實戰：SRE 儀表板

Vibe Prompt

「幫我在 Grafana 建立 SRE 儀表板：SLO 達成率、錯誤預算消耗、P95 延遲、Incident 數量。」

SRE 儀表板 Panels

# SLO 達成率（過去 30 天）
(
  sum(rate(http_requests_total{status!~"5.."}[30d]))
  /
  sum(rate(http_requests_total[30d]))
) * 100

# 錯誤預算消耗
(
  1 - (
    sum(rate(http_requests_total{status!~"5.."}[30d]))
    /
    sum(rate(http_requests_total[30d]))
  )
) * 43200  # 99.9% SLO 的每月錯誤預算秒數

# P95 延遲趨勢
histogram_quantile(0.95,
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
)

課程總結

SRE 課程完成！

• ✅ SLI / SLO / 錯誤預算
• ✅ Incident Response
• ✅ 容量規劃
• ✅ Chaos Engineering
• ✅ SRE 儀表板

---

關鍵要點

• ✅ SRE Dashboard 結合 SLI、SLO、錯誤預算於單一檢視
• ✅ 燃盡圖 (Burn Rate) 顯示錯誤預算消耗速度
• ✅ 多視窗率 (Multi-Window, Multi-Burn-Rate) 告警避免誤報
• ✅ 儀表板應分層：Executive View → Team View → Individual View
• ✅ On-Call 儀表板只顯示「需要立即處理」的資訊

告警分層

| 層級 | 通知方式 | 回應時間 | 範例 | |:----:|:--------:|:--------:|------| | P0 | 電話 + Slack | 5 分鐘 | 服務完全中斷 | | P1 | Slack @channel | 15 分鐘 | p99 延遲 > 1s | | P2 | Slack 訊息 | 4 小時 | 磁碟使用率 > 80% | | P3 | Jira Ticket | 下個 Sprint | 可加入快取改善延遲 |

多視窗率告警

# 5 分鐘視窗（快速偵測）
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
> 0.01  # 1% 錯誤率 → P0 告警

# 1 小時視窗（確認持續性）
sum(rate(http_requests_total{status=~"5.."}[1h]))
/
sum(rate(http_requests_total[1h]))
> 0.005  # 0.5% 錯誤率 → P1 告警

課程總結

你完成了 SRE 的五堂課程！

| 章節 | 核心技能 | |------|---------| | 1️⃣ SLO & SLI | 定義與測量服務可靠性 | | 2️⃣ 事故響應 | SEV 分級、事後覆盤文化 | | 3️⃣ 容量規劃 | 預測成長與資源配置 | | 4️⃣ Chaos Engineering | 受控實驗找出系統弱點 | | 5️⃣ SRE Dashboard | 錯誤預算與多層告警 |

SRE 儀表板：服務健康度一目瞭然

Grafana 把 SLO、Error Budget、事件狀態整合在同一個畫面。

必要元件

| 元件 | 資料源 | |:----|:------| | SLO 達成率 | Prometheus | | Error Budget 使用量 | Prometheus | | 服務延遲 p50/p95/p99 | Prometheus | | 錯誤率 | Prometheus |

課程總結

這堂 SRE 課從 SLO/SLI、事件管理、容量規劃、混沌工程到儀表板——你可以為任何服務建立完整維運體系。

打造完整的 SRE 觀測平台

How：怎麼設計 SRE 儀表板？

SRE 儀表板不是把所有圖表都丟上去就好——它需要針對不同的觀眾設計不同的視角。

三層儀表板架構

Google SRE 建議將儀表板分為三個層級：

Executive View（給主管看的）
  ├─ 目前 SLO 達成率（99.9% ✅ 或 99.5% ❌）
  ├─ 本月 Error Budget 使用量（43%／100%）
  ├─ 重大事件數量（本月 3 個 SEV-1）
  └─ 一句話總結：服務健康度綠燈/黃燈/紅燈

Team View（給團隊看的）
  ├─ 所有服務的 SLO 儀表板
  ├─ Error Budget 燃盡圖
  ├─ 服務延遲趨勢（p50/p95/p99）
  ├─ 錯誤率趨勢（5xx 比例）
  └─ 容量使用率（CPU、記憶體、磁碟）

Individual View（給值班工程師看的）
  ├─ 當前的告警列表（只顯示需要處理的）
  ├─ On-Call 輪值表
  └─ 快速連結：Runbook、Log 查詢、追蹤系統

關鍵的 PromQL 查詢

# SLO 達成率（過去 30 天的可用性）
(
  sum(rate(http_requests_total{status!~"5.."}[30d]))
  /
  sum(rate(http_requests_total[30d]))
) * 100

# Error Budget 剩餘量（秒）
(
  1 - (
    sum(rate(http_requests_total{status!~"5.."}[30d]))
    /
    sum(rate(http_requests_total[30d]))
  )
) * 2592000  # 30 天的總秒數

# 多視窗率告警（5 分鐘視窗快速偵測）
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
> 0.01  # 1% 錯誤率

多視窗率告警（Multi-Window, Multi-Burn-Rate）

這是最先進的 SRE 告警策略——同時使用短視窗和長視窗來避免誤報：

| 視窗 | 閾值 | 用途 | |:----|:----|:----| | 5 分鐘 | 錯誤率 > 1% | 快速偵測突發問題 | | 1 小時 | 錯誤率 > 0.5% | 確認問題是否持續 | | 6 小時 | 錯誤率 > 0.2% | 發現緩慢累積的問題 |

只有短視窗和長視窗同時觸發時才發送告警，大幅降低誤報率。

Why：為什麼需要好的儀表板？

沒有儀表板的問題：

• 服務出問題時，工程師要打開 5 個不同工具才能知道發生什麼事
• 主管問「系統穩不穩定？」你只能回答「應該還好吧」
• On-Call 工程師被 50 個告警轟炸，分不清哪些是緊急的

好的儀表板的好處：

• 問題發生時 30 秒內就能判斷影響範圍
• 主管一眼就知道服務的健康狀態
• On-Call 工程師只需要處理儀表板上「紅色」的東西

What：SRE 儀表板該包含的元件

| 元件 | 資料源 | 為什麼重要 | |:----|:------|:---------| | SLO 達成率 | Prometheus | 服務是否達到可靠性目標 | | Error Budget 燃盡圖 | Prometheus | 錯誤預算消耗速度是否正常 | | 服務延遲（p50/p95/p99） | Prometheus | 用戶體驗的核心指標 | | 錯誤率 | Prometheus | 服務是否正在出錯 | | 容量使用率 | Prometheus | 是否需要擴容 | | 事件時間線 | PagerDuty | 最近發生了什麼事件 |

課程總結

這堂 SRE 課程你從 SLO/SLI 的定義、Error Budget 的運作、Incident Response 的標準流程、容量規劃的預測方法、混沌工程的故障注入到 SRE 儀表板的設計——你現在可以為任何服務建立完整的 SRE 維運體系。

這不是理論——Google、Netflix、Amazon 每天都在用這些方法來確保服務的穩定性。你現在學會了跟世界頂尖公司一樣的維運思維。