生產環境數據丟失、數小時的宕機，這是GitLab給我們帶來的不幸而扣人心弦的故事，這個故事告訴我們小事可以變成災難，比如垃圾郵件、工程師疲勞狀態。
整個事件是從1月31日逐漸開始的，直到一條推特的發布徹底確認了GitLab.com有些不對勁了：
我們不小心刪除了生產環境數據，可能需要從備份恢復數據。谷歌Doc會有行動注解https://t.co/EVRbHzYlk8
--GitLab.com 狀態（@gitlabstatus）2017年2月1日
任務IT從業人員都不愿意聽到“刪除了生產環境數據”這樣的話，但是這種情況又容易發生，這就是為什么備份對于任何生產環境服務來說如此重要了。不幸的是，當團隊徹夜奮戰嘗試恢復服務時，壞消息接踵而來。
在一個帖子里面羅列了發生的事情，麻煩開始于惡意的垃圾郵件攻擊，即“通過反復的創建片段方式攻擊數據庫，導致數據庫不穩定”，導致了備份服務出現問題。3小時之后，數據庫什么都干不了了，導致GitLab.com站點奔潰。
一位工程師工作到深夜，他的目標是解決問題，但是最終跪倒在一個不幸的錯誤面前，他犯了一個錯誤，錯誤地刪除了主節點機器上的數據：
2017年1月31日晚上11點鐘（UTC時間），項目組成員1認為pg_basebackup不能正常工作的原因可能是由于PostgreSQL數據目錄已經存在（即便它是空的），所以他決定去移除這個目錄。很快他就意識到他的移除命令運行在db1.cluster.gitlab.com，而不是db2.cluster.gitlab.com。
2017年1月31日晚上11點27分（UTC時間），這位員工終止了移除文件夾操作，但是已經太遲了。300GB的文件僅剩下4.5GB。
當團隊嘗試去找到可用的備份文件用于恢復生產環境時，他們發現所有的可選方式都行不通。
LVM（邏輯卷管理）快照默認每24小時運行一次標準備份方式也是24小時運行一次，而且還沒有正常工作運行在Azure上的磁盤快照服務不會包含數據庫部分AWS的S3上面的備份是空的碰巧，工程師在執行刪除操作之前的6個小時生成了一個LVM快照。如果沒有這個神奇的操作，我們會發現更多的數據永遠找不回來了。
縱觀整個事件過程，GitLab團隊保持了完全的透明化，實時發布更新內容到谷歌Doc，這樣整個社區都可以緊跟事件。此外，他們也開放了現場視頻，直播工程師恢復數據的工作過程。
大約在數據庫宕機18個小時之后，GitLab.com恢復在線：
https://t.co/r11UmmDLDE應該已經對外正式恢復了。
--GitLab.com狀態（@gitlabstatus）2017年2月1日
社區存在多種評價，包括對團隊的支持和批判。一些人發帖給予慰問，并且贊揚GitLab的透明度。黑客新聞用戶js2評價這種錯誤的感受他很熟悉：“如果你干系統管理員工作時間足夠長的話，這種錯誤你也會犯的，你會在錯誤的機器上執行破壞性的命令。”另外有一些人就不那么仁慈了。
即便GitLab犯錯了，他們的痛苦經歷也是對社區內部關于測試備份方案重要性的一個提醒，Stack Overflow的工程經理David Haney說：
GitLab處理方式是正確的，可以作為企業的一個很好的案例和學習經驗，而不是讓別人感覺到神秘的宕機，以及完全沒有對外溝通的處理方式。我打賭，這周會進行很多的災備措施測試，而且這是大家以往并沒有想的。所有這一切都是因為GitLab的意外事件帶來了的連鎖反應。
也有一些人調侃說2月1日應該設立為備份檢查日。
GitLab創立于2011年，它是GitHub的開源替代版本。它是一個在GitLab.com上的托管版本，包含自服務的社區版本和企業版本。只有GitLab.com的托管服務收到本次意外事件的影響。
參考英文原文：Fatigue, Spam, and Lack of Backups Take Down GitLab.com
京公網安備 11010502049343號