順豐該不該開除刪庫的運維工程師？
作為極少數既 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、後話
人是靠不住的，因為人會變、會離開。只讓員工成長，卻不讓系統成長，結果就是經驗都沉澱到了員工自己身上，當員工離職時就帶走了所有，公司一無所獲。
系統才是唯一能永遠留在公司內部的資源。真正優秀的員工，會想方設法來迭代系統，即便自己離開也能高效運轉。而那種讓自己變得不可或缺，離開之後系統便不可持續運轉的員工，其實是最大的隱患。
我又要說我的口頭禪了：一個人的價值，不在於他得到過什麼；而在於他給這個世界留下了什麼。
祝各位朋友中秋節愉快！