概念地圖・共模失效
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：系統
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
共模失效：三條備援，共用一個節點
那天早上停電，三台不斷電系統全部亮綠燈，帳也對得上。可是控制室的溫度一路往上爬——因為冷氣不在備援清單裡，而機器撐不過四十分鐘。備援樹本來是一張讓人安心的圖：三條路徑並排，每一條自己壞掉的機率一成，三條同時壞就是千分之一，漂亮。共模失效問的是另一件事——這三條往下追，會不會在某一層碰頭。碰頭的那個點叫共用節點，它一倒，三條一起倒，千分之一當場退回一成。
三條路徑，共用一個節點
同一份備援清單，攤開來看跟往下追一層看，會是兩張完全不同的臉。
| 追哪一層 | 表面上：三條各自獨立 | 往下追：共用了什麼 |
|---|---|---|
| 電源 | 三組不斷電系統，季度試機都過 | 最後都插在同一面配電盤 |
| 網路 | 兩家電信、三條線路，合約分開簽 | 共用同一段最後一哩的管道 |
| 供應商 | 三家報價、三份合約、三個窗口 | 其中兩家向同一家上游調貨 |
| 人與流程 | 三班人馬輪值，職務代理寫得清楚 | 同一份手冊、同一個懂設定的人 |
| 環境 | 冷氣、水泵、排風，沒進備援清單 | 它們停了，三條路徑一起不敢動 |
右邊那一欄，才是可靠度的真正上限。三條路徑各自失效機率一成，真獨立的話同時掛掉是 0.001，可用度 99.9%；一旦共用一個同樣一成失效機率的節點，系統失效機率變成 0.1＋0.9×0.001＝0.1009，可用度掉到 89.9%。失效機率放大約一百倍，而其中九成九來自那一個節點——三條備援加起來的貢獻，還不到總失效機率的百分之一。
備援備到哪一層，四個問題追下去
一、電源：追到最後一顆插座。備援設備的規格書寫的是「獨立供電」，但那句話通常只保證到設備端子。往下追：獨立的電源模組，接進哪一個迴路？迴路上游是哪一面配電盤？配電盤又吃哪一路市電？追到某一格開始重複出現同一個名字，你就找到共用節點了。自問：三條路徑的電，最後是不是同一個師傅在同一面盤上拉的？
二、網路：追到最後一哩。兩家電信不等於兩條路。都市裡的管道資源有限，不同業者的線常常共管、共井、共同一段馬路。標案文件上是兩份合約，地底下是同一支怪手就能挖斷的東西。雲端也一樣——兩個帳號、兩個區域，可能還是同一朵雲的同一套控制平面。自問：這兩條線，我看過它們實際走的路徑圖嗎，還是只看過合約？
三、供應商：追到上游的上游。三家報價不代表三個來源。中間商往上追一到兩層，常常會收斂到同一座轉運倉、同一條產線、同一個原料產地。追法很土：直接問「你這批貨從哪裡出？」問不到答案本身就是一種答案。自問：我認識的是三個業務窗口，還是三條真的分開的供應鏈？
四、人與流程：追到同一個腦袋。這一層最常漏。三條路徑的切換動作，寫在同一份手冊裡，靠同一次教育訓練，而真的敢按下去的可能只有一個人。手冊本身也是共用節點——如果它有一句寫錯，三條路徑會用同一種方式錯下去。自問：這三條備援真的要切換時，是不是都得等同一個人接電話？
一家預拌混凝土廠停工那天，往下追三層
- 第一層：把三條路徑攤開：三台拌合機、三組出車班表、三家水泥供應商。任何一條停掉，另外兩條都吃得下當天的澆置量。紙上看，這是三條真備援
- 第二層：往上游追一格：三家供應商裡有兩家，貨其實都從同一座轉運倉出。那座倉一封，三家變一家。機率算式的分母先掉一截
- 第三層：追到配比與過磅：三台拌合機硬體各自獨立，但配比參數、過磅、出貨單全走同一套控制主機，主機插在辦公區那面配電盤上。三條在這一層合成一條
- 沒被寫進清單的那一格：洗車與回收水靠同一台泵。泵停了，車回不了廠，三台拌合機都不敢再下一車。它從來不在備援清單上
這家廠的備援清單上寫著三條，可靠度報表也算得出三個九。真正停工的那天，市電沒斷、拌合機沒壞、三家供應商也都還在營業——倒的是辦公區那面配電盤。控制主機一停，過磅出不了單，出不了單就攔住出車，三條路徑同時卡在同一個狀態：料在、車在、單子跑不出來。事後追下來，該補的不是第四條路徑，而是把控制主機挪到另一面盤、把洗車泵寫進清單、把兩家供應商換成真的兩個來源。備援樹畫得再寬，寬度只決定分岔那一端；能撐多久，由重逢那一端決定。以上為說明結構用的示意情境，僅供理解框架之用。
這棵備援樹什麼時候會騙你
- 共用節點常常不是硬體。大家追共模失效，眼睛都盯著電源、機房、線路，但更常見的共用節點是一份設定檔、一次同時推送的韌體更新、一套所有人都照著做的判斷習慣。三台機器跑同一版有 bug 的軟體，硬體再獨立也沒用——它們會在同一秒、用同一種方式一起錯。這類共用節點沒有實體，你在機房裡走一圈是看不到的。
- p 的三次方那個數字，本身就已經假設了獨立。可靠度報表最漂亮的那一格，通常是最沒有證據的一格。乘法只有在事件互相獨立時才成立，而「獨立」這兩個字，通常是人直接填進模型裡的假設，沒有人真的量過。看到 99.9%，先去問這串乘法背後的獨立假設誰驗過、用什麼驗的。沒人驗過，那個小數點後三位就只是排版效果。
- 往下追會追進無窮遞迴，停在哪裡是商業判斷。電追到插座、插座追到變電所、變電所追到電網，理論上永遠追得下去。實務上要有一條停損線：追到「這一層倒了，我幾小時內會知道、幾小時內有得換」為止。追不完不是理由，但停在合約那一層一定太淺——合約分得開的東西，實體上常常還連在一起。
三個九掉回一個九之後
「我們有備援」這句話，聽起來像結論，其實是一個問題的開頭。
接下來那句該問的是：備到哪一層。備援樹畫得出三條路徑在哪裡分岔、在哪裡重逢，畫不出重逢的那一刻，客戶會在第幾分鐘改打給別人。這正是 P.A.I.N. 那把尺跟可靠度模型分家的地方——模型算的是系統幾點恢復，客戶記的是自己等了多久、有沒有人主動告訴他發生什麼事。同一場四十分鐘的停擺，對趕澆置進度的工地是災難，對明天才要收貨的客戶只是一則通知。共模失效真正的成本，寫在你的客戶名單上。所以追共用節點的時候，順序可以反過來排：先問哪一群客戶最痛不起，再從他們身上往回追，看那條服務鏈在哪一層跟別人擠在一起。今晚把備援清單打開，在每一條旁邊補兩個欄位——最後插在哪一顆插座、最後靠哪一家供應商。三行寫完擺在一起看，重複出現的那個名字，明天早上就去問它有沒有第二個。
關於共模失效，常見問題
共模失效和單點故障有什麼不一樣？
單點故障是「這裡只有一份，壞了就沒了」，通常一眼看得出來，因為架構圖上它就是孤零零一個框。共模失效更難抓：架構圖上明明畫了三份，看起來完全冗餘，但三份共用了同一個下層元件，所以它們會一起倒。差別在偽裝——單點故障誠實地承認自己脆弱，共模失效則躲在一張很漂亮的備援圖背後。可以這樣記：共模失效是化了妝的單點故障，而妝就是那張備援樹。
怎麼知道我的備援有沒有共模？
最有效的方法是真的拔一次。挑離峰時段，把其中一條路徑實際切斷，看剩下兩條是不是真的自己跑起來、跑多久、需要誰按什麼。紙上推演會漏掉一堆隱性依賴，因為寫文件的人不知道自己不知道什麼。做不到實拔，退而求其次是畫依賴圖：把三條路徑各自往下拆到元件層，看有沒有同一個名字出現兩次以上。出現兩次，那就是要重點盯的地方。
備援做到幾條才夠？
條數幾乎不是重點。從兩條加到三條，只有在三條真的獨立時才有意義；共用一個節點的話，加到十條，系統失效機率還是卡在那個節點的失效機率上，多花的錢買到的只是心安。實務上的順序應該倒過來：先把現有兩條之間的共用節點拆掉，再考慮要不要加第三條。拆共用節點通常比加一條路徑便宜，效果也大得多——把控制主機挪到另一面配電盤，成本是一個下午。
多雲、多供應商就能避開共模失效嗎？
會減少，但不會歸零，而且成本經常被低估。多供應商解掉的是「這一家倒了怎麼辦」，解不掉的是大家共用的更上層：同一套網路骨幹、同一批相同型號的硬體、同一個資安漏洞、同一份被大家一起抄的設定範本。更麻煩的是，多一家供應商就多一套流程、多一組要維護的設定，而人與流程那一層的共用節點反而變厚了。決定之前先算清楚：你想擋掉的是哪一種同時失效，這一步真的把它拆開了嗎。
想把這張圖接著往兩個方向讀：層層防護為什麼會在同一天對齊，可以看瑞士起司模型；系統緊耦合到什麼程度會讓意外變成日常，可以看正常意外理論。這張備援樹只處理其中一件事——看起來各自獨立的三條路徑，在哪一層變回一條。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。