Sam Newman 谈如何构建高韧性 AI 软件并应对故障

上周播客的嘉宾是Sam Newman，他出版了一本我个人期待已久的书，名为Building Resilient Distributed Systems。对我们许多软件工程师来说，这是一本特别及时的书，因为我们看到几乎所有服务和系统都出现了更多故障——其中很大一部分原因是 AI 代理编写了更多代码，导致更多代码部署；以及更多 bug 在生产环境中引发更多事故。

Sam 的书“刚出炉”，自然也会涉及在我们设计弹性系统时 AI 带来了哪些变化。事实上，Sam 告诉我，他总共花了三年时间才完成这本书——而不是最初计划的两年——因为他回过头来重写了书中的所有部分，更新了与 AI 相关的内容。

我问 Sam 是否愿意分享书中的一段摘录，其中的章节对任何构建应当可靠的系统的人尤其相关。Sam 慷慨地同意了，今天的内容涵盖了几个重要主题，分布在他书中的两章里。我们涉及：

1. 灾难恢复（DR）。从灾难性故障中恢复：为云区域/数据中心/站点级中断做规划，RPO 和 RTO 的概念，DRO 目标和 SLO。

2. 灾难恢复模式。备份与恢复、预热备用故障转移、温备用故障转移和多站点主动-主动。

3. 规划 DR 时的基础设施可用性。持续的 GPU 和 CPU 短缺意味着你不能指望基础设施随时可用，因此你需要了解供应商的约束，并优先保障关键服务。

4. AI 驱动软件的弹性。模型提供商的弹性、模型变化的挑战，以及可观测性的需求。

5. 如何处理不确定性。诸如多模型和多供应商、让成本透明化，以及频繁分析供应商等策略。

尽管这篇文章相当长，但我们涵盖的内容还不到这本书 16 章中完整的一章。如果你以构建可靠系统为生，我热情推荐这本书本身，你可以从出版商处获取。

我一贯的免责声明：与我所有的推荐一样，我没有因推荐这本书而获得报酬，也没有任何链接是联盟链接。更多详情请参阅我的道德声明。

以下摘录来自 Sam Newman 的Building Resilient Distributed Systems。版权所有 © 2026 Sam Newman。由 O’Reilly Media, Inc. 出版。经许可使用。

1. 灾难恢复

摘自第 10 章：灾难恢复。

我们已经讨论了如何处理影响单个服务实例的各种故障。但当灾难性故障导致系统大部分区域大面积中断时，会发生什么？火灾、洪水、电力供应问题以及底层云基础设施中的错误都超出你的控制范围，它们可能一下子让你为使系统更健壮所做的努力完全付诸东流。

处理这些情况属于灾难恢复（DR）的范畴，这是一套在真正糟糕的事情发生时应启动的流程。正如我们在本书中探讨的许多内容一样，权衡无处不在。当你缩短可接受的停机时间或数据丢失时间时，成本和复杂性就会增加，因此为你的系统选择正确的方法可能是一项微妙的平衡工作。在本章中，我将为你提供一些具体的目标，以帮助你推动自己的 DR 方法。

云区域、数据中心还是站点？

你用来讨论基础设施的确切术语可能会因实现细节而有所不同，这反过来又会使围绕普遍适用模式的讨论变得更加困难。例如，在公共云上运行时，你可能熟悉云区域的概念，即你的云资源所在的地方。在私有云或更传统的本地部署环境中运行时，你则会从数据中心的角度来思考。

当我们讨论处理 DR 的各种选项时，我们将在本章后面看到的模式可用于公共云或私有云场景。因此，为简单起见，我将使用术语“站点”作为你的计算基础设施所在位置的一般描述。

在 DR 策略中混合使用云供应商有一些具体问题需要考虑，我们将在第 11 章中进一步探讨这些问题。

你的 DR 需要做到多好？

