全面剖析阿里雲宕機事故 這給雲上企業「上了寶貴一課」

一場事故，又讓中國最大的公有雲廠商陷入輿論風暴的中心。

3月2日深夜，阿里雲突然出現故障，引發眾多網友吐槽。有公司分析指出，因為阿里雲華北2地域部分伺服器異常，導致很多互聯網公司的App和網站陷入癱瘓，一大波程序員、運營和運維專員趕去公司加班。

之後，阿里雲的官方回應是「華北2地域可用區C部分ECS實例狀態異常，導致該區域眾多網站和App都無法正常使用。」

3月3日，阿里雲發布公告，解釋說「華北2地域可用區C部分ECS伺服器等實例出現IO HANG，經緊急排查處理後已全部恢復。目前，我們已全面排查其他地域及可用區，未發現此類情況。針對本次故障，我們將根據SLA協議，儘快地處理賠償事宜。」

以上是本次宕機事件的大致經過。

不過，看到阿里雲公告，筆者還有很多疑問：這次的故障原因是什麼？對上雲的中小企業來說，以後如何保障自己的服務？以及後續賠償如何進行？

如果只是一家網站宕機了，頂多是這家網站的用戶無法登錄和使用，但是作為國內最大的公有雲廠商，阿里雲的這次宕機，卻讓許多互聯網公司的App和網站癱瘓。

有數據顯示，中國目前有40%的網站部署在阿里雲上。作為國內最大的公有雲廠商，阿里雲佔據中國45%的雲計算市場份額。說得更簡單，阿里雲一出現問題，簡直波及一大批企業。

造成阿里雲故障的IO HANG是什麼？

我們注意到，此次事件有兩個要點：一是阿里雲宕機的原因是IO HANG，二是阿里雲將根據SLA協議，儘快賠償。

先來說說IO HANG。如果你去百度搜索，基本上全是阿里雲宕機，都沒有關於IO HANG的具體解釋。

據知乎網友妙正灰(準備升往「中高層」的底層架構師)解釋，IO HANG顧名思義就是IO卡在那兒不動了，即IO錯誤造成IO路徑阻塞，導致內部數據拷貝異常緩慢。

根據一篇《壞盤導致IO hang問題分析》文章，則指出了兩種可能情況：

一種是出現壞盤過程中raid卡的行為有所異常，在這台機器上的執行raid卡的命令megacli都卡住，觀察到這台機器上的物理盤的io都時不時異常繁忙(io不大，但是svctm甚至達到幾千ms)，從而導致我們的塊存儲的卷IO hang住，表現就是用戶的卷io util 100%較長時間。

另外一種情況是壞盤後，將壞盤從raid卡中剔除(做的單盤raid0，默認WB緩存策略，盤壞後需要從raid卡里刪除邏輯卷)，這台機器上的物理盤都io卡住一會，並且megacli命令也卡住。從而也導致部分用戶的卷io util 100%較長時間。

實際上，這並不是阿里雲第一次出現這種情況。

2016年10月11日，阿里雲華東地區部分ECS伺服器出現IO HANG問題，導致部分網站癱瘓，一些用戶無法連接雲伺服器。第二日，阿里雲通報，華東地區部分ECS伺服器出現問題。

知乎上名為baiy.cn的網友評論道，「阿里雲的IO HANG是個大BUG，因為它會永遠HANG在那，不會有IO Timeout，意即：你即使做了跨IDC的高可用設計，也不會實現故障轉移(Failover)等動作。相當於把一切高可用架構都給廢了。」

這位網友進一步解釋說，「這種完全違背物理存儲設備(如：磁碟、RAID卡、SAN等)的行為導致了基本所有帶磁碟IO的軟體產品(如：MySQL、MongoDB、SQL Server等)的高可用集群都不能正常工作。」

有雲服務專家表示，這個問題屬於TOP級故障，即阿里雲磁碟讀寫的操作卡住不動了。所有資料庫都在磁碟里，出現卡頓即數據無法讀出，這對用戶影響非常大。

