JP2005202597A - 遠隔障害監視システム - Google Patents

Abstract

【課題】遠隔地にあるサーバの障害発生時に、障害原因の特定、障害対策、作業内容や費用のユーザへの通知を自動化する。
【解決手段】複数のサービスサーバ１と保守管理サーバ５とを通信回線で接続する。サービスサーバ１は、自身のハードウェア、ソフトウェアまたはファームウェアの障害を監視する手段と、障害の発生が検出されたとき、その障害の内容をエラーコード化し、そのエラーコードを前記保守管理サーバに送信する手段とを備える。保守管理サーバ５は、サービスサーバ１から通知されたエラーコードを受信する手段と、サービスサーバから送信されてくるエラーコードを元に、エラーコードに対応する障害情報を格納した障害データベース９の検索を行って障害内容及び障害内容に従った対策内容を特定する手段と、特定された対策内容に従った障害対策処理を行う手段とを備える。
【選択図】 図１

Description

本発明は、遠隔障害監視システムに係り、特に、リモートサービスサーバ等の障害に対して自動的に保守対策を行うことを可能とした遠隔障害監視システムに関する。

リモートサービスサーバ等に対する障害監視に関する従来技術として、例えば、特許文献１等に記載された技術が知られている。この従来技術は、ネットワークを介してサーバ装置の障害検知を行い、障害箇所を判断することができるものである。
特開２００２−２２９８７１号公報

しかし、前述した従来技術は、検知された障害を保守者等に知らせるだけのものであり、システムが自律的に保守を行うことができるものではなく、障害検知後の保守作業等に多くの人手を要するという問題点を有している。

本発明の目的は、前述した従来技術の問題点を解決し、遠隔地にある複数のサーバ装置の効率的な障害監視を可能とし、人手を介することなく自動的に保守を行うことができる遠隔障害監視システムを提供することにある。

本発明によれば前記目的は、１または複数のサービスサーバと保守管理サーバとを通信回線で接続し、保守管理サーバが前記サービスサーバの障害を監視する遠隔障害監視システムにおいて、前記サービスサーバが、自身のハードウェア、ソフトウェアまたはファームウェアの障害を監視する手段と、障害の発生が検出されたとき、その障害の内容をエラーコード化し、そのエラーコードを前記保守管理サーバに送信する手段とを備え、前記保守管理サーバが、前記サービスサーバから通知されたエラーコードを受信する手段と、サービスサーバから送信されてくるエラーコードを元に、エラーコードに対応する障害情報を格納した障害データベースの検索を行って障害内容及び障害内容に従った対策内容を特定する手段と、特定された対策内容に従った障害対策処理を行う手段とを備えることにより達成される。

本発明によれば、遠隔地にある複数のサーバ装置に対して効率的に障害監視を行うことが可能となり、また、保守が自動化されているので、人手による保守作業を軽減して、迅速に障害に対応することができる。

以下、本発明による遠隔障害監視システムの実施形態を図面により詳細に説明する。

図１は本発明の一実施形態による遠隔障害監視システムの構成例を示すブロック図である。図１において、１はリモートサービスサーバ、２はデータセンタ、３は顧客ユーザ、４は保守会社、５は保守管理サーバ、６は障害データベース、７は顧客データベース、８は部品管理サーバ、９はパッチデータサーバ、１０はファームウェアデータサーバ、１１は部品倉庫、１２は保守員、１３は運送会社、１４は輸送管理サーバ、１５は部品メーカー、１６は広域ネットワークである。

本発明の一実施形態による遠隔監視システムは、１または複数のサーバ、ここでは、リモートサービスサーバ１を設置しているデータセンタ２と、顧客ユーザ３と、保守会社４と、運送会社１３と、部品メーカー１５と、それらの間を接続する広域ネットワーク１６とにより構成されている。そして、データセンタ２に設置されているリモートサービスサーバ１は、広域ネットワーク１６に接続されており、自身のハードウェア、ソフトウェア、ファームウェア等のエラーを監視し、エラー発生時に対応するエラーをエラーコード化しそのエラーコードを外部に送信する機能を持つ。顧客ユーザ３は、データセンタ２に設置されているリモートサービスサーバ１を運用するユーザであり、実際には、リモートサービスサーバ１を運用するための端末装置であり、この端末装置が広域ネットワーク１６に接続されている。

