那些年刪過的庫，跑過的路，你從中找到解決方法了嗎？

• 2019 年 10 月 10 日
• 筆記

導讀：本文我們盤點了往年發生的一些刪庫事件，我們該如何做到更好地預防和處理刪庫實踐呢？

本月，多名網友回饋購物推薦網站什麼值得買及APP無法訪問。晚上10點多官方發表了公告，稱伺服器遭遇大面積攻擊，網站及APP出現異常，目前正在逐步恢復中。針對之前傳聞的數據丟失及泄露，什麼值得買官方表示否認。但是此次疑似刪庫事件在網上也是引發了很多熱議，下面我們來盤點下往年發生的一些刪庫事件，思考我們該如何做到更好地預防和處理刪庫事件。

順豐事件 2018年9月19 日晚，據微博網友大佬坊間八卦爆料，順豐的一個高級工程手誤把線上系統一個庫刪除了，導致某項服務無法使用並持續 590 分鐘。然後跑路了！

事件詳情：

工程師鄧某在接到該變更需求後，按照操作流程要求，登陸生產資料庫跳轉機，通過navicat-mysql客戶端管理工具，連入SHIVA-OMCS的RUSS庫進行操作。

但在操作過程中，該運維發現選錯了RUSS 資料庫，打算刪除執行的sql。

在選定刪除時，因其操作不嚴謹，游標回跳到RUSS庫的實例上，在未看清所選內容的情況下，便通過delete執行刪除，同時，他忽略了彈窗提示，直接回車，導致RUSS庫被刪除。

因工作運維人員工作不嚴謹的操作，導致OMCS運營監控系統發生故障，該系統上臨時車線上發車功能無法使用並持續約590分鐘。同比9月5日的929條臨時車需求，此次故障對業務產生了嚴重的負面影響。

Gitlab刪庫事件

2017年1月底，Gitlab工作人員由於夜間開車時間很長，錯誤的將 db1.cluster.gilab.com （生產庫）的資料庫刪除，而不是db2的。丟失了 6 小時的資料庫數據。

事件詳情：

Gitlab的一位系統管理員在給線上資料庫做負載均衡工作時，遭受了DDoS攻擊。在阻止了攻擊之後，運維人員發現了資料庫不同步的問題，便開始修復，在修復過程中，錯誤地在生產環境上執行了資料庫目錄刪除命令，導致300GB數據被刪除，Gitlab被迫下線。在恢復的過程中，他們發現只有db1.staging的資料庫可以用於恢復，而其它的5種備份機制都不可用。db1.staging 是6小時前的數據，而且傳輸速率有限，導致恢復進程緩慢，Gitlab 最終丟掉了差不多6個小時的數據。

起因是Gitlab檢測到垃圾郵件發送者通過創建片段來攻擊資料庫，使其不穩定，於是運維block攻擊者的IP,並移除用戶發送垃圾郵件。之後運維A發現db2.staging複製滯後生產庫4GB的數據（據後期2nd Quadrant的CTO – Simon Riggs 建議，PostgreSQL有4GB的同步滯後是正常的）,運維A開始嘗試修復db2,但複製失敗，運維A在嘗試了多種方案之後依然如此。

運維A決定刪除該db2資料庫目錄，令其重新複製。由於夜間開車時間很長，運維A錯誤的將 db1.cluster.gitlab.com （生產庫）的資料庫刪除，而不是db2的。大約 300 GB 左右的數據只剩下約4.5 GB。

隨後雖然有號稱有五重備份機制（常規備份（24小時做一次）、自動同步、LVM快照（24小時做一次）、Azure備份（只對 NFS 啟用，對資料庫無效）、S3備份),沒有一個可靠地運行或設置，最終只能基於LVM的備份（最近6小時以前），還原了6 小時前的備份。恢復期間Gitlab直播了這次恢復過程。

2017/01/31 18:00開始數據異常，截止2017/02/02 02:14,GitLab.com恢復正常。期間丟失了 6 小時的資料庫數據（問題，合併請求，用戶，評論，片段等）。Git / wiki 存儲庫和自託管安裝不受影響。根據GitLab從日誌里得出的結論，有707位用戶丟失數據，5,037項目丟失，受事故影響的用戶基數不到1%。

