障害対応でありがちなのが、「とりあえず復旧したけど、また同じ問題が起きる」という状態です。これは一時対応だけで終わり、根本原因に手を打てていないことが原因です。再発防止策（二次対応）は、調査で特定した“本当の原因”を取り除くプロセスですが、重要なのは「どこまで原因を掘り下げるか」という粒度です。表面的な原因だけに対処すると、問題は形を変えて再発します。
本記事では、再発防止策の考え方に加え、原因を3層で捉える視点、判断を誤りやすいポイント、現場で使える進め方まで整理し、「無駄打ちしない対策」の実践ポイントを解説します。
再発防止策（二次対応）とは
二次対応とは
再発防止策では、調査で特定した問題の根本原因を取り除きます。根本原因を取り除くことで、障害の再発を防止し、安定稼働と工数削減を実現します。
取り急ぎの復旧である一時対応では、同様の問題が再発する可能性が残ります。そのため、復旧後に調査を行い、根本原因の特定を実施。特定した原因を取り除くために二次対応をする形です。
参考：AWSの運用:一次対応
参考：AWSの運用:調査
再発防止策をとらないと
再発防止策をとらないと
再発防止策をとらないと、どのような影響があるのか？
まず一つ目は、同様の障害が再発する可能性があります。たとえばメモリ不足で動作が遅くなった場合、対象プロセスやサーバーを再起動することで解消ができます。しかし、必要なメモリ量の確保ができていない場合は、しばらくするとまた動作が遅くなります。
もう一つは、別の事象として現れることがあります。メモリの例でいえば、OOM Killerなどでサービス提供不能な状態に陥る可能性があります。OOM Killerはシステムのメモリが不足しているときに、優先度の低いプロセスを停止させることでシステム全体の停止を防ぐ仕組みです。
メモリ不足自体を解消しない限り、「動作が遅くなる」「サービスが停止する」というように、様々な形で問題が表面化します。
再発防止の流れ
再発防止の流れ
では、再発防止の流れをみてみましょう。
■原因調査
まず原因調査が必要です。正確に根本原因を特定しない限り、再発防止はできません。
■再発防止策を検討
根本原因の特定ができたら、再発防止策の検討を行います。メモリ不足の例でいえば、「メモリを増やす」以外にも、「不要なサービスは立ち上げない」「複数台で負荷分散する」「設定をチューニングする」など様々な対策が検討できます。
■実施可否の判断
再発防止策のメリットデメリットを比較検討し、実際に行う再発防止策を決定します。影響によっては、何もしない。という選択肢もあります。
■再発防止策を実施
実施を決めたら、再発防止策を実施します。実施のためには、検証作業や手順書作成、日程調整などが必要になります。
お客様にて再発防止策を実施する場合のポイント
お客様にて再発防止策をする場合のポイント
まず、一度起きた事象は必ず二度目が発生すると考えるようにしましょう。再発防止策はもちろんですが、最低でも再発した時に復旧対応できるような準備をしておくと安心です。
再発防止策で最も重要なのは、原因特定です。メモリ不足の対策で、CPUを強化しても意味はありません。的外れな再発防止策は、「時間」「お金」「人的コスト」を大幅に無駄にします。正確に原因特定を行いましょう。
一度の調査では原因特定できない場合もあります。その場合は、再発時により詳細なデータが取得できるような仕掛けをしておきます。仮説を立てて、事前のデータ取得準備をしておきましょう。
再発防止策 失敗例
再発防止策失敗例
調査結果
お客様にて再発防止策を実施し改善しなかったため、ご相談いただいた例をご紹介します。
ECサイトを運営中のA社様。応答遅延が発生したため、WEBサーバーのスケールアウトで再発防止の対応をしました。原因特定はしていなかったそうです。事象が改善されなかったためディーネットへご相談いただきました。
ディーネットにて、リソース状況や各種ログを調べたところ、サーバーリソース以外の部分に問題があることがわかりました。外部サービスです。外部サービスの遅延によって、ECサイトが遅くなっていました。
外部サービスのベンダーと調整を行い、サーバー台数を戻すことで再発防止策としました。
クラウドはほぼ無制限にリソースを拡大していくことが可能です。しかしながら、リソース不足が根本原因でない場合は、いくらリソースを増やしても問題は解消しません。反対に状況が悪化する可能性すらあります。
クラウドを使いこなすためには、適切な調査と対応が必要です。
ディーネットのAWS運用代行サービスでは
ディーネットのAWS運用代行サービスでは
ディーネットのAWS運用代行サービスでは、熟練のエンジニアがお客様のシステムの稼働をサポートしております。
AWSのみならず、サーバー内のログなど多角的な調査から根本原因を特定していきます。その上で再発防止策を実施するので、非常に効果が高い対策をうつことが可能です。
技術的な対応はすべてディーネットが引き受けます。お客様は、対策実施可否の判断をしていただきます。
実施が決まった場合は、日程調整の上、ディーネットにて再発防止策を実施いたします。
関連するFAQ
Q. 一次対応と二次対応の違いは何ですか？
A. 一次対応はサービス継続のための応急処置、二次対応は再発を防ぐための根本解決です。一次対応だけでは原因が残るため、同じ障害が再発する可能性があります。
Q. 再発防止策で最も重要なポイントは何ですか？
A. 根本原因の特定ですが、「粒度」が重要です。現象（遅い）だけでなく、直接原因（メモリ不足）、さらにその原因（設計・負荷構造・外部依存）まで掘り下げて初めて有効な対策になります。
Q. 原因が特定できない場合はどうすればよいですか？
A. 無理に結論を出さず、次回発生時に特定できる状態を作ることが重要です。仮説を立てた上でログ取得や監視項目を追加し、「次は確実に捕まえる」設計にします。
Q. リソースを増やせば多くの問題は解決しますか？
A. いいえ。リソース不足が直接原因でない場合は効果がありません。外部サービス遅延やアプリケーション設計の問題であれば、いくらスケールしても解決しないどころかコストだけが増えます。
Q. 再発防止策をあえて実施しない判断はありですか？
A. あります。発生頻度・影響範囲・対策コストの3点で判断します。低頻度かつ影響が軽微で、対策コストが高い場合は「何もしない」が合理的なケースもあります。
Q. 原因が複数ある場合はどう考えるべきですか？
A. すべてを同時に解決しようとせず、影響度の大きい原因から優先順位を付けます。また「主因」と「誘因」を分けて整理すると、対策の順番が明確になります。
Q. 暫定対策と恒久対策はどう切り分けますか？
A. 再発確率と影響度が高い場合は、まず暫定対策でリスクを抑えつつ、並行して恒久対策を進めます。暫定対応だけで止めると、結果的に再発コストの方が高くつくケースが多いです。
Q. 再発防止策が失敗する典型例は？
A. 原因を特定せずに対策を決めるケースです。例えば外部サービスが原因なのにサーバーを増やす、といったミスマッチです。「とりあえずスケール」「ログを見ない推測」「一度の調査で確定」などが典型的な失敗パターンです。
まとめ
最後までご覧いただきありがとうございます
この記事では、再発防止策（二次対応）について解説しました。
メモリ不足の時はメモリを増やす必要があります。CPUを増強しても効果はありません。
再発防止策も同様で、調査で根本原因の特定を行い、その原因に対して対策を行う必要があります。的外れの対策を実施すると、「時間」「お金」「人的コスト」が無駄になります。
原因を特定し、適切な対策を取れるように気を付けましょう。