❏ 站外平台:

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

作者: 东京IT人 雷子

| 2016-03-23 10:27   评论: 12 收藏: 2    

号外!号外!走过,路过,不要错过!日本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”的构建。这个新系统,依然由富士通负责开发。

法庭上撕得jichibailian,回过头来该干啥干啥——东证和富士通,还真是一对好基友啊!

(本文一部分图片来自网络)



最新评论

cinews [Chrome 31.0|Windows 7] 2016-03-29 08:16 回复
呵呵
来自上海的 Chrome 47.0|Windows 10 用户 2016-03-24 22:53 回复
66666
hellbeta [Chrome 45.0|Windows 7] 2016-03-24 16:35 4 回复
有点知乎的风格。
snowhawkyrf [Chrome 49.0|GNU/Linux] 2016-03-23 17:48 1 回复
真是神一样的转折!故事十分精彩,鼓掌!
CuriousBull [Chrome 49.0|GNU/Linux] 2016-03-23 16:43 2 回复
哈哈哈,边看边笑
绿色圣光 [Iceweasel 44.0|GNU/Linux] 2016-03-23 16:30 回复
哦,哈哈。
[1]
delectate [Firefox 45.0|Windows 10] 发表于 2016-03-23 12:05 的评论:
然而,乌龙指的事情并不少见。例如前几年A股的光大乌龙指,也是由于bug造成的,虽然用股指期货对冲,但是依然损失惨重。(更多详情:http://daily.zhihu.com/story/4880322)
前几月,有个人购买环保B(都怪这雾霾天啊),手残输入hhb(拼音缩写),默认是“回报B”,操盘手没仔细看,直接把它拉涨停了(更多详情:http://fund.eastmoney.com/news/1593,20150303482192518.html)。
在国外也并不罕见,尤其是高频交易盛行的美国,2010年曾经有过闪电崩盘的记录(更多详情:http://news.xinhuanet.com/world/2015-04/25/c_127730270.htm)。
来自新西兰的 Chrome 48.0|Windows 8.1 用户 2016-03-23 15:23 2 回复
您也手残了...
来自天津的 Sina Weibo 6.3|Android 4.4 用户 2016-03-23 14:57 7 回复
哈哈哈  微软真赔的话裤衩都不剩
来自云南昆明的 Firefox 45.0|Windows 7 用户 2016-03-23 13:12 2 回复
我只是来看配图的
来自四川成都的 Chrome 49.0|GNU/Linux 用户 2016-03-23 13:01 回复
之前有相当长时间把新垣结衣的“垣(yuan4)”,错读成“恒(heng2)”。
POCMON [QQ Browser 9.3|Windows 10] 2016-03-23 12:05 6 回复
有没有BUG都不重要,重要的是“你应该做的事情”,你做了没有~

返回顶部

分享到微信

打开微信,点击顶部的“╋”,
使用“扫一扫”将网页分享至微信。