インシデント対応ドキュメント：その概要と、必要になる前にランブックを構築する方法

ほとんどのインシデント対応ドキュメントは、最初の重大インシデントの前ではなく、後に書かれます。

チームは本番障害との戦いに数時間を費やしたばかりです。2人のエンジニアは記憶から作業しました。1人のエンジニアは、誰も使っていないダッシュボードを参照する古いWikiページに従いました。

振り返りが行われます。誰かがアクションアイテムとして「ランブックが必要」と書きます。

3か月後、ランブックはまだ完成していません。

このガイドは反対のアプローチを取ります。有用なインシデント対応ドキュメントライブラリを構成する4つのアーティファクトを説明し、次に次の障害の前にランブックを構築する実践的な方法を順を追って説明します。

ここでの焦点はサイバーセキュリティだけではなく、運用上の信頼性です。同じ構造は、データベースフェイルオーバー、決済停止、ランサムウェアイベント、誤設定されたデプロイ、クラウドインシデントに対しても機能します。

インシデント対応ドキュメントとは何ですか？

インシデント対応ドキュメントは、システムが故障している、劣化している、または攻撃を受けているときに対応者に何をすべきかを伝える書かれたアーティファクトのセットです。

以下をカバーします：

• 操作の順序
• 役割と権限
• エスカレーションルール
• コミュニケーションステップ
• 復旧手順
• インシデント後の学習
• オーディエンスはアーティファクトによって変わります。
• オンコールエンジニアはランブックを必要とします。インシデントコマンダーはプレイブックを必要とします。リーダーシップ、監査人、法務チームはポリシーを必要とします。将来の対応者はポストモーテムを必要とします。
• ほとんどのチームは、それらすべてを1つのドキュメントとして扱うと困難に陥ります。
• それらは1つのドキュメントではありません。異なるジョブを持つ4つの異なるアーティファクトです。

ほとんどのインシデント対応ドキュメントが最初の重大インシデントの後に書かれる理由

3つの力がインシデント対応ドキュメントを「インシデント後」のタイミングウィンドウに押し込みます。

第一に、作業を事前に正当化するのは困難です。まだ故障していないシステムのためにランブックを書くことは、特にエンジニアリングのバックログが収益を生む機能で満たされているとき、オーバーヘッドのように感じます。ランブックのコストは具体的です（エンジニアリングの時間）。利益は仮説的です（今四半期に発生しないかもしれない障害からの迅速な復旧）。

第二に、作業を割り当てるのは困難です。SREはそれがサービスオーナーに属すると言います。サービスオーナーはそれがSREに属すると言います。両方が部分的に正しく、それは通常2つの間に落ち、どちらにも完了されません。

第三に、作業を最新の状態に保つのは困難です。3月に著作されたランブックは、基礎となるコンソール、アラート名、依存関係がすべて移動しているため、9月には半分古くなっています。チームがランブックを書き、ランブックが古くなり、次のインシデントが発生し、ランブックが間違っており、チームは「ランブックは役に立たない」と結論付けます。その結論は間違っていますが、障害モードを考えると合理的です。

修正は「もっと多くのランブックを書く」ことではありません。オーサリングモデルを切り替えることです。ランブックは、インシデントの前に書くのに十分安価で、関連する変更のたびに更新するのに十分安価である必要があります。キャプチャファーストオーサリング（手順を一度記録し、UIが変更されたら再生成する）は、その経済の両半分を機能させます。

より広いカテゴリのコンテキストについては、プロセスドキュメントのベストプラクティスと、一文字も書かずにチームがワークフローをドキュメント化する方法に関する作業を参照してください。

すべてのインシデント対応ドキュメントライブラリに必要な4つのアーティファクト

機能するすべてのインシデント対応ドキュメントライブラリには、4つのアーティファクトタイプがあります。アーティファクトは異なる質問に答え、異なるオーディエンスをターゲットにし、異なる更新サイクルを持ちます。ほとんどの失敗したライブラリは、1つか2つを出荷して完了したと呼びます。

1. インシデント対応ポリシー（IRP）

