ITインフラストラクチャの健全性メトリック、しきい値、およびITサービスユーザー

この記事のトピックは、ITサービスのユーザーの快適な仕事に対応するITインフラストラクチャの正常性メトリックのしきい値の決定です。 ITインフラストラクチャのヘルスメトリック（パフォーマンス、可用性など）のしきい値を、ユーザーがITサービスで快適に作業できると考えるものと、すべてが必要な理由と一致させる方法を見ていきます。



この記事は、ITサービスプロバイダー、システム管理者、およびITインフラストラクチャやITサービスのパフォーマンスと可用性の監視を構成したいが、その方法がわからない人を対象としています。

はじめに

監視の目的は、ユーザー、クライアントなどの作業に影響を与える前に、障害について調べることです。 監視システムが時間通りに障害を検出し、システム管理者またはサポートサービスに通知するためには、次のことが必要です。

1. どのメトリックを制御する必要があるかを把握します。
2. 監視対象のメトリックのしきい値を正しく設定します。

これらの質問に対する答えは、単純または複雑のいずれかであり、ITサービスが障害として理解するものに依存します。



少し前に、HPは成熟度レベル別にITサービスを分類することを提案しました。ITインフラストラクチャプロバイダー、ITサービスプロバイダー、ビジネスパートナーです。 提案された分類を使用して、最初の2つのケース（ITインフラストラクチャプロバイダーとITサービスプロバイダー）の障害と、これらのケースでのメトリックの決定方法としきい値の設定方法を検討します。 3番目のケース（ビジネスパートナーシップ）は、その複雑さとグローバル性のため、次のいずれかの記事で検討されます。

ITサービスレベル	失敗とは何ですか？
ITプロバイダー	ITインフラストラクチャに何らかの問題がある
ITサービスプロバイダー	ユーザーはITサービスを使用して職務を遂行することはできません。
ビジネスパートナー	ビジネスプロセスが停止または減速する

ITインフラストラクチャプロバイダーの障害：ITインフラストラクチャに何らかの問題がある

最も単純な場合、障害はITインフラストラクチャの誤動作です。 この場合のメトリックに関する情報は、MIB（管理情報ベース）に含まれています。 しきい値は3つの方法で設定されます。

1. メトリックがパーセント（廃棄、可用性など）で測定される場合、常識的な方法です。
2. 最も重要なメトリックについては、ソフトウェアおよびハードウェアメーカーの推奨事項に含まれる参照値があります。 この情報の重要な部分を体系化しました。結果はウェブサイトhttp://www.you-expert.ruのセクション「試験」に記載されています。
3. p。1およびp。2が不可能な場合は、ベースラインメソッドが使用されます。

ベースライン方法

ベースラインは、ITインフラストラクチャの通常の（通常の）操作を特徴付けるメトリックまたはメトリックのセットです。 ベースラインを構築するには、長期間（たとえば1か月）に取得した測定結果を統計的に処理し、平均値を取得する必要があります。これは標準と見なされます。 たとえば、10％、30％、または50％（直感的に決定される）基準を超える（モジュロ）値は、「悪い」評価に対応するしきい値と見なされます。



ベースラインを計算して表すには多くの方法があります。 最も単純な監視システムでは、これはメトリックの平均値であり、測定されたメトリックのグラフを横切る直線として表示されます。 プロのシステムでは、これらは時間に関連するいくつかの統計的推定値（通常はパーセンタイル）です。 これは、たとえば7-00と11-00のベースラインの値が2つの異なる値であることを意味します。 図2と図3は、ProLAN製品によって自動的に計算されたコアラインの例を示しています。 ベースライン20は、20分間隔でメトリックを評価し、表のように見えます。 ベースライン60は、60分間隔でメトリックを評価し、3つのグラフの形式をとります：平均、パーセンタイル75（最悪値の25％が破棄されます）、パーセンタイル90（最悪値の10％が破棄されます）。





図2.ベースライン20。





図3.ベースライン60。

ITサービスプロバイダーの失敗：ユーザーはITサービスを使用して業務を遂行できません

ITインフラストラクチャの誤動作と比較すると、このケースはより複雑で興味深いものです。 その重要性は、ITサービスの可用性がSLA（Service Level Agreement）の主要なコンポーネントであるという事実によって決まります。



