JP5605476B2 - システム運用管理装置、システム運用管理方法、及びプログラム記憶媒体 - Google Patents

Description

本発明は、システム運用管理装置、システム運用管理方法、及びプログラム記憶媒体に関し、特に管理対象のシステムの稼働状況を判定するシステム運用管理装置、システム運用管理方法、及びプログラム記憶媒体に関する。

顧客を対象とするサービスの提供において、近年、インターネットを利用した通信販売のように、コンピュータによるシステム及び情報通信技術を利用したサービスが数多く存在する。このようなサービスを円滑に実行するには、コンピュータによるシステムが常に安定に稼動することが求められる。そのためには、当該コンピュータのシステムについての運用管理が不可欠である。

しかし、このようなシステムの運用管理は、システム管理者により手作業で行われていた。そのため、システムが大規模化・複雑化するに伴い、システム管理者に求められる知識や経験が高度化すると共に、そのような知識や経験が少ないシステム管理者等による誤操作が、生ずることがあるという問題があった。

このような問題点を回避するため、システムを構成するハードウェアの状態を一元的に監視し、制御するシステム運用管理装置が提供されている。このシステム運用管理装置は、管理対象となるシステムのハードウェアの稼働状態を表すデータ（以下、性能情報）をオンラインで取得し、その性能情報を分析した結果から管理の対象となるシステム上の障害の有無を判定すると共に、その内容をシステム運用管理装置を構成する一要素である表示部（例えば、モニタ）に表示する。ここで、上述した障害の有無を判定する手法の例としては、予め性能情報に閾値を設定して判定する手法や、性能情報の実測値と予め算出した性能情報の計算値（理論値）とのずれに基準範囲を設けて判定する手法がある。

このシステム運用管理装置では、上述したように、モニタ等の表示部にシステム上の障害の有無に関する情報が表示される。そのため、もし障害がある旨が表示されたときは、その表示内容から障害の原因はメモリ容量の不足によるものであるか或いはＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）の過負荷によるものであるかというように、障害の改善のために、障害の原因を絞り込む必要がある。しかし、このような障害の原因の絞込み作業は、障害の発生に関与していそうな部分のシステム履歴やパラメータの調査を必要とすることから、その作業を担当するシステム管理者の経験と勘に頼る必要がある。よって、システム運用管理装置を操作するシステム管理者には、必然的に高いスキルが求められることとなる。同時に、システム運用管理システムを操作してのシステム障害の解決は、多くの時間的及び身体的負担をシステム管理者に強いる。

よって、このシステム運用管理装置では、管理対象のシステムから収集した処理能力にかかる情報に基づいて、異常状態の組合せ等の分析を自動的に行い、大まかな問題点や障害原因を推定してシステム管理者に通知した上で、対処指令を受付けることが重要である。

このように、システムの管理や障害の修繕にかかるシステム管理者の負担を軽減する機能を備えたシステム運用管理装置については、様々な関連技術が存在する。以下、それら関連技術を紹介する。

特開２００４−０６２７４１号公報に開示された技術は、システムの障害情報を表示する障害情報表示装置に関する技術である。その技術は、管理対象となるデータ処理システムの稼働状況を管理において、何らかの障害が発見された場合、当該障害の発生順や障害ユニットの実際の配置関係に応じた障害メッセージを外部に提示することにより、障害箇所を視覚的に認識し易くし、且つ障害発生元の推測作業を容易化し、システム管理者の負担を軽減する。

特開２００５−２５７４１６号公報に開示された技術は、測定対象装置から取得したパラメータの時系列情報に基づき、当該被測定対象装置を診断する装置に関する技術である。その技術は、パラメータの時系列情報の変化度に基づいて、各パラメータの情報間の相関関係の強さを算出することにより、測定対象装置の性能劣化による障害を適切に検出する。本技術によれば、異なるパラメータの情報の時系列変化が類似するか否かを適切に判断できる。

特開２００６−０２４０１７号公報に開示された技術は、コンピュータ資源の容量を予測するためのシステムに関する技術である。その技術は、システム要素の処理の履歴と性能情報の変化の履歴とを比較することにより、特定の処理に起因する負荷の量を特定すると共に、将来の処理量での負荷を分析する。本技術によれば、予め処理と負荷との関係が把握できている場合に、システムの挙動を特定できる。

特開２００６−１４６６６８号公報に開示された技術は、運用管理支援装置に関する技術である。その技術は、管理対象システムからＣＰＵ等のハードウェア稼働状況の情報やＷｅｂ管理サーバへのアクセス量の情報を一定の時間間隔で取得し、その情報を構成する複数の要素の相関関係を求め、その相関関係から現在のシステムの状態が正常か否かを判定する。本技術よれば、システムの性能の劣化の状況をより柔軟に検知できると共に、劣化の原因や対策を詳細に提示することが可能となる。

特開２００７−２９３３９３号公報に開示された技術は、過去の類似障害を探索する障害監視システムに関する技術である。その技術は、各種の処理能力にかかる情報を周期的に取得し、その情報を過去に起きた障害にかかる情報と併せて時間軸上に表示することにより、過去の障害発生時の解析情報と類似しているか否かに基づいて将来の障害発生を予測できる。

特開平１０−０７４１８８号公報に開示された技術は、データ学習装置についての技術である。その技術は、データ管理対象の装置から取得した学習対象となる情報と予め作成した予想値にかかる情報とを比較し、両者の類似度が所定の基準以下であるときは、取得した情報が例外的な情報であると判定する。加えて、その技術は、両者の差分に基づき予想値にかかる情報の内容を修正する。本技術によれば、これらの操作を繰返すことにより、データ管理対象の装置による処理の精度を向上できる。

しかしながら、上述した各特許文献に開示された技術には、以下に述べる問題点があった。

先ず、特開２００４−０６２７４１号公報に開示された技術では、実際に発生したシステム障害に対する対処は的確且つ容易に行われるものの、将来起こり得るシステム障害の予防は解決されないという問題点がある。そのため、将来のシステム障害の予防は、経験の乏しいシステム管理者にとって、依然として負担の大きい作業であるという問題がある。

次に、特開２００５−２５７４１６号公報に開示された技術では、崩れた相関関係の数や内容から実際に発生した障害を特定するために、対象となるシステムの構成と挙動を正確に理解しておく必要がある。すなわち、どのように相関関係が崩れるとどのような障害が起こるのかを把握しておく必要がある。このため、システム管理者に、多大な経験や知識が求められると共に、本技術を実施するときに、多大な負担を強いるという問題がある。

次に、特開２００６−０２４０１７号公報に開示された技術では、予測対象のシステムが大規模であったり、他システムと連携する構成をとっている場合は、処理と負荷との関係が極めて複雑となり、正確な負荷の量を予測するためには、関係し得る全ての処理の履歴を収集して分析しなくてはならなかった。

このため、当該分析において正確な予測をするには、データ収集及び分析の負荷が大きいため、当該分析に携わる者に、大きな負担を強いるという問題点がある。又、当該分析に携わる者は、極めて高度な知識を備えている必要があるという問題がある。

次に、特開２００６−１４６６６８号公報に開示された技術では、実際に起きたシステム異常に対する原因の解明及び改善処置は的確に行われるが、将来のシステム異常の発生についての予測については、現時点のシステムの状態の正常性の判定結果を基に、システム管理者等が自分で行わなければならない。そのため、システム管理者に、多くの経験が求められると共に、多くの負担を強いるという問題がある。

次に、特開２００７−２９３３９３号公報に開示された技術では、分析対象の情報の内容が正常異常の区別なく時系列で連続する情報である場合は、その値や変化状態のみから、どの部分が障害であるかを明確に切り出すことができない。よって、このような場合は、システム管理者等が、自らの経験を基に障害部分を検出しなければならず、システム管理者に、多大な負担を強いるという問題がある。

次に、特開平１０−０７４１８８号公報に開示された技術では、上述した予想値にかかる情報の作成は、システム管理者が自ら行う必要がある。この作成には多くの経験が求められるため、システム管理者に、多くの負担を強いるという問題がある。

以上述べたように、従来の各関連技術では、システム管理者に、ある程度以上のスキルや経験が求められ、又、システム管理者等が被る負担も大きい。

加えて、昨今においては、管理対象のシステムの内容が高度化・複雑化していく傾向にあるため、システム管理者が被る負担も今後更に増大していくことが予想される。

［発明の目的］
本発明は、上述の問題を解決し、将来の障害検出における判断基準を付与するときのシステム管理者にとっての負担を軽減できるシステム運用管理装置、システム運用管理方法、及びプログラム記憶媒体を提供することを目的とする。

本発明のシステム運用管理装置は、システムにおける複数種別の性能値を含む性能情報を時系列に格納する性能情報蓄積手段と、前記性能情報蓄積手段に格納された前記性能情報をもとに複数の期間毎に生成された、異なる前記種別の性能値間の相関関係を１以上含む相関モデルをもとに、同一の前記相関モデルが適用される１以上の期間を抽出し、当該１以上の期間に前記相関モデルを割当てるとともに、当該１以上の期間に適合する暦上の属性を決定することにより、前記暦上の属性と前記相関モデルを関連付けるモデル生成手段と、入力された前記システムの前記性能情報と、当該性能情報が取得された期間の前記暦上の属性に対する前記相関モデルとを用いて、当該性能情報の異常検出を行う分析手段と、を含む。

本発明のシステム運用管理方法は、システムにおける複数種別の性能値を含む性能情報を時系列に格納し、前記性能情報をもとに複数の期間毎に生成された、異なる前記種別の性能値間の相関関係を１以上含む相関モデルをもとに、同一の前記相関モデルが適用される１以上の期間を抽出し、当該１以上の期間に前記相関モデルを割当てるとともに、当該１以上の期間に適合する暦上の属性を決定することにより、前記暦上の属性と前記相関モデルを関連付け、入力された前記システムの前記性能情報と、当該性能情報が取得された期間の前記暦上の属性に対する前記相関モデルとを用いて、当該性能情報の異常検出を行う。

本発明のプログラムは、コンピュータに、システムにおける複数種別の性能値を含む性能情報を時系列に格納し、前記性能情報をもとに複数の期間毎に生成された、異なる前記種別の性能値間の相関関係を１以上含む相関モデルをもとに、同一の前記相関モデルが適用される１以上の期間を抽出し、当該１以上の期間に前記相関モデルを割当てるとともに、当該１以上の期間に適合する暦上の属性を決定することにより、前記暦上の属性と前記相関モデルを関連付け、入力された前記システムの前記性能情報と、当該性能情報が取得された期間の前記暦上の属性に対する前記相関モデルとを用いて、当該性能情報の異常検出を行う、処理を実行させる。

本発明の効果は、システム運用管理装置において、将来の障害検出における判断基準を付与するときのシステム管理者にとっての負担を大幅に軽減できることである。

