情報システムは日々、様々なトラブルに直面します。ビジネスのシステムに対する依存性が高まった今、トラブルの迅速な解決は企業の最重要課題とも言えます。一般的にこの課題を解決するための取り組みがトラブルシューティングです。企業は万が一、トラブルが発生したことを想定することが求められています。広義の意味でのトラブルシューティングは、問題を解決するだけでなく「問題を解決するための方法論」を意味し、情報システムにおいて問題のパターン化と作業プロセスを明確にし、日々発生するトラブルに対して迅速に対処するためのものです。

システムの安定稼働がビジネスには不可欠と理解している企業の多くは、トラブルシューティングの体制を整えています。しかし従来のトラブルシューティングにはある問題点が存在するのです。ここではその問題点と、それを解消するための方法についてお話します。

トラブルシューティングのプロセス

まずは、一般的なトラブルシューティングのプロセスを整理しておきます。前提として、トラブルシューティングではユーザーがシステム利用中に何らかのトラブルが発生し、それを情報システムもしくはヘルプデスクに連絡します。連絡を受けた担当は現場に向かい、ユーザーの利用状況のヒアリングと現況確認を行い、トラブルの性質や原因を特定します。トラブルを特定する作業において、次のようなプロセスが必要です。

  1. なぜそのトラブルが起こっているのか?を考察する為に、トラブルの性質を探ります。例えば「レスポンスの遅延」というトラブルの場合、症状を細かく分けて掘り下げて考えることで、本質的な症状を見極めていきます。
  2. 次に、そのトラブルはどこで発生したのか?を考えます。トラブルの発生場所を特定するのは簡単ではないものの、素早くトラブルシューティングを実行するのに不可欠です。問題が現れているシステムに原因があるとは限らない為、複数のテクノロジーの介在を意識しながらトラブルの発生場所を突き止めます。
  3. トラブルには特定のパターンがあることが多く、それを突き止める為にイベントログ情報などを時系列に取得します。トラブルが発生した時点から閲覧できるイベントログ情報を辿りながら、トラブルの原因を突き止めていきます。
  4. 時にはトラブルが発生した際に、動いていたシステムやアプリケーションは何か?そこまで辿って把握することも大切です。トラブルが発生する特定のパターンを明確にする為に、そしてトラブルシューティングを迅速に完了する為に重要な情報が得られます。
  5. 最終的にはそのトラブルを意図的に再現できるものかどうかを確認します。トラブルシューティングを速やかに実施し、または今後のトラブル解決のためのナレッジを積み上げる目的でもトラブルの再現は有効的です。

以上がトラブルシューティングの一般的なプロセスです。では、こうしたトラブルシューティングの一体どこに問題があるというのでしょうか?

今までのトラブルシューティングの問題点

それでは、トラブルシューティングの現場にありがちな問題点をご紹介します。いずれも効率的なトラブルシューティングを妨害するものばかりなので、情報システムはこれらの問題点を最優先の解決事項とする必要があります。

問題点 1.ヘルプデスクコールは時間との勝負

ヘルプデスクコールへの対応はスピードが命です。ユーザーは今困っているのであり、それを解決しなければビジネス自体が止まってしまいます。そのため多くのケースにおいて「トラブルの再現を待つ」「ユーザーの協力を得る」「現地を出向き実機を調べる」などの時間は最小化する必要があります。そのため複雑に絡み合った現代的なシステムにおいても問題箇所を瞬時に把握する必要があります。

問題点 2.誰がいつどのアプリケーションを利用していたかの把握

現代的なシステムにおいてアプリケーションの実行環境はクラウドというのが一般化しています。クラウドは基本的には共有環境で実行されるため問題の特定が困難です。例えばVDI(仮想デスクトップ基盤)環境では人々の利用状況によって多くのトラブルが発生します。システムパフォーマンスの低下は時間帯や混雑状況によって異なったりと問題の特定が極めて困難になります。トラブルが起こっている仮想マシンを特定するのは比較的簡単ですが、それだけではトラブルを解決できないのが実情です。当該仮想マシンでなぜトラブルが起こっているのかを突き止めるには、どのユーザー、どのアプリケーションをどのような状態で利用していたか、そして、システムの状態がどのようになっていたのかを調べる必要があるのですが、それらを正確に把握することは困難です。

問題点 3.マルチセッションOSにおける原因特定の難しさ

こちらもVDIに起因しますが、仮想化環境をマルチセッションOSで運用している場合、トラブルが発生したOS単位の特定は可能です。しかし、なぜそのトラブルが起こったのか?すなわちマルチセッションOSを利用していたユーザーの、どのアプリケーションが原因なのかを調査するのは難しく、しかしそれを特定しなければトラブルを解決できません。

問題点 4.優先度の低いアラートが混じっていること

情報システムはシステムパフォーマンスの状態を最高に保ち、ユーザーエクスペリエンスを最大化し続ける使命があります。このためトラブルの兆候を俯瞰的に監視する必要があるのですが、設定によっては多くのアラートが発せられて問題の特定が困難になるケースが見受けられます。多くの場合、関連する多くのアラートから一つのトラブルを特定する必要があるのですが、大量のアラートから問題を特定することは至難の技と言えます。

SysTrack Resolveで解決するトラブルシューティングの問題点

SysTrack Resolveはシステムに発生しているトラブルをリアルタイムに分析し、ヘルプデスクの業務を支援するトラブルシューティングソリューションです。

SysTrack Resolveの役割は物理クライアント、VDI環境、マルチセッションOSの状態を、システム視点ではなくユーザーとアプリケーションの視点で常に監視し、システム状況を様々な角度から分析することです。これによってユーザーがトラブルに見舞われた際に、システムの状態はどうだったか?ユーザーはどのアプリケーションを使っていたか?そのアプリケーションはどのように動いていたか?システムの何がボトルネックだったのかなど、トラブルの原因究明に必要な情報をリアルタイムに入手できます。

SysTrack Resolveがあることで、物理クライアント、VDI環境、マルチセッションOSのそれぞれでトラブルが起こった際に、ユーザーとアプリケーションの動作状況を調べる為の膨大な時間を消費しません。さらに、物理クライアントの問題を調査するのにユーザーのヒアリングや現地調査に膨大な時間を費やすこともなくなるので、トラブルシューティングが抱える深刻な問題点をピンポイントで解決します。

新型コロナウイルス感染症拡大の影響によりリモートワークが加速するの中、企業情報システムは大きな変動期と言えます。そのためトラブルも頻繁に発生しています。ヘルプデスク業務の生産性向上・質の向上にSysTrack Resolveの活用をご検討ください。

SysTrack Resolve によるトラブルシューティング