自12月18日阿里云香港可用区C因为机房水冷机组出现故障，导致一次阿里云历史上最长的宕机后，官方终于在圣诞节那天，出具了一份非常翔实的调查报告《关于阿里云香港Region可用区C服务中断事件的说明》，称得上是实事求是面对问题了。

我从业十五年，参与建设过4000个节点的私有云，也搞过机房装修和上架，还有一点运维经验，算是有相关经验，跟大家讨论一下以后自家单位的容灾应该怎么做吧。

大家先看这次阿里云宕机事故的重点时间线，8点56就发现机房温控告警了，然后9点01就正确定位到制冷异常了。这个问题阿里云没有隐瞒的必要，因为机房突然升温，只能是空调（冷机）故障了。

12月25日，阿里云发布香港Region可用区C服务中断事件说明，并向所有受到故障影响的客户公开致歉，称将尽快处理赔偿事宜。阿里云表示，将尽一切努力从此次事件中吸取经验教训，持续提升云服务的稳定性。在说明中，阿里云公布了本次事件的故障情况、问题分析和改进措施，具体如下：

处理过程

12月18日08:56，阿里云监控到香港Region可用区C机房包间通道温控告警，阿里云工程师介入应急处理，通知机房服务商进行现场排查。09:01，阿里云监控到该机房多个包间温升告警，此时工程师排查到冷机异常。09:09，机房服务商按应急预案对异常冷机进行4+4主备切换以及重启，但操作失败，冷水机组无法恢复正常。09:17，依照故障处理流程，启动制冷异常应急预案，进行辅助散热和应急通风。尝试对冷机控制系统逐个进行隔离和手工恢复操作，但发现无法稳定运行，联系冷机设备供应商到现场排查。此时，由于高温原因，部分服务器开始受到影响。

自10:30开始，为避免可能出现的高温消防问题，阿里云工程师陆续对整个机房计算、存储、网络、数据库、大数据集群进行降载处理。期间，继续多次对冷机设备进行操作，但均不能保持稳定运行。

12:30，冷机设备供应商到场，在多方工程师诊断下，对冷塔、冷却水管路及冷机冷凝器进行手工补水排气操作，但系统仍然无法保持稳定运行。阿里云工程师对部分高温包间启动服务器关机操作。14:47，冷机设备供应商对设备问题排查遇到困难，其中一个包间因高温触发了强制消防喷淋。15:20，经冷机设备商工程师现场手工调整配置，冷机群控解锁完成并独立运行，第1台冷机恢复正常，温度开始下降。工程师随后继续通过相同方法对其他冷机进行操作。18:55，4台冷机恢复到正常制冷量。19:02，分批启动服务器，并持续观察温升情况。19:47，机房温度趋于稳定。同时，阿里云工程师开始进行服务启动恢复，并进行必要的数据完整性检查。

21:36，大部分机房包间服务器陆续启动并完成检查，机房温度稳定。其中一个包间因消防喷淋启动，未进行服务器上电。因为保持数据的完整性至关重要，工程师对这个包间的服务器进行了仔细的数据安全检查，这里花费了一些必要的时间。22:50，数据检查以及风险评估完成，最后一个包间依据安全性逐步进行供电恢复和服务器启动。

服务影响

12月18日09:23，香港Region可用区C部分ECS服务器开始出现停机，触发同可用区内宕机迁移。随着温度继续升高，受影响的服务器停机数量持续增加，客户业务开始受到影响，影响面扩大到香港可用区C的EBS、OSS、RDS等更多云服务。

阿里云香港可用区C的故障，没有直接影响客户在香港其他可用区运行的业务，但影响了香港Region ECS管控服务（Control Plane）的正常使用。因大量可用区C的客户在香港其他可用区新购ECS实例，从12月18日14:49开始，ECS管控服务触发限流，可用性最低跌至20%。客户在使用RunInstances/CreateInstance API购买新ECS实例时，如果指定了自定义镜像，部分实例在购买成功之后会出现启动失败的现象，由于自定义镜像数据服务依赖可用区C的单AZ冗余版本的OSS服务，无法通过重试解决。此时，部分Dataworks、k8s用户控制台操作也受到了故障影响。API完全恢复可用为当日23:11。

