WO2016013056A1 - 計算機システムを管理する方法 - Google Patents

Abstract

　管理システムは、計算機システムの構成情報と、それぞれが、計算機システムで発生し得る１つ以上の条件イベントと、１以上の条件イベントの障害原因とされる結論イベントと、の関係を、構成要素種別によって示す、複数汎用ルールを保持する。管理システムは、計算機システムの構成変更の操作の実行を契機に、当該操作の対象の種別を結論イベントに含む第１汎用ルールを選択する。管理システムは、構成情報に基づき、第１汎用ルールを、１つ以上の条件イベントと結論イベントとの関係を構成要素識別子で示す第１解析ルール、に変換する。管理システムは、計算機システムにおいて障害が発生した場合に、障害原因を特定するために、第１解析ルールを参照する。

Description

計算機システムを管理する方法

　本発明は、計算機システムを管理する方法に関する。

　本技術分野の背景技術として、米国特許７１０７１８５号（特許文献１）がある。この文献には、「コンピュータ可読媒体上のコンピュータ実装方法は、症状に基づいて管理されたコンポーネントの複雑なシステムにおける問題の原因を決定するために提供される。問題元特定プロセスは、様々な活動に分割される。管理されるコンポーネント、それらの問題、症状、そして問題又は症状が伝搬する関係の種類の明示的構造非特異表現が生成され、実行可能なコンピュータコードによって操作することができる。データ構造は、システム内の管理されたコンポーネントの特定インスタンスの情報に基づいて、１又は複数の表現を組み合わせることによって、問題の原因を決定するために生成される。コンピュータ・コードが実行され、データ構造体を使用して１又は複数の症状から問題の原因を決定する。」と記載されている（要約参照）。

　本技術分野の背景技術として、特開２０１０－８６１１５号（特許文献２）がある。この文献には、「運用管理サーバにて、イベント情報取得対象の情報処理装置をイベント取得対象装置として構成情報に登録し、運用管理サーバに格納した複数のイベント情報か ら、予め格納したルールに適合するイベント情報を特定し、当該イベント情報が関連するネットワークサービスのサーバ装置を特定し、イベント情報を生成した クライアント情報処理装置で発生した当該イベントの要因がサーバ装置で発生したネットワークサービスに関するイベントであることを表示する。」と記載されている（要約参照）。

　本技術分野の背景技術として、国際公開２０１３／０４６２８７号（特許文献３）がある。この文献には、「大規模又は多数のイベント伝播モデルが必要な複雑な計算機システムを解析する際の因果律行列のサイズが大きくなり、管理計算機の記憶資源を大量に消費して いた。以上の課題を解決するため、計算機システムを管理する管理計算機は、トポロジと、イベント伝播モデルと、一つ以上の因果律を含む因果律情報と、を記 憶資源に格納し、管理計算機がイベントを解析又は検知した契機で、解析対象イベントに対応する所定の因果律が作成済みか否か判断し、未作成の場合はトポロジとイベント伝播モデルとに基づいて前記所定の因果律を作成する。」と記載されている（要約参照）。

米国特許７１０７１８５号 特開２０１０－８６１１５号 国際公開２０１３／０４６２８７号

　特許文献１や特許文献２のようなＥｖｅｎｔ　Ｃｏｒｒｅｌａｔｉｏｎ技術により障害を特定する場合、障害の影響が装置間でどのように波及するかを表したデータ構造を、装置間の接続関係に応じて予め構築できていないと、短時間で障害原因を特定できない。

　特許文献３は、障害発生時に障害の発生した装置に限定してデータ構造を構築しており、構築に要する時間自体は特許文献１や特許文献２に対して短くできる。しかし、特許文献３は、データ構造の構築を障害発生時に実施するために、障害が発生した時点で迅速に原因を特定できない。

　したがって、これら既存の公知技術を利用しても、障害発生時に迅速に障害回復を実現できないことが多く、運用管理者が障害からの回復を試みる場合のコスト増加を招き得る。

　本発明の代表的な一例は、監視の対象である複数ノード装置を含む計算機システムに接続された管理システムが、前記計算機システムを管理する方法である。前記管理システムは、前記計算機システムの構成情報と、それぞれが、前記計算機システムで発生し得る１つ以上の条件イベントと、当該１以上の条件イベントの障害原因とされる結論イベントと、の関係を、構成要素種別によって示す、複数汎用ルールを保持する。前記方法は、前記管理システムが、前記計算機システムの構成変更の操作の実行を契機に、当該操作の対象の種別を結論イベントに含む第１汎用ルールを、前記複数汎用ルールから選択し、前記管理システムが、前記構成情報に基づき、前記第１汎用ルールを、１つ以上の条件イベントと結論イベントとの関係を構成要素識別子で示す第１解析ルール、に変換し、前記管理システムが、前記計算機システムにおいて障害が発生した場合に、障害原因を特定するために、前記第１解析ルールを参照する、ことを含む。

　本発明の一態様は、障害が発生した際に、障害原因を迅速に特定できる。

実施例１による計算機システムの概念を示す図である。 計算機システムの物理的構成を示す図である。 実施例１で説明する状況を示す概念図である。 実施例１において、装置性能管理表の構成例を示す。 実施例１において、ファイルトポロジ管理表の構成例を示す。 実施例１において、ネットワークトポロジ管理表の構成例を示す。 実施例１において、ＶＭ構成管理表の構成例を示す。 実施例１において、イベント管理表の構成例を示す。 実施例１において、汎用ルールの構成例を示す。 実施例１において、汎用ルールの構成例を示す。 実施例１において、解析ルールの構成例を示す。 実施例１において、解析ルールの構成例を示す。 実施例１において、解析ルールの構成例を示す。 実施例１において、解析ルールの構成例を示す。 実施例１において、解析結果管理表の構成例を示す。 実施例１において、汎用プランリポジトリの構成例を示す図である。 実施例１において、対処プランの構成例を示す。 実施例１において、ルール・プラン対応管理表の構成例を示す図である。 実施例１において、構成変更操作に起因して障害原因解析ルール作成、対処プラン作成の処理を実施する際の処理の流れを示す図である。 実施例１において、図１５の処理の流れを具体化したフローチャートである。 実施例１において、図１５の処理の流れを具体化したフローチャートである。 実施例１において、操作実行履歴キューの構成例を示す図である。 実施例１において、ルール変換モジュールが構成変更操作の実施を契機に実行する解析ルール作成処理を示すフローチャートである。 実施例１において、プラン作成モジュールが構成変更操作の実施を契機に実行する、プラン作成処理を示すフローチャートである。 実施例１において、装置性能情報取得処理、解析ルール作成処理、対処プラン作成処理の流れを示すフローチャートである。 実施例１において、ルール変換モジュールが障害事象の発生を契機に実行する解析ルール生成処理を示すフローチャートである。 実施例１において、プラン作成モジュールが障害事象の発生を契機に実行する、プラン作成処理を示すフローチャートである。 実施例１において、画像表示モジュールが実行するプラン提示処理を示すフローチャートである。 実施例１において、メインモジュールが実行する、解析ルールと対処プランの削除処理を示すフローチャートである。 実施例１において、メインモジュールが定期的に実行する、解析ルールと対処プランの削除処理を示すフローチャートである。 実施例１において、管理サーバ計算機によって出力される対策プラン一覧画像の一例である。 実施例２において、メインモジュールが実行する、解析ルールと対処プランの事前作成処理を示すフローチャートである。

　以下、本発明の実施例を図面により詳細に説明する。尚、本発明は、以下で説明される実施形態に限定されるものではない。なお、以後の説明では「ａａａ表」、「ａａａリスト」、「ａａａＤＢ」、「ａａａキュー」等の表現にて本発明の情報を説明するが、これら情報はテーブル、リスト、ＤＢ、キュー、等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ａａａテーブル」、「ａａａリスト」、「ａａａＤＢ」、「ａａａキュー」等について「ａａａ情報」と呼ぶことがある。さらに、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いるが、これらについてはお互いに置換が可能である。

　以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信制御デバイス）を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は管理サーバ等の計算機、情報処理装置が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。

　また、各種プログラムはプログラム配布サーバや、計算機が読み取り可能な記憶メディアによって各計算機にインストールされてもよい。
　以後、情報処理システムを管理し、本願発明の表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理計算機が表示用情報を表示する場合は管理計算機が管理システムである、また、管理計算機と表示用計算機の組み合わせも管理システムである。また、管理処理の高速化や高信頼化のために複数の計算機で管理計算機と同等の処理を実現してもよく、この場合は当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含め）が管理システムである。

　本実施形態は、計算機システムの障害を管理する技術に関する。管理システムは、計算機システムに発生する障害の影響波及ルールと、発生した障害に対して実施するプランを事前に形式化しておく。形式化された影響波及ルールを汎用ルール、形式化されたプランを汎用プランとも呼ぶ。汎用ルール及び汎用プランは、構成要素種別によって定義される。

　計算機システムにおいて構成変更が実施された場合、管理システムは、構成変更に関係のある汎用ルールを、計算機システムの実際の接続関係に合わせて変換し、計算機システムの構成に即した影響波及ルールを作成する。当該ルールを、解析ルールとも呼ぶ。解析ルールは、計算機システムの構成要素識別子によってルールを示す。

　さらに、管理システムは、解析ルールにより指示される障害原因装置において障害が発生したと仮定し、障害回復のための実際の対処プランを、汎用プランと実際の計算機システム構成に基づいて作成する。対処プランは、計算機システムの構成要素識別子によってプランを示す。

　障害の発生時、管理システムは、構成変更時に事前に作成した解析ルールから、実際の障害発生状況と合致している解析ルールを選択し、選択した解析ルールにより障害原因を特定する。管理システムは、特定した障害原因に対応する対処プランを、構成変更時に事前に作成した対処プランから選択し、ユーザである運用管理者に提示する。

　計算機システムの構成が変更された場合、当該変更部分に起因して障害が発生する可能性が高い。本実施形態は、構成に関連する操作が実施された場合に、障害原因を特定して対策を講じる情報を、操作実施部分について予め用意する。したがって、障害が発生した際に、障害原因と障害原因を解消するための対処プランを、運用管理者に迅速に提示することができ、運用管理者が障害から回復するためのプランを選択して実行した場合に、障害回復までの時間を短縮できる。