你可以选择多种 DR 方案，它们在成本、复杂性和恢复方面差异很大。为了帮助你决定哪种 DR 方法最合适，我们应该首先尝试了解如何为你的具体情况确定适当的需求。

定义 DR 技术要求的一种简单方法是使用两个具体的可衡量目标：恢复点目标和恢复时间目标。在图 10-1 中，你可以看到这些目标与事件的关系：

恢复点目标

恢复点目标（RPO）定义了自数据上次备份或同步以来可能经过的最长时间。换句话说，RPO 定义了潜在数据丢失的上限时长。如果你的系统数据每小时备份一次，那么当系统发生事件时，最多可能丢失一小时的数据。因此，你的 RPO 就是一小时。

恢复时间目标

恢复时间目标（RTO）定义了在事件发生后，你的系统可以不可用多长时间。如果你所有的计算机都不可用，也许是因为整个数据中心的中断，那么你在另一个数据中心让服务运行起来需要多长时间？你的 RTO 包括从上一个恢复点恢复数据、为工作负载提供计算资源以及将流量重定向到新站点所需的所有时间——因此，在让系统重新上线方面，需要考虑的变量不仅仅是时间。

你不可能什么都想要

如果在真空中被问及你想要什么样的 RPO 和 RTO，你可能会给出一个非常简单的答案：你想要零 RPO（即保证无数据丢失），也想要零 RTO。这是一个可以理解的愿望，但当你降低 RPO 和 RTO 时，成本和复杂性会急剧增加——而且从技术上讲，无论如何都无法保证零 RPO 或 RTO。

另一个复杂之处在于，不同类型的工作负载可能需要不同的 RPO 和 RTO。以银行为例。拥有较低的 RPO 以确保支付信息不丢失是关键，而拥有较低的 RTO 以确保人们仍能从账户中取钱则至关重要。另一方面，允许新客户注册账户的系统部分可以拥有较高的 RTO 和 RPO，因为对业务的影响不那么严重。

因此，在决定合适的 RPO 和 RTO 时，需要与利益相关者就最终用户需求以及监管和立法要求进行讨论，并将其与实施所需解决方案的成本和复杂性进行权衡。例如，你的产品负责人最初可能会说他们需要 10 分钟的 RPO，但如果你能告诉他们实施起来需要数月的工作（在此期间其他工作必须被降低优先级），他们可能会降低目标，也许接受一个对你来说更容易交付的 RPO。你的目标 RPO 和 RTO 还应超过你所签订的任何服务级别协议中规定的任何值。

灾难恢复目标与 SLO

乍一看，RPO 和 RTO 似乎很适合作为服务级别目标（SLO）。毕竟，它们都是直接影响用户体验的重要指标。然而，将 RPO 和 RTO 作为 SLO 来管理存在一些挑战。

在确定我们是否达到某个 SLO 时，我们需要收集大量服务级别指标（SLI）来确认我们是否达标。因此，如果我们有一个 SLO 定义了一个月期间第 99 百分位延迟低于 500 毫秒，我们就会分析那个月期间与延迟相关的 SLI，以确保我们达到了目标。然而，对于 RPO 和 RTO，我们的 SLI 会是什么呢？

现实情况是，我们不会经常经历灾难，因此无法收集有用的 SLI。我们当然可以围绕与灾难恢复方法相关的事项定义相关的 SLO。例如，可以围绕数据复制的速度定义一个 SLO，因为这是我们在生产环境中正在做的事情，并且可以通过编程方式进行测量。但充其量，SLO 只是间接地衡量 RPO 和 RTO。

因此，RPO 和 RTO 并不真正契合 SLO 的概念。当然，这并不意味着你不能仍然测试你的系统以确保它实现了你的灾难恢复目标——我们将在本章后面进一步讨论这一点。

4. 灾难恢复模式

摘自第 10 章：灾难恢复的另一段摘录。

