JP5504670B2 - システム管理装置、システム管理プログラム及びシステム管理方法 - Google Patents

Description

本発明は、管理対象において障害が発生した場合における、システム管理者等の作業者によるトラブル対処作業を支援するシステム管理装置、システム管理プログラム及びシステム管理方法に関する。

従来、情報処理システムにおいて障害が発生した場合、システム管理者等の作業者は、自身が保有するノウハウに基づいて対処をおこなってきた。これらのノウハウは、個別の問題に対処した経験に基づいて各作業者ごとに蓄積され、十分に共有されていないことが多かった。そのため、作業者ごとに、障害への対応レベルに大きな差が生じる場合があった。

このような個人的なスキルへの依存を解消し、障害に対する対処の迅速化や均一化を実現するため、過去に行ったトラブル対処の手順を知識化してデータベースに登録しておく技術が知られている。

例えば、図１７に示すように、作業者Ａは、情報処理システムにおいて発生した新規障害に対して自身のノウハウに基づき対処を行った場合、当該障害により起きた症状や、障害発生箇所特定までの切り分け手順、障害への対処方法等をトラブル事例としてトラブル事例ＤＢに登録する（ステップＳ０１）。トラブル事例ＤＢに登録されたトラブル事例は、トラブル対処知識として知識化されトラブル対処知識ＤＢに登録される（ステップＳ０２）。

その後、上記と同様の症状が発生した場合、作業者Ｂは、トラブル対処知識ＤＢに対してその症状を入力することにより（ステップＳ０３）、トラブル対処知識ＤＢから、障害の原因やその対処の手順に関する情報を得ることができる（ステップＳ０４）。

ここで、作業者Ｂがトラブル対処知識ＤＢを用いて行うトラブル対処作業の一例について説明する。図１８に示すように、作業者Ｂは、ＰＣ(Personal Computer)等のディスプレイに表示された所定のウィンドウ７００の入力欄７５０に、障害によって起きた症状「servlet_a:com.fujitsu.labs…」を入力する（ステップＳ１１）。すると、ウィンドウ７００には、例えば「資料“ＱＱＱ”の値を入力して下さい。」など、次に作業者Ｂが行うべき作業手順が表示される。そして、作業者Ｂは、ウィンドウ７００に表示された指示に従い、入力欄７５０に資料“ＱＱＱ”の値を入力する（ステップＳ１２）。このような操作を繰り返すことにより、作業者Ｂは、最終的に、「障害が発生したサーブレットが使用しているＤＢテーブルのパラメータＸＸＸを０にしてください。」という対処方法を得ることができる（ステップＳ１３）。

特開平５−３０７４８４号公報

しかしながら、上述したような従来技術には、トラブル対処作業の効率性に関して改善の余地があった。

例えば、従来技術では、トラブル対処知識に基づき指示される対処方法が抽象的であった。すなわち、従来技術では、例えば「障害が発生したサーブレットが使用しているＤＢテーブルのパラメータＸＸＸを０にしてください。」といった抽象的な指示しかなされず、対処すべき機器やプログラム等を具体的に特定するような指示はなされなかった。

そのため、例えば図１９に示すように、ＰＣ１〜４にそれぞれサーブレット１〜４がインストールされている場合において上記の指示を受け取った場合、作業者は、どのＰＣのサーブレットが障害発生箇所であるかを特定し、さらに、当該サーブレットが使用するＤＢテーブルを特定する必要がある。したがって、例えばサーブレット４が障害発生箇所であり、ＤＢテーブル６が対処すべきＤＢテーブルである場合に、作業者がＰＣ１から順に調べていった場合、障害発生箇所を特定するまでに多くの時間を費やすこととなる。このように、トラブル対処知識に基づき指示される対処方法が抽象的である場合、障害切り分けに時間がかかるおそれがある。

また、従来技術において、作業者は、対処作業の最終段階（図１８のステップＳ１３）に到達しなければ対処すべき対象が分からなかった。すなわち、作業者には、図２０に示すように、例えば「資料“ＱＱＱ”の値を入力して下さい。」というようなトラブル対処作業の各段階における指示のみが与えられていた。そのため、作業者は、最終的な対処方法が指示されるまで、どの機器がトラブル対処の対象（すなわち、障害発生箇所）となるかがわからないまま作業を進めなければならず、見通しを持った作業ができなかった。

開示の技術は、上記に鑑みてなされたものであって、トラブル対処作業の効率性を向上させることのできるシステム管理装置、システム管理プログラム及びシステム管理方法を提供することを目的とする。

本願の開示するシステム管理装置、システム管理プログラム及びシステム管理方法は、一つの態様において、管理対象に含まれる構成要素を識別する識別情報と、各構成要素の種別を表す構成種別情報とを対応付けて構成要素情報として記憶する構成要素情報記憶手段と、前記構成要素情報記憶手段に記憶されている識別情報と、該識別情報によって識別される構成要素と関連を有する構成要素を識別するための識別情報と、該関連の種別を表す関連種別情報とを対応付けて関連要素情報として記憶する関連要素情報記憶手段と、障害を原因とする症状が観測された構成要素から該障害が発生した構成要素までの間に介在する各構成要素の構成種別情報と各構成要素間の関連の関連種別情報とが、前記症状が観測された構成要素から前記障害が発生した構成要素までの間に介在する順序で指定された検索式を、該症状の内容を表す症状内容情報と対応付けて記憶する対処情報記憶手段と、症状が観測された構成要素に対応する構成要素情報と該症状の内容を表す症状内容情報とを取得する症状取得手段と、前記症状取得手段によって取得された症状の内容と一致する症状内容情報と対応付けられた前記検索式を前記対処情報記憶手段から取得する検索式取得手段と、前記検索式取得手段により取得した検索式に基づく前記構成要素情報記憶手段及び前記関連要素情報記憶手段に対する検索処理を、前記症状取得手段により取得した構成要素情報を始点として実行し、特定された構成要素を前記観測された症状の原因となる障害の発生箇所の候補として抽出する障害発生箇所候補抽出手段とを備える。

本願の開示するシステム管理装置、システム管理プログラム及びシステム管理方法の一つの態様によれば、トラブル対処作業の効率性を向上させることができるという効果を奏する。

図１−１は、障害発生箇所候補を特定する処理を説明するための図である。 図１−２は、トラブル事例情報に基づき生成したクエリ式を対処情報記憶部へ登録する処理を説明するための図である。 図２は、本実施例にかかるシステム管理装置の構成を示すブロック図である。 図３は、ＣＭＤＢに記憶される構成情報の一例を示す図である。 図４は、図３に示した構成情報に基づくイメージ図である。 図５は、本実施例にかかる事例情報記憶部の一例を示す図である。 図６は、本実施例にかかる対処情報記憶部の一例を示す図である。 図７は、関連経路情報生成処理について説明するための図である。 図８−１は、ＣＩ３００ｈおよびＣＩ３００ｇ間の関連経路情報のデータ構成の一例を示す図である。 図８−２は、ＣＩ３００ｈおよびＣＩ３００ｃ間の関連経路情報のデータ構成の一例を示す図である。 図９−１は、図８−１に示す関連経路情報に基づき生成されるクエリ式の一例を示す図である。 図９−２は、図８−２に示す関連経路情報に基づき生成されるクエリ式の一例を示す図である。 図１０−１は、図９−１に示すクエリ式に基づく障害発生箇所候補抽出処理を説明するための図である。 図１０−２は、図９−２に示すクエリ式に基づく障害発生箇所候補抽出処理を説明するための図である。 図１１は、本実施例にかかる対処方法登録処理の処理手順を示すフローチャートである。 図１２は、本実施例にかかる症状観測ＣＩ特定処理の処理手順を示すフローチャートである。 図１３は、本実施例にかかる障害発生ＣＩ特定処理の処理手順を示すフローチャートである。 図１４は、本実施例にかかる障害発生箇所候補抽出処理の処理手順を示すフローチャートである。 図１５は、トラブル対処作業の操作画面の一例を示す図である。 図１６は、システム管理プログラムを実行するコンピュータを示す図である。 図１７は、従来技術を説明するための図である。 図１８は、作業者がトラブル対処知識ＤＢを用いて行うトラブル対処作業の一例を示す図である。 図１９は、指示される対処方法が抽象的であることによる弊害を説明するための図である。 図２０は、従来における作業者への指示の内容を示す図である。

以下に、本願の開示するシステム管理装置、システム管理プログラム及びシステム管理方法の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

[１．システム管理方法について]
本実施例にかかるシステム管理方法は、管理対象である情報処理システムにおいて過去に発生した障害の障害発生箇所と該障害を原因として観測された症状の症状観測箇所との因果関係を記憶しておき、同様の症状が観測された場合に、該症状が観測された症状観測箇所との間で上記因果関係と同様の因果関係を有する機器等を障害発生箇所候補として特定する。以下に、本実施例にかかるシステム管理方法について概略的に説明する。図１−１は障害発生箇所候補を特定する処理を説明するための図、図１−２はトラブル事例情報に基づき生成したクエリ式を対処情報記憶部へ登録する処理を説明するための図である。

本実施例に係るシステム管理方法では、図１−１に示すように、ＣＭＤＢ(Configuration Management Database)１０に記憶された構成情報及び対処情報記憶部２２に記憶されたトラブル対処情報を用いて、障害発生箇所候補の特定を行う。ＣＭＤＢ１０は、管理対象となる情報処理システムの構成情報を一元管理する構成管理データベースであり、情報処理システムの構成情報として、構成要素情報と関連要素情報とを記憶する。

構成要素情報とは、情報処理システムに含まれるサーバや、ルータ、アプリケーション等の構成要素に関する情報であり、該構成要素を識別する識別情報と各構成要素の種別を表す構成種別情報とを含む。関連要素情報は、構成要素間の関連を表す情報であり、構成要素情報に含まれる識別情報と、該識別情報によって識別される構成要素と関連を有する構成要素を識別するための識別情報と、該関連の種別を表す関連種別情報とを含む。以下、構成要素情報をＣＩ(Configuration Item)といい、関連要素情報をリレーションという。

対処情報記憶部２２は、障害発生箇所候補の特定に必要な情報をトラブル対処情報として記憶するデータベースである。具体的には、対処情報記憶部２２は、障害発生箇所候補を特定するためのクエリ式２２１を、症状の内容を表す症状内容情報２２２や該症状の原因となる障害に対して行うべき対処の内容を表す対処内容情報２２３等と対応付けて記憶する。

ここで、クエリ式２２１は、ＣＭＤＢ１０に記憶されたＣＩの中から、障害発生箇所候補となる構成要素に対応するＣＩを特定するための検索式であり、障害を原因とする症状が観測された構成要素である症状観測要素と該障害が発生した構成要素である障害発生要素との因果関係が指定される。因果関係とは、症状観測要素のＣＩと障害発生要素のＣＩとがＣＭＤＢ１０に記憶された構成情報上において有する関連を示す。具体的には、クエリ式２２１には、構成要素の構成種別情報と各構成要素間の関連の関連種別情報とが所定の順序で指定される。例えば、関連種別情報「Ａ」→構成種別情報「Ｂ」→関連種別情報「Ａ」の順序で指定されたクエリ式は、始点となるＣＩから関連種別「Ａ」のリレーション→該リレーションにより始点となるＣＩとの関連が示される構成種別「Ｂ」のＣＩ→該ＣＩの識別情報を含む関連種別「Ａ」のリレーションを辿り特定されるＣＩを要求することを示す。

本実施例にかかるシステム管理方法は、図１−１に示すように、先ず、作業者の使用する端末装置２ｂから、症状観測要素に関する情報と該症状の内容を表す症状内容情報とをネットワークを介して取得する（ステップＳ１０１）。続いて、取得した症状内容情報と一致する症状内容情報２２２と対応付けられたクエリ式２２１を対処情報記憶部２２から取得する。そして、端末装置２から取得した症状観測要素に関する情報に対応するＣＩを始点として、取得したクエリ式に基づくＣＭＤＢ１０の検索処理を実行する（ステップＳ１０２）。かかる検索処理により、ＣＭＤＢ１０に記憶されたＣＩ及びリレーションのうち、取得したクエリ式に含まれる関連種別情報と同一の関連種別情報を含むリレーションとクエリ式に含まれる構成種別情報と同一の構成種別情報を含むＣＩとを指定された順序で辿り特定されたＣＩが障害発生箇所候補のＣＩとして抽出される（ステップＳ１０３）。

そして、本実施例にかかるシステム管理方法では、抽出した障害発生箇所候補のＣＩを、端末装置２から取得した症状内容情報と同一の症状内容情報と対応付けて対処情報記憶部２２に記憶された対処内容情報２２３とともに端末装置２へネットワークを介して送信する（ステップＳ１０４）。

このように、本実施例にかかるシステム管理方法では、情報処理システムにおいて発生した障害を原因とする症状が観測された場合に、該症状が観測された構成要素のＣＩを始点とし、該症状の内容を表す症状内容情報と対応付けられたクエリ式に基づきＣＭＤＢ１０の検索処理を実行し特定されるＣＩを障害発生箇所候補のＣＩとして抽出する。これにより、作業者は、症状に関する情報を入力することで、該症状の原因となる障害の発生箇所の候補に関する情報を取得することができ、トラブル対処作業の効率性を向上させることができる。

また、本実施例にかかるシステム管理方法では、情報処理システムにおいて新規に発生した障害に対して実施されたトラブル対処作業の作業履歴に基づき、上記クエリ式２２１を生成し、対処情報記憶部２２に登録する。

具体的には、情報処理システムにおいて新規な障害が発生した場合、端末装置２ａを使用する作業者は、症状が観測された構成要素や症状の内容等から、自身のノウハウに基づき障害発生箇所を特定して、対処を行う。このようなトラブル対処作業を行った場合、端末装置２ａには、該トラブル対処作業の作業履歴として、症状観測要素に関する情報、症状の内容を表す症状内容情報、障害発生要素に関する情報、障害発生要素に対して行った対処の内容を表す対処内容情報等が記憶される。