　実施例１は、管理ソフトウェア（例えば、管理サーバ計算機において実行される）による障害原因候補の表示と、その原因候補から導出される障害回復手順の表示を記述する。

＜システム構成＞
　図１は、実施例１による計算機システムの概念を示す。当該計算機システムは、管理対象計算機システム１１と、計算機システム１１に対してネットワーク介して接続された管理サーバ計算機１０とを含んで構成される。

　本開示において、各モジュールはメモリのソフトウェアモジュールとして提供されてもよいし、ハードウェアモジュールとして提供されてもよい。また、各モジュールが行う処理が一つ以上のプログラムコードとして提供されてもよく、モジュール間の明確な境界が存在しなくてもよい。モジュールは、プログラムと読み替えてもよい。

　メインモジュール１００は、各モジュールの動作を制御する他、リポジトリを管理する。装置性能取得モジュール１１０と構成情報取得モジュール１２０とは、管理対象計算機システム１１を監視している。構成情報取得モジュール１２０は、管理対象計算機システム１１の構成が変更される度、構成情報リポジトリ１３０において、管理対象計算機システム１１の構成情報を更新する。

　構成変更実行モジュール１４５は、管理対象計算機システム１１に対して構成の変更を指示する。構成変更実行モジュール１４５は、管理対象計算機システム１１における構成変更が発生すると、解析ルールを作成するため、ルール変換モジュール１５０を呼び出す。

　なお、構成変更実行モジュール１４５が直接ルール変換モジュール１５０を呼び出してもよいし、後述するように、他のモジュールを介してルール変換モジュール１５０を呼び出してもよい。例えば、メインモジュール１００に構成変更を通知し、当該メインモジュール１００がルール変換モジュール１５０を呼び出してもよい。モジュールの呼び出しは、他のモジュールについて同様である。

　障害波及関係は予め定義されており、汎用ルールとしてルール化され、汎用ルールリポジトリ１５５に格納されている。ルール変換モジュール１５０は、構成情報リポジトリ１３０が示す構成変更に関係のある汎用ルールを汎用ルールリポジトリ１５５から選択し、計算機システムの実際の接続関係に合わせて変換し、解析ルールを作成する。解析ルールは、解析ルールリポジトリ１６５に格納される。

　ルール変換モジュール１５０は、対処プランを作成するため、プラン変換モジュール１８０を呼び出す。障害と対応するプランとの関係は、あらかじめ汎用プランとして形式化されている。汎用プランは、汎用プランリポジトリ１６０に格納されている。プラン変換モジュール１８０は、解析ルールにより指示される障害原因装置において障害が発生したと仮定し、障害回復のための対処プランを、汎用プランと構成情報リポジトリ１３０の構成情報に基づいて作成する。対処プランは、対処プランリポジトリ１７０に格納される。

　装置性能取得モジュール１１０は、動作中の管理対象計算機システム１１から、装置性能についての情報を随時取得する。装置性能取得モジュール１１０は、取得している性能情報から、管理対象計算機システム１１に障害が発生していることを検知すると、原因特定のために障害原因特定モジュール１４０を呼び出す。

　障害原因特定モジュール１４０は、予め作成されている解析ルールと装置性能取得モジュール１１１０が検知した障害事象とを利用することにより、障害原因の候補を特定する。

　プラン選択モジュール１７５は、予め作成されている対処プランから、障害原因特定モジュール１４０が特定した原因候補に対応する対処プランを選択する。画像表示モジュール１９０は、運用管理者に障害原因候補と、その候補に対応する対処プランを併せて表示する。

　図２は、本実施例における計算機システムの物理的構成例を示す。管理サーバ計算機１０は、計算機システムの運用を管理する。計算機システムは、ストレージ装置２１１、２１２、ホスト計算機２４１から２４３、管理サーバ計算機１０、ＷＥＢブラウザ起動サーバ計算機２５０と、ＩＰスイッチ２２１、２２２とを含み、それらが、ネットワーク２３０によって接続される。なお、図２に存在する装置の一部のみが存在し、又、図２に存在する装置が部分的に接続されていてもよい。

　ホスト計算機２４１から２４３は、例えば、それらに接続された、図示しないクライアント計算機からファイルのＩ／Ｏ要求を受信し、それに基づいてストレージ装置２１１、２１２へアクセスする。ホスト計算機２４１から２４３は、それらが互いにネットワーク２３０を介してプログラム間で通信を実施し、ファイルを交換する。そのために、ホスト計算機２４１から２４３は、ネットワーク２３０に接続するためのポート２５１から２５３をそれぞれ有する。

　ＷＥＢブラウザ起動サーバ計算機２５０は、ネットワーク２３０を介して、管理サーバ計算機１０の画像表示モジュール１９０と通信し、ＷＥＢブラウザ上に各種情報を表示する。図１に記載している画像表示モジュール１９０は、画像データを生成し、ＷＥＢブラウザ上で表示するために、ＷＥＢブラウザ起動サーバ計算機２５０に画像データを送信する。

　ユーザはＷＥＢブラウザ起動サーバ計算機２５０上のＷＥＢブラウザに表示された情報を参照することで、計算機システム内の装置を管理する。管理サーバ計算機１０と、ＷＥＢブラウザ起動サーバ計算機２５０とは、１台の計算機で構成されていてもよい。

　＜状況＞
　図３は、実施例１で説明する状況を示す概念図である。図３において、ＩＰスイッチＩＰＳＷ１およびＩＰＳＷ２は、それぞれ図２におけるＩＰスイッチ２２１およびＩＰスイッチ２２２に対応する。ＩＰスイッチ２２１は、ネットワーク２３０に接続するためのポート３５１から３５３を、ＩＰスイッチ２２２は、ネットワーク２３０に接続するためのポート３５４、３５５を有する。Ｓｅｒｖｅｒ１０、Ｓｅｒｖｅｒ１１、Ｓｅｒｖｅｒ２０は、それぞれ、図２におけるホスト計算機２４１から２４３を示しており、それぞれポート２５１から２５３を介してネットワーク２３０に接続している。

　この実施例で説明する状況では、それぞれのホスト計算機２４１から２４３上では、仮想化機構が動作しており、それぞれＨＯＳＴ１０からＨＯＳＴ１３で示される仮想マシン（ＶＭ）３１０から３１３が動作している。図示していないが、ＨＯＳＴ１０からＨＯＳＴ１３のＶＭ３１０から３１３上には、ＯＳがインストールされ、その上でウェブサービスが動作しているものとする。

＜管理サーバ計算機の内部構成＞
　図２に示すように、管理サーバ計算機１０は、ネットワーク２３０に接続するためのポート２０３、プロセッサ２０１、キャッシュメモリ等のメモリ２０２、ＨＤＤ等の二次メモリ２０４、を含む。メモリ２０２及び二次メモリ２０４は、それぞれ、揮発性メモリデバイス及び／又は不揮発性メモリデバイスで構成される。

　管理サーバ計算機１０は、さらに、後述する処理結果を出力するためのディスプレイ装置等の出力デバイス２０５と、ストレージ管理者が指示を入力するためのキーボード等の入力デバイス２０６とを含む。これらは、内部バスを介して相互に接続されている。

　メモリ２０２は、図１に示すモジュール及びデータに加え、他のモジュール及びデータを格納している。具体的には、メモリ２０２は、装置性能管理表４０、ファイルトポロジ管理表４５、ネットワークトポロジ管理表５０、ＶＭ構成管理表５５、イベント管理表６０、を格納する。

　メモリ２０２は、さらに、解析結果管理表７５、ルール・プラン対応管理表９０、操作実行履歴キュー９５を格納する。図１における構成情報リポジトリ１１３０は、ファイルトポロジ管理表４５、ネットワークトポロジ管理表５０、ＶＭ構成管理表５５を格納する。構成情報リポジトリ１１３０は、さらに、不図示の装置管理表を保持し、装置管理表は、装置それぞれの装置部位を示す。

　画像表示モジュール１９０は、入力デバイス２０６を介した管理者からの要求に応じ、取得した構成管理情報を出力デバイス２０５によって表示する。入力デバイスと出力デバイスは別々なデバイスでもよく、一つ以上のまとまったデバイスでもよい。

　管理サーバ計算機１０は、例えば、入力デバイス２０６としてキーボードとポインタデバイス等、出力デバイス２０５としてディスプレイやプリンタ等とを有しているが、これ以外の装置であってもよい。

　管理サーバ計算機１０が表示用情報を表示する場合は、管理サーバ計算機１０が管理システムであり、また、管理サーバ計算機１０と表示用計算機（例えば図２のＷＥＢブラウザ起動サーバ計算機２５０）の組み合わせも管理システムである。

＜装置性能管理表の構成＞
　図４は、管理サーバ計算機１０が有する装置性能管理表４０の構成例を示す。フィールド４０１は、管理対象となる機器の識別子である装置ＩＤを格納する。フィールド４０２は、管理対象機器内部の部位の識別子である装置部位ＩＤを格納する。フィールド４０３は、管理対象装置部位の性能情報のメトリック名称を格納する。フィールド４０４は、閾値異常を検知した機器のＯＳ種別を格納する。閾値異常を検知した機器は、閾値に基づいて異常であると判定された機器である。

　フィールド４０５は、管理対象装置から取得された、該当装置の装置部位の性能値を格納する。フィールド４０６は、性能値の正常範囲の上限もしくは下限である閾値（アラート実行閾値）を、ユーザからの入力を受けて格納する。フィールド４０７は、閾値が正常値の上限であるのか下限であるのかを示す。フィールド４０８は、性能値についての装置部位の状態を示し、性能値が正常値であるか異常値であるかを示す。

　例えば、図４の第１行目（１つ目のエントリ）は、以下のことを示す。ＨＯＳＴ１１上で動作するＷｅｂＳｅｒｖｉｃｅ１におけるレスポンスタイムが、現時点で、１５００ｍｓｅｃ（フィールド４０５参照）である。ＷｅｂＳｅｒｖｉｃｅ１のレスポンスタイムが１０ｍｓｅｃを超えた場合（フィールド４０６参照）に、管理サーバ計算機１０はＷｅｂＳｅｒｖｉｃｅ１が過負荷であると判定する。

