SRE 系列（第4篇）：Google STAMP框架引领可靠性工程新范式

Google 的 SRE 团队开创了通过在堆栈的每个部分工程化可靠性来保持故障罕见的方法。SRE 们已经扩展了让我们走得很远的方法——服务等级目标（SLOs）、错误预算、隔离策略、彻底的事后分析、渐进式推出和其他技术。

面对日益增加的系统复杂性和新兴挑战，Google 总是在问自己：下一步是什么？我们如何继续推动可靠性和安全性的边界？

随着AI和ML系统的普及，以及我们对这些系统的依赖程度的提高，传统的SRE方法面临着越来越大的挑战。SLO（服务水平目标）和错误预算等概念已经不足以应对当今复杂系统的需求，特别是在零容忍失败的场景中。

1 传统 SRE 方法的局限性

像错误预算这样的想法在基本上是无状态的 Web 服务的产品中运行良好，但今天我们的产品有绝不能发生的损失——零错误预算。我们需要预防的故障类型已经超出了错误预算能够有效解决的范围。像隐私泄露、数据丢失和法规合规这样的问题需要绝对预防，而不仅仅是低频率和快速缓解。

除了这些提高的期望外，我们的系统每年也变得更加复杂。复杂的自动化使我们能够扩展，AI 和 ML 现在几乎是我们构建的每个产品的核心，成本和能源效率与用户可见的功能同样重要。

SRE 一直致力于不仅仅是响应故障，而是预见和预防它们。但在 Google 这个以历史上最大代码库之一定义的系统中，预见故障被证明是极其困难的。而 AI 只是在增加这个挑战。

SRE如何理解和管理我们系统日益增加的复杂性，在它们发生之前预见潜在的故障，并从零开始设计更安全、更可靠的系统？

2 新的答案：STAMP 框架

答案在于范式转变。系统理论、控制理论及其通过系统思维解决问题的应用，为 SRE 提供了一种理解和管理复杂性的方法，一直到 Google 的行星规模系统。SRE 的未来将使用系统理论方法在 AI 时代提供全面、高效和有效的结果。

Google SRE 已经接受了系统理论和控制理论。我们采用了由 MIT 的 Nancy Leveson 教授开发的 STAMP（系统理论事故模型和过程）框架，该框架将重点从防止单个组件故障转移到理解和管理复杂的系统交互。STAMP 包含了像基于系统理论的因果分析（CAST）用于事后调查和系统理论过程分析（STPA）用于危险分析等工具。

STAMP基于控制理论，提出了一种不同的事故模型。在STAMP中，事故被视为控制不足或不适当的控制的结果，而不仅仅是组件故障的结果。

3 控制理论的四个基本条件

在《控制论导论》中，W.R. Ashby 阐述了控制的基本要求，Leveson 后来将这些要求纳入了她的 STAMP 方法论：

1. 目标条件控制器必须有一个或多个目标（例如，维持设定点）
2. 行动条件控制器必须能够影响系统的状态
3. 模型条件控制器必须是（或包含）系统的模型
4. 可观察性条件控制器必须能够确定系统的状态

这四个条件为思考复杂系统中的控制提供了一种结构化的方式。

当将 STAMP 应用于我们的 SRE 实践时，我们可以使用这些条件作为检查清单，以确保我们具备有效控制的必要元素。

4 从线性因果到系统控制

传统的事故分析往往将中断视为线性事件链的结果。但 STAMP 将我们对事故的视角从线性故障事件链转变为控制问题。

我们不是问"什么软件服务失败了？"而是问"系统各部分之间的什么交互没有得到充分控制？"

「在复杂系统中，大多数事故来自所有按设计运行的组件之间的交互，但集体产生了不安全状态。」

在复杂系统中，大多数事故来自所有按设计运行的组件之间的交互，但集体产生了不安全状态。

5 危险状态：给工程师更多时间

STAMP 在系统层面将事故概念形式化为危险状态。"危险是系统状态或条件集，与特定的最坏情况环境条件集一起，将导致损失。"

危险状态不是离散事件，而是整个系统的一个属性，系统可以在事故发生前处于危险状态很长时间。这给了工程师在试图预防中断时一个更大的瞄准目标。

危险状态不是离散事件，而是整个系统的一个属性，系统可以在事故发生前处于危险状态很长时间。

6 真实案例：2021 年 Google 配额调整器事件

一个具体案例发生在 2021 年的 Google。我们为在基础设施上运行的某些内部软件设置和强制执行资源配额。为了最大化效率，我们还监控每个服务使用其配额的多少。如果一个服务持续使用比其配额少的资源，我们会自动减少配额。

在 STPA 术语中，这个配额调整器有一个控制行动来减少服务的配额。从安全角度来看，我们问这个行动什么时候会不安全。

如果调整器将服务的配额减少到低于该服务的实际需求，那将是不安全的——服务将资源不足。

STPA分析系统中的每个交互，以全面确定交互必须如何控制才能使系统安全。不安全控制行动导致系统进入一个或多个危险状态，只有四种可能类型的UCA：

1. 没有提供必需的控制行动
2. 提供了不正确或不充分的控制行动
3. 在错误的时间或错误的顺序提供了控制行动
4. 控制行动停止得太早或应用得太久

通过查看系统层面并以控制-反馈循环的方式建模系统，我们在控制路径和反馈路径中都发现了问题。

7 STPA 的优势

当在越来越多的系统上运行STPA时，我们看到反馈路径通常比控制路径理解得较少，但从系统安全角度来看同样重要。

在 2021 年的事故中，关于Google基础设施中关键服务使用的资源的不正确反馈被发送给调整器。调整器计算了新的配额，分配了比服务实际使用少得多的资源。作为预防措施，这个配额减少没有立即应用，而是保持了几周时间。

整个系统处于危险状态几周，但因为我们没有寻找它，我们错过了预防随后损失的机会。几周后，配额减少被应用，导致了重大中断。

正如Leveson在《构建更安全的世界》中所写：『在 STAMP 中，理解为什么事故发生需要确定为什么控制无效。预防未来的事故需要从专注于防止故障转移到更广泛的目标，即设计和实施将强制执行必要约束的控制。』

8 展望未来

与其将复杂性视为错误，Google的SRE团队正在利用控制理论以及STPA和CAST等方法，引导我们走向更全面和主动的可靠性方法，超越简单地响应故障，从零开始主动设计更安全的系统。

SRE向系统安全方法的演进为我们的工程师提供了一种全新的方式来理解我们构建的系统，并为它们的工作方式提供了更强的保证。

我们已经用STPA分析了Google一些最复杂的系统，并且用相对较少的努力（想想：每次分析工程师周的工作），我们发现了数百个具有广泛影响的场景。

GoogleSRE的成功一直归功于那些每周工作(24X7)，以确保Google产品在规模上工作的非常有才华的工程师。奉献精神、独创性和大量辛勤工作使Google的产品成为高可靠性和性能的基准。

复杂性无处不在增加，Google的工程师将准备好面对它，以便在下一个时代提供同样卓越的性能。

思考题：在您的系统中，是否也存在类似的复杂交互问题？传统的SRE方法是否已经无法满足您对系统可靠性的要求？