@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 吧

@aababc #15
只能说没踩过坑的人才会喜欢 RESTful API 设计。。http 就该老老实实当 transport ，别乱参与业务逻辑了。不然规模上去有的你头秃。
anyway ，你喜欢就好。

正确做法是：
http：业务抛弃 http status code （俗称大码），使用业务小码区分业务错误。
grpc：使用 rpc status extension 。

任何情况下 http 大码都应该作为 i/egress Transport 层的状态表示，业务返回统一以 http 200 完成。
然后，在这个基础上，再去考虑 error 封装问题。

你都用 linux 自建 nas 了，那 grafana+ prometheus 到底有什么不好的，要啥数据自己手搓 exporter 分分钟撸出来。

@dcsuibian
事实上是
no one gives a shit about what you have done in your place

@hanxu317138
开发周期长才应该尽可能使用 rebase ，同时保持提交记录语意清晰，同步主干分支修改时尽量使用 rebase ，你一直 merge master 去同步苦果就是这样。

鉴于你现在情况，直接 squash commits 到一个然后 rebase 吧，反正都这样了，你大概也没拆语义化提交

你如果 rebase 会冲突 那合并一样会冲突，这有什么好吐槽的？

另外如果谁两周做一个需求合并主分支 200 多个提交，容我先找把扫把你就在这不要走动，搁保洁阿姨都知道倒垃圾是倒一次还是倒两百多次。

虽然但是。骗保当心吃官司

代报销？还有这种路子？
那你用什么换呢？

搞那么多就是为了省掉注册两行？你早说呗

开发脚手架 new 个消息桩子出来，然后生成一下 init ，导入包路径即注册，这不是很简单的

你要相信所有免费东西都是暗中标好价格的，返费只有一年是基本操作了。
至于免费送宽带提速，问清楚有没有低消和合约期。这种显然都是陷阱，op 多吃两次亏就知道了

@assiadamo
#23 你这才叫毒瘤… 改 go generate 代码真不是碳基生物能想的活，不要滥用 generate 和开发脚手架。