阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 蜗牛互联网 「蜗牛互联网」欢迎转载，保留摘要，谢谢！

• 01 一次寻常的发布
• 02 故障发现和止血
• 03 事件缘起和善后
• 04 我的感受和思考

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

大家好，我是艿艿~~~一个每天肝到 2 点钟的小胖子

最近在和朋友一起肝一个 SpringBoot2.4.2 + Vue 的开源项目：https://github.com/YunaiV/ruoyi-vue-pro

记得 Star 关注下噢，胖友们的支持，真的很重要！

几年前，刚进入职场，作为程序员走上了技术这条路，不久便亲身经历了一件特别震撼的事情。那是一行代码引发的线上故障，故障造成了百万级的资金损失。时至今日，我依然印象深刻，也正是这件事，让我在职业生涯初期就形成了敬畏代码，严谨做事的态度。时间过去的比较久，我脑海里的细节也存在失真。我将尽量还原事件的重点信息，分享我的感受和思考，希望能带给你启发。

01 一次寻常的发布

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

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

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

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

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

02 故障发现和止血

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

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

03 事件缘起和善后

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

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

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

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

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

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

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

04 我的感受和思考

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

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

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