JP4983599B2 - 情報システム管理装置 - Google Patents

Description

本発明は、情報システム管理装置に関し、更に詳しくは、運用ポリシによって情報システムの管理を行う情報システム管理装置に関する。

運用ポリシを適用して、情報システムの構成の設定変更を行う情報システムが知られている。情報システムに運用ポリシを適用する技術は、例えば特開２００２−２４４８７０号公報、特開平１１−２５０１５３号公報、特開２００３−２４８６４７号公報、特開２００２−１１１７２９号公報に記載さている。図１９は、特開２００２−２４４８７０号公報に記載されたシステム管理支援装置の構成を示している。この装置は、サービスを運用するための分散システム管理サーバ２０８、ジョブ実行サーバ２０４、アプリケーションサーバ２０６、及び、データベース２０１から構成されている。

図２０は、ジョブ実行サーバ２０４に記憶されているデータ及びプログラムを示す。ログ情報２４１及びログ書式情報２４２には、それぞれ、ジョブ実行サーバ２０４のログ情報と、そのログ情報の書式を定義したログ書式情報とが格納されている。ジョブ実行ルール（実行ポリシ）２４３には、分散システム管理サーバ２０８から送られてきた最適化ルールが格納されている。ジョブ実行処理２４４は、アプリケーションサーバから送られてきた要求に基づいてジョブの実行を行なうためのプログラムである。データベース管理処理２４５は、データベース２０１へのデータの格納、更新、データの読み出しを行なうためのプログラムである。

ログ情報取得処理２４６は、ジョブ実行サーバ２０４で実行されたコマンドなどをログ情報としてログ情報２４１に格納し、分散システム管理サーバ２０８からの要求に基づいて、ログ情報やログ書式情報を送る処理を行なうプログラムである。通信処理２４７は、他のアプリケーションサーバ２０６、ジョブ実行サーバ２０４、及び、分散システム管理サーバ２０８と、通信を行なうためのプログラムである。ジョブ２４８は、アプリケーションサーバ２０６からの要求に応じて、各種ジョブを実行するプログラムである。

ジョブ実行ポリシ２４３には、ジョブ実行サーバ２０４内のジョブや、アプリケーションサーバ２０６内のアプリケーションの実行順序を制御し、或いは、アプリケーションサーバ２０６からアクセスするジョブ実行サーバ２０４を制御するための条件が、複数のジョブ実行ポリシとして設定されている。ジョブ実行処理２４４は、ジョブ２４８やアプリケーションの実行により生成されたログ情報を、それぞれのサーバから収集し、収集したログ情報が条件を満たした場合に、この条件に対応付けられたジョブ実行ポリシが実行されるようにする。特開２００２−２４４８７０号公報では、このようにログ情報に基づいて、ジョブ２４８やアプリケーションの実行が決定されるため、日々変化するサービスの要求に対応することが可能となり、最適に情報システムを運用することが可能になるとしている。

特開平１１−２５０１５３号公報には、ルールが存在しないために手動で起動されたジョブの履歴情報から、ルールを自動的に合成することができるワークフロー支援システムが記載されている。このワークフロー支援システムでは、ユーザは、ジョブ投入インターフェースにより、手動で、格納されているルールから逸脱した方法でジョブを起動することができる。この手動で起動されたジョブを含む新たなルールが、格納されているルール履歴と接続情報とに基づいて、ルール自動合成部によって自動合成されて、ルールベースに格納される。これにより、手動で行われた仕事のやり方の事例に基づいてルールが自動合成され、以降は同種のワークフローを自動的に遂行することができる。

特開２００３−２４８６４７号公報には、電子メッセージに関連する複数の情報を、ユーザ又はシステムに送信するように、自動的に優先度決定する技術が記載されている。この技術では、ユーザに対する学習済み重要度に従い、１つ以上の受信メッセージの優先度決定、又は優先順位付けを行うように、明示的、及び/又は、黙示的に学習できるクラシファイアを利用できる。優先度決定された情報を管理するため、グラフィカルユーザインターフェースを提供する。このインターフェースは、メッセージがユーザにどのように受信されて処理されるかについてのユーザの希望に従い、容易にシステムをパーソナライゼーション可能とする。

特開２００２−１１１７２９号公報には、ネットワーク内の被管理装置であるルータで運用されているポリシを、トラヒックの状況に応じて、実時間で最適に調整できるようにしたポリシベース管理システムが記載されている。このポリシベース管理システムは、ネットワーク内の被管理装置に、管理装置から配信されたポリシ情報を運用してトラヒックを制御するポリシ運用手段と、管理装置から配信されたポリシ評価情報に基づいて、運用中のポリシを評価するポリシ評価手段と、管理装置から配信されたポリシ調整情報及びポリシ評価手段による評価結果に基づいて、運用中のポリシを動的に調整するポリシ調整手段とを備える。

特開２００２−２４４８７０号公報に記載された技術では、ジョブ実行ポリシ２４３が固定的であり、その妥当性や最適性があらかじめ検証されていることが前提となっている。つまり、アプリケーションを実行するシステムの構成や環境に合わせて、ジョブ実行ポリシ２４３を汎用化し、改良する旨が記載されていない。従って、システムの構成が大きく変更された場合や、他のシステムへ適用する場合に、ジョブ実行ポリシが妥当であるか否かを検証することはできないという問題がある。

特開平１１−２５０１５３号公報に記載の技術では、ユーザが手動で投入したジョブに基づいて、新たなルールが自動合成されるため、人手を介さない完全な自動化を実現することができない。他のシステムで自動合成されたルールの事例や投入したジョブの実行結果などの実績を統計的に判断した改良ではないため、自動合成した後のルールの妥当性や汎用性についての検証がなされていない。ユーザが手動で投入するジョブには、バグがある可能性があり、バグによってシステムに障害が発生する危険性を、回避することができないという問題がある。

特開２００３−２４８６４７号公報に記載の技術では、学習済み重要度から優先度を決定するまでの学習過程において、多数の電子メッセージを送受信する必要があり、長期間の学習時間が必要になる。優先度を決定するまでの学習過程において、不適切な優先順位付けを行い、適切ではない電子メッセージの送受信を行なう可能性がある。このため、決定した優先度の妥当性の判断は、グラフィカルユーザインターフェースを通してユーザが行なうことになり、妥当性の判断を自動化することはできないという問題がある。

特開２００２−１１１７２９号公報に記載の技術では、トラヒックの状況ごとに、ポリシ中に含まれるパラメータやしきい値を動的に調整するため、多様なトラヒックの状況や異なる特性を持つネットワーク装置に適用できる汎用性のあるポリシの生成がなされない。このため、他のシステムへポリシを流用した場合には、再びポリシ中に含まれるパラメータやしきい値を調整する必要がある。従って、パケットの棄却が発生する可能性があり、調整されたポリシを、要求されるサービスレベルのシステムには流用することができないという問題がある。

本発明は、上記各従来技術の問題点を解消し、運用ポリシの検証に際して、検証時間を短縮できる情報システム管理装置、方法、及び、プログラムを提供することを目的とする。また、本発明は、運用ポリシを自動的に改良し、適用できる情報システムの数と種類を広げることができる情報システム管理装置、方法、及び、プログラムを提供する。

本発明は、提供すべき業務と提供するサービスの保証レベルを指定するサービスレベルとが規定された複数の情報システムを管理する情報システム管理装置において、業務名と、サービスレベルと、情報システム内の資源に対して実行する操作と、操作を実行するための条件とを記述した運用ポリシを登録する運用ポリシ格納手段と、前記情報システムのそれぞれの業務名及びサービスレベルを含む構成情報を記憶する構成格納手段と、前記構成格納手段に記憶された構成情報を参照して、前記運用ポリシの業務名及びサービスレベルと業務名及びサービスレベルがそれぞれ一致する１つ以上の情報システムを抽出する情報システム抽出手段と、前記抽出された情報システムに前記運用ポリシを適用し、該適用して得られた実績データを記憶する運用ポリシ実施手段と、前記記憶された実績データに基づいて、前記適用された運用ポリシの有効性を検証する検証手段とを備え、前記運用ポリシ実施手段は、複数回にわたる前記操作の実行のうちの各回の前記操作の実行前後における前記情報システムの状態変化をモニタし、前記条件が満たされた回数と、前記実行された操作でサービスが改善された回数とを前記実績データとして記憶することを特徴とする情報システム管理装置を提供する。

本発明は、サーバを用い、提供すべき業務と提供するサービスの保証レベルを指定するサービスレベルとが規定された複数の情報システムを管理する情報システム管理方法において、前記サーバが、業務名と、サービスレベルと、情報システム内の資源に対して実行する操作と、操作を実行するための条件とを記述した運用ポリシを運用ポリシ格納手段に登録するステップと、前記サーバが、前記情報システムのそれぞれの業務名及びサービスレベルを含む構成情報を構成格納手段に記憶するステップと、前記サーバが、前記構成格納手段に記憶された構成情報を参照して、前記運用ポリシの業務名及びサービスレベルと業務名及びサービスレベルがそれぞれ一致する１つ以上の情報システムを抽出するステップと、前記サーバが、前記抽出された情報システムに前記運用ポリシを適用し、該適用して得られた実績データを記憶するステップと、前記サーバが、前記記憶された実績データに基づいて、前記適用された運用ポリシの有効性を検証するステップとを備え、前記実績データは、複数回にわたる前記操作の実行のうちの各回の前記操作の実行前後における前記情報システムの状態変化をモニタし、前記条件が満たされた回数と、前記実行された操作でサービスが改善された回数とを含むことを特徴とする情報システム管理方法を提供する。

本発明は、提供すべき業務と提供するサービスの保証レベルを指定するサービスレベルとが規定された複数の情報システムを管理する情報システム管理装置のためのプログラムであって、前記情報システム管理装置に、業務名と、サービスレベルと、情報システム内の資源に対して実行する操作と、操作を実行するための条件とを記述した運用ポリシを運用ポリシ格納手段に登録する処理と、前記情報システムのそれぞれの業務名及びサービスレベルを含む構成情報を構成格納手段に記憶する処理と、前記構成格納手段に記憶された構成情報を参照して、前記運用ポリシの業務名及びサービスレベルと業務名及びサービスレベルがそれぞれ一致する１つ以上の情報システムを抽出する処理と、前記抽出された情報システムに前記運用ポリシを適用し、該適用して得られた実績データを記憶装置に記憶する処理と、前記記憶された実績データに基づいて、前記適用された運用ポリシの有効性を検証する処理とを実行させ、前記実績データは、複数回にわたる前記操作の実行のうちの各回の前記操作の実行前後における前記情報システムの状態変化をモニタし、前記条件が満たされた回数と、前記実行された操作でサービスが改善された回数とを含むことを特徴とするプログラムを提供する。

本発明の情報システム管理装置、方法、及び、プログラムでは、業務名及びサービスレベルが一致する情報システムを用いて、運用ポリシの検証を行う。一般に、異なる情報システム間では、サーバの台数等が異なっている。本発明では、そのような場合でも、検証対象の運用ポリシの業務名及びサービスレベルと一致する業務名及びサービスレベルの情報システムを用いて検証を行うため、より多くの情報システムを用いて検証を行うことができ、運用ポリシの検証に要する時間を短縮できる。

