JP2006277685A - 障害発生通知プログラム、および通知装置。 - Google Patents

Abstract

【課題】 障害発生時に、障害対応のために必要な時刻情報を求め、その結果に応じて、適切な担当者に障害発生を通知する。
【解決手段】 プログラムは、外部からの障害発生情報に対応して、障害対応に必要な時間を現時刻に加算した対応予測時刻を算出する手順と、業務の必要上で障害対応が完了すべき対応必須時刻と、対応予測時刻とを比較する手順と、比較の結果に応じて担当者を選択し、選択された担当者に障害発生を通知する手順とを計算機に実行させる。
【選択図】図１

Description

本発明は、例えばユーザシステムの障害監視や運用管理を行なうアラートシステムに係り、さらに詳しくは、例えばユーザシステムからの障害発生情報に対応して、現時刻に障害の対応に必要な対応必要時間を加算した対応予測時刻と、業務上の必要性によって障害対応が完了すべき対応必須時刻とを比較して、障害発生を通知すべき担当者の振り分けを行なうための障害発生通知プログラム、および通知装置に関する。

従来のアラートシステムにおいては、例えばユーザシステムに障害が発生した時、その障害内容に対応して連絡すべき担当者の振り分けを行い、メールなどを用いてその担当者に通知を行っていた。しかしながら障害内容だけでは、連絡を受けた担当者がその時点においてその障害に本当に対応可能か否かの判断が難しかった。例えば障害発生通知を受けた担当者の時間的な制約などの都合によって、障害に対応することができないことも十分に考えられる。

従来のアラートシステムとしては、例えば携帯電話を利用して遠隔監視を行なって障害発生時にアラートを投げるシステムや、システム障害への対応をスムーズに行い、障害情報をユーザに迅速に返す仕組みとして、受付側のスキルに依存せずに障害への対応を行なえる仕組みも考えられている。さらにユーザと保守担当者が障害情報を共通化して、双方の間で調整をしながら保守を行なうサービスも考えられているが、これらの技術においては障害対応に要する時間や、業務的に必要となる障害対応の必須期限を意識したサービスを行なうことができないという問題点があった。

このような従来技術の例では、障害情報から障害関連モジュールを自動的に切り分けて、その障害情報を各障害関連モジュールの開発や保守の担当部門に電子メールで配信することによって、障害発生直後に障害解析を行なうことができる障害解析支援システムが開示されている（例えば、特許文献１参照）。しかしながらこの技術においても、障害対応に要する時間や、実際に担当者が障害対応が完了すべき対応必須時刻までに対応を完了することができるか否かなどの時間的な条件に応じて障害通知先を振り分けることができないという問題点を解決することはできなかった。

従来においては、まず第１に障害の対応に必要な時間、あるいは過去の実績として障害対応に要した時間を考慮した上で、適切な担当者を自動的に選択することはできないという問題点があった。

第２に、例えば業務計画によって障害対応が完了していなければならない時刻、すなわち対応必須時刻が明らかな場合にも、その時刻に間に合うように適切な担当者を自動的に選択することができないという問題点があった。

第３に担当者に障害対応を依頼する場合にも、その担当者の都合を確認した上で、対応必須時刻までに対応が完了できるかどうかの判断を行ない、それができない場合には、例えば他の担当者への依頼を自動的に行なうことができないという問題点があった。
特開２００３−４４３２２号公報

本発明の課題は、上述の問題点に鑑み、例えばユーザシステムから障害情報を受信した時、現時刻に対応に要する時間を加算した対応予測時刻、前述の対応必須時刻、および担当者が実際に対応を開始できる対応開始可能時刻などの時刻情報を考慮して、適切な担当者に障害発生通知を行うことができる障害発生通知プログラム、およびそのような障害通知を行う障害発生通知装置を提供することである。

図１は、本発明の障害発生通知プログラムの原理的な機能ブロック図である。このプログラムにおいては、まずステップＳ１で外部、例えばユーザシステムから与えられる障害発生情報に対応して、その障害の対応に要する対応必要時間を現時刻に加算した対応予測時刻が算出される。この対応必要時間は、例えば過去の実績としてデータベースに格納されているものとする。

