(57)【要約】【課題】障害要因となるコンポーネントをより確実に特定する。【解決手段】１つまたは複数の機能を、前記機能を利用して処理を行う処理コンポーネントに提供するサービスコンポーネントを管理する管理プログラムは、障害情報を受信する受信ステップと、障害情報に基づき障害の発生した機能を特定するステップと、特定した機能を利用するために必要な制約条件を読み出すステップと、前記制約条件の成立性を評価するための情報を収集するステップと、収集した情報に基づいて、前記制約条件が成立するか否かを評価するステップと、前記制約条件の成否が、前記サービスコンポーネントの状態、前記処理コンポーネントの状態、および、これらの両方の状態、のうちどの項目に依存するかを記述した依存情報を読み出すステップと、前記制約条件が成立しないとき、前記依存情報に記述された項目に関連するコンポーネントを障害要因コンポーネントとして特定するステップとを備える。【選択図】図２
2010009127.tif 000002
【特許請求の範囲】
【請求項１】
１つまたは複数の機能を、前記機能を利用して処理を行う処理コンポーネントに提供するサービスコンポーネントを管理する管理プログラムであって、
前記処理コンポーネントが前記機能を利用する際に発生した障害の内容を表す障害情報を、前記障害情報の送信を行う障害情報送信装置から受信する障害情報受信ステップと、
前記障害情報に基づき、前記サービスコンポーネントが提供する機能のうち、障害の発生した機能を特定する機能特定ステップと、
特定した機能を利用するために必要な制約条件を記述した制約条件情報を第１の記憶装置から読み出す第１の読み出しステップと、
前記制約条件情報に記述された前記制約条件の成立性を評価するための情報を収集する情報収集ステップと、
収集した情報に基づいて、前記制約条件が成立するか否かを評価する条件評価ステップと、
前記制約条件の成否が、前記サービスコンポーネントの状態、前記処理コンポーネントの状態、および、前記サービスコンポーネントの状態と前記処理コンポーネントの状態の両方、のうちどの項目に依存するかを記述した依存情報を第２の記憶装置から読み出す第２の読み出しステップと、
前記制約条件が成立しないとき、前記依存情報に記述された項目に関連するコンポーネントを障害要因コンポーネントとして特定する障害要因特定ステップと、
をコンピュータに実行させるための管理プログラム。
【請求項２】
前記制約条件は、１つ以上の制約式の論理積を含み、
前記依存情報は、前記制約式がそれぞれ、各前記項目のいずれに依存するのかを記述し、
前記条件評価ステップは、前記論理積の真偽を評価し、評価が真のとき前記制約条件が成立し、偽のとき前記制約条件が成立しないと判断し、
前記障害要因特定ステップは、前記制約条件が成立しないとき、前記制約条件に含まれる前記制約式のうち偽である制約式に対応する前記項目に関連するコンポーネントを前記障害要因コンポーネントとして特定する
ことを特徴とする請求項１に記載の管理プログラム。
【請求項３】
前記サービスコンポーネントに対して行うことで、発生した障害を復旧するサービスコンポーネント復旧操作と、
前記サービスコンポーネント復旧操作の実行を禁止するための禁止条件と、
前記サービスコンポーネントおよび前記処理コンポーネントの管理者の許可なしに前記サービスコンポーネント復旧操作の自動実行を許可するための許可条件と、
を関連づけた操作制御情報を前記制約条件に対応して第３の記憶装置から読み出す第３の読み出しステップと、
前記障害要因コンポーネントが前記サービスコンポーネントおよび前記処理コンポーネントの両方であるとき、前記禁止条件および前記許可条件が成立するか否かを評価する第２の条件評価ステップと、
前記禁止条件および前記許可条件の成立有無に従って、前記発生した障害を復旧するための復旧操作を行うべき復旧対象コンポーネントを判定する復旧判定ステップと、
をさらに前記コンピュータに実行させることを特徴とする請求項１または２に記載の管理プログラム。
【請求項４】
前記復旧判定ステップは、
前記禁止条件が成立するとき、前記復旧対象コンポーネントは前記処理コンポーネントであると判定し、
前記禁止条件が成立せず、かつ前記許可条件が成立するとき、前記復旧対象コンポーネントは前記サービスコンポーネントであると判定し、
前記禁止条件が成立せず、かつ前記許可条件が成立しないとき、前記復旧対象コンポーネントを前記サービスコンポーネントおよび前記処理コンポーネントの管理者に判断させることを決定する
ことを特徴とする請求項３に記載の管理プログラム。
【請求項５】
前記復旧対象コンポーネントが前記サービスコンポーネントであると判定されたとき、前記サービスコンポーネント復旧操作を自動実行する操作実行ステップ
をさらに前記コンピュータに実行させることを特徴とする請求項４に記載のシステム管理プログラム。
【請求項６】
前記復旧判定ステップは、
前記許可条件が成立するとき、前記復旧対象コンポーネントは前記サービスコンポーネントであると判定し、
前記許可条件が成立せず、かつ前記禁止条件が成立するとき、前記復旧対象コンポーネントは前記処理コンポーネントであると判定し、
前記許可条件が成立せず、かつ前記禁止条件が成立しないとき、前記復旧対象コンポーネントを前記サービスコンポーネントおよび前記処理コンポーネントの管理者に判断させることを決定する
ことを特徴とする請求項３に記載の管理プログラム。
【請求項７】
前記復旧対象コンポーネントが前記サービスコンポーネントであると判定されたとき、前記サービスコンポーネント復旧操作を自動実行する操作実行ステップ
をさらに前記コンピュータに実行させることを特徴とする請求項６に記載の管理プログラム。
【請求項８】
前記サービスコンポーネントに対して行うことで、発生した障害を復旧するサービスコンポーネント復旧操作と、
前記サービスコンポーネント復旧操作の実行を禁止するための禁止条件と、
前記サービスコンポーネントおよび前記処理コンポーネントの管理者の許可なしに前記サービスコンポーネント復旧操作の自動実行を許可するための許可条件と、
を関連づけた操作制御情報を前記制約条件に対応して第３の記憶装置から読み出す第３の読み出しステップと、
前記障害要因コンポーネントが前記サービスコンポーネントであるとき、前記禁止条件および前記許可条件が成立するか否かを評価し、
前記禁止条件が成立するとき、前記サービスコンポーネント復旧操作を実行しないことを決定し、
前記禁止条件が成立せず、かつ前記許可条件が成立するとき、前記サービスコンポーネント復旧操作を実行することを決定し、
前記禁止条件が成立せず、かつ前記許可条件が成立しないとき、前記サービスコンポーネント復旧操作の実行有無を前記サービスコンポーネントおよび前記処理コンポーネントの管理者に判断させることを決定する、第３の条件評価ステップと、
をさらに前記コンピュータに実行させることを特徴とする請求項１ないし７のいずれか一項に記載の管理プログラム。
【請求項９】
前記サービスコンポーネントに対して行うことで、発生した障害を復旧するサービスコンポーネント復旧操作と、
前記サービスコンポーネント復旧操作の実行を禁止するための禁止条件と、
前記サービスコンポーネントおよび前記処理コンポーネントの管理者の許可なしに前記サービスコンポーネント復旧操作の自動実行を許可するための許可条件と、
を関連づけた操作制御情報を前記制約条件に対応して第３の記憶装置から読み出す第３の読み出しステップと、
前記障害要因コンポーネントが前記サービスコンポーネントであるとき、前記禁止条件および前記許可条件が成立するか否かを評価し、
前記許可条件が成立するとき、前記サービスコンポーネント復旧操作を実行することを決定し、
前記許可条件が成立せず、かつ前記禁止条件が成立するとき、前記サービスコンポーネント復旧操作を実行しないことを決定し、
前記許可条件が成立せず、かつ前記禁止条件が成立しないとき、前記サービスコンポーネント復旧操作の実行有無を前記サービスコンポーネントおよび前記処理コンポーネントの管理者に判断させることを決定する、第４の条件評価ステップと
をさらに前記コンピュータに実行させることを特徴とする請求項１ないし７のいずれか一項に記載の管理プログラム。
【請求項１０】
前記サービスコンポーネント復旧操作を実行することが決定されたとき、前記サービスコンポーネント復旧操作を自動実行する操作実行ステップ
をさらに前記コンピュータに実行させることを特徴とする請求項８または９に記載の管理プログラム。
【請求項１１】
１つまたは複数の機能を、前記機能を利用して処理を行う処理コンポーネントに提供するサービスコンポーネントを管理する管理装置であって、
前記サービスコンポーネントが提供する各前記機能のそれぞれについて、前記機能を利用するために必要な制約条件を記述した制約条件情報を記憶する第１の記憶手段と、
各前記制約条件の成否が、前記サービスコンポーネントの状態、前記処理コンポーネントの状態、および前記サービスコンポーネントおよび前記処理コンポーネントの両方の状態、のうちどの項目に依存するかをそれぞれ記述した依存情報を記憶する第２の記憶手段と、
前記処理コンポーネントが前記機能を利用する際に発生した障害の内容を表す障害情報を、前記障害情報の送信を行う障害情報送信装置から受信する障害情報受信手段と、
前記障害情報に基づき、前記サービスコンポーネントが提供する機能のうち、障害の発生した機能を特定する機能特定手段と、
特定した機能に対応する制約条件を前記制約条件情報において特定する制約条件特定手段と、
特定した制約条件の成立性を評価するための情報を収集する情報収集手段と、
収集した情報に基づいて、前記特定した制約条件が成立するか否か評価する条件評価手段と、
前記特定した制約条件が成立しないとき、前記依存情報において前記特定した制約条件に対応する項目に関連するコンポーネントを障害要因コンポーネントとして特定する障害要因特定手段と、
を備えたことを特徴とする管理装置。
【請求項１２】
前記制約条件は、１つ以上の制約式の論理積を含み、
前記依存情報は、各前記制約式がそれぞれ、各前記項目のいずれに依存するのかを記述し、
前記条件評価手段は、前記特定した制約条件に含まれる論理積の真偽を評価し、評価が真のとき前記特定した制約条件が成立し、偽のとき前記特定した制約条件が成立しないと判断し、
前記障害要因特定手段は、前記特定した制約条件が成立しないとき、前記特定した制約条件に含まれる前記制約式のうち偽である制約式に対応する前記項目に関連するコンポーネントを前記障害要因コンポーネントとして特定する
ことを特徴とする請求項１１に記載の管理装置。
【請求項１３】
前記サービスコンポーネントに対して行うことで、発生した障害を復旧するサービスコンポーネント復旧操作と、
前記サービスコンポーネント復旧操作の実行を禁止するための禁止条件と、
前記サービスコンポーネントおよび前記処理コンポーネントの管理者の許可なしに前記サービスコンポーネント復旧操作の自動実行を許可するための許可条件と、
を各前記制約条件にそれぞれ関連づけた操作制御情報を記憶する第３の記憶手段と、
前記障害要因コンポーネントが前記サービスコンポーネントおよび前記処理コンポーネントの両方であるとき、前記特定した制約条件に関連する前記禁止条件および前記許可条件が成立するか否かを評価する第２の条件評価手段と、
前記禁止条件および前記許可条件の成立有無に従って、前記発生した障害を復旧するための復旧操作を行うべき復旧対象コンポーネントを判定する復旧判定手段と、
をさらに備えたことを特徴とする請求項１１または１２に記載の管理装置。
【請求項１４】
前記復旧判定手段は、
前記禁止条件が成立するとき、前記復旧対象コンポーネントは前記処理コンポーネントであると判定し、
前記禁止条件が成立せず、かつ前記許可条件が成立するとき、前記復旧対象コンポーネントは前記サービスコンポーネントであると判定し、
前記禁止条件が成立せず、かつ前記許可条件が成立しないとき、前記復旧対象コンポーネントを前記サービスコンポーネントおよび前記処理コンポーネントの管理者に判断させることを決定する
ことを特徴とする請求項１３に記載の管理装置。
【請求項１５】
前記復旧対象コンポーネントが前記サービスコンポーネントであると判定されたとき、前記特定された制約条件に関連する前記サービスコンポーネント復旧操作を自動実行する操作実行手段
をさらに備えたことを特徴とする請求項１４に記載の管理装置。
【請求項１６】
前記復旧判定手段は、
前記許可条件が成立するとき、前記復旧対象コンポーネントは前記サービスコンポーネントであると判定し、
前記許可条件が成立せず、かつ前記禁止条件が成立するとき、前記復旧対象コンポーネントは前記処理コンポーネントであると判定し、
前記許可条件が成立せず、かつ前記禁止条件が成立しないとき、前記復旧対象コンポーネントを前記サービスコンポーネントおよび前記処理コンポーネントの管理者に判断させることを決定する
ことを特徴とする請求項１３に記載の管理装置。
【請求項１７】
前記復旧対象コンポーネントは前記サービスコンポーネントであると判定されたとき、前記特定された制約条件に関連する前記サービスコンポーネント復旧操作を自動実行する操作実行手段
をさらに備えたことを特徴とする請求項１６に記載の管理装置。
【請求項１８】
前記サービスコンポーネントに対して行うことで、発生した障害を復旧するサービスコンポーネント復旧操作と、
前記サービスコンポーネント復旧操作の実行を禁止するための禁止条件と、
前記サービスコンポーネントおよび前記処理コンポーネントの管理者の許可なしに前記サービスコンポーネント復旧操作の自動実行を許可するための許可条件と、
を各前記制約条件にそれぞれ関連づけた操作制御情報を記憶する第３の記憶手段と、
前記障害要因コンポーネントが前記サービスコンポーネントであるとき、前記特定した制約条件に関連する前記禁止条件および前記許可条件が成立するか否かを評価し、
前記禁止条件が成立するとき、前記特定した制約条件に関連する前記サービスコンポーネント復旧操作を実行しないことを決定し、
前記禁止条件が成立せず、かつ前記許可条件が成立するとき、前記サービスコンポーネント復旧操作を実行することを決定し、
前記禁止条件が成立せず、かつ前記許可条件が成立しないとき、前記サービスコンポーネント復旧操作の実行有無を前記サービスコンポーネントおよび前記処理コンポーネントの管理者に判断させることを決定する、第３の条件評価手段
をさらに備えたことを特徴とする請求項１１ないし１７のいずれか一項に記載の管理装置。
【請求項１９】
前記サービスコンポーネントに対して行うことで、発生した障害を復旧するサービスコンポーネント復旧操作と、
前記サービスコンポーネント復旧操作の実行を禁止するための禁止条件と、
前記サービスコンポーネントおよび前記処理コンポーネントの管理者の許可なしに前記サービスコンポーネント復旧操作の自動実行を許可するための許可条件と、
を各前記制約条件にそれぞれ関連づけた操作制御情報を記憶する第３の記憶手段と、
前記障害要因コンポーネントが前記サービスコンポーネントであるとき、前記特定した制約条件に関連する前記禁止条件および前記許可条件が成立するか否かを評価し、
前記許可条件が成立するとき、前記特定した制約条件に関連する前記サービスコンポーネント復旧操作を実行することを決定し、
前記許可条件が成立せず、かつ前記禁止条件が成立するとき、前記サービスコンポーネント復旧操作を実行しないことを決定し、
前記許可条件が成立せず、かつ前記禁止条件が成立しないとき、前記サービスコンポーネント復旧操作の実行有無を前記サービスコンポーネントおよび前記処理コンポーネントの管理者に判断させることを決定する、第４の条件評価手段
をさらに備えたことを特徴とする請求項１１ないし１７のいずれか一項に記載の管理装置。
【請求項２０】
前記サービスコンポーネント復旧操作を実行することが決定されたとき、前記特定された制約条件に関連する前記サービスコンポーネント復旧操作を自動実行する操作実行手段
をさらに備えたことを特徴とする請求項１８または１９に記載の管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば一つ以上のコンポーネント(例えばアプリケーションサーバやデータベース管理システムなどのソフトウェアコンポーネント)から構成される情報システムにおいて障害が発生した場合に、障害要因となるコンポーネントを判定する管理プログラムおよび管理装置に関する。
【背景技術】
【０００２】
近年、複数の計算機によって構成される情報システムが大規模、複雑化するに伴い、人手による保守管理が困難になってきている。そこで、情報システムで障害が発生した場合、障害要因の特定や復旧操作の実行などを自動的に行う自己修復機能が注目されている。
【０００３】
自己修復機能の実現方法としては、例えば特許文献１および非特許文献１に、分散管理型の自己修復技術が開示されている。これらの従来技術では、コンポーネント毎に管理する、制約情報と状態遷移情報に基づき、コンポーネントを正常な状態に制御する方法が開示されている。特に特許文献１では、コンポーネント毎に制約情報と状態遷移情報を管理することで、情報システムの構成変更などにも柔軟に対応可能な自己修復機能を実現している。
【特許文献１】特開2007-128185号
【非特許文献１】A Self-healing technique using reusable component-level operation knowledge, Cluster Computing Journal vol. 10 pp 385-394, Springer, 2007
【発明の開示】
【発明が解決しようとする課題】
【０００４】
一般に、情報システムは、依存関係を持つ複数のコンポーネントにより構成される。このようなシステムにおいて、依存する側のコンポーネント(依存元コンポーネントと呼ぶ)が、依存される側のコンポーネント（依存先コンポーネントと呼ぶ）の機能を利用できないと障害が発生する。このような障害の原因と復旧操作には以下のパターンがある。
(1) 依存先に原因があり、依存先に対する復旧操作が必要（サーバプロセスの停止など）
(2) 依存元に原因があり、依存元に対する復旧操作が必要（クライアントの設定ミスなど）
(3) 依存先と依存元間の一貫性の問題であり、復旧対象が運用方針などにより異なる（ユーザ権限設定など）。
【０００５】
しかし、従来技術が対応できる障害は上記(1)に分類されるものに限られていた。これは、従来技術が備える復旧方法特定機能が依存先コンポーネントの情報のみを参照するためである。
【０００６】
本発明は、障害要因となるコンポーネントをより確実に特定できるようにした管理プログラムおよび管理装置を提供する。
【課題を解決するための手段】
【０００７】
本発明の一態様としての管理プログラムは、
１つまたは複数の機能を、前記機能を利用して処理を行う処理コンポーネントに提供するサービスコンポーネントを管理する管理プログラムであって、
前記処理コンポーネントが前記機能を利用する際に発生した障害の内容を表す障害情報を、前記障害情報の送信を行う障害情報送信装置から受信する障害情報受信ステップと、
前記障害情報に基づき、前記サービスコンポーネントが提供する機能のうち、障害の発生した機能を特定する機能特定ステップと、
特定した機能を利用するために必要な制約条件を記述した制約条件情報を第１の記憶装置から読み出す第１の読み出しステップと、
前記制約条件情報に記述された前記制約条件の成立性を評価するための情報を収集する情報収集ステップと、
収集した情報に基づいて、前記制約条件が成立するか否かを評価する条件評価ステップと、
前記制約条件の成否が、前記サービスコンポーネントの状態、前記処理コンポーネントの状態、および、前記サービスコンポーネントの状態と前記処理コンポーネントの状態の両方、のうちどの項目に依存するかを記述した依存情報を第２の記憶装置から読み出す第２の読み出しステップと、
前記制約条件が成立しないとき、前記依存情報に記述された項目に関連するコンポーネントを障害要因コンポーネントとして特定する障害要因特定ステップと、
をコンピュータに実行させることを特徴とする。
【０００８】
本発明の一態様としての管理装置は、
１つまたは複数の機能を、前記機能を利用して処理を行う処理コンポーネントに提供するサービスコンポーネントを管理する管理装置であって、
前記サービスコンポーネントが提供する各前記機能のそれぞれについて、前記機能を利用するために必要な制約条件を記述した制約条件情報を記憶する第１の記憶手段と、
各前記制約条件の成否が、前記サービスコンポーネントの状態、前記処理コンポーネントの状態、および前記サービスコンポーネントの状態と前記処理コンポーネントの状態の両方、のうちどの項目に依存するかをそれぞれ記述した依存情報を記憶する第２の記憶手段と、
前記処理コンポーネントが前記機能を利用する際に発生した障害の内容を表す障害情報を、前記障害情報の送信を行う障害情報送信装置から受信する障害情報受信手段と、
前記障害情報に基づき、前記サービスコンポーネントが提供する機能のうち、障害の発生した機能を特定する機能特定手段と、
特定した機能に対応する制約条件を前記制約条件情報において特定する制約条件特定手段と、
特定した制約条件の成立性を評価するための情報を収集する情報収集手段と、
収集した情報に基づいて、前記特定した制約条件が成立するか否か評価する条件評価手段と、
前記特定した制約条件が成立しないとき、前記依存情報において前記特定した制約条件に対応する項目に関連するコンポーネントを障害要因コンポーネントとして特定する障害要因特定手段と、
を備えたことを特徴とする。
【発明の効果】
【０００９】
本発明により、障害要因となるコンポーネントをより確実に特定できる。
【発明を実施するための最良の形態】
【００１０】
以下、図面を参照しながら、本発明の実施例について説明する。
【実施例１】
【００１１】
図１は本発明の実施例１に従った管理装置によって管理される情報システムを示す。
【００１２】
この情報システムは、ネットワーク１１で接続された計算機１および計算機２を備える。計算機１にはアプリケーションサーバ１２が配置され、計算機２にはデータベース管理システム１３が配置されている。
【００１３】
計算機１のアプリケーションサーバ１２は、計算機２のデータベース管理システム１３に接続し、データの検索などを行う。すなわち計算機１のアプリケーションサーバ１２は、計算機２のデータベース管理システム１３に依存している。
【００１４】
データベース管理システム１３は、３３０６番のポートを介してネットワーク１１上の他のコンポーネント（ここではアプリケーションサーバ１２）に対し、検索などの機能を提供する。アプリケーションサーバ１２では、データベース管理システム１３に接続し、データベース管理システム１３が提供する検索などの機能を利用する。アプリケーションサーバ１２では、データベース管理システム１３への接続前に、データベース管理システム１３のポート番号や、接続に用いるユーザ名やパスワードを設定しておく。
【００１５】
データベース管理システム１３は例えば１つまたは複数の機能を提供するサービスコンポーネントに相当し、アプリケーションサーバ１２は例えばサービスコンポーネントが提供する機能を利用する処理コンポーネントに相当する。
【００１６】
図１の例では、アプリケーションサーバ１２とデータベース管理システム１３とはそれぞれ異なる計算機に配置されているが、本発明はこれに限定されず、これらが同一の計算機内に配置されてもよい。
【００１７】
図１の情報システムにおいて、計算機２内には、データベース管理システム１３を管理する、本実施例１に係る管理装置（図２参照）が配置される（図３または図４参照）。
【００１８】
また計算機１および計算機２を接続するネットワーク１１には、上記情報システムの管理者により操作される管理者端末が配置される（図３参照）。
【００１９】
また、アプリケーションサーバ１２がデータベース管理システム１３の機能を利用する際に障害が発生したとき、発生した障害の内容を表す障害情報を生成して管理装置に転送する障害情報転送装置（障害情報送信装置）が、計算機１内、または上記管理者端末内に配置される（図３または図４参照）。
【００２０】
本実施例１に係る管理装置は、障害情報転送装置から障害情報を受信し、受信した障害情報に基づき障害の発生した機能を特定し、障害の発生要因がどのコンポーネント（アプリケーションサーバ１２、データベース管理システム１３、またはこれらの両方）にあるのかを特定し、特定したコンポーネントの識別情報を管理者端末に送信する。管理者端末において受信したコンポーネントの識別情報を表示することで、管理者は、障害の発生要因となったコンポーネントを識別できる。
【００２１】
以下では、アプリケーションサーバ１２においてデータベース管理システム１３のポートの設定が誤っていることが原因で、アプリケーションサーバ１２がデータベース管理システム１３に接続できない場合（接続機能の障害が発生した場合）を例に本実施例について説明する。
【００２２】
まず図３、図４および図８を用いて、障害情報転送装置および障害情報について説明する。
【００２３】
障害情報転送装置（障害情報送信装置）は、情報システムで発生した障害の内容を表す障害情報を生成あるいは外部から入力する機能と、該障害情報を管理装置２１に転送する機能を備える任意の装置でよい。障害情報転送装置は、例えば計算機１内、または管理者端末に配置することができる。障害情報転送装置の構成例を以下に３つ示す。
【００２４】
（第１の構成例）
図３はネットワーク１１に接続される管理者端末４１に組み込むようにして障害情報転送装置を構成した例を示す。障害情報転送装置は、人間の管理者が障害情報を入力するための障害情報入力部４２と、入力された障害情報を管理装置２１に転送する障害情報転送部４３とによって構成される。
【００２５】
（第２の構成例）
図４は計算機１に組み込むようにして障害情報転送装置を構成した例を示す。障害情報転送装置５１は、コンポーネント監視部５３と、障害情報生成情報５４と、障害情報生成部５５と、障害情報転送情報５６と、障害情報転送部５７とを備える。
【００２６】
コンポーネント監視部５３は、依存元コンポーネント（アプリケーションサーバ）１２のログ情報（ログファイル）５２を監視する。障害情報生成部５５は、ログ情報５２にエラーメッセージが出現した場合に、機能障害が発生したことを検出し、エラーメッセージと障害情報とを関連づけた障害情報生成情報５４に基づいて障害情報を生成する。障害情報転送部５７は、障害情報の転送先を記述した障害情報転送情報５６に基づいて、生成した障害情報を管理装置２１に転送する。
【００２７】
（第３の構成例）
第１および第２の構成例以外にも、非特許文献１のようにアスペクト指向プログラミングやJMX(JavaManagement Extension)を用いて依存元コンポーネント（アプリケーションサーバ）１２を拡張することによって障害情報転送装置を実現してもよい。
【００２８】
なお、本実施例において障害情報転送装置は、コンピュータ上で実行可能なプログラムとして実現されるものとする。
【００２９】
図８は、障害情報転送装置により生成される障害情報の一例を示す。
【００３０】
障害情報は、上述したとおり、発生した障害の内容を表現した情報である。障害情報は、依存先コンポーネントが提供する機能のうち利用しようとしたが利用できなかった機能(function)、機能を利用しようとしたユーザ(user)、機能を利用しようとした依存元コンポーネントが配置された計算機(host)、利用できなかった時刻(time)、エラーID(errornumber)、依存先コンポーネントに接続する際に用いたポート番号(port)などの情報を含む。
【００３１】
図８の例では、計算機1内のアプリケーションサーバ１２が、ポート5432を介し、ユーザadminとしてデータベース管理システム１３のデータベースdb1に接続を試みたが、接続できなかったことを示している。
【００３２】
次に、図２〜図７、図９および図１０を用いて、管理装置について説明する。
【００３３】
図２は、本実施例に従った管理装置２１の構成を概略的に示すブロック図である。
【００３４】
管理装置２１は、依存先コンポーネントと同じ計算機（本実施例では計算機２）に配置される（図３または図４参照）。管理装置２１は、コンピュータ上で実行可能なプログラムとして実現されるものとする。
【００３５】
図２の管理装置２１は、上記障害情報転送装置から障害情報を受信する受信部２６と、依存先コンポーネントが提供する機能についてその機能を利用するための制約条件を記憶する制約情報記憶部２２と、制約条件の成否を検査する制約検査部２３と、制約条件を検査する際に必要となるコンポーネント情報を取得するコンポーネント情報取得部２４と、制約検査部２３の検査結果から障害要因がどのコンポーネントにあったのかを判定する障害要因判定部２５と、障害要因となるコンポーネントの識別情報を含む判定結果を管理者端末に送信する送信部２７と、を備える。管理者端末４１（図３参照）は、要因情報受信部４５において上記判定結果を受信し、受信した判定結果を要因情報表示部４４において表示する。
【００３６】
管理装置２１の制約情報記憶部（第１の記憶装置、第２の記憶装置）２２は、（１）制約条件情報と、（２）制約式情報と、（３）制約式評価情報とを記憶している。（２）制約式情報はたとえば本発明の依存情報を含む。
【００３７】
図５は制約条件情報の一例を示す。制約条件情報は、依存先コンポーネントの機能と、該機能を利用するために必要な制約条件とを関連付けたものである。図示の制約条件情報には２つのデータ６１、６２が含まれる。
【００３８】
制約条件は、一つ以上の制約式の論理演算として構成される。例えば、データ６１の制約条件は、３つの制約式の論理積として構成され、当該制約条件が成立するためには、全ての制約式が真である必要がある。すなわち、データベース管理システム１３によって管理されるデータベースdbに接続(connect)するためには、制約式activeDaemonと制約式accessGrantedUser(db)と制約式correctPortとが全て真である必要がある。つまり、デーモンプロセスが稼働しており、かつアクセスしてきたユーザに対し接続許可が定められており、かつユーザが正しいポート番号で接続してきていることが必要である。３つの制約式のうちどれか１つでも偽であれば、当該制約条件は成立しない、すなわち偽であると判断される。
【００３９】
図６は制約式情報の一例を示す。制約式情報は、制約式の名前と、制約式とを関連づけた情報である。
【００４０】
制約式は、パラメータおよび関数の少なくとも一方を用いた論理式により定義される。制約式に含まれるパラメータおよび関数には、関連するコンポーネントに応じて、$または#のフラグが付されている。
【００４１】
#が付与された、パラメータまたは関数は、依存先コンポーネント（本実施例ではデータベース管理システム１３）の状態に関係（依存）するものであり、$が付与された、パラメータまたは関数は、依存元コンポーネント（本実施例ではアプリケーションサーバ１２）の状態に関係（依存）するものである。
【００４２】
依存先コンポーネント（本実施例ではデータベース管理システム１３）の状態に関係するパラメータおよび関数の値の取得は、後述するコンポーネント情報取得部２４において行う。依存元コンポーネント（本実施例ではアプリケーションサーバ１２）に関係するパラメータおよび関数の値の取得は、障害情報転送装置から受信する障害情報を利用してコンポーネント情報取得部２４において行う。
【００４３】
図７は制約式評価情報の一例を示す。
【００４４】
制約式評価情報は、コンポーネント情報取得部２４が、パラメータまたは関数の値を取得するための具体的な方法（評価方法）を記述している。制約式評価情報は、パラメータまたは関数の名前と、その評価方法とを関連づけている。評価方法は、例えば、評価を行うプログラムを指定する。図７の下段には、関数connGranted($user,$db)を評価するプログラムの例が示されている。
【００４５】
図９は、管理装置２１の動作の流れを概略的に示すフローチャートである。
【００４６】
まず、管理装置２１の受信部２６は、障害情報転送装置から障害情報を受信し、受信した障害情報を制約検査部２３に通知する（Ｓ１１）受信部２６は、たとえば障害情報を受信する障害情報受信手段を含む。
【００４７】
次に、制約検査部２３は、障害情報（図８参照）の機能(function)項目に指定された機能名に対応する制約条件を制約条件情報（図５参照）から特定する（Ｓ１２）。制約検査部２３は、たとえば、障害情報に基づき、障害の発生した機能を特定する機能特定手段を含む。また制約検査部２３は、制約条件情報を読み出す第１の読み出し手段、上述した関係情報を読み出す第２の読み出し手段を含む。
【００４８】
次に、制約検査部２３は、コンポーネント情報取得部２４を用いて、特定された制約条件の成否を評価するための必要な情報を取得する（Ｓ１３）。つまり、特定された制約条件に含まれる各制約式の評価に必要な情報を取得する。図２では、コンポーネント情報取得部２４は１つのブロックとして示され、１つのブロックが各制約式の評価に必要な情報を取得しているが、制約式の種類に応じてそれぞれの専用ブロックを用意し、制約式の種類ごとに専用のブロックを用いて、必要な情報を取得してもよい。制約検査部２３は、特定された制約条件を評価するために必要な情報を取得したら、取得した情報に基づき、特定された制約条件の成否を評価する（Ｓ１３）。制約検査部２３は、制約式の成否を評価する条件評価手段を含む。
【００４９】
評価の結果、制約条件が成立した場合（評価結果が真(true)）であった場合）、すなわち制約条件に含まれる各制約式が全て真であった場合は、未定義の障害が発生したものとし、送信部２７を用いて未定義障害の発生メッセージを管理者端末４１等に通知する（Ｓ１７）。未定義障害の発生メッセージには、評価された制約条件を含めてもよい。管理者端末４１は、要因情報受信部４５において当該発生メッセージを受信し、要因情報表示部４４に表示する。
【００５０】
一方、制約条件が非成立であった場合（評価結果が偽(false)であった場合）、すなわち評価した制約条件に含まれる各制約式のうち少なくとも１つが偽であった場合は、該制約条件の中で偽と判定された制約式を特定し、特定された制約式を障害要因判定部２５に通知する（Ｓ１５）。
【００５１】
障害要因判定部２５は、特定された制約式を受信すると、該制約式に含まれるフラグ($、#)を検査する（Ｓ１６）。すなわち該制約式に含まれるパラメータおよび関数に付されているフラグについて、それが$であるか#、あるいは＄と＃の両方であるかを検査することにより障害要因を判定する。障害要因判定部２５は、たとえば障害要因を特定する障害要因特定手段を含む。
【００５２】
該制約式に含まれるフラグが$のみであった場合は、依存元コンポーネント（本実施例ではアプリケーションサーバ１２）側に障害の要因があると判定する（Ｓ１８）。
【００５３】
該制約式に含まれるフラグが#のみであった場合は、依存先コンポーネント（本実施例ではデータベース管理システム１３）側に障害の要因があると判定する（Ｓ１９）。
【００５４】
該制約式に$と#の両方が含まれる場合は、障害の要因が存在する可能性が、依存先コンポーネント（本実施例ではデータベース管理システム１３）と依存元コンポーネント（本実施例ではアプリケーションサーバ１２）の両方にあると判定する（Ｓ２０）。すなわち、この場合、本実施例の管理装置では障害の要因を一方に特定できない。障害の要因が存在する可能性が、依存先コンポーネントと依存元コンポーネントの両方にある場合の一例としては、両コンポーネントの状態の一貫性に問題がある場合がある。
【００５５】
この後、管理装置２１は、送信部２７を用いて、障害要因が、依存元コンポーネント（本実施例ではアプリケーションサーバ１２）、依存先コンポーネント（本実施例ではデータベース管理システム１３）、およびこれらの両方のうちどれにあるのかを示す、障害要因の判定結果を管理者端末２１等に通知する（Ｓ２１）。
【００５６】
以下、具体例を用いて、管理装置の動作についてさらに詳細に説明する。
【００５７】
図１０は、図８に示した障害情報を受信した場合における管理装置の動作例を説明する図である。
【００５８】
管理装置２１は、障害情報転送装置から障害情報を受信すると（Ｓ３１）、制約条件情報（図５参照）においてconnect(db)に関連付けられた制約条件（activeDaemon&accessGrantedUser(db)&correctPort）を特定する（Ｓ３２）。
【００５９】
次に、管理装置２１は、特定した制約条件の成否をコンポーネント情報取得部２４と制約検査部２３とを用いて評価する（Ｓ３３）。すなわちコンポーネント情報取得部２４は、特定した制約条件の成否を評価するために必要な情報を取得する。制約検査部２３は、該取得した情報と、図７に示した制約式評価情報における評価方法(getDaemon,isGrantedなど)に対応付けられたプログラムとを用いて、特定した制約条件の成否を評価する。
【００６０】
ここで、障害情報のport項目に指定された情報が5432であったとする。この場合、制約式情報（図６参照）における制約式名correctPortに対応する制約式port==3306は偽と評価され、その結果、connect(db)に関連付けられた制約条件（activeDaemon&accessGrantedUser(db)&correctPort）は成立しない（偽である）と評価される（Ｓ３４）。
【００６１】
制約条件（activeDaemon&accessGrantedUser(db)&correctPort）が成立しない（偽である）と評価されたので、該制約条件の中で偽と評価された制約式を特定する。ここでは、制約式correctPortのみが特定され、制約式名activeDaemonに対応する制約式daemon==active、および制約式名accessGrantedUser(db)に対応する制約式connGranted(user,db)は、それぞれ真であったとする（Ｓ３５）。
【００６２】
次に、障害要因判定部２５は、制約式correctPortに含まれるフラグを検査し、障害要因の特定を行う（Ｓ３６）。制約式correctPortは、フラグとして$のみを含むため、依存元コンポーネント（本実施例ではアプリケーションサーバ１２）に障害の要因があると特定する（Ｓ３７）。
【００６３】
このように、本実施例によれば障害の要因が依存元コンポーネント（本実施例ではアプリケーションサーバ１２）側にあっても、障害要因となるコンポーネントの特定が可能となる。すなわち障害要因となるコンポーネントを確実に特定できる。
【実施例２】
【００６４】
実施例１の管理装置では、依存先コンポーネント（たとえばデータベース管理システム１３）の状態と依存元コンポーネント（たとえばアプリケーションサーバ１２）の状態の両方に障害の要因が存在する可能性があると判定された場合に、発生した障害を復旧するための復旧操作を行うべきコンポーネント（復旧対象コンポーネントあるいは単に復旧対象）を管理者が判断する必要がある。そこで、本実施例では、このような場合に、復旧対象コンポーネントを自動的に判断する実施の形態について説明する。
【００６５】
以下では、図１の情報システムにおいて、アプリケーションサーバ１２が、データベース管理システム１３に定義されていないユーザ(undef)により接続しようとし、接続が失敗する場合を例にして説明を行う。
【００６６】
図１１は本実施例に従った管理装置３１の構成を概略的に示すブロック図である。
【００６７】
図１１の管理装置３１は、図２に示した実施例１の管理装置２１に、復旧計画部３２と復旧対象判定部３３と操作情報記憶部３４を追加したものである。
【００６８】
実施例１と同様に、図１１の管理装置３１は、依存先コンポーネント(本実施例ではデータベース管理システム１３)と同じ計算機２に配置される。また、障害情報を管理装置に転送する障害情報転送装置が、計算機１または管理者端末４１内に配置される。障害情報転送装置は、実施例１の場合と同様に、障害情報を生成または入力する機能と、生成または入力した障害情報を管理装置に転送する機能を備える任意の装置でよい。
【００６９】
管理装置３１における操作情報記憶部（第３の記憶装置）３４は、（１）操作計画情報と、（２）操作制御情報とを記憶している。
【００７０】
図１２は、操作計画情報の一例を示す。
【００７１】
操作計画情報は、制約式と、該制約式が偽と評価される状態を真と評価される状態にするために必要な、依存先コンポーネント（本実施例ではデータベース管理システム１３）に対する復旧操作（復旧計画）とを関連付けたものである。
【００７２】
例えば、制約式accessGrantedUser(db)が偽と評価された場合、制約式accessGrantedUser(db)が真となるようにするには、関数planForGrantedUserAccess(db)を実行することにより得られる操作を依存先コンポーネント（本実施例ではデータベース管理システム１３）に対して実行すればよいことが示される。関数planForGrantedUserAccess(db)の実行コードの一例が図１２の下段に示される。
【００７３】
すなわち、関数planForGrantedUserAccess(db)の実行は、
1: 復旧操作の初期化(Operation[] ops = new Operation[1];)
2: 障害情報からユーザ情報を特定(String user = getUser();)
3: 特定されたユーザの接続を許可する操作の作成(ops[0]=new
GrantedUserOperation(user,db))
の手順（修復操作）を含み、これらの手順の実行により、復旧を行う（制約式accessGrantedUser(db)を真とする）ことができる。
【００７４】
図１３は、操作制御情報の一例を示す。
【００７５】
操作制御情報は、上記修復操作と、該修復操作の実現方法（コマンド）と、管理者の許可なしに該修復操作の自動実行を許可するための許可条件と、該修復操作の実行を禁止する禁止条件とを関連付けたものである。図中、Trueは無条件に真であること、Falseは無条件に偽であることを示す。
【００７６】
図１３において例えば、復旧操作GrantSelectOperation(user,db)は、コマンドecho “grant select for user on db”| dbmsの実行により実現される。dbが公開DB(public)であればその実行が自動実行することが許可され、userが未定義(notexist)である場合はその実行が（無条件に）禁止されることが意味される。許可条件および禁止条件に基づく処理の例は後に詳しく述べる。
【００７７】
以下、図１４を用いて、管理装置３１の動作について説明する。
【００７８】
図１４は、管理装置３１の動作の流れを概略的に示すフローチャートである。図１４において点線で囲った部分は、実施例１（図９）と同様であるため、点線枠内の各ブロックは図９と同一の符号を付して重複する説明を省略する。
【００７９】
管理装置３１は、障害要因判定部２５において障害要因が依存先コンポーネント（本実施例ではデータベース管理システム１３）と依存元コンポーネント（本実施例ではアプリケーションサーバ１２）の両方に障害要因が存在する可能性があると判定された場合（偽と評価された制約式に#と$とが含まれていた場合）、偽と評価された制約式を復旧計画部３２に通知する。復旧計画部３２は、操作計画情報（図１２参照）を用いて、偽と評価された制約式を真にするために必要な操作（復旧計画）を全て特定し（Ｓ４１）、特定した操作を復旧対象判定部３３に通知する。
【００８０】
特定された操作の通知を受けた復旧対象判定部３３は、操作制御情報（図１３参照）を用いて、特定された操作の禁止条件を評価する（Ｓ４２）。復旧対象判定部３３は、たとえば操作制御情報を読み出す第３の読み出し手段を含む。特定された操作の中で、禁止条件が真と評価される操作が一つでもあれば（Ｓ４３のＹＥＳ）、依存先コンポーネント（本実施例ではデータベース管理システム１３）側での復旧は不可能と判断し、復旧対象コンポーネントは依存元コンポーネント（本実施例ではアプリケーションサーバ１２）であると判定する（Ｓ４４）。
【００８１】
特定された全ての操作の禁止条件が偽であった場合は（Ｓ４３のＮＯ）、該特定された操作の許可条件を評価する（Ｓ４５）。全ての操作の許可条件が真と評価された場合（Ｓ４６のＹＥＳ）、依存先コンポーネント（本実施例ではデータベース管理システム１３）を復旧対象コンポーネントとして判定する（Ｓ４７）。全ての操作の許可条件が真と評価された場合とは、全ての操作の実行が、管理者の許可無しに、自動実行してよいことを意味する。復旧対象判定部３３は、復旧対象コンポーネントが依存先コンポーネントであることを示す情報を管理者端末４１に送信部２７を介して送信する。また、復旧対象判定部３３は、特定された操作を自動的に実行する操作実行手段を用いて、当該特定された操作を実行し、障害を復旧する。操作実行手段は復旧対象判定部に含まれていてもよい。
【００８２】
一方、特定された操作のうち、許可条件が偽と評価される操作が一つでもあった場合は（Ｓ４６のＮＯ）、特定された操作を管理者端末３１に通知して表示し、管理者に復旧対象コンポーネントの判断を委ねるようにする（Ｓ４８）。許可条件が偽と評価される操作とは、管理者の許可なしに実行してはならない操作を意味する。たとえば復旧操作として依存先コンポーネント（本実施例ではデータベース管理システム１３）の再起動が必要な場合などは、他の装置または他の処理への影響を考慮して、許可条件を無条件にFalseにして、常にその操作について管理者の判断に委ねるようにすることがあり得る。上述の操作実行手段は、管理者からの入力指示に応じて、上記特定された操作を実行するようにしてもよい。
【００８３】
復旧対象判定部３３は、禁止条件および許可条件が成立するか否かを判定する第２の条件評価手段と、禁止条件および許可条件の成立有無に従って復旧対象コンポーネントを判定する復旧判定ステップとを含む。
【００８４】
上述した図１４のフローでは、まずＳ４２で禁止条件を評価し、次にＳ４５で許可条件を評価することにより、禁止条件を優先的に扱ったが、運用方針に応じて、許可条件を優先的に扱ってもよい。すなわち、許可条件を先に評価し、次に禁止条件を評価するようにしてもよい。この場合の処理の流れとしては、まず特定された全ての操作の許可条件が真であれば、依存先コンポーネント（本実施例ではデータベース管理システム１３）を復旧対象コンポーネントとして判定する。このとき、復旧対象判定部３３は、上記操作実行手段を用いて、当該特定された操作を実行し、障害を復旧する。一方、特定された操作のうち、許可条件が偽と評価される操作が一つでもあった場合は、次に、特定された操作の中で、禁止条件が真と評価される操作があるかどうかを判断し、そのような操作が一つでもあれば、復旧対象コンポーネントは依存元コンポーネント（本実施例ではアプリケーションサーバ１２）であると判定する。特定された全ての操作の禁止条件が偽であった場合は特定された操作を管理者端末３１に通知して表示し、管理者に復旧対象コンポーネントの判断を委ねるようにする。
【００８５】
また上述した図１４のフローのＳ４３では真と評価される操作が１つでもあれば復旧対象コンポーネントは依存元コンポーネント（本実施例ではアプリケーションサーバ１２）であると判定したが、全ての操作が真と評価されたときのみ復旧対象コンポーネントは依存元コンポーネント（本実施例ではアプリケーションサーバ１２）であると判定してもよい。また、Ｓ４６の処理では、全ての操作が真と評価されたときのみ依存先コンポーネント（本実施例ではデータベース管理システム１３）を復旧対象コンポーネントとして判定したが、真と評価される操作が１つでもあれば依存先コンポーネント（本実施例ではデータベース管理システム１３）を復旧対象コンポーネントとして判定するようにしてもよい。
【００８６】
以下では、図１５に示す障害情報を受信した場合を例にして、管理装置の動作について具体的に説明する。
【００８７】
図１６は、図１５の障害情報を受信した場合における管理装置の動作を説明する図である。
【００８８】
まず、実施例１と同様の処理を行うことによって、制約式accessGrantedUser(db1)が偽と評価され、依存先コンポーネント（本実施例ではデータベース管理システム１３）と依存元コンポーネント（本実施例ではアプリケーションサーバ１２）の両方に障害要因が存在する可能性があると判定されたとする（Ｓ５１〜Ｓ５５）。
【００８９】
そこで、障害要因判定部２５は、偽と評価された制約式accessGrantedUser(db1)を復旧計画部３２に通知する。
【００９０】
復旧計画部３２は、操作計画情報（図１２参照）を用いて、通知された制約式を真とするための復旧操作を特定する（Ｓ５６）。この場合、復旧操作として操作GrantSelectOperation(undef,db1)が特定される。復旧計画部３２は、特定された操作を復旧対象判定部３３に通知する。
【００９１】
操作の通知を受けた復旧対象判定部３３は、操作制御情報（図１３参照）を用いて、操作GrantSelectOperation(undef,db1)の禁止条件を評価する（Ｓ５７）。
【００９２】
この場合、user=undef（ユーザが未定義）であるため、禁止条件（undef∈notexist）は真と評価される（Ｓ５８）。
【００９３】
したがって、依存先コンポーネント（本実施例ではデータベース管理システム１３）側での復旧操作GrantSelectOperation(undef,db1)は、禁止されていると判定され（Ｓ５９）、管理装置３１は、復旧対象を依存元コンポーネント（本実施例ではアプリケーションサーバ１２）と判定する（Ｓ６０）。
【００９４】
このように、本実施例によれば、依存先コンポーネント（本実施例ではデータベース管理システム１３）と依存元コンポーネント（本実施例ではアプリケーションサーバ１２）の両方に障害要因が存在する可能性があると判定されたときに、復旧操作の禁止条件・許可条件を評価することによって復旧対象コンポーネントを判定できる。
【００９５】
これまでの説明では、依存先コンポーネント（本実施例ではデータベース管理システム１３）と依存元コンポーネント（本実施例ではデータベース管理システム１３）の両方に障害要因が存在する可能性があると判定された場合に復旧対象コンポーネントを判定する例を示したが、以下では、別の例として、障害要因が依存先コンポーネントにあると判定された場合に復旧操作を自動的に行うか否かを判定する例を示す。この場合における管理装置の動作フローを図１７に示す。図１７において点線で囲った部分は、実施例１（図９）と同様であるため、点線枠内に各ブロックは、図９と同一の符号を付して重複する説明を省略する。また、図１７のＳ７１〜Ｓ７３、Ｓ７５、Ｓ７６は、図１４のＳ４１〜Ｓ４３、Ｓ４５、Ｓ４６と同じである。
【００９６】
管理装置３１は、障害要因判定部２５において障害要因が依存先コンポーネント（本実施例ではデータベース管理システム１３）にあると判定された場合（偽と評価された制約式に#のみが含まれていた場合）、偽と評価された制約式を復旧計画部３２に通知する。復旧計画部３２は、操作計画情報（図１２参照）を用いて、偽と評価された制約式を真にするために必要な操作（復旧操作）を全て特定し（Ｓ７１）、特定した操作を復旧対象判定部３３に通知する。
【００９７】
特定された操作の通知を受けた復旧対象判定部３３は、操作制御情報（図１３参照）を用いて、特定された操作の禁止条件を判定する（Ｓ７２）。特定された操作の中で、禁止条件が真と評価されるものが一つでもあれば（Ｓ７３のＹＥＳ）、特定された操作の実行による復旧（自動的な復旧）は不可能と判断し、特定された操作は実行しない（Ｓ７４）。この場合は、たとえば、管理者が、修復を行うべき新たな操作を別に特定してその実行を図る必要がある。
【００９８】
特定された全ての操作の禁止条件が偽であった場合は（Ｓ７３のＮＯ）、該特定された操作の許可条件を評価する（Ｓ７５）。全ての操作の許可条件が真と評価された場合（Ｓ７６のＹＥＳ）、復旧対象判定部３３は、上記操作実行手段を用いて、該特定された操作を、自動的に実行し、これにより障害の復旧を図る。
【００９９】
一方、特定された操作のうち、許可条件が偽と評価される操作が一つでもあった場合は（Ｓ７６のＮＯ）、特定された操作を管理者端末３１に通知して表示し、管理者に、特定された操作の実行の判断をゆだねる。
【０１００】
復旧対象判定部３３は、Ｓ７２〜Ｓ７８の処理を行う第３の条件評価手段を含む。
【０１０１】
図１７のフローでは、Ｓ７２で禁止条件を評価し、次いでＳ７５で許可条件を評価することで、禁止条件を許可条件よりも優先的に扱ったが、図１４のフローの場合と同様に、許可条件を優先的に扱ってもよい。この場合の処理の流れは、図１４のフローの場合で説明した処理に準じればよく、したがって詳細な説明は省略する。このような許可条件を優先的に扱った処理を行う第４の条件評価手段を復旧対象判定部８３は含む。
【０１０２】
また図１７のフローのＳ７３では真と評価される操作が１つでもあれば特定された操作による復旧は不可能と判断したが、全ての操作が真と評価されたときのみこのような判断を行ってもよい。また、Ｓ７６の処理では、全ての操作が真と評価されたときのみ、特定された操作を実行したが、真と評価される操作が１つでもあれば、該特定された操作を実行するようにしてもよい。
【０１０３】
このように図１７のフローに示した処理を行うことにより、障害要因が依存先コンポーネント（本実施例ではデータベース管理システム１３）にあると判定された場合に、復旧操作を自動的に行うか否かを判定することができる。
【０１０４】
なお、以上に説明した各実施例における管理装置は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、管理装置における受信部、制約検査部、コンポーネント情報取得部、障害要因判定部、送信部、操作実行手段は、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、管理装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、ＣＤ−ＲＯＭなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、制約情報記憶部２２は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用して実現することができる。
【図面の簡単な説明】
【０１０５】
【図１】本発明の実施例１に従った管理装置によって管理される情報システムを示す図。
【図２】本発明の実施例１に従った管理装置の構成を概略的に示すブロック図。
【図３】障害情報転送装置の一例を示す図。
【図４】障害情報転送装置の他の例を示す図。
【図５】制約条件情報の一例を示す図。
【図６】制約式情報の一例を示す図。
【図７】制約式評価情報の一例を示す図。
【図８】本発明の実施例１に係る障害情報の一例を示す図。
【図９】図２の管理装置の動作の流れを概略的に示すフローチャート。
【図１０】図８に示した障害情報を受信した場合における管理装置の動作例を説明する図。
【図１１】本発明の実施例２に従った管理装置の構成を概略的に示すブロック図。
【図１２】操作計画情報の一例を示す図。
【図１３】操作制御情報の一例を示す図。
【図１４】本発明の実施例２に従った管理装置の動作の流れを概略的に示すフローチャート。
【図１５】本発明の実施例２に係る障害情報の一例を示す図。
【図１６】図１５の障害情報を受信した場合における管理装置の動作例を説明する図。
【図１７】本発明の実施例２に従った管理装置の他の動作例の流れを示すフローチャート。
【符号の説明】
【０１０６】
１１：ネットワーク
１２：アプリケーションサーバ（処理コンポーネント）
１３：データベース管理システム（サービスコンポーネント）
２１、３１：管理装置
２２：制約情報記憶部（第１の記憶装置（第１の記憶手段）、第２の記憶装置（第２の記憶手段））
２３：制約検査部（機能特定手段、第１の読み出し手段、第２の読み出し手段、条件評価手段）
２４：コンポーネント情報取得部
２５：障害要因判定部（障害要因特定手段）
２６：受信部（障害情報受信手段）
２７：送信部
４１：管理者端末
４２：障害情報入力部
４３：障害情報転送部
４４：要因情報表示部
４５：要因情報受信部
５１：障害情報転送装置（障害情報送信装置）
５２：ログファイル
５３：コンポーネント監視部
５４：障害情報生成情報
５５：障害情報生成部
５６：障害情報転送情報
５７：障害情報転送部
３２：復旧計画部
３３：復旧対象判定部（第２〜第４の条件評価手段、復旧判定手段、操作実行手段）
３４：操作情報記憶部（第３の記憶装置（第３の記憶手段））
【図１】
2010009127.tif 000003
【図２】
2010009127.tif 000004
【図３】
2010009127.tif 000005
【図４】
2010009127.tif 000006
【図５】
2010009127.tif 000007
【図６】
2010009127.tif 000008
【図７】
2010009127.tif 000009
【図８】
2010009127.tif 000010
【図９】
2010009127.tif 000011
【図１０】
2010009127.tif 000012
【図１１】
2010009127.tif 000013
【図１２】
2010009127.tif 000014
【図１３】
2010009127.tif 000015
【図１４】
2010009127.tif 000016
【図１５】
2010009127.tif 000017
【図１６】
2010009127.tif 000018
【図１７】
2010009127.tif 000019