故障总结｜从事故中学习

在日常事故中，发现很多开发人员写故障总结就是走个过场，不清不楚，还会漏掉一些实际问题。其实一份好的事故总结能够加强自身对错误的反思和解决，并且能够帮助团队内其他人避免类似错误重犯，降低犯错几率，从而保障服务稳定性。

一般一个好的故障总结都会有如下几个重要特点：

• 看得懂，即便是一个非专业人员也能看懂来龙去脉；

• 有数据，通过数据说清楚故障真实原因、造成损失；

• 免指责，不要指责个人，以团队的名义说清楚解决方案和后续避免措施。

分享一份我在工作过程中经常使用的事故总结模版，以加快事故总结效率。

事项	内容
概述	一个到两个简短的句子，总结促成因素、时间线摘要和影响。例如：在  8 月 13 日早上，由于主数据库机器上的进程故障，遭受了 1 分钟的请求访问超时。
影响‍‍	用数字说明影响范围。例如：0.01%  用户下单失败，预计造成损失 578w。
开始和结束时间	故障发生时间和终止时间，永远试图减少故障发生间隔
原因‍	故障导致的真实原因，例如：由于订单数据的缓存过期，所有请求打到数据库，进而导致数据库  CPU 升高，无法处理更多请求。
解决方案	包括对解决问题的方法的描述。如果有临时解决方案与长期解决方案一起描述。
	临时方案：已经临时扩容  10 倍容量以减轻级联故障。
	长期方案：问题解决方案、时间线和对应负责人。
时间线	事前、事中、事后的整个过程，要非常具体，并包括确切的数字。
	时间线	描述
	11:45	收到HTTP 500电话告警
	11:47	发现数据库CPU飙升
	…..	….监控数据走势图
	12:00	10倍扩容，问题得到暂时解决
专业术语	对于没有接触过该系统，但是故障中出现的专业术语描述
事后学习	此次事故中哪些事情处理的值得称赞；什么事件做的不好，需要重点改进....
撰写者	xxx
撰写时间	20220813

---

原创不易，随手关注或者”在看“，诚挚感谢！