続いてステップＳ２で、業務上の必要性によってその障害への対応が完了すべき対応必須時刻と、対応予測時刻とが比較される。この対応必須時刻も、例えばユーザシステムによって実行される業務に対応してデータベースに格納されているものとする。

続いてステップＳ３で、比較結果に応じて障害発生を通知すべき担当者が選択され、選択された担当者に対して障害発生が通知される。
発明の実施の形態においては、ステップＳ３の障害発生通知手順において、対応予測時刻が対応必須時刻より早い時には、障害発生通知がその障害に対応可能なスキルを持つ担当者に対して行われることもできる。この場合、このスキルを持つ担当者から障害対応開始可能時刻の通知を受けた時、その障害対応開始可能時刻に前述の対応必要時間を加算して復旧予定時刻を算出する手順と、その復旧予定時刻と前述の対応必須時刻とを比較する手順と、その比較結果に応じて障害に関連する担当者にその障害への対応の可／否を通知する手順とを、障害発生プログラムがさらに計算機に実行させることもできる。

また本発明においては、この障害発生通知プログラムを格納した計算機読出し可能可搬型記憶媒体を用いることもできる。さらに本発明の障害発生通知プログラムの処理を実行し、適切な担当者に対して障害発生を通知する障害発生通知装置が用いられる。

以上のように本発明においては、例えば障害の内容や業務計画、担当者の所在などの各種条件に応じて、障害対応を行なうために必要な時刻情報を算出し、その算出結果に応じて、適切な担当者に対して障害発生を通知することができる。

本発明によれば、まず第１に適切な担当者を自動的に選択し、その担当者に対して復旧作業を要請する障害発生通知を行うことができる。第２に業務上の必要性によって障害対応が完了すべき対応必須時刻までに、障害を復旧できる可能性を高くすることができる。第３に過去の実績を取り込むことによって、対応完了までに必要な対応必要時間の予測精度を高めていくことができ、アラートシステムにおける運用の省力化に寄与するところが大きい。

図２は、本発明における自動アラートシステムを含む障害監視方式の全体システム構成図である。同図において自動アラートシステム１は、一般に複数の監視対象システム２、例えばユーザシステムと、例えばメールによって接続され、また一般に複数の担当者３、および上司・メーカー等関係者４とも、例えばメールによって接続される。

各監視対象システム２は、自システム内で障害が発生した場合に、アラートメールを自動アラートシステム１に送信する。担当者３、および上司・メーカー等関係者４は、自動アラートシステム１から障害発生を通知する通知メールを受信すると、必要に応じてその通知メールに対してリプライメールを送信し、またさらに自動アラートシステム１からの周知メールを受信する。

自動アラートシステム１は、その内部にメール管理機能５、対応予測時刻算出機能６、対応必須時刻算出機能７、通知先選択機能８、および時刻比較機能９を備え、さらに各種データベースとしてアラート情報テーブル１１、障害情報テーブル１２、業務予定情報テーブル１３、担当者情報テーブル１４、時間管理テーブル１５、およびメール管理テーブル１６を備えている。

図２において、監視対象システム２側で障害が発生すると、そのシステムからアラートメールが自動アラートシステム１に送信される。このメールはメール管理機能５によって受信され、その内容がチェックされる。

そのチェック結果に応じて、対応予測時刻算出機能６によって障害情報テーブル１２からその障害に対応するために必要となる対応必要時間が求められ、その対応必要時間を現時刻に加算することによって、対応予測時刻の算出が行なわれる。後述するように障害情報テーブル１２には、予め障害毎に対応必要時間が設定されるが、過去にその障害が発生した場合には、対応に要した時間としての実績を格納することによって、より精度が高い対応予測時刻の算出が可能となる。

次に対応必須時刻算出機能７によって、業務予定情報テーブル１３から障害が発生した監視対象システム２、例えばユーザシステムにおける本来の業務予定としての業務予定情報がチェックされる。この業務予定情報は、例えばユーザが監視対象システム２の運用を行なう前に立案し、システム全体の運用を行なうための業務計画として提示されるものであり、例えば「システムＡはファイルＢを毎日２１時までに作成し、システムＣに提供する。」というように、誰が、何を、誰に、いつまでに提供すべきかといった情報が業務予定情報テーブル１３に予め設定される。特に本実施形態では、いつまでに提供すべきかを対応必須時刻として抽出し、その後の処理に用いる。

