昨天,，GitLab.com發(fā)生了一個大事，某同學(xué)誤刪了數(shù)據(jù)庫,，這個事看似是個低級錯誤,，不過,，因?yàn)镚itLab把整個過程的細(xì)節(jié)都全部暴露出來了，所以,，可以看到很多東西,，而對于類似這樣的事情，我自己以前也干過,，而在最近的兩公司中我也見過（Amazon中見過一次,，阿里中見過至少四次），正好通過這個事來說說一下自己的一些感想和觀點(diǎn)吧,。我先放個觀點(diǎn)：你覺得有備份系統(tǒng)就不會丟數(shù)據(jù)了嗎,？

整個事件的回顧GitLab.com在第一時間就放到了Google Doc上，事后,，又發(fā)了一篇Blog來說明這個事，在這里,，我簡單的回顧一下這個事件的過程,。

首先，一個叫YP的同學(xué)在給GitLab的線上數(shù)據(jù)庫做一些負(fù)載均衡的工作,，在做這個工作時的時候突發(fā)了一個情況,，GitLab被DDoS攻擊，數(shù)據(jù)庫的使用飆高,，在block完攻擊者的IP后,，發(fā)現(xiàn)有個staging的數(shù)據(jù)庫(db2.staging)已經(jīng)落后生產(chǎn)庫4GB的數(shù)據(jù)，于是YP同學(xué)在Fix這個staging庫的同步問題的時候,，發(fā)現(xiàn)db2.staging有各種問題都和主庫無法同步,，在這個時候，YP同學(xué)已經(jīng)工作的很晚了,，在嘗試過多個方法后,，發(fā)現(xiàn)db2.staging都hang在那里，無法同步,，于是他想把db2.staging的數(shù)據(jù)庫刪除了,，這樣全新啟動一個新的復(fù)制，結(jié)果呢,，刪除數(shù)據(jù)庫的命令錯誤的敲在了生產(chǎn)環(huán)境上（db1.cluster）,，結(jié)果導(dǎo)致整個生產(chǎn)數(shù)據(jù)庫被誤刪除（陳皓注：這個失敗基本上就是 “工作時間過長” “在多數(shù)終端窗口中切換中迷失掉了”）。

在恢復(fù)的過程中,，他們發(fā)現(xiàn)只有db1.staging的數(shù)據(jù)庫可以用于恢復(fù),，而其它的5種備份機(jī)制都不可用，第一個是數(shù)據(jù)庫的同步,，沒有同步webhook,，第二個是對硬盤的快照,，沒有對數(shù)據(jù)庫做，第三個是用pg_dump的備份,，發(fā)現(xiàn)版本不對（用9.2的版本去dump 9.6的數(shù)據(jù)）導(dǎo)致沒有dump出數(shù)據(jù),，第四個S3的備份，完全沒有備份上,，第五個是相關(guān)的備份流程是問題百出的,，只有幾個粗糙的人肉的腳本和糟糕的文檔，也就是說,，不但是是人肉的,，而且還是完全不可執(zhí)行的（陳皓注：就算是這些備份機(jī)制都work，其實(shí)也有問題,，因?yàn)檫@些備份大多數(shù)基本上都是24小時干一次,，所以，要從這些備份恢復(fù)也一定是是要丟數(shù)據(jù)的了,，只有第一個數(shù)據(jù)庫同步才會實(shí)時一些）,。

最終，GitLab從db1.staging上把6個小時前的數(shù)據(jù)copy回來,，結(jié)果發(fā)現(xiàn)速度非常的慢,，備份結(jié)點(diǎn)只有60Mbits/S，拷了很長時間（陳皓注：為什么不把db1.staging給直接變成生產(chǎn)機(jī),？因?yàn)槟桥_機(jī)器的性能很差）,。數(shù)據(jù)現(xiàn)在的恢復(fù)了，不過,，因?yàn)榛謴?fù)的數(shù)據(jù)是6小時前的,，所以，有如下的數(shù)據(jù)丟失掉了：

• 粗略估計(jì),，有4613 的項(xiàng)目,， 74 forks,  和 350 imports 丟失了；但是,，因?yàn)镚it倉庫還在,，所以，可以從Git倉庫反向推導(dǎo)數(shù)據(jù)庫中的數(shù)據(jù),，但是,，項(xiàng)目中的issues等就完全丟失了。

• 大約有±4979 提交記錄丟失了（陳皓注：估計(jì)也可以用git倉庫中反向恢復(fù)）,。

