JPWO2014068659A1 - 管理計算機およびルール生成方法 - Google Patents

Abstract

複数のノード装置を監視する管理計算機であって、第１の障害に関連する第１の管理オブジェクトの種別の情報および前記第１の障害によって発生したと推定される第２の障害に関連する第２の管理オブジェクトの種別の情報を取得し、前記第２の管理オブジェクトの種別から前記第１の管理オブジェクトの種別までの関連を辿り、条件部および結論部を含むメタルールを生成し、前記管理オブジェクトの種別の辿り方に基づいて、前記管理オブジェクトの種別の関連によって構成されるトポロジの情報を取得する方式を生成し、前記生成された方式に基づいてトポロジの情報を取得し、前記生成されたメタルールおよび前記取得したトポロジの情報から展開ルールを生成する。

Description

本願明細書に開示される技術は、計算機システムの運用管理方法に関する。

計算機システムを管理する場合、システム内で検知した複数の障害または障害の兆候の中から、原因となる事象が検出されている。具体的には、米国特許第７１０７１８５号明細書に開示されるように、管理ソフトウェアを用いて、管理対象装置または管理対象装置を構成するコンポーネントにおける各種障害をイベント化し、イベントＤＢ（データベース）にイベントの発生情報を蓄積する。また、この管理ソフトウェアは、管理対象装置において発生した複数のイベントの因果関係を解析するための解析エンジンを持っている。この解析エンジンは、管理対象装置の構成情報を持つ構成管理ＤＢにアクセスして、あるＩ／Ｏ（入出力）経路上のパス上にある一つまたは複数の管理対象装置に跨る複数のコンポーネント間の関係を「トポロジ」と呼ばれる１つのグループとして認識する。そして、解析エンジンは、イベントが発生すると、イベントが発生したコンポーネントを含むトポロジに、事前に定められた条件文および解析結果からなるメタルールを適用して、各トポロジの障害を解析するための展開ルールを構築する。この展開ルールには、根本原因となり得る結論イベントと、結論イベントが発生した場合に引き起こされる条件イベント群が含まれる。具体的には、ルールのＴＨＥＮ部に記載されているイベントが根本原因となり得る結論イベント、ＩＦ部に記載されているイベントが条件イベントである。

米国特許第７１０７１８５号明細書

米国特許第７１０７１８５号明細書に開示された障害解析システムでは、あるパターンのトポロジにおいて発生し得るイベントの組み合わせと、そのトポロジのパターンにおいて障害の原因候補となるイベントとの対応関係をＩＦ−ＴＨＥＮ形式のルール（以下、メタルールと呼ぶ）を複数用意する。

そして、各メタルールが適用可能なトポロジのパターンを持つ管理対象装置群の構成情報を構成管理ＤＢから検索し、管理対象装置で発生し得るイベント（どの装置で発生するかの具体的な情報を含む）の組み合わせと、その組み合わせでイベントが発生した場合の障害の原因候補となるイベント（原因装置の情報を含む）との対応関係を示したＩＦ−ＴＨＥＮ形式のルール（以下、展開ルールと呼ぶ）を生成する。

障害解析システムは、展開ルールのＩＦ部に記載された条件イベントの発生率を計算することによって、ＴＨＥＮ部に記載された原因候補の確信度を算出する。算出した確信度と原因候補は、ユーザの求めに応じＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を介して表示される。また、ＩＦ部に記載された条件イベントをＴＨＥＮ部に記載された原因候補に対する影響範囲として合わせて表示する。これにより、ユーザは受信したイベントがどの障害に起因して発生しているものかを知ることができる。

しかしながら、このような従来の障害解析システムにおいては、あらかじめ障害解析のためのＩＦ−ＴＨＥＮ形式のルールが存在しないと、ユーザにとって適切な解析結果を表示できない。すなわち、受信したイベントに対応するルールをあらかじめ用意していないと、正しく解析がされないことになる。そのため、管理対象システムでの障害に対して正しく解析するためには、不足しているルールを解析対象となるシステムの運用管理者が追加しなければならない。

しかし、メタルールを追加する場合には、メタルールを適用可能なトポロジを構成管理ＤＢから検索する手段を作成する必要がある。そのため、運用管理者がメタルールを追加するためには、構成管理ＤＢのデータモデルなど、障害解析システムで構成情報がどのように管理されているかの理解が必要になる。

また、管理対象装置内のコンポーネントや、コンポーネントの相互関係に関する型を定義し、それらを組み合わせてＩＴシステムのモデルを宣言することで、ＩＴシステムのポリシーを定義する方法が公知となっている。しかし、この方法では、型を定義した者とＩＴシステムのモデルを宣言する者が同じでない場合、モデルを宣言する者は、各々の型の意味の理解が必要になる。また、宣言したモデルに当てはまる、実際の管理対象装置を検出する手段をどのように生成するかについては提案されていない。

さらに、ネットワーク状況に応じて有効なポリシールールを自動的に適用する技術が公知となっている。しかし、この技術では、管理対象装置に対してポリシールールを記述している。そのため、大規模なＩＴシステムにおいては入力するルールの数が非常に多くなる。

本願において開示される発明の代表的な一例は、管理オブジェクトの種別の関連を辿ることによって、障害を解析するために用いるメタルールを生成する管理計算機である。

すなわち、本願において開示される発明の代表的な一例は、複数のノード装置を監視する管理計算機であって、前記管理計算機は、プロセッサおよび記憶資源を有し、前記記憶資源は、前記ノード装置に含まれるコンポーネントの種別を含むコンポーネントの構成情報を格納し、前記ノード装置および前記コンポーネントは、管理オブジェクトとして管理されており、前記プロセッサは、原因と推定される第１の障害に関する第１の管理オブジェクトを特定するための情報と前記第１の障害の種別との組、および、前記第１の障害によって発生したと推定される第２の障害に関する第２の管理オブジェクトを特定するための情報と前記第２の障害の種別との組の入力を受信し、前記第１の管理オブジェクトの種別の情報および前記第２の管理オブジェクトの種別の情報を取得し、前記第２の管理オブジェクトの種別から前記第１の管理オブジェクトの種別までの関連を辿り、前記管理オブジェクトの種別と前記障害の種別との組によって定まる少なくとも一つの条件要素からなる条件部、および、原因と推定される管理オブジェクトの種別と障害の種別との組からなる結論部を含むメタルールを生成し、前記第２の管理オブジェクトの種別から前記第１の管理オブジェクトの種別までの辿り方に基づいて、前記第２の管理オブジェクトの種別から前記第１の管理オブジェクトの種別までの関連によって構成されるトポロジの情報を取得する方式を生成し、前記生成された方式に基づいてトポロジの情報を取得し、前記生成されたメタルールおよび前記取得したトポロジの情報から展開ルールを生成し、新たな障害を検知した場合、前記生成した展開ルールに基づいて、前記検知された障害を解析することを特徴とする。

本発明の実施形態によれば、ユーザが障害解析用のルールを作成するための作業工数を減らすことができる。

前述した以外の課題、構成および効果は、以下の実施形態の説明により明らかにされる。

本発明の第１の実施例の情報システムのハードウェアアーキテクチャおよび論理構成の例を示すブロック図である。 本発明の第１の実施例の情報システムのハードウェアアーキテクチャおよび論理構成の例を示すブロック図である。 本発明の第１の実施例のイベントテーブルのデータ構造の例を説明する図である。 本発明の第１の実施例のメタルールリポジトリに常駐するメタルールの例を説明する図である。 本発明の第１の実施例の構成管理ＤＢに含まれるテーブルのうち、管理オブジェクトの種別がサーバである装置の構成情報を示すテーブルを説明する図である。 本発明の第１の実施例の構成管理ＤＢに含まれるテーブルのうち、管理オブジェクトの種別がＦＣスイッチである装置の構成情報を示すテーブルを説明する図である。 本発明の第１の実施例の構成管理ＤＢに含まれるテーブルのうち、管理オブジェクトの種別がストレージである装置の構成情報を示すテーブルを説明する図である。 本発明の第１の実施例の構成管理ＤＢに含まれるテーブルのうち、管理オブジェクトの種別がＨＢＡであるコンポーネントの構成情報を示すテーブルを説明する図である。 本発明の第１の実施例の構成管理ＤＢに含まれるテーブルのうち、管理オブジェクトの種別がディスクドライブであるコンポーネントの構成情報を示すテーブルを説明する図である。 本発明の第１の実施例の構成管理ＤＢに含まれるテーブルのうち、管理オブジェクトの種別が論理ボリュームであるコンポーネントの構成情報を示すテーブルを説明する図である。 本発明の第１の実施例の構成管理ＤＢに含まれるテーブルのうち、管理オブジェクトの種別がＲＡＩＤグループであるコンポーネントの構成情報を示すテーブルを説明する図である。 本発明の第１の実施例の構成管理ＤＢに含まれるテーブルのうち、管理オブジェクトの種別がストレージポートであるコンポーネントの構成情報を示すテーブルを説明する図である。 本発明の第１の実施例の構成管理ＤＢに含まれるテーブルのうち、管理オブジェクトの種別がストレージディスクであるコンポーネントの構成情報を示すテーブルを説明する図である。 本発明の第１の実施例の構成管理ＤＢに含まれるテーブルのうち、管理オブジェクトの種別がＦＣスイッチポートであるコンポーネントの構成情報を示すテーブルを説明する図である。 本発明の第１の実施例の情報システムの管理オブジェクトの関連を示すクラス図である。 本発明の第１の実施例の関連テーブルのデータ構造の例を説明する図である。 本発明の第１の実施例の関連テーブルのデータ構造の例を説明する図である。 本発明の第１の実施例のトポロジ取得方式の例を説明する図である。 本発明の第１の実施例のトポロジ取得方式の例を説明する図である。 本発明の第１の実施例のトポロジ取得方式に対応して生成されるＳＱＬ文を説明する図である。 本発明の第１の実施例のトポロジ取得方式に対応して生成されるＳＱＬ文を説明する図である。 本発明の第１の実施例のトポロジ取得方式に対応して生成されるＳＱＬ文を説明する図である。 本発明の第１の実施例の展開ルールリポジトリに格納される展開ルールの例を説明する図である。 本発明の第１の実施例の展開ルールリポジトリに格納される展開ルールの例を説明する図である。 本発明の第１の実施例の展開ルールリポジトリに格納される展開ルールの例を説明する図である。 本発明の第１の実施例のメタルール生成処理の例のフローチャートである。 本発明の第１の実施例のメタルール生成処理の例のフローチャートである。 本発明の第１の実施例の原因イベント選択画面の例を説明する図である。 本発明の第１の実施例の影響イベント選択画面の例を説明する図である。 本発明の第１の実施例のトポロジ探索処理の例のフローチャートである。 本発明の第１の実施例の関連探索処理の例のフローチャートである。 本発明の第１の実施例の関連探索処理の例のフローチャートである。 本発明の第１の実施例のメタルール候補生成処理の例のフローチャートである。 本発明の第１の実施例のメタルール候補生成処理の例のフローチャートである。 本発明の第１の実施例のトポロジ取得方式選択処理の例のフローチャートである。 本発明の第１の実施例のメタルール検証情報表示処理の例のフローチャートである。 本発明の第１の実施例のメタルール検証情報表示処理の例のフローチャートである。 本発明の第１の実施例のルール展開処理の例のフローチャートである。 本発明の第１の実施例の障害解析処理の例のフローチャートである。 本発明の第１の実施例の障害解析処理の例のフローチャートである。 本発明の第２の実施例のメタルール生成処理の例のフローチャートである。 本発明の第２の実施例のイベント情報入力画面の例を説明する図である。 本発明の第２の実施例のトポロジ探索処理の例のフローチャートである。 本発明の第２の実施例の関連探索処理の例のフローチャートである。 本発明の第２の実施例のメタルール候補生成処理の例のフローチャートである。 本発明の第３の実施例の関連テーブルのデータ構造の例を説明する図である。 本発明の第３の実施例の関連テーブルのデータ構造の例を説明する図である。 本発明の第３の実施例のトポロジ取得方式選択処理の例のフローチャートである。 本発明の第３の実施例のトポロジ取得方式選択処理の例のフローチャートである。 本発明の第３の実施例のトポロジ取得方式選択処理の例のフローチャートである。 本発明の第３の実施例の関連テーブルのデータ構造の例を説明する図である。 本発明の第３の実施例の関連テーブルのデータ構造の例を説明する図である。 本発明の第３の実施例で生成される不要な展開ルールの例を説明する図である。 本発明の第３の実施例で生成される不要な展開ルールの例を説明する図である。 本発明の第３の実施例で生成される不要な展開ルールの例を説明する図である。 本発明の第３の実施例で生成される不要な展開ルールの例を説明する図である。 本発明の第３の実施例で生成される不要な展開ルールの例を説明する図である。 本発明の第３の実施例で生成される不要な展開ルールの例を説明する図である。

以下の本発明の詳細な説明において、開示の一部をなす添付図面を参照するが、これらは本発明を実施できる例示的な実施形態を示すものであって、本発明の範囲を限定するものではない。これらの図面において、複数の図を通じて同一の符号は同一の構成要素を示す。さらに、詳細な説明は各種の例示的な実施形態を提供するが、以下に記述および図示するように、本発明は本明細書に記述および図示する実施形態に限定されるものではなく、当業者には公知または将来公知となる他の実施形態に拡張できる点に注意されたい。

本明細書において「一実施形態」または「本実施形態」または「本実施例」に言及する場合、当該実施形態との関連で記述されている特定の特徴、構造または特性は、本発明の少なくとも一つの実施形態に含まれることを意味しており、本明細書の各所でこれらの語句が出現しても、必ずしも全て同一の実施形態を指している訳ではない。

また、以下の詳細な説明において、本発明が完全に理解されるよう多くの具体的な詳細事項を開示している。しかし、当業者には明らかなように、本発明を実施するために、これらの具体的な詳細事項の全てが必要とされるものではない。他の状況において、本発明を無用に分かり難くしないよう、公知の構造、材料、回路、処理およびインターフェースについては詳細に記述せず、および／またはブロック図の形式で示す場合がある。

さらに、以下に詳細な説明のある部分は、コンピュータ内部の動作のアルゴリズム的記述または記号的表現として示す。これらのアルゴリズム的記述および記号的表現は、データ処理技術に精通した当業者が自身の発明の本質を他の当業者に最も効果的に伝達するために用いる手段である。アルゴリズムとは、所望の最終状態または結果に達する一連の定義されたステップである。本発明において、実行されるステップは、有形の結果を実現するための有形の量を物理的に操作することを要求する。

但し、通常は必須ではないが、これらの量は、保存、転送、結合、比較、および他の操作が可能な電気または磁気の信号の形式をなす。原理的に共通に利用できるとの理由で、これらの信号をビット、値、要素、記号、文字、項目、数、命令等と称することが往々にして便利であることが分かっている。しかし、これらの全ておよび同様の項目は、適切な物理量に関連付けられるべきものであり、これら物理量に付けられた便宜的なラベルに過ぎないことに留意すべきである。

特に別途明言しない限り、以下の記述から明らかなように、本明細書の記述を通じて、「処理する」、「計算する」、「算出する」、「判定する」、「表示する」等の用語を用いた説明は、コンピュータシステムまたは当該コンピュータシステムのレジスタおよびメモリ内の物理的（電子的）な量として表現されたデータを操作して、当該コンピュータシステムのメモリまたはレジスタまたは他の情報記憶、伝送または表示装置内の物理量として同様に表現された他のデータに変換する他の情報処理装置の動作および処理を含んでいてよい。

また、本発明は本明細書における動作を実行する装置に関する。この装置は、必要な目的のために特別に構築されてもよいし、または、一つ以上のコンピュータプログラムにより選択的に起動または再設定される一つ以上の汎用コンピュータを含んでもよい。そのようなコンピュータプログラムは、例えば、光ディスク、磁気ディスク、読出専用メモリ、ランダムアクセスメモリ、固体装置（solid-state device）およびドライブ等のコンピュータ可読記憶媒体、または電子情報の保存に適している他の任意の媒体に保存できるが、これらに限定されない。

なお、以後の説明では「ａａａテーブル」、「ａａａリスト」、「ａａａＤＢ」、「ａａａキュー」等の表現にて本発明の情報を説明するが、これら情報は、必ずしもテーブル、リスト、ＤＢ、キュー、等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ａａａテーブル」、「ａａａリスト」、「ａａａＤＢ」、「ａａａキュー」等について「ａａａ情報」と呼ぶことがある。

さらに、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いるが、これらについてはお互いに置換が可能である。

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

また、各種プログラムはプログラム配布サーバや、計算機が読み取り可能な記憶メディア(computer-readable memory mediaと翻訳させたいです)によって各計算機にインストールされてもよい。

なお、管理計算機は入出力デバイスを有する。入出力デバイスの例としてはディスプレイとキーボードとポインタデバイスが考えられるが、これ以外のデバイスであってもよい。また、入出力デバイスの代替としてシリアルインターフェースやイーサーネットインターフェースを入出力デバイスとし、当該インターフェースにディスプレイまたはキーボードまたはポインタデバイスを有する表示用計算機を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力デバイスでの入力および表示を代替してもよい。

以後、情報処理システムを管理し、本願発明の表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理計算機が表示用情報を表示する場合は管理計算機が管理システムである、また、管理計算機と表示用計算機の組み合わせも管理システムである。また、管理処理の高速化や高信頼化のために複数の計算機で管理計算機と同等の処理を実現してもよく、この場合は当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含め）が管理システムである。

本明細書に示すアルゴリズムおよびディスプレイは、いかなる特定のコンピュータまたは他の装置にも本質的には関係しない。各種の汎用システムを、本明細書の開示によるプログラムおよびモジュールと共に用いてもよいが、所望の方法のステップを実行するための、より特化した装置を構築した方が便利な場合がある。これら各種のシステムの構造は以下に開示する説明で明らかになる。また、本明細書では、本発明をいかなる特定のプログラミング言語も前提としては記述していない。以下に記述するように、本発明の開示を実行するために各種のプログラミング言語を用いてもよいことが理解されよう。プログラミング言語の命令は、一つ以上の処理装置、例えば中央処理装置（ＣＰＵ）、プロセッサ、またはコントローラによって実行できる。

＜本実施例の概要＞
以下でより詳しく述べるように、本発明の例示的な実施形態は、障害解析用ルールの作成における作業工数を削減する効果を有する障害解析用ルール作成支援、および、それらルールに基づいて障害解析を実行する装置、方法、およびコンピュータプログラムを提供する。

例示的な実施形態によれば、管理コンピュータは複数の管理対象装置を管理するコンピュータである。管理対象装置の種別としては、例えば、サーバを含むコンピュータ、ＩＰスイッチ、ルータ、ＦＣ（ファイバチャネル）スイッチ等のネットワーク装置、およびＮＡＳ、ストレージ装置等がある。なお、管理対象装置が含むデバイス等の論理的または物理的な構成をコンポーネントと称する。コンポーネントの例としてはポート、プロセッサ、記憶資源、記憶デバイス、プログラム、仮想マシン、ストレージ装置内部で定義される論理ボリューム、ＲＡＩＤグループ等がある。なお、管理対象装置とコンポーネントとを区別せずに扱う場合は管理オブジェクトと称する。

管理コンピュータは、これら管理オブジェクトの構成情報、イベント情報と呼ばれる管理オブジェクトの状態または性能の変化を示す情報などの装置情報を取得する。

また、管理コンピュータは管理オブジェクトの障害発生を示すイベントを検知すると、そのイベントの組み合せから障害を解析して原因を特定する解析エンジン、および障害を解析するうえで必要となるルールの作成を支援するルール作成エンジンを有する。

解析エンジンは、管理対象装置の構成情報を持つ構成管理ＤＢにアクセスして、Ｉ／Ｏ（入出力）経路上のパス上にある一つまたは複数の管理対象装置に跨る複数のコンポーネント間の関係を、「トポロジ」と称される一つのグループとして認識する。また、障害が解析される前に予め用意される障害解析用のルールは、メタルールと称され、あるパターンのトポロジにおいて発生し得るイベントの組み合わせと、それらのイベントが発生した場合に障害の原因候補となるイベントとの対応関係が、例えばＩＦ−ＴＨＥＮ形式で記述される。解析エンジンは、ある管理オブジェクトにおける障害イベントを検知すると、検知した障害に関連するメタルール、および障害が発生した管理オブジェクトを含むトポロジの情報を構成管理ＤＢから取得し、メタルールに記述されたイベントの組み合わせ、および原因イベントと、当該トポロジから、発生した障害の原因候補を特定し、システムの運用管理者に通知する。

ルール作成エンジンは、メタルールの作成を支援する機能を有する。システム障害に関する知識を有するルール作成者が、ある障害の原因イベントおよび原因イベントによって連鎖的に引き起こされる影響イベントを入力すると、管理コンピュータの構成管理ＤＢのデータモデルに基づいて、原因イベントが発生したコンポーネントと影響イベントが発生したコンポーネントとの間のトポロジのパターンを導出する。そして、導出されたパターンのトポロジを構成管理ＤＢから検索および取得する手段を作成し、入力された原因イベントおよび影響イベントを合わせてメタルールを生成する。

したがって、本発明の例示的な実施形態において、原因イベントおよび影響イベントを入力すると、ルール作成エンジンはメタルールを生成し、メタルールの適用先となるトポロジの情報を構成管理ＤＢから取得する手段も合わせて生成する。このため、ルール作成者は管理コンピュータの構成管理ＤＢのデータモデルを含めた内部構造を学習することなくメタルールを作成することができ、また、解析エンジンは作成されたメタルールに基づいて、自動的に障害の原因を特定することができる。

