作者 | 馬超
出品 | 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老兵，筆者就以這個事件為切入點，來和大家聊聊大數據時代，災備建設與數據安全方面的新趨勢與新動向，提一些建設性意見。
數據治理之傷
其實數據安全的保護必須要以數據治理為前提，我們很少聽說微信、支付寶宕機，這背後不是靠高可用性來保證，而是靠整個服務體系的治理水平保證的。
我們使用分佈式架構對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場景。
可以說上述三類數據在流轉的過程中，相互之間是有比對關係的，如果數據治理的水平夠高，理清了各類數據彼此之間的一致性比對關係，那麼即使出現了刪庫的操作也不會造成如此長時間的中斷，不過從筆者目前掌握的情況來看，數據治理方面的工作並沒有引起業界足夠的重視。
災備建設之傷
在講災備體系之前，我們先來明確評價業務連續性的兩個重要指標：
RTO（Recovery Time Objective）
RTO是指災難發生後，從IT系統崩潰導致業務停頓開始，到IT系統完全恢復，業務恢復運營為止的這段時間長度。RTO用於衡量業務從停頓到恢復的所需時間。
RPO（Recovery Point Objective）
IT系統崩潰後，可以恢復到某個歷史時間點，從歷史時間點到災難發生的時間點的這段時間長度就稱為RPO。RPO用於衡量業務恢復所允許丟失的數據量。
簡單來講RTO就是災難發生後業務中斷的時間，RPO就是災難發生後數據丟失的數量。比如這次微盟的刪庫事件業務歷時七八天完全恢復，而數據全部找回，那麼其RTO就是七八天，RPO就是0。
一般來說目前比較流行的災備體系是至少建設三個數據中心，其中：
- 主中心：正常情況下全面提供業務服務。
- 同城中心：一般使用同步複製的方式來向同城災備中心傳輸數據，保證同城中心數據複本為最新，隨時可以接管業務，以保證RTO的指標。但是同城中心無法應對此類刪庫事件。
- 異地中心：一般使用延時異步複製（延時時間一般為30分鐘左右）的方式向異地災備中心傳輸數據，其中同步複製的好處是一旦主中心被人工破壞，那麼不會立刻涉及異地中心以保證RPO的指標。
一句話總結災備體系的最佳實踐就是兩地三中心；同城保證業務連續性，優先負責用戶體驗；異地保證數據連續性，確保企業生存底線。而針對行為及日誌等重要性等級不高的數據，一般採用異地磁帶備份的方式。具體方式如下：
不過從目前情況看不少企業尤其是創業型企業，都沒有百年老店的觀念，因此在異地中心的建設上投入還不夠，不過這樣的模式缺點也很明顯，一旦發生這種刪庫事件就影響就是致命的。
全面上雲，勢在必行
之前很多文章，分析了微盟的管理員權限過大以及涉事人員的法律負責問題，這些固然是造成此次事件的直接原因，但是筆者認為真正優秀的體系就是即使發生了惡性的操作事件也可以將風險降到最低。因此從這個角度來說，有以下幾點建議：
儘快進行HTAP轉型
目前的大數據時代的根本邏輯在於TP與AP的融合，而我們在上文也分析了數據治理完成後，數據最佳的使用實踐就是HTAP轉型。
全面上雲
據稱本次事件涉及微盟的核心繫統其實還並沒有完全上雲，這就極大提升了操作風險出現的可能性。而據筆者所瞭解到的情況，騰訊雲本身提供了相對比較完善的備份恢復功能，用戶直接使用既可。
重視異地中心的建設
由於異地中心採用的是延時複製技術，在出現數據惡意損壞時是可以保命的。因此類似於微盟這樣已經形成規模的企業，一定要按照標準建設異地數據中心，這樣才能保證企業在極端情況下的生存。
閱讀更多 CSDN程序人生 的文章
