9 月 19 日下午，據(jù)微博網(wǎng)友大佬坊間八卦爆料，順豐的一個(gè)工程師手誤把線上系統(tǒng)一個(gè)庫刪除了，然后跑路了。

??

根據(jù)郵件內(nèi)容，事件詳情如下：

在接到該變更需求后，按照操作流程要求，登陸生產(chǎn)數(shù)據(jù)庫跳轉(zhuǎn)機(jī)，通過 navicat-mysql 客戶端管理工具，連入 SHIVA-OMCS 的 RUSS 庫進(jìn)行操作。

但在操作過程中，該運(yùn)維發(fā)現(xiàn)選錯(cuò)了 RUSS 數(shù)據(jù)庫，打算刪除執(zhí)行的 sql。

在選定刪除時(shí)，因其操作不嚴(yán)謹(jǐn)，光標(biāo)回跳到 RUSS 庫的實(shí)例上，在未看清所選內(nèi)容的情況下，便通過 delete 執(zhí)行刪除，同時(shí)，他忽略了彈窗提示，直接回車，導(dǎo)致 RUSS 庫被刪除。

因運(yùn)維人員工作不嚴(yán)謹(jǐn)?shù)牟僮?，?dǎo)致 OMCS 運(yùn)營監(jiān)控系統(tǒng)發(fā)生故障，該系統(tǒng)上臨時(shí)車線上發(fā)車功能無法使用并持續(xù)約 590 分鐘。同比 9 月 5 日的 929 條臨時(shí)車需求，此次故障對業(yè)務(wù)產(chǎn)生了嚴(yán)重的負(fù)面影響。

??

根據(jù)順豐規(guī)定，予以開除，并通報(bào)公司批評。此外，據(jù)說該員工任職順豐科技 IT 數(shù)據(jù)中心應(yīng)用交付技術(shù)部互聯(lián)網(wǎng)產(chǎn)品運(yùn)維組，職務(wù) IT 運(yùn)維開發(fā)高級工程師。

如何看待順豐工程師誤刪公司數(shù)據(jù)庫被開除一事?

目前，此事已經(jīng)在圈內(nèi)傳開了，各路網(wǎng)友開始吐槽：

??

??

有幸災(zāi)樂禍調(diào)侃型的：不如，rm -f / 刺激。

??

也有人調(diào)侃稱：刪的時(shí)候肯定很激動(dòng)!

??

還有人調(diào)侃：付出如此巨大的代價(jià)，培養(yǎng)起了一個(gè)運(yùn)維工程師的安全意識，然后竟然把他開除了?

??

最后就是關(guān)于是否備份的討論：

??

不過最狠的還是屬這一條，反手丟給你一本 MySQL 從刪庫到跑路：

??

看看有沒有什么后路好走啊哥們：國內(nèi)呆不下了，趕緊出國。首先，不要選動(dòng)車，要選最近的一班飛機(jī)，盡快出國，能走高速走高速，不然選人少的路線。

沒錯(cuò)，我們 DBA 都是常備護(hù)照的。切記，注意看高德地圖實(shí)時(shí)路況。我們有個(gè)前輩就是刪庫之后開車就上二環(huán)，下午五點(diǎn)鐘。警察到的時(shí)候他還堵在路上。

以下為知乎網(wǎng)友的精彩評論：

知乎網(wǎng)友 @vczh 表示：

??

知乎網(wǎng)友@匿名用戶回答：

??

知乎@匿名用戶：

??

??

最后，我們再來看看一位資深運(yùn)維人對順豐數(shù)據(jù)庫被誤刪事件后的思考：

我們先來算一算，590 分鐘不可用是個(gè)什么概念，大概相當(dāng)于 10 個(gè)小時(shí)業(yè)務(wù)不可用。

我們按 365 天來算，一年為 525600 分鐘，590 分鐘服務(wù)不可用就意味著這次事件將服務(wù)可用性降低到了 99.88%。

那么 99.88% 是個(gè)什么概念呢，這個(gè)數(shù)值可能有些人覺得蠻高的，但是其實(shí)在互聯(lián)網(wǎng)公司，對于做 OLTP 業(yè)務(wù)的數(shù)據(jù)庫來說，估計(jì)一年的 KPI 都沒有了。

尤其是對于電商，交易，金融相關(guān)的業(yè)務(wù)來說，10 個(gè)小時(shí)不可用那簡直就和災(zāi)難一樣。所以這個(gè)運(yùn)維小哥被開除也應(yīng)該不足為奇吧。

目前我也不清楚這個(gè)運(yùn)維小哥什么情況，也不知道這 10 個(gè)小時(shí)是否影響的是核心業(yè)務(wù)，也不知道為什么要十個(gè)小時(shí)才恢復(fù)起來。我就數(shù)據(jù)庫被刪除這件事件和大家聊聊我的想法。

首先說說數(shù)據(jù)庫什么情況下會被刪，我想不外乎兩種情況，要么是被惡意刪除，那么就是被誤操作刪除。

