2020年谷歌宕机事件回顾（官方事故报告）

以下为谷歌官方的事故报告：

问题摘要

2020 年 12 月 14 日星期一，需要谷歌 OAuth 访问且面向客户的谷歌服务出现死机，并持续了 47 分钟。GCP 工作负载使用的云服务（Cloud Service）帐户不受影响，仍然可以正常运行。谷歌向服务或业务在此次事件中受到影响的客户表示歉意，并将立即采取措施改善平台的性能和可用性。

根本原因

谷歌用户 ID 服务为每个帐户维护一个唯一的标识符，并处理 OAuth 令牌和 Cookie 的身份验证凭据。它将帐户数据存储在分布式数据库中，该数据库使用 Paxos 协议协调更新。出于安全原因，此服务在检测到过期数据时将拒绝请求。

谷歌使用一套不断发展的自动化工具来管理分配给服务的各种资源的配额。10 月份谷歌进行了一项更改，以便将用户 ID 服务注册到新配额系统，但旧版配额系统的部分内容未被删除，并错误地报告用户 ID 服务的使用率为 0。现有的执行配额限制宽限期延迟了影响，最终宽限期到期后，触发了自动配额系统减少用户 ID 服务允许的配额，并引发此事故。现有的安全检查旨在防止许多意外配额的更改，但当时它们并未涵盖单个报告负载为 0 的情况：

•大量用户的配额变更，因为只有一个组是变更的目标。

•将配额降低到使用量以下，因为报告的使用量被错误地报告为零。

•存储系统的配额过度减少，因为在宽限期内没有触发警报。

•配额低，因为使用率和配额之间的差异超出了保护限制。

因此，帐户数据库的配额被减少，这使得 Paxos leader 节点无法写入。不久之后，大多数读取操作都过期了，导致身份验证查询出错。

补救与预防

随着新配额的生效，问题的范围立即变得清晰。

美国/太平洋时间

12 月 14 日 03:43 时，容量自动警报响起，

03:46 时用户 ID 服务开始发生错误，客户受到影响

03:48 时向谷歌工程师发出了警报

04:08 时，谷歌工程师确定了根本原因并找出可能的解决方法

04:22 时禁用一个数据中心的配额执行机制，此举很快改善了情况。

04:27 对所有数据中心采用了相同的缓解措施

04:33 时，错误率已恢复到正常水平。

如下所述，一些用户服务需要更长的时间才能完全恢复。

除了解决根本原因之外，我们还将通过多种方式实施变更，以防止、减少此类故障的影响，并更好地就此类故障进行通告:

1.审查我们的配额管理自动化，以防止快速实施全局变更。

2.改进监视和警报，以更快地捕获错误配置。

3.在影响内部工具的故障期间，提高发布外部通信的工具和程序的可靠性。

4.在我们的用户 ID 服务数据库中评估并实施改进的写入失败防护机制。

5.提高 GCP 服务的弹性，以更严格地限制用户 ID 服务故障期间对数据平面的影响。

对于此事件对我们的客户及其业务造成的影响，我们深表歉意。我们非常重视任何影响客户可用性和可靠性的问题，特别是跨越多地区的事件。我们正在对该事件进行彻底的调查，并将根据调查结果做出的更改作为谷歌工程的首要任务。

影响的详细说明

2020 年 12 月 14 日星期一，美国/太平洋时间从 03:46 到 04:33，所有谷歌用户帐户的登录信息和帐户元数据查找失败。因此，我们无法验证用户请求是否已通过身份验证，并在几乎所有经过身份验证的流量上出现了5xx 错误。大多数经过身份验证的服务都受到了类似的控制平面影响：所有谷歌云平台（Google Cloud Platform），谷歌工作区 API（Google Workspace API）和控制台的错误率升高。在事件发生期间，产品继续正常提供服务，除非以下特别注明。大多数服务在 04:33 主要问题结束后的短时间内自动恢复。一些服务具有独特或持久的影响，下面将对此进行详细说明。

云端控制台（Cloud Console）

之前尚未通过云端控制台认证的所有用户均无法登录。已经通过身份验证的用户可以使用云端控制台，但是可能看到某些功能降级了。

Google BigQuery

在事件期间，流式传输请求返回了约 75％ 的错误，而 BigQuery 作业在全球范围内平均返回了约 10％ 的错误。

谷歌云存储（Google Cloud Storage）

在停机期间，对谷歌云存储（GCS）的请求大约有 15％ 受到了影响，特别是使用 OAuth，HMAC 或电子邮件身份验证的请求。在 2020 年 12 月 14 日美国/太平洋时间 04:31 之后，大多数影响已得到解决，然而，对于试图确定在此窗口中开始可恢复上传的不到 1％ 的客户来说，影响仍然存在。这些上传内容处于不可恢复状态，GCS 返回的错误代码表明是可重试的，但后续重试无法取得进展，导致这些对象未最终确定。

谷歌云网络（Google Cloud Networking）

网络控制平面的操作错误率持续上升，直到美国/太平洋时间 2020 年 12 月 14日 05:21 完全恢复为止。只有对数据平面 VPC 网络进行了修改的操作才会受到影响。数据平面中的所有现有配置仍可运行。

谷歌 Kubernetes 引擎

在事件期间，对 GKE 控制平面 API 的请求中约有 4％ 失败，几乎所有谷歌管理和客户的工作负载都无法向 Cloud Monitoring 报告指标。

我们认为，大约有 5％ 的 Kubernetes 控制平面请求失败了，但是由于未报告的 Cloud Monitoring 指标，因而没有得到准确的衡量标准。

中断后长达一个小时，约 1.9％ 的节点报告了诸如 StartGracePeriod 或 NetworkUnavailable 之类的状况，这些状况可能会影响用户的工作负载。

谷歌工作空间（Google Workspace）

所有谷歌工作空间服务都依赖谷歌的帐户基础架构来登录，身份验证以及对资源（例如文档，日历事件，Gmail 邮件）的访问控制进行实施。结果，在事件发生期间，所有经过身份验证的 Google Workspace 应用程序都关闭了。在美国/太平洋时间 2020 年 12 月 14 日 04:32 缓解此问题后，Google Workspace 应用程序恢复了，并且大多数服务在 05:00 之前已完全恢复。由于初始恢复后的流量激增，包括谷歌日历和 Google Workspace 管理控制台在内的一些服务出现错误并持续到 05:21 时。由于身份服务中的错误缓存，某些 Gmail 用户在恢复后长达一个小时内仍遇到错误。

云端支援（Cloud Support）

云端支援的内部工具受到影响，这延迟了我们与谷歌云平台（Google Cloud Platform）和 Google Workspace 状态仪表板上的客户发布故障通告的能力。客户无法在云端控制台（Cloud Console）中创建或查看故障信息，影响消除后，我们在美国/太平洋时间 2020 年 12 月 14日 05:34 时更新最新信息。

————————————————————

由谷歌宕机引发的思考——稳定性之面向失败设计【可靠性之容错】