障害報告書の書き方｜ポストモーテムテンプレート

※本記事はプロモーションを含みます。

本記事では、障害発生後の重要なプロセスである「ポストモーテム（事後分析）」の書き方を、テンプレートを交えて解説します。ポストモーテムは単なる報告書ではなく、組織全体での障害学習を実現するための重要な仕組みです。本記事を読むことで、実務的で効果的な障害報告書を作成できるようになります。

📖 読了時間目安：8～10分

ポストモーテムとは何か

障害報告書の定義

ポストモーテム（Post-Mortem）は、本来は医学用語で「死後検査」を意味しますが、IT業界では障害が発生した後に、その原因・経過・対策をまとめた文書を指すようになりました。単なる「何が起きたのか」の記録ではなく、「なぜそれが起きたのか」「どうすれば再発防止できるのか」を明確にするためのプロセスとされています。

ポストモーテムが重要な理由

多くの組織では、障害発生直後は対応に追われ、その後は忙しさに紛れて「なぜ起きたのか」の本質的な分析をスキップしてしまう可能性があります。しかし、この「事後学習」を組織的に実施することで、以下のようなメリットが生まれるとされています。

同じ原因による障害の再発防止
チーム全体での知識共有
システム設計・運用プロセスの改善
責任追及ではなく「学習文化」の醸成
新しい障害パターンの事前発見

ポストモーテムの基本方針

ポストモーテムを効果的にするには、「犯人探し」ではなく「システム改善」を目的にすることが重要です。個人の過失を追及するのではなく、「そのような過失が起きる環境をどう改善するか」という視点を持つことで、チーム全体が心理的安全性を感じながら活発な議論に参加できるようになるとされています。

ポストモーテム作成の全体フロー

フェーズ①：タイムライン収集

ポストモーテムの作成は、障害が完全に解決した後、1～3日以内に開始することが推奨されています。まずは、障害が発生してから完全に復旧するまでの時系列を詳細に記録します。

いつ（日時）障害に気づいたのか
どのようなアラートまたは報告で検知したか
対応チームはいつ組成されたか
どのような調査が行われたか（実施日時）
いつ原因が特定されたか
いつ一時的な対応が実施されたか
いつ恒久的な対応が実施されたか
いつ完全な復旧を確認したか

フェーズ②：根本原因分析

次に、「なぜそのような障害が起きたのか」を5回の「なぜ」で掘り下げる手法（5 Why Analysis）が効果的とされています。単一の原因ではなく、複数の要因が重なって障害が発生する可能性があることを認識することが重要です。

例：ログイン機能が一時的に使用不可になった場合
❌ 原因（表面）：「キャッシュサーバーが落ちた」
✅ 根本原因（掘り下げ）：「キャッシュメモリ設定が低く、大量のセッション生成で満杯になった」→「セッション自動削除機能がコード変更時に削除されていた」→「自動テストでキャッシュ関連の回帰テストが実施されていなかった」

フェーズ③：改善項目の洗い出し

根本原因が明確になったら、それを防ぐための改善項目を列挙します。この際、実装の難易度と再発防止効果の大きさで優先度をつけることが実務的とされています。

短期対策：即座に実施できるもの（設定変更、監視項目追加など）
中期対策：2～4週間で実装できるもの（機能追加、テスト導入など）
長期対策：1ヶ月以上の時間が必要なもの（アーキテクチャ改善など）

フェーズ④：ドキュメント化と共有

最終的なポストモーテム文書は、技術的なディテールと、組織全体で理解できる説明のバランスを取ることが重要です。また、作成後は関係チーム全体で共有し、フィードバックを集めることも推奨されています。

テンプレート実例

標準的なテンプレート構成

以下が、実務的に用いられるポストモーテムの基本構成です。組織の規模やシステムの複雑さに応じて、カスタマイズして使用することが推奨されています。

セクション	記載内容
概要	障害内容、影響範囲、対応時間を1～2段落で要約
影響度	影響ユーザー数、ダウンタイム、ビジネス損失（推定）
タイムライン	検知→報告→対応→復旧の時系列（テーブル形式）
根本原因	5 Why Analysis で掘り下げた最終的な原因
改善項目	短期・中期・長期に分けた対策と実装予定日
教訓	組織全体が学ぶべき点、プロセス改善の示唆

記入例：APIサーバー障害

【概要】
2024年5月2日 14:30～15:45の間、会員向けAPIサーバーがメモリ不足により応答不可の状態となりました。スマートフォンアプリからのログイン機能が利用できず、約12,000人の活動ユーザーが影響を受けた可能性があります。最終的にはメモリ解放とプロセス再起動により復旧しました。

【影響度】
・影響ユーザー：約12,000人（推定アクティブユーザーの約60%）
・ダウンタイム：75分
・推定ビジネス損失：約250万円（取引仲介手数料の機会損失）

【タイムライン】

時刻	イベント
14:30	Datadog監視でAPIサーバーのメモリ使用率が95%を超えたとアラート発生
14:32	オンコール担当者が通知を受け、ヘルスチェック実施→APIが返応していないことを確認
14:35	Slack緊急対応チャネルで通知、エンジニア3名が参加
14:50	メモリダンプを確認、キャッシュプロセスが異常にメモリを占有していることを特定
15:10	一時的な対応：APIプロセスを再起動、キャッシュをクリア
15:45	復旧確認、ユーザーからの苦情報告が減少

【根本原因】