本発明のシステム運用管理装置の第１の実施形態の構成を示すブロック図である。 本発明の第１の実施形態における、スケジュール情報の一例を示す説明図である。 本発明の第１の実施形態における、スケジュール情報の他の例を示す説明図である。 本発明の第１の実施形態における、スケジュール情報の他の例を示す説明図である。 本発明の第１の実施形態における、相関変化分析結果の生成動作の一例を示す説明図である。 本発明の第１の実施形態における、システム運用管理装置の動作を示すフローチャートである。 本発明のシステム運用管理装置の第２の実施形態の構成を示すブロック図である。 本発明の第２の実施形態における、候補情報生成部２１の構成を示すブロック図である。 本発明の第２の実施形態における、スケジュール候補情報の生成動作の一例を示す説明図である。 本発明の第２の実施形態における、相関変化分析結果の生成動作の一例を示す説明図である。 本発明の第２の実施形態における、修正候補生成部２２の構成を示すブロック図である。 本発明の第２の実施形態における、分析スケジュールの修正候補の生成手順の一例を示す説明図である。 本発明の第２の実施形態における、分析スケジュールの修正候補の生成手順の一例（図１２の続き）を示す説明図である。 本発明の第２の実施形態における、管理者対話部１４により表示される内容の一例を示す説明図である。 本発明の第２の実施形態における、スケジュール候補情報の生成の動作を示すフローチャートである。 本発明の第２の実施形態における、スケジュール情報の修正候補の生成の動作を示すフローチャートである。 本発明のシステム運用管理装置の第３の実施形態の構成を示すブロック図である。 本発明の第３の実施形態における、管理者対話部１４により表示される内容の一例を示す説明図である。 本発明の第３の実施形態における、適合モデル判定部２３による動作を示すフローチャートである。 本発明にかかるシステム運用管理装置の前提となる構成を示すブロック図である。 図２０に示すシステム運用管理装置の性能情報の一例を示す説明図である。 図２１に示す性能情報が蓄積して格納された状態の一例を示す説明図である。 図２０に示すシステム運用管理装置の相関モデルの一例を示す説明図である。 図２０に示すシステム運用管理装置の動作を示すフローチャートである。 図２０に示すシステム運用管理装置の管理者対話部１４により表示される内容の一例を示す説明図である。 本発明の第一の実施の形態の特徴的な構成を示すブロック図である。

以下、本発明にかかるシステム運用管理装置の各実施形態を、図１乃至図２６に基づいて説明する。

［本発明の前提となるシステム運用管理装置］
先ず、第１の実施形態についての説明の前に、本発明の前提となるシステム運用管理装置１０１について図２０乃至図２５に基づいて説明する。

図２０は、本発明にかかるシステム運用管理装置の前提となる構成を示すブロック図である。

図２０において、システム運用管理装置１０１は、顧客用サービス実行システム４の稼働状態を管理する。顧客用サービス実行システム４は、顧客が希望する情報Ｅを電気通信回線を通じて受け取ると共に、上記情報を顧客に提供するサービスを実行する。

顧客用サービス実行システム４は、一又は二以上のサーバにより構成されている。この顧客用サービス実行システム４は、システム運用管理装置１０１とは独立したコンピュータで構成されていてもよい。

システム運用管理装置１０１は、図２０に示すように、性能情報収集部１１と性能情報蓄積部１２とを含む。ここで、性能情報収集部１１は、顧客用サービス実行システム４を構成するサーバの性能情報を当該サーバから定期的に取得する。性能情報蓄積部１２は、性能情報収集部１１が取得した性能情報を順次格納する。これにより、顧客用サービス実行システム４を構成するサーバの性能情報を経時的に保存できる。

ここで、サーバの性能情報とは、顧客用サービス実行システム４を構成するサーバの稼動を左右する各種要素（例えばＣＰＵ、メモリ）の状態を具体的に数値化した、複数種別の性能値により構成された情報である。性能値の具体例としては、ＣＰＵ使用率やメモリ残量がある。

図２１は、図２０に示すシステム運用管理装置の性能情報の一例を示す説明図である。また、図２２は、図２１に示す性能情報が蓄積して格納された状態の一例を示す説明図である。

例えば、性能情報収集部１１は、図２１のような性能情報を取得し、性能情報蓄積部１２は、図２２のように性能情報を格納する。

又、図２０に示すように、システム運用管理装置１０１は、相関モデル生成部１６と、分析用モデル蓄積部１７と、相関変化分析部１８とを含む。相関モデル生成部１６は、顧客用サービス実行システム４の稼動状態の相関モデルを生成する。分析用モデル蓄積部１７は、相関モデル生成部１６により生成された相関モデルを格納する。相関変化分析部１８は、性能情報を構成する性能値の実測値と分析用モデル蓄積部１７に保存されている相関モデルにかかる変換関数による計算値との差が予め設定された基準範囲内にあるか否かを判断しその結果を出力する。これにより、顧客用サービス実行システム４の稼動状態を確認できる。ここで、相関モデル生成部１６は、性能情報蓄積部１２に格納された一定期間の性能情報の時系列データを取出し、この時系列データをもとに性能情報における任意の二つの種別の性能値の相互間の変換関数を導出することで、相関モデルを生成する。

更に、図２０に示すように、システム運用管理装置１０１は、障害分析部１３と、管理者対話部１４と、対処実行部１５とを含む。障害分析部１３は、性能情報に対する相関変化分析部１８による分析結果を基に、顧客用サービス実行システム４について、システム障害の可能性の有無を分析する。管理者対話部１４は、障害分析部１３によりシステム障害の可能性があると判定されたときに、当該判定結果を外部に表示すると共に、表示した内容に対して外部から当該システム異常に対する改善指令が入力されたときにこの入力にかかる情報を受理する。対処実行部１５は、管理者対話部１４に改善指令が入力されたときに、入力にかかる情報を受取ると共に、当該入力にかかる情報の内容に応じて、顧客用サービス実行システム４を構成するサーバ上でシステム障害の対処となる処理を実行する。

これにより、顧客用サービス実行システム４を構成するサーバの性能情報の異常を正確に検知できると共に、的確に対処できる。

次に、システム運用管理装置１０１の各構成部について詳述する。

性能情報収集部１１は、定期的に顧客用サービス実行システム４のサーバにアクセスし、その性能情報を取得する。そして、取得した当該性能情報を性能情報蓄積部１２に格納する。本発明の実施形態においては、この性能情報収集部１１は定期的に性能情報を取得すると共に、性能情報蓄積部１２に順次格納する。

次に、性能情報蓄積部１２は、性能情報収集部１１により取得された性能情報を格納する。上述したように、この性能情報蓄積部１２には性能情報が定期的に順次格納される。

次に、相関モデル生成部１６は、性能情報蓄積部１２に格納された性能情報について、予め設定された取得期間にかかるものを受取り、これら性能情報における任意の二つの種別を選択し、一方の種別の性能値の時系列から他方の種別の性能値の時系列へと変換するための変換関数（以下、相関関数）を導出する。

又、相関モデル生成部１６は、種別の全ての組合せについて上述した相関関数を導出し、その結果得られた各相関関数を組合せることにより、相関モデルを生成する。

更に、相関モデル生成部１６は、上述した相関モデルを生成した後に、この相関モデルを分析用モデル蓄積部１７に格納する。

分析用モデル蓄積部１７は、相関モデル生成部１６から受取った相関モデルを格納する。

次に、相関変化分析部１８は、分析用として性能情報収集部１１により新たに取得された性能情報について、先述の相関関数に一方の種別の性能値を代入することにより得られる他方の種別の性能値の理論値（計算値）と当該性能値の実際の値（実測値）とを比較する。その結果、両値の差が予め設定された基準範囲内であるか否かを判定することにより、両種別の性能値の相関関係が保たれているか否かの分析（以下、相関変化分析）を行う。

相関変化分析部１８は、上記差が基準範囲内であるときに、両種別の性能値の相関関係は正常に保たれていると判定する。この分析結果により、その処理能力にかかる情報を取得した時点における取得元のシステム、即ち顧客用サービス実行システム４を構成するサーバの稼働状況を確認できる。

その後、相関変化分析部１８は、当該分析結果を障害分析部１３に送る。

次に、障害分析部１３は、相関変化分析部１８から受取った分析結果について、予め設定された手法に基づいて顧客用サービス実行システム４を構成するサーバ上の障害の可能性の有無を判定し、この判定の結果を管理者対話部１４に送る。

ここで、上記判定の手法の一例としては、以下のようなものがある。

一つ目の例として、障害分析部１３が、当該性能情報の相関変化分析結果で異常であると判定された相関関係の数が、予め設定された値よりも多いか否かの確認を行い、多いと確認された場合に顧客用サービス実行システム４に障害の可能性があると判定する。

又、二つ目の例として、異常であると判定された相関関係のうち、特定の要素（例えば、ＣＰＵ使用率）に関する相関関係の数が予め設定された閾値以上である場合に限り、顧客用サービス実行システム４に障害の可能性があると判定する。

次に、管理者対話部１４は、障害分析部１３から受取った障害の可能性の有無にかかる判定結果の内容を、図示しない出力部（例えば管理者対話部１４に装備されているモニタ）から外部に表示用として出力する。

図２５は、図２０に示すシステム運用管理装置１０１の管理者対話部１４に表示される内容の一例を示す図である。

例えば、管理者対話部１４は、上記判定結果を図２５の表示画面１４Ａのように表示する。この表示画面１４Ａに示すように、管理者対話部１４は、システム管理者が判定結果を容易把握できるように、図表を多用して表示する。

画面表示１４Ａについて更に説明する。表示画面１４Ａは、性能情報分析結果の異常度合いを示す相関破壊数１４Ａａ、異常場所を示す相関関係図１４Ａｂ、及び異常度合いの大きい要素のリスト１４Ａｃを含む。このように表示することで、例えば、図２５のように、Ｃ．ＣＰＵの異常度合いが大きい場合に、Ｃ．ＣＰＵに障害の可能性があることを的確にシステム管理者に伝えることができる。

又、管理者対話部１４は、障害分析の判定結果の表示（図２５、表示画面１４Ａ）を行った後に、その内容を確認したシステム管理者から、障害に対する改善指令の入力を受け付け、その情報を対処実行部１５へ送る。

次に、対処実行部１５は、管理者対話部１４に入力された障害改善指令に基づく措置を顧客用サービス実行システム４のサーバに実行する。

例えば、或る特定のＣＰＵの負荷が高くなっているため業務量を減らす旨の指令が管理者対話部１４より入力された場合は、対処実行部１５は顧客用サービス実行システム４のサーバに対し業務量を減らすための措置を行う。

［相関モデルの生成］
ここで、上述した相関モデル生成部１６による相関モデルの生成について、更に具体的に説明する。

相関モデル生成部１６は、性能情報蓄積部１２に格納された性能情報の内で、予め外部より設定された一定の期間に取得されたものを取り出す。

次に、相関モデル生成部１６は、性能情報における任意の二つの種別を選択する。

ここでは、相関モデル生成部１６が、図２２の性能情報１２Ｂにおける種別の内、「Ａ．ＣＰＵ」（Ａ．ＣＰＵの使用率）と「Ａ．ＭＥＭ」（Ａ．メモリの残量）を選択したとして説明を進める。

相関モデル生成部１６は、「Ａ．ＣＰＵ」の性能値（入力Ｘ）の時系列から「Ａ．ＭＥＭ」の性能値（出力Ｙ）の時系列へと変換する相関関数Ｆの算出を行う。

ここで、本発明の実施形態では、相関モデル生成部１６は、関数Ｆの内容として、様々な形式の関数の中から適したものを選択できる。ここでは、変換関数Ｆとして「Ｙ＝αＸ＋β」形式の関数が選択されたとして説明を続ける。

相関モデル生成部１６は、性能情報１２Ｂの「Ａ．ＭＥＭ」の性能値Ｘの時系列変化と「Ａ．ＭＥＭ」の性能値Ｙの時系列変化とを比較し、ＸからＹへと変換できる式「Ｙ＝αＸ＋β」のα及びβの値を算出する。ここでは、算出の結果、αとして「−０．６」、βとして「１００」が算出されたとする。

更に相関モデル生成部１６は、Ｘを上述の相関関数「Ｙ＝−０．６Ｘ＋１００」で変換したＹの値の時系列と実際のＹの値の時系列とを比較して、その差分である変換誤差からこの相関関数の重み情報ｗを算出する。

相関モデル生成部１６は、以上の操作を性能情報１２Ｂの二つの種別の全組合せについて実行する。例えば性能情報１２Ｂが五つの種別の性能値から構成されている場合は、相関モデル生成部１６は、これら五つの種別から得られる２０通りの組合せについて相関関数Ｆを生成する。

ここで、この相関関数Ｆは、管理対象となる顧客用サービス実行システム４の安定度をチェックする基準となるため、顧客用サービス実行システム４が安定している期間（平常時）に取得した性能情報を基に作成される。

