受訪者騰訊云技術人員

　　記者胡巍巍

　　出品 CSDN（ID：CSDNnews）

　　766 次在線會議、臨時調撥 100 多臺服務器，“調兵”四地工程師，這是騰訊云“救援”微盟的付出。

　　3 月 1 日，“微盟刪庫”事件收尾，并制定 1.5 億元賠付計劃。這，不啻于一場血的教訓。

　　此次災難，對于有著 300 萬注冊用戶、超 7 萬的付費用戶的上市公司微盟，后果非同小可。

　　金錢上如此，時間上更是成本巨大。作為國內開發界的佼佼者，即便是騰訊云工程師出馬，也花費整整 7 天 7 夜才搞定。

　　那么這次刪庫到底有多復雜？騰訊云又是如何做完這場堪稱技術界的“心臟手術”？

　　CSDN 采訪本次參與救援的騰訊云工程師，力圖為讀者復原“搶救”全過程，也希望能為開發者和企業，帶來以此次事件為圓心的建設性建議。

　　事發后，三方組隊救援

　　事故發生于 2 月 23 日周日晚上六點多，騰訊云基本和微盟同時發現，隨后雙方立馬建立虛擬團隊商量對策。

　　騰訊云投入大約三十多位來自服務器技術、IDC 現場、售后專家、安全、存儲、數據庫、網絡、基礎 IaaS 研發運維等團隊工程師，這些工程師分別來自北上廣深四地。7 天 7 夜中，他們時刻在和時間賽跑。

　　由于任務十萬火急，大家睡覺只敢定 2 小時的鬧鐘，鬧鐘一響就接著戰斗。騰訊云副總裁王慧星，也多次連夜進行技術指導，有次一直忙到凌晨 6 點多。

　　而這次救援的總指揮——騰訊云運維中心和客戶服務部門負責人徐勇州，在事件發生后，連續工作至少 36 個小時，才去稍微睡一會。

　　微盟 CTO 黃駿偉，7*24 小時全天在線，為的就是及時和騰訊云團隊，溝通修復過程中的技術問題。

　　救援很火急，在分工上需要做更專業的規劃，故此騰訊云、微盟以及數據恢復公司技佳瑞康，以最快的時間排查原因、并制定出一套完整的數據恢復方案。

　　排查原因：微盟賬號被執行高危操作

　　在排查到底哪個環節出問題時，工程師們發現所有服務器，都處于服務無法響應的狀態，是的，所有！

　　然后，他們選其中一臺服務器進行重啟。重啟后，發現系統所有數據都不見了，這說明數據庫要么被入侵，要么就是被故意破壞。

　　此時，騰訊云鼎實驗室應急專家團隊與微盟技術團隊隨即聯合排查，很快就溯源到微盟部署在自建 MySQL 數據庫上的核心業務數據，被微盟某運維人員用一種讓程序員聞風喪膽的 Linux 系統下文件刪除命令，整體進行了不可逆的刪除。

　　后續在對外公告中，微盟也披露了該細節。確定原因后，騰訊云開始制定救援方案。

　　方案分三個步驟：

　　第一，控制受損面。不能讓還有機會找回數據的服務器，再出現任何閃失。

　　第二，把數據找回來。這個過程非常耗時，首先要去看到底還有多少數據在，找到數據后再把它恢復出來。恢復之后，還要給微盟驗證數據是否完好、導入到數據庫是否正常、以及加載到服務器上是否正常。

　　第三，調試數據。數據驗證結束后，微盟要根據數據，進行業務上線和聯調演練。

　　但是，恢復過程也并非一帆風順，因為以往沒有任何可參考的案例，只能摸著石頭過河。

　　數據恢復：行走在危險的邊緣

　　找出原因后，就是艱難的數據恢復過程。

　　騰訊云先是把微盟服務器上的源數據鏡像，拷貝一份出來，以便保護好源數據。

　　微盟有接近數百T的數據，數據拷貝很花費時間，因此工程師們想了兩種拷貝方式。

　　第一種方式，是通過兩臺機器網絡來對拷。他們計算了一下，正常情況下，大概得兩天左右，優點是相對安全。

　　第二種方式，是把硬盤掛載。把硬盤從服務器里拔出來，插到有更多盤的設備上，即用多臺服務器并行的方式，把每個硬盤數據復制出來，雖然速度快、但是風險大，任何一步細微失誤，數據可能就徹底沒了。

　　兩難之下，在征得微盟同意后，團隊做了一個大膽決定：越過鏡像拷貝的步驟，同時不把微盟的數據盤，從原有服務器上拔下來。而是將另外一塊系統盤，安裝到原有服務器上，通過新系統盤加載 OS 和數據恢復軟件，直接掃描提取數據盤中的“隱藏”數據。

　　確定數據拷貝方式后，騰訊云立即組織團隊，進行設備準備。

　　由于是遠程結合現場的方式來進行救援，難免要進行遠程溝通。遠程連線的工程師們，一直用騰訊會議來開會、現場指導、以及戰況匯報。

騰訊云數據中心硬件工程師，通過騰訊會議遠程展示操作細節。

