社区译者：王英伟-北京
审校：刘征
原作者： Google SRE
英文原档案本地下载：[下载](/doc/Google-Postmortem Checklist.docx)
第一部分
1-1 事故数据收集
- 1、概要描述受到的影响
- 2、影响范围澄清
- 2.1、受影响的用户
- 2.2、受影响的区域
- 2.3、受影响的客户
- 3、严重性分类澄清
- 4、事故完整的 MTTx 时间线跨度度量
1-2 根因分析
- 1、充分说明所有导致根本原因发生的细节
- 2、使用 5 why 或者其他根因技术工具确保进行深度的分析
- 3、确定事件触发因素
- 4、决定实践相关的根因类型
1-3 经验教训 & 设计行动计划
- 1、调研那些地方进展顺利，那些方面做得不好，那些方面属于运气好
- 2、利用经验教训确定下一步的行动事项
- 3、确保每条行动事项都在跟踪系统中都有一个跟踪单（如 Jira 中的 Bug 单）
- 4、确保涵盖两个关键的类型：缓解 和 预防
第二部分 – 行动事项检查单
- 1、行动项是否是都是可实现的，并获得了 PO 产品负责人的检查确认？
- 2、你是否考虑过改善 预防 和 解决时间 的方法？
- 3、你是否考虑过其它相似性的（或者相似事故）事故，以及相关的可参考行动计划？
- 4、你是否考虑过如何用自动化的方式阻止人为失误？
- 5、你的事后分析清单是否至少有一个关键级或者高优先级的行动项？如果没有，利益干系人是否可接受降低了之后的风险？
- 6、你是否与责任小组（负责人）就执行的行动项进行了交流？
第三部分 – 评审/审批/社交化
- 1、你的事后分析清单是否按照团队的正常通过了评审/审批？
- 2、是否删除/修改了任何指责性语言？
- 3、你和初始的利益干系人共享了事后分析清单吗？
- 4、你和团队共享了事后分析清单吗？
- 5、是否能从仪表盘和工具中获取到你的事后分析清单？
- 6、你的事后分析清单是不是无指责性的，并且专注于系统改进的？
词汇表
- 严重性分类：用于帮助分析事故的严重性类别
- 5-whys: https://en.wikipedia.org/wiki/5_Whys
- 触发：在时间段内事故影响产生的时间点
- 相似事故（同频事故）：性质相似，但可能不是完全重复的事故
- 概要描述：用于报告高阶的状况，比如那些浅显的产品介绍。「译者注：目标是任何人都可以看懂」
- MTTx：x的平均时间（X 可以是故障的（检测|升级|缓解|解决）的时间）