このようにして得られた種々の相関関数を相関モデル生成部１６が一つに組合せることにより、相関モデルが生成される。

図２３は、図２０に示すシステム運用管理装置の相関モデルの一例を示す説明図である。

この図２３に示した相関モデル１７Ａは、二つの種別の組合せによる複数の相関関数から構成されている。

［相関変化分析］
次に、上述した相関変化分析部１８による相関変化分析について、更に具体的に説明する。

ここでは、性能情報収集部１１が、分析用の性能情報として、図２２の１２Ｂの最下段の行に示した性能情報（２００７年１１月７日８時３０分に取得した性能情報）１２Ｂａを取得したという前提で説明をする。

相関変化分析部１８は、性能情報１２Ｂａを性能情報収集部１１から受取ると、分析用モデル蓄積部１７にアクセスして、ここに格納されている相関モデルを取出し、この相関モデルを構成する相関関数の中から性能情報１２Ｂａの分析に適したものを抽出する。

具体的には、相関変化分析部１８は、性能情報１２Ｂａにおける種別の全ての組合せにかかる相関関数を抽出する。例えば、性能情報１２Ｂａにおける種別が「Ａ．ＣＰＵ」、「Ａ．ＭＥＭ」、及び「Ｂ．ＣＰＵ」の三つである場合は、相関変化分析部１８は、上述した「Ｘ」と「Ｙ」の組合せが、「Ａ．ＣＰＵ」と「Ａ．ＭＥＭ」、「Ａ．ＭＥＭ」と「Ｂ．ＣＰＵ」、及び「Ａ．ＣＰＵ」と「Ｂ．ＣＰＵ」、である相関関数を全て選択し抽出する。

以降、種別の組合せが「Ａ．ＣＰＵ」と「Ａ．ＭＥＭ」である相関関数を抽出し、これに基づき相関変化分析を実行するケースについて説明を続ける。

相関変化分析部１８は、性能情報１２Ｂａについて、「Ａ．ＣＰＵ」の実測値を上記相関関数のＸに代入し、Ｙの値を算出する。そして、相関変化分析部１８は、算出されたＹの値（即ち、「Ａ．ＭＥＭ」の理論値）と当該性能情報の「Ａ．ＭＥＭ」の実際の値（実測値）とを比較する。

この比較の結果、「Ａ．ＭＥＭ」の理論値及び「Ａ．ＭＥＭ」の実測値との差が、予め設定された基準範囲内（許容誤差範囲内）であると確認された場合は、相関変化分析部１８は、性能情報１２Ｂａにかかる二つの種別「Ａ．ＣＰＵ」と「Ａ．ＭＥＭ」については相関関係が保たれている（即ち、正常である）と判定する。

一方、上述した差が、基準範囲外であると確認された場合は、相関変化分析部１８は、性能情報１２Ｂａにかかる二つの種別「Ａ．ＣＰＵ」と「Ａ．ＭＥＭ」に関しては相関関係が崩れている（即ち、異常である）と判定する。

［図２０におけるシステム運用管理装置の動作］
次に、システム運用管理装置１０１の動作について、以下図２４に基づいて説明する。

図２４は、図２０に示すシステム運用管理装置の動作を示すフローチャートである。

性能情報収集部１１が、顧客用サービス実行部４から性能情報を定期的に取得し（ステップＳ１０１）、性能情報蓄積部１２に格納していく（ステップＳ１０２）。

次いで、相関モデル生成部１６が、性能情報蓄積部１２に格納された性能情報の内の予め設定された期間にかかるものを取得し、これらに基づき相関モデルを生成する（ステップＳ１０３）。ここで生成された相関モデルは、分析用モデル蓄積部１７に格納される。

続いて、相関変化分析部１８が、性能情報収集部１１から、分析対象となる性能情報を取得する（ステップＳ１０４）。それと共に、相関変化分析部１８は、分析用モデル蓄積部１７から、相関変化分析に用いる相関モデルを取得する。

続いて、相関変化分析部１８が、分析用の性能情報について相関変化分析を行い、相関破壊を検出する（ステップＳ１０５）。

この相関変化分析の終了後、相関変化分析部１８は、分析結果を障害分析部１３に送る。

分析結果を受取った障害分析部１３は、分析結果における相関関係が崩れていると判定された相関関係の数（相関破壊の数）をチェックし、その数が予め設定された基準を超えているか否かを確認する（ステップＳ１０６）。確認の結果、予め設定された基準を超えている場合は（ステップＳ１０６／イエス）、障害分析部１３は、顧客用サービス実行システム４に障害の可能性があると判断し、その詳細な分析内容にかかる情報を管理者対話部１４に送る。一方、予め設定された基準を超えていない場合は（ステップＳ１０６／ノー）、ステップＳ１０４の分析用性能情報の取得工程以降の工程が繰返される。

詳細な分析内容にかかる情報を障害分析部１３から受取った管理者対話部１４は、この情報に基づき、顧客用サービス実行システム４に障害の可能性がある旨を表示する（ステップＳ１０７）。

続いて、管理者対話部１４にて表示された分析結果を確認したシステム管理者により、障害に対する改善指令が管理者対話部１４に入力されると、管理者対話部１４は、その改善指令入力にかかる情報を対処実行部１５に送る（ステップＳ１０８）。

続いて、対処実行部１５は、改善指令入力にかかる情報を受取ると、その内容に従い顧客用サービス実行システム４に対して改善措置を実行する（ステップＳ１０９）。

以降、分析用性能情報の取得操作の工程（ステップＳ１０４）以降の工程が繰返される。これによって、顧客用サービス実行システム４の状態の経時変化を確認できる。

［第１の実施形態］
次に、本発明の第１の実施形態の具体的内容を図１乃至図６に基づいて説明する。

図１は、本発明のシステム運用管理装置の第１の実施形態の構成を示すブロック図である。

ここで、図１に示すように、本発明の第１の実施形態におけるシステム運用管理装置１は、前述した図２０におけるシステム運用管理装置１０１と同様に、性能情報収集部１１と、性能情報蓄積部１２と、相関モデル生成部１６と、分析用モデル蓄積部１７と、相関変化分析部１８と、障害分析部１３と、管理者対話部１４と、対処実行部１５とを含む。性能情報収集部１１は、性能情報を顧客用サービス実行システム４から取得する。性能情報蓄積部１２は、取得された性能情報を格納する。相関モデル生成部１６は、取得された性能情報を基に相関モデルを生成する。分析用モデル蓄積部１７は、生成された相関モデルを格納する。相関変化分析部１８は、相関モデルを用いて取得した性能情報の異常性を分析する。障害分析部１３は、相関変化分析部１８による分析結果を基に顧客用サービス実行システム４の異常性を判断する。管理者対話部１４は、障害分析部１３による判断結果を出力する。対処実行部１５は、管理者対話部１４が出力した内容に対する改善指令の入力があったときに、その指令に基づき、顧客用サービス実行システム４の改善を行う。

更に、システム運用管理装置１は、分析スケジュール蓄積部１９を含む。分析スケジュール蓄積部１９は、上述した相関変化分析時に、分析用の性能情報の取得時期に合せて相関モデルを切替えるためのスケジュールであるスケジュール情報を格納する。ここで、このスケジュール情報は、予めシステム管理者により作成される。

分析スケジュール蓄積部１９は相関モデル生成部１６及び相関変化分析部１８からアクセス可能である。これにより、この分析スケジュール蓄積部１９に格納されたスケジュール情報に基づき、相関モデルを生成し、性能情報分析を実行できる。

又、本発明の第１の実施形態における管理者対話部１４、相関モデル生成部１６、及び相関変化分析部１８は、先述した各種機能に加え、更に新たな機能を有している。以下、それらの機能について説明する。

管理者対話部１４は、外部にて予め生成されたスケジュール情報の入力を受け付けると共に、入力されたスケジュール情報を分析スケジュール蓄積部１９に格納する。

図２、図３及び図４は、本発明の第１の実施形態における、スケジュール情報の例を示す説明図である。

例えば図２におけるスケジュール情報１９Ａでは、毎週土日を表す１番目の優先度のスケジュールと、毎日を表す２番目の優先度のスケジュールが指定されている。このスケジュール情報１９Ａは、優先度順に適用され、分析期間は、毎週土日曜日と、それ以外の曜日（月曜日〜金曜日）の２つに区別される。

同様に、図３におけるスケジュール情報１９Ｂでは、毎日を表わす１番目の優先度のスケジュールのみが指定されている。

又、図４におけるスケジュール情報１９Ｃでは、毎月の最終日で且つ平日である１番目の優先度のスケジュールと、毎週土日を表す２番目の優先度のスケジュールと、毎日を表す３番目の優先度のスケジュールとが指定されている。

［相関モデルの生成］
次に、本発明の第１の実施形態における相関モデル生成部１６による相関モデルの生成について、更に説明する。

相関モデル生成部１６は、相関モデルの生成に当たり、性能情報蓄積部１２から予め設定された期間にかかる性能情報を取得すると共に、分析スケジュール蓄積部１９からスケジュール情報を受取る。そして、相関モデル生成部１６は、性能情報を、当該性能情報の性能情報収集部１１による取得時期について、スケジュール情報に定められた分析期間に従って区分けする。その後、相関モデル生成部１６は、その区分けされた各々の性能情報群に基づいて、前述した手法により相関モデルを生成する。これにより、各分析期間における相関モデルが得られる。

例えば、相関モデル生成部１６がスケジュール情報１９Ａ（図２）を取得し、相関モデルを生成するケースを考える。

先ず、相関モデル生成部１６は、１番目の優先度の分析期間、即ち土日曜日に性能情報収集部１１に取得された性能情報を基に相関関数を導出し、これに基づき相関モデルを生成する。

次いで、相関モデル生成部１６は、２番目の優先度の分析期間、即ち毎日から上記１番目の優先度の期間を除いた期間である月曜日〜金曜日に取得された性能情報を基に相関関数を導出し、これに基づいて相関モデルを生成する。

その後、相関モデル生成部１６は、生成した各分析期間にかかる相関モデルの全てを、各分析期間に関連付けて、分析モデル蓄積部１７に格納する。

なお、本発明の第１の実施の形態においては、モデル生成部３０が、相関モデル生成部１６を含むものとする。また、分析部３１が、相関変化分析部１８と障害分析部１３とを含むものとする。

［相関変化分析］
次に、本発明の第１の実施形態における相関変化分析部１８による相関変化分析について、更に説明する。

先ず、相関変化分析部１８は、情報収集部１１から分析用性能情報を受取ると共に、スケジュール情報に基づいて生成された相関モデルの全てを分析用モデル蓄積部１７から取出す。更に、相関変化分析部１８は、分析スケジュール蓄積部１９からスケジュール情報を取得する。

次いで、相関変化分析部１８は、取得した性能情報の取得日時を確認する。このときの取得日時の確認手法として、例えば、当該性能情報の中に包含されている日時情報（図２１の性能情報１２Ａ参照）を相関変化分析部１８が読み取ってもよい。

そして、相関変化分析部１８は、現在設定されている相関モデルが、分析用として取得した性能情報の相関変化分析を行うのに適したものであるか否か（即ち、この相関モデルの生成に用いられた性能情報の取得時期が取得された分析用性能情報の取得時期と同じ分析期間であるか否か）を確認する。

確認の結果、相関モデルが相関変化分析に用いるのに適さないものである場合は、相関変化分析部１８は分析用モデル蓄積部１７の中から分析に適した相関モデルを抽出し、その相関モデルに設定を切替える。

このときに、もし分析に適した相関モデルがまだ生成されていない場合は、相関変化分析部１８は、相関モデル生成部１６に分析に適した相関モデルが存在しない旨の情報を送る。この情報を受取った相関モデル生成部１６は、分析に適した相関モデルを補充生成し、分析用モデル蓄積部１７に格納する。更に相関モデル生成部１６は、相関モデルの生成が完了した旨の情報を相関変化分析部１８へと送る。