IRPは高レベルのガバナンスドキュメントです。インシデントとして何を数えるか、重要度がどのように分類されるか、誰がそれらを宣言し指揮するかを定義します。また、コミュニケーション、エスカレーション、規制開示に関する組織のコミットメントを名前付けします。オーディエンスはリーダーシップ、監査人、セキュリティ態勢について尋ねる顧客、および侵害中の法務チームです。

IRPはほとんどのNISTスタイルのガイドが長く扱うアーティファクトです。また、対応者が午前2時にほとんど決して読まないアーティファクトでもあります。SOC 2、ISO 27001、およびほとんどのエンタープライズ顧客のセキュリティレビューに必要です。更新サイクル：最低年次レビュー。

2. サービスランブック（システムごとのSOP）

サービスランブックは、サービスごと、障害モードごとの手順です。一般的な例：

• 決済データベースがレプリケーション遅延を表示しているときに何をすべきか。
• CDNオリジンが503を返しているときに何をすべきか。
• 上流プロバイダーでAPIレート制限が枯渇したときに何をすべきか。

各ランブックは1つのサービスと1つまたはいくつかの関連する障害モードをカバーします。オーディエンスは呼び出されたオンコールエンジニアです。ランブックは60秒以内に読み、5分以内に実行可能である必要があります。更新サイクル：基礎となるコンソールまたはアラート名が変更されるたびに、つまり実際には少なくとも四半期ごと。

3. 重要度ティアプレイブック（クロスシステム対応フロー）

プレイブックはクロスシステム対応をカバーします。一般的な例：

• 重大インシデントの実行方法。
• 顧客データを含むセキュリティインシデントの調整方法。
• 地域クラウド障害の処理方法。

プレイブックは、インシデントコマンダーに複数のチーム間で宣言、コミュニケーション、エスカレーション、スタンドダウンする方法を伝えます。オーディエンスはインシデントコマンダーです。プレイブックは重要度別です：重大はクロスファンクショナルな調整要件が異なるため、低重要度とは異なるプレイブックを持ちます。更新サイクル：各重大事後検討の後、加えて年次の完全レビュー。

4. ポストモーテム記録（組織記憶）

ポストモーテムは、特定のインシデント中に何が起こったかの構造化された記録です：タイムライン、寄与因子、顧客への影響、アクションアイテム、所有権。オーディエンスは、同様の障害モードに遭遇する次の対応者と、長期的な修正作業を実行するエンジニアリングチームです。

ポストモーテムは、インシデントの前に決して書くことができない唯一のアーティファクトです。また、チームが後で疲れているため、最もスキップされる可能性が高いアーティファクトでもあります。更新サイクル：インシデントごとに1つ、72時間以内に書かれる。

アーティファクトのまとめ

インシデント対応ポリシーはガバナンス用です。

ランブックはオンコールエンジニア用です。

プレイブックはインシデントコマンダー用です。

ポストモーテムは将来の対応者用です。

ドキュメントがポリシーレイヤーで止まると、インシデント自体ではあまり役に立ちません。

必要になる前にランブックを構築する方法：プレインシデントプレイブック

これは記事の運用上のコアです。上記の4アーティファクト分類は、何を書くかを伝えます。以下の5つのステップは、次の重大インシデントの前に最も必要なアーティファクト（サービスランブック）を実際に完了する方法を伝えます。

ステップ1：午前2時に誰かを呼び出すことができるサービスをインベントリ化する

アラートルーティング設定から始めます。人間を呼び出すすべてのアラートはランブック候補です。PagerDuty、Opsgenie、Splunk On-Call、またはチームを呼び出すものからリストを引き出します。サービス別にクラスター化します。

ほとんどの組織は、重複がマージされると実際のリストがどれほど短いかに驚きます。50人のエンジニアSaaSチームは通常、100ではなく15から25のランブック値するサービスを持っています。

90日のページボリュームでサービスをランク付けします。上位5サービスがオンコール負荷のほとんどを占めます。それらの5つが最初にランブックを取得します。長いテールは待つことができます。

ステップ2：呼び出しではなくキャプチャでランブックを書く

呼び出しはランブックの間違ったオーサリングモデルです。手順はエンジニアの手にあり、エンジニアの頭にはありません。それをタイピングで書くのは、実行するよりも5〜10倍長くかかります。

