1【原创】银行的事故（一） 51 河蚌 2008-06-21 06:53:48
    本来想做一个标题党，将本文名为《如何去抢银行》，不过考虑到这样一个题目不但很黄很暴力，而且可能引来权力部门的专政，所以还是老实一点比较好，就叫做事故吧。声明一下，那些没有技术含量的暴力事件，或者有技术含量但是却与IT无关的暴力事件，都不在本文关注的范围内。做什么事说什么话，我想写的，还是那些与IT相关的故事，或者可以称为智力事件，这个既包括一些有心而为之的案子，也包括由于脑袋断路而造成的损失。
    其实银行的IT应用应该是很久远的事情（印象中最早的是中国银行，据说在八十年代他们就用中型机了），不过大多数银行（包括工、农、建）一开始并没有大机的概念，都是一个网点一台机器，现在我们称那种系统为单点系统。在那个时代，电脑闹个头痛脑热是很正常的事情，而且一旦坏了，就只有等着运维人员上门来修，这时候，银行与顾客经常会有这样的对话，“我取钱”，”电脑坏了”，“什么时候好？“，”不知道“，”我急用呀”，“没办法“，”你们现在在干什么？”，“等修电脑的人”，“他们什么时候来？”，“正在过来“，“今天能好吗？”，“不知道，现在时间不早了，要不然你明天过来？“。
    反正遇到这种情况，你就是神也没用，只能去祈祷那些不是神却很神的人赶快出现。而且在那个时代，你甚至也不能象现在这样，换一个网点试试运气。银行的人会告诉，虽然本银行有众多分号，但概不通兑，新街口开的户到东四十条那是肯定不行的。本来上了电脑就意味着方便，比如当时最常见的广告语是“电脑核算，快捷方便”，但是故障如此之多，以至于据说某些农行（农行曾经就是银行界的泔水桶，有什么比较NC的事一般都会扣它头上，现在有了更好更大的泔水桶，那就是农信）网点打出“手工记帐、方便可靠”的招牌。
    不过那时的故障其实都算不得事故，因为影响范围有限，顾客也比较好对付，遇到取不出钱，一般都是自认倒霉，然后回家等着第二天来碰碰运气，一般而言，你的 RP不会太差，那种系统一连坏三天的情况虽然也有但并不常见。当时，电脑故障的不确定性几乎和今天下不下雨是一样的，天气这事情只有天老爷和气象局知道，而电脑这事儿，天老爷知不知道大家不清楚，明确知道是怎么回事的只有科技部的仙人们。
    其实有时候也不能怪系统不结实，因为银行网点的员工毕竟不是电脑专业，而且过去的电脑普及率也不象现在，很多人真的对电脑没有任何感觉。举个简单的例子，在UNIX下面，“_"是经常会用在程序名字里的，但是在实际工作中，这个最好别用，因为难免有时候系统出现些故障，然后需要通过电话支持一下，“你执行 sys_main.sh...",“什么？”，“S...Y...S下划线”，“下划线是什么？”，“就是减号那个键同时按上shift","shift 是什么？”，“就是那个......"。怎么样，麻烦增强版吧。这已经是对网管（网点主管）说了，要是普通员工，那就更麻烦了。
    就因为这个，在很长时间，电脑对于银行的业务人员都是一个比较神秘的东西，当然，这也为规避银行的某些管理提供了一个非常有效的借口。在九十年代中期，银行普遍开始加强管理，窗口人员和客户吵架一次，检查，两次，下岗培训一个月，三次，解聘，然后还有许多具体的服务指标，比如什么样的业务应该多长时间办完。但是如果你把这个条例看完一遍，相信印象最深刻的不是哪一条规定，而是那几乎每一条后面都跟着的”电脑故障除外”。
    时代在进步，银行当大爷的时代一去不复返，客户有个什么不舒服，大可以堵在窗口，然后一元一元的往帐户里存钱，只要不带凶器，银行还真拿你没办法。但这也间接造成了科技部门的紧迫感，曾经去一个网点维护，网点人员指着门上的那个大洞说，这个就是客户踢的，也不怪别人，三天没取成钱。不怪客户，那就自然应该怪科技了，虽然别人没这么说，但是作为科技人员，这个感觉真的不太好。
    不过在单点时代，所有的这些故障，都只能说是一些麻烦，真正上升到事故的层次还得到银行数据集中之后。

