软件工程师该如何做好事故检讨?

先前我们分别谈了 《软件工程师该如何做好监控 (monitoring)？》 和 《软件工程师该如何值班 (on-call)?》，这篇文将延续这个主题，来聊事故后的复盘。

一般来说，如果只是一个对终端用户影响不大的小问题，不一定需要开事故检讨；但只要造成了一定程度的影响，事故检讨就有必要。开事故检讨不是为了找战犯，而是要确保问题能够被根治，并且确保未来不会再发生类似问题。

在业界，事故检讨一般有几个名称，包含 incident review（直译就是事故检讨）、sev review（sev 是在 软件工程师该如何做好监控 (monitoring)? 一文提过的概念，也代表事故），以及 postmortem（英文另一个意思是验尸，事故检讨本质上和验尸有些类似，都是事后回头找原因）。

事故检讨的本质

要做好事故检讨，得先厘清事故检讨的本质。事故一定会对个人与团队造成伤害，但没有人是完美、永远不犯错的，所以事故在所难免。不过，当事故已经发生，重点就该放在解决问题，以及确保未来可以做得更好。

所谓做得更好，具体来说，首先是厘清如何确保同样的问题未来不再发生。如果真的无法完全避免，那有没有方法让问题更早被发现？以及发现问题后，有没有更快解决问题的方法？

找出以上这些问题的答案，才是事故检讨应该做的事。

而在事故检讨中，每位参与者都应抱持「从错误中学习」的心态。事故检讨中学到的内容，也需要进一步传承。这也是为什么许多制度成熟的公司在事故检讨时，都会有完整会议记录，确保其他团队，甚至公司里其他组，也能从这次经验中学习。

不指责人的事故检讨

谈到事故检讨，有一个不能不提的重点，就是「不指责人的事故检讨」。

如上面提到，事故检讨的本质是为了避免未来再出现同样的问题。基于这个本质，要尽可能避免在事故检讨里找战犯。这个世界没有完美的人，也没有完美的流程，犯错总是难免的；但同样的错误反复发生就不应该。因此团队该关注的，不是谁犯错，而是如何让未来不再犯同样的错。

先前 Meta 工程副总 Vijaye 在 2021 年 Meta 全球重大事故后，发过一篇分享（链接），谈到不指责人的事故检讨（blameless SEV review）。他提到，在事故检讨时，不该问「是谁造成这次事故」，因为在这个时机点找战犯，不仅对解决问题没帮助，也会让大家未来不敢做有风险的创新尝试。

在台湾软件史上，有一个叫趋势 594 的历史事件。当年趋势科技有工程师在发布代码前测试不完整，导致客户系统瘫痪，造成趋势科技市值蒸发 170 亿元新台币。当时趋势执行长受访的报道（链接）有这么一段：

「我相信，我只要问一句：『谁写的？为什么没测试好就发出来了？』我想， （公司）从此就完蛋了！」陈怡桦说， 当时不断提醒自己，不要伤害员工创新精神， 「不要问我是哪个员工干的？是哪个部门？」

事件过去 8 年，「元凶」是谁，仍是趋势内部的一个谜，只有少数高层才知道。

危机就是转机，因为这起「失误的创新」，让陈怡桦开始思考， 是否可以「不要把更新病毒码的程序放在客户的电脑里」， 也因此让趋势领先同业至少三、四年发展云端技术， 趋势才有机会成为如今服务器安全市场的龙头。

这是一个很好的示范，说明了什么是不指责的复盘，以及为什么要不指责。事实上，当一个组织文化演变成找战犯、指责人的氛围，当问题发生时，犯错的个人或团队很可能会试图掩盖问题（因为不想被指责或背锅），这反而不利于解决问题。这也是为什么多数拥有良好文化的组织，会强调事故发生时不指责人，而是专注在事情本身。

在 2026 年，AI 圈最热门的 AI 代理工具 Claude Code 因为一次部署失误，导致 source map 公开，进而让原本闭源的代码变成公开。在社群中，很多人在讨论搞砸这次部署的工程师会不会被开除。

但 Claude Code 创作者兼负责人 Boris Cherny 公开回应：「出错在所难免。作为一个团队，最重要的是认清问题从来不在于某个人，而在于流程、文化或基础设施。就这次情况而言，有一个手动部署步骤本应被更好地自动化。我们的团队已经针对这部分做了一些改进，后续还有几项优化正在进行中。」

Boris 的这个回应中，体现了「不指责人 + 专注在改善系统，让同样事故不再发生」，是我们认为很值得学习的典范。

阅读更多

如果你对如何做好事故检讨感兴趣，我们在 E+ 有写更深入详细的内容，包含具体在开事故检讨会议时有哪些要诀、如何做好事故检讨的文档记录、业界有哪些推荐参考资源。有兴趣的读者，欢迎加入 E+ 成长计划。

本文为 E+ 成长计划的深度内容，截取前三分之一开放免费阅读。欢迎加入 E+ 成长计划阅读完整版本（点此了解 E+ 的详细介绍）