导读：几年前，我刚进入职场，作为程序员走上了技术这条路，不久便亲身经历了一件特地震撼的事件。那是一行代码引发的线上故障，故障造成了百万级的资金损失。时至今日，我仍然印象粗浅，也正是这件事，让我在职业生涯初期就造成了敬畏代码，谨严做事的态度。工夫过来的比拟久，我脑海里的细节也存在失真。我将尽量还原事件的重点信息，分享我的感触和思考，心愿能带给你启发。
一次寻常的公布
如平常一样，又来到了一个公布窗口，这次产生变更的迭代很简略，是反对全链路压测的一个性能上线。
咱们团队负责的是一个底层外围零碎，链路上会有上百个利用依赖，为了应答大促这种超高流量的场景，大促前有一轮又一轮的压测。在首轮压测时，便发现咱们的零碎上有个数据库表不反对压测，导致压测打算无奈进行。因而团队有位共事 A 就起了紧急迭代，针对业务依赖的这个数据库表做压测革新，代码变更也就几行。
与此同时，共事 B 在这个零碎上也想改下代码，就搭了压测革新的车，两块变更一起公布。
共事 A 负责走公布流程，咱们的零碎有几百台服务器，部署会分为好几组，通常会搞到很晚。那天早晨，我也和大家一样，回去的比拟晚，而且还忘带了手机充电器。
回去没多久，我的手机就自动关机了，想着第二天到公司再充电。
故障发现和止血
到了公司，给手机充上电后，就晓得出事了。有大量客诉，并且呈现排队景象，同时上游零碎反馈有个错误码上午开始减少的特地多，所有迹象表明：对业务产生的一系列影响和昨晚的公布无关，共事 A 果决进行了代码回滚，防止了午顶峰来长期将影响扩充。
代码回滚后，上游零碎之前异样的错误码逐渐复原到基线程度，客满的共事也反馈不再有新的投诉进来。至此，止血工作实现。
事件缘起和善后
接下来就是定位起因和善后工作。团队外部认真看了下本次公布提交的代码，再联合上游零碎感知到的错误码，就定位到有一行代码的变更，影响了整个逻辑。
这行代码被共事 B 改成了「return null」，而老逻辑是有具体数据的时候会返回实体信息，没有才返回 null。这个后果信息的变动，间接影响了上游的交易，从而商户收款错乱，引起大量客诉，也造成了资金不平。
善后工作次要就是调账，安抚商户，差额的局部平台补足以及故障定级和整体复盘。调账的前提是，能晓得哪些订单有问题，故障期间每个订单谬误的收款户是哪个，实际上应该是哪个。产出这样一份数据是很简单的，波及很多业务和很多团队，光拉本次故障受影响数据就破费了一周以上。
受影响数据拿到之后根本就能晓得资损的量级，也能够基于此给受影响的用户抵偿，同时给故障定级。最终资损百万级，故障级别也相当高，高到故障不能往一线员工身上挂，只能往管理层上挂。
预先就有一大帮人参加复盘，拷问本次公布的各个环节是否符合规范。有没有代码 CR，有没有测试，有没有灰度，有没有监控，有没有核查。我发现如同该有的咱们都有，但事件还是这么诡异的产生了，并且是被迫发现。
诡异之处就在于共事 B 也不晓得有提交过那行「return null」的代码，能找到 CR 截图但并未笼罩到那一行代码，测试只关注了压测革新的变更并没有关注到搭车的内容，灰度公布又在早晨，感知不到业务异样，监控核查有报警，但平时比拟关注的我在当天刚好手机关机。
由此看来，故障的间接起因是共事 B 的代码误提交，但事实上在提交后的各个环节里都有疏漏的中央。不久之后，共事 B 和负责测试的共事就到职了。他们不须要为公司承当资金的损失，但会因而事失去不好的绩效，这可能是他们来到的起因。
我的感触和思考
过后还是职场小菜鸟的我懵懵懂懂，亲历了这么一次大故障，让我感触到 代码的弱小，弱小的影响力和破坏力。
「敬畏代码」不再是耳边的循循教诲，而是要落实到工程实际中。看待代码的自觉自信，也慢慢转变成只置信测试后果。代码是人敲进去的，人会犯错，但机器不会。编写的代码不仅要经得起实践的斟酌，也要挺得住实际的测验。不能想当然，每当心存侥幸的时候，你感觉不会产生的事件它还真的就会产生。谨严做事，该当成为职业工程师的根本素养。
另外就是标准的重要性。什么是标准？标准是明文规定或约定俗成的规范。人总会有忽略，大脑会有停转的时刻，理论执行也有脱漏的时候。遵循标准，人的不牢靠带来的影响能够限度在肯定范畴内，大大减少出错率。标准的制订，执行，调整，可能晋升效率，升高危险，防止相似这次故障的低级谬误。
（完）
首发于公众号「蜗牛互联网」。