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