Runbook は手順書ではなく判断の入口である – アラート、ダッシュボード、ログを対応へつなぐ

アラート通知を受けたとき、最初に必要なのは詳細な作業手順ではありません。まず、その通知が何を意味し、どの範囲に影響している可能性があり、何を見れば判断できるのかを短時間で把握できることです。

Runbook は、障害対応のすべてを自動的に解決する文書ではありません。通知を受けた人が、Prometheus のメトリクス、Grafana のダッシュボード、Loki のログ、チケット、エスカレーション先へ迷わず進むための入口です。

この記事では、Runbook を単なる手順書ではなく、アラートから初動判断へつなぐ設計として整理します。重要なのは、誰かに話しかけるような説明を増やすことではなく、判断に必要な情報の位置関係を固定することです。

Runbook は作業手順の一覧ではない

Runbook という言葉は、作業手順書の意味で使われることがあります。確かに、再起動、切り戻し、容量拡張、フェイルオーバーなど、決まった操作を記載する場面はあります。

しかし、アラート対応における Runbook の価値は、手順を並べることだけではありません。通知を受けた段階では、まだ原因も影響範囲も確定していないことが多いためです。最初に必要なのは、操作手順ではなく、判断の入口です。

Runbook に必要な要素	役割
アラートの意味	何がどの条件で検出されたのかを明確にする
影響範囲の確認	利用者影響、サービス影響、冗長性の残りを確認する
確認画面	Grafana など、最初に見るべき場所へ移動できるようにする
ログ確認	Loki やアプリケーションログで原因候補へ進む
判断基準	即時対応、様子見、エスカレーションの境界を示す
関連作業	silence、チケット、変更作業、切り戻しと接続する

Runbook が作業手順だけで構成されていると、手順に入る前の判断が個人に依存します。逆に、判断基準だけで具体的な確認先がない場合も、初動が遅くなります。Runbook は、判断と操作の間をつなぐ文書として設計する必要があります。

アラート名から対応内容を推測させない

アラート名が分かりやすければ十分だと考えると、運用は属人的になります。例えば、HighLatency、DiskFull、PodCrashLoopBackOff のような名前だけでは、どのサービスで、どの利用者影響があり、どこまで緊急なのかは判断できません。

アラート名は入口にすぎません。通知には、Runbook、ダッシュボード、ログ検索、関連サービス、責任チームへ進むための情報を含める必要があります。

通知に含めたい情報	理由
alertname	検出された異常の種類を識別する
severity	緊急度と通知経路を判断する
service	影響するサービスと責任範囲を示す
cluster / region	障害範囲を切り分ける
dashboard URL	状態確認の入口にする
Runbook URL	判断基準と対応方針へ接続する

通知本文を長くする必要はありません。重要なのは、通知だけで完結させることではなく、次に見るべき場所へ確実に進めることです。

最初に見る画面を固定する

障害対応では、最初に見る画面が人によって違うだけで判断がずれます。ある人はホストメトリクスを見て、別の人はアプリケーションログを見て、さらに別の人は Kubernetes の Pod 状態を見る。この状態では、同じアラートに対して初動の粒度が揃いません。

Runbook では、最初に見る Grafana ダッシュボード、次に確認する Prometheus のメトリクス、必要に応じて読む Loki のログを順番として定義します。画面を並べるだけではなく、何を判断するために見るのかを明記します。

確認順序	確認するもの	判断したいこと
1	サービス概要ダッシュボード	利用者影響があるか、単一箇所か広域か
2	SLI / SLO 関連メトリクス	エラー率、レイテンシ、成功率が閾値を超えているか
3	依存先メトリクス	DB、外部 API、ネットワークなどの依存先に偏りがあるか
4	Loki の関連ログ	例外、タイムアウト、認証失敗、WAF などの具体的な事象があるか
5	直近の変更履歴	デプロイ、設定変更、メンテナンスと時間が一致するか

この順序は固定的な儀式ではありません。重要なのは、利用者影響、障害範囲、原因候補へ進むための入口を決めておくことです。

Prometheus、Grafana、Loki の役割を分ける

Runbook にすべての情報を書き込もうとすると、文書はすぐに古くなります。Runbook は、監視基盤に保存されている情報の代替ではありません。どの情報をどこで見るかを示す索引として扱う方が保守しやすくなります。

情報源	Runbook での扱い
Prometheus	状態、傾向、比率、閾値超過を確認する
Grafana	確認順序に沿って状態を表示する
Loki	具体的なエラー、タイムアウト、拒否理由を読む
Alertmanager	通知、束ね方、抑制、silence の状態を確認する
チケット	対応履歴、変更履歴、承認、復旧後の記録を残す

Runbook にログの例を大量に貼る必要はありません。必要なのは、どの条件でどのログを見るのか、どのラベルやサービス名で検索するのか、正常時と異常時の差分をどう見るのかです。

