事故已经发生，你决定写一份事后回顾报告。如果已经完成了事故分析，那么该怎么执笔？一个大概的事后回顾报告的模板如下：摘要、影响、时间表、根本原因、行动项目和附录。只要详细捕获事故，就可以在事后回顾报告中添加任何想要的内容。我通常会写几页，但根据服务中断的复杂程度，它可能在1到20页之间。我通常用一个模板来帮助我组织想法。与仅查看空白页面并讨论要写的内容相比，在分析之后（或期间）紧跟着模板输入相关信息是一个非常实用的做法。网上有许多其他模板，GitHub上也有一些模板库可供参考。
在文档的顶部，添加相关人员的姓名、事件发生日期，以及文档最后一次修改的时间。如果你将事后回顾报告存储在云端，则可以添加关键字或标记来帮助组织文档。
总 结
第一部分应该是执行摘要。这意味着无论谁打开这个文档，他们都应该对发生了什么、何时发生的，以及谁受到影响有一个大致的了解。它往往是简短的，给读者一个关于事故的“快照”。
一个例子如下。
2016年2月22日，有一个有问题的配置变更更新到了我们的边缘路由器。边缘路由器将请求分发给各种应用程序的后端。这导致网站20%的请求失败了30分钟。失败的请求都向客户返回了500响应。
这个例子涵盖了一些基础知识。它总结了出现了什么问题，是如何出现问题的，以及影响是什么。它没有指责什么，也不会太深究技术问题，而且也不是很长。如果摘要长于两段，那么它可能太详细了。
影 响
事后回顾报告并不一定要包括这一部分，但是它对确定客户的响应是什么，或者如果停机的话是否会对外部有影响是有帮助的。这一部分非常适合用来描述感到宕机的客户、关于宕机的任何公开新闻、关于如何影响服务的SLA的讨论，或者一两个图表；也可以包括关于恢复时间或按需响应速度的统计数据，如果这些是你的组织感兴趣的度量指标的话。
产品团队会发现此部分有助于衡量他们应该关注的程度，也有助于管理层确定行动项目的优先级。
错误率随时间变化的示例图
此图表显示，在30分钟内，边缘路由器的所有请求中的20%会返回500错误。我们没有看到这些外部故障，但在此次中断期间，客户提交了15个相关的生产环境支持案例。我们决定不发布公开的事后回顾报告，但对这15个案例做出了回应。
这个解释很简单，它可能包含更多细节，但重要的是，事后回顾报告的读者了解事故对失败的请求，失败的任务或任何技术失败之外的影响。如果可以访问客户支持团队，他们可以提供大量有关中断期间传入请求的信息。
也可以通过社交网络和新闻网站来搜索提及你的宕机的信息。或者，可以深入挖掘日志，并尝试估计有多少客户机知道了服务器宕机。这个估计不是完美的，但可以让你更好地了解这种影响。另一种衡量冲击的方法是查看外部状态页的访问量。如果有谷歌云状态页或GitHub状态页这样的状态页面，就可以根据用户访问量的增加推断出有多少用户对宕机事故感兴趣了。与更直接的度量或客户通知相比，它提供的信息更少，但是它可以帮助你了解有多少人关心系统的性能。
时 间
我喜欢这一部分，因为它给出了每一分钟都发生了什么。每一行都是时间戳和描述。在描述中，从代码更改的链接、事件的时间线，到部署的服务描述都提供了非常深入的细节。这对读者来说，当跟踪所发生的事情时会很有用，因为你可以单击并查看上下文或查看附录，从而了解对事件做出响应的人都看到了什么。对于时刻准备着应对意外的人，本节将向你展示你的队友会如何应对问题。作为一个管理者，你可以了解谁参与了事故的处理。作为另一个团队成员，你可以看到其他同事使用的方法，并且可以将它们与你遇到类似情况时可能做出的响应进行比较。我最喜欢的问题之一是“当你看到Y时，为什么要做X？”有时，这只是直觉，但通常它指向可以被修复或自动化的东西，或者至少可以为后来者撰写有用的文档。
一个关于时间线的例子。
- 所有时间都是EST时间
- 16-02-22
- 14:04 - -提交abc1234用于配置存储库，为即将上线的项目配置新的路由路径。
- 14:12 - -1%边缘路由器完成部署。错误开始出现，但没有触发警报。[服务中断开始]
- 14:42 - -20%的边缘路由器完成部署。
- 14:45 - -Nat由于请求失败数不断提升收到呼叫。
- 15:00 - -Nat发现他没有回滚路由配置的权限。页面路由解析器所有者是Sarah，希望她有权限。
- 15:15 - -Sarah开始回滚。
- 15:17 - -回滚完成。[服务中断结束]
这个时间线非常简短，但是它有几个优点。首先，它说明了事故是何时开始和结束的。它显示了谁对事故做出反应并执行了行动，因此如果需要的话，这些人可以提供更多细节方面的信息。事后回顾报告不会因为事故的最初原因而责怪人们。因此要注意的是，虽然你可以把人们的名字放在这里，但是你不应该责怪他们的决定。既然赋予了某人对事件做出反应的责任，你就必须相信他们的决定，并且支持他们，这样做只是为了将来他们也会为你做同样的事情。如果你在阅读时间线时确实忍不住要批评，那么我建议你用一种友好和暗示的语气来表达它。不要问“为什么不……”，或者说“如果我在打电话，我会……”，而要试着问“我们能让X更好地为打电话的人工作吗？”如果你的陈述或问题是指责性的或咄咄逼人的，那最好不要说了。有时候，如果看起来某人不知道某事，你可以在会议后顺便提一下。你可以说，“嘿，我注意到你调试时没有使用Y工具。你以前用过吗？如果没有的话，我很乐意找个时间向你演示一下，因为这很适合展示Z这样的东西。”
根本原因
根本原因可能是一个工程团队的事后回顾报告中最重要的部分。它描述了造成服务中断的原因。前面的部分描述了发生了什么，或者它们是如何发生的，但不是发生的原因。如果想预防未来的中断，那么就需要知道它们为什么会发生。我们的目的不是说中断是某个人的错，而是要找出系统如何失败、为什么失败，以及将来如何防止这种情况。根本原因是分析得出的主要结果。
一个关于根本原因的例子。
所做的配置更改触发了边缘路由代码中的未知错误。在路由代码中，假设在配置的路径中只允许使用ASCII字符。此假设未在验证代码中定义，因此当使用前缀/定义新路由时，路由解析器会引发异常。边缘路由器没有捕获此异常，而是开始逐步崩溃，因为它们在引导时读取配置，并且一旦使用非ASCII字符解析配置就会崩溃。
如果对于系统崩溃的原因有一个非常令人惊讶的发现，根本原因部分可能所占篇幅巨大，但更常见的情况是可以归结为一些小问题。你可以使用此部分来说明探寻根本原因的方式或你确保根本原因正确的原因。这通常是需要留个心眼的部分，所以要尽量简洁而全面。有时候，有些流程失败了，这些流程也可以在这里曝光。但是，要小心——你的目的不是对所发生的事情进行问责。“克里斯提交的软件变更搞砸了一切”这样的言语并不恰当，而应该这样说：“做了一个变更，引入了一个新的路由，导致解析器出现了异常。”通常，在向更广泛的受众发送之前，由一两个人对事后回顾报告进行复核是比较好的习惯，这样能确保所说的内容都恰如其分。
行动项
行动项是事故发生后要采取的行动清单，通常附有工单或跟踪项。工单的好处是它列明了问题解决所需的责任和优先顺序。行动项确保一群人努力防止类似的中断事故再次发生，并且让人们各司其职。也就是说，避免把所有的工作都集中在一个人身上。即无论问题是如何发生的，团队都应该一起工作，确保同样的事故不会再次发生。一个例子如下。
#1234 - - 添加不相容路由的测试。
#1235 - - 调高第一只金丝雀的灵敏度，以确保在有问题时及时发出警报。
#1236 - - 确保当前所有一线生产运维成员都具有回滚路由配置的能力。
#1237 - - 添加对新来的一线生产运维成员回滚权限的检查。
此示例显示了为此特定事故创建的新行动项。通常，这里还会包含可能有助于防止或恢复此事故的解决办法的链接。将这些链接放在这里也有助于确保利益相关者和你的队友可以看到它们。
在尝试规划和选择行动项时，请专注于那些防止中断在此发生的选项，这在解决当前问题的同时，还有助于提升对问题的响应度，缩短恢复系统所用的时间。通常，添加工单以自动响应此类事故是一个很好的步骤；改进工具以便更容易地调试类似的问题也非常有用。不要添加类似“向仪表板添加另一个图表”之类的工单，而是要研究改进工具，让你不论是从宏观上还是微观上都能把控。这方面的一个示例可能是这样一个系统，它允许你单独执行与其他大多数系统截然不同的查询，让你可以非常快捷、方便地得到想要的信息。
请注意，如果在工单系统中忽略了行动项，则行动项将毫无意义。如果你认为任何人都不会重视行动项并去实现它，那么将它们放在事后回顾报告中是毫无意义的。有些团队喜欢创建工单，然后不断地给相同的Bug写不同的事后回顾报告。类似这种有多达40个行动项的事后回顾报告，没有人会感兴趣，所以是无用的。之所以说没有人去实现的行动项是无用的，还因为它们暗示了SRE工程师（或任何正在推动事后回顾报告的人）在公司里的重要程度不高。SRE工程师的一项工作是提高整个组织的可靠性，因此需要时刻保持警惕，并与负责安排工作的人员合作，以确保行动项完成。
没有行动项的事后回顾报告
在编写事后回顾报告时，你可能会遇到一个典型问题——没有立即的行动项。这通常发生在当所使用的一个依赖服务发生服务中断，而你在一个较小的公司里时。如前所述，Amazon S3在2017年2月28日发生了大规模的服务中断，许多公司都受到了影响。S3是一个BLOB（Binary LargeObject，二进制大对象）存储系统，许多公司在上面存储了很多东西，如图像和随机文件。当S3发生故障时，很多公司也不能做什么来使它恢复。如果你的企业还年轻，并且不知道业务或存储的数据在6个月内是否还有用，那么如果尝试自建一个不依赖于第三方系统的解决方案可能会很危险。你会希望花更多的时间专注于业务逻辑，而不是来回地重建。这对于企业来说是一个艰难的决定，但是你和你的团队可以共同衡量决定：与花时间来解决类似的服务中断相比，自建一个解决方案是不是划算。
在这些情况下，人们通常希望在行动项里面展示成本评估，也就是行动与不行动、将得到或失去什么。这是服务依赖方第一次宕机吗？迁移到另一个依赖方要花多少钱？是否应该找一个备份依赖方，以便如果主依赖方再次失败，还有其他选择？对于大型依赖方故障，提供灾备系统是首选的解决方案，但这可能很昂贵。它也常常需要花费很多时间或金钱来实施，而这两者往往是最大的问题。
一旦确认了可以继续向前的方向，就根据这些事实做出决定吧。事后回顾报告可能对资深的技术领导更有用，因为你要解释修复依赖方问题的成本。例如，要对存储的所有数据支付两次费用吗？这是一次性的改动吗？我们不能仅仅祈祷它不再发生，但是可以评估再次发生的成本与处理它的成本。如果系统中断两个小时，但每个月都能省下不少钱，这样就能使公司继续经营几个月，也许值得试试看。但另一方面，也许中断会在最大的活动期间发生，这对公司来说是很大的损失。
有人说，没有行动项，事后回顾报告就没有存在的意义。在一个资金雄厚的组织中，我是认同这个观点的。如果你有很多资源，行动项很重要。另一方面，如果你在一个3人团队中，那么现在只需要留下一些注释，说明一下当资源更充足时能做的事就可以了。当你的团队和业务发展壮大时，重新考虑其中的一些决策是一个好主意，但是在真正付诸行动前，永远不要忘记实事求是。