図５は、本発明の第１の実施形態における、相関変化分析結果の生成動作の一例を示す説明図である。

図５の１８Ａは、上述のように、分析期間の切り替え判定と分析実行の動作が繰り返し実行された場合の、分析結果を示す。図５の１８Ａａでは、休日（図２のスケジュール情報１９Ａの１番目の優先度のスケジュールに相当）と平日（図２のスケジュール情報１９Ａの２番目の優先度のスケジュールに相当）で分析期間が区別されており、それぞれの区間で相関モデルが生成され分析が行われる。これらの分析結果を分析期間毎に抽出して合成することで、図５の１８Ａｂに示すような分析結果が得られる。

この場合、平日には平日用相関モデルが利用され、休日には休日用相関モデルが利用されることで、それぞれの期間の稼動特性に応じた分析結果が提供される。このように、予め指定したスケジュール情報に従って自動的に相関モデルを切り替えて分析することで、管理者の負担を増加させずに高精度な分析結果が得られる。

上記各部のその他の機能については、上述した図２０におけるシステム運用管理装置１０１と同一である。

［第１の実施形態の動作］
次に、本発明の第１の実施形態におけるシステム運用管理装置１の動作について、以下図６に基づいて説明する。

図６は、本発明の第１の実施形態における、システム運用管理装置の動作を示すフローチャートである。

ここでは、全体的な動作の流れを明確にするために、上述した図２０におけるシステム運用管理装置１０１の動作と重複するものについても言及する。

管理者対話部１４が、外部から入力されたスケジュール情報を分析スケジュール蓄積部１９に送り、保存する（ステップＳ２０１、スケジュール情報格納工程）。

又、性能情報収集部１１が、顧客用サービス実行システム４を構成するサーバから定期的に性能情報を取得し（ステップＳ２０２、性能情報取得工程）、性能情報蓄積部１２に保存する（ステップＳ２０３、性能情報蓄積工程）。

次いで、相関モデル生成部１６は、性能情報蓄積部１２から一定期間の性能情報を取得する。更に、相関モデル生成部１６は、分析スケジュール蓄積部１９から分析スケジュール情報を取得する。

次いで、相関モデル生成部１６は、取得した分析スケジュール情報に含まれる分析期間毎に相関モデルを生成し（ステップＳ２０４、相関モデル生成工程）、各分析期間に関連付けて、分析用モデル蓄積部１７に保存する。

続いて、相関変化分析部１８は、性能情報収集部１１から分析用となる性能情報を取得する（ステップＳ２０５、分析用性能情報取得工程）。相関変化分析部１８は、分析用モデル蓄積部１７から各期間の相関モデルを、分析スケジュール蓄積部１９からスケジュール情報を、それぞれ取得する（ステップＳ２０６、相関モデル及びスケジュール情報取得工程）。

そして、相関変化分析部１８は、分析対象となる性能情報の取得日時を確認し、現在設定されている相関モデルが当該性能情報の分析に適したものであるか否かを確認し、相関モデルの切替えが必要であるか否かを判定する（ステップＳ２０７、分析期間選択工程）。

すなわち、現在設定されている相関モデルが性能情報の分析に適したものでない場合、相関変化分析部１８は、当該分析に適した相関モデルへと切替えを行うと判定する。一方、分析に適した相関モデルが既に設定されている場合、相関変化分析部１８は、相関モデルの切替えは行わないと判定する。

ステップＳ２０７にて相関モデルの設定の切替えを行うと判定した場合（ステップＳ２０７／イエス）、相関関係分析部１８は切替わった後の分析期間にかかる相関モデルが既に生成されているか否かを確認する（ステップＳ２０８）。もし未だ生成されていない場合は（ステップＳ２０８／ノー）、相関関係分析部１８は切替えた後の分析期間にかかる相関モデルが生成されていない旨の情報を相関モデル生成部１６に送信する。当該情報を受け取った相関モデル生成部１６は、当該相関モデルを補充生成する（ステップＳ２０９、相関モデル補充生成工程）と共に分析用モデル蓄積部１７に格納し、切替え後の相関モデルの補充生成終了の旨の情報を相関変化分析部１８に送る。

又、切替わった後の相関モデルが既に生成されている場合は（ステップＳ２０８／イエス）、相関変化分析部１８は、当該相関モデルを用いて性能情報について相関変化分析を行う（ステップＳ２１０、相関変化分析工程）。

又、ステップＳ２０７にて相関モデルの切替えを行わないと判定した場合は（ステップＳ２０７／ノー）、相関変化分析部１８は、そのまま現在設定されている分析期間にかかる相関モデルを用いて相関変化分析を行う（ステップＳ２１０、相関変化分析工程）。

相関変化分析の終了後、相関変化分析部１８は、分析結果を障害分析部１３に送る。

分析結果を受取った障害分析部１３は、当該性能情報の相関変化分析結果で異常と判定された相関関係数が予め規定された値を超えているか否かの確認を行う（ステップＳ２１１、障害分析工程）。確認の結果、超えている場合は（ステップＳ２１１／イエス）、障害分析部１３は、当該性能情報における異常性の詳細内容の情報を管理者対話部１４に送る。一方、超えていない場合は（ステップＳ２１１／ノー）、ステップＳ２０５の分析用性能情報取得工程以降の工程が繰返される。

管理者対話部１４は、性能情報の異常性の詳細内容にかかる情報を障害分析部１３から受取ると、その情報に基づき、顧客用サービス実行システム２０３に障害の可能性がある旨を表示する（ステップＳ２１２、障害情報出力工程）。

続いて、管理者対話部１４にて表示された分析結果を確認したシステム管理者により、上述のシステムの障害についての改善指令が管理者対話部１４に入力されると、管理者対話部１４は、その改善指令入力にかかる情報を対処実行部１５に送る（ステップＳ２１３、改善指令情報入力工程）。

続いて、対処実行部１５は、改善指令入力にかかる情報を管理者対話部１４から受取ると、その情報の内容に従い顧客用サービス実行システム４に対して改善措置を実行する（ステップＳ２１４、システム改善工程）。

これ以降、分析用性能情報の取得操作（ステップＳ２０５）以降の工程が繰返し実行される。これにより、顧客用サービス実行システム４の運用状態の変化を経時的に確認できる。

ここで、上述した各工程で実行される具体的内容をプログラム化し、これをコンピュータに実行させるようにしてもよい。

次に、本発明の第一の実施の特徴的な構成について説明する。図２６は、本発明の第一の実施の形態の特徴的な構成を示すブロック図である。

システム運用管理装置１は、性能情報蓄積部１２と、モデル生成部３０と、分析部３１とを含む。

ここで、性能情報蓄積部１２は、システムにおける複数種別の性能値を含む性能情報を時系列に格納する。モデル生成部３０は、複数の属性のいずれかを有する複数の期間のそれぞれにおける、性能情報蓄積部１２に格納された異なる種別の性能値間の相関関係を１以上含む相関モデルを生成する。分析部３１は、入力されたシステムの性能情報と、当該性能情報が取得された期間の前記属性に対応する相関モデルとを用いて、当該性能情報の異常検出を行う。

［第１の実施形態の効果］
本発明の第１の実施形態によれば、スケジュール情報を導入し、分析用性能情報の取得時と同じ分析期間に取得された性能情報に基づく相関モデルで相関変化分析を行うようにしたため、顧客用サービス実行システム４の環境が時々刻々変動するような場合であっても、好適な相関モデルを適宜選択した上で、相関変化分析を実行できる。これにより、高い精度で顧客用サービス実行システム４の運用を管理することができる。

更に、本発明の第１の実施形態によれば、業務パターンをスケジュール情報として登録しておくことで、業務パターンの組み合わせで必要となるモデルの作成および切り替えが自動化され、システム管理者の負担が大幅に低減される。

ここで、本発明はこの例に限定されるものではない。本発明では、分析用性能情報の取得日時に対応する分析期間の相関モデルの切り替えを指定できる他の方法を用いても、同様の効果を得ることが出来る。

又、上述の説明では、相関モデルの切替えをするか否かの判定を相関変化分析部１８が行う。しかしながら、本発明ではこの例に限定されるものではない。相関モデルの切替えをするか否かの判定を相関モデル生成部１６が判定するようにしてもよいし、相関モデル生成部１６と相関変化分析部１８との内のどちらか一方が判定して、他方を制御してもよい。又、相関モデル生成部１６と相関変化分析部１８とが共同で分析期間の判定を行うようにしてもよい。

以上何れの手法を採用しても、分析用性能情報の取得日時に応じて相関モデルを切り替えて分析を行えるものであれば、システム運用管理装置１は、同様の効果を提供できる。

［第２の実施形態］
次に、本発明にかかる運用管理システムの第２の実施形態について、図７乃至図１６に基づいて説明する。

図７は、本発明のシステム運用管理装置の第２の実施形態の構成を示すブロック図である。

図７に示すように、本発明の第２の実施形態におけるシステム運用管理装置２は、前述した第１の実施形態におけるシステム運用管理装置１と同様に、性能情報収集部１１と、性能情報蓄積部１２と、相関モデル生成部１６と、分析用モデル蓄積部１７と、相関変化分析部１８と、障害分析部１３と、管理者対話部１４と、対処実行部１５と、分析スケジュール蓄積部１９とを含む。性能情報収集部１１は、性能情報を顧客用サービス実行システム４から取得する。性能情報蓄積部１２は、取得された性能情報を格納する。相関モデル生成部１６は、取得された性能情報を基に相関モデルを生成する。分析用モデル蓄積部１７は、生成された相関モデルを格納する。相関変化分析部１８は、相関モデルを用いて取得した性能情報の異常性を分析する。障害分析部１３は、相関変化分析部１８による分析結果を基に顧客用サービス実行システム４の異常性を判断する。管理者対話部１４は、障害分析部１３による判断結果を出力する。対処実行部１５は、管理者対話部１４が出力した内容に対する改善指令の入力があったときにその指令に基づき記顧客用サービス実行システム４の改善を行う。分析スケジュール蓄積部１９は、分析スケジュールを格納する。

更に、図７に示すように、このシステム運用管理装置２は、定期モデル蓄積部２０と、候補情報生成部２１と、修正候補生成部２２とを含む。定期モデル蓄積部２０は、相関モデル生成部１６が定期的に生成した相関モデルを格納する。候補情報生成部２１は、定期モデル蓄積部２０から相関モデルを受取ると共に、それらの相関モデルの内容の変動状況からスケジュール情報の仮案であるスケジュール候補情報を生成する。修正候補生成部２２は、候補情報生成部２１により生成されたスケジュール候補情報における各分析期間に暦上の属性であるカレンダ情報を順次当て嵌めていく（各分析期間とカレンダ情報とを比較し、各分析期間に適合する暦上の属性を抽出する）ことにより、スケジュール情報の修正候補を生成する。

図７に示すように、定期モデル蓄積部２０は相関モデル生成部１６に接続されている。これにより、定期モデル蓄積部２０は、相関モデル生成部１６にて順次生成された相関モデルを順次格納できる。

図８は、本発明の第２の実施形態における、候補情報生成部２１の構成を示すブロック図である。

図８に示すように、候補情報生成部２１は、共通相関判定部２１ａ、静的要素変化点抽出部２１ｂ、動的要素類似度判定部２１ｃ、及び、必要モデル群抽出部２１ｄを含む。共通相関判定部２１ａは、連続する期間に相関モデル生成部１６により作成された相関モデル間の共通の相関関係を抽出する。静的要素変化点抽出部２１ｂは、共通相関判定部２１ａにより抽出された共通する相関関係の数の増減から、性能情報分析のための相関モデルを切替える時点を抽出する。動的要素類似度判定部２１ｃは、静的要素変化点抽出部２１ｂにより抽出された新しい分析期間の相関モデルと、過去の分析期間で用いられた相関モデルと、に含まれる相関関係の類似度を確認する。必要モデル群抽出部２１ｄは、静的要素変化点抽出部２１ｂ及び動的要素類似度判定部２１ｃにより相関モデルが割り当てられた各分析期間を基に、スケジュール候補情報を生成する。

