程序bug導致了天大的損失，要槍斃程序猿嗎？
當前位置：點晴教程→知識管理交流
→『 技術(shù)文檔交流 』
號外！號外！走過，路過，不要錯過！日本IT業(yè)的狗血八卦繼續(xù)獨家放送啦??！ 2015年9月3日，隨著東京最高法院駁回瑞穗證券的上訴，維持二審的原判結(jié)果，一個長達10年的訴訟終于畫下了句號。這個判例將對IT行業(yè)產(chǎn)生深遠的影響：如果程序的bug導致了巨大的經(jīng)濟損失，應該由誰來承擔？用戶？運營商？還是系統(tǒng)開發(fā)商？ bug：計算機程序里的錯誤 今天故事的主角是，瑞穗(みずほ)證券，東京證券交易所(下文簡稱東證)，和富士通。 各位富士通的同學，雷子真的不是富士通黑啊。你們公司行業(yè)內(nèi)第一，項目多，所以卦點就多??！要是又一次傷害了你們的感情，看下圖能原諒我不……
嗯，該說的也都說過了，下面正式開始。 （一）瑞穗證券的烏龍指事件 如果時光能夠倒流，讓瑞穗證券的交易員田中君(化名)穿越回2005年12月8日東證開盤前的那幾分鐘，田中君會不會選擇把自己那根烏龍指給掰斷呢？ 烏龍指(fat finger)：是指股票交易員、操盤手、股民在交易的時候，不小心敲錯了價格、數(shù)量、買賣方向等。 正是由于田中君的一次錯誤輸入，讓他所在的瑞穗證券遭受了超過400億日元的天價損失。雖然日元那面額畫得跟冥幣似的，400億日元也還是相當值些銀子滴(按照當時的匯率，約為人民幣27億元)。 這天，是日本公司J-Com首次公開上市(IPO)的日子。上午9:27，距離開盤還有幾分鐘。田中君接到一位客戶的委托：“以61萬日元的價格，賣出1股J-Com的股票”。田中君接到委托后，在瑞穗證券的交易終端上，錯誤地輸入了“以每股1日元的價格，賣出61萬股”。 指令發(fā)出后，瑞穗證券的交易軟件檢查到這是一個異常的交易訂單，給出了一個警告的對話框?？墒?，像瑞穗證券交易員這種級別的操盤手，玩的就是不按套路出牌，每天這種警告對話框見得太多了好么。田中君甚至都沒有好好讀一下對話框里的內(nèi)容，就按下了確定按鈕。于是，這個巨大的賣單就掛在了東證的交易盤口上。
2分鐘后，田中君發(fā)現(xiàn)了這個錯誤，趕緊試圖通過交易軟件撤銷這筆賣單?？墒沁B續(xù)輸入3次撤單指令，都被東證的交易系統(tǒng)拒絕了(后來查明是由于交易系統(tǒng)的bug所致)。 田中君又迅速給交易所的負責人打電話，要求將這個賣單撤下。交易所的人表示：“我們無權(quán)操作，這個問題只能你們自己想辦法”。 這時盤口交易已經(jīng)開始。這個巨大的賣單首先將開盤價定在了67.2萬日元，然后又依次將所有買單成交，最終將J-Com的股價釘死在跌停價57.2萬日元上。（與天朝不同，日本的漲跌停價并不是嚴格的按照10%來計算，而是根據(jù)開盤價確定出一個整數(shù)的價格范圍） 此刻市場內(nèi)一片大亂。散戶們被這個巨大空單嚇得驚慌失措，以為J-Com公司出了什么問題，紛紛跟風拋售。而一些機構(gòu)和大戶已經(jīng)猜到是出了烏龍指，迅速在跌停價買進。一些有節(jié)操的機構(gòu)，例如德意志證券，買了幾手后覺得實在是太不厚道，自覺停止了搶購。而大部分機構(gòu)紛紛表示：節(jié)操才多少錢一斤，有便宜不占王八蛋??！搶得不亦樂乎。 可能有同學不太懂股票交易，大概就是下面這種趕腳。 本來，客戶的委托是下面這樣的......
然而，手殘的田中君把數(shù)字輸入錯了……
但是，股票價格有漲跌幅限制。所以頁面發(fā)布以后，系統(tǒng)又自動把價格改成了下面這樣......
就算是57萬，也是非常便宜了好么！大媽，不，大戶們迅速圍觀，爭相爆買......
在股市這個游戲規(guī)則里，只要你賣出的股票有人接了，那成交后就必須把貨交給買家才行?？墒牵琂-Com的股票一共才發(fā)行了14000多股，大部分還由公司高管持有，真正在市場上流通的也就3000多股。61萬股，讓瑞穗上哪里去弄？總不能自己在家里畫??！ 沒有辦法，瑞穗證券只好發(fā)出了反向買入的決定，開始和其他人一起搶購籌碼。這樣一來，J-Com的股價又被拉高到漲停價77.2萬日元，一直持續(xù)到當天的交易結(jié)束。在當天的交易中，瑞穗證券一共損失了約270億日元。
受到影響的不僅僅是J-Com的股價。瑞穗證券直到當天收盤后，才向外界披露了這一烏龍指事件。而在當天的交易過程中，市場上已經(jīng)有傳聞，一家證券公司搞出了烏龍指，將有重大虧損。由于不知道是哪家券商出了問題，所有券商股票都慘遭拋售。 這下證券公司都哭了，紛紛發(fā)表聲明：股東老爺們，真的和我沒關(guān)系啊......然并卵。其中最慘的是J-Com上市的主要發(fā)行商——日興證券，股價一度狂跌了8%。而這股不安情緒也影響了所有投資者。當天收盤時，日經(jīng)指數(shù)大跌了301點。 （二）事后收場 首先是成交單的交割問題。不存在的股票怎么交割?。侩m然瑞穗證券通過回購，搶回了大部分的賣單，但還是有9萬多股被其他機構(gòu)和散戶買走了。根據(jù)規(guī)則，瑞穗必須在3天之內(nèi)交貨(日本的交割日是T+3)。前面說過，市場上一共才流通了3000多股J-Com的股票，這9萬多股真是逼死瑞穗證券也拿不出來啊。
最后經(jīng)過協(xié)商，買賣雙方同意用現(xiàn)金來結(jié)算。清算的價格定在了每股91萬日元——這是瑞穗證券敲下烏龍指前一刻的股票價格。這次現(xiàn)金交割又讓瑞穗證券雪上加霜，損失擴大到400多億。 至于當事人田中君，似乎并沒有受到太嚴厲的懲罰。瑞穗證券至今也沒有公布當事人的真實姓名，只知道是一名男性證券經(jīng)紀人。事件發(fā)生時，正趕上日本公司要發(fā)年終獎。就因為田中君的一個錯誤操作，一下子把公司一整年的利潤都給干掉了，讓瑞穗證券所有員工的年終獎都泡了湯。有傳聞，田中君成了瑞穗證券里“最討厭的人排行榜”的No.1。 那些趁火打劫的機構(gòu)大戶也受到了指責。事后查明，共有22家機構(gòu)在此次烏龍指事件中獲利。其中瑞士銀行，摩根斯坦利，日興證券，雷曼兄弟，瑞士信貸，野村證券這六家機構(gòu)，從這次事件中一共瓜分了168億，占瑞穗證券損失的40%還多。 盡管這錢來的不太光彩，可畢竟是按照市場規(guī)則賺來的，所以金融監(jiān)管部門只能從道德層面對這些公司進行譴責而已。有人提議，讓這些公司把賺到的錢吐出來。這些公司表示：這樣做，等于把公司的利潤白白送給別人，沒法向自己的股東交代啊。 后來在各方的調(diào)節(jié)下，一部分獲利的證券公司同意把錢拿出來，成立一個保護投資者利益的基金，這是后話了。 在這次事件中，東證交易所受到了最多的質(zhì)疑。首先瑞穗證券在意識到錯誤掛單后，曾經(jīng)多次發(fā)出取消的指令，但都被交易所的系統(tǒng)所拒絕，這顯然不符合系統(tǒng)的交易規(guī)則。其次，在瑞穗證券與東證負責人取得了聯(lián)系的情況下，東證方面仍然放任這筆賣單繼續(xù)執(zhí)行，有監(jiān)管不力之嫌。事后，東證社長鶴島琢夫引咎辭職。 瑞穗證券方面認為，正是由于東證的過錯，才讓自己蒙受了400億日元的損失。這個錯誤理應由東證來買單。東證的觀點是：你自己烏龍指敲錯了指令，憑啥賴在我身上？對此，瑞穗證券回擊：取消交易指令發(fā)出之前的那段時間，產(chǎn)生的損失自己認了。但是還沒成交的賣單為啥不讓人家撤銷？ 兩個公司之間扯來扯去，也沒把這個問題談攏。于是，2006年9月，瑞穗一紙訴狀，把東證以及交易系統(tǒng)的開發(fā)商——富士通告上法庭。就這樣，漫長的訴訟開始了。 （三）法庭訴訟 對于這個案件，事實已經(jīng)很清楚了：由于交易所的系統(tǒng)bug，在特定的條件下，會發(fā)生不能撤單的現(xiàn)象。經(jīng)過詳查得知，這個bug是富士通的技術(shù)人員在2000年某次程序修改時，不小心埋進去的。 本來，程序修改后必須經(jīng)過嚴格的回歸測試，來驗證對其他業(yè)務流程有沒有影響?？墒遣粌H富士通忽略了這個測試，東京證券交易所在系統(tǒng)驗收測試(UAT)的時候，也疏忽了這方面的內(nèi)容。結(jié)果，炸彈在這個時間點被引爆了。（下圖是包含了bug的cobol代碼）
圍繞著這個事實，第一個爭論點是：東證和富士通，應該為瑞穗證券的損失負責嗎？ 起初，東證還想耍賴，把錯誤全部推在富士通身上。東證主張：就算是交易系統(tǒng)的bug導致了瑞穗證券的損失，那也是富士通的錯。因為我的系統(tǒng)需求里面，是明確規(guī)定了可以撤單的。富士通開發(fā)的程序沒有符合我的需求，才導致了這樣的結(jié)果。 對于東證的這個主張，東京地方法院判定：這個系統(tǒng)的主要責任人是東證。富士通只是東證的系統(tǒng)供應商，屬于連帶責任人。無論是主要責任人還是連帶責任人，如果被證明犯有重大過失，都應該做出賠償。 那么，程序的bug算是“重大過失”嗎？這很難說。一個系統(tǒng)里有沒有隱藏的bug，是沒法從理論上證明的。就算是測試再徹底，也會有測不到的bug流出來。所以在法律上，通常不會把所有因為bug導致的損失都歸罪給程序開發(fā)商。否則的話，世界上最大的bug生產(chǎn)商——微軟，早就賠得連內(nèi)褲都不剩了。
這就帶出了本案第二個爭論焦點：什么樣的bug才算是“重大過失”？法院給出了判斷的標準——這個bug是不是很容易被發(fā)現(xiàn)。 于是，控辯雙方都找來了由資深程序猿和攻城獅組成的磚家組，在法庭上撕成一團。 穗瑞磚家組：臥槽，這個bug簡直太明顯了好么？連這個都測不粗來，請問貴司人員的編程，都是音樂老師教的嗎？
富士通磚家組：異議あり！這么復雜的條件組合，你特么能一下子就找出bug來??！你們敗吹牛逼了行不行！
雙方的磚家團吵來吵去，誰也說服不了誰，干脆，在法官面前開始review起程序代碼來了。 而此刻的法官，表情是很鎮(zhèn)靜的......
但是在法官的心里，簡直有一萬匹草泥馬奔騰而過啊！
爭辯到最后，一臉懵逼的法官表示：你們說得好像都挺有道理的......但是意見相反，所以也不能判定成容易發(fā)現(xiàn).......富士通就不用賠了！
最終，東京地方法院判定：程序bug并不能算是重大過失，由這部分導致的損失無需賠償。但是，在瑞穗證券電話聯(lián)絡東證交易所后，東證未能履行中止異常交易的職責，屬于重大過錯方。另一方面，事情的起因是由于瑞穗證券的烏龍指，所以瑞穗證券也不能完全免責。從電話聯(lián)絡那個時間點以后產(chǎn)生的損失，由東證承擔70%，107億日元。 瑞穗證券和東證都對這個審判結(jié)果表示不滿，上訴到東京最高法院。2015年9月3日，東京最高法院駁回上訴，維持原判結(jié)果。長達10年的訴訟終于塵埃落定。 （四）深遠影響 看到這里，程序猿和攻城獅應該是松了一口氣吧，終于不用為自己寫的bug而買單了。 但是且慢！根據(jù)這個判例，“bug是否很容易被檢測出來”這一點，將會成為今后類似訴訟的判斷基準。一旦被判定成重大過失，程序猿們可真是欲哭無淚了。 現(xiàn)在問題來了：身為程序猿，誰也不能保證自己的代碼里沒有bug。該如何做，才能避免陷入到這種境地中呢？ 雷子覺得，既然無法從理論上證明程序里所有的bug都被檢測出來，那么，一些行業(yè)內(nèi)公認的指標，例如測試時的case密度，bug密度等，很可能會成為測試是否充分的判斷依據(jù)。（對，就算沒有bug我們也要制造出來?。?/p> 此外，bug對應得是否充分，也會成為判斷的重要基準。一個bug被發(fā)現(xiàn)后，有沒有進行深刻的挖掘也是很重要的，即所謂的“橫展開”。看到這個詞，估計很多同行會做噩夢吧！這個話題很大，雷子今后另起文章和各位同行探討。 還有一點不要忘記，無論是測試結(jié)果也好，還是bug的對應結(jié)果也好， 要留證據(jù)！ 要留證據(jù)！ 要留證據(jù)！ 重要的事情說三遍。 本案也讓東證認識到，舊交易系統(tǒng)的老朽化以及bug過多等缺陷。隨著近年來程序化交易的盛行，舊系統(tǒng)已經(jīng)越來越無法滿足現(xiàn)代證券交易的需要。比起倫敦和紐約等地的證券交易所來，當時東證系統(tǒng)的響應時間要慢100倍啊。 以瑞穗證券烏龍指事件為契機，導出了2010年金融行業(yè)的重大項目——東證次世代的交易系統(tǒng)“arrowhead”的構(gòu)建。這個新系統(tǒng)，依然由富士通負責開發(fā)。 法庭上撕得面（ji）紅（chi）耳（bai）赤（lian），回過頭來該干啥干啥——東證和富士通，還真是一對好基友??！
本文一部分圖片來自網(wǎng)絡 聲明：本文為本站編輯轉(zhuǎn)載，文章版權(quán)歸原作者所有。文章內(nèi)容為作者個人觀點，本站只提供轉(zhuǎn)載參考（依行業(yè)慣例嚴格標明出處和作譯者），目的在于傳遞更多專業(yè)信息，普惠測試相關(guān)從業(yè)者，開源分享，推動行業(yè)交流和進步。 如涉及作品內(nèi)容、版權(quán)和其它問題，請原作者及時與本站聯(lián)系（QQ：1017718740），我們將第一時間進行處理。本站擁有對此聲明的最終解釋權(quán)！歡迎大家通過新浪微博（@測試窩）或微信公眾號（測試窩）關(guān)注我們，與我們的編輯和其他窩友交流。
該文章在 2024/1/13 17:56:59 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... 
|
400 186 1886
