GUIロボットとRUMを使用しないITサービスのパフォーマンスと可用性の監視

この記事では、GUIロボットとReal User Monitoring（RUM）クラスのシステムを使用せずに、ITサービスのパフォーマンスと可用性の監視を編成する方法について説明します。

以下で説明するソリューションは、数十万ドルかかるReal User Monitoringクラスの製品が高すぎる人向けであり、サービスデスクコールやユーザーアンケートの分析はほとんどないという理解がすでに得られています。

問題

多くの場合、ITサービスのパフォーマンスと可用性（以下、ITサービスの品質と呼びます）の「監視」は、サービスデスクでのユーザーリクエストの分析や調査の実施に帰着します。発生した問題を1〜5で評価します（リストから選択） ）など このようにITサービスの提供の品質を効果的に管理することは非常に困難です。



ご注意 理論によれば、ITサービスの品質の低下はインシデントと見なされるべきです。 ただし、実際には、ユーザーはサービス品質の低下のすべてのケースを記録するのではなく、ビジネスタスクを実行するために重要であると認識されたケースのみを記録します。 さらに、サポートに連絡する前に、ユーザーは自分で問題を解決または回避したり、インターネットで解決策を探したり、同僚と相談したりするなど、多くの場合成功します。 ユーザーが個別に解決したインシデントについては、サポートも不明です。



顧客の数が少ない小規模のアウトソーシング業者にとっては、これで十分かもしれません。 しかし、顧客が増え、ITサービスが複雑になればなるほど、レビューやサポートへの問い合わせだけに基づいて品質を追跡することが難しくなります。 この方法で取得された情報は不完全であり、ITサービスの運用における多くの小さな問題は、プロバイダーにとって未知のままです。

ITサービス品質監視方法

ITサービスの品質を監視するためのより高度な方法は次のとおりです。

• ITインフラストラクチャの監視。
• ビジネスアプリケーション（主にGUIロボット）の応答時間を監視します。
• リアルユーザー監視（RUM）。

それらのそれぞれを特徴付けます。



最初の方法は、ITインフラストラクチャの健全性がサービスの可用性と相関しているという考えに基づいています。 一般に、これは事実ですが、効果的に使用するには監視システムのしきい値を正しく設定する必要があります。 一般に、監視システムのしきい値を設定することは、監視システムを使用する際の主な困難です。 監視システムがセットアップされていない場合は、pingによってITインフラストラクチャ要素の可用性のみを効果的に監視できます。もちろん、これは実際にサービスを使用する機能とは異なります。 IPテレフォニーインフラストラクチャのすべての要素にはpingを介してアクセスできますが、接続を使用することはできません-音が鳴り、画像がフリーズします。



ビジネスアプリケーションの応答時間を監視するために、今日ではGUIロボットが最もよく使用されています。 GUIロボットは、ユーザーインターフェイスでユーザーの動作をシミュレートします。 これは、ITサービスの可用性を監視するための非常に効果的なツールですが、2つの「しかし」です。 第一に、GUIロボットは拡張性の低いソリューションであり、第二に、ユーザーの操作を大幅に簡素化します。 たとえば、ロボットGUIでは、複雑なトランザクションをエミュレートすることはできません。

2番目の欠点は、リアルユーザーモニタリング（RUM）を奪われていることです-リアルユーザーアクションのパッシブモニタリング。 ほとんどの場合、ネットワークトラフィックアナライザーがこれに使用されます。 これは実際にすべてのユーザーアクションを監視していますが、このクラスの製品にはそれぞれ数十万ドルの費用がかかります。 RUMに資金があり、それを使用する準備ができている場合は、RUMを使用します。 そうでない場合、RUMを使用しないソリューションを以下に説明します。

コンセプト

現在、状況は、ユーザーとの連絡（主に、インシデントおよびサービスリクエストの受信と処理）がサポートサービスによって処理され、システム管理者（システム管理者）が予防的な監視に従事していることです。 システム管理者は、インシデントが発生しないことを確認し、サポートチームは、すでに発生したインシデントを処理して、低下したサービス品質を可能な限り迅速に復元しようとします。

両方（プロアクティブな監視とインシデント管理）の最終的な目標は、ITサービスの品質が高いレベルに維持され、ユーザーが満足することを保証することです。



彼の仕事では、システム管理者は監視システムを使用します（または使用しません）。 原則として、監視システムはITインフラストラクチャの状態と状態、およびビジネスアプリケーションのパフォーマンスを監視します。 ただし、監視システムは、ITインフラストラクチャの健全性やビジネスアプリケーションのパフォーマンスだけでなく、あらゆるものを追跡できるように設計されています（または配置する必要があります）。 適切なモジュールを追加するだけです。



