2025 年 6 月 12 日，互联网相当大部分经历突然宕机。从 Gmail 和 Spotify 的间歇性故障开始，很快升级为全球基础设施崩溃。对数百万用户和数百家公司，关键应用 просто停止工作。
核心是 Google Cloud Platform（GCP）的大范围宕机，GCP 作为庞大数字服务生态系统的后端。中断始于太平洋夏令时上午 10:51，几分钟内，数十个区域的 API 请求返回 503 错误。几小时内，涟漪效应变得不可否认。
在消费者平台中，宕机影响：
- Spotify（约 46,000 用户在 Downdetector 报告）
- Snapchat、Discord、Twitch 和 Fitbit：用户无法流媒体、聊天或同步数据
- Google Workspace 应用（包括 Gmail、Calendar、Meet 和 Docs）。这些应用为数亿用户日常 workflows 供电
企业和开发者工具同样严重受影响：
- GitLab、Replit、Shopify、Elastic、LangChain 和其他依赖 GCP 服务的平台看到性能下降、超时或完全关闭
- 数千 CI/CD 管道、模型服务端点和 API 后端停滞或完全失败
- Vertex AI、BigQuery、Cloud Functions 和 Google Cloud Storage 都受影响，停止数据处理和 AI 操作
总共，超过 50 个不同 Google Cloud 服务在全球超过 40 个区域受影响。
也许最显著影响来自 Cloudflare，这家公司通常被视为互联网可靠性支柱。虽然其核心内容分发网络（CDN）保持运行，Cloudflare 的认证系统（依赖 Google Cloud）失败。这导致许多客户的会话验证、登录工作流和 API 保护问题。
金融市场也感受到这次宕机的影响。Alphabet（Google 母公司）股价下跌近 1%。这个事件引发的逻辑问题是：为全局规模构建的平台如何遭受这种级联崩溃？
Service Control 系统
要理解如此大规模宕机如何发生，我们需要查看 Google Cloud 基础设施深处的关键系统。它称为 Service Control。
Service Control 是 Google Cloud API 基础设施的基础组件之一。
每次用户、应用或服务向 Google Cloud 产品发出 API 请求时，Service Control 位于客户端和后端之间。它负责几个任务：
- 验证 API 请求是否授权
- 执行配额限制（可以进行多少请求）
- 检查各种策略规则（如组织限制）
- 记录、计量和审计请求以进行监控和计费
简而言之，Service Control 充当几乎所有 Google Cloud API 流量的看门人。如果它失败，大多数 Google Cloud 随之失败。
宕机原因
2025 年 5 月 29 日，Google 在 Service Control 系统中引入新功能。这个功能添加对更高级配额策略检查的支持，允许更细粒度控制如何应用配额限制。
功能分阶段跨区域推出。然而，它包含一个 bug，在新代码路径中引入空指针漏洞，这个路径在推出期间从未练习过。功能依赖特定类型策略输入激活。因为该输入在测试期间尚未引入，bug 未被检测到。
关键的是，这个新逻辑也没有受功能标志保护，功能标志本允许 Google 以受控方式安全激活它。相反，功能在二进制中存在并激活，静默等待正确（或在这个案例中错误）条件触发。
这些条件在 2025 年 6 月 12 日太平洋夏令时上午约 10:45 到达，当新策略更新插入 Google Cloud 区域 Spanner 数据库时。这个更新包含新配额检查逻辑未预期的空白或缺失字段。
当 Service Control 读取这个格式错误策略时，新代码路径激活。结果是空指针错误触发，导致 Service Control 二进制在该区域崩溃。
因为 Google Cloud 的策略和配额元数据设计为近乎实时全局复制作为 Spanner 的关键特性，损坏的策略数据在几秒内传播到每个区域。
一旦每个区域 Service Control 实例尝试处理相同坏数据，它们都以相同方式开始崩溃。这创建 Service Control 全局失败。
因为这个系统对处理 API 请求至关重要，几乎所有跨 Google Cloud 的 API 流量开始失败，返回 HTTP 503 Service Unavailable 错误。
失败的速度和规模惊人。一个格式错误更新，结合无保护代码路径和元数据全局复制，在几分钟内将世界上最强健云平台之一带入停滞。
响应和恢复
一旦宕机开始展开，Google 工程团队快速精确响应。在 Service Control 中观察到第一次崩溃后两分钟内，Google 的站点可靠性工程（SRE）团队积极处理情况。
跟随的事件序列如下：
幸运的是，引入新配额检查功能的团队构建了保障措施：内部”红色按钮”开关。这个终止开关设计为立即禁用负责服务新配额策略逻辑的特定代码路径。
虽然不是完全修复，它提供快速方式绕过损坏逻辑并停止崩溃循环。
红色按钮机制在识别根本原因后 10 分钟内激活。在事件开始后 40 分钟，红色按钮更改已跨所有区域推出，系统开始稳定。较小和较不复杂区域首先恢复，因为它们需要较少基础设施协调。
这个终止开关对停止最严重中断至关重要。然而，因为功能未受传统功能标志保护，问题在全球生产中被触发，然后红色按钮才能部署。
大多数区域在应用红色按钮后相对快速开始恢复。然而，一个区域（us-central1，位于爱荷华州）花费显著更长时间稳定。
延迟原因是”群体效应”的经典案例。
当 Service Control 任务尝试大量重启时，它们都同时击中相同底层基础设施：持有策略元数据的区域 Spanner 数据库。没有任何形式的随机指数退避，系统被同时请求洪水淹没。系统没有轻松进入恢复，而是创建新性能瓶颈。
Google 工程师必须仔细限制 us-central1 中的任务重启，并将一些负载重新路由到多区域 Spanner 数据库以缓解压力。这个过程花费时间。us-central1 中的完全恢复直到初始故障后约 2 小时 40 分钟才实现，远在其他区域已经稳定之后。
关键失败
Google Cloud 宕机不是单个错误结果，而是一系列工程疏忽相互叠加。每个失败点，虽然孤立来看很小，都在将 bug 转变为全球中断中发挥作用。
以下是导致整个问题的关键失败：
缺少功能标志：第一个也是最关键的疏忽是缺少功能标志。新配额检查逻辑在所有区域以激活状态发布，没有能力在推出期间逐步启用或禁用它。功能标志是大型系统标准保障，允许新代码路径在受控阶段激活。没有一个，bug 从一开始就在每个环境活跃。
缺少空检查：第二，代码未包括基本空检查。当引入带空白字段的策略时，系统未优雅处理缺失值。相反，它遇到空指针异常，在每个处理数据的区域崩溃 Service Control 二进制。
元数据复制：第三，Google 的元数据复制系统完全按设计运行。错误策略数据几乎瞬间跨所有区域传播，到处触发崩溃。全局复制过程没有内置延迟或验证检查点在数据到达生产前捕获格式错误数据。
群体效应：第四，“us-central1”区域的恢复努力揭示另一个问题。当 Service Control 实例尝试重启时，它们都同时击中后端基础设施，创建”群体效应”，淹没区域 Spanner 数据库。因为系统缺少适当随机指数退避，恢复过程生成新压力而不是缓解它。
监控失败：最后，监控和状态基础设施与核心系统一起失败。Google 自己的 Cloud Service Health 仪表板在宕机期间宕机，许多客户无法访问日志、警报或可观察性工具，这些工具通常在危机期间指导他们的响应。这在危机高峰期间创建关键可见性缺口。
教训
最终，是简单软件 bug 将世界上最强健云平台之一带入停滞。
在隔离系统中可能是小错误升级为全球失败，中断消费者应用、开发者工具、认证系统和跨多个大陆的业务运营。这次宕机是尖锐提醒，云基础设施，尽管其规模和自动化，不是不可错的。
Google 承认失败的严重性并向客户正式道歉。在公开声明中，公司承诺进行改进以确保此类宕机不再发生。Google 承诺的关键行动如下：
- 防止 API 管理系统在存在无效或损坏数据时崩溃
- 引入保障停止元数据在适当测试和监控前瞬间全局复制
- 改进核心系统中的错误处理并扩展测试以确保无效数据在导致失败前被捕获
本文为学习目的的个人翻译，译文仅供参考。
原文链接：How the Google Cloud Outage Crashed the Internet。
版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。