障害報告書の書き方
ストーリー
「先週、本番環境で障害が起きたんだけど、報告書見た？」
「はい、見ました。原因と対応が分かりやすく書かれていました」
「あの書き方を覚えておくといいよ。エンジニアなら必ず書く機会がくるから」
「障害報告書ですか...ちょっと怖い響きですね」
「怖がらなくていいよ。大事なのは事実を正確に記録すること。犯人探しじゃないんだ」
障害報告書とは
障害報告書（インシデントレポート）は、システムに障害が発生したときに、その事実を記録する文書です。
目的
| 目的 | 説明 |
|---|---|
| 事実の記録 | 何が起きたかを正確に記録する |
| 原因の明確化 | なぜ起きたかを分析する |
| 対応の共有 | どう対処したかを記録する |
| 再発防止 | 同じ障害を繰り返さないための対策を立てる |
障害報告書は「誰が悪いか」を見つけるためのものではありません。 「何が起きて、どうすれば防げるか」を共有するためのものです。
障害報告書のテンプレート
markdown
# 障害報告書
## 概要
| 項目 | 内容 |
|------|------|
| 報告者 | （名前） |
| 発生日時 | YYYY-MM-DD HH:MM 〜 HH:MM |
| 検知方法 | （どうやって気づいたか） |
| 影響範囲 | （影響を受けたユーザー・機能） |
| 重要度 | Critical / Major / Minor |
## タイムライン
| 時刻 | イベント |
|------|---------|
| HH:MM | （最初に何が起きたか） |
| HH:MM | （どう対応したか） |
| HH:MM | （復旧した時刻） |
## 原因
（障害の直接的な原因を記載）
## 対応内容
（実施した復旧作業を記載）
## 影響
（ユーザーやビジネスへの影響を記載）
## 再発防止策
| 対策 | 担当 | 期限 |
|------|------|------|
| （対策1） | （名前） | （YYYY-MM-DD） |
| （対策2） | （名前） | （YYYY-MM-DD） |
## 教訓
（今回の障害から学んだこと）各セクションの書き方
タイムライン
時系列で事実だけを書きます。 感想や推測は入れません。
markdown
## タイムライン
| 時刻 | イベント |
|------|---------|
| 14:30 | 監視アラートが発報（API応答時間が5秒超過） |
| 14:32 | 担当者（田中）がアラートを確認 |
| 14:35 | ログを調査し、データベース接続エラーを確認 |
| 14:40 | データベースサーバーのディスク容量が100%であることを特定 |
| 14:45 | 不要なログファイルを削除し、ディスク容量を確保 |
| 14:50 | データベース接続の復旧を確認 |
| 15:00 | 全サービスの正常動作を確認し、復旧完了 |原因
直接原因 と 根本原因 を分けて書くと分かりやすくなります。
markdown
## 原因
### 直接原因
データベースサーバーのディスク容量が100%に達し、
新しいデータの書き込みができなくなった。
### 根本原因
- アプリケーションログが日次ローテーションされておらず、
ログファイルが肥大化していた
- ディスク容量の監視アラートが設定されていなかった再発防止策
具体的で実行可能な対策 を書きます。「気をつける」のような精神論はNGです。
悪い例
markdown
## 再発防止策
- 今後は気をつける
- ディスク容量に注意する良い例
markdown
## 再発防止策
| 対策 | 担当 | 期限 |
|------|------|------|
| ログのローテーション設定（7日保持） | 鈴木 | 4/10 |
| ディスク使用率80%でアラート設定 | 鈴木 | 4/10 |
| 月次でディスク容量を確認するチェックリスト追加 | 田中 | 4/15 |重要度の分類
| 重要度 | 基準 | 例 |
|---|---|---|
| Critical | サービス全体が停止 | 全ユーザーがログインできない |
| Major | 主要機能に影響 | 検索機能が使えない |
| Minor | 一部機能に影響 | 特定条件で表示が崩れる |
障害報告書の具体例（完成版）
markdown
# 障害報告書: APIサーバー応答遅延
## 概要
| 項目 | 内容 |
|------|------|
| 報告者 | 田中一郎 |
| 発生日時 | 2025-04-01 14:30 〜 15:00（30分間） |
| 検知方法 | 監視ツール（Datadog）のアラート |
| 影響範囲 | 全ユーザーのAPI操作（約500名に影響） |
| 重要度 | Critical |
## タイムライン
| 時刻 | イベント |
|------|---------|
| 14:30 | Datadogアラート発報（API応答時間 > 5秒） |
| 14:32 | 田中がアラート確認、調査開始 |
| 14:35 | DBサーバーへの接続エラーをログで確認 |
| 14:40 | DBサーバーのディスク使用率100%を特定 |
| 14:45 | 不要ログファイル（15GB）を削除 |
| 14:50 | DB接続復旧を確認 |
| 15:00 | 全機能の正常動作を確認、復旧完了 |
## 原因
### 直接原因
DBサーバーのディスク容量が100%に達し、書き込み不可となった。
### 根本原因
- アプリケーションログの自動ローテーションが未設定
- ディスク容量の監視アラートが未設定
## 対応内容
1. 不要なログファイル（15GB分）を手動削除
2. DBサービスを再起動
3. 全APIエンドポイントの動作確認を実施
## 影響
- 約30分間、全ユーザーのAPI操作に遅延が発生
- データの損失はなし
- 一部ユーザーからの問い合わせ: 5件
## 再発防止策
| 対策 | 担当 | 期限 |
|------|------|------|
| ログローテーション設定（7日保持、自動削除） | 鈴木 | 2025-04-07 |
| ディスク使用率80%でアラート設定 | 鈴木 | 2025-04-07 |
| 月次インフラ点検チェックリストの作成 | 田中 | 2025-04-15 |
## 教訓
- 監視とアラートの設定は「事前に」行う必要がある
- ログ管理は運用の基本であり、初期構築時に設定すべきまとめ
| ポイント | 内容 |
|---|---|
| 障害報告書とは | 障害の事実・原因・対応・再発防止を記録する文書 |
| 大切なこと | 犯人探しではなく、再発防止が目的 |
| タイムライン | 時系列で事実だけを書く |
| 原因 | 直接原因と根本原因を分ける |
| 再発防止策 | 具体的で実行可能な対策を書く（精神論はNG） |
- 障害報告書の目的を理解した
- テンプレートの構成を把握した
- 各セクションの書き方を学んだ
次のステップへ
障害報告書の書き方は理解できましたか？
次のセクションでは、すべての報告書に共通する「読みやすい文章のコツ」を学びます。
推定読了時間: 30分