有贷款无脑选 2 ，热钱不多，要抓住，先还完贷能一身轻。
而且小孩已经 2 岁了，过了那个特别折腾人到晚上睡不好的年纪。多关注下家庭给足情绪价值就行。

哈哈，抄码农博客，偷 GitHub 代码，挂钓鱼木马，csdn 这辈子有了。

@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 多个提交，容我先找把扫把你就在这不要走动，搁保洁阿姨都知道倒垃圾是倒一次还是倒两百多次。

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