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

問題の症状はどのようなものか。

問題の記述を始めるとき、「問題は何か?」という質問ほど分かり切っているものはありません。 この質問は単純なように思われますが、これをいくつかの絞り込んだ質問に分解し、問題をさらに具体的に記述することができます。 次のような質問が考えられます。▲

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

問題が発生する場所はどこか

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

以下の質問により、問題が発生した層を切り分けることができます。

• 問題は 1 つのアプライアンスに固有であるか。
• 現在の環境および構成がサポートされているか。

ある層で問題が報告されたとしても、必ずしもその層内で問題が発生しているとは限りません。 問題がどこで発生したかを突き止めるには、問題が存在する環境を理解することが不可欠です。 時間を掛けて、問題の環境を完全に (オペレーティング・システムとバージョン、関連するすべてのソフトウェアとバージョン、およびハードウェアを含めて) 記述してください。 サポートされている環境で実行していることを確認してください。問題をトレースバックすると、一緒に実行することが意図されていないか、または一緒に使用した場合のテストが十分ではない非互換レベルのソフトウェアが原因であることが数多くあります。

問題が発生したのはいつか。

障害の原因となるイベントの詳細なタイムラインを作成します (特に、1 回限り発生する場合)。 タイムラインを作成する最も簡単な方法は、逆方向に作業することです。エラーが報告された時点 (できればミリ秒単位に至るまで精密に) から開始して、使用可能なログと情報を前にたどります。 通常、確認する必要があるのは、診断ログで見つけた最初の疑わしいイベントまでの部分のみです。

イベントの詳細な時刻表を作成するには、以下の質問に答えてください。

• 昼間または夜間の特定の時刻にのみ問題が発生するか。
• 問題が発生する頻度はどの程度か。
• 問題が報告された時刻までにイベントがどのような順序で発生したか。
• ソフトウェアやハードウェアのアップグレードまたはインストールなど、環境を変更した後に問題が発生するか。

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

問題が起こった時点で実行中だったシステムおよびアプリケーションを確認することは、トラブルシューティングの重要な部分です。 環境に関する次のような質問は、問題の原因を特定するのに役立ちます。

• 問題は同じタスクの実行中に常に起こるか
• 問題が発生するには、イベントが特定の順序で起きる必要があるか。
• ほかのアプリケーションにも同時に障害が起こるか。

これらのタイプの質問に回答することは、問題が発生している環境を説明し、依存関係の相関付けをするのに役立ちます。 ほぼ同時に複数の問題が発生する場合でも、それらの問題が必ずしも関連しているとは限らないことを覚えておいてください。

問題を再現できるか。

再現できる問題は、多くの場合、解決が容易です。 しかし、問題を再現できることが、デメリットになることもあります。 その問題がビジネスに重大な影響を与える場合は、それが繰り返し発生することは好ましくありません。 可能な場合は、テスト環境または開発環境で問題を再現してください。通常、そのような環境では、より柔軟で制御の利いた調査ができます。 以下の質問に回答してください。

• 問題をテスト・システムで再現することができるか。
• 複数のユーザーで同じタイプの問題が発生しているか。
• 単一コマンドまたは一連のコマンドを実行して問題を再現できるか。