近年來，云宕機事件頻繁發(fā)生。6月27日晚，阿里云因為“運維上的一個操作失誤”，導(dǎo)致一些客戶訪問阿里云官網(wǎng)控制臺和使用部分產(chǎn)品功能出現(xiàn)問題。無獨有偶，chromecast和Google Home也在同一日出現(xiàn)了服務(wù)器問題，谷歌公告告知，將在6小時恢復(fù)。服務(wù)器的宕機就像魚沒有了水一樣，對于用戶來說，每一分鐘的宕機都是巨大的經(jīng)濟損失。
2017 年 2 月 28 日，云計算巨頭 AWS S3 故障，事件的起因是 AWS S3（云存儲）團隊在進行調(diào)試時輸入了一條錯誤指令，本應(yīng)該將少部分的 S3 計費流程服務(wù)器移除，可是最終意外移除了大量服務(wù)器。被錯誤移除的服務(wù)其中運行著兩套 S3 的子系統(tǒng)，從而導(dǎo)致 S3 不能正常工作，S3 API 處于不可用狀態(tài)。
由于 S3 負責存儲文件，為 AWS 體系中的核心組成部分，這導(dǎo)致北弗吉尼亞日（美國東一）服務(wù)區(qū)中，依賴于 S3 存儲服務(wù)的其他 AWS 的 S3 控制臺、Amazon 彈性計算云（簡稱 EC2）新實例啟動、Amazon 彈性塊存儲（簡稱 EBS）分卷（限于需要讀取 S3 快照的數(shù)據(jù)）以及 AWS Lambda 均受到影響。
2017 年 3 月 22 日，微軟云服務(wù)宕機。Outlook、 Hotmail、 OneDrive、 Skype 和 Xbox Live 都出現(xiàn)了網(wǎng)絡(luò)故障，全球用戶都無法登錄。英國海岸和美國海岸城市的 Outlook 郵箱系統(tǒng)的用戶受到的影響特別嚴重，同樣悲慘的還有西歐與美國海岸線的美國 OneDrive 用戶，西歐和巴西的 Skype 用戶，及 Xbox 的英國、美國、西歐用戶。Azure 用戶的一天也不好過，一大批工程師無法登錄系統(tǒng)。這不是微軟最近第一次出現(xiàn)這種問題，上次是 3 月 7 日。
2015 年 6 月 6 日，QingCloud 廣東 1 區(qū)全部硬件設(shè)備因遭遇雷暴天氣引發(fā)電力故障，造成 QingCloud 官網(wǎng)及控制臺短時無法訪問、部署于 GD1 的用戶業(yè)務(wù)暫時不可用。在業(yè)務(wù)恢復(fù)后，青云方面披露了合作運營商針對事故的調(diào)查原因：
1.直擊雷導(dǎo)致電力系統(tǒng)出現(xiàn)瞬時浪涌，UPS 啟動自我保護，從而釋放電流導(dǎo)致瞬間斷電；
2.雖然機房配備了四級防雷，但主要是防止感應(yīng)雷，對于此次直擊雷，機房完全沒有招架之力。
2014 年 11 月 2 日，騰訊云服務(wù)器出現(xiàn)了六分鐘的訪問故障。騰訊云平臺部方面表示，此次訪問故障主要是上海和廣州機房的服務(wù)器出現(xiàn)故障，機房網(wǎng)絡(luò)出口抖動造成的，而網(wǎng)絡(luò)抖動是源于運營商網(wǎng)絡(luò)信道阻塞，導(dǎo)致用戶連接服務(wù)器出現(xiàn)丟包等現(xiàn)象。“這是網(wǎng)絡(luò)上游的問題，并非機房本身硬件故障，所以無法避免該情況的發(fā)生。”云平臺部方面負責人如是說。
對于吃瓜群眾們來說，看完熱鬧了，要看會什么門道呢？
縱觀以上云廠商宕機案例，有的是天災(zāi)（機房被雷劈了），有的是人禍（誤刪除操作），但可以肯定的是：宕機這事兒，預(yù)計在很長的一段時間里都無法避免。
以 AWS S3 故障為例。InfoQ 整合了三位技術(shù)專家陳皓、陳天、Nick Kephart 給出的思考整理如下：
1、要注意Error Handling
當問題出現(xiàn)時，一個普通的 S3 GET 返回什么：
所以AWS 告訴你Internal Error 了。
從 error handling 的角度，陳天認為在寫代碼的時候都應(yīng)該捕捉這個異常，然后做合適的錯誤處理。很遺憾的是，S3 這樣的服務(wù)是如此基礎(chǔ)，就像互聯(lián)網(wǎng)的水和電一樣，大家默認為它永遠不會出錯。因此，好多工程師干脆不做錯誤處理。
除了代碼編寫層面的處理，當云服務(wù)商的宕機發(fā)生時，盡量控制它影響面。像 Trello連 landing page 都一并掛掉實在不可取，因為起碼 S3 影響不到的頁面，如 landing page、用戶注冊 / 登錄頁面應(yīng)該還保持正常服務(wù)；而像 Quora的服務(wù)，其實是可以準備一個靜態(tài)化的鏡像，一旦出問題，起碼讓讀者可以無障礙地閱讀。
2、盡可能地把動態(tài)內(nèi)容緩存起來，甚至靜態(tài)化
Redis cache、Nginx cache、HAProxy、CDN 都是把內(nèi)容緩存甚至靜態(tài)化的一些手段。陳天認為：盡管多級緩存維護起來是個麻煩，但當?shù)讓臃?wù)出現(xiàn)問題時，它們就是難得的戰(zhàn)略緩沖區(qū)。cache 為你爭取到的半個小時到幾個小時幾乎是續(xù)命的靈芝，它能幫你撐過最艱難的時刻（這次 S3 宕機前后大概 4 小時，最嚴重的時候是 11點到1點），相對從容地尋找解決方案，緊急發(fā)布新的頁面，或者遷移服務(wù)，把損失降到最低。
否則，只能像這次事件中的諸多公司一樣，聽天由命，雙手合十祈禱 AWS 的工程師給力些解決問題。
3、云用戶應(yīng)檢查核心依賴關(guān)系，提升關(guān)鍵性服務(wù)的冗余水平
S3是多種Amazon服務(wù)的核心組成部分之一。無論是利用其進行簡單文件存儲、對象存儲抑或是用于存儲網(wǎng)站或者應(yīng)用程序中的內(nèi)容，其間復(fù)雜的依賴性都會引發(fā)級聯(lián)效應(yīng)。S3能影響到的組件包括用戶會話管理、媒體存儲、內(nèi)容存儲、用戶數(shù)據(jù)、第三方對象和自動化機制等。
在Thousandeyes公司的Nick Kephart看來，云用戶應(yīng)檢查核心依賴關(guān)系，提升關(guān)鍵性服務(wù)的冗余水平。AWS的系統(tǒng)在構(gòu)建當中具備冗余特性，能夠?qū)崿F(xiàn)跨數(shù)據(jù)中心自動復(fù)制存儲對象與文件。而作為另一種冗余層，云用戶需要利用額外AWS服務(wù)區(qū)或者其它云服務(wù)供應(yīng)商以徹底避免此類事故；不過這會增加大量管理復(fù)雜性與成本支出，因為跨環(huán)境間的數(shù)據(jù)同步工作需要由云用戶負責打理。大多數(shù)企業(yè)并沒有選擇上述選項，可是單純的數(shù)據(jù)備份在數(shù)小時的短周期內(nèi)并不能發(fā)揮作用。
雖然面向云環(huán)境的遷移確實能夠在穩(wěn)定性與彈性方面為企業(yè)帶來巨大幫助，但是各種不易被發(fā)現(xiàn)的依賴性也因此增加，單一服務(wù)失敗可能引發(fā)大規(guī)模服務(wù)癱瘓。Nick建議云用戶的開發(fā)與運營團隊審查與云服務(wù)供應(yīng)商間的核心依賴關(guān)系，制定策略以監(jiān)控各項服務(wù)可能受到的影響，同時調(diào)整現(xiàn)有架構(gòu)以提升關(guān)鍵性用戶的冗余水平。
4、故障演習很重要
對于這次事件，陳皓在其博客中表示美國東一區(qū)作為老牌的服務(wù)區(qū)擁有海量對象，能在數(shù)小時恢復(fù)已屬不易，并且幸運的是沒有丟失重要數(shù)據(jù)。
陳皓重申了其觀點：一個系統(tǒng)的高可用的因素很多，不僅僅只是系統(tǒng)架構(gòu)，更重要的是——高可用運維。并且，他認為對于高可用的運維，平時的故障演習是很重要的。AWS 平時應(yīng)該沒有相應(yīng)的故障演習，所以導(dǎo)致要么長期不出故障，一出就出個大的讓你措手不及。
比如，F(xiàn)acebook每個季度扔個骰子，隨機關(guān)掉一個IDC一天。Netflix 有 Chaos Monkey，路透每年也會做一次大規(guī)模的故障演練——災(zāi)難演習。
在陳天看來，這種容錯的操練適合大一些且工程團隊有余力的公司。為什么Netflix 重度使用 AWS，卻在歷次 AWS 的宕機中毫發(fā)無損？其實Netflix之前也深深地被云的「不穩(wěn)定性」刺痛過，而如今他們的 Chaos Monkey（之后發(fā)展為 simian army）服務(wù)，會隨時隨地模擬各種宕機情況，擾亂生產(chǎn)環(huán)境。比如說對于此次事件的演練，可以配置 simian army 去擾亂 S3：simianarmy.chaos.fails3.enabled = true.
這樣，這群討厭的猴子就會在不知情的情況下隨機把服務(wù)器的 /etc/hosts 改掉，讓所有的 S3 API 不可用。如此就可以體驗平時很難遇到的 S3 不可訪問的場景，進而找到相應(yīng)的對策（注意：請在 staging 環(huán)境下謹慎嘗試）。
5、處理危機的方式能看出一個公司的高度
陳皓表示非常喜歡GitLab、AWS這樣向大眾公開其故障及處理流程，哪怕起因是一個低級的人為錯誤，也不會掩蓋、不會文過飾非。
如果你是一個技術(shù)公司，你就會更多的相信技術(shù)而不是管理。相信技術(shù)會用技術(shù)來解決問題，相信管理，那就只會有制度、流程和價值觀來解決問題。沒有人愿意看到問題的發(fā)生；但是問題出現(xiàn)后，最重要的解決反思并從中汲取教訓：這難道不是技術(shù)人應(yīng)有的傲骨嗎？
你覺得呢？
（原標題：那些年，云廠商宕機教會我們的事）
