北京時(shí)間 6 月 27 日下午，阿里云掛了。市場(chǎng)占有率 47.6% 的阿里云宕機，影響的是中國互聯(lián)網(wǎng)的半壁江山。對此，坊間傳聞伴著(zhù)吐槽聲起伏不斷，甚至有人聲稱(chēng)此次事故是由兩個(gè)實(shí)習生造成。

事件發(fā)生后，阿里云在迅速人肉修復故障后，發(fā)表說(shuō)明：

“對于這次故障，沒(méi)有借口，我們不能也不該出現這樣的失誤！我們將認真復盤(pán)改進(jìn)自動(dòng)化運維技術(shù)和發(fā)布驗證流程，敬畏每一行代碼，敬畏每一份托付。”

云廠(chǎng)商宕機故障，這些年一直不是什么新聞

2017 年 2 月 28 日，云計算巨頭 AWS S3 故障，事件的起因是 AWS S3（云存儲）團隊在進(jìn)行調試時(shí)輸入了一條錯誤指令，本應該將少部分的 S3 計費流程服務(wù)器移除，可是最終意外移除了大量服務(wù)器。被錯誤移除的服務(wù)其中運行著(zhù)兩套 S3 的子系統，從而導致 S3 不能正常工作，S3 API 處于不可用狀態(tài)。

由于 S3 負責存儲文件，為 AWS 體系中的核心組成部分，這導致北弗吉尼亞日（美國東一）服務(wù)區中，依賴(lài)于 S3 存儲服務(wù)的其他 AWS 的 S3 控制臺、Amazon 彈性計算云（簡(jiǎn)稱(chēng) EC2）新實(shí)例啟動(dòng)、Amazon 彈性塊存儲（簡(jiǎn)稱(chēng) EBS）分卷（限于需要讀取 S3 快照的數據）以及 AWS Lambda 均受到影響。

2017 年 3 月 22 日，微軟云服務(wù)宕機。Outlook、 Hotmail、 OneDrive、 Skype 和 Xbox Live 都出現了網(wǎng)絡(luò )故障，全球用戶(hù)都無(wú)法登錄。英國海岸和美國海岸城市的 Outlook 郵箱系統的用戶(hù)受到的影響特別嚴重，同樣悲慘的還有西歐與美國海岸線(xiàn)的美國 OneDrive 用戶(hù)，西歐和巴西的 Skype 用戶(hù)，及 Xbox 的英國、美國、西歐用戶(hù)。Azure 用戶(hù)的一天也不好過(guò)，一大批工程師無(wú)法登錄系統。這不是微軟最近第一次出現這種問(wèn)題，上次是 3 月 7 日。

2015 年 6 月 6 日，QingCloud 廣東 1 區全部硬件設備因遭遇雷暴天氣引發(fā)電力故障，造成 QingCloud 官網(wǎng)及控制臺短時(shí)無(wú)法訪(fǎng)問(wèn)、部署于 GD1 的用戶(hù)業(yè)務(wù)暫時(shí)不可用。在業(yè)務(wù)恢復后，青云方面披露了合作運營(yíng)商針對事故的調查原因：

直擊雷導致電力系統出現瞬時(shí)浪涌，UPS 啟動(dòng)自我保護，從而釋放電流導致瞬間斷電；

雖然機房配備了四級防雷，但主要是防止感應雷，對于此次直擊雷，機房完全沒(méi)有招架之力。

2014 年 11 月 2 日，騰訊云服務(wù)器出現了六分鐘的訪(fǎng)問(wèn)故障。騰訊云平臺部方面表示，此次訪(fǎng)問(wèn)故障主要是上海和廣州機房的服務(wù)器出現故障，機房網(wǎng)絡(luò )出口抖動(dòng)造成的，而網(wǎng)絡(luò )抖動(dòng)是源于運營(yíng)商網(wǎng)絡(luò )信道阻塞，導致用戶(hù)連接服務(wù)器出現丟包等現象。“這是網(wǎng)絡(luò )上游的問(wèn)題，并非機房本身硬件故障，所以無(wú)法避免該情況的發(fā)生。”云平臺部方面負責人如是說(shuō)。

