案例库 · 软件与 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 上致歉,公司表示将重新架构,让单一系统故障无法拖垮整个运营,将审计所有系统,并加入功能开关,以便在预发环境捕获这一类变更。
为什么会这样
- 新代码路径没有功能开关就上线,所以真实流量来临前从未得到验证
- 触发代码对畸形输入没有错误处理,把空白字段变成了空指针
- 上线是按区域的,但触发器是全局的,所以任何区域都无法在全部命中前捕获缺陷
- 恢复比诊断慢,因为服务缺少随机退避,重启压垮了数据库
教训
一个可能作用于真实流量的变更需要功能开关和错误处理路径,即使上线很安静。
资料来源
- Google Cloud outage: Google apologizes after a major outage crippled services — CNBC, June 2025
- Google Cloud and other internet services report outages — CNBC, June 2025
- Google Cloud incident report, June 12 2025
发现哪里写错了?告诉我们。
类似的案例
这家公司栽倒的地方,别处有人漂亮地解开过。 第二意见 →

Comments · 0
登录 后就能评论。