WO2015079564A1

WO2015079564A1 - イベントの根本原因の解析を支援する管理システム及び方法

Info

Publication number: WO2015079564A1
Application number: PCT/JP2013/082207
Authority: WO
Inventors: 香緒里仲野; 名倉　正剛; 崇之永井
Original assignee: 株式会社日立製作所
Priority date: 2013-11-29
Filing date: 2013-11-29
Publication date: 2015-06-04
Also published as: DE112013006475T5; JPWO2015079564A1; CN104903866B; GB201513880D0; GB2536317A; US20150378805A1; CN104903866A; JP6208770B2

Abstract

　複数の汎用診断手順が用意される。各汎用診断手順は、複数のルールのいずれかに関連付けられており１又は複数のコンポーネント種別を用いて定義された汎用の診断手順である。各ルールは、１以上の条件イベントと結論イベントとの関連付けを示す。管理システムが、１以上の発生イベントに関連する１以上の条件イベントが関連付けられている１以上の対象ルールを基に、１以上の原因候補を特定し、１以上の原因候補のうちの選択された原因候補の基になる対象ルールに関連付けられている汎用診断手順を特定する。管理システムは、特定された汎用診断手順と、複数の管理対象コンポーネントの構成に関する情報である構成管理情報とに基づいて、１以上の管理対象コンポーネントに対して実行する診断手順であり選択された原因候補のより具体的な原因を特定する又は選択された原因候補の確からしさを更新するための展開診断手順を生成する。

Description

イベントの根本原因の解析を支援する管理システム及び方法

　本発明は、概して、管理対象コンポーネントにおいて発生したイベントの根本原因の解析の支援に関する。

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

ＷＯ２０１３／０４６２８７

　特許文献１に開示された技術を含め、コンポーネントで発生したイベントのパターンに基づいて障害原因を解析する技術は、ＩＴシステムで発生した複数の障害の発端となる障害を絞り込むことができる。しかし、発生したイベントのパターンだけでは、障害復旧方法を決定するのに十分詳細な原因特定までできない場合がある。すなわち、複数の障害の発端となった障害が発生した原因を特定することができない場合がある。

　記憶デバイスが、構成管理情報と、複数のルールと、複数の汎用診断手順とを記憶する。構成管理情報は、前記複数の管理対象コンポーネントの構成に関する情報である。複数のルールの各々は、１以上のイベントに対応した１以上の条件イベントと前記１以上の条件イベントが発生した場合に原因となる結論イベントとの関連付けを示すルールである。複数の汎用診断手順の各々は、複数のルールのいずれかに関連付けられており１又は複数のコンポーネント種別を用いて定義され管理対象コンポーネントに依存しない汎用の診断手順である。プロセッサが、複数のルールのうちの、１以上の発生イベント（発生したイベント）に関連する１以上の条件イベントが関連付けられている１以上のルールである１以上の対象ルールを基に、１以上の原因候補を特定する。プロセッサが、複数の汎用診断手順のうちの、１以上の原因候補のうちの選択された原因候補の基になる対象ルールに関連付けられている汎用診断手順を特定する。プロセッサが、特定された汎用診断手順と構成管理情報とに基づいて、１以上の管理対象コンポーネントに対して実行する診断手順であり選択された原因候補のより具体的な原因を特定する又は選択された原因候補の確からしさを更新するための展開診断手順を生成する。

　より詳細に又はより正確に１以上の発生イベントの原因を特定することが期待できる。

実施例１の概略を示す。実施例１のＩＴシステムおよび管理計算機の構成例を示す。構成管理ＤＢ中の装置テーブルの構成例を示す。構成管理ＤＢ中のｉＳＣＳＩディスクテーブルの構成例を示す。構成管理ＤＢ中のネットワークＩ／Ｆテーブルの構成例を示す。構成管理ＤＢ中のスイッチポートテーブルの構成例を示す。構成管理ＤＢ中のｉＳＣＳＩターゲットテーブルの構成例を示す。構成管理ＤＢ中のストレージポートテーブルの構成例を示す。性能テーブルの構成例を示す。イベントキューテーブルの構成例を示す。メタルールの構成例を示す。展開ルールの構成例を示す。メタ診断手順の構成例を示す。トポロジ条件の構成例を示す。メタ収集手段の構成例を示す。展開診断手順の構成例を示す。展開収集手段の構成例を示す。障害解析プログラムにより実行される障害原因解析処理の例のフローチャートを示す。イベント分析結果画面の一例を示す。診断手順展開プログラムにより実行される処理の例のフローチャートを示す。診断手順展開プログラムにより実行される処理の例のフローチャートを示す。表示プログラムにより実行される処理の例のフローチャートを示す。診断結果画面の一例を示す。実施例２におけるメタルールの構成例を示す。実施例２における展開ルールの構成例を示す。実施例２における展開診断手順の構成例を示す。実施例２において障害解析プログラムにより実行される障害原因解析処理の例のフローチャートを示す。

発明を実行するための形態

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

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

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

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

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

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

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

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

　さらに、要素の説明する際に、「識別子」、「名」、「名前」および「ＩＤ」のうちの少なくとも１つの表現が用いられるが、これらについてはお互いに置換が可能であり、また、これらのうちの少なくとも１つに代えてまたは加えて、別種の識別情報が用いられてもよい。

　以下の説明では「プログラム」を主語として処理の説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリおよび通信ポート（通信制御デバイス）を用いながら行うため、その処理の説明ではプロセッサが主語とされてもよい。また、プログラムを主語として開示された処理は管理計算機等の計算機が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。また、各種プログラムは、プログラム配布サーバや、計算機が読み取り可能な記憶メディアによって計算機にインストールされてもよい。

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

　以下、ＩＴシステム（情報処理システム）を管理し、表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理計算機が表示用情報を表示する場合は管理計算機が管理システムでよい。管理計算機と表示用計算機の組み合わせが管理システムでもよい。また、管理処理の高速化や高信頼化のために複数の計算機で管理計算機と同等の処理を実現してもよく、この場合はそれら複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含め）が管理システムでよい。管理計算機による「表示用情報を表示する」とは、管理計算機が有する表示デバイスに表示用情報を表示することであってもよいし、管理計算機（例えばサーバ）が遠隔の表示用計算機（例えばクライアント）に表示用情報を送信することであってもよい。

　また、以下の説明では、同種の要素を区別して説明する場合は、その要素の参照符号を使用し、同種の要素を区別しないで説明する場合は、その要素の参照符号のうちの共通の親符号を使用することがある。例えば、サーバを特に区別しないで説明する場合には、サーバ２０２と記載し、個々のサーバを区別して説明する場合には、サーバ２０２ａ、２０２ｂのように記載することがある。

　＜実施例の概要＞

　以下でより詳しく述べるように、実施例１によれば、ＩＴシステムで発生した障害の原因イベントを特定するための診断手順を導出、および、それらの診断手順に基づいて障害の原因イベントを特定する診断を実行する装置、方法、およびコンピュータプログラムが提供される。

　実施例１によれば、管理計算機２０１は、複数の管理対象装置を管理するコンピュータである。管理対象装置の種別としては例えば、コンピュータ（例えばサーバ）、ネットワーク装置（例えば、ＩＰ（Internet　Protocol）スイッチ、ルータ、またはＦＣ（Fibre　Channel）スイッチ）、および、ストレージ装置（例えばＮＡＳ（Network　Attached　Storage））のうちの少なくとも１つがある。１つの管理対象装置が含むデバイス等の論理的または物理的な要素としては、例えば、ポート、プロセッサ、記憶資源、物理記憶デバイス、プログラム、仮想マシン、論理ボリューム（論理記憶デバイス）、およびＲＡＩＤ（Redundant　Arrays　of　Inexpensive　(Independent)　Disks）グループのうちの少なくとも１つがある。以下、管理対象装置および管理対象装置が含む要素の各々を「管理対象コンポーネント」と総称する場合がある。また、管理対象装置を、ノード装置と呼ぶこともできる。

　図１は、実施例１の概略を示す。

　イベント分析プログラム結果表示画面１１１は、イベント分析結果１０１を表示する。イベント分析結果１０１は、複数の装置で発生した障害の伝播元となる障害を原因障害候補として表す。イベント分析結果１０１は、後述のイベント分析プログラムによって導出された結果である。イベント分析結果１０１は、例えば特許文献１に開示の方法で導出されてよい。

　管理計算機２０１は、ＩＴシステムの障害の原因イベントを特定する診断手順を格納したメタ診断手順リポジトリ２３４と、管理対象コンポーネントの構成情報を格納した構成管理ＤＢ（データベース）２３２を有する。メタ診断手順リポジトリ２３４に格納されたメタ診断手順は、ＩＴシステム内のある構成パターンに対して実行する診断手順が記述されている。構成管理ＤＢ２３２に格納される構成情報は、各管理対象コンポーネントに関する情報と、各管理対象コンポーネント間の接続関係を表す接続関係情報と、各管理対象コンポーネント間の依存関係を表す依存関係情報とを含む。

　イベント分析結果１０１が表す１または複数の原因障害候補から１つの原因障害候補がユーザまたは管理計算機２０１により選択された場合、管理計算機２０１は、さらに詳細な障害原因解析を行うべく診断手順展開プログラム２２３を実行する。診断手順展開プログラム２２３は、イベント分析結果１０１に関連するメタ診断手順をメタ診断手順リポジトリ２３４から取得する。次に、診断手順展開プログラム２２３は、取得したメタ診断手順に定義された構成パターンと、選択された原因障害候補とに基づいて、診断を実行すべき管理対象コンポーネントに関わる構成情報を構成管理ＤＢ２３２から取得する。そして、診断手順展開プログラム２２３は、取得したメタ診断手順と取得した構成情報から展開診断手順１２４を生成する。展開診断手順１２４は、診断に必要な情報を収集するための情報収集ステップ１３１と、収集した情報に基づいて判定を行う判定ステップ１３２と、判定の結果によって導き出される障害原因イベントを示す結論１３３とを含む。診断実行プログラム２２４は、生成された展開診断手順１２４において定義された各ステップを実行し、得られた結論をＩＴシステムの障害原因イベントとし、診断結果表示画面１１３に、その障害原因イベントに従う診断結果１４１を表示する。

　本実施例により、ＩＴシステムで複数の障害が発生した際、イベント分析によって複数障害の伝播元となった障害を絞り込んだ後、伝播元障害の発生原因を特定するのに必要な診断手順を自動で展開し、診断を実行することで、障害の発生原因の特定を迅速に行うことができる。

　その結果、特定した原因イベントに基づいて障害復旧対策を迅速に決定することができ、ＩＴシステムのダウンタイムを短くすることができる。その結果、ＩＴシステムの停止によって発生するビジネス機会損失などの経済的損害を削減することができる。特に、設定不良による障害や性能障害など、イベントのみでは原因特定が困難な障害を解析することができる。例えば、ＩＴシステムで性能障害が発生した場合、イベント分析プログラムによってボトルネックとなっているコンポーネント（例えば装置およびその要素）を特定した後、診断手順展開プログラム２２３および診断実行プログラム２２４によって、そのコンポーネントがボトルネックとなった原因を推定することができる。この場合、システム障害のボトルネックを特定するだけでなく、その発生原因を特定することで、障害復旧対策を決定するための根拠となる情報が増える。それにより、１つの障害に対して複数挙がった障害復旧対策の中から、実行する対策を１つに決定することが容易になる。

　以下、実施例１を詳細に説明する。

　＜ＩＴシステムおよび管理計算機２０１の構成＞

　図２は、実施例１のＩＴシステムおよび管理計算機２０１の構成例を示す。

　管理計算機２０１は、ＩＴシステムを管理する計算機である。ＩＴシステムは、一つ以上のサーバ（または、他の計算機）２０２ａ、２０２ｂ、および２０２ｃ、一つ以上のストレージ装置２０４、および、一つ以上のネットワークスイッチ（または、ＩＰスイッチのような他のネットワーク装置）２０３を有する。サーバ２０２ａ、２０２ｂ、２０２ｃ、ネットワークスイッチ２０３、および、ストレージ装置２０４は、ＬＡＮ（ローカルエリアネットワーク）のようなネットワーク２０５（図２の例によればネットワークスイッチ２０３）を介して通信可能に接続される。

　管理計算機２０１は、ＣＰＵ２１１、メモリ２１２、ディスク２１３、入力デバイス２１４、出力デバイス２１７、およびネットワークインタフェースデバイス（ネットワークＩ／Ｆ）２１５を含み、これらのデバイスがシステムバス２１６を介して接続される汎用計算機でよい。ディスク２１３は、例えばＨＤＤ（Hard　Disk　Drive）であるが、それに代えて、ＳＳＤ（Solid　State　Drive）のような他の不揮発性記憶デバイスが採用されてもよい。管理計算機２０１の論理モジュールとして、例えば、障害解析プログラム２２１、イベント分析プログラム２２２、診断手順展開プログラム２２３、診断実行プログラム２２４、表示プログラム２２５、一つ以上の判定プログラム２２６、イベント受信プログラム２２７、構成取得プログラム２２８、および性能取得プログラム２２９がある。判定プログラム２２６は、１つであってもよいし、メタ診断手順の判定毎に設けられてもよい。また、管理計算機２０１が記憶するデータとして、例えばメタルールリポジトリ２３１、構成管理ＤＢ２３２、イベントキューテーブル２３３、メタ診断手順リポジトリ２３４、展開診断手順リポジトリ２３５、メタ収集手段リポジトリ２３６、展開収集手段リポジトリ２３７、および性能テーブル２３８がある。本実施例（及び実施例２）で言う「メタ収集手段」および「展開収集手段」の各々における「手段」という言葉は、「方法」、「定義」又は「コマンド」という言葉に置換されてよい。展開診断手順リポジトリ２３５および展開収集手段リポジトリ２３７は、一度生成された情報を再利用するために保存するリポジトリであり、管理計算機２０１が有していなくてもよい。また、性能テーブル２３８は、性能取得プログラム２２９によって管理対象装置から収集された管理対象コンポーネントの性能情報を保存するデータベースである。性能取得プログラム２２９、および、性能テーブル２３８は、本実施例で説明する「診断手順」の一例を示すために利用するプログラムおよび情報であり、管理計算機２０１が有していなくてもよい。また、性能テーブル２３８は、管理計算機２０１が有するのではなく、各管理対象装置が情報を保持し、管理対象コンポーネントの性能情報を参照する際には、管理計算機２０１がネットワーク２０５を介して各管理対象装置にアクセスし性能情報を取得してもよい。