12月18日10:37，阿里云香港可用区C的部分存储服务OSS开始受到停机影响，此时客户暂不会感知，但持续高温会导致磁盘坏道，影响数据安全，工程师对服务器进行停机操作，从11:07至18:26中断了服务。阿里云在香港Region可用区C提供了2种类型的OSS服务，一种是OSS本地冗余LRS服务（通常叫单AZ冗余服务），仅部署在可用区C；另一种是OSS同城冗余ZRS服务（通常叫3AZ冗余服务），部署在可用区B、C和D。在此次故障中，OSS同城冗余ZRS服务基本没有受到影响。可用区C的OSS本地冗余服务中断时间较长，因不支持跨可用区切换，需要依赖故障机房的恢复。从18:26开始，存储服务器重新分批启动。其中，单AZ本地冗余LRS服务有部分服务器因消防问题需要做隔离处理。恢复服务前，我们必须要确保数据可靠性，花费了较多的时间进行完整性检验工作。直至12月19日00:30，这部分OSS服务（单AZ冗余服务）才恢复了对外服务能力。

阿里云网络少量单可用区产品（如：VPN、Privatelink以及少量GA实例）在此次故障中受到影响。12月18日11:21，工程师启动网络产品可用区容灾逃逸，12:45完成SLB等大部分网络产品可用区容灾逃逸，13:47NAT产品完成收尾逃逸。除上述少量单可用区产品以外，各网络产品在故障期间保持了业务连续性，NAT有分钟级业务受损。

12月18日10:17开始，阿里云香港Region可用区C部分RDS实例出现不可用的报警。随着该可用区受故障影响的主机范围扩大，出现服务异常的实例数量随之增加，工程师启动数据库应急切换预案流程。截至12:30，RDS MySQL与Redis、MongoDB、DTS等跨可用区实例完成跨可用区切换。部分单可用区实例以及单可用区高可用实例，由于依赖单可用区的数据备份，仅少量实例实现有效迁移。少量支持跨可用区切换的RDS实例没有及时完成切换。经排查是由于这部分RDS实例依赖了部署在香港Region可用区C的代理服务，由于代理服务不可用，无法通过代理地址访问RDS实例。我们协助相关客户通过临时切换到使用RDS主实例的地址访问来进行恢复。随着机房制冷设备恢复，21:30左右绝大部分数据库实例恢复正常。对于受故障影响的单机版实例及主备均在香港Region可用区C的高可用版实例，我们提供了克隆实例、实例迁移等临时性恢复方案，但由于底层服务资源的限制，部分实例的迁移恢复过程遇到一些异常情况，需要花费较长的时间来处理解决。

我们注意到，同时在多个可用区运行业务的客户，在这次事件中依然可以维持业务运行。对于业务需要绝对高可用的客户，我们持续建议您采用全链路多可用区的业务架构设计，以应对各种可能的意外事件。

问题分析与改进措施

1、冷机系统故障恢复时间过长

原因分析：机房冷却系统缺水进气形成气阻，影响水路循环导致4台主冷机服务异常，启动4台备冷机时因主备共用的水路循环系统气阻导致启动失败。水盘补水后，因机房冷却系统的群控逻辑，无法单台独立启动冷机，手工修改冷机配置，将冷机从群控调整为独立运行后，陆续启动冷机，影响了冷却系统的恢复时长。整个过程中，原因定位耗时3小时34分钟，补水排气耗时2小时57分钟，解锁群控逻辑启动4台冷机耗时3小时32分钟。

改进措施：全面检查机房基础设施管控系统，在监控数据采集层面，扩大覆盖度，提升精细度，提高对故障的排查和定位速度；在设施管控逻辑层面，确保系统自动切换逻辑符合预期，同时保证手工切换的准确性，防止内部状态死锁从而影响故障的恢复。

2、现场处置不及时导致触发消防喷淋

原因分析：随着机房冷却系统失效，包间温度逐渐升高，导致一机房包间温度达到临界值触发消防系统喷淋，电源柜和多列机柜进水，部分机器硬件损坏，增加了后续恢复难度和时长。

改进措施：加强机房服务商管理，梳理机房温升预案及标准化执行动作，明确温升场景下的业务侧关机和机房强制关电的预案，力求更简单有效，并通过常态化演练强化执行。

3、客户在香港地域新购ECS等管控操作失败