　さらに、当該具体例では、性能値が異常値であると判定されている（フィールド４０８参照）ことが分かる。この値が異常値であると判定した場合、管理サーバ計算機１０は、後述のイベント管理表６０に、イベントとして異常状態を書きこむ。

　なお、図４では、管理サーバ計算機１０が管理するデバイスの性能値としてレスポンスタイムや単位時間当たりのＩ／Ｏ量やＩ／Ｏエラー率を例として挙げられているが、管理サーバ計算機１０が管理する性能値はこれ以外でもよい。

＜ファイルトポロジ管理表の構成＞
　図５は、管理サーバ計算機１０の有するファイルトポロジ管理表４５の構成例を示す。ファイルトポロジ管理表４５は、ボリュームとファイルシステムとの間の関係を示す。フィールド４５１は、ホストの識別子であるホストＩＤを格納する。ホストは、物理計算機又は仮想計算機である。

　フィールド４５２は、ホストが有するボリュームの識別子であるボリュームＩＤを格納する。フィールド４５３は、ボリュームがホスト上でマウントされているときの識別名称であるパス名を示す。

　フィールド４５４は、ホストが他のホストにパス名で示されるファイルシステムを公開している場合に、その公開先のエキスポート先ホストを示す。フィールド４５５は、エキスポート先ホストにおいて当該ファイルシステムがマウントされているパス名を示す。

　例えば、図５の第１行目（１つ目のエントリ）は、以下のことを示す。ホストＩＤがＨＯＳＴ１０のホストは、ボリュームＶＯＬ１０１を、／ｖａｒ／ｗｗｗ／ｄａｔａというパス名のパスにマウントしている。

　上記パス名のファイルシステムは、ＨＯＳＴ１１、ＨＯＳＴ１２、ＨＯＳＴ１３で示されるホストに公開されている。それぞれのホストにおいて、ボリュームＶＯＬ１０１を、は、／ｍｎｔ／ｗｗｗ／ｄａｔａ、／ｖａｒ／ｗｗｗ／ｄａｔａ、￥￥ｈｏｓｔ１￥ｗｗｗ＿ｄａｔａのパス名のパスにマウントされている。

＜ネットワークトポロジ管理表の構成＞
　図６は、管理サーバ計算機１０の有するネットワークトポロジ管理表５０の構成例を示す。フィールド５０１は、ネットワーク装置であるＩＰスイッチの識別子である装置ＩＤを格納する。フィールド５０２は、ＩＰスイッチが有するポートの識別子であるポートＩＤを格納する。フィールド５０３は、ポートが接続されている装置のＩＤを示す。フィールド５０４は、接続先装置における接続されているポートのＩＤを示す。

　例えば、図６の第１行目（１つ目のエントリ）は、以下のことを示す。装置ＩＤがＩＰＳＷ１であるＩＰスイッチの、ポートＩＤがポート１であるポートが、装置ＩＤがＳｅｒｖｅｒ１０であるサーバの、ポートＩＤがポート１０１であるポートに接続している。

＜ＶＭ構成管理表の構成＞
　図７は、管理サーバ計算機１０の有するＶＭ構成管理表５５の構成例を示す。フィールド５５１は、仮想マシン（ＶＭ）が動作する物理マシンのＩＤを格納する。フィールド５５２は、物理マシンで動作している仮想マシンのホストＩＤを格納する。

　例えば、図７の第１行目（１つ目のエントリ）は、以下のことを示す。物理マシンＩＤがＳｅｒｖｅｒ１０である物理サーバ上では、ホストＩＤがＨＯＳＴ１０である仮想マシンが動作している。

＜イベント管理表の構成＞
　図８は、管理サーバ計算機１０が有するイベント管理表６０の構成例を示す。イベント管理表６０は、後述する障害原因の特定及び解析ルールの生成において適宜参照される。フィールド６０１は、イベントの識別子であるイベントＩＤを格納する。イベントは、例えば、取得した性能値における閾値異常である。フィールド６０２は、イベントの発生した機器の識別子である装置ＩＤを格納する。フィールド６０３は、イベントの発生した機器内の部位の識別子を格納する。

　フィールド６０４は、イベントを検知したメトリックの名称を格納する。フィールド６０５は、イベントが検知された機器のＯＳ種別を格納する。フィールド６０６は、機器内の部位のイベント発生時の状態を格納する。フィールド６０７は、イベントが解析済みかどうかを示す。フィールド６０８は、イベントが発生した日時を格納する。

　例えば、図８の第１行目（１つ目のエントリ）は、以下のことを示す。管理サーバ計算機１０が、ＨＯＳＴ１１上で動作するＷｅｂＳｅｒｖｉｃｅ１におけるレスポンスタイムの閾値異常を検知し、そのイベントＩＤはＥＶ１である。

＜汎用ルールの構成＞
　図９Ａ、９Ｂは、管理サーバ計算機１０が有する汎用ルールリポジトリ１５５内の汎用ルールの構成例を示す。図９Ａ、９Ｂは、異なる汎用ルール示し、これらは、同様の構成を有する表６５Ａ、６５Ｂでそれぞれ表わされている。

　汎用ルールは、計算機システムを構成するノード装置で発生し得る１つ以上の条件イベントの組み合わせと、その条件イベントの組み合わせに対して障害原因とされる結論イベントと、の関係を示す。

　汎用ルールは、障害原因を特定するためのイベント伝播モデルに従い形成されており、ある障害の結果発生することが予想されるイベントの組み合わせと、その原因とを、”ＩＦ－ＴＨＥＮ”形式で記載する。なお、図９Ａ、９Ｂは、汎用ルールの例を示し、他の汎用ルールも汎用ルールリポジトリ１５５に格納され得る。

　フィールド６５３は、汎用ルールの識別子である汎用ルールＩＤを格納する。フィールド６５１は、”ＩＦ－ＴＨＥＮ”形式で記載した汎用ルールのＩＦ部（条件部）に相当する、観測事象を格納する。フィールド６５２は、”ＩＦ－ＴＨＥＮ”形式で記載した汎用ルールのＴＨＥＮ部（結論部）に相当する原因事象を登録する。観測事象及び原因事象は、構成要素の種別で記述されている。具体的には、装置種別及び装置部位種別により記述されている。装置種別及び装置部位種別はそれぞれ構成要素種別である。事象は、装置種別のみを示すこともある。

　フィールド６５４は、汎用ルールを実システムにマッチングする際に適用するトポロジを格納する。フィールド６５５は、条件部６５１のイベントに対するイベントＩＤを格納する。条件部６５１のイベントが検知された場合、結論部６５２のイベントが障害の原因である。結論部６５２のステータスが正常になれば、条件部６５１の問題も解決しているという関係にある。条件部６５１は、一つの原因イベント及び当該原因イベントから派生するイベントを示す。図９Ａ、９Ｂの例では、条件部６５１には２つのイベントが記述されているが、イベント数に制限はない。

　例えば、図９Ａの汎用ルール表６５Ａは、汎用ルールＩＤがＲＵＬＥ１である汎用ルールを示す。汎用ルール表６５Ａは、観測事象として、サーバ上で動作するＷｅｂサービスのレスポンスタイムの閾値異常と、ファイルサーバにおけるボリュームのＩ／Ｏエラー率の閾値異常とを定義する。汎用ルール表６５Ａは、上記二つのイベントが検知されている場合、ファイルサーバにおけるボリュームのＩ／Ｏエラー率の閾値異常が、原因と結論付けるとことを示す。

　つまり、ファイルサーバにおけるボリュームのＩ／Ｏエラー率の閾値異常が原因イベントであり、サーバ上で動作するＷｅｂサービスのレスポンスタイムの閾値異常は、当該原因イベントを起因としては派生するイベントである。なお、汎用ルールは、条件部６５１に含まれるイベントとして、ある構成要素が正常であることを定義してもよい。

＜解析ルールの構成＞
　図１０Ａから１０Ｄは、管理サーバ計算機１０が有する解析ルールリポジトリ１６５内の解析ルールの構成例を示す。図１０Ａから１０Ｄは、異なる解析ルール示し、これらは、同様の構成を有するテーブル７５Ａから７０Ｄでそれぞれ表わされている。

　解析ルールは、汎用ルールを計算機システムの実構成に依存する形式に変換した情報であり、汎用ルール（図９Ａ、９Ｂ）に、ファイルトポロジ管理表４５とネットワークトポロジ管理表５０の情報を適用することによって生成される。解析ルールは、ルール変換モジュール１５０により作成される。

　図１０Ａを参照して、解析ルールのテーブル構成を説明する。フィールド７０３は、解析ルールの識別子である解析ルールＩＤを登録する。フィールド７０４は、解析ルールの基となった汎用ルールのＩＤを格納する。

　フィールド７０１は、”ＩＦ－ＴＨＥＮ”形式で記載した解析ルールのＩＦ部（条件部）に相当する観測事象を登録する。フィールド７０２は、”ＩＦ－ＴＨＥＮ”形式で記載した解析ルールのＴＨＥＮ部（結論部）に相当する原因事象を登録する。観測事象及び原因事象は、構成要素の識別子で記述されている。具体的には、装置ＩＤ及び装置部位ＩＤにより記述されている。装置ＩＤ及び装置部位ＩＤはそれぞれ構成要素識別子である。事象は、装置ＩＤのみを示すこともある。

　フィールド７０５は、事前作成フラグを格納する。事前作成フラグは、当該解析ルールが、障害事象発生を契機として作成されたものでないことを示す。フィールド７０６は、最終参照日時を格納する。最終参照日時は、当該解析ルールが参照された最終の日時を示す。

　例えば、図１０Ａの解析ルール表７０Ａは、汎用ルールＩＤがＲＵＬＥ１である汎用ルール表６５Ａに、ファイルトポロジ管理表４５における第１エントリ（ＨＯＳＴ１０、ＨＯＳＴ１１）の情報を格納することにより生成される。

　具体的には、汎用ルール表６５Ａの装置種別のフィールドに、ＨＯＳＴ１１と、ＨＯＳＴ１０とが、格納される。ＨＯＳＴ１１、ＨＯＳＴ１０はＶＭであり、その装置種別はサーバとファイルサーバである。装置部位種別のフィールドに、ＨＯＳＴ１１が提供するＷＥＢＳＥＲＶＩＣＥ１と、ＨＯＳＴ１０が提供するＶＯＬＵＭＥ１０１が格納される。不図示の装置管理表は、装置と装置部位との関係を示し、装置管理表から、各装置の装置部位の情報が取得できる。装置性能管理表４０からも、各装置の装置部位の情報が取得できる。

