阿里云发生重大事故，凸显三大基础隐患

阿里云崩了。

12月18日，澳门司法警察局官微发布消息称，“由于阿里云的香港机房节点发生故障，导致澳门金融管理局、澳门银河、莲花卫视、澳门水泥厂等关键基础设施营运者的网站、澳觅和MFood等外卖平台、以及澳门日报等本地传媒应用程式，自今天（18日）中午开始暂时无法访问使用”。

不仅如此，甚至Linux中国的官网也因此而无法访问，很多个人站长也表示阿里云的长时间故障影响了他们网站的运营。

随后，阿里云在官网发布公告，称“香港地域某机房设备异常，影响香港地域可用区C的云服务器ECS、云数据库PolarDB等云产品使用，阿里云工程师已在紧急处理中。”

根据多方报道显示，此次阿里云宕机时间持续了超过12小时之久，如此长时间的持续性服务故障，在业界也属于相当罕见的事件，OKGroup的创始人徐明星甚至把此次故障称为“阿里云发展史上重大丑闻”。

长久以来服务器宕机一直是数据安全事故当中最为常见也是影响较大的问题之一，当云计算已成为现代企业最基础的底层设施之后，如何降低宕机对业务的影响，企业的安全系统建设是至关重要的。

阿里云一直号称是中国最大公有云服务商，更是声称自己获得了多项“全球第一”的殊荣。香港机房作为连接大陆内地与海外市场的桥头堡，其地位不可谓不重要。如此关键的数据设施，仅仅因为“制冷设备故障”就引发如此巨大的损失，且修复时间如此之缓慢，实在令人难以信任。

12月25日，阿里云终于发布了本次服务中断事件的官方说明, 说明中列举了事件的处理过程，服务影响，问题分析与改进措施。

这份报告可以看出，阿里云相关团队态度真诚。

但是，作为自称多项“全球第一”殊荣的云服务企业，再真诚的文字粉饰，也无法掩盖其专业度上的缺陷。

作者张栋伟今天就以粗浅的知识认知，就阿里云的官方说明所涉及的产品和技术问题，略举一二，与读者们探讨。

一、Status Page 形同虚设

阿里云的说明中提到：

“故障发生后阿里云启动对客钉群、公告等通知手段，由于现场冷机处理进展缓慢，有效信息不够。Status Page页面信息更新不及时引发客户困惑。”

而其改进措施是：

“提升故障影响和客户影响的快速评估和识别拉取能力。尽快上线新版的阿里云服务健康状态页面（Status Page），提高信息发布的速度，让客户可以更便捷地了解故障事件对各类产品服务的影响。”

Status Page 这个角度确实比较独特！

阿里云为什么在报告里面，以这么个专业词汇来负责事故的背锅呢？

于是，作者在网上搜索了一下业内关于阿里云本次宕机事故的评论，不看不知道，一看吓一跳，原来多位业界技术达人们的指责矛头，都是针对阿里云Status Page服务。

我们要知道任何云服务都不可能保证所有的后端和提供的服务都能始终维100%的可用性，所以当我们的线上业务出现问题时，首先需要确认的是，导致问题的原因是云的问题，还是我们业务环境自身的问题，此时，来自云平台的及时全面的健康状态信息至关重要。

例如，杨攀在他的《中国云服务走向全球？先把Status Page搞定》一文中，不仅阐述了Status page的重要价值，更是揭示出国内云服务商普遍不重视Status Page的现状。

而马工在他的文章《我们可以信任阿里云的故障处理吗？》则提到：

“作为云用户, 我们对云厂家的要求更高: 状态页之外, 还要有服务运行状况API”, 但是却“很遗憾的看到, 没有一家中国云厂家提供此类 API”。

“会说话的波吉”在其公众号发布的《给阿里云的一封公开信》中讲，阿里云 “显然整个服务可用性的页面变成了一个摆设”。并向阿里云提出 “建立可靠的服务状态信息页” 的要求。

这些文章在评述阿里云的同时，均分别举例了海外云厂商以及SaaS服务商在Status page方面的做法。

那么，海外的云服务厂商是如何提供Status page服务的呢？

以全球第一市场份额的亚马逊云（AWS）的Status page服务为例：

首先，时间早。