　障害解析プログラム２２１、イベント分析プログラム２２２、診断手順展開プログラム２２３、診断実行プログラム２２４、表示プログラム２２５、一つ以上の判定プログラム２２６、イベント受信プログラム２２７、構成取得プログラム２２８、性能取得プログラム２２９は、メモリ２１２に記憶され、ＣＰＵ２１１が実行する。メタルールリポジトリ２３１、構成管理ＤＢ２３２、イベントキューテーブル２３３、メタ診断手順リポジトリ２３４、展開診断手順リポジトリ２３５、メタ収集手段リポジトリ２３６、展開収集手段リポジトリ２３７、および性能テーブル２３８は、ディスク２１３に記憶される。これらのうちの少なくとも１つのプログラムまたは少なくとも１つのデータは、ＣＰＵ２１１が参照可能な他の適当な記憶領域に記憶されてよい。

　ネットワークＩ／Ｆ２１５は、ネットワーク２０５を介して接続されるサーバ２０２、ネットワークスイッチ２０３、ストレージ装置２０４等の管理対象装置から構成情報や性能情報など、コンポーネントに関する情報を取得する。出力デバイス２１７は、表示プログラム２２５からの情報を出力（典型的には表示）するデバイスである。入力デバイス２１４は、ユーザの指示を入力するデバイスである。例えば、入力デバイス２１４としてキーボード、ポインタデバイス等を用いることができ、出力デバイス２１７としてディスプレイ、プリンタ等を用いることができるが、これら以外のデバイスでもよい。

　各サーバ２０２ａ、２０２ｂ、２０２ｃは、アプリケーション等のプログラムを実行する管理対象装置でよい。サーバ２０２ａは、メモリ２４２、ネットワークＩ／Ｆ２４３およびそれらに接続されたＣＰＵ２４６を含む汎用計算機でよい。サーバ２０２ａは、メモリ２４２のほかにＨＤＤのような不揮発性記憶デバイスを有してもよい。サーバ２０２ａは、サーバ２０２ａの状態を監視し特定の状態変化（イベント）が検出された場合にネットワーク２０５を介して管理計算機２０１にそのイベントを表すイベント情報を送信する監視エージェント（プログラム）２４５を含んでもよい。監視エージェント２４５はＣＰＵ２４１で実行されてよい。イベントを通知することは、そのイベントを表すイベント情報を送信することでよい。サーバ２０２ａは、ｉＳＣＳＩ（Internet　Small　Computer　System　Interface）イニシエータ２４４を有してよい。例えば、サーバ２０２ａは、ｉＳＣＳＩディスク２５１を仮想的にローカルＨＤＤのように利用できるが、これはｉＳＣＳＩイニシエータ２４４およびストレージ装置２０４の記憶容量により実現される。ｉＳＣＳＩの代わりにまたはこれに加えて、他の通信および記憶プロトコルが用いられてもよい。なお、サーバ２０２ａの構成を説明したが、サーバ２０２ｂ、２０２ｃもサーバ２０２ａと同じ構成を有してよい。

　各ストレージ装置２０４は、サーバ２０２上で動作するアプリケーション用の記憶容量（論理ボリューム）を提供するための（または他の目的のための）管理対象装置であってよい。ストレージ装置２０４は、Ｉ／Ｏポート２６３、ディスク２６２およびそれらに接続されたストレージコントローラ（例えばＣＰＵ）２６１を有する。Ｉ／Ｏポート２６３は複数存在してよい。ディスク２６２は、１つのＨＤＤであってもよいし、複数のＨＤＤで構成されたＲＡＩＤグループであってもよいが、ディスク２６２における不揮発性記憶デバイスは、ＳＳＤのような他の記憶デバイスであってもよい。本実施例において、ストレージ装置２０４は、サーバ２０２ａ、２０２ｂに対しｉＳＣＳＩ論理ボリュームを記憶容量として提供すべく構成されてよい。従って、２台のサーバ２０２ａ、２０２ｂが、ネットワークスイッチ２０３を介してストレージ装置２０４に接続されていて、ストレージ装置２０４が各サーバ２０２ａ、２０２ｂに対してｉＳＣＳＩ論理ボリュームを提供してよい。また、ストレージ装置２０４は、ストレージ装置２０４の状態を監視して管理計算機２０１にイベント情報を送信する監視エージェント（プログラム）２６４を含んでいてよい。監視エージェント２６４はストレージコントローラ２６１で実行されてよい。あるいは、サーバ２０２の監視エージェント２４５が、ストレージ装置２０４の状態を監視することができてよい。

　ネットワークスイッチ２０３は、サーバ２０２またはストレージ装置２０４から送信されたデータを受信したり受信したデータを送信したりするポート２７１ａ～ｄを有する。また、ネットワークスイッチ２０３は、ネットワークスイッチ２０３の状態を監視し特定の状態変化（イベント）が検出された場合にネットワーク２０５を介して管理計算機２０１にイベント情報を送る監視エージェント（プログラム）２７２を含んでもよい。監視エージェント２７２は、ネットワークスイッチ２０３内の図示しないＣＰＵで実行されてよい。あるいは、サーバ２０２の監視エージェント２４５が、ネットワークスイッチ２０３の状態を監視してもよい。

　＜構成管理ＤＢ＞

　構成管理ＤＢ２３２には、構成取得プログラム２２８が監視エージェント等から取得した管理対象装置の構成情報が格納される。構成情報は、管理対象コンポーネント間の接続関係、依存関係などを示す情報を含む。サーバ２０２、ネットワークスイッチ２０３およびストレージ装置２０４の構成情報の例を、図３～図９に示す。なお、構成管理ＤＢ２３２は、図３～９のテーブルのうちの一部を含まなくてもよいし、少なくとも１つのテーブル中の一部の項目を含まなくてもよい。また、構成管理ＤＢ２３２が格納する各項目のデータ表現形式及びデータ構造は、管理対象装置が持つデータの表現形式及びデータ構造と同じでなくてもよい。また、管理計算機２０１が管理対象装置からこれらの項目を受信する場合、管理対象装置のデータ構造及び表現形式に従い受信してもよい。また、構成管理ＤＢ２３２中のテーブルは、管理対象コンポーネントの構成変更に伴って情報が更新されてもよい。構成管理ＤＢ２３２中のテーブルにおける情報が更新された場合、その更新に関するログが履歴情報として保存されてもよい。ログを基に過去の構成管理ＤＢ２３２が復元されてもよい。

　図３は、構成管理ＤＢ２３２中の装置テーブルの構成例を示す。

　装置テーブル３００は、管理対象装置毎にレコードを有し、各レコードが、３つのフィールド、すなわち装置ＩＤ３０１、装置名３０２および種別３０３を有する。ＩＤ３０１は、管理対象装置を一意に識別する値を格納する。装置名３０２は、管理者が装置を一意に識別できる値を格納する。種別３０３は、装置の種別を示す識別子を格納する。

　図４は、構成管理ＤＢ２３２中のｉＳＣＳＩディスクテーブルの構成例を示す。

　ｉＳＣＳＩディスクテーブル４００は、サーバ２０２が利用しているｉＳＣＳＩディスク２５１の構成を示すテーブルである。ｉＳＣＳＩディスクテーブル４００は、ｉＳＣＳＩディスク２５１毎にレコードを有し、各レコードが、７つのフィールド、すなわちＩＤ４０１、ディスクドライブ名４０２、装置ＩＤ４０３、ｉＳＣＳＩイニシエータ名４０４、接続先ｉＳＣＳＩターゲット４０５、ＬＵＮ　ＩＤ４０６および種別４０７を有する。ＩＤ４０１は、ｉＳＣＳＩディスク（管理対象コンポーネント）２５１を一意に識別する値を格納する。ディスクドライブ名４０２は、サーバ２０２においてｉＳＣＳＩディスク２５１を一意に識別できる値を格納する。装置ＩＤ４０３は、ｉＳＣＳＩディスク２５１を利用するサーバ２０２を示す識別子を格納する。ｉＳＣＳＩイニシエータ名４０４は、ｉＳＣＳＩディスク２５１の実体が存在するストレージ装置２０４との通信の際に用いるサーバ２０２上のネットワークＩ／Ｆ２４３の識別子を格納する。接続先ｉＳＣＳＩターゲット４０５は、ｉＳＣＳＩディスク２５１の実体が存在するストレージ装置２０４との通信の際に用いるストレージ装置２０４上のＩ／Ｏポート２６３の識別子を格納する。ＬＵＮ　ＩＤ４０６は、ｉＳＣＳＩディスク２５１の実体としての論理ボリューム（ストレージ装置２０４における論理ボリューム）の識別子を格納する。種別４０７は、管理対象コンポーネント（ｉＳＣＳＩディスク）の種別を示す識別子を格納する。例えば、１行目のレコードは次のことを意味する。すなわち、「ＳｖＡ」という識別子で識別されるサーバ上で「Ｄ：」というディスクドライブ名で示されるｉＳＣＳＩディスクが、「ＤＲＩＶＥ１」という識別子で識別され、コンポーネントの種別は「ｉＳｃｓｉＤｉｓｋ」である。ｃｏｍ．ｈｉｔａｃｈｉ．ｓｖａというｉＳＣＳＩイニシエータ名で示されるサーバポート（サーバが有するポート）と、ｃｏｍ．ｈｉｔａｃｈｉ．ｓｔｏＣ１というｉＳＣＳＩターゲット名で示されるストレージポート（ストレージ装置が有するポート）を介して、０というＬＵＮ　ＩＤの論理ボリュームがストレージ装置からサーバに提供される。

　図５は、構成管理ＤＢ２３２中のネットワークＩ／Ｆテーブルの構成例を示す。

　ネットワークＩ／Ｆテーブル５００は、ネットワークＩ／Ｆ２４３毎にレコードを有し、各レコードが、５つのフィールド、すなわちＩＤ５０１、Ｉ／Ｆ名５０２、装置ＩＤ５０３、ｉＳＣＳＩイニシエータ名５０４および種別５０５を有する。ＩＤ５０１は、ネットワークＩ／Ｆ２４３（管理対象コンポーネント）を一意に識別する値を格納する。Ｉ／Ｆ名５０２は、サーバ２０２においてネットワークＩ／Ｆ２４３の識別子となる値を格納する。装置ＩＤ５０３は、ネットワークＩ／Ｆ２４３を有するサーバ２０２の識別子を格納する。ｉＳＣＳＩイニシエータ名５０４は、ｉＳＣＳＩディスクの実体が存在するストレージ装置との通信の際に用いるサーバ２０２上のネットワークＩ／Ｆ２４３の識別子を格納する。種別５０５は、管理対象コンポーネントの種別を示す識別子を格納する。例えば、１行目のレコードは次のことを意味する。「ｅｔｈ０」というＩ／Ｆ名で示されるネットワークＩ／Ｆが、「ＳｖＡ」という識別子で識別されるサーバに存在し、「ＳＶＩＦ１」という識別子で識別され、コンポーネントの種別は「ＳｅｒｖｅｒＩＦ」であり、ストレージ装置の通信の際に識別子として用いるｉＳＣＳＩイニシエータ名は「ｃｏｍ．ｈｉｔａｃｈｉ．ｓｖａ」である。

　図６は、構成管理ＤＢ２３２中のスイッチポートテーブルの構成例を示す。

　スイッチポートテーブル６００は、ネットワークスイッチ２０３が有するＩ／Ｏポート２７１毎にレコードを有し、各レコードが、５つのフィールド、すなわちＩＤ６０１、ポート番号６０２、装置ＩＤ６０３、接続先ポート６０４および種別６０５を有する。ＩＤ６０１は、Ｉ／Ｏポート２７１（管理対象コンポーネント）を一意に識別する値を格納する。ポート番号６０２は、ネットワークスイッチ２０３においてＩ／Ｏポート２７１を一意に識別する値を格納する。装置ＩＤ６０３は、Ｉ／Ｏポート２７１を有するネットワークスイッチ２０３の識別子を格納する。接続先ポート６０４は、Ｉ／Ｏポート２７１に接続されているサーバ２０２のネットワークＩ／Ｆ２４３あるいはストレージ装置２０４のＩ／Ｏポート２６３の識別子が格納される。ネットワークスイッチ２０３が多段に接続されている場合は、複数のサーバのネットワークＩ／Ｆあるいはストレージ装置のＩ／Ｏポートから出力されたデータがネットワークスイッチのポートを通るため、複数の識別子が接続先ポート６０４に格納されていてよい。種別６０５は、管理対象コンポーネントの種別を示す識別子を格納する。例えば、１行目のレコードは、次のことを意味する。「０」という番号で示されるＩ／Ｏポートが、「ＳｗＤ」という識別子で識別されるネットワークスイッチにあり、「ＳＷＰＯＲＴ１」という識別子で識別され、コンポーネントの種別が「ＮＷＳｗｉｔｃｈＰｏｒｔ」であり、「ＳＴＰＯＲＴ１」で識別されるＩ／Ｏポートに接続されている。

　図７は、構成管理ＤＢ２３２中のｉＳＣＳＩターゲットテーブルの構成例を示す。

　ｉＳＣＳＩターゲットテーブル７００は、ｉＳＣＳＩターゲット毎にレコードを有し、各レコードが、２つのフィールド、すなわちｉＳＣＳＩターゲット名７０１および接続許可ｉＳＣＳＩイニシエータ７０２を有する。ｉＳＣＳＩターゲット名７０１は、各ｉＳＣＳＩターゲットが持つｉＳＣＳＩターゲット名を格納する。接続許可ｉＳＣＳＩイニシエータ７０２は、ｉＳＣＳＩターゲットに属する論理ボリュームに対しアクセスが許可されたサーバ上のネットワークＩ／Ｆ２４３の識別子となるｉＳＣＳＩイニシエータ名を格納する。例えば、１行目のレコードは、次のことを意味する。「ｃｏｍ．ｈｉｔａｃｈｉ．ｓｔｏＣ１」で識別されるｉＳＣＳＩターゲットに属する論理ボリュームに対し、「ｃｏｍ．ｈｉｔａｃｈｉ．ｓｖａ」、「ｃｏｍ．ｈｉｔａｃｈｉ．ｓｖｂ」で識別されるサーバ上のネットワークＩ／Ｆ２４３は、アクセスが許可されている。

　図８は、構成管理ＤＢ２３２中のストレージポートテーブルの構成例を示す。