　解析ルール表７０Ａは、解析ルールＩＤがＥＸＲＵＬＥ１－１で示される解析ルールが、汎用ルールＩＤがＲＵＬＥ１で示される汎用ルールから変換されたことを示す。さらに、解析ルール表７０Ａは、観測事象としてホスト計算機ＨＯＳＴ１１上のＷＥＢＷＥＲＶＩＣＥ１のレスポンスタイムの閾値異常と、ホスト計算機ＨＯＳＴ１０上のＶＯＬＵＭＥ１０１の単位時間のＩ／Ｏ量の閾値異常が検知されたとき、ＶＯＬＵＭＥ１０１の単位時間のＩ／Ｏ量の閾値異常が原因と結論付けられることを示す。

＜解析結果管理表の構成＞
　図１１は、管理サーバ計算機１０の有する解析結果管理表７５の構成例を示す。解析結果管理表７５は、障害イベントの発生の解析結果を格納する。フィールド７５１は、原因装置ＩＤを格納する。原因装置ＩＤは、障害原因解析処理において障害の原因と判定されたイベントの発生した機器の識別子である。フィールド７５２は、当該イベントの発生した機器内の部位の識別子である、原因部位ＩＤを格納する。フィールド７５３は、閾値異常を検知したメトリックの名称を格納する。

　フィールド７５４は、解析ルールにおいて条件部に記載されたイベントの発生割合を示す確信度を格納する。フィールド７５５は、イベントを障害の原因と判定した根拠となる解析ルールのＩＤを格納する。フィールド７５６は、検知イベントＩＤを格納する。検知イベントＩＤは、解析ルールにおいて条件部に記載されたイベントのうち、実際に発生したイベントのＩＤである。フィールド７５７は、解析を実行した日時を格納する。例えば、イベント発生に伴う障害解析処理を開始した日時を格納する。

　例えば、解析結果管理表７５における第１段目（１つ目のエントリ）は、解析ルールＥＸＲＵＬＥ１－１に基づき、管理サーバ計算機１０がＨＯＳＴ１０のＶＯＬＵＭＥ１で示されるボリュームのＩ／Ｏエラー率の閾値異常を障害原因と判定したことを示す。さらに、当該エントリは、その根拠としてイベントＩＤがＥＶ１及びＥＶ４で示されるイベントを検知したことを示す。そのため、当該エントリは、条件イベントの発生割合を示す確信度が、２／２であることを示す。

＜汎用プランの構成＞
　図１２は、管理サーバ計算機１０の有する汎用プランリポジトリ１６０の構成例を示す。汎用プランリポジトリ１６０は、計算機システムにおいて実行可能な機能の一覧を示す。フィールド８０１は、汎用プランの識別子である汎用プランＩＤを格納する。

　フィールド８０２は、各プランの詳細情報を格納し、具体的には、計算機システムにおいて実行可能な操作とその実行順の情報を格納する。各プランは、構成要素種別によって記述されている。たとえば、ホストの停止や起動、スイッチでの設定変更や、ストレージ装置でのボリューム移行やＶＭの移動などのプランを示す。

　フィールド８０３は、プランが要するコスト示し、フィールド８０４はプランを実行するための時間を示す。なお、図１２は、プランの例を示すに過ぎず、汎用プランリポジトリ１６０が格納するプランは、例示されたプランに限定されない。

＜対処プランの構成＞
　図１３は、管理サーバ計算機１０の有する対処プランリポジトリ１７０に格納される、対処プランの一例を示す。対処プランは、汎用プランを計算機システムの実構成に依存する形式に変換した情報であり、障害原因に対する具体的な処理内容を示す。対処プランは、構成要素識別子によって記述される。

　図１３に示す対処プラン表８５は、プラン変換モジュール１８０により作成される。プラン変換モジュール１８０は、汎用プランリポジトリ１６０から選択した汎用プランに対して、ファイルトポロジ管理表４５、ネットワークトポロジ管理表５０、ＶＭ構成管理表５５及び装置性能管理表４０から取得した情報を適用することによって、対処プランを生成する。

　対処プラン表８５は、プラン対象に対するプランの具体的内容を示す。具体的には、汎用プランＩＤ８５２、対処プランＩＤ８５３、解析ルールＩＤ８５４、事前作成フラグ８６０、最終参照日時８６１、プラン対象８６２、コスト８５８、時間８５９、のフィールドを含む。汎用プランＩＤフィールド８５２は、対処プランの基となった汎用プランの汎用プランＩＤを格納する。

　対処プランＩＤフィールド８５３は、対処プランの識別子である対処プランＩＤを格納する。解析ルールＩＤフィールド８５４は、変換されたプランが、どの障害原因に対するプランなのかを識別するための情報として、解析ルールの解析ルールＩＤを格納する。

　事前作成フラグフィールド８６０は、このプランが障害事象発生前に、予め作成されたものか否かを示す。本例では、構成変更に応じて作成されたものか否かを示す。最終参照日時フィールド８６１は、このプランが参照された最終の日時を示す。

　プラン対象フィールド８６２は、プランの実行対象装置のフィールド８５５、実行前構成情報のフィールド８５６、及びプランの実行後構成情報のフィールド８５７を含む。これらは、構成要素識別子で記述される。

　コストフィールド８５８及び時間フィールド８５９は、プランを実施することに対する作業量を記述する。なおコストおよび時間は、プランを評価する尺度であれば、作業量を表す値としていかなる値であってもよく、またプランを実施することによりどの程度改善するかという効果を含んでもよい。

　図１３の対処プラン表８５は、汎用プランリポジトリ１６０が示すＰＬＡＮ１（ＶＭ移動プラン）の例を示す。プラン実行対象装置のフィールド８５５は、ホストＩＤによって、移動対象ＶＭを示す。実行前構成情報フィールド８５６は、装置ＩＤによってＶＭの移動元装置を示す。実行後構成情報８５７は、装置ＩＤによってＶＭの移動先装置を示す。プラン変換モジュール１８０は、これらフィールドの情報を、ＶＭ構成管理表５５から取得する。

　コストフィールド８５８及び時間フィールド８５９は、それぞれ、ＶＭの移動に要するコスト及び時間を示す。プラン実行における作業量を示す値及びプランによる改善効果を示す値は、どのような方法で算出されてもよい。ここでは、図１２の汎用プランリポジトリ１６０に示すように、説明の簡単化のために、予め各プランに対して定義されているとする。

　図１３を参照してＰＬＡＮ１（ＶＭ移動プラン）の対処プラン例を説明した。図１２の汎用プランリポジトリ１６０が保持する他の汎用プランに対応する対処プランも、同様に生成される。

＜ルール・プラン対応管理表の構成＞
　図１４は、管理サーバ計算機１０の有するルール・プラン対応管理表９０の構成例を示す。ルール・プラン対応管理表９０は、汎用ルールＩＤで示されるルールと、そのルールを適用して障害原因を特定した場合に実施可能なプランとの関係を示す。実行可能なプランは、当該プランの実行によって障害が解消し得るプランである。

　ルール・プラン対応管理表９０は、汎用ルールＩＤフィールド９０１と、汎用プランＩＤフィールド９０２と、を含む。汎用ルールＩＤフィールド９０１は、汎用ルールの識別子である汎用ルールＩＤを格納する。汎用ルールＩＤは、汎用ルールリポジトリ１５５における汎用ルールＩＤと同様の識別子である。汎用プランＩＤフィールド９０２は、汎用プランの識別子である汎用プランＩＤを格納する。ここでの汎用プランＩＤは、汎用プランリポジトリ１６０における汎用プランＩＤと同様の識別子である。

＜構成情報及び性能情報の更新処理＞
　メインモジュール１００は、構成情報取得モジュール１２０に対し、例えばポーリング処理によって、計算機システム内のノード装置、例えば、ストレージ装置、ホスト計算機及びＩＰスイッチ等から、構成情報を定期的に取得するよう指示する。構成情報取得モジュール１２０は、ノード装置から構成情報を取得するとともに、ファイルトポロジ管理表４５、ネットワークトポロジ管理表５０、及びＶＭ構成管理表５５を更新する。

　メインモジュール１００は、装置性能取得モジュール１１０に対し、例えばポーリング処理によって、計算機システム内のノード装置から、装置性能情報を定期的に取得するよう指示する。装置性能取得モジュール１１０は、ノード装置から装置性能情報を取得するとともに、装置性能管理表４０を更新する。

　＜全体の流れ＞
　図１５のフローチャートは、管理サーバ計算機１０が、計算機システム１１の構成操作に起因して、障害原因の解析ルールを作成し、さらに、作成した解析ルールに対応する対処プランを作成する全体処理の流れを示す。

　管理サーバ計算機１０のメインモジュール１００は、構成変更実行モジュール１４５によって、計算機システム１１における構成変更操作が実施されたことを検知する（Ｓ１０１）。

　ここでは、構成変更実行モジュール１４５によって構成変更操作が実行されたことを前提とするが、それ以外のプログラムや、運用管理者の操作によって構成変更操作が実行されてもよい。構成変更操作は、計算機システム１１の何らかの構成を変更する操作であって、構成情報リポジトリ１３０内の情報の変化を伴ってもよいし、伴わなくてもよい。

　構成操作によって変更される構成を、構成情報取得モジュール１２０によって取得することを前提にしてもよいし、構成変更実行モジュール１４５自身によってメインモジュール１００に通知されてもよいし、それ以外の方法によってメインモジュール１００に通知されてもよく、その方法を限定されない。

　メインモジュール１００は、構成変更操作が実施された装置に関係する解析ルールと対処プランとを、解析ルールリポジトリ１６５と対処プランリポジトリ１７０から削除する（Ｓ１０２）。これにより、構成変更に伴い有効でなくなった解析ルール及び対処プランを削除できる。その後、操作実行対象の装置に対する障害原因の解析ルール作成処理及び対処プラン作成処理を実行する（Ｓ１０３）。

