2 月 23 日 19:00 左右，來自微盟官網的消息，微盟的業務系統數據庫(包括主備)遭遇其公司運維人員的刪除。
目前微盟技術團隊正在努力恢復數據，但數據恢復較慢。目前對新用戶服務已經恢復正常，但老用戶數據官方預計要到 2 月 28 日才有結果。
微盟官網截圖
據悉，目前犯罪嫌疑人已經被寶山區公安局進行刑事拘留，犯罪嫌疑人承認了犯罪的事實。
犯罪嫌疑人乃微盟研發中心運維部核心運維人員賀某，賀某於 2 月 23 日晚 18 點 56 分通過個人 VPN 登入公司內網跳板機，因個人精神、生活等原因對微盟線上生產環境進行了惡意的破壞。
騰訊雲官方稱，微盟運維事故發生後，騰訊雲技術團隊已第一時間與微盟對齊，研究制定修復方案。工程師們正在日夜趕工，將盡最大努力協助微盟降低損失。
微盟集團成立於 2013 年，是一家主要通過 SaaS 產品和精準營銷為商戶提供雲端商業和營銷解決方案的提供商。
截止 2019 年 6 月 30 日，微盟的 SaaS 產品及精準營銷服務擁有 300 萬註冊商戶，SaaS 產品的付費商戶有 70006 名。
根據財報顯示，2019 年上半年微盟收入 6.57億元(人民幣)，毛利 3.65 億元，其中 SaaS 業務收入 2.19 億元，毛利 1.77 億元。
可以看出，其兩大核心業務之一的 SaaS 業務(另一核心業務為精準營銷服務)對微盟業績具有舉足輕重的影響。
微盟認為，此次 SaaS 生產環境和數據破壞對整體財務狀況的影響視修復程度和速度而定，預計將對 SaaS 業務營運帶來一定的負面影響。
針對這起刪庫事件，網友們都炸了：
刪庫跑路事件屢發，在這裡特別提醒各個公司，注意做好兩項工作：
- 更嚴密的權限管理：大部分公司對運維的權限都放得比較寬，容易造成事故。
- 更可靠的備份機制：主備都是可以被刪的，一旦需要從磁盤恢復，恢復時間會很慢。
作為技術人員，千萬不要因為一時腦熱，做出錯誤的決定，讓自己身陷囹圄。
最後，我們跟一位老 DBA，一起來回顧和深入反思下這個事件。
事件回顧
時間回顧如下：
- 2020.2.23 日 18:56，員工通過 VPN 登入服務器並實施破壞。
- 2020.2.23 日 19 時，系統監控報告故障並啟動應急方案。
- 2020.2.24 日，微盟公司向警方報案。
- 2020.2.25 日 7 時，恢復部分生產環境和數據，並預計到凌晨 0 點能完成恢復，並向新用戶恢復業務，但老用戶預計還要到 2 月 28 日晚上才能恢復。
為什麼會發生"刪庫"
從官方發佈的公告來看，是因為運維部的核心員工刻意進行的破壞，也就是說，這是人為的、惡意的、有計劃的破壞行為，而不是我們最常見的誤操作或黑客入侵所致。
不過，從我的經驗來看，這起事件未必是真的人為破壞，具體分析就不貼了。總之，我對官方的公告存疑。不過也不能改變人為破壞這個事實，就看公安機關怎麼定性了。
我們要做的是，進行反思和預防此類事件一再發生，這也是本文的用意。
此外這種意外事故受害的除了公司、員工，更無辜的是客戶，我們祝福微盟能救回更多數據，將損失最小化。
事故恢復的速度如何
從上面的回顧時間點來看，我認為恢復的速度並不算快。
我經過側面瞭解，這起事件主要的影響是數據庫的主備庫都被刪了，並且執行的是類似"rm -fr /"這樣的操作。這種行為，基本上只能通過其他備庫，或物理備份來恢復了。
從事後恢復情況來看，應該是沒有更多可用的備庫了，但備份數據應該是還有的，所以才需要花費這麼長時間。
此外，備份數據恢復完後，通常還需要有一個校驗核對的過程，所以一般會先發公告安撫客戶的情緒。
不過新舊用戶恢復服務的時間並不同，我們由此甚至可以猜測，備份機制可能不合理，新數據的備份更及時，舊數據的備份有延誤，或者比如因為舊數據的量太大了導致延遲更久。
這次更糟糕的是，趕上特殊情況，大家都在家遠程辦公，協同起來肯定更慢，也影響了恢復速度，真是禍不單行。
幸運的是，聽說騰訊雲已有多位技術專家參與了拯救工作，希望能儘快恢復。
事件反思和預防
這次的事件，不同於常見的黑客入侵或誤操作，而是源於內部發起的破壞，這種是最可怕、最難防範的行為。
我相信絕對超過 80% 甚至 90% 的中小型公司，都無法避免這個問題。畢竟中小型公司的人員規模有限，想要進行非常細緻的權限分級也不太現實，更容易因此降低工作效率和員工的積極性。
儘管如此，我們也嘗試做點什麼來預防此類事件再次發生。
首先，是權限分級
我們知道，為了提高工作效率，會部署自動化運維工具。但這樣一來，也極大增加了誤操作帶來的風險。
本次事件中，短時間內造成大面積服務器故障，基本可以斷定是因為工具批量分發命令導致的。
所以，一定要進行權限分級，也包括業務範圍分級。例如可以嘗試以下方案：
①角色分級
區分業務運維、系統運維、網絡運維、DBA 等多重角色，每個角色都只能接觸自己所負責的那票業務服務器，以及相應可執行的權限。
例如，業務運維、網絡運維、DBA 等都不能執行系統層的 rm 指令，系統運維也不能執行數據庫的指令。
②權限分級
區分一級執行權限、二級執行權限及審批權限。
例如，我們可以實施這樣一套方案，一級權限的人發起某個操作請求，有審批權限的審核校驗這個命令是否合理，再由二級權限的人去真正實施。
這樣基本可以防範人為破壞了，除非最後落地時是由同一個人來承擔所有角色，或者嫌麻煩繞過這個規範。
分級措施想做到位，就得有足夠的人員，公司上市的目的就是通過融資以改善運營狀況，該招人就招人吧。
其次，備份、備份、備份
備份的重要性無需多言。但其實，不只是做了備份就可以的，還有如下幾點要注意：
- 除了本地備份，還應該有異地備份，並且要區分本地備份和異地備份責任人的權限，交由不同等級的人管理，防止惡意破壞時，把全套備份都一把火燒了。
- 除了邏輯備份外，還應該有物理備份，物理備份恢復起來會更快一些。
- 除了備份，還應該做好備份校驗，確保備份的有效性，也就是隨機抽取備份集進行恢復測試，確保備份文件的可用性(我多年運維從業經歷，僅有一次比較嚴重的故障，就是栽在沒及時進行備份恢復測試校驗)。
最後，做好防災演練
防災演練的確比較難做，畢竟沒幾個人敢真的在線上全盤執行"rm -fr /"這樣的操作。
不過依然可以模擬各種可能的情況，以及不同情況的組合，再針對這些情況制定不同的預案，然後在開發、測試環境嘗試進行演練。
而且要不定期的進行演練，讓各個崗位的責任人熟悉整套流程。就像在日本，中小學總是不定期進行防災演練一樣，演練次數多了，真遇到問題時，自然就不慌了，恢復起來也會更快。
最後的最後，多給員工一些必要的關懷和培訓吧。還有，作為管理者，對負責後端的運維部門也多給些重視，運維部門一旦出個事故，是真的有可能會搞垮一家上市公司的，這並不是沒有前車之鑑。
閱讀更多 51CTO 的文章
