支付寶昨日發(fā)生大面積訪問和交易故障的事件令人記憶猶新，在網(wǎng)商銀行即將開業(yè)之際，對螞蟻金服來說，無疑迎來當頭一棒。因為網(wǎng)商銀行聲稱是中國第一家完全跑在“云”上的銀行，這也是螞蟻金融服務(wù)集團積極推動的旗艦業(yè)務(wù)。

事件一出，支付寶官方稱因市政施工導致杭州市某地光纜被挖斷，使支付寶一個主要機房被影響，從而出現(xiàn)訪問故障。

超過2個小時后，支付寶恢復服務(wù)，并稱其異地多活的系統(tǒng)架構(gòu)在此次意外中發(fā)揮了巨大作用。

對于此類解釋，遭來了眾多業(yè)內(nèi)專業(yè)人士的質(zhì)疑。在我們的采訪中，不論是IT提供商、企業(yè)用戶還是分析師，他們都認為，“由鏈路（所謂的光纖被挖斷，戲稱挖掘機事件）原因?qū)е碌木W(wǎng)絡(luò)中斷在大部分IT事故中并不算嚴重的。”

為什么？因為數(shù)據(jù)中心的災備能力，這是很多大型企業(yè)構(gòu)建的IT架構(gòu)的一部分。對于支付寶來說，更不例外，尤其支付寶還堅稱其異地多活發(fā)揮作用。

不說全業(yè)務(wù)恢復，支付寶最起碼的做到正常登錄總沒問題吧？

一位長期觀察企業(yè)級IT的資深媒體人直言，“RTO(Recovery Time Objective，恢復時間目標)超過兩個小時，還能說得上多活，簡直笑話。”

這和有觀點認為支付寶事件是中國金融史上首次完全意義的災難恢復案例觀點相左。

“多活”如此引人爭議，我們就來看一看它的來龍去脈。

我們來說所謂多活本身的概念，一是多中心之間地位均等，正常模式下協(xié)同工作，并行的為業(yè)務(wù)訪問提供服務(wù)；二是在一個數(shù)據(jù)中心發(fā)生故障或災難的情況下，其他數(shù)據(jù)中心可以正常運行并對關(guān)鍵業(yè)務(wù)或全部業(yè)務(wù)實現(xiàn)接管，達到互為備份的效果，實現(xiàn)用戶的“故障無感知”。

看上去，多活簡直簡直就是數(shù)據(jù)中心災難恢復的救火隊長?。∧堑降字Ц秾毜臑膫浣ㄔO(shè)是什么樣子的呢？多活的技術(shù)指標是什么？異地多活，異地是什么，多活又是幾活呢？支付寶在那兩個多小時的時間里又是怎樣進行異地多活的呢？

我們迫切想知道這些問題的答案，因為這些答案最能說明真相。

不過我們在對支付寶的采訪中，對方并沒有給出回復。

在早前我們對某IT提供商的采訪中說到，“雙活已經(jīng)部署在了其大型客戶的IT架構(gòu)中，它實現(xiàn)的是一鍵配置，一鍵容災，在分鐘內(nèi)實現(xiàn)。這不是一個概念，而是客戶的實際運行狀況，兩個數(shù)據(jù)中心融合在一起，并行和雙活使用。”

這種災備級的能力使得用戶所有的業(yè)務(wù)系統(tǒng)在兩個或多個數(shù)據(jù)中心同時運行，同時為用戶提供服務(wù)，當某個數(shù)據(jù)中心的單個或整個應(yīng)用系統(tǒng)出現(xiàn)問題時，都可以由另一個數(shù)據(jù)中心的對應(yīng)系統(tǒng)來接管全部業(yè)務(wù)，實現(xiàn)持續(xù)的服務(wù)提供，對用戶來講甚至感知不到業(yè)務(wù)系統(tǒng)的跨數(shù)據(jù)中心切換。

