程序Bug导致了天大的损失,要枪毙程序员吗?

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了程序Bug导致了天大的损失,要枪毙程序员吗?相关的知识,希望对你有一定的参考价值。

 

转自 http://www.cocoachina.com/programmer/20160331/15835.html

 

号外!号外!走过,路过,不要错过!日本 IT 业的狗血八卦继续独家放送啦!!

2015 年 9 月 3 日,随着东京最高法院驳回瑞穗证券的上诉,维持二审的原判结果,一个长达 10 年的诉讼终于画下了句号。这个判例将对 IT 行业产生深远的影响:如果程序的 bug 导致了巨大的经济损失,应该由谁来承担?用户?运营商?还是系统开发商?

bug:计算机程序里的错误

今天故事的主角是,瑞穗(みずほ)证券,东京证券交易所(下文简称东证),和富士通。

各位富士通的同学,雷子真的不是富士通黑啊。你们公司行业内第一,项目多,所以卦点就多啊!要是又一次伤害了你们的感情,看下图能原谅我不……

技术分享

嗯,该说的也都说过了,下面正式开始。

(一)瑞穗证券的乌龙指事件

如果时光能够倒流,让瑞穗证券的交易员田中君(化名)穿越回 2005 年 12 月 8 日东证开盘前的那几分钟,田中君会不会选择把自己那根乌龙指给掰断呢?

乌龙指(fat finger):是指股票交易员、操盘手、股民在交易的时候,不小心敲错了价格、数量、买卖方向等。

正是由于田中君的一次错误输入,让他所在的瑞穗证券遭受了超过 400 亿日元的天价损失。虽然日元那面额画得跟冥币似的,400 亿日元也还是相当值些银子滴(按照当时的汇率,约为人民币 27 亿元)。

这天,是日本公司J-Com 首次公开上市(IPO)的日子。上午9:27,距离开盘还有几分钟。田中君接到一位客户的委托:“以 61 万日元的价格,卖出 1 股J-Com 的股票”。田中君接到委托后,在瑞穗证券的交易终端上,错误地输入了“以每股 1 日元的价格,卖出 61 万股”。

指令发出后,瑞穗证券的交易软件检查到这是一个异常的交易订单,给出了一个警告的对话框。可是,像瑞穗证券交易员这种级别的操盘手,玩的就是不按套路出牌,每天这种警告对话框见得太多了好么。田中君甚至都没有好好读一下对话框里的内容,就按下了确定按钮。于是,这个巨大的卖单就挂在了东证的交易盘口上。

 技术分享

2 分钟后,田中君发现了这个错误,赶紧试图通过交易软件撤销这笔卖单。可是连续输入 3 次撤单指令,都被东证的交易系统拒绝了(后来查明是由于交易系统的 bug 所致)。

田中君又迅速给交易所的负责人打电话,要求将这个卖单撤下。交易所的人表示:“我们无权操作,这个问题只能你们自己想办法”。

这时盘口交易已经开始。这个巨大的卖单首先将开盘价定在了 67.2 万日元,然后又依次将所有买单成交,最终将J-Com 的股价钉死在跌停价 57.2 万日元上。(与天朝不同,日本的涨跌停价并不是严格的按照 10% 来计算,而是根据开盘价确定出一个整数的价格范围)

此刻市场内一片大乱。散户们被这个巨大空单吓得惊慌失措,以为J-Com 公司出了什么问题,纷纷跟风抛售。而一些机构和大户已经猜到是出了乌龙指,迅速在跌停价买进。一些有节操的机构,例如德意志证券,买了几手后觉得实在是太不厚道,自觉停止了抢购。而大部分机构纷纷表示:节操才多少钱一斤,有便宜不占王八蛋啊!抢得不亦乐乎。

可能有同学不太懂股票交易,大概就是下面这种赶脚。

本来,客户的委托是下面这样的……

技术分享

然而,手残的田中君把数字输入错了……

技术分享

但是,股票价格有涨跌幅限制。所以页面发布以后,系统又自动把价格改成了下面这样……

 技术分享

就算是 57 万,也是非常便宜了好么!大妈,不,大户们迅速围观,争相爆买……

 技术分享

在股市这个游戏规则里,只要你卖出的股票有人接了,那成交后就必须把货交给买家才行。可是,J-Com 的股票一共才发行了 14000 多股,大部分还由公司高管持有,真正在市场上流通的也就 3000 多股。61 万股,让瑞穗上哪里去弄?总不能自己在家里画啊!

没有办法,瑞穗证券只好发出了反向买入的决定,开始和其他人一起抢购筹码。这样一来,J-Com 的股价又被拉高到涨停价 77.2 万日元,一直持续到当天的交易结束。在当天的交易中,瑞穗证券一共损失了约 270 亿日元。

