在絕大多數情況下，當我們說一行文字“一字千金”時，往往只是在用誇張的方式表達其內容具備極高的價值。
但在某些特殊時候，“一字千金”這個詞很可能真的變成它字面上的那個意思。
嗯，比方說當有程序員想要刪庫跑路的時候。
2月25日，上海市一家港股上市企業微盟發佈公告，稱“其一名運維人員賀某因個人精神、生活等原因”而對企業的數據庫進行了惡意破壞，直接導致這家公司的線上系統引發了全面故障。
雖然引發這一切的那名運維人員賀某，現在已經被寶山區的公安民警抓獲，但這波鬧劇引發的損失卻是已經難以挽回。
作為一家上市企業，這家倒黴公司從23日晚上系統開始故障之後，資本市場就迅速對其做出了反應。
最直觀的體現就是在他們的股價上，僅僅在2月24日一天之內，微盟就直接蒸發掉了12.53億港元的市值。
一行業內流傳的刪庫代碼只有“rm -rf/*”區區幾個字符，而當前港元兌人民幣的匯率差不多是1：1，黃金的當前市價又是在340元人民幣/克。
有數學好的學習委員可以來算一下，這位程序員老哥寫下的這行代碼平均一個字符到底值多少黃金（手動滑稽）。
股價的下跌還只是明面上的損失，至於其他隱性損失則更是難以估量。
這裡先給大夥簡單科普一下微盟這家企業的大體業務吧，他們是一家給線上的小程序電商提供系統支持服務的企業。
用他們的專業術語來說叫“智能商業服務提供商”，不過我們大可以簡單的將其理解為給微信上的小程序電商提供服務的一個平臺，或者說就是微信上的淘寶（當然這麼說並不算嚴謹，只是為了方便理解）。
想象一下，如果你是一個在某寶上開網店的個體商戶，現在某寶的系統崩潰了，那麼你將會面臨的情況基本上就和本次事件裡微盟商戶的遭遇差不多了。
眾所周知，中國的商業市場競爭是非常非常激烈的。
現在微盟在這裡演了出自擺烏龍的大戲，那麼他的友商自然會跑過來強（趁）勢（火）圍（打）觀（劫）一波。
2月25日，有贊發出“江湖救急”公告，稱願意為所有因為微盟本次刪庫事件而業務停擺的商戶，提供長達兩週的免費開店業務，用意是幫助他們度過這個特殊時期。
也許是怕自己挖牆腳的意圖不夠明顯，他們還特地為那些“在微盟的軟件服務尚未到期”的商戶準備了額外的特殊補貼……
用小腦想想也能明白，只要有贊那邊別過兩天也出個類似的數據庫被刪事故，那麼在兩週的免費體驗期過後，這些商戶基本上不太可能再主動迴歸微盟了。
不過商業競爭嘛，這種事倒也還算可以理解……只要別最後查出來微盟那個刪庫跑路的運維，竟然是有贊派過去的就行。
說起來，相比起這次的苦主微盟，有贊這家企業在圈外的名氣應該還要更大一些。
畢竟他們家的CEO白鴉，曾經因為在公司年會上公然宣稱996工作制度，以至於被眾多網友罵上了熱搜，最後還被杭州有關部門的執法人員約談過。
嘖嘖……總感覺那些個體小商戶怕不是又跳進了另外一個火坑裡哦~
話說回來，其實運維（DBA）刪庫跑路現象在IT圈子裡其實不算什麼太稀罕的事情，幾乎每年都會有類似的新聞傳出。
只不過微盟這一次的損失特別慘重，創造了因為刪庫而一天蒸發十億市值的紀錄，所以才得到了這麼高的輿論關注度。
打個未必恰當的比方，就好像說世界上被戴綠帽的苦主千千萬，但是能夠被全國人民一起吃瓜關注的也就那幾位一樣。（我沒說寶強哥啊，你們別瞎想）
就像那些給自家老公戴綠帽的姑娘各有各的理由一樣，歷年來各位做出刪庫跑路這種壯舉的運維大兄弟，他們的初衷也可以稱得上是千奇百怪。
不過在所有理由當中，手滑一定是排在首位的哪一個。
2018年9月，順豐某高級工程師在升級系統數據庫的時候就一時不慎，將RUSS 數據庫順手給刪了，導致了整個順豐集團的線上發車功能都陷入了長時間停擺。
這件事的處理結果非常簡單，順豐在把這位直接責任人揪出後，直接將其當場開除了事。
這起事件一度還在程序員圈子裡引起了熱議，認為順豐此舉有待商榷。
畢竟一個能讓員工在無意間的誤操作而造成嚴重後果的數據庫，其本身的安全性就是存在問題的，不能把責任完全歸咎於員工個人。
同樣因為手滑而釀成大錯的還有海外的某明星企業GitLab，作為全球第二大的開源代碼託管平臺，GitLab的技術實力與他的名氣似乎並不相稱。
2017年1月31日，GitLab內部的一位系統管理員在給數據庫做日常維護時，遭受到了外部的惡意 DDoS 攻擊。
雖然該管理員成功阻止了本次攻擊，但他卻在做事後的修復工作時一時不慎，在生產環境上執行了數據庫目錄刪除命令……大家可以直接理解為簡單的三個字“格式化”。
<code>sudo rm -rf/<code>
最終經過一番搶救性的數據修復，論壇上原本高達300GB的數據只保留下來 4.5G，基本上是十不存一，直接導致當時的GitLab被迫下線。
雖然造成運維刪庫跑路的最主要原因都是手滑，但是並不代表就沒有發生過員工為了報復公司而做出的有意之舉。
2017年6月，荷蘭海牙的一家雲主機商 verelox.com，就被一名與企業存在糾紛的前任管理員刪光了公司所有客戶的數據，最終導致企業整體被迫下線。
2018年，杭州市餘杭區人民法院又宣判過一起因為刪庫引發的案件，被告人甚至都不知是簡單的運維員工，而是作為原告的那家科技企業的前技術總監。
具體過程當然無非就算那點狗屁倒灶的破事，因為公司發展不景氣、新人換舊人、內部派系鬥爭等原因，從2014年加入這家企業一手搭建起內部系統的技術總監被公司老闆強行清退。
而對此大感不滿的這位前技術總監，則直接來了個衝冠一怒，把老東家的數據庫與服務器來了個大掃除，最後被人民法院判了2年半的刑期。
所以說目前針對運維刪庫跑路現象的討論，其實都有點紙上談兵的意思。
不管是設置備份、分級權限操作還是多重審核之類的機制，歸根結底也只能用來降低因為“員工手滑”而導致的無心之過。
如果碰上的是因為對公司不滿而打算魚死網破的內部員工，那麼再嚴密的防範機制也還是可以被人繞過去的。
就像杭州那家科技企業的例子，人自個就是你們家技術部門的最高領導，他鐵了心要把公司的數據庫刪了跑路，你就是備份做的再好，也無非是讓人家多費兩道手，多刪除覆蓋幾遍罷了。
唯一能從根本上解決問題的方法，其實還是在公司老闆自己身上，對員工好點（多給點錢）其實啥事都解決了。
錢給足了，招點經驗豐富的靠譜員工，“手滑”的風險自然也就小了；至於員工惡意報復……你錢都給足了，哪來那麼多想不開的非要拼著自己進去蹲大獄，也要來給你找這個不痛快？
主筆 | 阿虛
閱讀更多 柴狗夫斯基 的文章