惡意刪除這種沒什么好說的，刪除了肯定根據(jù)公司損失來定責(zé)，性質(zhì)比較惡劣，當(dāng)然是嚴(yán)懲不貸，甚至是追究法律責(zé)任。我們重點(diǎn)來說說誤操作這種情況。

為什么會產(chǎn)生誤操作事件呢，我理解的誤操作是有兩種情況：

第一種是對技術(shù)的研究不夠深入，導(dǎo)致操作誤判出現(xiàn)故障，從而影響到線上業(yè)務(wù)，比如線上某臺數(shù)據(jù)庫由于 SQL 索引缺失造成性能問題，導(dǎo)致 SQL 堆積和數(shù)據(jù)庫 CPU 飆升。

這個(gè)時(shí)候我們應(yīng)該怎么操作呢，是Kill SQL，還是在線加索引，還是回滾業(yè)務(wù)?

我們都知道一般 SQL 索引問題可以通過加索引來解決，但是在這種數(shù)據(jù)庫高負(fù)荷的情況下，加索引可能會導(dǎo)致數(shù)據(jù)庫資源消耗更加嚴(yán)重，從而導(dǎo)致主庫不可用。

這種情況下和業(yè)務(wù)方溝通 Kill 掉問題 SQL 并且回滾代碼可能是比較好的辦法，或者備庫加好索引進(jìn)行 MHA 切換也是可以的，這些需要 DBA 同學(xué)對數(shù)據(jù)庫技術(shù)和線上操作有一定的經(jīng)驗(yàn)才可以準(zhǔn)確判斷如何處理這個(gè)問題。

如果操作誤判可能就是事故了，但是這些本身是技術(shù)經(jīng)驗(yàn)相關(guān)的，隨著工作經(jīng)驗(yàn)的增加，這種誤操作故障會越來越少。

第二種就是純粹的誤操作，誤刪庫，誤刪表，誤刪數(shù)據(jù)，rm -rf 等等。比如運(yùn)維同學(xué)手抖按了回車，眼睛看花眼把數(shù)據(jù)庫選錯(cuò)了，復(fù)制粘貼錯(cuò)了，敲命令太快了等。

這種故障和上面說的技術(shù)和經(jīng)驗(yàn)無關(guān)了，雖然不是惡意的，但是確實(shí)和操作人有關(guān)系。這種事件是在運(yùn)維操作里需要格外小心和關(guān)注的。

真出了事情，什么理由都不是理由，KPI 沒了，年終獎(jiǎng)沒了，甚至工作也沒了，甚至還影響到自己部門的 KPI 考核。

這些事情不論是作為運(yùn)維人員，還是部門領(lǐng)導(dǎo)都是不愿看到的事情，那么這種誤操作怎么能夠防范和避免呢，根據(jù)我自己的工作經(jīng)驗(yàn)，我大概總結(jié)了下面幾點(diǎn)：

責(zé)任心+細(xì)心

其實(shí)沒什么好說的，不論什么事情和工作，責(zé)任心都是基礎(chǔ)，自己的事情自己負(fù)責(zé)到底，有始有終，這個(gè)是考慮一個(gè)人首要條件，作為一個(gè) DBA，更加不用說，沒有責(zé)任心，做不了 DBA。

對生產(chǎn)環(huán)境的敬畏之心

之前看到一些公司的招聘要求，其中有一條就是對生產(chǎn)環(huán)境的敬畏之心，作為一個(gè)工作 N 年的 DBA 來說，這點(diǎn)現(xiàn)在越來越體會比較深刻。

工作經(jīng)驗(yàn)越久，膽子反而越來越小，線上環(huán)境操作各種確認(rèn)，一些重大變更回車遲遲不敢敲下，總要 Delay 半分鐘。

其實(shí)我覺得作為一個(gè) DBA 這是一個(gè)好的習(xí)慣，DBA 不是搬瓦工，不需要你快速操作，保障線上數(shù)據(jù)安全和持續(xù)穩(wěn)定才是第一位的。

Double Check 機(jī)制

Double Check 機(jī)制是一個(gè)重大變更減少事故的好習(xí)慣。很多時(shí)候，過于可能會出現(xiàn)失誤，有一些錯(cuò)誤是自己永遠(yuǎn)發(fā)現(xiàn)不了的，當(dāng)局者迷，旁觀者清，這個(gè)時(shí)候第二個(gè)人幫你 Review 操作可能幫助你減少故障。

所以我建議對于生成變更走 Double Check 機(jī)制是個(gè)很好的習(xí)慣。

個(gè)人心態(tài)

另外一點(diǎn)我想聊的是人無圣人，孰能無過，也許只有經(jīng)歷過一些事故才能更好的成長。

當(dāng)出現(xiàn)問題時(shí)，也不需要驚慌，把每次故障當(dāng)成一次成長，出現(xiàn)問題，積極總結(jié)問題和故障復(fù)盤，要避免的是不要在同一個(gè)地方犯同樣的錯(cuò)誤，也是一種成長。

如何優(yōu)雅地防止從刪庫到跑路?

換人容易，我們要從根本處避免問題的再次出現(xiàn)。運(yùn)維不易，且行且珍惜。

