艾銻知識 |與時間賽跑：微盟的數據恢復為什么需要這么長時間

2020-03-07 19:47 作者：艾銻無限 瀏覽量：

   
 
我在上學的時候就看過這樣一個故事,是說豐田汽車公司生產線發生了事故,他的管理者透過提問的方式找到了這次事故的根本原因,那時候自己還不是教練,只是覺得這個管理者很厲害,可以透過提問就能找到問題的本源,以后如果自己走上了工作崗位也要向他學習.
 
但后來創業,經歷的事越來越多,發現這種追問方式有時有效,有時也是沒有效的,有效的是能解決當下的問題,無效的是問題還會經常重復性發生.當時并沒有領悟到問題的根源是什么,只是覺得可能自己的能力有限,后來學習了教練,開始給企業高管和CEO做教練時,逐漸發現這樣的提問為什么只能解決當下發生的問題,原因是管理者的焦點只放在這件事情的本身,而沒有真正關注到人,人是一切問題的根源.
   
 
讓我們來看一下關注事的提問和關注人的提問兩個版本到底有什么不同:
 
關注事的版本:
 
豐田汽車公司前副社長大野耐一，用5Why法追問生產線停機原因的案例最為典型。
 
一次，大野耐一發現生產線上的機器總是停轉，工人修過多次但仍不見好轉。他忍不住問工人：
 
一問：“為什么機器停了?”
答：“因為超過了負荷，保險絲就斷了。”
 
二問：“為什么超負荷呢?”
答：“因為軸承的潤滑不夠。”
 
三問：“為什么潤滑不夠?”
答：“因為潤滑泵吸不上油來。”
 
四問：“為什么吸不上油來?”
答：“因為油泵軸磨損、松動了。”
 
五問：“為什么磨損了呢?”
再答：“因為沒有安裝過濾器，混進了鐵屑等雜質。噢……我們這就去安裝。”
 
經過連續五次不停地問“為什么”, 工人找到問題的真正原因和解決方法。
 
關注人的版本:
 
一問：“發生了什么?”
答：“我們的機器修過了好多次都沒有解決問題,也不知道怎么了.”
 
二問：“如果你經常生病,也經常去醫院,但總還是生病,你會如何思考?”
答：“我可能會想是不是這家醫院有問題,或者這個醫生不行,但每次來的時候他都能給冶好,隔幾天又發生了狀況,這會讓我想想進入我身體的食物、水、空氣、還有我居住的環境等是否有問題,從醫院和自身兩個方面入手來思考這個問題吧.”
 
三問：“非常好的思考方式,這樣的思考如果放在這臺機器上,你會有什么發現?”
答：“我覺得也可以從兩個方面入手,一方面是否我們的修理能力有問題,我們可以找其他師傅來試試,還有一方面,不一定是我們能力問題,有可能是這臺機器與其它設備連接原因,可以檢查一下和這臺設備有關的所有方面,看是否能找到根本的原因.”
 
四問：“你這樣思考的好處是什么?”
答：“這樣思考就能讓我看清整個問題系統的原因,而不是緊盯在這個問題上,還能讓我打開更多的思路,這樣下次遇到類似問題的時候,我就能立刻找到問題的本質,而不是在同一個問題上不斷重復處理浪費時間.
 
五問：“還有什么呢?”
答：“這對我自身的能力也是極大的提高,也會讓我從一個修理工的思維變成一個管理工程師的思維,在未來我相信自己也能成為一名團隊的管理人員.”
 
六問：“好的非常棒,那你覺得這件事你什么時間能處理完呢?”
答：“立刻,馬上來系統全面的檢查,我相信一會就能找到根本原因,徹底的解決這個問題.”
 
七問：“好的,透過這次談話,你最大的學習是什么?”
答：“我體驗到自己內在是有智慧的,這讓我很驚訝,你并沒有告訴我怎么做,卻啟發了我的思維,讓我看見自己是有能力解決一切的問題,只是以前給了自己太多的限制,在修不好的時候,內心里就已經下了決定,這個機器就是壞的,就是有問題的,怎么修都不會修好的,基于結果我證明自己是對的,但如果我能像您啟發我的那樣,去想我要什么,去突破內在的限制,去打開自己的思維,去看見自己想要的未來,我相信,這對于我一生的成長都是至關重要的,謝謝您.”
 
八問：“好的,加油,期待你成長過程中的好消息.”
   
