谷歌云称，因忽视其常规代码质量保护机制而导致服务中断

上周四，谷歌云（Google Cloud）发生了一次大规模服务中断事件，导致客户至少三个小时内无法访问其租用的基础设施。在这次事故中，Cloudflare 也是受影响客户之一——由于谷歌的错误，其服务也出现了不稳定，进而影响到了 Cloudflare 的用户。

谷歌在其发布的事故说明中写道：“我们的 API 和 Google Cloud 的 API 是通过 Google API 管理与控制平面来提供的。”

这两个“平面”是按区域分布的，它们“负责确保每一个传入的 API 请求都经过授权，并具备相应的策略和检查机制（如配额限制），以满足请求端点的需求。”

这个策略检查系统中的核心二进制组件被称为 “Service Control（服务控制）”。

谷歌在报告中指出：“Service Control 是一个区域性服务，它从一个区域数据存储中读取配额和策略信息。这些数据存储的元数据几乎可以实时在全球范围内复制，用于管理谷歌云及其客户的配额策略。”

5 月 29 日，谷歌为 Service Control 添加了一个新功能，以支持“额外的配额策略检查”。

这份事故报告解释道：“这次代码变更和二进制发布是逐步在各个区域部署上线的，但由于触发这段代码需要更改策略，因此在部署过程中并未真正运行到出问题的代码路径。”

谷歌似乎对这一改动有所顾虑，因此为其添加了一个“一键关闭该策略路径”的红色按钮（red-button）。

但问题是，“这段代码没有适当的错误处理机制，也没有使用功能开关进行保护。缺少恰当的错误处理机制，导致空指针异常使二进制程序崩溃。”

谷歌通常会使用功能开关来检测代码中的潜在问题。

“如果这段代码受到功能开关保护，这个问题本应在测试环境中就被发现。”

这段未受保护的代码在谷歌内部运行了直到 6 月 12 日，当天公司更改了一项包含“意外空白字段”的策略设置。

接下来发生了以下情况：

Service Control 在各区域开始根据各自的区域数据存储执行配额检查。这项操作引入了此次策略变更中的空白字段，从而触发了那段存在空指针异常的代码路径，最终导致所有二进制文件陷入崩溃循环。而由于每个区域都进行了部署，因此这次故障是全球性的。

谷歌表示，其站点可靠性工程团队在两分钟内就发现了问题并开始初步分类，在 10 分钟内确定了根本原因，并在 40 分钟内启动了恢复流程。

但在一些规模较大的谷歌云区域中，“当 Service Control 任务重启时，对其所依赖的基础架构产生了‘羊群效应’，导致底层基础设施过载。”

由于 Service Control 并未设计为能应对这种情况，因此在较大区域中，问题整整花了将近三小时才得以解决。

那些因这场混乱而停摆的谷歌产品团队随后不得不各自开展恢复工作。

谷歌承诺将不再重复导致此次宕机的错误——这和以往每次类似事件后的表态一样。

但这一次，公司还承诺了一些运营上的改进措施，具体包括：

• 我们将改进对外沟通机制，包括自动化和人工沟通渠道，以便让客户尽快获得所需信息，及时应对问题、管理自己的系统，并帮助他们的客户。
• 我们将确保监控和通信基础设施即使在谷歌云和主要监控产品出现故障的情况下也能正常运行，从而保障业务连续性。

这些举措实际上承认了谷歌在此次宕机期间未能向客户提供足够的信息，并计划对此做出改变。

这也意味着谷歌实质上承认了：它无法完全避免大型宕机的发生。