文章作者：姜南(Slyar) 文章来源：Slyar Home (www.slyar.com) 转载请注明，谢谢合作。
声明：本文内容完全基于公开信息，不涉及任何公司内部技术细节
- Google Cloud 事故报告：https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW
- Cloudflare 事故报告：https://blog.cloudflare.com/cloudflare-service-outage-june-12-2025/
美国时间2025年6月12日星期五，Google Cloud (GCP) 发生了全球范围的宕机事故，导致多个大型互联网服务瘫痪或中断，整个事故持续了3个小时 (10:49 - 13:49)。公开的事故报告里有详细的细节，这里我简单提炼一下核心内容方便以后查阅。
造成本次事故的核心服务是GCP Service Control，它负责所有API的认证，配额管理，日志记录等功能。如果这个服务挂了，那么所有通过API访问GCP内部和外部服务的其他服务和产品都将无法正常工作。
2025年5月29日，Service Control团队改了一些配额管理的代码新增了一个功能 (check)，其中有一个bug：当某个配额策略里包含空值的时候，这个新增的代码会丢一个空指针异常 (throw null pointer exception) 然后搞崩 (crash) 整个程序。这部分代码是灰度/金丝雀发布 (canary release) 到production的，但问题是不管是这部分代码的单元测试 (unit test) 还是production里当时都没有一个配额策略包含空值的情况，所以这个bug也就一直没有被触发。如果当时能触发这个bug，那么这个事故就会被限制在一个非常小的区域(canary)内而不会导致全球性的事故了。
2025年6月12日，该死不死的一些包含空值的配额策略终于被加入了基于Spanner的配额管理的数据库。Spanner是个高一致性分布式数据库，几秒钟之内在某个区域进行的修改就会被同步到全球。然后全球所有的配额管理程序但凡遇到这个策略就开始崩溃重启，然后继续崩溃(因为引起bug的配额策略一直在Spanner里)，Service Control就在全球范围挂了。
SRE被page之后动作很快，10分钟就找到root cause了。改这个配额策略很慢，不过好在他们有一个"red button flag" 可以直接禁用5月29日新增的这个功能 (check)，事故发生后40分钟包含这个禁用行为的代码被紧急部署到全球，Service Control开始陆续恢复。
但是事情还没完，在几个非常大的数据中心比如us-central-1，这些之前挂了的Service Control任务开始大规模在同一时间重启，然后在同一时间发送了大量的请求给底层的依赖服务，导致底层的服务过载并rate limiting这些任务，随后这些任务就继续重试。然而他们没有做随机指数退避算法 (Exponential Jitter Backoff Retry)，这就导致所有的重试也是发生在同一时间，底层的依赖服务永远在过载状态，而Service Control任务也永远无法恢复。SRE最后只能手动限制Service Control的任务数量，然后一点一点靠人工保证底层依赖服务不过载，最终耗费了大约2小时40分钟完全恢复了服务。
你以为这就结束了？并没有。。。
Cloudflare作为一个网络基建公司，提供包括但不限于CDN，网络安全，DDos防御，域名服务等，大量的互联网服务和产品都依赖于他们的网络。然而，作为一个基建服务，他们的一个全球分布式键值存储数据库Workers KV竟然是依靠Google Cloud这种云平台提供的Service Control服务来运行的，作为一个核心Key-value pair键值存储数据库Cloudflare内部的很多服务也是依靠它的，这就导致了Cloudflare也发生了全球性的宕机，进而演变成一个涉及半个互联网的大型事故。
草台班子。。。
说到这里，Google Search SRE 招人，我们没有受到影响，实力在线，有兴趣的留言。