JPWO2011007394A1 - 障害の根本原因に対応した復旧方法を表す情報を出力する管理システム - Google Patents

Abstract

管理サーバは、複数のノード装置で発生しうるイベントについて、根本原因となる事象を特定するメタルールと、メタルールに対応させた障害復旧方法と、を有し、管理サーバが検知したイベントの根本原因となる原因イベントを表示すると共に、この原因イベントからの復旧方法を表示する。

Description

本発明は、障害からの復旧方法を表す情報の出力に関する。

昨今のインターネットビジネスの本格化に伴い、システムの障害によるサービスの停止が招く企業信用力の低下や機会損失の問題が大きくなってきている。そのため、障害から迅速に復旧することが望まれる。

復旧方法を特定することを支援するためのシステムとして、例えば、特許文献１に開示の障害履歴データベースシステムがある。システム管理者が、監視対象ノードにて発生した障害と実際に障害から復旧させた方法とを、障害履歴として、そのデータベースシステムに登録する。データベースシステムは、複数の障害履歴を保持する。監視対象ノードの管理者（以下、「システム管理者」と言うことがある）は、新たに障害が発生した場合、所望のキーワードを入力する。データベースシステムは、入力されたキーワードに適合する障害履歴を、複数の障害履歴から検索する。

一方、監視対象ノードの稼働状況を監視するために、監視システムがある。監視システムは、監視対象ノードの稼働状態の変化（例えば、ディスク装置に対する入出力（Ｉ／Ｏ）のエラー、及び、プロセッサのスループット低下）を、その監視対象ノードからイベントとして受け取る。システム管理者は、メッセージやパトランプを用いてそのイベントを受け取ることで、そのイベントの内容を知る。管理者は、そのイベントの内容から、その監視対象ノードの障害（例えば、サービスの停止や性能低下）を知り、その障害の根本原因を予測する。

また、障害の根本原因を予測する技術として、Root Cause Analysis（以後、ＲＣＡと呼ぶ）がある。監視システムは、イベント群と根本原因との組み合わせをルールとして予め保持しておき、イベントを受け取った場合、そのイベントを含んだルールから、そのイベントの根本原因を推測する。

特許文献２によれば、発生したイベントが既知の場合と未知の場合のそれぞれの場合について、不整合量が算出され、障害の根本原因の推測に、算出された不整合量が考慮される。

特許文献３によれば、監視対象ノード間の環境の関係性を表す情報が構築される。障害の根本原因の推測の際には、その情報を基に、或る監視対象ノードで発生した障害がどの監視対象ノードに影響を与えるかが特定される。

特開２００９−４３０２９号公報 特開２００６−５２６８４２号公報 米国特許第７，４７８，４０４号明細書

Ｆｒｅｄｅｒｉｃｋ Ｈａｙｅｓ−Ｒｏｔｈ， "Ｒｕｌｅ−Ｂａｓｅｄ ｓｙｓｔｅｍｓ"， Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｏｆ ｔｈｅ ＡＣＭ， Ｓｅｐｔ． １９８５， ｐａｇｅ９２１−９３２

しかし、特許文献１乃至３のいずれの技術でも、システム管理者は、障害からの適切な復旧方法を迅速に特定することができない。

例えば、監視対象ノードが、スイッチＡと、スイッチＡに接続される通信インターフェース装置（通信Ｉ／Ｆ）を有するサーバＡであり、サーバＡが、スイッチＡを介して、ストレージ装置に対してＩ／Ｏを行うようになっており、サーバＡが有する通信Ｉ／Ｆ（例えばＮＩＣ（Network Interface Card））に障害が発生したとする。その障害により、サーバＡのＩ／Ｏスループットが異常値に達した第１のイベントと、スイッチＡのネットワークトラフィックが異常値に達した第２のイベントとが発生する。第１及び第２のイベントを含んだイベント群を監視システムが検知する。そのイベント群の内容が、システム管理者に送信される。この時、障害履歴データベースシステムには、同件は格納されていないが類件が格納されているとする「同件」とは、発生した障害（イベント群に相当する障害）と同じ障害を表す情報を含んだ障害履歴である。「類件」とは、発生した障害とは違う障害を表す情報を含んでいるが発生した障害からの復旧方法と同じ復旧方法を表す情報を含んでいる障害履歴である。

特許文献１によれば、障害履歴の検索には、システム管理者所望のキーワードが用いられる。そのため、キーワード次第では、目的とする障害履歴がヒットしない、または、無関係の障害履歴が多数ヒットする可能性がある。

特許文献２によれば、障害の根本原因を検索クエリとした場合、同件はヒットしても類件がヒットしない可能性がある。

特許文献３によれば、根本原因としての障害が発生した監視対象ノード、もしくは、その障害による影響を受ける監視対象ノードが検索クエリとされた場合、無関係の障害履歴が多数ヒットする可能性がある。

そこで、本発明の目的は、障害の根本原因に応じた適切な復旧方法をシステム管理者が迅速に特定できるようにすることにある。

管理サーバは、複数のノード装置で発生しうるイベントについて、根本原因となる事象を特定するメタルールと、メタルールに対応させた障害復旧方法と、を有し、管理サーバが検知したイベントの根本原因となる原因イベントを表示すると共に、この原因イベントからの復旧方法を表示する。なお、復旧方法は、管理サーバを利用する管理者が入力した、前述の複数のノード装置で発生して復旧させた時に用いた復旧方法に基づいて作成又は更新された情報であってもよい。

図１は、実施例１に係る計算機システムの構成を示すブロック図である。 図２は、管理サーバの構成を示すブロック図である。 図３は、表示用計算機の構成を示すブロック図である。 図４は、サーバ情報の構成を示すブロック図である。 図５は、スイッチ情報の構成を示すブロック図である。 図６は、ストレージ情報の構成を示すブロック図である。 図７は、トポロジ情報の構成を示すブロック図である。 図８は、メタＲＣＡルール情報の構成を示すブロック図である。 図９は、展開ＲＣＡルール情報の構成を示すブロック図である。 図１０は、イベント情報の構成を示すブロック図である。 図１１は、障害分析コンテキストの構成を示すブロック図である。 図１２Ａは、障害履歴エントリの構成を示すブロック図である。 図１２Ｂは、サーバ重み情報の構成を示すブロック図である。 図１２Ｃは、スイッチ重み情報の構成を示すブロック図である。 図１２Ｄは、ストレージ重み情報の構成を示すブロック図である。 図１３は、展開ＲＣＡルールを作成するためのフロー図である。 図１４は、根本原因候補とその確信度を決定するためのフロー図である。 図１５は、障害分析コンテキストを作成するためのフロー図である。 図１６は、根本原因を選択するためのフロー図である。 図１７は、障害履歴を登録するためのフロー図である。 図１８Ａは、障害分析コンテキストのマッチングをするためのフロー図である。 図１８Ｂは、図１８Ａのステップ１０２６の詳細を表すフロー図である。 図１８Ｃは、図１８Ｂのステップ１０３１の詳細を表すフロー図である。 図１８Ｄは、図１８Ｂのステップ１０３４の詳細を表すフロー図である。 図１８Ｅは、障害分析コンテキストのマッチングの概要を示す図である。 図１８Ｆは、図１８Ｂのステップ１０３５の詳細を表すフロー図である。 図１８Ｇは、障害分析コンテキストのマッチングの概要を示す図である。 図１９は、候補／確信度画面の一例を示す。 図２０は、障害履歴の検索結果画面の一例を示す。 図２１は、障害履歴の登録画面の一例を示す。 図２２Ａは、実施例２で表示される、メタ復旧方法登録画面の一例を示す。 図２２Ｂは、メタ復旧方法登録画面における表示領域ｅ１３の別の一例を示す。 図２３は、実施例２で表示される候補／確信度画面の一例を示す。 図２４Ａは、マッチング度合比較画面の第１の例を示す。 図２４Ｂは、マッチング度合比較画面の第２の例を示す。

以下に、本発明の幾つかの実施例を説明する。

＜１−０：実施例１に係る計算機システム等の構成＞。

図１は、本発明の実施例１に係る計算機システム１の構成に関するブロック図である。

計算機システム１は、管理サーバ１０、表示用計算機２０、監視対象ノード３０を備える。なお、管理サーバ１０、表示用計算機２０、監視対象ノード３０は、それぞれ一台ずつが図示されているが、何台備わっていてもよい。

監視対象ノード３０は、管理サーバ１０によって管理される装置である。なお、監視対象ノード２０の一例としては、サーバ計算機、ストレージ装置（例えばＲＡＩＤ構成を有するディスクアレイ装置）、ネットワークスイッチ（例えば、ＦＣ（Fibre Channel）スイッチ）、ルータ）、プロキシーサーバ等が考えられるが、他の装置であってもよい。

管理サーバ１０は、一つ以上の監視対象ノード３０を管理する計算機である。

表示用計算機２０は、管理サーバ１０から出力された情報を表示するためのディスプレイ画面を有する計算機である。

管理サーバ１０、表示用計算機２０、監視対象ノード３０は、ネットワーク５０を介して相互に接続される。なお、管理サーバ１０と表示用計算機２０とを接続するネットワーク５０と、管理サーバ１０と監視対象ノード３０を接続するネットワーク５０は、同一のネットワークであるが、別々なネットワークであってもよい。

また、管理サーバ１０と表示用計算機２０は一体であってもよい。管理サーバ１０を複数の計算機で構成し、管理サーバ１０が有する機能をそれら複数の計算機が有しても良い。なお、以後の説明では、管理サーバ１０と表示用計算機２０を構成する一つ以上の計算機を「管理システム」と記載することがある。管理サーバ１０が表示用情報を表示する場合は、管理計算機が管理システムである、また、管理サーバ１０と表示用計算機２０の組み合わせも管理システムである。

図２は、管理サーバ１０の構成を示す。

管理サーバ１０は、メモリ１１０、メモリインターフェース１６１、プロセッサ１４０及びネットワークインターフェース１５０を備える計算機である。メモリインターフェース１６１、プロセッサ１４０及びネットワークインターフェース１５０は、内部ネットワーク（例えばバス）１６０によって相互に接続される。

プロセッサ１４０は、メモリインターフェース１６１を介してメモリ１１０にアクセスする。プロセッサ１４０は、メモリ１１０に記憶されるプログラムを実行することによって、各種処理を行う。以後の説明では、「プログラム」を主語として説明を行う場合があるが、プログラムは、プロセッサ１４０によって実行されることで、定められた処理をメモリ１１０及びネットワークインターフェース１５０を用いながら行うため、プロセッサ１４０を主語とした説明としてもよい。また、プログラムを主語として開示された処理は、管理サーバ１０等の計算機が行う処理としてもよい。また、プログラムの一部または全ては、専用ハードウェアによって実現されてもよい。

また、各種プログラムは、プログラムソース（例えば、プログラム配布サーバ、又は、コンピュータ読取可能な記憶メディア（例えば可搬型のメディア））から各計算機にインストールされてもよい。

メモリ１１０には、プロセッサ１４０によって実行されるプログラム、及び、プロセッサ１４０によって必要とされる情報等が記憶される。具体的には、例えば、メモリ１１０には、サーバ情報１１１、スイッチ情報１１２、ストレージ情報１１３、トポロジ情報１１４、メタＲＣＡルール情報１１５、展開ＲＣＡルール情報１１６、イベント情報１１７、障害履歴情報１１９、トポロジ適用プログラム１２１、ルールマッチング解析プログラム１２２、生成プログラム１２３、コンテキストマッチング解析プログラム１２４、及び障害履歴管理プログラム１２５が記憶される。更に、メモリ１１０には、アプリケーションプログラム（以下、ＡＰ）１３１及びＯＳ（Operating System）１３２が記憶される。

ＡＰ１３１は、各種処理を実現するプログラムである。例えば、ＡＰ１１７は、データベース管理機能又はＷＥＢサーバ機能を提供する。ＯＳ１３２は、管理サーバ１０の処理の全体を制御するプログラムである。

サーバ情報１１１は、一種の監視対象ノードであるサーバの構成情報を管理するための情報である。

スイッチ情報１１２は、一種の監視対象ノードであるスイッチの構成情報を管理するための情報である。

ストレージ情報１１３は、一種の監視対象ノードであるストレージ装置の構成情報を管理するための情報である。

トポロジ情報１１４は、監視対象ノードであるサーバ、スイッチ及びストレージの接続構成（トポロジ）の情報を管理するための情報である。

メタＲＣＡルール情報１１５は、メタＲＣＡルールを管理するための情報である。なお、メタＲＣＡルールについては、後述の＜１−１：用語定義＞で詳細を説明する。

展開ＲＣＡルール情報１１６は、展開ＲＣＡルールを管理するための情報である。なお、展開ＲＣＡルールについては、後述の＜１−１：用語定義＞で詳細を説明する。

イベント情報１１７は、監視対象ノードで発生したイベントのイベントレコードを管理するための情報である。

障害履歴情報１１９は、一以上の障害履歴エントリで構成されている。一つの障害履歴エントリが、過去に発生した障害の原因を表す情報と、復旧方法を表す情報と、障害分析コンテキストとを含んでいる。少なくとも障害履歴情報１１９は、外部の記憶資源（例えば外部のストレージ装置）に格納されていても良い。その場合には、例えば、プロセッサ１４０は、ネットワークインターフェース１５０を介して障害履歴情報１１９にアクセスすることができる。

トポロジ適用プログラム１２１は、メタＲＣＡルール情報１１５、サーバ情報１１１、スイッチ情報１１２、ストレージ情報１１３及びトポロジ情報１１４を用いて、展開ＲＣＡルール情報１１６を作成する。

ルールマッチング解析プログラム１２２は、展開ＲＣＡルール情報１１６とイベント情報１１７を用いて、イベント情報１１７と関連するメタＲＣＡルール情報１１５と展開ＲＣＡルール情報１１６と確信度とを決定する。

生成プログラム１２３は、メタＲＣＡルール情報１１５、展開ＲＣＡルール情報１１６、サーバ情報１１１、スイッチ情報１１２、ストレージ情報１１３及びトポロジ情報１１４を用いて、障害分析コンテキストを生成する。

コンテキストマッチング解析プログラム１２４は、生成された障害分析コンテキストと、各障害履歴エントリ内の障害分析コンテキストのマッチングを行う。

障害履歴管理プログラム１２５は、生成された障害分析コンテキストと、復旧方法を表す情報と、発生した障害の内容を表す情報とを含んだ障害分析コンテキストを生成し、障害分析コンテキストを、障害履歴情報１１９に含める。

ネットワークインターフェース１５０は、別の計算機（例えば監視対象ノード）とネットワーク５０を介してデータの送受信を行う。

なお、メモリ１１０に格納された各種プログラムは、必ずしも別々なプログラムコードである必要は無く、一つ以上のプログラムコードが、プログラムの処理を実現してもよい。

また、メモリ１１０に代えて、他種の記憶資源（記憶装置）が採用されても良い。

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

図３は、表示用計算機２０の構成を示す。

表示用計算機２０は、メモリ２１０、プロセッサ２４０、ネットワークインターフェース２５０及び入出力装置２６０を有する（例えば、図２に示したようなメモリインタフェースは図示を省略している）。メモリ２１０、プロセッサ２４０、ネットワークインターフェース２５０及び入出力装置２６０は、内部ネットワーク２７０によって相互に接続される。

プロセッサ２４０は、メモリ２１０に記憶されているプログラムを実行することによって、各種処理を行う。

メモリ２１０には、プロセッサ２４０によって実行されるプログラム、及び、プロセッサ２４０によって必要とされる情報等が記憶される。具体的には、例えば、メモリ２１０には、画面表示プログラム２１１が記憶される。更に、メモリ２１０には、アプリケーションプログラム（以下、ＡＰ）２２１及びＯＳ（Operating System）２２２が記憶される。ＡＰ２２１は、各種処理を実現するプログラムである。例えば、ＡＰ２２１は、ＷＥＢクライアント機能を提供する。ＯＳ２２２は、表示用計算機２０の処理の全体を制御するプログラムである。

画面表示プログラム２１１は、入出力装置２６０、例えばディスプレイ装置に情報を表示するプログラムである。

