こんにちは、かつコーチです。
ネットワーク基礎編の最終回です。
IPアドレス、DNS、HTTP、TCP/UDP、OSI参照モデル、そしてping・tracerouteと積み上げてきた知識を、実際の障害対応の流れに落とし込みます。
上級者向けの内容なので、これまでの用語は前提知識として扱い、実践的な切り分けの進め方に絞って解説します。
ネットワークトラブルシューティングとは？
配達トラブルの原因切り分けという比喩
「荷物が届かない」というクレームが来たとき、優秀な配送担当者はいきなり原因を決めつけません。
まず「そもそも荷物は集荷されたか」「配送センターは通過したか」「最終の配達員まで渡ったか」と、配送網の上流から下流へ順番に確認していきます。
ネットワークトラブルシューティングも同じ発想で、OSI参照モデルの下位層（物理的に届く部分）から上位層（アプリケーションの中身）へ、順序立てて原因を切り分けていく作業です。
思いつきで疑わしい箇所を当てずっぽうに確認するのではなく、層ごとに「ここまでは正常」を積み上げていくことが、遠回りに見えて実は最短ルートになります。
なぜ手順立てて切り分ける必要があるのか
障害対応は、原因の可能性が無数にある中で進めることになります。
サーバー、ネットワーク機器、DNS、アプリケーションコード、外部サービス、どこに原因があってもおかしくありません。
手順を決めずに調査すると、同じ箇所を何度も確認したり、逆に確認すべき箇所を見落としたりしがちです。
下位層から上位層へと順番に確認する型を持っておくことで、チームで対応する際も「どこまで確認済みか」を共有しやすくなります。
基本の流れ：レイヤーごとに切り分ける
物理層〜ネットワーク層の確認
まず確認するのは、そもそも相手先まで経路が通っているかという、ネットワーク層（第3層）以下の疎通です。
# 対象サーバーへの疎通確認
ping -c 4 example.com
# 経路上のどこまで届いているかを確認
traceroute example.com
pingが失敗する、あるいはtracerouteが途中で止まる場合は、経路上のどこかに問題がある可能性が高いと判断できます。
自社の管理下にあるルーターやファイアウォールの設定、あるいはクラウド事業者側の障害情報も、このタイミングで合わせて確認します。
トランスポート層〜アプリケーション層の確認
下位層の疎通に問題がなければ、次はトランスポート層（第4層）以上、つまり目的のサービスが実際に応答しているかを確認します。
# 対象ポートが開いているか確認（443番＝HTTPS）
nc -zv example.com 443
# DNSの名前解決が正しく行われているか確認
dig example.com
nslookup example.com
# HTTPレスポンスの内容・ステータスコードを確認
curl -I https://example.com
nc -zvはポートへの接続可否、digやnslookupはDNSの名前解決結果、curl -IはHTTPレスポンスヘッダーとステータスコードを確認するコマンドです。
ここまでの確認で「DNSは正しいIPを返しているが、HTTPアクセスだけ失敗する」といった形で、問題の層がかなり絞り込めます。
よくあるつまずきポイント・実践的な切り分け例
「アクセスできない」の一報から原因を特定した経験
以前、運用中のサイトについて「お客様から急にアクセスできないと連絡が来た」という一報を受けたことがあります。
❌Before：いきなりサーバーを再起動して様子を見る
→ 原因が特定できないまま対応し、再発時にまた同じ手順を繰り返すことになる
✅After：下位層から順に確認する
1. ping → 応答あり（ネットワーク層は正常）
2. dig → 正しいIPを返している（DNSは正常）
3. curl -I → 503 Service Unavailableが返る（アプリケーション層で異常）
4. サーバーのリソース状況を確認 → メモリ枯渇によりアプリケーションプロセスが応答不能
このケースでは、pingとDNSが正常だったことで、ネットワーク経路やDNS設定ではなくアプリケーション側に原因を絞り込め、無駄な調査時間をかけずにメモリ増強で復旧できました。
もし手順を踏まずに「とりあえず再起動」で対応していたら、根本原因のメモリ枯渇に気づかないまま、同じ障害を繰り返していたはずです。
応用・一歩先の使い方
監視ツールで「気づく」までの時間を縮める
ここまでの手順は、いずれも障害に気づいてから手動で行う調査です。
実務では、これに加えて外形監視ツール（UptimeRobotやDatadogなど）でHTTPステータスや応答時間を常時監視し、異常を自動検知する仕組みを組み合わせるのが一般的です。
監視ツールがアラートを上げた時点で、この記事で紹介した手順（ping→DNS→ポート→HTTP）に沿って切り分けを始めれば、対応のスピードと再現性が大きく向上します。
日頃からこの型を意識して障害対応にあたることで、「まず何を疑うべきか」で迷う時間を減らせます。
まとめ
この記事のポイント
- ネットワークトラブルシューティングは「配達トラブルの原因切り分け」と同じく、下位層から上位層へ順序立てて確認する作業
- まずping・tracerouteでネットワーク層以下の疎通を確認し、次にDNS・ポート・HTTPレスポンスで上位層を確認する
- 手順を決めておくことで、原因の絞り込みが早くなり、チームでの情報共有もしやすくなる
- 監視ツールと組み合わせることで、障害に気づくまでの時間そのものも短縮できる
これでネットワーク基礎編（全15本）は完結です。
次に読むべき記事
- 次のシリーズでは、日々の開発・運用作業を効率化するシェルスクリプト編をお届けする予定です
タグ: ネットワーク, 上級者向け, トラブルシューティング
