V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  povsister  ›  全部回复第 1 页 / 共 41 页
回复总数  815
1  2  3  4  5  6  7  8  9  10 ... 41  
啊这。应该是 bug 吧,否则黑产用这玩意玩个反射 ddos 伤害可太高了
3 天前
回复了 Socrazy 创建的主题 路由器 求推荐不带 Wifi 的主路由器
rb952 有个升级款啥的。建议 rb5009 一步到位(
3 天前
回复了 minianson3 创建的主题 宽带症候群 headscale+derper+tailscale 组网问题
ping 有啥用?线路质量不是这么看的
7 天前
回复了 vst93 创建的主题 分享创造 bili-fm 通过音频来听 B 站节目
大致扫了眼代码,作为练手项目完成度尚可。但大概 b 站一更新签名这 app 就废了
手上没实权就别管那么多,掌管打绩效的权利才是该管人的角。你当好包工头就行了,至于磨人的活,信息留好到时候自然有人替你磨。
@zachary99 携转电信出去现在发短信没有任何合约的情况电信都不挽留。携转其他运营商到电信+升一档套餐,不给任何优惠。
@zachary99 电信五折现在没了啊,上周刚问的。229 套餐没有任何优惠
12 天前
回复了 singed58 创建的主题 职场话题 我也来问问 offer 怎么选?
有贷款无脑选 2 ,热钱不多,要抓住,先还完贷能一身轻。
而且小孩已经 2 岁了,过了那个特别折腾人到晚上睡不好的年纪。多关注下家庭给足情绪价值就行。
哈哈,抄码农博客,偷 GitHub 代码,挂钓鱼木马,csdn 这辈子有了。
13 天前
回复了 aababc 创建的主题 程序员 golang 中 error 如何影响 log 和 api 状态
@aababc
你列举的正是问题所在之一。
API 数量上升之后,服务治理将是一个非常头痛的问题,稍有不慎服务状态就和基础设施状态耦合进去了。你使用 http 状态码会加剧这一过程。

举个例子,http 504 是 gateway timeout ,但业务逻辑执行超时是很常见的现象,现在微服务框架都具备在链路超时 quota 超过后主动取消请求的能力,并且返回 deadline exceed 错误。按照你的想法,那它应该被设定为返回 http 504 。

ok ,记住上面的结论。
现实中,微服务和微服务间存在非常多的 middlebox ( router/Switch/L4/L7 LB ),他们会透明化的按照某些规则转发 http 请求。
假设,有一天中间某个 L7 负载均衡故障,造成 http 转发产生 504 超时。
请问:你怎么判断这个 504 是基础设施故障还是你业务逻辑故障?

以上是可观测问题,下面继续说深刻点。关于 SLO 治理。
正确的方式是让对的人去处理对的事情,而不是服务故障牵一发而动全身。因为你已经混淆了业务响应和基础设施问题,那服务出现故障告警时,运维和开发都会被拉进去。告警噪音将彻底击溃整个系统开发和 SRE 的基本信任。

ok ,到这都还是只讲了 http 。
那如果引入更多的应用层协议,使用 gRPC ,使用 thrift 时,虽然他们都是使用 http transport ,但并不遵守你那套 http status 要求,那你的告警和观测系统要各自做一套吗?

综上,最好的办法是,业务独立使用一套自己定义的错误观测体系,所有的应用层协议都按 transport 层处理。明确基础设施和业务边界
@stong2
#7 其实你分析的已经很对了。
总结就是,不要一厢情愿的去做自己认为有价值的事情,跟老板拉通对齐可不是一句虚话。
任何东西如果不能落下来量化为成果,做之前都需要思考一下。

拆老板的 OKR 能赚钱赚职级,做对的事情能赚名声。
这俩不冲突,甚至是相辅相成的。
KPI 和技术影响力都是需要一起抓的,这样工作才不会受委屈。
手机码字格式不错,点赞。

看完之后,替你分析一下吧。个人看法,仅作参考。

1. 非全日制本科
学历硬伤,这个越大越正规的厂提报晋升、调薪都会被 challenge 。看你描述似乎你也不是某个大 BOSS 心腹,那只会更倒霉。

2. 再看工作经历,怎么说呢。我一点点给你拆吧。

[- 迁移公司代码从 svn 至 gitlab ]
翻译:吃了一堆没人愿意吃的屎山,0 业务收益。

[由无到有,基于 XXX 搭建 XXX]
翻译:干了一堆没人愿意干的脏活,但没输出提效成果。节省多少人力?加速了多少研发需求吞吐?
再加上,你原本工作就是搞自动构建的,这些都是本职工作。做不好反倒有问题。

[接触智驾,深度参与 XXX]
翻译:没看到全权负责什么落地,都是大量 support 工作,而且泛的厉害。
真是最佳队友啊。这牛马精神值得一个年度最佳员工的虚名。

3. [高德总监:你觉得自己配吗]
虽然实话很伤人,但大厂就是这样的,你的工作不具有不可替代性。做好本职工作并且有所超越的情况下才属于 Excellent 。否则真就只能指望下普调或者老板大发慈悲。

老板嘛,都是喜欢有所建树的开拓者,至于开拓成果背后的事情,who cares ?
不然大厂也不会那么多喜欢向上管理,KPI 至上的卷王了。


打了这一堆,真是感觉把自己的磨盘看了个通透。总的看下来我觉得 OP 在执行力和责任心上肯定是杠杠的,可以突出这点去尝试找一找,希望 OP 也能早日找到自己喜欢的工作
不用 multi stage 就是一个 run 一层,你数一下你有多少个 run 吧
14 天前
回复了 aababc 创建的主题 程序员 golang 中 error 如何影响 log 和 api 状态
@aababc #15
只能说没踩过坑的人才会喜欢 RESTful API 设计。。http 就该老老实实当 transport ,别乱参与业务逻辑了。不然规模上去有的你头秃。
anyway ,你喜欢就好。
15 天前
回复了 aababc 创建的主题 程序员 golang 中 error 如何影响 log 和 api 状态
正确做法是:
http:业务抛弃 http status code (俗称大码),使用业务小码区分业务错误。
grpc:使用 rpc status extension 。

任何情况下 http 大码都应该作为 i/egress Transport 层的状态表示,业务返回统一以 http 200 完成。
然后,在这个基础上,再去考虑 error 封装问题。
1  2  3  4  5  6  7  8  9  10 ... 41  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1702 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 37ms · UTC 16:41 · PVG 00:41 · LAX 08:41 · JFK 11:41
Developed with CodeLauncher
♥ Do have faith in what you're doing.