阿里巴巴技術(shù)保障部研究員畢玄在今年四月份接受某技術(shù)媒體采訪談到其主導的數(shù)據(jù)中心異地多活項目說到，“淘寶因為能夠做到異地多活，并且流量是可以隨時切換的，所以對于我們來講，如果一地出現(xiàn)故障，不管是什么原因，最容易的解決方案，就是把這一地的流量全部切走。這樣可以把故障控制在一分鐘以內(nèi)，整個可用性是非常高的。”

當然這是在進行中的項目，也就是其定的標準目標是這樣的，現(xiàn)在看來，這還差點距離。

其實關(guān)于災備，國務(wù)院信息化工作辦公室在2007年7月將領(lǐng)導編制的《重要信息系統(tǒng)災難恢復指南》正式升級成為國家標準《信息系統(tǒng)災難恢復規(guī)范》（GB/T 20988-2007 ）。這是中國災難備份與恢復行業(yè)的第一個國家標準，并于2007年11月1日開始正式實施，并作為各行業(yè)進行災備建設(shè)的重要參考性文件。

《規(guī)范》在附錄A對災難恢復能力作了等級劃分，共6級：第1級 基本支持，第2級 備用場地支持，第3級 電子傳輸和部分設(shè)備支持，第4級 電子傳輸及完整設(shè)備支持，第5級 實時數(shù)據(jù)傳輸及完整設(shè)備支持，第6級 數(shù)據(jù)零丟失和遠程集群支持。

并指出信息系統(tǒng)災難恢復能力等級與恢復時間目標（RTO）和恢復點目標（RPO）的對應(yīng)關(guān)系。

因為沒有得到支付寶的答案，我們不知道支付寶的標準是什么，當然對照此表你可以參考支付寶的災難恢復能力等級。

其實，也有專業(yè)人士指出多活的挑戰(zhàn)性：在技術(shù)層面，不僅涉及到服務(wù)器/虛擬機之間的集群協(xié)同，還包括數(shù)據(jù)的復制與同步，更重要的是涉及到跨數(shù)據(jù)中心的網(wǎng)絡(luò)互聯(lián)互通及分支/Internet用戶對DC的訪問，因此網(wǎng)絡(luò)對業(yè)務(wù)的感知能力及對流量的牽引成為方案設(shè)計與部署的重中之重。此外，網(wǎng)絡(luò)訪問控制策略的遷移、服務(wù)器網(wǎng)關(guān)及數(shù)據(jù)同步對網(wǎng)絡(luò)帶寬與服務(wù)質(zhì)量的要求、IP地址設(shè)置、路由發(fā)布控制、網(wǎng)關(guān)設(shè)計、防火墻狀態(tài)會話、流量路徑規(guī)劃及迂回控制等技術(shù)都是設(shè)計上必須要考慮和解決的問題。

反正，我們看下來，多活的最高境界這樣子的：如果中斷了一個數(shù)據(jù)中心，其他的數(shù)據(jù)中心仍可獨立響應(yīng)業(yè)務(wù)，對用戶來說業(yè)務(wù)切換是無感知的。

再有一個參考，去年筆者曾采訪過某IT大型企業(yè)，在他們的容災演練中，兩個數(shù)據(jù)中心相隔1300公里，2小時成功切換關(guān)鍵業(yè)務(wù)系統(tǒng)，4小時切換全部業(yè)務(wù)系統(tǒng)，細分下來共包括500多個IT系統(tǒng)，整個切換沒有任何數(shù)據(jù)丟失和不一致。當然那不是雙活也不是多活，作為非技術(shù)專業(yè)人士我不知道這對支付寶事件有什么參考意義。

看了著這么多多活，又加上兩個小時，有人直言，“支付寶這次的故障絕非光纖問題那么簡單，而是多活切換的技術(shù)不過關(guān)。”

當然也有業(yè)內(nèi)人士說到，“粗略得看支付寶并沒有切換異地容災，而是恢復了網(wǎng)絡(luò)，雖然花的時間長了點。”

真相是什么呢，現(xiàn)在不得而知。不過支付寶的反應(yīng)相對于1月19日微信出現(xiàn)短暫癱瘓時的就是不告訴你已經(jīng)很有進步了。