「運維負擔（operational load）」是維持系統正常運作所需的工作。對複雜系統而言，這負擔分三類：
- Pages：生產告警，反應時間 SLO 以分鐘計
- Tickets：客戶請求，SLO 以小時、天、週計
- 持續性運維責任：發版、flag flip、即時諮詢——無嚴格 SLO 但會打斷人
怎麼分配#
- Pages：通常由「primary on-call」一人處理——避免旁觀者效應、減少打擾範圍
- Secondary on-call：當 fallthrough（漏接）後援；視團隊也可承擔 ticket 與其他中斷
- Tickets 處理方式各異：可由 primary 兼、由 secondary 兼、或設專責人；隨機指派或自取
- 持續性責任：由當值者承擔，或固定指派
衡量「怎麼處理中斷」的指標#
- 中斷的 SLO 或預期反應時間
- 通常積壓多少
- 嚴重度
- 頻率
- 可處理者人數（部分團隊要求一定 ticket 經驗才能 On-Call）
這些指標都把目標放在「最低反應時間」——人類成本幾乎沒被計入。
不完美的機器：人#
人類是不完美的處理器：會無聊、UI 不易理解、效率不高。把人類視為「就是這樣（Working as Intended）」並圍繞它做設計，才有意義。
認知 Flow 狀態#
「在 zone 裡」可以大幅提升生產力與創意。要達到 flow 需要：
- 清晰目標
- 即時回饋
- 控制感
- 時間扭曲
中斷會把人踢出 flow，需數十分鐘才能再進入。最大化 flow 時間是團隊管理的核心目標。
Flow 的兩種：創造模式 vs. Angry Birds 模式#
- 創造、投入：深入問題、忘了時間、忽略中斷
- Angry Birds 模式：當你 On-Call 或專心處理中斷時，中斷本身變成目標——關 bug、停 page，feedback 清楚——也是 flow
最壞的是「半 On-Call 半專案」——人處於持續可被打斷的狀態，永遠進不了任何一種 flow。
解法：極化時間（polarize）——某段時間全做專案、某段時間全處理中斷，不要混。
做好一件事#
「分心因子」太多#
Fred 週一早上想專心——但任何一刻可能：
- 自動分派的 ticket 今天到期
- 同事 page 找他諮詢某元件
- 上週的 ticket 被使用者提升優先級
- 為期 3 週的 rollout 出錯
- 使用者 IM 問問題
結果：即使行事曆全空，Fred 仍處於高度分心。
部分自己可控（關 email、關 IM）；部分由團隊政策造成——後者才是團隊該解決的。
極化時間#
對 context switch 賦予成本：一次 20 分鐘的中斷可能損失「兩個小時」的真正生產力。
把工作型態極化——理想是整週、最差也是整天甚至半天——讓每人每天「進公司就知道今天是哪一種」。
具體建議#
通則#
中斷量太大則加人——對 tickets 顯然；對 pages，可下放 secondary 或降級為 ticket。
On-Call#
Primary on-call 只做 On-Call。
- On-Call 那週的專案工作直接寫掉
- 若有不能延的專案 → 別 On-Call，請別人代
- 絕不期望同時 On-Call 又推進專案
Secondary 的職責決定他能不能做專案：
- 純 fallthrough → 可做專案
- 要協助 primary 解決多 page → 也要全職中斷
永遠都有清掃工作可做——文件、設定、自動化。今天清的下次 On-Call 就會感謝你。
Tickets#
隨機指派 ticket 給「倒霉鬼」是極度不尊重時間——刻意打破「不可被打斷」的原則。
把 tickets 當成全職角色（時間長度可管理）。若量超過 1 人，就兩人並行——不要把負擔灑滿全隊。
持續性責任#
盡量設計成可由任何人接手的角色（如 push manager）。離開 On-Call / 中斷週時正式交接，不要讓一個人從頭到尾跟一場數週的 rollout。
「要嘛做中斷，要嘛不做」#
- 沒輪到中斷時不要「順手」做 ticket——表面上看似在幫忙，實際上：
- 自己沒在做 flow 工作
- 拉低觀測數據，讓 ticket 量看起來可控但其實爆炸
減少中斷本身#
如果你的團隊得「同時太多人處理中斷」才能維持運作，那中斷量本身就有問題。
真的去分析 tickets#
很多 ticket / On-Call rotation 像「跑火線」（gauntlet）——每人喘口氣丟給下一人。
對策：
- 設計ticket / page handoff 流程，傳遞狀態
- 定期 scrub：以類別找根因
- 若根因可在合理時間內修，先靜音這類告警——同時給「修根因」設了硬期限
尊重自己也尊重客戶#
對使用者中斷，政策可以是強力工具：
- 把部分工作推回給請求者（請他們準備好 code change、配置變更）
- 沒人重視的工具就退役、棄置、替換
- 不要「過度服務」——這對誰都沒好處
通用原則：請求應該有意義、合理，並提供所需資訊與動作；你的回應應該有用、及時。雙向都需被尊重。