所以，在災難來臨的時候，你會發(fā)現(xiàn)你所設計精良的“備份系統(tǒng)”或是“災備系統(tǒng)”就算是平時可以工作，但也會導致數(shù)據(jù)丟失，而且可能長期不用的備份系統(tǒng)很難恢復(比如應用、工具、數(shù)據(jù)的版本不兼容等問題)。
我之前寫過一篇《分布式系統(tǒng)的事務處理》，你還記得下面這張圖嗎?看看 Data Loss 那一行的，在Backups, Master/Slave 和 Master/Master的架構下，都是會丟的。
所以說，如果你要讓你的備份系統(tǒng)隨時都可以用，那么你就要讓它隨時都Live著，而隨時都Live著的多結點系統(tǒng)，基本上就是一個分布式的高可用的系統(tǒng)。因為，數(shù)據(jù)丟失的原因有很多種，比如掉電、磁盤損壞、中病毒等等，而那些流程、規(guī)則、人肉檢查、權限系統(tǒng)、checklist等等都只是讓人不要誤操作，都不管用，這個時候，你不得不用更好的技術去設計出一個高可用的系統(tǒng)!別無它法。(重要的事，得再說一篇)
另外，你可以參看我的另一篇《關于高可用系統(tǒng)》，這篇文章中以MySQL為例，數(shù)據(jù)庫的replication也只能達到 兩個9。
AWS 的 S3 的的高可用是4個加11個9的持久性(所謂11個9的持久性durability，AWS是這樣定義的，如果你存了1萬個對象，那么丟一個的時間是1000萬年)，這意味著，不僅僅只是硬盤壞，機器掉電，整個機房掛了，其保證可以承受有兩個設施的數(shù)據(jù)丟失，數(shù)據(jù)還是可用的。試想，如果你把數(shù)據(jù)的可用性通過技術做到了這個份上，那么，你還怕被人誤刪一個結點上的數(shù)據(jù)嗎?
非技術方面
故障反思
一般說來，故障都需要反思，在Amazon，S2以上的故障都需要寫COE(Correction of Errors)，其中一節(jié)就是需要Ask 5 Whys，我發(fā)現(xiàn)在Gitlab的故障回顧的blog中第一段中也有說要在今天寫個Ask 5 Whys。關于Ask 5 Whys，其實并不是亞馬遜的玩法，這還是算一個業(yè)內(nèi)常用的玩法，也就是說不斷的為自己為為什么，直到找到問題的概本原因，這會逼著所有的當事人去學習和深究很多東西。在Wikipedia上有相關的詞條 5 Whys，其中羅列了14條規(guī)則：
你需要找到正確的團隊來完成這個故障反思。 使用紙或白板而不是電腦。 寫下整個問題的過程，確保每個人都能看懂。 區(qū)別原因和癥狀。 特別注意因果關系。 說明Root Cause以及相關的證據(jù)。 5個為什么的答案需要是精確的。 尋找問題根源的頻，而不是直接跳到結論。 要基礎客觀的事實、數(shù)據(jù)和知識。 評估過程而不是人。 千萬不要把“人為失誤”或是“工作不注意”當成問題的根源。 培養(yǎng)信任和真誠的氣氛和文化。 不斷的問“為什么”直到問題的根源被找到。這樣可以保證同一個坑不會掉進去兩次。 當你給出“為什么”的答案時，你應該從用戶的角度來回答。
工程師文化
上述的這些觀點，其實，我在我的以住的博客中都講過很多遍了，你可以參看《什么是工程師文化?》以及《開發(fā)團隊的效率》。其實，說白了就是這么一個事——如果你是一個技術公司，你就會更多的相信技術而不是管理。相信技術會用技術來解決問題，相信管理，那就只會有制度、流程和價值觀來解決問題。
這個道理很簡單，數(shù)據(jù)丟失有各種各樣的情況，不單單只是人員的誤操作，比如，掉電、磁盤損壞、中病毒等等，在這些情況下，你設計的那些流程、規(guī)則、人肉檢查、權限系統(tǒng)、checklist等等統(tǒng)統(tǒng)都不管用，這個時候，你覺得應該怎么做呢?是的，你會發(fā)現(xiàn)，你不得不用更好的技術去設計出一個高可用的系統(tǒng)!別無它法。(重要的事得說三遍)
事件公開
很多公司基本上都是這樣的套路，首先是極力掩蓋，如果掩蓋不了了就開始撒謊，撒不了謊了，就“文過飾非”、“避重就輕”、“轉(zhuǎn)移視線”。然而，面對危機的最佳方法就是——“多一些真誠，少一些套路”，所謂的“多一些真誠”的最佳實踐就是——“透明公開所有的信息”，Gitlab此次的這個事給大家樹立了非常好的榜樣。AWS也會把自己所有的故障和細節(jié)都批露出來。
事情本來就做錯了，而公開所有的細節(jié)，會讓大眾少很多猜測的空間，有利于抵制流言和黑公關，同時，還會贏得大眾的理解和支持?？纯碐itlab這次還去YouTube上直播整個修復過程，是件很了不起的事，大家可以到他們的blog上看看，對于這樣的透明和公開，一片好評。