ネットワーク・エンジニアがトラブルシューティング時に犯す間違いトップ 10 |NetScout

ネットワーク・エンジニアがトラブルシューティング時に犯す間違いトップ 10

ネットワークやアプリケーションの問題をトラブルシューティングする際に陥る可能性がある罠がいくつかあります。
このホワイトペーパーでは、そのうちの 10 個を紹介し、それらを回避する方法について説明します。

  • 目次
  • 思い込み
  • 再起動
  • アップグレード
  • 検証
  • ベースラインなし
  • 無線の課題
  • 不十分なモニタリング
  • コア・テクノロジーの理解
  • ノートパソコンの限界
  • まとめ 
 

100% のアップタイム?よし!

デスクトップの 10Gbps 接続?進捗は順調!

問題のないネットワークとアプリケーション?まさか。あり得ない。

ネットワークが完璧の域に達するまで(そんなことは無理でしょうが)、エンジニアはネットワーク・システムやアプリケーションの問題を直面し続けることでしょう。それが、パフォーマンスが遅い問題、音声/ビデオの品質が悪い問題、あるいはは今日のネットワークを悩ますその他の問題であろうが、エンジニアはこれら業務効率を破壊する問題にしっかり対応できるように、トラブルシューティング・スキルに絶えず磨きをかける必要があります。また、あまりにも多くのネットワーク・エンジニアが問題をトラブルシューティングする時に陥る罠を避けなければなりません。

これら罠の例を見てましょう。

1. 問題の根本的原因について思い込みをする

正直に認めましょう:人間は自分が知っていると考えることに基いて仮定を立てます。問題が発生すると、私たちはどうしても結論を急いでしまいます。特定のネットワーク環境についての知識と経験があると、その傾向が一層強まります。しかし、思い込みは大きな間違いに発展する可能性があります。不要なネットワークの変更、高額なアップグレード、根拠のない手入れにつながり、神頼み的にこれで問題が解決されたらと期待してしまうからです。このようなトラブルシューティング時の間違いは、何としてでも避けなければなりません。このような思慮に欠ける決断を行う前に、問題についての事実を収集する必要があります。何かを変更する前に、問題の何を、誰が、どこで、なぜ、どうやってを十分に把握しなければなりません。すべての決断は、事実に基づいたものでなければなりません。

 

2.「このやり方で以前うまくいったから、今度も試してみよう」的なトラブルシューティング

間違い 1 位と同様、ネットワーク問題に対するよくある反応も、思い込みに基づくものです。私たちは皆、自らの経験の犠牲者です。前回うまくいったやり方で今回もうまくいくという考えにどうしても依存してしまいます。多くの場合、新しい問題が以前起きた問題と同じ症状を見せていても、根本的原因が全く違うことがあります。

何かを変更する前に、問題がネットワーク、サーバー、アプリケーション、またはクライアントにあるのか、必ず切り分けてください。当てずっぽうで変更を行うアプローチを取る前に、どのコンポーネントに原因があるのか明確に特定してください。解決を進める前に、SNMP、NetFlow、パケット・キャプチャーを活用するツールを使用して、問題のレイヤーを切り分けてください。

3.再起動による問題解決

家庭用ルーターから 10G スイッチに至るまで、ほぼすべての電子機器は、どこかの時点で再起動しなければなりません。それは電子機器の仕組み上、そういうものなのです。しかし、一部の IT 環境では、デバイスを再起動することが、トラブルシューティングの標準的な最初の一歩になっています。過去にデバイスやサーバーを再起動することで問題が解決できた場合には、特にそう言えます。