但如果我在服務(wù)器維護(hù)的時(shí)候不小心執(zhí)行了 rm -rf 命令……現(xiàn)在整臺服務(wù)器被我刪光了腫么辦???......所以程序員特別喜歡跑步鍛煉。

??

[[244574]]

好吧，言歸正傳。下面我們來討論下，程序員如何優(yōu)雅地防止數(shù)據(jù)誤刪。現(xiàn)在先來介紹一下 rm。

rm -rf 的威力

rm 是 Linux 系統(tǒng)下刪除文件的命令，-r 代表刪除這個(gè)下面的一切，一切的一切那種的一切。f 表示不需要用戶確認(rèn)，直接執(zhí)行。

通常這個(gè)命令都是指定文件夾用的，比如：

rm -rf /home/test/

就是刪除 /home/test/ 這個(gè)文件夾下面的所有東西。但是如果后面的文件夾路徑?jīng)]有加對，rm -rf / 在服務(wù)器上也就意味著…解脫了......

??

[[244575]]

俗話說的好：常在河邊走，哪能不濕鞋。那該怎么避免這種悲劇的發(fā)生呢?

如何避免再次跑路?

一個(gè)方案就是重定向 rm 命令以嫁接為 mv 命令，相當(dāng)于給 Linux 系統(tǒng)定制了一個(gè)回收站。

實(shí)現(xiàn)方式如下：

### 重定義rm命令 ###  # 定義回收站目錄 trash_path='~/.trash'  # 判斷 $trash_path 定義的文件是否存在，如果不存在，那么就創(chuàng)建 $trash_path. if [ ! -d $trash_path ]; then     mkdir -p $trash_path fi  # 定義別名：使用 rm 就調(diào)用 trash alias rm=trash  # 使用 rl 就調(diào)用 'ls ~/.trash'  # 如果更改上面的回收站目錄這里的目錄也需要修改 alias rl='ls ~/.trash'  # 使用 unrm 就調(diào)用 restorefile，需要在刪除目錄的父目錄下執(zhí)行 alias unrm=restorefile  # 使用 rmtrash 就調(diào)用 claearteash alias rmtrash=cleartrash  # 恢復(fù)文件的函數(shù) restorefile() {     mv -i ~/.trash/$@  ./ }  # 刪除文件的函數(shù) trash() {       mv $@  ~/.trash/ }  # 清空回收站的函數(shù) cleartrash() { read -p "確定要清空回收站嗎?[y/n]" confirm 'y' ] || [ $confirm == 'Y' ]  && /bin/rm -rf  ~/.trash/* }

最后將上述腳本寫入 /etc/bashrc，并立即執(zhí)行命令 source /etc/bashrc 即刻生效。

??

[[244576]]

這個(gè)腳本定義了幾個(gè)命令：

• rl：查看回收站下的文件。
• unrm 文件名或目錄：恢復(fù)到當(dāng)前的路徑下。
• rmtrash：清空回收站，不過會友好提示。

執(zhí)行 rm 不會真正刪除，而是使用 mv 移動(dòng)到我們指定的回收站。實(shí)在真的想刪除可以 /bin/rm 來進(jìn)行刪除。

另外，需要注意的是，之前 rm 指令的一些參數(shù)可能不再使用，因?yàn)?rm 現(xiàn)在其實(shí)是 mv 了。

使用示例：

# touch hoxistest # touch 1 # mkdir haha # ls 1  haha  hoxistest # rm 1 # ls haha  hoxistest  # 查看回收站文件 # rl 1  myftp1  # 恢復(fù)已刪除文件 # unrm 1 [root@CESHI-CLM-10-254-4-48 test]# ls 1  haha  hoxistest  # rm haha/ # rm hoxistest # rl haha  hoxistest  # 情況回收站 # rmtrash 確定要清空回收站嗎?[y/n]y # rl

效果看著應(yīng)該還可以吧。

??

[[244577]]

雖然看著是還可以，但是也有一些問題，比如刪除文件不能重名，若重名了會提示你是否進(jìn)行覆蓋。

那就需要再進(jìn)行特殊處理了，比如刪除時(shí)加個(gè)時(shí)間戳什么的，有興趣的動(dòng)手實(shí)現(xiàn)下吧。參考：??https://www.cloudbility.com/club/6981.html??

出處：《如何優(yōu)雅地使用 rm 防止誤刪除?》一文來自【不正經(jīng)程序員】微信公眾號，作者：hoxis;《順豐數(shù)據(jù)庫被誤刪事件后的思考》一文來自【DBARUN社區(qū)】微信公眾號，作者：茹作軍，其他素材是互聯(lián)網(wǎng)綜合整理。

留 言 有 禮 活 動(dòng)

作為程序員，您怎么看待順豐工程師誤刪公司數(shù)據(jù)庫被開除一事?掃描下方二維碼，關(guān)注51CTO技術(shù)棧公眾號。歡迎在技術(shù)棧微信公眾號留言探討。小編將精選出最有價(jià)值的三條評論，分別獲得 50、30、20 元 的 紅 包 獎(jiǎng) 勵(lì)，活動(dòng)截止時(shí)間 9 月 28 號 12 時(shí)整。

??