前言
在咨询的经历中，发现有些软件项目经常出现线上事故，出现了线上事故之后，第一时间会去修复这个问题，第二时间，则是问责。
这是一个很有意思的现象，通常在一些传统行业的团队或者政府背景的团队中，发生了线上事故，他们会启动问责程序，找到事故的负责人，并对他做出相应的处罚。
作为程序员，大家都知道，代码的世界不出错是不可能的。问责在很大程度上会导致团队成员不敢写代码，不敢上线，不敢触碰线上环境的一切东西，最终导致团队研发效率下降。
那正确的做法应该是什么呢？
这里就给大家介绍一下Blameless Postmortem，中文意思就是无过错验尸报告。
什么是无过错验尸报告？
无过错验尸报告是对线上事故的书面记录，用来描述:
- 这一线上事故的影响。
- 减轻或解决事故所采取的行动。
- 事故的根本原因。
- 为防止该事故再次发生而采取的后续行动。
无过错验尸报告这个名字是英文直译过来的，如果觉得这个名字过于血腥，可以叫它无过错反思报告，或者无过错事故报告，或者无过错事后分析报告。但更多的人都习惯亲切的叫它验尸报告。
之所以强调无过错，是因为这样的话人们就不会在写报告的时候由于害怕被问责，从而互相埋怨或者隐藏自己的过错。
为什么需要无过错验尸报告？
验尸报告的目标是了解所有导致事故的根本原因，记录事故的经过以供未来参考，并制定有效的预防措施以减少事故再次发生的可能性。
为了使验尸报告能够有效地减少重复事故，总结过程必须激励团队识别根本原因并修复它们。
同时，关注这个过程并确保它是有效的则需要组织中各级的承诺。比如不能出现对团队某个人的问责。
什么时候需要无过错尸检报告？
线上事故都会有严重程度或者影响程度分级，因此，通常我们只会对级别较高的事故写尸检报告。
我们通常会在下面两个时间点开始写尸检报告：
- 修复事故期间
- 修复事故之后
谁完成验尸报告？
事故产生的服务所属的交付团队共同负责完成验尸报告。
但需要选择一名owner来主要负责编写报告，并且这个owner需要保证下面两件事情的发生：
- 分配不同的人去完成各类的事故调研工作，最后把结果汇总给这个owner。
- 保证报告中的改进action按照紧急程度安排到后面相应的迭代中。
如何跟踪报告中的action？
这个问题其实是紧接上面的第二条。
报告中的action通常分为两类：
- 根本原因改进
- 非根本原因改进
对于报告中的每个action：
- 应该在对应的团队的backlog中建卡，并根据优先级安排进相应的迭代。
- Owner要负责跟踪卡的完成情况。并记录到报告中。
验尸报告会议
验尸报告相关的会议有两种。
- 一种是在编写报告前，用于讨论事故的根因。
- 一种是在报告完成后，用于向团队分享报告内容，学习成长。
不管是哪种会议，都要记住，这个会议不是批斗会，不能在会议中指责任何人。
这里的指导原则和retro类似。
实践过程中，我发现大部分团队只会开第一个会议，在编写报告的过程中，大家基本上都学习了，并了解了报告中的根因。所以大部分团队都不会开第二个会议。
但是不少公司会开另外一种会议，就是报告写完了之后给领导的汇报会议，此会议根据不同公司的政策不同，可有可无。
报告模版
下图就是一个完整的报告模版。
报告可以是表格的形式，也可以是文档的形式。有了模版，写报告的人就可以照着模版往里面填内容了。
关于如何识别根因，Atlassian提供了一种叫5 Whys的分析方法，具体怎么做可以参考这里：
https://www.atlassian.com/tea...
总结
验尸报告是为了在软件开发过程中以及项目交付过程中能持续改进，有记录能存档，并且成为知识沉淀的一部分。
所以它的形式可以根据团队的实际情况来。我见过有团队用表格来写的，像上面模版那样，也有直接写卡上的，也有直接开会画在白板上然后拍下来的。
对于无过错验尸报告，大家在实践过程中有任何疑问，欢迎来找我讨论。
参考资料
https://www.atlassian.com/inc...
https://www.atlassian.com/inc...
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。