　本実施例は、構成変更操作の実行をトリガに、長時間を要する障害原因解析ルール作成処理及び対処プラン作成処理を実行する。これにより、障害発生の蓋然性が高い箇所に対する解析ルール及び対処プランを予め作成し、障害発生時の対応処理の時間を短縮できる。また、障害発生の蓋然性が高い箇所の解析ルールと対処プランを選択的に作成することで、これらの作成に要する時間を短縮できる。

　なお、メインモジュール１００は、障害原因解析ルール作成処理及び対処プラン作成処理の実行時間と、構成変更操作の実行時間とを見積もり、双方の実行時間を比較して、所定基準に基づいてステップＳ１０３をスキップしてもよい。

　図１６Ａ、１６Ｂのフローチャートは、図１５に示した流れを具体的に示す。ここに示した方法は一例である。本例において、構成変更実行モジュール１４５は、構成変更操作の実行を、メインモジュール１００に通知する。構成変更実行モジュール１４５は、通知される情報を、図１７に示すような操作実行履歴キュー９５に保持する。

　操作実行履歴キュー９５は、履歴のＩＤを格納するフィールド９５１と、実行対象の操作内容を格納するためのフィールド９５２を有する。操作実行履歴キュー９５は、実行操作の履歴が格納できれば、どのような構成でもよい。

　図１６Ａは、構成変更実行モジュール１４５が実行する構成変更操作の流れを示す。構成変更実行モジュール１４５は、実行対象の操作を開始する（Ｓ１５１）。構成変更実行モジュール１４５は、操作実行履歴キュー９５に実行対象の操作の情報を追加する（Ｓ１５２）。構成変更実行モジュール１４５は、実行対象の操作の実行完了を待つ（Ｓ１５３）。

　図１６Ｂは、メインモジュール１００が実行する構成操作の検知と、それに対する解析ルール作成処理及び対処プラン作成処理と、の流れを示す。本例では、メインモジュール１００は、定期的に構成操作の実行を監視している（Ｓ２０１）。操作実行履歴キュー９５にエントリがある場合（Ｓ２０２：ＹＥＳ）、メインモジュール１００は、格納されている各エントリに対して、次のステップＳ２０４からＳ２０６の処理を実施する（Ｓ２０３）。

　メインモジュール１００は、操作実行履歴キュー９５における先頭エントリを選択し、操作実行履歴キュー９５から削除する（Ｓ２０４）。当該エントリの選択順序は一例であって、特に限定されない。

　次に、メインモジュール１００は、構成変更操作が実施された装置に関係する解析ルールと対処プランを、解析ルールリポジトリ１６５と対処プランリポジトリ１７０から削除する（Ｓ２０５）。次に、メインモジュール１００は、他のプログラムを利用して、操作実行対象の装置に対する解析ルール作成処理と対処プラン作成処理を行う（Ｓ２０６）。

＜解析ルール作成処理（Ｓ１０３、Ｓ２０６、Ｓ６５８）＞
　図１８のフローチャートは、ルール変換モジュール１５０が実行する解析ルール作成処理の詳細を示す。ルール変換モジュール１５０は、メインモジュール１００から呼び出され、図１８に示す処理を実行する。なお、本フローチャートは、プラン変換モジュール１８０による対処プラン作成処理のステップを含むが、当該ステップの詳細は図１９を参照して後述される。

　図１８のフローチャートにおいて、ルール変換モジュール１５０は、汎用ルールリポジトリ１５５から汎用ルールを取得し（Ｓ２５１）、取得した汎用ルールそれぞれに対して、ステップＳ２５３からＳ２５８を繰り返して実行する（Ｓ２５２）。

　ルール変換モジュール１５０は、構成変更操作の対象装置の装置種別が、汎用ルールの結論部６５２のイベントとマッチするかを判定する（Ｓ２５３）。ここでは装置部位種別は問わない。管理サーバ計算機１０は、構成要素識別子と構成要素種別とを対応づける情報を構成情報リポジトリ１３０内に保持しており、当該情報を参照することで、対象装置の種別を決定する。

　装置内のいずれかの装置部位に変更が生じた場合、当該装置が、構成変更操作の対象装置である。上述のように、構成変更操作は、装置が自動的に実行する操作及び管理者が実行する操作を含む。

　例えば、移行元装置から移行先装置にボリュームを移動する場合、移行元装置及び移行先装置がそれぞれ操作対象装置である。移行元装置がＶＭである場合、当該ＶＭは操作対象装置である。ＶＭが動作している物理マシンも操作対象装置に含めてもよい。ＶＭ移動の例において、構成操作対象装置は、移動元物理マシン、移動先物理マシン、及び移動されるＶＭである。

　対象装置の種別が汎用ルールの結論部６５２のイベントにマッチする場合（Ｓ２５３：ＹＥＳ）、ルール変換モジュール１５０は、構成変更操作を起因とした解析ルールを作成する。

　本実施例は構成変更操作を起因として発生する障害のために、事前に解析ルールを作成する。汎用ルールの結論部６５２の条件イベントに現れるイベントは、そのイベントを発生させている装置が障害の原因になり得ることを示している。本例は、構成変更操作に起因した障害の発生を想定しており、構成変更操作の対象装置と汎用ルールの結論部の条件イベントとを比較する。

　解析ルールの作成は、次のステップＳ２５４からＳ２５８で実行される。ルール変換モジュール１５０は、対象装置に対して、汎用ルール表内の結論部フィールド６５２におけるイベントが示す関連を持つ、対象装置の装置部位を、構成情報リポジトリ１３０から取得する（Ｓ２５４）。本例では、ファイルトポロジ管理表４５、ネットワークトポロジ管理表５０、ＶＭ構成管理表５５から、必要な情報が取得される。

　ルール変換モジュール１５０は、対象装置と取得した装置部位の各組み合わせを作成する。結論部のイベントにマッチする装置及び装置部位の組み合わせを構成情報リポジトリ１３０から取得できない場合、当該汎用ルールに対応する解析ルールは作成されない。

　次に、ルール変換モジュール１５０は、構成情報リポジトリ１３０を参照して、関連を持つ装置と装置部位の組み合わせごとに、解析ルールを作成する（Ｓ２５５）。ルール変換モジュール１５０は、解析ルールリポジトリ１６５に同じ解析ルールが既に存在するかどうかを調べる（Ｓ２５６）。以下の処理により、解析ルールリポジトリ１６５が適切に更新される。

　同じ解析ルールが既に存在する場合（Ｓ２５６：ＹＥＳ）、ルール変換モジュール１５０は、解析ルールリポジトリ１６５における既存エントリの最終参照日時を更新する（Ｓ２５７）。同じ解析ルール存在しない場合（Ｓ２５６：ＮＯ）、ルール変換モジュール１５０は、解析ルールリポジトリ１６５に作成した解析を格納する。この際に、ルール変換モジュール１５０は、事前作成フラグを“ＹＥＳ”にセットする（Ｓ２５８）。

　例えば、図１６Ｂに示す流れの一例において、図１７に示す操作実行履歴キュー９５から履歴ＩＤがＥＸ１の”ＶＯＬＵＭＥ１０１マウント（ＨＯＳＴ１１）”が抽出され、それに対して図１８の処理が実施されたとする。なお、ＶＯＬＵＭＥ１０１は、ＨＯＳＴ１０に提供されている。

　ＨＯＳＴ１１は、変更が加えられる可能性がある操作対象装置である。ルール変換モジュール１５０は、ＨＯＳＴ１１を結論部に持つ汎用ルールを選択し、それらから障害原因の解析ルールを作成する。

　具体的には、ステップＳ２５２に示すように、ルール変換モジュール１５０は、全ての汎用ルールに対してステップＳ２５３からＳ２５８を繰り返す。選択された汎用ルールが、操作対象の装置であるＨＯＳＴ１１の装置種別（サーバ）にマッチする結論部のイベントを有する場合、ルール変換モジュール１５０は、当該汎用ルールを選択する。

　例えば、図９Ａに示す汎用ルール表６５Ａは、汎用ルールＲＵＬＥ１を示し、汎用ルールＲＵＬＥは、ファイルサーバのボリュームを結論部に持つ。したがって、汎用ルールＲＵＬＥ１は、操作対象の装置ＨＯＳＴ１１にマッチする結論部の条件イベントを有する。

　汎用ルールＲＵＬＥ１の結論部は、ファイルサーバに関連する装置部位としてＶＯＬＵＭＥを示す。ＨＯＳＴ１０とＶＯＬＵＭＥ１０１の組み合わせは、当該結論部のイベントにマッチする。したがって、ルール変換モジュール１５０は、汎用ルールＲＵＬＥ１から、解析ルールを作成する。

　なお、ルール変換モジュール１５０は、操作対象部位であるＶＯＬＵＭＥ１０１の装置である、ＨＯＳＴ１０についても解析ルールを作成してもよい。また、ルール変換モジュール１５０は、操作対象の装置及び装置部位の組み合わせに基づき、操作対象に対応する汎用ルールを選択してもよい。上記例において、ルール変換モジュール１５０は、ＨＯＳＴ１１とＶＯＬＵＭＥ１０１の組み合わせに結論部がマッチする汎用ルールのみを選択してもよい。

　図９Ａの示す汎用ルールに、ファイルトポロジ管理表４５とネットワークトポロジ管理表５０の各エントリの項目を挿入することで、ルール変換モジュール１５０は、図１０Ａから図１０Ｃに示す解析ルールを生成する。ルール変換モジュール１５０は、解析ルール表７０Ａから７０Ｃにおいて、事前作成フラグフィールド７０５に、“ＹＥＳ”を格納する。

　解析ルール作成が終了すると、メインモジュール１００は、解析ルールリポジトリ１６５に新規エントリが追加されたかどうかをチェックする（Ｓ２５９）。新規エントリが追加されている場合（Ｓ２５９：ＹＥＳ）、メインモジュール１００は、障害回復のための対処プラン作成処理（Ｓ２６０）を、プラン変換モジュール１８０に指示する。

＜対処プラン作成処理（Ｓ２６０、Ｓ５６３）＞
　図１９は、プラン変換モジュール１８０が実行する、プラン作成処理のフローチャートを示す。プラン変換モジュール１８０は、解析ルールリポジトリ１６５に存在する解析ルールのうち、新規追加された解析ルールそれぞれに対して、次に示す処理を実施する（Ｓ３０１）。

