程序bug導致了天大的損失，要槍斃程序猿嗎？
當前位置：點晴教程→知識管理交流
→『 技術文檔交流 』
號外！號外！走過，路過，不要錯過！日本IT業的狗血八卦繼續獨家放送啦?。?/p> 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萬股”。 指令發出后，瑞穗證券的交易軟件檢查到這是一個異常的交易訂單，給出了一個警告的對話框?？墒牵袢鹚胱C券交易員這種級別的操盤手，玩的就是不按套路出牌，每天這種警告對話框見得太多了好么。田中君甚至都沒有好好讀一下對話框里的內容，就按下了確定按鈕。于是，這個巨大的賣單就掛在了東證的交易盤口上。
2分鐘后，田中君發現了這個錯誤，趕緊試圖通過交易軟件撤銷這筆賣單?？墒沁B續輸入3次撤單指令，都被東證的交易系統拒絕了(后來查明是由于交易系統的bug所致)。 田中君又迅速給交易所的負責人打電話，要求將這個賣單撤下。交易所的人表示：“我們無權操作，這個問題只能你們自己想辦法”。 這時盤口交易已經開始。這個巨大的賣單首先將開盤價定在了67.2萬日元，然后又依次將所有買單成交，最終將J-Com的股價釘死在跌停價57.2萬日元上。（與天朝不同，日本的漲跌停價并不是嚴格的按照10%來計算，而是根據開盤價確定出一個整數的價格范圍） 此刻市場內一片大亂。散戶們被這個巨大空單嚇得驚慌失措，以為J-Com公司出了什么問題，紛紛跟風拋售。而一些機構和大戶已經猜到是出了烏龍指，迅速在跌停價買進。一些有節操的機構，例如德意志證券，買了幾手后覺得實在是太不厚道，自覺停止了搶購。而大部分機構紛紛表示：節操才多少錢一斤，有便宜不占王八蛋?。尩貌灰鄻泛酢?/p> 可能有同學不太懂股票交易，大概就是下面這種趕腳。 本來，客戶的委托是下面這樣的......
然而，手殘的田中君把數字輸入錯了……
但是，股票價格有漲跌幅限制。所以頁面發布以后，系統又自動把價格改成了下面這樣......
就算是57萬，也是非常便宜了好么！大媽，不，大戶們迅速圍觀，爭相爆買......
在股市這個游戲規則里，只要你賣出的股票有人接了，那成交后就必須把貨交給買家才行。可是，J-Com的股票一共才發行了14000多股，大部分還由公司高管持有，真正在市場上流通的也就3000多股。61萬股，讓瑞穗上哪里去弄？總不能自己在家里畫?。?/p> 沒有辦法，瑞穗證券只好發出了反向買入的決定，開始和其他人一起搶購籌碼。這樣一來，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年某次程序修改時，不小心埋進去的。 本來，程序修改后必須經過嚴格的回歸測試，來驗證對其他業務流程有沒有影響?？墒遣粌H富士通忽略了這個測試，東京證券交易所在系統驗收測試(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），回過頭來該干啥干啥——東證和富士通，還真是一對好基友??！
本文一部分圖片來自網絡 聲明：本文為本站編輯轉載，文章版權歸原作者所有。文章內容為作者個人觀點，本站只提供轉載參考（依行業慣例嚴格標明出處和作譯者），目的在于傳遞更多專業信息，普惠測試相關從業者，開源分享，推動行業交流和進步。 如涉及作品內容、版權和其它問題，請原作者及時與本站聯系（QQ：1017718740），我們將第一時間進行處理。本站擁有對此聲明的最終解釋權！歡迎大家通過新浪微博（@測試窩）或微信公眾號（測試窩）關注我們，與我們的編輯和其他窩友交流。
該文章在 2024/1/13 17:56:59 編輯過 |
關鍵字查詢
相關文章
正在查詢... 
|
400 186 1886
