JPH0993248A - ネットワーク管理システムおよび障害発生情報送信方法 - Google Patents

Abstract

(57)【要約】 【課題】ネットワークに障害が発生した場合、情報混乱
を起こさないように通知先に障害発生情報を通知する手
段を提供する。 【解決手段】管理端末は、ネットワーク障害発生時の障
害発生情報の通知先端末と通知の優先度とを対応付けて
記憶した通知先記憶手段と、障害発生情報を各通知先端
末に通知する通知処理手段とを備える。そして、該通知
処理手段は、優先度の一番高い通知先端末から、優先度
の一番低い通知先端末へと、順次、優先度を参照しなが
ら通知処理を行う。また、前記通知処理手段は、通知取
消手段によって、通知先端末への障害発生情報の取消し
が指示された場合、その時点での優先度より低い優先度
をもつ通知先端末への通知処理を停止する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワークシス
テムにおいて障害が発生した場合、障害発生情報を端末
に通知する技術に係り、特に、通知先が多数ある場合に
有効な障害発生情報の通知手段に関する。

【０００２】

【従来の技術】図２は、ある企業内におけるネットワー
クの構成例を示す図である。

【０００３】図示したように、本社構内１には、ＷＡＮ
（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）２との接続機
能を有するゲートウエイ１０を中心に、各階のハブ１１
〜１５を経由して、放射状にＬＡＮ（Ｌｏｃａｌ Ａｒ
ｅａ Ｎｅｔｗｏｒｋ）２０−ａ〜ｑが配置されてい
る。

【０００４】１階は、本社構内１内のネットワーク全体
を管理する管理センタであり、ゲートウエイ１０が配置
され、該ゲートウエイ１０には、ＬＡＮ２０−ｆ、ｇが
接続配置されている。ネットワークの故障状態、運用等
を管理する機能を有するネットワーク管理端末４０、ネ
ットワーク管理端末４０からの指令を受けて、所定の送
信先に電子メールを配信する機能を有する電子メールサ
ーバ３０、および、従業員用の端末３１−ｂ〜ｅも、Ｌ
ＡＮ２０−ｆ、ｇに接続されている。

【０００５】また、その他の階では、ゲートウエイ１０
に接続するハブ１１〜１５を介して、ＬＡＮ２０−ｈ〜
ｑが接続配置されており、さらに、従業員用の端末３２
−ａ〜ｆ、３３−ａ〜ｆ、３４−ａ〜ｆ、３５−ａ〜
ｆ、３６−ａ〜ｆが、これらのＬＡＮ２０−ｈ〜ｑに接
続されている。また、ＷＡＮ２を介して、他支店点のネ
ットワークとも接続され、宛先「Ａ−２、Ａ−３」は、
他支店に存在する。

【０００６】以上のネットワーク構成を備える本社構内
１には、本社構内１全体のネットワークの管理を担当す
る主管理者（Ａ）と、副管理者（Ｂ〜Ｋ）が存在し、各
人には、各々端末が割り当てられている。即ち、端末の
うち「黒色の端末」は、主管理者用の端末であり、この
例では、１階のほかに、６階に１台（３６−ｄ）設けら
れている。また、端末のうち「「×」記号で示した端
末」は、副管理者用の端末であり、この例では、各階に
１、２台づつ設けられている。これらの配置例は、１例
にすぎない。

【０００７】次に、図２を参照して説明すると、例え
ば、主管理者（Ａ）には、端末３６−ｄが、副管理者
（Ｂ）には、端末３６−ｂが割り当てられているものと
する。

【０００８】通常時には、主管理者（Ａ）は、１階の管
理センタ内のネットワーク管理端末４０上で作業を行っ
ている。

【０００９】また、副管理者は、各階のＬＡＮ毎に一人
ずつ存在し、通常時には、各自の端末を使用して業務を
遂行しており、ネットワークの障害発生時等の緊急時に
は、主管理者の補助をするために、ネットワークの復旧
等の作業を担当することになる。

【００１０】以上述べたネットワーク構成において、ネ
ットワークに障害が発生した際の、障害発生の通知方法
について説明する。

【００１１】図３に、ネットワーク管理端末４０の構成
図を示す。図３に示したようにネットワーク管理端末４
０は、装置全体の制御を行うＣＰＵ５０と、メモリ５１
と、ＬＡＮとのインタフェース制御を行うＬＡＮｉ／ｆ
５２、および、これらを互いに接続するバス５３と、を
有して構成される。

