JP2018190205A - 事業者間一括サービス管理装置および事業者間一括サービス管理方法 - Google Patents

Abstract

【課題】パートナー事業者から提供される構成要素サービスを連携させた連携サービスを監視して故障解析を可能とする。【解決手段】サービス状態管理部１３１は、連携サービスと構成要素サービスを関連付けた利用状況ＤＢ１５０を参照して、連携サービスから構成要素サービスを抽出して、下位の構成要素サービスから順番に、ＳＬＡ管理部１３２にＳＬＡ判定を指示する。ＳＬＡ管理部１３２は、サービスに関連するＳＬＡ判定ルールをプロダクトリソースＤＢ１７０から取得して、ＳＬＡ判定を実行して違反と判定されれば、当該サービスを故障と判断する。【選択図】図４

Description

本発明は、パートナー事業者が提供するサービスを組み合わせた連携サービスを可能とする事業者間一括サービス管理装置および事業者間一括サービス管理方法に関する。

現在、ネットワークサービス、計算機基盤サービスおよびアプリケーションサービスなど各種サービスを提供している卸サービス事業者が出現している。これに伴い、エンドユーザにサービスを提供するサービス事業者の中には、自社で資産を保有せず、卸サービス事業者（パートナー事業者）が提供するサービスを組み合わせて独自サービスを提供するサービス事業者も現れている。ネットワークサービスとは、広域イーサネットサービス（イーサネットは登録商標）、ＩＰ−ＶＰＮ（Internet Protocol Virtual Private Network）サービス、ＭＶＮＯ（Mobile Virtual Network Operator）が提供する移動体通信などのサービスである。計算機基盤サービスは、ＩａａＳ（Infrastructure as a Service）と呼ばれる仮想計算機が利用できるサービスである。アプリケーションサービスは、メールやネットストレージ、Ｗｅｂサーバなど各種アプリケーションが利用できるサービスである。他にも、ファイアウォールのようなゲートウェイのサービス、データベースサーバのようなストレージのサービスが提供されている。

パートナー事業者が提供するサービスを組み合わせた連携サービスの例として、Ｗｅｂサイトのレンタルサービスがある。Ｗｅｂサイトのレンタルサービス事業者は、Ｗｅｂサーバが稼働する計算機基盤サービスと、Ｗｅｂサーバが利用するデータベースサーバのサービスと、Ｗｅｂサーバをネットワーク攻撃から保護するファイアウォールのサービスとを連携させて、エンドユーザに連携させたサービスを提供する。

各々のパートナー事業者は、サービスをＡＰＩ（Application Programming Interface）を介して提供している。例えば、上記のＷｅｂサイトのレンタルサービスを提供するサービス事業者は、以下のような手順でＡＰＩを呼び出してサービスを開始する。（１）サービス事業者は、ＣＰＵ（Central Processing Unit）の仕様やメモリサイズなどを指定して仮想計算機を起動するＡＰＩを呼び出し、Ｗｅｂサーバを起動する。（２）サービス事業者は、ファイアウォールやデータベースサーバを、ＡＰＩを呼び出して起動する。（３）サービス事業者は、Ｗｅｂサーバとファイアウォールとデータベースサーバとが通信できるように、ネットワークで接続する設定のＡＰＩを呼び出す。（４）サービス事業者は、ファイアウォールとインターネットとを接続する設定のＡＰＩを呼び出す。このように、Ｗｅｂサーバのレンタルサービスの構成要素となるサービスが呼び出され、続いて構成要素のサービスが連携するように設定されることで、連携サービスが生成（起動）されて、エンドユーザに提供される。

他の連携サービスの例として、クラウド環境のレンタルサービスがある。具体例としてファイル共有サービスがあり、企業が利用する場合を例にして説明する。このサービスは、ファイル共有サービスそのものを提供するネットストレージのサービス、ネットストレージと利用者である企業の社内ネットワークとを接続するＩＰ−ＶＰＮサービス、および、ネットワーク攻撃からネットストレージを保護するファイアウォールのサービスを構成要素として含む。サービス事業者は、ネットストレージとファイアウォールのサービスをＡＰＩを用いて呼び出して起動し、続いて、ネットストレージとＩＰ−ＶＰＮとを接続するＡＰＩ、ネットストレージとファイアウォールとを接続するＡＰＩ、および、ファイアウォールとインターネットとを接続するＡＰＩを呼び出す。Ｗｅｂサイトのレンタルサービスと同様に、構成要素のサービスが呼び出されて、連携するように設定されて、１つのサービスとしてエンドユーザに提供される。

一方、パートナー事業者と同様に連携サービスを提供する事業者（連携サービス事業者）も、連携サービスがサービス契約書に含まれるＳＬＡ（Service Level Agreement）に記載された性能や品質を順守していることを監視する必要がある。また、連携サービス事業者は、連携サービスの障害（故障）を検出したり、故障の影響範囲（罹障範囲）を特定したりする必要がある。さらに、連携サービス事業者は、連携サービスの故障を検出した場合には、構成要素のどのサービスに故障があるかを特定する一次切り分けを行う必要がある。

連携サービスの稼働状況の監視に関しては、非特許文献１に記載の技術がある。この技術を用いれば、連携サービスを構成する各構成要素のサービスの監視項目を組み合わせて、新たな監視区間（監視エリア）を生成することができる。

尾居愛子, 大西浩行, 木村秀明, "監視項目および監視区間の自動紐付け方法," 2016年電子情報通信学会通信ソサイエティ大会, B-14-11.

非特許文献１の技術を用いれば、構成要素であるサービスの監視項目間の関連性や関連性に紐づく監視対象を把握することができる。しかしながら、連携サービスに故障が発生した場合の、故障の一次切り分けや故障の影響範囲の特定、故障箇所の絞込みについては、非特許文献１には記載がない。このために、連携サービスに故障が発生したときに、故障の一次切り分けや故障の影響範囲の特定、故障個所の絞込みなどの故障解析（故障判断）ができず、故障への対応が遅れてしまうという問題がある。結果として、連携サービスの品質や信頼性が低下してしまう問題が生じる。

本発明は、このような背景を鑑みてなされたのであり、連携サービスを監視して、故障解析を可能とする事業者間一括サービス管理装置および事業者間一括サービス管理方法を提供することを課題とする。

前記した課題を解決するため、請求項１に記載の発明は、サービスを提供するサーバと、複数の前記サービスを構成要素サービスとして連携させた連携サービスを利用するサービス事業者の計算機とネットワークを介して接続され、前記連携サービスを提供する事業者間一括サービス管理装置であって、前記連携サービスと当該連携サービスを構成する複数の前記構成要素サービスとを関連付けた情報が格納される利用状況データベースを記憶する記憶部と、前記構成要素サービスまたは前記連携サービスに関連付けられ、前記構成要素サービスまたは前記連携サービスが所定のサービスレベルを順守しているか違反しているかの判定の規則を示すサービスレベル順守判定ルールに従って、前記構成要素サービスと前記連携サービスとのそれぞれが、前記所定のサービスレベルを順守しているかまたは違反しているかのサービスレベル順守判定を実行するサービスレベル順守判定部と、前記利用状況データベースを参照して、前記連携サービスから前記構成要素サービスを抽出し、抽出された前記構成要素サービスが前記連携サービスならばさらに前記構成要素サービスを抽出することを繰り返し、抽出された下位の構成要素サービスから順番に前記サービスレベル順守判定部に前記サービスレベル順守判定を指示して、前記連携サービスの稼働状態を判定するサービス状態判定を実行するサービス状態管理部とを備えることを特徴とする事業者間一括サービス管理装置とした。

また、請求項８に記載の発明は、サービスを提供するサーバと、複数の前記サービスを構成要素サービスとして連携させた連携サービスを利用するサービス事業者の計算機とネットワークを介して接続され、前記連携サービスを提供する事業者間一括サービス管理装置の事業者間一括サービス管理方法であって、前記事業者間一括サービス管理装置は、前記連携サービスと当該連携サービスを構成する複数の前記構成要素サービスとを関連付けた情報が格納される利用状況データベースを備えており、前記構成要素サービスまたは前記連携サービスに関連付けられ、前記構成要素サービスまたは前記連携サービスが所定のサービスレベルを順守しているか違反しているかの判定の規則を示すサービスレベル順守判定ルールに従って、前記構成要素サービスと前記連携サービスとのそれぞれが、前記所定のサービスレベルを順守しているかまたは違反しているかのサービスレベル順守判定を実行するサービスレベル順守判定ステップと、前記利用状況データベースを参照して、前記連携サービスから前記構成要素サービスを抽出し、抽出された前記構成要素サービスが前記連携サービスならばさらに前記構成要素サービスを抽出することを繰り返し、抽出された下位の構成要素サービスから順番に前記サービスレベル順守判定ステップを実行して、前記連携サービスの稼働状態を判定するサービス状態判定を実行するサービス状態管理ステップとを実行することを特徴とする事業者間一括サービス管理方法とした。

上記の構成により、事業者間一括サービス管理装置は、連携サービスの下位の構成要素サービスからサービスレベル順守判定ルール（ＳＬＡ判定ルール）に従って、サービスがサービスレベルを順守しているかを判断するサービスレベル順守判定（ＳＬＡ判定）を実行する。下位の構成要素サービスからＳＬＡ判定することで、事業者間一括サービス管理装置は、連携サービスを構成するどの構成要素サービスに故障があるかを特定することができ、連携サービスの故障の一次切り分けが可能となる。

請求項２に記載の発明は、前記サービスレベル順守判定部が、前記構成要素サービスに対して前記サービスレベル順守判定を実行するときに、前記構成要素サービスに関連付けられた前記サービスレベル順守判定ルールに従って、前記構成要素サービスを提供する前記サーバから取得された前記構成要素サービスの性能情報を参照して前記サービスレベル順守判定を実行することを特徴とする請求項１に記載の事業者間一括サービス管理装置とした。

上記の構成により、事業者間一括サービス管理装置は、構成要素サービスを提供するサーバから構成要素サービスの性能情報を収集して構成要素サービスのＳＬＡ判定を実行する。こうすることで、構成要素サービスごとに性能情報を取得する機能を開発する必要がなく、既にある構成要素サービスの機能を使ってＳＬＡ判定を実行することが可能となり、事業者間一括サービス管理装置は、性能情報を取得する機能を開発する場合と比べて低コストかつ短期間で新しい構成要素サービスを利用して連携サービスを提供することができるようになる。

請求項３に記載の発明は、前記サービスレベル順守判定部が、前記連携サービスに対して前記サービスレベル順守判定を実行するときに、前記連携サービスに関連付けられた前記サービスレベル順守判定ルールに従って、前記連携サービスの前記構成要素サービスを提供する前記サーバから取得された前記構成要素サービスの性能情報を参照して前記サービスレベル順守判定を実行することを特徴とする請求項１に記載の事業者間一括サービス管理装置とした。

上記の構成により、事業者間一括サービス管理装置は、構成要素サービスを提供するサーバから構成要素サービスの性能情報を収集して連携サービスのＳＬＡ判定を実行する。こうすることで事業者間一括サービス管理装置は、構成要素サービスの性能情報を組み合わせて連携サービスに対するＳＬＡ判定を実行することができ、連携サービスの特徴にあわせたＳＬＡ判定を実行することが可能となる。