2银行的事故(四) 16 河蚌 2008-08-15 23:36:29
    如果对金融股感兴趣的朋友，一定知道这几年什么是银行业最大的事，股改，股改，还是股改。工农中建，四大行，先是不良资产剥离，然后是充实资本金（国家甚至不惜动用外汇储备）。银行的股改为整形行业提供了最光辉灿烂的案例（其实整形进入中国后就已经够灿烂的了，一切皆有可能，不但整人、整车，还能整企业），工行中行建行成了中国最成功的整形美人，俨然跨进世界最好银行的行列。不过说起来，整形总还是有技术限制的，比如一只黑猩猩，你能把它整成美女吗?
    在银行体系里，农行就是这么一只猩猩，而且是一只巨型的。虽然拥有众多整形高手，但是国资委看着这只金刚仍然只有摇头的份。集思广义，发挥大家的聪明才智，最后商量出的方案，拆了它。虽然"美的已拆了"就是中国制造,但是长考出的这个结果显然是步臭棋，不知道管理者是不是这么想的，反正这个建议只是在媒体上探了一下头，就给砸了回去。对农行的整形显然超出了现在的技术条件，所以搁置也不失为一种好办法。不过，与此同时，另外一个农字头的银行体系，整形却在热火朝天中，这就是农信。
    与农行相比，农信更象是《加勒比海盗》里那群螃蟹，野地里生，野地里长，甚至连保护动物都算不上。但是，既然所有的银行都在整形，农信自然也不能例外。与农行正好相反，农信的整形方案是把螃蟹们组合起来，或者形象一点，就是拿块布包一起。当美容师对着农行比量来比量去时，一群群农信已经纷纷为成立省级联社大动干戈。这样的整形对于农信是好是坏咱还真说不清楚，但是对于金融IT公司那肯定是天上掉金子的美事，不怕做错事，就怕不做事呀。
    省联社的目标就是将下属的成百上千的螃蟹变成一个海神，最有效的办法就是统一做套帐务系统，帐收上去了，你想不听也不行了。这个道理大家都懂，虽然大家都喜欢做鸡头，不喜欢做凤尾，但是大多数的农信确实也是没法子，再亏下去恐怕只有去做鸡了。“四大行股份制，城商城信农联社”，这农信系统是最次一档，多和农民打交道，什么种子、化肥之类，出力多却没有多少效益。不过，这些都是通常的情况，如果农信效益好的不得了,这个，合并就有阻力了。
    “那个地方是不是穷的只剩下农信了？“，经常有人对农信作区域老大的说法表示怀疑。人呀，有时候总会被自己的固有经验所蒙骗，这个就是一个例子。效益最好的农信不但不在穷地方，而且还在中国最富的地方——长三角的苏州无锡。看一下最新的县域经济排名就知道这个地方的繁荣，前十名中竟然有七个是苏州和无锡的，这已经够让人吃惊的，但如果换一种说法，也许你会更吃惊，那就是苏锡下辖七市全部进入前十。
    这些县级市，甚至在北方的地级市面前都是恐龙一样的经济怪物，因此也就不难理解那些地方的农信为什么是效益最好的了，当年所有的银行都在进城，只有农信十分委屈地留下来了，没想到乡镇经济却成就了它们。农信不同于四大行，虽然有个总体的称呼，但是各家信用社都是独立的法人。这也就不免会穷富分化，通过名称就可以看出很多讲究，有叫”农村商业银行“的，有叫”农村合作银行“的，还有仍然叫“农村信用联社”的。这里面那些叫行不叫社的，虽然还是农信，这骨子里已经不太姓农了，就象苏锡地区很多农民已经不种地一样。
    苏州无锡的每个县级市都有自己的农信，这些农信都是最高一档，叫作农商行（也有例外，比如宜兴，这个在苏锡地区敬陪末座的城市，农信叫做合作银行，而它也成了省联社在这一地区唯一的收获）。对于这些农商行而言，上海才是他们的根，南京那个省城无疑有些偏远了。他们对于成为这个偏远城市银行下的一家分行毫无兴趣，或者说，其实他们对于成为任何一家银行的分行都没什么兴趣。
    但是省农信的合并是一个政治任务，对抗就是自绝于组织,自绝于人民,就是政治错误。政治错误是会死人的，这个已经无数次被中国的历史所证明。当你官做的足够大时，你可以做很多常人不能做的事情，比如贪点钱、受点贿、玩个女人，只要政治正确，但是不能政治错误，一旦政治错误了，那你就完了，一堆罪名会堆到你头上，而且搞笑的是，这时候你的罪名反而全是那些小节，和政治却毫不沾边。
    农商行的领导当然知道这些，所以他们也绝对不会傻到象陈*宇那样在会议上拍桌子。省农信风风光光的成立了，然后一家老牌的IT公司也风风光光的为它建立起了自己的系统，这些富裕的诸侯似乎也只有接受王化这一条路了。不过就象温相说的，有一分希望，就要尽百倍努力，政治是不能抗的，因为任何的政治都是态度问题，只有YES和NO两种选择，但是技术不一样，技术是个方法问题，拿把铲子就能挖出一个回路来。当政治不能解决时，就需要技术的力量了。      
    银行科技部门一直是一个与政治无关的部门，我们的科技老总就一直不是党员，也从来没有入党的兴致，而这并妨碍他在这个位置上呆了八年。虽然一直以来业务人员都对科技人员很尊敬，但是就科技部门的性质而言，这确实只是一个辅助部门，这种尊敬其实与电线短路时对电工师傅的尊敬没太多区别。只是这一次，当各种力量都势均力敌时，科技部门就成了那只最后加把劲就将萝卜拔起来的小老鼠。
    农商行为了保证目前的管理水平不会降低，为了保证业务风险降到最低，为了保证新上系统具有最强大的功能，向省行的同仁和公司的对手提出了无数的需求。很多需求是不可能完成的，但是，技术上的不可行不能作为理由，因为农商行手里握着尚方宝剑，这个就又回到了政治层面。当初，省里为了让这些强大的诸侯归顺，曾经答应过，各家系统的合理要求都必须满足，你看，我这些需求里有一个不合理的吗？
    虽然农商行的归顺并不顺利，但是其它诸侯的王化却仍然在进行，终于，省农信甚至在无锡也有所斩获（不幸的宜兴农合行），前途已经一片光明，只剩下江南一隅了。一直以为，这场战争已经快要结束了，毕竟政治不是技术能抗过的。没想到，抵制运动竟然成功了，来得很迅速，而且轻松的令人意外，而成功的原因竟然是来自于技术层面，一个在IT系统中最常见的错误，计息的错误。
    其实省农信的节节胜利已经为这个错误做出了铺垫，收上来的行越多，数据就越大，而且越是发达地区的行，数据量就越大。当省农信庆祝常州和宜兴上线时，大概没有想到，他们的系统已经悄悄超越了运行的界限。于是，就在这个季度的计息日，计息一直运行到第二天上午，全省的网点都坐等了几个小时，一级事故，与去年交通银行那次一样。
    危机结束之后，大家擦汗之余，又将视线对准了这些农商行，无锡两家，苏州六家，估算了一下数据，于是终于泄气了，这是省农信范围内效益最好的几家行，也是数据量最大的几家，还是交易最活跃的几家行。现在的系统都已经搞不定，再加上这几家，还不知道会出什么乱子，算了吧，多一事不如少一事。曾经让众多能人志士耗费脑浆的事情就这么结束了，而这一切，都来自于一次并不太严重的事故。
    故事终于讲完了，却发现有些跑题，这场政治秀其实和IT关系不大，还是回到正题，咱们接着说银行的事故。对于IT人员来说，事故其实分两类，前面谈到的可以称为内部事故，天天都会有，经常盯着点，改了也就没事了。最害怕的是另外一类事故，也许影响范围不大，但是损失却是真金白银的，对于科技人员，后果显然更为严重，也更让我们闹心，比如银行卡的各类事故。


