インシデント・ポストモーテム・テンプレート：証拠から検証済みアクションへ

ポストモーテムで扱う仕事を区別する

インシデント報告は対応内容を記録できます。根本原因分析は故障機構を調べられます。判断ログは選択理由を残せます。ポストモーテムは、それらを測定影響、対応性能、不確実性、是正作業、その後の有効性確認へ結びます。

安定化する前に回顧文書を優先しない

進行中の優先事項は安全な検知、トリアージ、封じ込め、回復、連絡です。既存のOpenMaxインシデント対応自動化はライブ対応を扱います。復旧中の指揮担当者に文書整形をさせてはいけません。

内部ポリシーの安定条件を満たしてから開始し、ライブ記録を後知恵で編集しません。締切を記録すれば、遅延証拠が承認済み結論を黙って変えることを防げます。

一つの「根本原因」文に縮めない

「デプロイが原因」は広すぎます。デプロイはトリガー、許容的な既定値による無制限並行は直接機構、検証・カナリア・アラートの不足は寄与条件かもしれません。それぞれ異なる制御につながります。

本番が有効設定値を保持していなければ、差分、相関指標、ステージング再現に支持された機構は PLAUSIBLE のままにします。事実へ昇格することも、不確実だから削除することも避けます。

会議を成果物と誤解しない

会議は記録を修正し、作業を約束する場です。永続する成果は承認文書とアクション証拠です。「監視を改善する」という所有者のないメモや、試験なしで完了したチケットは閉鎖ではありません。

Googleの公開SRE資料は、影響、緩和、原因、フォローアップを含む書面記録とレビューを説明します。Atlassianの公開ハンドブックにも同様の構成があります。これらは設計参考であり、単一テンプレートが全ポリシーに適合する証明ではありません。

会議前に証拠を凍結する

高圧な出来事の後は記憶が変わり、ダッシュボードは古い粒度を失い、チャットが編集され、後の理論が曖昧な出来事を必然に見せます。証拠台帳はその変化を見えるようにします。

各成果物に安定IDと限界を付ける

ログクエリ、トレース、アラート、デプロイ、チケット、判断には次を記録します。

1. 安定した証拠ID。
2. イベント時刻または期間とタイムゾーン。
3. 正式な保存場所とアクセス区分。
4. 収集者または責任システム。
5. 支持する狭い命題。
6. 証明できない内容。

機能フラグ監査は特定時刻の無効化を支持しますが、キュー解消や以後の全結果の正しさは証明しません。それらには別証拠が必要です。

機密ペイロードではなく制限リンクと編集済み要約を使う

広く共有する文書にトークン、リクエスト本文、個人情報、顧客識別子は不要です。承認済みシステムへ安定リンクを置き、アクセス区分と最小要約を記録します。アクセスできない場合は通常の権限経路か承認済み抜粋で解決し、秘密を貼り付けません。

セキュリティ、プライバシー、法務、顧客通知は担当専門家が判断します。2025年4月に確定したNIST SP 800-61 Rev.3は、対応を広いサイバーリスク管理と改善へ接続します。本テンプレートの使用はNIST適合宣言でも、規制義務の判定でもありません。

締切と追補規則を明記する

「2026-09-04T12:00:00Z時点」は検査できますが、「後で集めた証拠」は曖昧です。締切後の重要資料は追補へ置き、影響する主張を示し、再レビューします。以前の状態も残して結論変更の理由を追跡可能にします。

影響母数を変えずに照合する

影響文には単位、母集団規則、期間、結果分類が必要です。数百件の失敗リクエストから数百人の利用者を推定できません。

証拠が本当に数えられる単位を選ぶ

リクエスト、ジョブ、注文、アカウント、人などから選びます。再試行で一人が複数リクエストを作るなら、安全な同一性照合とレビューなしに一意利用者へ変換しません。

PM081はレンダー「試行」を使い、利用者、ワークスペース、顧客、売上、契約を推定しません。母集団は09:07:11〜10:18:00 UTCに架空リージョンで受信した本番試行から内部ヘルスチェック再試行を除いたものです。

分類を相互排他的かつ網羅的にする

明記した優先規則で一行を一分類にします。PM081はタイムアウト、古いチェックサム、期待チェックサムの順です。

照合は 248 + 31 + 2,921 = 3,200、影響試行は 248 + 31 = 279、影響率は 279 / 3,200 × 100 = 8.71875% で表示は 8.72% です。再現できるよう未丸め値か出力を残します。

除外規則とクエリ版を残す

impact-v2からimpact-v3へ変えるなら理由を記録します。以前の出力を上書きして新しい数値が最初から既知だったようにしません。除外行と規則を残し、データ責任者が重複、時刻境界、結合を承認前に確認します。

証拠に基づくUTCタイムラインを作る