請求項４に記載の発明は、前記サービスレベル順守判定部が、前記連携サービスに対して前記サービスレベル順守判定を実行するときに、前記連携サービスに関連付けられた前記サービスレベル順守判定ルールに従って、前記構成要素サービスに対する前記サービスレベル順守判定の結果を用いて前記連携サービスについての前記サービスレベル順守判定を実行することを特徴とする請求項１に記載の事業者間一括サービス管理装置とした。

上記の構成により、事業者間一括サービス管理装置は、構成要素サービスのＳＬＡ判定結果に基づいて連携サービスに対するＳＬＡ判定を実行する。こうすることで事業者間一括サービス管理装置は、構成要素サービスのＳＬＡ判定を組み合わせて連携サービスのＳＬＡ判定を実行することができ、容易に連携サービスのＳＬＡ判定ルールを開発することが可能となる。

請求項５に記載の発明は、前記利用状況データベースの情報が、前記連携サービスの種別と、前記構成要素サービスの種別と、前記連携サービスの状態として正常、故障、故障疑の何れか１つの値を含む状態とをさらに関連付けた情報であり、前記構成要素サービスを提供する前記サーバから前記構成要素サービスの故障の通知があった場合に、前記利用状況データベースを参照して、前記故障の通知のあった前記構成要素サービスの種別と同じ種別の構成要素サービスを構成要素サービスとしている前記連携サービスについて、当該連携サービスに対応する前記利用状況データベースの前記状態を故障疑とし、当該連携サービスに対する前記サービス状態判定を前記サービス状態管理部に指示して、当該連携サービスまたはその構成要素サービスに対する前記サービスレベル順守判定で違反となったときには、当該連携サービスに対応する前記利用状況データベースの前記状態を故障疑から故障に変更し、当該連携サービスおよびその構成要素サービスに対する前記サービスレベル順守判定で順守となったときには、当該連携サービスに対応する前記利用状況データベースの前記状態を故障疑から正常に変更するシナリオ管理部をさらに備えることを特徴とする請求項１に記載の事業者間一括サービス管理装置とした。

上記の構成により、事業者間一括サービス管理装置は、構成要素サービスを提供するサーバから故障の通知を受け、このサービスと同種のサービスまたはその同種のサービスを構成要素サービスとする連携サービスのＳＬＡ判定を実行する。こうすることで事業者間一括サービス管理装置は、故障の通知のあったサービスと同種のサービスの故障を検出することでき、同種であるが異なるサービスの故障の通知がなくても構成要素サービスおよびその構成要素サービスを構成要素とする連携サービスの故障を検出することができる。

請求項６に記載の発明は、前記利用状況データベースの情報が、前記連携サービスの種別と、前記連携サービスの状態として正常、故障、故障疑の何れか１つの値を含む状態とをさらに関連付けた情報であり、前記サービス事業者の計算機から前記連携サービスの故障の通知があった場合に、前記利用状況データベースを参照して、前記故障の通知のあった前記連携サービスの種別と同じ種別の前記連携サービスについて、当該連携サービスに対応する前記利用状況データベースの前記状態を故障疑とし、当該連携サービスに対する前記サービス状態判定を前記サービス状態管理部に指示して、当該連携サービスまたはその構成要素サービスに対する前記サービスレベル順守判定で違反となったときには、当該連携サービスに対応する前記利用状況データベースの前記状態を故障疑から故障に変更し、当該連携サービスおよびその構成要素サービスに対する前記サービスレベル順守判定で順守となったときには、当該連携サービスに対応する前記利用状況データベースの前記状態を故障疑から正常に変更するシナリオ管理部をさらに備えることを特徴とする請求項１に記載の事業者間一括サービス管理装置とした。

上記の構成により、事業者間一括サービス管理装置は、連携サービスの利用者であるサービス事業者から故障の通知を受け、同種のサービスのＳＬＡ判定を実行する。こうすることで事業者間一括サービス管理装置は、故障の通知のあったサービスと同種のサービスの故障を検出することでき、故障を通知したサービス事業者とは別のサービス事業者からの通知がなくても連携サービスの故障を検出することができる。

請求項７に記載の発明は、前記利用状況データベースの情報が、前記連携サービスの前記サービス事業者をさらに関連付けた情報であり、前記シナリオ管理部は、前記サービス事業者ごとに、前記状態が故障である連携サービスのカウントする、前記サービス事業者ごとに、前記状態が故障疑である連携サービスのカウントする、前記連携サービスの種別ごとに、前記状態が故障である連携サービスのカウントする、前記連携サービスの種別ごとに、前記状態が故障疑である連携サービスのカウントするの何れかを実行することを特徴とする請求項５または請求項６に記載の事業者間一括サービス管理装置とした。

上記の構成により、事業者間一括サービス管理装置は、故障したサービスや故障が疑われるサービス、サービス事業者ごとの故障したサービス、サービス事業者ごとの故障が疑われるサービスをカウントする。こうすることで事業者間一括サービス管理装置は、連携サービスの稼働状況をわかりやすく事業者間一括サービス管理装置の管理者に提供することができる。

本発明によれば、連携サービスを監視して、故障解析を可能とする事業者間一括サービス管理装置および事業者間一括サービス管理方法を提供することができる。

本実施形態に係る事業者間一括サービス管理装置を含めた連携サービスシステムの全体構成を示す図である。 本実施形態に係る事業者間一括サービス管理装置が提供する連携サービスの定義および生成を説明するための図である。 本実施形態に係る事業者間一括サービス管理装置が提供する連携サービスのＳＬＡ判定による故障解析を説明するための図である。 本実施形態に係る事業者間一括サービス管理装置の構成例を示す機能ブロック図である。 本実施形態に係る利用状況ＤＢ（DataBase）のデータ構成例を示す図である。 本実施形態に係る性能情報ＤＢのデータ構成例を示す図である。 本実施形態に係るプロダクトリソースＤＢのデータ構成例を示す図である。 本実施形態に係る性能管理項目ＤＢのデータ構成例を示す図である。 本実施形態に係る事業者間一括サービス管理装置が実行する、定期監視を契機とするＳＬＡ判定処理を示すシーケンス図である。 本実施形態に係る事業者間一括サービス管理装置が実行する、サービス事業者からのトラブルチケット受領を契機とするＳＬＡ判定処理を説明するための図である。 本実施形態に係る事業者間一括サービス管理装置が実行する、パートナー事業者からのＳＬＡ違反通知を契機とするＳＬＡ判定処理を説明するための図である。

≪全体構成≫
以下、本発明の実施形態を、図面を参照しながら説明する。本発明である事業者間一括サービス管理装置の構成や処理内容を説明する前に、事業者間一括サービス管理装置が提供する連携サービスや連携サービスの故障解析（故障判断）の概要を説明する。

図１は、本実施形態に係る事業者間一括サービス管理装置１００を含めた連携サービスシステム１０１の全体構成を示す図である。連携サービスシステム１０１は、事業者間一括サービス管理装置１００や連携サービスを利用するサービス事業者２１０の計算機２１１の他に、パートナー事業者が保有し、構成要素となるサービスを提供するアプリケーションサーバ２２０と、計算機基盤サーバ２３０と、ネットワークサーバ２４０とを含んで構成される。

事業者間一括サービス管理装置１００とサービス事業者２１０の計算機２１１とは、ネットワーク２９１によって接続される。アプリケーションサーバ２２０と、計算機基盤サーバ２３０と、ネットワークサーバ２４０とは、ネットワーク２９２を介して事業者間一括サービス管理装置１００と接続される。また、アプリケーションサーバ２２０と計算機基盤サーバ２３０とはネットワーク２９３を介して接続され、計算機基盤サーバ２３０とネットワークサーバ２４０とはネットワーク２９４を介して接続され、アプリケーションサーバ２２０とネットワークサーバ２４０とはネットワーク（不図示）を介して接続される。上記に説明したネットワークは、１つのネットワークであってもよく、この１つのネットワークが、事業者間一括サービス管理装置１００、サービス事業者２１０の計算機２１１、アプリケーションサーバ２２０、計算機基盤サーバ２３０、および、ネットワークサーバ２４０を相互に接続してもよい。

事業者間一括サービス管理装置１００は、アプリケーションサーバ２２０、計算機基盤サーバ２３０、および、ネットワークサーバ２４０が提供するサービスを連携させて、１つのサービス（連携サービス）を生成し、この連携サービスをサービス事業者２１０に提供する。以下、計算機２１１をサービス事業者２１０と同一視して、単にサービス事業者２１０とも記す。

≪連携サービスの定義とサービス生成≫
図２は、本実施形態に係る事業者間一括サービス管理装置１００が提供する連携サービスの定義および生成を説明するための図である。図２に記載のステップＳ１１１〜ステップＳ１１５に沿って、連携サービスの定義と生成（起動）の処理を説明する。なお、以下では連携サービスやその構成要素となるサービスを単にサービスとも記す。また、定義された連携サービスをサービスプロダクトとも記す。

（１）サービスプロダクトの定義：ステップＳ１１１において、事業者間一括サービス管理装置１００が提供する連携サービスがサービスプロダクト１７９として定義される。サービスプロダクト１７９を定義するのは、サービスを利用するサービス事業者２１０または事業者間一括サービス管理装置１００の管理者である。サービスプロダクト１７９が定義されるときには、名称の他に構成要素となるサービス（構成要素サービス）や構成要素サービスの連携に必要な設定の方法が定義される。連携に必要な設定の例としては、構成要素サービスを提供するサーバ間のネットワーク接続、データベースのスキーマなどがある。構成要素サービスは、パートナー事業者のサーバ（図１の符号２２０、２３０、２４０）が提供するサービスとは限らず、別途定義されたサービスプロダクト１７９であってもよい。図２記載のサービスプロダクト＃４は、プロダクト名称が「Ｗｅｂサイトレンタルサービス」として定義されており、その構成要素サービスとなる構成プロダクトは、「サービスプロダクト＃１２」と「サービスプロダクト＃３」と「サービスプロダクト＃８」である。

（２）連携サービスの要求：ステップＳ１１２において、サービス事業者２１０が、事業者間一括サービス管理装置１００に、定義済みのサービスプロダクト＃４を指定して、そのインスタンスとしての連携サービスを要求する。
（３）構成要素サービスの生成：ステップＳ１１３において、連携サービスの要求を受領した事業者間一括サービス管理装置１００は、要求されたサービスプロダクトの構成要素サービスのそれぞれについて、生成（起動）するＡＰＩを呼び出して、構成要素サービスを開始する。構成要素サービスが、パートナー事業者が提供するサービスであるならば、ネットワークを介してサーバ（図１の符号２２０、２３０、２４０）のＡＰＩが呼び出される。構成要素サービスが、別の構成要素サービスを含む連携サービスならば、その連携サービスを要求するステップＳ１１２以降のステップが再帰的に実行される。図２記載のサービスプロダクト＃４の要求があった場合には、構成要素サービスとして、サービスプロダクト＃１２のサービス＃１２と、サービスプロダクト＃３のサービス＃３と、サービスプロダクト＃８のサービス＃８とが生成される。

（４）構成要素サービスの連携：ステップＳ１１４において、事業者間一括サービス管理装置１００は、ステップＳ１１３で生成された構成要素サービスを連携させる。連携の内容としては、構成要素サービスを提供するサーバ同士をネットワークで接続する、データベースのスキーマを定義するなどがある。図２記載のサービス＃１２とサービス＃３とサービス＃８とが連携されて、サービスプロダクト＃４のサービス＃４が生成（起動）されたことになる。