• 可能有 707  用戶丟失了,，這個數(shù)據(jù)來自Kibana的日志。

• 在1月31日17:20 后的Webhooks 丟失了。

因?yàn)镚itLab把整個事件的細(xì)節(jié)公開了出來,，所以,，也得到了很多外部的幫助，2nd Quadrant的CTO – Simon Riggs 在他的blog上也發(fā)布文章 Dataloss at GitLab 給了一些非常不錯的建議：

• 關(guān)于PostgreSQL 9.6的數(shù)據(jù)同步hang住的問題,，可能有一些Bug,，正在fix中。

• PostgreSQL有4GB的同步滯后是正常的,，這不是什么問題,。

• 正常的停止從結(jié)點(diǎn)，會讓主結(jié)點(diǎn)自動釋放WALSender的鏈接數(shù),，所以,，不應(yīng)該重新配置主結(jié)點(diǎn)的 max_wal_senders 參數(shù)。但是,，停止從結(jié)點(diǎn)時,，主結(jié)點(diǎn)的復(fù)數(shù)連接數(shù)不會很快的被釋放，而新啟動的從結(jié)點(diǎn)又會消耗更多的鏈接數(shù),。他認(rèn)為,，GitLab配置的32個鏈接數(shù)太高了，通常來說,，2到4個就足夠了。

• 另外,，之前GitLab配置的max_connections=8000太高了,，現(xiàn)在降到2000個是合理的。

• pg_basebackup 會先在主結(jié)點(diǎn)上建一個checkpoint,，然后再開始同步,，這個過程大約需要4分鐘。

• 手動的刪除數(shù)據(jù)庫目錄是非常危險(xiǎn)的操作,，這個事應(yīng)該交給程序來做,。推薦使用剛release 的 repmgr。

• 恢復(fù)備份也是非常重要的,，所以,，也應(yīng)該用相應(yīng)的程序來做。推薦使用 barman （其支持S3）,。

• 測試備份和恢復(fù)是一個很重要的過程,。

看這個樣子，估計(jì)也有一定的原因是——GitLab的同學(xué)對PostgreSQL不是很熟悉,。

隨后,，GitLab在其網(wǎng)站上也開了一系列的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

從上面的這個列表中,，我們可以看到一些改進(jìn)措施了,。挺好的，不過我覺得還不是很夠,。

因?yàn)轭愃七@樣的事,，我以前也干過（誤刪除過數(shù)據(jù)庫，在多個終端窗口中迷失掉了自己所操作的機(jī)器……）,，而且我在亞馬遜里也見過一次,，在阿里內(nèi)至少見過四次以上（在阿里人肉運(yùn)維的誤操作的事故是我見過最多的），但是我無法在這里公開分享,，私下可以分享,。在這里，我只想從非技術(shù)和技術(shù)兩個方面分享一下我的經(jīng)驗(yàn)和認(rèn)識,。

一直以來,，我都覺得直接到生產(chǎn)線上敲命令是一種非常不好的習(xí)慣。我認(rèn)為,，一個公司的運(yùn)維能力的強(qiáng)弱和你上線上環(huán)境敲命令是有關(guān)的,，你越是喜歡上線敲命令你的運(yùn)維能力就越弱，越是通過自動化來處理問題,，你的運(yùn)維能力就越強(qiáng),。理由如下：

1. 如果說對代碼的改動都是一次發(fā)布的話，那么,，對生產(chǎn)環(huán)境的任何改動（包括硬件,、操作系統(tǒng)、網(wǎng)絡(luò),、軟件配置……）,，也都算是一次發(fā)布。那么這樣的發(fā)布就應(yīng)該走發(fā)布系統(tǒng)和發(fā)布流程,，要被很好的測試,、上線和回滾計(jì)劃。關(guān)鍵是,，走發(fā)布過程是可以被記錄,、追蹤和回溯的，而在線上敲命令是完全無法追蹤的,。沒人知道你敲了什么命令,。

2. 真正良性的運(yùn)維能力是——人管代碼，代碼管機(jī)器,，而不是人管機(jī)器,。你敲了什么命令沒人知道，但是你寫個工具做變更線上系統(tǒng)，這個工具干了什么事,，看看工具的源碼就知道了,。

