作者 | 馬超

責編 | 胡巍巍

出品 | CSDN（ID：CSDNnews）

3月1日晚間，微盟發布公告稱，截止到3月1日晚8點，在騰訊云團隊協助下，數據已經全面找回。

微盟表示，由于此次數據量規模非常大，為了保證數據一致性和線上體驗，將于3月2日凌晨2點進行系統上線演練，將于3月3日上午9點數據恢復正式上線。

針對事故給商家造成的影響，微盟表示，管理層深感自責和愧疚，準備了1.5億元人民幣賠付撥備金，其中公司承擔1億元，管理層承擔5000萬元。

還不知道事情經過的小伙伴，可以戳下圖。

事情經過，圖源微盟官方公眾號

從事故經過中可以看到從2月23日刪庫中斷事件，到3月1日的數據全面找回，再到3月3日的數據恢復整個事件持續了一周多的時間。

這對于微盟這樣體量的電商來說損失無疑是巨大的，股市市值的蒸發是一方面。更重要的是科技公司從本質上是經營數據的公司，而數據丟失事件與銀行金庫被盜事件從某種程度來說是同樣性質的事件，都會對當事公司的聲譽造成極大的影響。

做為一名多年戰斗在銀行業的IT老兵，筆者就以這個事件為切入點，來和大家聊聊大數據時代，災備建設與數據安全方面的新趨勢與新動向，提一些建設性意見。

1. 數據治理之傷

其實數據安全的保護必須要以數據治理為前提，我們很少聽說微信、支付寶宕機，這背后不是靠高可用性來保證，而是靠整個服務體系的治理水平保證的。

我們使用分布式架構對IOE進行替代，不是利用WPS替代Office的過程，而是根據數據的特點，找到能夠適應大數據時代的方法論。按照筆者的觀察，目前從治理角度，可以將數據分為以下三種類型：

應用數據

也就是交易類應用所產生的數據。為了滿足業務需要構建業務IT系統，隨著IT業務系統的不斷運行，大量應用數據就產生了，這些數據經過ETL加工進入數據倉庫，進行再處理，供業務應用。這些數據都是單一的關系型數據，數據量級是GB的。

用戶行為數據

隨著互聯網和電商的快速發展，大量人的操作行為和使用行為產生的數據，像谷歌、臉書等大數據互聯公司，都記錄人的形成產生的數據。上網行為，瀏覽行為，購買行為，評論行為，刷微博，做抖音等都可以產生大量數據。這些數據不再是單一的結構化數據，出現了大量文檔、音頻和視頻數據，數據量級是TB級的。

硬件日志數據

進入萬物互聯的時代之后，大量機器傳感器和IoT設備都會產生大量數據。這些設備7*24小時產生數據，數據格式也是多種多樣，有的是日志數據，有的是時序數據，有的是網格數據等等，數據量級是PB的。

從數據備份角度上講，上述數據的備份需求是不同的，如果混到一起那么快速恢復業務根本無從談起。

而從數據使用的角度上講，隨著海量的行為及日志類數據的出現，數據中心的架構將發生變化，整合TP與AP的HTAP時代既將到來。

比如目前一般銀行的系統都是以Oracle數據庫來進行交易操作，完成了整個流程性應用的內容，并產生應用數據數據，交易結束了，數據的生命周期也結束了。

要想把數據價值做二次表達，要每天做ETL，跑批作業，存到數據倉庫中，然后在數據倉庫中建模、挖掘、數據集市、ODS，一層一層地構建起數據倉庫報表。

如果還回答不出更細節、隱含的問題，比如非線性問題，還要把數據復制到SAS中做機器學習，再做統計的指標體系，去做進一步的挖掘。

數據要在這里搬動三次，復制三份冗余，還要管理數據一致性，每天數據中心運維的大量工作在做數據搬家。

