if(400亿==Bug)由程序猿负责?

 

因BUG引起的天价损失,是否该由程序猿负责?...







今天事件的程序猿哥哥呢

我们先叫他凌八哥好了

凌八哥是一个苦逼的富士通程序员

整天帮公司给甲方开发一些

没什么新意的软件



万万没想到,

有一天他接到了一封起诉书

哎哟我天,

长这么大连情书都没收过!

竟然收到起诉书!



这次诉讼是关于2000年

给东京证券交易所开发系统时

他写进去的一个bug

说起来真的是满脸无辜

这个bug非常不起眼

而且在特定的组合条件下才会出现

因此在多次测试、验收中

都没有人发现

(下图是包含了bug的cobol代码)



就是这么一个不起眼的bug

然而凌八哥就是这么倒霉

偏偏就贪上了大事了

用这个软件的人

是日本瑞穗证券的一个交易员

我们先叫他寿参君好了

2005年12月8日,

是J-COM公司上市的日子

寿参君接到一位客户的委托:

“请以61万日元的价格,

卖出1股J-Com的股票

这种本来很基础的操作

结果寿参君硬是在系统上输成了

以每股1日元的价格,

卖出61万股

呵呵哒。

你说你怪谁?

发生这种事你还能怪谁?

大家有没有遇到过这种事

跟微信发红包有点像

有时候你想发61个1块钱的红包



一不小心发成了1个61块钱的红包



然后有一个不认识的人

迅雷不及掩耳抢走了红包

等你反应过来的时候

那个人已经退群了!



这种情况还算好的

证券系统上由于有限制

不可以卖1日元这种价格

所以系统还自动给他调整成了

以57万日元出售61万股

真的是...



事情发展到这里

都完全是手抖交易员的错

跟程序员没有半毛钱关系

但是——

后来,寿参君尝试弥补

2分钟后,他终于发现了这个错误~

握草,你咋不明天发现呢?

然后他试图撤销这笔交易

可是3次撤单指令

都被交易系统拒绝了

对,这个地方就是那个

凌八哥的那个bug!

当时的场面大家想象一下

一方面是寿参君整个人已经懵逼了

连带他的瑞穗证券的管理层也懵逼了



但是另外一方面

当天J-COM的股票开盘一度有91万元

然后因为这个57万元的大单

就开始一直狂跌

散户们先是惊慌失措,各种抛售

然后反应快的竞争对手和大户已经猜到

啊,一定是哪个手抖的乌龙指了!

然后就在那里疯狂抢购

有便宜干嘛不占啊!又不是智障

然后由于57万日元已经是相对低价了

接着又引发日本大妈跑步进场

各种抄底扫货一抢而空



这个场面。。。

没能目击真是我本世纪最大遗憾

还不止是这样

当时“有一个券商出了乌龙指”

这个消息不胫而走

所有股民都知道了

在还不知道是哪家券商的情况下

所有券商股票都惨遭抛售

如果各大券商们将来知道这一切

都是因为寿参君的话

恐怕他很难再在这一行混了。。

请计算寿参君的心理阴影面积

还没完啊,为了止损

瑞穗证券又决定自己反向买入J-COM股票

于是加入抢购的大军

就在这样各方疯抢的情况下

J-COM的股票一度又被拉高到

77.2万日元

最后到当天交易结束

瑞穗证券一共损失了约270亿日元



J-COM的主要发行商日兴证券

股价一度狂跌8%

当时大盘日经指数应声下跌301点

卧槽,竟然只下跌301点

下跌3000点我们中国股民都挺过来了!

301点多大点事?

虽然收盘了,但是悲剧还没结束

因为J-COM的股票

一共只发行了14000多股

现在这61万股

难道要画出来?



(原谅我今天画性大发)

最后经过协商

瑞穗证券用每股91万日元的价格

现金清算了股民手上的9万多股

还好剩下的都被自己反向买入了

但是这样一来

真的是雪上加霜

他们的损失扩大到400多亿日元

据事后统计

这些钱有40%被6个著名金融机构瓜分了

