在深入讨论Google SRE的文化和实践时，我们很自然地会联想到其他行业是如何对待 可靠性这个问题的。借着编纂本书这个机会，我有幸和许多 Google 工程师一起讨论了 他们之前的工作经历，这些行业也非常注重可靠性。在讨论时，我的目标是回答下列几个问题 :

• SRE采用的指导思想是否在Google外部也有采用？甚至，其他行业是否在用截然不同 的方式解决高可靠性问题？
• 如果其他行业也采用同样的指导思想，那么具体对应的实践是什么样的？
• 不同行业之间的具体实践的相似点与不同点是什么？
• 是什么因素导致了这些相似点和不同点的产生？
• Google 以及科技行业可以从这些对比中学到什么？
  
  

在本文中，我们会讨论到许多 SRE 的核心指导思想。为了简化与其他行业最佳实践的比较，我们将这些理念分为 4 大类 :

• 灾难预案与演习
• 书写事后总结的文化
• 自动化与降低日常运维负载
• 结构化的、理智的决策
  
  

文中同时介绍了有其他行业经验的资深 SRE。我们一起讨论了关键的 SRE 思想，以 及这些思想是如何在 Google 内部应用的，同时也给出了其他行业内部应用这些思想的例子。最后，以一些模式和反模式作为结尾。

前言：有其他行业背景的资深 SRE

包括 Peter Dahl，Mike Doherty，Erik Gross，Gus Hartmann，Ron Heiby，Adrian Hilton，Eddie Kennedy ，John Li ，Dan Sheridan，Jeff Stevenson，Matthew Toia。

他们都是Google SRE，并且在加入Google之前，都有多年的其他行业背景。

编者注：这些人名都将出现在后文中，但考虑到实际相关度不大，因此略去了他们的背景介绍，以减少篇幅。更多详情请参考原书。

1、灾难预案与演习

“愿望不是一个策略”，Google 的 SRE 这条口号很好地总结了我们对灾难预案与演习的态度。SRE 的文化是永远保持警惕，不停地提出疑问：什么可能出现故障？在故障导致服务停止或者数据丢失之前我们如何避免？

我们的年度灾难恢复演习（DiRT）就是为了解决这个问题。在 DiRT 演习中，SRE 在生产环境中创造真正的问题， 以便能够 :

• 确保系统按我们预想的方式应对故障。
• 寻找系统中未预料到的弱点。
• 寻找其他提高系统鲁棒性的方式来避免事故发生。
  
  

在其他行业中，关于如何测试团队的灾难准备情况，以及保障团队应对灾难的能力的策 略有如下几个方面 :

• 从组织架构层面坚持不懈地对安全进行关注。
• 不放过任何细节。
• 冗余容量。
• 模拟以及进行线上灾难演习。
• 培训与考核。
• 对细节要求的收集与系统的设计超乎寻常的关注。
• 纵深防御。
  
  

1.1 从组织架构层面坚持不懈地对安全进行关注

该理念对工业工程来说格外重要。Eddie Kennedy 曾经在一个高危制造车间工作，随时面临着格外危险的环境，“每次管理会议都是以安全讨论开头。”

制造业通过建立极为确定的流程，以及保证整个组织从上至下严格对该流程的遵守来确保不会出现意外事故。

每个员工对安全的关注是很极为重要的，这样每个员工在他们发现出现问题时可以主动提出。在核动力行业、军用飞机，以及轨道交通信号系统行业中，软件的安全标准是明确定义的。

例如 UK Defense Standard 00-56、IEC 61508、IEC 513、US DO-178B/C、DO-254。 同时，这些系统的可靠性级别也都是明确定义的（安全整合级别（SIL）1-4）。

这些规定的目标都是为保障交付软件产品时候的质量。

1.2 对细节的关注

Jeff Stevenson回忆起在美国海军的任职经历，所有人对某些小任务执行过程中出现的粗心情况可能会导致大型潜艇事故的情况非常了解（例如，润滑油的及时补充）。

非常小的一个错误都可能产生极为严重的后果。

系统相互连接紧密，所以一个区域的事故可能会导致多个相关系统出现故障。核动力海军对日常常规维护非常重视，以确保小问题不 会发展成大事故。

1.3 冗余容量

系统利用率在通信行业中可能是非常难以预知的。系统容量可能会被无法提前预料的事件所影响，例如自然灾害等，又或者是大型的可预知的活动，例如奥林匹克竞赛。

在 Gus Hartmann的经历中，通信行业利用SOW（Switch on wheels），移动通信平台来提供冗余容量，以便应对这些情况。

这些额外的容量可以应急部署，也可以在某个大型事 件发生之前提前部署。同时，系统容量不仅仅是指系统的绝对容量，也和其他方面有关。

例如，某个明星的电话号码在2005年泄漏之后，数以千计的粉丝同时试图拨打这个电话， 整个通信系统陷入了一种类似 DDoS 的状态，造成了大面积的路由错误。

1.4 模拟以及线上灾难演习

Google 的灾难恢复团队在模拟与线上灾难演习方面与其他行业的关注点非常类似。