トラブル対処作業の作業履歴は、図１−２に示すように、端末装置２ａからネットワークを介して送信され、事例情報記憶部２１にトラブル事例情報として記憶される（ステップＳ１１１）。続いて、本実施例にかかるシステム管理方法では、事例情報記憶部２１に記憶された症状観測要素に関する情報及び障害発生要素に関する情報に基づき、クエリ式を生成する（ステップＳ１１２）。

具体的には、先ず、症状観測要素に対応するＣＩから障害発生要素に対応するＣＩまでの間に介在するリレーション及びＣＩを、リレーションに含まれる各構成要素の識別情報に基づき特定する。続いて、特定した各リレーション及び各ＣＩの関連種別情報及び構成種別情報を、各リレーション及び各ＣＩが症状観測要素に対応するＣＩから障害発生要素に対応するＣＩまでの間に介在する順序で指定したクエリ式を生成する。

例えば、症状観測要素のＣＩから障害発生要素のＣＩまでの間に、関連種別情報「Ａ」のリレーション、構成種別情報「Ｂ」のＣＩ及び関連種別「Ａ」のリレーションが、それぞれ関連種別情報「Ａ」のリレーション→構成種別情報「Ｂ」のＣＩ→関連種別「Ａ」のリレーションの順に介在しているとする。かかる場合、関連種別情報「Ａ」、構成種別情報「Ｂ」及び関連種別情報「Ａ」が、関連種別情報「Ａ」→構成種別情報「Ｂ」→関連種別情報「Ａ」の順序で指定されたクエリ式が生成される。そして、生成されたクエリ式は、事例情報記憶部２１に記憶された症状内容情報及び対処内容情報と対応付けて対処情報記憶部２２へ登録される（ステップＳ１１３）。

[２．システム管理装置の構成]
次に、本実施例にかかるシステム管理装置の構成について図面を参照して説明する。図２は本実施例にかかるシステム管理装置の構成を示すブロック図である。

図２に示すように、本実施例にかかるシステム管理装置１は、ＣＭＤＢ１０と、記憶部２０と、制御部３０とを有する。また、システム管理装置１は、ＬＡＮ(Local Area Network)等のネットワークを介して端末装置２ａ，２ｂと接続する。なお、端末装置２ａ，２ｂは、システム管理者等の作業者が使用する端末装置であり、専用のコンピュータのほか、一般的なパーソナルコンピュータ等を適用することができる。

[２．１．ＣＭＤＢの構成]
ＣＭＤＢ１０は、上述したように、情報処理システムの構成情報を一元管理する構成管理データベースであり、構成情報として、ＣＩおよびリレーションを記憶する。ここで、ＣＭＤＢ１０に記憶されるＣＩおよびリレーションについて説明する。図３はＣＭＤＢに記憶される構成情報のデータ構成の一例であり、図４は図３に示した構成情報に基づく情報処理システムの構成イメージ図である。

図３に示すように、ＣＭＤＢ１０は、ＣＩとして、「ＣＩ ｉｄ」と「ｉｔｅｍ」と「ｔｙｐｅ」と「ｎａｍｅ」と「ｉｐ」とを対応付けて記憶する。なお、「ｎａｍｅ」及び「ｉｐ」は、これらの情報が構成要素に割当てられている場合にのみ記憶される。

「ＣＩ ｉｄ」は、情報処理システムに含まれる構成要素を識別するための識別情報である。また、「ｉｔｅｍ」および「ｔｙｐｅ」は、構成種別情報に相当し、構成要素の種別を示す。「ｉｔｅｍ」は、ＣＭＤＢ１０において決められた構成要素の名称を表す要素名情報である。例えば、構成要素がＰＣである場合、該構成要素に対応するＣＩのｉｔｅｍは「Ｐｃ」となり、構成要素がアプリケーションである場合、該構成要素に対応するＣＩのｉｔｅｍは「Ａｐｐ」となる。

また、「ｔｙｐｅ」は、同一のｉｔｅｍを持つ構成要素同士をさらに分類するための分類情報であり、ＰＣの型番やＯＳ名、アプリケーション名等で表される。例えば、図３に示すように、ＣＩ ｉｄ「０ＳＯＩＷ３ＳＨ」とｉｔｅｍ「Ｐｃ」とｔｙｐｅ「ＦＭＤ２２」とを有するＣＩは、該ＣＩに対応する構成要素が、型番「ＦＭＤ２２」のＰＣであることを示す。また、ＣＩ ｉｄ「０２９ＫＫＺＨＥ」とｉｔｅｍ「Ａｐｐ」とｔｙｐｅ「ｍｙｓｑｌ」とを有するＣＩは、該ＣＩに対応する構成要素が、「ｍｙｓｑｌ」という名称のアプリケーションであることを示す。

また、「ｎａｍｅ」は、ｉｔｅｍ「Ｐｃ」を有する各構成要素に個別に与えられる名称である。例えば、ＣＩ ｉｄ「０ＳＯＩＷ３ＳＨ」を有するｉｔｅｍ「Ｐｃ」のＣＩには、ｎａｍｅ「ＨｏｓｔＡ」が対応付けられている。ｎａｍｅにより、同一のｔｙｐｅ「ＦＲＯＮＴＩＥＲ ＤＸ２００」を有するｉｔｅｍ「Ｐｃ」同士を識別することができる。

このように、ＣＭＤＢ１０は、管理対象に含まれる構成要素を識別するための識別情報と、各構成要素の種別を表す構成種別情報とを対応付けて構成要素情報として記憶する構成要素情報記憶手段として機能する。

また、ＣＭＤＢ１０は、リレーションとして、図３に示すように、Ｒｅｌａｔｉｏｎ ｉｄとｓｒｃとｄｓｔとｔｙｐｅとを対応付けて記憶する。Ｒｅｌａｔｉｏｎ ｉｄは、リレーションごとに割当てられる識別情報である。

ｓｒｃ（Source）は、リレーションにより関連が示される２つの構成要素のうち、主体となる構成要素を示す情報であり、ＣＩ ｉｄで表される。また、ｄｓｔ（Destination）は、リレーションにより関連が示される２つの構成要素のうち、客体となる構成要素を示す情報であり、ｓｒｃと同様、ＣＩ ｉｄで表される。例えば、ｓｒｃ「０ＳＯＩＷ３ＳＨ」とｄｓｔ「Ｈ３８ＦＨＺ０Ｓ」とが対応付けて記憶されているリレーションは、ｉｄ「０ＳＯＩＷ３ＳＨ」を有する構成要素がｉｄ「Ｈ３８ＦＨＺ０Ｓ」を有する構成要素に対して有している関連を示す。

また、「ｔｙｐｅ」は、主体となる構成要素が客体となる構成要素に対して有する関連の種別を示す関連種別情報である。例えば、「Ｈａｓ」は、主体となる構成要素が客体となる構成要素を所有していることを示す。また、「ＩｎｓｔａｌｌｅｄＯｎ」は、主体となる構成要素が客体となる構成要素にインストールされていることを示す。また、「ＣｏｎｎｅｃｔｅｄＴｏ」は、主体となる構成要素が客体となる構成要素と接続されていることを示す。

より具体的には、例えば、ｓｒｃ「０ＳＯＩＷ３ＳＨ」とｄｓｔ「Ｈ３８ＦＨＺ０Ｓ」とｔｙｐｅ「Ｈａｓ」とを有するリレーションは、ｉｄ「０ＳＯＩＷ３ＳＨ」を有するＰＣがｉｄ「Ｈ３８ＦＨＺ０Ｓ」を有するＯＳを所有していることを示す情報である。また、ｓｒｃ「Ｈ３８ＦＨＺ０Ｓ」とｄｓｔ「０ＳＯＩＷ３ＳＨ」とｔｙｐｅ「ＩｎｓｔａｌｌｅｄＯｎ」とを有するリレーションは、ｉｄ「Ｈ３８ＦＨＺ０Ｓ」を有するＯＳがｉｄ「０ＳＯＩＷ３ＳＨ」を有するＰＣにインストールされていることを示す情報である。

このように、ＣＭＤＢ１０は、構成要素の識別情報と、該構成要素の識別要素によって識別される構成要素と関連を有する構成要素を識別するための識別要素と、該関連の種別を表す関連種別情報とを対応付けて関連要素情報として記憶する関連要素情報記憶手段として機能する。

なお、以下では、図３に示すＣＩのうち、ＣＩ ｉｄ「０ＳＯＩＷ３ＳＨ」、ｉｔｅｍ「Ｐｃ」、ｔｙｐｅ「ＦＭＤ２２」及びｎａｍｅ「ＨｏｓｔＡ」を有するＣＩをＣＩ３００ａとし、ＣＩ ｉｄ「ＳＳ９ＩＨＫＥＲ」、ｉｔｅｍ「Ｐｃ」、ｔｙｐｅ「ＦＲＯＮＴＩＥＲ ＤＸ２００」及びｎａｍｅ「ＨｏｓｔＢ」を有するＣＩをＣＩ３００ｂとする。同様に、ＣＩ ｉｄ「Ｈ３８ＦＨＺ０Ｓ」、ｉｔｅｍ「Ｏｓ」、ｔｙｐｅ「Ｗｏｎ３ｋ」及びｉｐ「１９２．１６８．１．１０」を有するＣＩをＣＩ３００ｃとし、ＣＩ ｉｄ「９３Ｈ６ＳＫ８Ａ」、ｉｔｅｍ「Ｏｓ」、ｔｙｐｅ「ＷｏｎＳＰ」及びｉｐ「１９２．１６８.１．１１」を有するＣＩをＣＩ３００ｄとする。

同様に、ＣＩ ｉｄ「０２９ＫＫＺＨＥ」、ｉｔｅｍ「Ａｐｐ」及びｔｙｐｅ「ｍｙｓｑｌ」を有するＣＩをＣＩ３００ｅとし、ＣＩ ｉｄ「２Ｈ９ＪＩＩＨＹ」、ｉｔｅｍ「Ａｐｐ」及びｔｙｐｅ「ｔｏｍｃａｔ」を有するＣＩをＣＩ３００ｆとする。同様に、ＣＩ ｉｄ「ＨＲＥＩＯ９２８」、ｉｔｅｍ「Ｉｎｓｔａｎｃｅ」及びｔｙｐｅ「ｔａｂｌｅ_ａ」を有するＣＩをＣＩ３００ｇとし、ＣＩ ｉｄ「５Ｔ９８ＩＫＳＨ」、ｉｔｅｍ「Ｉｎｓｔａｎｃｅ」及びｔｙｐｅ「ｓｅｒｖｌｅｔ_ａ」を有するＣＩをＣＩ３００ｈとする。

また、以下において、図３に示すリレーションのうち、Ｒｅｌａｔｉｏｎ ｉｄ「０２ＪＯＩＵＪＭ」、ｓｒｃ「０ＳＯＩＷ３ＳＨ」、ｄｓｔ「Ｈ３８ＦＨＺ０Ｓ」及びｔｙｐｅ「Ｈａｓ」を有するリレーションをリレーション４００ａとし、Ｒｅｌａｔｉｏｎ ｉｄ「ＴＰＯ２１ＲＩＫ」、ｓｒｃ「Ｈ３８ＦＨＺ０Ｓ」、ｄｓｔ「０ＳＯＩＷ３ＳＨ」及びｔｙｐｅ「ＩｎｓｔａｌｌｅｄＯｎ」で示すリレーションをリレーション４００ｂとする。

同様に、Ｒｅｌａｔｉｏｎ ｉｄ「０９ＡＷＩＪＭＡ」、ｓｒｃ「ＳＳ９ＩＨＫＥＲ」、ｄｓｔ「9３Ｈ６ＳＫ８Ａ」及びｔｙｐｅ「Ｈａｓ」を有するリレーションをリレーション４００ｃとし、Ｒｅｌａｔｉｏｎ ｉｄ「ＨＫＥ９２８ＵＨ」、ｓｒｃ「９３Ｈ６ＳＫ８Ａ」、ｄｓｔ「ＳＳ９ＩＨＫＥＲ」及びｔｙｐｅ「ＩｎｓｔａｌｌｅｄＯｎ」を有するリレーションをリレーション４００ｄとする。同様に、Ｒｅｌａｔｉｏｎ ｉｄ「ＪＹ９Ｗ８４ＩＩ」、ｓｒｃ「Ｈ３８ＦＨＺ０Ｓ」、ｄｓｔ「９３Ｈ６ＳＫ８Ａ」及びｔｙｐｅ「ＣｏｎｎｅｃｔｅｄＴｏ」を有するリレーションをリレーション４００ｅとする。

同様に、Ｒｅｌａｔｉｏｎ ｉｄ「ＩＥＪＪＢＧＢ０」、ｓｒｃ「Ｈ３８ＦＨＺ０Ｓ」、ｄｓｔ「０２９ＫＫＺＨＥ」及びｔｙｐｅ「Ｈａｓ」を有するリレーションをリレーション４００ｆとし、Ｒｅｌａｔｉｏｎ ｉｄ「４９ＡＯ２ＫＡＷ」、ｓｒｃ「０２９ＫＫＺＨＥ」、ｄｓｔ「Ｈ３８ＦＨＺ０Ｓ」及びｔｙｐｅ「ＩｎｓｔａｌｌｅｄＯｎ」を有するリレーションをリレーション４００ｇとする。同様に、Ｒｅｌａｔｉｏｎ ｉｄ「Ｑ０９Ｒ５ＩＫＳ」、ｓｒｃ「９３Ｈ６ＳＫ８Ａ」、ｄｓｔ「２Ｈ９ＪＩＩＨＹ」及びｔｙｐｅ「Ｈａｓ」を有するリレーションをリレーション４００ｈとし、Ｒｅｌａｔｉｏｎ ｉｄ「０３６７ＤＨＲＪ」、ｓｒｃ「２Ｈ９ＪＩＩＨＹ」、ｄｓｔ「９３Ｈ６ＳＫ８Ａ」及びｔｙｐｅ「ＩｎｓｔａｌｌｅｄＯｎ」を有するリレーションをリレーション４００ｉとする。

