作為極少數既?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然后回車的吧？肯定還有嫌每次彈個對話框麻煩，干脆設置成“不提醒確認”的吧？那一旦刪錯了，就能去求助Rstudio之類的數據恢復軟件，至于能不能找回來，就只能聽天由命了。

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

鄧某錯選了 RUSS 數據庫，打算執行刪除的 SQL。

在選定刪除時，因其操作不嚴謹，光標回跳到 RUSS 庫的實例……

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

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

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

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

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

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

現在最有爭議的話題就是：順豐到底怎么處理本次事件才是合理的？

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

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

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

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

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

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

4、我自己經歷的drop事故

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

感謝當時的boss胡震生不僅給了我足夠的包容，還為我開導排解，幫我學習和成長。痛定思痛細查原因，通過技術手段根治，從此再沒有犯過這兩個錯誤。

對我 rm rf / 的經歷感興趣的朋友，可以查看我的博客文章：《欲速則不達》http://zhangshenjia.com/it/slow-down/

5、后話

人是靠不住的，因為人會變、會離開。只讓員工成長，卻不讓系統成長，結果就是經驗都沉淀到了員工自己身上，當員工離職時就帶走了所有，公司一無所獲。

系統才是唯一能永遠留在公司內部的資源。真正優秀的員工，會想方設法來迭代系統，即便自己離開也能高效運轉。而那種讓自己變得不可或缺，離開之后系統便不可持續運轉的員工，其實是最大的隱患。

我又要說我的口頭禪了：一個人的價值，不在于他得到過什么；而在于他給這個世界留下了什么。

祝各位朋友中秋節愉快！