技术分享

受到影响的不仅仅是J-Com 的股价。瑞穗证券直到当天收盘后,才向外界披露了这一乌龙指事件。而在当天的交易过程中,市场上已经有传闻,一家证券公司搞出了乌龙指,将有重大亏损。由于不知道是哪家券商出了问题,所有券商股票都惨遭抛售。

这下证券公司都哭了,纷纷发表声明:股东老爷们,真的和我没关系啊……然并卵。其中最惨的是J-Com 上市的主要发行商——日兴证券,股价一度狂跌了8%。而这股不安情绪也影响了所有投资者。当天收盘时,日经指数大跌了 301 点。

(二)事后收场

首先是成交单的交割问题。不存在的股票怎么交割啊?虽然瑞穗证券通过回购,抢回了大部分的卖单,但还是有 9 万多股被其他机构和散户买走了。根据规则,瑞穗必须在 3 天之内交货(日本的交割日是T+3)。前面说过,市场上一共才流通了 3000 多股J-Com 的股票,这 9 万多股真是逼死瑞穗证券也拿不出来啊。

技术分享

最后经过协商,买卖双方同意用现金来结算。清算的价格定在了每股 91 万日元——这是瑞穗证券敲下乌龙指前一刻的股票价格。这次现金交割又让瑞穗证券雪上加霜,损失扩大到 400 多亿。

至于当事人田中君,似乎并没有受到太严厉的惩罚。瑞穗证券至今也没有公布当事人的真实姓名,只知道是一名男性证券经纪人。事件发生时,正赶上日本公司要发年终奖。就因为田中君的一个错误操作,一下子把公司一整年的利润都给干掉了,让瑞穗证券所有员工的年终奖都泡了汤。有传闻,田中君成了瑞穗证券里“最讨厌的人排行榜”的 No.1。

那些趁火打劫的机构大户也受到了指责。事后查明,共有 22 家机构在此次乌龙指事件中获利。其中瑞士银行,摩根斯坦利,日兴证券,雷曼兄弟,瑞士信贷,野村证券这六家机构,从这次事件中一共瓜分了 168 亿,占瑞穗证券损失的 40% 还多。

尽管这钱来的不太光彩,可毕竟是按照市场规则赚来的,所以金融监管部门只能从道德层面对这些公司进行谴责而已。有人提议,让这些公司把赚到的钱吐出来。这些公司表示:这样做,等于把公司的利润白白送给别人,没法向自己的股东交代啊。

技术分享

后来在各方的调节下,一部分获利的证券公司同意把钱拿出来,成立一个保护投资者利益的基金,这是后话了。

在这次事件中,东证交易所受到了最多的质疑。首先瑞穗证券在意识到错误挂单后,曾经多次发出取消的指令,但都被交易所的系统所拒绝,这显然不符合系统的交易规则。其次,在瑞穗证券与东证负责人取得了联系的情况下,东证方面仍然放任这笔卖单继续执行,有监管不力之嫌。事后,东证社长鶴島琢夫引咎辞职。

瑞穗证券方面认为,正是由于东证的过错,才让自己蒙受了 400 亿日元的损失。这个错误理应由东证来买单。东证的观点是:你自己乌龙指敲错了指令,凭啥赖在我身上?对此,瑞穗证券回击:取消交易指令发出之前的那段时间,产生的损失自己认了。但是还没成交的卖单为啥不让人家撤销?

两个公司之间扯来扯去,也没把这个问题谈拢。于是,2006 年 9 月,瑞穗一纸诉状,把东证以及交易系统的开发商——富士通告上法庭。就这样,漫长的诉讼开始了。

技术分享

(三)法庭诉讼

对于这个案件,事实已经很清楚了:由于交易所的系统 bug,在特定的条件下,会发生不能撤单的现象。经过详查得知,这个 bug 是富士通的技术人员在 2000 年某次程序修改时,不小心埋进去的。

本来,程序修改后必须经过严格的回归测试,来验证对其他业务流程有没有影响。可是不仅富士通忽略了这个测试,东京证券交易所在系统验收测试(UAT)的时候,也疏忽了这方面的内容。结果,炸弹在这个时间点被引爆了。(下图是包含了 bug 的 cobol 代码)

 技术分享

围绕着这个事实,第一个争论点是:东证和富士通,应该为瑞穗证券的损失负责吗?

起初,东证还想耍赖,把错误全部推在富士通身上。东证主张:就算是交易系统的 bug 导致了瑞穗证券的损失,那也是富士通的错。因为我的系统需求里面,是明确规定了可以撤单的。富士通开发的程序没有符合我的需求,才导致了这样的结果。

