JP2004532445A

JP2004532445A - サービスプロバイダーの業績を監視するシステム及び方法

Info

Publication number: JP2004532445A
Application number: JP2002566793A
Authority: JP
Inventors: ホーング−ウェイハー; ジュンマ; チウマンラム; デイヴィッドドワイヤー; カイフチェン
Original assignee: コンピュータアソシエイツシンク，インコーポレイテッド
Priority date: 2001-02-20
Filing date: 2002-02-20
Publication date: 2004-10-21
Also published as: KR20030086268A; EP1362294A1; CN1509444A; WO2002067136A1; IL157501A0; US20070226228A1; BR0207416A; EP1362294A4; CA2438999A1

Abstract

サービスプロバイダー(200)のサービスレベルを監視する方法は、実績基準を定義し、少なくとも１つのデータ収集エージェント(205)を配備し、そして各データ収集エージェントを実行して、オペレーションデータを監視及び収集する段階を含む。この方法は、更に、各データ収集エージェントからオペレーションデータを受け取り、そしてそのオペレーションデータを集約化する段階を含む。次いで、上記実績基準及び集約化されたオペレーションデータに基づいてサービスのレベルを決定する。サービスプロバイダーのサービスレベルを監視するためのシステム及びコンピュータ読み取り可能な記憶媒体も開示される。

Description

