ネットワークのトラブルシューティング方法論:系統的アプローチ

方法論のマットレスの理由

問題: データベースアプリケーションは「スロー」です。ネットワークチームは、サーバーチームを責めています。サーバチームはネットワークを非難します。一方、ユーザーは不満で、時間は円のデバッグで浪費されます。

ソリューション: 証拠、仮定ではなく、根本原因を識別するために、証拠を使用するトラブルシューティングに対する体系的、科学的アプローチ。

ハプハザードのトラブルシューティングのコスト: 無駄な時間, 誤った修正は、実際の問題をマスクします, チーム間で指を指す, 劣化したユーザーエクスペリエンス.

はじめに:ネットワークに適用される科学的方法

ネットワークのトラブルシューティングは、基本的に科学的方法の演習です。

オブザーブ 症状とデータ収集
仮説を形成する 根本原因について
仮説をテストする 診断用具を使って
結果の分析 仮説の確認や拒否
修正の実装 確認された根本原因に基づく
検証問題は解決されます

この記事では、一般的な下落を防ぐネットワークトラブルシューティングのための構造フレームワークを提供します。

確認バイアス(最初の推測をサポートする証拠だけを探します)
診断なしでランダムな変化(「スプレーと祈り」のアプローチ)
根本原因の代わりに症状を修正
試したものを文書化することなく、円のデバッグ

5つの主要な質問

技術的な診断に潜入する前に、これらの5つの重要な質問に答えて、調査範囲を絞り込みます。

質問1:最近何が変化したのか?

設定の変更? 新しいハードウェア? ソフトウェアの更新? トポロジーの修正?

変更管理ログの確認
コンフィギュレーション管理システムで最近のコミットを確認する
「昨日働いているの?」

質問2:誰が影響を受けますか?

1つのユーザー? 1棟? みんな? 特定のアプリケーションのみ?

1つの装置: ローカルの問題と同様に(NIC、ケーブル、設定)
1つのサブネット: ゲートウェイ、DHCP、スイッチの問題
みんな: コアインフラ、ISP、ワイドスプレッドの問題
特定のアプリ: アプリケーションサーバ、ファイアウォールルール、またはDNS

↓

質問3:定数または断続的ですか?

いつもお役に立ちますか? 特定の時間だけ? ランダムな発生?

定数: 故障(ケーブルカット、誤設定、ダウンサービス)
タイムベース: 営業時間、スケジュールされたプロセスの間の混雑
断続的/ランダム: 複式アパートの不一致、ハードウェア、断続的なリンク失敗

↓

質問4:それを再生産できますか?

問題が発生しますか?

はい: 診断が容易 (仮説をテストできます)
いいえ: 監視/ログを設定し、再発を待ちます

↓

質問5: 他の側面が見えるのは何ですか。

接続の両端を確認してください

クライアントの視点とサーバーの視点
ソースと目的地のパケットキャプチャ
対称ルーティング? 送信対. 受信のための異なるパス?

OSIモデルベースの診断アプローチ

OSIモデルはトラブルシューティングのための構造化されたフレームワークを提供します。レイヤー1(物理)上方、またはレイヤー7(アプリケーション)下方から、症状に応じて動作します。

ボトムアップアプローチ(層1→層7)

使用する場合: 完全な接続損失、リンクライト無し、または物理的な層の徴候

層 1: 物理的

チェック: ケーブル接続? ライトをリンクしますか? 繊維はきれいですか。
コマンド: show interfaces, ethtool eth0
参照してください:CRCのエラー、衝突、遅延衝突、暴動、巨人

↓

レイヤー2:データリンク

チェック: 正しいVLAN? ポートが有効になっていますか? STPブロック?
コマンド: show mac address-table, show spanning-tree
参照して下さい: MACの折り返し、STPのトポロジーの変更、VLANの不一致

↓

層3:ネットワーク

チェック: デフォルトのゲートウェイをpingできますか? ルーティングテーブルは正しいですか?
コマンド: ping, traceroute, show ip route
参照: ルートを欠く、次のホップ、ルーティングループを誤った

↓

層4:輸送

