トラブルシューティングとは、問題を解決するための体系的な方法です。
予期したとおりに動作しなかった理由を判別し、その問題の解決策を決定することが目的です。
トラブルシューティング・プロセスの最初のステップは、問題を完全に説明することです。問題の説明がない場合は、IBM® もお客様ご自身も、問題の原因究明をどこから始めればよいかわかりません。このステップには、以下のような基本的な質問も含まれます。
- 問題の症状は何か
- 問題が発生する場所はどこか
- 問題が発生するのはいつか
- どのような条件下で問題が発生するか
- 問題を再現できるか
通常は、これらの質問に答えることが問題の良い説明となり、問題解決に向かう最良の方法となります。
問題の症状は何か
問題の説明を始める場合、最も明白な質問は「問題は何か」です。
これは端的な質問に思われるかもしれませんが、問題をより明確に説明するための、焦点を絞ったいくつかの質問に分けることができます。例えば、以下のような質問です。
- 問題を報告しているのは誰か、または何か
- エラー・コードおよびエラー・メッセージは何か
- どのようなシステム障害が起きているか。例えば、ループ、ハング、異常終了、性能低下、結果の誤りなどです。
- その問題は業務に対してどのような影響があるか
問題が発生する場所はどこか
問題の発生源を特定することは必ずしも簡単ではありませんが、問題解決における最も重要なステップの 1 つです。報告するコンポーネントと障害のあるコンポーネントの間には、テクノロジーの層が多数存在します。ネットワーク、ディスク、およびドライバーは、問題を調査する際に考慮するコンポーネントのほんの一部にすぎません。
以下の質問は、問題の発生箇所を絞り込み、問題がある層を切り分ける場合に役立ちます。
- 問題は 1 つのプラットフォームまたはオペレーティング・システムに固有であるか、あるいは複数のプラットフォームまたはオペレーティング・システムに共通の問題か
- 現在の環境および構成はサポートされているか
ある層で問題が報告される場合、その問題は必ずしもその層で発生しているとは限らないことに留意してください。問題の発生源を特定するには、その問題が存在する環境を理解する必要があります。ある程度の時間を使用して、問題のある環境 (オペレーティング・システムとバージョン、対応するすべてのソフトウェアとそのバージョン、ハードウェア情報など) を完全に説明してください。サポートされている構成である環境で実行していることを確認してください。問題をトレースバックすると、一緒に実行することが意図されていないか、または一緒に使用した場合のテストが充分ではない非互換レベルのソフトウェアが原因であることが数多くあります。
問題が発生するのはいつか
特に発生が一回限りの場合には、障害に至るまでのイベントの詳細な時系列の記録を作成してください。それには、作業を逆方向に行うのが最も簡単です。エラーが報告された時刻から始め (ミリ秒単位に至るまでできるだけ正確に)、使用可能なログおよび情報を逆に遡って行きます。
通常、診断ログの中で最初の疑わしいイベントを見つけるまでで十分ですが、これは必ずしも容易ではなく、訓練が必要です。複数のテクノロジーの層が関係しており、それぞれに独自の診断情報がある場合には、どこまで調べるかという判断が特に難しくなります。
イベントの詳細な時系列の記録を作成するには、以下の質問に回答してください。
- その問題は、日中または夜間の特定の時刻にのみ発生するかどうか
- 問題の発生頻度
- 問題が報告された時刻までにイベントがどのような順序で発生したか
- ソフトウェアやハードウェアのアップグレードまたはインストールを行うなど、環境を変えても問題は発生するかどうか
この種の質問に答えることにより、問題を調査するための視点が明らかになります。
どのような条件下で問題が発生するか
問題が発生したときに、他にどのようなシステムおよびアプリケーションが実行されていたかを知ることは、トラブルシューティングにおいて重要です。環境に関する以下のような質問は、問題の根本原因の識別に役立ちます。
- 同じ操作を行った場合、その問題は常に発生するのかどうか
- 問題が表面化するには、特定の一連のイベントが発生する必要があるかどうか
- 同時に障害を起こすアプリケーションが他にあるか
このようなタイプの質問に答えると、問題が発生している環境について説明し、依存関係にあるものを関連付けるために役立ちます。ほぼ同時に複数の問題が発生したというだけでは、それらの問題に関連があるとは限りません。
問題を再現できるか
トラブルシューティングの観点から言うと、「理想的な」問題は再現することができます。通常、再現できる問題の場合は、調査のために自由に使用できるツールや手順の数が多くなります。そのため、再現可能な問題は多くの場合、再現できない問題よりもデバッグや解決が容易です。ただし、再現できる問題にも、場合によっては欠点があります。その問題が業務に非常に大きな影響を与える場合には、再現は望ましくありません。可能であれば、テスト環境または開発環境で問題を再現してください。通常、このような環境の方が、調査時の柔軟性が増し、制御しやすくなります。
ヒント: シナリオを単純化して、疑わしいコンポーネントにまで問題を切り分けます。
以下のような質問が、問題の再現に役立つ場合があります。
- 問題をテスト・マシンで再現できるかどうか
- 複数のユーザーまたはアプリケーションで、同じタイプの問題が発生しているかどうか
- 単一のコマンド、一連のコマンド、特定のアプリケーション、またはスタンドアロン・アプリケーションを実行することによって、問題を再現できるか