告警設計：半夜被叫醒，然後發現什麼都不用做

告警設計有一堆技巧，但它們全部從同一個問題推導出來：

三個層級，把東西放對地方

大部分團隊的問題是把後兩類做成了第一類。「磁碟使用率 80%」——它會在三週後才滿，這是 ticket；「單一 pod 重啟了」——K8s 會自己處理，這是 dashboard。

可行動性的三個檢查

每一條 page 都要有 runbook

annotations:
  summary: "付款 SLO 快速燃燒（2 天內將耗盡預算）"
  description: "目前錯誤率 {{ $value | humanizePercentage }}，正常應低於 0.1%"
  runbook_url: "https://wiki/runbooks/payment-slo-burn"
  dashboard_url: "https://grafana/d/payment-overview"

這是 Google SRE 最常被引用的一條原則，而它的理由非常實際。

兩種告警的差別

❌ 原因告警：CPU > 80%、記憶體 > 90%、單一 pod 重啟、佇列長度 > 1000
✅ 徵狀告警：付款成功率低於 SLO、SLO 錯誤預算正在快速燃燒、關鍵旅程的黑箱探針失敗

為什麼原因告警不好用

• 它會誤報：CPU 80% 可能完全沒問題（批次任務正常跑滿）。而使用者沒有受影響時把人叫醒，就是純粹的損耗。
• 它會漏報：使用者受影響的原因有無限多種，你不可能為每一種都設一條告警。而徵狀只有一個——「使用者用不了」。
• 它的數量會爆炸：一次資料庫變慢會同時觸發 CPU、連線數、佇列、延遲、錯誤率——五條告警，一個問題。

那原因指標就不用管了嗎

要管，但放對地方：

• 放儀表板：被叫醒之後，它們是你查根因的材料（ch01 的白箱指標）。
• 做成 ticket：「磁碟三週後會滿」「憑證 30 天後到期」這類有預測性的飽和度指標——它們的價值是讓你在變成徵狀之前就處理掉。

唯一該對原因 page 的情況

下面這條規則看起來很合理，但它幾乎必定會誤報：

- alert: HighErrorRate
  expr: rate(errors[5m]) > 0.01      # ← 沒有 for

只要有任何一個評估週期超標（可能只是一次部署造成的瞬間 5xx），它就會響，然後在下一個週期自己恢復。

for：問題要持續多久才算數

- alert: HighErrorRate
  expr: rate(errors[5m]) > 0.01
  for: 10m                           # 連續超標 10 分鐘才觸發

• 期間規則處於 pending 狀態，不發通知；持續滿 for 才變成 firing。
• 代價是延遲：for: 10m 意味著真的出事時，你也晚 10 分鐘才知道。

災難級（burn rate 14.4×）  → for: 2m   （寧可偶爾誤報）
嚴重（burn rate 6×）       → for: 15m
一般（burn rate 3×）       → for: 1h   （做成 ticket）

三個相關的時間參數不要搞混

另一種抖動：門檻邊緣來回震盪

指標剛好在門檻附近徘徊時，告警會反覆 firing / resolved。除了 for，還有兩個做法：

• 用比例而不是絕對值：「錯誤率 > 1%」比「錯誤數 > 100」穩定得多——後者會隨流量自然波動。
• 用 max_over_time 之類的平滑（ch03），讓短暫回落不會立刻解除告警。

就算每一條告警規則都設計良好，一次真實故障仍然可能產生幾十則通知——因為它同時影響了很多實例、很多服務。Alertmanager 這一層的工作就是把它們收斂成人類可以處理的形式。

① 分組（grouping）：把同類的合成一則

route:
  group_by: ['alertname', 'service']   # 同一個服務的同一種告警合成一則
  group_wait: 30s          # 第一則到達後，等 30 秒收集同組的其他告警
  group_interval: 5m       # 同組有新成員時，最快 5 分鐘再通知一次
  repeat_interval: 4h      # 問題仍未解決時，多久提醒一次

group_wait 是最有價值的一個：30 台機器同時出問題時，它會等 30 秒把它們收成一則「30 個實例受影響」，而不是發 30 則通知。

② 抑制（inhibition）：根因告警壓住衍生告警

inhibit_rules:
  - source_matchers: [ severity="critical", alertname="ClusterDown" ]
    target_matchers: [ severity="warning" ]
    equal: ['cluster']     # 同一個叢集裡的 warning 全部壓住

③ 靜音（silence）：處理中的問題不要再吵

已經在處理、或正在做計畫性維護時，手動靜音一段時間。但靜音有兩個要注意的地方：

• 一定要設到期時間，而且不要太長。永久靜音等於刪除告警，而且沒有人記得。
• 定期檢視現有的靜音：一條被靜音三個月的告警，通常代表它該被修掉或刪掉了。

④ dead man's switch：誰來監控監控系統

- alert: Watchdog
  expr: vector(1)          # 永遠為真
  labels: { severity: none }
  annotations: { summary: "這條告警應該永遠在響" }

徵狀

某次事故的檢討會上，時間軸長這樣：