デバイスを再起動するだけで問題が解決できた場合は、それは一時的なもので、近い将来にもう一度再起動が必要になる可能性があります。当然ながら、ソフトウェアのアップグレード後、パッチ適用後、または設定変更後に再起動が必要になる場合があります。しかし、ネットワーク問題の初期対応として、デバイスを繰り返し再起動しては、本当の根本的原因を隠してしまうだけです。デバイスを再起動する前に、可能な限りの情報を収集してください。例えば、アクセス・ポイントは、まだユーザーに応答していますか?サーバーは、新しい TCP 接続を受け付けていますか?スイッチの CPU 使用率は 100% ですか?これら情報は、一時しのぎの解決ではなく、本当の根本的原因へエンジニアを導いてくれるかもしれません。

 

4.アップグレードによる問題解決

1Gbps から 10Gbps にアップグレードすれば、パフォーマンスも 10 倍になりますか?

いいえ。

めったにそういうことはありません。ネットワークの問題に直面した時、特にパフォーマンスの遅さがかかわる場合、ネットワーク・エンジニアは WAN の帯域幅を増やしたり、スイッチやルーターをアップグレードしたり、加速化技術を導入する誘惑に駆られることが多々あります。よく知られているように、これらの「解決方法」にただのものはありません。それどころか、問題への初期対応としてのアップグレードは、予算を枯渇させ、マネージャーのフラストレーションが溜まり、業務生産性の低下を招き、そして最悪の場合、ネットワーク・エンジニアの職を奪う可能性があります。

新しいテクノロジーを導入したり、システム/デバイス/接続をアップグレードする前に、答えるべき重要な質問がいくつかあります。デバイス/テクノロジーの向上が問題解決になると確信している理由は?当初の問題は何なのか?問題は、本当にネットワークの容量または遅延に起因するのか?

新しい道具を持つことは楽しいかもしれせんが、その高価なソリューションで問題が解決できなった場合のマネージャーの表情は全くうれしくありません。重要なシステムの時折のアップグレードは正当な行為です。しかし、トラブルシューティングの手順としてデバイスをアップグレードする時は、慎重に行う必要があります。


 

5.検証なしに新しい接続をユーザーに提供

私たちは皆、何度も行ってきたことです。新しいスイッチを箱から取り出して、設定・設置を行い、アップリンクに接続し、エンドユーザー側の接続口に接続してからランプが点灯するのを確認します。

これで終わりですよね?

違います。エンドユーザーがネットワークに接続して仕事に取りかかると、パフォーマンスに影響を与える可能性がある要素はいくつもあります。リンクのネゴシエーション、ケーブルの問題、インターフェイス・ハードウェアの問題、その他のスループットを低下させる問題により、接続が影響を受けます。

エンドユーザーに正式にリンクを提供する前に、テストと検証を行わければなりません。これには、コア/データセンターへの各接続の遅延とスループットの測定も含まれます。すでに述べたように、エンジニアのほとんどは、リンクを接続し、リンク・ランプが点灯するのを確認して、ping を打ち、それでリンクをテストした気になっています。ところが、上記で説明した問題はすべて、このテストに合格してしまいます。完全なパフォーマンス・テストでしか、接続を検証したり、ユーザーが経験する前にこれらの問題を明らかにすることはできません。

 

6.正常なネットワーク・パフォーマンスのベースライン作成を怠る

問題をトラブルシューティングする時、エンジニアはネットワークについての情報を収集し解釈するのに、モニタリング・ツールをよく使います。これらのツールは、見事な量の統計データを提供してくれるものの、「正常時」のベースラインなしでは、多くの情報に溺れてしまいます。

問題が起きる前に、ネットワークのベースラインを適切に作成しておくことが重要です。これには、主要なネットワーク・リンクのトラフィック使用率と遅延の統計情報の収集、重要な業務アプリケーションの応答時間の測定、一般的な会話やプロトコルを含むパケット・キャプチャーのサンプル、および網羅的な無線評価が含まれます。これらのレポートは、「正常」とは何なのかを教えてくれるため、問題が発生した時に役立ちます。


 

7.無線ツールや経験の不足

