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

我以前也以为电脑就是那个显示器呢。。

新马路，马场角，太平洋

新街口、马群、泰山新村

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

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

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

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

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

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

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

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

我工作的第一家做单片机应用，设计生产了一种煤矿气压仪器，单片机其内，带压力传感器的，有液晶显示屏（6位7段码），还有一个4x4触摸式键盘。触摸式键盘的背板是整块的铝板，大概2毫米厚。仪器返修率挺高，返修的仪器键盘经常有个大窟窿，就是reset那个键的位置。

这个窟窿是怎么来的捏？

煤矿的老大哥只要发现有什么不对头，就按reset键（说明书说的）。煤矿老大哥们的指头那可是金刚杵啊，这么按啊按的，终于一指头下去，把键盘及背后铝板一起按穿了。

其实银行的大机挂了很多小鸡鸡，这些小鸡鸡就叫“前置机”。很多业务经过前置机过滤预先处理掉了，剩下的最简单的比如调整余额，上交给大机去处理。

比如，网银有自己的前置机，ATM业务有前置机，以此类推。

比方电梯的上下按钮，坏的快很多原因是用钥匙给捣的。

大集中不是概念上的，从物理到业务框架到系统都在升级。

第一次集中主要是核心系统的集中，主要指导原则是大会计、通存通兑、本外币一体化。大会计是指储蓄、会计、信用卡这些原来的分散系统统一在一个系统内，通存通兑是指全辖业务集中到一台主机，所以网点在各种业务上能够实现通兑，本外币一体化就是人民币、外币共用一套系统。

以上三点大的银行都实现了，但是很多区域性商业银行还没有实现。

分散的前置是第一次系统集中之后的发展起来的。因为银行实现了主机化，所以很多涉及第三方或者渠道的业务就可以实现电子化。比如POS、ATM，如果没有主机集中，实际上是不可想象的，信用卡只能采用手工压卡方式。主机集中之后，银行的电子经营渠道如ATM、POS、CALLCENTER、WEB BANK才开始发展，因为是一个一个上，因此增加了很多前置机。这才有第二次集中。

第二次集中，主机上整合进了客户中心的功能（虽然用的很不好），而渠道前置则在中间业务平台的基础上发展出大前置的概念，即所有的渠道和第三方接入（如银联、大小额、第三方代收代付）都集中在大前置系统上来实现。

前置集中的效果只能是各有说法，很多前置系统由于是设备厂商提供，还是无法整合进去，不过没有系统只提出标准接口的第三方代理业务整合的还是很不错的，比如通讯缴费、国税联网、银联、现代化支付等等。

可能还会有第三次集中，即管理系统的集中，这个称为商业智能领域，是以数据仓库为架构，统一整合管理平台，不过这个比上一个还难，现在真正实施的案例就没有。

当年也是把纸上到打印机上，然后一帮人开始在边上打牌，经常到很晚才能收工，最怕的是打印的中间纸跑偏了，这就不是一般惨了，得从头开始。也别说WIN的强大生命力，当时用的系统是UNIX的，从前任那里继承了十几条常用的命令，又陆陆续续从电脑部的技术人员那里问了些自认为密籍的命令，就上岗了，要知道我可不是学这个的，到后来还差点动了学点UNIX的念头。

业务和科技这两块是两个相辅相成的东西，任何一块设计好了，都会为另外一块带来便利，但绝不可能替代另一块的功能，但这就是问题出现的地方，业务的认为，技术应该都能搞定，技术的认为，业务上本身流程是没有问题的。在银行里，真正能从原理高度把这两块同时搞透的也是凤毛麟角，80%以上的人懂业务也就是知道个怎么操作，就象现在卖理财产品一样，客户经理事实上都不知道自己在卖什么。

前不久，自己也曾经算过一下，前前后后也用过大大小小上十种业务系统或软件，对于搞业务的，这估计也算不少了，自己最大的心得就是得去适应系统，哪怕它再烂，当然也反映了另外一头，就是前期开发一定要细致认真。自己也去写过一次需求，当时只有一个心愿，千万别在系统或培训手册的哪个地方鸣谢，不然会被一线弟兄们鄙视的。领导们有时太急功近利了，这活哪能做细呢！

是汽车厂里的工人，是液晶接触屏，程序不工作，工人愤怒地把屏幕戳了个洞！

好在我的小洗衣机是旋钮的，没人会用(海尔的，选转后要拔出才开始工作)，要不然不到1个月也得完蛋。

不做这个很久了,现在涌现出很多后起之秀,比如高阳(?)

花大力气搞质量体系,ISO、CMMI认证，然而，没有人指出来最大的质量风险来自于领导！

很多项目，审批环节能绕几个月甚至几年，有不少项目做完投产运行了还没批下来；

还有大部分项目，领导那儿花几个月甚至几年拍板，一旦拍板就规定一两个月给我干出来，时间不够？加班！

领导好象觉得加班是万能法宝，祭出来无往不利。

PMP说项目往往存在着时间/费用约束，诚不欺我。

最可笑是某大领导拍脑袋说，今年代码合格率要达到99.99%，于是下面层层执行者以满足这个指标为原则报BUG率，这些虚假数据还要作为历史数据进组织资产库，可想而知，据此而来的未来的预测模型结果，其可信性又有多大了。

看看那些官僚，就知道当年那股浮夸风如何恐怖了。

招商银行就是用的ES9000？我以前听说那个系统是IBM的。

我可是付了利息了。