那些年，雲廠商宕機教會我們的事

本文來自微信公眾號：InfoQ（infoqchina），編輯：小智，題圖來自：pixabay.com。

北京時間 6 月 27 日下午，阿里雲掛了。市場佔有率 47.6% 的阿里雲宕機，影響的是中國互聯網的半壁江山。對此，坊間傳聞伴着吐槽聲起伏不斷，甚至有人聲稱此次事故是由兩個實習生造成。

事件發生後，阿里雲在迅速人肉修復故障後，發表説明：

“對於這次故障，沒有藉口，我們不能也不該出現這樣的失誤！我們將認真覆盤改進自動化運維技術和發佈驗證流程，敬畏每一行代碼，敬畏每一份託付。”

雲廠商宕機故障，這些年一直不是什麼新聞

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

由於 S3 負責存儲文件，為 AWS 體系中的核心組成部分，這導致北弗吉尼亞日（美國東一）服務區中，依賴於 S3 存儲服務的其他 AWS 的 S3 控制枱、Amazon 彈性計算雲（簡稱 EC2）新實例啓動、Amazon 彈性塊存儲（簡稱 EBS）分卷（限於需要讀取 S3 快照的數據）以及 AWS Lambda 均受到影響。

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

2015 年 6 月 6 日，QingCloud 廣東 1 區全部硬件設備因遭遇雷暴天氣引發電力故障，造成 QingCloud 官網及控制枱短時無法訪問、部署於 GD1 的用户業務暫時不可用。在業務恢復後，青雲方面披露了合作運營商針對事故的調查原因：

直擊雷導致電力系統出現瞬時浪湧，UPS 啓動自我保護，從而釋放電流導致瞬間斷電；

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

2014 年 11 月 2 日，騰訊雲服務器出現了六分鐘的訪問故障。騰訊雲平台部方面表示，此次訪問故障主要是上海和廣州機房的服務器出現故障，機房網絡出口抖動造成的，而網絡抖動是源於運營商網絡信道阻塞，導致用户連接服務器出現丟包等現象。“這是網絡上游的問題，並非機房本身硬件故障，所以無法避免該情況的發生。”雲平台部方面負責人如是説。

對於吃瓜羣眾們來説，看完熱鬧了，要看會什麼門道呢？

縱觀以上雲廠商宕機案例，有的是天災（機房被雷劈了），有的是人禍（誤刪除操作），但可以肯定的是：宕機這事兒，預計在很長的一段時間裏都無法避免。

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

1、要注意Error Handling

當問題出現時，一個普通的 S3 GET 返回什麼：

所以AWS 告訴你Internal Error 了。

從 error handling 的角度，陳天認為在寫代碼的時候都應該捕捉這個異常，然後做合適的錯誤處理。很遺憾的是，S3 這樣的服務是如此基礎，就像互聯網的水和電一樣，大家默認為它永遠不會出錯。因此，好多工程師乾脆不做錯誤處理。

除了代碼編寫層面的處理，當雲服務商的宕機發生時，儘量控制它影響面。像 Trello連 landing page 都一併掛掉實在不可取，因為起碼 S3 影響不到的頁面，如 landing page、用户註冊 / 登錄頁面應該還保持正常服務；而像 Quora的服務，其實是可以準備一個靜態化的鏡像，一旦出問題，起碼讓讀者可以無障礙地閲讀。

2、儘可能地把動態內容緩存起來，甚至靜態化

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

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

3、雲用户應檢查核心依賴關係，提升關鍵性服務的冗餘水平

S3是多種Amazon服務的核心組成部分之一。無論是利用其進行簡單文件存儲、對象存儲抑或是用於存儲網站或者應用程序中的內容，其間複雜的依賴性都會引發級聯效應。S3能影響到的組件包括用户會話管理、媒體存儲、內容存儲、用户數據、第三方對象和自動化機制等。

在Thousandeyes公司的Nick Kephart看來，雲用户應檢查核心依賴關係，提升關鍵性服務的冗餘水平。AWS的系統在構建當中具備冗餘特性，能夠實現跨數據中心自動複製存儲對象與文件。而作為另一種冗餘層，雲用户需要利用額外AWS服務區或者其它雲服務供應商以徹底避免此類事故；不過這會增加大量管理複雜性與成本支出，因為跨環境間的數據同步工作需要由雲用户負責打理。大多數企業並沒有選擇上述選項，可是單純的數據備份在數小時的短週期內並不能發揮作用。

雖然面向雲環境的遷移確實能夠在穩定性與彈性方面為企業帶來巨大幫助，但是各種不易被發現的依賴性也因此增加，單一服務失敗可能引發大規模服務癱瘓。Nick建議雲用户的開發與運營團隊審查與雲服務供應商間的核心依賴關係，制定策略以監控各項服務可能受到的影響，同時調整現有架構以提升關鍵性用户的冗餘水平。

4、故障演習很重要

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

陳皓重申了其觀點：一個系統的高可用的因素很多，不僅僅只是系統架構，更重要的是——高可用運維。並且，他認為對於高可用的運維，平時的故障演習是很重要的。AWS 平時應該沒有相應的故障演習，所以導致要麼長期不出故障，一出就出個大的讓你措手不及。

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

在陳天看來，這種容錯的操練適合大一些且工程團隊有餘力的公司。**為什麼Netflix 重度使用 AWS，卻在歷次 AWS 的宕機中毫髮無損？**其實Netflix之前也深深地被雲的「不穩定性」刺痛過，而如今他們的 Chaos Monkey（之後發展為 simian army）服務，會隨時隨地模擬各種宕機情況，擾亂生產環境。比如説對於此次事件的演練，可以配置 simian army 去擾亂 S3：simianarmy.chaos.fails3.enabled = true。

這樣，這羣討厭的猴子就會在不知情的情況下隨機把服務器的 /etc/hosts 改掉，讓所有的 S3 API 不可用。如此就可以體驗平時很難遇到的 S3 不可訪問的場景，進而找到相應的對策（注意：請在 staging 環境下謹慎嘗試）。

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

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

如果你是一個技術公司，你就會更多的相信技術而不是管理。相信技術會用技術來解決問題，相信管理，那就只會有制度、流程和價值觀來解決問題。沒有人願意看到問題的發生；但是問題出現後，最重要的解決反思並從中汲取教訓：這難道不是技術人應有的傲骨嗎？

你覺得呢？