【技術分野】
【０００１】
本発明は、一般に、ネットワークにわたって情報を監視する分野に係る。より詳細には、本発明は、ネットワークをベースとするサービスホスティング環境におけるサービスプロバイダーの実績(performance)を監視するためのシステム及び方法に係る。
【０００２】
（関連出願）
本出願は、参考としてその全体をここに援用する２００１年２月２０日出願の「System and Method For Monitoring Service Levels of an Application Service Provider」と題する米国プロビジョナル特許出願第６０／２７０，０４３号の優先権を請求するものである。
【背景技術】
【０００３】
ネットワークベースのサービスホスティングは、１つの会社が、ソフトウェアホスティングサービス、例えば、アプリケーションホスティングサービスを他の会社にオファーして、これらの会社がビジネス関連オペレーションを実行するのに使用されるソフトウェア及びハードウェアをサポートする必要がもはやないようにするビジネスモデルである。このようなビジネス関係では、提供されるべきサービスと、実行されるべきサービスのクオリティが、サービスレベルアグリーメント（ＳＬＡ）と称する契約文書において定義される。
【０００４】
このようなサービスをオファーする企業を、通常、サービスプロバイダーと称する。慣習的なサービスプロバイダー業務関係では、サービスプロバイダーの報酬が一律料金構成に基づいている。サービスプロバイダーの顧客は、現在、それらのプロバイダーを、システム使用可能時間、帯域巾、拡張性、セキュリティ、及び問題解決度に関して評価している。更に、将来、サービスプロバイダーの顧客は、それらのプロバイダーを、例えば、コスト節約、繰り返し時間の短縮、顧客保有度、及び供給チェーン効率に関して評価すると予想される。サービスプロバイダーが、顧客又は潜在的な顧客に、特定のサービスタスク及びサービスクオリティのレベルを満足させたか又は満足できると納得させるために、サービスプロバイダーは、提供したサービスがＳＬＡに適合したという証拠を与えることがしばしば求められる。信頼できる証拠がないと、ＳＬＡの施行が困難となり、従って、顧客は、このような業務関係に留まるか又はこのような業務関係に入ることを嫌がる。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
それ故、サービスプロバイダーの実績を監視し、このような実績を顧客の期待値へと容易に換算する方法及びシステムが要望される。
【課題を解決するための手段】
【０００６】
本発明は、コンピュータ処理環境においてサービスプロバイダーの実績を監視するための方法及びシステムを提供する。本発明の１つの態様によれば、サービスプロバイダーの実績を監視する方法が開示される。この方法は、実績基準を定義し、そして少なくとも１つのデータ収集エージェントを配備する段階を含む。各配備されたデータ収集エージェントは、オペレーションデータを監視及び収集するように実行され、そして各データ収集エージェントからのオペレーションデータが受け取られて集約化される。この方法は、更に、上記実績基準及び集約化されたオペレーションデータに基づいてサービスのレベルを決定する段階を含む。
【０００７】
又、サービスプロバイダーの実績を監視するシステムも開示される。このシステムは、実績基準を定義する手段と、データを収集する手段とを備えている。各配備されたデータ収集エージェントは、オペレーションデータを監視及び収集するように実行され、そして各データ収集エージェントからのオペレーションデータが受け取られて集約化される。上記方法は、更に、上記実績基準及び集約化されたオペレーションデータに基づいてサービスのレベルを決定することを含む。
【０００８】
又、ここに開示する方法を実施するための処理命令を含むコンピュータ読み取り可能な記憶媒体も開示される。
ここに開示するシステム及び方法は、サービスプロバイダーのサービスレベルを管理、計測及び報告できるようにする。ここに提案する方法及びシステムの目的、特徴及び効果は、添付図面を参照した好ましい実施形態の以下の詳細な説明から容易に明らかとなろう。
【発明を実施するための最良の形態】
【０００９】
ここに述べるシステム及び方法をより完全に理解するために、同じ部分を同じ参照番号で示した添付図面を参照して以下に詳細に説明する。
図１は、顧客とのサービスプロバイダー関係を設定し、そしてサービスプロバイダーの業績と、サービスプロバイダーにより満足された業績に基づく顧客の勘定とを監視するために双方向に使用できるサービスレベルマネージメント、サービス計測及び勘定アプリケーションを含むサービスプロバイダーシステムを例示する。本発明によるサービスプロバイダーシステムは、いかなる形式のネットワークベースのサービスプロバイダーにも使用することができる。これは、例えば、インターネットサービスプロバイダー（ＩＳＰ）、アプリケーションサービスプロバイダー（ＡＳＰ）及びマネージメントサービスプロバイダー（ＭＳＰ）を含む。
【００１０】
サービスプロバイダーと顧客との関係は、サービスレベルアグリーメント（ＳＬＡ）として知られている協約書によって定義される。ＳＬＡは、提供されるべきサービス（１つ又は複数）と、そのようなサービスを提供すべきレベルとを要約したサービスプロバイダーと顧客との間の契約である。即ち、ＳＬＡは、提供されるべきサービスに関するサービスプロバイダー及び顧客の権利と責任を定義するものである。典型的に、本発明によるサービスプロバイダーシステムでは、サービスプロバイダーは、ある指定レベルのサービスを提供することに合意し、そして顧客は、実際に提供されたサービスのレベルに基づいてサービスプロバイダーに報酬を支払うことに合意する。
【００１１】
ＳＬＡ内には又はそれに関連して、サービスレベルオブジェクティブ（ＳＬＯ）として知られている１つ以上の条件又は目的のリストがあり、これは、サービスプロバイダーが顧客に提供すると合意したサービスのレベルを定義するものである。このようなオブジェクティブは、例えば、サービスプロバイダーシステムの利用性及びアクセス可能性、並びに実行されるべきサービスの実績に関連したメトリックを含む。ＳＬＯは、一般に、顧客により希望又は要求されるサービスのレベル、及びサービスプロバイダーが提供できる又は提供しようとするサービスのレベルに基づいている。ＳＬＯは、提供されているサービス及びおそらくはＳＬＡの期間に基づいて変化し得ることに注意されたい。
【００１２】
図４を参照すれば、ここに開示する方法及びシステムは、サービスレベルアグリーメントに関連してサービスプロバイダーの実績を監視するのに使用できるサービスレベルマネージメント及びサービス計測のためのメソッドを使用する。サービスレベルアグリーメント（ＳＬＡ）は、プロバイダーにより提供されるべきサービスと、その提供されるべきサービスのクオリティとを要約したクライアント／テナントとサービスプロバイダーとの間の契約である。ここに開示する方法及びシステムは、いかなる形式のネットワークベースのサービスプロバイダーに対して使用することもできる。これは、例えば、インターネットサービスプロバイダー（ＩＳＰ）、アプリケーションサービスプロバイダー（ＡＳＰ）及びマネージメントサービスプロバイダー（ＭＳＰ）を含む。
【００１３】
サービスプロバイダー／顧客関係において、初期に、サービスプロバイダー及び顧客は、通常、サービスレベルオブジェクティブを決定する（４０５）。このサービスレベルオブジェクティブ（ＳＬＯ）は、提供されるべきサービスのクオリティ、例えば、実行されるべきサービスの利用性、アクセス可能性及び実績を定義するオペレーション条件のリストである。ＳＬＯは、一般に、顧客により希望又は要求されるサービスのレベル、及びサービスプロバイダーが提供できるか又は提供しようとするサービスのレベルに基づいている。
【００１４】
ＳＬＯは、サービスプロバイダーと顧客との間のＳＬＡに対する基礎を形成する（４１０）。ＳＬＡは、提供されるべきサービスに関するサービスプロバイダー及び顧客の権利と責任を定義するものである。典型的に、サービスプロバイダーは、ある指定レベルのサービスを提供する義務があり、そして顧客は、実際に提供されたサービスのレベルに基づいてサービスプロバイダーに支払する義務がある。
【００１５】
サービスプロバイダーにより提供されたサービスのレベルを客観的に評価するために、サービスプロバイダー及び顧客は、ＳＬＯ及びＳＬＡに基づいて１組の定量化可能な実績基準を定義する（４１５）。通常、この実績基準は、ある最小スレッシュホールドより高い又は低いサービスのレベルを顧客に与えるよう確保するように設計される。例えば、顧客は、特定の最大応答時間内のサービスを要求してもよいし、又は顧客は、１日当たり最小長さの時間中にアプリケーションにアクセスできることを要求してもよい。更に、この実績基準は、顧客及びサービスプロバイダーをサービスプロバイダー／顧客関係で満足できるように文書化できるか又は他のやり方で確認できる事象又は条件を含むよう設計されねばならない。
【００１６】
サービスレベル及び実績基準が定義されると、サービス監視手順が実施され（４２０）、従って、サービスが監視される（４２５）。サービスは、ＳＬＡの期間全体にわたり監視され、そして実績基準に関して分析される（４３０）。実際のサービスレベルが決定されると、サービスプロバイダーは、ＳＬＡに定義されたサービスの価値に基づいて列挙し直される（４３５）。
【００１７】
図５は、本発明によるサービスレベルマネージメントメソッドのフローチャートである。このサービスレベルマネージメントメソッド（ソフトウェアベースのサービスレベルマネージャーにより実施できる）は、ＳＬＡから実績基準を定義する（５０５）。サービスレベルマネージメントアプリケーションは、ブロック４０５−４１５のファンクションを実行し、定義された実績基準を形成する。この定義された実績基準は、実績を測定できるいかなる数の種々のメトリックに関係してもよい。一実施形態では、実績基準は、例えば、ユーザの特定グループ、特定のビジネスファンクション又は特定のアプリケーションに関連した基準に関係する。
【００１８】
サービス計測ソフトウェアアプリケーションは、図４に示すブロック４２０−４３５のファンクションを実行する。サービス計測ソフトウェアアプリケーションは、監視されるべきシステム全体に配備された１つ以上のデータ収集エージェントを備えている（５１０）。各データ収集エージェントは、実績基準に基づくシステムの少なくとも一部分のオペレーションを監視し、そしてシステム性能の評価に使用するためのオペレーションデータを収集するように構成される（５１５）。ＳＬＡの期間全体にわたり、各データ収集エージェントは、収集したオペレーションデータを、図３を参照して詳細に述べるデータディレクター２１５へ周期的に送信し、このディレクターは、収集したオペレーションデータを受信してそれを集約化する（５２０）。
【００１９】
サービス計測ソフトウェアアプリケーションは、その集約化されたオペレーションデータに実績基準を適用することによりサービスの実績を分析し（５２５）、そしてサービスの価値が決定される（５３０）。集約化されたオペレーションデータへの実績基準の適用は、得られた集約化されたオペレーションデータの性質に基づいて多数の方法のいずれかで行うことができる。例えば、集約化されたオペレーションデータが動作値の平均を表わす場合には、それが、実績基準で定義された最小許容平均値と比較される。別の例では、集約化されたオペレーションデータが、受け入れられない動作条件の有無を表わす場合には、集約化されたオペレーションデータは、実績基準に基づいてテストされる。
【００２０】
サービスの価値は、サービスプロバイダー及び／又は顧客に多数の方法で報告される。例えば、サービスプロバイダーは、サービスの価値を受け取り、そしてその価値を、顧客へ送られる勘定書に組み込むことができる。或いは又、サービスの価値、実績基準及び／又は集約化されたオペレーションデータが、サービスプロバイダー及び顧客の両方に送られるハードコピーレポートに組み込まれてもよい。
【００２１】
動作環境
図２は、サービスプロバイダーの実績を監視するためのサービスプロバイダーシステムを例示するブロック図である。一般に、このシステムは、データレポジトリー２３５と、サービスレベルマネージメントアプリケーション２４５と、サービス計測アプリケーション２５０とを備え、これらは、アプリケーション一体化バス２３０を経て通信する。サービスレベルマネージメントアプリケーション２４５は、サービスレベルアグリーメント、サービスレベルオブジェクティブ、及び実績基準を定義するデータをデータレポジトリー２３５に記憶しそしてそこから検索する。
【００２２】
システム２００のアプリケーション一体化バス２３０は、例えば、データレポジトリー２３５及び勘定アプリケーション２４０を含む種々の異種ソースに情報を記憶しそしてそこから情報を検索することができる。アプリケーション一体化バス２３０は、異なるコンピュータプログラム間の通信を、一貫した信頼できるやり方で容易にするインフラストラクチャーである。適当なアプリケーション一体化バスは、例えば、ニューヨーク州、アイランディアのコンピュータ・アソシエート・インターナショナル・インクにより製造されたＪａｓｍｉｎｅ_iiとしてこれまで知られているＣＡコモン・サービスアプリケーションである。
【００２３】
サービス計測アプリケーション２５０は、実績基準に関連したメトリックを監視しそしてシステムオペレーションデータを収集する１つ以上のデータ収集エージェント２０５を備えている。各データ収集エージェント２０５は、異なる技術を利用して、所定のメトリックに基づきデータを収集する。例えば、データ収集エージェント２０５は、ワークステーションのＣＰＵ使用を監視し、一方、別のデータ収集エージェント２０６は、アプリケーションの欠陥レートを監視する。１つのエージェントにより収集されたデータは、１つ以上のメトリックに対して使用することができる。データ収集エージェント２０５により収集されるオペレーションデータの量は、システムに関連したデータ収集エージェント２０５の数に基づいて拡張できる。データ収集エージェント２０５は、システムが最初に構成されるときに配備されてもよいし、又はシステムのオペレーション中に動的に追加又は除去されてもよい。
【００２４】
サービス計測アプリケーション２５０の各データ収集エージェント２０５は、サービスプロバイダーアーキテクチャーにおける特定の要素又は要素のグループを監視するように構成される。監視される要素のカテゴリーは、例えば、アプリケーション、プラットホーム、オペレーション要素及び／又はネットワーク要素を含む。メトリックが監視される要素のサブカテゴリーであって、基本的カテゴリーと異なるか又はそれよりも詳細であるサブカテゴリーが存在する。例えば、若干の例を挙げると、アプリケーションカテゴリーには、ｅ−メールサブパッケージ、ＥＲＰサブパッケージ、又は口座パッケージ等の多数のサブカテゴリーが存在する。各カテゴリー又はサブカテゴリーを定義すると、特定形式のアプリケーションからでなければ得られないアプリケーション特有のメトリックをサービス計測アプリケーション２５０で監視することができる。
【００２５】
１つ以上のデータ収集エージェント２０５によって収集されたオペレーションデータは、データディレクター２１５に転送される。このデータディレクター２１５は、データ収集エージェント２０５からオペレーションデータを受け取り、初期レベルのデータ集約化を実行し、そして特定のメトリックに対するＳＬＯを発生する。
【００２６】
オペレーションデータを集約化するのに加えて、データディレクター２１５は、生又は合併されたデータ／事象を、勘定アプリケーション２４０及び／又はサービスレベルマネージメントアプリケーション２４５のような他の要素へ向け直すこともできる。この向け直されたデータは、アプリケーション一体化バス２３０に通されるか、又は例えば公表及び契約モデルインターフェイスを経て第三者インテグレーター２２５へ送信される。データディレクター２１５は、更に、パッケージ内のデータ収集エージェント２０５に管理及び構成機能を与えると共に、要素の状態に関してマネージメントシステムにフィードバックを与える。
【００２７】
ここに示すシステムは、単一のデータディレクター２１５を含むが、別の実施形態では、データ収集エージェント２０５の数及びワークロードに基づいて２つ以上のデータディレクター２１５を含んでもよい。ここに示すシステムは、更に、データディレクター２１５が、小さなインターバルの集約化データを記憶するためのそれ自身の一時的なデータベース２２０を有することも示している。
【００２８】
サービス計測アプリケーション２５０は、サービスプロバイダーに対する限定データ収集のためのスタンドアローンモードで動作することができるし、或いは勘定アプリケーション２４０及びサービスレベルマネージメントアプリケーション２４５のような他の製品に対する一体化データ供給モードで機能することもできる。サービス計測アプリケーション２５０は、バッチ処理のためにデータディレクター２１５からデータを引き出し、又はレジスタコールバックモードにおいてリアルタイム事象に対して要求者にデータを押し出すためにインターフェイスを含む。
【００２９】
勘定アプリケーション２４０については、使用データ又は勘定可能なデータが異なるソースから得られる。一実施形態では、出力がＸＭＬにあって融通性のあるデータ交換フォーマットを与える。サービスレベルマネージメントアプリケーション２４５については、初期の集約化されたオペレーションデータが、ＳＬＡを評価するために得られる。又、あるＳＬＯ違反事象も得られる。
【００３０】
ここに示す実施形態では、サービス計測アプリケーション２５０は、ＡＳＰアグレゲーターに良く適している。というのは、データを多数のＡＳＰからアグレゲーターへアプリケーション一体化バス２３０を経てＸＭＬフォーマットで転送できるからである。又、サービス計測アプリケーション２５０は、例えば、ユーザ応答時間及びシステムアクセス可能性のような、サービスプロバイダーにより提供されるサービスのクオリティをクライアントが確認するのを助ける技術も含む。又、サービス計測アプリケーション２５０は、ベースパッケージからの所定のＳＬＯを使用してサンプルＳＬＡテンプレートも与えることができる。
【００３１】
データコレクターマスター２６０（ＤＣマスター）は、データコレクター２０５からデータディレクター２１５への要求を監視する役割を果たすシステム要素である。ＤＣマスター２６０は、心拍数情報をデータディレクター２１５へ報告し、そしてデータディレクター２３０の構成マネージャー４２５からのコマンド（１つ又は複数）に基づいてデータコレクター２０５をスタート、ストップ又はリセットすることができる。各データコレクター２１５は、ＤＣマスター２６０により監視される。単一のＤＣマスター２６０が示されているが、システムは、高いワークロードを受け入れるために２つ以上のＤＣマスター２６０を含んでもよい。
【００３２】
図３は、データディレクター２１５を更に詳細に示す図である。ここに示す実施形態では、データディレクター２１５は、ＨＴＴＰサーバー３０５、ＣＧＩスクリプト３１０、及び構成マネージャー３１５を含む。ＨＴＴＰサーバー３０５は、従来のウェブサーバーであり、データ収集エージェント２０５（１つ又は複数）及び／又は第三者インテグレーター２２５との通信を容易にする。
【００３３】
構成マネージャー３１５は、サービスレベルマネージメントアプリケーション２４５及び勘定アプリケーション２４０からアプリケーションインターフェイスバス２３０を経て受け取られた要求を取り扱う役割を果たす。構成マネージャーは、更に、オペレーションデータの集約化と、生及び集約化オペレーションデータのデータレポジトリー２３５への転送とを管理する役割も果たす。
【００３４】
オペレーションデータの集約化及び転送は、実際には、構成マネージャー３１５の指示でＣＧＩスクリプト３１０により実行される。ＣＧＩスクリプト３１０は、更に、サービス計測アプリケーション２５０への及びそこからのデータ要求を取り扱うと共に、各インターバルの後にデータレポジトリー２３５の完全性を維持し、例えば、古いデータを削除する。
【００３５】
又、データレポジトリー２３５への外部アクセスも、構成マネージャー３１５により管理される。第三者インテグレーター２２５のような許可された当事者は、構成マネージャー３１５を経てデータレポジトリーへのアクセスを要求することができる。このようなアクセスは、ＨＴＴＰ又は他の通信手段を経て行うことができ、そしてログインＩＤ及びパスワードを与える等の、ある種のセキュリティ手順を受ける。
【００３６】
サービスレベルマネージメントの概要
サービスレベルマネージメントアプリケーション２４５は、サービスプロバイダーの環境に対して設計され、そしてシステムリソースだけではなく、ビジネスオブジェクティブ及びトランザクションも管理することができる。又、アプリケーションとインターフェイスするための役割ベースのビューも与える。これらのビジネスアクティビティを実行するために、サービスレベルマネージメントアプリケーション２４５は、例えば、顧客とサービスプロバイダーとの間の契約のようなビジネスオブジェクトを使用しそして維持する。アプリケーションは、例えば、ＡＳＰアドミニストレーターが、とりわけ、カスタマイズされたＳＬＡオファーパッケージを形成し、契約及びオファーパッケージの変更を取り扱い、新たなユーザ及びユーザグループを定義し、そしてシステムからユーザを除去することができるようにする。
【００３７】
ここに述べるサービスレベルマネージメントアプリケーションは、種々の観点のサービスプロバイダーのビジネスモデルに適用するように設計され、ユーザの観点から多数の特徴を与える。例えば、ユーザは、サービスレベル目標をある組合せで定義することもできるし、或いは予め定められたリストから単に選択してもよい。サービスレベルマネージメントアプリケーションの別の特徴は、例えば、ＳＬＡのネゴシエーションをサポートすることである。サーバープロバイダーが希望すれば、ユーザは、例えば、サービスレベル目標、法的期間、料金、及びオペレーションの例外を含むＳＬＡの多数の観点を定義するための自由度をもつことができる。更に別の特徴は、ユーザが異なるユーザグループ又はビジネスファンクションに対して多数の契約に署名できることである。
【００３８】
アドミニストレーターの観点から、アプリケーションは、ユーザ及びユーザグループの管理をサポートする。ＳＬＡ契約アドミニストレーション及び管理もサポートされ、サービスプロバイダーが多数の異なる契約テンプレートをオファーできるようにする。サービスレベルマネージメントアプリケーションは、更に、ブランド付けもサポートし、これは、サービスプロバイダーが全てのＳＬＡＧＵＩ及びレポートに顧客認識でブランド付けを行えるようにする。
【００３９】
サービスレベルマネージメントアプリケーションは、種々のＳＬＯシンタックス及びロジックを取り扱う。更に、アプリケーション要素は、詳細なロギング及び「進行ポインター」が内蔵された状態で自己管理される。システム欠陥の場合には、システムは、データを失うことなく回復してデータ処理を続けることができる。
【００４０】
ここに述べるサービスレベルマネージメントアプリケーションは、サービスプロバイダーが、顧客にオファーする正確なＳＬＡを提供する必要性を満足するように設計される。システムは、このビジネスオファーの端−端オペレーションをサポートする。アプリケーションは、サービス計測ソフトウェアアプリケーションとインターフェイスして、使用、実績及びオペレーション情報を収集し、オブジェクティブサービスレベルデータを保存し、そして契約に基づきＳＬＯを処理する。又、アプリケーションは、システムの顧客とインターフェイスして、レポートにより正確なＳＬＡステートメントを提示する。
【００４１】
アプリケーションは、非常に小さなサービスプロバイダー設定から非常に大きなサービスプロバイダーオペレーションまで拡張可能である。１つの実施形態では、このような拡張性は、分散型並列処理設計を使用して達成され、多数の要素が一緒に機能してデータ処理を完了できるようにされる。
【００４２】
役割に基づくＳＬＡ処理
ユーザの役割に基づいて多数の異なる構成が考えられる。サービスレベルマネージメントアプリケーションは、関連情報を処理し、ＳＬＡレポートを提示する。アプリケーションは、サービスプロバイダーと、例えば、エンドユーザ、企業組織、別のサービスプロバイダー、ＡＳＰアグレゲーター、ＩＳＰ／ＮＳＰ、ＩＳＶ又はシステム売主との間の多数のビジネス関係をサポートする。
【００４３】
分散型処理エンジン
サービスレベルマネージメントアプリケーションは、いかなるサイズのサービスプロバイダーに対しても配備することができる。通常、アプリケーションは、サービス計測データベースにローカル又はリモートでアクセスする単一マシンに対して配備される。
【００４４】
より大きな環境において、単一コンピュータでは、スケジュールタスクを完了するに充分なスループットをもてないことが考えられる。アプリケーションは、契約データを区切り、そしてあるデータを処理のために分散型ＳＬＡエンジンに指定することができる。単一契約及びサービス定義データベースは、この分散型環境にサービスし、従って、システムは、多数のデータベースの中で困難な同期ファンクションを実行する必要はない。
【００４５】
ＳＬＡエンジンは、ユーザ契約ＳＬＯをほぼリアルタイム形態で処理するように設計される。ＳＬＯ違反が生じた短時間後に、アプリケーションは、ある事象を発生する。更に、ＳＬＡシステムにより実行されるトランザクション及びプロセスは、監査され記録される。ＳＬＡ要素において、トランザクション及び処理ロジックは、処理の前に、永続的記憶装置に記録される。次いで、プロセスは、各完了したタスクを「終了(sign off)」する。これは、次に何を処理する必要があるかの「ポインター」をシステムに与える。これは、システムが、重要な情報を失ったり冗長に処理したりすることなく、欠陥から回復できるようにする。
【００４６】
プロビジョニング
あるケースでは、ＳＬＡを周期的に更新することが必要である。ＳＬＡのプロビジョニング(provisioning)は、監視されるべきメトリックの定義及びそれに関連した時間フレームを含むサービス定義及び契約データテーブルのデータを変更するだけで容易に達成することができる。プロビジョニングされた変更は、変更の直後に作用を及ぼす。換言すれば、ＳＬＡのプロビジョニングは、リアルタイム形態で達成することができる。
【００４７】
あるケースでは、ＳＬＡが契約に相関するので、以前の契約の満了時点でその満了した契約を新たな契約に置き換えるのではなく、プロビジョニングオペレーションを実行するのが良い。この状況は、ＳＬＯ／メトリック計算、スレッシュホールド値、及びサービス監視にも適用できる。サービスレベルマネージメントアプリケーション２４５は、これら両方のケースを満足することができる。
【００４８】
契約ブレークポイント
例えば、契約内容、サービス定義、契約詳細又は期間の変更のようなある種の変更は、契約期間が満了する前にＳＬＡレポート又は契約に影響を及ぼす。このような変更を受け入れるために、サービスレベルマネージメントアプリケーションは、既存のＳＬＡ／契約の終了と、新たなものの開始とをマークする適切な「ブレークポイント」をカレンダーに登録することができる。このブレークポイントに基づいてアプリケーションが報告を発生するか又は契約サービスレベルを再検討するときには、アプリケーションは、成果について２つの主張を発生する。その１つは、変更前の詳細に関するものであり、そしてもう１つは、変更後の詳細に関するものである。もし必要であれば、監視された結果の真の値を反映するように時間に基づいて両方の成果を比例配分してもよい。
【００４９】
時間ゾーン
サービスレベルマネージメントアプリケーションは、ＳＬＡ契約により駆動される多数の時間ゾーンを取り扱い、これにより、地理に関わりなく全てのユーザを一貫したやり方でサポートする。サービスプロバイダーはしばしばグローバルなネットワークにおいてサービスを提供するので、そのサービスは、多数の地理的位置及びオペレーションモデルに及ぶ。サービスプロバイダーは、世界中のいかなる国からのサービスも利用するユーザを有することが考えられる。
【００５０】
ユーザの地理的位置に基づき時間ゾーンの問題を取り扱うために多数の解決策が考えられる。サービスレベルマネージメントアプリケーションの１つの実施形態は、インターバルタイムスタンプをＧＭＴ時間に同期するものである。従って、サービスプロバイダー「ベース」ユーザ時間ゾーンに基づいて、サービスプロバイダーは、全ての必要なクロック計算を実行する。
【００５１】
例えば、サービスプロバイダーのユーザがニューヨークの主要位置において契約すると仮定する。更に、９ａｍと５ｐｍＥＳＴとの間の監視しか必要としないＳＬＯとの単一の契約があると仮定する。このユーザが西海岸へ旅行しそしてサービスプロバイダーにアクセスしたときには、サービスプロバイダーは、ユーザが実際に異なる時間ゾーンのサービスを利用するかどうかに関わらず、依然として東海岸の時間ゾーンにおける実績をベースとする。
【００５２】
オペレーション停止除外
サービスレベルマネージメントアプリケーションは、週末や休日のようなスケジュールされたオペレーション停止を取り扱う。これらの除外期間中に停止が生じた場合には、「利用性」計算は、計算式においてこれらの期間を除外する。
【００５３】
複合ＳＬＯシンタックスのサポート
ほとんどの場合に、ＳＬＯは、次のように見える。
"For App[A], metric [M] will not [operator] than [threshold] based on
[interval]"
あるケースでは、上記ステートメントは、この状態に依存する別のオペレーションと共に、単にＳＬＯ違反の「第１ステップ」として働くだけである。例えば、違反は、次のように定義される。
"For App[A], metric [M] will not [operator] than [threshold] based on
[interval]" AND "When this situation happens [T] times in [interval]"
ＳＬＯ違反定義の別の例は、次の通りである。
"For App[A], metric [M1] will not [operator1] than [threshold1] based
on [interval1]" AND "For App[A], metric [M2] will not [operator2]
than [threshold2] based on [interval2]"
ＳＬＡエンジンは、両方のケースを取り扱うことができる。更に、このエンジンは、実用的な枚数のスレッシュホールド及びインターバルチェック層を取り扱うことができる。
【００５４】
融通性のあるオファーパッケージ
サービスレベルマネージメントアプリケーションは、メトリックをグループ編成しそしてＳＬＯスレッシュホールド及び値を指定することにより、カスタマイズされたＳＬＯオファーパッケージを構築する能力をサービスプロバイダーのアドミニストレーターに与える。更に、アプリケーションは、ＡＳＰが、サービスプロバイダーのビジネス目標に適合するような束及び価格体系を形成できるようにする。極端なケースでは、サービスプロバイダーは、サービスプロバイダーのユーザにネゴシエーションに対して完全な融通性を与える「自由形態」のＳＬＯパッケージをオファーすることができる。
【００５５】
ウェブベースのＧＵＩ
このシステムの異なるユーザに対し、それらの役割に基づいて個別のＧＵＩが得られる。図６は、サービスレベルマネージメントアプリケーション内で定義される役割及び行われるアクションの例を示すメニューハイアラーキーである。
【００５６】
報告
ここに開示する方法及びシステムは、サービスプロバイダーアプリケーションの実績を文書化するためにウェブベースのＳＬＡ報告をサポートする。ほとんどの報告は、契約者にサービスレベルを報告するために契約期間の終りに準備される。ここに開示する方法及びシステムによりサポートされる報告は、例えば、ＳＬＯ違反及び測定データ値に関する詳細を含む違反報告と、単一契約観点からＳＬＡを記述したＳＬＡ契約報告と、測定データ値に基づいて実績の詳細を与える実績報告とを含む。図７及び８は、ここに開示するシステムによりサポートされる報告の形式を例示する。
【００５７】
ＳＬＡシステム容量
ここに述べるＳＬＡエンジンによれば、ＳＬＯ／メトリック処理能力は、付加的なサービス計測パッケージを適用することにより拡張できる。各サービス計測パッケージは、付加的なモニタ技術及びサポートされるメトリックを定義する。又、ＳＬＡシステムに適用できる各付加的なサービス計測パッケージにより、良好に定められたメトリック定義文書も供給される。
【００５８】
サービス計測の概要
一実施形態では、サービス計測ソフトウェアアプリケーション２５０は、ブロック４２０−４３５のファンクションを実行する役割を果たす。サービス計測ソフトウェアアプリケーション２５０は、サービスプロバイダー及びその顧客が、そのシステムの使用量及び性能を計測できるようにする。又、サービス計測アプリケーション２５０は、システムのアクティビティを反映する量的分析のための実質的なデータも与える。サービス計測アプリケーション２５０は、アプリケーションが種々のソース及び異なるアプリケーションから有用な情報を収集できるようにするデータ収集技術（１つ又は複数）を使用することができる。
【００５９】
サービス計測アプリケーション２５０は、システム全体にわたって収集されたデータの形式を反映するための多数の予め定められたＳＬＯを含む。これは、多数のＡＳＰからのメトリックを計算するためにＡＳＰアグレゲーターにより使用することができる。又、これは、クライアントが、サービスプロバイダーにより提供されるサービスのクオリティを確認するための確認ツールとしても使用できる。
【００６０】
サービス計測アプリケーション２５０は、少なくとも１つのデータ収集エージェント２０５及びデータディレクター２１５を含む。データ収集エージェント２０５は、例えば、リアルタイム事象、トランザクションデータ及び生のデータを含む多数のメトリックの情報を収集するための技術を含む。
【００６１】
現在、多数のサービスプロバイダーがそれらのクライアントに一律料金を課している。上述したサービス計測アプリケーション２５０では、サービスプロバイダーは、そのクライアントに提供されるサービスのクオリティレベルを区別することができる。例えば、サービスプロバイダーは、使用時間、トランザクションの回数、期間、又は転送バイト数により課金することができる。通常、顧客は、サービスプロバイダーを、使用可能時間、帯域巾、拡張性、セキュリティ、及び問題解決度に関して計測する。将来、顧客は、それらのプロバイダーを、コスト節約、繰り返し時間の短縮、顧客保有度、及び供給チェーン効率に関して計測することを希望する。サービス計測アプリケーション２５０は、サービスプロバイダーが現在及び将来の顧客の期待に合致できるようにする。
【００６２】
ここに例示したサービスレベルマネージメント及びサービス計測アプリケーションは、例えば、アプリケーション、プラットホーム、オペレーション及びネットワークのような幾つかの分類に基づいてシステムリソースを管理及び計測できるようにする。
【００６３】
ここに開示したシステム及び方法は、特定の実施形態及び用途に関して説明したが、当業者であれば、この教示に鑑み、本発明の精神又は範囲から逸脱せずに、種々の変更、置き換え及び修正を含む付加的な実施形態も考え得るであろう。従って、添付図面を参照した上記の説明は、システム及び方法の理解を容易にするものであって、本発明をこれに限定するものではないことを理解されたい。
【図面の簡単な説明】
【００６４】
【図１】サービスプロバイダーシステムを例示するブロック図である。
【図２】本発明の一実施形態によりサービスプロバイダーの実績を監視するシステムを示すブロック図である。
【図３】図２のデータディレクターの一実施形態における要素を示すブロック図である。
【図４】サービスプロバイダーの実績を監視するプロセスであって、本発明の一実施形態に基づきサービスレベルの管理及びサービス計測メソッドを含むプロセスの機能的ブロック図である。
【図５】本発明の方法の一実施形態に基づくサービスプロバイダーの実績を監視するサービス計測メソッドを例示するフローチャートである。
【図６】サービスレベルマネージメントアプリケーションの一実施形態のメニューハイアラーキーを例示する図である。