利用某种灾难情景可能导致的故障的严重程度来决定是使用模拟方式，还是线上方式进行演习。

例如，Matthew Toia指出，航空行业由于设备和人员安全因素无法进行真正的线 上测试。他们则部署了极为逼真的模拟器，这些模拟器使用线上真实数据。在测试中，控制室与设备在细节上与真实环境高度一致，以确保可以得到真实的测试数据。

Gus Hartmann 同时提到，通信行业一般采用线上演习模式，主要关注于应对飓风或者其他环境灾难。这种理念使得很多通信行业都建设了防水机房，同时内部带有可以运行超过飓风持续时间的发电机。

美国核动力海军会同时进行假想练习与真实的实战演习。

Jeff Stevenson说，实战演习包括“在可控环境下进行破坏”。实战演习每周进行，每次持续两到三天。对核动力海军来说， 假想练习是有用的，但是却不能真正防止灾难发生。灾难的响应机制必须要经过不断练 习才能确保不会忘记。

Mike Doherty，曾经的救生员，这个行业采用一种类似“神秘顾客”的方式进行灾难演习。

一般来说，设施负责人会和一个儿童，或者是某个正在接受训练的救生员一起构造一起伪落水事故。

这些情景会制造得非常逼真，救生员一般无法区分真实和虚构的紧急事故。

1.5 培训与考核

我们的座谈结果显示，培训与考核在涉及人身安全的行业极为重要。例如，Mike Doherty 描述了救生员如何通过非常严谨的培训考核过程，同时还要定期接受再考核。

培训课程包括健身部分（救生员必须能够将某个比自己还重的人托住，使得他们肩膀露 出水面），也包括技巧部分（例如急救和 CPR），同时还包括日常流程方面（例如，当某个救生员跳入水里时，其他团队成员应该做什么）。

每个设施都有当地特有的培训课程， 因为在游泳池里救人和在湖边或者海中救人有很大差异。

1.6 对详细的需求收集和系统设计的关注

与我们座谈的一些工程师讨论了详细的需求收集与设计文档的重要性。这些实践对医疗器械来说尤其重要。

在很多案例中，某个器械的使用情况或者维护情况与设计者的预想很不一样。因此，具体的使用情况与维护需求必须从其他来源获取到。

例如，根据Erik Gross的经验，激光视网膜手术设备被设计得极为简单明了，确保使用 它们的人不会出错。因此，从真正使用这些设备进行手术的医生处，以及维护这些设备的工程师处获取需求是很重要的。

在另一个例子里，Peter Dahl描述了国防系统中对设计高度重视的文化。构建新的国防设备甚至需要一整年的设计过程，最后的实际编码过 程只需要三周。

这两个例子与 Google 的发布迭代文化截然不同，我们更倾向于在计算过的风险性前提下，最大化迭代的速度。

其他行业（如上文提到的医疗行业和军用行业） 对风险的承受能力与我们区别很大，这就导致了他们采用的方案与 Google 截然不同。

1.7 纵深防御

在核能行业中，纵深防御是灾难预案中的一个关键元素。核反应 堆的所有系统都有冗余备份，同时在设计中，每个主要系统都强制备有后备系统。整个系统设计时加入了多层防护机制，包括最后的发电站核辐射物理屏障。纵深防御理念在核能行业中非常重要，因为他们对事故和灾难几乎是零容忍的。

2、事后总结的文化

纠正性和预防性操作（CAPA）是提升可靠性的一个常见概念。这意味着系统化关注于引起故障，或者带来风险的根源问题。

这与SRE“对事不对人”的事后总结理念非常一致。

当出现问题时（由于 Google 内部环境的海量环境、复杂程度，以及非常高的变化速度， 一定会有东西出现问题），详细考核下列问题是很重要的 :

• 究竟发生了什么？
• 响应的有效程度
• 下次是否可以采用其他方案解决问题
• 如何确保这次故障不会再次发生
  
  

这个过程在执行的时候不应该归责于任何一个个人，更重要的是，作为一个组织我们要找出什么出现了问题，以及如何确保问题不再发生。

纠结于“谁”造成了这个故障是没有意义的。

事后总结在每次事故发生之后都会进行，同时会在整个 SRE 团队内部传阅， 以便让所有人都能从中受益。

我们的座谈发现了很多行业也进行类似的事后总结活动（但是很多都不会用 Postmortem 这个词语来指代，因为这个词有验尸的意思）。但是，在不同的行业内部，他们进行事 后总结的原动力各有不同。

很多行业都受到政府部门的严密监管，出现问题时，会有相关的政府部门追责。这样监管在灾难预期后果严重的时候是更加紧密的（例如那些会造成人员伤亡的事故）。

相关的 政府监管部门包括 FCC（通信行业）、FAA（航空业）、OSHA（制造业与化工业）、FDA
（医疗器械），以及 欧盟中的数个 NCA 。核工业与运输业也被严密监管。

