3月1日晚上10點半，已經停擺一週的微盟發出公告：“截止到3月1日晚8點，在騰訊雲團隊協助下，經過7*24小時的努力，我們數據已經全面找回。”微盟平臺上的商家和用戶們，終於鬆了口氣。
作為在SaaS領域舉足輕重的服務提供商，微盟有300萬註冊用戶，以及超過7萬的SaaS付費用戶。
在過去的一週中，所有微盟平臺上的用戶和商家都因為一場運維事故而被迫停滯了一週時間。對於他們來說，服務沒有恢復的每一分每一秒都是收入和用戶的損失，用“心急如焚”來形容恐怕有過之而無不及。
微盟在數據恢復公告的最後著重提出“最後再特別感謝騰訊雲團隊”，看到發出的公告，徐勇州最大的感受是，終於可以放心的睡個好覺了。
徐勇州是騰訊雲運維中心和客戶服務部門負責人，也是微盟這場搶救活動的總指揮，就是為了“全面找回數據”這個目標，他和騰訊雲的多位技術專家，聯合微盟團隊一起，整整奮戰了七天七夜。
“不可能完成的任務”
時間倒回至23日下午7點，當時正在進行居家隔離的徐勇州，可能也想不到接下來的七天七夜，他和30多位同事會這樣度過——
騰訊雲監控中心發出告警，監測到微盟部署在黑石物理服務器上的業務出現大面積無法響應的情況，同時微盟也通過騰訊雲售後和商務團隊同步了這一信息。與此同時，微盟的商家服務群裡已經炸開了鍋。
團隊的第一反應是：難道騰訊雲黑石物理服務器服務出現問題了？徐勇州和團隊很快排除了這種可能性：黑石物理服務器集群整體運行正常，獨獨微盟業務大範圍受到影響，可以推斷問題應該不是出在雲服務商這側，而是在微盟業務側。
事故發生之初，微盟在官網發出公告
騰訊雲安全團隊與微盟技術團隊隨即聯合排查。很快，溯源到微盟部署在自建MySQL數據庫上的核心業務數據，被微盟某運維人員用一種讓程序員聞風喪膽的Linux系統下文件刪除命令，整體進行了不可逆的刪除。
業內經常調侃的程序員刪庫的事件，就如黑天鵝，毫無徵兆地發生在微盟身上，業務瞬間全線崩潰，數百萬商家無法開展業務。
事後外界的各種技術解讀，大多會提到“有沒有備份數據？為什麼不用備份數據快速還原？”外界並不清楚的是，備份數據也被一起刪除了。事情的嚴重程度遠超外界想象。
微盟立刻啟動緊急響應機制。由於內部相關技術能力缺乏，微盟也向騰訊雲緊急求援。
23日深夜，騰訊公司副總裁、騰訊雲總裁邱躍鵬接到團隊彙報，他指示團隊 “不管微盟的故障是什麼原因觸發，騰訊雲都要不惜代價全力支持” ，並立刻決定由徐勇州組建一支30多人的技術團隊，與微盟一起研究制定生產環境和數據修復方案，同時協調了內部等多個部門做好技術協助和資源保障。
數據庫連同備份文件被全部刪除，且數據體量達到數百T。這種情況，哪怕是專業的數據恢復公司，也只敢謹慎評估20%左右的修復預期。難度可想而知。
“這好像就是重症病人進了手術室”。徐勇州需要去完成一場搶救，雖然看起來救回來的希望不大，但 “病人的命就在你手上，客戶的生死存亡，我們不可能袖手旁觀”。
堅信數據肯定還在的是微盟CTO黃駿偉，他一再對徐勇州和騰訊雲技術團隊表示，“拜託你們一定要幫我們找回來”。
來自微盟的這種信任是責任，也是壓力。隨後七天七夜，徐勇州和技術團隊，與微盟一道，投入到了這場不眠不休的搶時間救數據戰鬥中，竭盡全力去完成這項“不可能完成的任務”。
一場168小時的騰訊會議
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分，在雲上迎接重生的微盟”
雖然最初大家並不敢斷言數據能否修復，隨著兩邊團隊的共同攻堅，大家關注的焦點逐漸變成數據能不能做到100%的修復。
然而，即便是方法論經過了驗證，但就像寫程序一樣，在一些細微的地方總會有一些意想不到的bug出現。
2月29日凌晨，恢復到最後一臺服務器時，徐勇州和技術團隊盤查發現，前面找回來的那些數據只有整體數據量的70%-80%。按照前面核心數據恢復的方法推演，如果邏輯成立的話，此時恢復的數據應該是100%。
剩下的數據去哪了？到底是哪個環節出了問題？“我們的目標是要做100分，哪怕失掉5分，對一個商家來說可能就是全部。”徐勇州和團隊連夜把所有的數據又重新盤點了一遍，把驗證的邏輯再推導了一遍：掃描了多少？提取了多少？哪些校驗過？哪些沒有？
又是一夜未眠。3月1日凌晨，終於在另一個的區段中，被遺漏的數據被“打撈”了出來。原來有一部分數據在提取時因為環境等各種原因被疏忽了，在把所有的數據都彙總整理和對齊後，很快找到了對應的那段未提取區段，然後又是進行緊張的“打撈、拼接、掃描、驗證”，但這時的團隊已經是技術嫻熟，胸有成竹。
3月1日晚，微盟發佈公告稱，數據已經全面找回。同時宣佈基礎設施全力上雲。
根據微盟公告，微盟將採取以下措施提升對數據安全的保障：首先在權限管理方面，使用騰訊雲CAM權限系統進行雲資源管理，嚴格執行分級授權和最小集權制度，對高危險動作執行二次授權制度；使用騰訊雲堡壘機替換自建堡壘機，進行細粒度許可權分級和授權管理。
其次，在北京、上海、南京等地區建立全備份的冷備系統架構，藉助騰訊雲IaaS的底層服務能力，建立高可用的同城雙活架構；所有非結構化數據使用騰訊COS對象存儲系統進行歸檔保存並啟用多異地複製功能。
最後，藉助騰訊雲數據庫MySQL的數據高可用和安全體系，逐步放棄自建數據庫服務，遷移到騰訊雲數據庫（CDB）,提升數據庫跨可用區和易地災備的能力，同時，將原來合作的黑石1.0物理機全面升級黑石2.0，全面使用雲主機。
在徐勇州看來，微盟事故的發生對其他企業的數據安全保護也敲響了警鐘，數據安全事件背後折射出的是，僅僅依靠單點防護難以達到真正的安全防護效果，而構建基於全生命週期的安全防護成為必然選擇。
微盟公告發出以後，騰訊雲技術團隊在微信群裡收到了微盟團隊的集體致謝。那個全程見證事件進展的超長騰訊會議的會議號，被團隊提議作為一個永久的番號保留。
閱讀更多 騰訊技術工程 的文章