（５）連携サービスの提供：ステップＳ１１５において、事業者間一括サービス管理装置１００は、ステップＳ１１４で生成された連携サービスであるサービス＃４を要求元のサービス事業者２１０に提供する。
以上の処理により、サービス事業者２１０は、複数の構成要素サービスからなる連携サービスを利用することができる。ステップＳ１１１でサービスプロダクトが定義された後は、サービス事業者２１０は、連携サービスがどのような構成要素サービスから構成されるか、その構成要素サービスがどのパートナー事業者（サーバ（図１の符号２２０、２３０、２４０））から提供されるかを意識することなく、連携サービスを要求して利用することができる。

≪連携サービスの故障判断≫
図３は、本実施形態に係る事業者間一括サービス管理装置１００が提供する連携サービスのＳＬＡ判定（サービスレベル順守判定）による故障解析を説明するための図である。図３を参照しながら、連携サービスに対する故障解析の処理を説明する。
事業者間一括サービス管理装置１００は、後述する監視シナリオ部１２１、サービス状態管理部１３１、性能管理部１３３、性能情報ＤＢ１６０、ＳＬＡ管理部１３２、および、プロダクトリソースＤＢ１７０を含んで構成される（後述する図４参照）。以下、ステップＳ１２１〜ステップＳ１２９に沿って、連携サービスの故障解析の処理概要を説明する。

（１）ＳＬＡ判定の実行の指示：ステップＳ１２１において、監視シナリオ部１２１が、サービス状態管理部１３１に対して、所定のタイミング、例えば、定期的にサービスを指定してＳＬＡ判定の実行を指示する。
（２）構成要素サービスの抽出：ステップＳ１２２において、サービス状態管理部１３１は、指定されたサービスを分解して構成要素サービスを抽出する。図３記載のサービス２７１は、サービスプロダクト＃４のサービスであり、サービスプロダクト＃１２のサービス２７２、サービスプロダクト＃３のサービス２７３およびサービスプロダクト＃８のサービス２７４の３つの構成要素サービスに分解されて、抽出される。なお、各サービス（２７１〜２７４）に対して、それぞれにサービス識別子（サービスＩＤ）が割り振られる。例えば、サービス２７１のサービス識別子はＳＶ４３８２３である。

（３）性能情報の収集指示：ステップＳ１２３において、サービス状態管理部１３１は、性能管理部１３３に、サービス（２７１〜２７４）の性能情報の収集を指示する。
（４）性能情報の収集：ステップＳ１２４において、性能管理部１３３は、指定されたサービスの性能情報を収集して、性能情報ＤＢ１６０（後述する図６参照）に格納する。
（５）ＳＬＡ判定を指示：ステップＳ１２５において、サービス状態管理部１３１は、ＳＬＡ管理部１３２にＳＬＡ判定を指示する。指示するときには、サービス状態管理部１３１は、構成要素となるサービスで最も下位のサービスから順にＳＬＡ判定を指示する。ここでは、サービス２７１の下位サービスにはサービス（２７２〜２７４）があり、これらのサービスより下位のサービスは存在しないので、サービス状態管理部１３１は、サービス（２７２〜２７４）の何れかのサービスからＳＬＡ判定を指示する。また、例えば、サービス２７３に下位のサービスがある場合には、サービス状態管理部１３１は、その下位のサービスからＳＬＡ判定を指示する。

（６）ＳＬＡ判定ルールの取得：ステップＳ１２６において、ＳＬＡ管理部（サービスレベル順守判定部）１３２は、指定されたサービスのＳＬＡ判定に必要なＳＬＡ判定ルール（サービスレベル順守判定ルール）をプロダクトリソースＤＢ１７０（後述する図７参照）から取得する。
（７）性能情報の取得：ステップＳ１２７において、ＳＬＡ管理部１３２は、ステップＳ１２６で取得したＳＬＡ判定ルールに含まれ、ＳＬＡ判定時に参照される性能管理項目の性能情報を性能情報ＤＢ１６０から取得する。
（８）ＳＬＡ判定：ステップＳ１２８において、ＳＬＡ管理部１３２は、ステップＳ１２７で取得した性能情報を参照し、ステップＳ１２６で取得したＳＬＡ判定ルールに従って、指定されたサービスがＳＬＡを順守しているか違反しているかを判定する。

（９）結果通知：ステップＳ１２９において、ＳＬＡ管理部１３２は、ステップＳ１２８判断したＳＬＡ判定の結果を監視シナリオ部１２１に通知する。
以上のＳＬＡ判定により、事業者間一括サービス管理装置１００は、ＳＬＡを順守していないサービスを特定することができ、故障している（障害が発生している）連携サービス、または、連携サービスの中の故障している構成要素サービスを特定することができる。また、サービスが故障している場合、事業者間一括サービス管理装置１００は、そのサービスを構成要素とする連携サービスを特定することができ、故障の影響範囲（罹障範囲）を特定することができる。さらに、事業者間一括サービス管理装置１００は、罹障範囲にあるサービス、サービスを提供するサーバ（図１の符号２２０、２３０、２４０）、サーバとの通信の経路にあるネットワーク機器（不図示）など、故障が疑われる設備やその数を把握することができる。このようにして、事業者間一括サービス管理装置１００は、故障解析（故障判断）を実行することができる。このようにして、連携サービス事業者は、故障箇所（故障したサービスまたは故障した設備）を特定でき、サービス復旧を従来より短時間でできるようになり、連携サービスの品質や信頼性を向上させることができる。
以下、事業者間一括サービス管理装置１００の構成や処理内容を説明する。

≪事業者間一括サービス管理装置の構成≫
図４は、本実施形態に係る事業者間一括サービス管理装置１００の構成例を示す機能ブロック図である。事業者間一括サービス管理装置１００は、入出力部１９１と、記憶部１９２と、制御部１９３とを含んで構成される。
入出力部１９１は、ＮＩＣ（Network Interface Card）他から構成され、サービス事業者２１０の計算機２１１（図１参照）やパートナー事業者が所有するアプリケーションサーバ２２０、計算機基盤サーバ２３０、ネットワークサーバ２４０との通信データの送受信を行う。

記憶部１９２は、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）、ＲＡＭ（Random Access Memory）などからなり、事業者間一括サービス管理装置１００の機能を実現させるためのプログラムや処理に必要な一時的なデータを記憶する。記憶部１９２は、後述する利用状況ＤＢ１５０と、性能情報ＤＢ１６０と、プロダクトリソースＤＢ１７０と、性能管理項目ＤＢ１８０とを記憶する。

制御部１９３は、ＣＰＵから構成され、記憶部１９２に記憶されたプログラムを実行することで、事業者間一括サービス管理装置１００を機能させる。制御部１９３は、後述する業務ＡＰＩ部１１０と、シナリオ管理部１２０と、業務リソース管理部１３０と、パートナー事業者ＡＰＩアダプタ部１４０とを含んで構成される。

業務ＡＰＩ部１１０は、サービス事業者２１０や関連システム（不図示）からのサービス要求を、ＡＰＩを介して受け付ける。主なサービス要求として、サービス事業者２１０からのサービスプロダクトを指定してのサービス要求（サービスオーダ実行要求）がある（図２記載のステップＳ１１２参照）。他に、サービスプロダクトを定義するサービス要求（図２記載のステップＳ１１１参照）、サービスの故障を通知するトラブルチケットのサービス要求などがある。トラブルチケットのサービス要求を受け付けるＡＰＩはトラブルチケット対応ＡＰＩ１１２（図４には不図示、後述する図１０参照）である。

シナリオ管理部１２０は、業務ＡＰＩ部１１０が受け付けたサービスに応じた業務シナリオの実行を管理する。シナリオ管理部１２０は、所定のタイミングでＳＬＡ判定を実行する監視シナリオ部１２１と、故障が検出されたときに発行されるトラブルチケットを処理するトラブルチケット対応シナリオ部１２２と、図２に示したようにサービスプロダクトを指定してサービスを生成（起動）する一括構築シナリオ部１２３とを備えている。
監視シナリオ部１２１は、利用状況ＤＢ１５０（後述する図５参照）にアクセスして、ＳＬＡ判定対象のサービスを選択し、そのサービスの識別子（サービス識別子またはサービスＩＤとも記す）を指定して、ＳＬＡ判定を後述するサービス状態管理部１３１に指示する。

図５は、本実施形態に係る利用状況ＤＢ１５０のデータ構成例を示す図である。利用状況ＤＢ１５０は、例えば表形式のデータであり、１つのレコード（行）は、実行中のサービスに関する情報を含んでいる。利用状況ＤＢ１５０のレコードは、サービスＩＤ１５１、プロダクトＩＤ１５２、親サービスＩＤ１５３、ユーザＩＤ１５４、構成サービスＩＤ１５５、開始日時１５６、および、状態１５７の属性（列）を含む。

サービスＩＤ１５１は、当該サービスの識別子（サービス識別子）である。
プロダクトＩＤ１５２は、サービス事業者２１０が当該サービスを要求したときに指定したサービスプロダクトの識別子であり、当該サービスが何のサービス（サービスの種別、サービス種別）であるかを示す。プロダクトＩＤ１５２は、プロダクトリソースＤＢ１７０（後述する図７参照）のプロダクトＩＤ１７１と同じである。

親サービスＩＤ１５３は、当該サービスが連携サービスの構成要素サービスである場合に、その親（上位のサービス）であり、当該サービスを構成要素とする連携サービスのサービス識別子である。当該サービスが、サービス事業者２１０が直接に生成（起動）を要求した連携サービスであり、親サービスが存在しない場合には、親サービスＩＤ１５３は無効値（図５では「−」と記載）となる。

ユーザＩＤ１５４は、当該サービスを利用しているサービス事業者２１０の識別子である。
構成サービスＩＤ１５５は、当該サービスの構成要素サービスのサービス識別子である。当該サービスがパートナー事業者から提供されるサービスの場合には、構成要素サービスは存在せず、構成サービスＩＤ１５５は無効値（図５では「−」と記載）となる。当該サービスが連携サービスである場合には、構成サービスＩＤ１５５は、１つ以上の構成要素サービスのサービス識別子を含む。

レコード２７６は、サービス識別子がＳＶ４７５８３のサービスを示しており、サービス識別子がＳＶ４１５３２のサービスを構成要素サービスとして含んでいる。レコード２７７は、このサービス識別子がＳＶ４１５３２のサービスを示しており、レコード２７６のサービスを親サービスとしている。すなわち、レコード２７６のサービスとレコード２７７のサービスとには上下（親子）関係があり、レコード２７６のサービスが上位（親）のサービスであって、レコード２７７のサービスが下位（子）のサービスである。また、サービスプロダクト＃３７が、構成要素サービスとしてサービスプロダクト＃３２を含んでいる。
開始日時１５６は、当該サービスが開始した日時である。レコード２７６のサービスの開始日時は２０１７年３月２０日の３時２４分５３秒である。

