3月1日晚上10點半，已經停擺一週的微盟發出公告：“截止到3月1日晚8點，在騰訊雲團隊協助下，經過7*24小時的努力，我們資料已經全面找回。”微盟平臺上的商家和使用者們，終於鬆了口氣。

微盟在公眾號發出公告

作為在SaaS領域舉足輕重的服務提供商，微盟有300萬註冊使用者，以及超過7萬的SaaS付費使用者。在過去的一週中，所有微盟平臺上的使用者和商家都因為一場運維事故而被迫停滯了一週時間。對於他們來說，服務沒有恢復的每一分每一秒都是收入和使用者的損失，用“心急如焚”來形容恐怕有過之而無不及。

微盟在資料恢復公告的最後著重提出“最後再特別感謝騰訊雲團隊”，看到發出的公告，徐勇州最大的感受是，終於可以放心的睡個好覺了。

徐勇州是騰訊雲運維中心和客戶服務部門負責人，也是微盟這場搶救活動的總指揮，就是為了“全面找回資料”這個目標，他和騰訊雲的多位技術專家，聯合微盟團隊一起，整整奮戰了七天七夜。

時間倒回至23日下午7點，當時正在進行居家隔離的徐勇州，可能也想不到接下來的七天七夜，他和30多位同事會這樣度過——

騰訊雲監控中心發出告警，監測到微盟部署在黑石物理伺服器上的業務出現大面積無法響應的情況，同時微盟也通過騰訊雲售後和商務團隊同步了這一資訊。與此同時，微盟的商家服務群裡已經炸開了鍋。

團隊的第一反應是：難道騰訊雲黑石物理伺服器服務出現問題了？徐勇州和團隊很快排除了這種可能性：黑石物理伺服器叢集整體執行正常，獨獨微盟業務大範圍受到影響，可以推斷問題應該不是出在雲服務商這側，而是在微盟業務側。

騰訊雲安全團隊與微盟技術團隊隨即聯合排查。很快，溯源到微盟部署在自建MySQL資料庫上的核心業務資料，被微盟某運維人員用一種讓程式設計師聞風喪膽的Linux系統下檔案刪除命令，整體進行了不可逆的刪除。

業內經常調侃的程式設計師刪庫的事件，就如黑天鵝，毫無徵兆地發生在微盟身上，業務瞬間全線崩潰，數百萬商家無法開展業務。

事後外界的各種技術解讀，大多會提到“有沒有備份資料？為什麼不用備份資料快速還原？”外界並不清楚的是，備份資料也被一起刪除了。事情的嚴重程度遠超外界想象。

微盟立刻啟動緊急響應機制。由於內部相關技術能力缺乏，微盟也向騰訊雲緊急求援。

23日深夜，騰訊公司副Quattroporte、騰訊雲Quattroporte邱躍鵬接到團隊彙報，他指示團隊 “不管微盟的故障是什麼原因觸發，騰訊雲都要不惜代價全力支援”，並立刻決定由徐勇州組建一支30多人的技術團隊，與微盟一起研究制定生產環境和資料修復方案，同時協調了內部等多個部門做好技術協助和資源保障。

資料庫連同備份檔案被全部刪除，且資料體量達到數百T。這種情況，哪怕是專業的資料恢復公司，也只敢謹慎評估20%左右的修復預期。難度可想而知。

“這好像就是重症病人進了手術室”。徐勇州需要去完成一場搶救，雖然看起來救回來的希望不大，但 “病人的命就在你手上，客戶的生死存亡，我們不可能袖手旁觀”。

堅信資料肯定還在的是微盟CTO黃駿偉，他一再對徐勇州和騰訊雲技術團隊表示，“拜託你們一定要幫我們找回來”。

來自微盟的這種信任是責任，也是壓力。隨後七天七夜，徐勇州和技術團隊，與微盟一道，投入到了這場不眠不休的搶時間救資料戰鬥中，竭盡全力去完成這項“不可能完成的任務”。

23日晚，不眠之夜。徐勇州連夜帶領團隊與微盟方面進行解決方案的探討和制定。

任務的十萬火急，讓每個人睡覺都只敢定2個小時的鬧鐘，鬧鐘一響就接著戰鬥。24日下午，已經連軸工作30多個小時的徐勇州，才第一次短暫休息。微盟CTO黃駿偉，也是始終保持線上，與騰訊雲團隊溝通修復過程中的技術問題。

技術團隊很快對修復方案達成一致：鑑於資料庫伺服器上檔案數量多，型別複雜，檔案的提取和確認難度很大，而備份伺服器上檔案型別單一，資料集中，且微盟資料被刪後，硬碟沒有被二次寫入，理論上裡面可能存在相對完整的備份資料，團隊決定從備份伺服器入手，嘗試恢復資料。