另外一个进行事后总结的动力是对安全的关注。在制造业与化工行业中，由于生产过程的危险性，员工伤亡的风险是一直存在的（高温、高压、有毒气体、腐蚀性液体等）。

例如， Aloca在安全问题上非常关注。前CEO Paul O’Neil要求员工在出现人员伤亡事故的24 小时内通知他。他甚至将自己家的电话号码直接分发给员工，这样一线员工可以在发现 安全问题时亲自联系他。

制造业与化工行业的危险性非常高，以至于“差点出事”——某个事件可能会造成严重伤亡，但是没有——这样的事件也会详细追究。这些场景成为了一种预防性的事后分析。根据 VM Brasseur 在 YAPCNA 2015 的一次演讲，

“在任何事故和业务灾难发生之前，类似事故都曾经发生过好几次，只是没有造成任何后果。这些事故在发生的时候都被忽略了。潜伏的错误，加上某个适合的时机，就会导致事故的发生。”

这种没出事的事故事实上就是一种潜伏的事故。例如，某个工人没有遵守标准的运营流程，或者某个工人在出现泄漏的时候躲开了，或者是台阶上的液体没有及时清理。

这些都意味着潜在事故的发生，以及学习和优化的机会。下一次，整个公司和员工可能就不 会这么幸运了。

英国的 CHIRP （航空与航海保密汇报机制）允许航空和航海行业的从业人员匿名汇报这类事故的发生，以在整个行业内部敲响警钟。关于这类差点出事的事故报告和分析会在周期性的杂志上刊登。

救生员行业也有一个根深蒂固的事后分析与计划文化。Mike Doherty 讽刺道：“如果救生员的脚踏入了水里，后续就要有很多报告要写。”在游泳池或者沙滩上出现的任何事 故都需要一个详细的事后总结。

对于严重的问题，团队还会集体从头到尾分析案例，讨论哪些行动是正确的哪些是错误的。接下来会根据这些讨论结果修改运营规则，同时还会组织培训帮助大家建立处理类似事故的信心和能力。在某次特别严重的或者创伤性的事故发生之后，甚至会有医疗顾问来帮助团队从精神创伤中恢复。

救生员可能已经尽力了，但是还是会感觉到他们做得不够。和 Google 类似，救生员行业也采用了对事不对人的事后分析机制。事故发生时总是非常混乱的，许多因素都可能影响事故的发生。

在这个领域中，指责某一个具体的人是没有意义的。

3、将重复性工作自动化，消除运维负载

Google SRE本质上还是软件工程师，他们对重复性的、被动性的工作十分反感。在我们的文化中强调避免反复执行一项重复性的工作。

如果一项工作可以自动进行，为什么还需要我们来重复执行呢?

自动化可以降低运维负载，同时节省工程师的时间。他们可用这些时间去主动改进服务的其他方面。

我们所调研的各个行业在对待自动化的问题上各有不同。某些行业信任人多过自动化。美国核动力海军通过一系列交叉管理流程来避免自动化。

例如，根据Jeff Stevenson的经历，操作某个阀门需要一个操作员、一个监督员，以及一个船员与负责监控该操作的工程负责人保持通话。这些操作过程是极为人工化的，因为担心自动化系统可能不会发 现人能注意到的问题。

潜艇上的操作是由一条信任的人工决策链管理的——一系列人，而非单独一个人。核动力海军同时担心自动化和计算机运行速度太快，以至于它们可能造成非常严重且无法挽回的问题。

当面对核反应堆时，缓慢而稳健的方法比快速完成任务更重要。

根据 John Li 的经验，私有化交易行业在近年来对自动化的应用越来越小心。经验证明，配置错误的自动化系统可能会在极短的时间内造成极大的财务损失。

在 2012 年，Knight Capital Group 遇到了一个“软件错误”，在几个小时之内造成了 4.4 亿美元的损失。

同样的，美国股票交易所2010年经历了一次闪电崩溃（Flash Crash），最终归责于一个交易商试图利用自动化方式操纵股市。虽然股票市场很快复原了，但是这次闪电崩溃在30分钟内造成了千亿美元的损失。

计算机能够非常快的执行操作，在这些操作配置错误的时候，速度反而是有害的。

相反，某些公司正是因为计算机比人要反应快得多而大量采用自动化。

根据 Eddie Kenned 的经验，效率与成本的节约在制造业中是非常关键的。自动化可以以更高的效率，更低的成本来完成这些工作。

而且，自动化通常比人工完成工作的重复性更强、更可靠，这意味着自动化可以产出更多高标准的产品。

Dan Sheridan讨论了部署于英国核能工业中的自动化机制。这里，采用的标准是如果整个发电站需要在少于30分钟的时间内响 应某种情况，那么这种响应必须要自动化进行。

在 Matt Toia 的经验中，航空行业有选择地采用自动化。例如后备系统的切换一般来说是自动进行的，但是在其他任务上，行业内部普遍要求人工进行二次校验。虽然整个行业内部采用了很多自动监控系统，实际的空中交通管理系统最终的实现还是需要人来校验 运行。

