AWS 发生故障：多处光缆被挖断，历经 11 小时完全修复

北京时间今日凌晨，AWS 多个可用区发生故障，官方发表声明称因多处光缆被挖断。截至今天下午 13:48，AWS 表示所有故障已经完全恢复。

北京时间今日凌晨 2:00，AWS 多个可用区发生故障，相关用户无法连接 Internet。随后，AWS 发表声明表示：“由于 CN-NORTH-1 区域有多处光纤在昨晚的道路施工中被挖断，导致该区域的第一个可用区中 EC2 实例不能访问，同时不能在整个 CN-NORTH-1 区域中新建 EC2 实例。维修团队已找到具体断点，正在尽力恢复。”

据网友爆料，受事故波及影响，三星服务器全线崩溃。用户登录三星部分服务器时，页面报错且无法显示正常状态。打开 Bixy 的时候只会显示 LOGO 然后就闪退，根本无法进入 Bixby，三星商店则一直处于网络错误状态。此外，国内也有多家公司的服务受到影响，VIPKID 通过官方微博表示：“目前已经启动替代方案，受影响区域的线上课程正在陆续恢复，受此影响未能正常完成的课程不会消耗您的课时。”

企业如何自救？

每逢云服务出现宕机，多云这个话题都会被提起，不少用户认为多云可以有效规避单一云服务故障引发的不可用问题。在知乎上，也有不少与多云相关的探讨：

对此，业内专家在接受 InfoQ 采访时表示，作为云服务的采用者，企业首先需要仔细考虑清楚自己的战略，同时了解这些挑战最终可能带来的复杂性、成本和陷阱。在多云部署中，成本可能会成倍增加，这不仅仅是云订单的价格，还有运维成本。虽然一开始通过利用多个云计算提供商来实现成本效率似乎是合理的，但长远来看，缺乏工具和标准以及其他低效率培训和跟踪云平台使用的成本可能代价高昂。

目前，多云支持能力的供应商成熟度差异非常大。虽然一些供应商是早期采用者和开拓者，但彼此之间存在全方位差异，而这种差异使得采用过程非常复杂和低效。此外，从安全性和合规性角度来看，缺乏集成身份和访问管理也是一项重要挑战。

对于云服务故障，企业需要明白，无论是传统环境还是云环境，都不能做到绝对的“持续可用”。大部分情况下，云环境的可用性和可靠性都比传统环境要高，这主要是因为云平台的运维更加专业。既然任何环境都有出现故障的可能，那么需要重视的问题就是“发生故障时，应该怎么办”。

接受风险，这一点很重要。对于现阶段国内的云计算发展进程来看，上云是不可避免的，在这种情况下，企业应该保持正确的心理，毕竟只要是系统，都会发生故障。国内主流云计算厂商已经投入了大量精力和成本在可用性和可靠性层面，这肯定要优于不少技术能力不足、成本有限的企业自建服务器。如果出现这种情况，那么走应急预案，用非系统的方式尽量降低风险。例如，某个服务宕机了，及时在官网做出声明。

其次，分散风险。云环境的同城双活、异地灾备等方案基本就绪，尽量在经济和人员条件可行的情况下使用这些分散风险的方法。如果故障只出在一个服务器集群，采用异地灾备方案可以在最快时间切换到另一个集群，从而保持系统可用。虽然还是会有中断，但是可以最快时间恢复。

按照此模式，云下系统做云上灾备也是防范传统环境出现可用性问题的一种重要手段。作为企业的 IT 人员，日常做到以下四点可以尽可能避免云故障带来的损失。

1、备份、备份，还是备份，要异机异地；

2、数据容灾；

3、业务双活；

4、定期对灾备和双活进行演练。

AWS 历史故障

在过去十年，AWS 也曾发生过几次因不可抗力造成的服务故障。根据不完全统计，2010 年 5 月 11 日，AWS 曾因停电事故出现故障，致使美国东部的少量用户失去服务近一个小时，其事故原因是一辆汽车撞倒了 AWS 数据中心附近的高压电线杆，数据中心的配电开关未能成功切换至内部备用发电机。

2011 年 8 月，亚马逊在北弗吉尼亚州的 EC2 服务发生断网故障，使许多使用亚马逊 Web 服务云计算基础设施的网站和服务临时中断。根据当时的声明，该事故是由于北爱尔兰都柏林出现闪电引起数据中心停电。

2012 年 6 月 14 日，雷暴导致亚马逊在该地区的设施运转异常，发电机无法正常运行，应急电源被消耗，从而导致 Amazon RDS 上近千个 MySQL 数据库宕机，影响了 AWS 多项云服务以及其上的 Quora 等知名网站。

2015 年 9 月 20 日，AWS 的一个数据中心遭遇停电事故，影响了 Netflix，Tinder，Airbnb 等应用程序的在线服务。

2016 年 6 月，澳大利亚悉尼遭遇风暴，AWS 在该地区的设施停电，众多 EC2 实例及为知名公司托管关键负载的 EBS 卷接连出现故障，这次服务中断持续了近 10 个小时。