如果一個面向使用者的系統只能量四個指標，就量延遲、流量、錯誤、飽和度。這四個回答「使用者現在痛不痛」，是儀表板與症狀型告警的骨架；其餘指標多半是它們的解釋。
🧠 Intuition
TIP
四個黃金指標分別問：多慢（延遲）、多忙（流量）、多壞（錯誤）、多滿（飽和度）。前三個是使用者當下就感受得到的「症狀」，飽和度則是預測「還能撐多久」的領先指標。
- 延遲（Latency）：請求的耗時。關鍵是把成功與失敗的延遲分開算——一個快速回傳的 500 會拉低平均延遲，製造「很快」的假象，但「慢的失敗」其實比「快的失敗」更傷。
- 流量（Traffic）：系統承受的需求量。Web 服務看 QPS、串流看網路 I/O 或並發連線、K/V 儲存看每秒交易數。
- 錯誤（Errors）：失敗請求的比率。分三種：明示（HTTP 500）、暗示（回 200 但內容錯）、政策性（回應超過合約延遲就算錯）。負載均衡器抓得到 500，但「回了錯內容」要靠端到端測試才驗得出。
- 飽和度（Saturation）：服務離「滿」有多近，對最受限的資源（記憶體、I/O、CPU）量。多數系統在達 100% 前就開始退化，所以要訂一個「目標利用率」而非等到爆掉；高百分位延遲通常是飽和度的領先訊號。
⚖️ Tradeoffs
用平均值看延遲 — 會被長尾（tail）騙
- 平均 100 ms 的服務裡，1% 的請求可能慢到 5 秒；聚合成平均後，這條長尾直接消失。
- 使用者若要串接多個後端，某個後端的 99th 百分位常常就是前端的中位數——長尾會沿著呼叫鏈放大。
- 正解：把請求依延遲分桶做直方圖（histogram），桶邊界近似指數成長（0–10、10–30、30–100 ms…），直接看分佈與高百分位，而不是單一平均。
白箱 vs. 黑箱 — 兩種視角要並存
- 黑箱（從使用者角度探測外部行為）是症狀導向，回答「服務現在真的壞了」——最適合用來 page（呼叫人類），強制紀律「真的影響使用者才叫醒人」。
- 白箱（讀系統內部曝露的指標）能看到「即將發生、被重試掩蓋、或細微」的健康變化，是黑箱看不到的。
- 缺一不可：只有黑箱，分不出「DB 真的慢」還是「網路出問題」；只有白箱，看不到「根本沒進到伺服器的請求」（DNS 失敗、整台掛掉）。
🔑 Takeaways
- 四個黃金指標＝延遲、流量、錯誤、飽和度，是面向使用者服務的儀表板與症狀型告警的最小充分集。
- 延遲要分開成功與失敗、錯誤要涵蓋明示/暗示/政策三類、飽和度對最受限資源量並訂目標利用率。
- 別用平均值——用直方圖看分佈與高百分位，才不會被長尾騙；白箱與黑箱兩種視角要並存。
No notes yet — jot your takeaways or Q&A here.