GitLab事故之技術(shù)詳敘:搶救后恢復(fù)在線,已確定下一步計劃

責(zé)任編輯:editor004

作者: 周明耀

2017-02-06 11:18:26

摘自:INFOQ

本文對GitLab事件進(jìn)行了全盤回顧,繼續(xù)追蹤GitLab在2月1日發(fā)布的申明,追溯各種問題根本原因??赡軄G失了707個用戶

本文對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存儲庫和自托管安裝不受影響。

五點詳情

大約6個小時的數(shù)據(jù)丟失大約丟失5037個項目(其中4613個常規(guī)項目,74個fork, 350個import)。由于Git的repository沒有任何損失,所以GitLab可以重建數(shù)據(jù)事故之前已經(jīng)存在的用戶/組的全部項目,但是并不能修復(fù)事故中的任何問題。丟失了大約4979(即5000)左右的注釋??赡軄G失了707個用戶,很難準(zhǔn)確進(jìn)行評估(部分源自Kibana記錄)受影響的時間點:1月31日17:20之后創(chuàng)建的數(shù)據(jù)

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)典解決案例被寫入教科書。

鏈接已復(fù)制,快去分享吧

企業(yè)網(wǎng)版權(quán)所有?2010-2024 京ICP備09108050號-6京公網(wǎng)安備 11010502049343號