從GITLAB誤刪除數(shù)據(jù)庫(kù)想到的

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

創(chuàng)新互聯(lián)建站于2013年成立，先為朝陽(yáng)等服務(wù)建站，朝陽(yáng)等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢(xún)服務(wù)。為朝陽(yáng)企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問(wèn)題。

事件回顧

整個(gè)事件的回顧Gitlab.com在第一時(shí)間就放到了Google Doc上，事后，又發(fā)了一篇Blog來(lái)說(shuō)明這個(gè)事，在這里，我簡(jiǎn)單的回顧一下這個(gè)事件的過(guò)程。

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

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

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

粗略估計(jì)，有4613 的項(xiàng)目， 74 forks, 和 350 imports 丟失了;但是，因?yàn)镚it倉(cāng)庫(kù)還在，所以，可以從Git倉(cāng)庫(kù)反向推導(dǎo)數(shù)據(jù)庫(kù)中的數(shù)據(jù)，但是，項(xiàng)目中的issues等就完全丟失了。 大約有±4979 提交記錄丟失了(陳皓注：估計(jì)也可以用git倉(cāng)庫(kù)中反向恢復(fù))。 可能有 707 用戶(hù)丟失了，這個(gè)數(shù)據(jù)來(lái)自Kibana的日志。 在1月31日17:20 后的Webhooks 丟失了。

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

關(guān)于PostgreSQL 9.6的數(shù)據(jù)同步hang住的問(wèn)題，可能有一些Bug，正在fix中。 PostgreSQL有4GB的同步滯后是正常的，這不是什么問(wèn)題。 正常的停止從結(jié)點(diǎn)，會(huì)讓主結(jié)點(diǎn)自動(dòng)釋放WALSender的鏈接數(shù)，所以，不應(yīng)該重新配置主結(jié)點(diǎn)的 max_wal_senders 參數(shù)。但是，停止從結(jié)點(diǎn)時(shí)，主結(jié)點(diǎn)的復(fù)數(shù)連接數(shù)不會(huì)很快的被釋放，而新啟動(dòng)的從結(jié)點(diǎn)又會(huì)消耗更多的鏈接數(shù)。他認(rèn)為，Gitlab配置的32個(gè)鏈接數(shù)太高了，通常來(lái)說(shuō)，2到4個(gè)就足夠了。 另外，之前gitlab配置的max_connections=8000太高了，現(xiàn)在降到2000個(gè)是合理的。 pg_basebackup 會(huì)先在主結(jié)點(diǎn)上建一個(gè)checkpoint，然后再開(kāi)始同步，這個(gè)過(guò)程大約需要4分鐘。 手動(dòng)的刪除數(shù)據(jù)庫(kù)目錄是非常危險(xiǎn)的操作，這個(gè)事應(yīng)該交給程序來(lái)做。推薦使用剛release 的 repmgr 恢復(fù)備份也是非常重要的，所以，也應(yīng)該用相應(yīng)的程序來(lái)做。推薦使用 barman (其支持S3) 測(cè)試備份和恢復(fù)是一個(gè)很重要的過(guò)程。

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

隨后，Gitlab在其網(wǎng)站上也開(kāi)了一系列的issues，其issues列表在這里 Write post-mortem (這個(gè)列表可能還會(huì)在不斷更新中)

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

相關(guān)的思考

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

技術(shù)方面

人肉運(yùn)維

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

其一，如果說(shuō)對(duì)代碼的改動(dòng)都是一次發(fā)布的話(huà)，那么，對(duì)生產(chǎn)環(huán)境的任何改動(dòng)(包括硬件、操作系統(tǒng)、網(wǎng)絡(luò)、軟件配置……)，也都算是一次發(fā)布。那么這樣的發(fā)布就應(yīng)該走發(fā)布系統(tǒng)和發(fā)布流程，要被很好的測(cè)試、上線(xiàn)和回滾計(jì)劃。關(guān)鍵是，走發(fā)布過(guò)程是可以被記錄、追蹤和回溯的，而在線(xiàn)上敲命令是完全無(wú)法追蹤的。沒(méi)人知道你敲了什么命令。 其二，真正良性的運(yùn)維能力是——人管代碼，代碼管機(jī)器，而不是人管機(jī)器。你敲了什么命令沒(méi)人知道，但是你寫(xiě)個(gè)工具做變更線(xiàn)上系統(tǒng)，這個(gè)工具干了什么事，看看工具的源碼就知道了。

另外、有人說(shuō)，以后不要用rm了，要用mv，還有人說(shuō)，以后干這樣的事時(shí)，一個(gè)人干，另一個(gè)人在旁邊看，還有人說(shuō)，要有一個(gè)checklist的強(qiáng)制流程做線(xiàn)上的變更，還有人說(shuō)要增加一個(gè)權(quán)限系統(tǒng)。我覺(jué)得，這些雖然可以work，但是依然不好，再由如下：