考虑到关于 RPO 和 RTO 的讨论，让我们来看看在重大事件发生后用于实施灾难恢复的一些常见模式。在图 10-2 中，我们可以看到我们将要探讨的四种模式的概述，大致按照复杂性和 RTO、RPO 改善程度递增的顺序排列。

如果从头开始，这些模式中的许多可以相互构建，允许你随着时间的推移逐步增加灾难恢复解决方案的复杂性（和成本）。例如，备份和恢复方法需要重新路由，热备模式会增加跨站点数据复制和基础设施自动化的需求，而温备故障转移则增加了准备好一些基础设施的成本。因此，如果你不确定从哪里开始，按照图 10-2 中从左到右的顺序逐一了解这些模式是非常有意义的。

如果你的系统不同部分有不同的 RPO 和 RTO，你可能最终也会混合使用这些模式。请注意，它们都需要某种形式的流量重路由，并且大多数需要某种形式的跨站点数据复制。这些选项将在本章后面讨论。

模式：备份和恢复

通过从备份中恢复数据并将其加载到替换系统中来进行恢复。

如图 10-3 所示，使用此模式时，数据会定期备份到单独的站点。如果主站点发生故障，需要在新站点提供基础设施，并恢复备份的数据。

工作原理

此模式实现起来非常简单，包含几个步骤：

1. 定期备份数据。

你希望提供给故障转移站点的所有数据都需要定期备份，备份数据存储在除主站点以外的某个地方。

2. 在故障转移站点上配置基础设施。

这最好是自动化的，因为手动配置基础设施可能会导致更长的 RTO 和更高的出错几率。

3. 将数据从备份恢复到故障转移站点。

数据从备份位置加载到新配置的基础设施中。

4. 将流量从主站点切换到故障转移站点。

一旦基础设施可用且数据已恢复，就可以将流量切换到辅助站点。

理想情况下，你的故障转移站点运行与主站点相同的核心技术栈，这意味着你在主站点上对基础设施自动化的任何投入也可以用于故障转移站点（例如，能够重用 Terraform 脚本）。保持用于自动化主站点和故障转移站点设置的代码相同非常有用，因为这意味着你对在故障转移站点上启动基础设施能够正常工作会有更高的信心。如果你的故障转移站点使用不同的技术栈——意味着无法在主站点和辅助站点之间共享自动化基础设施配置代码——那么定期测试你的 DR 故障转移流程就变得更加至关重要。按需启动基础设施的一个注意事项是保证在你需要时基础设施确实可用，我们将在本章后面探讨这一点。

何时使用它

此模式通常适用于主站点不可用且你可以容忍较长 RTO 的情况，尤其是在那些希望保持低成本的情况下。需要注意的是，定期测试备份和恢复流程是必要的，以确保它确实有效。我发现一个有用的方法是将备份和恢复到辅助站点作为其他常规活动的一部分来执行（例如，定期的负载测试演练）。

这种模式的 RPO 取决于备份频率。RTO 将是我们将要考察的模式中最长的，其时间主要取决于从备份恢复数据和配置替换资源所需的时间。在完全自动化流程和较小数据量的情况下，这可能在几分钟到几小时的范围内。手动恢复流程很可能会大大延长这些时间线，所涉及备份的大小也会如此——数 TB 的数据比数 GB 的数据传输时间更长！另一个主要因素是所需计算资源的可用性。如果你最终不得不购买替换设备，这种模式很容易导致时间线长达数周或更长。

模式：Pilot Light 故障转移

数据持续同步到故障转移站点，故障转移后配置基础设施。

在 pilot light 设置中，数据会从主站点持续复制到故障转移站点，如图 10-4 所示。在需要故障转移之前不会配置基础设施，从而确保在使用公有云基础设施时能够降低成本。

工作原理

这种模式建立在备份和恢复所做的大量工作之上，主要变化是数据会持续同步到故障转移站点。因此，所涉及的步骤看起来与备份和恢复模式相当相似：

1. 持续复制数据。

