阿里云回应宕机故障：将尽快处理赔偿 盘点2018年十大云宕机事故

3月阿里云出现大面积宕机故障?对此阿里云官方回应称将根据SLA协议，尽快处理赔偿事宜。

3日凌晨有众多网友在微博上反馈，阿里云疑似出现大规模故障情况，华北相当多的互联网公司都炸了，App、网站全部瘫痪，一大波程序员和运营、运维专员都从被窝爬起来去公司干活了。

有网友称，疑似阿里云华北2部分机器故障，怀疑是磁盘问题，部分硬盘无法访问，凡是会读写故障盘的系统软件或服务程序，都会受到影响。

针对此事，对此阿里云官方回应称，华北2地域可用区C部分ECS服务器等实例出现IO HANG，经紧急排查处理后逐步恢复。目前我们已经全面排查其他地域及可用区，未发现此类情况。针对本次故障，阿里云将根据SLA协议，尽快处理赔偿事宜。

根据阿里云描述，其在中国公共云市场占有率超过2至5名的总和，目前中国有40%的网站都在阿里云上运营，一半独角兽公司也在使用阿里云。

2018年十大云宕机事故：

1、谷歌公有云下的 Kubernetes 服务(GKE)宕机 11 月 9 日

事故详情：11 月 9 日，谷歌公有云上提供的 Kubernetes 服务(GKE)节点池建置功能出现异常，维运人员无法透过 Cloud Console UI 建立新节点。

补救措施：谷歌派工程团队调查故障原因，并开始着手维修。谷歌表示，受影响的企业用户可以先改为使用 GCP 内建的 gcloud command，建置新 Kubernetes 节点。

宕机时间：接近 19 小时

2、微软云 Azure 数据中心遭雷劈宕机 9 月 4 日

事故详情：9 月 4 日上午，微软 Azure 美国中南区数据中心附近发生雷击在内的恶劣天气，影响冷却系统的电压，导致多个 Azure 服务出现连接问题，客户难以访问存储在该区数据中心的资源。受影响的服务包括 Office365、Active Directory、Visual Studio Online、Visual Studio Team Services 等。

补救措施：9 月 5 日上午，微软工程师已恢复数据中心的电力和大多数网络设备，其他服务也在陆续恢复中。

宕机时间：超过 24 小时

3、腾讯云宕机 7 月 24 日

事故详情：2018 年 7 月 24 日，用户登录腾讯云时反复出现超时、退出等情况，即便更换运营商，结果也一样。随后，腾讯云发布通知称初步确定是运营商光缆中断，运营商已经找到断点，正在连线中，主要受影响的为广州区域部分用户。

补救措施：运营商第一时间介入抢修

宕机时间：宕机时间不明，恢复时间花费 30 至 40 分钟

4、腾讯云云硬盘故障 7 月 20 日

事故详情：2018 年 8 月 5 日，北京清博数控科技有限公司(以下简称“前沿数控”)在官方微博发布了一篇题为《腾讯云给一家创业公司带来的灾难》的博文，文中表明，2018 年 7 月 20 日，腾讯云云硬盘发生故障(腾讯云后期给出的事故原因说明)，导致该公司存放的数据全部丢失，并且不能恢复，这是该创业公司近千万元级的平台数据，包括经过长期推广导流积累起来的精准注册用户以及内容数据。

补救措施：腾讯云表示，监控到异常后第一时间向用户告知了故障状态，并立即组织文件系统专家并联合厂商技术专家尝试修复数据。但经过多方努力，最终仍有部分数据完整性校验失败。

事件后续：腾讯云提出“赔偿 + 补偿”方案，并承诺会继续与“前沿数控”保持沟通，帮助其进行业务恢复。

5、阿里云故障 6 月 27 日

事故详情：2018 年 6 月 27 日 16:21 左右，阿里云出现重大技术故障，16:50 分开始陆续恢复，官方给出的故障时间为 30 分钟左右，恢复时间大概花费一小时。经过技术复盘，阿里给出的故障原因为工程师团队上线自动化运维新功能时，执行了一项变更验证操作，该操作在测试环境中未发生问题，上线后触发未知 bug。

