一项政策，每个区域：Google Cloud 与全球控制平面的问责

摘要

• 2025 年 6 月 12 日，配额政策中意外的空白字段几乎同时到达了 Google Cloud 的区域 Service Control 数据存储。之前部署的代码路径既缺乏适当的错误处理，也没有功能标志保护；处理该策略导致 Service Control 二进制文件在每个区域崩溃。许多 Google Cloud、Google Workspace 和 Google Security Operations API 返回 503 错误。现有的流式和基础设施即服务资源基本上能够继续服务，但检查、修改、扩展或恢复服务所需的管理和 API 路径受到了广泛影响。
• 直接错误是狭窄的，但问责失败是架构性的。Google 拥有区域分布的服务实例和分阶段的二进制文件部署，但触发策略在几秒钟内全局复制。因此，终止机制绕过了部署本应提供的区域学习。恢复随后在更大的区域对 Spanner 产生了羊群效应，因为重新启动的任务缺乏随机指数退避。公共 Cloud Service Health 基础设施也依赖于受影响的环境，导致 Google 的首次通知延迟了约一个小时。
• 早期事件显示了不同的原因，但反复出现了关于逻辑独立性的问题。2019 年 6 月，维护自动化取消了几个物理位置上网络控制平面集群的调度，BGP 路由被撤销，诊断所需的工具争夺拥塞的网络。2021 年 2 月，在对等配额更改期间触发的潜在错误阻止了全球网络编程。2021 年 3 月，无效路由暴露了已知的供应商缺陷，一些 Cloud Interconnect 位置缺乏足够的路由器供应商多样性。这些并不是一个反复出现的软件缺陷；它们是对公共模式遏制、更改权限、网络恢复和真实可见性的反复测试。
• Google 负责验证全局复制的数据，隔离控制平面功能，在安全时保留故障静态或故障开放行为，保持事件通信独立，并证明承诺的补救措施已经完成。客户无法修复这些平台控制，但他们仍然负责识别哪些操作依赖控制平面 API，从提供商外部进行监控，测试降级模式，并购买路由和提供商多样性，而不是计算名义上的链接数量。多区域部署可以降低许多风险；但它本身并不能避开全球策略平面或共享骨干网。

中断是一次同时在各地做出的控制决策

云区域很容易想象。它有建筑物、电力、冷却、光纤、机器和旨在隔离物理故障的区域。控制平面更难看到。它是决定是否允许创建资源、应用哪些策略、如何编程路由、API 请求是否在配额内以及流量应流向何处的权威。当该权威暂时不可用时，应用程序可以继续处理现有工作，但当它们需要新实例、配置更改、凭证决策、路由更新或本身需要控制平面的故障转移时，它们就会变得脆弱。

这一区别解释了为什么 2025 年 6 月 12 日的事件既不是一次全面的基础设施瘫痪，也不仅仅是一个普通的 API 问题。Google 的完整 Service Control 事件报告指出，现有的流式和基础设施即服务资源并未受到主要故障的直接影响。然而，一长串产品出现了外部 API 错误，包括 Identity and Access Management、Cloud Storage、BigQuery、Cloud Run、Cloud DNS、Cloud Load Balancing、Hybrid Connectivity、Network Connectivity Center、Spanner、监控产品、控制台以及多项 AI 服务。从已编程状态继续提供服务的能力，比要求平台做出决定或进行更改的能力要强。

在 Google 的公开说明中，这一机制异常清晰。5 月 29 日，一项用于额外配额政策检查的新 Service Control 功能被逐区域发布。由于触发故障的代码路径需要后续的政策更改，二进制文件部署在不暴露故障的情况下完成。该功能未受到可以逐步为选定项目启用的标志的保护，并且其对无效数据的处理允许空值导致进程崩溃。6 月 12 日太平洋时间上午 10:45 左右，一项包含意外空白字段的配额政策被写入 Service Control 使用的区域 Spanner 表中。由于配额元数据被设计为以近乎即时的全球一致性移动，数据在几秒钟内出现在各个区域。每个区域 Service Control 部署随后遇到相同的输入并进入崩溃循环。

这并不是一个缺乏冗余的情况。区域服务实例和区域数据存储都存在。也不仅仅是一个工程师按错了按钮的情况。一个生产系统接受了结构上不安全的策略数据，一个关键路径缺乏防御性错误处理，一项功能在没有独立控制的激活路径的情况下到达每个区域，并且传播系统比验证系统更快。该架构将一个无效的逻辑对象转化为了一次全球事件。

