障害復旧システム、障害復旧装置、ルール作成方法、および障害復旧プログラム
【課題】 管理者に負担をかけないで、不適切な動作を導くような障害対処ルールを排除できるようにする。
【解決手段】 対話制御手段４は、ユーザの操作に応じて、条件式と復旧処理コマンドとを対応付けたユーザ指定ルールを入力し、ユーザ指定ルール蓄積手段６に記憶させる。共通条件制御手段７は、条件式に共通部分を有する複数のユーザ指定ルールがある場合、そのユーザ指定ルールの条件式が同時に満たされることがないようにユーザ指定ルールの条件式を書き換え、書き換え後のユーザ指定ルールを障害対処ルールとしてルール蓄積手段２に記憶させる。対処方法検索手段３は、サービス実行手段１０の動作状態に関する情報を動作状態検出手段１から受信する。そして、その情報に基づいてどの条件式が満足されているかを判断し、その条件式に対応する復旧処理コマンドの情報を出力する。
【解決手段】 対話制御手段４は、ユーザの操作に応じて、条件式と復旧処理コマンドとを対応付けたユーザ指定ルールを入力し、ユーザ指定ルール蓄積手段６に記憶させる。共通条件制御手段７は、条件式に共通部分を有する複数のユーザ指定ルールがある場合、そのユーザ指定ルールの条件式が同時に満たされることがないようにユーザ指定ルールの条件式を書き換え、書き換え後のユーザ指定ルールを障害対処ルールとしてルール蓄積手段２に記憶させる。対処方法検索手段３は、サービス実行手段１０の動作状態に関する情報を動作状態検出手段１から受信する。そして、その情報に基づいてどの条件式が満足されているかを判断し、その条件式に対応する復旧処理コマンドの情報を出力する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＷＥＢサービスや業務サービスといった情報通信サービスを提供する情報処理装置等に障害が発生した場合に、その情報処理装置等を障害から復旧させるための障害復旧システム、障害復旧装置、およびその障害復旧システムに適用されるルール作成方法、障害復旧プログラムに関する。
【背景技術】
【０００２】
ＷＥＢサービスのような情報通信サービスの社会インフラストラクチャとしての重要性が高まるにつれて、そのサービスを提供する装置の安定稼動が重要となっている。従来、このような装置の運用管理は、管理者が手作業で行っていたが、装置が大規模化、複雑化するにつれて、知識および操作の面で管理者の負担が飛躍的に増大した。その結果、管理者の判断ミスや操作ミスによるサービス停止といった問題も発生している。
【０００３】
このようなミスの防止策として、障害の対処を自動化する技術が紹介されている（例えば、非特許文献１）。非特許文献１には、障害状態を検出し、自動的に障害に対する対処を行うという処理経過が記載されている。また、ｉｆ−ｔｈｅｎ形式の障害対処ルール群に従って、対処を決定することが記載されている。すなわち、障害状態を検出した場合、ｉｆ−ｔｈｅｎ形式の障害対処ルール群に従って、障害状態に応じた対処を決定し、その対処を実行することになる。また、システムが対処を実行する際に、管理者との対話を行いつつ対処を実行することも記載されている。非特許文献１に記載の技術によれば、障害発生時に、障害復旧システムが、その障害発生状態を条件として定めた障害対処ルールに基づいて対処手順を自動的に決定し、その手順を実行するので、障害発生時に迅速かつ確実に対処を行うことが可能となり、管理者によるミスを防止することが可能である。
【０００４】
【非特許文献１】加藤清志、外２名，「自律運用管理に向けたポリシー適用優先度の制御に関する一考察」，第６６回（平成１６年）全国大会講演論文集（１），社団法人 情報処理学会，２００４年３月９日発行，分冊１，ｐ．５１−５２
【発明の開示】
【発明が解決しようとする課題】
【０００５】
非特許文献１に記載された技術によって障害復旧システムが適切な障害対処を行うためには、各障害対処ルールが矛盾なく正確に記述されている必要がある。しかし、管理者にとっては、矛盾なく正確に各障害対処ルールを記載することは大きな負担である。ここで、「矛盾」とは複数の障害対処ルールが同時に成立してしまう状態を意味する。
【０００６】
以下に、管理者にかかる負担を具体的に説明する。図２２は、管理者が障害対処ルールを追加する状況を示す説明図である。図２２（ａ）に示すような障害対処ルールが、障害を復旧させるための障害復旧システムに元々記憶されていたとする。障害対処ルールは、障害が発生したと判定するための条件式と、その条件式を満足する状態を検出したときに、復旧させるべき装置（以下、復旧対象装置と記す。例えば、情報通信サービス提供装置等。）に対して実行する復旧処理コマンドの情報とを含む。条件式としては、障害が発生したとみなされる復旧対象装置の動作状態または障害発生の前兆とみなされる復旧対象装置の動作状態が記述される。復旧処理コマンドは、条件式が満たされる状態となったときに、障害からの復旧または障害の回避のための処理を制御するコマンドである。条件式を複数の状態のＡＮＤ（論理積）によって表してもよい。以下の説明では、条件式に記載される“＆”記号は、論理積を意味するものとする。すなわち、図２２（ａ）に示す障害対処ルールでは、状態Ａおよび状態Ｂが共に真ならば（換言すると、状態Ａおよび状態Ｂが共に検出されているならば）、対処手順Ａという復旧処理コマンドを実行することを表している。
【０００７】
状態Ａおよび状態Ｂが真であり（検出されており）、さらに特別な状態（ここでは状態Ｃとする。）も真であるときには、対処手順Ａとは異なる対処手順Ｂを実行させることを意図して、管理者が、図２２（ｂ）に示す２番目の障害対処ルールを追加したとする。ここで、管理者は、状態Ａおよび状態Ｂは真であるが、状態Ｃが生じていない場合には、対処手順Ａを実行し、状態Ａ，Ｂ，Ｃがいずれも真であるときには対処手順Ｂを実行することを意図している。ところが、図２２（ｂ）に示す２番目の障害対処ルールを追加した場合、障害復旧システムは、状態Ａおよび状態Ｂを検出したときには、状態Ｃが発生しているか否かによらず対処手順Ａを実行してしまうことになる。障害対処ルールを追加するときには、このような意図に反する対処手順が実行されてしまう場合があるということまで、管理者はなかなか気付きにくい。例えば、障害復旧システムが、状態Ａおよび状態Ｂを検出したときに、対処手順Ａを実行することの確認を管理者に求めたときに、状態Ｃが発生しているか否かの判定が完了していないことに管理者が気付き、そのときに初めて、元々存在していた障害対処ルール（図２２（ａ）に示すルール）も変更しなければならないということに気付く。
【０００８】
そして、元々存在していた障害対処ルールの変更の必要性に気付いた管理者は、その障害対処ルールを図２３に示す１行目の障害対処ルールに変更する。図２３に示す“ＮＯＴ”は、「・・・でないこと」を意味し、「ＮＯＴ状態Ｃ」は、状態Ｃではないことを意味する。この結果、障害復旧システムは、管理者の意図に従い、状態Ａおよび状態Ｂは真であるが、状態Ｃが生じていない場合には、対処手順Ａを実行し、状態Ａ，Ｂ，Ｃがいずれも真であるときには対処手順Ｂを実行することになる。このように、管理者は、自身の意図を反映させるために、障害対処ルール追加時に既存の障害対処ルールを確認し、矛盾がなくなるように既存の障害対処ルールに対する変更も行わなければならず、管理者にとっての負担が大きい。また、管理者が、既存の障害対処ルールに対する変更の必要性に気付かなかった場合、複数の障害対処ルールの条件式がともに成立してしまい、自身の意図に反する対処手順が実行されてしまうおそれが生じる。
【０００９】
また、追加した障害対処ルールと既存の障害対処ルールとの間に矛盾がなくなるように、管理者が既存の障害対処ルールを変更したとしても（例えば、図２３に示すように変更したとしても）、別の問題が生じる。すなわち、対処手順の実行が遅れ、対処に失敗し、障害が波及してしまい復旧が困難になってしまう場合が生じ得るという問題が発生する。新たな障害対処ルールを追加する前（図２２（ａ）参照。）であれば、障害復旧システムは、状態Ａおよび状態Ｂを検出したときに直ちに対処手順Ａを実行する。しかし、図２３の１番目および２番目に示すような障害対処ルールのもとでは、障害復旧システムは、状態Ｃが発生しているか否かを判定するまでは、図２３に示す対処手順Ａ，Ｂのいずれも実行しない。そして、状態Ｃが発生しているか否かの判定が完了するまでの間に、障害が波及してしまうおそれが生じる。このように、新たな障害対処ルールを追加する前であれば、状態Ａおよび状態Ｂの検出時に迅速に対処手順Ａを実行していたが、管理者が新たな障害対処ルールを追加して図２３に示すように障害対処ルールを変更したことにより、処理手順の実行タイミングが遅れて、対処に失敗してしまうことが生じ得る。このような場合、対処手順に、復旧や障害回避のための対処コマンドと、対処コマンド実行前に実行すべき準備コマンドとが含まれているならば、例えば、図２４に示すように、対処手順Ａに含まれている対処手順Ａ２（対処コマンド）と対処手順Ａ１（準備コマンド）とを分けて障害対処ルールを作成することが考えられる。すなわち、管理者は、状態Ａおよび状態Ｂが検出されたときに対処手順Ａ１が直ちに実行されるように、図２４に示す３番目の障害対処ルールを作成する。また、管理者は、「状態Ｃが発生していないこと（ＮＯＴ状態Ｃ）」が判定されたときに、対処手順Ａ２が実行されるように、図２３に示す１番目のルールを図２４に示す１番目のルールのように変更する。
【００１０】
この結果、比較的実行時間のかかる準備コマンド（対処手順Ａ１）が、状態Ａおよび状態Ｂの検出時に実行開始される。対処手順Ａ１の実行開始は、図２２（ａ）に示す対処手順Ａの実行タイミングと同じであり、実行タイミングの遅れを緩和することができる。ただし、この場合にも、管理者、新たな障害対処ルールを作成したり（図２４の３番目参照。）、対処コマンドのみを含むように障害対処ルールを変更したり（図２４の１番目参照。）しなければならない。そのため、管理者は、障害対処ルールの追加に伴い、障害対処ルールを新たに作成したり、障害対処ルールを変更したりしなければならず、管理者に負担がかかってしまう。また、管理者は、障害対処ルールの追加に伴い、新しい障害対処ルールを作成することによって、さらに不具合が発生するという悪循環を招くおそれもある。そのため、障害対処ルールの追加時には、管理者は、追加に伴い新たに作成する障害対処ルールの内容や、障害対処ルールの変更内容を十分に検証しなければならず、負担が大きくなってしまう。
【００１１】
復旧対象装置が大規模であるために大量の障害対処ルールが存在する場合や、随時追加修正を繰り返したことにより複雑な相関関係を持つ障害対処ルールができてしまった場合等に、以上のような管理者の負担（障害対処ルールの検証、作成、変更等の負担）は、特に大きくなる。
【００１２】
また、管理者の負担が大きいだけでなく、障害対処ルールを追加していくことにより、障害復旧システムの処理負荷も大きくなってしまうという問題がある。障害対処ルールを追加して障害対処ルールの数を増加させていくと、各障害対処ルールの条件式に記述される状態の種類も増えていく。すると、障害復旧システムが、復旧対象装置から検出しなければならない状態の種類も増えていく。例えば、図２２（ａ）に示す障害対処ルールに従って、復旧処理コマンドを決定する場合には、障害復旧システムは、状態Ｃの発生を検出する必要はなかった。しかし、状態Ｃを条件式に含む障害対処ルールが管理者によって追加されたことにより、障害復旧システムは、復旧対象装置に状態Ｃが発生しているか否かも検出しなければならなくなり、それだけ障害復旧システムの処理負荷が大きくなる。
【００１３】
また、障害復旧システムは、各障害対処ルールの条件式が満たされているか否かを判定して復旧処理コマンドを決定しているので、障害対処ルールが増加すれば、条件式が満たされているか否かの判定処理が増加する。その結果、障害復旧システムの処理負荷が大きくなる。
【００１４】
そこで、本発明は、管理者のルール作成負担やルール作成時における既存のルールの検証負担を軽減させることを目的とする。また、障害復旧システムの処理負荷を軽減することを目的とする。
【課題を解決するための手段】
【００１５】
本発明による障害復旧システムは、情報処理システムの動作状態が、予め作成されたルールの条件式を満足する場合に、条件式が満たされたルールが定める復旧処理コマンドを実行する障害復旧システムであって、障害発生または障害発生の前兆と見なされる情報処理システムの動作状態を条件式とし、復旧処理コマンドの情報を有するルールであって、ユーザによって作成されたルールであるユーザ指定ルールを記憶するユーザ指定ルール蓄積手段と、条件式に共通部分を有する各ユーザ指定ルールの条件式が同時に満足されないように、前記ユーザ指定ルールの条件式を変更したルールを作成する同時不成立ルール作成手段とを備えたことを特徴とする。
【００１６】
そのような構成によれば、同時不成立ルール作成手段が、条件式に共通部分を有する各ユーザ指定ルールの条件式が同時に満足されないように、そのユーザ指定ルールの条件式を変更したルールを作成する。従って、管理者は、条件式が同時に満足されるか否かの検証を行わずにユーザ指定ルールを作成することができ、管理者のルール作成負担やルール検証負担が軽減される。
【００１７】
ユーザ指定ルール蓄積手段が、復旧処理コマンドの情報として、障害からの復旧または障害回避のための対処コマンドおよび前記対処コマンド実行の準備を行うための準備コマンドの情報を有するユーザ指定ルールを記憶し、ユーザ指定ルールの条件式を変更したルールとして同時不成立ルール作成手段に作成されたルールから準備コマンドの情報を削除するとともに、条件式に共通部分を有する各ユーザ指定ルールにおける前記共通部分を条件式とし、条件式を変更することによって作成されたルールの元となったユーザ指定ルールが有する準備コマンドの情報を有する準備ルールを作成する準備ルール作成手段を備えた構成であってもよい。
【００１８】
そのような構成によれば、準備ルール作成手段が、条件式に共通部分を有する各ユーザ指定ルールにおけるその共通部分を条件式とし、条件式を変更することによって作成されたルールの元となったユーザ指定ルールが有する準備コマンドの情報を有する準備ルールを作成するので、管理者にルールの検証負担をかけることなく、共通部分が満たされたときに準備コマンドを実行させることができる。そして、先に準備コマンドを実行させることによって、対処コマンドの実行の遅れを緩和することができる。
【００１９】
準備ルール作成手段が、同時不成立ルール作成手段が作成したルールに基づいて選択された対処コマンドの実行に失敗した場合に、ユーザ指定ルールの条件式を変更したルールとして同時不成立ルール作成手段に作成されたルールから準備コマンドの情報を削除するとともに、条件式に共通部分を有する各ユーザ指定ルールにおける前記共通部分を条件式とし、条件式を変更することによって作成されたルールの元となったユーザ指定ルールが有する準備コマンドの情報を有する準備ルールを作成する構成であってもよい。
【００２０】
そのような構成によれば、同時不成立ルール作成手段が作成したルールに基づいて選択された対処コマンドの実行に失敗するまでは、準備ルール作成手段は準備コマンドを作成しない。従って、対処コマンドの実行に失敗するまでは、準備コマンドが先に実行されることがなく、準備コマンド同士の競合を防止することができる。
【００２１】
準備コマンドおよび対処コマンドの情報を有する準備対処ルールと、準備コマンドの情報を有する準備ルールの条件式が同時に成立することがあり、準備コマンド同士が競合すると定められている場合に、前記準備対処ルールに、前記準備ルールの準備コマンドの実行取消を指示する取消コマンドの情報を付加する取消コマンド情報付加手段を備えた構成であってもよい。
【００２２】
そのような構成によれば、取消コマンド情報付加手段が、準備対処ルールに、競合する準備コマンドの実行取消を指示する取消コマンドの情報を付加するので、準備コマンド同士の競合を防止することができる。
【００２３】
条件式に共通部分を有する各ユーザ指定ルールにおける前記共通部分を条件式とし、前記各ユーザ指定ルールの条件式のうち前記共通部分以外に示される動作状態が発生しているか否かの検出を指示する検出コマンドの情報を有する検出ルールを作成する検出ルール作成手段を備えた構成であってもよい。
【００２４】
一のユーザ指定ルールの条件式全体が、複数のユーザ指定ルールの条件式の共通部分となっている場合に、前記共通部分を条件式とし、前記複数のユーザ指定ルールの条件式のうち前記共通部分以外に示される動作状態が発生しているか否かの検出を指示する検出コマンドの情報と、前記一のユーザ指定ルールが有する準備コマンドの情報とを有する検出ルールを作成するとともに、前記一のユーザ指定ルールから準備コマンドの情報を削除したルールを作成する検出ルール作成手段を備えた構成であってもよい。
【００２５】
情報処理システムの動作状態を検出する動作状態検出手段と、前記動作状態検出手段によって検出された動作状態によって条件式が満足されるルールを特定し、前記ルールが有する復旧処理コマンドの情報を出力する対処方法検索手段と、前記対処方法検索手段が復旧処理コマンドの情報として検出コマンドの情報を出力した場合に、前記検出コマンドに応じた動作状態が前記情報処理システムに発生しているか否かの検出を前記動作状態検出手段に指示する検出要素制御手段とを備えた構成であってもよい。
【００２６】
そのような構成によれば、動作状態検出手段は、当初、共通部分に示された動作状態が発生しているか否かだけを検出していればよく、処方法検索手段が復旧処理コマンドの情報として検出コマンドの情報を出力した場合に、その検出コマンドに応じた動作状態が情報処理システムに発生しているか否かの検出を開始すればよい。従って、検出コマンドに応じた動作状態が情報処理システムに発生しているか否かの検出を最初から行う必要がなく、障害復旧システムの処理負荷を軽減することができる。
【００２７】
情報処理システムの動作状態を検出する動作状態検出手段と、前記動作状態検出手段によって検出された動作状態によって条件式が満足されるルールを特定し、前記ルールが有する復旧処理コマンドの情報を出力する対処方法検索手段とを備え、前記対処方法検索手段は、検出ルールの条件式が満足されるまでは、前記検出ルールが有する検出コマンドの情報に対応する動作状態を条件式に含むルールを、条件式が満足されているか否かの判定対象から外すように構成されていてもよい。
【００２８】
そのような構成によれば、動作状態検出手段は、当初、検出ルールが有する検出コマンドの情報に対応する動作状態を条件式に含むルールを、条件式が満足されているか否かの判定対象から外すので、全てのルールについて条件式が満足されているか否かの判定を行わなくてよい。よって、障害復旧システムの処理負荷を軽減することができる。
【００２９】
また、本発明による障害復旧装置は、情報処理システムの動作状態が、予め作成されたルールの条件式を満足する場合に、条件式が満たされたルールが定める復旧処理コマンドの情報を出力する障害復旧装置であって、障害発生または障害発生の前兆と見なされる情報処理システムの動作状態を条件式とし、復旧処理コマンドの情報を有するルールであって、ユーザによって作成されたルールであるユーザ指定ルールを記憶するユーザ指定ルール蓄積手段と、条件式に共通部分を有する各ユーザ指定ルールの条件式が同時に満足されないように、前記ユーザ指定ルールの条件式を変更したルールを作成する同時不成立ルール作成手段とを備えたことを特徴とする。
【００３０】
また、本発明による障害復旧装置は、情報処理システムに対し復旧処理コマンドを実行することにより前記情報処理システムに障害からの復旧または障害の回避を行わせる障害復旧装置であって、前記情報処理システムの動作状態を検出する動作状態検出手段と、復旧処理コマンドの情報を受信し、前記情報が示す復旧処理コマンドを実行するコマンド実行手段と、コマンド実行手段が、復旧処理コマンドとして、所定の動作状態が発生しているか否かの検出を指示する検出コマンドを受信した場合に、前記動作状態が前記情報処理システムに発生しているか否かの検出を前記動作状態検出手段に指示する検出要素制御手段とを備えたことを特徴とする。
【００３１】
そのような構成によれば、所定の動作状態が発生しているか否かの検出を指示する検出コマンドを受信するまでは、動作状態検出手段は、その動作状態が発生しているか否かの検出を行わなくてよい。よって、障害復旧装置の処理負荷を軽減することができる。
【００３２】
また、本発明によるルール作成方法は、情報処理システムの動作状態が、予め作成されたルールの条件式を満足する場合に、条件式が満たされたルールが定める復旧処理コマンドを実行する障害復旧システムに適用されるルール作成方法であって、ユーザ指定ルール蓄積手段が、障害発生または障害発生の前兆と見なされる情報処理システムの動作状態を条件式とし、復旧処理コマンドの情報を有するルールであって、ユーザによって作成されたルールであるユーザ指定ルールを記憶し、同時不成立ルール作成手段が、条件式に共通部分を有する各ユーザ指定ルールの条件式が同時に満足されないように、前記ユーザ指定ルールの条件式を変更したルールを作成することを特徴とする。
【００３３】
また、本発明による障害復旧プログラムは、情報処理システムの動作状態が、予め作成されたルールの条件式を満足する場合に、条件式が満たされたルールが定める復旧処理コマンドの情報を出力するコンピュータであって、障害発生または障害発生の前兆と見なされる情報処理システムの動作状態を条件式とし、復旧処理コマンドの情報を有するルールであって、ユーザによって作成されたルールであるユーザ指定ルールを記憶するユーザ指定ルール蓄積手段を備えたコンピュータに、条件式に共通部分を有する各ユーザ指定ルールの条件式が同時に満足されないように、前記ユーザ指定ルールの条件式を変更したルールを作成する同時不成立ルール作成処理を実行させることを特徴とする。
【００３４】
また、本発明による障害復旧プログラムは、情報処理システムに対し復旧処理コマンドを実行することにより前記情報処理システムに障害からの復旧または障害の回避を行わせるコンピュータに、前記情報処理システムの動作状態を検出する動作状態検処理、復旧処理コマンドの情報を受信し、前記情報が示す復旧処理コマンドを実行するコマンド実行処理、および復旧処理コマンドとして、所定の動作状態が発生しているか否かの検出を指示する検出コマンドを受信した場合に、前記動作状態が前記情報処理システムに発生しているか否かの検出を前記動作状態検処理で開始させる検出要素制御処理を実行させることを特徴とする。
【発明の効果】
【００３５】
本発明によれば、管理者のルール作成負担やルール作成時における既存のルールの検証負担を軽減させることができる。また、障害復旧システムの処理負荷を軽減することができる。
【発明を実施するための最良の形態】
【００３６】
以下、本発明を実施するための最良の形態を図面を参照して説明する。
【００３７】
実施の形態１．
図１は、本発明の第１の実施の形態を示すブロック図である。第１の実施の形態における障害復旧システムは、エージェント装置２０と、マネージャ装置３０とを備える。エージェント装置２０は、復旧対象装置（図１に示すサービス実行手段１０）の動作状態を検出するとともに、マネージャ装置３０が決定した復旧処理コマンドを復旧対象装置に対して実行する。マネージャ装置３０は、エージェント装置２０が検出した復旧対象装置の動作状態に基づいて復旧処理コマンドを決定する。マネージャ装置３０とエージェント装置２０は、通信ネットワーク（図示せず。）によって接続される。図１では、マネージャ装置３０とエージェント装置２０を１台ずつ図示しているが、マネージャ装置３０に対して複数台のエージェント装置２０が接続されていてもよい。
【００３８】
エージェント装置２０は、動作状態検出手段１と、コマンド実行手段５とを備える。また、エージェント装置２０は、サービス実行手段１０に接続される。
【００３９】
サービス実行手段１０は、Ｗｅｂサービスや業務サービスといった情報通信サービスを提供する情報処理システムである。サービス実行手段１０は、１台の情報処理装置からなる構成であってもよいし、複数台の情報処理装置が接続されたネットワークシステムであってもよい。また、図１では、エージェント装置２０がサービス実行手段１０を含んでいるように図示しているが、エージェント装置２０とサービス実行手段１０とが通信ネットワークを介して接続される構成であってもよい。
【００４０】
動作状態検出手段１は、サービス実行手段１０の動作状態を検出し、対処方法検索手段３に出力（送信）する。検出する動作状態には、サービス実行手段１０の起動／停止状態、アプリケーションプログラムの起動／停止状態、アプリケーションプログラムのエラー状態、ＣＰＵ状態、メモリ状態、ディスク状態など各種の状態がある。サービス実行手段１０の動作状態を検出する方法としては、サービス実行手段１０にＳＮＭＰ（Simple Network Management Protocol ）エージェントを常駐させ、動作状態検出手段１が定期的にＳＮＭＰリクエストをＳＮＭＰエージェントへ送信することによって検出する方法や、サービス実行手段１０にＳＮＭＰトラップの設定を行い、ＳＮＭＰトラップイベントが発生したときにそのイベント（動作状態）を受信する方法など、任意の方法を使用することができる。
【００４１】
コマンド実行手段５は、マネージャ装置３０（具体的には、後述する対話制御手段４）から復旧処理コマンドの情報を受信し、サービス実行手段１０上でその復旧処理コマンドを実行する。
【００４２】
マネージャ装置３０は、ルール蓄積手段２と、対処方法検索手段３と、対話制御手段４と、ユーザ指定ルール蓄積手段６と、共通条件制御手段７とを備える。
【００４３】
ルール蓄積手段２は、障害対処ルールを蓄積する記憶装置である。既に説明したように、障害対処ルールは、障害が発生したと判定するための条件式と、その条件式を満足する状態を検出したときにサービス実行手段１０に対して実行する復旧処理コマンドの情報とを含む。条件式としては、障害が発生したとみなされるサービス実行手段１０の状態または障害発生の前兆とみなされるサービス実行手段１０の状態が記述される。条件式として記述される状態の具体例として、例えば、サービス実行手段１０として使用される情報処理装置の処理負荷、メモリ使用量、エラー発生状況等が挙げられる。以下の説明では、説明を簡単にするために、条件式に記述される状態を、「状態Ａ」、「状態Ｂ」等のように記号で示して説明する。復旧処理コマンドは、条件式が満たされる状態となったときに、障害からの復旧または障害の回避のために使われるコマンドである。
【００４４】
本発明においても、既に説明した場合と同様に、条件式を複数の状態のＡＮＤ（論理積）によって表してもよい。図２２等に示す場合と同様に、ここでは、論理積を“＆”記号によって表すこととする。すなわち、「状態Ａ＆状態Ｂ」という条件式は、「状態Ａおよび状態Ｂが共に真である（状態Ａおよび状態Ｂがともに検出されている）」ことを意味し、その条件式が満たされたときに、その条件式に対応する復旧処理コマンドを実行することを意味する。なお、複数の状態の論理和を用いて条件式を記述することも可能である。しかし、そのような条件式を含む障害対処ルールは、実質的に複数の障害対処ルールを含んでいるので、論理和を用いない複数の障害対処ルールに分けることができる。例えば、「状態Ａまたは状態Ｂが発生しているならば対処手順Ａを実行する。」という障害対処ルールは、「状態Ａが発生しているならば対処手順Ａを実行する。」、「状態Ｂが発生しているならば対処手順Ａを実行する。」という論理和を用いない２つの障害対処ルールに分けられる。本発明では、ルール蓄積手段２は、論理和を用いずに条件式が記述された障害対処ルールを記憶しているものとする。また、本実施の形態では、ある状態が発生していないこと（ある状態の否定）を、図２３等に示す場合と同様に“ＮＯＴ”で示すことにする。
【００４５】
対処方法検索手段３は、動作状態検出手段１によって検出されたサービス実行手段１０の動作状態の情報を動作状態検出手段１から受信する。そして、対処方法検索手段３は、条件式がその動作状態に合致している障害対処ルールをルール蓄積手段２から検索し、その障害対処ルール中の復旧処理コマンドの情報を対話制御手段４に出力する。
【００４６】
対話制御手段４は、例えば、ディスプレイ装置や入力デバイス（例えば、キーボード等）を備え、対処方法検索手段３の出力情報が示す復旧処理コマンドを実行するか否かを、ユーザ（例えば、サービス実行手段１０および障害復旧システムの管理者）との対話により決定する。すなわち、対話制御手段４は、その復旧処理コマンドを実行するか否かの決定を促すＧＵＩをディスプレイ装置（図示せず。）に表示し、実行する旨の指示が入力された場合、復旧処理コマンドを実行することを決定し、その復旧処理コマンドを示す情報をコマンド実行手段５に出力（送信）する。
【００４７】
また、対話制御手段４は、ユーザが作成したルールを入力し、ユーザ指定ルール蓄積手段６に記憶させる。ユーザが作成するルールも、障害対処ルールと同様の形式で記述され、条件式および復旧処理コマンドの情報を対応付けた形式になっている。ユーザが作成したルールは、ユーザ指定ルール蓄積手段６に記憶され、そのルールに基づいて、ルール蓄積手段２に記憶される障害対策ルールが生成される。従って、ルール蓄積手段２が記憶する障害対処ルールは、ユーザが作成したルールそのものではない。そこで、ユーザが作成したルールを、ユーザ指定ルールと記し、ルール蓄積手段２が記憶する障害対処ルールと区別する。対話制御手段４は、ユーザの操作に応じて、ユーザ指定ルール蓄積手段６に新たなユーザ指定ルールを追加記憶させたり、既にユーザ指定ルール蓄積手段６が記憶しているユーザ指定ルールを編集したりする。また、対話制御手段４は、ユーザの操作に応じて、ユーザ指定ルール蓄積手段６が記憶しているユーザ指定ルールの削除も行う。
【００４８】
ユーザ指定ルール蓄積手段６は、ユーザ指定ルールを記憶する。ユーザ指定ルールは、ユーザが作成したルールそのものである。従って、図２２（ｂ）で説明したような、実際にはユーザの意図に反する復旧処理コマンドの情報を導出してしまうようなルールになっている可能性が高い。
【００４９】
共通条件制御手段７は、ユーザ指定ルール蓄積手段６に新たなユーザ指定ルールが記憶された場合（新たにユーザ指定ルールが追加された場合や、ユーザ指定ルールの編集が行われた場合）、ルール蓄積手段２が記憶している障害対処ルール全体を消去する。そして、共通条件制御手段７は、ユーザ指定ルール蓄積手段６に記憶されているユーザ指定ルールに基づいて、矛盾のない障害対処ルールの集合を作成し、その障害対処ルールの集合をルール蓄積手段２に記憶させる。ユーザ指定ルールに基づいて障害対処ルールを作成する処理については後述する。なお、ここで「矛盾のない」とは、複数の障害対処ルールの条件式が同時に成立してしまうことがないことを意味する。
【００５０】
動作状態検出手段１およびコマンド実行手段５は、例えば、コンピュータと障害復旧プログラムによって実現することができる。この障害復旧プログラムは、コンピュータ（エージェント装置２０）の立ち上げ時等にコンピュータに読み取られ、コンピュータが障害復旧プログラムに従って動作することにより、コンピュータが動作状態検出手段１およびコマンド実行手段５として機能する。障害復旧プログラムは、エージェント装置２０が備える磁気ディスクや半導体メモリ等のコンピュータ可読記録媒体に予め記録される。
【００５１】
対処方法検索手段３、対話制御手段４、および共通条件制御手段７も、例えば、コンピュータと障害復旧プログラムによって実現することができる。この障害復旧プログラムは、コンピュータ（マネージャ装置３０）の立ち上げ時等にコンピュータに読み取られ、コンピュータが障害復旧プログラムに従って動作することにより、コンピュータが対処方法検索手段３、対話制御手段４、および共通条件制御手段７として機能する。障害復旧プログラムは、マネージャ装置３０が備える磁気ディスクや半導体メモリ等のコンピュータ可読記録媒体に予め記録される。また、ルール蓄積手段２およびユーザ指定ルール蓄積手段６は、例えば、マネージャ装置３０が備える記憶装置によって実現される。
【００５２】
また、動作状態検出手段１、コマンド実行手段５、対処方法検索手段３、対話制御手段４、および共通条件制御手段７をそれぞれハードウェア装置として実現してもよい。
【００５３】
次に、動作について説明する。
図２は、ユーザ指定ルールが修正されたときにおけるマネージャ装置３０（主に共通条件制御手段７）による処理経過の例を示すフローチャートである。また、図３は、ユーザ指定ルールに基づく矛盾解消の具体例を示す説明図である。本例では、ユーザ指定ルール蓄積手段６には、初期状態として、図３に示すユーザ指定ルール５０１が記憶されているものとする。
【００５４】
まず、対話制御手段４は、ユーザの操作に応じて、ユーザ指定ルール蓄積手段６内のユーザ指定ルールに対して追加や変更等を行う（ステップＳ２１１）。ここでは、対話制御手段４は、ユーザの操作に応じて、図３に示すユーザ指定ルール５０２をユーザ指定ルール蓄積手段６に追加記憶させる。この結果、ユーザ指定ルール蓄積手段６は、ユーザ指定ルール５０１，５０２を記憶する。
【００５５】
ユーザ指定ルール蓄積手段６が記憶するユーザ指定ルールが変更されると、共通条件制御手段７は、ユーザ指定ルール蓄積手段６が記憶するユーザ指定ルールのうち、条件式に共通部分を有するユーザ指定ルールの有無を判定する（ステップＳ２１２）。ステップＳ２１２において、条件式に共通部分を有するユーザ指定ルールがないと判定した場合（ステップＳ２１２におけるＮｏ）、共通条件制御手段７は、ユーザ指定ルール蓄積手段６が記憶しているユーザ指定ルールを障害対処ルールとしてルール蓄積手段２に記憶させる（ステップＳ２１４）。このとき、共通条件制御手段７は、ステップＳ２１２においてＮｏと判定した後、ルール蓄積手段２の記憶内容（障害対処ルール）を全て削除してからステップＳ２１４の処理を実行する。
【００５６】
一方、ステップＳ２１２において、条件式に共通部分を有するユーザ指定ルールがあると判定した場合（ステップＳ２１２におけるＹｅｓ）、共通条件制御手段７は、そのユーザ指定ルールを収集して、そのユーザ指定ルール間に矛盾がなくなるように、収集したユーザ指定ルールの条件式を変更する（ステップＳ２１３）。そして、共通条件制御手段７は、条件式を変更したユーザ指定ルールを障害対処ルールとしてルール蓄積手段２に記憶させる（ステップＳ２１４）。なお、このとき、条件式に他のユーザ指定ルールとの共通部分がないユーザ指定ルールが存在していた場合、共通条件制御手段７は、そのユーザ指定ルールについては、そのまま障害対処ルールとしてルール蓄積手段２に記憶させる。
【００５７】
図４は、ステップＳ２１３の処理（ユーザ指定ルール間に矛盾がなくなるように、ユーザ指定ルールの条件式を変更することによって障害対処ルールを作成する処理）の処理経過の一例を示すフローチャートである。共通条件制御手段７は、まず、ルール蓄積手段２に記憶された障害対処ルールを全て削除する（ステップＳ３０１）。次に、共通条件制御手段７は、ユーザ指定ルール蓄積手段６が記憶するユーザ指定ルールのうち、条件式に共通部分を有するユーザ指定ルールを収集する（ステップＳ３０２）。
【００５８】
共通条件制御手段７は、ステップＳ３０２で収集したユーザ指定ルールから、条件式の変更検証対象ルールを１つずつ選択する。以下、条件式の変更検証対象となるルールを第１ルールと記す。また、共通条件制御手段７は、第１ルールの条件式を変更するか否かを、他のユーザ指定ルールの条件式と比較しながら決定していく。この他のユーザ指定ルールを第２ルールと記す。第２ルールも１つずつ順次選択される。
【００５９】
共通条件制御手段７は、ステップＳ３０２の後、収集したユーザ指定ルールのうち、第１ルール（条件式の変更検証対象となるルール）として選択されていないユーザ指定ルールがあるか否かを判定する（ステップＳ３０３）。第１ルールとして選択されていないユーザ指定ルールがなければ（ステップＳ３０３におけるＮｏ）、ステップＳ２１３（図２参照。）の処理を終了する。収集したユーザ指定ルール中に未だ第１ルールとして選択されていないユーザ指定ルールがあれば、そのユーザ指定ルールの中から１つを選択して第１ルールとする（ステップＳ３０４）。ステップＳ３０２で収集されたユーザ指定ルールのうち、ステップＳ３０４で選択された第１ルール以外の全ユーザ指定ルールが順次第２ルールとして選択される。
【００６０】
共通条件制御手段７は、ステップＳ３０４の後、ステップＳ３０２で収集されたユーザ指定ルールであって、ステップＳ３０４で選択された第１ルール以外のユーザ指定ルールの中に、第２ルールとして選択されていないユーザ指定ルールがあるか否かを判定する（ステップＳ３０５）。第２ルールとして選択されていないユーザ指定ルールがなければ（ステップＳ３０５におけるＮｏ）、ステップＳ３０３に移行し、ステップＳ３０３以降の処理を繰り返す。第２ルールとして選択されていないユーザ指定ルールがあれば（ステップＳ３０５におけるＹｅｓ）、そのユーザ指定ルールの中から１つを選択して第２ルールとする（ステップＳ３０６）。
【００６１】
共通条件制御手段７は、第１ルールと第２ルールとが同時に成立し得るか否かを判定する（ステップＳ３０７）。ステップＳ３０７では、任意の状態Ｐについて、第１ルールと第２ルールのいずれかの条件式に「状態Ｐになっていること」が条件として記述され、他方の条件式に「状態Ｐになっていないこと」が条件として記述されているならば、第１ルールと第２ルールとが同時に成立し得ないと判定すればよい。また、そうでなければ、第１ルールと第２ルールとが同時に成立し得ると判定すればよい。例えば、一方の条件式に「・・・＆状態Ｐ＆・・・」と記述され、他方の条件式に「・・・＆（ＮＯＴ状態Ｐ）＆・・・」と記述されていれば、共通条件制御手段７は、第１ルールと第２ルールとが同時に成立し得ないと判定する。第１ルールと第２ルールとが同時に成立し得ないと判定した場合（ステップＳ３０７におけるＮｏ）、ステップＳ３０５に移行し、ステップＳ３０５以降の処理を繰り返す。
【００６２】
また、第１ルールと第２ルールとが同時に成立し得ると判定した場合（ステップＳ３０７におけるＹｅｓ）、共通条件制御手段７は、第２ルールの条件式内の共通部分以外の条件を抽出し、その否定を第１ルールの条件式に追加する（ステップＳ３０８）。このとき、共通条件制御手段７は、第１ルールの条件式に記述されていた条件式と、第２ルールから抽出した条件の否定とを“＆”で結べばよい。すなわち、第１ルールの条件式に記述されていた条件式と、第２ルールから抽出した条件の否定との論理積を、第１ルールの新たな条件式とすればよい。
【００６３】
共通条件制御手段７が、第２ルールの条件式内の共通部分以外の条件を抽出し、その否定を第１ルールの条件式に追加する（ステップＳ３０８）ことによって、第１ルールと第２ルールとは同時に成立し得ない（第１ルールの条件式と第２ルールの条件式とが同時に満たされ得ない）ことになる。このように複数のルールが同時に成立しないことを、各ルールが「一意に識別される」と表現することがある。
【００６４】
共通部分を有するユーザ指定ルールのグループが複数存在した場合、それらの各グループについて、図４に示すステップＳ３０１以降の処理を行えばよい。そして、各グループについて、ステップＳ３０１以降の処理が終了した後、ステップＳ２１４に移行すればよい。
【００６５】
なお、図２および図４の処理を行ったとしても、共通条件制御手段７は、ユーザ指定ルール蓄積手段６に記憶されているユーザ指定ルール自体については書き換えない。共通条件制御手段７は、ステップＳ３０２で収集したユーザ指定ルールをバッファ等（図示せず。）に記憶させ、そのバッファ等において条件式の変更などを行う。従って、ステップＳ２１１以降、ユーザ指定ルール蓄積手段６に記憶されているユーザ指定ルールの内容は変わらない。ただし、ユーザの操作に応じて、再度ステップＳ２１１の処理が行われれば、当然に、ユーザ指定ルール蓄積手段６に記憶されているユーザ指定ルールの内容は変更される。
【００６６】
図３に示すユーザ指定ルールを用いて、以上の処理を説明する。ユーザ指定ルール５０２が追加された（ステップＳ２１１）後、共通条件制御手段７は、ユーザ指定ルール蓄積手段６が記憶するユーザ指定ルールのうち、条件式に共通部分を有するユーザ指定ルールの有無を判定する（ステップＳ２１２）。図３に示すユーザ指定ルール５０１，５０２を参照すると、条件式において“状態Ａ ＆ 状態Ｂ”の部分が共通する（ステップＳ２１２におけるＹｅｓ）。
【００６７】
その結果、共通条件制御手段７は、ステップＳ２１３の処理を開始する。具体的には、まず、ルール蓄積手段２の記憶内容を削除する（ステップＳ３０１）。そして、共通条件制御手段７は、ユーザ指定ルール蓄積手段６から、条件式に共通部分（本例では、“状態Ａ ＆ 状態Ｂ”）を有するユーザ指定ルール５０１，５０２を収集する。この時点で、ユーザ指定ルール５０１，５０２は、いずれも第１ルールとして選択されていない。よって、ステップＳ３０３の判定後、ステップＳ３０４に移行する。ステップＳ３０４では、共通条件制御手段７は、第１ルールとして未だ選択されていないユーザ指定ルール５０１，５０２の中から１つを選択する（ここでは、ユーザ指定ルール５０１を選択するものとする。）。この時点で、ユーザ指定ルール５０２は第２ルールとして選択されていない。よって、ステップＳ３０５の判定後、ステップＳ３０６に移行する。ステップＳ３０６では、共通条件制御手段７は、ユーザ指定ルール５０２を第２ルールとして選択する。
【００６８】
次に、共通条件制御手段７は、第１ルールと第２ルールとが同時に成立し得るか否かを判定する（ステップＳ３０７）。第１ルール（ここでは、ユーザ指定ルール５０１）および第２ルール（ここでは、ユーザ指定ルール５０２）との間には、いずれかの条件式に「状態Ｐになっていること」が条件として記述され、他方の条件式に「状態Ｐになっていないこと」が条件として記述されているという関係は成立していない（状態Ｐは、任意の障害発生状態）。そのため、第１ルールと第２ルールとが同時に成立し得ると判定し、ステップＳ３０８に移行する。ステップＳ３０８では、共通条件制御手段７は、第２ルールの条件式内の共通部分以外の条件を抽出する。共通部分は“状態Ａ ＆ 状態Ｂ”であるので、それ以外の条件である“状態Ｃ”を第２ルールから抽出する。そして、共通条件制御手段７は、その否定である“（ＮＯＴ状態Ｃ）”と、第１ルールの条件式に記述されていた条件式“状態Ａ ＆ 状態Ｂ”とを“＆”で結び、第１ルールの条件式を“状態Ａ ＆ 状態Ｂ ＆ （ＮＯＴ状態Ｃ）”とする。この変更後のユーザ指定ルールを、図３では、ユーザ指定ルール５０１ａとして示している。これまでユーザ指定ルールとして５０１と記していたユーザ指定ルールを、以降、ユーザ指定ルール５０１ａと記す。
【００６９】
続いて、ステップＳ３０５に移行したときには、第２ルールとして選択されていないユーザ指定ルールは存在していない（なお、第１ルールとして選択されているユーザ指定ルールは、第２ルールとして選択されない。）。よって、ステップＳ３０３に移行する。このとき、図３に示すユーザ指定ルール５０２は、未だ第１ルールとして選択されていない。よって、ステップＳ３０３からステップＳ３０４に移行し、共通条件制御手段７は、ユーザ指定ルール５０２を第１ルールとして選択する。この時点で、ユーザ指定ルール５０１ａは第２ルールとして選択されていない。よって、ステップＳ３０５の判定後、ステップＳ３０６に移行する。ステップＳ３０６では、共通条件制御手段７は、ユーザ指定ルール５０１ａ（図３参照。）を第２ルールとして選択する。
【００７０】
次に、共通条件制御手段７は、第１ルールと第２ルールとが同時に成立し得るか否かを判定する（ステップＳ３０７）。第１ルール（ここでは、ユーザ指定ルール５０２）および第２ルール（ここでは、ユーザ指定ルール５０１ａ）を参照すると、一方の条件式には、“状態Ｃ”が記述され、他方の条件式には“（ＮＯＴ状態Ｃ）”が記述されている。よって、共通条件制御手段７は、第１ルールと第２ルールとが同時に成立し得ないと判定し（ステップＳ３０７におけるＮｏ）、ステップＳ３０５に移行する。
【００７１】
続いて、ステップＳ３０５に移行したときには、第２ルールとして選択されていないユーザ指定ルールは存在していない。よって、ステップＳ３０３に移行する。この時点で、第１ルールとして選択されていないユーザ指定ルールは存在しないので（ステップＳ３０３におけるＮｏ）、処理（図２に示すステップＳ２１３の処理）を終了する。この結果、本例では、ユーザ指定ルール５０２は変更されない。ステップＳ２１３に続く、ステップＳ２１４（図２参照。）では、共通条件制御手段７は、図３に示すユーザ指定ルール５０１ａ，５０２を、障害対処ルールとしてルール蓄積手段２に記憶させる。
【００７２】
ユーザが作成したユーザ指定ルール５０１，５０２は、矛盾する状態（条件式が同時に成立してしまうことがある状態）であったが、図２および図４に示す処理を実行することにより、ユーザ指定ルール５０１，５０２という集合は、ユーザ指定ルール５０１ａ，５０２（図３参照。）という集合に修正され、ユーザ指定ルール５０１ａ，５０２が障害対処ルールとしてルール蓄積手段２に記憶される。よって、ユーザが、自身の作成したユーザ指定ルールに対する検証を行わなくても、矛盾のない障害対処ルールを作成することができ、ユーザの負担を軽減することができる。
【００７３】
図３では、条件式に共通部分を有するユーザ指定ルールが２つある場合を示したが、そのようなユーザルールが３つ以上ある場合でも、図２および図４に示す処理により、矛盾のない障害対処ルールを作成することができる。図５は、条件式に共通部分を有するユーザ指定ルールが３つある場合における矛盾解消の具体例を示す説明図である。ステップＳ３０１までの処理は、既に説明した場合と同様である。ステップＳ３０２では、共通条件制御手段７は、図５に示すユーザ指定ルール５０１〜５０３を収集する。
【００７４】
続く処理（ステップＳ３０４）で、ユーザ指定ルール５０１を第１ルールとして選択したとする。また、ステップＳ３０６で、ユーザ指定ルール５０２を第２ルールとして選択したとする。ステップＳ３０７では、共通条件制御手段７は、第１ルールと第２ルールとが同時に成立し得るか否かを判定する。このとき、第１ルール（ここでは、ユーザ指定ルール５０１）および第２ルール（ここでは、ユーザ指定ルール５０２）との間には、いずれかの条件式に「状態Ｐになっていること」が条件として記述され、他方の条件式に「状態Ｐになっていないこと」が条件として記述されているという関係は成立していない。よって、第１ルールと第２ルールとが同時に成立し得ると判定し、ステップＳ３０８に移行する。ステップＳ３０８では、共通条件制御手段７は、第２ルールの条件式内の共通部分以外の条件を抽出する。共通部分は“状態Ａ ＆ 状態Ｂ”であるので、それ以外の条件である“状態Ｃ”を第２ルールから抽出する。そして、共通条件制御手段７は、その否定である“（ＮＯＴ状態Ｃ）”と、第１ルールの条件式に記述されていた条件式“状態Ａ ＆ 状態Ｂ”とを“＆”で結び、第１ルールの条件式を“状態Ａ ＆ 状態Ｂ ＆ （ＮＯＴ状態Ｃ）”とする。その後のステップＳ３０６で、ユーザ指定ルール５０３を第２ルールとして選択したとする。この場合も、ステップＳ３０７において、共通条件制御手段７は、第１ルールの条件式“状態Ａ ＆ 状態Ｂ ＆ （ＮＯＴ状態Ｃ）”と、第２ルールの条件式“状態Ａ ＆ 状態Ｂ ＆ 状態Ｄ”とを参照し、第１ルールと第２ルールとが同時に成立し得ると判定する。そして、ステップＳ３０８では、共通条件制御手段７は、第２ルールの条件式内の共通部分以外の条件を抽出する。共通部分は“状態Ａ ＆ 状態Ｂ”であるので、それ以外の条件である“状態Ｄ”を第２ルールから抽出する。そして、共通条件制御手段７は、その否定である“（ＮＯＴ状態Ｄ）”と、第１ルールの条件式に記述されていた条件式“状態Ａ ＆ 状態Ｂ ＆ （ＮＯＴ状態Ｃ）”とを“＆”で結び、第１ルールの条件式を“状態Ａ ＆ 状態Ｂ ＆ （ＮＯＴ状態Ｃ） ＆ （ＮＯＴ状態Ｄ）”とする。この変更後のユーザ指定ルールを、図５では、ユーザ指定ルール５０１ｂとして示している。これまでユーザ指定ルールとして５０１と記していたユーザ指定ルールを、以降、ユーザ指定ルール５０１ｂと記す。
【００７５】
次に、ユーザ指定ルール５０２を第１ルールとして選択したとする。また、ステップＳ３０６で、ユーザ指定ルール５０１ｂを第２ルールとして選択したとする。すると、第１ルールの条件式の中には“状態Ｃ”が記述され、第２ルールの条件式には“（ＮＯＴ状態Ｃ）”が記述されている。よって、共通条件制御手段７は、第１ルールと第２ルールとが同時に成立し得ないと判定し、ステップＳ３０５に移行する。次に、共通条件制御手段７は、ユーザ指定ルール５０３を第２ルールとして選択する。このとき、第１ルール（ここでは、ユーザ指定ルール５０２）および第２ルール（ここでは、ユーザ指定ルール５０３）との間には、いずれかの条件式に「状態Ｐになっていること」が条件として記述され、他方の条件式に「状態Ｐになっていないこと」が条件として記述されているという関係は成立していない（状態Ｐは、任意の障害発生状態）。よって、第１ルールと第２ルールとが同時に成立し得ると判定し、ステップＳ３０８に移行する。ステップＳ３０８では、共通条件制御手段７は、第２ルールの条件式内の共通部分以外の条件を抽出する。共通部分は“状態Ａ ＆ 状態Ｂ”であるので、それ以外の条件である“状態Ｄ”を第２ルールから抽出する。そして、共通条件制御手段７は、その否定である“（ＮＯＴ状態Ｄ）”と、第１ルールの条件式に記述されていた条件式“状態Ａ ＆ 状態Ｂ ＆ 状態Ｃ”とを“＆”で結び、第１ルールの条件式を“状態Ａ ＆ 状態Ｂ ＆ 状態Ｃ ＆ （ＮＯＴ状態Ｄ）”とする。この変更後のユーザ指定ルールを、図５では、ユーザ指定ルール５０２ｂとして示している。これまでユーザ指定ルールとして５０２と記していたユーザ指定ルールを、以降、ユーザ指定ルール５０２ｂと記す。
【００７６】
次に、ユーザ指定ルール５０３を第１ルールとして選択したとする。また、ステップＳ３０６で、ユーザ指定ルール５０１ｂを第２ルールとして選択したとする。すると、第１ルールの条件式の中には“状態Ｄ”が記述され、第２ルールの条件式には“（ＮＯＴ状態Ｄ）”が記述されている。よって、共通条件制御手段７は、第１ルールと第２ルールとが同時に成立し得ないと判定し、ステップＳ３０５に移行する。次に、共通条件制御手段７は、ユーザ指定ルール５０２ｂを第２ルールとして選択したとする。この場合も、第１ルールの条件式の中には“状態Ｄ”が記述され、第２ルールの条件式には“（ＮＯＴ状態Ｄ）”が記述されている。よって、共通条件制御手段７は、第１ルールと第２ルールとが同時に成立し得ないと判定し、ステップＳ３０５に移行する。従って、ユーザ指定ルール５０３の条件式は変更されない。共通条件制御手段７は、収集した３つのユーザ指定ルールをそれぞれ第１ルールとして選択したので、次にステップＳ３０３に移行したときにはＮｏと判定し、ステップＳ２１３（図２参照。）の処理を終了する。そして、ステップ２１４において、図５に示すユーザ指定ルール５０１ｂ，５０２ｂ，５０３を障害対処ルールとしてルール蓄積手段２に記憶させる。
【００７７】
障害復旧システムは、サービス実行手段１０の状態を検出し、その状態と、以上のようにルール蓄積手段２に記憶された障害対処ルールとに基づいて復旧処理コマンドを決定し、サービス実行手段１０に対し、その復旧処理コマンドを実行する。図６は、サービス実行手段１０の状態検出から、復旧処理コマンド実行までの処理経過を示すフローチャートである。
【００７８】
動作状態検出手段１は、サービス実行手段１０の動作状態を検出し、通信ネットワークを介して対処方法検索手段３に動作状態の情報を送信する（ステップＳ２０１）。対処方法検索手段３は、動作状態検出手段１から現在の動作状態の情報を受信し、ルール蓄積手段２に蓄積されている各障害対処ルールの中に、条件式が満たされている障害対処ルールがあるか否かを判定する（ステップＳ２０２）。サービス実行手段１０の動作状態によっていずれの障害対処ルールの条件式も満たされていない場合（ステップＳ２０２におけるＮｏ）、障害が発生していないものとしてステップＳ２０１に移行し、ステップＳ２０１移行の処理を繰り返す。
【００７９】
サービス実行手段１０の動作状態によって条件式が満たされる障害対処ルールが存在する場合には（ステップＳ２０２におけるＹｅｓ）、対処方法検索手段３は、障害発生とみなして、その障害対処ルールに含まれる復旧処理コマンドの情報を抽出し、その情報を対話制御手段４に出力する。対話制御手段４は、ＧＵＩによって、その復旧処理コマンドの情報を出力し、その復旧処理コマンドを実行するか否かの決定をユーザ（管理者）に促す（ステップＳ２０３）。復旧処理コマンドを実行しない旨が管理者によって入力された場合、ステップＳ２０１に移行し、ステップＳ２０１以降の処理を繰り返す。なお、ユーザに適切な判断を行わせるために、ＧＵＩと併せて、サービス実行手段１０の動作状態や、その動作状態によって満たされた条件式の情報等を表示出力してもよい。また、特定の復旧処理コマンドについては、管理者に問い合わせることなく自動的に実行してよいという設定を対話制御手段４に対して施しておいてもよい。この場合、対話制御手段４は、その特定の復旧処理コマンドの情報が入力されると、その復旧処理コマンドを実行するか否かの決定を促すＧＵＩを表示することなく、その特定の復旧処理コマンドの情報をコマンド実行手段５に送信する。
【００８０】
復旧処理コマンドを実行する旨が管理者によって入力された場合（ステップＳ２０３におけるＹｅｓ）、対話制御手段４は、その復旧処理コマンドの情報をコマンド実行手段５に送信し、コマンド実行手段５はサービス実行手段１０上でその復旧処理コマンドを実行する（ステップＳ２０４）。
【００８１】
例えば、図３に示すルール５０１ａ，５０２が障害対処ルールとしてルール蓄積手段２に記憶されているとする。この場合、動作状態検出手段１によって、状態Ａ，Ｂ，Ｃのいずれもが発生している場合、障害対処ルール５０２の条件式が満たされる。従って、対処方法検索手段３は、障害対処ルール５０２における復旧処理コマンドの情報である「対処手順Ｂ」を対話制御手段４に出力する。対話制御手段４は、ＧＵＩによって「対処手順Ｂ」の実行可否の決定を管理者に促し、実行する旨の指示が入力されると、「対処手順Ｂ」という情報をコマンド実行手段５に送信する。そして、コマンド実行手段５は、対処手順Ｂを実行する。その結果、状態Ａ，Ｂ，Ｃがいずれも発生してしまっているという障害が復旧または回避されることになる。
【００８２】
本実施の形態によれば、ユーザ指定ルールの修正（追加や変更等）の結果、条件式に共通部分を有するユーザ指定ルールが存在した場合、共通条件制御手段７が、ステップＳ３０１以降の処理を行い、矛盾がなくなるようにユーザ指定ルールの条件式を修正する。そして、共通条件制御手段７が、修正後のユーザ指定ルールを障害対処ルールとしてルール蓄積手段２に記憶させる。従って、ユーザ（管理者）にとって、自らが作成したユーザ指定ルールに対する無矛盾性検証、ユーザ指定ルールの変更等の負担が大幅に軽減される。
【００８３】
また、管理者は自らが意図したユーザ指定ルールを作成すれば、そのユーザ指定ルールに基づく矛盾のない障害対処ルールが作成される。そして、障害復旧システムが図６に示す処理を実行する際には、障害対処ルールが作成されていればよく、管理者が障害対処ルールの全てを理解している必要はない。よって、管理者の負担が軽減される。障害対処ルールは、ステップＳ３０８で条件が新たに追加されている場合があるので、必ずしも管理者にとって理解しやすい記述とはなっていない。例えば、図５に示す例では、条件式に“（ＮＯＴ状態Ｃ） ＆ （ＮＯＴ状態Ｄ）”が追加されているが、この追加条件は、管理者自身が記述したものではない。このような条件追加が多く行われた障害対処ルールを管理者が参照しても、本来何を目的としたルールであったのかを理解することが困難となる。しかし、上記のように、管理者はそのような障害対処ルールを理解する必要がないので、負担が軽減される。
【００８４】
また、共通条件制御手段７は、ステップＳ３０２で収集したユーザ指定ルールをバッファ等（図示せず。）に記憶させ、そのバッファ等においてユーザ指定ルールを行う。よって、ユーザ指定ルール蓄積手段６には、管理者によって入力されたユーザ指定ルールが変更されることなく記憶されている。対話制御手段４は、ユーザ指定ルール蓄積手段６に記憶されたユーザ指定ルールを管理者に提示する。この結果、管理者に、管理者自身が入力した理解容易なユーザ指定ルールを提示することになる。従って、管理者は、そのような理解容易なユーザ指定ルールを参照して、新たなユーザ指定ルールの追加やユーザ指定ルールの変更を効率よく行える。
【００８５】
また、本発明では、条件式が満たされた障害対処ルールが存在した場合、対処方法検索手段３が、その条件式に対応する復旧処理コマンドの情報を出力し、その情報は対話制御手段４を介して、コマンド実行手段５に送信される。コマンド実行手段５は、受信した情報が示す復旧処理コマンドをサービス実行手段１０に対して実行する。従って、サービス実行手段１０における障害復旧や障害回避を迅速に行うことができる。
【００８６】
実施の形態２．
本発明の第２の実施の形態における障害復旧システムの構成は、図１に例示する構成と同様であり、図１を用いて第２の実施の形態について説明する。ただし、第２の実施の形態では、共通条件制御手段７は、第１の実施の形態における動作に加え、さらに他の動作も行う。
【００８７】
サービス実行手段１０の状態検出から、復旧処理コマンド実行までの処理経過は、第１の実施の形態（図６参照。）と同様である。
【００８８】
また、第２の実施の形態では、ユーザ指定ルールにおける復旧処理コマンドには、対処コマンドおよび準備コマンドが含まれているものとする。すなわち、対話制御手段４が、ユーザ（管理者）の操作に応じてユーザ指定ルールを入力する場合、その個々のユーザ指定ルールには、復旧処理コマンドの情報として対処コマンドおよび準備コマンドの情報がそれぞれ含まれているものとする。対処コマンドは、サービス実行手段１０を障害から復旧させたり、障害発生を回避させたりするためのコマンドである。準備コマンドは、対処コマンド実行の準備を行うためのコマンドである。
【００８９】
準備コマンドによる事前準備の例として、データのバックアップ、コマンドのダウンロード、切替用情報処理装置に対する準備等が挙げられる。切替用情報処理装置に対する準備の例として、例えば、サービス実行手段１０が、障害発生時に用いられる切替用情報処理装置を含む複数の情報処理装置によって構成されるシステムである場合おける、切替用情報処理装置に対するソフトウェアインストール等が挙げられる。対処コマンドによる対処の例としては、サービス実行手段１０の設定変更や、切替用情報処理装置への切り替え等が挙げられる。切替用情報処理装置への切り替えとは、障害が発生した情報処理装置ではなく切替用情報処理装置にデータが流れるようにサービス実行手段１０内のデータ転送経路を切り替えることである。
【００９０】
準備コマンドの特徴として、実行時間が比較的長いことが挙げられる。また、サービス実行手段１０に対して準備コマンドを実行したとしても、サービス実行手段１０を準備コマンド実行前の状態に戻すことができるという特徴がある。一方、対処コマンドの特徴として、対処コマンド実行後にサービス実行手段１０が情報通信サービスを提供した場合、サービス実行手段１０を対処コマンド実行前の状態に戻すことができないということが挙げられる。例えば、対処コマンドを実行したことにより、サービス実行手段１０の設定が変更され、その後、サービス実行手段１０が情報通信サービスを提供したとする。すると、情報通信サービスを提供に伴い、変更後の設定に基づいた新たなデータが生成されることになる。このとき、サービス実行手段１０の設定自体は元の設定に戻すことができるが、その状態では、新たに生成されたデータに対する処理を行うことができない。このように設定を戻したとしても、設定変更後に生成されたデータが既に発生した状態になっているため、サービス実行手段１０を対処コマンド実行前の状態に戻すことができない。よって、対処コマンドは、サービス実行手段１０に対して不可逆な変更を加えるコマンドであると言える。
【００９１】
ユーザ自身が作成したユーザ指定ルールにおける復旧処理コマンドの情報には、対処コマンドおよび準備コマンドの両方の情報が含まれているが、ルール蓄積手段２が記憶する復旧処理コマンドでは、対処コマンドと準備コマンドのうちのいずれか一方のみの情報が含まれていてもよい。また、復旧処理コマンドでは、対処コマンドと準備コマンドの両方の情報が含まれていてもよい。
【００９２】
共通条件制御手段７は、第１の実施の形態と同様に、ユーザ指定ルールの矛盾を解消して、ユーザ指定ルールが一意に識別されるようにする処理（図４に示すステップＳ３０１〜Ｓ３０８の処理）を実行する。本実施の形態では、共通条件制御手段７は、さらに以下の処理を行う。すなわち、一意に識別できるように条件式が変更されたユーザ指定ルールと、変更前のユーザ指定ルールとを比較し、変更されているユーザ指定ルールを特定する。そして、共通条件制御手段７は、その変更されたユーザ指定ルールの変更前の条件式を条件式とし、変更前の復旧処理コマンドに含まれる準備コマンドのみを復旧処理コマンドとする新たな障害対処ルールを作成する。また、共通条件制御手段７は、変更されたユーザ指定ルールにおいて復旧処理コマンドとして含まれている準備コマンドの情報を削除し、対処コマンドが残るように、さらにユーザ指定コマンドを変更する。共通条件制御手段７は、以上の処理を行ったユーザ指定コマンドおよび新たに作成した障害対処ルールを、障害対処ルールとしてルール蓄積手段２に記憶させる。
【００９３】
以下、第２の実施の形態の動作について説明する。図７は、ユーザ指定ルールが修正されたときにおけるマネージャ装置３０（主に共通条件制御手段７）による処理経過の例を示すフローチャートである。また、図８は、ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。
【００９４】
まず、対話制御手段４は、ユーザの操作に応じて、ユーザ指定ルール蓄積手段６内のユーザ指定ルールに対して追加や変更等を行う（ステップＳ２２１）。ここでは、元々図８（ａ）に示すユーザ指定ルール６０１が記憶されていて、ステップＳ２２１において、対話制御手段４がユーザの操作に応じてユーザ指定ルール６０２を追加したものとする。ステップＳ２２１の結果、ユーザ指定ルール蓄積手段６には、ユーザ指定ルール６０１，６０２が記憶されている。本実施の形態では、ユーザ指定ルールにおける復旧処理コマンドの情報には、対処コマンドおよび準備コマンドの両方の情報が含まれる。図８（ａ）に示す例では、ユーザ指定ルール６０１は、「準備Ａ（準備コマンド）」および「対処Ａ（対処コマンド）」の情報を含んでいる。同様に、ユーザ指定ルール６０２は、「準備Ｂ（準備コマンド）」および「対処Ｂ（対処コマンド）」の情報を含んでいる
【００９５】
ユーザ指定ルール蓄積手段６が記憶するユーザ指定ルールが変更されると、共通条件制御手段７は、ユーザ指定ルール蓄積手段６が記憶するユーザ指定ルールのうち、条件式に共通部分を有するユーザ指定ルールの有無を判定する（ステップＳ２２２）。この処理は、第１の実施の形態におけるステップＳ２１２の処理と同様である。また、ステップＳ２２２において、条件式に共通部分を有するユーザ指定ルールがないと判定した場合（ステップＳ２２２におけるＮｏ）、共通条件制御手段７は、ユーザ指定ルール蓄積手段６が記憶しているユーザ指定ルールを障害対処ルールとしてルール蓄積手段２に記憶させる（ステップＳ２２５）。ステップＳ２２２においてＮｏと判定し、ステップＳ２２５に移行する際の共通条件制御手段７の動作は、第１の実施の形態で、ステップＳ２１２の次にステップＳ２１４に移行する動作と同様である。
【００９６】
一方、ステップＳ２２２において、条件式に共通部分を有するユーザ指定ルールがあると判定した場合（ステップＳ２２２におけるＹｅｓ）、共通条件制御手段７は、そのユーザ指定ルールを収集して、そのユーザ指定ルール間に矛盾がなくなるように、収集したユーザ指定ルールの条件式を変更する（ステップＳ２２３）。ステップＳ２２３の処理は、第１の実施の形態におけるステップＳ２１３の処理と同様である。より詳細には、ステップＳ２２３の処理として、第１の実施の形態で示したステップＳ３０１〜Ｓ３０８（図４参照。）と同様の処理を実行すればよい。ステップＳ２２３の結果、図８（ａ）に示すユーザ指定ルール６０１，６０２から、図８（ｂ）に示すユーザ指定ルール６０１ａ，６０２ａが生成される。
【００９７】
ステップＳ２２３の後、共通条件制御手段７は、復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールの作成や、対処コマンドのみを含むようにユーザ指定ルールを変更する処理を実行する（ステップＳ２２４）。そして、共通条件制御手段７は、ステップＳ２２４の結果得られた各ルール（ユーザ指定ルールや新たに作成した障害対処ルール）を、障害対処ルールとしてルール蓄積手段２に記憶させる（ステップＳ２２５）。なお、このとき、条件式に他のユーザ指定ルールとの共通部分がないユーザ指定ルールが存在していた場合、共通条件制御手段７は、そのユーザ指定ルールについては、そのまま障害対処ルールとしてルール蓄積手段２に記憶させる。
【００９８】
図９は、ステップＳ２２４の処理（復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールの作成や、対処コマンドのみを含むようにユーザ指定ルールを変更する処理）の処理経過の一例を示す説明図である。ステップＳ２２３の処理により、図８（ｂ）に例示するような一意に識別されるユーザ指定ルールを導出した後、共通条件制御手段７は、ステップＳ２２３の矛盾解消処理において条件式が変更されたユーザ指定ルールから準備コマンドの情報を削除する（ステップＳ３２１）。
【００９９】
ステップＳ３２１の後、共通条件制御手段７は、ステップＳ２２３の処理において条件式が変更されたユーザ指定ルールにおける元の（変更前の）ユーザ指定ルールを抽出する（ステップＳ３２２）。ユーザ指定ルール蓄積手段６には、ユーザによって作成されたユーザ指定ルールがそのまま記憶されているので、共通条件制御手段７は、ユーザ指定ルール蓄積手段６から変更前のユーザ指定ルールを読み込めばよい。
【０１００】
ステップＳ３２２の後、共通条件制御手段７は、ステップＳ３２２で抽出したユーザ指定ルール（条件式が変更されたユーザ指定ルールにおける元のユーザ指定ルール）の条件式と同一の条件式を有し、復旧処理コマンドの情報として、ステップＳ３２２で抽出したユーザ指定ルールに含まれる準備コマンドの情報を有する障害対処ルールを作成する（ステップＳ３２３）。
【０１０１】
共通部分を有するユーザ指定ルールのグループが複数存在した場合、それらの各グループについて、図９に示すステップＳ３２１以降の処理を行えばよい。そして、各グループについて、ステップＳ３２１以降の処理が終了した後、ステップＳ２２５に移行すればよい。
【０１０２】
図８を用いて、以上の処理を説明する。共通条件制御手段７は、ユーザ自身が作成したユーザ指定ルール６０１，６０２に基づいて、ステップＳ２２３の処理（より具体的には図４に示すステップＳ３０１〜Ｓ３０８の処理）を実行することにより、ユーザ指定ルール６０１ａ，６０２ａ（図８（ｂ）参照。）を作成する。この作成過程は、第１の実施の形態において図３を用いて説明した場合と同様である。なお、図８（ｃ）は、図９に示すステップＳ３２１〜Ｓ３２３の処理の後における各ルールを示す。
【０１０３】
ユーザ指定ルール６０１ａ，６０２ａ作成後、共通条件制御手段７は、ステップＳ２２３の処理において条件式が変更されたユーザ指定ルールから準備コマンドの情報を削除する（ステップＳ３２１）。図８（ｂ）に示すユーザ指定ルール６０１ａは、図８（ａ）に示す条件式を変更し、“（ＮＯＴ状態Ｃ）”をいう条件を追加して作成されている。従って、共通条件制御手段７は、ユーザ指定ルール６０１ａから準備コマンドである「準備Ａ」の情報を削除する。この結果を、図８（ｃ）においてユーザ指定ルール６０１ｂとして示している。また、図８（ｂ）に示すユーザ指定ルール６０２ａは、元のユーザ指定ルール６０２と同一であり、変更されていない。従って、共通条件制御手段７は、ユーザ指定ルール６０２ａからは準備コマンドの情報を削除しない。よって、図８（ｃ）にユーザ指定ルール６０１ｂとして示しているように、復旧処理コマンドの情報として「準備Ｂ」が残される。
【０１０４】
続く、ステップＳ３２２において、共通条件制御手段７は、ステップＳ２２３の処理において条件式が変更されたユーザ指定ルールにおける元の（変更前の）ユーザ指定ルールを抽出する。本例では、条件式が変更されたユーザ指定ルール６０１ａの元のユーザ指定ルール６０１をユーザ指定ルール蓄積手段６から抽出すればよい。ユーザ指定ルール６０２ａに関しては条件式が変更されていないので、その元のユーザ指定ルール６０２を抽出する必要はない。
【０１０５】
次のステップＳ３２３では、共通条件制御手段７は、抽出したユーザ指定ルール６０１の条件式と同一の条件式“状態Ａ ＆ 状態Ｂ”を有し、復旧処理コマンドの情報として、抽出したユーザ指定ルール６０１に含まれる準備コマンドの情報（「準備Ａ」）を有する障害対処ルールを作成する。図８（ｃ）では、この障害対処ルールを、障害対処ルール６０３ｂとして示している。
【０１０６】
以上の処理の結果、図８（ｃ）に示すルール６０１ｂ、６０２ｂ、６０３ｂが生成される。共通条件制御手段７は、これらのルール６０１ｂ、６０２ｂ、６０３ｂを障害対処ルールとしてルール蓄積手段２に記憶させる（図７に示すステップＳ２２５）。
【０１０７】
図８（ｂ）に示すユーザ指定ルール６０１ａ，６０２ａを障害対処ルールとした場合、「対処Ｂ」の実行タイミングは、「状態Ａかつ状態Ｂかつ状態Ｃ」が検出された時点である。これは、ユーザ自身が作成したユーザ指定ルール６０２において規定されている「対処Ｂ」の実行タイミングと同一である。一方、「対処Ａ」の実行タイミングは、「状態Ａおよび状態Ｂであることが検出され、かつ状態Ｃでないこと」が検出された時点である。このタイミングは、ユーザ自身が作成したユーザ指定ルール６０１において規定されている「対処Ａ」の実行タイミングよりも遅れる。状態Ｃが発生していないことを判定する分だけ条件式の判定時間がかかるためのである。
【０１０８】
第２の実施の形態によれば、図８（ａ），（ｂ）に示すユーザ指定ルールを用いてステップＳ２２４（より具体的には図９に示すステップＳ３２１〜Ｓ３２３）を行い、図８（ｃ）に例示するルール６０１ｂ，６０２ｂ，６０３ｃを生成する。そして、このルール群を障害対処ルールとする。この場合、「状態Ａかつ状態Ｂ」が検出された時点で、「準備Ａ」が実行される。その後、状態Ｃが発生しているか否かが判定された時に、「準備Ｂ、対処Ｂ」または「対処Ａ」が選択的に実行される。「準備Ａ」の実行タイミングは、ユーザ自身が作成したユーザ指定ルール６０１において規定されている「準備Ａ、対処Ａ」の実行タイミングと同一である。従って、第２の実施の形態によれば、比較的実行時間のかかる「準備Ａ」の実行タイミングを、ユーザ自身が作成したユーザ指定ルールにおいて規定されている実行タイミングにあわせることができ、対処の実行の遅れを緩和することができる。
【０１０９】
図８では、ステップＳ２２１（図７参照。）後において、条件式に共通部分を有するユーザ指定ルールが２つある場合を示したが、そのようなユーザルールが３つ以上ある場合でも、同様に処理を行う。以下、ステップＳ２２１（図７参照。）後において、条件式に共通部分を有するユーザ指定ルールが３つである場合を例に説明する。図１０は、ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。図１０（ａ）は、ステップＳ２２１後におけるユーザ指定ルールを表し、図１０（ｂ）は、ステップＳ２２３の矛盾解消処理後のユーザ指定ルールを表す。図１０（ａ）に示すユーザ指定ルール６１１〜６１３に基づいて、図１０（ｂ）に示すユーザ指定ルール６１１ａ〜６１３ａを導出する処理は、図５を用いて説明した場合と同様である。
【０１１０】
図１０（ｂ）に示すユーザ指定ルール６１１ａ〜６１３ａの作成後、共通条件制御手段７は、ステップＳ２２３で条件式が変更されたユーザ指定ルールから準備コマンドの情報を削除する（ステップＳ３２１）。図１０（ｂ）に示すユーザ指定ルール６１１ａは、図１０（ａ）に示す条件式を変更し、“（ＮＯＴ状態Ｃ） ＆ （ＮＯＴ状態Ｄ）”という条件を追加して作成されている。従って、共通条件制御手段７は、ユーザ指定ルール６１１ａから「準備Ａ」の情報を削除する。この結果を図１０（ｃ）においてユーザ指定ルール６１１ｂとして示している。同様に、共通条件制御手段７は、ユーザ指定ルール６１２ａから「準備Ｂ」の情報を削除する。この結果を図１０（ｃ）においてユーザ指定ルール６１２ｂとして示している。また、図１０（ｂ）に示すユーザ指定ルール６１３ａは、元のユーザ指定ルール６１３と同一であり、変更されていない。従って、共通条件制御手段７は、ユーザ指定ルール６１３ａからは準備コマンドの情報を削除しない。よって、図１０（ｃ）にユーザ指定ルール６１３ｂとして示しているように、復旧処理コマンドの情報として「準備Ｃ」が残される。
【０１１１】
続く、ステップＳ３２２において、共通条件制御手段７は、ステップＳ２２３の処理で条件式が変更されたユーザ指定ルールにおける元の（変更前の）ユーザ指定ルールを抽出する。本例では、条件式が変更されたユーザ指定ルール６１１ａ，６１２ａの元のユーザ指定ルール６１１，６１２をユーザ指定ルール蓄積手段６から抽出すればよい。ユーザ指定ルール６１３ａに関しては条件式が変更されていないので、その元のユーザ指定ルール６１３を抽出する必要はない。
【０１１２】
次のステップＳ３２３では、共通条件制御手段７は、抽出したユーザ指定ルール６１１の条件式と同一の条件式“状態Ａ ＆ 状態Ｂ”を有し、復旧処理コマンドの情報として、抽出したユーザ指定ルール６１１に含まれる準備コマンドの情報（「準備Ａ」）を有する障害対処ルールを作成する。図１０（ｃ）では、この障害対処ルールを、障害対処ルール６１４ｂとして示している。同様に、共通条件制御手段７は、抽出したユーザ指定ルール６１２の条件式と同一の条件式“状態Ａ ＆ 状態Ｂ ＆ 状態Ｃ”を有し、復旧処理コマンドの情報として、抽出したユーザ指定ルール６１２に含まれる準備コマンドの情報（「準備Ｂ」）を有する障害対処ルールを作成する。図１０（ｃ）では、この障害対処ルールを、障害対処ルール６１５ｂとして示している。
【０１１３】
以上の処理の後、共通条件制御手段７は、図１０（ｃ）に示す各ルールを障害対処ルールとしてルール蓄積手段２に記憶させる。
【０１１４】
第２の実施の形態によれば、共通条件制御手段７が、ユーザ指定ルールの矛盾を解消した後、ステップＳ２２４（より具体的には図９に示すステップＳ３２１〜Ｓ３２３）の処理を行う。従って、ユーザが作成したユーザ指定ルールが規定するタイミングで準備コマンドを実行して対処コマンドの実行の遅れを緩和することができる。
【０１１５】
次に、第２の実施の形態の変形例について説明する。図８（ｃ）に示すような障害対処ルールを作成した場合、状態Ａ，Ｂ，Ｃを全て検知した場合には、「準備Ａ」を実行し、「準備Ｂ、対処Ｂ」も実行することになる。この場合、「準備Ａ」と「準備Ｂ」の実行が何らかの競合を引き起こし、サービス実行手段１０に好ましくない動作を行わせる場合が発生する場合もある。また、図８（ｂ）に例示するユーザ指定ルール（ステップＳ２２３後のユーザ指定ルール）を障害対処ルールとして使用した場合であっても、「対処Ａ」の遅れが問題にならない場合もある。そこで、まず、ステップＳ２２３の矛盾解消処理の結果得られるユーザ指定ルールを障害対処ルールとしてルール蓄積手段２に記憶させてもよい。そして、ステップＳ２２３の矛盾解消処理において条件式に変更を加えたルールにおける対処コマンドの実行に失敗したときに、復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールの作成等（図７に示すステップＳ２２４に相当する処理）を実行してもよい。
【０１１６】
図１１は、上記の変形例におけるマネージャ装置３０（主に共通条件制御手段７）による処理経過の例を示すフローチャートである。図７に示す処理と同様の処理に関しては、図７と同様の符号を付して、詳細な説明を省略する。本変形例では、図１１に示すように、矛盾解消処理（ステップＳ２２３）の結果得られるユーザ指定ルールを障害対処ルールとして記憶する（ステップＳ２２５）。すなわち、ステップＳ２２５では、図８（ｂ）や図１０（ｂ）に例示するルールを障害対処ルールとしてルール蓄積手段に蓄積する。
【０１１７】
その後、矛盾解消処理（ステップＳ２２３）において条件式が変更されたルールにおける準備コマンドおよび対処コマンドを、対処方法検索手段３が検索し、対話制御手段４がその準備コマンドおよび対処コマンドの情報をコマンド実行手段５に送信して、その準備コマンドおよび対処コマンドが実行されたとする。動作状態検出手段１は、対処コマンド実行後の動作状態を検出して、その動作状態の情報を対処方法検索手段３に送信する。対処方法検索手段３は、その動作状態の情報と、各障害対処ルールの条件式とを照合して、障害が発生している状態か否かを判定する。障害が発生している状態であれば、対処コマンドの実行が遅れ、対処コマンドの実行に失敗したことになる。障害が発生していなければ、対処コマンドの実行タイミングが、ユーザ自身が作成したユーザ指定ルールにおいて規定されているタイミングより遅れても、対処コマンドの実行に成功したことになる。対処方法検索手段３は、このように、対処コマンドの実行に成功したか否かを判定する（ステップＳ２２６）。ステップＳ２２６で、対処コマンドの実行に成功したと判定した場合には、ステップＳ２２１に移行し、ステップＳ２２１以降の処理を繰り返せばよい。
【０１１８】
一方、ステップＳ２２６で、対処コマンドの実行に失敗したとする（ステップＳ２２６におけるＮｏ）。この場合、共通条件制御手段７は、ステップＳ２２７の処理として以下の処理を実行する。共通条件制御手段７は、ルール蓄積手段２に記憶させた障害対処ルールのうち、ステップＳ２２３の矛盾解消処理において条件式に変更が加えられていたルールから、準備コマンドの情報を削除する。例えば、ステップＳ２２３，Ｓ２２５の処理の結果、図８（ｂ）に示す各ルール６０１ａ，６０２ａが障害対処ルールとしてルール蓄積手段２に記憶されていたとする。この例では、ステップＳ２２３の矛盾解消処理において条件式に変更が加えられていたルールは、ルール６０１ａである。従って、共通条件制御手段７は、障害対処ルールとしてルール蓄積手段２に記憶されたルール６０１から準備コマンドの情報である「準備Ａ」を削除し、図８（ｃ）に示すルール６０１ｂになるように障害対処ルールを書き換える。
【０１１９】
また、復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールを作成し、その障害対処ルールをルール蓄積手段２に追加記憶させる。この障害対処ルール作成処理は、図９に示すステップＳ３２２，３２３と同様に行えばよい。すなわち、共通条件制御手段７は、ステップＳ２２３の処理において条件式が変更されたユーザ指定ルールにおける元の（変更前の）ユーザ指定ルールを抽出する。そして、共通条件制御手段７は、その抽出したユーザ指定ルールの条件式と同一の条件式を有し、復旧処理コマンドの情報として、抽出したユーザ指定ルールに含まれる準備コマンドの情報を有する障害対処ルールを作成すればよい。以上の処理を、ステップＳ２２７の処理として行い、その後ステップＳ２２１に移行する。
【０１２０】
以上のような変形例によれば、準備コマンド同士の競合により、サービス実行手段１０に好ましくない動作を行わせることを防止できる。
【０１２１】
また、第２の実施の形態の他の変形例は、図９に示す処理において、ステップＳ３２３の後、競合する準備コマンドが同時に実行されることがある場合に、準備コマンドの前に、競合する準備コマンドの実行を取り消す取消コマンドの情報を付加する形態である。なお、準備コマンドの実行を取り消すとは、その準備コマンド実行前の状態に戻すことである。
【０１２２】
図１２は、本変形例におけるステップＳ２２４の処理（復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールの作成や、対処コマンドのみを含むようにユーザ指定ルールを変更する処理）の処理経過の一例を示す説明図である。図９に示す処理と同様の処理については、図９と同一の符号を付して説明を省略する。
【０１２３】
ステップＳ３２３の後、共通条件制御手段７は、ステップＳ３２３によって得られた各ルールのうち、準備コマンドが競合するルールが存在するか否かを判定する（ステップＳ３２４）。ステップＳ３２４において、共通条件制御手段７は、まず、準備コマンドの情報を含むルールであって、同時に成立し得るルールを選択する。ここで同時に成立し得ることは、あるルールの条件式では「状態Ｐになっていること」が条件として記述され、他のルールの条件式では「状態Ｐになっていないこと」が条件として記述されていることに基づいて判定すればよい（状態Ｐは、任意の障害発生状態）。そして、共通条件制御手段７は、選択した各ルールの準備コマンドが競合するか否かを判定すればよい。なお、競合する準備コマンドの情報は、例えば、マネージャ装置が備える記憶装置（図示せず。）に予め記憶させておけばよい。
【０１２４】
準備コマンドの情報を含むルールであって、同時に成立し得るルールを選択し、そのルールの準備コマンドが競合するものでなければ（ステップＳ３２４におけるＮｏ）、処理を終了する。
【０１２５】
準備コマンドが競合する場合（ステップＳ３２４におけるＹｅｓ）、共通条件制御手段７は、準備コマンドが競合するルールに、準備コマンドの実行を取り消す取消コマンドの情報を追加する（ステップＳ３２５）。具体的には、共通条件制御手段７は、対処コマンドの情報を含むルールの準備コマンドの情報の前に、その準備コマンドと競合する準備コマンドの取消コマンドの情報を追加する。その後、共通条件制御手段７は、以上の処理の結果得られるルールを障害対処ルールとしてルール蓄積手段２に記憶させる（図７に示すステップＳ２２５）。なお、共通部分を有するユーザ指定ルールのグループが複数存在した場合、それらの各グループについて、図１２に示すステップＳ３２１以降の処理を行えばよい。そして、各グループについて、ステップＳ３２１以降の処理が終了した後、ステップＳ２２５に移行すればよい。
【０１２６】
例えば、ステップＳ３２３の結果、図８（ｃ）に示すルール６０１ｂ，６０２ｂ，６０３ｂが生成されていたとする。ステップＳ３２３の後、共通条件制御手段７は、準備コマンドの情報を含むルールであって、同時に成立し得るルールを選択する。本例では、共通条件制御手段７は、図８（ｃ）に示すルール６０２ｂ，６０３ｂを選択する。そして、共通条件制御手段７は、選択したルールの準備コマンドが競合するか否かを判定する（ステップＳ３２４）。ここでは、ルール６０２ｂにおける「準備Ｂ」とルール６０３ｂにおける「準備Ａ」とが競合するか否かを判定する。
【０１２７】
「準備Ｂ」と「準備Ａ」とが競合しなければ、処理を終了する。「準備Ｂ」と「準備Ａ」とが競合する場合には、共通条件制御手段７は、対処コマンドの情報を含むルール６０２ｂの準備コマンド「準備Ｂ」の情報の前に、その準備コマンドと競合する準備コマンド「準備Ａ」の取消コマンド「取消Ａ」の情報を追加する。この結果得られるルール群の例を図１３に示す。対処コマンドの情報を含むルール６０２ｂの準備コマンドの前に取消コマンド「取消Ａ」を追加したルールを、図１３では、ルール６０２ｃとして示している。
【０１２８】
なお、図１１に示すステップＳ２２７において、図１２に示すステップＳ３２１〜Ｓ３２５の処理を実行してもよい。
【０１２９】
また、図７に示すフローチャートでは、ステップＳ２２２においてＹｅｓと判定した場合、矛盾解消処理（ステップＳ２２３）を実行する。第２の実施の形態の他の変形例として、共通条件制御手段７が、ステップＳ２２２においてＹｅｓと判定した場合、条件式に共通部分を有する各ユーザ指定ルールを、準備コマンドの情報を有するユーザ指定ルールと、対処コマンドの情報を有するユーザ指定ルールに分離し、その後、ステップＳ２２３の処理を実行し、ステップＳ２２５に移行してもよい。
【０１３０】
本変形例では、ステップＳ２２２においてＹｅｓと判定した場合、共通条件制御手段７は、例えば、図８（ａ）に例示するユーザ指定ルール６０１を、条件式が“状態Ａ ＆ 状態Ｂ”であり、「準備Ａ」の情報を含むルールと、条件式が“状態Ａ ＆ 状態Ｂ”であり、「準備Ｂ」の情報を含むルールとに分離する。同様に、図８（ａ）に例示するユーザ指定ルール６０２についても分離する。そして、ステップＳ２２３の処理を実行し、ステップＳ２２５に移行する。
【０１３１】
実施の形態３．
図１４は、本発明の第３の実施の形態を示すブロック図である。第１の実施の形態や第２の実施の形態と同様の構成部については、図１と同一の符号を付し、説明を省略する。ただし、第２の実施の形態では、共通条件制御手段７は、第２の実施の形態における動作に加え、さらに他の動作も行う。また、本実施の形態では、エージェント装置２０は、検出要素制御手段８を備える。
【０１３２】
本実施の形態では、第２の実施の形態と同様に、ユーザ自身が作成したユーザ指定ルールにおける復旧処理コマンドの情報には、対処コマンドおよび準備コマンドの両方の情報が含まれる。また、ユーザ指定ルールに基づいて作成される復旧処理コマンドには、準備コマンドや対処コマンドの他に、検出コマンドが含まれる場合がある。検出コマンドは、サービス実行手段１０の動作状態の検出を動作状態検出手段１に変更させるためのコマンドである。例えば、動作状態検出手段１が、サービス実行手段１０に「状態Ｃ」が発生しているか否かを検出していないとする。この場合、検出要素制御手段８が、検出コマンド（ここでは「検出Ｃ」とする。）を受け取ると、検出要素制御手段８が動作状態検出手段１に対し「状態Ｃ」が発生しているか否かの検出を指示する。動作状態検出手段１は、この指示に応じて「状態Ｃ」が発生しているか否かの検出を開始し、その検出結果を対処方法検索手段３に出力する。
【０１３３】
共通条件制御手段７は、複数のユーザ指定ルールの条件式の共通部分を条件式とし、その複数のユーザ指定ルールの共通部分以外に記述された状態が発生しているか否かを検出するための検出コマンドの情報を含む障害対処ルールを作成する。
【０１３４】
また、共通条件制御手段７は、第１の実施の形態や第２の実施の形態と同様に、ユーザ指定ルールの矛盾を解消して、ユーザ指定ルールが一意に識別されるようにする処理（図４に示すステップＳ３０１〜Ｓ３０８の処理）を実行する。ただし、共通条件制御手段７は、対処コマンドの情報を含むユーザ指定ルールを対象として、上記の矛盾解消処理を行う。従って、検出コマンドの情報を含んでいるが対処コマンドの情報を含んでいないルール等は、矛盾解消処理の対象外となる。
【０１３５】
また、共通条件制御手段７は、第２の実施の形態におけるステップＳ２２４（より具体的には図９に示すステップＳ３２１〜Ｓ３２３）と同様の処理を行い、ユーザ指定ルールから準備コマンドを削除したり、準備コマンドを含む新たな障害対処ルールを作成したりする。
【０１３６】
また、共通条件制御手段７は、導出した各ルールを障害対処ルールとしてルール蓄積手段２に記憶させる前に、条件式が同一であるルールを１つにまとめる処理を行う。
【０１３７】
対処方法検索手段３が、検出コマンドの情報を対話制御手段４に出力し、対話制御手段４もその検出コマンドの情報をコマンド実行手段５に出力したとする。コマンド実行手段５は、検出コマンドの情報を受信した場合には、その情報が示す検出コマンドを検出要素制御手段８に出力する。検出要素制御手段８は、コマンド実行手段５から検出コマンドを受け取ると、その検出コマンドに応じて、動作状態検出手段１に検出する動作を変更させる。例えば、動作状態検出手段１に新たな動作状態の検出を行わせる。
【０１３８】
検出要素制御手段８は、例えば、動作状態検出手段１等と同様に、コンピュータと障害復旧プログラムによって実現することができる。また、検出要素制御手段８をハードウェア装置によって実現してもよい。
【０１３９】
以下、第３の実施の形態の動作について説明する。図１５は、ユーザ指定ルールが修正されたときにおけるマネージャ装置３０（主に共通条件制御手段７）による処理経過の例を示すフローチャートである。図７に示す処理と同様の処理については、図７と同様の符号を付して説明を省略する。
【０１４０】
ステップＳ２２２において、条件式に共通部分を有するユーザ指定ルールがあると判定した場合（ステップＳ２２２におけるＹｅｓ）、共通条件制御手段７は、共通部分を条件式とし、検出コマンドを含む障害対処ルールを作成する（ステップＳ２２２ａ）。図１６は、この検出コマンドを含む障害対処ルール作成処理（ステップＳ２２２ａ）の処理経過の例を示すフローチャートである。共通条件制御手段７は、検出コマンドを含む障害対処ルールを作成する際、まず、ユーザ指定ルール蓄積手段６が記憶するユーザ指定ルールのうち、条件式に共通部分を有するユーザ指定ルールを収集する（ステップＳ３４１）。次に、共通条件制御手段７は、収集したユーザ指定ルールの条件式の共通部分を条件式とし、その各ユーザ指定ルールの条件式の共通部分以外に記述された状態が発生しているか否かを検出するための検出コマンドの情報を含む障害対処ルールを作成する（ステップＳ３４２）。以上の処理によって、ステップＳ２２２ａの処理を終了する。なお、共通部分を有するユーザ指定ルールのグループが複数存在した場合、それらの各グループについて、ステップＳ３４２の処理を実行すればよい。
【０１４１】
ステップＳ２２２ａの後、共通条件制御手段７は、各ユーザ指定ルール間に矛盾がなくなるように、収集したユーザ指定ルールの条件式を変更する（ステップＳ２２３）。この処理は、第２の実施の形態におけるステップＳ２２３（図７参照。）と同様である。すなわち、図４に示すステップＳ３０１〜Ｓ３０８と同様の処理を実行すればよい。ただし、ユーザ指定ルールの収集処理（図４に示すステップＳ３０２）に相当する処理は、図１６に示すステップＳ３４１で実行しているので、ステップＳ３０２の処理は省略してよい。また、本実施の形態では、共通条件制御手段７は、条件式に共通部分を有するユーザ指定ルールであって、対処コマンドの情報を含むユーザ指定ルールを対象として、ステップＳ２２３の矛盾解消処理を行う。上記のステップＳ２２２ａで作成されたルールには、対処コマンドの情報は含まれないので、ステップＳ２２２ａで作成されたルールの条件式が、ステップＳ２２３で変更されることはない。
【０１４２】
ステップＳ２２３の後、共通条件制御手段７は、復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールの作成や、対処コマンドのみを含むようにユーザ指定ルールを変更する処理を実行する（ステップＳ２２４）。この処理は、第２の実施の形態におけるステップＳ２２４（図７参照。）と同様である。すなわち、図９に示すステップＳ３２１〜Ｓ３２３と同様の処理を実行すればよい。ただし、共通条件制御手段７は、ステップＳ２２２ａで作成した検出コマンドの情報を含む障害対処ルールに対しては、何ら処理を行わない。従って、ステップＳ２２２ａで作成されたルールの条件式が、ステップＳ２２４で変更されることはない。
【０１４３】
続いて、共通条件制御手段７は、ステップＳ２２４の結果得られた各ルールと、ステップＳ２２２ａで作成した障害対処ルールのうち、条件式が同一のものがあれば、そのルールを１つのルールにまとめる（ステップＳ２２４ａ）。例えば、条件式が“状態Ａ ＆ 状態Ｂ”であり、「検出Ｃ」という検出コマンドの情報を含むルールと、条件式が“状態Ａ ＆ 状態Ｂ”であり、「準備Ａ」という準備コマンドの情報を含むルールとが存在したとする。この場合、共通条件制御手段７は、この２つのルールをまとめて、条件式が“状態Ａ ＆ 状態Ｂ”であり、「検出Ｃ、準備Ａ」を含むルールを作成する。
【０１４４】
ステップＳ２２４ａにおいてまとめられるルールをまとめた後、各ルールを、障害対処ルールとしてルール蓄積手段２に記憶させる（ステップＳ２２５）。なお、このとき、条件式に他のユーザ指定ルールとの共通部分がないユーザ指定ルールが存在していた場合、共通条件制御手段７は、そのユーザ指定ルールについては、そのまま障害対処ルールとしてルール蓄積手段２に記憶させる。
【０１４５】
図１７および図１８を用いて、以上の処理を説明する。図１７および図１８は、ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。ユーザ指定ルール蓄積手段６は、初期状態において、図１７（ａ）に示すユーザ指定ルールを記憶しているとする。そして、ステップＳ２２１において、対話制御手段４が、ユーザの操作に応じて、図１７（ｂ）に示すユーザ指定ルール７０２を追加したとする。すると、ステップＳ２２２ａにおいて、共通条件制御手段７は、ユーザ指定ルール７０１，７０２を収集する。そして、共通条件制御手段７は、その２つのユーザ指定ルール７０１，７０２の条件式の共通部分である“状態Ａ ＆ 状態Ｂ”を条件式とし、ユーザ指定ルール７０１，７０２の条件式の共通部分以外に記述された状態（本例では状態Ｃ）が発生しているか否かを検出するための検出コマンド（「検出Ｃ」とする。）の情報を含む障害対処ルールを作成する。図１７（ｃ）では、このルールを障害対処ルール７５１として示している。
【０１４６】
次のステップＳ２２３では、共通条件制御手段７は、図１７（ｃ）に示すユーザ指定ルール７０１，７０２に基づいて、図１８（ａ）に示すユーザ指定ルール７０１ａ，７０２ａを導出する。この導出過程は、図８（ａ）に示すユーザ指定ルールから図８（ｂ）に示すユーザ指定ルールを導出する過程と同様である。なお、障害対処ルール７５１には対処コマンドの情報が含まれないので、ステップＳ２２３の処理対象とされない。
【０１４７】
次のステップＳ２２４では、共通条件制御手段７は、図１８（ａ）に示すユーザ指定ルール７０１ａ，７０２ａに基づいて、図１８（ｂ）に示すルール７０１ｂ，７０２ｂ，７０３ｂを導出する。この導出過程は、図８（ｂ）に示すユーザ指定ルールから、図８（ｃ）に示す各ルールを導出する過程と同様である。なお、ステップＳ２２４において、共通条件制御手段７は、検出コマンドの情報を含む障害対処ルール７５１に対しては、何ら処理を行わない。
【０１４８】
次の、ステップＳ２２４ａでは、共通条件制御手段７は、ステップＳ２２４で得られた各ルール７０１ｂ，７０２ｂ，７０３ｂと、ステップＳ２２２ａで作成した障害対処ルール７５１のうち、条件式が同一のものがあれば、そのルールを１つにまとめる。本例では、図１８（ｂ）に示す障害対処ルール７５１，７０３ｂの条件式が同一であるので、この２つのルールをまとめ、図１８（ｃ）に示す障害対処ルール７５２を生成する。その後、共通条件制御手段７は、図１８（ｃ）に示す各ルールを障害対処ルールとして、ルール蓄積手段２に記憶させる。
【０１４９】
他の具体例について説明する。図１９および図２０も、ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。ステップＳ２２１の後、ユーザ指定ルール蓄積手段６に、図１９（ａ）に示すユーザ指定ルール８０１，８０２が記憶されているとする。すると、ステップＳ２２２ａにおいて、共通条件制御手段７は、ユーザ指定ルール８０１，８０２を収集する。そして、共通条件制御手段７は、その２つのユーザ指定ルール８０１，８０２の条件式の共通部分である“状態Ａ ＆ 状態Ｂ”を条件式とし、ユーザ指定ルール８０１，８０２の条件式の共通部分以外に記述された状態（本例では状態Ｃ、状態Ｄ）が発生しているか否かを検出するための各検出コマンドの情報を含む障害対処ルールを作成する。ここでは、状態Ｃが発生しているか否かを検出するための検出コマンドを「検出Ｃ」、状態Ｄが発生しているか否かを検出するための検出コマンドを「検出Ｄ」とする。図１９（ｂ）では、このルールを障害対処ルール８５１として示している。
【０１５０】
次のステップＳ２２３では、共通条件制御手段７は、図１９（ｂ）に示すユーザ指定ルール８０１，８０２に基づいて、図２０（ａ）に示すユーザ指定ルール８０１ａ，８０２ａを導出する。なお、障害対処ルール８５１には対処コマンドの情報が含まれないので、ステップＳ２２３の処理対象とされない。
【０１５１】
次のステップＳ２２４では、共通条件制御手段７は、図２０（ａ）に示すユーザ指定ルール８０１ａ，８０２ａに基づいて、図２０（ｂ）に示すルール８０１ｂ，８０２ｂ，８０３ｂを導出する。なお、ステップＳ２２４において、共通条件制御手段７は、検出コマンドの情報を含む障害対処ルール７５１に対しては、何ら処理を行わない。
【０１５２】
ステップＳ２２４ａでは、共通条件制御手段７は、ステップＳ２２４で得られた各ルール８０１ｂ，８０２ｂ，８０３ｂと、ステップＳ２２２ａで作成した障害対処ルール８５１のうち、条件式が同一のものがあれば、そのルールを１つにまとめる。本例では、条件式が同一となるものがないので、ルールをまとめることはない。続いて、共通条件制御手段７は、図２０（ｂ）に示す各ルールを障害対処ルールとして、ルール蓄積手段２に記憶させる。
【０１５３】
なお、図１７に示す具体例では、初期状態として“状態Ａ ＆ 状態Ｂ”を条件式とするユーザ指定ルール７０１が記憶され、続いて、その条件式“状態Ａ ＆ 状態Ｂ”を包含する条件式“状態Ａ ＆ 状態Ｂ ＆ 状態Ｃ”を有するユーザ指定ルール７０２が追加された場合を示している。一方、図１９（ａ）に示すユーザ指定ルール８０１，８０２では、一方の条件式が他方の条件式を包含しているわけではない。
【０１５４】
既に記憶されているユーザ指定ルールの条件式を包含する条件式を有するユーザ指定ルールを追加した場合、元々記憶されていたユーザ指定ルールの条件式全体が、条件式の共通部分となる。例えば、図１７に示す例では、元々記憶されていたユーザ指定ルール７０１の条件式全体（“状態Ａ ＆ 状態Ｂ”）が、追加されたユーザ指定ルール７０２の条件式との共通部分になっている。
【０１５５】
ユーザ（管理者）が、新たにユーザ指定ルールを追加する場合、既にユーザ指定ルール蓄積手段６に記憶されているユーザ指定ルールの条件式を包含する条件式を有するユーザ指定ルールを追加することが多いと考えられる。従って、元々記憶されていたユーザ指定ルールの条件式全体が、条件式の共通部分となることが多いと考えられる。
【０１５６】
あるユーザ指定ルールの条件式全体が、複数のユーザ指定ルールの条件式の共通部分となる場合、図１５に示すステップＳ２２２ａにおいて、以下のような処理を行ってもよい。共通条件制御手段７は、ユーザ指定ルール蓄積手段６が記憶するユーザ指定ルールのうち、条件式に共通部分を有するユーザ指定ルールを収集する。このユーザ指定ルールの中には、条件式全体が、各ユーザ指定ルールの条件式の共通部分となっているユーザ指定ルールが存在する。このユーザ指定ルールをＫとし、ユーザ指定ルールＫの条件式をＪとする。Ｊは、条件式の共通部分でもある。共通条件制御手段７は、Ｊを条件式とし、各ユーザ指定ルールの条件式のうちＪ以外の部分に記述された状態が発生しているか否かを検出するための検出コマンドの情報を含む障害対処ルールを作成する。さらに、共通条件制御手段７は、作成した障害対処ルールに対し、ユーザ指定ルールＫに含まれる準備コマンドの情報も付加する。この結果、検出コマンドおよび準備コマンドの情報を有する障害対処ルールが作成される。また、共通条件制御手段７は、ユーザ指定ルールＫから準備コマンドの情報を削除する。共通条件制御手段７は、以上の処理をステップＳ２２２ａとして行う。
【０１５７】
この後、ステップＳ２２３に移行するが、ステップＳ２２３終了後は、ステップＳ２２４，Ｓ２２４ａの処理を行わずに、ステップＳ２２５に移行する。
【０１５８】
図２１を用いて、以上の処理の具体例を説明する。図２１は、ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。ユーザ指定ルール蓄積手段６は、初期状態において、図２１（ａ）に示すユーザ指定ルール９０１を記憶していて、その後、図２１（ａ）に示すユーザ指定ルール９０２が追加記憶されたとする。本例では、ユーザ指定ルール９０１の条件式全体が、複数のユーザ指定ルール９０１，９０２の条件式の共通部分となる。従って、ユーザ指定ルール９０１が、上記の説明におけるユーザ指定ルールＫとなり、その条件式“状態Ａ ＆ 状態Ｂ”が上記の説明におけるＪに相当する。
【０１５９】
共通条件制御手段７は、ステップＳ２２２ａにおいて、図２１（ａ）に示すユーザ指定ルール９０１，９０２を収集する。そして、共通条件制御手段７は、ユーザ指定ルール９０１の条件式Ｊ（すなわち、“状態Ａ ＆ 状態Ｂ”）を条件式とし、各各ユーザ指定ルールの条件式のうちＪ以外の部分に記述された状態（本例では状態Ｃ）が発生しているか否かを検出するための検出コマンド（「検出Ｃ」とする。）の情報を含む障害対処ルールを作成する。さらに、共通条件制御手段７は、ユーザ指定ルール９０１に含まれる準備コマンドの情報（準備Ａ）を、その障害対処ルールに付加する。この結果得られるルールを、図２１（ｂ）において障害対処ルール９５１として示している。
【０１６０】
また、共通条件制御手段７は、ユーザ指定ルール９０１（ユーザ指定ルールＫ）から準備コマンドの情報を削除する。この結果得られるルールを、図２１（ｂ）において障害対処ルール９０１ａとして示している。図２１（ｂ）は、ステップＳ２２２ａ終了後の各ルールの状態を示している。なお、図２１（ｂ）に示すユーザ指定ルール９０２ａは、図２１（ａ）に示すユーザ指定ルール９０１と同一である。
【０１６１】
次のステップＳ２２３では、共通条件制御手段７は、図２１（ｂ）に示すユーザ指定ルール９０１ａ，９０２ａに基づいて、図２１（ｃ）に示すユーザ指定ルール９０１ｂ，９０２ｂを導出する。なお、障害対処ルール９５１には対処コマンドの情報が含まれないので、ステップＳ２２３の処理対象とされない。
【０１６２】
本例では、ステップＳ２２４，Ｓ２２４ａの処理を行わない。よって、ステップＳ２２３の結果得られた各ルール（図２１（ｃ）参照。）を障害対処ルールとしてルール蓄積手段２に記憶させる。
【０１６３】
次に、本実施の形態における障害復旧動作の例について説明する。本実施の形態における障害復旧動作は、図６に示す動作と同様である。ただし、ステップＳ２０３において、復旧処理コマンドを実行する旨が入力され、対話制御手段４は、その復旧処理コマンドの情報をコマンド実行手段５に送信するときに、復旧処理コマンドの情報として検出コマンドの情報が含まれていたとする。この場合、対話制御手段４は、検出コマンドを含む復旧処理コマンドの情報を送信し、コマンド実行手段５は、その情報を受信する。コマンド実行手段５は、受信した情報が示す復旧処理コマンドのうち、準備コマンド、対処コマンドについては、第１の実施の形態と同様に、サービス実行手段１０上でそれらのコマンドを実行する（ステップＳ２０４）。ただし、コマンド実行手段５は、検出コマンドについては、ステップＳ２０４で検出要素制御手段８に出力する。
【０１６４】
検出要素制御手段８は、コマンド実行手段５が出力する検出コマンドに応じて、動作状態検出手段１に動作状態検出手段１に検出する動作状態を変更させる。すると、動作状態検出手段１は、新たにサービス実行手段１０の動作状態を検出し、その動作状態の情報を対処方法検索手段３に送信する（ステップＳ２０１）。以降、同様の動作を繰り返す。
【０１６５】
以下に、具体例を示す。図２１（ｃ）に示すルール９０１ｂ，９０２ｂ，９５１が障害対処ルールとして、ルール蓄積手段２に記憶されているものとする。
【０１６６】
動作状態検出手段１は、サービス実行手段１０の動作状態として「状態Ａかつ状態Ｂ」を検出すると、その動作状態の情報を対処方法検索手段３に送信する（ステップＳ２０１）。対処方法検索手段３は、その動作状態の情報を受信し、ルール蓄積手段２に蓄積されている各障害対処ルールの中に、条件式が満たされている障害対処ルールがあるか否かを判定する（ステップＳ２０２）。本例では、図２１（ｃ）に示す障害対処ルール９５１の条件式が満たされる（ステップＳ２０２におけるＹｅｓ）。そこで、対処方法検索手段３は、障害対処ルール９５１に含まれる「検出Ｃ、準備Ａ」という復旧処理コマンドの情報を、対話制御手段４に出力する。対話制御手段４は、「検出Ｃ、準備Ａ」を実行する旨の指示をユーザから受けると（ステップＳ２０３におけるＹｅｓ）、「検出Ｃ、準備Ａ」という情報をコマンド実行手段５に送信する。コマンド実行手段５は、サービス実行手段１０上で「準備Ａ」を実行するとともに、検出コマンドである「検出Ｃ」を検出要素制御手段８に出力する（ステップ２０４）。
【０１６７】
検出要素制御手段８は、この検出コマンド「検出Ｃ」を受け取り、動作状態検出手段１に状態検出方法の変更を指示する。本例では、「検出Ｃ」を受け取った場合は、動作状態検出手段１に対して、新たに「状態Ｃ」が発生しているか否かを検出するようにに指示するものとする。動作状態検出手段１は、この指示に応じて「状態Ｃ」が生じているか否かの検出を開始し、その検出結果を対処方法検索手段３に送信する（ステップ２０１）。このとき、対処方法検索手段３は、既に「状態Ａかつ状態Ｂ」が生じていることを認識している。従って、「状態Ｃ」の真偽によって、対処方法検索手段３は、図２１（ｃ）に示す障害対処ルール９０１ｂ，９０２ｂのいずれの条件式が満たされているかを判定する（ステップＳ２０２）。そして、条件式が満たされている方の障害対処ルールに含まれる復旧処理コマンドの情報（「対処Ａ」または「準備Ｂ、対処Ｂ」）を出力する。対話制御手段４は、その復旧処理コマンドを実行するか否かの決定をユーザに促し、復旧処理コマンドを実行する旨の指示を受けたならば（ステップＳ２０３におけるＹｅｓ）、復旧処理コマンドの情報をコマンド実行手段５に送信する。コマンド実行手段５は、受信した情報が示す復旧処理コマンド（ここでは「対処Ａ」または「準備Ｂ、対処Ｂ」）をサービス実行手段１０上で実行する（ステップＳ２０４）。
【０１６８】
このように本実施の形態によれば、第１、第２の実施の形態で説明した条件式の修正に加えて、動作状態検出手段１が検出対象とする動作状態を変更することができる。例えば、図２１に示すユーザ指定ルール９０２が追加される前では、動作状態検出手段１は、「状態Ａ」が生じているか否かおよび「状態Ｂ」が生じているか否かを検出していればよかった。新たに図２１に示すユーザ指定ルール９０２の追加に伴い、仮に障害対処ルール９０１ｂ，９０２ｂだけがルール蓄積手段２に追加されると、「状態Ｃ」が発生しているか否かについても検出しなければならないため、エージェント装置２０の処理負荷が大きくなる。このように、障害対処ルールの数が増加すると、検出すべき要素の種類も増加し、障害復旧システムの処理負荷が大きくなり、その結果、サービス実行手段１０の効率低下を引き起こす場合がある。本実施の形態では、共通条件制御手段７が、ユーザ指定ルールの条件式の共通部分を条件式とし、その各ユーザ指定ルールの条件式の共通部分以外に記述された状態が発生しているか否かを検出するための検出コマンドの情報を含む障害対処ルールを作成する。従って、常時監視する動作状態は、条件式の共通部分に記述された動作状態のみとすることができる。そして、各条件式の共通部分に相当する条件が満たされたときに、対処方法検索手段３が、各条件式の共通部分を条件式とする障害対処ルールに含まれる検出コマンドの情報を出力し、その検出コマンドに応じた動作状態の検出が開始される。このように、常時監視する動作状態を、条件式の共通部分に記述された動作状態のみとすることができるので、障害復旧システム（特にエージェント装置２０）の監視負荷を大幅に低減することができる。
【０１６９】
また、上記の第３の実施の形態の説明では、ステップＳ２０２（図６参照。）において、対処方法検索手段３が、ルール蓄積手段２に蓄積されている各障害対処ルールの中に、条件式が満たされている障害対処ルールがあるか否かを判定するものとして説明した。対処方法検索手段３は、条件式が満たされているか否かを判定する際、ルール蓄積手段２に記憶されている障害対処ルールの一部を判定の対象外とし、条件式が満たされた障害対処ルールが生じたときに、条件式が満たされているか否かの判定対象となる障害対処ルールを増加していってもよい。具体的には、対処方法検索手段３は、検出コマンドの情報が復旧処理コマンドの情報として含まれている障害対処ルールが存在する場合、その検出コマンドによって検出が開始される動作状態を条件式に含む障害対処ルールを、条件式が満たされているか否かの判定対象から外していてもよい。そして、検出コマンドの情報が復旧処理コマンドの情報として含まれている障害対処ルールの条件式が満たされた後、その検出コマンドによって検出が開始される動作状態を条件式に含む障害対処ルールを、条件式が満たされているか否かの判定対象に含めてもよい。
【０１７０】
例えば、図２１（ｃ）に示す３つの障害対処ルール９０１ｂ，９０２ｂ，９５１が、ルール蓄積手段２に記憶されているとする。この場合、検出コマンドの情報「検出Ｃ」が含まれている障害対処ルール９５１が存在する。従って、対処方法検索手段３は、当初、「検出Ｃ」によって検出が開始される動作状態（本例では、“状態Ｃ”、“ＮＯＴ状態Ｃ”）を条件式に含む障害対処ルール９０１ｂ，９０２ｂを、条件式が満たされているか否かの判定対象から外していてもよい。このとき、対処方法検索手段３は、図２１（ｃ）に示す全ての障害対処ルールについて、条件式が満たされているか否かを判定する必要がないので、対処方法検索手段３の処理負荷は軽減される。
【０１７１】
その後、「検出Ｃ」という情報を含む障害対処ルール９５１の条件式が満たされた後、対処方法検索手段３は、その検出コマンドによって検出が開始される動作状態（“状態Ｃ”、“ＮＯＴ状態Ｃ”）を条件式に含む障害対処ルール９０１ｂ，９０２ｂを、条件式が満たされているか否かの判定対象に含める。
【０１７２】
このように、条件式が満たされているか否かの判定対象外となる障害対処ルールを定めておき、条件式が満たされた障害対処ルールが生じたときに、条件式が満たされているか否かの判定対象となる障害対処ルールを増加させることにより、当初は、条件式が満たされているか否かの判定対象となる障害対処ルールの数を抑えることができ、対処方法検索手段３の処理負荷を抑えることができる。
【０１７３】
また、上記の説明では、コマンド実行手段５が検出コマンドの情報を受信して検出要素制御手段８に対して検出コマンドを出力することにより、検出要素制御手段８が、動作状態検出手段１に、検出コマンドに応じた動作状態が発生しているか否かの検出開始を指示する場合を示した。すなわち、検出コマンドが、その検出コマンドに応じた動作状態の検出開始のトリガとなるものとして説明した。検出コマンドの情報を含む障害対処ルールの条件式が満たされている間は、対処方法検索手段１から、対処制御手段４、コマンド実行手段５、検出要素制御手段８を介して、動作状態検出手段１に検出クエリを出力し続けてもよい。そして、動作状態検出手段１は、検出クエリが出力され続けている間、その検出クエリに応じた動作状態が発生しているか否かを検出する構成であってもよい。ただし、対話制御手段４が、検出クエリを出力しない旨の指示を受けた場合には、対話制御手段４は、検出クエリの出力を停止する。
【０１７４】
また、検出コマンドの情報の含む障害対処ルールの条件式が満たされなくなった時には、対処方法検索手段３は、その検出コマンドに応じて開始された動作状態の検出を中止させる中止コマンドの情報を出力してもよい。対話制御手段４は、他のコマンドの情報と同様に、中止コマンドの情報をコマンド実行手段に送信する。コマンド実行手段５は、中止コマンドの情報を受信した場合、その中止コマンドを検出要素制御手段８に出力する。検出要素制御手段８は、中止コマンドを受けると、その中止コマンドに対応する動作状態の検出中止を動作状態検出手段１に指示する。動作状態検出手段１は、この指示に応じて、動作状態が発生しているか否かの検出を中止する。
【０１７５】
例えば、状態Ａおよび状態Ｂが真となり、図２１（ｃ）に示す障害対処ルール９５１に基づいて、対処方法検索手段３が、「検出Ｃ、準備Ａ」という情報を出力したとする。その結果、動作状態検出手段１は、「状態Ｃ」が発生しているか否かの検出を開始する。その後、状態Ａおよび状態Ｂのいずれかが偽（発生していない状態）となり、障害対処ルール９５１の条件式が満たされなくなったとする。このとき、対処方法検索手段３は、「状態Ｃ」が発生しているか否かの検出を中止させる中止コマンドの情報を対話制御手段４に出力する。対話制御手段４は、他のコマンドの情報と同様に、この中止コマンドの情報をコマンド実行手段５に送信する。コマンド実行手段５は、この情報を受信すると、「状態Ｃ」が発生しているか否かの検出を中止させる中止コマンドを検出要素制御手段８に出力する。すると、検出要素制御手段８は、「状態Ｃ」が発生しているか否かの検出の中止を動作状態検出手段１に出力し、動作状態検出手段１は、「状態Ｃ」が発生しているか否かの検出を中止する。
【０１７６】
検出クエリを出力したり、中止コマンドを出力したりする場合であっても、第３の実施の形態と同様の効果を得ることができる。
【０１７７】
なお、上記の各実施の形態では、マネージャ装置３０とエージェント装置２０とを備える構成として説明したが、マネージャ装置３０とエージェント装置２０とを一体化した装置として、障害復旧システムを実現してもよい。
【図面の簡単な説明】
【０１７８】
【図１】本発明の第１の実施の形態を示すブロック図である。
【図２】ユーザ指定ルールが修正されたときにおけるマネージャ装置による処理経過の例を示すフローチャートである。
【図３】ユーザ指定ルールに基づく矛盾解消の具体例を示す説明図である。
【図４】ユーザ指定ルール間に矛盾がなくなるように、ユーザ指定ルールの条件式を変更することによって障害対処ルールを作成する処理の一例を示すフローチャートである。
【図５】条件式に共通部分を有するユーザ指定ルールが３つある場合における矛盾解消の具体例を示す説明図である。
【図６】サービス実行手段の状態検出から復旧処理コマンド実行までの処理経過を示すフローチャートである。
【図７】ユーザ指定ルールが修正されたときにおけるマネージャ装置による処理経過の例を示すフローチャートである。
【図８】ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。
【図９】復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールの作成や、対処コマンドのみを含むようにユーザ指定ルールを変更する処理の一例を示す説明図である。
【図１０】ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。
【図１１】第２の実施の形態の変形例におけるマネージャ装置による処理経過の例を示すフローチャートである。
【図１２】復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールの作成や、対処コマンドのみを含むようにユーザ指定ルールを変更する処理の一例を示す説明図である。
【図１３】取消コマンドが追加されたルールを含むルール群の例を示す説明図である。
【図１４】本発明の第３の実施の形態を示すブロック図である。
【図１５】ユーザ指定ルールが修正されたときにおけるマネージャ装置による処理経過の例を示すフローチャートである。
【図１６】検出コマンドを含む障害対処ルール作成の処理経過の例を示すフローチャートである。
【図１７】ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。
【図１８】ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。
【図１９】ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。
【図２０】ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。
【図２１】ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。
【図２２】管理者が障害対処ルールを追加する状況を示す説明図である。
【図２３】管理者によって変更された障害対処ルールの例を示す説明図である。
【図２４】管理者によって変更された障害対処ルールの例を示す説明図である。
【符号の説明】
【０１７９】
１ 動作状態検出手段
２ ルール蓄積手段
３ 対処方法検索手段
４ 対話制御手段
５ コマンド実行手段
６ ユーザ指定ルール蓄積手段
７ 共通条件制御手段
８ 検出要素制御手段
１０ サービス実行手段
２０ エージェント装置
３０ マネージャ装置
【技術分野】
【０００１】
本発明は、ＷＥＢサービスや業務サービスといった情報通信サービスを提供する情報処理装置等に障害が発生した場合に、その情報処理装置等を障害から復旧させるための障害復旧システム、障害復旧装置、およびその障害復旧システムに適用されるルール作成方法、障害復旧プログラムに関する。
【背景技術】
【０００２】
ＷＥＢサービスのような情報通信サービスの社会インフラストラクチャとしての重要性が高まるにつれて、そのサービスを提供する装置の安定稼動が重要となっている。従来、このような装置の運用管理は、管理者が手作業で行っていたが、装置が大規模化、複雑化するにつれて、知識および操作の面で管理者の負担が飛躍的に増大した。その結果、管理者の判断ミスや操作ミスによるサービス停止といった問題も発生している。
【０００３】
このようなミスの防止策として、障害の対処を自動化する技術が紹介されている（例えば、非特許文献１）。非特許文献１には、障害状態を検出し、自動的に障害に対する対処を行うという処理経過が記載されている。また、ｉｆ−ｔｈｅｎ形式の障害対処ルール群に従って、対処を決定することが記載されている。すなわち、障害状態を検出した場合、ｉｆ−ｔｈｅｎ形式の障害対処ルール群に従って、障害状態に応じた対処を決定し、その対処を実行することになる。また、システムが対処を実行する際に、管理者との対話を行いつつ対処を実行することも記載されている。非特許文献１に記載の技術によれば、障害発生時に、障害復旧システムが、その障害発生状態を条件として定めた障害対処ルールに基づいて対処手順を自動的に決定し、その手順を実行するので、障害発生時に迅速かつ確実に対処を行うことが可能となり、管理者によるミスを防止することが可能である。
【０００４】
【非特許文献１】加藤清志、外２名，「自律運用管理に向けたポリシー適用優先度の制御に関する一考察」，第６６回（平成１６年）全国大会講演論文集（１），社団法人 情報処理学会，２００４年３月９日発行，分冊１，ｐ．５１−５２
【発明の開示】
【発明が解決しようとする課題】
【０００５】
非特許文献１に記載された技術によって障害復旧システムが適切な障害対処を行うためには、各障害対処ルールが矛盾なく正確に記述されている必要がある。しかし、管理者にとっては、矛盾なく正確に各障害対処ルールを記載することは大きな負担である。ここで、「矛盾」とは複数の障害対処ルールが同時に成立してしまう状態を意味する。
【０００６】
以下に、管理者にかかる負担を具体的に説明する。図２２は、管理者が障害対処ルールを追加する状況を示す説明図である。図２２（ａ）に示すような障害対処ルールが、障害を復旧させるための障害復旧システムに元々記憶されていたとする。障害対処ルールは、障害が発生したと判定するための条件式と、その条件式を満足する状態を検出したときに、復旧させるべき装置（以下、復旧対象装置と記す。例えば、情報通信サービス提供装置等。）に対して実行する復旧処理コマンドの情報とを含む。条件式としては、障害が発生したとみなされる復旧対象装置の動作状態または障害発生の前兆とみなされる復旧対象装置の動作状態が記述される。復旧処理コマンドは、条件式が満たされる状態となったときに、障害からの復旧または障害の回避のための処理を制御するコマンドである。条件式を複数の状態のＡＮＤ（論理積）によって表してもよい。以下の説明では、条件式に記載される“＆”記号は、論理積を意味するものとする。すなわち、図２２（ａ）に示す障害対処ルールでは、状態Ａおよび状態Ｂが共に真ならば（換言すると、状態Ａおよび状態Ｂが共に検出されているならば）、対処手順Ａという復旧処理コマンドを実行することを表している。
【０００７】
状態Ａおよび状態Ｂが真であり（検出されており）、さらに特別な状態（ここでは状態Ｃとする。）も真であるときには、対処手順Ａとは異なる対処手順Ｂを実行させることを意図して、管理者が、図２２（ｂ）に示す２番目の障害対処ルールを追加したとする。ここで、管理者は、状態Ａおよび状態Ｂは真であるが、状態Ｃが生じていない場合には、対処手順Ａを実行し、状態Ａ，Ｂ，Ｃがいずれも真であるときには対処手順Ｂを実行することを意図している。ところが、図２２（ｂ）に示す２番目の障害対処ルールを追加した場合、障害復旧システムは、状態Ａおよび状態Ｂを検出したときには、状態Ｃが発生しているか否かによらず対処手順Ａを実行してしまうことになる。障害対処ルールを追加するときには、このような意図に反する対処手順が実行されてしまう場合があるということまで、管理者はなかなか気付きにくい。例えば、障害復旧システムが、状態Ａおよび状態Ｂを検出したときに、対処手順Ａを実行することの確認を管理者に求めたときに、状態Ｃが発生しているか否かの判定が完了していないことに管理者が気付き、そのときに初めて、元々存在していた障害対処ルール（図２２（ａ）に示すルール）も変更しなければならないということに気付く。
【０００８】
そして、元々存在していた障害対処ルールの変更の必要性に気付いた管理者は、その障害対処ルールを図２３に示す１行目の障害対処ルールに変更する。図２３に示す“ＮＯＴ”は、「・・・でないこと」を意味し、「ＮＯＴ状態Ｃ」は、状態Ｃではないことを意味する。この結果、障害復旧システムは、管理者の意図に従い、状態Ａおよび状態Ｂは真であるが、状態Ｃが生じていない場合には、対処手順Ａを実行し、状態Ａ，Ｂ，Ｃがいずれも真であるときには対処手順Ｂを実行することになる。このように、管理者は、自身の意図を反映させるために、障害対処ルール追加時に既存の障害対処ルールを確認し、矛盾がなくなるように既存の障害対処ルールに対する変更も行わなければならず、管理者にとっての負担が大きい。また、管理者が、既存の障害対処ルールに対する変更の必要性に気付かなかった場合、複数の障害対処ルールの条件式がともに成立してしまい、自身の意図に反する対処手順が実行されてしまうおそれが生じる。
【０００９】
また、追加した障害対処ルールと既存の障害対処ルールとの間に矛盾がなくなるように、管理者が既存の障害対処ルールを変更したとしても（例えば、図２３に示すように変更したとしても）、別の問題が生じる。すなわち、対処手順の実行が遅れ、対処に失敗し、障害が波及してしまい復旧が困難になってしまう場合が生じ得るという問題が発生する。新たな障害対処ルールを追加する前（図２２（ａ）参照。）であれば、障害復旧システムは、状態Ａおよび状態Ｂを検出したときに直ちに対処手順Ａを実行する。しかし、図２３の１番目および２番目に示すような障害対処ルールのもとでは、障害復旧システムは、状態Ｃが発生しているか否かを判定するまでは、図２３に示す対処手順Ａ，Ｂのいずれも実行しない。そして、状態Ｃが発生しているか否かの判定が完了するまでの間に、障害が波及してしまうおそれが生じる。このように、新たな障害対処ルールを追加する前であれば、状態Ａおよび状態Ｂの検出時に迅速に対処手順Ａを実行していたが、管理者が新たな障害対処ルールを追加して図２３に示すように障害対処ルールを変更したことにより、処理手順の実行タイミングが遅れて、対処に失敗してしまうことが生じ得る。このような場合、対処手順に、復旧や障害回避のための対処コマンドと、対処コマンド実行前に実行すべき準備コマンドとが含まれているならば、例えば、図２４に示すように、対処手順Ａに含まれている対処手順Ａ２（対処コマンド）と対処手順Ａ１（準備コマンド）とを分けて障害対処ルールを作成することが考えられる。すなわち、管理者は、状態Ａおよび状態Ｂが検出されたときに対処手順Ａ１が直ちに実行されるように、図２４に示す３番目の障害対処ルールを作成する。また、管理者は、「状態Ｃが発生していないこと（ＮＯＴ状態Ｃ）」が判定されたときに、対処手順Ａ２が実行されるように、図２３に示す１番目のルールを図２４に示す１番目のルールのように変更する。
【００１０】
この結果、比較的実行時間のかかる準備コマンド（対処手順Ａ１）が、状態Ａおよび状態Ｂの検出時に実行開始される。対処手順Ａ１の実行開始は、図２２（ａ）に示す対処手順Ａの実行タイミングと同じであり、実行タイミングの遅れを緩和することができる。ただし、この場合にも、管理者、新たな障害対処ルールを作成したり（図２４の３番目参照。）、対処コマンドのみを含むように障害対処ルールを変更したり（図２４の１番目参照。）しなければならない。そのため、管理者は、障害対処ルールの追加に伴い、障害対処ルールを新たに作成したり、障害対処ルールを変更したりしなければならず、管理者に負担がかかってしまう。また、管理者は、障害対処ルールの追加に伴い、新しい障害対処ルールを作成することによって、さらに不具合が発生するという悪循環を招くおそれもある。そのため、障害対処ルールの追加時には、管理者は、追加に伴い新たに作成する障害対処ルールの内容や、障害対処ルールの変更内容を十分に検証しなければならず、負担が大きくなってしまう。
【００１１】
復旧対象装置が大規模であるために大量の障害対処ルールが存在する場合や、随時追加修正を繰り返したことにより複雑な相関関係を持つ障害対処ルールができてしまった場合等に、以上のような管理者の負担（障害対処ルールの検証、作成、変更等の負担）は、特に大きくなる。
【００１２】
また、管理者の負担が大きいだけでなく、障害対処ルールを追加していくことにより、障害復旧システムの処理負荷も大きくなってしまうという問題がある。障害対処ルールを追加して障害対処ルールの数を増加させていくと、各障害対処ルールの条件式に記述される状態の種類も増えていく。すると、障害復旧システムが、復旧対象装置から検出しなければならない状態の種類も増えていく。例えば、図２２（ａ）に示す障害対処ルールに従って、復旧処理コマンドを決定する場合には、障害復旧システムは、状態Ｃの発生を検出する必要はなかった。しかし、状態Ｃを条件式に含む障害対処ルールが管理者によって追加されたことにより、障害復旧システムは、復旧対象装置に状態Ｃが発生しているか否かも検出しなければならなくなり、それだけ障害復旧システムの処理負荷が大きくなる。
【００１３】
また、障害復旧システムは、各障害対処ルールの条件式が満たされているか否かを判定して復旧処理コマンドを決定しているので、障害対処ルールが増加すれば、条件式が満たされているか否かの判定処理が増加する。その結果、障害復旧システムの処理負荷が大きくなる。
【００１４】
そこで、本発明は、管理者のルール作成負担やルール作成時における既存のルールの検証負担を軽減させることを目的とする。また、障害復旧システムの処理負荷を軽減することを目的とする。
【課題を解決するための手段】
【００１５】
本発明による障害復旧システムは、情報処理システムの動作状態が、予め作成されたルールの条件式を満足する場合に、条件式が満たされたルールが定める復旧処理コマンドを実行する障害復旧システムであって、障害発生または障害発生の前兆と見なされる情報処理システムの動作状態を条件式とし、復旧処理コマンドの情報を有するルールであって、ユーザによって作成されたルールであるユーザ指定ルールを記憶するユーザ指定ルール蓄積手段と、条件式に共通部分を有する各ユーザ指定ルールの条件式が同時に満足されないように、前記ユーザ指定ルールの条件式を変更したルールを作成する同時不成立ルール作成手段とを備えたことを特徴とする。
【００１６】
そのような構成によれば、同時不成立ルール作成手段が、条件式に共通部分を有する各ユーザ指定ルールの条件式が同時に満足されないように、そのユーザ指定ルールの条件式を変更したルールを作成する。従って、管理者は、条件式が同時に満足されるか否かの検証を行わずにユーザ指定ルールを作成することができ、管理者のルール作成負担やルール検証負担が軽減される。
【００１７】
ユーザ指定ルール蓄積手段が、復旧処理コマンドの情報として、障害からの復旧または障害回避のための対処コマンドおよび前記対処コマンド実行の準備を行うための準備コマンドの情報を有するユーザ指定ルールを記憶し、ユーザ指定ルールの条件式を変更したルールとして同時不成立ルール作成手段に作成されたルールから準備コマンドの情報を削除するとともに、条件式に共通部分を有する各ユーザ指定ルールにおける前記共通部分を条件式とし、条件式を変更することによって作成されたルールの元となったユーザ指定ルールが有する準備コマンドの情報を有する準備ルールを作成する準備ルール作成手段を備えた構成であってもよい。
【００１８】
そのような構成によれば、準備ルール作成手段が、条件式に共通部分を有する各ユーザ指定ルールにおけるその共通部分を条件式とし、条件式を変更することによって作成されたルールの元となったユーザ指定ルールが有する準備コマンドの情報を有する準備ルールを作成するので、管理者にルールの検証負担をかけることなく、共通部分が満たされたときに準備コマンドを実行させることができる。そして、先に準備コマンドを実行させることによって、対処コマンドの実行の遅れを緩和することができる。
【００１９】
準備ルール作成手段が、同時不成立ルール作成手段が作成したルールに基づいて選択された対処コマンドの実行に失敗した場合に、ユーザ指定ルールの条件式を変更したルールとして同時不成立ルール作成手段に作成されたルールから準備コマンドの情報を削除するとともに、条件式に共通部分を有する各ユーザ指定ルールにおける前記共通部分を条件式とし、条件式を変更することによって作成されたルールの元となったユーザ指定ルールが有する準備コマンドの情報を有する準備ルールを作成する構成であってもよい。
【００２０】
そのような構成によれば、同時不成立ルール作成手段が作成したルールに基づいて選択された対処コマンドの実行に失敗するまでは、準備ルール作成手段は準備コマンドを作成しない。従って、対処コマンドの実行に失敗するまでは、準備コマンドが先に実行されることがなく、準備コマンド同士の競合を防止することができる。
【００２１】
準備コマンドおよび対処コマンドの情報を有する準備対処ルールと、準備コマンドの情報を有する準備ルールの条件式が同時に成立することがあり、準備コマンド同士が競合すると定められている場合に、前記準備対処ルールに、前記準備ルールの準備コマンドの実行取消を指示する取消コマンドの情報を付加する取消コマンド情報付加手段を備えた構成であってもよい。
【００２２】
そのような構成によれば、取消コマンド情報付加手段が、準備対処ルールに、競合する準備コマンドの実行取消を指示する取消コマンドの情報を付加するので、準備コマンド同士の競合を防止することができる。
【００２３】
条件式に共通部分を有する各ユーザ指定ルールにおける前記共通部分を条件式とし、前記各ユーザ指定ルールの条件式のうち前記共通部分以外に示される動作状態が発生しているか否かの検出を指示する検出コマンドの情報を有する検出ルールを作成する検出ルール作成手段を備えた構成であってもよい。
【００２４】
一のユーザ指定ルールの条件式全体が、複数のユーザ指定ルールの条件式の共通部分となっている場合に、前記共通部分を条件式とし、前記複数のユーザ指定ルールの条件式のうち前記共通部分以外に示される動作状態が発生しているか否かの検出を指示する検出コマンドの情報と、前記一のユーザ指定ルールが有する準備コマンドの情報とを有する検出ルールを作成するとともに、前記一のユーザ指定ルールから準備コマンドの情報を削除したルールを作成する検出ルール作成手段を備えた構成であってもよい。
【００２５】
情報処理システムの動作状態を検出する動作状態検出手段と、前記動作状態検出手段によって検出された動作状態によって条件式が満足されるルールを特定し、前記ルールが有する復旧処理コマンドの情報を出力する対処方法検索手段と、前記対処方法検索手段が復旧処理コマンドの情報として検出コマンドの情報を出力した場合に、前記検出コマンドに応じた動作状態が前記情報処理システムに発生しているか否かの検出を前記動作状態検出手段に指示する検出要素制御手段とを備えた構成であってもよい。
【００２６】
そのような構成によれば、動作状態検出手段は、当初、共通部分に示された動作状態が発生しているか否かだけを検出していればよく、処方法検索手段が復旧処理コマンドの情報として検出コマンドの情報を出力した場合に、その検出コマンドに応じた動作状態が情報処理システムに発生しているか否かの検出を開始すればよい。従って、検出コマンドに応じた動作状態が情報処理システムに発生しているか否かの検出を最初から行う必要がなく、障害復旧システムの処理負荷を軽減することができる。
【００２７】
情報処理システムの動作状態を検出する動作状態検出手段と、前記動作状態検出手段によって検出された動作状態によって条件式が満足されるルールを特定し、前記ルールが有する復旧処理コマンドの情報を出力する対処方法検索手段とを備え、前記対処方法検索手段は、検出ルールの条件式が満足されるまでは、前記検出ルールが有する検出コマンドの情報に対応する動作状態を条件式に含むルールを、条件式が満足されているか否かの判定対象から外すように構成されていてもよい。
【００２８】
そのような構成によれば、動作状態検出手段は、当初、検出ルールが有する検出コマンドの情報に対応する動作状態を条件式に含むルールを、条件式が満足されているか否かの判定対象から外すので、全てのルールについて条件式が満足されているか否かの判定を行わなくてよい。よって、障害復旧システムの処理負荷を軽減することができる。
【００２９】
また、本発明による障害復旧装置は、情報処理システムの動作状態が、予め作成されたルールの条件式を満足する場合に、条件式が満たされたルールが定める復旧処理コマンドの情報を出力する障害復旧装置であって、障害発生または障害発生の前兆と見なされる情報処理システムの動作状態を条件式とし、復旧処理コマンドの情報を有するルールであって、ユーザによって作成されたルールであるユーザ指定ルールを記憶するユーザ指定ルール蓄積手段と、条件式に共通部分を有する各ユーザ指定ルールの条件式が同時に満足されないように、前記ユーザ指定ルールの条件式を変更したルールを作成する同時不成立ルール作成手段とを備えたことを特徴とする。
【００３０】
また、本発明による障害復旧装置は、情報処理システムに対し復旧処理コマンドを実行することにより前記情報処理システムに障害からの復旧または障害の回避を行わせる障害復旧装置であって、前記情報処理システムの動作状態を検出する動作状態検出手段と、復旧処理コマンドの情報を受信し、前記情報が示す復旧処理コマンドを実行するコマンド実行手段と、コマンド実行手段が、復旧処理コマンドとして、所定の動作状態が発生しているか否かの検出を指示する検出コマンドを受信した場合に、前記動作状態が前記情報処理システムに発生しているか否かの検出を前記動作状態検出手段に指示する検出要素制御手段とを備えたことを特徴とする。
【００３１】
そのような構成によれば、所定の動作状態が発生しているか否かの検出を指示する検出コマンドを受信するまでは、動作状態検出手段は、その動作状態が発生しているか否かの検出を行わなくてよい。よって、障害復旧装置の処理負荷を軽減することができる。
【００３２】
また、本発明によるルール作成方法は、情報処理システムの動作状態が、予め作成されたルールの条件式を満足する場合に、条件式が満たされたルールが定める復旧処理コマンドを実行する障害復旧システムに適用されるルール作成方法であって、ユーザ指定ルール蓄積手段が、障害発生または障害発生の前兆と見なされる情報処理システムの動作状態を条件式とし、復旧処理コマンドの情報を有するルールであって、ユーザによって作成されたルールであるユーザ指定ルールを記憶し、同時不成立ルール作成手段が、条件式に共通部分を有する各ユーザ指定ルールの条件式が同時に満足されないように、前記ユーザ指定ルールの条件式を変更したルールを作成することを特徴とする。
【００３３】
また、本発明による障害復旧プログラムは、情報処理システムの動作状態が、予め作成されたルールの条件式を満足する場合に、条件式が満たされたルールが定める復旧処理コマンドの情報を出力するコンピュータであって、障害発生または障害発生の前兆と見なされる情報処理システムの動作状態を条件式とし、復旧処理コマンドの情報を有するルールであって、ユーザによって作成されたルールであるユーザ指定ルールを記憶するユーザ指定ルール蓄積手段を備えたコンピュータに、条件式に共通部分を有する各ユーザ指定ルールの条件式が同時に満足されないように、前記ユーザ指定ルールの条件式を変更したルールを作成する同時不成立ルール作成処理を実行させることを特徴とする。
【００３４】
また、本発明による障害復旧プログラムは、情報処理システムに対し復旧処理コマンドを実行することにより前記情報処理システムに障害からの復旧または障害の回避を行わせるコンピュータに、前記情報処理システムの動作状態を検出する動作状態検処理、復旧処理コマンドの情報を受信し、前記情報が示す復旧処理コマンドを実行するコマンド実行処理、および復旧処理コマンドとして、所定の動作状態が発生しているか否かの検出を指示する検出コマンドを受信した場合に、前記動作状態が前記情報処理システムに発生しているか否かの検出を前記動作状態検処理で開始させる検出要素制御処理を実行させることを特徴とする。
【発明の効果】
【００３５】
本発明によれば、管理者のルール作成負担やルール作成時における既存のルールの検証負担を軽減させることができる。また、障害復旧システムの処理負荷を軽減することができる。
【発明を実施するための最良の形態】
【００３６】
以下、本発明を実施するための最良の形態を図面を参照して説明する。
【００３７】
実施の形態１．
図１は、本発明の第１の実施の形態を示すブロック図である。第１の実施の形態における障害復旧システムは、エージェント装置２０と、マネージャ装置３０とを備える。エージェント装置２０は、復旧対象装置（図１に示すサービス実行手段１０）の動作状態を検出するとともに、マネージャ装置３０が決定した復旧処理コマンドを復旧対象装置に対して実行する。マネージャ装置３０は、エージェント装置２０が検出した復旧対象装置の動作状態に基づいて復旧処理コマンドを決定する。マネージャ装置３０とエージェント装置２０は、通信ネットワーク（図示せず。）によって接続される。図１では、マネージャ装置３０とエージェント装置２０を１台ずつ図示しているが、マネージャ装置３０に対して複数台のエージェント装置２０が接続されていてもよい。
【００３８】
エージェント装置２０は、動作状態検出手段１と、コマンド実行手段５とを備える。また、エージェント装置２０は、サービス実行手段１０に接続される。
【００３９】
サービス実行手段１０は、Ｗｅｂサービスや業務サービスといった情報通信サービスを提供する情報処理システムである。サービス実行手段１０は、１台の情報処理装置からなる構成であってもよいし、複数台の情報処理装置が接続されたネットワークシステムであってもよい。また、図１では、エージェント装置２０がサービス実行手段１０を含んでいるように図示しているが、エージェント装置２０とサービス実行手段１０とが通信ネットワークを介して接続される構成であってもよい。
【００４０】
動作状態検出手段１は、サービス実行手段１０の動作状態を検出し、対処方法検索手段３に出力（送信）する。検出する動作状態には、サービス実行手段１０の起動／停止状態、アプリケーションプログラムの起動／停止状態、アプリケーションプログラムのエラー状態、ＣＰＵ状態、メモリ状態、ディスク状態など各種の状態がある。サービス実行手段１０の動作状態を検出する方法としては、サービス実行手段１０にＳＮＭＰ（Simple Network Management Protocol ）エージェントを常駐させ、動作状態検出手段１が定期的にＳＮＭＰリクエストをＳＮＭＰエージェントへ送信することによって検出する方法や、サービス実行手段１０にＳＮＭＰトラップの設定を行い、ＳＮＭＰトラップイベントが発生したときにそのイベント（動作状態）を受信する方法など、任意の方法を使用することができる。
【００４１】
コマンド実行手段５は、マネージャ装置３０（具体的には、後述する対話制御手段４）から復旧処理コマンドの情報を受信し、サービス実行手段１０上でその復旧処理コマンドを実行する。
【００４２】
マネージャ装置３０は、ルール蓄積手段２と、対処方法検索手段３と、対話制御手段４と、ユーザ指定ルール蓄積手段６と、共通条件制御手段７とを備える。
【００４３】
ルール蓄積手段２は、障害対処ルールを蓄積する記憶装置である。既に説明したように、障害対処ルールは、障害が発生したと判定するための条件式と、その条件式を満足する状態を検出したときにサービス実行手段１０に対して実行する復旧処理コマンドの情報とを含む。条件式としては、障害が発生したとみなされるサービス実行手段１０の状態または障害発生の前兆とみなされるサービス実行手段１０の状態が記述される。条件式として記述される状態の具体例として、例えば、サービス実行手段１０として使用される情報処理装置の処理負荷、メモリ使用量、エラー発生状況等が挙げられる。以下の説明では、説明を簡単にするために、条件式に記述される状態を、「状態Ａ」、「状態Ｂ」等のように記号で示して説明する。復旧処理コマンドは、条件式が満たされる状態となったときに、障害からの復旧または障害の回避のために使われるコマンドである。
【００４４】
本発明においても、既に説明した場合と同様に、条件式を複数の状態のＡＮＤ（論理積）によって表してもよい。図２２等に示す場合と同様に、ここでは、論理積を“＆”記号によって表すこととする。すなわち、「状態Ａ＆状態Ｂ」という条件式は、「状態Ａおよび状態Ｂが共に真である（状態Ａおよび状態Ｂがともに検出されている）」ことを意味し、その条件式が満たされたときに、その条件式に対応する復旧処理コマンドを実行することを意味する。なお、複数の状態の論理和を用いて条件式を記述することも可能である。しかし、そのような条件式を含む障害対処ルールは、実質的に複数の障害対処ルールを含んでいるので、論理和を用いない複数の障害対処ルールに分けることができる。例えば、「状態Ａまたは状態Ｂが発生しているならば対処手順Ａを実行する。」という障害対処ルールは、「状態Ａが発生しているならば対処手順Ａを実行する。」、「状態Ｂが発生しているならば対処手順Ａを実行する。」という論理和を用いない２つの障害対処ルールに分けられる。本発明では、ルール蓄積手段２は、論理和を用いずに条件式が記述された障害対処ルールを記憶しているものとする。また、本実施の形態では、ある状態が発生していないこと（ある状態の否定）を、図２３等に示す場合と同様に“ＮＯＴ”で示すことにする。
【００４５】
対処方法検索手段３は、動作状態検出手段１によって検出されたサービス実行手段１０の動作状態の情報を動作状態検出手段１から受信する。そして、対処方法検索手段３は、条件式がその動作状態に合致している障害対処ルールをルール蓄積手段２から検索し、その障害対処ルール中の復旧処理コマンドの情報を対話制御手段４に出力する。
【００４６】
対話制御手段４は、例えば、ディスプレイ装置や入力デバイス（例えば、キーボード等）を備え、対処方法検索手段３の出力情報が示す復旧処理コマンドを実行するか否かを、ユーザ（例えば、サービス実行手段１０および障害復旧システムの管理者）との対話により決定する。すなわち、対話制御手段４は、その復旧処理コマンドを実行するか否かの決定を促すＧＵＩをディスプレイ装置（図示せず。）に表示し、実行する旨の指示が入力された場合、復旧処理コマンドを実行することを決定し、その復旧処理コマンドを示す情報をコマンド実行手段５に出力（送信）する。
【００４７】
また、対話制御手段４は、ユーザが作成したルールを入力し、ユーザ指定ルール蓄積手段６に記憶させる。ユーザが作成するルールも、障害対処ルールと同様の形式で記述され、条件式および復旧処理コマンドの情報を対応付けた形式になっている。ユーザが作成したルールは、ユーザ指定ルール蓄積手段６に記憶され、そのルールに基づいて、ルール蓄積手段２に記憶される障害対策ルールが生成される。従って、ルール蓄積手段２が記憶する障害対処ルールは、ユーザが作成したルールそのものではない。そこで、ユーザが作成したルールを、ユーザ指定ルールと記し、ルール蓄積手段２が記憶する障害対処ルールと区別する。対話制御手段４は、ユーザの操作に応じて、ユーザ指定ルール蓄積手段６に新たなユーザ指定ルールを追加記憶させたり、既にユーザ指定ルール蓄積手段６が記憶しているユーザ指定ルールを編集したりする。また、対話制御手段４は、ユーザの操作に応じて、ユーザ指定ルール蓄積手段６が記憶しているユーザ指定ルールの削除も行う。
【００４８】
ユーザ指定ルール蓄積手段６は、ユーザ指定ルールを記憶する。ユーザ指定ルールは、ユーザが作成したルールそのものである。従って、図２２（ｂ）で説明したような、実際にはユーザの意図に反する復旧処理コマンドの情報を導出してしまうようなルールになっている可能性が高い。
【００４９】
共通条件制御手段７は、ユーザ指定ルール蓄積手段６に新たなユーザ指定ルールが記憶された場合（新たにユーザ指定ルールが追加された場合や、ユーザ指定ルールの編集が行われた場合）、ルール蓄積手段２が記憶している障害対処ルール全体を消去する。そして、共通条件制御手段７は、ユーザ指定ルール蓄積手段６に記憶されているユーザ指定ルールに基づいて、矛盾のない障害対処ルールの集合を作成し、その障害対処ルールの集合をルール蓄積手段２に記憶させる。ユーザ指定ルールに基づいて障害対処ルールを作成する処理については後述する。なお、ここで「矛盾のない」とは、複数の障害対処ルールの条件式が同時に成立してしまうことがないことを意味する。
【００５０】
動作状態検出手段１およびコマンド実行手段５は、例えば、コンピュータと障害復旧プログラムによって実現することができる。この障害復旧プログラムは、コンピュータ（エージェント装置２０）の立ち上げ時等にコンピュータに読み取られ、コンピュータが障害復旧プログラムに従って動作することにより、コンピュータが動作状態検出手段１およびコマンド実行手段５として機能する。障害復旧プログラムは、エージェント装置２０が備える磁気ディスクや半導体メモリ等のコンピュータ可読記録媒体に予め記録される。
【００５１】
対処方法検索手段３、対話制御手段４、および共通条件制御手段７も、例えば、コンピュータと障害復旧プログラムによって実現することができる。この障害復旧プログラムは、コンピュータ（マネージャ装置３０）の立ち上げ時等にコンピュータに読み取られ、コンピュータが障害復旧プログラムに従って動作することにより、コンピュータが対処方法検索手段３、対話制御手段４、および共通条件制御手段７として機能する。障害復旧プログラムは、マネージャ装置３０が備える磁気ディスクや半導体メモリ等のコンピュータ可読記録媒体に予め記録される。また、ルール蓄積手段２およびユーザ指定ルール蓄積手段６は、例えば、マネージャ装置３０が備える記憶装置によって実現される。
【００５２】
また、動作状態検出手段１、コマンド実行手段５、対処方法検索手段３、対話制御手段４、および共通条件制御手段７をそれぞれハードウェア装置として実現してもよい。
【００５３】
次に、動作について説明する。
図２は、ユーザ指定ルールが修正されたときにおけるマネージャ装置３０（主に共通条件制御手段７）による処理経過の例を示すフローチャートである。また、図３は、ユーザ指定ルールに基づく矛盾解消の具体例を示す説明図である。本例では、ユーザ指定ルール蓄積手段６には、初期状態として、図３に示すユーザ指定ルール５０１が記憶されているものとする。
【００５４】
まず、対話制御手段４は、ユーザの操作に応じて、ユーザ指定ルール蓄積手段６内のユーザ指定ルールに対して追加や変更等を行う（ステップＳ２１１）。ここでは、対話制御手段４は、ユーザの操作に応じて、図３に示すユーザ指定ルール５０２をユーザ指定ルール蓄積手段６に追加記憶させる。この結果、ユーザ指定ルール蓄積手段６は、ユーザ指定ルール５０１，５０２を記憶する。
【００５５】
ユーザ指定ルール蓄積手段６が記憶するユーザ指定ルールが変更されると、共通条件制御手段７は、ユーザ指定ルール蓄積手段６が記憶するユーザ指定ルールのうち、条件式に共通部分を有するユーザ指定ルールの有無を判定する（ステップＳ２１２）。ステップＳ２１２において、条件式に共通部分を有するユーザ指定ルールがないと判定した場合（ステップＳ２１２におけるＮｏ）、共通条件制御手段７は、ユーザ指定ルール蓄積手段６が記憶しているユーザ指定ルールを障害対処ルールとしてルール蓄積手段２に記憶させる（ステップＳ２１４）。このとき、共通条件制御手段７は、ステップＳ２１２においてＮｏと判定した後、ルール蓄積手段２の記憶内容（障害対処ルール）を全て削除してからステップＳ２１４の処理を実行する。
【００５６】
一方、ステップＳ２１２において、条件式に共通部分を有するユーザ指定ルールがあると判定した場合（ステップＳ２１２におけるＹｅｓ）、共通条件制御手段７は、そのユーザ指定ルールを収集して、そのユーザ指定ルール間に矛盾がなくなるように、収集したユーザ指定ルールの条件式を変更する（ステップＳ２１３）。そして、共通条件制御手段７は、条件式を変更したユーザ指定ルールを障害対処ルールとしてルール蓄積手段２に記憶させる（ステップＳ２１４）。なお、このとき、条件式に他のユーザ指定ルールとの共通部分がないユーザ指定ルールが存在していた場合、共通条件制御手段７は、そのユーザ指定ルールについては、そのまま障害対処ルールとしてルール蓄積手段２に記憶させる。
【００５７】
図４は、ステップＳ２１３の処理（ユーザ指定ルール間に矛盾がなくなるように、ユーザ指定ルールの条件式を変更することによって障害対処ルールを作成する処理）の処理経過の一例を示すフローチャートである。共通条件制御手段７は、まず、ルール蓄積手段２に記憶された障害対処ルールを全て削除する（ステップＳ３０１）。次に、共通条件制御手段７は、ユーザ指定ルール蓄積手段６が記憶するユーザ指定ルールのうち、条件式に共通部分を有するユーザ指定ルールを収集する（ステップＳ３０２）。
【００５８】
共通条件制御手段７は、ステップＳ３０２で収集したユーザ指定ルールから、条件式の変更検証対象ルールを１つずつ選択する。以下、条件式の変更検証対象となるルールを第１ルールと記す。また、共通条件制御手段７は、第１ルールの条件式を変更するか否かを、他のユーザ指定ルールの条件式と比較しながら決定していく。この他のユーザ指定ルールを第２ルールと記す。第２ルールも１つずつ順次選択される。
【００５９】
共通条件制御手段７は、ステップＳ３０２の後、収集したユーザ指定ルールのうち、第１ルール（条件式の変更検証対象となるルール）として選択されていないユーザ指定ルールがあるか否かを判定する（ステップＳ３０３）。第１ルールとして選択されていないユーザ指定ルールがなければ（ステップＳ３０３におけるＮｏ）、ステップＳ２１３（図２参照。）の処理を終了する。収集したユーザ指定ルール中に未だ第１ルールとして選択されていないユーザ指定ルールがあれば、そのユーザ指定ルールの中から１つを選択して第１ルールとする（ステップＳ３０４）。ステップＳ３０２で収集されたユーザ指定ルールのうち、ステップＳ３０４で選択された第１ルール以外の全ユーザ指定ルールが順次第２ルールとして選択される。
【００６０】
共通条件制御手段７は、ステップＳ３０４の後、ステップＳ３０２で収集されたユーザ指定ルールであって、ステップＳ３０４で選択された第１ルール以外のユーザ指定ルールの中に、第２ルールとして選択されていないユーザ指定ルールがあるか否かを判定する（ステップＳ３０５）。第２ルールとして選択されていないユーザ指定ルールがなければ（ステップＳ３０５におけるＮｏ）、ステップＳ３０３に移行し、ステップＳ３０３以降の処理を繰り返す。第２ルールとして選択されていないユーザ指定ルールがあれば（ステップＳ３０５におけるＹｅｓ）、そのユーザ指定ルールの中から１つを選択して第２ルールとする（ステップＳ３０６）。
【００６１】
共通条件制御手段７は、第１ルールと第２ルールとが同時に成立し得るか否かを判定する（ステップＳ３０７）。ステップＳ３０７では、任意の状態Ｐについて、第１ルールと第２ルールのいずれかの条件式に「状態Ｐになっていること」が条件として記述され、他方の条件式に「状態Ｐになっていないこと」が条件として記述されているならば、第１ルールと第２ルールとが同時に成立し得ないと判定すればよい。また、そうでなければ、第１ルールと第２ルールとが同時に成立し得ると判定すればよい。例えば、一方の条件式に「・・・＆状態Ｐ＆・・・」と記述され、他方の条件式に「・・・＆（ＮＯＴ状態Ｐ）＆・・・」と記述されていれば、共通条件制御手段７は、第１ルールと第２ルールとが同時に成立し得ないと判定する。第１ルールと第２ルールとが同時に成立し得ないと判定した場合（ステップＳ３０７におけるＮｏ）、ステップＳ３０５に移行し、ステップＳ３０５以降の処理を繰り返す。
【００６２】
また、第１ルールと第２ルールとが同時に成立し得ると判定した場合（ステップＳ３０７におけるＹｅｓ）、共通条件制御手段７は、第２ルールの条件式内の共通部分以外の条件を抽出し、その否定を第１ルールの条件式に追加する（ステップＳ３０８）。このとき、共通条件制御手段７は、第１ルールの条件式に記述されていた条件式と、第２ルールから抽出した条件の否定とを“＆”で結べばよい。すなわち、第１ルールの条件式に記述されていた条件式と、第２ルールから抽出した条件の否定との論理積を、第１ルールの新たな条件式とすればよい。
【００６３】
共通条件制御手段７が、第２ルールの条件式内の共通部分以外の条件を抽出し、その否定を第１ルールの条件式に追加する（ステップＳ３０８）ことによって、第１ルールと第２ルールとは同時に成立し得ない（第１ルールの条件式と第２ルールの条件式とが同時に満たされ得ない）ことになる。このように複数のルールが同時に成立しないことを、各ルールが「一意に識別される」と表現することがある。
【００６４】
共通部分を有するユーザ指定ルールのグループが複数存在した場合、それらの各グループについて、図４に示すステップＳ３０１以降の処理を行えばよい。そして、各グループについて、ステップＳ３０１以降の処理が終了した後、ステップＳ２１４に移行すればよい。
【００６５】
なお、図２および図４の処理を行ったとしても、共通条件制御手段７は、ユーザ指定ルール蓄積手段６に記憶されているユーザ指定ルール自体については書き換えない。共通条件制御手段７は、ステップＳ３０２で収集したユーザ指定ルールをバッファ等（図示せず。）に記憶させ、そのバッファ等において条件式の変更などを行う。従って、ステップＳ２１１以降、ユーザ指定ルール蓄積手段６に記憶されているユーザ指定ルールの内容は変わらない。ただし、ユーザの操作に応じて、再度ステップＳ２１１の処理が行われれば、当然に、ユーザ指定ルール蓄積手段６に記憶されているユーザ指定ルールの内容は変更される。
【００６６】
図３に示すユーザ指定ルールを用いて、以上の処理を説明する。ユーザ指定ルール５０２が追加された（ステップＳ２１１）後、共通条件制御手段７は、ユーザ指定ルール蓄積手段６が記憶するユーザ指定ルールのうち、条件式に共通部分を有するユーザ指定ルールの有無を判定する（ステップＳ２１２）。図３に示すユーザ指定ルール５０１，５０２を参照すると、条件式において“状態Ａ ＆ 状態Ｂ”の部分が共通する（ステップＳ２１２におけるＹｅｓ）。
【００６７】
その結果、共通条件制御手段７は、ステップＳ２１３の処理を開始する。具体的には、まず、ルール蓄積手段２の記憶内容を削除する（ステップＳ３０１）。そして、共通条件制御手段７は、ユーザ指定ルール蓄積手段６から、条件式に共通部分（本例では、“状態Ａ ＆ 状態Ｂ”）を有するユーザ指定ルール５０１，５０２を収集する。この時点で、ユーザ指定ルール５０１，５０２は、いずれも第１ルールとして選択されていない。よって、ステップＳ３０３の判定後、ステップＳ３０４に移行する。ステップＳ３０４では、共通条件制御手段７は、第１ルールとして未だ選択されていないユーザ指定ルール５０１，５０２の中から１つを選択する（ここでは、ユーザ指定ルール５０１を選択するものとする。）。この時点で、ユーザ指定ルール５０２は第２ルールとして選択されていない。よって、ステップＳ３０５の判定後、ステップＳ３０６に移行する。ステップＳ３０６では、共通条件制御手段７は、ユーザ指定ルール５０２を第２ルールとして選択する。
【００６８】
次に、共通条件制御手段７は、第１ルールと第２ルールとが同時に成立し得るか否かを判定する（ステップＳ３０７）。第１ルール（ここでは、ユーザ指定ルール５０１）および第２ルール（ここでは、ユーザ指定ルール５０２）との間には、いずれかの条件式に「状態Ｐになっていること」が条件として記述され、他方の条件式に「状態Ｐになっていないこと」が条件として記述されているという関係は成立していない（状態Ｐは、任意の障害発生状態）。そのため、第１ルールと第２ルールとが同時に成立し得ると判定し、ステップＳ３０８に移行する。ステップＳ３０８では、共通条件制御手段７は、第２ルールの条件式内の共通部分以外の条件を抽出する。共通部分は“状態Ａ ＆ 状態Ｂ”であるので、それ以外の条件である“状態Ｃ”を第２ルールから抽出する。そして、共通条件制御手段７は、その否定である“（ＮＯＴ状態Ｃ）”と、第１ルールの条件式に記述されていた条件式“状態Ａ ＆ 状態Ｂ”とを“＆”で結び、第１ルールの条件式を“状態Ａ ＆ 状態Ｂ ＆ （ＮＯＴ状態Ｃ）”とする。この変更後のユーザ指定ルールを、図３では、ユーザ指定ルール５０１ａとして示している。これまでユーザ指定ルールとして５０１と記していたユーザ指定ルールを、以降、ユーザ指定ルール５０１ａと記す。
【００６９】
続いて、ステップＳ３０５に移行したときには、第２ルールとして選択されていないユーザ指定ルールは存在していない（なお、第１ルールとして選択されているユーザ指定ルールは、第２ルールとして選択されない。）。よって、ステップＳ３０３に移行する。このとき、図３に示すユーザ指定ルール５０２は、未だ第１ルールとして選択されていない。よって、ステップＳ３０３からステップＳ３０４に移行し、共通条件制御手段７は、ユーザ指定ルール５０２を第１ルールとして選択する。この時点で、ユーザ指定ルール５０１ａは第２ルールとして選択されていない。よって、ステップＳ３０５の判定後、ステップＳ３０６に移行する。ステップＳ３０６では、共通条件制御手段７は、ユーザ指定ルール５０１ａ（図３参照。）を第２ルールとして選択する。
【００７０】
次に、共通条件制御手段７は、第１ルールと第２ルールとが同時に成立し得るか否かを判定する（ステップＳ３０７）。第１ルール（ここでは、ユーザ指定ルール５０２）および第２ルール（ここでは、ユーザ指定ルール５０１ａ）を参照すると、一方の条件式には、“状態Ｃ”が記述され、他方の条件式には“（ＮＯＴ状態Ｃ）”が記述されている。よって、共通条件制御手段７は、第１ルールと第２ルールとが同時に成立し得ないと判定し（ステップＳ３０７におけるＮｏ）、ステップＳ３０５に移行する。
【００７１】
続いて、ステップＳ３０５に移行したときには、第２ルールとして選択されていないユーザ指定ルールは存在していない。よって、ステップＳ３０３に移行する。この時点で、第１ルールとして選択されていないユーザ指定ルールは存在しないので（ステップＳ３０３におけるＮｏ）、処理（図２に示すステップＳ２１３の処理）を終了する。この結果、本例では、ユーザ指定ルール５０２は変更されない。ステップＳ２１３に続く、ステップＳ２１４（図２参照。）では、共通条件制御手段７は、図３に示すユーザ指定ルール５０１ａ，５０２を、障害対処ルールとしてルール蓄積手段２に記憶させる。
【００７２】
ユーザが作成したユーザ指定ルール５０１，５０２は、矛盾する状態（条件式が同時に成立してしまうことがある状態）であったが、図２および図４に示す処理を実行することにより、ユーザ指定ルール５０１，５０２という集合は、ユーザ指定ルール５０１ａ，５０２（図３参照。）という集合に修正され、ユーザ指定ルール５０１ａ，５０２が障害対処ルールとしてルール蓄積手段２に記憶される。よって、ユーザが、自身の作成したユーザ指定ルールに対する検証を行わなくても、矛盾のない障害対処ルールを作成することができ、ユーザの負担を軽減することができる。
【００７３】
図３では、条件式に共通部分を有するユーザ指定ルールが２つある場合を示したが、そのようなユーザルールが３つ以上ある場合でも、図２および図４に示す処理により、矛盾のない障害対処ルールを作成することができる。図５は、条件式に共通部分を有するユーザ指定ルールが３つある場合における矛盾解消の具体例を示す説明図である。ステップＳ３０１までの処理は、既に説明した場合と同様である。ステップＳ３０２では、共通条件制御手段７は、図５に示すユーザ指定ルール５０１〜５０３を収集する。
【００７４】
続く処理（ステップＳ３０４）で、ユーザ指定ルール５０１を第１ルールとして選択したとする。また、ステップＳ３０６で、ユーザ指定ルール５０２を第２ルールとして選択したとする。ステップＳ３０７では、共通条件制御手段７は、第１ルールと第２ルールとが同時に成立し得るか否かを判定する。このとき、第１ルール（ここでは、ユーザ指定ルール５０１）および第２ルール（ここでは、ユーザ指定ルール５０２）との間には、いずれかの条件式に「状態Ｐになっていること」が条件として記述され、他方の条件式に「状態Ｐになっていないこと」が条件として記述されているという関係は成立していない。よって、第１ルールと第２ルールとが同時に成立し得ると判定し、ステップＳ３０８に移行する。ステップＳ３０８では、共通条件制御手段７は、第２ルールの条件式内の共通部分以外の条件を抽出する。共通部分は“状態Ａ ＆ 状態Ｂ”であるので、それ以外の条件である“状態Ｃ”を第２ルールから抽出する。そして、共通条件制御手段７は、その否定である“（ＮＯＴ状態Ｃ）”と、第１ルールの条件式に記述されていた条件式“状態Ａ ＆ 状態Ｂ”とを“＆”で結び、第１ルールの条件式を“状態Ａ ＆ 状態Ｂ ＆ （ＮＯＴ状態Ｃ）”とする。その後のステップＳ３０６で、ユーザ指定ルール５０３を第２ルールとして選択したとする。この場合も、ステップＳ３０７において、共通条件制御手段７は、第１ルールの条件式“状態Ａ ＆ 状態Ｂ ＆ （ＮＯＴ状態Ｃ）”と、第２ルールの条件式“状態Ａ ＆ 状態Ｂ ＆ 状態Ｄ”とを参照し、第１ルールと第２ルールとが同時に成立し得ると判定する。そして、ステップＳ３０８では、共通条件制御手段７は、第２ルールの条件式内の共通部分以外の条件を抽出する。共通部分は“状態Ａ ＆ 状態Ｂ”であるので、それ以外の条件である“状態Ｄ”を第２ルールから抽出する。そして、共通条件制御手段７は、その否定である“（ＮＯＴ状態Ｄ）”と、第１ルールの条件式に記述されていた条件式“状態Ａ ＆ 状態Ｂ ＆ （ＮＯＴ状態Ｃ）”とを“＆”で結び、第１ルールの条件式を“状態Ａ ＆ 状態Ｂ ＆ （ＮＯＴ状態Ｃ） ＆ （ＮＯＴ状態Ｄ）”とする。この変更後のユーザ指定ルールを、図５では、ユーザ指定ルール５０１ｂとして示している。これまでユーザ指定ルールとして５０１と記していたユーザ指定ルールを、以降、ユーザ指定ルール５０１ｂと記す。
【００７５】
次に、ユーザ指定ルール５０２を第１ルールとして選択したとする。また、ステップＳ３０６で、ユーザ指定ルール５０１ｂを第２ルールとして選択したとする。すると、第１ルールの条件式の中には“状態Ｃ”が記述され、第２ルールの条件式には“（ＮＯＴ状態Ｃ）”が記述されている。よって、共通条件制御手段７は、第１ルールと第２ルールとが同時に成立し得ないと判定し、ステップＳ３０５に移行する。次に、共通条件制御手段７は、ユーザ指定ルール５０３を第２ルールとして選択する。このとき、第１ルール（ここでは、ユーザ指定ルール５０２）および第２ルール（ここでは、ユーザ指定ルール５０３）との間には、いずれかの条件式に「状態Ｐになっていること」が条件として記述され、他方の条件式に「状態Ｐになっていないこと」が条件として記述されているという関係は成立していない（状態Ｐは、任意の障害発生状態）。よって、第１ルールと第２ルールとが同時に成立し得ると判定し、ステップＳ３０８に移行する。ステップＳ３０８では、共通条件制御手段７は、第２ルールの条件式内の共通部分以外の条件を抽出する。共通部分は“状態Ａ ＆ 状態Ｂ”であるので、それ以外の条件である“状態Ｄ”を第２ルールから抽出する。そして、共通条件制御手段７は、その否定である“（ＮＯＴ状態Ｄ）”と、第１ルールの条件式に記述されていた条件式“状態Ａ ＆ 状態Ｂ ＆ 状態Ｃ”とを“＆”で結び、第１ルールの条件式を“状態Ａ ＆ 状態Ｂ ＆ 状態Ｃ ＆ （ＮＯＴ状態Ｄ）”とする。この変更後のユーザ指定ルールを、図５では、ユーザ指定ルール５０２ｂとして示している。これまでユーザ指定ルールとして５０２と記していたユーザ指定ルールを、以降、ユーザ指定ルール５０２ｂと記す。
【００７６】
次に、ユーザ指定ルール５０３を第１ルールとして選択したとする。また、ステップＳ３０６で、ユーザ指定ルール５０１ｂを第２ルールとして選択したとする。すると、第１ルールの条件式の中には“状態Ｄ”が記述され、第２ルールの条件式には“（ＮＯＴ状態Ｄ）”が記述されている。よって、共通条件制御手段７は、第１ルールと第２ルールとが同時に成立し得ないと判定し、ステップＳ３０５に移行する。次に、共通条件制御手段７は、ユーザ指定ルール５０２ｂを第２ルールとして選択したとする。この場合も、第１ルールの条件式の中には“状態Ｄ”が記述され、第２ルールの条件式には“（ＮＯＴ状態Ｄ）”が記述されている。よって、共通条件制御手段７は、第１ルールと第２ルールとが同時に成立し得ないと判定し、ステップＳ３０５に移行する。従って、ユーザ指定ルール５０３の条件式は変更されない。共通条件制御手段７は、収集した３つのユーザ指定ルールをそれぞれ第１ルールとして選択したので、次にステップＳ３０３に移行したときにはＮｏと判定し、ステップＳ２１３（図２参照。）の処理を終了する。そして、ステップ２１４において、図５に示すユーザ指定ルール５０１ｂ，５０２ｂ，５０３を障害対処ルールとしてルール蓄積手段２に記憶させる。
【００７７】
障害復旧システムは、サービス実行手段１０の状態を検出し、その状態と、以上のようにルール蓄積手段２に記憶された障害対処ルールとに基づいて復旧処理コマンドを決定し、サービス実行手段１０に対し、その復旧処理コマンドを実行する。図６は、サービス実行手段１０の状態検出から、復旧処理コマンド実行までの処理経過を示すフローチャートである。
【００７８】
動作状態検出手段１は、サービス実行手段１０の動作状態を検出し、通信ネットワークを介して対処方法検索手段３に動作状態の情報を送信する（ステップＳ２０１）。対処方法検索手段３は、動作状態検出手段１から現在の動作状態の情報を受信し、ルール蓄積手段２に蓄積されている各障害対処ルールの中に、条件式が満たされている障害対処ルールがあるか否かを判定する（ステップＳ２０２）。サービス実行手段１０の動作状態によっていずれの障害対処ルールの条件式も満たされていない場合（ステップＳ２０２におけるＮｏ）、障害が発生していないものとしてステップＳ２０１に移行し、ステップＳ２０１移行の処理を繰り返す。
【００７９】
サービス実行手段１０の動作状態によって条件式が満たされる障害対処ルールが存在する場合には（ステップＳ２０２におけるＹｅｓ）、対処方法検索手段３は、障害発生とみなして、その障害対処ルールに含まれる復旧処理コマンドの情報を抽出し、その情報を対話制御手段４に出力する。対話制御手段４は、ＧＵＩによって、その復旧処理コマンドの情報を出力し、その復旧処理コマンドを実行するか否かの決定をユーザ（管理者）に促す（ステップＳ２０３）。復旧処理コマンドを実行しない旨が管理者によって入力された場合、ステップＳ２０１に移行し、ステップＳ２０１以降の処理を繰り返す。なお、ユーザに適切な判断を行わせるために、ＧＵＩと併せて、サービス実行手段１０の動作状態や、その動作状態によって満たされた条件式の情報等を表示出力してもよい。また、特定の復旧処理コマンドについては、管理者に問い合わせることなく自動的に実行してよいという設定を対話制御手段４に対して施しておいてもよい。この場合、対話制御手段４は、その特定の復旧処理コマンドの情報が入力されると、その復旧処理コマンドを実行するか否かの決定を促すＧＵＩを表示することなく、その特定の復旧処理コマンドの情報をコマンド実行手段５に送信する。
【００８０】
復旧処理コマンドを実行する旨が管理者によって入力された場合（ステップＳ２０３におけるＹｅｓ）、対話制御手段４は、その復旧処理コマンドの情報をコマンド実行手段５に送信し、コマンド実行手段５はサービス実行手段１０上でその復旧処理コマンドを実行する（ステップＳ２０４）。
【００８１】
例えば、図３に示すルール５０１ａ，５０２が障害対処ルールとしてルール蓄積手段２に記憶されているとする。この場合、動作状態検出手段１によって、状態Ａ，Ｂ，Ｃのいずれもが発生している場合、障害対処ルール５０２の条件式が満たされる。従って、対処方法検索手段３は、障害対処ルール５０２における復旧処理コマンドの情報である「対処手順Ｂ」を対話制御手段４に出力する。対話制御手段４は、ＧＵＩによって「対処手順Ｂ」の実行可否の決定を管理者に促し、実行する旨の指示が入力されると、「対処手順Ｂ」という情報をコマンド実行手段５に送信する。そして、コマンド実行手段５は、対処手順Ｂを実行する。その結果、状態Ａ，Ｂ，Ｃがいずれも発生してしまっているという障害が復旧または回避されることになる。
【００８２】
本実施の形態によれば、ユーザ指定ルールの修正（追加や変更等）の結果、条件式に共通部分を有するユーザ指定ルールが存在した場合、共通条件制御手段７が、ステップＳ３０１以降の処理を行い、矛盾がなくなるようにユーザ指定ルールの条件式を修正する。そして、共通条件制御手段７が、修正後のユーザ指定ルールを障害対処ルールとしてルール蓄積手段２に記憶させる。従って、ユーザ（管理者）にとって、自らが作成したユーザ指定ルールに対する無矛盾性検証、ユーザ指定ルールの変更等の負担が大幅に軽減される。
【００８３】
また、管理者は自らが意図したユーザ指定ルールを作成すれば、そのユーザ指定ルールに基づく矛盾のない障害対処ルールが作成される。そして、障害復旧システムが図６に示す処理を実行する際には、障害対処ルールが作成されていればよく、管理者が障害対処ルールの全てを理解している必要はない。よって、管理者の負担が軽減される。障害対処ルールは、ステップＳ３０８で条件が新たに追加されている場合があるので、必ずしも管理者にとって理解しやすい記述とはなっていない。例えば、図５に示す例では、条件式に“（ＮＯＴ状態Ｃ） ＆ （ＮＯＴ状態Ｄ）”が追加されているが、この追加条件は、管理者自身が記述したものではない。このような条件追加が多く行われた障害対処ルールを管理者が参照しても、本来何を目的としたルールであったのかを理解することが困難となる。しかし、上記のように、管理者はそのような障害対処ルールを理解する必要がないので、負担が軽減される。
【００８４】
また、共通条件制御手段７は、ステップＳ３０２で収集したユーザ指定ルールをバッファ等（図示せず。）に記憶させ、そのバッファ等においてユーザ指定ルールを行う。よって、ユーザ指定ルール蓄積手段６には、管理者によって入力されたユーザ指定ルールが変更されることなく記憶されている。対話制御手段４は、ユーザ指定ルール蓄積手段６に記憶されたユーザ指定ルールを管理者に提示する。この結果、管理者に、管理者自身が入力した理解容易なユーザ指定ルールを提示することになる。従って、管理者は、そのような理解容易なユーザ指定ルールを参照して、新たなユーザ指定ルールの追加やユーザ指定ルールの変更を効率よく行える。
【００８５】
また、本発明では、条件式が満たされた障害対処ルールが存在した場合、対処方法検索手段３が、その条件式に対応する復旧処理コマンドの情報を出力し、その情報は対話制御手段４を介して、コマンド実行手段５に送信される。コマンド実行手段５は、受信した情報が示す復旧処理コマンドをサービス実行手段１０に対して実行する。従って、サービス実行手段１０における障害復旧や障害回避を迅速に行うことができる。
【００８６】
実施の形態２．
本発明の第２の実施の形態における障害復旧システムの構成は、図１に例示する構成と同様であり、図１を用いて第２の実施の形態について説明する。ただし、第２の実施の形態では、共通条件制御手段７は、第１の実施の形態における動作に加え、さらに他の動作も行う。
【００８７】
サービス実行手段１０の状態検出から、復旧処理コマンド実行までの処理経過は、第１の実施の形態（図６参照。）と同様である。
【００８８】
また、第２の実施の形態では、ユーザ指定ルールにおける復旧処理コマンドには、対処コマンドおよび準備コマンドが含まれているものとする。すなわち、対話制御手段４が、ユーザ（管理者）の操作に応じてユーザ指定ルールを入力する場合、その個々のユーザ指定ルールには、復旧処理コマンドの情報として対処コマンドおよび準備コマンドの情報がそれぞれ含まれているものとする。対処コマンドは、サービス実行手段１０を障害から復旧させたり、障害発生を回避させたりするためのコマンドである。準備コマンドは、対処コマンド実行の準備を行うためのコマンドである。
【００８９】
準備コマンドによる事前準備の例として、データのバックアップ、コマンドのダウンロード、切替用情報処理装置に対する準備等が挙げられる。切替用情報処理装置に対する準備の例として、例えば、サービス実行手段１０が、障害発生時に用いられる切替用情報処理装置を含む複数の情報処理装置によって構成されるシステムである場合おける、切替用情報処理装置に対するソフトウェアインストール等が挙げられる。対処コマンドによる対処の例としては、サービス実行手段１０の設定変更や、切替用情報処理装置への切り替え等が挙げられる。切替用情報処理装置への切り替えとは、障害が発生した情報処理装置ではなく切替用情報処理装置にデータが流れるようにサービス実行手段１０内のデータ転送経路を切り替えることである。
【００９０】
準備コマンドの特徴として、実行時間が比較的長いことが挙げられる。また、サービス実行手段１０に対して準備コマンドを実行したとしても、サービス実行手段１０を準備コマンド実行前の状態に戻すことができるという特徴がある。一方、対処コマンドの特徴として、対処コマンド実行後にサービス実行手段１０が情報通信サービスを提供した場合、サービス実行手段１０を対処コマンド実行前の状態に戻すことができないということが挙げられる。例えば、対処コマンドを実行したことにより、サービス実行手段１０の設定が変更され、その後、サービス実行手段１０が情報通信サービスを提供したとする。すると、情報通信サービスを提供に伴い、変更後の設定に基づいた新たなデータが生成されることになる。このとき、サービス実行手段１０の設定自体は元の設定に戻すことができるが、その状態では、新たに生成されたデータに対する処理を行うことができない。このように設定を戻したとしても、設定変更後に生成されたデータが既に発生した状態になっているため、サービス実行手段１０を対処コマンド実行前の状態に戻すことができない。よって、対処コマンドは、サービス実行手段１０に対して不可逆な変更を加えるコマンドであると言える。
【００９１】
ユーザ自身が作成したユーザ指定ルールにおける復旧処理コマンドの情報には、対処コマンドおよび準備コマンドの両方の情報が含まれているが、ルール蓄積手段２が記憶する復旧処理コマンドでは、対処コマンドと準備コマンドのうちのいずれか一方のみの情報が含まれていてもよい。また、復旧処理コマンドでは、対処コマンドと準備コマンドの両方の情報が含まれていてもよい。
【００９２】
共通条件制御手段７は、第１の実施の形態と同様に、ユーザ指定ルールの矛盾を解消して、ユーザ指定ルールが一意に識別されるようにする処理（図４に示すステップＳ３０１〜Ｓ３０８の処理）を実行する。本実施の形態では、共通条件制御手段７は、さらに以下の処理を行う。すなわち、一意に識別できるように条件式が変更されたユーザ指定ルールと、変更前のユーザ指定ルールとを比較し、変更されているユーザ指定ルールを特定する。そして、共通条件制御手段７は、その変更されたユーザ指定ルールの変更前の条件式を条件式とし、変更前の復旧処理コマンドに含まれる準備コマンドのみを復旧処理コマンドとする新たな障害対処ルールを作成する。また、共通条件制御手段７は、変更されたユーザ指定ルールにおいて復旧処理コマンドとして含まれている準備コマンドの情報を削除し、対処コマンドが残るように、さらにユーザ指定コマンドを変更する。共通条件制御手段７は、以上の処理を行ったユーザ指定コマンドおよび新たに作成した障害対処ルールを、障害対処ルールとしてルール蓄積手段２に記憶させる。
【００９３】
以下、第２の実施の形態の動作について説明する。図７は、ユーザ指定ルールが修正されたときにおけるマネージャ装置３０（主に共通条件制御手段７）による処理経過の例を示すフローチャートである。また、図８は、ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。
【００９４】
まず、対話制御手段４は、ユーザの操作に応じて、ユーザ指定ルール蓄積手段６内のユーザ指定ルールに対して追加や変更等を行う（ステップＳ２２１）。ここでは、元々図８（ａ）に示すユーザ指定ルール６０１が記憶されていて、ステップＳ２２１において、対話制御手段４がユーザの操作に応じてユーザ指定ルール６０２を追加したものとする。ステップＳ２２１の結果、ユーザ指定ルール蓄積手段６には、ユーザ指定ルール６０１，６０２が記憶されている。本実施の形態では、ユーザ指定ルールにおける復旧処理コマンドの情報には、対処コマンドおよび準備コマンドの両方の情報が含まれる。図８（ａ）に示す例では、ユーザ指定ルール６０１は、「準備Ａ（準備コマンド）」および「対処Ａ（対処コマンド）」の情報を含んでいる。同様に、ユーザ指定ルール６０２は、「準備Ｂ（準備コマンド）」および「対処Ｂ（対処コマンド）」の情報を含んでいる
【００９５】
ユーザ指定ルール蓄積手段６が記憶するユーザ指定ルールが変更されると、共通条件制御手段７は、ユーザ指定ルール蓄積手段６が記憶するユーザ指定ルールのうち、条件式に共通部分を有するユーザ指定ルールの有無を判定する（ステップＳ２２２）。この処理は、第１の実施の形態におけるステップＳ２１２の処理と同様である。また、ステップＳ２２２において、条件式に共通部分を有するユーザ指定ルールがないと判定した場合（ステップＳ２２２におけるＮｏ）、共通条件制御手段７は、ユーザ指定ルール蓄積手段６が記憶しているユーザ指定ルールを障害対処ルールとしてルール蓄積手段２に記憶させる（ステップＳ２２５）。ステップＳ２２２においてＮｏと判定し、ステップＳ２２５に移行する際の共通条件制御手段７の動作は、第１の実施の形態で、ステップＳ２１２の次にステップＳ２１４に移行する動作と同様である。
【００９６】
一方、ステップＳ２２２において、条件式に共通部分を有するユーザ指定ルールがあると判定した場合（ステップＳ２２２におけるＹｅｓ）、共通条件制御手段７は、そのユーザ指定ルールを収集して、そのユーザ指定ルール間に矛盾がなくなるように、収集したユーザ指定ルールの条件式を変更する（ステップＳ２２３）。ステップＳ２２３の処理は、第１の実施の形態におけるステップＳ２１３の処理と同様である。より詳細には、ステップＳ２２３の処理として、第１の実施の形態で示したステップＳ３０１〜Ｓ３０８（図４参照。）と同様の処理を実行すればよい。ステップＳ２２３の結果、図８（ａ）に示すユーザ指定ルール６０１，６０２から、図８（ｂ）に示すユーザ指定ルール６０１ａ，６０２ａが生成される。
【００９７】
ステップＳ２２３の後、共通条件制御手段７は、復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールの作成や、対処コマンドのみを含むようにユーザ指定ルールを変更する処理を実行する（ステップＳ２２４）。そして、共通条件制御手段７は、ステップＳ２２４の結果得られた各ルール（ユーザ指定ルールや新たに作成した障害対処ルール）を、障害対処ルールとしてルール蓄積手段２に記憶させる（ステップＳ２２５）。なお、このとき、条件式に他のユーザ指定ルールとの共通部分がないユーザ指定ルールが存在していた場合、共通条件制御手段７は、そのユーザ指定ルールについては、そのまま障害対処ルールとしてルール蓄積手段２に記憶させる。
【００９８】
図９は、ステップＳ２２４の処理（復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールの作成や、対処コマンドのみを含むようにユーザ指定ルールを変更する処理）の処理経過の一例を示す説明図である。ステップＳ２２３の処理により、図８（ｂ）に例示するような一意に識別されるユーザ指定ルールを導出した後、共通条件制御手段７は、ステップＳ２２３の矛盾解消処理において条件式が変更されたユーザ指定ルールから準備コマンドの情報を削除する（ステップＳ３２１）。
【００９９】
ステップＳ３２１の後、共通条件制御手段７は、ステップＳ２２３の処理において条件式が変更されたユーザ指定ルールにおける元の（変更前の）ユーザ指定ルールを抽出する（ステップＳ３２２）。ユーザ指定ルール蓄積手段６には、ユーザによって作成されたユーザ指定ルールがそのまま記憶されているので、共通条件制御手段７は、ユーザ指定ルール蓄積手段６から変更前のユーザ指定ルールを読み込めばよい。
【０１００】
ステップＳ３２２の後、共通条件制御手段７は、ステップＳ３２２で抽出したユーザ指定ルール（条件式が変更されたユーザ指定ルールにおける元のユーザ指定ルール）の条件式と同一の条件式を有し、復旧処理コマンドの情報として、ステップＳ３２２で抽出したユーザ指定ルールに含まれる準備コマンドの情報を有する障害対処ルールを作成する（ステップＳ３２３）。
【０１０１】
共通部分を有するユーザ指定ルールのグループが複数存在した場合、それらの各グループについて、図９に示すステップＳ３２１以降の処理を行えばよい。そして、各グループについて、ステップＳ３２１以降の処理が終了した後、ステップＳ２２５に移行すればよい。
【０１０２】
図８を用いて、以上の処理を説明する。共通条件制御手段７は、ユーザ自身が作成したユーザ指定ルール６０１，６０２に基づいて、ステップＳ２２３の処理（より具体的には図４に示すステップＳ３０１〜Ｓ３０８の処理）を実行することにより、ユーザ指定ルール６０１ａ，６０２ａ（図８（ｂ）参照。）を作成する。この作成過程は、第１の実施の形態において図３を用いて説明した場合と同様である。なお、図８（ｃ）は、図９に示すステップＳ３２１〜Ｓ３２３の処理の後における各ルールを示す。
【０１０３】
ユーザ指定ルール６０１ａ，６０２ａ作成後、共通条件制御手段７は、ステップＳ２２３の処理において条件式が変更されたユーザ指定ルールから準備コマンドの情報を削除する（ステップＳ３２１）。図８（ｂ）に示すユーザ指定ルール６０１ａは、図８（ａ）に示す条件式を変更し、“（ＮＯＴ状態Ｃ）”をいう条件を追加して作成されている。従って、共通条件制御手段７は、ユーザ指定ルール６０１ａから準備コマンドである「準備Ａ」の情報を削除する。この結果を、図８（ｃ）においてユーザ指定ルール６０１ｂとして示している。また、図８（ｂ）に示すユーザ指定ルール６０２ａは、元のユーザ指定ルール６０２と同一であり、変更されていない。従って、共通条件制御手段７は、ユーザ指定ルール６０２ａからは準備コマンドの情報を削除しない。よって、図８（ｃ）にユーザ指定ルール６０１ｂとして示しているように、復旧処理コマンドの情報として「準備Ｂ」が残される。
【０１０４】
続く、ステップＳ３２２において、共通条件制御手段７は、ステップＳ２２３の処理において条件式が変更されたユーザ指定ルールにおける元の（変更前の）ユーザ指定ルールを抽出する。本例では、条件式が変更されたユーザ指定ルール６０１ａの元のユーザ指定ルール６０１をユーザ指定ルール蓄積手段６から抽出すればよい。ユーザ指定ルール６０２ａに関しては条件式が変更されていないので、その元のユーザ指定ルール６０２を抽出する必要はない。
【０１０５】
次のステップＳ３２３では、共通条件制御手段７は、抽出したユーザ指定ルール６０１の条件式と同一の条件式“状態Ａ ＆ 状態Ｂ”を有し、復旧処理コマンドの情報として、抽出したユーザ指定ルール６０１に含まれる準備コマンドの情報（「準備Ａ」）を有する障害対処ルールを作成する。図８（ｃ）では、この障害対処ルールを、障害対処ルール６０３ｂとして示している。
【０１０６】
以上の処理の結果、図８（ｃ）に示すルール６０１ｂ、６０２ｂ、６０３ｂが生成される。共通条件制御手段７は、これらのルール６０１ｂ、６０２ｂ、６０３ｂを障害対処ルールとしてルール蓄積手段２に記憶させる（図７に示すステップＳ２２５）。
【０１０７】
図８（ｂ）に示すユーザ指定ルール６０１ａ，６０２ａを障害対処ルールとした場合、「対処Ｂ」の実行タイミングは、「状態Ａかつ状態Ｂかつ状態Ｃ」が検出された時点である。これは、ユーザ自身が作成したユーザ指定ルール６０２において規定されている「対処Ｂ」の実行タイミングと同一である。一方、「対処Ａ」の実行タイミングは、「状態Ａおよび状態Ｂであることが検出され、かつ状態Ｃでないこと」が検出された時点である。このタイミングは、ユーザ自身が作成したユーザ指定ルール６０１において規定されている「対処Ａ」の実行タイミングよりも遅れる。状態Ｃが発生していないことを判定する分だけ条件式の判定時間がかかるためのである。
【０１０８】
第２の実施の形態によれば、図８（ａ），（ｂ）に示すユーザ指定ルールを用いてステップＳ２２４（より具体的には図９に示すステップＳ３２１〜Ｓ３２３）を行い、図８（ｃ）に例示するルール６０１ｂ，６０２ｂ，６０３ｃを生成する。そして、このルール群を障害対処ルールとする。この場合、「状態Ａかつ状態Ｂ」が検出された時点で、「準備Ａ」が実行される。その後、状態Ｃが発生しているか否かが判定された時に、「準備Ｂ、対処Ｂ」または「対処Ａ」が選択的に実行される。「準備Ａ」の実行タイミングは、ユーザ自身が作成したユーザ指定ルール６０１において規定されている「準備Ａ、対処Ａ」の実行タイミングと同一である。従って、第２の実施の形態によれば、比較的実行時間のかかる「準備Ａ」の実行タイミングを、ユーザ自身が作成したユーザ指定ルールにおいて規定されている実行タイミングにあわせることができ、対処の実行の遅れを緩和することができる。
【０１０９】
図８では、ステップＳ２２１（図７参照。）後において、条件式に共通部分を有するユーザ指定ルールが２つある場合を示したが、そのようなユーザルールが３つ以上ある場合でも、同様に処理を行う。以下、ステップＳ２２１（図７参照。）後において、条件式に共通部分を有するユーザ指定ルールが３つである場合を例に説明する。図１０は、ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。図１０（ａ）は、ステップＳ２２１後におけるユーザ指定ルールを表し、図１０（ｂ）は、ステップＳ２２３の矛盾解消処理後のユーザ指定ルールを表す。図１０（ａ）に示すユーザ指定ルール６１１〜６１３に基づいて、図１０（ｂ）に示すユーザ指定ルール６１１ａ〜６１３ａを導出する処理は、図５を用いて説明した場合と同様である。
【０１１０】
図１０（ｂ）に示すユーザ指定ルール６１１ａ〜６１３ａの作成後、共通条件制御手段７は、ステップＳ２２３で条件式が変更されたユーザ指定ルールから準備コマンドの情報を削除する（ステップＳ３２１）。図１０（ｂ）に示すユーザ指定ルール６１１ａは、図１０（ａ）に示す条件式を変更し、“（ＮＯＴ状態Ｃ） ＆ （ＮＯＴ状態Ｄ）”という条件を追加して作成されている。従って、共通条件制御手段７は、ユーザ指定ルール６１１ａから「準備Ａ」の情報を削除する。この結果を図１０（ｃ）においてユーザ指定ルール６１１ｂとして示している。同様に、共通条件制御手段７は、ユーザ指定ルール６１２ａから「準備Ｂ」の情報を削除する。この結果を図１０（ｃ）においてユーザ指定ルール６１２ｂとして示している。また、図１０（ｂ）に示すユーザ指定ルール６１３ａは、元のユーザ指定ルール６１３と同一であり、変更されていない。従って、共通条件制御手段７は、ユーザ指定ルール６１３ａからは準備コマンドの情報を削除しない。よって、図１０（ｃ）にユーザ指定ルール６１３ｂとして示しているように、復旧処理コマンドの情報として「準備Ｃ」が残される。
【０１１１】
続く、ステップＳ３２２において、共通条件制御手段７は、ステップＳ２２３の処理で条件式が変更されたユーザ指定ルールにおける元の（変更前の）ユーザ指定ルールを抽出する。本例では、条件式が変更されたユーザ指定ルール６１１ａ，６１２ａの元のユーザ指定ルール６１１，６１２をユーザ指定ルール蓄積手段６から抽出すればよい。ユーザ指定ルール６１３ａに関しては条件式が変更されていないので、その元のユーザ指定ルール６１３を抽出する必要はない。
【０１１２】
次のステップＳ３２３では、共通条件制御手段７は、抽出したユーザ指定ルール６１１の条件式と同一の条件式“状態Ａ ＆ 状態Ｂ”を有し、復旧処理コマンドの情報として、抽出したユーザ指定ルール６１１に含まれる準備コマンドの情報（「準備Ａ」）を有する障害対処ルールを作成する。図１０（ｃ）では、この障害対処ルールを、障害対処ルール６１４ｂとして示している。同様に、共通条件制御手段７は、抽出したユーザ指定ルール６１２の条件式と同一の条件式“状態Ａ ＆ 状態Ｂ ＆ 状態Ｃ”を有し、復旧処理コマンドの情報として、抽出したユーザ指定ルール６１２に含まれる準備コマンドの情報（「準備Ｂ」）を有する障害対処ルールを作成する。図１０（ｃ）では、この障害対処ルールを、障害対処ルール６１５ｂとして示している。
【０１１３】
以上の処理の後、共通条件制御手段７は、図１０（ｃ）に示す各ルールを障害対処ルールとしてルール蓄積手段２に記憶させる。
【０１１４】
第２の実施の形態によれば、共通条件制御手段７が、ユーザ指定ルールの矛盾を解消した後、ステップＳ２２４（より具体的には図９に示すステップＳ３２１〜Ｓ３２３）の処理を行う。従って、ユーザが作成したユーザ指定ルールが規定するタイミングで準備コマンドを実行して対処コマンドの実行の遅れを緩和することができる。
【０１１５】
次に、第２の実施の形態の変形例について説明する。図８（ｃ）に示すような障害対処ルールを作成した場合、状態Ａ，Ｂ，Ｃを全て検知した場合には、「準備Ａ」を実行し、「準備Ｂ、対処Ｂ」も実行することになる。この場合、「準備Ａ」と「準備Ｂ」の実行が何らかの競合を引き起こし、サービス実行手段１０に好ましくない動作を行わせる場合が発生する場合もある。また、図８（ｂ）に例示するユーザ指定ルール（ステップＳ２２３後のユーザ指定ルール）を障害対処ルールとして使用した場合であっても、「対処Ａ」の遅れが問題にならない場合もある。そこで、まず、ステップＳ２２３の矛盾解消処理の結果得られるユーザ指定ルールを障害対処ルールとしてルール蓄積手段２に記憶させてもよい。そして、ステップＳ２２３の矛盾解消処理において条件式に変更を加えたルールにおける対処コマンドの実行に失敗したときに、復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールの作成等（図７に示すステップＳ２２４に相当する処理）を実行してもよい。
【０１１６】
図１１は、上記の変形例におけるマネージャ装置３０（主に共通条件制御手段７）による処理経過の例を示すフローチャートである。図７に示す処理と同様の処理に関しては、図７と同様の符号を付して、詳細な説明を省略する。本変形例では、図１１に示すように、矛盾解消処理（ステップＳ２２３）の結果得られるユーザ指定ルールを障害対処ルールとして記憶する（ステップＳ２２５）。すなわち、ステップＳ２２５では、図８（ｂ）や図１０（ｂ）に例示するルールを障害対処ルールとしてルール蓄積手段に蓄積する。
【０１１７】
その後、矛盾解消処理（ステップＳ２２３）において条件式が変更されたルールにおける準備コマンドおよび対処コマンドを、対処方法検索手段３が検索し、対話制御手段４がその準備コマンドおよび対処コマンドの情報をコマンド実行手段５に送信して、その準備コマンドおよび対処コマンドが実行されたとする。動作状態検出手段１は、対処コマンド実行後の動作状態を検出して、その動作状態の情報を対処方法検索手段３に送信する。対処方法検索手段３は、その動作状態の情報と、各障害対処ルールの条件式とを照合して、障害が発生している状態か否かを判定する。障害が発生している状態であれば、対処コマンドの実行が遅れ、対処コマンドの実行に失敗したことになる。障害が発生していなければ、対処コマンドの実行タイミングが、ユーザ自身が作成したユーザ指定ルールにおいて規定されているタイミングより遅れても、対処コマンドの実行に成功したことになる。対処方法検索手段３は、このように、対処コマンドの実行に成功したか否かを判定する（ステップＳ２２６）。ステップＳ２２６で、対処コマンドの実行に成功したと判定した場合には、ステップＳ２２１に移行し、ステップＳ２２１以降の処理を繰り返せばよい。
【０１１８】
一方、ステップＳ２２６で、対処コマンドの実行に失敗したとする（ステップＳ２２６におけるＮｏ）。この場合、共通条件制御手段７は、ステップＳ２２７の処理として以下の処理を実行する。共通条件制御手段７は、ルール蓄積手段２に記憶させた障害対処ルールのうち、ステップＳ２２３の矛盾解消処理において条件式に変更が加えられていたルールから、準備コマンドの情報を削除する。例えば、ステップＳ２２３，Ｓ２２５の処理の結果、図８（ｂ）に示す各ルール６０１ａ，６０２ａが障害対処ルールとしてルール蓄積手段２に記憶されていたとする。この例では、ステップＳ２２３の矛盾解消処理において条件式に変更が加えられていたルールは、ルール６０１ａである。従って、共通条件制御手段７は、障害対処ルールとしてルール蓄積手段２に記憶されたルール６０１から準備コマンドの情報である「準備Ａ」を削除し、図８（ｃ）に示すルール６０１ｂになるように障害対処ルールを書き換える。
【０１１９】
また、復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールを作成し、その障害対処ルールをルール蓄積手段２に追加記憶させる。この障害対処ルール作成処理は、図９に示すステップＳ３２２，３２３と同様に行えばよい。すなわち、共通条件制御手段７は、ステップＳ２２３の処理において条件式が変更されたユーザ指定ルールにおける元の（変更前の）ユーザ指定ルールを抽出する。そして、共通条件制御手段７は、その抽出したユーザ指定ルールの条件式と同一の条件式を有し、復旧処理コマンドの情報として、抽出したユーザ指定ルールに含まれる準備コマンドの情報を有する障害対処ルールを作成すればよい。以上の処理を、ステップＳ２２７の処理として行い、その後ステップＳ２２１に移行する。
【０１２０】
以上のような変形例によれば、準備コマンド同士の競合により、サービス実行手段１０に好ましくない動作を行わせることを防止できる。
【０１２１】
また、第２の実施の形態の他の変形例は、図９に示す処理において、ステップＳ３２３の後、競合する準備コマンドが同時に実行されることがある場合に、準備コマンドの前に、競合する準備コマンドの実行を取り消す取消コマンドの情報を付加する形態である。なお、準備コマンドの実行を取り消すとは、その準備コマンド実行前の状態に戻すことである。
【０１２２】
図１２は、本変形例におけるステップＳ２２４の処理（復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールの作成や、対処コマンドのみを含むようにユーザ指定ルールを変更する処理）の処理経過の一例を示す説明図である。図９に示す処理と同様の処理については、図９と同一の符号を付して説明を省略する。
【０１２３】
ステップＳ３２３の後、共通条件制御手段７は、ステップＳ３２３によって得られた各ルールのうち、準備コマンドが競合するルールが存在するか否かを判定する（ステップＳ３２４）。ステップＳ３２４において、共通条件制御手段７は、まず、準備コマンドの情報を含むルールであって、同時に成立し得るルールを選択する。ここで同時に成立し得ることは、あるルールの条件式では「状態Ｐになっていること」が条件として記述され、他のルールの条件式では「状態Ｐになっていないこと」が条件として記述されていることに基づいて判定すればよい（状態Ｐは、任意の障害発生状態）。そして、共通条件制御手段７は、選択した各ルールの準備コマンドが競合するか否かを判定すればよい。なお、競合する準備コマンドの情報は、例えば、マネージャ装置が備える記憶装置（図示せず。）に予め記憶させておけばよい。
【０１２４】
準備コマンドの情報を含むルールであって、同時に成立し得るルールを選択し、そのルールの準備コマンドが競合するものでなければ（ステップＳ３２４におけるＮｏ）、処理を終了する。
【０１２５】
準備コマンドが競合する場合（ステップＳ３２４におけるＹｅｓ）、共通条件制御手段７は、準備コマンドが競合するルールに、準備コマンドの実行を取り消す取消コマンドの情報を追加する（ステップＳ３２５）。具体的には、共通条件制御手段７は、対処コマンドの情報を含むルールの準備コマンドの情報の前に、その準備コマンドと競合する準備コマンドの取消コマンドの情報を追加する。その後、共通条件制御手段７は、以上の処理の結果得られるルールを障害対処ルールとしてルール蓄積手段２に記憶させる（図７に示すステップＳ２２５）。なお、共通部分を有するユーザ指定ルールのグループが複数存在した場合、それらの各グループについて、図１２に示すステップＳ３２１以降の処理を行えばよい。そして、各グループについて、ステップＳ３２１以降の処理が終了した後、ステップＳ２２５に移行すればよい。
【０１２６】
例えば、ステップＳ３２３の結果、図８（ｃ）に示すルール６０１ｂ，６０２ｂ，６０３ｂが生成されていたとする。ステップＳ３２３の後、共通条件制御手段７は、準備コマンドの情報を含むルールであって、同時に成立し得るルールを選択する。本例では、共通条件制御手段７は、図８（ｃ）に示すルール６０２ｂ，６０３ｂを選択する。そして、共通条件制御手段７は、選択したルールの準備コマンドが競合するか否かを判定する（ステップＳ３２４）。ここでは、ルール６０２ｂにおける「準備Ｂ」とルール６０３ｂにおける「準備Ａ」とが競合するか否かを判定する。
【０１２７】
「準備Ｂ」と「準備Ａ」とが競合しなければ、処理を終了する。「準備Ｂ」と「準備Ａ」とが競合する場合には、共通条件制御手段７は、対処コマンドの情報を含むルール６０２ｂの準備コマンド「準備Ｂ」の情報の前に、その準備コマンドと競合する準備コマンド「準備Ａ」の取消コマンド「取消Ａ」の情報を追加する。この結果得られるルール群の例を図１３に示す。対処コマンドの情報を含むルール６０２ｂの準備コマンドの前に取消コマンド「取消Ａ」を追加したルールを、図１３では、ルール６０２ｃとして示している。
【０１２８】
なお、図１１に示すステップＳ２２７において、図１２に示すステップＳ３２１〜Ｓ３２５の処理を実行してもよい。
【０１２９】
また、図７に示すフローチャートでは、ステップＳ２２２においてＹｅｓと判定した場合、矛盾解消処理（ステップＳ２２３）を実行する。第２の実施の形態の他の変形例として、共通条件制御手段７が、ステップＳ２２２においてＹｅｓと判定した場合、条件式に共通部分を有する各ユーザ指定ルールを、準備コマンドの情報を有するユーザ指定ルールと、対処コマンドの情報を有するユーザ指定ルールに分離し、その後、ステップＳ２２３の処理を実行し、ステップＳ２２５に移行してもよい。
【０１３０】
本変形例では、ステップＳ２２２においてＹｅｓと判定した場合、共通条件制御手段７は、例えば、図８（ａ）に例示するユーザ指定ルール６０１を、条件式が“状態Ａ ＆ 状態Ｂ”であり、「準備Ａ」の情報を含むルールと、条件式が“状態Ａ ＆ 状態Ｂ”であり、「準備Ｂ」の情報を含むルールとに分離する。同様に、図８（ａ）に例示するユーザ指定ルール６０２についても分離する。そして、ステップＳ２２３の処理を実行し、ステップＳ２２５に移行する。
【０１３１】
実施の形態３．
図１４は、本発明の第３の実施の形態を示すブロック図である。第１の実施の形態や第２の実施の形態と同様の構成部については、図１と同一の符号を付し、説明を省略する。ただし、第２の実施の形態では、共通条件制御手段７は、第２の実施の形態における動作に加え、さらに他の動作も行う。また、本実施の形態では、エージェント装置２０は、検出要素制御手段８を備える。
【０１３２】
本実施の形態では、第２の実施の形態と同様に、ユーザ自身が作成したユーザ指定ルールにおける復旧処理コマンドの情報には、対処コマンドおよび準備コマンドの両方の情報が含まれる。また、ユーザ指定ルールに基づいて作成される復旧処理コマンドには、準備コマンドや対処コマンドの他に、検出コマンドが含まれる場合がある。検出コマンドは、サービス実行手段１０の動作状態の検出を動作状態検出手段１に変更させるためのコマンドである。例えば、動作状態検出手段１が、サービス実行手段１０に「状態Ｃ」が発生しているか否かを検出していないとする。この場合、検出要素制御手段８が、検出コマンド（ここでは「検出Ｃ」とする。）を受け取ると、検出要素制御手段８が動作状態検出手段１に対し「状態Ｃ」が発生しているか否かの検出を指示する。動作状態検出手段１は、この指示に応じて「状態Ｃ」が発生しているか否かの検出を開始し、その検出結果を対処方法検索手段３に出力する。
【０１３３】
共通条件制御手段７は、複数のユーザ指定ルールの条件式の共通部分を条件式とし、その複数のユーザ指定ルールの共通部分以外に記述された状態が発生しているか否かを検出するための検出コマンドの情報を含む障害対処ルールを作成する。
【０１３４】
また、共通条件制御手段７は、第１の実施の形態や第２の実施の形態と同様に、ユーザ指定ルールの矛盾を解消して、ユーザ指定ルールが一意に識別されるようにする処理（図４に示すステップＳ３０１〜Ｓ３０８の処理）を実行する。ただし、共通条件制御手段７は、対処コマンドの情報を含むユーザ指定ルールを対象として、上記の矛盾解消処理を行う。従って、検出コマンドの情報を含んでいるが対処コマンドの情報を含んでいないルール等は、矛盾解消処理の対象外となる。
【０１３５】
また、共通条件制御手段７は、第２の実施の形態におけるステップＳ２２４（より具体的には図９に示すステップＳ３２１〜Ｓ３２３）と同様の処理を行い、ユーザ指定ルールから準備コマンドを削除したり、準備コマンドを含む新たな障害対処ルールを作成したりする。
【０１３６】
また、共通条件制御手段７は、導出した各ルールを障害対処ルールとしてルール蓄積手段２に記憶させる前に、条件式が同一であるルールを１つにまとめる処理を行う。
【０１３７】
対処方法検索手段３が、検出コマンドの情報を対話制御手段４に出力し、対話制御手段４もその検出コマンドの情報をコマンド実行手段５に出力したとする。コマンド実行手段５は、検出コマンドの情報を受信した場合には、その情報が示す検出コマンドを検出要素制御手段８に出力する。検出要素制御手段８は、コマンド実行手段５から検出コマンドを受け取ると、その検出コマンドに応じて、動作状態検出手段１に検出する動作を変更させる。例えば、動作状態検出手段１に新たな動作状態の検出を行わせる。
【０１３８】
検出要素制御手段８は、例えば、動作状態検出手段１等と同様に、コンピュータと障害復旧プログラムによって実現することができる。また、検出要素制御手段８をハードウェア装置によって実現してもよい。
【０１３９】
以下、第３の実施の形態の動作について説明する。図１５は、ユーザ指定ルールが修正されたときにおけるマネージャ装置３０（主に共通条件制御手段７）による処理経過の例を示すフローチャートである。図７に示す処理と同様の処理については、図７と同様の符号を付して説明を省略する。
【０１４０】
ステップＳ２２２において、条件式に共通部分を有するユーザ指定ルールがあると判定した場合（ステップＳ２２２におけるＹｅｓ）、共通条件制御手段７は、共通部分を条件式とし、検出コマンドを含む障害対処ルールを作成する（ステップＳ２２２ａ）。図１６は、この検出コマンドを含む障害対処ルール作成処理（ステップＳ２２２ａ）の処理経過の例を示すフローチャートである。共通条件制御手段７は、検出コマンドを含む障害対処ルールを作成する際、まず、ユーザ指定ルール蓄積手段６が記憶するユーザ指定ルールのうち、条件式に共通部分を有するユーザ指定ルールを収集する（ステップＳ３４１）。次に、共通条件制御手段７は、収集したユーザ指定ルールの条件式の共通部分を条件式とし、その各ユーザ指定ルールの条件式の共通部分以外に記述された状態が発生しているか否かを検出するための検出コマンドの情報を含む障害対処ルールを作成する（ステップＳ３４２）。以上の処理によって、ステップＳ２２２ａの処理を終了する。なお、共通部分を有するユーザ指定ルールのグループが複数存在した場合、それらの各グループについて、ステップＳ３４２の処理を実行すればよい。
【０１４１】
ステップＳ２２２ａの後、共通条件制御手段７は、各ユーザ指定ルール間に矛盾がなくなるように、収集したユーザ指定ルールの条件式を変更する（ステップＳ２２３）。この処理は、第２の実施の形態におけるステップＳ２２３（図７参照。）と同様である。すなわち、図４に示すステップＳ３０１〜Ｓ３０８と同様の処理を実行すればよい。ただし、ユーザ指定ルールの収集処理（図４に示すステップＳ３０２）に相当する処理は、図１６に示すステップＳ３４１で実行しているので、ステップＳ３０２の処理は省略してよい。また、本実施の形態では、共通条件制御手段７は、条件式に共通部分を有するユーザ指定ルールであって、対処コマンドの情報を含むユーザ指定ルールを対象として、ステップＳ２２３の矛盾解消処理を行う。上記のステップＳ２２２ａで作成されたルールには、対処コマンドの情報は含まれないので、ステップＳ２２２ａで作成されたルールの条件式が、ステップＳ２２３で変更されることはない。
【０１４２】
ステップＳ２２３の後、共通条件制御手段７は、復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールの作成や、対処コマンドのみを含むようにユーザ指定ルールを変更する処理を実行する（ステップＳ２２４）。この処理は、第２の実施の形態におけるステップＳ２２４（図７参照。）と同様である。すなわち、図９に示すステップＳ３２１〜Ｓ３２３と同様の処理を実行すればよい。ただし、共通条件制御手段７は、ステップＳ２２２ａで作成した検出コマンドの情報を含む障害対処ルールに対しては、何ら処理を行わない。従って、ステップＳ２２２ａで作成されたルールの条件式が、ステップＳ２２４で変更されることはない。
【０１４３】
続いて、共通条件制御手段７は、ステップＳ２２４の結果得られた各ルールと、ステップＳ２２２ａで作成した障害対処ルールのうち、条件式が同一のものがあれば、そのルールを１つのルールにまとめる（ステップＳ２２４ａ）。例えば、条件式が“状態Ａ ＆ 状態Ｂ”であり、「検出Ｃ」という検出コマンドの情報を含むルールと、条件式が“状態Ａ ＆ 状態Ｂ”であり、「準備Ａ」という準備コマンドの情報を含むルールとが存在したとする。この場合、共通条件制御手段７は、この２つのルールをまとめて、条件式が“状態Ａ ＆ 状態Ｂ”であり、「検出Ｃ、準備Ａ」を含むルールを作成する。
【０１４４】
ステップＳ２２４ａにおいてまとめられるルールをまとめた後、各ルールを、障害対処ルールとしてルール蓄積手段２に記憶させる（ステップＳ２２５）。なお、このとき、条件式に他のユーザ指定ルールとの共通部分がないユーザ指定ルールが存在していた場合、共通条件制御手段７は、そのユーザ指定ルールについては、そのまま障害対処ルールとしてルール蓄積手段２に記憶させる。
【０１４５】
図１７および図１８を用いて、以上の処理を説明する。図１７および図１８は、ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。ユーザ指定ルール蓄積手段６は、初期状態において、図１７（ａ）に示すユーザ指定ルールを記憶しているとする。そして、ステップＳ２２１において、対話制御手段４が、ユーザの操作に応じて、図１７（ｂ）に示すユーザ指定ルール７０２を追加したとする。すると、ステップＳ２２２ａにおいて、共通条件制御手段７は、ユーザ指定ルール７０１，７０２を収集する。そして、共通条件制御手段７は、その２つのユーザ指定ルール７０１，７０２の条件式の共通部分である“状態Ａ ＆ 状態Ｂ”を条件式とし、ユーザ指定ルール７０１，７０２の条件式の共通部分以外に記述された状態（本例では状態Ｃ）が発生しているか否かを検出するための検出コマンド（「検出Ｃ」とする。）の情報を含む障害対処ルールを作成する。図１７（ｃ）では、このルールを障害対処ルール７５１として示している。
【０１４６】
次のステップＳ２２３では、共通条件制御手段７は、図１７（ｃ）に示すユーザ指定ルール７０１，７０２に基づいて、図１８（ａ）に示すユーザ指定ルール７０１ａ，７０２ａを導出する。この導出過程は、図８（ａ）に示すユーザ指定ルールから図８（ｂ）に示すユーザ指定ルールを導出する過程と同様である。なお、障害対処ルール７５１には対処コマンドの情報が含まれないので、ステップＳ２２３の処理対象とされない。
【０１４７】
次のステップＳ２２４では、共通条件制御手段７は、図１８（ａ）に示すユーザ指定ルール７０１ａ，７０２ａに基づいて、図１８（ｂ）に示すルール７０１ｂ，７０２ｂ，７０３ｂを導出する。この導出過程は、図８（ｂ）に示すユーザ指定ルールから、図８（ｃ）に示す各ルールを導出する過程と同様である。なお、ステップＳ２２４において、共通条件制御手段７は、検出コマンドの情報を含む障害対処ルール７５１に対しては、何ら処理を行わない。
【０１４８】
次の、ステップＳ２２４ａでは、共通条件制御手段７は、ステップＳ２２４で得られた各ルール７０１ｂ，７０２ｂ，７０３ｂと、ステップＳ２２２ａで作成した障害対処ルール７５１のうち、条件式が同一のものがあれば、そのルールを１つにまとめる。本例では、図１８（ｂ）に示す障害対処ルール７５１，７０３ｂの条件式が同一であるので、この２つのルールをまとめ、図１８（ｃ）に示す障害対処ルール７５２を生成する。その後、共通条件制御手段７は、図１８（ｃ）に示す各ルールを障害対処ルールとして、ルール蓄積手段２に記憶させる。
【０１４９】
他の具体例について説明する。図１９および図２０も、ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。ステップＳ２２１の後、ユーザ指定ルール蓄積手段６に、図１９（ａ）に示すユーザ指定ルール８０１，８０２が記憶されているとする。すると、ステップＳ２２２ａにおいて、共通条件制御手段７は、ユーザ指定ルール８０１，８０２を収集する。そして、共通条件制御手段７は、その２つのユーザ指定ルール８０１，８０２の条件式の共通部分である“状態Ａ ＆ 状態Ｂ”を条件式とし、ユーザ指定ルール８０１，８０２の条件式の共通部分以外に記述された状態（本例では状態Ｃ、状態Ｄ）が発生しているか否かを検出するための各検出コマンドの情報を含む障害対処ルールを作成する。ここでは、状態Ｃが発生しているか否かを検出するための検出コマンドを「検出Ｃ」、状態Ｄが発生しているか否かを検出するための検出コマンドを「検出Ｄ」とする。図１９（ｂ）では、このルールを障害対処ルール８５１として示している。
【０１５０】
次のステップＳ２２３では、共通条件制御手段７は、図１９（ｂ）に示すユーザ指定ルール８０１，８０２に基づいて、図２０（ａ）に示すユーザ指定ルール８０１ａ，８０２ａを導出する。なお、障害対処ルール８５１には対処コマンドの情報が含まれないので、ステップＳ２２３の処理対象とされない。
【０１５１】
次のステップＳ２２４では、共通条件制御手段７は、図２０（ａ）に示すユーザ指定ルール８０１ａ，８０２ａに基づいて、図２０（ｂ）に示すルール８０１ｂ，８０２ｂ，８０３ｂを導出する。なお、ステップＳ２２４において、共通条件制御手段７は、検出コマンドの情報を含む障害対処ルール７５１に対しては、何ら処理を行わない。
【０１５２】
ステップＳ２２４ａでは、共通条件制御手段７は、ステップＳ２２４で得られた各ルール８０１ｂ，８０２ｂ，８０３ｂと、ステップＳ２２２ａで作成した障害対処ルール８５１のうち、条件式が同一のものがあれば、そのルールを１つにまとめる。本例では、条件式が同一となるものがないので、ルールをまとめることはない。続いて、共通条件制御手段７は、図２０（ｂ）に示す各ルールを障害対処ルールとして、ルール蓄積手段２に記憶させる。
【０１５３】
なお、図１７に示す具体例では、初期状態として“状態Ａ ＆ 状態Ｂ”を条件式とするユーザ指定ルール７０１が記憶され、続いて、その条件式“状態Ａ ＆ 状態Ｂ”を包含する条件式“状態Ａ ＆ 状態Ｂ ＆ 状態Ｃ”を有するユーザ指定ルール７０２が追加された場合を示している。一方、図１９（ａ）に示すユーザ指定ルール８０１，８０２では、一方の条件式が他方の条件式を包含しているわけではない。
【０１５４】
既に記憶されているユーザ指定ルールの条件式を包含する条件式を有するユーザ指定ルールを追加した場合、元々記憶されていたユーザ指定ルールの条件式全体が、条件式の共通部分となる。例えば、図１７に示す例では、元々記憶されていたユーザ指定ルール７０１の条件式全体（“状態Ａ ＆ 状態Ｂ”）が、追加されたユーザ指定ルール７０２の条件式との共通部分になっている。
【０１５５】
ユーザ（管理者）が、新たにユーザ指定ルールを追加する場合、既にユーザ指定ルール蓄積手段６に記憶されているユーザ指定ルールの条件式を包含する条件式を有するユーザ指定ルールを追加することが多いと考えられる。従って、元々記憶されていたユーザ指定ルールの条件式全体が、条件式の共通部分となることが多いと考えられる。
【０１５６】
あるユーザ指定ルールの条件式全体が、複数のユーザ指定ルールの条件式の共通部分となる場合、図１５に示すステップＳ２２２ａにおいて、以下のような処理を行ってもよい。共通条件制御手段７は、ユーザ指定ルール蓄積手段６が記憶するユーザ指定ルールのうち、条件式に共通部分を有するユーザ指定ルールを収集する。このユーザ指定ルールの中には、条件式全体が、各ユーザ指定ルールの条件式の共通部分となっているユーザ指定ルールが存在する。このユーザ指定ルールをＫとし、ユーザ指定ルールＫの条件式をＪとする。Ｊは、条件式の共通部分でもある。共通条件制御手段７は、Ｊを条件式とし、各ユーザ指定ルールの条件式のうちＪ以外の部分に記述された状態が発生しているか否かを検出するための検出コマンドの情報を含む障害対処ルールを作成する。さらに、共通条件制御手段７は、作成した障害対処ルールに対し、ユーザ指定ルールＫに含まれる準備コマンドの情報も付加する。この結果、検出コマンドおよび準備コマンドの情報を有する障害対処ルールが作成される。また、共通条件制御手段７は、ユーザ指定ルールＫから準備コマンドの情報を削除する。共通条件制御手段７は、以上の処理をステップＳ２２２ａとして行う。
【０１５７】
この後、ステップＳ２２３に移行するが、ステップＳ２２３終了後は、ステップＳ２２４，Ｓ２２４ａの処理を行わずに、ステップＳ２２５に移行する。
【０１５８】
図２１を用いて、以上の処理の具体例を説明する。図２１は、ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。ユーザ指定ルール蓄積手段６は、初期状態において、図２１（ａ）に示すユーザ指定ルール９０１を記憶していて、その後、図２１（ａ）に示すユーザ指定ルール９０２が追加記憶されたとする。本例では、ユーザ指定ルール９０１の条件式全体が、複数のユーザ指定ルール９０１，９０２の条件式の共通部分となる。従って、ユーザ指定ルール９０１が、上記の説明におけるユーザ指定ルールＫとなり、その条件式“状態Ａ ＆ 状態Ｂ”が上記の説明におけるＪに相当する。
【０１５９】
共通条件制御手段７は、ステップＳ２２２ａにおいて、図２１（ａ）に示すユーザ指定ルール９０１，９０２を収集する。そして、共通条件制御手段７は、ユーザ指定ルール９０１の条件式Ｊ（すなわち、“状態Ａ ＆ 状態Ｂ”）を条件式とし、各各ユーザ指定ルールの条件式のうちＪ以外の部分に記述された状態（本例では状態Ｃ）が発生しているか否かを検出するための検出コマンド（「検出Ｃ」とする。）の情報を含む障害対処ルールを作成する。さらに、共通条件制御手段７は、ユーザ指定ルール９０１に含まれる準備コマンドの情報（準備Ａ）を、その障害対処ルールに付加する。この結果得られるルールを、図２１（ｂ）において障害対処ルール９５１として示している。
【０１６０】
また、共通条件制御手段７は、ユーザ指定ルール９０１（ユーザ指定ルールＫ）から準備コマンドの情報を削除する。この結果得られるルールを、図２１（ｂ）において障害対処ルール９０１ａとして示している。図２１（ｂ）は、ステップＳ２２２ａ終了後の各ルールの状態を示している。なお、図２１（ｂ）に示すユーザ指定ルール９０２ａは、図２１（ａ）に示すユーザ指定ルール９０１と同一である。
【０１６１】
次のステップＳ２２３では、共通条件制御手段７は、図２１（ｂ）に示すユーザ指定ルール９０１ａ，９０２ａに基づいて、図２１（ｃ）に示すユーザ指定ルール９０１ｂ，９０２ｂを導出する。なお、障害対処ルール９５１には対処コマンドの情報が含まれないので、ステップＳ２２３の処理対象とされない。
【０１６２】
本例では、ステップＳ２２４，Ｓ２２４ａの処理を行わない。よって、ステップＳ２２３の結果得られた各ルール（図２１（ｃ）参照。）を障害対処ルールとしてルール蓄積手段２に記憶させる。
【０１６３】
次に、本実施の形態における障害復旧動作の例について説明する。本実施の形態における障害復旧動作は、図６に示す動作と同様である。ただし、ステップＳ２０３において、復旧処理コマンドを実行する旨が入力され、対話制御手段４は、その復旧処理コマンドの情報をコマンド実行手段５に送信するときに、復旧処理コマンドの情報として検出コマンドの情報が含まれていたとする。この場合、対話制御手段４は、検出コマンドを含む復旧処理コマンドの情報を送信し、コマンド実行手段５は、その情報を受信する。コマンド実行手段５は、受信した情報が示す復旧処理コマンドのうち、準備コマンド、対処コマンドについては、第１の実施の形態と同様に、サービス実行手段１０上でそれらのコマンドを実行する（ステップＳ２０４）。ただし、コマンド実行手段５は、検出コマンドについては、ステップＳ２０４で検出要素制御手段８に出力する。
【０１６４】
検出要素制御手段８は、コマンド実行手段５が出力する検出コマンドに応じて、動作状態検出手段１に動作状態検出手段１に検出する動作状態を変更させる。すると、動作状態検出手段１は、新たにサービス実行手段１０の動作状態を検出し、その動作状態の情報を対処方法検索手段３に送信する（ステップＳ２０１）。以降、同様の動作を繰り返す。
【０１６５】
以下に、具体例を示す。図２１（ｃ）に示すルール９０１ｂ，９０２ｂ，９５１が障害対処ルールとして、ルール蓄積手段２に記憶されているものとする。
【０１６６】
動作状態検出手段１は、サービス実行手段１０の動作状態として「状態Ａかつ状態Ｂ」を検出すると、その動作状態の情報を対処方法検索手段３に送信する（ステップＳ２０１）。対処方法検索手段３は、その動作状態の情報を受信し、ルール蓄積手段２に蓄積されている各障害対処ルールの中に、条件式が満たされている障害対処ルールがあるか否かを判定する（ステップＳ２０２）。本例では、図２１（ｃ）に示す障害対処ルール９５１の条件式が満たされる（ステップＳ２０２におけるＹｅｓ）。そこで、対処方法検索手段３は、障害対処ルール９５１に含まれる「検出Ｃ、準備Ａ」という復旧処理コマンドの情報を、対話制御手段４に出力する。対話制御手段４は、「検出Ｃ、準備Ａ」を実行する旨の指示をユーザから受けると（ステップＳ２０３におけるＹｅｓ）、「検出Ｃ、準備Ａ」という情報をコマンド実行手段５に送信する。コマンド実行手段５は、サービス実行手段１０上で「準備Ａ」を実行するとともに、検出コマンドである「検出Ｃ」を検出要素制御手段８に出力する（ステップ２０４）。
【０１６７】
検出要素制御手段８は、この検出コマンド「検出Ｃ」を受け取り、動作状態検出手段１に状態検出方法の変更を指示する。本例では、「検出Ｃ」を受け取った場合は、動作状態検出手段１に対して、新たに「状態Ｃ」が発生しているか否かを検出するようにに指示するものとする。動作状態検出手段１は、この指示に応じて「状態Ｃ」が生じているか否かの検出を開始し、その検出結果を対処方法検索手段３に送信する（ステップ２０１）。このとき、対処方法検索手段３は、既に「状態Ａかつ状態Ｂ」が生じていることを認識している。従って、「状態Ｃ」の真偽によって、対処方法検索手段３は、図２１（ｃ）に示す障害対処ルール９０１ｂ，９０２ｂのいずれの条件式が満たされているかを判定する（ステップＳ２０２）。そして、条件式が満たされている方の障害対処ルールに含まれる復旧処理コマンドの情報（「対処Ａ」または「準備Ｂ、対処Ｂ」）を出力する。対話制御手段４は、その復旧処理コマンドを実行するか否かの決定をユーザに促し、復旧処理コマンドを実行する旨の指示を受けたならば（ステップＳ２０３におけるＹｅｓ）、復旧処理コマンドの情報をコマンド実行手段５に送信する。コマンド実行手段５は、受信した情報が示す復旧処理コマンド（ここでは「対処Ａ」または「準備Ｂ、対処Ｂ」）をサービス実行手段１０上で実行する（ステップＳ２０４）。
【０１６８】
このように本実施の形態によれば、第１、第２の実施の形態で説明した条件式の修正に加えて、動作状態検出手段１が検出対象とする動作状態を変更することができる。例えば、図２１に示すユーザ指定ルール９０２が追加される前では、動作状態検出手段１は、「状態Ａ」が生じているか否かおよび「状態Ｂ」が生じているか否かを検出していればよかった。新たに図２１に示すユーザ指定ルール９０２の追加に伴い、仮に障害対処ルール９０１ｂ，９０２ｂだけがルール蓄積手段２に追加されると、「状態Ｃ」が発生しているか否かについても検出しなければならないため、エージェント装置２０の処理負荷が大きくなる。このように、障害対処ルールの数が増加すると、検出すべき要素の種類も増加し、障害復旧システムの処理負荷が大きくなり、その結果、サービス実行手段１０の効率低下を引き起こす場合がある。本実施の形態では、共通条件制御手段７が、ユーザ指定ルールの条件式の共通部分を条件式とし、その各ユーザ指定ルールの条件式の共通部分以外に記述された状態が発生しているか否かを検出するための検出コマンドの情報を含む障害対処ルールを作成する。従って、常時監視する動作状態は、条件式の共通部分に記述された動作状態のみとすることができる。そして、各条件式の共通部分に相当する条件が満たされたときに、対処方法検索手段３が、各条件式の共通部分を条件式とする障害対処ルールに含まれる検出コマンドの情報を出力し、その検出コマンドに応じた動作状態の検出が開始される。このように、常時監視する動作状態を、条件式の共通部分に記述された動作状態のみとすることができるので、障害復旧システム（特にエージェント装置２０）の監視負荷を大幅に低減することができる。
【０１６９】
また、上記の第３の実施の形態の説明では、ステップＳ２０２（図６参照。）において、対処方法検索手段３が、ルール蓄積手段２に蓄積されている各障害対処ルールの中に、条件式が満たされている障害対処ルールがあるか否かを判定するものとして説明した。対処方法検索手段３は、条件式が満たされているか否かを判定する際、ルール蓄積手段２に記憶されている障害対処ルールの一部を判定の対象外とし、条件式が満たされた障害対処ルールが生じたときに、条件式が満たされているか否かの判定対象となる障害対処ルールを増加していってもよい。具体的には、対処方法検索手段３は、検出コマンドの情報が復旧処理コマンドの情報として含まれている障害対処ルールが存在する場合、その検出コマンドによって検出が開始される動作状態を条件式に含む障害対処ルールを、条件式が満たされているか否かの判定対象から外していてもよい。そして、検出コマンドの情報が復旧処理コマンドの情報として含まれている障害対処ルールの条件式が満たされた後、その検出コマンドによって検出が開始される動作状態を条件式に含む障害対処ルールを、条件式が満たされているか否かの判定対象に含めてもよい。
【０１７０】
例えば、図２１（ｃ）に示す３つの障害対処ルール９０１ｂ，９０２ｂ，９５１が、ルール蓄積手段２に記憶されているとする。この場合、検出コマンドの情報「検出Ｃ」が含まれている障害対処ルール９５１が存在する。従って、対処方法検索手段３は、当初、「検出Ｃ」によって検出が開始される動作状態（本例では、“状態Ｃ”、“ＮＯＴ状態Ｃ”）を条件式に含む障害対処ルール９０１ｂ，９０２ｂを、条件式が満たされているか否かの判定対象から外していてもよい。このとき、対処方法検索手段３は、図２１（ｃ）に示す全ての障害対処ルールについて、条件式が満たされているか否かを判定する必要がないので、対処方法検索手段３の処理負荷は軽減される。
【０１７１】
その後、「検出Ｃ」という情報を含む障害対処ルール９５１の条件式が満たされた後、対処方法検索手段３は、その検出コマンドによって検出が開始される動作状態（“状態Ｃ”、“ＮＯＴ状態Ｃ”）を条件式に含む障害対処ルール９０１ｂ，９０２ｂを、条件式が満たされているか否かの判定対象に含める。
【０１７２】
このように、条件式が満たされているか否かの判定対象外となる障害対処ルールを定めておき、条件式が満たされた障害対処ルールが生じたときに、条件式が満たされているか否かの判定対象となる障害対処ルールを増加させることにより、当初は、条件式が満たされているか否かの判定対象となる障害対処ルールの数を抑えることができ、対処方法検索手段３の処理負荷を抑えることができる。
【０１７３】
また、上記の説明では、コマンド実行手段５が検出コマンドの情報を受信して検出要素制御手段８に対して検出コマンドを出力することにより、検出要素制御手段８が、動作状態検出手段１に、検出コマンドに応じた動作状態が発生しているか否かの検出開始を指示する場合を示した。すなわち、検出コマンドが、その検出コマンドに応じた動作状態の検出開始のトリガとなるものとして説明した。検出コマンドの情報を含む障害対処ルールの条件式が満たされている間は、対処方法検索手段１から、対処制御手段４、コマンド実行手段５、検出要素制御手段８を介して、動作状態検出手段１に検出クエリを出力し続けてもよい。そして、動作状態検出手段１は、検出クエリが出力され続けている間、その検出クエリに応じた動作状態が発生しているか否かを検出する構成であってもよい。ただし、対話制御手段４が、検出クエリを出力しない旨の指示を受けた場合には、対話制御手段４は、検出クエリの出力を停止する。
【０１７４】
また、検出コマンドの情報の含む障害対処ルールの条件式が満たされなくなった時には、対処方法検索手段３は、その検出コマンドに応じて開始された動作状態の検出を中止させる中止コマンドの情報を出力してもよい。対話制御手段４は、他のコマンドの情報と同様に、中止コマンドの情報をコマンド実行手段に送信する。コマンド実行手段５は、中止コマンドの情報を受信した場合、その中止コマンドを検出要素制御手段８に出力する。検出要素制御手段８は、中止コマンドを受けると、その中止コマンドに対応する動作状態の検出中止を動作状態検出手段１に指示する。動作状態検出手段１は、この指示に応じて、動作状態が発生しているか否かの検出を中止する。
【０１７５】
例えば、状態Ａおよび状態Ｂが真となり、図２１（ｃ）に示す障害対処ルール９５１に基づいて、対処方法検索手段３が、「検出Ｃ、準備Ａ」という情報を出力したとする。その結果、動作状態検出手段１は、「状態Ｃ」が発生しているか否かの検出を開始する。その後、状態Ａおよび状態Ｂのいずれかが偽（発生していない状態）となり、障害対処ルール９５１の条件式が満たされなくなったとする。このとき、対処方法検索手段３は、「状態Ｃ」が発生しているか否かの検出を中止させる中止コマンドの情報を対話制御手段４に出力する。対話制御手段４は、他のコマンドの情報と同様に、この中止コマンドの情報をコマンド実行手段５に送信する。コマンド実行手段５は、この情報を受信すると、「状態Ｃ」が発生しているか否かの検出を中止させる中止コマンドを検出要素制御手段８に出力する。すると、検出要素制御手段８は、「状態Ｃ」が発生しているか否かの検出の中止を動作状態検出手段１に出力し、動作状態検出手段１は、「状態Ｃ」が発生しているか否かの検出を中止する。
【０１７６】
検出クエリを出力したり、中止コマンドを出力したりする場合であっても、第３の実施の形態と同様の効果を得ることができる。
【０１７７】
なお、上記の各実施の形態では、マネージャ装置３０とエージェント装置２０とを備える構成として説明したが、マネージャ装置３０とエージェント装置２０とを一体化した装置として、障害復旧システムを実現してもよい。
【図面の簡単な説明】
【０１７８】
【図１】本発明の第１の実施の形態を示すブロック図である。
【図２】ユーザ指定ルールが修正されたときにおけるマネージャ装置による処理経過の例を示すフローチャートである。
【図３】ユーザ指定ルールに基づく矛盾解消の具体例を示す説明図である。
【図４】ユーザ指定ルール間に矛盾がなくなるように、ユーザ指定ルールの条件式を変更することによって障害対処ルールを作成する処理の一例を示すフローチャートである。
【図５】条件式に共通部分を有するユーザ指定ルールが３つある場合における矛盾解消の具体例を示す説明図である。
【図６】サービス実行手段の状態検出から復旧処理コマンド実行までの処理経過を示すフローチャートである。
【図７】ユーザ指定ルールが修正されたときにおけるマネージャ装置による処理経過の例を示すフローチャートである。
【図８】ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。
【図９】復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールの作成や、対処コマンドのみを含むようにユーザ指定ルールを変更する処理の一例を示す説明図である。
【図１０】ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。
【図１１】第２の実施の形態の変形例におけるマネージャ装置による処理経過の例を示すフローチャートである。
【図１２】復旧処理コマンドの情報として準備コマンドのみを含む障害対処ルールの作成や、対処コマンドのみを含むようにユーザ指定ルールを変更する処理の一例を示す説明図である。
【図１３】取消コマンドが追加されたルールを含むルール群の例を示す説明図である。
【図１４】本発明の第３の実施の形態を示すブロック図である。
【図１５】ユーザ指定ルールが修正されたときにおけるマネージャ装置による処理経過の例を示すフローチャートである。
【図１６】検出コマンドを含む障害対処ルール作成の処理経過の例を示すフローチャートである。
【図１７】ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。
【図１８】ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。
【図１９】ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。
【図２０】ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。
【図２１】ユーザ指定ルールに基づく障害対処ルール生成過程の具体例を示す説明図である。
【図２２】管理者が障害対処ルールを追加する状況を示す説明図である。
【図２３】管理者によって変更された障害対処ルールの例を示す説明図である。
【図２４】管理者によって変更された障害対処ルールの例を示す説明図である。
【符号の説明】
【０１７９】
１ 動作状態検出手段
２ ルール蓄積手段
３ 対処方法検索手段
４ 対話制御手段
５ コマンド実行手段
６ ユーザ指定ルール蓄積手段
７ 共通条件制御手段
８ 検出要素制御手段
１０ サービス実行手段
２０ エージェント装置
３０ マネージャ装置
【特許請求の範囲】
【請求項１】
情報処理システムの動作状態が、予め作成されたルールの条件式を満足する場合に、条件式が満たされたルールが定める復旧処理コマンドを実行する障害復旧システムであって、
障害発生または障害発生の前兆と見なされる情報処理システムの動作状態を条件式とし、復旧処理コマンドの情報を有するルールであって、ユーザによって作成されたルールであるユーザ指定ルールを記憶するユーザ指定ルール蓄積手段と、
条件式に共通部分を有する各ユーザ指定ルールの条件式が同時に満足されないように、前記ユーザ指定ルールの条件式を変更したルールを作成する同時不成立ルール作成手段とを備えた
ことを特徴とする障害復旧システム。
【請求項２】
ユーザ指定ルール蓄積手段は、復旧処理コマンドの情報として、障害からの復旧または障害回避のための対処コマンドおよび前記対処コマンド実行の準備を行うための準備コマンドの情報を有するユーザ指定ルールを記憶し、
ユーザ指定ルールの条件式を変更したルールとして同時不成立ルール作成手段に作成されたルールから準備コマンドの情報を削除するとともに、条件式に共通部分を有する各ユーザ指定ルールにおける前記共通部分を条件式とし、条件式を変更することによって作成されたルールの元となったユーザ指定ルールが有する準備コマンドの情報を有する準備ルールを作成する準備ルール作成手段を備えた
請求項１に記載の障害復旧システム。
【請求項３】
準備ルール作成手段は、同時不成立ルール作成手段が作成したルールに基づいて選択された対処コマンドの実行に失敗した場合に、ユーザ指定ルールの条件式を変更したルールとして同時不成立ルール作成手段に作成されたルールから準備コマンドの情報を削除するとともに、条件式に共通部分を有する各ユーザ指定ルールにおける前記共通部分を条件式とし、条件式を変更することによって作成されたルールの元となったユーザ指定ルールが有する準備コマンドの情報を有する準備ルールを作成する
請求項２に記載の障害復旧システム。
【請求項４】
準備コマンドおよび対処コマンドの情報を有する準備対処ルールと、準備コマンドの情報を有する準備ルールの条件式が同時に成立することがあり、準備コマンド同士が競合すると定められている場合に、前記準備対処ルールに、前記準備ルールの準備コマンドの実行取消を指示する取消コマンドの情報を付加する取消コマンド情報付加手段を備えた
請求項２または請求項３に記載の障害復旧システム。
【請求項５】
条件式に共通部分を有する各ユーザ指定ルールにおける前記共通部分を条件式とし、前記各ユーザ指定ルールの条件式のうち前記共通部分以外に示される動作状態が発生しているか否かの検出を指示する検出コマンドの情報を有する検出ルールを作成する検出ルール作成手段を備えた
請求項２に記載の障害復旧システム。
【請求項６】
一のユーザ指定ルールの条件式全体が、複数のユーザ指定ルールの条件式の共通部分となっている場合に、前記共通部分を条件式とし、前記複数のユーザ指定ルールの条件式のうち前記共通部分以外に示される動作状態が発生しているか否かの検出を指示する検出コマンドの情報と、前記一のユーザ指定ルールが有する準備コマンドの情報とを有する検出ルールを作成するとともに、前記一のユーザ指定ルールから準備コマンドの情報を削除したルールを作成する検出ルール作成手段を備えた
請求項１に記載の障害復旧システム。
【請求項７】
情報処理システムの動作状態を検出する動作状態検出手段と、
前記動作状態検出手段によって検出された動作状態によって条件式が満足されるルールを特定し、前記ルールが有する復旧処理コマンドの情報を出力する対処方法検索手段と、
前記対処方法検索手段が復旧処理コマンドの情報として検出コマンドの情報を出力した場合に、前記検出コマンドに応じた動作状態が前記情報処理システムに発生しているか否かの検出を前記動作状態検出手段に指示する検出要素制御手段とを備えた
請求項５または請求項６に記載の障害復旧システム。
【請求項８】
情報処理システムの動作状態を検出する動作状態検出手段と、
前記動作状態検出手段によって検出された動作状態によって条件式が満足されるルールを特定し、前記ルールが有する復旧処理コマンドの情報を出力する対処方法検索手段とを備え、
前記対処方法検索手段は、検出ルールの条件式が満足されるまでは、前記検出ルールが有する検出コマンドの情報に対応する動作状態を条件式に含むルールを、条件式が満足されているか否かの判定対象から外す
請求項５から請求項７のうちのいずれか１項に記載の障害復旧システム。
【請求項９】
情報処理システムの動作状態が、予め作成されたルールの条件式を満足する場合に、条件式が満たされたルールが定める復旧処理コマンドの情報を出力する障害復旧装置であって、
障害発生または障害発生の前兆と見なされる情報処理システムの動作状態を条件式とし、復旧処理コマンドの情報を有するルールであって、ユーザによって作成されたルールであるユーザ指定ルールを記憶するユーザ指定ルール蓄積手段と、
条件式に共通部分を有する各ユーザ指定ルールの条件式が同時に満足されないように、前記ユーザ指定ルールの条件式を変更したルールを作成する同時不成立ルール作成手段とを備えた
ことを特徴とする障害復旧装置。
【請求項１０】
情報処理システムに対し復旧処理コマンドを実行することにより前記情報処理システムに障害からの復旧または障害の回避を行わせる障害復旧装置であって、
前記情報処理システムの動作状態を検出する動作状態検出手段と、
復旧処理コマンドの情報を受信し、前記情報が示す復旧処理コマンドを実行するコマンド実行手段と、
コマンド実行手段が、復旧処理コマンドとして、所定の動作状態が発生しているか否かの検出を指示する検出コマンドを受信した場合に、前記動作状態が前記情報処理システムに発生しているか否かの検出を前記動作状態検出手段に指示する検出要素制御手段とを備えた
ことを特徴とする障害復旧装置。
【請求項１１】
情報処理システムの動作状態が、予め作成されたルールの条件式を満足する場合に、条件式が満たされたルールが定める復旧処理コマンドを実行する障害復旧システムに適用されるルール作成方法であって、
ユーザ指定ルール蓄積手段が、障害発生または障害発生の前兆と見なされる情報処理システムの動作状態を条件式とし、復旧処理コマンドの情報を有するルールであって、ユーザによって作成されたルールであるユーザ指定ルールを記憶し、
同時不成立ルール作成手段が、条件式に共通部分を有する各ユーザ指定ルールの条件式が同時に満足されないように、前記ユーザ指定ルールの条件式を変更したルールを作成する
ことを特徴とするルール作成方法。
【請求項１２】
情報処理システムの動作状態が、予め作成されたルールの条件式を満足する場合に、条件式が満たされたルールが定める復旧処理コマンドの情報を出力するコンピュータであって、障害発生または障害発生の前兆と見なされる情報処理システムの動作状態を条件式とし、復旧処理コマンドの情報を有するルールであって、ユーザによって作成されたルールであるユーザ指定ルールを記憶するユーザ指定ルール蓄積手段を備えたコンピュータに、
条件式に共通部分を有する各ユーザ指定ルールの条件式が同時に満足されないように、前記ユーザ指定ルールの条件式を変更したルールを作成する同時不成立ルール作成処理
を実行させるための障害復旧プログラム。
【請求項１３】
情報処理システムに対し復旧処理コマンドを実行することにより前記情報処理システムに障害からの復旧または障害の回避を行わせるコンピュータに、
前記情報処理システムの動作状態を検出する動作状態検処理、
復旧処理コマンドの情報を受信し、前記情報が示す復旧処理コマンドを実行するコマンド実行処理、および
復旧処理コマンドとして、所定の動作状態が発生しているか否かの検出を指示する検出コマンドを受信した場合に、前記動作状態が前記情報処理システムに発生しているか否かの検出を前記動作状態検処理で開始させる検出要素制御処理
を実行させるための障害復旧プログラム。
【請求項１】
情報処理システムの動作状態が、予め作成されたルールの条件式を満足する場合に、条件式が満たされたルールが定める復旧処理コマンドを実行する障害復旧システムであって、
障害発生または障害発生の前兆と見なされる情報処理システムの動作状態を条件式とし、復旧処理コマンドの情報を有するルールであって、ユーザによって作成されたルールであるユーザ指定ルールを記憶するユーザ指定ルール蓄積手段と、
条件式に共通部分を有する各ユーザ指定ルールの条件式が同時に満足されないように、前記ユーザ指定ルールの条件式を変更したルールを作成する同時不成立ルール作成手段とを備えた
ことを特徴とする障害復旧システム。
【請求項２】
ユーザ指定ルール蓄積手段は、復旧処理コマンドの情報として、障害からの復旧または障害回避のための対処コマンドおよび前記対処コマンド実行の準備を行うための準備コマンドの情報を有するユーザ指定ルールを記憶し、
ユーザ指定ルールの条件式を変更したルールとして同時不成立ルール作成手段に作成されたルールから準備コマンドの情報を削除するとともに、条件式に共通部分を有する各ユーザ指定ルールにおける前記共通部分を条件式とし、条件式を変更することによって作成されたルールの元となったユーザ指定ルールが有する準備コマンドの情報を有する準備ルールを作成する準備ルール作成手段を備えた
請求項１に記載の障害復旧システム。
【請求項３】
準備ルール作成手段は、同時不成立ルール作成手段が作成したルールに基づいて選択された対処コマンドの実行に失敗した場合に、ユーザ指定ルールの条件式を変更したルールとして同時不成立ルール作成手段に作成されたルールから準備コマンドの情報を削除するとともに、条件式に共通部分を有する各ユーザ指定ルールにおける前記共通部分を条件式とし、条件式を変更することによって作成されたルールの元となったユーザ指定ルールが有する準備コマンドの情報を有する準備ルールを作成する
請求項２に記載の障害復旧システム。
【請求項４】
準備コマンドおよび対処コマンドの情報を有する準備対処ルールと、準備コマンドの情報を有する準備ルールの条件式が同時に成立することがあり、準備コマンド同士が競合すると定められている場合に、前記準備対処ルールに、前記準備ルールの準備コマンドの実行取消を指示する取消コマンドの情報を付加する取消コマンド情報付加手段を備えた
請求項２または請求項３に記載の障害復旧システム。
【請求項５】
条件式に共通部分を有する各ユーザ指定ルールにおける前記共通部分を条件式とし、前記各ユーザ指定ルールの条件式のうち前記共通部分以外に示される動作状態が発生しているか否かの検出を指示する検出コマンドの情報を有する検出ルールを作成する検出ルール作成手段を備えた
請求項２に記載の障害復旧システム。
【請求項６】
一のユーザ指定ルールの条件式全体が、複数のユーザ指定ルールの条件式の共通部分となっている場合に、前記共通部分を条件式とし、前記複数のユーザ指定ルールの条件式のうち前記共通部分以外に示される動作状態が発生しているか否かの検出を指示する検出コマンドの情報と、前記一のユーザ指定ルールが有する準備コマンドの情報とを有する検出ルールを作成するとともに、前記一のユーザ指定ルールから準備コマンドの情報を削除したルールを作成する検出ルール作成手段を備えた
請求項１に記載の障害復旧システム。
【請求項７】
情報処理システムの動作状態を検出する動作状態検出手段と、
前記動作状態検出手段によって検出された動作状態によって条件式が満足されるルールを特定し、前記ルールが有する復旧処理コマンドの情報を出力する対処方法検索手段と、
前記対処方法検索手段が復旧処理コマンドの情報として検出コマンドの情報を出力した場合に、前記検出コマンドに応じた動作状態が前記情報処理システムに発生しているか否かの検出を前記動作状態検出手段に指示する検出要素制御手段とを備えた
請求項５または請求項６に記載の障害復旧システム。
【請求項８】
情報処理システムの動作状態を検出する動作状態検出手段と、
前記動作状態検出手段によって検出された動作状態によって条件式が満足されるルールを特定し、前記ルールが有する復旧処理コマンドの情報を出力する対処方法検索手段とを備え、
前記対処方法検索手段は、検出ルールの条件式が満足されるまでは、前記検出ルールが有する検出コマンドの情報に対応する動作状態を条件式に含むルールを、条件式が満足されているか否かの判定対象から外す
請求項５から請求項７のうちのいずれか１項に記載の障害復旧システム。
【請求項９】
情報処理システムの動作状態が、予め作成されたルールの条件式を満足する場合に、条件式が満たされたルールが定める復旧処理コマンドの情報を出力する障害復旧装置であって、
障害発生または障害発生の前兆と見なされる情報処理システムの動作状態を条件式とし、復旧処理コマンドの情報を有するルールであって、ユーザによって作成されたルールであるユーザ指定ルールを記憶するユーザ指定ルール蓄積手段と、
条件式に共通部分を有する各ユーザ指定ルールの条件式が同時に満足されないように、前記ユーザ指定ルールの条件式を変更したルールを作成する同時不成立ルール作成手段とを備えた
ことを特徴とする障害復旧装置。
【請求項１０】
情報処理システムに対し復旧処理コマンドを実行することにより前記情報処理システムに障害からの復旧または障害の回避を行わせる障害復旧装置であって、
前記情報処理システムの動作状態を検出する動作状態検出手段と、
復旧処理コマンドの情報を受信し、前記情報が示す復旧処理コマンドを実行するコマンド実行手段と、
コマンド実行手段が、復旧処理コマンドとして、所定の動作状態が発生しているか否かの検出を指示する検出コマンドを受信した場合に、前記動作状態が前記情報処理システムに発生しているか否かの検出を前記動作状態検出手段に指示する検出要素制御手段とを備えた
ことを特徴とする障害復旧装置。
【請求項１１】
情報処理システムの動作状態が、予め作成されたルールの条件式を満足する場合に、条件式が満たされたルールが定める復旧処理コマンドを実行する障害復旧システムに適用されるルール作成方法であって、
ユーザ指定ルール蓄積手段が、障害発生または障害発生の前兆と見なされる情報処理システムの動作状態を条件式とし、復旧処理コマンドの情報を有するルールであって、ユーザによって作成されたルールであるユーザ指定ルールを記憶し、
同時不成立ルール作成手段が、条件式に共通部分を有する各ユーザ指定ルールの条件式が同時に満足されないように、前記ユーザ指定ルールの条件式を変更したルールを作成する
ことを特徴とするルール作成方法。
【請求項１２】
情報処理システムの動作状態が、予め作成されたルールの条件式を満足する場合に、条件式が満たされたルールが定める復旧処理コマンドの情報を出力するコンピュータであって、障害発生または障害発生の前兆と見なされる情報処理システムの動作状態を条件式とし、復旧処理コマンドの情報を有するルールであって、ユーザによって作成されたルールであるユーザ指定ルールを記憶するユーザ指定ルール蓄積手段を備えたコンピュータに、
条件式に共通部分を有する各ユーザ指定ルールの条件式が同時に満足されないように、前記ユーザ指定ルールの条件式を変更したルールを作成する同時不成立ルール作成処理
を実行させるための障害復旧プログラム。
【請求項１３】
情報処理システムに対し復旧処理コマンドを実行することにより前記情報処理システムに障害からの復旧または障害の回避を行わせるコンピュータに、
前記情報処理システムの動作状態を検出する動作状態検処理、
復旧処理コマンドの情報を受信し、前記情報が示す復旧処理コマンドを実行するコマンド実行処理、および
復旧処理コマンドとして、所定の動作状態が発生しているか否かの検出を指示する検出コマンドを受信した場合に、前記動作状態が前記情報処理システムに発生しているか否かの検出を前記動作状態検処理で開始させる検出要素制御処理
を実行させるための障害復旧プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【公開番号】特開２００６−２４４４０４（Ｐ２００６−２４４４０４Ａ）
【公開日】平成１８年９月１４日（２００６．９．１４）
【国際特許分類】
【出願番号】特願２００５−６２８１７（Ｐ２００５−６２８１７）
【出願日】平成１７年３月７日（２００５．３．７）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成１８年９月１４日（２００６．９．１４）
【国際特許分類】
【出願日】平成１７年３月７日（２００５．３．７）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]