【００１２】さらに、メモリ５１には、ネットワークに
障害が発生しているか否かを監視し、障害発生時には、
その対策を実行する障害監視処理プログラム４１と、障
害発生時の通知先が登録してある障害通知先テーブル４
２が格納されている。障害通知先テーブル４２内には、
障害発生情報の通知先の電子メールアドレス４２−ａと
して、主管理者（Ａ−１〜３）および副管理者（Ｂ〜
Ｋ）宛の電子メールアドレス４２−ａが、登録されてい
る。なお、主管理者（Ａ）宛のアドレスが、Ａ−１〜３
と、複数登録されているのは、主管理者が複数の異なる
場所に配置された端末を使用することを考慮しているた
めである。ただし、図２には、Ａ−２、Ａ−３宛の端末
を図示していないが、これらは他支店構内にあるものと
する。

【００１３】このように、ＣＰＵ５０は、障害監視処理
プログラム４１にしたがって動作し、障害発生時の情報
を、電子メールによって、障害通知先テーブル４２に登
録された通知先に送信する。実際の電子メールの送信
は、図示しないメールサーバを駆動することにより行
う。

【００１４】さて、図４に、障害監視処理プログラム４
１の内容を示すフローチャートを示す。

【００１５】図４に示したように、ネットワーク管理端
末４０は、常にネットワーク障害が発生していないか否
かを監視している（ステップ９）。

【００１６】次に、ネットワーク管理端末４０は、回線
不通等の障害を検出すると、表示画面上にその旨を表示
し、主管理者に、障害発生を知らせる（ステップ１
０）。

【００１７】そして、ネットワーク管理端末４０は、図
３に示した障害通知先テーブル４２に予め登録された通
知先（Ａ−１〜３、およびＢ〜Ｋ）へ、ネットワークの
障害発生を通知するための、電子メールを送信する処理
を行う（ステップ１１）。

【００１８】図２に示すように、ネットワーク管理端末
４０が送信した電子メールは、一旦電子メールサーバ３
０へ送られる（図２中「」で示す）。そして、電子メ
ールは、電子メールサーバ３０において、電子メールを
他端末へ転送するために用いられる「．ｆｏｒｗａｒ
ｄ」ファイルや、ＰＯＰ（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐ
ｒｏｔｏｃｏｌ）等の設定により、主管理者（Ａ−１）
の端末３６−ｄ、およびＡ−２、Ａ−３宛の端末（図２
には、図示していないが他支店に存在する）や、各副管
理者（Ｂ〜Ｋ）用の端末３１−ｄ、３２−ａ、３２−
ｆ、３３−ｂ、３３−ｄ、３４−ｃ、３４−ｅ、３５−
ａ、３５−ｆ、３６−ｂ、３６−ｄへ自動的に転送され
ることになる（図２中「」で示す）。

【００１９】これにより、主管理者が、管理センタ内の
ネットワーク管理端末４０を使用して作業を行っている
場合には、ネットワーク管理端末４０の表示処理によ
り、即座に、ネットワークの障害発生を知ることが可能
となる。また、主管理者が、管理センタ以外の部署の端
末（例えば、６階の端末３６−ｄ（電子メールアドレ
ス：Ａ−１））や、他支店の端末（電子メールアドレ
ス：Ａ−２、Ａ−３）を使用して作業を行っている場合
であっても、電子メールが送られてくることによって、
ネットワークの障害発生を知ることが可能となる。さら
に、主管理者が、不在、あるいは、端末の存在場所から
離れていた場合であっても、副管理者宛にネットワーク
の障害発生を通知する電子メールが送信されるため、副
管理者が、ネットワークの障害発生を知ることが可能で
ある。

【００２０】また、ネットワークの障害発生により、主
管理者宛への電子メールが届かなかった場合でも、ネッ
トワークの障害発生の影響を受けていない、他のＬＡＮ
の副管理者宛の電子メールは届けられるため、副管理者
への障害発生の通知が可である。

【００２１】そして、ネットワークの障害発生を知った
副管理者は、即座に、その障害に直接対応、あるいは、
主管理者に電話等で障害の発生を通知する等の処置をと
ることが可能となる。このようにして、ネットワークの
障害発生に対する対応が可能であった。

【００２２】

【発明が解決しようとする課題】ところで、前述した、
従来のネットワーク障害の通知方法では、主管理者が、
不在、あるいは、端末の存在場所から離れていた場合で
も、副管理者へ、ネットワークの障害発生を電子メール
で通知することによって、副管理者の誰かが、ネットワ
ーク障害に対応することが可能となる。

【００２３】しかし、主管理者が、ネットワーク管理端
末４０や、他の端末（例えば、端末３６−ｄ）を使用し
て作業をしており、ネットワークの障害発生を、ネット
ワーク管理端末４０の画面表示、あるいは、電子メール
によって、即座に知った場合であっても、副管理者宛
に、ネットワークの障害発生を通知する電子メールが送
信されてしまうことになる。