?透過上面的案例我們發現,關注人的提問,焦點始終放在這個人身上,這個人要什么,怎樣幫助他去獲得自己想要的,當他發生改變的時候,他的世界也就變了,他世界里遇到的問題也都不是問題了,我相信下次這個人在遇到類似這些問題時,他就會啟動自主的思考,從而一一化解.
 
關注事的提問者只能算是個管理者,這個管理者只是運用了提問的技巧,機械式的解決了當下遇到的問題.而關注人的提問,才是真正的教練,因為他未必了解機器的原理,但他了解人,并啟動了人的生命力,他知道人產生問題最大的根源是自我設限,所以很多時候我們的困難和挑戰,不是沒有能力去實現,而是沒有打開自己的能量,讓自己的能力釋放出來,才會讓我們陷入混沌和迷茫,我們的思維和內心的能量一旦打開,每個人都將無所不能.
 
無論是在生活中,還是在企業中,我們遇到的每個人都是創造力的天才,但很多時候就像掉進了泥潭中,有力卻無計可施,如果是這樣,記得找一位愿意關注你,關注你內在發生了什么,關注你想要成為一個什么樣的人,關注你渴望的是什么,關注你內心真正的想法的人,也許這個人就能幫你從泥潭中走出來,還能陪你一起箭步如飛的前行.
 
你的生命中有這樣的人嗎?

微盟“刪庫跑路“事件已經過去好幾天了，據悉，微盟的服務已經全部恢復，對于新用戶，已經能夠正常開始所有相關的業務活動了，但是對于老用戶，數據依然沒能全部恢復，根據其官網的信息，目前恢復了商

家賬戶和權益數據，截止到2月28日晚上，大約會有七成的數據完成恢復。

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

聊聊我的理解。

正式聊技術前，我想先說說今年羅胖的跨年演講《時間的朋友》，羅胖談到“躬身入局”讓我這個常年和IT技術打交道的”我輩中人“深有感觸，很多時候當我們站在局外的時候，感覺很多事情都不復雜，但是當你投

入其中之后，就會發現原來我們只是看到了冰山一角，很多事情要遠遠比你想的要復雜和困難。
 
舉個很形象例子，人們通常喜歡采摘低垂的果實，因為就大腦的反饋來講，低垂的果實是很容易采摘的，但是一個果實看起來低，它未必是真的低，很有可能是你離它太遠了，當你走進一些，你會發現它比你最

初看起來要高，當你再走進一些，你會發現根本高不可及。

這就像一座山，當你離它很遠的時候，會覺得山不高，只有當你親自走到山腳下，才會認識到自己更本不可能爬上去。這里我配了張圖，是我當年在珠穆朗瑪峰北坡登山大本營的照片，當時的海拔是5300米左

右，我的身后就是傳說中海拔8848的世界之巔珠穆朗瑪峰，你也許看起來覺得似乎不高啊，那是應為我離得還足夠遠。換句話說，當你覺得一件事情很簡單的時候，往往不是真的簡單，而很可能是因為你不懂。
 
回到這次微盟事件，也是一樣的道理，現代的大型互聯網產品，無論是toC的還是toB的，站在用戶的角度來看，使用都很簡單，但是其背后的架構復雜性就是屬于冰山下面的部分，其復雜程度會遠遠超過你的想

象，我就常說一句話“認知限制了你的想象力”。所以，我相信，此時此刻，微盟一定在冰山下面盡著自己最大的努力來推動數據早日恢復。

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

“不上云”：建立在自己的數據中心，完全自己管理硬件、軟件和數據，這是云平臺普及以前的主流實踐。在這種模式下，所有相關的數據庫高可用性，容量擴展，數據備份都要有自己非常專業的團隊(DBA團隊和

運維團隊)來管理和維護，對企業的技術要求是比較高的。

“全上云”：完全建立在云端環境之上。注意，這里的云可以是公有云，也可以是私有云。云廠商會提供全套的解決方案來支持高可用性，容量擴展和數據備份等特性。可以說，隨著云計算的普及以及泛數據庫類

服務( DBaaS)的快速發展，越來越多的新興企業會選擇這個方案。

“假上云”：這種方案是最奇葩的，有點像用Louis Vuitton的包來裝菜，但在行業內也不在少數，應該說這是一個過渡階段的產物。這種方式就是把云方案當做虛擬機來使用。這種方式和上面的“不上云”很類似，完

全沒有用好云端的優勢，只是把數據中心的機器移到了云端而已。云方案所能提供的容災、擴容等功能都被閹割了。

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

操作系統層面執行此類命令，數據庫數據也就不會被rm -rf /給刪掉。