将该事件称为格式错误的政策中断是准确的，但不完整。政策是触发器。更大的原因是附加在其上的权限量级，以及在接受、复制、解释和服务之间缺乏遏制。需要问责的问题不仅仅是为什么存在空白字段。而是为什么任何单一政策能够在一个区域、一个项目组或一个影子验证器有时间拒绝它之前成为可执行的故障状态。

短暂的触发导致了漫长且不均衡的恢复

Google 的时间表包含两个截然不同的故事。检测和诊断很快。完全恢复却不快。

us-central1 中较慢的路径是风险分析的核心。随着 Service Control 任务重新启动，它们对底层的 Spanner 表产生了集中的需求。这些任务缺乏防止同步重试所需的随机指数退避。Google 不得不限制任务创建并将流量路由到多区域数据库。换句话说，第一次故障是对全局数据的不安全解释；第二次故障是恢复行为使共享依赖项过载。

Google 自身的 SRE 文献早就描述了这种危险。其关于解决级联故障的章节解释了重试和重启如何使后端保持过载，以及随机指数退避、优雅降级和受控减载如何防止局部容量问题演变为级联故障。2025 年的报告明确承诺对系统进行审计以实现这种退避。重要性不在于 Google 未能遵循书中的一句话。而在于一种已知的分布式系统危害仍然存在于一项关键服务中，该服务的重启群体是区域性的，而其支持数据是全球性的。

因此，恢复计划应作为生产架构进行评估，而不仅仅是手册段落。一个可以安全禁用的系统需要一个其自身依赖关系被理解的终止机制。一个可以一起崩溃的集群需要一个重启调控器、准入控制、抖动和经过测试的最大恢复速率。预期吸收集群恢复的数据存储需要保留容量或降级读取路径。如果工程师必须在事件期间路由到多区域数据库，则该路由应在事件之前进行排练和观察，并有证据表明它不会将过载转移到其他地方。

长尾也对客户沟通产生影响。Google 的初步报告描述了一次三小时的全球事件，而事件页面继续列出产品恢复情况直到下午 6:18。一些产品在 API 服务恢复后有积压。在主要窗口期间请求失败的客户可能遇到了重试、排队作业、部分工作流、陈旧缓存或需要更长时间恢复的第三方服务。提供商的绿色状态是客户协调的开始，而不是所有业务流程都完整的证明。

区域部署并未带来区域学习

渐进式交付本应将距离转化为证据。一项更改到达小部分群体；操作员观察其行为；然后才进一步推进。Google 对新的 Service Control 代码采用了逐区域的二进制文件部署，但部署从未执行后来失败的那个代码路径。激活政策遵循了不同的分发机制，该机制经过优化，可在几秒钟内使配额状态全球化。代码是渐进的；代码的含义却不是。

这是一个微妙但后果严重的变更控制失败。团队通常将二进制文件、配置、模式、政策和数据视为单独的对象。然而，生产行为来自它们的组合。一个休眠功能可以逐个通过每个区域检验，直到一个配置值将其处处唤醒。一个对写入者有效的模式可能对旧读取者无效。一个全局复制的政策可以使区域金丝雀部署变得无关紧要。一个红色按钮可能存在，但仍依赖损坏的控制平面生效。

Google 当前的基础设施指南认识到了这一风险。可靠性构建块指南指出，全局资源对区域性和区域性基础设施事件具有弹性，但当关键配置错误具有全局范围时，它们可能成为单点故障。它建议仔细控制更改，并对要求极高的工作负载采用区域纵深防御回退措施。配套的管理和监控指南建议对全局资源采用渐进式部署和额外审查。2025 年的事件在提供商内部应用了相同的逻辑：全局覆盖是应对物理故障的可靠性优势，也是不良逻辑状态的爆炸半径危害。

完整的补救需要联合发布模型。二进制文件、政策模式、政策值、数据存储复制、读取器版本、回退行为和紧急控制应被视为一个变更面。新读取器应能安全地接受旧的、新的、缺失的和损坏的值。新政策在成为权威之前应进行影子读取。激活应从内部项目或有界区域开始，并在崩溃、延迟或错误阈值时自动停止。复制应是递增的，以保留检测间隔，即使最终业务状态必须变得全局一致。

