過去的36個小時我們都在幹什麼哪？我們是不是還沒從“新冠”的陰影中清醒過來，依然沉寂在疫情的緊張和焦慮中？是不是好不容易熬到了週末，可以不用經歷比平日裡更加忙碌的“在線辦公”的日子哪？
然而就在這過去的36個小時中，有人甚至顧不得病毒的危害，全身心的投入到了另一場沒有硝煙的戰鬥中。這場戰鬥的殘酷程度，不亞於與新冠病毒搏鬥的場面。
這就是微盟團隊。可以說，在這36小時中，微盟與死神已經碰面，幾乎快去閻王那裡報道了。
事情還得從幾天前說起，就在幾天前，國內中小企業線上服務的領軍企業微盟忽然遭遇了一場“噩夢”，生產環境大批量的服務器無法響應，很多中小企業的服務頁面再也無法訪問了。包括集群環境也已經失效了。於是受其影響，千百萬家中小企業的在線服務全部停止服務。一天之內微盟的市值蒸發了14億，甚至瀕臨破產的邊緣。可以說，這是筆者有生以來聽說過的在國內發生的最為惡劣的網絡事件之一，直逼2007年的熊貓燒香病毒。
事情的起因竟是因為微盟內部的一名程序員“刪庫跑路”了。以往“刪庫跑路”的事件倒是屢見不鮮，可從來沒有哪次“刪庫跑路”事件像這次一樣對互聯網業造成了如此大的衝擊。至於這名程序員為什麼會這麼做，就讓我們等待一段時間以後的審訊結果吧。
不過幸運的是，就在昨夜，在騰訊與微盟共同的努力下，微盟的數據算是大致恢復了，大部分的中小企業得以繼續享受微盟的在線服務了。具體過程不再贅述，大家可以自行上網八卦一下。
筆者在這裡只是想反思一下，為什麼身為國內中小企業線上服務的領軍企業，竟會栽在這樣一個低級問題上哪？我想，微盟內部真正的管理問題估計不會公之於眾，只會吃一塹長一智，確保下次不會因為程序員刪庫跑路而栽倒了。
作為一個IT公司來說，往往有會很多運行數據，這些數據基本都保存在數據庫中，每時每刻都在發生著變化。而公司的各項業務均依賴於這些數據，所以數據就超越了程序成為了一個企業的“命根子”。程序沒了還可以重寫，運行的真實數據一旦沒了，可就一點兒辦法都沒有了。
幸好，為了防止這種情況發生，數據庫軟件都提供了數據備份和恢復機制，可以在數據庫發生故障或者數據被損壞時將數據恢復到故障前的版本，從而將用戶的損失降到最低。數據庫的備份機制有“自動”和“手動”兩種模式。“自動模式”就是給數據庫軟件設置一個自動備份策略，讓它根據策略自動定時進行備份。比如每月或者每週備份一次。因為數據備份耗費的空間和時間都較長，所以一般的企業因為沒有那麼多的存儲資源，都採用“整庫備份+定時增量備份”的模式。也就是在一段時間內只讓數據庫進行一次完整備份，然後每天(每週/每月)只備份發生變化的部分。這樣既可以保證新的數據儘可能的不丟失，又不至於每次備份都佔據大量的存儲空間。
微盟作為領軍企業，自然是有自己的一套備份機制的。可為什麼花了整整的36+個小時才把數據恢復回來哪？據筆者查閱相關資料，發現微盟並沒有採用傳統的數據庫恢復的方式恢復丟失的數據，而是走了另一條路——將被刪除文件還原回來。
這是什麼意思哪？我們都知道，計算機中的文件可以被刪除掉(也就是從回收站裡也被刪除了)，一旦被刪除掉，用戶也就無法再恢復文件了。所以只好自認倒黴了。
彆著急，這只是一般人的困惑。對於計算機“高手”來說，就沒有那麼棘手了。這要從計算機的數據存儲原理上來說。計算機存儲文件時，是採用“0”或者“1”來記錄信息的。具體來說，就是無論採用的是何種存儲介質，最終都會將數據轉換為“0”或者“1”存儲在存儲介質上。比如，對於數字5，可以用101來表示；對於數字59，可以用111011來表示。然後把這些0和1的組合按順序寫入到介質上。以光盤為例，空白的光盤可以看成是一個平整的面，上面沒有任何瑕疵。人們在這個面上劃定了規定數量的跑道。於是，計算機開始寫數據了。如果遇到了0，就不做處理；如果遇到了1，就往這個面上打個坑……以此類推。這還沒完，因為我怎麼知道這次寫的數據從哪個點兒開始打的，打到什麼位置結束？這些位置信息也得記錄下來，否則一旦有多次寫入操作，就不知道之前寫的數據從哪裡去讀了。這樣在讀取數據的時候，只需要首先讀取信息的起止位置(學名叫“文件分區表”)，找到起始位置後再按照順序讀取每個位置有沒有坑就可以把信息原樣讀取出來了。
而刪除文件是在做什麼操作哪？直覺上，我們會認為就把上面的過程反過來處理一遍好了，就是把是1的地方抹平(因為光盤被燒刻下去的部分無法再修復，所以一般的光盤是一次性寫入，無法恢復成初始狀態的)，這樣就把介質恢復成初始狀態了。
這種辦法一定是沒問題的，但這樣會產生一個問題——因為寫入過程是緩慢的，所以刪除過程依舊會如此漫長。於是有人就在想：既然寫入數據需要將數據的起始位置和終止位置記錄下來，並且標記為被佔用。那隻要把這些被佔用的區域標記為未佔用不就相當於把文件刪除掉了嗎？下次再寫入數據時反正要重新打坑，所以不用費時費力地把數據區域“抹平”了。聰明！於是不論什麼操作系統，都是這樣處理文件的刪除操作的。
這就給數據恢復帶來了一線生機。只需要挨個掃描一遍數據區域，把“有坑”的位置再提取一遍就可以了。沒錯！這就是數據恢復軟件所做的事情。當然，這樣做是有失敗的可能的。因為被刪除的區域會被操作系統再次利用，這樣一旦有新的數據寫入到這片區域裡，那麼恢復出來的數據也不再是原來的了。這樣對於一般的文字性的數據沒有太惡劣的影響(頂多經書不全麼)，但是對於數據庫文件來說，可就是致命的影響了，有可能導致恢復回來的整個文件都不能再被使用，就跟沒恢復出來一樣。
所以本次微盟採用的就是這種最“靠譜”的方式。這樣可以最大限度地恢復最近一次的數據。當然，這種操作也存在一定的提取失敗的風險，但至少可以嘗試一下。實在不行了，再去用最近一次的數據庫備份來恢復數據。
這就是微盟36個小時做的事情，可謂驚心動魄。幸好，恢復過程還算順利，據說大部分的內容都回來了。
回過頭來，微盟該反思一下，為什麼如此重要的數據，居然被一個小小的程序猿給輕鬆刪掉了。這裡面就牽扯到管理及授權機制的問題了。
一般說來，只要是上了一定規模的軟件公司或者機構，都是要由專人來負責數據庫維護的(學名叫“DBA”)，只有他才具有數據庫的最高權限，才有可能做到“刪庫跑路”。而能到這個位置的人，都是有公司“乾股”的，而且精神絕對不會不正常。所以不是有國仇家恨是不會“刪庫跑路”的。而普通的小程序猿們是沒有對整個數據庫的刪除權限的，頂多只能刪除自己有權限的個別數據庫。在IT行業，這叫數據的“分級管理”。就是什麼級別的人只能幹該級別對應的事，除非他盜取了DBA的賬戶和密碼。即便這樣，管理完善的公司或機構對於DBA賬戶的登錄位置也有著嚴格的要求，必須在指定的機器上才能登錄。這就進一步確保了數據庫的安全，即便DBA的賬戶及密碼不小心被盜了，也只能在領導或攝像頭的眼皮子底下才能刪庫。這樣第一時間就會被抓現行。
再退一步，即便數據庫真的被刪除了，還有上面提到的數據庫備份文件。還可以用這些文件來將數據恢復到最近的一次備份時間。據說，微盟這個程序猿好狠心，連所有的備份文件都刪除了。所以，微盟才迫不得已採用恢復被刪除文件的方式來恢復數據。
OMG！微盟的管理這是有多麼混亂呀！昨天正好聽馬未都老先生講述1983年馬王堆漢墓被盜的故事。說當時剛出土的文物被陳列在了博物館裡。有天夜裡，一名名叫“許反帝”的17歲“不良少年”惦記上了這批無價的國寶。於是偷偷潛入了博物館中，用大榔頭將博物館陳列櫃上面的玻璃一一砸碎，將自己覺得值錢的文物裝了麻袋中。砸櫃檯這一過程持續了很長時間居然都沒有人發現異常。裝滿了一麻袋文物後，這名少年居然堂而皇之地走到大門口，要求門衛給開門。門衛看都不看一眼，居然嫌棄他加班太晚了，就這麼著將罪犯和文物給放了出去。最後罪犯雖然被抓住了，但一件無價之寶——兩件直裾素紗襌衣中的一件被許母所毀，再也回不來了。試想如果在報警器等技術手段失靈而無法阻止竊賊以後，還是可以通過保安、巡視人員等管理手段進行彌補的，竊賊也不會得逞的。然而當時的管理意識就是這麼薄弱。
類似的事情還發生在巴黎聖母院，人類最愛的蒙娜麗莎也曾遭此劫難。
所以，在一個公司或者單位的內部，數據安全管理機制也是非常非常重要的。微盟在管理上跟馬王堆文物所在的博物館所犯的問題一樣，居然將DBA的權限開放給了普通的程序猿，並且沒有將數據庫的備份文件進行異地災備。於是一旦出現問題，就無法彌補了。還好，還有最後一線生機——磁盤被刪文件的恢復。不然，微盟恐怕真的就涼涼了。
筆者又想起了前年發生在國外一個互聯網巨頭公司的一個事，該公司使用MongoDB來存儲用戶的資料。可是MongoDB默認是不需要設置訪問密碼的。而該公司真的心大的沒有給MongoDB設置訪問密碼。於是有一天，該公司的MongoDB數據庫被一個小黑給黑掉了，數以萬計的客戶資料被洩露。這家公司也遭遇了自成立以來最大的危機。
我想，微盟的這次危機應該會給國內乃至世界的IT公司敲響了警鐘，讓大家重視數據的安全問題及管理機制。如果下次哪家公司還發生類似的事情，恐怕會被大家笑掉大牙的。
PS：吐槽一句，劉慈欣先生在史詩級科幻鉅著《三體》中早就把人類這個毛病淋漓盡致地揭露出來了，那就是人類終究是好了傷疤忘了疼的。所以，就讓我們拭目以待，看看下一家如此心大的公司會是誰吧。
歡迎您關注頭條本賬號，或者關注本人的微信公眾號greatgarden:
閱讀更多 greatfeather 的文章
