如何評價 2017 年 2 月 1 日 GitLab 資料庫被誤刪？

12-31

詳情：

GitLab官網：GitLab.com Database Incident

開源中國社區：Gitlab.com 誤刪數據，備份恢復失敗已宕機 10 小時

事件回顧

GitLab官方的事故報告（postmortem）：

https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub

恢復過程直播，有一些工程師的現場答疑：

https://www.youtube.com/watch?v=nc0hPGerSd4

OSChina的中文報道：

Gitlab.com 誤刪數據，備份恢復失敗已宕機 10 小時

YCombinator的英文討論：

GitLab Database Incident Progress Report

目前來看最終會丟失一小部分線上數據（6個小時的issues、comments、merge requests等，代碼和wiki文檔不受影響），或許不算是災難級的事故，但教訓仍然是深刻的。GitLab 去年曾經提出自建私有雲服務的計劃，這次事故對於他們的聲譽也會是一個沉重打擊。

如何面對事故

這次事故雖然暴露了 GitLab 內部的一些問題，但他們的應對方式和態度還是值得讚許和學習的：

- Don"t panic，承擔責任的人才有犯錯的機會，"You"re not one of the team until you"ve brought down the server."

- 信息透明，儘可能尋求幫助

- 首先齊心合力解決問題，然後檢討流程，不歸責於個人

- 提交詳盡的事故報告（postmortem），從錯誤中積累經驗

GitLab 的教訓

以下簡單總結這次事故中 GitLab 犯的一系列錯誤。

1、在深夜做高風險操作

事件的起因是 GitLab 遭到攻擊後，一位工程師加班到深夜維護線上環境。因為遇到了種種常規腳本沒能解決的問題，不得不進行大量人工操作，於是在精力不濟後出現致命失誤，準備從 db1 同步到 db2 時錯誤的刪除了 db1 的數據。

2、部分備份腳本/設置沒有定期維護

GitLab 的 PostGreSQL 本地備份和 Amazon S3 備份都沒有正常工作。

其中 PostGreSQL 本地備份設置在資料庫版本升級後失效了，但沒有人注意到。

其它備份腳本也處於散落各處，長期無人維護的狀態。

3、部分備份方案沒有覆蓋到所有數據類型

Azure 提供了磁碟快照服務，但 GitLab 的資料庫伺服器並沒有使用，只在 NFS 伺服器上使用了。

4、部分備份方案沒有保留完整數據

GitLab 在 Staging 環境上有一份6小時以前的數據，但其中沒有保留 Webhook（STG 環境不應產生真實的 Webhook 行為）。實際上 Staging 環境本就不應該承擔備份的責任，但這是 GitLab 眼下能找到的最完整歷史數據了。後來他們在其它的備份中補回了 Webhook 的數據。

5、備份流程沒有 Monitoring 和 Alert

因為沒有 Monitoring 和 Alert，以上這些安全隱患長期沒有人發現和注意。

6、備份頻率不足

GitLab 的各種備份方案都是每天運行一次，從這次事件來看，對於他們來說可能還是不夠。

7、備份不能正確恢復/需要太長時間

GitLab 的 LVM 快照因為某些原因，沒能正確恢復成功。

從 Staging 環境恢復到 Production 環境的過程中，因為跨數據中心的網速以及 Staging 環境的磁碟速度等原因，備份數據在10個小時後還只傳了一半，大大拖延了恢復進程。

8、沒有正確的設置維護 PostGreSQL

事故發生後一些第三方評論指出（參見官方事故報告附錄），GitLab 沒有正確的配置和使用 PostGreSQL，也是這次事故升級的部分原因。

如何做得更好

GitLab 在事故報告之後附上了內部總結的若干 TODO 事項，對於其它流程不夠完備的中小型團隊來說，可以考慮同樣做一遍自查。以下是我個人的一些建議：

1、審核所有數據的備份方案，備份頻率如何，備份數據放在哪裡，保留多久。

2、對於雲服務自帶的鏡像備份等服務，確認是否正確的打開和設置

3、對於自行搭建的備份方案，確認

- 是否覆蓋了所有重要數據

- 是否還在正常工作，考慮設置相關 Monitoring 和 Alert

- 相關的 script 和 configuration 進入源碼管理

- 最終備份文件考慮存儲不止一份（本地、不同的雲服務商），使用雲服務時最好使用單獨的文件存儲服務，而非直接放置在VM鏡像內

4、定期做災備演習，檢驗是否可以正確從備份中恢復，以及此過程需要多少時間和資源。

5、將災備流程文檔化，日常伺服器維護流程中的注意事項也寫成 checklist（或腳本化）。

6、降低 Production 環境的誤操作可能

- 提倡 IAC （Infrastructure as Code）的最佳實踐

- 深夜等工作時間外伺服器出現狀況時，優先考慮基於 CI 的 rollback 等自動化操作，高風險的人工操作盡量放在工作時間，有其它同事可以監督或者支援

