这次阿里云的故障又刷爆全网，目前官网的公告只阐述了时间线，没有透露任何的技术细节。内部肯定在连轴转，准备详细的复盘报告。在官方发布报告前，我先来尝试分析一下这次故障的原因。毕竟之前在 GCP 呆过 5 年，虽然自己没能搞出过那么大的新闻，但这类故障的配方我还是熟悉的。。。事先声明，所有猜测基于外部信息结合个人经验，难免会和事实有所出入。

症状分析

首先看到影响面是全球

影响的服务是 API 调用，以及依赖 API 调用的控制台。

像阿里云这样做了单元化的云架构，能引发全球故障的组件并不多。一个是网络，一个是访问系统。

提到了底层服务组件，那基本就是访问系统了。因为如果是网络的话，一般会直接说网络问题。阿里云的访问控制系统叫 RAM (Resource Access Management)

RAM 里的用户和用户组都是全局资源，从 API 的 CreateUser 能看到

相对的其他绝大多数服务的资源都不是全局的，比如 ECS，创建时要指定 Region 地域和 Zone 可用区

根因猜测

变更引起

变更有三种类型，一种是应用代码变更，一种是配置变更，一种是数据库变更。我想可以先排除数据库变更，因为如果是数据库变更的话，故障无法那么快恢复（1 小时的故障不算短，但如果是数据库变更导致的问题，恢复时间会更长，因为要处理脏数据）。

代码变更和配置变更都有可能。猜测代码变更的原因是从恢复的方式看，是以逐步重启组件完成的，那么可能是新的代码版本发出去后，出现了问题，然后又陆续回滚。

不过我更倾向于是配置变更，原因是：

1. 一般应用代码的变更，会更严格遵循灰度发布，像 RAM 这种核心服务，新版本往往会按天按地域分批发布，从周一开始一直发布到周四，不太会造成全球级别的故障。虽然 RAM 资源是全局的，但是它服务的接入点是分地域的，所以如果是应用代码 bug 的话，不会一下子全挂。

   
   

1. RAM 这样的系统会使用不少的配置来控制策略，而配置的发布通常不会有像代码变更那样长时间的灰度过程（因为配置本身就是为了针对能更灵活地改变软件行为而设计的）。有时一个全局配置推送出去后，经过一些简单的检查之后，很快就会同步到各个分区。所以坏的配置更容易造成全球故障。

2. 组件重启的原因，也可能是因为配置问题导致内存状态被污染了，所以最快恢复的方式是重启。

非变更引起

但故障发生的时间点在周日下午 17:44，正常是不会在周五以及休息日做变更的。所以也有可能是非变更引起的。可能就是跑 RAM 一个组件的硬件突然坏了，容灾失灵，导致容量不够，结果引起了雪崩，类似下图这样。

工程师恢复服务也需要一定的时间，因为先要做限流，不然新服务刚拉起来，立刻会被无数堆积的请求压垮，又崩了（thundering herd）。所以需要步步为营（bootstrap），慢慢起服务。

差不多就这些吧，重大的事故，往往都是几个小概率事件同时发生的结果。等阿里云官方的复盘报告出来后，再去观摩学习一下，引以为戒。另外也没有必要因为阿里云的这次事故而恐慌，跑到其他云或者下云。相信这次事故之后，阿里云肯定会投入大量的资源来保障稳定性。