我们仍需心怀敬畏的面对每一行代码

[lucifer1108]

起因是昨天写一个实时流任务,订阅一个 topic,处理后写到下游.框架搭起来想当然就上线了.任务起来之后可以看到消费,但下游迟迟看不到数据.

刷了十几分钟后,瞟了眼数据源的监控,消息数指数级上升,几个 consumer 全部 1000W+的 lag.

立马停了任务,review 了下代码,发现 sink 的 topic 直接取了 message 的 topic.于是变成了消费->生产->消费的死循环.并且每次消费和生产,消息数翻倍.

联系了队列的生产和消费的同学,重启了消费任务,重复数据影响也不是很大,没有影响到业务核心流程,也没有用户反馈.提心吊胆了一下午,但也还是抹过去了.

整个晚上人都挺懵的.今天一度不敢上线.想了下,还好只跑了十几分钟,并且非核心流程.假如是晚上上线,这样一个放大器跑一晚上.怕是整个集群的存储都要崩掉...

公司的队列没有鉴权机制,生产和消费都很随意.感觉这样也是有问题的.

不过,最主要的是,对待代码还是要敬畏,工作久了,就没有刚开始的那种初心了,感觉自己可以 cover 的住,变的傲慢.

[bigbyto]

其实总有麻木大意的时候，gitlab 那些大佬们应该够厉害了，当初还是发生了低级错误导致数据被删。公司内部要有一套机制去对付这类事发生才能从根本上去杜绝。

[mxT52CRuqR6o5]

靠敬畏可没法保证不出问题，不出问题得靠合理的流程，我读下来感觉你们好像没有完善的测试环境与测试流程

[mxT52CRuqR6o5]

应该去敬畏流程和制度，而不是去敬畏代码

[oxoxoxox]

1.代码 review 流程需要改善
2.代码提交前需要自测
3.需要独立的测试验证流程
4.系统需要异常通知机制

[lucifer1108]

上线流程的问题:公司有比较完善的 ci cd 流程和平台,但是实时流任务和服务不太一样,允许本地打包上传,于是有了上面的骚操作.
@oxoxoxox
@mxT52CRuqR6o5

[darkengine]

不是对代码敬畏，要对上线敬畏

[3dwelcome]

所以我更喜欢写客户端代码，崩了就崩了，让客户重启一下就行，这叫 BUG 。

而线上服务奔溃，那就属于严重事故，要担责任的。

问题是你线上服务，有时候并不知道什么时候会挂，提心吊胆的感觉，真是很糟糕。

[abigeater]

赞同，但要求快速上线的前提下，总是忽视了这些问题。

[popbones]

恰恰相反，无论多么小心，人其实是开发流程里最薄弱的环节，一个人的敬畏可以走多远？每个人都能做到吗？浑身是铁能打几根钉子？这个时候要依靠系统和流程，单元测试、集成测试、Peer Review 和 QA ，CI/CD 这些。否则每天要么麻木不仁，要么诚惶诚恐，加班、复查、猝死。

[hejw19970413]

以前我实习的时候，就是因为把一个判断写错了，就匆匆忙忙上了线，然后就没有然后了。从那时起，无论多紧急，都要再三确认，才能上线

[arvinsilm]

这。。。。哪怕自测跑一条消息也能发现吧

[ezrealrao]

让我想起了我之前做订单，一直和 increment 和 decrement 分不清，然后在扣减库存的时候一直 increment ，商户发现后质问我们，为什么订单越多，我这库存越多？