AWS宕机11个小时，都是光纤被挖断惹的祸？

2019年6月2日凌晨两点开始，AWS北京区域出现大面积瘫痪，据称是因为CN-NORTH-1地区有多处光缆在夜晚道路施工中被切断，导致该区域的第一个可用区中EC2实例不能访问，同时不能在整个CN-NORTH-1区域中新建EC2实例。

Amazon Elastic Compute Cloud（Beijing）的处理进展如下：

02:38，我们正在调查CN-NORTH-1的网络连接问题。

04:17，我们正在调查CN-NORTH-1的所有可用区的EC2 API错误率上升的问题以及启动新的EC2实例失败的问题。我们也在调查CN-NORTH-1区域EBS API的错误率上升和延迟增大的问题。

06:36,我们已经找到了CN-NORTH-1区所有可用区中EC2 API和EBS API错误率上升的问题，以及新的EC2实例启动失败的问题的原因，我们正在修复这个问题。

09:27，我们已经确定了CN2-NORTH-1区域内所有可用区域内新EC2实例的EC2和EBS API错误率增加以及启动失败的原因，并正在努力解决问题。因为网络连接导致无法成功完成Runlnstances API请求，将影响CN-NORTH-1所有区域。对其中一个可用区中的现有运行实例没有任何影响。

14:56，在北京时间，2:00AM到13:48PM之间，在CN-NORTH-1区域，客户遇到在所有区域中EC2 API调用失败率增高以及无法新建实例的故障，目前故障已经解决，服务恢复正常。

回顾去年的AWS故障事件：3月，亚马逊AWS网络服务出现问题，故障时间不详。5月，北弗吉尼亚地区的数据中心出现硬件故障，AWS再次出现连接问题，持续时间30分钟。7月，AWS管理控制台故障，故障持续近6小时。11月，AWS韩国服务器中断，故障时间持续一个多小时。相比之下，此次的从2点到14点，11个多小时的故障不得不称为最近AWS宕机事件中的大事。

AWS此次的恢复时间为什么长达11个多小时？这不得不让人联想到AWS没有做好网络冗余设计。网络冗余设计主要通过重复设置网络链路和网络设备冗余措施，并制定网络重要系统和数据备份策略等。网络链路冗余指为了确保业务正常运转，除配置主线路外，同时做好第二种、第三种线路的部署。

据悉，AWS北京区域使用的是光环新网的数据中心，该公司在北京拥有酒仙桥、太和桥、光环新谷、东直门、房山和亦庄6个数据中心，每个都拥有高达100G的BGP总出口带宽，多运营商通信链路。光环新网并未对此事作出回应。

正值6.18中国电商大促阶段，不仅亚马逊中国官网（www.amazon.cn）的页面一度崩溃，VIPKID、流利说、三星应用商店等用户均受到不同程度的影响。笔者也是VIPKID的用户，所幸当天并未约课，只是无法完成课后作业及预习课程。而约了课的家长就比较抓狂，取消已约课程，重新约课…

虽然云服务不可能保证100%不出现问题，但是扎扎实实做好灾备，把宕机带来的影响降到最低是云厂商的重要职责。

对于用户来说，除了选择更安全的云服务外，使用多家云服务，实施多云战略也是未来的重要方向。

首先，优化了业务负载。由于根据企业负载的不同，为之匹配不同厂商间最适合的云技术，可以明显提高企业业务运转效率。

第二，确保服务的可靠性。再可靠的云服务也不能保证100%的安全，即使云计算提供商在多个区域提供数据中心服务，并可以确保安全的冗余级别，但仍然会存在各种突出事件，影响云服务的可靠性。而通过实施在多个云平台之间故障转移，无论发生什么类型的中断，都可以尽快完成灾备，保持应用程序的运行。

国际数据公司 IDC 的一项预测表明：“截止到2020年，90%以上的企业将使用多个云服务和平台”。著名研究机构 451 Research 公司的调查也显示：“IT 的未来是多云和混合云，69%的受访企业表示，计划到2019年采用各种类型的多云环境。”

最后笔者还想说，光缆、管道等基础设施的保护也应受到重视，轻而易举的被破坏，在当今的云时代，付出的代价太大了！

【责任编辑：赵立京 TEL：（010）68476606】