一项策略，每个区域：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 错误，包括身份和访问管理、Cloud Storage、BigQuery、Cloud Run、Cloud DNS、Cloud Load Balancing、混合连接、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 的服务基础设施架构将管理平面、控制平面和数据平面分开，同时展示了平台功能的广泛程度：认证、授权、配额、速率限制、审计、计费、日志记录和监控。这种广泛性正是模块化故障行为如此重要的原因。一个解析器或策略路径不应该能够将每种类型的决策都变成相同的 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 隧道和外部连接以不同的比例受到影响。

这就是为什么韧性审查必须超越“我们有两条链路”。审查应该询问谁拥有每条光纤路径，它使用哪栋建筑和边缘可用性域，哪个路由器供应商和软件版本终止它，哪个 Cloud Router 控制其 BGP 会话，路由如何重新收敛，故障转移容量是否能承载全部负载，以及两条路径是否依赖于同一个提供商的控制平面。它应该观察实际的路由更改并运行计划中的路由撤回，而不是接受拓扑图作为证据。

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 的回应确定了正确的主题：增量传播、功能标志、模块化故障、退避和独立通信。客户应期望看到这些变更有效的证据，同时诚实地面对他们仍承担的风险。一个工作负载可以跨区域分布，但仍依赖于一个全球决策。一家企业可以购买两个网络，但仍使用一条通往命运的路径。一个状态页面可以是公共的，但仍置身于事件之中。

恰当的问责标准并非全球云绝不允许失败。而是全球权威的移动速度不得快于验证它的控制措施；区域系统必须能够拒绝或不安全地共用状态中存活下来；网络和恢复路径必须在运营上独立，而不仅仅是名义上独立；客户必须能够在仍有时间采取行动时看到故障。在云控制平面中，速度就是力量。韧性始于限制这种力量可以传递到何处。