这并不意味着每个全球政策都应变得缓慢不一致。配额和授权决策可能需要及时、一致的状态。设计问题在于验证是否可以与权威分离。候选政策可以作为惰性数据复制，针对类似生产流量进行解析和评估，并且仅在检查成功后生效。当新对象无效时，区域可以保留上一个已知的良好政策。读取器可以区分损坏与合法拒绝。全球一致性与分阶段安全性并不矛盾；它只需要比快速复制更多的东西。

故障开放是一项业务和安全决策，而不是一句口号

Google 承诺对 Service Control 进行模块化，以便可以隔离受影响的功能并在故障时开放，允许在相应检查失败时 API 请求继续。这是一项有意义的修正，但“故障开放”这个短语需要界限。配额检查、身份验证决策、计费控制和滥用预防控制在不可用时不会带来相同的后果。

对于低风险的配额检查，临时宽松的服务可能比拒绝每个客户 API 请求更安全。提供商可以稍后核对使用情况，按项目限制曝光，并保持核心可用性。对于身份验证检查，盲目允许请求可能会造成比停机更糟糕的安全事件。对于资源创建，有限的最新政策本地缓存可能比统一拒绝或统一允许更安全。正确的降级行为取决于控制的目的、受信任状态的新鲜度、操作的可逆性以及欺诈、数据丢失或支出失控的可能性。

Google 的Service Infrastructure 架构分离了管理、控制和数据平面，同时显示了平台功能的广度：身份验证、授权、配额、速率限制、审计、计费、日志记录和监控。这一广度正是模块化故障行为重要的原因。一个解析器或政策路径不应能够将每种类型的决策都变成相同的 503 响应。

一个负责的设计将发布原则而非敏感的实施方案细节。哪些类型的检查使用最后已知的良好数据？哪些可以临时故障开放？哪些因安全后果占主导而故障关闭？在降级服务期间，哪些严格限制仍然存在？如何核对异常使用情况？客户能否为受监管的工作负载选择更严格的行为？平台如何区分无效的提供商政策与合法的客户配额拒绝？

这也改变了测试。仅仅确认良好策略返回正确答案是不够的。测试应注入空白字段、未知字段、过期版本、部分复制、损坏对象、不可用的数据存储、缓慢读取和冲突策略。它们应证明一个模块可以被绕过而不会绕过不相关的安全措施。它们应测量降级操作期间客户可见的行为，并验证恢复是否不会以不可预测的方式重放被拒绝或重复的更改。

状态系统本身也遭遇了它本应描述的中断

大约在第一个小时内，客户没有收到公开的 Cloud Service Health 事件报告，因为该基础设施本身已宕机。一些客户还在 Google Cloud 上运行监控，因此服务和其服务证据一同失效。中断不仅影响了生产，还影响了认知控制：了解正在发生的事情、决定是否故障转移以及向用户解释情况的能力。

这并非没有先例。在 2020 年 12 月 14 日 Google 全球身份验证中断期间，事件报告指出 Cloud Support 的内部工具受到影响，客户无法在控制台中创建或查看支持案例，仪表板通信延迟到主要影响结束后才进行。该事件源于自动配额管理降低了中央身份系统的容量。现有的网络数据平面配置仍可运行，但经过身份验证的服务、API 访问、控制台和许多内部工具却无法运行。其机制与 2025 年不同；反复出现的问题是，身份、支持、监控和通信可能与其本应诊断的服务共享命运。

此后，Google 记录了一种更明确的通信模式。其事件通信指南区分了 Personalized Service Health（使用项目上下文并可以与警报和 API 集成）与公共 Cloud Service Health 仪表板。该指南承认 Personalized Service Health 依赖 IAM 等服务，并建议在个性化系统不可用时回退到公共仪表板和 RSS 源。这是合理的建议，但 2025 年 6 月表明，公共渠道也需要运营独立性。

提供商的义务是维护一个外部可达、独立供电和管理的发布路径，配备预先授权的事件模板以及来自事件指挥部的带外输入。它不应需要常规控制台、客户身份平面、主监控栈或正在调查的控制服务。第一份通知无需包含根本原因。它应说明观察到的症状、已知范围、开始时间、控制平面操作还是现有工作负载受到影响、可用的解决方法以及下次更新时间。

客户也有并行的义务。Google 的Personalized Service Health 集成指南明确指出，该服务无法知晓每个产品对特定应用程序是否关键，也无法知晓当某个依赖项失败时应用程序是否继续运行。操作员需要自己的用户旅程检查、应用程序指标、网络遥测和业务流程警报。至少应有一条路径在 Google Cloud 之外运行，并传递到一个不依赖 Google 身份的事件渠道。提供商状态是佐证，而非首要且唯一的检测手段。

