歡迎光臨
每天分享高質量文章

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

(點擊上方公眾號,可快速關註)


# 投稿作者:張砷鎵,個人公號:鎵話


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


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


1、事件還原


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


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


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


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


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


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


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


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


宣告:以下所述只是我個人的揣測,很可能不是事實!


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


做資料同步和遷移有很多種方法,其中最方便快捷、簡單粗暴的方法就是:


  1. 把線上的資料庫 dump(打包) 成一個檔案

  2. 把這個檔案下載到測試環境的機器上

  3. 在測試環境 drop (卸載)現有的庫

  4. 用檔案中的資料重建新的庫


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


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


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



2、問題到底出在哪裡?


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


  1. Why:導致問題的根本原因究竟是什麼?

  2. How: 怎麼避免以後再發生類似的問題?

  3. 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、後話


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


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


我又要說我的口頭禪了:一個人的價值,不在於他得到過什麼;而在於他給這個世界留下了什麼。


祝各位朋友中秋節愉快!



【作者介紹】


張砷鎵:一名具有獨立思考能力和代碼潔癖,且興趣愛好廣泛的程式猿,曾任趕集黃頁事業部技術經理,現從事編程教育工作。骨灰級游戲玩家,曾在魔方、掃雷、俄羅斯方塊等領域取得國內第一,多次打破全國記錄,掃雷網(saolei.net)創始人。

【關於投稿】


如果大家有原創好文投稿,請直接給公號發送留言。


① 留言格式:
【投稿】+《 文章標題》+ 文章鏈接

② 示例:
【投稿】
《不要自稱是程式員,我十多年的 IT 職場總結》:

http://blog.jobbole.com/94148/


③ 最後請附上您的個人簡介哈~

看完本文有收穫?請轉發分享給更多人

關註「資料分析與開發」,提升資料技能

赞(0)

分享創造快樂