本発明の情報システム管理装置では、前記運用ポリシ実施手段は、前記抽出された情報システムにおいて運用ポリシに記述された操作を実行する条件が満たされると、当該運用ポリシに記述された操作を実行する構成を採用できる。本発明の情報システム管理方法では、前記抽出された情報システムで、運用ポリシに記述された操作を実行する条件が満たされると、当該運用ポリシに記述された操作を実行する構成を採用できる。本発明のプログラムでは、前記抽出された情報システムで、運用ポリシに記述された操作を実行する条件が満たされると、当該運用ポリシに記述された操作を実行させる構成を採用できる。これら構成を採用することにより、資源に対する操作が行われることによって、サービスレベルの維持が図られる。

本発明の情報システム管理装置では、前記運用ポリシ実施手段は、前記操作の実行前後における前記情報システムの状態変化をモニタし、前記条件が満たされた回数と、前記実行された操作でサービスが改善された回数とを前記実績データとして記憶する構成を採用できる。また、本発明の情報システム管理方法では、前記実績データは、前記操作の実行前後における前記情報システムの状態変化をモニタし、前記条件が満たされた回数と、前記実行された操作でサービスが改善された回数とを含む構成を採用できる。本発明のプログラムでは、前記実績データは、前記操作の実行前後における前記情報システムの状態変化をモニタし、前記条件が満たされた回数と、前記実行された操作でサービスが改善された回数とを含む構成を採用できる。これら構成を採用することにより、例えば、改善された回数を条件が満たされた回数で割ることにより、どのくらいの割合で、サービスレベルの維持に貢献できたかを知ることができる。

本発明の情報システム管理装置では、前記検証手段は、前記条件が満たされた回数と、前記実行された操作でサービスが改善された回数との関係が所定の条件を満たす運用ポリシを有効な運用ポリシと判定する構成を採用できる。また、本発明の情報システム管理方法では、前記検証ステップは、前記条件が満たされた回数と、前記実行された操作でサービスが改善された回数との関係が所定の条件を満たす運用ポリシを有効な運用ポリシと判定する構成を採用できる。本発明のプログラムでは、前記検証処理は、前記条件が満たされた回数と、前記実行された操作でサービスが改善された回数との関係が所定の条件を満たす運用ポリシを有効な運用ポリシと判定する構成を採用できる。これら構成を採用することにより、例えば、条件が満たされた回数が所定回数以上有り、かつ、サービスレベルの維持に貢献できた割合が所定の割合以上であったときに、その運用ポリシを、サービスレベルの維持に有効な運用ポリシと判定する構成を採用できる。

本発明の情報システム管理装置では、前記運用ポリシ格納手段は、提供すべき業務が指定され、サービスレベルが指定されない運用ポリシが入力されると、前記提供すべき業務と同じ業務について定義されたサービスレベルの内で最も低いサービスレベルを指定した運用ポリシを記憶し、前記検証手段によって当該運用ポリシが有効と判断されると段階的にサービスレベルを引き上げた運用ポリシに変更する構成を採用できる。本発明の情報システム管理方法は、前記サーバは、提供すべき業務が指定され、サービスレベルが指定されない運用ポリシが入力されると、前記サーバが、前記提供すべき業務と同じ業務について定義されたサービスレベルの内で最も低いサービスレベルを指定した運用ポリシを記憶し、該運用ポリシの検証結果が有効な場合には段階的にサービスレベルを引き上げた運用ポリシに変更するステップを更に備える構成を採用でき、本発明のプログラムは、前記情報システム管理装置に、提供すべき業務が指定され、サービスレベルが指定されない運用ポリシが入力されると、前記提供すべき業務と同じ業務について定義されたサービスレベルの内で最も低いサービスレベルを指定した運用ポリシを記憶し、該運用ポリシの検証結果が有効な場合には段階的にサービスレベルを引き上げた運用ポリシに変更する処理を更に実行させる構成を採用できる。これら構成を採用することにより、サービスレベルを引き上げながら運用ポリシの検証を行うことにより、その運用ポリシを適用可能なサービスレベルを自動判定することができる。

本発明の情報システム管理装置は、前記運用ポリシ格納手段から、前記検証手段によって有効と判定された、業務名とサービスレベルが相互に一致する複数の運用ポリシを読み出し、該複数の運用ポリシから１つ以上の新たな運用ポリシを作成するポリシ作成手段を更に備える構成を採用できる。また、本発明の情報システム管理方法は、前記サーバが、前記検証ステップで有効と判定された、業務名とサービスレベルが相互に一致する複数の運用ポリシを前記記憶装置から読み出し、該読み出した複数の運用ポリシから１つ以上の新たな運用ポリシを作成するステップを更に備える構成を採用できる。本発明のプログラムは、前記情報システム管理装置に、前記検証処理で有効と判定された、業務名とサービスレベルが相互に一致する複数の運用ポリシを前記記憶装置から読み出し、該読み出した複数の運用ポリシから１つ以上の新たな運用ポリシを作成する処理を更に実行させる構成を採用できる。これら構成を採用することにより、検証によって有効性が確かめられた複数の運用ポリシから、新たな運用ポリシを生成することで、より、サービスレベルの維持に有効な運用ポリシを生成できる。また、有効性が検証済みの運用ポリシから、新たな運用ポリシを生成しているため、新たな運用ポリシを適用できる情報システムの数と種類を広げることができる。

本発明の情報システム管理装置は、前記検証手段によって有効と判定された運用ポリシと、当該運用ポリシと業務名及びサービスレベルが一致し、かつ、有効なポリシとして既に運用ポリシ格納手段に登録された運用ポリシとに基づいて、新たな運用ポリシを作成するポリシ作成手段を更に備える構成を採用できる。本発明の情報システム管理方法は、前記サーバが、前記検証ステップで有効と判定された運用ポリシと、有効なポリシとして既に運用ポリシ格納手段に登録された運用ポリシとに基づいて、新たな運用ポリシを作成するステップを更に備える構成を採用でき、本発明のプログラムは、前記情報システム管理装置に、前記検証処理で有効と判定された運用ポリシと、当該運用ポリシと業務名及びサービスレベルが一致し、かつ、有効なポリシとして既に運用ポリシ格納手段に登録された運用ポリシとに基づいて、新たな運用ポリシを作成する処理を更に実行させる構成を採用できる。これら構成を採用することにより、検証により有効と判定された運用ポリシから、よりサービスレベルの維持に有効な運用ポリシを生成できる。

本発明の情報システム管理装置では、前記検証手段は、前記検証手段によって有効と判定された運用ポリシの実績データと、前記ポリシ作成手段によって新たに作成された運用ポリシの実績データとを比較し、該比較結果に基づいて前記新たに作成された運用ポリシを有効又は無効を判定する構成を採用できる。本発明の情報システム管理方法は、前記サーバが、前記検証ステップで有効と判定された運用ポリシの実績データと、前記ポリシ作成手段によって新たに作成された運用ポリシの実績データとを比較し、該比較結果に基づいて前記新たに作成された運用ポリシを有効又は無効と判定するステップを更に備える構成を採用でき、本発明のプログラムは、前記情報システム管理装置によって、前記検証処理で有効と判定された運用ポリシの実績データと、前記ポリシ作成手段によって新たに作成された運用ポリシの実績データとを比較し、該比較結果に基づいて前記新たに作成された運用ポリシを有効又は無効を判定する処理を実行させる構成を採用できる。これら構成を採用することにより、例えば、新たに作成した運用ポリシの実績データが、検証で有効と判断された運用ポリシの実績データよりもよい成績であったときに、その作成した運用ポリシを有効と判定する構成を採用することで、運用ポリシを改良することができる。

本発明の情報システム管理装置では、前記ポリシ作成手段は、複数の運用ポリシ間で、前記操作及び条件の少なくとも一方を入れ替えて、新たな運用ポリシを作成する構成を採用できる。また、本発明の情報システム管理方法では、前記ポリシ作成ステップは、複数の運用ポリシ間で、前記操作及び条件の少なくとも一方を入れ替えて、新たな運用ポリシを作成する構成を採用できる。本発明のプログラムは、前記ポリシ作成処理は、複数の運用ポリシ間で、前記操作及び条件の少なくとも一方を入れ替えて、新たな運用ポリシを作成する構成を採用できる。

本発明の情報システム管理装置では、前記ポリシ作成手段は、複数の運用ポリシの操作及び条件のうちで共通な部分をまとめて、新たな運用ポリシを作成する構成を採用できる。また、本発明の情報システム管理方法では、前記ポリシ作成ステップは、複数の運用ポリシの操作及び条件のうちで共通な部分をまとめて、新たな運用ポリシを作成する構成を採用できる。本発明のプログラムでは、前記ポリシ作成処理は、複数の運用ポリシの操作及び条件のうちで共通な部分をまとめて、新たな運用ポリシを作成する構成できる。

本発明の情報システム管理装置、方法、及び、プログラムでは、検証対象の運用ポリシの業務名及びサービスレベルと一致する業務名及びサービスレベルの情報システムを用いて運用ポリシの検証を行う。このため、より多くの情報システムを用いて検証を行うことができ、運用ポリシの検証に要する時間を短縮できる。

以下、図面を参照し、本発明の実施の形態を詳細に説明する。図１は、本発明の第１実施形態に係る情報システム提供者サーバを含む、情報システム提供システムの構成を示している。情報システム提供者サーバ１００は、情報システム、又は、情報システムの運用の代行を提供するアウトソースサービス事業者センタとして構成される。アウトソースサービス事業者は、複数のクライアント企業（Ｃ００１など）に対し、コンタクトセンタの業務を支援するＣＴＩ（computer telephony integration）アプリケーション、営業プロジェクトや営業人員の管理を支援するＳＦＡ（sales force automation）アプリケーション、顧客データベースの分析を行うＣＲＭ（customer relationship management）アプリケーションなどの提供を行う。

情報システム提供者サーバ１００は、プログラムにより動作するコンピュータシステムとして構成され、運用ポリシ管理サーバ１０１と、サービス契約インタフェース（ＩＦ手段）１０２と、情報システム１０３と、ゲートウェイ装置１０４とを備える。ゲートウェイ装置１０４は、インターネットＮ１を介してクライアント企業からのアクセスを受け付ける。サービス契約ＩＦ手段１０２は、クライアント企業に、提供を受けるアプリケーションとサービスレベルとを指定するためのユーザインタフェースを提供する。情報システム１０３は、アプリケーションを提供するためのシステムとして構成される。情報システム提供者サーバ１００は、契約に応じて、クライアント企業、例えばクライアント企業Ｃ００１に、情報システムＳ０１を貸与する。運用ポリシ管理サーバ１０１は、サービス契約で決められたサービスレベルを保証するために、情報システム１０３内のさまざまな資源に対して操作を行う。

