线上出了Bug，全组排查到凌晨三点。最后发现是我改公共类导致的。检讨书写到一半，隔壁老兵说了句话，让我从“背锅侠“变成了“改革者“

关注

原创最新推荐文章于 2026-11-13 22:30:05 发布 283 阅读 AI 写同款· GEO 优化 ›

15. GD32E230定时器实战：基于TIMER5的1秒LED闪烁中断配置详解本文详细讲解了如何在GD32E230微控制器上配置TIMER5定时器，实现精准的1秒LED闪烁中断。内容涵盖从时钟开启、参数计算、中断设置到服务函数编写的完整流程，重点解析了预分频值与周期值的配置方法，帮助开发者掌握硬件定时器的核心应用。阅读详情

故事是这样的。

凌晨两点，手机震了。

群里炸了，生产环境挂了，用户支付页面全白屏，客服电话被打爆。技术总监@全体成员，所有人立刻上线排查。

我迷迷糊糊爬起来，打开电脑，心里一个咯噔。

昨天下午我改了一个公共类，就加了两行代码，优化了一个工具方法的性能。代码审查过了，测试也跑通了，晚上八点发的版本。

不会是我吧。。。

不会吧不会吧。

群里消息刷得飞快，运维在查日志，前端在排查接口，后端在回滚代码。我手心开始冒汗，偷偷去看了一眼我改的那个类，越看越心虚。

凌晨三点半，真相大白。

就是我改的那个公共类，导致了支付模块的一个边界条件判断失效。影响范围，全站支付功能，持续时间，5个小时，损失。。。不敢想。

我当时脑子一片空白。

群里安静了几秒钟，然后技术总监发了一句，明天早上开复盘会。

我知道接下来会怎样，背锅，写检讨，可能还要扣绩效。我打开Word，开始写检讨书，「由于本人的低级失误，导致线上故障，给公司造成重大损失，我深刻反省。。。」

写到一半，隔壁工位的老张发了条私信过来。

老张是团队里的老兵，写了十几年代码，经历过无数次线上事故。他说，别急着写检讨，明天复盘会上听我的。

第二天早上，会议室里气氛凝重。

技术总监让我先说说情况，我硬着头皮把事情经过讲了一遍，然后说，这是我的失误，我愿意承担责任。

话音刚落，老张开口了。

他说，这不是某个人的失误，这是我们整个防御体系的失效。

会议室里所有人都看向他。

老张打开电脑，投屏了一张图，上面画着好几层奶酪，每层都有洞。他说，这叫瑞士奶酪模型，是1990年英国曼彻斯特大学一个教授提出来的，专门用来分析事故为什么会发生。

他指着那些奶酪说，你看，我们的防御体系就像这些奶酪，每一层都是一道屏障。第一层是代码审查，第二层是自动化测试，第三层是QA测试，第四层是预发布验证，第五层是生产环境监控。

理想状态下，每一层都应该是完好无缺的，但实际上，每一层都有漏洞。

他看着我说，你改公共类的时候，代码审查为什么没发现问题，自动化测试为什么没覆盖到这个边界条件，QA测试为什么没测到支付场景，预发布环境为什么没模拟出这个问题，生产环境监控为什么没有及时报警。

当所有层的漏洞恰好对齐的时候，事故就发生了。

会议室里安静了几秒钟。

技术总监若有所思地点了点头，说，继续说。

老张切换了一张PPT，上面是一张表格，我一眼就看到了那个数字，100x。

他说，你们知道软件缺陷在不同阶段修复的成本差异有多大吗，需求分析阶段发现问题，成本是1，设计阶段是3到5倍，编码阶段是10倍，测试阶段是15到20倍，生产环境，100倍起步。

这次事故，我们付出了100倍的代价，但这不是某个人的错，而是我们的防御体系在前面四个阶段全部失效了。

他看向技术总监，说，我们应该问的不是谁犯了错，而是我们的系统为什么没有拦住这个问题。

技术总监沉默了一会儿，说，你说得对。

然后他看向我，说，这次事故，你不需要写检讨，但我们需要一份完整的根因分析报告，不是追责，而是找出我们防御体系的每一个漏洞，然后补上。

我当时鼻子一酸。

会后，老张拉着我去楼下抽烟。