在Erik Gross的故事中，自动化机制在降低激光视网膜手术的过程中的用户错误是很有效的。在 LASIK 手术进行之前，医生需要进行屈光度测试。

在最初设计中，医生需要手 动输入数字，再按一个按钮，激光系统则会开始视力矫正过程。然而，数据输入错误的问题很严重。在这个流程中，可能会错误输入另外一个病人数据，甚至是左右两个眼睛 的数据搞混了。

自动化在这个环节中减少了这种错误带来影响的可能性。一个自动化的对输入数据的正确性检查是第一个改进：如果操作者输入了超出预期范围的数字，自动化程序会立刻自动提出警告。

其他自动化的改进包括：在操作环节中的虹膜照片会自动与屈光度测量环 节的虹膜图像进行对比，以防止数据混乱情况发生。当这种自动化解决方案最终实现时，这一类的问题就全部消失了。

4、结构化和理性的决策

在 Google 内部，尤其是 SRE 部门内部，数据是极为重要的。整个团队通过以下几种方式保障结构化和理性的决策过程 :

• 某项决策的基本方向是事先决定的，而不是事后得出的。
• 决策时考虑的信息源是清楚的。
• 任何假设都应该明确说明。
• 数据驱动决策要优于情感驱动的决策，直觉驱动的决策，以及资深人士的意见。
  
  

Google SRE 同时用以下列信息作为团队内部的基础要求 :

• 每个人都为服务的用户负责。
• 每个成员都能够根据可用的数据找出执行方案。
  
  

决策应该是通知式的，而不是指令式的，决策的过程不应该考虑个人意见——哪怕是最资深的成员。Eric Schmidt和Jonathan Rosenberg将之称为“HiPPO”——工资最高的员 工的意见。

其他行业中进行决策的过程有很多不同。我们了解到某些行业使用“如果没有坏，就永远不要试着修复它”这种理念来进行决策。这些在设计过程中投入很多思考与精力的行业有一个显著的特点——非常不愿意改变底层技术。

例如，通信行业仍然在使用 19 世纪80年代部署的远距离交换机。为什么他们要依赖几十年前的技术呢?因为这些交换机“基本上不会出错，同时冗余度非常高”，Gus Hartmann 解释道。Dan Sheridan 提到，核能行 业也类似。所有的决策都由一个想法驱动：“如果目前运行正常，那就不要修改它。”

很多行业都非常依赖手册与流程，而不是实时的故障排除。

任何人类能想到的故障场景都在一个检查列表中或者“大本子”里面记载了。当故障发生时，这些资料是进行操作的权威指南。

这种指令式的方式适用于那些发展和演进较慢的行业，因为故障场景不会 因为系统升级而快速变化。这种方式同时适用于那些员工技能水平较低的行业，这样确保员工在紧急情况中正确响应的方法就是提供一套简单清晰的指令集。

其他行业也会采用很清晰的、数据驱动的决策方式。在Eddie Kennedy的经验中，制造业中的一大特点就是试验文化，对构建和测试猜想非常关注。

这些行业经常性地进行某种可控的测试，保证某种变更不会导致结果的大幅度改变，确保没有意外情况发生。变 更只有在经过实验证明后才会实施。

最终，某些行业，例如交易行业，将决策划分成更小的块来更好地管理风险。根据JohnLi的经验，交易行业有一个专门的风险控制部门，独立于交易部门之外，负责确保不会在追求利益的同时承受不必要的风险。

这个风险控制部门负责监控交易场所内部，同时在交易发生意外的时候终止。如果某个系统发生异常情况，风险控制部门的第一反应是 关掉这个系统。John Li提到：“如果我们不在进行交易，那么我们就不会亏钱。

虽然我们也没有赚钱，但是起码不会亏钱。”只有风险控制部门可以将系统重新启用，不论交易员是否错失了某种可以赚钱的机会。

5、结论

Google SRE的很多核心思想在很多行业中都得到了验证。这些成功行业的很多经验教训可能启发了一些 Google 今天内部所使用的流程与实践。

在本次跨行业调研中最主要的一点结论是，与很多软件行业对比，Google 明显更倾向于变更的速度。

但是对变更速度的追求一定要考虑到故障发生时的影响。例如在核动力、民航，以及医疗行业中，如果造成事故可能会有人身伤亡。当故障的影响这么大时，采用更保守的方法是必要的。

在Google内部，我们经常在用户对高可靠性的预期与内部对快速变更和创新的追求之 间寻求平衡。虽然Google对可靠性非常看重，我们也必须要适应内部快速的变更频率。

正如前面几章提到的，我们的很多业务（例如搜索）都要在产品层面进行决策，来决定到底多么可靠才是“足够可靠”。

Google的软件产品和服务如果出现问题，并不会直接造成人身伤亡，这是一个优势。因此我们可以利用例如错误预算这样的工具来支撑快速创新的文化。

总的来说，Google已经采用了行业内部普遍采用的可靠性原则，并且创建了自己独特的文化。Google的这种文化可以满足内部对扩展性、复杂度、迭代速度以及高可靠性之间追求的平衡。