タイムラインはチャット全文ではありません。影響、検知、判断、緩和、回復を理解するイベントと、その時刻を固定する証拠を置きます。

発生・観測・報告・判断の時刻を区別する

09:07にタイムアウト、09:20にサポート受領、09:24にアラート、09:29に宣言という時刻は別の問いに答えます。サポート時刻を開始にすると、PM081で確認済みの12m52sが消えます。

指標名より先に時計を定義する

最初の確認影響から自動アラートは16m49s、宣言から緩和操作は12m00s、最初の確認影響から標本回復確認は1h10m49sです。

自動的にMTTA/MTTRとは呼びません。組織ごとに開始、終了、重大度、停止時間の定義が異なります。承認定義がない間は説明的な区間名を使います。

回復には異なる種類の観測を使う

空キューは待機作業がないことを示しますが、内容が最新とは示しません。そこでキュー解消と定義済み正しさフィクスチャを別々に記録します。それでも全結果ではなく標本回復です。

非難せず、確実性も捏造しない

非難しない分析は、当時の情報とシステムに基づき行動したと仮定し、不安全な結果を可能にした条件を調べます。率直さを高めますが責任を消しません。

トリガー、機構、寄与条件を分ける

• トリガー： 故障経路を始めた変更またはイベント。
• 直接機構： 観測された故障を作った技術・運用プロセス。
• 寄与条件： 確率または影響を高めた防護、UI、負荷、文書、検知条件。
• 代替説明： 証拠が確定・棄却するまで残す競合仮説。

PM081では設定変更のデプロイはCONFIRMEDトリガーです。欠落max_inflightが無制限となり下流プールを枯渇させた機構はPLAUSIBLEです。検証不足、カナリアのバースト不足、遅延アラートは確認済み寄与条件です。DB内容破損は本件では否定されていますが、全DB障害が不可能とは述べません。

当時の判断環境を記録する

何が見え、どの手順版が利用でき、どの権限と競合リスクがあったかを尋ねます。「なぜ早くしなかったか」ではなく「09:12に見えたシグナルと手順が許可した行動は何か」と聞けば、変更できる条件が得られます。

人の誤りを記録しないという意味ではありません。個人名で止まり、検証、既定値、権限、レビュー、負荷設計を見逃さないためです。

未知を正式記録に残す

PM081はE03以前の影響を決定できず、C07をUNKNOWNにします。物語が不整然になるから削除しません。解消価値がコストとプライバシー影響を上回る場合に、保持・テレメトリアクションを作ります。

検証可能な是正アクションを作る

アクションには対象リスク、具体的変更、責任者、期限、観測可能な検証契約が必要です。「注意する」「監視を改善」は不十分です。

実装と有効性を別状態にする

OPEN、IN_PROGRESS、IMPLEMENTED、EFFECTIVENESS_VERIFIED、ACCEPTED_RISKを使えます。手順公開で実装済みでも、定義した独立操作試験とレビュー前は有効性確認済みではありません。

PM081のA04は無効化、バックログ、正しさ確認を追加しIMPLEMENTEDですが、ゲームデイ未実施のため有効とはしません。

クローズ前に検証契約を書く

「負荷試験を追加」はタスクです。「40ワーカー上限で1,000ジョブを再生し、キュー排出、最大稼働<=40、定義フィクスチャの古い結果ゼロを確認」は検証契約です。

数字はPM081の架空条件で普遍的推奨ではありません。実サービスは構造とリスク許容度から設定します。

リスク受容も判断として記録する

費用がリスクを上回る場合、権限者が理由、範囲、再確認日を記録して受容できます。重要な取捨選択は判断ログ・テンプレートへ接続できます。放置はリスク受容ではありません。

完全な作例PM081を監査する

ダウンロード資料には9証拠、7役割、7因果主張、5アクション、60分議題、フォローアップ台帳があります。証拠がない承認・結果は未完了のままです。

架空サービスで起きたこと

Northstar Previewは09:02:14 UTCにv4.18.0をデプロイ。09:06:50からキュー時間とプール使用が上がり、09:07:11に最初の保持タイムアウト。サポート報告は自動アラートより早く、対応者は架空SEV-2宣言、新経路停止、バックログ確認、合成確認を行いました。

デプロイが先だから全原因とはしません。直接機構はSLレビュー待ちです。

各証拠の能力境界を読む

フラグ記録は操作、ゼロキューは排出、合成試験は標本正しさ、影響出力は試行件数を支持します。それぞれ回復全体、最新内容全件、一意人数は証明しません。

「支持する/証明しない」を繰り返すのは、成果物以上の確実性を持たせないためです。

成功事例として見せない理由

SLの機構レビュー、DLの影響レビュー、SEの開示審査が未完了です。EFFECTIVENESS_VERIFIEDのアクションはなく、文書はIN_REVIEWです。