クライアント企業Ｃ００１は、サービスの提供を受けるにあたり、ゲートウェイ装置１０４とサービス契約ＩＦ手段１０２とを通して、アウトソースサービス契約する情報システムのアプリケーションとサービスレベルとを指定する。情報システム提供者サーバ１００は、情報システム１０３を複数有しており、指定されたアプリケーションとサービスレベルとに基づいて情報システムＳ０１を選択し、その情報システムＳ０１をクライアント企業Ｃ００１に割り当てる。情報システム提供者サーバ１００は、クライアント企業Ｃ００１に、割り当てた情報システムＳ０１にアクセスするためのアカウントを与え、インターネットやＶＰＮ（virtual private network：仮想施設網）からアクセスできるように、情報システムＳ０１へのアクセスを開放する。

情報システム提供者サーバ１００は、割り当てられていない情報システム１０３がある限り、クライアント企業との新規のサービス契約に対応することができる。情報システム提供者サーバ１００は、サービス契約期間が終了すると、情報システム１０３の割り当てを解除し、他のクライアント企業との契約に備える。クライアント企業にとっては、アウトソースサービス事業者が、情報システム１０３として、アプリケーション資源、コンピュータ資源、ネットワーク資源、及び、データ資源を一括して提供し、サービス契約で決められたサービスレベルを保証してくれる利便性がある。

図２は、情報システム１０３の構成を示している。情報システム１０３は、コンピュータ資源、ネットワーク資源、アプリケーション資源、及び、データ資源を含む資源１３１と、それらにアクセスするためのＳＮＭＰ（simple network management protocol）クライアント１３２とを備える。資源１３１を構成するコンピュータ資源、ネットワーク資源、アプリケーション資源、データ資源には、あらかじめ固有の資源識別子が割り当てられており、一意に識別が可能である。なお、一般には、資源識別子の割り当てられた資源ごとにＳＮＭＰクライアント１３２が存在するが、図２では、図面簡略化のため、単一のＳＮＭＰクライアント１３２のみを図示している。

コンピュータ資源には、サーバ装置、そのサーバ装置で動作するオペレーティングシステムやその他の基盤ソフトウェア、及び、サーバ装置に付属する外部記憶装置などが含まれる。ネットワーク資源には、スイッチ装置（ＳＷ）、ファイアウォール装置（ＦＷ）、ＶＰＮやＶＬＡＮ（Virtual LAN：仮想ＬＡＮ）の利用権、ネットワーク経路上の最小保証帯域、及び、パケット転送時の優先権が含まれる。アプリケーション資源には、アプリケーションプログラムと、そのアプリケーションプログラムの使用ライセンスとが含まれる。データ資源には、テンプレート、ライブラリ、統計データベース等のアプリケーションが使用するデータと、それらの使用ライセンスとが含まれる。

資源１３１には、予備資源を含ませることができる。例えば、資源１３１には、予備のコンピュータ資源として、障害時にバックアップとして使用し、或いは、高負荷時に能力増強の目的で使用するための予備のサーバ装置を含めることができる。このような予備資源は、複数の情報システム１０３間で貸し借り可能とすることもできる。例えば、情報システムＳ０１内で、予備のサーバ装置が使用されていないときには、その予備のサーバ装置を、一時的に他の情報システムＳ０２等に貸与して、資源の稼働率を維持する。このようにすることで、資源１３１の有効利用を図ることができる。

クライアント企業は、自身の情報端末を用いて、情報システム１０３と接続する。クライアント企業の情報端末と情報システム１０３とは、インターネットやＩＰ ＶＰＮを介して接続される。情報端末には、各地の事業所や工場に設置されたパーソナルコンピュータを用いることができ、また、不特定地点からインターネットに接続されたＰＤＡ（personal digital assistant）や携帯電話機を用いることができる。情報端末と情報システム１０３との間のデータ通信には、ＳＯＡＰプロトコル（simple object access protocol）、音声通信にはＳＩＰプロトコル（session initiation protocol）を使用することができる。この場合、ゲートウェイ装置１０４は、これらのプロトコルを使用した通信が、サービス契約を行なった適正なクライアント企業からのものであるか否かを監視する。

図３は、運用ポリシ管理サーバ１０１を機能ブロック図で示している。運用ポリシ管理サーバ１０１は、構成格納手段１１１、状態監視手段１１２、運用ポリシ実施手段１１３、情報システム分類手段（抽出手段）１１４、運用ポリシ格納手段１１５、運用ポリシ変更手段（作成手段）１１６、サービスレベル格納手段１１７、コンソール１１８、ＳＮＭＰマネージャ１１９、及び、実績集計・評価手段（検証手段）１２０を備える。コンソール１１８は、各種情報の入力を行い、或いは、各種情報を表示画面上に表示する入出力手段として構成される。

ＳＮＭＰマネージャ１１９は、情報システム１０３内のＳＮＭＰクライアント１３２（図２）との間で通信を行う。ＳＮＭＰマネージャ１１９は、ＳＮＭＰプロトコルによって、情報システム１０３の各資源の構成情報と状態情報とを格納したＭＩＢ（management information base）にアクセスする。コンピュータ資源及びネットワーク資源のＭＩＢは、それら資源内のメモリや付属する外部記憶装置内に格納されている。アプリケーション資源及びデータ資源のＭＩＢは、それらが格納されているコンピュータ資源内に格納されている。ＳＮＭＰマネージャ１１９は、ＳＮＭＰプロトコルを用いて、各資源の構成情報に対する設定変更の書き込み（ＳＮＭＰのｓｅｔ処理）を行なう。また、各資源の構成情報及び状態情報に対する読み出し（ＳＮＭＰのｇｅｔ処理とｔｒａｐ処理）を行なう。

各資源の構成情報及び状態情報は、コンピュータ資源、ネットワーク資源、アプリケーション資源、データ資源といった資源の種別ごとに異なっており、あらかじめＭＩＢとして規定されている。例えば、コンピュータ資源のＭＩＢには、サーバ装置のモデル名やオペレーティングシステムのバージョン番号などの構成情報、ＣＰＵ使用率（％）、メモリ使用量（ＭＢｙｔｅ）などの状態情報が含まれる。また、ネットワーク資源のＭＩＢには、スイッチ装置のモデル名やＶＬＡＮの割り当てなどの構成情報と、トラヒック流量（ＭＢｙｔｅ／ｓ）などの状態情報とが含まれる。

ＳＮＭＰマネージャ１１９は、ＳＮＭＰのｇｅｔ処理によって、例えば、コンピュータ資源のＭＩＢから、ＣＰＵ使用率を取得する。また、ＳＮＭＰのｓｅｔ処理により、予備のサーバ装置のＭＩＢの構成情報の現用・予備（ｗｏｒｋｉｎｇ／ｂａｃｋｕｐ）を指定する情報を書き換えて、サーバ装置の設定変更を行い、かつ、予備のサーバ装置とゲートウェイ装置１０４との間を接続するＳＷ装置やＦＷ装置のＭＩＢの構成情報への書き込みを行って、予備資源として用意されているサーバ装置を現用サーバとして使用するように設定変更を行う。

コンピュータ資源及びネットワーク資源に関しては、標準的に規格化されているＭＩＢ定義を使用し、必要に応じてアウトソースサービス事業者が拡張したＭＩＢ定義を使用する。一方、アプリケーション資源とデータ資源については、標準的に規格化されているＭＩＢの定義はなく、アプリケーション資源やデータ資源ごとに、それらに特有の構成情報及び状態情報を定義する。例えば、アプリケーション資源であるＣＴＩアプリケーションのＭＩＢとして、サービスレベルや電話への応答の優先度などの構成情報と、サーバ装置あたりの同時アクセス数などの状態情報とを定義する。

構成格納手段１１１は、更に情報システム１０３の属性の情報を格納する。図４は、構成格納手段１１１に格納される情報システム１０３の属性情報を示している。同図において、「情報システム識別子」は、個々の情報システム１０３の識別子を示している。同図の例では、Ｓ０１からＳ０４までの４つの情報システム１０３が記載されている。「クライアント識別子」は、アウトソースサービス事業者がサービス契約しているクライアント企業の識別子を示している。同図の例では、情報システムＳ０１〜Ｓ０４について、各情報システム１０３に割り当てられたＣ００１からＣ００３までの３つのクライアント企業が記載されている。「クライアント識別子」は、クライアント企業との契約に基づいて、サービス契約ＩＦ手段１０２によって、或いは、コンソール１１８によって入力される。

「アプリケーション」及び「サービスレベル」は、それぞれ、契約に従ってクライアント企業に提供するアプリケーションの名称とサービスレベルの指定値を示している。これら「アプリケーション」及び「サービスレベル」の属性値は、クライアント企業との契約に基づいて、サービス契約ＩＦ手段１０２によって、或いは、コンソール１１８によって入力される。図４の例では、情報システムＳ０１〜Ｓ０３は、それぞれＣＴＩアプリケーションを提供することを示している。また、情報システムＳ０１及びＳ０２は、それぞれ、ＣＴＩアプリケーションをサービスレベル２で提供することを示し、情報システムＳ０３は、ＣＴＩアプリケーションをサービスレベル１で提供することを示している。

「サービスレベル」は、クライアント企業に提供するアプリケーションに対するサービスの保証レベルを指定する値を属性値とする。具体的には、アプリケーションの性能や信頼性の保証レベルである。本実施形態においては、サービスレベルの属性値を整数で示し、小さな値がより高品質な保証レベルを示し、大きな値がより低品質な保証レベルに対応するものとする。例えば、ＣＴＩアプリケーションでは、レベル「２」は応答時間５秒以内を示し、レベル「１」は応答時間３秒以内を示す。また、ＳＦＡアプリケーションでは、レベル「２」は対応する携帯端末数の上限１００を示し、レベル「１」は上限１０００を示す。ＣＲＭアプリケーションでは、レベル「２」は収容する顧客数の上限１０，０００を示し、レベル「１」は上限１，０００，０００を示す。クライアント企業は、性能が高い情報システムを必要とする場合には、アウトソースサービス事業者に対して、高品質なサービスを受けることを保証するサービスレベル、例えばレベル１を指定する。また、性能が高い情報システムをそれほど必要としていない場合には、アウトソースサービス事業者に対して、例えばレベル２を指定する。

「コンピュータ資源識別子」には、情報システム１０３が利用しているコンピュータ装置の資源識別子が記載される。「ネットワーク資源識別子」、「アプリケーション識別子」、「データ資源識別子」についても、同様に、情報システム１０３が利用する資源の識別子が記載される。これら識別子は、ＳＮＭＰマネージャ１１９によって、情報システム１０３内の資源から取得される。例えば、ネットワーク資源識別子「ＳＷ装置１」はＩＥＥＥ８０２．１ ＬＡＮ規格のスイッチ装置を示し、「ＲＴ装置１」はＩＰルータ装置を示す。また、「ＬＢ装置１」はロードバランサ装置、「ＦＷ装置１」はファイアウォール装置、「ＶＰＮ装置１」はＶＰＮの終端装置をそれぞれ示す。

状態監視手段１１２は、ＳＮＭＰマネージャ１１９とＳＮＭＰクライアント１３２（図２）とを経由して、ＭＩＢから、構成情報及び状態情報を読み出し、資源の状態を監視する。状態監視手段１１２は、構成情報又は状態情報を読み出す際には、構成格納手段１１１を参照し、読み出し対象の資源を調べて、その資源から情報の読み出しを行う。例えば、情報システムＳ０１におけるサーバ装置のハードウェアのモデル名を読み出す際には、構成格納手段１１１に格納された構成情報を参照して、情報システムＳ０１が使用するサーバ装置の識別子を調べ、「サーバ１」、「サーバ２」、「サーバ３」から、ハードウェアのモデル名を読み出す。

