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

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

一般来说，假如只是一个没有对终端使用者太多影响的小问题，可以不须用开事故检讨；然而，如果有造成一定程度的影响，事故检讨就会有必要。开事故检讨不是要找战犯，而是要确保问题能够被根治，以及确保未来不会再发生类似问题。

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

事故检讨的本质

要做好事故检讨这件事，需要先厘清事故检讨的本质。造成事故对个人与团队肯定都会有伤害，然而没有人是完美不会犯错的，所以事故是在所难免。不过，当事故已经发生了，该专注的就是解决，以及确保未来可以做更好。

所谓做更好，具体来说，首先是要去厘清如何确保同样的问题，在未来不会再次发生? 假如真的无法完全避免问题，那有没有方法能让问题及早被发现? 以及当发现问题后，有没有更快解决问题的方法?

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

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

不指责人的事故检讨

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

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

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

在台湾软体史上，有一个叫趋势 594 的历史事件，是当年趋势科技有工程师发布程式码前测试不完全，导致客户的系统瘫痪，造成趋势科技市值蒸发 170 亿元台币。当时趋势的执行长受访的报导 (连结)有这么一个段落：

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

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

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

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

阅读更多

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

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