那些年，我們刪過的庫與跑過的路。

圖注：圖片源自網路

在 IT 從業者中，有著一群比程式設計師還要低調且掌管著大資料時代企業生死命門的人，他們就是傳說中的 DBA。論起 DBA 的工作職能，很多人表示這可比程式設計師日常複雜得多，不僅上要和應用程式打交道，下還要深入作業系統和硬體之中。所以當繼而談起成為一名優秀的 DBA 是種怎樣的體驗時？不少過來人調侃道，你能明白那種刪得了庫跑不了路的酸爽感嗎？

近來，一名來自順豐的技術工程師親身經歷告訴了我們，“對，沒錯，就是這樣的一種感覺。”。

日前，據微博知名網際網路資訊博主@大佬坊間八卦爆料，順豐科技資料中心的一位鄧某因誤刪生產資料庫，導致某項服務無法使用並持續 590 分鐘。

圖注：來自@大佬坊間八卦微博

後來有網友爆料，這位鄧某是順豐科技 IT 資料中心應用交付技術部網際網路產品運維組的 IT 運維開發高階工程師。

而事件的起因，據網上流傳的郵件截圖顯示：

在接收到變更需求後，鄧某在操作過程中，錯選了 RUSS 資料庫，打算刪除執行的 SQL。在選定刪除時，因其操作不嚴謹，游標回跳到 RUSS 庫的例項，在未看清所選內容的情況下，便通過 delete 執行刪除，同時鄧某忽略了彈窗提醒，直接回車，導致 RUSS 生產資料庫被刪掉。

因運維工作人員不嚴謹的操作，導致 OMCS 運營監控管控系統發生故障，該系統上臨時車險發車功能無法使用並持續了約 590 分鐘。

目前順豐根據公司相關規定，已將鄧某辭退，且在順豐科技全網通報批評。事件一出，立即引發圈中程式設計師們的熱議。很多人無奈的表示，庫都刪了，不跑路幹什麼？記得看好地圖，搭載飛機跑路，否則或因堵車，短短几分鐘之內你就會被抓回了，譬如下面這位：

事實上，無獨有偶，在國內外，刪庫事件早已不是第一次發生，相比之下，此次順豐刪庫帶來的後果還不算最為嚴重，接下來，我們將共同回顧那些年，刪的那些庫帶來了怎樣的後果？我們又該如何避免刪庫跑路事件的頻發？

1.那些年，刪過的庫

大廠說：

2017 年 2 月，GitLab 的一位系統管理員在給線上資料庫做負載均衡工作時，遭受了 DDoS 攻擊。在阻止了攻擊之後，運維人員發現了資料庫不同步的問題，便開始修復，在修復過程中，錯誤地在生產環境上執行了資料庫目錄刪除命令：

2017 年 6 月，一家荷蘭海牙的雲主機商 verelox.com，一名前任管理員刪光了該公司所有客戶的資料，並且擦除了大多數伺服器上面的內容。

最終導致 Verelox 暫時將網路下線。在釋出的官方公告中，Verelox 表示一直努力恢復資料，但遺憾的是，目前已丟失的所有資料可能恢復不了了。

2017 年 9 月，某 IT 大廠技術工程師幫助廣西移動進行擴容割接（即增加系統容量）時，不小心將 HSS 裝置裡面的使用者資料格式化刪除，導致廣西移動近 80 萬用戶資料丟失。

網友說：

@張家考拉：

公司新來一位應屆畢業生，工作能力非常弱，什麼都不會，怎麼辦呢？就先讓她幫忙盤點機房裝置資產。

就因為有個資產標籤看不清楚，直接把刀鋒伺服器拔出來了，旁邊帶她的人看到，瞬間就石化了。業務系統中斷十幾分鍾，領導也沒說什麼，就是不讓她繼續盤點了，而她，根本不知道自己闖禍了。

@土豆爸爸：

多年前（2001 年），那還是 Unix 字元介面，半夜我例行維護，刪過一個包含二十萬本圖書的庫。十分鐘自己確認出錯後，開始冒汗，胃部像是被猛打了一拳得開始痙攣，疼的我都坐不住。

好一會我去過道抽了兩根菸，才回憶起前天做了全系統備份，丟的資料不多！

那感覺，一輩子難忘。

