刪庫惹的禍,順豐高階工程師“被跑路”
在IT 從業者中,有著一群比程式員還要低調且掌管著大資料時代企業生死命門的人,他們就是傳說中的DBA。論起DBA 的工作職能,很多人表示這可比程式設計師日常複雜得多,不僅上要和應用程式打交道,下還要深入作業系統和硬體之中。所以當繼而談起成為一名優秀的DBA 是種怎樣的體驗時?不少過來人調侃道,你能明白那種刪得了庫跑不了路的酸爽感嗎?
近來,一名來自順豐的技術工程師親身經歷告訴了我們,“對,沒錯,就是這樣的一種感覺。”。
日前,據微博知名網際網路資訊博主@大佬坊間八卦爆料,順豐科技資料中心的一位鄧某因誤刪生產 ofollow,noindex">資料庫 ,導致某項服務無法使用並持續590 分鐘。
來自@大佬坊間八卦微博
後來有網友爆料,這位鄧某是順豐科技IT 資料中心應用交付技術部網際網路產品運維組的IT 運維 開發 高階工程師。
而事件的起因,據網上流傳的郵件截圖顯示:
目前順豐根據公司相關規定,已將鄧某辭退,且在順豐科技全網通報批評。事件一出,立即引發圈中程式設計師們的熱議。很多人無奈的表示,庫都刪了,不跑路幹什麼?記得看好地圖,搭載飛機跑路,否則或因堵車,短短几分鐘之內你就會被抓回了,譬如下面這位:
事實上,無獨有偶,在國內外,刪庫事件早已不是第一次發生,相比之下,此次順豐刪庫帶來的後果還不算最為嚴重,接下來,我們將共同回顧那些年,刪的那些庫帶來了怎樣的後果?我們又該如何避免刪庫跑路事件的頻發?
01、那些年,刪過的庫
大廠說:
2017 年2 月,GitLab 的一位系統管理員在給線上資料庫做負載均衡工作時,遭受了DDoS 攻擊。在阻止了攻擊之後,運維人員發現了資料庫不同步的問題,便開始修復,在修復過程中,錯誤地在生產環境上執行了資料庫目錄刪除命令:
sudo rm -rf
導致300GB 資料被刪成4.5G,GitLab 被迫下線。
2017 年6 月,一家荷蘭海牙的 雲主機 商verelox.com,一名前任管理員刪光了該公司所有客戶的資料,並且擦除了大多數 伺服器 上面的內容。
最終導致Verelox 暫時將網路下線。在釋出的官方公告中,Verelox 表示一直努力恢復資料,但遺憾的是,目前已丟失的所有資料可能恢復不了了。
2017 年9 月,某IT 大廠技術工程師幫助廣西移動進行擴容割接(即增加系統容量)時,不小心將HSS 裝置裡面的使用者資料格式化刪除,導致廣西移動近80 萬用戶資料丟失。
網友說:
與此同時,來自知乎(http://www.zhihu.com/question/58802374)的不少網友也為曾刪過的那些庫,大驚失色,直至現在仍心有餘悸:
@張家考拉:
公司新來一位應屆畢業生,工作能力非常弱,什麼都不會,怎麼辦呢?就先讓她幫忙盤點機房裝置資產。
就因為有個資產標籤看不清楚,直接把刀鋒伺服器拔出來了,旁邊帶她的人看到,瞬間就石化了。業務系統中斷十幾分鍾,領導也沒說什麼,就是不讓她繼續盤點了,而她,根本不知道自己闖禍了。
@土豆爸爸:
多年前(2001 年),那還是Unix 字元介面,半夜我例行維護,刪過一個包含二十萬本圖書的庫。十分鐘自己確認出錯後,開始冒汗,胃部像是被猛打了一拳得開始痙攣,疼的我都坐不住。
好一會我去過道抽了兩根菸,才回憶起前天做了全系統備份,丟的資料不多!
那感覺,一輩子難忘。
@ai0by:
之前自己做的一個站,伺服器是在Vultr 上面,使用者有1000 多,訪問量不少。某天在Vultr 上面另開了一臺測試機器,測試完了準備刪除時刪錯了機器,把放 網站 的那臺刪掉了……(有必要吐槽一下Vultr 的伺服器介面,我以為新開的機器一定是最下面的那個,然後沒看直接就刪掉了,沒想到最下面的那個不是最新開的那臺!)
當時只能說非常慌張,好像在夢裡一樣,滿頭大汗,只能眼睜睜看著一條提示刪除成功的訊息,隨即立刻提交了一條ticket,Vultr 告訴我已經刪除掉的機器是不能恢復的,瞬間感覺長時間的經營全部白費了,很難想象經營了那麼久一個失誤操作全完蛋了。
後來發現那臺機器之前有過備份,另開了一臺機器把映象恢復到新機器上面,時間是一週前,好歹算是救回來了,丟失的資料後來自己手工補上了。
刪掉的一瞬間,好多使用者來找我,我只能淡定的回覆說是在維護,實際慌的要死,在問題解決差不多後,自己後背都溼透了,再也不想有第二次了,切記做好備份,切記切記!
02、那些年,跑路前,我們還可以做些什麼?
和上文刪庫事件相比,不少網友對順豐的處理結果及制度產生質疑,紛紛表示:開除了涉事工程師,順豐自身就完全沒責任?花了這麼大的教訓培養了一位運維就這麼拱手讓人了?
剖開表面,我們不由深思,順豐以辭退為名,真的能撇開其在流程問題所因擔起的責任?此次出事,好在影響尚未造成無法挽回的後果,順豐應做的不是第一時間去辭退涉事員工,而是通過該教訓來看清內部的問題:
-
刪庫事件發生一方面源於工程師本人的失誤,另一方面是否體現了日常管理流程的鬆懈,及操作的不規範?
-
安全責任不分明,除了涉事員工,其直接上司不應擔責?
-
許可權控制混亂,僅一名運維工程師可以直接操作資料庫?
-
災備恢復能力弱,事件的發生到恢復,偌大的順豐企業花費了590 分鐘?
所以,從以上的種種問題來看,我們該如何再次避免刪庫“跑路”等事件的再次發生?
對此,在企業首先做好許可權管理以及多重稽核機制的同時,CSDN 也曾教諸多程式員們如何在Linux 下謹慎使用rm,避免從刪庫到跑路的悲劇發生:
還有無論是運維、DBA 還是程式設計師們都應該在日常Coding 時嚴加註意操作規範,銘記“一失手成千古恨”的後果。在審查時也要做好自動容災、資料同步的步驟,最後,重要的事情說三遍,不要忘記: