在 Google 教授一种新的预防故障的方法

作者：Garrett Holthaus, 技术作家

从小我就喜欢像侦探一样诊断和修复损坏的系统——对我来说是电子产品。让一台无声的收音机重新播放，有时只需要花费几美元更换零件，这让我感到非常满足。因此，在我大学毕业后的第一份工作中，从故障后分析转变为故障前分析并不算太大的转变，我成为了一名微处理器验证工程师。我通过在模拟器上运行测试来查找硬件错误，赶在芯片投入生产之前，避免了问题修复成本呈指数级增长。我永远记得那位资深工程师告诉我要戴上我的“邪恶”帽子，尝试通过抛出意想不到的情况来破坏芯片。但是，你如何提出意想不到的情况？更好的是，你如何知道从哪里开始寻找可能的问题？

现在我在 Google，这里的系统复杂性甚至更高，而 Site Reliability Engineers (SREs) 致力于在拥有数十亿用户的全球规模计算机上预防故障。值得庆幸的是，Google 在发现问题方面取得了越来越大的成功，因此可以在问题导致中断之前修复它们。我们正在使用 System Theoretic Process Analysis (STPA)，这是一种纸笔方法，自 2000 年代初创建以来，已在许多其他行业成功应用，用于分析纯软件系统并发现未知的未知（你未意识到且未主动寻找的风险）。

为了在 Google 扩展 STPA，我们需要更多专家接受过将 STPA 应用于 Google 软件系统的培训。在本文中，我将讨论 Google 定制内部 STPA 培训的开发，以及我们在纯软件环境中获得的 STPA 教育经验。

STPA 简介

STPA 使用系统和控制理论来建模复杂系统中的控制-反馈回路。它将系统安全视为一个控制问题，并寻找系统中控制行为可能导致系统进入不安全状态的所有方式。STPA 并没有试图想到所有可能立即导致中断的离散操作，然后尝试阻止它们，而是侧重于定义可能导致最坏情况下中断的不安全系统状态。通过采取这种方法来理解为什么会发生这些不安全的控制操作，STPA 使我们能够发现复杂的、意想不到的系统交互，而这通常是系统中断的原因。一旦我们了解了系统如何进入不安全状态，我们就可以设计和实施控制措施来防止这种情况，从而防止与不安全操作相关的中断。或者，我们可以检测到不安全状态并采取行动以恢复安全操作。如果自动校正不可行，我们至少可以提醒系统中的人员注意不安全的情况。

为什么 Google 需要定制 STPA 培训？

鉴于 Google 在运行 STPA 方面取得的成功——发现以前未知的问题并在它们导致中断之前修复它们——显然符合 Google 的利益，即开发更多的内部 STPA 专业知识并扩大我们的工作范围。目前有很多现有的 STPA 教育材料和许多外部顾问可以提供面对面的培训，那么为什么 Google 需要开发定制培训？要回答这个问题，我需要提供一些历史背景。

Google 的 STPA 培训始于 2021 年，最初面向 40 名感兴趣的 Google 员工开设了一个课程。兴趣和势头蔓延开来，我们决定开始基于现有材料举办讲师指导的培训课程。其他行业有很多引人注目的 STPA 示例——灾难故事以及应用 STPA 获得的令人大开眼界的经验教训。但是，当我们向 Google 观众展示这些物理系统的示例（例如 Mars Polar Lander crash）时，我们得到的回复是，“这很有趣，但我不明白它如何应用于我的纯软件系统。”因此，很明显我们需要一些软件示例，甚至更好的是，一些将 STPA 应用于 Google 系统的示例。

早期培训工作

即使有来自您自己行业或公司的示例，STPA 培训似乎也是一项艰巨的任务。成功应用 STPA 需要付出巨大的努力来学习该理论。然后，在您获得经验之前，您需要来自具有 STPA 经验的人的指导或指导。因此，我们决定从 STPA 的一部分开始，这部分可以独立存在——控制结构的概念，使用控制-反馈回路对系统建模。

图 1: 基本控制-反馈回路