同様に、Ｒｅｌａｔｉｏｎ ｉｄ「２３ＫＤ９９ＥＵ」、ｓｒｃ「０２９ＫＫＺＨＥ」、ｄｓｔ「ＨＲＥＩＯ９２８」及びｔｙｐｅ「Ｈａｓ」を有するリレーションをリレーション４００ｊとし、Ｒｅｌａｔｉｏｎ ｉｄ「８７ＥＵＤＨＷＥ」、ｓｒｃ「ＨＲＥＩＯ９２８」、ｄｓｔ「０２９ＫＫＺＨＥ」及びｔｙｐｅ「ＤｅｐｌｏｙｅｄＯｎ」を有するリレーションをリレーション４００ｋとする。

同様に、Ｒｅｌａｔｉｏｎ ｉｄ「ＭＪＵＹＥＧＣＸ」、ｓｒｃ「２Ｈ９ＪＩＩＨＹ」、ｄｓｔ「５Ｔ９８ＩＫＳＨ」及びｔｙｐｅ「Ｈａｓ」を有するリレーションをリレーション４００ｌとし、Ｒｅｌａｔｉｏｎ ｉｄ「２ＹＤＢＩ９８Ａ」、ｓｒｃ「５Ｔ９８ＩＫＳＨ」、ｄｓｔ「２Ｈ９ＪＩＩＨＹ」及びｔｙｐｅ「ＤｅｐｌｏｙｅｄＯｎ」を有するリレーションをリレーション４００ｍとする。同様に、Ｒｅｌａｔｉｏｎ ｉｄ「ＹＩＲＵＥＴＷＧ」、ｓｒｃ「５Ｔ９８ＩＫＳＨ」、ｄｓｔ「ＨＲＥＩＯ９２８」及びｔｙｐｅ「Ｕｓｅ」を有するリレーションをリレーション４００ｎとする。

ここで、図３に示した構成情報に基づく情報処理システムの構成イメージ図を図４に示す。図４に示すように、ＣＭＤＢ１０に記憶されたＣＩ３００ａ〜３００ｄにより、情報処理システムに、それぞれ型番「ＦＭＤ２２」のＰＣ、型番「ＦＲＯＮＴＩＥＲ ＤＸ２００」のＰＣ、「Ｗｏｎ３ｋ」という分類のＯＳ、「ＷｏｎＳＰ」という分類のＯＳが含まれることが示される。同様に、ＣＩ３００ｅ〜３００ｈにより、情報処理システムに、それぞれ「ｍｙｓｑｌ」という分類のアプリケーション、「ｔｏｍｃａｔ」という分類のアプリケーション、「ｔａｂｌｅ＿ａ」という分類のインスタンス、「ｓｅｒｖｌｅｔ＿ａ」という分類のインスタンスが含まれることが示される。

また、ＣＭＤＢ１０に記憶されたリレーション４００ａにより、ＣＩ３００ａで表されるＰＣがＣＩ３００ｃで表されるＯＳを所有することが示され、リレーション４００ｂにより、ＣＩ３００ｃで表されるＯＳがＣＩ３００ａで表されるＰＣにインストールされていることが示される。同様に、リレーション４００ｃにより、ＣＩ３００ｂで表されるＰＣがＣＩ３００ｄで表されるＯＳを所有することが示され、リレーション４００ｄにより、ＣＩ３００ｄで表されるＯＳがＣＩ３００ｂで表されるＰＣにインストールされていることが示される。同様に、リレーション４００ｅにより、ＣＩ３００ｃで表されるＯＳがＣＩ３００ｄで表されるＯＳと接続していることが示される。

同様に、リレーション４００ｆにより、ＣＩ３００ｃで表されるＯＳがＣＩ３００ｅで表されるアプリケーションを所有することが示され、リレーション４００ｇにより、ＣＩ３００ｅで表されるアプリケーションがＣＩ３００ｃで表されるＯＳにインストールされていることが示される。同様に、リレーション４００ｈにより、ＣＩ３００ｄで表されるＯＳがＣＩ３００ｆで表されるアプリケーションを所有することが示され、リレーション４００ｉにより、ＣＩ３００ｆで表されるアプリケーションがＣＩ３００ｄで表されるＯＳにインストールされていることが示される。

同様に、リレーション４００ｊにより、ＣＩ３００ｅで表されるアプリケーションがＣＩ３００ｇで表されるインスタンスを所有することが示され、リレーション４００ｋにより、ＣＩ３００ｇで表されるインスタンスがＣＩ３００ｅで表されるアプリケーションにより実行されることが示される。同様に、リレーション４００ｌにより、ＣＩ３００ｆで表されるアプリケーションがＣＩ３００ｈで表されるインスタンスを所有することが示され、リレーション４００ｍにより、ＣＩ３００ｈで表されるインスタンスがＣＩ３００ｆで表されるアプリケーションにより実行されることが示される。同様に、リレーション４００ｎにより、ＣＩ３００ｈで表されるインスタンスがＣＩ３００ｇで表されるインスタンスを使用することが示される。

また、ＣＩ３００ａに含まれるｎａｍｅ「ＨｏｓｔＡ」及びリレーション４００ａ，４００ｆ，４００ｊに含まれるｔｙｐｅ「Ｈａｓ」により、ＣＩ３００ｃで表されるＯＳ「Ｗｏｎ３ｋ」とＣＩ３００ｅで表されるアプリケーション「ｍｙｓｑｌ」とＣＩ３００ｇで表されるインスタンス「ｔａｂｌｅ＿ａ」とが、ＣＩ３００ａで表されるｎａｍｅ「ＨｏｓｔＡ」のＰＣに含まれることが示される。同様に、ＣＩ３００ｂに含まれるｎａｍｅ「ＨｏｓｔＢ」及びリレーション４００ｃ，４００ｈ，４００ｌに含まれるｔｙｐｅ「Ｈａｓ」により、ＣＩ３００ｄで表されるＯＳ「ＷｏｎＳＰ」とＣＩ３００ｆで表されるアプリケーション「ｔｏｍｃａｔ」とＣＩ３００ｈで表されるインスタンス「ｓｅｒｖｌｅｔ＿ａ」とが、ＣＩ３００ａで表されるｎａｍｅ「ＨｏｓｔＢ」のＰＣに含まれることが示される。

[２．２．記憶部の構成]
記憶部２０は、制御部３０による各種処理に必要なデータやプログラムを格納する。特に、記憶部２０は、事例情報記憶部２１と対処情報記憶部２２とを有する。事例情報記憶部２１は、端末装置２ａを用いて行われたトラブル対処作業の作業履歴に基づくトラブル事例情報を記憶する。本実施例にかかる事例情報記憶部２１の一例を図５に示す。

図５に示すように、事例情報記憶部２１は、「ＩＤ」と、「観測日時」と、「症状」と、「調査」と、「対処」に関する情報を記憶する。「ＩＤ」は、事例情報記憶部２１に登録されたトラブル事例を識別するための識別情報である。「観測日時」は、障害が原因で観測された症状の観測日時である。「症状」は、観測された症状についての情報であり、症状観測箇所に関する情報と症状の内容に関する情報とを含む。症状観測箇所は、症状観測機器名と症状観測要素名とを含む。症状観測要素名は、症状が観測された構成要素の名称であり、該構成要素のｔｙｐｅで表される。症状観測機器名は、症状観測要素を所有する機器の名称であり、該機器に対応する構成要素のｎａｍｅで表される。また、症状の内容には、症状観測箇所において観測された症状の内容が記憶される。

また、「調査」は、トラブル対処作業において行った調査についての情報であり、資料名と該資料の値とを項目として含む。「対処」は、障害に対して行った対処に関する情報であり、障害発生箇所に関する項目と対処内容に関する項目とを含む。障害発生箇所は、障害が発生した構成要素のＣＩ ｉｄ及びｔｙｐｅで表される。また、対処内容には、障害に対して行った対処の内容が記憶される。なお、障害発生箇所として記憶されるＣＩ ｉｄ及びｔｙｐｅは、トラブル対処作業の作業履歴に含まれる障害発生機器名と障害発生要素名とに基づき、後述する事例登録部３１によりＣＭＤＢ１０から抽出される情報である。

例えば、「ＳＵＰ０１２３４」というＩＤで識別されるトラブル事例情報は、２００８年１０月３０日１９時３７分に、ｎａｍｅ「ＨｏｓｔＢ」が割当てられた機器が所有するｔｙｐｅ「ｓｅｒｖｌｅｔ＿ａ」の構成要素において、データベースセッションがクローズされるという症状が観測されたことを示す。また、同情報は、上記症状の原因となった障害の発生箇所が、ｎａｍｅ「ＨｏｓｔＡ」の機器が所有するｔｙｐｅ「ｔａｂｌｅ＿ａ」の構成要素であること、該障害発生に対して「接続先ＤＢサーバのテーブルのパラメータＸＸＸの値を０に設定」するという対処を行ったことを示す。また、同情報は、上記障害発生箇所を特定するため、「８６４００」の値を持つ「接続先ＤＢサーバのＯＳのＴＣＰ＿ＩＰパラメータＸＸＸ＿ＴＩＭＥＯＵＴ」という資料を用いた調査を行ったことを示す。

対処情報記憶部２２は、情報処理システムにおいて観測された症状の原因となる障害に対してトラブル対処作業を行う場合に必要な情報をトラブル対処情報として記憶するデータベースである。本実施例にかかる対処情報記憶部２２の一例を図６に示す。

図６に示すように、対処情報記憶部２２は、「症状の内容」と「対処の内容」とを「障害発生箇所候補のクエリ式」と対応付けて記憶する。例えば、対処情報記憶部２２は、症状の内容「データベースセッションをクローズしました」と対処の内容「接続先ＤＢサーバのＯＳのＴＣＰ＿ｉｐパラメータＸＸＸ＿ＴＩＭＥＯＵＴの値を３６００に設定」に対応付けて、障害発生箇所候補のクエリ式「%{this}/&DeployedOn/%App[type=‘tomcat’]/&InstalledOn/%Os[type=‘WonSP’]/&ConnectedTo/%Os[type=‘Won3k’]」を記憶する。かかるクエリ式は、症状観測要素から障害発生要素までの間に介在する各構成要素の構成種別情報と各構成要素間の関連の関連種別情報とが、症状観測要素から障害発生要素までの間に介在する順序で指定された検索式であり、詳細については後述する。

このように、対処情報記憶部２２は、障害を原因とする症状が観測された構成要素から該障害が発生した構成要素までの間に介在する各構成要素の構成種別情報と各構成要素間の関連の関連種別情報とが、症状が観測された構成要素から障害が発生した構成要素までの間に介在する順序で指定された検索式を、該症状の内容を表す症状内容情報と対応付けて記憶する対処情報記憶手段に相当する。

[２．３．制御部の構成]
制御部３０は、システム管理システム全体を制御する制御部である。制御部３０は、事例登録部３１と、関連経路情報生成部３２と、クエリ生成部３３と、対処方法登録部３４と、対処検索部３５と、クエリ取得部３６と、障害発生箇所候補抽出部３７とを有する。

事例登録部３１は、端末装置２ａを用いて行われたトラブル対処作業の作業履歴に基づくトラブル事例情報を事例情報記憶部２１に登録する。ここで、事例登録部３１による事例登録処理について説明する。

先ず、情報処理システムにおいて新規な障害が発生した場合、端末装置２ａを使用する作業者は、症状観測箇所や症状の内容等から、自身のノウハウに基づき障害発生箇所を特定して、対処を行う。このようなトラブル対処作業を行った場合、端末装置２ａには、該トラブル対処作業の作業履歴として、症状の観測日時、症状観測機器名、症状観測要素名、症状の内容が記憶される。また、端末装置２ａには、該トラブル対処作業の作業履歴として、障害発生機器名、障害発生要素名、対処の内容、該トラブル対処作業において用いた資料の資料名、該資料の値等も記憶される。

上記トラブル対処作業を終えると、作業者は、端末装置２ａを用い、該トラブル対処作業の作業履歴に関する情報を事例登録部３１にネットワークを介して送信する。そして、事例登録部３１は、該作業履歴に関する情報を取得すると、作業履歴に含まれる上記各情報をＩＤと対応付けて事例情報記憶部２１に登録する。

関連経路情報生成部３２は、症状観測要素のＣＩから障害発生要素のＣＩまでの間に介在する関連要素情報に基づき、関連経路情報を生成する。具体的には、先ず、関連経路情報生成部３２は、事例情報記憶部２１から症状観測箇所に関する情報として記憶された症状観測機器名及び症状観測要素名と、障害発生箇所に関する情報として記憶された障害発生機器名及び障害発生要素名とを取出す。

続いて、関連経路情報生成部３２は、症状観測機器名及び症状観測要素名に基づき、症状観測要素のＣＩをＣＭＤＢ１０から抽出する。具体的には、関連経路情報生成部３２は、先ず、症状観測機器名として記憶されたｎａｍｅに基づき、ＣＭＤＢ１０と照合して症状観測機器のＣＩを特定する。例えば、症状観測機器名として記憶されたｎａｍｅが「ＨｏｓｔＢ」であった場合、関連経路情報生成部３２は、ｎａｍｅ「ＨｏｓｔＢ」を有するＣＩ３００ｂを症状観測機器のＣＩとして特定する。続いて、関連経路情報生成部３２は、特定したＣＩから、ｔｙｐｅ「Ｈａｓ」のリレーションによって結ばれるＣＩを辿り、症状観測要素名として記憶されたｔｙｐｅと同じｔｙｐｅを持つＣＩを症状観測箇所として抽出する。