状態１５７は、当該サービスの状態を示す。状態には、正常に稼働している「正常」、故障中である「故障」、構成要素サービスが故障である「下位故障」、同じ種別の（サービスプロダクトが同じ）サービスが故障または下位故障である「被疑」がある。連携サービスに２つの構成要素サービスがあり、一方が「正常」、他方が「故障」ならば、連携サービスは「下位故障」となる。全ての構成要素サービスが「正常」であっても、その親である連携サービス自体が「故障」である場合もある。

故障のサービスが検出されると、サービスプロダクトが同じ（同じ種別の）他のサービスも故障している可能性があると判断され、状態１５７が「被疑」となる。「被疑」となったサービスについては、故障解析のためにＳＬＡ判定が実行され、結果に応じて「正常」、「故障」、「下位故障」の何れかとなる。故障解析のためのＳＬＡ判定については、図１０のステップＳ１３６と図１１のステップＳ１４６で後述する。

図４に戻って、監視シナリオ部１２１は、所定のタイミング、例えば定期的に（サービスプロダクトに応じた間隔で）ＳＬＡ判定を実行する。例えば、サービスプロダクト＃３７のＳＬＡ判定の間隔が１５分であるとする。この場合、監視シナリオ部１２１は、１５分おきにプロダクトＩＤ１５２がサービスプロダクト＃３７であるレコードを利用状況ＤＢ１５０の中で検索し、探索結果のレコードに含まれるサービスＩＤ１５１を指定して、ＳＬＡ判定をサービス状態管理部１３１に指示する。ＳＬＡ判定の処理概要は、図３で説明したとおりであり、詳細は図９を参照して後述する。

トラブルチケット対応シナリオ部１２２は、後述するトラブルチケット管理部１３４が発行し、サービスの故障の情報が含まれるトラブルチケットについて、そのサービスのＳＬＡ判定を後述するサービス状態管理部１３１に指示して故障解析を行う。ＳＬＡ判定の処理概要は、監視シナリオ部１２１が指示したＳＬＡ判定とほぼ同様であり、詳細は図１０と図１１を参照して後述する。
一括構築シナリオ部１２３は、図２で説明したように、サービス事業者２１０から要求（ステップＳ１１２）のあったサービスプロダクトの構成要素サービスを生成し（ステップＳ１１３）、連携させて（ステップＳ１１４）、要求された連携サービスを起動して、サービス事業者２１０に提供する（ステップＳ１１５）一連の処理を実行する。

業務リソース管理部１３０は、シナリオ管理部１２０に備わる業務シナリオや、業務ＡＰＩ部１１０が受け付けたサービス要求から呼び出される機能を備えており、サービス状態管理部１３１、ＳＬＡ管理部１３２、性能管理部１３３、トラブルチケット管理部１３４を含んで構成される。

サービス状態管理部１３１は、監視シナリオ部１２１やトラブルチケット対応シナリオ部１２２に指示されたサービスのＳＬＡ判定を実行する。詳しくは、サービス状態管理部１３１は、指定されたサービスを分解し構成要素サービスを抽出して、各構成要素サービスと指定されたサービスとの性能情報の収集を後述する性能管理部１３３に指示する。続いて、サービス状態管理部１３１は、性能管理部１３３から収集完了の通知を受け取り、後述するＳＬＡ管理部１３２に下位のサービスから順にＳＬＡ判定を指示する。性能情報は、性能管理部１３３により性能情報ＤＢ１６０（後述する図６参照）に格納される。

サービス状態管理部１３１は、指示された連携サービスを構成要素サービスに分解するときに、利用状況ＤＢ１５０を参照する。詳しくは、サービス状態管理部１３１は、監視シナリオ部１２１やトラブルチケット対応シナリオ部１２２が指定したサービス識別子をサービスＩＤ１５１にもつレコードを検索し、検索結果のレコードの構成サービスＩＤ１５５を参照することで、構成要素サービスを取得して、構成要素サービスを抽出する。サービス状態管理部１３１は、抽出した各構成要素サービスのサービス識別子を指定して、性能情報の収集を性能管理部１３３に指示する。

図６は、本実施形態に係る性能情報ＤＢ１６０のデータ構成例を示す図である。性能情報ＤＢ１６０は、例えば表形式のデータであり、１つのレコード（行）は、実行中のサービスに関する性能情報に関連する情報を含んでいる。性能情報ＤＢ１６０のレコードは、サービスＩＤ１６１、プロダクトＩＤ１６２、収集日時１６３、および、収集データ１６４の属性（列）を含む。なお、性能情報は、例えばサービスの応答時間といった性能そのものを示す情報とは限らず、エラーの発生頻度、サービスのダウン時間など、品質または信頼性に関わる情報を含む情報であり、ＳＬＡ判定に必要となる情報である。

サービスＩＤ１６１は、当該のサービスの識別子であり、利用状況ＤＢ１５０のサービスＩＤ１５１と同じである。
プロダクトＩＤ１６２は、当該サービスのサービス種別を示し、利用状況ＤＢ１５０のプロダクトＩＤ１５２と同じである。

収集日時１６３は、性能情報を収集した日時である。図６に記載のレコードの収集日時１６３は、２０１７年３月３０日の１３時４３分２３秒である。
収集データ１６４は、収集された性能情報である。収集データ１６４は、単一のデータではなく、性能情報の測定期間や各種性能の数値を含む。例えば、計算機基盤サーバ２３０（図１参照）の場合には、収集データ１６４は、仮想計算機の性能情報の測定期間、測定期間の平均ＣＰＵ利用率、測定期間に受信したデータのバイト数、測定期間に仮想ボリュームに書込んだデータのバイト数、測定期間に発生した書込みエラーの件数などのデータを含む。

図４に戻り、ＳＬＡ管理部（サービスレベル順守判定部）１３２は、サービス状態管理部１３１から指示されたサービスのＳＬＡ判定を実行する。ＳＬＡ管理部１３２は、プロダクトリソースＤＢ１７０（後述する図７参照）からＳＬＡ判定ルールを取得し、性能情報ＤＢ１６０から性能情報（収集データ１６４）を取得して、ＳＬＡ判定を実行する。

図７は、本実施形態に係るプロダクトリソースＤＢ１７０のデータ構成例を示す図である。プロダクトリソースＤＢ１７０は、サービスプロダクト１７９（図２参照）を示すレコード２７８を複数含んで構成される。プロダクトリソースＤＢ１７０のレコード２７８は、プロダクトＩＤ１７１に対応づけて、プロダクト名称１７２、プロダクト記述１７３、構成プロダクト１７４、契約１７５、ＳＬＡ判定ルール１７６、および、アダプタＩＤ１７７の属性を含んでいる。

プロダクトＩＤ１７１は、当該サービスプロダクトの識別子であり、利用状況ＤＢ１５０のプロダクトＩＤ１５２や性能情報ＤＢ１６０のプロダクトＩＤ１６２と同じである。
プロダクト名称１７２は、当該サービスプロダクトの名称である。サービスプロダクト１７９（図２参照）において、プロダクトＩＤ１７１がサービスプロダクト＃４であるサービスプロダクトのプロダクト名称１７２は、「Ｗｅｂサイトレンタルサービス」である。
プロダクト記述１７３は、当該サービスプロダクトの説明である。

構成プロダクト１７４は、当該サービスプロダクトの構成要素であるサービスプロダクトである。サービスプロダクト１７９（図２参照）において、プロダクトＩＤ１７１がサービスプロダクト＃４であるサービスプロダクトの構成プロダクト１７４は、サービスプロダクト＃１２とサービスプロダクト＃３とサービスプロダクト＃８である。
契約１７５は、当該サービスプロダクトを利用する際のサービス事業者２１０との契約内容であり、ＳＬＡを含む。

ＳＬＡ判定ルール（サービスレベル順守判定ルール）１７６は、当該サービスプロダクトのＳＬＡが満たされているか否かを判定するルールである。ＳＬＡ判定ルール１７６は、性能情報ＤＢ１６０の収集データ１６４に含まれる性能管理項目のデータを参照して、ＳＬＡを順守しているかを判断する。ＳＬＡ判定ルール１７６は、単一の性能管理項目のデータを参照するとは限らず、複数の性能管理項目のデータを参照してＳＬＡを判定する場合もある。ＳＬＡ判定ルールの例として、１５分間隔の書込みエラー発生件数を１時間分累積して、所定の発生件数以下となっているかを判定するルールがある。ネットワークサーバ２４０（図１参照）が提供するサービスならば、通信遅延の発生率、ファイアウォールのサービス（不図示）ならば、通信のスループットなどのＳＬＡ判定ルール１７６がある。

アダプタＩＤ１７７は、当該サービスプロダクトがパートナー事業者から提供されるサービスの場合に、サービスが提供されるインタフェースとなるパートナー事業者ＡＰＩアダプタ部１４０（図４参照）が備える個別のアダプタ１４１の識別子である。パートナー事業者ＡＰＩアダプタ部１４０については後述する。

図４に戻り、ＳＬＡ管理部１３２が、サービス状態管理部１３１からＳＬＡ判定を指示されるときには、判定対象のサービスの識別子を伴って指示される。ＳＬＡ管理部１３２は、利用状況ＤＢ１５０を参照してサービス識別子と同じサービスＩＤ１５１をもつレコードからプロダクトＩＤ１５２を取得し、さらにプロダクトリソースＤＢ１７０を参照して、プロダクトＩＤ１５２と同一のプロダクトＩＤ１７１をもつレコードからＳＬＡ判定ルール１７６を取得する。続いて、ＳＬＡ管理部１３２は、ＳＬＡ判定ルール１７６に含まれる性能管理項目のデータを性能情報ＤＢ１６０の収集データ１６４から取得し、ＳＬＡ判定ルール１７６に従ってＳＬＡ判定を実行して、結果を監視シナリオ部１２１に通知する。

性能管理部１３３は、サービス状態管理部１３１が指示したサービスの性能情報を収集して、性能情報ＤＢ１６０に格納する。収集対象のサービスがパートナー事業者から提供されるサービスの場合には、性能管理部１３３は、後述するパートナー事業者ＡＰＩアダプタ部１４０が備えるアダプタ１４１を介して性能情報を収集する。性能管理部１３３は、利用状況ＤＢ１５０（図５参照）から当該サービスのプロダクトＩＤ１５２を取得し、性能管理項目ＤＢ１８０（後述する図８参照）を検索して、呼び出すアダプタ１４１や収集する性能管理項目を決定する。

図８は、本実施形態に係る性能管理項目ＤＢ１８０のデータ構成例を示す図である。性能管理項目ＤＢ１８０は、例えば表形式のデータであり、１つのレコード（行）は、サービスの性能管理項目に関する情報を含んでいる。パートナー事業者から提供されるサービス（サーバ（図１の符号２２０、２３０、２４０））の性能管理項目は、サーバから提供され、アダプタ１４１を介して性能管理項目の性能情報が取得される。性能管理項目ＤＢ１８０のレコードは、アダプタＩＤ１８１、プロダクトＩＤ１８２、性能管理項目（メトリック名称）１８３、および、ＳＬＡ要否１８４の属性（列）を含む。