这种分离有一个治理原因。延迟的状态页面会改变客户行为。团队可能会浪费时间搜索自己的部署，进行有风险的回滚，向损坏的控制平面扩容，或在等待确认时推迟故障转移。支持沉默也可能导致下游提供商发布猜测。因此，通信可用性是一种具有可衡量检测和发布目标的风险控制，而非在工程工作开始后添加的礼貌行为。

现有工作负载比旨在拯救它们的行动生存得更好

2025 年报告中关于现有流式和基础设施即服务资源未受影响的声明应仔细解读。它展示了数据平面的部分与管理路径之间的有益分离。这并不意味着仅仅因为当前运行的虚拟机保持运行，应用程序就是安全的。

云系统是动态的。自动伸缩器创建实例。编排器替换不健康的节点。部署系统获取工件并发起 API 调用。数据库进行故障转移。证书和令牌轮换。无服务器服务在一个看似简单的请求背后调用提供商的控制路径。事件响应者更改防火墙规则、负载均衡器、DNS、路由、配额和权限。静态数据平面可以继续转发，而围绕其的业务流程却失去了适应能力。

2021 年 2 月的网络中断使这一界限具体化。Google 的网络编程故障事件报告指出，当全球网络控制平面重新处理与对等配额更改相关的操作时，触发了一个潜在错误。新的、更新的、删除的或迁移的虚拟机和网络端点无法正确编程，而许多未更改的实例继续运行。Google 全球暂停了实时迁移；大约 1000 个 GKE 集群因无法置备节点或集群而受到影响；一些实例创建和负载均衡器更新以非常高的速率失败。一个健康的现有服务器对于需要一个新网络服务器的自动伸缩组毫无帮助。

这就是灾难恢复的控制平面悖论。恢复计划中的操作通常比普通服务更少经过测试且更依赖控制平面。手册可能会说“在第二个区域创建容量”或“切换负载均衡器”，但这些是 API 操作。如果引发中断影响了资源创建或全局负载均衡器更新，恢复步骤在需要时恰好不可用。

Google 的灾难恢复架构指南区分了数据平面操作和控制平面更新，并解释了特定服务的弹性。其可靠基础设施设计指南建议避免或最小化在故障期间对非数据平面操作的依赖，例如创建新的负载均衡器。实用的教训是预先配置恢复路径。容量可以是温备的，而非假设性的。区域端点可以在全局前端失败之前存在。DNS 记录、凭证、路由、镜像和手册应可用，而无需在最后一刻进行管理操作。

对于每个恢复步骤，操作员应能够指出其所需的 API、身份提供商、网络路径、DNS 解析器、工件存储、密钥和人工审批。然后，演练应逐个移除这些依赖项。仅在控制台、IAM、Service Control、全球网络编程和主区域全部健康时才能成功的计划是扩展步骤，而非灾难恢复。

2019 年的中断表明，物理隔离可能共享同一个自动化边界

2019 年 6 月 2 日，美国多个区域的 Google Cloud 项目出现了持续三个多小时的丢包率升高。一些 Google 服务无法完全将用户重定向到未受影响的区域。网络事件报告描述了组合成一次重大中断的多个故障：网络控制平面作业被配置为因维护事件而停止；多个集群管理实例符合相同罕见事件类型的条件；一个软件错误允许自动化取消独立软件集群的调度，即使它们位于不同的物理位置。

网络最初在无控制平面的“故障静态”模式下继续运行。几分钟后，受影响位置之间的 BGP 路由被撤销，降低了网络容量并使一些区域无法访问。拥塞网络上诊断工具的故障减缓了调查速度。当工程师恢复控制平面实例时，必须重建和重新分发配置，从而延长了恢复时间。

与 2025 年存在显著的结构性相似之处。在 2019 年，物理位置和多个集群管理器存在，但一个维护抽象将它们一起选中。在 2025 年，区域 Service Control 实例存在，但一个全局政策将它们一起命中。两次事件都涉及一个被证明过于短暂或过于依赖的安全期：2019 年的故障静态路由和 2025 年的红色按钮绕过。两次事件都损害了用于理解或沟通中断的工具。两次恢复路径都必须在降级条件下重建或重新分发控制状态。

