谁来为银联系统瘫痪埋单？

4月20日上午10点56分，银联通信网络和主机出现故障，造成银行卡跨行交易不能正常进行。虽然银联及时发现问题并对此进行了全力以赴的抢修，但到当天下午5点10分为止，全国大部分的成员机构和商户只是基本恢复正常，直到晚上8点，银联跨行交易网络才得以全面恢复。

直到截稿之时，银联还未能统计出此次故障所造成影响的具体范围和持卡人数目，但就之前银联所公布的相关资料显示，截至2005年底，国内共有175家银联成员机构，共发行银联卡5.5亿张。银联网络境内受理商户达到39.4万户，POS机60.8万台，ATM机8万多台；境外受理商户2.94万户，POS机4.53万台，ATM机6.32万台。目前中国银联天天的跨行转接交易量在1000万笔左右。

据此初步测算，当天银联的网络瘫痪，可能导致全国数百万笔交易量无法完成，而商户刷卡失败的数量现在还难以估算。中国银联相关人士表示，此次故障造成的损失主要来自三方面：一是商家货物交易不成功；二是没有带现金而习惯于刷卡的消费者无法购物；三是银行业务量减少，但绝对不会出现交易错乱或资金清算上的任何问题。

无法定时的炸弹

在一场浩劫过后，人们往往最为担心的就是这样的事情还会不会再次出现，但遗憾的是，直到目前为止，无论是中国银联本身，以及其下属的成员机构都不能明确给用户一个相关的保证。就在此次故障刚刚被排除后，一位招商银行的相关负责人明确告诉记者：“称这样的事件是埋藏在我们四周的一颗炸弹，一点也不过分，而且，最令人担忧的是，我们不知道它何时会再次发生。”兴业银行的相关人士也表示：“假如说系统偶然或短时间出现一些问题，我们都可以理解。但此次事故时间长达8小时之久，由此可以看出银联系统在平时对这种突发性灾难预备不足，并且在事故发生之时没有做好相应的应急措施。”没想到，就在我们对网络银行遭受恶意攻击与打击盗窃的忧虑还未过去时，却发现原来银行交易系统与业务流程本身的缺陷才是安置在我们身边的炸弹，最可怕的是，我们无法去估算其爆炸的时间。

据中国银联上海总部相关负责人介绍，由中国银联公司领导、技术团队和设备厂商组成的故障排查小组的初步分析表明，此次故障原因是由于银联新近预备上线的某外围设备的隐性缺陷诱发了跨行交易系统主机的缺陷，使主机发生故障。同时，中国银联还强调，上述结论还有待相关厂商的专家确认，并将组织有关专家进一步论证。

但是，仅仅是设备的隐性缺陷就能诱发中国银联长达8个小时的全国范围内系统瘫痪吗？造成这次自中国银联成立以来最为严重的事故原因是否真的如银联所公开的那么简单吗？就在系统恢复的当天，记者联系到北京农业银行信用卡部门的相关负责人，从那里，我们发现了隐藏在这次事故背后更为复杂的原因。

“由于中国银联采取了全国上收的政策，也就是说，全国各银行的数据必须全部集中到位于上海的银联总部来进行处理。所以，一旦发生通信系统拥堵，所涉及的范围必然是全国性的。从我们现在了解到的情况来看，此次事故的原因是因为交易数量的忽然增大，造成了系统通道的堵塞，而在此大面积系统瘫痪之后，中国银联只能采取逐行放行的策略，也就是说，要一个一个银行来进行系统恢复，从而就造成了此次瘫痪的时间如此之长。”

灾备系统是否一应俱全？

中国银联作为全国银行卡业务交换中心，负责统一规划和建设全国银行卡跨行信息交换网络，向成员机构提供跨行和跨境的金融交易转接处理和清算、代授权、差错处理、查询与报表等服务。按此道理分析，中国银联对信息处理中心灾难备份系统集成项目所采用的设备应该是非常严格的，必须保证交易系统的高度可用和可靠。

事实上，银联也确实是如此设想的。2005年6月1日，中国银联与北京华胜天成科技股份有限公司及Sun公司正式签订了关于银联信息处理中心灾难备份系统集成项目的合同。通过采用Sun技术平台，由华胜天成提供系统集成，为中国银联上海浦东数据中心、上海浦西备份中心和北京灾难恢复中心三地建立灾难备份系统，由此可见中国银联非常重视银行业务的连续运营与持续发展。而早在此之前，中国银联信息处理中心灾难备份系统集成项目就采用了六台思科MDS9509存储核心产品，上海同城灾备四台、北京异地灾备两台。

据了解，中国银联与Sun所签订的灾难备份系统项目涉及的总存储容量高达300TB，是目前国内规模最大的灾难备份系统，它采用的业务连续发展(BCP)技术在全球也处于领先地位。但如此强壮的系统为何会在交易数量的突发增长面前显得如此脆弱不堪呢？对此，曾经参与银联新系统建设的一位工程师解释了其中的原因：“银联的新系统简称CUPs，由上海华腾开发建设，历时已经有二三年了。这套系统按说交易速度很快，功能很多，可以说是大而全了，兼容内外卡、磁条、IC卡。不过这种实时系统的重大缺陷是即使有灾备、即使做到进程级备份，假如程序出问题，备份系统肯定也有问题，在这个意义上备份系统只是摆设而已。”同时，该工程师还强调，考虑到银行业务的非凡性，假如交易出了问题，会导致一大堆冲正交易，也就是反向交易，大大加大了系统和网络的负担，导致系统更大的错误或者更快的崩溃。

