无过错验尸报告 - Blameless Postmortem

前言

在咨询的经历中，发现有些软件项目经常出现线上事故，出现了线上事故之后，第一时间会去修复这个问题，第二时间，则是问责。

这是一个很有意思的现象，通常在一些传统行业的团队或者政府背景的团队中，发生了线上事故，他们会启动问责程序，找到事故的负责人，并对他做出相应的处罚。

作为程序员，大家都知道，代码的世界不出错是不可能的。问责在很大程度上会导致团队成员不敢写代码，不敢上线，不敢触碰线上环境的一切东西，最终导致团队研发效率下降。

那正确的做法应该是什么呢？

这里就给大家介绍一下Blameless Postmortem，中文意思就是无过错验尸报告。

什么是无过错验尸报告？

无过错验尸报告是对线上事故的书面记录，用来描述:

• 这一线上事故的影响。
• 减轻或解决事故所采取的行动。
• 事故的根本原因。
• 为防止该事故再次发生而采取的后续行动。

无过错验尸报告这个名字是英文直译过来的，如果觉得这个名字过于血腥，可以叫它无过错反思报告，或者无过错事故报告，或者无过错事后分析报告。但更多的人都习惯亲切的叫它验尸报告。

之所以强调无过错，是因为这样的话人们就不会在写报告的时候由于害怕被问责，从而互相埋怨或者隐藏自己的过错。

为什么需要无过错验尸报告？

验尸报告的目标是了解所有导致事故的根本原因，记录事故的经过以供未来参考，并制定有效的预防措施以减少事故再次发生的可能性。

为了使验尸报告能够有效地减少重复事故，总结过程必须激励团队识别根本原因并修复它们。

同时，关注这个过程并确保它是有效的则需要组织中各级的承诺。比如不能出现对团队某个人的问责。

什么时候需要无过错尸检报告？

线上事故都会有严重程度或者影响程度分级，因此，通常我们只会对级别较高的事故写尸检报告。

我们通常会在下面两个时间点开始写尸检报告：

• 修复事故期间
• 修复事故之后

谁完成验尸报告？

事故产生的服务所属的交付团队共同负责完成验尸报告。

但需要选择一名owner来主要负责编写报告，并且这个owner需要保证下面两件事情的发生：

1. 分配不同的人去完成各类的事故调研工作，最后把结果汇总给这个owner。
2. 保证报告中的改进action按照紧急程度安排到后面相应的迭代中。

如何跟踪报告中的action？

这个问题其实是紧接上面的第二条。

报告中的action通常分为两类：

1. 根本原因改进
2. 非根本原因改进

对于报告中的每个action：

• 应该在对应的团队的backlog中建卡，并根据优先级安排进相应的迭代。
• Owner要负责跟踪卡的完成情况。并记录到报告中。

验尸报告会议

验尸报告相关的会议有两种。

1. 一种是在编写报告前，用于讨论事故的根因。
2. 一种是在报告完成后，用于向团队分享报告内容，学习成长。

不管是哪种会议，都要记住，这个会议不是批斗会，不能在会议中指责任何人。

这里的指导原则和retro类似。

实践过程中，我发现大部分团队只会开第一个会议，在编写报告的过程中，大家基本上都学习了，并了解了报告中的根因。所以大部分团队都不会开第二个会议。

但是不少公司会开另外一种会议，就是报告写完了之后给领导的汇报会议，此会议根据不同公司的政策不同，可有可无。

报告模版

下图就是一个完整的报告模版。

报告可以是表格的形式，也可以是文档的形式。有了模版，写报告的人就可以照着模版往里面填内容了。

关于如何识别根因，Atlassian提供了一种叫5 Whys的分析方法，具体怎么做可以参考这里：

https://www.atlassian.com/tea...

总结

验尸报告是为了在软件开发过程中以及项目交付过程中能持续改进，有记录能存档，并且成为知识沉淀的一部分。

所以它的形式可以根据团队的实际情况来。我见过有团队用表格来写的，像上面模版那样，也有直接写卡上的，也有直接开会画在白板上然后拍下来的。

对于无过错验尸报告，大家在实践过程中有任何疑问，欢迎来找我讨论。

---

参考资料

https://www.atlassian.com/inc...
https://www.atlassian.com/inc...