他們很快面臨了第一個艱難的抉擇——

通常來說，資料修復的第一步是對源資料進行映象拷貝，以避免修復過程中源資料受損的風險。如果採用網路傳輸進行拷貝，以微盟的資料體量，光是資料拷貝過程就至少需要2天以上，會讓資料修復的時間進一步加長。“微盟和商家們都等不起。”

另一種慣用的處理方式是將原來伺服器上的硬碟拆裝後掛載到新伺服器上，以並行的方式進行“硬碟對拷”。這樣可以節約時間，但風險是一旦中途出現故障，源資料可能會因此完全丟失。“對於僅有一次這樣修復機會的微盟來說，這樣做風險太大。”

兩難之下，在徵得微盟同意後，團隊做了一個大膽的決定：越過映象拷貝的步驟，同時不將微盟的資料盤從原有伺服器上拔下來，而是將另外一塊系統盤安裝到原有伺服器上，通過新系統盤載入OS和資料恢復軟體，直接掃描提取資料盤中的“隱藏”資料。

這樣做的依據是，資料硬碟的健康度良好，且騰訊雲技術團隊有豐富的硬體處理經驗，有較大把握在源資料不損傷的前提下進行掃描。這相當於藉助一根體外供血管在體內完成這場手術，通過完美的技術，實現效率與完整性兼顧。

為了萬無一失，徐勇州還邀請了騰訊內部多位硬體專家通過騰訊會議進行遠端視訊指導。“所有的專家都線上，幾十雙眼睛，在螢幕前盯著現場工程師的每一個動作，以保證準確無誤。”

資料中心硬體工程師通過騰訊會議遠端展示操作細節

前期進展很順利，但在接近完成的時候，團隊最擔心的事還是發生了。25日凌晨6點鐘，徐勇州趁著工作的間隙打了個盹兒。可是很快，他就在半睡半醒之間，被電腦裡說什麼“載入不上”嚇到，一激靈就醒了。

驚醒徐勇州的，就是新系統盤安裝，在接近完成的時候，資料硬碟發出掉線警告。 “整個團隊的心都懸到了嗓子眼。畢竟這些資料可能就對應著微盟的百億市值，不能出任何閃失。”徐勇州說。慶幸的是，經過排查，原因是由於新加的系統盤觸發了原來伺服器中的硬體保護機制，不難解決。半小時的技術實施後，全部資料開始正常讀取。這個舉措為修復搶回了一天多的時間。值得一提的是，由於團隊只能遠端辦公，從第一天開始騰訊會議就成為了最高效的協同工具。在整個修復過程期中，騰訊會議處於7*24小時開啟狀態，從未間斷，各個業務團隊累計通過騰訊會議進行766次入會溝通。

小心翼翼的“手術”過後，更大的挑戰在於如何將資料完整地提取出來。

2月26日，資料恢復工作已經開展了三天三夜。當天中午，第一批次的資料拿到，匯入資料驗證正常。但他們很快發現，他們掃描出來的最新一份資料是截止到2月17日的資料拷貝，完整性尚不確定。

“也就是說，即便這份資料完整，那17號到23號當天的資料也是缺失的。”徐勇州解釋，“這個事情，好的一面是明確地告訴我們資料還在，恢復有希望。但是隻找回一部分資料意義不大，我們需要完整的資料。”

掃描仍在繼續嘗試，工程師們逐步發現了更多資料的蹤跡。到了週三深夜，新的問題再次出現：工程師們發現，現有的資料備份中，缺少大檔案資料，而這些大檔案極有可能是微盟最核心的業務資料。它們沒有被掃描出來。

“用絕望來形容當時的心情都不誇張，核心資料如果沒有，等於前期的工作都白做了，其他資料恢復了都沒意義。”徐勇州說。

事實上，此時掃描出的資料大約是微盟資料整體的30%左右，已經符合甚至超過了此前行業對此類事故恢復程度的預期。“這難道真的是一個完不成的任務？”

徐勇州和技術團隊不想放棄：核心資料找不回，影響的不止是微盟，還有那些商家的利益。“有一點希望都得試試看。”

徐勇州徹夜未眠。思量再三，決定兩條腿走路：一是嘗試對磁碟的每一塊（block）進行二次掃描；二是讓騰訊雲的作業系統團隊從OS底層入手，制定資料恢復方案PlanB，這需要極其龐大數量的嘗試和資料驗證，“方案一能成功是最理想的，方案二就意味著資料恢復的時間不確定，業務停擺，繼續失血。”

週四上午，第一臺伺服器的第一塊掃描成功，導回資料庫檢視是完整的。“方案一可行！大家信心一下子又起來了。”