保守会社４は、リモートサービスサーバ１の保守を行う会社であり、保守管理サーバ５、障害データベース６、顧客データベース７、部品管理サーバ８、パッチデータサーバ９、ファームウェアサーバ１０を備えている。保守会社４内に設置されている保守管理サーバ５は、広域ネットワーク１６に接続されていて、リモートサービスサーバ１から送信されてくるエラーコードを元に、障害データベース６を用いて障害情報の検索や送信されてくるＩＰアドレスを元に、顧客データベース７を用いて顧客情報の検索を行う。また、この保守管理サーバ５は、ハードウェア保守が必要な障害がリモートサービスサーバ１に発生した場合、部品管理サーバ８に部品の出庫依頼を行ったり、運送会社１３に保守部品の発送依頼を行う。さらに、この保守管理サーバ５は、ソフトウェア保守やファームウェア保守が必要な障害の場合、パッチデータサーバ９やファームウェアデータサーバ１０から必要なデータを受け取って、リモートサービスサーバ１に対する自動アップデート等を行う。

障害データベース６は、リモートサービスサーバ１から送信されるエラーコードに対する障害原因、適した保守対策、保守対策に必要な部品のパーツ番号、施した保守の金額等を保持するデータベースであり、前述したように、保守管理サーバ５から検索される。顧客データベース７は、リモートサービスサーバ１からエラーコードと共に送られるＩＰアドレスと、そのＩＰアドレスに対応する障害が起こったリモートサービスサーバ名、サーバを運用している顧客の住所、電話番号、Ｅメールアドレス等を保持するデータベースであり、前述したように、保守管理サーバ５から検索される。

部品管理サーバ８は、広域ネットワーク１６に接続されていて、部品倉庫１１に保存している保守部品の在庫を管理しており、リモートサービスサーバの障害により部品交換が必要になった場合、保守管理サーバ５から部品出庫を依頼され、出庫処理を行う。また、部品管理サーバ８は、保守部品の出庫後、部品の在庫数量を自動的に更新し、在庫部品数が一定数を下回った場合、部品メーカー１５に発注を行う。パッチデータサーバ９は、保守管理サーバ５から通知されてくるソフトウェア障害に対するパッチデータ番号のデータを保守管理サーバ５に提供するファイルサーバである。ファームウェアデータサーバ１０は、保守管理サーバ５から通知されてくるファームウェア障害に対するファームウェアデータ番号のデータを保守管理サーバ５に提供するファイルサーバである。

部品倉庫１１は、保守会社４の管理下にある倉庫であり、部品管理サーバ８が部品メーカー１５に発注した部品を納める場所である。また、部品倉庫１１は、運送会社１３が輸送する保守部品を受け取る場所である。運送会社１３は、保守部品を輸送する会社であり、輸送管理サーバ１４が設置されている。この輸送管理サーバ１４は、広域ネットワーク１６に接続されていて、保守管理サーバ５から保守部品の輸送依頼を受け、また、保守管理サーバ５に、データセンタ２への保守部品の到着日時を通知する。保守部品メーカー１５は、部品管理サーバから保守部品の注文を受け、その部品を部品倉庫１１に発送する。保守部品メーカー１５には、図示しない注文端末が設置され、この注文端末が広域ネットワーク１６に接続されている。保守員１２は、リモートサービスサーバ１に現地での保守が必要な障害が発生した場合に、データセンタ２に出向いて保守を行う保守会社の保守員であり、保守管理サーバ５との通信を行うための端末装置を所持している。