図１１は、本発明の第２の実施形態における、修正候補生成部２２の構成を示すブロック図である。

図１１に示すように、修正候補生成部２２は、カレンダ情報蓄積部２２ａ、カレンダ特性判定部２２ｂ、及び、修正候補生成部２２ｃを含む。カレンダ情報蓄積部２２ａは、曜日情報や祝日情報といった暦上の属性にかかる情報（以下、カレンダ情報）を保存する。カレンダ特性判定部２２ｂは、候補情報生成部２１の必要モデル群抽出部２１ｄからスケジュール候補情報を受取ると共に、その内容にカレンダ情報蓄積部２２ａに保存されているカレンダ情報を当て嵌めることにより、スケジュール候補情報における各分析期間の日付の特性（以下、カレンダ特性）を決定する。修正候補生成部２２ｃは、カレンダ特性判定部２２ｂにより決定されたカレンダ特性を既存のスケジュール情報の内容と比較すると共に、両者に差異点が存在するときは、カレンダ特性の内容に基づきスケジュール情報の修正候補を生成する。

又、本発明の第２の実施形態においては、相関モデル生成部１６、及び管理者対話部１４は、上述した各種機能に加え、更に新たな機能を有している。以下、それらの機能について説明する。

相関モデル生成部１６は、予め外部より設定された時間間隔で相関モデルを生成する。これにより、顧客用サービス実行システム４の様々な運用状況に対応した相関モデルを得ることができる。

管理者対話部１４は、スケジュール情報の修正候補を分析スケジュール蓄積部１９から取得すると共に、それを表示する。これにより、生成したスケジュール情報案をシステム管理者に提示できると共に、スケジュール情報の変更の可否について、システム管理者の判断を仰ぐことができる。

なお、本発明の第２の実施の形態においては、モデル生成部３０が、相関モデル生成部１６と、候補情報生成部２１と、修正候補生成部２２とを含むものとする。また、分析部３１が、相関変化分析部１８と障害分析部１３とを含むものとする。

［相関モデルの定期的生成］
本発明の第２の実施形態における相関モデルの生成について、上述した第１の実施形態と異なる部分を中心に説明する。

上述したように、相関モデル生成部１６は予め外部より設定された時間間隔で（区間毎に）相関モデルを作成する。ここで、上記時間間隔の設定の一例として、システム管理者は、時間間隔に「毎日１５時に相関モデルを生成する」という内容を設定できる。

なお、上記時間間隔（区間）の長さは、時間間隔（区間）毎に同一の長さでもよいし、異なる長さでもよい。

そして、順次生成された相関モデルは、分析用モデル蓄積部１７ではなく、定期モデル蓄積部２０に順次格納されていく。

［スケジュール候補情報の生成］
次に、上述した候補情報生成部２１によるスケジュール候補情報の生成について、以下説明する。

共通相関判定部２１ａは、定期モデル蓄積部２０に格納されている複数の相関モデルを取出す。そして、取出した相関モデルの内で、生成の基となった性能情報の取得時期が連続しているもの同士を比較し、共通する相関関係（例えば、相関関数）を抽出していく。

この操作を、共通相関判定部２１ａは、全ての連続する期間に作成された相関モデルの組合せについて行っていく。

次に、静的要素変化点抽出部２１ｂは、共通相関判定部２１ａにより抽出された各共通する相関関係について、その共通する相関関係の数の経時的変化を確認する。

この静的要素変化点抽出部２１ｂによる相関関係の数の経時的変化の確認操作について、具体例を用いて説明する。

例として、連続している各期間ｐ、ｑ、ｒ、ｓ、ｔに、性能情報収集部１１により取得された性能情報に基づいて相関モデル生成部１６により生成された、相関モデルＰ、Ｑ、Ｒ、Ｓ、Ｔが存在する事例を考える。

静的要素変化点抽出部２１ｂは、（ａ）相関モデルＰと相関モデルＱにおける共通する相関関係の数、（ｂ）相関モデルＱと相関モデルＲにおける共通する相関関係の数、（ｃ）相関モデルＲと相関モデルＳにおける共通する相関関係の数、（ｄ）相関モデルＳと相関モデルＴにおける共通する相関関係の数を順次確認していく。

静的要素変化点抽出部２１ｂによる確認の結果、共通する相関関係の数が上記（ａ）の組合せでは３個、上記（ｂ）の組合せでは２個、上記（ｃ）の組合せでは３個、上記（ｄ）の組合せでは０個であるものと仮定する。

このとき、静的要素変化点抽出部２１ｂは、上述した連続する期間の相関モデル間の共通する相関関係の数の経時的変化について、その変化量が予め外部より設定された数より多くなった時点を、性能情報分析のための相関モデルを切替える時点（分析期間の分割点）と判断する。

本事例では、上記設定が、「共通する相関関係の数の変化が３以上となった時点で相関モデルを切替える」という内容であるものと仮定する。

これにより、上述の事例においては、上記（ａ）の組合せから上記（ｂ）の組合せでは変化量は１であり、上記（ｂ）の組合せから上記（ｃ）の組合せでは変化量は１であり、上記（ｃ）の組合せから上記（ｄ）の組合せでは変化量は３である。

よって、上記（ｃ）の組合せから上記（ｄ）の組合せになる時点が上記設定に合致することになるため、静的要素変化点抽出部２１ｂは、ここが相関モデルを切替える時点、即ち分析期間の分割点と判断する。そして、静的要素変化点抽出部２１ｂは、この分割点にて分析期間を分割する。

次に、動的要素類似度判定部２１ｃは、上述した分析期間の分割によって設定される新しい分析期間に、相関モデル生成部１６により定期的に生成されている相関モデルの内の最新のものを一時的に割り当てる。

更に、動的要素類似度判定部２１ｃは、上記一時的に割当てられた相関モデルと、分析期間が静的要素変化点抽出部２１ｂにより分割される以前に割当てられていた相関モデル（分割点より前のそれぞれの分析期間に割り当てられている相関モデル）とについて、その内容の類似度を確認する。

この確認の結果、予め設定された類似基準を超えて両者が類似していると確認されたときは、動的要素類似度判定部２１ｃは、上記新しい分析期間における相関モデルを、分割される以前に割当てられていた相関モデル（分割点より前のそれぞれの分析期間に割り当てられている相関モデルのうち、上記一時的に割当てられた相関モデルと類似している相関モデル）に置き換える。

ここで、上述した静的要素変化点抽出部２１ｂ及び動的要素類似度判定部２１ｃによる分析期間の分割及び分析期間毎の相関モデルの割当てについて、図９に基づき更に説明する。

図９は、本発明の第２の実施形態における、スケジュール候補情報の生成動作の一例を示す説明図である。

この図９の２１Ａは、分析期間の分割と、新たな相関モデルの割り当てを示している。図９の段階１（２１ｂ１）では、相関モデルＡにより性能情報分析がなされていた区間が分割されて、相関モデルＢが新たに設定されている。この場合、まず相関モデルＡで性能情報分析が実行されている状態で、候補情報生成部２１の静的要素変化点抽出部２１ｂが、定期的に生成された相関モデル間の差異を発見し、分析期間を分割するとともに、最新の定期相関モデルである相関モデルＢをその期間に割り当てている。

図９の段階２（２１ｂ２）では、このようにして相関モデルＢを用いた分析が継続した後、同様にして、静的要素変化点抽出部２１ｂが新たな分析期間を設定し、最新の定期相関モデルである相関モデルＣを割り当てている。同時に、候補情報生成部２１の動的要素類似度判定部２１ｃは、相関モデルＡと相関モデルＣとの類似性を判定する。その結果、類似していると判断した場合は、動的要素類似度判定部２１ｃは、図９の段階３（２１ｃ１）に示すように、新たな区間に対する相関モデルとして、相関モデルＣではなく相関モデルＡを割り当てる。

これによって、設定された異なる分析期間の間で相関モデルが類似しているにもかかわらず、分析期間毎に異なる分析モデルが生成されることにより、相関モデルが大量に生成され、格納用メモリ容量が不足する事態を防ぐことができる。更には、格納用メモリ不足が原因でシステム運用管理装置２全体の動作速度の低下や、動作が不安定になる事態を防ぐことができる。

次に、必要モデル群抽出部２１ｄは、静的要素変化点抽出部２１ｂ及び動的要素類似度判定部２１ｃにより相関モデルが割り当てられた各分析期間を一つにつなげることで、スケジュール候補情報を生成する。

図１０は、本発明の第２の実施形態における、相関変化分析結果の生成動作の一例を示す説明図である。

ここで、図１０の２１Ｂは、本発明の第２の実施形態における相関変化の分析結果を示している。

図１０の２１ｃ２に示すように、静的要素変化点抽出部２１ｂ及び動的要素類似度判定部２１ｃにより、上述した分析期間への相関モデルの割当て動作が行われることにより、各分析期間１、２及び３に対して、相関モデルＡ又はＢが割当てられる。ここで、分析期間１、２及び３における分析結果の内、相関モデルＡを用いた各分析結果をそれぞれＡ１及びＡ３とする。同様に、相関モデルＢを用いた各分析結果をそれぞれＢ２とする。

そして、図１０の２１ｄ１に示すように、上述した分析結果Ａ１、分析結果Ｂ２、分析結果Ａ３が分析結果として生成される。

必要モデル群抽出部２１ｄは、スケジュール候補情報の各分析期間に割り当てられている相関モデルを分析用モデル蓄積手段２０に蓄積し、スケジュール候補情報を修正候補生成手段２２のカレンダ特性判定部２２ｂに送る。

図１２は、本発明の第２の実施形態における、分析スケジュールの修正候補の生成手順の一例を示す説明図である。

例えば、必要モデル群抽出部２１ｄは、図１２のスケジュール候補情報２１ｄ２をカレンダ特性判定部２２ｂに送る。

［スケジュール情報の修正候補の生成］
カレンダ特性判定部２２ｂは、必要モデル群抽出部２１ｄからスケジュール候補情報を受取ると共に、カレンダ情報蓄積部２２ａからカレンダ情報を取得する。ここで、カレンダ情報は、予めシステム管理者により作成される。

そして、カレンダ特性判定部２２ｂは、スケジュール候補情報の内容とカレンダ情報とを比較し、スケジュール候補情報における各分析期間のそれぞれに、対応するカレンダ情報を順次当て嵌める。これにより、カレンダ特性が決定される。

ここで、上述したカレンダ特性判定部２２ｂによるカレンダ特性の決定について、図１２に基づき更に説明する。

図１２に示すように、必要モデル群抽出部２１ｄから受取った２００９年８月のスケジュール候補情報２１ｄ２が、土・日曜日と月〜金曜日と月末日という三種類の分析期間Ａ〜Ｃに分けられている事例を考える。この事例において、カレンダ情報２２ａ１は、土・日曜日に対して「休日」、月〜金曜日に対して「平日」、２００９年８月３１日に対して「月末日」という暦上の属性が設定されていると仮定する。

このとき、カレンダ特性判定部２２ｂは、スケジュール候補情報２１ｄ２とこのカレンダ情報２３ａ１とを比較し、スケジュール候補情報２１ｄ２の各分析期間に適合するカレンダ情報２３ａ１の属性を抽出する（生成手順２１ｂ１）。これにより、土・日曜日にかかる分析期間が「休日」、月〜金曜日にかかる分析期間が「平日」、及び８月３１日にかかる分析期間が「月末日」というように、それぞれの分析期間についてカレンダ特性２２ｂ２が決定される。

上記カレンダ特性の決定により、スケジュール候補情報の各分析期間についてその内容を逐一調査せずとも、上記各分析期間の暦上の属性を自動的に特定することができる。