　ストレージポートテーブル８００は、ストレージ装置２０４が有するＩ／Ｏポート２６３毎にレコードを有し、各レコードが、５つのフィールド、すなわちＩＤ８０１、ポート番号８０２、装置ＩＤ８０３、ｉＳＣＳＩターゲットＩＤ８０４および種別８０５を有する。ＩＤ８０１は、Ｉ／Ｏポート２６３（管理対象コンポーネント）を一意に識別する値を格納する。ポート番号８０２は、ストレージ装置２０４においてＩ／Ｏポート２６３を一意に識別する値を格納する。装置ＩＤ８０３は、Ｉ／Ｏポート２６３を有するストレージ装置２０４の識別子を格納する。ｉＳＣＳＩターゲット８０４は、Ｉ／Ｏポート２６３を使用するｉＳＣＳＩターゲットの識別子を格納する。種別６０５は、管理対象コンポーネントの種別を示す識別子を格納する。例えば、１行目のレコードは、次のことを意味する。「０」という番号で示されるＩ／Ｏポートが、「ＳｔｏＣ」という識別子で識別されるストレージ装置にあり、「ＳＴＰＯＲＴ１」という識別子で識別され、コンポーネントの種別は「ＳｔｏｒａｇｅｉＳＣＳＩＰｏｒｔ」であり、「ｃｏｍ．ｈｉｔａｃｈｉ．ｓｔｏＣ１」で識別されるｉＳＣＳＩターゲットに使用されている。

　＜性能テーブル＞

　性能テーブル２３８には、性能取得プログラム２２９が監視エージェント等から取得した管理対象装置を構成する管理対象コンポーネントの性能情報が格納される。

　図９は、性能テーブル２３８の構成例を示す。

　性能テーブル２３８は、性能情報毎にレコードを有し、各レコードが、５つのフィールド、すなわち、コンポーネントＩＤ９０１、メトリック９０２、時刻９０３、値９０４および単位９０５を有する。コンポーネントＩＤ９０１は、性能情報の取得元の管理対象コンポーネントを一意に識別する値を格納する。メトリック９０２は、管理対象コンポーネントの性能の観測項目（メトリック）を識別する値を格納する。時刻９０３は、管理対象コンポーネントの性能を観測した時刻を格納する。時刻は、年月時刻分の単位であるが、それよりも粗い単位でも細かい単位でもよい。値９０４は、管理対象コンポーネントの性能として観測した値を格納する。単位９０５は、観測した値に対する単位を格納する。例えば、１行目のレコードは、次のことを意味する。「ＳＷＰＯＲＴ１」という識別子で識別される管理コンポーネント（ここでは、ネットワークスイッチＤのポート０）の「ＴｘＤｒｏｐＰａｃｋｅｔＮｕｍ」で識別される観測項目に対して、２０１３／０１／０１／０：００に「０　Ｐａｃｋｅｔｓ／ｓｅｃ」という性能が観測された。

　＜イベントキューテーブル＞

　図１０は、イベントキューテーブル２３３の構成例を示す。

　イベントキューテーブル２３３は、イベント受信プログラム２２７が管理対象装置の監視エージェント等から取得したイベント情報を格納する。イベントキューテーブル２３３は、イベント情報毎にレコードを有し、各レコードが、５つのフィールド、すなわち、イベントＩＤ１００１、装置ＩＤ１００２、コンポーネントＩＤ１００３、イベント種別１００４および発生時刻１００５を有する。イベントＩＤ１００１は、イベント情報を一意に識別するための識別子を格納する。装置ＩＤ１００２は、イベント情報の取得元の管理対象装置を一意に識別するための識別子を格納する。コンポーネントＩＤ２０３は、イベント情報の取得元の管理対象コンポーネントを一意に識別するための識別子を格納する。イベント種別１００４は、管理対象コンポーネントで発生したイベントの種別を示す識別子を格納する。発生時刻１００５は、イベントが発生した時刻（取得されたイベント情報が含む時刻）を格納する。発生時刻１００５は、管理計算機２０１がイベント情報を受信した時刻を格納してもよい。イベントが、装置の要素に関するイベントではなく、装置そのものに関するイベントである場合、コンポーネントＩＤ１００３の値は装置ＩＤ１００２の値と等しくてもよい。例えば、１行目のレコードは、次のことを意味する。装置ＩＤがＳｗＤであるネットワークスイッチ２０３のコンポーネントＩＤがＳＷＰＯＲＴ１であるＩ／Ｏポート２７３において「ＴｘＤｒｏｐＰａｃｋｅｔＮｕｍＥｒｒｏｒ（送信ドロップパケット数異常）」が２０１３年１月１日０時０分に発生した。

　＜メタルールリポジトリおよびメタルール＞

　イベント分析プログラム２２２が、障害原因解析を実行する。障害原因解析は、例えば、特許文献１に記載の解析と同じでよい。そして、イベント分析プログラム２２２が、ＩＴシステムで発生した複数の障害の伝播元となった障害を絞り込んだ後、伝播元となった障害の発生原因を特定すべく診断を実行する。メタルールは、イベント分析プログラム２２２が分析時に使用する情報である。メタルールは、あるトポロジ（あるＩ／Ｏの経路上に存在する１つまたは複数の管理対象コンポーネントのグループ）のパターンにおいて発生し得るイベントの組合せと、それらのイベントが同じタイミングで発生した場合に障害の原因候補との対応関係を示す情報である。実施例１では、メタルールに定義される原因候補はシステム障害の伝播元となる障害を示す。メタルールは、メタルールが示す障害の原因イベントに対して詳細な診断を実行する際に使用するメタ診断手順を識別する情報と診断の対象となるトポロジの起点となる管理対象コンポーネントの情報を有する。本実施例においては、メタルールはＩＦ－ＴＨＥＮ形式で記述されるが、システム障害の原因イベントと、原因イベントによって引き起こされる観測イベント（観測されるイベント）が記述されていればそれ以外の形式であってもよい。

　図１１Ａは、メタルールリポジトリ２３１に常駐するメタルール１１００の構成例を示す。

　一般に、ルールは、２つの部分（フィールド）、すなわち「ＩＦ」部１１１１と呼ばれる第１の部分および「ＴＨＥＮ」部１１１２と呼ばれる第２の部分に分けることができる。ＩＦ部１１１１は１つ以上の条件要素を含んでいてよい。

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

　本実施例においては、イベント分析プログラム２２２は、図１０のイベントキューテーブル２３３に格納されるイベント情報が表すイベントを観測イベントとし、分析を行う。そのため、ＩＦ部１１１１は、条件要素毎にエントリを有し、各エントリが、装置種別１１０１、コンポーネント種別１１０２およびイベント種別１１０３を有する。すなわち、管理対象装置やその要素は、管理計算機２０１においていくつかの種別に分類されており、ＩＦ部１１１１の条件要素は、指定した種別の管理対象コンポーネントにおいて指定したイベント種別が示す状態が発生することを示す。条件要素が、装置の要素ではなく、装置そのものに関するイベントを示す場合は、その条件要素についてのコンポーネント種別１１０２の値は装置種別１１０１と等しい値であってもよい。

　また、メタルール１１００は、各々のメタルールを一意に識別するメタルールＩＤを格納するフィールドであるメタルールＩＤ１１１３と、メタルール１１００を実際の管理対象のＩＴシステムの構成に適用して展開ルールを生成する際にメタルール１１００を適用するトポロジの条件を格納するためのフィールドであるトポロジ条件１１１４とを含む。本実施例においては、トポロジ条件として、構成管理ＤＢ２３２からトポロジの情報を取得する方式を例に挙げている。例えば、図１１Ａに示すトポロジ条件の例は、メタルールを適用するトポロジが、ｉＳＣＳＩディスクと、そのｉＳＣＳＩディスクの記憶容量を提供すべく使用されるサーバのネットワークＩ／Ｆ、および、ストレージ装置のＩ／Ｏポートと、それら２つのＩ／Ｏポートの間にあるネットワークスイッチのＩ／Ｏポートの組合せであることを示している。

　さらに、本実施例では、メタルールを用いて導出された結論に基づき、さらに詳細に原因イベントを特定するための診断を実行するため、メタルール１１００は、メタ診断手順の識別子、診断の対象となるトポロジの起点となる装置、および管理対象コンポーネントの条件を格納するためのフィールド１１１５を含む。図１１のメタルールが障害原因解析で使用された場合、そのメタルールに関連付けられているメタ診断手順ＩＤ（そのメタルールのフィールド１１１５に記述されているメタ診断手順ＩＤ）から識別されるメタ診断手順が使用される。図１１Ａの例では、「メタ診断手順ＩＤ＝（識別子），起点＝（装置種別　コンポーネント種別）」という形式でメタ診断手順の識別子と起点の条件が格納されている。フィールド１１１５には、複数の組合せ（メタ診断手順の識別子と起点の条件の組合せ）が格納されていてよい。また、複数のメタルール１１００の各々のフィールド１１１５に１つのメタ診断手順の識別子が格納されていてよい。診断の対象となるトポロジは、メタルール１１００が適用されるトポロジと異なっていてよい。診断の対象となるトポロジに関する説明については後述する。

　例えば、図１１Ａのメタルール「ＭｅｔａＲｕｌｅ１」は、観測イベントとして「サーバ２０２上のｉＳＣＳＩディスク１５１のディスクアクセスレスポンス時間異常」と、「ネットワークスイッチ２０３におけるＩ／Ｏポート２７１の送信ドロップパケット数異常」とが検知されたときに、「ネットワークスイッチ２０３におけるＩ／Ｏポート２７１の送信ドロップパケット数異常」がボトルネックであると結論付けられることを示している。また、メタルール「ＭｅｔａＲｕｌｅ１」を用いて分析を行う際には、トポロジ条件１１１４に格納された条件に基づいてメタルールを適用するトポロジの情報が、構成管理ＤＢ等から取得される。また、ＴＨＥＮ部１１１２に記述された結論を詳細解析する場合には、「ＭｅｔａＤｉａｇｎｏｓｔｉｃＰｒｏｃ１」で識別されるメタ診断手順を用い、取得したトポロジ情報のうち、「ネットワークスイッチ２０３のＩ／Ｏポート２７１」に当てはまる管理対象コンポーネントを起点とした別のトポロジに対して診断を実行する（フィールド１１１５中の「起点＝(NetworkSwitch　NWSwitchPort)」を参照）。メタ診断手順を用いて詳細解析をする際に、イベント分析プログラム２２２の分析対象となったトポロジ内の管理対象コンポーネントを起点とし、診断対象トポロジを別に定義できるようにすることで、イベント分析の対象となったトポロジの周辺の管理対象コンポーネントも含めて診断対象とすることができる。なお、ＩＦ部１１１１に含まれる条件要素として、あるコンポーネントが正常であること（障害イベントが発生していないこと）を定義してもよい。また、ＴＨＥＮ部１１１２のイベント種別１１０３が表すイベント種別は、新たに定義してもよく、イベント受信プログラム２２７が受信するイベントのイベント種別でなくてもよい。

　＜展開ルール＞

　展開ルールは、ＩＴシステムにおいて発生し得るイベントの組み合わせと、それらのイベントが発生した場合の障害の原因候補となるイベントとの対応関係を示す情報である。実施例１では、展開ルールに定義される原因候補はシステム障害の伝播元となる障害を示す。展開ルールは、メタルール１１００のトポロジ条件１１１４に基づいて、メタルール１１００を適用可能なトポロジを管理対象ＩＴシステムの中から検索し、検索されたトポロジに対してメタルール１１００を適用した結果として生成されるルールである。また、展開ルールは、イベント分析プログラム２２２が分析時に使用する情報である。

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

　図１１Ｂは、展開ルールの構成例を示す。

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

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

　本実施例においては、図１０のイベントキューテーブル２３３に格納されるイベント情報が表す観測イベントとし、イベント分析プログラム２２２によって障害の原因候補を絞り込む。展開ルール１１５０のＩＦ部１１５１は、条件要素毎にエントリを有し、各エントリが、装置ＩＤ１１６１、コンポーネントＩＤ１１６２、イベント種別１１６３および受信フラグ１１６４というフィールドを有する。すなわち、ＩＦ部１１５１の条件要素は、装置ＩＤ１１６１およびコンポーネントＩＤ１１６２によって指定される管理対象コンポーネントにおいてイベント種別１１６３の情報によって示される状態が発生することを示す。また、受信フラグ１１６４は、実際に条件要素が示すイベントを受信したか否かの結果を格納する。条件要素が示すイベントを受信した場合は、受信フラグ１１６４に「１」が格納され、条件要素が示すイベントを受信していない場合は、受信フラグ１１６４に「０」が格納される。受信フラグ１１６４に「１」が格納されてから所定の時間が経過するとその値が「０」に戻されるなどの処理が行われてもよい。

　ＩＦ部１１５１およびＴＨＥＮ部１１５２の各々において、装置ＩＤ１１６１とコンポーネントＩＤ１１６２に格納される値は、メタルール１１００のトポロジ条件１１１４に基づいて構成管理ＤＢ２３２から特定された装置ＩＤおよびコンポーネントＩＤのうち、装置種別１１０１及びコンポーネント種別１１０２で定義された種別に該当する値である。

