如果系統在正常運作時需要人類操作員介入，那就是 bug。 而「正常」的定義會隨系統成長而改變。 — Carla Geisser，Google SRE

SRE 把時間投入「長期工程專案」而非「運維工作」。為避免「運維」一詞被誤解，Google 用一個更精準的詞——瑣事（toil）。

什麼算瑣事#

瑣事不等於「我不喜歡的工作」，也不等於行政雜事或繁瑣工作。每個人的偏好不同，某些人甚至享受重複勞動。

瑣事是「綁在生產服務上的、手動、重複、可自動化、戰術性、無持久價值、且隨服務成長線性放大的工作」。

具備以下特徵愈多者，愈像瑣事：

• 手動（manual）：包括手動執行自動化腳本——耗的是人盯著的時間，不是流程跑的時間
• 重複（repetitive）：第一次、第二次不算；做到第三、第四次才是
• 可自動化（automatable）：機器可同等代勞，或更好的設計可消除這項任務
• 戰術性（tactical）：被中斷驅動、反應式，而非戰略驅動、主動規劃。回應 pager 屬此類
• 無持久價值（no enduring value）：做完後服務狀態未改善——若有永久改善，則不算瑣事
• 隨服務 O(n) 成長：流量或使用者翻倍就要做兩倍的事

不是瑣事的東西#

• 行政管理開銷（overhead）：團隊會議、目標設定（OKR）、週報、HR 文件
• 繁瑣但有長期價值的工作：例如徹底清理告警設定——粗活但不是瑣事

為什麼要少做瑣事#

Google SRE 對外承諾的目標：每位 SRE 投入瑣事的時間不超過 50%，剩餘至少 50% 必須投入工程專案。

理由：

• 瑣事若不約束，會自動膨脹到 100%
• 工程工作才能讓 SRE 規模隨服務「次線性」成長——這是 SRE 的「E」
• 招募新人時這是承諾，必須兌現

瑣事的下限#

SRE 若揹 On-Call，瑣事就有一個下限。例：6 人輪值、每人主要 1 週 + 次要 1 週，光是 On-Call 就佔 2/6 ≈ 33%；8 人輪值則 25%。

Google 季度調查顯示平均瑣事比例約 33%——優於 50% 目標，但有極端值（從 0% 到 80%）。當個別 SRE 報告瑣事過高時，是經理該重新分配負擔的訊號。

瑣事的主要來源#

• 中斷（非緊急的服務相關訊息與郵件）——最大宗
• On-Call 緊急應變
• Release 與 push

什麼算「工程」#

工程工作的特徵：新穎、需人類判斷、產生永久改善、由策略引導。SRE 的活動分四類：

• 軟體工程：寫或改程式碼（自動化腳本、工具、框架、可擴展性與可靠性的功能、基礎建設程式碼加固）
• 系統工程：一次性的配置改動產生長期效益（監控設定、負載平衡配置、伺服器調校、OS 參數、為開發團隊做生產化諮詢）
• 瑣事：如上定義
• 管理開銷：行政性質、與服務無直接關聯

「50% 工程」是以幾季或一年為單位的平均值。瑣事有突發性，某季略低於 50% 不可怕；若長期顯著低於 50% 就是警訊，需團隊回頭檢視。

瑣事一定是壞事嗎#

少量瑣事不一定不好——可預期、低風險、能帶來快速完成感，部分人甚至偏好這類工作。問題在於量。

過量瑣事會引發以下惡果：

• 職涯停滯：粗活有獎勵，但無法靠粗活建立職涯
• 士氣低落：每個人耐受度不同，但都有上限——超過會 burnout
• 造成混淆：對外造成「SRE 也是運維部門」的錯覺
• 拖慢進度：SRE 忙於救火，功能上線速度降低
• 塑造先例：愈樂意接，開發團隊愈會把運維工作丟過來
• 促成流失：團隊最好的工程師會去找更有挑戰的工作
• 違背招募承諾：新進 SRE 期望做工程，發現都在做瑣事 → 士氣受傷

結語#

若每人每週都用好的工程手段消除一點瑣事，整個服務就會持續變乾淨。把集體精力投入下一代服務設計與跨團隊工具——多發明、少瑣事。