当数据提交到主站点时，它会持续复制到故障转移站点。这可以通过多种方式完成，例如利用原生数据库技术或应用层复制。

2. 在故障转移站点配置基础设施。

假设数据库和数据存储已经存在于故障转移站点，因此只需要配置计算等剩余资源。

3. 将流量从主站点切换到故障转移站点。

一旦基础设施可用且数据已恢复，就可以将流量切换到故障转移站点。

从实现的角度来看，新的复杂性来源是从主站点到故障转移站点的数据复制。对于在设计时就考虑到这一流程的系统来说，实现起来可能相当简单。然而，在改造现有系统时，如果你使用的数据产品不原生支持这种复制策略，事情就会变得更加复杂。这值得在本章后面进行更深入的讨论，尤其是接下来的两种模式也依赖这一能力。

何时使用

与备份和恢复相比，pilot light 故障转移由于数据复制更频繁，可以实现更短的 RPO，同时通过消除数据恢复所需的时间来降低 RTO。

Pilot light 故障转移的成本节约只有在公有云的背景下才真正有意义。成本降低主要体现在除非使用否则无需为基础设施付费。但如果你的故障转移站点是你自己的私有基础设施，无论是否使用都必须付费，那么某种形式的温故障转移就更有意义。到那时，你已经在为硬件付费，所以不妨使用它。

模式：温故障转移

数据同步到故障转移站点，至少已配置一些基础设施来处理流量。

如图 10-5 所示，在温故障转移中，数据会持续从主站点复制到故障转移站点，并且在故障转移本身发生之前，至少已有部分基础设施预先配置好。

即使在故障转移发生之前就已配置部分基础设施，也能缩短某些功能的 RTO。故障转移站点上配置多少基础设施可以有所不同，但其思路是已经存在一些容量，从而实现更快的故障转移。

一种常见做法是优先在次要站点上为系统更关键的能力提供一部分基础设施，从而为最重要的功能缩短 RTO。

冷、温、热故障转移：这里有必要对“温”这个术语做一点简要说明。你会发现各种解决方案和厂商产品都承诺提供冷、温或热故障转移，而这些术语之间唯一真正的区别往往在于：与温故障转移相比，热故障转移能提供更低的 RTO；而与冷故障转移相比，温故障转移能提供更低的 RTO。鉴于不同厂商、不同技术栈对“热”或“温”的定义差异极大，我干脆选择“温”并一直沿用。

给事物命名很难。

本摘录省略了“工作原理”和“何时使用”部分，但这些内容在书中是有的。

模式：多站点主动-主动

系统分布在两个或多个站点上，写入可以发送到任意站点。

在多站点主动-主动设置中，数据会在两个或多个站点之间持续复制，如图 10-6 所示。任何客户的流量都可以在任何时间由任意站点提供服务。

这种模式绕开了对故障转移的需求，因为其假设任何用户的流量都可以随时在站点之间切换。因此，它提供了我们目前所看到的所有模式中最低的 RTO 和 RPO，但代价是更高的成本和复杂性。

本摘录省略了“工作原理”和“何时使用”部分，但这些内容在书中是有的。

3. 规划 DR 时的基础设施可用性

同样摘自第 10 章：灾难恢复。

在撰写本文时，GenAI 正被越来越多的行业使用。无论你如何看待这项技术的实用性（或其更广泛的社会影响），用于训练和推理的 GenAI 工作负载的性质都推动了对基础设施日益增长的需求，进而导致许多用户可用容量减少。即使你并未运行自认为属于专业化的 GenAI 工作负载（例如需要特定 GPU 的工作负载），也很可能会更广泛地感受到这些短缺带来的影响。

除了 GPU 成本不断上涨之外，内存在 2025 年和 2026 年也大幅飙升，影响了通用服务器的可用性。我已经与一些客户交流过，他们在一些大型公有云提供商上运行“普通”（非 AI）工作负载时举步维艰，因为他们无法获得足够的容量。在某些情况下，能够切换区域会有所帮助，但对未来可用性的保障似乎相当薄弱。即使购买自己的硬件似乎也不是快速解决办法，因为服务器的交付周期似乎每周都在进一步延长。