　また、展開ルール１１５０は、その展開ルール１１５０を一意に識別する展開ルールＩＤを格納するフィールドである展開ルールＩＤ１１５３を含む。また、展開ルール１１５０は、その展開ルール１１５０を用いて導出された結論に基づきさらに詳細に原因イベントを特定するための診断を実行するため、メタ診断手順の識別子、診断の対象となるトポロジの起点となる装置、および管理対象コンポーネントの識別子を格納するためのフィールド１１５５を有する。フィールド１１５５に格納される値のうち、メタ診断手順ＩＤは、展開ルール１１５０を生成するときに使用したメタルール１１００のフィールド１１１５に格納されている値と等しい。また、フィールド１１５５に格納される値のうち、起点として格納される装置ＩＤおよびコンポーネントＩＤは、メタルール１１００のトポロジ条件１１１４に基づいて構成管理ＤＢ２３２から特定された装置ＩＤおよびコンポーネントＩＤのうち、メタルール１１００のフィールド１１１５に格納された「起点の条件」に該当するＩＤである。図１１Ｂの例では、「メタ診断手順ＩＤ＝（識別子），起点＝（装置ＩＤ　コンポーネントＩＤ）」という形式で値が格納されている。図１１Ｂは、図１１Ａのメタルール１１００を図３～図８が示す構成管理ＤＢ２３２に基づいて展開し生成された展開ルール１１５０ａ～１１５０ｄを示す。例えば、展開ルール１１５０ａ「ＥｘｐａｎｄｅｄＲｕｌｅ１」は、観測イベントとして「サーバＡ（ＩＤ＝ＳｖＡ）のＤドライブ（ＩＤ＝ＤＲＩＶＥ１）のディスクアクセスレスポンス時間異常」と、「ネットワークスイッチＤ（ＩＤ＝ＳｗＤ）におけるポート０（ＩＤ＝ＳＷＰＯＲＴ１）の送信ドロップパケット数異常」とが検知された場合、「ネットワークスイッチＤにおけるポート０の送信ドロップパケット数異常」がボトルネックであると結論付けられることを示す。また、その展開ルール１１５０ａのＴＨＥＮ部１１５２に記述された結論を詳細解析する場合には、「ＭｅｔａＤｉａｇｎｏｓｔｉｃＰｒｏｃ１」で識別されるメタ診断手順を用い、「装置ＩＤがＳｗＤ、コンポーネントＩＤがＳＷＰＯＲＴ１」で識別される管理対象コンポーネントを起点としたトポロジに対して診断が実行される。なお、ＩＦ部１１５１に含まれる条件要素として、あるコンポーネントが正常であること（障害イベントが発生していないこと）を定義してもよい。

　＜メタ診断手順リポジトリおよびメタ診断手順＞

　メタ診断手順は、イベント分析プログラム２２２によって、ＩＴシステムの障害の伝播元となる障害を絞り込んだ後、障害原因イベントを特定すべく実行される診断の一連の手順である。メタ診断手順は、診断に必要な情報を収集するステップと、収集した情報に基づいて判定を行うステップと、１つあるいは複数の判定の結果に基づいて導出される結論で構成される。メタ診断手順を実行する対象となる具体的な管理対象コンポーネントは定義されておらず、手順を実行する対象となるトポロジのパターンや構成のパターンが定義される。

　図１２は、メタ診断手順リポジトリ２３４に常駐するメタ診断手順１２００の構成例を示す。

　メタ診断手順１２００は、そのメタ診断手順１２００に関する情報を格納する基本オブジェクト１２０１と、診断に必要な情報を収集する手段を格納した情報収集オブジェクト１２０２と、収集した情報に基づいて判定する手段を格納した判定オブジェクト１２０３と、１つあるいは複数の判定の結果に基づいて導出される結論の情報を格納した結論オブジェクト１２０４とで構成される。本実施例においては、メタ診断手順１２００は、オブジェクト構造であるが、情報を収集する手段の情報と、判定のステップの情報と、判定の結果に基づいて導出される結論の情報の組合せで構成されていれば、他のデータ構造であってもよい。オブジェクト１２０１～１２０４のうちオブジェクト１２０１以外は複数存在し得る。図１２に例示されるメタ診断手順１２００は、基本オブジェクト１２０１と、２つの情報収集オブジェクト１２０２ａおよび１２０２ｂと、２つの判定オブジェクト１２０３ａおよび１２０３ｂと、３つの結論オブジェクト１２０４ａ、１２０４ｂおよび１２０４ｃとで構成されている。

　基本オブジェクト１２０１は、５つのフィールド、すなわち、タイプ１２１１、ＩＤ１２１２、メタ診断手順ＩＤ１２１３、トポロジ条件ＩＤ１２１４およびＮｅｘｔＩＤ１２１５を有する。タイプ１２１１は、オブジェクトの種別を識別するための識別子（例えば、基本情報であることを示す「Ｓｔａｒｔ」）を格納する。ＩＤ１２１２は、オブジェクトを一意に識別するための識別子を格納する。メタ診断手順ＩＤ１２１３は、メタ診断手順１２００を一意に識別するための識別子を格納する。トポロジ条件ＩＤ１２１４は、メタ診断手順１２００を適用するトポロジの条件を一意に識別するための識別子を格納する。ＮｅｘｔＩＤ１２１５は、最初に実行するステップを格納したオブジェクトの識別子を格納する。

　情報収集オブジェクト１２０２は、４つのフィールド、すなわち、タイプ１２２１、ＩＤ１２２２、手段ＩＤ１２２３およびＮｅｘｔＩＤ１２２４を有する。タイプ１２２１は、オブジェクトの種別を識別するための識別子（例えば、情報収集手段が格納されていることを示す「ＣｏｌｌｅｃｔＩｎｆｏ」）を格納する。ＩＤ１２２２は、ＩＤ１２１２と同様に、オブジェクトを一意に識別するための識別子を格納する。手段ＩＤ１２２３は、メタ収集手段を一意に識別するための識別子を格納する。手段ＩＤ１２２３に格納された識別子を基に、メタ収集手段リポジトリ２３６から診断に必要なメタ収集手段が検索される。ＮｅｘｔＩＤ１２２５は、次に実行するステップを格納したオブジェクトの識別子を格納する。例えば、情報収集オブジェクト１２０２ａは、診断実行時に、「ＧｅｔＩｎｆｏ１」という識別子で識別されるメタ収集手段をメタ収集手段リポジトリ２３６から取得し、その手段に基づいて情報収集を行った後、ＩＤが「２」のオブジェクトが示すステップを実行することを示している。

　判定オブジェクト１２０３は、５つのフィールド、すなわち、タイプ１２３１、ＩＤ１２３２、判定プログラムＩＤ１２３３、引数１２３４およびＤｅｃｉｓｉｏｎ　Ｍａｐ１２３５を有する。タイプ１２３１は、オブジェクトの種別を識別するための識別子（例えば、判定ステップに関する情報が格納されていることを示す「Ｄｅｃｉｓｉｏｎ」）を格納する。ＩＤ１２３２は、ＩＤ１２１２と同様に、オブジェクトを一意に識別するための識別子を格納する。判定プログラムＩＤ１２３３は、収集した情報に基づいて判定を行うプログラムを一意に識別する識別子を格納する。判定プログラムＩＤに格納された識別子を基に、メモリ２１２に常駐する判定プログラム２２６が呼び出される。引数１２３４は、判定プログラム２２６によって判定を実行する際に使用する情報の識別情報を格納する。Ｄｅｃｉｓｉｏｎ　Ｍａｐ１２３５は、キー１２３６とＮｅｘｔＩＤ１２３７の組合せの一覧を格納する。キー１２３６は、判定プログラム２２６の戻り値になり得る値を格納し、ＮｅｘｔＩＤ１２３７は、オブジェクトの識別子を格納する。すなわち、Ｄｅｃｉｓｉｏｎ　Ｍａｐ１２３５には、診断実行時に、判定プログラム２２６の戻り値に応じて、次に実行するステップを決定するための情報が格納される。例えば、判定オブジェクト１２０３ａは、診断実行時に、「判定プログラム１」という識別子で識別される判定プログラム２２６を起動させ、「判定プログラム１」に引数として「１」という識別子で識別されるオブジェクト１２０２ａで収集した情報を渡し、「判定プログラム１」の戻り値が「ＹＥＳ」であった場合は「３」という識別子で識別されるオブジェクト１２０２ｂが示すステップを実行し、戻り値が「ＮＯ」であった場合は「４」という識別子で識別されるオブジェクト１２０４ａが示すステップを実行することを示している。また、１つの判定プログラムの例として、「判定プログラム１」は、「引数として与えられた性能情報の上昇率が事前に定義された値以上であるかどうかを判定し、その値以上であればＹＥＳを、その値未満であればＮＯを返すプログラム」などであってよい。

　結論オブジェクト１２０４は、３つのフィールド、すなわち、タイプ１２４１、ＩＤ１２４２およびＣｏｎｃｌｕｓｉｏｎ１２４３を有する。タイプ１２４１は、オブジェクトの種別を識別するための識別子（例えば、結論に関する情報が格納されていることを示す「Ｅｎｄ」）を格納する。ＩＤ１２４２は、ＩＤ１２１２と同様に、オブジェクトを一意に識別するための識別子を格納する。Ｃｏｎｃｌｕｓｉｏｎ１２４３は、診断実行時において診断の結論となる情報を格納する。例えば、Ｃｏｎｃｌｕｓｉｎｏ１２４３に格納された情報が、出力デバイス２１７に表示されてもよい。例えば、診断実行時に、判定オブジェクト１２０３ａの判定結果によって結論オブジェクト１２０４ａが結論として選択された場合、診断結果として「“ネットワークスイッチポート”の帯域不足」が出力デバイス２１７に表示される。ただし、“ネットワークスイッチポート”には、トポロジ条件ＩＤ１２１４が示すトポロジ条件に基づいて構成管理ＤＢ２３２から取得したネットワークスイッチポートの識別情報が表示される。

　図１３は、メタ診断手順１２００を適用するトポロジ条件の構成例を示す。

　トポロジ条件１３００は、２つのフィールド、すなわち、トポロジ条件ＩＤ１３０１および条件１３０２を有する。トポロジ条件ＩＤ１３０１は、トポロジ条件を一意に識別する識別子を格納する。トポロジ条件ＩＤ１３０１に格納される値は、図１２の基本オブジェクト１２０１のトポロジ条件ＩＤ１２１４に格納される識別子と等しい。条件１３０２は、メタ診断手順１２００を適用するトポロジの条件に関する情報を格納する。本実施例においては、構成管理ＤＢ２３２からトポロジの情報を取得する方式を例に挙げている。例えば、図１３の条件１３０２に基づいてトポロジの情報を取得する場合、（１）スイッチポートテーブル６００の装置ＩＤ６０３の値が、展開ルールのフィールド１１５５に格納された起点の装置ＩＤと等しく、かつ（２）ネットワークＩ／Ｆテーブル５００のＩＤ５０１の値が、（１）のスイッチポートテーブル６００のレコードの接続先ポートの値と等しいレコードの組合せを取得する。つまり、条件１３０２が表す起点の管理対象コンポーネントと、その条件１３０２において起点の管理対象コンポーネントに関連付けられている管理対象コンポーネントとを含んだトポロジが特定される。条件１３０２に格納するトポロジ条件は、トポロジの情報を取得するための方法が記述されていれば、図１３に示す形式でなくてよい。

　＜メタ収集手段リポジトリおよびメタ収集手段＞

　図１４は、メタ収集手段リポジトリ２３６に格納されたメタ収集手段の構成例を示す。

　メタ収集手段１４００は、２つのフィールド、すなわち、手段ＩＤ１４０１および収集手段１４０２を有する。手段ＩＤ１４０１は、メタ収集手段１４００を一意に識別する識別子を格納する。手段ＩＤ１４０１に格納される値は、図１２の情報収集オブジェクト１２０２の手段ＩＤ１２２３に格納される識別子と等しい。メタ収集手段１４０２は、診断に必要な情報収集手段を格納する。本実施例においては、診断に必要な情報の１つの例として、性能テーブル２３８から取得できる管理対象コンポーネントの性能情報が挙げられる。そのため、例えば、メタ収集手段１４０２ａには、テーブルから情報を取得するためのクエリが格納される。ただし、どの管理対象コンポーネントの性能情報を収集するかは、イベント分析プログラム２２２の導出した結論によるため、管理対象コンポーネントの識別子は変数とする。図１４の例では、ダブルクォーテーションでかこった部分を変数として表現している（この点は、メタ収集手段１４０２ｂについても同様である）。

　＜展開診断手順リポジトリおよび展開診断手順＞

　展開診断手順は、メタ診断手順とトポロジ情報に基づいて診断手順展開プログラム２２３によって展開される診断手順である。展開診断手順は、メタ診断手順と同様に、診断に必要な情報を収集するステップと、収集した情報に基づいて判定を行うステップと、１つあるいは複数の判定の結果に基づいて導出される結論で構成される。メタ診断手順には、実行する対象となる具体的なコンポーネントは定義されていなかったのに対し、展開診断手順は、トポロジ情報に基づいて、実行の対象となるコンポーネントが定義される。

　図１５は、展開診断手順リポジトリ２３５に格納される展開診断手順１５００の構成例を示す。なお、展開診断手順リポジトリ２３５は、一度生成した展開診断手順を別の診断で再利用するために保存するリポジトリであり、そのリポジトリが必ずしも管理計算機２０１に無くてもよい。また、図１では展開診断手順に「１２４」という参照符号が付されているが、図１５に示す展開診断手順は図１の展開診断手順と構成が違っているため、図１５の展開診断手順は図１の展開診断手順と違う参照符号「１５００」を使用している。しかし、図１の展開診断手順も図１５の展開診断手順も同じ方法で生成された手順でよい。

　展開診断手順１５００は、展開診断手順に関する情報を格納する基本オブジェクト１５０１と、診断に必要な情報を収集する手段を格納した情報収集オブジェクト１５０２と、収集した情報に基づいて判定する手段を格納した判定オブジェクト１５０３と、１つあるいは複数の判定の結果に基づいて導出される結論の情報を格納した結論オブジェクト１５０４で構成される。本実施例においては、展開診断手順は、オブジェクト構造であるが、情報を収集する手段の情報と、判定のステップの情報と、判定の結果に基づいて導出される結論の情報の組合せで構成されていれば、他のデータ構造であってもよい。オブジェクト１５０１～１５０４のうちオブジェクト１５０１以外は複数存在し得る。図１５に例示される展開診断手順１５００は、基本オブジェクト１５０１と、２つの情報収集オブジェクト１５０２ａおよび１５０２ｂと、２つの判定オブジェクト１５０３ａおよび１５０３ｂと、３つの結論オブジェクト１５０４ａ、１５０４ｂおよび１５０４ｃとで構成されている。

　基本オブジェクト１５０１は、６つのフィールド、すなわち、タイプ１５１１、ＩＤ１２１２、メタ診断手順ＩＤ１５１３、展開診断手順ＩＤ１５１４，経路リスト１５１５およびＮｅｘｔＩＤ１５１６を有する。タイプ１５１１は、メタ診断手順１２００のタイプ１２１１と同様に、オブジェクトの種別を識別するための識別子（例えば、基本情報であることを示す「Ｓｔａｒｔ」）を格納する。ＩＤ１５１２は、オブジェクトを一意に識別するための識別子を格納する。メタ診断手順ＩＤ１５１３は、展開診断手順１５００を生成する際に使用したメタ診断手順１２００の識別子を格納する。展開診断手順ＩＤ１５１４は、展開診断手順１５００を一意に識別するための識別子を格納する。経路リスト１５１５は、診断実行時に、参照した展開診断手順１５００のオブジェクトのＩＤの一覧を格納する。すなわち、経路リスト１５１５は、診断実行後に、診断のために収集した情報と判定結果と判定結果に基づいて導出された結論を取得できるようなデータ構造であればよい。ＮｅｘｔＩＤ１５１６は、最初に実行するステップを格納したオブジェクトの識別子を格納する。