図２はリモートサービスサーバの構成を示すブロック図であり、次に、これについて説明する。図２において、１０２は専用コントローラ、１０３はマネージメントコントローラ、１０４は通信コントローラ、１０５はＣＰＵ、１０６はＦＡＮ、１０７はマネージメントバス、１０８はファームウェア（Ｆ／Ｗ）、１０６はドライバ、１１０はＯＳ、１１１はアプリケーション、１１２は電源ＯＮ／ＯＦＦ、Ｒｅｓｅｔコネクタ、１１３は通信回線であり、他の符号は図１の場合と同一である。

リモートサービスサーバ１は、図２に示すように、自サーバ内の状態監視を行うマネージメントコントローラ１０３及びリモートサービスサーバ１にエラーが生じ、マネージメントコントローラ１０３がエラーを検知した場合に、外部に設置される保守管理サーバ５に広域ネットワーク１６を介する通信回線１１３を経てエラーを送信する通信コントローラ１０４を持つ専用コントローラ１０２と、リモートサービスサーバ１の各種の処理を行い、また、マネージメントコントローラ１０３からマネージメントバス１０７を通じて、その温度や電圧値の確認が行われるＣＰＵ１０５と、冷却用のファンであって、マネージメントコントローラ１０３からマネージメントバス１０７を通じて、回転数等の確認が行われるＦＡＮ１０６と、マネージメントコントローラ１０３とＣＰＵ１０、ＦＡＮ１０６とを接続し、ＣＰＵ１０５の温度、電圧値やＦＡＮ１０６の回転数などの情報の送受信を行うマネージメントバス１０７と、マネージメントコントローラ１０３に自身の障害を示すエラーを通知することもがきるファームウェア１０８と、マネージメントコントローラ１０３に対するドライバであり、ＯＳやアプリケーションで生じたエラーを検知することができるドライバ１０９と、リモートサービスサーバ１にインストールされているオペレーティングシステム（ＯＳ）１１０と、顧客ユーザが運用しているアプリケーション１１１と、保守管理サーバ５から通信回線１１３を通じて遠隔電源操作が可能なマザーボード上にある電源ＯＮ／ＯＦＦ、Ｒｅｓｅｔコネクタ１１２とを備えて構成されている。

図３は前述したように構成されたリモートサービスサーバ１に障害が生じたときに送信されるパケットデータのフォーマット構成を示す図であり、次に、これについて説明する。

リモートサービスサーバ１から広域ネットワーク１６を介して保守管理サーバに送信されるパケットデータ２０３は、リモートサービスサーバ１で検出された障害のエラーコード２０１と、障害が発生したリモートサービスサーバのＩＰアドレス２０２により構成される。

図４は保守会社４に備えられる障害データベース６の登録内容を説明する図、図５は保守会社４の部品管理サーバに登録された情報の内容を説明する図、図６は保守会社４に備えられる顧客データベース７の登録内容を説明する図であり、次に、これらについて説明する。

障害データベース６には、図４に示すように、エラーコード３０１と、区分セル３０２と、障害原因セル３０３と、障害対策セル３０４と、交換要否セル３０５と、部品パーツ番号セル３０６と、金額セル３０７とを１つのレコードとして、複数のレコードが格納される。区分セル３０２には、エラーコードの区分が登録される。この区分は、ハードウェア障害の場合、“Ｈ／Ｗ”、ソフトウェア障害の場合、“Ｓ／Ｗ”、ファームウェア障害の場合、“Ｆ／Ｗ”として表されて格納される。障害原因セル３０３には、エラーコードに対応させられた障害原因が格納され、障害データベースの検索で得ることができる障害原因が格納される。この障害原因は、図４に示すように、ＦＡＮ異常、ＯＳバグ等として具体的に記述される。障害対策セル３０４には、障害原因３０３に適した障害対策の内容が格納される。交換要否セル３０５は、障害対策の内容で部品交換等の要否であり、“ＹＥＳ”か“ＮＯ”で記述される。そして、このセルは、ハードウェア障害の場合、部品交換の要否の項目であり、ソフトウェア障害の場合、ソフトウェアのアップデートの要否の項目であり、ファームウェア障害の場合、ファームウェアデータの要否の項目である。パーツ番号セル３０６には、交換が必要な部品のパーツ番号が登録される。パーツ番号は、ハードウェア障害の場合、保守が必要な部品番号であり、ソフトウェア障害の場合、ソフトウェアのパッチデータ番号であり、ファームウェア障害の場合、ファームウェアデータ番号である。金額セル３０８には、対応した保守の金額が登録される。なお、レコード３０８は、後述するハードウェア障害が発生した場合の説明で使用する障害情報の例である。

