本章深入探討 On-Call（值班）的具體實踐，回應了第一本 SRE 書中讀者提出的常見問題和回饋，包括小型團隊如何運作值班、開發人員與 DevOps 如何組織值班職責、以及如何處理過高的 pager 負載等議題。

旅程概觀：從「開發人員也值班」到「SRE 擁有值班」#

本章追溯了一家公司從幾位創辦人到擁有專屬 SRE 團隊的 on-call 演進過程。這個旅程分為幾個階段：

1. 所有人都是功能開發者，所有人輪值
2. 公司成長後，一小群開發者兼任營運職責
3. 引入專職 SRE 角色，專責生產環境可靠性

在 Google，值班是 SRE 的核心特徵之一。SRE 團隊負責緩解事件、修復生產問題和自動化營運任務。由於大多數 SRE 團隊尚未完全自動化所有營運任務，因此需要人作為聯絡點——即值班工程師。

Google 內部的 On-Call 設置範例#

範例 1：單一站點的 Google Cloud 團隊#

一個負責多個 Google Cloud 產品的 SRE 團隊面臨了典型的挑戰。團隊採取的方法包括：

• 技術領導兼任 on-call：團隊技術領導（tech lead）和管理者都參與值班輪值，展示「以身作則」的精神
• 公平的排程系統：使用權重系統來避免對個別成員的不公平分配
• shadow 制度：讓新成員在正式值班前先以「影子」角色跟隨資深 on-call 學習
• 訓練週期：通常需要約一個季度的學習，包含 reverse shadow 階段（新人為主要值班，資深成員提供備援）

範例 2：多站點搜索 SRE 團隊#

大規模搜索服務的 SRE 團隊展示了如何管理更複雜的值班設置：

• follow-the-sun 模式：利用不同時區的站點實現 12 小時輪值
• 分層值班：primary on-call 處理所有進入的 page，secondary on-call 在 primary 需要協助時介入
• 值班結束後的報告：填寫結構化的值班報告，記錄事件處理情況，有助於知識傳承

範例 3：Evernote 的 SRE On-Call#

Evernote 提供了一個 Google 外部的實踐案例，展示中型公司如何建立有效的值班制度：

接受 SLO 作為共同語言： Evernote 建立了 SLO（Service Level Objectives）來確保監控和值班的焦點放在使用者體驗上。他們將事件分為三個優先等級：

• P1：立即處理 — 立即可行動、呼叫值班人員、影響 SLO
• P2：下個工作日處理 — 通常非面向客戶或範圍有限
• P3：僅供資訊 — 收集在儀表板和被動電子郵件中

重構監控和指標： 團隊專注於高階指標（如 API 回應性）而非低階基礎設施指標（如 MySQL 的 InnoDB 行鎖等待），讓值班人員能專注於使用者在停機期間的真正痛點。

追蹤長期績效： 實施每月服務審查會議，回顧上月的服務狀況和值班負擔，同時在公司內推廣 SLO 的重要性。

與 Google CRE 合作： 將目標以 SLO 表達後，能與 Google 的 Customer Reliability Engineering 團隊合作，在 SLO 影響事件時 CRE 會與 Evernote 工程師一同被呼叫。

實務執行細節#

Pager 負載剖析#

Pager 負載（Pager Load）是值班工程師在一個典型班次中收到的呼叫事件數量。影響 pager 負載的三大因素：

生產環境因素：

• 既有 bug 的數量
• 新 bug 引入的速率
• 新 bug 被識別的速度
• bug 被緩解和移除的速度

告警因素：

• 觸發呼叫告警的閾值設定
• 新呼叫告警的引入
• 服務 SLO 與其依賴服務 SLO 的一致性

人為流程因素：

• 修復和後續跟進的嚴謹程度
• 收集的呼叫告警資料品質
• 對 pager 負載趨勢的關注
• 人為對生產環境的手動變更

情境：過載的團隊#

Connection SRE 團隊的案例展示了一個團隊如何面對和解決高 pager 負載。團隊的 pager 預算是每班次 2 個事件，但過去一年每班次經常收到 5 個。三分之一的班次超出 pager 預算。

問題的根源：

• 團隊接管了超過 10 個開發團隊的軟體元件
• 對 Google 的客戶端邊緣和骨幹網路有硬性依賴
• 許多呼叫超出團隊的直接控制範圍
• 基礎設施正從 10 年舊框架遷移到新系統，變更速度前所未有

處理既有 Bug#

• 確保系統只有必要的複雜度
• 定期更新系統依賴的軟體和程式庫
• 執行定期的破壞性測試或 fuzzing（如 Netflix 的 Chaos Monkey）
• 除了整合和單元測試外，也進行定期的負載測試

處理新 Bug#

• 持續改進測試：對每個生產環境中發現的 bug 問「我們如何在上線前偵測到它？」
• 不忽略負載測試——許多 bug 只在特定負載條件下出現
• 在類似生產環境中進行 staging 測試
• 在生產環境中執行 Canarying（金絲雀發布）
• 對新 bug 保持低容忍度：採用「偵測、回滾、修復、再前滾」策略

最小化生產環境中的 bug 數量不僅減少 pager 負載，還能讓識別和分類新 bug 變得更容易。優先修復既有 bug 而非交付新功能。

適當的回應時間#

工程師不應該在收到呼叫後幾分鐘內就必須在電腦前工作，除非有非常好的理由。根據事件嚴重程度設定不同的回應時間：

識別延遲的縮短技巧#