　　在一些關鍵操作上，往往是幾十雙眼睛盯著會議直播畫面，因為任何失誤，都會帶來不可逆的后果。

　　7 天 7 夜里，他們隨時起會，騰訊會議也默默記錄著事態的進展，開遠程會議的賬號7*24 無中斷。各業務團隊通過騰訊會議，累積進行 766 次會議溝通。而這個會議號，也將作為這場戰斗的番號永久保留。

　　最擔心的事情發生！

　　好在前期進展很順利，但進行到最后三塊系統盤安裝時，團隊最擔心的事情還是發生了——新系統盤安裝后，數據硬盤出現掉線。

　　慶幸的是，經過排查，掛載不上的原因，是由于新加的系統盤，觸發了原來服務器中的硬件保護機制。

　　確定故障后，工程師們迅速施策，并對全部數據進行讀取。相比通常的數據鏡像進程，節省 70% 以上的時間。

　　這其中遇到的最大難題是，當肇事者把數百T數據刪除后（含備份數據），工程師們再在這么短的時間內恢復起來，其數據量之大、難度之高，遠超他們的經驗。

　　正式進入數據提取過程時，微盟的大文件未能提取出來，這意味想要獲得完整數據，就得進行拼接。

　　這好比整塊拼圖，被打散扔進大海，不僅得打撈出碎片，還得一片片重新拼圖。

　　并且，數據越大，拼接難度也越大。好在微盟的備份機制比較完整，數據類型也比較統一，所以很容易就能判斷出哪塊是開頭，拿著開頭去找剩下的塊，就會比較容易。

　　這其中，最大的一個文件，由 6 塊原始碎片組成。找到開頭后，騰訊云開始掃描其他相似的塊。運氣好的時候，打撈出來的數據，只有一塊和原始碎片相似（那肯定就是它了），運氣不好的時候 ，有二三十塊都是相似的。

　　所以，每進行一次拼接，都要把數據塊從頭到尾掃描一遍，目的就是驗證一下是否匹配。

　　掃描需要大量的計算力，為此騰訊云從上海機房臨時調撥 100 多臺服務器來支持掃描和運算。

　　團隊的心情，也好比坐過山車，每當一個難題被打敗，大家就覺得數據恢復有望，立馬就嗨起來。但是又出現問題時，心情又跌到谷底。

　　好在最后恢復了 100% 的數據，所有辛苦和付出都值得。

　　7 天 7 夜一百多個小時，這對于所有救援者的體力和意志力，都是巨大的考驗。而經此一役，騰訊云工程師的能力再次得到驗證，同時參與救援的工程師，也想借 CSDN 表達一些肺腑之言。

　　養兵千日，用兵一時

　　實際上，無論企業把業務部署在自有 IDC（Internet Data Center，互聯網數據中心），還是放在外部托管 IDC 里，只要暴露在公網下，都會存在威脅。

　　所以，建議企業從整體上梳理風險點，進行統籌和聯動防御，并對外部、內部、大數據等不同場景，準備出相應的解決方案。

　　如果企業已經上云，就要做好云主機的定期快照、云賬號權限管控，并對重要數據實施分級管理，同時還要做好加密，從而建立全生命周期的數據安全防護。

　　如果企業使用自建數據庫，建議把通過 Binlog 或其他備份文件進行恢復的詳細步驟制定成預案，并且定期演練，畢竟養兵千日，用兵一時。

　　對于開發者，可以多關注云計算領域的最新進展，包括云安全、數據防護、加密、惡意攻擊等知識，還可以多關注數據恢復的案例實踐。

　　上云的緊迫性和必要性

　　此外，沒上云的企業，也可以考慮上云。

　　以騰訊云硬盤來說，其采用分布式塊存儲架構，每個數據塊在可用區有個 3 副本，因此可以規避物理磁盤故障和宕機故障導致的數據損壞。

　　另外，通過云硬盤的快照技術，可實現數據“秒級”恢復到一小時內的狀態。

　　更重要的是，騰訊云還有數據安全產品，能對安全事件實現全面監控、告警和事后審計等功能。

　　而騰訊云堡壘機，其結合人工智能技術，可以為企業提供運維人員操作審計，還能對異常行為進行告警，進而防止內部數據泄密。

　　坦白講，過往很多企業，對于安全重視不足。而“微盟事件”依然在鳴叫的警鐘，正是為我們敲響。

　　人常說，吃一塹長一智，但最省心的，難道不是他人吃塹你長智嗎？可以說，微盟的天價學費，不只是為自己而交，更是為全行業而交。

　　最后，也為所有參與救援的工程師點贊，如果沒有他們，微盟的損失可能會更大。7 天 7 夜不間斷工作，他們像極了“救火隊員”。

　　每一次互聯網事故的修復，網友能看到的，是產品又能重新使用，看不到的則是工程師們在背后的廢寢忘食。

　　這位工程師，可能是你的家人，可能是你的同事，也可能是你的朋友......我們身邊從來不缺乏這樣的“救火隊員”，所以以后對程序員們少些調侃（禿頭），多些愛護吧！

總結

以上是生活随笔為你收集整理的腾讯云“抢救”微盟！766次在线会议、调拨100多台服务器、闹钟只定2H的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。