一名工程師刪除了GitLab的生產資料庫。300 GB。
UTC時間2017年1月31日23:27：一位GitLab工程師在漫長夜晚的盡頭，努力修復一個損壞的副本，他不小心在db1（主資料庫）上而不是db2上移除了PostgreSQL資料目錄。
UTC時間2017年1月31日23:27：一位GitLab工程師在漫長夜晚的盡頭，努力修復一個損壞的副本，他不小心在db1（主資料庫）上而不是db2上移除了PostgreSQL資料目錄。db1是主資料庫。GitLab.com約300 GB的資料庫在短短一兩秒內消失，而五種備份和複製機制，沒有一個正常運作。事後檢討：從垃圾郵件激增到錯誤的主機名，為什麼pg_basebackup看起來卡住了，為什麼pg_dump一直靜默失敗（9.2的二進制檔案用在9.6的資料庫，DMARC退回了失敗通知郵件），從一個6小時前的測試快照進行的18小時還原（在YouTube上直播），以及誰該真正負責。對應變的評語：SHIP IT。
本影片重點
- 2017年1月31日：在主資料庫的資料目錄上執行 rm -Rvf；約300 GB被移除，剩餘4.5 GB。
- 5個備份全部失敗：S3儲存桶是空的（pg_dump版本不匹配），資料庫沒有Azure快照，副本被清除，每日LVM複製沒有webhooks。
- 2月1日18:00 UTC：GitLab.com從一個6小時前的手動快照恢復，提供即時文件、即時串流，並附有修復清單的無責事後檢討。
翻譯文字稿
譯自英文原版旁白。可用的音訊和字幕由 YouTube 控制。
0:00 一名GitLab工程師在錯誤的資料庫伺服器上執行了rm -rf， 短短一兩秒內，三百GB的GitLab.com資料消失了， 這大約是讀取一個主機名稱所需的時間。 2017年1月31日，晚上11點27分， UTC。GitLab發推特表示它不小心刪除了生產資料， 向網路公開事件記錄，並在YouTube上直播恢復過程， 成為該平台第二受歡迎的直播。 隔天，書面記錄顯示：五種備份技術中，
0:25 沒有一種能可靠地運作。 它是如何發生的，為什麼會發生，以及誰該真正負責。 這是The Daily Diff，事後檢討。 下午5點20分：一名工程師拍攝了生產快照， 用於測試預備環境中的負載平衡器。 晚上7點：垃圾郵件攻擊資料庫，加上一項任務硬性刪除了一名GitLab員工， 這名員工被一名巨魔舉報濫用。 晚上11點：副本嚴重落後，以至於主資料庫已經丟棄了
0:48 它所需的日誌；唯一的解決辦法是清除副本並重新複製主資料庫。 pg_basebackup在沒有任何輸出的情況下掛起了。 它實際上是在靜默地等待主資料庫；沒有人知道這點， 而且操作手冊中也沒有說明。 這位工程師本打算在11點下班，他認為空的資料目錄 是問題所在，於是將其移除。 在db1上。也就是主資料庫。 他過了一兩秒才注意到；大約三百GB的資料中，
1:11 只剩下4.5 GB。備份。 一：每天pg_dump到S3。 儲存桶是空的。 排程任務在一個沒有資料庫的應用程式伺服器上執行，所以程式包選擇了 用於9.6資料庫的PostgreSQL 9.2二進制檔案，導致失敗，並發送了 失敗通知郵件，但因缺少DMARC而被退回。 二：Azure磁碟快照，為檔案伺服器啟用， 但未為資料庫啟用。
1:32 三：副本，一小時前剛故意清除。 四：每日快照，24小時前的，每個webhook都被 預備環境同步移除。五：來自5:20的手動快照，用於不相關的測試。 這個成功了。 還原意味著以每秒六十兆位元的速度透過Azure的廉價儲存，將預備磁碟複製回生產環境：十八小時。 還原意味著以每秒六十兆位元的速度透過Azure的廉價儲存，將預備磁碟複製回生產環境：十八小時。 GitLab.com於2月1日下午六點， UTC時間恢復，資料已是六小時前的。
1:58 git blame：兩個只差一個字元的主機名稱，以及五個從未有人還原過的備份系統。 從未有人還原過的備份系統。 不是工程師的錯。 由執行長簽署的事後檢討，保護了他的匿名性， 將生產提示標為紅色，並為資料持久性指定了負責人， 因為直到現在它都沒有負責人。 影響範圍：十八小時停機，六小時資料遺失， 大約五千個專案，五千條評論，
2:18 七百個新使用者，以及五千人正在觀看進度條。 Hacker News給了這份即時文件1,162分，並引用了一行 文字反駁他們：五個備份中，沒有一個。 事後檢討的裁決：應變：SHIP IT。 他們公開處理此事件，歸咎於流程，並發布了附帶問題編號的修復清單。 並發布了附帶問題編號的修復清單。 週一行動：還原備份。 如果您從未還原過它，那您就沒有備份。
2:42 請在評論中，或發送至thedailydiff.dev， 告訴我您仍然不被允許談論的事件。 這就是今天的差異。 我是Axrisi的Niko。 負責任地合併。
來源
- GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)about.gitlab.com
- GitLab, "GitLab.com database incident" (Feb 1, 2017)about.gitlab.com
- @gitlabstatus, "We accidentally deleted production data…"twitter.com
- @gitlabstatus, emergency maintenance noticetwitter.com
- Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)news.ycombinator.com
- Hacker News, the postmortem thread (377 points)news.ycombinator.com
