JP2004280171A

JP2004280171A - 障害情報通知プログラム

Info

Publication number: JP2004280171A
Application number: JP2003066931A
Authority: JP
Inventors: Hideki Ishiwatari; 秀樹石渡
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2003-03-12
Filing date: 2003-03-12
Publication date: 2004-10-07

Abstract

【課題】障害発生を受信すると、予想される対処作業をスケジューリングし、各担当者に障害内容と各担当者の作業開始予想時間を通知することで、各担当者にとって効率的な障害通知を可能にする。
【解決手段】コンピュータに、各事象に関する担当者と対処内容とを格納したリカバリ情報テーブルを参照し、監視対象サーバで発生した事象に関する担当者と対処内容とを抽出する第一抽出ステップと、前記第一抽出ステップにおいて抽出した対処内容に基づき、対処スケジュールを作成する第一スケジューリングステップと、前記対処スケジュールを前記担当者に対して通知する第一通知ステップと、を動作させることを特徴とする。
【選択図】図１

Description

【０００１】
【発明の属する技術分野】
本発明は監視対象サーバで発生する障害を監視する障害監視サーバにおいて動作する障害情報通知プログラムに関する。
【０００２】
【従来の技術】
従来、運用中のコンピュータシステムに障害が発生した時、まず、保守部門の窓口担当者を呼び出し、呼び出された人が現場の状況を確認して適切な担当者を呼び出すという、二段階呼び出しを行うことが多い。この場合、適切な担当者が呼び出されるまでに時間がかかり、障害情報の伝達が不十分になる恐れもある。
【０００３】
上記の問題点に対し、運用中に発生した障害を受信し、障害の種別に基づきその障害の復旧処置を行う担当者を設定し、通信ネットワークを介して障害情報を通知するコンピュータ監視システムがある（例えば、特許文献１参照。）。
【０００４】
【特許文献１】
特開２００２−２１５４２５号公報
【０００５】
【発明が解決しようとする課題】
しかし、コンピュータシステムの障害は、多くの場合いくつかの要因が存在し、その障害に対処する場合には、複数の担当者が必要となる。例えば、ネットワークのトラブルが発生した場合に、ネットワーク担当者が対処した後、サーバ担当者がサーバの設定を修正し、アプリケーションプログラム担当者がプログラムの修正を行い、運用担当者がデータの修正を行うということが考えられる。
【０００６】
このような場合に、上記先行技術を適用すると、一時に各担当者に通知が行くことになるが、例えば最後に対処を行う運用担当者は、他の対処が完了するまで何も手を打つことができないといった無駄な時間を過ごすことになってしまう。
【０００７】
このような問題を解決するため、本発明は、障害発生を受信すると、予想される対処作業をスケジューリングし、各担当者に障害内容と各担当者の作業開始予想時間を通知することで、各担当者にとって効率的な障害通知を可能にすることを目的とする。
【０００８】
【課題を解決するための手段】
本発明に係る障害情報通知プログラムは、コンピュータに、各事象に関する担当者と対処内容とを格納したリカバリ情報テーブルを参照し、監視対象サーバで発生した事象に関する担当者と対処内容とを抽出する第一抽出ステップと、前記第一抽出ステップにおいて抽出した対処内容に基づき、対処スケジュールを作成する第一スケジューリングステップと、前記対処スケジュールを前記担当者に対して通知する第一通知ステップと、を動作させることを特徴とする。
【０００９】
このように構成することにより、発生した事象に必要な対処をスケジューリングし、そのスケジューリング結果を各担当者に通知することが可能となる。
【００１０】
また、本発明に係る障害情報通知プログラムは、監視対象サーバからのエラーメッセージを受信するエラーメッセージ受信ステップと、各エラーメッセージに該当する事象情報を格納した事象テーブルを参照し、前記エラーメッセージ受信ステップにおいて受信したエラーメッセージに該当する事象情報を抽出する第二抽出ステップと、を備え、前記第一抽出ステップにおいて、前記第二抽出ステップにおいて抽出された事象情報に関する担当者と対処内容とを抽出することを特徴とする。
【００１１】
このように構成することにより、監視対象サーバからのエラーメッセージを受信することを契機に自動的に通知処理を行うことが可能となる。
【００１２】
また、本発明に係る障害情報通知プログラムは、各担当者からの完了通知を受信する完了通知受信ステップと、前記完了通知に基づき、再度対処スケジュールを作成する第二スケジューリングステップと、前記第二スケジューリングステップで作成した対処スケジュールを前記担当者に対して通知する第二通知ステップと、を備えることを特徴とする。
【００１３】
このように構成することにより、一度作成して通知したスケジュールを実績に基づいて見直しを行って再通知することが可能となる。
【００１４】
また、本発明に係る障害情報通知プログラムは、実際に対処が完了した時間に基づき、前記リカバリ情報テーブルに格納された対処に要する所要時間を補正することを特徴とする。
【００１５】
このように構成することにより、従前に見積もって作成した対処スケジュールを、実績に基づいてより正確な値に補正することが可能となる。
【００１６】
なお、上述のプログラムは、コンピュータにて実施することができ、このプログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介してデジタル信号として配信される場合もある。なお、中間的な処理結果はメモリに一時保管される。
【００１７】
【発明の実施の形態】
本発明の実施の形態に係るシステム概要について図１を用いて説明する。本発明の障害情報通知プログラムは、監視対象サーバ１５０とネットワークを介して接続されて、当該監視対象サーバ１５０で発生する障害を監視する障害監視サーバ１００のハードディスクにインストールすることで機能する。
【００１８】
インストールされる主なプログラムは、監視対象サーバ１５０から送信されるエラーメッセージや担当者が保持する端末１８０から送信される完了通知を受信する受信プログラム１０２、受信プログラム１０２で受信したエラーメッセージや完了通知に基づき、対処スケジュールを作成するスケジューリングプログラム１０３、スケジューリングプログラム１０３で作成されたスケジュールを担当者が保持する端末１８０に通知する通知プログラム１０４、全ての対処が完了した際に実績に基づいて従前に見積もって作成した対処スケジュールの補正を行う情報登録プログラム１０５、が含まれる。
【００１９】
なお、受信プログラム１０２及び通知プログラム１０４と、担当者が保持する端末１８０との電子メールの送受信については、本発明の障害情報通知プログラムとは別に障害監視サーバ１００に備えられるメール送受信プログラム１０１と、メールサーバ１６０とを介し、更にインターネット等のネットワーク１７０を介して行われるものとする。但し、必ずしも電子メールで情報のやり取りを行う必要はなく、ＷＷＷサーバを用いる等、様々な手段が考えられるが、本実施の形態においては説明の便宜上電子メールでのやり取りを用いて説明する。
【００２０】
これらのプログラムは、障害監視サーバ１００の図示せぬ外部記憶装置に格納されており、各プログラム実行時に内部記憶装置に読み出される。
【００２１】
また更に、障害監視サーバ１００の外部記憶装置には、各メッセージに対応する事象名を格納する事象テーブル１０７、各事象に関するリカバリ情報を格納するリカバリ情報テーブル１０８、担当者に関する情報を格納する担当者テーブル１０９、対処中の事象の状況を管理する対処状況テーブル１１０、受信プログラム１０２で受信した情報を格納するメッセージ退避テーブル１１１、とが含まれ、必要に応じて受信プログラム１０２、スケジューリングプログラム１０３、通知プログラム１０４、情報登録プログラム１０５、から参照又は更新される。
【００２２】
なお、監視対象サーバ１５０には、障害監視サーバ１００に障害情報を通知するための監視プログラム１５１が備えられているものとする。
【００２３】
次に、本発明の一実施の形態に係る処理概要について図２を用いて説明する。監視対象サーバ１５０において何らかの障害が発生すると、監視対象サーバ１５０の監視プログラム１５１が感知し、所定のフォーマットに編集したメッセージ電文として障害監視サーバ１００に送信する。
【００２４】
このメッセージ電文を、図３のメッセージ電文３０１に例示する。メッセージ電文３０１は、電文の種別を表す種別、電文の内容を表す内容、とから構成されている。メッセージ電文３０１は、監視対象サーバ１５０の監視プログラム１５１から送信されたエラーメッセージであれば、種別に“ＳＹＳ”と設定されている。後述する担当者からの完了通知であれば、“ＩＮＦ”が設定されるものとする。また、監視対象サーバ１５０の監視プログラム１５１から送信されたエラーメッセージであれば、エラーコードが設定されている。
【００２５】
メッセージ電文３０１の場合は、３つの情報が同時に送信され、それら全ての種別が“ＳＹＳ”であることから、監視対象サーバ１５０の監視プログラム１５１から送信されたエラーメッセージであることがわかる。更に、エラーメッセージは“ｍｓｇ００１”、“ｍｓｇ０５２”、“ｍｓｇ１０７”であることもわかる。
【００２６】
監視対象サーバ１５０の監視プログラム１５１がこのようなメッセージ電文を送信すると、障害監視サーバ１００の受信プログラム１０２が受信する（Ｓ２０１）。次に、受信プログラム１０２は、受信処理を行う（Ｓ２０２）。この処理は、メッセージ電文を事象テーブルに照らし合わせて、本障害情報通知プログラムで処理すべきデータであるかの判定を行うものである。
【００２７】
上記判定において本障害情報通知プログラムで処理すべきデータであると判定した場合、スケジューリングプログラム１０３がリカバリ情報テーブルを参照することで、必要となる対処と各対処の開始予定時刻を算出する（Ｓ２０３）。そして、通知プログラム１０４は、これらの情報を各担当者の保持する端末１８０に通知する（Ｓ２０４）。
【００２８】
ここまでで、最初の通知処理が完了する。次に、各対処作業の進捗を監視する処理が始まる。スケジュールをチェックして完了予定時刻になっても完了していない対処が存在するか否かの判定と、監視対象サーバ１５０の監視プログラム１５１からのメッセージの受信や担当者が保持する端末１８０からの完了通知を受信したか否かの判定と、を定期的にチェックするフェーズである。
【００２９】
具体的には、まずＳ２０４の通知処理が完了した時点で今回の障害の全ての対処が完了したか否かの判定を行う（Ｓ２０５）。現時点ではまだ最初の通知処理を行っただけなのでこの判定は完了していないという結果になり、Ｓ２０６の判定に進むが、以下の繰り返しを行った後、最終的に全ての対処が完了した場合には後述する情報登録処理（Ｓ２０８）に進む。
【００３０】
次に、Ｓ２０３で作成したスケジュールを参照し、現在処理中の対処の完了予定時刻が既に過ぎてしまっているか否かの判定を行う（Ｓ２０６）。この判定で、まだ完了予定時刻になっていないと判定された場合は、Ｓ２０７の判定に進む。もし完了予定時刻になっていると判定された場合は、Ｓ２０３のスケジューリング処理に戻り、再スケジューリングを行い、その結果を再度各担当者の保持する端末１８０に通知する（Ｓ２０４）。
【００３１】
Ｓ２０６の判定においてまだ完了予定時刻になっていないと判定された場合、監視対象サーバ１５０の監視プログラム１５１からのメッセージの受信や担当者が保持する端末１８０からの完了通知を受信したか否かの判定を行う（Ｓ２０７）。これらのメッセージ受信がないと判定された場合は、Ｓ２０６の判定に戻り、Ｓ２０６及びＳ２０７の処理を定期的に繰り返す。
【００３２】
Ｓ２０７でいずれかのメッセージ受信があったと判定された場合は、Ｓ２０２の受信処理に戻り、本障害情報通知プログラムで処理すべきデータであるかの判定を行う。そして受信したメッセージの内容に基づき再スケジューリングを行い（Ｓ２０３）、その結果を再度各担当者の保持する端末１８０に通知する（Ｓ２０４）。
【００３３】
このように、Ｓ２０１からＳ２０７の処理を全ての対処が完了するまで繰り返した後、最終的に全ての対処が完了した時点で、情報登録プログラム１０５は、今回の対処実績情報をリカバリ情報テーブルに反映することで、当該テーブルの情報をより実態に即したデータにメンテナンスする（Ｓ２０８）。つまり、従前に見積もった対処予定を、実際に対処に要した作業時間に置き換えることで、次回の同じ事象に対する対処予定が正確なものとなるという効果を奏するのである。
【００３４】
次に、Ｓ２０１のメッセージの受信で図３のメッセージ電文３０１を監視対象サーバ１５０の監視プログラム１５１から受信したあとの障害情報通知プログラムの処理を詳細に説明する。メッセージ電文を受信すると、受信プログラム１０２は、受信処理（Ｓ２０２）を行う。
【００３５】
この受信処理（Ｓ２０２）について、図４のフローを用いて詳細に説明する。まず、受信したメッセージ電文が監視プログラム１５１から受信したものか否かの判定を行う（Ｓ４０１）。これは、前述したように、メッセージ電文の種別に”ＳＹＳ”と設定されているか否かで判定する。図３のメッセージ電文３０１の情報は全て種別に“ＳＹＳ”と設定されているので、ここではＳ４０２の処理に進む。もしメッセージ電文の種別に”ＩＮＦ”が設定されていた場合は、各担当者の保持する端末１８０からの完了通知であると判定されてＳ４０４に進むが、この処理については後述するものとする。
【００３６】
次に、受信したエラーメッセージが既知のものであるかの判定を行う（Ｓ４０２）。この判定は、受信したメッセージ電文の内容と、事象テーブル１０７とに基づいて行われる。
【００３７】
ここで、事象テーブル１０７を図５の事象テーブル５０２に例示する。事象テーブル５０２は、各メッセージＩＤで考えられる事象名を予め設定してあるテーブルである。事象テーブル５０２では便宜上“事象Ａ”“事象Ｂ”等と記載してあるが、実際は例えば“ＷＯＲＫＵＮＩＴの起動エラー”“ファイルシステムの異常”“メモリの交換要求”“メモリハードエラー”“ディスクエラー”等の具体的な名称が設定されているものである。
【００３８】
このように、事象テーブル５０２の各レコードはメッセージＩＤをレコードキーとした構造となっているので、受信したメッセージ電文の内容に設定されているメッセージＩＤをキーとして事象テーブル５０２を検索することで既知のエラーメッセージか否かの判定が可能となる。
【００３９】
ここで既知のエラーメッセージであると判定された場合は、本障害情報通知プログラムで処理可能なエラーであると考えられるため、受信処理（Ｓ２０２）を完了する。しかし、既知のエラーメッセージではないと判定された場合は、本障害情報通知プログラムで処理不可能なエラーであると考えられるため、システム管理者へ通知を行い、本障害情報通知プログラムでは処理できない障害が発生した旨を知らせる（Ｓ４０３）。
【００４０】
この時の連絡先については、担当者テーブル１０９を参照することで行われる。
【００４１】
この担当者テーブル１０９を図５の担当者テーブル５０１に例示する。担当者テーブル５０１は、担当者を一意に識別するための担当者ＩＤ、担当者名、メールアドレス、電話番号、等とから構成されている。また、担当者テーブル５０１に情報を格納されている担当者のうち、システム管理者については、それがわかるようにフラグを設けている。
【００４２】
Ｓ４０３においては、上述のような情報を参照し、システム管理者のメールアドレスを抽出して、当該メールアドレスに対して電子メールを送信する。なお、電子メールの送信については、メール送受信プログラム１０１がメールサーバ１６０に送信依頼を行うことにより、メールサーバ１６０が実行する。
【００４３】
受信処理（Ｓ２０２）において本障害情報通知プログラムで処理可能であると判定された場合、次にスケジューリング処理（Ｓ２０３）で対処スケジュールを作成する。このスケジューリング処理（Ｓ２０３）について、図６のフローに基づき詳細に説明する。
【００４４】
まず、受信したメッセージ電文が監視プログラム１５１から受信したものか否かの判定を行う（Ｓ６０１）。これは、前述したように、メッセージ電文の種別に”ＳＹＳ”と設定されているか否かで判定する。図３のメッセージ電文３０１の情報は全て種別に”ＳＹＳ”と設定されているので、ここではＳ６０２の処理に進む。もしメッセージ電文の種別に”ＩＮＦ”が設定されていた場合は、各担当者の保持する端末１８０からの完了通知であると判定されてＳ６０６に進むが、この処理については後述するものとする。
【００４５】
次に、受信したメッセージ電文を、本障害情報通知プログラムが受信した時間とともに、メッセージ退避テーブル１１１に格納する（Ｓ６０２）。このメッセージ退避テーブル１１１は図７のメッセージ退避テーブル７０１に例示したように、メッセージ電文のフォーマットに受信時間を付加したものとなっている。
【００４６】
続いて、受信したメッセージで示されたメッセージＩＤで想定される事象名を、事象テーブル１０７を検索することで抽出する（Ｓ６０３）。具体的には、メッセージ退避テーブル７０１の内容に格納された“ｍｓｇ００１”“ｍｓｇ０５２”“ｍｓｇ１０７”をキーに、事象テーブル５０２を検索する。
【００４７】
この検索において例えば事象テーブル５０２のようなレコードが抽出されるが、各レコードには複数の事象名が列挙されている。ここでは、各レコードに共通な事象名が一番確率の高い事象であると考え、各レコードに共通な“事象Ｂ”が今回の事象であると決定する。
【００４８】
上述のように、今回の事象が確定すると、次に、リカバリ情報テーブル１０８を参照して、今回の障害を対処するための手順を抽出する（Ｓ６０４）。
【００４９】
ここで、リカバリ情報テーブル１０８を、図７のリカバリ情報テーブル７０２に例示する。リカバリ情報テーブル７０２は、各事象に対する手順と、当該手順に要する作業時間である所要時間、担当者、対処内容から構成されている。
【００５０】
Ｓ６０４の処理においては、Ｓ６０３で確定した事象名をキーにリカバリ情報テーブル７０２を検索し、これらの情報を取得する。リカバリ情報テーブル７０２の例では、事象Ｂには手順がＳＴＥＰ１から３までの３つあることがわかる。ＳＴＥＰ１には１５分を要し、担当者コードは１２３で、対処内容はアプリケーションの停止であることがわかる。以下同様である。
【００５１】
次に、Ｓ６０４でリカバリ情報テーブル７０２から抽出した内容に基づき、対処状況テーブル１１０を作成する（Ｓ６０５）。
【００５２】
この対処状況テーブル１１０を図８の対処状況テーブル８０１に例示する。対処状況テーブル８０１は、基本的にはリカバリ情報テーブル７０２の情報を書き出すが、各対処の完了予定時間を算出して各レコードに付加する。具体的には以下のように算出する。
【００５３】
まず、システム日付等から現在の時間を取得する。ここでは仮に１４時１５分であるとする。そして、ＳＴＥＰ１に要する時間をリカバリ情報テーブル７０２を参照することで取得する。これらの値により、ＳＴＥＰ１は１４時１５分から１５分後の１４時３０分に対処が完了することがわかる。この１４時３０分という時間を、対処状況テーブルの完了予定時間に書き込む。
【００５４】
次に、ＳＴＥＰ２についてはＳＴＥＰ１の完了予定時間に、リカバリ情報テーブル７０２のＳＴＥＰ２のレコードから判明する所要時間である５分を加えることで、ＳＴＥＰ２の完了予定時間１４時３５分が算出され、この時間を対処状況テーブル８０１の完了予定時間に書き込む。ＳＴＥＰ３についても同様の算出を行い、１４時５０分という完了予定時間を書き込むことができる。このようにして、対処状況テーブルの作成が完了する。
【００５５】
Ｓ２０３で対処スケジュールが作成されると、次にこのスケジュール情報を各担当者の保持する端末１８０に通知する（Ｓ２０４）。この通知処理（Ｓ２０４）について、図９のフローを用いて詳細に説明する。まず、対処状況テーブル８０１に基づき、通知メールを作成する（Ｓ９０１）。
【００５６】
この通知メールを図１０の通知メール１００１に例示する。例示のように、障害の発生時刻、内容、リカバリ状況から構成されている。このうち、障害の発生時刻についてはメッセージ退避テーブルの一番古いレコードの受信時間から、その他については対処状況テーブル８０１から転記される。
【００５７】
次に、Ｓ９０１で作成された通知メールを、各担当者の保持する端末１８０に送信する（Ｓ９０２）。なお、電子メールの送信については、メール送受信プログラム１０１がメールサーバ１６０に送信依頼を行うことにより、メールサーバ１６０が実行するが、メールアドレスについては、対処状況テーブル８０１の担当者ＩＤをキーに担当者テーブル５０１を検索することで取得する。
【００５８】
ここまでで、最初の通知処理が完了する。次に、各対処作業の進捗を監視する処理が始まる。スケジュールをチェックして完了予定時刻になっても完了していない対処が存在するか否かの判定と、監視対象サーバ１５０の監視プログラム１５１からのメッセージの受信や担当者が保持する端末１８０からの完了通知を受信したか否かの判定と、を定期的にチェックするフェーズである。
【００５９】
具体的には、まずＳ２０４の通知処理が完了した時点で今回の障害の全ての対処が完了したか否かの判定を行う（Ｓ２０５）。現時点ではまだ最初の通知処理を行っただけなのでこの判定は完了していないという結果になり、Ｓ２０６の判定に進むが、以下の繰り返しを行った後、最終的に全ての対処が完了した場合には後述する情報登録処理（Ｓ２０８）に進む。
【００６０】
次に、Ｓ２０３で作成したスケジュールを参照し、現在処理中の対処の完了予定時刻が既に過ぎてしまったいるか否かの判定を行う（Ｓ２０６）。例えば、現在時刻が１４時２５分であった場合、ＳＴＥＰ１の完了時間は１４時３０分なので、まだ完了予定時刻が過ぎていないと判定される。すると、次のＳ２０７の判定に進む。
【００６１】
Ｓ２０７では、監視対象サーバ１５０の監視プログラム１５１からのメッセージの受信や担当者が保持する端末１８０からの完了通知を受信したか否かの判定を行う。そして、これらのメッセージ受信がないと判定された場合は、Ｓ２０６の判定に戻り、Ｓ２０６及びＳ２０７の処理を定期的に繰り返す。
【００６２】
さて、上記の繰り返し処理において、例えば数サイクルの後、１４時３０分になった場合、ＳＴＥＰ１の完了予定時刻を過ぎていることが判明する。更に、実際の完了時点でその時刻が書き込まれる完了時刻が空白であることから、まだ対処が完了していないことが判明する。
【００６３】
そのため、スケジューリング処理（Ｓ２０３）に戻り、再スケジューリングを行う。この再スケジューリングについて、図６のフローを用いて詳細に説明する。まず、監視対象サーバ１５０の監視プログラム１５１からのメッセージ受信か否かを判定する（Ｓ６０１）。今回は完了予定時刻を経過したことによるスケジューリング処理であるため、この判定は“ＮＯ”となり、Ｓ６０６に進む。
【００６４】
次に、従前にＳ６０５で作成された対処状況テーブル８０１の完了予定時刻を補正する（Ｓ６０６）。この補正については、様々な方法が考えられるが、本実施の形態においては、全ての完了予定時刻を５分間延伸するように補正するものとする。この補正後の対処状況テーブル１１０を図８の対処状況テーブル８０２に例示する。このように各手順の完了予定時刻を５分ずつ延伸するように補正する。
【００６５】
上記補正が完了すると、次に通知処理Ｓ２０４を行い、各担当者の保持する端末に補正後のスケジュールの通知を行う。この処理については上で説明した通りである。そして、まだ全ての対処が完了していないのでＳ２０５の判定は“ＮＯ”となり、またＳ２０６とＳ２０７の処理を繰り返すこととなる。
【００６６】
続いて、担当者からの対処完了通知を受信したものとする。この対処完了通知は、例えば障害情報通知プログラムからの通知メールに返信する形で担当者の保持する端末からメールサーバ１６０に送信され、メール送受信プログラム１０１を介して障害情報通知プログラムに送達する。その際、メール送受信プログラム１０１は、電子メールの内容を解析して、所定のフォーマットに編集したメッセージ電文として障害監視サーバ１００に送信する。
【００６７】
このメッセージ電文を、図３のメッセージ電文３０２に例示する。フォーマットは上で説明したメッセージ電文３０１と同じだが、監視対象サーバ１５０の監視プログラム１５１からのメッセージではなく、メール送受信プログラム１０１からのメッセージなので、種別には“ＩＮＦ”が設定されている。また、内容には、どのステップを担当している担当者の保持する端末からのメッセージかわかるように、ステップの番号が設定されている。さらに、対処が完了した場合は“ＯＫ”が、何らかの理由により完了しなかった場合は“ＮＧ”が設定されているものとする。
【００６８】
この場合、Ｓ２０７の判定で、メッセージの受信があったと判定されるので、Ｓ２０２の受信処理に戻る。この受信処理（Ｓ２０２）について、図４のフローを用いて詳細に説明する。まず、受信したメッセージ電文が監視プログラム１５１から受信したものか否かの判定を行う（Ｓ４０１）。これは、前述したように、メッセージ電文の種別に”ＳＹＳ”と設定されているか否かで判定する。図３のメッセージ電文３０２の情報は種別に“ＩＮＦ” と設定されているので、ここではＳ４０４の処理に進む。Ｓ４０４では、受信したメッセージ電文の内容を判定して、それが完了したものか否かを見る。メッセージ電文３０２の内容は“ＯＫ”となっているので、“Ｙ”となり、受信処理Ｓ２０２は完了する。しかし、もしメッセージ電文３０２の内容が“ＮＧ”となっていた場合は、本障害情報通知プログラムで処理不可能な事象である考えられるため、システム管理者へ通知を行い、本障害情報通知プログラムでは処理できない障害が発生した旨を知らせる（Ｓ４０５）。
【００６９】
次に、受信したメッセージの受信時間に基づき、再スケジューリングを行う。ここでの処理は、上述した完了予定時刻になっても完了通知が来なかった場合の再スケジューリングと同様なので、詳細な説明は割愛するが、例えば１４時４０分にＳＴＥＰ１の対処完了の通知を受信した場合は、その時刻を基点として、図８の対処状況テーブル８０３のような補正を行う。つまり、ＳＴＥＰ１の完了時刻に１４時４０分を設定し、この時刻を基点として以下の対処の完了予定時刻を補正するものである。
【００７０】
上記補正が完了すると、次に通知処理Ｓ２０４を行い、各担当者の保持する端末に補正後のスケジュールの通知を行う。この処理については上で説明した通りである。そして、まだ全ての対処が完了していないのでＳ２０５の判定は“ＮＯ”となり、またＳ２０６とＳ２０７の処理を繰り返すこととなる。
【００７１】
Ｓ２０６とＳ２０７の処理を繰り返しているうちに、新たなエラーメッセージが監視対象サーバ１５０の監視プログラム１５１から送信されてくることも考えられる。この場合は、Ｓ２０７の判定で、メッセージの受信があったと判定されるので、Ｓ２０２の受信処理に戻る。そして、スケジューリング処理（Ｓ２０３）でメッセージ退避テーブル１１１にこの新たなエラーメッセージが格納されれ、それまで格納されたエラーメッセージを用いて再度事象テーブルを検索し、それまでと異なる事象と判定された場合は、その新たな事象に関するリカバリ情報をリカバリ情報テーブル１０８から抽出して、そのリカバリ情報に基づいて再作成されたスケジュールが各担当者の保持する端末１８０に送信されることとなる。この時、直前の対処状況テーブルを退避しておき、見直し後の対処スケジュールから外れた担当者を把握し、当該担当者の保持する端末に対して対処不要の通知を送ることも可能である。
【００７２】
このように、Ｓ２０６及びＳ２０７の処理を繰り返すことにより、常に最適なスケジュールを作成して各担当者の保持する端末１８０にそのスケジュールを通知することが可能となる。そして、最終的に全ての対処が完了すると、その実績情報（特に完了時刻）をリカバリ情報テーブル１０８に反映することで、スケジュール作成の元データである各対処に要する時間の最適化を可能とする。
【００７３】
具体的には、Ｓ２０４で全ての対処が完了した旨の通知を各担当者の保持する端末１８０に通知した後、Ｓ２０５の判定で“Ｙ”となり、Ｓ２０８の情報登録処理に進む。この情報登録処理を図１１のフローに基づいて詳細に説明する。この時点で、対処状況テーブル１１０は、図１２の対処状況テーブル１２０１のようになっているものとする。
【００７４】
対処状況テーブル１２０１でわかることは、メッセージ退避テーブルの内容から一番最初にエラーメッセージを受信した時刻が１４時１５分であることからＳＴＥＰ１は２５分、ＳＴＥＰ２は１０分、ＳＴＥＰ３は２５分かかったという実績対処時間である。リカバリ情報テーブル１０８は、リカバリ情報テーブル７０２のように、ＳＴＥＰ１は１５分、ＳＴＥＰ２は５分、ＳＴＥＰ３は１５分という見積になっていたので、これを実態に即して補正することが情報登録処理Ｓ２０８の目的である。
【００７５】
よって、上記のように算出した実績対処時間に基づいてリカバリ情報テーブル１０８を補正する（Ｓ１１０１）。補正後のリカバリ情報テーブル１０８を図７のリカバリ情報テーブル７０３に例示する。リカバリ情報テーブル７０２と比較すると、各ステップの所要時間が補正されていることがわかる。このように実態に即した各対処の所要時間の補正が完了する。
【００７６】
なお、本実施の形態においては、担当者が保持する端末として携帯電話やＰＤＡ（ＰｅｒｓｏｎａｌＤａｔａＡｓｓｉｓｔａｎｔ）のようなものを想定して説明したが、担当者が操作する端末は特にインターネットのようなネットワークを介して接続されている必要はなく、監視対象サーバと同じＬＡＮに接続されている端末など、障害監視サーバ１００からの通知を受信できるものであれば何であっても構わない。
（付記１）
コンピュータに、
各事象に関する担当者と対処内容とを格納したリカバリ情報テーブルを参照し、監視対象サーバで発生した事象に関する担当者と対処内容とを抽出する第一抽出ステップと、
前記第一抽出ステップにおいて抽出した対処内容に基づき、対処スケジュールを作成する第一スケジューリングステップと、
前記対処スケジュールを前記担当者に対して通知する第一通知ステップと、
を動作させることを特徴とする障害情報通知プログラム。
（付記２）
監視対象サーバからのエラーメッセージを受信するエラーメッセージ受信ステップと、
各エラーメッセージに該当する事象情報を格納した事象テーブルを参照し、前記エラーメッセージ受信ステップにおいて受信したエラーメッセージに該当する事象情報を抽出する第二抽出ステップと、
を備え、
前記第一抽出ステップにおいて、前記第二抽出ステップにおいて抽出された事象情報に関する担当者と対処内容とを抽出することを特徴とする付記１記載の障害情報通知プログラム。
（付記３）
各担当者からの完了通知を受信する完了通知受信ステップと、
前記完了通知に基づき、再度対処スケジュールを作成する第二スケジューリングステップと、
前記第二スケジューリングステップで作成した対処スケジュールを前記担当者に対して通知する第二通知ステップと、
を備えることを特徴とする付記２から３までのいずれかに記載の障害情報通知プログラム。
（付記４）
実際に対処が完了した時間に基づき、前記リカバリ情報テーブルに格納された対処に要する所要時間を補正することを特徴とする付記３記載の障害情報通知プログラム。
（付記５）
コンピュータに、
各事象に関する担当者と対処内容とを格納したリカバリ情報テーブルを参照し、監視対象サーバで発生した事象に関する担当者と対処内容とを抽出する抽出ステップと、
前記抽出ステップにおいて抽出した対処内容に基づき、対処スケジュールを作成するスケジューリングステップと、
前記対処スケジュールを前記担当者に対して通知する通知ステップと、
を動作させることを特徴とする障害情報通知プログラムを記録したコンピュータ読み取り可能な記録媒体。
（付記６）
監視対象サーバで発生する障害を監視する障害監視サーバによる障害情報通知方法であって、
各事象に関する担当者と対処内容とを格納したリカバリ情報テーブルを参照し、前記監視対象サーバで発生した事象に関する担当者と対処内容とを抽出する抽出ステップと、
前記抽出ステップにおいて抽出した対処内容に基づき、対処スケジュールを作成するスケジューリングステップと、
前記対処スケジュールを前記担当者に対して通知する通知ステップと、
を含むことを特徴とする障害情報通知方法。
（付記７）
監視対象サーバで発生する障害を監視する障害監視サーバであって、
各事象に関する担当者と対処内容とを格納したリカバリ情報テーブルと、
前記リカバリ情報テーブルを参照し、前記監視対象サーバで発生した事象に関する担当者と対処内容とを抽出する抽出手段と、
前記抽出手段において抽出した対処内容に基づき、対処スケジュールを作成するスケジューリング手段と、
前記対処スケジュールを前記担当者に対して通知する通知手段と、
を備えることを特徴とする障害情報通知サーバ。
【００７７】
【発明の効果】
以上説明したように、本発明によれば、監視対象サーバで発生した事象に必要な対処をスケジューリングし、そのスケジューリング結果を各担当者に通知することが可能となる。また、監視対象サーバからのエラーメッセージを受信することを契機に自動的に通知処理を行うことが可能となる。更に、一度作成して通知したスケジュールを実績に基づいて見直しを行って再通知することが可能となる。また、従前に見積もって作成した対処スケジュールを、実績に基づいて、より正確な値に補正することが可能となる。
【図面の簡単な説明】
【図１】実施例のシステム構成図である。
【図２】実施例の処理フローである。
【図３】メッセージ電文の一例を示す図である。
【図４】受信処理の流れを示すフローチャートである。
【図５】担当者テーブルと事象テーブルの一例を示す図である。
【図６】スケジューリング処理の流れを示すフローチャートである。
【図７】メッセージ退避テーブルとリカバリ情報テーブルの一例を示す図である。
【図８】対処状況テーブルの一例を示す図である。
【図９】通知処理の流れを示すフローチャートである。
【図１０】通知メールの一例を示す図である。
【図１１】情報登録処理の流れを示すフローチャートである。
【図１２】対処状況テーブルの一例を示す図である。
【符号の説明】
１００障害監視サーバ
１０１メール送受信プログラム
１０２受信プログラム
１０３スケジューリングプログラム
１０４通知プログラム
１０５情報登録プログラム
１０７事象テーブル
１０８リカバリ情報テーブル
１０９担当者テーブル
１１０対処状況テーブル
１１１メッセージ退避テーブル
１５０監視対象サーバ
１５１監視プログラム
１６０メールサーバ
１７０ネットワーク
１８０担当者の保持する端末