在考虑前面详述的模式时，必须将这一点纳入考量。如果你选择的方案假设在发生故障时可以动态配置基础设施，那么你就必须审视自己对于所需容量有哪些保障。在大型云厂商的某个区域发生故障的场景中，你可能会发现自己正在与其他所有人争夺残羹剩饭。

处理这种场景有三种方式：预留容量；优先保障关键服务；或者最后一种，考虑始终运行一套完全冗余的基础设施。

并非每个厂商都提供预留容量的能力，而且即便提供，也仅限于某些云服务。例如在 AWS 上，你可以付费来保证在需要时获得 EC2 实例（托管虚拟机）的可用性。这会产生成本影响，因为无论你是否使用这些实例，都要为预留付费（好的一面是，如果你最终确实使用了它们，成本会比正常的按需定价更便宜）。不过，当你使用无法预留的云资源时，这并不能帮到你——例如，你无法购买 Lambda 调用的有保障可用性。

接下来，考虑优先保障关键服务。如果保障可用性需要付出成本（或者只有有限的基础设施可用），那么至关重要的是将其分配给关键性更高的工作负载。这正是按服务逐一设置不同 RTO 和 RPO 发挥作用的地方。

最后，如果你能够证明拥有一套随时可运行系统的完全冗余基础设施所带来的复杂性和费用是合理的，那么你就会有信心认为自己的计算资源将可用，但前提是这一选项可能极其昂贵。不过，如果你能对冗余资源加以替代利用，这种成本就可以被缓解。

回到第 4 章，我提到了 BankCo，我们在那里跨一大群机器运行计算。这些计算机中有很大一部分是闲置在伦敦郊外一间办公室里的台式 PC。这些 PC 构成了该银行灾难恢复（DR）策略的一部分：一旦交易员不得不撤离银行主址，他们可以转移到备用站点继续工作。要求这些备用 PC 持续运行，以确保我们知道它们能正常工作，并且可以向它们推送更新。这显然是在大多数关键工作还依赖胖客户端应用、因此无法通过 Web 访问的年代。

我们能够利用这些 DR 工作站来扩大可用工作节点的池子。这意味着当 DR 站点未投入运行时（大多数时候都是如此），我们能够更快地完成计算，因为我们可以将工作并行化到更多机器上。如果 DR 站点的机器无法供我们使用，我们仍然有一套自己的服务器，可以在其上运行计算以达到我们的正常目标。

所以，如果你正在考虑作为 DR 方案的一部分来确保获得圈护的基础设施，那么看看能否想出有用的办法，在它不需要用于生产工作负载时将其好好利用起来。例如，你可以将备用基础设施用于负载测试环境；当需要 DR 时，负载测试可以很容易地被中止。

4. AI 驱动软件的韧性

摘自第 7 章：韧性与 AI

我们已经探讨了 AI 如何改变我们构建和运营软件的方式。但我们也在将 AI 集成到我们所构建的产品中，希望借此为用户改进我们的软件。这为确保我们的系统具备韧性带来了哪些新挑战？

模型提供商的韧性

基础模型提供商 OpenAI 和 Anthropic 在为其服务提供高可用性方面并没有很好的记录，至少与公共云供应商等其他托管服务提供商相比是如此。虽然我相信这会随着时间的推移而改善，但在你的关键功能中混入一个可能不稳定的第三方可能会成为问题。

这里的一个解决方案是考虑确保即使模型不可用，你的软件仍能运行。这可以通过在模型不可用（或者你被限流或令牌耗尽！）的情况下限制功能来实现——这是优雅降级模式的一个例子，我们将在第 11 章中进一步探讨。

