問題のトラブルシューティング
トラブルシューティングは問題を解決するための系統的アプローチです。トラブルシューティングの目標は、何かが予期したとおりに働かない理由を判断し、問題を解決する方法を明白にすることです。
トラブルシューティング・プロセスの最初のステップは、問題を完全に記述することです。ユーザーも HCL® サポート担当員も、問題記述を利用して、問題の原因の探索をどこから始めるかを判断します。このステップには、自分で次のような基本的な質問をしてみることが含まれます。
- どのような問題の徴候があるか。
- どこで問題が起こるか。
- いつ問題が起こるか。
- どのような条件で問題が起こるか。
- 問題を再現できるか。
通常、これらの質問に答えることにより、的確な問題記述が得られます。問題解決の作業を始めるにはこれが最良の方法です。
どのような問題の徴候があるか。
問題の記述を始めるとき、最も明白な質問は「何が問題か。」です。これは簡単すぎる質問のように見えますが、さらに焦点を絞ってこの質問をいくつかの質問に分解すると、問題点をより明確にすることができます。次のような質問が考えられます。
- 誰が、または何が問題を報告しているか。
- どのようなエラー・コードまたはメッセージが出ているか。
- どのような障害がシステムに起こったか。例えば、ループ、ハング、異常終了、性能低下、結果が正しくない、など。
- 問題がビジネスにどのように影響するか。
どこで問題が起こるか。
問題がどこで発生しているかの判断は、簡単にできるとは限りませんが、問題解決のための最も重要なステップの 1 つです。問題を報告しているコンポーネントと障害が起こっているコンポーネントの間には、多数のテクノロジー層が存在することがあります。問題を調査するときは、ネットワーク、ディスク、ドライバーを始めとして多くのコンポーネントを考慮する必要があります。
問題が起こった場所に焦点を当てて問題層を分離するには、以下の質問が役立ちます。
- 1 つのプラットフォームまたはオペレーティング・システムに固有の問題か、それとも複数のプラットフォームまたはオペレーティング・システムに共通の問題か。
- 現在の環境および構成がサポートされているか。
ある層から問題が報告されても、その層で発生した問題であるとは限らないことに注意してください。問題がどこで発生したかを突き止めるには、問題が存在する環境を理解することが不可欠です。しばらく時間を割いて、問題の環境を完全に記述してください。これにはオペレーティング・システムとそのバージョン、対応するすべてのソフトウェアとそのバージョン、およびハードウェア情報を含める必要があります。サポートされている構成の環境で実行していることを確認してください。問題の多くは、ソフトウェアのレベルが非互換 (一緒に実行することが意図されていないソフトウェアまたはその組み合わせでのテストが完全になされていないソフトウェア) であることが原因で生じている可能性があります。
いつ問題が起こるか。
障害に至るまでのイベント (特に発生が 1 回限りのイベント) の詳しい時刻表を作成してください。これには逆方向に遡るのが最も簡単です。エラーが報告された時点 (可能な限り正確に、できればミリ秒単位で) から始めて、使用できるログおよび情報を逆方向にたどります。通常は、診断ログで最初に発見された疑わしいイベントまでたどれば十分です。ただし、これは必ずしも容易ではなく、熟練する必要があります。複数のテクノロジー層が関係していて、それぞれの層に固有の診断情報がある場合、探索をどこで停止するかの判断が特に難しくなります。
詳しい予定表を作成するには、以下の質問に答えてください。
- 昼間または夜間の特定の時刻にのみ問題が発生するか。
- 問題がどのくらい頻繁に発生するか。
- 問題が報告された時点までにどのようなイベントのシーケンスがあったか。
- 問題は環境の変更 (ソフトウェアまたはハードウェアのアップグレードまたはインストールなど) の後で発生するか。
このような質問に答えることにより、問題を調査するための基準枠が得られます。
どのような条件で問題が起こるか。
問題が起こった時点で実行中だったシステムおよびアプリケーションを確認することは、トラブルシューティングの重要な部分です。問題の根本原因を突き止めるためには、環境に関する以下の質問が役立つことがあります。
- 問題は同じタスクの実行中に常に起こるか。
- 問題が表面化するために一定のイベントのシーケンスが必要か。
- ほかのアプリケーションにも同時に障害が起こるか。
この種の問題に答えることが、問題の起こる環境を明白にし、相互の依存関係を記述する上で役立つことがあります。ほぼ同時に複数の問題が起こった可能性があるため、問題の間に関連があるとは限らないことに注意してください。
問題を再現できるか。
トラブルシューティングの観点からは、理想的な 問題とは再現可能な問題です。通常、再現可能な問題には、意のままに調査に使用できるツールまたは手順がより多く用意されています。したがって、再現可能な問題はデバッグおよび解決が容易なことがしばしばあります。ただし、再現可能な問題にも欠点があります。ビジネスに著しく影響する問題の場合、再現することは望ましくありません。可能な場合、テスト環境または開発環境で問題を再現してください。通常、そのような環境では、より柔軟で制御の利いた調査ができます。
- 問題をテスト・システムで再現できるか。
- 複数のユーザーまたは複数のアプリケーションで同じタイプの問題が発生しているか。
- 単一のコマンド、一連のコマンド、特定のアプリケーション、またはスタンドアロン・アプリケーションを実行して問題を再現できるか。