对于东证的这个主张,东京地方法院判定:这个系统的主要责任人是东证。富士通只是东证的系统供应商,属于连带责任人。无论是主要责任人还是连带责任人,如果被证明犯有重大过失,都应该做出赔偿。

那么,程序的 bug 算是“重大过失”吗?这很难说。一个系统里有没有隐藏的 bug,是没法从理论上证明的。就算是测试再彻底,也会有测不到的 bug 流出来。所以在法律上,通常不会把所有因为 bug 导致的损失都归罪给程序开发商。否则的话,世界上最大的 bug 生产商——微软,早就赔得连内裤都不剩了。

技术分享

这就带出了本案第二个争论焦点:什么样的 bug 才算是“重大过失”?法院给出了判断的标准——这个 bug 是不是很容易被发现。

于是,控辩双方都找来了由资深程序猿和攻城狮组成的砖家组,在法庭上撕成一团。

穗瑞砖家组:卧槽,这个 bug 简直太明显了好么?连这个都测不粗来,请问贵司人员的编程,都是音乐老师教的吗?

 技术分享

富士通砖家组:異議あり!这么复杂的条件组合,你特么能一下子就找出 bug 来啊!你们败吹牛逼了行不行!

 技术分享

双方的砖家团吵来吵去,谁也说服不了谁,干脆,在法官面前开始 review 起程序代码来了。

而此刻的法官,表情是很镇静的……

 技术分享

但是在法官的心里,简直有一万匹草泥马奔腾而过啊!

技术分享

争辩到最后,一脸懵逼的法官表示:你们说得好像都挺有道理的……但是意见相反,所以也不能判定成容易发现…….富士通就不用赔了!

 技术分享

最终,东京地方法院判定:程序 bug 并不能算是重大过失,由这部分导致的损失无需赔偿。但是,在瑞穗证券电话联络东证交易所后,东证未能履行中止异常交易的职责,属于重大过错方。另一方面,事情的起因是由于瑞穗证券的乌龙指,所以瑞穗证券也不能完全免责。从电话联络那个时间点以后产生的损失,由东证承担 70%,107 亿日元。

瑞穗证券和东证都对这个审判结果表示不满,上诉到东京最高法院。2015 年 9 月 3 日,东京最高法院驳回上诉,维持原判结果。长达 10 年的诉讼终于尘埃落定。

(四)深远影响

看到这里,程序猿和攻城狮应该是松了一口气吧,终于不用为自己写的 bug 而买单了。

但是且慢!根据这个判例,“bug 是否很容易被检测出来”这一点,将会成为今后类似诉讼的判断基准。一旦被判定成重大过失,程序猿们可真是欲哭无泪了。

现在问题来了:身为程序猿,谁也不能保证自己的代码里没有 bug。该如何做,才能避免陷入到这种境地中呢?

雷子觉得,既然无法从理论上证明程序里所有的 bug 都被检测出来,那么,一些行业内公认的指标,例如测试时的 case 密度,bug 密度等,很可能会成为测试是否充分的判断依据。(对,就算没有 bug 我们也要制造出来!)

此外,bug 对应得是否充分,也会成为判断的重要基准。一个 bug 被发现后,有没有进行深刻的挖掘也是很重要的,即所谓的“横展開”。看到这个词,估计很多同行会做噩梦吧!这个话题很大,雷子今后另起文章和各位同行探讨。

还有一点不要忘记,无论是测试结果也好,还是 bug 的对应结果也好,

要留证据!

要留证据!

要留证据!

重要的事情说三遍。

本案也让东证认识到,旧交易系统的老朽化以及 bug 过多等缺陷。随着近年来程序化交易的盛行,旧系统已经越来越无法满足现代证券交易的需要。比起伦敦和纽约等地的证券交易所来,当时东证系统的响应时间要慢 100 倍啊。

以瑞穗证券乌龙指事件为契机,导出了 2010 年金融行业的重大项目——东证次世代的交易系统“arrowhead”的构建。这个新系统,依然由富士通负责开发。

法庭上撕得面(ji)红(chi)耳(bai)赤(lian),回过头来该干啥干啥——东证和富士通,还真是一对好基友啊!

 技术分享

 

以上是关于程序Bug导致了天大的损失,要枪毙程序员吗?的主要内容,如果未能解决你的问题,请参考以下文章

离职两年后,程序员遭前东家索赔:Bug 是你写的

离职两年后,程序员遭前东家索赔:Bug 是你写的

程序员写的东西出了bug,造成了损失谁来承担?

盘点程序员写过的惊天 Bug:损失 3 千万不算啥,就差毁灭世界了!

一个小小的程序Bug竟值400亿?

SQL Server 子查询会导致性能损失吗?