阿里云香港云服务器不知道有多少P事故史诗级宕机事件重演

2023-08-22 1199阅读 0评论

上周日，12月18日，阿里云香港服务器遭遇了不知道统计了多少次的史诗级宕机事件。整个事件导致香港C区ECS、OSS、EBS、RDS等云服务大范围不可用，故障时间从上午8:00持续到晚上10:00才最终恢复，整个故障时间持续了14个小时。

（图片来源网络，侵删）

Gate.io、OKEX等知名交易所受到大规模故障影响，我还以为他们跑路了。

按照事故发生时间计算，可用率约为98%，这意味着可以获得的基本赔偿为每月服务费的25%。

昨天，阿里云官方还公布了关于今年估计造成阿里云程序员大规模故障的325起故障恢复的指示。

过程

12月18日08时56分，阿里云监测到香港区可用区C机房通道温控报警。阿里云工程师介入紧急处理，并通知机房服务商进行现场排查。

09时01分，阿里云监测到机房多个包间出现温升报警。这时，工程师发现冷却机出现异常。

09时09分，机房服务商按照应急预案对异常冷水机进行4+4主备倒换并重启，但操作失败，冷水机无法恢复正常。

09时17分，根据故障处理流程，启动制冷异常应急预案，进行辅助散热和应急通风。尝试对冷水机控制系统进行一一隔离并手动恢复，发现无法稳定运行，联系冷水机设备供应商现场排查。此时，由于气温较高，部分服务器开始受到影响。

从10时30分开始，为了避免可能出现的高温消防问题，阿里云工程师陆续降低了整个机房的计算、存储、网络、数据库、大数据集群的负载。期间，冷却设备多次持续运行，但均未能保持稳定运行。

12时30分，冷水机设备供应商来到现场。在多位工程师的诊断下，对冷却塔、冷却水管道和冷水机冷凝器进行了人工补水和排气，但系统仍然无法维持稳定运行。阿里云工程师对部分高温包房进行了服务器关闭操作。

14时47分，冷水机设备供应商在排查设备问题时遇到困难，其中一间包房因高温触发强制消防喷淋。

15时20分，冷水机组设备厂家工程师现场手动调整配置后，冷水机组群控解锁，独立运行。第一台冷水机恢复正常，温度开始下降。随后，工程师们开始以同样的方式研究其他冷却器。

18时55分，4台冷水机恢复正常制冷能力。

19:02分批启动服务器，继续观察温度上升情况。

19时47分，机房温度稳定。与此同时，阿里云工程师开始恢复服务并进行必要的数据完整性检查。

21时36分，机房包间大部分服务器陆续启动并检查，机房温度稳定。其中一间包间因消防喷淋启动，服务器未开机。由于维护数据的完整性至关重要，工程师们对这个展位的服务器进行了仔细的数据安全检查，在这里花费了一些必要的时间。

22时50分，完成数据检查和风险评估，并根据安全情况，在最后一个包房内逐步恢复供电并启动服务器。

服务影响

12月18日09点23分，香港地区C可用区部分ECS服务器开始关闭，引发同可用区宕机迁移。随着气温持续升高，受影响的服务器不断关闭，客户业务开始受到影响，并且影响扩大到香港C可用区的EBS、OSS、RDS等更多云服务。

阿里云香港可用区C的故障并未直接影响客户在香港其他可用区的业务运行，但影响了香港地区ECS控制平面的正常使用。

由于C可用区大量客户在香港其他可用区购买了新的ECS实例，从12月18日14:49开始，ECS管控服务触发限流，可用性降至最低20% 。当客户使用RunInstances/CreateInstance API购买新的ECS实例时，如果指定了自定义镜像，由于自定义镜像数据服务依赖于单一AZ冗余版本的ECS实例，购买成功后部分实例可能无法启动。重试无法解决可用区C OSS服务。

此时Dataworks和k8s的部分用户控制台操作也受到了故障的影响。该 API 完全可用至当日 23:11。

12月18日10时37分，阿里云香港可用区C区部分存储服务OSS开始受到宕机影响。这时候客户不会察觉，但持续高温会造成磁盘坏道，影响数据安全。工程师关闭了服务器操作，服务于11时07分至18时26分中断。

阿里云在香港地区可用区C提供两种OSS服务。一种是OSS本地冗余LRS服务（通常称为单AZ冗余服务），仅部署在C可用区；另一种是OSS本地冗余LRS服务（通常称为单AZ冗余服务）。另一种是OSS同城冗余服务。剩余的ZRS服务（通常称为3AZ冗余服务）部署在B、C、D可用区。本次故障中，OSS同城冗余ZRS服务基本没有受到影响。 C可用区的OSS本地冗余服务长时间中断，由于不支持跨可用区切换，需要依赖故障机房的恢复。

18时26分起，存储服务器批量重启。其中，单AZ本地冗余LRS服务的部分服务器因消防问题需要隔离。在恢复服务之前，我们必须保证数据的可靠性，并且花了很多时间来检查完整性。

直到12月19日零时30分，这部分OSS服务（单AZ冗余服务）才恢复对外服务能力。

阿里云网络少量单可用区产品（如VPN、Privatelink、少量GA实例）受此故障影响。

12月18日11点21分，工程师在网络产品可用区启动容灾逃生。

12:45 完成SLB等大部分网络产品可用区的容灾逃生。

13:47NAT产品完成收尾工作并越狱。

除上述少数单AZ产品外，所有网络产品在故障时均保持业务连续性，NAT存在分钟级业务损坏。

12月18日10点17分开始，阿里云香港区可用区C部分RDS实例出现不可用告警。随着该可用区故障影响的主机范围扩大，服务异常的实例数量增加，工程师启动数据库紧急切换预案流程。

截至12点30分，RDS MySQL与Redis、MongoDB、DTS等大部分跨可用区实例已完成跨可用区切换。对于部分单可用区实例和单可用区高可用实例，由于依赖单可用区数据备份，因此只能有效迁移少量实例。少数支持跨可用区切换的RDS实例没有及时完成切换。经查，是因为这些RDS实例依赖于香港C区部署的代理服务。由于代理服务不可用，因此无法通过代理地址访问RDS实例。我们协助相关客户暂时切换到RDS主实例的地址访问进行恢复。

随着机房制冷设备的恢复，21时30分左右大部分数据库实例恢复正常。对于受故障影响的单机实例以及主备均在香港区可用区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可用区OSS服务的单可用区冗余版本，导致客户购买新实例后启动失败。

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

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

原因分析：故障发生后，阿里云推出了客户钉群、公告等通知方式。由于现场冷机加工进展缓慢，没有足够的有效信息。状态页信息更新不及时，给客户造成混乱。

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