跟是不是空指针关系不大

blog dot bytebytego dot com /p/how-the-google-cloud-outage-crashed

关键的工程失败

谷歌云服务中断并非单一错误造成的，而是一系列工程疏忽造成的，这些疏忽相互叠加。每个故障点，虽然单独来看很小，但却在将漏洞演变成全球性中断的过程中发挥了重要作用。

以下是导致整个问题的关键失误：

第一个也是最关键的失误是缺少功能开关。新的配额检查逻辑在所有区域都处于活动状态，无法在发布过程中逐步启用或禁用。功能开关是大型系统中的标准安全措施，允许在受控阶段激活新的代码路径。由于缺少功能开关，这个漏洞从一开始就存在于所有环境中。

其次，代码未能包含基本的空值检查。当引入包含空字段的策略时，系统未能妥善处理缺失值。相反，它遇到了空指针异常，导致处理该数据的每个区域中的服务控制二进制文件崩溃。

第三，谷歌的元数据复制系统完全按照设计运行。错误的策略数据几乎瞬间传播到所有区域，导致所有区域崩溃。全局复制流程没有内置延迟或验证检查点，无法在数据进入生产环境之前捕获格式错误的数据。

第四，“us-central1”区域的恢复工作暴露了另一个问题。当服务控制实例尝试重启时，它们会同时影响后端基础设施，从而产生“羊群效应”，导致区域 Spanner 数据库不堪重负。由于系统缺乏适当的随机指数退避算法，恢复过程非但没有缓解压力，反而产生了新的压力。

最后，监控和状态基础设施与核心系统一同出现故障。谷歌自己的云服务健康仪表盘在此次故障期间瘫痪，许多客户无法访问通常用于指导其响应的日志、警报或可观察性工具。这在危机高峰期造成了严重的可见性缺口。
--
FROM 222.129.207.*