另一种选择是为给定模型准备备用供应商，以对冲你常用的模型提供商出现可用性问题的情况。例如，你可以在 Azure 上使用 OpenAI 模型，如果通过 OpenAI 自己的服务访问模型被证明太不稳定，这是一个方便的替代方案；类似地，Anthropic 的模型也可以通过 Google 的 Gemini Enterprise Agent Platform 访问。使用这样的备用供应商时，最新模型的可用速度可能会有滞后，但考虑到你可能并不总是希望使用最前沿的模型来嵌入你的软件（我们稍后会讨论这一点），这大概没什么问题。

模型变更

行为一致性在帮助我们确保系统行为正常方面起着重要作用。虽然应对意外是韧性的一个关键概念（或者如 David Woods 所说的“优雅可扩展性”），但这并不意味着我们想要构建一个意外不断发生的软件。且不说 LLM 是非确定性的，模型中的微小变化也可能导致相当不同的行为。

我见过一些报告，其中模型开始表现不同，而供应商并未标记出任何重大行为变化。此外，迁移到更新版本的模型可能会从根本上改变你的提示词被处理的方式。

因此，拥有一套良好的测试来验证代码中 AI 部分的行为是否正常至关重要——这应该是传统功能测试与 AI 评估工具（evals）使用的结合。你要确保当意外发生时，最先感到意外的是你自己，而不是你的用户。

对于那些想要总体探索测试（包括基于 AI 系统的验证）的人，我可以推荐 Gayathri Mohan 的《Full Stack Testing》第二版。若想更深入地专门了解 evals，我建议阅读 Shreya Shankar 和 Hamel Husain 的《Evals for AI Engineers》。

可观测性

我们从自己的软件以及第三方服务中接收到的遥测数据，对于确保我们的应用程序按预期运行至关重要。正如我们在第 3 章中讨论的那样，我们更倾向于延迟的小幅波动，而不是大幅波动。例如，如果成功完成一项操作所需的时间变化很大，就很难知道应该从哪里开始触发超时。定义与延迟相关的 SLO 也会变得更加困难。

一旦你向 AI 模型发送提示词，或指示智能体为你做某件事，该操作的延迟可能会有很大差异，而且其变化方式从一开始就很难预测。其中一部分可以归因于提供商在某一时刻性能的可变性，但也可能是提供商限流的结果，或者只是你的提示词处理时间较长。

在提示词直接来自你的用户并发送给模型的情况下，你对模型需要多长时间才能返回结果的不确定性可能会更大。是调用挂起了，还是它在期待一个很大的输出？

解决这个问题的一些技术包括：根据正在生成的 token 数量动态设置超时，或者监控模型的流式输出，这样你就可以跟踪响应何时开始返回，而不是等待完整响应。

5. 如何处理不确定性

摘自第 7 章：韧性与 AI

在前面的章节中，我概述了为什么当今的 AI 世界如此不确定。然而，我希望这本书聚焦于实用、可操作的建议。考虑到这一点，我想概述一些关键步骤，帮助你确保自己为未来的不确定性做好准备。

多模型、多供应商

随着模型行为、速度和质量因版本而异，构建软件以支持不断变化的模型至关重要。你不仅希望有能力更换模型以利用最新、最好的成果，而且如果某个供应商的成本开始上涨，你也要确保寻找另一个供应商的门槛不会太高。

值得强调的是，在单一流程中混合使用来自不同供应商的模型可能会加剧问题。例如，一个涉及 Anthropic、OpenAI 和 Google Gemini 模型的流程，如果其中任何一个模型出现可用性问题，都会受到影响。在执行该流程时，所有这些模型都必须可用且正常运行。此外，针对一个模型有效的提示词可能无法完全移植到另一个模型——即使你留在同一供应商生态系统中，针对一个模型调优的提示词在迁移到不同模型时也必须重新评估。