情報システム１０３の運用にあたっては、運用ポリシが適用される。運用ポリシとは、アプリケーションの動作を安定させ、サービスレベルを保証するための情報システム１０３への設定方法を記述した規則群である。運用ポリシは、アプリケーションとサービスレベルとに対応して定義される。情報システム１０３において、サービスレベルの保証が難しくなると予測されると、運用ポリシが発火し、情報システム１０３の構成を変更することで、サービスレベルの改善が図られる。

例えば、情報システムＳ０１において、サーバ装置あたりの同時アクセス数が増大し、コンピュータ資源とネットワーク資源の負荷が高くなった場合には、運用ポリシが発火し、その発火した運用ポリシに従って、予備資源として用意されているサーバ３を、現用サーバとして運用し、情報システムＳ０１の能力を増強する。予備資源は、サーバ装置とは限らず、スイッチ装置の予備ポートや予備帯域の場合もある。また、運用ポリシによって、電話への応答の優先度といったアプリケーション資源の設定を変更することで、サービスレベルの維持を図る場合もある。

運用ポリシ格納手段１１５は、情報システム１０３に適用する運用ポリシと、それに関連する情報とを格納する。運用ポリシ格納手段１１５に格納される運用ポリシの入力には、コンソール１１８が用いられる。図５は、運用ポリシ格納手段１１５に格納されている情報を示している。同図において、「ポリシ識別子」は、運用ポリシの識別子を示している。同図の例では、運用ポリシ格納手段１１５は、ポリシ識別子「Ｐ０１」及び「Ｐ０２」の２つの運用ポリシが格納されている。「発火実績」、「サービスレベル改善実績」、及び、「ステータス」については後述する。運用ポリシ変更手段１１６は、運用ポリシ格納手段１１５から運用ポリシを取得し、後述する改良動作により、運用ポリシの改良を行う。

図６及び図７は、それぞれ、図５における運用ポリシ記述の内容を例示している。運用ポリシは、ポリシ識別記述、構成情報記述、状態情報記述、及び、構成変更記述の４つの部分から構成されている。運用ポリシ記述の４つの構成部分のうち、構成情報記述と状態情報記述とは、ポリシ発火の条件内容（ＩＦ文）に対応し、構成変更記述は条件が成立した場合の実行内容（ＴＨＥＮ文）に対応する。運用ポリシは、構成情報記述、状態情報記述、及び、構成変更記述を、それぞれ複数有することができる。

ポリシ識別記述は、運用ポリシが適用される「アプリケーション」及び「サービスレベル」とを含む。構成情報記述は、運用ポリシが発火するための構成情報の条件を示している。状態情報記述は、運用ポリシが発火するための状態情報の条件を示している。構成情報記述及び状態情報記述では、ＳＮＭＰマネージャ１１９を通してＭＩＢから読み出せる情報を用いて、ポリシ発火条件が記述される。構成変更記述は、運用ポリシが発火したときの構成変更の内容を示している。構成変更記述には、ＳＮＭＰマネージャ１１９を通してＭＩＢへ書き込める構成情報について、構成情報の設定変更内容が記述される。

図８は、サービスレベル格納手段１１７に格納された情報を例示している。同図に示すように、サービスレベル格納手段１１７は、クライアントに提供するアプリケーションとサービスレベルの組に対して、運用ポリシ管理サーバ１０１内で目標とする情報システムの状態値を保持する。これら目標値は、コンソール１１８により入力できる。同図の例では、「サービスレベル」の値が小さいほど、サービス品質が高い。例えば、ＣＴＩアプリケーションでは、サービスレベル「１」は、サービスレベル「２」に比して、目標値となる応答時間が短く、提供されるサービスの品質が高い。

目標値は、ＳＮＭＰマネージャ１１９を通してアクセスするＭＩＢに含まれている資源の状態情報を用いて、算術演算や関数を使用して記述することができる。例えば、目標値がサーバ１台あたりのクライアント数で定義される場合には、（クライアント数÷サーバ台数）＝２０というように記述することができ、目標値が、複数のサーバのうちのＣＰＵ使用率が最大のものにより定義される場合には、ＭＡＸ（サーバ１のＣＰＵ使用率，サーバ２のＣＰＵ使用率，サーバ３のＣＰＵ使用率）＝７０％というように記述できる。

ここで、目標値は、運用ポリシ管理サーバ１０１内の管理の目的で設定された値であり、クライアントに提供されるサービスの品質そのものではない。例えば、クライアントに提供されるサービスの品質内容として、ＣＴＩアプリケーションのサービスレベル２では、応答時間５秒以内であるとする。この場合、運用ポリシ管理サーバ１０１内で目標とする状態値は、例えば応答時間４秒である。サービスレベル２では、応答時間を４秒とすることで、クライアントに提供されるサービスの品質内容を保証できると共に、アウトソースサービス事業者センタ内の資源の有効利用を図ることができる。

運用ポリシ実施手段１１３は、各情報システム１０３と、その情報システムに適用すべき運用ポリシとを対応付けて記憶し、各情報システム１０３において、運用ポリシの実施を行う。運用ポリシ実施手段１１３は、状態監視手段１１２によって情報システム１０３の状態を監視し、情報システム１０３において、構成情報記述及び状態情報記述により指定されるポリシ発火条件が満たされたか否かを判断する。運用ポリシ実施手段１１３は、ポリシ発火条件が満たされたと判断すると、運用ポリシを発火させ、ＳＮＭＰマネージャ１１９を介して、構成変更記述に従って、設定変更を実施する。

情報システム分類手段１１４は、構成格納手段１１１の「アプリケーション」と「サービスレベル」とに従って、情報システム１０３が類似するか否かを判定する。情報システム分類手段１１４は、複数の情報システム１０３間で、各情報システム１０３が含む資源のモデル名や、バージョン番号、台数などが相互に異なっている場合でも、その「アプリケーション」と「サービスレベル」が相互に同じであれば、それらを相互に類似する情報システムと判定する。例えば、図４では、情報システムＳ０１と情報システムＳ０２とは、共に、「アプリケーション」＝「ＣＴＩ」、「サービスレベル」＝「レベル２」であるため、情報システム分類手段１１４は、使用されているサーバの台数等が異なってはいても、それらを類似の情報システムと判定する。

運用ポリシ格納手段１１５は、コンソール１１８により、新たな運用ポリシが入力されると、その運用ポリシの「ステータス」を検証中とする。運用ポリシ格納手段１１５に新たに格納された運用ポリシは、検証動作により、その有効性が検証される。コンソール１１８から新たに入力される運用ポリシには、アプリケーション及びサービスレベルが指定されて入力されるものと、サービスレベルが指定されないで入力されるものとがある。サービスレベルが指定されているときには、そのサービスレベルで検証が行われ、有効又は無効が判断される。また、サービスレベルが指定されていないときには、サービスレベルが低いものから順に検証が行われ、運用ポリシを適用することができるサービスレベルが判定される。

アプリケーション及びサービスレベルが指定された運用ポリシの検証には、情報システム分類手段１１４によって、検証対象の運用ポリシが適用される情報システムに類似すると判定された情報システム１０３が用いられる。検証に用いられる情報システム１０３には、クライアント企業に既に割り当てられた情報システム、及び、まだクライアント企業に割り当てたれていない情報システムを用いることができる。未割り当ての情報システム１０３を検証に用いる場合には、疑似クライアント装置１０８を用いる。疑似クライアント装置１０８は、実際にクライアント企業に割り当てられた情報システムに対して発行される要求やジョブのパターンを格納しており、そのパターンに従って、未割り当ての情報システム１０３を運用状態とする。検証において、指定されたサービスレベルのサービス品質を提供可能であると判断されたときには、その運用ポリシは、有効であると判断される。一方、指定されたサービスレベルのサービス品質を提供可能でないと判断されたとき
には、その運用ポリシは無効と判断される。

サービスレベルが指定されていない運用ポリシが入力された場合には、運用ポリシ格納手段１１５は、その運用ポリシを格納する際に、サービスレベル格納手段１１７を参照し、運用ポリシが適用されるアプリケーションについて、最もサービスレベルが低いものを選択して、運用ポリシに、その選択したサービスレベルを設定する。例えば、アプリケーション「ＣＴＩアプリケーション」では、図８に示す情報を有するサービスレベル格納手段１１７を参照して、「サービスレベル２」をポリシ識別記述（図６参照）に付加する。

その後、運用ポリシ格納手段１１５によって設定されたサービスレベルにおいて、アプリケーション及びサービスレベルが指定された運用ポリシの検証と同様な動作により、運用ポリシの検証を行う。この検証において、運用ポリシが有効であると判断されると、運用ポリシ格納手段１１５は、運用ポリシのサービスレベルを、前回に運用ポリシに設定したサービスレベルよりも一段階高いサービスレベルに変更する。その後、変更されたサービスレベルにおいて検証を行う。このような検証を、変更されたサービスレベルでは運用ポリシが有効でないと判断されるまで、或いは、サービスレベルが最も高いサービスレベルとなるまで行う。これにより、運用ポリシが有効であると判断されるサービスレベルが判定される。検証により、最も低いサービスレベルで有効でないと判断されると、その運用ポリシは、無効と判断される。

運用ポリシの検証には、実績集計・評価手段１２０が用いられる。図９は、実績集計・評価手段１２０が記憶する運用ポリシの実績情報を示している。運用ポリシ実施手段１１３は、検証対象のポリシを発火させると、実績集計・評価手段１２０に格納された発火した運用ポリシの「発火実績」を１つ加算する。また、運用ポリシ実施手段１１３は、サービスレベル格納手段１１７を参照してポリシ記述に含まれるアプリケーション及びサービスレベルに対応する目標値と取得し、ポリシ発火後、その目標値の項目の状態情報について、ポリシ発火前の値と、設定変更実施後の値とを状態監視手段１１２より取得し、運用ポリシがサービスレベルの維持に有効であったか否かを判断し、有効であったと判断したときには、「サービスレベル改善実績」を１つ加算する。

例えば、検証中の運用ポリシがＣＴＩアプリケーションのサービスレベル２であれば、目標値は「平均応答時間＝４秒」である（図８参照）。この場合、運用ポリシ実施手段１１３は、状態監視手段１１２を介して、ポリシ発火前の情報システム１０３の平均応答時間と、ポリシ発火による設定変更実施後の情報システム１０３の平均応答時間とを取得する。ポリシ発火前の平均応答時間が５秒であり、設定変更実施後の平均応答時間が３．５秒であれば、情報システム１０３の平均応答時間は、目標値に近づいたと判断できる。この場合、運用ポリシ実施手段１１３は、発火した運用ポリシがサービスレベルの維持に有効であったと判断して、実績集計・評価手段１２０に格納されたその運用ポリシの「サービスレベル改善実績」を１つ加算する。