　情報収集オブジェクト１５０２は、４つのフィールド、すなわち、タイプ１５２１、ＩＤ１５２２、展開手段ＩＤ１５２３およびＮｅｘｔＩＤ１５２４を有する。タイプ１５２１は、メタ診断手順１２００のタイプ１２２１と同様に、オブジェクトの種別を識別するための識別子（例えば、情報収集手段が格納されていることを示す「ＣｏｌｌｅｃｔＩｎｆｏ」）を格納する。ＩＤ１５２２は、ＩＤ１５１２と同様に、オブジェクトを一意に識別するための識別子を格納する。展開手段ＩＤ１５２３は、展開収集手段を一意に識別するための識別子を格納する。展開手段ＩＤ１２２３に格納された識別子を基に、展開収集手段リポジトリ２３７から診断に必要な展開収集手段が検索される。ＮｅｘｔＩＤ１５２５は、次に実行するステップを格納したオブジェクトの識別子を格納する。例えば、情報収集オブジェクト１５０２ａは、診断実行時に、「ＥｘｐａｎｄｅｄＧｅｔＩｎｆｏ１－１」という識別子で識別される情報収集手段を展開収集手段リポジトリ２３７から取得し、その手段に基づいて情報収集を行った後、ＩＤが「Ｐｒｏｃ１－１－２」のオブジェクトが示すステップを実行することを示している。

　判定オブジェクト１５０３は、５つのフィールド、すなわち、タイプ１５３１、ＩＤ１５３２、判定プログラムＩＤ１５３３、引数１５３４およびＤｅｃｉｓｉｏｎ　Ｍａｐ１５３５を有する。タイプ１５３１は、メタ診断手順１２００のタイプ１２３１と同様に、オブジェクトの種別を識別するための識別子（例えば、判定ステップに関する情報が格納されていることを示す「Ｄｅｃｉｓｉｏｎ」）を格納する。ＩＤ１５３２は、ＩＤ１５１２と同様に、オブジェクトを一意に識別するための識別子を格納する。判定プログラムＩＤ１５３３は、収集した情報に基づいて判定を行うプログラムを一意に識別する識別子を格納する。判定プログラムＩＤ１５３３には、メタ診断手順１２００の判定プログラムＩＤ１２３３と等しい値が格納される。判定プログラムＩＤに格納された識別子を基に、メモリ２１２に常駐する判定プログラム２２６が呼び出される。引数１５３４は、判定プログラム２２６によって判定を実行する際に使用する情報の識別情報を格納する。Ｄｅｃｉｓｉｏｎ　Ｍａｐ１５３５は、メタ診断手順１２００のＤｅｃｉｓｉｏｎ　Ｍａｐ１２３５と同様に、キー１５３６とＮｅｘｔＩＤ１５３７の組合せの一覧を格納する。キー１５３６は、判定プログラム２２６の戻り値になり得る値を格納し、ＮｅｘｔＩＤ１５３７は、オブジェクトの識別子を格納する。すなわち、Ｄｅｃｉｓｉｏｎ　Ｍａｐ１５３５には、診断実行時に、判定プログラム２２６の戻り値に応じて、次に実行するステップを決定するための情報が格納される。例えば、判定オブジェクト１５０３ａは、診断実行時に、「判定プログラム１」という識別子で識別される判定プログラム２２６を起動させ、「判定プログラム１」に引数として「Ｐｒｏｃ１－１－１」という識別子で識別されるオブジェクト１５０２ａで収集した情報を渡し、「判定プログラム１」の戻り値が「ＹＥＳ」であった場合は「Ｐｒｏｃ１－１－３」という識別子で識別されるオブジェクト１５０２ｂが示すステップを実行し、戻り値が「ＮＯ」であった場合は「Ｐｒｏｃ１－１－４」という識別子で識別されるオブジェクト１５０４ａが示すステップを実行することを示している。

　結論オブジェクト１５０４は、３つのフィールド、すなわち、タイプ１５４１、ＩＤ１５４２およびＣｏｎｃｌｕｓｉｏｎ１５４３を有する。タイプ１５４１は、メタ診断手順１２００のタイプ１２４１と同様に、オブジェクトの種別を識別するための識別子（例えば、結論に関する情報が格納されていることを示す「Ｃｏｎｃｌｕｓｉｏｎ」）を格納する。ＩＤ１５４２は、ＩＤ１５１２と同様に、オブジェクトを一意に識別するための識別子を格納する。Ｃｏｎｃｌｕｓｉｏｎ１５４３には、診断実行時において、診断の結論となる情報が格納される。例えば、Ｃｏｎｃｌｕｓｉｏｎ１５４３に格納された情報が、出力デバイス２１７に表示されてもよい。例えば、診断実行時に、判定オブジェクト１５０３の判定結果によって結論オブジェクト１５０４ａが結論として選択された場合、診断結果として「ＳＷＰＯＲＴ１（ネットワークスイッチＤのポート０）の帯域不足」が出力デバイス２１７に表示される。

　＜展開収集手段リポジトリおよび展開収集手段＞

　展開収集手段は、メタ展開収集手段とトポロジ情報に基づいて診断手順展開プログラム２２３によって、展開される情報収集手段である。メタ収集手段には、情報収集の対象となる具体的なコンポーネントは定義されず、本実施例においては、変数で表現されていた。これに対し、展開収集手段はトポロジ情報に基づいて、情報収集の対象となるコンポーネントが定義される。

　図１６は、展開収集手段リポジトリ２３７に格納された展開収集手段の構成例を示す。

　展開収集手段１６００は、２つのフィールド、すなわち、展開手段ＩＤ１６０１および展開収集手段１６０２を有する。展開手段ＩＤ１６０１は、展開収集手段を一意に識別する識別子を格納する。展開手段ＩＤ１６０１に格納される値は、図１５の情報収集オブジェクト１５０２の展開手段ＩＤ１５２３に格納される識別子と等しい。展開収集手段１６０２は、診断に必要な情報収集手段を格納する。本実施例においては、診断に必要な情報の１つの例として、性能テーブル２３８から取得できる管理対象コンポーネントの性能情報を挙げている。そのため、例えば、展開収集手段１６０２ａは、テーブルから情報を取得するためのクエリを格納する。他の展開収集手段１６０２ｂ、１６０２ｃおよび１６０２ｄについても同様である。展開収集手段１６０２は、メタ収集手段１４０２と異なり、情報収集の対象を定義している。図１６は、図１４のメタ収集手段１４００を、図１３のトポロジ条件１３００ａに基づいて展開し生成された展開収集手段１６００ａ～１６００ｄの例を示す。

　＜障害解析プログラムの処理＞

　本実施例においては、イベントのパターンに基づいて障害原因解析を実行した後、その結果に基づいて、さらに詳細な障害原因イベントの特定を行うべく、診断を実行する。

　図１７は、障害解析プログラム２２１により実行される障害原因解析処理の例のフローチャートを示す。

　障害解析プログラム２２１は、ＩＴシステムにおいて障害が発生し、その障害に関するイベントをイベント受信プログラム２２７によって検知されるとこの処理を開始すべく構成されていてよい。また、ＩＴシステムにおける障害の発生を管理者が検知し、入力デバイス２１４から管理者の指示により起動されるとこの処理が開始されてもよい。

　ステップＳ１７０１において、障害解析プログラム２２１は、イベント分析プログラム２２２を実行する。イベント分析プログラム２２２は、発生したイベントのパターンに基づいて障害原因イベントを絞り込む処理を実行する。本実施例においては、イベント分析プログラム２２２は、イベントキューテーブル２３３に格納されたイベント情報群と、メタルールリポジトリ２３１に格納されたメタルールと、構成管理ＤＢ２３２に格納された構成情報とに基づいて、システム障害の伝播元となる障害の候補を絞り込む。例えば、図１０に示すイベントキューテーブル２３３のイベント情報群をイベント受信プログラム２２７が受信し、図１１Ａに示すメタルール１１００と図３～図８のテーブルに基づいてイベント分析プログラム２２２が分析を行った場合、展開ルール１１５０ａ、１１５０ｂ、１１５０ｃ、１１５０ｄが生成される。そして、例えば、展開ルール１１５０ａおよび１１５０ｂの各々のＴＨＥＮ部１１５２の情報に基づいて、イベント分析プログラム２２２が、「ネットワークスイッチＤ（ＩＤはＳｗＤ）のポート０（ＩＤはＳＷＰＯＲＴ１）の送信ドロップパケット数異常（イベント種別の識別子はＴｘＤｒｏｐＰａｃｋｅｔＮｕｍＥｒｒｏｒ）が障害の伝播元である」という結論を導出する。

　図１８に、イベント分析結果画面１８００の一例を示す。

　イベント分析結果画面１８００は、イベント分析プログラム２２２が導出した結論をＩＴシステムで発生した複数の障害の伝播元となる障害を原因候補として提示した画面である。イベント分析結果画面１８００は、伝播元となる障害原因候補毎にエントリを有し、各エントリが、障害原因候補を表示する原因障害候補フィールド１８０１と、フィールド１８０１が示す原因候補に対する確からしさ（確信度）を表示する確信度フィールド１８０２と、診断実行ボタン１８０３とを有してよい。確信度フィールド１８０２に表示される確信度は、例えば、原因候補１８１１に関連する展開ルール１１５０のイベント受信率であってよい。イベント受信率は、例えば、「イベント受信率＝（受信フラグ１１６４が「１」の条件要素数）／（条件要素の総数）」という式で算出されてよい。

　１つの原因候補１８１１に対して複数の展開ルールが存在する場合は、複数の展開ルールにそれぞれ対応した複数のイベント受信率に基づく値（例えば、イベント受信率の最大値、平均値、あるいは、最小値など）が確信度フィールド１８０２に表示されてよい。あるいは、原因候補１８１１に関連する全ての展開ルールの条件要素の総数と受信フラグ１１６４が「１」の条件要素数に基づいてイベント受信率が算出され、確信度フィールド１８０２に、算出された値が表示されてよい。また、原因候補は、イベント分析プログラム２２２の導出した結論に基づいて確信度の高い順に複数表示されてよい。

　管理者が所望の原因候補に対応した実行ボタン１８０３を押下すると、対応する原因候補の詳細診断を実行すべく、図１７のステップＳ１７０２に進み、診断手順展開プログラム２２３が起動する。管理者によって詳細診断を実行するための入力インタフェースは、ボタンに限定せず、診断実行を管理計算機２０１に指示するいずれの入力インタフェースも採用可能である。また、診断手順展開プログラム２２３の開始は、管理者の指示ではなく、イベント分析プログラム２２２によって原因候補が導出された後に、導出された各々の原因候補に対して自動で実行されてもよい。また、自動で診断手順展開プログラム２２３を実行する場合には、イベント分析プログラム２２２が導出した原因候補のうち、確信度が一定値以上のものに対してのみ、診断手順展開プログラム２２３が実行されてもよい。

　本実施例においては、イベント分析プログラム２２２が導出した結論は、ＩＴシステムで発生した複数の障害の伝播元となる障害を示しており、管理者が診断実行ボタン１８０３を押下し、それに応答して、伝播元となった障害の発生原因を特定する診断を実行すべく診断手順展開プログラム２２３が起動される。

　ステップＳ１７０２において、障害解析プログラム２２１は、ステップＳ１７０１で選択された原因候補の情報を入力として、診断手順展開プログラム２２３を起動する。診断手順展開プログラムは、入力された原因候補の情報、すなわち展開ルール１１５０のＴＨＥＮ部１１５２の情報と、展開ルール１１５０と、メタ診断手順１２００と、メタ収集手段１４００と、構成管理ＤＢ２３２に格納された構成情報に基づいて、展開診断手順１５００を生成する。診断手順展開プログラム２２３の詳細な処理の例については図１９に示す。

　ステップＳ１７０３において、障害解析プログラム２２１は、展開診断手順１５００を入力として、診断実行プログラム２２４を起動する。診断実行プログラム２２４は、展開診断手順１５００に基づいて、診断を実行しＩＴシステムの障害原因イベントを特定する。診断実行プログラム２２４の詳細な処理の例については図２０に示す。

　ステップＳ１７０４において、障害解析プログラム２２１は、ステップＳ１７０３で診断を実行した展開診断手順１５００を入力として、表示プログラム２２５を起動する。表示プログラム２２５は、入力された展開診断手順１５００とその経路リスト１５１５に基づき、ステップＳ１７０３で導出された障害の原因に関する情報を出力デバイス２１７に表示する。

　本実施例においては、イベント分析プログラム２２２を実行した後に、診断手順展開プログラム２２３を実行しているが、イベント分析プログラム２２２の実行前に、診断手順展開プログラム２２３が実行されてもよい。例えば、診断手順展開プログラム２２３が、構成管理ＤＢ２３２の構成情報とメタルール１１００に基づいて、イベント分析プログラム２２２が導出し得る原因候補を全て挙げ、そして、それらの原因候補を診断するのに必要な展開診断手順１５００と展開収集手段１６００を、メタ診断手順１２００とメタ収集手段１４００と構成管理ＤＢ２３２の構成情報に基づいて生成し、そして、それらを展開診断手順リポジトリ２３５及び展開収集手段リポジトリ２３７に格納してもよい。この場合、障害解析プログラム２２１は、イベント分析プログラム２２２を実行した後、イベント分析プログラム２２２によって導出された原因候補に対する展開診断手順１５００を展開診断手順リポジトリ２３５から取得し、取得した展開診断手順１５００を入力として診断実行プログラム２２４を起動する。

　また、本実施例においては、診断実行プログラム２２４が、診断に必要な情報を収集し、判定プログラム２２６が判定を実行する例を挙げているが、ステップＳ１７０２実行後に、生成した展開診断手順１５００を表示プログラム２２５に渡し、表示プログラム２２５が出力デバイス２１７に展開診断手順１５００を表示し、管理者が、その展開診断手順１５００の通りに処理を行ってよい。

　＜診断手順展開プログラムの処理＞

　図１９は、診断手順展開プログラム２２３により実行される処理の例のフローチャートを示す（ステップＳ１７０２）。

