誤刪數據庫的順豐工程師，真的應該被開除麽？

昨天晚上，據微博網友大佬坊間八卦爆料，順豐科技數據中心的一位高級工程師（鄧XX）誤刪生產數據庫，導致某項服務無法使用並持續 590 分鐘。最終公司決定辭退工程師鄧某，並在順豐內網通報。

據內部通報：

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

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

網友爆料的內部通報郵件截圖：

下面是部分網友的討論：

一直以來，「刪庫」就是 IT 人口中的熱點話題，每次的討論都離不開一張神圖：

對於「從刪庫到跑路」這個半調侃半心酸的觀點，知乎上有一位朋友的回復，可能反映了這個行業的一些現狀：

正如這位朋友所說的，在一家公司，你真的搞得線上數據無法恢復的話，那麽可能真的只好跑路了。

但發生誤操作從而「刪庫」的工程師，真的一定要被開除麽？

以上是網友們的觀點，而我的觀點是：犯了錯誤，就要承擔相應的後果，但不一定非要開除。原因有三：

1. 如果一定要開除，那麽他的直屬主管也應該一並被開除。以順豐事件為例，當事人的責任在所難免，但「刪庫」應該是運維主管才有的權限，所以部門的老大應該承擔更大的責任；

2. 一般來說，對於線上的數據庫操作，提交的 SQL 語句都會進行審核、數據備份，然後才是入庫。正如網友所說的那樣，順豐運維平台在數據庫操作權限、操作流程控制以及災備應急這三方面做得確實太不到位了...

跟開除一名員工相比，借由這次的事情解決自身平台的運維問題才是關鍵，而一名內部的高級工程師在這項工作中肯定能提供很大的幫助；

3. 如果這個人平時是個很負責、很忠誠、技術能力很強的人，今天確實是腦子一熱做的誤操作。為此就開除一個培養了多年的精英，實在是便宜了別的公司，開除不如採用一些別的形式的懲罰措施。

這點國外技術公司的做法值得我們借鑒，在核實情況後，他們大部分是會保護“誤操作”的員工。說的好聽點是對工程師友好尊重，說的更直白點是，我花這麽大代價培養的人，怎麽可以輕易便宜了其他公司呢？

21世紀什麽最貴？人才啊！

*部分素材整理自網絡，如侵刪

網上有一個觀點：任何運維問題，可以分成三類：政治問題、管理問題、技術問題。

如果是政治問題，那有相應的解決方案；但這次事故，顯然更像是一個管理問題，把責任粗暴安在一個技術人員頭上，是最差的做法，哪怕只是做到亡羊補牢，也為時未晚。

順豐前一陣兒先是數據庫被暗網售賣，現在又是高級工程師“從刪庫到跑路”...辭退一名員工很容易，但真的有利於順豐解決技術問題麽？

這事兒你怎麽看？

你覺得這個員工應該被開除麽？

本文轉載自【51CTO官微】