＜管理コンピュータのハードウェアおよび論理構成＞
図１Ａおよび図１Ｂは、本発明の第１の実施例の情報システムのハードウェアアーキテクチャおよび論理構成の例を示すブロック図である。

図に示すシステムは、管理コンピュータ１０１、一つ以上のサーバ（または、他のコンピュータ）１０２Ａおよび１０２Ｂ、一つ以上のＦＣ（ファイバチャネル）スイッチ（または、他のネットワーク装置）１０５、一つ以上のストレージ１０４Ａおよび１０４Ｂ、および、一つ以上のＩＰスイッチ（または、他のネットワーク装置）１０３を有する。

管理コンピュータ１０１、サーバ１０２Ａ、１０２ＢおよびＦＣスイッチ１０５は、ＬＡＮ（ローカルエリアネットワーク）１０６等のネットワークを介して通信可能に接続される。ストレージ１０４Ａ、１０４Ｂは、ＳＡＮ（ストレージエリアネットワーク）１０７等のネットワークを介してサーバ１０２Ａ、１０２Ｂと通信可能に接続される。

管理コンピュータ１０１は、ＣＰＵ１１１、メモリ１１２、ハードディスクドライブ（ＨＤＤ）１１３等の記憶媒体、入力デバイス１１４、出力デバイス１１７、およびネットワークインターフェース（Ｉ／Ｆ）１１５を含み、これらのデバイスがシステムバス１１６を介して接続される汎用コンピュータでよい。管理コンピュータ１０１の論理モジュールは、メタルール生成プログラム１２１、イベント受信プログラム１２２、障害解析プログラム１２３、構成情報取得プログラム１２４および表示モジュール１２５を含む。また、管理コンピュータ１０１は、データとして、イベントテーブル１３１、構成管理ＤＢ１３２、関連テーブル１３３、トポロジ取得方式リポジトリ１３４、メタルールリポジトリ１３５および展開ルールリポジトリ１３６を有する。

メタルール生成プログラム１２１、イベント受信プログラム１２２、障害解析プログラム１２３、構成情報取得プログラム１２４および表示モジュール１２５は、メモリ１１２または他の計算機可読媒体に保存され、ＣＰＵ１１１が実行する。以下に記述するイベントテーブル１３１、構成管理データベース１３２、関連テーブル１３３、トポロジ取得方式リポジトリ１３４、メタルールリポジトリ１３５および展開ルールリポジトリ１３６などのデータは、ディスク１１３または他の適当な計算機可読媒体に保存されていてよい。

ネットワークインターフェース１１５は、ＬＡＮ１０６を介して接続されるサーバ１０２、ＩＰスイッチ１０３、ストレージ１０４およびＦＣスイッチ１０５等の、管理対象である動作ノードからイベント情報を取得する。出力デバイス１１７は、表示モジュール１２５からの情報を運用管理者に提示するために用いられる。入力デバイス１１４は、運用管理者の指示を入力するために用いられる。例えば、入力デバイス１１４としてキーボード、ポインタデバイス等を用いることができ、出力デバイス１１７としてディスプレイ、プリンタ等を用いることができるが、これら以外の装置でもよい。また、入力デバイス１１４および出力デバイス１１７の代わりに、シリアルインターフェースやイーサーネットインターフェースを用いてもよい。この場合、当該インターフェースにディスプレイ、キーボード、ポインタデバイス等を有する表示用計算機を接続し、表示用情報を表示用計算機に送信し、入力用情報を表示用計算機から受信することによって、表示用計算機において表示を行い、また、表示用計算機から入力を受け付けることによって、入力デバイス１１４および出力デバイス１１７の機能を代替してもよい。

各サーバ１０２Ａ、１０２Ｂは、当技術分野で公知であるように、アプリケーション等を実行している管理対象ノードでよい。サーバ１０２Ａは、ＣＰＵ１４６、メモリ（ストレージを含んでもよい）１４７、およびネットワークインターフェース１４４を含む汎用コンピュータでよい。サーバ１０２Ａは、サーバ１０２Ａの状態を監視し、特定の状態変化が検出された場合にＬＡＮ１０６を介して管理コンピュータ１０１にイベント情報を送る監視エージェント１４１を含んでもよい。例示する実施例において、各サーバ１０２Ａは、ＳＡＮ１０７に接続するためのＨＢＡ（ホストバスアダプタ）１４２を有する。例えば、サーバ１０２Ａは、ディスクドライブ１５１Ａを仮想的にローカルＨＤＤのように利用できる。このディスクドライブ１５１Ａは、ＨＢＡ１４２およびストレージ１０４Ａ、１０４Ｂの記憶領域によって実現できる。さらに、代替的な実施例において、ＳＣＳＩの代わりに、またはこれに加えて、他の通信およびストレージプロトコルを用いてもよい。

なお、サーバ１０２Ａの構成を説明したが、サーバ１０２Ｂも同じ構成を有してよい。

ストレージ１０４Ａ、１０４Ｂは、当該技術分野で公知であるように、サーバ１０２上で動作するアプリケーションが使用する記憶容量を提供するため、または他の目的のための管理対象ノードでよい。ストレージ１０４Ａは、ストレージコントローラ１６１、ＳＡＮ１０７に接続するためのＩ／Ｏポート１６３、ＬＡＮ１０６に接続するためのネットワークインターフェース１６７、およびＲＡＩＤグループ１６４Ａ、１６４Ｂを有し、これらのデバイスが内部バス等を介して接続されている。なお、ＲＡＩＤグループ１６４の接続とは、より正確にはＲＡＩＤグループ１６４を構成する記憶媒体１６２Ａ〜１６２Ｄが他のデバイスと接続されていることである。

記憶媒体１６２Ａ〜１６２Ｄは、本実施例ではハードディスクドライブでもよいが、固体記憶媒体（ＳＳＤ）、光記憶媒体等、他の種類の記憶媒体でもよい。ＲＡＩＤグループ１６４Ａ、１６４Ｂは、それぞれ、一つまたは複数の記憶媒体１６２Ａ等で構成されている。なお、ＲＡＩＤグループ１６４Ａ、１６４Ｂが、複数の記憶媒体１６２Ａ等によって構成されている場合、それらの記憶媒体１６２Ａ等はＲＡＩＤを構成してもよい。また、ＲＡＩＤグループ１６４は、論理的に複数のボリューム（ＬＵＮ）１６５Ａ等を構成している。

本実施例において、ストレージ１０４Ａは、サーバ１０２Ａ、１０２Ｂに対し、記憶容量として論理ボリュームを提供するように構成される。したがって、例示する実施例において、２台のサーバ１０２Ａ、１０２ＢがＦＣスイッチ１０５を介してストレージ１０４Ａに接続されており、ストレージ１０４Ａが各サーバ１０２Ａ、１０２Ｂに論理ボリュームを提供する。また、ストレージ１０４Ａは、ストレージ１０４Ａの状態を監視し、特定の状態変化が検出された場合にＬＡＮ１０６を介して管理コンピュータ１０１にイベント情報を送る監視エージェント１６６を含んでもよい。あるいは、サーバ１０２Ａの監視エージェント１４１が、ストレージ１０４Ａの状態を監視してもよい。

なお、ストレージ１０４Ａの構成を説明したが、ストレージ１０４Ｂも同じ構成を有してよい。

ＦＣスイッチ１０５は、当該技術分野で公知であるように、サーバ１０２Ａ、１０２Ｂおよびストレージ１０４Ａ、１０４Ｂを接続するＳＡＮ１０７を構成するための、または他の目的のための管理対象ノードであってよい。これによって、ストレージ１０４Ａ、１０４Ｂの論理ボリュームを記憶領域としてサーバ１０２Ａ、１０２Ｂに提供される。

ＦＣスイッチ１０５はサーバ１０２またはストレージ１０４から送信されるデータを受信し、かつ、受信したデータを送信するポート１７１Ａ〜１７１Ｄを有する。また、ＦＣスイッチ１０５は、ＬＡＮ１０６に接続するためのネットワークインターフェース１７３を含んでいてよい。さらに、ＦＣスイッチ１０５は、ＦＣスイッチ１０５の状態を監視し、特定の状態変化が検出された場合にＬＡＮ１０６を介して管理コンピュータ１０１にイベント情報を送る監視エージェント１７２を含んでもよい。あるいは、サーバ１０２Ａの監視エージェント１４１が、ＦＣスイッチ１０５の状態を監視してもよい。

＜イベントテーブル＞
図２は、本実施例のイベントテーブル１３１のデータ構造の例を説明する図である。イベントテーブル１３１は、イベント受信プログラム１２２が管理対象装置の監視エージェントから受信したイベント情報を格納する。

イベントテーブル１３１は、五つのフィールド、すなわち、イベントＩＤ２０１、装置ＩＤ２０２、コンポーネントＩＤ２０３、イベント種別２０４および発生日時２０５を含む。イベントＩＤ２０１は、各イベント情報を一意に識別するための識別情報である。装置ＩＤ２０２は、管理対象装置を一意に識別するための識別情報である。コンポーネントＩＤ２０３は、管理対象コンポーネントを一意に識別するための識別情報である。イベント種別２０４は、管理オブジェクトで生起したイベントの種別である。発生日時２０５は、イベントが生起した時刻である。発生日時は、管理コンピュータ１０１がイベント情報を受信した時刻でもよい。イベントが、コンポーネントに関するイベントではなく、装置そのものに関するイベントである場合、コンポーネントＩＤ２０３の値は「ＮＵＬＬ」でもよい。

例えば、図２のエントリ２１１は、装置ＩＤがＳｔＡであるストレージ１０４Ａ内のコンポーネントＩＤがＲＧ１であるＲＡＩＤグループ１６４において「ＷｒｉｔｅＨｉｔＰｅｒｆＥｒｒｏｒ」（書込処理のヒット率性能エラー）が２０１２年７月７日１５時０分０秒に発生したことを意味する。

＜メタルールリポジトリおよびメタルール＞
メタルールは、あるパターンのトポロジにおいて発生し得るイベントの組み合わせと、それらのイベントが同じタイミングで発生した場合に障害の原因候補となるイベントとの対応関係を示す情報である。本実施例において、メタルールはＩＦ−ＴＨＥＮ形式で記述されるが、システム障害の原因事象および原因事象によって引き起こされる観測事象が記述されていれば、他の形式でもよい。

図３は、本実施例のメタルールリポジトリ１３５に常駐するメタルール３００の例を説明する図である。

一般に、メタルールは二つの部分、すなわちＩＦ部３１１と称される第１の部分と、ＴＨＥＮ部３１２と称される第２の部分とに分けることができる。ＩＦ部３１１は一つ以上の条件要素を含んでもよい。

メタルール３００は、ＩＦ部３１１のイベント（条件イベント）が検知された場合、ＴＨＥＮ部３１２のイベント（結論イベント）が障害の原因となることを示す。したがって、ＴＨＥＮ部３１２のステータスが正常になれば、ＩＦ部３１１の問題も解決することが見込まれる。

本実施例においては、図２のイベントテーブル１３１に格納されるイベント情報を観測事象とし、障害を解析するため、メタルール３００のＩＦ部３１１の各条件要素には「装置種別」、「コンポーネント種別」および「イベント種別」が記述される。すなわち、管理対象装置およびコンポーネントは、管理コンピュータ１０１において、いくつかの種別に分類されており、ＩＦ部３１１の条件要素は指定した種別の管理オブジェクトにおいて指定したイベント種別の状態が発生することを示す。イベントが、コンポーネントに関するイベントではなく、装置そのものに関するイベントである場合、「コンポーネント種別」の値は「ＮＵＬＬ」でもよい。

また、メタルール３００は、各メタルールを一意に識別するメタルールＩＤ３１３を含むフィールド３１３を含む。また、メタルール３００は、メタルール３００を実際の管理対象システムの構成に適用して、展開ルールを生成する際に、メタルール３００を適用するトポロジの情報を取得する手段（トポロジ取得方式）の識別子を格納するためのフィールド３１４を含む。なお、複数のメタルール３００が、同じトポロジ取得方式のＩＤをフィールド３１４に格納してもよい。

例えば、図３のメタルール（メタルールＩＤ＝「ＭｅｔａＲｕｌｅ１」）は、観測事象として「サーバ１０２Ａなど上のディスクドライブ１５１Ａの転送時間性能エラー」と、「ストレージ１０４Ａ等におけるＲＡＩＤグループ１６４の書込処理のキャッシュヒット率性能低下エラー」とが検知された場合、「ストレージ１０４Ａ等におけるＲＡＩＤグループ１６４の書込処理の「ヒット率性能低下エラー」が原因であると結論付けられることを示す。

また、メタルールＩＤ＝「ＭｅｔａＲｕｌｅ１」のメタルールについて展開ルールを生成する場合、トポロジ取得方式ＩＤフィールド３１４で指定しているトポロジ取得方式をトポロジ取得方式リポジトリ１３４から取得し、メタルールから展開ルールを生成するのに必要なトポロジ情報を、取得した方式を用いて構成管理ＤＢ等から取得する。なお、ＩＦ部３１１に含まれる条件要素として、ある管理オブジェクトが正常であること（障害イベントが発生していないこと）を定義してもよい。また、ＴＨＥＮ部３１２のイベント種別は、新たに定義してもよく、イベント受信プログラム１２２が受信するイベントのイベント種別でなくてもよい。

＜構成管理ＤＢ＞
構成管理ＤＢ１３２は、構成情報取得プログラム１２４が監視エージェント等から取得した管理対象装置の構成情報を格納する。構成情報は、管理対象装置およびコンポーネントのＩ／Ｏ（入出力）の関係、接続関係、依存関係などを示す関連情報も含む。すなわち、トポロジはこれら関連の組み合わせによって表現することができる。

図１のサーバ１０２、ＦＣスイッチ１０５、ストレージ１０４について、構成管理ＤＢ１３２が格納する構成情報の例を図４〜図１３を用いて説明する。また、図１４は、図１に示す各管理オブジェクトの関連を、管理オブジェクトの種別ごとに表現したクラス図である。

本実施例においては、図１４のクラス図に合わせ、管理オブジェクトの種別ごとに、構成管理ＤＢ１３２内にテーブルを作る。そのため、各テーブル名は管理オブジェクト種別名を示し、各テーブルの一つのエントリは一つの管理オブジェクトを示す。ただし、管理オブジェクトの種別ごとに構成管理ＤＢのテーブルが構成される必要はなく、各エントリに対して、管理オブジェクトの種別を示す情報が登録されてもよい。また、一つの管理オブジェクトの情報が複数のエントリに登録されてもよい。

また、本実施例においては、管理オブジェクト間の関連を、各テーブルのフィールドの値を等しくすることによって表現しているが、管理オブジェクトの情報とは別に関連の情報を記録したテーブルを別に用意してもよい。

なお、構成管理ＤＢ１３２の一部のテーブルおよび／またはテーブル中の一部の項目のみを格納してもよい。また、構成管理ＤＢが格納する各項目のデータ表現形式およびデータ構造は、管理対象装置が持つデータの表現形式およびデータ構造と異なってもよい。また、管理コンピュータ１０１が管理対象装置から受信するデータは、管理対象装置のデータ構造およびデータ表現形式でもよい。

また、管理対象装置の構成の変更にしたがって、構成管理ＤＢ１３２のテーブルの情報が更新されてもよい。構成管理ＤＢのテーブルの情報が更新された場合、更新前の情報も記録しておき、履歴情報によって過去の構成情報を参照できるようにしてもよい。

図４は、本実施例の構成管理ＤＢ１３２に含まれるテーブルのうち、管理オブジェクトの種別がサーバである装置の構成情報を示すテーブルを説明する図である。

サーバテーブル４００は、二つのフィールド、すなわち、装置ＩＤ４０１およびホスト名４０２を含む。装置ＩＤ４０１は、管理対象装置を一意に識別するための識別情報である。ホスト名４０２は、運用管理者がサーバ１０２を一意に識別するための識別情報である。

特に、図４のサーバテーブル４００は、２０１２年１月１日から２０１２年１２月３１日までの管理対象のサーバ１０２Ａ、１０２Ｂの構成情報を示す。構成管理ＤＢ１３２のテーブルは、その情報が更新される毎にその変更日時および変更内容を記録する。または、定期的に各テーブルのスナップショットを取得する等によって、任意の期間の構成情報を示すテーブルを取得してもよい。以降に述べる構成管理ＤＢ１３２の各テーブルは、同様に任意の期間の構成情報を示すテーブルでよい。

図５は、本実施例の構成管理ＤＢ１３２に含まれるテーブルのうち、管理オブジェクトの種別がＦＣスイッチである装置の構成情報を示すテーブルを説明する図である。

ＦＣスイッチテーブル５００は、三つのフィールド、すなわち、装置ＩＤ５０１、スイッチ名５０２およびポート数５０３を含む。装置ＩＤ５０１は、管理対象装置を一意に識別するための識別情報である。スイッチ名５０２は、運用管理者がＦＣスイッチ１０５を一意に識別するための名称である。ポート数５０３は、ＦＣスイッチ１０５が持つポート数である。

特に、図５のＦＣスイッチテーブル５００は、２０１２年１月１日から２０１２年１２月３１日までの管理対象のＦＣスイッチ１０５の構成情報を示す。

図６は、本実施例の構成管理ＤＢ１３２に含まれるテーブルのうち、管理オブジェクトの種別がストレージである装置の構成情報を示すテーブルを説明する図である。

ストレージテーブル６００は、二つのフィールド、すなわち、装置ＩＤ６０１およびストレージ名６０２を含む。装置ＩＤ６０１は、管理対象装置を一意に識別するための識別情報である。ストレージ名６０２は、運用管理者がストレージ１０４Ａ等を一意に識別するための名称である。

特に、図６の、ストレージテーブル６００は、２０１２年１月１日から２０１２年１２月３１日までの管理対象のストレージ１０４Ａ、１０４Ｂの構成情報を示す。

図７は、本実施例の構成管理ＤＢ１３２に含まれるテーブルのうち、管理オブジェクトの種別がＨＢＡであるコンポーネントの構成情報を示すテーブルを説明する図である。

ＨＢＡテーブル７００は、四つのフィールド、すなわち、コンポーネントＩＤ７０１、ＷＷＮ７０２、装置ＩＤ７０３および接続先ターゲットＷＷＮ７０４を含む。

コンポーネントＩＤ７０１は、管理対象装置のコンポーネントを一意に識別するための識別情報である。ＷＷＮ７０２は、ＨＢＡに割り当てられたＷＷＮ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）である。装置ＩＤ７０３は、ＨＢＡが動作しているサーバ１０２Ａ等の識別情報である。装置ＩＤ７０３に記録される識別情報はサーバテーブル４００の装置ＩＤ４０１に格納される値と同じ値を用いる。接続先ターゲットＷＷＮ７０４は、ＨＢＡ１４２がストレージ１０４Ａの論理ボリューム１６５Ａなどをマウントするために使用しているストレージ１０４ＡのＩ／Ｏポート１６３のＷＷＮである。

特に、図７の、ＨＢＡテーブル７００は、２０１２年１月１日から２０１２年１２月３１日までのＨＢＡ１４２の構成情報を示す。

図８は、本実施例の構成管理ＤＢ１３２に含まれるテーブルのうち、管理オブジェクトの種別がディスクドライブであるコンポーネントの構成情報を示すテーブルを説明する図である。

ディスクドライブテーブル８００は、六つのフィールド、すなわち、コンポーネントＩＤ８０１、ドライブ名８０２、装置ＩＤ８０３、ＨＢＡ＿ＷＷＮ８０４、接続先ターゲットＷＷＮ８０５およびＬＵＮ＿ＩＤ８０６を含む。

コンポーネントＩＤ８０１は、管理対象装置のコンポーネントを一意に識別するための識別情報である。ドライブ名８０２は、サーバ１０２におけるドライブ（ＳＣＳＩディスク）１５１Ａの名称である。装置ＩＤ８０３は、ドライブ１５１Ａをマウントしているサーバ１０２Ａの識別子である。ＨＢＡ＿ＷＷＮ８０４は、ディスクドライブ１５１Ａへのアクセスに使用されるＨＢＡ１４２のＷＷＮである。接続先ターゲットＷＷＮ８０５は、ストレージ１０４Ａなどのドライブの記憶領域を論理ボリューム１６５Ａとして利用するためにアクセスしているストレージ１０４ＡなどのＩ／Ｏポート１６３のＷＷＮである。ＬＵＮ＿ＩＤ８０６は、各ストレージ１０４ＡなどのＩ／Ｏポート１６３に関連付けられる論理ボリューム１６５Ａなどの識別子である。

特に、図８の、ディスクドライブテーブル８００は、２０１２年１月１日から２０１２年１２月３１日までのＳＣＳＩディスク１５１Ａなどの構成情報を示す。

図９は、本実施例の構成管理ＤＢ１３２に含まれるテーブルのうち、管理オブジェクトの種別が論理ボリュームであるコンポーネントの構成情報を示すテーブルを説明する図である。

論理ボリュームテーブル９００は、六つのフィールド、すなわち、コンポーネントＩＤ９０１、ポートＷＷＮ９０２、ＬＵＮ＿ＩＤ９０３、装置ＩＤ９０４、容量９０５およびＲＡＩＤグループ番号９０６を含む。

コンポーネントＩＤ９０１は、管理対象装置のコンポーネントを一意に識別するための識別情報である。ポートＷＷＮ９０２は、各論理ボリューム１６５Ａなどの記憶領域を提供するために利用するＩ／Ｏポート１６３のＷＷＮである。ＬＵＮ＿ＩＤ９０３は、Ｉ／Ｏポート１６３に関連付けられる論理ボリューム１６５Ａなどの識別子である。装置ＩＤ９０４は、論理ボリューム１６５Ａなどが構成されるストレージ１０４の識別子である。容量９０５は、論理ボリューム１６５Ａなどの記憶領域の容量である。ＲＡＩＤグループ番号９０６は、ＲＡＩＤグループ１６４Ａなどを各ストレージ１０４Ａ内で一意に識別する識別情報であり、論理ボリューム１６５Ａなどの記憶領域を提供しているＲＡＩＤグループである。

