ランブックは、特定の症状や定型作業に対して、影響確認、安全な調査、一次対応、復旧確認、エスカレーションを順に実行する運用手順書です。 結論は、コマンド集ではなく「いつ使い、何を見て、どの条件で止めるか」まで書くことです。
なぜ必要か
障害時は時間圧力があり、担当者の記憶だけでは確認漏れや危険操作が起きます。手順を平常時に検証しておけば、初めて当番に入る人も安全な初動を取り、専門担当へ同じ情報を渡せます。ランブックは調査を完全自動化するものではなく、既知の症状に対する再現可能な入口です。
良いランブックは、正常・異常・中止の条件を読み手が判定できます。
登場人物と対象
一次対応者、インシデントコマンダー、サービス所有者、DB・ネットワーク・セキュリティなどの専門担当が関わります。対象はアラート、ダッシュボード、ログ、依存サービス、設定、復旧操作、連絡経路です。個人名だけでなく当番やチームの窓口を書きます。
作成の流れ
- 対象アラート・症状と対象外を定義する。
- 利用者影響と緊急度の確認方法を書く。
- 読み取り専用の調査を安全な順に並べる。
- 一次対応ごとに前提、影響、承認、戻し方を書く。
- 復旧条件と監視継続を定義する。
- エスカレーションに必要な情報をまとめる。
- 検証環境や訓練で実行し、所有者と更新日を残す。
構成
対象アラート・症状:
想定される利用者影響:
最初に見るダッシュボード:
安全な確認コマンド:
一次対応:
実行前に承認が必要な操作:
復旧確認:
連絡先・エスカレーション:
関連する過去事例:
最終確認日:
コマンドだけを書かない
各操作に「何を確認するか」「正常なら何が出るか」「失敗時に次へ進んでよいか」を書きます。
手順パターンの比較
| 種類 | 例 | 必須条件 |
|---|---|---|
| 観測 | メトリクス・ログ確認 | 読み取り対象と時間範囲 |
| 診断 | ヘルスチェック | 正常・異常の判定 |
| 緩和 | 機能停止・流量制限 | 影響と解除条件 |
| 復旧 | ロールバック・再処理 | 承認と戻し方 |
| 連絡 | エスカレーション | 伝える情報と期限 |
確認から始め、変更系操作は後へ置きます。 いきなり再起動すると、原因を示すメモリ上の状態やログを失う場合があります。
危険な操作
削除、再起動、権限変更、DB更新には対象環境、影響、戻し方、承認者を明記します。秘密値を文書へ直接載せません。
コマンド例にはプレースホルダーを使い、対象環境を確認するコマンドを先に置きます。ただし、プレースホルダーの置換漏れが危険なら、専用ツールや自動化を検討します。不可逆操作はランブックだけを根拠に実行せず、組織の承認手順に従います。
よくある誤解
すべての障害を一冊へまとめると検索しにくくなります。症状やアラート単位に分け、共通手順へリンクします。「詳しい人なら分かる」省略は、深夜や交代時に機能しません。一方、判断をなくすほど固定化すると未知の障害へ誤適用されます。適用条件と中止条件を明示します。
注意とベストプラクティス
- 秘密値・個人情報を本文や実行例へ載せない。
- コマンドの権限、副作用、対象環境を記す。
- ダッシュボードや画面名の変更に合わせて更新する。
- 過去インシデントと関連付ける。
- 定期的に机上訓練または検証環境で試す。
デバッグ・確認方法
対象サービスに詳しくない人が、検証環境で手順を読み上げながら実行します。リンク切れ、権限不足、コマンドの終了条件、期待出力を確認します。本番でしか確認できない箇所は、読み取り専用の代替やスクリーンショットではなく最新画面へのリンクを用意します。
実践演習：アラート一件から作る
検証用アラートを一件選び、アラート名を知らない当番でも利用者影響を説明できるようにします。最初に開くダッシュボード、対象サービス、時間範囲、正常・異常の見分け方を書きます。次に読み取り専用の確認だけで、依存先か自サービスかを分ける手順を用意します。
一次対応を一つ加える場合は、実行条件、対象環境、必要権限、予想される影響、中止条件、元へ戻す操作を埋めます。どれか不明なら自動実行できる手順として扱いません。専門担当へ渡す時に必要なタイムライン、ログ参照先、既に試した操作もテンプレート化します。
訓練後は所要時間より、迷った分岐、権限不足、古いリンク、判定できない出力を修正します。実行されなかった手順も、不要なのか適用条件が曖昧なのかを確認します。
ランブックを保守する
各ランブックに所有チーム、最終検証日、対象サービス・アラート、想定読者を付けます。組織に有効期限の規則がある場合はそれに従い、期限だけ機械的に更新せず実際に手順を確認します。サービス廃止時は検索結果に古い手順が残らないよう、廃止表示と後継先を示します。
インシデント後は、手順どおり進めなかった箇所を確認します。担当者のミスと決めず、観測が不足していた、権限申請が間に合わなかった、コマンドの出力が変わったなど仕組みの問題へ分解します。頻繁で安全な操作は自動化候補ですが、自動化にも権限、監査、停止条件が必要です。
複数サービスで共通する確認を共有ランブックへ切り出す場合、サービス固有の前提まで抽象化しないようにします。入口側には、どの共通手順をどの値で使うかを残します。
更新をPull Requestで行う場合は、手順変更の理由、検証した環境、旧手順を使えなくなる時期を説明します。レビュー担当は文章だけでなく、安全な検証環境で期待結果まで実際に確認し、記録も残します。
ケーススタディ：決済完了の反映遅延アラート
「決済は成功したが受講状態へ反映されない」というアラートのランブックを作ります。利用者は支払い済みなのに教材を開けず、再決済すると二重請求につながるため、単なる表示遅延より優先度が高い症状です。適用条件は、決済事業者の成功通知があり、一定時間後も受講状態が未更新であることです。決済自体が失敗したケースや管理者が取消したケースは対象外にします。
判断は、影響件数、発生開始時刻、処理待ち行列、通知受信、反映処理の順に進めます。最初に個別データを書き換えると、全体障害を隠し、後から自動処理と競合するおそれがあります。まず読み取り専用の画面で、直近の成功決済数と反映済み数の差を確認します。差がなく単一利用者だけなら個別調査へ、差が増え続けるなら全体障害としてエスカレーションします。
良い手順は「滞留件数が平常範囲を超え、最古メッセージが十分以上前なら、処理担当へ開始時刻、件数、関連変更を連絡する」のように観測と行動が結び付きます。悪い手順は「キューを確認し、必要なら再起動する」です。何件なら必要か、再起動で処理中データがどうなるか、誰の承認が要るかが分かりません。
再処理を許す場合は、同じ決済識別子を二度処理しても二重登録されないことが前提です。その保証を確認できない、対象件数を取得できない、外部状態と内部状態が食い違う場合は手順を止め、決済担当へ渡します。本文に利用者名、カード情報、秘密鍵を貼らず、調査用識別子と権限制御された記録を使います。
復旧はアラートが消えただけでは判断しません。新規決済が通常時間内に反映され、滞留件数が減り、失敗率が基準へ戻り、影響件数と再処理件数が一致したことを観測します。数字が一致しなければ見かけ上の復旧として終了せず、未処理対象を明示して引き継ぎます。
訓練では新人へ手順を渡し、どこで質問が止まるか記録します。迷った箇所は能力不足ではなく、前提、判定値、権限、期待結果の不足候補です。所要時間、誤操作、エスカレーションまでに集められた情報を観測すると、感想ではなく事実で改善できます。
まとめ
ランブックは、対象症状、影響、安全な観測、一次対応、復旧条件、エスカレーションを判断可能な順で結ぶ文書です。 危険操作には承認と戻し方を付け、平常時に第三者が試して更新します。
参考リソース
実際に試す
障害時に初めて読むのではなく、検証環境で手順を実行します。古い画面名、権限不足、存在しないコマンドを見つけたら更新します。