补救措施：人工介入，定位并解决问题

宕机时间：30 分钟，恢复时间花费一小时左右

事件后续：本次事故被定义为 S1 级别，即核心业务重要功能不可用，影响部分用户，造成一定损失。阿里云发布官方声明，表示“对于这次故障，没有借口，我们不能也不该出现这样的失误!我们将认真复盘改进自动化运维技术和发布验证流程，敬畏每一行代码，敬畏每一份托付。”

6、微软 Azure 爱尔兰数据中心宕机 6 月 17 日

事故详情：2018 年 6 月 17 日至 18 日，因爱尔兰数据中心的恒温系统出现问题，微软 Azure 被高温影响导致存储和网络中断。

宕机时间：5 小时以上

7、亚马逊 AWS 故障 Prime Day

事故详情：Prime Day 是亚马逊在全球范围内启动的为期 36 小时的会员促销活动，活动刚开始，亚马逊网站及 App 就同时发生严重宕机，不光电子商务业务受损，亚马逊的其他产品和服务都受到了不同程度的影响。亚马逊对此给出的解释是 AWS 管理控制台出现全球性问题。

宕机时间：故障持续了将近 6 小时

事件后续：AWS 发言人表示，间歇性的 AWS 管理控制台问题并未对亚马逊的消费者业务产生任何有意义的影响。

8、AWS 北弗吉尼亚地区数据中心出现硬件问题 5 月 31 日

事故详情：2018 年 5 月 31 日，因北弗吉尼亚地区的数据中心出现硬件故障，AWS 再次出现连接问题。在此事故中，AWS 的核心 EC2 服务，Workspaces 虚拟桌面服务以及 Redshift 数据仓库服务均受到影响。

补救措施：人为修复

宕机时长：30 分钟左右

事件后续：亚马逊公司 S3 的副总裁兼总经理 Mai-Lan Tomsen Bukovec 近日接受采访表示，亚马逊从未见过数据中心崩溃。这意味着，过去的每一次事故都未曾导致整个数据中心的崩溃，AWS 也在系统设计层面进行了改进以防止此类事故发生。

9、AWS 宕机致部分 Alexa 失声 3 月 2 日

事故详情：2018 年 3 月 2 日凌晨，依赖 AWS 服务的部分 Alexa 开始出现失声问题，该智能音箱的红色指示灯不停闪烁表明服务出现中断，Alexa 也一直发出系统内置道歉声。随后几小时内，Alexa 又接到了成千上万封投诉。据了解，Alexa 这一故障源于亚马逊 AWS 的网络服务出现问题，其他依赖 AWS 作为骨干网的应用在当天也受到了影响，包括软件开发公司 Atlassian，云通讯公司 Twilio 等。

补救措施：亚马逊 AWS 的在线支持团队对此进行了修复

宕机时间：数小时(因事发凌晨，未在第一时间发酵)

事件后续：亚马逊 AWS 未对此故障进行详细说明，只透露与网络连接有关。

10、谷歌云自动化失效导致宕机 1 月 18 日

事故详情：2018 年 1 月 18 日，谷歌云自动化机制失效，导致其 us-central1 和 europe-west3 两大可用区中的计算引擎停运 93 分钟。谷歌对此的回应是“网络编程失效”导致 Autoscaler(自动扩展器)服务无法正常运行，该服务失效意味着新的虚拟机或刚迁移的虚拟机无法与其他可用区虚拟机联系。

补救措施：工程团队手动切换到替换任务，以恢复数据持久层正常运行。

宕机时间：93 分钟

事件后续：谷歌承诺，未来如果配置数据过时，谷歌将停止虚拟机迁移，数据持久层会在长时间运行进程期间重新解析对等体(peer)，以便故障发生时迅速切换到替换任务。