障害の再発防止策｜原因分析から実効性ある対策を作る方法

「原因は設定ミスだった。次から注意する、で終えてよいのだろうか」

「再発防止策を作ったが、本当に効果があるか判断できない」

システム障害は、サービスが復旧した時点で終わりではありません。

再発防止を考えるには、まず障害原因を「アプリケーション・設定・ネットワーク・ハードウェア・運用」などに分類し、原因に合った対策を選ぶことが重要です。

同じ種類の問題を繰り返さないために、発生原因だけでなく、検出できなかった理由や影響が広がった理由まで振り返る必要があります。

再発防止策が「担当者へ注意喚起する」「レビューを強化する」だけでは、実施したか、効果があったかを判断できません。人の注意力に依存した対策は、時間がたつと形骸化しやすいものです。

25年以上の開発・保守経験から感じるのは、良い再発防止策ほど、特定の担当者を責めるのではなく、仕組み、手順、検知、復旧の弱点を具体的に変えているということです。

この記事では、原因分析を実行可能な対策へ落とし込み、完了と効果を確認する方法を解説します。

システム障害の原因を分類する

原因分類は責任者を決めるためではなく、再発防止策の方向性を決めるために行います。

すべての障害を完全に防ぐことは困難です。そのため、発生させない予防だけでなく、発生時に早く気付く検知、発生しても影響を小さくする影響軽減を組み合わせます。

対策は、担当者、期限、成果物、確認方法まで決めて初めて実行可能になります。

障害箇所	再発防止策例
ネットワーク障害	監視追加通信経路の冗長化 FW/DNS設定レビュータイムアウトやリトライ設計切替手順の整備
ハードウェア障害	冗長化予兆監視保守交換容量・寿命管理バックアップ／復旧試験
アプリ・設定障害	自動テスト設定差分確認 CI/CDでのチェックレビュー観点追加

最初に、発生から検知、連絡、暫定復旧、恒久対応までの時系列を整理します。推測を混ぜず、ログ、作業記録、承認記録などで裏付けます。

時系列には、「起きたこと」だけでなく「本来あるべきだったこと」も並べます。差が見えると、手順や検知の弱点を見つけやすくなります。

直接原因は障害を発生させた直接の事象です。背景要因は、その事象を生みやすくした設計・手順・体制上の条件です。流出原因は、リリース前や監視で検出できなかった理由です。

たとえば直接原因が設定値誤りでも、背景に環境別設定の手作業、流出原因に差分レビュー不足があるかもしれません。

「レビュー強化」ではなく、「本番と検証環境の設定差分を自動出力し、リリース判定会で確認する」のように、実施内容と完了条件を明確にします。

対策のコストが障害リスクに見合うかも確認します。すべてを大規模改修にせず、短期対策と中長期対策に分けると進めやすくなります。

悪い例：設定確認を徹底する
改善例：環境別設定ファイルの差分一覧をリリース前に自動生成し、担当者とレビュー者が確認記録を残す

担当：基盤チームA
期限：次回リリース判定まで
完了条件：差分一覧・確認記録・試行結果がそろう

手順書を更新しただけでは、再発防止の効果は確認できません。対策が実施されたことと、実際に誤りを検出できることを分けて確認します。

テスト環境で意図的に異常を発生させ、監視通知や切り戻し手順が機能するかを確認する方法も有効です。

対策を会議資料だけに残さず、担当・期限・完了条件を一覧で管理します。

【事象】
障害概要：
直接原因：
背景要因：
流出原因：
影響拡大要因：

【対策】
区分：予防／検知／影響軽減／復旧改善
実施内容：
担当者：
期限：
成果物：
実施確認方法：
効果確認方法：
横展開先：

原因と対策を一対一で結び付けると、対策漏れや過剰対策を確認しやすくなります。