本文對GitLab事件進(jìn)行了全盤回顧，繼續(xù)追蹤GitLab在2月1日發(fā)布的申明，追溯各種問題根本原因。然后陳列了恢復(fù)在線后，GitLab聲明了哪些下一步舉措。最后摘錄了一些網(wǎng)友在Twitter和YouTube的評論，大多數(shù)人都對GitLab表達(dá)了自己的支持和寬容。

事件總覽

2017年1月31日18:00（UTC時間），GitLab通過推特發(fā)文承認(rèn)300GB生產(chǎn)環(huán)境數(shù)據(jù)因為UNIX SA的誤操作，已經(jīng)被徹底刪除（后發(fā)文補充說明已經(jīng)挽回部分?jǐn)?shù)據(jù)），引起業(yè)界一片嘩然。

2017年2月1日 18:14（UTC時間），GitLab.com恢復(fù)在線。通過使用一個之前的6小時備份數(shù)據(jù)庫，GitLab申明1月31日下午17:20（UTC時間）至晚上23:25（UTC時間）之間的數(shù)據(jù)已經(jīng)被恢復(fù)并可以在生產(chǎn)環(huán)境使用，包括項目、問題、合并請求、用戶、注釋等等。

GitLab背景

GitLab目前是硅谷一顆冉冉升起的新星，它估值3.29千萬美元并且存放著寶貴的用戶數(shù)據(jù)。

GitLab是基于 Ruby on Rails 開發(fā)的一個開源的版本管理系統(tǒng)，它實現(xiàn)了一個自托管的Git項目倉庫，支持通過Web界面進(jìn)行訪問公開的或者私人項目。

GitLab擁有與Github類似的功能，能夠瀏覽源代碼，管理缺陷和注釋?？梢怨芾韴F(tuán)隊對倉庫的訪問，非常易于瀏覽提交過的版本并提供一個文件歷史庫。團(tuán)隊成員可以利用內(nèi)置的簡單聊天程序進(jìn)行交流。此外，GitLab提供了一個代碼片段收集功能，可以輕松實現(xiàn)代碼復(fù)用，便于日后有需要的時候進(jìn)行查找?！?br /> 自2012年上線以來，GitLab已經(jīng)被超過10萬個公司或組織使用，包括IBM、Alibaba.com、Uber、Intel、VMWare等等。

事件影響

一句話概述

GitLab申明指出其一個數(shù)據(jù)庫出現(xiàn)了異常，導(dǎo)致GitLab.com丟失6個小時的數(shù)據(jù)庫數(shù)據(jù)（問題、合并請求、用戶、注釋等等），不過Git / wiki存儲庫和自托管安裝不受影響。

五點詳情

Offline前的種種掙扎

首次事故：垃圾郵件用戶的數(shù)據(jù)庫負(fù)載的峰值

2017年1月31日18:00（UTC時間）發(fā)現(xiàn)垃圾郵件發(fā)送者正在通過創(chuàng)建片段方式攻擊數(shù)據(jù)庫，目的是讓數(shù)據(jù)庫不穩(wěn)定。工作人員隨即開始尋找問題并準(zhǔn)備應(yīng)對方案。

2017年1月31日18:00-21:00（UTC時間），工作人員（team-member-1 ）正在預(yù)發(fā)布環(huán)境安裝pgpool和備份工具，為了拿到最新的生產(chǎn)環(huán)境數(shù)據(jù)他創(chuàng)建了一個LVM快照，這個快照會用于預(yù)發(fā)布環(huán)境，他希望可以重用這個快照用于引導(dǎo)其他的副本。這個操作在丟失數(shù)據(jù)前的6小時完成。

副本啟用的過程中發(fā)現(xiàn)存在問題，并且需要消耗大量時間（根據(jù)估計僅僅是初始化pg_basebackup同步過程就需要耗時20個小時以上）。LVM快照在工作人員可以修復(fù)問題之前又不能再其他副本上使用。整個修復(fù)過程都被這個問題耽擱下來。

2017年1月31日21:00（UTC時間），開始出現(xiàn)鎖定數(shù)據(jù)庫寫操作，并引起一些停機情況。進(jìn)一步進(jìn)行處理，措施包括鎖定垃圾郵件的發(fā)送IP、刪除一個用戶并啟用倉庫（造成47000個IP使用了相同的賬戶簽名，進(jìn)而導(dǎo)致數(shù)據(jù)庫高負(fù)載）、刪除垃圾郵件用戶。

　　第二個事故：復(fù)制延遲觸發(fā)警報

