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

  一场事故，又让中国最大的公有云厂商陷入舆论风暴的中心。

  3月2日深夜，阿里云突然出现故障，引发众多网友吐槽。有公司分析指出，因为阿里云华北2地域部分服务器异常，导致很多互联网公司的App和网站陷入瘫痪，一大波程序员、运营和运维专员赶去公司加班。

  之后，阿里云的官方回应是“华北2地域可用区C部分ECS实例状态异常，导致该区域众多网站和App都无法正常使用。”

  3月3日，阿里云发布公告，解释说“华北2地域可用区C部分ECS服务器等实例出现IO HANG，经紧急排查处理后已全部恢复。目前，我们已全面排查其他地域及可用区，未发现此类情况。针对本次故障，我们将根据SLA协议，尽快地处理赔偿事宜。”

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

  不过，看到阿里云公告，笔者还有很多疑问：这次的故障原因是什么？对上云的中小企业来说，以后如何保障自己的服务？以及后续赔偿如何进行？

  如果只是一家网站宕机了，顶多是这家网站的用户无法登录和使用，但是作为国内最大的公有云厂商，阿里云的这次宕机，却让许多互联网公司的App和网站瘫痪。

  有数据显示，中国目前有40%的网站部署在阿里云上。作为国内最大的公有云厂商，阿里云占据中国45%的云计算市场份额。说得更简单，阿里云一出现问题，简直波及一大批企业。

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

  我们注意到，此次事件有两个要点：一是阿里云宕机的原因是IO HANG，二是阿里云将根据SLA协议，尽快赔偿。

  先来说说IO HANG。如果你去百度搜索，基本上全是阿里云宕机，都没有关于IO HANG的具体解释。

  据知乎网友妙正灰(准备升往“中高层”的底层架构师)解释，IO HANG顾名思义就是IO卡在那儿不动了，即IO错误造成IO路径阻塞，导致内部数据拷贝异常缓慢。

  根据一篇《坏盘导致IO hang问题分析》文章，则指出了两种可能情况：

  一种是出现坏盘过程中raid卡的行为有所异常，在这台机器上的执行raid卡的命令megacli都卡住，观察到这台机器上的物理盘的io都时不时异常繁忙(io不大，但是svctm甚至达到几千ms)，从而导致我们的块存储的卷IO hang住，表现就是用户的卷io util 100%较长时间。

  另外一种情况是坏盘后，将坏盘从raid卡中剔除(做的单盘raid0，默认WB缓存策略，盘坏后需要从raid卡里删除逻辑卷)，这台机器上的物理盘都io卡住一会，并且megacli命令也卡住。从而也导致部分用户的卷io util 100%较长时间。

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

  2016年10月11日，阿里云华东地区部分ECS服务器出现IO HANG问题，导致部分网站瘫痪，一些用户无法连接云服务器。第二日，阿里云通报，华东地区部分ECS服务器出现问题。

  知乎上名为baiy.cn的网友评论道，“阿里云的IO HANG是个大BUG，因为它会永远HANG在那，不会有IO Timeout，意即：你即使做了跨IDC的高可用设计，也不会实现故障转移(Failover)等动作。相当于把一切高可用架构都给废了。”

  这位网友进一步解释说，“这种完全违背物理存储设备(如：磁盘、RAID卡、SAN等)的行为导致了基本所有带磁盘IO的软件产品(如：MySQL、MongoDB、SQL Server等)的高可用集群都不能正常工作。”

  有云服务专家表示，这个问题属于TOP级故障，即阿里云磁盘读写的操作卡住不动了。所有数据库都在磁盘里，出现卡顿即数据无法读出，这对用户影响非常大。

  2015年6月，阿里云香港数据中心因机房建设方和运营商电力故障造成香港机房故障，断电12小时;

  2015年9月，阿里云云顿的安骑士产品升级触发的bug导致用户ECS中的部分正常文件被隔离;

  2016年7月，阿里云北京机房内网发生故障，导致大量互联网公司业务受到影响;

  2016年12月，阿里云域名解析出现故障，官方称故障原因为突发大流量攻击导致的部分解析服务器异常……

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

  对今天的企业来说，上云是一种趋势，更是数字化转型的必走之路。我们看到，从AWS、微软Azure到阿里云等，全球任何一家云服务商对服务可靠性的承诺都不是100%，也做不到100%。

  这意味着，云服务提供商总会出现一些不可避免的问题，比如自然灾害类的台风、暴雨、闪电等，人为的误删、误操作等。这些事情的发生，都会让云上企业的服务受到影响，出现宕机等。

  现在的关键问题是，对中小企业来说，如何在上云之后更好地实现自我保障？

  对大企业来说，有充足的资金支持，企业的IT系统建设得比较好，考虑比较周全。但是对一些中小企业而言，这种事情就损失惨重。

  知乎上名为汪慧的网友说得比较贴切，“阿里云这种情况比较无奈，尤其是对中小企业，放在阿里云上，本身就有一部分是负担不起在线热切换。不上云的时候，自建的各大机房、各大运营商哪个都有挂掉的时候。”

  “有人说不要上云，其实自己管过机房的都知道，问题太多，三天两头要么被DDOS了，用的时间长的机器硬盘挂了，数据丢失，什么事儿都有，云上确实解决了部分问题。”他写道。

  云上企业要做的是，在云服务提供商提供的保障上，再加一层防护罩。

  这里就涉及做容灾。如果一家公司就那么一台服务器支撑整体服务，一旦出现问题，又没有考虑做高可用性，那么这家公司的业务就完了。

  知乎上有网友评论说，“这次事故，假设做了同城容灾，华北2的C机房挂了，至少华北2还有A、B等其他机房做备份。如果是更有钱的一些公司，做了两地容灾策略，基本上可以避过云厂商所有的意外事故了。”

  企业只要建立两套或多套功能相同的IT系统，互联之间进行健康状态监视和功能切换，当一处系统因意外停止工作时，整个应用系统就可以切换到另一处，使得该系统功能可以继续正常工作。

  对企业来说，随着时间的不断发展，业务增加或变动，IT系统也要变化。为了实现高可用性，容灾是一件非常重要的事情，可以保证公司业务的稳定，持续向前发展。

  殊不知，有些互联网公司因一次宕机，就损失惨重，甚至用户流失，业务遭受重创，最后关门。正所谓“未雨绸缪”，才能“有备无患”!

  最后是赔偿。赔偿是按照规定来的，依据就是阿里云向客户承诺的SLA服务等级协议。根据阿里云对服务可用性的承诺：

  1. 对于单实例维度，阿里云承诺一个服务周期内ECS的服务可用性不低于99.95%;

  2. 对于单地域多可用区维度，阿里云承诺一个服务周期内ECS的服务可用性不低于99.99%。

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

  后话：

  对阿里云来说，这不是第一次故障，也不会是最后一次故障。对其他云服务提供商而言，阿里云发生的故障也会在自己身上不断重演。但对上云企业来说，“事故”的一次次发生不断地教训了自己，上云不能全靠云服务提供商，自己要考虑IT系统的高可用性，要考虑做容灾。

 （声明：本文为天极网作者原创内容，未经允许，禁止转载。）