特に、図９の、論理ボリュームテーブル９００は、２０１２年１月１日から２０１２年１２月３１日までの論理ボリューム１６５Ａなどの構成情報を示す。

図１０は、本実施例の構成管理ＤＢ１３２に含まれるテーブルのうち、管理オブジェクトの種別がＲＡＩＤグループであるコンポーネントの構成情報を示すテーブルを説明する図である。

ＲＡＩＤグループテーブル１０００は、五つのフィールド、すなわち、コンポーネントＩＤ１００１、ＲＡＩＤグループ番号１００２、装置ＩＤ１００３、容量１００４およびＲＡＩＤレベル１００５を含む。

コンポーネントＩＤ１００１は、管理対象装置のコンポーネントを一意に識別するための識別情報である。ＲＡＩＤグループ番号１００２は、ＲＡＩＤグループ１６４Ａなどをストレージ１０４Ａ内で一意に識別するための識別情報である。装置ＩＤ１００３は、ＲＡＩＤグループ１６４Ａなどが含まれるストレージ１０４Ａの識別情報である。容量１００４は、ＲＡＩＤグループ１６４Ａなどの記憶領域の容量である。ＲＡＩＤレベル１００５は、ＲＡＩＤグループ１６４ＡなどのＲＡＩＤレベルである。

特に、図１０の、ＲＡＩＤグループテーブル１０００は、２０１２年１月１日から２０１２年１２月３１日までのＲＡＩＤグループ１６４Ａなどの構成情報を示す。

図１１は、本実施例の構成管理ＤＢ１３２に含まれるテーブルのうち、管理オブジェクトの種別がストレージポートであるコンポーネントの構成情報を示すテーブルを説明する図である。

ストレージポートテーブル１１００は、五つのフィールド、すなわち、コンポーネントＩＤ１１０１、ポート番号１１０２、ＷＷＮ１１０３、装置ＩＤ１１０４およびアクセス許可ＷＷＮ１１０５を含む。

コンポーネントＩＤ１１０１は、管理対象装置のコンポーネントを一意に識別するための識別情報である。ポート番号１１０２は、ストレージ１０４ＡなどでＩ／Ｏポート１６３を一意に識別するための識別情報である。ＷＷＮ１１０３は、Ｉ／Ｏポート１６３に割り当てられたＷＷＮである。装置ＩＤ１１０４は、Ｉ／Ｏポート１６３を有するストレージ１０４Ａなどの識別情報である。アクセス許可ＷＷＮ１１０５は、Ｉ／Ｏポート１６３へのアクセスが許可されたＨＢＡのＷＷＮである。

特に、図１１の、ストレージポートテーブル１１００は、２０１２年１月１日から２０１２年１２月３１日までのＩ／Ｏポート１６３の構成情報を示す。

図１２は、本実施例の構成管理ＤＢ１３２に含まれるテーブルのうち、管理オブジェクトの種別がストレージディスクであるコンポーネントの構成情報を示すテーブルを説明する図である。

ストレージディスクテーブル１２００は、四つのフィールド、すなわち、コンポーネントＩＤ１２０１、ディスク番号１２０２、装置ＩＤ１２０３およびＲＡＩＤグループ番号１２０４を含む。

コンポーネントＩＤ１２０１は、管理対象装置のコンポーネントを一意に識別するための識別情報である。ディスク番号１２０２は、ストレージ１０４Ａなどで記憶媒体１６２Ａなどを一意に識別する識別情報である。装置ＩＤ１２０３には、記憶媒体１６２Ａなどを有するストレージ１０４Ａなどの識別情報である。ＲＡＩＤグループ番号１２０４は、記憶媒体１６２Ａなどが構成するＲＡＩＤグループ１６４Ａなどを各ストレージ１０４Ａなどで一意に識別する識別情報である。

特に、図１２の、ストレージディスクテーブル１２００は、２０１２年１月１日から２０１２年１２月３１日までの記憶媒体１６２Ａの構成情報を示す。

図１３は、本実施例の構成管理ＤＢ１３２に含まれるテーブルのうち、管理オブジェクトの種別がＦＣスイッチポートであるコンポーネントの構成情報を示すテーブルを説明する図である。

ＦＣスイッチポートテーブル１３００は、五つのフィールド、すなわち、コンポーネントＩＤ１３０１、ポート番号１３０２、ＷＷＮ１３０３、装置ＩＤ１３０４および接続先ポートＷＷＮ１３０５を備える。

コンポーネントＩＤ１３０１は、管理対象装置のコンポーネントを一意に識別するための識別情報である。ポート番号１３０２は、ＦＣスイッチ１０５内でポート１７１Ａなどを一意に識別する識別情報である。ＷＷＮ１３０３は、ポート１７１Ａなどに割り当てられたＷＷＮである。装置ＩＤ１３０４は、ポート１７１Ａなどを有するＦＣスイッチ１０５の識別子である。接続先ポートＷＷＮ１３０５は、ポート１７１Ａなどが直接接続されるポートのＷＷＮである。

特に、図１３の、ＦＣスイッチポートテーブル１３００は、２０１２年１月１日から２０１２年１２月３１日までのＦＣスイッチのポート１７１Ａの構成情報を示す。

前述したように、図１４は、図１に示す各管理オブジェクトのＩ／Ｏ（入出力）の関係、接続関係、依存関係などの関連を、管理オブジェクトの種別ごとに表現したクラス図である。

例えば、図１４のサーバ１４０１や、ＨＢＡ１４０２は、それぞれ管理オブジェクトの種別を表す。例えば、矢印１４０３は、ＨＢＡ１４０２がサーバ１４０１の部品となり得ることを示す。例えば、コネクタ１４０４は、ＨＢＡ１４０２とストレージポート１４０６との接続関係が生じ得ることを示し、多重度１４０５は、ストレージポート１４０６が一つ存在する場合、接続関係が生じ得るＨＢＡは０個、１個、または複数であることを示す。実際の管理オブジェクトに矢印１４０３およびコネクタ１４０４が示す関連が生じているかは、構成管理ＤＢ１３２の構成情報から導出することができる。

＜関連テーブル＞
図１５Ａおよび図１５Ｂは、本実施例の関連テーブル１３３のデータ構造の例を説明する図である。本実施例の関連テーブル１３３は、図１５Ａに示すエントリの下に、図１５Ｂに示すエントリが続く構造である。

関連テーブル１３３は、各管理オブジェクト種別間（本実施例では、構成管理ＤＢ１３２のテーブル間）で生じ得る関連の情報、すなわち、図１４のクラス図における矢印１４０３およびコネクタ１４０４の情報を格納する。関連テーブル１３３は、構成管理ＤＢ１３２の各テーブルの各フィールドの対応関係を格納しており、対応関係があるフィールドの値が等しい場合、構成管理ＤＢ１３２のテーブルの各エントリの管理オブジェクトは関連があることを示す。

関連テーブル１３３を参照することによって、指定した管理オブジェクトと関連を持つ管理オブジェクトの情報を構成管理ＤＢ１３２から取得することができる。すなわち、関連テーブル１３３の各エントリは、構成管理ＤＢ１３２から管理オブジェクト間の関連情報を取得するための関連付けを示す。

関連テーブル１３３は、五つのフィールド、すなわち、関連ＩＤ１５０１、テーブル名Ｘ１５０２、フィールド名Ｘ１５０３、テーブル名Ｙ１５０４、フィールド名Ｙ１５０５を含む。

関連ＩＤ１５０１は、管理オブジェクト種別の対応関係を一意に識別するための識別情報である。テーブル名Ｘ１５０２は、構成管理ＤＢ１３２のテーブル名である。フィールド名Ｘ１５０３は、テーブル名Ｘ１５０２が示すテーブルのフィールド名である。テーブル名Ｙ１５０４は、テーブル名Ｘ１５０２が示すテーブルと関連を持つテーブル名である。フィールド名Ｙ１５０５は、テーブル名Ｙ１５０４が示すテーブルのフィールド名である。フィールド名Ｘ１５０３が示すフィールドと、フィールド名Ｙ１５０５が示すフィールドとに等しい値が格納されている場合、各エントリが示す管理オブジェクトは関連を持つ。

例えば、図１５Ａに示す１番目のエントリ１５１１は、構成管理ＤＢ１３２において、ディスクドライブテーブル８００の装置ＩＤフィールド８０３の値（図８参照）と、サーバテーブル４００の装置ＩＤフィールド４０１の値（図４参照）とが等しいエントリが各テーブルに格納されている場合、それらのエントリが示すディスクドライブ１５１Ａなどとサーバ１０２Ａなどとは関連している（すなわち、ディスクドライブ１５１Ａはサーバ１０２Ａの構成要素である）ことを示す。

また、３番目のエントリ１５１３は、フィールド１５０３および１５０５において、さらにＡＮＤ演算子を用いている。すなわち、エントリ１５１３は、構成管理ＤＢ１３２において、ディスクドライブテーブル８００の接続先ターゲットＷＷＮフィールド８０５の値と、論理ボリュームテーブル９００のポートＷＷＮフィールド９０２の値とが等しく、かつ、ディスクドライブテーブル８００のＬＵＮ＿ＩＤフィールド８０６の値と、論理ボリュームテーブル９００のＬＵＮ＿ＩＤフィールド９０３の値とが等しいエントリが各テーブルに格納されている場合、それらのエントリが示すディスクドライブ１５１Ａなどと論理ボリューム１６５Ａなどとは関連している（すなわち、論理ボリューム１６５Ａをディスクドライブ１５１Ａの記憶領域として利用している）ことを示す。

なお、本実施例では、構成管理ＤＢ１３２の各テーブルの関連ごとに関連テーブルのエントリを用意したが、二つ以上の関連に関する情報を一つのエントリに格納してもよい。例えば、図１４のクラス図に示すように、論理ボリュームテーブルとストレージディスクとは直接関連しない。しかし、論理ボリュームとストレージディスクはが、トポロジとしてＲＡＩＤグループを介して関連するので、論理ボリュームテーブルのエントリとストレージディスクテーブルのエントリとの関連を示すエントリが、関連テーブル１３３に含まれてもよい。

＜トポロジ取得方式リポジトリおよびトポロジ取得方式＞
トポロジ取得方式は、メタルールを実際に管理対象システムに対して適用して展開ルールを生成する際に、メタルールを適用可能なトポロジを構成管理ＤＢ１３２から検索し、該当するトポロジの情報を取得するための手段を示す情報である。

図１６Ａから図１６Ｅは、本実施例のトポロジ取得方式リポジトリ１３４に常駐するトポロジ取得方式の例を説明する図である。

図１６Ａおよび図１６Ｂに示すように、トポロジ取得方式は、二つのフィールド、すなわち、方式ＩＤ１６０１および方式１６０２を含む。

方式ＩＤ１６０１は、トポロジ取得方式を一意に識別するための識別情報である。方式１６０２は、関連テーブル１３３の一つまたは複数のエントリの識別情報（関連ＩＤ）である。方式１６０２に格納された関連ＩＤを持つ関連テーブル１３３のエントリを取得し、取得したエントリが示す関連を全て持つ管理オブジェクト群の情報を構成管理ＤＢ１３２から取得することによって、トポロジ情報を取得することができる。

なお、トポロジ取得方式１６００は、複数のメタルール３００から参照されていてよい。

また、例えば、図１６Ｂに示すトポロジ取得方式１６００は、識別情報が「Ｍｅｔｈｏｄ２」であり、関連テーブル１３３において関連ＩＤ１５０１がＡＳ３およびＡＳ１０のエントリに登録された構成管理ＤＢ１３２のフィールドの対応関係に基づいて、メタルール３００を適用するトポロジの情報を構成管理ＤＢ１３２から取得できることを示す。トポロジ取得方式１６００を用いて実際にトポロジ情報を取得する際には、関連テーブル１３３の関連ＩＤ１５０１が「ＡＳ３」のエントリと「ＡＳ１０」のエントリの情報に基づいて、以下の全ての条件を同時に満たす構成管理ＤＢ１３２のディスクドライブテーブル８００と、論理ボリュームテーブル９００と、ストレージポートテーブル１１００とのエントリの組み合わせを取得する。
（１）ディスクドライブテーブル８００の接続先ターゲットＷＷＮ８０５の値と、論理ボリュームテーブル９００のポートＷＷＮ９０２の値とが等しく、かつ、ディスクドライブテーブル８００のＬＵＮ＿ＩＤ８０６の値と論理ボリュームテーブル９００のＬＵＮ＿ＩＤ９０３の値とが等しい。
（２）論理ボリュームテーブル９００のポートＷＷＮ９０２の値とストレージポートテーブル１１００のＷＷＮ１１０３の値が等しい。

方式１６０２には、関連テーブル１３３の一つまたは複数のエントリの情報に基づいて導出された、構成管理ＤＢ１３２からトポロジを取得する処理、例えば、プログラムやＳＱＬなどのデータベース問い合わせ言語などが格納されてもよい。

例えば、構成管理ＤＢ１３２が当該技術分野において公知であるリレーショナルデータベースであり、データベース問い合わせ言語ＳＱＬによってデータを取得できる場合、図１６Ａに示すトポロジ取得方式１６００に対応して、関連ＩＤ１５０１がＡＳ３、ＡＳ１２のエントリに登録された構成管理ＤＢ１３２のフィールドの対応関係に基づいて、図１６Ｃに示すＳＱＬ１６５０Ａ、図１６Ｄに示すＳＱＬ１６５１Ａ、図１６Ｅに示すＳＱＬ１６５２Ａを生成してもよい。ＳＱＬ１６５０Ａはディスクドライブテーブルに属するコンポーネントＩＤを起点としてトポロジ情報を取得するＳＱＬであり、ＳＱＬ１６５１ＡはＲＡＩＤグループテーブルに属するコンポーネントＩＤを起点としてトポロジ情報を取得するＳＱＬであり、ＳＱＬ１６５２Ａは指定した関連を持つ全てのトポロジの情報を取得するＳＱＬである。

なお、これらのＳＱＬには処理の高速化のための工夫がされるとよい。例えば、構成管理ＤＢ１３２のテーブル間の多重度に応じて、ＳＱＬ文のＷＨＥＲＥ句に記述する条件によって取得するエントリを絞り込む順序を変更してもよい。

また、トポロジ取得方式において、スイッチのようにある装置から別の装置までの間に多段に接続されたトポロジを取得する場合、方式１６０２に、「Ｎ＊ＡＳ８」など、「ＡＳ８（関連ＩＤ）に対応するエントリが示す関連をＮ回繰り返し辿る」という定義を含めてもよい。

＜展開ルールリポジトリおよび展開ルール＞
展開ルールは、管理対象システムにおいて発生しうるイベントの組み合わせと、それらのイベントが発生した場合の障害の原因候補となるイベントとの対応関係を示す情報である。展開ルールは、管理対象システムの構成情報に基づいて、メタルール３００を適用可能なトポロジを管理対象システムの中から検索し、検索されたメタルール３００を適用した結果生成されるルールである。

本実施例において、展開ルールは、メタルールと同様に、ＩＦ−ＴＨＥＮ形式で記述するが、システム障害の原因事象と、原因事象によって引き起こされる観測事象が記述されていれば、他の形式でもよい。

図１７Ａから図１７Ｃは、本実施例の展開ルールリポジトリ１３６に格納される展開ルールの例を説明する図である。

一般に、展開ルールも、メタルール３００と同様に、二つの部分、すなわちＩＦ部１７１１と称される第１の部分と、ＴＨＥＮ部１７１２と称される第２の部分とに分けることができる。ＩＦ部１７１１は一つ以上の条件要素を含んでもよい。

展開ルール１７００は、ＩＦ部１７１１のイベント（条件イベント）が検知された場合、ＴＨＥＮ部１７１２のイベント（結論イベント）が障害の原因となることを示す。したがって、ＴＨＥＮ部１７１２のステータスが正常になれば、ＩＦ部１７１１の問題も解決することが見込まれる。

本実施例においては、図２のイベントテーブル１３１に格納されるイベント情報を観測事象とし、障害を解析するため、展開ルール１７００のＩＦ部１７１１の各条件要素には装置ＩＤ１７０１、コンポーネントＩＤ１７０２、イベント種別１７０３、および受信フラグ１７０４が記述される。すなわち、ＩＦ部１７１１の条件要素の装置ＩＤ１７０１およびコンポーネントＩＤ１７０２によって指定される管理オブジェクトにおいてイベント種別１７０３の状態が発生することを示す。また、受信フラグ１７０４は、実際に条件要素が示すイベントを受信したかの結果である。条件要素が示すイベントを受信した場合は受信フラグ１７０４に「１」が格納され、条件要素が示すイベントを受信していない場合は受信フラグ１７０４に「０」が格納される。受信フラグ１７０４に「１」が格納された後、所定の時間が経過すると値を「０」に戻すなどの処理を行ってもよい。

また、展開ルール１７００は、各メタルールを一意に識別する展開ルールＩＤを格納するフィールド１７１３を含む。

例えば、図１７Ａに示す展開ルール「ＥｘｐａｎｄｅｄＲｕｌｅ１−１」は、観測事象として「サーバＡ（装置ＩＤ＝ＳｖＡ）のＤドライブ（コンポーネントＩＤ＝ＤＲＩＶＥ１）の転送時間性能エラー」と、「ストレージＡ（装置ＩＤ＝ＳｔＡ）におけるＲＡＩＤグループ０（コンポーネントＩＤ＝ＲＧ１）の書込処理のヒット率性能エラー」とが検知された場合、「ストレージＡにおけるＲＡＩＤグループ０の書込処理のヒット率性能エラー」が原因であると結論付けられることを示す。なお、ＩＦ部１７１１に含まれる条件要素として、ある管理オブジェクトが正常であること（障害イベントが発生していないこと）を定義してもよい。

＜メタルールの生成処理＞
本実施例においては、ルール作成者（システムの運用管理者）が管理対象システムで実際に発生した障害の原因と、その原因によって引き起こされた各管理オブジェクトのイベントを入力し、それらの入力された情報に基づいてメタルールが生成される。ルール作成者が実際に管理しているシステムにおいて実際に発生した障害の情報に基づいて、情報を入力することによって、より正確なルールを作成できる。さらに、障害解析機能の内部仕様を極力隠蔽して、メタルール生成に必要な情報を入力することができる。

例えば、管理対象システムで発生した障害について、障害解析機能が正しい解析結果を出さなかった場合、メタルールが不足していることが分かる。当該障害の対策後に、原因が判明した場合、当該障害の情報に基づいてメタルールの生成に必要な情報を入力し、新しいメタルールを生成することによって、以後、同様の障害が発生した場合に、障害を迅速に解析することができる。

図１８Ａおよび図１８Ｂは、本実施例の管理コンピュータ１０１でメタルール生成プログラム１２１が実行するメタルール生成処理の例のフローチャートである。

メタルール生成プログラム１２１は、入力デバイス１１４からのルール作成者の指示によって起動されるように構成されるとよい。また、メタルール生成プログラム１２１は、管理対象システムで障害が発生し、障害解析プログラム１２３が障害を解析した後、解析結果が正しくなかったと判断される条件を満たした場合、障害解析プログラム１２３によって起動され、処理を開始してもよい。

メタルール生成プログラム１２１は、図１８の処理において、さらに図２１から図２７に示す処理を呼び出して、実行する。

ステップＳ１８１１において、メタルール生成プログラム１２１は、表示モジュール１２５を起動し、管理対象システムで発生したイベントをイベントテーブル１３１から取得し、イベント一覧を表示した原因イベント選択画面を出力デバイス１１７に表示する。

図１９は、本実施例の原因イベント選択画面１９００の例を説明する図である。

図１９に例示するように、例えば、原因イベント選択画面１９００は、ルール作成者が入力フォーム１９０１で期間を入力して検索ボタン１９０３を操作すると、入力された期間内に発生したイベントをイベントテーブル１３１から検索し、イベント表示部１９０４に、その一覧を表示する機能を有してよい。あるいは、図１９に例示するように、入力フォーム１９０２で文字列を入力して検索ボタン１９０３を操作すると、入力された文字列を含むイベントをイベントテーブル１３１から検索し、検索されたイベントの一覧をイベント表示部１９０４に表示する機能を有してよい。あるいは、イベントテーブル１３１から、最新のイベントを起点として順に古いイベントを辿れてもよい。

ステップＳ１８１２において、メタルール生成プログラム１２１は、ルール作成者が選択したイベントを原因イベントとして受信する。例えば、ルール作成者は、原因イベント選択画面１９００（図１９）に表示されたイベント一覧の中から、あるシステム障害の原因となる事象を示すイベントを選択し、原因イベント確定ボタン１９０６を操作すると、メタルール生成プログラム１２１は、選択されたイベントの情報を受信する。

ステップＳ１８１３において、メタルール生成プログラム１２１は、イベントテーブル１３１から発生日時フィールド２０５の値を参照し、Ｓ１８１２で受信したイベントの発生時刻から所定期間内に発生したイベントを取得する。例えば、受信した原因イベントのイベントＩＤが、イベントテーブル１３１のイベントＩＤ２０１が「ＥＶ１」であり、所定期間が「前後１０分以内」である場合、イベントＩＤ２０１がＥＶ２のイベントおよびＥＶ３のイベントをイベントテーブル１３１から取得する。

