システム障害発生！インフラエンジニアが語るトラブルシューティングの思考プロセス

本番環境で障害が発生した瞬間、あなたはどう動きますか？
「えっ…今？」「とりあえず再起動？」といった焦りや衝動的な行動は、多くのエンジニアが一度は経験しているはずです。

しかし、インフラの現場では、慌てて手を動かすことが一番危険です。
誤った操作で症状を悪化させたり、原因を特定できないまま復旧してしまい、再発防止策が立てられなくなることもあります。

そこで今回は、インフラエンジニアが実際に障害対応で使っているトラブルシューティングの思考プロセスを、ステップごとに整理してご紹介します。
この流れを頭に叩き込んでおけば、いざというときにも落ち着いて行動できるはずです。

1. 正確な状況の把握 〜まずは5W1Hで〜

障害対応の第一歩は「正確な状況の把握」です。
ここで情報があいまいだと、その後のすべての判断がぶれます。

筆者の経験談として、この1がずれていたために、後続の4で調査していたログが全く見当違いのものだったことがあります。
その際は無駄な時間を費やしてしまったと非常に後悔したものです。

上記の経験談を踏まえ、私は5W1H（When, Where, Who, What, Why, How）を意識すると情報整理がスムーズになると考えています。

• When（いつから）：発生時刻、現時点で障害が継続しているか否か
  
• Where（どこで）：特定のサーバ・ルータ、リージョン、サービス単位
  
• Who（誰が影響を受けているか）：全ユーザー、特定の顧客、社内のみ
  
• What（何が起きているか）：レスポンス遅延、接続不可、データ不整合
  
• Why（なぜ）：障害発生時は不明でも仮説だけ立てる
  
• How（どういう経路で発生しているか）：操作ログや監視ツールで確認
  

このように文章で整理してみるだけでも、ひとまず落ち着くことができ衝動的な行動は防げるものです。

ここでは「原因特定」よりも「事実の整理」が目的になります。
例えば、Slackでチームに報告する際も、このフォーマットで情報共有すると状況が伝わりやすくなります。

2. 問題箇所の切り分け 〜影響範囲を縮める〜

状況が把握できたら、次は問題箇所の切り分けです。
これは「どこが正常で、どこが異常か」を判別し、障害の範囲を狭めていく作業です。

障害が発生した環境によって方法は異なりますが、主に以下のようなものがあります。

切り分けの典型的な方法

• 物理層か論理層か：ハードの故障なのか、ソフトの故障なのか
  
• ネットワーク経路の確認：pingやtracertなどで到達性を調査
  
• サービス単位の確認：Webは落ちているがDBは生きている、など
  
• 比較対象を持つ：同構成の別サーバで再現するか
  

切り分けの目的は、「やみくもに全部見る」ことを避けるためです。
例えば、ロードバランサー配下の一部サーバだけが異常なら、そのサーバ固有の設定やリソースに注目できます。

3. 仮説立て 〜原因の可能性をリスト化〜

切り分けができたら、その範囲で起こりうる原因を洗い出します。
ここでは複数の仮説を並列に持つことが重要です。

仮説の立て方

• 最近の変更を確認：デプロイ、設定変更、OSアップデートなど
  
• 過去の障害履歴を参照：同じような症状はなかったか
  
• リソース状況を確認：CPU・メモリ・ディスク使用率、ネットワーク帯域
  
• 外部要因も考慮：クラウド側の障害、DDoS攻撃、ISPの問題など

上記のような要素をもとに、以下のような仮説を立てることができます。

仮説の具体例

• 最近のデプロイや設定変更による不具合
  
• メモリ不足によるサービス停止
  
• クラウドサービス側の障害

仮説は優先度を付けて検証します。
「再現性が高いもの」「影響が大きいもの」から調べると効率的です。

この仮説立ては経験値によるものが大きいと思います。
そのため、トラブルシューティングを始めたころは見当違いの仮説しか立てられなかったとしても心配する必要はありません。

4. 情報収集 〜仮説を検証し、原因を特定〜

仮説を立てたら、次はそれを裏付ける情報を集めます。
経験上、この段階で原因が見えてくることが多いです。

情報収集の具体例

• 監視ツールのデータ：OS(イベントログやSyslog)、ミドルウェア(Zabbix)、クラウド(CloudWatch) などで過去の傾向を確認
  
• システムログ：/var/log配下、アプリケーションログ
  
• ネットワークログ：Firewall、ロードバランサ、WAFのログ

重要なのは「情報を集めながら仮説を消していく」ことです。
例えば「CPUスパイクが原因ではない」と分かれば、その仮説は除外して次に進めます。

5. 対処 〜安全かつ再現性のある修正〜

原因が特定できたら、いよいよ対処です。
ここで大事なのは「安全に」「記録を残しながら」行うことです。
現場のメンバーだけでの対処が不安であれば、リーダーの監視のもとで行うことも有効な方法として挙げられます。

対処時の注意点

• 影響範囲を最小化：設定変更は一部サーバや検証環境で試す
  
• 手順を事前に確認：コマンドのタイプミスや予期しない挙動を防ぐ
  
• 変更履歴を残す：誰が、いつ、何をしたかを記録
  
• 復旧確認を怠らない：監視ツールやユーザーからのフィードバックで正常性を確認
  

対処後は必ず「なぜそうなったのか」を再確認し、再発防止策を検討します。

まとめ 〜慌てないための思考の型〜

本番環境での障害対応は、慣れていても心拍数が上がってしまうものです。
しかし、今回紹介した以下の流れを頭に入れておけば、冷静に行動できます。

1. 正確な状況の把握（5W1H）
   
2. 問題箇所の切り分け
   
3. 仮説立て
   
4. 情報収集で原因特定
   
5. 安全な対処
   

このプロセスは、ネットワーク障害、サーバ障害、アプリケーションの不具合など、どんなトラブルにも応用できます。
重要なのは、「慌てて手を出す前に頭を使う」ことです。
そして、対応が終わったら必ずナレッジとして残し、次に同じ状況が起きたときのスピードを上げることです。

障害対応は、経験を積むほど上手くなります。
最初は時間がかかっても、手順を守って落ち着いて進めれば確実に成長できます。
いざという時、冷静な判断ができるインフラエンジニアでありたいですね。