対応予測時刻算出機能６によって算出された対応予測時刻と、対応必須時刻算出機能７によって抽出された対応必須時刻とは、時間管理テーブル１５に格納され、時刻比較機能９によって両者の比較が行なわれる。対応予測時刻が対応必須時刻より早い場合、すなわち対応必須時刻の前に障害対応を完了できる可能性がある場合には、通知先選択機能８によって、担当者情報テーブル１４の格納内容を用いた担当者情報チェックと通知先選択処理その１が行われる。

この担当者情報チェックと通知先選択処理その１では、障害が発生した監視対象システム２の業務内容や障害内容から、対応に必要と考えられるスキル、すなわちハードウェアやソフトウェアなどに関する知識を持った担当者の絞込みが行なわれる。

そして絞り込まれた、一般に複数の担当者について、担当者情報テーブル１４からその担当者の現時点での所在（今どこにいるか）、およびステータス（今何をしているか）の情報が抽出される。このような情報は、担当者が属している組織で利用される行き先管理情報や、スケジュール情報とのリンクによって、最新情報を常に持つことが可能となる。

このように担当者の所在とステータスを確認することによって、明らかに障害対応ができない担当者、例えば出張で遠方にいる担当者や、長期休暇中の担当者を除外し、かつ対応必須時刻までに対応可能な担当者を、例えば複数選択し、選択された担当者に対してメール管理機能５によって通知メールが送信される。なおすべての担当者の所在やステータスの状況から、スキルを持つ担当者の全員が障害に対応できる可能性が低いと判断される場合には、通知先選択機能８によって通知先選択処理その２が行なわれる。

通知先選択処理その２は、基本的には、前述の時刻比較機能９によって対応予測時刻と対応必須時刻とが比較され、対応必須時刻の方が早く、現時点で障害への対応を開始しても、対応必須時刻までに障害復旧ができる可能性が低い場合に行なわれる処理である。この場合には、障害が発生した監視対象システム２以外のシステムに対して、その障害が影響する可能性が高いと判断されるため、その影響によって問題が発生する以前に必要な関係者に対して障害発生の通知を行なうことによって、関係者の注意を喚起するものである。したがってこの通知先選択処理その２では、担当者情報テーブル１４などの格納内容から、障害が起こった監視対象システム２の動作に関連がある他の監視対象システム２の担当者や、障害が起こった監視対象システム２の担当者の上司や、システム開発メーカーなどに対して、障害発生を通知する通知メールがメール管理機能５によって送信される。

送信される通知メールには、障害発生の通知と合わせて、担当者が対応必須時刻までに障害が発生した監視対象システム２の存在する場所まで移動し、障害への対応を行なうことが可能かどうかを確認するための質問が記述される。担当者は通知メールを受領して内容を確認したことを示すために、自動アラートシステム１に対してリプライメールを返信する。そのリプライメールには対応が可能か否か、および対応が可能である場合には対応開始が何時になるかの返事が格納される。このようなメールの内容についてはさらに後述する。

自動アラートシステム１側では、メール管理機能５によってリプライメールの内容がチェックされ、そのリプライメールを送信した担当者が対応可能な場合には対応開始可能時刻が抽出される。そして時刻比較機能９によって、時間管理テーブル１５の内容を用いて対応開始可能時刻に対応予測時間を加算した加算結果と、対応必須時刻とが比較され、対応必須時刻のほうが遅い場合、すなわちその担当者によって対応必須時刻までに障害への対応が完了可能な場合には、メール管理機能５によって障害への対応が可能であることを示す周知メールが作成され、他の担当者３や、上司・メーカー等関係者４に対して、その周知メールが送信される。

通知メールを送信したすべての担当者から対応できないという回答があった場合や、例えばあらかじめ定められた時間内に誰からもリプライメールが戻ってこなかった場合には、通知先選択機能８によって通知先選択処理その２が実行され、スキルを持つ担当者３以外の上司・メーカー等関係者４に対して通知メールの送信が行われる。なおすでに通知先選択処理その２が行われている場合には、対応必須時刻以前に障害対応が完了できないことを示す対応不可周知メールが作成されて、すべての担当者３、上司・メーカー等関係者４に対して、その対応不可周知メールが送信される。