ネットワークインターフェース２５０は、別の計算機（例えば管理サーバ１０）とネットワーク５０を介してデータの送受信を行う。

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

また、管理サーバ１０が、第１及び第２の計算機を有し、第１の計算機が、トポロジ適用プログラム１２１、ルールマッチング解析プログラム１２２、及び生成プログラム１２３を実行し、第２の計算機が、コンテキストマッチング解析プログラム１２４及び障害履歴管理プログラム１２５を実行しても良い。この場合、サーバ情報１１１、スイッチ情報１２１、ストレージ情報１１３、トポロジ情報１１４、メタＲＣＡルール情報１１５及び展開ＲＣＡルール情報１１６は、第１の計算機が有し、イベント情報１１７及び障害履歴情報１１９は、第２の計算機が有しても良い。

＜１−１：用語定義＞。

以下に、実施例の説明で用いる用語の意味を記す。

「イベント」は、監視対象ノード３０で発生した稼働状態の変化の事象である。

「イベントレコード」は、イベントを特定するための情報である。イベントレコードは、例えば、イベントの種別を示す情報であるイベントタイプと、発生元の監視対象ノード３０の識別子と、イベントの内容を表す情報と、イベントの発生日時を表す情報とを含む。一つのイベントにつき一つのイベントレコードがある。

「ＲＣＡ」は、Root Cause Analysisの略であり、監視対象ノード（例えば、サーバ、スイッチ、ストレージ装置）のイベントレコードを基に、イベントの根本原因としての監視対象ノードを特定するための機能である。

「メタＲＣＡルール」は、或る障害とその障害により発生が想定されるイベント群とを定義したルールである。ＲＣＡにより用いられる。メタＲＣＡルールを用いることで、イベント群からその根本原因となる障害を導き出すことができる。メタＲＣＡルールは、一以上の監視対象ノードで構成されるトポロジを表すトポロジ情報を含まない情報（メタ情報）である。

「展開ＲＣＡルール」は、メタＲＣＡルールを監視対象ノード毎に展開したルールである。ＲＣＡにより用いられる。

「障害分析コンテキスト」は、障害を分析する際に用いられる情報である。障害分析コンテキストには、メタＲＣＡルール情報１１５内のレコード、展開ＲＣＡルール情報１１６内のレコード、サーバ情報１１１内のレコード、スイッチ情報１１２内のレコード、ストレージ情報１１３内のレコード、及び、トポロジ情報１１４内のレコードが関連付けられている。詳細は、図１１を参照して後に説明する。

＜１−２：管理サーバが有する情報＞。

以下、各種情報を説明するが、その際に、「識別子」、「名」、「ＩＤ」といった表現が用いられるが、これらは互いに置換が可能な識別情報である。

＜１−２−１：サーバ情報＞。

図４は、サーバ情報１１１を示す図である。

サーバ情報１１１は、一つのサーバにつき一つのレコード（以下、サーバレコード）を有するテーブルである。サーバレコードは、サーバＩＤ５０１、サーバ名５０２、サーバのベンダ５０３、サーバのＩＰアドレス５０４、サーバのＯＳ５０５、及び、サーバの連続稼働時間５０６を属性値として有する一つのレコードである。以下、一つのサーバ（以下、図４の説明において「対象サーバ」と言う）を例に採り、情報要素５０１〜５０６を説明する。

サーバＩＤ５０１は、トポロジ適用プログラム１２１が監視対象ノード３０である対象サーバに割り当てた識別子である。

サーバ名５０２は、対象サーバがもつコンピュータ名である。

サーバのベンダ５０３は、対象サーバがもつ製造元名である。

サーバのＩＰアドレス５０４は、ネットワーク上で対象サーバが割り当てられた識別子である。

サーバのＯＳ５０５は、対象サーバにインストールされているＯＳ名である。

サーバの連続稼働時間５０６は、対象サーバが最後に起動してから現在までの連続での稼働時間である。

なお、サーバ情報１１１は、サーバに関する属性値を有するのであれば、テーブル以外のデータ構造でもよく、上記に記した属性値以外の属性値を有しても良い。また、サーバ情報１１１は、サーバＩＤ５０１以外の少なくとも一つの属性値を有しなくてもよい。

＜１−２−２：スイッチ情報＞。

図５は、スイッチ情報１１２を示した図である。

スイッチ情報１１２は、一つのスイッチにつき一つのレコード（以下、スイッチレコード）を有するテーブルである。スイッチレコードは、スイッチＩＤ５１１、スイッチ名５１２、スイッチのベンダ５１３、スイッチのＩＰアドレス５１４、スイッチのタイプ５１５、及び、スイッチの連続稼働時間５１６を属性値とするレコードである。以下、一つのスイッチ（以下、図５の説明において「対象スイッチ」と言う）を例に採り、情報要素５１１〜５１６を説明する。

スイッチＩＤ５１１は、トポロジ適用プログラム１２１が監視対象ノード３０である対象スイッチに割り当てた識別子である。

スイッチ名５１２は、対象スイッチがもつコンピュータ名である。

スイッチのベンダ５１３は、対象スイッチがもつ製造元名である。

スイッチのＩＰアドレス５１４は、ネットワーク上で対象スイッチが割り当てられた識別子である。

スイッチのタイプ５１５は、対象スイッチの機種名である。

スイッチの連続稼働時間５１６は、対象スイッチが最後に起動してから現在までの連続での稼働時間である。

なお、スイッチ情報１１２は、スイッチに関する属性値を有するのであれば、テーブル以外のデータ構造でもよく、上記に記した属性値以外の属性値を有しても良い。また、スイッチ情報１１２は、スイッチＩＤ５１１以外の少なくとも一つの属性値を有しなくても良い。

＜１−２−３：ストレージ情報＞。

図６は、ストレージ情報１１３を示した図である。

ストレージ情報１１３は、一つのストレージ装置につき一つのレコード（以下、ストレージレコード）を有するテーブルである。ストレージレコードは、ストレージＩＤ５２１、ストレージ名５２２、ストレージのベンダ５２３、ストレージのＩＰアドレス５２４、ストレージのファームウェア５２５、及び、ストレージの連続稼働時間５２６を属性値として有するレコードである。以下、一つのストレージ装置（以下、図６の説明において「対象ストレージ」と言う）を例に採り、情報要素５２１〜５２６を説明する。

ストレージＩＤ５２１は、トポロジ適用プログラム１２１が監視対象ノード３０である対象ストレージに割り当てた識別子である。

ストレージ名５２２は、対象ストレージがもつコンピュータ名である。

ストレージのベンダ５２３は、対象ストレージがもつ製造元名である。

ストレージのＩＰアドレス５２４は、ネットワーク上で対象ストレージが割り当てられた識別子である。

ストレージのファームウェア５２５は、対象ストレージにインストールされているファームウェア名である。

ストレージの連続稼働時間５２６は、対象ストレージが最後に起動してから現在までの連続での稼働時間である。

なお、ストレージ情報１１３は、ストレージ装置に関する属性値を有するのであれば、テーブル以外のデータ構造でもよく、上記に記した属性値以外の属性値を有しても良い。また、ストレージ情報１１３は、ストレージＩＤ５２１以外の少なくとも一つの属性値を有しなくても良い。

＜１−２−４：トポロジ情報＞。

図７は、トポロジ情報１１４を示した図である。

トポロジ情報１１４は、一つのトポロジにつき一つのレコード（以下、トポロジレコード）を有するテーブルである。トポロジレコードは、トポロジＩＤ５３１、サーバＩＤ５３２、スイッチＩＤ５３３及びストレージＩＤ５３４を属性値とするレコードである。以下、一つのトポロジ（以下、図７の説明において「対象トポロジ」と言う）を例に採り、情報要素５３１〜５３４を説明する。

トポロジＩＤ５３１は、対象トポロジの識別子である。「トポロジ」とは、監視対象ノード３０同士の接続形態、言い換えれば、監視対象ノード３０の組合せである。具体的には、トポロジとして、監視対象ノードの種類と並びが定義されている。

サーバＩＤ５３２は、対象トポロジが有するサーバのサーバＩＤ５０１である。

スイッチＩＤ５３３は、対象トポロジが有するスイッチのスイッチＩＤ５１１である。

ストレージＩＤ５３４は、対象トポロジが有するストレージ装置のストレージＩＤ５２１である。

なお、トポロジ情報１１４は、監視対象ノード３０の接続形態に関する属性値を有するのであれば、テーブル以外のデータ構造でもよく、上記に記した属性値以外の属性値を有しても良い。本実施例では、トポロジは、典型的には、サーバ（計算機）がスイッチ（ネットワークスイッチ）を介してストレージ装置に接続されている接続形態である。このようなトポロジによれば、サーバは、ストレージ装置から提供される論理ボリュームを指定したＩ／Ｏコマンド（ライトコマンド又はリードコマンド）を発行する。Ｉ／Ｏコマンドは、スイッチを介してストレージ装置に届く。ストレージ装置は、そのＩ／Ｏコマンドに従い、そのコマンドで指定されている論理ボリュームに対するＩ／Ｏを行う。

＜１−２−５：メタＲＣＡルール情報＞。

図８は、メタＲＣＡルール情報１１５を示した図である。

メタＲＣＡルール情報１１５は、一つのメタＲＣＡルールにつき一つのレコード（以下、メタＲＣＡレコード）を有するテーブルである。メタＲＣＡレコードは、メタＲＣＡルールＩＤ５４１、サーバイベント５４２、スイッチイベント５４３、ストレージイベント５４４、原因ノード５４５及び原因内容５４６を属性値として有するレコードである。以下、一つのメタＲＣＡルール（以下、図８の説明において「対象メタＲＣＡルール」と言う）を例に採り、情報要素５４１〜５４６を説明する。

メタＲＣＡルールＩＤ５４１は、ルールマッチング解析プログラム１２２が対象メタＲＣＡルールに割り当てた識別子である。

サーバイベント５４２は、対象メタＲＣＡルールがもつサーバでのイベントの内容を表す情報である。

スイッチイベント５４３は、対象メタＲＣＡルールがもつスイッチでのイベントの内容を表す情報である。

ストレージイベント５４４は、対象メタＲＣＡルールがもつストレージ装置でのイベントの内容を表す情報である。

原因ノード５４５は、対象メタＲＣＡルールがもつイベントの根本原因であるノードの種類を表す情報である。

原因内容５４６は、対象メタＲＣＡルールがもつイベントの根本原因の内容を表す情報である。原因内容５４６と前述の原因ノード５４５との組合せが、イベント群の根本原因を表す。

なお、メタＲＣＡルール情報１１５は、メタＲＣＡルールに関する属性値を有するのであれば、テーブル以外のデータ構造でもよく、上記に記した属性値以外の属性値を有してもよい。

＜１−２−６：展開ＲＣＡルール情報＞。

図９は、展開ＲＣＡルール情報１１６を示した図である。

展開ＲＣＡルール情報１１６は、一つの展開ＲＣＡルールにつき一つのレコード（以下、展開ＲＣＡレコード）を有するテーブルである。展開ＲＣＡレコードは、展開ＲＣＡルールＩＤ５５１、メタＲＣＡルールＩＤ５５２、トポロジＩＤ５５３、原因ノードＩＤ５５４及び原因詳細５５５を属性値として有するレコードである。以下、一つの展開ＲＣＡルール（以下、図９の説明において「対象展開ＲＣＡルール」と言う）を例に採り、情報要素５５１〜５５５を説明する。

展開ＲＣＡルールＩＤ５５１は、ルールマッチング解析プログラム１２２が対象展開ＲＣＡルールに割り当てた識別子である。

メタＲＣＡルールＩＤ５５２は、対象展開ＲＣＡルールが属するメタＲＣＡルールがもつメタＲＣＡルールＩＤ５４１である。

トポロジＩＤ５５３は、対象展開ＲＣＡルールが属するトポロジがもつトポロジＩＤ５３１である。

原因ノードＩＤ５５４は、対象展開ＲＣＡルールの根本原因となる監視対象ノード３０を同定するためのサーバＩＤ５０１、スイッチＩＤ５１１又はストレージＩＤ５２１である。

原因詳細５５５は、対象展開ＲＣＡルールの根本原因の内容を表す原因内容５４６である。

なお、展開ＲＣＡルール情報１１６は、展開ＲＣＡルールに関する属性値を有するのであれば、テーブル以外のデータ構造でもよく、上記に記した属性値以外の属性値を有してもよい。

＜１−２−７：イベント情報＞。

図１０は、イベント情報１１７を示した図である。

イベント情報１１７は、一つのイベントにつき一つのイベントレコードを有するテーブルである。イベントレコードは、イベントＩＤ５６１、イベントタイプ５６２、対象ノードタイプ５６３、対象ノードＩＤ５６４、イベント内容５６５、発生日時５６６及び状態５６７を属性値として有するレコードである。以下、一つのイベント（以下、図１０の説明において「対象イベント」と言う）を例に採り、情報要素５６１〜５６７を説明する。

イベントＩＤ５６１は、ルールマッチング解析プログラム１２２が対象イベントのイベントレコードに割り当てた識別子である。

イベントタイプ５６２は、対象イベントの種類を表す情報である。イベントタイプ５６２の具体的な値として、例えば、「Ｃｒｉｔｉｃａｌ」、「Ｗａｒｎｉｎｇ」、「Ｉｎｆｏｒｍａｔｉｏｎ」、がある。

対象ノードタイプ５６３は、対象イベントの発生元である監視対象ノード３０のノードの種類（例えば、サーバ、スイッチもしくはストレージ装置）を表す情報である。

対象ノードＩＤ５６４は、対象イベントの発生元である監視対象ノード３０を表すサーバＩＤ５０１、スイッチＩＤ５１１又はストレージＩＤ５２１である。

イベント内容５６５は、対象イベントの内容を表す情報である。

発生日時５６６は、対象イベントの発生日時を表す情報である。

状態５６７は、対象イベントが解決済みか否かを表す情報である。

なお、イベント情報１１７は、イベントに関する属性値を有するのであれば、テーブル以外のデータ構造でもよく、上記に記した属性値以外の属性値を有してもよい。また、イベント情報１１７は、イベントＩＤ５５１、対象ノードＩＤ５６４、イベント内容５６５及び発生日時５６６以外の少なくとも一つの属性値を有しなくても良い。

＜１−２−８：障害分析コンテキスト＞。

図１１は、障害分析コンテキスト１２０を示した図である。

障害分析コンテキスト１２０は、障害分析コンテキストＩＤ６０１、メタＲＣＡルールＩＤ６０２、展開ＲＣＡルールＩＤ６０３、トポロジＩＤ６０４、サーバＩＤ６０５、スイッチＩＤ６０６及びストレージＩＤ６０７を属性値として有するデータである。

障害分析コンテキストＩＤ６０１は、生成プログラム１２３が障害分析コンテキスト１２０に割り当てた識別子である。

メタＲＣＡルールＩＤ６０２は、この障害分析コンテキスト１２０に関連付けられたメタＲＣＡルールを同定するためのメタＲＣＡルールＩＤ５４１である。

展開ＲＣＡルールＩＤ６０３は、この障害分析コンテキスト１２０に関連付けられた展開ＲＣＡルールを同定するための展開ＲＣＡルールＩＤ５５１である。

トポロジＩＤ６０４は、この障害分析コンテキスト１２０に関連付けられたトポロジを同定するためのトポロジＩＤ５３１である。

サーバＩＤ６０５は、この障害分析コンテキスト１２０に関連付けられたサーバを同定するためのサーバＩＤ５０１である。

スイッチＩＤ６０６は、この障害分析コンテキスト１２０に関連付けられたスイッチを同定するためのスイッチＩＤ５１１である。

ストレージＩＤ６０７は、この障害分析コンテキスト１２０に関連付けられたストレージ装置を同定するためのストレージＩＤ５２１である。

なお、障害分析コンテキスト１２０は、上記に記した属性値以外の属性値を有しても良い。

＜１−２−９：障害履歴情報＞。

図１２Ａは、障害履歴情報１１９が有する障害履歴エントリ１１９１を示した図である。

