作者簡介：茹炳晟，業界知名實戰派軟件質量和研發工程效能專家，中國商業聯合會互聯網應用技術委員會智庫專家，暢銷書《測試工程師全棧技術進階與實踐》的作者，InfoQ極客時間“軟件測試52講-從小工到專家的實戰心法”的專欄作者。現任Dell EMC中國研發集團資深架構師，歷任eBay中國研發中心測試基礎架構技術負責人，HP軟件中國研發中心資深架構師、性能測試專家，Alcatel-Lucent高級技術主管，Cisco中國研發中心資深工程師等職位，具有超過16年的軟件研發經驗和技術管理經驗。

微盟“刪庫跑路“事件已經過去好幾天了，據悉，微盟的服務已經全部恢復，對于新用戶，已經能夠正常開始所有相關的業務活動了，但是對于老用戶，數據依然沒能全部恢復，根據其官網的信息，目前恢復了商家賬戶和權益數據，截止到2月28日晚上，大約會有七成的數據完成恢復。

作為B端用戶以及廣大吃瓜群眾，都會有這樣的好奇，現在的云計算，容器化部署，彈性擴縮容，數據備份技術等技術已經非常先進了，為什么整個恢復周期還會需要這么長時間。那么今天我就從技術的維度來聊聊我的理解。

正式聊技術前，我想先說說今年羅胖的跨年演講《時間的朋友》，羅胖談到“躬身入局”讓我這個常年和IT技術打交道的”我輩中人“深有感觸，很多時候當我們站在局外的時候，感覺很多事情都不復雜，但是當你投入其中之后，就會發現原來我們只是看到了冰山一角，很多事情要遠遠比你想的要復雜和困難。

舉個很形象例子，人們通常喜歡采摘低垂的果實，因為就大腦的反饋來講，低垂的果實是很容易采摘的，但是一個果實看起來低，它未必是真的低，很有可能是你離它太遠了，當你走進一些，你會發現它比你最初看起來要高，當你再走進一些，你會發現根本高不可及。

這就像一座山，當你離它很遠的時候，會覺得山不高，只有當你親自走到山腳下，才會認識到自己更本不可能爬上去。這里我配了張圖，是我當年在珠穆朗瑪峰北坡登山大本營的照片，當時的海拔是5300米左右，我的身后就是傳說中海拔8848的世界之巔珠穆朗瑪峰，你也許看起來覺得似乎不高啊，那是應為我離得還足夠遠。換句話說，當你覺得一件事情很簡單的時候，往往不是真的簡單，而很可能是因為你不懂。

回到這次微盟事件，也是一樣的道理，現代的大型互聯網產品，無論是toC的還是toB的，站在用戶的角度來看，使用都很簡單，但是其背后的架構復雜性就是屬于冰山下面的部分，其復雜程度會遠遠超過你的想象，我就常說一句話“認知限制了你的想象力”。所以，我相信，此時此刻，微盟一定在冰山下面盡著自己最大的努力來推動數據早日恢復。

好了，接下來聊聊偏技術的話題。很顯然，目前微盟的主要問題是在數據庫的恢復上，由于官方并沒有公布具體的技術細節，我在網上也只找到一張非常頂層的架構示意圖，并沒有能獲得系統基礎架構，尤其是數據庫架構方面的詳細信息，所以只能從個人經驗的角度做一些可能的猜想，目的是想讓你能夠理解其中的技術復雜程度。

首先讓我們了解一下數據庫的運行環境，簡化來講主要有以下三種：

“不上云”：建立在自己的數據中心，完全自己管理硬件、軟件和數據，這是云平臺普及以前的主流實踐。在這種模式下，所有相關的數據庫高可用性，容量擴展，美國服務器租用，數據備份都要有自己非常專業的團隊（DBA團隊和運維團隊）來管理和維護，對企業的技術要求是比較高的。

“全上云”：完全建立在云端環境之上。注意，這里的云可以是公有云，也可以是私有云。云廠商會提供全套的解決方案來支持高可用性，容量擴展和數據備份等特性。可以說，隨著云計算的普及以及泛數據庫類服務（ DBaaS）的快速發展，越來越多的新興企業會選擇這個方案。

“假上云”：這種方案是最奇葩的，有點像用Louis Vuitton的包來裝菜，但在行業內也不在少數，應該說這是一個過渡階段的產物。這種方式就是把云方案當做虛擬機來使用。這種方式和上面的“不上云”很類似，完全沒有用好云端的優勢，只是把數據中心的機器移到了云端而已。云方案所能提供的容災、擴容等功能都被閹割了。

對于上面三種方式，“不上云”和“假上云”對于數據的風險相比“全上云”會更大，運維人員在“不上云”和“假上云”的情況下更容易有機會去執行類似“rm -rf /*”和“fdisk”類型的極端操作，而“全上云”，就比較難有機會從操作系統層面執行此類命令，數據庫數據也就不會被rm -rf /給刪掉。