トラブルシューティングとは、問題を解決するための体系的な方法です。 予期したとおりに動作しなかった理由を判別し、その問題の解決策を決定することが目的です。
通常は、これらの質問に答えることが問題の良い説明となり、問題解決に向かう最も良い方法となります。
問題の発生源を特定することは必ずしも簡単ではありませんが、問題解決における最も重要なステップの 1 つです。 報告するコンポーネントと障害のあるコンポーネントの間には、テクノロジーの層が多数存在します。ネットワーク、ディスク、およびドライバーは、問題を調査する際に考慮するコンポーネントのほんの一部にすぎません。
ある層で問題が報告されても、その層で問題が発生しているとは限りません。 問題の発生源の識別には、その問題が存在する環境を知ることが含まれます。 ある程度の時間を使用して問題のある環境 (オペレーティング・システムとそのバージョン、対応するすべてのソフトウェアとそのバージョン、ハードウェア情報など) を完全に説明してください。 構成がサポートされている環境で実行していることを確認してください。 問題をトレースバックすると、一緒に実行することが意図されていないか、または一緒に使用した場合のテストが充分ではない非互換レベルのソフトウェアが原因であることが数多くあります。
特に発生が一回限りの場合には、障害に至るまでのイベントの詳細な時系列の記録を作成してください。作業を逆方向に行うのが最も簡単です。エラーが報告された時間から始め (ミリ秒単位に至るほどにできるだけ正確に)、使用可能なログおよび情報を逆に遡って行きます。 通常、診断ログの中で最初の疑わしいイベントを見つけるまでで十分ですが、これは必ずしも容易ではなく、訓練が必要です。 複数のテクノロジーの層が関係しており、それぞれに独自の診断情報がある場合には、どこまで調べるかという判断が特に難しくなります。
このような質問に答えていくことは、問題を調査するための視点を提供するために役立ちます。
このようなタイプの質問に答えることは、問題が発生している環境について説明し、依存関係にあるものを関連付ける場合に役立ちます。 同時に複数の問題が発生したからといって、それらの問題に関連があるとは限りません。
トラブルシューティングの観点から言うと、理想的な問題は再現することができます。 通常、再現できる問題には、自由に使用できる多数のツールやプロシージャーのセットがあり、調査に役立ちます。そのため、再現できる問題は多くの場合、デバッグや解決がより容易です。 ただし、再現できる問題にも、場合によっては欠点があります。 その問題が業務に非常に大きな影響を与える場合には、再現は避けたいでしょう。 可能であれば、テスト環境または開発環境で問題を再現してください。 こうした環境は、通常、調査時により大きな柔軟性と制御をもたらします。
(c) Copyright IBM Corporation 2005, 2006. All rights reserved.
(c) Copyright IBM Japan 2006
このインフォメーション・センターでは、Eclipse テクノロジー (http://www.eclipse.org) が採用されています。