　ステップＳ１９０１において、診断手順展開プログラム２２３は、イベント分析プログラム２２２が障害の原因候補として導出した結論の情報を受信する。結論の情報は、展開ルール１１５０のＴＨＥＮ部１１５２に格納された情報の組合せであってよい。例えば、診断手順展開プログラム２２３は、「ネットワークスイッチＤ（ＩＤはＳｗＤ）のポート０（ＩＤはＳＷＰＯＲＴ１）の送信ドロップパケット数異常（イベント種別の識別子はＴｘＤｒｏｐＰａｃｋｅｔＮｕｍＥｒｒｏｒ）」という情報を受信する。

　ステップＳ１９０２において、診断手順展開プログラム２２３は、ステップＳ１９０１で受信した結論の情報に関連する展開ルール１１５０を取得する。すなわち、診断手順展開プログラム２２３は、受信した結論をＴＨＥＮ部１１５２に持つ展開ルール１１５０を取得する。診断手順展開プログラム２２３は、ステップＳ１９０２で取得した全ての展開ルール１１５０の各々について、ステップＳ１９０４乃至Ｓ１９１２の処理を行う。以下、１つの展開ルール（以下、図１９の説明において「対象展開ルール」）１１５０を例に取る。

　ステップＳ１９０４において、診断手順展開プログラム２２３は、対象展開ルール１１５０のフィールド１１５５に格納されているメタ診断手順ＩＤから識別されるメタ診断手順１２００をメタ診断手順リポジトリ２３４から取得する。診断手順展開プログラム２２３は、ステップＳ１９０４で取得した全てのメタ診断手順１２００の各々について、ステップＳ１９０６乃至Ｓ１９１２の処理を行う。以下、１つのメタ診断手順（以下、図１９の説明において「対象メタ診断手順」）１２００を例に取る。

　ステップＳ１９０６において、診断手順展開プログラム２２３は、対象メタ診断手順１２００が対象展開ルール１１５０のフィールド１１５５が示す起点に対して展開済みか否かを判定する。この判定の結果が真の場合（Ｓ１９０６：ＹＥＳ）、処理はステップＳ１９０７へ進み、この判定の結果が偽の場合（Ｓ１９０６：ＮＯ）、処理はステップＳ１９０８に進む。

　ステップＳ１９０７において、診断手順展開プログラム２２３は、対象展開ルール１１５０のフィールド１１５５が示す対象メタ診断手順と起点に基づいて展開した展開診断手順１５００を、展開診断手順リポジトリ２３５から取得する。

　ステップＳ１９０８において、診断手順展開プログラム２２３は、対象メタ診断手順１２００の基本オブジェクト１２０１のトポロジ条件ＩＤ１２１４に格納された識別子から識別されるトポロジ条件１３００を取得する。

　ステップＳ１９０９において、診断手順展開プログラム２２３は、ステップＳ１９０８で取得したトポロジ条件１３００の条件１３０２に格納された情報に基づき、構成管理ＤＢ２３２からトポロジ情報を取得する。取得するトポロジ情報が表すトポロジは、対象展開ルール１１５０のフィールド１１５５の中の「起点」が示す管理対象コンポーネント（装置あるいはその要素）を起点とする。例えば、対象展開ルール１１５０が図１１Ｂの展開ルール１１５０ａであった場合、起点は、装置ＩＤが「ＳｗＤ」およびコンポーネントＩＤが「ＳＷＰＯＲＴ１」の管理対象コンポーネントである。また、トポロジ条件１３００が図１３のトポロジ条件１３００ａであった場合、診断手順展開プログラム２２３は、スイッチポートテーブル６００の装置ＩＤ６０３が「ＳｗＤ」のレコード（１行目～４行目のレコード）を参照し、かつ、ネットワークＩ／Ｆテーブル５００のＩＤ５０１が、それらのレコードの接続先ポート６０４に格納された値と等しいレコード（２行目～４行目のレコード）を参照し、参照したレコードのＩＤの組合せ（ＳＷＰＯＲＴ１－ＳＷＰＯＲＴ２－ＳＶＩＦ１、ＳＷＰＯＲＴ１―ＳＷＰＯＲＴ３－ＳＶＩＦ２、ＳＷＰＯＲＴ１－ＳＷＰＯＲＴ４－ＳＶＩＦ３の３組）をトポロジ情報として取得する。

　また、トポロジ条件１３００を用いて取得できるトポロジ情報のうち、起点となる管理対象コンポーネント以外の管理対象コンポーネント（あるいは、それらが構成する装置）において障害のイベントが発生していないトポロジに関しては、ステップＳ１９０９で取得するトポロジ情報から除いてもよい。管理対象コンポーネントで障害のイベントが発生しているか否かは、イベント受信プログラム２２７が、分析を開始する契機となった障害イベントを、検知した時刻から一定期間内に障害に関するイベントが発生したかどうかで判定してよい。これにより、診断の対象を、障害が発生しているトポロジに限定することができる。また、展開診断手順１５００は、トポロジごとに生成されてもよいし、１組のトポロジ条件と起点に基づいて取得した全てのトポロジに対して１つ生成されてもよい。

　ステップＳ１９１０において、診断手順展開プログラム２２３は、メタ診断手順１２００の情報収集オブジェクト１２０２の手段ＩＤ１２２３に格納された識別子から識別されるメタ収集手段１４００をメタ収集手段リポジトリ２３６から取得する。そして、診断手順展開プログラム２２３は、ステップＳ１９０９で取得したトポロジ情報に基づいてメタ収集手段１４００を展開することにより展開収集手段１６００を生成する。メタ収集手段１４００中の変数にトポロジ情報中のＩＤが代入されることにより、展開収集手段１６００が生成される（展開収集手段１６０２が例えば図１６に示した通りとなる）。

　ステップＳ１９１１において、診断手順展開プログラム２２３は、メタ診断手順１２００とステップＳ１９０９で取得したトポロジ情報とステップＳ１９１０で生成した展開収集手段１６００に基づいて展開診断手順１５００を生成する。

　ステップＳ１９１２において、診断手順展開プログラム２２３は、ステップＳ１９１１で生成した展開診断手順１５００を展開診断手順リポジトリ２３５に登録する。

　ステップＳ１９１３において、診断手順展開プログラム２２３は、生成あるいは展開診断手順リポジトリ２３５から取得した展開診断手順１５００を呼び出し元プログラムに返す。

　なお、ステップＳ１９０４において、対象展開ルール１１５０のイベント受信率が一定値以下の場合には、対象展開ルールが、展開ルールに関連するメタ診断手順の展開及び診断実行の対象外とされてもよい。これにより、診断実行プログラム２２４が実行する展開診断手順を、イベント受信率が一定値以上の展開ルールに関連する展開診断手順に限定し、不要な診断の実行を削減することができる。

　図１９の処理の具体例は次の通りである。ステップＳ１９０１において、イベント分析プログラム２２２の結論として、「ネットワークスイッチＤ（ＩＤはＳｗＤ）のポート０（ＩＤはＳＷＰＯＲＴ１）の送信ドロップパケット数異常（イベント種別の識別子はＴｘＤｒｏｐＰａｃｋｅｔＮｕｍＥｒｒｏｒ）」という情報を受信した場合、診断手順展開プログラム２２３は、ステップＳ１９０２において、図１１Ｂの展開ルール１１５０ａと１１５０ｂを取得する。展開ルール１１５０ａを例に取ると、診断手順展開プログラム２２３は、ステップＳ１９０４において、図１２のメタ診断手順１２００を取得する。ステップＳ１９０６において、展開済みではないと判定された場合、診断手順展開プログラム２２３は、ステップＳ１９０８において、図１３のトポロジ条件１３００ａを取得する。ステップＳ１９０９において、診断手順展開プログラム２２３は、３つのトポロジ情報（ＳＷＰＯＲＴ１－ＳＷＰＯＲＴ２－ＳＶＩＦ１、ＳＷＰＯＲＴ１―ＳＷＰＯＲＴ３－ＳＶＩＦ２、ＳＷＰＯＲＴ１－ＳＷＰＯＲＴ４－ＳＶＩＦ３）を取得する。メタ診断手順１２００の２つの情報収集オブジェクト１２０２の手段ＩＤ１２２３には、それぞれ「ＧｅｔＩｎｆｏ１」と「ＧｅｔＩｎｆｏ２」が格納されているため、ステップＳ１９１０において、診断手順展開プログラム２２３は、図１４のメタ収集手段１４００ａとトポロジ情報に基づいて展開収集手段１６００ａを生成し、メタ収集手段１４００ｂとトポロジ情報に基づいて展開収集手段１６００ｂ、１６００ｃおよび１６００ｄを生成する。ステップＳ１９１１において、診断手順展開プログラム２２３は、メタ診断手順１２００と取得したトポロジ情報から図１５に示す展開診断手順１５００を生成する。そして、ステップＳ１９１２において、診断手順展開プログラム２２３は、展開診断手順１５００を展開診断手順リポジトリ２３５に格納し、ステップＳ１９１３において、診断手順展開プログラム２２３は、生成した展開診断手順１５００を障害解析プログラム２２１に返す。

　＜診断実行プログラムの処理＞

　図２０は、診断手順展開プログラム２２３により実行される処理の例のフローチャートを示す（ステップＳ１７０３）。

　ステップＳ２００１において、診断実行プログラム２２４は、展開診断手順１５００を受信する。診断実行プログラム２２４は、ステップＳ２００１において受信した全ての展開診断手順に対して、ステップＳ２００３乃至Ｓ２０１４の処理を繰り返す。以下、１つの展開診断手順（以下、図２０の説明において「対象展開診断手順」）を例に取る。

　ステップＳ２００３において、診断実行プログラム２２４は、対象展開診断手順１５００を構成するオブジェクトのうち、タイプが「Ｓｔａｒｔ」である基本オブジェクト１５０１を参照する。

　ステップＳ２００４において、診断実行プログラム２２４は、基本オブジェクト１５０１の経路リスト１５１５に、参照しているオブジェクトのＩＤを追加する。

　ステップＳ２００５において、診断実行プログラム２２４は、参照しているオブジェクトの次のオブジェクトを参照する。参照しているオブジェクトが基本オブジェクト１５０１、あるいは、情報収集オブジェクト１５０２である場合には、診断実行プログラム２２４は、ＮｅｘｔＩＤ１５１６あるいはＮｅｘｔＩＤ１５２４に格納されたＩＤを持つオブジェクトを参照する。判定オブジェクト１５０３を参照している場合は、後述のステップＳ２０１３において、診断実行プログラム２２４は、Ｄｅｃｉｓｉｏｎ　Ｍａｐ１５３５に基づいて次のオブジェクトを決定する。

　ステップＳ２００６において、診断実行プログラム２２４は、ステップＳ２００５において参照したオブジェクトのタイプが「Ｅｎｄ」か否かを判定する。この判定結果が真の場合（Ｓ２００６：ＹＥＳ）、処理はステップＳ２００７へ進み、この判定結果が偽の場合（Ｓ２００６：ＮＯ）、処理はステップＳ２０１４へ進む。

　ステップＳ２００７において、診断実行プログラム２２４は、ステップＳ２００５で参照したオブジェクトのタイプが「ＣｏｌｌｅｃｔＩｎｆｏ」か否かを判定する。この判定の結果が真の場合（Ｓ２００７：ＹＥＳ）、処理はステップＳ２００８へ進み、この判定の結果が偽の場合（Ｓ２００７：ＮＯ）、処理はステップＳ２０１０へ進む。

　ステップＳ２００８において、診断実行プログラム２２４は、参照しているオブジェクトの展開手段ＩＤ１５２３に格納された識別子から識別される展開収集手段１６００を展開収集手段リポジトリ２３７から取得する。

　ステップＳ２００９において、診断実行プログラム２２４は、ステップＳ２００８で取得した展開収集手段に基づいて、管理対象装置や管理計算機２０１が持つリポジトリから情報を取得する。

　ステップＳ２０１０において、診断実行プログラム２２４は、参照しているオブジェクトの引数１５３４に格納された情報に基づいてステップＳ２００９で収集した情報を取得する。

　ステップＳ２０１１において、診断実行プログラム２２４は、ステップＳ２０１０で取得した情報を入力とし、参照しているオブジェクトの判定プログラムＩＤ１５３３に格納された識別子から識別される判定プログラム２２６を起動する。

　ステップＳ２０１２において、診断実行プログラム２２４は、ステップＳ２０１１で実行した判定プログラム２２６から判定結果を受信する。

　ステップＳ２０１３において、診断実行プログラム２２４は、ステップＳ２０１２で受信した判定結果をキーとして、参照しているオブジェクトのＤｅｃｉｓｉｏｎ　Ｍａｐ１５３５に格納されたＮｅｘｔＩＤ１５３７を取得し、次に参照するオブジェクトを決定する。

　ステップＳ２０１４において、診断実行プログラム２２４は、基本オブジェクト１５０１の経路リスト１５１５に、参照しているオブジェクトのＩＤを追加する。

　ステップＳ２０１５において、診断実行プログラム２２４は、受信した展開診断手順１５００を呼び出し元プログラムに返す。

