順豐該不該開除刪庫的運維工程師？

知識 09-23

（點擊

上方公眾號

，可快速關注）

# 投稿作者：張砷鎵，個人公號：鎵話

順豐運維工程師因誤刪庫被開除的事，現在已經在圈內炸鍋了

。

作為極少數既 drop 過生產庫，也 rm -rf / 過線上伺服器的過來人，我覺得自己很有必要站出來說點什麼。

1、事件還原

本次事件流出的是一封順豐內部通報郵件，大概描述了一位鄧姓工程師因操作不當而導致數據丟失、業務停擺的事故，郵件內容如下：

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

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

…… 此次故障導致業務產生了嚴重的負面影響。

……根據《獎勵與處罰管理規定3.0》……對直接責任人鄧XXX予以解除勞動合同處罰，並予以順豐科技全網通報批評。

以上描述得有些專業了，非技術人員理解起來可能有點困難，我來給大家用白話翻譯一下：

小鄧是一名年輕的程序員，干起活來手特別快，平時敲打鍵盤如狂風暴雨一般，一般人的眼睛根本跟不上他的操作。然而跑得越快、摔得越慘，終於有一天，他在做危險操作的時候因為手快發生了失誤，刪除了重要的工作數據，讓公司的系統癱瘓了十個小時。結果他被開除了，還被全公司通報批評。

好了，事情的經過就是這樣。接下來我再從技術角度分析一下。從「導致RUSS 生產資料庫被刪掉」這句話來看，小鄧應該做的是 drop （卸載庫）操作，而不是 delete （刪除數據）操作。根據我的經驗和理解，事情大概率是這樣的：

聲明：以下所述只是我個人的揣測，很可能不是事實！

很明顯，小鄧想把生產環境的資料庫的數據搬到測試環境里。定期將生產數據同步到測試環境，這是一個非常常見且高頻的需求。如果數據結構不同，代碼就跑不起來；如果數據不新不真，產品經理也不好評估新產品的效果。

做數據同步和遷移有很多種方法，其中最方便快捷、簡單粗暴的方法就是：

把線上的資料庫 dump（打包）成一個文件

把這個文件下載到測試環境的機器上

在測試環境 drop （卸載）現有的庫

用文件中的數據重建新的庫

很明顯，事故發生在第三步，也就是：本應在測試環境執行的 drop 操作，在生產環境被執行了。

如果是第一次做這樣的操作，我相信任何有基本職業操守的人都會非常小心的。從小鄧「忽略了彈窗提醒，直接回車」來看，他對整個操作流程是非常熟練的，當天他一定是已經做了很多次這樣的操作。

我大膽地猜測：小鄧同學是在熬夜加班 / 臨近飯點 / 老婆催回家 / …… 之類的狀態下，無心犯下這個錯誤的。

2、問題到底出在哪裡？

既然問題出現了，我們就得搞清楚以下三個問題：

Why：導致問題的根本原因究竟是什麼？

How：怎麼避免以後再發生類似的問題？

What：現在我們應該做些什麼？

我們先來研究一下，導致本起事故的根本原因到底是什麼？真的是小鄧粗心大意、一味求快么？

對任何已有結論的問題，都應該進行自己的獨立思考，這樣才不會人云亦云，掉入思維陷阱里。

在未看清所選內容的情況下，便通過 delete 執行刪除……
同時鄧某忽略了彈窗提醒，直接回車

這一部分沒得說，100%是小鄧的問題。不看提醒直接默認選擇，這是一個非常不好的習慣。應該有很多人在Windows里刪除文件時因為懶得再去清回收站，就直接Shift+Delete然後回車的吧？肯定還有嫌每次彈個對話框麻煩，乾脆設置成「不提醒確認」的吧？那一旦刪錯了，就能去求助R-studio之類的數據恢復軟體，至於能不能找回來，就只能聽天由命了。

做開發和運維的人理應知道數據的重要性，在對數據做 drop、delete 等無法撤銷的危險操作時要慎之又慎，一定要反覆檢查，最好找人結對和review。

鄧某錯選了 RUSS 資料庫，打算執行刪除的 SQL。
在選定刪除時，因其操作不嚴謹，游標回跳到 RUSS 庫的實例……