【００２４】この結果、副管理者は、主管理者が、既
に、ネットワーク障害に対応しているのか否か等の確認
を行う必要があった。

【００２５】また、ネットワークの障害発生に気付き、
その旨を副管理者に問い合わせたが、詳細な情報が得ら
れずに、直接、主管理者へ問い合わせようとする、一般
ユーザーや障害の詳細内容を知りたいと考えた副管理者
による、主管理者への電子メールや電話等での問い合わ
せが殺到する可能性がある。

【００２６】このような問い合わせが殺到する結果、主
管理者が、ネットワーク障害の対応に専念できない事態
を招いていた。

【００２７】さらに、自分の端末が接続されているＬＡ
Ｎ内において、障害が発生していることを気づいた副管
理者が、ネットワークの障害発生を通知する電子メール
を受けとったことで、自分の端末が接続されているＬＡ
Ｎを、ゲートウェイから切り離す等の対策を、勝手に行
ってしまう可能性がある。このような勝手な作業は、障
害の原因の判明を遅らせることや、障害の範囲をさらに
広げること等の原因となり、結局は、ネットワーク障害
の復旧作業の完了を遅らせる原因ともなっていた。

【００２８】そこで、本発明は、このような従来の課題
を解決し、ネットワークシステムにおいて障害が発生し
た場合に、情報混乱等を招かずに、障害復旧を迅速に行
うことを可能とするような、障害発生情報の通知手段を
提供することにある。

【００２９】

【課題を解決するための手段】上記課題を解決するため
に、以下の手段がある。

【００３０】即ち、複数の端末と管理端末とを、ネット
ワークを介して通信可能にしたシステムであって、前記
管理端末は、ネットワーク障害発生時の障害発生情報の
通知先端末と通知の優先度とを対応付けて記憶した通知
先記憶手段と、障害発生情報を各通知先端末に通知する
通知処理手段とを備える。そして、該通知処理手段は、
優先度の一番高い通知先端末から、優先度の一番低い通
知先端末へと、順次、優先度を参照しながら通知処理を
行っていく、ネットワーク管理システムである。

【００３１】なお、前記通知処理手段は、ある優先度を
もつ各通知先端末に対する障害発生情報の通信処理を終
了し、次に低い優先度をもつ各通知先端末に対する障害
発生情報の通信処理を行う前に、所定時間の経過を待つ
機能を有するように構成した、ネットワーク管理システ
ムも考えられる。

【００３２】また、前記管理装置は、さらに、通知先端
末への障害発生情報の取消しを指示する通知取消手段を
備え、前記通知処理手段は、さらに、該通知取消手段に
よって、通知先端末への障害発生情報の取消しが指示さ
れた場合、その時点での優先度より低い優先度をもつ通
知先端末への通知処理を停止する、ネットワーク管理シ
ステムも好ましい。

【００３３】また、以下のような方法の態様も考えられ
る。

【００３４】即ち、管理端末から通信先端末に障害発生
情報を送信する方法であって、前記管理端末は、障害発
生情報の通知先端末と通知の優先度とを対応付けを予め
行っておき、優先度の一番高い通知先端末から、優先度
の一番低い通知先端末へと、順次、優先度を参照しなが
ら通知処理を行っていく。そして、通知先端末への障害
発生情報の取消しを指示された時点で、その時点での優
先度より低い優先度をもつ通知先端末への通知を停止す
る障害発生情報送信方法である。

【００３５】本発明にかかる手段の動作は、以下のよう
になる。

【００３６】複数の端末と管理端末とを、ネットワーク
を介して通信可能にしたシステムを想定する。前記管理
端末が備える通知先記憶手段には、ネットワーク障害発
生時の障害発生情報の通知先端末と通知の優先度とを対
応付けて記憶しておく。そして、通知処理手段は、障害
発生情報を各通知先端末に通知する。即ち、該通知処理
手段は、優先度の一番高い通知先端末から、優先度の一
番低い通知先端末へと、順次、優先度を参照しながら通
知処理を行う。

【００３７】なお前記通知処理手段は、ある優先度をも
つ各通知先端末に対する障害発生情報の通信処理を終了
し、次に低い優先度をもつ各通知先端末に対する障害発
生情報の通信処理を行う前に、所定時間の経過を待つ機
能を有する。これによって、優先度に従って、段階的な
通知処理が行われる。

