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

特定の共通した手法が、トラブルシューティングの作業に役立つことがあります。トラブルシューティング・プロセスの最初のステップは、問題を完全に記述することです。

問題を記述することで、ユーザーと IBM 技術サポート担当者が、問題の原因を特定しやすくなります。このステップでは、次の基本的な質問をご自身で検討します。

  • 問題の症状はどのようなものか。
  • 問題が発生する場所はどこか
  • 問題が発生したのはいつか。
  • どのような条件下で問題が発生するか
  • 問題を再現できるか。

通常は、これらの質問に回答することで問題が適切に記述され、問題解決につながります。

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

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

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

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

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

問題が発生している部分に焦点を当てて問題となっているレイヤーを切り分ける上で、次の質問が役立ちます。

  • 問題は 1 つのオペレーティング・システムに固有か、それとも複数のオペレーティング・システムに共通か。
  • 現在の環境および構成がサポートされているか。
  • ユーザー全員に問題が発生しているか。
  • (マルチサイト・インストールの場合) すべてのサイトに問題が発生しているか。

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

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

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

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

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

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

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

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

  • 問題が起きるのはいつも同じタスクの実行中か。
  • この問題が発生するときに、特定の一連のイベントが必ず発生するか。
  • ほかのアプリケーションにも同時に障害が起こるか。

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

問題を再現できるか。

トラブルシューティングの観点からすると、理想的な問題とは、再現できる問題であるということです。通常、問題を再現できる場合は、調査に役立てるために自由に使用できるツールまたは手順の数が多くなります。再現可能な問題はデバッグおよび解決が容易なことがしばしばあります。

ただし、再現可能な問題にも欠点があります。ビジネスに著しく影響する問題の場合、再現することは望ましくありません。可能な場合は、テスト環境または開発環境で問題を再現してください。通常、そのような環境では、より柔軟で制御の利いた調査ができます。

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