经验表明，真正对事不对人的事后总结文化可以带来更可靠的系统——这也是我们认为这种做法对于创建和维护一个成功的SRE组织十分重要的原因。
将事后总结引入组织既是一种文化变革，也是一种技术变革。这样的转变似乎是令人生畏的，本章的关键点是，做出这种改变是可能的，不是一个难以克服的挑战。不要指望你的系统能够自行解决问题。你可以从引入一个非常基础的事后调查程序开始，反映和调整你的流程来适应你的组织——跟很多事情一样，没有放之四海而皆准的方法。
如果总结的很好，可以采取行动并广泛分享，事后总结可以成为积极推动组织变革和防止重复故障的利器。为了可以说明优秀的事后总结的写作原则，本章介绍了一个曾经发生在Google的故障案例进行研究。一个糟糕的事后总结的案例可以突显出为什么“糟糕”的事后总结对于努力创建健康的事后分析文化的组织是有害的。将糟糕的事后总结与实际事后总结进行比较后，可以突出高质量事后总结的原则和最佳实践。
本章的第二部分分享了我们在实现强大的事后总结文化激励机制以及识别（和补救）文化破裂的预兆方面所学到的知识。
最后，我们提供了用于引导事后总结文化的工具和模板。
有关对事不对人的事后总结哲学的全部讨论，请参阅我们的第一本书“站点可靠性工程”中的第15章。
案例分析
本案例研究的是例行机架退役导致用户服务延迟增加的case。我们的自动化维护系统的一个bug，加上限速不足，导致数千台承载生产流量的服务器同时宕机。
虽然Google的大多数服务器都位于我们的专有数据中心，但我们在托管设施（或“colos”）中也有机架代理/缓存机器。colos中包含我们代理机器的机架被称为卫星，由于卫星经常进行例行维护和升级，所以在任何时间点都会安装或退役许多卫星机架。在Google，这些维护流程基本是自动化的。
退役过程使用我们称为diskerase流程覆盖机架中所有驱动器的全部内容。一旦机器进入diskerase，它曾存储的数据将不再可检索。典型的机架退役步骤如下：
获取
卫星上所有活跃的机器
machines = GetMachines(satellite)
将所有通过“filter”匹配到的候选机器发送decom
SendToDecom(candidates = GetAllSatelliteMachines(), filter=machines)
我们的案例研究始于一个标记为退役的卫星机架。退役过程的diskerase步骤已成功完成，但负责剩余机器退役的自动化失败了。为了调试失败，我们重新尝试了停用过程。第二次退役如下：
获取卫星上所有活跃的机器
machines = GetMachines(satellite)
因为decom流已经在运行了，因此”machines”是一个空的列表
API bug：anmpty list被视为“无过滤，即为在全部机器上运行”，而不是“不在任何机器上运行”
将所有通过“filter”匹配到的候选机器发送到decom
SendToDecom(candidates=GetAllSatelliteMachines(), filter=machines)
将所有候选机器发送到diskerase。
几分钟内，全球所有卫星机架的磁盘数据都被删除。这些机器处于不可用状态，无法接受用户的连接，因此后续用户的连接直接路由到我们的数据中心。结果导致用户延迟增加。得益于良好的容量规划，很少有用户注意到这两天我们在受影响的colo机架中重新安装机器。事件发生后，我们花了几周的时间进行审核，并为自动化添加了更多的健全性检查，使我们的退役工作流程具有幂等性（其任意多次执行所产生的影响均与一次执行的影响相同）。
故障发生的三年后，我们遇到了类似的事件：由于许多卫星被耗尽导致用户延迟增加。根据原始事后总结，本次事件后实施的行动大大减小了二次事故的影响范围和速度。
假设你是负责为此案例研究撰写事后总结总结的人。你想了解什么，以及你会采取什么行动来防止此类故障再次发生？
让我们从这个事件的一个糟糕的事后总结示例开始。
糟糕的事后总结示例：
事后总结：所有卫星机器进入diskerase流程 2014-8-11:
负责人：maxone@，logantwo@， sydneythree@，dylanfour@
与以下人员共享：satellite-infra-team@
状态：不可更改
事件日期：2014年8月11日
发布时间：2014年12月30日执行摘要
影响：所有卫星机器都被发送到diskerase，实际导致Google Edge不可用。
根本原因：dylanfour@忽略了自动化设置并手动运行了集群启动逻辑，从而触发了现有bug。故障摘要
故障持续时间：40分钟
受影响的产品：satellite-infra-team
受影响的产品百分比：所有卫星集群。
用户影响：进入卫星的所有查询都是由Core提供的，导致延迟增加。
收入影响：由于查询异常，部分广告未投放。目前确切的收入影响未知。
监控：监控报警。
解决方案：将流量转移到核心，然后手动修复边缘集群。背景（可选）
影响
- 用户影响：
进入卫星的所有查询都是由Core提供的，导致延迟增加。- 收入影响：
由于查询异常，部分广告未投放。根本原因和触发点
集群开启和关闭的自动化并不意味着是幂等的，该工具有安全措施确保某些步骤不能多次运行。但无法阻止某个人手动多次运行代码，也没有文件提及这个问题。因此，大多数团队成员认为工具失效时，可以多次运行该过程。正好在机架的常规退役期间发生这种情况。机架正在被一个新的基于lota的卫星取代。dylanfour@忽略了已经执行了一次启动并在第一次执行时出现问题。由于粗心以及无知，他们引发了一个错误的交互，即将所有卫星机器分配给了弃用团队。
为恢复生产投入的努力
经验教训
- 事情进展顺利：
- 报警及时发现问题。
- 事故处理进展顺利。
- 事情进展受挫：
- 团队（特别是maxone@，logantwo@）从未编写任何文档告知SRE不要多次运行自动化。
- on-call处理的不够及时，没有阻止大多数卫星机器被删除。这已经不是第一次出现处理故障不及时的情况了。
- 幸运的
- Core能够为原本进入边缘集群的所有流量提供服务。简直无法相信我们这次能幸免于难！
行动列表
行动列表 类型 优先级 负责人 bug跟踪 完善自动化工具。 缓解 P2 logantwo@ 报警改善 检测 P2 sydneythree@ 需要学习正确的跨站点轮值文档，避免发生重复的问题 缓解 P2 BUG6789 训练大家不要运行不安全的命令 避免 P2 名词解释
为什么这份总结十分糟糕？
示例包含一些我们试图避免的常见故障模式。以下说明如何改进这份事后总结。
缺少上下文
从一开始，作为示例的事后总结引入了特定于流量服务的术语（例如，卫星）和Google机器管理自动化的较低层（例如，“diskerase”）。如果你需要提供其他上下文作为总结的一部分，请在背景或名词解释部分进行添加（可以链接到更长的文档）。上述总结在这两部分都是空白的。
如果在编写事后总结时没有将内容置于正确的上下文中，文档可能会被误解或被忽略。谨记，你的受众并不只仅仅是有着直接关系的团队。
省略了关键细节
多个部分包含摘要但缺少重要细节。例如：
问题总结
针对多个服务的中断，应该提供数字来表示影响范围。示例中唯一的数据是故障的持续时间。没有足够的细节来评估故障的规模或影响。即使没有一个具体值，一个估计的值也比没有数据好。毕竟，你如果不知道如何衡量它，那么你也不知道它是否被修复了！
根本原因和触发点
确定根本原因和触发点是编写事后总结的重要原因之一。示例包含一个描述根本原因和触发点的小段落，但没有探索故障的底层细节。
为恢复生产投入的努力
对读者来说，事后总结是事件记录。一份好的事后总结能让读者知道发生了什么，该如何减轻问题，以及用户受到了什么影响。很多问题的答案通常在投入恢复的努力中可以找到，但示例中，这部分是空的。
如果故障值得写入事后总结中，那么你还应该花时间准确获取并记录必要的详细信息。读者可以全面了解停机情况，更重要的是可以了解新事物。
缺失了关键行动列表
示例的“行动列表”（AIs）部分缺少防止此类故障再次发生的可执行的行动计划。例如：
- 行动列表主要是缓解措施。为了最大程度的降低重复发生中断的几率，还应该包括一些预防性和修复性的操作。一个“预防性的”行动列表说明我们“让人不会轻易出错”。一般来说，试图改变人类行为比改变自动化系统和流程更不靠谱。（正如Dan.Milstein曾打趣道：“让我们为未来做好计划，因为未来的我们跟今天一样愚蠢。”）
- 所有操作项都标记了相同的优先级。没法确认首先要执行的行动。
- 列表前两个操作项用词模糊不清，如“改善”和“完善”。用词不当会很难衡量和理解成功的标准。
- 只有一个操作项标明跟踪bug。如果没有正式的跟踪过程，事后总结的行动列表往往会被遗忘，导致故障再次发生。
用Google全天候运维副总裁Ben TreynorSloss的话来说：“对我们的用户而言，没有后续行动的事后总结和没有事后总结并无差别。因此，所有影响到用户的事后总结都必须至少有一个与它们相关的P[01]错误。例外情况由我亲自审查，但几乎没有例外。”
适得其反的指责
每一次事后总结都可能会陷入相互指责中。来看一些例子：
事情变得糟糕
整个团队都被指责要对故障负责，尤其是这两名成员（maxone@和logantwo@）。
行动列表
列表的最后一项指向了sydneythree@，负责跨站点轮岗。
根本原因和触发点
dylanfour@为本次故障全权负责。
在事后总结中强调个体似乎是个好主意，但实际上，这种做法会导致团队成员不愿承担风险，因为害怕被当众羞辱。他们可能会掩盖那些防止再次发生故障的事实。
Animated语言
事后总结基于事实，不应该受个人判断和主观语言的影响，应该考虑多种观点并尊重他人。示例中包含了多个反面例子：
根本原因和触发点
多余的语言（例如，“粗心无知”）
事情变得糟糕
Animated文字（例如，“这太荒谬了”）
幸运的
一种夸张的感叹（例如，“无法相信我们能够幸免于难！”）
动画语言和对事件的戏剧性描述稀释了关键信息，降低了警惕性。应该提供可验证的数据来证明事件的严重性。
缺少负责人
宣布官方所有权会产生问责制，从而促进采取行动。示例中有几个缺少所有权的例子：
- 总结列出了四个负责人。理想情况下，负责人是单点联系人，负责事后总结，后续以及完善工作。
- “行动列表”部分很少甚至没有提及各条目的负责人。没有明确负责人的行动项目不大可能会被解决。 最好的是拥有一个负责人和多个协作者。
受众有限
示例事后总结仅在团队成员之间共享。默认情况下，公司的每个人都应该可以访问该文档。建议尽可能广泛的分享你的事后总结，甚至和客户分享。总结的价值和所创造的经验成正比。能够从过去事件中吸取教训的人越多，重复发生的可能性就越低。周密和诚实的事后总结也是恢复信任的关键。
随着体验和舒适度的提高，可以将“受众”扩展到非人类。成熟的事后总结文化通常会添加机器可读标签（和其他元数据）以启用下游分析。
延迟发布
示例是在事件发生四个月后公布的。在此期间，如果事故再次发生（实际上确实发生过），团队成员可能会忘记总结中提到的关键细节。
优秀的事后总结示例
这是一份真实的事后总结。个人和团队的名字均为虚构，为了保护敏感容量信息，我们使用了占位符替换实际值。在你为内部分享的事后总结中，应该包含具体的数字。
事后总结：所有发送到diskerase的卫星机器 2014-8-11:
负责人：
- 事后总结：maxone@，logantwo@，
- 数据中心自动化：sydneythree@，
- 网络：dylanfour@
- 服务器管理：finfive@
与以下人员共享：all_engineering_employees@google.com@
状态：不可更改
事件日期：2014年8月11日, 星期一，PST8PDT 17:10至17:50
发布时间：2014年8月15日, 星期五执行摘要
影响：前端查询丢失。
部分广告未投放
近两天由卫星提供的服务延迟增加
根本原因：自动调节系统中的某个错误导致所有机架的卫星服务器被发送磁盘diskerase指令。导致所有卫星机器进入退役工作流程，磁盘数据被擦除。致使全球卫星前端中断。。故障摘要
故障持续时间：故障：周一，8月11日，PST8PDT 17:10至17:50。 周三，8月13日，07:46进行重建工作，之后故障解除。
受影响的产品：前端基础设施，尤其是卫星所在地。
受影响的产品百分比：全球——所有由卫星提供服务的流量（占全球查询的60%）。
用户影响：[ ]前端查询在40分钟内有所下降（[ ]QPS在此期间处于平均值，占全球流量的百分比[ ]）。所有由卫星提供的服务延迟增加。
收入影响：目前未知确切的收入影响。
监控：黑盒报警：对于每个卫星，流量团队收到“卫星a12bcd34有过多失败的HTTP请求”报警。
解决方案：通过将所有Google的前端流量转移到核心集群，以用户请求的额外延迟为代价，迅速缓解故障。背景（可选）
影响
- 用户影响：
- [_]个前端查询在40分钟的时间段内丢失，QPS在此期间持平，占全球流量的[ ]%。我们的监控表明这是个大故障；然而数据并不可靠，监控将自身停止监控的但仍在服务的卫星视为请求被拒绝。附录描述了如何估算上述数字。。
- 最近两天所有由卫星提供的服务延迟增加。
- –核心集群附近的RTT峰值[ ]ms
- –对于更依赖卫星的地点（例如澳大利亚，新西兰，印度），延迟+[ ]ms
- 收入影响：
- 由于请求丢失，部分广告未投放。目前尚不清楚确切的收入影响
- 显示和视频：由于日常波动，数据的误差较大，但我们估计故障当天有[ ]%到[ ]%的收入损失。
- 搜索：在17:00到18:00之间，在使用同样的误差时，有[ ]%到[ ]%的损失。
- 团队影响：
- 流量团队花了大约48小时全力投入重建卫星。
- 因为需要对过载的对等链路进行流量工程设计，NST的故障/报警负载高于正常值。
- 由于GFE的缓存命中率降低，某些服务可能会在前端提供更多响应。
- —例如，请参阅线程[链接]关于[缓存依赖服务]。
- —[缓存相关服务]在恢复之前，GFE的缓存命中率从[ ]%下降到[ ]%。
故障文件
[我们的事后总结文档的链接。]根本原因和触发点
流量管理服务器中一个长期存在的输入验证bug，由于手动重新执行a12bcd34卫星的工作流程而被触发的。该bug删除了执行退役操作的机器的约束，发送并停用了所有卫星机器。 因此，数据中心自动化执行了退役工作流程，擦除了大多数卫星机器的硬盘驱动器，在此之前无法停止这项操作。 Traffic Admin服务器提供ReleaseSatelliteMachines RPC。此处理程序使用三个MDB API调用卫星停用：
- 查找与边缘节点关联的机架名称（例如，a12bcd34 ->）。
- 查找与机架关联的机器名称（->等）。
- 将这些计算机重新分配给diskerase，间接触发退役工作流程。
由于MDB API的行为以及安全检查不是幂等的。如果卫星节点先前已成功发送到decom，则上面步骤2返回一个空列表，步骤3中将其解释为机器主机名上没有约束。 这种危险行为已存在一段时间，但被调用不安全操作的工作流程隐藏：调用RPC的工作流程步骤标记为“运行一次”，意味着工作流引擎一旦成功就不会重新执行RPC。 但是，“运行一次”的语义不适用于工作流的多个实例。当集群启停团队手动启动a12bcd34的另一个工作流时，会触发admin_server bug。
为恢复生产投入的努力
[我们的时间线日志的链接已被省略。在真正的事后总结中，这些信息始终包含在内。]经验教训
- 事情进展顺利：
- 疏散边缘。核心中的GFE明确的进行容量规划能允许这种情况发生，生产主干也是如此（除了对等链路之外；请参阅下一节中的故障列表）。这种边缘疏散使得流量团队能迅速减缓故障。
- 自动减轻卫星故障。覆盖的线路自动将来自故障卫星的流量拉回到核心集群，并且当检测到异常抖动时会自行排出。
- 尽管可能会造成混乱，但卫星decom/diskerase工作十分高效和迅速。
- 故障通过OMG触发了快速的IMAG响应，并且该工具适用于持续的事件跟踪。跨团队的反应非常棒，OMG帮助大家保持交流。
- 事情进展受挫：
- 故障
- Traffic Admin服务器没有对其发送到MDB的命令进行适当的健全性检查。所有命令都应该是幂等的，或者至少在重复调用时是自动防故障的。
- MDB不拒绝缺少主机名约束的所有权更改请求。
- decom工作流程不与其他数据源（例如，计划的机架decom）交叉检查decom请求。因此，对已清除（地理上不同）的机器的请求没有异议。
- decom工作流不受速率限制。一旦机器进入decom，磁盘擦除和其他decom步骤以最大速度进行。
- 当卫星停止服务时，由于出口流量转移到不同位置，Google和各国之间的一些对等链路过载，而请求是从核心集群提供服务。导致了在卫星恢复且匹配NST缓解工作之前，选择对等链路的阻塞短暂爆发。
- 恢复
- 重新安装卫星机器的速度很慢且不可靠。在高延迟链路末端传输到卫星时，重新安装使用TFTP传输数据效果不佳。
- Autoreplacer基础架构无法在故障时设置GFE的[ ]。需要多个SRE并行手动执行设置来匹配自动化设置的速度。以下因素导致自动化的缓慢：
- —SSH超时阻止了Autoreplacer在远程卫星上的操作。
- —无论机器是否已具有正确的版本，都执行了慢速内核升级过程。
- —Autoreplacer中的并发回归阻止了每个工作机器运行两个以上的机器设置任务。
- 当23%的目标被移除时，没有触发监控配置的安全检查参数（25%变化），当读取相同内容（剩余的29%）时触发了。导致重新启用卫星监控延迟30分钟。
- “安装人员”有限，因此，变更过程困难又缓慢。
- 使用超级用户权限将机器从diskerase拉回来时留下了很多僵尸进程，导致后续清理困难。
- 幸运的
- 核心集群的GFE与卫星GFE的管理方式不同。他们没有受到decom的影响。
- 同样，YouTube的CDN作为独立的基础设施运行，因此没有受到影响。否则故障将更加严重和持久。
行动列表
由于此事件的广泛性，我们将行动列表分为五个主题：
- 预防/风险教训
- 紧急响应
- 监控/报警
- 卫星/边缘
- 清理/其他
表10-1.预防/风险教训
行动列表 类型 优先级 负责人 bug跟踪 审核所有能够将实时服务器转换为宕机状态的系统（即，不仅仅是维修和diskerase工作流） 调查 P1 sydneythree@ BUG1234 提交bug，跟踪BUG1234识别出的所有系统的拒绝错误输入实施的情况。 预防 P1 sydneythree@ BUG1235 禁止任何单个会影响跨命名空间/类边界的服务器操作。 减缓 P1 maxone@ BUG1236 流量管理服务器需要进行安全检查才能在超过[ ]节点数的情况下运行。 减缓 P1 dylanfour@ BUG1237 流量管理服务器应该依据<安全检查服务>批准破坏性工作。 预防 P0 logantwo@ BUG1238 MDB应拒绝对非预期的当前约束提供值的操作。 预防 P0 louseven@ BUG1239 表10-2.紧急响应
行动列表 类型 优先级 负责人 bug跟踪 确保由核心提供的服务不会使出口网络链路过载。 修复 P2 rileyslx@ BUG1240 确保在[我们的紧急停止文档]和[我们的升级联系页面]下注明了decom工作流问题。 减缓 P2 logantwo@ BUG1241 为decom工作流添加一个大红色禁用按钮a 减缓 P0 maxone@ BUG1242 a : 由于灾难性环境中避免进一步损坏的关闭开关（例如，紧急电源关闭按钮）的常见术语。 表10-3.监控/报警
行动列表 类型 优先级 负责人 bug跟踪 监控目标的安全检查，不允许发布无法回滚的变更。 减缓 P2 dylanfour@ BUG1243 当超过[ ]%的机器退役需要添加报警。16:38机器从卫星上取下，17:10开始世界范围的报警。 监测 P1 rileyslx@ BUG1244 表10-4.卫星/边缘
行动列表 类型 优先级 负责人 bug跟踪 利用IPXE配合HTTPS可以使重新安装更快更可靠。 减缓 P2 dylanfour@ BUG1245 表10-5.清理/其他
行动列表 类型 优先级 负责人 bug跟踪 在我们的工具中查看与MDB相关的代码，并将管理服务器备份放至unwedge调节中。 修复 P2 rileyslx@ BUG1246 安排DiRT测试：在diskerase后带回卫星；对YouTube CDN执行相同操作。 减缓 P2 louseven@ BUG1247 名词解释
管理服务器
RPC服务器，支持自动化为前端服务基础结构执行特权操作。自动化服务器常参与PCR和集群启停操作。
Autoreplacer
将非Borgified服务器从一台机器移动到另一台机器的系统。在机器故障时保持服务运行，并且支持colo重新配置。
Borg集群管理系统，旨在管理大规模任务和机器资源。Borg拥有Borg单元中所有机器，并将任务分配给具有可用资源的机器。
Decom
退役的缩写。设备的decom是一个与许多运维团队相关的过程。
Diskerase
在生产硬盘驱动器离开Google数据中心前安全擦除生产硬盘的过程（以及相关的硬件/软件系统）。diskerase是decom工作流的一个步骤。
GFE（Google前端）
外部连接(几乎)所有谷歌服务的服务器。
*IMAG（Google事件管理）
一个程序，一种标准，以一致的方式来处理从系统中断到自然灾害的所有类型的事件——并组织有效的响应。
MDB（机器数据库）
事件管理仪表盘/工具，用于跟踪和管理Google所有正在进行的事件的中心位置。
卫星
小巧便宜的机器机架，仅提供提供来自Google网络边缘的非视频、前端流量。几乎没有传统的生产集群基础设施可用于卫星。卫星不同于CDN，它提供来自Google边缘网络的YouTube视频内容，以及来自互联网中更广泛的其他地方的视频内容。YouTube CDN未受此事件的影响。附录
为什么释放卫星机器不是幂等的？
[该问题的回复已被删除]
管理服务器将所有卫星分配给diskerase团队后发生了什么？
[该问题的回复已被删除]
故障期间真正的QPS损失是多少？
[该问题的回复已被删除]
IRC日志
[IRC日志已被删除]图表
更快的延迟统计——卫星曾为我们做过什么？
从这次故障经验得到，卫星会在核心集群附近的许多位置产生[ ]ms延迟，离主干更远的位置甚至会达到[ ]ms：
[图表的解释已被删除]
核心与边缘服务负载
为重建服务所付出的努力是个很好的例证。边缘服务恢复50%的流量需要大约36小时，恢复到正常的流量水平需要额外的12小时（见图10-1和图10-2）。
来自流量转换的对等压力[图表省略]
该图显示了由网络区域聚合的数据包丢失情况。在活动期间有一些短的尖峰，但大部分损失发生在卫星覆盖少的各个地区的高峰时刻。
人与机器，GFE
[省略了人机与自动机器设置速率的图表说明。]
图10-1.故障期间核心与边缘QPS分布
图10-2.故障期间核心与边缘QPS分布（替代表示） 为什么这份事后总结示例更好？
这个事后总结符合了好几条写作要求。
明晰
事后总结组织的很好，详细解释了关键术语。例如：
名词解释
一个精心编写的名词解释让事后总结更容易被大众接受和理解。
行动列表
这是一个涉及许多小的行动列表的大事件。按照主题对操作项进行分组可以更加轻松的分配负责人和优先级。
量化指标
事后总结提供了相关事件的有用数据，例如缓存命中率、流量级别和影响持续时间。数据的相关部分将显示原始来源的链接。这种数据透明性消除了歧义并为读者提供了上下文参考。
具体行动列表
没有行动列表的事后总结是无效的。这些行动列表有一些显著特点：
负责人
所以操作项都有负责人和bug跟踪号。
优先级
为所有操作项分配优先级。
可测性
操作项具有可验证的最终状态（例如，“当我们的机器中超过X%的机器退役时添加报警”）。
预防措施
每个操作项“主题”都有预防/缓解操作项，这些操作项有助于避免故障重复发生（例如，“禁止任何单个会影响跨命名空间/类边界的服务器操作。”）
不指责
作者关注的是系统设计中的差距，正是这些差距导致了非预期的故障，例如：
事情进展受挫
没有任何人或团队因此事件受到指责。
根本原因和触发点
关注“什么”出了问题，而不是“谁”造成了这一问题。
行动列表
旨在改善系统而不是改善人。
深度
事后调查不仅仅是调查系统故障的近似区域，也研究了多个团队的影响和系统缺陷。尤其：
影响
本节包含来自不同视角的大量细节，尽可能的做到平衡，客观。
根本原因和触发点
本节对事件进行深入研究，找到根本原因和触发点。
由数据推及结论
提出的所有结论均基于事实和数据。用于得出结论的数据都和文档相关联。
其他资源
以图表的形式进一步呈现有用的信息。向不熟悉系统的读者解释图表帮助其理解上下文。
及时
事件结束后不到一星期就写完并传播了事后总结。快速的事后总结往往更加准确，因为此时任何参与者心理都记着这件事。而受故障影响的人正在等待一个解释，证明你们已经控制了故障。等待的时间越长，他们就越能散发想象，那样对你十分不利。
简明
该事件是全球范围的事件，影响多个系统。事后总结记录了且随后分析了大量数据。冗长的数据源（例如聊天记录和系统日志）被抽象化，未经编辑的版本可从主文档中链接到。总体而言，这份总结在冗长和可读性之间取得了平衡。
组织激励
理想情况下，高级领导应该支持和鼓励有效的事后总结。本节描述了一个组织如何激励健康的事后总结文化。我们着重描述了总结文化失败的征兆，并给出了一些解决方案。同时还提供了工具和模板来简化和自动化事后处理流程。
模型以及对事不对人
为了正确的支持事后总结文化，领导者应始终如一的坚持对事不对人的原则，并在事后讨论中鼓励对事不对人。可以使用一些具体策略来强制组织执行对事不对人这一准则。
使用对事不对人的语言
指责性的语言会影响团队协作。请考虑以下情况：
Sandy 错过了服务Foo培训，且不确定如何运行特定的更新命令。因而导致故障时间的延长。 SRE Jesse [对Sandy的leader说]:“你是经理，为什么不确保每个人都完成培训？”
这个交流凸显了一个主要问题，即让收件人处于劣势。更平衡的回应是：
SRE Jesse [对Sandy的leader]：“看完事后总结，能够注意到on-call错过了一次重要的培训，导致没有更快的解决故障。因此是否应该要求团队成员加入on-call轮转之前都完成此培训？或者是否可以提醒on-call，如果操作卡住可以尽快升级事件。毕竟，升级不是错误——尤其它有助于降低客户的负担！从长远来看，因为一些细节很容易被忘记，因此我们不能完全依赖培训。”
事后总结的创作要包含所有事件参与者
当事后总结是单人或由单个团队编写时，很容易忽略导致故障的关键因素。
收集反馈
明确的审查过程和事后计划可以帮助防止指责的语言和观点在组织内传播。有关的结构化审核流程请参阅第221页的“事后检查清单”部分。
奖励事后总结
事后总结培训是积极推动组织变革和防止重复故障的有效工具。如果写的够好，采取行动并广泛分享，可以考虑以下策略来激励事后总结文化。
对完成行动列表进行奖励
如果你奖励工程师编写事后总结而不是完成了相关的行动列表，那么可能会出现总结中的行动项目未完成的事情。需要在编写事后总结和成功完成行动计划间平衡奖励措施。
对积极的组织变革进行奖励
你可以将事后总结的重要性作为提高组织影响的依据，通过对标奖金、积极的绩效评估、晋升等作为奖励。来激励并广泛实施事后总结教训。
突出提高可靠性
随着时间的推移，有效的事后总结可以减少故障，让系统更加可靠。因此，团队可以专注于特性功能的开发速度，而不是基础架构的修补上。在总结、演示文稿和绩效评估中强调这些改进在本质上是会提供动力的。
把事后总结的负责人当做领导者
通过电子邮件或会议完成事后总结，或者通过给作者向受众提供经验教训的机会，能够吸引那些喜欢公共赞誉的人。对于寻求同行认可的工程师而言，可以将负责人设置为某种类型的故障的“专家”。例如，你可能会听到有人说：“和Sara说，她现在是专家了。她参与了事后总结的撰写，并且想出了解决问题的方法！”
游戏化
一些人会被成就感和更远大的目标所激励，例如修复系统薄弱点和提高可靠性。对于这些人而言，事后总结行动列表的记录或完成所获得的成就已经是奖励了。在Google，我们每年举办两次“FixIt”周。完成最重要的行动列表项目的SRE会收到小额赞赏和吹牛的权利。图10-3显示了一个事后总结排行榜的示例。
公开分享事后总结
为了在组织内保持健康的事后总结文化，要尽可能广泛的分享事后总结。以下策略可以提供一些帮助。
在整个组织内分享总结
在内部沟通渠道、电子邮件、Slack等中宣传事后总结的可用性。如果你负责一个公司，可以分享一个最近的有趣的事后总结。
进行跨团队审核
对事后总结进行跨团队审查。过程中，一个团队过一遍故障，其他团队提出问题并间接学习。在Google，几个办公室都设有非正式的事后总结俱乐部，向所有员工开放。
此外，由开发人员、SRE和组织领导组成的跨职能小组审核整个事后总结流程。他们每个月都会审查事后总结过程和模板的有效性。
进行培训练习
使用“命运之轮”训练新入职工程师：一群工程师重新扮演事后总结的角色，当时的事故总控负责人也参与其中，确保这次演习尽可能的“真实”。
每周总结事件和故障
每周对过去七天内发生的事件和故障的进行总结，并尽可能广泛的进行分享。
响应事后总结文化的失败
事后总结文化的崩溃可能并不明显，以下介绍了常见的故障模式和推荐的解决方案。
逃避
逃避事后总结过程可能是一个组织的事后总结文化失败的征兆，例如，假设SRE 主管 Parker无意中听到以下对话：
SWE Sam：哇，你听说了这次的大故障了吗？
SWE Riley：听说了，太可怕了。他们现在得写一个事后总结了。
SWE Sam：不是吧，还好我没有参与进去。
SWE Riley：对啊，我是真的不想参与那个讨论会议。
确保对产生这些抱怨的事件进行高可见度的事后总结可以避免这种逃避。此外，分享高质量的案例并讨论参与的人如何获得奖励将有助于重新团结每个人。。
没有强调文化
当高级管理人员使用责备的语言做出回应可能会使事情更糟糕。假设一个高级领导在会议上对故障做出以下声明：
VP Ash：我知道应该对事不对人，但有人事先知道这个操作可能会产生问题，你为什么不听那个人的？
可以通过更有建设性的话术来减少损害，例如：
SRE Dana：我确信每个人的出发点都是好的，所以为了保持对事不对人的准则，我们一般会这样问：是否有任何应该注意到的告警以及我们为何会忽略它们。
对于组织而言，立足正确的出发点，并根据现有的最佳信息做出决策，调查误导性信息的来源比分配责任更有帮助。（如果你知道敏捷原则，那么你应该对这个更加清楚。）
没有时间写事后总结
优质的事后总结撰写是需要时间的。当一个团队负担其他任务时，总结的质量会受到影响。低质量的没有完整的行动列表的事后总结会更容易导致故障复发。事后总结是你写给团队未来成员的信件：以免你不小心教给未来的队友一个错误的教训，保持一致的质量标准十分重要。应该优先考虑事后检查工作，跟踪事后完成情况和审查，并让团队有足够的时间来实施相关的行动计划。我们在第220页的“工具和模板”一节中讨论的工具可以帮助完成此项活动。
重复故障
如果团队在遇到类似故障时采用以前的经验失败了，那么就该深入挖掘了。要考虑以下问题：
- 行动列表项目是否需要很长时间才能完成？
- 故障速度是否超过了可靠性的修复速度？
- 最先获得的是正确的行动项目吗？
- 重构的故障服务是否过期？
- 是否把Band-Aids定位成更严重的问题上了？
如果你发现了系统性流程或技术问题，应该退一步考虑整体服务运行状况。将每个类似事件的事后总结作者聚集到一起，讨论防止故障重复发生的最佳行动方案。
工具和模板
一组工具和模板可以让编写事后总结和管理相关数据变得更轻松，从而引导事后总结文化。在这一领域，你可以利用Google和其他公司提供的大量资源。
事后总结模板
模板可以使编写和分享完整的事后总结更加轻松。使用标准格式可以使非专业的读者更容易理解事后处理过程。你可以自定义模板。例如，获取特定团队的元数据（如数据中心团队的硬件品牌/型号）或受移动团队影响的Android版本可能更有用。随着团队在这方面的成熟，还可以自定义模板。
Google模板
Google已经通过http://g.co/SiteReliabilityWorkbookMaterials以Google文档格式分享了我们的事后模板。我们在内部主要使用Docs来编写事后总结，可以通过共享编辑权限和注释促进合作。我们的一些内部工具可以使用元数据预填充此模板让事后总结更容易编写。我们利用Google Apps脚本自动化部分创作，并将大量数据捕获到特定的部分和表格中，以便我们的事后总结存储库更容易解析数据。
其他行业模板
其他几家公司和个人分享了他们的事后总结模板：
- 报警职责
- 改编原始的Google可靠性站点工程书籍模型
- GitHub上托管的四个模板列表
- GitHub用户Julian Dunn
- 服务器故障
事后总结工具
在撰写本文时，Google的事后总结管理工具无法供外部使用（请查看我们的博客获取最新更新）。但是，我们可以解释我们的工具是如何促进事后总结文化的。
事件管理工具
我们的事件管理工具收集并存储大量关于故障的有用数据，并将该数据自动推动到事后总结模板中。我们推送的数据类型包括：
- 故障指挥人和其他角色
- 详细的事件时间表和IRC日志
- 受影响的服务和导致根本原因的服务
- 事件严重性
- 事件检测机制
事后总结清单
为了帮助作者确保正确完成事后检查，我们提供了一个事后检查清单，通过关键步骤引导负责人。以下是列表中的一些示例检查：
- 对事件影响进行全面评估。
- 进行足够详细的根本原因分析，推动行动列表的规划。
- 确保行动列表项目通过服务技术主管的审查和批准。
- 和更多的组织分享事后总结。 完整的清单可在http://g.co/SiteReliabilityWorkbookMaterials找到。
归档事后总结
我们将事后总结归档在一个名为Requiem的工具中，这样任何Google员工都可以轻松找到它们。我们的事件管理工具会自动将所有事后总结推送到Requiem，组织中的任何人都可以发布他们的事后总结给所有人查看。我们有成千上万的总结存档，可以追溯到2009年。Requiem会解析个人事后总结的元数据，使其可以用于搜索、分析和总结。
跟进事后总结
我们的事后总结归档在Requiem的数据库中。任何生成的操作项都会在我们的集中式bug跟踪系统中归档为bug。因此，我们可以监控每个事后总结的行动项目的结束与否。通过这种级别的跟踪，可以确保行动项目不会有漏洞以致服务越来越不稳定。图10-4显示了由我们的工具启用的事后总结操作项监控的模型。
事后总结分析
我们的事后总结管理工具将信息存储在数据库中以供分析。团队可以使用这些数据编写有关其事后趋势的总结，并确定易受攻击的系统。这有助于我们发现潜在的不稳定因素或可能被忽略的故障管理障碍。例如，图10-5显示了使用我们的分析工具构建的图表。这些图表显示了我们每个组织每月有多少次事后追踪、事件平均持续时间、检测时间、解决时间和故障半径的趋势。
其他行业工具
以下是一些可以帮助你创建、组织和分析事后总结的第三方工具：
- 报警职责事后调查
- Etsy的档案室
- VictorOps 尽管完全实现自动化编写事后总结是不可能的，但我们发现事后总结模板和工具会使整个流程更加顺畅。这些工具可以节省时间，让作者能够专注于事后的关键部分，例如根本原因的分析和行动项目计划。
结论
在培养事后总结文化的持续投资中，能够减少故障，为用户提供更好的体验，以及让依赖你的人对你更加信任。这些实践的应用可以使系统设计更完善、宕机时间更短、工程师工作效率更高且工作更快乐。如果最坏的情况确实发生并且故障再次发生，那么你受到的损失会更小并且恢复的更快，而且有更多的数据帮助健壮生产环境。