チェック:TCP接続を確立できますか? ファイアウォールブロックポート?
コマンド: telnet host port, netstat -an, パケットキャプチャ
参照して下さい:TCPのretransmissions、ゼロ窓、RSTのパケット

↓

レイヤー5-7:セッション/プレゼンテーション/アプリケーション

チェック: DNS の解決? アプリケーション対応? 認証作業?
コマンド: nslookup, dig, curl -v
参照:DNSの失敗、アプリケーションエラー、タイムアウトの問題

トップダウンアプローチ(層7→層1)

使用する場合: 基本的な接続が存在するアプリケーション固有の問題

例: 「インターネットを閲覧できますが、SharePointサイトにアクセスできません。」

レイヤー7(SharePointサービスが稼働していますか?) DNS は IP を正しいかを解決し、必要な場合にのみダウンします。

決定ツリー:レイヤー1、2、3ですか?

このクイック診断ツリーを使用して、どのレイヤーが失敗しているかを識別します。

ローカルホスト(127.0.0.1)をpingできますか?

↓ いいえ

問題:オペレーティングシステム/ソフトウェアの問題

TCP/IP スタックが機能しない OSサービスをチェックし、ネットワークドライバを再インストールします。

↓ はい

自分のIPアドレスをpingできますか?

↓ NO

問題:層1/2 -ローカルネットワークインターフェイス

NIC は、間違った運転者、ケーブルプラグを外しました。チェック: ip link show デバイスマネージャー

↓ YES

デフォルトのゲートウェイをpingできますか?

↓ NO

問題:層1/2 - ローカルネットワーク

チェック: 物理的なケーブル、スイッチポートの状態、VLANの割り当て、ARPのテーブル

↓ YES

IPアドレスでリモートホストをpingできますか?

↓ NO

問題: 層 3 - ルーティング

チェック: ルーティングテーブル、ファイアウォールルール、ACL 使用条件 traceroute パケットが停止する場所を見つける

↓ YES

DNS(nslookup hostname)を解決できますか?

↓ NO

問題: DNS の構成

チェック:DNSサーバーの設定、DNSサーバーの可用性、ファイアウォールブロックポート53

↓ YES

アプリケーションポート(telnetホストポート)に到達できますか?

↓ NO

問題: 防火壁/港の妨害

チェック:ファイアウォールルール、セキュリティグループ、ポートを聴くサービス

↓ YES

ネットワークがOK - アプリケーション層の問題

アプリケーション自体、認証、またはアプリケーション設定の問題

分離の技術

根本原因に関する仮説がある場合、これらの分離技術を使用して確認または拒否します。

1. 部品を系統的に取り替えて下さい

ヒント: 一度に1変数を変更します。ケーブルとスイッチポートの両方を交換すると、その固定がわかりません。

有名なよいケーブルが付いているスワップパッチケーブル
別のスイッチポートのテスト
異なるNIC(またはUSBネットワークアダプタ)を試してください
異なるクライアントデバイスからのテスト
異なるVLAN/サブネットに移動

2. 複数のポイントでのパケットキャプチャ

ソース、中間点、宛先でトラフィックをキャプチャして、パケットがドロップまたは変更された場所を特定します。

# Capture on client
tcpdump -i eth0 -w client.pcap host server.example.com

# Capture on server
tcpdump -i eth0 -w server.pcap host client.example.com

# Compare:
# - Do packets leave client? (check client.pcap)
# - Do packets arrive at server? (check server.pcap)
# - If yes/no: problem is in the path between
# - If yes/yes but server doesn't respond: server-side issue

3. ループバックのテスト

外部変数を単一デバイス内の接続をテストすることで排除します。

# Test TCP stack without network
ping 127.0.0.1

# Test application listening locally
telnet localhost 80

# Test loopback on network interface (if supported)
# Some NICs support physical loopback for Layer 1 testing

4. 既知のベースラインの比較

作業システムに対する構成と動作を比較します。

# Compare interface settings
diff <(ssh working-switch "show run int gi1/0/1") \
     <(ssh broken-switch "show run int gi1/0/1")

# Compare routing tables
diff <(ssh router1 "show ip route") \
     <(ssh router2 "show ip route")

トラブルシューティング中にドキュメント

適切な文書は、それを実現せずに複数の時間を試すと、円のデバッグを防ぐことができます。