【００３８】また、通知取消手段によって、通知先端末
への障害発生情報の取消しを指示された場合、前記通知
処理手段は、その時点での優先度より低い優先度をもつ
通知先端末への通知処理を停止する。これによって情報
混乱を避けることができる。

【００３９】さらに、前記通知先記憶手段には、通知先
端末と通知の優先度とを対応付けを、該優先度が時間帯
によって変化するようにして記憶しておき、前記通知処
理手段は、時間帯によって変化する優先度の一番高い通
知先端末から優先度の一番低い通知先端末へと、順次、
時間帯によって変化する優先度を参照しながら通知処理
を行っていくことによって、より実情を考慮した通知先
を選択できる。

【００４０】

【発明の実施の形態】以下、本発明の実施形態を図面を
参照して説明するが、本発明の理解の容易化のため、ま
ず、本発明の概要について述べ、その後、具体的な実施
形態について説明することにする。

【００４１】（発明の概要）本発明の概要を、図１、図
５を参照して説明する。

【００４２】図１に示すネットワーク管理端末１００
は、装置全体の制御を行うＣＰＵ１０１と、メモリ１０
２と、ＬＡＮとのインタフェース制御を行うＬＡＮｉ／
ｆ１０３と、タイマー１０５と、これらを互いに接続す
るバス１０４と、を有して構成される。

【００４３】さらに、メモリ１０２によって、ネットワ
ークに障害が発生しているか否かを監視し、障害発生時
には、以下に述べる所定の処理を行う障害監視処理手段
１０６と、障害発生時の通知先が登録してある障害先記
憶手段１０７が実現される。

【００４４】障害先記憶手段１０７は、障害発生情報の
通知先と、それに対応する通知の優先度が対応付けて登
録されている。ＣＰＵ１０１は、障害監視処理手段１０
６等を起動して、所定の処理を行わせる。

【００４５】さて、ネットワーク管理端末１００は、ネ
ットワーク障害が発生した場合、障害監視処理手段１０
６により、まず、ネットワーク障害発生の旨を表示画面
上に表示する（ステップ１、２）。

【００４６】次に、通知先記憶手段１０７に記憶された
優先度の一番高い通知先へ、ネットワークの障害発生を
通知する（ステップ３）。

【００４７】そして、所定時間後に、優先度のより低い
通知先への通知を開始することと、この通知を中止した
い場合には、通知中止命令を実行することとを、表示画
面上に表示し、タイマーを使用した監視を開始する（ス
テップ４、５）。

【００４８】タイマーを使用した監視開始後、所定時間
（ｎ分）経過しても、優先度のより低い通知先への通知
中止命令が実行されない場合には、優先度のより低い通
知先への通知を開始する。

【００４９】逆に、所定時間内に、通知中止命令が実行
された場合には、優先度のより低い通知先への通知は行
わない（ステップ６、７、８）。

【００５０】これにより、通知中止命令が実行された場
合、つまり優先度の高い通知先（例えば主管理者）がネ
ットワークの障害発生を知った場合には、優先度のより
低い通知先（例えば副管理者）への通知は実行されな
い。

【００５１】このため、優先度のより低い通知先は、ネ
ットワークの障害発生に気づいていても、現在、優先度
の高い通知先の担当者が、障害に対処していることが分
かり、勝手に障害に対応することや、優先度の高い通知
先への問い合わせが殺到する事態の発生が回避できる。
この結果、障害の原因判明の遅延や、障害の範囲の拡
大、が回避され、優先度の高い通知先の担当者は、障害
対策に専念できる。

【００５２】逆に、所定時間経過しても通知中止命令が
実行されなかった場合、つまり優先度の高い通知先の担
当者が、ネットワークの障害発生を知ることがなかった
場合には、優先度のより低い通知先は、優先度のより高
い通知先の担当者の不在や障害発生に気付いていないと
判断できるため、自らがネットワーク障害に迅速に対処
することが可能となり、ネットワークの障害発生を、誰
もが知らないという状況の発生を阻止できる。

【００５３】（具体的な実施形態）以下、本発明の実施
形態を図面を参照しつつ詳細に説明する。

【００５４】図６に、本発明にかかるネットワーク管理
端末４０の構成形態を示す。図示したように、ネットワ
ーク管理端末４０は、装置全体の制御を行うＣＰＵ５
０、メモリ５１、ＬＡＮインターフェイスであるＬＡＮ
ｉ／ｆ５２、各構成要素間で情報の伝送を行うためのバ
ス５３、タイマー５４、障害情報や情報通知動作の取消
しを指示するコマンド入力を促す情報を表示する表示装
置５５、および、各種コマンド、特に、情報通知動作の
取消しを指示するコマンドを少なくとも入力するための
入力装置を、有して構成される。

