返回档案库

案例库 · 软件与 IT · 技术决策 · 2025

Google Cloud 一个未加功能开关的特性让 70 多项服务瘫痪 7 小时

一个未加功能开关的配额检查特性遇到空白数据,空指针触发全局崩溃循环,拖垮了 Google Cloud 及其客户。

Google Cloud · 2025-06-12

怎么回事

2025 年 6 月 12 日,Google Cloud 的核心 API 策略检查系统 Service Control 在所有区域同时陷入崩溃循环。全球超过 70 项 Google Cloud 服务失灵,下游客户包括 Cloudflare、OpenAI、Shopify、GitHub 和 GitLab 均受波及。Gmail、Calendar、Drive 和 Meet 也受到影响。

Google 自己的事故报告把故障追溯到两个星期前的一个决定。2025 年 5 月 29 日,一个用于额外配额策略检查的新特性被加入 Service Control。它按区域逐步上线,但出错的那条代码路径从未被真正执行过,因为它需要一次策略变更来触发——而这次变更没有错误处理,也未受功能开关保护。

6 月 12 日,一次无关的策略变更向共享表中插入了空白字段。当新配额检查代码读取这些字段时,它命中空指针,并在所有区域同时陷入重启循环。工程师十分钟内就找到了原因,但恢复却拖了很久;最大的区域 us-central1 在任务重启时压垮了自己的数据库,又花了 2 小时 40 分钟才恢复。

Google Cloud 首席执行官 Thomas Kurian 在 X 上致歉,公司表示将重新架构,让单一系统故障无法拖垮整个运营,将审计所有系统,并加入功能开关,以便在预发环境捕获这一类变更。

为什么会这样

  • 新代码路径没有功能开关就上线,所以真实流量来临前从未得到验证
  • 触发代码对畸形输入没有错误处理,把空白字段变成了空指针
  • 上线是按区域的,但触发器是全局的,所以任何区域都无法在全部命中前捕获缺陷
  • 恢复比诊断慢,因为服务缺少随机退避,重启压垮了数据库
代价全球 70 多项服务瘫痪数小时代价高昂

教训

一个可能作用于真实流量的变更需要功能开关和错误处理路径,即使上线很安静。

资料来源

发现哪里写错了?告诉我们。

Comments · 0

    登录 后就能评论。

    类似的案例

    这家公司栽倒的地方,别处有人漂亮地解开过。 第二意见 →