判断基準を文章ではなく境界として残す

Runbook が長い説明文だけで構成されていると、対応者は結局、自分で判断を組み立てることになります。判断基準は、可能な限り境界として残すべきです。

例えば、CPU 使用率が高い、レイテンシが悪い、エラーが多いという表現だけでは対応に進めません。どの状態なら様子見でよいのか、どの状態なら一次対応が必要なのか、どこからエスカレーションするのかを分けます。

判断	基準の例	次の行動
様子見	短時間の揺れで、SLO や利用者影響に達していない	ダッシュボードを継続確認し、通知の重複を確認する
一次対応	利用者影響があり、原因候補が限定できている	Runbook の対応手順または既定の切り戻し判断へ進む
エスカレーション	影響範囲が広い、原因が不明、権限や判断責任を超える	責任チーム、オンコール、インシデント管理へ接続する
silence	計画作業または既知事象で、通知停止の期限と理由がある	対象を限定して silence を作成し、チケットへ記録する

すべてを数値で決められるわけではありません。それでも、判断の境界を残しておくことで、対応者の経験差を小さくできます。

Runbook はアラート単位だけで作らない

Runbook をアラート名ごとに一つずつ作ると、数が増えすぎて保守できなくなる場合があります。すべてのアラートに固有の Runbook が必要なわけではありません。

同じサービスのレイテンシ、エラー率、依存先タイムアウトは、一つのサービス障害 Runbook から分岐できるかもしれません。逆に、同じ DiskFull でも、ログ領域、DB 領域、オブジェクトストレージのメタデータ領域では確認先や対応責任が異なるかもしれません。

Runbook の単位	向いている場面
アラート単位	固有の確認手順や固有の危険操作がある
サービス単位	複数のアラートが同じ初動確認に集約される
障害種別単位	容量不足、証明書期限、レイテンシ悪化など横断的に扱える
基盤単位	Kubernetes、DB、ネットワーク、WAF など責任範囲で整理する

Runbook の単位は、文書管理の都合ではなく、対応者が最短で判断に入れる単位で決めます。

自動化と Runbook の境界を決める

Runbook に書かれている作業が安定していて、条件も明確で、失敗時の戻し方も決まっている場合、その一部は自動化できます。しかし、自動化できることと、自動実行してよいことは同じではありません。

Runbook は、自動化する前の設計資料にもなります。どの条件で実行するのか、どの権限が必要なのか、影響範囲はどこまでか、結果をどう確認するのかが整理されていなければ、安全な自動化にはなりません。

Runbook 上の要素	自動化前に確認すること
実行条件	誤検知や一時的な揺れで実行されないか
操作対象	サービス、クラスタ、ホスト、Pod の範囲が限定されているか
権限	実行主体に必要以上の権限を与えていないか
ロールバック	失敗時に戻せるか、戻せない変更を含まないか
監査	誰が、いつ、どの条件で実行したかを残せるか

Runbook は人間のためだけの文書ではありません。将来、自動化や AI に判断を委ねる範囲を決めるためにも、判断条件と操作条件を分けて残しておく必要があります。

更新されない Runbook は負債になる

Runbook は一度作って終わりではありません。サービス構成、メトリクス名、Grafana の URL、ログラベル、オンコール体制、チーム名、エスカレーション先は変わります。更新されない Runbook は、ない場合より危険になることがあります。

Runbook を保守するには、障害対応後の振り返りで「Runbook は役に立ったか」を確認する必要があります。アラートは正しかったのか、最初に見る画面は適切だったのか、判断基準は曖昧ではなかったのか、リンク切れや古い手順はなかったのかを見直します。

見直し観点	確認内容
リンク	ダッシュボード、ログ検索、チケット、資料へ移動できるか
メトリクス	名前やラベルが現在の設計と一致しているか
判断基準	実際の対応で迷った点が反映されているか
責任分界	通知先、承認者、エスカレーション先が正しいか
手順	実行できない操作や古い画面説明が残っていないか

まとめ

Runbook は、アラート対応の作業手順を並べるだけの文書ではありません。通知を受けた人が、影響範囲、原因候補、確認画面、ログ、エスカレーション条件へ進むための入口です。

アラート名から対応内容を推測させず、最初に見る Grafana ダッシュボード、Prometheus のメトリクス、Loki のログ、関連チケット、判断基準を接続します。Runbook は、対応者が同じ初動に入るための情報設計です。

Runbook を整備すると、障害対応だけでなく、自動化や AI 活用の前提も整理されます。どこまでを固定手順にできるのか、どこから人間の判断が必要なのか、どの情報を根拠にするのかが明確になるためです。通知を受けたあとに何を見るのかを決めていない監視は、運用に接続されていません。

参考書籍

参考資料

• Google SRE Book: Monitoring Distributed Systems
• Google SRE Book: Being On-Call
• Prometheus: Alertmanager
• Grafana documentation: Dashboards

関連する記事