基本控制-反馈回路包括一个控制器和一个受控过程。我们希望防止受控过程进入不安全状态。例如，我们可能希望将化学制造过程的温度保持在安全范围内。或者，受控过程可能是一个用户生成内容的数据库，例如业务评论，我们希望使其免受不正确或滥用的内容的影响。

控制器发出控制动作来改变受控过程的状态。因此，对于我们的数据库，控制器可能会发出一个控制动作来添加、更新或删除内容。但是控制器如何知道要发出什么控制动作？它知道是因为它对受控过程的当前状态有一些了解，并且它从反馈中获得这种了解。基于此反馈，它会更新其受控过程模型，然后应用算法（在本例中为软件算法）来确定要发出什么控制动作。

控制结构由许多这些基本控制回路组成，这些回路通过其控制动作和反馈路径相互连接。我们已经看到，仅仅是构建这个模型的行为就会导致设计思维的转变，从而包括系统级的反馈。虽然大多数软件开发人员在设计控制路径方面做得很好——即使没有控制理论的知识——但他们在设计反馈路径上花费的时间却很少（如果有的话！）。在向新团队介绍 STPA 时，我们经常在他们系统的控制结构中发现缺失或不足的反馈，这引发了关于如何改进他们设计的富有成果的讨论。

我们设计并进行了我们的控制结构培训。但是，我们发现教人们在有限的时间内创建一个有用的控制结构非常困难。特别是，教授正确的控制器抽象级别以实现有意义的分析对于为期 2 天的研讨会来说是一个主要的挑战。虽然我们研讨会的参与者有了一个坚实的开端，但需要时间、创建控制结构的经验以及专家的指导才能获得使用控制反馈回路对系统建模的技能。此外，虽然人们觉得这门课很有趣，但如果没有 STPA 的其他步骤（控制结构在发现设计缺陷和不安全的系统行为方面起着关键作用），它的吸引力就会降低。最后，也许最大的挑战是，初始班级的七名参与者为他们七个完全不同的软件系统构建了控制结构，而作为讲师，我们忙于学习关于每个复杂系统的足够信息，以提供有意义的反馈。

作为教育者的成长

在控制结构课程之后，我们决定教授 STPA 的所有步骤会更具吸引力和效果。我们的目标是让 Google 员工能够自己开始，为他们的系统运行 STPA。由于软件开发人员的初步努力，学习 STPA 并进行一些分析，当 STPA 专家加入时，事情会进展得更顺利。这种策略将能够更快地生成高质量的结果——即等待导致中断的系统设计问题列表，以及修复这些问题的建议。因此，我们开始为 STPA 的每个步骤构建一小时的课程。

如前所述，我们收到了足够多的关于非 Google STPA 示例的反馈，知道它们对我们的受众没有吸引力。因此，在构建新培训时，我们采用了一种通用方法：使用非 Google 示例来介绍每个 STPA 步骤的概念和流程，然后使用将该步骤应用于 Google 系统的真实示例进行跟进。我们对真实的 Google 示例给予了很好的赞扬，但我们也了解到了激励我们受众的其他信息。

了解什么激励我们的受众

当我们为更多的 Google 员工举办培训课程，与更多的 SRE 交谈，并为更多的团队领导 STPA 项目时，一些强大的主题开始涌现出来，这些主题始终引起我们受众的共鸣。第一个是之前提到的反馈概念。我们开始使用来自 Google STPA 的示例，其中反馈路径（或在某些情况下缺少反馈路径）导致了问题。有一些示例是关于从一个软件组件到另一个软件组件的反馈，但也有关于缺少或不完整地反馈给系统中人类的示例。

在 Google 的一个特定案例中，一个软件控制器——根据来自另一个软件系统的错误反馈——确定它应该发出一个不安全的控制动作。它安排了这个动作在 30 天后发生。即使有迹象表明这种不安全的动作将会发生，但没有软件工程师——人类——实际上在监视这些迹象。因此，30 天后，发生了不安全的控制动作，导致了中断。在这次中断中，存在两个反馈问题——从一个软件到另一个软件的错误反馈，以及从软件到工程师的缺失反馈。我们已经使用 STPA 分析了几次涉及缺失或不正确反馈给人类的中断。与这次中断一样，不安全的情况存在了 30 天，如果系统中的人员被告知一些不安全的系统状态，那么许多其他中断本可以很容易地避免。这是 STPA 的核心原则之一——如果您专注于预防（或至少检测）导致中断的不安全系统状态，那么您更有可能预防中断。

