2018 年，公有云服務模式更加成熟，云計算市場規模也在不斷擴大，但公有云服務的故障仍然頻繁發生，幾大主流公有云無一幸免。

根據 IDC 今年 7 月份發布的《中國公有云服務市場半年度跟蹤報告》顯示，阿里云的市場占有率已過 45%，騰訊云達到 10%。在全球市場，根據 Gartner ***數據顯示，亞馬遜 AWS 占全球份額的 51.8%;微軟 Azure 位列第二位，占比 13.3%;阿里云位列第三位，占比 4.6%;谷歌 Cloud 云服務占比 3.3%;隨后是 IBM，占比 1.9%。可見，這幾大主流云供應商占據全球絕大部分市場，一旦云服務出現宕機，受影響的企業將不計其數。

2018 年，云計算市場不僅發展迅速，而且問題不斷。云供應商與開源社區的矛盾不斷升級，主流云廠商均未逃過宕機事件，更有甚者一年出現多次服務宕機，導致企業對公有云的信心持續走低。本文總結了 2018 年前十大云宕機事故，歡迎各位補充經歷過的云服務至暗時刻。

[[253728]]

1 月 18 日：谷歌云自動化失效導致宕機

事故詳情：2018 年 1 月 18 日，谷歌云自動化機制失效，導致其 us-central1 和 europe-west3 兩大可用區中的計算引擎停運 93 分鐘。谷歌對此的回應是“網絡編程失效”導致 Autoscaler(自動擴展器)服務無法正常運行，該服務失效意味著新的虛擬機或剛遷移的虛擬機無法與其他可用區虛擬機聯系。

補救措施： 工程團隊手動切換到替換任務，以恢復數據持久層正常運行。

宕機時間：93 分鐘

事件后續： 谷歌承諾，未來如果配置數據過時，谷歌將停止虛擬機遷移，數據持久層會在長時間運行進程期間重新解析對等體(peer)，以便故障發生時迅速切換到替換任務。

3 月 2 日：AWS 宕機致部分 Alexa 失聲

事故詳情：2018 年 3 月 2 日凌晨，依賴 AWS 服務的部分 Alexa 開始出現失聲問題，該智能音箱的紅色指示燈不停閃爍表明服務出現中斷，Alexa 也一直發出系統內置道歉聲。隨后幾小時內，Alexa 又接到了成千上萬封投訴。據了解，Alexa 這一故障源于亞馬遜 AWS 的網絡服務出現問題，其他依賴 AWS 作為骨干網的應用在當天也受到了影響，包括軟件開發公司 Atlassian，云通訊公司 Twilio 等。

補救措施： 亞馬遜 AWS 的在線支持團隊對此進行了修復。

宕機時間： 數小時(因事發凌晨，未在***時間發酵)

事件后續： 亞馬遜 AWS 未對此故障進行詳細說明，只透露與網絡連接有關。

5 月 31 日：AWS 北弗吉尼亞地區數據中心出現硬件問題

事故詳情：2018 年 5 月 31 日，因北弗吉尼亞地區的數據中心出現硬件故障，AWS 再次出現連接問題。在此事故中，AWS 的核心 EC2 服務，Workspaces 虛擬桌面服務以及 Redshift 數據倉庫服務均受到影響。

補救措施： 人為修復

宕機時長：30 分鐘左右

事件后續： 亞馬遜公司 S3 的副總裁兼總經理 Mai-Lan Tomsen Bukovec 近日接受采訪表示，亞馬遜從未見過數據中心崩潰。這意味著，過去的每一次事故都未曾導致整個數據中心的崩潰，AWS 也在系統設計層面進行了改進以防止此類事故發生。

6 月 17 日：微軟 Azure 愛爾蘭數據中心宕機

事故詳情：2018 年 6 月 17 日至 18 日，因愛爾蘭數據中心的恒溫系統出現問題，微軟 Azure 被高溫影響導致存儲和網絡中斷。

宕機時間：5 小時以上

6 月 27 日：阿里云故障

事故詳情：2018 年 6 月 27 日 16:21 左右，阿里云出現重大技術故障，16:50 分開始陸續恢復，官方給出的故障時間為 30 分鐘左右，恢復時間大概花費一小時。經過技術復盤，阿里給出的故障原因為工程師團隊上線自動化運維新功能時，執行了一項變更驗證操作，該操作在測試環境中未發生問題，上線后觸發未知 bug。

補救措施： 人工介入，定位并解決問題。

宕機時間：30 分鐘，恢復時間花費一小時左右。