それでは、ユーザーの満足度を追跡するために監視システムに請求してみませんか？

結局のところ、ITインフラストラクチャの監視は、ITインフラストラクチャの健全性がクライアントへのITサービスの提供を保証する場合にのみ必要です。 お金は、コンピューターやルーターではなく、クライアントによって支払われます。



ご注意 サービスプロバイダーの観点からITサービスの品質を監視する目的は、サービス自体の抽象的な品質を監視することではなく、サービスの品質に対するユーザーの満足度を確保することです。

ユーザー満足度の監視

ユーザーは、ITサービス（実際には、サービスデスク）に、機能上重要であると同時に不解決であると思われる不満のケースのみを報告します（不適切な性格と大規模な権限は角かっこから外されます）。

ITサービスでの作業中に、ユーザーがあらゆる種類の小さな問題について苦情を申し立てることができるようにします。 しかし、そのような異議申し立てを受け入れます-彼らに苦情を呼びましょう-あなたはサービスをサポートすることはできません-それらの多くがあります（あなたが正しいケースを入れた場合）、そしてサポートサービスは単に彼らに圧倒されます。



したがって、苦情はサポートサービスではなく、監視システムによって受け入れられます。



監視システムは：

1. サーバー、通信チャネルなどのヘルスメトリックとともに、苦情を別のメトリックとして追跡します。
2. この新しいメトリックをnポイントスケールで評価します。
3. 許容値を超える場合は、サポートサービスに通知します（サービスデスクシステムにエントリを作成し、サービスの従業員に電子メールなどで通知します）。

報告システムにより、遡及的分析を実施したり、特定の不満を引き起こすサービスを特定したりすることができます。

解決策

苦情を送る

ユーザーはITサービスとの通信を好みません。 苦情の送信の複雑さを最小限に抑えます。ボタンまたはキーボードショートカットをクリックするだけで、完全に自動的に送信されます。



サービスの品質が一時的に低下したとき（サービスがフリーズするが、数分でハングすることが事前にわかっている場合）、ユーザーは原則として何の関係もありません。 彼の事業は中断されましたが、彼はサポートに目を向けているように見えました。反応が起こる頃には、すべてがすでに機能していたからです。 ユーザーは彼のexpressingりを表現し、サービスを改善することを気にしませんが、それを行う方法を知りません。 彼は部門全体で大声で誓います：「もう一度、犬！」または彼自身でこのドラマを経験しています。 彼に赤いボタンを渡します。 さて、サービスが再び退屈になったとき、彼は最初にボタンを押し、次に部門全体を誓います。



赤いボタンは、EPM-Agent Plusソフトウェアエージェントです。 ユーザーのコンピューターまたはターミナルサーバーにインストールされます。 デバイスは、ソフトウェアエージェントに接続されます-USBを介して接続されたハードウェアプッシュボタンボタン。 サービスで問題が発生したときにユーザーがクリックするのはその上です。 誰かのためにボタンが古風に見える場合は、キーの組み合わせを押すことでそれを行うことができます-これはハードウェアボタンを押すのと同じです。





ご注意 ハードウェアボタンが必要なのはなぜですか？ 美しい。 ITサービスのサプライヤと受信者が異なる企業である場合、サプライヤはマーケティング目的でこの美しい赤いものを使用する方法をすぐに理解します。



EPM-Agent Plusは次のことができます。 ボタン（ハードウェアまたはキーの組み合わせ）に触れるだけで、使用するビジネスアプリケーションとビジネスオペレーションを決定し、スクリーンショットを撮り、環境変数とユーザー資格情報の値を追加し、HelpMeメッセージの形式ですべて情報アグリゲーター（サービスデスクではありません！） 。



ご注意 一般的に、赤いボタンは苦情を送信できるだけでなく、インシデントを記録することもできます。 したがって、彼女には2つの操作モードがあります。 最初のボタンをクリックすると、インシデントの記録に必要なダイアログボックスが開きます。 ほとんどのアクションは自動的に実行されますが、インシデントのタイプを明示的に指定する必要があり、そのためにはダイアログボックスが必要です。 2番目のモードでは、ウィンドウは開かず、プログラムが自動的に実行されます。 このモードは、苦情を送信するために使用されます。 ボタンを一度に2つの目的で使用できるようにするために、モードは異なるボタンを押すことで呼び出されます。最初の-短い、通常の、2番目の-長い、約2秒（電話をオンにするなど）。