❶ なぜ再起動が必要だったのか？
→ キャッシュプロセスがメモリ上限に達し、OSがプロセスをキルしたため

❷ なぜキャッシュが暴走したのか？
→ 先週の新機能リリースで、セッション取得ロジックが変更され、キャッシュのメモリ解放タイミングが失われた

❸ なぜテストで検出されなかったのか？
→ 負荷テスト環境は本番環境と異なるセッション数（テストは1,000、本番は100,000）で運用されていた

❹ なぜ負荷テスト環境が陳腐化したのか？
→ 本番トラフィックが当初予想の100倍に成長したが、負荷テスト環境の仕様書が更新されていなかった

❺ なぜ本番との乖離が放置されたのか？
→ インフラチーム内での定期的なレビュープロセスが確立されておらず、環境が「陳腐化」することへの所有感がなかった

【改善項目】

■ 短期（1週間以内）
・キャッシュメモリ上限を本番環境の実際のピークトラフィックに基づいて再設定
・メモリ使用率のアラート閾値を80%に引き下げ（現在は95%）

■ 中期（2～4週間）
・負荷テスト環境の仕様を本番と同期するドキュメントを作成（月次レビュー）
・自動テストに「キャッシュメモリリーク検出」テストを追加

■ 長期（1ヶ月以上）
・キャッシュレイヤーの設計見直し（メモリ制約下での自動スケジューリング機能の導入）

【教訓】
本件を通じて、以下の3点が組織的な学習として挙げられます。①開発環境・テスト環境と本番環境の乖離は、障害の温床となる。定期的な同期メカニズムが必須。②単一原因ではなく複数の要因が重なって障害が発生する。各層での検証・監視が重要。③インフラ・開発の責任分界点が曖昧だと、誰も所有していない領域が生まれ、劣化する。チーム横断での定期レビューの仕組みを導入する。

よくある失敗パターン

❌ パターン①：犯人探しに終始

多くの組織で見られる失敗は、「誰がミスしたのか」に焦点が当たり、本質的なシステム改善につながらないことです。たとえば「▲▲が設定を間違えたから障害が起きた」と判断して終わると、その人への個人攻撃につながり、チームの心理的安全性が損なわれるとされています。重要なのは「なぜそのようなミスが起きやすい環境になっているのか」を問うことです。

❌ パターン②：表面的な原因で終わる

「データベース接続がタイムアウトした」という表面的な症状を原因と勘違いし、タイムアウト値を増やすだけで終わってしまうケースがあります。実は「背景には不適切なクエリが実行され、ロックが長時間保持されていた」という構造的問題があるかもしれません。5 Whyで掘り下げることが重要です。

❌ パターン③：アクションプランなし

原因分析までは実施するものの、「改善項目をリストアップしたが、誰も実装しない」という組織は少なくないとされています。ポストモーテムは、具体的な改善項目に実装責任者と期限を割り当てるところまでが完成です。理想的には、月次レビューで進捗を追跡することが推奨されています。

❌ パターン④：開催のタイミングが遅すぎる

障害から数週間経ったしてからポストモーテムを開催すると、参加者の記憶が曖昧になり、タイムラインの再構成が困難になるとされています。理想的には障害完全解決から1～3日以内に開催することが推奨されています。

実装時のチェックリスト

ポストモーテムを実施する際に、以下のチェックリストを参考にすることで、実務的で質の高いドキュメントが作成できるとされています。

【事前準備】

☐ ポストモーテムは障害完全解決から1～3日以内に開催する
☐ 対応に参加した全メンバー（開発・インフラ・運用・QA）を招待
☐ ログ・ダッシュボード・アラート履歴などの資料を事前に収集
☐ 責任追及ではなく「学習」が目的であることを明示

【進行中】

☐ タイムラインを分単位で構築（後で見返すための記録）
☐ 各メンバーの視点から「その時点で何が見えていたのか」を聞く
☐ 5 Whyで最低3回は「なぜ」を繰り返す
☐ 複数の原因が重なっていないか確認
☐ 改善項目ごとに担当者と完了期限を決定

【事後フォローアップ】

☐ ドキュメントを全社に共有（技術以外の部門にも）
☐ 月次の進捗レビューを実施、改善項目の進捗を追跡
☐ 3～6ヶ月後に「実装した改善が効果を発揮しているか」を検証
☐ 類似の原因を持つ過去の障害がないか横断検索

まとめ

ポストモーテムは、単なる事後報告書ではなく、組織全体が障害から学び、再発を防ぐための重要なプロセスです。本記事で紹介した通り、タイムラインの詳細な記録、5 Whyによる根本原因分析、具体的な改善項目の列挙、そして実装責任者・期限の明確化まで行うことで、初めて「実のあるポストモーテム」として機能するとされています。

ポストモーテムの実施を通じて、チーム内での「失敗を学習の機会に変える文化」が醸成されることで、長期的には障害の頻度低下や、より堅牢なシステム設計へつながる可能性があります。障害が起きた際は、焦らず、チーム全体で丁寧にポストモーテムプロセスを実施することをお勧めします。

免責事項

本記事の情報は執筆時点のものです。ポストモーテムプロセスの実装は組織の文化・規模・システムの複雑さにより異なります。本記事の手法を導入する際は、必ず社内の関係者と相談の上、組織に合わせたカスタマイズを行ってください。障害対応やシステム監視に関する判断は、必ず公式ドキュメントおよび専門家にご確認ください。

【編集・制作ポリシー】
本記事はRoute Bloom編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。編集ポリシーはこちら