【51CTO.com原創稿件】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年采用各種類型的多云環境。”

***筆者還想說，光纜、管道等基礎設施的保護也應受到重視，輕而易舉的被破壞，在當今的云時代，付出的代價太大了！

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】