
隨著災難備份及業務連續性管理(BCM)工作的不斷加強,監管機構擬定和出臺了相關的指引和管理規范,各大銀行也都加強了災難備份中心的建設與完善。但是,與資金雄厚的四大行相比,城市商業銀行在災備方面略顯“猶豫”。
目前,城市商業銀行正處于變革期,每個銀行對災備方面的重視程度各不相同。災備中心不是一個簡單的信息系統項目,而是一個耗資龐大的系統工程,需要投入大量的人力、物力和財力。對于城市商業銀行這種小規模銀行來說,如何建設災備中心,在管理、技術、人員、組織等方面如何協調,缺乏直接的借鑒,從而帶來潛在的投入風險。再者,災備中心與其他項目相比投入較大,但見效卻很難快速體現。
災備主要是為小概率災難事件準備的,對于城市商業銀行而言,決策層在權衡企業發展的策略過程中,不會將其納入最重要的考慮因素。因此,種種因素嚴重困擾著城市商業銀行決策層,使他們很難痛下決心投入災難備份中心建設。
外包還是自建
面對困惑,城市商業銀行在災難備份方面將何去何從?從國際上的災備建設情況看,主要分為自建、共建和外包三種方式。
總體上看,“自建”具有投資金額巨大、建設周期長、技術與實施難度較大、管理與維護要求高、運營維護成本大等特點,比較適合風險控制要求高,資產規模大、技術與管理實力強的金融企業;“共建”具有投資少、技術與管理難度大、人員組織困難、責任不易界定、合作模式要求高等特點,很多城市商業銀行比較青睞這種方式;“外包”是銀行花錢購買第三方的服務,而不是自己企業內部員工完成災備任務。
這三種模式中,城市商業銀行區域性強、資產規模小、抗風險能力弱、人員素質與管理水平不高,如果讓其投入巨額資金自建災備中心,再花費許多時間和大量運維人員維護系統,長期處于待命狀態,對于城市商業銀行這種小規模銀行而言,似乎有些困難。
所以,大部分人認為共建和外包是城市商業銀行最理想的方式。現在,隨著人們意識的提升,各個城市商業銀行也在陸續開展業務連續性體系規劃和應急演練,災難備份咨詢與外包服務也更加深入規范,不少城市商業銀行甚至真正將災難備份提升到了業務連續性管理的高度。自建災備中心的城市商業銀行也有不少,呼和浩特市商業銀行(下簡稱呼市商行)就是其中之一。
呼和浩特商業銀行科技部總經理吳志堅說,“雖然我們銀行規模比較小,董事會、經營班子高層還是蠻重視IT建設的,雖然不可能一步達到國有商業銀行的標準,但我們在一步一步向這個方向努力。”
一舉兩得做災備
呼市商行成立于1999年,由于城市商業銀行是在城市信用社基礎上組建的,IT系統比較薄弱。呼市商行成立之初就著手IT系統的建設,基本上是從無到有的建設過程,但也是由于這個原因, IT系統在建設之初就和銀行業務結合得比較緊密,發展到現在,業務已和IT系統密不可分,所以領導層非常重視IT系統的建設。
2005年,《關于重要信息系統災難恢復指南》下達后,給行業用戶做災難恢復設計、建設、運維提供了一個操作性很強的參考思路。稍后,銀監會也對金融機構的信息風險提出《IT風險的管理指引》,同時對業務的連續性也提了很多要求。
IT系統建設八年來,呼市商行目前在運營上完全依賴IT系統,高管層包括董事會層面、經營管理層都對業務連續性比較擔心。2006年,正值呼市商行的一部分IT硬件設備需要升級,利用這個機會,他們在同城建立了一個災備中心。
在搭建災備中心前,呼市商行先找了一些服務商做了咨詢,參考了其他中小銀行和大銀行的做法,最后選擇了國內比較大的集成商進行整體的集成。
呼市商行有60家支行,數據全部集中在總行的數據中心。目前擁有多套小型機及服務器、存儲設備、網絡設備等,IT基礎設施具備了一定的規模。
選擇基于存儲和主機的同城容災方案,對于中小型銀行來講,還是比較實用的。一方面提升了現有業務能力,一方面還可以作為災備中心。采取兩套同步數據,即便有一些風險的話,也可以保證數據不丟失。
同時,原有的主機性能已經滿足不了新業務發展的需要,將原有主機替換成了IBM P系列的570I,使日終批處理時間得到有效的縮短,提高了效率。還對整個IT環境作了一個簡單的規劃,把多余的服務器都重新整合,使IT環境更加合理。
2007年,呼市商行升級了生產系統的主機,把舊的主機放到災備中心,做到了可以接管核心業務系統。2008年,在上一年建設的基礎上,增加了相應的主機設備,把生產系統中的核心業務、中間業務、現代化支付、銀行卡系統等全部接管,其他一些實時性要求不是很高的系統都采用冷備份的方式在備份中心部署。
兩個中心采用裸光纖直連,一旦生產中心出了問題,同城的災備中心就能接管主要的應用系統,隨時啟動應急預案。
吳志堅說:“硬件設備我們一直選用國際上主流的設備,當然要考慮我們這樣銀行的具體情況,并且延續一些自身的使用習慣。像IBM這樣比較大的國際廠商服務還是有保障的,硬件設備也比較穩定。”
下一步,BCM
這個災難備份中心坐落在一家支行的辦公樓里,作為生產數據中心的擴建改建工程的附加產品,災備中心建設的初衷是建一個應用級的容災數據中心,同時是生產中心的延伸,雖然物理上不在一個地點,但邏輯上可以當作一個整體考慮,滿足今后生產中心擴充的需要。
除了容災,這個備份中心也是一個開發測試中心,為新業務提供開發測試環境。
原來沒有建立災備中心之前,需要人為將前一日數據流帶備份異地存放,現在可以自動同步。
2006、2007年是主要保證數據的容災,2008年是應用級別的同城容災。下一步呼市商行計劃首先實現異地數據級別的容災,一點一點做,一點一點去投入,慢慢地完善自己的基礎設施。
業務連續性管理不僅是災備,還包括整體的規劃和流程管控。一旦發生災難,才能游刃有余。
“我們下一步要做的是梳理整個銀行IT系統運維流程和IT規劃,這么多年來,小銀行都面臨了重建設、輕管理的問題。由于自身業務發展的需要和監管的要求,每天要做的開發建設工作很多。尤其是2003年以后,銀行信息化的建設步伐進一步加快,同時監管部門的要求也越來越高。我們這樣的銀行面臨很多問題,包括信息孤島、項目管理、運維管理、IT審計、IT規劃、安全以及體系架構等問題都來了,感覺越來越難,只能一步一步往前走,然后請人梳理一下。往往干得時候還沒有標準,做到一定程度的時候,監管部門就會出臺一些政策和標準,然后就要根據這些進行改造和更新。這是一個非常漫長的摸索過程。” 吳志堅最后總結道。
CIO頻道人物視窗
CIO頻道方案案例庫
大數據建設方案案例庫
電子政務建設方案案例庫
互聯集成系統構建方案案例庫
商務智能建設方案案例庫
系統集成類軟件信息研發企業名錄