致命Bug:軟體缺陷的災難與啟示
這是一本在講軟體 bug 小故事的書, 和我平常在讀的電腦技術書籍比起來, 非常容易讀, 也很有趣, 讓我知道了不少事情, 有些事應該是需要被報匯出來的, 可是我完全沒印象有聽過這些報導, 我對自己的孤陋寡聞感到哀傷。可惜這本書沒有電子版, 這是本很適合用電子閱讀器讀的書。
本書寫的淺顯、易懂、好讀, 就算不是相關的軟體專業人員, 也可以當作是一篇篇的故事來讀, 精彩度絲毫不遜於小說。
本書的原文是韓文, 這是翻譯重要的一種表現, 我相信有人英文一定很好, 看原文書沒問題, 但在這些人當中韓文也好的那可能就很少了。在我購買的書籍中, 有日文、韓文、英文這些翻譯本, 但事實上還會有德文、法文、俄文等的翻譯本, 不太可能把這些語言都學過一遍的。
翻譯工業應該要由政府來當領頭羊, 將整個人民的眼界帶到全世界才是, 人們眼界開了, 國家就會更進步才是, 因為語言隔閡而不能大開眼界, 真是太冤枉了, 要求每個人外文學的好的難度大於將翻譯工業好好的建構起來。
軟體在一般人的印象是不是網頁, 手機上的 app, 還有 windows 上的那些軟體、遊戲呢? 這本書提到的都是讓人很難想到的領域軟體, 書上有幾個很深刻的軟體 bug 想和大家聊聊。
chapter 4 在講停電的故事, 因為軟體的原因, 導致電力負荷不過來時, 接應的系統沒來幫忙, 就這樣, 像水管承受不了水壓而爆開, 電力系統最終癱瘓。
chapter 5 的約克城號是艘戰艦, 使用的是 ms windows 4.0, 它有一天突然不動了, 就這樣靜靜地停在海上, 任由海洋帶領, 漂浮了 2 小時 45 分鐘, 軟體的錯誤是 divided by zero。
chapter 9 的美國的文森號戰艦, 它擊落了伊朗航空 655 民航機, 因為文森號戰艦把他當成了伊朗的 F-14 戰鬥機, 至於為什麼伊朗會有美國的 F-14 那是另外一個值得探究的問題。
美軍當然不是傻蛋, 怎麼會搞不清楚是戰鬥機還是民航機呢? 但是可遇而不可求的巧合還是讓這場悲劇發生了, 總共要符合以下條件: 文森號戰艦使用軍用無線電頻率警告對方, 對方是民航機, 收不到的。 文森號戰艦後在使用國際救援無線電頻率警告對方, 但對方可能沒收到, 因為沒找到黑盒子, 無法確認。 文森號戰艦查詢了民用客機的起飛時間, 可惜 655 民航機延遲 27 分鐘才起飛, 所以美軍不認為那個時間點有民航機。而文森號戰艦使用了 GMT+4 的時間, 但航班時間是 GMT+3.5, 更讓事情變得棘手。 再來是雷達掃描系統, 655 民航機的識別程式碼是 3, 但是掃到的程式碼是 2 (軍用機), 不是軟體出問題, 而是掃錯區域, 本來應該掃民用機場的方向結果掃到軍用機場。 最後, 終於來到最後, 研判系統出錯, 655 民航機在明明是在升高, 但文森號戰艦的軟體系統使得軍方人員研判 655 民航機在下降。 就是這以上幾點造成了這個悲劇, 但美國死不認錯也令人不齒, 不過有賠錢, 但強國就可以這樣鴨霸嗎?
但我覺得作者把這件事情也規到軟體 bug 倒是有點牽強了, UI 的結果不好研判或是警示系統不周全說是 bug 我實在不能接受。
chapter 12 的核子武器系統 bug, 知道的人應該都會覺得現在還有個好的地球可生存, 都會為此心存感謝。
美國/蘇聯的偵測系統會互相偵測核彈, 當對方發射過來時, 我方就反擊, 但如果誤判了呢? 對方明明沒有發射核彈, 但警示系統確認為有呢? 你會怎麼辦呢?
這樣的 bug 還一邊發生一次, 有夠公平。還好這些人果真都是菁英份子, 最後什麼都沒發生, 感謝這些研判正確的軍方人員。
chapter 13 的癌症治療系統, 這個很嚴重, 讓治療的病人接受了高於需要的放射線照射, 這是加拿大的 AECL Therac-25, 本來需要的能量是 200 rad, 但病人卻接收了 15000 ~ 20000 rad 的照射, 在怎麼沒概念的人也知道這差太多了, 造成許多人死亡。
這個軟體問題是算術溢位, 8 bit 整數, 只能存放 0 ~ 255, 超過就會繞回, 就是這問題倒置整個劑量數值出錯。
chapter 18 豐田暴衝, 原來日本人也是會騙人的, 和福斯的造假測試一樣, 令我驚訝, 原來德國人也是會騙人的, 他們把自己好不容易打造的形象搞砸了。
談軟體部份, 當機械結構改成電子加上軟體之後才發生這樣的事情, 有個 Barr Group 對豐田的軟體分析, 發現在某些情形下, 某些 reltime os tast 不會去執行該做的工作, 造成這樣的原因是, stack overflow, 而其程式有 11000 全域變數也令人驚訝, 日本人的軟體好像也不怎麼高竿是吧!
相關文章
- 《致命Bug:軟體缺陷的災難與啟示》讀後感受
- 關鍵基礎設施軟體的缺陷可能意味著災難
- 缺陷軟體:大資料驅動科學的致命傷?大資料
- 軟體缺陷的案例
- 【乾貨分享】軟體Bug和缺陷有什麼區別?
- 軟體用例寫作與缺陷管理
- [軟體測試理論基礎] 記錄第一個 Bug 的誕生,為什麼軟體缺陷叫 Bug/Defect?
- 研究顯示,用Python更易出現軟體缺陷!Python
- 軟體測試:軟體缺陷管理
- 軟體缺陷管理流程
- 【軟體測試】缺陷
- [個體軟體過程]之缺陷管理--缺陷預測 (轉)
- 排隊與掉線,線上遊戲的「人口災難」遊戲
- 無人車致命車禍視訊曝光:Uber技術失敗的實錘,一場本可避免的災難
- 軟體測試中容易忽略的缺陷
- 軟體測試--缺陷報告
- 軟體危機和軟體缺陷的特點和區別
- 案發現場:被注入的軟體及 ORA-600 16703 災難的恢復
- 機器學習中的維度災難機器學習
- 軟體開發的難
- SaaS軟體的技術缺陷以及解決方案
- 軟體工程的最大難題軟體工程
- SQL Server災難恢復SQLServer
- 1人作《致命公司》的成功,帶給遊戲開發者的三點啟示遊戲開發
- 從光大證券的軟體設計缺陷想到的。
- 和智慧手錶相比:智慧手環這個缺陷太致命
- Bug管理工具(TCE)之缺陷匯入與匯出
- 81%的開發人員表示知道軟體存在缺陷
- 一個專業的缺陷跟蹤管理軟體:JIRA
- 由SUN公司為太平洋災難中心提供災難預警系統的技術支援想到的
- 何為軟體開發的難?
- 巧破軟體測試缺陷管理之痛
- 突破還是災難? 淺談遊戲中的身份轉換與敘事遊戲
- 架構與思維:一次快取雪崩的災難覆盤架構快取
- PyroSim 2021,火災模擬軟體ROS
- 昨日Oracle災難現場的經歷薦Oracle
- Oralce 資料庫的災難恢復(轉)資料庫
- 當下SaaS軟體的技術缺陷以及解決方案