那天系統掛點，產線停了，經理臉都綠了
那天真是嚇死人。我們產線的自動化系統，在出貨前最後一個站點，突然就卡住了，畫面一片空白，動彈不得。整條線上的機台瞬間停擺，你知道那是什麼場面嗎？幾百萬的貨就晾在那邊，經理衝進來，臉色比發爐的機台還難看。IT 部門的人衝過來，搞了半天，才發現是軟體一個從來沒看過的 bug，導致系統死鎖。這種鳥事，一年少說也要來個一兩次，每次都搞得人仰馬翻。我們老是在講硬體可靠度，MTBF、FIT rate 這些，但軟體可靠度，說實話，大家好像都當成「天塌下來再說」的問題。
問題到底出在哪？
說穿了，你以為軟體就沒有可靠度的問題嗎？當然有！只是我們量測的方法跟硬體不太一樣。硬體我們看的是平均無故障時間（MTTF，Mean Time To Failure），軟體其實也有類似的概念。但軟體不會「磨損」，它只會「出包」。所以我們看的是它「多久會出包一次」，以及「出包的頻率」。
- MTTF (Mean Time To Failure)： 很多人以為 MTTF 只有硬體才適用，其實軟體也有類似的。它指的是軟體在正常運作情況下，平均能撐多久才出現第一次「無法復原」的故障。跟硬體不同的是，軟體出包可能是因為輸入資料的組合沒見過，或是記憶體洩漏，而不是零件老化。
- 缺陷密度 (Defect Density)： 這個就直觀了。它量的是每千行程式碼（KLOC，Kilo Line Of Code）裡面有多少個 bug。舉個例子，如果你的程式寫了 50KLOC，結果測出 30 個 bug，那你的缺陷密度就是 30 / 50 = 0.6 defects/KLOC。這個數字越低越好，代表你的程式碼品質越高。
- 測試覆蓋率 (Test Coverage)： 這個也很重要。你想想看，你寫了一堆測試案例，但這些測試案例到底涵蓋了你多少程式碼的功能？如果你的測試只跑了 30% 的程式碼路徑，那剩下的 70% 不就等於裸奔嗎？常見的像是語句覆蓋率 (Statement Coverage)、分支覆蓋率 (Branch Coverage) 等等，至少要做到 80% 以上，才比較安心。
實際上怎麼做？
要提升軟體可靠度，實際做法就是從這幾個面向下手：
- 追蹤缺陷密度： 每次軟體發版前，一定要要求開發團隊提供缺陷密度數據。我們公司內部規定，新版軟體發行，缺陷密度要控制在 0.5 defects/KLOC 以下，否則就打回票。舊的穩定版本則要求在 0.1 defects/KLOC 以下。
- 拉高測試覆蓋率： 在規劃測試案例時，要確保測試覆蓋率。我們現在導入了自動化測試工具，每次 CI/CD 流程跑完，都會自動產生覆蓋率報告。如果分支覆蓋率低於 90%，就會亮紅燈，不准上線。坦白講，以前人工測試根本測不完，現在有了自動化，真的省事很多。
- 監控 MTTF： 雖然軟體不會「壞」，但它會「掛」。所以我們要監控系統平均多久會因為軟體 bug 導致停機。如果一個月內系統掛了兩次，MTTF 就只剩 15 天，這絕對是警訊。我們的目標是希望 MTTF 能拉到 90 天以上，也就是一個季度才掛一次。
最常見的坑
我跟你說，最常見的坑就是「頭痛醫頭，腳痛醫腳」。以前我們每次系統掛了，IT 就只針對那個 bug 打補丁，然後就沒下文了。結果呢？下次又換一個地方掛。說實話，這就跟硬體一樣，如果你只換掉一個壞掉的電阻，卻不分析它為什麼會燒掉，那肯定會重蹈覆轍。
另一個坑是「過度自信」。有些工程師覺得自己寫的程式碼很完美，根本不用測。結果一上線，各種邊角案例就跑出來，搞得大家雞飛狗跳。還有那種，為了趕時程，硬是把測試覆蓋率壓低，甚至直接跳過某些測試環節。這種短視近利，最後一定會付出慘痛代價，而且通常都是半夜被叫起來處理。
今天能做的一件事
請你的 IT 或開發團隊提供最新的缺陷密度與測試覆蓋率報告。