阿里云故障原因分析_全面剖析阿里云宕机事故 这给云上企业“上了宝贵一课”

【天极网云计算频道】某个意外事件，再次使国内规模领先的公共云服务提供商，处于公众讨论的激烈漩涡之中。

3月2日深夜，阿里云突发状况，引来网友广泛议论。某企业研究指出，由于阿里云华北2区部分机器出现异常，致使众多网络公司的应用程序和网页无法正常运作，大批技术开发人员、市场管理人员和系统维护人员匆忙赶往单位加班加点。

接下来，阿里云方面表示，华北地区第二处的部分计算服务实例出现了工作不正常的情况，因此该地方很多网络平台和应用程序都受到了影响，无法正常运作。

三月份三日，阿里云发布官方通知，说明“华北地区第二分区C区部分ECS实例遭遇输入输出卡顿，在紧急处理完毕后均已恢复正常运行。现阶段，我们已彻底检查其他区域及分区，未检测到类似状况。对于此次问题，我们将依照服务等级协议，迅速落实补偿措施。”

以上是本次宕机事件的大致经过。

然而，通过阅读阿里云的通告，作者内心仍存诸多困惑：此次事故的根源究竟为何？对于采用云服务的中小型企业而言，未来应怎样确保自身业务的稳定运行？另外，事后的补偿方案又将以何种方式展开？

倘若仅仅某个站点出现故障，顶多是该站点的访客无法访问和操作，然而阿里云作为国内首要的公共云服务提供者，此次服务中断，致使众多网络公司的应用程序和网页全面瘫痪。

根据统计资料，国内四成左右的网站选择在阿里云平台运行。作为国内规模最大的公有云服务提供商，阿里云在中国云计算市场拥有四成五的占有率。简单来说，阿里云一旦发生故障，众多企业将受到严重影响。

造成阿里云故障的IO HANG是什么？

我们留意到，此次事件存在两个关键点，一个是阿里云出现故障是由于IO僵持造成的，另一个是阿里云会依照服务等级协议，迅速进行补偿。

先谈谈IO HANG的问题，如果你在百度上查询，几乎都是阿里云服务中断的信息，但找不到关于IO HANG的详细说明。

根据知乎用户妙正灰的说法，这位人士即将晋升为“中高层”的初级架构师，他阐述了IO HANG的成因，这种状况指的是IO操作停滞不前，具体表现为IO错误引发了IO路径的梗塞，进而造成内部数据传输变得极为迟缓。

依据《坏盘导致IO hang问题分析》一文，存在两种潜在状况，具体如下：

有一种情况是，在硬盘损坏期间，RAID控制卡的操作出现不正常现象，这台设备上对RAID控制卡发出的指令全都停滞不前，发现这台设备里的物理硬盘的读写活动时常出现异常的忙碌状态，虽然实际的读写量并不大，但服务响应时间却时常达到几千毫秒，因此造成我们的块存储系统中的卷读写操作被卡住，具体表现为用户的卷读写使用率长时间维持在百分之百。

另一种状况是当出现故障磁盘时，需要将该坏盘从阵列控制器中移除，因为这是单盘raid0配置，且采用写回缓存机制，磁盘损坏后必须从控制器中删除对应的逻辑单元，此时该设备的所有物理磁盘会出现io阻塞现象，同时相关指令也会暂时无法执行，进而造成部分用户的卷读写使用率长时间维持在百分之百的状态

实际上，这并不是阿里云第一次出现这种情况。

2016年10月11日，阿里云华东部分ECS服务器遭遇IO僵局，致使部分站点中断，少数客户无法访问云主机。次日，阿里云公布，华东部分ECS服务器发生故障。

该网友在知乎平台发表看法称，阿里云的IO功能存在严重缺陷，该功能会持续卡顿无法响应，导致无法进行IO操作，也就是说即便采用了跨地域的容灾方案，也无法完成服务切换等关键操作，这种情况使得所有容灾架构的设计都失去意义。

这位网友继续阐述，这种行为完全无视物理存储设备，例如磁盘、RAID卡、SAN等，因此几乎所有依赖磁盘输入输出的软件产品，诸如MySQL、SQL等，其高可用集群都无法正常运行。

业内人士指出，该问题属于最高级别的故障，也就是说阿里云的磁盘读写操作陷入了停滞状态。由于所有数据库均存储在磁盘上，一旦出现操作冻结，数据便无法被读取出来，给用户带来了极为严重的后果。

