這段時間，儲存圈內對寧夏銀行7月系統癱瘓事件討論熱烈，為什麼作為在IT基礎架構和系統建設都相對嚴謹和嚴格的銀行會頻頻出現當機等問題。可能大家還記得2013年6月工行和中國銀行的兩次事件。
“6月23日，中國工商銀行系統癱瘓導致全國多地工行系統櫃面取款、ATM、網銀等無法辦理。24日，中國銀行系統也短暫癱瘓，一時間金融業錢荒，銀行股價暴跌，金融市場流動性緊張。”
對於去年發生的銀行系統問題，網友討論也比較多，歸結起來，還是系統維護方面紕漏。
對於今年寧夏銀行的系統癱瘓事件，官方訊息如下：
銀行二部（2014）187號正式發全國檔案，對寧夏銀行事故的描述大致如下2014年7月1日，寧夏銀行核心系統資料庫出現故障，導致該行（含異地分支機構）存取款、轉賬支付、借記卡、網上銀行、ATM和POS業務全部中斷。
經初步分析，在季末結算業務量較大的情況下，因備份系統異常導致備份儲存磁碟讀寫處理嚴重延時，備份與主儲存資料不一致，在採取中斷資料備份錄影操作後，造成生產資料庫損壞並當機。因寧夏銀行應急恢復處置機制嚴重缺失，導致系統恢復工作進展緩慢，直至7月3日5點40分核心系統才恢復服務，業務系統中斷長達37小時40分鐘，其間完全依靠手工辦理業務。
該事件的根本原因是在於該行安全生產意思薄弱、應急管理體系缺失、應急處置過程混亂。該行核心系統資料庫版本嚴重老化，且2007年至今未購買核心資料庫的維保服務，核心系統長期缺乏維護，事故發生後，無法獲得系統供應商及時技術支援。系統恢復過程中，缺乏應急預案和準備，長時間無法實施有效處置，導致業務恢復緩慢，對銀行運營產生較為嚴重影響。
對於這個事件的發生，網上論壇有網友開始懷疑當時在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系統之後，只是萬里長征走了第一步，後面更為重要的是長期的執行與維護，包括核心系統、資料庫的後續維保等，因此，這也是為什麼某國內著名廠商捨得將裝置免費送給銀行測試一年多，希望得到銀行採購後長期使用，只有使用之後才有價值，一旦使用了，後續的服務收費才是真金白銀。
因此，不管是什麼情況，不管遇到什麼變化，只有長期的服務品質不變，長期保持演練時的心態不變，即便遇到突發情況，也會比想象的情況要好一些。