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

　　點(diǎn)擊圖片，立即加入開源中國碼云

　　摘要: 上周轟動一時的Gitlab事件終于塵埃落定了，不可否認(rèn)的是這次事故Gitlab官方公關(guān)的的很出色，及時公布事件細(xì)節(jié)并尋求幫助，這讓本是一個失誤引發(fā)的事故，演變?yōu)橐粋€真誠面對問題并反思的正面教材。對此，網(wǎng)絡(luò)上一片好評。

　　事態(tài)發(fā)展

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

　　事件回顧

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

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

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

　　相關(guān)鏈接：

　　? Gitlab.com 因疲勞誤刪數(shù)據(jù)導(dǎo)致宕機(jī)超24小時，現(xiàn)已恢復(fù)

　　? Gitlab 的倒霉運(yùn)維將被罰看 10 小時無聊視頻

　　? GitLab 稱有 707 位用戶超 5000 個項(xiàng)目丟失數(shù)據(jù)

　　借鑒意義

　　積極公開，尋求幫助

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

　　防止人肉運(yùn)維

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

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

　　高可用分布系統(tǒng)

　　本次的事故在恢復(fù)的時候，發(fā)現(xiàn)有5個備份系統(tǒng)基本都無用，最終導(dǎo)致了6個小時數(shù)據(jù)的丟失?；趥浞菹到y(tǒng)的缺陷，有運(yùn)維同學(xué)建議如下：

蘇州數(shù)據(jù)恢復(fù)

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

　　2、對于云服務(wù)自帶的鏡像備份等服務(wù)，確認(rèn)是否正確的打開和設(shè)置

　　3、對于自行搭建的備份方案，確認(rèn)

　　4、定期做災(zāi)備演習(xí)，檢驗(yàn)是否可以正確從備份中恢復(fù)，以及此過程需要多少時間和資源。

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

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

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

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

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

　　所以，在災(zāi)難來臨的時候，你會發(fā)現(xiàn)你所設(shè)計(jì)精良的“備份系統(tǒng)”或是“災(zāi)備系統(tǒng)”就算是平時可以工作，但也會導(dǎo)致數(shù)據(jù)丟失，而且可能長期不用的備份系統(tǒng)很難恢復(fù)（比如應(yīng)用、工具、數(shù)據(jù)的版本不兼容等問題）。

　　所以說，如果你要讓你的備份系統(tǒng)隨時都可以用，那么你就要讓它隨時都Live著，而隨時都Live著的多結(jié)點(diǎn)系統(tǒng)，基本上就是一個分布式的高可用的系統(tǒng)。因?yàn)椋瑪?shù)據(jù)丟失的原因有很多種，比如掉電、磁盤損壞、中病毒等等，而那些流程、規(guī)則、人肉檢查、權(quán)限系統(tǒng)、checklist等等都只是讓人不要誤操作，都不管用，這個時候，你不得不用更好的技術(shù)去設(shè)計(jì)出一個高可用的系統(tǒng)！別無它法。

　　以上是每種架構(gòu)的優(yōu)缺點(diǎn)，我們可以看到Backups、Master/Slave、Master/Master架構(gòu)下，Data都是會出現(xiàn)loss的情況的，而2PC和Paxos是不會的。

　　謹(jǐn)防夜間開車

　　夜黑風(fēng)高，夜間長時間開車，必然會有車禍現(xiàn)場的時候。這次事故的運(yùn)維A,工作到深夜，想必也是和疲勞駕駛有一定的關(guān)系。

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

　　推薦閱讀

　　2017 年 Web 發(fā)展十大預(yù)測

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

　　日常用上這些開源項(xiàng)目，輕松提升網(wǎng)絡(luò)安全性能

　　小程序?yàn)楹蝿偵暇€就遭冷落？部分已停止更新

　　一幅圖看懂 Linux 內(nèi)核結(jié)構(gòu) | 漫畫

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

　　點(diǎn)擊“閱讀原文”查看更多精彩內(nèi)容