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

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

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

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

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

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

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

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

1.直擊雷導(dǎo)致電力系統(tǒng)出現(xiàn)瞬時(shí)浪涌，UPS 啟動(dòng)自我保護(hù)，從而釋放電流導(dǎo)致瞬間斷電；

2.雖然機(jī)房配備了四級(jí)防雷，但主要是防止感應(yīng)雷，對(duì)于此次直擊雷，機(jī)房完全沒有招架之力。

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

對(duì)于吃瓜群眾們來說，看完熱鬧了，要看會(huì)什么門道呢？

縱觀以上云廠商宕機(jī)案例，有的是天災(zāi)（機(jī)房被雷劈了），有的是人禍（誤刪除操作），directadmin漢化 虛擬主機(jī)，但可以肯定的是：宕機(jī)這事兒，預(yù)計(jì)在很長(zhǎng)的一段時(shí)間里都無法避免。

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

1、要注意Error Handling

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

所以AWS 告訴你Internal Error 了。

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

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

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

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

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

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