• 使用好的告警和控制台：確保呼叫連結到相關監控控制台，保持 playbook 更新
• 練習緊急回應：執行「Wheel of Misfortune」演練
• 小規模發布：頻繁的小型發布讓 bug 與對應變更的關聯更容易
• 記錄變更：將變更資訊彙總到可搜尋的時間軸
• 尋求協助：值班工程師永遠不是孤身一人

緩解延遲的縮短技巧#

• 回滾變更：如果 bug 是最近的程式碼或配置發布引入的，優先回滾而非快速修復再前滾
• 功能隔離：設計系統使功能 X 出問題時可以透過 feature flag 停用，不影響功能 Y
• 排空請求（Drain）：將請求重新導向離開有 bug 的系統元素

如果你的目標是 99.99% 可用性，每季度大約只有 15 分鐘的錯誤預算。快速修復的建置步驟可能就超過 15 分鐘，因此回滾對使用者的影響遠小於前滾。

告警管理#

Google SRE 每 12 小時班次最多 2 個不同事件的上限，鼓勵我們對呼叫告警的配置和引入保持審慎。關鍵原則：

• 所有告警應立即可行動，且信噪比要高
• 如果團隊完全採用基於 SLO 的告警，放寬告警閾值很少是適當的回應
• 新告警應像新程式碼一樣被徹底審查，每個告警都應有對應的 playbook 條目
• 在正式升級為呼叫告警前，應先在生產環境中充分測試新告警（建議至少一周）

跟進的嚴謹度#

目標是識別每個呼叫的根本原因。「根本原因」延伸到機器之外，進入團隊的流程。對每個呼叫告警，考慮：

• 如何防止這個特定 bug 再次發生？
• 如何防止類似的 bug 再次發生？
• 什麼測試能在上線前發現這個 bug？
• 什麼工單告警能在 bug 變嚴重前觸發行動？

三層修復策略：

• 點修復（Point fix）：直接修復當前問題
• 系統性修復（Systemic fix）：使用自動化確保所有類似情境都不再出現此問題
• 監控/預防修復（Monitoring fix）：在問題尚未影響服務前預先告警

將呼叫解釋為「暫時性的」，或因為系統「自行修復」而不採取任何行動，等於邀請 bug 再次發生並造成下一次呼叫。

資料品質#

收集結構化的呼叫資料是做出正確決策的基礎。建議的做法：

• 為每個呼叫告警在 bug 追蹤系統中建立佔位 bug
• 值班工程師建立呼叫告警與相關 bug 之間的連結
• 利用結構化資料產生報告，回答「哪些 bug 造成最多呼叫」等問題
• 定義並記錄團隊對資料收集的政策和期望

警覺性#

團隊常因千刀萬剮而陷入營運超載。避免「溫水煮青蛙」的技巧：

• 在生產會議中定期討論 pager 負載趨勢（建議使用 21 天移動平均）
• 當 pager 負載超過團隊預先同意的「警告」閾值時設置工單告警
• 定期召開 SRE 與開發團隊的會議，討論生產環境現狀

On-Call 彈性#

班次長度#

需要處理每日一次以上呼叫的值班輪值，建議限制班次長度為 12 小時。較短的班次對工程師的心理健康更好。即使在單一地點，也可以讓 12 小時班次運作——例如一人負責白天，另一人負責夜間。

自動化排班#

隨著團隊成長，管理排班限制變得困難。自動化排班工具應具備：

• 因應成員需求變化重新安排班次
• 自動重新平衡值班負載
• 考慮個人偏好和歷史負載確保公平
• 不修改已產生的排程

短期換班#

建立去中心化的換班機制，讓團隊成員能更新值班輪值。同儕審查的變更提供了安全性和彈性之間的良好平衡。

長期休息#

有時團隊成員需要因個人情況或倦怠暫時離開值班。建議的最低人力配置：

• 多站點 24/7 配置：每站點至少 6 人（最低 5 人加 1 人緩衝）
• 單站點 24/7 配置：每站點至少 9 人（最低 8 人加 1 人緩衝）

兼職工作安排#

兼職與值班是可以相容的。兩種兼職模式：

• 每週減少全天工作天數：可以設定不在非工作日排班
• 每天減少工作時數：可以與其他工程師分享值班時段

On-Call 團隊動態#

情境：「撐過這一週」的文化#

一家公司從所有人值班演進到 25 名功能開發者和 5 名 ops 共同輪值，但因高 pager 量和低士氣而困擾。功能開發者優先開發新功能，值班跟進的實施很慢。

提案一：賦權你的 Ops 工程師#

將營運組織重塑為 SRE 模式，明確宣告 SRE 擁有站點營運的所有權：

• Action item 只指派給 SRE，SRE 與主題專家合作完成
• 鼓勵 SRE 深入程式碼自行進行變更
• SRE 負責定義共享的可靠性路線圖、推動問題完整解決、維護監控規則

提案二：改善團隊關係#

建立更強的團隊紐帶：

• 安排團隊活動來加強團隊連結
• 讓值班輪值的所有成員坐在一起，不分職稱和功能領域
• 鼓勵團隊一起用餐
• 「我保護我的同事」 的心態轉化為更有生產力的工作氛圍

結論#

SRE 的 on-call 不同於傳統的 ops 角色。SRE 完全擁有生產環境，並通過定義適當的可靠性閾值、開發自動化和執行策略性工程專案來改善它。

如果你的值班團隊淹沒在無止盡的告警中，建議退後一步從更高層次觀察情況，與其他 SRE 和合作團隊交換意見，然後系統性地解決問題。深思熟慮地架構 on-call 制度，對值班工程師、團隊和整個公司來說都是值得的投資。