多くの場合、ITサービスは、生活を簡素化するために、ITサービスの可用性をITインフラストラクチャの関連するすべてのコンポーネントの可用性として解釈します。 この単純化は小規模のアウトソーシング業者（事実上のITインフラストラクチャプロバイダー）には許されますが、成熟したITサービスプロバイダーには許されません。 これは客観的に間違っています。 典型的な例はIPテレフォニーです。 加入者間の通信をサポートするITインフラストラクチャのすべてのコンポーネントは動作可能で技術的に機能できますが、通信品質が非常に低いため、サービスを使用できません（音が鳴り、画像がフリーズします）。 したがって、ITサービスの可用性は技術的な指標ではなく、ping機器はそれを測定するのに十分ではありません。



サービスが適切に機能するメトリックの値と、それほどではないものを決定するか、ビジネスアプリケーションの応答時間（エンドツーエンドの応答時間）を測定する必要があります。



両方の方法をさらに詳しく考えてみましょう。



最初の方法は、ビジネスアプリケーションの応答時間（エンドツーエンドの応答時間）を測定することです。 ビジネスアプリケーションの応答時間を測定するには、特別なメトリックと特別な測定ツールが必要です。 GUIロボット（ SLA-ONプローブと統合されたAutoITを使用）、ネットワークプロトコルアナライザー（たとえばNetwork InstrumentsのObserver Suite ）、クライアントまたはサーバーにインストールされたソフトウェアエージェント（たとえばFifth Level ）を使用できます。 しきい値は、常識的な方法またはベースライン方法によって設定されます。



2番目の方法は、どのメトリックのどの値でサービスがうまく機能するか（ユーザーが目標を達成し、義務を果たすことができる）、および悪い（サービスを使用できない）場合にコンプライアンスを確立することです。 この場合、制御されるのはビジネスアプリケーションの反応時間ではなく、それが依存する技術的な指標です。 監視が大幅に簡素化され、安価になりました。 拡張性の低いGUIロボットや高価なアナライザーの代わりに、従来の、さらには無料の監視システムを使用できます。



実際にどのメトリック値がユーザーの快適な作業に対応するかをどのように判断できますか？

ITサービスユーザーの快適な作業に対応するポア値を決定するアルゴリズム

ストリーミングアプリケーション（音声、ビデオ）の場合、技術指標とユーザーの知覚のしきい値を一致させるタスク（またはITサービスを使用することの利便性）は、長い間解決されてきました。 シスコの機器（だけでなく）を使用するすべての人は、この機器を使用して、測定基準ではなく、技術指標から計算される（コーデックのタイプに応じて）主観的指標MOS（平均意見スコア）およびICPIFを制御できることを知っています遅延、パケット損失（実際に測定されます）。 このために、R-Valueモデルが使用されます。 関連する規格からの抜粋および通信省の注文番号113はそれらをサポートする専門家であり、トピックに関する他の情報はウェブサイトwww.you-expert.ruで見つけることができます。



ただし、UDPではなくTCP上で実行されるトランザクションアプリケーションの場合、そのような標準はありません。 つまり、テクニカルメトリックの値とユーザーの認識の間の対応を確立する必要があります。 このため、APDEX方法論（下記参照）およびProLANソリューションを使用することが提案されています。





図4. ALFAビジネスアプリケーションの操作。



通信チャネルで区切られた2つのオフィスがあるとします。 同時に、ALFAアプリケーションサーバーは1つのオフィスにあり、ALFAアプリケーションユーザーは別のオフィスにいます（図4を参照）。もちろん、ALFA名は条件付きです。 また、ルーター、アプリケーションサーバー、通信チャネル、特にジッタ、遅延、パケット損失の技術的な健全性メトリックを測定できるProLAN SLA-ON監視システム（またはその他）があるとします。



ここで、ALFAビジネスアプリケーションのユーザーが快適に作業できるように、通信事業者とのSLAに登録する必要があるジッタ、遅延、パケット損失の値について懸念しています。 また、監視システムにしきい値として導入されるため、システム管理者またはサポートサービスは、超過した場合、障害が発生したことを即座に認識できます（つまり、ユーザーは提供されたサービス-ALFAビジネスアプリケーションを使用して通常の業務を実行できません） 。





図5. ITインフラストラクチャの健全性メトリックの収集、ユーザーのパフォーマンスに関する情報、およびALFAアプリケーションの動作が不十分な場合



1.この問題を解決するには、ALFA Red Buttonアプリケーション（USBデバイス、SelfTraceプログラム、EPM-Agent Plusプログラム）の最も適切なユーザーをコンピューターにインストールします。 SelfTraceプログラムは、ユーザーがALFAアプリケーションで作業するとき（アプリケーションが開いているだけでなく、従業員が別の部門でコーヒーを飲んでいるときにキーボードのキーを押してマウスを動かす）を自動的に測定し、結果を統合データベースに転送します、図5を参照してください。