我们一次又一次地从其他 Google 员工那里听说，这些例子已经导致他们对系统设计的方法发生了转变。不仅关注控制路径，还关注反馈路径，导致人们更加意识到与其他部件交互的其他软件基础设施。例如，人们开始问：“如果该系统传递给我错误或不完整的信息，或者没有在正确的时间将信息传递给我的系统怎么办？”而不是假设邻近系统始终表现完美。Ariane 5 火箭是软件反馈问题的一个著名例子，它在首次发射时偏离航向并自毁。代码中的许多变量中有一个浮点值代表火箭的方向。这非常合理，但埋藏在代码中的是从一个软件到另一个软件的切换——反馈——接收软件将该值解释为 16 位整数。设计人员对使用整数数学的系统软件的这一接收部分充满信心，因为它在 Ariane 4 中运行得非常好。系统思维会引导设计人员提出诸如“如果我由于从相邻软件系统传递的值而获得整数错误会发生什么？”之类的问题。在 Ariane 5 的案例中，一个结论是，这种类型的错误使得将接收到的值解释为真实的火箭方向是不安全的，而这实际上在灾难中发生了。

数据流图 vs. 控制结构

鉴于在 Google 的 STPA 中经常出现不充分或缺失的反馈，并且考虑到反馈经常给系统设计人员留下深刻的印象，我们改变了我们的信息传递方式。我们开始专注于 STPA 的能力，不仅可以分析控制路径，还可以分析反馈路径——这是软件设计的一部分，正如我们所见，通常很少受到关注（如果有的话）。

对反馈的关注自然发生在 STPA 中，因为我们将系统建模为控制结构——几个控制回路通过控制动作和反馈连接。这种类型的系统模型与软件设计中经常使用的另一种模型数据流图形成鲜明对比。这些图显示了数据如何在不同的软件组件之间移动，例如通过远程过程调用。与控制结构不同，数据流图不指示数据是控制还是反馈。它们也没有建立控制层次结构——哪些软件控制其他软件的状态。由于控制结构显示了这种层次结构，因此它们通常被称为分层控制结构。对于由数百万行代码组成的软件系统，数据流图可能非常复杂。

图 2: 示例数据流图——缺陷在哪里？

在本文的开头，我提到在复杂系统中开始查找问题的位置通常并不明显。如果要求您分析上面的数据流图——33 个盒子，上面有相互连接的箭头组成的蜘蛛网——您将如何确定由于复杂的系统交互可能发生哪些中断？例如，图表底部和顶部的许多框只有指向它们的箭头，没有指向它们的箭头。如果这些软件组件出现故障，将如何影响系统？即使这些组件都没有出现故障，我们如何知道由于组件之间无法预见的复杂交互不会发生中断？如果您不知道这些软件组件的功能，就很难说。更糟糕的是，与典型的软件系统复杂性相比，尤其是在 Google，此示例数据流图相对简单。

图 3: 示例控制结构

使用控制结构来建模系统中的控制-反馈关系可以实现一种抽象级别，从而使这种分析——搜索可能导致中断的复杂系统交互——变得可行。Google 系统的典型控制结构有 10-15 个盒子，即使盒子更少也可以进行有意义的分析。上面的控制结构只有 4 个盒子，来自一个真实的 Google STPA。在与系统专家合作构建此控制结构之后，我们立即注意到从控制器 C 到控制器 B 缺少反馈——换句话说，控制器 B 没有足够的信息来支持它需要做出的决策。当我们继续运行 STPA 时，我们还发现其他可能导致中断的系统设计问题。