【００５５】なお、表示装置５５に対する表示処理は、
ＣＰＵ５０が、図示しない予め定めたプログラムを内蔵
しておいたＲＯＭの内容を参照して行う。また、入力装
置５６は、キーボードやマウスで実現できるが、情報通
知動作の取消しを指示するコマンドを入力可能とするた
めタッチパネル式のディスプレイで実現しても良い。

【００５６】さて、前記メモリ５１には、障害監視処理
プログラム４１と、障害通知先テーブル４３とを格納し
ている。障害通知先テーブル４３には、障害発生情報の
通知先である電子メールアドレス４３−ａと、通知先に
対する優先度４３−ｂとを対応付けて格納している。な
お、本実施形態では、優先度４３−ｂの値が「１」の場
合が最も高く、次に、「０」の場合が、より優先度が低
いものとして、２種類の優先度を設定している。具体的
には、主管理者（Ａ−１〜３）に対する優先度を「１」
にして、副管理者（Ｂ〜Ｋ）に対する優先度を「０」に
設定してある。

【００５７】また、ＣＰＵ５０が、障害監視処理プログ
ラム４１にしたがった動作を行うことで、本管理端末４
０が、所定の動作を行うように構成されている。

【００５８】次に、図７に、障害監視処理プログラム４
１の内容を表すフローチャートを示す。また、図８に
は、本発明を、図２に示したような本社構内１のネット
ワークに適用した場合の動作概要を示す。

【００５９】図７に示したように、ネットワーク管理端
末４０は、障害監視処理プログラム４１により、常に、
ネットワークに障害が発生していないか否かを監視する
（ステップ１２）。次に、ネットワーク管理端末４０
が、回線不通等の障害を検出すると、ネットワーク管理
端末４０の表示画面にその旨を表示し、主管理者に対し
て障害発生を通知する（ステップ１３）。

【００６０】さらに、ネットワーク管理端末４０は、障
害通知先テーブル４３に登録された優先度“１”の通知
先、つまり、最も優先度の高い通知先である主管理者宛
（Ａ−１〜３）に、ネットワークの障害発生を通知する
ための電子メールを送信する（ステップ１４）。

【００６１】ここで、図８に示すように、ネットワーク
管理端末４０の送信した電子メールは、一旦、電子メー
ルサーバ３０に送られ、さらに、電子メールサーバ３０
は、主管理者用の端末へと電子メールを転送する（図示
する動作、、）。

【００６２】次に、ネットワーク管理端末４０は、表示
画面上に、「ｎ分後に副管理者宛に障害発生通知の電子
メールを送信します。キャンセルする場合にはキャンセ
ルボタンを押して下さい。」という内容と、キャンセル
ボタンウィンドウを表示し、タイマー５４をセットする
（ステップ１５、１６）。キャンセルボタンウィンドウ
は、表示処理によって実現すればよい。また、「ｎ分
後」は、任意に設定しうる値であり、設定時間に対応可
能なタイマー５４を採用すれば良い。

【００６３】この時、主管理者が、ｎ分の間に画面の表
示内容、あるいは、電子メールにより、ネットワークの
障害発生を知り、キャンセルボタンを押した場合には、
ネットワーク管理端末４０は、何もせず終了する。つま
り、ネットワーク管理端末４０は、副管理者宛に電子メ
ールを送信することは行わない。

【００６４】逆に、主管理者が、ｎ分経過してもネット
ワークの障害発生を知ることがなく、キャンセルボタン
を押すことがなかった場合には、ネットワーク管理端末
４０は、障害通知先テーブル４３に登録された、次に低
い優先度に対する通知先、即ち、優先度「０」の通知
先、つまり副管理者宛（Ｂ〜Ｋ）に対してネットワーク
の障害発生を通知するための電子メールを送信し、処理
を終了する（ステップ１７〜１９）。

【００６５】このことを図８を参照して説明すると、ネ
ットワーク管理端末４０が送信した電子メールは、一
旦、電子メールサーバ３０に送られ、さらに、電子メー
ルサーバ３０は、副管理者用の端末へ電子メールを転送
するのである（図示する動作、、）。

【００６６】これにより、主管理者が、ネットワークの
障害発生を即座に知った場合には、副管理者宛の電子メ
ールの送信が中止される。このため、副管理者は、ネッ
トワークの障害発生に気付いていても、自分宛の障害通
知を伝える電子メールが送信されて来ないことから、主
管理者が、障害に対応しているものと判断し、主管理者
へ、障害等についての問い合わせを行うことが不要とな
る。また、ネットワークの障害発生に気付いていない副
管理者も、障害の発生を知ることはないため、副管理者
が、自ら勝手に障害の対策を行うことがなくなる。この
ため、障害の原因究明の遅延や、障害範囲の拡大等を阻
止できる。また、副管理者や一般ユーザーによる、主管
理者への問い合わせの殺到を防止でき、主管理者は、ネ
ットワーク障害の復旧作業に専念することが可能とな
る。

