(57)【特許請求の範囲】
【請求項１】
監視対象となる情報処理装置に生じた障害を復旧させる情報処理装置であって、
前記監視対象となる情報処理装置を識別するための装置識別情報と前記監視対象となる情報処理装置のそれぞれに生じた過去の障害を示すエラー情報と前記障害に対する復旧手順とを対応付けて履歴で記憶する記憶部と、
複数の前記監視対象となる情報処理装置から、前記監視対象となる情報処理装置の稼働情報および前記装置識別情報を取得し、取得した前記稼働情報が所定の条件を満たすか否かを判定する動作チェックを行う動作チェック部と、
前記動作チェック部が、前記稼働情報が所定の条件を満たさないと判定したことを受けて、前記装置識別情報をキーとして、前記稼働情報と、前記記憶部に記憶された前記エラー情報とに基づいて、前記装置識別情報と同じ装置識別情報に対応する前記復旧手順にしたがって前記監視対象となる情報処理装置に生じた障害を復旧させるリカバリ部と、を備え、
前記リカバリ部は、前記装置識別情報と同じ装置識別情報に対応する前記復旧手順が存在しない場合、他の前記装置識別情報のなかで同じＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）を有する情報処理装置の装置識別情報に対応する復旧手順の有無を判定し、前記復旧手順があると判定した場合には、その復旧手順にしたがって前記監視対象となる情報処理装置に生じた障害を復旧させ、前記復旧手順がないと判定した場合には、前記稼働情報に含まれるエラーコードに対応付けて記憶されている復旧手順にしたがって、前記監視対象となる情報処理装置に生じた障害を復旧させることを特徴とする情報処理装置。
【請求項２】
前記動作チェック部は、前記稼働情報が所定の条件を満たさないと判定した場合に、前記監視対象となる情報処理装置に障害が生じた旨をあらかじめ定められた管理者に知らせ、
前記リカバリ部は、前記動作チェック部が、前記監視対象となる情報処理装置に障害が生じた旨をあらかじめ定められた管理者に知らせたことを受けて、前記監視対象となる情報処理装置に生じた障害を復旧させる、
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記動作チェック部は、前記稼働情報が所定のしきい値の範囲内にあるか否か、または前記稼働情報が所定のキーワードを含むか否かを判定することによって、前記稼働情報が所定の条件を満たすか否かを判定する、
ことを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記動作チェック部は、前記リカバリ部が前記監視対象となる情報処理装置に生じた障害を復旧させた状態で、前記監視対象となる情報処理装置から稼働情報を取得し、取得した前記稼働情報が所定の条件を満たすか否かを判定し、
前記リカバリ部は、前記障害を復旧させた状態で、前記動作チェック部が、前記稼働情報が所定の条件を満たすと判定した場合、前記復旧手順の優先順位を上げる、
ことを特徴とする請求項１〜３のいずれか１項に記載の情報処理装置。
【請求項５】
前記動作チェック部は、前記稼働情報が所定の条件を満たすと判定した場合において、前記稼働情報が所定の条件を満たさない状態に近いほど、前記動作チェックを短い間隔で行う、
ことを特徴とする請求項１〜４のいずれか１項に記載の情報処理装置。
【請求項６】
前記監視対象となる情報処理装置の稼働状況を所定の間隔で監視し、前記稼働情報が所定の条件を満たすか否かを判定するパフォーマンス部をさらに備え、
前記動作チェック部は、前記パフォーマンス部が、前記稼働情報が所定の条件を満たさないと判定した場合に、前記監視対象となる情報処理装置に障害が生じた旨をあらかじめ定められた管理者に知らせ、
前記リカバリ部は、前記動作チェック部が、前記監視対象となる情報処理装置に障害が生じた旨をあらかじめ定められた管理者に知らせたことを受けて、前記監視対象となる情報処理装置に生じた障害を復旧させる、
ことを特徴とする請求項１〜５のいずれか１項に記載の情報処理装置。
【請求項７】
監視対象となる情報処理装置に生じた障害を復旧させる情報処理装置で行われる障害モニタリング・自動復旧方法であって、
複数の前記監視対象となる情報処理装置から、前記監視対象となる情報処理装置の稼働情報および前記監視対象となる情報処理装置を識別するための装置識別情報とを取得し、取得した前記稼働情報が所定の条件を満たすか否かを判定する動作チェックを行う動作チェックステップと、
前記動作チェックステップにおいて、前記稼働情報が所定の条件を満たさないと判定したことを受けて、前記装置識別情報をキーとして、前記稼働情報と、記憶部に前記障害に対する復旧手順に対応付けて履歴で記憶された前記監視対象となる情報処理装置のそれぞれに生じた過去の障害を示すエラー情報と前記装置識別情報とに基づいて、前記装置識別情報と同じ装置識別情報に対応する前記復旧手順にしたがって前記監視対象となる情報処理装置に生じた障害を復旧させるリカバリステップと、を含み、
前記リカバリステップにおいて、前記装置識別情報と同じ装置識別情報に対応する前記復旧手順が存在しない場合、他の前記装置識別情報のなかで同じＯＳを有する情報処理装置の装置識別情報に対応する復旧手順の有無を判定し、前記復旧手順があると判定した場合には、その復旧手順にしたがって前記監視対象となる情報処理装置に生じた障害を復旧させ、前記復旧手順がないと判定した場合には、前記稼働情報に含まれるエラーコードに対応付けて記憶されている復旧手順にしたがって、前記監視対象となる情報処理装置に生じた障害を復旧させる、ことを特徴とする障害復旧方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ハードウェア、ＯＳ（Operating  System）、アプリケーション、システムなどの稼動状況を監視し、障害発生時に自動で復旧を行う情報処理装置、および障害復旧方法に関するものである。
【背景技術】
【０００２】
従来、ハードウェア、ＯＳ、アプリケーション、システム等に障害が生じた場合、その障害を復旧するために、障害を監視する端末等の監視装置が、監視対象機器に対して一定時間の間隔で障害の状況を監視し、障害の復旧のためのコマンドを実行する。または、監視装置が、異常を検知した場合に監視対象機器から出力されるログ上のエラーコードを参照し、そのエラーコードに対応する復旧方法をとることによって、障害を復旧させている。
【０００３】
例えば、障害監視を開始する場合、監視装置にインストールされたスケジューラソフト等の障害監視ツールが所定の間隔で監視対象機器の稼働状況をチェックし、監視対象機器から出力されるログファイルの監視や監視対象機器から発行されるメッセージを受信する（例えば、特許文献１）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００３−１５０４０７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上述したような監視対象機器のチェックを行うか否か、あるいはメッセージの受信可否の判断は、サーバの稼働状況によって変動させることが難しいという課題がある。また、障害復旧では、想定されるエラーに対して、予め事前に定義された復旧手順を実行するということが一般的であるが、この場合、人手を介す場合と異なってフレキシブルな対応が難しいという課題がある。
【０００６】
例えば、上述した特許文献１に開示された技術では、システム等の通常運用時はスケジューラソフト等を使用して障害監視を実行できたとしても、システム等の障害発生時や異常時の際において、その状況が短時間で変化するような場合には、固定的にその障害の復旧することは困難であり、人手によって障害を復旧せざるを得ないという問題があった。すなわち、発生状況に応じて、自動的に障害を復旧させることができないという問題があった。
【０００７】
本発明は、上記に鑑みてなされたものであって、発生状況に応じて自動的に障害を復旧させることが可能な情報処理装置、および障害復旧方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上述した課題を解決し、目的を達成するために、本発明にかかる情報処理装置は、監視対象となる情報処理装置に生じた障害を復旧させる情報処理装置であって、前記監視対象となる情報処理装置に生じた過去の障害を示すエラー情報と前記障害に対する復旧手順とを対応付けて履歴で記憶する記憶部と、前記監視対象となる情報処理装置から、前記監視対象となる情報処理装置の稼働情報を取得し、取得した前記稼動情報が所定の条件を満たすか否かを判定する動作チェックを行う動作チェック部と、前記動作チェック部が、前記稼動情報が所定の条件を満たさないと判定したことを受けて、前記稼動情報と、前記記憶部に記憶された前記エラー情報とに基づいて、前記稼動情報に応じた復旧手順を前記記憶部に記憶された前記復旧手順の中から特定し、特定した前記復旧手順にしたがって前記監視対象となる情報処理装置に生じた障害を復旧させるリカバリ部と、を備えたことを特徴とする。
【０００９】
また、本発明は、上記情報処理装置で行われる障害復旧方法である。
【発明の効果】
【００１０】
本発明によれば、発生状況に応じて自動的に障害を復旧させることが可能な情報処理装置、および障害復旧方法を提供することができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施の形態にかかる障害モニタリング・自動復旧システムの構成を示すブロック図である。
【図２】実行制御ＤＢが記憶するコマンドや処理結果の例を示す図である。
【図３】結果判定テーブルが記憶する実行条件や判定条件の例を示す図である。
【図４】コマンドテーブルが記憶するコマンドの具体的な内容や判断方法の例を示す図である。
【図５】キーワードテーブルが記憶するキーワードの具体的な内容の例を示す図である。
【図６】サーバ情報テーブルが記憶する設定情報の例を示す図である。
【図７】通知先テーブルが記憶する通知先に関する情報の例を示す図である。
【図８】スケジュールテーブルが記憶するコマンドの実行タイミングに関する情報の例を示す図である。
【図９】パフォーマンスデータＤＢが記憶するパフォーマンスに関する情報の例を示す図である。
【図１０】結果抽出テーブルが記憶する抽出条件の例を示す図である。
【図１１】エラー管理ＤＢがリカバリに関する情報を記憶する例を示す図である。
【図１２】障害管理テーブルが記憶するリカバリ結果に関する情報の例を示す図である。
【図１３】動作チェック処理部が行う動作チェック処理の処理手順を示すフローチャートである。
【図１４】パフォーマンスデータ収集部が行うパフォーマンスデータ収集処理の処理手順を示すフローチャートである。
【図１５】リカバリ部が行うリカバリ処理の処理手順を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下に添付図面を参照して、本発明にかかる情報処理装置、および障害復旧方法の実施の形態を詳細に説明する。
【００１３】
図１は、本発明の実施の形態にかかる障害モニタリング・自動復旧システム１０００の構成を示すブロック図である。図１に示すように、障害モニタリング・自動復旧システム１０００は、Ｗｉｎｄｏｗｓ（登録商標）サーバ１０１と、Ｕｎｉｘ（登録商標）サーバ１０２と、ＤＢ（DataBase）サーバ１０３と、アプリケーションサーバ１０４と、共通監視端末２５１と、ネットワークＮとを含んで構成される。なお、ネットワークＮは、ＬＡＮ（Local  Area  Network）やＷＡＮ（Wide  Area  Network）等の一般的な通信回線網である。また、以下では、障害モニタリング・自動復旧システム１０００は上述した各種のサーバを監視対象としているが、これらのＯＳやデータベースを備えた装置に限定されるものではない。
【００１４】
Ｗｉｎｄｏｗｓサーバ１０１およびＵｎｉｘサーバ１０２は、障害モニタリング・自動復旧システム１０００の監視対象となるサーバ（以下、単に監視対象サーバと呼ぶ。）であって、例えば、アプリケーションサーバ１０４に登録されている種々のアプリケーションを実行するものである。ＤＢサーバ１０３は、例えば、外部のアプリケーションで生成されたデータを記憶するものである。また、アプリケーションサーバ１０４は、例えば、上述したＷｉｎｄｏｗｓサーバ１０１およびＵｎｉｘサーバ１０２において実行される種々のアプリケーションを記憶するものである。
【００１５】
共通監視端末２５１は、上述した各監視対象サーバを監視し、各監視対象サーバに障害が生じた場合に、その障害を自動的に復旧させるＰＣ（Personal  Computer）等の端末である。図１に示すように、共通監視端末２５１は、制御部２０１と、記憶部３５０とを含んで構成されている。制御部２０１は、ＣＰＵ（Central  Processing  Unit）等の演算装置から構成され、動作チェック部３０１と、パフォーマンスデータ収集部３０２と、リカバリ部３０３と、通信部３０４とを含んで構成されている。なお、制御部２０１は、現在の日時（時刻）を計時するタイマ（不図示）を有しているものとする。また、通信部３０４は、例えば、ＮＩＣ（Network  Interface  Card）等の通信装置である。
【００１６】
また、記憶部３５０は、ＨＤＤ（Hard  Disk  Drive）等の記憶媒体から構成され、実行制御ＤＢ３５１と、結果判定テーブル３５２と、コマンドテーブル３５３と、キーワードテーブル３５４と、サーバ情報テーブル３５５と、通知先テーブル３５６と、スケジュールテーブル３５７と、パフォーマンスＤＢ３５８と、結果抽出テーブル３５９と、エラー管理ＤＢ３６０と、障害管理テーブル３６１とを記憶している。
【００１７】
実行制御ＤＢ３５１は、図１に示した監視対象サーバに対して実行させるコマンドや、コマンドによって実行された動作チェック処理、パフォーマンスデータ収集処理、リカバリ処理（いずれも後述）の処理結果を記憶するものである。
【００１８】
図２は、実行制御ＤＢ３５１が記憶するコマンドや処理結果の例を示す図である。図２に示すように、実行制御ＤＢ３５１は、監視対象サーバを一意に識別するための対象サーバと、監視対象サーバに対して実行させるためのコマンドと、監視対象サーバのＯＳ（Operating  System）の種別を示すサーバタイプと、コマンドが実行された日時を示す実行日時と、実行されたコマンドによって取得された実行結果を示す取得値と、コマンドが実行された際の監視対象サーバの状態の種類を示すステータスと、監視対象サーバの状態に応じてコマンドの実行間隔を変更するか否かを示す時間変動フラグと、コマンドが実行されてから次に実行されるまでの間隔を示す次回実行間隔とが対応付けて記憶されている。
【００１９】
図２では、例えば、サーバタイプ「ＯＳ１」である対象サーバ「開発サーバ１」に対して、ステータス「Ａ」の状態（後述するが、監視対象サーバが安定稼動している状態）で、コマンド「ＵＢＤＦ０１」が実行日時「２００９／４／１０  ２２：００：００」に実行され、その際に取得値「８０」（％）が取得されたことを示している。また、次回実行されるまでの間隔は「１０分後」であり、状況に応じて実行間隔は変更されない（Ｎｏ）ことを示している。さらに、同じ対象サーバ「開発サーバ１」に対して、コマンド「ＵＳＹＬ０１」が設定され、以下同様に、上述した各項目が設定されていることを示している。
【００２０】
なお、図２に示した例では、実行制御ＤＢ３５１は、実行日時、取得値、ステータスを、コマンドが実行される都度その結果や値を格納できるように、これらを（１）〜（１５）まで保持しているが、特にこの数に限定されることはない。また、上述した実行日時、取得値、ステータス以外の各項目は、例えば、障害モニタリング・自動復旧システム１０００の管理者等によってあらかじめ設定されるものとする。続いて、図１に戻り、結果判定テーブル３５２について説明する。
【００２１】
結果判定テーブル３５２は、監視対象サーバに対して実行されるコマンドの実行条件や、監視対象サーバの状態を判定するための判定条件を記憶するものである。
【００２２】
図３は、結果判定テーブル３５２が記憶する実行条件や判定条件の例を示す図である。図３に示すように、結果判定テーブル３５２は、実行されるコマンドを一意に特定するための実行コマンドと、コマンドを実行させる監視対象サーバのＯＳの種別を示す対象サーバタイプと、監視対象サーバが正常な状態（例えば、ＯＳのエラーがない状態）であって、安定稼動している場合におけるコマンドの実行間隔を示すステータスＡと、監視対象サーバが正常である場合におけるコマンドの実行間隔を示すステータスＢと、監視対象サーバが正常ではない（警戒時）場合におけるコマンドの実行間隔を示すステータスＣと、監視対象サーバが初期状態にある場合におけるコマンドの実行間隔を示す初期値と、後述する動作チェック処理やパフォーマンスデータ収集処理において、監視対象サーバが安定していると判断すべき稼動状態である（ステータスＡの状態である）と判定するためのしきい値（Ａ）と、監視対象サーバが注意を要すると判断すべき稼動状態である（ステータスＢの状態である）と判定するためのしきい値（Ｂ）と、監視対象サーバがエラーと判断すべき稼動状態である（ステータスＣの状態である）と判定するためのしきい値（Ｃ）と、ステータスＡ〜Ｃにおけるコマンドの実行間隔を見直す回数を示すステータス見直し回数とが対応付けて記憶されている。
【００２３】
図３では、例えば、対象サーバタイプ「ＯＳ１」の監視対象サーバに対して実行される実行コマンド「ＵＢＤＦ０１」は、監視対象サーバが正常な状態であって、安定稼動している場合には「１２時間毎」に実行され、監視対象サーバが正常である場合には「６時間毎」に実行され、監視対象サーバが正常ではない（警戒時）場合には「２時間毎」に実行されることを示している。また、実行コマンド「ＵＢＤＦ０１」が当初実行される間隔は「３時間毎」であることを示している。さらに、後述する動作チェック処理、パフォーマンスデータ収集処理、リカバリ処理において取得された取得値が、しきい値（Ａ）「８０」（％）以上の値であれば、監視対象サーバが正常な状態であって、安定稼動している状態（ステータスＡの状態）であり、その取得値がしきい値（Ｂ）「９０」（％）以上の値であれば、監視対象サーバに注意が必要な状態（ステータスＢの状態）であり、その取得値が「９８」（％）以上の値であれば、監視対象サーバがエラーとなった状態（ステータスＣの状態）であることを示し、コマンドが「１０回」実行された場合にステータスＡ〜Ｃで示されたコマンドの実行間隔が見直されることを示している。なお、上述した結果判定テーブル３５２の各項目は、例えば、障害モニタリング・自動復旧システム１０００の管理者等によってあらかじめ設定されるものとする。続いて、図１に戻り、コマンドテーブル３５３について説明する。
【００２４】
コマンドテーブル３５３は、実行するコマンドの具体的な内容や、コマンドを実行した際に監視対象サーバの状態を判断するための判断方法を記憶するものである。
【００２５】
図４は、コマンドテーブル３５３が記憶するコマンドの具体的な内容や判断方法の例を示す図である。図４に示すように、コマンドテーブル３５３は、実行するコマンドを一意に識別するためのコマンドＩＤと、コマンドが実行された際に監視対象サーバの状態を判断するための判断方法を示す判断種別と、上述した対象サーバタイプと、実際に実行されるコマンドと、そのコマンドを実行する際のオプション情報（引数等）とが対応付けて記憶されている。
【００２６】
図４では、例えば、対象サーバタイプ「ＯＳ１」の監視対象サーバに対して実行される実行コマンド「ＵＢＤＦ０１」は、監視対象サーバの状態を判断するための判断方法として「しきい値」によって判断し、実際に実行されるコマンドは「ｄｂｆ」であり、引数は指定されていないことを示している。また、各監視対象サーバ共通に実行される実行コマンド「ＣＤＢＣ０１」は、判断方法としてコマンド実行時に出力されるログを確認すること（「ログ確認」）によって判断し、実際に実行されるコマンドは「ｂｒｃｏｎｎｅｃｔ」であり、引数「−ｕ／−ｃ−ｆ  ｃｈｅｃｋ」が指定されることを示している。なお、上述したコマンドテーブル３５３の各項目は、結果判定テーブル３５２等と同様、障害モニタリング・自動復旧システム１０００の管理者等によってあらかじめ設定されるものとする。続いて、図１に戻り、キーワードテーブル３５４について説明する。
【００２７】
キーワードテーブル３５４は、コマンドが実行された際に出力されるログに含まれる数値や文字列、符号等の種々の情報（キーワード）をアラームとして記憶するものである。
【００２８】
図５は、キーワードテーブル３５４が記憶するキーワードの具体的な内容の例を示す図である。図５に示すように、キーワードテーブル３５４は、上述した実行コマンドと、ログに含まれるキーワードのうち、エラーとすべきキーワードを示すエラーキーワードと、ログに含まれるキーワードのうち、注意するレベルで足り、エラーとするレベルではないキーワードを示す無視キーワードとが対応付けて記憶されている。
【００２９】
図５では、例えば、実行コマンド「ＣＤＢＣ０１」が実行され、出力されたログにエラーキーワード「ＯＲＡ−０１５５５」、「ＯＲＡ−０００６０」、「ＯＲＡ−０１６３１」が含まれている場合にはエラーとなる一方、出力されたログに無視キーワード「ＯＲＡ−２３７０１」、「ＯＲＡ−０３１０６」、「ＯＲＡ−０１４２８」が含まれている場合にはエラーとはならずにそのまま処理が続行されることを示している。なお、上述したキーワードテーブル３５４の各項目は、結果判定テーブル３５２等と同様、障害モニタリング・自動復旧システム１０００の管理者等によってあらかじめ設定されるものとする。続いて、図１に戻り、サーバ情報テーブル３５５について説明する。
【００３０】
サーバ情報テーブル３５５は、監視対象サーバに関する種々の設定情報を記憶するものである。
【００３１】
図６は、サーバ情報テーブル３５５が記憶する設定情報の例を示す図である。図６に示すように、サーバ情報テーブル３５５は、監視対象サーバのホスト名と、監視対象サーバのＩＰアドレスと、監視対象サーバのＯＳ種別と、監視対象サーバの用途を示す用途タイプと、監視対象サーバの用途タイプが「ＤＢ」である場合のインスタンス名と、管理対象サーバにアクセス可能な管理者のアカウント（管理ユーザアカウント）およびパスワード（管理ユーザパスワード）と、ＤＢにアクセス可能なユーザのアカウント（ＤＢユーザアカウント）およびパスワード（ＤＢユーザパスワード）とが対応付けて記憶されている。
【００３２】
図６では、例えば、ホスト名「開発サーバ１」、ＯＳ種別「ＯＳ１」である監視対象サーバのＩＰアドレスは「ＡＡＡ．ＡＡＡ．ＡＡＡ．ＡＡＡ」であり、インスタンス名「ＢＳＣ」のＤＢサーバとして設定されていることを示している。また、このサーバの管理ユーザアカウントおよび管理ユーザパスワードは、それぞれ「ｒｏｏｔ」「ＡＡＡＡＡＡＡ」であり、ＤＢユーザアカウントおよびＤＢユーザパスワードは、それぞれ「ｂｓｃａｄｍ」「ＡＡＡＡＡＡＡ」であることを示している。上述したサーバ情報テーブル３５５の各項目は、結果判定テーブル３５２等と同様、障害モニタリング・自動復旧システム１０００の管理者等によってあらかじめ設定されるものとする。続いて、図１に戻り、通知先テーブル３５６について説明する。
【００３３】
通知先テーブル３５６は、監視対象サーバがエラーや障害となった場合に、その旨を通知する通知先に関する情報を記憶するものである。
【００３４】
図７は、通知先テーブル３５６が記憶する通知先に関する情報の例を示す図である。図７に示すように、通知先テーブル３５６は、通知先にエラーや障害となった旨を通知する対象サーバと、エラーコードと、通知する方法を示す連絡先手段と、エラーや障害となった旨を通知する連絡先宛先と、その宛先の氏名・名称を示す連絡先登録者名とが対応付けて記憶されている。
【００３５】
図７では、例えば、対象サーバ「開発サーバ１」にエラーコード「ＯＲＡ−１５５５」のエラーが生じた場合、登録者「ＡＡＡＡ」に対して電話で「０２９−ＸＸＸ−ＸＸＸＸ」まで通知することを示している。なお、図７では、通知先の登録者が不在等の理由で連絡が付かない場合に備え、予備の連絡先（連絡先５まで）を記憶している。ここに示した各項目は、結果判定テーブル３５２等と同様、障害モニタリング・自動復旧システム１０００の管理者等によってあらかじめ設定されるものとする。続いて、図１に戻り、スケジュールテーブル３５７について説明する。
【００３６】
スケジュールテーブル３５７は、コマンドを実行するタイミングに関する情報を記憶するものである。
【００３７】
図８は、スケジュールテーブル３５７が記憶するコマンドの実行タイミングに関する情報の例を示す図である。図８に示すように、スケジュールテーブル３５７は、コマンドの実行日と、コマンドの実行時刻と、コマンドを実行する監視対象サーバを示す対象サーバと、実行コマンドとが対応付けて記憶されている。
【００３８】
図８では、例えば、実行コマンド「ＵＢＤＦ０１」を実行するタイミングは、「２００９／０１／０１」の「００時００分」であり、「開発サーバ１」を対象サーバとして実行することを示している。ここに示した各項目は、結果判定テーブル３５２等と同様、障害モニタリング・自動復旧システム１０００の管理者等によってあらかじめ設定されるものとする。続いて、図１に戻り、パフォーマンスデータＤＢ３５８について説明する。
【００３９】
パフォーマンスデータＤＢ３５８は、監視対象サーバの稼働状況（パフォーマンス）に関する情報を記憶するものである。
【００４０】
図９は、パフォーマンスデータＤＢ３５８が記憶するパフォーマンスに関する情報の例を示す図である。図９に示すように、パフォーマンスデータＤＢ３５８は、監視対象サーバのパフォーマンスをチェックする種類（どのようなチェックを行うか）を一意に特定するための識別ＩＤと、識別ＩＤで識別されるチェックのチェック内容と、上述した対象サーバおよび実行コマンドと、コマンドの実行間隔およびその実行結果とが対応付けて記憶されている。なお、図９で示した例では、実行間隔および実行結果は１〜１０まで登録されているが、この数に限定されるものではない。
【００４１】
図９では、例えば、識別ＩＤ「ＨＷ００１」で識別される実行コマンド「ＵＢＤＦ０１」が、サーバ「開発サーバ１」を対象として、メモリ使用率を１分ごとに実行されることを示している。そして、その実行結果として、３５（％）あるいは５０（％）等の値が格納されていることを示している。なお、実行結果については、後述するパフォーマンスデータ収集処理において設定され、これら以外の各項目は、結果判定テーブル３５２等と同様、障害モニタリング・自動復旧システム１０００の管理者等によってあらかじめ設定されるものとする。このように、実行結果を定期的に繰り返し登録しておくことによって、例えば、管理者はメモリ使用率の推移を容易に把握することができる。続いて、図１に戻り、結果抽出テーブル３５９について説明する。
【００４２】
結果抽出テーブル３５９は、後述する動作チェック処理、パフォーマンスデータ収集処理が実行され、その結果として出力されたログ等に含まれる種々の情報のうち、障害モニタリング・自動復旧システム１０００が必要とする情報のみを抽出するため抽出条件を記憶するものである。
【００４３】
図１０は、結果抽出テーブル３５９が記憶する抽出条件の例を示す図である。図１０に示すように、結果抽出テーブル３５９は、実行コマンドと、ログ等に含まれる種々の情報の中から必要な情報のみ解析して抽出するための抽出キーワードと、抽出キーワードによって抽出された情報を集計する場合の集計条件とが対応付けて記憶されている。
【００４４】
図１０では、例えば、実行コマンド「ＵＢＤＦ０１」が実行された際に出力されるログ等の情報の中から、「ｃｐｕ」および「ｕｓ」の２つの文字列を含む文字列（あるいは、その文字列を含む段落等のかたまり）が抽出されることを示している。なお、図１０に示した例では、抽出キーワードとして５つのキーワードが設定されている。これらの各項目は、結果判定テーブル３５２等と同様、障害モニタリング・自動復旧システム１０００の管理者等によってあらかじめ設定されるものとする。続いて、図１に戻り、エラー管理ＤＢ３６０について説明する。
【００４５】
エラー管理ＤＢ３６０は、後述するリカバリ処理において、エラーに応じたリカバリを行うためのリカバリに関する情報を記憶するものである。このエラー管理ＤＢ３６０は、自動的に登録されるものではなく、過去に同様のリカバリ手順が存在しない場合に備えて管理者等によってあらかじめ登録されているものである。
【００４６】
図１１は、エラー管理ＤＢ３６０がリカバリに関する情報を記憶する例を示す図である。図１１に示すように、エラー管理ＤＢ３６０は、監視対象サーバから出力されるログ等に含まれるエラーの内容を示すエラーコードと、上述した対象サーバと、リカバリ処理を実行させる優先順位を示す対応順序と、通知先テーブル３５６に登録された宛先に通知するメッセージを示す通知内容と、動作チェック処理において実行されたコマンドを示すチェック時実行コマンドと、エラーをリカバリする手順を含むコマンドを示すリカバリ手順とが対応付けて記憶されている。
【００４７】
図１１では、「ＯＳ１」の対象サーバに対して動作チェック処理時の実行コマンド「ＵＢＤＦ０１」が実行され、そのログ等にエラーコード「ＯＲＡ−０１６３１」が含まれている場合、管理者等に対しては「テーブル・索引がＭａｘＥｘｔｅｎｔ（＊＊＊）に到達」した旨が通知されるとともに、リカバリ手順としてコマンド「Ｒ３３ＴＣＤＢ１３」が実行されることを示している。また、同じ「ＯＳ１」の対象サーバに対して動作チェック処理時の実行コマンド「ＵＰＳＣ０１」が実行され、そのログ等にエラーコード「ＯＲＡ−０１６３１」が含まれている場合、管理者等に対しては「テーブル・索引がＭａｘＥｘｔｅｎｔ（＊＊＊）に到達」した旨が通知されるとともに、リカバリ手順としてコマンド「ＯＲＡＥＸＴＣＨ０１」が実行されることを示している。そして、この２つのエラーが同じタイミングで発生した場合には、対応順序が「１」であるコマンド「Ｒ３３ＴＣＤＢ１３」が実行され、その後、対応順序が「２」であるコマンド「ＯＲＡＥＸＴＣＨ０１」が実行されることを示している。これらの各項目は、結果判定テーブル３５２等と同様、障害モニタリング・自動復旧システム１０００の管理者等によってあらかじめ設定されるものとする。続いて、図１に戻り、障害管理テーブル３６１について説明する。
【００４８】
障害管理テーブル３６１は、リカバリ処理で実行されたリカバリ結果に関する情報を記憶するものである。
【００４９】
図１２は、障害管理テーブル３６１が記憶するリカバリ結果に関する情報の例を示す図である。図１２に示すように、障害管理テーブル３６１は、上述したエラーコードと、リカバリ処理が行われた監視対象サーバを示す実施サーバと、リカバリ処理が開始された日時を示す実施日時と、リカバリ処理で行われた手順を示すリカバリ手順と、リカバリ処理が完了した際のチェック手順を示す確認手順と、リカバリ処理が完了した日時を示す完了日時とが対応付けて記憶されている。
【００５０】
図１２では、例えば、監視対象サーバ「開発サーバ５」に、エラーコード「ＯＲＡ−０１６３１」のエラーが生じた場合のリカバリ処理として、実施日時「２００８／１２／３１  １８時３０分」から完了日時「２００８／１２／３１  ２１時３０分」まで「Ｅｘｔｅｎｔ拡張」が行われたことを示している。また、リカバリ処理の結果を「ＤＢＣｈｅｃｋ」で確認する手順となっていることを示している。なお、リカバリ手順および確認手順は、実際には「ＡＢＣＤ」「１２３４」等のコードとして障害管理テーブル３６１に記憶されている。これらの各項目は、リカバリ処理実行時に設定されるものとする。続いて、図１に戻り、動作チェック部３０１について説明する。
【００５１】
動作チェック部３０１は、監視対象となる各サーバの稼動状態をチェックするためのヘルスチェックを行うと共に、各サーバから出力される各種ログ情報から動作状況を確認するものである。動作チェック部３０１は、上述した実行制御ＤＢ３５１、結果判定テーブル３５２、コマンドテーブル３５３、キーワードテーブル３５４、サーバ情報テーブル３５５、通知先テーブル３５６、スケジュールテーブル３５７等の各種のテーブルを参照して後述する種々の処理を行う。なお、各種ログ情報とは、例えば、上述した各サーバに記憶されるイベントログ、アクセスログ、システムログ、エラーログ）、ＤＢアラートログ、サーバ稼働情報ログ、アプリケーションログ、ジョブログ等がある。
【００５２】
パフォーマンスデータ収集部３０２は、監視対象となる各サーバが備えているリソースの使用状況や、各サーバの稼働情報を収集し、収集した各サーバの稼働状況をモニタリングするものである。パフォーマンスデータ収集部３０２は、結果判定テーブル３５２、コマンドテーブル３５３、サーバ情報テーブル３５５、スケジュールテーブル３５７、パフォーマンスＤＢ３５８、結果抽出テーブル３５９等の各種のテーブルを参照して、後述する種々の処理を行う。
【００５３】
リカバリ部３０３は、動作チェック部３０１やパフォーマンスデータ収集部３０２が監視対象となる各サーバの異常を検知した際に、その異常の状況を解析し、その状況に応じた対応を実行するものである。リカバリ部３０１は、コマンドテーブル３５３と、通知先テーブル３５６と、エラー管理ＤＢ３６０と、障害管理テーブル３６１等の各種のテーブルを参照して、後述する種々の処理を行う。また、リカバリ部３０３は、各サーバの異常を検知した際には、あらかじめ登録されている障害モニタリング・自動復旧システム１０００のサーバ管理者４０１や保守業者４０２宛に電話やメール等で異常が生じた旨の通知を行う。
【００５４】
続いて、障害モニタリング・自動復旧システム１０００で行われる処理について説明する。まず、動作チェック部が３０１行う動作チェック処理について説明する。
図１３は、動作チェック処理部３０１が行う動作チェック処理の処理手順を示すフローチャートである。なお、以下では、監視対象となる各サーバ等の装置はあらかじめ定められ、また、障害モニタリング・自動復旧システム１０００が所定のタイミングで起動されているものとする。
【００５５】
図１３に示すように、動作チェック処理部３０１は、まず、スケジュールテーブル３５７を参照し（ステップＳ１１５１）、現在時刻と、実行日および時刻とを比較して、対象サーバが実行コマンドを実行すべきタイミングであるか否かを判定する（ステップＳ１１５２）。
【００５６】
そして、動作チェック部３０１は、実行コマンドを実行すべき実行タイミングであると判定した場合（ステップＳ１１５１；Ｙｅｓ）、サーバ情報テーブル１１０２を参照し、スケジュールテーブル３５７の対象サーバのホスト名を特定し、特定したホスト名と同じレコードの情報（ＩＰアドレス、ホスト名、各種のアカウントやパスワード等）のログイン情報を含む対象サーバ情報を読み込む（ステップＳ１１５４）。
【００５７】
一方、動作チェック部３０１は、実行コマンドを実行すべき実行タイミングではないと判定した場合（ステップＳ１１５１；Ｎｏ）、実行タイミングとなるまで待機する。なお、後述するように、この時点でリカバリ部３０３がリカバリ処理を実行していた場合（ステップＳ１１５３）、ステップＳ１１５１〜Ｓ１１５２を行わず（実行タイミングの判定を行わず）に、即時にステップＳ１１５４以降の処理を行う。
【００５８】
続いて、動作チェック部３０１は、スケジュールテーブル３５７の実行コマンドとサーバ情報テーブル３５５のＯＳ種別とをキーとしてコマンドテーブル３５３を参照し、その実行コマンドとＯＳ種別に一致するレコードに含まれるコマンドおよびオプション（すなわち、実際に実行されるコマンドやオプション。以下、コマンド詳細情報と呼ぶ。）を取得する（ステップＳ１１５５）。
【００５９】
そして、動作チェック部３０１は、取得したコマンド詳細情報を、ステップＳ１１５４で取得した対象サーバ情報に示されたサーバに送信し、サーバに送信したコマンドを実行させ（ステップＳ１１５８）、そのコマンドの実行結果を取得する（ステップＳ１１５９）。
【００６０】
ここで、実行結果は単純にコマンドを実行した結果であるため、サーバの動作チェックには不要な情報も含まれている。したがって、動作チェック部３０１は、実行したコマンドをキーとして結果抽出テーブル３５９を参照し、実行したコマンドに一致する実行コマンドを含むレコードを特定し、特定したレコードに含まれる抽出キーワードに関する情報のみを抽出して加工する（ステップＳ１１６０）。
【００６１】
各種ログ情報に含まれている正常終了・異常終了・単純な操作等を示す情報が含まれているため、このように、動作チェック部３０１が、上述した抽出キーワードに関する情報のみを抽出した上で動作チェックを行うことによって、より精度の高い結果を得ることができる。
【００６２】
ステップＳ１１６０の処理が終了すると、動作チェック部３０１は、実行したコマンドをキーとしてコマンドテーブル３５３を参照し、そのコマンドに一致するコマンドＩＤを含むレコードを特定し、特定したレコードに含まれる判断種別がしきい値であるか否か（すなわち、実行結果をしきい値によって確認するか否か）を判定する（ステップＳ１１６１）。
【００６３】
動作チェック部３０１は、実行結果をしきい値によって確認すると判定した場合（ステップＳ１１６１；Ｙｅｓ）、結果判定テーブル３５２のしきい値（Ａ）〜（Ｃ）を読み取り（ステップＳ１１６３）、実行結果が、読み取ったしきい値（Ａ）〜（Ｃ）のうちのいずれの範囲に該当するか否かを判定したのち、しきい値（Ｃ）の値を超えた範囲にあるか否かを判定する（ステップＳ１１６４）。
【００６４】
そして、動作チェック部３０１は、実行結果が、しきい値（Ｃ）の値を超えた範囲にあると判定した場合（ステップＳ１１６４；Ｙｅｓ）、そのサーバの稼動状態が異常であると判定し、ステップＳ１１７１に進む。なお、後述するパフォーマンスデータ収集処理で異常と検知した場合も、ステップＳ１１６４と同様に、ステップＳ１１７１に進む（ステップＳ１１６２）。
【００６５】
一方、動作チェック部３０１は、実行結果が、しきい値（Ｃ）の値を超えた範囲にないと判定した場合（ステップＳ１１６４；Ｎｏ）、そのサーバは異常な稼動状態ではないと判定（サーバの動作確認が正常に終了したと判定）し、実行結果を実行制御ＤＢ３５１の取得値およびステータスに格納する（ステップＳ１１６５）。
【００６６】
その後、動作チェック部３０１は、動作チェックの次回実行時間を設定するため、実行制御ＤＢ３５１と結果判定テーブル３５２とを参照し、そのコマンドを次回実行させるタイミングを決定し、その結果をスケジュールテーブル３５７および実行制御ＤＢ３５１に格納する（ステップＳ１１６６）。
【００６７】
例えば、ステップＳ１１６４において、実行コマンド「ＵＢＤＦ０１」の実行結果が「８０％」であった場合、そのサーバのステータスは「Ａ」であるため、図３に示す結果判定テーブル３５２のステータスＡを参照し、コマンド「ＵＢＤＦ０１」を「１２時間毎」に実行させるように、そのタイミングを設定する。
【００６８】
これと同様に、実行コマンド「ＵＢＤＦ０１」の実行結果が「９０％」であった場合には、そのサーバのステータスは「Ｂ」であるため、結果判定テーブル３５２のステータスＢを参照し、コマンド「ＵＢＤＦ０１」を「６時間毎」に実行させるように、そのタイミングを設定し、実行コマンド「ＵＢＤＦ０１」の実行結果が「９８％」であった場合には、そのサーバのステータスは「Ｃ」であるため、結果判定テーブル３５２のステータスＣを参照し、コマンド「ＵＢＤＦ０１」を「３時間毎」に実行させるように、そのタイミングを設定する。このように、サーバの稼動状態が異常な状態（危険な状態）に近づくにつれて、コマンドを実行させる間隔を短くし、サーバの稼動状態を迅速に把握することができるようになっている。
【００６９】
その後、動作チェック部３０１は、リカバリ処理が起動して実行された状態で、動作チェック処理を行っているか否か（すなわち、動作チェックが単体で実行されたものであるか、リカバリ処理の一環として実行されたものであるか）を判定し（ステップＳ１１６７）、動作チェックがリカバリ処理の一環として実行されていないと判定した場合（ステップＳ１１６７；Ｎｏ）、処理を終了させる。
【００７０】
一方、動作チェック部３０１は、動作チェックがリカバリ処理の一環として実行されていると判定した場合（ステップＳ１１６７；Ｙｅｓ）、図１５に示すリカバリ処理に進む（ステップＳ１１６８）。
【００７１】
動作チェック部３０１は、ステップＳ１１６１において、実行結果をしきい値によって確認しないと判定した（すなわち実行結果を各種ログ情報によって確認すると判定した）場合（ステップＳ１１６１；Ｎｏ）、キーワードテーブル１１１２を参照し、各種ログ情報の中からステップＳ１１５７において実行されたコマンドに一致する実行コマンドを読み込んで特定し（ステップＳ１１６９）、そのコマンドの実行結果にエラーがあり、そのエラーがキーワードテーブル３５４のエラーキーワードとして登録されているものであるか否か（すなわち、実行結果にエラーが存在し、そのエラーが無視できないものであるか否か）を判定する（ステップＳ１１７０）。
【００７２】
そして、動作チェック部３０１は、実行結果にエラーが存在せず、もしくはそのエラーが無視できないものではない（例えば、実行結果にエラーが存在しても、そのエラーが無視キーワードである場合等）と判定した場合（ステップＳ１１７０；Ｎｏ）、上述したステップＳ１１６５に進む。
【００７３】
一方、動作チェック部３０１は、実行結果にエラーが存在し、もしくはそのエラーが無視できないものである（例えば、実行結果にエラーが存在し、そのエラーがエラーキーワードである場合等）と判定した場合（ステップＳ１１７０；Ｙｅｓ）、通知先テーブル３５６を参照し、ステップＳ１１５４で取得した対象サーバ情報に含まれるホスト名に一致する対象サーバを特定し（ステップＳ１１７１）、特定した対象サーバの連絡先として登録された宛先に通報する（ステップＳ１１７２）。
【００７４】
その後、動作チェック部３０１は、ステップＳ１１６５、Ｓ１１６６の場合と同様に、実行結果を実行制御ＤＢ３５１に格納し（ステップＳ１１７３）、そのコマンドを次回実行させるタイミングを決定し、その結果をスケジュールテーブル３５７および実行制御ＤＢ３５１に格納する（ステップＳ１１７４）。このステップＳ１１７４の処理、またはステップＳ１１６７の処理が終了すると、図１３に示す動作チェック処理の全ての処理が終了する。続いて、パフォーマンスデータ収集部３０２が行うパフォーマンスデータ収集処理について説明する。
【００７５】
図１４は、パフォーマンスデータ収集部３０２が行うパフォーマンスデータ収集処理の処理手順を示すフローチャートである。
【００７６】
図１４に示すように、パフォーマンスデータ収集部３０２は、スケジュールテーブル３５７を読み込み（ステップＳ１２５１）、スケジュールテーブル３５７の実行日と、現在時刻とを比較し、パフォーマンスデータ収集処理の実行タイミングであるか否かを判定する（ステップＳ１２５２）。
【００７７】
そして、パフォーマンスデータ収集部３０２は、パフォーマンスデータ収集処理の実行タイミングであると判定した場合（ステップＳ１２５２；Ｙｅｓ）、さらに、サーバ情報テーブル３５５を読み込んで、スケジュールテーブル３５７の対象サーバと同じホスト名とＯＳ種別と含む対象サーバ情報を取得する（ステップＳ１２５３）。
【００７８】
その後、パフォーマンスデータ収集部３０２は、コマンドテーブル３５３を参照し、ステップＳ１２５１で読み込んだスケジュールテーブル３５７に含まれる実行コマンドと、ステップＳ１２５３で取得したＯＳ種別に一致するレコードに含まれるコマンドを特定し（ステップＳ１２５４）、そのコマンドを実行するための実行ファイル（実行コマンド）を生成する（ステップＳ１２５５）。
【００７９】
具体的には、パフォーマンスデータ収集部３０２は、ステップＳ１２５１においてスケジュールテーブル３５７の対象サーバ（例えば、開発サーバ１）、実行コマンド（例えば、ＵＢＤＦ０１）を読み込み、読み込んだ対象サーバをキーとして、さらに、ステップＳ１２５３において、サーバ情報テーブル３５５のＯＳ種別（例えば、ＯＳ１）を読み込む。その後、パフォーマンスデータ収集部３０２は、ステップＳ１２５４において、実行コマンドとＯＳ種別とをキーとして、さらに、コマンドテーブル３５３のコマンド（例えば、ｄｂｆ）を取得し、取得したコマンドを実行させるためのファイルを生成する。
【００８０】
パフォーマンスデータ収集部３０２は、ステップＳ１２５５で生成したファイルを対象となるサーバに送信して処理を実行させ（ステップＳ１２５６、Ｓ１２５７）、その実行結果を取得し、対象サーバおよび実行コマンド（例えば、開発サーバ１、ＵＢＤＦ０１）をキーとして、その実行結果（例えば、３５（％））をパフォーマンスデータＤＢ３５８に登録する（ステップＳ１２５８）。
【００８１】
ここで、実行結果は単純にコマンドを実行した結果であるため、サーバのパフォーマンスデータの収集には不要な情報も含まれている。したがって、パフォーマンスデータ収集部３０２は、実行したコマンドをキーとして結果抽出テーブル３５９を参照し、図１３に示したステップＳ１１６０の場合と同様に、実行したコマンドに一致する実行コマンドを含むレコードを特定し、特定したレコードに含まれる抽出キーワードに関する情報のみを抽出して加工する（ステップＳ１２５９）。
【００８２】
さらに、パフォーマンスデータ収集部３０２は、取得した実行結果が異常である場合も存在するため、実行コマンド（例えば、ＵＢＤＦ０１）およびＯＳ種別（例えば、ＯＳ１）をキーとして結果判定テーブル３５２を読み込んで、その実行コマンドおよびＯＳ種別に一致する実行コマンドおよび対象サーバタイプを含むレコードを特定し、そのレコードのしきい値（例えば、８０（％以上）、９０（％以上）、９８（％以上））を取得するとともに（ステップＳ１２６０）、ステップＳ１２５８で取得した実行結果を、対象サーバ、コマンド、対象サーバタイプ（例えば、開発サーバ１、ＵＢＤＦ０１、ＯＳ１）をキーとして実行制御ＤＢ３５１に登録する（ステップＳ１２６１）。
【００８３】
その後、パフォーマンスデータ収集部３０２は、ステップＳ１２５８で取得した実行結果が、ステップＳ１２６０で取得したしきい値を満たしているか否か（しきい値を超えているか否か）を判定し（ステップＳ１２６２）、実行結果がしきい値を超えていないと判定した場合（ステップＳ１２６２；Ｎｏ）、実行結果がいずれのしきい値を満たすものであるかを判定し、その結果（取得値、ステータス）を実行制御ＤＢ３５１に登録する（ステップＳ１２６５）。
【００８４】
一方、パフォーマンスデータ収集部３０２は、実行結果がしきい値を超えていると判定した場合（ステップＳ１２６２；Ｙｅｓ）、サーバの稼働状況が異常であると判定し、その結果（取得値、ステータス）を実行制御ＤＢ３５１に登録し（ステップＳ１２６３）、サーバの動作をチェックするために、図１３に示した動作チェック処理に進む（ステップＳ１２６４）。このステップＳ１２６４またはステップＳ１２６５の処理が終了すると、図１４に示したパフォーマンスデータ収集処理の全ての処理が終了する。続いて、リカバリ部３０３が行うリカバリ処理について説明する。
【００８５】
図１５は、リカバリ部３０３が行うリカバリ処理の処理手順を示すフローチャートである。なお、以下に示すリカバリ処理は、それ自体が単独で起動することはなく、図１３に示した動作チェック処理において実行結果に無視できないエラーが存在し、その異常が連絡先として登録された宛先に通報された場合（図１３に示したステップＳ１１７１〜１１７４までの処理が実行された場合）に、自動的に起動するものとする。
【００８６】
図１５に示すように、リカバリ部３０３は、動作チェック処理からリカバリ処理に処理が遷移したタイミングで、通知先テーブル３５６の情報を読み込み（ステップＳ１３５１）、ステップＳ１１７１において参照した通知先テーブル３５６の連絡先として登録された宛先に、リカバリ処理を開始する旨を通報する（ステップＳ１３５２）。
【００８７】
そして、リカバリ部３０３は、図１３に示した動作チェック処理のステップＳ１１５４で取得した対象サーバ情報に含まれるホスト名に一致する対象サーバを取得する（ステップＳ１３５３）。その後、リカバリ部３０３は、取得した対象サーバと障害管理テーブル３６１の実施サーバが一致するレコードを読み込み（ステップＳ１３５４）、読み込んだレコードに含まれるエラーコードをキーとして、障害管理テーブル３６１の中に過去に同じコマンドでエラーが発生しているか確認し（ステップＳ１３５５）、障害管理テーブル３６１に同一の障害履歴が記憶されているか否かを判定する（ステップＳ１３５６）。
【００８８】
リカバリ部３０３は、障害管理テーブル３６１に同一の障害履歴が記憶されていると判定した場合（ステップＳ１３５６；Ｙｅｓ）、記憶されているその障害履歴（エラーコード）に対応するリカバリ手順を選択し、過去の手順を採用する（ステップＳ１３５７）。
【００８９】
例えば、図１３に示した動作チェック処理のステップＳ１１５４で取得した対象サーバ情報が「開発サーバ５」である場合、リカバリ部３０３は、その対象サーバに一致する障害管理テーブル３６１の実施サーバ「開発サーバ５」を含むレコードを読み込む。そして、リカバリ部３０３は、そのレコードに含まれるエラーコード「ＯＲＡ−０１６３１」を参照し、リカバリ手順として「Ｅｘｔｅｎｔ拡張（ＡＢＣＤ）」を採用する。
【００９０】
一方、リカバリ部３０３は、障害管理テーブル３６１に同一の障害履歴が記憶されていないと判定した場合（ステップＳ１３５６；Ｎｏ）、サーバ情報テーブル３５５を参照し、他のサーバの中で同じＯＳ種別のサーバのホスト名と同じ名称を、障害管理テーブル３６１の中から特定し、特定した他のサーバ（実施サーバ）のリカバリ手順を確認する（ステップＳ１３６６）。
【００９１】
そして、リカバリ部３０３は、他のサーバのリカバリ手順があると判定した場合（ステップＳ１３６６；Ｙｅｓ）、ステップＳ１３５７に進み、過去のリカバリ手順を採用した場合と同様に、他のサーバのリカバリ手順を採用する。
【００９２】
一方、リカバリ部３０３は、他のサーバのリカバリ手順がないと判定した場合（ステップＳ１３６６；Ｎｏ）、エラー管理ＤＢ３６０のエラーコードを参照し（ステップＳ１３６７）、エラー管理ＤＢ３６０に同一の障害履歴が記憶されているか否かを判定する（ステップＳ１３６８）。
【００９３】
そして、リカバリ部３０３は、エラー管理ＤＢ３６０に同一の障害履歴が記憶されていると判定した場合（ステップＳ１３６８；Ｙｅｓ）、エラー管理ＤＢ３６０に記憶されているリカバリ手順を採用し（ステップＳ１３６９）、ステップＳ１３５８に進む。
【００９４】
一方、リカバリ部３０３は、エラー管理ＤＢ３６０に同一の障害履歴が記憶されていないと判定した場合（ステップＳ１３６８；Ｎｏ）、自動的なリカバリ処理は困難であるため、図１３に示したステップＳ１１７２の場合と同様に関係者に再度通報を行い（ステップＳ１３７０）、管理者による対応を行う（ステップＳ１３７１）。
【００９５】
ステップＳ１３５７またはステップＳ１３６９が終了すると、ステップＳ１３５７またはステップＳ１３６９で採用したリカバリ手順のコマンド（例えば、障害管理テーブル３６１のリカバリ手順「Ｅｘｔｅｎｔ拡張」を実施した際のコマンド、あるいはエラー管理ＤＢ３６０のリカバリ手順のファイルである「Ｒ３ＲＴＣＤＢ１３」およびエラーコード「ＯＲＡ−０１６３１」に対応するコマンド「ＵＢＤＦ０１」）をコマンドテーブル３５３から取得し（ステップＳ１３５８）、図１４に示したステップＳ１２５５の場合と同様に、取得したコマンドを実行させるためのファイルを生成する（ステップＳ１３５９）。
【００９６】
そして、リカバリ部３０３は、ステップＳ１３５９で生成したファイルを対象となるサーバに送信してリカバリ処理を実行させ（ステップＳ１３６０、Ｓ１３６１）、その実行結果（例えば、そのサーバの各種ログ情報）を取得する（ステップＳ１３６２）。
【００９７】
ステップＳ１３６２の処理が終了すると、そのリカバリ手順の有効性を確認するために、動作チェック部３０１は、図１３に示したステップＳ１１５３（Ａ）〜Ｓ１１６８（Ｄ）までの動作チェック処理を実行する。そして、これらの動作チェック処理が終了すると、リカバリ部３０３は、その動作チェック処理によって、エラーが解消されたか否か（例えば、しきい値（Ｃ）の値を超えた範囲にないか）を判定する（ステップＳ１３６５）。
【００９８】
そして、リカバリ部３０３は、その動作チェック処理によって、エラーが解消されていないと判定した場合（ステップＳ１３６５；Ｎｏ）、ステップＳ１３６９に戻って、エラー管理ＤＢ３６０に記憶されているリカバリ手順を採用し（ステップＳ１３６９）、ステップＳ１３５８に進む。
【００９９】
一方、リカバリ部３０３は、その動作チェック処理によって、エラーが解消されたと判定した場合（ステップＳ１３６５；Ｙｅｓ）、そのリカバリ手順を障害管理テーブル３６１に登録し（ステップＳ１３７２）、エラーコードをキーとして、そのエラーコードが生じた際のリカバリ手順を優先的に実行させるために、エラー管理ＤＢ３６０の対応順序を変更する（ステップＳ１３７３）。
【０１００】
具体的には、図１１に示す例では、対象サーバ「ＯＳ１」のサーバに、エラーコード「ＯＲＡ−０１６３１」が生じた場合、リカバリ手順としては、まず、「Ｒ３ＲＴＣＤＢ１３」のファイルを実行し、次に「ＯＲＡＥＸＴＣＨ０１」のファイルを実行する手順となっているが、例えば、「ＯＲＡＥＸＴＣＨ０１」のファイルを実行した方が、より多くの容量を確保できた場合、短い処理時間でリカバリ処理が実行できた等のように、実行されたリカバリ処理が有効なものである場合には、リカバリ手順の対応順序を入れ替えて、今後障害が生じた場合に「ＯＲＡＥＸＴＣＨ０１」のファイルを実行する手順が先に実行されるように、優先順位を高く設定する。
【０１０１】
そして、リカバリ部３０３は、ステップＳ１３７３までの処理が終了すると、実行制御ＤＢ３５１の各項目をクリアすることによってリセットし（ステップＳ１３７４）、リカバリ処理が完了した旨の連絡を、図１３に示したステップＳ１１７２の場合と同様に関係者に通知する（ステップＳ１３７５、Ｓ１３７６）。このステップＳ１３７６又はステップＳ１３７１の処理が終了すると、図１５に示したリカバリ処理の全ての処理が終了する。
【０１０２】
このように、監視対象となるサーバに生じた障害を復旧させる共通監視端末２５１において、記憶部３５０が、監視対象となるサーバに生じた過去の障害を示すエラーコードと障害に対するリカバリ手順とを対応付けて履歴で記憶し、動作チェック部３０１が、監視対象となるサーバから、監視対象となるサーバの稼働情報を取得し、取得した稼動情報が所定の条件（しきい値、キーワード）を満たすか否かを判定する動作チェックを行い、リカバリ部３０３が、動作チェック部３０１が、稼動情報が所定の条件（しきい値、キーワード）を満たさないと判定したことを受けて、稼動情報と、記憶部３５０に記憶されたエラーコードとに基づいて、稼動情報に応じたリカバリ手順を記憶部３５０に記憶されたリカバリ手順の中から特定し、特定したリカバリ手順にしたがって監視対象となるサーバに生じた障害を復旧させるので、発生状況に応じて自動的に障害を復旧させることが可能となる。
【０１０３】
例えば、サーバの稼働状況によって、サーバの動作をチェックする条件を自動的に変更し、サーバに障害が発生した場合にも、単にあらかじめ定義したシナリオだけでなく、過去の実績のあるリカバリ手順にしたがって自動的に復旧させることが可能となる。
また、サーバが平常運用されている場合においては、その動作チェック、あるいはリソースの使用状況やパフォーマンスを自動的に実行させ、その際に異常を検知した場合、自動的に管理者への通報から異常の原因となった障害の復旧までの一連の流れの作業を行うので、サーバやシステムの運用保守を自動で行われることとなり、運用担当者や管理者の負担を軽減することが可能となる、
さらに、障害の復旧までの一連の流れの作業を自動的に行うので、迅速に障害が復旧でき、その結果、システムのダウンタイムを抑制することができるため、ユーザに安定したサービスを提供することができる。
【０１０４】
なお、本発明は、上記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施の形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施の形態に示される全構成要素からいくつかの構成要素を削除してもよい。さらに、異なる実施の形態にわたる構成要素を適宜組み合わせても良い。
【符号の説明】
【０１０５】
１０００  障害モニタリング・自動復旧システム、
１０１  Ｗｉｎｄｏｗｓサーバ
１０２  Ｕｎｉｘサーバ
１０３  ＤＢ（DataBase）サーバ
１０４  アプリケーションサーバ
２５１  共通監視端末
２０１  制御部
３０１  動作チェック部
３０２  パフォーマンスデータ収集部
３０３  リカバリ部
３０４  通信部
３５０  記憶部
３５１  実行制御ＤＢ
３５２  結果判定テーブル
３５３  コマンドテーブル
３５４  キーワードテーブル
３５５  サーバ情報テーブル
３５６  通知先テーブル
３５７  スケジュールテーブル
３５８  パフォーマンスＤＢ
３５９  結果抽出テーブル
３６０  エラー管理ＤＢ
３６１  障害管理テーブル
Ｎ  ネットワーク。
【図１】
0005588295.tif 000002
【図２】
0005588295.tif 000003
【図３】
0005588295.tif 000004
【図４】
0005588295.tif 000005
【図５】
0005588295.tif 000006
【図６】
0005588295.tif 000007
【図７】
0005588295.tif 000008
【図８】
0005588295.tif 000009
【図９】
0005588295.tif 000010
【図１０】
0005588295.tif 000011
【図１１】
0005588295.tif 000012
【図１２】
0005588295.tif 000013
【図１３】
0005588295.tif 000014
【図１４】
0005588295.tif 000015
【図１５】
0005588295.tif 000016