例えば、症状観測要素名としてｔｙｐｅ「ｓｅｒｖｌｅｔ＿ａ」が記憶されていた場合、関連経路情報生成部３２は、ＣＩ３００ｂからｔｙｐｅ「Ｈａｓ」のリレーション４００ｃにより辿ることのできるＣＩ３００ｄのｔｙｐｅが「ｓｅｒｖｌｅｔ＿ａ」であるか否かを判定する。この場合、ＣＩ３００ｄのｔｙｐｅは、「ｓｅｒｖｌｅｔ＿ａ」ではないため、関連経路情報生成部３２は、さらに、ＣＩ３００ｄからｔｙｐｅ「Ｈａｓ」のリレーション４００ｈにより辿ることのできるＣＩ３００ｆのｔｙｐｅが「ｓｅｒｖｌｅｔ＿ａ」であるか否かを判定する。この場合、ＣＩ３００ｆのｔｙｐｅは、「ｓｅｒｖｌｅｔ＿ａ」ではないため、関連経路情報生成部３２は、さらに、ＣＩ３００ｆからｔｙｐｅ「Ｈａｓ」のリレーション４００ｌにより辿ることのできるＣＩ３００ｈのｔｙｐｅが「ｓｅｒｖｌｅｔ＿ａ」であるか否かを判定する。

そして、ＣＩ３００ｈのｔｙｐｅは「ｓｅｒｖｌｅｔ＿ａ」であるため、関連経路情報生成部３２は、ＣＩ３００ｈを症状観測箇所のＣＩとして抽出し、所定の記憶領域に記憶する。具体的には、関連経路情報生成部３２は、ＣＩ３００ｈのＣＩ ｉｄ「５Ｔ９８ＩＫＳＨ」を所定の記憶領域に記憶する。

続いて、関連経路情報生成部３２は、障害発生機器名及び障害発生要素名に基づき、障害発生要素のＣＩをＣＭＤＢ１０から抽出する。具体的には、関連経路情報生成部３２は、先ず、障害発生機器名として記憶されたｎａｍｅに基づき、ＣＭＤＢ１０と照合して障害発生機器のＣＩを特定する。例えば、障害発生機器名として記憶されたｎａｍｅが「ＨｏｓｔＡ」であった場合、関連経路情報生成部３２は、ｎａｍｅ「ＨｏｓｔＡ」を有するＣＩ３００ａを障害発生機器のＣＩとして特定する。続いて、関連経路情報生成部３２は、特定したＣＩから、ｔｙｐｅ「Ｈａｓ」のリレーションによって結ばれるＣＩを辿り、障害発生要素名として記憶されたｔｙｐｅと同じｔｙｐｅを持つ構成要素を障害発生箇所として抽出する。

例えば、障害発生要素名としてｔｙｐｅ「ｔａｂｌｅ＿ａ」が記憶されている場合、関連経路情報生成部３２は、ＣＩ３００ａからｔｙｐｅ「Ｈａｓ」のリレーション４００ａにより辿ることのできるＣＩ３００ｃのｔｙｐｅが「ｔａｂｌｅ＿ａ」であるか否かを判定する。この場合、ＣＩ３００ｃのｔｙｐｅは、「ｔａｂｌｅ＿ａ」ではないため、関連経路情報生成部３２は、さらに、ＣＩ３００ｃからｔｙｐｅ「Ｈａｓ」のリレーション４００ｆにより辿ることのできるＣＩ３００ｅのｔｙｐｅが「ｔａｂｌｅ＿ａ」であるか否かを判定する。この場合、ＣＩ３００ｅのｔｙｐｅは、「ｔａｂｌｅ＿ａ」ではないため、関連経路情報生成部３２は、さらに、ＣＩ３００ｅからｔｙｐｅ「Ｈａｓ」のリレーション４００ｊにより辿ることのできるＣＩ３００ｇのｔｙｐｅが「ｔａｂｌｅ＿ａ」であるか否かを判定する。

そして、ＣＩ３００ｇのｔｙｐｅは「ｔａｂｌｅ＿ａ」であるため、関連経路情報生成部３２は、ＣＩ３００ｇを障害発生箇所として抽出し、所定の記憶領域に記憶する。具体的には、関連経路情報生成部３２は、ＣＩ３００ｇのＣＩ ｉｄ「ＨＲＥＩ０９２８」を所定の記憶領域に記憶する。

続いて、関連経路情報生成部３２は、所定の領域に記憶した症状観測箇所のＣＩを始点とし、所定の領域に記憶した障害発生箇所のＣＩを終点とする関連経路情報を生成する。具体的には、関連経路情報生成部３２は、先ず、症状観測箇所のＣＩから障害発生箇所のＣＩまでの間に介在するリレーションを特定する。以下に、かかる関連経路情報生成部３２による関連経路情報生成処理について図面を参照して具体的に説明する。図７は、関連経路情報生成処理について説明するための図である。

例えば、所定の領域に記憶した症状観測箇所のＣＩがＣＩ３００ｈであり、障害発生箇所のＣＩがＣＩ３００ｇであったとすると、関連経路情報生成部３２は、ＣＩ３００ｈからＣＩ３００ｇまでの間に介在するリレーションを特定する。

具体的には、関連経路情報生成部３２は、ＣＭＤＢ１０を参照し、ＣＩ３００ｈを主体とする、すなわちｓｒｃ「５Ｔ９８ＩＫＳＨ」を有するリレーション４００ｍ，４００ｎを特定するとともに、各リレーション４００ｍ，４００ｎによりＣＩ３００ｈとの関連が示されるＣＩ３００ｆ，３００ｇを特定する。そして、特定したＣＩ３００ｆ，３００ｇが、ＣＩ ｉｄ「ＨＲＥＩ０９２８」を有するＣＩであるか否かを判定する。かかる場合において、ＣＩ３００ｇは、ＣＩ ｉｄ「ＨＲＥＩ０９２８」を有するＣＩであるため、関連経路情報生成部３２は、ＣＩ３００ｈからＣＩ３００ｇまでの間に介在するリレーションとして、リレーション４００ｎを取出す。

一方、ＣＩ３００ｆは、ＣＩ ｉｄ「ＨＲＥＩ０９２８」を有するＣＩではないため、関連経路情報生成部３２は、ＣＭＤＢ１０を参照して、ＣＩ３００ｆを主体とする、すなわちｓｒｃ「０２９ＫＫＺＨＥ」を有するリレーションの特定を行う。そして、特定されたリレーション４００ｉによりＣＩ３００ｆとの関連が示されるＣＩ３００ｄを特定し、特定したＣＩ３００ｄがＣＩ ｉｄ「ＨＲＥＩ０９２８」を有するＣＩであるか否かを判定する。かかる場合において、ＣＩ３００ｄは、ＣＩ ｉｄ「ＨＲＥＩ０９２８」を有するＣＩではないため、関連経路情報生成部３２は、ＣＭＤＢ１０を参照して、ＣＩ３００ｄを主体とする、すなわちｓｒｃ「９３Ｈ６ＳＫ８Ａ」を有するリレーションの特定を行う。

続いて、関連経路情報生成部３２は、特定されたリレーション４００ｄ，４００ｅによりＣＩ３００ｄとの関連が示されるＣＩ３００ｂ，３００ｃを特定し、特定したＣＩ３００ｂ，３００ｃがＣＩ ｉｄ「ＨＲＥＩ０９２８」を有するＣＩであるか否かを判定する。かかる場合において、ＣＩ３００ｂは、ＣＩ ｉｄ「ＨＲＥＩ０９２８」を有するＣＩではないため、関連経路情報生成部３２は、ＣＭＤＢ１０を参照して、ＣＩ３００ｂを主体とするリレーションの特定を行う。また、ＣＩ３００ｃも、ＣＩ ｉｄ「ＨＲＥＩ０９２８」を有するＣＩではないため、関連経路情報生成部３２は、ＣＭＤＢ１０を参照して、ＣＩ３００ｃを主体とするリレーションの特定を行う。

続いて、関連経路情報生成部３２は、特定されたリレーション４００ｂ，４００ｆによりＣＩ３００ｃとの関連が示されるＣＩ３００ａ，３００ｅを特定し、特定したＣＩ３００ａ，３００ｅがＣＩ ｉｄ「ＨＲＥＩ０９２８」、ｔｙｐｅ「ｔａｂｌｅ＿ａ」を有するＣＩであるか否かを判定する。かかる場合において、ＣＩ３００ａ，３００ｅのいずれもＣＩ ｉｄ「ＨＲＥＩ０９２８」、ｔｙｐｅ「ｔａｂｌｅ＿ａ」を有するＣＩではないため、関連経路情報生成部３２は、ＣＭＤＢ１０を参照して、ＣＩ３００ａ，３００ｅを主体とするリレーションの特定をそれぞれ行う。

続いて、関連経路情報生成部３２は、特定されたリレーション４００ｊによりＣＩ３００ｅとの関連が示されるＣＩ３００ｇを特定し、特定したＣＩ３００ｇがＣＩ ｉｄ「ＨＲＥＩ０９２８」を有するＣＩであるか否かを判定する。そして、ＣＩ３００ｇは、ＣＩ ｉｄ「ＨＲＥＩ０９２８」を有するＣＩであるため、関連経路情報生成部３２は、ＣＩ３００ｈからＣＩ３００ｇまでの間に介在するリレーションとして、リレーション４００ｍ，４００ｉ，４００ｅ，４００ｆ，４００ｊを取出す。

そして、関連経路情報生成部３２は、取出したリレーションに基づき関連経路情報を生成する。具体的には、関連経路情報生成部３２は、取出した各リレーションについて、当該リレーションのｔｙｐｅを抽出するとともに、当該リレーションのｄｓｔに基づき当該リレーションの客体となるＣＩのｉｔｅｍ及びｔｙｐｅをＣＭＤＢ１０から抽出する。

例えば、関連経路情報生成部３２は、取出したリレーション４００ｍのｔｙｐｅ「ＤｅｐｌｏｙｅｄＯｎ」を抽出するとともに、リレーション４００ｍのｄｓｔ「２Ｈ９ＪＩＨＹ」からＣＩ３００ｆを特定し、ＣＩ３００ｆのｉｔｅｍ「Ａｐｐ」およびｔｙｐｅ「ｔｏｍｃａｔ」を抽出する。関連経路情報生成部３２は、他のリレーション４００ｉ，４００ｅ，４００ｆ、４００ｊについても同様の処理を行う。そして、関連経路情報生成部３２は、各リレーション４００ｍ，４００ｉ，４００ｅ，４００ｆ，４００ｊに基づき抽出した情報を関連経路情報として対処情報記憶部２２の所定の記憶領域に記憶する。

また、関連経路情報生成部３２は、ＣＩ３００ｈからＣＩ３００ｇまでの間に介在するリレーションとして取出したリレーション４００ｎについても上記と同様の処理を行う。すなわち、関連経路情報生成部３２は、リレーション４００ｎから該リレーション４００ｎのｔｙｐｅ「Ｕｓｅ」を抽出する。また、リレーション４００ｎは、ｉｔｅｍ「Ｉｎｓｔａｎｃｅ」を有するＣＩ３００ｇを客体とするため、関連経路情報生成部３２は、該ＣＩ３００ｇのｉｔｅｍ「Ｉｎｓｔａｎｃｅ」のみをＣＭＤＢ１０から抽出する。そして、関連経路情報生成部３２は、抽出したリレーションのｔｙｐｅとＣＩのｉｔｅｍとを対応付けて関連経路情報として対処情報記憶部２２の所定の記憶領域に記憶する。

ここで、関連経路情報のデータ構成の一例として、ＣＩ３００ｈおよびＣＩ３００ｇ間の関連経路情報のデータ構成を図８−１に示す。図８−１は、ＣＩ３００ｈおよびＣＩ３００ｇ間の関連経路情報のデータ構成の一例を示す図である。なお、図７に示すように、ＣＩ３００ｈおよびＣＩ３００ｇ間の関連経路情報のうち、リレーション４００ｍ，４００ｉ，４００ｅ，４００ｆ，４００ｊに基づき生成した関連経路情報を関連経路情報Ｒ１とし、リレーション４００ｎに基づき生成した関連経路情報を関連経路情報Ｒ２とする。

図８−１に示すように、各関連経路情報Ｒ１，Ｒ２は、同一の症状観測箇所のＣＩおよび障害発生箇所のＣＩ間の関連経路情報ごとにまとめられ、他の症状観測箇所のＣＩおよび障害発生箇所のＣＩ間の関連経路情報と識別するための識別情報として「ＲｅｌａｔｉｏｎＰａｔｈ ｉｄ」が割当てられる。例えば、関連経路情報Ｒ１，Ｒ２には、ＲｅｌａｔｉｏｎＰａｔｈ ｉｄ「１」が割当てられている。

また、各関連経路情報Ｒ１，Ｒ２には、同一の症状観測箇所のＣＩおよび障害発生箇所のＣＩ間の関連を示す関連経路情報同士を識別するための識別情報として「Ｒｅｌｓ ｉｄ」が割当てられる。例えば、関連経路情報Ｒ１には、Ｒｅｌｓ ｉｄ「１」が割当てられ、関連経路情報Ｒ２には、Ｒｅｌｓ ｉｄ「２」が割当てられている。

また、関連経路情報Ｒ１には、各リレーション４００ｍ，４００ｉ，４００ｅ，４００ｆ，４００ｊに基づく各情報が、症状観測箇所のＣＩから障害発生箇所のＣＩまでの間に介在する順で記憶されている。すなわち、リレーション４００ｍ，４００ｉ，４００ｅ，４００ｆ，４００ｊは、症状観測箇所のＣＩ３００ｈから障害発生箇所のＣＩ３００ｇまでの間に、リレーション４００ｍ→４００ｉ→４００ｅ→４００ｆ→４００ｊの順で存在する。そして、関連経路情報Ｒ１には、リレーション４００ｍに基づき抽出された情報、リレーション４００ｉに基づき抽出された情報、リレーション４００ｅに基づき抽出された情報、リレーション４００ｆに基づき抽出された情報、リレーション４００ｊに基づき抽出された情報の順に記憶されている。

