不久前谷歌云发生了一次极其严重的生产故障，虽然只是影响了一个用户。但是这个用户名叫 UniSuper，澳大利亚最大的养老基金之一，管理着 60 多万人的 1240 亿美金。

这次故障持续了 2 周时间，从 2024.5.2 开始一直到 2024.5.15 完全恢复。在解决故障的过程中，UniSuper 的 CEO 几乎每天都会发邮件给用户同步进展，并且和谷歌云 CEO 一起发了几封联合声明。这样的举动在谷歌云历史上应该是首次，足见这次故障的严重程度。官方也用了 "one-of-a-kind occurence" 来形容。

前两天谷歌云也发布了复盘报告

作为前谷歌云工程师，下面也对这次谷歌云史无前例的故障做一个解读。

故障原因

谷歌云把 UniSuper 的私有云完全删除了。被删除的原因是在 2023 年，故障发生的一年前，一名操作人员使用了一个内部工具对 UniSuper 私有云进行了一次人工运维操作。不幸的是，在操作过程中，因为没有指定一个参数，导致根据默认值，该私有云会在一年后被删除。所以到了 2024.5.2，也就是一年期之时，谷歌云的内部系统就把整个 UniSuper 私有云给删掉了 🤯

而如此严重的故障通常是一系列偶然事件同时发生才导致的。

• 使用被弃用的内部工具。通常用户的服务为了高可用性，会在一个地域里的多个可用区部署多个副本。不过这个内部工具绕过了这些限制，能够一下子把整个地域的服务副本全部删除。因为一系列安全隐患，这个内部工具其实在 2023 年已经被列入弃用（deprecated）名单。在故障发生的时候，也已经下线了。但就像下面这幅描绘谷歌内部文化的漫画，虽然旧工具被打上了弃用标签，但是新东西还没有准备好。所以操作员那时依然还是需要使用旧的工具。

• 欠考虑的默认值。没有指定参数，导致使用了默认的一年删除时间。

• 没有对系统数据进行巡检。如果有巡检发现即将被删除的私有云，那就能通知相关人员，确认是否符合预期。

  
  

不幸中的万幸

虽然谷歌云自己的报告中并未提及，但在 UniSuper 官网上提到了它所幸在另一家云厂商那里有备份，所以得以最大程度地减少数据丢失。

感想

• 做好数据备份。对于一个企业是否要全面拥抱多云，业界并没有达成共识。但在备份这一点上，采用多云策略相对没有那么多争议。这次的故障就是一个证明，一个云服务商那里的数据全被误删了，还能从另外一家厂商恢复。

• 运维/控制面变更最好代码化（IaC），至少白屏化，通过界面 UI 操作。直接跑一个脚本，跑一个命令行这种太容易出错了。

• 一次严重故障背后，其实还有上百次的 near miss。出不同等级的故障是概率大小的问题。就像之前分析「阿里云大故障」说的，也不能因为一次大故障就拉黑，反而更可能的是谷歌云经历了这次事件后，会更加重视稳定性。