原因不可互换。2019 年的事件是网络控制和维护自动化的故障；2025 年的事件是政策数据和 API 控制的故障。问责不应将它们简化为“Google 又发生了中断”。比较的价值在于检验组织是否反复发现名义上独立组件仍然共享一个管理域、一个传播机制、一个应急工具或一个恢复依赖项。

Google 2019 年的承诺包括拒绝涉及的维护请求、持久化本地控制平面配置、延长故障静态网络操作持续时间、强化应急工具以及扩展灾难恢复测试。当前的问责问题不是这些行动是否能防止无关的 2025 年空指针。而是其背后的治理方法是否成为标准：绘制公共权限、持久化安全状态、将紧急控制放在主故障域之外，并测试灾难性相关故障。补救计划只有在其控制模式超越撰写事后剖析的团队时，才具有制度价值。

对等和传输多样性关乎命运，而非电路数量

云可用性通过网络到达客户。一项工作负载可以在区域内健康运行，而用户却可能因为边缘、骨干路由、对等会话、传输提供商、DNS 路径或混合互连出现故障而无法访问它。相反，两条接入电路在采购订单上看起来很具多样性，却可能汇聚在同一个城域网、同一个提供商、同一个路由器型号、同一个 Google 边缘或同一个控制系统上。

Google 2021 年 3 月 17 日的骨干网事件报告说明了这种差异。连接新路由器改变了某些路由器角色接收哪些路由。这些路由暴露了特定路由器型号中的已知缺陷，导致路由进程失败。自动重定向降低了更广泛级联的风险，但在收敛过程中产生了丢包。一次手动缓解措施造成了另一段拥塞时期，并且一些 Cloud Interconnect 地点因路由器供应商冗余不足而受到较长时间的影响。区域间私有 IP 流量、公共 IP 流量、负载均衡器、VPN 隧道和外部连接以不同比例受到影响。

这就是为什么弹性评估必须超越“我们有两条链路”的原因。评估应询问每条光纤路径的所有者、其所使用的大楼和边缘可用性域、终结其的路由器供应商和软件版本、控制其 BGP 会话的 Cloud Router、路由重新收敛的方式、故障转移容量是否能承载全部负载，以及两条路径是否依赖同一个提供商控制平面。它应观察实际的路由更改并运行计划中的撤销，而不是将拓扑图视为证明。

Google 的Cloud Interconnect 概览提供了 99.9% 和 99.99% 的配置，并说明单个连接没有运行时间 SLA。Partner Interconnect 指南要求在其推荐的 99.99% 拓扑中使用跨两个城域网和边缘可用性域的四个 VLAN 连接；它还指出，Google 网络之外的提供商部分需要其自身的保障。使用多个服务提供商可以提高可用性，但前提是它们的底层路径实际上是分离的，并且在故障转移期间有足够的容量。

云内部的对等默认情况下不是中继。Google 的VPC 网络对等文档指出，对等是非传递的：如果网络 A 与 B 对等，且 A 也与 C 对等，B 并不因此获得与 C 的连接。这一约束可以是一个有用的遏制边界，但它会让假设中央 VPC 自动充当中继枢纽的团队感到惊讶。在中断期间，临时的恢复路由可能会因为所宣传的拓扑从未被支持而失败。在需要中继的地方，应明确设计它，包括路由交换、策略、容量、安全检查和端到端的故障行为测试。

互联网传输同样需要这种精确性。通过两个 ISP 的公共访问可能仍然通过一个公共对等地进入 Google 的网络。一个私有互连和一个互联网 VPN 可能提供更好的管理多样性，但两者仍然可能依赖 Google 的骨干网或相同的客户身份和 DNS。只有当应用程序、数据、身份、部署工具、可观察性和 DNS 故障转移可以在那里独立运行时，第二个云才能减少提供商集中度。一个标志数量不是架构。

多区域是针对错误类别的强力保护

多区域设计仍然很有价值。它可以防范电源事件、本地容量损失、分区硬件故障以及许多区域性软件问题。错误不在于使用多个区域；而在于将该术语视为完全的独立性声明。

2019 年的网络事件影响了多个区域，因为控制平面自动化边界跨越了物理位置。2021 年的对等配额事件影响了全球网络编程，因为相关的控制器和 VPC 资源具有全局范围。2025 年的 Service Control 事件影响了每个区域，因为策略平面是全球性的。在每种情况下，受影响的管理域内更多的应用程序副本都无法消除共同原因。