2017年1月31日22:00（UTC時間），數(shù)據(jù)庫備份進(jìn)展出現(xiàn)落后情況，查明造成原因是備份數(shù)據(jù)庫寫入操作時出現(xiàn)異常，導(dǎo)致沒有跟上備份節(jié)奏。

采取處理措施包括：嘗試修復(fù)db2數(shù)據(jù)庫，這時候備份落后了大概4GB。然后db2集群開始拒絕執(zhí)行備份作業(yè)，db2集群拒絕連接到db1，調(diào)整max_wal_senders為db2，重啟PostgreSQL數(shù)據(jù)庫，隨即PostgreSQL數(shù)據(jù)庫提醒存在很多打開的連接，并拒絕啟動服務(wù)。管理人員隨即調(diào)整max_connections參數(shù)從8000調(diào)整至2000，PostgreSQL隨即啟動。注意，此時db2集群依然拒絕執(zhí)行備份，處于未知原因的掛起狀態(tài)。

第三個事故：誤刪操作

2017年1月31日23:00（UTC時間），工作人員（team-member-1 ）感覺pg_basebackup拒絕執(zhí)行的原因是PostgreSQL數(shù)據(jù)文件夾已經(jīng)存在，所以決定去移除這個文件夾。執(zhí)行rm操作之后，該工作人員意識到命令正在db1.cluster.gitlab.com執(zhí)行，而不是db2.cluster.gitlab.com。

2017年1月31日23:27（UTC時間），工作人員（team-member-1 ）終止了刪除操作，300GB的數(shù)據(jù)僅剩余4.5GB。

下線，進(jìn)入緊急狀態(tài)

GitLab決定下線GitLab.com并將事故通過推特向外公布，并且通過YouTube對外進(jìn)行了修復(fù)過程的直播。

　　思考，羅列問題清單

GitLab進(jìn)一步對遇到的問題進(jìn)行梳理和逐一解釋，包括：

** LVM鏡像**默認(rèn)每24小時執(zhí)行一次。工作人員（team-member-1 ）事故發(fā)生6小時之前手動執(zhí)行了一次。

常規(guī)備份也是24小時執(zhí)行一次，但是工作人員（team-member-1 ）無法確定存放于何處。另外一名工作人員（team-member-2）認(rèn)為這意味著失效，因為產(chǎn)生的文件只有幾個字節(jié)。

一名工作人員（Team-member-3）：PostgreSQL9.2的二進(jìn)制文件開始運行，導(dǎo)致pg_dump失敗。由于數(shù)據(jù)庫版本設(shè)置為PostgreSQL9.6，最終導(dǎo)致SQL備份不啟用。

Azure上的磁盤鏡像只是針對NFS服務(wù)器，沒有針對數(shù)據(jù)庫服務(wù)器。

同步過程移除了webhooks。除非我們可以從過去24小時的常規(guī)備份中提取這些內(nèi)容，否則將丟失。

復(fù)制過程極度脆弱，很易出錯，依賴于一系列Shell腳本，而這些腳本的注釋很差。

S3 備份過程沒有正常工作。

當(dāng)備份失敗時，沒有可靠的警報/分頁，在dev host上面現(xiàn)在也看到這一點

綜上所述，5個備份/復(fù)制技術(shù)都沒有正常工作。無奈之下，我們最終啟用6小時之前的備份。

pg_basebackup需要等待主機啟動復(fù)制過程完畢，這個過程需要10分鐘。這個過程會導(dǎo)致我們認(rèn)為復(fù)制過程卡住了。使用strace命令也看不出什么問題原因。

行動， 恢復(fù)過程

GitLab的官方聲明中說明了恢復(fù)過程的執(zhí)行步驟：

** 2017年2月1日00:36**（UTC時間），備份db1.staging.gitlab.com數(shù)據(jù)。

** 2017年2月1日00:55**（UTC時間），掛載db1.staging.gitlab.com到db1.cluster.gitlab.com。從/var/opt/gitlab/postgresql/data/拷貝數(shù)據(jù)到生產(chǎn)環(huán)境/var/opt/gitlab/postgresql/data/。

2017年2月1日01:05（UTC時間），nfs-share01服務(wù)器被征用作為臨時備份服務(wù)器，放置于/var/opt/gitlab/db-meltdown。

2017年2月1日01:18（UTC時間），包括還存在的生產(chǎn)環(huán)境數(shù)據(jù)，包括pg_xlog，命名為20170131-db-meltodwn-backup.tar.gz。

下面這張圖顯示了刪除和隨后恢復(fù)事件的時間。

　　未完，GitLab下一步打算

Todo list

