システム障害のRCA（根本原因分析）の進め方｜再発防止につなげる実践手順
株式会社 SunSunTech
システム障害の対応後、「原因は特定できたのに同じトラブルが繰り返される」「報告書が担当者探しで終わってしまう」と悩む運用担当者や開発リーダーは少なくありません。必要なのは、発生箇所を見つけるだけでなく、障害を生んだ仕組みまで掘り下げ、実行可能な再発防止策へつなげるRCA（Root Cause Analysis：根本原因分析）です。本記事では、事実収集から原因の切り分け、対策の優先順位付け、効果確認までを実務で使える順序で解説します。
目次
RCAとは？障害対応や原因調査との違い
障害対応の最優先事項はサービスを復旧させ、利用者への影響を止めることです。一方、RCAの目的は「なぜ障害が起き、なぜ影響を防げなかったのか」を明らかにし、再発する確率や影響を下げることにあります。復旧時に見つかった直接原因と、RCAで扱う根本原因は同じとは限りません。
たとえば、アプリケーションが停止した直接原因がメモリ不足でも、根本原因はメモリ使用量の増加を検知する監視がなかったこと、負荷試験の条件が実トラフィックと合っていなかったこと、容量計画の責任者が曖昧だったことかもしれません。プロセス再起動だけで完了にすると、条件がそろった時点で再発します。
RCAで追うべき対象は、技術要因だけではありません。設計、実装、テスト、変更管理、監視、連絡体制など、障害の発生と影響拡大に関係した仕組みを確認します。ただし、人の不注意を結論にしないことが重要です。「なぜその操作が可能だったか」「誤りを検知する仕組みはあったか」と問い直すことで、改善可能な原因が見えてきます。
RCAを始める前に集める事実と証拠
分析の質は、最初に集める事実で決まります。記憶や推測が混ざる前に、時刻をそろえたタイムラインを作成してください。障害の検知時刻だけでなく、最初の異常兆候、直前の変更、問い合わせ発生、一次対応、復旧操作、正常性確認までを並べます。
- 監視アラート、メトリクス、アプリケーション・OS・ネットワークのログ
- デプロイ、設定変更、ジョブ実行、権限変更などの履歴
- 発生条件、影響範囲、影響時間、利用者から見えた症状
- 対応者が実行したコマンドや判断、その時点で参照した情報
- 正常時との違いと、復旧を確認した客観的な指標
事実と仮説は明確に分けます。「DB接続数が上限に達した」は観測事実ですが、「アクセス集中が原因」は未検証の仮説です。各記録に時刻、情報源、確認者を付けると、後から矛盾を解消しやすくなります。ログの保存期間が短い場合は、障害対応中に退避する手順もランブックへ入れておきましょう。
根本原因を特定する5ステップ
1. 問題を一文で定義する
「システムが不安定だった」のような曖昧な表現を避け、「9月7日12時10分から12時28分まで、APIの応答時間が基準値を超え、一部リクエストが失敗した」のように対象、時間、期待状態との差を定義します。問題の境界が決まると、無関係な調査を減らせます。
2. タイムラインから変化点を探す
最初の異常の直前に何が変わったかを確認します。リリースだけでなく、データ量、アクセス傾向、証明書、外部API、バッチ処理、インフラ構成も候補です。ただし、時間的に近い出来事を即座に原因と決めないでください。
3. 仮説を複数立てて検証する
アプリ、データベース、ネットワーク、基盤、外部サービスなどの観点から仮説を並べます。各仮説には「正しければ、どのログやメトリクスに何が現れるか」という反証可能な条件を付けます。再現試験が難しい本番障害では、正常系との比較や段階的な切り分けが有効です。
4. 「なぜ」を仕組みまで掘り下げる
なぜなぜ分析では、回数を5回に固定せず、組織が制御できる要因に到達するまで問いを続けます。原因が複数経路に分かれる場合は、特性要因図やフォルトツリーを使うと整理しやすくなります。「担当者が確認しなかった」で止めず、チェックが省略できた理由、レビューや自動検証で捕捉できなかった理由を掘り下げます。
5. 原因と証拠の対応をレビューする
結論ごとに裏付けとなるログ、設定、試験結果を示します。主要因を取り除けば同じ条件で障害が防げるか、残った説明不能な事実がないかを関係チームで確認します。確証がない部分は「推定」と明記し、追加観測の計画を立てます。
再発防止策を決める優先順位とチェックリスト
対策は「注意する」「教育する」だけで終わらせず、発生防止、早期検知、影響軽減、復旧短縮の四層で考えます。恒久対策に時間がかかる場合は、暫定対策にも期限と解除条件を設定します。
- 原因を直接取り除くか、発生確率を下げられるか
- 自動テスト、入力制御、権限分離などで人の判断に依存しないか
- 監視指標としきい値が症状より前の兆候を捉えられるか
- 冗長化、流量制御、機能縮退で影響範囲を限定できるか
- ランブック、連絡経路、切り戻し手順で復旧を短縮できるか
- 担当者、期限、完了条件、効果測定方法が決まっているか
対策候補は効果、実装コスト、新たなリスク、完了までの時間で比較します。変更によって別の障害を生まないよう、テスト方法とロールバックも同時に設計してください。すべてを一度に実施できない場合は、被害の大きさと再発可能性が高い項目から着手します。
形だけのRCAにしないための失敗例と改善策
典型的な失敗は、会議を早く終えるために最初の仮説を採用することです。改善策は、仮説ごとの証拠と反証条件を表にし、別チームのレビューを受けることです。次に多いのは、報告書を作成して完了とするケースです。対策をチケット化し、通常の開発計画に組み込まなければ実装されません。
また、重大障害だけを分析対象にすると、小さな予兆を見逃します。利用者影響が軽くても、偶然や手作業で復旧できた事象、同じ兆候が繰り返される事象は対象に含めます。反対に、すべての軽微なアラートへ重い分析を行うと運用が続きません。影響度、再発性、未知性を基準に、簡易レビューと正式RCAを使い分けると現実的です。
個人を責める雰囲気も情報不足を招きます。RCAは評価や処罰の場ではなく、システムを改善する場だと共有してください。判断時点で見えていた情報を基準に検証し、結果を知った後の視点で過去の判断を断罪しないことが、率直な事実共有につながります。
よくある質問
Q1. RCAはどの障害で実施すべきですか？
サービス停止、データ不整合、セキュリティ影響など重大な事象に加え、再発している事象、原因が不明な事象、今回は偶然影響を免れた事象を優先します。影響度と再発可能性で基準を事前に決めておくと判断がぶれません。
Q2. なぜなぜ分析は必ず5回行うのですか？
必ずしも5回ではありません。重要なのは回数ではなく、証拠に基づいて因果関係をたどり、組織が変更できる仕組み上の要因へ到達することです。複数原因が絡む場合は一本の直線にせず、分岐させて整理します。
Q3. RCA報告書には何を書けばよいですか？
概要、影響範囲、タイムライン、検知と復旧の経緯、直接原因と根本原因、裏付け、対策、担当者、期限、効果確認方法を記載します。未確定事項と追加調査も分けて示すと、読み手が確定情報を誤解しません。
まとめ
RCAは原因を一つ言い当てる作業ではなく、再発を防げる仕組みに変える活動です。まず事実と仮説を分けたタイムラインを作り、複数の仮説を証拠で検証し、人ではなく設計・テスト・運用プロセスまで掘り下げます。そのうえで、発生防止、早期検知、影響軽減、復旧短縮の対策を担当者と期限付きで実行してください。次の一歩として、直近の障害を一件選び、本記事のチェックリストを使って未検証の仮説と未完了の対策を洗い出しましょう。
投稿者プロフィール
-
はじめまして。
株式会社SunSunTech代表取締役の鈴木と申します。
SunSunTechは、エンジニアが納得できるキャリアと報酬を得られるSES企業を目指して設立しました。
私は元々、エンジニアとして複数のSES現場で経験を積んできました。
その中で、「スキルに見合った評価が得られない」「給与の仕組みが不透明」といった業界特有の課題に何度も直面してきました。
こうした状況を変えるために、SunSunTechでは、透明性のある評価制度の導入、エンジニアファーストな案件選定など、"エンジニアが報われる仕組み"を徹底しています。
SES企業様とのパートナー連携においても、スピード・誠実・精度を大切にし、長期的に信頼される関係構築を目指しております。
エンジニアの未来を、本気で変えていく。
その想いに共感してくださる方、ぜひ一度お気軽にお声がけください。