ステップＳ１８１４において、メタルール生成プログラム１２１は、ステップＳ１８１２で受信した原因イベント、およびステップＳ１８１３で取得したイベント群を入力として、トポロジ探索処理を起動し、イベント、トポロジ情報およびトポロジ情報取得方式の組み合わせを取得する。各組み合わせは、ステップＳ１８１３で取得した各イベント、原因イベントが発生した管理オブジェクト間のトポロジ情報、および、そのトポロジを取得するための手段（方式）の組み合わせである。

ステップＳ１８１５において、メタルール生成プログラム１２１は、表示モジュール１２５を起動し、ステップＳ１８１４で取得したイベント、トポロジ情報およびトポロジ取得方式の組み合わせのうち、各イベント、トポロジ情報および原因イベントを出力デバイス１１７に表示する。複数のトポロジの全てまたは一部が重複している場合、一つにまとめて表示してもよい。

このように所定期間内に発生したイベントを表示し、その中からイベントの選択を促すことによって、原因イベントによって引き起こされたイベントを検索する手間を省くことができ、さらに、選択漏れを防ぐことができる。

図２０は、ステップＳ１８１５で表示する影響イベント選択画面２０００の例を説明する図である。

例えば、影響イベント選択画面２０００は、ステップＳ１８１２またはＳ１８１４で取得したイベントの情報、および、取得したイベントが発生した管理オブジェクトの情報を、アイコン２００１、２００２のように表示する。例えば、アイコン２００１は、イベントが「ストレージＡのＲＡＩＤグループ０の書込処理のヒット率性能エラー」であることを示す。また、アイコン２００１は、原因イベントであることを示す表示を有してもよい。

また、コネクタ２００３は二つの管理オブジェクト間の関連を示しており、例えば、アイコン２００２、アイコン２００４およびアイコン２００１の間をコネクタ２００３で繋ぐことによって、サーバＡのＤドライブおよびストレージＡのＲＡＩＤグループ０の間には、「サーバＡのＤドライブは、ストレージＡ上の、ＬＵＮ ＩＤが０の論理ボリュームを記憶容量として利用しており、さらにＬＵＮ ＩＤが０の論理ボリュームはＲＡＩＤグループ０に生成されている」というトポロジがあることを示すことができる。なお、コネクタ２００３には、そのコネクタの意味（例えば、「利用している」「マウントしている」）などを表示してもよい。

また、特定の二つの管理オブジェクトに対して、複数のトポロジが表示されてもよい。例えば、サーバＡのＤドライブと、ストレージＡのＲＡＩＤグループ０は、アイコン２００２、２００７、２００６、２００４、２００１、および、それらの間を繋ぐコネクタで表現されるトポロジも有する。また、影響イベント選択画面２０００には、同じメタルールを作らないようにするため、原因イベントに対して既にメタルール３００によってルール化されているイベントがある場合は、ルール化されているイベントを表示してもよい。

ここで、メタルール生成プログラム１２１の処理の説明に戻る。

ステップＳ１８１６において、メタルール生成プログラム１２１は、ルール作成者が選択したイベントを影響イベントとして受信する。影響イベントは、複数選択されてもよい。

例えば、図２０の影響イベント選択画面２０００に表示されたアイコンの中から、ルール作成者はステップＳ１８１２で選択した原因イベントが引き起こしたイベントを選択し、確定ボタン２００８を操作する。メタルール生成プログラム１２１は、選択されたイベントの情報を受信する。

ステップＳ１８１７において、メタルール生成プログラム１２１は、ステップＳ１８１４で取得したイベント、トポロジ情報およびトポロジ取得方式の組み合わせの一覧から、ステップＳ１８１６で受信した影響イベントに対応するトポロジ情報およびトポロジ取得方式の組み合わせを全て取得する。

ステップＳ１８１８において、メタルール生成プログラム１２１は、ステップＳ１８１２で受信した原因イベント、ステップＳ１８１６で受信した影響イベント、および、ステップＳ１８１７で取得したイベント、トポロジ情報およびトポロジ取得方式の組み合わせを入力として、メタルール候補生成処理を起動し、メタルール３００を取得する。

ステップＳ１８１９において、メタルール生成プログラム１２１は、ステップＳ１８１８で取得したメタルールを入力として、メタルール検証情報表示処理を起動する。メタルール検証情報表示処理は、生成されたメタルールを用いて、正しい障害解析が可能かを検証するためのヒント情報を表示する処理である。

ステップＳ１８２０において、メタルール生成プログラム１２１は、ルール作成者が入力したメタルールの「生成」または「破棄」の決定を受信する。

ステップＳ１８２１において、メタルール生成プログラム１２１は、ステップＳ１８２０の入力が「生成」であるかを調べる。条件を満たす（入力が「生成」である）場合、処理はステップＳ１８２２へ進み、条件を満たさない場合、処理は終了する。

ステップＳ１８２２において、メタルール生成プログラム１２１は、ステップＳ１８１８で取得したメタルールをメタルールリポジトリ１３５に登録する。

図２１は、本実施例のメタルール生成プログラム１２１のステップＳ１８１４で実行されるトポロジ探索処理の例のフローチャートである。

トポロジ探索処理は、入力された原因イベントが発生した管理オブジェクトから、当該原因イベント以外のイベントが発生した管理オブジェクトまでの関連を、構成管理ＤＢ１３２において探索し、二つの管理オブジェクト間のトポロジを抽出する処理である。また、関連を探索する際に、関連の辿り方を記録することによって、メタルールを適用するトポロジを構成管理ＤＢ１３２から取得する手段（トポロジ取得方式）を生成する。

ステップＳ２１１１において、トポロジ探索サブプログラムは、原因イベントおよび当該原因イベント以外のイベントを含む、イベントテーブル１３１のエントリを、パラメータとして受信する。

ステップＳ２１１２において、トポロジ探索サブプログラムは、原因イベント以外のイベントについて、ステップＳ２１１３からＳ２１１７の処理を繰り返す。

ステップＳ２１１３において、トポロジ探索処理は、当該イベントのコンポーネントＩＤ２０３の値（コンポーネントＩＤがＮＵＬＬの場合は装置ＩＤ２０２の値）を取得する。

ステップＳ２１１４において、トポロジ探索サブプログラムは、ステップＳ２１１３で取得した管理オブジェクトＩＤ（コンポーネントＩＤ２０３または装置ＩＤ２０２）が登録された構成管理ＤＢ１３２のテーブル名およびエントリを取得する。エントリを取得する構成管理ＤＢ１３２のテーブルは、当該イベントの発生時刻または原因イベントの発生時刻における構成情報を示す構成管理ＤＢ１３２のテーブルでよい。また、以降で呼び出す関連探索処理も含め、構成管理ＤＢ１３２から取得するエントリは、全て当該イベントの発生時刻または原因イベントの発生時刻における構成情報を示す構成管理ＤＢ１３２のテーブル内のエントリでよい。

本実施例においては、管理オブジェクトの種別ごとに構成管理ＤＢ１３２のテーブルを作成している。このため、ステップＳ２１１４においてテーブル名を取得しているが、テーブル名ではなく、管理オブジェクトの種別を表す別の識別情報を取得してもよい。

ステップＳ２１１５において、トポロジ探索サブプログラムは、トポロジ情報およびトポロジ取得方式を含むリストを生成し、Ｓ２１１３のエントリの管理オブジェクトＩＤおよび空の関連ＩＤの組を起点として、リストの先頭に記録する。

ステップＳ２１１６において、トポロジ探索サブプログラムは、原因イベント、ステップＳ２１１４で取得したエントリ、テーブル名、および、ステップＳ２１１５で生成した管理オブジェクトＩＤおよび関連ＩＤの組のリストを入力として、関連探索処理を起動する。関連探索処理は、ステップＳ２１１４で取得したエントリを起点とし、関連テーブル１３３の情報に基づいて、各管理オブジェクトを示すエントリの関連を辿り、トポロジ情報および当該トポロジ情報を取得するためのトポロジ取得方式の組み合わせを生成して、探索結果メモリとして、メモリ１１２に記録する処理である。

ステップＳ２１１７において、トポロジ探索サブプログラムは、メモリ１１２に格納された探索結果メモリから、トポロジ情報およびトポロジ取得方式の組み合わせを取得し、各組み合わせについて当該イベントの情報を付加し、メモリ１１２に記録する。なお、探索結果メモリに記録された情報は削除してもよい。

ステップＳ２１１８において、トポロジ探索サブプログラムは、ステップＳ２１１７で記録した、トポロジ情報、トポロジ取得方式およびイベントの組み合わせを読み出し、呼出元プログラムに返す。

図２２Ａおよび図２２Ｂは、本実施例のトポロジ探索処理のステップＳ２１１６で実行される関連探索処理の例のフローチャートである。

関連探索処理は、構成管理ＤＢ１３２において、一つの管理オブジェクトを起点とし、原因イベントが発生した管理オブジェクトまでの関連を、関連テーブル１３３の情報に基づいて辿ることによって、起点管理オブジェクトから原因管理オブジェクトまでのトポロジ情報を取得する。また、関連を探索する際に、関連の辿り方を記録することによって、合わせてトポロジ取得方式も生成し、トポロジ情報および当該トポロジ情報を取得するためのトポロジ取得方式の組み合わせを、探索結果メモリとして、メモリ１１２に記録する処理である。

ある装置で障害イベントが発生した場合、トポロジ上の管理オブジェクトは全て影響を受けるが、管理コンピュータ１０１が取得できる管理オブジェクトの状態情報および性能情報によっては、トポロジ上の全ての管理オブジェクトのイベントを検知できない場合がある。そのため、ルール作成者が指定する原因管理オブジェクトおよび影響管理オブジェクトは直接関連するとは限らないため、関連探索処理が示すように管理オブジェクト間の関連を辿る必要がある。

なお、本実施例においては、構成管理ＤＢ１３２のエントリをノードとした場合に関連を探索するアルゴリズムは、経路探索アルゴリズムのうち、当該技術分野で公知の深さ優先探索のアルゴリズムを用いることができるが、他のアルゴリズム（例えば、幅優先探索）を用いてもよい。また、一つのノードから探索するのではなく、原因管理オブジェクトおよび影響管理オブジェクトの両方から探索を開始してもよい。

ステップＳ２２１１において、関連探索サブプログラムは、原因イベント、構成管理ＤＢ１３２のエントリ、テーブル名、管理オブジェクトＩＤおよび関連ＩＤの組のリストをパラメータとして受信する。

ステップＳ２２１２において、関連探索サブプログラムは、関連テーブル１３３から、テーブル名Ｘ１５０２またはテーブル名Ｙ１５０４の値が受信したテーブル名と等しいエントリを全て取得する。

ステップＳ２２１３において、関連探索サブプログラムは、ステップＳ２２１２において取得した関連テーブル１３３のエントリについて、ステップＳ２２１４からＳ２２２１の処理を繰り返す。

ステップＳ２２１４において、関連探索サブプログラムは、関連テーブル１３３の当該エントリに登録された構成管理ＤＢ１３２における管理オブジェクト種別間の対応関係に基づいて、受信した構成管理ＤＢ１３２のエントリと関連する全てのエントリを構成管理ＤＢ１３２から取得する。すなわち、例えば、当該エントリのテーブル名Ｘ１５０２に、受信したテーブル名が格納されている場合、フィールド名Ｘ１５０３に格納されたフィールド名Ａを取得し、受信したエントリのフィールド名Ａに該当するフィールドに格納された値Ｂを取得する。そして、当該エントリのテーブル名Ｙ１５０４に格納されたテーブル名を持つ構成管理ＤＢ１３２のテーブルから、フィールド名Ｙ１５０５に格納されたフィールド名に該当するフィールドに値Ｂと等価な値が格納されたエントリ一覧を取得する。

ステップＳ２２１５において、関連探索サブプログラムは、ステップＳ２２１４で取得した構成管理ＤＢ１３２のエントリについて、ステップＳ２２１６からＳ２２２１の処理を繰り返す。

ステップＳ２２１６において、関連探索サブプログラムは、構成管理ＤＢ１３２の当該エントリのコンポーネントＩＤ（装置に関するエントリについては装置ＩＤ）と、関連テーブル１３３の当該エントリの関連ＩＤ１５０１とを組にしたものを探索中のトポロジの最先端管理オブジェクト（最先端ノード）に関する情報として、受信したリストの先頭に追加する。

ステップＳ２２１７において、関連探索サブプログラムは、原因イベントのコンポーネントＩＤ（コンポーネントＩＤがＮＵＬＬである場合は装置ＩＤ）と、構成管理ＤＢ１３２の当該エントリのコンポーネントＩＤ（または、装置ＩＤ）が等しいかを判定する。条件を満たす場合、処理はステップＳ２２１８に進む。一方、条件を満たさない場合、処理はステップＳ２２１９に進む。

ステップＳ２２１８において、関連探索サブプログラムは、管理オブジェクトＩＤと関連ＩＤとの組のリストから、管理オブジェクトＩＤのリストをトポロジ情報とし、関連ＩＤのリストをトポロジ取得方式とし、トポロジ情報およびトポロジ取得方式の組み合わせを、探索結果メモリとして、メモリ１１２に記録する。また、ステップＳ２１１５からの繰り返し処理を終了する。

ステップＳ２２１９において、関連探索サブプログラムは、関連探索の打ち切り条件を満たしているかを調べる。条件を満たす場合、構成管理ＤＢの次のエントリについてステップＳ２２１５からの繰り返し処理を実行する。一方、条件を満たさない場合、処理はステップＳ２２２０に進む。

ステップＳ２２１９における関連探索の打ち切り条件は、例えば、管理オブジェクトＩＤと関連ＩＤの組のリストの中に、同じ管理オブジェクトＩＤが記録されている場合、すなわち、同じ管理オブジェクトに戻ってきた場合を条件としてよい。また、トポロジ探索処理の処理時間を短縮するため、一部のトポロジを探索せず、例えば、管理オブジェクトＩＤと関連ＩＤの組のリストの要素が一定数以上になった場合、以後の探索を打ち切ってもよい。また、構成管理ＤＢ１３２のデータモデル上、トポロジとしてあり得ないパターンを事前に定義できる場合、それ以上の探索を打ち切る条件としてもよい。例えば、あるサーバ上のコンポーネントから、ストレージ上のコンポーネントを介し、別のサーバ上のコンポーネントまたはスイッチ上のコンポーネントまで辿った場合、それ以上の探索を打ち切る条件を定義できる場合は、それ以上の探索を打ち切る条件としてもよい。

ステップＳ２２２０において、関連探索サブプログラムは、構成管理ＤＢ１３２から当該エントリが属するテーブル名を取得する。

ステップＳ２２２１において、関連探索サブプログラムは、受信した原因イベント、構成管理ＤＢ１３２の当該エントリ、ステップＳ２２２０で取得したテーブル名、管理オブジェクトＩＤおよび関連ＩＤの組のリストを入力として、関連探索処理を再帰的に呼び出すために、起動する。

トポロジ探索処理および関連探索処理において、トポロジ情報、トポロジ取得方式およびイベントの組み合わせの一覧を取得する具体例を以下に説明する。

例えば、ステップＳ２１１１において、原因イベントとして、図２のエントリ２１１を、それ以外のイベントとして、エントリ２１２を受信する。ステップＳ２１１２の繰り返し処理で、エントリ２１２を選択した場合、エントリ２１２のコンポーネントＩＤ２０３からコンポーネントＩＤ「ＤＲＩＶＥ１」を取得する（ステップＳ２１１３）。

次に、コンポーネントＩＤ「ＤＲＩＶＥ１」が格納されたエントリ８１１と、エントリ８１１が格納されたテーブルの名称「ディスクドライブ」とを取得する（ステップＳ２１１４）。そして、トポロジ情報とトポロジ取得方式を記録するためのリストを生成し、コンポーネントＩＤ「ＤＲＩＶＥ１」および空の関連ＩＤを先頭に追加する（ステップＳ２１１５）。

次に、エントリ２１１、エントリ８１１、テーブル名「ディスクドライブ」、および先頭の要素が「ＤＲＩＶＥ１」のリストを入力として、関連探索処理を起動する（ステップＳ２１１６）。関連探索処理は、これらの値をパラメータとして受信する（ステップＳ２２１１）。

次に、関連テーブル１３３から、テーブル名Ｘ１５０２およびテーブル名Ｙ１５０４の各フィールドの値が「ディスクドライブ」となるエントリ１５１１、１５１２、１５１３を取得する（ステップＳ２２１２）。ステップＳ２２１３の繰り返し処理で、エントリ１５１３を選択した場合、エントリ８１１の接続先ターゲットＷＷＮ８０５の値「２０：００：００：００：００：００：００：０１」と、ＬＵＮ＿ＩＤ８０６の値「０」を取得する。そして、構成管理ＤＢの論理ボリュームテーブル９００を参照して、ポートＷＷＮ９０２のフィールドの値が「２０：００：００：００：００：００：００：０１」であり、かつ、ＬＵＮ＿ＩＤ９０３のフィールドの値が「０」であるエントリ９１１を取得する（ステップＳ２２１４）。

ステップＳ２２１４からの繰り返し処理で、エントリ９１１を選択した場合、エントリ９１１のコンポーネントＩＤ「ＶＯＬ１」と、エントリ１５１３の関連ＩＤ「ＡＳ３」とを組みにして、受信したリストの先頭に追加する（ステップＳ２２１６）。したがって、この時点でリストは「ＶＯＬ１，ＡＳ３」−「ＤＲＩＶＥ１，ｅｍｐｔｙ」の要素と順序を持つ。

次に、ステップＳ２２１７において、エントリ９１１のコンポーネントＩＤ「ＶＯＬ１」と原因イベントのエントリ２１２のコンポーネントＩＤは異なるため、処理はステップＳ２２１９に進む。ステップＳ２２１９において、関連探索打ち切り条件を満たしていない場合はステップＳ２２２０に進む。

次に、エントリ９１１が属するテーブル名「論理ボリューム」を取得する（ステップＳ２２２０）。そして、原因イベントのエントリ２１２、エントリ９１１、テーブル名「論理ボリューム」、および、リスト「ＶＯＬ１，ＡＳ３」−「ＤＲＩＶＥ１，ｅｍｐｔｙ」を入力として、関連探索処理を起動する。以降の関連探索処理で、ステップＳ２２１３の繰り返し処理においてエントリ１５２２を選択し、ステップＳ２２１５でエントリ１０１１を選択した場合、ステップＳ２２１７において、エントリ１０１１は原因イベントのコンポーネントＩＤ「ＲＧ１」を有するため、ステップＳ２２１８に進む。

そして、リスト「ＲＧ１，ＡＳ１２」−「ＶＯＬ１，ＡＳ３」−「ＤＲＩＶＥ１，ｅｍｐｔｙ」から「ＲＧ１−ＶＯＬ１−ＤＲＩＶＥ１」というトポロジ情報と、「ＡＳ１２−ＡＳ３」というトポロジ取得方式を生成して、両者を組み合わせ、探索結果メモリとして、メモリ１１２に記録する。

このようにして、複数のトポロジ情報とトポロジ取得方式との組み合わせが、メモリ１１２に記録される。トポロジ探索処理のステップＳ２１１７に戻り、探索結果メモリから、例えば「ＲＧ１−ＶＯＬ１−ＤＲＩＶＥ１」というトポロジ情報と、「ＡＳ１２−ＡＳ３」というトポロジ取得方式の組み合わせを取得した場合、その組み合わせに対してイベントを示すエントリ２１２を組み合わせてメモリ１１２に記録する（ステップＳ２１１８）。そして、ステップＳ２１１７で記録した情報を呼び出し元プログラムに渡す。

なお、本実施例の「トポロジ探索処理」において、イベント毎に、イベントが発生した管理オブジェクトから原因管理オブジェクトまでのトポロジを探索し、トポロジ取得方式を生成している。これに対し、あるイベントに対応するトポロジを探索した際に、探索中に別のイベントの発生管理オブジェクトを辿った場合、途中経路に出現した管理オブジェクトのトポロジ探索処理は省略するなどの処理を行い、処理を高速化してもよい。

図２３Ａおよび図２３Ｂは、本実施例のメタルール生成プログラム１２１のステップＳ１８１８で実行されるメタルール候補生成処理の例のフローチャートである。

メタルール候補生成処理は、トポロジ探索処理で取得したトポロジ取得方式と、ルール作成者が指定した原因イベント、影響イベントからメタルール３００を生成し、新規メタルール候補としてルール作成者に提示する処理である。

ステップＳ２３１１において、メタルール候補生成サブプログラムは、原因イベントを示すイベントテーブル１３１のエントリ、影響イベントを示すイベントテーブル１３１のエントリ、および、トポロジ探索処理から取得したイベント、トポロジ情報およびトポロジ取得方式の組み合わせの一覧をパラメータとして受信する。

ステップＳ２３１２において、メタルール候補生成サブプログラムは、原因イベントのイベント種別２０４の値、装置ＩＤ２０２に格納された値が属する装置種別、および、コンポーネントＩＤ２０３に格納された値が属するコンポーネント種別を取得する。本実施例においては、構成管理ＤＢ１３２の各テーブルが管理オブジェクト種別毎に作成されているため、各管理オブジェクトＩＤが属する構成管理ＤＢ１３２のテーブル名を取得する。

ステップＳ２３１３において、メタルール候補生成サブプログラムは、影響イベントのイベント種別２０４の値、および、装置ＩＤ２０２またはコンポーネントＩＤ２０３が属する管理オブジェクト種別（構成管理ＤＢ１３２のテーブル名）を取得する。

ステップＳ２３１４において、メタルール候補生成サブプログラムは、ステップＳ２３１２、Ｓ２３１３で取得した装置種別、コンポーネント種別およびイベント種別を組み合わせ、メタルールのＩＦ部３１１を生成する。