苦情集計

HelpMeメッセージはSOAPパッケージです。 HelpMeメッセージは、Information Aggregatorで収集（集約）されます。

Information Aggregatorは、ProLAN SLA-ON監視システムです。 監視システム自体に加えて、情報アグリゲーターには次のものが含まれます。

• エキスパートシステム
• 統合データベース
• 報告ツール

情報アグリゲーターは苦情（HelpMeメッセージ）を受け入れ、統合データベースに書き込みます。 すべての苦情はまとめられており、私たちが苦情を収集したのと同じ方法だけでなく、何らかの苦情を彼らとする必要があります。



ご注意 フル機能のProLAN SLA-ONとともに 、いくつかの目的で、無料のQuTester Plusを使用できます。 QuTester Plusは、監視システムと赤いボタンの両方を含むパッケージです。 もちろん、機能は切り捨てられますが、時間制限はありません。 フル機能のProLAN SLA-ONとRed Buttonには、30日間の無料試用期間があります。 一般に、このソリューションは、Real User Monitoringクラスの製品よりも1桁または2桁安いです。

苦情とユーザー満足度

各苦情はユーザーの不満の兆候であり、HelpMeメッセージの内容により、不満がどのサービスに関連するか、ユーザーが地理的にどこにいるか、どの部門から、どの位置にいるかなどを判断できます。



サポートおよびアンケートサービスのデータのみを使用した場合よりも、サービスに対するユーザーの態度について既に多くのことを学びました。 しかし、どこからでも注がれている苦情の塊をどうやって理解するのでしょうか？

私たちは、私たちの興味を引く兆候に従って苦情をグループ化します-たとえば、次のように：

/	ユーザーリファレンス
操作リファレンス	/	トップス-モスクワ	売り手-ピーター	すべて-ソチ
	1Cで働く	メトリック1：モスクワの1Cの仕事に対するトップの苦情	メトリック4：サンクトペテルブルクから1CおよびSAP CRMを使用する販売者への苦情	メトリック6：ソチから1CおよびSAP CRMの作業までのすべてのユーザーの苦情
	SAP CRMで作業する	メトリック2：モスクワからの苦情は、SAP CRMの作業に関するトップ
	インターネット	メトリック3：モスクワからインターネットの仕事に対するトップの苦情	メトリック5：サンクトペテルブルクの売り手とソチのすべてのユーザーのインターネットの仕事に関する苦情

現在、これらの苦情グループは、監視システムによって監視されるメトリックです。 SAPについてセラーズピーターグループのユーザーから苦情が寄せられた場合、メトリック4によって1Cからソチの苦情が考慮されます。ユーザー満足度メトリックを使用して、監視システムはITサービスの品質を監視します。 各メトリックは、「良い」、「許容できる」、「注意が必要」、「瀬戸際にある」、「悪い」の5段階で自動的に評価されます。 たとえば、SAPの作業に関するソチからの1日（または1時間、1分あたり）の苦情は2つまでです。これは「良い」、2つ以上「許容できる」、3つ以上「注意が必要」などです。

品質評価（色の「インジケータ」）	> / <	しきい値
悪い（赤）	>	7
寸前（赤く点滅）	>	5
注意が必要（黄色）	>	3
許容（黄色に点滅）	>	2
良い（緑色）	<	2

「注意が必要」-集約インシデントスナップショットをサービスデスクに送信するための品質評価のしきい値。



ユーザーの満足度を意味するメトリックのダイナミクスは、リアルタイムで確認できます。 緑色の四角-「良い」、点滅する緑-「許容される」、黄色が現れる-「注意が必要」。

報告書

生データと専門家の見積もりをリアルタイムで監視でき、色付きの信号機の形で専門家の評価を地理的マップまたはビジネスプロセスの図に適用できます。 生データと専門家の判断に基づいて、運用レポートと戦術レポートを生成できます。 運用レポートを使用すると、営業所などのさまざまな部門（アナリスト）でITサービスの品質に対するユーザーの満足度を確認できます。 戦術レポートを使用すると、長期間（トレンド）のITサービスの品質に対するユーザー満足度の変化、さまざまなセクションのベースラインなどを確認できます。

集約されたインシデントのスナップショット

特定のサービスが1人または別のユーザーから受け取った苦情の数を単純に評価するだけでは不十分です。 ITサービスの品質の維持を担当する従業員が、サービスデスクにインシデントを登録しているユーザーがいなくても、サービスの品質の低下を迅速に発見し、状況を修正できるようにする必要があります。