控制结构清楚地表明了每个软件控制器的目标是什么，它控制哪些其他软件以及它从哪里获得反馈。每个箭头都标有在系统不同部分之间传递的控制动作或反馈，从而可以很容易地看出每个控制器是否获得了发出正确控制动作所需的信息。最重要的是，我们可以列出特定控制动作不安全的情况，从而导致不安全的系统状态并可能导致中断。

再次，在培训和与许多不同的 Google 员工合作创建控制结构的过程中，我们提出了一个令人信服的信息：在应用 STPA 的过程中，您实际上是将搜索问题的范围从数百万行代码缩小到数百行。这是通过识别软件中哪些决策会导致不安全行为来实现的。我们通过构建导致不安全控制动作的场景来实现这一点——这些场景实际上指向了导致可能中断的代码行！

总结

感谢在我们的培训中加入真实的 Google 示例，并找到正确的信息来吸引和激励我们的受众，我们受到了 Google 更多团队的关注。此外，反馈持续朝着积极的方向发展。一位参与者说：

“课程本身的结构非常好。我过去几年听说过 STPA，但这是我第一次看到它用具体的例子来解释。最后的 Google 示例也真的很有帮助。”

一个团队甚至要求举办一个定制的研讨会，以在他们的系统上运行一个小型 STPA。在我们构建培训的过程中，一个主要的成就是一个新的为期三天的研讨会，该研讨会不仅关注控制结构，还关注 STPA 的所有步骤，并围绕另一个真实的 Google 示例构建。但是，现在我们遇到了一些新的挑战。

第一个挑战是，尽管兴趣很高，并且注册在宣布第一个研讨会后的几天内就已完成，但只有大约一半的注册者参加了。这可能归因于为培训预算三天的困难。为了应对这一挑战，我们决定采用分步方法。我们开发了两个 30 分钟和 60 分钟的 STPA 教程，同样基于真实的 Google 示例构建，展示了有影响力的结果。在每个教程的结尾，我们宣传了研讨会。目标是通过这些教程尽可能多地接触到人（在您的一天中找到 30 分钟比找到几个小时更容易），然后让与会者自我选择参加研讨会——这些最初教程中最有动力的人将注册参加研讨会并实际参加。

第二个挑战是，尽管参加研讨会的人喜欢它并表示对 STPA 的持续兴趣，但在大多数情况下，他们实际上并没有尝试在自己的系统上运行 STPA。这使我们进入了 Google STPA 培训开发的最新阶段：我们正在构建一个自助服务的内部研讨会版本，其中包含一系列短录音，包括家庭作业。当 Google 员工观看视频时，他们将填写带有额外指导的模板，以开始在自己的系统上运行 STPA。我们希望通过增量工作并在观看相应的培训视频后立即完成 STPA 的每个部分，可以减少恐惧感。到 Google 员工完成研讨会时，他们将对自己的系统中的 STPA 有一个良好的开端，并且如前所述，这将允许在 STPA 专家加入分析时快速生成高质量的结果。更好的是，我们可以将自选原则提高一个级别，并有望找到 Google 的下一批 STPA 专家——早期采用者，他们将通过向他们各自的团队宣传来帮助在 Google 扩展 STPA。

你也可以做到！

您对 STPA 了解得越多，看到 STPA 成功应用于您的业务或行业的结果越多，您就越意识到您不能不使用它。它是应对当今日益复杂的系统中无处不在的未知事物的有力工具。从一些个人或一个小团队引入一位专家 STPA 引导者来指导您公司的第一个 STPA，您可以建立意识和专业知识，并扩展 STPA 的使用，正如许多其他人所做的那样。对于希望采用 STPA 的软件公司，没有替代方法可以基于实际软件示例构建内部培训——这将使您的软件工程师真正看到 STPA 的好处并致力于学习该过程。是的，一路上会遇到挑战，就像 Google 所面临的那样，但请记住——大多数软件公司都非常擅长调整以应对不断变化的优先级和策略。如果您的 STPA 培训失败，请调整并重试！在您意识到这一点之前，您将获得改进系统可靠性和安全性的好处。

有关 SRE 在 Google 采用 STPA 的更多详细信息、STPA 背后的理论以及 Google STPA 应用的案例研究，请参阅“The Evolution of SRE at Google.”