在深入讨论Google SRE的文化和实践时，我们很自然地会联想到其他行业是如何对待 可靠性这个问题的。借着编纂本书这个机会，我有幸和许多 Google 工程师一起讨论了 他们之前的工作经历，这些行业也非常注重可靠性。在讨论时，我的目标是回答下列几个问题 :

• SRE采用的指导思想是否在Google外部也有采用？甚至，其他行业是否在用截然不同 的方式解决高可靠性问题？
• 如果其他行业也采用同样的指导思想，那么具体对应的实践是什么样的？
• 不同行业之间的具体实践的相似点与不同点是什么？
• 是什么因素导致了这些相似点和不同点的产生？
• Google 以及科技行业可以从这些对比中学到什么？
  
  

在本文中，我们会讨论到许多 SRE 的核心指导思想。为了简化与其他行业最佳实践的比较，我们将这些理念分为 4 大类 :

• 灾难预案与演习
• 书写事后总结的文化
• 自动化与降低日常运维负载
• 结构化的、理智的决策
  
  

文中同时介绍了有其他行业经验的资深 SRE。我们一起讨论了关键的 SRE 思想，以 及这些思想是如何在 Google 内部应用的，同时也给出了其他行业内部应用这些思想的例子。最后，以一些模式和反模式作为结尾。

前言：有其他行业背景的资深 SRE

包括 Peter Dahl，Mike Doherty，Erik Gross，Gus Hartmann，Ron Heiby，Adrian Hilton，Eddie Kennedy ，John Li ，Dan Sheridan，Jeff Stevenson，Matthew Toia。

他们都是Google SRE，并且在加入Google之前，都有多年的其他行业背景。

编者注：这些人名都将出现在后文中，但考虑到实际相关度不大，因此略去了他们的背景介绍，以减少篇幅。更多详情请参考原书。

1、灾难预案与演习

“愿望不是一个策略”，Google 的 SRE 这条口号很好地总结了我们对灾难预案与演习的态度。SRE 的文化是永远保持警惕，不停地提出疑问：什么可能出现故障？在故障导致服务停止或者数据丢失之前我们如何避免？

我们的年度灾难恢复演习（DiRT）就是为了解决这个问题。在 DiRT 演习中，SRE 在生产环境中创造真正的问题， 以便能够 :

• 确保系统按我们预想的方式应对故障。
• 寻找系统中未预料到的弱点。
• 寻找其他提高系统鲁棒性的方式来避免事故发生。
  
  

在其他行业中，关于如何测试团队的灾难准备情况，以及保障团队应对灾难的能力的策 略有如下几个方面 :

• 从组织架构层面坚持不懈地对安全进行关注。
• 不放过任何细节。
• 冗余容量。
• 模拟以及进行线上灾难演习。
• 培训与考核。
• 对细节要求的收集与系统的设计超乎寻常的关注。
• 纵深防御。
  
  

1.1 从组织架构层面坚持不懈地对安全进行关注

该理念对工业工程来说格外重要。Eddie Kennedy 曾经在一个高危制造车间工作，随时面临着格外危险的环境，“每次管理会议都是以安全讨论开头。”

制造业通过建立极为确定的流程，以及保证整个组织从上至下严格对该流程的遵守来确保不会出现意外事故。

每个员工对安全的关注是很极为重要的，这样每个员工在他们发现出现问题时可以主动提出。在核动力行业、军用飞机，以及轨道交通信号系统行业中，软件的安全标准是明确定义的。

例如 UK Defense Standard 00-56、IEC 61508、IEC 513、US DO-178B/C、DO-254。 同时，这些系统的可靠性级别也都是明确定义的（安全整合级别（SIL）1-4）。

这些规定的目标都是为保障交付软件产品时候的质量。

1.2 对细节的关注

Jeff Stevenson回忆起在美国海军的任职经历，所有人对某些小任务执行过程中出现的粗心情况可能会导致大型潜艇事故的情况非常了解（例如，润滑油的及时补充）。

非常小的一个错误都可能产生极为严重的后果。

系统相互连接紧密，所以一个区域的事故可能会导致多个相关系统出现故障。核动力海军对日常常规维护非常重视，以确保小问题不 会发展成大事故。

1.3 冗余容量

系统利用率在通信行业中可能是非常难以预知的。系统容量可能会被无法提前预料的事件所影响，例如自然灾害等，又或者是大型的可预知的活动，例如奥林匹克竞赛。

在 Gus Hartmann的经历中，通信行业利用SOW（Switch on wheels），移动通信平台来提供冗余容量，以便应对这些情况。

这些额外的容量可以应急部署，也可以在某个大型事 件发生之前提前部署。同时，系统容量不仅仅是指系统的绝对容量，也和其他方面有关。

例如，某个明星的电话号码在2005年泄漏之后，数以千计的粉丝同时试图拨打这个电话， 整个通信系统陷入了一种类似 DDoS 的状态，造成了大面积的路由错误。

1.4 模拟以及线上灾难演习

Google 的灾难恢复团队在模拟与线上灾难演习方面与其他行业的关注点非常类似。

