概念地圖・錯誤預算
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：管理
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
錯誤預算：把「不准出事」換成可以壞多少
演唱會開賣前十分鐘，售票平台的戰情室已經坐滿人。大螢幕上掛的不是「今天不准出事」這句話，是一個會往下跳的數字：這一季還剩 70 分鐘可以壞。那 70 分鐘叫錯誤預算——把服務等級目標裡「允許故障」的那一小塊先算成一筆總額，用掉一分就少一分，燒完就停止發新版本。工程師盯它，因為它把「穩定」從一句口號變成會見底的東西；老闆盯它，因為同一格數字也決定了這一季還能推幾次新功能。
SLO 每多一個 9，可以壞的時間就少一位數
錯誤預算是 SLO 的減法，一條乘法算式就跑得出來。以一季 90 天、也就是 129600 分鐘來算，四個常見等級長這樣：
| 這一季的 SLO | 可以壞掉的總時間 | 換算成感覺 |
|---|---|---|
| 99% | 約 21.6 小時 | 將近一整天，尖峰全掛都還有餘 |
| 99.9% | 約 129.6 分鐘 | 兩小時出頭，三次中型事故就見底 |
| 99.95% | 約 64.8 分鐘 | 一小時多一點，一次大當機幾乎吃光 |
| 99.99% | 約 13 分鐘 | 一次重開機的時間，形同不准壞 |
這張表最該記住的是它的間距：從 99% 走到 99.9%，可以壞的時間從 21.6 小時掉到 129.6 分鐘，一口氣少了九成。上面那張圖畫的就是 99.9% 那一列——季初入帳約 130 分鐘，三次事故分別燒掉 38、22、55 分鐘，加起來 115 分，季末剩下 15 分。多數團隊在會議上訂 SLO 時，訂的是一個聽起來體面的數字；很少人當場把它換算成「那我這一季可以壞幾分鐘」，於是承諾發了出去，額度躺在哪個抽屜裡沒人知道。
畫這條線之前，先講定五件事
一、這筆額度掛在誰身上。錯誤預算掛在產品負責人身上才有力氣；掛在維運團隊身上，它會退化成一份沒人看的月報。它真正的用途，是逼「今年要多推三個功能」和「今年要更穩」在同一張表上分帳。自問：額度燒到剩一半時，誰會收到通知？如果只有值班工程師看得到，那它管不到任何一個決定。
二、分母有沒有算到人。「壞掉」的定義決定一切。拿「伺服器有沒有回應」當分母，跟拿「使用者有沒有買成票」當分母，算出來的燒速差好幾倍：全站活著、結帳成功率卻掉到七成的那 20 分鐘，前者記 0、後者記滿。分母選錯，這條線會一路漂亮到季末，客訴卻堆到爆。自問：你量的是機器的存活，還是一筆交易的完成？
三、燒完之後真的停得下來嗎。政策線只有被執行過一次以後才有重量。多數公司的錯誤預算是軟的：燒完了照樣發版，理由永遠是這次很趕。線一旦軟過一次，往後每一次都會軟，而且大家會學得很快。自問：上一次額度見底，發版停了幾天？答案是「沒停過」的話，那條零線只是裝飾。
四、剩太多算不算問題。這是最少人問的一格。季末額度剩八成，通常會被寫進報告當好消息；它其實代表你買了一份用不到的保險，而為了那份保險少出的貨，帳上沒有任何一欄記得。標準訂得太保守，跟訂得太寬鬆一樣要付錢，只是帳單不會寄過來。自問：上一季沒用掉的額度，換算成幾次不敢上線的改動？
五、時間窗切齊還是滾動。每季一號歸零的額度，會長出一種季初特有的放縱：反正剛入帳。改成「永遠看回頭三十天」的滾動窗，燒得快的隊伍當週就感覺得到壓力，用不著等季末結算才發現額度早就見底。自問：你的額度是每季重來一次，還是每天都在重算？
一個台灣售票平台的一季，一百三十分鐘怎麼燒
- 季初入帳：SLO 訂在 99.9%，一季 90 天換算成 129.6 分鐘，取整成 130 分鐘，做成大螢幕上唯一的那個數字。爭吵少一半
- 第 24 天：金流供應商逾時，結帳頁轉了 38 分鐘的圈。站台活著，票卻買不成，照樣記進額度。三成沒了
- 第 51 天：資料庫改版之後，選位查詢慢了三倍，撐 22 分鐘才回復。沒有人喊當機，額度還是照扣。慢也算壞
- 第 74 天：某團體開賣，排隊機制被壓垮 55 分鐘。手上剩的 70 分鐘，一次燒掉 55。剩的燒掉八成
- 季末結算：剩 15 分鐘，零線沒被跌破，發版沒有被凍結。政策線守住了
這一季真正的產出，是第 74 天之後大家看那個數字的表情變了。前兩次事故發生時，會議上的問題是「修好了嗎」；第三次之後，問題變成「剩下的 15 分鐘，要留給下一次開賣，還是留給那個等了三個月的改版」。額度沒有替任何人做決定，它只是把一個一直被躲開的取捨擺到桌上：這一季，穩定跟速度誰先讓步，要在還有額度的時候講清楚，別等到零線被跌破的那個凌晨，由值班的人替全公司回答。以上為說明結構用的示意情境，僅供理解框架之用。
這張圖什麼時候會騙你
- 額度會被當成配額花掉。知道還有 90 分鐘可以壞，就有人把風險最大的那次改版排進來——反正還有額度。錯誤預算標的是上限，用途從來不在把它花完。把它當配額用的隊伍，季末永遠剛好見底，而且見底的位置總是落在最不該壞的那幾天：檔期、開賣、月底結帳。
- 總分鐘數蓋掉了誰在痛。129.6 分鐘是一個平均概念，它分不出凌晨三點掛 60 分鐘和開賣尖峰掛 6 分鐘的差別——後者燒掉的信任與退款，可能是前者的好幾倍。只盯總量的團隊，會很自然地把維護排在自己方便的時候，然後在最貴的那一個小時裸奔。要修，就得替不同時段加權，讓尖峰的一分鐘扣掉不只一分鐘。
- 凍結發版可能把修復也一起凍住。燒光就停止上線，本意是逼團隊回頭補洞；執行得太死，連修復用的變更都卡在流程外，問題只會累積成下一次更大的一版。政策線要先寫清楚哪一類變更不受限——修缺陷、補監控、加告警，這三種永遠放行，否則它會在最需要動手的時候把手綁起來。
把道德題改寫成預算題
道德不會用完，預算會。
「不准出事」是一道道德題：它沒有刻度，所以永遠吵不完——每個人都能說自己已經很小心，也沒有人能證明對方不夠小心。錯誤預算把同一件事改寫成一筆預算題，會議上的題目就從「你在不在乎品質」換成「這一季剩下的 15 分鐘要留給誰」。有刻度的題目，才排得出順序。不過這張圖畫得出還剩幾分鐘，畫不出那幾分鐘掉在誰身上：同樣是 6 分鐘，掉在凌晨的自動對帳，跟掉在有人正把信用卡號打到一半的那一刻，是兩種完全不同的痛。P.A.I.N. 的第一格永遠先問「誰在痛」，而錯誤預算的分子裡沒有這一欄。今晚可以做一件小事：把上一季的事故清單攤開，在每一則後面加一欄「那段時間，誰正打算掏錢」。加完你會看到，用分鐘數排出來的順序，跟用這一欄排出來的順序，長得不一樣。
常見問題
錯誤預算怎麼算？
先訂一個週期和一個 SLO，再把「允許不達標」的比例乘回週期總時間。以一季 90 天為例，總時間是 129600 分鐘；SLO 訂 99.9%，允許不達標的是千分之一，額度就是 129.6 分鐘。訂 99.95% 剩 64.8 分鐘，訂 99.99% 只剩不到 13 分鐘。算式本身沒有難度，真正要吵的是「不達標」怎麼認定：伺服器沒回應才算，或者使用者買不成票就算。後者算出來的燒速通常快上好幾倍，也比較貼近生意的真相。
錯誤預算和 SLA 有什麼不同？
SLA 是寫給客戶看的合約，違反了要賠錢或退費；SLO 是團隊寫給自己的內部目標，通常訂得比 SLA 嚴一些；錯誤預算則是 SLO 的另一面——把 SLO 沒承諾到的那一小塊時間，明白地換算成一筆會被花完的額度。三者管的事情不同：SLA 決定你賠多少，SLO 決定你追什麼，錯誤預算決定你這一季還能冒多少險。多數團隊簽了 SLA、也講得出 SLO，卻從沒把第三個算出來，於是「還能不能發版」永遠靠吵的。
額度燒完，真的要停止發版嗎？
重點在於它會自動觸發，至於停幾天反而是次要的。實務上多數團隊採取的做法，是切換到一種「只准修、不准加」的模式：修復缺陷、補監控、還技術債照走，新功能一律排隊。這樣做有兩個作用，一是讓補洞的時間真的被排進行事曆，二是讓「要不要更穩」這件事第一次有人負責回答。如果每次燒完都用「這次很趕」放行，那條零線在第二次之後就沒有人會再看它一眼，你也等於白算了一整季。
小公司沒有 SRE 團隊，用得上錯誤預算嗎？
用得上，而且門檻比想像中低。你不需要完整的監控平台，只需要三樣東西：一個大家同意的「壞掉」定義、一份誠實記錄的事故清單、一個掛在牆上的剩餘數字。十個人的團隊可以把週期縮短成一個月，額度自然小、感覺更真——一個月 43200 分鐘的千分之一是 43.2 分鐘，掉一次就少一大截，反而比季度制更容易讓人有感。難的從來都在事故當下那一筆：願意誠實記下這次到底壞了幾分鐘。
額度算的是還剩幾分鐘；掉下去之後能多快站回來，是另一把尺，那把尺叫韌性三角。至於哪幾種事故值得優先花額度去防，可以先用風險矩陣把清單排一次序，再回頭看這一季的分鐘該怎麼分——先排序，再分錢，這條線才不會每一季都燒在同一個地方。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。