Claims

コンピュータに、
各事象に関する担当者と対処内容とを格納したリカバリ情報テーブルを参照し、監視対象サーバで発生した事象に関する担当者と対処内容とを抽出する第一抽出ステップと、
前記第一抽出ステップにおいて抽出した対処内容に基づき、対処スケジュールを作成する第一スケジューリングステップと、
前記対処スケジュールを前記担当者に対して通知する第一通知ステップと、
を動作させることを特徴とする障害情報通知プログラム。
監視対象サーバからのエラーメッセージを受信するエラーメッセージ受信ステップと、
各エラーメッセージに該当する事象情報を格納した事象テーブルを参照し、前記エラーメッセージ受信ステップにおいて受信したエラーメッセージに該当する事象情報を抽出する第二抽出ステップと、
を備え、
前記第一抽出ステップにおいて、前記第二抽出ステップにおいて抽出された事象情報に関する担当者と対処内容とを抽出することを特徴とする請求項１記載の障害情報通知プログラム。
コンピュータに、
各事象に関する担当者と対処内容とを格納したリカバリ情報テーブルを参照し、監視対象サーバで発生した事象に関する担当者と対処内容とを抽出する抽出ステップと、
前記抽出ステップにおいて抽出した対処内容に基づき、対処スケジュールを作成するスケジューリングステップと、
前記対処スケジュールを前記担当者に対して通知する通知ステップと、
を動作させることを特徴とする障害情報通知プログラムを記録したコンピュータ読み取り可能な記録媒体。
監視対象サーバで発生する障害を監視する障害監視サーバによる障害情報通知方法であって、
各事象に関する担当者と対処内容とを格納したリカバリ情報テーブルを参照し、前記監視対象サーバで発生した事象に関する担当者と対処内容とを抽出する抽出ステップと、
前記抽出ステップにおいて抽出した対処内容に基づき、対処スケジュールを作成するスケジューリングステップと、
前記対処スケジュールを前記担当者に対して通知する通知ステップと、
を含むことを特徴とする障害情報通知方法。
監視対象サーバで発生する障害を監視する障害監視サーバであって、
各事象に関する担当者と対処内容とを格納したリカバリ情報テーブルと、
前記リカバリ情報テーブルを参照し、前記監視対象サーバで発生した事象に関する担当者と対処内容とを抽出する抽出手段と、
前記抽出手段において抽出した対処内容に基づき、対処スケジュールを作成するスケジューリング手段と、
前記対処スケジュールを前記担当者に対して通知する通知手段と、
を備えることを特徴とする障害情報通知サーバ。