工商銀行” 6.23事件”讓人們更加關注核心系統的高可用性，從報道看，起因于數據庫系統升級。如何化解類似風險呢？從技術上看應對是否得當？……
 
        帶著這樣的問題，我求教了SAP(73.02,-0.67,-0.91%)公司數據庫及技術平臺部售前總監宋一平先生。宋先生從事數據庫多年，參與并領導了Sybase數據庫在金融、電信、政府、能源交通等主要行業的方案討論、系統論證、產品配置、技術答標、評審、技術咨詢和項目鑒定等工作；主持過國內重大行業事件故障調查工作，行業實戰經驗豐富。2010年8月Sybase公司被SAP公司收購。
  
        非軟件升級事故
        就“6.23”事件而言，系統故障與軟件升級有關，由軟件升級帶來，但并不屬于軟件升級事故。故障是由軟件的Bug所造成的，按工行描述是由于 DB2 數據庫V10版本內存清理機制存在缺陷所引發。從過程來看，升級已在前一天晚上順利完成。新數據庫版本投入使用，由于自身Bug，造成了系統的故障。這與 突發硬件故障在性質上是完全一樣的。對于這種軟件的Bug并不是通過測試就可以完全解決的。


 



        宋一平表示：“對于軟件，目前還沒有方法來驗證其完全正確性，軟件行業有一句話，軟件總是有Bug，看你遇到遇不到。” 工商銀行很不幸，遇到了所謂“內存清理機制”Bug。由于事發時間接近，很容易被認為是一次軟件升級事故。試想一下，如果不是時間接近，還會有人將故障歸罪于軟件升級嗎？
 
        “對于關鍵業務系統，補丁不是隨便打的，需要進行壓力測試。”宋一平說。據他介紹系統升級通常需要進行壓力測試，因此類似工商銀行業務處理的峰 值數據一定是測試過，而且測試數據會更高一些，只有測試沒有問題，才會對系統進行升級，而且升級需要制定詳細的預案，選擇最適合的時間進行。
 
        宋一平表示，首先升級容災中心是一種較為穩妥的方式，使用穩定后，再投入生產中心使用，以求最大程度降低升級風險。但即使如此，生產中心實際環境畢竟還是存在著一定差別，因此無法完全避免類似事件的發生。
 
        容災中心切換之謎
        宋一平也曾參加過一些突發事件的應急處理。“對故障原因的查找會有一個時限，并不是無限期查找，通常也就是15分鐘，超過這個時限，就應該切換容災中心。”宋一平說。
 
        在“兩地三中心”進行系統升級的策略上，宋一平的意見是首先測試容災中心，然后升級生產中心。但也有意見認為，容災中心升級可以暫緩。不升級容災中心，會有一段時間數據不同步，但借助RAID、快照、冗余等硬件技術，以及數據庫日志等軟件手段，仍然可以防止數據丟失，業務風險性并不是太高。
 
        對于事故處理，工行采取了系統回退的做法。宋一平表示，在實際升級的案例中，系統回退采用并不多，但在升級前一定要做好系統回退的預案。系統回 退由于需要靠人工來進行恢復，其所花費的時間一定會長，它往往是升級失敗所采取的一種措施。針對類似“6.23事件”的偶發故障，如果不能在短時間內解 決，最好還是切換到容災中心。
 
        目前很多用戶擔心切換的問題，對切換容災中心的把握不高。實際上，銀行每月都需要進行切換的演練，應該可以解決切換的問題。
 
        “集中、分布”老話重提
        “6.23事件”造成廣泛影響是因為工行目前采取大集中模式，類似于把雞蛋放在同一個籃子里，一旦發生災難牽涉甚廣。如果采用分布式，也可以合理分擔風險。
 
        所謂合久必分，分久必合。銀行大集中模式已經實現了10多年，通過中央集權解決了權力分散所帶來的業務風險，避免類似“巴林銀行倒閉事件”的發生。但業務大集中也帶來的系統風險的大集中。
 
        以互聯網企業為代表，借助分布式集群以及總體框架設計，有效降低故障風險的影響范圍，提供整體業務連續性。這種架構設計會被銀行所采用嗎？
 
        本質上看，銀行是一個保守企業。另外，銀行有很多的傳統，也是包袱。這就決定了銀行沒有辦法輕裝上陣。“銀行推倒從來的代價非常高，也決定他們不會輕易嘗試采用分布式集群技術。”宋一平說。
 
        哲學上講，曲折前進，從量變到質變。類似“6.23”事件，銀行界已經有很多事故發生，當積累到一定程度，從新走向分布式也未可知。但當務之急，還是需要在容災中心建設使用中花功夫，不要讓容災中心成為應景的擺設。