【００６７】逆に、主管理者が、端末の存在場所から離
れていたり、主管理者宛の電子メールがネットワーク障
害により届かなかった等の理由により、主管理者がネッ
トワークの障害発生を知らないままであった場合であっ
ても、副管理者宛に電子メールが送信されるため、副管
理者が、ネットワークの障害に対して迅速に対応できる
ようになる。

【００６８】ところで、前述の実施形態では、障害発生
の通知先の優先度として、主管理者と副管理者との２種
類しか設定していないが、副管理者間で、さらに数種類
の優先度を設定しておいてもよいのは、言うまでもな
い。むしろ、通常は、複数種類の優先度を設定しておく
のが好ましい。

【００６９】それには、障害通知先テーブル４３内の優
先度４３ーｂに、複数の優先度を設定、格納しておき、
障害監視処理プログラム４１を、優先度の高い通知先か
ら、優先度の低い通知先へと、順に、優先度を下げてい
きながら、ネットワーク障害発生の通知の電子メールを
送信するようにすればよい。

【００７０】このような設定により、各副管理者の夫々
に、異なる優先度を与えた場合、ネットワーク障害発生
の通知の電子メールにより、ネットワークの障害発生を
最初に知った管理者は、自分以外の管理者がネットワー
クの障害発生に気付いていないと判断し、自らが、迅速
にネットワーク障害に対応しても混乱が生じることが無
くなる。またこの場合には、副管理者の間で、誰がネッ
トワーク障害に対応するか等の確認をする必要もなくな
る。このように、複数種類の優先度を設定しておくこと
によって、混乱を生じさせずに、より迅速に障害対策を
可能なように、障害情報を通知することができる。

【００７１】また、前述の実施形態では、ネットワーク
の障害発生を通知する手段として、電子メールを利用し
ているが、この他にも、例えば、ページャ等の通信手段
を併存させてることで、ネットワーク障害により電子メ
ールでは通知ができない場合であってもも、別の通信手
段によって、障害発生の通知を行うことが可能となる。

【００７２】このためには、図６に示すネットワーク管
理端末４０に対して、図９に示すように、モデムの機能
を有するモデム部６０を追加して構成にすれば良い。

【００７３】ＣＰＵ５０は、ＲＯＭ（図示せず）に予め
内蔵したプログラムに従って、モデム部６０を起動し、
電話回線を介して、ページャによって障害通知を行うよ
うにしておく。すなわち、ページャによる障害通知先
を、予め障害通知先テーブル４４に登録しておき、登録
されたページャによる障害通知先を参照して、ページャ
による障害通知を行うように、ＣＰＵ５０は、モデム部
６０を起動動作する。

【００７４】具体例としては、障害通知先テーブル４４
の内容を、図１０に示すように変更し、障害監視処理プ
ログラム４１を、図１１に示すように変更すれば良い。

【００７５】図１０に示すように、障害通知先テーブル
４４には、通知先として、電子メールアドレス／電話番
号（ページャ用）４４−ａと、優先度４４−ｂ、およ
び、使用する通知装置を示す通知手段４４−ｃとが、登
録されている。なお、電子メールアドレス／電話番号４
４−ａにおいて、「Ａ−４」は、主管理者が所有してい
るページャの電話番号である。優先度４４−ｂには、
「２」から「０」までの３段階（「２」、「１」、
「０」）の３段階の値が設定されており、「２」が最も
高い優先度であり、「０」が最も低い優先度として設定
されている。

【００７６】さて、図１１に示すように、ネットワーク
管理端末４０は、ネットワークの障害発生を検出すると
（ステップ２０）、その旨を、表示画面に表示後（ステ
ップ２１）、優先度４４−ｂが最も高い「２」の通知先
から、順に、障害発生通知キャンセルが実行されるま
で、各通知手段４４−ｃを利用して、障害通知を行って
いく（ステップ２２〜２７）。

【００７７】つまり、ネットワーク管理端末４０は、最
初に、優先度４４−ｂ「２」の通知先である主管理者宛
（Ａ−１〜３）へ電子メールを利用して障害通知を行
う。次に、障害発生通知のキャンセルが実行されなけれ
ば、優先度４４−ｂ「１」の通知先である主管理者宛
（Ａー４）へ、ページャを利用して再度通知する。最後
に、優先度４４−ｂ「０」の通知先である副管理者宛
（Ｂ−１、Ｃ−１、…、Ｊ、Ｋ）へ、電子メールにより
障害通知を行う。