より具体的には、各リレーションに基づく情報には、「Ｐａｔｈ ｒｅｌｔｙｐｅ」と、「ｉｔｅｍ」と、「ｉｔｅｍｔｙｐｅ」とが含まれる。「Ｐａｔｈ ｒｅｌｔｙｐｅ」は、該リレーションのｔｙｐｅである。「ｉｔｅｍ」は、該リレーションに含まれるｄｓｔに基づき特定されたＣＩのｉｔｅｍである。「ｉｔｅｍｔｙｐｅ」は、該ＣＩのｔｙｐｅである。例えば、Ｒｅｌｓ ｉｄ「１」で識別される関連経路情報Ｒ１のうち、該関連経路情報Ｒ１の先頭に記憶されたリレーョン４００ｍに基づく情報には、Ｐａｔｈ ｒｅｌｔｙｐｅ「ＤｅｐｌｏｙｅｄＯｎ」と、ｉｔｅｍ「Ａｐｐ」と、ｉｔｅｍｔｙｐｅ「ｔｏｍｃａｔ」とが含まれる。

一方、例えば、所定の領域に記憶した症状観測箇所のＣＩがＣＩ３００ｈであり、障害発生箇所のＣＩがＣＩ３００ｃであったとすると、関連経路情報生成部３２は、ＣＩ３００ｈからＣＩ３００ｃまでの間に介在するリレーションを特定する。

かかる場合、関連経路情報生成部３２は、ＣＩ３００ｈからＣＩ３００ｃまでの間に介在するリレーションを上記と同様の処理により特定する。すなわち、関連経路情報生成部３２は、ＣＩ３００ｈからリレーションを辿り、取出した障害発生箇所に関する情報に対応するＣＩ３００ｃまでの間に介在するリレーション４００ｍ，４００ｉ及び４００ｅを特定する。そして、特定したリレーション４００ｍ，４００ｉ，４００ｅに基づき、上記と同様の処理により関連経路情報を生成し、事例情報記憶部２１の所定の記憶領域に記憶する。

ここで、ＣＩ３００ｈおよびＣＩ３００ｃ間の関連経路情報のデータ構成を図８−２に示す。図８−２は、ＣＩ３００ｈおよびＣＩ３００ｃ間の関連経路情報のデータ構成の一例を示す図である。なお、図７に示すように、ＣＩ３００ｈおよびＣＩ３００ｃ間の関連経路情報として、リレーション４００ｍ，４００ｉ，４００ｅに基づき生成した関連経路情報を関連経路情報Ｒ３とする。

図８−２に示すように、関連経路情報Ｒ３には、他の症状観測箇所のＣＩおよび障害発生箇所のＣＩ間の関連経路情報と識別するための識別情報としてＲｅｌａｔｉｏｎＰａｔｈ ｉｄ「２」が割当てられる。また、関連経路情報Ｒ３には、同一の症状観測箇所のＣＩおよび障害発生箇所のＣＩ間の関連を示す関連経路情報同士を識別するための識別情報としてＲｅｌｓ ｉｄ「１」が割当てられる。

また、関連経路情報Ｒ３には、各リレーション４００ｍ，４００ｉ，４００ｅに基づき抽出した各情報が、症状観測箇所のＣＩから障害発生箇所のＣＩまでの間に介在する順で記憶されている。すなわち、リレーション４００ｍ，４００ｉ，４００ｅは、症状観測箇所のＣＩ３００ｈから障害発生箇所のＣＩ３００ｇまでの間に、リレーション４００ｍ→４００ｉ→４００ｅの順で存在する。そして、関連経路情報Ｒ３には、リレーション４００ｍに基づき抽出された情報、リレーション４００ｉに基づき抽出された情報、リレーション４００ｅに基づき抽出された情報の順に記憶されている。

このように関連経路情報生成部３２は、介在要素特定手段として機能し、障害を原因とする症状が観測された構成要素から該障害が発生した構成要素までの間に介在する各構成要素のＣＩ及び各構成要素間の関連を表すリレーションと、これらＣＩ及びリレーションが、該症状が観測された構成要素から該障害が発生した構成要素までの間に介在する順序とを特定する。

また、関連経路情報生成部３２は、症状観測箇所のＣＩを始点として、リレーションを辿り特定されるＣＩが障害発生箇所のＣＩであるか否かを順次判定していき、該ＣＩが障害発生箇所のＣＩである場合には、症状観測箇所のＣＩから障害発生箇所のＣＩに至るまでに辿ったリレーションを取出す。そして、関連経路情報生成部３２は、取出した各リレーションに基づき、関連経路情報を生成する。

クエリ生成部３３は、関連経路情報生成部３２により生成した関連経路情報に基づき、障害の発生箇所の候補を特定するためのＣＭＤＢ１０に対するクエリ式を生成する。以下に、クエリ生成部３３によるクエリ生成処理について具体的に説明する。図９−１は図８−１に示す関連経路情報に基づき生成されるクエリ式を示す図、図９−２は図８−２に示す関連経路情報に基づき生成されるクエリ式を示す図である。

ここで、クエリ式は、情報を要求するＣＩの構成別情報やリレーションの関連種別情報などを指定して生成される。例えば、型番「ＦＭＤ２２」のＰＣに関する情報、すなわち、ｔｙｐｅ「ＦＭＤ２２」を有するＣＩの情報を要求する場合、クエリ式は「％Ｐｃ[ｔｙｐｅ＝‘ＦＭＤ２２’]」で表される。なお、ｉｔｅｍやｔｙｐｅ等で示される検索条件の前に付された「％」は、その検索条件がＣＩに対する検索条件であることを示す。

また、「／」を区切りとして、ＣＩ及びリレーションを交互に並べることで、ＣＩ間の関係を辿る検索が可能となる。例えば、型番「ＦＭＤ２２」のＰＣとｔｙｐｅ「ＤｅｐｌｏｙｅｄＯｎ」のリレーションにより関連が示されるＣＩを要求する場合、クエリ式は、「％Ｐｃ[ｔｙｐｅ＝‘ＦＭＤ２２’]／＆ＤｅｐｌｏｙｅｄＯｎ／％」で表される。なお、「＆」は、その後に付された検索条件がリレーションに対する検索条件であることを示す。

例えば、ＲｅｌａｔｉｏｎＰａｔｈ ｉｄ「１」が割当てられた関連経路情報Ｒ１，Ｒ２に基づくクエリ式を生成する場合、クエリ生成部３３は、対処情報記憶部２２から該関連経路情報Ｒ１，Ｒ２に含まれる情報を対処情報記憶部２２に記憶されている順に取出す。そして、クエリ生成部３３は、関連経路情報Ｒ１，Ｒ２に含まれるｒｅｌｔｙｐｅを有するリレーション及び関連経路情報Ｒ１，Ｒ２に含まれるｉｔｅｍ及びｉｔｅｍｔｙｐｅを有するＣＩを取出した順に指定したクエリ式を生成する。関連経路情報Ｒ１，Ｒ２に基づき生成されるクエリ式の一例を図９−１に示す。

クエリ生成部３３は、図９−１に示すように、「ＤｅｐｌｏｙｅｄＯｎ」のリレーション→ｔｙｐｅ「ｔｏｍｃａｔ」及びｉｔｅｍ「Ａｐｐ」のＣＩ→「ＩｎｓｔａｌｌｅｄＯｎ」のリレーション→ｔｙｐｅ「ＷｏｎＳＰ」及びｉｔｅｍ「Ｏｓ」のＣＩ→「ＣｏｎｎｅｃｔｅｄＴｏ」のリレーション→ｔｙｐｅ「Ｗｏｎ３ｋ」及びｉｔｅｍ「Ｏｓ」のＣＩ→「Ｈａｓ」のリレーション→ｔｙｐｅ「ｍｙｓｑｌ」及びｉｔｅｍ「Ａｐｐ」のＣＩ→「Ｈａｓ」のリレーションの順で辿ることのできるｉｔｅｍ「Ｉｎｓｔａｎｃｅ」及びｔｙｐｅ「ｔａｂｌｅ＿ａ」のＣＩを特定するためのクエリ式を生成する。

なお、クエリ式の先頭には、検索の起点となるＣＩを指定する検索条件「％{ｔｈｉｓ}」が付加されている。この検索条件に含まれる「{ｔｈｉｓ}」に後述する障害発生箇所候補抽出部３７が症状観測箇所のＣＩを指定して上記クエリを実行することにより、障害発生箇所の候補のＣＩを特定することができる。かかる処理については、後述する。

また、例えば、ＲｅｌａｔｉｏｎＰａｔｈ ｉｄ「２」が割当てられた関連経路情報Ｒ３に基づくクエリ式を生成する場合、クエリ生成部３３は、対処情報記憶部２２から該関連経路情報Ｒ３に含まれる情報を対処情報記憶部２２に記憶されている順に取出す。そして、クエリ生成部３３は、関連経路情報Ｒ３に含まれるｒｅｌｔｙｐｅを有するリレーション及び関連経路情報Ｒ１，Ｒ２に含まれるｉｔｅｍ及びｉｔｅｍｔｙｐｅを有するＣＩを取出した順に指定したクエリ式を生成する。

かかる処理により、クエリ生成部３３は、図９−２に示すように、「ＤｅｐｌｏｙｅｄＯｎ」のリレーション→ｔｙｐｅ「ｔｏｍｃａｔ」及びｉｔｅｍ「Ａｐｐ」のＣＩ→「ＩｎｓｔａｌｌｅｄＯｎ」のリレーション→ｔｙｐｅ「ＷｏｎＳＰ」及びｉｔｅｍ「Ｏｓ」のＣＩ→「ＣｏｎｎｅｃｔｅｄＴｏ」のリレーションの順で辿ることのできるｔｙｐｅ「Ｗｏｎ３ｋ」及びｉｔｅｍ「Ｏｓ」のＣＩを特定するためのクエリ式を生成する。

このように、クエリ生成部３３は、関連経路情報生成部３２により特定した各リレーションの関連種別情報と同一の関連種別情報を含むリレーション及び関連経路情報生成部３２により特定した各ＣＩの構成種別情報と同一の構成種別情報を含むＣＩを、関連経路情報生成部３２により特定した順序と同一の順序でＣＭＤＢ１０を検索し特定されるＣＩを要求する旨の検索式を生成する。

対処方法登録部３４は、対処情報登録手段として機能し、クエリ生成部３３により生成されたクエリ式を、事例情報記憶部２１に記憶されている情報のうち、該クエリ式の生成処理に用いた「症状観測箇所」及び「障害発生箇所」と対応付けて記憶されている「症状の内容」及び「対処内容」とともに対処情報記憶部２２に登録する。

対処検索部３５は、端末装置２ｂから取得した対処方法検索要求に基づき、対処情報記憶部２２から必要な情報を取出す。具体的には、端末装置２ｂからネットワークを介して送信される対処方法検索要求には、症状観測要素名、症状観測機器名及び症状の内容が含まれる。そして、対処検索部３５は、対処方法検索要求に含まれる構成要素の名称及び該構成要素を所有する機器の名称に基づき、症状観測要素のＣＩ ｉｄを特定し、所定の記憶領域に記憶しておく。

また、対処検索部３５は、対処方法検索要求に含まれる症状の内容に基づき、該症状の内容と同一の内容と対応付けられている対処の内容を対処情報記憶部２２から取出し、後述する障害発生箇所候補抽出部３７により抽出された障害発生箇所候補とともに、端末装置２ｂへネットワークを介して送信する。

例えば、対処情報記憶部２２から取出した対処の内容が「障害が発生したサーブレットが使用しているＤＢテーブルのパラメータＸＸＸを０にしてください。」であり、障害発生箇所候補抽出部３７により、障害発生箇所の候補としてｔｙｐｅ「ｔａｂｌｅ＿ａ」のＣＩが抽出されたとする。かかる場合、対処検索部３５は、端末装置２ｂに対して、「障害が発生したサーブレット”ｓｅｒｖｌｅｔ＿ａ”が使用しているＤＢテーブル”ｔａｂｌｅ＿ａ”のパラメータＸＸＸを０にしてください。」という対処内容に関する情報を端末装置２ｂへ送信する。これにより、端末装置２ｂを使用する作業者は、障害への対処方法を、該障害の発生箇所の候補に関する情報とともに取得することができる。なお、上記の例において「ｓｅｒｖｌｅｔ＿ａ」に関する情報は、後述する障害発生箇所候補抽出部３７による処理によって特定することができる。

このように、対処検索部３５は、症状が観測された構成要素に対応するＣＩと該症状の内容を表す症状内容情報とを取得する症状取得手段として機能する。また、対処検索部３５は、障害発生箇所候補抽出部３７により障害発生箇所候補として抽出したＣＩを、対処検索部３５により取得した症状の内容と同一の症状の内容を表す症状内容情報と対応付けて対処情報記憶部２２に記憶された対処内容情報とともに提示する対処情報提示手段として機能する。

クエリ取得部３６は、対処検索部３５が端末装置２ｂから取得した症状の内容に関する情報に基づき、該症状の内容と同一の内容と対応付けられているクエリ式を対処情報記憶部２２から取出す。例えば、「データベースセッションをクローズしました」という症状の内容を取得した場合、クエリ取得部３６は、該症状の内容と同一の内容と対応付けられたクエリ式として、図６に示す２つのクエリ式（図９−１及び図９−２に示すクエリ式）を対処情報記憶部２２から取出す。

このように、クエリ取得部３６は、検索式取得手段として機能し、対処検索部３５によって取得された症状の内容と一致する症状内容情報と対応付けられたクエリ式を対処情報記憶部２２から取得する。

