前言
在征询的经验中，发现有些软件我的项目经常出现线上事变，呈现了线上事变之后，第一工夫会去修复这个问题，第二工夫，则是问责。
这是一个很有意思的景象，通常在一些传统行业的团队或者政府背景的团队中，产生了线上事变，他们会启动问责程序，找到事变的负责人，并对他做出相应的处罚。
作为程序员，大家都晓得，代码的世界不出错是不可能的。问责在很大水平上会导致团队成员不敢写代码，不敢上线，不敢触碰线上环境的所有货色，最终导致团队研发效率降落。
那正确的做法应该是什么呢？
这里就给大家介绍一下 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…