(57)【要約】【課題】通信経路における障害によりパケットが送信先に届かない場合にも、パケットが送信先に届いていないことを早期に検出できるシステムを実現する。【解決手段】サーバ装置１は、障害が発生した際に障害の発生を通知する障害発生通報パケットをコールセンタ装置６に送信するとともに、障害発生通報パケットの送信回数を計数し、コールセンタ装置６は、障害発生通報パケットを受信する度に障害発生通報パケットの受信回数を計数する。サーバ装置１は、所定の周期で、障害発生通報パケットの送信回数をコールセンタ装置６に通知し、コールセンタ装置６は、計数している受信回数と、サーバ装置１から通知された送信回数とを比較し、受信回数が送信回数よりも少ない場合に、通信経路における障害により障害発生通報パケットがコールセンタ装置６に届いていないと判断することができる。【選択図】図１
2012068729.tif 000002
【特許請求の範囲】
【請求項１】
所定のイベントが発生した際に、イベントの発生を通知するイベント通知を生成するイベント通知生成部と、
前記イベント通知生成部により生成されたイベント通知を所定の管理装置に対して送信するイベント通知送信部と、
前記イベント通知送信部によりイベント通知が送信される度に、イベント通知の送信回数を計数するイベント通知送信回数計数部と、
所定の間隔で、前記イベント通知送信回数計数部により計数されたイベント通知の送信回数を通知する送信回数通知を生成する送信回数通知生成部と、
前記送信回数通知生成部により生成された送信回数通知を前記管理装置に対して送信する送信回数通知送信部とを有することを特徴とする情報処理装置。
【請求項２】
前記情報処理装置は、
所定の監視対象物における障害を検出し、障害検出イベントを発生させる障害検出部を有し、
前記イベント通知生成部は、
前記障害検出部により障害検出イベントが発生した場合に、障害検出イベントを通知するイベント通知を生成することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
情報処理装置から、前記情報処理装置における所定のイベントの発生を通知するイベント通知を受信するイベント通知受信部と、
前記イベント通知受信部によりイベント通知が受信される度に、イベント通知の受信回数を計数するイベント通知受信回数計数部と、
前記情報処理装置から所定の間隔で送信される、前記情報処理装置で計数されたイベント通知の送信回数が通知される送信回数通知を受信する送信回数通知受信部と、
前記送信回数通知受信部により送信回数通知が受信された際に、受信された送信回数通知で通知されているイベント通知の送信回数と、前記イベント通知受信回数計数部により計数されているイベント通知の受信回数とを比較する比較部と、
前記比較部による比較の結果、イベント通知の送信回数とイベント通知の受信回数が一致しない場合に、異常の発生の可能性を警告する警告メッセージを生成する警告メッセージ生成部と、
前記警告メッセージ生成部により生成された警告メッセージを出力する警告メッセージ出力部とを有することを特徴とする管理装置。
【請求項４】
前記管理装置は、更に、
前記送信回数通知受信部が前記情報処理装置から送信回数通知を受信してからの経過時間を計測し、経過時間が所定の閾値を超過した場合に、経過時間が閾値を超過したことを通知する経過時間計測部を有し、
前記警告メッセージ生成部は、
前記経過時間計測部から経過時間が閾値を超過したことが通知された場合に、警告メッセージを生成することを特徴とする請求項３に記載の管理装置。
【請求項５】
前記警告メッセージ生成部は、
前記情報処理装置との通信経路における異常の発生の可能性を警告する警告メッセージを生成することを特徴とする請求項３又は４に記載の管理装置。
【請求項６】
前記警告メッセージ出力部は、
前記情報処理装置の保守を行う保守センタに設けられている装置に対して、警告メッセージを出力することを特徴とする請求項３〜５のいずれかに記載の管理装置。
【請求項７】
前記管理装置は、
複数の情報処理装置に接続され、
前記イベント通知受信部は、
情報処理装置ごとに、イベント通知を受信し、
前記イベント通知受信回数計数部は、
情報処理装置ごとに、イベント通知の受信回数を計数し、
前記送信回数通知受信部は、
情報処理装置ごとに、送信回数通知を受信し、
前記比較部は、
情報処理装置ごとに、イベント通知の送信回数とイベント通知の受信回数とを比較し、
前記警告メッセージ生成部は、
前記比較部による比較の結果、イベント通知の送信回数とイベント通知の受信回数が一致しない情報処理装置がある場合に、当該情報処理装置について異常の発生の可能性を警告する警告メッセージを生成することを特徴とする請求項３〜６にいずれかに記載の管理装置。
【請求項８】
前記管理装置は、更に、
情報処理装置ごとに、前記送信回数通知受信部が送信回数通知を受信してからの経過時間を計測し、経過時間が所定の閾値を超過した情報処理装置がある場合に、当該情報処理装置について経過時間が閾値を超過したことを通知する経過時間計測部を有し、
前記警告メッセージ生成部は、
前記経過時間計測部から経過時間が閾値を超過したことが通知された情報処理装置について、警告メッセージを生成することを特徴とする請求項７に記載の管理装置。
【請求項９】
前記管理装置は、更に、
前記警告メッセージ生成部により警告メッセージが生成された情報処理装置の保守を行う保守センタに設けられている装置に対して、警告メッセージを出力する警告メッセージ出力部を有することを特徴とする請求項７又は８に記載の管理装置。
【請求項１０】
前記イベント通知受信部は、
情報処理装置で発生した障害検出イベントを通知するイベント通知を受信することを特徴とする請求項３〜９のいずれかに記載の管理装置。
【請求項１１】
所定のイベントが発生した際に、イベントの発生を通知するイベント通知を生成するイベント通知生成処理と、
前記イベント通知生成処理により生成されたイベント通知を所定の管理装置に対して送信するイベント通知送信処理と、
前記イベント通知送信処理によりイベント通知が送信される度に、イベント通知の送信回数を計数するイベント通知送信回数計数処理と、
所定の間隔で、前記イベント通知送信回数計数処理により計数されたイベント通知の送信回数を通知する送信回数通知を生成する送信回数通知生成処理と、
前記送信回数通知生成処理により生成された送信回数通知を前記管理装置に対して送信する送信回数通知送信処理とをコンピュータに実行させることを特徴とするプログラム。
【請求項１２】
情報処理装置から、前記情報処理装置における所定のイベントの発生を通知するイベント通知を受信するイベント通知受信処理と、
前記イベント通知受信処理によりイベント通知が受信される度に、イベント通知の受信回数を計数するイベント通知受信回数計数処理と、
前記情報処理装置から所定の間隔で送信される、前記情報処理装置で計数されたイベント通知の送信回数が通知される送信回数通知を受信する送信回数通知受信処理と、
前記送信回数通知受信処理により送信回数通知が受信された際に、受信された送信回数通知で通知されているイベント通知の送信回数と、前記イベント通知受信回数計数処理により計数されているイベント通知の受信回数とを比較する比較処理と、
前記比較処理による比較の結果、イベント通知の送信回数とイベント通知の受信回数が一致しない場合に、異常の発生の可能性を警告する警告メッセージを生成する警告メッセージ生成処理と、
前記警告メッセージ生成処理により生成された警告メッセージを出力する警告メッセージ出力処理とをコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバ装置等において障害が発生した際に、コールセンタ等の通知先に障害の発生を通知する技術に関する。
【背景技術】
【０００２】
図１８を参照して従来の障害通報方式を説明する。
【０００３】
図１８において、１００は監視対象となるサーバ装置である。
２は、サーバ装置１００の障害発生を監視する監視部である。
２１は、障害を検出する障害検出部である。
２２は、障害の発生を通報する障害発生通報パケットを生成する通報通知作成部である。
２３は、障害発生通報パケットを送信する通報通知送信部である。
３０〜３ｍは、サーバ装置１００の構成要素群である。
４０〜４ｍは、障害検出用信号群である。
５は、通信回線である。
５０は、サーバ側ルータである。
６００は、障害発生通報パケットを受けるコールセンタ装置である。
６０は、センタ側ルータである。
６１は、コールセンタ装置６００の全体の制御を行う制御部である。
６２は、障害発生通報パケットを受信する通報通知受信部である。
６３は、障害発生通報パケットを解析して後述する通知メッセージ６６を生成する通知作成部である。
６４は、通知メッセージ６６を蓄積する通知蓄積部である。
６５は、通知メッセージ６６を出力する通知出力部である。
６６は、サーバ装置１００における障害内容を通知する通知メッセージであり、例えば、電子メールである。
７は、サーバ装置１００の保守を行う保守センタである。
７１は、保守員である。
９は、通信回線である。
【０００４】
次に動作について説明する。
ここでは、サーバ装置１００の構成要素３０で障害が発生した場合を例に説明する。
構成要素３０で障害が発生すると、サーバ装置１００では、障害検出用信号４０が有意になり、それを障害検出部２１で検出したサーバ監視部２は障害発生通報パケットを通報通知作成部２２で生成し、通報通知送信部２３経由でコールセンタ装置６００に向けて送信する。
障害発生通報パケットはサーバ側ルータ５０、通信回線５、センタ側ルータ６０を経由し、コールセンタ装置６００に届く。
コールセンタ装置６００では、通報通知受信部６２で障害発生通報パケットを受信し、解析し、障害が発生したサーバ装置１００の設置場所に近い保守センタ７に障害内容を通知する通知メッセージ６６を通知生成部６３で生成する。
通知メッセージ６６は、人がわかる形式のメッセージであり、例えば、電子メールである。
コールセンタ装置６００では、通知メッセージ６６を通知蓄積部６４に蓄積した後、通知出力部６５が保守センタに送信する。
通知メッセージを受けた保守センタ７では、通知の内容からサーバ装置１００の構成要素の交換部品を携えた保守員７１がサーバ設置場所に行き、サーバ装置１００の故障部品を交換する。
こうして、サーバ装置１００は正常状態に復帰することができる。
【０００５】
また、例えば、特許文献１では、障害通報（Ａ）を受け付けたとき、通報履歴ＤＢを調べ、所定時間内の過去に同一顧客から障害通報（Ｂ）があれば、障害通報（Ａ、Ｂ）の組み合わせが、関連通報ＤＢに存在するかを調べ、関連通報ＤＢに、この組み合わせが登録されていれば、障害通報（Ａ）を障害通報（Ｂ）の関連通報とし、通知を省略もしくは参考情報として通知する方式が開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００７−８００３５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
図１８を参照して説明した従来の障害通報方式、更には、特許文献１の方式においても、例えばサーバ側ルータ５０が故障している場合には、サーバ装置１００の構成要素３０で障害が発生した時に、サーバ装置１００が障害発生通報パケットを生成し、送信しても、サーバ側ルータ５０が故障しているために、障害発生通報パケットがコールセンタ装置６００に届かず、保守センタ７への障害発生通知は行われない。
従って、例えば、サーバ装置１００の管理者がサーバ障害に気づき、保守センタなどに人手で通報するまでサーバの障害状態が継続し、システムの信頼性を下げてしまうという課題がある。
【０００８】
この発明は、上記のような課題を解決することを主な目的の一つとしており、通信経路における障害により通知が通知先に届かない場合にも、通知が通知先に届いていないことを早期に検出できるシステムを実現することを主な目的とする。
【課題を解決するための手段】
【０００９】
本発明に係る情報処理装置は、
所定のイベントが発生した際に、イベントの発生を通知するイベント通知を生成するイベント通知生成部と、
前記イベント通知生成部により生成されたイベント通知を所定の管理装置に対して送信するイベント通知送信部と、
前記イベント通知送信部によりイベント通知が送信される度に、イベント通知の送信回数を計数するイベント通知送信回数計数部と、
所定の間隔で、前記イベント通知送信回数計数部により計数されたイベント通知の送信回数を通知する送信回数通知を生成する送信回数通知生成部と、
前記送信回数通知生成部により生成された送信回数通知を前記管理装置に対して送信する送信回数通知送信部とを有することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、情報処理装置が、イベント通知を管理装置に送信する度にイベント通知の送信回数を計数し、計数したイベント通知の送信回数を管理装置に通知するため、管理装置で計数されたイベント通知の受信回数と、情報処理装置から通知されたイベント通知の送信回数とを比較することにより、管理装置にイベント通知が届いていないことを早期に検出できる。
【図面の簡単な説明】
【００１１】
【図１】実施の形態１及び２に係るシステム構成例を示す図。
【図２】実施の形態１に係るサーバ装置の構成例を示す図。
【図３】実施の形態１に係るコールセンタ装置の構成例を示す図。
【図４】実施の形態１に係る障害発生通報パケットの構成例を示す図。
【図５】実施の形態１に係る障害発生回数通知パケットの構成例を示す図。
【図６】実施の形態２に係るコールセンタ装置の構成例を示す図。
【図７】実施の形態３に係るコールセンタ装置の構成例を示す図。
【図８】実施の形態１に係るサーバ装置の障害発生通報処理の手順例を示すフローチャート図。
【図９】実施の形態１に係るサーバ装置の障害発生回数通知処理の手順例を示すフローチャート図。
【図１０】実施の形態１に係るコールセンタ装置の通報関連処理の手順例を示すフローチャート図。
【図１１】実施の形態１に係るコールセンタ装置の障害発生通報処理の手順例を示すフローチャート図。
【図１２】実施の形態１に係るコールセンタ装置の障害発生回数通知処理の手順例を示すフローチャート図。
【図１３】実施の形態２及び３に係るコールセンタ装置の通報関連処理の手順例を示すフローチャート図。
【図１４】実施の形態３に係るコールセンタ装置の障害発生通報処理の手順例を示すフローチャート図。
【図１５】実施の形態３に係るコールセンタ装置の障害発生回数通知処理の手順例を示すフローチャート図。
【図１６】実施の形態３に係るコールセンタ装置の経路障害確認処理の手順例を示すフローチャート図。
【図１７】実施の形態１〜３に係るサーバ装置１及びコールセンタ装置６のハードウェア構成例を示す図。
【図１８】従来技術のシステム構成例を示す図。
【発明を実施するための形態】
【００１２】
実施の形態１．
図１は、本実施の形態に係るシステム構成例を示す。
【００１３】
図１では、サーバ装置１がサーバ側ルータ５０、通信回線５及びセンタ側ルータ６０を介してコールセンタ装置６に接続されている。
そして、コールセンタ装置６は通信回線９を介して保守センタ７内の保守センタ装置７０に接続されている。
図１８を参照して説明したように、サーバ装置１の構成要素において障害が発生すると、サーバ装置１から障害発生通報パケットがサーバ側ルータ５０、通信回線５、及びセンタ側ルータ６０を経由してコールセンタ装置６に送信される。
コールセンタ装置６では、障害発生通報パケットを解析し、障害内容を通知する通知メッセージ６６を生成し、保守センタ装置７０に送信する。
通知メッセージを受けた保守センタ７では、通知の内容からサーバ装置１の構成要素の交換部品を携えた保守員７１がサーバ設置場所に行き、サーバ装置１の故障部品を交換する。
なお、サーバ装置１は情報処理装置の例であり、コールセンタ装置６は管理装置の例である。
【００１４】
図２は、本実施の形態に係るサーバ装置１の構成例を示す。
図２において、障害通報送信カウンタ２４、送信間隔設定部２５、送信間隔計測タイマ２６及び要求信号２７以外は、図１８に示した要素と同じである。
但し、通報通知作成部２２及び通報通知送信部２３は、図１８とは異なる機能を有する。
以下では、通報通知作成部２２、通報通知送信部２３、障害通報送信カウンタ２４、送信間隔設定部２５、送信間隔計測タイマ２６及び要求信号２７について説明し、他の要素の説明は省略する。
【００１５】
本実施の形態では、通報通知作成部２２は、障害検出部２１による障害検出というイベント（障害検出イベント）が発生した際に、障害の発生（障害検出イベントの発生）を通知する障害発生通報パケット（イベント通知）を生成するとともに、所定の間隔で、後述する障害通報送信カウンタ２４により計数された障害発生通報パケット（イベント通知）の送信回数を通知する障害発生回数通知パケット（送信回数通知）を生成する。
通報通知作成部２２は、イベント通知生成部及び送信回数通知生成部の例である。
【００１６】
通報通知送信部２３は、通報通知作成部２２により生成された障害発生通報パケット及び障害発生回数通知パケットをコールセンタ装置６に対して送信する。
通報通知送信部２３は、イベント通知送信部及び送信回数通知送信部の例である。
【００１７】
障害通報送信カウンタ２４は、通報通知送信部２３により障害発生通報パケット（イベント通知）が送信される度に、障害発生通報パケットの送信回数を計数する。
障害通報送信カウンタ２４は、イベント通知送信回数計数部の例である。
【００１８】
送信間隔設定部２５は、通報通知作成部２２が障害発生回数通知パケットを生成し、通報通知送信部２３が障害発生回数通知パケットを送信する間隔（周期）を後述の送信間隔計測タイマ２６に設定する。
【００１９】
送信間隔計測タイマ２６は、送信間隔設定部２５により設定された間隔（周期）にて、要求信号２７を通報通知作成部２２に出力するタイマである。
【００２０】
図３は、本実施の形態に係るコールセンタ装置６の構成例を示す。
図３において、通報確認部８内の要素以外は、図１８に示した要素と同じである。
但し、通報通知受信部６２、通知生成部６３及び通知出力部６５は、図１８とは異なる機能を有する。
以下では、通報通知受信部６２、通知生成部６３、通知出力部６５及び通報確認部８内の要素について説明し、他の要素の説明は省略する。
【００２１】
通報通知受信部６２は、サーバ装置１から送信された障害発生通報パケット（イベント通知）を受信するとともに、サーバ装置１から所定の間隔で送信される障害発生回数通知パケットを受信する。
障害発生回数通知パケットは、前述したように、サーバ装置１で計数された障害発生通報パケットの送信回数が通知されるパケットである。
通報通知受信部６２は、イベント通知受信部及び送信回数通知受信部の例である。
【００２２】
通報通知解析部８０は、通報通知受信部６２により受信されたパケットが障害発生通報パケットであるか障害発生回数通知パケットであるかを判別する。
そして、障害発生通報パケットである場合は、通報通知解析部８０は障害発生通報パケットを通知生成部６３に転送するとともに、障害通報受信カウンタ８１に障害発生通報パケットを受信したことを通知する。
また、障害発生回数通知パケットである場合は、通報通知解析部８０は障害発生回数通知パケット内の数値（サーバ装置１で計数した障害発生通報パケットの送信回数）を障害通報送信回数受信部８２に出力する。
【００２３】
障害通報受信カウンタ８１は、通報通知解析部８０から障害発生通報パケットを受信した旨の通知を受ける度に、障害発生通報パケットの受信回数を計数する。
障害通報受信カウンタ８１は、イベント通知受信回数計数部の例である。
【００２４】
障害通報送信回数受信部８２は、通報通知解析部８０から障害発生回数通知パケット内の数値（サーバ装置１で計数した障害発生通報パケットの送信回数）を入力し、比較部８３に出力する。
【００２５】
比較部８３は、障害通報送信回数受信部８２から障害発生回数通知パケット内の数値を入力した際（つまり、通報通知受信部６２が障害発生回数通知パケットを受信した際）に、障害通報送信回数受信部８２から入力した数値（サーバ装置１で計数した障害発生通報パケットの送信回数）と障害通報受信カウンタ８１で計数されている受信回数とを比較する。
そして、比較部８３は、比較の結果、送信回数と受信回数が一致しない場合に、通知生成部６３に対して、通信経路における異常の発生の可能性を警告する警告メッセージの生成を指示する。
【００２６】
通知生成部６３は、通報通知解析部８０から障害発生通報パケットを入力した場合に、図１８の場合と同様に障害内容を通知する通知メッセージ６６を生成するとともに、比較部８３から警告メッセージの生成指示を入力した場合に、警告メッセージを生成する。
比較部８３は、警告メッセージ生成部の例である。
【００２７】
通知出力部６５は、通知生成部６３により生成された通知メッセージ６６を保守センタ装置７０に対して送信するとともに、通知生成部６３により警告メッセージが生成された場合に、警告メッセージを保守センタ装置７０に送信する。
通知出力部６５は、警告メッセージ出力部の例である。
【００２８】
図４は、サーバ監視部２からコールセンタ装置６に対して送信される障害発生通報パケットの構成例を示す。
障害発生通報パケットは、宛先であるコールセンタ装置６のアドレスがセットされた送信先アドレス部、送信元であるサーバ監視部２のアドレスがセットされた発信元アドレス部、障害通報であることを示すコマンドコードが設定されるコマンド部、障害発生箇所（種類）を示すコードがセットされるデータ部から構成される。
【００２９】
図５は、サーバ監視部２からコールセンタ装置６に対して送信される障害発生回数通知パケットの構成例を示す。
障害発生回数通知パケットは、宛先であるコールセンタ装置６のアドレスがセットされた送信先アドレス部、送信元であるサーバ監視部２のアドレスがセットされた発信元アドレス部、障害発生回数通知であることを示すコマンドコードが設定されるコマンド部、サーバ監視部２からコールセンタ装置６に向けて送信された障害発生通報パケットの送信回数がセットされるデータ部から構成される。
【００３０】
次に、図８〜１２を参照して動作について説明する。
図８は、サーバ装置１がコールセンタ装置６に障害が発生したことを通知する障害発生通報処理の手順例を示す。
図９は、サーバ装置１がコールセンタ装置に障害発生通報パケットの送信回数を通知する障害回数通知処理の手順例を示す。
図１０は、コールセンタ装置６において周期的に実行される通報関連処理の手順例を示す。
図１１は、本実施の形態に係るコールセンタ装置６が障害発生通報を受信した際の障害発生通報処理の手順例であり、図１０のＳＴ２１０の詳細を示す。
図１２は、本実施の形態に係るコールセンタ装置６が障害発生回数通知を受信した際の障害発生回数通知処理の手順例であり、図１０のＳＴ２２０の詳細を示す。
なお、以下では、サーバ装置１の構成要素３０で障害が発生した場合を例に説明を進める。
【００３１】
サーバ装置１の構成要素３０で障害が発生すると（図８のＳＴ１０１でＹＥＳ）、障害検出用信号４０が有意になり、それを障害検出部２１で検出したサーバ監視部２は障害発生通報パケットを通報通知作成部２２で生成する（ＳＴ１０２）（イベント通知生成処理）。
次に、通報通知送信部２３が障害発生通報パケットをコールセンタ装置６に向けて送信する（ＳＴ１０３）（イベント通知送信処理）。
また、この時、障害通報送信カウンタ２４の値がインクリメント（＋１）される（ＳＴ１０４）（イベント通知送信回数計数処理）。
【００３２】
障害発生通報パケットはサーバ側ルータ５０、通信回線５、センタ側ルータ６０を経由し、コールセンタ装置６に届く。
コールセンタ装置６では、通報通知受信部６２で障害発生通報パケットを受信し（図１０のＳＴ２０１でＹＥＳ）（イベント通知受信処理）、通報通知解析部８０にて解析される。
より詳細には、コールセンタ装置６では、通報通知解析部８０が、通報通知受信部６２で受信されたパケットからコマンド部を取り出し（ＳＴ２０２）、コマンド部を解析して受信パケットが障害発生通報パケットであるか障害発生回数通知パケットであるかを判断する（ＳＴ２０３）。
ここでは、受信パケットは障害発生通報パケットであるため、障害発生通報処理（ＳＴ２１０）が行われる。
【００３３】
障害発生通報処理（ＳＴ２１０）では、通報通知解析部８０から障害通報受信カウンタ８１に障害発生通報パケットが受信された旨が通知され、また、通報通知解析部８０から通知生成部６３に障害発生通報パケットが転送される。
そして、通報通知解析部８０から障害発生通報パケットが受信された旨が通知されると、障害通報受信カウンタ８１はカウンタ値をインクリメント（＋１）する（図１１のＳＴ２１１）（イベント通知受信回数計数処理）。
また、通知生成部６３は、障害発生通報パケットの少なくとも発信元アドレスとデータ部を用いて通知メッセージ６６を生成する（ＳＴ２１２）。
次に、通知蓄積部６４が、通知生成部６３により生成された通知メッセージ６６を蓄積するとともに（図１１のＳＴ２１３）、通知出力部６５が保守センタ７の保守センタ装置７０に通知メッセージ６６を送信する（ＳＴ２１４）。
【００３４】
通知メッセージ６６を受けた保守センタ７では、通知の内容からサーバ装置１の構成要素３０の交換部品を携えた保守員７１がサーバ設置場所に行き、サーバ装置１の故障部品を交換する。
こうして、サーバ装置１は正常状態に復帰することができる。
【００３５】
また、サーバ装置１で障害が発生していない間は、送信間隔設定部２５からセットされた時間の間、送信間隔計測タイマ２６が時間の計測を継続する。
設定された時間が経過し、障害発生回数の通知タイミングになると（図９のＳＴ１１１でＹＥＳ）、送信間隔計測タイマ２６は要求信号２７を有意にする。
要求信号２７が有意になると、通報通知作成部２２で要求信号２７が有意になったことを検出し、通報通知作成部２２が障害発生回数通知パケットを生成する（ＳＴ１１２）（送信回数通知生成処理）。
具体的には、通報通知作成部２２は、障害通報送信カウンタ２４のカウンタ値を読み出し、カウンタ値をセットした障害発生回数通知パケットを生成する。
次に、通報通知送信部２３が障害発生回数通知パケットをコールセンタ装置６に向けて送信する（ＳＴ１１３）（送信回数通知送信処理）。
【００３６】
障害発生回数通知パケットはサーバ側ルータ５０、通信回線５、センタ側ルータ６０を経由し、コールセンタ装置６に届く。
コールセンタ装置６では、通報通知受信部６２で障害発生回数通知パケットを受信し（図１０のＳＴ２０１でＹＥＳ）（送信回数通知受信処理）、通報通知解析部８０にて解析される。
より詳細には、コールセンタ装置６では、通報通知解析部８０が、通報通知受信部６２で受信されたパケットからコマンド部を取り出し（ＳＴ２０２）、コマンド部を解析して受信パケットが障害発生通報パケットであるか障害発生回数通知パケットであるかを判断する（ＳＴ２０３及びＳ２０４）。
ここでは、受信パケットは障害発生回数通知パケットであるため、障害発生回数通知処理（ＳＴ２２０）が行われる。
【００３７】
障害発生回数通知処理（ＳＴ２２０）では、通報通知解析部８０から障害通報受信カウンタ８１に障害発生回数通知パケットを受信した旨が通知され、また、通報通知解析部８０から障害通報送信回数受信部８２に障害発生回数通知パケットのデータ部に設定されている数値（障害発生回数）が出力される。
障害通報受信カウンタ８１は、現在のカウンタ値を比較部８３に出力し、また、障害通報送信回数受信部８２は障害発生回数通知パケットのデータ部の数値（障害発生回数）を比較部８３に出力する。
なお、障害発生回数通知パケットが受信された場合は、障害通報受信カウンタ８１の値は変化しない。
【００３８】
比較部８３では、障害通報送信回数受信部８２から出力された障害発生回数通知パケットのデータ部の数値（障害発生回数）と、障害通報受信カウンタ８１から出力されたカウンタ値を比較する（図１２のＳＴ２２１）（比較処理）。
比較の結果、両者の値が一致している場合（ＳＴ２２２でＹＥＳ）には、サーバ監視部２からの障害発生通報パケットは全て正常に処理されたことになるため新たな処理は何も行われない。
一方、両者の値が一致しない場合（ＳＴ２２２でＮＯ）は、比較部８３は通知生成部６３に通信経路に異常が発生している可能性又は異常が発生していた可能性を警告する通知メッセージを生成するよう指示し、通知生成部６３は、このような通知メッセージ（警告メッセージ）を生成する（ＳＴ２２３）（警告メッセージ生成処理）。
次に、通知蓄積部６４が、通知生成部６３により生成された警告メッセージを蓄積するとともに（ＳＴ２２４）、通知出力部６５が保守センタ７の保守センタ装置７０に警告メッセージを送信する（ＳＴ２２５）（警告メッセージ送信処理）。
そして、次回の比較に備え、障害通報送信回数受信部８２の値が障害通報受信カウンタ８１にセットされる（ＳＴ２２６）。
【００３９】
もしも、サーバ側ルータ５０が障害で一時的に動作を停止している間にサーバ装置１で何らかの障害が発生すると、障害発生前に障害通報送信カウンタ２４の値がＮだった場合には、コールセンタ装置６へ障害発生通報パケットは届かないが、サーバ装置１からは障害発生通報パケットは送出されているので障害通報送信カウンタ２４の値はＮ＋１になる。
その後、サーバ側ルータ５０が障害から復旧すると、送信間隔計測タイマ２６に設定されていただけの時間が経過した時に、Ｎ＋１をデータ部に設定した障害通報回数通知パケットがコールセンタ装置６に送信される。
障害通報回数通知パケットを受信したコールセンタ装置６では、それまでに受信した障害発生通報の回数をカウントしていた障害通報受信カウンタ８１の内容Ｎと、障害通報回数通知パケットから取り出された数値Ｎ＋１とが比較部８３で比較される。
この場合は、その出力が不一致を示す状態になるため、障害発生通報の通信経路（サーバ側ルータ５０、通信回線５、センタ側ルータ６０）上で障害が発生している可能性を警告する警告メッセージが保守センタ装置７０に送信される。
そして、次回の比較に備え、障害通報回数通知パケットから取り出された数値Ｎ＋１が障害通報受信カウンタ８１にセットされる。
【００４０】
警告メッセージを受けた保守センタ７では、通知の内容から通信経路に異常が発生している可能性をサーバ装置１の管理者に伝えるとともに、障害発生通報パケットとして通報されなかった障害が何であるかを確認するため、保守員７１がサーバ設置場所に行き、ログなどを解析して、障害箇所を見極め、部品交換することで、サーバ装置１が正常状態に復旧する。
このように、障害発生通報経路に異常がある場合でも、サーバ装置１での障害発生を確実に通報できるようになり、復旧までの時間の長時間化を防ぐことができるので、信頼性の高いシステムを構築することができる。
【００４１】
なお、以上の説明では、障害発生通報パケットをコールセンタ装置６に届けるための通信経路と、障害発生回数通知パケットをコールセンタ装置６に届けるための通信経路が同じである例を説明したが、障害発生通報パケットをコールセンタ装置６に届けるための通信経路と、障害発生回数通知パケットをコールセンタ装置６に届けるための通信経路を別の経路としてもよい。
【００４２】
実施の形態２．
実施の形態１に係るシステムでは、障害発生通報パケットをコールセンタ装置６に届けるための通信経路と、障害発生回数通知パケットをコールセンタ装置６に届けるための通信経路が同じである場合には、通信経路が障害から回復しないと、障害発生回数通知パケットはコールセンタ装置６に届かない。
このため、通信経路の回復に長時間を要する場合には、コールセンタ装置６において、不達になっている障害発生通報パケットの存在を確認するまでに長時間を要することになる。
本実施の形態では、このような事態に対処し、不達になっている障害発生通報パケットの存在を早期に確認できるコールセンタ装置６を説明する。
【００４３】
図６は、本実施の形態に係るコールセンタ装置６の構成例を示す。
コールセンタ装置６以外の要素は、実施の形態１に示したものと同様であるため、コールセンタ装置６以外の要素の説明は省略する。
【００４４】
図６では、図３の構成と比較して、通知受信間隔計測タイマ８４と受信間隔設定部８５が追加されている。
受信間隔設定部８５は、送信間隔設定部２５よりも長い時間間隔を設定する。
通知受信間隔計測タイマ８４は、障害発生回数通知パケットを受信した時に受信間隔設定部８５に設定されている値をセットし、その後時間の経過とともにセット値をカウントダウンしていく。
つまり、通知受信間隔計測タイマ８４は、通報通知受信部６２が障害発生回数通知パケットを受信してからの経過時間を計測し、経過時間が受信間隔設定部８５により設定された値を超過した場合に、経過時間が受信間隔設定部８５の設定値を超過したことを通知生成部６３に通知する。
通知受信間隔計測タイマ８４は、経過時間計測部の例である。
そして、本実施の形態では、通知生成部６３は、通知受信間隔計測タイマ８４から経過時間が受信間隔設定部８５の設定値を超過したことを通知された場合に、警告メッセージを生成する。
【００４５】
次に動作について説明する。
なお、サーバ装置１における動作は、図８及び図９に示す通りである。
つまり、サーバ装置１で障害が発生していない間は、送信間隔設定部２５に設定された時間の間隔で、障害発生回数通知パケットがサーバ監視部２から、サーバ側ルータ５０、通信回線５、センタ側ルータ６０を経由し、コールセンタ装置６に送信される。
【００４６】
本実施の形態に係るコールセンタ装置６の動作は、図１３に示す通りである。
図１３では、図１０と比較して、Ｓ２０５及びＳＴ２３０が追加されており、他の処理は図１０と同様である。
以下では、Ｓ２０５及びＳＴ２３０について説明する。
なお、図１３では、ＳＴ３００、ＳＴ４００、ＳＴ５００も記述されているが、ＳＴ３００、ＳＴ４００、ＳＴ５００は実施の形態３で説明する。
【００４７】
本実施の形態では、通報通知解析部８０が、通報通知受信部６２により受信されたパケットが障害発生回数通知パケットであると判断すると、受信間隔設定部８５に設定されている値が通知受信間隔計測タイマ８４にセットされ、通知受信間隔計測タイマ８４はセット値のカウントダウンを開始する。
つまり、通知受信間隔計測タイマ８４は、障害発生回数通知パケットの受信時刻からの経過時間を計測する。
そして、通信経路に障害が発生しなければ、通知受信間隔計測タイマ８４の値がゼロになる前に、サーバ装置１の送信間隔設定部２５に設定された時間間隔でサーバ監視部２が障害発生回数通知パケットを送信する。
このため、通信経路に障害が発生しなければ、通知受信間隔計測タイマ８４の値がゼロになる前に、通報通知受信部６２が障害発生回数通知パケットを受信し、通報通知解析部８０が障害発生回数通知パケットが受信された旨を確認する。
通報通知解析部８０が障害発生回数通知パケットの受信を確認すると、通知受信間隔計測タイマ８４には受信間隔設定部８５に設定されていた時間が再度セットされ、その後カウントダウンが再度開始される。
結局、通信経路が正常であれば、通知受信間隔の再設定→カウントダウン→通知受信間隔の再設定→カウントダウンが繰り返され、通知受信間隔計測タイマ８４がゼロになることはない。
ここで、もしも、サーバ側ルータ５０に障害が発生した場合、サーバ監視部２からの障害発生回数通知パケットを受信しないため、通知受信間隔計測タイマ８４のカウントダウンが進み、通知受信間隔計測タイマ８４の値がゼロになる。
図１３に従って説明すると、通知受信間隔計測タイマ８４は、単位時間ごとに（ＳＴ２０５）に障害経路確認処理（ＳＴ２３０）を行って、カウントダウンを進め、カウンタ値がゼロになった場合に、通知生成部６３が警告メッセージを生成し、通知出力部６５が警告メッセージを送信する。
ここでは、ＳＴ２０５の単位時間を１秒とし、受信間隔設定部８５が通知受信間隔計測タイマ８４に設定する受信間隔を１０００秒とする例で障害経路確認処理（ＳＴ２３０）を説明する。
【００４８】
ＳＴ２０５により１秒ごとに経路障害確認処理（ＳＴ２３０）が開始され、通知受信間隔計測タイマ８４はカウンタ値をデクリメントし、カウンタ値がゼロになっていなければ、経路障害確認処理（ＳＴ２３０）を終了し、次の１秒が経過するのを待つ。
一方、カウンタ値をデクリメントした結果カウンタ値がゼロになれば（障害発生回数通知パケットを受信していない時間が閾値である１０００秒を超えたら）、通知受信間隔計測タイマ８４が通知生成部６３にカウンタ値がゼロになった旨を通知する。
通知生成部６３は、通知受信間隔計測タイマ８４からの通知を受けて、通信経路の異常の可能性を警告する警告メッセージを生成し、通知出力部６５での蓄積の後、通知出力部６５が警告メッセージを保守センタ装置７０に送信する。
【００４９】
警告メッセージを受けた保守センタ７では、通知の内容から障害通報経路に異常がある旨をサーバ装置１の管理者に伝えるとともに、通信経路の障害箇所を確認するとともに障害発生通報パケットとして通報されなかった障害がないかを確認するため、保守員７１がサーバ設置場所に行き、サーバ側ルータ５０の障害であることを見極め、交換するとともに、サーバ装置１自体には障害はないことを確認することでシステムが正常状態に戻る。
【００５０】
このように、障害発生通報経路に異常がある場合でも、サーバ装置で障害が発生した時に障害発生通報がコールセンタに届かなくなることを未然に防ぐことが可能になり、信頼性の高いシステムを構築することができる。
【００５１】
実施の形態３．
本実施の形態では、複数のサーバ装置１と複数の保守センタ７に対応させたコールセンタ装置６を説明する。
【００５２】
図７は、本実施の形態に係るコールセンタ装置６の構成例を示す。
図示は省略しているが本実施の形態に係るコールセンタ装置６は複数のサーバ装置１にネットワーク接続されている。
また、本実施の形態に係るコールセンタ装置６は、複数の保守センタ７とネットワーク接続されている。
【００５３】
図７は、図６に示した通報確認部８をソフトウェアとして実現している例を示す。
つまり、サーバ群監視情報記憶部８００において、サーバ装置ごとの記憶ブロックを設け、各記憶ブロックに図６に示した通報確認部８を実現するためのデータを格納している。
サーバ１対応情報ブロック８１０は、サーバ番号１のサーバ装置１に対する記憶ブロックであり、サーバｎ対応情報ブロック８ｎ０は、サーバ番号ｎのサーバ装置１に対する記憶ブロックである。
以下では、サーバ１対応情報ブロック８１０を例にして、記憶ブロック内の構成を説明する。
【００５４】
障害通報受信カウンタ８１１は、図６に示した障害通報受信カウンタ８１と同様に動作し、障害発生通報パケットの受信回数を計数する。
障害通報送信回数受信部８１２は、図６に示した障害通報送信回数受信部８２と同様に動作し、通報通知解析部８０から障害発生回数通知パケットのデータ部の数値（障害発生回数）を記憶する。
通知受信間隔計測タイマ８１４は、図６に示した通知受信間隔計測タイマ８４と同様に動作し、障害発生回数通知パケットを受信してからの経過時間を計測する。
受信間隔設定部８１５は、図６に示した受信間隔設定部８５と同様に動作し、通知受信間隔計測タイマ８１４の計測時間をセットする。
アドレス設定部８１６は、サーバ番号１のサーバ装置１の通信アドレスを格納している。
サーバ１近隣保守センタアドレス８１７は、サーバ番号１のサーバ装置１の近隣に設置されている保守センタ７の保守センタ装置７０の通信アドレスを格納している。
サーバ１有効フラグ８１８は、サーバ１対応情報ブロック８１０が登録済で有効であることを示す。
【００５５】
なお、本実施の形態では、図６に示した比較部８３の動作は制御部６１が行うものとする。
つまり、本実施の形態では、例えばサーバ番号１のサーバ装置１の場合では、制御部６１が障害通報受信カウンタ８１１のカウンタ値と障害通報送信回数受信部８１２の値とを比較する。
なお、コールセンタ装置６の他の要素は図６と同じであり、説明を省略する。
【００５６】
次に動作について説明する。
各サーバ装置１における障害発生時の通報および正常時の障害発生回数通知については実施の形態１と同様に行われる。
ここでは、図１３〜図１６を参照して、通報および通知を受信したコールセンタ装置６での動作を中心に述べる。
なお、図１３は、本実施の形態に係るコールセンタ装置６において周期的に実行される通報関連処理の手順例を示す。
図１４は、本実施の形態に係るコールセンタ装置６が障害発生通報を受信した際の障害発生通報処理の手順例であり、図１３のＳＴ３００の詳細を示す。
図１５は、本実施の形態に係るコールセンタ装置６が障害発生回数通知を受信した際の障害発生回数通知処理の手順例であり、図１３のＳＴ４００の詳細を示す。
図１６は、本実施の形態に係るコールセンタ装置６の経路障害確認処理の手順例であり、全てのサーバ装置において通信経路故障による通知の受信タイムアウトが発生していないかを周期的にチェックする動作を示す。
図１６は、図１３のＳＴ５００の詳細を示す。
【００５７】
サーバ装置１からの障害発生通報パケットを通報通知受信部６２で受信する（図１３のＳＴ２０１でＹＥＳ）と、通報通知解析部８０がパケットのコマンド部を取り出して（ＳＴ２０２）パケットを解析し、障害発生通報パケットであることを確認する（ＳＴ２０３でＹＥＳ）。
このため、障害発生通報処理（ＳＴ３００）（図１４）が行われる。
【００５８】
障害発生通報処理（ＳＴ３００）では、制御部６１が、障害発生通報パケットの送信元アドレスを読み出す（図１４のＳＴ３０１）とともに、サーバ群監視情報記憶部８００の記憶ブロックの配置順にアドレス設定部８１６・・・８ｎ６を読み出し（ＳＴ３０２、ＳＴ３０３）、読み出したアドレス設定部のアドレスと障害発生通信パケットの送信元アドレスとの比較を行う（ＳＴ３０４）。
一致しない場合（ＳＴ３０４でＮＯ）は、次の記憶ブロックのアドレス設定部を読み出して（ＳＴ３０９、ＳＴ３１０、ＳＴ３０３）、障害発生通報パケットの送信元アドレスとの比較を行う（ＳＴ３０４）。
【００５９】
一方、ＳＴ３０４でＹＥＳの場合は、当該アドレス設定部が含まれている記憶ブロックに対応するサーバ装置１からの通報であり、制御部６１は、その記憶ブロックを選択する。
以下では、サーバ１対応情報ブロック８１０を選択したとして説明を進める。
制御部６１は、障害通報受信カウンタ８１１の内容をインクリメント（＋１）するとともに、サーバ１近隣保守センタアドレス８１７に格納されているサーバ番号１のサーバ装置１の近隣にある保守センタ７のアドレス（保守センタ装置７０のアドレス）を通知生成部６３に通知メッセージ６６の送信先として通知する（ＳＴ３０５）。
また、制御部６１は、障害発生通報パケットのデータ部の障害発生個所を示すコードを通知生成部６３に通知する（ＳＴ３０６）。
また、制御部６１は、通知生成部６３が通知メッセージ６６を生成するにあたって他に必要なデータがあれば、そのデータを通知生成部６３に通知する（ＳＴ３０７）。
次に、通知生成部６３が通知メッセージ６６を生成し、通知蓄積部６４に蓄積された後に、通知出力部６５が通知メッセージ６６を送信する（ＳＴ３０８）。
通知メッセージ６６の送信先は、ＳＴ３０５で抽出された、サーバ番号１のサーバ装置１の近隣にある保守センタ７の保守センタ装置７０である。
【００６０】
この後、障害発生の通知を受けた保守センタ７から保守員がサーバ装置１の設置場所に派遣され、障害発生箇所の交換が行われてシステムは正常に復帰する。
【００６１】
もしも、サーバ側ルータ５０が障害で一時的に動作を停止している間にサーバ装置１で何らかの障害が発生すると、障害発生前に障害通報送信カウンタ２４の値がＮだった場合には、コールセンタ装置６へ障害発生通報パケットは届かないが、サーバ装置１からは障害発生通報パケットは送出されているので障害通報送信カウンタ２４の値はＮ＋１になる。
その後、サーバ側ルータ５０が障害から復旧すると、送信間隔計測タイマ２６に設定されていただけの時間が経過した時に、Ｎ＋１をデータ部に設定した障害通報回数通知パケットがコールセンタ装置６に送信される。
【００６２】
障害通報回数通知パケットを受信したコールセンタ装置６では、サーバ装置１からの障害発生通報パケットを通報通知受信部６２で受信する（図１３のＳＴ２０１でＹＥＳ）と、通報通知解析部８０がパケットのコマンド部を取り出して（ＳＴ２０２）パケットを解析し、障害発生回数通知パケットであることを確認する（ＳＴ２０３でＮＯ、ＳＴ２０４でＹＥＳ）。
このため、障害発生回数通知処理（ＳＴ４００）（図１５）が行われる。
【００６３】
障害発生回数通知処理（ＳＴ４００）では、制御部６１が、障害発生回数通知パケットの送信元アドレスを読み出す（図１５のＳＴ４０１）とともに、サーバ群監視情報記憶部８００の記憶ブロックの配置順にアドレス設定部８１６・・・８ｎ６を読み出し（ＳＴ４０２、ＳＴ４０３）、読み出したアドレス設定部のアドレスと障害発生回数通知パケットの送信元アドレスとの比較を行う（ＳＴ４０４）。
一致しない場合（ＳＴ４０４でＮＯ）は、次の記憶ブロックのアドレス設定部を読み出して（ＳＴ４１４、ＳＴ４１５、ＳＴ４０３）、障害発生回数通知パケットの送信元アドレスとの比較を行う（ＳＴ４０４）。
【００６４】
一方、ＳＴ４０４でＹＥＳの場合は、当該アドレス設定部が含まれている記憶ブロックに対応するサーバ装置１からの通報であり、制御部６１は、その記憶ブロックを選択する。
以下では、サーバ１対応情報ブロック８１０を選択したとして説明を進める。
制御部６１は、次に、受信間隔設定部８１５に格納されている受信間隔の値を通知受信間隔計測タイマ８１４にセットして、通知受信間隔計測タイマ８１４のカウントダウンとを開始させる（ＳＴ４０５）。
次に、制御部６１は、障害発生回数通知パケットのデータ部に格納されている障害発生回数を読み出し、読み出した障害発生回数を障害通報送信回数受信部８１２に格納する（ＳＴ４０６）。
そして、制御部６１は、障害通報受信カウンタ８１１からカウンタ値を読み出すとともに（ＳＴ４０７）、障害通報送信回数受信部８１２から障害発生回数を読み出して、両者を比較する（ＳＴ４０８）。
障害通報受信カウンタ８１１の内容と、障害通報送信回数受信部８１２の内容が等しければ（ＳＴ４０８でＹＥＳ）、制御部６１は処理を終了する。
一方、障害通報受信カウンタ８１１の値がＮ、障害通報送信回数受信部８１２の値がＮ＋１である場合には、不一致であり（ＳＴ４０８でＮＯ）、制御部６１は、サーバ１近隣保守センタアドレス８１７に格納されているサーバ番号１のサーバ装置１の近隣にある保守センタ７のアドレス（保守センタ装置７０のアドレス）を通知生成部６３に警告メッセージの送信先として通知する（ＳＴ４０９）。
また、制御部６１は、通信経路故障を示すメッセージを通知生成部６３に通知する（ＳＴ４１０）。
また、制御部６１は、通知生成部６３が警告メッセージを生成するにあたって他に必要なデータがあれば、そのデータを通知生成部６３に通知する（ＳＴ４１１）。
次に、通知生成部６３が警告メッセージを生成し、通知蓄積部６４に蓄積された後に、通知出力部６５が警告メッセージを送信する（ＳＴ４１２）。
警告メッセージの送信先は、ＳＴ４０９で抽出された、サーバ番号１のサーバ装置１の近隣にある保守センタ７の保守センタ装置７０である。
そして、次回の比較に備え、障害通報送信回数受信部８１２の値Ｎ＋１を障害通報受信カウンタ８１１にセットする（ＳＴ４１３）。
【００６５】
その後、通知を受けた保守センタ７では、通知の内容から障害通報経路に異常があり、サーバ番号１のサーバ装置１で障害が発生している可能性がある旨を当該サーバ装置１の管理者に伝えるとともに、障害発生通報パケットとして通報されなかった障害が何であるかを確認するため、保守員７１がサーバ設置場所に行き、ログなどを解析して、障害箇所を見極め、部品交換することで、サーバが正常状態に復旧する。
また、サーバ側ルータ５０も交換されて、システムが正常状態に戻る。
【００６６】
また、サーバ装置１で障害が発生しなかった場合でも、コールセンタ装置６のサーバ群監視情報記憶部８００内に記憶された各サーバに対応する記憶ブロック中の通知受信間隔計測タイマの内容が一定間隔でカウントダウンされる。
あるサーバ装置１から障害発生回数通知パケットを受信すると、通報通知解析部８０で解析されて、対応する記憶ブロック中の受信間隔設定部の内容が通知受信間隔計測タイマにセットされる。
通信経路に障害がない場合には、こうして各サーバ装置に対応した通知受信間隔計測タイマがカウントダウン→受信間隔設定部の内容の再セット→カウントダウン→受信間隔設定部の内容の再セットを繰り返す。
ここで、もしも、サーバ側ルータ５０に障害が発生した場合、サーバ監視部２からの障害発生回数通知パケットを受信しないため、通知受信間隔計測タイマのカウントダウンが進み、その値がゼロになる。
図１３に従って説明すると、制御部６１は、単位時間ごとに（ＳＴ２０５）に障害経路確認処理（ＳＴ５００）を行って、通知受信間隔計測タイマのカウントダウンを進め、カウンタ値がゼロになった場合に、通知生成部６３が警告メッセージを生成し、通知出力部６５が警告メッセージを送信する。
ここでは、ＳＴ２０５の単位時間を全サーバ装置で共通に１秒とし、受信間隔設定部が通知受信間隔計測タイマに設定する受信間隔を全サーバ装置で共通に１０００秒とする例で障害経路確認処理（ＳＴ５００）を説明する。
【００６７】
ＳＴ２０５により１秒ごとに経路障害確認処理（ＳＴ５００）が開始される。
経路障害確認処理（ＳＴ５００）では、制御部６１が、サーバ群監視情報記憶部８００の記憶ブロックの配置順にサーバ１有効フラグ８１８・・・８ｎ８を読み出し（図１６のＳＴ５０１、ＳＴ５０２）、フラグ有効になっている記憶ブロックの通知受信間隔計測タイマ８１４・・・８ｎ４のカウンタ値をデクリメント（−１）させ（ＳＴ５０３）、カウンタ値がゼロになっていなければ（ＳＴ５０４でＮＯ）、次の記憶ブロックの有効フラグを確認する（ＳＴ５０９、ＳＴ５１０、ＳＴ５０２）。
全ての記憶ブロックに対して処理が終了すると（ＳＴ５０９でＹＥＳ）、制御部６１は経路障害確認処理（ＳＴ５００）を終了し、次の１秒が経過するのを待つ。
一方、カウンタ値をデクリメントした結果カウンタ値がゼロになれば（障害発生回数通知パケットを受信していない時間が閾値である１０００秒を超えたら）（ＳＴ５０４でＹＥＳ）、制御部６１は、Ｓ５０５に処理を進める。
ここでは、サーバ１対応情報ブロック８１０の通知受信間隔計測タイマ８１４のカウンタ値がゼロになった場合、すなわち、サーバ番号１のサーバ装置１からの障害発生回数通知パケットを１０００秒以上受信していない場合を例にして説明する。
制御部６１は、サーバ１近隣保守センタアドレス８１７に格納されているサーバ装置１の近隣にある保守センタ７のアドレスを通知生成部６３に警告メッセージの送信先として通知する（ＳＴ５０５）。
また、制御部６１は、通信経路故障を示すメッセージを通知生成部６３に通知する（ＳＴ５０６）。
また、制御部６１は、通知生成部６３が警告メッセージを生成するにあたって他に必要なデータがあれば、そのデータを通知生成部６３に通知する（ＳＴ５０７）。
次に、通知生成部６３が警告メッセージを生成し、通知蓄積部６４に蓄積された後に、通知出力部６５が警告メッセージを送信する（ＳＴ５０８）。
警告メッセージの送信先は、ＳＴ５０５で抽出された、サーバ番号１のサーバ装置１の近隣にある保守センタ７の保守センタ装置７０である。
通知生成部６３による警告メッセージの送信及び通知出力部６５による警告メッセージの送信に並行して、制御部６１はＳＴ５０９以降の処理を進め、全ての記憶ブロックに対して処理が終了すると（ＳＴ５０９でＹＥＳ）、制御部６１は経路障害確認処理（ＳＴ５００）を終了し、次の１秒が経過するのを待つ。
【００６８】
通知出力部６５により警告メッセージが送信されると、通知を受けた保守センタ７では、通知の内容から障害通報経路に異常がある旨をサーバ装置１の管理者に伝えるとともに、通信経路の障害箇所を確認するとともに通報されなかった障害がないかを確認するため、保守員７１がサーバ設置場所に行き、サーバ側ルータ５０の障害であることを見極め、交換するとともに、サーバ装置１自体には障害はないことを確認することでシステムが正常状態に戻る。
【００６９】
以上のように、複数のサーバ装置についてサーバ装置もしくは障害発生通報経路に異常が発生した場合でも、障害の発生を検出できるとともに、場合によってはサーバ装置での障害が発生した時に障害発生通報がコールセンタに届かなくなることを未然に防ぐことが可能になるため、信頼性の高いシステムを構築することができる。
【００７０】
以上、実施の形態１〜３では、
サーバ装置の障害発生を監視するサーバ監視部に障害通報送信カウンタを設け、障害通報を受信するコールセンタ装置にはサーバ装置毎に障害通報受信カウンタを設け、サーバ装置で障害が発生したことを検出した監視部は障害発生を通報する度に障害通報送信カウンタを＋１し、コールセンタ装置側では障害通報を受信する度に障害通報受信カウンタを＋１し、
サーバ監視部は定期的に障害通報送信カウンタの内容をコールセンタ装置に送信するようにし、コールセンタ装置で、サーバ監視部から送信されてきた障害通報送信カウンタの内容と障害通報受信カウンタの内容を比較し、
コールセンタ装置で両者が一致しないことを検出した場合には、監視対象のサーバ装置とコールセンタ装置間の通信経路に障害が発生したか、設定に誤りがあることを検出でき、保守センタに通知できるので、通信経路断などの障害が発生したことを素早く検出でき、対処することができるようになり、システムの信頼性を上げることができるシステムを説明した。
【００７１】
なお、以上の説明では、サーバ装置１における障害の発生をコールセンタ装置６に通知する例を説明したが、通知する内容は障害の発生に限らない。
サーバ装置１における所定のイベントの発生を通知するイベント通知をコールセンタ装置６に送信するシステム構成において、サーバ装置１でイベント通知の送信回数を計数し、コールセンタ装置６でイベント通知の受信回数を計数し、所定の間隔でサーバ装置１がイベント通知の送信回数を通知するようにしてもよい。
また、イベント通知を送受信する装置は、サーバ装置１とコールセンタ装置６に限定されない。
【００７２】
最後に、実施の形態１〜３に示したサーバ装置１及びコールセンタ装置６のハードウェア構成例について説明する。
図１７は、実施の形態１〜３に示すサーバ装置１及びコールセンタ装置６のハードウェア資源の一例を示す図である。
なお、図１７の構成は、あくまでもサーバ装置１及びコールセンタ装置６のハードウェア構成の一例を示すものであり、サーバ装置１及びコールセンタ装置６のハードウェア構成は図１７に記載の構成に限らず、他の構成であってもよい。
【００７３】
図１７において、サーバ装置１及びコールセンタ装置６は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。
ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。
更に、ＣＰＵ９１１は、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ  Ｄｉｓｋ  Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７と接続していてもよい。また、磁気ディスク装置９２０の代わりに、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）、光ディスク装置、メモリカード（登録商標）読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。
実施の形態１〜３で説明した通知蓄積部６４又はサーバ群監視情報記憶部８００は、ＲＡＭ９１４、磁気ディスク装置９２０等により実現される。
通信ボード９１５、キーボード９０２、マウス９０３、スキャナ装置９０７、ＦＤＤ９０４などは、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは出力装置の一例である。
【００７４】
通信ボード９１５は、図１に示すように、ネットワークに接続されている。
例えば、通信ボード９１５は、ＬＡＮ（ローカルエリアネットワーク）、インターネット、ＷＡＮ（ワイドエリアネットワーク）、ＳＡＮ（ストレージエリアネットワーク）などに接続されていても構わない。
【００７５】
磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。
プログラム群９２３のプログラムは、ＣＰＵ９１１がオペレーティングシステム９２１、ウィンドウシステム９２２を利用しながら実行する。
【００７６】
また、ＲＡＭ９１４には、ＣＰＵ９１１に実行させるオペレーティングシステム９２１のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。
また、ＲＡＭ９１４には、ＣＰＵ９１１による処理に必要な各種データが格納される。
【００７７】
また、ＲＯＭ９１３には、ＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ  Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）プログラムが格納され、磁気ディスク装置９２０にはブートプログラムが格納されている。
サーバ装置１及びコールセンタ装置６の起動時には、ＲＯＭ９１３のＢＩＯＳプログラム及び磁気ディスク装置９２０のブートプログラムが実行され、ＢＩＯＳプログラム及びブートプログラムによりオペレーティングシステム９２１が起動される。
【００７８】
上記プログラム群９２３には、実施の形態１〜３の説明において「〜部」（通知蓄積部６４及びサーバ群監視情報記憶部８００以外、以下同様）として説明している機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
【００７９】
ファイル群９２４には、実施の形態１〜３の説明において、「〜の判断」、「〜の計算」、「〜の比較」、「〜の読み出し」、「〜の更新」、「〜の設定」、「〜の登録」、「〜の選択」、「〜の入力」、「〜の出力」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。
「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。
ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出される。
そして、読み出された情報やデータや信号値や変数値やパラメータは、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。
抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、実施の形態１〜３で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示す。
データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。
また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
【００８０】
また、実施の形態１〜３の説明において「〜部」として説明しているものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。
すなわち、実施の形態１〜３で説明したフローチャートに示すステップ、手順、処理により、本発明を方法の発明として把握することができる。
また、「〜部」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。
或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。
ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。
プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。
すなわち、プログラムは、実施の形態１〜３の「〜部」としてコンピュータを機能させるものである。あるいは、実施の形態１〜３の「〜部」の手順や方法をコンピュータに実行させるものである。
【００８１】
このように、実施の形態１〜３に示すサーバ装置１及びコールセンタ装置６は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータである。
そして、上記したように「〜部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。
【符号の説明】
【００８２】
１  サーバ装置、２  サーバ監視部、５  通信回線、６  コールセンタ装置、７  保守センタ、８  通報確認部、９  通信回線、２１  障害検出部、２２  通報通知作成部、２３  通報通知送信部、２４  障害通報送信カウンタ、２５  送信間隔設定部、２６  送信間隔計測タイマ、２７  要求信号、５０  サーバ側ルータ、６０  センタ側ルータ、６１  制御部、６２  通報通知受信部、６３  通知生成部、６４  通知蓄積部、６５  通知出力部、６６  通知メッセージ、７０  保守センタ装置、７１  保守員、８０  通報通知解析部、８１  障害通報受信カウンタ、８２  障害通報送信回数受信部、８３  比較部、８４  通知受信間隔計測タイマ、８５  受信間隔設定部、８００  サーバ群監視情報記憶部、８１０  サーバ１対応情報ブロック、８１１  障害通報受信カウンタ、８１２  障害通報送信回数受信部、８１４  通知受信間隔計測タイマ、８１５  受信間隔設定部、８１６  アドレス設定部、８１７  サーバ１近隣保守センタアドレス、８１８  サーバ１有効フラグ。
【図１】
2012068729.tif 000003
【図２】
2012068729.tif 000004
【図３】
2012068729.tif 000005
【図４】
2012068729.tif 000006
【図５】
2012068729.tif 000007
【図６】
2012068729.tif 000008
【図７】
2012068729.tif 000009
【図８】
2012068729.tif 000010
【図９】
2012068729.tif 000011
【図１０】
2012068729.tif 000012
【図１１】
2012068729.tif 000013
【図１２】
2012068729.tif 000014
【図１３】
2012068729.tif 000015
【図１４】
2012068729.tif 000016
【図１５】
2012068729.tif 000017
【図１６】
2012068729.tif 000018
【図１７】
2012068729.tif 000019
【図１８】
2012068729.tif 000020