2 月 23 日 19:00 左右，來自微盟官網的消息，微盟的業務系統數據庫(包括主備)遭遇其公司運維人員的刪除。

[[316157]]

目前微盟技術團隊正在努力恢復數據，但數據恢復較慢。目前對新用戶服務已經恢復正常，但老用戶數據官方預計要到 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 /"這樣的操作。這種行為，基本上只能通過其他備庫，或物理備份來恢復了。

[[316163]]

從事后恢復情況來看，應該是沒有更多可用的備庫了，但備份數據應該是還有的，所以才需要花費這么長時間。

此外，備份數據恢復完后，通常還需要有一個校驗核對的過程，所以一般會先發公告安撫客戶的情緒。

不過新舊用戶恢復服務的時間并不同，我們由此甚至可以猜測，備份機制可能不合理，新數據的備份更及時，舊數據的備份有延誤，或者比如因為舊數據的量太大了導致延遲更久。

這次更糟糕的是，趕上特殊情況，大家都在家遠程辦公，協同起來肯定更慢，也影響了恢復速度，真是禍不單行。

幸運的是，聽說騰訊云已有多位技術專家參與了拯救工作，希望能盡快恢復。

事件反思和預防

這次的事件，不同于常見的黑客入侵或誤操作，而是源于內部發起的破壞，這種是最可怕、最難防范的行為。

我相信絕對超過 80% 甚至 90% 的中小型公司，都無法避免這個問題。畢竟中小型公司的人員規模有限，想要進行非常細致的權限分級也不太現實，更容易因此降低工作效率和員工的積極性。

盡管如此，我們也嘗試做點什么來預防此類事件再次發生。

首先，是權限分級

我們知道，為了提高工作效率，會部署自動化運維工具。但這樣一來，也極大增加了誤操作帶來的風險。

本次事件中，短時間內造成大面積服務器故障，基本可以斷定是因為工具批量分發命令導致的。

所以，一定要進行權限分級，也包括業務范圍分級。例如可以嘗試以下方案：

①角色分級

區分業務運維、系統運維、網絡運維、DBA 等多重角色，每個角色都只能接觸自己所負責的那票業務服務器，以及相應可執行的權限。

例如，業務運維、網絡運維、DBA 等都不能執行系統層的 rm 指令，系統運維也不能執行數據庫的指令。

②權限分級

區分一級執行權限、二級執行權限及審批權限。

例如，我們可以實施這樣一套方案，一級權限的人發起某個操作請求，有審批權限的審核校驗這個命令是否合理，再由二級權限的人去真正實施。

這樣基本可以防范人為破壞了，除非最后落地時是由同一個人來承擔所有角色，或者嫌麻煩繞過這個規范。

分級措施想做到位，就得有足夠的人員，公司上市的目的就是通過融資以改善運營狀況，該招人就招人吧。

其次，備份、備份、備份

備份的重要性無需多言。但其實，不只是做了備份就可以的，還有如下幾點要注意：

• 除了本地備份，還應該有異地備份，并且要區分本地備份和異地備份責任人的權限，交由不同等級的人管理，防止惡意破壞時，把全套備份都一把火燒了。
• 除了邏輯備份外，還應該有物理備份，物理備份恢復起來會更快一些。
• 除了備份，還應該做好備份校驗，確保備份的有效性，也就是隨機抽取備份集進行恢復測試，確保備份文件的可用性(我多年運維從業經歷，僅有一次比較嚴重的故障，就是栽在沒及時進行備份恢復測試校驗)。

最后，做好防災演練

防災演練的確比較難做，畢竟沒幾個人敢真的在線上全盤執行"rm -fr /"這樣的操作。

不過依然可以模擬各種可能的情況，以及不同情況的組合，再針對這些情況制定不同的預案，然后在開發、測試環境嘗試進行演練。

而且要不定期的進行演練，讓各個崗位的責任人熟悉整套流程。就像在日本，中小學總是不定期進行防災演練一樣，演練次數多了，真遇到問題時，自然就不慌了，恢復起來也會更快。

最后的最后，多給員工一些必要的關懷和培訓吧。還有，作為管理者，對負責后端的運維部門也多給些重視，運維部門一旦出個事故，是真的有可能會搞垮一家上市公司的，這并不是沒有前車之鑒。