简单翻译：Google Cloud Infrastructure Components Incident #20013

2020年12月14日于美国时间太平洋时间，4时07分开始至6时23分，全球的GCP和Workspace服务中断。

原文

Google Cloud Infrastructure Components Incident #20013

事故总结

2020年12月14日周一，在为时47分钟的时间内，需要 Google OAuth 权限的 面向用户 Google 服务不可用。云服务账户不受影响。我们对因此次事故造成的服务和业务影响的客户致歉，我们正立即采取措施提高平台的表现和可用性。

事故原因

The Google User ID Service 为每个账户维护唯一标识以及处理 OAuth 令牌和 cookie。 它将账户数据存储在分布式数据库中，该数据库使用 Paxos 协议协调更新。出于安全原因，该服务检测到过期数据时会拒绝请求。

Google 使用不断演化的自动化工具套件管理为服务分配的各种资源的额度。作为正在进行的 User ID Service 的迁移至新额度系统的一部分，在2020年10月 User ID Service 使用新额度系统注册，但先前额度系统的一部分不正确地将 User ID Service 使用额度报告为 0。现存的基于额度限制的宽限期延缓这一影响，最终仍然过期，触发自动化额度系统减少服务的允许额度，引发本次事件。会有安全检查，来防御非计划中的额度变化，但并没有覆盖到单服务的零负载的情况：（以下是检查的范围 - 和未能触发的原因）

  • 大量用户的额度变动，然而只有一小部分是变动的目标。
  • 将额度降至使用量之下，然而服务的使用量错误报告为0。
  • 存储系统过量减少额度，然而宽限期中没有触发任何警告。
  • 低额度量，然而使用量和额度的差距量超过保护限制。

因此，账户数据库的额度减少，阻止 Paxos leader 写操作。不久之后，大多数读操作过期，导致鉴权查找错误。

修复与防护

(略去修复时间报告) Google将实现以下改变：

  1. 评审额度管理自动化系统，防止快速化全球更新（没看懂 D:）

  2. 改善监控和报警,更快地捕获不正确的配置信息。

  3. 改善用于发布因内部工具导致的服务停止的对外通讯工具和流程的可靠性。

  4. 评估并实现 User ID Service 数据库的写失败弹性改进。

  5. 改善 GCP 服务的弹性，以更严格地限制因 User ID Service 故障对数据平面的影响。

名词解释

workloads: 工作负载。包括无状态应用(Stateless applications), 有状态应用(Stateful applications), 批处理作业(Batch jobs), 守护进程(Daemons) data plane: On a network the Data Plane is the layer that has infrastructure to carry network traffic.

个人总结

拖了很长时间的翻译，其实是想通关翻译学习 Google 的事件处理报告的内容和应对方法。看下来其专业态度值得学习。精确到时间和影响到的服务内容、范围、地区、时间等 ,极大归功于其强大的基础设施。多看看大厂的资料，总能有不少收获。