障害履歴エントリ１１９１は、障害履歴ＩＤ７０１、メタＲＣＡルールＩＤ７０２、展開ＲＣＡルールＩＤ７０３、トポロジＩＤ７０４、サーバＩＤ７０５、スイッチＩＤ７０６、ストレージＩＤ７０７、サーバ重みＩＤ７０８、スイッチ重みＩＤ７０９、ストレージ重みＩＤ７１０、原因７１１及び復旧方法７１２を属性値として有するデータである。

障害履歴ＩＤ７０１は、障害履歴管理プログラム１２５が障害履歴エントリ１１９１に割り当てた識別子である。

メタＲＣＡルールＩＤ７０２は、この障害履歴エントリ１１９１に関連付けられたメタＲＣＡルールを同定するためのメタＲＣＡルールＩＤ５４１である。

展開ＲＣＡルールＩＤ７０３は、この障害履歴エントリ１１９１に関連付けられた展開ＲＣＡルールを同定するための展開ＲＣＡルールＩＤ５５１である。

トポロジＩＤ７０４は、この障害履歴エントリ１１９１に関連付けられたトポロジを同定するためのトポロジＩＤ５３１である。

サーバＩＤ７０５は、この障害履歴エントリ１１９１に関連付けられたサーバを同定するためのサーバＩＤ５０１である。

スイッチＩＤ７０６は、この障害履歴エントリ１１９１に関連付けられたスイッチを同定するためのスイッチＩＤ５１１である。

ストレージＩＤ７０７は、この障害履歴エントリ１１９１に関連付けられたストレージ装置を同定するためのストレージＩＤ５２１である。

サーバ重みＩＤ７０８は、この障害履歴エントリ１１９１に関連付けられたサーバ重みレコードを同定するためのサーバ重みＩＤ８０１（図１２Ｂ参照）である。サーバ重みレコードは、サーバ重み情報８００が有するレコードである。

スイッチ重みＩＤ７０９は、この障害履歴エントリ１１９１に関連付けられたスイッチ重みレコードを同定するためのスイッチ重みＩＤ８１１（図１２Ｃ参照）である。スイッチ重みレコードは、スイッチ重み情報８１０が有するレコードである。

ストレージ重みＩＤ７１０は、この障害履歴エントリ１１９１に関連付けられたストレージ重みレコードを同定するためのストレージ重みＩＤ８２１（図１２Ｄ参照）である。ストレージ重みレコードは、ストレージ重み情報８２０が有するレコードである。

原因７１１は、この障害履歴エントリ１１９１に対応した障害の原因を表す情報である。

復旧方法７１２は、この障害履歴エントリ１１９１に対応した障害からの復旧方法を表す情報である。

障害履歴エントリ１１９１が有するＩＤ７０２〜７０７は、障害分析コンテキスト１２０（図１１参照）が有するＩＤ６０２〜６０７の複製である。つまり、前述したように、障害履歴エントリ１１９１は、障害分析コンテキスト１２０を有する。図１２Ａによれば、障害分析コンテキストＩＤ６０１は障害履歴エントリ１１９１に含まれていないが、そのＩＤ６０１がそのレコード１１９１に含まれても良い。

障害履歴情報１１９は、障害履歴に関する属性値を有するのであれば、上述のデータ構造以外のデータ構造でもよく、上記に記した属性値以外の属性値を有しても良い。また、障害履歴情報１１９は、サーバ重みＩＤ７０８、スイッチ重みＩＤ７０９及びストレージ重みＩＤ７１０を有していなくても良い。

＜１−２−１０：サーバ重み情報＞。

図１２Ｂは、サーバ重み情報８００を示した図である。

サーバ重み情報８００は、一つのサーバ重みにつき一つのレコード（サーバ重みレコード）を有するテーブルである。サーバ重みレコードは、サーバ重みＩＤ８０１、サーバのベンダ８０２、サーバのＩＰアドレス８０３、サーバのＯＳ８０４、及び、サーバの連続稼働時間８０５を属性値として有するレコードである。以下、一つのサーバ重み（図１２Ｂの説明において「対象サーバ重み」という）を例に採り、情報要素８０１〜８０５を説明する。

サーバ重みＩＤ８０１は、対象サーバ重みに割り当てられた識別子である。

サーバのベンダ８０２は、対象サーバ重みに属する一種の重みであり、サーバのベンダという項目をどれだけ重要視するかを表す値である。

サーバのＩＰアドレス８０３は、対象サーバ重みに属する一種の重みであり、サーバのＩＰアドレスという項目をどれだけ重要視するかを表す値である。

サーバのＯＳ８０４は、対象サーバ重みに属する一種の重みであり、サーバのＯＳという項目をどれだけ重要視するかを表す値である。

サーバの連続稼働時間８０５は、対象サーバ重みに属する一種の重みであり、サーバの連続稼働時間という項目をどれだけ重要視するかを表すである。

以上の説明からわかるように、「サーバ重み」とは、サーバに関する複数種類の項目の重みで定義されている。

なお、サーバ重み情報８００は、サーバ重みに関する属性値を有するのであれば、テーブル以外のデータ構造でもよく、上記に記した属性値以外の属性値も有しても良い。また、サーバ重み情報８００は、サーバ重みＩＤ８０１以外の少なくとも一つの属性値を有しなくても良い。

＜１−２−１１：スイッチの重み情報＞。

図１２Ｃは、スイッチの重み情報８１０を示した図である。

スイッチ重み情報８１０は、一つのスイッチ重みにつき一つのレコード（スイッチ重みレコード）を有するテーブルである。スイッチ重みレコードは、スイッチ重みＩＤ８１１、スイッチのベンダ８１２、スイッチのＩＰアドレス８１３、スイッチのタイプ８１４、及び、スイッチの連続稼働時間８１５を属性値として有するレコードである。以下、一つのスイッチ重み（図１２Ｃの説明において「対象スイッチ重み」という）を例に採り、情報要素８１１〜８１５を説明する。

スイッチ重みＩＤ８１１は、対象スイッチ重みに割り当てられた識別子である。

スイッチのベンダ８１２は、対象スイッチ重みに属する一種の重みであり、スイッチのベンダという項目をどれだけ重要視するかを表す値である。

スイッチのＩＰアドレス８１３は、対象スイッチ重みに属する一種の重みであり、スイッチのＩＰアドレスという項目をどれだけ重要視するかを表す値である。

スイッチのタイプ８１４は、対象スイッチ重みに属する一種の重みであり、スイッチのタイプという項目をどれだけ重要視するかを表す値である。

スイッチの連続稼働時間８１５は、対象スイッチ重みに属する一種の重みであり、スイッチの連続稼働時間という項目をどれだけ重要視するかを表すである。

以上の説明からわかるように、「スイッチ重み」とは、スイッチに関する複数種類の項目の重みで定義されている。

なお、スイッチ重み情報８１０は、スイッチ重みに関する属性値を有するのであれば、テーブル以外のデータ構造でもよく、上記に記した属性値以外の属性値も有しても良い。また、スイッチ重み情報８１０は、スイッチ重みＩＤ８１１以外の少なくとも一つの属性値を有しなくても良い。

＜１−２−１２：ストレージの重み情報＞。

図１２Ｄは、ストレージ重み情報８２０を示した図である。

ストレージ重み情報８２０は、一つのストレージ重みにつき一つのレコード（ストレージ重みレコード）を有するテーブルである。ストレージ重みレコードは、ストレージ重みＩＤ８２１、ストレージのベンダ８２２、ストレージのＩＰアドレス８２３、ストレージのファームウェア８２４、及び、ストレージの連続稼働時間８２５を属性値として有するレコードである。以下、一つのストレージ重み（図１２Ｄの説明において「対象ストレージ重み」という）を例に採り、情報要素８２１〜８２５を説明する。

ストレージ重みＩＤ８２１は、対象ストレージ重みに割り当てられた識別子である。

ストレージのベンダ８２２は、対象ストレージ重みに属する一種の重みであり、ストレージのベンダという項目をどれだけ重要視するかを表す値である。

ストレージのＩＰアドレス８２３は、対象ストレージ重みに属する一種の重みであり、ストレージのＩＰアドレスという項目をどれだけ重要視するかを表す値である。

ストレージのファームウェア８２４は、対象ストレージ重みに属する一種の重みであり、ストレージのファームウェアという項目をどれだけ重要視するかを表す値である。

ストレージの連続稼働時間８２５は、対象ストレージ重みに属する一種の重みであり、ストレージの連続稼働時間という項目をどれだけ重要視するかを表すである。

以上の説明からわかるように、「ストレージ重み」とは、ストレージに関する複数種類の項目の重みで定義されている。

なお、ストレージ重み情報８２０は、ストレージ重みに関する属性値を有するのであれば、テーブル以外のデータ構造でもよく、上記に記した属性値以外の属性値も有しても良い。また、ストレージ重み情報８２０は、ストレージ重みＩＤ８２１以外の少なくとも一つの属性値を有しなくても良い。

前述したサーバ重み情報８００、スイッチ重み情報８１０およびストレージ重み情報８２０が、例えば障害履歴情報に含まれている。

＜１−２−１３：各情報の抽象化＞。

以下の説明では、サーバ、スイッチ及びストレージ装置で構成されたトポロジを一例として記載する。しかし、本発明は、そのようなトポロジに限らず他種のトポロジについても適用可能である。例えば、トポロジは、所定のネットワークサービスを提供するサービス提供ノード装置（一例がストレージ装置）と、その所定のネットワークサービスを利用するサービス利用ノード装置（一例がサーバ）が、監視対象ノードであればよい。そうした広い観点から考えると、各種情報は、以下の情報を有していれば良いことになる。

サーバ情報（図４参照）は、より抽象的には、サービス利用ノード装置情報である。サービス利用ノード装置情報は、以下の情報（ａ１）〜（ａ３）：
（ａ１）サービス利用ノード装置のIPアドレス等のネットワーク識別子；
（ａ２）当該ノード装置のハードウェア又はソフトウェアの構成を表す情報；
（ａ３）設定内容を表す情報、
を含むことができる。

スイッチ情報（図５参照）は、より抽象的には、中継装置情報（または中継ノード装置情報）である。中継装置情報は、以下の情報（ｂ１）及び（ｂ２）：
（ｂ１）サービス利用ノード装置とサービス提供ノード装置との通信を仲介するノード装置（一例がスイッチ）のハードウェア又はソフトウェアの構成を表す情報；
（ｂ２）設定内容を表す情報、
を含むことができる。

ストレージ情報（図６参照）は、より抽象的には、サービス提供ノード装置情報である。サービス提供ノード装置情報は、以下の情報（ｃ１）〜（ｃ３）：
（ｃ１）サービス提供ノード装置のIPアドレス等のネットワーク識別子；
（ｃ２）当該ノード装置のハードウェア又はソフトウェアの構成を表す情報；
（ｃ３）設定内容を表す情報、
を含むことができる。また、サービス提供ノード装置情報は、サービス利用ノード装置が提供するネットワークサービスの種別を表す情報等を含んでも良い。

トポロジ情報（図７参照）は、サービス利用ノード装置の識別子と当該サービス利用ノード装置が利用するサービス提供ノード装置の識別子との組（または対応関係）を表す情報を含むことができる。なお、サービス利用ノード装置と当該サービス利用ノード装置とが通信する際に一つ以上の中継装置を介するのであれば、それら一つ以上の中継装置の識別子がトポロジ情報に含まれても良い。

メタＲＣＡルール情報（図８参照）は、管理サーバが監視対象とする各ネットワークサービスについて、以下の情報（ｄ１）及び（ｄ２）：
（ｄ１）サービス利用ノード装置で発生しうる第１のイベント（サービス利用ノード装置発生イベント）の種別と、サービス提供ノード装置（又は中継装置）で発生しうる第２のイベント（サービス提供ノード装置発生イベント）の種別との組み合わせを表す情報；
（ｄ２）第１のイベントと第２のイベントとが発生した場合の原因と決定できる（または原因と推定される）サービス提供ノード装置又は中継装置で発生しうる原因（または原因の種別）を示す情報、
を含むことができる。

展開ＲＣＡルール情報（図９参照）は、ネットワークサービスを利用又は提供する各監視対象ノードについて、以下の情報（ｅ１）〜（ｅ３）：
（ｅ１）サービス利用ノード装置であるノード装置で発生しうる第１のイベントの種別及びサービス利用ノード装置の識別子と、サービス提供ノード装置（又は中継装置）で発生しうる第２のイベントの種別及びサービス提供ノード装置（又は中継装置）の識別子との組み合わせを表す情報；
（ｅ２）第１のイベントと第２のイベントとが発生した場合の原因と決定できる（又は原因と推定される）サービス提供ノード装置（又は中継装置）の識別子；
（ｅ３）当該サービス提供ノード装置（又は中継装置）で発生しうる原因（または原因の種別）を示す情報、
を含むことができる。

障害分析コンテキスト（図１１参照）は、障害の根本原因を特定するために用いたメタＲＣＡルールの識別子を含むことができる。なお、障害の根本原因を特定するために用いた展開ＲＣＡルールの識別子、トポロジの識別子又は監視対象ノードの識別子が含まれてもよい。

障害履歴エントリ（図１２Ａ参照）は、障害分析コンテキストの内容と、そのコンテキストに対応した障害からの復旧方法（例えば復旧手順）を表す情報とを含むことができる。なお、障害履歴エントリは、そのレコードが有する障害分析コンテキストのマッチング度を評価するための評価値、又は、評価値が記録された情報の識別子を含んでも良い。

サーバ重み情報（図１２Ｂ参照）は、サービス利用ノード装置のハードウェア又はソフトウェア構成及び設定内容の要素に振り分ける、マッチング度を評価するための値を含むことができる。

スイッチ重み情報（図１２Ｃ参照）：中継装置のハードウェア又はソフトウェア構成及び設定内容の要素に振り分ける、マッチング度を評価するための値を含むことができる。

ストレージ重み情報（図１２Ｄ参照）は、サービス提供ノード装置のハードウェア又はソフトウェア構成及び設定内容の要素に振り分ける、マッチング度を評価するための値を含むことができる。

＜１−３：展開ＲＣＡルール作成＞。

図１３は、展開ＲＣＡルールを作成するフローを示す。

（ステップ１００１）トポロジ適用プログラム１２１は、ネットワーク５０を通じて、監視対象ノード３０から情報を取得する。監視対象ノード３０がサーバであれば、サーバ名、サーバのベンダ名、サーバのＩＰアドレス、サーバのＯＳ名、及び、サーバの連続稼働時間を含んだ情報（以下、サーバ取得情報）が取得される。トポロジ適用プログラム１２１は、各監視対象ノード（各サーバ）から受信したサーバ取得情報に基づいてサーバ情報１１１を作成又は更新する。具体的には、例えば、トポロジ適用プログラム１２１は、以下の処理（Ａ）及び（Ｂ）：
（Ａ）サーバ取得情報内の識別子がサーバ情報１１１に格納されていない場合、そのサーバ取得情報に対応した、サーバ情報１１１内のサーバレコード（以下、図１３の説明において「対象サーバレコード」と言う）に対して、サーバＩＤ５０１（例えば、サーバ取得情報内の識別子）を割り振り、そのサーバＩＤ５０１を対象レコードに格納する；
（Ｂ）サーバ取得情報内のサーバ名５０２、ベンダ名５０３、ＩＰアドレス５０４、ＯＳ名５０５及び連続稼働時間５０６を、対象サーバレコードに格納する、
を行う。

なお、サーバ取得情報のデータ構造は、サーバ情報１１１を更新できるのであれば、上記構造に限られない。また、予めサーバでないことが明らかな監視対象ノードについてはステップ１００１が省略されてもよい。