2.監視システムは、 ジッタ、遅延、パケット損失のメトリックを収集するように構成されます。これらのメトリックも統合データベースに自動的に記録され、共通のタイムラインに関連付けられます。



3. ALFAアプリケーションのユーザーは、自分の観点から職務を遂行するためにALFAアプリケーションを快適に使用できない瞬間に、「赤いボタン」を押す必要があると指示されます。 ボタンクリックの結果も自動的に統合データベースに転送され、共通のタイムラインにも関連付けられます。 したがって、統合データベースでは、 ジッタ、遅延、パケット損失のメトリックの値、ALFAアプリケーションの使用期間、およびALFAアプリケーションの動作不良に関するメッセージは、1つの共通のタイムラインに関連付けられています。



4.しきい値の計算に進みます。 統合データベースにアクセスし、 ジッタ、遅延、パケット損失のメトリックの平均値を計算する特別なアプリケーション（スクリプト）を起動します。

1. ALFAユーザーがITサービスについて不平を言ったとき（ボタンを押したとき）。
2. ユーザーの意見では、アルファではすべてが正常であった当時。

ご注意 商用のProLAN製品を使用しているアフィリエイトは、このスクリプトを無料で入手できます。



その結果、各ジッタ、遅延、パケット損失メトリックに対して、 2つのしきい値があります。

1. jitter_satisfiedおよびjitter_frustrated
2. delay_satisfiedおよびdelay_frustrated
3. パケットloss_satisfiedおよびパケットloss_frustrated

APDEX方法論によれば、 イライラした接尾辞を持つメトリックは、対応するメトリックの4倍のしきい値です。 つまり、 jitter_frustrated値が200マイクロ秒の場合、ALFAユーザーの快適な作業に対応するジッタメトリックのしきい値は50マイクロ秒です。





図6. 2、7、11、12-ジッター値は考慮されません（この時点では、ユーザーはALPHAアプリケーションで作業していません）。 5、14-を考慮して、jitter_frustratedを計算します。 1、3、4、6、8、9、10、13、15は、jitter_satisfiedの計算に考慮されます。



問題は解決しました。 しきい値を受け取りましたが、その超過はユーザーの観点からの障害を意味するため、ITサービスプロバイダー（ITサービスのユーザーの快適な操作モードの違反）を意味します。



途中で、別の重要な問題が解決されます。このサービスのパフォーマンスの観点から重要なメトリックを決定します。 たとえば、 jitter_satisfiedとjitter_frustratedの値が近いことが判明した場合、ALPHAアプリケーションを（そのパフォーマンスのために）快適に使用するためのジッタメトリックは重要ではありません。 IPチャネルの動作を特徴付けるメトリックの場合、これはあまり当てはまりません。 ただし、ルーター、アプリケーションサーバーの正常性メトリックについては、これは重要です。

APDEXテクニック

図7. APDEXテクニック。



結論として、APDEXテクニックに関するいくつかの言葉。



APDEX （アプリケーションパフォーマンスインデックス）は、アプリケーションパフォーマンスに対するユーザーの満足度を定量化する標準です。 APDEXテクニックは次のとおりです。 すべての測定結果（たとえば、ビジネスアプリケーションの応答時間の測定結果）は、3つのグループに分けられます。



最初のグループには、ユーザーの快適な作業に対応するしきい値T未満の値を持つ測定値が含まれます。 （これはまさに決定する必要があるものです。）そのような測定の数は、 Satisfied count変数の値です。ユーザーは満足しています。



2番目のグループには、値がTより大きいが4 * Tより小さい測定値が含まれます。 そのような測定値の数は、 許容カウント変数の値です。ユーザーはあまり満足していませんが、耐えることを望んでいます。



他のすべての測定値は、3番目のグループに記録されます。 測定の総数は、 Total samples変数の値です。 APDEX値は、図7の式を使用して計算されます。

ポスト台本

驚くべき事実。 巨大なロシアでの監視システムの販売は、小さなドイツのほぼ30倍です。 30という数字は保証できませんが、順序はまったく同じです。 長い間、私はそれが何に関連しているかを理解していませんでしたが、最近まで非常に大きな小売業者のITディレクターと会話をしました。 ITインフラストラクチャを監視する方法を尋ねました。 彼は、オープンソース製品の1つに名前を付けました。 私は尋ねます：「それで、あなたにどのように合いますか？」 -エンジニアは幸せです。 ユーザーは単に不満を抱き、定期的にすべてが遅くなっていると不満を漏らし、手紙が届かないこともあります。 そして、私たちのデータによると、すべてがうまく機能しています。 何ができるか分からないのですか？」