這段時間，存儲圈內對寧夏銀行7月系統癱瘓事件討論熱烈，為什么作為在IT基礎架構和系統建設都相對嚴謹和嚴格的銀行會頻頻出現宕機等問題。可能大家還記得2013年6月工行和中國銀行的兩次事件。

“6月23日，中國工商銀行系統癱瘓導致全國多地工行系統柜面取款、ATM、網銀等無法辦理。24日，中國銀行系統也短暫癱瘓，一時間金融業錢荒，銀行股價暴跌，金融市場流動性緊張。”

對于去年發生的銀行系統問題，網友討論也比較多，歸結起來，還是系統維護方面紕漏。

對于今年寧夏銀行的系統癱瘓事件，官方消息如下：

對于這個事件的發生，網上論壇有網友開始懷疑當時在2010年進行的高大上的寧夏銀行800公里災備演練，當時號稱區域性商業銀行的第一次。

查 閱資料，回憶當時演練現場，時任寧夏銀行信息技術部總經理的王春表示，隨著區域性商業銀行的跨省發展，實施災難備份系統已經勢在必行，寧夏銀現在實施成功 之后，實現了寧夏銀行所提出的“提升業務連續性，提升業務管理水平”的戰略目標，做到了核心系統的災難恢復的“全范圍覆蓋”。

其中演練主要包括了兩種“突發情況”：數據庫系統癱瘓和數據中心發生火災——前者模擬寧夏銀行生產中心數據庫系統發生崩潰癱瘓的嚴重故障，測試根據需要啟動應急響應流程，進行本地的數據庫系統恢復;后者模擬生產中心發生大火，測試根據應急流程進行從銀川到西安的異地切換。

整場演練全部在真實的生產環境進行，步驟銜接流暢，而且恢復速度讓在場觀摩人員無不驚嘆，兩個場景的演練時間加起來不過10分鐘：第一場數據庫癱瘓演練，4分鐘成功恢復完成;第二場火災演練，6分鐘系統異地切換成功。

當時的IT環境是IBM AIX UNIX、Informix、EMC DMX800。

以上是寧夏銀行2010年災備演練情況的存儲在線當時報道摘要，在整個演練過程中，飛康CDP起到了舉足輕重的作用。為此，網友在論壇上評論說，“停止備份 系統，竟然會導致主數據庫損壞，看來FalconStor CDP ，不靠譜啊。”也有網友評論道：“系統維護沒有跟上，再好的方案也會有問題。”

對此，阿明認為：寧夏銀行本次事件發生的根本應該更多歸咎在系統維護上，很多時候，大型企業或銀行做過周密的預案或災備演練之后，就放松了對系統的整體維 護，這是發生問題的主要原因所在。為此，寧夏銀行官方表態也是“2007年至今未購買核心數據庫的維保服務，核心系統長期缺乏維護，事故發生后，無法獲得 系統供應商及時技術支持。”(要知道，數據庫廠商很牛叉，這是圈內人士有目共睹的，既然長期不交“保護費”，自然得讓你痛一下，痛定思痛之后，你就得乖乖上交數據庫“保護費”了。)

說完今年寧夏銀行這次事件之后，我們再回看一下去年工行、中行出現的系統問題，當時CSDN的夏夢竹同學找到了一位叫jaccc的IT顧問，這位顧問的看法分析很透徹，也很中肯，對當前寧夏銀行出現的系統問題也有借鑒意義，大家不妨“溫故知新”：

為什么IT系統會出問題?

1) 現代IT系統非常復雜，當系統大到一定的程度，總會有失控的狀況。世界上就從來都沒有過沒錯誤的復雜程序，問題只在于這個錯誤你有沒有碰上而已。銀行的系 統是由很多不同軟硬件廠商的產品拼在一起運作，復雜程度遠超過普通家用電腦，這么簡單的家用電腦還會死機呢....而且系統復雜到一定程度，就不是人多或 者錢多就能完全解決問題的了，推薦看看《人月神話》。

2)要盡量不出問題，要錢，很多錢(比如中型銀行建設一個過得去的容災系統要上億)。但出問題只是“有可能”，花的錢可是實實在在的。換了你是領導，你也不會無限制的向里面投錢。