障害発生箇所候補抽出部３７は、対処検索部３５により特定された症状観測箇所を始点とする、クエリ取得部３６により取得したクエリ式に基づくＣＭＤＢ１０の検索処理を実行し、障害発生箇所の候補のＣＩを特定する。以下に、障害発生箇所候補抽出部３７による障害発生箇所候補抽出処理について具体的に説明する。図１０−１は、図９−１に示すクエリ式に基づく障害発生箇所候補抽出処理を説明するための図、図１０−２は、図９−２に示すクエリ式に基づく障害発生箇所候補抽出処理を説明するための図である。

ここで、以下において、情報処理システムには、図４に示したＣＩ３００ａ〜３００ｇ及びリレーション４００ａ〜４００ｎの他に、図１０−１に示すように、それぞれｔｙｐｅ「ＳＶＣ０１」及びｎａｍｅ「ＨｏｓｔＣ」のＰＣ、ｔｙｐｅ「ＤＸＬ６６０」及びｎａｍｅ「ＨｏｓｔＤ」のＰＣ、ｔｙｐｅ「Ｗｏｎ３ｋ」のＯＳ、ｔｙｐｅ「ＷｏｎＳＰ」のＯＳが含まれるとする。同様に、情報処理システムには、それぞれｔｙｐｅ「ｍｙｓｑｌ」のアプリケーション、ｔｙｐｅ「ｔｏｍｃａｔ」のアプリケーション、ｔｙｐｅ「ｔａｂｌｅ＿ａ」のインスタンス、ｔｙｐｅ「ｓｅｒｖｌｅｔ＿ｂ」のインスタンスが含まれるとする。そして、ＣＭＤＢ１０は、これら構成要素の構成要素情報としてそれぞれＣＩ３１０ａ〜３１０ｇを記憶する。

また、ＣＭＤＢ１０は、図１０−１に示すように、ＣＩ３１０ａを主体としＣＩ３１０ｃを客体とするｔｙｐｅ「Ｈａｓ」のリレーション４１０ａ、ＣＩ３１０ｃを主体としＣＩ３１０ａを客体とするｔｙｐｅ「ＩｎｓｔａｌｌｅｄＯｎ」のリレーション４１０ｂを記憶する。同様に、ＣＭＤＢ１０は、ＣＩ３１０ｂを主体としＣＩ３１０ｄを客体とするｔｙｐｅ「Ｈａｓ」のリレーション４１０ｃ、ＣＩ３１０ｄを主体としＣＩ３１０ｂを客体とするｔｙｐｅ「ＩｎｓｔａｌｌｅｄＯｎ」のリレーション４１０ｄを記憶する。同様に、ＣＭＤＢ１０は、ＣＩ３１０ｄを主体としＣＩ３１０ｃを客体とするｔｙｐｅ「ＣｏｎｎｅｃｔｅｄＴｏ」のリレーション４１０ｅを記憶する。

同様に、また、ＣＭＤＢ１０は、ＣＩ３１０ｃを主体としＣＩ３１０ｅを客体とするｔｙｐｅ「Ｈａｓ」のリレーション４１０ｆ、ＣＩ３１０ｅを主体としＣＩ３１０ｃを客体とするｔｙｐｅ「ＩｎｓｔａｌｌｅｄＯｎ」のリレーション４１０ｇを記憶する。同様に、ＣＭＤＢ１０は、ＣＩ３１０ｄを主体としＣＩ３１０ｆを客体とするｔｙｐｅ「Ｈａｓ」のリレーション４１０ｈ、ＣＩ３１０ｆを主体としＣＩ３１０ｄを客体とするｔｙｐｅ「ＩｎｓｔａｌｌｅｄＯｎ」のリレーション４１０ｉを記憶する。

また、ＣＭＤＢ１０は、ＣＩ３１０ｅを主体としＣＩ３１０ｇを客体とするｔｙｐｅ「Ｈａｓ」のリレーション４１０ｊ、ＣＩ３１０ｇを主体としＣＩ３１０ｅを客体とするｔｙｐｅ「ＤｅｐｌｏｙｅｄＯｎ」のリレーション４１０ｋを記憶する。同様に、ＣＭＤＢ１０は、ＣＩ３１０ｆを主体としＣＩ３１０ｈを客体とするｔｙｐｅ「Ｈａｓ」のリレーション４１０ｌ、ＣＩ３１０ｈを主体としＣＩ３１０ｆを客体とするｔｙｐｅ「ＤｅｐｌｏｙｅｄＯｎ」のリレーション４１０ｍを記憶する。同様に、ＣＭＤＢ１０は、ＣＩ３１０ｈを主体としＣＩ３１０ｇを客体とするｔｙｐｅ「Ｕｓｅ」のリレーション４１０ｎを記憶する。

かかる場合において、端末装置２ｂからの対処方法検索要求に基づき、対処検索部３５が症状観測要素のＣＩ ｉｄを特定するとともに、クエリ取得部３６が図９−１に示すクエリ式を取出したとする。このような場合、障害発生箇所候補抽出部３７は、クエリ式の先頭に付された、検索の起点となるＣＩを指定する検索条件「％{ｔｈｉｓ}」に症状観測要素のＣＩ ｉｄを指定し、該ＣＩを始点としたクエリ式を実行する。

具体的には、障害発生箇所候補抽出部３７は、ｉｔｅｍ「Ｉｎｓｔａｎｃｅ」及びｔｙｐｅ「Ｓｅｒｖｌｅｔ＿ｂ」を有するＣＩから、ｔｙｐｅ「ＤｅｐｌｏｙｅｄＯｎ」のリレーション→ｔｙｐｅ「ｔｏｍｃａｔ」及びｉｔｅｍ「Ａｐｐ」のＣＩ→ｔｙｐｅ「ＩｎｓｔａｌｌｅｄＯｎ」のリレーション→ｔｙｐｅ「ＷｏｎＳＰ」及びｉｔｅｍ「Ｏｓ」のＣＩ→ｔｙｐｅ「ＣｏｎｎｅｃｔｅｄＴｏ」のリレーション→ｔｙｐｅ「Ｗｏｎ３ｋ」及びｉｔｅｍ「Ｏｓ」のＣＩ→ｔｙｐｅ「Ｈａｓ」のリレーション→ｔｙｐｅ「ｍｙｓｑｌ」及びｉｔｅｍ「Ａｐｐ」のＣＩ→ｔｙｐｅ「Ｈａｓ」のリレーションの順で辿ることのできるｉｔｅｍ「Ｉｎｓｔａｎｃｅ」及びｔｙｐｅ「ｔａｂｌｅ＿ａ」のＣＩを特定する。

より具体的には、障害発生箇所候補抽出部３７は、図１０−１に示すように、検索の起点となるＣＩ３１０ｈのＣｉ ｉｄをｓｒｃとして有するｔｙｐｅ「ＤｅｐｌｏｙｅｄＯｎ」のリレーション４１０ｍをＣＭＤＢ１０を検索して特定する。続いて、障害発生箇所候補抽出部３７は、リレーション４１０ｍが有するｄｓｔと同一のＣＩ ｉｄを有するｔｙｐｅ「ｔｏｍｃａｔ」及びｉｔｅｍ「Ａｐｐ」のＣＩ３１０ｆをＣＭＤＢ１０を検索して特定する。続いて、障害発生箇所候補抽出部３７は、ＣＩ３１０ｆのＣＩ ｉｄをｓｒｃとして有するｔｙｐｅ「ＩｎｓｔａｌｌｅｄＯｎ」のリレーションｉを特定する。続いて、障害発生箇所候補抽出部３７は、リレーション４１０ｉが有するｄｓｔと同一のＣＩ ｉｄを有するｔｙｐｅ「ＷｏｎＳＰ」及びｉｔｅｍ「Ｏｓ」のＣＩｄを特定する。

このような処理を繰り返すことにより、障害発生箇所候補抽出部３７は、上記クエリ式に基づき、図１０−１に示すように、ＣＩ３１０ｈを始点として、リレーション４１０ｍ→ＣＩ３１０ｆ→リレーション４１０ｉ→ＣＩ３１０ｄ→リレーション４１０ｅ→ＣＩ３１０ｃ→リレーション４１０ｆ→ＣＩ３１０ｅ→リレーション４１０ｊを辿って、ＣＩ３１０ｇを特定する。そして、障害発生箇所候補抽出部３７は、特定したＣＩ３１０ｇに含まれるＣＩ ｉｄやｉｔｅｍ、ｔｙｐｅ等の情報を障害発生箇所候補としてＣＭＤＢ１０から抽出する。なお、障害発生箇所候補抽出部３７は、必要に応じて、上記クエリ式に基づき辿った他のＣＩに関する情報も抽出してもよい。

また、障害発生箇所候補抽出部３７は、図９−１に示すクエリ式に基づく検索式として、ｉｔｅｍ「Ｉｎｓｔａｎｃｅ」及びｔｙｐｅ「Ｓｅｒｖｌｅｔ＿ｂ」を有するＣＩから、「Ｕｓｅ」のリレーションで辿ることのできるｉｔｅｍ「Ｉｎｓｔａｎｃｅ」のＣＩを特定する。すなわち、障害発生箇所候補抽出部３７は、図１０−２に示すように、ＣＩ３１０ｈを始点として、リレーション４１０ｎを辿って、ＣＩ３１０ｇを特定する。そして、障害発生箇所候補抽出部３７は、特定したＣＩ３１０ｇを障害発生箇所候補としてＣＭＤＢ１０から抽出する。

また、端末装置２ｂからの対処方法検索要求に基づき、対処検索部３５が症状観測箇所の構成要素のＣＩ ｉｄを特定するとともに、クエリ取得部３６が図９−２に示すクエリ式を取出したとする。このような場合、障害発生箇所候補抽出部３７は、図９−２に示すクエリ式の先頭に付された検索の起点となるＣＩを指定する検索条件「％{ｔｈｉｓ}」に症状観測要素のＣＩ ｉｄを指定し、該ＣＩを始点とした図９−２に示すクエリ式を実行する。

具体的には、障害発生箇所候補抽出部３７は、ｉｔｅｍ「Ｉｎｓｔａｎｃｅ」及びｔｙｐｅ「Ｓｅｒｖｌｅｔ＿ｂ」を有するＣＩから、「ＤｅｐｌｏｙｅｄＯｎ」のリレーション→ｔｙｐｅ「ｔｏｍｃａｔ」及びｉｔｅｍ「Ａｐｐ」のＣＩ→「ＩｎｓｔａｌｌｅｄＯｎ」のリレーション→ｔｙｐｅ「ＷｏｎＳＰ」及びｉｔｅｍ「Ｏｓ」のＣＩ→「ＣｏｎｎｅｃｔｅｄＴｏ」のリレーションの順で辿ることのできるｔｙｐｅ「Ｗｏｎ３ｋ」及びｉｔｅｍ「Ｏｓ」のＣＩを特定する。

すなわち、障害発生箇所候補抽出部３７は、上記クエリ式に基づき、図１０−２に示すように、ＣＩ３１０ｈを始点として、リレーション４１０ｍ→ＣＩ３１０ｆ→リレーション４１０ｉ→ＣＩ３１０ｄ→リレーション４１０ｅを辿って、ＣＩ３１０ｃを特定する。そして、障害発生箇所候補抽出部３７は、特定したＣＩ３１０ｃのｉｐ等の情報を障害発生箇所候補としてＣＭＤＢ１０から抽出する。

このように、障害発生箇所候補抽出部３７は、障害発生箇所候補抽出手段として機能し、ＣＭＤＢ１０に記憶されたＣＩ及びリレーションのうち、クエリ取得部３６により取得したクエリ式に含まれる関連種別情報と同一の関連種別情報を含むリレーションと、該クエリ式に含まれる構成種別情報と同一の構成種別情報を含むＣＩとを、対処検索部３５により取得したＣＩを始点とし、指定された順序で辿ることにより特定される構成要素を障害発生箇所候補として抽出する。

[３．システム管理装置の具体的動作]
次に、本実施例にかかるシステム管理装置１の具体的動作について図面を参照して説明する。先ず、端末装置２ａから取得した作業履歴に基づく対処方法登録処理について説明する。図１１は、本実施例にかかる対処方法登録処理の処理手順を示すフローチャートである。

端末装置２ａから作業履歴に関する情報を取得すると、事例登録部３１は、図１０に示すように、症状観測ＣＩ特定処理を行う（ステップＳ１１０１）。症状観測ＣＩ特定処理は、作業履歴に含まれる症状観測機器名及び症状観測要素名に基づき、症状観測箇所のＣＩを特定する。症状観測ＣＩ特定処理は、図１１に示す処理であり、後述する。ステップＳ１１０１の処理を終えると、事例登録部３１は、障害発生ＣＩ特定処理を行う（ステップＳ１１０２）。障害発生機器名及び障害発生要素名に基づき、障害発生箇所のＣＩを特定する。障害発生ＣＩ特定処理は、図１２に示す処理であり、後述する。

続いて、関連経路情報生成部３２は、ステップＳ１１０１の症状観測ＣＩ特定処理において特定した症状観測箇所のＣＩからステップＳ１１０２の障害発生ＣＩ特定処理において特定した障害発生箇所のＣＩまでの間に介在するリレーションを特定する（ステップＳ１１０３）。続いて、関連経路情報生成部３２は、特定したリレーションに基づき関連経路情報を生成する（ステップＳ１１０４）。そして、クエリ生成部３３は、ステップＳ１１０４において生成した関連経路情報に基づくクエリ式を生成する（ステップＳ１１０５）。

ステップＳ１１０５の処理を終えると、対処方法登録部３４は、ステップＳ１１０５において生成したクエリ式を、該クエリ式の生成処理に用いた「症状観測箇所」及び「障害発生箇所」と対応付けて記憶されている「症状の内容」及び「対処内容」とともに対処情報記憶部２２に登録する（ステップＳ１１０６）。ステップＳ１１０６の処理を終えると、制御部３０は、対処方法登録処理を終了する。

