企業や組織の中に情報システムのトラブルシューティングに関する体系が確立していると、システムに生じた問題などをすぐに特定し、解決/改善することが可能になります。

実は企業の情報システムでは、そうした明確なプロセスを持っていないケースも多数存在します。そのためエンドユーザーから寄せられた問題や苦情に対し都度対応しているため、問題解決と改善が後手に回ってしまい、トラブルが後を絶えないという負のスパイラルに陥りがちです。

システムには日々多くのトラブルの発生が想定でき、かつ高いレベルで新しいテクノロジーなど変化への対応が求められています。トラブルシューティングが確立していない環境では、現代ビジネスにおいて厳しい戦いを強いられることは、すでに多くのCIOや情報システム役員が理解しているところです。

本稿ではそんなトラブルシューティングの基本的な手法についてご紹介しますので、この機会にプロセスの確立について熟考していただければと思います。

トラブルシューティングとは?

そもそもトラブルシューティングとは何か?
それは問題を解決するための手法の1つであり、問題の原因を論理的に考え、究明し、体系立てられたプロセスによって問題を解決するために最も効率的な方法で解決していくことです。一般的には、予め想定されたトラブルに対して体系的にマニュアル化されたものを指します。もちろん、イレギュラーで発生するトラブルの原因究明と解決のプロセスを確立することも大切です。

トラブルシューティングの基本は最も単純で確率の高い原因から検討していき、消去法によって原因を特定していくことです。たとえばコンピューターメーカーが提供するトラブルシューティングでは、最初に「電源は入っていますか?」と聞かれることが多くあります。これは現状の把握と、考えられる可能性を排除していくためのプロセスの一部です。

医療業界には「ひづめの音が聞こえたら、シマウマではなくまず馬を探せ」という格言があります。これは、ある症状に対して珍しい病気ではなく、一般的な病気を想定してまず診療に当たれという意味です。トラブルシューティングでもこの考え方が非常に大切で、何らかの問題に対して特殊な原因を想定するのではなく、まず一般的かつ発生確率の高い原因を想定して究明を行い、消去法によって原因を究明していくことが最も効率的な方法だとされているのです。

トラブルシューティングの基本的な手法

トラブルシューティングではエンドユーザーから受けた問題や苦情の連絡から、ヒアリングを通じて原因を特定していき、状況に応じた様々な対応を取っていきます。単純な問題ならば電話口でエンドユーザーに指示を出して解決する場合もありますし、複雑な問題ならシステムパフォーマンスをチェックしてから原因究明と問題解決を実行します。時には問題を再現したりして、原因を明確にします。こうしたトラブルシューティングにはいくつか基本的な手法があります。

1. 問題の症状を把握する

「今発生している問題は何か?」この質問は単純なもののように思えますが、実際は質問をいくつかに分類し、問題の症状を具体的に把握していく必要があります。たとえば次のような質問が想定されます。

  • 誰が(何が)問題を報告しているのか?
  • どのようなエラーコードおよびメッセージが出ているのか?
  • どのような問題が発生したのか?(ループ、ハング、異常終了、パフォーマンス低下、正しくない結果など)

2. 問題の発生場所を特定する

問題がどこで発生しているかの特定は決して単純ではありませんが、トラブルシューティングで最も重要なプロセスの1つです。問題を報告している人およびシステムと、問題が発生しているシステムの間には複数のテクノロジー層が存在することがあります。従って、問題の発生場所を調査するときはネットワーク、ディスク、ドライバーをはじめとして多くのシステムやツールとその関連性を考慮する必要があるのです。問題の発生場所を特定する場合は、以下の考え方が役に立ちます。

  • 問題は1つのプラットフォーム、またはオペレーティングシステム固有のものか?
  • 複数のプラットフォーム、またはオペレーティングシステムに共通のものか?
  • 現在の環境および構成はサポートされているか?
  • エンドユーザー全員に同じような問題は発生していないか?
  • すべてのシステムに同じような問題は発生していないか?

3. 問題の発生日時を特定する

問題が発生するに至ったイベントの詳しい時系列表を作成することで、問題の発生日時を特定することができます。簡単に時系列表を作成する方法は、イベントを逆方向に辿っていくことです。問題が報告された時点から開始して、使用可能なログと情報を通じて逆方向に辿っていきます。このとき大切なのはミリ秒単位まで可能な限り精密に時系列表を作成することです。問題の発生日時を特定する際は、以下の考え方が役に立ちます。

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

4. どのような条件下で発生するのかを知る

問題が発生した際に実行中だったシステムおよびアプリケーションが何かを知ることは、トラブルシューティングで欠かせません。どういった状況下で問題が発生するかを知ることで、問題の原因究明に役立ちます。以下の考え方を持って、問題発生の条件を把握しましょう。

  • 問題発生は同じタスクの実行中に常に起きているか?
  • 特定の一連のイベントが発生場合のみ問題は発生しているのか?
  • 他のアプリケーションにも同様に問題は発生しているか?

5. 問題は再現できないか考える

トラブルシューティングにおいて再現可能な問題は、原因究明と問題解決のスピードを飛躍することができます。そのため、その問題は再現できるものか?を考えることも大切です。問題を再現できる場合は原因究明や問題解決に役立てるためのツールを自由に使用でき、かつ手順の数も多くなります。従って、問題が再現可能かどうかを考えることはトラブルシューティングにおいて効率的な手法の1つです。次の視点で、問題が再現可能かどうかを検討しましょう。

  • 問題をテストシステムで再現することはできるか?
  • 複数のエンドユーザーまたはアプリケーションで、同じタイプの問題が検出されていないか?
  • 1つのコマンド、一連のコマンド、あるいは特定のアプリケーションを実行することで問題は再現できないか?

トラブルシューティングを成功させるためには?

こうしたトラブルシューティングを成功させるために欠かせないことが、プロセスを体系化することと、ITツールを積極的に採用することです。トラブルシューティングのプロセスを体系化することで、誰もが同じように原因究明と問題解決を実行でき、プロセスの標準化によって解決スピードがアップし、属人的な環境も排除できます。

ITツールに関してはシステムパフォーマンスを常にチェックしたり、問題の原因究明を半自動化したりするために欠かせません。ITツールを積極的に採用することで、トラブルシューティングの精度とスピードをアップさせましょう。

SysTrackでは、企業の情報システムの問題を瞬時に特定する昨日や、プロアクティブな予防保守などにもご活用いただけます。基本をもとに、環境に適した組織独自のトラブルシューティングを徐々に完成させていきましょう。そして、SysTrackのようなITツールをフル活用することでエンドユーザーの効率性を最大限に高めることも可能になります。
この頃は、VDI環境のトラブルシューティングでご相談を受けることが多くあります。構成要素が多いVDI環境では、トラブルの要因を判明することが困難であるため現状のシステムを可視化し把握するためSysTrackをご活用いただいているお客様が増えてきています。トラブルの早期判明と解決、システムの安定運用にSysTrackの導入をご検討ください。

あわせて読みたい:

サービスデスク ソリューション