（ステップ１００２）トポロジ適用プログラム１２１は、ネットワーク５０を通じて、監視対象ノード３０から情報を取得する。監視対象ノード３０がスイッチであれば、スイッチ名、スイッチのベンダ名、スイッチのＩＰアドレス、スイッチのタイプ、及び、スイッチの連続稼働時間を含んだ情報（以下、スイッチ取得情報）が取得される。トポロジ適用プログラム１２１は、各監視対象ノード（各スイッチ）から受信したスイッチ取得情報に基づいてスイッチ情報１１２を作成又は更新する。具体的には、例えば、トポロジ適用プログラム１２１は、以下の処理（Ａ）及び（Ｂ）：
（Ａ）スイッチ取得情報内の識別子がスイッチ情報１１２に格納されていない場合、そのスイッチ取得情報に対応した、スイッチ情報１１２内のスイッチレコード（以下、図１３の説明において「対象スイッチレコード」と言う）に対して、スイッチＩＤ５１１（例えば、スイッチ取得情報内の識別子）を割り振り、そのスイッチＩＤ５１１を対象スイッチレコードに格納する；
（Ｂ）スイッチ取得情報のスイッチ名５１２、ベンダ名５１３、ＩＰアドレス５１４、タイプ５１５及び連続稼働時間５１６を、対象スイッチレコードに格納する、
を行う。

なお、スイッチ取得情報のデータ構造は、スイッチ情報１１２を更新できるのであれば、上記構造に限られない。また、予めスイッチでないことが明らかな監視対象ノードについてはステップ１００２が省略されてもよい。

（ステップ１００３）トポロジ適用プログラム１２１は、ネットワーク５０を通じて、監視対象ノード３０からから情報を取得する。監視対象ノード３０がストレージ装置であれば、ストレージ名、ストレージのベンダ名、ストレージのＩＰアドレス、ストレージのファームウェア名、及び、ストレージの連続稼働時間を含んだ情報（以下、ストレージ取得情報）が取得される。トポロジ適用プログラム１２１は、各監視対象ノード（各ストレージ装置）から受信したストレージ取得情報に基づいてストレージ情報１１３を作成又は更新する。具体的には、例えば、トポロジ適用プログラム１２１は、以下の処理（Ａ）及び（Ｂ）：
（Ａ）ストレージ取得情報内の識別子がストレージ情報１１３に格納されていない場合、そのストレージ取得情報に対応した、ストレージ情報１１３内のストレージレコード（以下、図１３の説明において「対象ストレージレコード」と言う）に対して、ストレージＩＤ５２１（例えば、ストレージ取得情報内の識別子）を割り振り、そのストレージＩＤ５２１を対象ストレージレコードに格納する；
（Ｂ）ストレージ取得情報のストレージ名５２２、ベンダ名５２３、ＩＰアドレス５２４、ファームウェア５２５及び連続稼働時間５２６を、対象ストレージレコードに格納する、
を行う。

なお、ストレージ取得情報のデータ構造は、ストレージ情報１１２を更新できるのであれば、上記構造に限られない。また、予めストレージでないことが明らかな監視対象ノードについてはステップ１００３が省略されてもよい。

（ステップ１００４）トポロジ適用プログラム１２１は、ネットワーク５０を通じて、監視対象ノード３０のトポロジ取得情報を受信する。トポロジ取得情報の一例として、スイッチのＩＤと、そのスイッチに接続されているサーバ及びストレージ装置のそれぞれのＩＤとを含む。具体的には、例えば、トポロジ適用プログラム１２１は、以下の処理（Ａ）及び（Ｂ）：
（Ａ）トポロジ取得情報内の識別子がトポロジ情報１１４に格納されていない場合、そのトポロジ取得情報に対応した、トポロジ情報１１４内のトポロジレコード（以下、図１３の説明において「対象トポロジレコード」と言う）に対して、トポロジＩＤ５３１（例えば、トポロジ取得情報内の識別子）を割り振り、そのトポロジＩＤ３２１を対象トポロジレコードに格納する；
（Ｂ）トポロジ取得情報内のスイッチＩＤ５３３、サーバＩＤ５３２及びストレージＩＤ５３４を、対象トポロジレコードに格納する、
を行う。

なお、トポロジ取得情報のデータ構造は、トポロジ情報１１４を更新できるのであれば、上記構造に限られない。また、予めスイッチ、サーバ及びストレージ装置でないことが明らかな監視対象ノードについてはステップ１００４が省略されてもよい。また、トポロジレコードは、次のように更新されても良い。すなわち、各監視対象ノードから、どの監視対象ノードに直接接続されているかを表す接続先情報が取得され、且つ、サーバ又はストレージ装置から、どのサーバからどの論理ボリュームにアクセスされるかを表すパス情報が取得され、接続先情報及びパス情報を基に、対象トポロジレコードが更新されても良い。

（ステップ１００５）トポロジ適用プログラム１２１は、トポロジ情報１１４とメタＲＣＡルール情報１１５とに基づいて、展開ＲＣＡルール情報１１６を作成する。より具体的には、このプログラム１２１が、以下の処理（ｘ）及び（ｙ）：
（ｘ）トポロジ情報１１４内のトポロジＩＤ５３１とメタＲＣＡルール情報１１５内のメタＲＣＡルールＩＤ５４１との全ての組み合わせを作成する（例えば、２つのトポロジＩＤ５３１と３つのメタＲＣＡルールＩＤ５４１がある場合、６つ（２×３＝６）の組合せを作成する）；
（ｙ）各組み合わせについて、展開ＲＣＡルールＩＤ５５１を割り振り、且つ、展開ＲＣＡルールＩＤ５５１と、組合せを構成するトポロジＩＤ及びメタＲＣＡルールＩＤとを、展開ＲＣＡレコード（展開ＲＣＡルール情報１１６内のレコード）に格納する、
を行う。なお、実際には利用されることのないストレージ装置とサーバの組み合わせを含んだトポロジのトポロジＩＤについては、上記（ｘ）の処理は行われなくて良い。同様に、他の処理によって展開ＲＣＡルール情報が作成されてもよい。より抽象化して考えた場合、例えば、トポロジ適用プログラム１２１は、以下の（ステップＡ）〜（ステップＤ）：
（ステップＡ）監視対象ノードから上記の各取得情報に含まれる少なくとも一つの値をノード取得情報として取得する；
（ステップＢ）ノード取得情報に基づいて、サービス利用ノード装置情報、サービス提供ノード装置情報、又は中継ノード装置情報を更新する；
（ステップＣ）トポロジ取得情報に基づいて、所定のネットワークサービスについてのサービス提供ノード装置の識別子と、当該ノード装置を利用するサービス利用ノード装置の識別子との対応を、トポロジ情報に含める；
（ステップＤ）トポロジ情報とメタＲＣＡルール情報に基づいて、展開ＲＣＡルール情報を更新する；
を行うことができる。

なお、上記の例によれば、展開ＲＣＡルール情報の１レコードがメタＲＣＡルール情報の１レコードから作成されるが、本発明はこれに限定されない。その一例としては多段推論がある。多段推論の場合、３段論法等を用いて複数のルールから新しいルールを導出することができる。この場合、展開ＲＣＡルール情報のメタＲＣＡルールＩＤ以外に、実際に一つ以上のメタＲＣＡルールのレコードとトポロジ情報とによって展開ＲＣＡルール情報が作成されればよい。複数のルールから新しいルールを導出する一例としては以下がある。
（第１のメタＲＣＡルール）第１のネットワークサービス（例えばＷＷＷ（World Wide Web））について、サービス利用ノード装置で発生する第１の種別のイベント（以下、イベントＡ）とサービス提供ノード装置で発生する第２の種別のイベント（以下、イベントＢ）とを検知した場合、イベントＡが発生する根本原因はイベントＢの発生である。
（第２のメタＲＣＡルール）第２のネットワークサービス(例えばＤＮＳ（Domain Name System）)について、サービス利用ノード装置で発生する第３の種別のイベント（以下、イベントＣ）と、サービス提供ノード装置で発生する第４の種別のイベント（以下、イベントＤ）とを検知した場合、イベントＣが発生する根本原因はイベントＤの発生である。
（第１のトポロジ情報）第１のネットワークサービスについて、ノード装置Ａがサービス利用ノード装置であり、ノード装置Ｂがサービス提供ノード装置である。
（第２のトポロジ情報）第２のネットワークサービスについて、ノード装置Ｂがサービス利用ノード装置であり、ノード装置Ｃがサービス提供ノード装置である。
（第３のトポロジ情報）ノード装置Ｂにおける第１のネットワークサービスは、第２のネットワークサービスを利用して提供する。
（生成される第１の展開ＲＣＡルール）ノード装置Ａで発生したイベントＡが検知され且つノード装置Ｂで発生したイベントＢが検知された場合、ノード装置Ａで発生したイベントＡの根本原因は、ノード装置ＢでのイベントＢの発生である。
（生成される第２の展開ＲＣＡルール）ノード装置Ｂで発生したイベントＣが検知され且つノード装置Ｃで発生したイベントＤが検知された場合、ノード装置Ｂで発生したイベントＣの根本原因は、ノード装置ＣでのイベントＤの発生である。
（生成される第３の展開ＲＣＡルール）ノード装置Ａで発生したイベントＡが検知され且つノード装置Ｃで発生したイベントＤが検知された場合、ノード装置Ａで発生したイベントＡの根本原因は、ノード装置ＣでのイベントＤの発生である。

なお、多段推論が用いられる場合、物理的な装置間（例えばノード間）の依存関係以外に、ネットワークサービス又は論理的な対象間の依存関係を表す情報も、トポロジ情報に含まれても良い。上記第３のトポロジ情報がその一例である。

また、図９の展開ＲＣＡルール情報では、メタＲＣＡルールＩＤ５５２及びトポロジＩＤ５５３に基づいて、メタＲＣＡルール情報１１５が表すメタＲＣＡルールとトポロジ情報が表すトポロジとを参照しつつ、根本原因の特定が行われる。しかし、代替の処理として、メタＲＣＡルール及びトポロジを基に展開されたルールを表す情報が、展開ＲＣＡルール情報に含まれても良い。この方式によれば、管理サーバ１０のメモリ１１０の消費量は増加するものの、根本原因を特定する速度はより高速となる。ただし、展開ＲＣＡルールからメタＲＣＡルールを特定する必要があるため、いずれにしても展開ＲＣＡルール情報にはメタＲＣＡルールＩＤ５５２は必要である。

＜１−４：イベント検知処理＞。

図１４は、イベントの検知からイベントの根本原因の特定までのフローを示す。本フローは一定時間毎（例えば１０分毎）または単なる繰り返しで実行される。

（ステップ１０１１）プログラム１２２は、全ての監視対象ノード３０に対して、イベントタイプ、対象ノードタイプ、対象ノードＩＤ、イベント内容、発生日時を含む情報であるイベントエントリを要求する。なお、イベントエントリに含まれる各情報要素は、以下の通りである：
（イベントタイプ）イベントエントリの属するイベントの種類（例えば、Ｃｒｉｔｉｃａｌ、Ｗａｒｎｉｎｇ、Ｉｎｆｏｒｍａｔｉｏｎ）を示す；
（対象ノードタイプ）発生したイベントの対象である監視対象ノード３０のノードの種類（例えば、サーバ、スイッチもしくはストレージ装置）を示す；
（対象ノードＩＤ）イベントが発生した監視対象ノード３０を示す識別子（サーバＩＤ５０１、スイッチＩＤ５１１又はストレージＩＤ５２１）である；
（イベント内容）発生したイベントの内容である；
（発生日時）イベントの発生日時である。

なお、イベントエントリは、ルールマッチング解析プログラム１２２からの要求を受けること無しに監視対象ノード３０から送信されても良い。また、発生日時を表す情報は必ずしも含まれていなくても良い。その場合、発生日時に代えて、管理サーバ１０が、イベントエントリを受信した日時を採用することができる。

（ステップ１０１２）ルールマッチング解析プログラム１２２は、ステップ１０１１で監視対象ノード３０からイベントエントリを受信した場合、ステップ１０１３を行う。監視対象ノード３０からイベントエントリを受信しなかった場合、ステップ１０１１が行われる。

（ステップ１０１３）ルールマッチング解析プログラム１２２は、イベントエントリに基づいてイベント情報１１７に情報を追加する。具体的には、例えば、プログラム１２２は、以下の処理（Ａ）〜（Ｃ）：
（Ａ）新規のイベントＩＤ５６１を取得し、イベント情報１１７内のブランクのレコード（以下、ステップ１０１３の説明において「対象レコード」と言う）に、そのＩＤ５６１を格納する；
（Ｂ）対象レコードに、イベントエントリ内のイベントタイプ、対象ノードタイプ、対象ノードＩＤ、イベント内容及び発生日時を格納する；
（Ｃ）対象レコードに、状態５６７として、「未解決」という値を格納する、
を行う。

なお、イベントエントリは、イベント情報１１７のイベントレコード（イベント情報１１７内のレコード）を追加又は更新できるのであれば、他の値を含んでも良い。

（ステップ１０１４）ルールマッチング解析プログラム１２２は、「未解決」を表す状態５６７を含んだイベントレコードと、トポロジ情報１１４と、展開ＲＣＡルール情報１１６とを基に、「未解決」を表す状態５６７を含んだイベントレコードと関連する展開ＲＣＡレコード（展開ＲＣＡルール情報１１６内のレコード）を特定する。具体的には、例えば、ルールマッチング解析プログラム１２２は、以下の処理（Ａ）〜（Ｈ）：
（Ａ）状態５５６が「未解決」のイベントレコードのうち、発生日時５６５が最も遅いイベントレコード（第１のイベントレコード）を特定する；
（Ｂ）直前のステップで特定された第１のイベントレコードを基に、一つ以上の第２のイベントレコードを特定する（第１のイベントレコード内の発生日時５６５と、第２のイベントレコード内の発生日時５６５との差は、所定の時間（例えば１０分前後）以内である）；
（Ｃ）上記（Ｂ）で得られた全ての第２のイベントレコード内の対象ノードタイプ５６３を参照し、それら第２のイベントレコード内の全ての対象ノードＩＤを基に、対象ノードタイプの異なる対象ノードＩＤで構成された全ての組み合わせ（以下、ノードＩＤセット）を作成する（例えば、４つのイベントレコードがあり、そのうちの２つがサーバＡ及びＢに関するレコードであり、残りの２つがスイッチＡ及びＢに関するレコードである場合、サーバＡのＩＤ−スイッチＡのＩＤ、サーバＡのＩＤ−スイッチＢのＩＤ、サーバＢのＩＤ−スイッチＡのＩＤ、及びサーバＢのＩＤ−スイッチＢのＩＤという４つのノードＩＤセットを作成する）；
（Ｄ−１）上記（Ｃ）で得られたいずれのＩＤセットにも含まれない対象ノードＩＤを含んだ第２のイベントレコード（「未解決」を表す状態５５６を含んだイベントレコード）がある場合、その中で発生日時５６５が最も遅い第２のイベントエントリを特定し、その第２のイベントエントリを上記第１のイベントエントリとして上記（Ｂ）を実施する；
（Ｄ−２）上記（Ｃ）で得られたいずれのＩＤセットにも含まれない対象ノードＩＤを含んだ第２のイベントレコード（「未解決」を表す状態５５６を含んだイベントレコード）がない場合、次の処理（Ｅ）を実施する；
（Ｅ）上記（Ｄ−１）及び（Ｄ−２）までに得られた各ノードＩＤセットについて、以下の（条件Ｅ１）〜（条件Ｅ３）の全てに適合するトポロジレコード（トポロジ情報１１４のレコード）：
（条件Ｅ１）ノードＩＤセット内のサーバの対象ノードＩＤと一致するサーバＩＤ５３２を有する；
（条件Ｅ２）そのノードＩＤセット内のスイッチの対象ノードＩＤと一致するスイッチＩＤ５３３を有する；
（条件Ｅ３）そのノードＩＤセット内のストレージ装置の対象ノードＩＤと一致するストレージＩＤ５３４を有する、
を探し、そのようなトポロジレコードが見つかれば、そのトポロジレコードが有するトポロジＩＤ５３１を抽出し、そのＩＤ５３１を、そのトポロジレコードに対応するノードＩＤセットに対応づける；
（Ｆ）上記（Ｅ）で得られた各ノードＩＤセット（条件Ｅ１〜Ｅ３に適合するトポロジレコードが特定されたノードＩＤセット）について、以下の（条件Ｆ１）〜（条件Ｆ３）の全てに適合するメタＲＣＡレコード（メタＲＣＡルール情報１１５のレコード）：
（条件Ｆ１）イベントＩＤセット内のサーバの対象ノードＩＤを有するイベントレコード内のイベント内容５６４と一致するサーバイベント５４２を有する；
（条件Ｆ２）そのイベントＩＤセット内のスイッチの対象ノードＩＤを有するイベントレコード内のイベント内容５６４と一致するスイッチイベント５４３を有する；
（条件Ｆ３）そのイベントＩＤセット内のストレージ装置の対象ノードＩＤを有するイベントレコード内のイベント内容５６４と一致するストレージイベント５４４を有する、
を探し、そのようなメタＲＣＡレコードが見つかれば、そのメタＲＣＡレコードが有するメタＲＣＡルールＩＤ５４１を抽出し、そのＩＤ５４１を、対応するノードＩＤセットに対応づける；
（Ｇ）上記（Ｆ）で得られた各ノードＩＤセット（メタＲＣＡルールＩＤ５４１が対応付けられたセット）について、以下の処理（ｇ１）〜（ｇ４）：
（ｇ１）ノードＩＤセットに対応付けられたメタＲＣＡルールＩＤ５４１を有するメタＲＣＡレコードから原因ノード５４５を抽出する；
（ｇ２）抽出された原因ノード５４５と一致する対象ノードタイプ５６３を有するイベントレコードを特定する；
（ｇ３）特定されたイベントレコードから対象ノードＩＤ５６４を抽出する；
（ｇ４）抽出された対象ノードＩＤ５６４を、上記（ｇ１）でのノードＩＤセットに対応付ける、
を行う；
（Ｈ）下記（ｈ１）〜（ｈ３）の要素を有する展開ＲＣＡレコード（展開ＲＣＡルール情報１１６のレコード）：
（ｈ１）上記（Ｅ）で得られたトポロジＩＤ５３１と一致するトポロジＩＤ５５３；
（ｈ２）上記（Ｆ）で得られたメタＲＣＡルールＩＤ５４１と一致するメタＲＣＡルールＩＤ５５２；
（ｈ３）上記（Ｇ）で得られた対象ノードＩＤ５６４と一致する原因ノードＩＤ５５４、
を抽出する。

