この仕事の90%は、どのような種類の問題を探すべきかを教えてくれる経験であり、残りの90%は、どこから始めればよいかのヒントを得るためにGoogleで探すべき場所を知っているため、具体的な答えを出すのは困難です。
私は通常、顧客に問題を実証する(主に指の問題や顧客が彼の問題を説明している可能性のある問題を除外する)ようにしてから、別のコンピューターで問題を再現しようと紙袋を試します。これを行うと、多くの場合、どこを見ればよいかがわかります。
今日でも、特にWindowsシステムでは、再起動の修正問題を忘れないでください。以前はこのようだったので、「再起動しましたか?それを試して、問題が解決しないかどうかを教えてください」と尋ねました。これにより、私が尋ねた問題の大部分が修正されました。
DNS解決の問題や基本的な接続性(ルーターのACL、ネットワークのエアギャップ、リモートサイトへのping / traceroutes / mtrsなど)には、頻繁に低い成果もあります。
直接制御できるサービスの場合、nagiosなどを実行して、サービスが実際に実行されていることを確認することで、顧客から問題が通知される前に問題を修正することが頻繁に発生します。また、muninなどを介して直接、またはCactiなどのSNMPを介して、統計情報の収集を実行することもできます。
私は通常、少なくともすべてのコアスイッチとファイアウォールに対してCactiを実行しようとしています。可能な場合は、できる限りすべてに対してCactiを実行します。これらのケースでは、通常、ポートエラーカウントや過剰なトラフィックなどを探しています。一部のデバイスのファイアウォールグラフは、CPU使用率と同時セッションを表示できます。ファイアウォールデバイスで問題が発生し始めるしきい値を知ることができます。
ファイアウォールがsyslogデバイスにログを記録できる場合があります。もしそうなら、あなたができるすべてをログに記録し、ヒントを探してください。これは、syslog-ng、rsyslog、またはsplunkのような何かを実行すると、1つのモノリシックファイルを処理するよりも、ログをいくぶん分割できる場合に簡単になります。
また、少なくともファイアウォールの内側と、可能であればインターネットプロバイダーへのアップリンクに対してnfsenを実行しようとします。これにより、時間をさかのぼってセッションを調べ、誰が何をしていたかを確認できます。これにより、興味深い動作をキャッチできる場合があります。