宋一平老公 SAP公司宋一平:数据库升级的风险和化解方法

工商银行” 6.23事件”让人们更加关注核心系统的高可用性,从报道看,起因于数据库系统升级。如何化解类似风险呢?从技术上看应对是否得当?……

带着这样的问题,我求教了SAP公司数据库及技术平台部售前总监宋一平先生。宋先生从事数据库多年,参与并领导了Sybase数据库在金融、电信、政府、能源交通等主要行业的方案讨论、系统论证、产品配置、技术答标、评审、技术咨询和项目鉴定等工作;主持过国内重大行业事件故障调查工作,行业实战经验丰富。2010年8月Sybase公司被SAP公司收购。

SAP公司数据库及技术平台部售前总监宋一平

非软件升级事故

就“6.23”事件而言,系统故障与软件升级有关,由软件升级带来,但并不属于软件升级事故。故障是由软件的Bug所造成的,按工行描述是由于DB2 数据库V10版本内存清理机制存在缺陷所引发。从过程来看,升级已在前一天晚上顺利完成。新数据库版本投入使用,由于自身Bug,造成了系统的故障。这与突发硬件故障在性质上是完全一样的。对于这种软件的Bug并不是通过测试就可以完全解决的。

宋一平表示:“对于软件,目前还没有方法来验证其完全正确性,软件行业有一句话,软件总是有Bug,看你遇到遇不到。” 工商银行很不幸,遇到了所谓“内存清理机制”Bug。由于事发时间接近,很容易被认为是一次软件升级事故。试想一下,如果不是时间接近,还会有人将故障归罪于软件升级吗?

“对于关键业务系统,补丁不是随便打的,需要进行压力测试。”宋一平说。据他介绍系统升级通常需要进行压力测试,因此类似工商银行业务处理的峰值数据一定是测试过,而且测试数据会更高一些,只有测试没有问题,才会对系统进行升级,而且升级需要制定详细的预案,选择最适合的时间进行。

宋一平表示,首先升级容灾中心是一种较为稳妥的方式,使用稳定后,再投入生产中心使用,以求最大程度降低升级风险。但即使如此,生产中心实际环境毕竟还是存在着一定差别,因此无法完全避免类似事件的发生。

容灾中心切换之谜

宋一平也曾参加过一些突发事件的应急处理。“对故障原因的查找会有一个时限,并不是无限期查找,通常也就是15分钟,超过这个时限,就应该切换容灾中心。”宋一平说。

在“两地三中心”进行系统升级的策略上,宋一平的意见是首先测试容灾中心,然后升级生产中心。但也有意见认为,容灾中心升级可以暂缓。不升级容灾中心,会有一段时间数据不同步,但借助RAID、快照、冗余等硬件技术,以及数据库日志等软件手段,仍然可以防止数据丢失,业务风险性并不是太高。

对于事故处理,工行采取了系统回退的做法。宋一平表示,在实际升级的案例中,系统回退采用并不多,但在升级前一定要做好系统回退的预案。系统回退由于需要靠人工来进行恢复,其所花费的时间一定会长,它往往是升级失败所采取的一种措施。针对类似“6.23事件”的偶发故障,如果不能在短时间内解决,最好还是切换到容灾中心。

目前很多用户担心切换的问题,对切换容灾中心的把握不高。实际上,银行每月都需要进行切换的演练,应该可以解决切换的问题。

“集中、分布”老话重提

“6.23事件”造成广泛影响是因为工行目前采取大集中模式,类似于把鸡蛋放在同一个篮子里,一旦发生灾难牵涉甚广。如果采用分布式,也可以合理分担风险。

所谓合久必分,分久必合。银行大集中模式已经实现了10多年,通过中央集权解决了权力分散所带来的业务风险,避免类似“巴林银行倒闭事件”的发生。但业务大集中也带来的系统风险的大集中。

以互联网企业为代表,借助分布式集群以及总体框架设计,有效降低故障风险的影响范围,提供整体业务连续性。这种架构设计会被银行所采用吗?

本质上看,银行是一个保守企业。另外,银行有很多的传统,也是包袱。这就决定了银行没有办法轻装上阵。“银行推倒从来的代价非常高,也决定他们不会轻易尝试采用分布式集群技术。”宋一平说。

哲学上讲,曲折前进,从量变到质变。类似“6.23”事件,银行界已经有很多事故发生,当积累到一定程度,从新走向分布式也未可知。但当务之急,还是需要在容灾中心建设使用中花功夫,不要让容灾中心成为应景的摆设。