実績集計・評価手段１２０は、「発火実績」と「サービスレベル改善実績」とに基づいて、運用ポリシが指定されたサービスレベルに適用可能であるか否かを判断する。実績・集計・評価手段１２０は、例えば、発火実績が８０を超えると、サービスレベル改善実績÷発火実績を算出し、その値に基づいて、運用ポリシの有効性を判断する。例えば、サービスレベル改善実績÷発火実績が９５％を超えると、その運用ポリシは有効であると判断し、それ以外であれば無効であると判断する。この適用可能か否かの判断基準は、コンソール１１８により指定できる。実績集計・評価手段１２０は、運用ポリシが有効であると判断すると、運用ポリシ格納手段１１５の「ステータス」（図５）を有効に書き換え、検証において集計した「発火実績」及び「サービスレベル改善実績」を、運用ポリシ格納手段１１５の「発火実績」及び「サービスベル改善実績」にそれぞれ書き込む。また、運用ポリシが無効であると判断すると、運用ポリシ格納手段１１５の「ステータス」を無
効に書き換える。

「ステータス」が有効とされた運用ポリシは、その後、運用ポリシ実施手段１１３により、実際にクライアント企業に割り当てられた情報システム１０３において適用される。運用ポリシ実施手段１１３は、検証時と同様な動作により、情報システム１０３におけるポリシ発火実績及びサービスレベル改善実績の集計を継続して行う。「ステータス」が無効とされた運用ポリシは、その後、破棄される。運用ポリシの破棄は、運用ポリシごとに、検証終了後直ちに行ってもよく、或いは、所定時間間隔で「ステータス」が無効となっている運用ポリシをサーチし、まとめて行ってもよい。

以下、運用ポリシの検証について詳細に説明する。図１０は、アプリケーション及びサービスレベルが指定された運用ポリシの検証の動作手順をフローチャートで示している。アウトソース事業者のデータセンタの管理者は、コンソール１１８を用いて、新規に作成した運用ポリシを入力する（ステップＳ１００１）。管理者は、例えば、アプリケーション＝ＣＴＩ、サービスレベル＝レベル２に対して作成した新しい運用ポリシをコンソール１１８から入力する。ステップＳ１００１で入力された運用ポリシは、例えば図６に示す内容を有する。ステップＳ１００１では、管理者は、アプリケーションとサービスレベルの組に対して、複数の運用ポリシを入力することができる。運用ポリシ格納手段１１５は、ステップＳ１００１で入力された運用ポリシに、ポリシ識別子（Ｐ０１）を割り当て、発火実績＝０回、サービスレベル改善実績＝０回、ステータス＝検証中と初期化して、入力された新たな運用ポリシを登録する（ステップＳ１００２）。また、実績集計・評価手段１２０の「発火実績」及び「サービスレベル改善実績」をそれぞれ０に初期化する。

運用ポリシ格納手段１１５に新たな運用ポリシが格納されると、情報システム分類手段１１４は、複数の情報システム１０３の中から、アプリケーション及びサービスレベルが、運用ポリシが指定するアプリケーション及びサービスレベルと同じ情報システム１０３を類似の情報システムとして選定し、その類似の情報システム１０３を、運用ポリシの検証に用いる情報システムとして決定する（ステップＳ１００３）。ステップＳ１００３では、例えば情報システムＳ０１及びＳ０２が、アプリケーション＝ＣＴＩ、サービスレベル＝レベル２と類似すると判定され、運用ポリシＰ０１の検証に利用される情報システム１０３として決定される。構成格納手段１１１は、情報システム１０３の属性情報として、検証に利用する情報システム１０３のクライアント識別子に、運用ポリシ検証の目的に割り当てられたことを示す特別な識別子を記載する。その後、運用ポリシ実施手段１１３により、ステップＳ１００３で検証に用いると決定された情報システム１０３で運用ポリシを実施し、運用ポリシの発火実績とサービスレベル改善実績との集計を行う（ステップＳ１００４）。

ステップＳ１００４では、運用ポリシ実施手段１１３は、例えば所定時間間隔で、構成格納手段１１１及び状態監視手段１１２を参照し、検証で用いる情報システム１０３の状態を取得する。運用ポリシ実施手段１１３は、取得した状態と、運用ポリシ記述に記述された構成情報記述及び状態情報記述を比較し、運用ポリシに記述された条件内容（ＩＦ文）が成立するか否かを判断する。なお、運用ポリシの検証では、その運用ポリシが適用されるべき情報システムと類似する情報システム１０３が用いられるため、構成情報記述（図６、図７参照）に記述されたサーバのモデル名等が、検証に用いる情報システム１０３のサーバのモデル名等と一致しないこともある。運用ポリシ実施手段１１３は、検証中の運用ポリシに関しては、この部分の厳密な比較は行わないものとする。

運用ポリシ実施手段１１３は、条件内容が成立すると判断すると、運用ポリシを発火し、構成変更記述（ＴＨＥＮ文）に記載されている設定変更を、ＳＮＭＰマネージャ１１９を介して実行する。このとき、運用ポリシ実施手段１１３は、実績集計・評価手段１２０の「発火実績」を１つ加算する。ポリシの発火は、ステップＳ１００３で、複数の情報システム１０３が検証に利用する情報システムとして決定されているときには、複数の情報システム１０３の何れでも起こる可能性がある。

運用ポリシ実施手段１１３は、サービスレベル格納手段１１７から、運用ポリシのアプリケーション及びサービスレベルに対応する目標値を取得している。運用ポリシ実施手段１１３は、設定変更の実施後、状態監視手段１１２が監視している状態情報から、ポリシ発火により、目標値に近付いたか否かを判定する。運用ポリシ実施手段１１３は、目標値へ近付いたと判断したときには、実績集計・評価手段１２０の「サービスレベル改善実績」を１つ加算する。運用ポリシ実施手段１１３は、目標値から遠ざかったと判断した場合、或いは、変化がなかったと判断した場合には、「サービスレベル改善実績」を変更しない。

実績集計・評価手段１２０は、「発火実績」が所定の値を超えたか否かを判断する（ステップＳ１００５）。この所定の値は、アウトソースサービス事業者のデータセンタの管理者により、コンソール１１８を用いて入力される。所定の値としては、例えばポリシ発火実績８０回が採用される。所定の値を超えていないときには、ステップＳ１００４に戻り、発火実績及びサービスレベル改善実績の集計を継続する。実績集計・評価手段１２０は、ステップＳ１００５で、「発火実績」が所定の値を超えたと判断すると、発火実績とサービスレベル改善実績とが、所定の条件を満たすか否かを判定する（ステップＳ１００６）。この判定は、運用ポリシが複数あるときには、そのそれぞれについて行われる。所定の条件は、アウトソース事業者のデータセンタの管理者により、コンソール１１８を用いて入力される。所定の条件としては、例えば、「サービスレベル改善実績÷発火実績＞９５％」が採用される。

実績集計・評価手段１２０は、ステップＳ１００６で、所定の条件を満たすと判断したときには、検証中の運用ポリシは有効であると判定し、運用ポリシ格納手段１１５の「ステータス」を「有効」に書き換える（ステップＳ１００７）。また、実績集計・評価手段１２０によって、検証中に集計された「発火実績」及び「サービスレベル改善実績」を、運用ポリシ格納手段１１５にそれぞれ格納する。ステップＳ１００７で、所定の条件を満たさないと判断されたときには、検証中の運用ポリシは有効な運用ポリシではないと判定し、運用ポリシ格納手段１１５のステータスを「無効」に書き換える（ステップＳ１００８）。

図１１は、サービスレベルを指定されない運用ポリシの検証の動作手順をフローチャートで示している。アウトソース事業者のデータセンタの管理者は、コンソール１１８を用いて、新規に作成した運用ポリシを入力する（ステップＳ１１０１）。管理者は、例えば、アプリケーション＝ＣＴＩ、サービスレベル＝指定無し（記述無し）を記述した新しい運用ポリシをコンソール１１８から入力する。運用ポリシ格納手段１１５は、ステップＳ１１０１で入力された運用ポリシに、ポリシ識別子を割り当て、発火実績＝０回、サービスレベル改善実績＝０回、ステータス＝検証中と初期化して、運用ポリシを格納する（ステップＳ１１０２）。また、実績集計・評価手段１２０の「発火実績」及び「サービスレベル改善実績」をそれぞれ０に初期化する。

運用ポリシ格納手段１１５は、ステップＳ１１０２でサービスレベルを指定しない運用ポリシを格納する際に、サービスレベル格納手段１１７を参照し、運用ポリシが適用されるアプリケーションのサービスレベルのうちで、最も低いサービスレベルを運用ポリシに設定する（ステップＳ１１０３）。例えば、サービスレベル格納手段１１７が図８に示す情報を有するときには、ＣＴＩアプリケーションでは、サービスレベル２が最もサービスレベルが低い。この場合、図１２に示すポリ識別記述が入力された場合には、運用ポリシ格納手段１１５は、その運用ポリシを格納する際に、ポリシ識別記述に、最も低いサービスレベルであるサービスレベル＝２を付加する。

その後、ステップＳ１００３と同様な動作により検証に用いる情報システムを決定し（ステップＳ１１０４）、ステップＳ１００４と同様な動作により、運用ポリシを実施して、発火実績とサービスレベル改善実績の集計を行う（ステップＳ１１０５）。また、ステップＳ１００５と同様に、発火実績が所定の値を超えたか否かを判断し（ステップＳ１１０６）、ステップＳ１００６と同様に、発火実績及びサービスレベル改善実績が所定の条件を満たすか否かを判定する（ステップＳ１１０７）。

ステップＳ１１０７で、サービスレベル及びサービスレベル改善実績が所定の条件を満たすと判断されたときには、運用ポリシは、現在のサービスレベルにおいて有効であると判断されたことになる。この場合、運用ポリシ格納手段１１５は、サービスレベル格納手段１１７を参照し、ステップＳ１１０３で運用ポリシに設定したサービスレベルよりも一段階高いサービスレベルが存在するか否かを調べ（ステップＳ１１０８）、存在するときには、運用ポリシに、現在よりも一段階高いサービスレベルを設定する（ステップＳ１１０９）。例えば、ステップＳ１１０３でＣＴＩアプリケーションのサービスレベル２が設定されたときには、ステップＳ１１０８では、それよりも一段階高いサービスレベル１が設定され、ポリシ識別記述（図１２）のサービスレベルが「１」に書き換えられる。

運用ポリシ格納手段１１５によって１段階高いサービスレベルが設定されると、ステップＳ１１０４に戻って、運用ポリシを前回よりも１段階高いサービスレベルで検証する際に使用する情報システム１０３を決定し、ステップＳ１１０４〜Ｓ１１０７を実行することにより、１段階高いサービスレベルで運用ポリシの検証を行う。ステップＳ１１０７で、現在のサービスレベルにおいて所定の条件を満たさないと判断されたときには、その現在のサービスレベルでは、運用ポリシは有効ではない。この場合、運用ポリシが、現在よりも１段階下のサービスレベルで有効であると判断して（ステップＳ１１１０）、運用ポリシのサービスレベルを１段階下のサービスレベルに設定し直す。その後、ステップＳ１００８と同様な動作により、運用ポリシ格納手段１１５の「ステータス」を有効に書き換える。ただし、最も低いサービスレベルにおいて有効でないと判断されたときには、１段階下のサービスレベルが存在しないため、運用ポリシは無効であると判断し、ステップＳ１００９と同様な動作により、運用ポリシ格納手段１１５の「ステータス」を無効とする。