続いて本実施形態における処理の詳細についてそのフローチャート、各テーブルや各メールの内容を用いて、さらに詳細に説明する。図３は、本実施形態における障害発生通知処理の詳細フローチャートである。同図において処理が開始されると、まずステップＳ１１で前述の通知先選択処理その２が行なわれた回数を示すｎの値が“０”に初期化される。続いてステップＳ１２で監視対象システム２側から送られたアラートメールが受信される。

図４は、アラートメールの例である。同図においてアラートメールの１行目には障害コード、２行目には障害メッセージ、３行目には障害発生日時が記述されている。
ステップＳ１２でメール管理機能５によって受信されたアラートメールから、ステップＳ１３でアラート情報のチェックが行なわれ、その内容はアラート情報テーブル１１に格納される。

図５は、アラート情報テーブル１１の格納内容の例である。同図においてアラート情報テーブル１１には、アラート番号、障害コード、発生日時と発生サブシステムの名称が格納される。発生サブシステムとは、図２において障害が発生した監視対象システム２の名称である。またアラート情報テーブル１１には、障害対応が完了した時点でその日時が格納され、また必要に応じて障害への対応者の名前などが格納される。

図３のステップＳ１４で、対応予測時刻算出機能６によって障害情報がチェックされ、前述の対応予測時刻の算出が行なわれる。すなわちアラート情報テーブル１１の障害コードに対応して、障害情報テーブル１２からその障害の対応完了までに必要な対応必要時間の予測値、または実績値が抽出され、現時刻への加算によって対応予測時刻の算出が行なわれる。

図６は障害情報テーブル１２の格納データの例である。このテーブルには、発生した障害の障害コード、障害内容、障害の発生したサブシステムの名称と所在地、障害対応に必要な時間の予測（実績）値、障害の影響を受けるサブシステムの名称などが格納されている。

続いてステップＳ１５で対応必須時刻算出機能７によって、業務予定情報テーブル１３から障害が発生したシステムの業務予定が抽出され、他の業務、すなわち他の監視対象システム２の動作に影響がでないようにするためには、何時までに障害対応が完了していなければならないか、すなわち対応必須時刻の抽出が行なわれる。

図７は、業務予定情報テーブル１３の格納データの例である。このテーブルには、図２の監視対象システム２、すなわち動作サブシステムに対応して、業務ごとの運用計画からその業務予定を管理するためのデータが格納される。データとしては業務名、処理名、データ、相手先のシステム、動作サブシステム、現時点における状況としての業務の完了必須時刻と、その業務のステータスなどが格納されている。

次にステップＳ１６で時刻比較機能９によって、時間管理テーブル１５の格納内容を用いて、対応予測時刻が対応必須時刻より前であるか否かが判定される。前である場合にはステップＳ１７で通知先選択機能８によって通知先選択処理その１が実行される。この通知先選択処理その１では担当者情報テーブル１４の格納内容を用いて発生した障害の対応を行なうことができるスキルを持つ担当者の絞込みが行なわれる。

図８は、時間管理テーブル１５の格納データの例である。このテーブルには、発生した障害の障害コードに対応して、前述の対応予測時刻と対応必須時刻、担当者からのリプライメールに記述されている対応開始可能時刻、および対応開始可能時刻に対応予測時間を加算した加算結果としての復旧予定時刻が格納されている。

図９は、担当者情報テーブル１４の格納内容の例である。このテーブルには、担当者ごとにその番号、氏名、所属、担当するサブシステム、すなわち監視対象システム２の名称、メールアドレス、連絡先としての電話番号、現時点での所在地、その担当者のステータス、その担当者が障害への対応が不可能な場合の次の通知先、例えば上司の番号を示す通知先２、その担当者がスキルを保有するサブシステムの名称などが格納されている。なおステータスとしては、長期出張中や休暇中などもあることは当然である。

ステップＳ１８で、通知先選択機能８によって担当者ステータスチェックが行なわれる。すなわちステップＳ１７で絞り込まれた担当者ごとに、担当者情報テーブル１４の格納内容からその時点における所在、および勤務状況などのチェックが行なわれ、対応必須時刻までに明らかに障害対応ができないと判断される担当者を除いて、障害発生通知先の最終絞込みが行なわれる。なお担当者の所在については、例えば携帯電話として現在地を確認できるＧＰＳ機能が搭載されたものを使用して、より正確な位置情報を得ることも可能であり、また将来的には対応可能場所までの移動時間を自動的に算出する仕組みを利用することも考えられる。

