硬碟出故障、機房被雷劈，雲服務能不能靠點兒譜？

編輯 | 小智

7 月 20 日，騰訊雲北京三區部分雲硬碟 IO 異常。類似的故障在各大雲廠商提供的雲服務里，可謂是司空見怪，但這次因為一家名叫「前沿數控」 的創業公司，這個事件重新發酵，引起了熱議。

「前沿數控」是一家以微信公眾號起家的創業公司，因為這次硬碟故障，該公司線上生產數據完全丟失，在與廠商客服溝通後，得知數據無法恢復，該公司發言人稱其網路產品已全部停運。

事件發生後，騰訊雲做出回應：

事件到此遠未完結，我們也將持續關注事件進展。現在，讓我們來聊點別的。

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

2018 年 6 月 27 日，阿里雲故障，起因：運維操作失誤觸發未知 bug；

2017 年 2 月 28 日，雲計算巨頭 AWS S3 故障，起因：調試時輸入錯誤指令，意外移除大量伺服器導致 S3 不能正常工作；

2017 年 3 月 22 日，微軟雲服務一個月內出現又一次宕機（上一次是 3 月 7 日）；

2015 年 6 月 6 日，QingCloud 廣東 1 區全部硬體設備因遭遇雷暴天氣引發電力故障，造成 QingCloud 官網及控制台短時無法訪問、部署於 GD1 的用戶業務暫時不可用。

……

運維失誤、硬碟出故障、機房被雷劈、調試輸入錯誤指令，不同的失誤會引起不同的 bug，最後同樣導致雲服務故障，造成大額損失。AWS 的費良宏老師回顧雲計算的發展時曾說：「我眼裡的雲計算，就是十年生聚，十年教訓」。故障，一直是雲服務命運的雙生子，每一次故障的陣痛，都是在倒逼雲服務廠商和用戶加速成長，只是這一次對於「前沿數控」這家創業公司而言過於疼痛了。

InfoQ 認為，在這類雲服務故障的事件里，雲廠商和用戶都上了寶貴的一課。

對於廠商而言，需要學會的是：

注意 Error Handling

廠商工程師在寫代碼的時候都應該捕捉異常，然後做合適的錯誤處理。

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

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

故障演習很重要

一個系統的高可用的因素很多，不僅僅只是系統架構，更重要的是——高可用運維。對於高可用的運維，平時的故障演習是很重要的。Facebook 每個季度扔個骰子，隨機關掉一個 IDC 一天。Netflix 有 Chaos Monkey，路透每年也會做一次大規模的故障演練——災難演習。為的就是提升因對突發故障的應變能力。

充分告知用戶雲計算服務並不是 100% 可靠的

雲廠商在提供雲服務的時候，應該告知用戶雲存儲有極小概率出現損壞或數據丟失，建議用戶自己備份或者購買雲備份。如果不告知或者不充分強調，很多用戶都會以為雲廠商造成數據丟失就要負責賠償其所有損失。

敬畏用戶，妥善處理危機

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

對於用戶而言，需要學會的是：

檢查核心依賴關係，提升關鍵性服務的冗餘水平

很多雲服務，比如 AWS 自身的系統在構建當中就具備冗餘特性，但要充分使用就會增加大量管理複雜性與成本支出，因為跨環境間的數據同步工作需要由雲用戶負責打理。大多數企業並沒有選擇上述選項，可是單純的數據備份在數小時的短周期內並不能發揮作用。但這卻是一個值得去做的事。

主動做好備份

根據美國標準 TIA-942《數據中心的通信基礎設施標準》，從可用性、穩定性和安全性分為四個等級：T1，可用性為 99.67%；T2，可用性 99.749%；T3，可用性 99.982%；T4，可用性 99.995%。年平均故障時間也從 0.4 小時到 28.8 小時不等，這意味著每年都可能存在各種原因的不可用。不管雲服務是幾個「9」，其靠譜程度始終不是 100%。用戶需要自己做好備份，在雲服務出現故障時，有可以恢複數據的渠道，而不是像「前沿數控」一樣最終兩眼一抹黑。

寫在最後

此次事件發展至今，眾說紛紜，事件雙方都給出了各自的說法和解釋，怎麼樣去判斷事件的真相和對錯，InfoQ 在此不做價值判斷，留給大家自己去思考、評價。我們希望大家可以基於事件本身去討論問題，兼聽則明，偏信則暗。

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