現在，數據中心也開始要做一個融合性的計算框架。比如，現在AI要做Online訓練，淘寶推薦引擎，滴滴打車的路徑動態規劃都在做即時數據，數據閉環是數據基礎設施的一個很大的要求。BI和AI操作都要Online化，也就是AP操作要變成TP場景。

可以說上述三類數據在流轉的過程中，相互之間是有比對關系的，如果數據治理的水平夠高，理清了各類數據彼此之間的一致性比對關系，那么即使出現了刪庫的操作也不會造成如此長時間的中斷，不過從筆者目前掌握的情況來看，數據治理方面的工作并沒有引起業界足夠的重視。

2. 災備建設之傷

在講災備體系之前，我們先來明確評價業務連續性的兩個重要指標：

RTO（Recovery Time Objective）

RTO是指災難發生后，從IT系統崩潰導致業務停頓開始，到IT系統完全恢復，業務恢復運營為止的這段時間長度。RTO用于衡量業務從停頓到恢復的所需時間。

RPO（Recovery Point Objective）

IT系統崩潰后，可以恢復到某個歷史時間點，從歷史時間點到災難發生的時間點的這段時間長度就稱為RPO。RPO用于衡量業務恢復所允許丟失的數據量。

簡單來講RTO就是災難發生后業務中斷的時間，RPO就是災難發生后數據丟失的數量。比如這次微盟的刪庫事件業務歷時七八天完全恢復，而數據全部找回，那么其RTO就是七八天，RPO就是0。

一般來說目前比較流行的災備體系是至少建設三個數據中心，其中：

• 主中心：正常情況下全面提供業務服務。

• 同城中心：一般使用同步復制的方式來向同城災備中心傳輸數據，保證同城中心數據復本為最新，隨時可以接管業務，以保證RTO的指標。但是同城中心無法應對此類刪庫事件。

• 異地中心：一般使用延時異步復制（延時時間一般為30分鐘左右）的方式向異地災備中心傳輸數據，其中同步復制的好處是一旦主中心被人工破壞，那么不會立刻涉及異地中心以保證RPO的指標。

一句話總結災備體系的最佳實踐就是兩地三中心；同城保證業務連續性，優先負責用戶體驗；異地保證數據連續性，確保企業生存底線。而針對行為及日志等重要性等級不高的數據，一般采用異地磁帶備份的方式。具體方式如下：

不過從目前情況看不少企業尤其是創業型企業，都沒有百年老店的觀念，因此在異地中心的建設上投入還不夠，不過這樣的模式缺點也很明顯，一旦發生這種刪庫事件就影響就是致命的。

3. 全面上云，勢在必行

之前很多文章，分析了微盟的管理員權限過大以及涉事人員的法律負責問題，這些固然是造成此次事件的直接原因，但是筆者認為真正優秀的體系就是即使發生了惡性的操作事件也可以將風險降到最低。因此從這個角度來說，有以下幾點建議：

盡快進行HTAP轉型

目前的大數據時代的根本邏輯在于TP與AP的融合，而我們在上文也分析了數據治理完成后，數據最佳的使用實踐就是HTAP轉型。

全面上云

據稱本次事件涉及微盟的核心系統其實還并沒有完全上云，這就極大提升了操作風險出現的可能性。而據筆者所了解到的情況，騰訊云本身提供了相對比較完善的備份恢復功能，用戶直接使用既可。

重視異地中心的建設

由于異地中心采用的是延時復制技術，在出現數據惡意損壞時是可以保命的。因此類似于微盟這樣已經形成規模的企業，一定要按照標準建設異地數據中心，這樣才能保證企業在極端情況下的生存。

有道無術，術可成；有術無道，止于術

歡迎大家關注Java之道公眾號

好文章，我在看??

新人創作打卡挑戰賽發博客就能抽獎！定制產品紅包拿不停！

總結

以上是生活随笔為你收集整理的微盟耗时 145 个小时弥补删库，血亏 1.5 亿元！的全部內容，希望文章能夠幫你解決所遇到的問題。

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