这么惨的损失，瑞惠整年的利润都报销了，全体员工翘首以盼的年终奖也挥一挥衣袖，让你摸不着踪影了。这么大的黑锅谁来背？瑞惠？东证？富士通？手捧传票心胆具颤的程序猿小哥？

瑞穗认为，事发后2分钟自己已提交撤销交易请求，但由于系统bug，4次撤销请求均被拒，直接导致损失大到难以承受的地步。之前的损失也就算了，撤销请求提交后造成的损失应该由东京证券来买单(你赔，你赔，你的系统你来赔！)

东证把社长鹤岛琢夫祭了出去，出了问题就要谢罪下台表态度，日本流行这个。但咱坚决不背这笔债，明明是系统承包商富士通的责任嘛。我的需求里写了要能撤单，你连拒人家4次明显没达到要求。

富士通更绝：自己脑残手贱怪我咯？

 

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

至于什么样的bug算“重大过失”，法院给出了判断的标准：bug是不是很容易被检测出。

于是，控辩双方当庭撕代码。两边请来的资深程序猿专家吵成一团。你说“这么简单的bug，肉眼看都能看出来，测这么多遍还没测出，脑子秀逗了？”他说：“你觉得简单，那你现场重现给我看看？”

　　互撕结果：

东京地方法院判定：

程序bug不能算是重大过失，由这部分导致的损失无需赔偿。瑞穗电话联络东证后，东证未能履行中止异常交易的职责，属于重大过错方。但事件起因是由于瑞穗交易员的乌龙指，所以瑞穗也不能完全免责。电话联络时间点以后产生的损失，由东证承担70%，107亿日元。

没富士通啥事儿，更不关程序猿的事儿。程序猿小哥捧传票的手不抖了？小心肝儿落肚了？

先别急着安心。有了判例，“bug是不是很容易被检测出”这一标准便会被延续下去，成为此类诉讼的参照标杆。这次判决是bug非重大过失，那下次呢？

哪里有代码，哪里就有bug。苦逼程序猿小哥(或者程序媛小妹^_^)能保证自己的代码就不会遇上这种极品事件？

 

那么，在bug难免的情况下，要怎样规避程序猿、系统开发商、系统运营商、用户的风险呢？

首先，责权明晰。围绕系统开发、使用、维护过程中各个角色的责任与权力进行清晰的界定与描述，避免后续发生推诿现象。

其次，合规。系统开发商拿到客户的需求先别忙着成立项目组，划分任务模块，先到客户环境中尽职调研一番，把客户的业务逻辑搞清，编制出清晰明确的项目任务书。

程序猿应严格按照任务书给出的业务逻辑编写安全的代码，项目组遵从软件安全开发生命周期，反复测试、迭代，尽量掐灭bug出现的苗头。敏感事务、非常态事务请求提交前应进行有效的前端检查。系统运营商应尽职审查与合理部署，避免人为引入触发bug的特殊情况。

最后，完善事件响应和危机处理。防备掉电、断网、黑客攻击、敏感数据泄露、数据迁移失误、热备失效、数据库崩溃、激增交易量导致系统延迟等等突发状况。

程序猿虽然自称为‘猿’，本质上还是肉体凡胎，虽然在debug的路上披荆斩棘，身后留下的bug依然不计其数(参见微软大侠，每月打啊打啊打补丁，还是补不完^_^)。但是，虽然“bug恒久远，一颗永流传”，程序猿小哥小妹们也不必太过惊慌。一套系统的诞生、成长、运行、维护、使用，是很多人共同运作的结果，在系统研发运维的道路上你不是一个人，在立功受奖或者追责赔偿上当然也不会只揪着你一个小小的程序猿不放。bug难免，但可以尽力免，努力修，做到能做到的，一切水到渠成。

(责任编辑：安博涛)