另外，有人說,，以后不要用rm了,，要用mv，還有人說,，以后干這樣的事時,，一個人干，另一個人在旁邊看,，還有人說,，要有一個checklist的強(qiáng)制流程做線上的變更，還有人說要增加一個權(quán)限系統(tǒng),。我覺得,，這些雖然可以work，但是依然不好,，因?yàn)椋?/p>

• 如果要解決一個事情需要加更多的人來做的事,，那這事就做成勞動密集型了。今天我們的科技就是在努力消除人力成本,，而不是在增加人力成本,。而做為一個技術(shù)人員，解決問題的最好方式是努力使用技術(shù)手段,，而不是使用更多的人肉手段,。人類區(qū)別于動物的差別就是會發(fā)明和使用現(xiàn)代化的工具，而不是使用更多的人力,。另外,，這不僅僅因?yàn)槭?，人都是會有這樣或那樣的問題（疲憊,、情緒化、急燥,、沖動……）,，而機(jī)器是單一無腦不知疲憊的，更是因?yàn)?，機(jī)器干活的效率和速度是比人肉高出N多倍的,。

• 增加一個權(quán)限系統(tǒng)或是別的一個watch dog的系統(tǒng)完全是在開倒車，權(quán)限系統(tǒng)中的權(quán)限誰來維護(hù)和審批,？不僅僅是因?yàn)槎喑鰜淼南到y(tǒng)需要多出來的維護(hù),，關(guān)鍵是這個事就沒有把問題解決在root上。除了為社會解決就業(yè)問題，別無好處,，故障依然會發(fā)生,，有權(quán)限的人一樣會誤操作。對于GitLab這個問題,，正如2nd Quadrant的CTO建議的那樣,，你需要的是一個自動化的備份和恢復(fù)的工具，而不是一個權(quán)限系統(tǒng),。

• 像使用mv而不rm,，搞一個checklist和一個更重的流程，更糟糕,。這里的邏輯很簡單,，因?yàn)椋?）這些規(guī)則需要人去學(xué)習(xí)和記憶，本質(zhì)上來說,，你本來就不相信人,，所以你搞出了一些規(guī)則和流程，而這些規(guī)則和流程的執(zhí)行,，又依賴于人,，換湯不換藥，2）另外,，寫在紙面上的東西都是不可執(zhí)行的,，可以執(zhí)行的就是只有程序，所以,，為什么不把checklist和流程寫成代碼呢（你可能會說程序也會犯錯,，是的，程序的錯誤是consistent,，而人的錯誤是inconsistent）,？

最關(guān)鍵的是，數(shù)據(jù)丟失有各種各樣的情況,，不單單只是人員的誤操作,，比如，掉電,、磁盤損壞,、中病毒等等，在這些情況下,，你設(shè)計(jì)的那些想流程,、規(guī)則、人肉檢查,、權(quán)限系統(tǒng),、checklist等等統(tǒng)統(tǒng)都不管用了,，這個時候，你覺得應(yīng)該怎么做呢,？是的,，你會發(fā)現(xiàn)，你不得不用更好的技術(shù)去設(shè)計(jì)出一個高可用的系統(tǒng),！別無它法,。

一個系統(tǒng)是需要做數(shù)據(jù)備份的，但是,，你會發(fā)現(xiàn),，GitLab這個事中，就算所有的備份都可用,，也不可避免地會有數(shù)據(jù)的丟失,，或是也會有很多問題。理由如下：

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

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

3. 有一些公司或是銀行有災(zāi)備的數(shù)據(jù)中心,，但是災(zāi)備的數(shù)據(jù)中心沒有一天live過,。等真正災(zāi)難來臨需要live的時候，你就會發(fā)現(xiàn),，各種問題讓你live不起來,。你可以讀一讀幾年前的這篇報(bào)道好好感受一下《以史為鑒，寧夏銀行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)的事務(wù)處理》，你還記得下面這張圖嗎,？看看 Data Loss 那一行的,，在Backups, Master/Slave 和 Master/Master的架構(gòu)下，都是會丟的,。

所以說,，如果你要讓你的備份系統(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),！別無它法,。（重要的事，得再說一篇）

另外,，你可以參看我的另一篇《關(guān)于高可用系統(tǒng)》,，這篇文章中以MySQL為例，數(shù)據(jù)庫的replication也只能達(dá)到 兩個9,。

