北京時間今日凌晨，AWS 多個可用區發生故障，官方發表聲明稱因多處光纜被挖斷。截至6月2日下午 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 服務雲計算基礎設施的網站和服務臨時中斷。根據當時的聲明，該事故是由於北愛爾蘭都柏林出現閃電引起數據中心停電。當時，該數據中心是亞馬遜在歐洲唯一的數據存儲地，這意味著 EC2 雲計算平臺客戶在事故期間沒有其他數據中心可供臨時使用。
2012 年 6 月 14 日，雷暴導致亞馬遜在該地區的設施運轉異常，發電機無法正常運行，應急電源被消耗，從而導致 Amazon RDS 上近千個 MySQL 數據庫宕機，影響了 AWS 多項雲服務以及其上的 Quora 等知名網站。
2015 年 9 月 20 日，AWS 的一個數據中心遭遇停電事故，影響了 Netflix，Tinder，Airbnb 等應用程序的在線服務。
2016 年 6 月，澳大利亞悉尼遭遇風暴，AWS 在該地區的設施停電，眾多 EC2 實例及為知名公司託管關鍵負載的 EBS 卷接連出現故障，這次服務中斷持續了近 10 個小時。
閱讀更多 知更長沙 的文章