　プラン変換モジュール１８０は、解析ルールから、汎用ルールＩＤを取得する（Ｓ６３０２０）。次に、プラン変換モジュール１８０は、ルール・プラン対応管理表９０、及び汎用プランリポジトリ１６０を参照し、汎用ルールＩＤに対応する汎用プランＩＤを取得する（Ｓ６３０３０）。プラン変換モジュール１８０は、取得した汎用プランＩＤのプランに全てに対して、ステップ６３０５０からステップ６３０８０の処理を実施する（Ｓ６３０４０）。

　プラン変換モジュール１８０は、ファイルトポロジ管理表４５と、ネットワークトポロジ管理表５０と、ＶＭ構成管理表５５とを参照し、汎用プランに対応する対処プランを生成する（Ｓ６３０５０）。例えば、プラン変換モジュール１８０は、ＶＭ移動の汎用プランから対処プランを作成する場合、移動先となり得るサーバを、ＶＭ構成管理表５５から取得して汎用プランに適用する。

　プラン変換モジュール１８０は、対処プランリポジトリ１７０に同じ対処プランが既に存在するかどうかを調べる（Ｓ３０６）。以下の処理により、対処プランリポジトリ１７０が適切に更新される。

　同じ対処プランが既に存在する場合（Ｓ３０：ＹＥＳ）、プラン変換モジュール１８０は、対処プランリポジトリ１７０に存在する既存エントリの最終参照日時を更新し、対処プランテーブルの解析ルールＩＤフィールド８５４に、当該対処プランを作成する際に利用した解析ルールＩＤを追加する（Ｓ３０８）。

　同じ対処プランが存在しない場合（Ｓ３０６：ＮＯ）、プラン変換モジュール１８０は、対処プランリポジトリ１７０に新たに作成した対処プランを追加する。プラン変換モジュール１８０は、対処プランテーブルの事前作成フラグフィールド８６０に “ＹＥＳ”に設定し、解析ルールＩＤフィールド８５４に、当該対処プランを作成する際に利用した解析ルールのＩＤを追加する（Ｓ３０７）。

＜障害発生時の処理＞
　図２０は、メインモジュール１００が実行制御する、装置性能情報取得処理、イベント検知処理、障害原因特定処理、対処プラン作成処理の流れを示すフローチャートである。メインモジュール１００は、各処理を他のモジュールによって実行する。

　メインモジュール１００は、プログラム起動時、もしくは前回の装置性能情報取得処理から所定時間経過後するたびに、装置性能取得モジュール１１０に装置性能情報取得処理Ｓ３５１を実行するよう指示する。当該実行指示を繰り返し出す場合、指示間の期間は一定でなくてもよい。

　ステップＳ３５１において、装置性能取得モジュール１１０は、監視対象の各装置に対し、性能値を送信するように指示する。装置性能取得モジュール１１０は、受信した性能値を装置性能管理表４０の各エントリに格納する。

　装置性能管理表４０の更新後、装置性能取得モジュール１１０は、装置性能管理表４０の各エントリに対して、ステップＳ３５３からステップＳ３５５を実施する（Ｓ３５２）。装置性能取得モジュール１１０は、性能値が閾値を超えているか否かを判定する。前回に性能値を取得できている場合で、性能値のステータスが変化している場合（Ｓ３５４：ＹＥＳ）に、装置性能取得モジュール１１０は、イベント管理表６０にイベントを登録する（Ｓ３５５）。

　装置性能管理表４０の全ての性能値についてチェックを行った後、メインモジュール１００は、イベント管理表６０に新規登録されたイベントがあるか否か判定する（Ｓ３５６）。新規登録されたイベントがある場合（Ｓ３５６：ＹＥＳ）、新規登録されたイベントについて、ステップＳ３５８からＳ３６２までが実行される（Ｓ３５７）。

　メインモジュール１００からの指示に応じて、障害原因特定モジュール１４０は、解析ルールリポジトリ１６５において、対象イベントを結論部に持ち、事前作成フラグが“ＹＥＳ”の解析ルールを検索する（Ｓ３５８）。該当する解析ルールが存在する場合（Ｓ３５８：ＹＥＳ）、事前作成の解析ルールとそれに関連して作成された対処プランが利用される。

　障害原因特定モジュール１４０は、該当解析ルールの最終参照日時を更新する（Ｓ３５９）。次に、障害原因特定モジュール１４０は、解析ルールと発生イベント情報を、解析結果管理表７５に格納する（Ｓ３６０）。障害原因特定モジュール１４０は、解析ルールに対して、イベント管理表６０に登録された障害イベントのうち所定期間内に登録された障害イベントを対比する。障害原因特定モジュール１４０は、解析ルールの条件部に存在する種別の装置からイベントが発生している場合に、確信度を計算して解析結果管理表７５に書き出す。

　プラン選択モジュール１７５は、該当解析ルールのＩＤを利用して、対処プランリポジトリ１７０において関連する対処プランを検索する。プラン選択モジュール１７５は、該当する対処プランにおいて、最終参照日時を更新する（Ｓ３６１）。

　ステップＳ３５８において、該当する解析ルールが解析ルールリポジトリ１６５に存在しない場合（Ｓ３５８：ＮＯ）、イベント起因の解析ルール作成処理・対処プラン作成処理が実行される（Ｓ３６２）。

＜イベント起因の解析ルール作成（Ｓ３６２）＞
　図２１は、ルール変換モジュール１５０が実行する、イベント起因の解析ルール作成処理を示すフローチャートである。本フローチャートで示される処理は、障害イベントの検知に起因して実施されるが、その処理の多くは、図１８に示される構成変更操作に起因して事前に実施する処理と同一である。

　ルール変換モジュール１５０は、汎用ルールリポジトリ１５５から汎用ルールを取得し（Ｓ４０１）、取得した汎用ルールそれぞれに対して、ステップＳ２５３からＳ２５８を繰り返して実行する（Ｓ４０２）。

　ルール変換モジュール１５０は、対象のイベント情報における装置と装置部位とメトリックの組み合わせがルールの条件イベントとマッチするかを判定する（Ｓ４０３）。マッチする場合（Ｓ４０３：ＹＥＳ）、ルール変換モジュール１５０は、イベントを起因とした解析ルールを作成する。

　解析ルールの作成は、次のステップＳ４０４からＳ４０８で実行される。ルール変換モジュール１５０は、汎用ルール表内の条件部フィールド６５１における条件イベントに対応する装置及び装置部位のペアを、構成情報リポジトリ１３０から取得する（Ｓ４０４）。本例では、ファイルトポロジ管理表４５、ネットワークトポロジ管理表５０、ＶＭ構成管理表５５から、必要な情報が取得される。

　次に、ルール変換モジュール１５０は、関連を持つ組み合わせごとに、解析ルールを作成する（Ｓ４０５）。ルール変換モジュール１５０は、解析ルールリポジトリ１６５に同じ解析ルールが既に存在するかどうかを調べる（Ｓ４０６）。

　同じ解析ルールが既に存在する場合（Ｓ４０６：ＹＥＳ）、ルール変換モジュール１５０は、解析結果管理表７５に当該解析ルールの情報を格納する（Ｓ４０８）。その際に、ルール変換モジュール１５０は、解析ルールとイベント管理表６０に登録された障害イベントのうち所定期間内に登録されたものを比較し、解析ルールの条件部に存在する種別の装置からイベントが発生している場合に、確信度を計算して解析結果管理表７５に書き出す。

　同じ解析ルールが存在しない場合（Ｓ４０６：ＮＯ）、ルール変換モジュール１５０は、解析ルールリポジトリ１６５に作成した解析ルールを格納する。この際に、ルール変換モジュール１５０は、事前作成フラグを“ＮＯ”にセットする。さらに、ルール変換モジュール１５０は、ステップＳ４０８と同様の方法で、解析結果管理表７５に解析結果を格納する（Ｓ４０７）。

　例えば、図８に示すイベントＥＶ５が発生したとする。イベントＥＶ５は、ＩＰＳＷ１のポート１における、単位時間Ｉ／Ｏ量の閾値異常である。図９Ｂに示す汎用ルール表６５Ｂの条件部フィールド６５１に存在する条件イベントが、イベントＥＶ５にマッチする。

　ルール変換モジュール１５０は、ネットワークトポロジ管理表５０を利用し、図１０Ｄに示す解析ルール表７０Ｄを作成する。その結果、解析結果管理表７５の４エントリ目に示す解析結果が得られる。当該解析結果は、ＳＥＲＶＥＲ１０のポート１０１が原因であることを示す。

　障害原因解析が終了すると、メインモジュール１００は、解析ルールリポジトリ１６５に新規エントリが追加されたかどうかをチェックする（Ｓ４０９）。新規エントリが追加されている場合（Ｓ４０９：ＹＥＳ）、メインモジュール１００は、障害回復のための対処プラン作成処理（Ｓ４１０）を、プラン変換モジュール１８０に指示する。

＜対処プラン作成処理（Ｓ４１０）＞
　図２２は、プラン変換モジュール１８０が実行する、プラン作成処理を示すフローチャートである。本フローチャートで示される処理の流れは、障害イベントの検知に起因して実施されるが、その処理の多くは図１９に示される構成変更操作に起因して事前に実施される処理と同一である。ここでは、異なるステップのみ記載する。ステップＳ４５１からＳ４５５は、それぞれ、図１９のフローチャートにおけるステップＳ３０１からＳ３０５に相当する。

　プラン変換モジュール１８０は、対処プラン作成後、対処プランリポジトリ１７０に同じ対処プランが既に存在するかどうかを調べる（Ｓ４５６）。同じ対処プランが既に存在する場合（Ｓ４５６：ＹＥＳ）、対処プランリポジトリに存在する既存エントリに含まれる解析ルールＩＤ３３８３３に、プラン変換モジュール１８０は、当該対処プランを作成する際に利用した解析ルールのＩＤを追加する（Ｓ４５８）。

　同じ対処プランが存在しない場合（Ｓ４５６：ＮＯ）、プラン変換モジュール１８０は、対処プランリポジトリ１７０に登録する。プラン変換モジュール１８０は、事前作成フラグフィールドに“ＮＯ”をセットし、解析ルールＩＤフィールドに、この対処プランを作成する際に利用した解析ルールのＩＤを追加する（Ｓ４５７）。

