一名工程師刪除了 GitLab 的生產數據庫。300 GB。
2017 年 1 月 31 日，世界標準時間 23:27：一名 GitLab 工程師在漫長夜晚的尾聲，與一個損壞的副本奮鬥，結果移除了 db1 上的 PostgreSQL 數據目錄，而不是 db2。
2017 年 1 月 31 日，世界標準時間 23:27：一名 GitLab 工程師在漫長夜晚的尾聲，與一個損壞的副本奮鬥，結果移除了 db1 上的 PostgreSQL 數據目錄，而不是 db2。db1 是主要數據庫。GitLab.com 大約 300 GB 的數據庫在一兩秒鐘內消失了，而且五個備份和複製機制中，沒有一個在正常運作。事後分析：從垃圾郵件激增到錯誤的主機名，為什麼 pg_basebackup 看起來卡住了，為什麼 pg_dump 一直在靜默失敗（9.2 二進制文件在 9.6 數據庫上運行，失敗電子郵件被 DMARC 退回），YouTube 現場直播的從 6 小時前的測試快照恢復 18 小時的過程，以及誰真正該受責備。對響應的判決：SHIP IT。
本影片涵蓋的內容
- 2017 年 1 月 31 日：在主要數據目錄上運行 rm -Rvf；約 300 GB 被移除，剩下 4.5 GB
- 五個備份全部失敗：S3 存儲桶為空（pg_dump 版本不匹配），數據庫上沒有 Azure 快照，副本被清除，每日 LVM 複製沒有網絡鉤子
- 2 月 1 日，世界標準時間 18:00：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。 存儲桶是空的。 cron 作業在沒有數據庫的應用服務器上運行，因此該程序包選擇了 用於 9.6 數據庫的 PostgreSQL 9.2 二進制文件，失敗，並發送了 失敗郵件，但因缺少 DMARC 而被退回。 二：Azure 磁盤快照，已為文件服務器啟用， 但未為數據庫啟用。
1:32 三：副本，一小時前故意清除。 四：每日快照，24 小時前，所有網絡鉤子都被 測試環境同步移除。五：下午 5 點 20 分的手動快照，用於不相關的測試。 這一個成功了。 恢復意味著以每秒 60 兆比特的速度，通過 Azure 的廉價 存儲將測試磁盤複製回生產環境：十八小時。 GitLab.com 於 2 月 1 日下午 6 點恢復， UTC，數據舊了六小時。
1:58 git blame：兩個主機名只差一個字符，以及五個從未有人 恢復過的備份系統。 不是工程師的錯。 事後分析報告由首席執行官簽署，保持他的匿名， 將生產提示標為紅色，並為數據持久性指定了負責人， 因為在此之前它沒有負責人。 影響範圍：停機十八小時，六小時數據丟失， 大約五千個項目，五千條評論，
2:18 七百個新用戶，以及五千人觀看進度條。 Hacker News 給實時文檔 1,162 分，並引用了一句 話給他們：五個備份中，沒有一個可用。 判決，事後分析：SHIP IT，關於響應。 他們公開處理事件，歸咎於流程，並發布了帶有問題編號的修復列表。 星期一行動：恢復備份。 如果你從未恢復過它，那麼你並沒有備份。 在評論中，或發送到 thedaily.diff.dev，
2:42 把你仍然不允許談論的事件發給我。 這就是今天的 The Daily Diff。 我是 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
