問題のトラブルシューティング手法

問題にはどのような症状がありますか?

問題の記述を始める際に最も明白な質問は、「何が問題であるか」です。 この質問は 単純に思えるかもしれませんが、的を絞ったいくつかの質問に細分化することで、問題の状況をより詳しく述べることができます。 次のような質問が含まれます。

• 問題を報告しているのは誰または何ですか?
• エラー・コードおよびメッセージは何ですか?
• システムにどのような障害が発生しますか? 例えば、ループ、停止、異常終了、 性能低下、または間違った結果。

どこで問題が発生していますか?

問題が発生している 場所の判別は必ずしも容易ではありませんが、問題解決においては最も重要な 手順の 1 つです。障害を報告したコンポーネントと障害が発生したコンポーネントの間には、 何層ものテクノロジーが存在する可能性があります。ネットワーク、ディスク、 およびドライバーは、問題を調査する際に考慮すべきコンポーネントの 一部に過ぎません。

以下の質問は、問題の発生場所に焦点を絞って、 問題の層を特定するのに役立ちます。

• 問題は 1 つのプラットフォームまたはオペレーティング・システムに特定のものですか、 それとも複数のプラットフォームまたはオペレーティング・システムに共通しますか?
• 現行の環境および構成はサポートされていますか?

ある層で問題が報告されたとしても、必ずしもその層内で問題が発生しているとは限りません。問題の発生場所を 特定するためには、その問題が存在する環境を理解することも必要です。 オペレーティング・システムとバージョン、対応するすべてのソフトウェアと バージョン、およびハードウェア情報など、 時間をかけて問題の環境を完全に記述してください。サポートされる構成の環境で稼働していることを確認してください。 問題の多くは、ソフトウェア・レベルの非互換性に原因がある場合が多く、それらのソフトウェアは、同時に実行されることを意図していないか、 または同時に実行する場合のテストが十分に行われていません。

いつ問題が発生しますか?

障害の原因となるイベントの詳細なタイムラインを作成します (特に、1 回限りの発生である場合)。 作業をさかのぼることによって、タイムラインを簡単に作成できます。エラーが報告された時点 (できるだけ詳細に、ミリ秒単位まで) から開始し、使用できるログと情報を逆方向にたどります。通常は、診断ログで最初に見つけた疑わしいイベントまでを調べるだけで十分です。

イベントの詳細なタイムラインを作成するには、 次の質問に答えます。

• 問題が発生するのは、一日の特定の時刻だけですか?
• 問題はどのくらいの頻度で発生しますか?
• 問題が報告される時刻に至るまで、どういうイベントのシーケンスがありますか?
• 問題が発生するのは、ソフトウェアやハードウェアのアップグレードや インストールなど、環境を変更した後ですか?

このようなタイプの質問に回答することによって、問題を調査する基準枠が得られます。

どのような条件下で問題が発生しますか?

問題の発生時に 稼働しているシステムおよびアプリケーションを把握することは、 トラブルシューティングの重要な部分です。次の環境に関する質問は、 問題の根本原因を特定するのに役立ちます。

• 同じタスクの実行中に必ず問題が発生しますか?
• 特定のイベントのシーケンスが発生しないと、問題は表面化しませんか?
• 同時に他のアプリケーションにも障害が発生しますか?

これらの種類の質問に対する回答は、問題が発生する環境を説明し、依存関係を示すために役立ちます。 ほぼ同時に複数の問題が発生する場合でも、それらの問題が関連しているとは限らないことに 注意してください。

問題を再現できますか?

トラブルシューティングの観点からすると、再現可能な問題が理想的です。通常、問題を再現できる場合は、調査に役立てるために自由に使用できるツールまたは手順が多くなります。そのため、再現可能な問題は デバッグおよび解決が容易である場合が多いです。 しかし、再現可能な問題には不利な点もあります。 業務に大きな影響を与える問題は、再現したくありません。 可能であれば、テストまたは開発用の環境で問題を再作成します。 これらの環境では通常、調査時の柔軟性が高まり、制御しやすくなります。

• テスト・システムで問題を再現できますか?
• 複数のユーザーまたはアプリケーションで同じタイプの問題が発生していますか?
• 単一のコマンド、一連のコマンド、特定のアプリケーションのいずれかを実行することによって問題を再現できますか?