【現場直伝】ネットワーク障害の切り分けフロー｜原因特定から再発防止まで
「ネットワークが繋がらない」——この一言ほど、エンジニアの心拍数を上げる言葉はそうありません。笑
障害対応で一番やってはいけないのは、「なんとなく怪しいところをいじり始める」ことです。経験が浅い頃、焦るあまり原因もわからないまま機器を再起動して、状況をさらに悪化させた…という話は現場あるあるです。
私が障害対応で意識するようにしたのは、「動く前に情報を集める」というシンプルな原則です。まずシステムの設計や前提情報を確認し、現状と照らし合わせる。ログやエラーから原因を絞り込んでから、初めて対処に移る。この順番を守るだけで、復旧スピードが別次元に変わります。
この記事では、現場で実際に使っている障害切り分けのフローと、便利なツールを丸ごと解説します。
障害対応の大原則——「動く前に考える」
障害対応には、大きく4つのフェーズがあります。
- ① 基本情報の確認：システムの設計・構成・前提条件を把握する
- ② 現状把握：今何が起きているのかを具体的に確認する
- ③ 原因の絞り込み：ログ・エラー・監視データから原因を特定する
- ④ 対処・復旧：原因に対して適切な対応を実施する
特に①と②を省略してしまうと、見当違いな場所を調査し続けるという時間の無駄が発生します。「急がば回れ」は障害対応の鉄則です。
フェーズ1：基本情報の確認
障害対応の出発点は、「このシステムは本来どう動くべきか」を理解することです。
- ネットワーク構成図・設計書の確認
- 影響を受けているシステム・サービスの把握
- 障害発生直前の変更履歴（デプロイ・設定変更・機器交換など）
- 過去に同様の障害が発生していないか
「直前に何かしましたか？」という質問は、障害対応の王道です。設定変更・ファームウェアアップデート・新しい機器の導入——これが原因であることが驚くほど多い。変更履歴を確認するだけで、調査時間が半分以下になることもあります。
フェーズ2：現状把握と影響範囲の特定
「繋がらない」という報告だけでは情報が足りません。以下を具体的に確認します。
- 影響範囲：特定のユーザーだけか、部署全体か、全社か
- 影響サービス：特定のアプリだけか、インターネット全体か
- 発生時刻：いつから発生しているか
- 再現性：常に発生するか、断続的か
- エラーメッセージ：具体的に何と表示されているか
この情報を集めるだけで、「どの層で問題が起きているか」がある程度見えてきます。例えば「特定のWebサイトだけ繋がらない」なら DNS や アプリ層が怪しい。「社内ネット全体が落ちている」ならルーターやスイッチを疑う——という具合です。
焦っているときほど「とりあえず再起動」をやりたくなりますが、まずここで5分使う方が結果的に早く解決できます。
フェーズ3：切り分けの基本——物理層から上位層へ
業務での障害対応は、担当範囲が決まっていることが多いですが、切り分けの基本思想は共通しています。
物理層（L1）から上位のアプリ層（L7）に向かって、順番に確認していくのが鉄則です。
- L1（物理層）：ケーブルの抜け・断線・ランプの状態確認
- L2（データリンク層）：スイッチの状態・MACアドレステーブル
- L3（ネットワーク層）：IPアドレス・ルーティングテーブル・pingで疎通確認
- L4（トランスポート層）：ポートの開放状態・TCP/UDPの接続確認
- L7（アプリケーション層）：アプリのログ・DNS・HTTPレスポンス
「物理から上へ」の順番で確認することで、上位層の問題に見えて実は物理ケーブルが抜けていた——という恥ずかしい見落としを防げます。笑 現場では意外とこれが多いです。
フェーズ4：使えるツール一覧
障害切り分けで実際に使うツールを紹介します。
コマンドラインツール（iTerm / ターミナル / CMD）
基本はターミナル（Mac）やコマンドプロンプト・PowerShell（Windows）です。iTerm2を使っているエンジニアも多いですね。ここで以下のコマンドを打つことが多いです。
ping [IPアドレス]：疎通確認の基本。応答があるかどうかで生死確認tracert / traceroute [IPアドレス]：どの経路を通っているか・どこで止まっているかを可視化nslookup [ドメイン]：DNS解決の確認netstat：現在の通信状態・ポートの使用状況を確認ipconfig / ifconfig：IPアドレスの確認
pingとtracerouteだけでも、かなりの部分まで原因を絞り込めます。まずこの2つを打つのが、障害対応のファーストステップです。
パケットキャプチャ：Wireshark
ネットワーク上を流れる通信データを詳細に分析できるツールです。「pingは通るのになぜか遅い」「断続的に切断される」といった、コマンドだけでは追えない問題の切り分けに使います。
TCPの再送パケットが多発していればパケットロスが疑われる、特定のIPとの通信だけ異常であればその経路に問題がある——といった判断ができます。ただしキャプチャデータが膨大になるので、障害発生時刻前後に絞って分析するのがコツです。
外部障害確認：Cloudflare Radar
「自分のネットワークじゃなくて、インターネット全体の問題では？」と疑うときに使います。世界規模のインターネットトラフィックの状況を可視化してくれるので、プロバイダや外部サービス側の障害を素早く確認できます。「こちらは何も悪くなかった」を証明するのにも役立ちます。笑
監視ツール：Zabbix / OpManager
IT企業の現場で定番の監視ツールです。サーバー・ネットワーク機器のCPU・メモリ・トラフィックをリアルタイムで監視し、閾値を超えたらアラートを飛ばしてくれます。
障害対応時は、まずこれを開いて「どの機器がおかしいか」の全体像を掴むところから始めます。ただし、監視ツールが「正常」を示していても油断は禁物。個々の機器の細かい挙動まではカバーしきれないことがあるので、異常を感じたら深掘りが必要です。
フェーズ5：関係者への報告フロー
技術的な切り分けと並行して、関係者への報告も忘れずに。情報が遅れると関係部署が独自に動き出し、情報が錯綜するという二次災害が起きます。
- 初期報告（発生直後）：「何が起きているか」と「影響範囲」だけでもすぐ共有。原因不明でもOK
- 状況報告（調査中）：進捗と暫定的な復旧見込みを定期的に連絡
- 復旧報告（復旧後）：原因と再発防止策をセットで共有
「まだ何も分かっていない」と報告を遅らせるのが一番よくないパターンです。断片的な情報でも早めに共有することで、組織全体の動きがスムーズになります。
フェーズ6：原因分析と再発防止策
復旧したら終わり——ではありません。同じ障害を繰り返さないために、振り返りが重要です。
- 設定変更時のレビュー体制強化：複数人チェック・承認フローの導入
- 定期的なヘルスチェック：障害予兆の早期検知のための監視強化
- 対応手順書の更新：今回の教訓を反映した実践的な手順書に見直す
- 関係部署との情報共有：過去の障害事例を定期的に勉強会で共有
障害対応の記録をしっかり残しておくと、次回似たような障害が起きたときに「あの時と同じパターンだ」と気づけます。これが経験値として積み上がっていく、エンジニアとしての成長サイクルです。
まとめ
ネットワーク障害の切り分けフローをまとめます。
- まず基本情報・変更履歴を確認してから動く
- 影響範囲・発生時刻・再現性を具体的に把握する
- 物理層（L1）から上位層（L7）に向かって順番に切り分ける
- ping・traceroute・Wireshark・Zabbixを状況に応じて使い分ける
- 報告は断片的でも早めに、復旧後は再発防止策をセットで
障害対応は「知識」と「落ち着き」の両輪です。フローを頭に入れておくだけで、焦りが減り、判断が速くなります。
「繋がらない」の一言に動じない、頼れるエンジニアを目指しましょう。