前言

作为 SRE，我们负责运维大型的、复杂分布式系统。同时我们还在不断地增加新功能， 和增加新系统。以我们的改动速率和规模，发生事故是难以避免的。

在事故发生后，我们要修复根源性问题，同时将服务恢复到正常服务状态下。如果没有一种方法从已发生的事故中学习经验，那么事故就可能循环反复地发生。

如果不能解决系统的这个问题，那么随着系统规模和复杂度的增加，事故可能成倍增加，最终导致我们没有足够的资源处理事故，最终影响最终用户。因此，事后总结是 SRE 的一个必要工具。

事后总结的概念已经是科技行业中众所周知的了。一篇事后总结是一次事故的书面记录，包括该事故造成的影响，为缓解该事故采取的措施，事故的根本原因，以及防止未来问题重现的后续任务。

本文描述了决定是否需要书写事后总结的标准，一些事后总结的最佳实践，以我们在如何培育一种良好的事后总结风气上的一些经验。

Google 的事后总结哲学

书写事后总结的主要目标，是为了保证该事故被记录下来，理清了所有的根源性问题， 同时最关键的是，确保实施了有效的措施使得未来重现的几率和影响得到降低，甚至避 免重现。

但是在系统质 量分析领域有非常多的文章、最佳实践和工具可供选用。Google 的每个团队在根源分析上都采用了不同的方法和工具。在任何一个重要事故发生后，团队必须书写一份事后总结。

要注意的是，书写事后总结不是一种惩罚措施，而是整个公司的一次学习机会。但是书写事后总结的过程确实需要消耗团队的一定时间和精力，所以我们在选择上很严格。

每个团队都有一些内部灵活性，但是基本的事后总结条件为 :

·         用户可见的宕机时间或者服务质量降级程度达到一定标准。

·         任何类型的数据丢失。

·         on-call 工程师需要人工介入的事故(包括回滚、切换用户流量等) y 问题解决耗时超过一定限制。

·         监控问题(预示着问题是由人工发现的，而非报警系统)。

在事故发生前定义好事后总结的标准是很重要的，这样每个参与处理事故的人都知道是 否应该书写书面报告。在这些客观条件之外，任何受影响的相关部门都可以提出写一篇 事后总结的要求。

在 SRE 文化中，最重要的就是事后总结“对事不对人”。一篇事后总结必须重点关注如何定位造成这次事件的根本问题，而不是指责某个人或某团队的错误或者不恰当的举动。

一篇对事不对人的事后总结假设所有参与事件处理的人都是善意的，他们在自己当时拥有的信息下做了正确的举动。如果因为某些“错误的”举动就公开指责或者羞辱某个人或团队，那么人们就会自然地逃避事后总结。

对事不对人的文化起源于医疗和航空行业，在这些领域中错误的举动可能会造成人身伤亡。这些行业认为每个“错误”都是一次学习机会，从而使系统变得更可靠。

当事后总结系统性、逻辑性地讨论为什么某些团队或个人会在事故过程中获得“错误”的信息时，我们才能建立更好的预防措施，防止问题再现。我们不能“修好”某个人，但是可以通过改善系统和流程从而更好地协助他，在设计和维护大型复杂系统时，做出更多“正确” 的判断。

当一次事故发生时，我们不能把事后总结当成例行公事。我们的工程师将事后总结看作 一个修复问题，一个使 Google 变得更可靠的机会。一篇“对事不对人”的事后总结不应该简单地指责或者抱怨某个团队，而应该确实提出服务如何能够获得进步。

指责

我们需要重写整个复杂后端系统。在过去三个季度中，它每周都在出问题。我们对 一点一点修复它的问题已经烦透了!真的，如果我再收到一个报警，那我就自己重 写了。”

对事不对人

“通过重写整个后端系统可能可以避免这些烦人的报警信息继续发生，目前版本的维 护手册非常冗长，学习成本很高。相信通过重写，可以减少报警信息，未来的 on-call 工程师会感谢我们的。”

最佳实践

1. 避免指责，提供建设性意见
对事不对人的事后总结有的时候比较难写，因为事后总结的格式清晰地表明了触 发事故的原因。从事后总结中排除指责的因素可以使人们在向上升级汇报问题的 时候更有自信。同时我们也不应该因为某个团队和个人经常写事后总结而对他们产生怀疑。一个充满相互指责风气的环境很容易让人将事故和问题掩盖起来，从 而对整个组织酿成更大的灾难。

协作和共享知识

说起来容易做起来难，建立起事后总结文化需要不断地培育和加强。Google 通过高级管理层的主动参与协作和评审环节来不断加强内部事后总结文化。虽然管理层可以鼓励建立“对事不对人”的氛围，但是由工程师自主驱动，效果会更好。为了更好地建立事后 总结文化，SRE 经常搞一些集体学习活动，例子包括 :