最后于2008-08-15 23:43:46改,共1次;

3这么大的数据量，要拿小机吃不消，得要大机了 盐城闲人 2008-08-23 03:29:20
IBM的业务代表要笑了

3没搞清楚需求盲目上马，一切都是为了领导自己 女生跟班 2008-08-16 02:09:30
某市曾引进某国的先进公交管理系统，试运行没问题，等把所有的公交线路都加上，系统就挂了。
对方工程师来看了之后说：我们全国才几十条公交线路，你这一个市就几百条，我们这系统玩不转。
这个时候想想，在这件事情上，领导不就是S13么，反正花的又不是自己的钱，玩不转就不用了还不成么。

4哪个欧洲鸟国？还是新家坡？ nighter 2008-08-16 02:13:07
似乎不太可能

欧洲小国都鼓励公交，环境问题而且又没有大的汽车制造商

难道新加坡只要几十条公交？

5不能说，嘿嘿。。。 2 女生跟班 2008-08-16 02:19:14
还听说一件事，某项目终验需要将所有文档打印，非常正当的要求。
交上去之后，对方领导来了个：怎么没有源代码？把源代码也打出来，交上来，终验需要。
估计打完了要用卡车拉过去。
后来一个电话解决问题：咱们这边验收不是有规定要页签么？

