我的亲历:一行代码,百万人民币打水漂
作者:互联网
导读:几年前,我刚进入职场,作为程序员走上了技术这条路,不久便亲身经历了一件特别震撼的事情。那是一行代码引发的线上故障,故障造成了百万级的资金损失。时至今日,我依然印象深刻,也正是这件事,让我在职业生涯初期就形成了敬畏代码,严谨做事的态度。时间过去的比较久,我脑海里的细节也存在失真。我将尽量还原事件的重点信息,分享我的感受和思考,希望能带给你启发。
一次寻常的发布
如往常一样,又来到了一个发布窗口,这次发生变更的迭代很简单,是支持全链路压测的一个功能上线。
我们团队负责的是一个底层核心系统,链路上会有上百个应用依赖,为了应对大促这种超高流量的场景,大促前有一轮又一轮的压测。在首轮压测时,便发现我们的系统上有个数据库表不支持压测,导致压测计划无法进行。因此团队有位同事 A 就起了紧急迭代,针对业务依赖的这个数据库表做压测改造,代码变更也就几行。
与此同时,同事 B 在这个系统上也想改下代码,就搭了压测改造的车,两块变更一起发布。
同事 A 负责走发布流程,我们的系统有几百台服务器,部署会分为好几组,通常会搞到很晚。那天晚上,我也和大家一样,回去的比较晚,而且还忘带了手机充电器。
回去没多久,我的手机就自动关机了,想着第二天到公司再充电。
故障发现和止血
到了公司,给手机充上电后,就知道出事了。有大量客诉,并且出现排队现象,同时上游系统反馈有个错误码上午开始增加的特别多,一切迹象表明:对业务产生的一系列影响和昨晚的发布有关,同事 A 果断进行了代码回滚,避免了午高峰来临时将影响扩大。
代码回滚后,上游系统之前异常的错误码逐步恢复到基线水平,客满的同事也反馈不再有新的投诉进来。至此,止血工作完成。
事件缘起和善后
接下来就是定位原因和善后工作。团队内部仔细看了下本次发布提交的代码,再结合上游系统感知到的错误码,就定位到有一行代码的变更,影响了整个逻辑。
这行代码被同事 B 改成了 「return null」,而老逻辑是有具体数据的时候会返回实体信息,没有才返回 null。这个结果信息的变化,直接影响了上游的交易,从而商户收款紊乱,引起大量客诉,也造成了资金不平。
善后工作主要就是调账,安抚商户,差额的部分平台补足以及故障定级和整体复盘。调账的前提是,能知道哪些订单有问题,故障期间每个订单错误的收款户是哪个,实际上应该是哪个。产出这样一份数据是很复杂的,涉及很多业务和很多团队,光拉本次故障受影响数据就花费了一周以上。
受影响数据拿到之后基本就能知道资损的量级,也可以基于此给受影响的用户赔偿,同时给故障定级。最终资损百万级,故障级别也相当高,高到故障不能往一线员工身上挂,只能往管理层上挂。
事后就有一大帮人参与复盘,拷问本次发布的各个环节是否符合规范。有没有代码 CR,有没有测试,有没有灰度,有没有监控,有没有核对。我发现好像该有的我们都有,但事情还是这么诡异的发生了,并且是被迫发现。
诡异之处就在于同事 B 也不知道有提交过那行「return null」的代码,能找到 CR 截图但并未覆盖到那一行代码,测试只关注了压测改造的变更并没有关注到搭车的内容,灰度发布又在晚上,感知不到业务异常,监控核对有报警,但平常比较关注的我在当天刚好手机关机。
由此看来,故障的直接原因是同事 B 的代码误提交,但事实上在提交后的各个环节里都有疏漏的地方。不久之后,同事 B 和负责测试的同事就离职了。他们不需要为公司承担资金的损失,但会因此事得到不好的绩效,这可能是他们离开的原因。
我的感受和思考
当时还是职场小菜鸟的我懵懵懂懂,亲历了这么一次大故障,让我感受到代码的强大,强大的影响力和破坏力。
「敬畏代码」不再是耳边的循循教导,而是要落实到工程实践中。对待代码的盲目自信,也渐渐转变成只相信测试结果。代码是人敲出来的,人会犯错,但机器不会。编写的代码不仅要经得起理论的推敲,也要挺得住实践的检验。不能想当然,每当心存侥幸的时候,你觉得不会发生的事情它还真的就会发生。严谨做事,应当成为职业工程师的基本素养。
另外就是规范的重要性。什么是规范?规范是明文规定或约定俗成的标准。人总会有疏忽,大脑会有停转的时刻,实际执行也有遗漏的时候。遵循规范,人的不可靠带来的影响可以限制在一定范围内,大大减少出错率。规范的制定,执行,调整,能够提升效率,降低风险,避免类似这次故障的低级错误。
(完)
首发于公众号「蜗牛互联网」。
标签:打水漂,压测,代码,同事,错误码,故障,亲历,发布,百万 来源: https://www.cnblogs.com/huayonglun/p/13946842.html