保守会社４の部品管理サーバ８に登録される情報は、図５に示すように、部品パーツ番号セル４０１と、部品名セル４０２と、員数セル４０３と、しきい値セル４０４とが１つのレコードとして構成され、複数のレコードが部品管理サーバ８に登録されている。パーツ番号セル４０１は、保守管理の対象となる部品番号としてのパーツ番号であり、部品名セル４０２には、パーツ番号に対応した部品名が登録される。員数セル４０３には、部品倉庫１１に保管されている保守部品の員数が登録される。この員数セル４０３の値は、部品管理サーバ８の指示により、保守部品が出庫されるとその値が差し引かれる。しきい値セル４０４には、部品管理サーバ８が部品倉庫１１に保管されている保守部品の在庫数を管理するために必要なしきい値が登録されており、保守部品の員数セル４０３の値が、しきい値セル４０４の値よりも下回ると、部品管理サーバ８が、部品メーカー１５に不足分を発注する。なお、レコード４０５は、後述のハードウェア障害が発生した場合の説明で使用する保守部品の情報の例である。

顧客データベース７には、図６に示すように、顧客が運用しているリモートサービスサーバのＩＰアドレス５０１と、リモートサービスサーバ名５０２と、顧客ユーザの住所、氏名５０３と、顧客ユーザの電話番号５０４と、顧客ユーザのＥメールアドレス５０５とを１つのレコードとして構成し、複数のレコードが登録されている。なお、レコード５０６は、後述のハードウェア障害が発生した場合の説明で使用する顧客情報の例である。

図７はリモートサービスサーバに障害が発生した場合に、保守管理サーバが障害原因を判定するまでの保守管理サーバの処理動作を説明するフローチャートであり、次に、これについて説明する。

（１）リモートサービスサーバ１に障害が発生すると、そのリモートサービスサーバ１は、障害内容を示すエラーコード２０１と自リモートサービスサーバのＩＰアドレス２０２を含むＩＰパケット２０３を生成し、このＩＰパケット２０３を広域ネットワーク１６を介して保守管理サーバ５に送信する（ステップＳ７０１、Ｓ７０２）。

（２）保守会社４に設置されている保守管理サーバ５は、リモートサービスサーバ１からのパケット２０３を受信し、受信したパケット２０３のエラーコード２０１を使用して障害データベース６を検索、確認する。この検索、確認の処理により、保守管理サーバ５は、例えば、区分セル３０２が“Ｈ／Ｗ”、障害原因セル３０３が“ＦＡＮ不良”、障害対策セル３０４“ＦＡＮ交換”、交換要否セル３０５が“ＹＥＳ”、部品パーツ番号セル３０６が“０００−００１”、保守金額セル３０７が“￥１０，０００”を示していることを確認することができる（ステップＳ７０３）。

（３）ステップＳ７０３での障害データベース６の検索結果により、保守管理サーバ５は、区分セル３０２の内容が、“Ｈ／Ｗ”、“Ｓ／Ｗ”、“Ｆ／Ｗ”、“不明”の何れであるかを判定する（ステップＳ７０４）。

図８ａ〜図８ｃは図７に示すフローでのステップＳ７０４の判定処理で、区分セル３０２の内容が“Ｈ／Ｗ”であった場合の処理動作を説明するフローチャートであり、次に、これについて説明する。

（１）保守管理サーバ５は、区分セル３０２の内容が“Ｈ／Ｗ”であることを確認の後、交換要否セル３０５の内容を確認し、交換要か否かを判定する。交換が不要である場合、保守等の必要がないとして、ここでの処理を終了する（ステップＳ８０１、Ｓ８０２）。

