段子竟然成真了！微盟被刪庫的事情，估計大家都知道了吧，反正我的朋友圈已經被刷屏了。
不少同事還就這個事情進行了討論，討論那個運維是怎麼做的操作；討論微盟的IT架構缺失了哪些東西；討論他們在技術管理上存在什麼問題 .....
不過，無論如何，這個事情都已經發生了。
一方面，這會給微盟的業績營收帶來巨大的損失，被刪庫的這塊是微盟的SaaS業務，佔微盟整體利潤的50%以上。
另一方面，如果那個刪庫的運維，確實是主觀故意的話，還會面臨牢獄之災。
反正這是一個雙輸的事情，不論個人和公司之間發生了什麼，都不應該主觀故意的去做這件事情。
我估計很多同學，對這件事情是抱著一個吃瓜的態度在看的，畢竟事不關己高高掛起。不過，刪庫要真發生了，還真是個極難處理的事情，要在極限的壓力，極限的時間下，做極限的恢復操作。
2013 年的時候，我在做存儲系統，就遇到了類似的事情。
那時候，我們的存儲系統已經成功在全部門鋪開了，當時我們正準備著手進行第二輪的優化。相比前面階段，我們的壓力已經小了很多，因為已經完成了最關鍵的 kpi, 我們可以有規劃，有時間地慢慢做優化了。
那天晚上，我本著想 22 點就走的，想回去看部電影，畢竟太久沒看了。不過正要走的時候，被 leader 拉住，他跟我討論起了存儲冷備的問題。
熱備我們已經解決的不錯了，業務的可用性因此得到很大的提升，冷備是為了解決業務上的問題，比如有人不小心寫了個 bug 把數據給刪了，便可以從冷備的數據中恢復回來。
我們討論得很投入，方案也慢慢清晰了，不知不覺已經 23 點了，覺得太晚了，就約定明天再聊。
我關了顯示器，正準備離開的時候，隔壁團隊的 D 帶著新人 J 跑了過來，很慌張地樣子。
他拉住了我，對我說：“你們存儲系統的數據可以恢復嗎？”
我有點懵：“什麼意思？容災(熱備)出問題了嗎？”
D 答到：“不是，我們一個實習生的代碼有 bug , 把業務 G 的核心數據全刪了！”
“啊！” 我吃驚到。
剛好我 leader 也在，他走過來，“剛剛我們還在討論冷備的事情，就是為了應對這種情況的，不過還沒開始搞呢！” 他說到。
“那怎麼辦? 有沒有其它辦法可以恢復數據，要不整個業務就完蛋了，那是最核心的數據！” D驚慌地說到。
“讓我們想想 ！” 我轉過身就跟我的 leader 討論了起來。
討論了不到十分鐘，就想到一個辦法。
因為我們的存儲採用的是 BitCask 的模型，刪除操作只是在對應的數據裡面做了一個標記，沒有真正刪除，真實的刪除會在業務低峰期，數據回收的時候才進行。也就是說，只要執行數據回收之前，我們就有可能把數據撈出來做恢復。
但方案執行起來有很多需要注意的細節，而且有比較大風險，於是就具體的細節，我們又討論了二十來分鐘。
那時候時間已經是 00：30 了。
一切敲定後，我登錄上了他們業務的機器。看配置，數據回收的時間是凌晨3點，我趕緊將配置改到了上午12點，為接下來的恢復爭取時間。
我跟D解釋了一番，並告知他，可以從未被回收的舊文件裡面恢復數據，不過因為第一次遇到這種情況，我需要寫個新的工具把舊文件的數據撈出來，然後D那邊也需要配合寫一個工具，將讀出來的數據，從業務接口面寫回去。
D聽到，彷彿得到了拯救一般，連忙道謝！之後就一些細節，我們又進行了一番討論。
一切敲定，大家便各自忙了起來。我也立馬帶上我的耳機，吭哧吭哧寫起了代碼。所幸工具的邏輯不是特別複雜，不到一小時就寫完了。
我自己驗證了幾遍，可以正確的將數據從舊文件中讀出來。這時候，已經是凌晨 2 : 00 了。
我跑去了他們的座位，他們那邊的工具也準備好了。
於是我們拿了一臺機器，準備合起來跑一遍工具，做一次全流程的驗證。D執行了這個操作，看著黑底白字的屏幕上打出的一行行log , 我們都屏住了呼吸，生怕看到 “Error” 的字樣！
所幸，整個過程沒有任何報錯，我們又找了一箇舊工具做了一次數據讀取的驗證，以確保恢復的數據是正確的。
當看到最終結果的那一刻，我們終於鬆了一口氣，整個方案是可行的，可以正確的恢復數據。這時候，時間已經到了凌晨3點多。
此時放鬆的心，又緊繃了起來。
因為有數據的業務機器，有上百臺，我們必須在凌晨5點前完成全部數據的恢復，要不就會影響到用戶的正常訪問了。
我們又立馬投入到方案的討論中，很快敲定了，單機多進程，多機併發跑的方案。方案的執行，需要寫些併發的 shell 腳本。我們 3 人又趕忙跑到了運維大神A座位，他已經瞭解事情的前因後果，我們就執行方案跟他做了進一番的討論，敲定後，他立馬就寫起了shell 。
十分多種後，兩個 shell 腳本都搞定了，A做了一次驗證，一切符合預期。
在準備開跑前，我們又討論了異常的應對情況，需要監控的關鍵數據和曲線。這時候時間已經接近 4:00 了。
“時間不多了，跑吧！”， 我們異口同聲到。
D和他的實習生也跑回了座位去看業務監控，我在運維大神A旁邊看著他的操作和監控。
很快，一百多臺機器上的自動化腳本和工具全部跑了起來，我們來回切換，看機器的負載和業務的曲線，一切都在預期之中，５點前，數據終於全部被恢復了。
我們又趕忙找了幾個測試號，從用戶側做了一次完整的驗證，確保整個業務流程不受影響。一切符合預期！我們的心才終於安定了下來。看了看時間，已經是凌晨５多了 ......
那一晚上的經歷，到現在都記憶猶新。
這個故事，在公眾號以前的文章裡寫過了，之所以發出來，倒不是為了炒冷飯，而是微盟的這次事故，讓我又想起了這個事情。
我想，現在微盟負責恢復這部分數據和業務的程序員，也正在經歷著跟我們當時一樣的困境吧，極限的壓力，極限的時間，極限的操作！
而且因著疫情的原因，估計有部分人，不得不通過遠程來操作，也估計有的人已經通宵一整晚，甚至兩晚了。
說實話，真是很辛苦的！
希望這次的事故能夠儘快的被恢復過來，也希望微盟能儘早渡過難關，畢竟3000多名員工等著開飯呢。
最後，給總是衝在一線的救火工程師們，點個贊，他們都是逆境中的前行者 ！
閱讀更多 IT技術之家 的文章
