为什么阿里云香港主机停机这么久？恢复服务要多久

2022年12月18日08:56，阿里云监控系统首次检测到香港Region可用区C机房出现温控异常告警。这一看似普通的设备故障，最终演变为阿里云运营史上持续时间最长的大规模服务中断事件，历时超过15个半小时。机房冷却系统的异常运转导致温度持续升高，工程师在09:01迅速定位到冷机异常，但随后的应急处置却遭遇了重重阻碍。

在水冷系统中，缺水进气形成的气阻严重影响了水路循环，导致4台主冷机服务异常。当启动备用的4台冷机时，由于主备共用的水路循环系统存在相同问题，启动操作以失败告终。冷机设备供应商直到12:30才抵达现场，开始对冷却系统进行手工补水排气操作，但系统仍无法保持稳定运行。

应急处置的连环困境

整个故障处理过程充满了技术挑战和意外状况。在09:17启动制冷异常应急预案后，工程师尝试了辅助散热和应急通风等多项措施，但冷机控制系统始终无法稳定运行。随着温度不断攀升，阿里云工程师被迫从10:30开始对整个机房的各类服务进行降载处理，以避免可能发生的消防问题。

最严峻的时刻出现在14:47，一个高温包间触发了强制消防喷淋系统。喷淋导致电源柜和多列机柜进水，部分机器硬件遭受损坏，进一步增加了恢复难度。直到15:20，经设备商工程师现场手工调整配置，才成功将冷机群控解锁并转为独立运行，第一台冷机得以恢复正常。

关键系统的多米诺骨牌效应

此次故障的影响范围犹如多米诺骨牌般逐步扩大：

• 09:23：香港Region可用区C部分ECS服务器开始停机，触发同可用区内宕机迁移
• 10:17：部分RDS实例出现不可用报警
• 10:37：存储服务OSS开始受到停机影响
• 11:07至18:26：OSS服务完全中断

值得注意的是，阿里云香港Region的架构设计存在明显缺陷，ECS管控服务所依赖的中间件服务集中部署在可用区C机房，导致该可用区宕机后，新购ECS实例等管控操作完全无法执行。

恢复过程的艰难推进

从18:55开始，4台冷机陆续恢复到正常制冷量，但服务的全面恢复仍需经历复杂过程。19:02起，工程师开始分批启动服务器，并密切监测温升情况。到19:47，机房温度终于趋于稳定，服务启动恢复和数据完整性检查工作随即展开。

工程师对这个包间的服务器进行了仔细的数据安全检查，这里花费了一些必要的时间，因为保持数据的完整性至关重要。

受影响最严重的OSS本地冗余LRS服务直至12月19日00:30才恢复对外服务能力，而同城冗余ZRS服务则基本未受影响。

故障根源的系统性分析

阿里云在事后公告中承认了四大核心问题：

1. 冷机系统故障恢复时间过长：原因定位耗时3小时34分钟，补水排气耗时2小时57分钟，解锁群控逻辑启动冷机耗时3小时32分钟
2. 现场处置不及时导致消防喷淋触发：高温环境下未及时控制风险
3. 新购ECS等管控操作失败：架构设计未遵循多可用区原则
4. 故障信息发布不够及时透明：影响客户应急响应

这些问题集中暴露了云计算服务在基础设施管理和高可用设计方面的薄弱环节。

行业影响与经验教训

此次故障波及范围远超预期，澳门金融管理局、澳门银河、莲花卫视等关键基础设施营运者的网站，以及多个外卖平台和本地传媒应用都受到影响。这警示云服务提供商，必须重视基础设施的冗余设计和应急预案的完善性。

阿里云承诺将根据SLA协议进行赔付，并表示将尽一切努力从此次事件中吸取经验教训，持续提升云服务的稳定性。云服务用户也应重视跨可用区、跨地域的容灾架构设计，避免单一故障点导致的业务中断风险。