利用某种灾难情景可能导致的故障的严重程度来决定是使用模拟方式，还是线上方式进行演习。

例如，Matthew Toia指出，航空行业由于设备和人员安全因素无法进行真正的线 上测试。他们则部署了极为逼真的模拟器，这些模拟器使用线上真实数据。在测试中，控制室与设备在细节上与真实环境高度一致，以确保可以得到真实的测试数据。

Gus Hartmann 同时提到，通信行业一般采用线上演习模式，主要关注于应对飓风或者其他环境灾难。这种理念使得很多通信行业都建设了防水机房，同时内部带有可以运行超过飓风持续时间的发电机。

美国核动力海军会同时进行假想练习与真实的实战演习。

Jeff Stevenson说，实战演习包括“在可控环境下进行破坏”。实战演习每周进行，每次持续两到三天。对核动力海军来说， 假想练习是有用的，但是却不能真正防止灾难发生。灾难的响应机制必须要经过不断练 习才能确保不会忘记。

Mike Doherty，曾经的救生员，这个行业采用一种类似“神秘顾客”的方式进行灾难演习。

一般来说，设施负责人会和一个儿童，或者是某个正在接受训练的救生员一起构造一起伪落水事故。

这些情景会制造得非常逼真，救生员一般无法区分真实和虚构的紧急事故。

1.5 培训与考核

我们的座谈结果显示，培训与考核在涉及人身安全的行业极为重要。例如，Mike Doherty 描述了救生员如何通过非常严谨的培训考核过程，同时还要定期接受再考核。

培训课程包括健身部分（救生员必须能够将某个比自己还重的人托住，使得他们肩膀露 出水面），也包括技巧部分（例如急救和 CPR），同时还包括日常流程方面（例如，当某个救生员跳入水里时，其他团队成员应该做什么）。

每个设施都有当地特有的培训课程， 因为在游泳池里救人和在湖边或者海中救人有很大差异。

1.6 对详细的需求收集和系统设计的关注

与我们座谈的一些工程师讨论了详细的需求收集与设计文档的重要性。这些实践对医疗器械来说尤其重要。

在很多案例中，某个器械的使用情况或者维护情况与设计者的预想很不一样。因此，具体的使用情况与维护需求必须从其他来源获取到。

例如，根据Erik Gross的经验，激光视网膜手术设备被设计得极为简单明了，确保使用 它们的人不会出错。因此，从真正使用这些设备进行手术的医生处，以及维护这些设备的工程师处获取需求是很重要的。

在另一个例子里，Peter Dahl描述了国防系统中对设计高度重视的文化。构建新的国防设备甚至需要一整年的设计过程，最后的实际编码过 程只需要三周。

这两个例子与 Google 的发布迭代文化截然不同，我们更倾向于在计算过的风险性前提下，最大化迭代的速度。

其他行业（如上文提到的医疗行业和军用行业） 对风险的承受能力与我们区别很大，这就导致了他们采用的方案与 Google 截然不同。

1.7 纵深防御

在核能行业中，纵深防御是灾难预案中的一个关键元素。核反应 堆的所有系统都有冗余备份，同时在设计中，每个主要系统都强制备有后备系统。整个系统设计时加入了多层防护机制，包括最后的发电站核辐射物理屏障。纵深防御理念在核能行业中非常重要，因为他们对事故和灾难几乎是零容忍的。

2、事后总结的文化

纠正性和预防性操作（CAPA）是提升可靠性的一个常见概念。这意味着系统化关注于引起故障，或者带来风险的根源问题。

这与SRE“对事不对人”的事后总结理念非常一致。

当出现问题时（由于 Google 内部环境的海量环境、复杂程度，以及非常高的变化速度， 一定会有东西出现问题），详细考核下列问题是很重要的 :

• 究竟发生了什么？
• 响应的有效程度
• 下次是否可以采用其他方案解决问题
• 如何确保这次故障不会再次发生
  
  

这个过程在执行的时候不应该归责于任何一个个人，更重要的是，作为一个组织我们要找出什么出现了问题，以及如何确保问题不再发生。

纠结于“谁”造成了这个故障是没有意义的。

事后总结在每次事故发生之后都会进行，同时会在整个 SRE 团队内部传阅， 以便让所有人都能从中受益。

我们的座谈发现了很多行业也进行类似的事后总结活动（但是很多都不会用 Postmortem 这个词语来指代，因为这个词有验尸的意思）。但是，在不同的行业内部，他们进行事 后总结的原动力各有不同。

很多行业都受到政府部门的严密监管，出现问题时，会有相关的政府部门追责。这样监管在灾难预期后果严重的时候是更加紧密的（例如那些会造成人员伤亡的事故）。

相关的 政府监管部门包括 FCC（通信行业）、FAA（航空业）、OSHA（制造业与化工业）、FDA
（医疗器械），以及 欧盟中的数个 NCA 。核工业与运输业也被严密监管。