ステップＳ１１０７で所定の条件を満たすと判断された後に、ステップＳ１１０８で、１段階高いサービスレベルが存在しないと判断された場合には、それは、その運用ポリシが現在設定された最上位のサービスレベルにおいて、所定の条件を満たすと判断されたことを意味している。この場合には、最上位のサービスレベルにおける検証で有効であると判断して（ステップＳ１１１１）、ステップＳ１００８と同様な動作で、運用ポリシ格納手段１１５の「ステータス」を有効に書き換える。

上記検証の動作により、コンソール１１８により入力された運用ポリシが検証において有効であると判断されると、その有効と判断された運用ポリシを用いて、改良動作によって新たに運用ポリシを生成し、その改良後の運用ポリシの検証を行う。図１３は、改良により生成された運用ポリシの検証の動作手順をフローチャートで示している。コンソール１１８によって入力された運用ポリシの検証が終了し、その運用ポリシの「ステータス」が有効に書き換えられると、運用ポリシ変更手段１１６は、その有効となった運用ポリシを取得する（ステップＳ１３０１）。また、運用ポリシ格納手段１１５から、ステップＳ１３０１で取得した運用ポリシと同じアプリケーション及びサービスレベルの運用ポリシであって、「ステータス」が有効とされている別の運用ポリシを取得する（ステップＳ１３０２）。その後、ステップＳ１３０１で取得した運用ポリシと、ステップＳ１３０２で取得した運用ポリシとを用いて、改良動作により、新たに運用ポリシを生成する（ステップＳ１３０３）。

ステップＳ１３０３で行う運用ポリシの改良には、組換型の改良と結合型の改良とを用いる。組換型の改良は、遺伝的プログラミングの考え方を応用し、高いサービスレベル改善実績が得られる運用ポリシの作成を目的としたものである。組換型の改良によって、高いサービスレベル改善実績が得られる運用ポリシを作成しておき、これを結合型の改良で汎用化することで、誤動作の少ない高い品質の運用ポリシを作成することを狙いとしている。

図１４は、組換型の改良による運用ポリシの作成の様子を示している。まず、運用ポリシ格納手段１１５から、検証によって有効であると判断された運用ポリシと同じアプリケーション及びサービスレベルの任意の運用ポリシを１つ選び出す。例えば、運用ポリシ格納手段１１５から、「サービスレベル改善実績÷発火実績」が最も大きいものを選び出す。次いで、検証によって有効であると判断された運用ポリシの記述と、運用ポリシ格納手段１１５から選び出された運用ポリシの記述とを部分的に書き換えることで、新たな運用ポリシを作成する。図１４の例では、運用ポリシＰ０１の状態情報記述０１と、運用ポリシＰ０２の状態情報記述０２とを組み換えて、運用ポリシＰ０１とＰ０２とから、２つの新しい運用ポリシを作成する。

組換型の改良の基本パターンは、構成情報記述を組み換える場合、状態情報記述を組み換える場合、構成変更記述を組み換える場合の３通りである。３通りの運用ポリシの作成を同時に実施して、改良によって新たに作成する運用ポリシを２個から６個へ増やしてもよい。または、３通りから１通りだけをランダムに選択して作成してもよい。さらに、構成情報記述と状態情報記述を同時に組み換える場合、構成情報記述と構成変更記述を同時に組み換える場合、状態情報記述と構成変更記述を同時に組み換える場合の３通りがあるが、これらは、上記した基本パターンの作成の手順の繰り返しにより実現できる。

運用ポリシＰ０１とＰ０２とを用いて、組換型の改良により、新たな運用ポリシを生成する場合には、運用ポリシＰ０１と運用ポリシＰ０２とで、構成情報記述が一致しているため、構成情報記述を組み換えることはできない。また、運用ポリシＰ０１とＰ０２とから、構成変更記述を組み換えて２つの運用ポリシを作成すると、それは、図１４に示す状態情報記述を組み換えて作成した運用ポリシと等価になる。このような場合には、図１４に示した２個の運用ポリシが、検証の対象となる。

図１５は、結合型の改良による運用ポリシの作成の様子を示している。結合型の改良は、与えられたアプリケーションとサービスレベルの条件の下で、できるだけ多くの構成の情報システム１０３に適用できる汎用化された運用ポリシの作成を目的としたものである。まず、運用ポリシ格納手段１１５から、検証によって有効であると判断された運用ポリシと同じアプリケーション及びサービスレベルの任意の運用ポリシを１つ選び出す。例えば、運用ポリシ格納手段１１５から、「サービスレベル改善実績÷発火実績」が最も大きいものを選び出す。次いで、検証によって有効であると判断された運用ポリシと、運用ポリシ格納手段１１５から選び出された運用ポリシとの共通部分をまとめ、１つの運用ポリシを作成する。結合型の改良により、運用ポリシＰ０１と運用ポリシＰ０２とから運用ポリシを作成する場合、運用ポリシＰ０１と運用ポリシＰ０１とでは、ポリシ識別記述と構成情報記述０１とが共通の記述であるため、これをまとめて、状態情報記述から先が枝分かれした１つの運用ポリシを作成する。

図６及び図７を参照すると、状態情報記述０１＝「サーバあたりの同時アクセス数＞２０」、構成変更記述０１＝「電話への応答の優先度＝高に設定変更」、状態情報記述０２＝「サーバあたりの同時アクセス数＞３０」、構成変更記述０２＝「予備のサーバ３を現用に設定変更」である。この場合、運用ポリシ実施手段１１３は、改良後の運用ポリシの実施に当たっては、改良後の運用ポリシの枝分かれの部分を「ＩＦ３０＞（サーバあたりの同時アクセス数＞２０）ＴＨＥＮ（電話への応答の優先度＝高に設定変更）ＥＬＳＥ ＩＦ（サーバあたりの同時アクセス数＞３０）ＴＨＥＮ（予備のサーバ３を現用に設定変更）」と解釈する。

ところで、結合型の改良により作成された運用ポリシでは、枝分かれする２つの状態情報記述の条件が排他的でなく、改良後の運用ポリシの枝分かれの部分が同時に成立する場合もある。その場合には、枝分かれの部分が排他的となるよう、片方を修正した運用ポリシを２通り作成する。例えば、図１６（ａ）に示すように、運用ポリシＰ０１の状態情報記述０１が「サーバあたりの同時アクセス数＜３０」、構成変更記述０１が「電話への応答の優先度＝高に設定変更」であり、同図（ｂ）に示すように、運用ポリシＰ０２の状態情報記述０２が「サーバあたりの同時アクセス数＞２５」、構成変更記述０２が「予備のサーバ３を現用に設定変更」である場合には、枝分かれ部分が排他的となるように、２通りの運用ポリシを作成する。その場合、運用ポリシ実施手段１１３は、運用ポリシの一方を、「ＩＦ（サーバあたりの同時アクセス数＜３０）ＴＨＥＮ（電話への応答の優先度＝高に設定変更）ＥＬＳＥ ＩＦ（サーバあたりの同時アクセス数＞３０）ＴＨＥＮ（予備のサーバ３を現用に設定変更）」（同図（ｃ））と解釈する。また、他方を、「ＩＦ（サーバあたりの同時アクセス数＜２５）ＴＨＥＮ（電話への応答の優先度＝高に設定変更）ＥＬＳＥ ＩＦ（サーバあたりの同時アクセス数＞２５）ＴＨＥＮ（予備のサーバ３を現用に設定変更）」（同図（ｄ））と解釈する。

図１３に戻り、組換型又は結合型の改良により、運用ポリシが生成されると、図１０のステップＳ１００２と同様に、ステップＳ１３０３で作成した運用ポリシを運用ポリシ格納手段１１５に登録する（ステップＳ１３０４）。その後、ステップＳ１００３と同様にして、情報システム分類手段１１４を用いて、ステップＳ１３０３で作成された運用ポリシの検証に利用する情報システムを決定し（ステップＳ１３０５）、ステップＳ１００４と同様に、運用ポリシ実施手段１１３により、ポリシ発火回数とサービスレベル改善実績の集計を行う（ステップＳ１３０６）。

実績集計・評価手段１２０は、ステップＳ１００６と同様に、運用ポリシの発火実績が所定の値を超えたか否かを判断し（ステップＳ１３０７）、超えたときには、集計した発火実績とサービスレベル改善実績とが、所定の条件を満たすか否かを判定する（ステップＳ１３０８）。ステップＳ１３０８で、所定の条件を満たすと判定されたときには、運用ポリシ格納手段１１５に格納された改良前の運用ポリシの「発火実績」及び「サービスレベル」と、実績集計・評価手段１２０の「発火実績」及び「サービスレベル改善実績」とに基づいて、改良の前後での（サービスレベル改善実績÷発火実績）の値を相互に比較する（ステップＳ１３０９）。そして、改良後の値が、改良前の値よりも大きいか否かを判断する（ステップＳ１３１０）。

比較の結果、改良後の（サービスレベル改善実績÷発火実績）が、改良前の（サービスレベル改善実績÷発火実績）よりも値が大きいときには、改良後の運用ポリシが、改良前の運用ポリシに比して、より、サービスレベルの維持に有効である。この場合、改良前の運用ポリシの「ステータス」を無効とし、改良後の運用ポリシの「ステータス」を有効とする（ステップＳ１３１１）。これとは逆に、ステップＳ１３１０で、改良後の（サービスレベル改善実績÷発火実績）が、改良前の（サービスレベル改善実績÷発火実績）よりも値が小さいと判断されたときには、改良前の運用ポリシが、改良後の運用ポリシに比して、サービスレベルの維持に有効であると判断し、改良後の運用ポリシの「ステータス」を無効とする（ステップＳ１３１２）。

本実施形態では、運用ポリシの検証を、情報システム分類手段１１４によって類似の情報システムとして判定された情報システム１０３を用いて行っている。これにより、より多くの情報システム１０３を用いて、運用ポリシの妥当性を検証し、或いは、汎用化改良を行うことができ、運用ポリシを実際の運用に用いるまでのテスト時間を短縮化できる。このようにして、サービスレベルを保証した情報システム１０３を提供するまでのテストから運用開始までの時間を短縮することで、アウトソースサービス事業者は、クライアント企業とサービス契約後、短期間で、サービス契約したサービスレベルの情報システム１０３を提供することができる。

本実施形態では、サービスレベルが指定されない運用ポリシについては、サービスレベルが低いものから順次に検証を行い、運用ポリシが適用可能なサービスレベルを判断する。このようにすることで、適切なサービスレベルを自動的に発見でき、サービスレベルポリシ生成作業の作業負担を軽減することができる。また、本実施形態では、運用ポリシの改良動作によって、検証済みの運用ポリシの改良を行い、改良によって生成された運用ポリシが、改良前の運用ポリシに比して、よりサービスレベルの維持に有効であると判断されたときには、その改良後の運用ポリシを、実際にクライアント企業に割り当てられた情報システムに適用する運用ポリシとする。このように、本実施形態では、高いサービスレベル改善実績を実現でき、また、より多くの情報システム１０３に対応した汎用性が高い運用ポリシを生成することができる。