（ステップ１０１５）ルールマッチング解析プログラム１２２は、ステップ１０１４で得られた複数の展開ＲＣＡレコードを、メタＲＣＡルールＩＤ５５２が一致するレコード同士でまとめる。これにより、メタＲＣＡルールＩＤ５５２が同じ展開ＲＣＡレコードのグループが１又は複数個できる。

（ステップ１０１６）プログラム１２２は、ステップ１０１５で得られたグループに属する展開ＲＣＡルールを、原因ノードＩＤ５５４が一致するレコード同士でまとめる。これにより、メタＲＣＡルールＩＤ５５２が同じ展開ＲＣＡレコードのグループにつき、原因ノードＩＤ５５４が同じ展開ＲＣＡレコードのサブグループが１又は複数個できる。原因ノードＩＤ５５４が示す監視対象ノード３０が、根本原因候補である。

（ステップ１０１７）プログラム１２２は、ステップ１０１６で得られた根本原因候補の確からしさを確信度として算出する。確信度の算出方法として、例えば、原因ノードＩＤ５５４が一致する展開ＲＣＡルールレコードの数に基づく方法がある。例えば、各根本原因候補に対して、原因ノードＩＤ５５４が一致する展開ＲＣＡルールレコードの数に応じた確信度が割り振られる。原因ノードＩＤ５５４が一致する展開ＲＣＡルールレコードの数が多い根本原因候補に割り振られた確信度は、そのような展開ＲＣＡルールレコードの数が少ない根本原因候補に割り振られた確信度よりも高い。なお、確信度は他の算出方法でもよい。

＜１−５：障害分析コンテキストの作成＞。

図１５は、障害分析コンテキストの作成のフロー図である。このフローは、例えばステップ１０１７の直後に開始される。

（ステップ１０１８）生成プログラム１２３は、障害分析コンテキスト１１８を作成する。具体的には、例えば、生成プログラム１２３は、以下の処理（Ａ）〜（Ｇ）：
（Ａ）ステップ１０１５で得られたメタＲＣＡルールＩＤ５５２を障害分析コンテキストに含める；
（Ｂ）ステップ１０１４で得られた１つ以上の展開ＲＣＡルールＩＤ５５１を有する１以上の展開ＲＣＡレコードのうちの、上記（Ａ）で得られたメタＲＣＡルールＩＤ５５２と一致するＩＤ５５２を有するレコードから展開ＲＣＡルールＩＤ５５１を抽出し、抽出したＩＤ５５１を障害分析コンテキストに含める；
（Ｃ）上記（Ｂ）で得られた展開ＲＣＡルールＩＤ５５１（６０３）と一致するＩＤ５５１を有する展開ＲＣＡレコードからトポロジＩＤ５５３を抽出し、そのＩＤ５５３を障害分析コンテキストに含める；
（Ｄ）上記（Ｃ）で得られたトポロジＩＤ５５３（６０５）と一致するＩＤ５３１を有するトポロジレコードからサーバＩＤ５３２を抽出し、そのＩＤ５３２を障害分析コンテキストに含める；
（Ｅ）上記（Ｃ）で得られたトポロジＩＤ５５３（６０５）と一致するＩＤ５３１を有するトポロジレコードからスイッチＩＤ５３３を抽出し、そのＩＤ５３３を障害分析コンテキストに含める；
（Ｆ）上記（Ｃ）で得られたトポロジＩＤ５５３（６０５）と一致するＩＤ５３１を有するトポロジレコードからストレージＩＤ５３４を抽出し、そのＩＤ５３４を障害分析コンテキストに含める；
（Ｇ）生成プログラム１２３が、障害分析コンテキストＩＤ６０１を割り振り、そのＩＤ６０１を障害分析コンテキストに含める、
を行う。障害分析コンテキスト１１８は、障害分析コンテキストＩＤ６０１とメタＲＣＡルールＩＤ６０３だけ用いて作成されてもよい。

＜１−６：根本原因の表示と選択＞。

図１６は、根本原因を選択のためのフローを示す。本フローは、例えばステップ１０１８の直後に開始される。

（ステップ１０１９）生成プログラム１２３は、以下の要素（ａ）〜（ｃ）を含む第１の表示情報：
（ａ）ステップ１０１６での原因ノードＩＤ５５４と一致するサーバＩＤ５０１を有するサーバレコード内のサーバ名５０２、ステップ１０１６での原因ノードＩＤ５５４と一致するスイッチＩＤ５１１を有するスイッチレコード内のスイッチ名５１２、又は、ステップ１０１６での原因ノードＩＤ５５４と一致するストレージＩＤ５２１を有するストレージレコード内のストレージ名５２２；
（ｂ）上記（ａ）での原因ノードＩＤ５５４に対応した展開ＲＣＡレコード（ステップ１０１５でまとめられた展開ＲＣＡレコード）における原因詳細５５５；
（ｃ）上記（ａ）での原因ノードＩＤ５５４に対応した確信度（ステップ１０１７で得られた確信度）、
を、ネットワーク５０を通じて表示用計算機２０に送信する。

（ステップ１０２０）画面表示プログラム２１１は、ステップ１０１９で送信された第１の表示情報を受信する。

（ステップ１０２１）画面表示プログラム２１１は、ステップ１０２０で受信した第１の表示情報を入出力装置２６０（例えば、ディスプレイ装置）に表示する。

図１９は、候補／確信度画面２０１０を示す。画面２０１０は、第１の表示情報の表示画面の一例である。

候補ＩＤ２０１１は、根本原因候補の識別子である。候補ＩＤ、例えば、表示プログラム２１１によって、各根本原因候補に割り振られる。

原因ノード名２０１２は、第１の表示情報に含まれている要素であり、根本原因候補（監視対象ノード３０）のサーバ名５０２、スイッチ名５１２、もしくはストレージ名５２２である。

原因詳細２０１３は、第１の表示情報に含まれている原因詳細５５５である。

確信度２０１４は、第１の表示情報に含まれている確信度である。

再び図１６の説明に戻る。

（ステップ１０２２）画面表示プログラム２１１は、入出力装置２６０（例えば、マウス）を用いてシステム管理者が選択した根本原因候補を同定するための情報（例えば原因ノードＩＤ）を、ネットワーク５０を通じて管理サーバに送信する。

（ステップ１０２３）生成プログラム１２３は、ステップ１０２２で送信された情報を受信する。

（ステップ１０２４）生成プログラム１２３は、ステップ１０２３で受信した情報と対応する障害分析コンテキスト１１８を決定する。この障害分析コンテキスト１１８は、ステップ１０１８作成された障害分析コンテキストである。

＜１−７：障害履歴の登録＞。

図１７は、障害の登録のフローを示す。障害履歴エントリが０件の場合、図１６のフローの後、このフローが開始される。障害履歴エントリが１件以上ある場合、図１６のフローの後、図１８Ａのフローを経た後、本フローが開始される。

（ステップ１０４０）表示用計算機２０は、障害履歴の登録画面を表示する。

図２１は、登録画面２０３０を示す。この画面２０３０は、障害履歴の登録画面の一例である。

根本原因２０３１は、ステップ１０１６での原因ノードＩＤに対応した根本原因候補（監視対象ノード３０）を示すサーバ名５０２、スイッチ名５１２もしくはスイッチ名５２２である。

障害分析コンテキストＩＤ２０３２乃至ストレージＩＤ２０３８は、ステップ１０１６での原因ノードＩＤと対応する障害分析コンテキスト（ステップ１０２４で決定されたコンテキスト）内の障害分析コンテキストＩＤ６０１乃至ストレージＩＤ６０７である。ステップ１０２４から当該ステップまでの間に、図１９に示した画面が閉じられてもよい。この場合、ステップ１０２４で得られた障害分析コンテキストを、図１９の画面を閉じる前にメモリ等の記憶装置に記録しておき、当該ステップにおいて読み込む必要がある。

原因２０３９は、当該障害の原因の内容を、システム管理者が入出力装置２６０を用いて自然言語で登録するシステム管理者フォームである。

復旧方法２０４０は、当該障害からの復旧方法の内容を、システム管理者が入出力装置２６０を用いて自然言語で登録するシステム管理者フォームである。

システム管理者は、原因２０３９と復旧方法２０４０の欄を入力した後、登録ボタンを押すことで、メタＲＣＡルールＩＤ２０３３乃至ストレージＩＤ２０３８、原因２０３９、復旧方法２０４０を、障害履歴管理プログラム１２５に送信する。

再び図１７を参照する。

（ステップ１０４１）障害履歴管理プログラム１２５は、ステップ１０４０で送信されたメタＲＣＡルールＩＤ２０３３乃至ストレージＩＤ２０３８、原因２０３９、復旧方法２０４０を受信する。

（ステップ１０４２）障害履歴管理プログラム１２５は、ステップ１０４１で受信したメタＲＣＡルールＩＤ２０３３乃至ストレージＩＤ２０３８と、原因２０３９と、復旧方法２０４０とを、障害履歴エントリに登録する。プログラム１２５は、このレコードに、障害履歴ＩＤ７０１を割り振る。

（ステップ１０４３）障害履歴管理プログラム１２５は、サーバの重み情報８００に新たなレコードを作成する。そのレコードのサーバのベンダ８０２乃至サーバの連続稼働時間８０５に初期値（例えば１００）が代入され、そのレコードにサーバ重みＩＤが格納される。なお、初期値は各要素の重みを示すものであれば他の値でもよい。

（ステップ１０４４）障害履歴管理プログラム１２５は、スイッチの重み情報８１０に新たなレコードを作成する。そのレコードのスイッチのベンダ８１２乃至スイッチの連続稼働時間８１５に初期値（例えば１００）が代入され、そのレコードにスイッチ重みＩＤが格納される。なお、初期値は各要素の重みを示すものであれば他の値でもよい。

（ステップ１０４５）障害履歴管理プログラム１２５は、ストレージの重み情報８２０に新たなレコードを作成する。そのレコードのストレージのベンダ８２２乃至ストレージの連続稼働時間８２５に初期値（例えば１００）が代入され、そのレコードにストレージ重みＩＤが格納される。なお、初期値は各要素の重みを示すものであれば他の値でもよい。

ステップ１０４３乃至１０４５についての説明では、監視対象ノードの組み合わせとして、ホスト＝スイッチ＝ストレージが例として採用されている。しかし、本発明は、監視対象ノードのハードウェア又はソフトウェア構成と設定内容との、任意の要素にマッチング度を評価するための値、を含んでいればよい。そうした広い観点から考えると、ステップ１０４３乃至ステップ１０４５では、障害分析コンテキストがもつ監視対象ノードのハードウェア又はソフトウェア構成と設定内容との任意の要素に、障害分析コンテキストのマッチングのための評価値を割り振る処理があればよい。

＜１−９：障害履歴の検索＞。

図１８Ａは、障害履歴情報から同件及び／又は類件の障害履歴エントリを取得するフローである。

（ステップ１０２５）コンテキストマッチング解析プログラム１２４は、障害履歴エントリの件数が０件の場合、本フローを終了する。プログラム１２４は、障害履歴エントリの件数が１件以上の場合、ステップ１０２２を実行する。

（ステップ１０２６）プログラム１２４は、障害分析コンテキストを用いて障害履歴情報を検索する。ステップ１０２６の詳細は、後に図１８Ｂを用いて説明する。

（ステップ１０２７）プログラム１２４は、ステップ１０２６で得られた検索結果の情報を表示用計算機２０に送信する。なお、検索結果の情報には、例えば、障害履歴ＩＤ７０１、メタＲＣＡルールＩＤ７０２、展開ＲＣＡルールＩＤ７０３、トポロジＩＤ７０４、サーバＩＤ７０５、スイッチＩＤ７０６、ストレージＩＤ７０７、サーバ重みＩＤ７０８、スイッチ重みＩＤ７０９、ストレージ重みＩＤ７１０、原因７１１、復旧方法７１２及びマッチング率が含まれる。しかし、後述する図２０の表示が可能であれば、他の情報が送信されてもよい。

（ステップ１０２８）画面表示プログラム２１１（表示用計算機２０）は、ステップ１０２７で送信された情報を受信し、入出力装置２６０（例えば、ディスプレイ装置）に表示する。その際、プログラム２１１は、マッチング率が高い情報を優先的に表示する（例えば、マッチング率の降順（高い順）に情報を表示する）。

図２０は、ステップ１０２８で表示される検索結果画面２０２０を示す。この画面２０２０は、検索結果画面の一例である。

履歴ＩＤは、ヒットした検索履歴に割り振られた識別子（例えば通し番号）である。

障害履歴ＩＤ２０２２は、ヒットした障害履歴エントリがもつ障害履歴ＩＤ７０１である。

障害履歴ノード名２０２３は、サーバレコード内のサーバ名５０２、スイッチレコード内のスイッチ名５１２、又は、ストレージレコード内のストレージ名５２２である。それらの要素５０２、５２２又は５１２を有するレコードは、原因ノードＩＤ５５４と一致するＩＤを有する。その原因ノードＩＤ５５４は、ヒットした障害履歴エントリがもつ展開ＲＣＡルールＩＤ７０３と一致する展開ＲＣＡルールＩＤ５５１を有する展開ＲＣＡレコード内にある。

原因２０２４は、ヒットした障害履歴エントリがもつ原因７１１である。

復旧方法２０２５は、ヒットした障害履歴エントリがもつ復旧方法７１２である。

マッチング率２０２６は、ステップ１０２７でコンテキストマッチング解析プログラム１２４より送信されたマッチング率を示す。このマッチング率の降順に検索結果が表示される。

検索結果画面には、図２０に示した情報要素に代えて又は加えて、障害履歴の検索結果に関する他種の情報要素が表示されても良い。

システム管理者が、図２０に示した画面における表から任意の行（障害履歴）を選択すると、選択された障害履歴が表す障害と今回発生した障害とを比較するための画面が表示される。

図２４Ａは、マッチング度合比較画面の第１の例を示す。

今回発生した障害に関する情報の詳細が表示領域ｅ０１に表示される。表示領域ｅ０１には、例えば、今回の障害に対応したメタＲＣＡルールＩＤ５４１と、発生したイベントのノード名５０２、５１２もしくは５２２と、イベント内容５６５とが表示される。

