告警不該對「有錯誤」響，而該對「正在以會燒光 error budget 的速度出錯」響。把 SLO 換算成燃燒率（burn rate），再用多窗口把「夠嚴重」與「還在持續」兩件事分開判斷——這是防守應用層 SLO 最穩的告警方式。
🧠 Intuition
TIP
好告警要同時顧四件事：精確度（響的都是真事件）、召回率（真事件都會響）、偵測時間（多快響）、重置時間（修好後多快停）。四者互相拉扯，燃燒率告警就是在它們之間找平衡。
- Burn rate（燃燒率）＝相對於 SLO，error budget 被消耗的速度。以 SLO 99.9% / 30 天為例：burn rate 1 剛好 30 天燒完、burn rate 10 只要 3 天、burn rate 1000（100% 全掛）43 分鐘就見底。
- 用燃燒率當告警條件，等於直接問「照這個速度，budget 會不會很快燒光」——比「錯誤率超過某個死閾值」更貼近真正該不該叫人。
- 症狀 vs. 原因：page（呼叫人類）應綁在使用者可感的症狀（budget 正在快速流失）上，而非某個內部原因（某台 CPU 高）。原因型訊號留給除錯，不該打斷睡眠。
- 告警分級對應處置：快速燒光 → page；緩慢滲漏 → ticket（工單）；其餘 → 留在儀表板。
⚖️ Tradeoffs
固定窗口的錯誤率閾值 — 最直覺，但顧此失彼
- 窗口太短（如 10 分鐘 error rate ≥ 0.1% 就響）：偵測快，但精確度極低——0.1% 撐 10 分鐘只燒掉 0.02% 月度 budget 卻天天狂響，全部不理仍能達標。
- 窗口太長（如 36 小時）：精確度上來了，但重置時間極差——100% 中斷修好後告警還會掛 36 小時，且長窗口的率值計算很吃記憶體/IO。
- 加
for（持續時間）也救不了：波動性 SLI 只要一瞬間回到閾值內就重置計時器，可能永遠不觸發——每 10 分鐘爆一次的尖峰燒掉 35% budget，告警卻從頭到尾沒響過。
多窗口、多燃燒率告警 — Workbook 推薦的做法
- 一條規則配一組（長窗口 + 燃燒率 + 通知類型），依嚴重度分級。99.9% SLO 的常見起手式：1 小時 / burn 14.4（燒 2%）→ page；6 小時 / burn 6（燒 5%）→ page；3 天 / burn 1（燒 10%）→ ticket。
- 每級再加一個短窗口（長窗口的 ~1/12）當確認閘門：長窗口判斷「夠嚴重」，短窗口判斷「現在還在燒」。錯誤一停，短窗口很快掉回閾值下、告警隨即停止，不必空等長窗口的 60 分鐘。
- 換來精確度、召回率、重置時間三者兼顧；代價是參數變多、規則較難維護，多條同時成立時要做告警抑制避免重複通知。
- 低流量服務是例外：每小時才 10 個請求時，單一失敗就是 10% 錯誤率、瞬間 1000x burn rate。得靠合成流量、聚合同故障域的小服務、或與利害關係人協商調低 SLO 來處理。
🔑 Takeaways
- 告警要對準燃燒率（budget 消耗速度），不是死的錯誤率閾值——快燒 page、慢滲 ticket。
- 用精確度 / 召回率 / 偵測時間 / 重置時間四把尺評估告警策略；固定單一窗口總會在某把尺上失分。
- 首選 multiwindow, multi-burn-rate：長窗口定嚴重度、短窗口確認仍在燒；並替低流量服務另做處理。
No notes yet — jot your takeaways or Q&A here.