本章探討 SRE 團隊如何識別、應對並從工作過載（overload）中恢復。當操作負載超出團隊的處理能力時，工程師開始加班處理工單與告警，長期工程專案因此停滯，壓力與疲憊進而引發更多錯誤，最終影響服務可靠性與終端使用者體驗。
操作負載的定義與過載的門檻#
操作負載（operational load） 指維持系統與服務正常運作所需的持續性維護工作，包含三大類型：
- 告警（pages）：需要立即處理的緊急事件
- 工單（tickets）：可能有緊迫期限的問題
- 持續性操作職責（ongoing operational responsibilities）：日常維運工作
告警和緊急工單會打斷工程師的專案工作，因此被稱為中斷（interrupts）。Google SRE 團隊將操作工作的上限設定為工程師時間的 50%。當團隊無法在關鍵優先事項上取得進展、持續被緊急問題搶佔時，就進入了**操作過載（operational overload）**狀態。
從負載到過載#
過載可分為兩種型態：
- 客觀過載（work overload）：任務量確實超出團隊在限定時間內能完成的範圍
- 感知過載（perceived overload）：團隊成員主觀感覺工作過多，即使客觀負載未必增加
感知過載的成因#
感知過載通常發生在多項組織或工作變動同時出現，而團隊缺乏與管理層溝通的機會時。認知偏誤會使人錯估工作量——例如看到大量待處理工單時就感到不堪重負，即使這些工單實際上可以快速處理。
當頻繁的中斷搭配外部壓力因素（如害怕讓隊友失望、工作不安全感、健康問題等），即使是少量工作也可能轉變為感知過載。
分析團隊狀況時，不應假設工作量本身需要改變。建議先量化團隊面臨的工作量及其隨時間的變化趨勢，再輔以心理壓力因素的評估，才能做出合理的決策。
案例研究 1：半數團隊離開導致的工作過載#
背景#
Google 內部儲存 SRE 團隊負責 Gmail、Google Drive、Google Groups 等多個服務的後端。2016 年中期，團隊三分之二的成員（包括最資深的工程師/經理）在短時間內因各自不同原因轉調其他職位。每位成員的專業知識各自侷限於不同的生產環境領域，進一步惡化了人力不足的問題。
問題#
專案工作開始落後，工單堆積如山，團隊缺乏頻寬處理積壓。嘗試卸載工作時，團隊遭遇兩個心理障礙：
- 沉沒成本謬誤：放棄進行中的工作讓人感覺之前的努力白費
- 壓倒感：需要投入時間自動化或修復根本原因，但面對已經龐大的待辦事項時，所有工作都讓人感到不堪重負
解決方案#
團隊集中在一個房間，列出所有職責（專案積壓、操作工作、工單），然後進行分類：
- 辨識可快速部署的低成本自動化，以顯著降低操作負載
- 撰寫文件讓客戶可以自助解決常見問題
- 關閉大量積壓工單——多數已過時、重複或不如聲稱的那麼緊急
- 對不確定的任務先標記為「待二次分類」，最終發現幾乎沒有任務值得恢復
在兩天內（一天密集分類 + 一天文件化與自動化），大幅縮小的團隊解決了數月的中斷積壓。
經驗教訓#
- 識別和界定過載是修復的第一步
- 建立每兩週一次的定期分類機制
- 技術負責人定期檢查任務佇列，設定每人不超過 10 張未關閉工單的門檻
- 超過門檻時可採取：提醒關閉過期工單、重新分配、組織團隊修復日等措施
案例研究 2：組織與工作變動後的感知過載#
背景#
該 SRE 團隊分布在雪梨和蘇黎世兩地，各有六到七名 on-call 工程師。雪梨團隊運作健康，但蘇黎世團隊陷入過載。多個觸發因素同時出現：
- 開始接管更嘈雜且整合度低的新服務
- 技術負責人和另一名成員離開團隊
- 新服務未調整的監控導致每班告警增加
- 新的工單告警揭露了先前被忽視的技術債
- 新的三天工單 SLO 要求 on-call 人員在班次期間更快解決工單
- 新經理同時管理三個團隊，未參與 on-call 輪值，無法直接感受壓力
惡化過程#
團隊向經理反映過載狀況時，經理不認同。隨著長時間工作持續，疲憊降低了生產力，任務累積速度超過解決速度。感知過載演變為客觀過載，形成惡性循環：
- 信任與依賴感崩潰——成員開始假設無法依靠他人完成工作
- 心理安全感（psychological safety） 降低，協作停止
- 團隊調查顯示成員不再有歸屬感，不關心職涯發展，晉升率降至歷史新低
解決方案#
分為短期、中期與長期三階段：
短期（一個月內）：
- 建立半定期圓桌會議討論問題、釋放挫折感
- 改善負載衡量指標（從告警數量改為 on-call 後解決工單所需時間）
- 審計並移除垃圾告警，慷慨地靜音已知問題的告警
- 指派專屬經理（不再跨三個團隊），重建對管理層的信任
- 引入有經驗的 SRE 重新平衡團隊
- 舉辦團隊活動（午餐、桌遊）改善心理安全感
中期（三個月內）：
- 將操作工作盡量限制在 on-call 時段
- 將一個服務的責任歸還開發團隊
- 互相培訓，分享知識以加快問題排查
- 從遠端團隊引入 SRE 支援部分 on-call 班次
- 回填空缺職位
- 逐一處理靜音到期的告警，調整或修復根本問題
- 組織傾聽活動，管理層主動聆聽團隊痛點
長期：
- 對齊服務 SLO 與後端 SLO
- 推動服務標準化，降低認知負載並便於跨服務自動化
- 更新長期運行但未跟上變化的服務
成效#
數月後 on-call 班次變得安靜，團隊能夠協作處理困難事件。新成員加入後表示無法想像團隊曾經有此問題，認為這是一個溫暖且安全的工作環境。一年後匿名調查顯示團隊成員認為團隊是有效且安全的。
感知過載就是過載，其對團隊的影響與客觀工作過載相同。在案例 2 中，告警數量相較往年並未顯著變化，真正的問題在於人員流失、認知負載增加、工單噪音與新的 SLO 壓力共同造成的感知過載。
緩解過載的策略#
識別過載的症狀#
- 團隊士氣下降：抱怨增加，工作滿意度調查結果轉差
- 團隊成員長時間工作或帶病工作：加班且無補償是心理社會壓力源
- 更頻繁的疾病：過勞的成員更容易生病
- 不健康的任務佇列：積壓增長、錯過截止日期、無法定期進行審查
- 不平衡的指標：關閉單一問題耗時過長、toil 佔比過高、on-call 後工單關閉天數過多
沒有一體適用的衡量方式。每個團隊的過載反映在不同面向，團隊應共同決定使用什麼指標，而非由管理者單方面強加。
減少過載與恢復團隊健康#
識別並緩解心理社會壓力因素：
- 給予團隊成員更多控制權和參與權可降低感知過載
- 避免微管理；讓團隊參與優先排序以提升績效與滿意度
- 與合作的開發團隊溝通，他們可能能幫忙分擔
- 發掘專業領域並指派負責人與技術負責人，提升自信心
- 決策過程應透明，盡可能民主化
在一個季度內優先排序與分類：
- 團隊共同審查積壓工作，重新設定優先順序
- 安排無中斷時間（不 on-call），讓工程師專注於自動化和根本原因分析
- 必要時果斷放棄工作，例如將服務責任歸還開發團隊
保護未來的自己：
- 建立指標評估團隊工作量，定期審查
- 從過載中走出後，建立輕量級的分類流程以偵測增長的積壓
- 優先處理能減少重複性 toil 的專案工作
- 團隊每位成員都應對過載的早期警訊負責
結論#
過度的中斷可以輕易讓團隊從正常工作量滑向過載。過載會產生心理社會壓力，進一步影響工作，形成自我強化的惡性循環。感知過載是一種特殊形式的過載，無法僅通過 toil 或操作工作量來衡量。為了維持團隊工作量的平衡，持續監控過載（無論是感知的還是客觀的）至關重要。要更好地服務使用者並做好工作，首先需要尊重自己和團隊，維持日常工作的健康平衡。