選択された障害履歴の詳細が表示領域ｅ０２に表示される。表示領域ｅ０２には、障害履歴のメタＲＣＡルールＩＤ５４１と、発生したイベントのノード名５０２、５１２もしくは５２２と、イベント内容５６５とが表示される。

表示領域ｅ０３には、今回の障害と障害履歴とのマッチング率２０２６が表示される。

表示領域ｅ０４には、障害履歴の復旧方法２０２５が表示される。

図２４Ａは、マッチング度合比較画面の第２の例を示す。

表示領域ｅ０５には、今回の障害に関して、イベント情報とトポロジ情報とノード情報に基づく図が表示される。図としては、ノード間の繋がりがどのようになっていてどのノードでどんなイベントが発生したかが表示された図である。具体的には、例えば、表示領域ｅ０５には、３つのブロックがあり、各ブロックは、いずれかのノードに対応しており、ブロック同士の繋がりは、トポロジ情報から特定されるトポロジに従っており、ブロック内に表示される文字列は、そのブロックに対応したノードのノード名と、そのノードで発生したイベント（障害）の内容とを表している。

表示領域ｅ０６には、障害履歴に関して、イベント情報とトポロジ情報とノード情報に基づく図が表示される。具体的には、例えば、表示領域ｅ０６には、３つのブロックが表示されているが、各ブロックは、表示領域ｅ０５と同様に、いずれかのノードに対応している。

表示領域ｅ０５に表示された情報と表示領域ｅ０６に表示された情報とのうち互いに一致する部分（メタＲＣＡルールが一致する部分）が、破線で囲む等の方法で示される。これにより、システム管理者は、システム管理者が選択した障害履歴と今回の障害との差異を視覚的に把握できる。具体的には、今回発生した障害は、選択された障害履歴と比べて、ノード名「BOTAN」のノードでのIOエラーが生じていないことがわかる。

なお、マッチング度合比較画面には、システム管理者が今回の障害と障害履歴の比較を参照できるなら、他の値を表示してもよい。例えば、図２４Ｂの各ブロック（いずれかのノードに対応したブロック）には、ノードタイプを表す情報が表示されても良い。

図１８Ｂは、図１８Ａのステップ１０２６の詳細を示す。

（ステップ１０３１）コンテキストマッチング解析プログラム１２４は、ステップ１０３１の処理として、メタＲＣＡルールマッチングを行う。ステップ１０３１の詳細は、後に図１８Ｃを参照して説明する。

以下、図１８Ｃが示すフローについて説明する。

（ステップ１１０１）コンテキストマッチング解析プログラム１２４は、特定の障害分析コンテキストを含んだ障害履歴エントリの検索要求を、障害履歴管理プログラム１２５に送信する。ここで、「特定の障害分析コンテキスト」とは、ステップ１０２４で得た障害分析コンテキスト１１９のメタＲＣＡルールＩＤと等しいメタＲＣＡルールＩＤをもつ障害分析コンテキストである。

（ステップ１１０２）障害履歴管理プログラム１２５は、ステップ１１０１で送信された検索要求を受信する。

（ステップ１１０３）障害履歴管理プログラム１２５は、ステップ１１０２で受けた検索要求に応答して、上記特定の障害分析コンテキストをもつ障害履歴エントリを検索する。プログラム１２５は、その検索結果を表す情報を、コンテキストマッチング解析プログラム１２４に送信する。送信される情報は、特定の障害分析コンテキストを含んだ障害履歴エントリに登録されている情報を含んでいる。

（ステップ１１０４）コンテキストマッチング解析プログラム１２４は、ステップ１１０３で送信された情報を受信する。

再び図１８Ｂの説明に戻る。

（ステップ１０３３）コンテキストマッチング解析プログラム１２４は、ステップ１０３１で得た障害履歴エントリの数が第１の閾値（例えば１０）を下回る場合、ステップ１０３４を実行する。一方、プログラム１２４は、ステップ１０３１で得られた障害履歴エントリの数が第２の閾値（例えば５０）を上回る場合、ステップ１０３５を実行する。第２の閾値は、第１の閾値と同じかそれより大きい値である。ステップ１０３１で得られた障害履歴エントリが適切な数（例えば第１の閾値以上第２の閾値以下）の場合、本フローを終了する。

なお、前述した第１及び第２の閾値のうちの少なくとも一つは、システム管理者が任意に設定可能である。

（ステップ１０３４）プログラム１２４は、検索の条件を緩めることでステップ１０３１より多くの障害履歴エントリを得るための処理を行う。具体的には、図１８Ｄに示す処理が行われる。検索クエリである障害分析コンテキストが複数のメタＲＣＡルールをもつ場合（すなわち、展開ＲＣＡルールが、メタＲＣＡルールの多段推論で成り立っている場合）、検索クエリと同じメタＲＣＡルールを一つ以上持つ障害履歴エントリを全て得るようにする。

以下、図１８Ｄが示すフローについて説明する。

（ステップ１１１１）コンテキストマッチング解析プログラム１２４は、検索元の障害分析コンテキスト（検索のキーとなる障害分析コンテキスト）１１９がもつ複数のメタＲＣＡルールＩＤ６０２と等しいメタＲＣＡルールＩＤ７０２をｋ個（ｋは自然数）以上もつ障害履歴エントリの検索要求を、障害履歴管理プログラム１２５に送信する。なお、ｋの値は、システム管理者が任意に設定できる。

（ステップ１１１２）障害履歴管理プログラム１２５は、ステップ１１１１で送信された検索要求を受信する。

（ステップ１１１３）プログラム１２５は、ステップ１１１２で受けた検索要求に応答して、検索を行なう。つまり、プログラム１２５は、検索元の障害分析コンテキスト１１９のメタＲＣＡルールＩＤ６０２と等しいメタＲＣＡルールＩＤ７０２をｋ個以上もつ障害履歴エントリに記録されている情報を送信する。例えば、ｋ＝２であり、且つ、図１８Ｅに例示するように、互いに２つのメタＲＣＡルールＩＤが一致している場合、図示の障害履歴エントリに記録されている情報が送信される。なお、検索元の障害分析コンテキスト１１９内のメタＲＣＡルールＩＤ６０２と一致するメタＲＣＡルールＩＤの数が多い障害履歴エントリから順に高いマッチング率が割り当てられ、その割り当てられたマッチング率を表す情報が、送信される情報に含まれてよい。つまり、この例では、検索元の障害分析コンテキスト１１９内のメタＲＣＡルールＩＤ６０２と一致するメタＲＣＡルールＩＤの数に基づいて、マッチング率が算出される。なお、マッチング率は、他の算出方式でもよい。

（ステップ１１１４）コンテキストマッチング解析プログラム１２４は、ステップ１１１３で送信された情報を受信する。なお、送信される情報の件数（検索ヒットとする障害履歴エントリの件数）は、適切な数（例えば後述の第１の数及び／又は第２の数）以下に抑えられても良い。

以上が、図１８Ｂのステップ１０３４での検索についての説明である。なお、検索の方法としては、上述した方法に限らず、他の方法が採用されても良い。例えば、検索元の障害分析コンテキストもいずれの障害履歴エントリも一つのメタＲＣＡルールＩＤを有している場合、検索元の障害分析コンテキスト内のメタＲＣＡルールＩＤから同定されるメタＲＣＡルール（以下、第１のメタＲＣＡルール）と、障害履歴エントリ内のメタＲＣＡルールＩＤから同定されるメタＲＣＡルール（以下、第２のメタＲＣＡルール）とが異なっていても、障害履歴管理プログラム１２５は、第１のメタＲＣＡルールとのマッチング率がＸ％以上（Ｘは自然数）の第２のメタＲＣＡルールのＩＤを有する障害履歴エントリを、検索ヒットの対象としても良い。ここでのマッチング率は、第１のメタＲＣＡルールに属するイベント群と第２のメタＲＣＡルールに属するイベント群との重複度合いに基づく。具体的には、例えば、第１のメタＲＣＡルールに属するイベントの総数に対する重複したイベントの数の第１の割合と、第２のメタＲＣＡルールに属するイベントの総数に対する重複したイベントの数の第２の割合とのうちの少なくとも一方を基に、マッチング率が算出される。図２４Ｂの例によれば、表示領域ｅ０５に表示されている第１のメタＲＣＡルールと、表示領域ｅ０６に表示されている第２のメタＲＣＡルールは部分的に一致している。第１の割合は２／２（＝１）であり、第２の割合は２／３である。これらのうちの少なくとも一つの割合を基に算出されるマッチング率が、上記Ｘ％以上であれば、表示領域ｅ０６に表示されている第２のメタＲＣＡルールは検索ヒットとなる。なお、各メタＲＣＡルールに属するイベントが何であるかは、メタＲＣＡルール情報１１５を参照することにより、特定することができる。

再び、図１８Ｂの説明に戻る。

（ステップ１０３５）コンテキストマッチング解析プログラム１２４は、図１８Ｆに示す処理を行う。この処理では、ステップ１０３１で得られた検索結果に対して、マッチング率を評価することで、検索ヒットした複数の障害履歴エントリから、検索元の障害分析コンテキストと条件の近い障害履歴エントリを素早く得ることができるようにする。マッチング評価は、例えば、以下の（Ａ）及び（Ｂ）：
（Ａ）検索元の障害分析コンテキストから特定される監視対象ノードハードウェア又はソフトウェア構成、及び設定内容の要素；
（Ｂ）障害履歴エントリから特定される監視対象ノードのハードウェア又はソフトウェア構成、及び設定内容の要素、
の互いの一致度を基に行われる。

以下、図１８Ｆが示すフローを説明する。

（ステップ１１２１）コンテキストマッチング解析プログラム１２４は、ステップ１０２４で得た障害分析コンテキスト１１９のメタＲＣＡルールＩＤ（第１のメタＲＣＡルールのＩＤ）を含んだ検索要求を、障害履歴管理プログラム１２５に送信する。

（ステップ１１２２）プログラム１２５は、ステップ１１０１で送信された検索要求を受信する。

（ステップ１１２３）プログラム１２５は、ステップ１１０２で受けた検索要求に応答して検索を行い、コンテキストマッチング解析プログラム１２４に、第１のメタＲＣＡルールＩＤと等しいメタＲＣＡルールＩＤをもつ障害履歴エントリに記録されている情報を送信する。

（ステップ１１２４）コンテキストマッチング解析プログラム１２４は、ステップ１１０３で送信された情報を受信する。

（ステップ１１２５）プログラム１２４が、以下の処理（Ａ）〜（Ｄ）：
（Ａ）検索元の障害分析コンテキスト内のＩＤから同定されるサーバレコード、スイッチレコード及びストレージレコードのうちの少なくとも一つのレコードと、ステップ１１２４で得た障害履歴エントリ内のＩＤから同定されるサーバレコード、スイッチレコード及びストレージレコードのうちの少なくとも一つのレコードとから、互いに一致する又は近似する値を抽出する（例えば、連続稼働時間については、誤差が３０００以内であれば、互いに近似する値となる）；
（Ｂ）上記（Ａ）で得た各値に対応した各項目の重みを、障害履歴情報が有するサーバ重み情報８００、スイッチ重み情報８１０及びストレージ重み情報８２０から抽出する；
（Ｃ）ステップ１１２４で得た障害履歴エントリ毎に、上記（Ｂ）で得た重みの累計値を算出する；
（Ｄ）ステップ１１２４で得た各障害履歴エントリに、重みの累計値に応じたマッチング率を割り当てる（例えば、重みの累計値が高い障害履歴エントリには高いマッチング率が割り当てられ、重みの累計値が低い障害履歴エントリには低いマッチング率が割り当てられる）、
を行う。なお、マッチング率の算出には、重みの累計値に代えて又は加えて、他の要素が参酌されてもよい。

（ステップ１１２６）プログラム１２４は、ステップ１１２５で得たマッチング率の降順に障害履歴エントリを並べ替える。この処理を行うことで、システム管理者は、今回発生した障害とマッチング率の高い障害履歴から順に参照することができる。

（ステップ１１２７）プログラム１２４は、ステップ１１２５の比較処理において、障害履歴情報がもつ情報８００、８１０及び８２０のうち、ステップ１１２５で抽出された値の項目（以下、図１８Ｆ及び図１８Ｇの説明において「対象項目」と言う）に対応した重みを相対的に増加する。「相対的に増加する」とは、対象項目に対応した重みを増加することであっても良いし、非対象項目に対応した重みを減少することであっても良い。

（ステップ１１２８）プログラム１２４は、重みが変更された項目の識別情報（例えば名称）と更新後の重み（及び／又は変化量）とを含んだ更新要求を、障害履歴管理プログラム１２５に送信する。

（ステップ１１２９）障害履歴管理プログラム１２５は、上記更新要求に応じて、障害履歴情報内の情報８００、８１０及び８２０のうちの少なくとも一つを更新する。つまり、ステップ１１２７で計算された重みを、障害履歴情報内の情報８００、８１０及び８２０における対応するレコードに反映する。

図１８Ｇを参照して、図１８Ｆを参照して説明したフローの概要を説明する。

検索元の障害分析コンテキスト（又は検索クエリ）が、そのコンテキストから特定される展開ＲＣＡルール（又はトポロジ）に属する各ノード装置について、ノード装置のタイプ以外の各属性の重みを表す値を含んでいる。

そのコンテキストと第１の障害履歴エントリとの比較によれば、複数種類の属性のうち、ベンダとＯＳが一致している。このため、第１の障害履歴エントリについての累計値は、ベンダについての重み「５０」とＯＳについての重み「８０」との合計「１３０」となる。

一方、そのコンテキストと第２の障害履歴エントリとの比較によれば、複数種類の属性のうち、ＩＰアドレスと連続稼働時間が一致している。このため、第２の障害履歴エントリについての累計値は、ＩＰアドレスについての重み「２０」と連続稼働時間「１０」との合計「３０」となる。

この結果、第１の障害履歴エントリの方が第２の障害履歴エントリよりも検索元の障害分析コンテキストとの類似度が高いということになる。

ステップ１１２５で、ベンダ、ＩＰアドレス、ＯＳ及び連続稼働時間のいずれも抽出された場合、ステップ１１２７で、それらの属性の重みはより高い値とされる。なお、ステップ１１２５で抽出された値に対応した属性に代えて又は加えて、システム管理者から選択された復旧方法を表す情報を含んだ障害分析レコードが有する各値に対応した属性の重みがより高い値とされても良い。

システム管理者が、以上のようにして、今回発生した障害の復旧方法を、障害履歴情報から特定する。システム管理者は、今回発生した障害の復旧を終えた後、この事象を障害履歴として図１７のフローを実施する。これにより、今回発生した障害に対応する障害分析コンテキストと、今回発生した障害の根本原因を表す情報と、今回採った復旧方法を表す情報とが対応付けられる。

図１８Ｂのステップ１０３１で得られた情報を基に、ステップ１１２４以降が行われても良い。

以上が、実施例１についての説明である。

実施例１によれば、障害履歴エントリが、発生した障害の根本原因を表す情報と、その根本原因に応じた復旧方法を表す情報との他に、その発生した障害に対応する障害分析コンテキストを含む。障害分析コンテキストは、複数の原因／結果ルールのうちの、障害の根本原因の根拠となった原因／結果ルールを特定するための情報（以下、ルール特定情報）を含んだ情報である。原因／結果ルールは、以下の（ｘ）及び（ｙ）：
（ｘ）根本原因としての、ノード装置のタイプと発生したイベントの内容；
（ｙ）結果としての、ノード装置のタイプと発生したイベントの内容（どのタイプのノード装置でどんなイベントが発生したか）、
の対応関係を表す。発生した障害に対応した障害分析コンテキストを含んだ検索クエリが、システム管理者から管理サーバに入力される。管理サーバは、その検索クエリに応答して、検索クエリが有する障害分析コンテキスト（第１の障害分析コンテキスト）と、障害履歴情報が有する各障害履歴エントリ内の障害分析コンテキスト（第２の障害分析コンテキスト）とを比較し、それにより、検索元の障害分析コンテキストと類似性の高い障害分析コンテキストを含んだ障害履歴エントリを特定する。管理サーバは、特定された第２の障害履歴エントリに登録されている情報（復旧方法を表す情報を含んだ情報）を表示する。これにより、システム管理者は、迅速に、発生した障害からの復旧方法を特定することができる。

