2020年4月5号：Google Cloud Platform服务的错误率提高原因发布公告：
事件始于2020-03-26 16:14 ，终止于2020-03-27 05:55 （所有时间均为美国/太平洋）。
截至2020年3月27日（星期五）美国/太平洋地区，所有受影响的项目均已解决Google Cloud基础结构组件的问题。
问题摘要
2020年3月26日，星期四，美国/太平洋地区，Cloud IAM经历了更高的错误率，导致3.5个小时内许多服务中断，并且数据过时（导致部分服务的管理操作不断中断）持续14小时。Google对用户隐私和数据安全的承诺意味着，IAM是许多GCP服务中的常见依赖项。对于在此中断期间业务受到影响的Cloud客户，我们深表歉意–这不是我们努力为您提供的质量和可靠性水平，我们正在立即采取措施来改善平台的性能和可用性。我们已经进行了内部调查，并正在采取措施来提高服务的弹性。
根本原因
许多云服务依赖于身份和访问管理（IAM）中的分布式访问控制列表（ACL）来验证权限，激活新的API或创建新的云资源。这些权限存储在分布式数据库中，并大量缓存。有两个过程可以使数据库保持最新状态。一实时和一批。但是，如果实时流水线落后太久，则会提供过时的数据，这可能会影响下游服务的运行。
触发事件的原因是组成员身份的大量更新，扩展到意外高的修改后的权限数量，从而产生了大量积压的排队突变，需要实时应用。缓存服务器的潜在问题导致积压的处理性能下降，从而导致它们的内存不足。进而导致请求IAM超时。为缓解高内存使用情况而进行的紧急部署在各个地区使该问题暂时恶化。
补救与预防
一旦问题的范围在2020-03-26 16:35美国/太平洋地区明确后，Google工程师便迅速开始寻找可行的缓解措施。在17:06，手动启动了用于构建更新的缓存的脱机作业。此外，在17:34，重新启动了缓存服务器并增加了内存，并进行了配置更改，以便在调查继续进行的同时临时提供陈旧数据（有问题的批量更新之前的快照）。这减轻了第一个影响窗口。18:49在其他地区开始了第二个影响窗口。在19:13，开始了类似的尝试以减少额外的内存，从而通过19:42减轻了第二个影响窗口。修复过时数据的其他工作仍在继续，最后，最新的IAM数据脱机回填已加载到缓存服务器中。
Google致力于快速，持续地改进我们的技术和运营，以防止服务中断并在发生故障时迅速予以缓解。除了确保高速缓存服务器可以处理引发此事件的那种类型的批量更新之外，我们还在努力优化高速缓存服务器上的内存使用和保护，并允许紧急配置更改而无需重新启动。为了使我们将来能够更快地缓解数据过时问题，我们还将分派数据库批处理，以允许并行化和更频繁地运行。我们了解区域可靠性对我们的用户有多么重要，并对这一事件深表歉意。
影响的详细说明
2020年3月26日（星期四）美国/太平洋地区2020年3月16日至星期五（星期五）06：20，Cloud IAM经历了过时（陈旧）数据，其影响程度不同，如下所述。此外，多种服务遇到了Cloud IAM错误爆发。这些峰值聚集在16:35至17：45、18：45至19:00和19:20至19:40左右，但是每个Cloud区域的确切时间都不同。随着缓解措施在全球范围内的传播，错误率在后两个时期中高达100％。结果，许多云服务在多个区域出现并发中断，并且大多数区域都受到了一些影响。即使缓解后的错误率已恢复，但Google Groups的Cloud IAM成员[1]仍然过时，直到完整的事件得到解决为止。随着新批处理过程的完成，整个事件的严重程度有所不同，大约在16:14延迟了四个小时，在21:13延迟了9个小时。直接授予IAM角色的用户不受过时权限的影响。
Cloud云计算总结
因为对于某些公共平台的客户，是无法忍受哪怕一秒钟的停机服务的！
这也是为什么，用户那么害怕上云的最主要的原因之一！
您觉得，我们到底该做哪些准备呢？
我们真的准备好了吗？
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理