（２）ステップＳ８０２の判定で、交換要否セル３０５の内容が“ＹＥＳ”であった場合、保守管理サーバ５は、ステップ７０３の処理で得られたパーツ番号セル３０６の内容“０００−００１”を部品管理サーバ８に送信し、部品出庫依頼を行う（ステップＳ８０３）。

（３）部品管理サーバ８は、受け取った部品パーツ番号セル３０６の内容をもとに部品情報を検索し、部品名セル４０２から交換する部品が“筐体ＦＡＮ”であり、員数セル４０３の値が“１０”、しきい値セル４０４の値が“１０”であることを確認する（ステップＳ８０４）。

（４）部品管理サーバ８は、交換部品である“筐体ＦＡＮ”に対する出庫処理を行い、員数セル４０３の値から出庫したＦＡＮの個数“１”を差し引き、差し引いた値“９”を員数セル４０３に登録する（ステップＳ８０５）。

（５）次に、部品管理サーバ８は、員数セル４０３の値“９”としきい値セル４０４の値“１０”との比較を行い、員数セル４０３の値がしきい値セル４０４の値を下回ったか否かを判定する（ステップＳ８０６）。

（６）ステップＳ８０６の判定で、員数セル４０３の値がしきい値セル４０４の値を下回っていた場合、部品管理サーバ８は、部品メーカー１５に、その部品の一定数を注文する（ステップＳ８０７）。

（７）部品メーカー１５が保守会社４の部品倉庫１１に発注した部品を届けると、部品管理サーバは、員数セル４０３に入庫した部品の数を加える。なお、ここでの処理は、注文した部品の輸送を伴うため、時間的に遅れて行われる（ステップＳ８０８、Ｓ８０９）。

（８）ステップＳ８０６の判定で、員数セル４０３の値がしきい値セル４０４の値を下回っていなかった場合、または、ステップＳ８０７の処理が行われた後、保守管理サーバ５は、運送会社１３に設置されている輸送管理サーバ１４に部品のデータセンタ２への輸送依頼を送信する。輸送依頼を受けた運送会社１３に設置されている輸送管理サーバ１４は、保守管理サーバ５に部品到着日時を通知する（ステップＳ８１０）。

（９）次に、保守管理サーバ５は、障害発生時にリモートサービスサーバ１から送られたパケット２０３のリモートサービスサーバのＩＰアドレス２０２をもとに顧客データベース７を検索し、サーバ名５０２が“リモートサービスサーバ１”、顧客住所、氏名５０３が“愛知県豊川市”、“ＹＹ ＺＺ”、顧客の電話番号５０４が“ＸＸ-ＸＸＸＸ”、顧客Ｅメールアドレス５０５が“ＸＸＸ＠ebina.hitachi.co.jp”であることを取得、確認する（ステップＳ８１１）。

（10）保守管理サーバ５は、輸送管理サーバ１４から受け取った部品到着日時をデータセンタ２に通知する。また、保守管理サーバ５は、保守員１２にサーバ名５０２と部品到着時刻とを通知する（ステップＳ８１２）。

（11）運送会社１３は、部品倉庫１１からＦＡＮを受け取り、予定した部品到着日時までにＦＡＮをデータセンタ２に輸送する（ステップＳ８１３）。

（12）一方、保守員１２は、データセンタ２に出動して、障害の発生した部品、ここでの説明ではＦＡＮの交換を行う（ステップＳ８１４）。

（13）保守員による保守作業の完了後、保守管理サーバ５は、顧客のＥメールアドレス宛に、リモートサービスサーバに障害が発生したこと、原因がＦＡＮ異常であること、障害対策のためにＦＡＮ交換を行ったこと、保守金額が￥１０，０００であることを通知する（ステップＳ８１５）。

（14）その後、保守会社４は、顧客ユーザ３へ保守請求書を送付し、顧客ユーザ３は、保守会社４へ請求金額を支払う（ステップＳ８１６、Ｓ８１７）。