亚马逊早在2008年就开始提供一项叫作“Amazon Health”的专业的服务来做这件事情，可以公开提供 Amazon 全球所有Region，200多项服务的状态信息。

作为全球云计算服务的开创者之一和领导者之一，亚马逊云如此早期的就提供这种服务，就说明Status page类的服务是云厂商的基础服务。

而至今，国内很多云厂商要么根本没有这种服务，要么就是敷衍凑合。

其次，技术深。

Amazon Health服务，不仅仅提供一个公共看板，还提供跟客户账号相关的事件信息。而且亚马逊云有很明显“API First”的设计理念，Health这个服务也不例外，这种方式让解决方案更容易，跟IaC结合让运维更自动化。

在主流的开源生态中，IaC的部分对于AWS都是原生支持（而其他很多云服务企业还需要自己贡献或者开发者贡献，质量无法保证）, 例如比较流行的Terraform, Pulumi, Serverless Framework。AWS 服务中也针对IaC也做了多种方式的支持。

对IaC的友好支持让客户可以使用脚本或高级语言的方式来运维自己的云环境，结合CI/CD的方案进行自动化部署。当某个AZ甚至region出现问题的时候，只需要提前做好数据的跨可用区/地域的备份，即可自动在没有问题的可用区/地域段时间内重新拉起所有的服务，这有可能比等待服务恢复还要快！

这一点非常重要！

例如这次阿里云宕机事件中，如果在香港区域的客户选择了AWS，并且完成了跨可用区/地域的备份，那么当这次宕机发生时，自动运维就可以自动在备份区域重新拉齐服务，极大的减少业务损失。

所以，在这里也提示一下云服务的企业客户，在选择云厂商的时候，应该先做一下IaC的PoC验证。

最后，生态繁荣。

正是因为有了API, 才繁荣了生态。 Datadog，Splunk，Pagerduty公司都和Amazon Health进行了集成，已经形成了非常体系化和完整的解决方案。

选择云服务不是孤立的选择一款云产品，而是在选择一个生态，更完整的生态意味着更多的方案选择和满足紧急需求的可能性。

反观阿里云现在的Status Page服务，至今还只是一个看板，连订阅功能都找不到，这连亚马逊云14年前的功能都比不上。

（2022年12月28日，阿里云）

（2008年4月17日，亚马逊AWS）二、高可靠设计自欺欺人

“依赖”，是阿里云报告中最让人觉得搞笑的用词，整篇文章可以找到很多“依赖”。简单列举如下：

1、“单可用区高可用实例，由于依赖单可用区的数据备份...”

2、“支持跨可用区切换的RDS实例没有及时完成切换。经排查是由于这部分RDS实例依赖了部署在香港Region可用区C的代理服务”

3、“新扩容的ECS管控系统启动时依赖的中间件服务部署在可用区C机房，导致较长时间内无法扩容“

4、”ECS管控依赖的自定义镜像数据服务，依赖可用区C的单AZ冗余版本的OSS服务，导致客户新购实例后出现启动失败的现象。”

从阿里云官网可以明确看的，阿里云从2014年就开始拓展海外市场，香港Region也是那个时候对外运营，以香港为主的东南亚市场是阿里云海外投入最早的，也是具备优势的区域。

这次香港Region事故，一下子曝光出来，原来阿里云有这么多的高可靠服务都依赖不那么高可靠的服务。

作为运营最早、且已经有3个可用区的成熟Region都这样，那么阿里云有大量Reigon只有1-2个可用区的又会怎样？

使用这些区域的客户依赖阿里云的高可靠，然后阿里云的高可靠依赖低可靠。

这个风险系数，阿里云的客户知道吗？

除此之外，还有一个问题我特别想问问，“高可用的设计”是用来给人看的还是用来给人用的？

如果只是看看，那文档上写了确实算是合格了。如果运气好还真的有一部分代码写进去了，那真是走运啊。

如果是用的，有没有人验证过？

如果验证过，这么多问题之前没有发现么？

产品文档上发布功能的时候是因为有几行代码写进去了就算，还是功能实际验证过，并且经历过长时间的考验才算？

我对技术的理解，肯定不如阿里云的专家们深刻，但是类比一下同样是软件的自动驾驶功能，如果是这么交付的（代码写了就算有），谁敢用？