二零一五年六月，阿里云香港的数据中心遭遇了问题，原因是建筑公司以及电力服务提供商出现了供电故障，导致香港的机房停摆，整整十二个小时没有电力供应。

二零一五年九月，阿里云云顿的安骑士软件版本更新引发的故障，造成用户ECS实例里一些本来正常的文档被系统暂时隔离了

二零一六年七月，阿里云北京的数据中心内部系统出现异常，造成众多网络企业的服务受到波及。

二零一六年十二月，阿里云的域名解析系统遭遇了问题，官方解释称，问题的起因是遭遇了突发的巨大流量冲击，进而引发了部分解析服务器的运作失常……

云上企业学到的宝贵一课：做高可用性 做容灾

如今的企业，采用云服务已经成为一种潮流，同时也是实现数字化升级的必然选择。我们了解到，无论是亚马逊网络服务、微软的Azure平台，还是阿里巴巴的云业务，全球所有的云服务提供商，对于服务稳定性的保证都无法做到百分之百，也确实无法达到绝对完美的程度。

这表明，云服务供应商难免会遭遇某些无法避免的情况，例如台风、暴雨、闪电等自然灾害，以及人为的误删、误操作等。这些情况的发生，都会导致云上企业的服务受到干扰，出现系统停止运行等现象。

当前核心议题在于，对于规模较小的企业而言，怎样在迁移至云端之后，更有效地落实自身安全防护措施？

大型公司拥有充裕的财力，能够顺利推进其信息技术系统的构建，并且规划得相当完备，然而对于众多规模较小的公司来说，这类投入往往导致它们蒙受巨大的经济损失。

汪慧在知乎上的观点颇具见地，阿里云的处境颇为尴尬，对于许多中小型企业而言尤为明显，若将业务部署于阿里云，其中一部分成本是企业难以承受的，因为需要承担在线热切换的费用，而未使用云服务时，自建的数据中心以及各大运营商的网络也时常出现故障。

某些人声称云端服务不可取，但熟悉服务器维护的人清楚，隐患频发，时常遭遇分布式拒绝服务攻击，长时间运行的服务器硬盘易损，导致信息遗失，各类状况层出不穷，云端服务确实化解了部分困境。

云上企业需要做的是，在云服务供应商提供的支持基础上，再增加一道安全屏障。

当前情况需要考虑建立备用系统，假如某个企业仅依靠一台服务器来维持全部业务运作，一旦该服务器发生故障，并且事先没有部署容错机制，那么这家企业的运营将会彻底中断。

有知乎用户表示，此次事件若实施同城备份方案，即便华北地区第二数据中心机房失效，华北区仍可依靠A、B等其余机房承担业务，保障服务不中断；而财力更为雄厚的机构，若采用跨区域容灾机制，则能大概率规避云服务商可能发生的各类故障问题。

公司若部署两个或以上具备同等作用的计算机系统，这些系统之间需实现运行状况监测与业务转换，一旦某个系统遭遇故障停摆，全部业务流程便能够切换至备用系统，确保该系统功能得以持续稳定运行。

公司业务会随时间推移而增长或调整，相应地，IT系统也需随之更新。确保系统的高稳定运行至关重要，这需要做好灾难恢复准备。灾难恢复有助于维护公司业务的连续性，使公司能够稳定发展。

一些网络企业，仅仅因为短暂的服务中断，就蒙受巨大损失，客户纷纷离开，经营遭遇重大打击，最终不得不停业，这并非罕见现象，事先做好防范措施，才能避免事后手忙脚乱，正所谓“事先预防，事后无忧”！

最终涉及补偿事宜，补偿遵循既定规范，其依据为阿里云对客户确立的服务等级协议，即SLA。依据阿里云关于服务稳定运行所做出的保证：

对于单个实例规格，阿里云保证一个服务时段内ECS的服务稳定性不低于99.95%。

针对单一地区存在多个可用区的情况，阿里云保证在规定的服务时间内，ECS的运行稳定性不低于99.99%。

当然，后续赔偿，一切按照流程走基本完成。

后话：

对于阿里云而言，系统出现差错并非初次，未来也未必不会再次发生此类情况。对于其他提供云端服务的机构，阿里云所经历的这些问题迟早也会在他们那里出现。然而，对于采用云端服务的企业来说，事故的接连发生持续地让他们吸取教训，认识到不能完全依赖云服务提供商，必须自行思考如何确保自身IT系统的高效稳定运行，同时也要考虑建立备用系统以防万一。