Google 的可靠性文档在位置范围和应用程序可靠性之间做出了有用的区分。全球资源可能对区域性基础设施中断具有很强的弹性，但仍然可能因配置而成为单点故障。多区域资源可以在一个区域丢失后存活，但仍然依赖全球身份、API 管理、网络控制或全球前端。客户需要一个标记地理和权限的依赖关系图。

该图应至少包含五个层次。第一是执行：流程和数据实际运行的地方。第二是控制：哪些 API 创建、路由、授权、扩展和故障转移这些资源。第三是访问：哪些 DNS、对等、传输、互连、VPN 和骨干网路径连接用户和操作员。第四是观察：日志、指标、状态源、寻呼和支援位于何处。第五是恢复：需要哪些仓库、凭证、人员和外部服务来恢复运营。

只有当同一可信事件无法同时禁用它和主要组件时，依赖项才是独立的。对于由一条无效全球策略控制的两个区域，对该事件而言它们不是独立的。通过同一个身份系统传输的两个监控栈，对于身份验证中断而言不是独立的。运行相同路由器软件的两条电路，对于相关的供应商缺陷而言不是独立的。另一个云中的温备服务，如果唯一的 DNS 控制、工件仓库或操作员登录位于 Google Cloud，则不是独立的。

这种分析不应变成一项昂贵的要求，即每个小工作负载都要跨三个提供商运行。控制必须相称。一个公共信息站点可以接受几个小时的停机，并保留一个外部状态页面。一个支付授权服务可能需要预配置容量、独立传输、外部监控以及经过测试的备用提供商。问责的行为是了解哪些依赖项仍然是共同的，评估其后果，并获得业务所有者的明确接受。

Cloudflare 将一个提供商的事件变成了另一个提供商的依赖教训

2025 年 6 月的事件以一种特别有启发性的方式跨越了企业边界。Cloudflare 的自身中断报告指出，Workers KV 部分依赖于一个第三方云提供商。当该依赖项故障时，Workers KV 变得不可用，且使用它的一系列 Cloudflare 产品受到影响，包括 Access、Gateway、WARP、Turnstile、Images、Stream、仪表板的部分以及其他服务。Cloudflare 的核心 CDN 和安全服务并未统一宕机，但依赖关系使 Google Cloud 控制平面的故障通过以另一提供商名义销售的产品变得可见。

这并非证明外包本质上是不负责任的证据。提供商之间合理地相互购买服务。这证明的是，依赖项的商业距离并不能降低其运营后果。客户可能认为通过购买 Google Cloud 用于基础设施和 Cloudflare 用于边缘安全已经实现了多元化，但一个 Cloudflare 控制服务可能依赖 Google Cloud。由此产生的链条可以是 Google Cloud 到 Workers KV 到 Access 再到客户的操作员登录。如果没有披露和测试，客户无法看到备用控制与主要故障域共享。

Cloudflare 接受了其应负的部分责任。其报告描述了哪些服务依赖 Workers KV，指出核心服务最初未能从第三方存储路径进行故障转移，并概述了减少或消除关键产品依赖项的工作。Google 仍然对上游平台故障负责；Cloudflare 仍然对决定一个关键内部服务可以依赖它而没有足够的连续性负责；最终客户仍然对评估访问其自身系统是否有破拆途径负责。这些责任是并行的，而非相互排斥。

当时的美联社报道记录了流行在线服务中可见的中断以及数以万计的用户报告。这类报道对于展示公众影响范围很有用，但中断报告数量并不是受影响人群、请求或财务损失的普查。更有力的证据来自提供商的技术报告和客户交易数据。问责应既抵制轻描淡写，也抵制夸大其词：即使没有精确的全球损失总数，广泛的依赖级联也很重要。

因此，合同和架构审查应要求提供商识别控制、身份、配置、状态和恢复功能的关键第四方依赖项。它们应规定在上游事件负责时的通知义务，保留允许客户核对影响的日志，并定义提供商是否有经过测试的替代方案。出于安全和商业原因，客户可能不会收到完整的供应商地图，但应获得足够的保证，以了解云、身份平台、网络运营商和地理控制平面的集中度。

SLA 积分不能证明依赖项是可接受的

服务等级协议很有用，因为它们定义了可衡量的承诺和补救措施。它们不是完整的风险评估。每月正常运行时间百分比是平均值，通常适用于特定产品或配置的拓扑。它可能排除客户配置、第三方部分、配额、预览功能或所涵盖服务之外的故障。补救措施通常是对未来支出的积分，而非对收入损失、紧急劳动力、监管风险或客户用户损害的赔偿。

