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


 



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