從可行到成功，中間仍有艱難險阻。資料公司提取出來的單一的塊，從體積來看還是達不到微盟核心檔案的大小。這意味著，要獲得完整資料，需要進行資料“拼接”。

就好像整塊拼圖被打散扔進了大海里，一塊一塊打撈上來是第一步，拼接是第二步。不同的是，拼圖時還能夠根據形狀來判斷哪些可以放在下一塊，而拼接資料塊，根本無法通過肉眼識別，只能靠一塊塊去掃描，尋找相似度高的拼接到一起，再重新掃描看斷點是否能重合。

慶幸的是微盟的備份機制較為完備，資料的覆蓋度和完整性檢查等工作非常細緻。徐勇州發現，檔案型別只有一種，那麼就能很容易判斷出哪塊是開頭，拿著開頭去找剩下的塊，把工作量從“N*N”降低到“1*N”。

但“1*N”的工作量也不小。最大的一個檔案，由7塊碎片組成。找到開頭以後，工程師開始掃描其他有相似性的塊。運氣好的時候，相似度可能只有一塊，運氣不好的時候 ，有二三十塊。每進行一次拼接，都需要把資料塊從頭到尾掃描一遍，驗證是否匹配。這需要大量的計算力。為了加快掃描和驗證，騰訊雲伺服器團隊還臨時從上海機房調撥了100多臺伺服器進行算力支援。

徐勇州已經不記得這樣的“打撈、拼接、掃描、驗證，重新打撈、拼接、掃描、驗證”進行了多少次，只記得每一次都是四五個小時的煎熬。“大家每隔一會兒就在騰訊會議上吼，好了沒，好了沒，快看看！”終於，一塊又一塊的資料被拼接出來，核心資料逐漸被修復。“太不容易了，心情真的跟過山車一樣。”2月28日，深夜，資料修復勝利在望。

雖然最初大家並不敢斷言資料能否修復，隨著兩邊團隊的共同攻堅，大家關注的焦點逐漸變成資料能不能做到100%的修復。

然而，即便是方法論經過了驗證，但就像寫程式一樣，在一些細微的地方總會有一些意想不到的bug出現。

2月29日凌晨，恢復到最後一臺伺服器時，徐勇州和技術團隊盤查發現，前面找回來的那些資料只有整體資料量的70%-80%。按照前面核心資料恢復的方法推演，如果邏輯成立的話，此時恢復的資料應該是100%。

剩下的資料去哪了？到底是哪個環節出了問題？“我們的目標是要做100分，哪怕失掉5分，對一個商家來說可能就是全部。”徐勇州和團隊連夜把所有的資料又重新盤點了一遍，把驗證的邏輯再推導了一遍：掃描了多少？提取了多少？哪些校驗過？哪些沒有？又是一夜未眠。3月1日凌晨，終於在另一個的區段中，被遺漏的資料被“打撈”了出來。原來有一部分資料在提取時因為環境等各種原因被疏忽了，在把所有的資料都彙總整理和對齊後，很快找到了對應的那段未提取區段，然後又是進行緊張的“打撈、拼接、掃描、驗證”，但這時的團隊已經是技術嫻熟，胸有成竹。

3月1日晚，微盟釋出公告稱，資料已經全面找回。同時宣佈基礎設施全力上雲。

根據微盟公告，微盟將採取以下措施提升對資料安全的保障：首先在許可權管理方面，使用騰訊雲CAM許可權系統進行雲資源管理，嚴格執行分級授權和最小集權制度，對高危險動作執行二次授權制度；使用騰訊雲堡壘機替換自建堡壘機，進行細粒度許可權分級和授權管理。

其次，在北京、上海、南京等地區建立全備份的冷備系統架構，藉助騰訊雲IaaS的底層服務能力，建立高可用的同城雙活架構；所有非結構化資料使用騰訊COS物件儲存系統進行歸檔儲存並啟用多異地複製功能。

最後，藉助騰訊雲資料庫MySQL的資料高可用和安全體系，逐步放棄自建資料庫服務，遷移到騰訊雲資料庫（CDB）,提升資料庫跨可用區和易地災備的能力，同時，將原來合作的黑石1.0物理機全面升級黑石2.0，全面使用雲主機。

在徐勇州看來，微盟事故的發生對其他企業的資料安全保護也敲響了警鐘，資料安全事件背後折射出的是，僅僅依靠單點防護難以達到真正的安全防護效果，而構建基於全生命週期的安全防護成為必然選擇。

微盟公告發出以後，騰訊雲技術團隊在微信群裡收到了微盟團隊的集體致謝。那個全程見證事件進展的超長騰訊會議的會議號，被團隊提議作為一個永久的番號保留。