例如，当前的Cloud Interconnect SLA区分了生产级拓扑与单一连接，并要求客户在索赔时提供证据。该框架可以鼓励合理的拓扑结构，但它无法告诉董事会四个小时的混合访问损失是否可容忍。针对特定产品的 SLA 也不能描述用于更改服务的 API、用于观察其的监控以及用于报告其的支持渠道之间的相关故障。

客户需要为其自身的用户旅程制定服务等级目标。该目标应包括完成旅程所需的云产品、网络路径、内部服务和供应商。它应衡量稳态服务和恢复行动。一个保持运行但无法增加容量的结账流可能现在健康，但面临直接风险。一个可以提供读取但无法提升副本的数据库可能在用户看到错误之前就已降低了可恢复性。

Google 的责任和积分条款是法律分配，而非工程证据。反过来，提供商的公开道歉也不是疏忽的证据或法律承认。本文基于控制分配运营和治理问责：谁设计了传播路径，谁接受了依赖关系，谁可以测试它，谁必须验证补救措施。法律责任取决于合同、管辖权、事实和技术事件报告范围之外的裁决。

因此，董事会应要求量化超出供应商正常运行时间的风险敞口。多少收入或公共服务取决于控制平面操作？已运行的资源在不扩展或更新凭证的情况下能服务多长时间？通过备用传输路径移动用户需要多长时间？哪些恢复需要故障提供商的支持？上次演练中有哪些证据？服务积分应记录在财务记录中；绝不应误认为持续性。

Google 的补救措施清单只有成为证据时才可信

2025 年的事件报告包含了一系列强有力的承诺。Google 冻结了 Service Control 的更改和恢复后的手动政策推送。它表示将对服务进行模块化并在适当时机故障开放，审计消费全球复制数据的系统，逐步传播这些数据并留出验证时间，要求关键二进制文件受默认禁用的功能标志保护，改进静态分析和无效数据测试，审计随机指数退避，改善外部通信，并在 Google Cloud 宕机时保持监控和通信可用。

这些行动与观察到的故障链异常匹配。剩下的问题是保证。一个承诺可以关闭跟踪系统中的事后行动项，却无法证明风险在生产中已降低。Google 应公布最高影响行动的完成状态、验证方法和残留限制，即使详细架构仍然保密。

对于全球策略安全性，证据可以包括分阶段激活覆盖的关键策略消费者百分比；对格式错误候选数据的自动拒绝率；在全球权威生效前的最小观察间隔；以及在一个集群中阻止坏对象的成功演练。对于故障隔离，可以包括表明配额模块可以在不相关的 API 检查继续时发生故障，且安全敏感决策保留其预期边界的测试。

对于恢复，Google 应展示集群重启限制、退避合规性、保留的数据存储容量以及同时区域恢复的负载测试结果。对于通信，它应公布从首次客户影响到内部检测、首次公开通知、首次范围影响声明的时间，以及演练期间独立状态路径的可用性。对于制度学习，它应报告是否发现并修复了 Service Control 之外的类似全球消费者。

早期事件加剧了对这种后续行动的需求。2019 年后，Google 承诺延长故障静态网络操作、持久化控制配置、增强应急工具并扩展灾难测试。2021 年 2 月后，它承诺进一步区域化全球网络控制组件、为迁移设置自动暂停，并在控制器无响应时改善数据平面弹性。2021 年 3 月后，它承诺提供路由策略实施的功能域并改进路由器构建测试。每项承诺可能在其自身计划内已完成；公开记录并未提供一个连续的保证视图，以显示平台共模风险如何随时间变化。

Google 的 SRE 书籍将事后剖析描述为一个学习系统，行动项与原因相关联，且不会将复杂事件简化为个人责备。同样的原则支持外部问责。公布证据的目的不是曝光某位员工或邀请客户运行 Google 的网络。而是让客户区分临时解决方法与持久控制，了解哪些问题仍然存在，并决定他们自身的风险处理是否足够。

对于最全球化的控制，独立审查将增加价值。它可以抽样设计文档、部署记录、故障注入结果、红色按钮独立性和行动关闭情况。公共产出可以说明范围、例外和结论，而无需揭示可利用的内部细节。自我报告提供了技术深度；独立保证提供了信心，即关闭标准并非仅由负责交付的团队定义。