アダプタＩＤ１８１は、当該性能管理項目を取得するアダプタ１４１の識別子であり、プロダクトリソースＤＢ１７０（図７参照）のアダプタＩＤ１７７と同じである。アダプタＩＤ１８１で識別されるアダプタ１４１が呼び出されることで、性能情報が取得される。
プロダクトＩＤ１８２は、当該サービスのサービス種別を示し、利用状況ＤＢ１５０のプロダクトＩＤ１５２やプロダクトリソースＤＢ１７０のプロダクトＩＤ１７１と同じである。
性能管理項目１８３は、サービスの性能管理項目の名称（メトリック名称）である。
ＳＬＡ要否１８４は、当該性能管理項目がＳＬＡ判定で参照されるか否かを示し、参照されるならＹ、参照されないならＮである。

図４に戻って、性能管理部１３３は、性能管理項目ＤＢ１８０の中で、利用状況ＤＢ１５０から取得したプロダクトＩＤ１５２と同じプロダクトＩＤ１８２であり、ＳＬＡ要否１８４がＹであるレコードを検索して、アダプタＩＤ１８１と性能管理項目１８３を取得する。次に、性能管理部１３３は、このアダプタＩＤ１８１で識別されるアダプタ１４１を介し、サービス識別子を指定して、性能管理項目１８３の性能情報を取得し、性能情報ＤＢ１６０に格納して、サービス状態管理部１３１に性能情報の取得が完了したことを通知する。
トラブルチケット管理部１３４は、サービスの故障が発見された場合やＳＬＡ違反があった場合に、トラブルチケットを発行する。トラブルチケットには、故障があるサービスの識別子や発行された日時、故障対応の状況などが含まれる。発行されたトラブルチケットはトラブルチケット対応シナリオ部１２２により処理される。

パートナー事業者ＡＰＩアダプタ部１４０は、パートナー事業者が提供するサービスのＡＰＩを呼び出すインタフェース機能を提供する。パートナー事業者ＡＰＩアダプタ部１４０は、インタフェース機能を提供するアダプタ１４１をサービスプロダクトごとに備える。パートナー事業者のサービスが生成されたり、性能情報が取得されたりする場合には、そのサービスに対応するアダプタ１４１が呼び出される。アダプタ１４１が、パートナー事業者が提供するサービス（サーバ（図１の符号２２０、２３０、２４０））のＡＰＩを呼び出すことで、サービスが生成されたり、性能情報が取得されたりする。

≪定期監視におけるＳＬＡ判定処理≫
図９は、本実施形態に係る事業者間一括サービス管理装置１００が実行する、定期監視を契機とするＳＬＡ判定処理を示すシーケンス図である。図９を参照しながら、図３で概要を説明した、監視シナリオ部１２１、サービス状態管理部１３１、ＳＬＡ管理部１３２、性能管理部１３３が実行するＳＬＡ判定処理を説明する。なお、ＳＬＡ判定処理は、定期に限らず、例えば、事業者間一括サービス管理装置１００の負荷が所定の値以上になった場合など、所定のタイミングで実行される。

ステップＳ１１において、監視シナリオ部１２１が、ＳＬＡ判定対象のサービスを特定し、当該サービスの識別子をサービス状態管理部１３１に出力して、ＳＬＡ判定を指示する。詳しくは、監視シナリオ部１２１は、サービスプロダクトに応じた所定の間隔で、利用状況ＤＢ１５０（図５参照）のレコードであって、プロダクトＩＤ１５２が当該サービスプロダクトの識別子であるレコードを検索する。次に、監視シナリオ部１２１は、検索結果のレコードに含まれるサービスＩＤ１５１を指定して、ＳＬＡ判定をサービス状態管理部１３１に指示する。検索結果のレコードが複数の場合には、監視シナリオ部１２１は、順次にＳＬＡ判定を指示する。

ステップＳ１２において、サービス状態管理部１３１は、指定されたサービスを分解して構成要素サービスを抽出して、各構成要素サービスと指定されたサービスとの性能情報の収集を性能管理部１３３に指示する。詳しくは、サービス状態管理部１３１は、利用状況ＤＢ１５０（図５参照）のレコードであって、サービスＩＤ１５１が指示に含まれていたサービス識別子であるレコードを検索し、検索結果のレコードの構成サービスＩＤ１５５から構成要素サービスのサービス識別子を取得する。続いて、サービス状態管理部１３１は、取得した構成要素サービスのサービス識別子がサービスＩＤ１５１である利用状況ＤＢ１５０のレコードを検索して、当該構成要素サービスの構成要素サービスの識別子を取得する。この構成要素サービスを検索する処理を繰り返すことで、サービス状態管理部１３１は、監視シナリオ部１２１から指示されたサービスを分解して、構成要素サービスを抽出する。サービス状態管理部１３１は、指定された連携サービスと抽出した構成要素サービスとのサービス識別子を性能管理部１３３に出力して性能情報の収集を指示する。

ステップＳ１３において、性能管理部１３３は、サービス状態管理部１３１の指示にあったサービスの性能情報を収集して性能情報ＤＢ１６０（図６参照）に格納する。詳しくは、性能管理部１３３は、利用状況ＤＢ１５０のレコードであって、サービスＩＤ１５１が指示にあったサービス識別子であるレコードを検索して、当該サービスのプロダクトＩＤ１５２を取得する。次に、性能管理部１３３は、性能管理項目ＤＢ１８０（図８参照）のレコードであって、プロダクトＩＤ１８２が上記のプロダクトＩＤ１５２であり、ＳＬＡ要否１８４がＹであるレコードを検索して、当該サービスプロダクトのアダプタＩＤ１８１と性能管理項目１８３とを取得する。

続いて、性能管理部１３３は、このアダプタＩＤ１８１で識別されるアダプタ１４１を介して、性能管理項目１８３の性能情報の収集を取得する。アダプタ１４１は、サービスを提供するサーバ（図１の符号２２０、２３０、２４０）のＡＰＩを呼び出して、指定されたサービスの指定された性能管理項目の性能情報を取得して、性能管理部１３３に出力する。性能管理部１３３は、出力された性能情報を性能情報ＤＢ１６０（図６参照）に格納し、サービス状態管理部１３１に性能情報の取得が完了したことを通知する。性能情報ＤＢ１６０に性能情報を格納するときには、性能管理部１３３は、新規にレコードを追加する。続いて、性能管理部１３３は、追加したレコードのサービスＩＤ１６１、プロダクトＩＤ１６２、収集日時１６３、収集データ１６４に、指示されたサービス識別子、上記のプロダクトＩＤ１５２、現在日時、収集した性能情報をそれぞれ格納する。

ステップＳ１４において、監視シナリオ部１２１が指定したサービスを含めて、サービス状態管理部１３１がステップＳ１２で抽出した構成要素サービスの下位のサービスから順に、サービス状態管理部１３１とＳＬＡ管理部１３２とが、ステップＳ１５〜ステップＳ２２を実行する。
ステップＳ１５において、サービス状態管理部１３１は、サービス識別子を指定して、ＳＬＡ判定をＳＬＡ管理部１３２に指示する。

ステップＳ１６において、ＳＬＡ管理部１３２は、ＳＬＡ判定ルール１７６を取得する。詳しくは、ＳＬＡ管理部１３２は、利用状況ＤＢ１５０のレコードであって、サービスＩＤ１５１が指示にあったサービス識別子であるレコードを検索して、当該サービスのプロダクトＩＤ１５２を取得する。次に、ＳＬＡ管理部１３２は、プロダクトリソースＤＢ１７０（図７参照）のレコードであって、プロダクトＩＤ１７１が上記のプロダクトＩＤ１５２であるレコードを検索して、当該サービスプロダクトのＳＬＡ判定ルール１７６を取得する。

ステップＳ１７において、ＳＬＡ管理部１３２は、性能情報を取得する。詳しくは、ＳＬＡ管理部１３２は、性能情報ＤＢ１６０（図６参照）のレコードであって、サービスＩＤ１６１が指示にあったサービス識別子であるレコードを検索して、検索結果のレコードの収集データ１６４を取得する。次に、ＳＬＡ管理部１３２は、ステップＳ１６で取得したＳＬＡ判定ルール１７６に含まれる性能管理項目のデータを上記の収集データ１６４から取得する。ＳＬＡ判定ルール１７６に応じて、ＳＬＡ管理部１３２は、直近の１件の収集データ１６４を取得する場合もあれば、直近の複数の収集データ１６４を取得する場合もある。

ステップＳ１８において、ＳＬＡ管理部１３２は、ＳＬＡ判定を実行する。詳しくは、ＳＬＡ管理部１３２は、ステップＳ１７で取得した性能管理項目のデータを参照し、ＳＬＡ判定ルール１７６に基づいて、当該サービスでＳＬＡ違反があったか否かを判断する。
ステップＳ１９において、ＳＬＡ管理部１３２は、ステップＳ１８でＳＬＡ違反があれば、ステップＳ２０に進み、違反がなければ、ステップＳ２２に進む。
ステップＳ２０において、ＳＬＡ管理部１３２は、ＳＬＡ違反があったことを、監視シナリオ部１２１に通知する。通知には、違反のあったサービスの識別子や違反の内容（ＳＬＡ判定ルール１７６の内容）が含まれる。

ステップＳ２１において、ＳＬＡ管理部１３２は、利用状況ＤＢ１５０（図５参照）を更新する。詳しくは、ＳＬＡ管理部１３２は、利用状況ＤＢ１５０のレコードで、サービスＩＤ１５１がＳＬＡ判定対象のサービス識別子であるレコードを検索して、当該レコードの状態１５７を「故障」に更新する。また、ＳＬＡ管理部１３２は、当該サービスを構成要素とするサービスの状態１５７を「下位故障」に更新する。詳しくは、ＳＬＡ管理部１３２は、利用状況ＤＢ１５０のレコードで、構成サービスＩＤ１５５にＳＬＡ判定対象のサービス識別子が含まれるレコードを検索して、当該レコードの状態１５７を「下位故障」に更新する。さらに、ＳＬＡ管理部１３２は、検索結果のサービスを構成要素とするサービスのレコードを検索して、検索結果のレコードの状態１５７を「下位故障」に更新することを繰り返す。

なお、構成要素サービスが故障である連携サービスについて、連携サービスの状態１５７は構成要素サービスのＳＬＡ判定で「下位故障」に更新される。この連携サービス自体のＳＬＡ判定が違反である場合には、ＳＬＡ管理部１３２が連携サービス自体を「故障」と更新する。この連携サービス自体のＳＬＡ判定が違反でなければ、ＳＬＡ管理部１３２は状態１５７を更新せず、「下位故障」のままとなる。

ステップＳ２２において、ＳＬＡ管理部１３２は、当該サービスのＳＬＡ判定が完了したことをサービス状態管理部１３１に通知する。
ステップＳ２３において、サービス状態管理部１３１がステップＳ１２で抽出した構成要素サービスの全てに対して、ステップＳ１５〜ステップＳ２２を実行したか判断する。監視シナリオ部１２１が指定したサービスを含めて全てのサービスに対して実行したならば、サービス状態管理部１３１は、ステップＳ２４に進み、未処理のサービスがあるならば、下位のサービスからステップＳ１５以降の処理を繰り返す。
ステップＳ２４において、サービス状態管理部１３１は、指示にあったサービスのＳＬＡ判定が完了したことを監視シナリオ部１２１に通知する。

