作為一名運維俠，如何瀟灑的刪庫跑路?
9 月 19 日下午，據微博網友大佬坊間八卦爆料，順豐的一個工程師手誤把線上系統一個庫刪除了，然后跑路了。
?? 
根據郵件內容，事件詳情如下：
在接到該變更需求后，按照操作流程要求，登陸生產數據庫跳轉機，通過 navicat-mysql 客戶端管理工具，連入 SHIVA-OMCS 的 RUSS 庫進行操作。
但在操作過程中，該運維發現選錯了 RUSS 數據庫，打算刪除執行的 sql。
在選定刪除時，因其操作不嚴謹，光標回跳到 RUSS 庫的實例上，在未看清所選內容的情況下，便通過 delete 執行刪除，同時，他忽略了彈窗提示，直接回車，導致 RUSS 庫被刪除。
因運維人員工作不嚴謹的操作，導致 OMCS 運營監控系統發生故障，該系統上臨時車線上發車功能無法使用并持續約 590 分鐘。同比 9 月 5 日的 929 條臨時車需求，此次故障對業務產生了嚴重的負面影響。
?? 
根據順豐規定，予以開除，并通報公司批評。此外，據說該員工任職順豐科技 IT 數據中心應用交付技術部互聯網產品運維組，職務 IT 運維開發高級工程師。
如何看待順豐工程師誤刪公司數據庫被開除一事?
目前，此事已經在圈內傳開了，各路網友開始吐槽：
?? 
?? 
有幸災樂禍調侃型的：不如，rm -f / 刺激。
?? 
也有人調侃稱：刪的時候肯定很激動!
?? 
還有人調侃：付出如此巨大的代價，培養起了一個運維工程師的安全意識，然后竟然把他開除了?
?? 
最后就是關于是否備份的討論：
?? 
不過最狠的還是屬這一條，反手丟給你一本 MySQL 從刪庫到跑路：
?? 
看看有沒有什么后路好走啊哥們：國內呆不下了，趕緊出國。首先，不要選動車，要選最近的一班飛機，盡快出國，能走高速走高速，不然選人少的路線。
沒錯，我們 DBA 都是常備護照的。切記，注意看高德地圖實時路況。我們有個前輩就是刪庫之后開車就上二環，下午五點鐘。警察到的時候他還堵在路上。
以下為知乎網友的精彩評論：
知乎網友 @vczh 表示：
?? 
知乎網友@匿名用戶回答：
?? 
知乎@匿名用戶：
?? 
?? 
最后，我們再來看看一位資深運維人對順豐數據庫被誤刪事件后的思考：
我們先來算一算，590 分鐘不可用是個什么概念，大概相當于 10 個小時業務不可用。
我們按 365 天來算，一年為 525600 分鐘，590 分鐘服務不可用就意味著這次事件將服務可用性降低到了 99.88%。
那么 99.88% 是個什么概念呢，這個數值可能有些人覺得蠻高的，但是其實在互聯網公司，對于做 OLTP 業務的數據庫來說，估計一年的 KPI 都沒有了。
尤其是對于電商，交易，金融相關的業務來說，10 個小時不可用那簡直就和災難一樣。所以這個運維小哥被開除也應該不足為奇吧。
目前我也不清楚這個運維小哥什么情況，也不知道這 10 個小時是否影響的是核心業務，也不知道為什么要十個小時才恢復起來。我就數據庫被刪除這件事件和大家聊聊我的想法。
首先說說數據庫什么情況下會被刪，我想不外乎兩種情況，要么是被惡意刪除，那么就是被誤操作刪除。
惡意刪除這種沒什么好說的，刪除了肯定根據公司損失來定責，性質比較惡劣，當然是嚴懲不貸，甚至是追究法律責任。我們重點來說說誤操作這種情況。
為什么會產生誤操作事件呢，我理解的誤操作是有兩種情況：
第一種是對技術的研究不夠深入，導致操作誤判出現故障，從而影響到線上業務，比如線上某臺數據庫由于 SQL 索引缺失造成性能問題，導致 SQL 堆積和數據庫 CPU 飆升。
這個時候我們應該怎么操作呢，是Kill SQL，還是在線加索引，還是回滾業務?
我們都知道一般 SQL 索引問題可以通過加索引來解決，但是在這種數據庫高負荷的情況下，加索引可能會導致數據庫資源消耗更加嚴重，從而導致主庫不可用。
這種情況下和業務方溝通 Kill 掉問題 SQL 并且回滾代碼可能是比較好的辦法，或者備庫加好索引進行 MHA 切換也是可以的，這些需要 DBA 同學對數據庫技術和線上操作有一定的經驗才可以準確判斷如何處理這個問題。
如果操作誤判可能就是事故了，但是這些本身是技術經驗相關的，隨著工作經驗的增加，這種誤操作故障會越來越少。
第二種就是純粹的誤操作，誤刪庫，誤刪表，誤刪數據，rm -rf 等等。比如運維同學手抖按了回車，眼睛看花眼把數據庫選錯了，復制粘貼錯了，敲命令太快了等。
這種故障和上面說的技術和經驗無關了，雖然不是惡意的，但是確實和操作人有關系。這種事件是在運維操作里需要格外小心和關注的。
真出了事情，什么理由都不是理由，KPI 沒了，年終獎沒了，甚至工作也沒了，甚至還影響到自己部門的 KPI 考核。
這些事情不論是作為運維人員，還是部門領導都是不愿看到的事情，那么這種誤操作怎么能夠防范和避免呢，根據我自己的工作經驗，我大概總結了下面幾點：
責任心+細心
其實沒什么好說的，不論什么事情和工作，責任心都是基礎，自己的事情自己負責到底，有始有終，這個是考慮一個人首要條件，作為一個 DBA，更加不用說，沒有責任心，做不了 DBA。
對生產環境的敬畏之心
之前看到一些公司的招聘要求，其中有一條就是對生產環境的敬畏之心，作為一個工作 N 年的 DBA 來說，這點現在越來越體會比較深刻。
工作經驗越久，膽子反而越來越小，線上環境操作各種確認，一些重大變更回車遲遲不敢敲下，總要 Delay 半分鐘。
其實我覺得作為一個 DBA 這是一個好的習慣，DBA 不是搬瓦工，不需要你快速操作，保障線上數據安全和持續穩定才是第一位的。
Double Check 機制
Double Check 機制是一個重大變更減少事故的好習慣。很多時候，過于可能會出現失誤，有一些錯誤是自己永遠發現不了的，當局者迷，旁觀者清，這個時候第二個人幫你 Review 操作可能幫助你減少故障。
所以我建議對于生成變更走 Double Check 機制是個很好的習慣。
個人心態
另外一點我想聊的是人無圣人，孰能無過，也許只有經歷過一些事故才能更好的成長。
當出現問題時，也不需要驚慌，把每次故障當成一次成長，出現問題，積極總結問題和故障復盤，要避免的是不要在同一個地方犯同樣的錯誤，也是一種成長。
如何優雅地防止從刪庫到跑路?
換人容易，我們要從根本處避免問題的再次出現。運維不易，且行且珍惜。
但如果我在服務器維護的時候不小心執行了 rm -rf 命令……現在整臺服務器被我刪光了腫么辦???......所以程序員特別喜歡跑步鍛煉。
?? ??
好吧，言歸正傳。下面我們來討論下，程序員如何優雅地防止數據誤刪。現在先來介紹一下 rm。
rm -rf 的威力
rm 是 Linux 系統下刪除文件的命令，-r 代表刪除這個下面的一切，一切的一切那種的一切。f 表示不需要用戶確認，直接執行。
通常這個命令都是指定文件夾用的，比如：
就是刪除 /home/test/ 這個文件夾下面的所有東西。但是如果后面的文件夾路徑沒有加對，rm -rf / 在服務器上也就意味著…解脫了......
?? ??
俗話說的好：常在河邊走，哪能不濕鞋。那該怎么避免這種悲劇的發生呢?
如何避免再次跑路?
一個方案就是重定向 rm 命令以嫁接為 mv 命令，相當于給 Linux 系統定制了一個回收站。
實現方式如下：
最后將上述腳本寫入 /etc/bashrc，并立即執行命令 source /etc/bashrc 即刻生效。
?? ??
這個腳本定義了幾個命令：
- rl：查看回收站下的文件。
- unrm 文件名或目錄：恢復到當前的路徑下。
- rmtrash：清空回收站，不過會友好提示。
執行 rm 不會真正刪除，而是使用 mv 移動到我們指定的回收站。實在真的想刪除可以 /bin/rm 來進行刪除。
另外，需要注意的是，之前 rm 指令的一些參數可能不再使用，因為 rm 現在其實是 mv 了。
使用示例：
效果看著應該還可以吧。
?? ??
雖然看著是還可以，但是也有一些問題，比如刪除文件不能重名，若重名了會提示你是否進行覆蓋。
那就需要再進行特殊處理了，比如刪除時加個時間戳什么的，有興趣的動手實現下吧。參考：??https://www.cloudbility.com/club/6981.html??
出處：《如何優雅地使用 rm 防止誤刪除?》一文來自【不正經程序員】微信公眾號，作者：hoxis;《順豐數據庫被誤刪事件后的思考》一文來自【DBARUN社區】微信公眾號，作者：茹作軍，其他素材是互聯網綜合整理。
留 言 有 禮 活 動
作為程序員，您怎么看待順豐工程師誤刪公司數據庫被開除一事?掃描下方二維碼，關注51CTO技術棧公眾號。歡迎在技術棧微信公眾號留言探討。小編將精選出最有價值的三條評論，分別獲得 50、30、20 元 的 紅 包 獎 勵，活動截止時間 9 月 28 號 12 時整。
?? 