2上花送宝 蝶舞春园 2008-08-15 06:18:16

2说起门上的大洞，我会心地笑了，客户啊客户，讲个故事吧 2 HAL 2008-06-26 17:29:15
我工作的第一家做单片机应用，设计生产了一种煤矿气压仪器，单片机其内，带压力传感器的，有液晶显示屏（6位7段码），还有一个4x4触摸式键盘。触摸式键盘的背板是整块的铝板，大概2毫米厚。仪器返修率挺高，返修的仪器键盘经常有个大窟窿，就是reset那个键的位置。
这个窟窿是怎么来的捏？
煤矿的老大哥只要发现有什么不对头，就按reset键（说明书说的）。煤矿老大哥们的指头那可是金刚杵啊，这么按啊按的，终于一指头下去，把键盘及背后铝板一起按穿了。

3这个我也见过 懒厨 2008-06-26 18:41:08
是汽车厂里的工人，是液晶接触屏，程序不工作，工人愤怒地把屏幕戳了个洞！

4见过一台洗衣机，开关处是个窟窿，控制板都给戳掉下去。 lanchong 2008-06-26 18:46:55
好在我的小洗衣机是旋钮的，没人会用(海尔的，选转后要拔出才开始工作)，要不然不到1个月也得完蛋。

3这种洞八成是用什么工具 河蚌 2008-06-26 17:40:49
比方电梯的上下按钮，坏的快很多原因是用钥匙给捣的。