包括瑞士银行,摩根斯坦利,日兴证券,

雷曼兄弟,瑞士信贷,野村证券

他们趁火打劫了168亿日元之后

扭扭捏捏不想把钱还回来

真是令人心寒啊~

不过这些跟我们都没啥关系了

只能看看

话说瑞穗证券从此受到重挫

据说这400亿比他们一整年的利润还多

而当事人本人的姓名

一直没有被公布

这个公司也算是良心啊

所以我们在这里

只能让他化名为寿参君=手残君了~

只不过,本来公司正在计划发年终奖的

这些全体员工的年终奖

都变成西北风了~~

好了,背景前戏告一段落

下面瑞穗开始追责了

噢,正片终于开始了~



瑞穗认为

自己在事发后的2分钟

就已经尝试撤销交易

但是由于系统bug

导致他们没能及时止损

在取消指令发出之前的损失自己认了

但是那之后的损失

应该由东京证券来买单

说的也算是有理有据

很快,东证社长鶴島琢夫

因为此事引咎辞职。

但是,东证没打算背这个锅

他们把责任全部推到

当初承包这个项目的富士通身上,理由是:

我的需求里,

是明确写明可以撤单的

是你开发的系统没有符合我的需求

富士通的表态更加坚决:

我去,你手残你怪谁呢?



双方就这样开始扯皮

谈来谈去谁也不肯让步

于是,2006年9月

瑞穗把东证和富士通告上了法庭

开始了漫长的十年诉讼之路

其实吧,在我们看来

这件事寿参君肯定是主要责任

任何系统,都不可能完全没有bug

任何测试,都不能确保测出每一个bug

否则的话,我每次电脑蓝屏

都损失了好几行劳动成果

如果这些都要赔钱

世界上最大的bug生产商——

微软,早就赔得连内裤都不剩了



关于这个案子

东京地方法院给出的判定是:

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

那么问题来了,

什么样的bug算是“重大过失”呢?

法院给出了判断的标准:

这个bug是不是很容易被发现。

于是,控辩双方都请来了资深程序猿专家

在法庭上当庭 review 代码

蔚为壮观

让我想起了乐视的庭审~~

穗瑞专家组:

这种bug都测试不出来?妈的智障~~

富士通专家组:

这么复杂的bug,

你给我马上重现一个试试?

你行你上,no can no bb!

而此时的法官表面上

泰然自若胸有成竹

而他的内心os:



总而言之,

在这场盛大的当庭撕代码之后

最终东京地方法院判定:

程序bug并不能算是重大过失,由这部分导致的损失无需赔偿。



但是,在瑞穗证券电话联络东证交易所后,东证未能履行中止异常交易的职责,属于重大过错方。另一方面,事情的起因是由于瑞穗证券的乌龙指,所以瑞穗证券也不能完全免责。从电话联络那个时间点以后产生的损失,由东证承担70%,107亿日元。

瑞穗证券和东证

都对这个审判结果表示不满,

上诉到东京最高法院。

2015年9月3日,

东京最高法院驳回上诉,

维持原判结果。

长达10年的诉讼终于尘埃落定



各位程序猿哥哥是不是

觉得心里暖暖的呢

法律是站在程序猿这一边耶

其实并不是。。。

“bug是否很容易被检测出来”这一点,

从此将会成为此类诉讼的判断标准。

所以万一被判定成重大过失,

程序猿们可真是欲哭无泪了。

本案也让东证认识到,

旧交易系统的老朽化以及bug过多等缺陷。

以瑞穗证券乌龙指事件为契机

他们开始了金融行业的重大项目

开发全新的交易系统

这个新系统,

依然由富士通负责开发。

你们这种基友真的是真爱好嘛~



至于那位凌八哥

就没有再接这个case了

他痛定思痛

回去改了个名字叫

凌八哥 = 0 bug

希望大家坚挺在编程第一线

每天都 0 bug 好嘛~~


    关注 猿带马


微信扫一扫关注公众号

0 个评论

要回复文章请先登录注册