多個機房光纜被挖斷，40%伺服器停服，26秒恢復？！
網際網路時代，伺服器機房可謂心臟，大型機房出故障是小概率事件。但即便如此，依然可能出現自然災害、斷電、光纜被挖斷等黑天鵝事件。
有人斗膽下了個戰書：如果多個機房的光纜同時被挖斷，40%的伺服器突然無法工作，結果會怎樣?
結果，居然還真的有人敢來應戰。此人便是螞蟻金服副CTO胡喜。
據報道，在9月20日的雲棲ATEC主論壇上，螞蟻金服副CTO胡喜在現場特別模擬了剪斷支付寶位於一個城市中兩個模擬機房的光纜。
一旦機房發生故障，會怎麼辦?
首先，設想一下伺服器機房如果發生了故障，我們的生活會出現什麼樣的變化?
斷網了，或許打不通網頁，或許撥不出電話，或許各種失聯……
有人說如果伺服器機房發生變化，在支付寶領域，遇到的最大困擾就是轉賬失敗。
轉賬失敗?付不了帳?買不了東東，這可腫麼辦?
螞蟻金服正是這樣做了這樣一次嘗試性實驗，此次實驗被差評君(ID:Chaping321)全程記錄。
現場在模擬支付寶轉賬的同時，程式員剪斷了位於杭州一個模擬機房的光纖，當光纖被剪斷後，這個模擬機房所負責區域的任何業務都不能處理。這就是轉賬失敗的原因。
螞蟻金服副CTO胡喜現場解釋，這是演習。
然而，在真實環境下，如果支付寶部署在兩個城市的兩個機房同時出問題，據官方宣稱，跑在這兩個機房上的支付寶賬戶，恢復正常的速度是分鐘級。精確地說，只需要26秒，模擬環境中的支付寶就能完全恢復正常。
分分鐘就能完全恢復，這完全顛覆了宕機停服幾個小時的傳統印象。
為什麼能在這麼短的時間，能讓故障排除，迅速恢復到正常工作的情況?
據悉，這是因為這一機房架構叫“三地五中心”，即在三座城市部署五個機房，一旦其中一個或兩個機房發生故障，其底層技術系統會將故障城市的流量全部切換到執行正常的機房，並且能做到資料保持一致且零丟失。
目前，網際網路和金融科技行業普遍採用的是“兩地三中心”部署架構，即在一個城市設兩個機房，在另一個城市設一個冷備機房。
而在這個實驗中，城市A的兩個機房是服務大眾的，不管是轉賬、繳費還是查賬全部都由這兩個機房提供服務，而且兩個機房是同步在處理資料且資料一致的。但在城市B的備份機房只是做備份而已，並不參與服務大眾這一活動。
一旦城市A的兩個機房被自然災害等毀壞就不能繼續對外服務，那隻能讓程式設計師熬夜去切換另一個城市的備份資料。但是由於B城市的機房常年沒有工作(提供服務)，整個機器都處於“冷凍人”的狀態，所以切換前還需要校驗資料，再預熱等等複雜的操作後才能讓服務再次暢通。
這就是為什麼很多App伺服器掛掉的時候，要花很久時間才能恢復的原因。
據悉，上圖是支付寶的城市級故障自動容災系統，是它支撐了26秒的災後恢復。
災備方案有備無患
目前來看，主要的資料備份方式如下：
定期磁帶備份：包括遠端磁帶庫、光碟庫備份和遠端關鍵資料+磁帶備份。
資料庫備份：就是在與主資料庫所在生產機相分離的備份機上建立主資料庫的一個拷貝。
網路資料：這種方式是對生產系統的資料庫資料和所需跟蹤的重要目標檔案的更新進行監控與跟蹤，並將更新日誌實時通過網路傳送到備份系統，備份系統則根據日誌對磁碟進行更新。
遠端映象：通過高速光纖通道線路和磁碟控制技術將映象磁碟延伸到遠離生產機的地方，映象磁碟資料與主磁碟資料完全一致，更新方式為同步或非同步。
這些措施能夠在系統發生故障後進行系統恢復，但是這些措施一般只能處理計算機單點故障，對區域性、毀滅性災難比如地震、火災等則束手無策，也不具備災難恢復能力。
災備場景涵蓋面廣，方案複雜，傳統資料中心容災方案存在CAPEX、OPEX高昂、資料同步策略複雜、災難恢復效果有限等問題。企業有必要採用多雲災備策略，以保證業務連續性及關鍵資料可靠性。我們就需要建立異地容災中心，做資料的遠端備份，在災難發生之後要確保原有的資料不會丟失或者遭到破壞。建立的異地容災中心可以簡單地把它理解成一個遠端的資料備份中心。
如今，資料中心相關行業越發重視災備方案，業界已有許多優秀的災備方案問世。7月，華為雲Multi cloud混合雲災備解決方案;8月，浪潮推出並展示了基於Openstack的“同城雙活、多雲資料中心災備解決方案”….期待，未來越來越多的災備方案，能讓資料更安全，使用者更安心