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

最新動(dòng)態(tài):

截止北京時(shí)間2017/02/02 02:14,GitLab.com已恢復(fù)正常承耿。期間丟失了 6 小時(shí)的數(shù)據(jù)庫(kù)數(shù)據(jù)（問(wèn)題冠骄，合并請(qǐng)求，用戶加袋，評(píng)論凛辣，片段等）。Git / wiki 存儲(chǔ)庫(kù)和自托管安裝不受影響职烧。根據(jù)GitLab從日志里得出的結(jié)論蟀给，有707位用戶丟失數(shù)據(jù)，5,037項(xiàng)目丟失阳堕，受事故影響的用戶基數(shù)不到1%。

事件回顧：

起因是在 2017/01/31 18:00左右择克，Gitlab檢測(cè)到垃圾郵件發(fā)送者通過(guò)創(chuàng)建片段來(lái)攻擊數(shù)據(jù)庫(kù)恬总，使其不穩(wěn)定，于是運(yùn)維block攻擊者的IP,并移除用戶發(fā)送垃圾郵件肚邢。

之后運(yùn)維A發(fā)現(xiàn)db2.staging復(fù)制滯后生產(chǎn)庫(kù)4GB的數(shù)據(jù)（據(jù)后期2nd Quadrant的CTO – Simon Riggs 建議壹堰，PostgreSQL有4GB的同步滯后是正常的）,A開(kāi)始嘗試修復(fù)db2,但復(fù)制失敗，A在嘗試了多種方案之后依然如此骡湖。

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

隨后雖然有號(hào)稱有五重備份機(jī)制（常規(guī)備份（24小時(shí)做一次）罐孝、自動(dòng)同步、LVM快照（24小時(shí)做一次）肥缔、Azure備份（只對(duì) NFS 啟用莲兢，對(duì)數(shù)據(jù)庫(kù)無(wú)效）、S3備份),沒(méi)有一個(gè)可靠地運(yùn)行或設(shè)置，最終只能基于LVM的備份（最近6小時(shí)以前）改艇，還原了6 小時(shí)前的備份收班。恢復(fù)期間Gitlab直播了這次恢復(fù)過(guò)程遣耍。

詳細(xì)內(nèi)容請(qǐng)查閱文檔

借鑒意義

1闺阱、積極公開(kāi)，尋求幫助

本次事件讓我們大感震撼的是舵变，Gitlab居然主動(dòng)的公告了事件的細(xì)節(jié)酣溃，不但提交了詳盡的事故報(bào)告到googleDoc上，還在網(wǎng)絡(luò)上也積極的尋求幫助纪隙。

這份真誠(chéng)實(shí)在是令人敬佩赊豌。如果是一般的技術(shù)團(tuán)隊(duì)都是在向外界隱藏問(wèn)題，然后自己悶頭解決绵咱，最終時(shí)間耽誤了碘饼，用戶還不認(rèn)可你，而你自己也有苦說(shuō)不出悲伶。反而是Gitlab主動(dòng)公布艾恼，不但獲得了各方面的技術(shù)組織的鼎力幫助，還收獲了用戶的理解和支持麸锉，同時(shí)還讓網(wǎng)絡(luò)上也少了一份猜測(cè)和謠言钠绍。

除了積極的公開(kāi)事件詳細(xì)，GitLab的故障回顧中也說(shuō)明了要對(duì)本次事故進(jìn)行Ask 5 Whys花沉。隨后在直播的過(guò)程中柳爽，官方也主動(dòng)說(shuō)明了不會(huì)辭退運(yùn)維A,而是會(huì)罰他看一個(gè)名為 "10 hours of nyancat" 的視頻（http://www.nyan.cat/哈哈，很難看下去凹钇ā）磷脯。

這個(gè)表明整個(gè)團(tuán)隊(duì)對(duì)本次事故的處理態(tài)度是，齊心合力解決問(wèn)題娩脾，然后檢討流程赵誓，不歸責(zé)于個(gè)人。這份處事態(tài)度也值得人欽佩柿赊，出現(xiàn)問(wèn)題架曹，首先不是追究責(zé)任，而是解決問(wèn)題闹瞧，然后發(fā)現(xiàn)后面的深層次問(wèn)題绑雄，從而有效的避免下次再犯同樣錯(cuò)誤。

