sre-dashboards について
sre-dashboardsは、SREやサービスチーム向けの信頼性ダッシュボード設計スキルです。SLOの概要からサービスの健全性、エンドポイント診断までを階層化します。
主な機能
- 01階層型の信頼性ダッシュボード構成
- 02ゴールデンシグナルとSLOパネル
- 03デプロイと依存関係の相関表示
- 04PromQL例と運用ガイド
活用シーン
- 01SLO達成率とエラーバジェット消費の追跡
- 02サービスビューを使った本番インシデントの調査
- 03チーム間でのダッシュボードパターンの統一
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ bagelhole/ devops-security-agent-skills --skill sre-dashboardsインストール後、Claude Code で/sre-dashboardsを入力して読み込まれたか確認します。
詳細
SRE ダッシュボード
チームが信頼性インシデントを検知、トリアージ、防止するのに役立つダッシュボードを構築します。
このスキルを使用するタイミング
次の場合にこのスキルを使用します。
- 本番システムのサービスレベルダッシュボードを定義するとき
- SLO の健全性とエラーバジェットの消費状況を追跡するとき
- インシデント対応の司令センター用ビューを作成するとき
- チーム間でダッシュボードのパターンを標準化するとき
前提条件
- メトリクスパイプライン(Prometheus、OpenTelemetry、またはベンダー相当のもの)
- サービスと環境に関連付けられたログ/トレース
- 合意済みのサービス分類体系(チーム、サービス、ティア、環境)
ダッシュボードのアーキテクチャ
ダッシュボードを次のレイヤーに分けて構成します。
- 経営層向け信頼性ビュー:SLO 達成状況、インシデント件数、MTTR の推移。
- サービス健全性ビュー:RED/USE メトリクス、依存関係の健全性、リリースマーカー。
- 詳細分析ビュー:エンドポイントごとのレイテンシ、リソースの飽和度、エラーのカテゴリ。
各ビューは、質問への回答を重視します。
- 顧客に影響が出ていますか?
- 何が変わりましたか?
- ボトルネックはどこですか?
SRE の主要パネル
ゴールデンシグナル
- レイテンシ:エンドポイントごとの p50/p95/p99 リクエスト所要時間
- トラフィック:リクエストのスループットとキューの深さ
- エラー:5xx 率、ジョブの失敗数、タイムアウト比率
- 飽和度:CPU、メモリ、ディスク I/O、スレッド/接続プールの枯渇
SLO パネル
- 現在の SLI 値(ローリングウィンドウ:5m、1h、24h、30d)
- エラーバジェットの残量(%)
- バーンレートパネル(短期および長期ウィンドウ)
- マルチウィンドウのバーンアラートステータス
変更との相関
- デプロイマーカーと設定変更の注釈
- フィーチャーフラグの状態オーバーレイ
- 上流/下流の依存関係のエラー率
PromQL の例
# API error rate (%)
100 * sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
# p95 latency by route
histogram_quantile(0.95,
sum by (le, route) (rate(http_request_duration_seconds_bucket[5m]))
)
# Fast burn rate (5m / 1h)
(
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
)
/
(
sum(rate(http_requests_total{status=~"5.."}[1h]))
/ sum(rate(http_requests_total[1h]))
)
運用ガイドライン
- 一貫した色の意味を使用します(緑=正常、黄=劣化、赤=違反)
- 単位を明記します(ms、req/s、%、コア)
- 時間範囲のデフォルト値には、インシデント対応に適した範囲を使用します(15m、1h、6h、24h)
- 認知負荷を軽減するため、ダッシュボードごとのパネル数を最小限に抑えます
- パネルの説明にランブックへのリンクを直接追加します
トラブルシューティング
パネルの表示が平坦または空になる
- ラベルのカーディナリティとフィルター(
service、env、region)を確認します - スクレイプ/取り込みのレイテンシが想定範囲内であることを確認します
- 計装の更新後にメトリクス名が変更されていないか確認します
高いカーディナリティによってダッシュボードの表示が遅くなる
- 生の ID ではなく、安定したディメンション(
service、route_group)で集約します - コストの高いパーセンタイルクエリと比率クエリにはレコーディングルールを使用します
- 詳細分析ダッシュボードと NOC の概要ダッシュボードを分けます
関連スキル
- prometheus-grafana - ダッシュボードの実装と PromQL
- opentelemetry - 標準化されたテレメトリー計装
- alerting-oncall - 信頼性アラートのルーティングとエスカレーション
- agent-observability - AI ワークロードの信頼性テレメトリー
コメント
Markdown 対応