キャプチャファーストオーサリングはこれを逆転させます。エンジニアは平穏な時間のドライランで手順を一度実行し、画面でキャプチャします。ツールは自動的にスクリーンショット付きの番号付きステップバイステップガイドを生成します。

2つの副次的な利点。キャプチャされたランブックは、エンジニアが最初にシステムを学んだときのUIではなく、現在のUIを反映します。キャプチャされたランブックは、エンジニアが無意識に取るステップも表面化します。それは、オンコールローテーションが変わったときに失われる可能性が最も高い組織知識です。

ステップ3：ほとんどのチームがスキップする退屈なランブックフィールドを含める

解決ステップのみを含むランブックは午前2時に失敗します。オンコールエンジニアは、元の著者が暗黙的に持っていたコンテキストを欠いています。ランブックには退屈なフィールドも必要です：

どのアラートに対応するか。

どの重要度を意味するか。

どの資格情報が必要か。

解決が機能しない場合にどのエスカレーションパスが適用されるか。

以下の9セクションテンプレートは完全なリストをカバーしています。

最もスキップされる単一のフィールドは「最終検証日」です。それなしでは、対応者はランブックが新鮮か古いかを判断できません。それを持って、対応者は迅速な信頼決定を下します。6週間前の検証日は信頼を獲得します。6四半期前の日付は、行動前に検証する反射を獲得します。

ステップ4：コンテキストなしのドライランでランブックをテストする

ランブックは、それを書いていない人が実行できる場合にのみ有用です。関連するサービスを一度も担当したことのないエンジニアにランブックを渡してテストします。

ランブック自体以外のコンテキストなしでエンドツーエンドで実行してもらいます。所要時間を計測します。彼らが質問しなければならなかったすべての場所をメモします。

質問はランブックのバグです。次のエンジニアをトレーニングするのではなく、ランブックで修正します。コンテキストのないエンジニアが外部の助けなしでランブックを実行できるまで再テストします。これはランブック品質の最も予測的なテストであり、ほとんどのチームがスキップするテストです。

ステップ5：ランブックをそれを発火するアラートに結び付ける

午前2時に誰も見つけることができないランブックは、存在しないランブックです。ランブックURLを直接アラートペイロードに配線します。ランブックURLフィールドをサポートする一般的なアラートツール：

PagerDuty（サービスのランブックフィールド）。

Datadogモニター。

Splunk On-Call（現在のSplunk Incident Intelligence）。

Opsgenie（アラートポリシーのランブックURL）。

アラートツールが何であれ、ランブックへのリンクは、エンジニアが検索する必要があるWikiではなく、ページ自体に表示される必要があります。

配線はフィードバックループも作成します。ランブックが欠落している場合、アラートペイロードはギャップを明確にします。ランブックが間違っている場合、対応者はどのドキュメントを更新すべきかを正確に知っています。

より広いランブックオーサリングシフトについては、AIプロセスドキュメントとITドキュメントソフトウェア、機能2のITチーム固有のフレームワークのカバレッジを参照してください。

有用なランブックテンプレート（9セクションパターン）

ライブラリ内のすべてのランブックは、同じ9セクションパターンに従う必要があります。一貫性が重要です。オンコールエンジニアは、各サービスのランブック構造を再学習する必要はありません。以下のテンプレートは、ベンダーUIの変更とチームローテーションを生き延びてきたものです。

最初の6セクションはランブックのコンテンツです。セクション7〜9は、ランブックをプレッシャーの下で使用可能にする運用メタデータです。ほとんどの失敗したランブックライブラリは、セクション7〜9を完全にスキップします。結果は、卓上演習で機能し、実際のインシデントで失敗するランブックです。

ランブックオーサリングに適用可能なより深いSOPパターンライブラリについては、UIの変更にも耐える12のSOPパターンを参照してください。

ランブックとプレイブックの違いは何ですか？

これはインシデント対応ドキュメントクラスタで最も尋ねられる質問であり、ほとんどのドキュメントライブラリの混乱の源です。正面から扱う価値があります。

ランブックはサービスごと、障害モードごとです。1人のエンジニアに、1つの特定のシステムでの1つの特定の問題を解決する方法を伝えます。オーディエンスはオンコールエンジニアです。出力は、健全な状態に戻ったシステムです。