＜プラン提示処理（Ｓ３６３）＞
　図２３は、画像表示モジュール１９０が実行する、プラン提示処理を示すフローチャートである。画像表示モジュール１９０は、解析結果管理表７５から障害原因と確信度情報を取得する（Ｓ５０１）。

　画像表示モジュール１９０は、障害原因のうち新規登録エントリそれぞれについて、ステップＳ５０３を実施する（Ｓ５０２）。ステップＳ５０３において、画像表示モジュール１９０は、障害原因エントリから解析ルールＩＤを選択し、その解析ルールＩＤを持つ対処プランを対処プランリポジトリ１７０から選択する。

　新規登録エントリ全てについてステップＳ５０３を実行した後、画像表示モジュール１９０は、障害原因と確信度と取得した対処プランの情報とを合わせて画像データを作成し、表示する（Ｓ５０４）。

　図２６は、ステップＳ５０４において出力される、対策プラン一覧画像の一例である。図２６の対策プラン一覧画像において、表示領域６２１は、計算機システムにおける障害発生時、管理者がその原因を追究して対策を実施する際に、その障害の原因の可能性のある部位と、その障害に対して取り得る対処プランの対応関係を表示する。プラン実行ボタン６２２は、対処プランを実行するための選択ボタンである。ボタン６２３は、画像表示をキャンセルするためのボタンである。

　障害原因と障害に対する対処プランの対応を表示する表示領域６２１は、障害原因の情報として、障害原因の装置のＩＤ、障害原因の装置部位のＩＤ、障害と判定されたメトリックの種別、解析ルールによると発生するはずのイベント数に対する、実際に発生したイベント数の割合を示す確信度情報を示す。画像表示モジュール１９０は、解析結果管理表７５から、障害原因（原因装置ＩＤ７５１、原因部位ＩＤ７５２、メトリック７５３）及び確信度７５４を取得することにより、これらの値を表示する。

　障害に対するプランの情報として、候補となる対処プラン、対処プラン実行にかかるコスト、対処プラン実行によりかかる時間、すなわち障害が残り続ける時間が示される。画像表示モジュール１９０は、対処プランから取得したプラン対象８６２、コスト８５８、時間８５９の情報を取得することにより、これらの値を表示する。

　なお、表示領域６２１は、候補となる対処プランそれぞれに対して、後述のプラン実行ボタン６２２を押下した際に実行する対処プランをユーザに選択させるためのチェックボックスを表示する。

　プラン実行ボタン６２２は、選択されたプランの実行を指示するためのアイコンである。プラン実行ボタン６２２を押下することにより、候補となる対処プランのうちチェックボックスにおいて選択されている一つの対処プランが実行される。管理サーバ計算機１０は、対処プランに対応づけられた具体的なコマンド群を実行することにより、対処プランを実現する。

　管理者に障害原因と対処プラン候補を合わせて表示することで、管理者に障害対応に必要な情報を与えると共に、管理者が望む対処プランを選択させることができる。なお、図２６の画像は一例であり、表示画像は、対処プラン実行にかかるコスト、対処プラン実行にかかる時間以外の、対処プランの特徴を示す情報を表示領域６２１にあわせて表示してもよく、他の表示態様に従ってもよい。たとえば、障害原因のみを提示してもよいし、対処プランの選択を受け付けなくてもよい。

＜解析ルール、対処プランの削除処理（Ｓ１０２、Ｓ２０５、Ｓ６５４）＞
　図２４は、メインモジュール１００が実行する、解析ルールと対処プランの削除処理を示すフローチャートである。このフローチャートは、構成変更操作対象の装置が指定されることにより実施される。

　メインモジュール１００は、解析ルールリポジトリ１６５の全ての解析ルールに対して、ステップＳ５５２からＳ５５５を実行する（Ｓ５５１）。まず、メインモジュール１００は、解析ルールリポジトリ１６５から、構成変更操作対象の装置を条件部に含む解析ルールを選択する（Ｓ５５２：ＹＥＳ）。構成変更操作の影響がある場合は、解析ルールの結論部に記述される装置だけでなく、条件部に記述される装置の構成も変化する可能性があるためである。

　解析ルールが、構成変更操作対象の装置を条件部に含む場合（Ｓ５５２：ＹＥＳ）、メインモジュール１００は、その解析ルールを解析ルールリポジトリ１６５から削除する（Ｓ５５３）。メインモジュール１００は、当該解析ルールのＩＤを含む対処プランを、対処プランリポジトリ１７０から選択し（Ｓ５５４）、選択した各対処プランについて、ステップＳ５５６からＳ５５８を実行する（Ｓ５５５）。

　まず、メインモジュール１００は、対象の解析ルールＩＤを対処プランから削除する（Ｓ５５６）。対処プランに含まれる解析ルールＩＤが無くなった場合（Ｓ５５７：ＹＥＳ）、メインモジュール１００は、対処プランを対処プランリポジトリ１７０から削除する（Ｓ５５８）。ここまでのステップにより、構成変更操作が実施される装置に関係する解析ルールと、それに関連した対処プランを削除できる。

　次に、メインモジュール１００は、構成変更操作対象の装置を、プラン対象に含む対処プランについての処理を行う。まず、メインモジュール１００は、対処プランリポジトリ１７０から、構成変更操作対象の装置を対象装置に含む対処プランを選択する（Ｓ５５９）。メインモジュール１００は、各対処プランについて、ステップＳ５６１からＳ５６３を実行する（Ｓ５６０）。

　まず、メインモジュール１００は、対処プランに含まれる解析ルールＩＤを取得する（Ｓ５６１）。次に、メインモジュール１００は、対処プランを対処プランリポジトリ１７０から削除する（Ｓ５６２）。メインモジュール１００は、ステップＳ５６１で取得した解析ルールＩＤを利用して、プラン作成処理を実施する（Ｓ５６３）。プラン作成処理は、図１９を参照して説明した処理と同様であるため、説明を省略する。

＜所定時間利用されない解析ルールと対処プランの削除処理＞
　本実施例は、障害原因解析に必要な解析ルールと対処に必要な対処プランを事前に作成した後、任意の方法で削除してもよい。例えば、作成後所定時間利用されない場合や、対処プラン実行に失敗した場合等の条件に基づき、メインモジュール１００は、関連する解析ルールや対処プランを削除してもよい。

　図２５には、メインモジュール１００が定期的に実行する、解析ルールと対処プランの削除処理を示すフローチャートである。メインモジュール１００は、まず、解析ルールリポジトリ１６５から、最終参照日時が特定の時刻より前の解析ルールを選択する（Ｓ６０１）。そして抽出した各解析ルールに対して、ステップＳ６０３からＳ６０９を実行する（Ｓ６０２）。

　まず、メインモジュール１００は、対象の解析ルールのＩＤを含む対処プランを対処プランリポジトリ１７０から選択する（Ｓ６０３）。選択した全ての対処プランの最終参照日時が特定の時間より前である場合（Ｓ６０４：ＹＥＳ）、メインモジュール１００は、解析ルールを削除する（Ｓ６０５）。

　メインモジュール１００は、全ての対処プランについて、ステップＳ６０７からＳ６０９を実行する（Ｓ６０６）。メインモジュール１００は、対象の解析ルールＩＤが対処プランに含まれていれば、当該解析ルールＩＤを当該対処プランから削除する（Ｓ６０７）。その結果として、対処プランに含まれる解析ルールＩＤが無くなった場合（Ｓ６０８：ＹＥＳ）、メインモジュール１００は、当該対処プランを対処プランリポジトリ１７０から削除する（Ｓ６０９）。

　上記例は、所定時間参照されていない解析ルールと、所定時間参照されていない対処プランと、を削除する。そのために、解析ルールや対処プランは、最終参照日時のフィールドを含む。削除のための方法は、この限りではない。削除の方法に合わせて必要とする任意のフィールドが、解析ルール及び対処プランに含まれる。

　以上本実施例によれば、構成変更操作を実施した段階で、その操作に関係して発生すると予測される障害に対する障害原因解析用のルールと、その原因に対処するためのプランを、あらかじめ用意することが可能である。これにより、障害発生時の障害原因の分析と対処プランの提示を迅速に行うことができる。障害発生時に運用管理者は対処プランの実行を決定できるため、障害発生時の運用管理コストを削減できる。

　上記例は、解析ルールと共に対処プランを、構成変更を契機として作成する。管理サーバ計算機１０は、対処プランを障害発生後に作成してもよい。管理サーバ計算機１０は、対処プランを管理者に提示することなく障害原因のみ表示してもよいし、障害原因及び対処プランの情報を提示することなく、自装置が選択した対処プランを自動実行してもよい。管理サーバ計算機１０は、上記解析ルール及び対処プランの削除処理を実行しなくてもよいし、一方の処理のみを行ってもよい。

　以下では、実施例１との差異を中心に説明し、実施例１と同等の構成要素、同等の機能を持つプログラム、同等の項目を持つテーブルについては、説明を省略する。

　実施例１は、何らかの構成変更操作が実施された段階で、その操作に関係して発生する障害に対する解析ルール及び対処プランを作成する。図１６Ａに示すように、実施例１は、操作実行順に解析ルール及び対処プランを作成する。実行例２は、対処プラン実行時に対処プランに含まれる操作に基づき解析ルール及び対処プランを作成する。

　運用管理者は、図２６に示す対策プラン一覧画像より、候補となる対処プランを選択し、プラン実行ボタン６２２の押下により、選択した対処プランを実行する。実施例２は、当該選択操作に基づき、解析ルール及び対処プランを作成する。

　運用管理者が選択した対処プランを実行する際に、その対処プランに含まれるいくつもの操作の対象になる装置は、そうでない装置に比べ障害が発生し易い。この考えに基づき、実施例２は、対処プランに含まれる装置ごとに、その装置を含む操作の数をカウントし、操作数の多い順に解析ルール作成と対処プラン作成を実行する。これにより、より障害の発生し易い機器に対して、優先的に解析ルール及び対処プランを事前準備できる。

　図２７は、解析ルールと対処プランの事前作成処理を示すフローチャートである。まず、メインモジュール１００は、プラン実行ボタン６２２されたことを検知する（Ｓ６５１）。次に、メインモジュール１００は、選択された対処プランに含まれる装置を、対処プランリポジトリ１７０から選択する（Ｓ６５２）。選択した各装置について、ステップＳ６５４及びＳ６５５が実行される（Ｓ６５３）。

