（原标题：阿里云正式发布澳门需用区C服务项目受阻该事件表明，称将尽早处置索赔事项）
12月25日，阿里云正式发布澳门Region需用区C服务项目受阻该事件表明，并向所有受到机械故障负面影响的顾客公开道歉，称将尽早处置索赔事项。阿里云表示，将尽一切努力从此次该事件中科藤教训，稳步提升云服务项目的平衡性。在表明中，阿里云公布了本次该事件的机械故障情况、难题分析和改进措施，具体如下：
处置过程
12月18日08:56，阿里云监视到澳门Region需用区C控制室包厢通道控温监视系统，阿里云技师介入紧急处置，通知控制室服务项目商展开当晚摸查。09:01，阿里云监视到该控制室多个包厢面部潮红监视系统，这时技师摸查到科真亮极度。09:09，控制室服务项目商按紧急应急对极度冷机展开4+4Maignelay切换以及重启，但操作方式失败，冷水机组难以恢复正常。09:17，依照机械故障处置流程，开启压缩机极度紧急应急，展开辅助散热器和紧急通风。尝试对科真亮控制系统逐一展开隔离和纯手工恢复操作方式，但发现难以平衡运转，联系科真亮电子设备分销商到当晚摸查。这时，由于低温原因，部份伺服器已经开始受到负面影响。
自10:30已经开始，为避免可能出现的低温消防队难题，阿里云技师相继对整个控制室计算、存储、网络、统计资料库、大统计数据软件产业展开降载处理。期间，竭尽全力多次对科真亮电子设备展开操作方式，但均不能竭尽全力保持运转。
12:30，科真亮电子设备分销商亲临现场，在多方技师诊断下，对冷塔、冷却系统阀门及科真亮冷却系统展开纯手工保湿排气管操作方式，但系统仍然难以竭尽全力保持运转。阿里云工程师对部份低温包厢开启伺服器停机操作方式。14:47，科真亮电子设备分销商对电子设备难题摸查顾虑到，其中两个包厢因低温促发了强制消防队除尘。15:20，经科真亮电子设备商技师当晚纯手工调整配置，科真亮群控弹出顺利完成并独立运转，第1台科真亮恢复正常，环境温度已经开始下降。技师随后竭尽全力通过相同方法对其他科真亮展开操作方式。18:55，4台科真亮恢复到正常功率密度。19:02，先期开启伺服器，并稳步观察面部潮红情况。19:47，控制室环境温度趋于平衡。同时，阿里云技师已经开始展开服务项目开启恢复，并展开必要性的TPM检查和。
21:36，大部份控制室包厢伺服器相继开启并顺利完成检查和，控制室环境温度平衡。其中两个包厢因消防队除尘开启，未展开伺服器INS13ZD。因为TNUMBERFK的准确性至关重要，技师对这个包厢的伺服器展开了仔细的统计数据巡查和，这里花费了一些必要性的时间。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左右绝大部份统计资料库实例恢复正常。对于受机械故障负面影响的单机版实例及Maignelay均在澳门Region需用区C的高需用版实例，我们提供了克隆实例、实例迁移等临时性恢复方案，但由于底层服务项目资源的限制，部份实例的迁移恢复过程遇到一些极度情况，需要花费较长的时间来处置解决。
我们注意到，同时在多个需用区运转业务的顾客，在这次该事件中依然可以维持业务运行。对于业务需要绝对高需用的顾客，我们稳步建议您采用全链路多需用区的业务架构设计，以应对各种可能的意外该事件。
难题分析与改进措施
1、科真亮系统机械故障恢复时间过长
原因分析：控制室冷却系统缺水进气形成气阻，负面影响水路循环导致4台主科真亮服务项目极度，开启4台备科真亮时因Maignelay共用的水路循环系统气阻导致开启失败。水盘保湿后，因控制室冷却系统的群控逻辑，难以单台独立开启科真亮，纯手工修改科真亮配置，将科真亮从群控调整为独立运转后，相继开启科真亮，负面影响了冷却系统的恢复时长。整个过程中，原因定位耗时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），提高信息正式发布的速度，让顾客可以更便捷地了解机械故障该事件对各类产品服务项目的负面影响。