對于吃瓜群眾們來(lái)說(shuō)，看完熱鬧了，要看會(huì )什么門(mén)道呢？

縱觀(guān)以上云廠(chǎng)商宕機案例，有的是天災（機房被雷劈了），有的是人禍（誤刪除操作），但可以肯定的是：宕機這事兒，預計在很長(cháng)的一段時(shí)間里都無(wú)法避免。

以 AWS S3 故障為例。InfoQ 整合了三位技術(shù)專(zhuān)家陳皓、陳天、Nick Kephart 給出的思考整理如下：

1、要注意Error Handling

當問(wèn)題出現時(shí)，一個(gè)普通的 S3 GET 返回什么：

所以AWS 告訴你Internal Error 了。

從 error handling 的角度，陳天認為在寫(xiě)代碼的時(shí)候都應該捕捉這個(gè)異常，然后做合適的錯誤處理。很遺憾的是，S3 這樣的服務(wù)是如此基礎，就像互聯(lián)網(wǎng)的水和電一樣，大家默認為它永遠不會(huì )出錯。因此，好多工程師干脆不做錯誤處理。

除了代碼編寫(xiě)層面的處理，當云服務(wù)商的宕機發(fā)生時(shí)，盡量控制它影響面。像 Trello連 landing page 都一并掛掉實(shí)在不可取，因為起碼 S3 影響不到的頁(yè)面，如 landing page、用戶(hù)注冊 / 登錄頁(yè)面應該還保持正常服務(wù)；而像 Quora的服務(wù)，其實(shí)是可以準備一個(gè)靜態(tài)化的鏡像，一旦出問(wèn)題，起碼讓讀者可以無(wú)障礙地閱讀。

2、盡可能地把動(dòng)態(tài)內容緩存起來(lái)，甚至靜態(tài)化

Redis cache、Nginx cache、HAProxy、CDN 都是把內容緩存甚至靜態(tài)化的一些手段。陳天認為：盡管多級緩存維護起來(lái)是個(gè)麻煩，但當底層服務(wù)出現問(wèn)題時(shí)，它們就是難得的戰略緩沖區。cache 為你爭取到的半個(gè)小時(shí)到幾個(gè)小時(shí)幾乎是續命的靈芝，它能幫你撐過(guò)最艱難的時(shí)刻（這次 S3 宕機前后大概 4 小時(shí)，最嚴重的時(shí)候是 11點(diǎn)到1點(diǎn)），相對從容地尋找解決方案，緊急發(fā)布新的頁(yè)面，或者遷移服務(wù)，把損失降到最低。

否則，只能像這次事件中的諸多公司一樣，聽(tīng)天由命，雙手合十祈禱 AWS 的工程師給力些解決問(wèn)題。

3、云用戶(hù)應檢查核心依賴(lài)關(guān)系，提升關(guān)鍵性服務(wù)的冗余水平

S3是多種Amazon服務(wù)的核心組成部分之一。無(wú)論是利用其進(jìn)行簡(jiǎn)單文件存儲、對象存儲抑或是用于存儲網(wǎng)站或者應用程序中的內容，其間復雜的依賴(lài)性都會(huì )引發(fā)級聯(lián)效應。S3能影響到的組件包括用戶(hù)會(huì )話(huà)管理、媒體存儲、內容存儲、用戶(hù)數據、第三方對象和自動(dòng)化機制等。