原因分析：ECS管控系统为B、C可用区双机房容灾，C可用区故障后由B可用区对外提供服务，由于大量可用区C的客户在香港其他可用区新购实例，同时可用区C的ECS实例拉起恢复动作引入的流量，导致可用区 B 管控服务资源不足。新扩容的ECS管控系统启动时依赖的中间件服务部署在可用区C机房，导致较长时间内无法扩容。ECS管控依赖的自定义镜像数据服务，依赖可用区C的单AZ冗余版本的OSS服务，导致客户新购实例后出现启动失败的现象。

改进措施：全网巡检，整体优化多AZ产品高可用设计，避免出现依赖OSS单AZ和中间件单AZ的问题。加强阿里云管控平面的容灾演练，进一步提升云产品高可用容灾逃逸能力。

4、故障信息发布不够及时透明

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

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

这个事故的主要原因，就是因为制冷设备整整10个小时不能恢复工作，机房升温太快，工程师为了保护数据，只能逐步关机。

次要原因是，在关机后还是有某个包间因为温度过高导致喷淋装置启动。手机和电脑不能进水都已经是常识了，服务器上淋了水那还得了？

再次原因，就是阿里云香港Reigon的架构设计，同样没有遵循自己提到的「全链路多可用区的业务架构设计」，新扩容的ECS管控系统启动时依赖的中间件服务部署在可用区C机房，导致可用区C一旦宕机，扩容服务也启动不了。相信后续阿里云一定会全网巡检，整体优化多可用区高可用设计，避免制造单点故障，类似依赖OSS单AZ和中间件单AZ的问题，再次出现就说不过去了。

第四个原因，是对于云服务来说，高可用架构能够保障是某几台物理服务器（ECS、OSS、RDS）因为故障宕机时，原来的应用可以漂移到同一个AZ（可用区）的其他服务器上，保证服务的连续性和数据的可用性。但是原有复杂的分布式架构在一个AZ（可用区）整体出现网络、服务器、存储全部下线的时候，国内没有厂家敢于承诺100%实现全量无伤漂移到其他可用区，或者其他机房的。

打个比方，如果把中国大陆看成一个CN可用区，那么当武汉或者上海出现疫情的时候，是能够把病人疏散到其他城市去治疗，缓解自身医疗压力的。但是当举国上下都遭遇新冠的时候，病人还能往哪送？阿里云这次遭遇的是一个AZ（可用区）整体下线，里面近千个机柜、上万台设备的数据，又能切换到哪里？

第五个原因，是对极小概率事件的应急预案，是没法考虑得那么周详的，甚至完全考虑不到。比如谁能提前考虑服务器被喷淋装置喷水导致损坏的场景？谁能考虑一个主备配置4+4的水冷机组，能够同时出现故障，修好却需要10个小时？

第六个原因，是对于一个巨型系统来说，有能力搞清楚里面所有的细节的总工程师，一定在新项目上，绝不是去搞运维浪费人才。其他的成员都是分模块承担任务的，他们只能选择信任其他模块。例如搞数据库（RDS）的同学关注的是支持跨区迁移，谁能考虑到跨区迁移依赖的反向代理竟然不是跨区高可用的，结果大部分数据库成功迁移了，但是香港可用区C一旦宕机，依赖这个反向代理的的数据库就迁移不了。

所以，我来点评一下。

1、假的主备冷机系统

阿里云宕机的主要原因是机房主备水冷机组共用了同一个水路循环系统，存在单点故障，修这个就用了10个小时。然而这个机房还只是阿里云租的。查了一下阿里云香港C区所在的机房，应该是下图的香港粉岭安汇中心/安乐电话机房。（来自知乎@香港sim精神小伙）

