Incident Postmortem

• 本番環境のサービス停止や性能劣化イベントの後に、P1/P2/P3またはSEVレベルのインシデントレポートを作成する必要がある。
• インシデントに関する大まかなメモがあり、それをプロフェッショナルで責任追及をしないポストモーテム形式に整理したい。
• 技術エンジニアと非技術系のリーダーシップの両方と共有できる、一貫性のあるRCAドキュメントが必要である。
• チームがインシデント後レビューを実施しており、責任追及をしない表現、明確なアクションアイテムのオーナー、そして体系的なギャップ分析を徹底できる構造化されたフォーマットを求めている。

• リアルタイムのインシデントランブックやオンコール対応ガイドが必要な場合 — このスキルはインシデント発生中のライブ対応ではなく、インシデント事後のドキュメント作成を目的としています。
• インシデントがまだ進行中で未解決の場合。検知、軽減、および解決の詳細が揃うまでお待ちください。

このスキルは、タイムラインおよび根本原因のセクション全体にわたって、受動態およびシステムに焦点を当てた表現を使用し、特定の個人を責めるような言い回しを明示的に避けます。品質チェックリストは、システム上のギャップではなく個人に過失を帰するような表現にフラグを立てます。

平易な技術的言語による主要なルート原因のステートメントを生成し、さらに寄与因子のリストと、既存のセーフガードがなぜ機能しなかったかについての率直な説明を提供します。これは有用なRCAの核心部分です。

最初の症状から検出、エスカレーション、仮説検証、修正、解決確認までの出来事を、タイムスタンプ付きのタイムラインとして生成します。主要なイベント間の時間的な間隔も含まれます。

アクションアイテムは「再発防止」「検知改善」「対応改善」のいずれかに分類され、具体的な担当者と期限が設定されます。「モニタリングを改善する」といった曖昧な項目は却下され、テスト可能でクローズできるタスクが優先されます。

エグゼクティブサマリーは専門用語を使わず、技術的な知識を持たないステークホルダー向けに記述される一方、技術セクションはエンジニアリングチーム向けに詳細な内容を提供します。これにより、同一のドキュメントが組織全体にわたって役立つものとなります。

生成されたすべてのポストモーテムには、ドキュメントが共有される前に、タイムラインの表現、根本原因の具体性、アクションアイテムの完全性、およびエグゼクティブサマリーの読みやすさを確認するセルフレビューチェックリストが含まれています。

サービスが停止した後、オンコール時のメモやSlackのスレッドをスキルに貼り付けるだけで、タイムライン、影響範囲テーブル、根本原因を含む完全なポストモーテムに整理されます。インシデント管理ツールやWikiに数分以内で投稿できる状態に仕上がります。なお、このスキルのブランド名は Incident Postmortem のままご利用ください。

リーダーシップ層が重大インシデントに関するブリーフィングを必要としています。Incident Postmortem は、完全な技術文書と並行して非技術的なエグゼクティブサマリーを生成するため、全ての関係者に対して1つのレポートを送付するだけで済みます。

「What Went Well（うまくいったこと）」と「Lessons Learned（学んだ教訓）」のセクションを活用して、チームのレトロスペクティブを進めましょう。構造化されたフォーマットにより、対応改善とチーム間で共有すべき知識の両方を網羅した議論が確実に行われます。

インシデントが顧客のSLAに違反した場合、Incident Postmortemのインパクトテーブルとコミュニケーションログのセクションが、顧客向けレポートおよび是正措置の追跡に必要な構造化された証拠を提供します。