　図２０の処理の具体例は次の通りである。例えば、ステップＳ２００１において、図１５に示す展開診断手順１５００を受信した場合、診断実行プログラム２２４は、ステップＳ２００３において、基本オブジェクト１５０１ａを参照し、ステップＳ２００４において、経路リスト１５１５にオブジェクトのＩＤ「Ｐｒｏｃ１－１－０」を追加する。次に、ステップＳ２００５において、診断実行プログラム２２４は、ＮｅｘｔＩＤ１５１６が示す識別子「Ｐｒｏｃ１－１－１」に基づいて情報収集オブジェクト１５０２を参照する。情報収集オブジェクト１５０２ａはタイプが「ＣｏｌｌｅｃｔＩｎｆｏ」であるため、処理がステップＳ２００８に進む。ステップＳ２００８において、診断実行プログラム２２４は、展開手段ＩＤ「ＥｘｐａｎｄｅｄＧｅｔＩｎｆｏ１－１」に基づいて、図１６の展開情報手段１６００ａを取得する。そして、診断実行プログラム２２４は、展開収集手段１６０２に記述されたＳＱＬクエリに基づいて性能テーブル２３８から情報を収集する。そして、ステップＳ２００４に戻り、診断実行プログラム２２４は、経路リスト１５１５にオブジェクトのＩＤ「Ｐｒｏｃ１－１－１」を追加する。次に、ステップＳ２００５で参照するオブジェクトは判定オブジェクト１５０３ａとなるため、処理はステップＳ２０１０に進む。ステップＳ２０１０において、診断実行プログラム２２４は、展開情報手段１６００ａに基づいて取得した性能情報を取得し、ステップＳ２０１１において、診断実行プログラム２２４は、その性能情報を入力として「判定プログラム１」を起動する。ステップＳ２０１２において、「判定プログラム１」から「ＮＯ」という値を受信した場合には、診断実行プログラム２２４は、Ｄｅｃｉｓｉｏｎ　Ｍａｐ１５３５に基づいて次に参照するオブジェクトはＩＤ「Ｐｒｏｃ１－１－４」を持つ結論オブジェクト１５０４ａと決定する。再び、ステップＳ２００４に戻り、診断実行プログラム２２４は、経路リスト１５１５にオブジェクトのＩＤ「Ｐｒｏｃ１－１－３」を追加し、ステップＳ２００５で結論オブジェクト１５０４ａを参照する。結論オブジェクト１５０４ａはタイプが「Ｅｎｄ」であるため、処理がステップＳ２０１４に進み、診断実行プログラム２２４は、経路リスト１５１５にオブジェクトのＩＤ「Ｐｒｏｃ１－１－４」を追加する。そして、診断実行プログラム２２４は、経路リスト１５１５が更新された展開診断手順１５００を、呼び出し元である障害解析プログラム２２１に返す。

　以上の処理により、診断手順展開プログラム２２３によって生成された展開診断手順に基づいて、診断実行プログラム２２４はＩＴシステムで発生した障害の原因イベントを特定すべく、診断を実行することができる。

　なお、診断実行プログラム２２４は、ステップＳ２００９において、収集した情報を出力デバイス２１７に表示し、ステップＳ２０１１において実行される判定プログラム２２６は、出力デバイス２１７に、判定基準と管理者が判定結果を入力する入力インタフェース（例えばボタン）を表示し、ステップＳ２０１２において受信する判定結果は、管理者が入力インタフェースを介して入力した判定結果であってもよい。

　また、診断実行プログラム２２４は、ステップＳ２０１０において、判定に使用する情報を取得できなかった場合、ステップＳ２０１１において、判定プログラム２２６は、複数の判定結果を返し、診断実行プログラム２２４は、複数の判定結果の各々について診断手順を続行し、複数の結論オブジェクト１５０４を参照し、表示プログラム２２５は、それら複数の結論オブジェクト１５０４に基づいて複数の原因イベントを表示してもよい。

　また、診断実行プログラム２２４は、情報収集オブジェクト１５０２に基づいた情報収集処理、および、判定オブジェクト１５０３に基づいた判定プログラム２２６の判定は、展開診断手順のオブジェクトの順に実行せず、並列に実行されてもよい。

　＜表示プログラムの処理＞

　図２１は、表示プログラム２２５により実行される処理の例のフローチャートを示す（ステップＳ１７０４）。

　ステップＳ２１０１において、表示プログラム２２５は、展開診断手順１５００を受信する。

　ステップＳ２１０２において、表示プログラム２２５は、受信した展開診断手順１５００と、基本オブジェクト１５０１の経路リスト１５１５に格納されたリストに基づいて、診断実行プログラム２２４が最終的に参照した結論オブジェクト１５０４を取得し、診断結果として表示する。

　ステップＳ２１０３において、表示プログラム２２５は、受信した展開診断手順に基づいて、使用した診断手順を表示する。

　ステップＳ２１０４において、表示プログラム２２５は、受信した展開診断手順１５００の基本オブジェクト１５０１の経路リスト１５１５に基づいて、診断実行プログラム２２４が使用した診断手順のうち、実行した手順を表示する。

　なお、ステップ２１０１～Ｓ２１０４によれば、情報が順次表示されるが、それに代えて、表示プログラム２２５は、表示対象の情報をメモリ２１２に書き込みし、全ての表示対象がメモリ２１２に書き込まれた場合に、それらの表示対象を含んだ画面（例えば図２２の画面）を表示してもよい。

　図２２は、診断結果画面の一例を示す。

　診断結果画面２２００は、診断実行プログラム２２４が実行した診断手順とその診断結果を表示する画面であり、出力デバイス２１７に表示される。この画面２２００は、具体的には、図１５の展開診断手順とその手順を実行した結果を示す。診断結果画面２２００は、診断実行プログラム２２４によって導出された診断結果を表示する診断結果フィールド２２０１と、診断実行プログラム２２４で使用した展開診断手順１５００の情報を表示する診断手順フィールド２２０２で構成されていてよい。また、診断結果画面２２００は、診断を実行したトポロジの情報を表示する診断対象トポロジフィールド２２０３と、診断実行時に収集し、判定に使用した情報を表示する診断対象データフィールド２２０４を有していてもよい。

　診断結果フィールド２２０１に表示されている情報は、ステップＳ２１０２において表示プログラム２２５により表示された情報（診断結果）の一例である。受信した展開診断手順１５００の経路リスト１５１５に基づいて、診断実行プログラム２２４が最終的に参照した結論オブジェクト１５０４が取得されるが、フィールド２２０１には、その結論オブジェクト１５０４が、診断結果として表示されている。

　診断手順フィールド２２０２に表示されている情報は、ステップＳ２１０３において表示プログラム２２５により表示された情報（診断手順）の一例である。受信した展開診断手順１５００の情報に基づき、診断実行プログラム２２４が使用した診断手順が取得されるが、フィールド２２０２には、その診断手順が表示されている。図２２では、診断手順の表示の一例として、判定オブジェクト１５０３の引数１５３４が示す値と、判定オブジェクト１５０３から識別された判定プログラム２２６による判定基準と、結論オブジェクト１５０４が導出する結論の情報とが表示されている。図２２の経路２２２３は、ステップＳ２１０４で、表示プログラム２２５が経路リスト１５１５に基づいて表示する「実行した手順」の一例である。図２２に示すように、診断手順２２２１対して、「実行した手順」の流れを示す部分（矢印）が強調表示されてもよいし、実行した手順の一覧が表示されてもよい。

　診断対象トポロジフィールド２２０３に表示されている情報は、展開診断手順１５００の対象となったトポロジを表す情報である。診断手順展開プログラム２２３が図１９の処理においてトポロジ情報を展開診断手順１５００と関連させて管理計算機２０１のメモリ２１２等の記憶領域に保存し、表示プログラム２２５の起動時に、表示プログラム２２５が、その保存されている情報をフィールド２２０３に表示してもよい。

　診断対象データフィールド２２０４には、診断実行プログラム２２４が展開診断手順１５００の情報収集オブジェクト１５０２を参照した際に取得した情報が表示されている。診断実行プログラム２２４が図２０の処理においてステップＳ２００９で取得した情報を展開診断手順１５００と関連させて管理計算機２０１のメモリ２１２等の記憶領域に保存し、表示プログラム２２５の起動時に、表示プログラム２２５が、その保存されている情報をフィールド２２０４に表示してもよい。

　また、診断対象トポロジフィールド２２０３において、判定の手順毎に、判定の対象となった管理対象コンポーネントに関する情報が表示されてもよい。例えば、図２２の表示例において、管理者が、判定オブジェクト１５０３の判定基準を表示した判定表示２２２２を選択すると、判定オブジェクト１５０３に関連する判定プログラム２２６が判定対象とした管理対象コンポーネントの情報が強調表示されてもよい。例えば、管理者が、判定オブジェクト１５０３ａの判定基準を表示した判定表示２２２２ａを選択した場合、判定オブジェクト１５０３ａの引数１５３４が示す情報は「Ｐｒｏｃ１－１－１の戻り値」であり、手順「Ｐｒｏｃ１－１－１」が収集する情報は「ネットワークスイッチＤのポート０（識別子はＳＷＰＯＲＴ１）」の性能情報であるため、「ネットワークスイッチＤのポート０」が強調表示されてもよい。

　また、診断対象トポロジフィールド２２０３において、判定の手順毎に、判定結果を決定する要素となった管理対象コンポーネントに関する情報が表示されてもよい。例えば、図２２の表示例において、管理者が、展開診断手順１５００の判定オブジェクト１５０３の判定基準を表示した判定表示２２２２を選択すると、診断対象トポロジフィールド２２０３に表示された管理対象コンポーネントのうち、判定結果を決定する要素となった管理対象コンポーネントの情報が強調表示されてもよい。例えば、判定表示２２２２ｂに関連する判定オブジェクト１５０３ｂは、「ネットワークスイッチＤのポート０の送信ドロップパケット数の上昇率とサーバＡのｅｔｈ０、サーバＢのｅｔｈ０、サーバＣのｅｔｈ０の送信パケット数の上昇率をそれぞれ比較する。そして、１つでもネットワークＤのポート０の送信ドロップパケット数と上昇率の等しいサーバが存在した場合には、結論表示２２２３ａに関連する結論オブジェクト１５０４ｃを参照し、そうでなければ結論オブジェクト１５０４ｂを参照する」という判定情報を持つ展開診断手順１５００のオブジェクトである。そして、サーバＢのみがネットワークスイッチＤのポート０の送信ドロップパケット数の上昇率と等しかった場合、診断実行プログラム２２４は結論オブジェクト１５０４ｃを参照する。この場合、結論オブジェクト１５０４ｃを参照する要因となった「サーバＢのｅｔｈ０（識別子はＳＶＩＦ２）」と比較対象となった「ネットワークスイッチＤのポート０（識別子はＳＷＰＯＲＴ１）」が強調表示されてもよい。診断実行プログラム２２４の実行時にステップＳ２０１０で取得した情報とステップＳ２０１２の判定結果を管理計算機２０１のメモリ２１２等の記憶領域に保存することで、これらの情報が表示されてもよい。判定オブジェクト１５０３ｂを例に取ると、判定プログラムＩＤ１５３３が示す「判定プログラム２」が、呼び出されて判定を行っており、「判定プログラム２」が、性能情報の上昇率が等しいコンポーネントのＩＤの組を返すプログラムであった場合、「判定プログラム２」の戻り値を管理計算機２０１のメモリ２１２等の記憶領域に保存し、表示プログラム２２５が、それらのＩＤを持つ管理対象コンポーネントの情報を表示してもよい。

　また、診断対象データフィールド２２０４において、判定の手順毎に、判定の対象となった情報が表示されてもよい。例えば、図２２の表示例において、管理者が、判定オブジェクト１５０３の判定基準を表示した判定表示２２２２を選択すると、判定オブジェクト１５０３の引数１５３４が示す情報が強調表示されてもよい。例えば、管理者が、判定オブジェクト１５０３ａの判定基準を表示した判定表示２２２２ａを選択した場合、判定オブジェクト１５０３ａの引数１５３４が示す情報２２４１ｂが強調表示されてもよい。

　また、診断対象データフィールド２２０４において、判定の手順毎に、判定結果を決定する要素となった情報が表示されてもよい。例えば、図２２の表示例において、管理者が、展開診断手順１５００の判定オブジェクト１５０３の判定基準を表示した判定表示２２２２を選択すると、診断対象データフィールド２２０４に表示された情報のうち、判定結果を決定する要素となった情報が強調表示されてもよい。例えば、判定表示２２２２ｂに関連する判定オブジェクト１５０３ｂは、「ネットワークスイッチＤのポート０の送信ドロップパケット数の上昇率とサーバＡのｅｔｈ０、サーバＢのｅｔｈ０、サーバＣのｅｔｈ０の送信パケット数の上昇率をそれぞれ比較する。そして、１つでもネットワークＤのポート０の送信ドロップパケット数と上昇率の等しいサーバが存在した場合には、結論表示２２２３ａに関連する結論オブジェクト１５０４ｃを参照し、そうでなければ結論オブジェクト１５０４ｂを参照する」という判定情報を持つ展開診断手順１５００のオブジェクトである。そして、サーバＢのみがネットワークスイッチＤのポート０の送信ドロップパケット数の上昇率と等しかった場合、診断実行プログラム２２４は、結論オブジェクト１５０４ｃを参照する。この場合、結論オブジェクト１５０４ｃを参照する要因となった「サーバＢのｅｔｈ０（識別子はＳＶＩＦ２）の送信パケット数の性能情報」と比較対象となった「ネットワークスイッチＤのポート０（識別子はＳＷＰＯＲＴ１）の送信ドロップパケット数の性能情報」が、強調表示されてもよい。診断実行プログラム２２４の実行時にステップＳ２０１０で取得した情報とステップＳ２０１２の判定結果を管理計算機２０１のメモリ２１２等の記憶領域に保存することで、これらの情報が表示されてもよい。

　また、イベント分析プログラム２２２の導出した１つの原因候補に対して複数の展開診断手順が実行された場合には、展開診断手順毎に診断結果の画面が表示されてもよい。

　また、診断実行プログラム２２４は、ステップＳ２００９で収集した情報を一定期間、管理計算機２０１のメモリ２１２等の記憶領域に保存しておき、別の診断実行時に同じ管理対象コンポーネントに対して同じ情報を収集するステップを実行する際には、メモリ２１２等の記憶領域に既に保存されている情報を使用してもよい。収集した情報を出力デバイス２１７に表示する際には、収集した時刻が表示されてもよい。

　また、診断実行プログラム２２４は、ステップＳ２０１２で受信した判定結果を管理計算機２０１のメモリ２１２等の記憶領域に一定期間保存しておき、別の診断実行時に、同じ管理対象コンポーネントの同じ情報に基づいて判定を行う際には判定プログラムを実行せず、保存されている判定結果が使用されてもよい。判定結果を出力デバイス２１７に表示する際には、判定した時刻が表示されてもよい。

　以上に説明したように、実施例１によれば、イベント分析プログラム２２２によって導出された原因障害候補に対して関連する診断を実行し、診断においては、診断に必要な情報収集を実行し、収集した情報に対して判定を行い、その結果得られた結論によって障害の原因イベントを特定することができる。これにより、管理者は、障害の原因イベントを迅速に特定することができ、ＩＴシステムの障害によるダウンタイムを短縮することができる。

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

　実施例１では、イベント分析プログラムによって導出された複数障害の伝播元となる障害に対して、診断を実行し、診断によって得られた結論を伝播元となる障害の発生原因として提示する。実施例１に例示される方法は、イベント分析プログラムによってわかる範囲で原因を特定した後、さらに詳細な原因を調査するのに有効である。一方、診断の有効な利用方法としては、他に、イベント分析プログラムによって導出される原因候補の確信度の精度を向上する（例えば確信度の値を高める）ことが挙げられる。