また、発生した障害に対応した第１の障害分析コンテキストと、特定された復旧方法を表す情報とを含んだ新たな障害履歴エントリを登録することができる。この登録作業は、システム管理者が手動で行っても良いし、管理サーバが自動で行っても良い。後者の場合、例えば、管理サーバは、検索の際に使用された第１の障害分析コンテキストと、特定された根本原因を表す情報と、特定された復旧方法を表す情報とを含んだ障害履歴エントリを登録することができる。

また、第１の障害分析コンテキストと類似する第２の障害分析コンテキストを含んだ障害履歴エントリの検索の際、第１及び第２の障害分析コンテキスト内のルール特定情報を基に、どのタイプのノード装置でどんなイベントが発生したかを表す情報が特定される。つまり、ノード装置のタイプが互いに比較される。このため、同じ内容のイベントが発生したノード装置が違っていても、ノード装置のタイプが同じであれば、当該第２の障害分析コンテキストが第１の障害分析コンテキストに類似するということになる。従って、例えば、前回或るイベントがサーバＡで発生し、今回は同イベントがサーバＢで発生した場合、その前回の障害に対応する第２の障害分析コンテキストを含んだ障害履歴エントリが、検索ヒットの対象となる可能性がある。つまり、類件をヒットさせることができる。

また、実施例１の説明によれば、原則、第１の障害分析コンテキストから特定される原因／結果ルールと完全に一致する原因／結果ルールが関連付けられた第２の障害分析コンテキストを含んだ障害履歴エントリが、検索ヒットの対象となる。しかし、ヒットした障害履歴エントリの数が、第１の数よりも少ない場合、条件を緩和して再検索が行われる。具体的には、例えば、原因／結果ルール同士が所定の類似度（但し１００％未満）以上に類似していれば、検索履歴レコードがヒットとなる。一方、ヒットした障害履歴エントリの数が、第１の数又は第１の数よりも大きい第２の数よりも多い場合、条件を厳しくして再検索が行われる。具体的には、例えば、ノード装置のタイプ以外の複数の属性のうちの或る程度の属性が一致している場合に（ノード装置同士が或る程度類似している場合に）、検索履歴レコードがヒットとなる。

＜２−０：実施例２の概要＞。

本発明の実施例２に係る管理システムは、復旧方法の手順をメタ化してメタ復旧方法として登録することを補助する機能と、メタ復旧方法をメタＲＣＡルールに対応づける機能と、根本原因参照時にメタ復旧方法を併せて表示する機能とを有する。

実施例１では、管理システムが、過去に障害が発生したノードのＩＰアドレス等の識別子を表示し、システム管理者は、表示された復旧方法の情報を、今回障害が発生したノードに置き換えて作業を行う。

実施例２では、メタ復旧方法を用いることで、管理システムが、今回障害が発生したノードの識別子を用いた復旧方法を表示する。これにより、システム管理者は、根本原因参照時に、採り得る復旧方法の候補を特定することができる。

＜２−１：実施例２における実施例１との構成の差異＞
実施例１のメタＲＣＡルール情報１１５（メタＲＣＡレコード）に、メタ復旧方法（後述）を表す情報が対応づけられる。

実施例１のステップ１０４０において、障害履歴の登録画面（図２１）に、メタ復旧方法登録画面（図２２Ａ）が追加され、メタ復旧方法を登録するステップが追加される。

実施例１のステップ１０２０において、根本原因候補リストと確信度画面（図１９）に、メタ復旧方法を表す情報が追加される（図２３）。

＜２−２：用語定義＞。

「メタ復旧方法」とは、管理システムが提供する有限の要素（オブジェクト）の組み合わせで定義される復旧方法である。メタ復旧方法は、特定のノードに依存しない方法であり、メタＲＣＡルールと対応づけて登録することができる。復旧方法を定義できるなら情報の形式は問わない。本実施例では、一例として、メタ復旧方法を、一つ以上のＡｒｃ、Ｂｒａｎｃｈ及びＣｏｍｍａｎｄの３つの要素の組み合わせから定義されるとする。ちなみに、「Ａｒｃ」は、ＢｒａｎｃｈまたはＣｏｍｍａｎｄ間の遷移を示す。「Ｂｒａｎｃｈ」は、条件分岐を示す。「Ｃｏｍｍａｎｄ」は、処理を示す。

＜２−３：メタ復旧方法の登録＞。

メタ復旧方法の登録は、例えば、実施例１におけるステップ１０４０において障害履歴の登録情報を送信する直前のタイミングで行う。

図２２Ａは、メタ復旧方法登録画面の一例を示す。

表示領域ｅ１１には、Ａｒｃ、Ｂｒａｎｃｈ及びＣｏｍｍａｎｄのアイコンが設置されている。システム管理者は、いずれかのアイコンを表示領域ｅ１２にドラッグアンドドロップすることで、表示領域ｅ１２にアイコンを設置することができる。

図２２Ａｅ０２は、メタ復旧方法を定義するための編集画面である。表示領域ｅ０１のアイコンを配置することで、メタ復旧方法の構成が定義できる。

表示領域ｅ１３は、表示領域ｅ１２に設置した各アイコンの詳細設定を実施するウィンドウである。本図ではBranchの設定画面の一例を示す。

表示領域ｅ１４は、当該アイコンの識別子を示す。

表示領域ｅ１５は、条件分岐における条件の対象を選択するフォームである。選択項目はシステム側が提供する有限の要素である。

表示領域ｅ１６は、条件分岐における条件の内容を選択するフォームである。選択項目はシステム側が提供する有限の要素である。

表示領域ｅ１７は、表示領域ｅ１６で定義した条件が真の場合の遷移先と、偽の場合の遷移先を定義する。

表示領域ｅ１８は、表示領域ｅ１６だけでは表現しきれない分岐の内容の詳細を入力するフォームである。該情報は、システム管理者による自然言語で登録される。

システム管理者は、当該画面にてメタ復旧方法の定義を終えたら表示領域ｅ１９の登録ボタンを押すことで登録が完了し、実施例１のステップ１１４０において登録するメタＲＣＡルール情報に本メタ復旧方法を対応づける。

図２３Ｂに示す表示領域ｅ１３は、表示領域ｅ１３がＣｏｍｍａｎｄの設定画面であった場合の一例を示す。

図２３Ｂに示す表示領域ｅ１４は、当該アイコンの識別子を示す。

図２３Ｂに示す表示領域ｅ１５は、処理の対象を選択するフォームである。選択項目はシステム側が提供する有限の要素である。

図２３Ｂに示す表示領域ｅ１６は、処理の内容を選択するフォームである。選択項目はシステム側が提供する有限の要素である。

図２３Ｂに示す表示領域ｅ１７は、表示領域ｅ１６だけでは表現しきれない処理の内容の詳細を入力するフォームである。該情報は、システム管理者による自然言語で登録される。

要するに、メタ復旧方法の定義では、復旧の開始から終了までにおけるオブジェクトの遷移の流れが定義される。具体的には、どのオブジェクト（条件分岐又は処理）からどのオブジェクトに遷移するかが定義される。

＜２−４：メタ復旧方法の取得＞。

メタ復旧方法の取得は、例えば、実施例１におけるステップ１０１５のメタＲＣＡルールを抽出する直後に実施される。メタ復旧方法登録時にメタＲＣＡルールに対応づけて登録したため、メタＲＣＡルールが決定すれば、メタ復旧方法も決定されることになる。

実施例１におけるステップ１０１９で、メタ復旧方法も一緒に送信される。

実施例１におけるステップ１０２０で、根本原因と確信度の他に、メタ復旧方法も表示される。

図２３は、実施例２で表示される候補／確信度画面の一例である。

実施例１の図１９と比較して、得られた全てのメタ復旧方法の内、Ｃｏｍｍａｎｄの処理内容の累計を示した表である表示領域ｅ２１と、メタ復旧方法のＣｏｍｍａｎｄの処理一覧をリストアップした列である列ｅ２２が追加されている。

表示領域ｅ２１によれば、「サーバリブート７件、サーバリプレース２件、バックアップからのリカバリ２件」と表示されている。これにより、システム管理者は、採り得る復旧における処理のバリエーションを特定し易い。

列ｅ２２には、各根本原因に対応する復旧方法の概要が記載されている。これにより、システム管理者は、各根本原因に対応する復旧方法の概要を迅速に特定することができる。

以上、本発明の実施例２によれば、条件分岐（Ｂｒａｎｃｈ）及び処置（Ｃｏｍｍａｎｄ）といった共通パーツを用いた一連のフローで定義されたメタ復旧方法が用意される。そして、イベント群と根本原因との組み合わせのメタＲＣＡルールに、メタ復旧方法が関連付けられる。これにより、発生した障害の検出から復旧方法までを一つのルールとして定義できる。

＜３−０：実施例３の概要＞。

既存の一般的なルールベースシステムを用いた場合のデータ構造について具体例を示す。以下の記述は、実施例１に記載の各種情報の抽象化した場合の一つの具体例であるが、ルールベースシステムの場合は、時間的な条件など二つ以上の物理的又は論理的な対象間の関係以外の記述も可能である。

本実施例は、前述した非特許文献１の汎用的ルールベースシステムが適用された本発明の一実施例である。

非特許文献１によれば、ルールメモリとファクトメモリをルールベースシステム上にもつ汎用的ルールベースシステムが開示されている。ルールメモリは、特定の個体に依存せず記述された汎用ルールが格納されている。ファクトメモリは、特定の個体の具体的な情報が格納されている。

該ルールベースシステムは、該ルールと該情報を用いて、新しい事実を導出するシステムである。

＜３−１：実施例３の具体的データ構造＞。

非特許文献１を基に、ルールとして、Ｃａｕｓａｌｉｔｙ ＲｕｌｅとＴｏｐｏｌｏｇｙ Ｒｕｌｅを定義する。

Ｃａｕｓａｌｉｔｙ Ｒｕｌｅとは、イベントとその原因の関係を、特定トポロジに依存せず記述したルールである。具体的なＣａｕｓａｌｉｔｙ Ｒｕｌｅの例は以下の通りである。

Ｃ−ＲＵＬＥ−１００：
ＩＦ Ｓｅｒｖｅｒ（Ｘ） ＆ Ｓｔｏｒａｇｅ（Ｙ） ＆ ＦＣ−Ｃｏｎｎｅｃｔｅｄ（ｘ，ｙ） ＆ ＥｖｅｎｔＨａｐｐｅｎｓＯｎ（ＩＯ＿ＥＲＲＯＲ， ｘ， ｙ， ｔ１） ＆ ＥｖｅｎｔＨａｐｐｅｎｓＯｎ（ＣＴＲＬ＿ＦＡＩＬ， ｙ， ｔ２） ＆ ＷｉｔｈｉｎＴｉｍｅＷｉｎｄｏｗ（ｔ１， ｔ２， “１０ ｍｉｎｕｔｅｓ”）
ＴＨＥＮ ＩｄｅｎｔｉｆｙＲｏｏｔＣａｕｓｅ（ＣＴＲＬ＿ＦＡＩＬ， ｙ）
Ｔｏｐｏｌｏｇｙ Ｒｕｌｅとは、ノードの接続状態を、特定トポロジに依存せず記述したルールである。具体的なＴｏｐｏｌｏｇｙ Ｒｕｌｅの例は以下の通りである。

Ｔ−ＲＵＬＥ−２００：
ＩＦ ＦＣ−ｃｏｎｎｅｃｔｅｄ（ｘ，ｙ）＆ ＦＣ−ｃｏｎｎｅｃｔ（ｚ，ｙ）
ＴＨＥＮ ＦＣ−ｃｏｎｎｅｃｔｅｄ（ｘ、ｚ）。

ｘ、ｙなどの小文字のアルファベットは変数を示す。ＩＯ＿ＥＲＲＯＲ、“ＳｅｒｖｅｒＡ”は定数（特定のインスタンス）を示すリテラルとする。

トポロジ適用プログラム１２１は、Ｃａｕｓａｌｉｔｙ ＲｕｌｅとＴｏｐｏｌｏｇｙ Ｒｕｌｅをルールベースシステム上のルールメモリに格納する。

トポロジ適用プログラム１２１は、Ｔｏｐｌｏｇｙルールを監視対象ノード３０に適用することで、下記トポロジファクトを検出し、ルールベースシステム上のファクトメモリに格納する。
ＴＦ１： Ｓｅｒｅｒ（“ＳｅｒｖｅｒＡ”）
ＴＦ２： Ｓｔｏｒａｇｅ（“ＳｔｏｒａｇｅＡ”）
ＴＦ３： Ｓｗｉｔｃｈ（“ＳｗｉｔｃｈＡ”）
ＴＦ４： ＦＣ−Ｃｏｎｎｅｃｔｅｄ（“ＳｅｒｖｅｒＡ”， “ＡＢＣ”）
ＴＦ５： ＦＣ−Ｃｏｎｎｅｃｔｅｄ（“ＡＭＳ１０００”， “ＡＢＣ”）。

ルールベースシステムは、Ｃａｕｓａｌｉｔｙ Ｒｕｌｅとトポロジファクトを組み合わせて、以下の例のようなインスタンスを作成する。

Ｃ−ＲＵＬＥ−１００−ＩＮＳＴＡＮＣＥ−１：
ＩＦ ＥｖｅｎｔＨａｐｐｅｎｓＯｎ（ＩＯ＿ＥＲＲＯＲ， “ＳｅｒｖｅｒＡ”，ｔ１） ＆ ＥｖｅｎｔＨａｐｐｅｎｓＯｎ（ＣＴＲＬ＿ＦＡＩＬ， “ＳｔｏｒａｇｅＡ”，ｔ２） ＆ ＷｉｔｈｉｎＴｉｍｅＷｉｎｄｏｗ（ｔ１， ｔ２， “１０ ｍｉｎｕｔｅｓ”）
ＴＨＥＮ ＩｄｅｎｔｉｆｙＲｏｏｔＣａｕｓｅ（ＣＴＲＬ＿ＦＡＩＬ， “ＳｔｏｒａｇｅＡ”）。

Ｃ−ＲＵＬＥ−１００−ＩＮＳＴＡＮＣＥ−１もメモリ上に格納される。