在Thousandeyes公司的Nick Kephart看來(lái)，云用戶(hù)應檢查核心依賴(lài)關(guān)系，提升關(guān)鍵性服務(wù)的冗余水平。AWS的系統在構建當中具備冗余特性，能夠實(shí)現跨數據中心自動(dòng)復制存儲對象與文件。而作為另一種冗余層，云用戶(hù)需要利用額外AWS服務(wù)區或者其它云服務(wù)供應商以徹底避免此類(lèi)事故；不過(guò)這會(huì )增加大量管理復雜性與成本支出，因為跨環(huán)境間的數據同步工作需要由云用戶(hù)負責打理。大多數企業(yè)并沒(méi)有選擇上述選項，可是單純的數據備份在數小時(shí)的短周期內并不能發(fā)揮作用。

雖然面向云環(huán)境的遷移確實(shí)能夠在穩定性與彈性方面為企業(yè)帶來(lái)巨大幫助，但是各種不易被發(fā)現的依賴(lài)性也因此增加，單一服務(wù)失敗可能引發(fā)大規模服務(wù)癱瘓。Nick建議云用戶(hù)的開(kāi)發(fā)與運營(yíng)團隊審查與云服務(wù)供應商間的核心依賴(lài)關(guān)系，制定策略以監控各項服務(wù)可能受到的影響，同時(shí)調整現有架構以提升關(guān)鍵性用戶(hù)的冗余水平。

4、故障演習很重要

對于這次事件，陳皓在其博客中表示美國東一區作為老牌的服務(wù)區擁有海量對象，能在數小時(shí)恢復已屬不易，并且幸運的是沒(méi)有丟失重要數據。

陳皓重申了其觀(guān)點(diǎn)：一個(gè)系統的高可用的因素很多，不僅僅只是系統架構，更重要的是——高可用運維。并且，他認為對于高可用的運維，平時(shí)的故障演習是很重要的。AWS 平時(shí)應該沒(méi)有相應的故障演習，所以導致要么長(cháng)期不出故障，一出就出個(gè)大的讓你措手不及。

比如，Facebook每個(gè)季度扔個(gè)骰子，隨機關(guān)掉一個(gè)IDC一天。Netflix 有 Chaos Monkey，路透每年也會(huì )做一次大規模的故障演練——災難演習。

在陳天看來(lái)，這種容錯的操練適合大一些且工程團隊有余力的公司。為什么Netflix 重度使用 AWS，卻在歷次 AWS 的宕機中毫發(fā)無(wú)損？其實(shí)Netflix之前也深深地被云的「不穩定性」刺痛過(guò)，而如今他們的 Chaos Monkey（之后發(fā)展為 simian army）服務(wù)，會(huì )隨時(shí)隨地模擬各種宕機情況，擾亂生產(chǎn)環(huán)境。比如說(shuō)對于此次事件的演練，可以配置 simian army 去擾亂 S3：simianarmy.chaos.fails3.enabled = true。

這樣，這群討厭的猴子就會(huì )在不知情的情況下隨機把服務(wù)器的 /etc/hosts 改掉，讓所有的 S3 API 不可用。如此就可以體驗平時(shí)很難遇到的 S3 不可訪(fǎng)問(wèn)的場(chǎng)景，進(jìn)而找到相應的對策（注意：請在 staging 環(huán)境下謹慎嘗試）。

5、處理危機的方式能看出一個(gè)公司的高度

陳皓表示非常喜歡GitLab、AWS這樣向大眾公開(kāi)其故障及處理流程，哪怕起因是一個(gè)低級的人為錯誤，也不會(huì )掩蓋、不會(huì )文過(guò)飾非。

如果你是一個(gè)技術(shù)公司，你就會(huì )更多的相信技術(shù)而不是管理。相信技術(shù)會(huì )用技術(shù)來(lái)解決問(wèn)題，相信管理，那就只會(huì )有制度、流程和價(jià)值觀(guān)來(lái)解決問(wèn)題。沒(méi)有人愿意看到問(wèn)題的發(fā)生；但是問(wèn)題出現后，最重要的解決反思并從中汲取教訓：這難道不是技術(shù)人應有的傲骨嗎？

你覺(jué)得呢？