無線は本当に悩みの種となりえます。特に、ケーブルから Wi-Fi に 100% 乗り換えるエンドユーザーのデバイスが増えるほど厄介になります。この傾向、ならびにこれらデバイスが要求する音声/ビデオ・アプリケーションの増加は、無線環境の範囲を広げ、大幅に複雑化させています。たとえこれらシステムが、熟練の無線エキスパートにより導入・保守されたとしても、クライアント側でパフォーマンスの低下、ネットワークの切断、またはその他の苛立たしい問題に遭遇する可能性があります。

パフォーマンス問題の影響を受けやすい無線環境は、何か新たな問題が発生した時に一番最初に責めを受けます。多くのネットワーク・エンジニアにとって、Wi-Fi はネットワークの中で十分に理解していない領域で、分析するためのツールが不足しているため、Wi-Fi のせいにしてしまいます。ネットワーク・マネージャーは、ネットワークに大きな死角を残すのではなく、この領域で発生する問題に対応するためのツールとトレーニングに投資し、エンジニアが無線についてよく知るようにしなければなりません。

 

8.不十分なネットワーク・モニタリング

今日のエンジニアが直面する問題は、複雑で断続的に発生し、システムの影に隠れることがあります。かつては、ネットワークを監視するのに必要だったのは、アップかダウンかを把握するための ping ベースのツールだけでした。今では、これが大きく様変わりしました。

今日の問題を解決するには、ネットワークとアプリケーションの両方に対応し、隅々まで調べるために SNMP、NetFlow、パケット・キャプチャを活用するモニタリング・システムが必要です。これらのシステムは、イベントを見逃さないように週 7 日、24 時間 365 日アプリケーションを監視し、断続的な問題を現在進行系で捉える必要があります。

 

9.コア・テクノロジーの運用についての誤解

スパニング・ツリー、ARP、オートネゴシエーション、ICMP リダイレクト、IP フラグメンテーションに共通することは何でしょうか?

どれも古いもので(すべて 20 年以上も前の技術)、ネットワーの動作に絶対不可欠です。IP フラグメンテーションはそうでもないかもしれませんが、言及する価値があります。ネットワーク・エンジニアは、自社の最先端のシステムで使われるコア・テクノロジーを理解する必要があります。次のベンダー認証試験の準備をするときは、現在も、さらに今後もシステムの動作に関与するプロトコルやテクノロジーの勉強を省略しないでください。


 

10.パケット・キャプチャにノートパソコンを使用

問題を調査するにあたって、詳細を深く掘り下げるためにパケット・キャプチャとトレース・ファイルの解釈は欠かせません。この分析方法は、ネットワークの潔白を晴らすだけでなく、問題の根本原因を突き止めるのに極めて重要です。

パケット収集するにあたって今日のネットワーク・エンジニアによくある間違いは、キャプチャに使用するハードウェアの限界を誤解することです。例えば、Wireshark などがあります。このオープンソースのツールは、世界中のエンジニアに愛され、最もダウンロードされているネットワーク・ツールです。その一方で、ほとんどのユーザーは、高速トラフィック・ストリームに対応できないノートパソコンや未検証のハードウェアでこのツールを使用しています。実際、標準的なほどんどのノートパソコンは、100Mbps より速いビットレートでシームレスにキャプチャすることはできません。

データセンター環境でキャプチャを行う前は、パケット収集に使うハードウェアの限界を知っておく必要があります。トレース・ファイルでパケットが抜けていると、エンジニアを惑わせ、問題の解決までの時間を増大させる可能性があります。

 

まとめ 

これはすべて網羅するリストではありません。他にもあらゆる経験レベルのエンジニアが陥る落とし穴があります。よくある間違いに対して少しでも準備し、把握しておくことで、エンジニアは問題解決までの時間を短縮させ、フラストレーションを減らし、コストや不要な出費を削減して、ネットワーク問題をトラブルシューティングする際の頭痛の種を回避することができます。

 
 
Powered By OneLink