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

トラブルシューティングとは、問題を解決するための体系的なアプローチである。 トラブルシューティングの目的は、期待したとおりに処理されない理由を突き止め、問題の解決方法を見つけることにあります。

トラブルシューティングのプロセスにおける最初のステップは、問題を完全に記述することです。 問題の説明は、お客様とIBM®テクニカル・サポート担当者が問題の原因を見つけるために何から始めればよいかを知るのに役立ちます。 このステップには、自分で次のような基本的な質問をしてみることが含まれます。

通常、これらの質問に答えることにより問題を適切に描写でき、問題の解決につながります。

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

問題を説明し始めるとき、最も明白な質問は"何が問題なのか?"である これは単純な質問のように思えますが、的を絞ったいくつかの質問に分けることで、問題をさらに具体的に記述することができます。 次のような質問が考えられます。

  • 誰が、または何がその問題をレポートしたか。
  • どのようなエラー・コードおよびメッセージが出されたか。
  • システムにどのような障害が起きるか。 (例: ループ、ハング、異常終了、性能低下、間違った結果など)

問題がどこで発生したか

問題の発生源を判別することは、必ずしも容易ではありませんが、これは問題の解決のための最も重要なステップの 1 つです。 障害を報告しているコンポーネントと障害が起こっているコンポーネントの間には、テクノロジーの多くのレイヤーが存在する可能性があります。 ネットワーク、ディスク、およびドライバーは、問題を調査するときに考慮する必要があるコンポーネントの、ほんのわずかな例にすぎません。

以下の質問により、問題が発生している場所に焦点を当て、問題のある層を切り分けることができます。

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

1 つのレイヤーで問題が報告されていても、その問題は必ずしもそのレイヤーで発生しているわけではありません。 問題の発生源を識別するには、その問題が存在する環境を知ることが不可欠です。 十分に時間をかけて、オペレーティング・システムとそのバージョン、該当するすべてのソフトウェアとそのバージョン、ハードウェア情報など、問題が存在する環境を詳細に記述してください。 サポートされる構成の環境内で実行していることを確認します。多くの問題は、特定のソフトウェアを同時に実行することは想定されていない、または同時に作動させた状態で十分にテストされていない場合に、ソフトウェアのレベルが非互換であることに由来します。

問題がいつ発生するか

障害発生に至るイベントについて、特に発生が 1 回限りのケースについて、詳しい時系列対照表を作成してください。 最も簡単にタイムラインを作成する方法は、逆方向に作業することです。エラーが報告された時点 (可能な限り正確に、ミリ秒単位まで) から開始して、使用可能なログおよび情報を前にたどります。 通常は、診断ログで最初に検出した疑わしいイベントまで調べるだけでかまいません。

イベントを時系列で詳細に記述するために、次の質問に答えます。

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

このような質問に回答することにより、問題を調査するための枠組みを得ることができます。

問題はどのような状況で発生するか

問題の発生時に実行されていたシステムとアプリケーションを把握することは、トラブルシューティングにおいて重要です。 現在の環境に関する以下の質問に答えると、問題の根本原因を特定するのに役立ちます。

  • 問題が発生するのは、いつも同じタスクを実行しているときか。
  • 問題が表面化するには、特定の順序でイベントが発生する必要があるか
  • 同時に他のアプリケーションにも障害が発生するか。

このようなタイプの質問に回答すると、問題が発生する環境を説明し、依存関係を相互に関連付けるために役立ちます。 単に同じような時刻に複数の問題が発生していても、必ずしもそれらの問題に関連があるとは限らないことに留意してください。

問題を再現できるか

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

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