LESSON 30分

ストーリー

田
田中VPoE
データの収集・保存・分析の基盤が設計できた。最後は「可視化」だ。どんなに優れたデータがあっても、人に伝わらなければ意味がない
あなた
ダッシュボードをたくさん作ればいいですか？
あ
田
田中VPoE
たくさん作ることが目的ではない。実際に多くの組織で「ダッシュボードの墓場」が発生している。誰も見ないダッシュボードが数百枚存在する状態だ。重要なのは「誰が」「何のために」「いつ」見るダッシュボードかを設計することだ
あなた
ペルソナ別に設計するということですか
あ
田
田中VPoE
その通りだ。経営層、マネージャー、SRE、開発者。それぞれ必要な情報粒度が異なる。4つの層でダッシュボード体系を設計する

ダッシュボード階層設計

4層のダッシュボード体系

┌─────────────────────────────────────────────┐
│ Layer 1: ビジネスダッシュボード               │
│ 対象: 経営層・プロダクトマネージャー           │
│ 更新頻度: リアルタイム〜日次                   │
│ KPI: ビジネスメトリクス、SLA達成状況           │
├─────────────────────────────────────────────┤
│ Layer 2: サービスダッシュボード               │
│ 対象: チームリード・マネージャー               │
│ 更新頻度: リアルタイム                        │
│ KPI: SLI/SLO、エラーバジェット、サービス健全性 │
├─────────────────────────────────────────────┤
│ Layer 3: オペレーションダッシュボード          │
│ 対象: SRE・オンコール担当者                   │
│ 更新頻度: リアルタイム（秒単位）               │
│ KPI: REDメトリクス、インフラリソース、アラート  │
├─────────────────────────────────────────────┤
│ Layer 4: 探索ダッシュボード                   │
│ 対象: 開発者・SRE（調査時）                   │
│ 更新頻度: アドホック                          │
│ KPI: トレース詳細、ログ検索、メトリクス深掘り   │
└─────────────────────────────────────────────┘

Layer 1: ビジネスダッシュボード

設計原則

原則説明
シンプルさ1画面で全体像が把握できる
ビジネス言語技術用語ではなくビジネス言語で表現
トレンド重視瞬間値より推移・傾向を重視
アクショナブル見て判断・行動に繋がる情報のみ

推奨パネル構成

パネルメトリクス表示形式
システム全体の健全性SLA達成率、全体エラーレート信号機（緑/黄/赤）
ユーザー体験ページロード時間、API応答時間（P50/P99）時系列グラフ
ビジネスKPIアクティブユーザー数、トランザクション数数値 + トレンド
インシデントサマリー現在のインシデント数、今月のMTTRステータス表示
コスト概要月間インフラコスト、可観測性ツールコスト棒グラフ + 予算比

Layer 2: サービスダッシュボード

REDメソッドに基づく設計

メトリクス定義可視化
Rate（レート）リクエスト/秒時系列グラフ
Errors（エラー）エラーレート（%）時系列 + SLO閾値ライン
Duration（所要時間）レイテンシ（P50, P90, P99）ヒートマップまたは時系列

サービス別ダッシュボードテンプレート

┌──────────────────────────────────────────────┐
│ [サービス名] ダッシュボード                     │
├──────────────┬───────────────┬───────────────┤
│ SLO状態       │ エラーバジェット │ 直近アラート  │
│ ○ 99.95%     │ ████░░ 62%残 │ 0件           │
├──────────────┴───────────────┴───────────────┤
│ リクエストレート    [時系列グラフ]              │
├──────────────────────────────────────────────┤
│ エラーレート        [時系列 + SLO閾値ライン]    │
├──────────────────────────────────────────────┤
│ レイテンシ          [P50/P90/P99 ヒートマップ]  │
├──────────────────────────────────────────────┤
│ 依存サービス状態    [サービスマップ]             │
├──────────────────────────────────────────────┤
│ 最近のデプロイ      [デプロイマーカー]           │
└──────────────────────────────────────────────┘

Layer 3: オペレーションダッシュボード

USEメソッドに基づくインフラ可視化

メトリクス対象リソースアラート閾値
Utilization（使用率）CPU、メモリ、ディスク、ネットワーク80%超で警告
Saturation（飽和度）キュー深度、コネクションプール、スレッドプール容量の90%で警告
Errors（エラー）ハードウェアエラー、ネットワークエラー発生で警告

オンコール向けダッシュボード設計

要素設計指針
アラートパネル現在のアクティブアラートを重大度順に表示
サービスマップサービス間の依存関係と各サービスの状態を可視化
変更履歴直近のデプロイ、設定変更、インフラ変更を時系列で表示
比較ビュー現在と1日前/1週間前の同時間帯を並べて比較

Layer 4: 探索ダッシュボード

アドホック分析のための設計

機能目的ツール例
ログ検索キーワード、フィルタ、正規表現によるログの探索Grafana Explore, Kibana
トレース検索サービス、期間、ステータスによるトレースの検索Jaeger UI, Tempo
メトリクスクエリPromQLやLogQLによる柔軟なクエリ実行Grafana Explore
相関ジャンプメトリクス→トレース→ログへのシームレスな遷移統合ツールの相関機能

ダッシュボード運用のベストプラクティス

ダッシュボードライフサイクル管理

フェーズアクション
作成テンプレートベースで作成、命名規則に従う
レビューチーム内でレビュー、冗長パネルの排除
利用オンコールローテーションでの実用テスト
更新サービス変更に合わせたパネルの追加・修正
棚卸し四半期ごとに未使用ダッシュボードの特定と削除

命名規則

命名規則: [層]-[チーム/サービス]-[目的]

例:
  L1-Company-Business-Overview
  L2-Payment-Service-SLO
  L3-Infrastructure-Kubernetes
  L4-API-Debug-Latency

アンチパターン

アンチパターン問題対策
ダッシュボードの墓場誰も見ない大量のダッシュボード定期的な棚卸しと利用状況の追跡
情報過多1画面に50以上のパネルが並ぶ1画面あたりのパネル数を10-15に制限
コンテキスト不足数値だけ表示されて意味が分からない閾値ライン、アノテーション、説明の追加
個人ダッシュボード乱立同じ情報の個人ダッシュボードが多数存在チーム標準ダッシュボードの整備

「最高のダッシュボードとは”見なくてもいい”ダッシュボードだ。異常時だけ自分に気づかせてくれる。それが成熟した可観測性の姿だ」 — 田中VPoE

まとめ

ポイント内容
4層設計ビジネス、サービス、オペレーション、探索の4層でペルソナ別に設計
メソッドREDメソッド（サービス）、USEメソッド（インフラ）を活用
テンプレート標準テンプレートの整備で品質と効率を両立
運用命名規則、ライフサイクル管理、定期的な棚卸し

チェックリスト

  • 4層のダッシュボード体系を理解した
  • REDメソッドとUSEメソッドの適用を理解した
  • ダッシュボードのアンチパターンを理解した
  • 命名規則とライフサイクル管理を理解した

次のステップへ

次は演習です。ここまで学んだプラットフォームアーキテクチャ、データ収集、ストレージ、可視化を統合して、統合可観測性プラットフォームを設計しましょう。

推定読了時間: 30分