他说，你知道Google怎么处理线上事故吗，他们有一套叫Blameless Postmortem的文化，翻译过来就是无责复盘。核心理念就是，事故发生后，聚焦查找根本原因，而不是追究个人责任。

他吐了口烟，说，你想想看，如果今天我们把你拉出来批评一顿，扣你绩效，下次再有人改公共类的时候，他会怎么做，他会隐瞒，会推责，会想尽办法证明这不是他的问题。

但如果我们把重点放在系统上，放在流程上，下次再有人改公共类的时候，他会主动提出来，这个改动影响范围有多大，我们需要加什么测试用例，需要在哪些环节加强审查。

这才是一个学习型组织应该有的样子。

我问他，那我们接下来应该怎么做。

他掐灭烟头，说，代码审查流程要改，公共组件的改动必须有至少两个资深工程师审查，而且要明确标注影响范围。然后自动化测试覆盖率要提上去，尤其是公共组件，必须有完整的单元测试，每次提交合并的时候必须通过所有测试，否则禁止合码。还有预发布环境要真正模拟生产环境，不能只是走个过场。另外生产环境监控要加强，关键业务指标要有实时报警。

他拍了拍我肩膀，说，这些都是我们这次事故暴露出来的问题，不是你一个人的问题。

回到工位，我打开那份检讨书，删掉了。

然后新建了一个文档，标题是「支付模块故障根因分析报告」。

我花了整整一周时间，把这次事故的每一个环节都梳理了一遍。代码审查环节，审查者没有意识到这是一个公共类，影响范围评估不足。自动化测试环节，这个工具方法的单元测试覆盖率只有60%，边界条件没有覆盖到。QA测试环节，测试用例里没有包含支付金额为0的场景。预发布环节，预发布环境的数据库配置跟生产环境不一致，导致这个问题没有暴露。监控环节，支付成功率的报警阈值设置得太宽松，5个小时后才触发报警。

五层防御，五个漏洞，恰好对齐。

报告写完后，技术总监组织了一次全员分享会，让我把这份报告讲给所有人听。

讲完之后，技术总监说，从今天开始，我们要建立一套完整的公共组件改动规范。公共组件必须有完善的单元测试，覆盖率不低于80%。公共组件的改动必须经过至少两个资深工程师的代码审查，并且要明确标注影响范围。我们要建立一个公共组件改动的checklist，每次改动都要过一遍。预发布环境要跟生产环境保持一致，包括数据库配置、中间件版本、网络环境。关键业务指标的监控报警要收紧，不能等到用户投诉了才发现问题。

他看着所有人，说，这些规范不是为了限制大家，而是为了保护大家。我们要建立的是一个学习型组织，而不是一个恐惧文化的组织。

会后，好几个同事过来跟我说，谢谢你把这件事讲出来，我们以前也遇到过类似的问题，但都不敢说。

我突然意识到，老张那句话的分量。

如果今天我们把这次事故定性为「个人低级失误」，那么下次再有人遇到类似的问题，他会选择隐瞒，会选择推责，会选择自保。但如果我们把它定性为「流程体系缺失」，那么下次再有人遇到问题，他会选择暴露，会选择分享，会选择改进。

这就是文化的力量。

三个月后，我们的公共组件改动规范已经完全落地了。代码审查通过率从原来的95%降到了70%，但线上事故率从每月3次降到了每月0.5次。自动化测试覆盖率从60%提升到了85%，预发布环境的问题发现率提升了3倍。

更重要的是，团队的氛围变了。

以前大家改代码都小心翼翼，生怕出问题，出了问题就互相推责。现在大家改代码更大胆了，因为知道有完善的防御体系在保护着，出了问题就一起复盘，一起改进。

有一次，前端的小李改了一个公共组件，结果在预发布环境发现了一个严重问题。他主动在群里@所有人，说这个问题如果流到生产环境会导致全站崩溃，然后详细分析了问题原因，并且提出了改进建议。

技术总监在群里发了个大拇指，说，这才是我们想要的文化。

我想起老张那天跟我说的话，他说，2024年亚马逊有个AI工具叫Kiro，一周内引发了4次最高级别事故，电商平台瘫痪了6小时。后来调查发现，不是技术问题，而是裁员1.6万人之后，运维团队减员，工程师超负荷工作，引发了连锁反应。

技术事故的背后，往往是组织层面的问题。