図１７は、本発明の第２実施形態の情報システム提供システムの構成を示している。本実施形態の情報システム提供システムは、図３に示す構成に、資源プール１０５、資源プール制御手段１０６、スイッチ１０７とが追加されている点で、第１実施形態と相違する。本実施形態では、既にある情報システム１０３に加えて、又は、これに代えて、検証用に作成した情報システム１０３を用いて、運用ポリシの検証を行う。

資源プール１０５は、コンピュータ資源、ネッワワーク資源、アプリケーション資源、及び、データ資源を含んでいる。資源プール１０５の内部では、これら資源がそれぞれ単体で配置されている。この状態では、与えられたアプリケーションとサービスレベルとを満たす情報システム１０３として運用することはできない。資源プール１０５内では、多数のサーバ、ロードバランサ装置、ファイアウォール装置、アプリケーションやデータを格納するハードディスク装置などがスイッチ１０７につながった状態になっている。

資源プール１０５内の各資源は、スイッチ１０７を切り替えることにより、情報システム１０３と接続される。スイッチ１０７により、情報システム１０３と資源プール１０５内の資源とを接続すると、その資源は、情報システム１０３の一部として利用できる。また、資源プール１０５内で資源をいくつか接続すれば、これらを新規の情報システム１０３とみなすことができる。資源プール制御手段１０６は、資源プール１０５内の資源の操作を行う。資源プール制御手段１０６は、スイッチ１０７を制御して、各資源の接続状況を制御する。これにとり、情報システム１０３の構成を変更し、或いは、新たな情報システム１０３を作成することができる。

資源プール制御手段１０６が動作する例としては、クライアント企業との新たな契約に対応して、資源プール１０５内の資源を用いて、新たな情報システム１０３を作成する場合がある。クライアント企業は、サービスの提供を受けるにあたり、ゲートウェイ装置１０４とサービス契約ＩＦ手段１０２とを通して、アウトソースサービス契約する情報システムのアプリケーションとサービスレベルとを指定する。この場合、サービス契約ＩＦ手段１０２から構成格納手段１１１を経由し、資源プール制御手段１０６を通して、情報システム１０３が構築される。

資源プール制御手段１０６は、クライアント企業から指定されたアプリケーションとサービスレベルとに基づいて、必要な資源の種類と数量を決定する。例えば、ＣＴＩアプリケーションでのサービスレベルのレベル２ではサーバ台数２台、サービスレベルのレベル１ではサーバ台数４台と決定する。台数決定に使用する情報は、あらかじめ資源プール制御手段１０６内に、アプリケーション及びサービスレベルと対応付けて記憶されている。

資源プール制御手段１０６は、スイッチ１０７を操作し、資源プール１０５内の資源を接続する。資源プール制御手段１０６は、例えば、１台のロードバランサ装置を１台のファイアウォール装置に接続し、４台のサーバを１台のロードバランサ装置に接続し、ハードディスク装置をそれぞれのサーバに接続する。その後、資源プール制御手段１０６は、サーバ上でアプリケーションを起動し、運用可能な状態にする。このような操作を実行することにより、資源プール１０５から新規の情報システム１０３が作成される。

資源プール制御手段１０６によって作成された情報システム１０３は、サービス契約ＩＦ手段１０２から情報システム提供者サーバ１００を通して、クライアント企業に割り当てられる。情報システム提供者サーバ１００は、クライアント企業に、割り当てた情報システム１０３にアクセスするためのアカウントを与え、インターネットやＶＰＮからアクセスできるように、情報システム１０３へのアクセスを開放する。

資源プール制御手段１０６は、サービス契約ＩＦ手段１０２によって、クライアント企業との契約が解除されると、そのクライアントに提供していた情報システム１０３を解体して、情報システム１０３を構成していた資源を、資源プール１０５に戻す。情報システムの解体では、資源プール制御手段１０６は、情報システム１０３で起動していたアプリケーションを停止し、スイッチ１０７を操作して、資源の間の接続を解放する。これにより、資源は、資源プール１０５に戻され、サーバ、ロードバランサ装置、ファイアウォール装置、アプリケーションやデータを格納するハードディスク装置などがスイッチにつながった状態に戻される。

図１８は、本実施形態における新規に作成された運用ポリシの検証の手順を示している。アウトソース事業者のデータセンタの管理者は、図１０のステップＳ１００１と同様に、コンソール１１８を用いて、アプリケーション及びサービスレベルが指定された運用ポリシを入力する（ステップＳ１８０１）。運用ポリシ格納手段１１５は、ステップＳ１００２と同様に、ステップＳ１８０１で入力された運用ポリシを登録する（ステップＳ１８０２）。

ポリシ分類手段１１４は、ステップＳ１００３と同様な動作により、運用ポリシの検証に用いる情報システム１０３を決定する（ステップＳ１８０３）。このとき、ポリシ分類手段１１４により、運用ポリシを適用すべき情報システムに類似する情報システムが既存の情報システム１０３に存在しないと判断されたとき、或いは、存在はするがその数があらかじめ定めておいた所定の数よりも少ないとき、資源プール制御手段１０６は、資源プール１０５内の資源に対する操作を行い、ステップＳ１８０１で入力された運用ポリシに対応するアプリケーションとサービスレベルを提供する情報システム１０３を作成する（ステップＳ１８０４）。

例えば、運用ポリシのポリシ識別記述（図６）が「アプリケーション＝ＣＴＩ、サービスレベル＝レベル２」であるときには、資源プール制御手段１０６は、ステップＳ１８０４で、資源プール１０５内の複数のサーバを相互に接続し、そのサーバ上でＣＴＩアプリケーションを駆動して、ＣＴＩアプリケーションをサービスレベル２に対応した情報システム１０３を作成する。その後、運用ポリシ実施手段１１３によって、ステップＳ１８０３で検証に用いると決定された情報システム及びステップＳ１８０４で作成された情報システム１０３で、ステップＳ１８０１で入力された運用ポリシを実施し、発火実績とサービスレベル改善実績との集計を行う（ステップＳ１８０５）。

実績集計・評価手段１２０は、図１０のステップＳ１００５と同様に、発火実績が所定の値を超えたか否かを判断する（ステップＳ１８０６）。発火実績が所定の値を超えたときには、ステップＳ１００６と同様に、集計した発火実績とサービスレベル改善実績とが、所定の条件を満たすか否かを判定する（ステップＳ１８０７）。ステップＳ１８０７で、所定の条件を満たすと判定されたときには、有効な運用ポリシと判定し、運用ポリシの「ステータス」を有効に書き換える（ステップＳ１８０８）。ステップＳ１８０７で、所定の条件を満たさないと判断されたときには、有効な運用ポリシではないと判定し、運用ポリシの「ステータス」を無効に書き換える（ステップＳ１８０９）。運用ポリシの検証の終了後、資源プール制御手段１０６は、ステップＳ１８０４で作成した情報システム１０３を速やかに解体し、情報システム１０３を構成していた資源を資源プール１０５に戻して、他の用途に使用できるようにする（ステップＳ１８１０）。

本実施形態では、資源プール制御手段１０６により作成された情報システム１０３を利用して、運用ポリシの妥当性の検証を行う。このため、既存の情報システム１０３に、類似の情報システム１０３が存在しない場合でも、運用ポリシの検証を行うことができる。また、類似の情報システムが既に存在する場合には、その情報システム１０３に加えて、ステップＳ１８０４で作成された情報システム１０３を利用して、運用ポリシの検証を行うこともでき、その場合には、より多くの情報システム１０３を用いて、運用ポリシの検証を行うことができる。

なお、図１０、図１１、図１３を用いて説明した運用ポリシの検証は、同時に並行的に実行することもできる。また、例えばある運用ポリシの検証中に、他の運用ポリシの検証を開始することもできる。第２実施形態では、資源プール制御手段１０６により作成された情報システム１０３を用いて、アプリケーション及びサービスレベルが指定された運用ポリシの検証を行う例について示したが、検証対象の運用ポリシは、これには限定されない。第１実施形態で説明した、サービスレベルが指定されない運用ポリシ、又は、改良により生成された運用ポリシについても、同様に行うことができる。図１１では、サービスレベルが指定されない運用ポリシを、サービスレベルを最も低いサービスレベルから順次引き上げながら検証する例について示したが、サービスレベルが指定された運用ポリシについても、その指定されたサービスレベルを初期値として、図１１に示す手順により、サービスレベルを順次に引き上げて検証を行うことができる。この場合、指定されたサービ
スレベルよりも上位のサービスレベルに適用可能か否かを検証できる。

また、運用ポリシの検証では、運用ポリシの発火実績が所定の値を超えないと検証が終了しないため、例えば、ポリシ発火条件が適切でなく、ポリシが発火しないような場合には、検証が終了しないことも考えられる。このような場合には、例えば検証時間を１時間と定め、検証開始から１時間を経過しても発火実績が所定の値を超えない場合には、その運用ポリシは無効であると判断すればよい。また、運用ポリシの検証では、クライアント企業に割り当てられていない情報システム１０３に対して、疑似クライアント装置１０８により、要求やジョブを発行して検証を行ったが、この検証には、クライアント企業に既に割り当てられている情報システム１０３を用いることもできる。この場合、より実際の動作環境に近い状態で検証を行うことができる。

上記実施形態では、運用ポリシ管理サーバ１０１が、ＳＮＭＰを用いて各資源の状態等を取得する例について示したが、これには限定れず、その他の手法を用いて取得してもよい。また、各資源が、ＭＩＢにより状態情報や構成情報を管理する例について示したが、これには限定されない。例えばＳＭＮＰ以外のプロトコルを用いる場合には、ＬＤＡＰ（Lightweight Directory Access Protocol）等で管理してもよい。

以上、本発明をその好適な実施形態に基づいて説明したが、本発明の情報システム管理装置、方法、及び、プログラムは、上記実施形態例にのみ限定されるものではなく、上記実施形態の構成から種々の修正及び変更を施したものも、本発明の範囲に含まれる。

本発明の第１実施形態の情報システム提供者サーバを含む情報システム提供システムの構成を示すブロック図。 情報システムの構成を示すブロック図。 運用ポリシ管理サーバ手段の構成を示すブロック図。 構成格納手段に格納される情報システムの属性情報を示すテーブル。 ポリシ格納手段運用に格納されている情報を示すテーブル。 運用ポリシ記述の内容を示すブロック図。 運用ポリシ記述の内容を示すブロック図。 サービスレベル格納手段に格納された情報を示すテーブル。 実績集計・評価手段が記憶する発火実績及びサービスレベル改善実績の状況を示すテーブル。 新規に作成された運用ポリシの検証の動作手順を示すフローチャート。 サービスレベルが指定されずに入力された運用ポリシの検証の動作手順を示すフローチャート。 運用ポリシのポリ識別記述の具体例を示す図。 改良により生成された運用ポリシの検証の動作手順を示すフローチャート。 組換型の改良による運用ポリシの作成の様子を示すブロック図。 組換型の改良による運用ポリシの作成の様子を示すブロック図。 （ａ）及び（ｂ）は、それぞれ運用ポリシの状態情報記述及び構成変更記述の内容を模式的に示す模式図、同図（ｃ）及び（ｄ）は、それぞれ改良後の運用ポリシの状態情報記述及び構成変更記述の解釈の様子を示す模式図。 本発明の第２実施形態の情報システム提供システムの構成を示すブロック図。 本実施形態における新規に作成された運用ポリシの検証の手順を示すフローチャート。 特許文献１に記載されたシステム管理支援装置の構成を示すブロック図。 ジョブ実行サーバ手段の記憶部の記憶状態を示すブロック図。