采用多模型方法也延伸到你的供应商。如果你依赖的供应商又依赖于单一供应商的模型或 API，那么你和你的供应商都会容易受到该模型波动的影响，或受到突然涨价的影响。Cursor 在 2025 年被迫将大幅成本上涨转嫁给客户，因为它依赖使用 Anthropic 的服务，而 Anthropic 改变了定价结构，导致 Cursor 不得不支付更多费用。巧合的是，Anthropic 的 Claude Code 是 Cursor 的直接竞争对手。如果 Cursor 能够使用另一家公司的 AI 模型，它可能就不会那么容易受到这个问题的影响。

保持选择开放：确保你不会完全依赖单一模型或 AI 平台。如果模型质量下降，或者 OpenAI 或 Anthropic 的价格上涨，你要确保自己有转向其他选择的灵活性。

成本透明度

鉴于对供应商成本上升的担忧，以及按使用量付费的定价模式可能导致出人意料且不可持续的账单，能够定期查看自己花了多少钱、花在哪里，可能非常重要。这不一定是为了限制支出；它可以是为了理解你如何花钱，以及理解这带来了什么价值。

数字医疗公司 Nordhealth 的 CTO James Stanier 主张能够按人查看支出。这并不是为了羞辱花钱太多的人，他认为这种可见性有助于更好地理解软件的使用方式，并帮助推动那些被证明有价值的工具的采用。在 2025 年于 LeadDev Berlin 的演讲“LLMs: An Operator’s View”中，Stanier 解释说，如果你看到某个人花了很多钱，这不应被视为坏事，因为通常这表明有人正试图完成更多工作。他举了一个例子：他的一位 QA 工程师在一周内就在 Claude Code 上花掉了 1,000 欧元，远高于正常支出。在与这位工程师结对以了解这些钱花到哪里之后，Stanier 发现这笔支出让这位工程师的生产力提高了一倍多。

掌握支出信息，并能够与人们讨论他们如何使用这些工具以及这些工具带来的好处（或问题），将帮助大家做出更好、更明智的决策。

它还可以帮助你发现严重的超支。Uber 最近披露，它在今年前四个月就烧掉了全年的 AI 预算，而 Microsoft 宣布将收回员工的 Claude 许可证，部分原因显然就是成本。5 这些故事可能会让人挑一挑眉，但与 Axios 最近（诚然尚未证实）的报道相比就相形见绌了：一家未具名的企业公司因未能实施成本控制，在 Claude 许可证上花费了 5 亿美元。

提示：让你的 AI 支出可见！它可以帮助你了解人们如何使用它，也可以帮助你在账单开始急剧攀升时及时发现。

更频繁的供应商分析

供应商管理是许多公司都会开展的一项常见活动。它通常包括定期审查组织所使用的主要供应商，以帮助其在未来做出更好的决策。例如，如果发现向某个特定供应商支付了大量资金，尽管该供应商的服务质量正在下降，这可能促使升级处理，以降低价格或改善服务质量——也可能启动寻找替代供应商的流程。

在我上一份在 Thoughtworks 的工作中，我参与领导了我们的内部技术运营。虽然我的主要工作是帮助为内部交付团队提供支持，但我也时常参与我们自己的供应商管理活动。作为这些活动的一部分，我们会定期评估供应商自身的整体健康状况。在我参与的最后一次评审中，我们正积极关注我们一家主要技术供应商的健康状况；该供应商处于一个竞争非常激烈的市场，其市场份额正在下降。尽管我们对其提供的服务质量（以及成本）感到满意，但我们担心的是，更广泛的市场力量会将其挤出市场。因此，我们决定更深入地了解该供应商，同时也准备一份备选解决方案清单，以便在该供应商无法存活时选用。

鉴于 AI 行业整体存在的不确定性，我建议定期开展供应商管理活动。如果你已经有常规的供应商分析周期，可以考虑对 AI 供应商提高其频率。如果可能的话，了解是否有供应商反过来依赖于另一家提供商，就像 Cursor 依赖 Anthropic 的云服务那样。相比一家在选择使用谁的服务方面有更多灵活性的供应商，我会更担心一家反过来完全依赖单一公司的供应商。如果你以前从未做过供应商管理，可以考虑建立一个轻量级流程，以便更好地了解你在这个领域面临的风险敞口。