@ai0by：

之前自己做的一個站，伺服器是在 Vultr 上面，使用者有 1000 多，訪問量不少。某天在 Vultr 上面另開了一臺測試機器，測試完了準備刪除時刪錯了機器，把放網站的那臺刪掉了……（有必要吐槽一下 Vultr 的伺服器介面，我以為新開的機器一定是最下面的那個，然後沒看直接就刪掉了，沒想到最下面的那個不是最新開的那臺！）

當時只能說非常慌張，好像在夢裡一樣，滿頭大汗，只能眼睜睜看著一條提示刪除成功的訊息，隨即立刻提交了一條 ticket，Vultr 告訴我已經刪除掉的機器是不能恢復的，瞬間感覺長時間的經營全部白費了，很難想象經營了那麼久一個失誤操作全完蛋了。

後來發現那臺機器之前有過備份，另開了一臺機器把映象恢復到新機器上面，時間是一週前，好歹算是救回來了，丟失的資料後來自己手工補上了。

刪掉的一瞬間，好多使用者來找我，我只能淡定的回覆說是在維護，實際慌的要死，在問題解決差不多後，自己後背都溼透了，再也不想有第二次了，切記做好備份，切記切記！

2.那些年，跑路前，我們還可以做些什麼？

和上文刪庫事件相比，不少網友對順豐的處理結果及制度產生質疑，紛紛表示：開除了涉事工程師，順豐自身就完全沒責任？花了這麼大的教訓培養了一位運維就這麼拱手讓人了？

剖開表面，我們不由深思，順豐以辭退為名，真的能撇開其在流程問題所因擔起的責任？此次出事，好在影響尚未造成無法挽回的後果，順豐應做的不是第一時間去辭退涉事員工，而是通過該教訓來看清內部的問題：

• 刪庫事件發生一方面源於工程師本人的失誤，另一方面是否體現了日常管理流程的鬆懈，及操作的不規範？
• 安全責任不分明，除了涉事員工，其直接上司不應擔責？
• 許可權控制混亂，僅一名運維工程師可以直接操作資料庫？
• 災備恢復能力弱，事件的發生到恢復，偌大的順豐企業花費了 590 分鐘？

所以，從以上的種種問題來看，我們該如何再次避免刪庫“跑路”等事件的再次發生？

對此，在企業首先做好許可權管理以及多重稽核機制的同時，CSDN 也曾教諸多程式設計師們如何在 Linux 下謹慎使用 rm，避免從刪庫到跑路的悲劇發生：

一個方案就是重定向 rm 命令以嫁接為 mv 命令，相當於給 Linux 系統定製了一個回收站。實現方式如下：

最後將上述指令碼寫入 /etc/bashrc，並立即執行命令 source /etc/bashrc 即刻生效。

以上的指令碼定義了幾個命令：

• rl：查看回收站下的檔案；
• unrm 檔名或目錄：恢復到當前的路徑下；
• rmtrash：清空回收站，不過會友好提示。

執行 rm 不會真正刪除，而是使用 mv 移動到我們指定的回收站。實在真的想刪除可以 /bin/rm 來進行刪除。另外，需要注意的時，之前 rm 指令的一些引數可能不再使用，因為 rm 現在其實是 mv 了。

還有無論是運維、DBA 還是程式設計師們都應該在日常 Coding 時嚴加註意操作規範，銘記“一失手成千古恨”的後果。在審查時也要做好自動容災、資料同步的步驟，最後，重要的事情說三遍，不要忘記：

備份！ 備份！ 備份！

“徵稿啦”

CSDN 公眾號秉持著「與千萬技術人共成長」理念，不僅以「極客頭條」、「暢言」欄目在第一時間以技術人的獨特視角描述技術人關心的行業焦點事件，更有「技術頭條」專欄，深度解讀行業內的熱門技術與場景應用，讓所有的開發者緊跟技術潮流，保持警醒的技術嗅覺，對行業趨勢、技術有更為全面的認知。

如果你有優質的文章，或是行業熱點事件、技術趨勢的真知灼見，或是深度的應用實踐、場景方案等的新見解，歡迎聯絡 CSDN 投稿，聯絡方式：微信（guorui_1118，請備註投稿+姓名+公司職位），郵箱（[email protected]）。