次に、修正候補生成部２２ｃは、カレンダ特性をカレンダ特性判定部２２ｂから受取り、システム管理者により予め生成されたスケジュール情報を分析スケジュール蓄積部１９から受取る。そして、修正候補生成部２２ｃは、カレンダ特性と既に生成されたスケジュール情報について、その内容を比較する。

この比較の結果、カレンダ特性が示す内容が予め生成されたスケジュール情報の内容から変化している場合は、スケジュール情報生成部２２ｃは、カレンダ特性の内容を基にスケジュール情報の修正候補を生成する。そしてスケジュール情報生成部２２ｃは、このスケジュール情報の修正候補を分析スケジュール蓄積部１９に保存する。

図１３は、本発明の第２の実施形態における、分析スケジュールの修正候補の生成手順の一例（図１２の続き）を示す説明図である。

ここで、上述したスケジュール情報生成部２１ｃによるスケジュール情報の修正候補の生成の機能について、図１３に基づき更に説明する。

図１３に示すように、カレンダ特性判定部２２ｂによりカレンダ特性２２ｂ２が生成され、分析スケジュール蓄積部１９に既存のスケジュール情報１９Ｂが保存されているものとする。

両者を比較すると、カレンダ特性２２ｂ２の内容は、既存のスケジュール情報１９Ｂの内容から、明らかに変化している（生成手順２２ｃ１）。よって、スケジュール情報生成部２２ｃは、このカレンダ特性２２ｂ２をスケジュール情報に反映することにより、スケジュールの修正候補２２ｃ２を生成する。

これにより、既存のスケジュール情報がたとえ好適でないものであっても、好適なスケジュール情報を自動的に得ることが出来る。

［スケジュール情報の修正候補の表示］
管理者対話部１４は、分析スケジュール蓄積部１９からスケジュール情報の修正候補を予め生成されたスケジュール情報と共に取出すと共に、両者を同一画面上に表示する。

図１４は、本発明の第２の実施形態における、管理者対話部１４により表示される内容の一例を示す説明図である。

例えば、管理者対話部１４は、図１４の表示画面１４Ｂを表示する。

この表示画面１４Ｂに示すように、管理者対話部１４は、予め生成されたスケジュール情報とスケジュール情報の修正候補の両者を、その内容を容易に比較できるように並べて表示する。

又、管理者対話部１４は、予め生成されたスケジュール情報とスケジュール情報の修正候補における、分析期間毎の相関モデル（１４Ｂａ）及び必要な相関モデルの一覧（１４Ｂｂ）も同時に表示する。この理由は、構成要素である相関モデルを明示することにより、予め生成されたスケジュール情報とスケジュール情報との相違点を明確にできるからである。

更に、管理者対話部１４は、正規のスケジュール情報を、予め生成されたスケジュール情報からスケジュール情報の修正候補へ変更する為の操作ボタン１４Ｂｃも表示する。システム管理者がこの操作ボタン１４Ｂｃにより正規スケジュール情報の変更の旨を入力した場合、この入力にかかる情報が管理者対話部１４から分析スケジュール蓄積部１９へと送られ、スケジュール情報の修正候補の内容に基づき、予め生成されたスケジュール情報の内容が修正される。

このように、システム管理者は、大まかな内容のスケジュール情報を予め生成し、システム運用管理装置２が、その内容を相関変化分析に適した内容へと修正を行うため、システム管理者のスケジュール情報生成時の負担を大幅に軽減できる。

上記各部のその他の機能については、上述した第１の実施形態と同一である。

［第２の実施形態の動作］
次に、本発明の第２の実施形態におけるシステム運用管理装置２の動作について、上述した第１の実施形態と異なる部分を中心に、図１５、図１６に基づいて以下説明する。

図１５は、本発明の第２の実施形態における、スケジュール候補情報の生成の動作を示すフローチャートである。

先ず、上述した第１の実施形態のシステム運用管理装置１と同様に、性能情報収集部１１が、顧客用サービス実行システム３のサーバから定期的に性能情報を取得し、性能情報蓄積部１２に順次格納する。

次いで、相関モデル生成部１６は、予め外部より設定された時間間隔で相関モデルを生成する（図１５：ステップＳ３０１、相関モデル定期生成工程）。その後、生成された相関モデルを定期モデル蓄積部２０に順次格納する。

続いて、候補情報生成２１の共通相関判定部２１ａが、予め外部より設定された期間分の相関モデルを定期モデル蓄積部２０から取得する。そして、共通相関判定部２１ａは、取得したこれら相関モデルの内、生成された期間が連続する相関モデル同士を比較し、両者に共通する相関関係（相関関数等）を抽出していく（図１５：ステップＳ３０２、共通相関関係抽出工程）。

次に、静的要素変化点抽出部２１ｂが、上述した共通する相関関係の数の経時的変化を確認し（図１５：ステップＳ３０３）、その変化が予め外部より設定された基準範囲以内であるかを確認する（図１５：ステップＳ３０４）。

このとき、相関関数の数の変化が基準範囲以内であれば（ステップＳ３０４／イエス）、静的要素変化点抽出部２１ｂは、同じ相関モデルを用いて性能情報の分析をすべきと判断する。一方、相関関数の数の変化が基準範囲を超えた場合は（ステップＳ３０４／ノー）、静的要素変化点抽出部２１ｂは、その時点を相関変化分析のための相関モデルを切り替える時点であると判断し、この時点で分析期間を分割する（図１５：ステップＳ３０５、相関モデル分割工程）。

次に、動的要素類似度判定部２１ｃは、静的要素変化点抽出部２１ｂによる新しい分析期間における相関モデルに最新の相関モデルを一時的に割り当てる。その後、この分割点より前の分析期間に割当てられていた相関モデルの内容と前述の最新の相関モデルの内容とを比較し（図１５：ステップＳ３０６）、両者の類似度を確認する（図１５：ステップＳ３０７）。

このとき、予め設定された基準範囲を超えて両者が類似しているものと確認されたときは（ステップＳ３０7／イエス）、動的要素類似度判定部２１ｃは、この新しい分析期間の相関モデルとして、分割点より前の相関モデルを割り当てる（図１５：ステップＳ３０８、相関モデル割当て工程）。一方、基準範囲以下の類似度であると確認されたときは（ステップＳ３０7／ノー）、動的要素類似度判定部２１ｃは、この新しい分析期間の相関モデルとして、上述の一時的に割当てた相関モデルを割当てる。

次に、必要モデル群抽出部２１ｄは、静的要素変化点抽出部２１ｂ及び動的要素類似度判定部２１ｃにより相関モデルが割り当てられた各分析期間を基に、スケジュール候補情報を構築し、修正候補生成部２２のカレンダ特性判定部２２ｂへ送る（図１５：ステップＳ３０９、候補情報生成送信工程）。それと共に、必要モデル群抽出部２１ｄは、スケジュール候補情報の各分析期間に割り当てられた各相関モデルを、各分析期間に関連付けて、分析用モデル蓄積部１７に格納する。

図１６は、本発明の第２の実施形態における、スケジュール情報の修正候補の生成の動作を示すフローチャートである。

次に、カレンダ特性判定部２２ｂは、必要モデル群抽出部２１ｄからスケジュール候補情報を受取り（図１６：ステップＳ３１０、候補情報取得工程）、それと共にカレンダ情報蓄積部２２ａからカレンダ情報を取得する。そして、カレンダ特性判定部２２ｂは、スケジュール候補情報の内容とカレンダ情報の内容とを比較すると共に、スケジュール候補情報における各分析期間にカレンダ情報を当て嵌めることでカレンダ特性を決定する（図１６：ステップＳ３１１、カレンダ特性判定工程）。

次に、修正候補生成部２２ｃは、カレンダ特性判定部２２ｂにより決定されたカレンダ特性を受取り、そのカレンダ特性の内容と既に生成されているスケジュール情報の内容とを比較する（図１６：ステップＳ３１２）。

この比較の結果、カレンダ特性の内容が、既に作成されているスケジュール情報の内容から変化していると確認されたときは（ステップＳ３１３／イエス）、修正候補生成部２２ｃは、カレンダ特性を基にスケジュール情報の修正候補を生成し分析スケジュール蓄積部１９に格納する（図１６：ステップＳ３１４、修正候補生成格納工程）。そして、管理者対話部１４は、このスケジュール情報の修正候補をスケジュール蓄積部１９から取得し、外部に表示する（図１６：ステップＳ３１５、修正候補出力工程）。一方、上記比較の結果、カレンダ特性の内容が既存のスケジュール情報の内容から変化していないと確認されたときは（ステップＳ３１３／ノー）、修正候補生成部２２ｃは、スケジュール情報の修正候補を生成しない。

そして、外部からスケジュール情報の変更の旨が管理者対話部１４に入力された場合、管理者対話部１４は、当該入力にかかる情報を分析スケジュール蓄積部１９に送ると共に、相関変化分析に用いる正規のスケジュール情報を修正候補の内容に変更する。

その後、相関変化分析部１８は、分析用に取得された性能情報について、生成されたスケジュール情報に基づき相関変化分析を行う。

これ以降の工程については、上述した第1の実施形態と同じである。

ここで、上述した各工程で実行される具体的内容をプログラム化し、これをコンピュータに実行させるようにしてもよい。

［第２の実施形態の効果］
本発明の第２の実施形態によれば、システム運用管理装置２がスケジュール情報を生成するため、システム管理者の知識や経験が少なく、システム管理者がスケジュール情報を自ら生成することが困難な場合であっても、システム管理者は個々の業務パターンを正確に把握してスケジュール情報を逐一生成する必要がなく、その負担を大幅に軽減できる。

又、本発明の第２の実施形態によれば、システム運用管理装置２が顧客用サービス実行システム４の環境の変化を時々刻々読み取り、それに合せて臨機応変にスケジュール情報を生成するため、業務パターンが不規則であるためにこの業務パターンをスケジュール情報として登録することが難しい場合であっても、顧客用サービス実行システム４の変化に応じた相関モデルを自動的且つ的確に割り当てることが可能であり、常に実際の利用形態に応じた精度の高い分析結果を提供できる。

この効果が最も有効に働くケースとして、顧客用サービス実行システム４が複数部門で共通利用されるケースがある。

このケースでは、当該システムの利用者が複数存在するため、その利用パターンが複雑になる。しかしながら、上述したように本発明の第２の実施形態では、必要となる相関モデルの生成及び切替えが自動化されるため、不適切なスケジュール設定による分析結果の精度の低下が起こらず、常に適切な分析結果が維持される。これにより、管理対象システムの性能劣化に対する対処効率が向上する。

ここで、上述の説明では、システム運用管理装置２が、切り替えるべき相関モデルが検出された場合に、スケジュール情報の修正候補を作成すると共に、表示画面１４Ｂ（図１２）のように、既存のスケジュール情報と修正候補とを並べて表示し、システム管理者等のスケジュール情報の修正命令にかかる入力を受けて、スケジュール情報の修正を実行する。しかしながら、本発明はこの例に限定されるものではない。例えば、一定の範囲で、システム運用管理装置２がスケジュールを自動修正したり、システム管理者等の入力を受けて将来のスケジュール変更を計画したり、過去の性能データの分析を再実行してもよい。即ち、従来はシステム管理者が逐一生成しなければならなかったスケジュール情報をシステム運用管理装置が自動生成するものであれば、同様の効果が得られる。

［第３の実施形態］
次に、本発明に係る運用管理システムの第３の実施形態について、図１７乃至図１９に基づいて説明する。

図１７は、本発明のシステム運用管理装置の第３の実施形態の構成を示すブロック図である。