続いて、ステップＳ１１０１における症状観測ＣＩ特定処理について、図１１を参照して具体的に説明する。図１２は、本実施例にかかる症状観測ＣＩ特定処理の処理手順を示すフローチャートである。

図１２に示すように、症状観測ＣＩ特定処理を開始すると、事例登録部３１は、事例情報記憶部２１に記憶された情報から、症状観測機器名および症状観測要素名を取得する（ステップＳ１２０１）。続いて、事例登録部３１は、取得した症状観測機器名と一致するＣＩをＣＭＤＢ１０から取得する（ステップＳ１２０２）。例えば、取得した症状観測機器名が「ＨｏｓｔＢ」である場合、事例登録部３１は、ＣＭＤＢ１０からｎａｍｅ「ＨｏｓｔＢ」を有するＣＩ３００ｂを取出す。

続いて、事例登録部３１は、ステップＳ１２０２において取得したＣＩが“Ｈａｓ”関連を持つか否かを判定する（ステップＳ１２０３）。すなわち、事例登録部３１は、該ＣＩと他のＣＩとの関連を示すリレーションのうち、ｔｙｐｅ「Ｈａｓ」を有するリレーションが存在するか否かを判定する。かかる処理において、該ＣＩが“Ｈａｓ”関連を持たない場合（ステップＳ１２０３否定）、事例登録部３１は、例えば、端末装置２ａにエラー報告を行い処理を終了する（ステップＳ１２０４）。

一方、該ＣＩが“Ｈａｓ”関連を持つと判定した場合（ステップＳ１２０３肯定）、事例登録部３１は、取得したＣＩから“Ｈａｓ”関連により辿ることのできるＣＩを特定する（ステップＳ１２０５）。すなわち、事例登録部３１は、ｔｙｐｅ「Ｈａｓ」を有するリレーションによりステップＳ１２０２において取得したＣＩとの関連が示されるＣＩを特定する。例えば、ステップＳ１２０２において取得したＣＩがＣＩ３００ｂである場合、事例登録部３１は、図４に示すように、ｔｙｐｅ「Ｈａｓ」を有するリレーション４００ｃで辿ることのできるＣＩ３００ｄを特定する。

続いて、事例登録部３１は、特定したＣＩのｔｙｐｅと症状観測要素名が一致するか否かを判定する（ステップＳ１２０６）。かかる処理において特定したＣＩのｔｙｐｅと症状観測要素名が一致しないとき（ステップＳ１２０６否定）、事例登録部３１は、処理をステップＳ１２０３へ移行する。例えば、特定したＣＩ３００ｄのｔｙｐｅ「ＷｏｎＳＰ」が端末装置２ａから取得した症状観測要素名と異なる場合、事例登録部３１は、処理１２０３へ移行し、ＣＩ３００ｄが“Ｈａｓ”関連を持つか否かを判定する。

一方、特定したＣＩのｔｙｐｅと症状観測要素名が一致すると判定した場合（ステップＳ１２０６肯定）、事例登録部３１は、ステップＳ１２０５において特定したＣＩを症状観測要素のＣＩとして所定の記憶領域に記憶する（ステップＳ１２０７）。ステップＳ１２０７の処理を終えたとき、事例登録部３１は、症状観測ＣＩ特定処理を終了する。

このように、事例登録部３１は、端末装置２ａから取得した作業履歴に関する情報に含まれる症状観測機器名と一致するｔｙｐｅを有するＣＩからｔｙｐｅ「Ｈａｓ」を有するリレーションを順次辿っていき、症状観測要素名と一致するｔｙｐｅを有するＣＩを症状観測要素のＣＩとして特定する。

続いて、ステップＳ１１０２における障害発生ＣＩ特定処理について、図１３を参照して具体的に説明する。図１３は、本実施例にかかる障害発生ＣＩ特定処理の処理手順を示すフローチャートである。

図１３に示すように、障害発生ＣＩ特定処理を開始すると、事例登録部３１は、事例情報記憶部２１に記憶された情報から、障害発生機器名および障害発生要素名を取得する（ステップＳ１３０１）。続いて、事例登録部３１は、取得した障害発生機器名と一致するＣＩをＣＭＤＢ１０から取得する（ステップＳ１３０２）。例えば、取得した障害発生機器名が「ＨｏｓｔＢ」である場合、事例登録部３１は、ＣＭＤＢ１０からｎａｍｅ「ＨｏｓｔＢ」を有するＣＩ３００ａを取出す。

続いて、事例登録部３１は、ステップＳ１３０２において取得したＣＩが“Ｈａｓ”関連を持つか否かを判定する（ステップＳ１３０３）。かかる処理において、該ＣＩが“Ｈａｓ”関連を持たない場合（ステップＳ１３０３否定）、事例登録部３１は、例えば、端末装置２ａにエラー報告を行い処理を終了する（ステップＳ１３０４）。

一方、該ＣＩが“Ｈａｓ”関連を持つと判定した場合（ステップＳ１３０３肯定）、事例登録部３１は、取得したＣＩから“Ｈａｓ”関連により辿ることのできるＣＩを特定する（ステップＳ１３０５）。例えば、取得したＣＩがＣＩ３００ａである場合、図４に示すように、事例登録部３１は、ｔｙｐｅ「Ｈａｓ」を有するリレーション４００ａで辿ることのできるＣＩ３００ｃを特定する。

続いて、事例登録部３１は、特定したＣＩのｔｙｐｅと障害発生要素名が一致するか否かを判定する（ステップＳ１３０６）。かかる処理において特定したＣＩのｔｙｐｅと障害発生要素名が一致しないとき（ステップＳ１３０６否定）、事例登録部３１は、処理をステップＳ１３０３へ移行する。一方、特定したＣＩのｔｙｐｅと障害発生要素名が一致すると判定した場合（ステップＳ１３０６肯定）、事例登録部３１は、ステップＳ１３０５において特定したＣＩを障害発生箇所のＣＩとして所定の記憶領域に記憶する（ステップＳ１３０７）。ステップＳ１３０７の処理を終えたとき、事例登録部３１は、障害発生ＣＩ特定処理を終了する。

このように、事例登録部３１は、端末装置２ａから取得した作業履歴に関する情報に含まれる障害発生機器名と一致するｔｙｐｅを有するＣＩからｔｙｐｅ「Ｈａｓ」を有するリレーションを順次辿っていき、障害発生要素名と一致するｔｙｐｅを有するＣＩを障害発生要素のＣＩとして特定する。

続いて、端末装置２ｂから取得した対処方法検索要求に基づき実行される、障害発生箇所候補抽出処理について説明する。図１４は、本実施例にかかるシステム管理装置１の障害発生箇所候補抽出処理の処理手順を示すフローチャートである。

端末装置２ｂから対処方法検索要求を取得すると、対処検索部３５は、図１４に示すように、対処方法検索要求に含まれる症状発生機器名及び症状発生要素名を取得する（ステップＳ１４０１）。続いて、対処検索部３５は、取得した症状観測機器名と一致するＣＩをＣＭＤＢ１０から取得する（ステップＳ１４０２）。例えば、取得した症状観測機器名が「ＨｏｓｔＤ」である場合、対処検索部３５は、図１０−１に示すように、ＣＭＤＢ１０からｎａｍｅ「ＨｏｓｔＤ」を有するＣＩ３１０ｂを取出す。

続いて、対処検索部３５は、ステップＳ１４０２において取得したＣＩが“Ｈａｓ”関連を持つか否かを判定する（ステップＳ１４０３）。かかる処理において、該ＣＩが“Ｈａｓ”関連を持たない場合（ステップＳ１４０３否定）、対処検索部３５は、例えば、端末装置２ａにエラー報告を行う（ステップＳ１４０４）。

一方、該ＣＩが“Ｈａｓ”関連を持つと判定した場合（ステップＳ１４０３肯定）、対処検索部３５は、取得したＣＩから“Ｈａｓ”関連により辿ることのできるＣＩを特定する（ステップＳ１４０５）。例えば、取得したＣＩがＣＩ３１０ｂである場合、対処検索部３５は、図１０−１に示すように、ｔｙｐｅ「Ｈａｓ」を有するリレーション４１０ｃで辿ることのできるＣＩ３１０ｄを特定する。

続いて、対処検索部３５は、特定したＣＩのｔｙｐｅと症状観測要素名が一致するか否かを判定する（ステップＳ１４０６）。かかる処理において特定したＣＩのｔｙｐｅと症状観測要素名が一致しないとき（ステップＳ１４０６否定）、対処検索部３５は、処理をステップＳ１４０３へ移行する。一方、特定したＣＩのｔｙｐｅと症状観測要素名が一致すると判定した場合（ステップＳ１４０６肯定）、対処検索部３５は、ステップＳ１４０５において特定したＣＩを症状観測箇所のＣＩとして所定の記憶領域に記憶する（ステップＳ１４０７）。

続いて、クエリ取得部３６は、対処方法検索要求に含まれる症状の内容に関する情報に基づき、該症状の内容と同一の内容と対応付けられているクエリ式を対処情報記憶部２２から取得する（ステップＳ１４０８）。続いて、障害発生箇所候補抽出部３７は、ステップＳ１４０７において登録された症状観測箇所を始点とし、ステップＳ１４０９において取得したクエリ式に基づくＣＭＤＢ１０の検索処理を実行する（ステップＳ１４０９）。

続いて、障害発生箇所候補抽出部３７は、ステップＳ１４１０において実行した検索処理により特定されたＣＩを障害発生箇所候補として所定の記憶領域に記録する（ステップＳ１４１０）。そして、対処検索部３５は、対処方法検索要求に含まれる症状の内容に基づき、該症状の内容と同一の内容と対応付けられている対処の内容を対処情報記憶部２２から取出し、取出した対処の内容をステップＳ１４１０において記録された障害発生箇所候補とともに、端末装置２ｂへネットワークを介して送信する（ステップＳ１４１１）。ステップＳ１４０４、Ｓ１４１１の処理を終えると、制御部３０は、障害発生箇所候補抽出処理を終了する。

上述してきたように、本実施例では、管理対象である情報処理システムにおいて過去に発生した障害の障害発生要素と該障害を原因として観測された症状の症状観測要素との因果関係を記憶しておき、同様の症状が観測された場合に、該症状が観測された構成要素との間で上記因果関係と同様の因果関係を有する構成要素を障害発生箇所候補として特定する。これにより、作業者は、症状に関する情報を入力することで、該症状の原因となる障害の発生箇所の候補に関する情報を取得することができ、トラブル対処作業の効率性を向上させることができる。

また、本実施例において、対処情報記憶部２２は、症状内容情報とともに、該症状の原因となった障害への対処の内容を表す対処内容情報をクエリ式と対応付けて記憶しており、障害発生箇所候補抽出部３７により障害発生箇所候補として抽出したＣＩを、端末装置２ｂから取得した症状の内容と同一の症状の内容を表す症状内容情報と対応付けて対処情報記憶部２２に記憶された対処内容情報とともに端末装置２ｂへ提示する。これにより、作業者は、症状に関する情報を入力することで、例えば、対処を行うべき機器名等が具体的に指定された対処内容を取得することができ、トラブル対処作業の効率性をより一層向上させることができる。

具体的には、例えば、対処内容情報「障害が発生したサーブレットが使用しているＤＢテーブルのパラメータＸＸＸを０にしてください」に該当するサーブレットやＤＢテーブルが情報処理システム内に複数存在する場合、作業者は、該当するサーブレットやＤＢテーブルを特定するための切り分け作業を行う。かかる場合において、本実施例のように、対処内容情報とともに障害発生箇所候補に関する情報を対処検索部３５から取得することにより、作業者は、障害発生箇所候補として特定された機器等から切り分け作業を行う。すなわち、当りを付けた切り分け作業を行うことができるため、切り分け作業に要する時間を短縮することができる。

また、本実施例では、事例情報記憶部２１に記憶されたトラブル事例情報に基づき、症状観測要素から障害発生要素までの間に介在する各構成要素のＣＩ及び各構成要素間の関連を表すリレーションとこれらＣＩ及びリレーションが介在する順序とを特定するとともに、特定した各情報に基づきクエリ式を生成し、観測された症状の内容を表す症状内容情報と対応付けて対処情報記憶部２２に登録する。これにより、例えば、情報処理システム内において新規な障害が発生した場合に、その障害に対するトラブル対処作業に基づくトラブル事例情報からクエリ式を生成し、対処情報記憶部２２に登録しておくことで、再度同様な障害が発生した場合に、上記クエリ式に基づきＣＭＤＮ１０を検索して障害発生候補のＣＩや対処内容情報を取得することができる。

以上、本発明の実施の形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の概要の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。

例えば、図６に示すように、同一の症状の内容を表す症状内容情報が対処情報記憶部２２に複数記憶されている場合には、該症状内容情報と対応付けられた対処内容情報も対処情報記憶部２２に複数記憶される。そのため、端末装置２ｂに送信すべき対処内容情報を特定するために、システム管理装置１は、例えば「資料“ＱＱＱ”の値を入力して下さい。」などの指示を端末装置２ｂに送信して、端末装置２ｂから更に情報を取得することにより、端末装置２ｂに送信すべき対処内容情報を特定する。作業者は、このような指示に基づき作業を行っている途中であっても、すなわち、システム管理装置１から対処内容情報を取得する前であっても、障害発生箇所候補に関する情報を取得することができる。

例えば、図１５に示すように、作業者は、端末装置２ｂのディスプレイに表示された所定のウィンドウ５００の入力欄５５０に表示された「症状（メッセージ）を入力してください」という指示に基づき、障害が原因となり観測された症状の内容や症状観測機器名、症状観測要素名を入力する（ステップＳ２１）。

