TA的每日心情 | 慵懒 2016-4-20 00:14 |
---|
签到天数: 15 天 [LV.4]金丹
|
6#
楼主 |
发表于 2011-12-22 22:37:32
|
只看该作者
本帖最后由 河蚌 于 2011-12-23 09:59 编辑 - j/ q& W! A7 G) U0 T1 V4 E
& X3 b2 b6 t* }% ?) S( Z六% F2 p" ~, p- x4 I6 d* F
4 T% G4 J: n# y. u 银行的任何运营系统都涉及到钱,而且这里的钱还是数字的,加一个零就翻一个数量级,俺有时经常想,抢现金的人真没有技术含量,你即使开着个大卡车来,也不过抢几亿元走,对于玩数字的人来说,不过是一个10位数字而已,这样的损失,其实俺们动一下小手指就能做出来,当然更多时,这样的情况,更多就是一个笔误,好吧,换一个说法,俺们写程序写错了。
; r# _; o5 U& Z' d, @- e9 } 在软件开发时,经常说的一句话就是,能够在程序中校验出来的错误不是错误,那只能称作“例外”。真正的错误,是那些你预想不到的,不知道什么时候发作出来的错误,它们充满了偶然,总会出现在你意想不到的地方,而造成的损失,则会让你刻骨铭心,终生永记,因为这些可能都是钱。因此在银行工作期间,总有一种如履薄冰的感觉。
" l4 C; U, i! @ l 其实银行软件开发时是蛮辛苦的,不知道是什么时候哪位爷(其实我心里更想叫丫孙子)定下的作息时间,一周6天周一到周六,除了白天正常工作外,晚7点到10点要加班,只周三和周六除外。这样坑爹的制度,竟然成了银行软件开发的标准制度,其实很多时候,晚上就是在耗时间。但是工作时间虽长,心情却是轻松的,因为毕竟是在实验阶段,犯了什么错误,都可以重来,即使编了几天的程序忽然没有了,还得强忍着再重写一遍,却也可能因为思路更清晰,写出程序会更快更好。对于银行科技人员来说,真正开始提心吊胆,是从程序上生产机的那一刻开始的。
$ n* [# X, d9 I% ^$ I+ W3 z1 \: T 记得有本编程的书里将软件的错误分为四个级别:崩溃、严重、一般和提示,这四个级别都是用来定义软件的技术错误的,从无法运行到信息提示不对,一级比一级轻。应该说,这样的错误级别设定用来衡量码农的工作质量,不让无证码农蒙混过关酿成追尾事故,是完全足够了。但要说这些技术错误级别就等同造成的损失级别,这咱就不能认同,其实这两者之间,真的没有什么必然的联系,甚至,还可以说是相反的,因为一个无法运行的东西,它想造损失也得有这个能力,是吧。0 X( q- H0 _% X. b: g& `7 h( Y, k
测试时一切OK但运行时却出错的程序,是每一个银行IT人员的梦魇,应该说,几乎所有的人都能痛说几段不堪回首的往事。比如俺10年前在一家银行做储蓄系统优化时,就曾经在系统上线的头两天,连续三次提交更新程序,当时以为自己就够熊的了,回头一打听,才知道,其实俺这是更新的最少的。俺们的这些程序,可都是经过自己测试过无数遍,又经过近百名业务人员三次大规模业务测试后的结果。现在回想,其实这还真不算太大的错误,毕竟只是定期一本通换折时打不出已经销户的记录,这样的错误只是带来不便,还没有造成直接的损失。但有些错误就没有那么幸运了,当钱已经发到个人手里时,想找回来可没那么容易,尤其是在大批量出错的时候,这就只能算事故了。
- ]$ A2 f: ? o6 U5 ~# l$ F 在银行的系统中,除了为大家存着钱的主机系统外,还有一个对于外人来说根本看不见的系统也是至关重要的,那就是被命名为渠道接入或者综合前置的交易集中转发系统。这个系统对于银行就如同主神经之于人体,银行的外围系统都是通过它来与主机系统打交道,甚至系统之间的交互也必须通过这个系统来完成。虽然它不存储业务数据,但是银行日常的所有业务几乎都要通过这个系统来上传下达,而如同人的神经一样,这个系统由于联系太过广泛,却极易受到伤害。回首工作经历,俺记忆最深也最感到幸运的,也是这样一个发生在交易转发系统上的错误。
, x+ t$ b- C$ m5 i8 x" L, U, D 当时,还没有渠道接入系统的概念,我们只是做了一个简单的前置程序,将自助电子设备(ATM、POS)上发生的业务先集中发给这个程序,再转发到主机上。应该说,对于银行的主机来说,所有的外围系统都是客户请求端,而主机系统对于请求可能有三种结果,返回成功、返回失败和无应答。前两种处理起来都很标准,只是最后一种无应答却是很难处理的。8 l3 M. n+ A) F, {) |
因为你不知道主机到底是什么状态,或者说很多原因都会导致这种情况,可能是业务程序直接出错崩溃了,也可能只是系统处理比较慢。但无论是外围系统还是转发程序都不可能无限期等待,因此,每一个请求都会有一个超时设定,超过这个时间,就会自动返回出错,然后再向主机系统发起一个撤销交易的请求。( L3 a2 ~, j: ]- n% f* i
上面的过程说起来就比较繁复,真正运行起来,就更为繁复,而且还有个问题需要解决,一笔正常业务没有应答,接着发出的撤销交易请求很大的可能是主机也会处理失败,也就是说,正常交易并不能会被撤销掉。因为这个原因,当时对帐总是不能完全对上,于是项目组中有人就做了一个重复发送撤销交易的程序,将那些无响应的交易找出来重新发一遍撤销请求。
% j$ U9 @: Z U! H" M 按照原理,这样的程序其实流程并不复杂并不难,但不知道什么原因,反正写程序的将逻辑搞反了,竟然是将所有的成功交易找出来发起撤销,按照这个逻辑,任何人都可以在ATM上随意取款,因为取款成功后,撤销程序就会将账户余额恢复回去,但是银行可没办法让ATM长出手将已经到了客户手中的现金再拿回来。应该说,当时我们的测试还是不完善,这个运行正确但逻辑错误的程序就上了生产机,而且是周五快下班时上的。2 O5 b- Y0 S h* R/ { D& C' r8 }
研发人员平时并没有运行监控的任务,也都是正常下班。那天,我不知道出于哪门心思,跑到监控室转了一圈,扫了一眼监控屏,马上就意识到不正常,因为交易屏中撤销交易太多了。赶紧让运行人员将前置程序停下来,此时,什么ATM停运多少小时要处罚的规定就顾不上了,那个毕竟是面子问题,现在的这个错误,可是里子,不,是钱的问题。
* e) |4 d) B" ~' C8 T+ o- K. _ 此时,已经有二百多笔交易出错了。还好,大部分错帐都可以恢复,即使是帐不可恢复,当时的人大多有根脚,问他们要,他们也不会因为几千元钱就给自己找麻烦,当然,最终还是有二笔交易一万多元没法挽回,好在这点损失,对于银行来说,不算太多。6 z+ t6 Z3 c: n, P8 p# J" Z# B
每次回想起这起事故,我都为我无意中去监控室而感到幸运,因为,我们周六周日不上班,而从周五到周日正是卡交易最活跃的时段。指望运行监控人员发现问题是不可能的,当时俺去看时,那帮人也正直着眼睛盯着呢。天知道错误会如何被发现,也许会是某个热心的客户打进来热线,或者干脆是新视点当作奇闻报道之后,俺们才能知道。到那时,就不知道有多少笔错帐,而无法挽回的,恐怕也不会只是区区两笔一万元了。! r7 N/ d% c8 E* J+ R, \: e
银行当时正在大搞企业文化,宣扬什么理念和座右铭,其中一句至今还记忆尤新,”我的微小疏忽,可能给客户带来很大麻烦,我的微小失误,可能给银行带来巨大的损失“,诚不吾欺!!# Q6 F3 \" D' F4 r
|
|