以上の処理において、サービス状態管理部１３１は、指示されたサービスを分解して構成要素サービスを抽出して（ステップＳ１２）、ＳＬＡ管理部１３２が、抽出された各構成要素サービスの中で下位のサービスから順にＳＬＡを順守しているか判定する。サービスに何らかの故障が発生した場合には、事業者間一括サービス管理装置１００は、当該サービスの構成要素まで遡ってＳＬＡ判定しているので、原因となるサービスをＳＬＡ判定結果が違反であることで特定することができ、故障が発生しているサービスの数を把握することができる。また、事業者間一括サービス管理装置１００は、そのサービスを提供しているサーバ、サーバとの通信の経路にあるネットワーク機器など、故障が疑われる設備やその数を把握することができる。以上のようにして、事業者間一括サービス管理装置１００は、故障解析（故障判断）を実行することができる。

また、故障が検出されていない連携サービスであっても、上記の故障解析によって、事業者間一括サービス管理装置１００は、故障が発生している構成要素サービスを特定することができる。事業者間一括サービス管理装置１００は、故障が発生している構成要素サービスを正常なサービスに置き換えるなどして、当該連携サービスを利用しているサービス事業者２１０に影響が出る前に、対応することができる。

≪サービス事業者からのトラブルチケットを契機としたＳＬＡ判定≫
図９を参照して、事業者間一括サービス管理装置１００自身が、所定のタイミングで実行するＳＬＡ判定処理を説明した。続いて、サービス事業者２１０が検知したサービスの故障についてのＳＬＡ判定処理を用いた故障解析を説明する。図１０は、本実施形態に係る事業者間一括サービス管理装置１００が実行する、サービス事業者からのトラブルチケット受領を契機とするＳＬＡ判定処理を説明するための図である。図１０に記載のステップＳ１３１〜ステップＳ１３６に沿って、ＳＬＡ判定処理を説明する。

ステップＳ１３１において、サービス事業者２１０は、利用しているサービスの故障を検知し、事業者間一括サービス管理装置１００に通知する。詳しくは、サービス事業者２１０は、業務ＡＰＩ部１１０が備えるトラブルチケット対応ＡＰＩ１１２を通じて、故障を通知する。通知には、故障が発生したサービスのサービス識別子を含む。
ステップＳ１３２において、トラブルチケット対応ＡＰＩ１１２が、トラブルチケット管理部１３４を呼び出して、トラブルチケットの発行を要求する。

ステップＳ１３３において、トラブルチケット管理部１３４がトラブルチケット２８１を発行する。トラブルチケット２８１には、発行日時、トラブルチケット発行の契機となった故障を通知したサービス事業者２１０のユーザ識別子（トラブルチケット２８１のユーザ）、故障のあるサービスの識別子（トラブルチケット２８１の関連サービス）、対応状態（不図示）などが含まれる。対応状態には、未対応、対応中、対応中断、対応済などの状態があり、トラブル対応（故障解析）の進展状態を示す。発行されたトラブルチケット２８１は、シナリオ管理部１２０が備えるトラブルチケット対応シナリオ部１２２に送られる。

ステップＳ１３４において、トラブルチケット対応シナリオ部１２２が、当該サービスのＳＬＡ判定を実行する。詳しくは、トラブルチケット対応シナリオ部１２２は、トラブルチケット２８１に含まれている故障が発生したサービスの識別子をサービス状態管理部１３１に出力して、ＳＬＡ判定を指示する。サービス状態管理部１３１とＳＬＡ管理部１３２と性能管理部１３３とは、図９に記載したステップＳ１２以降の処理を実行する。但し、ステップＳ２０のＳＬＡ違反の通知先とステップＳ２４のＳＬＡ判定完了の通知先とは、トラブルチケット対応シナリオ部１２２である。

ステップＳ１３５において、トラブルチケット対応シナリオ部１２２が、関連するサービスを特定する。関連するサービスとは、トラブルチケット２８１に含まれる故障が発生したサービスと同じ種別の（同じサービスプロダクトである）サービスである。トラブルチケット対応シナリオ部１２２は、利用状況ＤＢ１５０（図５参照）のレコードの中で、サービスＩＤ１５１がトラブルチケット２８１に含まれる故障が発生したサービスの識別子と同じレコードを検索して、プロダクトＩＤ１５２を取得する。このプロダクトＩＤ１５２が当該サービスのサービスプロダクトを示す識別子である。
次に、トラブルチケット対応シナリオ部１２２は、利用状況ＤＢ１５０のレコードの中で、プロダクトＩＤ１５２が上記の検索結果のプロダクトＩＤ１５２と同じレコードを検索して、サービスＩＤ１５１を取得する。このサービスＩＤ１５１が、故障が発生したサービスと同じ種別のサービスの識別子である。

ステップＳ１３６において、トラブルチケット対応シナリオ部１２２は、関連するサービスのＳＬＡ判定を順次実行する。詳しくは、トラブルチケット対応シナリオ部１２２は、関連するサービスとその構成要素サービスのＳＬＡ判定を実行する。最初に、トラブルチケット対応シナリオ部１２２は、利用状況ＤＢ１５０（図５参照）のレコードであって、ＳＬＡ判定対象のサービスとその構成要素サービスに対応するレコードの状態１５７を「被疑」に更新する。

次に、トラブルチケット対応シナリオ部１２２は、取得したサービスの識別子をサービス状態管理部１３１に出力して、ＳＬＡ判定を指示する。サービス状態管理部１３１とＳＬＡ管理部１３２と性能管理部１３３とは、ステップＳ１３４と同様にＳＬＡ判定処理を実行する。続いて、トラブルチケット対応シナリオ部１２２は、ＳＬＡ判定の結果、構成要素サービスを含めて故障がなければ、利用状況ＤＢ１５０のレコードであって、ＳＬＡ判定対象のサービスとその構成要素サービスに対応するレコードの状態１５７を「正常」に更新する。

図１０に示したサービス事業者２１０からのトラブルチケット受領を契機とするＳＬＡ判定処理を実行すること（ステップＳ１３４）で、事業者間一括サービス管理装置１００は、通知のあったサービスの故障の原因となる構成要素サービスを特定する。さらに、事業者間一括サービス管理装置１００は、関連するサービスとして通知のあったサービスと同じサービスプロダクトのサービスを特定して（ステップＳ１３５）、そのサービスのＳＬＡ判定を行い（ステップＳ１３６）、故障が発生していないか診断する故障解析を実行することができる。事業者間一括サービス管理装置１００は、同じサービスプロダクトを利用している他のサービス事業者２１０からの通知（トラブルチケットの発行）を待つことなく、先んじて故障の発生の有無を判断して故障解析を実行する。また、事業者間一括サービス管理装置１００は、そのサービスを提供しているサーバ、サーバとの通信の経路にあるネットワーク機器など、故障が疑われる設備やその数を把握することが可能となる。

≪パートナー事業者からのＳＬＡ違反を契機としたＳＬＡ判定≫
続いて、パートナー事業者が検知したＳＬＡ違反を契機としたサービスの故障についてのＳＬＡ判定処理を用いた故障判断を説明する。図１１は、本実施形態に係る事業者間一括サービス管理装置１００が実行する、パートナー事業者からのＳＬＡ違反通知を契機とするＳＬＡ判定処理を説明するための図である。図１１に記載のステップＳ１４１〜ステップＳ１４６に沿って、ＳＬＡ判定処理を説明する。図１１では、パートナー事業者を計算機基盤サーバ２３０としているが、アプリケーションサーバ２２０（図１参照）やネットワークサーバ２４０であっても同じ処理となる。

ステップＳ１４１において、計算機基盤サーバ２３０が、提供しているサービスのＳＬＡ違反（故障）を検知し、事業者間一括サービス管理装置１００に通知する。詳しくは、計算機基盤サーバ２３０は、事業者間一括サービス管理装置１００の内部で計算機基盤サーバ２３０へのインタフェースとなっているアダプタ１４１を通じて通知する。通知には、故障が発生したサービスの識別子や違反内容を含む。
ステップＳ１４２において、アダプタ１４１がＳＬＡ違反の通知（ＳＬＡ違反通知）２８３を生成して、トラブルチケット管理部１３４に通知する。ＳＬＡ違反通知２８３には、通知日時、ＳＬＡ違反のあったサービスの識別子、違反の内容などが含まれる。

ステップＳ１４３において、トラブルチケット管理部１３４がトラブルチケット２８４を発行する。トラブルチケット２８４には、発行日時、関連オブジェクトしてＳＬＡ違反通知２８３の識別子（図１１記載のＳＬＡＶ８４７９２）などが含まれる。他に、関連サービスや対応状態などが含まれるが、図示していない。発行されたトラブルチケット２８４とＳＬＡ違反通知２８３は、シナリオ管理部１２０が備えるトラブルチケット対応シナリオ部１２２に出力される。

ステップＳ１４４において、トラブルチケット対応シナリオ部１２２が、当該サービスを構成要素とするサービスのＳＬＡ判定を実行する。詳しくは、トラブルチケット対応シナリオ部１２２は、利用状況ＤＢ１５０（図５参照）の中でサービスＩＤ１５１がトラブルチケット２８４に含まれているサービスの識別子であるレコードを検索して、親サービスＩＤ１５３を取得する。次に、トラブルチケット対応シナリオ部１２２は、利用状況ＤＢ１５０の中でサービスＩＤ１５１が親サービスＩＤ１５３であるレコードを検索して、検索結果のレコードの親サービスＩＤ１５３を取得する。トラブルチケット対応シナリオ部１２２は、親サービスＩＤ１５３が無効値なるまで親サービスＩＤ１５３の検索を繰り返す。

続いて、トラブルチケット対応シナリオ部１２２は、親サービスＩＤ１５３が無効値で親がいないサービスのサービスＩＤ１５１をサービス状態管理部１３１に出力して、ＳＬＡ判定を指示する。サービス状態管理部１３１とＳＬＡ管理部１３２と性能管理部１３３とは、図９に記載したステップＳ１２以降の処理を実行する。但し、ステップＳ２０のＳＬＡ違反の通知先とステップＳ２４のＳＬＡ判定完了の通知先とは、トラブルチケット対応シナリオ部１２２である。

ステップＳ１４５において、トラブルチケット対応シナリオ部１２２が、関連するサービスを特定する。関連するサービスとは、ＳＬＡ違反通知２８３に含まれるサービスと同じサービスプロダクトであるサービスを構成要素とするサービスである。トラブルチケット対応シナリオ部１２２は、利用状況ＤＢ１５０のレコードの中で、サービスＩＤ１５１がＳＬＡ違反通知２８３の関連サービスにある識別子であるレコードを検索して、プロダクトＩＤ１５２を取得する。このプロダクトＩＤ１５２が当該サービスのサービスプロダクトを示す識別子である。次に、トラブルチケット対応シナリオ部１２２は、プロダクトリソースＤＢ１７０の中で構成プロダクト１７４に上記のプロダクトＩＤ１５２を含むレコードを検索して、プロダクトＩＤ１７１を取得する。このプロダクトＩＤ１７１が、故障が発生したサービスを構成要素とするサービスプロダクトの識別子である。