【００７８】本実施形態では、変数ｉを変化させること
によって、順次、優先度を変化させて、優先度に応じた
通知処理を行っている。

【００７９】なお、ページャを使用する場合には、ネッ
トワーク管理端末４０内のモデム部６０を利用すること
は、前出したとおりである。

【００８０】このように、複数種類の通知手段を利用し
て、ネットワークの障害発生を通知することが可能とな
り、例えば電子メールが使用不可能な場合であっても、
ページャで通知することが可能となる等、通信系の信頼
性が高まる。

【００８１】さらに、時間帯によって通知先の優先度を
変更するようにするのも好ましい。

【００８２】それには、障害通知先テーブル７０を、図
１２に示すように変更すれば良い。

【００８３】即ち、各通知先に対する優先度を、各時間
帯毎に設定する。この場合、さらに、障害監視処理プロ
グラム４１を、図１３に示すように変更すればよい。

【００８４】さて、図１２に示したように、障害通知先
テーブル７０には、通知先の、電子メールアドレス／電
話番号７０−ａと、各時間帯毎の優先度７０−ｂ〜ｄ
と、通知手段７０−ｅとが対応して登録されている。

【００８５】本実施形態では、時間帯として、「AM9:00
〜PM6:00（勤務時間内）」、「PM6:00〜PM11:00（残業
時間内）」、および、「PM11:00〜AM9:00（勤務時間
外）」の３種類が考慮され、各時間帯に対する優先度が
登録されている。

【００８６】図１３に示すように、ネットワーク管理端
末４０は、ネットワークの障害発生を検出すると（ステ
ップ２８）、その旨を表示画面に表示後（ステップ２
９）、障害通知先テーブル７０に登録された障害発生の
時刻に対応した時間帯の優先度を選択し、障害発生の通
知を行う（ステップ３０〜ステップ３５）。なお、各ス
テップ毎の処理の説明は、図１１等とほぼ同等のため省
略する。

【００８７】つまり、障害が「勤務時間内」に発生した
場合、ネットワーク管理端末４０は、 「主管理者（Ａ
−１〜３：電子メール）→主管理者（Ａ−４：ページ
ャ）→副管理者（Ｂ〜Ｋ）」の順で障害発生の通知を実
行する。

【００８８】同様に、ネットワーク障害が「残業時間
内」に発生した場合には、「主管理者（Ａ−１〜３：電
子メール）→副管理者（Ｂ〜Ｋ）→主管理者（Ａ−４：
ページャ）」の順で、さらに、「勤務時間外」の場合に
は、「副管理者（Ｂ〜Ｋ）→主管理者（Ａ−４：ページ
ャ）」の順で障害発生が通知される。

【００８９】これにより、時間帯に応じて、通知の優先
度を変更することが可能となり、ネットワーク管理者の
勤務体系に合わせた、障害通知処理が可能となる。

【００９０】

【発明の効果】上述したように、本発明によれば、ネッ
トワーク管理において、主管理者がネットワークの障害
発生を、ネットワーク管理端末上の表示や電子メールに
よって把握した場合には、副管理者宛に対し、ネットワ
ークの障害発生を通知する電子メールを送信する必要が
なくなる。

【００９１】このため、副管理者は、ネットワークの障
害発生に気付いていても、自分宛の障害通知の電子メー
ルが送信されて来ないので、主管理者が、障害に対処し
きれていると判断でき、主管理者への問い合わせも不要
となり、障害発生時の情報混乱がなくなる。また、ネッ
トワークの障害発生に気付いていない副管理者も、障害
発生を知ることはないため、副管理者自らが勝手に、障
害対策を行うことがなくなる。この結果、障害原因の判
明が遅れたり、障害の範囲が広まるといった、いわば２
次災害もなくなる。

【００９２】また、副管理者や一般ユーザーによる、主
管理者への問い合わせの殺到を防止することが可能とな
り、主管理者は、ネットワーク障害の対応に専念するこ
とができるようになり、障害復旧の迅速化が図れること
にもつながる。

【００９３】逆に、主管理者が、管理端末から離れてい
たり、主管理者宛の電子メールがネットワーク障害によ
り届かなかった等の様々な理由により、主管理者がネッ
トワークの障害発生を知らないままであった場合には、
副管理者宛に電子メールが送信されることになり、この
場合には、副管理者がネットワーク障害に対して迅速に
対応することが可能となる。