続いてステップＳ１９で、障害に対応できるスキルを持つ担当者の全てが対応不可能であるか否かが通知先選択機能８によって判定され、全ての担当者が対応不可でない、すなわち少なくとも一部の担当者が対応可能と考えられる場合には、ステップＳ２０でメール管理機能５によって通知メールが作成され、絞り込まれたスキルを持つ担当者３に対して通知メールが送信される。なお前述のように受信側の担当者３は携帯電話のメール機能を利用することを前提とする。さらに通知メールに関する情報はメール管理テーブル１６に格納される。

図１０は、通知メールの例である。このメールの１行目には障害コード、２行目には障害メッセージ、３行目には障害発生日時が記述され、４行目には対応必須時刻までにその担当者が対応可能か否かを入力するための質問、５行目には対応可能な場合に対応開始可能時刻を担当者が入力することを要求する質問が記述されている。

図１１は、メール管理テーブル１６の格納内容の例である。このテーブルには、メールの番号、通知メール、リプライメール、または周知メールの区別を示すメール種別、発信日時、通知先／発信元、例えば通知メールに対してリプライがあったか否かを示すステータス、リプライメールから抽出される対応開始可能時刻などが格納される。

続いてステップＳ２１でメール管理機能５は通知メールに対する一定時間のリプライ待ちとなり、ステップＳ２２でその一定時間の間に担当者からのリプライメールを受信したか否かがメール管理機能５によって判定され、受信した場合にはステップＳ２３でリプライメールの内容チェックが行なわれる。すなわち担当者は、受信した通知メールに対応して対応可能か否か、対応可能な場合には対応開始可能時刻を記述したリプライメールを自動アラートシステム１に対して返信するため、メール管理機能５によってステップＳ２４で担当者が対応可能か否かが判定され、対応可能な場合には時刻比較機能９によって対応開始可能時刻に対応予測時間を加算した加算結果としての復旧予定時刻と対応必須時刻とが比較され、対応必須時刻より復旧予定時刻が前である場合には、ステップＳ２６でメール管理機能５によって周知メールの作成と送信が行なわれて処理を終了する。

図１２は、リプライメールの例である。その１行目には対応必須時刻までに対応可能であることを示す“ｙ”、２行目には対応可能開始時刻が記述され、３行目以下は図１０で説明した通知メールの内容と同一である。担当者によって対応可能か否か、対応可能な場合に対応開始可能時刻が入力されて、担当者３から自動アラートシステム１にこのメールが送信される。

図１３は、周知メールの例である。この周知メールは、障害の発生した監視対象システム２に対するスキルを持つ担当者３以外の全ての担当者３、および上司・メーカー等関係者４の全てに対して障害に関する周知を行なうためのものであり、その１行目には障害コード、２行目には障害メッセージ、３行目には障害発生日時、４行目には障害対応予定者、５行目には障害の復旧予定時刻が記述されている。なおこの周知メールやリプライメールに関する情報も図１１のメール管理テーブルに格納される。

図３のステップＳ１６で対応予測時刻が対応必須時刻より前でない場合には、ステップＳ３１からＳ３５で、通知先選択機能８によって通知選択処理その１と通知先選択処理その２との両方を含む処理が行われた後に、ステップＳ２０以降の処理に移行する。すなわちこの場合には、現在の時刻から直ちに障害への対応を開始したとしても、対応必須時刻以前に対応完了、すなわち障害復旧を行なうことが不可能であることが予測されるために、障害の起こった監視対象システム２に対するスキルを持つ担当者だけでなく、その担当者の上司・メーカー等関係者４を含み、全ての担当者と関係者に通知メールを送信するためにステップＳ３１で通知先選択処理１、ステップＳ３２で担当者ステータスチェックがいずれも通知先選択機能８によって実行され、ステップＳ３３で通知先選択処理その２が実行された回数を示すｎの値が“１”であるか否かが判定される。

