北京时间2022年12月18日，阿里云香港Region可用区C发生了大规模的服务中断事件，根据官方发布的事件线索，从最早08:56分开始发生告警，到22:50完成主要故障恢复，花了差不多整整20小时来处理此次事件。澳门司法警察局反馈从中午开始依赖阿里云服务的澳门金融管理局、澳门银河、莲花卫视、澳门水泥厂等关键基础设施营运着的网站，澳觅和MFood等外卖平台，以及澳门日报等本地应用APP都收到影响导致暂时无法使用。甚至有的网友称自己的服务器到19日凌晨2点多还没恢复。从用户侧来看，因为机房基础设施故障而引发的次生应用级别的故障其处理和恢复时间还要长。
12月18日本是圣诞节前一个悠闲的假日，故障刚刚发生时，阿里云及其机房的运维管理人员应该也认为是一个能够快速搞定的故障。因为从8:56分告警，到定位到冷机故障并在9:17分启动应急预案，这一系列步骤的操作看起来有条不紊。只有当冷机预案失效之后，一切开始变得刺激起来。
我认真的看完了整个服务中断事件的说明，结合我所在单位的运维经验，总结了对于所有运维人员和运维事件处理中比较容易出问题，也比较容易被领导诟病的三个问题，在这里整理出来和大家分享讨论，说的不对的地方还请大家指正。
处置怎么这么慢
我们看到这次事件是工程师通过温控告警发现的，而故障的核心组件「冷机」系统没有直接发出告警，这就导致工程师找到故障点需要花费一些时间。
「冷机」很显然是外部采购的一个产品，在定位到这个组件故障后，按照常见的应急预案处置方法进行处理却无法恢复故障时，因为现场人员对于设备的了解程度不够，需要供应商到现场支持，这中间消耗了接近2个半小时到等待时间。
影响为何这么大
我们在整理应急预案过程中，往往是针对某个故障点来整理对应的操作步骤。对于一个故障可能引起的关联问题，以及关联问题的处理，往往没有系统的总结到文档中，一般情况下这种问题需要对于系统整个运行有全局观的人才能提前识别到。
在阿里云服务中断事件中，我们看到从 8:56 开始介入事件处理，直到 10:30 左右才开始做出一些应对机房高温可能产生的次生影响处理动作。如果在这之前，能够及早的将事件向上反映，并做出提前的准备，我想可能有些用户就有足够充裕的时间来实施服务/数据转移的变更。
历史无法假设，未来也很难评估。我猜测早上的一段时间，大家可能在乐观的等待冷机厂商赶到后能够将故障尽快恢复。然而如果我们没有对最坏的处境做好充足的准备，当这一刻来临时一定会手忙脚乱，并且将事情的发展引向更坏的结局。
应急指挥一团糟
阿里云服务中断事件的最后也提到「故障信息发布不够及时透明」，我非常理解阿里云在此次事件中组织信息并及时对外发布的难度。这次事件由基础设施故障引发，最终引起机房物理环境和设备，各类应用服务都发生了不同严重程度的影响。想必故障的处理也涉及了阿里云内部众多的部门和人员，在一个原本平静的周日遇到这类突发事件，很多人解决问题都是通过远程的方式接入，在人员组织、信息收集、信息整理、信息发布方面，存在的困难可想而知。
通过对于阿里云此次服务中断事件过程的学习，我能想到很多很多的优化点，细化应急预案、量化影响分析、强化组织架构等等等等。对于每一位运维人员来说，对系统运行始终保持敬畏的态度，认真做好每一件运维工作，落实好相关的制度规范要求，才能尽可能的避免故障发生、减少故障的影响，借阿里云的此次事件以自勉。
以上分析均为本人结合经验对此次事件的一个预判评估，如果有不正确的地方，请及时与我联系修改。
参考资料
用心体验、认真记录，欢迎关注大江小浪的技术人生！