2【原创】银行的事故（三） 29 河蚌 2008-06-26 10:01:39
    在科技部门眼里，上面这出热闹的阴阳错就如同隔岸观火，烧得再旺也到不了这边。但是业务和技术毕竟都在一个锅里，看别人热闹时，自己最好还是小心点。做程序的都知道，技术错误和业务错误是两码事，程序崩溃在技术上是一级错误，对于业务却毫无影响（程序根本不能用，还到不了业务那块），而有些低级别的技术错误，却能导致极其严重的后果（例如小数点少算了两位，然后日元按美元价给付出去，不过这是另一个故事）。当然最让科技人员担心的，是那种测试中完全没错，上运行环境后却莫明其妙影响效率，甚至造成当机事故的错误，就比如上面提到的按姓名查户主这个功能。
    对于开发人员而言，按姓名查户主的业务危险根本不用去考虑，只要业务人员提出并通过需求评定，那么开发人员就没有责任了。迟迟不愿做的原因恰恰是技术考虑，因为本功能可能造成无索引查询引起的锁表问题。在银行系统中，使用频度最高的数据表是对私分户帐，存取款、查询等业务都会用到这张表。系统一般都不会对姓名这样的中文字段加索引，这就意味着按姓名查询是对无索引字段进行查询操作，如果银行不大，分户不多业务量小，这种影响完全没什么，但是如果银行很大，那么，这种查询方式，只能是后果很严重。
    只有摔一跤才知道石头有多硬，推演是推演，在没有实际体验前，谁也不知道我们花上千万买的机器是否能横寻千军如卷席。大家决定还是赌一把，当然这次显然 RP不太好，几十分钟后，系统就不负众望地开始阻塞，最后甚至完全停滞下来，然后一起事故就这样在众望所归中诞生了。好在当时系统上线不长时间，错误、修改、再错，这一循环甚至成了我们的工作方式，因此，倒也没有造成什么恶劣的影响——科技的名声已经够差了，并不会因为这种小CASE而增加什么。
    这个事故发生已经十多年了，原来以为这只是我们开发过程中的一个小插曲，或者说是成长的代价，但是等离开银行来到公司，才发现自己错了。虽然一个人不应该在同一个地方摔两次，但这并不意味着另一伙人不会在这儿再来上一下。近年来，这样的事故已经见了三次，同样的错误，同样的模式，同样的影响恶劣，甚至连最后解决手法都基本类似（交易包发往备份主机），只是银行不同罢了。
    按姓名查户主这个典故经常被我用在和客户交流中作为业务简单技术难做的例证，然而这种事故毕竟还是比较容易解决的，只要停掉这个业务，将相关进程取消，甚至不用重启就可以解决问题。但是随着数据集中的加剧，另一个技术问题却越来越突出，但却绝不能那么简单地一停了之。这个问题，虽然大家都知道它难做，但是却又不得不做，甚至原来一年只做一次，现在必须一年做四次，由此衍生出的问题，甚至超出了技术和纯业务范畴，影响到银行业的一些重组。这个就是银行系统的计息。
    银行是通过存贷利息差来获取利润的，因此结息无疑是经营活动中的大事，在几年前，对公结息和对私结息是不同的，企业户结息是每季度最后月的20号，储蓄户则是6月30号，现在，托国家的福，两者统一，都是一年计四次。在单点系统时代，每季度对公结息虽然比不上年终结转（那是银行业的佳年华会），也是除此之外最重大的事件，一般都要干到晚上两点钟。系统集中后，这个工作就收到总部，由系统自动处理，各网点只要第二天来打印计息单就可以了。
    不过，系统数据的集中，显然使看来已经轻松的工作重新变为一种负担，特别是储蓄计息变成一年四次更使这一问题尖锐起来。到现在已经不知道听到多少起这种事故，或者说，一直到现在，计息日都是科技人员关注的重点，不但影响到运营系统，甚至影响到管理系统。在这一天，平日里只有十几万条的业务会因为分户计息而充塞进上百甚至千万条（活期分户有多少就有多少条）的结息流水，平日里十分钟运行的程序，如果不加处理3个小时也运行不完。而稍微不注意，计息就有可能一直运行到第二天网点开业时都无法完成，这样又一起影响范围巨大的事故就诞生了。
    在今天这个银行业纵横捭阖的时代，这样的事故不但会影响银行的业务，还会被用作一块板砖，砸向任何用的着的地方。玄武湖畔的一只蝴蝶残缺了翅膀，一场将要发生的合并风暴因此而悄然收场，有些事情，曾经让大家想尽办法，却没有想到，结束竟然如此简单。

3想想年终结算 真是恐怖啊 盐城闲人 2008-08-23 02:59:26
元旦前一天晚上吃饭，吃过饭开始干活，要是有一分钱的账不平，都别想过。所有相关的厂商、软件商的技术人员都到场支持。吃的喝的堆满了桌子。

3上个世纪80年代北京某银行新系统第一次月结 zhonghm 2008-07-22 01:56:19
直至第二天中午10点都没出结果。传说所有开发人员在警察叔叔的监视下，坐在机房等结果。

这个是俺当年刚工作被前辈教育的第一堂课。公司的名字叫：南天信息。

4南天那时候真的是一霸, v22 2008-08-15 00:43:58
简称南霸天,是好利获得的总代,说好腰杆子挺得夯儿直

5好利获得结束了 被NCR收购了 盐城闲人 2008-08-23 03:13:57
现在银行提到好利获得还赞不绝口，说稳定、好用。

南天的PRII打印机真是风靡广大银行界。卖的爽呆了，而且还正好是2001年2002年那个IT寒冷的冬天。

3说到无索引查询，真是要了亲命了 1 贵中堂 2008-07-01 22:04:24
中堂公司是做外包的，客户的公司负责人喜欢提一些稀奇古怪的问题。

最近的就是要对一张数据条目超过4M，字段数超过200的表，做一个查询条件超过8个，包括有日期时间段的匹配和用户姓名的匹配的自由选择查询。

这难度真是。。。

4呵呵，原来的设计就做的太马虎吧 1 风北客 2008-07-03 00:11:13
原表不让加索引，因为还要不断的插入数据是吧？其实有些数据库加索引对这种级别数据也不会有太大影响。
这种情况，也可以做缓存表了， 一边定时生成缓存表，原表既然有日期字段做同步就比较简单了，另外一边查询先查缓存表，没命中再查原表。缓存表根据实际情况可能还可以做多级缓存，不过这样同步会比较麻烦。

400w记录，对于现在的数据库来说也就soso吧，呵呵，只要不是再关联一堆表就行。