- 考慮在 Production 環境的 CLI 界面中增加更多防呆提示（比如設置不同顏色，對於 rm 命令使用 alias 增加保護性檢查等）

7、今天資料庫運維仍然是一項比想像中更困難的任務，即使對於 GitLab 這樣的成熟團隊也是如此。對於沒有專職 DBA 的創業公司來說，直接使用雲服務商提供的資料庫服務可能更為安全高效。

傳說中有6種備份的 gitlab 怎麼就爆炸了呢? 看他們的報告吧

https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub

1.LVM snapshots are by default only taken once every 24 hours. YP happened to run one manually about 6 hours prior to the outage

這是唯一能用的備份,每24小時執行一次,上一次是6小時前.

2.Regular backups seem to also only be taken once per 24 hours, though YP has not yet been able to figure out where they are stored. According to JN these don』t appear to be working, producing files only a few bytes in size.

這個也是24小時一次的備份,不過首先找不到它在哪.等找到了發現備份是空的

3.Disk snapshots in Azure are enabled for the NFS server, but not for the DB servers.

Azure 的備份沒給資料庫伺服器用

4.The synchronisation process removes webhooks once it has synchronised data to staging.

同步進程在一次同步完成後就把 webhooks 刪了

5.The replication procedure is super fragile, prone to error, relies on a handful of random shell scripts, and is badly documented

這個備份是依賴一些混亂的腳本,很容易出錯,而且沒文檔2333

6.Our backups to S3 apparently don』t work either: the bucket is empty

S3 備份是空的2333

看得我都要笑死了,備份從來沒人管吧233.然後直播複製備份,速度只有6MiB/s.好在 gitlab 只有 310 GiB 的數據.

總之現在直播給出的 ETA 還有至少 5 小時吧.

歡迎圍觀史上第一次 YouTube 直播歡樂地恢複數據 https://www.youtube.com/watch?v=nc0hPGerSd4

剛看到輪子哥的微博……

下面有個評論：

這一事件說明兩個問題：

天災易躲，人禍難防。所有的備份策略都應該以防止人禍為第一優先順序。
讓程序員去當DBA有多麼的不靠譜。一天備份一次是什麼鬼。

想想我司的SQL Azure，明明自身有4個replica，數據文件存放的Azure Storage還自帶3個replica，根本不會丟數據，為什麼還要任勞任怨自動地每周做一次全量備份、每天做一次差量備份，每5分鐘做一次日誌備份？就是因為不停地有客戶來開Incident，「啊，我不小心drop table了」，「啊，我不小心delete *了」，「啊，我的update忘記加where了」。甚至於你不小心drop database ，在一定期限內都可以恢復。這些都是這麼多年SQL Server的運營經驗帶來的血的教訓啊。聽說gitlab這樣的新興公司還曾經想自己搞私有雲？簡直呵呵。

昨天在微博上看到的，把Adobe所有軟體都裝上，刪庫時先刪A打頭的文件，光Adobe就得刪個十分鐘吧，那時候早就反應過來了，所以說Adobe關鍵時刻能救命。

俗話說，出來混早晚要還的。俗話又說，常在河邊走，早晚要濕鞋。俗話還說，好了傷疤忘了疼。

好多人喜歡追捧小公司那套：全棧、devops[1]啥的。七八年前，有個人來我們組，過了一陣子他覺得不爽，他說：他們以前在某某某地方都可以自己直接進production環境去改東西的，為什麼在微軟這裡管的那麼死？我們那時候資料庫操作只有dba有許可權，我們那些做開發的只有讀許可權。要在db裡面改東西，要寫好步驟或腳本、給dba開一個ticket去做的。我們當時甚至連讀許可權都沒有的，因為要防止有人寫很愚蠢的query把表給鎖了。我們當時都是去讀replica的。小公司沒這些限制這些分工，的確很爽啊，但記住，出來混遲早是要還的。當然，一百個這樣的公司里也許只有兩三個會遇到刪庫級別的大事故，剩下九十幾個幾年下來都安然無恙。這叫survivor"s bias。大公司為什麼成本高、動作慢？就因為有這些東西拖累。你想，如果gmail或者onedrive一下丟了好多郵件而且恢復不出來了，會怎麼樣？整個公司也許就從此聲譽掃地了。我在Azure，Azure裡面在安全和災備上花的力氣海了去了。

有人說到要做備份，要有災備方案，要演習。但這次gitlab發現備份也是壞的。怎麼判斷備份是不是好的，這其實是一個哲學上（或者方法論上）的困境：你刻了一張盤，不可以播放，但是要確保有朝一日需要播放的時候可以放。這有點像家裡的滅火器：你要確保滅火器可以用，但是又不能用，因為一隻滅火器一用，就沒用了。有人說，你可以找一個測試環境，把備份恢復出來看看。我跟他們說：你可以這樣做，但是你沒法確保備份裡面的每一條數據都是對的。你就算能驗證備份裡面99%的數據是好的，但是萬一剩下1%裡面有data corruption，也許到時候就是致命的：可能你的code沒法handle那種corruption，導致你的code就崩了。搞到最後，能用的也就是做做diff、弄個hash啥的。但是還是沒有根本性的解決這個方法論上的困境。

