圈子外的同學可能覺得這個不應該很復雜，感覺不就是重裝一下系統(tǒng)嗎，數(shù)據(jù)庫不是都應該有備份嗎，直接恢復一下不就行了嗎。其實事情遠遠要比你想的復雜得多。很多時候，人常常會有一個認知上的偏差，對于一個自己沒有切身參與過的領域，我們會不自覺地對難度產(chǎn)生錯誤的判斷。這種所謂的迷之自信，是很難克服的。

這樣的例子很多，比如在看球賽的時候，有人就恨不得把電視砸了，總覺得某些球員怎么這么挫，但是真要是輪到你上場，你就能比他好嗎。再比如蘭州拉面，看起來也沒什么難度嘛，來回幾下子面就拉出來了，但要是換你上，你能拉出那碗面嗎。

其實，熟悉現(xiàn)代軟件架構和運維的同學一定知道，現(xiàn)在軟件的架構以及部署是極其復雜的，尤其在微服務大行其道的今天，每個微服務本身就是一個集群，微服務和微服務之間還有各種依賴關系，同時每個微服務都有可能會和數(shù)據(jù)庫打交道，光理清楚這些服務之間的依賴和配置就夠大家受的了。

更何況這次的微盟事件不是一次局部的更新和發(fā)布，而是幾乎整體架構的全局梳理，從這個意義上說，難度不亞于從頭搭建整個系統(tǒng)，更何況是在如此巨大的業(yè)務壓力和輿論壓力之下。

再來看看數(shù)據(jù)庫，根據(jù)目前官方的信息推測，這次的數(shù)據(jù)庫應該是在生產(chǎn)環(huán)境的本地庫發(fā)生了不可逆的刪除，否則不可能會需要這么長的時間。假定本地生產(chǎn)庫沒了，那唯一的方法就是借助遠程災備的全量備份庫來恢復，但這也會引發(fā)出一系列的問題，比如遠程庫容量大，需要大量的網(wǎng)絡傳輸時間。

再比如，增量備份的完整性欠缺，另外，還會出現(xiàn)由于近期的數(shù)據(jù)Scheme變更引發(fā)的備份數(shù)據(jù)兼容性問題等。這些都需要研發(fā)人員和運維人員的共同推進，這就會需要更多的時間……