工商银行” 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”事件，银行界已经有很多事故发生，当积累到一定程度，从新走向分布式也未可知。但当务之急，还是需要在容灾中心建设使用中花功夫，不要让容灾中心成为应景的摆设。
带着这样的问题，我求教了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”事件，银行界已经有很多事故发生，当积累到一定程度，从新走向分布式也未可知。但当务之急，还是需要在容灾中心建设使用中花功夫，不要让容灾中心成为应景的摆设。