テンプレートのトラブルシューティング

Issue ID: TICKET-12345
Date/Time: 2026-02-02 14:30 UTC
Reported By: Jane Smith (jane.smith@company.com)
Affected Users: ~50 users in Building A, 3rd floor
Symptom: Cannot access file server \\fileserver01

Initial Observations:
- Issue started around 14:00 UTC
- Only affects Building A, 3rd floor
- Other buildings can access fileserver01
- Ping to fileserver01 (10.1.50.10) times out from affected users
- Ping to default gateway (10.1.30.1) succeeds

Tests Performed:
1. [14:35] Checked switch port status: gi1/0/15 is UP/UP
2. [14:38] Checked VLAN assignment: Port is in VLAN 30 (correct)
3. [14:42] Checked interface errors: 1,234 CRC errors on gi1/0/15
4. [14:45] Replaced patch cable - still seeing CRC errors
5. [14:50] Moved uplink to different port (gi1/0/16) - errors persist
6. [14:55] Checked fiber cleanliness - dirty connector found

Root Cause:
Dirty fiber connector on uplink between Building A floor switch
and distribution switch causing CRC errors and packet loss

Resolution:
Cleaned fiber connector with proper cleaning kit. CRC errors
dropped to zero. File server access restored.

Verification:
Users confirmed file server accessible. Monitored for 15 minutes
with no errors.

Time to Resolution: 25 minutes

なぜドキュメントマター: このレコードがなければ、そのスイッチにCRCのエラーが表示されると、ケーブルやテストポートを交換する時間が無駄になる可能性があります。

リアルワールド・ケース・スタディ

事例1:「ネットワークはスロー」(実際には:TCPウィンドウの排気)

シンプトム

データベースのアプリケーション応答時間は、<100ms〜5秒に分解されます。「ネットワークレイテンシ」を非難

初期仮定(間違った)

ネットワーク輻輳
WANリンク飽和
ファイアウォールボトルネック

診断プロセス

ピンテスト: RTT = 2ms(連続、レイヤー3レイテンシを除外)
帯域幅テスト(iperf): 1 Gbps リンクの 950 Mbps (混雑無し)
パケットキャプチャ: データベースサーバからTCP Zero Windowパケットを回復
サーバー点検: データベースサーバがバッファを受け取る = 64KB (tiny!)

根本原因

データベースサーバ OS バッファは、帯域幅 × 遅延製品に対しても小型化しました。 TCPウィンドウは、送信者を強制的に待機します。

ソリューション

# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216

レッスン学習

想定しない: 「遅い」は「ネットワークレイテンシー」という意味ではありません。結論にジャンプする前に、常に証拠(レイテンシー、行動のためのパケットキャプチャ)を集めます。

ケーススタディ2:断続的なコネクティビティ(実際には:デュプレックス・ミスマッチ)

Symptom

サーバー接続は、特に負荷下で、ランダムにドロップします。時には、完全に反応しなくなることがあります。

Initial Assumptions (Wrong)

故障 NIC
悪いケーブル
ハードウェアの問題の切り替え

Diagnostic Process

インターフェイス点検: サーバー NIC = 1000/Full、スイッチポート = 1000/Half (mismatch!)
エラーカウンター: スイッチポートの大規模な衝突カウント
レイトの衝突: 二重不一致の表示器

Root Cause

自動交渉は失敗しました。サーバーは双方向通信を交渉し、スイッチは半二重に戻って落ちました。両側が同時に送信しようとすると、衝突は負荷下でのみ発生します。

Resolution

! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
 speed 1000
 duplex full

Lesson Learned

両端をチェック: インターフェイスの状態は交渉された設定を示します。不一致とは、自動交渉が失敗することを意味します。常にサーバーのためのハードコードの速度/複式アパート。

ケーススタディ3:「特定のウェブサイトにリーチできない」(実際には:MTU/PMTUDブラックホール)

Symptom

一部のウェブサイト(Google、Yahoo)を閲覧できますが、他のウェブサイト(銀行ウェブサイト、会社ポータル)では閲覧できません。小さな HTTP リクエストが機能し、大きなページがタイムアウトしました。

Initial Assumptions (Wrong)

