如果从线上故障的次数和影响范围来看 2022 年，于我来说无疑是痛苦的一年。这一年有新业务刚交接过来第二天就发生大规模海外玩家登录不可用，也有犹如刺刀一般的支付系统故障。当救火队长的这一年，写了好几份故障报告，这里总结一下团队里写故障报告的思路。
软件工程的历史上无数案例告诉我们随着系统的发展，发生线上事故总是难以避免的。因此事前通过代码评审(我们是如何做代码评审的)、自动化测试来降低线上事故发生的概率。当然事故发生时我们需要以最快的速度将服务恢复到正常状态。而事后更重要的是我们从失败中学习到了什么，事故报告则是进行事故复盘的重要手段。
我们团队目前在事后总结的文化和实践上遵循的是Google SRE 的 postmortem-culture，即每一次故障都应该写一份事故故障报告，相信很多公司或者团队都多多少少会借鉴类似的实践。
为了工作更有效率，我们不可能为每一个 bug 都写一个事故报告，以下我们团队在采用的一些标准：
故障发生的时间段、影响范围。比如我们负责的团队是公司有所业务的基础登录和支付服务，则登录失败、下单失败、支付到账失败的发生次数以用户数、金额数则是我们最为关心的。
不同的事故等级可能对应的不同的事故处理流程，重大故障要全公司范围内通报，涉及到外部开发者还需要撰写外部故障报告邮件通知开发者等等。比如之前维护 LeanCloud 的即时通讯出现影响用户的故障，我们一般都会给相关用户发送故障报告。
分析造成此次事故发生的直接原因。如果是由代码造成的，应该贴上代码链接或者截图并逐行分析代码；如果是发布造成需要附上发布链接等等。虽然实践上总会遇到一时无法知道原因的 bug，但是原则不接受没有 root cause 的故障报告。
描述了如何处理使事故恢复的，比如做了代码发布、回滚、重启等等。
按照时间顺序发生的事件写清楚故障处理过程，这也为我们复盘故障处理是否得当提供了基础。
回归故障处理时间线上，我们有哪些做的不够好的，以及哪些做得比较好。比如是否及时响应、是否告警是否及时、trouble shooting 能力是否有缺失、是否及时告知上下游和业务方等等。
请记住写故障报告最重要的是：确保实施有效的措施使得未来重现的几率和影响得到降低。
比如：
改进措施可能会有短期或者长期的，所有改进措施并指定到负责人，而且必须要有 deadline。确保改进措施得到实施！我们一般会在 Jira 上创建对应的 Task, 然后在故障报告中贴入链接。
故障报告一般由故障排查的主要人员进行发起，原则上我们希望当天就开始写故障报告，不一定需要当天完成，但是应该在第二天或者第三天把故障报告完成。如果是重要故障需要更多的时间进行仔细调查则可以适当延后。
报告可以多人一起编辑，大家一起提供原因分析，现场数据等等。我们团队的故障报告都会放在 Confluence 上一个公开的目录下面。
除了事故发生时及时通知上下游和业务方之外，事故报告的撰写也没必要忌讳让相关方参与进来。事故故障报告的编辑是公开的。所有人都可以评论，任何人都可以编辑。
在故障报告写完之后，需要进行团队内部或者故障小组的 review 以保证信息一致和规范性。报告在进行团队内部 review 之后及时同步给外部，比如我们会在 Slack 公开频道把故障报告同步给上下游和业务团队。
每个月的工程师月度计划会议上，将所有故障报告简单同步一遍，以确保工程师团队内所有人都知晓。
团队文化的建立需要团队管理层的努力，因此团队管理者应该在这方面多督促。首先建立对事不对人非常重要，如果因为某些错误的举动就公开指责或者羞辱某人或团队，那么人们就自然地逃避事后总结。对于积极响应故障的工程师给予激励，对于频繁故障的同事应该考虑帮助或者汰换，对于消极响应故障的同事应该给予提醒。
在阿里的三年里发现阿里对稳定性的重视程度总得来是比较高的，但是在对稳定性的预防性措施投入缺非常少。故障发生了力求第一时间恢复，但是事后的扯皮都非常多，对于改进措施则非常不重视，对于事情预防则更加不愿意投入时间和精力。
无法想象去年阿里云香港机房故障了那么长时间连 Status 页面都没有任何变化… 而 LeanCloud 在这方面反而做得更好一些。
作为 Team Leader 我自己会通过故障的处理和复盘过程看看团队里是否有优秀的工程师，优秀的工程师在处理故障的时候， TA 对整个系统有比较全局的认识，同时又能够从细微处入手。但如果是一个不熟悉系统的工程师， TA 会慌张，因为 TA 不知道哪里出现了问题。当你从故障处理的过程中看到优秀的工程师时需要去给 TA 相应的一些鼓励与肯定。