Claims

サービスプロバイダーの実績を監視する方法であって、
実績基準を定義し、
少なくとも１つのデータ収集エージェントを配備し、
各データ収集エージェントを実行して、オペレーションデータを監視及び収集し、
各データ収集エージェントからオペレーションデータを受け取り、
上記オペレーションデータを集約化し、そして
上記実績基準及び集約化されたオペレーションデータに基づいてサービスのレベルを決定する、
という段階を備えた方法。
上記実績基準は、上記データ収集エージェントの数に基づいて拡張可能である請求項１に記載の方法。
上記実績基準は、ユーザのグループに関連した基準を含む請求項１に記載の方法。
上記実績基準は、業務機能に関連した基準を含む請求項１に記載の方法。
少なくとも１つの付加的なデータ収集エージェントを配備する段階を更に備えた請求項１に記載の方法。
少なくとも１つのデータ収集エージェントをサービスから除去する段階を更に備えた請求項１に記載の方法。
上記オペレーションデータの一部分に関連した領域時間ゾーンに基づいて上記オペレーションデータの少なくとも一部分を変換する段階を更に備えた請求項１に記載の方法。
上記集約化されたオペレーションデータを第三者のインテグレーターにエクスポートする段階を更に備えた請求項１に記載の方法。
上記集約化されたオペレーションデータに対して公表されたインターフェイスを発生する段階を更に備えた請求項８に記載の方法。
サービスプロバイダーの実績を監視するシステムであって、
実績基準を定義する手段と、
オペレーションデータを監視しそして収集する手段と、
オペレーションデータを受け取る手段と、
オペレーションデータを集約化する手段と、
上記実績基準及び集約化されたオペレーションデータに基づいてサービスのレベルを決定する手段と、
を備えたシステム。