DNSの問題
特定のサイトをブロックファイアウォール
ISPルーティングの問題

Diagnostic Process

DNSの解像度: すべてのサイトが正常に機能する
ピンテスト: "unreachable"サイトをpingすることができます
小さいHTTP (要求カール): 小さなページのために働く
大きいダウンロード: TCPハンドシェイク後のストール
MTUテスト: ping -M do -s 1472 成功, ping -M do -s 1473 失敗
ICMPの監視: 「Fragmentation Needed」(Type 3 Code 4) のメッセージを受信しない

Root Cause

VPN トンネルは MTU を 1400 に減らしましたが、ファイアウォールは ICMP 「フラグメンテーションニーズ」メッセージをブロックしました。パスMTUディスカバリー(PMTUD)は、MTUの黒い穴を作るために動作できませんでした。小さいパケットは、DFビットセットの大きなパケットがサイレントに落ちていました。

Resolution

! Implemented TCP MSS clamping on router
interface Tunnel0
 ip tcp adjust-mss 1360

! Alternative: Allow ICMP Type 3 Code 4 through firewall
access-list 101 permit icmp any any packet-too-big

Lesson Learned

サイズの問題: 小さなリクエストがうまくいくが、大きな転送が失敗すると、MTU/fragmentationの問題が疑われる。 DF ビットで ping を使用してパス MTU をテストします。

ケーススタディ4:VoIP品質の問題(実際には:QoSの構成)

Symptom

音声通話は、音声、断続的なドロップアウトが刻まれていました。営業時間(午前9時～午後5時)にのみ発生します。

Initial Assumptions (Wrong)

十分な帯域幅
VoIPサーバーの積み過ぎ
ISP接続品質

Diagnostic Process

帯域幅テスト: 混雑時は40%しか利用できないリンク
QoSの点検: DSCP EF(46)が正しくマークされた音声トラフィック
急な点検: 音声キューは帯域幅が5%だけであった(33%)
パケットキャプチャ: 混雑時にパケットを落とす

Root Cause

QoSの方針は存在しましたが、帯域幅の配分は後方にありました:最高効果は60%を得ました、声は5%を得ました。データトラフィックが増加した営業時間中は、キューオーバーフローにより音声パケットが低下しました。

Resolution

! Corrected QoS policy
policy-map WAN-QOS
 class VOICE
  priority percent 33
 class VIDEO
  bandwidth percent 25
 class CRITICAL-DATA
  bandwidth percent 20
 class class-default
  bandwidth percent 22

Lesson Learned

時間ベースの問題 = 容量: 忙しい時間帯に問題が起きた場合、故障ではなく、容量/QoSの問題です。キューの統計情報をチェックするだけでなく、総帯域幅。

Symptom によるコマンド参照

シンプトム	レイヤー	コマンドを実行する	探すべきこと
リンクライトなし	層 1	`show interfaces ethtool eth0`	状態: 、キャリア無し、ケーブルのunplugged
パケットロス	層 1/2	`show interfaces show interfaces counters errors`	CRCのエラー、ラン、巨人、衝突、遅延衝突
ゲートウェイをpingできません	レイヤー2	`arp -a show mac address-table show spanning-tree`	ARPエントリーなし、MACは学習しない、STPブロック
リモートサブネットに到達できません	層 3	`traceroute show ip route show ip route summary`	ルートを欠く、次のホップ、ルーティングループが間違っている
接続拒否	層 4	`telnet host port netstat -an tcpdump`	聴くことのないサービス, ファイアウォールブロック, TCP RST
スローパフォーマンス	層 4+ (44)	`ping (RTT) iperf3 tcpdump show interfaces`	高レイテンシ、帯域幅制限、TCPの送金、ゼロウィンドウ
hostname を解決できません	層 7	`nslookup dig cat /etc/resolv.conf`	DNSサーバーが到達不能で、DNSの設定が間違っている、NXDOMAIN
断続的な低下	Layer 1/2	`ping -f (flood) show logging show interfaces`	複式アパートの不一致、ケーブル、STPの再構成失敗
他の人ではなく、時々働く	複数の	`Extended ping Packet capture Interface statistics`	負荷分散問題、ECMPのasymmetry、州のテーブルのoverflow