ステップＳ２３１５において、メタルール候補生成サブプログラムは、ステップＳ２３１２で取得した原因イベントの装置種別、コンポーネント種別およびイベント種別を組み合わせ、メタルールのＴＨＥＮ部３１２を生成する。そして、ステップＳ２３１４で生成したＩＦ部３１１と、ステップＳ２３１５で生成したＴＨＥＮ部３１２とを組み合わせてメタルール３００を生成する。

ステップＳ２３１６において、メタルール候補生成サブプログラムは、ステップＳ２３１５で生成したメタルール３００のメタルールＩＤ３１３に、メタルールリポジトリ１３５においてメタルールを一意に識別できる識別子を設定する。

ステップＳ２３１７において、メタルール候補生成サブプログラムは、受信したイベント、トポロジ情報およびトポロジ取得方式の組み合わせの一覧から、トポロジ情報とトポロジ取得方式との組み合わせの一覧を抽出する。そして、抽出された一覧を入力とし、トポロジ取得方式選択処理を起動する。トポロジ取得方式選択処理は、入力されたトポロジ取得方式の一覧の中から、メタルールが利用するトポロジ取得方式一覧を取得する処理である。

ステップＳ２３１８において、メタルール候補生成サブプログラムは、ステップＳ２３１７で取得した全てのトポロジ取得方式について、ステップＳ２３１９からＳ２３２３の処理を繰り返す。

ステップＳ２３１９において、メタルール候補生成サブプログラムは、当該トポロジ取得方式がトポロジ取得方式リポジトリ１３４に含まれているか否かを判定する。条件を満たす場合、処理はステップＳ２３２２に進む。一方、条件を満たさない場合、処理はステップＳ２３２０に進む。

ステップＳ２３２０において、メタルール候補生成サブプログラムは、当該トポロジ取得方式１６００の方式ＩＤ１６０１に、トポロジ取得方式リポジトリ１３４において一意に識別できる識別子を設定し、トポロジ取得方式１６００をトポロジ取得方式リポジトリ１３４に登録する。

ステップＳ２３２１において、メタルール候補生成サブプログラムは、ステップＳ２３２０において方式ＩＤ１６０１に設定した識別子をメタルール３００のトポロジ取得方式ＩＤ３１４に設定する。

また、ステップＳ２３１９において、処理がステップＳ２３２２に進んだ場合、ステップＳ２３２２において、メタルール候補生成サブプログラムは、トポロジ取得方式リポジトリ１３４から、当該トポロジ取得方式と等しい方式１６００の方式ＩＤ１６０１の値を取得する。

ステップＳ２３２３において、メタルール候補生成サブプログラムは、ステップＳ２３２２で取得した方式ＩＤ１６０１の値をメタルール３００のトポロジ取得方式ＩＤ３１４に設定する。

その後、ステップＳ２３２４において、メタルール候補生成サブプログラムは、生成したメタルール３００をメタルール候補生成処理の呼び出し元プログラムに渡す。なお、ステップＳ２３２１またはＳ２３２３で格納した複数のトポロジ取得方式が関連ＩＤのリストの全てまたは一部が一致していた場合、トポロジ取得方式を結合して一つのトポロジ取得方式として作成し、メタルール３００のトポロジ取得方式ＩＤ３１４に登録してもよい。

例えば、ステップＳ２３１１において、原因イベントとしてイベントテーブル１３１のエントリ２１１を取得し、影響イベントとしてエントリ２１２を取得し、ステップＳ２３１７において、図１６に示すトポロジ取得方式１６００Ａを取得した場合、図３に示すメタルール３００が生成される。

図２４は、本実施例のメタルール候補生成処理のステップＳ２３１７で実行されるトポロジ取得方式選択処理の例のフローチャートである。

トポロジ取得方式選択処理では、ルール作成者に各影響イベントに対応するトポロジ情報を提示し、各影響イベントに対応するトポロジ取得方式を一つ選択させることによって、一つまたは複数のトポロジ取得方式の中からメタルール３００が利用する方式を絞り込む。

ステップＳ２４１１において、トポロジ取得方式選択サブプログラムは、イベント、トポロジ情報およびトポロジ取得方式の組み合わせの一覧をパラメータとして受信する。

ステップＳ２４１２において、トポロジ取得方式選択サブプログラムは、表示モジュール１２５を起動し、受信したイベントとトポロジ情報の組み合わせを出力デバイス１１７に表示する。

ステップＳ２４１３において、トポロジ取得方式選択サブプログラムは、ルール作成者が各影響イベントに対応して選択した一つのトポロジのトポロジ情報を受信する。

ステップＳ２４１４において、トポロジ取得方式選択サブプログラムは、ステップＳ２４１１で受信したトポロジ情報およびトポロジ取得方式の組み合わせの一覧の中から、ステップＳ２４１３で受信したトポロジ情報に対応するトポロジ取得方式を取得し、呼び出し元プログラムに渡す。

図２５Ａおよび図２５Ｂは、本実施例のメタルール生成プログラム１２１のステップＳ１８１９で実行されるメタルール検証情報表示処理の例のフローチャートである。

メタルール検証情報表示処理は、生成したメタルールを用いて正しい障害解析が可能かを検証するためのヒント情報を表示する処理である。ルール作成者は、表示されたヒント情報に基づいて、メタルール生成プログラム１２１がステップＳ１８１８で生成したメタルール３００を、以降、管理対象システムで発生する障害の解析に利用するかを決定する。具体的には、以下の２点を検証用の情報として表示する。

（１）メタルール３００を、最新の管理対象システムの構成に適用し、展開ルールを生成して、全てまたは一部の展開ルールを表示する。また、一つのメタルール３００に対応して生成される展開ルール数を表示する。これにより、トポロジ取得方式選択処理で選択したトポロジ取得方式に基づいて、実際の管理対象システム構成にメタルール３００を適用した場合に、正しい展開ルールが生成されるかの検証や、管理対象システムを構成する装置数に対して展開ルールが多いか、少ないかなどを検証できる。

（２）メタルール３００が、過去に発生した障害に対して有効であるかを表示する。すなわち、メタルールのＩＦ部３１１が示すイベントが同じタイミングに発生した例が過去にあるかを判定し、同じタイミングに発生した例がある場合は、イベントテーブル１３１の情報に基づいて発生回数を導出し、導出した発生回数を表示する。メタルールのＩＦ部３１１が示すイベントが同じタイミングに発生した例が過去にある場合、メタルールが有効であることが分かる。

ステップＳ２５１１において、メタルール検証情報表示サブプログラムは、メタルール３００をパラメータとして受信する。

ステップＳ２５１２において、メタルール検証情報表示サブプログラムは、表示モジュール１２５を起動し、メタルールを出力デバイス１１７に表示する。

ステップＳ２５１３において、メタルール検証情報表示サブプログラムは、メタルール３００のトポロジ取得方式ＩＤ３１４が示すトポロジ取得方式１６００をトポロジ取得方式リポジトリ１３４から取得する。

ステップＳ２５１４において、メタルール検証情報表示サブプログラムは、最新のシステム構成情報を示す構成管理ＤＢ１３２から、ステップＳ２５１３のトポロジ取得方式１６００が示すトポロジに該当するトポロジ情報を全て取得する。

ステップＳ２５１５において、メタルール検証情報表示サブプログラムは、ステップＳ２５１４で取得した全てのトポロジに対して、ステップＳ２５１６の処理を繰り返す。

ステップＳ２５１６において、メタルール検証情報表示サブプログラムは、当該トポロジ情報内のエントリ一覧の中から、メタルール３００のＩＦ部３１１の条件要素、またはＴＨＥＮ部３１２が指定するコンポーネント種別または装置種別に該当するエントリを抽出する。そして、抽出されたエントリおよびメタルール３００の情報を組み合わせて展開ルール１７００を生成する。

ステップＳ２５１７において、メタルール検証情報表示サブプログラムは、ステップＳ２５１２で表示したメタルールの情報に加えて、ステップＳ２５１６で取得した展開ルールおよび取得した展開ルールの数を表示する。

例えば、ステップＳ２５１１において、メタルール３００を受信し、最新の構成情報を示す構成管理ＤＢ１３２のテーブルが図４から図１３に示すテーブルである場合、ステップＳ２５１３で取得するトポロジ取得方式は図１６Ａに示すトポロジ取得方式１６００であり、ステップＳ２５１４で取得するトポロジの情報は「エントリ８１１（ＤＲＩＶＥ１），エントリ９１１（ＶＯＬ１），エントリ１０１１（ＲＧ１）」「エントリ８１２（ＤＲＩＶＥ２），エントリ９１３（ＶＯＬ３），エントリ１０１３（ＲＧ３）」「エントリ９１４（ＤＲＩＶＥ４），エントリ９１２（ＶＯＬ２），エントリ１０１２（ＲＧ２）」の三つである。ステップＳ２５１６において、これら三つのトポロジ情報およびメタルール３００に基づいて、図１７Ａから図１７Ｃに示す展開ルール１７００Ａ、１７００Ｂ、１７００ｃを生成する。このため、ステップＳ２５１７においては、これら三つの展開ルールおよび生成した展開ルールの数「３」を出力デバイス１１７に表示する。

ステップＳ２５１８において、メタルール検証情報表示サブプログラムは、受信したメタルール３００のＩＦ部３１１の全ての条件要素に合致するイベントをイベントテーブル１３１から検索し、取得する。

検索範囲はイベントテーブル１３１全てのエントリであってもよいし、特定の期間内に発生したイベントに検索範囲を限定してもよい。その場合、ルール作成者が期間を指定することができる。

例えば、受信したメタルールが図３に示すメタルール３００であり、イベントテーブル１３１が図２に示すテーブルである場合、メタルール３００の条件要素は「ストレージ ＲＡＩＤグループ ＷｒｉｔｅＨｉｔＰｅｒｆＥｒｒｏｒ」と「サーバ ディスクドライブ ＡｖｅｒａｇｅＳｅｃＰｅｒＸｆｅｒＥｒｒｏｒ」である。このため、これらに合致するイベントは図２のエントリ２１１とエントリ２１２となる。

ステップＳ２５１９において、メタルール検証情報表示サブプログラムは、ステップＳ２５１８で取得した全イベントに対して、ステップＳ２５２０からＳ２５２６の処理を繰り返す。

ステップＳ２５２０において、メタルール検証情報表示サブプログラムは、当該イベントが処理済みかを判定する。条件を満たす場合、次のイベントについてステップＳ２５１９からの繰り返し処理を実行する。一方、条件を満たさない場合、処理はステップＳ２５２１に進む。

ステップＳ２５２１において、メタルール検証情報表示サブプログラムは、メタルール３００、当該イベントの発生日時２０５、装置ＩＤ２０２、コンポーネントＩＤ２０３およびイベント種別２０４を入力として、ルール展開処理を起動し、展開ルール一覧を取得する。

ステップＳ２５２２において、メタルール検証情報表示サブプログラムは、ステップＳ２５２１で取得した全ての展開ルールに対し、ステップＳ２５２３からステップＳ２５２６の処理を繰り返す。

ステップＳ２５２３において、メタルール検証情報表示サブプログラムは、イベントテーブル１３１において、当該展開ルールのＩＦ部１７１１に記述された全てのイベントが、当該イベントの発生日時から所定の期間内に発生しているかを判定する。条件を満たす場合、処理はステップＳ２５２４に進む。一方、条件を満たさない場合、次の展開ルールについてステップＳ２５２２からの繰り返し処理を実行する。

ステップＳ２５２４において、メタルール検証情報表示サブプログラムは、当該展開ルールおよびステップＳ２５２３において展開ルール１７００のＩＦ部１７１１に記述されたイベントに合致したイベント（当該イベントを含む）の組み合わせを、メモリ１１２に記録する。

例えば、展開ルールが図１７Ａに示す展開ルール１７００であり、イベントが図２のエントリ２１１であり、「所定の期間」が前後１０分以内である場合、図２に示すイベントテーブル１３１を参照すると、エントリ２１１の発生から５分後にエントリ２１２が示すイベントが発生しており、エントリ２１１およびエントリ２１２によって、図１７Ａに示す展開ルール１７００のＩＦ部１７１１に記述されたイベントを全て満たす。このため、ステップＳ２５２３における条件を満たすことになる。したがって、ステップＳ２５２４において、展開ルール１７００、イベントを示すエントリ２１１およびエントリ２１２の組み合わせをメモリ１１２に記録する。

ステップＳ２５２５において、メタルール検証情報表示サブプログラムは、ステップＳ２５２４において記録されたイベント一覧を全て処理済みイベントとして登録する。

ステップＳ２５２６において、メタルール検証情報表示サブプログラムは、ステップＳ２５１７の表示に加えて、ステップＳ２５２４で記録した展開ルール、イベント一覧（または、それらの組み合わせ）および組み合わせの数を表示する。

したがって、ステップＳ２５２６によって過去に生成したメタルール３００が適用される障害事例の内容および発生回数をメタルール作成者に提示することができる。また、イベントの履歴と展開ルールとを比較することによって、展開ルールが正しいかを検証することができる。

例えば、図２５Ａおよび図２５Ｂに示す方法においては、メタルール３００が適用される障害事例が少ない場合、メタルール３００のＩＦ部に記述された条件要素に余分なものが含まれる可能性があるなどの判断をすることができる。ＩＦ部に余分な条件要素が含まれる場合、障害解析時に、後述する「展開ルールのイベント受信率」が１００％より低くなり、適切な障害解析結果を提示できない。

なお、図２５Ａおよび図２５Ｂに示す方法は、イベントテーブルの中からメタルールのＩＦ部が示す障害イベントのみを表示するが、それらの障害イベントの発生時刻から所定の期間内に発生した別の障害イベントも合わせて表示してもよい。これにより、生成したメタルールのＩＦ部に記述された条件要素が不足している可能性があるなどを判断することができる。ＩＦ部の条件要素が不足している場合、障害解析時に、後述する「展開ルールのイベント受信率」が本来示すべき値より高くなり、適切な障害解析結果を提示できない。

また、図２５Ａおよび図２５Ｂに示す方法は、ステップＳ２５２１で一度メタルールから展開ルールを生成し、そのＩＦ部の条件要素に合致する障害イベントをイベントテーブルから検索する。これにより、検索対象を、メタルールを適用するトポロジに限定した上で、メタルールに対応する障害事例が発生したことがあるかを提示することができる。

なお、ステップＳ２５１４においては、処理の高速化のために、当該トポロジ取得方式で取得できる全てのトポロジ情報に対してメタルールを適用するのではなく、一部のトポロジ情報に対してメタルールを適用してもよい。この場合、ステップＳ２５１７において、当該トポロジ取得方式で取得できる全てのトポロジ情報の数に対して、何パーセントのトポロジ情報を抽出したかの概算を表示してもよい。

また、ステップＳ２５２６において、ステップＳ２５２４で記録した展開ルールとイベント一覧の組み合わせの数だけでなく、展開ルールのＴＨＥＮ部に記述されたイベントの過去の発生回数に対応して、ステップＳ２５２３において、展開ルールのＩＦ部の条件を満たした回数（または割合）を表示してもよい。

図２６は、本実施例のメタルール検証情報表示処理のステップＳ２５１６、Ｓ２５２１、および、障害解析プログラム１２７のステップＳ２８１４で実行されるルール展開処理の例のフローチャートである。

ルール展開処理は、入力されたメタルールを、入力されたコンポーネントＩＤ（または装置ＩＤ）が示す管理オブジェクトを起点とするトポロジに適用し、展開ルールを生成する処理である。入力する時刻は、どの時刻の構成管理ＤＢ１３２を利用してトポロジ情報を取得するかを指定する。

ステップＳ２６１１において、ルール展開サブプログラムは、メタルール３００、日時、コンポーネントＩＤ（または装置ＩＤ）およびイベント種別をパラメータとして受信する。

ステップＳ２６１２において、ルール展開サブプログラムは、メタルール３００のトポロジ取得方式ＩＤ３１４で指定する識別子のトポロジ取得方式１６００を、トポロジ取得方式リポジトリ１３４から取得する。

ステップＳ２６１３において、ルール展開サブプログラムは、構成管理ＤＢ１３２のテーブルの内、ステップＳ２６１１で受信した日時における構成情報を示すテーブルを抽出する。

ステップＳ２６１４において、ルール展開サブプログラムは、受信した装置ＩＤ、またはコンポーネントＩＤを起点として、ステップＳ２６１２で取得したトポロジ取得方式１６００に基づいて、ステップＳ２６１３で抽出した構成管理ＤＢ１３２のテーブルからメタルールを適用するトポロジ情報を取得する。

例えば、ステップＳ２６１１でコンポーネントＩＤ「ＲＧ１」を受信し、ステップＳ２６１２で図１６Ａに示すトポロジ取得方式１６００を取得する。そして、ステップＳ２６１３で抽出した構成管理ＤＢ１３２のテーブルが図４から図１３に示すテーブルであった場合、一つのトポロジ「エントリ１０１１（ＲＧ１），エントリ９１１（ＶＯＬ１），エントリ８１１（ＤＲＩＶＥ１）」が取得される。

ステップＳ２６１５において、ルール展開サブプログラムは、ステップＳ２６１４で取得した全てのトポロジ情報に対して、ステップＳ２６１６の処理を繰り返す。

ステップＳ２６１６において、ルール展開サブプログラムは、当該トポロジ情報内のエントリ一覧の中から、メタルール３００のＩＦ部３１１の条件要素、またはＴＨＥＮ部３１２が指定するコンポーネント種別（または装置種別）に該当するエントリを抽出し、抽出されたエントリの情報およびメタルール３００の情報を組み合わせて展開ルール１７００を生成する。

例えば、ステップＳ２６１１で図３のメタルール３００を受信し、ステップＳ２６１６の繰り返し処理においてトポロジ「エントリ１０１１（ＲＧ１），エントリ９１１（ＶＯＬ１），エントリ８１１（ＤＲＩＶＥ１）」が選択された場合、メタルール３００のＴＨＥＮ部３１２はコンポーネント種別がＲＡＩＤグループであるため、トポロジ情報の中からエントリ１０１１のコンポーネントＩＤ「ＲＧ１」および装置ＩＤ「ＳｔＡ」を取得し、展開ルールのＴＨＥＮ部１７１２として「ＳｔＡ ＲＧ１ ＷｒｉｔｅＨｉｔＰｅｒｆＥｒｒｏｒ」を生成する。同様にＩＦ部の条件要素も生成し、展開ルール１７００Ａを生成する。

ステップＳ２６１７において、ルール展開サブプログラムは、ステップＳ２６１６で生成した展開ルール１７００の一覧をルール展開処理の呼び出し元プログラムに渡す。

＜障害解析の処理＞
図２７Ａおよび図２７Ｂは、本実施例の管理コンピュータ１０１において障害解析プログラム１２３によって実行される障害解析処理の例のフローチャートである。

障害解析プログラム１２３は、イベント受信プログラム１２２が管理対象装置からイベントを受信し、イベントテーブル１３１にイベント情報を書き込んだ後に呼び出されることにより、処理を開始してよい。

障害解析プログラム１２３は、受信したイベントと、メタルールリポジトリ１３５内のメタルール３００に基づいて、必要な展開ルール１７００を生成し、障害原因候補とその影響範囲をシステムの運用管理者に提示すべく障害解析処理を実行する。

ステップＳ２７１１において、障害解析プログラム１２３は、未処理のイベントをイベントテーブル１３１から取得する。

ステップＳ２７１２において、障害解析プログラム１２３は、ステップＳ２７１１で取得したイベントを処理済みのイベントとして登録する。

ステップＳ２７１３において、障害解析プログラム１２３は、ステップＳ２７１１で取得したイベントに対応するメタルール３００をメタルールリポジトリ１３５から取得する。

例えば、ステップＳ２７１１でエントリ２２２が示すイベントを取得した場合、装置ＩＤ２０２の値が「ＳｖＢ」であり、コンポーネントＩＤ２０３の値が「ＤＲＩＶＥ４」であり、それぞれの装置種別は「サーバ」であり、コンポーネント種別は「ディスクドライブ」である。このため、メタルールのＩＦ部に「サーバ ディスクドライブ ＡｖｅｒａｇｅＳｅｃＰｅｒＸｆｅｒＥｒｒｏｒ」の条件要素を持つ図３のメタルール３００を取得する。

ステップＳ２７１４において、障害解析プログラム１２３は、ステップＳ２７１３で取得した全てのメタルールについて、ステップＳ２７１５からＳ２７１８の処理を繰り返す。

ステップＳ２７１５において、障害解析プログラム１２３は、当該メタルール、ステップＳ２７１１で取得したイベントの発生日時２０５、装置ＩＤ２０２、コンポーネントＩＤ２０３およびイベント種別２０４を入力として、ルール展開処理を起動し、展開ルール一覧を取得する。

ステップＳ２７１６において、障害解析プログラム１２３は、ステップＳ２７１５において取得した全ての展開ルールについて、ステップＳ２７１７からＳ２７１８の処理を繰り返す。

ステップＳ２７１７において、障害解析プログラム１２３は、当該展開ルールが既に展開ルールリポジトリ１３６に含まれているかを判定する。条件を満たす場合、次の展開ルールについてステップＳ２７１４からの繰り返し処理を実行する。一方、条件を満たさない場合、処理はステップＳ２７１８に進む。

ステップＳ２７１８において、障害解析プログラム１２３は、当該展開ルールを展開ルールリポジトリ１３６に登録する。

ステップＳ２７１９において、障害解析プログラム１２３は、ステップＳ２７１１で取得したイベントをＩＦ部１７１１の条件要素に含む展開ルール一覧を展開ルールリポジトリ１３６から取得する。