順豐有 DBA 嗎？運維同學為什麼竟然有許可權操作生產資料庫？生產環境和測試環境為什麼不進行嚴格的隔離？執行線上危險操作時，為什麼不安排雙人結對或者review？同步數據這種高頻操作為什麼沒有做成腳本或服務，而是靠容易出錯的人工來執行？

當然，順豐體量雖大，但畢竟並不是一家互聯網公司，可能工程師數量還不及業內一家小型創業公司。在這種情況下，一人多用、許可權混亂也是可以理解的常態。但對於數據十分重要、服務絕對不能停的業務，CTO和項目leader，應該對員工可能出現的操作失誤設計預先防範的措施和制度，否則就是失職。當你的業務有可能因為員工一個小失誤就癱瘓，甚至數據無法找回導致公司關門時，你怎麼還睡得著覺？

在照顧孩子的時候，我學到的最重要的道理就是：如果有樣東西不能讓孩子玩，那就不能放在孩子夠得著的地方。如果你是一名銷售，剛簽完一個大客戶，興高采烈地回到家裡，把合同扔到茶几上，然後衝進洗手間上了個廁所回來，就發現合同被你家熊孩子用筆塗得一塌糊塗，你覺得是該怪孩子調皮呢，還是該怪你自己不小心？

綜上所述，我認為雖然小鄧的誤操作是本次事故的直接原因，但順豐公司對明顯的安全隱患視而不見，在許可權管理、風險控制、流程設計上存在重大缺陷，才是本次事故的根本原因。

3、順豐到底該不該開除小鄧？

如果找不到問題的根本原因，在錯誤的方向上再怎麼努力，也不可能找到解決方案。相反，只要找到了正確的原因，解決方案也就自動呈現。所以，我們就不浪費時間來討論如何避免再發生類似事故了。

現在最有爭議的話題就是：

順豐到底怎麼處理本次事件才是合理的？

小鄧因工作失誤，給公司帶來了巨大的損失，這是客觀事實。而小鄧作為個人是無力賠償公司損失的，順豐公司作為非國家單位，能動用最高級別的懲罰就只有開除。我相信，順豐這麼大的公司，作出開除並通報批評這個決定，應該是經過激烈的討論的。最終決策者還是決定殺雞儆猴，以儆效尤。從法律的角度上講，順豐有權這麼做；從道德的角度上講，順豐的立場也沒有問題。

可是，為什麼業內對這個處理結果會出現如此大的反應呢？因為順豐在處理的過程中呈現了一副冷冰冰的姿態，在事故原因分析中把所有責任推卸到員工頭上，對公司制度的缺失及領導者的失職隻字不提，實在讓人心寒。

定義為人的問題，那就只能解決人，卻解決不了問題。

開除了一個小鄧，卻不在許可權設計、流程管控上下功夫，那還一定還會有小王、小張們前仆後繼地繼續出同樣的問題。也許現在風聲緊，大家都會對安全格外注意，但不會持續多久。

定義為程序和制度的問題，才能從根本上解決問題。

順豐本來可以保留一個忠心耿耿、加薪慾望低的好員工，同時呈現出包容錯誤的正能量企業文化，收買大片人心。但是現在順豐的員工們會怎麼想呢？原來公司沒有把我們當人看，我們只是隨時可以更換的螺絲釘，出了問題就走人，就算是機器出了問題，我們也得當背鍋俠。

對小鄧來說，被開除反而是一個好消息。有過這麼一次慘痛的經驗教訓，估計小鄧一輩子都不會再犯刪除線上庫這種錯誤了。我們都知道人的價值是由稀缺性決定的，擁有小鄧這樣有經驗的人可謂是少之又少。小鄧現在出了名，一定會有N多公司給他拋出橄欖枝，會有更好的機會等待著他。相反，如果順豐沒有開除小鄧，他一定會因為內疚而對工作更加盡職盡責，短期也不會選擇跳槽。交了這麼高學費的人，怎麼能放他走，便宜別的公司呢？

開除了一個大有前途的員工，順便傷了全公司的人的心，還引發業界口誅筆伐，帶動股價下跌。順豐這次真是賠到姥姥家了。

4、我自己經歷的drop事故

我2011-2013年在微拍工作期間，既犯過 drop 線上庫的錯誤，也犯過 rm rf / 線上伺服器的錯誤。其中drop線上庫的經過，跟小鄧基本上是一模樣的。我後來寫了一篇博客來反思，直接上圖吧：