ここで、入力された症状の内容と同一の内容を表す症状内容情報が対処情報記憶部２２に複数存在する場合、対処検索部３５は、端末装置２ｂに対して、例えば「資料“ＱＱＱ”の値を入力して下さい」等の、次に作業者が行うべき作業手順を指示する情報を送信する。また、対処検索部３５は、ステップＳ２１において取得した症状の内容や症状観測機器名、症状観測要素名に基づき障害発生箇所候補抽出部３７が特定した障害発生箇所候補に関する情報を上記指示とともに端末装置２ｂへ送信する（ステップＳ２２）。これにより、端末装置２ｂのディスプレイには、「資料“ＱＱＱ”の値を入力して下さい」等の指示とともに、「１９２．１６８．１．１０」や「ｔａｂｌｅ＿ａ」等の障害発生箇所候補のＣＩに含まれる情報５６０が表示される。

そして、作業者は、ウィンドウ５００に表示された指示に従い、入力欄５５０に資料“ＱＱＱ”の値を入力し、対処検索部３５へ送信する。このような処理を繰り返すことにより、対処検索部３５は、端末装置２ｂから送信された症状内容情報に対応する複数の対処内容情報の中から、端末装置２ｂに送信すべき対処内容情報を特定する。そして、対処検索部３５は、特定した対処内容情報を、該対処内容情報と対応付けられたクエリ式に基づき抽出された障害発生箇所候補に関する情報を端末装置２ｂへ送信する。これにより、端末装置２ｂのディスプレイには、例えば「障害が発生したサーブレット”ｓｅｒｖｌｅｔ＿ａ”が使用している、ＤＢテーブル”ｔａｂｌｅ＿ａ”のパラメータＸＸＸを０にしてください。」といった、対処を行うべき機器名等が具体的に指定された対処内容５７０が表示される（ステップＳ２３）。

このように、作業者は、システム管理装置１から対処内容情報を取得する前であっても、障害発生箇所候補に関する情報を取得することができるため、見通しを持ったトラブル対処作業を行うことができる。

また、本実施例において、クエリ生成部３３は、障害発生箇所候補として抽出すべきＣＩのｔｙｐｅを指定したクエリ式を生成することとした。例えば、クエリ生成部３３は、クエリ式「%{this}/&DeployedOn/%App[type=‘tomcat’]/&InstalledOn/%Os[type=‘WonSP’]/&ConnectedTo/%Os[type=‘Won3k’]」に含まれる「%Os[type=‘Won3k’]」のように、障害発生箇所候補としてｔｙｐｅ「Ｗｏｎ３ｋ」を指定したクエリ式を生成する。しかし、障害発生箇所候補として抽出すべきＣＩのｔｙｐｅは、必ずしも指定しなくてもよい。

かかる場合、関連経路情報生成部３２は、症状観測要素のＣＩから障害発生要素のＣＩまでの間に介在するＣＩ及びリレーションのうち、障害発生要素のＣＩと他のＣＩの関連を表すリレーションについては、該リレーションのｔｙｐｅ及び障害発生要素のＣＩのｉｔｅｍのみを抽出し、関連経路情報を生成する。例えば、症状観測要素のＣＩがＣＩ３００ｈであり、障害発生要素のＣＩがＣＩ３００ｇである場合、関連経路情報生成部３２は、障害発生要素のＣＩ３００ｇを客体とするリレーション４００ｊについては、該リレーション４００ｊのｔｙｐｅ「Ｈａｓ」を抽出するとともに、ＣＩ３００ｇのｉｔｅｍ「Ｉｎｓｔａｎｃｅ」のみをＣＭＤＢ１０から抽出する。そして、クエリ生成部３３は、関連経路情報生成部３２により生成された関連経路情報に基づき、クエリ式を生成する。

これにより、障害発生箇所候補のＣＩを、ｔｙｐｅを限定せずに抽出することができるため、作業者のニーズにより応じた検索処理が可能となる。

また、上記実施例では、構成要素情報記憶手段及び関連要素情報記憶手段の一例として、ＣＭＤＢを用いて説明したが、構成要素情報記憶手段及び関連要素情報記憶手段は、ＣＭＤＢに限らず、例えば、複数のＣＭＤＢに散在する各種の構成情報を仮想的に統合するＦＣＭＤＢ（Federated CMDB）であってもよい。

ところで、上記の実施例で説明した各種の処理は、予め用意されたプログラムをコンピュータで実行することによって実現することができる。そこで、以下では、図１５を用いて、上記実施例に示したシステム管理装置１と同様の機能を有するシステム管理プログラムを実行するコンピュータの一例を説明する。図１６は、システム管理プログラムを実行するコンピュータを示す図である。

図１６に示すように、システム管理装置１としてのコンピュータ６００は、ＨＤＤ６１０、ＣＰＵ６２０、ＲＯＭ６３０及びＲＡＭ６４０をバス６５０で接続して構成される。

ＲＯＭ６３０には、上記の実施例と同様の機能を発揮するシステム管理プログラム、つまり、図１６に示すように、症状取得プログラム６３１、検索式取得プログラム６３２、障害発生箇所候補抽出プログラム６３３が予め記憶されている。

そして、ＣＰＵ６２０が、これらのプログラム６３１〜６３５をＲＯＭ６３０から読み出して実行することにより、各プログラム６３１〜６３５は、それぞれ症状取得プロセス６２１、検索式取得プロセス６２２、障害発生箇所候補抽出プロセス６２３として機能する。

なお、ＨＤＤ６１０には、プロセス６２１〜６２３によって利用される各種データが格納されている。ＣＰＵ６２０は、ＨＤＤ６１０に格納された各種データを読み出して、ＲＡＭ６４０に格納し、プロセス６２１〜６２３が、ＲＡＭ６４０に格納された各種データを利用して、障害発生箇所候補抽出処理などの各種処理を実行する。

１ システム管理装置
２ａ，２ｂ 端末装置
１０ ＣＭＤＢ
２０ 記憶部
２１ 事例情報記憶部
２２ 対処情報記憶部
３０ 制御部
３１ 事例登録部
３２ 関連経路情報生成部
３３ クエリ生成部
３４ 対処方法登録部
３５ 対処検索部
３６ クエリ取得部
３７ 障害発生箇所候補抽出部

Claims (5)

1. 管理対象に含まれる構成要素を識別する識別情報と、各構成要素の種別を表す構成種別情報とを対応付けて構成要素情報として記憶する構成要素情報記憶手段と、
   前記構成要素情報記憶手段に記憶されている識別情報と、該識別情報によって識別される構成要素と関連を有する構成要素を識別するための識別情報と、該関連の種別を表す関連種別情報とを対応付けて関連要素情報として記憶する関連要素情報記憶手段と、
   障害を原因とする症状が観測された構成要素から該障害が発生した構成要素までの間に介在する各構成要素の構成種別情報と各構成要素間の関連の関連種別情報とが、前記症状が観測された構成要素から前記障害が発生した構成要素までの間に介在する順序で指定された検索式を、該症状の内容を表す症状内容情報と対応付けて記憶する対処情報記憶手段と、
   症状が観測された構成要素に対応する構成要素情報と該症状の内容を表す症状内容情報とを取得する症状取得手段と、
   前記症状取得手段によって取得された症状の内容と一致する症状内容情報と対応付けられた前記検索式を前記対処情報記憶手段から取得する検索式取得手段と、
   前記検索式取得手段により取得した検索式に基づく前記構成要素情報記憶手段及び前記関連要素情報記憶手段に対する検索処理を、前記症状取得手段により取得した構成要素情報を始点として実行し、特定された構成要素を前記観測された症状の原因となる障害の発生箇所の候補として抽出する障害発生箇所候補抽出手段とを備え、
   前記障害発生箇所候補抽出手段は、前記構成要素情報記憶手段及び前記関連要素情報記憶手段に記憶された構成要素情報及び関連要素情報のうち、前記検索式取得手段により取得した検索式に含まれる関連種別情報と同一の関連種別情報を含む関連要素情報と、該検索式に含まれる構成種別情報と同一の構成種別情報を含む構成要素情報とを、前記症状取得手段により取得した構成要素情報を始点とし、前記検索式に含まれる関連種別情報と同一の関連種別情報を含む関連要素情報に含まれる識別情報に基づき前記介在する順序で辿ることにより特定される構成要素を前記観測された症状の原因となる障害の発生箇所の候補として抽出することを特徴とするシステム管理装置。
2. 前記対処情報記憶手段は、症状の内容を表す症状内容情報とともに、該症状の原因となった障害への対処の内容を表す対処内容情報を前記検索式と対応付けて記憶し、
   前記障害発生箇所候補抽出手段により障害発生箇所候補として抽出した構成要素情報を、前記症状取得手段により取得した症状の内容と同一の症状の内容を表す症状内容情報と対応付けて前記対処情報記憶手段に記憶された対処内容情報とともに提示する対処情報提示手段をさらに備えたことを特徴とする請求項１に記載のシステム管理装置。
3. 障害を原因とする症状が観測された構成要素から該障害が発生した構成要素までの間に介在する各構成要素の構成要素情報及び各構成要素間の関連を表す関連要素情報と、前記構成要素情報及び前記関連要素情報が、前記症状が観測された構成要素から前記障害が発生した構成要素までの間に介在する順序とを特定する介在要素特定手段と、
   前記介在要素特定手段により特定した各関連要素情報の関連種別情報と同一の関連種別情報を含む関連要素情報及び前記介在要素特定手段により特定した各構成要素情報の構成種別情報と同一の構成種別情報を含む構成要素情報を、前記介在要素特定手段により特定した順序と同一の順序で前記構成要素記憶手段及び前記関連要素記憶手段を検索し特定される構成要素情報を要求する旨の検索式を生成する検索式生成手段と、
   前記検索式生成手段により生成された検索式を、前記観測された症状の内容を表す症状内容情報と対応付けて前記対処情報記憶手段に登録する対処情報登録手段と
   をさらに備えたことを特徴とする請求項１又は２に記載のシステム管理装置。
4. 管理対象において発生した障害を原因とする症状の内容を取得するとともに、前記管理対象に含まれる構成要素を識別する識別情報と、各構成要素の種別を表す構成種別情報とを対応付けて構成要素情報として記憶する構成要素情報記憶手段から、該症状が観測された構成要素に対応する構成要素情報を取得する症状取得手順と、
   障害を原因とする症状が観測された構成要素から該障害が発生した構成要素までの間に介在する各構成要素の構成種別情報と各構成要素間の関連の関連種別情報とが、前記症状が観測された構成要素から前記障害が発生した構成要素までの間に介在する順序で指定された検索式を、該症状の内容を表す症状内容情報と対応付けて記憶する対処情報記憶手段から、前記症状取得手順によって取得された症状の内容と一致する症状内容情報と対応付けられた検索式を取得する検索式取得手順と、
   前記検索式取得手順により取得した検索式に基づく検索処理を、前記症状取得手順により取得した構成要素情報を始点として実行し、特定された構成要素を前記観測された症状の原因となる障害の発生箇所の候補として抽出する障害発生箇所候補抽出手順と
   をコンピュータに実行させ、
   前記障害発生箇所候補抽出手順は、前記構成要素情報記憶手段に記憶された構成要素情報、及び、前記構成要素情報記憶手段に記憶されている識別情報と、該識別情報によって識別される構成要素と関連を有する構成要素を識別するための識別情報と、該関連の種別を表す関連種別情報とを対応付けて関連要素情報として記憶する関連要素情報記憶手段に記憶された関連要素情報のうち、前記検索式取得手順により取得した検索式に含まれる関連種別情報と同一の関連種別情報を含む関連要素情報と、該検索式に含まれる構成種別情報と同一の構成種別情報を含む構成要素情報とを、前記症状取得手順により取得した構成要素情報を始点とし、前記検索式に含まれる関連種別情報と同一の関連種別情報を含む関連要素情報に含まれる識別情報に基づき前記介在する順序で辿ることにより特定される構成要素を前記観測された症状の原因となる障害の発生箇所の候補として抽出することを特徴とするシステム管理プログラム。
5. 管理対象において発生した障害を原因とする症状の内容を取得するとともに、前記管理対象に含まれる構成要素を識別する識別情報と、各構成要素の種別を表す構成種別情報とを対応付けて構成要素情報として記憶する構成要素情報記憶手段から、該症状が観測された構成要素に対応する構成要素情報を取得する症状取得ステップと、
   障害を原因とする症状が観測された構成要素から該障害が発生した構成要素までの間に介在する各構成要素の構成種別情報と各構成要素間の関連の関連種別情報とが、前記症状が観測された構成要素から前記障害が発生した構成要素までの間に介在する順序で指定された検索式を、該症状の内容を表す症状内容情報と対応付けて記憶する対処情報記憶手段から、前記症状取得ステップにおいて取得した症状の内容と一致する症状内容情報と対応付けられた検索式を取得する検索式取得ステップと、
   前記検索式取得ステップにより取得した検索式に基づく検索処理を、前記症状取得ステップにより取得した構成要素情報を始点として実行し、特定された構成要素を前記観測された症状の原因となる障害の発生箇所の候補として抽出する障害発生箇所候補抽出ステップとを含み、
   前記障害発生箇所候補抽出ステップは、前記構成要素情報記憶手段に記憶された構成要素情報、及び、前記構成要素情報記憶手段に記憶されている識別情報と、該識別情報によって識別される構成要素と関連を有する構成要素を識別するための識別情報と、該関連の種別を表す関連種別情報とを対応付けて関連要素情報として記憶する関連要素情報記憶手段に記憶された関連要素情報のうち、前記検索式取得ステップにより取得した検索式に含まれる関連種別情報と同一の関連種別情報を含む関連要素情報と、該検索式に含まれる構成種別情報と同一の構成種別情報を含む構成要素情報とを、前記症状取得ステップにより取得した構成要素情報を始点とし、前記検索式に含まれる関連種別情報と同一の関連種別情報を含む関連要素情報に含まれる識別情報に基づき前記介在する順序で辿ることにより特定される構成要素を前記観測された症状の原因となる障害の発生箇所の候補として抽出することを特徴とするシステム管理方法。

Images