(57)【要約】【課題】ＳＬＯのＳＬＡ違反についてサービス提供者とユーザとの間の折衝コストを減らす。【解決手段】ユーザシステムにおいて提供されるサービスレベルを、サービスレベル管理システムが管理する方法を開示する。前記サービスレベル管理システムは、サービスレベル項目の異常の責任の所在について規定する責任判定ルールを保持し、前記ユーザシステムについての所定期間のログデータを取得し、前記ログデータを参照し、前記所定期間おける前記サービスレベル項目の異常の責任の所在について、前記責任判定ルールに基づき判定を行い、前記判定の結果に基づき、前記所定期間における前記サービスレベル項目の実績値の最良値と最悪値とを決定し、前記決定された最良値と最悪値とを示す情報を出力する。【選択図】図３
2015138484.tif 000002
【特許請求の範囲】
【請求項１】
ユーザシステムにおいて提供されるサービスレベルを管理する、サービスレベル管理システムであって、
サービスレベル項目の異常の責任の所在について規定する責任判定ルールを保持し、
前記ユーザシステムについての所定期間のログデータを取得し、
前記ログデータを参照し、前記所定期間おける前記サービスレベル項目の異常の責任の所在について、前記責任判定ルールに基づき判定を行い、
前記判定の結果に基づき、前記所定期間における前記サービスレベル項目の実績値の最良値と最悪値とを決定し、
前記決定された最良値と最悪値とを示す情報を出力する、サービスレベル管理システム。
【請求項２】
請求項１に記載のサービスレベル管理システムであって、
前記最悪値及び最良値と共に、前記異常それぞれの責任の所在についての判定結果を出力する、サービスレベル管理システム。
【請求項３】
請求項１に記載のサービスレベル管理システムであって、
前記サービスレベル項目について異常の条件を規定する異常判定ルールを保持し、
前記ログデータにおいて前記異常判定ルールが示す条件が満たされる場合に、前記所定期間において前記異常が発生していると判定する、サービスレベル管理システム。
【請求項４】
請求項３に記載のサービスレベル管理システムであって、
ユーザ毎に、異常判定ルールとサービスレベル項目との関係を管理する、異常判定ルール情報と、
ユーザ毎に、サービスレベル項目と責任判定ルールとの関係を管理する、責任ルール情報と、
ユーザ毎に、実測値計算ルールとサービスレベル項目との関係を管理する、集計ルール情報と、を保持し、
ユーザ毎に、前記異常判定ルール情報から、前記ユーザシステムのユーザ及び前記サービスレベル項目に関連づけられている前記異常判定ルールを選択し、
責任ルール情報から、前記ユーザ及び前記サービスレベル項目に関連付けられている前記責任判定ルールを選択し、
前記最良値及び前記最悪値を計算するために、前記集計ルール情報から、前記ユーザ及び前記サービスレベル項目に関連付けられている実測値計算ルールを選択する、サービスレベル管理システム。
【請求項５】
請求項４に記載のサービスレベル管理システムであって、
前記ユーザ及び前記サービスレベル項目の、前記異常判定ルール、前記責任判定ルール、及び前記実測値計算ルールを出力する、サービスレベル管理システム。
【請求項６】
請求項１に記載のサービスレベル管理システムであって、
前記最良値と最悪値とに対する前記ユーザシステムのユーザからの訂正入力を受け付け、
前記訂正入力に基づいて、前記サービスレベル項目の異常の責任の所在について、再判定を行い、
前記再判定の結果に基づき、前記最良値と最悪値とを再決定し、
前記再決定された最良値と最悪値とを示す情報を出力する、サービスレベル管理システム。
【請求項７】
請求項６に記載のサービスレベル管理システムであって、
前記訂正入力は、前記ログデータから選択された、当該訂正の根拠となる情報を含む、サービスレベル管理システム。
【請求項８】
請求項６に記載のサービスレベル管理システムであって、
前記訂正入力は、前記サービスレベル管理システムの外部からアップロードされた、当該訂正の根拠となる情報を含む、サービスレベル管理システム。
【請求項９】
請求項６に記載のサービスレベル管理システムであって、
前記訂正入力に基づき、前記サービスレベル項目に適用する責任判定ルールを更新する、サービスレベル管理システム。
【請求項１０】
請求項６に記載のサービスレベル管理システムであって、
前記サービスレベル項目について異常の条件を規定する異常判定ルールを保持し、
前記異常判定ルールに基づき、前記所定期間において前記異常が発生した異常期間チャンクを特定し、
前記責任判定ルールに基づき、前記異常期間チャンクそれぞれの責任が前記ユーザシステムを提供する事業者にあるか否かを判定し、
前記所定期間における異常期間チャンクと非異常期間チャンクとを示す画像を生成し、
前記異常期間のうち、ユーザからの訂正入力により否定された回数が閾値を超える責任判定ルールが適用されている異常期間チャンクを、他の異常期間チャンクよりも強調して示す、サービスレベル管理システム。
【請求項１１】
請求項３に記載のサービスレベル管理システムであって、
前記異常判定ルールに基づき、前記所定期間において前記異常が発生した異常期間チャンクを特定し、
前記異常期間チャンクのそれぞれについて、前記責任判定ルールに基づき、責任の所在が、前記ユーザシステムを提供する事業者、当該事業者以外、及び不明のいずれであるか判定し、
正常期間チャンク、責任の所在が前記事業者外である異常期間チャンク、及び責任の所在が不明である異常期間チャンクの合計を、最大みなし非異常期間と決定し、
正常期間チャンク、及び責任の所在が前記事業者外である異常期間チャンクの合計を、最小みなし非異常期間と決定し、
前記最大みなし非異常期間から前記最良値を決定し、前記最小みなし非異常期間から前記最悪値を決定する、サービスレベル管理システム。
【請求項１２】
請求項３に記載のサービスレベル管理システムであって、
前記異常判定ルールに基づき、前記所定期間において前記異常が発生した異常期間チャンクを特定し、
前記異常期間チャンクのそれぞれについて、前記責任判定ルールに基づき、責任の所在が、前記ユーザシステムを提供する事業者、当該事業者以外、及び不明のいずれであるか判定し、
正常期間チャンク、及び責任の所在が前記事業者外である異常期間チャンクの合計を、最大みなし非異常期間と決定し、
正常期間チャンクの合計を、最小みなし非異常期間と決定し、
前記最大みなし非異常期間から前記最良値を決定し、前記最小みなし非異常期間から前記最悪値を決定する、サービスレベル管理システム。
【請求項１３】
請求項１に記載のサービスレベル管理システムであって、
複数のサービスレベル項目のそれぞれについて実績値の最良値と最悪値とを決定し、当該決定した複数のサービスレベル項目の最良値と最悪値とを、一つの画像において出力し、
前記複数のサービスレベル項目のうち、基準値が最悪値から最良値の間にある重要サービスレベル項目を決定し、
前記重要サービスレベル項目の情報を、他のサービスレベル項目の情報よりも強調して示す、サービスレベル管理システム。
【請求項１４】
請求項３に記載のサービスレベル管理システムであって、
前記異常判定ルールに基づき、前記所定期間において前記異常が発生した異常期間チャンクを特定し、
前記責任判定ルールに基づき、前記異常期間チャンクそれぞれの責任が前記ユーザシステムを提供する事業者にあるか否かを判定し、
前記所定期間における異常期間チャンクと非異常期間チャンクとを示す画像を生成し、
前記事業者に責任があると判定した異常期間チャンクのうち、期間長が閾値を超える異常期間チャンクを、他の異常期間チャンクよりも強調して示す、サービスレベル管理システム。
【請求項１５】
ユーザシステムにおいて提供されるサービスレベルを、サービスレベル管理システムが管理する方法であって、
前記サービスレベル管理システムは、サービスレベル項目について予め設定されている、責任判定ルールを保持し、
前記サービスレベル管理システムが、前記ユーザシステムについての所定期間のログデータを取得し、
前記サービスレベル管理システムが、前記ログデータを参照し、前記所定期間おける前記サービスレベル項目の異常の責任の所在について、前記責任判定ルールに基づき判定を行い、
前記サービスレベル管理システムが、前記判定の結果に基づき、前記所定期間における前記サービスレベル項目の実績値の最良値と最悪値とを決定し、
前記サービスレベル管理システムが、前記決定された最良値と最悪値とを示す情報を出力する、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービスレベルの管理に関する。
【背景技術】
【０００２】
ネットワークを介して、ＩＴリソースを提供するサービス形態（以下、クラウドサービス）には、コンピューティングリソースやネットワークなどのＩＴインフラを提供するＩａａＳ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  ａｓ  ａ  Ｓｅｒｖｉｃｅ）や、ソフトウェアの開発・実行基盤を提供するＰａａＳ（Ｐｌａｔｆｏｒｍ  ａｓ  ａ  Ｓｅｒｖｉｃｅ）、Ｗｅｂアプリケーションを提供するＳａａＳ（Ｓｏｆｔｗａｒｅ  ａｓ  ａ  Ｓｅｒｖｉｃｅ）などがある。
【０００３】
クラウドサービスでは、一般に複数の顧客（ユーザの例）が共有する物理的なリソースの上で、仮想的なリソースが各顧客に提供される。このようなシステム形態をマルチテナント型のアーキテクチャと呼ぶことがある。例えば、サーバを提供するサービスの場合には、物理マシン上に構築された仮想マシン（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ、  以下、ＶＭと呼ぶ）が、各顧客に提供される。
【０００４】
クラウドサービスでは、クラウドサービスを提供する事業者（サービス提供者の例）と、クラウドサービスを利用する顧客の間で、サービスレベルアグリーメント（Ｓｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ａｇｒｅｅｍｅｎｔ、  以下、ＳＬＡと呼ぶ）を締結する。ＳＬＡとは、事業者が顧客に提供するべきクラウドサービスの内容とその品質水準（サービスレベル）に関する取り決めである。
【０００５】
また、サービスレベル項目（Ｓｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ｏｂｊｅｃｔｉｖｅｓ、  以下、ＳＬＯと呼ぶ）とは、ＳＬＡを遵守するために定められた保証値（場合によっては目標値）が設定された項目である。ＳＬＯは、例えば、ＳＬＯ名「ＶＭの月間稼働率」、その保証値「９９．９％以上」のように設定される。
【０００６】
ＳＬＯの実績値が保証値を達成できなかった場合、すなわち、ＳＬＡ違反時には、顧客は事業者に対して、契約内容に応じた責任要求をする。例えば、契約内容によっては返金規定を伴う。ＳＬＯの実績値（以下、ＳＬＯ実績値、あるいは単に実績値と呼ぶ）と保証値を定期的に比較し、違反時に改善策を取ることをサービスレベル管理（Ｓｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ｍａｎａｇｅｍｅｎｔ、  以下、ＳＬＭ）と呼ぶ。なお、以降では、サービスレベル（Ｓｅｒｖｉｃｅ  Ｌｅｖｅｌ）のことをＳＬと略記する。
【０００７】
ＳＬＭに関する従来技術としては、ＳＬＯの測定及び計算に必要な情報が全て取得できる環境で、ＳＬＯ実績値を計算する技術が提案されている。特許文献１は、必要な情報が全て取得できる環境上で、監視システムを構築し、その監視データを用いてＳＬＯ実績値を計算する技術を開示する。
【０００８】
特許文献２は、必要な情報が全て取得できる環境で、その取得データの一部が未取得の場合にも、過去の数値からＳＬＯの実績値を推測できる。例えば、「１日のリクエストの９８％以上が応答時間３秒以内達成」とＳＬＯを定めた場合に、１日の途中でもＳＬＯの実績値を計算できる。これは、未取得である１日分のリクエスト数を過去の数値から推測することで実現される。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２０１０−２５７２７２号公報
【特許文献２】国際公開第２０１３／０１５２９２号パンフレット
【発明の概要】
【発明が解決しようとする課題】
【００１０】
ＳＬＡには、曖昧さが含まれる場合がある。例えば、ＳＬＯの計算方法や違反対象外とする例外事項の全てを事前に列挙できない場合がある。例えば、例外事項として、「顧客所有のソフトウェアの不具合による停止期間は違反対象外とみなす」と定められていた場合に、「顧客所有のソフトウェアの不具合による停止」を全て事前に定義することは難しい。
【００１１】
または、ＳＬＯの計算に必要な情報を、事業者あるいは顧客のどちらか一方だけでは、全て揃えられない場合がある。マルチテナント型のアーキテクチャでは、複数の顧客が共有しているリソースの情報については、各顧客に全て開示することはできない。他の例としては、顧客がクラウド上に構築したアプリケーションに関する情報について、事業者は閲覧できないことがある。
【００１２】
このような情報の非対称性が、ＳＬＡ遵守状況に関して、事業者と顧客間の認識の相違を引き起こすことがある。例えば、事業者が常に把握できるハイパーバイザまでのログでは、ＶＭが正常稼働しているように見えても、顧客が管理しているＯＳ以上のログでは異常が発生している場合などが考えられる。
【００１３】
つまり、顧客との事前の取り決め、事業者の持っている情報だけでは、ＳＬＡ違反の有無を判断しきれない場合がある。その場合、協議が必要で、事業者と顧客の双方にコストがかかる。
【００１４】
特許文献１及び２はＳＬＯの測定と計算を行う。しかし、例外事項の考慮が必要な部分や、違反が発生したかどうかが曖昧な領域については協議が必要である。したがって、サービス提供者が保持する情報だけではＳＬＡ違反の有無を判断しきれないＳＬＯが保証対象である場合に、サービス提供者とユーザによるＳＬＭを支援し、コストを低減することができる技術が望まれる。
【課題を解決するための手段】
【００１５】
本発明の一態様は、ユーザシステムにおいて提供されるサービスレベルを管理する、サービスレベル管理システムであって、サービスレベル項目の異常の責任の所在について規定する責任判定ルールを保持し、前記ユーザシステムについての所定期間のログデータを取得し前記ログデータを参照し、前記所定期間おける前記サービスレベル項目の異常の責任の所在について、前記責任判定ルールに基づき判定を行い、前記判定の結果に基づき、前記所定期間における前記サービスレベル項目の実績値の最良値と最悪値とを決定し、前記決定された最良値と最悪値とを示す情報を出力するものである。
【発明の効果】
【００１６】
本発明の一態様によれば、ＳＬＭコストを低減できる。
【図面の簡単な説明】
【００１７】
【図１】本発明の実施形態の概念図である。
【図２】ＳＬＭサーバにおけるＳＬＯ実績値の計算処理の概要を示す模式図である。
【図３】コンピュータシステムを模式的に示す図である。
【図４】ログデータテーブルの例を示す図である。
【図５】システムの構成情報テーブルの例を示す図である。
【図６】ＳＬ異常判定ルールテーブルの例を示す図である。
【図７】ＳＬ異常判定結果テーブルの例を示す図である。
【図８】責任判定ルールテーブルの例を示す図である。
【図９】責任判定結果テーブルの例を示す図である。
【図１０】ＳＬＯ実績値集計ルールテーブルの例を示す図である。
【図１１】ＳＬＯ実績値テーブルの例を示す図である。
【図１２】ＳＬＭポータルのＳＬＯ実績値計算及び表示処理の全体のフローチャートである。
【図１３】ＳＬＭポータルのＳＬ異常判定プログラムによる、ＳＬ異常判定処理の詳細フローチャートである。
【図１４】ＳＬＭポータルの責任判定プログラムによる、責任判定処理の詳細フローチャートである。
【図１５】ＳＬＭポータルのＳＬＯ実績値集計プログラムによる、ＳＬＯ実績値集計処理の詳細フローチャートである。
【図１６】ＳＬＯ実績値表示画像の例を示す図である。
【図１７】ＳＬＯ実績値表示画像の例を示す図である。
【図１８】ＳＬＯ実績値の訂正入力画像の例である。
【図１９】ＳＬＯ実績値修正プログラムによる、承認時におけるＳＬＯ実績値再計算処理の詳細フローチャートである。
【図２０】ＳＬＯ実績値修正プログラムによる、訂正入力時におけるＳＬＯ実績値再計算処理の詳細フローチャートである。
【図２１】ＳＬＯ実績値修正プログラムによる、訂正内容承認時におけるＳＬＯ実績値再計算処理の詳細フローチャートである。
【発明を実施するための形態】
【００１８】
以下、添付図面を参照して本発明の実施形態を説明する。本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。各図において共通の構成については同一の参照符号が付されている。
【００１９】
本実施形態は、ユーザに提供されるサービス内で発生するログを入力として、ＳＬＯ実績値を計算、表示するＳＬＭシステムを開示する。本実施形態のＳＬＭシステムは、ＳＬＯ実績値の計算方法や例外事項の定義をルールベースで管理し、曖昧な部分を明示することで、より正確な実績値を計算するためのコストを削減できる。
【００２０】
より具体的には、本実施形態のＳＬＭシステムは、サービスにおいて発生する異常において、サービス提供者がルールベースで責任の所在を特定できる範囲とできない範囲を切り分ける。ＳＬＭシステムは、サービス提供者の責任の有無が曖昧な部分を特定し、ＳＬＯ実績値の最良値と最悪値とを計算し、提示する。
【００２１】
ＳＬＯ実績値の最大値と最小値とを示すことによって、ユーザ及びサービス提供者は、ＳＬＡ違反の有無について確認すべき範囲を、ＳＬＡ違反の有無が曖昧な部分に絞ることができる。この結果、ＳＬＭコストが低減される。
【００２２】
例えば、ＳＬＯ実績値の最悪値が保証範囲内である場合、又は最良値が保証範囲外にある場合、ユーザによる確認は不要である。最良値が保証範囲内にあり、最悪値が保証範囲外にある場合、ユーザは、ＳＬＡ違反について確認を行う。このように、ＳＬＯ実績値の範囲を示すことで、ユーザ及びサービス提供者が、確認範囲をＳＬＡ違反の有無が曖昧な部分に絞ることができる。
【００２３】
一例において、ＳＬＭシステムは、対象期間における、最良値と最悪値で画定されるＳＬＯ実績値の範囲と共に、各異常の責任の所在と、そのように判定した理由を提示する。これにより、対象期間における複数の異常において、ユーザ及びサービス提供者が、確認範囲を、サービス提供者責任の有無が曖昧な部分に絞ることができる。
【００２４】
ＳＬＭシステムは、ＳＬＯ実績値の計算結果に対する、ユーザからの反論を受け付けてもよい。ユーザからの反論に応じてＳＬＯ実績値を再計算・調整することで、ユーザとサービス提供者との間の協議コストを削減できる。例えば、サービス提供者が、ユーザシステムにおける全ての情報を取得できない場合、曖昧な部分に対して反論に必要な情報を顧客がＳＬＭシステムにアップロードする。ＳＬＭシステムは、反論に応じて実績値を再計算し、システム提供者に提示する。これにより、ユーザとシステム提供者との間で、ＳＬＯ実測値を効率的に調整でき、ユーザとシステム提供者と間の折衝コストを低減できる。
【００２５】
図１は、本実施形態の概念図の一例を示す。事業者１５１がＳＬＭ機能をポータル１２３として実現し、クラウドの運用管理サービスとして顧客１５２に提供する例を説明する。本実施形態では、事業者１５１が、事業者側のログ（ハードウェア１０７、ハイパーバイザ１０６のログ）と、顧客ログの一部（ＯＳ１０５のログなどの標準的なログ）を預かることを想定する。事業者１５１はサービス提供者の例であり、顧客１５２はユーザの例である。以下に説明する例においては、実測値の最大値が最良値であり、最小値が最悪値である。
【００２６】
図の左側は、ＳＬＭの対象となる顧客のシステム１０１である。また、図の右側は、ＳＬＭ機能を提供するサーバ（ＳＬＭサーバ）１２１である。図中の矢印は、データの流れ、又は、事業者と顧客からの操作入力を表している。
【００２７】
顧客システム１０１においては、ＯＳ１０５上で、ミドルウェアプログラム１０３及びアプリケーションプログラム１０２が動作している。さらに、監視エージェント１０４が動作しており、ＯＳ１０５のログをＳＬＭサーバ１２１に送信する。
【００２８】
ＳＬＭサーバ１２１は、顧客システム１０１のハードウェア１０７及びハイパーバイザ１０６のログデータを、監視エージェント１１０を介して収集する。監視エージェント１１０は、顧客Ａのシステム１０１、ＳＬＭサーバ１２１又はネットワーク上の他装置上で動作している。
【００２９】
ＳＬＭサーバ１２１は、ＯＳ１０５のログデータを、監視エージェント１０４を介して収集する。ＳＬＭサーバ１２１は、収集したログデータを、ログデータベースプログラム１２２を介して、データベース１２４に格納する。
【００３０】
ＳＬＭサーバ１２１は、ログデータとＳＬＯ実績値の計算方法を入力として、違反（言い換えると事業者責任によるＳＬ異常）と判断できる範囲とできない範囲を切り分けて、ＳＬＯ実績値の取り得る範囲（最大値及び最小値）を計算する。そして、計算したＳＬＯ実績値を、その根拠と共に顧客１５２に提示する。
【００３１】
本実施形態の利用例としては、例えば、ＳＬＭサーバ１２１は、月次を契機にＳＬＯ実績値を計算し、それを顧客にレポートする。顧客１５２はその結果を見て、訂正要求があればフィードバック入力を行い、必要に応じてＳＬＯ実績値を修正する。
【００３２】
本実施形態のＳＬＭサーバにおけるＳＬＯ実績値の計算処理の概要を、図２に示す模式図を用いて説明する。ＳＬＭサーバ１２１は、ＳＬＯの計算対象期間を、事業者責任の異常かどうか判断できる範囲とできない範囲を切り分けたうえで、ＳＬＯ実績値の取り得る範囲（最大値及び最小値）を計算する。
【００３３】
ステップ１において、ＳＬＭサーバ１２１は、ＳＬＯの計算対象期間のログ及び指定されているルールに基づいて、ＳＬに異常が発生していた期間を判定し、正常期間のチャンク２０１〜２０３と、異常期間のチャンク２１１〜２１３に分ける。図２は、計算対象期間を計１２０分間とした例を示している。チャンク２０１〜２０３、２１１〜２１３に括弧書きで記載された数字は、そのチャンクの期間である。
【００３４】
ステップ２において、ＳＬＭサーバ１２１は、ステップ１で判定した異常期間のチャンク２１１〜２１３のそれぞれについて、ルールベースにより、異常を引き起こした責任者を判定する。本実施形態は、異常期間を「事業者責任」、「事業者責任外」、「責任不明」に区別する。
【００３５】
ステップ３において、ＳＬＭサーバ１２１は、ステップ２で判定した責任判定結果と実績値の集計ルールとに基づいて、ＳＬＯ実績値の取り得る範囲（実績値の最大値及び最小さ値）を計算する。ここでは、ＶＭの稼働率の実績値のように、計算対象期間全体に対して、非異常期間が占める割合を集計する例を示す。
【００３６】
実績値の最大値と最小値は、事業者責任か否かが曖昧な範囲をどのように定義するかによって、異なるバリエーションの計算方法がありえる。計算対象期間中の各期間を以下の通りに名づける。
Ｔｉｍｅ１・・・正常期間チャンクの合計時間
Ｔｉｍｅ２・・・事業者責任外の異常期間チャンクの合計時間
Ｔｉｍｅ３・・・責任不明の異常期間チャンクの合計時間
Ｔｉｍｅ４・・・事業者責任の異常期間チャンクの合計時間
【００３７】
計算方法のバリエーションは主に以下の２つが考えられる。以下の各式は、非異常期間とみなす時間を示している。
［バリエーション１］
実績値の最大値＝Ｔｉｍｅ１＋Ｔｉｍｅ２＋Ｔｉｍｅ３
実績値の最小値＝Ｔｉｍｅ１＋Ｔｉｍｅ２
［バリエーション２］
実績値の最大値＝Ｔｉｍｅ１＋Ｔｉｍｅ２
実績値の最小値＝Ｔｉｍｅ１
【００３８】
バリエーション１は、例えば、事業者の責任判定が信頼できる場合に用い、一方、バリエーション２は、例えば、事業者による責任判定自体があまり信頼できない場合に用いることができる。
【００３９】
バリエーション１の例を説明する。図２におけるステップ３を例にとると、最大値は、（計算対象時間１２０分−事業者責任の異常期間２０分）÷計算対象時間１２０分＝１００／１２０となる。一方、最小値は、（計算対象時間１２０分−事業者責任の異常期間２０分−責任不明の異常期間３０分）÷計算対象時間１２０分＝７０／１２０となる。ＳＬＭサーバ１２１は、このように、ＳＬＯ実績値の取り得る範囲として、最大値と最小値を求める。
【００４０】
図３は、本実施形態のコンピュータシステムの構成例を模式的に示す。コンピュータシステムは、ＳＬＭサーバ３、データベース４、端末５、及び端末７を含む。これらの装置は、通信ネットワーク２を通して管理ネットワーク１に接続される。ＳＬＭサーバ３、データベース４は、ＳＬＭシステムの構成要素である。ＳＬＭシステムに含まれる計算機及び他の装置の数は設計に依存する。
【００４１】
顧客システム６は、顧客のシステムを構成するコンポーネントの例である。顧客システム６上には、ハイパーバイザ６１、その上に搭載されるＶＭ６２１、ＶＭ６２１上のＯＳ６３１、ＯＳ上に搭載されるミドルウェア６４１やアプリケーション６５１といったソフトウェアコンポーネントが存在する。
【００４２】
監視エージェント６６１は、各コンポーネント６１１、６２１、６３１、６４１、６５１からログデータを取得する。各コンポーネント６１１、６２１、６３１、６４１、６５１、６６１は、それぞれ、顧客システムの構成によって、１又は複数個存在し得るが、図３は、簡単のため、１個だけ示している。
【００４３】
ＳＬＭサーバ３は、ログデータを収集、格納、検索する機能を提供するログデータベースプログラム３１と、そのログデータを用いて、ＳＬＯ実績値を計算、表示する機能を提供するＳＬＭポータル３２を含む。
【００４４】
ログデータベースプログラム３１は、ログ収集プログラム３１０とログ登録プログラム３１１、ログ検索プログラム３１２を含む。ログ収集プログラム３１０は、顧客のシステムにある機器からログデータを収集する。
【００４５】
一般的な収集方法の一つは、各機器上でＳｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ（ＳＮＭＰ）などの監視エージェントを動作させ、その監視エージェントとログ収集プログラム３１０の間で通信することでログデータを収集する。ログ登録プログラム３１１は、受信したログデータを、データベース４に登録する。ログ検索プログラム３１２は、データベース４から検索条件を満たしたログデータを取得する。
【００４６】
ＳＬＭポータル３２は、ＳＬ異常判定プログラム３２０、責任判定プログラム３２２、責任判定ルール登録プログラム３２３、ＳＬＯ実績値集計プログラム３２１、ＳＬＯ実績値確認プログラム３２４、ＳＬＯ実績値修正プログラム３２５を含む。
【００４７】
ＳＬ異常判定プログラム３２０は、計算対象となったＳＬＯ及び、その計算対象期間について、ルールベースでＳＬ異常期間を判定する。つまり、ＳＬ異常判定プログラム３２０は、図２のステップ１に示した処理を実施する。
【００４８】
具体的には、ＳＬ異常判定プログラム３２０は、データベース４から、計算対象として選択されたＳＬＯに対応するＳＬ異常判定ルールをＳＬ異常判定ルールテーブルＴ３００から取得し、取得したルールと計算対象期間に対応するログデータをログデータテーブルＴ１００から取得する。ＳＬ異常判定プログラム３２０は、取得した情報を元に、ＳＬ異常期間を判定し、正常期間と異常期間のチャンクを生成し、データベース４のＳＬ異常判定結果テーブルＴ６００に登録する。
【００４９】
責任判定プログラム３２２は、計算対象となったＳＬＯ及び、その計算対象期間におけるＳＬ異常判定結果テーブルＴ６００に対して、ルールベースで異常を引き起こした責任者の判定を行う。つまり、責任判定プログラム３２２は、図２のステップ２に示した処理を実施する。
【００５０】
具体的には、責任判定プログラム３２２は、データベース４から、ＳＬ異常判定結果テーブルＴ６００に対応する責任判定ルールテーブルＴ５００とログデータテーブルＴ１００を取得し、各異常期間のチャンクについて、責任者の判定を行う。その判定を付与した結果を、データベース４の責任判定結果テーブルＴ７００に登録する。
【００５１】
責任判定ルール登録プログラム３２３は、その責任判定ルールを登録する。一般的な登録方法の一例は、ＧＵＩ等を介してプログラムレスでルールを定義し、そのルールをプログラム上で解釈可能なデータ構造に変換し、データベース４に登録する。
【００５２】
ＳＬＯ実績値集計プログラム３２１は、計算対象となったＳＬＯ及び、その計算対象期間における責任判定結果テーブルＴ７００と、そのＳＬＯ実績値集計ルールテーブルＴ４００を用いて、ＳＬＯ実績値の取り得る範囲として最大値と最小値を計算し、データベース４のＳＬＯ実績値テーブルＴ８００に登録する。つまり、ＳＬＯ実績値集計プログラム３２１は、図２のステップ３に示した処理を実施する。
【００５３】
ＳＬＯ実績値確認プログラム３２４は、データベース４の責任判定結果テーブルＴ７００、ＳＬＯ実績値テーブルＴ８００、ログデータテーブルＴ１００を取得、加工して、ＳＬＯ実績値表示画像を生成する。
【００５４】
顧客は、端末５のＷｅｂブラウザ５１を介して、ＳＬＯ実績値表示画像を閲覧することで、ＳＬＯ達成状況を確認できる。ＳＬＯ実績値確認プログラム３２４は、この画像上で、顧客からのＳＬＯ実績値に対する訂正入力を受け付ける。
【００５５】
ＳＬＯ実績値確認プログラム３２４は、その訂正内容を確認する画像を生成し、端末７に送信する。事業者は、端末７のＷｅｂブラウザ７１（出力デバイス）が示す画像により、訂正内容を確認する。事業者は、端末７の入力デバイスにより、画像が示す訂正内容に対する承認を入力する。ＳＬＯ実績値確認プログラム３２４は、Ｗｅｂブラウザ７１から送信された承認を受け付ける。
【００５６】
ＳＬＯ実績値修正プログラム３２５は、計算されたＳＬＯ実績値に対する、フィードバック入力情報を用いて、ＳＬＯ実績値を再計算する。なお、本実施形態では、ＳＬＯ実績値の計算方法の前提として、計算時に必要となるログデータは、すべてデータベース４から取得できることとする。データベース４上のログデータの検索・取得は、ログ検索プログラム３１２を介して行うこととする。以降では、説明の単純化のため、ログ検索プログラム３１２を介した処理の説明は省略する。
【００５７】
本実施形態では、ＳＬＯの説明例として、主にＶＭの稼働率を用いる。しかし、本発明によるＳＬＯ実績値計算、表示、調整方法は、ＶＭの稼働率に限定されるものではなく、他のＳＬＯに対しても適用可能である。例えば、ハイパーバイザの稼働率にも適用できる。また、サービスの応答時間などの性能に関するＳＬＯに対しても適用可能である。
【００５８】
また、本実施形態では、代表的な事例として、ＳＬＯが、顧客とその顧客の利用する機器の一意な組合せに対して、定義されることとする。しかし、機器ではなく、サービスメニュー（例えば、システム全体の障害対応時間など）に対して定義しても良い。
【００５９】
以降では、本実施形態のデータベース４に格納される各種情報について順に説明する。本実施形態では、データベース４上で各種情報を表形式で格納する。しかし、本発明の実施形態は、表形式のデータに限定されるものではない。例えば、木構造のデータであっても、テキストのデータであっても、後述する各情報に相当するデータがあれば、本発明を適用できる。
【００６０】
図４は、データベース４に格納するログデータテーブルＴ１００の一例を示す。ログデータテーブルＴ１００は、クラウドサービス上の機器から収集されたログデータそのもの、あるいは、そのデータ構造を分析し、テーブル形式に加工した情報である。本実施形態では、ログデータには、顧客、クラウドサービス上の機器、ログデータの種類の情報が付与される。
【００６１】
以下では、顧客を一意に識別するための名称を「顧客名」と呼ぶ。通常、顧客名には、企業名や組織名、個人名などの具体的な顧客の名称が格納される。本実施形態では、事業者が管理し、複数の顧客によって共用されるリソースから収集されたログデータの場合には、例外として「共用」という文字列が格納されることとする。
【００６２】
クラウドサービス上の機器を一意に識別するための名称を「インスタンス名」と呼ぶ。インスタンス名としては、ＦＱＤＮ（Ｆｕｌｌｙ  Ｑｕａｌｉｆｉｅｄ  Ｄｏｍａｉｎ  Ｎａｍｅ）で記述されたホスト名や、ＩＰアドレスなどがあり得る。
【００６３】
ログデータの種類を一意に識別するための名称を「データ種別名」と呼ぶ。データ種別は、ハードウェア装置（例えば、ネットワーク装置）に関するデータ、ハイパーバイザに関するデータ、ＶＭ（及びＶＭ上に搭載されるＯＳ）に関するデータ、そのＯＳ上の複数アプリケーションから共通して利用されるミドルウェア（データベース、Ｗｅｂコンテナなど）に関するデータ、及びアプリケーション固有のデータがある。データ種別名は、「ＶＭの死活監視ログ」、「ＯＳのＣＰＵ利用率」など、これらの種別が特定できる文字列データである。
【００６４】
なお、本実施形態では、事業者が、事業者側のログ（ハードウェア〜ハイパーバイザのログ）と、顧客ログの一部（ＯＳログなどの標準的なログ）を管理することを想定する。データベース４上には、ハードウェア〜標準的なログが格納されており、事業者は全てのログに、顧客は自身のログ及び、共有リソースのログの一部にアクセスできることとする。
【００６５】
列Ｔ１０１は、ログの出力元となるインスタンスに関連する顧客名を格納する。列Ｔ１０２は、インスタンス名、列Ｔ１０３は、データ種別名を格納する。列Ｔ１０４は、データベース４に登録されるログを一意に特定するためのデータＩＤを格納する。このデータＩＤは、明示的に付与されても、自動生成されても良い。この例では、ログ登録プログラム３１１によって、自動生成された一意な数値が付与されることとする。
【００６６】
列Ｔ１０５は、このログが計測された時刻を格納する。列Ｔ１０６は、このログに含まれる計測時刻以外のデータを格納する。この例では、時刻以外のデータをキーと値のペアとして示している。
【００６７】
図４は、４つの行（エントリ）Ｔ１５０〜Ｔ１５６を例示している。例えば、行Ｔ１５０は、２０１３年４月２日の５時５５分０秒に、顧客Ａのホスト名ＶＭ１のＶＭによるＰｉｎｇ送信による死活監視の結果が失敗だったことを示している。
【００６８】
図５は、システムの構成情報テーブルＴ２００の一例を示す。本実施形態では、クラウドサービス上の各顧客のシステムにおける現在の構成情報が管理されていることとする。なお、構成情報テーブルＴ２００は、ＳＬＯ実績値計算に関する各種ルールの内容次第では、用いなくても構わない。
【００６９】
列Ｔ２０１は、インスタンスを利用する顧客名を格納する。ログデータテーブルＴ１００と同様、共有リソースの場合には、例外として「共有」が設定される。列Ｔ２０２は、インスタンス名を格納する。列Ｔ２０３はインスタンスの種別名を格納する。インスタンスの種別名には、「仮想マシン」、「物理スイッチ」、「ハイパーバイザ」などの物理的あるいは論理的な機器の種別を特定する情報が格納される。列Ｔ２０４は、インスタンスが接続する他のインスタンスを示す情報を格納する。この例では、接続関係として、接続先である上位のインスタンスとの関係のみが記載されている。
【００７０】
ここで構成情報について具体例を用いて説明する。図５は、行Ｔ２５０〜Ｔ２５４を例示している。例えば、行Ｔ２５０は、顧客Ａが利用するＶＭ１という名前のＶＭが存在し、ハイパーバイザ１上に搭載されていることを示す。顧客名Ｔ２０１と接続関係Ｔ２０４の情報を組み合わせることで、事業者が管理する共用リソースの利用状況を特定できる。
【００７１】
行Ｔ２５０、Ｔ２５１のＶＭの利用者は顧客Ａ、行Ｔ２５２のＶＭの利用者は顧客Ｂである。行Ｔ２５０、Ｔ２５２のＶＭは、ハイパーバイザ１に接続されている。したがって、ハイパーバイザ１は、顧客ＡとＢが利用している。
【００７２】
なお、構成情報テーブルＴ２００は、木構造の接続関係のみを表現可能である。しかし、本発明の実施形態は、この接続関係の表現に限定されない。例えば、リスト等を用いて多対多の接続関係を表現しても構わない。
【００７３】
図６は、ＳＬ異常判定ルールテーブルＴ３００の例を示す。この例では、各行が、ある顧客名とインスタンス名のペアに対して設定したＳＬＯ及びそのＳＬ異常判定ルールを表している。本実施形態では、顧客名とインスタンス名のペアのことを、ＳＬＯ適用対象Ｔ３０６と呼ぶ。
【００７４】
列Ｔ３０１は顧客名、列Ｔ３０２はインスタンス名、列Ｔ３０３はＳＬＯ名を格納する。列Ｔ３０４は、ＳＬＯ名に対応する保証値を格納する。列Ｔ３０５は、ＳＬ異常判定ルールを格納する。この判定ルール列には、本ＳＬＯのＳＬ異常判定に利用するログのデータ種別名、及びＳＬ異常期間を抽出するための条件が記載される。
【００７５】
図６は、行Ｔ３５０、Ｔ３５１を例示する。ＳＬ異常判定ルールテーブルＴ３００の具体例について、行Ｔ３５０を用いて説明する。行Ｔ３５０では、顧客Ａが利用しているＶＭ１に関して「ＶＭの月間稼働率９９．９５％以上を保証する」というＳＬＯが設定されている。そのＳＬ異常判定ルールとして、「ＶＭの死活監視ログが２回以上連続で失敗した１回目の失敗時刻から、２回以上連続で成功した１回目の成功時刻までをＳＬ異常期間とみなす」という条件が設定されている。
【００７６】
実際にＳＬ異常判定ルールテーブルＴ３００をログデータテーブルＴ１００に適用した例を述べる。ログデータテーブルＴ１００の行Ｔ１５０〜Ｔ１５５は、インスタンス名ＶＭ１の「ＶＭの死活監視ログ」のログである。このログに対して、行３５０に示したルールを適用する。行Ｔ１５０〜Ｔ１５２に着目すると、行Ｔ１５２の時点で２回連続失敗している。そのため、Ｔ１５１の計測時刻「６時０分０秒」から異常の開始と判定される。
【００７７】
さらに、行Ｔ１５３〜Ｔ１５５に着目する。行Ｔ１５５の時点で２回連続成功しているため、行Ｔ１５４の計測時刻「６時３０分０秒」が異常の終了と判定される。以上により、行Ｔ１５２〜Ｔ１５４の３０分間において、異常が発生したと判定される。
【００７８】
なお、ひとつのＳＬＯに対して、複数のＳＬ異常判定ルールを定義しても良い。例えば、ＶＭの稼働率の異常判定に関して、行Ｔ３５０に記載のルールの他に、「死活監視ログのＮ番目の計測時刻とＮ＋１番目の計測時間を比較して１０分よりも長い時」という条件を加えても良い。その場合、異常判定の抜け漏れをより少なくできるという利点がある。
【００７９】
図７は、ＳＬ異常判定結果テーブルＴ６００の一例を示す。ＳＬ異常判定結果テーブルＴ６００には、ＳＬ異常判定ルールテーブルＴ３００に基づく判定結果であるＳＬ正常／異常期間のチャンクが登録される。
【００８０】
列Ｔ６０１のチャンクＩＤは、ＳＬ正常／異常期間の各チャンクを一意に識別するための識別子である。本実施形態では、チャンクＩＤはデータベース４上で自動採番されることとする。列Ｔ６０２は顧客名、列Ｔ６０３はインスタンス名、列Ｔ６０４はＳＬＯ名を格納する。
【００８１】
列Ｔ６０５は期間、すなわち、チャンク（期間）の開始時刻と終了時刻の組を格納する。列Ｔ６０６は、各チャンクの異常／正常の分類情報を格納する。正常期間の場合には「正常」、異常期間の場合には「異常」が設定される。
【００８２】
列Ｔ６０７は、このチャンクを生成した際の異常判定に利用したログデータへの参照を表す情報を格納する。利用した０件以上のログデータのデータＩＤが列挙される。このデータＩＤをデータベース４にて管理されるログデータテーブルＴ１００のデータＩＤ（列Ｔ１０４）と関連付けることで、実際のログデータを検索、取得可能である。なお、本実施形態では、前のチャンクの終了時刻と次のチャンクの開始時刻の間は、切れ目なく連続することとする。
【００８３】
図７は、行Ｔ６５０〜Ｔ６５４を例示する。例えば、行Ｔ６５１は、先のＳＬ異常判定ルールテーブルＴ３００の具体例で示したＶＭ１の稼働率に関する３０分間の異常期間を登録した結果である。
【００８４】
次に、責任判定ルールテーブルＴ５００について説明する。本実施形態では、異常期間に対して、事業者責任の有無を表す数値として、「事業者責任度合」を定義する。本実施形態では、事業者責任度合は以下の３つの離散値を取ることと定義する。
−１：  事業者責任外
１：  事業者責任
０：  責任不明
【００８５】
図８は、責任判定ルールテーブルＴ５００の一例を示す。この例は、特定の顧客の、特定のＳＬＯにおいて発生した異常期間に対して、適用される責任判定ルールを表している。列Ｔ５０１のルールＩＤは、責任判定ルールを一意に特定する識別子である。列Ｔ５０２は顧客名を格納する。列Ｔ５０３は、ルールが適用される対象となるＳＬＯ名を格納する。列Ｔ５０４は、責任判定ルールを格納する。この例では、責任判定ルールは、ＳＬ異常判定結果テーブルＴ６００のうち、ＳＬＯ名が列Ｔ５０３と一致した各異常期間に対して適用される。
【００８６】
列Ｔ５０５は、事業者責任度合を格納する。列Ｔ５０６はこのルールによって判定された理由（原因）を説明する文章を格納する。列Ｔ５０７はこの判定ルールの有効／無効設定を格納する。「有効」の場合には、責任判定処理時にこのルールが利用される。一方、「無効」の場合には、適用対象となる異常期間があった場合にも、このルールは利用されない。
【００８７】
列Ｔ５０８の否定回数カウンタは、このルールの適用が却下された回数を集計するカウンタの値を格納する。カウンタの値は、初期値０からはじまり、このルールが適用された異常期間が訂正されるたびに１ずつ加算される。
【００８８】
図８は、行Ｔ５５０〜Ｔ５５３を例示する。責任判定ルールテーブルＴ５００の具体例を、行Ｔ５５０を用いて説明する。このルールは、顧客ＡのあるＶＭの稼働率のＳＬ異常判定結果テーブルＴ６００における、異常期間に対して適用される。ルールＴ５０４によると、その異常期間の前後１０分以内において、ＶＭが接続するインスタンス種別「ハイパーバイザ」のデータ種別「イベントログ」が、判定に用いるログデータである。
【００８９】
上記の期間の該ログデータに、キー「ユーザ」の値が「Ｃｌｉｅｎｔ＿Ａ」と一致し、かつ、キー「詳細」の値が「｛インスタンス名｝のパワーオフ」と一致するデータが存在した場合に、事業者責任度合は「−１」、すなわち事業者責任外と判定される。この例において、中括弧で括った部分は変数である。例えば、インスタンス名ＶＭ１の判定の場合、｛インスタンス名｝の部分がＶＭ１である場合に、一致しているという意味であることを示す。
【００９０】
ここで、２０１３年４月２日２０時１０分０秒〜２１時００分０秒が、顧客ＡのＶＭ１の異常期間であったとする。その場合に、本ルールを適用すると、まず図５の構成情報テーブルＴ２００より、接続先のハイパーバイザがハイパーバイザ１と特定できる。次に、図４に示すログデータテーブルＴ１００を参照すると、その異常期間におけるハイパーバイザ１のイベントログとして、行Ｔ１５６が取得される。行Ｔ１５６はルールに記載の条件を満たしているため、異常は、事業者責任外であると判定される。
【００９１】
図９は、責任判定結果テーブルＴ７００の一例を示す。責任判定結果テーブルＴ７００は、ＳＬ異常判定結果テーブルＴ６００に対して、責任判定ルールテーブルＴ５００による判定を実施し、その判定結果を付与した情報である。そのため、列Ｔ７０１〜列Ｔ７０７は、ＳＬ異常判定結果テーブルＴ６００の列Ｔ６０１〜列Ｔ６０７と同様である。そして、列Ｔ７０８〜Ｔ７１３が新たに付与された責任判定結果である。図９は、チャンク（行）Ｔ７５０〜Ｔ７５４の責任判定結果を例示する。
【００９２】
正常期間のチャンクについては、列Ｔ７０８〜列Ｔ７１３には、判定対象外を表す「−」が設定される。列Ｔ７０８は、事業者責任度合を格納する。異常期間のチャンクにおいて、該当するルールがあった場合には、「−１」あるいは「１」が設定されている。また、該当するルールが無かった場合には、「０」が設定される。「０」が設定された場合には、該当したルールの詳細を示す列Ｔ７０９〜列Ｔ７１１には該当なしを表す「無」が設定される。
【００９３】
列Ｔ７０９は該当するルールのＩＤを格納する。列Ｔ７１０は、該当したルールの責任判定に利用したログデータの参照情報を格納する。参照情報としては、１件以上のデータＩＤが列挙される。列Ｔ７１１は、列Ｔ５０６から転記した理由（原因）の説明文を格納する。
【００９４】
列Ｔ７１２と列７１３とは、主に顧客と事業者間のＳＬＯ実績値の調整時に利用される情報を格納する。列Ｔ７１２の状態は、異常期間のチャンクの訂正、承認状況を表す。チャンクが生成された時には初期値として「顧客承認待ち」が設定される。その後の調整で、承認された場合には「承認済み」、顧客が訂正している場合には「顧客訂正中」、訂正内容が事業者に提出された場合には、「事業者承認待ち」が設定される。
【００９５】
列Ｔ７１３は、手作業によって追加された判定情報を格納する。そのため、通常は情報が無いことを表す「無」が設定される。追加時に記述される情報については調整処理の説明にて後述する。なお、事業者責任度合Ｔ７０８が「１」すなわち事業者責任の場合には、列Ｔ７１２と列Ｔ７１３は使われないため、「−」が設定される。
【００９６】
図１０は、ＳＬＯ実績値集計ルールテーブルＴ４００の一例を示す。この例では、ひとつの行が、あるＳＬＯ適用対象に対して、ＳＬＯの実績値の取り得る範囲を集計するルールを表している。この集計ルールは、責任判定結果テーブルＴ７００に対して適用することで、実績値を求める方法を示す。
【００９７】
列Ｔ４０１〜列Ｔ４０４は、それぞれ顧客名、インスタンス名、ＳＬＯ名、保証値を格納する。これらは、ＳＬ異常判定ルールテーブルＴ３００の列Ｔ３０１〜列Ｔ３０４と同様である。列Ｔ４０５と列Ｔ４０６は、それぞれ実績値の最大値と最小値を計算するための集計ルールを格納する。計算対象期間と責任判定結果テーブルＴ７００を用いた実績値の集計方法（例えば、計算式）が記述されている。
【００９８】
列Ｔ４０７は、ＳＬＯの計算対象期間の単位を格納する。例えば、「各月」の場合には、各月の初日から末日までを計算対象期間として、ＳＬＯ実績値を計算することを表す。この単位で集計した実績値と、保証値とを比較することで、ＳＬＯの達成／未達成を判断することができる。
【００９９】
図１０は、行Ｔ４５０、Ｔ４５１を例示する。ＳＬＯ実績値集計ルールテーブルＴ４００の具体例を、行Ｔ４５０を用いて説明する。行Ｔ４５０では、顧客ＡのＶＭ１に対する月間ＶＭ稼働率の実績値の最小値、最大値の計算ルールが示されている。
【０１００】
最大値については、列Ｔ４０５より、「（計算対象期間の総時間−事業者責任による異常期間の合計時間）÷計算対象期間の総時間×１００」という集計ルールが定義されている。最小値については、列Ｔ４０６より、「（計算対象期間の総時間−事業者責任による異常期間の合計時間−責任不明による異常期間の合計時間）÷計算対象期間の総時間×１００」という集計ルールが定義されている。定義されたルールに従い、各月の実績値が計算される。
【０１０１】
月の総時間を３０日×２４時間＝７２０時間とし、事業者責任による異常期間が１５分とする。実績値（７２０時間−１５分）÷７２０時間＝月間稼働率の最大値は、９９．９７％となる。行Ｔ４５０の場合、実績値≧保証値を満たしているため、最大値ではＳＬＯ達成である。
【０１０２】
さらに、責任不明の異常期間の合計時間を１５分とすると、（７２０時間―１５分―１５分）÷７２０時間＝月間稼働率の最小値は９９．９３％となり、最小値は、ＳＬＯを未達成である。
【０１０３】
このように実績値の最大値と最小値で達成／未達成が異なるケースでは、事業者と顧客による折衝対象となる可能性が高い。なお、本実施形態では、常に実績値は、最大値≧最小値となるように、最小値と最大値の集計ルールが定義されるとする。
【０１０４】
本実施形態は、実績値の集計ルールを、最大値と最小値の場合で別々に定義しているが、本発明はこれに限定されるものではない。最大値／最小値で同一のルールが定義されてもよい。最大値と最小値の計算方法の違いが、全てのＳＬＯの集計ルールで一定である場合には、計算方法をプログラムに埋め込んでも良い。
【０１０５】
さらに、本実施形態は、ＳＬＯを、インスタンス毎に定義している。しかし、ＳＬＯを、インスタンス種別毎に定義してもよいし、インスタンスグループ毎に定義してもよい。顧客毎にひとつのインスタンスグループを定義して、そのグループに対して、ひとつのＳＬＯを規定してもよい。
【０１０６】
上述のＳＬＯの例では、保証単位は月間である。そのため、各月の実績値を計算できることは必須である。それに加えて、より細かい粒度でＳＬＯ実績値を計算、提示してもよい。事業者と顧客は、折衝をする際に、提示された値を参考値として使用することができる。そこで、本実施形態は、各月の実績値に加えて、各日の実績値についても、同様の集計ルールを用いて計算する。各日の実績値は計算、提示しなくてもよい。
【０１０７】
図１１は、計算されたＳＬＯ実績値テーブルＴ８００の一例を示す。列Ｔ８０１〜列Ｔ８０４は、それぞれ、顧客名、インスタンス名、ＳＬＯ名、保証値を格納する。これらは、ＳＬ異常判定ルールテーブルＴ３００の列Ｔ３０１〜列Ｔ３０４やＳＬＯ実績値集計ルールテーブルＴ４００の列Ｔ４０１〜Ｔ４０４と同様である。
【０１０８】
列Ｔ８０５は、実績値の計算対象期間を格納する。列Ｔ８０６と列Ｔ８０７は、実績値の最小値と最大値とを格納する。列Ｔ８０８〜列Ｔ８１０は、実績値の計算対象期間に存在した異常期間のチャンクのＩＤのリストを示す。列Ｔ８０８、列Ｔ８０９、列Ｔ８１０は、それぞれ、事業者責任外、事業者責任、責任不明の異常期間のチャンクＩＤのリストを示す。
【０１０９】
ＳＬＯ実績値テーブルＴ８００について具体例を説明する。図１１は、行Ｔ８５０〜Ｔ８５２を例示する。行Ｔ８５２は、顧客ＡのＶＭ１における稼働率の月間実績値である。この例では、２０１３年４月分の実績値を示す。そして、行Ｔ８５０〜Ｔ８５１は、それぞれ、行Ｔ８５２の期間中の１日の実績値である。
【０１１０】
ここで、行Ｔ８５０の例をさらに詳細に説明する。行Ｔ８５０は、２０１３年４月２日分の実績値である。この実績値は、図９に示した責任判定結果テーブルＴ７００の当日分のチャンクＴ７５０〜Ｔ７５４に対して、図１０に示した実績値集計ルールＴ４５０を適用することで計算した結果である。この例では、異常期間のチャンクは、チャンクＩＤ１１、１３、１４、１６のチャンクＴ７５１〜Ｔ７５４のみである。
【０１１１】
事業者責任度合に従って分類すると、事業者責任外のチャンクはチャンク１１とチャンク１４、事業者責任のチャンクはチャンク１６、責任不明のチャンクはチャンク１３と分類できる。この分類結果がそれぞれ、列Ｔ８０８〜Ｔ８１０に格納される。
【０１１２】
この分類結果から、事業者責任による異常期間の合計時間は１０分、責任不明の異常期間の合計時間は１時間となる。したがって、実績値集計ルールのＴ４５０を適用すると、最大値は、（２４時間−１０分）÷２４時間×１００＝９９．３１％となる。一方、最小値は、（２４時間−１０分−１時間）÷２４時間×１００＝９５．１４％となる。この計算結果が、列Ｔ８０６と列Ｔ８０７に格納される。
【０１１３】
以上のように、本実施形態は、顧客毎に、ＳＬＭで使用する異常判定ルール、責任判定ルール及びＳＬＯ実績値集計ルールを顧客毎に管理する。これにより、顧客に応じたＳＬＭを適切に行うことができる。なお、これらの一部のルールのみを顧客毎に管理してもよい。
【０１１４】
以降では、本実施形態におけるＳＬＯ実績値計算処理について、フローチャートを用いて説明する。図１２は、本実施形態のＳＬＭポータル３２におけるＳＬＯ実績値計算及び表示処理の全体のフローチャートを示す。
【０１１５】
ＳＬＭポータル３２は、ＳＬＯ実績値集計ルールテーブルＴ４００から、計算対象となるＳＬＯのリスト（以下、ＴＬ）を取得する（Ｓ００１）。例えば、ＳＬＭポータル３２は、ある顧客に対するすべてのＳＬＯ実績値を計算したい場合には、顧客名を検索条件として、ＳＬＯのリストを取得する。
【０１１６】
以下、ＳＬＭポータル３２は、ステップＳ００１で列挙したＴＬについて、未計算のＳＬＯがある間、ＴＬから、未計算のＳＬＯであるＴを選択し、ステップＳ１〜Ｓ３の処理を繰り返す（Ｓ００２〜Ｓ００３）。Ｔは、列Ｔ４０１〜Ｔ４０４及びＴ４０７に該当する情報、すなわち、顧客名、インスタンス名、ＳＬＯ名、保証値、計算対象期間の単位を含む。
【０１１７】
ここで、本実施形態では、ＳＬＭポータル３２は、Ｔ４０７に指定された各月のトータルの実績値に加えて、その間の各日の実績値も併せて計算する。そのため、以降の計算対象期間として、Ｔ４０７で設定した値（各月）に加えて、その月の各日がそれぞれ指定される。
【０１１８】
ステップＳ１〜Ｓ３の処理は、Ｔの実績値を計算する処理である。ＳＬＭポータル３２のＳＬ異常判定プログラム３２０は、ＳＬ異常判定ルールテーブルＴ３００に従って、Ｔの異常判定に利用するログデータテーブルＴ１００を取得する。ＳＬ異常判定プログラム３２０は、計算対象期間の中の異常／正常期間のチャンクを生成し、データベース４上にＳＬ異常判定結果テーブルＴ６００として登録する（Ｓ１）。
【０１１９】
ＳＬＭポータル３２の責任判定プログラム３２２は、責任判定ルールテーブルＴ５００に従って、Ｓ１で生成した異常期間の各チャンク（ＳＬ異常判定結果テーブルＴ６００）に対して責任判定を行う。責任判定プログラム３２２は、その責任判定結果をチャンクに付与し、データベース４上に責任判定結果テーブルＴ７００として登録する（Ｓ２）。
【０１２０】
ＳＬＭポータル３２のＳＬＯ実績値集計プログラム３２１は、責任判定後の異常期間のチャンク（責任判定結果テーブルＴ７００）とＳＬＯ実績値集計ルールをもとに、ＴのＳＬＯ実績値（最大値と最小値）を求める。ＳＬＯ実績値集計プログラム３２１は、求めた値をデータベース４上のＳＬＯ実績値テーブルＴ８００として登録する（Ｓ３）。これらＳ１〜Ｓ３の処理の詳細は、後述する。
【０１２１】
ＳＬＭポータル３２のＳＬＯ実績値確認プログラム３２４は、ＳＬＯ実績値（最大値と最小値）と根拠（異常期間及びその責任判定結果）とを共に表示する、画像（データ）を生成する（Ｓ００４）。この表示画像の例については、後述する。
【０１２２】
図１３は、本実施形態におけるＳＬ異常判定プログラム３２０によるＳＬ異常判定処理の詳細フローチャートを示す。図１２に示したステップＳ１の処理の詳細である。ＳＬ異常判定プログラム３２０は、計算対象となるＳＬＯのＳＬ異常判定ルールテーブルＴ３００を取得する（Ｓ１０１）。例えば、計算対象となるＳＬＯが「顧客ＡのＶＭ１のＶＭ稼働率」であった場合には、ＳＬ異常判定プログラム３２０は、行Ｔ３５０のＳＬ異常判定ルールを取得する。
【０１２３】
次に、ＳＬ異常判定プログラム３２０は、ステップＳ１０１で取得したＳＬ異常判定ルールに従って、計算対象期間の実績値計算に利用するログデータを、ログデータテーブルＴ１００から取得する（Ｓ１０２）。
【０１２４】
例えば、２０１３年４月２日の実績値を計算する場合には、計算対象期間は、「２０１３年４月２日０時０分０秒≦計算対象期間＜２０１３年４月２日０時０分０秒」である。列Ｔ３５０より、この判定ではデータ種別「ＶＭの死活監視ログ」のログデータを利用する。したがって、ＳＬ異常判定プログラム３２０は、ログデータテーブルＴ１００から、上記計算対象期間中におけるＶＭ１のデータ種別「ＶＭの死活監視ログ」のログデータを取得する（図４中の行Ｔ１５０〜Ｔ１５５はその一部である）。
【０１２５】
ＳＬ異常判定プログラム３２０は、取得したログデータを計測時間Ｔ１０５の時系列昇順にチェックし、計算対象期間を、ＳＬ異常判定ルールテーブルＴ３００の条件を満たす期間（異常期間）と、満たさない期間（正常期間）のチャンクに分ける（Ｓ１０３）。
【０１２６】
ＳＬ異常判定プログラム３２０は、ステップＳ１０３で生成したチャンクをＳＬ異常判定結果テーブルＴ６００としてデータベース４に登録する（Ｓ１０４）。例えば、先の例で取得したＶＭ１の「ＶＭの死活監視ログ」にＳＬ異常判定ルールを適用すると、行Ｔ１５０〜Ｔ１５５より、「２０１３年４月２日６時０分０秒〜２０１３年４月２日６時３０分０秒」が異常期間と判定される。
【０１２７】
ここで、当日のそれ以前の時間帯に異常期間が無いとする。まず、当日のチャンクとして、「２０１３年４月２日０時０分０秒〜２０１３年４月２日６時０分０秒」が正常期間のチャンクとして生成され、データベース４上のＳＬ異常判定結果テーブルＴ６００に登録される（図７の例における行Ｔ６５０）。
【０１２８】
次に、「２０１３年４月２日６時０分０秒〜２０１３年４月２日６時３０分０秒」の異常期間のチャンクが生成されて、ＳＬ異常判定結果テーブルＴ６００に登録される（行Ｔ６５１）。以降も判定結果にしたがって、ＳＬ異常判定結果テーブルＴ６００にチャンクが登録される（行Ｔ６５２以降）。
【０１２９】
図７の例では、チャンクＩＤ１０〜１６のチャンクが、列Ｔ６０２〜Ｔ６０４に示されるＳＬＯに対する２０１３年４月２日のすべてのチャンクである。行Ｔ６５１に例示する通り、ＳＬ異常判定結果テーブルＴ６００には、各チャンクの異常判定（異常ｏｒ正常）の情報Ｔ６０６と、その判定に利用したログデータの参照情報Ｔ６０７が登録される。この例では、異常判定にログデータＴ１５０〜Ｔ１５５が利用されたため、そのＩＤである５０００〜５００６が参照情報として登録されている。
【０１３０】
図１４は、本実施形態におけるＳＬＭポータル３２の責任判定プログラム３２２による責任判定処理の詳細フローチャートを示す。図１２に示したステップＳ２の処理の詳細である。
【０１３１】
責任判定プログラム３２２は、計算対象となるＳＬＯの計算対象期間におけるＳＬ異常判定結果の集合（以下、ＡＤＳと呼ぶ）を、ＳＬ異常判定結果テーブルＴ６００から取得する（Ｓ２０１）。例えば、計算対象となるＳＬＯが「顧客ＡのＶＭ１のＶＭ稼働率」で、計算対象期間が「２０１３年４月２日０時０分０秒≦計算対象期間＜２０１３年４月２日０時０分０秒」である場合、責任判定プログラム３２２は、行Ｔ６５０〜Ｔ６５４を取得する。
【０１３２】
次に、責任判定プログラム３２２は、責任判定の初期化処理として、ＡＤＳをデータベース４上の責任判定結果テーブルＴ７００にコピーする（Ｓ２０２）。図９に示す責任判定結果テーブルＴ７００は、前述の行Ｔ６５０〜Ｔ６５４の列Ｔ６０１〜Ｔ６０７を、行Ｔ７５０〜Ｔ７５４の列Ｔ７０１〜Ｔ７０７にコピーした例を示している。列Ｔ７０８〜Ｔ７１１は、以降の判定結果に基づいて追加される列である。これらの列には、初期状態として「−」が登録される。
【０１３３】
さらに、責任判定プログラム３２２は、ＡＤＳの中に、未検証の異常期間がある間（Ｓ２０３：ＹＥＳ）、ＡＤＳから未検証の異常期間ＡＤを選択し（Ｓ２０４）、ステップＳ２０５〜Ｓ２１１の処理を繰り返す。ここで、異常期間とは、ＡＤＳ内の各チャンクのうち、ＳＬ異常判定結果テーブルＴ６００における異常判定Ｔ７０６が「異常」と設定されたチャンクのことである。「正常」と設定されたチャンクは、以降の処理の実施対象外となる。
【０１３４】
続いて、責任判定プログラム３２２は、責任判定ルールテーブルＴ５００から、計算対象となるＳＬＯに関するルールの集合（以下、ＲＲＳと呼ぶ）を取得する（Ｓ２０５）。例えば、ＳＬＯが「顧客ＡのＶＭ１のＶＭ稼働率」の場合には、責任判定プログラム３２２は、責任判定ルールテーブルＴ５００から顧客名Ｔ５０２が「顧客Ａ」、対象となるＳＬＯ名「ＶＭ稼働率」であり、かつ有効／無効設定Ｔ５０７が「有効」となっているルールをすべて取得する（図８中の行Ｔ５５０〜Ｔ５５３はその一部である）。
【０１３５】
その後、責任判定プログラム３２２は、ＲＲＳの中に未検証のルールがある間（Ｓ２０６：ＹＥＳ）、ＲＲＳから未検証のルールＲＲを選択し（Ｓ２０７）、ステップＳ２０８〜Ｓ２１１の処理を繰り返す。ただし、ステップＳ２１０を実行した場合、責任判定プログラム３２２は、ステップ２０３に戻る。
【０１３６】
責任判定プログラム３２２は、責任判定ルールＲＲと異常期間ＡＤとに基づいて、ルール判定に利用するログデータを、ログデータテーブルＴ１００から取得する（Ｓ２０８）。この処理を行Ｔ５５０が示す責任判定ルールを例に説明する。責任判定ルールＴ５５０は、顧客によるシャットダウンかどうかを判定するためのルールである。このルールは、判定に「異常期間の前後１０分以内」におけるＶＭが接続するハイパーバイザのデータ種別「イベントログ」のログデータを利用する。
【０１３７】
まず、構成情報テーブルＴ２００の行Ｔ２５０より、ＶＭ１が接続するハイパーバイザは、「ハイパーバイザ１」である。また検証中の異常期間が図８に示すＴ６５３だとすると、異常期間の前後１０分は、「２０１３年４月２日１９時５０分０秒≦計算対象期間＜２０１３年４月３日２１時１０分０秒」となる。したがって、データベース４からはログデータテーブルＴ１００として、計測時刻が「２０１３年４月２日１９時５０分０秒≦計測時刻＜２０１３年４月３日２１時１０分０秒」のハイパーバイザ１のイベントログを取得する。図４の行Ｔ１５６は、取得されるログデータの一部である。
【０１３８】
次に、責任判定プログラム３２２は、取得したログデータに対して、ルールの条件判定を行う。条件を満たすログＬが存在する場合には、ステップＳ２１０を実行し、存在しない場合には次の未検証なルールに対して処理を繰り返す（Ｓ２０９）。
【０１３９】
条件を満たすログＬが存在する場合（Ｓ２０９：ＹＥＳ）、責任判定プログラム３２２は、異常期間ＡＤについて、該当したルールとしてＲＲを、根拠となるログとしてＬを設定し、データベース４上の責任判定結果テーブルＴ７００を更新する（Ｓ２１０）。該当したルールに関する情報として、該当したルールのＩＤ、ルールに設定された事業者責任度合、説明文を、責任判定結果テーブルＴ７００に登録する。また、根拠となるログの情報として、Ｌのログを参照するためのＩＤのリストを登録する。
【０１４０】
ステップＳ２０９、Ｓ２１０の処理について、例を用いて説明する。先の例で取得したハイパーバイザ１のイベントログＴ１５６に着目すると、行Ｔ５５０に示した責任判定ルールを満たしている。したがって、責任判定プログラム３２２は、この異常期間は、顧客によるシャットダウンによるものと判定し、事業者責任度合は「−１」、すなわち事業者責任外と判定する。責任判定プログラム３２２は、この結果をデータベース４上の責任判定結果テーブルＴ７００に追記する。
【０１４１】
列Ｔ７０１〜Ｔ７０７までが設定された該当行Ｔ７５３に対して、責任判定プログラム３２２は、該当したルールに関する情報として、事業者責任度合Ｔ７０８に「−１」、該当ルールＩＤＴ７０９に「１」、説明文Ｔ７１１に「顧客によるシャットダウン」を指定する。また、責任判定に利用したログの参照情報Ｔ７１０として、イベントログＴ１５６のＩＤである「９０１０」を指定する。
【０１４２】
条件を満たすログＬが存在しない場合（Ｓ２０９：ＮＯ）、責任判定プログラム３２２は、他の未検証なルールに対して、処理を繰り返す。その結果、全てのルールを検証しても該当するルールが存在しなかった場合（Ｓ２０６：ＮＯ）、責任判定プログラム３２２は、ＡＤについては責任不明として、データベース４上の責任判定結果テーブルＴ７００を更新する（Ｓ２１１）。具体的には、該責任判定結果の該当する行に対して、事業者責任度合に「０」を、その他の項目である列Ｔ７０９〜Ｔ７１１には「無」を設定する。
【０１４３】
図１５は、本実施形態におけるＳＬＭポータル３２のＳＬＯ実績値集計プログラム３２１によるＳＬＯ実績値集計処理の詳細フローチャートを示す。図１２に示したＳ３の処理の詳細である。
【０１４４】
ＳＬＯ実績値集計プログラム３２１は、計算対象となるＳＬＯのＳＬＯ実績値集計ルールを、ＳＬＯ実績値集計ルールテーブルＴ４００から取得する（Ｓ３０１）。例えば、計算対象となるＳＬＯが「顧客ＡのＶＭ１のＶＭ稼働率」であった場合には、行Ｔ４５０を取得する。
【０１４５】
次に、ＳＬＯ実績値集計プログラム３２１は、計算対象となるＳＬＯの計算対象期間における責任判定結果の集合（以下、ＲＤＳと呼ぶ）を、責任判定結果テーブルＴ７００から取得する（Ｓ３０２）。例えば、計算対象となるＳＬＯが「顧客ＡのＶＭ１のＶＭ稼働率」で、計算対象期間が「２０１３年４月２日０時０分０秒≦計算対象期間＜２０１３年４月２日０時０分０秒」であった場合には、行Ｔ７５０〜Ｔ７５４を取得する。
【０１４６】
さらに、ＳＬＯ実績値集計プログラム３２１は、集計の前処理として、ＲＤＳ中の異常期間のチャンクを、事業者責任度合に従って、「事業者責任外」、「事業者責任」、「原因不明」のグループに分類する（Ｓ３０３）。図９の責任判定結果テーブルＴ７００を例にとると、この期間における異常期間（異常チャンク）は、行Ｔ７５１〜Ｔ７５４のチャンク（チャンクＩＤ１１、１３、１４、１６）だけである。
【０１４７】
ＳＬＯ実績値集計プログラム３２１は、事業者責任度合に従って、事業者責任外のチャンク（事業者責任度合が−１）はチャンクＩＤが１１と１４のチャンク、事業者責任のチャンク（事業者責任度合が１）はチャンクＩＤが１６のチャンク、責任不明のチャンク（事業者責任度合が０）はチャンクＩＤが１３のチャンク、と分類する。
【０１４８】
続いて、ＳＬＯ実績値集計プログラム３２１は、ＲＤＳとＳＬＯ実績値集計ルールに基づき、ＳＬＯ実績値の取りうる最大値を計算する（Ｓ３０４）。例えば、ＳＬＯ実績値集計ルールＴ４５０の最大値集計ルールは、「（計算対象期間の総時間−事業者責任による異常期間の合計時間）÷計算対象期間の総時間×１００」である。
【０１４９】
先の分類結果より、事業者責任による異常期間の合計時間は、チャンクＩＤ１６の期間、すなわち１０分となる。したがって、ＳＬＯ実績値集計ルールＴ４５０を適用すると、最大値は、（２４時間−１０分）÷２４時間×１００＝９９．３１％となる。
【０１５０】
その後、ＳＬＯ実績値集計プログラム３２１は、ＲＤＳとＳＬＯ実績値集計ルールに基づき、ＳＬＯ実績値の取りうる最小値を計算する（Ｓ３０５）。例えば、ＳＬＯ実績値集計ルールＴ４５０の最小値集計ルールは、「（計算対象期間の総時間−事業者責任による異常期間の合計時間−責任不明による異常期間の合計時間）÷計算対象期間の総時間×１００」である。先に分類結果より、責任不明による異常期間の合計時間は、チャンクＩＤ１３の期間、すなわち１時間となる。ＳＬＯ実績値集計ルールＴ４５０を適用すると、最小値は、（２４時間−１０分−１時間）÷２４時間×１００＝９５．１４％となる。
【０１５１】
続いて、ＳＬＯ実績値集計プログラム３２１は、データベース４上のＳＬＯ実績値テーブルＴ８００に、計算対象期間、ステップＳ３０４〜Ｓ３０５で集計したＳＬＯ実績値の取りうる範囲（最小値と最大値）、ステップＳ３０３で分類した責任判定のグループごと（事業者責任外、事業者責任、責任不明）の異常期間のチャンクＩＤ、を登録する（Ｓ３０６）。
【０１５２】
本実施形態の責任判定処理においては、ＳＬ異常期間だけを対象として、責任判定を行っている。しかし、正常期間に対しても同様の判定を行っても構わない。正常期間に対しても判定することで理由を明確ができれば、事業者や顧客が正常であることの根拠を確認する際に情報として活用可能である。
【０１５３】
以降では、ＳＬＯ実績値確認プログラム３２４によって生成されるＳＬＯ実績値表示画像の例を示す。顧客は、端末５の出力デバイスを介してこの画像を閲覧してＳＬＯ達成状況を確認し、必要に応じて入力デバイスによりＳＬＯ実績値の訂正操作を行う。以下の説明において、顧客は、端末５の出力デバイスに表示されたＧＵＩ画像を視認し、入力デバイスにより当該ＧＵＩ画像に対して操作を行う。
【０１５４】
図１６は、ＳＬＯ実績値確認プログラム３２４によって生成されたＳＬＯ実績値表示画像の例を示す。この実績値表示画像Ｄ１００は、定期的に発行されるレポートを想定した画像である。この例では、月ごと（２０１３年４月）のＳＬＯ実績値の結果が表示されている。
【０１５５】
セクションＤ１０１は、ＳＬＯ未達成可能性がある場合の警告メッセージ表示である。ＳＬＯ実績値確認プログラム３２４は、データベース４上のＳＬＯ実績値テーブルＴ８００を参照して、各ＳＬＯの実績値（例：実績値の最小値）と保証値とを比較する。実績値が保証値を下回っていた場合には、メッセージを表示する。この例は、２０１３年４月の顧客ＡのＶＭ１の稼働率において、実績値の最小値が保証値を下回っていることを警告している。顧客はこのメッセージを閲覧することで、未達成の可能性があるＳＬＯを絞り込むことができる。
【０１５６】
セクションＤ１０２は、２０１３年４月におけるＳＬＯ別の保証値、実績値、最大値計算で責任対象外とみなしたＳＬ異常期間とその理由を示したテーブルである。実績値列の「○」は保証値達成、「×」は未達成、「△」は未達成の可能性あり、をそれぞれ示している。ＳＬＯ実績値確認プログラム３２４は、ＳＬＯ名、保証値、実績値を、データベース４上のＳＬＯ実績値テーブルＴ８００を参照することで生成する。
【０１５７】
最大値計算で責任対象外とみなしたＳＬ異常期間は、ＳＬＯ実績値テーブルＴ８００の列Ｔ８０８、Ｔ８１０と、そのＩＤを検索キーとして取得した責任判定結果テーブルＴ７００を用いて生成された情報である。画面右上にある「前月へ」と「翌月へ」は、ハイパーリンクであり、これらのリンクが押下されると、ＳＬＯ実績値確認プログラム３２４は、それぞれ前月と翌月のＳＬＯ実績値表示画像に移動する。
【０１５８】
また、最大値計算で責任対象外とみなしたＳＬ異常期間とその理由列には、ＳＬ異常期間とその理由が列挙される。各異常期間の右端にある「確認」ボタンが押下されると、ＳＬＯ実績値確認プログラム３２４は、各日の実績値表示画像に移動する。図１７は、その画像例を示す。
【０１５９】
図１７は、ＳＬＯ実績値確認プログラム３２４によって生成されたＳＬＯ実績値表示画像の例である。この実績値表示画像Ｄ２００は、ＳＬＯ実績値とその計算根拠の詳細を確認することを想定した画像である。この画像例では、ある特定の日（２０１３年４月２日）のＳＬＯ実績値の詳細が表示されている。この画像は、例えば、図１６の実績値表示画像Ｄ１００における４月２日の異常期間の横にある「確認」ボタンを押下することで表示される。
【０１６０】
セクションＤ２０１は、当日ならびに当月のＳＬＯの状況に関する表示である。上部には、当日ならびに当月の実績値の数値情報が示される。この表示情報は、データベース４上のＳＬＯ実績値テーブルＴ８００に基づいて生成できる。下部には、当日のＳＬ正常／異常期間のタイムチャートが示されている。この表示情報は、責任判定結果テーブルＴ７００に基づいて生成できる。顧客は、これらの表示を見ることで、当日のＳＬＯの状況を把握できる。
【０１６１】
セクションＤ２０２は、最大値計算で責任対象外とみなしたＳＬ異常期間とその理由に関する表示である。当日発生した異常期間について、異常の発生期間、責任対象外とみなした理由、根拠となる情報へのハイパーリンク、ＳＬＯ実績値に対する操作ボタンが示される。
【０１６２】
セクションＤ２０２中の根拠となる情報へのハイパーリンクが押下されると、ＳＬＯ実績値確認プログラム３２４は、画像下部にある根拠となるログの詳細表示Ｄ２０３を更新する。このログの詳細表示では、異常判定に利用したログデータの情報と、責任判定に利用したログデータの情報をそれぞれ表示可能である。
【０１６３】
ＳＬＯ実績値確認プログラム３２４は、責任結果判定テーブル７００の列Ｔ７０７及び列Ｔ７１０の参照情報におけるデータＩＤをキーに、ログデータテーブルＴ１００からログデータを取得し、そのデータを加工することで、当該画像を生成できる。図１７は、セクションＤ２０２の＃３の「ハイパーバイザのイベントログ」のハイパーリンクを押下した場合の表示例を示している。
【０１６４】
セクションＤ２０２中の「承認」、「却下」ボタンは、事業者責任対象外とみなされた各異常期間に対して、顧客が承認及び却下のフィードバック入力をするためのボタンである。「承認」が選択された場合には、事業者と顧客双方の合意が取れるため、ＳＬＯ実績値確認プログラム３２４は、当該イベントが事業者責任対象外と確定する。
【０１６５】
一方、「却下」が選択された場合には、ＳＬＯ実績値確認プログラム３２４は、図１８に示す画像を表示し、顧客は、ＳＬＯ実績値の訂正入力を行う。以降では、事業者と顧客の間でのＳＬＯ実績値調整が開始される。この調整処理の詳細については後述するため、ここでは概要のみ説明する。上記の入力が行われるたびに、ＳＬＯ実績値確認プログラム３２４は、ＳＬＯ実績値を再計算し、その結果を再描画する。顧客は、その結果を見て、承認及び訂正内容に問題がなければ、「訂正内容提出」ボタンを押下する。
【０１６６】
「訂正内容提出」ボタンが押下されると、ＳＬＯ実績値確認プログラム３２４は、訂正内容を事業者に送信する。事業者がその内容を確認して問題がなければ、訂正内容を承認する。承認がされた場合には、ＳＬＯ実績値修正プログラム３２５は、ＳＬＯ実績値を訂正後の値で確定し、その旨を顧客に通知する。
【０１６７】
なお、「一括承認」ボタンは、当日の異常期間について、「承認」を一括実施するボタンである。また、「異常期間追加」ボタンは、テーブルに表示された以外のＳＬ異常期間を追加するためのボタンである。このボタンを押下することで、顧客は、図１８に示す画像に移動し、フィードバック入力ができる。
【０１６８】
図１８は、ＳＬＯ実績値確認プログラム３２４によって生成されたＳＬＯ実績値の訂正入力画像の例を示す。このＳＬＯ実績値訂正情報入力画像Ｄ３００は、ある特定のＳＬＯについて、実績値を訂正するために、異常期間を追加、変更し、その責任範囲を変更するための入力画像である。
【０１６９】
この画像例は、ある特定の日（２０１３年４月２日）のＳＬＯ実績値の実績値に対する訂正内容を表示している。具体的には、顧客が図１７のセクションＤ２０２に記載の＃２の異常期間に対して却下ボタンを押下した後に、本画像に移動して訂正入力を行なっている。
【０１７０】
セクションＤ３０１は、ＳＬＯ実績値に対する訂正内容を示し、訂正内容を入力するためのＧＵＩ部品が用意されている。「説明文」は、異常期間の理由を記入するためのテキストフィールドである。「対象ＳＬＯ」は、対象となるインスタンス及び対象となるＳＬＯ名を選択するためのドロップダウンリストである。
【０１７１】
「ＳＬ異常期間」は、ＳＬ異常期間が発生した時刻範囲を設定するためのテキストフィールドである。「責任」は、このＳＬ異常期間の責任者を指定するためのドロップダウンリストである。ドロップダウンリストで選択できる項目は、「事業者責任」、「事業者責任外」、「責任不明」の３種類である。「根拠となる情報」は、ＳＬ異常期間及びその責任者の判定根拠を示す情報である。この例では、既に「ＶＭ１の死活監視ログ」が根拠として設定されている。
【０１７２】
顧客は、「ＶＭ１の死活監視ログ」の領域を押下することで、その根拠の内容を修正できる。つまり、ＳＬＯ実績値確認プログラム３２４は、その修正を受け付ける。一方、その右横にある「追加」が押下されると、ＳＬＯ実績値確認プログラム３２４は、顧客により入力された新たな根拠を設定する。「コメント」は、自由記述を行うためのテキストエリアである。
【０１７３】
右下にある「訂正完了して戻る」ボタンと「訂正完了して提出」ボタンは、それぞれ訂正の完了時に押下するためのボタンである。顧客により前者が押下された場合、ＳＬＯ実績値確認プログラム３２４は、この訂正情報を保持したまま、実績値表示画像Ｄ２００に戻る。戻る際、ＳＬＯ実績値確認プログラム３２４は、訂正情報に基づいて実績値を再計算し、画面上の実績値も更新する。一方、後者が押下された場合、ＳＬＯ実績値確認プログラム３２４は、この訂正情報を保持したまま、訂正内容を事業者に送信する。
【０１７４】
なお、異常期間に対する修正の場合には、セクションＤ２０２に基づいた異常期間の設定値が、デフォルトで入力される。顧客は、これらの設定値を必要に応じて修正する。また、異常期間を新規追加する場合には、これらの入力情報をゼロから設定する。
【０１７５】
セクションＤ３０２は、根拠となる情報を修正／追加する際に表示される入力方法の選択ラジオボタンである。この例では、「ログデータベースを検索」、「ファイルアップロード」、「テキストアップロード」の３種類の方法から一つの方法を選択できる。「ログデータベースを検索」は、データベース４上のログデータテーブルＴ１００を検索して、根拠として登録するための手段を提供する。一方、「ファイルアップロード」、「テキストアップロード」は、外部（例えば、顧客のローカル環境など）からファイルやテキストを根拠として登録するための手段を提供する。
【０１７６】
セクションＤ３０３は、「ログデータベースを検索」を選択した場合に表示される入力インタフェースである。「インスタンス」及び「データ種別」は、ログのインスタンス名とデータ種別を選択するためのドロップダウンリストである。ログ検索対象時刻は、上記のログを取得する際の検索条件を指定するテキストフィールドである。
【０１７７】
これらの情報が変更されるたびに、ＳＬＯ実績値確認プログラム３２４は、ログを再検索し、Ｄ３０３の下部にあるログデータの表示テーブルを更新する。このテーブルの最右列には、選択／非選択を切り替えるチェックボックスが用意されている。このチェックボックスが選択された状態で、「根拠となる情報として追加」ボタンが押下されると、ＳＬＯ実績値確認プログラム３２４は、チェックされたログを根拠となる情報として追加し、この検索インタフェースを閉じる。
【０１７８】
なお、ＳＬＯ実績値確認プログラム３２４が提供する上記検索インタフェースでは、例えば、操作をしている顧客は、顧客名（Ｔ１０１）がその顧客名と一致する全てのログ情報を検索、閲覧できる。一方、操作をしている顧客は、他の顧客名のログを閲覧できないこととする。
【０１７９】
さらに、列Ｔ１０１が事業者のログ（すなわち、共有リソース）については、操作している顧客は、当該顧客のインスタンスと接続関係のあるインスタンスのログのみを検索でき、顧客固有の情報が秘匿化（マスキングあるいはフィルタ）された状態でのみ閲覧できることとする。ＳＬＯ実績値確認プログラム３２４は、接続関係を、構成情報テーブルＴ２００から取得できる。
【０１８０】
「ファイルアップロード」、「テキストアップロード」の場合の入力インタフェース（不図示）は、ログ検索インタフェース用フィールドの代わりに、ファイル選択用ＧＵＩあるいはテキスト入力用ＧＵＩと、「根拠となる情報として追加」ボタンを備える。その他の内容は、セクションＤ３０３と同様である。根拠となる情報により、事業者は、訂正を承認するか否かの判断を、迅速かつ容易に行うことができる。
【０１８１】
以降では、本実施形態におけるＳＬＯ実績値調整ならびに再計算処理について説明する。図１９は、本実施形態におけるＳＬＭポータル３２のＳＬＯ実績値修正プログラム３２５による、ＳＬＯ実績値再計算処理の詳細フローチャートを示す。この処理は、顧客によってＳＬ異常期間が事業者責任外であることが確定（承認）されたときに実行される。
【０１８２】
ＳＬＯ実績値修正プログラム３２５は、特定のＳＬ異常期間について、事業者責任外の承認を入力として受け付ける（Ｓ４０１）。具体的な入力方法は、例えば、実績値表示画像Ｄ２００の各ＳＬ異常期間表示の「承認」ボタンを押下する。
【０１８３】
次に、ＳＬＯ実績値修正プログラム３２５は、データベース４の責任判定結果テーブルＴ７００中の該ＳＬ異常期間のチャンクについて、事業者責任度合Ｔ７０８を「−１」に更新する。また、状態Ｔ７１２を「承認済み」に更新する（Ｓ４０２）。
【０１８４】
さらに、ＳＬＯ実績値修正プログラム３２５は、ＳＬＯ実績値集計プログラム３２１の機能により、ＳＬＯ実績値を再計算する。具体的には、上記の責任判定結果テーブルＴ７００を用いて、ステップＳ３に示したＳＬＯ実績値の集計処理を再実行する。
【０１８５】
ＳＬＯ実績値修正プログラム３２５は、その計算結果を、実績値表示画像Ｄ１００またはＤ２００上に反映する（Ｓ００４）。なお、責任不明の異常期間が承認されることで、実績値の最小値と最大値の間の差が狭まる。もし、最大値と最小値が等しい値になったのであれば、画像は、最大値と最小値の両方ではなく、片方の数値だけを表示してもよい。
【０１８６】
以降では、ＳＬ異常期間の訂正時における処理を説明する。訂正時には顧客と事業者の調整が必要となる。そのため、ＳＬ異常期間の訂正は、承認時のように即座に確定されるのではなく、訂正後に事業者が承認した後で確定される。そのため、以降では訂正入力までの処理と、事業者による訂正内容について、順に説明する。
【０１８７】
図２０は、本実施形態におけるＳＬＭポータル３２のＳＬＯ実績値修正プログラム３２５による、訂正入力時におけるＳＬＯ実績値再計算処理の詳細フローチャートを示す。ＳＬＯ実績値修正プログラム３２５は、特定のＳＬ異常期間について、訂正内容を入力として受け付ける（Ｓ５０１）。具体的な入力方法は、例えば、ＳＬＯ実績値訂正情報入力画像Ｄ３００を介して訂正内容を記入し「訂正完了して戻る」ボタンを押下する。
【０１８８】
訂正の場合には、事業者の承認も伴うので、訂正内容及びＳＬＯ実績値の際計算結果が即座に反映されるべきではない。そのため、ＳＬＯ実績値修正プログラム３２５は、入力を受け付けると、対象となるＳＬＯについて、責任判定結果テーブルＴ７００及びＳＬＯ実績値テーブルＴ８００の一時的なコピーを訂正用に用意する（Ｓ５０２）。以下、訂正用の責任判定結果をＴ７００−２、訂正用のＳＬＯ実績値をＴ８００−２と記載する。
【０１８９】
ＳＬＯ実績値修正プログラム３２５は、訂正用の責任判定結果テーブルＴ７００−２の該当期間のチャンクに対して、入力された訂正内容を登録する（Ｓ５０３）。具体的には、ＳＬＯ実績値修正プログラム３２５は、訂正内容にしたがって、事業者責任度合いＴ７０８、責任判定に利用したログデータの参照情報Ｔ７１０、説明文Ｔ７１１を更新する。
【０１９０】
さらに、ＳＬＯ実績値修正プログラム３２５は、状態Ｔ７１２を「顧客訂正中」に更新する。ＳＬＯ実績値修正プログラム３２５は、手作業による判定情報Ｔ７１３には、コメント欄の情報を追記する。もし、ファイルアップロード／テキストアップロードによって根拠となる情報が登録された場合、ＳＬＯ実績値修正プログラム３２５は、手作業による判定情報Ｔ７１３には、ファイルパスあるいはテキスト情報も追記する。
【０１９１】
ＳＬＯ実績値修正プログラム３２５は、ＳＬＯ実績値集計プログラム３２１の機能により、訂正用のＳＬＯ実績値テーブルＴ８００−２を再計算する。具体的には、ＳＬＯ実績値修正プログラム３２５は、訂正用の責任判定結果テーブルＴ７００−２を用いて、ステップＳ３に示したＳＬＯ実績値の集計処理を再実行する。
【０１９２】
ＳＬＯ実績値修正プログラム３２５は、その計算結果を、実績値表示画像Ｄ１００またはＤ２００上に反映する（Ｓ００４）。ＳＬＯ実績値修正プログラム３２５は、上記を繰り返す。一連の訂正が完了した後、顧客は事業者に訂正内容の提出を行う。ＳＬＯ実績値修正プログラム３２５は、訂正内容の提出を入力として受け付ける（Ｓ５０４）。具体的な入力方法は、例えば、実績値表示画像Ｄ２００の「訂正内容提出」ボタンを押下する。
【０１９３】
続いて、ＳＬＯ実績値修正プログラム３２５は、訂正用の責任判定結果テーブルＴ７００−２のうち状態Ｔ７１２が「顧客訂正中」であるセルの値を、「事業者承認待ち」に変更する（Ｓ５０５）。ＳＬＯ実績値修正プログラム３２５は、顧客から訂正内容の提出が行われた旨を事業者にメール等で通知する（Ｓ５０６）。
【０１９４】
図２１は、本実施形態におけるＳＬＭポータル３２のＳＬＯ実績値修正プログラム３２５による訂正内容承認時における処理の詳細フローチャートである。ここで、根拠となる理由やログが訂正された場合には、もともと適用されていたルールの精度が低い可能性があることを示唆する。そこで本実施形態においては、このような訂正された回数をルールの否定回数としてカウントし、一定回数を超えた場合には、ルール自体を無効化する。本フローチャートは、この無効化までの処理も含む。
【０１９５】
ＳＬＯ実績値修正プログラム３２５は、訂正中の特定のＳＬ異常期間について、訂正内容の承認を入力として受け付ける（Ｓ６０１）。なお、訂正内容の提出通知を受け取った事業者は、事業者向けの実績値表示画像（実績値表示画像Ｄ２００と同等の情報を含み、訂正部分が強調されている画像を想定）を参照して、訂正された責任判定結果テーブルＴ７００−２及びＳＬＯ実績値テーブルＴ８００−２を確認し、問題がなければ実績値表示画像Ｄ２００と同様の入力方法で承認を行うこととする。
【０１９６】
次に、ＳＬＯ実績値修正プログラム３２５は、訂正用の責任判定結果テーブルＴ７００−２と元の責任判定結果テーブルＴ７００を比較する。ＳＬＯ実績値修正プログラム３２５は、責任判定に利用したログデータの参照情報と説明文が一致しないチャンクについて、該当ルールＩＤを取得し、訂正用の責任判定結果テーブルＴ７００−２の該チャンクの該当ルールＩＤを「無」に変更する（Ｓ６０２）。
【０１９７】
ＳＬＯ実績値修正プログラム３２５は、訂正用の責任判定結果テーブルＴ７００−２とＳＬＯ実績値テーブルＴ８００−２を、もとの責任判定結果テーブルＴ７００とＳＬＯ実績値テーブルＴ８００に上書きする（Ｓ６０３）。
【０１９８】
次に、ＳＬＯ実績値修正プログラム３２５は、責任判定結果テーブルＴ７００の中の、状態「事業者承認待ち」を「承認済み」に変更する（Ｓ６０５）。ＳＬＯ実績値修正プログラム３２５は、ステップＳ６０２で取得したルールＩＤを持つ責任判定ルールに対して、否定回数カウンタＴ５０８を１増加させる（Ｓ６０５）。
【０１９９】
ＳＬＯ実績値修正プログラム３２５は、ステップＳ６０２で取得したルールの否定カウンタの回数がしきい値Ｘを超えた場合には、責任判定ルールテーブルＴ５００上の該当するルールの設定を「無効化」する（Ｓ６０６）。このように、否定回数の多いルールについては自動的に除外される。
【０２００】
ＳＬＯ実績値修正プログラム３２５は、事業者によって訂正内容の承認が行われた旨を顧客にメール等で通知する（Ｓ６０７）。ＳＬ異常期間の追加／削除についても、上記と同様の方法のため、説明は省略する。
【０２０１】
本実施形態の実績値表示画像Ｄ１００は、顧客に関するすべてのＳＬＯの実績値及び事業者責任除外期間を一覧で表示する。しかし、顧客がそのすべてを確認、判断するには、コストがかかる。
【０２０２】
それを解決する方法の一つは、ＳＬＯ違反か否かが曖昧で顧客による確認が重要な部分を強調表示する。強調表示としては、確認が重要な部分を色付け表示、重要な部分から順に表示、重要でない部分を非表示にする、などのバリエーションが挙げられる。確認が重要な部分は、保証値の達成／未達成が、折衝次第で変化する可能性の高い部分である。
【０２０３】
確認が重要な部分の判断方法の例を以下に示す。
・実績値が特定の範囲内に含まれるＳＬＯ（例：保証値が最大値と最小値との間（最大値≧保証値≧最小値））
・判定訂正時の影響が大きいＳＬ異常期間（例：期間長さが一定のしきい値Ｙを超えた異常期間）
・判定の確度が低いＳＬ異常期間（例：責任度合の絶対値＜１、または否定回数が一定のしきい値Ｚを超えたルールが適用された期間）
【０２０４】
上記判断基準から選択された一つ又は複数（全てでもよい）を使用することができる。ある部分が選択された条件のいずれか一つに該当する場合、当該部分が強調表示される。顧客は、上記に従って強調表示したＳＬＯ実績値表示を確認することで、確認箇所をさらに絞ることができるため、作業コストをより減らすことができる。
【０２０５】
本実施形態のＳＬＭポータル３２の出力の一例として、実績値計算に関するルールの提示が挙げられる。例えば、ＳＬＭポータル３２は、顧客に関する、ＳＬ異常判定ルールテーブルＴ３００、ＳＬＯ実績値集計ルールテーブルＴ４００、責任判定ルールテーブルＴ５００に記載の全部あるいは一部の情報を出力する機能を有する。例えば、これらの情報を契約書の書面として加工し、印刷顧客にルールが開示することで、実績値の計算方法や例外事項の定義が明確になる。そのため、顧客と事業者間の認識合わせの手段として活用可能である。
【０２０６】
本実施形態では、事業者責任外及び責任不明の異常期間を対象としたフィードバック入力方法を提供する例について述べたが、事業者責任の異常期間や正常期間に対してもフィードバック入力を行えるようにしてもよい。この場合には、ＳＬＭサーバ３上での、顧客と事業者間の実績値の調整がより細かく行える。
【０２０７】
また、本実施形態では、事業者による操作に関しては、訂正内容の承認処理を中心に記載したが、システムは、事業者が顧客と同様に却下や再訂正を行う操作機能を備えていてもよい。これら事業者による操作機能は、本実施形態の顧客向け画像及びフィードバック処理にて説明した内容と同様の方法で実現可能である。これによい、ＳＬＭサーバ３上で、顧客と事業者間の実績値の調整がより細かく行える。
【０２０８】
本実施形態では、事業者の管理システムが顧客のログの一部を預かる例を記載したが、顧客の全ログを預かってもよいし、顧客のログを全く預からなくてもよい。顧客の全ログを預かる例では、ミドルウェアや顧客固有のアプリケーションのログも、ログデータベース上に格納される。
【０２０９】
そのため、顧客による訂正入力時には、ログデータベース上にある情報だけで根拠となる情報を集められる可能性が高まる。また、その情報を用いて、アプリケーションなどのログを含めた責任判定ルールテーブルＴ５００を整備することで、自動判定する範囲も拡大する。これにより、事業者と顧客の間の折衝コストをさらに減らすことができる。
【０２１０】
この構成例では、情報がＳＬＭサーバ３上に集まるので、事業者と顧客の間の情報の非対称性は軽減され得る。しかし、通常、アプリケーションのログの意味は顧客しか把握していないため、折衝の機会を完全になくすことはできない。
【０２１１】
管理システムが顧客のログを全く預からない構成例では、主なフィードバック入力方法は、外部からのファイルやテキストのアップロードである。アップロードされるデータは、顧客システムにおけるログを含み得る。この構成例は、セキュリティ懸念などによって、顧客のログを預かることができない環境においても、必要最低限の情報だけを事業者に提供することにより、本発明を利用可能であることを示す。
【０２１２】
本実施形態では、事業者の責任度合は、−１、０、１の離散値としたが、連続値を用いても良い。この場合には、責任判定ルールテーブルＴ５００の確度に応じて、数値を調整できる。
【０２１３】
以上のようにして、本実施形態のＳＬＭサーバ３は、ログデータテーブルＴ１００、ＳＬ異常判定ルールテーブルＴ３００、責任判定ルールテーブルＴ５００、ＳＬＯ実績値集計ルールテーブルＴ４００を入力として、事業者責任によるＳＬ異常と判断できる範囲とできない範囲を切り分けて、ＳＬＯ実績値の取り得る範囲を計算する。そして、計算したＳＬＯ実績値と、その根拠と共に表示する。
【０２１４】
顧客及び事業者は、このＳＬＯ実績値表示を見ることで、確認範囲を事業者責任の有無が曖昧な部分に絞ることができるため、ＳＬＭのコストを削減できる。また、ＳＬＯ計算方法や例外事項の定義をルールベースで管理し、曖昧な部分の強調表示まで半自動化することで、ＳＬＭシステムを構築、運用し、より正確な実績値を計算するためのコストを削減できる。
【０２１５】
事業者にとっては、ＳＬＭを自動化することで、顧客が増えても、ＳＬＭの仕組みを流用できるため、追加工数が少なくてすむ。また本発明が、運用管理サービスの一部として提供されるならば、顧客にとっては、独自のＳＬＭシステムを構築・運用するコストが削減できる。
【０２１６】
また、本実施形態のＳＬＭサーバ３は、責任有無の判断に対する顧客からの承認／訂正のフィードバック入力を受け付け、その入力内容に基づいて実績値を再計算する。この仕組みを用いて事業者と顧客との間で実績値の調整を行うことで、折衝コストを削減できる。
【０２１７】
上記構成は、ＳＬＭサーバ３におけるログ収集プログラム３１０が取得したログデータにおいて、ＳＬＯ実測値を計算する。計算対象となるログデータは、定期的に収集されたデータに加え、顧客がアップロードした外部データを含んでもよい。
【０２１８】
ＳＬＭサーバ３は、ＳＬＯ実測値のレポートを、Ｗｅｂブラウザ５１上で提示する他、電子メールでレポートファイルを出力する、又は、紙にレポートを出力してもよい。当該紙レポートは、顧客に郵送される。他の画像についても同様である。ＳＬＯ実測値のレポートにおいて、保証値や理由の情報等は省略されていてもよい。
【０２１９】
上記例は、異常期間の責任の所在が、事業者、事業者外、不明の三箇所に分類される。これと異なり、異常期間の責任の所在は、事業者と事業者外又は事業者と不明の二箇所に分類されてもよい。
【０２２０】
上記例は、計算対象期間における異常期間と正常期間を特定する。ＳＬＯによっては、計算対象期間において、異常期間は特定されなくてもよい。例えば、計算対象期間において発生した異常イベントのそれぞれについて、責任の所在が判定され、事業者責任の異常イベント回数に基づき、ＳＬＯ実測値の範囲が計算される。
【０２２１】
本実施形態のＳＬＭシステムは、クラウドサービスに好適であるが、他のサービスにも適用可能である。ＳＬＭサーバ３が要する各ルールの構成は上記例に限定されず、適用されたサービスの責任判定や異常判定に適切な構成のルールが定義される。ルールは、顧客毎に定義されていなくてもよい。一つのＳＬＯに１又は複数の異常判定ルールが適用され得、又、一つのＳＬＯに１又は複数の責任判定ルールが適用され得る。
【０２２２】
本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明したすべての構成を備えるものに限定されるものではない。また、ある例の構成の一部を他の例の構成に置き換えることが可能であり、また、ある例の構成に他の例の構成を加えることも可能である。また、各例の構成の一部について、他の例の追加・削除・置換をすることが可能である。
【０２２３】
また、上記の各構成・機能・処理部等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード等の記録媒体に置くことができる。
【符号の説明】
【０２２４】
１  管理ネットワーク
２  物理的な通信回線
３  ＳＬＭサーバ
３１  ログデータベースプログラム
３１０  ログ収集プログラム
３１１  ログ登録プログラム
３１２  ログ検索プログラム
３２  ＳＬＭポータル
３２０  ＳＬ異常判定プログラム
３２１  ＳＬＯ実績値集計プログラム
３２２  責任判定プログラム
３２３  責任判定ルール登録プログラム
３２４  ＳＬＯ実績値確認プログラム
３２５  ＳＬＯ実績値修正プログラム
４  データベース
５  端末
５１  Ｗｅｂブラウザ
６  顧客システム
６１  ハイパーバイザ
６２  ＶＭ
６３  ＯＳ
６４  ミドルウェア
６５  アプリケーション
６６  監視エージェント
７  端末
７１  Ｗｅｂブラウザ
Ｔ１００  ログデータテーブル
Ｔ２００  構成情報テーブル
Ｔ３００  ＳＬ異常判定ルールテーブル
Ｔ４００  ＳＬＯ実績値集計ルールテーブル
Ｔ５００  責任判定ルールテーブル
Ｔ６００  ＳＬ異常判定結果テーブル
Ｔ７００  責任判定結果テーブル
Ｔ８００  ＳＬＯ実績値テーブル
【図１】
2015138484.tif 000003
【図２】
2015138484.tif 000004
【図３】
2015138484.tif 000005
【図４】
2015138484.tif 000006
【図５】
2015138484.tif 000007
【図６】
2015138484.tif 000008
【図７】
2015138484.tif 000009
【図８】
2015138484.tif 000010
【図９】
2015138484.tif 000011
【図１０】
2015138484.tif 000012
【図１１】
2015138484.tif 000013
【図１２】
2015138484.tif 000014
【図１３】
2015138484.tif 000015
【図１４】
2015138484.tif 000016
【図１５】
2015138484.tif 000017
【図１６】
2015138484.tif 000018
【図１７】
2015138484.tif 000019
【図１８】
2015138484.tif 000020
【図１９】
2015138484.tif 000021
【図２０】
2015138484.tif 000022
【図２１】
2015138484.tif 000023