也许云行业还没有规范到发布产品和说明需要第三方去验证，但是我也常看到云厂商发布产品一般有Preview，Alpha，Beta之类的标签，然后最后上线的功能会有GA (General Availability)。

比如阿里云文档上有 “预发布功能用于对已测试通过的版本进行预发布（灰度），通过限定一个较小的发布范围来观察升级效果，提前发现问题。”

那么，我想问问你们能不能重新审查一遍文档，重新标注一下你们有多少东西只能算是“预发布”？

不对，按照阿里云的说法，对预发布的定义是“已测试通过的版本”。

那么，是不是以后需要再发明一个新的阶段？比如用来描述只是文档里有，代码里面也写了一些，但是能不能用不知道的功能阶段，比如“试试版本已经上线，研发说他写好了”。

三、基础设施捉襟见肘

为什么数据中心机房不配备气体消防？

在阿里云这次故障的“问题分析与改进措施” 中提到，“一机房包间温度达到临界值触发消防系统喷淋，电源柜和多列机柜进水，部分机器硬件损坏”。

阿里云的基础设施就这样？

（1）整篇文章为何看不到气体消防系统是否存在？

我还一度怀疑中国香港地区不支持气体消防，为了验证随手查看了香港消防局的政策文件。

香港认证的消防设备显然已经包括气体灭火。比如“FM-200灭火系统采用氮气加压，无水，激活后，FM-200会释放出气体以迅速降温并抑制火灾”。

另外，作者还查询到一些国际级数据中心的规范文档和知名供应商的宣传资料上，都提到关于消防部分数据中心应该采用惰性气体抑制系统。

（2）为什么冷机系统没有储水?

阿里云的故障说明提到“机房冷却系统缺水”，为何专业的数据中心冷机没有配套的储水系统？如果市政供水意外中断如何处理。

我很想知道阿里的数据中心有柴油发电备用么？里面有储油么？这些不专业的事情，万一出事儿是谁来买单呢？

此时要补一句，阿里云还是很厚道的，已经早早的提出了补偿方案，据说是可以让受损失的客户免费多用一个月。

（3）为什么冷机故障处理需要这么久？

从阿里云报告看“09:01,定位到冷机异常”，“12:30,冷机设备供应商到场”，在香港这样的城市经历3个半小时才有相关人士现场处理。“18:55，4台冷机恢复到正常制冷量”。

近7个小时，才解决了冷机问题！

现场读文档再操作的么？

这个冷机问题处理效率简直还不如普通的IDC机房。

下次如果UPS故障呢？

3个可用区的香港Region都这样，其他阿里云海外数据中心情况呢？

尾声：

云计算是2B的生意, 服务的客户大部分都是企业客户, 云服务商应该以专业的水准服务这些用户，而显然阿里云做的并不够，一份事故分析报告就已经暴露了三方面的问题。

今天，这些问题出现在了香港地区，如果这些问题找不到明确的答案，就很难不让人担心，明天会不会出现在全球的其他区域。

当然，即使云服务会由于诸多原因而发生故障宕机事件，但是相对于传统数据机房IDC服务，云服务已经极大降低了故障发生概率。

"Everything fails, all the time" 是我很欣赏的一句名言。既然“所有的东西最终都会坏”，那么设计上为何不能学下人家的“控制爆炸半径”。

通过此次阿里云故障事件，可以看出云服务在为企业提供更好，更便宜和更可靠的应用过程中，也不可避免会发生不同程度的故障，故障原因多种多样不仅与技术有关，在故障发生之前的监测和检测、故障发生后的修复和恢复、故障原因的排查和公布，也尤为重要。

云服务商应该更加重视数据中心基础设施、硬件设备和传输网络的可靠性和稳定性，对于不可预期的外部故障和事故，云服务商应汲取教训，积累经验，做好提前检测和压力测试，减少故障发生频率，也尽力减少故障对客户造成的损失。

类似亚马逊AWS这样可以充分保障用户权益的功能措施，应该成为所有云服务企业的标准配置。

作为用户的我们，也应该对云服务采取更加包容支持的态度。相信云服务在未来的发展过程中有望进入下一个发展阶段，服务于更多用户。

阿里云更应该通过这次事故真正看到差距和问题，加快向专业的水准迈进，才配得上国内第一公有云的称谓。

作者：张栋伟（资深互联网人士、市场营销专家、大学生就业创业导师）