作者：谷歌工程团队
问题摘要：2020年12月14日周一，需要访问谷歌OAuth的且面向用户的谷歌服务停运了47分钟。 GCP工作负载使用的云服务帐户没有受到影响，仍然可以正常运行。
根本原因
谷歌用户ID服务（Google User ID Service）为每个帐户维护一个唯一的标识符，并处理OAuth令牌和cookie的身份验证登录信息。它将帐户数据存储在一个分布式数据库中，该数据库使用Paxos协议来协调更新。出于安全原因，该服务检测到过时数据后将拒绝请求。
谷歌使用一套不断完善的自动化工具套件来管理为服务分配的各种资源的配额（quota）。10月份进行了一处变更，以便向新的配额系统注册用户ID服务，这是当时在进行的用户ID服务迁移到新配额系统的一部分，但是旧版配额系统的一些部分保留了下来，从而错误地报告了用户ID服务的使用为零。执行配额限制方面现有的宽限期延迟了影响，最终宽限期到期后，触发了自动配额系统减少留给用户ID服务的配额，并引发了该事件。现有的安全检查阻止了许多意外的配额变更，但当时它们并没有考虑到单个服务报告负载为零的情况：
针对大量用户的配额变更，因为只有一个用户组是变更的对象；
将配额降到低于使用量，因为报告的使用量被错误地报告成零；
存储系统的配额减幅过大，因为宽限期间没有触发警报；
配额低，因为使用量和配额之间的差异超过了保护限制。
因而，减少了帐户数据库的配额，这使得Paxos leader节点无法执行写入操作。没过多久，大多数读取操作变得过时，从而导致了身份验证查询出错。
缓解和预防
新配额生效后，问题的范围立即明确。美国/太平洋时间2020年12月14日03点43分，容量方面出现了自动报警，03点46分用户ID服务开始出错，客户受影响1分钟后，03点48分谷歌工程师收到了警报。04点08分，谷歌工程师确定了根本原因和潜在的解决方法，这导致在04点22分禁用了一个数据中心的配额执行机制。此举很快改善了情形，04点27分对所有数据中心采取了相同的缓解措施，到04点33分错误率已恢复到正常水平。如下所述，一些用户服务花了较长的时间才完全恢复。
除了解决根本原因外，我们还将通过多种方式，实施变更以防止此类故障、减小其影响并更及时地发布故障公告：
1.审查我们的配额管理自动化机制，以防止快速实施全局变更；2.改进监测和警报机制，以更快地发现错误的配置；3.提高在影响内部工具的故障期间对外发布公告的工具和程序的可靠性；4.评估和实施添加到我们用户ID服务数据库中的经过改进的写入失败防护机制；5.提高GCP服务的弹性，以更严格地限制用户ID服务故障期间对数据平面造成的影响。
对于此次事件对客户及其业务的影响范围，我们深表歉意。我们对待会影响客户可用性和可靠性的任何事件极为认真，尤其是影响多个地区的事件。我们正在对此事件进行彻底的调查，并将根据调查结果做出的变更视作谷歌工程部门的首要任务。
影响的详细说明
2020年12月1周一，美国/太平洋时间03点46分到04点33分，所有谷歌用户帐户的登录信息签发和帐户元数据查询都失败。结果，我们无法验证用户请求已通过身份验证，几乎所有经过身份验证的流量都出现了5xx错误。大多数经过身份验证的服务都受到了类似的控制平面影响：所有谷歌云平台、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网络进行修改的操作受到影响。数据平面中的所有现有配置仍可运行。
•Google Kubernetes Engine（谷歌Kubernetes引擎）
事件发生期间，针对GKE控制平面API的请求中约4%失败，几乎所有谷歌管理的工作负载和客户的工作负载都无法向Cloud Monitoring报告度量指标。
我们认为，针对Kubernetes控制平面的请求中约5%失败了，但是它们因未报告的Cloud Monitoring度量指标而没有准确的度量指标。
故障后长达一个小时，约1.9%的节点报告了StartGracePeriod或NetworkUnavailable之类的状况，这些状况可能对用户工作负载产生了影响。
•Google Workspace（谷歌工作空间）
所有Google Workspace服务都依赖谷歌的帐户基础架构来登录、验证身份以及对资源（比如文档、日历事件和Gmail邮件）执行访问控制机制。结果，所有经过身份验证的Google Workspace应用程序在事件持续期间都关闭了。2020年12月14日04点32分缓解此问题后，Google Workspace应用程序恢复正常，到05点00分大多数服务已完全恢复。由于初始恢复后流量激增，包括Google日历和Google Workspace Admin Console在内的一些服务出现错误，一直持续到05点21分。由于缓存来自身份服务的错误，一些Gmail用户在故障恢复后长达一个小时内都遇到错误。
Cloud Support
Cloud Support的内部工具受到了影响，这影响了我们在谷歌云平台和Google Workspace 状态仪表板上向客户及时发布故障公告的能力。客户无法在云控制台中创建或查看故障情况。我们在影响消失后的2020年12月14日05点34分向客户发布了最新信息。
问题摘要：2020年12月14日周一，需要访问谷歌OAuth的且面向用户的谷歌服务停运了47分钟。 GCP工作负载使用的云服务帐户没有受到影响，仍然可以正常运行。
根本原因
谷歌用户ID服务（Google User ID Service）为每个帐户维护一个唯一的标识符，并处理OAuth令牌和cookie的身份验证登录信息。它将帐户数据存储在一个分布式数据库中，该数据库使用Paxos协议来协调更新。出于安全原因，该服务检测到过时数据后将拒绝请求。
谷歌使用一套不断完善的自动化工具套件来管理为服务分配的各种资源的配额（quota）。10月份进行了一处变更，以便向新的配额系统注册用户ID服务，这是当时在进行的用户ID服务迁移到新配额系统的一部分，但是旧版配额系统的一些部分保留了下来，从而错误地报告了用户ID服务的使用为零。执行配额限制方面现有的宽限期延迟了影响，最终宽限期到期后，触发了自动配额系统减少留给用户ID服务的配额，并引发了该事件。现有的安全检查阻止了许多意外的配额变更，但当时它们并没有考虑到单个服务报告负载为零的情况：
针对大量用户的配额变更，因为只有一个用户组是变更的对象；
将配额降到低于使用量，因为报告的使用量被错误地报告成零；
存储系统的配额减幅过大，因为宽限期间没有触发警报；
配额低，因为使用量和配额之间的差异超过了保护限制。
因而，减少了帐户数据库的配额，这使得Paxos leader节点无法执行写入操作。没过多久，大多数读取操作变得过时，从而导致了身份验证查询出错。
缓解和预防
新配额生效后，问题的范围立即明确。美国/太平洋时间2020年12月14日03点43分，容量方面出现了自动报警，03点46分用户ID服务开始出错，客户受影响1分钟后，03点48分谷歌工程师收到了警报。04点08分，谷歌工程师确定了根本原因和潜在的解决方法，这导致在04点22分禁用了一个数据中心的配额执行机制。此举很快改善了情形，04点27分对所有数据中心采取了相同的缓解措施，到04点33分错误率已恢复到正常水平。如下所述，一些用户服务花了较长的时间才完全恢复。
除了解决根本原因外，我们还将通过多种方式，实施变更以防止此类故障、减小其影响并更及时地发布故障公告：
1.审查我们的配额管理自动化机制，以防止快速实施全局变更；2.改进监测和警报机制，以更快地发现错误的配置；3.提高在影响内部工具的故障期间对外发布公告的工具和程序的可靠性；4.评估和实施添加到我们用户ID服务数据库中的经过改进的写入失败防护机制；5.提高GCP服务的弹性，以更严格地限制用户ID服务故障期间对数据平面造成的影响。
对于此次事件对客户及其业务的影响范围，我们深表歉意。我们对待会影响客户可用性和可靠性的任何事件极为认真，尤其是影响多个地区的事件。我们正在对此事件进行彻底的调查，并将根据调查结果做出的变更视作谷歌工程部门的首要任务。
影响的详细说明
2020年12月1周一，美国/太平洋时间03点46分到04点33分，所有谷歌用户帐户的登录信息签发和帐户元数据查询都失败。结果，我们无法验证用户请求已通过身份验证，几乎所有经过身份验证的流量都出现了5xx错误。大多数经过身份验证的服务都受到了类似的控制平面影响：所有谷歌云平台、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网络进行修改的操作受到影响。数据平面中的所有现有配置仍可运行。
•Google Kubernetes Engine（谷歌Kubernetes引擎）
事件发生期间，针对GKE控制平面API的请求中约4%失败，几乎所有谷歌管理的工作负载和客户的工作负载都无法向Cloud Monitoring报告度量指标。
我们认为，针对Kubernetes控制平面的请求中约5%失败了，但是它们因未报告的Cloud Monitoring度量指标而没有准确的度量指标。
故障后长达一个小时，约1.9%的节点报告了StartGracePeriod或NetworkUnavailable之类的状况，这些状况可能对用户工作负载产生了影响。
•Google Workspace（谷歌工作空间）
所有Google Workspace服务都依赖谷歌的帐户基础架构来登录、验证身份以及对资源（比如文档、日历事件和Gmail邮件）执行访问控制机制。结果，所有经过身份验证的Google Workspace应用程序在事件持续期间都关闭了。2020年12月14日04点32分缓解此问题后，Google Workspace应用程序恢复正常，到05点00分大多数服务已完全恢复。由于初始恢复后流量激增，包括Google日历和Google Workspace Admin Console在内的一些服务出现错误，一直持续到05点21分。由于缓存来自身份服务的错误，一些Gmail用户在故障恢复后长达一个小时内都遇到错误。
Cloud Support
Cloud Support的内部工具受到了影响，这影响了我们在谷歌云平台和Google Workspace 状态仪表板上向客户及时发布故障公告的能力。客户无法在云控制台中创建或查看故障情况。我们在影响消失后的2020年12月14日05点34分向客户发布了最新信息。
文章来源： 云头条
网友评论
最新评论