Google Cloud 2025 年故障复盘：异常输入测试之外，还要控制变更扩散

Google Cloud 在 2025 年 6 月的故障说明：异常输入可能触发代码缺陷，而发布范围和恢复机制会决定影响如何扩大。输入测试需要与渐进变更、故障隔离和恢复演练共同设计。

官方报告确认了什么

Google 的复盘记录，6 月 12 日一项包含意外空字段的策略变更写入 Service Control 使用的数据表，并迅速复制到全球。策略检查触发空指针路径，使进程进入循环崩溃。报告还列出了功能开关、全球数据渐进传播、静态分析与测试、随机指数退避等改进方向。Google 官方事故报告

因此，不能把事故简单概括为“一个空值”或“没有做模糊测试”。空字段是触发条件，缺陷代码是直接机制，大范围传播和恢复压力则属于系统层问题。

把异常输入分成可验证场景

针对配置解析和策略检查，可从四类场景建立测试集：必填项缺失；值为空、零或超出范围；字段类型和组合不符合约束；新旧版本对同一字段的解释不一致。

这些输入必须真正到达被测逻辑。若测试入口过早丢弃畸变数据，覆盖率可能停在浅层校验；若绕过全部真实约束，又可能只触发生产中不可达的路径。测试设计需要说明入口、前置状态及预期行为。

模糊测试如何补充固定用例

覆盖率引导的模糊测试会变异已有输入，并依据执行到的代码区域探索更多路径。它适合补充手写边界用例，但发现能力受测试入口、种子语料、运行状态和观测手段影响。LLVM libFuzzer

一个可落地的做法是：先保存正常与异常配置样例，再接入解析及执行逻辑，同时监测崩溃、超时、资源占用和业务断言。对发现的问题缩减输入，保存环境与版本，修复后加入回归集。

发布与恢复也应进入验收

以下是由事故推导的工程检查建议：在小范围先验证配置，保留独立关闭新功能的方式，确认回滚不会依赖已经失效的控制面；同时演练大量实例重连时的限流与退避，并让必要的告警渠道具备独立性。

故障时采用何种降级方式，需要结合安全与业务要求决定。不能把某个服务的“失败放行”策略普遍应用于鉴权或高影响操作。

模糊测试通过能证明不会宕机吗？ 不能。它提供已测试范围内的证据，无法穷尽所有输入、状态和分布式交互。

一次异常值得留下长期用例吗？ 值得。能够重现的输入与预期结果，是防止同类缺陷再次引入的直接依据。