ステップＳ２７２０において、障害解析プログラム１２３は、ステップＳ２７１９で取得した全ての展開ルールについて、ステップＳ２７２１からＳ２７２３の処理を繰り返す。

ステップＳ２７２１において、障害解析プログラム１２３は、ステップＳ２７１１において取得したイベントに該当する当該展開ルールの条件要素の受信フラグ１７０４を「１」に変更する。

ステップＳ２７２２において、障害解析プログラム１２３は、当該展開ルールのイベント受信率を計算する。各展開ルールのイベント受信率は、以下の式によって計算することができる。

イベント受信率＝受信フラグ１７０４が「１」の条件要素数／条件要素の総数

例えば、図１７Ａに示す展開ルール１７００においては、条件要素の数は二つであり、そのうち受信フラグ１７０４が「１」の条件要素は一つであるため、イベント受信率は１／２（５０％）となる。

ステップＳ２７２３において、障害解析プログラム１２３は、表示モジュール１２５を起動し、当該展開ルールのＴＨＥＮ部１７１２を障害の原因候補とし、ＩＦ部の各条件要素を原因候補に対する影響範囲とし、さらに、ステップＳ２７２２で算出したイベント受信率を原因候補の確からしさとし、それらを解析結果として出力デバイス１１７に表示する。

なお、すでにＴＨＥＮ部１７１２の障害が原因候補として出力デバイス１１７に表示されている場合、高い方のイベント受信率を表示してもよい。

以上に説明したように、障害解析プログラム１２３が実行する処理によって、管理対象システムに障害が発生した場合、障害原因候補およびその影響範囲を自動的に導出し、システム運用管理者に提示することができる。

なお、障害解析プログラム１２３の処理を高速化するために、ステップＳ２７１５で展開ルールを生成する前に、生成しようとする展開ルールが既に展開ルールリポジトリ１３６内に含まれるかが分かるように、展開履歴を作成してもよい。

また、障害解析処理を高速化する公知の技術（例えば、特表２０１１−５１８３５９号公報に開示されるもの）を適用してもよい。また、イベントを受信するごとに展開ルールを生成せずに、障害が発生する前に全ての展開ルールを生成してもよい。

また、図２７Ａおよび図２７Ｂに示す障害解析プログラム１２３が実行する処理では、発生したイベントを含む展開ルールのみしか作成していないが、ステップＳ２７１５で取得した展開ルールのＴＨＥＮ部に記述されたイベントの情報、および当該イベントに関連するメタルールを入力として、ルール展開処理を起動し、ＴＨＥＮ部のイベントを含む展開ルールを全て生成し、それらの展開ルールも含めてステップＳ２７２０以降の処理を実行して解析結果を提示してもよい。これにより、ある原因候補に対する影響を受けて発生し得る全ての障害イベントを表示することができる。

以上で説明したメタルール生成プログラム１２１および障害解析プログラム１２３が実行する処理によって、ルール作成者が指定した原因イベントの情報および影響イベントの情報からメタルールを生成し、生成したメタルールに基づいて、同じパターンのトポロジ上で発生した障害を解析することができる。

例えば、システム運用管理者が、メタルール生成プログラム１２１の実行するステップＳ１８１２において、原因イベントとしてイベントテーブル１３１のエントリ２１１（ストレージＡのＲＡＩＤグループ０の書込処理のヒット率性能エラー）を選択し、ステップＳ１８１６において、影響イベントとしてエントリ２１２（サーバＡのＤドライブの転送時間性能エラー）を選択し、トポロジ取得方式選択処理が実行するステップＳ２４１３において、「ＤＲＩＶＥ１，ＶＯＬ１，ＲＧ１」に該当するトポロジを選択した場合、メタルール生成プログラム１２１は、図３に示すメタルール３００および図１６Ａに示すトポロジ取得方式１６００を生成する。そして、例えば、管理対象システムのサーバＢにおいて、イベントテーブル１３１のエントリ２２２が示すイベントが発生した場合、障害解析プログラム１２３によって、メタルール３００とトポロジ取得方式１６００Ａから図１７Ｃに示す展開ルール１７００が生成され、障害解析結果として「ストレージＡのＲＡＩＤグループ１の書込処理のヒット率性能エラーが原因である」という解析結果、および、影響範囲は「ストレージＡのＲＡＩＤグループ１の書込処理のヒット率性能エラー」、「サーバＢのＤドライブの転送時間性能エラー」であるという解析結果が運用管理者に提示される。

以上に説明したように、本発明の第１の実施例によれば、システム運用管理者が一つの原因イベントを選択し、一つまたは複数の影響イベントを選択すると、各イベントが発生した管理オブジェクトの種別を導出し、メタルール、およびメタルールを他の管理オブジェクトに適用するためのトポロジ取得方式を自動的に生成する。これにより、システム運用管理者は、障害解析機能の内部仕様を知ることなく、実際に管理しているシステムの情報および実際に発生したイベントを指定するだけで、メタルールを生成することができる。

前述した第１の実施例では、ルール作成者が、実際に発生した障害の情報に基づいて必要な情報を入力し、メタルールを生成する。第２の実施例では、実際に障害が発生していなくてもルールを作成できるように、ルール作成者がメタルールを作成するために入力する情報および入力画面が異なる。

また、第１の実施例では、原因管理オブジェクトおよび影響管理オブジェクトの実際のトポロジを探索し、トポロジ取得方式を生成する。その結果、管理対象システムのトポロジが複雑な場合、トポロジ探索処理の演算量が大きくなり、メタルールの生成に時間がかかる可能性がある。第２の実施例では、トポロジ探索処理を高速化するため、トポロジ探索処理のもう一つの方法として、実際の管理オブジェクトの関連を辿ってトポロジ情報を取得するのではなく、関連テーブルに登録された管理オブジェクトがとり得る関連を辿り、管理オブジェクトがとり得るトポロジの情報を取得する。これにより、トポロジ取得方式を生成する。

具体的には、実際に発生した障害のイベントではなく、原因となる管理オブジェクト種別、原因となるイベント種別、影響を受ける管理オブジェクト種別および影響を受けるイベント種別の入力を求める。そして、入力された影響管理オブジェクト種別を起点として、関連テーブル１３３のテーブル名を辿り、影響管理オブジェクト種別と原因管理オブジェクト種別がとり得るトポロジの情報を取得する。

第２の実施例において、システム構成、各装置の構成および各プログラムが実行する処理のうち、第１の実施例と同じものについては説明を省略する。第２の実施例を説明するための管理対象の例示的なハードウェアアーキテクチャおよび論理構成は、第１の実施例において前述したもの（図１）でよい。また、イベントテーブル１３１は図２に示す構成例でよく、メタルールリポジトリ１３５のメタルールは図３に示す構成例でよく、構成管理ＤＢ１３２のテーブルは図４から図１３に示す構成例でよく、関連テーブル１３３は図１５に示す構成例でよく、トポロジ取得方式リポジトリ１３４のトポロジ取得方式は図１６に示す構成例でよく、展開ルールリポジトリ１３６の展開ルールは図１７に示す構成例でよい。

また、第２の実施例において、第１の実施例と同様に、トポロジ取得方式選択処理は図２４に示す処理と同じでよく、メタルール検証情報表示処理は図２５に示す処理と同じでよく、ルール展開処理は図２６に示す処理と同じでよく、障害解析プログラム１２３が実行する処理は図２７に示す処理と同じでよい。

＜メタルール生成の処理＞
図２８は、第２の実施例の管理コンピュータ１０１でメタルール生成プログラム１２１が実行するメタルール生成処理の例のフローチャートである。

メタルール生成プログラム１２１は、入力デバイス１１４からのルール作成者の指示によって起動されるように構成されるとよい。

第２の実施例では、第１の実施例と異なり、実際に障害が発生していなくてもルールを作成できるようにするため、メタルール生成プログラム１２１では、実際に発生した障害のイベントではなく、原因となる管理オブジェクト種別、原因となる管理イベント種別、影響を受ける管理オブジェクト種別および影響を受けるイベント種別の入力を求め、入力された情報に基づいてメタルールを生成する。

ステップＳ２８１１において、メタルール生成プログラム１２１は、表示モジュール１２５を起動し、イベント情報入力画面を出力デバイス１１７に表示する。

図２９は、第２の実施例のイベント情報入力画面２９００の例を説明する図である。

イベント情報入力画面２９００は、例えば、図２９に例示するように、影響イベントの装置種別、コンポーネント種別およびイベント種別、原因イベントの装置種別、コンポーネント種別およびイベント種別を、各リストボックス２９０１〜２９０６から選択できるとよい。また、原因イベント情報に対して、メタルールの影響イベント情報を複数設定する場合には、追加ボタン２９０７を操作することによって、影響イベント情報を追加する機能を有するとよい。

また、装置種別のリストボックス２９０１および２９０４において一つの装置種別を選択すると、選択した装置種別に含まれるコンポーネントの種別のみを各リストボックス２９０２および２９０５に、それぞれ表示する機能を有するとよい。また、装置種別およびコンポーネント種別をリストボックス２９０１〜２９０２、２９０４〜２９０５から選択すると、リストボックス２９０３および２９０６には、選択した装置種別あるいはコンポーネント種別において発生し得るイベント種別のみを、それぞれ表示する機能を有するとよい。

なお、イベント情報入力画面２９００は、構成情報を表示する画面において、実際に管理されている管理対象装置およびそのコンポーネントを選択することによって、メタルール生成プログラム１２１が自動的に、装置およびコンポーネンツの種別を導出してもよい。

ステップＳ２８１２において、メタルール生成プログラム１２１は、ルール作成者が選択した原因イベント情報および影響イベント情報を受信する。具体的には、図２９のイベント情報入力画面２９００において、ルール作成者が影響イベント情報および原因イベント情報を、それぞれリストボックス２９０１〜２９０６で選択し、確定ボタン２９０８を操作すると、メタルール生成プログラム１２１は、選択されたイベントの情報を受信する。

ステップＳ２８１３において、メタルール生成プログラム１２１は、ステップＳ２８１２で受信した原因イベント情報および影響イベント情報を入力として、トポロジ探索処理を起動し、影響イベント情報およびトポロジ取得方式の組み合わせの一覧を取得する。

ステップＳ２８１４において、メタルール生成プログラム１２１は、ステップＳ２８１２で受信した原因イベント情報および影響イベント情報、および、ステップＳ２８１３で取得した影響イベント情報およびトポロジ取得方式の組み合わせの一覧を入力として、メタルール候補生成処理を起動し、メタルール３００を取得する。

ステップＳ２８１５において、メタルール生成プログラム１２１は、ステップＳ２８１４で取得したメタルール３００を入力として、メタルール検証情報表示処理を起動する。メタルール検証情報表示処理は、生成したメタルールを用いて正しい障害解析が可能かを検証するためのヒント情報を表示する処理であり、第１の実施例で説明した処理を利用することができる。

ステップＳ２８１６において、メタルール生成プログラム１２１は、ルール作成者が入力したメタルールの生成または破棄の決定を受信する。

ステップＳ２８１７において、メタルール生成プログラム１２１は、ステップＳ２８１６の入力が生成かを判定する。条件を満たす場合、処理はステップＳ２８１９へ進む。一方、条件を満たさない場合、処理は終了する。

ステップＳ２８１９において、メタルール生成プログラム１２１は、ステップＳ２８１４で取得したメタルール３００をメタルールリポジトリ１３５に登録する。

図３０は、第２の実施例のメタルール生成プログラム１２１のステップＳ２８１３で実行されるトポロジ探索処理の例のフローチャートである。

第２の実施例のトポロジ探索処理が受信するパラメータは、第１の実施例における入力に装置ＩＤおよびコンポーネントＩＤと異なり、装置種別およびコンポーネント種別が含まれる。そのため、パラメータとして入力された装置種別およびコンポーネント種別に含まれる装置およびコンポーネントがとり得るトポロジを関連テーブル１３３に基づいて導出し、メタルールが利用するトポロジ取得方式を取得する。

具体的には、影響イベント情報の管理オブジェクト種別を起点として、原因イベント情報の管理オブジェクト種別まで、関連テーブル１３３のエントリを辿ることによって、トポロジ取得方式を取得する。

ステップＳ３０１１において、トポロジ探索処理は、原因イベント情報と影響イベント情報をパラメータとして受信する。受信するパラメータは、メタルール生成プログラム１２１のステップＳ２８１２において受信した原因イベントおよび影響イベントの管理オブジェクト種別およびイベント種別である。

ステップＳ３０１２において、トポロジ探索処理は、ステップＳ３０１１で受信した全ての影響イベント情報について、ステップＳ３０１３からＳ３０１４の処理を繰り返す。

ステップＳ３０１３において、トポロジ探索処理は、原因イベント情報、当該影響イベント情報の管理オブジェクト種別（コンポーネント種別、またはコンポーネント種別が指定されていなければ装置種別）、および関連ＩＤを記録するリストを入力として、関連探索処理を起動する。なお、本実施例においては構成管理ＤＢ１３２のテーブル名は管理オブジェクト種別名と等しいため、入力される管理オブジェクト種別は構成管理ＤＢ１３２のテーブル名を示す。関連探索処理は、関連テーブル１３３の情報に基づいて、入力されたテーブル名を起点とし、原因イベント情報の管理オブジェクト種別が示すテーブル名までの関連を辿り、トポロジ取得方式を生成して、探索結果メモリとしてメモリ１１２に記録する処理である。

ステップＳ３０１４において、トポロジ探索処理は、メモリ１１２に関連探索処理によって記録された探索結果メモリからトポロジ取得方式一覧を取得し、取得したトポロジ取得方式一覧を当該影響情報と組み合わせてメモリ１１２に記録する。

ステップＳ３０１５において、トポロジ探索処理は、ステップＳ３０１４で記録した影響情報およびトポロジ取得方式の組み合わせの一覧をトポロジ探索処理の呼び出し元プログラムに渡す。

図３１は、トポロジ探索処理のステップＳ３０１３で実行される関連探索処理の例のフローチャートである。

第２の実施例における関連探索処理は、関連テーブル１３３のエントリに登録されたテーブル名を辿り、受信した影響イベント情報の管理オブジェクト種別（テーブル名）と原因イベント情報の管理オブジェクト種別（テーブル名）がとり得るトポロジを導出し、トポロジ取得方式を生成する処理である。

ステップＳ３１１１において、関連探索サブプログラムは、原因イベント情報、テーブル名および関連ＩＤを記録するリストをパラメータとして受信する。

ステップＳ３１１２において、関連探索サブプログラムは、ステップＳ３１１１で受信したテーブル名とテーブル名Ｘ１５０２またはテーブル名Ｙ１５０４の値が等しい全てのエントリを関連テーブル１３３から取得する。

ステップＳ３１１３において、関連探索サブプログラムは、ステップＳ３１１２で取得した関連テーブル１３３のエントリについて、ステップＳ３１１４からＳ３１１９の処理を繰り返す。

ステップＳ３１１４において、関連探索サブプログラムは、当該関連テーブルのエントリの関連ＩＤを、関連ＩＤを記録するリストの先頭に追加する。

ステップＳ３１１５において、関連探索サブプログラムは、当該関連テーブルのエントリに基づいて、受信したテーブル名と関連するテーブル名を取得する。

ステップＳ３１１６において、関連探索サブプログラムは、ステップＳ３１１５で取得したテーブル名が、受信した原因イベント情報の管理オブジェクト種別を示すかを判定する。条件を満たす場合、処理はステップＳ３１１７に進む。一方、条件を満たさない場合、処理はステップＳ３１１８に進む。

ステップＳ３１１７において、関連探索サブプログラムは、関連ＩＤを記録したリストからトポロジ取得方式を生成し、探索結果メモリとしてメモリ１１２に記録する。

ステップＳ３１１８において、関連探索サブプログラムは、関連探索の打ち切り条件を満たしているか否かを調べる。条件を満たす場合、次の関連テーブルのエントリについてステップＳ３１１３からの繰り返し処理を実行する。一方、条件を満たさない場合、ステップＳ３１１９に進む。関連探索の打ち切り条件は、例えば、関連ＩＤのリストの中に、同じ関連ＩＤが所定の回数以上記録されている場合を条件としてもよい。また、トポロジ探索処理の処理時間を短縮するため、一部のトポロジを探索せず、例えば、関連ＩＤのリストの要素が一定数以上になった場合、以後の探索を打ち切ってもよい。

ステップＳ３１１９において、関連探索サブプログラムは、受信した原因情報、ステップＳ３１１５で取得したテーブル名および関連ＩＤのリストを入力として、関連探索処理を再帰的に起動する。

例えば、トポロジ探索処理が、原因情報として、装置種別「ストレージ」、コンポーネント種別「ＲＡＩＤグループ」、イベント種別「書込処理のヒット率性能エラー」を入力し、さらに、影響イベント情報のテーブル名として「ディスクドライブ」を、関連探索処理に入力し、関連探索処理がそれらを受信した（ステップＳ３１１１）。

この場合、関連テーブル１３３のエントリ１５１１、１５１２、１５１３（図１５Ａ参照）を取得する（ステップＳ３１１２）。ステップＳ３１１３の繰り返し処理でエントリ１５１３を選択した場合、関連ＩＤのリストには「ＡＳ３」が追加され（ステップＳ３１１４）、テーブル名「論理ボリューム」を取得する（ステップＳ３１１５）。取得したテーブル名「論理ボリューム」と原因イベント情報のコンポーネント種別「ＲＡＩＤグループ」とが一致しないため（ステップＳ３１１６）、原因イベント情報、テーブル名「論理テーブル」、関連ＩＤのリストを入力として再帰的に関連探索処理を起動する（ステップＳ３１１９）。

再帰的に起動した関連探索処理では、ステップＳ３１１３の繰り返し処理でエントリ１５２２が選択され、テーブル名「ＲＡＩＤグループ」を取得する（ステップ３１１５）。このため、ステップＳ３１１６で処理をステップＳ３１１７に進め、要素に「ＡＳ３，ＡＳ１２」を持つ関連ＩＤのリストからトポロジ取得方式を生成し、探索結果メモリとしてメモリ１１２に記録する。

図３２は、第２の実施例のメタルール生成プログラム１２１のステップＳ２８１４で実行されるメタルール候補生成処理の例のフローチャートである。

ステップＳ３２１１において、メタルール候補生成サブプログラムは、原因イベント情報、影響イベント情報、影響イベント情報およびトポロジ取得方式の組み合わせの一覧をパラメータとして受信する。

ステップＳ３２１２において、メタルール候補生成サブプログラムは、影響イベント情報の装置種別、影響イベント情報のコンポーネント種別、影響イベント情報のイベント種別、原因イベント情報の装置種別、原因イベント情報のコンポーネント種別、および原因イベント情報のイベント種別を組み合わせてメタルールのＩＦ部３１１を生成する。

ステップＳ３２１３において、メタルール候補生成サブプログラムは、原因イベント情報の装置種別、コンポーネント種別およびイベント種別を組み合わせてメタルールのＴＨＥＮ部３１２を生成し、ステップＳ３２１２で生成したＩＦ部３１１と組み合わせてメタルール３００を生成する。

ステップＳ３２１４において、メタルール候補生成サブプログラムは、メタルール３００を一意に識別する識別子をメタルールＩＤ３１３に設定する。

ステップＳ３２１５において、メタルール候補生成サブプログラムは、受信した影響情報とトポロジ取得方式の組み合わせの一覧を入力として、トポロジ取得方式選択処理を起動し、メタルールを適用するトポロジを取得するためのトポロジ取得方式の一覧を取得する。

ステップＳ３２１５から後の処理は、前述した第１の実施例のメタルール候補生成処理（図２３Ｂ）のステップＳ２３１８以後と同じである。

なお、第１の実施例ではトポロジ取得方式選択処理が起動する際に受信するパラメータは、イベント、トポロジ情報およびトポロジ取得方式の組み合わせの一覧であったが、第２の実施例では、トポロジ取得方式選択処理が起動する際に受信するパラメータは、影響イベント情報およびトポロジ取得方式の組み合わせの一覧である。このため、第２の実施例では、入力した各影響イベント情報と取得できるトポロジのパターンを出力デバイス１１７に表示し、ルール作成者に各影響イベント情報に対応した一つのトポロジのパターンを選択させるとよい。

以上が、本実施例におけるメタルールのメタルール生成プログラム１２１の処理である。

以上に説明したように、本発明の第２の実施例によれば、実際に障害が発生していない場合でもメタルールを作成することができる。また、構成管理ＤＢ１３２の情報に基づいて原因管理オブジェクトの実際のトポロジおよび影響管理オブジェクトの実際のトポロジを探索することなく、関連テーブル１３３のエントリのみを辿り、トポロジ取得方式を生成することによって、トポロジ探索処理の計算量を減らすことができる。その結果、メタルール生成の処理およびルール作成者への情報提示の処理を高速化することができる。

前述した第１および第２の実施例では、トポロジ取得方式選択処理において、生成したメタルールに対して適切なトポロジをルール作成者に選択させ、選択されたトポロジに基づいてメタルールと対応付けるトポロジ取得方式を決定する。

しかし、一つのメタルールに対応して多くのトポロジが候補として提示された場合、ルール作成者が適切なトポロジを選択することが困難であり、また、その作業のためのコストが大きくなる。

このため、第３の実施例では、一つのメタルールに対応して複数のトポロジ取得方式が候補となった場合、メタルールが利用すべきトポロジ取得方式の優先度を決定する。これにより、ルール作成者がメタルールに対応して利用するトポロジ取得方式を選択し易くなり、選択作業のコストを削減することができる。