図１７に示すように、本発明の第３の実施形態におけるシステム運用管理装置３は、前述した第２の実施形態におけるシステム運用管理装置２と同様に、性能情報収集部１１と、性能情報蓄積部１２と、相関モデル生成部１６と、分析用モデル蓄積部１７と、相関変化分析部１８と、障害分析部１３と、管理者対話部１４と、対処実行部１５とを含む。性能情報収集部１１は、性能情報を顧客用サービス実行システム４から取得する。性能情報蓄積部１２は、取得された性能情報を格納する。相関モデル生成部１６は、取得された性能情報を基に相関モデルを生成する。分析用モデル蓄積部１７は、生成された相関モデルを格納する。相関変化分析部１８は、相関モデルを用いて取得した性能情報の異常性を分析する。障害分析部１３は、相関変化分析部１８による分析結果を基に顧客用サービス実行システム４の異常性を判断する。管理者対話部１４は、障害分析部１３による判断結果を出力する。対処実行部１５は、管理者対話部１４が出力した内容に対する改善指令の入力があったときに、その指令に基づき記顧客用サービス実行システム４の改善を行う。

又、図１７に示すように、本発明の第３の実施形態におけるシステム運用管理装置３は、前述した第２の実施形態におけるシステム運用管理装置２と同様に、分析スケジュール蓄積部１９と、定期モデル蓄積部２０と、候補情報生成部２１と、修正候補生成部２２とを含む。分析スケジュール蓄積部１９は、分析スケジュールを格納する。定期モデル蓄積部２０は、相関モデル生成部１６により定期的に生成された相関モデルを順次格納する。候補情報生成部２１は、定期モデル蓄積部２０に格納された性能情報を基にスケジュール情報の草案であるスケジュール候補情報を生成する。修正候補生成部２２は、スケジュール候補情報に暦上の属性を当て嵌めることによりスケジュール情報の修正候補を生成する。

更に、システム運用管理装置３は、図１７に示すように、適合モデル判定部２３を含む。適合モデル判定部２３は、相関変化分析部１８による相関変化分析の結果が複数ある場合に、それらの異常度の比較を行うことにより、各分析結果の異常度に基づく序列を決定する。

又、相関変化分析部１８、障害分析部１３、及び管理者対話部１４は、上述した各機能に加え、更に新たな機能を有している。以下、それらの機能について説明する。

相関変化分析部１８は、性能情報収集部１１から受取った性能情報について、スケジュール情報に従って割り当てられた相関モデルを用いた相関変化分析だけではなく、分析用モデル蓄積部１７に蓄積されている他の相関モデルを用いた相関変化分析も行う。

障害分析部１３は、適合モデル判定部２３から、スケジュール情報に従って割り当てられた相関モデルを用いた分析結果に加えて、上記他の相関モデルを用いた分析結果も受取り、障害分析を行うと共に、その結果を管理者対話部１４に送る。

管理者対話部１４は、障害分析部１３から受取ったスケジュール情報に従った分析結果と上記他の相関モデルによる分析結果を併せて表示する。加えて、この管理者対話部１４が、上記他の相関モデルを用いた分析結果を正規の分析結果とする旨の入力を受け、分析スケジュール蓄積部１９に格納されているスケジュール情報の内容を上記他の相関モデルの内容に基づいて修正する。

これにより、上述の第１及び第２の実施形態におけるスケジュール情報の内容について何らかの不具合があったとしても、他の相関モデルから好適な相関モデルを選んで相関変化分析に適用することにより、高精度の相関変化分析を実行できる。

なお、本発明の第３の実施の形態においては、モデル生成部３０が、相関モデル生成部１６と、候補情報生成部２１と、修正候補生成部２２と、適合モデル判定部２３とを含むものとする。また、分析部３１が、相関変化分析部１８と、障害分析部１３とを含むものとする。

本発明の第３の実施形態の内容について、上述した第１及び第２の実施形態と異なる部分を中心に、以下詳述する。

相関変化分析部１８は、性能情報収集部１１から分析用の性能情報を取得すると共に、分析スケジュール蓄積部１９からスケジュール情報を、分析用モデル蓄積部１７から予め設定された分析期間にかかる各相関モデルを取得する。

次に、相関変化分析部１８は、分析用の性能情報について、スケジュール情報に従って割り当てられた相関モデルを用いて相関変化分析を行う。更に、相関変化分析部１８は、分析用モデル蓄積部１７から取得した各種相関モデルを用いて相関変化分析を行う。

そして、相関変化分析部１８は、上述の相関変化分析による分析結果の全てを適合モデル判定部２３に送る。

適合モデル判定部２３は、相関変化分析部１８から受取った全ての分析結果についてその異常度（実測値と理論値との差）を比較し、各分析結果の序列を決める。

そして、適合モデル判定部２３は、スケジュール情報に従った分析結果よりも異常度の低い分析結果が、他の相関モデルを用いた分析結果の中に存在するか否かを確認する。確認の結果、そのような分析結果が存在した場合は、適合モデル判定部２３は、上記他の相関モデルを用いた分析結果を分析結果の代替案に決定すると共に、この分析結果の代替案にかかる相関モデルを適合モデルに決定する。なお、スケジュール情報に従った分析結果よりも異常度の低い分析結果が複数存在するときは、適合モデル判定部２３は、その中で最も異常度の低い分析結果を分析結果の代替案に決定してもよい。

最後に、適合モデル判定部２３は、スケジュール情報に従った分析結果と分析結果の代替案の両者を障害分析部１３に送る。

ここで、適合モデル判定部２３による各分析結果の異常度を比較する手法としては、例えば異常度が定常的に大きいか又は小さいかという情報から判断するという手法がある。

その一具体例として、図１０の２１ｃ２を参照に、相関モデルＡで性能情報分析された結果の一つである分析結果Ａ３と相関モデルＢで性能情報分析された結果の一つである分析結果Ｂ３とを比較するケースを考える。

両者を比較した結果、分析結果Ｂ３は、分析結果Ａ３よりも異常度の高い状態が長時間継続している（図１０、２１ｃ２）。よって、この場合、適合モデル判定部２３は、分析結果Ｂ３は適した分析結果ではないという判定を行う。そして、分析結果Ａ３の方がＢ３より異常度が定常的に小さいため、適合モデル判定部２３は、分析結果Ａ３の方がＢ３よりも適した分析結果であると判定する。

よって、仮にスケジュール情報に従って割り当てられた相関モデルがモデルＢ、その分析結果がＢ３であり、他の相関モデルによる分析結果として相関モデルＡを用いた分析結果Ａ３が存在するケースでは、適合モデル判定部２２は、分析結果Ａ３を分析結果の代替案として決定する。

障害分析部１３は、適合モデル判定部２３にて代替案が決定されたときは、この適合モデル判定部２３からスケジュール情報に従った分析結果と代替案の両方を受取り、スケジュール情報に従った分析結果について上述した障害分析を行った後に、両者を管理者対話部１４へと送る。

管理者対話部１４は、障害分析部１３からスケジュール情報に従った分析結果と代替案が送られてきたときは、その両方を受取ると共に両者を同時に表示する。

図１８は、本発明の第３の実施形態における、管理者対話部１４により表示される内容の一例を示す説明図である。

例えば、管理者対話部１４は、図１８の表示画面１４Ｃを表示する。

この表示画面１４Ｃは、異常度（実測値と相関関数による理論値との差）を示す現在の分析結果（スケジュール情報に従った分析結果）１４Ｃａを含む。また、表示画面１４Ｃは、上述した現在の分析結果のうち分析結果の代替案が存在する分析期間における分析結果と使用した相関モデルの情報１４Ｃｂ、及び、分析結果の代替案の分析結果と使用した相関モデルの情報１４Ｃｃを含む。さらに、表示画面１４Ｃは、正規の分析結果として現在の分析結果の代わりに、分析結果の代替案の方を採用する為の操作ボタン１４Ｃｄを含む。

これにより、システム管理者は、この表示画面１４Ｃに表わされた各種情報を基に、現在の分析結果（スケジュール情報に従った分析結果）で検出されている異常度に応じた改善指令を管理者対話部１４に入力できる。

更に、システム管理者は、性能情報の分析結果として現在の分析結果ではなく分析結果の代替案を正規の分析結果として採用する旨の指令を管理者対話部１４に入力することもできる（図１８、操作ボタン１４Ｃｄ）。

加えて、分析結果の代替案を分析結果として採用した場合には、管理者対話部１４は、分析スケジュール蓄積部１９に格納されている現行のスケジュール情報の内容を、適合モデルの内容に基づいて修正する（代替案を提示した分析期間に対応する相関モデルを適合モデルにより置き換える）。これにより、以降の分析結果の精度を向上させることができる。

上記各部のその他の機能については、上述した第２の実施形態と同一である。

［第３の実施形態の動作］
次に、本発明の第３の実施形態におけるシステム運用管理装置３の動作について、上述した第１及び第２の実施形態と異なる部分を中心に、図１９に基づいて以下説明する。

図１９は、本発明の第３の実施形態における、適合モデル判定部２３による動作を示すフローチャートである。

本発明の第３の実施形態におけるシステム運用管理装置３の動作のうち、スケジュール情報を生成するための各工程は、第２の実施形態と同じである。

続く相関変化分析の工程において、相関変化分析部１８は、性能情報収集部１１から分析用の性能情報を取得すると共に、分析用モデル蓄積部１７から蓄積されている相関モデルの内の予め設定された期間にかかる相関モデルの全てを取得する。

そして、相関変化分析部１８は、スケジュール情報に従って割り当てられた相関モデルを用いて性能情報の相関変化分析を行う（ステップＳ４０１、本来モデル分析工程）。

続いて、相関変化分析部１８は、分析用モデル蓄積部１７から取得した他の相関モデルを用いても性能情報の相関変化分析を行う（ステップＳ４０２、他モデル分析工程）。

そして、相関変化分析部１８は、スケジュール情報に従った分析結果と上記他の相関モデルを用いた分析結果の全てを適合モデル判定部２３に送る。

次に、適合モデル判定部２３は、スケジュール情報に従った分析結果と上記他の相関モデルを用いた分析結果とを比較する（ステップＳ４０３、適合モデル判定工程）。

その結果、上記他の相関モデルを用いた分析結果がスケジュール情報に従った分析結果よりも優れている（異常度が低い）ときは（ステップＳ４０４／イエス）、適合モデル判定部２３は、当該他の相関モデルを用いた分析結果をスケジュール情報に従った分析結果の代替案とする。そして、適合モデル判定部２３は、この分析結果の代替案にかかる当該他の相関モデルを適合モデルとすると共に、スケジュール情報に従った分析結果と分析結果の代替案を障害分析部１３に送る。

一方、上記他の相関モデルを用いた分析結果がスケジュール情報に従った分析結果よりも優れたものでないときは（ステップＳ４０４／ノー）、適合モデル判定部２３は、スケジュール情報に従った分析結果のみを障害分析部１３に送る。

次いで、障害分析部１３は、適合モデル判定部２３からスケジュール情報に従った分析結果と代替案を受取り、障害分析を行った後、障害分析の終了したスケジュール情報に従った分析結果と代替案を管理者対話部１４へ送る。

次に、管理者対話部１４は、障害分析部１３から受取ったスケジュール情報に従った分析結果と代替案との内容を表示する（ステップＳ４０５、代替案出力工程）。

そして、管理者対話部１４は、上述の表示内容を閲覧したシステム管理者等による対処命令にかかる入力を受け付けると共に、その入力にかかる情報を対処実行部１５に送る（ステップＳ４０６）。

更に、管理者対話部１４は、分析結果の代替案の方を正規のスケジュール情報として採用する旨の入力を受けたときは、分析スケジュール蓄積部１９に格納されている現行のスケジュール情報を適合モデルの内容に基づき修正する（代替案を提示した分析期間に対応する相関モデルを適合モデルにより置き換える）（ステップＳ４０７、スケジュール情報修正工程）。

これ以降、ステップＳ４０１以降の工程が、繰返し実行される。

ここで、上述した各工程で実行される具体的内容をプログラム化し、これをコンピュータに実行させるようにしてもよい。