在下一次全球事件之前，客户应测试什么

没有客户能够为 Google 内部的 Service Control 二进制文件设置功能标志，或更改其策略表的复制方式。那些仅仅告诉客户在提供商范围内发生故障后“更好地设计架构”的建议，是不公平地转移责任。然而，客户确实需要就提供商中断对其业务的权限程度做出重要选择。

从服务路径开始。确定如果所有 Google Cloud 管理 API 不可用三小时，哪些用户事务可以继续。在暂停新部署、冻结自动伸缩、IAM 更改不可用、负载均衡器修改被阻止以及支持不可访问的情况下进行测试。衡量能力、凭证、证书、队列或计划作业何时成为限制因素。结果通常是一条曲线而非二元答案：服务在当前负载下持续一段时间，然后随着常规控制操作的累积而退化。

接下来，测试操作员访问。保留破拆凭证，其检索和验证不依赖主云身份路径。在 Google Cloud 之外维护一个最小的事件工作区、联系人列表、运行手册、架构图和状态发布器。确保团队能够在不依赖企业协作套件的情况下联系网络运营商和关键供应商，如果该套件共享 Google 身份。审计每个应急工具是否存在隐藏的 DNS、电子邮件、单点登录和密钥依赖项。

然后测试网络路径。在受控演练中撤销每个 BGP 会话和互连连接。确认流量通过预期的城域网和提供商移动，测量收敛损失，并验证备用路径具有满负载容量。检查公共互联网回退路径未被防火墙、路由或源地址假设所阻止。对于 VPC 对等，验证确切导入和导出的路由，不要假设传递性。对于多云传输，同时测试数据一致性、身份以及数据包。

预配置在控制平面中断期间无法创建的内容。这可能包括区域负载均衡器、DNS 记录、备用集群、备用数据库、配额、服务账户、工件和网络隧道。保持更改足够小，以使最后已知的良好配置仍然可用。练习一种降级模式，该模式放弃非必要功能，而不是向受损的提供商发出一批重试或扩展请求。

最后，在演练后进行核对。确定哪些事务失败、哪些被重试、哪些重复、哪些保持排队以及哪些客户需要通知。提供商的恢复并不保证应用程序的正确性。恢复目标应包括积压清理和数据验证，而不仅是 HTTP 健康检查。

对于较小的组织，适当版本可以适度：一个外部运行时间检查、另一个提供商上的状态页面、导出的联系详情和运行手册、经过测试的备份、已知的手动程序，以及关于多云成本是否合理的文档化决策。问责并非最大架构的同义词。它是展示一个清醒的风险决策取代了意外依赖的能力。

控制平面和网络问责的记分卡

董事会、监管机构或主要客户不需要专有源代码就能提出精确的问题。它需要与观察到的故障模式相对应的证据。

记分卡应按行横向阅读。没有独立状态的功能标志是不够的。没有提供商和路由器多样性的四个互连连接可能还不够。没有预配置恢复的多区域应用程序仍然可能依赖全球控制器。可靠性来自于控制的组合以及组合在故障下有效的证据。

持久的信号是共享权威的速度

云平台通过集中决策来创造价值。一项政策可以管辖数千个项目。一个网络可以承载跨洲的流量。一个 API 可以在几秒钟内创建基础设施。同样的杠杆作用决定了错误的爆炸半径。

因此，2025 年 6 月的中断最好不要被记住为一个空指针。空指针是普通的软件缺陷。使这一缺陷具有全球性后果的是，休眠代码、无效策略、快速复制、区域读取器、同步重启、共享监控和下游提供商形成了一条链条。系统是分布式的，但权限没有被充分分区。

Google 的回应确定了正确的主题：增量传播、功能标志、模块化故障、退避和独立通信。客户应期待这些更改有效的证据，同时诚实地面对他们仍然拥有的风险。一项工作负载可以跨区域分布，但仍然依赖一个全球决定。一个企业可以购买两个网络，但仍然使用一条通往命运的路线。一个状态页面可以是公开的，但仍然置身于事件内部。

正确的问责标准不是一个全球云必须永不故障。而是全球权限的移动速度不得快于验证其的控制；区域系统必须能够拒绝或在危险的共同状态下存活；网络和恢复路径必须在运营上独立，而不仅仅在名义上；并且客户必须能够在还有时间采取行动时看到故障。在云控制平面中，速度就是力量。弹性始于对该力量能够到达之处施加限制。