程式Bug導致了天大的損失，要槍斃程式設計師嗎？

文/雷子；來源/公眾號：東京 IT 人

號外！號外！走過，路過，不要錯過！日本 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），回過頭來該幹啥幹啥——東證和富士通，還真是一對好基友啊！

本文一部分圖片來自網路