第３の実施例において、システム構成、各装置の構成および各プログラムが実行する処理のうち、第１または第２の実施例と同じものについては説明を省略する。第３の実施例を説明するための管理対象の例示的なハードウェアアーキテクチャおよび論理構成は、第１の実施例において前述したもの（図１）でよい。また、イベントテーブル１３１は図２に示す構成例でよく、メタルールリポジトリ１３５のメタルールは図３に示す構成例でよく、構成管理ＤＢ１３２のテーブルは図４から図１３に示す構成例でよく、トポロジ取得方式リポジトリ１３４のトポロジ取得方式は図１６に示す構成例でよく、展開ルールリポジトリ１３６の展開ルールは図１７に示す構成例でよい。

また、第３の実施例において、第１の実施例と同様に、メタルール生成プログラム１２１が実行する処理は図１８に示す処理と同じでよく、障害解析プログラム１２３が実行する処理は図２７に示す処理と同じでよい。なお、メタルール生成プログラム１２１が実行する処理は図２８に示す第２の実施例の処理でもよい。

第３の実施例においては、メタルールが利用すべきトポロジ取得方式の優先度を決定するためにトポロジ取得方式選択処理、または関連テーブル１３３を変更する。本実施例においては、優先度決定のための方法を五つ記述する。したがって、第３の実施例では複数のトポロジ方式選択処理および関連テーブルの例について説明する。

＜トポロジ取得方式選択の処理およびトポロジ取得方式優先度決定の処理＞
第３の実施例では、一つのメタルールにおいて、１組の原因管理オブジェクトから影響管理オブジェクトまでのトポロジを取得する方式として、複数のトポロジ取得方式が候補となった場合、それらの中からトポロジ取得方式の優先度を決定する。

トポロジ取得方式は、メタルールの適用先を限定するために用いられる。ある装置で障害が発生した場合でも、関連しない装置には影響がない。さらに、限定された特定のトポロジ（例えば、ストレージの論理ボリュームを、サーバのディスクドライブがマウントしているというトポロジ等）上の管理オブジェクトでないと伝播しない障害もある。トポロジ取得方式を用いることによって、障害が伝播し得る特定のトポロジ上の管理オブジェクトの組み合わせに限定して、メタルールを適用する。限定しない場合は、不要な、または誤った展開ルールが生成されることになる。トポロジ取得方式によってメタルールを適用する範囲を限定することによって、運用管理者に不要な原因候補または誤った原因候補を提示することを抑制し、さらには不要な展開ルールの生成を抑制することで管理コンピュータ１０１の処理負荷を軽減できる。

本実施例では、メタルールをより適切な範囲に適用できるトポロジ取得方式から順にランク付けをして、優先度としてルール作成者に提示する。

以下に、五つの優先度の決定方法を説明する。

なお、本実施例では五つの方法を優先度の決定する方法の例を説明するが、障害解析の特徴に基づいて予め定義された基準を利用してトポロジ取得方式を評価し、優先度を決定する方法であれば、例示する五つの方法に限定されない。

＜方法１：関連の多重度を評価基準とした優先度決定方法＞
トポロジ取得方式の優先度を決定する第１の方法は、管理オブジェクトの関連の多重度を評価基準とする方法である。具体的には、取得できる影響管理オブジェクトと原因管理オブジェクトの組み合わせが多対多関係となるトポロジ取得方式より、１対多関係となる方式を優先し、１対多関係となる方式より１対１関係となる方式を優先する。

これは、トポロジ取得方式によって取得できる影響管理オブジェクトと原因管理オブジェクトの組み合わせが１対１関係であるということは、１対多または多対多関係より二つの管理オブジェクトの関係が限定されており、障害が伝播するトポロジを示している可能性が高い。

したがって、本実施例の方法１では、関連テーブル１３３の各エントリの関連の多重度を登録する。この多重度は、各管理オブジェクト種別の関連の多重度を示しており、実際の管理オブジェクトが持つ関連の数とは異なる意味である。そして、１組の影響管理オブジェクトから原因管理オブジェクトまでのトポロジを取得する方式として、複数のトポロジ取得方式が候補となった場合、トポロジ取得方式によって取得される各管理オブジェクト種別の関連に、多対多、１対多、多対１、１対１のいずれが含まれるかを判定して、トポロジ取得方式の優先度を決定する。

なお、本実施例では１対１、１対多、多対多の順で優先度を決定したが、これ以外の基準で多重度を評価し、トポロジ取得方式の優先度を決定してもよい。

図３３Ａおよび図３３Ｂは、第３の実施例の関連テーブル１３３のデータ構造の例を説明する図である。本実施例の関連テーブル１３３は、図３３Ａに示すエントリの下に、図３３Ｂに示すエントリが続く構造である。

方法１の関連テーブル１３３は六つのフィールドを持つ。関連ＩＤ３３０１、テーブル名Ｘ３３０２、フィールド名Ｘ３３０３、テーブル名Ｙ３３０４、フィールド名Ｙ３３０５は、それぞれ、第１の実施例の関連テーブル（図１５Ａ、図１５Ｂ）の関連ＩＤ１５０１、テーブル名Ｘ１５０２、フィールド名Ｘ１５０３、テーブル名Ｙ１５０４、フィールド名Ｙ１５０５と同じである。

多重度３３０６は、関連テーブル１３３の各エントリが示す構成管理ＤＢ１３２のテーブル間の関連の多重度である。すなわち、図１４に示すクラス図の多重度１４０５に該当する情報である。多重度３３０６を構成するフィールド３３０７およびフィールド３３０８には「多」、「１」のいずれかが登録される。フィールド３３０７は、テーブル名Ｙ３３０４が示すテーブルを起点としたテーブル名Ｘ３３０２が示すテーブルの多重度を登録し、フィールド３３０８は、テーブル名Ｘ３３０２が示すテーブルを起点としたテーブル名Ｙ３３０２が示すテーブルの多重度を登録する。

例えば、エントリ３３１１は、ディスクドライブとサーバとの関連を示しており、フィールド３３０７には「多」、フィールド３３０８には「１」が格納されている。この場合、ディスクドライブテーブルのエントリに関連するサーバテーブルのエントリは必ず一つ以下であり、サーバテーブルのエントリに関連するディスクドライブテーブルのエントリは複数になり得ることを示す。つまり、ディスクドライブを起点として関連するサーバは多対１関係、サーバを起点として関連するディスクドライブは１対多関係にあることを示す。

図３４Ａおよび図３４Ｂは、第３の実施例の第１の方法におけるトポロジ取得方式選択処理の例のフローチャートである。

本実施例では、第１の実施例の方法でトポロジ取得方式選択処理が実行される場合について説明しているため、受信するパラメータは「イベント、トポロジ情報およびトポロジ取得方式の組み合わせの一覧」であるが、第２の実施例の方法でトポロジ取得方式選択処理を実行する場合には、受信するパラメータが「影響イベント情報およびトポロジ取得方式の組み合わせの一覧」でもよい。また、本実施例では優先度を数値で表し、値が小さい程優先度が高いものと定めるが、値が大きいほど優先度が高いものと定めてもよい。また、優先度の表現は数値でなく、順序を表す記述であればよい。

ステップＳ３４１１において、トポロジ取得方式選択サブプログラムは、イベント、トポロジ情報およびトポロジ取得方式の組み合わせの一覧をパラメータとして受信する。

ステップＳ３４１２において、トポロジ取得方式選択サブプログラムは、受信した全てのトポロジ取得方式について、ステップＳ３４１３からＳ３４２０の処理を繰り返す。

ステップＳ３４１３において、トポロジ取得方式選択サブプログラムは、受信したイベント、トポロジ情報およびトポロジ取得方式の組み合わせの一覧から、当該トポロジ取得方式に対応するイベントを取得し、そのイベントの管理オブジェクト種別を取得する。

ステップＳ３４１４において、トポロジ取得方式選択サブプログラムは、当該トポロジ取得方式に登録された関連ＩＤに対応する関連テーブル１３３のエントリを取得し、ステップＳ３４１３で取得した管理オブジェクト種別に該当するテーブル名を起点として、取得した各エントリのテーブル名Ｘ３３０２およびテーブル名Ｙ３３０４に格納されたテーブル名を辿る。さらに、テーブル名に対応する多重度３３０６を取得する。

例えば、ステップＳ３４１３において、管理オブジェクト種別「ディスクドライブ」を取得し、当該トポロジ取得方式が図１６Ａに示すトポロジ取得方式１６００である場合、関連ＩＤが「ＡＳ３」である関連テーブルのエントリのテーブル名Ｘ３３０２「ディスクドライブ」を取得する。また、「ディスクドライブ」に対する「論理ボリューム」の多重度「１対１」を多重度３３０６から取得する。さらに、関連テーブルの当該エントリのテーブル名Ｙ３３０４が「論理ボリューム」であるため、トポロジ取得方式１６００に含まれ、かつ、テーブル名Ｘ３３０２に「論理ボリューム」が格納されている関連ＩＤが「ＡＳ１２」のエントリを関連テーブルから取得する。この時、論理ボリュームに対する多重度「多対１」を多重度３３０６から取得する。したがって、多重度を「１対１」「多対１」の順で取得する。

ステップＳ３４１５において、トポロジ取得方式選択サブプログラムは、ステップＳ３４１４で取得した多重度に「多対多」が含まれているかを判定する。条件を満たす場合、処理はステップＳ３４１７に進む。一方、条件を満たさない場合、処理はステップＳ３４１６に進む。

ステップＳ３４１６において、トポロジ取得方式選択サブプログラムは、ステップＳ３４１４で取得した多重度が「多対１」「１対多」の順に現れたかを判定する。条件を満たす場合、処理はステップＳ３４１７に進む。一方、条件を満たさない場合、処理はステップＳ３４１８に進む。なお、「多対１」と「１対多」との間に「１対１」または「多対１」があってもよい。

ステップＳ３４１７において、トポロジ取得方式選択サブプログラムは、当該トポロジ取得方式の優先度を「３」に設定する。

ステップＳ３４１８において、トポロジ取得方式選択サブプログラムは、ステップＳ３４１４で取得した多重度に「１対多」が含まれるかを判定する。条件を満たす場合、処理はステップＳ３４１９に進む。一方、条件を満たさない場合、処理はステップＳ３４２０に進む。

ステップＳ３４１９において、トポロジ取得方式選択サブプログラムは、当該トポロジ取得方式の優先度を「２」に設定する。

ステップＳ３４２０において、トポロジ取得方式選択サブプログラムは、当該トポロジ取得方式の優先度を「１」に設定する。

ステップＳ３４２１において、トポロジ取得方式選択サブプログラムは、表示モジュール１２５を起動し、各トポロジ取得方式に対応するトポロジ情報、イベントおよび優先度の組み合わせを出力デバイス１１７に表示する。

ステップＳ３４２２において、トポロジ取得方式選択サブプログラムは、ステップＳ３４２１の表示情報の中からルール作成者が各イベントに対応して一つ選択したトポロジのトポロジ情報を受信する。

ステップＳ３４２３において、トポロジ取得方式選択サブプログラムは、ステップＳ３４２２で受信したトポロジ情報に対応するトポロジ取得方式一覧を、トポロジ取得方式選択処理の呼び出し元プログラムに渡す。

以上に説明した方法１は、他の方法のように適用対象が制限されないので、どのような場合でも使いやすい方法である。

＜方法２：適用トポロジの集合を評価基準とした優先度決定方法＞
トポロジ取得方式の優先度を決定する第２の方法は、適用トポロジの集合を評価基準とする方法である。具体的には、１組の影響管理オブジェクトから原因管理オブジェクトまでのトポロジを取得する方式として、複数のトポロジ取得方式が候補となった場合、各トポロジ取得方式で取得できる全てのトポロジ情報を取得して、各トポロジ取得方式の集合とする。そして、各々のトポロジ情報から抽出できる原因管理オブジェクトと影響管理オブジェクトの組み合わせを比較する要素とし、各集合の包含関係を求め、下位の集合を取得した方式ほど優先度を高くする。

すなわち、あるトポロジ取得方式が取得できるトポロジ情報の集合が、別の方式によって取得できるトポロジ情報の集合に包含されている場合、前者のトポロジ取得方式によって取得できる原因管理オブジェクトと影響管理オブジェクトの組み合わせは、より範囲が限定されている。したがって、メタルールの適用範囲が限定されており、前者の方式で取得するトポロジ情報の方が、障害が伝播するトポロジである可能性が高く、不要な展開ルールが生成される可能性が低くなる。

したがって、本実施例では、１組の影響管理オブジェクトから原因管理オブジェクトまでのトポロジを取得する方式として、複数のトポロジ取得方式が候補となった場合、各トポロジ取得方式によって取得できる全てのトポロジの情報を取得し、それらの集合の包含関係を算出して、最下位の集合を取得した方式から順に優先度を高くつける。

なお、本実施例では取得できるトポロジ情報の集合が下位のものほど優先度を高くしたが、別の基準に基づいて各々のトポロジ取得方式が取得できるトポロジ情報を評価し、トポロジ取得方式の優先度を決定してもよい。

図３５は、第３の実施例の第２の方法におけるトポロジ取得方式選択処理の例のフローチャートである。

ステップＳ３５１１において、トポロジ取得方式選択サブプログラムは、イベント、トポロジ情報およびトポロジ取得方式の組み合わせの一覧をパラメータとして受信する。

ステップＳ３５１２において、トポロジ取得方式選択サブプログラムは、受信した全てのイベントについて、ステップＳ３５１３からＳ３５１６の処理を繰り返す。

ステップＳ３５１３において、トポロジ取得方式選択サブプログラムは、当該イベントに対応するトポロジ取得方式を、受信した組み合わせの一覧から取得する。

ステップＳ３５１４において、トポロジ取得方式選択サブプログラムは、各トポロジ取得方式に対応して、取得できる全てのトポロジ情報を構成管理ＤＢ１３２から取得し、トポロジ取得方式ごとにトポロジ情報の集合を構成して、メモリ１１２に保存する。

ステップＳ３５１５において、トポロジ取得方式選択サブプログラムは、ステップＳ３５１４で取得したトポロジ情報の各集合の包含関係を算出する。この時、包含関係を算出するために比較する要素は、各々のトポロジ情報から抽出できる原因管理オブジェクトと影響管理オブジェクトとの組み合わせとする。

ステップＳ３５１６において、トポロジ取得方式選択サブプログラムは、最下位のトポロジ情報集合を取得したトポロジ取得方式の優先度を「１」とし、下位のトポロジ情報集合を取得した方式から順に優先度を設定する。

ステップＳ３５１７において、トポロジ取得方式選択サブプログラムは、表示モジュール１２５を起動し、各トポロジ取得方式に対応するトポロジ情報、イベントおよび優先度の組み合わせを出力デバイス１１７に表示する。

ステップＳ３５１８において、トポロジ取得方式選択サブプログラムは、ステップＳ３５１７の表示情報の中から、ルール作成者が各イベントに対して選択した一つのトポロジのトポロジ情報を受信する。

ステップＳ３５１９において、トポロジ取得方式選択サブプログラムは、ステップＳ３５１８で受信したトポロジ情報に対応するトポロジ取得方式の一覧を、トポロジ取得方式選択処理の呼び出し元プログラムに渡す。

なお、本実施例では、各トポロジ取得方式が取得できる全てのトポロジ情報を構成管理ＤＢ１３２から取得したが、処理を高速化するために、起点となるいくつかの管理オブジェクトを限定してトポロジ情報を取得することによって、取得するトポロジ情報の範囲を限定してもよい。このため、トポロジ情報の一部を部分的に検証することになり、処理を高速化することができる。

＜方法３：レイヤを評価基準とした優先度決定方法＞
トポロジ取得方式の優先度を決定する第３の方法は、レイヤを評価基準とする方法である。具体的には、関連テーブル１３３のエントリが示す関連が、いずれのレイヤの接続関係を表しているかを予め定義しておき、下位レイヤの関連を含むトポロジの情報を取得するトポロジ取得方式の優先度を下げる。

例えば、ネットワーク接続関係を示すトポロジの場合、「二つのサーバが物理的にスイッチを介して接続されている」という下位レイヤの接続関係を表すトポロジより、「二つのサーバ上のアプリケーションがＴＣＰ接続をして通信している」という上位レイヤの接続関係を表すトポロジの方が、一方のサーバの障害が他方のサーバに伝播する可能性が高い。

したがって、本実施例の第３の方法では、関連テーブルの各エントリが示す関連のレイヤの情報を登録し、レイヤの上位・下位の関係を定義する。そして、１組の影響管理オブジェクトから原因管理オブジェクトまでのトポロジを取得する方式として、複数のトポロジ取得方式が候補となった場合、各トポロジ取得方式が取得できるトポロジの関連に下位レイヤの関連が含まれている場合、トポロジ取得方式の優先度を下げる。

なお、本実施例では、下位レイヤの関連を含むトポロジ情報を取得するトポロジ取得方式の優先度を高くしたが、別の基準で関連を評価し、トポロジ取得方式を決定してもよい。

図３６Ａおよび図３６Ｂは、第３の実施例の第３の方法の関連テーブル１３３のデータ構造の例を説明する図である。本実施例の関連テーブル１３３は、図３６Ａに示すエントリの下に、図３６Ｂに示すエントリが続く構造である。

方法３の関連テーブル１３３は六つのフィールドを持つ。関連ＩＤ３６０１、テーブル名Ｘ３６０２、フィールド名Ｘ３６０３、テーブル名Ｙ３６０４、フィールド名Ｙ３６０５は、それぞれ、第１の実施例の関連テーブル（図１５Ａ、図１５Ｂ）の関連ＩＤ１５０１、テーブル名Ｘ１５０２、フィールド名Ｘ１５０３、テーブル名Ｙ１５０４、フィールド名Ｙ１５０５と同じである。

レイヤ３６０６は、関連テーブル１３３の各エントリが示す構成管理ＤＢ１３２のテーブル間の関連のレイヤの情報である。すなわち、関連テーブル１３３の各エントリが示す関連がいずれのレイヤの接続関係であるかの情報である。なお、特にレイヤが設定されない関連があってもよい。

本実施例では、一例として、ストレージがサーバに論理ボリュームを提供するネットワークのレイヤを「レイヤＡ」「レイヤＢ」「レイヤＣ」の三つに分類した。「レイヤＡ」は物理的な接続関係を示す関連に、「レイヤＢ」はＳＣＳＩプロトコルによる通信関係を示す関連に、「レイヤＣ」は論理ボリュームをマウントする関係を示す関連に定義される。

例えば、エントリ３６１３は、サーバのディスクドライブとストレージの論理ボリュームの関連は「レイヤＣ」の接続関係であることを示す。エントリ３６１２のように一つの装置内で閉じる関連等については、ネットワーク接続関係を表していないため、レイヤ３６０６に値を格納しなくてよい。

本実施例では、各レイヤは「レイヤＣ」「レイヤＢ」「レイヤＡ」の順で優先度が高く設定される。

なお、関連テーブルのエントリが示す各々の関連に定義されるレイヤは、当該技術分野で公知のＯＳＩ参照モデルによって分類されたレイヤでもよい。

トポロジ取得方式選択処理では、受信した各トポロジ取得方式の方式ＩＤ１６０２に格納された全ての関連ＩＤ１５０１に対応する関連テーブル１３３のエントリを取得し、取得したエントリのレイヤ３６０６に「レイヤＡ」が格納されているトポロジ取得方式は優先度を「３」、「レイヤＢ」が格納されているトポロジ取得方式は優先度を「２」、それ以外は優先度を「１」と設定する。そして、図３４Ａおよび図３４Ｂに示すトポロジ取得方式選択処理と同様に、ルール作成者に対して、各トポロジ取得方式に対応するトポロジ情報とイベントと優先度を表示することができる。

本実施例においては、関連についてレイヤを設定したが、管理オブジェクト種別についてレイヤを設定し、各トポロジ取得方式が取得できる管理オブジェクトの種別に基づいて優先度を設定してもよい。

以上に説明した方法３は、管理オブジェクトの関連についてレイヤの情報が設定されている場合に好適な方法である。

＜方法４：既存のトポロジ取得方式を評価基準とした優先度決定方法＞
トポロジ取得方式の優先度を決定する第４の方法は、既存のトポロジ取得方式を評価基準とする方法である。具体的には、１組の影響管理オブジェクトから原因管理オブジェクトまでのトポロジを取得する方式として、複数のトポロジ取得方式が候補となった場合、既にトポロジ取得方式リポジトリ１３４に格納されている方式と完全に一致する、または部分的に一致するトポロジ取得方式を優先する。

既に利用されているトポロジ取得方式は、他のメタルールにおいて障害が伝播するトポロジを取得する手段として定義されているため、新しく生成するメタルールが示す障害原因が伝播するトポロジとなる可能性が高いからである。

なお、本実施例では既存のトポロジ取得方式と一致する方式の優先度を高くしたが、別の基準によって既存のトポロジ取得方式との関係を評価し、トポロジ取得方式の優先度を決定してもよい。

二つのトポロジ取得方式が完全に一致する、または部分的に一致するとは、トポロジ取得方式１６００の方式１６０２に格納される関連ＩＤが全て等しい、または一部が等しいことでよい。また、一部が等しい場合に関しては、等しい関連ＩＤの比率などで優先度を決定してもよい。

以上に説明した方法４は、他の方法より簡易な方法として有用である。

＜方法５：過去のイベントとの関係を評価基準とした優先度決定方法＞
トポロジ取得方式の優先度を決定する第５の方法は過去のイベントとの関係を評価基準とする方法である。具体的には、生成しようとしているメタルールに各トポロジ取得方式を対応付けた場合、イベントテーブル１３１および構成管理ＤＢ１３２に基づいて、当該メタルールを用いて過去のイベントを解析するシミュレーションを行い、メタルールと各トポロジ取得方式から展開ルールを生成した場合に、過去のイベントに対して過不足なく展開ルールを生成できている方式を優先する。