而另一名曾经供职于银行系统的软件工程师认为: “目前各大银行和银联都进入了数据大集中时代，可以说对交易、对统一推广业务、对加强治理都有好处，但是把所有的鸡蛋都放在一个篮子里的危害也日益凸显。原来的电信程控交换机都是集中式的，电信看到了集中的危害，后来多采用分布式的。而银行业却选择了集中，但同时也选择了风险。一旦出现问题就可能引起全国范围内的银联系统瘫痪，这次的故障就属于这种情况。据我了解，银联系统有‘双机备份’，而且肯定经过演练。”

记者了解到以前人民银行清算中心只做大额的支付，而近年开始，包括人民银行在内的许多银行清算中心的小额支付系统都已经上线，其功能和银联相似，不知道在这样的发展形势下，各个银行是否会逐渐放弃银联，这次的事件是否会对银联造成影响，我们还需拭目以待。

有了损失找谁去？

银联系统瘫痪事故发生后，记者听到了各方面的抱怨声，虽然全部都是围绕银联卡跨行交易失效导致自身交易受阻而展开的，但事情发生后，人们更多考虑的是自己所遭受的损失应该由谁来负担？据了解，这次POS机瘫痪正好是在生意最旺的时段，记者从许多百货公司和超市了解到，银联系统故障均给公司的营业额造成了一定的影响，有些甚至很大。有商家提出，像这种情况，银联和银行方面是否应该考虑给予一定补偿？也有商家建议，在下一步签订合同时，商家应该考虑联手对此问题进行商讨。

其实，就目前来看，在和银行签订的关于银联的服务合同中，虽然有赔偿条款，但是并不具体。而且，在商户所提供刷卡服务方面，银联是惟一的一家，许多商家都认为：“银联的话语权一直处于强势”。就商家的这些看法，记者询问了中国银联上海总部的负责人，但该公司的对外发言人态度强硬地表示：“商家在提出索赔前，应该看清楚签订的有关合同方是谁，盖的是哪里的章。”银联的意思也就是说，商家应该去找与自己签订合同的相关银行进行索赔事宜。但对于这种回答，许多商户的反应都是：“与银行签订的是结账服务方面的合同，与银联签订的是提供POS机和系统服务的合同，这两个合同在订立之初是捆绑在一起的，为什么在出了问题后，银联就把责任推给了银行呢？”

早在此次事故原因还未查明之时，中鸿律师事务所的黄志坤律师就曾表示：“倘若银联系统瘫痪由于不可抗拒因素造成，应属突发事件，从公平角度讲，银联可依法对相关的交易作无效处理，并不用承担因为瘫痪带来的客户赔偿责任。”

但事后，被公布出来的事故原因还是出自银联系统本身，中国银联的该发言人还表示: “就算涉及索赔问题，对于商家及刷卡消费者造成的损失，因损失数额不好举证，赔偿问题也恐难有着落。”中国银联品牌部的屠先生告诉记者，检测发现银联系统故障发生于l0时56分，之前发生的故障“应该属于个案”。他告诉记者，此次故障只会导致银行卡支付失败和跨行业务无法进行，而不会对银行卡账户产生交易金额错误等影响，“就算故障发生时客户正在使用银行卡，也不会出现交易错误，更不会出现数据丢失的现象。”

对于目前是否有用户提出索赔的情况，农行表示目前本行还没有接到这样的请求，但是，假如有这样的情况发生，农行表示，在进行相关法律程序之后，农行会负责履行应有的赔偿责任。

当然，为这种自身无法掌控的事故负责，除农行外，许多银行都表示出强烈的无奈，兴业银行的人士也表示：“目前来说，银联更像是一家官方机构，它需要转变思路将自己定位为服务的角色。”但是，出于目前银联与各银行之间业务流程与权责划分的混乱，这样的无奈可能还要顺延。

相关链接一

近年全国银联故障统计

● 2004年8月15日 广州银联故障

晚7时，广州两家吉之岛百货店因银联系统出了故障无法刷卡。从下午5时55分开始，至晚上9时30分左右系统恢复正常。 

● 2005年6月7日  全国银联POS机瘫痪

晚6时到8时，银联上海总公司进行技术切换处理，导致全国的POS机在该时段处于瘫痪状态。

● 2005年7月23日  北京银联故障无法刷卡

上午10时到12时左右，北京银联网络出现故障，导致银行卡在刷卡机上无法使用。

● 2005年12月18日  上海银联故障刷卡卡壳

下午3时20分，上海银联系统突发故障，市民无法跨行取款，无法刷卡消费。下午4时20分左右，银联系统得以修复。

相关链接二

系统抗灾仍任重道远

就在银联系统瘫痪之前几天，美国麻省理工学院做了一个禽流感应急反应模拟试验，结果表明，禽流感会切断经济供给链。这样的实验结果表明，灾难防不胜防。此次模拟试验的负责人说：“危机预防的主要困难是人们总是对事前的危机浑然不知。”

试验结果的确令人失望，不过在2001年，美国“9·11”灾难发生时，编者也听到一家金融公司由于之前建设了很好的灾难备份系统，并没有对正常的营运产生重大影响。

要害业务的系统建设不可能全面抗衡各种可能发生的灾难，但就像我们追求5个9甚至7个9的核心业务系统可靠性一样，建设具有强大抗灾难性的要害网络及应用系统，应该是所有IT工作者永远追求的目标。