1. 本月最佳事后总结

通过每周一次的新闻邮件，与整个组织共享一篇一篇有趣并且质量很高的事后总结。

2. Google+ 事后总结小组

本小组共享和讨论内部与外部的事后总结，同时包括一些最佳实践和事后总结的评论文章。

3. 事后总结阅读俱乐部

某团队经常性地组织阅读俱乐部。在这项活动过程中，所有参与者和未参与者(甚至是新来的工程师)共同开发式地讨论一篇有趣或者很有影响力的事后总结，包括事件的发生过程，学习到的经验教训，以及善后处理。通常，我们讨论的是几月前 甚者几年前的事后总结。

4. 命运之轮(Wheel of Misfortune)

刚加入的 SRE 工程师经常需要参加命运之轮这个活动。在这个活动中，我们将之前的某篇事后总结的场景再现，一批工程师负责扮演这篇文档中提到的各种角色。经常，当时的事故总控负责人也参与其中，确保这次演习越真实越好。

在引入事后总结机制的时候，最大的阻力来源于对投入产出比的质疑。下面的策略可以帮助面对这些挑战 :

·         逐渐引入事后总结流程。首先进行几次完整的和成功的事后总结，证明它们的价 值，同时帮助确定具体是否应该书写事后总结的条件。

·         确保对有效的书面总结提供奖励和庆祝。不光通过前面提到的公开渠道，也应该在团队或个人的绩效考核中体现。

·         鼓励公司高级管理层认可和参与其中。Larry Page(Google创始人之一)经常称 赞事后总结的价值之高!

最佳实践

2. 公开奖励做正确事的人

Google 创始人 Larry Page 和 Sergey Brain，每周会在美国加州山景城总部举办全公司的 TGIF 大会，所有 Google 全球办公室都可以收看直播。2014 年一次 TGIF 以 “事后总结的艺术”为主题，邀请了 SRE 一起讨论重大的事故处理过程。某 SRE 讨论了他经历的一次更新事故。在某次更新中，虽然经过了详细测试，还是由于不 可预知的关联系统问题导致某关键服务停止运行 4 分钟。因为 SRE 立刻执行了回滚，从而避免了更长和影响更大的事故，导致这次事故仅仅持续了 4 分钟。

这名工程师不仅立即收到了两个同事发来的奖金(Peer Bonus)，同时他的快速和沉着处理赢得了 TGIF 观众的热烈掌声，其中包括几千名在场观众和两名 Google 创始人。除此之外，Google 内部还有一系列内部社交网络，鼓励用户对质量优秀的事后报 告和灾难处理提出奖励。

上面这个例子只是很多个例子中的一个，在 Google 内部， 良好的事后总结和事故处理可以赢得从 CEO 到工程师的一致好评。

3. 收集关于事后总结有效性的反馈
在 Google，我们倾向于解决新问题并将创新在内部共享。我们经常在团队内部搞 调查问卷，以了解事后总结流程是否在合理地支持他们的工作，以及如何改进。

我们问的问题有:团队文化是否支持你的工作?书写事后总结是否引入了太多杂事?你们团队有什么最佳实践可以分享?这些调查结果可以给平时很忙的 SRE 一个机会去提供有效性的改进和反馈意见

在事故流程管理之外，事后总结已经成为 Google 文化的一部分:在任何严重问题发生时， 都会产生一篇事后总结(比如某项产品上线之后反响很差，也会有类似的事后总结)。

总结以及不断优化

我们可以很自信地说，由于我们不断地培育公司事后总结文化，Google 的事故越来越少， 用户体验也越来越好。我们的“事后总结”小组是建立“对事不对人”文化努力的一个 代表。这个小组协调公司内部各种部门的事后总结流程 : 建立事故总结模板，用流程管理工具自动化数据收集，以及自动化元数据收集以便进行趋势分析。

我们能够将我们的 最佳实践共享给不同的产品部门，包括Youtube、Google Fiber、Gmail、Google Cloud、 Adwords 及 Google 地图等。这些截然不同的产品部门都是为了共同的学习目标进行事后总结的工作。

每月有大量的事后总结在 Google 内部形成，汇总这些总结的工具也越来越有用。这些工具帮助我们在事后总结中寻找共同的模式和主题，以便形成改进意见。

为了更好地进行数据收集汇总分析工作，我们最近在模板中增加了一些元数据。接下来我们还会采取机器学习等手段在这个领域内尝试预测系统的弱点，降低重复事故的发生，和更好地进行实时事故调查。（孙宇聪翻译）