另外一个进行事后总结的动力是对安全的关注。在制造业与化工行业中，由于生产过程的危险性，员工伤亡的风险是一直存在的（高温、高压、有毒气体、腐蚀性液体等）。

例如， Aloca在安全问题上非常关注。前CEO Paul O’Neil要求员工在出现人员伤亡事故的24 小时内通知他。他甚至将自己家的电话号码直接分发给员工，这样一线员工可以在发现 安全问题时亲自联系他。

制造业与化工行业的危险性非常高，以至于“差点出事”——某个事件可能会造成严重伤亡，但是没有——这样的事件也会详细追究。这些场景成为了一种预防性的事后分析。根据 VM Brasseur 在 YAPCNA 2015 的一次演讲，

“在任何事故和业务灾难发生之前，类似事故都曾经发生过好几次，只是没有造成任何后果。这些事故在发生的时候都被忽略了。潜伏的错误，加上某个适合的时机，就会导致事故的发生。”

这种没出事的事故事实上就是一种潜伏的事故。例如，某个工人没有遵守标准的运营流程，或者某个工人在出现泄漏的时候躲开了，或者是台阶上的液体没有及时清理。

这些都意味着潜在事故的发生，以及学习和优化的机会。下一次，整个公司和员工可能就不 会这么幸运了。

英国的 CHIRP （航空与航海保密汇报机制）允许航空和航海行业的从业人员匿名汇报这类事故的发生，以在整个行业内部敲响警钟。关于这类差点出事的事故报告和分析会在周期性的杂志上刊登。

救生员行业也有一个根深蒂固的事后分析与计划文化。Mike Doherty 讽刺道：“如果救生员的脚踏入了水里，后续就要有很多报告要写。”在游泳池或者沙滩上出现的任何事 故都需要一个详细的事后总结。

对于严重的问题，团队还会集体从头到尾分析案例，讨论哪些行动是正确的哪些是错误的。接下来会根据这些讨论结果修改运营规则，同时还会组织培训帮助大家建立处理类似事故的信心和能力。在某次特别严重的或者创伤性的事故发生之后，甚至会有医疗顾问来帮助团队从精神创伤中恢复。

救生员可能已经尽力了，但是还是会感觉到他们做得不够。和 Google 类似，救生员行业也采用了对事不对人的事后分析机制。事故发生时总是非常混乱的，许多因素都可能影响事故的发生。

在这个领域中，指责某一个具体的人是没有意义的。

3、将重复性工作自动化，消除运维负载

Google SRE本质上还是软件工程师，他们对重复性的、被动性的工作十分反感。在我们的文化中强调避免反复执行一项重复性的工作。

如果一项工作可以自动进行，为什么还需要我们来重复执行呢?

自动化可以降低运维负载，同时节省工程师的时间。他们可用这些时间去主动改进服务的其他方面。

我们所调研的各个行业在对待自动化的问题上各有不同。某些行业信任人多过自动化。美国核动力海军通过一系列交叉管理流程来避免自动化。

例如，根据Jeff Stevenson的经历，操作某个阀门需要一个操作员、一个监督员，以及一个船员与负责监控该操作的工程负责人保持通话。这些操作过程是极为人工化的，因为担心自动化系统可能不会发 现人能注意到的问题。

潜艇上的操作是由一条信任的人工决策链管理的——一系列人，而非单独一个人。核动力海军同时担心自动化和计算机运行速度太快，以至于它们可能造成非常严重且无法挽回的问题。

当面对核反应堆时，缓慢而稳健的方法比快速完成任务更重要。

根据 John Li 的经验，私有化交易行业在近年来对自动化的应用越来越小心。经验证明，配置错误的自动化系统可能会在极短的时间内造成极大的财务损失。

在 2012 年，Knight Capital Group 遇到了一个“软件错误”，在几个小时之内造成了 4.4 亿美元的损失。

同样的，美国股票交易所2010年经历了一次闪电崩溃（Flash Crash），最终归责于一个交易商试图利用自动化方式操纵股市。虽然股票市场很快复原了，但是这次闪电崩溃在30分钟内造成了千亿美元的损失。

计算机能够非常快的执行操作，在这些操作配置错误的时候，速度反而是有害的。

相反，某些公司正是因为计算机比人要反应快得多而大量采用自动化。

根据 Eddie Kenned 的经验，效率与成本的节约在制造业中是非常关键的。自动化可以以更高的效率，更低的成本来完成这些工作。

而且，自动化通常比人工完成工作的重复性更强、更可靠，这意味着自动化可以产出更多高标准的产品。

Dan Sheridan讨论了部署于英国核能工业中的自动化机制。这里，采用的标准是如果整个发电站需要在少于30分钟的时间内响 应某种情况，那么这种响应必须要自动化进行。

在 Matt Toia 的经验中，航空行业有选择地采用自动化。例如后备系统的切换一般来说是自动进行的，但是在其他任务上，行业内部普遍要求人工进行二次校验。虽然整个行业内部采用了很多自动监控系统，实际的空中交通管理系统最终的实现还是需要人来校验 运行。

