雲廠商故障宕機這些年來一直不是什麼新聞：
運維失誤、硬碟出故障、機房被雷劈、除錯輸入錯誤指令，不同的失誤會引起不同的 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 在此不做價值判斷，留給大家自己去思考、評價。我們希望大家可以基於事件本身去討論問題，兼聽則明，偏信則暗。
硬碟常見故障
硬碟做為計算機的外儲存器，容量越做越大，但是其穩定性好像卻是越來越不如以前。到現在還有 三 四百mb的ide介面老硬碟在二手市場上銷售，並且用起來一點問題也沒有，只是速度太慢。可新的大容量硬碟呢？速度是快了許多，就是三天兩頭的出毛病。硬碟在使用過程中，由於硬碟的質量問題，供電不良，病毒破壞，高頻干擾...
linux硬碟故障修復
1 如果出現唯讀檔案系統，先備份重要資料，2 重新掛載 系統mount o remount,rw 3 如果不能解決問題，重啟伺服器以cd 光碟引導進入linux rescue修復模式，選擇troubleshooting，然後選擇rescue a centos system，選擇continue繼續操...
Ceph osd故障硬碟更換
1 關閉ceph集群資料遷移 osd硬碟故障，狀態變為down。在經過mod osd down out interval 設定的時間間隔後，ceph將其標記為out，並開始進行資料遷移恢復。為了降低ceph進行資料恢復或scrub等操作對效能的影響，可以先將其暫時關閉，待硬碟更換完成且osd恢復後再...