昨天，Gitlab.com發生了一個大事，某同學誤刪了數據庫，這個事看似是個低級錯誤，不過，因爲Gitlab把整個過程的細節都全部暴露出來了，所以，可以看到很多東西，而對於類似這樣的事情，我自己以前也幹過，而在最近的兩公司中我也見過（Amazon中見過一次，阿里中見過至少四次），正好通過這個事來說說一下自己的一些感想和觀點吧。我先放個觀點：你覺得有備份系統就不會丟數據了嗎？
事件回顧
整個事件的回顧Gitlab.com在第一時間就放到了Google Doc上，事後，又發了一篇Blog來說明這個事，在這裏，我簡單的回顧一下這個事件的過程。
首先，一個叫YP的同學在給gitlab的線上數據庫做一些負載均衡的工作，在做這個工作時的時候突發了一個情況，Gitlab被DDoS攻擊，數據庫的使用飆高，在block完攻擊者的IP後，發現有個staging的數據庫(db2.staging)已經落後生產庫4GB的數據，於是YP同學在Fix這個staging庫的同步問題的時候，發現db2.staging有各種問題都和主庫無法同步，在這個時候，YP同學已經工作的很晚了，在嘗試過多個方法後，發現db2.staging都hang在那裏，無法同步，於是他想把db2.staging的數據庫刪除了，這樣全新啓動一個新的複製，結果呢，刪除數據庫的命令錯誤的敲在了生產環境上（db1.cluster），結果導致整個生產數據庫被誤刪除。（陳皓注：這個失敗基本上就是 “工作時間過長” + “在多數終端窗口中切換中迷失掉了”）
在恢復的過程中，他們發現只有db1.staging的數據庫可以用於恢復，而其它的5種備份機制都不可用，第一個是數據庫的同步，沒有同步webhook，第二個是對硬盤的快照，沒有對數據庫做，第三個是用pg_dump的備份，發現版本不對（用9.2的版本去dump 9.6的數據）導致沒有dump出數據，第四個S3的備份，完全沒有備份上，第五個是相關的備份流程是問題百出的，只有幾個粗糙的人肉的腳本和糟糕的文檔，也就是說，不但是是人肉的，而且還是完全不可執行的。（陳皓注：就算是這些備份機制都work，其實也有問題，因爲這些備份大多數基本上都是24小時幹一次，所以，要從這些備份恢復也一定是是要丟數據的了，只有第一個數據庫同步纔會實時一些）
最終，gitlab從db1.staging上把6個小時前的數據copy回來，結果發現速度非常的慢，備份結點只有60Mbits/S，拷了很長時間（陳皓注：爲什麼不把db1.staging給直接變成生產機？因爲那臺機器的性能很差）。數據現在的恢復了，不過，因爲恢復的數據是6小時前的，所以，有如下的數據丟失掉了：
- 粗略估計，有4613 的項目， 74 forks, 和 350 imports 丟失了；但是，因爲Git倉庫還在，所以，可以從Git倉庫反向推導數據庫中的數據，但是，項目中的issues等就完全丟失了。
- 大約有±4979 提交記錄丟失了（陳皓注：估計也可以用git倉庫中反向恢復）。
- 可能有 707 用戶丟失了，這個數據來自Kibana的日誌。
- 在1月31日17:20 後的Webhooks 丟失了。
因爲Gitlab把整個事件的細節公開了出來，所以，也得到了很多外部的幫助，2nd Quadrant的CTO – Simon Riggs 在他的blog上也發佈文章 Dataloss at Gitlab 給了一些非常不錯的建議：
- 關於PostgreSQL 9.6的數據同步hang住的問題，可能有一些Bug，正在fix中。
- PostgreSQL有4GB的同步滯後是正常的，這不是什麼問題。
- 正常的停止從結點，會讓主結點自動釋放WALSender的鏈接數，所以，不應該重新配置主結點的 max_wal_senders 參數。但是，停止從結點時，主結點的複數連接數不會很快的被釋放，而新啓動的從結點又會消耗更多的鏈接數。他認爲，Gitlab配置的32個鏈接數太高了，通常來說，2到4個就足夠了。
- 另外，之前gitlab配置的max_connections=8000太高了，現在降到2000個是合理的。
- pg_basebackup 會先在主結點上建一個checkpoint，然後再開始同步，這個過程大約需要4分鐘。
- 手動的刪除數據庫目錄是非常危險的操作，這個事應該交給程序來做。推薦使用剛release 的 repmgr
- 恢復備份也是非常重要的，所以，也應該用相應的程序來做。推薦使用 barman （其支持S3）
- 測試備份和恢復是一個很重要的過程。
看這個樣子，估計也有一定的原因是——Gitlab的同學對PostgreSQL不是很熟悉。
隨後，Gitlab在其網站上也開了一系列的issues，其issues列表在這裏 Write post-mortem (這個列表可能還會在不斷更新中)
- infrastructure#1094 – Update PS1 across all hosts to more clearly differentiate between hosts and environments
- infrastructure#1095 – Prometheus monitoring for backups
- infrastructure#1096 – Set PostgreSQL’s max_connections to a sane value
- infrastructure#1097 – Investigate Point in time recovery & continuous archiving for PostgreSQL
- infrastructure#1098 – Hourly LVM snapshots of the production databases
- infrastructure#1099 – Azure disk snapshots of production databases
- infrastructure#1100 – Move staging to the ARM environment
- infrastructure#1101 – Recover production replica(s)
- infrastructure#1102 – Automated testing of recovering PostgreSQL database backups
- infrastructure#1103 – Improve PostgreSQL replication documentation/runbooks
- infrastructure#1104 – Kick out SSH users inactive for N minutes
- infrastructure#1105 – Investigate pgbarman for creating PostgreSQL backups
從上面的這個列表中，我們可以看到一些改進措施了。挺好的，不過我覺得還不是很夠。
相關的思考
因爲類似這樣的事，我以前也幹過（誤刪除過數據庫，在多個終端窗口中迷失掉了自己所操作的機器……），而且我在amazon裏也見過一次，在阿里內至少見過四次以上（在阿里人肉運維的誤操作的事故是我見過最多的），但是我無法在這裏公開分享，私下可以分享。在這裏，我只想從非技術和技術兩個方面分享一下我的經驗和認識。
技術方面
人肉運維
一直以來，我都覺得直接到生產線上敲命令是一種非常不好的習慣。我認爲，一個公司的運維能力的強弱和你上線上環境敲命令是有關的，你越是喜歡上線敲命令你的運維能力就越弱，越是通過自動化來處理問題，你的運維能力就越強。理由如下：
其一，如果說對代碼的改動都是一次發佈的話，那麼，對生產環境的任何改動（包括硬件、操作系統、網絡、軟件配置……），也都算是一次發佈。那麼這樣的發佈就應該走發佈系統和發佈流程，要被很好的測試、上線和回滾計劃。關鍵是，走發佈過程是可以被記錄、追蹤和回溯的，而在線上敲命令是完全無法追蹤的。沒人知道你敲了什麼命令。
其二，真正良性的運維能力是——人管代碼，代碼管機器，而不是人管機器。你敲了什麼命令沒人知道，但是你寫個工具做變更線上系統，這個工具幹了什麼事，看看工具的源碼就知道了。
另外、有人說，以後不要用rm了，要用mv，還有人說，以後幹這樣的事時，一個人幹，另一個人在旁邊看，還有人說，要有一個checklist的強制流程做線上的變更，還有人說要增加一個權限系統。我覺得，這些雖然可以work，但是依然不好，再由如下：
其一、如果要解決一個事情需要加更多的人來做的事，那這事就做成勞動密集型了。今天我們的科技就是在努力消除人力成本，而不是在增加人力成本。而做爲一個技術人員，解決問題的最好方式是努力使用技術手段，而不是使用更多的人肉手段。人類區別於動物的差別就是會發明和使用現代化的工具，而不是使用更多的人力。另外，這不僅僅因爲是，人都是會有這樣或那樣的問題（疲憊、情緒化、急燥、衝動……），而機器是單一無腦不知疲憊的，更是因爲，機器幹活的效率和速度是比人肉高出N多倍的。
其二、增加一個權限系統或是別的一個watch dog的系統完全是在開倒車，權限系統中的權限誰來維護和審批？不僅僅是因爲多出來的系統需要多出來的維護，關鍵是這個事就沒有把問題解決在root上。除了爲社會解決就業問題，別無好處，故障依然會發生，有權限的人一樣會誤操作。對於Gitlab這個問題，正如2nd Quadrant的CTO建議的那樣，你需要的是一個自動化的備份和恢復的工具，而不是一個權限系統。
其三、像使用mv而不rm，搞一個checklist和一個更重的流程，更糟糕。這裏的邏輯很簡單，因爲，1）這些規則需要人去學習和記憶，本質上來說，你本來就不相信人，所以你搞出了一些規則和流程，而這些規則和流程的執行，又依賴於人，換湯不換藥，2）另外，寫在紙面上的東西都是不可執行的，可以執行的就是隻有程序，所以，爲什麼不把checklist和流程寫成代碼呢？（你可能會說程序也會犯錯，是的，程序的錯誤是consistent，而人的錯誤是inconsistent）
最關鍵的是，數據丟失有各種各樣的情況，不單單只是人員的誤操作，比如，掉電、磁盤損壞、中病毒等等，在這些情況下，你設計的那些想流程、規則、人肉檢查、權限系統、checklist等等統統都不管用了，這個時候，你覺得應該怎麼做呢？是的，你會發現，你不得不用更好的技術去設計出一個高可用的系統！別無它法。
關於備份
一個系統是需要做數據備份的，但是，你會發現，Gitlab這個事中，就算所有的備份都可用，也不可避免地會有數據的丟失，或是也會有很多問題。理由如下：
1）備份通常來說都是週期性的，所以，如果你的數據丟失了，從你最近的備份恢復數據裏，從備份時間到故障時間的數據都丟失了。
2）備份的數據會有版本不兼容的問題。比如，在你上次備份數據到故障期間，你對數據的scheme做了一次改動，或是你對數據做了一些調整，那麼，你備份的數據就會和你線上的程序出現不兼容的情況。
3）有一些公司或是銀行有災備的數據中心，但是災備的數據中心沒有一天live過。等真正災難來臨需要live的時候，你就會發現，各種問題讓你live不起來。你可以讀一讀幾年前的這篇報道好好感受一下《以史爲鑑 寧夏銀行7月系統癱瘓最新解析》
所以，在災難來臨的時候，你會發現你所設計精良的“備份系統”或是“災備系統”就算是平時可以工作，但也會導致數據丟失，而且可能長期不用的備份系統很難恢復（比如應用、工具、數據的版本不兼容等問題）。
我之前寫過一篇《分佈式系統的事務處理》，你還記得下面這張圖嗎？看看 Data Loss 那一行的，在Backups, Master/Slave 和 Master/Master的架構下，都是會丟的。
所以說，如果你要讓你的備份系統隨時都可以用，那麼你就要讓它隨時都Live着，而隨時都Live着的多結點系統，基本上就是一個分佈式的高可用的系統。因爲，數據丟失的原因有很多種，比如掉電、磁盤損壞、中病毒等等，而那些流程、規則、人肉檢查、權限系統、checklist等等都只是讓人不要誤操作，都不管用，這個時候，你不得不用更好的技術去設計出一個高可用的系統！別無它法。（重要的事，得再說一篇）
另外，你可以參看我的另一篇《關於高可用系統》，這篇文章中以MySQL爲例，數據庫的replication也只能達到 兩個9。
AWS 的 S3 的的高可用是4個加11個9的持久性（所謂11個9的持久性durability，AWS是這樣定義的，如果你存了1萬個對象，那麼丟一個的時間是1000萬年），這意味着，不僅僅只是硬盤壞，機器掉電，整個機房掛了，其保證可以承受有兩個設施的數據丟失，數據還是可用的。試想，如果你把數據的可用性通過技術做到了這個份上，那麼，你還怕被人誤刪一個結點上的數據嗎？
非技術方面
故障反思
一般說來，故障都需要反思，在Amazon，S2以上的故障都需要寫COE（Correction of Errors），其中一節就是需要Ask 5 Whys，我發現在Gitlab的故障回顧的blog中第一段中也有說要在今天寫個Ask 5 Whys。關於Ask 5 Whys，其實並不是亞馬遜的玩法，這還是算一個業內常用的玩法，也就是說不斷的爲自己爲爲什麼，直到找到問題的概本原因，這會逼着所有的當事人去學習和深究很多東西。在Wikipedia上有相關的詞條 5 Whys，其中羅列了14條規則：
- 你需要找到正確的團隊來完成這個故障反思。
- 使用紙或白板而不是電腦。
- 寫下整個問題的過程，確保每個人都能看懂。
- 區別原因和症狀。
- 特別注意因果關係。
- 說明Root Cause以及相關的證據。
- 5個爲什麼的答案需要是精確的。
- 尋找問題根源的頻，而不是直接跳到結論。
- 要基礎客觀的事實、數據和知識。
- 評估過程而不是人。
- 千萬不要把“人爲失誤”或是“工作不注意”當成問題的根源。
- 培養信任和真誠的氣氛和文化。
- 不斷的問“爲什麼”直到問題的根源被找到。這樣可以保證同一個坑不會掉進去兩次。
- 當你給出“爲什麼”的答案時，你應該從用戶的角度來回答。
工程師文化
上述的這些觀點，其實，我在我的以住的博客中都講過很多遍了，你可以參看《什麼是工程師文化？》以及《開發團隊的效率》。其實，說白了就是這麼一個事——如果你是一個技術公司，你就會更多的相信技術而不是管理。相信技術會用技術來解決問題，相信管理，那就只會有制度、流程和價值觀來解決問題。
這個道理很簡單，數據丟失有各種各樣的情況，不單單只是人員的誤操作，比如，掉電、磁盤損壞、中病毒等等，在這些情況下，你設計的那些流程、規則、人肉檢查、權限系統、checklist等等統統都不管用，這個時候，你覺得應該怎麼做呢？是的，你會發現，你不得不用更好的技術去設計出一個高可用的系統！別無它法。（重要的事得說三遍）
事件公開
很多公司基本上都是這樣的套路，首先是極力掩蓋，如果掩蓋不了了就開始撒謊，撒不了謊了，就“文過飾非”、“避重就輕”、“轉移視線”。然而，面對危機的最佳方法就是——“多一些真誠，少一些套路”，所謂的“多一些真誠”的最佳實踐就是——“透明公開所有的信息”，Gitlab此次的這個事給大家樹立了非常好的榜樣。AWS也會把自己所有的故障和細節都批露出來。
事情本來就做錯了，而公開所有的細節，會讓大衆少很多猜測的空間，有利於抵制流言和黑公關，同時，還會贏得大衆的理解和支持。看看Gitlab這次還去YouTube上直播整個修復過程，是件很了不起的事，大家可以到他們的blog上看看，對於這樣的透明和公開，一片好評。