大公司裡面那些做備份、disaster recovery的活其實不怎麼受待見，因為做的東西說不定好多好多年才用到一次。等用到了，說不定做的人都已經走掉了。而且，到底好用不好用也不知道，再怎麼演習也還是不能百分之百的確信。備份（跟容災不一樣）這事兒跟最近的Survivalist那檔子事有點像，都是很奢侈的一件事情，只有財大氣粗的人（公司）才搞得起。

[1] 別誤會我的意思，現在微軟裡面也比以前敏捷很多，dev會幹很多devops的事情，很多以前一季度上線一次的組現在都改進到每周上線甚至每天上線了。

感覺我看旁邊聊天是要笑屎了

不過還是希望gitlab能夠快點恢復吧

Make Gitlab great again|(￣3￣)|

前幾個月俺干過一次類似的事，晚上十點多在sql developer中手工改一行核心表的數據

update table T set status = 0 where conditions

本來按照俺的condition只會改一行的，悲催的是俺執行語句的時候手一抖，where 沒選上，然後整個數據表狀態清零......

在sql developer中auto commit是off的，可俺cancel掉執行語句之後新開一個session, select一把，居然所有數據都更新了......

這張表直接關係著系統里內部所有ETL job的調度，然後成千上萬不該被調度的job被調度, 工作表的數據被污染, 無數美國和印度的SDE, DBA被page起來停job, 恢複數據

完事了寫COE(Correction of Errors), 重點有以下幾條：

盡量利用腳本，工具等來避免人工錯誤。
盡量不要多個team更改一個重要數據集，可以不同team更新不同的子集，再merge回mainline, 即使有誤操作影響也有限。
不要在半夜改數據!!!

謝邀。

coding 採取了如下策略保障數據安全：

1. 數據至少 3 個節點實時同步

2. 額外節點做延時 1 小時的半實時同步

3. 每天全量備份

4. 全量備份保存在兩個相隔 30 公里以上的機房

5. 數據相關服務動態伸縮實例時，基礎數據從全量備份副本恢復，保證備份副本可被正常使用

以保證不管是天災還是人禍都可恢復。

運維小夥伴說他們的目標是「打瞌睡操作也不會丟數據！」同時，運維在公司有特權不喝酒。

以及希望 gitlab 數據早日恢復。

應該立法規定在使用rm -rf的時候，一定要連接到另一塊硬碟上，做std::swap（逃

送大家一段定時備份資料庫的腳本：

#!/bin/sh DATABASE=/backup/mysql/ #文件備份路徑 DATE=`date "+%Y%m%d-%H%M"` #日期格式(作為文件名) DUMPFILE=$DATABASE-$DATE.sql #備份文件名 DATE_N=`date -d "-30 day" +%Y%m%d` #刪除N天前的備份文件（額，這句千萬別寫錯了） rm -rf $DATABASE-$DATE_N* #備份數據 mysqldump &<你的資料庫名&> -u&<你的資料庫用戶名&> -p&<你的資料庫密碼&> &>$DUMPFILE #壓縮文件 tar zcvf $DATABASE&<你的資料庫名&>-$DATE.tar.gz $DUMPFILE #刪除sql文件sql（額，這句千萬別寫錯了） rm -rf $DUMPFILE

拿到電腦我一般都會這樣alias rm="i am ready to play with the fire balabala"哎，說多了都是淚

哼(? ˇ?ˇ ?) 人家超想下班的！(￣^￣)ゞ拿小拳拳捶鍵盤！(＞人＜;)rm -rf (*｀へ′*)大壞蛋，刪死你！

看以後誰敢笑網易的備份

其實可能是網管突發奇想想玩遊戲了，發現機器上有Intel核顯和NV獨顯，打算裝個Bumblebee搞自動切換。[大誤]

有多少人還記得，Bumblebee的安裝腳本里，有一行

rm -rf /usr /lib/nvidia-current/xorg/xorg

作者本意是刪掉/usr/lib/nvidia-current/xorg/xorg，但因為/usr和/lib之間多大了一個空格。。。install script does rm -rf /usr for ubuntu · Issue #123 · MrMEEE/bumblebee-Old-and-abbandoned

「不是女裝差評」

rm -rf 不亞於翻牆進入動物園的老虎區

資料庫進階：從刪庫到跑路

世界各地的程序員一起歡樂

大多數公司的運維備份與回復從來就沒有過災難預演，因為只要前端的程序夠成熟夠穩定，幾年也不會遇到一次事故，但是一旦遇上了，基本就sb了。。。

所以網路上的照片有的在機房裡燒香拜佛開光，很多人就當笑話看，我是笑不出來，因為的確是血淋淋的事實。。。