ここではｎの値はステップＳ１１で初期値として設定された“０”であり、ステップＳ３４で通知先選択機能８によって通知先選択処理その２が行われた後に、ステップＳ３５でｎの値がインクリメントされ、ステップＳ２０の処理に移行する。またステップＳ１９で、通知先選択機能８によって選択（ステップＳ１７）されたスキルを持つ担当者がすべて対応不可と判定されると、ステップＳ３３以降の処理に移行する。

ステップＳ２２で一定の待ち時間の間に担当者からのリプライメールが受信されなかったと判定されると、ステップＳ３３以降の処理に移行する。この時、通知先選択処理その２の実行回数を示すｎの値が“１”でないと判定された場合には、ステップＳ３４以降の処理が行なわれる。

ｎの値が“１”であると判定されると、すでに通知先選択処理その１と通知先選択処理その２とが実行されていることになり、通知メールが全ての関係者にすでに送信されているにも拘わらず、スキルを持つ担当者による障害対応が不可能であることになり、ステップＳ３８で対応不可周知メールがメール管理機能５によって作成され、担当者３、上司・メーカー等関係者４などの全ての関係者にそのメールが送信されて、処理を終了する。

図１４は、この対応不可周知メールの例である。このメールの１行目には障害コード、２行目には障害メッセージ、３行目には障害発生日時、４行目には対応必須時刻までに障害対応ができないことを示す通知文が記述されている。

図３のステップＳ２４でリプライメールを送信してきた担当者が障害対応不可能である場合、あるいはステップＳ２５で対応可能であっても対応必須時刻より復旧予定時刻が前でない場合には、ステップＳ３７でスキルを持つ担当者全員からリプライメールが返ってきたか否かがメール管理機能５によって判定され、まだ返ってきていない場合にはステップＳ２１の通知メールリプライ待ち以降の処理が繰り返され、すでに返ってきた場合にはステップＳ３３以降の処理が繰り返される。なおここでスキルを持つ担当者全員とは、障害の起こった監視対象システム２に対するスキルを持つ担当者３のみでなく、上司・メーカー等関係者４であっても、障害発生システムに対応するスキルを持つ関係者を含むものとする。

以上において本発明の障害発生通知プログラムなどについてその詳細を説明したが、このプログラムは当然一般的なコンピュータシステムによって実行することが可能である。図１５はそのようなコンピュータシステム、すなわちハードウェア環境の構成ブロック図である。

図１５においてコンピュータシステムは中央処理装置（ＣＰＵ）２０、リードオンリメモリ（ＲＯＭ）２１、ランダムアクセスメモリ（ＲＡＭ）２２、通信インタフェース２３、記憶装置２４、入出力装置２５、可搬型記憶媒体の読取り装置２６、およびこれらの全てが接続されたバス２７によって構成されている。

記憶装置２４としてはハードディスク、磁気ディスクなど様々な形式の記憶装置を使用することができ、このような記憶装置２４、またはＲＯＭ２１に図３などのフローチャートに示されたプログラムや、本発明の特許請求の範囲の請求項１〜３のプログラムなどが格納され、そのようなプログラムがＣＰＵ２０によって実行されることにより、本実施形態における対応予測時刻と対応必須時刻との比較結果に対応した通知メール送信先の選択などが可能となる。

このようなプログラムは、プログラム提供者２８からネットワーク２９、および通信インタフェース２３を介して、例えば記憶装置２４に格納されることも、また市販され、流通している可搬型記憶媒体３０に格納され、読取り装置２６にセットされて、ＣＰＵ２０によって実行されることも可能である。可搬型記憶媒体３０としてはＣＤ−ＲＯＭ、フレキシブルディスク、光ディスク、光磁気ディスク、ＤＶＤなど様々な形式の記憶媒体を使用することができ、このような記憶媒体に格納されたプログラムが読取り装置２６によって読取られることにより、本実施形態における障害発生の通知が可能となる。

本発明の障害発生通知プログラムの原理的な機能ブロック図である。 自動アラートシステムを含む障害発生通知方式の全体システム構成ブロック図である。 障害発生通知処理の詳細フローチャートである。 アラートメールの例である。 アラート情報テーブルの格納例である。 障害情報テーブルの格納例である。 業務予定情報テーブルの格納例である。 時間管理テーブルの格納例である。 担当者情報テーブルの格納例である。 通知メールの例である。 メール管理テーブルの格納例である。 リプライメールの例である。 周知メールの例である。 対応不可周知メールの例である。 本発明のプログラムのコンピュータへのローディングを説明する図である。

