# 以史为鉴：宁夏银行7月系统瘫痪最新解析

- URL: https://wuming.si/blog/755/
- Author: Aaron
- Published: 2014-08-10
- Language: zh-Hans
- Categories: Uncategorized
- Originally published at: http://blog.wo.ai/archives/755

![0](http://blog.wo.ai/wp-content/plugins/wp-o-matic/cache/eaf9c84860_dcfcd07e645d245babe887e5e2daa016.jpg)

这段时间，存储圈内对宁夏银行7月系统瘫痪事件讨论热烈，为什么作为在IT基础架构和系统建设都相对严谨和严格的银行会频频出现宕机等问题。可能大家还记得2013年6月工行和中国银行的两次事件。

“6月23日，中国工商银行系统瘫痪导致全国多地工行系统柜面取款、ATM、网银等无法办理。24日，中国银行系统也短暂瘫痪，一时间金融业钱荒，银行股价暴跌，金融市场流动性紧张。”

对于去年发生的银行系统问题，网友讨论也比较多，归结起来，还是系统维护方面纰漏。

对于今年宁夏银行的系统瘫痪事件，官方消息如下：

银行二部（2014）187号正式发全国文件，对宁夏银行事故的描述大致如下2014年7月1日，宁夏银行核心系统数据库出现故障，导致该行（含异地分支机构）存取款、转账支付、借记卡、网上银行、ATM和POS业务全部中断。

经初步分析，在季末结算业务量较大的情况下，因备份系统异常导致备份存储磁盘读写处理严重延时，备份与主存储数据不一致，在采取中断数据备份录像操作后，造成生产数据库损坏并宕机。因宁夏银行应急恢复处置机制严重缺失，导致系统恢复工作进展缓慢，直至7月3日5点40分核心系统才恢复服务，业务系统中断长达37小时40分钟，其间完全依靠手工办理业务。

该事件的根本原因是在于该行安全生产意思薄弱、应急管理体系缺失、应急处置过程混乱。该行核心系统数据库版本严重老化，且2007年至今未购买核心数据库的维保服务，核心系统长期缺乏维护，事故发生后，无法获得系统供应商及时技术支持。系统恢复过程中，缺乏应急预案和准备，长时间无法实施有效处置，导致业务恢复缓慢，对银行运营产生较为严重影响。

对于这个事件的发生，网上论坛有网友开始怀疑当时在2010年进行的高大上的宁夏银行800公里灾备演练，当时号称区域性商业银行的第一次。

查阅资料，回忆当时演练现场，时任宁夏银行信息技术部总经理的王春表示，随着区域性商业银行的跨省发展，实施灾难备份系统已经势在必行，宁夏银现在实施成功之后，实现了宁夏银行所提出的“提升业务连续性，提升业务管理水平”的战略目标，做到了核心系统的灾难恢复的“全范围覆盖”。

其中演练主要包括了两种“突发情况”：数据库系统瘫痪和数据中心发生火灾——前者模拟宁夏银行生产中心数据库系统发生崩溃瘫痪的严重故障，测试根据需要启动应急响应流程，进行本地的数据库系统恢复;后者模拟生产中心发生大火，测试根据应急流程进行从银川到西安的异地切换。

整场演练全部在真实的生产环境进行，步骤衔接流畅，而且恢复速度让在场观摩人员无不惊叹，两个场景的演练时间加起来不过10分钟：第一场数据库瘫痪演练，4分钟成功恢复完成;第二场火灾演练，6分钟系统异地切换成功。

**当时的IT环境是IBM AIX UNIX、Informix、EMC DMX800。**

以上是宁夏银行2010年灾备演练情况的存储在线当时报道摘要，在整个演练过程中，飞康CDP起到了举足轻重的作用。为此，网友在论坛上评论说，“停止备份系统，竟然会导致主数据库损坏，看来FalconStor CDP ，不靠谱啊。”也有网友评论道：“系统维护没有跟上，再好的方案也会有问题。”

**对此，阿明认为：宁夏银行本次事件发生的根本应该更多归咎在系统维护上，很多时候，大型企业或银行做过周密的预案或灾备演练之后，就放松了对系统的整体维护，这是发生问题的主要原因所在。为此，宁夏银行官方表态也是“2007年至今未购买核心数据库的维保服务，核心系统长期缺乏维护，事故发生后，无法获得系统供应商及时技术支持。”** （要知道，数据库厂商很牛叉，这是圈内人士有目共睹的，既然长期不交“保护费”，自然得让你痛一下，痛定思痛之后，你就得乖乖上交数据库“保护费”了。）

说完今年宁夏银行这次事件之后，我们再回看一下去年工行、中行出现的系统问题，当时**CSDN的夏梦竹同学找到了一位叫jaccc的IT顾问** ，这位顾问的看法分析很透彻，也很中肯，对当前宁夏银行出现的系统问题也有借鉴意义，大家不妨“温故知新”：

**为什么IT系统会出问题?**

1）现代IT系统非常复杂，当系统大到一定的程度，总会有失控的状况。世界上就从来都没有过没错误的复杂程序，问题只在于这个错误你有没有碰上而已。银行的系统是由很多不同软硬件厂商的产品拼在一起运作，复杂程度远超过普通家用电脑，这么简单的家用电脑还会死机呢….而且系统复杂到一定程度，就不是人多或者钱多就能完全解决问题的了，推荐看看《人月神话》。

2）要尽量不出问题，要钱，很多钱（比如中型银行建设一个过得去的容灾系统要上亿）。但出问题只是“有可能”，花的钱可是实实在在的。换了你是领导，你也不会无限制的向里面投钱。

3）稳定运行的最好的办法之一是不对系统进行改造。由于有新的业务要求，系统确实要不停的升级，很多银行每周都在升级，每次变动对系统的稳定运行都是一个挑战。你每天走路有时候还会摔倒，只要一动作，就有出错的可能，这就是科学。

为什么会大面积的出现问题?

因为三个字：大集中。最早之前，银行系统还没联网，一出问题只是某个区或者某个市。最近十多年银行业都在搞大集中：五大行除了中国银行之外的四家都已经完成了大集中。

**为什么这种故障好像越来越多了？**

以前没有微博没有微信，只要你不是倒霉的用户就不会知道出过问题。我要不是上微博也不知道工行出这么大的事。以前没有网银没有淘宝，你半夜不会买东西刷卡。用行话来说就是以前没那么多7*24的需求（一周7天，一天24小时运行）。

**为什么没有应急预案或者应急预案没有起作用?**

与电信运营商，政府行业，普通企业相比，银行是中国IT业中IT基础最好，最严谨的行业。比如有的银行还要求厂商维护人员不能操作，只能银行员工操作。

大的变更一定会有预案，甚至换个硬盘，改个IP这种做过几百次的操作都会有预案。但预案与真实一般都有相当差距。上面已经提到系统非常复杂，可能出现的问题如果真全部写下来，可能有几百几千分支。而且，系统的故障并不会根据你的应急预案来发生。

只靠应急预案真解决问题的概率比拿着《泡妞指南》泡到美眉的几率还低，应急预案的最重要的作用是应付上级监管，根据应急预案搭好可能需要的应急软硬件环境，大致理清概要思路，以及锻炼团队。真有复杂问题，还是靠牛人现场解决的多。

平心而论，工行的IT能力和运维水平在四大行里面不是第一就是第二了（不同的省份略有不同）。

**为什么要停几个小时这么久？**

先说定位问题的时间：从发现问题上报到IT信息中心（或者在监控系统发现问题），IT中心的人开始查系统，定位故障原因，如果定位不清还要找相关的软硬件人员到场或者远程网络支持（基于安全原因，银行大部分都不能远程网络查看系统，维护人员到数据中心也需要时间，如果还堵车…..），找出问题的根源，一小时算超快的了。类似你莫名高烧，到底是哪个器官出问题，去医院做检查做判断总需要时间吧？??解决问题就更不好说了，其实和大家的电脑一样，往往重启是最有效的方法，但很多业务系统部分出现问题是不能重启的（可能会影响别的业务系统）。至今国外各大厂商的标准维护合同，绝大部分都没有承诺修复时间。??根据手头的一份略过时的银监会突发事件应急管理规范：一个省停业6个小时以上才算I级特别重大突发事件，3小时是II级，半小时以上是III级。以管窥豹，落叶知秋，几小时真不算什么。

**不是说有容灾和备份吗？为啥不快速切过去就好了？**

这是一个很常见的误解：出了故障的时候，有备份系统和容灾系统就可以很快恢复业务。一怀愁绪，几年离索，错，错，错。

先说备份系统，常规备份系统是不能运行业务程序的：备份一般只是把数据保存多一份或者几份，一般是在丢数据的时候才用来恢复，而且恢复的时间很多都在几小时以上。类似大家手头只有一个avi文件，没有播放软件也没法看啊，只不过银行的“播放软件”要架设起来就复杂了…..

再说容灾系统，强调一个连很多IT人都不清楚的事实：银行容灾系统不会轻易启用整体切换！前面已经说了，IT系统已经这么复杂了，容灾系统相当于再复制一套，复杂性增加了不止2倍。切换起来是非常麻烦，非常伤筋动骨，惊动非常多人力物力，不是碰到大灾大难（比如地震，机房着火，恐怖分子爆炸之类）不会进行切换。

当然平时会进行容灾切换演练，但一般不会拿核心系统来真实切换，原因是有风险。以前也出现过华东某省级行（还是某省某运营商？记不太清楚了）切换到了容灾中心后切不回生产中心的悲催惨剧。最近西北某地农信社成功的把核心生产切到了容灾系统上，比较不简单，不过这毕竟是独立法人的小银行，大行不是这么个玩法。

这么说吧，迄今为止，五千年来，四大行的核心容灾系统都没出现过需要两地切换的重大灾难的场景，和准备买iPhone6的肾一样，有两个，没切过，但时刻准备着切….其实个人不太靠谱的猜想，就算停个三五天，各大行都不会愿意全业务切换，今天这种停几小时的算个毛有啥好切的，赶快修好系统就是了。

另外，看到有不少评论说“没人敢担风险切换到灾备节点上”。其实一般是这样的：建好容灾系统之后往往都会写一套DRP（灾难恢复计划）或者BCP（业务连续性计划），就是容灾系统启动的流程方案，里面会规定好什么场景下由什么人拍板切换到灾备中心，一般不会真出问题才临时来拍脑袋来想，（当然临时调整也是有可能的），也不是谁说切换就谁去背黑锅。

当然，大部分的小故障会通过双机切换，快速重启部分应用的等方式解决。但很快解决了，你们就意识不了其实已经出过故障了嘛，是不是有点人择原理的味道？……但总有无法快速解决的问题。补充一句，当然业界有很多新技术已经把备份高可用灾备等揉在一起了，但银行业应用还不多，这里就不展开了。

**升级要失败，快速回退不就好了嘛？**

一个常见的误会：升级不成功马上回退啊。这是很理想的情形，现实的情形是这样的：

1）技术上无法回退。我举个例子，你从winxp升级到win7，升到一半，蓝屏了，或者报某个文件包找不到了。你会回退吗？

2）回退的风险更大，升级过程中很多配置，软硬件都改掉了，改不回来了，或者耗费的时间比继续升级更大。

3）硬着头皮冲过去就算超了时间的还能找个理由掩饰一下，回退了就确定升级失败了，下次继续升级的政治压力会很大。

所以实际情况中，除非可以很干净利落的回退，而且实在升级无法成功，才会回退。真的升级切割出问题会进行回退的不超过5%。

**周日到底出什么问题了？**

在中国，无论出现什么IT系统问题，对外宣称总是电脑系统升级。我以前就有个变态的习惯在处理故障中途如果有空（等别人处理或者等系统回滚什么的时候）就打呼叫中心电话，听那些美眉怎么解释系统用不了了。清一色的，100%的，毫无例外都说是电脑系统升级。当我再问为什么大白天升级啊？为什么之前不通知我们客户啊？这时候就能体现呼叫中心的培训能力的差距了。

回到今天这事，别说我现在还没去八卦，就算知道了也不可能公开说，这是职业操守的问题。而且有的故障的真相是查不出来的（你知道你每次生病的确切原因吗？），有的故障是查出来但不能实说（一般故障分析报告书很快就能到竞争对手手中）。这种情况下，怎么去写故障分析报告，是一门艺术：真相不重要，达到目的才重要。这个目的有可能是大事化小，有可能是小事化大，水深着呢。

**这几天微信圈里，继续在讨论宁夏银行系统问题，据圈内人士透露，银监会正在查这件事情， IBM和飞康都在等待结果。相信事实的真相不久后将浮出水面。**

银行系统相对复杂，银行IT建设也相对要求严格与苛刻，在建设好了IT系统之后，只是万里长征走了第一步，后面更为重要的是长期的运行与维护，包括核心系统、数据库的后续维保等，因此，这也是为什么某国内著名厂商舍得将设备免费送给银行测试一年多，希望得到银行采购后长期使用，只有使用之后才有价值，一旦使用了，后续的服务收费才是真金白银。

因此，不管是什么情况，不管遇到什么变化，只有长期的服务品质不变，长期保持演练时的心态不变，即便遇到突发情况，也会比想象的情况要好一些。

[以史为鉴：宁夏银行7月系统瘫痪最新解析](http://blog.jobbole.com/75051/)，首发于[博客 – 伯乐在线](http://blog.jobbole.com)。