これを行うには、メトリックの評価が「注意が必要」という値に達するとすぐに、監視システムがインシデントの集約スナップショットを自動的に作成し、サービスデスク-システムに新しいインシデントを登録します。 それに関連するすべての苦情は、インシデントの集約スナップショットに適用されます（HelpMeメッセージ）。 インシデントの集約スナップショットを受信すると、サポートサービスは通常のインシデントと同様にそれと連携します。



注1. ITサービス品質監視とITインフラストラクチャの健全性およびビジネスアプリケーションのパフォーマンスの監視を統合すると、品質低下の原因を診断するタスクが容易になります。

注2.この理論は、ユーザーからではなく、自動イベント管理システムからのサポートサービスへのインシデントの登録を許可し、さらに奨励しています。 これは、ITインフラストラクチャの正常性を監視する監視システムを指し、誤動作（サーバーが応答しない、Webサイトが利用できないなど）を検出すると、サポートサービスへの自動リクエストを形成します。 同じことを行います（監視システムを使用してインシデントを自動的に登録します）が、ITインフラストラクチャではなくユーザーの満足度で問題が検出された場合。

範囲と制限

明らかに、ユーザーに小さな問題について絶えず不満を言うように頼むこと（このタスクを可能な限り単純化することさえ）は、良い考えではありません。 ユーザーがITサービスの仕事をする必要がある理由-人々が問題を報告しても改善が見られない場合、彼らはそれをやめます。 したがって、ボタンを押すように要求するユーザーへのアピールは、まず正当化され、次に一時的（最大1〜3か月）である必要があります。 これは、たとえば次の場合に行うのが論理的です。

1. ITサービスの品質の監査の実施（年次保守）。 しかし、私たちが知らない問題はありますか？ 「受け取ったサービスの品質を評価してください」など
2. 新しいサービスの導入の終わりに。 苦情の体系化は、ビジネスアプリケーションの欠陥やITインフラストラクチャの問題のローカライズに役立ちます。 「新しいビジネスアプリケーションが導入されています。請負業者の仕事の質を評価するのを手伝ってください。」
3. CIOまたはITチームを変更するとき。 災害の規模を数字で評価する。

主な目標：

1. ネットワークプロトコルアナライザーなど、より正確な診断ツールをより効率的に使用できるようにする問題のローカライズ。
2. 隠れた欠陥とボトルネック（ITサービスが認識していない）を診断します。 それらを排除するために、ユーザーはもはや文句を言いません。
3. ユーザーの快適な作業に対応する技術指標（廃棄、エラー数、遅延）のしきい値の決定。 既存のITインフラストラクチャ監視システムを使用して、ユーザーに関与することなく、ITサービスのパフォーマンスと可用性を制御する。 これは非常に重要なトピックであり、別の記事で開示する予定です。

結論

1. サポートサービスおよびアンケートによる「監視」の過去は次のとおりです。
   
   
   • ユーザーが無視するサービス品質の低下のケース。
   • ユーザーが自分で決定した、サービス品質の低下のケース。
   • ユーザーがサービスの品質に関するアンケートへの記入を望まず、サポートに連絡しなかった他のすべてのケース。
   
   
   
2. コンセプト
   
   
   1. ITサービスプロバイダーのITサービスの品質を監視することは、ITサービスの品質に対するユーザーの満足度を監視することです。
   2. さらに見るには、ITサービスの作業における軽微な違反について不満を言うようにユーザーを動機付ける必要があります。
   
   
   
3. 解決策
   
   
   1. ユーザーはボタン（ 赤いボタン ）を押して苦情を送信します。
   2. 苦情は人（サポートサービス）ではなく、ITシステム（ProLAN SLA-ON監視システム）によって受け入れられます。
   3. 人々は個々の苦情ではなく、レポートおよび集約されたインシデントを処理します。
   
   
   
4. 範囲と制限
   
   
   1. 監視の目的は、ユーザーの作業に影響を与える前に問題を発見することです。 したがって、永続的な解決策として、ユーザーの苦情を伴う監視を使用しないでください。
   2. ユーザーの苦情を活用して監視する目的は、問題を特定し、隠れた欠陥やボトルネックを診断し、ユーザーの快適さに対する技術的指標の適合性を確立することです。
   3. ユーザーの苦情による監視の使用-ITサービスの品質の監査、新しいサービスの導入、CIOまたはITチームの変更。