符号の説明

１ 自動アラートシステム
２ 監視対象システム
３ 担当者
４ 上司・メーカー等関係者
５ メール管理機能
６ 対応予測時刻算出機能
７ 対応必須時刻算出機能
８ 通知先選択機能
９ 時刻比較機能
１１ アラート情報テーブル
１２ 障害情報テーブル
１３ 業務予定情報テーブル
１４ 担当者情報テーブル
１５ 時間管理テーブル
１６ メール管理テーブル
２０ 中央処理装置（ＣＰＵ）
２１ リードオンリメモリ（ＲＯＭ）
２２ ランダムアクセスメモリ（ＲＡＭ）
２３ 通信インターフェース
２４ 記憶装置
２５ 入出力装置
２６ 読取装置
２７ バス
２８ プログラム提供者
２９ ネットワーク
３０ 可搬型記憶媒体

Claims (5)

1. 外部から与えられる障害発生情報に対応して、障害と対応必要時間とを対応付けて記憶した障害対応テーブルを参照し、該障害の対応に要する対応必要時間を現時刻に加算した対応予測時刻を算出する対応予測時刻算出手順と、
   業務上の必要性によって該障害対応が完了すべき対応必須時刻と、前記対応予測時刻算出手順で算出した対応予測時刻とを比較する比較手順と、
   前記業務の担当者情報を記憶した担当者情報テーブルを参照し、前記比較手順による比較の結果に応じて障害発生を通知すべき担当者を選択し、選択された担当者に該障害発生を通知する障害発生通知手順と
   を計算機に実行させることを特徴とする障害発生通知プログラム。
2. 前記障害発生通知手順において、前記対応予測時刻が対応必須時刻より早い時、前記障害発生を該障害に対応可能なスキルを持つ担当者に通知することを特徴とする請求項１記載の障害発生通知プログラム。
3. 前記スキルを持つ担当者から障害対応開始可能時刻の通知を受けた時、該障害対応開始可能時刻に前記対応必要時間を加算して復旧予定時刻を算出する復旧予定時刻算出手順と、
   前記復旧予定時刻算出手順で算出した復旧予定時刻と前記対応必須時刻とを比較する第２の比較手順と、
   前記担当者情報テーブルを参照し、前記第２の比較手順による比較結果に応じて、前記障害に関連する担当者に該障害への対応の可／否を通知する対応可否通知手順と
   をさらに計算機に実行させることを特徴とする請求項２記載の障害発生通知プログラム。
4. 外部から与えられる障害発生情報に対応して、障害と対応必要時間とを対応付けて記憶した障害対応テーブルを参照し、該障害の対応に要する対応必要時間を現時刻に加算した対応予測時刻を算出する対応予測時刻算出ステップと、
   業務上の必要性によって該障害対応が完了すべき対応必須時刻と、前記対応予測時刻算出ステップで算出した対応予測時刻とを比較する比較ステップと、
   前記業務の担当者情報を記憶した担当者情報テーブルを参照し、前記比較ステップによる比較の結果に応じて障害発生を通知すべき担当者を選択し、選択された担当者に該障害発生を通知する障害発生通知ステップと
   を計算機に実行させるプログラムを格納した計算機読出し可能可搬型記憶媒体。
5. 障害と対応必要時間とを対応付けて記憶する障害対応テーブルと、
   外部から与えられる障害発生情報に対応して、前記障害対応テーブルを参照し、該障害の対応に要する対応必要時間を現時刻に加算した対応予測時刻を算出する対応予測時刻算出手段と、
   業務上の必要性によって該障害対応が完了すべき対応必須時刻と、前記対応予測時刻算出手段で算出した対応予測時刻とを比較する比較手段と、
   前記業務の担当者情報を記憶する担当者情報テーブルと、
   前記担当者情報テーブルを参照し、前記比較手段による比較の結果に応じて障害発生を通知すべき担当者を選択し、選択された担当者に該障害発生を通知する障害発生通知手段と
   を備えることを特徴とする障害発生通知装置。

Images