図９は図７に示すフローでのステップＳ７０４の判定処理で、区分セル３０２の内容が“Ｓ／Ｗ”であった場合の処理動作を説明するフローチャートであり、次に、これについて説明する。

（１）保守管理サーバ５は、区分セル３０２の内容が“Ｓ／Ｗ”であることを確認の後、交換要否セル３０５の内容を確認し、ソフトウェアアップデートの要否を判定する。アップデートが不要である場合、保守等の必要がないとして、ここでの処理を終了する（ステップＳ９０１、Ｓ９０２）。

（２）ステップＳ９０２の判定で、交換要否セル３０５の内容が“ＹＥＳ”であった場合、保守管理サーバ５は、ステップ７０３の処理で得られたパーツ番号セル３０６の内容を確認し、アップデートすべきパッチデータＮｏを確認し、そのパッチデータＮｏをパッチデータサーバ９に送信する（ステップＳ９０３）。

（３）パッチデータＮｏを受け取ったパッチデータサーバ９は、該当するパッチデータを保守管理サーバ５に送信する（ステップＳ９０４）。

（４）保守管理サーバ５は、障害が発生したリモートサービスサーバへ、パッチデータサーバ９から受け取ったパッチデータを送信して、ソフトウェアのアップデートを行う（ステップＳ９０５）。

（５）次に、保守管理サーバ５は、障害発生時にリモートサービスサーバ１から送られたパケット２０３のリモートサービスサーバのＩＰアドレス２０２をもとに顧客データベース７を検索し、顧客Ｅメールアドレスを取得して、顧客のＥメールアドレス宛に、リモートサービスサーバに障害が発生したこと、原因がＳ／Ｗ異常であること、障害対策のためにソフトウェアのアップデートを行ったことを通知する（ステップＳ９０６、Ｓ９０７）。

（６）図９に示すフローには示していないが、保守管理サーバ５は、前述の保守に対する費用を課金し、保守会社４は、月末に請求書を発行して費用の請求を行う。この費用の課金は、例えば、リモートサービスサーバに対する保守契約で月毎の保守費用だけでよい場合、行う必要はない。

図１０は図７に示すフローでのステップＳ７０４の判定処理で、区分セル３０２の内容が“Ｆ／Ｗ”であった場合の処理動作を説明するフローチャートであり、次に、これについて説明する。

（１）保守管理サーバ５は、区分セル３０２の内容が“Ｆ／Ｗ”であることを確認の後、交換要否セル３０５の内容を確認し、ファームウェアアップデートの要否を判定する。アップデートが不要である場合、保守等の必要がないとして、ここでの処理を終了する（ステップＳＡ０１、ＳＡ０２）。

（２）ステップＳＡ０２の判定で、交換要否セル３０５の内容が“ＹＥＳ”であった場合、保守管理サーバ５は、ステップ７０３の処理で得られたパーツ番号セル３０６の内容を確認し、アップデートすべきファームウェアＮｏを確認し、そのファームウェアＮｏをファームウェアデータサーバ１０に送信する（ステップＳＡ０３）。

（３）ファームウェアＮｏを受け取ったファームウェアデータサーバ１０は、該当するファームウェアを保守管理サーバ５に送信する（ステップＳＡ０４）。

（４）保守管理サーバ５は、障害が発生したリモートサービスサーバへ、ファームウェアデータサーバ１０から受け取ったファームウェアを送信して、ファームウェアのアップデートを行う（ステップＳＡ０５）。

（５）次に、保守管理サーバ５は、障害発生時にリモートサービスサーバ１から送られたパケット２０３のリモートサービスサーバのＩＰアドレス２０２をもとに顧客データベース７を検索し、顧客Ｅメールアドレスを取得して、顧客のＥメールアドレス宛に、リモートサービスサーバに障害が発生したこと、原因がＦ／Ｗ異常であること、障害対策のためにファームウェアのアップデートを行ったことを通知する（ステップＳＡ０６、ＳＡ０７）。