例えば、以下の処理によって、優先度を決定することができる。

当該メタルールのＩＦ部に記述された条件要素が指定するイベントが所定の期間内に発生したイベント群をイベントテーブルから取得する。そして、当該イベント群が発生した各々の管理オブジェクトを起点として、トポロジ取得方式を用いてトポロジ情報を取得し、当該メタルールから展開ルール群を生成する。

当該イベント群の中に、生成した全ての展開ルールのＩＦ部の条件要素が示すイベントに該当しないものがある場合、展開ルールが不足していると判定する。また、展開ルールの条件要素に当該イベント群に含まれないものがある場合、展開ルールが過剰であると判定する。各トポロジ取得方式に以上の処理を実行し、展開ルールの過不足が少ないものから順に優先度をつける。

以上の五つの方法によって、１組の影響管理オブジェクトから原因管理オブジェクトまでのトポロジ情報を取得する方式として、複数のトポロジ取得方式が候補となった場合、決定した各トポロジ取得方式の優先度を、トポロジ取得方式をメタルールに対応付けるかを判定するための情報として、ルール作成者に提示することができる。

例えば、第１の実施例のメタルール生成プログラム１２１のステップＳ１８１２の処理で原因イベントとして「ＳｔＡ ＲＧ１ ＷｒｉｔｅＨｉｔＰｅｒｆＥｒｒｏｒ」を受信し、ステップＳ１８１６で影響イベントとして「ＳｖＡ ＤＲＩＶＥ１ ＡｖｅｒａｇｅＳｅｃＰｅｒＸｆｅｒＥｒｒｏｒ」を受信した場合、ステップＳ１８１７で、コンポーネント「ＲＧ１」と「ＤＲＩＶＥ１」と同じトポロジを取得するトポロジ取得方式として、以下の四つを取得できる。
（ａ）方式１６０２が「ＡＳ３，ＡＳ１２」のトポロジ取得方式
（ｂ）方式１６０２が「ＡＳ２，ＡＳ１７，ＡＳ１０，ＡＳ１２」のトポロジ取得方式
（ｃ）方式１６０２が「ＡＳ２，ＡＳ６，ＡＳ１０，ＡＳ１２」のトポロジ取得方式
（ｄ）方式１６０２が「ＡＳ２，ＡＳ４，ＡＳ８，ＡＳ８，ＡＳ７，ＡＳ１０，ＡＳ１２」のトポロジ取得方式

ただし、図２２Ｂに示す関連探索処理のステップＳ２２１９が利用する関連探索条件は、以下とする。
（ｘ）同じ管理オブジェクトを辿る場合
（ｙ）ストレージまたはサーバを辿った後、同じ装置内の別のコンポーネントを辿る場合
（ｚ）ストレージまたはサーバのコンポーネントから別のストレージまたはサーバのコンポーネントを辿った後に、さらに別の装置のコンポーネントを辿る場合

取得した四つのトポロジ取得方式を、第１の方法によってトポロジ取得方式選択処理で優先度を設定する場合、ステップＳ３４１４の処理において（ａ）の方式は、取得した多重度情報が「１対１」「多対１」の順となるため、優先度が「１」に設定される。同様に、（ｂ）の方式は、取得した多重度情報が「多対１」「多対多」「１対多」「多対１」の順となり、「多対多」を含むため、優先度が「３」に設定される。（ｃ）の方式も、取得した多重度情報が「多対１」「多対多」「１対多」「多対１」の順となり、「多対多」を含むため、優先度は「３」が設定される。（ｄ）の方式は、取得した多重度情報が「多対１」「１対１」「多対１」「１対多」「１対１」「１対多」「多対１」の順となり、「多対１」「１対多」の並びを含むため、優先度が「３」に設定される。

図４から図１３に示す構成管理ＤＢ１３２から、トポロジ取得方式（ａ）で取得できるトポロジに基づいて、図３に示すメタルール３００から展開ルールを生成すると、図１７Ａから図１７Ｃに示す三つの展開ルールが生成される。方式（ａ）は「ＲＡＩＤグループを分割した論理ボリュームをマウントしているディスクドライブ」というトポロジを取得しており、「ＲＡＩＤグループの書込処理のヒット率性能エラー」が原因で「ディスクドライブの転送時間性能エラー」を引き起こす関係のＲＡＩＤグループおよびディスクドライブのみを抽出し、展開ルールを生成することができる。

また、例えば、トポロジ取得方式（ｄ）を利用してメタルール３００から展開ルールを生成した場合、ＲＡＩＤグループおよびＦＣスイッチを介してストレージと接続し、外部ボリュームをマウントしているディスクドライブとの全ての組み合わせを取得して、展開ルールを生成する。そのため、図１７Ａから図１７Ｃに示す展開ルールに加えて、図３７Ａから図３７Ｆに示す展開ルールも含めた合計９つの展開ルールが生成される。

図３７Ａから図３７Ｆに示す展開ルールには、実際の管理対象システムにおいて発生し得ないイベントの組み合わせが記述されているため、不要な展開ルールである。また、偶然ＩＦ部に記述されたイベントが同時に発生した場合には、誤った原因候補をイベント受信率１００％の原因候補として提示し、かつ、誤った障害の影響範囲を提示することになる。したがって、メタルールを適用する範囲として適切なトポロジを取得する方式（ａ）の優先度を高くし、ルール作成者に提示することができる。このため、発生しているパターンを利用することによって、精度を向上することができる。

なお、本実施例では優先度を決定するための五つの方法を説明したが、これらの一つのみを利用してもよいし、複数を組み合わせて、各方法の優先度をルール作成者に提示してもよい。また、各方法で算出した優先度の値を加算または乗算し、総合的な優先度として表示してもよい。

また、本実施例では、ルール作成者の１回の入力に対応してトポロジ取得方式の優先度を決定し、一つのメタルールを生成したが、一つのメタルールに対応して同じ管理オブジェクト種別およびイベント種別を持つ別のイベントを数回入力してもよい。そして、それら影響イベントおよび原因イベントの全ての組み合わせが表すトポロジのパターンの共通の特徴を抽出して、メタルールに対応付けるトポロジ取得方式の優先度を決定し、優先度の精度を高めてもよい。

また、本実施例では１組の影響管理オブジェクトから原因管理オブジェクトまでのトポロジを取得する一つの方式を決定したが、候補となった複数のトポロジ取得方式の優先度を記録して、発生した障害イベントを優先度の高いものから順に利用してトポロジ情報を取得し、ある方式でトポロジ情報が取得できなかった場合、優先度が次の方式を利用してもよい。

また、本実施例では、各トポロジ取得方式の優先度をルール作成者に提示したが、優先度が最も高い方式をメタルールに対応付ける方式として自動的に決定してもよい。

また、本実施例では、トポロジ探索処理によって原因管理オブジェクトおよび影響管理オブジェクト間でとり得る全てのトポロジの情報と、当該トポロジに対応するトポロジ取得方式を導出して、優先度を決定する。これに対し、探索中のトポロジ情報およびトポロジ取得方式が、既に導出したトポロジ取得方式より優先度が低くなった時点で探索処理を中断してもよい。

以上に説明したように、本発明の第３の実施例によれば、トポロジ取得方式に優先度を設定して、設定された優先度をルール作成者に提示することによって、ルール作成者がメタルールに対応付けるトポロジ取得方式を選択する作業を支援し、作業コストを削減することができる。

以上、本発明を添付の図面を参照して詳細に説明したが、本発明はこのような具体的構成に限定されるものではなく、添付した請求の範囲の趣旨内における様々な変更および同等の構成を含むものである。

例えば、図２のエントリ２１１は、装置ＩＤがＳｔＡであるストレージ１０４Ａ内のコンポーネントＩＤがＲＧ１であるＲＡＩＤグループ１６４において「ＷｒｉｔｅＨｉｔＰｅｒｆＥｒｒｏｒ」（書込処理のキャッシュヒット率性能エラー）が２０１２年７月７日１５時０分０秒に発生したことを意味する。

例えば、図３のメタルール（メタルールＩＤ＝「ＭｅｔａＲｕｌｅ１」）は、観測事象として「サーバ１０２Ａなど上のディスクドライブ１５１Ａの転送時間性能エラー」と、「ストレージ１０４Ａ等におけるＲＡＩＤグループ１６４の書込処理のキャッシュヒット率性能エラー」とが検知された場合、「ストレージ１０４Ａ等におけるＲＡＩＤグループ１６４の書込処理の「キャッシュヒット率性能エラー」が原因であると結論付けられることを示す。

例えば、図１７Ａに示す展開ルール「ＥｘｐａｎｄｅｄＲｕｌｅ１−１」は、観測事象として「サーバ Ａ（装置ＩＤ＝ＳｖＡ）のＤドライブ（コンポーネントＩＤ＝ＤＲＩＶＥ１）の転送時間性能エラー」と、「ストレージＡ（装置ＩＤ＝ＳｔＡ）における ＲＡＩＤグループ０（コンポーネントＩＤ＝ＲＧ１）の書込処理のキャッシュヒット率性能エラー」とが検知された場合、「ストレージＡにおけるＲＡＩＤグループ０の書込処理のキャッシュヒット率性能エラー」が原因であると結論付けられることを示す。なお、ＩＦ部１７１１に含まれる条件要素として、ある管理オブジェクトが正常であること（障害イベントが発生していないこと）を定義してもよい。

ステップＳ１８１４において、メタルール生成プログラム１２１は、ステップＳ１８１２で受信した原因イベント、およびステップＳ１８１３で取得したイベント群を入力として、トポロジ探索処理を起動し、イベント、トポロジ情報およびトポロジ情報取得方式の組み合わせを取得する。各組み合わせは、ステップＳ１８１３で取得した各イベントが発生した原因イベントが発生した管理オブジェクト間のトポロジ情報、および、そのトポロジを取得するための手段（方式）の組み合わせである。

例えば、影響イベント選択画面２０００は、ステップＳ１８１２またはＳ１８１４で取得したイベントの情報、および、取得したイベントが発生した管理オブジェクトの情報を、アイコン２００１、２００２のように表示する。例えば、アイコン２００１は、イベントが「ストレージＡのＲＡＩＤグループ０の書込処理のキャッシュヒット率性能エラー」であることを示す。また、アイコン２００１は、原因イベントであることを示す表示を有してもよい。

例えば、システム運用管理者が、メタルール生成プログラム１２１の実行するステップＳ１８１２において、原因イベントとしてイベントテーブル１３１のエントリ２１１（ストレージＡのＲＡＩＤグループ０の書込処理のキャッシュヒット率性能エラー）を選択し、ステップＳ１８１６において、影響イベントとしてエントリ２１２（サーバＡのＤドライブの転送時間性能エラー）を選択し、トポロジ取得方式選択処理が実行するステップＳ２４１３において、「ＤＲＩＶＥ１，ＶＯＬ１，ＲＧ１」に該当するトポロジを選択した場合、メタルール生成プログラム１２１は、図３に示すメタルール３００および図１６Ａに示すトポロジ取得方式１６００を生成する。そして、例えば、管理対象システムのサーバＢにおいて、イベントテーブル１３１のエントリ２２２が示すイベントが発生した場合、障害解析プログラム１２３によって、メタルール３００とトポロジ取得方式１６００Ａから図１７Ｃに示す展開ルール１７００が生成され、障害解析結果として「ストレージＡのＲＡＩＤグループ１の書込処理のキャッシュヒット率性能エラーが原因である」という解析結果、および、影響範囲は「ストレージＡのＲＡＩＤグループ１の書込処理のキャッシュヒット率性能エラー」、「サーバＢのＤドライブの転送時間性能エラー」であるという解析結果が運用管理者に提示される。

例えば、トポロジ探索処理が、原因情報として、装置種別「ストレージ」、コンポーネント種別「ＲＡＩＤグループ」、イベント種別「書込処理のキャッシュヒット率性能エラー」を入力し、さらに、影響イベント情報のテーブル名として「ディスクドライブ」を、関連探索処理に入力し、関連探索処理がそれらを受信した（ステップＳ３１１１）。

図４から図１３に示す構成管理ＤＢ１３２から、トポロジ取得方式（ａ）で取得できるトポロジに基づいて、図３に示すメタルール３００から展開ルールを生成すると、図１７Ａから図１７Ｃに示す三つの展開ルールが生成される。方式（ａ）は「ＲＡＩＤグループを分割した論理ボリュームをマウントしているディスクドライブ」というトポロジを取得しており、「ＲＡＩＤグループの書込処理のキャッシュヒット率性能エラー」が原因で「ディスクドライブの転送時間性能エラー」を引き起こす関係のＲＡＩＤグループおよびディスクドライブのみを抽出し、展開ルールを生成することができる。

Claims (14)

1. 複数のノード装置を監視する管理計算機であって、
   前記管理計算機は、プロセッサおよび記憶資源を有し、
   前記記憶資源は、前記ノード装置に含まれるコンポーネントの種別を含むコンポーネントの構成情報を格納し、
   前記ノード装置および前記コンポーネントは、管理オブジェクトとして管理されており、
   前記プロセッサは、
   原因と推定される第１の障害に関する第１の管理オブジェクトを特定するための情報と前記第１の障害の種別との組、および、前記第１の障害によって発生したと推定される第２の障害に関する第２の管理オブジェクトを特定するための情報と前記第２の障害の種別との組の入力を受信し、
   前記第１の管理オブジェクトの種別の情報および前記第２の管理オブジェクトの種別の情報を取得し、
   前記第２の管理オブジェクトの種別から前記第１の管理オブジェクトの種別までの関連を辿り、
   前記管理オブジェクトの種別と前記障害の種別との組によって定まる少なくとも一つの条件要素からなる条件部、および、原因と推定される管理オブジェクトの種別と障害の種別との組からなる結論部を含むメタルールを生成し、
   前記第２の管理オブジェクトの種別から前記第１の管理オブジェクトの種別までの辿り方に基づいて、前記第２の管理オブジェクトの種別から前記第１の管理オブジェクトの種別までの関連によって構成されるトポロジの情報を取得する方式を生成し、
   前記生成された方式に基づいてトポロジの情報を取得し、
   前記生成されたメタルールおよび前記取得したトポロジの情報から展開ルールを生成し、
   新たな障害を検知した場合、前記生成した展開ルールに基づいて、前記検知された障害を解析することを特徴とする管理計算機。
2. 請求項１に記載の管理計算機であって、
   前記記憶資源は、前記管理オブジェクトの種別間の関連情報を取得する方法の情報を記憶し、
   前記プロセッサは、
   前記管理オブジェクトを特定するための情報と前記障害の種別との組の入力を受信する際に、管理オブジェクト識別情報を、前記管理オブジェクトを特定するための情報として受信し、
   前記第２の管理オブジェクトの種別から前記第１の管理オブジェクトの種別までの関連を辿る際に、前記第１の管理オブジェクトの種別と前記第２の管理オブジェクトの種別との間の関連情報を取得する方法の情報に基づいて、前記関連を辿ることを特徴とする管理計算機。
3. 請求項１に記載の管理計算機であって、
   前記プロセッサは、前記管理オブジェクトを特定するための情報と障害の種別との組の入力を受信する際に、前記管理オブジェクトの種別を、前記管理オブジェクトを特定するための情報として受信することを特徴とする管理計算機。
4. 請求項１に記載の管理計算機であって、
   前記記憶資源は、過去に発生した障害の履歴の情報を格納し、
   前記プロセッサは、前記管理オブジェクトを特定するための情報と障害の種別との組の入力を求める際に、前記管理オブジェクトを含むトポロジ情報および指定された期間に発生した前記障害を表示するためのデータを生成することを特徴とする管理計算機。
5. 請求項４に記載の管理計算機であって、
   前記プロセッサは、
   前記記憶資源に格納された前記障害の履歴の情報に含まれる、前記過去に発生した障害を表示するためのデータを生成し、
   前記表示された障害から選択された前記第１の障害または前記第２の障害の入力を受信し、
   前記入力された第１の障害または第２の障害が発生した時刻から前後の所定期間に発生した障害を、前記指定された期間に発生した障害として表示するためのデータを生成することを特徴とする管理計算機。
6. 請求項１に記載の管理計算機であって、
   前記プロセッサは、
   前記生成されたトポロジの情報を取得する方式によって構成情報から取得できる全てのトポロジの情報を取得し、
   前記生成されたメタルールから、前記情報を取得した全てのトポロジに対応する展開ルールを生成し、
   前記生成された展開ルールおよび展開ルールの数の少なくとも一方を表示するためのデータを生成することを特徴とした管理計算機。
7. 請求項１に記載の管理計算機であって、
   前記記憶資源は、過去に発生した障害の履歴の情報、および、前記管理オブジェクトの構成情報の履歴を記憶し、
   前記プロセッサは、
   前記障害の履歴の情報から、前記第１の管理オブジェクトにおいて第１の障害が発生したことを示す第３の障害と、前記第３の障害の発生日時から前後の所定期間に、前記第２の管理オブジェクトにおいて第２の障害が発生したことを示す第４の障害とを取得し、
   前記生成されたトポロジの情報を取得する方式に基づいて、前記第３の障害または前記第４の障害が発生した時刻の構成情報の履歴からトポロジ情報を取得し、
   前記第４の障害が発生した管理オブジェクトの管理オブジェクト識別情報、または、前記第３の障害が発生した管理オブジェクトの管理オブジェクト識別情報が、前記取得したトポロジ情報に含まれているかを判定し、
   前記判定の結果に基づいて、前記第３の障害および前記第４の障害の情報を表示するためのデータを生成することを特徴とする管理計算機。
8. 請求項１に記載の管理計算機であって、
   前記プロセッサは、
   前記トポロジの情報を取得する方式が複数生成された場合、障害解析の特徴に基づいた所定の基準にしたがって、前記生成された各方式を評価し、
   前記評価の結果に基づいて、前記各方式の優先度を決定することを特徴とする管理計算機。
9. 請求項８に記載の管理計算機であって、
   前記プロセッサは、前記トポロジの情報を取得する方式の各々によって取得されるトポロジの情報に基づいて、前記各方式の優先度を決定することを特徴とする管理計算機。
10. 請求項８に記載の管理計算機であって、
    前記記憶資源は、前記管理オブジェクトの種別間の関連の多重度を記憶し、
    前記プロセッサは、前記トポロジの情報を取得する方式の各々が情報を取得できるトポロジに含まれる管理オブジェクトの種別間の関連の多重度に基づいて、前記各方式の優先度を決定することを特徴とする管理計算機。
11. 請求項８に記載の管理計算機であって、
    前記記憶資源は、前記管理オブジェクトの種別間の関連のレイヤの情報を記憶し、
    前記プロセッサは、トポロジの情報を取得する方式の各々が情報を取得できるトポロジに含まれる管理オブジェクトの種別間の関連のレイヤに基づいて、前記各方式の優先度を決定することを特徴とする管理計算機。
12. 請求項８に記載の管理計算機であって、
    前記プロセッサは、既に利用されているトポロジの情報を取得する方式との一致度に基づいて、前記各方式の優先度を決定することを特徴とする管理計算機。
13. 請求項８に記載の管理計算機であって、
    前記記憶資源は、過去に発生した障害の履歴の情報、および、前記コンポーネントの構成情報の履歴を記憶し、
    前記プロセッサは、
    前記障害の履歴の情報から、前記第１の管理オブジェクトにおいて第１の障害が発生したことを示す第３の障害と、前記第３の障害の発生日時から前後の所定期間に、前記第２の管理オブジェクトにおいて第２の障害が発生したことを示す第４の障害とを取得し、
    前記生成されたトポロジの情報を取得する方式に基づいて、前記第３の障害または前記第４の障害が発生した時刻の構成情報の履歴からトポロジ情報を取得し、
    前記第４の障害が発生した管理オブジェクトの管理オブジェクト識別情報、または、前記第３の障害が発生した管理オブジェクトの管理オブジェクト識別情報と、前記取得したトポロジ情報に含まれる管理オブジェクト識別情報との関係に基づいて、前記各方式の優先度を決定することを特徴とする管理計算機。
14. 複数のノード装置を監視する管理計算機において、障害を検知するためのルールを生成する方法であって、
    前記管理計算機は、プロセッサおよび記憶資源を有し、
    前記記憶資源は、前記ノード装置に含まれるコンポーネントの種別を含むコンポーネントの構成情報を格納し、
    前記ノード装置および前記コンポーネントは、管理オブジェクトとして管理されており、
    前記方法は、
    前記プロセッサが、原因と推定される第１の障害に関する第１の管理オブジェクトを特定するための情報と前記第１の障害の種別との組、および、前記第１の障害によって発生したと推定される第２の障害に関する第２の管理オブジェクトを特定するための情報と前記第２の障害の種別との組の入力を受信し、
    前記プロセッサが、前記第１の管理オブジェクトの種別の情報および前記第２の管理オブジェクトの種別の情報を取得し、
    前記プロセッサが、前記第２の管理オブジェクトの種別から前記第１の管理オブジェクトの種別までの関連を辿り、
    前記プロセッサが、前記管理オブジェクトの種別と前記障害の種別との組によって定まる少なくとも一つの条件要素からなる条件部、および、原因と推定される管理オブジェクトの種別と障害の種別との組からなる結論部を含むメタルールを生成し、
    前記プロセッサが、前記第２の管理オブジェクトの種別から前記第１の管理オブジェクトの種別までの辿り方に基づいて、前記第２の管理オブジェクトの種別から前記第１の管理オブジェクトの種別までの関連によって構成されるトポロジの情報を取得する方式を生成し、
    前記プロセッサが、前記生成された方式に基づいてトポロジの情報を取得し、
    前記プロセッサが、前記生成されたメタルールおよび前記取得したトポロジの情報から展開ルールを生成することを特徴とするルール生成方法。

Images