完全なPM081資料を開き、空欄テンプレートの前に影響算術と時計を再現してください。良いテンプレートは見栄えだけでなく、異論を検査可能にします。

レビュー会議と承認経路を運用する

会議前に草稿とアクセス方法を配布し、通話中の初読ではなく証拠とコミットメントの修正に時間を使います。

母数と証拠を守る順序を使う

PM081の60分例は、5分で範囲・非難しない規則、10分で影響、12分で時系列、15分で因果と代替、12分でアクション、6分で読み返しです。複雑なセキュリティ事案は複数会議、単純事案はポリシー上可能なら非同期でも構いません。

記録を修正できる役割を招く

IC、サービス、データ、観測、アクション責任者と独立ファシリテーターを含めます。必要に応じ安全、プライバシー、法務、広報、ベンダーを追加します。出席は承認権ではないので、署名範囲を記録します。

楽観要約でなく未決事項を読み返す

変更主張、未知、アクション、所有者、期限、検証、編集、承認条件を読み返します。専門審査がなければIN_REVIEWのままです。遅延証拠には追補を使い、履歴を上書きしません。

OpenMaxを限定された草稿作業で試す

OpenMaxの公開DevOpsユースケースは、提供された資料の構造化、不足項目の指摘、レポート化、アクション追跡を説明します。これは限定試験を支持するベンダー説明です。本ページは製品、連携、権限、精度、公開性能値を試験していません。

正解が既知の資料から始める

PM081を入力し、E01–E09と限界、3,200件照合と8.72%、時刻種別、C01–C07の状態、A01–A05の検証契約、未承認一覧を保つよう求めます。

顧客を作る、試行を利用者に変える、A04を有効と呼ぶ、未知を落とす、ベンダー主張を独立証拠とする出力は拒否します。

証拠と承認ゲートは人の権限に残す

権限者が資料を選び、データ/サービス責任者が定量/技術を確認し、専門家が機密性を判断し、PAが公開状態を決めます。AI草稿に権限は移りません。

実記録前にOpenMaxまたは管理者へ現行連携、保持、権限、データ取扱いを確認してください。公開例は環境別検証の代替ではありません。

低複雑性なら単純な方法を選ぶ

頻度が低く証拠が少ないチームには文書と課題追跡で十分です。資料権限が未解決、引用をレビューできない、所有権が未定義ならAI層を増やしません。最小の次段階は編集済み既知資料一件であり、自律的本番取り込みではありません。

見栄えのよい文書が隠す失敗を防ぐ

草稿ごとに母数が変わる

一方はリクエスト、他方は利用者、または期間変更後も率が同じです。版管理規則、排他的分類、照合式で防ぎます。

タイムラインが記憶の合意になる

順序には合意してもログ、アラート、判断リンクがありません。時刻の隣に証拠IDを置き、推定を表示します。

根本原因が全条件を吸収する

広い一段落では制御へ対応できません。トリガー、機構、寄与、代替、未知を分けます。

非難しないことが所有者不在になる

分析はシステム中心でも、実装、検証、承認の責任は明記します。

完了を有効性と取り違える

マージや手順作成で閉じず、有効性状態と事前合意観測を残します。

機密証拠を便宜上コピーする

秘密、顧客内容、個人情報ではなく制限リンク、承認抜粋、専門編集を使います。

よくある質問

どのインシデントにポストモーテムが必要ですか？

重大度、顧客/データ影響、異例の回復、反復、コンプライアンス、学習価値などを事前ポリシーで定義します。書きやすさで事後判断せず、例外は権限者が承認します。

いつレビューすべきですか？

安定後すぐ証拠を保存し、文脈が残る間に開催しますが、影響クエリと因果分析の時間も確保します。重大度、保持、専門家の空きで変わり、普遍的日数はありません。

非難しないとは説明責任がないことですか？

違います。個人非難に単純化せず、証拠所有、主張レビュー、アクション所有、期限、承認、有効性を明確にします。

AIが根本原因を決められますか？

資料整理や不足発見はできますが、もっともらしい文は因果証明ではありません。サービス/データ責任者と、安全・法務等の有資格者が確認します。

是正アクションはいつ完了ですか？

少なくとも実装と有効性確認を分け、試験、閾値、証拠、レビュー者を先に決めます。失敗時は意図を書き換えず再開・置換します。

情報源と関連OpenMaxワークフロー

2026-09-05に確認した一次・公式資料：

• Google SRE Book: Postmortem Culture
• Google SRE Workbook: Postmortem Culture
• NIST SP 800-61 Rev.3
• Atlassian Incident Management Handbook: Postmortems
• OpenMax DevOpsユースケース文書

ライブ対応はインシデント対応自動化、リスク判断の履歴は判断ログ・テンプレートを参照できます。公開前に製品能力と安全上の助言を最新公式資料・内部ポリシーで再確認してください。