近日，中国工商银行信息科技部就6月23日工行系统故障事件（以下简称“6·23事件”）正式作出内部通报，这份通报称，工行数据中心（上海）主机系统出现故障，是由于IBM提供的主机DB2V10版本内存清理机制存在缺陷引发。

　　而在技术问题之外，工行本身的管理问题以及国内银行业信息系统落后的沉疴可能也是此次事件的诱因。

　　事件原因直指IBM：软件存在缺陷

　　6月28日上午，工行某直属一级分行信息科技部员工陆续收到内部通报邮件。该通报就6·23事件的情况及原因作了基本描述，但对事件影响范围、内部处理能力判断均语焉不详。

　　通报称，“6月23日上午，数据中心（上海）监控发现主机CPU利用率升高，经分析判断与6月23日凌晨实施的主机DB2数据库软件升级版本有关（从V9升级到V10），在紧急回退升级系统软件版本后系统运行恢复正常。”同时，工行总行信息科技部将该事件直接原因归为IBM公司提供的软件产品存在缺陷，并称这点“经IBM公司正式确认”。



　　工行就6·23事件做出的正式内部通报文件

　　6月23日上午，全国多地中国工商银行柜台、ATM、网银业务出现故障，持续近1个小时。作为服务2.92亿个人客户及400多万公司客户的全国金融服务巨头，工行此次故障波及北京、上海、广州、武汉、哈尔滨等多个大中型城市。

　　当日，工行将该事故对外模糊描述为：“中国工商银行部分地区因计算机系统升级原因造成柜面和电子渠道业务办理缓慢。”这也是迄今为止工行就6·23事件向用户发布的唯一公开解释。

　　IBM公开官方资料显示，工行与IBM的合作始于1997年，至今16年之久。针对通报中提及的“经IBM公司正式确认”，记者联系多位IBM相关负责人，但均未得到回应。

　　工行IT运维能力遭质疑

　　这份内部通报由一位不愿透露姓名的工行在职员工提供。该员工表示，自己并不太满意这份解释：“对灾难备份只字未提，有意将管理问题规避为技术问题。”

　　通报也提及了一些管理问题，但表述颇为模糊，通报称，“（数据中心上海）没有按照‘第一时间恢复生产’的要求采取果断措施及时进行回退，并且回退过程不坚决，耗时较长。”

　　银行的灾难备份系统，是指银行对本地数据中心的数据、业务系统、软硬件等资源进行同城或异地备份，以确保发生某些不可预测的灾难后，重要信息系统的数据安全的一种预防措施。

　　据中国银行业监督管理委员会（以下简称“银监会”）发布的《银行业金融机构信息系统风险管理指引》，银行业金融机构应制定信息系统应急预案，并定期演练、评审和修订；全国性数据中心要实现异地灾备。

　　日前，国内最大的灾难备份服务商万国数据CEO黄伟在接受福布斯中文网采访时表示，“银行的IT系统永远面临信息安全的挑战，但悲哀的是，银行在IT系统和灾难备份中不计成本，但遇到这样的大面积的安全问题依然无法在短时间内恢复系统。”他认为，长久以来国内银行的IT系统运作是在给这样的事件埋下伏笔，他最后指出，“在国内银行，IT系统的搭建更像是给上级和银监会看的‘政绩工程’。”

　　2008年，现任银监会副主席郭利根曾就多起国内银行信息科技风险事件发表讲话。他说，工行等国有银行是国内在IT技术和风险管控上都比较先进的银行，它们的问题频发，“充分暴露出我国银行业信息系统的脆弱性。”

　　他指出，基础建设滞后、软硬件及核心技术受制于人和系统管理粗放是当时银行业信息科技建设存在的主要问题，“特别是在业务连续性规划、业务恢复机制、风险化解和转移措施、技术恢复方案等方面，存在明显的‘短板’。”

　　整整五年过去，工行6 23事件证明了这些问题仍旧没有得到有效解决。

了解一下。

有个疑问，内存清理机制存在缺陷为何会造成cpu利用率的升高，按常理内存清理机制存在问题只会造成内存升高占用更多的页，不会造成cpu的增加。有可能是其它方面的原因，不知道当天是否进行过其它方面的变更，不过很有可能是升级造成的db2v9升级到v10确实存在隐患，我就遇到过应用系统在db2 v9上可以正常运行，但是到了v10上就出现问题，当时也查了很久，最后从官方重新下载了db2的几个补丁安装上才把问题解决，v10兼容性确实是存在问题的，希望以后多加注意。

来看看~

学习一下