2奥邮、防止人肉運(yùn)維

事故發(fā)生后万牺，有人建議不要用rm命令罗珍，采用mv命令，其實(shí)這個(gè)只能解決暫時(shí)問(wèn)題脚粟，你們保證用其他命令就不會(huì)出問(wèn)題么覆旱。另外有人建議建立一個(gè)checkList流程，每次執(zhí)行的時(shí)候check一遍流程核无，有文檔做指示不會(huì)犯一些低級(jí)錯(cuò)誤扣唱，如若每個(gè)命令都去check一下，工作是不會(huì)更復(fù)雜了团南。

另外還有一些建議雙人操作噪沙，增加權(quán)限系統(tǒng)等等，我覺(jué)得對(duì)于一個(gè)規(guī)范流程來(lái)說(shuō)吐根，一些必要的提示和規(guī)范可以增加正歼，但是運(yùn)維要自動(dòng)化，以機(jī)器來(lái)代替人工拷橘，而不是開(kāi)倒車(chē)去采用更多的人工來(lái)避免錯(cuò)誤局义。

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

本次的事故在恢復(fù)的時(shí)候冗疮，發(fā)現(xiàn)有5個(gè)備份系統(tǒng)基本都無(wú)用萄唇，最終導(dǎo)致了6個(gè)小時(shí)數(shù)據(jù)的丟失∈踽＃基于備份系統(tǒng)的缺陷穷绵，有運(yùn)維同學(xué)建議如下：

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

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

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

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

從備份流程和規(guī)范來(lái)說(shuō)咬摇，這些建議很中肯。從另外一個(gè)角度來(lái)說(shuō)煞躬，即便是你的備份系統(tǒng)已經(jīng)做到了這些肛鹏，而且操作人員零失誤逸邦，但是丟失數(shù)據(jù)的問(wèn)題也會(huì)發(fā)生，為何吶在扰。

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

備份通常來(lái)說(shuō)都是周期性的，所以芒珠，如果你的數(shù)據(jù)丟失了桥狡，從你最近的備份恢復(fù)數(shù)據(jù)里，從備份時(shí)間到故障時(shí)間的數(shù)據(jù)都丟失了皱卓。

備份的數(shù)據(jù)會(huì)有版本不兼容的問(wèn)題裹芝。比如，在你上次備份數(shù)據(jù)到故障期間好爬，你對(duì)數(shù)據(jù)的scheme做了一次改動(dòng)局雄，或是你對(duì)數(shù)據(jù)做了一些調(diào)整，那么存炮，你備份的數(shù)據(jù)就會(huì)和你線上的程序出現(xiàn)不兼容的情況炬搭。

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

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

所以說(shuō)猜旬，如果你要讓你的備份系統(tǒng)隨時(shí)都可以用，那么你就要讓它隨時(shí)都Live著倦卖，而隨時(shí)都Live著的多結(jié)點(diǎn)系統(tǒng)洒擦，基本上就是一個(gè)分布式的高可用的系統(tǒng)。因?yàn)?b>怕膛，數(shù)據(jù)丟失的原因有很多種熟嫩，比如掉電、磁盤(pán)損壞褐捻、中病毒等等邦危，而那些流程洋侨、規(guī)則、人肉檢查倦蚪、權(quán)限系統(tǒng)希坚、checklist等等都只是讓人不要誤操作，都不管用陵且，這個(gè)時(shí)候裁僧，你不得不用更好的技術(shù)去設(shè)計(jì)出一個(gè)高可用的系統(tǒng)！別無(wú)它法慕购。

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

4贡珊、謹(jǐn)防夜間開(kāi)車(chē)

夜黑風(fēng)高，夜間長(zhǎng)時(shí)間開(kāi)車(chē)涉馁，必然會(huì)有車(chē)禍現(xiàn)場(chǎng)的時(shí)候门岔。這次事故的運(yùn)維A,工作到深夜，想必也是和疲勞駕駛有一定的關(guān)系烤送。

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