主题：【原创】银行的事故（一） -- 河蚌

在科技部门眼里，上面这出热闹的阴阳错就如同隔岸观火，烧得再旺也到不了这边。但是业务和技术毕竟都在一个锅里，看别人热闹时，自己最好还是小心点。做程序的都知道，技术错误和业务错误是两码事，程序崩溃在技术上是一级错误，对于业务却毫无影响（程序根本不能用，还到不了业务那块），而有些低级别的技术错误，却能导致极其严重的后果（例如小数点少算了两位，然后日元按美元价给付出去，不过这是另一个故事）。当然最让科技人员担心的，是那种测试中完全没错，上运行环境后却莫明其妙影响效率，甚至造成当机事故的错误，就比如上面提到的按姓名查户主这个功能。

对于开发人员而言，按姓名查户主的业务危险根本不用去考虑，只要业务人员提出并通过需求评定，那么开发人员就没有责任了。迟迟不愿做的原因恰恰是技术考虑，因为本功能可能造成无索引查询引起的锁表问题。在银行系统中，使用频度最高的数据表是对私分户帐，存取款、查询等业务都会用到这张表。系统一般都不会对姓名这样的中文字段加索引，这就意味着按姓名查询是对无索引字段进行查询操作，如果银行不大，分户不多业务量小，这种影响完全没什么，但是如果银行很大，那么，这种查询方式，只能是后果很严重。

只有摔一跤才知道石头有多硬，推演是推演，在没有实际体验前，谁也不知道我们花上千万买的机器是否能横寻千军如卷席。大家决定还是赌一把，当然这次显然 RP不太好，几十分钟后，系统就不负众望地开始阻塞，最后甚至完全停滞下来，然后一起事故就这样在众望所归中诞生了。好在当时系统上线不长时间，错误、修改、再错，这一循环甚至成了我们的工作方式，因此，倒也没有造成什么恶劣的影响——科技的名声已经够差了，并不会因为这种小CASE而增加什么。

这个事故发生已经十多年了，原来以为这只是我们开发过程中的一个小插曲，或者说是成长的代价，但是等离开银行来到公司，才发现自己错了。虽然一个人不应该在同一个地方摔两次，但这并不意味着另一伙人不会在这儿再来上一下。近年来，这样的事故已经见了三次，同样的错误，同样的模式，同样的影响恶劣，甚至连最后解决手法都基本类似（交易包发往备份主机），只是银行不同罢了。

按姓名查户主这个典故经常被我用在和客户交流中作为业务简单技术难做的例证，然而这种事故毕竟还是比较容易解决的，只要停掉这个业务，将相关进程取消，甚至不用重启就可以解决问题。但是随着数据集中的加剧，另一个技术问题却越来越突出，但却绝不能那么简单地一停了之。这个问题，虽然大家都知道它难做，但是却又不得不做，甚至原来一年只做一次，现在必须一年做四次，由此衍生出的问题，甚至超出了技术和纯业务范畴，影响到银行业的一些重组。这个就是银行系统的计息。

银行是通过存贷利息差来获取利润的，因此结息无疑是经营活动中的大事，在几年前，对公结息和对私结息是不同的，企业户结息是每季度最后月的20号，储蓄户则是6月30号，现在，托国家的福，两者统一，都是一年计四次。在单点系统时代，每季度对公结息虽然比不上年终结转（那是银行业的佳年华会），也是除此之外最重大的事件，一般都要干到晚上两点钟。系统集中后，这个工作就收到总部，由系统自动处理，各网点只要第二天来打印计息单就可以了。

不过，系统数据的集中，显然使看来已经轻松的工作重新变为一种负担，特别是储蓄计息变成一年四次更使这一问题尖锐起来。到现在已经不知道听到多少起这种事故，或者说，一直到现在，计息日都是科技人员关注的重点，不但影响到运营系统，甚至影响到管理系统。在这一天，平日里只有十几万条的业务会因为分户计息而充塞进上百甚至千万条（活期分户有多少就有多少条）的结息流水，平日里十分钟运行的程序，如果不加处理3个小时也运行不完。而稍微不注意，计息就有可能一直运行到第二天网点开业时都无法完成，这样又一起影响范围巨大的事故就诞生了。

在今天这个银行业纵横捭阖的时代，这样的事故不但会影响银行的业务，还会被用作一块板砖，砸向任何用的着的地方。玄武湖畔的一只蝴蝶残缺了翅膀，一场将要发生的合并风暴因此而悄然收场，有些事情，曾经让大家想尽办法，却没有想到，结束竟然如此简单。