事件后續： 本次事故被定義為 S1 級別，即核心業務重要功能不可用，影響部分用戶，造成一定損失。阿里云發布官方聲明，表示“對于這次故障，沒有借口，我們不能也不該出現這樣的失誤!我們將認真復盤改進自動化運維技術和發布驗證流程，敬畏每一行代碼，敬畏每一份托付。”

7 月 20 日：騰訊云云硬盤故障

事故詳情：2018 年 8 月 5 日，北京清博數控科技有限公司(以下簡稱“前沿數控”)在官方微博發布了一篇題為《騰訊云給一家創業公司帶來的災難》的博文，文中表明，2018 年 7 月 20 日，騰訊云云硬盤發生故障(騰訊云后期給出的事故原因說明)，導致該公司存放的數據全部丟失，并且不能恢復，這是該創業公司近千萬元級的平臺數據，包括經過長期推廣導流積累起來的精準注冊用戶以及內容數據。

補救措施： 騰訊云表示，監控到異常后***時間向用戶告知了故障狀態，并立即組織文件系統專家并聯合廠商技術專家嘗試修復數據。但經過多方努力，最終仍有部分數據完整性校驗失敗。

事件后續： 騰訊云提出“賠償 + 補償”方案，并承諾會繼續與“前沿數控”保持溝通，幫助其進行業務恢復。

7 月 24 日：騰訊云宕機

事故詳情：2018 年 7 月 24 日，用戶登錄騰訊云時反復出現超時、退出等情況，即便更換運營商，結果也一樣。隨后，騰訊云發布通知稱初步確定是運營商光纜中斷，運營商已經找到斷點，正在連線中，主要受影響的為廣州區域部分用戶。

補救措施： 運營商***時間介入搶修。

宕機時間： 宕機時間不明，恢復時間花費 30 至 40 分鐘

Prime Day：亞馬遜 AWS 故障

事故詳情：Prime Day 是亞馬遜在全球范圍內啟動的為期 36 小時的會員促銷活動，活動剛開始，亞馬遜網站及 App 就同時發生嚴重宕機，不光電子商務業務受損，亞馬遜的其他產品和服務都受到了不同程度的影響。亞馬遜對此給出的解釋是 AWS 管理控制臺出現全球性問題。

宕機時間： 故障持續了將近 6 小時。

事件后續：AWS 發言人表示，間歇性的 AWS 管理控制臺問題并未對亞馬遜的消費者業務產生任何有意義的影響。

9 月 4 日：微軟 Azure 數據中心遭雷劈宕機

事故詳情：9 月 4 日上午，微軟 Azure 美國中南區數據中心附近發生雷擊在內的惡劣天氣，影響冷卻系統的電壓，導致多個 Azure 服務出現連接問題，客戶難以訪問存儲在該區數據中心的資源。受影響的服務包括 Office36***ctive Directory、Visual Studio Online、Visual Studio Team Services 等。

補救措施：9 月 5 日上午，微軟工程師已恢復數據中心的電力和大多數網絡設備，其他服務也在陸續恢復中。

宕機時間： 超過 24 小時

11 月 9 日：谷歌公有云下的 Kubernetes 服務(GKE)宕機

事故詳情：11 月 9 日，谷歌公有云上提供的 Kubernetes 服務(GKE)節點池建置功能出現異常，維運人員無法透過 Cloud Console UI 建立新節點。

補救措施： 谷歌派工程團隊調查故障原因，并開始著手維修。谷歌表示，受影響的企業用戶可以先改為使用 GCP 內建的 gcloud command，建置新 Kubernetes 節點。

宕機時間： 接近 19 小時

寫在***對于很多中小企業來說，自建機房的人力和維護成本太高，他們希望利用云計算的低成本、可擴展性、可靠性和便利性等好處，但卻擔心面臨風險。這些風險通常是相同的，例如安全漏洞、監管問題，以及缺乏有關如何構建***云計算基礎設施的知識。而在過去幾年，云供應商還發生過數起大大小小的故障，也說明企業的擔心不是多余的。隨著越來越多的企業和政府機構將數據上云，即便只是一個小小的宕機都可能引發很大的災難。即便是提供 99.9% 可靠性的阿里云，那 0.1% 的宕機還是發生了。

考慮到企業的這些需求，現在混合云的趨勢也比較明顯，很多公有云廠商都在布局混合云市場。借助混合云，企業在提高生產力的同時還能降低成本，也不用完全投入到公有云當中。但是混合云也還存在兼容性和安全合規性方面的挑戰，所以為了盡可能地減少故障帶來的損失，企業不僅要建立完善的災備保障體系，還應該對災備系統進行定期演練。