【図面の簡単な説明】

【図１】本発明にかかるネットワーク管理端末の構成図
である。

【図２】本社構内に設置されるネットワーク構成例、お
よび、従来のネットワーク障害の通知方法における電子
メールの流れを示す説明図である。

【図３】従来のネットワーク管理端末の構成図である。

【図４】従来の障害監視処理の内容を示すフローチャー
トである。

【図５】本発明にかかる処理内容を示すフローチャート
である。

【図６】本発明にかかる実施形態におけるネットワーク
管理端末の構成図である。

【図７】本発明にかかる実施形態である障害監視処理内
容を示すフローチャートである。

【図８】本発明にかかる実施形態における電子メールの
流れを示す説明図である。

【図９】本発明の他の実施形態におけるネットワーク管
理端末の構成図である。

【図１０】本発明の他の実施形態における障害通知先テ
ーブルの説明図である。

【図１１】本発明の他の実施形態における障害監視処理
内容を示すフローチャートである。

【図１２】本発明のさらに他の実施形態における障害通
知先テーブルの説明図である。

【図１３】本発明のさらに他の実施形態における障害監
視処理内容を示すフローチャートである。

【符号の説明】

１０１…ＣＰＵ、１０２…メモリ、１０３…ＬＡＮｉ／
Ｆ、１０４…バス、１０５…タイマー、１０６…障害監
視処理手段、１０７…通知先記憶手段

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 庁内整理番号 ＦＩ 技術表示箇所 Ｈ０４Ｌ 12/58

Claims (7)

【特許請求の範囲】
1. 【請求項１】複数の端末と管理端末とを、ネットワーク
   を介して通信可能にしたシステムであって、 前記管理端末は、 ネットワーク障害発生時の障害発生情報の通知先端末と
   通知の優先度とを対応付けて記憶した通知先記憶手段
   と、障害発生情報を各通知先端末に通知する通知処理手
   段とを備え、 該通知処理手段は、優先度の一番高い通知先端末から、
   優先度の一番低い通知先端末へと、順次、優先度を参照
   しながら通知処理を行っていく、ネットワーク管理シス
   テム。
2. 【請求項２】請求項１において、前記通知処理手段は、
   ある優先度をもつ各通知先端末に対する障害発生情報の
   通信処理を終了し、次に低い優先度をもつ各通知先端末
   に対する障害発生情報の通信処理を行う前に、所定時間
   の経過を待つ機能を有することを特徴とする、ネットワ
   ーク管理システム。
3. 【請求項３】請求項１および２のいずれかにおいて、前
   記管理装置は、さらに、通知先端末への障害発生情報の
   取消しを指示する通知取消手段を備え、 前記通知処理手段は、さらに、該通知取消手段によっ
   て、通知先端末への障害発生情報の取消しが指示された
   場合、その時点での優先度より低い優先度をもつ通知先
   端末への通知処理を停止することを特徴とする、ネット
   ワーク管理システム。
4. 【請求項４】請求項１、２および３のいずれかにおい
   て、前記通知先記憶手段は、通知先端末と通知の優先度
   とを対応付けを、該優先度が時間帯によって変化するよ
   うにして記憶し、 前記通知処理手段は、時間帯によって変化する優先度の
   一番高い通知先端末から優先度の一番低い通知先端末へ
   と、順次、時間帯によって変化する優先度を参照しなが
   ら通知処理を行っていく、ネットワーク管理システム。
5. 【請求項５】請求項１、２、３および４のいずれかに記
   載のネットワーク管理システムに、電子メールを配信可
   能なメールサーバを備え、 該メールサーバは、前記通知処理手段が通信処理する通
   信先に、電子メールで障害発生情報を送信する、ネット
   ワーク管理システム。
6. 【請求項６】請求項１、２、３および４のいずれかに記
   載のネットワーク管理システムに、障害発生情報を送信
   可能なページャ装置を備え、 該ページャ装置は、前記通知処理手段が通信処理する通
   信先に、障害発生情報を送信するように構成されてい
   る、ネットワーク管理システム。
7. 【請求項７】管理端末から通信先端末に障害発生情報を
   送信する方法であって、 前記管理端末は、 障害発生情報の通知先端末と通知の優先度とを対応付け
   を予め行っておき、優先度の一番高い通知先端末から、
   優先度の一番低い通知先端末へと、順次、優先度を参照
   しながら通知処理を行っていき、 通知先端末への障害発生情報の取消しを指示された時点
   で、その時点での優先度より低い優先度をもつ通知先端
   末への通知を停止することを特徴とする障害発生情報送
   信方法。