01 一次寻常的发布

如往常一样，又来到了一个发布窗口，这次发生变更的迭代很简单，是支持全链路压测的一个功能上线。

我们团队负责的是一个底层核心系统，链路上会有上百个应用依赖，为了应对大促这种超高流量的场景，大促前有一轮又一轮的压测。在首轮压测时，便发现我们的系统上有个数据库表不支持压测，导致压测计划无法进行。因此团队有位同事 A 就起了紧急迭代，针对业务依赖的这个数据库表做压测改造，代码变更也就几行。

与此同时，同事 B 在这个系统上也想改下代码，就搭了压测改造的车，两块变更一起发布。

同事 A 负责走发布流程，我们的系统有几百台服务器，部署会分为好几组，通常会搞到很晚。那天晚上，我也和大家一样，回去的比较晚，而且还忘带了手机充电器。

回去没多久，我的手机就自动关机了，想着第二天到公司再充电。

02 故障发现和止血

到了公司，给手机充上电后，就知道出事了。有大量客诉，并且出现排队现象，同时上游系统反馈有个错误码上午开始增加的特别多，一切迹象表明：对业务产生的一系列影响和昨晚的发布有关，同事 A 果断进行了代码回滚，避免了午高峰来临时将影响扩大。

代码回滚后，上游系统之前异常的错误码逐步恢复到基线水平，客满的同事也反馈不再有新的投诉进来。至此，止血工作完成。

03 事件缘起和善后

接下来就是定位原因和善后工作。团队内部仔细看了下本次发布提交的代码，再结合上游系统感知到的错误码，就定位到有一行代码的变更，影响了整个逻辑。

这行代码被同事 B 改成了 「return null」，而老逻辑是有具体数据的时候会返回实体信息，没有才返回 null。 这个结果信息的变化，直接影响了上游的交易，从而商户收款紊乱，引起大量客诉，也造成了资金不平。

善后工作主要就是调账，安抚商户，差额的部分平台补足以及故障定级和整体复盘。调账的前提是，能知道哪些订单有问题，故障期间每个订单错误的收款户是哪个，实际上应该是哪个。产出这样一份数据是很复杂的，涉及很多业务和很多团队，光拉本次故障受影响数据就花费了一周以上。

受影响数据拿到之后基本就能知道资损的量级，也可以基于此给受影响的用户赔偿，同时给故障定级。最终资损百万级，故障级别也相当高，高到故障不能往一线员工身上挂，只能往管理层上挂。

事后就有一大帮人参与复盘，拷问本次发布的各个环节是否符合规范。有没有代码 CR，有没有测试，有没有灰度，有没有监控，有没有核对。我发现好像该有的我们都有，但事情还是这么诡异的发生了，并且是被迫发现。

诡异之处就在于同事 B 也不知道有提交过那行「return null」的代码，能找到 CR 截图但并未覆盖到那一行代码，测试只关注了压测改造的变更并没有关注到搭车的内容，灰度发布又在晚上，感知不到业务异常，监控核对有报警，但平常比较关注的我在当天刚好手机关机。

由此看来，故障的直接原因是同事 B 的代码误提交，但事实上在提交后的各个环节里都有疏漏的地方。不久之后，同事 B 和负责测试的同事就离职了。他们不需要为公司承担资金的损失，但会因此事得到不好的绩效，这可能是他们离开的原因。

04 我的感受和思考

亲历了这么一次大故障，让我感受到代码的强大，强大的影响力和破坏力 。

「敬畏代码」不再是耳边的循循教导，而是要落实到工程实践中。对待代码的盲目自信，也渐渐转变成只相信测试结果。代码是人敲出来的，人会犯错，但机器不会。 编写的代码不仅要经得起理论的推敲，也要挺得住实践的检验。不能想当然，每当心存侥幸的时候，你觉得不会发生的事情它还真的就会发生。严谨做事，应当成为职业工程师的基本素养。

另外就是规范的重要性。什么是规范？规范是明文规定或约定俗成的标准。人总会有疏忽，大脑会有停转的时刻，实际执行也有遗漏的时候。遵循规范，人的不可靠带来的影响可以限制在一定范围内，大大减少出错率。 规范的制定，执行，调整，能够提升效率，降低风险，避免类似这次故障的低级错误。