Toil 消除與工程平衡#

可靠性靠的不只是當下把系統撐住，更靠把「撐住系統」這件事本身自動化掉。Toil（瑣務）是維運中那種重複、手動、沒有持久價值的勞動——它不會讓系統變好，只會隨規模膨脹，最終吃掉團隊改善系統的時間。本章談如何辨識 toil、為什麼要設工程時間的下限、以及如何系統性削減。

什麼是 Toil#

Toil 不是「我不喜歡做的工作」，它有明確的判準。一項工作越符合以下特徵，就越是 toil：

• 手動（Manual）：需要人親手執行步驟，而非系統自動完成。
• 重複（Repetitive）：同樣的事一做再做，而非一次性的。
• 可自動化（Automatable）：機器完全能代勞，只是還沒去做。
• 戰術性（Tactical）：被動救火、回應中斷，而非主動規劃。
• 無持久價值（No enduring value）：做完之後系統狀態沒有變得更好，下次還得再做一遍。
• 隨規模線性成長（Scales linearly）：服務規模翻倍，這項工作量也跟著翻倍——這是最危險的特徵。

「隨規模線性成長」是 toil 最致命的訊號。一項手動工作如果隨流量、機器數、客戶數同比增加，它終將吞噬整個團隊。自動化的本質，就是切斷工作量與規模之間的線性關係。

Toil 不是什麼#

容易跟 toil 混淆的兩類工作，需要區分清楚——因為它們的處理方式不同：

判準是「做完之後系統有沒有變得更好」。一次深入的根因除錯雖然繁瑣痛苦，但它讓系統永久消除了一個故障源——這是工程，不是 toil。把手動重啟服務這種事重複一百次，系統還是老樣子——這才是 toil。

50% 工程上限#

維運團隊應該為「toil 的時間占比」設一個上限——常見的基準是 每人花在 toil 上的時間不超過 50%。剩下的至少一半，必須投入能減少未來 toil 的工程工作（自動化、架構改善、工具建設）。

這條規則的邏輯是一個正向循環：

flowchart LR
    A[投入工程時間] --> B[自動化掉部分 toil]
    B --> C[toil 占比下降]
    C --> D[釋出更多工程時間]
    D --> A
    E[toil 失控膨脹] -.->|無工程時間| F[只能繼續救火]
    F -.-> E

• 若 toil 長期超過 50%：團隊被救火淹沒，沒有餘力做改善，toil 只會越積越多，最終陷入「越忙越糟」的死亡螺旋。
• 若刻意守住 50%：用一半時間持續削減 toil，長期下來總 toil 量會被壓低，團隊規模才能不隨服務規模等比膨脹。

四類工作分配#

把團隊的時間攤開來看，大致可分為四類。健康的分配是讓「工程工作」站穩、把 toil 壓在上限以下：

團隊時間占比（健康狀態示意）
┌───────────────────────────────────────────────┐
│ 軟體 + 系統工程 (持久價值)                       │  ≥ 50%
│ ███████████████████████████                     │
├───────────────────────────────────────────────┤
│ Toil (瑣務，須壓在上限以下)                      │  ≤ 50%
│ ████████████                                    │
├───────────────────────────────────────────────┤
│ 行政開銷                                         │  精簡
│ ████                                            │
└───────────────────────────────────────────────┘

過量 Toil 的危害#

當 toil 失控，傷害遠不只是「事情做不完」：

• 職業倦怠：長期重複勞動消磨士氣，優秀工程師流失。
• 能力停滯：沒時間做工程，技術能力與職涯發展停擺。
• 可靠性下降：手動操作越多，人為失誤越多，反而傷害可靠性。
• 無法規模化：團隊規模被迫隨服務規模等比擴張，成本失控。
• 創新停擺：所有時間都在救火，沒有餘力做能根本改善系統的事。

削減策略#

• 先量化再削減：用工單、值班記錄統計 toil 來源與占比，找出最大的幾個源頭優先處理。
• 針對線性成長源頭：優先自動化那些「隨規模膨脹」的工作，投資報酬率最高。
• 把救火變成預防：每次處理事故後，問「怎樣讓它下次不再發生、或自動恢復」，而非只是當下解決。
• 自助化（self-service）：把常見的人工請求做成讓需求方自助操作的工具或平台，從源頭消滅工單。
• 設定預算與守門：把 50% 上限當成硬性指標追蹤；一旦逼近，主動把 toil 退回給開發團隊或暫停接收新負載。

自動化不是為了「不做事」，而是把人的精力從機器能做的事上解放出來，投入到只有人能做的判斷、設計與改善上。這正是維運從「人肉腳本」走向「工程學科」的關鍵。

小結#

• Toil 有明確判準：手動、重複、可自動化、戰術性、無持久價值、隨規模線性成長。
• 區分 toil、行政開銷與有價值的繁瑣工作——判準是「做完系統有沒有變更好」。
• 守住 50% 工程上限，靠工程時間持續削減 toil，才能打破「越忙越糟」的螺旋。
• 過量 toil 會引發倦怠、能力停滯與可靠性下降；削減要從量化與線性成長源頭著手。