前言

作为 SRE，我们负责运维大型的、复杂分布式系统。同时我们还在不断地增加新功能， 和增加新系统。以我们的改动速率和规模，发生事故是难以避免的。

在事故发生后，我们要修复根源性问题，同时将服务恢复到正常服务状态下。如果没有一种方法从已发生的事故中学习经验，那么事故就可能循环反复地发生。

如果不能解决系统的这个问题，那么随着系统规模和复杂度的增加，事故可能成倍增加，最终导致我们没有足够的资源处理事故，最终影响最终用户。因此，事后总结是 SRE 的一个必要工具。

事后总结的概念已经是科技行业中众所周知的了。一篇事后总结是一次事故的书面记录，包括该事故造成的影响，为缓解该事故采取的措施，事故的根本原因，以及防止未来问题重现的后续任务。

本文描述了决定是否需要书写事后总结的标准，一些事后总结的最佳实践，以我们在如何培育一种良好的事后总结风气上的一些经验。

Google 的事后总结哲学

书写事后总结的主要目标，是为了保证该事故被记录下来，理清了所有的根源性问题， 同时最关键的是，确保实施了有效的措施使得未来重现的几率和影响得到降低，甚至避 免重现。

但是在系统质 量分析领域有非常多的文章、最佳实践和工具可供选用。Google 的每个团队在根源分析上都采用了不同的方法和工具。在任何一个重要事故发生后，团队必须书写一份事后总结。

要注意的是，书写事后总结不是一种惩罚措施，而是整个公司的一次学习机会。但是书写事后总结的过程确实需要消耗团队的一定时间和精力，所以我们在选择上很严格。

每个团队都有一些内部灵活性，但是基本的事后总结条件为 :

·         用户可见的宕机时间或者服务质量降级程度达到一定标准。

·         任何类型的数据丢失。

·         on-call 工程师需要人工介入的事故(包括回滚、切换用户流量等) y 问题解决耗时超过一定限制。

·         监控问题(预示着问题是由人工发现的，而非报警系统)。

在事故发生前定义好事后总结的标准是很重要的，这样每个参与处理事故的人都知道是 否应该书写书面报告。在这些客观条件之外，任何受影响的相关部门都可以提出写一篇 事后总结的要求。

在 SRE 文化中，最重要的就是事后总结“对事不对人”。一篇事后总结必须重点关注如何定位造成这次事件的根本问题，而不是指责某个人或某团队的错误或者不恰当的举动。

一篇对事不对人的事后总结假设所有参与事件处理的人都是善意的，他们在自己当时拥有的信息下做了正确的举动。如果因为某些“错误的”举动就公开指责或者羞辱某个人或团队，那么人们就会自然地逃避事后总结。

对事不对人的文化起源于医疗和航空行业，在这些领域中错误的举动可能会造成人身伤亡。这些行业认为每个“错误”都是一次学习机会，从而使系统变得更可靠。

当事后总结系统性、逻辑性地讨论为什么某些团队或个人会在事故过程中获得“错误”的信息时，我们才能建立更好的预防措施，防止问题再现。我们不能“修好”某个人，但是可以通过改善系统和流程从而更好地协助他，在设计和维护大型复杂系统时，做出更多“正确” 的判断。

当一次事故发生时，我们不能把事后总结当成例行公事。我们的工程师将事后总结看作 一个修复问题，一个使 Google 变得更可靠的机会。一篇“对事不对人”的事后总结不应该简单地指责或者抱怨某个团队，而应该确实提出服务如何能够获得进步。

指责

我们需要重写整个复杂后端系统。在过去三个季度中，它每周都在出问题。我们对 一点一点修复它的问题已经烦透了!真的，如果我再收到一个报警，那我就自己重 写了。”

对事不对人

“通过重写整个后端系统可能可以避免这些烦人的报警信息继续发生，目前版本的维 护手册非常冗长，学习成本很高。相信通过重写，可以减少报警信息，未来的 on-call 工程师会感谢我们的。”

最佳实践

1. 避免指责，提供建设性意见
对事不对人的事后总结有的时候比较难写，因为事后总结的格式清晰地表明了触 发事故的原因。从事后总结中排除指责的因素可以使人们在向上升级汇报问题的 时候更有自信。同时我们也不应该因为某个团队和个人经常写事后总结而对他们产生怀疑。一个充满相互指责风气的环境很容易让人将事故和问题掩盖起来，从 而对整个组织酿成更大的灾难。

协作和共享知识

说起来容易做起来难，建立起事后总结文化需要不断地培育和加强。Google 通过高级管理层的主动参与协作和评审环节来不断加强内部事后总结文化。虽然管理层可以鼓励建立“对事不对人”的氛围，但是由工程师自主驱动，效果会更好。为了更好地建立事后 总结文化，SRE 经常搞一些集体学习活动，例子包括 :