続いて、トラブルチケット対応シナリオ部１２２は、プロダクトリソースＤＢ１７０の中で構成プロダクト１７４に上記のプロダクトＩＤ１７１を含むレコードを検索して、検索結果のレコードのプロダクトＩＤ１７１を取得する。この検索を繰り返すことで、トラブルチケット対応シナリオ部１２２は、ＳＬＡ違反のサービスを構成要素とするサービスプロダクトの識別子を取得することができる。サービスプロダクトの識別子は１つとは限らず、複数の場合もある。次に、トラブルチケット対応シナリオ部１２２は、利用状況ＤＢ１５０の中でプロダクトＩＤ１５２が上記のサービスプロダクトの識別子であるレコードを検索して、サービスＩＤ１５１を取得する。
このサービスＩＤ１５１が、関連するサービスであり、ＳＬＡ違反通知２８３に含まれるサービスと同じサービスプロダクトのサービスを構成要素とするサービスである。

ステップＳ１４６において、トラブルチケット対応シナリオ部１２２は、関連するサービスのＳＬＡ判定を順次実行する。詳しくは、トラブルチケット対応シナリオ部１２２は、関連するサービスとその構成要素サービスのＳＬＡ判定を実行する。最初に、トラブルチケット対応シナリオ部１２２は、利用状況ＤＢ１５０（図５参照）のレコードであって、ＳＬＡ判定対象のサービスとその構成要素サービスに対応するレコードの状態１５７を「被疑」に更新する。次に、トラブルチケット対応シナリオ部１２２は、取得したサービスの識別子をサービス状態管理部１３１に出力して、ＳＬＡ判定を指示する。サービス状態管理部１３１とＳＬＡ管理部１３２と性能管理部１３３とは、ステップＳ１４４と同様にＳＬＡ判定処理を実行する。続いて、トラブルチケット対応シナリオ部１２２は、ＳＬＡ判定の結果、構成要素サービスを含めて故障がなければ、利用状況ＤＢ１５０のレコードであって、ＳＬＡ判定対象のサービスとその構成要素サービスに対応するレコードの状態１５７を「正常」に更新する。

図１１に示したパートナー事業者からのＳＬＡ違反通知を契機とするＳＬＡ判定処理を実行することで、事業者間一括サービス管理装置１００は、通知のあったサービスを構成要素とするサービスの故障診断を行う（ステップＳ１４４）。さらに、事業者間一括サービス管理装置１００は、ＳＬＡ違反のあったサービスプロダクトを構成要素とするサービスプロダクトのサービスを特定して（ステップＳ１４５）、そのサービスのＳＬＡ判定を行い（ステップＳ１４６）、故障が発生していないか診断して故障解析を実行する。故障が発生している可能性があるサービスプロダクトに対して、事業者間一括サービス管理装置１００は、サービス事業者２１０からの通知を待つことなく、先んじて故障の発生の有無を判断する故障解析を実行することができる。また、事業者間一括サービス管理装置１００は、そのサービスを提供しているサーバ、サーバとの通信の経路にあるネットワーク機器など、故障が疑われる設備やその数を把握することができる。さらに、事業者間一括サービス管理装置１００は、ＳＬＡ違反の影響を受けるサービス（影響範囲、罹障範囲）を特定することが可能となる。

≪変形例≫
ＳＬＡ判定ルール１７６（図７参照）は１つのルールとは限らない。仮想ボリュームに対する書込み遅延時間、読込み遅延時間、書込みエラー発生頻度、読込みエラー発生頻度のそれぞれに関するＳＬＡ判定ルールなど、複数のＳＬＡ判定ルールである場合もある。また、ＳＬＡ管理部１３２が実行するＳＬＡ判定の契機は、定期監視（所定のタイミングでの監視）（図３、図９参照）と、サービス事業者２１０からの故障通知（図１０参照）と、パートナー事業者からのＳＬＡ違反通知（図１１参照）であった。契機に応じて、ＳＬＡ管理部１３２は、適用するＳＬＡ判定ルール１７６を変えてもよい。

構成要素をもつサービスのＳＬＡ判定では、複数の構成要素サービスの性能情報を参照したり、構成要素サービスのＳＬＡ判定の結果を用いたりして、ＳＬＡ判定を実行する場合もある。Ｗｅｂサイトレンタルサービスの例で言えば、ファイアウォールとＷｅｂサーバとデータベースサーバとのレスポンス時間を合算することで、Ｗｅｂサイトの利用者からみたレスポンス時間がＳＬＡを順守しているか否かを判断するルールがＳＬＡ判定ルール１７６に含まれてもよい。また、複数の同じサービスを構成要素とする連携サービスにおいて、ＳＬＡ管理部１３２は、所定の割合の構成要素サービスに対するＳＬＡ判定結果が順守であれば連携サービスのＳＬＡ判定結果を順守としてもよい。また、ＳＬＡ管理部１３２は、個々の構成要素サービスの処理能力（スループット）に応じて構成要素サービスのＳＬＡ判定結果に重みづけを行って、連携サービスのＳＬＡ判定を行ってもよい。

また、ＳＬＡ判定ルール１７６の判断結果は、順守または違反の２つではなく、３つ以上の判定レベルであってもよい。ＳＬＡ管理部１３２は、構成要素サービスの判定レベルを組み合せて、連携サービスのＳＬＡ判定を行ってもよい。例えば、判定レベルが、順守レベル３（順守レベルが最高）、順守レベル２、順守レベル１（順守レベルが最低）および違反レベルの４つとする。構成要素サービスに違反レベルがなく、順守レベルの平均が所定の値以上ならば、ＳＬＡ管理部１３２は、連携サービスのＳＬＡ判定結果を順守としてもよい。

定期監視を契機とするＳＬＡ判定では、即座に故障と判断するＳＬＡ判定ルールではなく、複数回の定期監視の性能情報を参照して故障発生を予測してＳＬＡ違反と判断してもよい。例えば、所定の回数の定期監視で連続して利用可能なメモリサイズが継続して減少している場合には、メモリ不足の故障が発生すると予測して、ＳＬＡ違反と判断するルールが、ＳＬＡ判定ルール１７６に含まれていてもよい。また、機械学習技術を用いて複数の構成要素サービスの性能管理項目や複数回の定期監視の性能情報を参照し、故障を予想してＳＬＡ違反と判断するルールがＳＬＡ判定ルール１７６に含まれてもよい。さらには、性能情報だけではなく、サービスプロダクトや構成要素サービスを提供しているパートナー事業者、サービスを提供しているサーバ、そのサーバへの通信経路上にあるネットワーク機器、ネットワーク機器の種別などを含めて故障を予想して判定するルールがＳＬＡ判定ルール１７６に含まれてもよい。

サービス事業者２１０からの故障通知と、パートナー事業者からのＳＬＡ違反通知とを契機とした故障解析において、事業者間一括サービス管理装置１００は、故障が発見されたサービスプロダクトの定期監視の間隔を短くしてもよい。詳しくは、事業者間一括サービス管理装置１００は、当該サービスプロダクトのサービスに対して監視シナリオ部１２１が実行する定期監視の間隔を短くしてもよい。定期監視の間隔を短くすることにより、事業者間一括サービス管理装置１００は、故障発生の確率が高いサービスを重点的に監視できるようになり、短時間で故障を検出することができるようになる。

上記の実施形態では、性能情報が収集され、性能情報ＤＢ１６０に格納された後に、下位の構成要素サービスからＳＬＡ管理部１３２が、ＳＬＡ判定を実行している。ＳＬＡ管理部１３２が、ＳＬＡ判定を実行するごとに、必要な性能情報を収集するようにしてもよい。

性能情報ＤＢ１６０に格納された性能情報は、ＳＬＡ判定の前に収集され、ＳＬＡ判定するときに参照されている。ＳＬＡ判定とは関係なく、性能管理部１３３が性能管理項目ＤＢ１８０にある全ての性能情報を定期的に取得してもよい。この場合には、サービス状態管理部１３１は、図９記載のステップＳ１２の性能情報の収集を指示することなく、指定されたサービスを構成要素サービスを抽出した後にステップＳ１４以降のＳＬＡ判定を実行する。

故障が発生すると、定期監視やトラブルチケット、ＳＬＡ違反通知を契機として、複数のＳＬＡ判定が同時に実行される可能性があり、同じ性能情報が複数回収集される可能性がある。しかしながら、性能管理部１３３が定期的に性能情報を取得しておいて、ＳＬＡ判定がこの性能情報を参照することで、重複した性能情報の収集を回避でき、事業者間一括サービス管理装置１００やパートナー事業者が提供するサービスの負荷を軽減することができる。

性能管理部１３３は、定期的に取得した性能情報を参照し、予め指定された性能管理項目の数値が所定の閾値を越えた場合に、当該サービスについて警告をあげてもよい。所定の時間内に所定回数以上の警告が発生した場合には、当該サービスの故障の可能性があると判断して、当該サービスに対するＳＬＡ判定が実行されてもよい。また、性能管理部１３３は、機械学習技術を用いて複数の構成要素サービスの性能管理項目を参照して、ＳＬＡ違反（故障）を予想してもよい。

利用状況ＤＢ１５０（図５参照）のレコードついて、その構成要素サービスは、そのサービス識別子（構成サービスＩＤ１５５）のみを含んでいた。構成要素プロダクトとして、構成要素サービスのサービスプロダクトの識別子を含めるようにしてもよい。ＳＬＡ違反通知があった場合に、トラブルチケット対応シナリオ部１２２は、利用状況ＤＢ１５０（図５参照）とプロダクトリソースＤＢ１７０（図７参照）の両方にアクセスしてＳＬＡ違反通知があったサービスプロダクトを構成要素とするサービスプロダクトを検索していた。利用状況ＤＢ１５０の属性に構成要素サービスのサービスプロダクトの識別子を加えることで、プロダクトリソースＤＢ１７０へのアクセスが不要となる。

図１０記載のＳ１３６においては、トラブルチケット対応シナリオ部１２２は、関連するサービスごとに、当該サービスとその構成要素サービスに対応する利用状況ＤＢ１５０（図５参照）のレコードの状態１５７を「被疑」に更新して、ＳＬＡ判定を実行し、故障がなければ「正常」にしていた。トラブルチケット対応シナリオ部１２２は、最初に関連するサービスに対応する全てのレコードの状態１５７を「被疑」に更新して、続いて、関連するサービスごとにＳＬＡ判定を実行し、故障がなければ「正常」にしてもよい。こうすることで、事業者間一括サービス管理装置１００は、早期に被疑のサービスを特定することができる。図１１記載のステップＳ１４６でも同様である。

図９記載のＳＬＡ判定処理では、ＳＬＡ管理部１３２が利用状況ＤＢ１５０（図５参照）の状態１５７を「故障」や「下位故障」に更新していた（図９記載のステップＳ２１）。ＳＬＡ違反の通知を受けた監視シナリオ部１２１が更新してもよい。また、図１０と図１１に記載のＳＬＡ判定処理では、トラブルチケット対応シナリオ部１２２が更新してもよい。
利用状況ＤＢ１５０のレコードの状態１５７は、「故障」と「下位故障」を区別していたが、「下位故障」を含めて「故障」としてもよい。

利用状況ＤＢはサービス事業者の識別子（図５記載のユーザＩＤ１５４）を含んで構成されており、事業者間一括サービス管理装置１００は、故障したサービス、故障が疑われるサービス、サービス事業者２１０ごとの故障したサービス、サービス事業者２１０ごとの故障が疑われるサービス、サービスプロダクトごとの故障したサービス、サービスプロダクトごとの故障が疑われるサービスの何れかをカウントすることができる。こうすることで事業者間一括サービス管理装置１００は、連携サービスの稼働状況をわかりやすく事業者間一括サービス管理装置１００の管理者に提供することができる。

