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

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

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

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

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

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

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

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

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

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

看上去，多活簡直簡直就是數(shù)據(jù)中心災(zāi)難恢復(fù)的救火隊長??！那到底支付寶的災(zāi)備建設(shè)是什么樣子的呢？多活的技術(shù)指標是什么？異地多活，異地是什么，多活又是幾活呢？支付寶在那兩個多小時的時間里又是怎樣進行異地多活的呢？

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

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

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

這種災(zāi)備級的能力使得用戶所有的業(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ù)媒體采訪談到其主導(dǎo)的數(shù)據(jù)中心異地多活項目說到，“淘寶因為能夠做到異地多活，并且流量是可以隨時切換的，所以對于我們來講，如果一地出現(xiàn)故障，不管是什么原因，最容易的解決方案，就是把這一地的流量全部切走。這樣可以把故障控制在一分鐘以內(nèi)，整個可用性是非常高的。”

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

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

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

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

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

其實，也有專業(yè)人士指出多活的挑戰(zhàn)性：在技術(shù)層面，不僅涉及到服務(wù)器/虛擬機之間的集群協(xié)同，還包括數(shù)據(jù)的復(fù)制與同步，更重要的是涉及到跨數(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è)，在他們的容災(zāi)演練中，兩個數(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)人士說到，“粗略得看支付寶并沒有切換異地容災(zāi)，而是恢復(fù)了網(wǎng)絡(luò)，雖然花的時間長了點。”

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