2015年6月，阿里雲香港數據中心因機房建設方和運營商電力故障造成香港機房故障，斷電12小時;

2015年9月，阿里云云頓的安騎士產品升級觸發的bug導致用戶ECS中的部分正常文件被隔離;

2016年7月，阿里雲北京機房內網發生故障，導致大量互聯網公司業務受到影響;

2016年12月，阿里雲域名解析出現故障，官方稱故障原因為突發大流量攻擊導致的部分解析伺服器異常……

雲上企業學到的寶貴一課：做高可用性 做容災

對今天的企業來說，上雲是一種趨勢，更是數字化轉型的必走之路。我們看到，從AWS、微軟Azure到阿里雲等，全球任何一家雲服務商對服務可靠性的承諾都不是100%，也做不到100%。

這意味著，雲服務提供商總會出現一些不可避免的問題，比如自然災害類的颱風、暴雨、閃電等，人為的誤刪、誤操作等。這些事情的發生，都會讓雲上企業的服務受到影響，出現宕機等。

現在的關鍵問題是，對中小企業來說，如何在上雲之後更好地實現自我保障？

對大企業來說，有充足的資金支持，企業的IT系統建設得比較好，考慮比較周全。但是對一些中小企業而言，這種事情就損失慘重。

知乎上名為汪慧的網友說得比較貼切，「阿里雲這種情況比較無奈，尤其是對中小企業，放在阿里雲上，本身就有一部分是負擔不起在線熱切換。不上雲的時候，自建的各大機房、各大運營商哪個都有掛掉的時候。」

「有人說不要上雲，其實自己管過機房的都知道，問題太多，三天兩頭要麼被DDOS了，用的時間長的機器硬碟掛了，數據丟失，什麼事兒都有，雲上確實解決了部分問題。」他寫道。

雲上企業要做的是，在雲服務提供商提供的保障上，再加一層防護罩。

這裡就涉及做容災。如果一家公司就那麼一台伺服器支撐整體服務，一旦出現問題，又沒有考慮做高可用性，那麼這家公司的業務就完了。

知乎上有網友評論說，「這次事故，假設做了同城容災，華北2的C機房掛了，至少華北2還有A、B等其他機房做備份。如果是更有錢的一些公司，做了兩地容災策略，基本上可以避過雲廠商所有的意外事故了。」

企業只要建立兩套或多套功能相同的IT系統，互聯之間進行健康狀態監視和功能切換，當一處系統因意外停止工作時，整個應用系統就可以切換到另一處，使得該系統功能可以繼續正常工作。

對企業來說，隨著時間的不斷發展，業務增加或變動，IT系統也要變化。為了實現高可用性，容災是一件非常重要的事情，可以保證公司業務的穩定，持續向前發展。

殊不知，有些互聯網公司因一次宕機，就損失慘重，甚至用戶流失，業務遭受重創，最後關門。正所謂「未雨綢繆」，才能「有備無患」!

最後是賠償。賠償是按照規定來的，依據就是阿里雲向客戶承諾的SLA服務等級協議。根據阿里雲對服務可用性的承諾：

1. 對於單實例維度，阿里雲承諾一個服務周期內ECS的服務可用性不低於99.95%;

2. 對於單地域多可用區維度，阿里雲承諾一個服務周期內ECS的服務可用性不低於99.99%。

當然，後續賠償，一切按照流程走基本完成。

後話：

對阿里雲來說，這不是第一次故障，也不會是最後一次故障。對其他雲服務提供商而言，阿里雲發生的故障也會在自己身上不斷重演。但對上雲企業來說，「事故」的一次次發生不斷地教訓了自己，上雲不能全靠雲服務提供商，自己要考慮IT系統的高可用性，要考慮做容災。

（聲明：本文為天極網作者原創內容，未經允許，禁止轉載。）

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！