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

0 引言

年会上Review 源代码算什么？ 法庭上 Review code 才带劲.....

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

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

1 瑞穗证券的乌龙指事件

如果时光能够倒流，让瑞穗证券的交易员田中君(化名)穿越回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公司出了什么问题，纷纷跟风抛售。而一些机构和大户已经猜到是出了乌龙指， 迅速在跌停价买进。一些有节操的机构，例如德意志证券，买了几手后觉得实在是太不厚道，自觉停止了抢购。而大部分机构纷纷表示：节操才多少钱一斤，有便宜 不占王八蛋啊！抢得不亦乐乎。

1.1 图解乌龙指事件

本来，客户的委托是下面这样的......

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

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

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

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

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

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

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

2 事后收场

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

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

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

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

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

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

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

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

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

3 法庭诉讼

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

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

争论

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

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

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

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

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

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

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

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

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

• 而此刻的法官，表情是很镇静的......

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

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

判决

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

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

4 深远影响

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

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

现在问题来了：

• 身为程序猿，谁也不能保证自己的代码里没有bug。该如何做，才能避免陷入到这种境地中呢？

雷子觉得：

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

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

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

要留证据！
要留证据！
要留证据！
重要的事情说三遍。

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

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

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