ネットワークのトラブルシューティング

構築・運用

ネットワークのトラブルシューティング、それはネットワークがうまく使えないといったトラブルが発生した場合に、何とかして使えるようにすることだ。現象の把握から始まり、原因箇所の特定、原因の推定、対策方法検討、対策実施といった手順になろう。ネットワークに限らず、すべてのトラブルに通用する王道の手順だ。エンジニアにとってトラブルの調査や対策は腕の見せ所だ。
まず、何らかの通信トラブルが発生したとして、現象の把握から考えてみる。

現象の把握
原因箇所の特定
原因の推定
対策方法検討
対策実施
確認試験

現象の把握

何が起こったのか、起こっているのか事実関係を正確に捉える。

通信トラブルが発生

いつ、何が、どのような条件で、どうなったのかヒアリングする。これらを明確にすることが真っ先であり、最も重要である。トラブルの内容を時系列で、できるだけ多くの現象を挙げたい。後々後戻りしなくて済むように手順良く進めるためである。時系列や現象があいまいなら、そういった補足（おそらく・・・であった）を加えておく。記憶や情報が残っている内に記録として残しておきたい。ここで忘れてはならないことは、うまくいっている通信についても整理して残しておくことだ。それは、後々切り分け作業を行う時に必ず役に立つ情報となる。正常と異常の分水嶺（時間、場所、通信量、通信プロトコルレイヤー、操作内容など）に近い情報がより役に立つ。
当然のことではあるが、都合の悪いことは記録に残さないというようなことは無しにしよう。

原因箇所の特定

次は原因箇所の特定、つまり原因調査となる。それには、何が起こっているのかを正確に突きとめる必要がある。では、どうすればいいか。まずは切り分けだ。これまでに発生した障害（何々がうまくいかない）を時系列で列挙する。残るように何かに書くのがいいだろう。そして、何がうまくいって、何がうまくいかないのか、細かく調べていく。そうして原因の範囲（トラブルが発生する条件）を絞っていく。状況によっては、システム開発エンジニアなどのSEや他社の協力を求める場合もあるだろう。絞り切れない場合には、現象の把握に戻ってさらに情報を集めてから、再度切り分けを行う。どんどん情報が積み重ねられることになるが、同時にトラブルの原因箇所を少しずつでも明確にしていきたい。

ここで注意したいことだが、特定の機器が単に疑わしいとなってもこの時点で機器を交換するなど、まだやってはいけない。設定条件を変えてどう変わるか見てみることもやってみたいが我慢する。最終的に原因を突きとめた後に対策方法として行うのであれば良いが、調査の段階で試すようなことは、現状に対してむやみに変更を加えることとなり、トラブル現象が発生しなくなってしまい、いつの日か再発することになるからだ。接触不良、電源電圧変動、振動、ノイズなど、不安定な原因は見えにくいので細心の注意が必要だ。真の原因を突きとめていない時点では気を付けたい。

原因の推定

ヒアリングから原因の切り分け作業まで実施してきたが、ここまで来ると多くの情報を元に原因がかなり絞り込めているはずだ。原因を絞り込むとは、複数の要因から一つの原因を想定するということだ。
例えば単純な例だが、端末が多数あって、その内１台だけがうまくいかない場合、その端末のみが原因を抱えているという想定だ。この場合、端末のせいだからこちら（ネットワーク）が悪いのではないと思っても、確証が得られるまでは断定的な表現は控えよう。逆に端末が多数あって、そのすべてがうまくいかない場合、すべての端末というよりも、間をつなぐネットワークが原因を抱えているという想定だ。これらの想定はあくまで見かけ上かもしれない不確かな想定だ。可能性は高いが、まだまだ結論とはいえないこともあるだろう。
いろいろな状況に応じてさらに詳しく突きとめる必要がある。地道な作業だ。通信トラブルは単純な原因ではないことが多いからだ。

トラブルの原因を推定する考え方の例を挙げてみる。
端末、ネットワーク、サーバー、その他のシステムなど、これらのいずれかあるいは組み合わせにより発生したトラブルの要因はこんな感じだ。原因が一つではないことを踏まえ、いくつかの要因を考える。

　　推定要因１：設定上の問題（IPアドレス不整合）
　　推定要因２：インターフェース不一致（仕様不適合）
　　推定要因３：トラフィック過大（処理能力オーバー）
　　推定要因４：通信トラフィック内容の不一致（プロトコル不一致）
　　推定要因５：その他（不明）

どんな要因であってもこのように考えられる要因を初めから挙げてみることだ。不要となったら斜線などで消せばいい。足りないと分かったら追加だ。

厄介なのは、どうしても分からない時だ。何が起こっているのかも分からない場合もあるだろう。それでも調べることは尽きない。あきらめずに調べを進めるに限る。できれば、障害の現象を発生させて通信の内容を見てみることだ。そのためにネットワークエンジニアが知っておかないとならないのは特にTCP/IPプロトコルの基本、ARPとICMPだ。それは基本スキルつまり、習得必須スキルであり、重要スキルである。それから、通信データのプロトコル解析だ。筆者は後に得意となるほどこのプロトコル解析を実施したが、時間と手間がかかり、かなり面倒なので最後の手段に近いという感覚で対応していた。
原因が明確になった時は先に進めるという意味で一瞬であるが視界が開ける。原因を正しく突きとめれば、トラブルシューティングの半分以上は済んでいるといえよう。

対策方法検討

原因が明確になれば、後は対策だ。応急対策と恒久対策がある。目の前の障害を回避すべく急いで行う応急対策と、きれいに原因を除去して再発防止策を練りこんだ恒久対策だ。利用者の都合や要望を聞いて丁寧に対応することだ。構築のように何度かに分けて対策する場合もあるだろう。

対策実施

対策方法が決まれば、対策の実施だ。ネットワークに問題があったのであれば、ネットワーク構築のような作業が発生する。ネットワークエンジニアとしては大変な原因調査を終えたところで一息入れたいところであるが、気を抜かずに進めたい。

確認試験

ひととおりの試験を行う。トラブルが発生した時の現象が収まったかどうかはもちろん、問題なかった通信の確認も行い、すべて問題なく通信できることを確認する。

確認試験の結果が良好であれば、トラブルシューティングはうまくいったことになる。通常は何らかの報告書としてまとめることになるが、これまでの経緯をきちんとまとめればいい。それには、振り返ってみて何が良くなかったのか、それと、再発防止や今後の課題なども含めるといいだろう。

ネットワークのトラブルシューティングについて、一連の手順をまとめたが、これらはネットワークエンジニアとしては貴重な経験だ。繰り返し同じようなトラブルが発生しないようにすることが、ネットワークを構築した関係者それぞれの責務であろう。

原因がネットワークにあるかどうかさえ分からない現象が発生した時に、ネットワークに関わるエンジニアが調査して、ネットワークの問題ではなかったという場面もあるだろう。そんな時でもきちんと切り分けし、ネットワークの問題ではなく、例えば端末機器の設定であるとか、使い方の問題であるとか、他の要因であってもネットワークエンジニアは責任を持って対応したい。