其一、如果要解決一個(gè)事情需要加更多的人來(lái)做的事，那這事就做成勞動(dòng)密集型了。今天我們的科技就是在努力消除人力成本，而不是在增加人力成本。而做為一個(gè)技術(shù)人員，解決問(wèn)題的最好方式是努力使用技術(shù)手段，而不是使用更多的人肉手段。人類(lèi)區(qū)別于動(dòng)物的差別就是會(huì)發(fā)明和使用現(xiàn)代化的工具，而不是使用更多的人力。另外，這不僅僅因?yàn)槭牵硕际菚?huì)有這樣或那樣的問(wèn)題(疲憊、情緒化、急燥、沖動(dòng)……)，而機(jī)器是單一無(wú)腦不知疲憊的，更是因?yàn)椋瑱C(jī)器干活的效率和速度是比人肉高出N多倍的。 其二、增加一個(gè)權(quán)限系統(tǒng)或是別的一個(gè)watch dog的系統(tǒng)完全是在開(kāi)倒車(chē)，權(quán)限系統(tǒng)中的權(quán)限誰(shuí)來(lái)維護(hù)和審批?不僅僅是因?yàn)槎喑鰜?lái)的系統(tǒng)需要多出來(lái)的維護(hù)，關(guān)鍵是這個(gè)事就沒(méi)有把問(wèn)題解決在root上。除了為社會(huì)解決就業(yè)問(wèn)題，別無(wú)好處，故障依然會(huì)發(fā)生，有權(quán)限的人一樣會(huì)誤操作。對(duì)于Gitlab這個(gè)問(wèn)題，正如2nd Quadrant的CTO建議的那樣，你需要的是一個(gè)自動(dòng)化的備份和恢復(fù)的工具，而不是一個(gè)權(quán)限系統(tǒng)。 其三、像使用mv而不rm，搞一個(gè)checklist和一個(gè)更重的流程，更糟糕。這里的邏輯很簡(jiǎn)單，因?yàn)椋?)這些規(guī)則需要人去學(xué)習(xí)和記憶，本質(zhì)上來(lái)說(shuō)，你本來(lái)就不相信人，所以你搞出了一些規(guī)則和流程，而這些規(guī)則和流程的執(zhí)行，又依賴(lài)于人，換湯不換藥，2)另外，寫(xiě)在紙面上的東西都是不可執(zhí)行的，可以執(zhí)行的就是只有程序，所以，為什么不把checklist和流程寫(xiě)成代碼呢?(你可能會(huì)說(shuō)程序也會(huì)犯錯(cuò)，是的，程序的錯(cuò)誤是consistent，而人的錯(cuò)誤是inconsistent)

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

關(guān)于備份

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

1)備份通常來(lái)說(shuō)都是周期性的，所以，如果你的數(shù)據(jù)丟失了，從你最近的備份恢復(fù)數(shù)據(jù)里，從備份時(shí)間到故障時(shí)間的數(shù)據(jù)都丟失了。 2)備份的數(shù)據(jù)會(huì)有版本不兼容的問(wèn)題。比如，在你上次備份數(shù)據(jù)到故障期間，你對(duì)數(shù)據(jù)的scheme做了一次改動(dòng)，或是你對(duì)數(shù)據(jù)做了一些調(diào)整，那么，你備份的數(shù)據(jù)就會(huì)和你線(xiàn)上的程序出現(xiàn)不兼容的情況。 3)有一些公司或是銀行有災(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)題)。

我之前寫(xiě)過(guò)一篇《分布式系統(tǒng)的事務(wù)處理》，你還記得下面這張圖嗎?看看 Data Loss 那一行的，在Backups, Master/Slave 和 Master/Master的架構(gòu)下，都是會(huì)丟的。

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

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

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

非技術(shù)方面

故障反思

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

你需要找到正確的團(tuán)隊(duì)來(lái)完成這個(gè)故障反思。 使用紙或白板而不是電腦。 寫(xiě)下整個(gè)問(wèn)題的過(guò)程，確保每個(gè)人都能看懂。 區(qū)別原因和癥狀。 特別注意因果關(guān)系。 說(shuō)明Root Cause以及相關(guān)的證據(jù)。 5個(gè)為什么的答案需要是精確的。 尋找問(wèn)題根源的頻，而不是直接跳到結(jié)論。 要基礎(chǔ)客觀的事實(shí)、數(shù)據(jù)和知識(shí)。 評(píng)估過(guò)程而不是人。 千萬(wàn)不要把“人為失誤”或是“工作不注意”當(dāng)成問(wèn)題的根源。 培養(yǎng)信任和真誠(chéng)的氣氛和文化。 不斷的問(wèn)“為什么”直到問(wèn)題的根源被找到。這樣可以保證同一個(gè)坑不會(huì)掉進(jìn)去兩次。 當(dāng)你給出“為什么”的答案時(shí)，你應(yīng)該從用戶(hù)的角度來(lái)回答。

工程師文化

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

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

事件公開(kāi)

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

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

本文名稱(chēng)：從GITLAB誤刪除數(shù)據(jù)庫(kù)想到的
網(wǎng)頁(yè)URL：http://muchs.cn/article32/soiosc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)建站、企業(yè)建站、品牌網(wǎng)站建設(shè)、軟件開(kāi)發(fā)、網(wǎng)站設(shè)計(jì)公司、靜態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)