Claims (27)

1. 提供すべき業務と提供するサービスの保証レベルを指定するサービスレベルとが規定された複数の情報システムを管理する情報システム管理装置において、
   業務名と、サービスレベルと、情報システム内の資源に対して実行する操作と、操作を実行するための条件とを記述した運用ポリシを登録する運用ポリシ格納手段と、
   前記情報システムのそれぞれの業務名及びサービスレベルを含む構成情報を記憶する構成格納手段と、
   前記構成格納手段に記憶された構成情報を参照して、前記運用ポリシの業務名及びサービスレベルと業務名及びサービスレベルがそれぞれ一致する１つ以上の情報システムを抽出する情報システム抽出手段と、
   前記抽出された情報システムに前記運用ポリシを適用し、該適用して得られた実績データを記憶する運用ポリシ実施手段と、
   前記記憶された実績データに基づいて、前記適用された運用ポリシの有効性を検証する検証手段とを備え、
   前記運用ポリシ実施手段は、複数回にわたる前記操作の実行のうちの各回の前記操作の実行前後における前記情報システムの状態変化をモニタし、前記条件が満たされた回数と、前記実行された操作でサービスが改善された回数とを前記実績データとして記憶することを特徴とする情報システム管理装置。
2. 前記運用ポリシ実施手段は、前記抽出された情報システムにおいて運用ポリシに記述された操作を実行する条件が満たされると、当該運用ポリシに記述された操作を実行する、請求項１に記載の情報システム管理装置。
3. 前記検証手段は、前記条件が満たされた回数と、前記実行された操作でサービスが改善された回数との関係が所定の条件を満たす運用ポリシを有効な運用ポリシと判定する、請求項１に記載の情報システム管理装置。
4. 前記運用ポリシ格納手段は、提供すべき業務が指定され、サービスレベルが指定されない運用ポリシが入力されると、前記提供すべき業務と同じ業務について定義されたサービスレベルの内で最も低いサービスレベルを指定した運用ポリシを記憶し、前記検証手段によって当該運用ポリシが有効と判断されると段階的にサービスレベルを引き上げた運用ポリシに変更する、請求項１に記載の情報システム管理装置。
5. 前記運用ポリシ格納手段から、前記検証手段によって有効と判定された、業務名とサービスレベルが相互に一致する複数の運用ポリシを読み出し、該複数の運用ポリシから１つ以上の新たな運用ポリシを作成するポリシ作成手段を更に備える、請求項１に記載の情報システム管理装置。
6. 前記検証手段によって有効と判定された運用ポリシと、当該運用ポリシと業務名及びサービスレベルが一致し、かつ、有効なポリシとして既に運用ポリシ格納手段に登録された運用ポリシとに基づいて、新たな運用ポリシを作成するポリシ作成手段を更に備える、請求項１に記載のシステム管理装置。
7. 前記検証手段は、前記検証手段によって有効と判定された運用ポリシの実績データと、前記ポリシ作成手段によって新たに作成された運用ポリシの実績データとを比較し、該比較結果に基づいて前記新たに作成された運用ポリシを有効又は無効と判定する、請求項６に記載のシステム管理装置。
8. 前記ポリシ作成手段は、複数の運用ポリシ間で、前記操作及び条件の少なくとも一方を入れ替えて、新たな運用ポリシを作成する、請求項５〜７の何れか一に記載の情報システム管理装置。
9. 前記ポリシ作成手段は、複数の運用ポリシの操作及び条件のうちで共通な部分をまとめて、新たな運用ポリシを作成する、請求項５〜７の何れか一に記載の情報システム管理装置。
10. サーバを用い、提供すべき業務と提供するサービスの保証レベルを指定するサービスレベルとが規定された複数の情報システムを管理する情報システム管理方法において、
    前記サーバが、業務名と、サービスレベルと、情報システム内の資源に対して実行する操作と、操作を実行するための条件とを記述した運用ポリシを運用ポリシ格納手段に登録するステップと、
    前記サーバが、前記情報システムのそれぞれの業務名及びサービスレベルを含む構成情報を構成格納手段に記憶するステップと、
    前記サーバが、前記構成格納手段に記憶された構成情報を参照して、前記運用ポリシの業務名及びサービスレベルと業務名及びサービスレベルがそれぞれ一致する１つ以上の情報システムを抽出するステップと、
    前記サーバが、前記抽出された情報システムに前記運用ポリシを適用し、該適用して得られた実績データを記憶するステップと、
    前記サーバが、前記記憶された実績データに基づいて、前記適用された運用ポリシの有効性を検証するステップとを備え、
    前記実績データは、複数回にわたる前記操作の実行のうちの各回の前記操作の実行前後における前記情報システムの状態変化をモニタし、前記条件が満たされた回数と、前記実行された操作でサービスが改善された回数とを含むことを特徴とする情報システム管理方法。
11. 前記抽出された情報システムで、運用ポリシに記述された操作を実行する条件が満たされると、前記サーバが、当該運用ポリシに記述された操作を実行する、請求項１０に記載の情報システム管理方法。
12. 前記検証ステップでは、前記条件が満たされた回数と、前記実行された操作でサービスが改善された回数との関係が所定の条件を満たす運用ポリシを有効な運用ポリシと判定する、請求項１０に記載の情報システム管理方法。
13. 提供すべき業務が指定され、サービスレベルが指定されない運用ポリシが入力されると、前記サーバが、前記提供すべき業務と同じ業務について定義されたサービスレベルの内で最も低いサービスレベルを指定した運用ポリシを記憶し、該運用ポリシの検証結果が有効な場合には段階的にサービスレベルを引き上げた運用ポリシに変更するステップを更に備える、請求項１０に記載の情報システム管理方法。
14. 前記サーバが、前記検証ステップで有効と判定された、業務名とサービスレベルが相互に一致する複数の運用ポリシを運用ポリシ格納手段から読み出し、該読み出した複数の運用ポリシから１つ以上の新たな運用ポリシを作成するステップを更に備える、請求項１０に記載の情報システム管理方法。
15. 前記サーバが、前記検証ステップで有効と判定された運用ポリシと、当該運用ポリシと業務名及びサービスレベルが一致し、かつ、有効なポリシとして既に運用ポリシ格納手段に登録された運用ポリシとに基づいて、新たな運用ポリシを作成するステップを更に備える、請求項１０に記載の情報システム管理方法。
16. 前記サーバが、前記検証ステップで有効と判定された運用ポリシの実績データと、前記ポリシ作成ステップで新たに作成された運用ポリシの実績データとを比較し、該比較結果に基づいて前記新たに作成された運用ポリシを有効又は無効を判定するステップを更に備える、請求項１５に記載の情報システム管理方法。
17. 前記ポリシ作成ステップでは、複数の運用ポリシ間で、前記操作及び条件の少なくとも一方を入れ替えて、新たな運用ポリシを作成する、請求項１４〜１６の何れか一に記載の情報システム管理方法。
18. 前記ポリシ作成ステップでは、複数の運用ポリシの操作及び条件のうちで共通な部分をまとめて、新たな運用ポリシを作成する、請求項１４〜１６の何れか一に記載の情報システム管理方法。
19. 提供すべき業務と提供するサービスの保証レベルを指定するサービスレベルとが規定された複数の情報システムを管理する情報システム管理装置のためのプログラムであって、前記情報システム管理装置に、
    業務名と、サービスレベルと、情報システム内の資源に対して実行する操作と、操作を実行するための条件とを記述した運用ポリシを運用ポリシ格納手段に登録する処理と、
    前記情報システムのそれぞれの業務名及びサービスレベルを含む構成情報を構成格納手段に記憶する処理と、
    前記構成格納手段に記憶された構成情報を参照して、前記運用ポリシの業務名及びサービスレベルと業務名及びサービスレベルがそれぞれ一致する１つ以上の情報システムを抽出する処理と、
    前記抽出された情報システムに前記運用ポリシを適用し、該適用して得られた実績データを記憶装置に記憶する処理と、
    前記記憶された実績データに基づいて、前記適用された運用ポリシの有効性を検証する処理とを実行させ、
    前記実績データは、複数回にわたる前記操作の実行のうちの各回の前記操作の実行前後における前記情報システムの状態変化をモニタし、前記条件が満たされた回数と、前記実行された操作でサービスが改善された回数とを含むことを特徴とするプログラム。
20. 前記抽出された情報システムで、運用ポリシに記述された操作を実行する条件が満たされると、前記情報システム管理装置に当該運用ポリシに記述された操作を実行させる、請求項１９に記載のプログラム。
21. 前記検証処理では、前記条件が満たされた回数と、前記実行された操作でサービスが改善された回数との関係が所定の条件を満たす運用ポリシを有効な運用ポリシと判定する、請求項１９に記載のプログラム。
22. 前記情報システム管理装置に、提供すべき業務が指定され、サービスレベルが指定されない運用ポリシが入力されると、前記提供すべき業務と同じ業務について定義されたサービスレベルの内で最も低いサービスレベルを指定した運用ポリシを記憶し、該運用ポリシの検証結果が有効な場合には段階的にサービスレベルを引き上げた運用ポリシに変更する処理を更に実行させる、請求項１９に記載のプログラム。
23. 前記情報システム管理装置に、前記検証処理で有効と判定された、業務名とサービスレベルが相互に一致する複数の運用ポリシを前記運用ポリシ格納手段から読み出し、該読み出した複数の運用ポリシから１つ以上の新たな運用ポリシを作成する処理を更に実行させる、請求項１９に記載のプログラム。
24. 前記情報システム管理装置に、前記検証処理で有効と判定された運用ポリシと、当該運用ポリシと業務名及びサービスレベルが一致し、かつ、有効なポリシとして既に前記運用ポリシ格納手段に登録された運用ポリシとに基づいて、新たな運用ポリシを作成する処理を更に実行させる、請求項１９に記載のプログラム。
25. 前記情報システム管理装置に、前記検証処理で有効と判定された運用ポリシの実績データと、前記ポリシ作成処理で新たに作成された運用ポリシの実績データとを比較し、該比較結果に基づいて前記新たに作成された運用ポリシを有効又は無効を判定する処理を実行させる、請求項２４に記載のプログラム。
26. 前記ポリシ作成処理では、複数の運用ポリシ間で、前記操作及び条件の少なくとも一方を入れ替えて、新たな運用ポリシを作成する、請求項２３〜２５の何れか一に記載のプログラム。
27. 前記ポリシ作成処理では、複数の運用ポリシの操作及び条件のうちで共通な部分をまとめて、新たな運用ポリシを作成する、請求項２３〜２５の何れか一に記載のプログラム。

Images