トポロジ適用プログラム１２１が監視対象ノード３０を監視しており，"ＳｅｒｖｅｒＡ"でＩＯ＿ＥＲＲＯＲイベントと、“ＳｔｏｒａｇｅＡ”でＣＴＲＬ＿ＦＡＩＬイベントが、イベント相関処理の時間幅内で発生したことを観測した場合、トポロジ適用プログラム１２１は，ルールベースシステムに対して、次のイベントファクトをメモリに格納する。
EF1:
EventHappensOn(IO_ERROR, "ServerA", "12:32:12 22009/03/10")
EF2:
EventHappensOn(CTRL_FAIL, "AMS1000", "12:32:10 22009/03/10")
EF3:
WithinTimeWindow("12:32:10 22009/03/10", "12:32:12
22009/03/10", "10 minutes")。

ルールベースシステムは、Ｃ−ＲＵＬＥ−１００−ＩＮＳＴＡＮＣＥ−１とイベントファクトから、ＩｄｅｎｔｉｆｙＲｏｏｔＣａｕｓｅ（ＣＴＲＬ＿ＦＡＩＬ， “ＳｔｏｒａｇｅＡ”）を導出し、これにより根本原因が特定できる。

上記の枠組みでは、
Ｃ−ＲＵＬＥ−１００−ＩＮＳＴＡＮＣＥ−１という中間形式が展開ＲＣＡルールであり、
Ｃ−ＲＵＬＥ−１００（Ｃａｕｓａｌｉｔｙ Ｒｕｌｅ）がメタＲＣＡルールに対応し、"Ｃ−ＲＵＬＥ−１００"がメタＲＣＡルールＩＤ５４１となる。

複数のＣａｕｓａｌｉｔｙ Ｒｕｌｅを用いて多段推論が行われる場合もあり，メタＲＣＡルールは複数あってよい。

本実施例では、メモリの中を参照し、根本原因の導出に利用されたメタＲＣＡルールと対応したＣａｕｓａｌｉｔｙ Ｒｕｌｅや、展開ＲＣＡルールと対応したインスタンスを取得し、障害分析コンテキストとして扱うことで、本発明の効果を得ることができる。

以上のように、一般的なルールベースシステムを適用することができる。なお、展開ＲＣＡルール情報のデータ構造として、以下のような格納形式が採用されてもよい。
（Ａ）監視対象ノードで発生して管理システムが管理対象とする発生部位（含むノード装置）及びイベント内容を区別するイベントについて、全ての組み合わせパターンを格納する。
（Ｂ）（Ａ）の組み合わせの中で根本原因を特定可能な組み合わせについては、根本原因とする発生部位（ノード装置を含む）及びイベント内容を対応させて格納する。

なお、対応する根本原因がない（Ａ）の組み合わせの格納が省略されてもよい。

以上の説明により、本発明の一つの観点である、複数のノード装置と通信するインターフェースと、前記インターフェースを介して、前記複数のノード装置で発生するイベントを検知するプロセッサと、イベント情報と、メタルール情報と、障害履歴情報と、を格納する記憶資源と、前記複数のノード装置についての情報を表示する表示装置と、入力装置と、を備える管理システムについて：
＊前記イベント情報は、前記発生したイベントの発生元ノード装置を特定する情報と、前記発生したイベントの種別と、を示すイベントエントリを含む。
＊前記メタルール情報は、ノード装置で潜在的に発生する可能性のある潜在イベントの種別と、前記潜在イベントの種別に対応するイベントが発生した場合に根本原因と特定可能なイベントの種別とを示すメタルール、を含む。
＊前記障害履歴情報は、復旧方法を示す情報及び前記復旧方法が対応する前記メタルールを識別する情報を含む障害履歴エントリ、を含む。

＊前記プロセッサは：
（Ａ）前記メタルール情報に基づき、前記イベント情報に格納した前記イベントエントリで特定される第一のイベントの根本原因である第一の原因イベントを特定し、前記第一の原因イベントの特定に用いた第一のメタルールを特定し；
（Ｂ）前記第一の原因イベントから復旧する方法である第一の復旧方法を、前記入力装置を介して受信し、前記第一の復旧方法に基づいて、前記障害履歴情報に前記第一のメタルールに対応する第一の障害履歴エントリを追加し；
（Ｃ）前記メタルール情報に基づき、前記イベント情報に格納した前記イベントエントリで特定される第二のイベントの根本原因である第二の原因イベントを特定し、第二の原因イベントの特定に用いた第二のメタルールを特定し；
（Ｄ）前記障害履歴情報に基づき、前記第二のメタルールに対応する所定の障害履歴エントリを特定する。

＊前記表示装置は：
（Ｘ）前記第二の原因イベントに関する情報を、前記第二のイベントの根本原因として表示し；
（Ｙ）前記所定の障害履歴エントリに基づき、前記第二の原因イベントからの復旧方法を表示する、
ことを特徴とした管理システムについて説明した。

なお、管理システムは、前記障害履歴エントリは復旧方法を適用したノード装置の識別子を含み、前記表示装置は：
（Ｚ）前記所定の障害履歴エントリが示すノード装置の識別子を、前記（Ｙ）の前記所定の障害履歴エントリが示す復旧方法を適用したノード装置の識別子として表示してもよい。

また、管理システムは、前記第一の原因イベントの発生元ノード装置と前記第二の原因イベントの発生元ノード装置は異なるノード装置の場合、前記表示装置は：
（ａ）前記（Ｘ）の前記第二の原因イベントに関する情報の表示として、前記第二の原因イベントの発生元ノード装置の識別子を含む情報を表示し、
（ｂ）前記（Ｚ）の前記所定の障害履歴エントリが示すノード装置の識別子の表示として、前記第一の原因イベントの発生元ノード装置の識別子を表示してもよい。

また、前記（Ｄ）の特定は：
（Ｄ１）前記第二のメタルールと同一のメタルールのを示す前記障害履歴エントリを選択し、
（Ｄ２）前記（Ｄ１）により選択された障害履歴エントリの数が第一の閾値未満の場合は、前記障害履歴エントリが対応するメタルールと、前記第二のメタルールとのマッチング率に基づいて前記所定の障害履歴エントリを特定し、
（Ｄ３）前記（Ｄ１）により選択された障害履歴エントリを前記所定の障害履歴エントリと特定してもよい。

また、前記記憶資源は、前記複数のノード装置の構成設定情報を格納し、前記障害履歴エントリは、前記複数のノード装置の当該エントリ作成時点に対応する過去の構成設定情報を含み、前記（Ｄ）の特定は：
（Ｄ４）前記（Ｄ１）により選択された障害履歴エントリの数が第二の閾値以上の場合は、前記障害履歴エントリに含まれる前記過去の構成設定情報と、前記構成設定情報とのマッチング率に基づいて、前記所定の障害履歴エントリを特定してもよい。

なお、上記（Ｄ４）は（Ｄ２）及び（Ｄ３）を前提としなくてもよい。また、前記記憶資源は、構成設定情報の項目についての重み値を示す、重み情報を格納し、前記（Ｄ４）の特定は、前記重み情報に基づいて行われてもよい。

また、前記（Ｂ）の第一の復旧方法は、前記第一の原因イベントの発生元ノード装置の識別子を含まない復旧方法であるメタ復旧方法であり、前記（Ｙ）の前記第二の原因イベントからの復旧方法の表示は、前記メタ復旧方法と前記第二の原因イベントの発生元ノード装置の識別子との表示であってもよい。

記憶資源は、管理システムの中にあっても良いし外にあっても良い。中にある場合、記憶資源は、例えば、メモリである。外にある場合、記憶資源は、例えば、ストレージ装置（例えばディスクアレイ装置）である。

以上、本発明の幾つかの実施例を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。

１０：管理サーバ

Claims (15)

1. 複数のノード装置と、
   前記複数のノード装置で発生するイベントを検知する管理システムと、
   を備える計算機システムであって、
   前記管理システムは、イベント情報と、メタルール情報と、障害履歴情報と、を格納し、
   前記イベント情報は、前記発生したイベントの発生元ノード装置を特定する情報と、前記発生したイベントの種別と、を示すイベントエントリを含み、
   前記メタルール情報は、ノード装置で潜在的に発生する可能性のある潜在イベントの種別と、前記潜在イベントの種別に対応するイベントが発生した場合に根本原因と特定可能なイベントの種別とを示すメタルール、を含み、
   前記障害履歴情報は、復旧方法を示す情報及び前記復旧方法が対応する前記メタルールを識別する情報を含む障害履歴エントリ、を含み、
   前記管理システムは：
   （Ａ）前記メタルール情報に基づき、前記イベント情報に格納した前記イベントエントリで特定される第一のイベントの根本原因である第一の原因イベントを特定し、前記第一の原因イベントの特定に用いた第一のメタルールを特定し；
   （Ｂ）前記第一の原因イベントから復旧する方法である第一の復旧方法を、前記入力装置を介して受信し、前記第一の復旧方法に基づいて、前記障害履歴情報に前記第一のメタルールに対応する第一の障害履歴エントリを追加し；
   （Ｃ）前記メタルール情報に基づき、前記イベント情報に格納した前記イベントエントリで特定される第二のイベントの根本原因である第二の原因イベントを特定し、第二の原因イベントの特定に用いた第二のメタルールを特定し；
   （Ｄ）前記障害履歴情報に基づき、前記第二のメタルールに対応する所定の障害履歴エントリを特定し、
   （Ｘ）前記第二の原因イベントに関する情報を、前記第二のイベントの根本原因として表示し；
   （Ｙ）前記所定の障害履歴エントリに基づき、前記第二の原因イベントからの復旧方法を表示する、
   ことを特徴とした計算機システム。
2. 請求項１記載の計算機システムであって、
   前記障害履歴エントリは、復旧方法を適用したノード装置の識別子を含み、
   前記管理システムは：
   （Ｚ）前記所定の障害履歴エントリが示すノード装置の識別子を、前記（Ｙ）の前記所定の障害履歴エントリが示す復旧方法を適用したノード装置の識別子として表示する、
   ことを特徴とした計算機システム。
3. 請求項２記載の計算機システムであって、
   前記第一のメタルールと前記第二のメタルールが同一の場合、前記（Ｙ）の前記所定の障害履歴エントリが示す復旧方法は、前記第一の障害履歴エントリが示す第一の復旧方法であり、
   前記第一の原因イベントの発生元ノード装置と前記第二の原因イベントの発生元ノード装置は異なるノード装置の場合、前記管理システムは：
   （ａ）前記（Ｘ）の前記第二の原因イベントに関する情報の表示として、前記第二の原因イベントの発生元ノード装置の識別子を含む情報を表示し、
   （ｂ）前記（Ｚ）の前記所定の障害履歴エントリが示すノード装置の識別子の表示として、前記第一の原因イベントの発生元ノード装置の識別子を表示する、
   ことを特徴とした計算機システム。
4. 請求項２記載の計算機システムであって、
   前記（Ｄ）の特定は：
   （Ｄ１）前記第二のメタルールと同一のメタルールを示す前記障害履歴エントリを選択し、
   （Ｄ２）前記（Ｄ１）により選択された障害履歴エントリの数が第一の閾値未満の場合は、前記障害履歴エントリが対応するメタルールと、前記第二のメタルールとのマッチング率に基づいて前記所定の障害履歴エントリを特定し、
   （Ｄ３）前記（Ｄ１）により選択された障害履歴エントリを前記所定の障害履歴エントリと特定する、
   ことを特徴とした計算機システム。
5. 請求項４記載の計算機システムであって、
   前記記憶資源は、前記複数のノード装置の構成設定情報を格納し、
   前記障害履歴エントリは、前記複数のノード装置の当該エントリ作成時点に対応する過去の構成設定情報を含み、
   前記（Ｄ）の特定は：
   （Ｄ４）前記（Ｄ１）により選択された障害履歴エントリの数が第二の閾値以上の場合は、前記障害履歴エントリに含まれる前記過去の構成設定情報と、前記構成設定情報とのマッチング率に基づいて、前記所定の障害履歴エントリを特定する、
   ことを特徴とした計算機システム。
6. 請求項５記載の計算機システムであって、
   前記記憶資源は、構成設定情報の項目についての重み値を示す重み情報を格納し、
   前記（Ｄ４）の特定は、前記重み情報に基づいて行われる、
   ことを特徴とした計算機システム。
7. 請求項１記載の計算機システムであって、
   前記（Ｂ）の第一の復旧方法は、前記第一の原因イベントの発生元ノード装置の識別子を含まない復旧方法であるメタ復旧方法であり、
   前記（Ｙ）の前記第二の原因イベントからの復旧方法の表示は、前記メタ復旧方法と前記第二の原因イベントの発生元ノード装置の識別子との表示である、
   ことを特徴とした計算機システム。
8. 複数のノード装置と通信するインターフェースと、
   前記インターフェースを介して、前記複数のノード装置で発生するイベントを検知するプロセッサと、
   イベント情報と、メタルール情報と、障害履歴情報と、を格納する記憶資源と、
   前記複数のノード装置についての情報を表示する表示装置と、
   入力装置と、
   を備え、
   前記イベント情報は、前記発生したイベントの発生元ノード装置を特定する情報と、前記発生したイベントの種別と、を示すイベントエントリを含み、
   前記メタルール情報は、ノード装置で潜在的に発生する可能性のある潜在イベントの種別と、前記潜在イベントの種別に対応するイベントが発生した場合に根本原因と特定可能なイベントの種別とを示すメタルール、を含み、
   前記障害履歴情報は、復旧方法を示す情報及び前記復旧方法が対応する前記メタルールを識別する情報を含む障害履歴エントリ、を含み、
   前記プロセッサは：
   （Ａ）前記メタルール情報に基づき、前記イベント情報に格納した前記イベントエントリで特定される第一のイベントの根本原因である第一の原因イベントを特定し、前記第一の原因イベントの特定に用いた第一のメタルールを特定し；
   （Ｂ）前記第一の原因イベントから復旧する方法である第一の復旧方法を、前記入力装置を介して受信し、前記第一の復旧方法に基づいて、前記障害履歴情報に前記第一のメタルールに対応する第一の障害履歴エントリを追加し；
   （Ｃ）前記メタルール情報に基づき、前記イベント情報に格納した前記イベントエントリで特定される第二のイベントの根本原因である第二の原因イベントを特定し、第二の原因イベントの特定に用いた第二のメタルールを特定し；
   （Ｄ）前記障害履歴情報に基づき、前記第二のメタルールに対応する所定の障害履歴エントリを特定し、
   前記表示装置は：
   （Ｘ）前記第二の原因イベントに関する情報を、前記第二のイベントの根本原因として表示し；
   （Ｙ）前記所定の障害履歴エントリに基づき、前記第二の原因イベントからの復旧方法を表示する、
   ことを特徴とした管理システム。
9. 請求項８記載の管理システムであって、
   前記障害履歴エントリは復旧方法を適用したノード装置の識別子を含み、
   前記表示装置は：
   （Ｚ）前記所定の障害履歴エントリが示すノード装置の識別子を、前記（Ｙ）の前記所定の障害履歴エントリが示す復旧方法を適用したノード装置の識別子として表示する、
   ことを特徴とした管理システム。
10. 請求項９記載の管理システムであって、
    前記第一の原因イベントの発生元ノード装置と前記第二の原因イベントの発生元ノード装置は異なるノード装置の場合、前記表示装置は：
    （ａ）前記（Ｘ）の前記第二の原因イベントに関する情報の表示として、前記第二の原因イベントの発生元ノード装置の識別子を含む情報を表示し、
    （ｂ）前記（Ｚ）の前記所定の障害履歴エントリが示すノード装置の識別子の表示として、前記第一の原因イベントの発生元ノード装置の識別子を表示する、
    ことを特徴とした管理システム。
11. 請求項９記載の管理システムであって、
    前記（Ｄ）の特定は：
    （Ｄ１）前記第二のメタルールと同一のメタルールのを示す前記障害履歴エントリを選択し、
    （Ｄ２）前記（Ｄ１）により選択された障害履歴エントリの数が第一の閾値未満の場合は、前記障害履歴エントリが対応するメタルールと、前記第二のメタルールとのマッチング率に基づいて前記所定の障害履歴エントリを特定し、
    （Ｄ３）前記（Ｄ１）により選択された障害履歴エントリを前記所定の障害履歴エントリと特定する、
    ことを特徴とした管理システム。
12. 請求項１１記載の管理システムであって、
    前記記憶資源は、前記複数のノード装置の構成設定情報を格納し、
    前記障害履歴エントリは、前記複数のノード装置の当該エントリ作成時点に対応する過去の構成設定情報を含み、
    前記（Ｄ）の特定は：
    （Ｄ４）前記（Ｄ１）により選択された障害履歴エントリの数が第二の閾値以上の場合は、前記障害履歴エントリに含まれる前記過去の構成設定情報と、前記構成設定情報とのマッチング率に基づいて、前記所定の障害履歴エントリを特定する、
    ことを特徴とした管理システム。
13. 請求項１２記載の管理システムであって、
    前記記憶資源は、構成設定情報の項目についての重み値を示す、重み情報を格納し、
    前記（Ｄ４）の特定は、前記重み情報に基づいて行われる、
    ことを特徴とした管理システム。
14. 請求項８記載の管理システムであって、
    前記（Ｂ）の第一の復旧方法は、前記第一の原因イベントの発生元ノード装置の識別子を含まない復旧方法であるメタ復旧方法であり、
    前記（Ｙ）の前記第二の原因イベントからの復旧方法の表示は、前記メタ復旧方法と前記第二の原因イベントの発生元ノード装置の識別子との表示である、
    ことを特徴とした管理システム。
15. 複数のノード装置を管理する管理システムの管理方法であって、
    前記管理システムは、複数のノード装置で発生しうるイベントについて、根本原因となる事象を特定するメタルールと、メタルールに対応させた障害復旧方法と、を有し、
    前記管理システムは、管理サーバが検知したイベントの根本原因となる原因イベントと、前記原因イベントからの復旧方法と、を表示する。
    ことを特徴とした管理システムの管理方法。

Images