考虑到使用 AI 可能带来的潜在安全漏洞，我还建议通过定期威胁评估来保持你的威胁模型最新。与供应商评审一样，考虑在大量使用 AI 的领域提高常规威胁评估的频率，因为这项技术以及我们使用它的方式正在非常迅速地变化。

定期审查你的 AI 供应商！鉴于该领域的波动性，请确保你审查 AI 供应商的频率远高于普通供应商。

总结

我意识到这一章可能以某种略显消极的基调结束。但我想明确表示，我们在帮助构建更具韧性的分布式系统方面，确实有真实、实用的 AI 用例。我在本章中概述的大多数用例，正被世界各地的人们每天使用。关键在于，我在这里分享的解决方案仍然将人类置于决策的核心。很明显，由于我在这里也涵盖的那些挑战，我们距离真正自主的 AI SRE 还有很长的路要走。

尽管使用 AI 有明显的好处，但我们确实需要在微观和宏观层面都充分意识到其弊端。在微观层面，由 LLM 驱动的 AI 要求我们接受非确定性，而在构建韧性系统的背景下，我们执行的许多活动需要完全可重复且确定。在宏观层面，对整个 AI 行业的担忧意味着我们面对的是建立在非常不稳固的财务基础上、不断变化（但愿是在改进）的一系列产品。如果使用成本太高（或者制造它的公司破产），那么工具再好也无济于事。

事物的本质就是如此，随着我们了解更多、市场趋于稳定，围绕 AI 在我们行业乃至整个社会中角色的这种不确定性将会消退。但请注意：我认为我们仍深陷风暴之中，风平浪静可能还要数年之后才会到来。

本章大部分内容都在讨论不确定性，而能让系统弹性变得相当不确定的一个因素，就是机器故障时会发生什么。因此在第 8 章中，我将探讨如何确保即使机器让我们失望，我们的系统仍能正常工作。

要点

又是 Gergely。

感谢 Sam 分享本书的这一节选！虽然这本身就是一篇长文，但我们只涵盖了全书 16 章中的不到一章。我觉得这本书非常值得一读，如果你在构建生产系统，我推荐入手：

获取电子书或纸质书

我的感觉是，AI 让“弹性基础”变得比以往更加重要。本书大部分内容与 AI 无关——事实上，许多章节几乎没提到 AI。但随着 AI 智能体生成更多代码，并让软件构建速度超过以往：我们现在有更多软件（或更复杂的软件！）需要运维。

虽然有一些 AI 工具和厂商承诺借助 AI 能让软件运维变得更轻松：我并不真的相信会如此，至少在大规模场景下不是。配置好正确的监控和告警正变得越来越重要，响应故障同样如此，还要意识到诸如惊群、重试、幂等性、超时等棘手情况。

当你的服务足够重要时，为灾难恢复做准备似乎是件务实的事。我想收录关于灾难恢复的节选，因为我观察到业界发生大量“灾难”（即大范围故障），其中恢复时间长得惊人。其中一些原因可能是团队事先没有为灾难恢复做好准备或进行演练。

一个很好的例子是 Coinbase 的全球交易服务在单个 AWS 可用区出现问题后下线。正如我 6 月在 The Pulse 中总结该事件时所说：

“对于 Coinbase 这种规模的公司来说，没有自动故障转移简直业余得离谱。Coinbase 每年处理约 5.2 万亿美元，估值约 400 亿美元。根据我的粗略估算，这次故障中断了约 70 亿美元的金融活动。”

能够从他人的错误中学习是明智之举：而 Coinbase 事件感觉就是其中之一。

希望你觉得这些话题有参考价值，再次感谢 Sam 撰写本书，并与我们分享相关部分。