（６）図１０に示すフローには示していないが、保守管理サーバ５は、前述の保守に対する費用を課金し、保守会社４は、月末に請求書を発行して費用の請求を行う。この費用の課金は、例えば、リモートサービスサーバに対する保守契約で月毎の保守費用だけでよい場合、行う必要はない。

図１１は図７に示すフローでのステップＳ７０４の判定処理で、区分セル３０２の内容から障害が特定することができなかった場合の処理動作を説明するフローチャートであり、次に、これについて説明する。

（１）この処理が開始されると、保守管理サーバ５は、障害発生時にリモートサービスサーバ１から送られたパケット２０３のリモートサービスサーバのＩＰアドレス２０２をもとに顧客データベース７を検索し、サーバ名５０２、顧客住所、氏名５０３、顧客の電話番号５０４、顧客Ｅメールアドレス５０５を取得、確認する（ステップＳＢ０１）。

（２）次に、保守管理サーバ５は、保守員１２に対して、リモートサービスサーバに原因不明の障害が発生したことを通知すると共に、そのサーバ名を通知する（ステップＳＢ０２）。

（３）ステップＳＢ０２での通知を受けた保守員１２は、データセンタ２に行き、障害が発生しているリモートサービスサーバの障害原因の調査を行うと共に、障害対策を行う（ステップＳＢ０３）。

（４）障害対策を行った保守員１２は、調査結果と対策とに従って、障害データベース６に、エラーコード３０１、区分セル３０２、障害原因セル３０３、障害対策セル３０４、交換要否セル３０５、部品パーツ番号セル３０６、金額セル３０７によるレコードを追加登録する（ステップステップＳＢ０４）。

（５）保守管理サーバ５は、保守員１２による障害データベースへの登録に基づいて、顧客のＥメールアドレス宛に、リモートサービスサーバに障害が発生したこと、障害原因、障害対策の内容保守に要した金額を通知する（ステップＳＢ０５）。

（６）その後、保守会社４は、顧客ユーザ３へ保守費用の請求書を送付し、顧客ユーザ３は、保守会社４へ請求金額を支払う（ステップＳＢ０６、ＳＢ０７）。

前述で説明した本発明の実施形態による各処理における保守費用の請求は、保守管理サーバ５が請求書を作成し、それを印刷して保守会社の係員が送付の処理を行ってもよく、また、保守管理サーバ５が請求書を作成してメールにより送付するようにしてもよい。

前述した本発明の実施形態における各処理は、処理プログラムとして構成することができ、この処理プログラムは、ＨＤ、ＤＡＴ、ＦＤ、ＭＯ、ＤＶＤ−ＲＯＭ、ＣＤ−ＲＯＭ等の記録媒体に格納して提供することができ、また、インターネットを含む公衆通信網等の通信回線を介して提供することもできる。

前述した本発明の実施形態によれば、障害原因となった交換部品の輸送依頼を自動的に行うことができ、障害原因となったソフトウェアのバグ、ファームウェアのエラーに対するソフトウェアパッチやファームウェアデータのアップデートを自動的に行うことができ、さらに、ユーザに障害原因、対策内容、費用等を通知することができる。これにより、本発明の実施形態は、保守の自動化を行うことができ、障害に対して迅速に対応することができる。

また、本発明の実施形態によれば、保守作業の準備作業、例えば、保守部品の出庫作業、障害が発生したサーバの設置場所まで保守部品の発送を行う作業を自動化することができ、人件費の削減を図ることができる。

