🎯 什麼情境該想到我
分工：《DevOps 手冊》的遙測章節已經展開成型錄 → 五層遙測覆蓋、日誌分級、均值與標準差告警、非高斯資料的異常偵測、從事故回推告警、資安遙測。這張補書中沒有的兩件事：要量什麼（黃金訊號）和什麼時候該叫醒人（SLO 與燃燒率告警）。
當你「總是等使用者回報才知道出事」、上線後對系統健康一無所知時。這是三步工作法第二步（回饋）的核心。
⚙️ 怎麼用
- 到處埋遙測：在應用、基礎設施、業務層都產生指標、日誌、追蹤（三大支柱）。
- 監控要涵蓋業務指標，不只 CPU/記憶體——「訂單成功率」比「機器負載」更早反映問題。
- 建立告警：針對關鍵指標設閾值/異常偵測，讓問題主動找上你。
- 讓資訊人人可見：儀表板公開，部署、事件都上牆，形成快速回饋迴路。
- 用資料做決策（A/B、假說驗證），而非靠猜。
★ 要量什麼：三套常用的指標框架
| 框架 | 指標 | 適合 |
|---|---|---|
| 四個黃金訊號（Google SRE） | 延遲、流量、錯誤、飽和度 | 任何對外服務 |
| RED | Rate（請求率）、Errors（錯誤率）、Duration（耗時分布） | 請求驅動的服務（API、微服務） |
| USE（Brendan Gregg） | Utilization（使用率）、Saturation（飽和度／排隊）、Errors | 資源：CPU、記憶體、磁碟、連線池 |
延遲要看分布，不看平均：平均 50 ms 可能是 99% 的請求 10 ms、1% 的請求 4 秒。用 p50、p95、p99，而且成功和失敗的請求要分開算——快速失敗的錯誤會把延遲平均拉低，讓圖表看起來很好。
★ 什麼時候叫醒人：SLO 與錯誤預算
- SLI（指標）：例如「成功且在 300 ms 內完成的請求比例」。
- SLO（目標）：例如「30 天內 SLI ≥ 99.9%」。
- 錯誤預算 = 1 − SLO = 0.1%——30 天內允許千分之一的請求不好。
錯誤預算把「可靠性 vs 開發速度」變成可以量的東西：預算還很多 → 可以大膽上線；預算快用完 → 凍結風險高的變更，先處理可靠性。
★ 燃燒率告警：比「錯誤率 > X%」好的告警方式
燃燒率 = 實際錯誤率 ÷ 錯誤預算率。燃燒率 1 代表「剛好在 30 天內用完預算」；燃燒率 10 代表 3 天就用完。
Google《SRE Workbook》的建議起始值（2026-09-25 查證）：
| 條件 | 對應的燃燒率 | 動作 |
|---|---|---|
| 1 小時內消耗 2% 的預算 | 14.4 | 呼叫值班人員 |
| 6 小時內消耗 5% 的預算 | 6 | 呼叫值班人員 |
| 3 天內消耗 10% 的預算 | 1 | 開工單 |
這些數字可以自己推導：燃燒率 = 消耗的預算比例 × (SLO 週期 ÷ 視窗長度)。
- 2% × (30 天 × 24 小時 ÷ 1 小時) = 0.02 × 720 = 14.4
- 5% × (720 ÷ 6) = 0.05 × 120 = 6
- 10% × (30 天 ÷ 3 天) = 0.1 × 10 = 1
換算成錯誤率：SLO 99.9% 時，燃燒率 14.4 = 錯誤率 1.44%。
多視窗：Workbook 建議同時要求長視窗（1 小時）與短視窗（5 分鐘）都超過門檻才告警——長視窗確保問題夠嚴重，短視窗確保問題還在發生（已經恢復的事故不會繼續叫人）。
★ Go 的埋點
| 需求 | 做法 |
|---|---|
| 結構化日誌 | 標準函式庫 log/slog（Go 1.21+）：slog.Info("order created", "order_id", id, "amount", amt)，輸出 JSON 方便查詢 |
| 指標 | Prometheus 的 client_golang，或 OpenTelemetry metrics |
| 分散式追蹤 | OpenTelemetry：ctx 一路傳下去，trace ID 就跟著走——這也是為什麼 Go 的函式第一個參數是 ctx |
| 執行時期狀態 | net/http/pprof（CPU、記憶體、goroutine）；不要對外公開這個端點 |
把日誌和追蹤串起來：在日誌裡帶上 trace ID，事故時才能從一條錯誤日誌直接跳到完整的請求路徑。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意
-
告警太多＝沒有告警（狼來了）；聚焦真正可行動的訊號。
-
高基數標籤會把監控系統打垮：把
user_id、request_id當成 Prometheus 標籤，每個值都會產生一條新的時間序列。這類資訊放在日誌或追蹤裡，不要放在指標標籤。
🔗 相關工具
- 工具-部署管線與持續交付 —— 前一環，能頻繁上線的前提是出事能馬上看見
- 工具-無指責事後檢討 —— 後一環，遙測提供事實，檢討把事實變成組織的學習
- 工具-服務容錯設計 —— 互為表裡，監控負責看見異常，容錯負責在你看見之前先撐住