起因是昨天写一个实时流任务,订阅一个 topic,处理后写到下游.框架搭起来想当然就上线了.任务起来之后可以看到消费,但下游迟迟看不到数据.
刷了十几分钟后,瞟了眼数据源的监控,消息数指数级上升,几个 consumer 全部 1000W+的 lag.
立马停了任务,review 了下代码,发现 sink 的 topic 直接取了 message 的 topic.于是变成了消费->生产->消费的死循环.并且每次消费和生产,消息数翻倍.
联系了队列的生产和消费的同学,重启了消费任务,重复数据影响也不是很大,没有影响到业务核心流程,也没有用户反馈.提心吊胆了一下午,但也还是抹过去了.
整个晚上人都挺懵的.今天一度不敢上线.想了下,还好只跑了十几分钟,并且非核心流程.假如是晚上上线,这样一个放大器跑一晚上.怕是整个集群的存储都要崩掉...
公司的队列没有鉴权机制,生产和消费都很随意.感觉这样也是有问题的.
不过,最主要的是,对待代码还是要敬畏,工作久了,就没有刚开始的那种初心了,感觉自己可以 cover 的住,变的傲慢.
1
bigbyto 2022-02-23 17:07:11 +08:00
其实总有麻木大意的时候,gitlab 那些大佬们应该够厉害了,当初还是发生了低级错误导致数据被删。公司内部要有一套机制去对付这类事发生才能从根本上去杜绝。
|
2
mxT52CRuqR6o5 2022-02-23 17:09:03 +08:00 1
靠敬畏可没法保证不出问题,不出问题得靠合理的流程,我读下来感觉你们好像没有完善的测试环境与测试流程
|
3
mxT52CRuqR6o5 2022-02-23 17:10:08 +08:00
应该去敬畏流程和制度,而不是去敬畏代码
|
4
oxoxoxox 2022-02-23 17:12:01 +08:00
1.代码 review 流程需要改善
2.代码提交前需要自测 3.需要独立的测试验证流程 4.系统需要异常通知机制 |
5
lucifer1108 OP |
6
darkengine 2022-02-23 17:16:29 +08:00 2
不是对代码敬畏,要对上线敬畏
|
7
3dwelcome 2022-02-23 17:37:32 +08:00
所以我更喜欢写客户端代码,崩了就崩了,让客户重启一下就行,这叫 BUG 。
而线上服务奔溃,那就属于严重事故,要担责任的。 问题是你线上服务,有时候并不知道什么时候会挂,提心吊胆的感觉,真是很糟糕。 |
8
abigeater 2022-02-23 17:39:05 +08:00
赞同,但要求快速上线的前提下,总是忽视了这些问题。
|
9
popbones 2022-02-23 18:08:45 +08:00 via iPhone 1
恰恰相反,无论多么小心,人其实是开发流程里最薄弱的环节,一个人的敬畏可以走多远?每个人都能做到吗?浑身是铁能打几根钉子?这个时候要依靠系统和流程,单元测试、集成测试、Peer Review 和 QA ,CI/CD 这些。否则每天要么麻木不仁,要么诚惶诚恐,加班、复查、猝死。
|
10
hejw19970413 2022-02-23 18:12:13 +08:00
以前我实习的时候,就是因为把一个判断写错了,就匆匆忙忙上了线,然后就没有然后了。从那时起,无论多紧急,都要再三确认,才能上线
|
11
arvinsilm 2022-02-24 09:16:05 +08:00
这。。。。哪怕自测跑一条消息也能发现吧
|
12
ezrealrao 2022-02-24 11:14:57 +08:00
让我想起了我之前做订单,一直和 increment 和 decrement 分不清,然后在扣减库存的时候一直 increment ,商户发现后质问我们,为什么订单越多,我这库存越多?
|