本発明の一実施形態による遠隔障害監視システムの構成例を示すブロック図である。 リモートサービスサーバの構成を示すブロック図である。 リモートサービスサーバ１に障害が生じたときに送信されるパケットデータのフォーマット構成を示す図である。 保守会社に備えられる障害データベースの登録内容を説明する図である。 保守会社の部品管理サーバに登録された情報の内容を説明する図である。 保守会社４に備えられる顧客データベースの登録内容を説明する図である。 リモートサービスサーバに障害が発生した場合に、保守管理サーバが障害原因を判定するまでの保守管理サーバの処理動作を説明するフローチャートである。 図７に示すフローでのステップＳ７０４の判定処理で、区分セルの内容が“Ｈ／Ｗ”であった場合の処理動作を説明するフローチャート（その１）である。 図７に示すフローでのステップＳ７０４の判定処理で、区分セルの内容が“Ｈ／Ｗ”であった場合の処理動作を説明するフローチャート（その２）である。 図７に示すフローでのステップＳ７０４の判定処理で、区分セルの内容が“Ｈ／Ｗ”であった場合の処理動作を説明するフローチャート（その３）である。 図７に示すフローでのステップＳ７０４の判定処理で、区分セルの内容が“Ｓ／Ｗ”であった場合の処理動作を説明するフローチャートである。 図７に示すフローでのステップＳ７０４の判定処理で、区分セルの内容が“Ｆ／Ｗ”であった場合の処理動作を説明するフローチャートである。 図７に示すフローでのステップＳ７０４の判定処理で、区分セルの内容から障害が特定することができなかった場合の処理動作を説明するフローチャートである。

符号の説明

１ リモートサービスサーバ
２ データセンタ
３ 顧客ユーザ
４ 保守会社
５ 保守管理サーバ
６ 障害データベース
７ 顧客データベース
８ 部品管理サーバ
９ パッチデータサーバ
１０ ファームウェアデータサーバ
１１ 部品倉庫
１２ 保守員
１３ 運送会社
１４ 輸送管理サーバ
１５ 部品メーカー
１６ 広域ネットワーク
１０２ 専用コントローラ
１０３ マネージメントコントローラ
１０４ 通信コントローラ
１０５ ＣＰＵ
１０６ ＦＡＮ
１０７ マネージメントバス
１０８ ファームウェア（Ｆ／Ｗ）
１０６ ドライバ
１１０ ＯＳ
１１１ アプリケーション
１１２ 電源ＯＮ／ＯＦＦ、Ｒｅｓｅｔコネクタ
１１３ 通信回線

Claims (5)

1. １または複数のサービスサーバと保守管理サーバとを通信回線で接続し、保守管理サーバが前記サービスサーバの障害を監視する遠隔障害監視システムにおいて、前記サービスサーバは、自身のハードウェア、ソフトウェアまたはファームウェアの障害を監視する手段と、障害の発生が検出されたとき、その障害の内容をエラーコード化し、そのエラーコードを前記保守管理サーバに送信する手段とを備え、前記保守管理サーバは、前記サービスサーバから通知されたエラーコードを受信する手段と、サービスサーバから送信されてくるエラーコードを元に、エラーコードに対応する障害情報を格納した障害データベースの検索を行って障害内容及び障害内容に従った対策内容を特定する手段と、特定された対策内容に従った障害対策処理を行う手段とを備えることを特徴とする遠隔障害監視システム。
2. 特定された障害内容がハードウェアの障害であった場合の前記障害対策処理は、保守管理サーバが保守員の持つ端末装置へのハードウェア交換作業の通知を行う処理及び運送会社が所持する輸送管理サーバへハードウェア部品のサービスサーバ設置場所への輸送依頼を行う処理であることを特徴とする請求項１記載の遠隔障害監視システム。
3. 特定された障害内容がソフトウェアの障害であった場合の前記障害対策処理は、保守管理サーバがパッチデータサーバから得たパッチデータを前記サービスサーバに送付して、サービスサーバのソフトウェアをアップデートする処理であることを特徴とする請求項１記載の遠隔障害監視システム。
4. 特定された障害内容がファームウェアの障害であった場合の前記障害対策処理は、保守管理サーバがファームウェアデータサーバから得たファームウェアを前記サービスサーバに送付して、サービスサーバのファームウェアをアップデートする処理であることを特徴とする請求項１記載の遠隔障害監視システム。
5. 前記保守管理サーバは、前記障害対策処理の終了後、前記サービスサーバを管理するユーザの端末装置に障害原因、対策内容、費用を通知することを特徴とする請求項２、３または４記載の遠隔障害監視システム。
   

Images