这个机房原来是PCCW电讯盈科的，然后Vantage(数据中心园区提供商，其母公司是纽交所上市公司，代码DBRG）在2021年刚刚收购了电讯盈科的数据中心。

《Vantage Data Centers 完成对 PCCW DC 的收购，将其一流的超大规模数据中心平台带到香港和吉隆坡 – Vantage Data Centers》

这两栋机房同属Vantage的HKG1园区，大概机房参数如下：

所以阿里云也是倒霉，租了个机房还换了东家。换了东家之后，最了解情况的中基层领导很可能已经被扫地出门了，Twitter不就是这样么？所以故障响应就会不及时。

修个水冷机组还要用10个小时，其中真正有效的时间就是排水补气的3小时，除此之外，定位原因怎么要用3个半小时的？这个水冷机组的服务商也挺废物的。

定位原因的3个半小时，就是设备维护商赶到现场的时间。一个重要数据中心的冷机坏了，香港的设备维护上用了3个半小时才到达现场，这种服务水平和响应速度极不可靠，从深圳到广州也用不了三个小时吧。

另外，解锁群控逻辑，手动启动4台冷机，竟然要用3小时32分，也说明服务商的工程师对这个系统根本都不熟，大概率是照着操作手册现学现卖的。

2020年，微软Azure位于美国东部的数据中心发生服务中断，持续六小时。微软披露说，冷却系统故障是导致这次停机的原因，发生故障的楼宇自动化控制导致气流减少，随后整个数据中心的温度峰值阻碍了网络设备的性能，使计算和存储实例无法访问。但是微软的信息披露没有阿里云这一次这么翔实，这一点还是要给阿里云的实事求是点个赞。

2021年11月，网易游戏机房大规模服务器宕机，原因同事是机房过热，空调重新开机也没有解决问题。但幸好这只是游戏服务器，玩家是可以接受的。但是大陆的服务更到位，网易的宕机只用了3小时就恢复了。

2022年夏天，伦敦的谷歌云及甲骨文数据中心出现制冷系统故障，导致数据中心气温升高，产生宕机。甲骨文的是系统自动采取保护措施关闭作业，于是业务宕机；谷歌的是温度过高导致存储故障，引起虚拟机宕机，然后谷歌也关闭了一部分机器。

2、数据中心机房用喷淋

所以根据《建筑设计防火规范》GB50016规定，重要机房、配电房是需要做气体自动灭火，这是中国大陆的规定。

但是我国的国标之间也有冲突，比如根据《《数据中心设计规范》GB 50174-2017》，只要数据中心的系统在其他数据中心内有承担相同功能的备份系统时，也可以设置自动喷水灭火系统。这个规范的主编单位是中国电子工程设计院。

我在2010年参与了苏州国科数据中心Tier-IV机房项目，当时是东北亚最高端的机房，那时候我们用的就是七氟丙烷气体灭火。参见《运营环境 苏州国科数据中心》

为什么要用对人体有微毒性的七氟丙烷灭火，而不是用干粉、气水雾或者喷淋方式灭火呢？因为电子设备就没有不怕水的，干粉也会对设备造成伤害。顺口再说一句，国外声称他们重视员工生命，所以建议少用这种有毒的气体灭火方式。这方面很多公司都参考了美国消防协会NFPA的标准，国际某个头部的云厂商也有不少这类设计。

我参与的项目还是经受住了考验，2022年10月13日，苏州国科数据中心A2栋建筑屋顶备用冷却塔起火，半小时后扑灭，但是建筑内的苏州超算中心数据机房安然无恙，数据没受影响，说明气体灭火还是极有必要的，要不然超算中心就无了。

当然，气体灭火也有弊端，比如对空间有要求，大于3600平方就达不到消防效果，这些在国标里都有提及。此外气体的储备量也是有限制的。

这个机房原来是PCCW电讯盈科的，也是资深数据中心运营商，真的会这么离谱么？《电讯盈科PowerBase方案》里面也写的非常清楚，数据中心对制冷机组、供电机组全年无休监控。现在看来，制冷机组的监控明显失灵，反而是机房先升温告警，然后才找到了制冷机组的问题。

虽然这次故障的源起是机房。但硬件设备的能力和可靠性是有限的，这就是为什么有云计算的原因。我认为，我们需要提升数据中心设施的可靠性，但不应该只专注于此。云计算不应当如此严重的依赖于单个机房，阿里云更应该做的是提升云产品的稳定性，加强整个AZ层面的灾备演练。

我们该怎么自保？

IDC圈盘点了近几年的前十大数据中心灾难事故，《盘点：近年数据中心十大灾难事件_机房_火灾_服务器》，包括2020年韩国SK公司数据中心火灾，影响了3.2万个服务器；2021年3月，欧洲云计算巨头OVH在法国的数据中心严重火灾，一共4座数据中心，有一座被完全烧毁。导致法国360个政府、企业与公共事业网站直接瘫痪。

2021年，河南多机房因汛情断电，还有位于河南的数据中心出现机房进水情况；2022年谷歌数据中心电气爆炸，影响了40多个国家的1338台服务器。这种事一篇稿子都写不下。

所以，重要应用和数据，请务必做到狡兔三窟，一定要充分考虑云主机的单点故障，做好多可用区的高可用，做好数据的容灾和备份；千万不要全盘相信连锁型的自动化操作。

在极端情况下，全自动化操作容易导致出现多米诺骨牌一样的连锁反应。比如这次阿里云香港机房的冷机就是群控启动的，死活就启动不起来。因为再完备、再安全、再可靠的自动化方案，哪怕平时运转非常正常，赶上寸劲和巧合，总会出现无法预计的问题。

人体的设计也有这种Bug，当免疫系统在体内杀新冠病毒杀疯了的时候，他才不会管人体是否受得了，直接烧到42度，或者免疫风暴走起。反正新冠病毒总得死，但是人会不会死，免疫系统不在乎。

自动喷淋灭火系统也是，反正只要温度过高我就要喷水，我的任务是保证火被扑灭了，但是物理服务器进水会不会损坏，自动喷淋灭火系统不在乎。特斯拉也是，他的自动控制系统只负责接管车辆驾驶，至于是不是刹车失败，会不会造成人员伤亡，自动控制系统不在乎。

我的群晖NAS有100T的容量，其中有5T工作文档数据，算是我十五年来攒下的命根子。两个月之前，我在三天里连续坏了两块硬盘，真的是吓出一身冷汗；我做了Raid5，如果只坏一块盘，数据是可以恢复的；但是如果同时坏了两块盘，那我事务的数据就全game over了。

在这件事情之后，我直接搞了个同城灾备和异地容灾。同城灾备是我买了一块16T的硬盘，接在群晖NAS上，把我的重要数据每日备份；异地容灾就是一年几百块买了阿里云盘，映射成WebDAV，也是每天备份我的重要数据，这样才能保证数据可靠性。

对于应用服务来说，一定要考虑好安全性，比如反亲和性，两台虚拟机不要放在同一台物理机上；比如做好镜像备份和容器的编排，在异地设置好备份，保证必要的时候可以快速在异地拉起容器；比如做好数据库的异步同步，基本保证数据的一致性，在应用里不要直接写死数据库的IP地址，还是要用域名指向。

比如2019年3月，腾讯云上海南汇机房的光缆被施工挖断，等于所有网络都不通了，暖暖、QQ 飞车，王者荣耀，吃鸡等 90 多个服务受到影响，这种问题就属于意外，也没法问责云厂商。

所以，如果老板问为什么要花这么多资金和人力来搞容灾，那就可以告诉老板，不管是谷歌云、甲骨文、微软云、阿里云、还是腾讯云，全都出过故障，只要是服务，就有不可用的时候，所以靠谁不如靠自己。像阿里云这次故障中，在架构层面设计了多可用区高可用方案的客户，就完全没有受到影响，当然，安全是需要额外成本的。

每个公司都是自己业务应用和数据的第一责任人，不应该也不能把希望全部寄托在云厂商身上。

比如2021年3月，云厂商OVH在法国的数据中心起火之后，游戏《Rust》表示，25台欧洲服务器完全损毁，没有备份，数据无法被修复。你说这个数据丢失的主责是云厂商OVH，还是游戏运营商呢？像阿里云香港机房本月的可用时间大约是98%左右，也会按照规则赔偿25%的月费用，但是用户的业务稳定和数据安全，能全部依赖于供应商么？当然不能。

阿里云这一次的信息披露，算是这么多家云厂商中最坦诚、最详尽的了，也是给各个企业一个充分的经验借鉴，让大家在容灾方案设计时，除了保证应用和数据的高可用，还要考虑中间件的高可用；除了考虑自身的架构设计，也要考虑租赁的数据中心的制冷和防火设计者有没有脑血栓

毕竟人生中充满了黑天鹅事件，我们除了积极应对风险，还能怎么办呢？狡兔务必三窟就是唯一的答案。

参考资料

[1]

香港sim精神小伙: https://www.zhihu.com/people/15217944045

[2]

Vantage Data Centers 完成对 PCCW DC 的收购，将其一流的超大规模数据中心平台带到香港和吉隆坡 – Vantage Data Centers: https://vantage-dc.com/news/vantage-data-centers-finalizes-pccw-dc-acquisition-to-bring-its-best-in-class-hyperscale-data-center-platform-to-hong-kong-and-kuala-lumpur/[3]

运营环境 苏州国科数据中心: http://m.sisdc.com.cn/operatingEnvi.html