　実施例２では、イベント分析プログラムによって原因候補を導出後、診断を実行し、診断結果を、イベント分析機能によって導出された原因候補の確信度に反映させる例について説明する。

　図２３は、実施例２におけるメタルール２３００の構成例を示す。

　実施例２におけるメタルール２３００の構成は、実施例１におけるメタルール１１００の構成と実質的に同じである。実施例１のメタルール１１００は、ＩＦ部１１１１を構成する条件要素１１２１は、イベント受信プログラム２２７が受信するイベントの種別を格納すべく、装置種別１１０１、コンポーネント種別１１０２、イベント種別１１０３で構成されている。これに対し、実施例２におけるメタルール２３００は、診断の結果を反映すべく、ＩＦ部１１１１の条件要素として、メタ診断手順１２００の識別子を格納するフィールド２３１１を有してよい。

　図２４は、実施例２における展開ルール２４００の構成例を示す。

　実施例２における展開ルール２４００の構成は、実施例１における展開ルール１１５０の構成と実質的に同じである。メタルールと同様に、実施例１の展開ルール１１５０は、ＩＦ部１１５１について、条件要素は、イベント受信プログラム２２７が受信し得るイベントを格納すべく、装置ＩＤ１１６１、コンポーネントＩＤ１１６２およびイベント種別１１６３で構成されている。これに対し、実施例２における展開ルール２４００には、診断の結果を反映すべく、ＩＦ部１１５１の条件要素として、展開診断手順の識別子を格納するフィールド２４１１を有してよい。

　図２５は、実施例２における展開診断手順の構成例を示す。

　実施例２における展開診断手順２５００の構成は、実施例１における展開診断手順１５００の構成と実質的に同じである。展開診断手順２５００は、診断の結果を反映すべく、結論オブジェクト１５０４のＣｏｎｃｌｕｓｉｏｎ１５４３に、展開ルール２４００の展開診断手順の識別子が格納されたフィールド２４１１に対応する受信フラグ１１６４を更新する指示が格納されてよい。

　図２６は、実施例２において障害解析プログラム２２１により実行される障害原因解析処理の例のフローチャートを示す。障害解析プログラム２２１の開始のタイミングは実施例１に記載のタイミングでよい。

　ステップＳ１７０１において、障害解析プログラム２２１は、イベント分析プログラム２２２を実行する。実行される処理は、実施例１において説明したステップＳ１７０１の処理と同じである。

　ステップＳ１７０２において、障害解析プログラム２２１は、ステップＳ１７０１で選択された原因候補の情報を入力として、診断手順展開プログラム２２３を起動する。実行される処理は、実施例１において説明したステップＳ１７０２、あるいは図１９の処理と実質的に同じである。ただし、診断手順展開プログラム２２３は、ステップＳ１９０９で展開診断手順２５００を生成した後、ステップS１９０２で取得した展開ルール２４００と、その展開ルール２４００のベースとなったメタルール２３００を取得する。そして、生成した展開診断手順２５００が、メタルール２３００の条件要素フィールド２３１１に格納されたメタ診断手順の識別子と同じメタ診断手順ＩＤを持つ場合、診断手順展開プログラム２２３は、展開診断手順ＩＤを、メタルール２３００に関連する展開ルール２４００の条件要素のフィールド２４１１に格納する。

　なお、展開診断手順が、展開ルールのＩＦ部のコンポーネントＩＤの値を起点としたトポロジ情報に基づいて生成された場合は、診断手順展開プログラム２２３は、起点となったコンポーネントのＩＤを持つ展開ルールに限定して、展開診断手順ＩＤを条件要素のフィールド２４１１に格納してもよい。また、診断手順展開プログラム２２３は、展開診断手順を生成する際に取得したトポロジ情報と展開ルールを生成するときに取得したトポロジ情報が等しい場合に限定して、展開ルールのフィールド２４１１に、展開診断手順ＩＤを格納してもよい。

　ステップＳ１７０３において、障害解析プログラム２２１は、展開診断手順を入力として、診断実行プログラム２２４を起動する。実行される処理は、実施例１において説明したステップＳ１７０３の処理と同じである。

　ステップＳ２６０１において、障害解析プログラム２２１は、診断実行プログラム２２４から展開診断手順を受信し、展開診断手順の経路リスト１５１５に基づいて、診断実行プログラム２２４によって参照された展開診断手順２４００の結論オブジェクト１５０４を参照する。

　ステップＳ２６０２において、障害解析プログラム２２１は、診断実行プログラム２２４から受信した展開診断手順２４００の展開診断手順ＩＤを条件要素に持つ展開ルールを探索する。そして、ステップＳ２６０１で参照した結論オブジェクト１５０４のＣｏｎｃｌｕｓｉｏｎ１５４３に格納された指示のとおりに、展開ルール２４００の条件要素２４１１の受信フラグ１１６４を更新する。

　例えば、診断実行プログラム２２４から受信した展開診断手順が図２５の展開診断手順２５００で、ステップＳ２０６１で結論オブジェクト１５０４ｄを参照した場合には、障害解析プログラム２２１は、条件要素に展開診断手順２５００のＩＤである「ＥｘｐａｎｄｅｄＤｅａｇｎｏｓｔｉｃＰｒｏｃ１０－１」を持つ展開ルール２４００の条件要素のフィールド２４１１に対応した受信フラグ１１６４を「１」に更新する。

　ステップＳ２６０３において、障害解析プログラム２２１は、各展開ルールのイベント受信率を算出する。実施例１で述べたとおり、イベント受信率の計算式は、「イベント受信率＝（受信フラグ１１６４が「１」の条件要素数）／（条件要素の総数）」でよい。

　ステップＳ２６０４において、障害解析プログラム２２１は、表示プログラム２２５を起動する。表示プログラム２２５は、ステップＳ２６０３で算出したイベント受信率に基づいて、イベント分析結果画面１８００において、ステップＳ１７０１で選択された原因候補の確信度を更新する。

　以上に説明したように、実施例２によれば、イベント分析プログラムによって導出された原因候補に対して関連する診断を実行し、その結果得られた結論によって原因候補の確信度を更新することで、より確からしい障害原因候補を優先して管理者に提示することができる。これにより、管理者は障害原因を迅速に特定することができる。

　以上、幾つかの実施例を説明したが、本発明はそれらの実施例に限定されない。例えば、メタルール１１００が、そのメタルール１１００に関連付けられているメタ診断手順１２００のメタ診断手順ＩＤ及び起点を含むことに代えて又は加えて、メタ診断手順１２００が、そのメタ診断手順１２００に関連付けられているメタルール１１００のメタルールＩＤと起点を含んでもよい。いずれの構成であっても、メタルール１００とメタ診断手順１２００とを多対多で関連付けることができる。

　２０１：管理計算機

Claims

　複数の管理対象コンポーネントのうちの１以上の管理対象コンポーネントで発生した１以上のイベントである１以上の発生イベントの原因解析を行う管理システムであって、
　記憶デバイスと、
　前記記憶デバイスに接続されたプロセッサと
を有し、
　前記記憶デバイスが、構成管理情報と、複数のルールと、複数の汎用診断手順とを記憶し、
　前記構成管理情報は、前記複数の管理対象コンポーネントの構成に関する情報であり、
　前記複数のルールの各々は、１以上の条件イベントと前記１以上の条件イベントが発生した場合に原因となる結論イベントとの関連付けを示すルールであり、
　前記複数の汎用診断手順の各々は、前記複数のルールのいずれかに関連付けられており１又は複数のコンポーネント種別を用いて定義され管理対象コンポーネントに依存しない汎用の診断手順であり、
　前記プロセッサが、
　　前記複数のルールのうちの、前記１以上の発生イベントに関連する１以上の条件イベントが関連付けられている１以上のルールである１以上の対象ルールを基に、１以上の原因候補を特定し、
　　前記複数の汎用診断手順のうちの、前記１以上の原因候補のうちの選択された原因候補の基になる対象ルールに関連付けられている汎用診断手順を特定し、前記特定された汎用診断手順と前記構成管理情報とに基づいて、１以上の管理対象コンポーネントに対して実行する診断手順であり前記選択された原因候補のより具体的な原因を特定する又は前記選択された原因候補の確からしさを更新するための展開診断手順を生成する、
管理システム。
　前記プロセッサが、前記生成した展開診断手順を表す情報を表示する、
請求項１記載の管理システム。
　前記プロセッサが、前記特定された汎用診断手順と、前記構成管理情報を基に特定されるトポロジであり前記１以上の対象ルールの中の１以上の条件イベントの対象となる管理対象コンポーネントまたは前記１以上の対象ルール中の１以上の結論イベントの対象となる管理対象コンポーネントを起点としたトポロジに対して前記展開診断手段を生成する、
請求項１記載の管理システム。
　前記プロセッサが、前記特定された汎用診断手順と前記構成管理情報とに加えて、前記１以上の発生イベントの情報を基に、前記展開診断手順を生成する、
請求項１記載の管理システム。
　前記複数の汎用診断手順の各々が、１以上の情報収集定義と、１以上の判定定義と、複数の結論定義との組合せであり、
　前記１以上の情報収集定義の各々は、情報収集と情報収集元のコンポーネント種別とを表し、
　前記１以上の判定定義の各々は、収集した情報に基づいて判定することを表し、判定の結果として少なくとも１つの結論定義と少なくとも１つの情報収集定義とのうちの少なくとも一方に対応し、
　前記１以上の結論定義の各々は、結論を表し、
　少なくとも１つの判定定義が、少なくとも１つの結論定義に関連付けられている、
請求項１記載の管理システム。
　前記展開診断手順は、前記特定された汎用診断手順におけるコンポーネント種別に対しそのコンポーネント種別に該当する管理対象コンポーネントが前記構成管理情報を基に関連付けられることにより生成され、
　前記プロセッサが、前記展開診断手順を基に結論を決定し、決定した結論を表示する、
請求項５記載の管理システム。
　前記プロセッサは、前記選択された原因候補の基になる対象ルールに関連付けられている１以上の条件イベントのうち発生イベントに適合する条件イベントの割合が一定値以上の場合にのみ、前記選択された原因候補の基になる対象ルールに関連付けられている汎用診断手順を、展開診断手順の生成のための基とする、
請求項１記載の管理システム。
　前記プロセッサが、実行した定義及び収集した情報のうちの少なくとも一方を表示する、
請求項６記載の管理システム。
　前記プロセッサが、前記選択された原因候補の基になる対象ルールと前記１以上の発生イベントとを基に、前記１以上の原因候補の各々の確信度を算出し、
　前記プロセッサが、算出された１以上の確信度に基づいて、前記１以上の原因候補の中から診断対象とする原因候補を選択する、
請求項１記載の管理システム。
　前記プロセッサが、前記選択された原因候補の基になる対象ルールと前記１以上の発生イベントとを基に、前記１以上の原因候補の各々の確信度を算出し、
　前記複数の結論定義のうちの一部の結論定義が、算出された確信度を更新することを表しており、
　前記プロセッサが、前記展開診断手順を基に結論を決定し、決定した結論が確信度の更新であれば、前記選択された原因候補の確信度を更新する、
請求項５記載の管理システム。
　前記プロセッサが、前記展開診断手順を表示し、その後に、前記展開診断手順が表す判定についての結果を表す情報の入力を受け付け、受け付けた情報が表す判定結果に基づいて、実行する定義を決定する、
請求項５記載の管理システム。
　前記プロセッサが、前記展開診断手順を表示し、その後に、前記展開診断手順に基づき収集した情報のうち、判定結果を満たす情報を表示する、
請求項５記載の管理システム。
　前記プロセッサが、前記展開診断手順の実行において収集した情報と収集時刻、及び、前記展開診断手順の実行における判定結果と判定時刻、のうちの少なくとも一方を前記記憶デバイスに書き込み、別の展開診断手順の実行において、前記記憶デバイスに書き込まれている情報又は判定結果と同じ管理対象コンポーネントについての情報収集又は判定であり、且つ、前記記憶デバイスに書き込まれている収集時刻又は判定時刻から一定時間経過していなければ、前記記憶デバイスに記憶されている情報又は判定結果を前記別の展開診断手順における収集情報又は判定結果として扱う、
請求項５記載の管理システム。
　複数の管理対象コンポーネントのうちの１以上の管理対象コンポーネントで発生した１以上のイベントである１以上の発生イベントの原因解析を支援する方法であって、
　それぞれが１以上の条件イベントと前記１以上の条件イベントが発生した場合に原因となる結論イベントとの関連付けを示す複数のルールのうちの、前記１以上の発生イベントに関連する１以上の条件イベントが関連付けられている１以上のルールである１以上の対象ルールを基に、１以上の原因候補を特定し、
　それぞれが前記複数のルールのいずれかに関連付けられており１又は複数のコンポーネント種別を用いて定義され管理対象コンポーネントに依存しない汎用の診断手順である複数の汎用診断手順のうちの、前記１以上の原因候補のうちの選択された原因候補の基になる対象ルールに関連付けられている汎用診断手順を特定し、
　前記特定された汎用診断手順と、前記複数の管理対象コンポーネントの構成に関する情報である構成管理情報とに基づいて、１以上の管理対象コンポーネントに対して実行する診断手順であり前記選択された原因候補のより具体的な原因を特定する又は前記選択された原因候補の確からしさを更新するための展開診断手順を生成する、
方法。
　それぞれが１以上の条件イベントと前記１以上の条件イベントが発生した場合に原因となる結論イベントとの関連付けを示す複数のルールのうちの、前記１以上の発生イベントに関連する１以上の条件イベントが関連付けられている１以上のルールである１以上の対象ルールを基に、１以上の原因候補を特定し、
　それぞれが前記複数のルールのいずれかに関連付けられており１又は複数のコンポーネント種別を用いて定義され管理対象コンポーネントに依存しない汎用の診断手順である複数の汎用診断手順のうちの、前記１以上の原因候補のうちの選択された原因候補の基になる対象ルールに関連付けられている汎用診断手順を特定し、
　前記特定された汎用診断手順と、複数の管理対象コンポーネントの構成に関する情報である構成管理情報とに基づいて、１以上の管理対象コンポーネントに対して実行する診断手順であり前記選択された原因候補のより具体的な原因を特定する又は前記選択された原因候補の確からしさを更新するための展開診断手順を生成する、
ことをコンピュータに実行させるためのコンピュータプログラム。