　メインモジュール１００は、装置に関係する解析ルールと対処プランを、解析ルールリポジトリ１６５と対処プランリポジトリ１７０とから削除する（Ｓ６５４）。これは、図２４に示す削除処理と同様である。当該ステップは、実行しようとする対処プランの対象となる装置に対する事前作成の解析ルール及び対処プランの削除である。次に、メインモジュール１００は、対処プラン内で装置が含まれる操作数をカウントする（Ｓ６５５）。

　全ての装置に対してステップＳ６５４及びＳ６５５が終了すると、メインモジュール１００は、対処プランに含まれる装置を操作数の多い順に整列する（Ｓ６５６）。ステップＳ６５６で整列した順に、ステップＳ６５８が実行される（Ｓ６５７）。

　ステップＳ６５８において、ルール変換モジュール１５０及びプラン変換モジュール１８０は、選択した装置に対する解析ルール作成及び対処プラン作成処理を実行する。解析ルール作成処理及び対処プラン作成処理は、図１８及び図１９に示したフローと同様であり、説明を省略する。

　以上本実施例によれば、実施例１での構成変更操作に起因した解析ルール及び対処プランの事前作成に加え又は代えて、対処プラン実行時にプラン実行に影響を受けやすい装置に対する解析ルール及び対処プランを事前作成できる。実施例１は、各構成変更操作間に関連はなく実行順に解析ルール及び対処プランを生成する。一方、プラン実行の場合はプランの範囲内での操作については連続実行されることがあらかじめ予測できるため、本実施例は、操作が多く実施され障害の発生の可能性の高いと考えられる装置から順に優先的に解析ルール及び対処プランを生成できる。

　管理サーバ計算機１０は、実行順序の優先度を、操作数と異なる基準で決定してもよい。たとえば、対処プランの操作の実行順序、過去の履歴から計算される障害発生確率の高い順序、又は接続する他の構成要素が多い順序、に基づき、実行順序の優先度を決定してもよい。

　なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明したすべての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

　また、上記の各構成・機能・処理部等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード等の記録媒体に置くことができる。

　また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしもすべての制御線や情報線を示しているとは限らない。実際には殆どすべての構成が相互に接続されていると考えてもよい。

Claims (15)

1. 　監視の対象である複数ノード装置を含む計算機システムに接続された管理システムが、前記計算機システムを管理する方法であって、
   　前記管理システムは、
   　前記計算機システムの構成情報と、
   　それぞれが、前記計算機システムで発生し得る１つ以上の条件イベントと、当該１以上の条件イベントの障害原因とされる結論イベントと、の関係を、構成要素種別によって示す、複数汎用ルールを保持し、
   　前記方法は、
   　前記管理システムが、前記計算機システムの構成変更の操作の実行を契機に、当該操作の対象の種別を結論イベントに含む第１汎用ルールを、前記複数汎用ルールから選択し、
   　前記管理システムが、前記構成情報に基づき、前記第１汎用ルールを、１つ以上の条件イベントと結論イベントとの関係を構成要素識別子で示す第１解析ルール、に変換し、
   　前記管理システムが、前記計算機システムにおいて障害が発生した場合に、障害原因を特定するために、前記第１解析ルールを参照する、ことを含む方法。
2. 　請求項１に記載の方法であって、
   　前記管理システムは、障害原因を解消するためのプランを構成要素種別によって示す、複数汎用プランを保持し、
   　前記方法は、
   　前記管理システムが、前記第１解析ルールの作成を契機に、第１解析ルールの前記第１解析ルールに対応する第１汎用プランを前記複数汎用プランから選択し、
   　前記管理システムが、前記第１解析ルール及び前記構成情報に基づき、前記第１汎用プランを、前記計算機システムにおける障害原因に対するプランを構成要素識別子で示す第１対処プランに変換する、方法。
3. 　請求項２に記載の方法であって、
   　前記管理システムが、前記第１解析ルールにより特定された障害原因と前記第１対処プランとを関連付けて表示する、ことを含む方法。
4. 　請求項３に記載の方法であって、
   　前記管理システムが、前記第１対処プランのユーザによる選択を検知し、
   　前記管理システムが、前記第１対処プランの実行における操作対象に対して、規定基準に基づく優先度を付与し、
   　前記管理システムが、前記優先度の順で、前記第１対処プランの実行における前記操作対象の解析ルール及び対処プランを作成する、ことを含む方法。
5. 　請求項４に記載の方法であって、
   　前記管理システムが、前記第１対処プランの実行における操作数に基づいて、前記操作対象に対して前記優先度を付与する、方法。
6. 　請求項２に記載の方法であって、
   　前記管理システムは、
   　前記複数汎用ルール及び前記構成情報に基づき作成された複数解析ルール、を格納する解析ルールリポジトリと、
   　前記複数解析ルール、前記構成情報、及び前記複数汎用ルールに基づき作成された複数対処プラン、を格納する対処プランリポジトリと、を保持し、
   　前記複数対処プランそれぞれは、最終参照日時を示す情報を含み、
   　前記方法は、
   　前記管理システムが、前記解析ルールリポジトリから第２解析ルールを選択し、
   　前記管理システムが、前記第２解析ルールに対応する全ての対処プランを前記対処プランリポジトリから選択し、
   　前記管理システムが、前記全ての対処プランそれぞれの最終参照日時に基づき、前記第２解析ルールを前記解析ルールリポジトリから削除するか否か判定する、ことを含む方法。
7. 　請求項１に記載の方法であって、
   　前記管理システムは、前記複数汎用ルール及び前記構成情報に基づき作成された複数解析ルールを格納する解析ルールリポジトリを保持し、
   　前記方法は、
   　前記管理システムが、前記計算機システムの構成変更の操作を検知し、
   　前記管理システムが、検知された前記操作に関係する解析ルールを前記解析ルールリポジトリから削除する、ことを含む方法。
8. 　請求項１に記載の方法であって、
   　前記管理システムは、前記複数汎用ルール及び前記構成情報に基づき作成された複数解析ルール、を格納する解析ルールリポジトリを保持し、
   　前記複数解析ルールそれぞれは、最終参照日時を示す情報を含み、
   　前記方法は、
   　前記管理システムが、前記複数解析ルールそれぞれ最終参照日時に基づき、前記解析ルールリポジトリから削除する解析ルールを選択する、ことを含む方法。
9. 　監視の対象である複数ノード装置を含む管理対象計算機システムと、
   　前記管理対象計算機システムに接続され、前記管理対象計算機システムを管理する管理システムと、を含み、
   　前記管理システムは、
   　前記管理対象計算機システムの構成情報と、
   　それぞれが、前記複数ノード装置で発生し得る１つ以上の条件イベントと、前記１以上の条件イベントの障害原因とされる結論イベントと、の関係を、構成要素種別によって示す、複数汎用ルールを保持し、
   　前記管理対象計算機システムの構成変更の操作の実行を契機に、当該操作の対象の種別を結論イベントに含む第１汎用ルールを、前記複数汎用ルールから選択し、
   　前記構成情報に基づき、前記第１汎用ルールを、１つ以上の条件イベントと結論イベントとの関係を構成要素識別子で示す第１解析ルール、に変換し、
   　前記管理対象計算機システムにおいて障害が発生した場合に、障害原因を特定ために、前記第１解析ルールを参照する、システム。
10. 　請求項９に記載のシステムであって、
    　前記管理システムは、
    　障害原因を解消するためのプランを構成要素種別によって示す、複数汎用プランを保持し、
    　前記第１解析ルールの作成を契機に、前記第１汎用ルールに対応する第１汎用プランを前記複数汎用プランから選択し、
    　前記管理システムが、前記第１解析ルール及び前記構成情報に基づき、前記第１汎用プランを、前記管理対象計算機システムにおける障害原因に対するプランを構成要素識別子で示す、第１対処プランに変換し、
    　前記管理システムが、前記第１解析ルールにより特定された障害原因と前記第１対処プランとを関連付けて表示する、システム。
11. 　請求項１０に記載のシステムであって、
    　前記管理システムは、
    　前記複数汎用ルール及び前記構成情報に基づき作成された複数解析ルール、を格納する解析ルールリポジトリと、
    　前記複数解析ルール、前記構成情報、及び前記複数汎用ルールに基づき作成された複数対処プラン、を格納する対処プランリポジトリと、を保持し、
    　前記複数対処プランそれぞれは、最終参照日時を示す情報を含み、
    　前記管理システムは、
    　前記解析ルールリポジトリから第２解析ルールを選択し、
    　前記第２解析ルールに対応する全ての対処プランを前記対処プランリポジトリから選択し、
    　前記全ての対処プランそれぞれの最終参照日時に基づき、前記第２解析ルールを前記解析ルールリポジトリから削除するか否か判定する、システム。
12. 　請求項１０に記載のシステムであって、
    　前記管理システムは、
    　前記第１対処プランのユーザによる選択を検知し、
    　前記第１対処プランの実行における操作対象に対して、規定基準に基づく優先度を付与し、
    　前記優先度の順で、前記第１対処プランの実行における前記操作対象の解析ルール及び対処プランを作成する、システム。
13. 　請求項１２に記載のシステムであって、
    　前記管理システムは、前記第１対処プランの実行における操作数に基づいて、前記操作対象に対して前記優先度を付与する、システム。
14. 　請求項９に記載のシステムであって、
    　前記管理システムは、
    　前記複数汎用ルール及び前記構成情報に基づき作成された複数解析ルール、を格納する解析ルールリポジトリを保持し、
    　前記管理対象計算機システムの構成変更の操作を検知し、
    　検知された前記操作に関係する解析ルールを前記解析ルールリポジトリから削除する、システム。
15. 　請求項９に記載のシステムであって、
    　前記管理システムは、前記複数汎用ルール及び前記構成情報に基づき作成された複数解析ルール、を格納する解析ルールリポジトリを保持し、
    　前記複数解析ルールそれぞれは、最終参照日時を示す情報を含み、
    　前記管理システムは、前記複数解析ルールそれぞれ最終参照日時に基づき、前記解析ルールリポジトリから削除する解析ルールを選択する、システム。

Images