2025 年 6 月 12 日，Google Cloud 经历了一次重大故障，导致 Gmail、YouTube、Google 搜索、Google Cloud API 以及众多依赖其服务的互联网应用出现大规模中断。这次故障从太平洋时间 10:51 开始，直到 18:18 才完全解决，持续了约 7 小时 27 分钟。
根因分析
据 Google Cloud 发布的报告，此次故障产生的根本原因是一个新功能在没有经过充分测试和灰度发布的情况下被直接部署到生产环境，并且处理推送关键配置没有灰度过程。具体来说有以下几个环节：
故障引入：新功能部署
Google Cloud 为 Service Control 系统添加了一个新功能，用于配额策略检查。这个功能在没有经过充分测试和灰度发布的情况下被直接部署到生产环境。
设计缺陷：错误处理不足
新添加的功能缺乏适当的错误处理机制，特别是对于意外的空字段（blank fields）没有进行处理。根据 Reddit 上的信息，代码中存在致命缺陷：无法处理策略数据中的意外空字段。
故障触发：空指针异常
推送新配置，当系统遇到空字段时，代码抛出了空指针异常（null pointer exception），导致 Service Control 实例完全无响应，并进入崩溃循环（crash loop）状态。
连锁反应：全球服务中断
由于推送新配置没有灰度过程，导致配置在全球范围几秒内迅速生效，且 Service Control 是 Google Cloud 的核心组件，负责 API 管理和配额控制，其故障导致了连锁反应，影响了众多依赖 Google Cloud 的服务和应用，造成了全球范围的互联网中断。
配置灰度及常见的实现路径
什么是配置灰度发布
配置灰度发布是一种软件配置变更策略，通过逐步将新的配置参数发布给一部分服务实例或用户，以降低全量发布可能带来的风险。它允许在不影响大多数用户的情况下，验证新配置的有效性和稳定性。
配置灰度的核心思想是在黑（旧配置）与白（新配置）之间，实现平滑过渡的一种发布方式，确保系统稳定性的同时逐步引入新的配置变更。
配置灰度的主要应用场景包括配置参数调整、功能开关切换、系统阈值修改等需要谨慎变更的配置场景，特别适用于高可用性要求的核心业务系统。
配置灰度的常见实现路径
配置灰度发布作为一种降低风险的发布策略，有多种实现路径。根据不同的业务需求和技术架构，可以选择最适合的实现方式。以下是几种常见的配置灰度发布实现路径：
● 基于标识的灰度发布
○ 用户 ID 灰度：根据用户 ID 特征（如尾号）决定是否应用新配置
○ IP 地址灰度：基于服务实例 IP 地址进行灰度发布
○ 设备特征灰度：根据设备类型（如 iOS/Android）进行灰度
● 基于规则的灰度发布
○ 白名单/黑名单：通过维护特定名单控制配置应用范围
○ 标签灰度：给服务实例添加标签，根据标签决定配置版本
○ 业务规则灰度：基于业务场景或特定条件进行灰度
● 基于流量的灰度发布
○ 比例灰度：按照一定比例的流量应用新配置
○ 区域灰度：根据地理位置或区域进行灰度发布
○ 时间窗口灰度：在特定时间段内进行灰度发布
● 基于架构的灰度发布
○ 服务网格灰度：利用服务网格技术控制配置分发
○ 网关灰度：在 API 网关层面实现配置灰度
○ 配置中心灰度：通过配置中心直接控制配置分发
