SLO運用で差がつく可観測性ダッシュボードの作り方
目次
夜間リリースでレスポンスが2秒台に落ち、経営陣に「どこで遅れているの？」と問われたとき、メトリクスもトレースも足りずに口ごもった経験があります。その後、SLO設計と可観測性ダッシュボードを作り直した結果、同じ質問に30秒で答えられ、オンコールの判断も劇的に速くなりました。この記事は、「SLO ダッシュボード 作り方」「エラーバジェット 運用」「OpenTelemetry 導入 手順」を探している人向けに、実務で評価された最小セットと進め方をまとめます。
なぜ今、SLO設計と可観測性スキルが刺さるのか
- 生成AIやモバイルフロントの複雑化で「レスポンス悪化の犯人探し」が増加。SLOとトレースがあるだけで調査時間が1/3になる。
- SRE採用では「SLOを決め、エラーバジェットで運用を調整した経験」が定番の深掘り質問。具体例を語れる候補者がまだ少ない。
- FinOps文脈でも、SLO未達の原因がリソース不足か設計ミスかを数字で示せる人が重宝される。
まず決めるSLO/SLI（数字を先に置く）
- サービスとユーザ行動を1つ選ぶ: 例) Web APIの
/orders。リクエスト/秒が安定している時間帯を基準にする。 - SLIを計測方法まで言語化
- 可用性: 「2xx/3xxの割合をCloudWatch Logs Insightsで5分ウィンドウ計測」
- レイテンシ: 「p95レスポンス<=250ms（ALBのTargetResponseTime）」
- エラーバジェット: 「月間稼働時間43,200分のうち許容障害5分」
- SLOを暫定で決める: 可用性99.9%、p95 250ms、エラーバジェット5分など「今の能力で届きそうな線」を宣言。理想値から始めない。
- ダッシュボードに“現在の達成率”を最初に置く: SLOカードを一番上に固定し、チーム全員の目に触れる場所にする。
ポイント: SLOは「守れたか/破ったか」を決める線引き。曖昧なままダッシュボードを作ると、後で全差し替えになる。
計測の最小構成（ベンダー非依存で組む）
- トレース: アプリにOpenTelemetry SDKを仕込み、OTLPでCollectorへ送る。Collectorはメトリクスを生成し、エクスポート先（CloudWatch/Prometheus/Grafanaいずれか）に流す。
- メトリクス: レイテンシ（p50/p95/p99）、エラー率、リクエスト数、依存サービス別の外形監視（HTTP 200率）。
- ログ: 構造化ログで
trace_idを付与し、トレースと突合できる状態にする。 - コスト意識: トレースのサンプリング率をまず10%にし、SLO付近のルートだけ100%に切り替える仕組みを用意する。
セットアップの順番は「トレース → メトリクス → アラート」。エラーバジェット計算はメトリクスが揃ってからで十分です。
ダッシュボードのレイアウト（テンプレ）
- SLOカード: 可用性・レイテンシの達成率とエラーバジェット残量。週/日次切り替えを用意。
- エンドポイント別p95: 上位リクエストのp95推移。デプロイ時刻のマーカーを表示。
- 依存サービスの健全性: DB接続遅延、外部APIのエラー率、キュー滞留数。
- ユーザ影響度: 地域・デバイス別の失敗率。モバイルで先に崩れるケースを拾う。
- リリース関連: 直近デプロイのリストとロールバック可否、
feature flagの状態。 - 原価ヒント: リクエスト単価の簡易グラフ（例: Lambda GB-sec/リクエスト）。性能改善とコストをセットで議論できる。
ヒント: グラフは「原因の探り方」に合わせて並べる。上から「影響範囲 → 症状 → 原因候補」の順に置くと、オンコール時に迷わない。
アラートとRunbookをセットで用意する
- 閾値: 「p95 400ms以上が5分続く」「エラーバジェット消費が1時間で30%以上」の2軸。短期スパイクと長期悪化を分けて通知。
- 通知先の優先度: まずオンコールチャンネル、次に開発チャンネル。経営陣向け通知は週次レポートに限定し、ノイズを避ける。
- Runbookの最小項目
- 何が起きたときに実行する手順か
- 一時緩和策（例: フィーチャーフラグOFF、キャッシュTTL延長）
- 恒久対応の候補と担当
- エラーバジェット残量をどう扱うか（新機能リリース凍結 / 継続）
RunbookはMarkdownでリポジトリに置き、ダッシュボードからリンクしておくと属人化を防げます。
30日で形にするロードマップ（週6〜8時間想定）
- Day1-7: 主要エンドポイントを1つ選び、SLI計測式と暫定SLOを決める。OpenTelemetry CollectorをPoC環境に置き、p95/エラー率を可視化。
- Day8-15: ダッシュボードのSLOカードとエンドポイント別p95を作成。アラート（短期スパイク・長期悪化）を2本だけ設定し、Runbook初版を書く。
- Day16-23: 依存サービスのメトリクスを追加し、外形監視を1本入れる。デプロイ時刻マーカーを自動反映。
- Day24-30: エラーバジェット残量と週次レポートをチームに共有。振り返りでSLO値を見直し、サンプリング率やログ量を調整。
ポートフォリオに残すと評価されるアウトプット
- GitHubリポジトリに SLO定義（YAMLでもMarkdownでも可）とRunbook をセットで置く。
- ダッシュボードのスクリーンショットと、改善前後のp95/エラー率・MTTRの比較グラフ。
- 「エラーバジェットを使い切った後にリリースを止めた／続行した」判断の記録。意思決定の筋道を示すと面接で強い。
- オンコールのふりかえりを1本書き、どこで可観測性が効いたかを数字で説明する。
次の一手
- 直近のサービスで SLI計測式を1つ書き出す（レスポンスか可用性どちらかでOK）。
- OpenTelemetry Collectorをローカルか検証環境に立て、p95/エラー率を可視化する。
- SLOカードとアラートを2本作り、Runbookをリンクする。
- 週次レポートでエラーバジェット残量を共有し、開発優先度の会話に混ぜる。
- コスト影響も議論したい人は FinOps実務で評価されるクラウドコスト最適化スキル完全ガイド を続けてどうぞ。
可観測性は「豪華なツール」より「決めたSLOに沿って見える化し、チームで運用する」ことが肝心です。小さく始めて、エラーバジェットとRunbookをセットで回し始めるだけで、オンコールの質と説得力が変わります。