1. 本月最佳事后总结

通过每周一次的新闻邮件，与整个组织共享一篇一篇有趣并且质量很高的事后总结。

2. Google+ 事后总结小组

本小组共享和讨论内部与外部的事后总结，同时包括一些最佳实践和事后总结的评论文章。

3. 事后总结阅读俱乐部

某团队经常性地组织阅读俱乐部。在这项活动过程中，所有参与者和未参与者(甚至是新来的工程师)共同开发式地讨论一篇有趣或者很有影响力的事后总结，包括事件的发生过程，学习到的经验教训，以及善后处理。通常，我们讨论的是几月前 甚者几年前的事后总结。

4. 命运之轮(Wheel of Misfortune)

刚加入的 SRE 工程师经常需要参加命运之轮这个活动。在这个活动中，我们将之前的某篇事后总结的场景再现，一批工程师负责扮演这篇文档中提到的各种角色。经常，当时的事故总控负责人也参与其中，确保这次演习越真实越好。

在引入事后总结机制的时候，最大的阻力来源于对投入产出比的质疑。下面的策略可以帮助面对这些挑战 :

·         逐渐引入事后总结流程。首先进行几次完整的和成功的事后总结，证明它们的价 值，同时帮助确定具体是否应该书写事后总结的条件。

·         确保对有效的书面总结提供奖励和庆祝。不光通过前面提到的公开渠道，也应该在团队或个人的绩效考核中体现。

·         鼓励公司高级管理层认可和参与其中。Larry Page(Google创始人之一)经常称 赞事后总结的价值之高!

最佳实践

2. 公开奖励做正确事的人

Google 创始人 Larry Page 和 Sergey Brain，每周会在美国加州山景城总部举办全公司的 TGIF 大会，所有 Google 全球办公室都可以收看直播。2014 年一次 TGIF 以 “事后总结的艺术”为主题，邀请了 SRE 一起讨论重大的事故处理过程。某 SRE 讨论了他经历的一次更新事故。在某次更新中，虽然经过了详细测试，还是由于不 可预知的关联系统问题导致某关键服务停止运行 4 分钟。因为 SRE 立刻执行了回滚，从而避免了更长和影响更大的事故，导致这次事故仅仅持续了 4 分钟。

这名工程师不仅立即收到了两个同事发来的奖金(Peer Bonus)，同时他的快速和沉着处理赢得了 TGIF 观众的热烈掌声，其中包括几千名在场观众和两名 Google 创始人。除此之外，Google 内部还有一系列内部社交网络，鼓励用户对质量优秀的事后报 告和灾难处理提出奖励。

上面这个例子只是很多个例子中的一个，在 Google 内部， 良好的事后总结和事故处理可以赢得从 CEO 到工程师的一致好评。

3. 收集关于事后总结有效性的反馈
在 Google，我们倾向于解决新问题并将创新在内部共享。我们经常在团队内部搞 调查问卷，以了解事后总结流程是否在合理地支持他们的工作，以及如何改进。

我们问的问题有:团队文化是否支持你的工作?书写事后总结是否引入了太多杂事?你们团队有什么最佳实践可以分享?这些调查结果可以给平时很忙的 SRE 一个机会去提供有效性的改进和反馈意见

在事故流程管理之外，事后总结已经成为 Google 文化的一部分:在任何严重问题发生时， 都会产生一篇事后总结(比如某项产品上线之后反响很差，也会有类似的事后总结)。

总结以及不断优化

我们可以很自信地说，由于我们不断地培育公司事后总结文化，Google 的事故越来越少， 用户体验也越来越好。我们的“事后总结”小组是建立“对事不对人”文化努力的一个 代表。这个小组协调公司内部各种部门的事后总结流程 : 建立事故总结模板，用流程管理工具自动化数据收集，以及自动化元数据收集以便进行趋势分析。

我们能够将我们的 最佳实践共享给不同的产品部门，包括Youtube、Google Fiber、Gmail、Google Cloud、 Adwords 及 Google 地图等。这些截然不同的产品部门都是为了共同的学习目标进行事后总结的工作。

每月有大量的事后总结在 Google 内部形成，汇总这些总结的工具也越来越有用。这些工具帮助我们在事后总结中寻找共同的模式和主题，以便形成改进意见。

为了更好地进行数据收集汇总分析工作，我们最近在模板中增加了一些元数据。接下来我们还会采取机器学习等手段在这个领域内尝试预测系统的弱点，降低重复事故的发生，和更好地进行实时事故调查。（孙宇聪翻译）