如果刪除操作不是發生在操作系統的數據文件層面(備份通常是以文件形式存在的)，那么我們利用數據庫自身的特性來恢復誤刪數據的效率會大大提高。

同樣，面對數據的誤操作問題(比如，錯誤地批量update表中數據的某個字段)，“全上云”也比“不上云”和“假上云”有明顯的優勢。這個我是有切身經歷的，以前有個項目使用自建數據庫，由于某個DBA的誤操作，

在生產環境的數據庫上執行了一條沒有加where條件的update語句，直接造成競拍商品的出價記錄字段全部丟失，而后就是艱難的全量回滾和binlog重放，最終耗時4個多小時才恢復。后來同樣的誤操作發生在了

云端數據庫，回滾恢復的時間只花了幾分鐘。

從之前騰訊云對外的回應中，我們可以大概看到微盟被刪的數據不在騰訊云上，再結合目前數據恢復的速度來看，我們幾乎可以判定很大概率微盟沒有采用“全上云”的架構，或者是只有部分數據在云端，而且很

可能發生了比較極端的“rm -rf /*”和“fdisk”情況。那么在這種情況下，所有的主從庫文件，全量備份文件，增量備份文件以及binlog都一起丟失了。這里的技術挑戰主要在于傳統IT廠商如何進行磁盤恢復，已經不是

任何一個云廠商的技能點所在。

要在這種情況下恢復全部數據，可想而知技術難度是很大的。根據我的粗略理解，至少要跨過下面這些技術的檻。

獲取全量備份，如果存在異地的冷備或者災備，那是比較理想的情況，但是由于全量備份通常非常龐大，所以需要較長的時間完成文件的傳輸和校驗。如果沒有異地的全量備份可供使用，那么就必須采取更耗

時，而且不能保證一定100%全量成功的磁盤恢復手段。為什么說磁盤恢復會更加耗時，我一會兒來解釋。這里還有一個問題就是全量備份可能太“舊”了，這也給后面的恢復帶來了更多的時間成本。

獲取增量備份，很多時候增量備份沒有來得及做異地容災備份，所以很大概率要從磁盤恢復，這又是大量的時間消耗，而且同樣不能保證100%完全恢復。

獲取binlog，binlog是記錄所有數據庫表結構變更(例如CREATE、ALTER TABLE等)以及表數據修改(INSERT、UPDATE、DELETT等)的二進制日志文件，通常以索引文件(后綴為.index)和日志文件(后綴

為.00000*)的形式存在磁盤上，通常為了保證binlog記錄數據變更的準確性，一般都是采用row格式的binlog，因此文件尺寸也不小，而且文件個數也很多。

有了上面這些作為基本的輸入，才能開始數據庫層面的數據導入和恢復工作，這個過程也需要花費大量的時間，而且這是基于上述文件都可以100%得到為前提的，如果上述備份文件中出現數據問題，那由此帶

來的額外時間成本將會變得更大。

最后來說說磁盤文件的恢復。當我們對磁盤等存儲介質上的文件進行刪除操作，甚至是格式化操作(低級格式化除外)時，磁盤上的數據并沒有真正從磁盤上消失，而只是在文件分配表中標注了一下而已，位于數

據區的數據本身并沒有被立即抹掉。只要文件的數據區沒有被后面寫入的信息覆蓋，那么這些被刪除的文件就是可以恢復的，這就是磁盤文件在刪除后可以恢復的理論基礎。

但是數據庫的數據文件和備份文件往往很大，那么只要有個別數據區出現了重寫，那么恢復出來的文件就是不完整的，這個時候就需要人為介入來進行修正，這個工作量以及技術難度就會很大，有時還會需要借

助專用的儀器設備。在更復雜的情況下，還會采用數據雕刻技術(File Carving)，數據雕刻技術是數字取證研究中頻繁使用的一種文件恢復技術，它從表面上無差別的二進制數據集即原始磁盤映象中提取文件，而

不利用磁盤的文件系統類型。

除此之外，像微盟如此龐大的系統，各個垂直事業部可能都有各自的業務數據庫，這些數據庫甚至可能采用了不同的方案，這種架構上的異構性也會給恢復過程帶來極大的挑戰。另外，即使部分數據恢復完成之

后，也不能立即上線，而要等其他相關數據恢復，并且做好數據的的交叉校驗，確保數據的萬無一失，這些都需要大量的時間。

這些只是我能想到的一些情況，我站的也很遠，也是從旁觀者的維度在看問題，所以，我相信實際情況會比我所描述的更為復雜。我們還沒法對最終的恢復結果作出推斷，能夠做的只有等待