事故报告撰写（参考《SRE Google 运维解密》）

图片摘自网络

事故报告撰写

一篇事故总结是一次事故的书面记录，包括该事故造成的影响，为缓解该事故采取的措施，事故的根本原因，以及防止未来问题重现的后续任务。

事故总结的条件

• 用户可见的宕机时间或者服务质量降级程度到达一定标准。
• 任何类型的数据丢失。
• on-call 工程师需要人工介入的事故（包括回滚，切换用户流量等）
• 问题解决耗时超过一定限制
• 监控问题（预示着问题是由人工发现的，而非报警系统）

事故报告对事不对人，是为了提出服务如何如何能够获得进步。避免职责，提供建设性意见。

协作和知识共享

事故报告使用公司的模板。

评审条件如下几项：

• 关键的灾难数据是否已经被收集并保存起来了？
• 本次事故的影响评估是否完整？
• 造成事故的根源问题是否足够深入？
• 文档中记录的任务优先级是否合理，能否及时解决了根源问题？
• 这次事故处理的过程是否共享给了所有相关部门？

所有的事故总结都需要评审。未经评审的事后总结还不如不写。事故报告写完要举行评审会议。会议上注意着重着重解决目前文档中的疑问和评论，收集相关的想法，将文档完成。

以上内容编抄自《SRE Google 运维解密》第十五章 事后总结：从失败中学习。省略了一些内容。喜欢的可买书看。

我们是怎么做的

书中附录D是总结示范（模板）。我们模板大致类似。分为如下几项：

1.参与开发人员
2.影响时间和范围
3.问题现象及处理步骤
4.根本原因的分析和定位
5.后续任务

也就是要明确责任人，记录事故发生及其处理恢复的时间。问题现象（运维监控图或者程序bug）及处理步骤的记录，回顾起来也能帮你优化你的处理方式。最重要的是原因的分析和定位。这个才是有参考价值的。让你成长也避免下次再犯。后续任务就是根据业务做些优化或者组内学习或者其他有促进的学习或改善的事情。