≪効果≫
連携サービスに故障があった場合に、事業者間一括サービス管理装置１００は、構成要素サービスまで遡ってＳＬＡ判定を行い、故障の原因を解析することができる。このために、故障の切り分けが容易になり、故障の解析時間を削減することができ、故障からの復旧時間を削減することができる。結果として、事業者間一括サービス管理装置１００は、連携サービスの信頼性を向上したり、故障対応のコストを削減したりすることができる。

事業者間一括サービス管理装置１００は、所定のタイミングでＳＬＡ判定を行っており、サービスに故障があった場合に、どの構成要素サービスが故障しているか特定することができる。
連携サービスの利用者であるサービス事業者２１０からの故障の通知や、構成要素サービスを提供するパートナー事業者からのＳＬＡ違反の通知を契機に、事業者間一括サービス管理装置１００は当該サービスプロダクトのＳＬＡ判定を実行する。事業者間一括サービス管理装置１００は、通知のあったサービスだけではなく、同じサービスプロダクトのサービスに対してもＳＬＡ判定を実行している。事業者間一括サービス管理装置１００は、ＳＬＡ判定の際には、サービスを一旦は故障の被疑サービスとしておき、故障がないと判明したなら、正常としている。

これにより、故障が疑われるサービスを特定して、その後に故障しているサービスに絞り込むことができ、事業者間一括サービス管理装置１００は、故障しているサービスの数や故障の影響範囲（罹障範囲）にあるサービスの数を精度高く把握することができる。また、故障が検出されていない連携サービスであっても、その構成要素サービスに故障があれば、事業者間一括サービス管理装置１００は、この故障を検知することができる。故障が発生した構成要素サービスを正常なサービスに置き換えることで、事業者間一括サービス管理装置１００は、連携サービスに故障が発生する前に故障対応をすることができる。

事業者間一括サービス管理装置１００は、構成要素サービスまで遡ってＳＬＡ判定を実行して、故障を検出しているので、故障の原因となるサービスを特定することができ、故障の影響範囲（罹障範囲）を特定することができる。また、利用状況ＤＢ１５０（図５参照）においてサービスとサービスを利用しているサービス事業者２１０とが関連付けて管理されており、事業者間一括サービス管理装置１００は、サービス事業者２１０ごとに、故障しているサービスやその数を把握することができる。事業者間一括サービス管理装置１００は、罹障範囲に含まれるサービスやそのサービスを提供するサーバ、そのサーバとの通信の経路にあるネットワーク機器など、故障が疑われる設備やその数を把握することができる。

ＳＬＡを判定するときには、事業者間一括サービス管理装置１００は、パートナー事業者が提供する性能管理項目にある性能情報を組み合わせて判定している。このために、新たにＳＬＡ判定に必要な性能情報を取得する機能の開発が不要となり、開発する場合と比べて低コストで連携サービスのＳＬＡ判定を実現することができる。また、新しいパートナー事業者が提供するサービスを構成要素として新しい連携サービスを提供する場合でも、当該パートナー事業者が提供する性能情報を利用してＳＬＡ判定をすることができ、事業者間一括サービス管理装置１００は、性能情報を取得する機能を開発する場合に比べて短期間で新しい連携サービスをサービス事業者へ提供することができる。

事業者間一括サービス管理装置１００は、提供しているサービス全体、各サービス事業者２１０が利用しているサービス、各サービスプロダクトのサービスについて、故障や故障が疑われるサービスをカウントすることができる。こうすることで事業者間一括サービス管理装置１００は、連携サービスの稼働状況をわかりやすく事業者間一括サービス管理装置１００の管理者に提供することができる。

１０１ 連携サービスシステム
１００ 事業者間一括サービス管理装置
１１０ 業務ＡＰＩ部
１２０ シナリオ管理部
１２１ 監視シナリオ部
１２２ トラブルチケット対応シナリオ部
１３０ 業務リソース管理部
１３１ サービス状態管理部（サービスレベル順守判定部）
１３２ ＳＬＡ管理部
１３３ 性能管理部
１３４ トラブルチケット管理部
１４０ パートナー事業者ＡＰＩアダプタ部
１４１ アダプタ
１５０ 利用状況ＤＢ
１６０ 性能情報ＤＢ
１７０ プロダクトリソースＤＢ
１７６ ＳＬＡ判定ルール（サービスレベル順守判定ルール）
１８０ 性能管理項目ＤＢ
２１０ サービス事業者
２１１ 計算機

Claims (8)

1. サービスを提供するサーバと、複数の前記サービスを構成要素サービスとして連携させた連携サービスを利用するサービス事業者の計算機とネットワークを介して接続され、前記連携サービスを提供する事業者間一括サービス管理装置であって、
   前記連携サービスと当該連携サービスを構成する複数の前記構成要素サービスとを関連付けた情報が格納される利用状況データベースを記憶する記憶部と、
   前記構成要素サービスまたは前記連携サービスに関連付けられ、前記構成要素サービスまたは前記連携サービスが所定のサービスレベルを順守しているか違反しているかの判定の規則を示すサービスレベル順守判定ルールに従って、前記構成要素サービスと前記連携サービスとのそれぞれが、前記所定のサービスレベルを順守しているかまたは違反しているかのサービスレベル順守判定を実行するサービスレベル順守判定部と、
   前記利用状況データベースを参照して、前記連携サービスから前記構成要素サービスを抽出し、抽出された前記構成要素サービスが前記連携サービスならばさらに前記構成要素サービスを抽出することを繰り返し、抽出された下位の構成要素サービスから順番に前記サービスレベル順守判定部に前記サービスレベル順守判定を指示して、前記連携サービスの稼働状態を判定するサービス状態判定を実行するサービス状態管理部と
   を備えることを特徴とする事業者間一括サービス管理装置。
2. 前記サービスレベル順守判定部は、前記構成要素サービスに対して前記サービスレベル順守判定を実行するときに、前記構成要素サービスに関連付けられた前記サービスレベル順守判定ルールに従って、前記構成要素サービスを提供する前記サーバから取得された前記構成要素サービスの性能情報を参照して前記サービスレベル順守判定を実行する
   ことを特徴とする請求項１に記載の事業者間一括サービス管理装置。
3. 前記サービスレベル順守判定部は、前記連携サービスに対して前記サービスレベル順守判定を実行するときに、前記連携サービスに関連付けられた前記サービスレベル順守判定ルールに従って、前記連携サービスの前記構成要素サービスを提供する前記サーバから取得された前記構成要素サービスの性能情報を参照して前記サービスレベル順守判定を実行する
   ことを特徴とする請求項１に記載の事業者間一括サービス管理装置。
4. 前記サービスレベル順守判定部は、前記連携サービスに対して前記サービスレベル順守判定を実行するときに、前記連携サービスに関連付けられた前記サービスレベル順守判定ルールに従って、前記構成要素サービスに対する前記サービスレベル順守判定の結果を用いて前記連携サービスについての前記サービスレベル順守判定を実行する
   ことを特徴とする請求項１に記載の事業者間一括サービス管理装置。
5. 前記利用状況データベースの情報は、前記連携サービスの種別と、前記構成要素サービスの種別と、前記連携サービスの状態として正常、故障、故障疑の何れか１つの値を含む状態とをさらに関連付けた情報であり、
   前記構成要素サービスを提供する前記サーバから前記構成要素サービスの故障の通知があった場合に、前記利用状況データベースを参照して、前記故障の通知のあった前記構成要素サービスの種別と同じ種別の構成要素サービスを構成要素サービスとしている前記連携サービスについて、当該連携サービスに対応する前記利用状況データベースの前記状態を故障疑とし、
   当該連携サービスに対する前記サービス状態判定を前記サービス状態管理部に指示して、
   当該連携サービスまたはその構成要素サービスに対する前記サービスレベル順守判定で違反となったときには、当該連携サービスに対応する前記利用状況データベースの前記状態を故障疑から故障に変更し、
   当該連携サービスおよびその構成要素サービスに対する前記サービスレベル順守判定で順守となったときには、当該連携サービスに対応する前記利用状況データベースの前記状態を故障疑から正常に変更するシナリオ管理部をさらに備える
   ことを特徴とする請求項１に記載の事業者間一括サービス管理装置。
6. 前記利用状況データベースの情報は、前記連携サービスの種別と、前記連携サービスの状態として正常、故障、故障疑の何れか１つの値を含む状態とをさらに関連付けた情報であり、
   前記サービス事業者の計算機から前記連携サービスの故障の通知があった場合に、前記利用状況データベースを参照して、前記故障の通知のあった前記連携サービスの種別と同じ種別の前記連携サービスについて、当該連携サービスに対応する前記利用状況データベースの前記状態を故障疑とし、
   当該連携サービスに対する前記サービス状態判定を前記サービス状態管理部に指示して、
   当該連携サービスまたはその構成要素サービスに対する前記サービスレベル順守判定で違反となったときには、当該連携サービスに対応する前記利用状況データベースの前記状態を故障疑から故障に変更し、
   当該連携サービスおよびその構成要素サービスに対する前記サービスレベル順守判定で順守となったときには、当該連携サービスに対応する前記利用状況データベースの前記状態を故障疑から正常に変更するシナリオ管理部をさらに備える
   ことを特徴とする請求項１に記載の事業者間一括サービス管理装置。
7. 前記利用状況データベースの情報は、前記連携サービスの前記サービス事業者をさらに関連付けた情報であり、
   前記シナリオ管理部は、
   前記サービス事業者ごとに、前記状態が故障である連携サービスのカウントする、
   前記サービス事業者ごとに、前記状態が故障疑である連携サービスのカウントする、
   前記連携サービスの種別ごとに、前記状態が故障である連携サービスのカウントする、
   前記連携サービスの種別ごとに、前記状態が故障疑である連携サービスのカウントする
   の何れかを実行することを特徴とする請求項５または請求項６に記載の事業者間一括サービス管理装置。
8. サービスを提供するサーバと、複数の前記サービスを構成要素サービスとして連携させた連携サービスを利用するサービス事業者の計算機とネットワークを介して接続され、前記連携サービスを提供する事業者間一括サービス管理装置の事業者間一括サービス管理方法であって、
   前記事業者間一括サービス管理装置は、前記連携サービスと当該連携サービスを構成する複数の前記構成要素サービスとを関連付けた情報が格納される利用状況データベースを備えており、
   前記構成要素サービスまたは前記連携サービスに関連付けられ、前記構成要素サービスまたは前記連携サービスが所定のサービスレベルを順守しているか違反しているかの判定の規則を示すサービスレベル順守判定ルールに従って、前記構成要素サービスと前記連携サービスとのそれぞれが、前記所定のサービスレベルを順守しているかまたは違反しているかのサービスレベル順守判定を実行するサービスレベル順守判定ステップと、
   前記利用状況データベースを参照して、前記連携サービスから前記構成要素サービスを抽出し、抽出された前記構成要素サービスが前記連携サービスならばさらに前記構成要素サービスを抽出することを繰り返し、抽出された下位の構成要素サービスから順番に前記サービスレベル順守判定ステップを実行して、前記連携サービスの稼働状態を判定するサービス状態判定を実行するサービス状態管理ステップと
   を実行することを特徴とする事業者間一括サービス管理方法。

Images