3)穩定運行的最好的辦法之一是不對系統進行改造。由于有新的業務要求，系統確實要不停的升級，很多銀行每周都在升級，每次變動對系統的穩定運行都是一個挑戰。你每天走路有時候還會摔倒，只要一動作，就有出錯的可能，這就是科學。

為什么會大面積的出現問題?

因為三個字：大集中。最早之前，銀行系統還沒聯網，一出問題只是某個區或者某個市。最近十多年銀行業都在搞大集中：五大行除了中國銀行之外的四家都已經完成了大集中。

為什么這種故障好像越來越多了?

以前沒有微博沒有微信，只要你不是倒霉的用戶就不會知道出過問題。我要不是上微博也不知道工行出這么大的事。以前沒有網銀沒有淘寶，你半夜不會買東西刷卡。用行話來說就是以前沒那么多7*24的需求(一周7天，一天24小時運行)。

為什么沒有應急預案或者應急預案沒有起作用?

與電信運營商，政府行業，普通企業相比，銀行是中國IT業中IT基礎最好，最嚴謹的行業。比如有的銀行還要求廠商維護人員不能操作，只能銀行員工操作。

大的變更一定會有預案，甚至換個硬盤，改個IP這種做過幾百次的操作都會有預案。但預案與真實一般都有相當差距。上面已經提到系統非常復雜，可能出現的問題如果真全部寫下來，可能有幾百幾千分支。而且，系統的故障并不會根據你的應急預案來發生。

只靠應急預案真解決問題的概率比拿著《泡妞指南》泡到美眉的幾率還低，應急預案的最重要的作用是應付上級監管，根據應急預案搭好可能需要的應急軟硬件環境，大致理清概要思路，以及鍛煉團隊。真有復雜問題，還是靠牛人現場解決的多。

平心而論，工行的IT能力和運維水平在四大行里面不是第一就是第二了(不同的省份略有不同)。

為什么要停幾個小時這么久?

先 說定位問題的時間：從發現問題上報到IT信息中心(或者在監控系統發現問題)，IT中心的人開始查系統，定位故障原因，如果定位不清還要找相關的軟硬件人 員到場或者遠程網絡支持(基于安全原因，銀行大部分都不能遠程網絡查看系統，維護人員到數據中心也需要時間，如果還堵車.....)，找出問題的根源，一 小時算超快的了。類似你莫名高燒，到底是哪個器官出問題，去醫院做檢查做判斷總需要時間吧?

解決問題就更不好說了，其實和大家的電腦一樣，往往重啟是 最有效的方法，但很多業務系統部分出現問題是不能重啟的(可能會影響別的業務系統)。至今國外各大廠商的標準維護合同，絕大部分都沒有承諾修復時間。

 根據手頭的一份略過時的銀監會突發事件應急管理規范：一個省停業6個小時以上才算I級特別重大突發事件，3小時是II級，半小時以上是III級。以管窺 豹，落葉知秋，幾小時真不算什么。

不是說有容災和備份嗎?為啥不快速切過去就好了?

這是一個很常見的誤解：出了故障的時候，有備份系統和容災系統就可以很快恢復業務。一懷愁緒，幾年離索，錯，錯，錯。

先 說備份系統，常規備份系統是不能運行業務程序的：備份一般只是把數據保存多一份或者幾份，一般是在丟數據的時候才用來恢復，而且恢復的時間很多都在幾小時 以上。類似大家手頭只有一個avi文件，沒有播放軟件也沒法看啊，只不過銀行的“播放軟件”要架設起來就復雜了.....

再 說容災系統，強調一個連很多IT人都不清楚的事實：銀行容災系統不會輕易啟用整體切換!前面已經說了，IT系統已經這么復雜了，容災系統相當于再復制一 套，復雜性增加了不止2倍。切換起來是非常麻煩，非常傷筋動骨，驚動非常多人力物力，不是碰到大災大難(比如地震，機房著火，恐怖分子爆炸之類)不會進行 切換。

