关注微信号:javalearns 随时随地学Java
或扫一扫
随时随地学Java
号外!号外!走过,路过,不要错过!日本 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),回过头来该干啥干啥——东证和富士通,还真是一对好基友啊!
关注微信号:javalearns 随时随地学Java
或扫一扫
随时随地学Java