AWS 的 S3 的的高可用是4個加11個9的持久性（所謂11個9的持久性durability,，AWS是這樣定義的，如果你存了1萬個對象,，那么丟一個的時間是1000萬年）,，這意味著，不僅僅只是硬盤壞,，機(jī)器掉電,，整個機(jī)房掛了，其保證可以承受有兩個設(shè)施的數(shù)據(jù)丟失,，數(shù)據(jù)還是可用的,。試想,，如果你把數(shù)據(jù)的可用性通過技術(shù)做到了這個份上，那么,，你還怕被人誤刪一個結(jié)點(diǎn)上的數(shù)據(jù)嗎,？

一般說來，故障都需要反思,，在Amazon,，S2以上的故障都需要寫COE（Correction of Errors），其中一節(jié)就是需要Ask 5 Whys,，我發(fā)現(xiàn)在GitLab的故障回顧的blog中第一段中也有說要在今天寫個Ask 5 Whys,。關(guān)于Ask 5 Whys，其實(shí)并不是亞馬遜的玩法,，這還是算一個業(yè)內(nèi)常用的玩法,，也就是說不斷的為自己為為什么，直到找到問題的概本原因,，這會逼著所有的當(dāng)事人去學(xué)習(xí)和深究很多東西,。在Wikipedia上有相關(guān)的詞條 5 Whys，其中羅列了14條規(guī)則：

• 你需要找到正確的團(tuán)隊(duì)來完成這個故障反思,。

• 使用紙或白板而不是電腦,。

• 寫下整個問題的過程，確保每個人都能看懂,。

• 區(qū)別原因和癥狀,。

• 特別注意因果關(guān)系。

• 說明Root Cause以及相關(guān)的證據(jù),。

• 5個為什么的答案需要是精確的,。

• 尋找問題根源的頻，而不是直接跳到結(jié)論,。

• 要基礎(chǔ)客觀的事實(shí),、數(shù)據(jù)和知識。

• 評估過程而不是人,。

• 千萬不要把“人為失誤”或是“工作不注意”當(dāng)成問題的根源,。

• 培養(yǎng)信任和真誠的氣氛和文化。

• 不斷的問“為什么”直到問題的根源被找到,。這樣可以保證同一個坑不會掉進(jìn)去兩次,。

• 當(dāng)你給出“為什么”的答案時，你應(yīng)該從用戶的角度來回答,。

上述的這些觀點(diǎn),，其實(shí)，我在我的以住的博客中都講過很多遍了,，你可以參看《什么是工程師文化,？》以及《開發(fā)團(tuán)隊(duì)的效率》。其實(shí),，說白了就是這么一個事——如果你是一個技術(shù)公司,，你就會更多的相信技術(shù)而不是管理。相信技術(shù)會用技術(shù)來解決問題,，相信管理,，那就只會有制度、流程和價值觀來解決問題,。

這個道理很簡單,，數(shù)據(jù)丟失有各種各樣的情況，不單單只是人員的誤操作,，比如,，掉電、磁盤損壞,、中病毒等等,，在這些情況下，你設(shè)計(jì)的那些流程,、規(guī)則,、人肉檢查、權(quán)限系統(tǒng),、checklist等等統(tǒng)統(tǒng)都不管用,，這個時候，你覺得應(yīng)該怎么做呢,？是的,，你會發(fā)現(xiàn)，你不得不用更好的技術(shù)去設(shè)計(jì)出一個高可用的系統(tǒng),！別無它法（重要的事得說三遍）,。

很多公司基本上都是這樣的套路，首先是極力掩蓋,，如果掩蓋不了了就開始撒謊,，撒不了謊了，就“文過飾非”,、“避重就輕”,、“轉(zhuǎn)移視線”。然而,，面對危機(jī)的最佳方法就是——“多一些真誠,，少一些套路”，所謂的“多一些真誠”的最佳實(shí)踐就是——“透明公開所有的信息”,，GitLab此次的這個事給大家樹立了非常好的榜樣,。AWS也會把自己所有的故障和細(xì)節(jié)都批露出來,。

事情本來就做錯了，而公開所有的細(xì)節(jié),，會讓大眾少很多猜測的空間,，有利于抵制流言和黑公關(guān)，同時,，還會贏得大眾的理解和支持,。看看GitLab這次還去YouTube上直播整個修復(fù)過程,，是件很了不起的事,，大家可以到他們的blog上看看，對于這樣的透明和公開,，一片好評,。

今日薦文

點(diǎn)擊下方圖片即可閱讀

Uncle Bob：如何成為一名優(yōu)秀的軟件架構(gòu)師？

---