プレイブックはクロスシステムで、重要度ごとです。インシデントコマンダーに、特定の重要度ティアのインシデント中に複数のチームを調整する方法を伝えます。オーディエンスはインシデントコマンダーです。出力は、明確な役割と明確なコミュニケーションを伴う調整された対応です。

両方のアーティファクトが必要です。ランブックを持っているがプレイブックを持っていないチームは、高い重要度でつまずきます。クロスチーム調整を担当する人を誰も知りません。プレイブックを持っているがランブックを持っていないチームは、プロセスはあるが運用上の知識はありません。

インシデント対応をドキュメント化する際の一般的なミス

5つのミスが、18か月以内に再構築されるインシデント対応ドキュメントライブラリで繰り返し現れます。

ミス1：IRPを最初に書いて、決してランブックに到達しない

IRPは主にポリシー言語であるため、最も書きやすいアーティファクトです。また、対応者が午前2時に決して読まないアーティファクトでもあります。IRPを出荷して停止するチームは、監査人に最適化され、オペレーターには役に立たないドキュメントライブラリを持っています。IRPを書き、その後同じ四半期内に上位5つのページボリュームサービスのランブックを書きます。

ミス2：ランブックとプレイブックの両方になろうとする1つのドキュメントを出荷する

結合されたドキュメントは両方のジョブで失敗します。オンコールエンジニアが60秒でスキャンできないため、ランブックには長すぎます。インシデントコマンダーが調整に使用できないため、プレイブックには浅すぎます。

ドキュメントを分割します。ランブックには上記の9セクションランブックテンプレートを使用します。クロスファンクショナルフローには別の重要度ティアプレイブック構造を使用します。

ミス3：キャプチャの代わりに呼び出しでランブックをオーサリングする

呼び出しは、現在のUIではなく、UIに対するエンジニアの記憶に一致するランブックを生成します。ランブックが書かれた時点で、スクリーンショットの半分は間違っています。キャプチャファーストオーサリング（一度記録、UIが変更されたら再生成）は、初期オーサリング時間とメンテナンス時間の両方を圧縮します。

ミス4：コンテキストなしのドライランをスキップする

元の著者が実行できるランブックは、誰でも実行できるランブックと同じではありません。元の著者は、ランブックがキャプチャしない暗黙のコンテキストを持っています。サービスの知識がないエンジニアにランブックを渡し、彼らが行き詰まる場所を見ることでテストします。次のエンジニアのトレーニングではなく、ランブックのギャップを修正します。

ミス5：ランブックをそれを発火するアラートに結び付けない

午前2時に誰も見つけることができないランブックは、存在しないランブックです。ランブックURLをアラートペイロード自体に配線します。リンクは、エンジニアが受け取るページに表示される必要があり、検索する必要があるWikiではありません。

ミス回避のまとめ

IRPの後ではなく、同じ四半期内にランブックを出荷します。

ランブックとプレイブックを分割します。異なるオーディエンスと異なるジョブを担当します。

呼び出しではなくキャプチャ。呼び出しは古いスクリーンショットを生成します。

コンテキストなしのドライランでテストします。質問はランブックのバグです。

ランブックURLをアラートに配線します。検索を必要とするランブックは存在しません。

インシデント対応ドキュメントの構築にはどれくらい時間がかかるべきですか？

ゼロから始める中規模のエンジニアリングチームの場合、数週間の集中したパートタイム作業を期待してください。

実用的な6週間のスプリントは以下のようになります：

• 1週目：アラートをインベントリ化し、サービス別にグループ化し、ページボリュームとリスクでランク付け。
• 2週目：インシデント対応ポリシーを起草または更新。
• 3〜4週目：9セクションテンプレートを使用して上位サービスのランブックをキャプチャ。
• 5週目：重大および低重要度の調整のための重要度ティアプレイブックを書く。
• 6週目：卓上演習を実行し、ギャップを修正し、ランブックリンクをアラートに配線。
• その後、メンテナンスは通常の運用に組み込まれるべきです。
• 四半期ごと、主要なサービス変更後、およびランブックが使用されたか不足していたインシデントの後にランブックをレビューします。

FAQ