為不同的環(huán)境改變Linux終端的格式或者顏色，例如紅色代表生產(chǎn)環(huán)境，黃色代表測試環(huán)境。針對所有用戶在shell提示符處顯示機器的完整名字，例如db1.staging.gitlab.com，而不是僅僅是“db1”。： https://gitlab.com/gitlab-com/infrastructure/issues/1094

針對postgresql的文件夾拒絕執(zhí)行rm -rf這樣的命令？可以設(shè)置命令執(zhí)行保護(hù)或者針對數(shù)據(jù)庫文件夾有對應(yīng)的備份措施。

為備份增加提醒：檢查S3倉庫之類的體型。增加圖形化界面，顯示時間變化后的備份大小，當(dāng)下降超過10%時發(fā)出警報。：https://gitlab.com/gitlab-com/infrastructure/issues/1095

找出為什么PostgreSQL在max_connections被設(shè)置為8000之后突然出現(xiàn)問題，這個設(shè)置在2016年5月13日就已經(jīng)完成了。因為這個問題的突然出現(xiàn)導(dǎo)致了其他很多問題。https://gitlab.com/gitlab-com/infrastructure/issues/1096

通過WAL歸檔增加備份閾值，這個方法對審計失敗也許有用。https://gitlab.com/gitlab-com/infrastructure/issues/1097

針對上線產(chǎn)品創(chuàng)建常見問題查找指南手冊。

從一個數(shù)據(jù)中心移動數(shù)據(jù)到另一個數(shù)據(jù)中心可以通過AxCopy完成：微軟聲稱這個工具比rsync要快很多?？瓷先ミ@是Windows上面的問題，但是沒有任何Windows專家參與。

五天內(nèi)公開自省報告

GitLab官方申明指出丟失生產(chǎn)環(huán)境數(shù)據(jù)是不可以接受的錯誤，5天之內(nèi)GitLab將對外發(fā)布錯誤發(fā)生及保護(hù)措施失效的原因，并將發(fā)布一系列措施避免悲劇再次發(fā)生。

網(wǎng)友們的關(guān)注

GitLab致謝網(wǎng)友

GitLab申明最后感謝了共計42位網(wǎng)友的外援，他們通過Twitter和其他渠道上給出的技術(shù)建議。

網(wǎng)友留言

“keturu ta”的評價

我們在日本工作，我們能夠理解你們的痛苦和精神上的挫折。我們會一如既往地支持你們。

“Axel Dreyfus”的評價

現(xiàn)在已經(jīng)很少看到這么開放的工作態(tài)度了。祝你們好運，永遠(yuǎn)支持你們。千萬不要針對那個UNIX SA，他已經(jīng)瘦了20磅（開玩笑）。

“Neer”的評價

這樣的事故對于任何人都有可能發(fā)生，我鼓勵涉及團(tuán)隊不要有挫折感。這篇文章已經(jīng)開始在社交媒體上流傳開來了，讓我感到這是一家非常公開和透明的公司。我之前沒有聽說過這個產(chǎn)品，但是從此以后我會開始使用它。

“Codepotato”的評價

感謝這樣的全面解釋。問題發(fā)生確實讓人感覺很丟臉，但是同時也體現(xiàn)了你們對外的開放態(tài)度。當(dāng)務(wù)之急我們需要找到辦法提升恢復(fù)速度。

公開，直播修復(fù)過程

除了在網(wǎng)絡(luò)上對事故進(jìn)行文字說明，GitLab還在YouTube上直播了其數(shù)據(jù)庫修復(fù)過程。該過程視頻時長8小時，共計有32萬人次觀看。https://www.youtube.com/watch?v=nc0hPGerSd4

　　寫在后面

事故處理過程中，GitLab采用了開放的態(tài)度，事故發(fā)生后第一時間對外公布，并對處理過程進(jìn)行現(xiàn)場直播，讓全世界所有程序員都有機會一起參與恢復(fù)過程。GitLab也針對網(wǎng)友提出的關(guān)于肇事工作人員如何處理問題進(jìn)行了官方回應(yīng)，表態(tài)不會因為這次事件解雇事故相關(guān)技術(shù)人員。

正是由于這樣的開放性姿態(tài)，網(wǎng)友并沒有對事故的發(fā)生而進(jìn)行謾罵、嘲諷，而是一起通過網(wǎng)絡(luò)對GitLab進(jìn)行鼓勵，對處理事故團(tuán)隊提供積極的技術(shù)建議。這樣的處理方式可以作為IT公司生產(chǎn)環(huán)境經(jīng)典解決案例被寫入教科書。