［第３の実施形態の効果］
本発明の第３の実施形態によれば、顧客用サービス実行システム４の運用パターンが時々刻々変化するようなケース（即ち、必ずしもスケジュール情報で設定したとおりに顧客用サービス実行システム４が運用されないケース）においても、システム運用管理装置３は、高い精度で相関変化分析を実行できる。その理由は、システム運用管理装置３が、スケジュール情報にて割当てられていない他の相関モデルを用いた相関変化分析結果を出力し、一時的な運用パターンの乱れが生じたとしても、その乱れた運用パターン時にかかる相関モデルを用いた相関変化分析結果を分析結果の代替案として適用できるからである。

例えば、通常月末日に行われる業務が何らかの理由で前倒しされるようなことがあった場合であっても、本第３実施の形態によれば、「仮に月末日と見做せば正常である」といった分析結果の代替案を、スケジュール情報に従った分析結果と共に提示できる。このように、顧客用サービス実行システム４に突発的な運用パターンの違いが発生した場合にも、システム運用管理装置３は、適切な分析結果をシステム管理者に提示できる。

更に、本発明の第３の実施形態によれば、システム運用管理装置３が、適用モデルの内容に基づき、分析スケジュール蓄積部１９に格納されているスケジュール情報の内容を順次修正できるため、常にスケジュール情報の内容を最新の状態に更新でき、様々なシステムエラーに対して臨機応変に対処できる運用管理環境が得られる。

以上、上記各実施形態にて本発明を説明したが、本発明は上記各実施形態に限定されるものではない。

この出願は、２００９年１０月１５日に出願された日本出願特願２００９−２３８７４７を基礎とする優先権を主張し、その開示の全てをここに取り込む。

本発明に係るシステム運用管理装置、システム運用管理方法、及びプログラム記憶媒体は、上述のようにＷｅｂサービスや業務サービスといった種々の情報通信サービスを提供する情報処理装置に適用できる。この情報処理装置内はシステムの性能劣化を検知できることから、インターネット通信販売装置や社内情報装置のみならず、鉄道や航空機の座席予約発券装置や映画館の自動座席券購入装置のように大勢の顧客による利用が一時に集中して殺到するケースが想定される各種装置にも利用可能である。

１、２、３、１０１ システム運用管理装置
４ 顧客用サービス実行システム
１１ 性能情報収集部
１２ 性能情報蓄積部
１３ 障害分析部
１４ 管理者対話部
１５ 対処実行部
１６ 相関モデル生成部
１７ 分析用モデル蓄積部
１８ 相関変化分析部
１９ 分析スケジュール蓄積部
２０ 定期モデル蓄積部
２１ 候補情報生成部
２１ａ 共通相関判定部
２１ｂ 静的要素変化点抽出部
２１ｃ 動的要素類似度判定部
２１ｄ 必要モデル群抽出部
２２ 修正候補生成部
２２ａ カレンダ情報蓄積部
２２ｂ カレンダ特性判定部
２２ｃ 修正候補生成部
２３ 適合モデル判定部
３０ モデル生成部
３１ 分析部

Claims (21)

1. システムにおける複数種別の性能値を含む性能情報を時系列に格納する性能情報蓄積手段と、
   前記性能情報蓄積手段に格納された前記性能情報をもとに複数の期間毎に生成された、異なる前記種別の性能値間の相関関係を１以上含む相関モデルをもとに、同一の前記相関モデルが適用される１以上の期間を抽出し、当該抽出された１以上の期間に当該同一の前記相関モデルを割当てるとともに、当該抽出された１以上の期間に適合する暦上の属性を特定することにより、前記暦上の属性と前記相関モデルを関連付けるモデル生成手段と、
   入力された前記システムの前記性能情報と、当該性能情報が取得された期間の前記暦上の属性に対する前記相関モデルとを用いて、当該性能情報の異常検出を行う分析手段と、
   を含む、
   システム運用管理装置。
2. 前記分析手段は、前記性能情報に前記相関モデルを適用することにより算出される前記相関関係の相関破壊の数をもとに、異常検出を行う
   請求項１に記載のシステム運用管理装置。
3. 前記モデル生成手段は、前記性能情報蓄積手段に格納された所定期間の前記性能情報をもとに、前記所定期間に含まれる複数の期間毎の前記相関モデルを生成し、共通な相関関係を有する１以上の期間から成る分析期間を設定し、当該分析期間の期間毎に生成された前記相関モデルのいずれかを当該分析期間に割当てる
   請求項２に記載のシステム運用管理装置。
4. 前記モデル生成手段は、連続する２つの期間における前記相関モデルの間で共通する、前記相関関係の数の増減の度合が所定値以上の場合、前記所定期間を分割する分割点とし、前記分割点により分割された１以上の期間から成る前記分析期間を設定する
   請求項３に記載のシステム運用管理装置。
5. 前記モデル生成手段は、前記分析期間に設定された前記相関モデルに含まれる前記相関関係と、前記分析期間以外の他の分析期間に設定された前記相関モデルに含まれる前記相関関係とが類似している場合、当該分析期間に設定された前記相関モデルに当該他の分析期間に設定された前記相関モデルを割り当てる
   請求項４に記載のシステム運用管理装置。
6. 前記モデル生成手段は、複数の前記暦上の属性のそれぞれについて、前記性能情報蓄積手段に格納された当該暦上の属性を有する期間における前記性能情報を取得し、当該性能情報をもとに前記相関モデルを生成し、当該暦上の属性に対する前記相関モデルに設定する
   請求項２に記載のシステム運用管理装置。
7. 前記分析手段は、前記性能情報の異常検出を、当該性能情報が取得された期間の前記暦上の属性に対応する前記相関モデルと、当該相関モデル以外の他の相関モデルとを用いて行い、前記他の相関モデルを用いた異常検出についての異常の度合いが、当該性能情報が取得された期間の前記暦上の属性に対応する前記相関モデルを用いた異常検出についての異常の度合いよりも低い場合、当該他の相関モデルを当該暦上の属性に対する適合モデルとして選択する
   請求項１乃至６のいずれかに記載のシステム運用管理装置。
8. システムにおける複数種別の性能値を含む性能情報を時系列に格納し、
   前記性能情報をもとに複数の期間毎に生成された、異なる前記種別の性能値間の相関関係を１以上含む相関モデルをもとに、同一の前記相関モデルが適用される１以上の期間を抽出し、当該抽出された１以上の期間に当該同一の前記相関モデルを割当てるとともに、当該抽出された１以上の期間に適合する暦上の属性を特定することにより、前記暦上の属性と前記相関モデルを関連付け、
   入力された前記システムの前記性能情報と、当該性能情報が取得された期間の前記暦上の属性に対する前記相関モデルとを用いて、当該性能情報の異常検出を行う、
   システム運用管理方法。
9. 前記性能情報の異常検出を行う場合、前記性能情報に前記相関モデルを適用することにより算出される前記相関関係の相関破壊の数をもとに、異常検出を行う
   請求項８に記載のシステム運用管理方法。
10. 前記暦上の属性と前記相関モデルを関連付ける場合、所定期間の前記性能情報をもとに、前記所定期間に含まれる複数の期間毎の前記相関モデルを生成し、共通な相関関係を有する１以上の期間から成る分析期間を設定し、当該分析期間の期間毎に生成された前記相関モデルのいずれかを当該分析期間に割当てる
    請求項９に記載のシステム運用管理方法。
11. 前記暦上の属性と前記相関モデルを関連付ける場合、連続する２つの期間における前記相関モデルの間で共通する、前記相関関係の数の増減の度合が所定値以上の場合、前記所定期間を分割する分割点とし、前記分割点により分割された１以上の期間から成る前記分析期間を設定する
    請求項１０に記載のシステム運用管理方法。
12. 前記暦上の属性と前記相関モデルを関連付ける場合、前記分析期間に設定された前記相関モデルに含まれる前記相関関係と、前記分析期間以外の他の分析期間に設定された前記相関モデルに含まれる前記相関関係とが類似している場合、当該分析期間に設定された前記相関モデルに当該他の分析期間に設定された前記相関モデルを割り当てる
    請求項１１に記載のシステム運用管理方法。
13. さらに、複数の前記暦上の属性のそれぞれについて、当該暦上の属性を有する期間における前記性能情報を取得し、当該性能情報をもとに前記相関モデルを生成し、当該暦上の属性に対する前記相関モデルに設定する
    請求項９に記載のシステム運用管理方法。
14. 前記性能情報の異常検出を行う場合、前記性能情報の異常検出を、当該性能情報が取得された期間の前記暦上の属性に対応する前記相関モデルと、当該相関モデル以外の他の相関モデルとを用いて行い、前記他の相関モデルを用いた異常検出についての異常の度合いが、当該性能情報が取得された期間の前記暦上の属性に対応する前記相関モデルを用いた異常検出についての異常の度合いよりも低い場合、当該他の相関モデルを当該暦上の属性に対する適合モデルとして選択する
    請求項８乃至１３のいずれかに記載のシステム運用管理方法。
15. コンピュータに、
    システムにおける複数種別の性能値を含む性能情報を時系列に格納し、
    前記性能情報をもとに複数の期間毎に生成された、異なる前記種別の性能値間の相関関係を１以上含む相関モデルをもとに、同一の前記相関モデルが適用される１以上の期間を抽出し、当該抽出された１以上の期間に当該同一の前記相関モデルを割当てるとともに、当該抽出された１以上の期間に適合する暦上の属性を特定することにより、前記暦上の属性と前記相関モデルを関連付け、
    入力された前記システムの前記性能情報と、当該性能情報が取得された期間の前記暦上の属性に対する前記相関モデルとを用いて、当該性能情報の異常検出を行う、
    処理を実行させるプログラム。
16. 前記性能情報の異常検出を行う場合、前記性能情報に前記相関モデルを適用することにより算出される前記相関関係の相関破壊の数をもとに、異常検出を行う
    処理を実行させる請求項１５に記載のプログラム。
17. 前記暦上の属性と前記相関モデルを関連付ける場合、所定期間の前記性能情報をもとに、前記所定期間に含まれる複数の期間毎の前記相関モデルを生成し、共通な相関関係を有する１以上の期間から成る分析期間を設定し、当該分析期間の期間毎に生成された前記相関モデルのいずれかを当該分析期間に割当てる
    処理を実行させる請求項１６に記載のプログラム。
18. 前記暦上の属性と前記相関モデルを関連付ける場合、連続する２つの期間における前記相関モデルの間で共通する、前記相関関係の数の増減の度合が所定値以上の場合、前記所定期間を分割する分割点とし、前記分割点により分割された１以上の期間から成る前記分析期間を設定する
    処理を実行させる請求項１７に記載のプログラム。
19. 前記暦上の属性と前記相関モデルを関連付ける場合、前記分析期間に設定された前記相関モデルに含まれる前記相関関係と、前記分析期間以外の他の分析期間に設定された前記相関モデルに含まれる前記相関関係とが類似している場合、当該分析期間に設定された前記相関モデルに当該他の分析期間に設定された前記相関モデルを割り当てる
    処理を実行させる請求項１８に記載のプログラム。
20. さらに、複数の前記暦上の属性のそれぞれについて、当該暦上の属性を有する期間における前記性能情報を取得し、当該性能情報をもとに前記相関モデルを生成し、当該暦上の属性に対する前記相関モデルに設定する
    処理を実行させる請求項１６に記載のプログラム。
21. 前記性能情報の異常検出を行う場合、前記性能情報の異常検出を、当該性能情報が取得された期間の前記暦上の属性に対応する前記相関モデルと、当該相関モデル以外の他の相関モデルとを用いて行い、前記他の相関モデルを用いた異常検出についての異常の度合いが、当該性能情報が取得された期間の前記暦上の属性に対応する前記相関モデルを用いた異常検出についての異常の度合いよりも低い場合、当該他の相関モデルを当該暦上の属性に対する適合モデルとして選択する
    処理を実行させる請求項１５乃至請求項２０のいずれかに記載のプログラム。

Images