當然平時會進行容災切換演練，但一般不會拿核心系統來真實切換，原因是有風險。以前也出現過華東某省級行(還 是某省某運營商?記不太清楚了)切換到了容災中心后切不回生產中心的悲催慘劇。最近西北某地農信社成功的把核心生產切到了容災系統上，比較不簡單，不過這 畢竟是獨立法人的小銀行，大行不是這么個玩法。

這么說吧，迄今為止，五千年來，四大行的核心容災系統都沒出現過需要 兩地切換的重大災難的場景，和準備買iPhone6的腎一樣，有兩個，沒切過，但時刻準備著切....其實個人不太靠譜的猜想，就算停個三五天，各大行都 不會愿意全業務切換，今天這種停幾小時的算個毛有啥好切的，趕快修好系統就是了。

另外，看到有不少評論說“沒人敢擔 風險切換到災備節點上”。其實一般是這樣的：建好容災系統之后往往都會寫一套DRP(災難恢復計劃)或者BCP(業務連續性計劃)，就是容災系統啟動的流 程方案，里面會規定好什么場景下由什么人拍板切換到災備中心，一般不會真出問題才臨時來拍腦袋來想，(當然臨時調整也是有可能的)，也不是誰說切換就誰去 背黑鍋。

當然，大部分的小故障會通過雙機切換，快速重啟部分應用的等方式解決。但很快解決了，你們就意識不了其實已經出過故障了嘛，是不是 有點人擇原理的味道?......但總有無法快速解決的問題。補充一句，當然業界有很多新技術已經把備份高可用災備等揉在一起了，但銀行業應用還不多，這 里就不展開了。

升級要失敗，快速回退不就好了嘛?

一個常見的誤會：升級不成功馬上回退啊。這是很理想的情形，現實的情形是這樣的：

1)技術上無法回退。我舉個例子，你從winxp升級到win7，升到一半，藍屏了，或者報某個文件包找不到了。你會回退嗎?

2)回退的風險更大，升級過程中很多配置，軟硬件都改掉了，改不回來了，或者耗費的時間比繼續升級更大。

3)硬著頭皮沖過去就算超了時間的還能找個理由掩飾一下，回退了就確定升級失敗了，下次繼續升級的政治壓力會很大。

所以實際情況中，除非可以很干凈利落的回退，而且實在升級無法成功，才會回退。真的升級切割出問題會進行回退的不超過5%。

周日到底出什么問題了?

在 中國，無論出現什么IT系統問題，對外宣稱總是電腦系統升級。我以前就有個變態的習慣在處理故障中途如果有空(等別人處理或者等系統回滾什么的時候)就打 呼叫中心電話，聽那些美眉怎么解釋系統用不了了。清一色的，100%的，毫無例外都說是電腦系統升級。當我再問為什么大白天升級啊?為什么之前不通知我們 客戶啊?這時候就能體現呼叫中心的培訓能力的差距了。

回到今天這事，別說我現在還沒去八卦，就算知道了也不可能公開 說，這是職業操守的問題。而且有的故障的真相是查不出來的(你知道你每次生病的確切原因嗎?)，有的故障是查出來但不能實說(一般故障分析報告書很快就能 到競爭對手手中)。這種情況下，怎么去寫故障分析報告，是一門藝術：真相不重要，達到目的才重要。這個目的有可能是大事化小，有可能是小事化大，水深著 呢。

這幾天微信圈里，繼續在討論寧夏銀行系統問題，據圈內人士透露，銀監會正在查這件事情， IBM和飛康都在等待結果。相信事實的真相不久后將浮出水面。

阿明點評：銀 行系統相對復雜，銀行IT建設也相對要求嚴格與苛刻，在建設好了IT系統之后，只是萬里長征走了第一步，后面更為重要的是長期的運行與維護，包括核心系 統、數據庫的后續維保等，因此，這也是為什么某國內著名廠商舍得將設備免費送給銀行測試一年多，希望得到銀行采購后長期使用，只有使用之后才有價值，一旦 使用了，后續的服務收費才是真金白銀。

因此，不管是什么情況，不管遇到什么變化，只有長期的服務品質不變，長期保持演練時的心態不變，即便遇到突發情況，也會比想象的情況要好一些。