| 网站首页 | 业界新闻 | 小组 | 威客 | 人才 | 下载频道 | 博客 | 代码贴 | 在线编程 | 编程论坛
欢迎加入我们,一同切磋技术
用户名:   
 
密 码:  
共有 4430 人关注过本帖
标题:程序bug导致了天大的损失,要枪毙程序猿吗?
只看楼主 加入收藏
TonyDeng
Rank: 20Rank: 20Rank: 20Rank: 20Rank: 20
等 级:贵宾
威 望:304
帖 子:25859
专家分:48889
注 册:2011-6-22
结帖率:100%
收藏
已结贴  问题点数:100 回复次数:12 
程序bug导致了天大的损失,要枪毙程序猿吗?

作者:雷子


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),回过头来该干啥干啥——东证和富士通,还真是一对好基友啊!
搜索更多相关主题的帖子: 计算机程序 富士通 名词解释 最高法院 运营商 
2016-03-26 20:59
TonyDeng
Rank: 20Rank: 20Rank: 20Rank: 20Rank: 20
等 级:贵宾
威 望:304
帖 子:25859
专家分:48889
注 册:2011-6-22
收藏
得分:0 
剛看到一個問帖,突然想發一發此帖,順帶說一句:如果判題系統能夠評價一個程序完全沒問題,也不會有這類事情發生了。程序寫是否寫得過關,不是這麽判斷的,也不能靠這個,太著迷提交判題系統的,唉……你真以爲AC了就是高手了?

授人以渔,不授人以鱼。
2016-03-26 21:05
TonyDeng
Rank: 20Rank: 20Rank: 20Rank: 20Rank: 20
等 级:贵宾
威 望:304
帖 子:25859
专家分:48889
注 册:2011-6-22
收藏
得分:0 
看看許霆案,明明就是程序bug,雖然許霆是惡意提款行爲,但至少ATM機供應方要承擔一部分責任,他們卻連這一點責任都不承認,根本不觸及這一點。中國的司法跟日本比,差遠了。

授人以渔,不授人以鱼。
2016-03-26 21:16
tlliqi
Rank: 19Rank: 19Rank: 19Rank: 19Rank: 19Rank: 19
等 级:贵宾
威 望:204
帖 子:15453
专家分:65956
注 册:2006-4-27
收藏
得分:34 
慢慢看看这个故事
2016-03-26 22:31
luckhide
Rank: 5Rank: 5
来 自:青岛
等 级:职业侠客
帖 子:51
专家分:338
注 册:2016-3-19
收藏
得分:34 


[此贴子已经被作者于2016-3-27 09:09编辑过]

2016-03-26 23:10
诸葛欧阳
Rank: 19Rank: 19Rank: 19Rank: 19Rank: 19Rank: 19
来 自:流年
等 级:贵宾
威 望:82
帖 子:2790
专家分:14619
注 册:2014-10-16
收藏
得分:34 
再接一次

一片落叶掉进了回忆的流年。
2016-03-27 17:10
TonyDeng
Rank: 20Rank: 20Rank: 20Rank: 20Rank: 20
等 级:贵宾
威 望:304
帖 子:25859
专家分:48889
注 册:2011-6-22
收藏
得分:0 
日本有一點是很需要中國人學習的,就是不遷怒于人。程序有bug,儘管那個人在公司內部成爲最討厭的人,但從外到內,都沒有公開他的名字,更沒有公開處理他,倒霉的反而是社長。依據客觀事理辦事,當代中國人做不到,總是急於找替罪羊,這思維方式非常要不得。反觀中國的高鐵事故,鐵道部的上司是不用負責的,倒是判官,一言九鼎,劉志軍必須下馬,於是下馬,該負責的領導者反而是正義審判官得聲譽。講法治,當代中國人沒有資格。

日本民族就是抱團的族群。個別人在外被綁架勒索,自身及其家屬都是公開向國民道歉,“給大家惹麻煩了”,但在中國是絕對不會的,給祖國惹麻煩非但沒有歉意,反而炒大綁架政府去搭救,那些在外國機場唱國歌“維權”的就是,丟人到家,但你還是迫於責任去解救,而他們卻因此不斷地給你惹麻煩,同類事件一而再再而三而發生,就是明證。

[此贴子已经被作者于2016-3-27 18:41编辑过]


授人以渔,不授人以鱼。
2016-03-27 18:33
TonyDeng
Rank: 20Rank: 20Rank: 20Rank: 20Rank: 20
等 级:贵宾
威 望:304
帖 子:25859
专家分:48889
注 册:2011-6-22
收藏
得分:0 
這個案例,責任界定很清楚:程序有bug,但僅應負責到人工干預的時刻前爲止,當人正式通知“手刹”的時候,是沒有理由以機器設置爲由拒絕執行的,那就是你公司管理制度問題(任何電腦系統不給特殊權限人士以最高管理權控制非常規操作是不可能的,庫克就是大腦不正常才是基佬),所以社長引咎辭職是正確的。損失的大部分,不在程序bug那裏產生,而是因你拒絕人工干預造成,故不應追究到程序猿身上,但也有其直接責任,麻煩就是你的bug造成,所以引人討厭。

日本佬爭吵、打架、打官司,完畢之後該是怎麽做還是怎麽做,不會貿然分道揚鑣翻臉成仇,該合作還是合作。中國人不會這樣,還總是以自己的特點推測對惡意。

授人以渔,不授人以鱼。
2016-03-27 18:54
TonyDeng
Rank: 20Rank: 20Rank: 20Rank: 20Rank: 20
等 级:贵宾
威 望:304
帖 子:25859
专家分:48889
注 册:2011-6-22
收藏
得分:0 
。。。

授人以渔,不授人以鱼。
2016-03-27 18:54
风吹过b
Rank: 20Rank: 20Rank: 20Rank: 20Rank: 20
等 级:贵宾
威 望:364
帖 子:4938
专家分:30047
注 册:2008-10-15
收藏
得分:0 
发现我竟然看完了

授人于鱼,不如授人于渔
早已停用QQ了
2016-03-27 21:52
快速回复:程序bug导致了天大的损失,要枪毙程序猿吗?
数据加载中...
 
   



关于我们 | 广告合作 | 编程中国 | 清除Cookies | TOP | 手机版

编程中国 版权所有,并保留所有权利。
Powered by Discuz, Processed in 0.017229 second(s), 8 queries.
Copyright©2004-2024, BCCN.NET, All Rights Reserved