verelox.com刪庫事件

2017年6月，一家荷蘭海牙的雲主機商 verelox.com，一名前任管理員刪光了該公司所有客戶的數據，並且擦除了大多數伺服器上面的內容。最終導致 Verelox 暫時將網路下線。

網路剪報服務商 – Instapaper事件

2017年2月9日至2月10日下午7時30分，Instapaper服務突然中斷，事故起因是2014年4月之前創建的RDS實例的2TB文件大小限制，造成了不小的損失。

事件詳情：

Instapaper 最初的全文檢索使用一台 Sphinx 伺服器直接和 MySQL 聯合提供搜索，這個搜索使用 AWS EC2 大約70GB 記憶體，4TB 存儲的資源：

Instapaper 的索引數據量（資料庫的數據量未知），在2016年5月時數據量2.2TB，每月增長約110GB，後來實在慢的不行，最後選擇了 AWS 的 elasticsearch cluster來承載這項服務。而最終，還是敗在了存儲，數據寫入失敗直接導致資料庫宕機。

攜程刪庫事件

2015年5月28日上午11時，攜程網突然陷入癱瘓。攜程回應稱攜程部分伺服器遭不明攻擊，在此次故障中全部遭受物理刪除，且備份數據也無法使用。但在5月29日，攜程發布官方情況說明稱，此次事件是由於員工錯誤操作，刪除了生產伺服器上的執行程式碼導致。

任何程式都會有Bug，任何系統都會有異常，歷史發生的刪庫事件，是提醒我們需要時刻注意風險，積極總結和反思，預防那些可以避免的異常，妥善處理已經發生的異常，讓產品更好地服務客戶。

說道刪庫不得不提rm，rm 是 linux 系統下刪除文件的命令，-r 代表刪除這個下面的一切，一切的一切那種的一切。f 表示不需要用戶確認，直接執行。通常這個命令都是指定文件夾用的，比如：

rm -rf /home/test/

就是刪除 /home/test/ 這個文件夾下面的所有東西。但是如果後面的文件夾路徑沒有加對，rm -rf / 在伺服器上也就意味著刪庫了！

所以！嚴重警告：rm是非常危險的！

面對上面的這些刪庫事件，我們該如何進行反思？做到更好地預防和處理刪庫事件呢？

首先，要有完善、有效的備份和容災機制。誠然很多企業都有了一整套的備份、容災機制，但是這套備份機制能否真實奏效是需要檢驗的。我接觸過某大型企業，投入巨資興建的災備中心，從未正式切換過，這樣的災備在故障來臨時也很難有人拍板去進行切換，所以備份的有效、容災手段的有效是必須確保的。注意，備份的恢復速度必須足夠的考慮到，磁帶的低效備份關鍵時刻會害死人。

其次，要有完善的故障處理策略和流程。對於不同系統，在關鍵時刻要優先確保什麼，是要訂立規則的，有了規則才能照章辦事，不走錯方向，不無辜背鍋。幾年前某中國金融系統出現數據壞塊，同樣選擇了帶病修復，最終沒能解決問題，同樣選擇了回檔承擔了數據損失。

再次，要有端到端融會貫通的應急機制。也就是說不僅僅技術上具備容災應急的響應方案，從業務端同樣要有對應的預案，以便應急時同步處理，區別對待。很多時候，有了業務上的應急、降級服務方案，技術層面的處理就能夠從容許多。

最後，要有能夠快速協同的團隊資源。很多時候嚴重的故障，需要較大規模的專業團隊協作處理，原廠商和第三方在其中都承載著重要的角色，所以關鍵時刻，要能夠獲得內外部快速及時的支援，尤其是在綿延數天的高強度工作中。

還有無論是運維、DBA 還是程式設計師們都應該在日常 Coding 時嚴加註意操作規範，銘記「一失手成千古恨」的後果。在審查時也要做好自動容災、數據同步的步驟，最重要的是不要忘記備份！！！