無需跑路，GitLab 刪庫事件的借鑒意義

　　點擊圖片，立即加入開源中國碼云

　　摘要: 上周轟動一時的Gitlab事件終于塵埃落定了，不可否認的是這次事故Gitlab官方公關的的很出色，及時公布事件細節并尋求幫助，這讓本是一個失誤引發的事故，演變為一個真誠面對問題并反思的正面教材。對此，網絡上一片好評。

　　事態發展

　　截止北京時間2017/02/02 02:14,GitLab.com已恢復正常。期間丟失了 6 小時的數據庫數據（問題，合并請求，用戶，評論，片段等）。Git / wiki 存儲庫和自托管安裝不受影響。根據GitLab從日志里得出的結論，有707位用戶丟失數據，5,037項目丟失，受事故影響的用戶基數不到1%。

　　事件回顧

　　起因是在 2017/01/31 18:00左右，Gitlab檢測到垃圾郵件發送者通過創建片段來攻擊數據庫，使其不穩定，于是運維block攻擊者的IP,并移除用戶發送垃圾郵件。之后運維A發現db2.staging復制滯后生產庫4GB的數據（據后期2nd Quadrant的CTO – Simon Riggs 建議，PostgreSQL有4GB的同步滯后是正常的）,A開始嘗試修復db2,但復制失敗，A在嘗試了多種方案之后依然如此。

　　在2017年1月31日23：00 左右A決定刪除該db2數據庫目錄，令其重新復制。由于夜間開車時間很長，A錯誤的將db1.cluster.gitlab.com（生產庫）的數據庫刪除，而不是db2的。雖然在一兩秒之后意識到這個問題，終止了刪除操作，但為時已晚。大約 300 GB 左右的數據只剩下約4.5 GB。

　　隨后雖然有號稱有五重備份機制（常規備份（24小時做一次）、自動同步、LVM快照（24小時做一次）、Azure備份（只對 NFS 啟用，對數據庫無效）、S3備份),沒有一個可靠地運行或設置，最終只能基于LVM的備份（最近6小時以前），還原了6 小時前的備份。恢復期間Gitlab直播了這次恢復過程。

　　相關鏈接：

　　? Gitlab.com 因疲勞誤刪數據導致宕機超24小時，現已恢復

　　? Gitlab 的倒霉運維將被罰看 10 小時無聊視頻

　　? GitLab 稱有 707 位用戶超 5000 個項目丟失數據

　　借鑒意義

　　積極公開，尋求幫助

　　除了積極的公開事件詳細，GitLab的故障回顧中也說明了要對本次事故進行Ask 5 Whys。隨后在直播的過程中，官方也主動說明了不會辭退運維A,而是會罰他看一個名為 "10 hours of nyancat" 的視頻（http://www.nyan.cat/哈哈，很難看下去啊）。這個表明整個團隊對本次事故的處理態度是，齊心合力解決問題，然后檢討流程，不歸責于個人。這份處事態度也值得人欽佩，出現問題，首先不是追究責任，而是解決問題，然后發現后面的深層次問題，從而有效的避免下次再犯同樣錯誤。

　　防止人肉運維

　　事故發生后，有人建議不要用rm命令，采用mv命令，其實這個只能解決暫時問題，你們保證用其他命令就不會出問題么。另外有人建議建立一個checkList流程，每次執行的時候check一遍流程，有文檔做指示不會犯一些低級錯誤，如若每個命令都去check一下，工作是不會更復雜了。

　　另外還有一些建議雙人操作，增加權限系統等等，我覺得對于一個規范流程來說，一些必要的提示和規范可以增加，但是運維要自動化，以機器來代替人工，而不是開倒車去采用更多的人工來避免錯誤。

　　高可用分布系統

　　本次的事故在恢復的時候，發現有5個備份系統基本都無用，最終導致了6個小時數據的丟失。基于備份系統的缺陷，有運維同學建議如下：

蘇州數據恢復

　　1、審核所有數據的備份方案，備份頻率如何，備份數據放在哪里，保留多久。

　　2、對于云服務自帶的鏡像備份等服務，確認是否正確的打開和設置

　　3、對于自行搭建的備份方案，確認

　　4、定期做災備演習，檢驗是否可以正確從備份中恢復，以及此過程需要多少時間和資源。

　　從備份流程和規范來說，這些建議很中肯。從另外一個角度來說，即便是你的備份系統已經做到了這些，而且操作人員零失誤，但是丟失數據的問題也會發生，為何吶。

　　以下是采自左耳朵耗子《從Gitlab誤刪除數據庫想到的》的文字。

　　備份通常來說都是周期性的，所以，如果你的數據丟失了，從你最近的備份恢復數據里，從備份時間到故障時間的數據都丟失了。

　　備份的數據會有版本不兼容的問題。比如，在你上次備份數據到故障期間，你對數據的scheme做了一次改動，或是你對數據做了一些調整，那么，你備份的數據就會和你線上的程序出現不兼容的情況。

　　有一些公司或是銀行有災備的數據中心，但是災備的數據中心沒有一天live過。等真正災難來臨需要live的時候，你就會發現，各種問題讓你live不起來。你可以讀一讀幾年前的這篇報道好好感受一下《以史為鑒，寧夏銀行7月系統癱瘓最新解析》。

　　所以，在災難來臨的時候，你會發現你所設計精良的“備份系統”或是“災備系統”就算是平時可以工作，但也會導致數據丟失，而且可能長期不用的備份系統很難恢復（比如應用、工具、數據的版本不兼容等問題）。

　　所以說，如果你要讓你的備份系統隨時都可以用，那么你就要讓它隨時都Live著，而隨時都Live著的多結點系統，基本上就是一個分布式的高可用的系統。因為，數據丟失的原因有很多種，比如掉電、磁盤損壞、中病毒等等，而那些流程、規則、人肉檢查、權限系統、checklist等等都只是讓人不要誤操作，都不管用，這個時候，你不得不用更好的技術去設計出一個高可用的系統！別無它法。

　　以上是每種架構的優缺點，我們可以看到Backups、Master/Slave、Master/Master架構下，Data都是會出現loss的情況的，而2PC和Paxos是不會的。

　　謹防夜間開車

　　夜黑風高，夜間長時間開車，必然會有車禍現場的時候。這次事故的運維A,工作到深夜，想必也是和疲勞駕駛有一定的關系。

　　我們不評論8小時工作制度是否合理，但對于腦力勞動者，違背用腦規律甚至使之處于過載疲勞狀態，都會顯著降低腦部的能量轉換效率，還是科學用腦最為可靠，把時間用在效率最高的地方。對此希望決策者能夠意識到這個問題，而不是一味加班趕進度。這種危害已經越來越得到更多從業人員的認同了。

　　推薦閱讀

　　2017 年 Web 發展十大預測

　　幾款開源的 ETL 工具及 ELT 初探

　　日常用上這些開源項目，輕松提升網絡安全性能

　　小程序為何剛上線就遭冷落？部分已停止更新

　　一幅圖看懂 Linux 內核結構 | 漫畫

　　程序員不能錯過的 Git 技術干貨 | 碼云周刊

　　點擊“閱讀原文”查看更多精彩內容