障害報告と再発防止
障害報告と再発防止
障害が復旧したら終わりではありません。障害から学び、再発を防止するための取り組みが、組織のIT基盤を強くしていきます。障害報告書の作成と再発防止策の策定は、ひとり情シスの重要な責務です。
障害報告書の書き方
障害報告書は「何が起きたか」を正確に記録し、関係者に共有するための文書です。
障害報告書の構成
| 項目 | 内容 |
|---|---|
| 障害概要 | どのシステムにどのような障害が発生したかの要約（1〜2行） |
| 発生日時 | 障害の発生日時（検知日時と実際の発生推定日時の両方） |
| 復旧日時 | 障害が復旧した日時（暫定復旧と完全復旧を区別） |
| 影響範囲 | 影響を受けたシステム、ユーザー数、業務への影響 |
| 経緯（タイムライン） | 発生から復旧までの対応を時系列で記載 |
| 原因 | 直接原因と根本原因（後述のRCA結果） |
| 対応内容 | 暫定対応と恒久対応の具体的な内容 |
| 再発防止策 | 同じ障害を防ぐための具体的な施策と実施期限 |
| 教訓・改善点 | 対応プロセスの改善点、得られた教訓 |
📋 具体例
障害報告書のタイムライン記載例：
09:00 複数ユーザーから「ファイルサーバーに接続できない」との申告
09:05 ファイルサーバー（SV-FILE01）にpingが通らないことを確認
09:10 サーバールームにて確認、サーバーの電源LEDが消灯していることを確認
09:15 UPSのログを確認、03:22にバッテリー残量ゼロで電源断が発生
09:20 商用電源は復旧済みであることを確認、サーバーを手動起動
09:35 OS起動完了、ファイルサーバーサービスの正常稼働を確認
09:40 全ユーザーにファイルサーバー復旧を通知
09:45 ファイルの整合性チェックを実施、異常なし
根本原因：UPSバッテリーの経年劣化（設置後5年、交換推奨期限を超過）
根本原因分析（RCA）
RCA（Root Cause Analysis）とは、障害の表面的な原因ではなく、真の根本原因を特定するための分析手法です。
5Why分析（なぜなぜ分析）
「なぜ？」を5回繰り返すことで、根本原因にたどり着く手法です。
📋 具体例
事象：ファイルサーバーが停止した
なぜ1：なぜサーバーが停止した？ → 電源が落ちたから
なぜ2：なぜ電源が落ちた？ → UPSのバッテリーが切れた状態で停電が発生したから
なぜ3：なぜバッテリーが切れていた？ → バッテリーが劣化していたから
なぜ4：なぜ劣化に気づかなかった？ → UPSのバッテリー状態を定期確認していなかったから
なぜ5：なぜ定期確認していなかった？ → UPSの点検が運用手順に含まれていなかったから
根本原因：UPSの定期点検が運用手順に含まれておらず、バッテリー劣化を検知する仕組みがなかった
再発防止策：①UPS点検を月次チェックリストに追加 ②UPS監視ソフトウェアを導入しバッテリー状態をアラート通知
再発防止策の策定
再発防止策は「具体的」「実行可能」「測定可能」であることが重要です。
| NG（曖昧な防止策） | OK（具体的な防止策） |
|---|---|
| 注意する | 変更作業前のチェックリストに「バックアップ確認」の項目を追加する |
| 監視を強化する | PRTGにディスク使用率90%超過のアラートを設定し、Teamsに通知する |
| 手順書を見直す | ○○手順書のステップ5に確認事項を追記し、ダブルチェック体制にする |
| 教育を徹底する | 四半期ごとの全社セキュリティ研修に「パスワード管理」の15分枠を追加する |
⚠️ 注意
「人のミスが原因」で分析を終わらせないでください。ヒューマンエラーは「なぜそのミスが起きやすい状態だったのか」「なぜミスを防止する仕組みがなかったのか」まで掘り下げることが重要です。個人を責めるのではなく、システムや仕組みの改善に焦点を当てましょう。
ポストモーテム文化
ポストモーテム（事後検証）は、障害から学ぶための振り返りミーティングです。GoogleやAmazonなどのテック企業で広く実践されており、中小企業でも取り入れるべき文化です。
ポストモーテムの原則
- 非難しない（Blameless）：個人を非難するのではなく、仕組みの改善に焦点を当てる
- 事実ベース：推測ではなく、ログやデータに基づいて議論する
- 全員参加：対応に関わった全員が参加し、それぞれの視点を共有する
- 改善にコミット：抽出された改善策には担当者と期限を設定し、確実に実行する
- 共有する：ポストモーテムの結果を組織内で共有し、他のチームも学べるようにする
ポイント：ポストモーテムは「犯人探し」の場ではなく「学びの場」です。「あの人がミスした」ではなく「なぜミスが起きやすい環境だったのか」「どうすればミスを防げる仕組みを作れるか」を議論します。この文化が根付くと、障害が報告されやすくなり、組織全体の改善スピードが上がります。
教訓の共有と標準化
障害から得られた教訓は、組織のナレッジとして蓄積し、標準化することで価値を最大化します。
- 障害データベース（ナレッジベース）の構築：過去の障害事例と対応方法を検索可能な形で蓄積。Confluence、SharePoint、Notionなどが活用できる
- 運用手順書への反映：再発防止策を運用手順書に反映し、標準手順として定着させる
- チェックリストの更新：変更作業前のチェックリストや定期点検リストに新たな確認事項を追加
- 監視設定の追加：障害の予兆を検知できるよう、監視項目やアラート閾値を追加・調整
- 定期的な振り返り：四半期に一度、過去の障害事例を振り返り、再発防止策が機能しているか確認
📋 具体例
障害ナレッジベースの管理例（SharePointリストの場合）：
・項目：障害ID、発生日、カテゴリ（HW/SW/NW/セキュリティ）、障害概要、根本原因、対応方法、再発防止策、ステータス
・ビュー：カテゴリ別ビュー、未完了の再発防止策ビュー、直近3ヶ月の障害一覧ビュー
・活用法：類似障害が発生した際に、過去の対応方法を検索して迅速に対応。新メンバーの教育資料としても活用
障害メトリクスの管理
障害対応の品質を継続的に改善するため、以下のメトリクス（指標）を記録・分析しましょう。
| メトリクス | 内容 | 改善の方向性 |
|---|---|---|
| MTBF（Mean Time Between Failures） | 障害と障害の間の平均時間 | 長いほど良い（システムの安定性） |
| MTTR（Mean Time To Recovery） | 障害検知から復旧までの平均時間 | 短いほど良い（復旧の迅速さ） |
| MTTD（Mean Time To Detect） | 障害発生から検知までの平均時間 | 短いほど良い（検知の迅速さ） |
| 障害件数 | 月間/四半期間の障害発生件数 | 減少傾向が望ましい |
| 再発率 | 同一原因による障害の再発割合 | ゼロに近づけるべき |
ひとり情シスの視点：障害報告書を「面倒な事務作業」と捉えるのではなく、「自分のスキルと組織の仕組みを向上させるための投資」と捉えましょう。特にひとり情シスは、自分の対応経験を文書化しておかないと、属人化が進み、自分が不在の時に誰も対応できなくなります。障害報告書とナレッジベースは、自分自身の「分身」を作るための最も効果的な方法です。
✅ 完了済み