02:14  支付服務開始大量失敗
02:14  告警觸發，送進值班頻道
02:54  客服接到第 6 通客訴，打電話給值班工程師    ← 40 分鐘後
02:58  開始處理
03:20  恢復

• 告警在第一分鐘就響了——系統沒有漏報。
• 但沒有人看見它。
• 調紀錄發現：那 40 分鐘裡，同一個頻道收到了 73 則告警。

診斷

把過去一個月的告警拉出來統計（這件事本身就該定期做）：

根因（四個設計問題）

修法

結果

改造前：412 則/月，可行動 5.6%
改造後： 31 則/月，可行動 74%

告警的接收端是人，而人的處理能力是有明確上限的。把這件事量化出來，告警治理才有客觀依據。

三個該量的數字

• 每次值班的中斷次數：Google SRE 的經驗值是一個 12 小時的班次最多處理 2 個事件。超過這個數字，處理品質會明顯下降——因為每個事件都需要調查、記錄、跟進。
• 可行動比例：導致實際處理動作的告警 / 全部告警。低於 50% 就該做減法了。
• 深夜中斷次數：半夜的告警成本遠高於白天——它影響的不只是那一小時，還有隔天一整天。

on-call 的基本盤（與這一章直接相關的部分）

• 輪值要可預測，而且交接時要有明確的「目前有什麼未結事項」。
• 每一條 page 都要有 runbook（本章第一節）。
• 升級路徑要事先寫好：多久沒有人回應就自動升級到下一個人。本章那個案例，如果有升級機制，40 分鐘會變成 5 分鐘。
• 事後檢討要無咎責：目的是找出系統與流程的缺陷，不是找出「誰沒看告警」。本章的案例如果檢討成「值班的人不夠認真」，那 412 則告警下個月還在。

toil：能自動化的就不要叫人

如果某條告警的處理動作每次都一樣，那它就是 toil 的訊號：

「pod 記憶體高 → 重啟它」        → 設好 liveness probe 與資源限制，讓 K8s 自己做
「磁碟滿 → 清理舊日誌」          → 設定保留策略（ch04）
「流量高 → 手動擴容」            → HPA 自動擴縮
「某個依賴慢 → 手動關掉功能」    → 熔斷與降級（見 /cool/resilience/）

建立順序

每條告警上線前的檢查表

□ 使用者受到影響了嗎？（否 → 不該 page）
□ 有具體的處理動作嗎？（否 → 不該 page）
□ 需要現在做嗎？（否 → ticket）
□ 這個動作能自動化嗎？（能 → 自動化，不要叫人）
□ 有 for 或等效的持續條件嗎？
□ 有 runbook 嗎？
□ 這個問題會不會同時觸發其他告警？（會 → 設抑制規則）

定期健檢（每季一次，30 分鐘）

• 統計：告警總數、可行動比例、每次值班的中斷次數、深夜中斷次數。
• 找出最吵的前五條規則，逐一問：修掉根因、加 for、降級成 ticket、還是直接刪除？
• 檢視所有靜音中的告警：靜音超過一個月的，通常該刪或該修。
• 檢查有沒有「該響卻沒響」的**：拿上一季的事故清單對照——每一次事故是告警先發現的，還是使用者先發現的？後者的比例是這套系統最誠實的成績單。

什麼時候不要加告警

• 「以防萬一」：這是告警數量失控的頭號來源。沒有明確可行動性的，放儀表板。
• 事故之後的反射性動作：出了事就加一條告警，感覺有在改進——但如果根因已經修掉了，那條告警永遠不會再響；如果沒修掉，它只是提醒你問題還在。先問「加這條告警能讓下次更快發現嗎」。
• 已經被更上層的徵狀告警涵蓋的：SLO burn rate 已經會抓到使用者影響，就不需要再為每個可能的原因各設一條。

四筆帳

• 人的耗損：這是最貴的一筆，而且不會出現在任何帳單上。長期的高頻值班會直接造成人員流失，而補一個熟悉系統的人，成本遠高於任何基礎設施。
• 信任的耗損：一旦「告警＝可能是雜訊」成為預設，重建信任比建立它困難得多。這是不可逆的成本。
• 維護成本：告警規則會腐化——服務改名、指標改名、門檻過時。一條指向不存在指標的告警規則永遠不會響，而且沒有人會發現（這正是需要定期健檢與 dead man's switch 的理由）。
• 過度收斂的風險：分組與抑制設得太激進，可能把真正獨立的問題壓成一則。

三個盲點

• 告警只涵蓋你想得到的失敗模式。ch01 的「未知的未知」在告警這一層無解——徵狀告警之所以有價值，正是因為它不需要預先知道原因。
• 它看不到緩慢的劣化。延遲每週增加 5%，任何單一時間點都不會超標，但半年後就是災難。這要靠趨勢檢視與容量規劃，不是告警。
• 它不知道「這次是計畫性的」。部署、資料遷移、壓力測試都會觸發告警。這要靠靜音與變更管理系統的整合來處理，而「每次部署都手動靜音」本身也是一種 toil。

把這一章收成三句

最後一章回到 Java 這邊：把前面七章的東西真正接到一個 Spring 專案上，並且算一次完整的帳——因為可觀測性系統很容易變成整個架構裡最貴的一套系統。