Escalate のとき

ベンダー TAC またはシニアエンジニアにエスカレーションするときを知っている。ときにエスカレート:

知識ベースでトラブルシューティングの手順をすべて疲れていました
問題は、あなたが持っていないアクセス/許可を必要とします
問題は、ベンダーソフトウェアのバグやハードウェアの不具合を含む
業務への影響は極めて重要で時間感度が高い
複数のチームがコラボレーションする必要があります(アプリケーション+ネットワーク+サーバー)

エスカレーションの前に: 試したすべてのものを文書化します。 TAC エンジニアは、この情報を必要としています。含まれる:

完全な症状の説明
発行開始時刻
診断コマンドの実行と出力
設定バックアップ
パケットキャプチャ(関連する場合)
すでに試したこと

パーソナルナレッジベースの構築

トラブルシューティングは学習機会です。個人的な知識ベースを構築する:

1. トラブルシューティングジャーナルを作成する

# Example structure
~/troubleshooting-journal/
├── 2026-01-15-duplex-mismatch.md
├── 2026-01-22-mtu-black-hole.md
├── 2026-02-02-tcp-window-exhaustion.md
└── README.md  # Index of all issues

# Each file contains:
# - Symptom
# - Diagnostic steps
# - Root cause
# - Resolution
# - Lessons learned
# - Related tickets/documentation

2. コマンドチートシートを作成する

トラブルシューティング中に素早く参照するためのシナリオで頻繁に使用されるコマンドを整理します。

3. ネットワークを文書化

トポロジー図(レイヤー2とレイヤー3)
IPアドレススキームの文書
VLANの割り当て
標準構成(テンプレート)
既知のベースライン(問題前のインターフェイス統計)

避けるべき共通の反パターン

××DON'T:診断なしでランダムな変化を作る

問題を理解しずに構成を変更すると、多くの場合、物事が悪化したり、実際の問題をマスクしたりします。

DON'T:ネットワークを障害で常に仮定して下さい

多くの場合、「ネットワークの問題」は、アプリケーション、サーバー、またはクライアント側の問題です。非難を受け入れる前に証拠を収集します。

〇 DON'T:トラブルシューティング手順の文書化をスキップする

既に行ったテストを繰り返す時間を無駄にするか、試した同僚に説明できないか。

〇 DON'T: 断続的な問題を無視する

断続的な問題は、多くの場合、障害の早期警告兆候です。重要になる前にそれらを調査します。

〇 DON'T: 根本原因の代わりに症状を修正

デバイスを再起動すると、サービスを復元する可能性がありますが、再起動が必要なWHYが見つからない場合、問題は再発します。

概要:システム障害チェックリスト

✓ 始める前に

5つの重要な質問に答える(変更されたこと) 誰が影響を受けますか? 定数または断続的? Reproducibleか。反対側は何が見えますか?
初期症状とユーザーレポートの収集
最近の変更やメンテナンスの確認

✓ トラブルシューティング中に

OSIレイヤー(ボトムアップまたはトップダウン)による作業方法論
テスト時に1変数を一度に変更する
すべてのテストと結果の文書化
パケットキャプチャを使用して実際のトラフィックの動作を確認します
既知のベースラインと比較

✓ 決断の後

実際に問題を解決した問題を修正
文書の根本原因と解像度
知識ベースの更新
設定が変更された場合、ドキュメントの更新
考慮: 監視は、この先ほどキャッチした?

コンテンツ

ネットワークのトラブルシューティングは、科学と芸術の両方です。科学は、診断ツールを正しく使用し、プロトコルを理解する、系統的な方法論に従います。体験からパターンを認識し、エスカレーションをするときに知る、症状に基づいて最初に実行するテストがわかっています。

この記事で概説した系統的アプローチに従うことで、正しい質問をすることで、OSIモデルを操作し、手順を文書化し、各問題から学習することで、トラブルシューティングでより効率的になり、無駄な時間と誤った修正につながる一般的な落とし穴を回避します。

覚えている: 目標は、サービスを復元するだけでなく、WHYが失敗したことを理解するため、再び起こっているのを防ぐことができます。

最終更新日: 2026年2月2日 | 投稿者: Baud9600 テクニカルチーム