(57)【要約】  運用管理システム１２が、計算機システム１１で発生した障害の再発監視を行う管理者１０３の負担を軽減する。運用管理システム１２が、計算機システム１１で発生した一以上の検出イベントを検知し、因果律情報１６８と検出イベントとに基づいて、因果律情報１６８に含まれる第一の因果律コード１８０を抽出する。運用管理システム１２は、検出イベントの発生原因を解消させるべく計算機システム１１の構成が変更された場合、変更後の因果律情報１６８と第一の因果律コード１８０とに基づいて、変更後の因果律情報１６８に含まれる第二の因果律コード１８０を抽出し、抽出された第二の因果律コード１８０に関わる情報を管理者１０３に通知する。
2010137063.tif 000002
【特許請求の範囲】
【請求項１】
複数のノード装置を有する計算機システムの管理を行う管理サーバであって、
記憶資源と、
前記記憶資源に接続されたプロセッサと、を有し、
前記記憶資源が、症状イベントセット毎の原因特定コードを含んだイベント原因情報を記憶し、
前記原因特定コードは、症状イベントセットと原因イベントとの関係を表すデータであり、
前記症状イベントセットは、一以上の症状イベントの組み合わせであり、
前記原因イベントは、原因としてのイベントであり、
前記症状イベントは、原因イベントを原因として発生するイベントであり、
前記プロセッサは、
（ａ）一以上の第一のイベントを検知し、
（ｂ）前記一以上の第一のイベントの組み合せと一致する症状イベントセットに対応した第一の原因特定コードを、前記イベント原因情報の中から抽出し、
（ｃ）前記第一の原因特定コードが表す原因イベントを前記一以上の第一のイベントの発生原因と特定し、
（ｄ）前記一以上の第一のイベントの発生原因を解消させるべく前記計算機システムの構成が変更された場合、前記イベント原因情報を、前記計算機システムの変更後の構成に対応したイベント原因情報に変更し、
（ｅ）前記第一の原因特定コードが表す症状イベントセットと一致する症状イベントセットに対応した第二の原因特定コードを、前記変更後のイベント原因情報の中から抽出し、前記第二の原因特定コードに関わる情報を、管理者に通知する、
管理サーバ。
【請求項２】
前記プロセッサは、前記（ｅ）において、前記第二の原因特定コードが表す症状イベント及び原因イベントのそれぞれの発生元の装置間の接続関係を表した第二の接続関係情報を、管理者に通知する、
請求項１記載の管理サーバ。
【請求項３】
前記プロセッサは、前記（ｅ）において、前記第一の原因特定コードが表す症状イベント及び原因イベントのそれぞれの発生元の装置間の接続関係を表した第一の接続関係情報も、管理者に通知する、
請求項２記載の管理サーバ。
【請求項４】
前記プロセッサは、前記（ｅ）において、前記第二の原因特定コードが表す原因イベントに関する情報、及び、前記第二の原因特定コードが表す原因イベントが再発監視において重点的に監視されるイベントであることを表す情報を、管理者に通知する、
請求項１記載の管理サーバ。
【請求項５】
前記プロセッサは、
（ｆ）前記第二の原因特定コードを抽出した後に一以上の第二のイベントを検知し、
（ｇ）前記一以上の第二のイベントのうちの所定の数の第二のイベントが、前記第二の原因特定コードが表す症状イベントと一致している場合、前記第二の原因特定コードが表す症状イベントのうち前記第二のイベントと一致した症状イベントに関する情報と、前記再発兆候が表れたことを表す情報とを、管理者に通知する、
請求項１記載の管理サーバ。
【請求項６】
前記記憶資源が、前記計算機システム内に存在する装置であってイベントの発生元となり得る対象装置と、前記対象装置の上位装置及び／又は下位装置との関係を表す集約関係情報を記憶し、
前記プロセッサは、前記第一の原因特定コードが表す症状イベントの発生元の装置である第一の装置と、前記選択された原因特定コードが表す症状イベント又は原因イベントの発生元の装置である第二の装置と、前記集約関係情報とに基づいて、前記（ｅ）の処理を行う、
請求項１記載の管理サーバ。
【請求項７】
症状イベント同士が一致していれば、症状イベントセット同士が一致しており、
症状イベントの一致の条件は、症状イベントの発生元の装置が一致することであり、
前記記憶資源が、前記計算機システム内に存在する装置であってイベントの発生元となり得る対象装置と、前記対象装置の上位装置及び／又は下位装置との関係を表す集約関係情報を記憶し、
前記プロセッサは、
（ｘ１）前記（ｅ）において、前記第一の原因特定コードが表す症状イベントセットと、前記変更後のイベント原因情報から選択された原因特定コードが表す症状イベントセットとが一致するか否かを判定し、
（ｘ２）その判定において、前記第一の原因特定コードが表す症状イベントの発生元の装置である第一の装置と、前記選択された原因特定コードが表す症状イベントの発生元の装置である第二の装置とが一致するか否かの発生元判定を行い、
（ｘ３）前記発生元判定において、前記第一の装置の上位装置と前記第二の装置の上位装置とが一致していることを、前記集約関係情報から特定した場合は、前記第一の装置と前記第二の装置とは一致していると判断する、
請求項１記載の管理サーバ。
【請求項８】
症状イベント同士が一致していれば、症状イベントセット同士が一致しており、
症状イベントの一致の条件は、症状イベントの発生元の装置が一致することであり、
前記記憶資源が、前記計算機システム内に存在する装置であってイベントの発生元となり得る対象装置と、前記対象装置の上位装置及び／又は下位装置との関係を示した集約関係情報を記憶し、
前記プロセッサは、前記（ｅ）において、前記第一の原因特定コードが表す症状イベントセットと、前記変更後のイベント原因情報から選択された原因特定コードが表す症状イベントセットとが一致するか否かのイベント一致判定を行い、前記イベント一致判定において、以下の処理：
（ｙ１）前記第一の原因特定コードが表す症状イベントの発生元の装置の上位装置と、前記第一の原因特定コードが表す原因イベントの発生元の装置の上位装置とが一致していることを、前記集約関係情報から特定した場合に、その症状イベントを第一の除外イベントとする；
（ｙ２）前記選択された原因特定コードが表す症状イベントの発生元の装置の上位装置と、前記選択された原因特定コードが表す原因イベントの発生元の装置の上位装置とが一致していることを、前記集約関係情報から特定した場合に、その症状イベントを第二の除外イベントとする；
（ｙ３）前記第一の原因特定コードが表す症状イベントセットのうちの前記第一の除外イベントを除いたイベントセットと、前記選択された原因特定コードが表す症状イベントセットのうちの前記第二の除外イベントを除いたイベントセットとが一致する場合に、前記第一の原因特定コードが表す症状イベントセットと前記選択された原因特定コードが表す症状イベントセットとは一致していると判断する、
を行う、
請求項１記載の管理サーバ。
【請求項９】
前記記憶資源が、前記計算機システム内に存在する装置であってイベントの発生元となり得る仮想的な仮想装置と、前記仮想装置と関係のある物理的な物理装置との関係を示した物理装置情報を記憶し、
前記プロセッサは、前記第一の原因特定コードが表す原因イベントの発生元の装置が仮想装置である場合は、前記物理装置情報に基づいて、前記第一の原因特定コードの原因イベントの発生元の装置と関係のある物理装置を特定し、前記特定された物理装置と関係のある全ての仮想装置を特定し、前記特定された仮想装置をその原因イベントの発生元とする全ての原因特定コードを、前記第一の原因特定コードの症状イベントセットと前記変更後のイベント原因情報に含まれる原因特定コードの症状イベントセットとの比較によって抽出された原因特定コードに加えて、第二の原因特定コードとして抽出する、
請求項１記載の管理サーバ。
【請求項１０】
複数のノード装置を有する計算機システムの管理を行う管理システムであって、
前記管理システムは、
記憶資源と、
前記記憶資源に接続されたプロセッサと、を有する管理サーバと、
表示部を有する入出力装置と、を有し、
前記記憶資源が、症状イベントセット毎の原因特定コードを含んだイベント原因情報を記憶し、
前記原因特定コードは、症状イベントセットと原因イベントとの関係を表すデータであり、
前記症状イベントセットは、一以上の症状イベントの組み合わせであり、
前記原因イベントは、原因としてのイベントであり、
前記症状イベントは、原因イベントを原因として発生するイベントであり、
前記プロセッサは、
（ａ）一以上の第一のイベントを検知し、
（ｂ）前記一以上の第一のイベントの組み合せと一致する症状イベントセットに対応した第一の原因特定コードを、前記イベント原因情報の中から抽出し、
（ｃ）前記第一の原因特定コードが表す原因イベントを前記一以上の第一のイベントの発生原因と特定し、
（ｄ）前記一以上の第一のイベントの発生原因を解消させるべく前記計算機システムの構成が変更された場合、前記イベント原因情報を、前記計算機システムの変更後の構成に対応したイベント原因情報に変更し、
（ｅ）前記第一の原因特定コードが表す症状イベントセットと一致する症状イベントセットに対応した第二の原因特定コードを、前記変更後のイベント原因情報の中から抽出し、前記第二の原因特定コードに関わる情報を前記表示部に表示させることにより、前記第二の原因特定コードに関わる情報を管理者に通知する、
管理システム。
【請求項１１】
前記プロセッサは、前記（ｅ）において、前記第二の原因特定コードが表す症状イベント及び原因イベントのそれぞれの発生元の装置間の接続関係を表した第二の接続関係情報を、管理者に通知する、
請求項１０記載の管理システム。
【請求項１２】
前記プロセッサは、前記（ｅ）において、前記第一の原因特定コードが表す症状イベント及び原因イベントのそれぞれの発生元の装置間の接続関係を表した第一の接続関係情報も、管理者に通知する、
請求項１０記載の管理システム。
【請求項１３】
前記プロセッサは、前記（ｅ）において、前記第二の原因特定コードが表す原因イベントに関する情報、及び、前記第二の原因特定コードが表す原因イベントが再発監視において重点的に監視されるイベントであることを表す情報を、管理者に通知する、
請求項１０記載の管理システム。
【請求項１４】
複数のノード装置を有する計算機システムの管理を行う管理システムで実行されるコンピュータプログラムを格納する記憶媒体であって、前記コンピュータプログラムは：
前記管理システムに、一以上の第一のイベントを検知させ、
前記管理システムに、一以上の症状イベントの組み合わせである症状イベントセット毎の原因特定コードを含んだイベント原因情報の中から、前記一以上の第一のイベントの組み合せと一致する症状イベントセットに対応した第一の原因特定コードを、前記イベント原因情報の中から抽出させ、
前記管理システムに、前記第一の原因特定コードが表す原因イベントを前記一以上の第一のイベントの発生原因と特定させ、
前記管理システムに、前記一以上の第一のイベントの発生原因を解消させるべく前記計算機システムの構成が変更された場合、前記イベント原因情報を、前記計算機システムの変更後の構成に対応したイベント原因情報に変更させ、
前記管理システムに、前記第一の原因特定コードが表す症状イベントセットと一致する症状イベントセットに対応した第二の原因特定コードを、前記変更後のイベント原因情報の中から抽出させ、前記第二の原因特定コードに関わる情報を、管理者に通知させる、
ことを特徴とした記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、計算機システムの管理を行う管理サーバ及び管理システムの技術に関し、特に、障害の再発を監視する技術に関する。
【背景技術】
【０００２】
複数の機器（計算機やストレージ装置やネットワーク装置等）から構成される計算機システムを管理する技術が知られている。以下、計算機システムを管理するシステムを「運用管理システム」と呼ぶ。【０００３】
例えば、特許文献１には、計算機システムで発生した障害を検出しその障害の原因を特定する機能（根本原因解析（ＲＣＡ）機能）を有する運用管理システムが開示されている。特許文献１の開示では、運用管理システムが、原因とその原因により発生するイベント（障害の症状）との因果関係を定義した情報（因果律情報）を予め保持しておく。そして、運用管理システムは、計算機システムを構成する機器やその機器に搭載されている部品（以下、適宜「機器等」という）でイベントが発生した場合に、その発生したイベントを取得し、その取得したイベントと因果律情報とに基づいて原因を特定する。【０００４】
また、例えば、特許文献２には、計算機システムの構成が変更されたことを認識する機能を有する運用管理システムが開示されている。特許文献２の開示では、構成変更を検知するためのプログラムが、計算機システム内の各機器に配置される。運用管理システムが、構成変更に関する情報を上記プログラムから取得することにより、計算機システムにおける構成変更を認識する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】米国特許第７，１０７，１８５号明細書
【特許文献２】米国特許第７，１８８，２０１号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、計算機システムで障害が発生した場合の障害対策のプロセスは、一般に、障害検知、原因特定、原因解消及び再発監視の順序で行われる。ここで、「障害検知」とは、計算機システムで発生した障害の症状（即ち、イベント）を検知することをいう。「原因特定」とは、障害検知で検知した障害の症状を調査し、障害の原因を特定することをいう。「原因解消」とは、管理者が、原因特定で特定された原因を解消すること（それにより、障害を解消すること）をいう。「再発監視」とは、障害の解消後に、その解消された障害或いは障害解消のために採られた処置（例えば、機器等の交換）を原因とする障害（即ち、二次的な障害）が一定の潜伏期間を経て再発することを抑制するため、着目した機器等を一定期間監視することをいう。再発の一例としては、サーバ装置で発生したメモリ不良がサーバ装置の交換により解消された後に、同様のメモリ不良が交換後のサーバ装置で再び発生することや、サーバ装置の交換の際のユーザ設定の間違いによってソフトウェアが停止してしまうこと等が挙げられる。【０００７】
上記特許文献１に開示された運用管理システムは、障害検知及び原因特定を行うものである。即ち、この種の運用管理システムは、イベントを検知し、検知したイベントと因果律情報とに基づいて、その検知したイベントの原因を特定する。一方、原因解消は、通常、管理者によって行われる。即ち、運用管理システムから原因を通知された管理者が、その原因を解消するために必要な処置（例えば、機器等の交換やソフトウェアの修復等）を行う。そして、再発監視についても、通常、管理者の知見に基づき、管理者の管理の下で行われる。例えば、管理者は、因果律情報に含まれる、解消された原因（以下、「解消済み原因」）とその解消済み原因により発生していたイベントとの因果関係を参考にして、解消済み原因と何からの繋がりのあった機器等を、着目する機器等と選定し、その選定した機器等を重点的にイベントの発生を監視することにより、再発監視を行うことができる。このように、解消済み原因と何からの繋がりのあった機器等を重点的に監視することで、再発監視における管理者の負担が軽減される。【０００８】
ここで、原因解消のための処置として、計算機システムの構成に変更が生じる処置（例えば、機器等の交換等）が採られる場合がある。通常、計算機システムの構成に変更が生じると、因果律情報は、その変更後の構成に対応したものに変更される。このように、計算機システムの構成に変更が生じ、因果律情報が変更された場合、管理者が、どの機器等を重点的に監視すればよいかを容易に判断できなくなるといった問題が生じる。何故ならば、因果律情報が変更された結果、解消済み原因に関する情報が変更後の因果律情報に含まれなくなっていることが多く、また、解消済み原因により発生していたイベントに関する情報も変更後の因果律情報に含まれなくなっていることがあり、解消済み原因と何らかの繋がりのあった機器等の選定が困難となるからである。【０００９】
そこで、本発明の目的は、計算機システムで発生した障害の再発監視を行う管理者の負担を軽減することにある。
【課題を解決するための手段】
【００１０】
管理サーバが、計算機システムで発生した一以上の第一のイベントを検知し、イベント原因情報と第一のイベントとに基づいて、イベント原因情報に含まれる第一の原因特定コードを抽出する。管理サーバは、第一のイベントの発生原因を解消させるべく計算機システムの構成が変更された場合、変更後のイベント原因情報と第一の原因特定コードとに基づいて、変更後のイベント原因情報に含まれる第二の原因特定コードを抽出し、抽出された第二の原因特定コードに関わる情報を管理者に通知する。【００１１】
なお、「イベント原因情報」とは、症状イベントセット毎の原因特定コードを含んだ情報である。「症状イベントセット」は、一以上の症状イベントの組み合わせである。「原因イベント」は、原因としてのイベントである。「症状イベント」は、原因イベントを原因として発生するイベントである。【００１２】
第一のイベントの発生原因を解消させるべく計算機システムの構成が変更された場合、イベント原因情報の内容が変更される。例えば、管理サーバは、変更後のイベント原因情報に含まれる原因特定コードのうち、その症状イベントセットが、第一の原因特定コードの症状イベントセットと一致する原因特定コードを、第二の原因特定コードとして抽出することができる。【００１３】
本発明に従う管理サーバが行う処理は、管理計算機内のプロセッサがコンピュータプログラムを実行することにより、行うことができる。コンピュータプログラムは、遠隔のサーバからインストールされても良いし、記憶媒体（例えば、ＣＤ−ＲＯＭ、ＤＶＤ（Digital Versatile Disk）などの可搬型の記憶媒体）からインストールされても良い。なお、管理サーバの処理の少なくとも一部が、ハードウェア回路で実現されても良い。
【図面の簡単な説明】
【００１４】
【図１】実施例１に係る情報処理システムの全体構成の一例を示す図である。
【図２】因果律情報の一例を示す図である。
【図３】症状定義情報の一例を示す図である。
【図４】原因定義情報の一例を示す図である。
【図５】ＲＣＡプログラムが行う処理のフローチャートである。
【図６】原因解析結果表示画面の一例を示す図である。
【図７】コード関連付けプログラムが行う処理のフローチャートである。
【図８】実施例１における原因解消後の因果律情報を示す図である。
【図９】実施例１における原因解消後の症状定義情報を示す図である。
【図１０】実施例１における原因解消後の原因定義情報を示す図である。
【図１１】妥当性検証表示画面の一例を示す図である。
【図１２】コード再発監視プログラムが行う処理のフローチャートである。
【図１３】再発警告結果表示画面の一例を示す図である。
【図１４】実施例２に係る情報処理システムの全体構成の一例を示す図である。
【図１５】原因解消前の物理／論理属性関連情報を示す図である。
【図１６】原因解消後の物理／論理属性関連情報を示す図である。
【図１７】実施例２のシナリオの下で表示される妥当性検証表示画面の一例を示す図である。
【図１８】実施例３に係る情報処理システムの全体構成の一例を示す図である。
【図１９】集約関係定義情報の一例を示す図である。
【図２０】実施例３における原因解消前の因果律情報を示す図である。
【図２１】実施例３における原因解消前の症状定義情報を示す図である。
【図２２】実施例３における原因解消前の原因定義情報を示す図である。
【図２３】実施例３における原因解消後の因果律情報を示す図である。
【図２４】実施例３における原因解消後の症状定義情報を示す図である。
【図２５】実施例３における原因解消後の原因定義情報を示す図である。
【図２６】実施例３のシナリオの下で表示される妥当性検証表示画面の一例を示す図である。
【図２７】実施例４における原因解消前の因果律情報を示す図である。
【図２８】実施例４における原因解消前の症状定義情報を示す図である。
【図２９】実施例４における原因解消前の原因定義情報を示す図である。
【図３０】実施例４における原因解消後の因果律情報を示す図である。
【図３１】実施例４における原因解消後の症状定義情報を示す図である。
【図３２】実施例４における原因解消後の原因定義情報を示す図である。
【図３３】実施例４のシナリオの下で表示される妥当性検証表示画面の一例を示す図である。
【図３４】プログラムを配布するプログラム配布サーバの一例を示す図である。
【図３５】実施例２における原因解消前の因果律情報を示す図である。
【図３６】実施例２における原因解消前の症状定義情報を示す図である。
【図３７】実施例２における原因解消前の原因定義情報を示す図である。
【図３８】実施例２における原因解消後の因果律情報を示す図である。
【図３９】実施例２における原因解消後の症状定義情報を示す図である。
【図４０】実施例２における原因解消後の原因定義情報を示す図である。
【発明を実施するための形態】
【００１５】
以下、図面を参照しながら、本発明の幾つかの実施例を説明する。
【００１６】
なお、以後の説明では、「ｘｘｘテーブル」、「ｘｘｘリスト」、「ｘｘｘＤＢ」、「ｘｘｘキュー」等の表現で情報を表す。しかし、情報は、テーブル、リスト、ＤＢ、キュー等のデータ構造以外で表現されていてもよい。データ構造に依存しないことを示すために「ｘｘｘテーブル」、「ｘｘｘリスト」、「ｘｘｘＤＢ」、「ｘｘｘキュー」等を、「ｘｘｘ情報」と呼ぶことがある。また、情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いる場合があるが、これらについては互いに置換が可能である。
【００１７】
また、以後の説明では、コンピュータプログラムを主語として説明を行う場合があるが、実際には、プログラムはプロセッサ（典型的にはマイクロプロセッサ）によって実行されることで定められた処理を行う。その際、メモリ等の記憶資源や、通信ポート（通信制御装置）を用いることもある。プロセッサがプログラムを実行することによって行われる処理の説明の主語はプロセッサであってもよい。プログラムを主語として説明された処理は計算機が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。
【００１８】
また、プログラムは、プログラム配布サーバや記憶メディア等のプログラムソースから計算機にインストールされてもよい。
【実施例１】
【００１９】
図１は、実施例１に係る情報処理システム１の全体構成の一例を示す図である。【００２０】
情報処理システム１は、例えば、計算機システム１１と、運用管理システム１２とから構成される。本実施例において、計算機システム１１は、例えば、一以上の業務サーバ１０４と、一以上のストレージ装置１０８と、通信ネットワーク１１０又はＳＡＮ（Storage Area Network）１１１を構成するための一以上のネットワーク装置（図示しない）とを有する。以下、計算機システム１１を構成する機器（業務サーバ１０４やストレージ装置１０８やネットワーク装置等）を、ノード装置と呼ぶ。計算機システム１１は、業務サーバ１０４やストレージ装置１０８等だけでなく、例えばプリンタやファイルサーバ等をノード装置として有していてもよい。業務サーバ１０４とストレージ装置１０８とは、例えば、ＳＡＮ１１１を介して接続される。運用管理システム１２は、計算機システム１１を管理するためのシステムである。運用管理システム１２は、例えば、管理サーバ１０１と、入出力端末１０２とを有する。管理サーバ１０１と入出力端末１０２とは、例えば、通信ネットワーク１１０を介して接続される。なお、ＳＡＮ１１１の接続方式は、例えば、ＦＣ（ファイバチャネル）とされるが、ＦＣ以外の接続方式（例えば、ｉＳＣＳＩ等）とされてもよい。また、通信ネットワーク１１０とＳＡＮ１１１は、同一ネットワークとされてもよい。【００２１】
業務サーバ１０４は、例えば、ＣＰＵ（Central Processing Unit）１３１と、メモリ１３２と、ディスク１３３と、通信Ｉ／Ｆ（インターフェース）１３４と、ポート１３５とを有する。ストレージ装置１０８は、例えば、ＣＰＵ１４１と、メモリ１４２と、ディスク１４３と、通信Ｉ／Ｆ１４４と、ポート１４５とを有する。以下、業務サーバ１０４のディスク１３３を「サーバディスク」と呼び、ストレージ装置１０８のディスク１４３を「ストレージディスク」と呼ぶ。図示してはいないが、ストレージ装置１０８には、ストレージディスク１４３の記憶領域を基に、ＬＵ（論理ユニット）が形成される。【００２２】
管理サーバ１０１は、各ノード装置と、例えば通信ネットワーク１１０を介して接続される。管理サーバ１０１は、ノード装置から取得した種々の情報（例えば、ノード装置で発生したイベントを表す情報等）に基づいて、後述する種々の処理（例えば、障害の原因を解析する処理等）を行い、その処理結果を管理者１０３へ通知する。管理者１０３は、通知された処理結果を参照し、計算機システム１１の運用管理（例えば、障害の解消や再発監視等）を行う。【００２３】
管理サーバ１０１は、例えば、ＣＰＵ１２１と、メモリ１２２と、ディスク１２３と、通信Ｉ／Ｆ１２４とを有する。管理サーバ１０１のメモリ１２２には、例えば、構成管理プログラム１６１と、ＲＣＡプログラム１６２と、コード関連付けプログラム１６３と、コード再発監視プログラム１６４と、イベント受信プログラム１７３とが格納される。また、管理サーバ１０１のメモリ１２２には、上記の各種プログラムに加えて、例えば、構成管理情報１６７と、因果律情報１６８と、原因定義情報１６９と、症状定義情報１７０と、イベント情報１７４とが格納される。なお、メモリ１２２は、揮発性のメモリであっても不揮発性のメモリであってもよく、また、ディスク１２３上の記憶領域が、メモリ１２２の記憶領域の全部又は一部として使用されてもよい。【００２４】
なお、管理サーバ１０１は、入出力装置を有していてもよい。入出力装置は、例えば、ディスプレイやキーボードやポインタデバイス等である。また、インターフェース装置（例えば、シリアルインターフェースやイーサーネットインターフェース）が入出力装置とされてもよい。この場合、当該インターフェース装置が表示用計算機に接続され、表示用情報が表示用計算機に送信されたり、入力用情報が表示用計算機から受信されてもよい。本実施例では、入出力端末１０２が上記表示用計算機の役割を担っており、上記入出力装置での入力及び表示を代替する。【００２５】
本実施例では、運用管理システム１２は、管理サーバ１０１と入出力端末１０２とから構成されているが、必ずしもこのような構成に限られるわけではない。例えば、管理サーバ１０１自身が、入出力装置を有している場合は、運用管理システム１２は、入出力端末１０２を有している必要はなく、また、管理処理の高速化や高信頼化のために複数の計算機で管理サーバ１０１と同等の処理を実現してもよく、この場合は当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含め）が、管理システム１２を構成することになる。【００２６】
以下、運用管理システム１２のメモリ１２２に格納される情報と運用管理システム１２が行う処理とについて詳しく説明する。まず、以下に、本実施例及び他の実施例で用いられる主要な用語の説明を行う。【００２７】
（１）監視対象オブジェクト：
計算機システム１１上に存在する物理的又は論理的な装置のうち、運用管理システム１２が管理の対象とするものをいう。ここで、計算機システム１１上に存在する物理的又は論理的な装置としては、例えば、ノード装置（即ち、計算機システム１１を構成する機器であり、業務サーバ１０４やストレージ装置１０８やネットワーク装置等）や、ノード装置に搭載されている部品（サーバディスク１３３やストレージディスク１４３やポート１３５，１４５等）や、ノード装置内に形成された論理的な装置（例えば、ストレージ装置１０８に形成されたＬＵ等）や、コンピュータプログラムの実行によりノード装置上に実現された機能モジュール等が挙げられる。【００２８】
（２）データモデル：
監視対象オブジェクトに関する種々のデータ（以下、「オブジェクトデータ」）を計算機上で管理可能とするために規定された監視対象オブジェクトのモデルをいう。データモデルは、例えば、オブジェクトデータのデータ項目の組み合わせで表現される。【００２９】
ここで、オブジェクトデータには、例えば、監視対象オブジェクトの属性を示すデータや監視対象オブジェクト間の関係（接続関係、依存関係或いは包含関係）を示すデータ等が含まれる。そして、監視対象オブジェクトの属性には、例えば、監視対象オブジェクトが業務サーバ１０４或いはストレージ装置１０８である場合は、業務サーバ１０４等のＩＤや、業務サーバ１０４等の名称や、業務サーバ１０４等に割り当てられているＩＰアドレス等が含まれる。また、例えば、監視対象オブジェクトが通信ネットワーク１１０又はＳＡＮ１１１を構成するネットワーク装置（例えば、スイッチ装置）である場合は、監視対象オブジェクトの属性には、ネットワーク装置のＩＤや、ネットワーク装置が有するポートの数等が含まれる。【００３０】
（３）データエントリ：
監視対象オブジェクトごとに、データモデルに従って生成されたデータをいう。即ち、データモデルを定義付ける各データ項目のそれぞれの値（対象とする監視対象オブジェクトに関する値）の組み合わせが、データエントリとなる。例えば、データモデルが、監視対象オブジェクトのＩＤと、ＩＰアドレスと、接続関係を有する装置のＩＤとの組み合わせで表現されている場合、図１におけるストレージ装置１に関するデータエントリは、ストレージ装置１のＩＤ（例えば“ＳＴ１”）と、ストレージ装置１に割り当てられているＩＰアドレスと、ストレージ装置１と接続関係を有する装置（即ち、業務サーバ１、業務サーバ２及び業務サーバ３）のそれぞれのＩＤ（例えば“ＳＶ１”、“ＳＶ２”及び“ＳＶ３”）との組み合わせとなる。【００３１】
管理サーバ１０１は、データエントリを参照することで、計算機システム１１上に存在する監視対象オブジェクトを知ることができるとともに、各監視対象オブジェクトのオブジェクトデータ（つまり、その装置の属性や、他の装置との接続関係）を知ることができる。【００３２】
（４）イベント：
監視対象オブジェクトにおいて発生し得る事象のことをいう。本実施例では、イベントは、特に、障害に関わる事象を意味するものとする。例えば、“ストレージディスク内のデータが読み出せない”といった事象や、“ストレージディスクから読み出したデータが壊れている”といった事象等が、イベントとなる。【００３３】
（５）イベントモデル：
イベントに関する種々のデータ（以下、「イベントデータ」）を計算機上で管理可能とするために規定されたイベントのモデルをいう。イベントモデルは、例えば、イベントデータのデータ項目の組み合わせで表現される。【００３４】
ここで、イベントデータには、例えば、イベントのＩＤや、イベント種別や、イベントの発生時間や、イベントの発生場所（即ち、イベントが発生した監視対象オブジェクト）等が含まれる。イベント種別としては、例えば、“サーバディスクの故障”や“ストレージディスクの故障”や“通信ＩＦの故障”等がある。上述したイベント“ストレージディスク内のデータが読み出せない”や“ストレージディスクから読み出したデータが壊れている”は、ともに“ストレージディスクの故障”に分類される。なお、イベントデータには、イベントの発生場所の種別（即ち、イベントが発生した監視対象オブジェクトの種別）が含まれてもよい。イベントの発生場所の種別としては、例えば、“業務サーバ”や“ストレージ装置”や“サーバディスク”や“ストレージディスク”等がある。図１における業務サーバ１，２，３は、ともに“業務サーバ”に分類される。【００３５】
（６）イベントエントリ：
或るイベント（実際に発生したイベント或いは発生し得るイベント）について、イベントモデルに従って生成されたデータをいう。即ち、イベントモデルを定義付ける各データ項目のそれぞれの値（対象とするイベントに関する値）の組み合わせが、イベントエントリとなる。例えば、イベントモデルが、イベントのＩＤと、イベント種別と、イベントの発生場所との組み合わせで表現されている場合、ストレージ装置１のストレージディスク１４３で発生した或いは発生し得る“ストレージディスク内のデータが読み出せない”というイベント（イベントＡとする）のイベントエントリは、イベントＡのＩＤと、イベントＡの種別である“ストレージディスクの故障”と、イベントＡの発生場所であるストレージ装置１のストレージディスク１４３を示すデータ（例えば、“ＳＴ１−Ｄ２”）との組み合わせとなる。【００３６】
なお、本実施例及び他の実施例の説明において、イベントとそのイベントに関するイベントエントリとは、それぞれ対応する名称が付与されるものとする。例えば、イベントの名称が“Ａイベント”である場合は、Ａイベントに関するイベントエントリの名称は“Ａイベントエントリ”である。【００３７】
（７）イベント伝播モデル：
イベントモデル（特に、イベント種別とイベントの発生場所の種別との組み合わせで表現されるモデル（イベント種別がイベントの発生場所をも特定できるものである場合はイベント種別で表現されるモデル））を用いてイベント間の伝播関係を定義したモデルのことをいう。イベント伝播モデルには、例えば、“ストレージディスクの故障”が“サーバディスクの故障”に伝播する等の伝播関係が定義される。【００３８】
なお、上記定義のうち、「ｘｘｘモデル」と「ｘｘｘエントリ」は、オブジェクト指向言語又は開発環境により開発されることを想定して命名したが（即ち、「ｘｘｘモデル」は「クラス」に相当し、「ｘｘｘエントリ」は「インスタンス」に相当する）、実装形式はこれに限られない。「ｘｘｘエントリ」は、「ｘｘｘモデル」に従う具体的情報であり、従って、データエントリに対応する装置、部品、プログラム等についてのオブジェクトデータが管理サーバ１０１のメモリ１２２に格納されていれば良い。【００３９】
まず、管理サーバ１０１のメモリ１２２に格納される各種の情報１６７，１６８，１６９，１７０，１７４について説明する。【００４０】
構成管理情報１６７は、計算機システム１１の構成を示す情報、即ち、計算機システム１１がどんなノード装置によって構成されているかや、各ノード装置の構成がどのようになっているか（例えば、ノード装置にはどんな部品が搭載されているか）や、ノード装置間或いは部品間の接続関係がどうなっているかや、ノード装置と部品との間の包含関係がどうなっているか等を示す情報のことをいう。ノード装置の構成には、ノード装置の物理的な属性（製造番号やＭＡＣ（Media Access Control）アドレスなど）、ノード装置の論理的な属性（ＩＰアドレスや性能情報など）及びノード装置内の部品構成等が含まれる。【００４１】
本実施例では、計算機システム１１上に存在する監視対象オブジェクトのそれぞれに関するデータエントリの集合が、計算機システム１１の構成を示していることから、上記データエントリの集合が、構成管理情報１６７として用いられる。【００４２】
イベント情報１７４は、計算機システム１１で発生したイベントに関するイベントエントリを一以上含んだ情報である。イベント情報１７４は、例えば、次のようにして更新される。即ち、或るノード装置においてイベントが発生すると、そのノード装置は、発生したイベントに関するイベントエントリを生成し、生成したイベントエントリを、管理サーバ１０１へ送信する。管理サーバ１０１のイベント受信プログラム１７３は、ノード装置から受信したイベントエントリをイベント情報１７４に追加することで、イベント情報１７４を更新する。なお、イベント受信プログラム１７３は、上記のように、ノード装置からイベントエントリを受信したタイミングでイベント情報１７４を更新するという方法に代えて、次のように処理してもよい。即ち、イベント受信プログラム１７３は、定期的又は不定期的に、イベントが発生したか否か（即ち、イベントエントリが生成されているか否か）を各ノード装置に問い合わせて、イベントエントリが生成されている場合に、その生成されているイベントエントリを取得して、イベント情報１７４に追加するようにしてもよい。また、管理サーバ１０１と各ノード装置との間でのイベントエントリの受け渡しは、通信ネットワーク１１０経由で行われてもよいし、媒体経由で行われてもよい。【００４３】
図２は、因果律情報１６８の一例を示す図である。【００４４】
因果律情報１６８は、一以上のイベントと、それら一以上のイベントが発生した場合の原因との関係を示した情報である。原因も一種のイベントである。そこで、以下、発生したイベントの原因としてのイベントを「原因イベント」と呼ぶ。また、原因イベントを原因として発生するイベントの組み合わせを「症状イベントセット」と呼ぶ。更に、症状イベントセットに属するそれぞれのイベントを「症状イベント」と呼ぶ。症状イベントは、原因イベントを原因として発生するイベントである。【００４５】
因果律情報１６８は、例えば、図２に示したような行列形式で表現される。行項目２０１には、症状イベントとなり得るイベント（以下、「症状イベント候補」）のＩＤ（ｅ１、ｅ２、ｅ３・・・ｅｍ）が列挙される。また、列項目２０４には、原因イベントのＩＤ（ｐ１・・・ｐｎ）が列挙される。行列の各値は、対応する行項目２０１の症状イベント候補が、対応する列項目２０４の原因イベントに対する症状イベントであるか否かを示している。本実施例では、値が“１”の症状イベント候補が、症状イベントである。【００４６】
因果律情報１６８における各列が、症状イベント（症状イベントセット）と原因イベントとの一つの因果関係を示している。例えば、図２における原因イベントｐ１に対応する列は、症状イベント候補ｅ１，ｅ２，ｅ３に対応する値がそれぞれ“１”であり、症状イベント候補ｅ１，ｅ２，ｅ３のそれぞれが、原因イベントｐ１に対する症状イベントであることを示している（図中の“…”の部分の値は、全て“０”である。以下同じ。）。つまり、症状イベントｅ１，ｅ２，ｅ３が発生した場合は、ｐ１が原因イベントと断定されることになる。以下、この一つの因果関係を示すデータ（各列の値と、その列に対応する原因イベントのＩＤとを含んだデータ）１８０を「因果律コード」と呼ぶ。本実施例では、因果律コード１８０の内容を“［症状イベントのＩＤ１、症状イベントのＩＤ２・・・］→原因イベントのＩＤ”のように表現する。この表現方法を用いた場合、図２における原因イベントｐ１に対応する列が示す因果律コード１８０は、“［ｅ１，ｅ２，ｅ３］→ｐ１”と表現される。【００４７】
図３は、症状定義情報１６９の一例を示す図である。【００４８】
症状定義情報１６９は、因果律情報１６８の行項目２０１として列挙されたイベント（症状イベント候補）のそれぞれに関するイベントエントリを含んだ情報である。図３の例では、各行が、一つのイベントエントリを示している。各イベントエントリには、例えば、対応する症状イベント候補のＩＤ２１１と、対応する症状イベント候補のイベント種別２１３と、対応する症状イベント候補が発生する監視対象オブジェクト（以下、「発生元」）を識別するデータ（以下、「発生元識別データ」）２１２とが含まれる。【００４９】
図４は、原因定義情報１７０の一例を示す図である。【００５０】
原因定義情報１７０は、因果律情報１６８の列項目２０４として列挙された原因イベントのそれぞれに関するイベントエントリを含んだ情報である。図４の例では、図３と同様に、各行が、一つのイベントエントリを示しており、各イベントエントリには、例えば、対応する原因イベントのＩＤ２２１と、対応する原因イベントのイベント種別２２３と、対応する原因イベントの発生元識別データ２２２とが含まれる。なお、上記因果律情報、症状定義情報、及び原因定義情報はどのようなデータ構造であってもよく、一つの情報として統合されていてもよい。また、上記因果律情報、症状定義情報、及び原因定義情報は表現形式として、ルール形式によって一つ以上の症状に対する原因を表現してもよい。【００５１】
以下、運用管理システム１２が行う処理について説明する。【００５２】
構成管理プログラム１６１は、ＳＮＭＰ（Simple Network Management Protocol）や各ノード装置が提供するＡＰＩ（Application Programming Interface）などを用いて必要な情報を取得し、構成管理情報１６７を生成する。計算機システム１１の構成が変更された場合は、構成管理プログラム１６１は、変更後の構成に対応するものとなるように、構成管理情報１６７の内容を更新する。【００５３】
図５は、ＲＣＡプログラムが行う処理のフローチャートである。【００５４】
ＲＣＡプログラム１６２が起動されると、ＲＣＡプログラム１６２は、まず、イベントモデル、イベント伝播モデル及び構成管理情報１６７に基づいて、因果律情報１６８、症状定義情報１６９及び原因定義情報１７０を作成する（Ｓ３０１）。【００５５】
その後、ＲＣＡプログラム１６２は、イベント情報１７４の更新を随時チェックすることにより、計算機システム１１内で発生するイベントを監視する（Ｓ３０２）。【００５６】
計算機システム１１内でイベントが発生すると（本実施例では、監視対象オブジェクトでイベントが発生すると）、イベント受信プログラム１７３は、その発生したイベントのイベントエントリを受信する。そして、イベント受信プログラム１７３は、受信したイベントエントリをイベント情報１７４へ追加する。【００５７】
イベント情報１７４が更新されると、ＲＣＡプログラム１６２は、新たにイベント情報１７４に追加されたイベントエントリを取得する。これにより、ＲＣＡプログラム１６２は、計算機システム１１で発生したイベントを検知する。例えば、ＲＣＡプログラム１６２は、イベント情報１７４に含まれる複数のイベントエントリのうちの一以上（例えば、現在から所定時間前までの間に追加されたもの）を、新たに追加されたイベントエントリとして取得することができる。以下、ＲＣＡプログラム１６２が検知した一以上のイベント（上記取得された一以上のイベントエントリのそれぞれが示すイベント）の組み合わせを「検出イベントセット」と呼ぶ。また、ＲＣＡプログラム１６２が検知した一以上のイベントのそれぞれを「検出イベント」と呼ぶ。即ち、検出イベントは、検出イベントセットに属するイベントである。【００５８】
次に、ＲＣＡプログラム１６２は、因果律情報１６８を参照して検出イベントの原因を解析することにより、計算機システム１１で発生した障害の根本原因を特定する（Ｓ３０３）。具体的には、ＲＣＡプログラム１６２は、因果律情報１６８に含まれる因果律コード１８０のそれぞれについて、その症状イベントセットが、検出イベントセットと一致するか否かを判定する。ここで、症状イベントセットと検出イベントセットとが一致するか否かは、組み合わせに属するイベント同士（対応するもの同士）が一致するか否かを判定することにより行われる。また、症状イベントと検出イベントとが一致するか否かは、それぞれに関するイベントエントリの全部又は一部の情報（例えば、発生元識別データとイベント種別）が一致するか否かを判定することにより行われる。そして、ＲＣＡプログラム１６２は、その症状イベントセットが検出イベントセットと一致した因果律コード１８０（以下、「発火コード」）の原因イベントを、計算機システム１１で発生した障害の根本原因と断定する。【００５９】
以下、因果律情報１６７の列項目２０４に列挙された原因イベントのうち、実際に原因と断定されたイベント（即ち、発火コードの原因イベント）を「断定原因イベント」と呼ぶ。また、検出イベントセットと一致した症状イベントセット（即ち、発火コードの症状イベントセット）を「検出症状イベントセット」と呼ぶ。更に、検出症状イベントセットに属するイベント（即ち、発火コードの症状イベント）のそれぞれを「検出症状イベント」と呼ぶ。つまり、検出症状イベントセットに属するイベント（検出症状イベント）の全てが計算機システム１１で発生したことにより、断定原因イベントが、障害の根本原因と断定されたことになる。【００６０】
その後、ＲＣＡプログラム１６２は、管理者１０３に障害の原因を通知するための画面（以下、「原因解析結果表示画面」）の生成に必要となる種々の情報を収集し、その収集した情報に基づいて、原因解析結果表示画面を生成する（Ｓ３０４）。そして、ＲＣＡプログラム１６２は、生成された原因解析結果表示画面を入出力端末１０２へ送信する。原因解析結果表示画面を受信した入出力端末１０２は、受信した原因解析結果表示画面を表示部１６５に表示する。なお、ＲＣＡプログラム１６２は、入出力端末１０２に原因解析結果表示画面を表示させることに加えて、電子メールや電話などにより、管理者１０３に対して、障害の原因を特定した旨を通知してもよい。ここで、図６を参照して、原因解析結果表示画面について説明する。【００６１】
図６は、原因解析結果表示画面１００１の一例を示す図である。【００６２】
原因解析結果表示画面１００１には、例えば、システムトポロジの表示領域４０１と、検出症状イベントエントリの一覧の表示領域４０４と、断定原因イベントエントリの一覧の表示領域４０５とが設けられる。また、原因解析結果表示画面１００１には、確定ボタン４０２と取消ボタン４０３とが設けられる。これらのボタン４０２，４０３により、障害対策のプロセスを原因特定から原因解消に進めるかどうかを管理者１０３に選択させることができる。【００６３】
システムトポロジの表示領域４０１には、発火コードに関わる監視対象オブジェクトの接続関係が表示される。ここで、発火コードに関わる監視対象オブジェクトとは、発火コードの症状イベント（即ち、検出症状イベント）の発生元（検出症状イベントエントリの発生元識別データ２１２で示される監視対象オブジェクト）、及び、発火コードの原因イベント（即ち、断定原因イベント）の発生元（断定原因イベントエントリの発生元識別データ２２２で示される監視対象オブジェクト）のそれぞれをいう。従って、システムトポロジの表示領域４０１には、検出症状イベントの発生元と断定原因イベントの発生元との接続関係が表示される。この接続関係は、構成管理情報１６７を参照することにより得られる。なお、システムトポロジの表示領域４０１には、例えば、検出症状イベントの発生元或いは断定原因イベントの発生元と包含関係のある監視対象オブジェクト（即ち、発生元がストレージディスク１４３であれば、それを搭載するストレージ装置１０８）も表示される。【００６４】
検出症状イベントエントリの一覧の表示領域４０４には、一以上の検出症状イベントエントリのそれぞれについて、そのイベントエントリに含まれる全部又は一部の情報（本実施例では、発生元識別データ４３１とイベント種別４３２）が表示される。【００６５】
断定原因イベントエントリの一覧の表示領域４０５には、断定原因イベントエントリに含まれる全部又は一部の情報（本実施例では、発生元識別データ４４１とイベント種別４４２）が表示される。【００６６】
再び図５を参照する。その後、ＲＣＡプログラム１６２は、計算機システム１１の構成が変更されたか否かを判定する（Ｓ３０５）。【００６７】
計算機システム１１の構成が変更された場合は（Ｓ３０５：変更あり）、ＲＣＡプログラム１６２は、ステップＳ３０１の処理を行う。即ち、ＲＣＡプログラム１６２は、変更後の構成に対応した因果律情報（即ち、原因解消後の因果律情報）１６８を生成する。ここで、通常、原因解消前の因果律情報１６８は、メモリ１２２から削除される。その際、原因解消前の因果律情報１６８に含まれる発火コードについては、例えばメモリ１２２に記憶される。【００６８】
一方、計算機システム１１の構成が変更されなかった場合は（Ｓ３０５：変更なし）、ＲＣＡプログラム１６２は、ステップＳ３０２の処理を行う。即ち、ＲＣＡプログラム１６２は、因果律情報１６８を変更せずに、再度、計算機システム１１で発生するイベントの監視を行う。【００６９】
なお、構成管理プログラム１６１は、計算機システム１１の構成変更を検出した際、構成管理情報１６７を更新するとともに、ＲＣＡプログラム１６２に対して、構成が変更された旨を通知することができる。ＲＣＡプログラム１６２は、上記構成が変更された旨の通知を受けた場合に、計算機システム１１の構成が変更されたと判定し、ステップＳ３０１の処理を行うようにしてもよい。【００７０】
以上が、ＲＣＡプログラム１６２が行う処理の説明である。この処理により、障害対策のプロセスにおける、障害検知及び原因特定が行われる。そして、原因解析結果表示画面１００１によって原因を把握した管理者は、原因を解消するために必要な処置を行う。本実施例では、原因を解消するための処置として、計算機システム１１の構成に変更が生じる処置（例えば、ストレージ装置１の交換等）が採られるものとする。【００７１】
本実施例に係る運用管理システム１２は、再発監視において重点的に監視する対象オブジェクト或いはイベントを決定し、それに基づいて障害の再発兆候の有無を監視し、再発兆候が表れた場合にその情報を管理者１０３へ通知することで、管理者１０３の再発監視における負担を軽減することができる。上記再発監視における管理者１０３の負担軽減のための処理は、コード関連付けプログラム１６３及びコード再発監視プログラム１６４によって行われる。【００７２】
図７は、コード関連付けプログラム１６３が行う処理のフローチャートである。【００７３】
コード関連付けプログラム１６３は、起動された後、ＲＣＡプログラム１６２が図５のステップＳ３０３で原因イベントを断定するまで待機する（Ｓ３１１）。【００７４】
コード関連付けプログラム１６３は、ＲＣＡプログラム１６２が原因イベントを断定すると、コード関連付けプログラム１６３は、発火コード（断定された原因イベント（即ち、断定原因イベント）を含んだ因果律コード１８０）を、ＲＣＡプログラム１６２から取得する（Ｓ３１２）。そして、コード関連付けプログラム１６３は、ＲＣＡプログラム１６２が、原因解消後の因果律情報１６８を生成するまで、再度待機する（Ｓ３１３）。【００７５】
原因解消後の因果律情報１６８が生成されると、コード関連付けプログラム１６３は、原因解消後の因果律情報１６８をＲＣＡプログラム１６２から受信する（Ｓ３１４）。【００７６】
その後、コード関連付けプログラム１６３は、ステップＳ３１４で取得した原因解消後の因果律情報１６８から、ステップＳ３１２で取得した発火コードに関連する因果律コード１８０を抽出する（Ｓ３１５）。以下、原因解消後の因果律情報１６８から抽出された、発火コードに関連する因果律コード１８０を「監視コード」と呼ぶ。また、監視コードの原因イベントを「監視原因イベント」と呼ぶ。更に、監視コードの症状イベントセットを「監視症状イベントセット」と呼び、監視コードの症状イベント（即ち、監視症状イベントセットに属するイベント）を「監視症状イベント」と呼ぶ。【００７７】
監視コードは、再発監視のプロセスにおいて、重点的に監視する監視対象オブジェクト或いはイベントを選定するための情報として用いられる。本実施例では、監視原因イベントが、重点的に監視されるイベントとなる。また、それに付随して、監視症状イベント、監視原因イベントの発生元及び監視症状イベントの発生元のそれぞれも、重点的に監視されることになる。即ち、運用管理システム１２（コード再発監視プログラム１６４）は、監視原因イベントが発生することを障害の再発ととらえて、障害の再発兆候の有無を監視するために、監視症状イベントの発生を監視することになる。【００７８】
例えば、コード関連付けプログラム１６３は、原因解消後の因果律情報１６８に含まれる因果律コード１８０のうち、その症状イベントセットが、発火コードの症状イベントセットと一致する因果律コード１８０を、監視コードとして抽出することができる。ここで、イベントセットが一致するか否かは、上述したように、イベントセットに属するイベント同士（対応するもの同士）が一致するか否かを判定することにより行われる。そして、イベントが一致するか否かは、それぞれに関するイベントエントリの全部又は一部の情報（例えば、発生元識別データとイベント種別）が一致するか否かを判定することにより行われる。【００７９】
このように、その症状イベントセットが検出症状イベントセットと一致する因果律コード１８０が監視コードとして抽出される理由は、例えば、交換前の機器等が他の機器等に対して何らかの機能を提供していた場合は、交換後の機器等も、同様の機能を上記他の機器等に対して提供する場合が多いということに基づいている。つまり、上記他の機器等で検出症状イベントが発生していた場合、その検出症状イベントが発生したのは（つまり、イベントが伝播したのは）、機能の提供関係があったからと考えることができる。そして、交換後の機器等も交換前の機器等と同様の機能を提供するものであれば、交換前の機器等で発生した原因イベントと同等のイベントが交換後の機器等で発生した場合、そのイベントが伝播し、上記他の機器等において、原因解消前に発生した検出症状イベントが再発する可能性があるからである。【００８０】
その後、コード関連付けプログラム１６３は、監視コードを抽出できたか否かを判定する（Ｓ３１６）。【００８１】
監視コードの抽出ができなかった場合は（Ｓ３１６：失敗）、コード関連付けプログラム１６３は、ステップＳ３１３の処理を行う。即ち、コード関連付けプログラム１６３は、原因解消後の因果律情報１６８が生成されるまで待機する。【００８２】
一方、監視コードの抽出ができた場合は（Ｓ３１６：成功）、コード関連付けプログラム１６３は、管理者１０３に原因解消の妥当性を検証させるための画面（以下、「妥当性検証表示画面」）の生成に必要となる種々の情報を収集し、その収集した情報に基づいて、妥当性検証表示画面を生成する（Ｓ３１７）。そして、コード関連付けプログラム１６３は、生成された妥当性検証表示画面を入出力端末１０２へ送信する。妥当性検証表示画面を受信した入出力端末１０２は、受信した妥当性検証表示画面を表示部１６５に表示する。なお、コード関連付けプログラム１６３は、上述した原因解析結果表示画面１００１の場合と同様に、入出力端末１０２に妥当性検証表示画面を表示させることに加えて、電子メールや電話などにより、管理者１０３に対して、原因解消の妥当性を検証させる準備が整った旨を通知してもよい。妥当性検証表示画面については、後に図１１を参照して説明する。【００８３】
その後、コード関連付けプログラム１６３は、コード再発監視プログラム１６４に監視コードを通知し（Ｓ３１８）、再びステップＳ３１１で待機する。【００８４】
図１１は、妥当性検証表示画面１００２の一例を示す図である。【００８５】
妥当性検証表示画面１００２には、例えば、システムトポロジの表示領域５０１と、検出症状イベントエントリの一覧の表示領域５０４と、断定原因イベントエントリの一覧の表示領域５０５と、監視原因イベントエントリの一覧の表示領域５０６とが設けられる。また、妥当性検証表示画面１００２には、確定ボタン５０２と取消ボタン５０３とが設けられる。これらのボタン５０２，５０３により、障害対策のプロセスを再発監視に進めるかどうかを管理者１０３に選択させることができる。【００８６】
これらの表示領域のうち、検出症状イベントエントリの一覧の表示領域５０４及び断定原因イベントエントリの一覧の表示領域５０５のそれぞれに表示される情報は、原因解析結果表示画面１００１で表示された情報と実質的に同じである。【００８７】
システムトポロジの表示領域５０１には、発火コードに関わる監視対象オブジェクト及び監視コードに関わる監視対象オブジェクトのそれぞれの接続関係が表示される。ここで、発火コードに関わる監視対象オブジェクトとは、上述したように、検出症状イベントの発生元及び断定原因イベントの発生元のそれぞれをいう。また、監視コードに関わる監視対象オブジェクトとは、監視コードの症状イベント（即ち、監視症状イベント）の発生元（監視症状イベントエントリの発生元識別データ２１２で示される監視対象オブジェクト）、及び、監視コードの原因イベント（即ち、監視原因イベント）の発生元（監視原因イベントエントリの発生元識別データ２２２で示される監視対象オブジェクト）のそれぞれをいう。なお、監視症状イベントと検出症状イベントとは一致するため、それらの発生元は同じである。例えば、システムトポロジの表示領域５０１において、発火コードに関わる監視対象オブジェクト（つまり、障害解消前のもの）が点線で描かれ、監視コードに関わる監視対象オブジェクト（つまり、障害解消後のもの）が実線で描かれる。このように表示することで、管理者が、監視対象オブジェクトが障害解消によってどのように変更されたかを容易に理解できるようになる。【００８８】
監視原因イベントエントリの一覧の表示領域５０６には、監視原因イベントエントリに含まれる全部又は一部の情報（本実施例では、発生元識別データ５５１とイベント種別５５２）が表示される。管理者は、表示領域５０６を見ることにより、重点的に監視するイベントとされた監視原因イベントに関する情報を知ることができる。【００８９】
図１２は、コード再発監視プログラム１６４が行う処理のフローチャートである。【００９０】
コード再発監視プログラム１６４は、起動された後、コード関連付けプログラム１６３から監視コードを通知されるまで待機する（Ｓ３２１）。【００９１】
コード関連付けプログラム１６３が図７のステップＳ３１８の処理を実行することにより、コード再発監視プログラム１６４は、監視コードを受信する（Ｓ３２２）。【００９２】
その後、コード再発監視プログラム１６４は、イベント情報１７４の更新を随時チェックすることにより、計算機システム１１内で発生するイベントを監視する（Ｓ３２３）。このイベントの監視は、所定の監視期間（例えば、運用管理システム１２が原因の解消を検知してから一定期間）が経過するまで続けられる。【００９３】
なお、このコード再発監視プログラム１６４が行うイベントの監視は、ＲＣＡプログラム１６２が図５のステップＳ３０２で行うイベントの監視と同様の方法で行われる。即ち、計算機システム１１内でイベントが発生すると、そのイベントに関するイベントエントリがイベント情報１７４に追加されるが、コード再発監視プログラム１６４は、その追加されたイベントエントリをイベント情報１７４から取得することにより、計算機システム１１で発生したイベントを検知する。以下、コード再発監視プログラム１６４が検知した一以上のイベントの組み合わせを「再発監視時イベントセット」と呼ぶ。また、コード再発監視プログラム１６４が検知した一以上のイベント（即ち、再発監視時イベントセットに属するイベント）のそれぞれを「再発監視時イベント」と呼ぶ。【００９４】
監視期間が経過する前にイベントを検知した場合（Ｓ３２４：監視期間内）は、コード再発監視プログラム１６４は、再発監視時イベントエントリ（イベント情報１７４から取得したイベントエントリ）と、ステップＳ３２２で受信した監視コードとに基づいて、再発兆候があるか否かを判定する。具体的には、例えば、コード再発監視プログラム１６４は、再発監視時イベントセットと監視症状イベントセット（監視コードの症状イベントセット）とが、少なくとも一部において一致している場合（例えば、再発監視時イベントのいずれかと監視症状イベントのいずれかとが一致している場合）に、再発兆候があると判定することができる。以下、再発監視時イベントのいずれかと一致した監視症状イベント、即ち、再発した監視症状イベントを「再発症状イベント」と呼ぶ。【００９５】
再発兆候があると判定された場合、コード再発監視プログラム１６４は、管理者１０３に再発兆候を通知するための画面（以下、「再発警告結果表示画面」）の生成に必要となる種々の情報を収集し、その収集した情報に基づいて、再発警告結果表示画面を生成する（Ｓ３２６）。そして、コード再発監視プログラム１６４は、生成された再発警告結果表示画面を入出力端末１０２へ送信する。再発警告結果表示画面を受信した入出力端末１０２は、受信した再発警告結果表示画面を表示部１６５に表示する。なお、コード再発監視プログラム１６４は、上述した原因解析結果表示画面１００１や妥当性検証表示画面１００２の場合と同様に、入出力端末１０２に再発警告結果表示画面を表示させることに加えて、電子メールや電話などにより、管理者１０３に対して、再発兆候がある旨を通知してもよい。再発警告結果表示画面については、後に図１３を参照して説明する。【００９６】
所定の監視期間が経過した場合は（Ｓ３２４：監視期間外）、コード再発監視プログラム１６４は、再発監視を終了する（Ｓ３２７）。その後、再び、ステップＳ３２１の処理が行われる。なお、コード再発監視プログラム１６４は、所定の監視期間が経過したことを管理者１０３に通知することができる。【００９７】
図１３は、再発警告結果表示画面１００３の一例を示す図である。【００９８】
再発警告結果表示画面１００３には、例えば、システムトポロジの表示領域６０１と、検出症状イベントエントリの一覧の表示領域６０４と、断定原因イベントエントリの一覧の表示領域６０５と、監視原因イベントエントリの一覧の表示領域６０６と、再発症状イベントエントリの一覧の表示領域６０７とが設けられる。【００９９】
これらの表示領域のうち、システムトポロジの表示領域６０１、検出症状イベントエントリの一覧の表示領域６０４、断定原因イベントエントリの一覧の表示領域６０５、及び監視原因イベントエントリの一覧の表示領域６０６のそれぞれに表示される情報は、妥当性検証表示画面１００２で表示された情報と実質的に同じである。【０１００】
再発症状イベントエントリの一覧の表示領域６０７には、一以上の再発症状イベントエントリのそれぞれについて、そのイベントエントリに含まれる全部又は一部の情報（本実施例では、発生元識別データ６６１とイベント種別６６２）が表示される。管理者は、表示領域６０７を見ることにより、再発兆候があるとの判断の根拠となったイベント（再発症状イベント）に関する情報を知ることができる。【０１０１】
以上が、コード関連付けプログラム１６３及びコード再発監視プログラム１６４が行う処理の説明である。【０１０２】
次に、これまで説明してきた運用管理システム１２の処理について、下記（Ａ１）〜（Ｄ１）の一連のシナリオを想定して説明する。なお、以下のシナリオは一例に過ぎず、本実施例の適用範囲がこれに限られるものではない。【０１０３】
（Ａ１）図１に示されるように、管理者１０３は、管理サーバ１０１を用いて、三台の業務サーバ１０４（業務サーバ１、業務サーバ２及び業務サーバ３）と一台のストレージ装置１０８（ストレージ装置１）とが接続されている計算機システム１１を、運用管理している。ここで、業務サーバ１，２，３は、それぞれが利用するデータを、ストレージ装置１のストレージディスク１４３に格納している。また、ストレージ装置１０８における“ストレージディスクの故障”が、そのストレージ装置１０８を利用する業務サーバ１０４における“サーバディスクの故障”に伝播することが、イベント伝播モデルで定義されている。【０１０４】
（Ｂ１）運用開始後、ストレージ装置１のストレージディスク１４３の故障が原因で、各業務サーバ１，２，３のそれぞれのサーバディスク１３３で、サーバディスク１３３が故障するイベントが発生した。以下、業務サーバ１、業務サーバ２、業務サーバ３のそれぞれのサーバディスク１３３で発生する、サーバディスク１３３の故障イベントを、それぞれ、「サーバディスク故障イベント１」、「サーバディスク故障イベント２」、「サーバディスク故障イベント３」と呼ぶ。サーバディスク故障イベント１，２，３を検出したＲＣＡプログラム１６２は、図５の処理を行って、原因イベントが、ストレージ装置１のストレージディスク１４３が故障するイベント（以下、「ストレージディスク故障イベント１」）であると断定し、障害の原因が、ストレージ装置１のストレージディスク１４３にあることを特定した。【０１０５】
（Ｃ１）原因解析結果表示画面１００１により障害の原因を知った管理者１０３は、原因を解消するため、ストレージ装置１を、ストレージ装置１とは異なるストレージ装置２に交換し、各業務サーバ１，２，３が、ストレージ装置２のストレージディスク１４３にアクセスできるように、ストレージ装置２の設定を行った。【０１０６】
（Ｄ１）上記（Ｃ１）による原因解消から数時間経過後、ストレージ装置２のストレージディスク１４３の設定に間違いがあったため、業務サーバ１のサーバディスク１３３で、サーバディスク故障イベント１が再発した。再発警告結果表示画面１００３により再発兆候を認識した管理者１０３は、ストレージ装置２の再調整を行った。その後、上記（Ｃ１）による原因解消から所定の監視期間が経過したため、コード再発監視プログラム１６３は、再発監視の終了を管理者１０３に通知した。【０１０７】
上記シナリオ（Ａ１）〜（Ｄ１）に従って、実施例１をより具体的に説明する。【０１０８】
図１において、計算機システム１１の運用が開始された後、管理者１０３は、管理サーバ１０１上のイベント受信プログラム１７３、構成管理プログラム１６１、ＲＣＡプログラム１６２、コード関連付けプログラム１６３及びコード再発監視プログラム１６４のそれぞれを起動させる。【０１０９】
ＲＣＡプログラム１６２は、図５のステップＳ３０１を実行することで、図２〜図４の各情報を生成する。即ち、図２〜図４は、原因解消前の因果律情報１６８、症状定義情報１６９、原因定義情報１７０を示している。【０１１０】
ここで、図３における“ＳＶ１−Ｄ１”、“ＳＶ２−Ｄ１”、“ＳＶ３−Ｄ１”は、それぞれ、業務サーバ１のサーバディスク１３３を示す発生元識別データ、業務サーバ２のサーバディスク１３３を示す発生元識別データ、業務サーバ３のサーバディスク１３３を示す発生元識別データである。また、“Ｅ１”は、イベント種別“サーバディスクの故障”を意味している。従って、イベントｅ１，ｅ２，ｅ３は、それぞれ、サーバディスク故障イベント１、サーバディスク故障イベント２、サーバディスク故障イベント３を意味する。また、図４における“ＳＴ１−Ｌ１”は、ストレージ装置１のストレージディスク１４３を示す発生元識別データである。また、“Ｐ１”は、イベント種別“ストレージディスクの故障”を意味している。従って、イベントｐ１は、ストレージディスク故障イベント１を意味する。【０１１１】
その後、ＲＣＡプログラム１６２は、サーバディスク故障イベント１，２，３を検知し、因果律情報１６８を参照して原因を特定する。ここで、図２に示されるように、因果律情報１６８には、因果律コード“［ｅ１，ｅ２，ｅ３］→ｐ１”が含まれている。従って、サーバディスク故障イベント１，２，３は、症状イベントセット（ｅ１，ｅ２，ｅ３）と一致するため、原因イベントｐ１（即ち、ストレージディスク故障イベント１）が根本原因と断定される。なお、上記の因果律コード“［ｅ１，ｅ２，ｅ３］→ｐ１”が発火コードとなる。そして、原因解析結果表示画面１００１における断定原因イベントエントリの一覧の表示領域４０５には、ストレージディスク故障イベント１に関するイベントエントリが表示される。【０１１２】
その後、原因解析結果表示画面１００１によって原因を把握した管理者が、原因を解消するために、上記シナリオの（Ｃ１）の処置を行う。【０１１３】
原因が解消され、計算機システム１１の構成が変更されると、ＲＣＡプログラム１６２は、変更後の構成に対応した因果律情報１６８を生成する。図８〜図１０は、原因解消後の因果律情報１６８、症状定義情報１６９、原因定義情報１７０をそれぞれ示している。なお、図１０において、“ＳＴ２−Ｌ１”は、ストレージ装置２のストレージディスク１４３を示す発生元識別データである。以下、ストレージ装置２のストレージディスク１４３が故障するイベントを「ストレージディスク故障イベント２」と呼ぶ。即ち、イベントｐ２は、ストレージディスク故障イベント２を意味する。【０１１４】
図８からわかるように、原因解消前の因果律情報１６８には、発火コード（“［ｅ１，ｅ２，ｅ３］→ｐ１”）が存在しない代わりに、因果律コード“［ｅ１，ｅ２，ｅ３］→ｐ２”が存在している。これは、ストレージ装置１がストレージ装置２へ交換され、ストレージ装置２のストレージディスク１４３が、ストレージ装置１のストレージディスク１４３の代わりとされたためである。【０１１５】
その後、コード関連付けプログラム１６３は、発火コード（“［ｅ１、ｅ２、ｅ３］→ｐ１”）の症状イベントセットと、原因解消後の因果律情報１６８に含まれる因果律コード“［ｅ１、ｅ２、ｅ３］→ｐ２”の症状イベントセットとが一致することから、因果律コード“［ｅ１、ｅ２、ｅ３］→ｐ２”を監視コードとして抽出する。即ち、イベントｅ１、ｅ２、ｅ３の組み合わせが監視症状イベントセットとなり、イベントｐ２が監視原因イベントとなる。そして、妥当性検証表示画面１００２の表示領域５０６には、監視原因イベントであるストレージディスク故障イベント２に関するイベントエントリが表示される。【０１１６】
その後、上記シナリオの（Ｄ１）に示すとおり、再発監視において、サーバディスク故障イベント１が再発監視時イベントとして検知される。コード再発監視プログラム１６４は、サーバディスク故障イベント１が監視症状イベントであることから、再発兆候があると判定する。そして、コード再発監視プログラム１６４は、再発警告結果表示画面１００３を、表示部１６５に表示させる。再発警告結果表示画面１００３の表示領域６０６には、妥当性検証表示画面１００２の表示領域５０６と同様、監視原因イベントであるストレージディスク故障イベント２に関するイベントエントリが表示される。また、再発警告結果表示画面１００３の表示領域６０７には、再発症状イベントであるサーバディスク故障イベント１に関するイベントエントリが表示される。【０１１７】
その後、再発警告結果表示画面１００３によって再発兆候を認識した管理者が、ストレージ装置２の再調整を行って、その再発兆候に対処する。【０１１８】
以上、実施例１によれば、発火コードに関連する因果律コード１８０が、原因解消後の因果律情報１６８から、監視コードとして抽出される。運用管理システム１２は、監視コードに関する情報を管理者１０３に通知するとともに、監視原因イベントが発生することを障害の再発ととらえて、監視症状イベントの発生を監視することにより、障害の再発兆候の有無を監視する。そして、運用管理システム１２は、一以上の監視症状イベントのうちのいずれかが発生した場合に、再発兆候が表れたと判定し、その旨を管理者１０３に通知する。これにより、再発監視における管理者１０３の負担が軽減される。
【実施例２】
【０１１９】
以下、本発明の実施例２を説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略或いは簡略する。【０１２０】
図１４は、実施例２に係る情報処理システム１の全体構成の一例を示す図である。【０１２１】
業務サーバ１０４のメモリ１３２には、仮想サーバ１１２を稼動するためのコンピュータプログラム（例えば、VMware（登録商標）等）であるサーバ仮想化プログラム１６６が格納されている。サーバ仮想化プログラム１６６が実行されることにより、業務サーバ１０４上で仮想サーバ１１２が稼動する。なお、図示してはいないが、仮想サーバ１１２は、ＣＰＵ、メモリ、ディスク、通信Ｉ／Ｆ及びポートを仮想的に有している。以下、仮想サーバ１１２が有するディスクを「仮想ディスク」と呼ぶ。仮想ディスクは、サーバディスク１３３の記憶領域を基に形成される。【０１２２】
また、管理サーバ１０１のメモリ１２２には、物理／論理属性関連情報１７１が格納される。物理／論理属性関連情報１７１は、業務サーバ１０４が有する物理的な装置と仮想サーバ１１２が有する仮想的な装置（図１５における論理装置）との関連を示した情報である。図１５に示されるように、物理／論理属性関連情報１７１には、例えば、業務サーバ１０４と、その業務サーバ１０４で稼動する仮想サーバ１１２との対応関係や、サーバディスク１３３と、そのサーバディスク１３３を基に形成されている仮想ディスクとの対応関係等が含まれる。物理／論理属性関連情報１７１は、計算機システム１１の構成が変更された場合に、変更後の構成に対応するものとなるように、その内容が更新される。【０１２３】
実施例２の処理は、監視コードの抽出方法（図７のステップＳ３１５の処理方法）を除いて、実質的に実施例１の処理を同じである。実施例２では、コード関連付けプログラム１６３は、原因解消後の因果律情報１６８及び発火コードに加えて、原因解消後の物理／論理属性関連情報１７１をも参照して、監視コードを抽出する。監視コードの抽出方法については、後述する。【０１２４】
以下、下記（Ａ２）〜（Ｃ２）の一連のシナリオを想定して、実施例２を説明する。なお、以下のシナリオは一例に過ぎず、本実施例の適用範囲がこれに限られるものではない。【０１２５】
（Ａ２）図１４に示されるように、業務サーバ１では仮想サーバ１が、業務サーバ２では仮想サーバ２が、業務サーバ３では仮想サーバ３及び仮想サーバ４が、それぞれ稼動している。そして、仮想サーバ１の仮想ディスク（以下、「仮想ディスク１」）は、仮想サーバ３の仮想ディスク（以下、「仮想ディスク３」）の記憶領域の全部又は一部が割り当てられることにより形成されている。同様に、仮想サーバ２の仮想ディスク（以下、「仮想ディスク２」）は、仮想サーバ４の仮想ディスク（以下、「仮想ディスク４」）の記憶領域の全部又は一部が割り当てられることにより形成されている。そして、割当元の仮想ディスクにおける“仮想ディスクの故障”が、割当先の仮想ディスクにおける“仮想ディスクの故障”に伝播することが、イベント伝播モデルで定義されている。【０１２６】
（Ｂ２）運用開始後、仮想ディスク３の故障が原因で、仮想ディスク１が故障するイベント（以下、「仮想ディスク故障イベント１」）が発生した。仮想ディスク故障イベント１を検出したＲＣＡプログラム１６２は、図５の処理を行って、原因イベントが、仮想ディスク３が故障するイベント（以下、「仮想ディスク故障イベント３」）であると断定し、障害の原因が、仮想ディスク３の基となる、業務サーバ３のサーバディスク１３３にあることを特定した。【０１２７】
（Ｃ２）原因解析結果表示画面１００１により障害の原因を知った管理者１０３は、原因を解消するため、業務サーバ３を、業務サーバ３とは異なる業務サーバ４に交換した。【０１２８】
上記シナリオ（Ａ２）〜（Ｃ２）に従って、実施例２を具体的に説明する。【０１２９】
図１５は、原因解消前の物理／論理属性関連情報１７１を示している。ここで、“ＬＳＶ１”、“ＬＳＶ２”、“ＬＳＶ３”、“ＬＳＶ４”、“ＬＳＶ３−ＬＤ１”、“ＬＳＶ４−ＬＤ１”は、それぞれ、仮想サーバ１、仮想サーバ２、仮想サーバ３、仮想サーバ４、仮想ディスク３、仮想ディスク４のそれぞれを示す識別データである。また、“ＰＳＶ１”、“ＰＳＶ２”、“ＰＳＶ３”、“ＰＳＶ３−ＰＤ１”は、それぞれ、業務サーバ１、業務サーバ２、業務サーバ３、業務サーバ３のサーバディスク１３３のそれぞれを示す識別データである。従って、例えば、行２６３は、仮想サーバ１が、業務サーバ１上で稼動していることを表している。また、例えば、行２６７は、仮想ディスク３が、業務サーバ３のサーバディスク１３３の記憶領域を基に形成されていることを表している。【０１３０】
ＲＣＡプログラム１６２は、図５のステップＳ３０１を実行することで、図３５〜図３７の各情報を生成する。即ち、図３５〜図３７は、実施例２における原因解消前の因果律情報１６８、症状定義情報１６９、原因定義情報１７０を示している。実施例２では、イベントｅ１は、仮想ディスク故障イベント１を意味し、イベントｐ１は、仮想ディスク故障イベント３を意味している。【０１３１】
その後、ＲＣＡプログラム１６２は、仮想ディスク故障イベント１を検知し、因果律情報１６８を参照して原因を特定する。ここで、図３５に示されるように、因果律情報１６８には、因果律コード“［ｅ１］→ｐ１”が含まれている。従って、仮想ディスク故障イベント１は、症状イベントセット（ｅ１）と一致するため、原因イベントｐ１（即ち、仮想ディスク故障イベント３）が根本原因と断定される。なお、上記の因果律コード“［ｅ１］→ｐ１”が発火コードとなる。そして、原因解析結果表示画面１００１の表示領域４０５には、仮想ディスク故障イベント３に関するイベントエントリが表示される。【０１３２】
その後、原因解析結果表示画面１００１によって原因を把握した管理者が、原因を解消するために、上記シナリオの（Ｃ２）の処置を行う。【０１３３】
原因が解消され、計算機システム１１の構成が変更されると、物理／論理属性関連情報１７１が更新されるとともに、ＲＣＡプログラム１６２は、変更後の構成に対応した因果律情報１６８を生成する。【０１３４】
図１６は、原因解消後の物理／論理属性関連情報１７１を示している。業務サーバ３が業務サーバ４に交換されたため、“ＰＳＶ３”が“ＰＳＶ４”に、“ＰＳＶ３−ＰＤ１”が“ＰＳＶ４−ＰＤ１”にそれぞれ変更されている。ここで、“ＰＳＶ４”、“ＰＳＶ４−ＰＤ１”は、それぞれ、業務サーバ４を示す識別データ、業務サーバ４のサーバディスク１３３を示す識別データである。【０１３５】
また、図３８〜図４０は、実施例２における原因解消後の因果律情報１６８、症状定義情報１６９、原因定義情報１７０をそれぞれ示している。図３５及び図３８からわかるように、実施例２では、原因解消前後で因果律情報１６８の内容に変更がない。これは、仮想サーバ１１２は、それが有する仮想的な装置の実体（物理的な装置）に関する情報を、管理サーバ１０１等の他の装置に対して隠蔽しているからである。即ち、物理的な装置が変更されたとしても、管理サーバ１０１等が認識している仮想的な装置の構成には変更がないため、因果律情報１６８の内容は原因解消前後で同じものとなる。【０１３６】
その後、コード関連付けプログラム１６３は、次のようにして監視コードを抽出する。即ち、まず、コード関連付けプログラム１６３は、断定原因イベント（仮想ディスク故障イベント３）に関するイベントエントリから、断定原因イベントの発生元（仮想ディスク３）を示す発生元識別データ（即ち、“ＬＳＶ３−ＬＤ１”）を取得する。次に、コード関連付けプログラム１６３は、原因解消後の物理／論理属性関連情報１７１を参照し、断定原因イベントの発生元（仮想ディスク３）と関連のある物理的な装置（以下、「関連物理装置」）の識別データを取得する。ここで、原因解消後の物理／論理属性関連情報１７１では、仮想ディスク３と業務サーバ４のサーバディスク１３３とが関連付けられているため、業務サーバ４のサーバディスク１３３が関連物理装置とされ、その識別データ（即ち、“ＰＳＶ４−ＰＤ１”）が取得される。そして、コード関連付けプログラム１６３は、再び、原因解消後の物理／論理属性関連情報１７１を参照し、関連物理装置（業務サーバ４のサーバディスク１３３）と関連のある仮想的な装置（以下、「関連仮想装置」）の全ての識別データを取得する。ここで、原因解消後の物理／論理属性関連情報１７１では、仮想ディスク３と業務サーバ４のサーバディスク１３３とが関連付けられていることに加えて、仮想ディスク４と業務サーバ４のサーバディスク１３３とも関連付けられているため、仮想サーバ３及び仮想サーバ４が関連仮想装置とされ、それらの識別データ（即ち、“ＬＳＶ３−ＬＤ１”及び“ＬＳＶ４−ＬＤ１”）が取得される。そして、コード関連付けプログラム１６３は、原因解消後の因果律情報１６８に含まれる因果律コード１８０のうち、その原因イベントの発生元が関連仮想装置（本例では、仮想ディスク３又は仮想ディスク４）となる因果律コード１８０の全部又は一部を、監視コードとして抽出する。即ち、因果律コード“［ｅ１］→ｐ１”及び／又は“［ｅ２］→ｐ２”が監視コードとして抽出される。このように監視コードが抽出されることで、管理者１０３は、断定原因イベント（ｐ１）と表面上の繋がり（イベントの伝播関係）はないものの、断定原因イベント（ｐ１）の発生元（仮想ディスク３）と物理的な装置を介して実質的に繋がっている監視対象オブジェクト（仮想ディスク４）を発生元とするイベント（ｐ２）をも、重点的に監視できるようになる。【０１３７】
図１７は、実施例２のシナリオの下で表示される妥当性検証表示画面１００２の一例を示す図である。【０１３８】
システムトポロジの表示領域５０１には、実施例１と同様に、発火コードに関わる監視対象オブジェクト及び監視コードに関わる監視対象オブジェクトのそれぞれの接続関係が表示される。また、図１７に示されるように、例えば、発火コードに関わる監視対象オブジェクト及び監視コードに関わる監視対象オブジェクトのいずれかと関連のある物理的な装置（業務サーバ３、４のサーバディスク１３３）も表示され、それらとの接続関係も表示される。【０１３９】
監視原因イベントエントリの一覧の表示領域５０６には、監視原因イベントとされたｐ１，ｐ２のそれぞれについて、そのイベントエントリに含まれる全部又は一部の情報（本実施例では、発生元識別データ５５１とイベント種別５５２）が表示される。【０１４０】
以上、実施例２によれば、断定原因イベントの発生元が仮想装置である場合、関連仮想装置（断定原因イベントの発生元をも含む）をその原因イベントの発生元とする因果律コード１８０が、監視コードとして抽出される。これにより、管理者１０３は、断定原因イベントと表面上の繋がり（イベントの伝播関係）はないものの、断定原因イベントの発生元と物理的な装置を介して実質的に繋がっている監視対象オブジェクトを発生元とするイベントをも、重点的に監視できるようになる。
【実施例３】
【０１４１】
以下、本発明の実施例３を説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略或いは簡略する。【０１４２】
図１８は、実施例３に係る情報処理システム１の全体構成の一例を示す図である。【０１４３】
業務サーバ１０４は、ＨＢＡ（Host Bus Adapter）１３７を有している。ＨＢＡ１３７には、二つのポート１３５（ポート１及びポート２）が搭載されている。業務サーバ１０４は、いずれか一方のポート１３５を通じてＳＡＮ１１１に接続されている。管理サーバ１０１のメモリ１２２には、集約関係定義情報１７２が格納される。【０１４４】
図１９は、集約関係定義情報１７２の一例を示す図である。【０１４５】
集約関係定義情報１７２は、監視対象オブジェクト間の集約関係（包含関係）を定義した情報である。下位装置２８１は、集約される側（下位側）の監視対象オブジェクト（以下、「下位装置」）の識別データである。上位装置２８２は、集約する側（上位側）の監視対象オブジェクト（以下、「上位装置」）の識別データである。機能代替可否２８３は、対応する集約関係において、上位装置が下位装置の機能を代替できるか否かを示す情報である。【０１４６】
ここで、図１９における、“Ｄ”、“ＨＢＡ”、“ＨＢＡ＿Ｐ”、“Ｌ”、“ＦＣ＿Ｐ”、“ＳＶ”、“ＳＴ”は、それぞれ、サーバディスク１３３、ＨＢＡ１３７、業務サーバ１０４のポート１３５（以下、「サーバポート」）、ストレージディスク１４３、ストレージ装置１０８のポート１４５（以下、「ストレージポート」）、ストレージ装置１０８のそれぞれを示す識別データである。従って、例えば、行２８４は、サーバディスク１３３が業務サーバ１０４に集約されること、及び、業務サーバ１０４はサーバディスク１３３の機能を代替できないことを示している。同様に、例えば、行２８６は、サーバポート１３５がＨＢＡ１３７に集約されること、及び、ＨＢＡ１３７はサーバポート１３５の機能を代替できることを示している。【０１４７】
実施例３の処理は、監視コードの抽出方法（図７のステップＳ３１５の処理方法）を除いて、実質的に実施例１の処理を同じである。実施例３では、コード関連付けプログラム１６３は、監視コードを抽出する際に、原因解消後の因果律情報１６８及び発火コードに加えて、集約関係定義情報１７２をも参照して、監視コードを抽出することができる。監視コードの抽出方法については、後述する。【０１４８】
以下、下記（Ａ３）〜（Ｃ３）の一連のシナリオを想定して、実施例３を説明する。なお、以下のシナリオは一例に過ぎず、本実施例の適用範囲がこれに限られるものではない。【０１４９】
（Ａ３）図１８に示されるように、管理者１０３は、管理サーバ１０１を用いて、二台の業務サーバ１０４（業務サーバ１及び業務サーバ２）と一台のストレージ装置１０８（ストレージ装置１）とが接続されている計算機システム１１を、運用管理している。ここで、業務サーバ１，２は、それぞれ、二つのサーバポート１３５（サーバポート１及びサーバポート２）を有しており、それぞれ、サーバポート１を通じてＳＡＮ１１１に接続されている。以下、業務サーバＮのサーバポートＭ（Ｎ、Ｍは１又は２）を「サーバポートＮ−Ｍ」と表記する。即ち、例えば業務サーバ１のサーバポート１は「サーバポート１−１」である。また、業務サーバ１，２は、それぞれが利用するデータを、ストレージ装置１のストレージディスク１４３に格納している。更に、ストレージ装置１０８における“ストレージポートの故障”が、そのストレージ装置１０８を利用する業務サーバ１０４における“サーバポートの故障”に伝播することが、イベント伝播モデルで定義されている。【０１５０】
（Ｂ３）運用開始後、ストレージ装置１のストレージポート１４５の故障が原因で、サーバポート１−１及びサーバポート２−１のそれぞれで、サーバポート１３５が故障するイベントが発生した。以下、サーバポート１−１、サーバポート２−１で発生する、サーバポート１３５の故障イベントを、それぞれ、「サーバポート故障イベント１−１」、「サーバポート故障イベント２−１」と呼ぶ。サーバポート故障イベント１−１，２−１を検出したＲＣＡプログラム１６２は、図５の処理を行って、原因イベントが、ストレージ装置１のストレージポート１４５が故障するイベント（以下、「ストレージポート故障イベント１」）であると断定し、障害の原因が、ストレージ装置１のストレージポート１４５にあることを特定した。【０１５１】
（Ｃ３）原因解析結果表示画面１００１により障害の原因を知った管理者１０３は、原因を解消するため、ストレージ装置１を、ストレージ装置１とは異なるストレージ装置２に交換した。ここで、管理者１０３は、業務サーバ１において、ＳＡＮ１１１に接続するためのサーバポート１３５（以下、「ＳＡＮ接続ポート」）を、サーバポート１−１からサーバポート１−２に変更した。【０１５２】
上記シナリオ（Ａ３）〜（Ｃ３）に従って、実施例３を具体的に説明する。【０１５３】
ＲＣＡプログラム１６２は、図５のステップＳ３０１を実行することで、図２０〜図２２の各情報を生成する。即ち、図２０〜図２２は、実施例３における原因解消前の因果律情報１６８、症状定義情報１６９、原因定義情報１７０を示している。実施例３では、イベントｅ１は、サーバポート故障イベント１−１を意味し、イベントｅ２は、サーバポート故障イベント２−１を意味し、イベントｐ１は、ストレージポート故障イベント１を意味している。【０１５４】
その後、ＲＣＡプログラム１６２は、サーバポート故障イベント１−１，２−１を検知し、因果律情報１６８を参照して原因を特定する。ここで、図２０に示されるように、因果律情報１６８には、因果律コード“［ｅ１，ｅ２］→ｐ１”が含まれている。従って、サーバポート故障イベント１−１，２−１は、症状イベントセット（ｅ１，ｅ２）と一致するため、原因イベントｐ１（即ち、ストレージポート故障イベント１）が根本原因と断定される。なお、上記の因果律コード“［ｅ１，ｅ２］→ｐ１”が発火コードとなる。そして、原因解析結果表示画面１００１の表示領域４０５には、ストレージポート故障イベント１に関するイベントエントリが表示される。【０１５５】
その後、原因解析結果表示画面１００１によって原因を把握した管理者が、原因を解消するために、上記シナリオの（Ｃ３）の処置を行う。【０１５６】
原因が解消され、計算機システム１１の構成が変更されると、ＲＣＡプログラム１６２は、変更後の構成に対応した因果律情報１６８を生成する。図２３〜図２５は、実施例３における原因解消後の因果律情報１６８、症状定義情報１６９、原因定義情報１７０をそれぞれ示している。なお、実施例３では、イベントｅ３は、サーバポート１−２で発生する、サーバポート１３５の故障イベント（以下、「サーバポート故障イベント１−２」）を意味し、イベントｐ２は、ストレージ装置２のストレージポート１４５が故障するイベント（以下、「ストレージポート故障イベント２」）を意味している。【０１５７】
図２３からわかるように、原因解消前の因果律情報１６８には、発火コード（“［ｅ１，ｅ２］→ｐ１”）が存在しない代わりに、因果律コード“［ｅ２，ｅ３］→ｐ２”が存在している。ここで、削除された発火コード“［ｅ１，ｅ２］→ｐ１”と追加された因果律コード“［ｅ２，ｅ３］→ｐ２”とは、原因イベントに加えて、症状イベントセットも一致しなくなっている。これは、断定原因イベントの発生元に加えて、検出症状イベントの発生元も変更されたためである。即ち、ストレージ装置１がストレージ装置２へ交換されるとともに、業務サーバ１のＳＡＮ接続ポートが、サーバポート１−１からサーバポート１−２に変更されたためである。【０１５８】
このように、検出症状イベントの発生元（本例では、業務サーバ１のＳＡＮ接続ポート）についても変更が生じた場合、コード関連付けプログラム１６３は、実施例１と同様の方法では、監視コードを抽出することができない。何故ならば、上述したように、原因解消後の因果律情報１６８に追加された因果律コード１８０の症状イベントセットは、検出イベントセットと一致せず、通常、その症状イベントセットが、検出症状イベントセットと一致する因果律コード１８０が、更新後の因果律情報１６８に存在しなくなっているからである。【０１５９】
そのため、コード関連付けプログラム１６３は、次のようにして監視コードを抽出する。即ち、まず、コード関連付けプログラム１６３は、原因解消後の因果律情報１６８に含まれる因果律コード１８０の中から、監視コードとなるか否かの判断の対象とするもの（以下、「対象因果律コード」）を一つ選択する。【０１６０】
そして、コード関連付けプログラム１６３は、集約関係定義情報１７２を参照し、検出症状イベントの発生元、及び、対象因果律コード１８０の症状イベント（以下、「対象症状イベント」）の発生元のそれぞれについて、その発生元を下位装置とし且つ機能代替可能である上位装置（以下、「集約可能装置」）が存在するか否かを判定する。そして、コード関連付けプログラム１６３は、集約可能装置が存在する場合は、監視コードとなるか否かの判断においては、その発生元を、集約可能装置として取り扱うようにする。【０１６１】
本例において、因果律コード“［ｅ２，ｅ３］→ｐ２”が対象因果律コード１８０として選択された場合、対象症状イベントは、イベントｅ２、イベントｅ３であり、それらの発生元は、それぞれ、サーバポート２−１、サーバポート１−２である。ここで、集約関係定義情報１７２の行２８６には、サーバポート１３５がＨＢＡ１３７に集約されること、及び、ＨＢＡ１３７はサーバポート１３５の機能を代替できることが示されている。従って、監視コードとなるか否かの判断において、サーバポート２−１は、業務サーバ２のＨＢＡ１３７として取り扱われ、サーバポート１−２は、業務サーバ１のＨＢＡ１３７として取り扱われることになる。一方、検出症状イベントは、イベントｅ１、イベントｅ２であり、それらの発生元は、それぞれ、サーバポート１−１、サーバポート２−１である。そして、これらの発生元についても、上記と同様に、集約可能装置が存在するため、集約可能装置として取り扱われる。即ち、監視コードとなるか否かの判断において、サーバポート１−１は、業務サーバ１のＨＢＡ１３７として取り扱われ、サーバポート２−１は、業務サーバ２のＨＢＡ１３７として取り扱われることになる。【０１６２】
以上の取り扱いを踏まえて、コード関連付けプログラム１６３は、検出症状イベントセットと対象因果律コード１８０の症状イベントセットとが一致するか否かを判定する。本例において、検出症状イベントセット（ｅ１，ｅ２）と、対象因果律コード１８０の症状イベントセット（ｅ２，ｅ３）とは、上記の取り扱いを踏まえた場合、イベントｅ１の発生元とイベントｅ３の発生元とは、ともに業務サーバ１のＨＢＡ１３７と取り扱われているため一致する。また、イベントｅ１のイベント種別とイベントｅ３のイベント種別も一致する。従って、イベントｅ１とイベントｅ３は、一致すると判断される。また、両症状イベントセットに含まれるイベントｅ２同士は、同じである。従って、結果として、検出症状イベントセット（ｅ１，ｅ２）と、対象因果律コード１８０の症状イベントセット（ｅ２，ｅ３）とは、一致すると判定され、対象因果律コード“［ｅ２，ｅ３］→ｐ２”が、監視コードとして抽出される。【０１６３】
コード関連付けプログラム１６３は、原因解消後の因果律情報１６８に含まれる因果律コード１８０の全てについて、上記と同様の処理で、監視コードとなるか否かを判断することができる。【０１６４】
図２６は、実施例３のシナリオの下で表示される妥当性検証表示画面１００２の一例を示す図である。【０１６５】
監視原因イベントエントリの一覧の表示領域５０６には、監視原因イベントとされたｐ２について、そのイベントエントリに含まれる全部又は一部の情報（本実施例では、発生元識別データ５５１とイベント種別５５２）が表示される。【０１６６】
なお、本実施例において、集約可能装置を機能代替可能ものに限定しているのは、以下の理由による。即ち、そのような限定がない場合、例えば最も上位の装置であるノード装置の単位で発生元が一致するか否かの判定が行われ得ることとなり（つまり、判定の粒度が粗くなりすぎる可能性があり）、それ故、監視コードとしては不適切な因果律コード１０８が監視コードとして抽出される可能性が出てくるからである。【０１６７】
以上、実施例３によれば、監視コードの抽出処理において、症状イベントセット（検出症状イベントセットと、対象因果律コード１８０の症状イベントセット）の比較が、次のように行われる。即ち、症状イベントセットの比較において検出症状イベントの発生元（第一の装置）と対象因果律コード１８０の症状イベントの発生元（第二の装置）とが一致するか否かの判定（発生元判定）が行われる際、第一の装置の集約可能装置と第二の装置の集約可能装置とが一致していた場合は、第一の装置と第二の装置とは一致しているものとみなして、発生元判定が行われる。これにより、原因解消のための処置によって検出症状イベントの発生元に変更が生じた場合でも、運用管理システム１２は、適切な監視コードを抽出できるようになる。
【実施例４】
【０１６８】
以下、本発明の実施例４を説明する。その際、実施例３との相違点を主に説明し、実施例３との共通点については説明を省略或いは簡略する。【０１６９】
実施例４の構成は、実施例３と同様である。即ち、図１８が、実施例４に係る情報処理システム１の全体構成を示す図である。【０１７０】
以下、下記（Ａ４）〜（Ｃ４）の一連のシナリオを想定して、実施例４を説明する。なお、以下のシナリオは一例に過ぎず、本実施例の適用範囲がこれに限られるものではない。【０１７１】
（Ａ４）図１８に示されるように、管理者１０３は、管理サーバ１０１を用いて、二台の業務サーバ１０４（業務サーバ１及び業務サーバ２）と一台のストレージ装置１０８（ストレージ装置１）とが接続されている計算機システム１１を、運用管理している。ここで、業務サーバ１，２は、それぞれが利用するデータを、ストレージ装置１のストレージディスク１４３に格納している。また、ストレージ装置１０８における“ストレージディスクの故障”が、そのストレージ装置１０８における“ストレージポートの故障”と、そのストレージ装置１０８を利用する業務サーバ１０４における“サーバディスクの故障”に伝播することが、イベント伝播モデルで定義されている。【０１７２】
（Ｂ４）運用開始後、ストレージ装置１のストレージディスク１４３の故障が原因で、ストレージポート故障イベント１とサーバディスク故障イベント１とサーバディスク故障イベント２とが発生した。ストレージポート故障イベント１及びサーバディスク故障イベント１，２を検出したＲＣＡプログラム１６２は、図５の処理を行って、原因イベントが、ストレージディスク故障イベント１であると断定し、障害の原因が、ストレージ装置１のストレージディスク１４３にあることを特定した。【０１７３】
（Ｃ４）原因解析結果表示画面１００１により障害の原因を知った管理者１０３は、原因を解消するため、ストレージ装置１を、ストレージ装置１とは異なるストレージ装置２に交換し、各業務サーバ１，２が、ストレージ装置２のストレージディスク１４３にアクセスできるように、ストレージ装置２の設定を行った。【０１７４】
上記シナリオ（Ａ４）〜（Ｃ４）に従って、実施例４を具体的に説明する。【０１７５】
ＲＣＡプログラム１６２は、図５のステップＳ３０１を実行することで、図２７〜図２９の各情報を生成する。即ち、図２７〜図２９は、実施例４における原因解消前の因果律情報１６８、症状定義情報１６９、原因定義情報１７０を示している。実施例４では、イベントｅ１は、サーバディスク故障イベント１を意味し、イベントｅ２は、サーバディスク故障イベント２を意味し、イベントｅ３は、ストレージポート故障イベント１を意味し、イベントｐ１は、ストレージディスク故障イベント１を意味している。【０１７６】
その後、ＲＣＡプログラム１６２は、ストレージポート故障イベント１及びサーバディスク故障イベント１，２を検知し、因果律情報１６８を参照して原因を特定する。ここで、図２７に示されるように、因果律情報１６８には、因果律コード“［ｅ１，ｅ２，ｅ３］→ｐ１”が含まれている。従って、ストレージポート故障イベント１及びサーバディスク故障イベント１，２は、症状イベントセット（ｅ１，ｅ２，ｅ３）と一致するため、原因イベントｐ１（即ち、ストレージディスク故障イベント１）が根本原因と断定される。なお、上記の因果律コード“［ｅ１，ｅ２，ｅ３］→ｐ１”が発火コードとなる。そして、原因解析結果表示画面１００１の表示領域４０５には、ストレージディスク故障イベント１に関するイベントエントリが表示される。【０１７７】
その後、原因解析結果表示画面１００１によって原因を把握した管理者が、原因を解消するために、上記シナリオの（Ｃ４）の処置を行う。【０１７８】
原因が解消され、計算機システム１１の構成が変更されると、ＲＣＡプログラム１６２は、変更後の構成に対応した因果律情報１６８を生成する。図３０〜図３２は、実施例４における原因解消後の因果律情報１６８、症状定義情報１６９、原因定義情報１７０をそれぞれ示している。なお、実施例４では、イベントｅ４は、ストレージポート故障イベント２を意味し、イベントｐ２は、ストレージディスク故障イベント２を意味している。【０１７９】
図３０からわかるように、原因解消前の因果律情報１６８には、発火コード（“［ｅ１，ｅ２，ｅ３］→ｐ１”）が存在しない代わりに、因果律コード“［ｅ１，ｅ２，ｅ４］→ｐ２”が存在している。実施例３と同様に、削除された発火コード“［ｅ１，ｅ２，ｅ３］→ｐ１”と追加された因果律コード“［ｅ１，ｅ２，ｅ４］→ｐ２”とは、原因イベントに加えて、症状イベントセットも一致しなくなっている。これは、断定原因イベントの発生元と検出症状イベントの発生元とが同じノード装置に搭載されており、原因解消のために行われたノード装置の交換により、断定原因イベントの発生元に加えて、検出症状イベントの発生元も変更されたためである。即ち、ストレージ装置１がストレージ装置２へ交換されることにより、ストレージポート１のストレージポート１４５にも変更が生じた（存在しなくなった）ためである。【０１８０】
実施例３と同様、検出症状イベントの発生元（本例では、ストレージポート１のストレージポート１４５）についても変更が生じているため、コード関連付けプログラム１６３は、実施例１と同様の方法では、監視コードを抽出することができない。【０１８１】
そのため、コード関連付けプログラム１６３は、次のようにして監視コードを抽出する。即ち、まず、コード関連付けプログラム１６３は、原因解消後の因果律情報１６８に含まれる因果律コード１８０の中から、監視コードとなるか否かの判断の対象とするもの（対象因果律コード）を一つ選択する。【０１８２】
そして、コード関連付けプログラム１６３は、発火コード及び対象因果律コード１８０のそれぞれについて、その原因イベントの発生元の上位装置と、その症状イベントの発生元の上位装置とが一致するか否かを判定する。ここで、コード関連付けプログラム１６３は、集約関係定義情報１７２を参照することにより、発生元の上位装置を知ることができる。また、上位装置が複数ある場合は、コード関連付けプログラム１６３は、例えば最上位の装置を上位装置とすることができる。そして、原因イベントの発生元の上位装置と症状イベントの発生元の上位装置とが一致した場合は、コード関連付けプログラム１６３は、その発生元の上位装置が一致した症状イベント（以下、「上位一致症状イベント」）を無視して、監視コードとなるか否かの判断、即ち、検出症状イベントセットと対象因果律コード１８０の症状イベントセットとが一致するか否かの判定を行うようにする。【０１８３】
本例において、因果律コード“［ｅ１，ｅ２，ｅ４］→ｐ２”が対象因果律コード１８０として選択された場合、対象因果律コード１８０の症状イベント（対象症状イベント）は、イベントｅ１、イベントｅ２、イベントｅ４であり、それらの発生元は、それぞれ、業務サーバ１のサーバディスク１３３、業務サーバ２のサーバディスク１３３、ストレージポート２である。そして、集約関係定義情報１７２の行２８４には、サーバディスク１３３が業務サーバ１０４に集約されることが示されていることから、業務サーバ１のサーバディスク１３３の上位装置は、業務サーバ１であると判断される。同様に、業務サーバ２のサーバディスク１３３の上位装置は、業務サーバ２であると判断される。また、集約関係定義情報１７２の行２８８には、ストレージポート１４５がストレージ装置１０８に集約されることが示されていることから、ストレージポート２の上位装置は、ストレージ装置２と判断される。【０１８４】
一方、対象因果律コード１８０の原因イベント（以下、「対象原因イベント」）は、イベントｐ２であり、その発生元は、ストレージ装置２のストレージディスク１４３である。そして、集約関係定義情報１７２の行２８７には、ストレージディスク１４３がストレージ装置１０８に集約されることが示されていることから、ストレージ装置２のストレージディスク１４３の上位装置は、ストレージ装置２と判断される。【０１８５】
ここで、対象原因イベントの発生元の上位装置と、対象症状イベントの発生元の上位装置とを比較すると、イベントｅ４の発生元であるストレージポート２の上位装置と、イベントｐ２の発生元であるストレージ装置２のストレージディスク１４３の上位装置とが、ストレージ装置２で一致する。従って、その発生元の上位装置が一致した症状イベントｅ４が、上位一致症状イベントとなり、検出症状イベントセットとの比較の際に無視されることになる。【０１８６】
発火コード“［ｅ１，ｅ２，ｅ３］→ｐ１”についても同様である。即ち、検出症状イベントｅ１，ｅ２，ｅ３の発生元は、それぞれ、業務サーバ１のサーバディスク１３３、業務サーバ２のサーバディスク１３３、ストレージポート１である。そして、業務サーバ１のサーバディスク１３３の上位装置は、業務サーバ１と判断され、業務サーバ２のサーバディスク１３３の上位装置は、業務サーバ２と判断され、ストレージポート１の上位装置は、ストレージ装置１と判断される。一方、断定原因イベントｐ１の発生元は、ストレージ装置１のストレージディスク１４３である。そして、ストレージ装置１のストレージディスク１４３の上位装置は、ストレージ装置１と判断される。従って、発火コード“［ｅ１，ｅ２，ｅ３］→ｐ１”については、検出症状イベントｅ３が、上位一致症状イベントとなり、対象因果律コード１８０の症状イベントセットとの比較の際に無視されることになる。【０１８７】
以上を踏まえて、コード関連付けプログラム１６３は、検出症状イベントセットと対象因果律コード１８０の症状イベントセットとが一致するか否かを判定する。本例において、検出症状イベントセット（ｅ１，ｅ２，ｅ３）と、対象因果律コード１８０の症状イベントセット（ｅ１，ｅ２，ｅ４）との比較において、上位一致症状イベントｅ３，ｅ４が無視されるため、無視されない部分（ｅ１，ｅ２）が一致し、両イベントセットは一致すると判定される。従って、対象因果律コード“［ｅ１，ｅ２，ｅ４］→ｐ２”が、監視コードとして抽出される。【０１８８】
コード関連付けプログラム１６３は、原因解消後の因果律情報１６８に含まれる因果律コード１８０の全てについて、上記と同様の処理で、監視コードとなるか否かを判断することができる。【０１８９】
図３３は、実施例４のシナリオの下で表示される妥当性検証表示画面１００２の一例を示す図である。【０１９０】
監視原因イベントエントリの一覧の表示領域５０６には、監視原因イベントとされたｐ２について、そのイベントエントリに含まれる全部又は一部の情報（本実施例では、発生元識別データ５５１とイベント種別５５２）が表示される。【０１９１】
以上、実施例４によれば、監視コードの抽出処理において、症状イベントセット（検出症状イベントセットと、対象因果律コード１８０の症状イベントセット）の比較が、次のように行われる。即ち、検出症状イベントセットと、対象因果律コード１８０の症状イベントセットとが一致するか否かの判定（監視コード抽出判定）が行われる際、発火コードと対象因果律コード１８０のそれぞれについて、症状イベントの発生元と原因イベントの発生元との関係に基づいて、除外イベントが決定される。そして、検出症状イベントセットのうちの除外イベントを除いたイベントセットと、対象因果律コード１８０の症状イベントセットのうちの除外イベントを除いたイベントセットとが一致する場合は、検出症状イベントセットと対象因果律コード１８０の症状イベントセットとは一致しているものとみなして、前記第二のコード抽出判定が行われる。これにより、断定原因イベントの発生元と検出症状イベントの発生元とが同じノード装置に搭載されていたために、原因解消のための処置によって検出症状イベントの発生元に変更が生じた場合でも、運用管理システム１２は、適切な監視コードを抽出できるようになる。【０１９２】
図３４は、プログラムを配布するプログラム配布サーバ３４１０４の一例を示す図である。【０１９３】
プログラム配布サーバ３４１０４は、ＣＰＵ３４１３１、メモリ（半導体メモリ３４１３２及び／又はディスク３４１３３等の記憶デバイス）、通信Ｉ／Ｆ３４１３４を有する。メモリ３４１３２には、コード関連付けプログラム１６３やコード再発監視プログラム１６４等の各種のコンピュータプログラム（以下、「対象プログラム」）を管理サーバ１０１にインストールするためのコンピュータプログラムであるインストールプログラム３４１３２ｂと、インストールプログラム３４１３２ｂを配布するためのコンピュータプログラムである配布プログラム３４１３２ａとが格納される。配布プログラム３４１３２ａは、管理サーバ１０１又は他の装置からの要求に応じて、インストールプログラム３４１３２ｂを、その要求を出した装置へ送信する。【０１９４】
上述した本発明の幾つかの実施例は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。本発明は、その要旨を逸脱することなく、その他の様々な態様でも実施することができる。
【符号の説明】
【０１９５】
１１…計算機システム、１０１…管理サーバ、１０２…入出力端末、１０３…管理者、１０４…業務サーバ、１０８…ストレージ装置、１１０…通信ネットワーク、１１１…ＳＡＮ、１１２…仮想サーバ、１２１，１３１，１４１…ＣＰＵ、１２２，１３２，１４２…メモリ、１２３，１３３，１４３…ディスク、１２４，１３４，１４４…通信インターフェース、１３５，１４５…ポート、１３７…ＨＢＡ、１６１…構成管理プログラム、１６２…ＲＣＡプログラム、１６３…コード関連付けプログラム、１６４…コード再発監視プログラム、１６５…表示部、１６６…サーバ仮想化プログラム、１６７…構成管理情報、１６８…因果律情報、１６９…症状定義情報、１７０…原因定義情報、１７１…論理／物理属性関連情報、１７２…集約関係定義情報
【図１】
2010137063.tif 000003
【図２】
2010137063.tif 000004
【図３】
2010137063.tif 000005
【図４】
2010137063.tif 000006
【図５】
2010137063.tif 000007
【図６】
2010137063.tif 000008
【図７】
2010137063.tif 000009
【図８】
2010137063.tif 000010
【図９】
2010137063.tif 000011
【図１０】
2010137063.tif 000012
【図１１】
2010137063.tif 000013
【図１２】
2010137063.tif 000014
【図１３】
2010137063.tif 000015
【図１４】
2010137063.tif 000016
【図１５】
2010137063.tif 000017
【図１６】
2010137063.tif 000018
【図１７】
2010137063.tif 000019
【図１８】
2010137063.tif 000020
【図１９】
2010137063.tif 000021
【図２０】
2010137063.tif 000022
【図２１】
2010137063.tif 000023
【図２２】
2010137063.tif 000024
【図２３】
2010137063.tif 000025
【図２４】
2010137063.tif 000026
【図２５】
2010137063.tif 000027
【図２６】
2010137063.tif 000028
【図２７】
2010137063.tif 000029
【図２８】
2010137063.tif 000030
【図２９】
2010137063.tif 000031
【図３０】
2010137063.tif 000032
【図３１】
2010137063.tif 000033
【図３２】
2010137063.tif 000034
【図３３】
2010137063.tif 000035
【図３４】
2010137063.tif 000036
【図３５】
2010137063.tif 000037
【図３６】
2010137063.tif 000038
【図３７】
2010137063.tif 000039
【図３８】
2010137063.tif 000040
【図３９】
2010137063.tif 000041
【図４０】
2010137063.tif 000042
【国際調査報告】
2010137063.tif 000043
2010137063.tif 000044
2010137063.tif 000045
2010137063.tif 000046