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

どのような問題の徴候があるか。

これは単刀直入な質問のように見えます。しかしこれは、問題の詳細を具体的に説明する、もっと焦点を絞った複数の質問に細分化することができます。次のような質問が考えられます。

• 誰が、または何が問題を報告しているか。
• どのようなエラー・コードまたはメッセージが出ているか。
• どのような障害がシステムに起こったか。例えば、ループ、ハング、異常終了、性能低下、結果が正しくない、など。

どこで問題が起こるか。

問題がどこで発生しているかの判断は、簡単にできるとは限りませんが、問題解決のための最も重要なステップの 1 つです。問題を報告しているコンポーネントと障害が起こっているコンポーネントの間には、多数のテクノロジー層が存在することがあります。問題を調査するときは、ネットワーク、ディスク、ドライバーを始めとして多くのコンポーネントを考慮する必要があります。

問題が起こった場所に焦点を当てて問題層を分離するには、以下の質問が役立ちます。

• 1 つのプラットフォームまたはオペレーティング・システムに固有の問題か、それとも複数のプラットフォームまたはオペレーティング・システムに共通の問題か。
• 現在の環境および構成がサポートされているか。

あるレイヤーで問題が報告されたとしても、必ずしもそのレイヤー内で問題が発生しているとは限りません。問題がどこで発生したかを突き止めるには、問題が存在する環境を理解することが不可欠です。しばらく時間を割いて、問題の環境を完全に記述してください。これにはオペレーティング・システムとそのバージョン、対応するすべてのソフトウェアとそのバージョン、およびハードウェア情報を含める必要があります。サポートされている構成の環境で実行していることを確認してください。問題の多くは、ソフトウェアのレベルが非互換 (一緒に実行することが意図されていないソフトウェアまたはその組み合わせでのテストが完全になされていないソフトウェア) であることが原因で生じている可能性があります。

いつ問題が起こるか。

障害に至るまでのイベント (特に発生が 1 回限りのイベント) の詳しい予定表を作成してください。時間をさかのぼることによって、タイムラインを簡単に作成できます。エラーが報告された時点 (可能な限り正確に、できればミリ秒単位で) から始めて、使用できるログおよび情報を逆方向にたどります。通常、確認する必要があるのは、診断ログで見つけた最初の疑わしいイベントまでの部分だけです。

詳しい予定表を作成するには、以下の質問に答えてください。

• 昼間または夜間の特定の時刻にのみ問題が発生するか。
• 問題がどのくらい頻繁に発生するか。
• 問題が報告された時点までにどのようなイベントのシーケンスがあったか。
• 問題は環境の変更 (ソフトウェアまたはハードウェアのアップグレードまたはインストールなど) の後で発生するか。

このようなタイプの質問に回答することで、問題を調査するための基準枠を設定できます。

どのような条件で問題が起こるか。

問題が起こった時点で実行中だったシステムおよびアプリケーションを確認することは、トラブルシューティングの重要な部分です。問題の根本原因を突き止めるためには、環境に関する以下の質問が役立つことがあります。

• 問題は同じタスクの実行中に常に起こるか。
• 問題が表面化するために一定のイベントのシーケンスが必要か。
• ほかのアプリケーションにも同時に障害が起こるか。

この種の問題に答えることが、問題の起こる環境を明白にし、相互の依存関係を記述する上で役立つことがあります。ほぼ同時に複数の問題が起こった可能性があるため、問題の間に関連があるとは限らないことに注意してください。

問題を再現できるか。

トラブルシューティングの観点からすると、再現可能な問題が理想的です。通常、問題を再現できる場合、一連のさまざまなツールや手順を自由に利用して、問題を調査できます。したがって、再現可能な問題はデバッグおよび解決が容易なことがしばしばあります。ただし、再現可能な問題にも欠点があります。ビジネスに著しく影響する問題の場合、再現することは望ましくありません。可能な場合、テスト環境または開発環境で問題を再現してください。通常、そのような環境では、より柔軟で制御の利いた調査ができます。

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