在Erik Gross的故事中，自动化机制在降低激光视网膜手术的过程中的用户错误是很有效的。在 LASIK 手术进行之前，医生需要进行屈光度测试。

在最初设计中，医生需要手 动输入数字，再按一个按钮，激光系统则会开始视力矫正过程。然而，数据输入错误的问题很严重。在这个流程中，可能会错误输入另外一个病人数据，甚至是左右两个眼睛 的数据搞混了。

自动化在这个环节中减少了这种错误带来影响的可能性。一个自动化的对输入数据的正确性检查是第一个改进：如果操作者输入了超出预期范围的数字，自动化程序会立刻自动提出警告。

其他自动化的改进包括：在操作环节中的虹膜照片会自动与屈光度测量环 节的虹膜图像进行对比，以防止数据混乱情况发生。当这种自动化解决方案最终实现时，这一类的问题就全部消失了。

4、结构化和理性的决策

在 Google 内部，尤其是 SRE 部门内部，数据是极为重要的。整个团队通过以下几种方式保障结构化和理性的决策过程 :

• 某项决策的基本方向是事先决定的，而不是事后得出的。
• 决策时考虑的信息源是清楚的。
• 任何假设都应该明确说明。
• 数据驱动决策要优于情感驱动的决策，直觉驱动的决策，以及资深人士的意见。
  
  

Google SRE 同时用以下列信息作为团队内部的基础要求 :

• 每个人都为服务的用户负责。
• 每个成员都能够根据可用的数据找出执行方案。
  
  

决策应该是通知式的，而不是指令式的，决策的过程不应该考虑个人意见——哪怕是最资深的成员。Eric Schmidt和Jonathan Rosenberg将之称为“HiPPO”——工资最高的员 工的意见。

其他行业中进行决策的过程有很多不同。我们了解到某些行业使用“如果没有坏，就永远不要试着修复它”这种理念来进行决策。这些在设计过程中投入很多思考与精力的行业有一个显著的特点——非常不愿意改变底层技术。

例如，通信行业仍然在使用 19 世纪80年代部署的远距离交换机。为什么他们要依赖几十年前的技术呢?因为这些交换机“基本上不会出错，同时冗余度非常高”，Gus Hartmann 解释道。Dan Sheridan 提到，核能行 业也类似。所有的决策都由一个想法驱动：“如果目前运行正常，那就不要修改它。”

很多行业都非常依赖手册与流程，而不是实时的故障排除。

任何人类能想到的故障场景都在一个检查列表中或者“大本子”里面记载了。当故障发生时，这些资料是进行操作的权威指南。

这种指令式的方式适用于那些发展和演进较慢的行业，因为故障场景不会 因为系统升级而快速变化。这种方式同时适用于那些员工技能水平较低的行业，这样确保员工在紧急情况中正确响应的方法就是提供一套简单清晰的指令集。

其他行业也会采用很清晰的、数据驱动的决策方式。在Eddie Kennedy的经验中，制造业中的一大特点就是试验文化，对构建和测试猜想非常关注。

这些行业经常性地进行某种可控的测试，保证某种变更不会导致结果的大幅度改变，确保没有意外情况发生。变 更只有在经过实验证明后才会实施。

最终，某些行业，例如交易行业，将决策划分成更小的块来更好地管理风险。根据JohnLi的经验，交易行业有一个专门的风险控制部门，独立于交易部门之外，负责确保不会在追求利益的同时承受不必要的风险。

这个风险控制部门负责监控交易场所内部，同时在交易发生意外的时候终止。如果某个系统发生异常情况，风险控制部门的第一反应是 关掉这个系统。John Li提到：“如果我们不在进行交易，那么我们就不会亏钱。

虽然我们也没有赚钱，但是起码不会亏钱。”只有风险控制部门可以将系统重新启用，不论交易员是否错失了某种可以赚钱的机会。

5、结论

Google SRE的很多核心思想在很多行业中都得到了验证。这些成功行业的很多经验教训可能启发了一些 Google 今天内部所使用的流程与实践。

在本次跨行业调研中最主要的一点结论是，与很多软件行业对比，Google 明显更倾向于变更的速度。

但是对变更速度的追求一定要考虑到故障发生时的影响。例如在核动力、民航，以及医疗行业中，如果造成事故可能会有人身伤亡。当故障的影响这么大时，采用更保守的方法是必要的。

在Google内部，我们经常在用户对高可靠性的预期与内部对快速变更和创新的追求之 间寻求平衡。虽然Google对可靠性非常看重，我们也必须要适应内部快速的变更频率。

正如前面几章提到的，我们的很多业务（例如搜索）都要在产品层面进行决策，来决定到底多么可靠才是“足够可靠”。

Google的软件产品和服务如果出现问题，并不会直接造成人身伤亡，这是一个优势。因此我们可以利用例如错误预算这样的工具来支撑快速创新的文化。

总的来说，Google已经采用了行业内部普遍采用的可靠性原则，并且创建了自己独特的文化。Google的这种文化可以满足内部对扩展性、复杂度、迭代速度以及高可靠性之间追求的平衡。