(57)【要約】【課題】マルチベンダシステムの保守サービスや保守支援に関するシステム管理者の手間を削減する。【解決手段】マルチベンダシステム１にマルチベンダシステム監視通報サーバ４を接続し、マルチベンダシステム監視通報サーバ４はマルチベンダシステム１を構成する各機器から送出される複数の異なった障害通報インターフェイスを入力して認識し、障害発生をシステム管理者装置２とプライマリ保守者端末５と各メーカー／ベンダ／保守会社システム７に自動通報する。プライマリ保守者端末５は障害の経過情報と完了情報等を作成し、マルチベンダシステム監視通報サーバ４から電子メール通報を行う。プライマリ保守者は第１次保守者として障害情報収集、障害対応処理、及び障害管理を一括し、システム運用と管理情報の提示と各ベンダ間の工程管理協議調整を行う。【選択図】      図１
2004164389.tif 000002
【特許請求の範囲】
【請求項１】
マルチベンダシステムの保守サービスを行う保守サービス方式であって、
複数のベンダから納入された各種の機器から構成され情報処理を行うマルチベンダシステムと、
前記マルチベンダシステムと接続し前記マルチベンダシステムの障害を検出し障害情報を通報するマルチベンダシステム監視通報サーバと、
プライマリ保守者が管理操作し前記マルチベンダシステム監視通報サーバから通報された障害情報を受信し前記障害に関連する保守会社システムに障害解決処理の指示を行い前記障害の発生状況および解決状況に関する報告文書を作成して発信するプライマリ保守者端末と、
前記マルチベンダシステム監視通報サーバから通報された障害情報を受信し前記マルチベンダシステムを構成する機器の保守を行う保守会社システムと、
を備えることを特徴とする保守サービス方式。
【請求項２】
前記マルチベンダシステム監視通報サーバは、前記各種の機器が出力する障害自動通報メッセージあるいは自動通報信号を入力して障害メッセージに変換するインターフェイス変換装置と、ＲＳ送信要求信号を感知して前記インターフェイス変換装置に送出するＲＳ信号感知部と、前記障害メッセージを通報する障害自動通報装置と、障害メールサーバと、を有することを特徴とする請求項１記載の保守サービス方式。
【請求項３】
前記各種の機器が、サーバ機器とクライアント機器と付帯設備機器から成ることを特徴とする請求項２記載の保守サービス方式。
【請求項４】
前記サーバ機器はＳＶＰ（サービスプロセッサ）を備え、前記ＳＶＰは障害を検出しモデム経由で前記インターフェイス変換装置と前記保守会社システムに通知する手段を有することを特徴とする請求項３記載の保守サービス方式。
【請求項５】
前記サーバ機器はＳＶＰを備え、前記ＳＶＰとモデム間のインターフェイスケーブルであるＤＴＥケーブルを前記ＲＳ信号感知部を中継して接続する構成を成し、前記ＳＶＰは障害を検出して前記モデム経由で前記保守会社システムに通知する手段を有し、前記ＤＴＥケーブルに送出した前記モデムへのＤＴＥインターフェイス信号のうちＲＳ送信要求信号を前記ＲＳ信号感知部を経由して前記インターフェイス変換装置が感知して障害発生を認知することを特徴とする請求項３記載の保守サービス方式。
【請求項６】
前記サーバ機器は、オペレーティングシステムが障害を検出しモデム経由で前記インターフェイス変換装置と前記保守会社システムに通知する手段を有することを特徴とする請求項３記載の保守サービス方式。
【請求項７】
前記サーバ機器は、前記サーバ機器とモデム間のインターフェイスケーブルであるＤＴＥケーブルを前記ＲＳ信号感知部を中継して接続する構成を成し、前記サーバ機器は障害を検出して前記モデム経由で前記保守会社システムに通知する手段を有し、前記ＤＴＥケーブルに送出した前記モデムへのＤＴＥインターフェイス信号のうちＲＳ送信要求信号を前記ＲＳ信号感知部を経由して前記インターフェイス変換装置が感知して障害発生を認知することを特徴とする請求項３記載の保守サービス方式。
【請求項８】
前記サーバ機器は、障害を検出しＲＳ２３２Ｃシリアルインターフェイス信号により前記インターフェイス変換装置にメッセージ通知する手段を有することを特徴とする請求項３記載の保守サービス方式。
【請求項９】
前記付帯設備は、障害検出時にＲＳ２３２Ｃシリアルインターフェイス信号により前記インターフェイス変換装置にメッセージ通知する手段を有することを特徴とする請求項３記載の保守サービス方式。
【請求項１０】
前記付帯設備は、障害時に接点を閉じ正常時は接点を開放する接点信号により前記インターフェイス変換装置に通知する手段を有することを特徴とする請求項３記載の保守サービス方式。
【請求項１１】
前記インターフェイス変換装置は、前記信号を感知して前記信号に対応する障害メッセージ変換・付加を行う手段を有することを特徴とする請求項５，７，８，９または１０記載の保守サービス方式。
【請求項１２】
システム管理者が前記マルチベンダシステムを管理するためにシステムコンソールと運用監視サーバとメールサーバとを含むシステム管理者装置を備えることを特徴とする請求項１記載の保守サービス方式。
【請求項１３】
前記システムコンソールと前記運用監視サーバは、前記前記システムコンソールと前記運用監視サーバが受信したメッセージの中から障害用語を含むメッセージを検出し前記プライマリ保守者端末に伝達する手段を有することを特徴とする請求項１２記載の保守サービス方式。
【請求項１４】
複数のベンダから納入された各種の機器から構成され情報処理を行うマルチベンダシステムの保守サービスを行う保守サービス方法であって、
マルチベンダシステム監視通報サーバは、
前記マルチベンダシステムを監視して障害を検出し、
障害情報をプライマリ保守者端末と保守会社システムに通報し、
前記プライマリ保守者端末は、
前記マルチベンダシステム監視通報サーバから通報された障害情報を受信し、
障害分析および障害処理を行い、
前記障害に関連する保守会社システムに障害解決処理の指示を行い、
障害の発生状況に関する報告文書を作成してシステム管理者装置とエンドユーザクライアントと保守会社システムに発信し、
保守会社システムは、
前記マルチベンダシステム監視通報サーバから通報された障害情報を受信し、
前記プライマリ保守者端末から障害解決処理の指示を受け、
前記マルチベンダシステムを構成する障害機器の保守を行い、
障害処理状況を前記プライマリ保守者端末に報告し、
前記プライマリ保守者端末は、
障害の解決状況に関する報告文書を作成してシステム管理者装置とエンドユーザクライアントと保守会社システムに発信する、
ことを特徴とする保守サービス方法。
【請求項１５】
プライマリ保守者は前記プライマリ保守者端末を使用して定期点検のための運用停止情報，各機器の現在状態情報，システム運用関係情報，システム管理関係の報告情報ならびに点検および工事作業の工程情報を作成し、前記マルチベンダシステム監視通報サーバを経由して電子メール発信、あるいは前記マルチベンダシステム監視通報サーバ上にウェブ掲載することを特徴とする請求項１４記載の保守サービス方法。
【請求項１６】
プライマリ保守者は、前記障害処理が完了したら、前記プライマリ保守者端末を使用してテストランジョブをリモート起動して実行し、障害の完了を確認し、運用業務再開の操作をすることを特徴とする請求項１４記載の保守サービス方法。
【請求項１７】
前記障害処理は、プライマリ保守者が全てを行うことを特徴とする請求項１４記載の保守サービス方法。
【請求項１８】
前記障害処理は、マルチベンダシステムの全体を把握したプライマリ保守者の主導にて行い、プライマリ保守者とセカンダリ以降の保守者が分担して行うことを特徴とする請求項１４記載の保守サービス方法。
【請求項１９】
前記障害処理は、プライマリ保守者がシステム管理者とエンドユーザへの窓口処理を行い、プライマリ保守者が前記障害処理をセカンダリ以降の保守者に渡し前記セカンダリ以降の保守者が行うことを特徴とする請求項１４記載の保守サービス方法。
【請求項２０】
前記障害処理は、
プライマリ保守者が、
障害発生したシステムサーバ機器の業務内容と障害事象内容により、
運用続行優先の場合は、再立ち上げ操作を行い、再立ち上げが成功して運用業務が続行した場合は、間欠障害とみなして業務を続行し、その障害の原因を究明し故障・不良に対する調査・処置のためのマシンタイムを確保して運用停止の条件が整ったときに運用を停止し、再立ち上げ操作にて障害が回復しなかった場合あるいは再立ち上げしても短時間に障害が再発する場合は間欠障害ではなく固定障害であるとみなして障害処理を行うために運用停止操作をし、
運用続行優先でない場合は、障害発生の原因を究明し処置を優先してシステムサーバ機器を停止し、
障害エラーログを収集し、
アサインした技術支援部門の技術者あるいはプライマリ保守者自身によりエラーログ解析を行い、
エラーログ解析にて故障個所が判明した場合には故障部品を手配し、故障個所が判明しなかった場合には障害事象やエラーログなどにより故障の原因と予測される部品を確定し確定した部品を手配し、
運搬された部品を受け取り、
故障部品あるいは故障予測部品を交換し、
障害処理状況や復旧見込みの障害処理情報をシステム管理者とエンドユーザに報告する、
ことであることを特徴とする請求項１７記載の保守サービス方法。
【請求項２１】
前記障害処理は、
プライマリ保守者が、
システムサーバ機器の運用に関係する操作である再立ち上げ操作と運用停止操作と調査マシンタイム確保停止とエラーログの収集を行い、
セカンダリ以降の保守者が、
エラーログを解析し、
故障部品を特定し、
前記部品を手配し、
前記部品を運搬し、
前記部品交換を行い、
前記プライマリ保守者に障害処理状況を報告し、
プライマリ保守者が、
前記セカンダリ以降の保守者から経過報告を受け、
プライマリ保守者の状況判断を加えて障害処理状況や復旧見込みの障害処理情報をシステム管理者とエンドユーザに報告する、
ことであることを特徴とする請求項１８記載の保守サービス方法。
【請求項２２】
前記障害処理は、
セカンダリ以降の保守者が、
再立ち上げ操作を行い、
運用停止を操作を行い、
エラーログを収集し、
エラーログを解析し、
故障部品を特定し、
前記部品を手配し、
前記部品を運搬し、
前記部品交換を行い、
前記プライマリ保守者に障害処理状況を報告し、
プライマリ保守者が、
前記セカンダリ以降の保守者から経過報告を受け、
プライマリ保守者の状況判断を加えて障害処理状況や復旧見込みの障害処理情報をシステム管理者とエンドユーザに報告する、
ことであることを特徴とする請求項１９記載の保守サービス方法。
【請求項２３】
ソフトウェア障害については、
障害ダンプデータ収集を行い、
前記ダンプデータ解析を行い、
ソフトウェア障害に対するパッチ修正物件の作成を依頼し、
前記パッチ修正物件を入手し、
前記パッチ修正物件を適用する、
ことを特徴とする請求項２０，２１または２２記載の保守サービス方法。
【請求項２４】
複数のベンダから納入された各種の機器から構成され情報処理を行うマルチベンダシステムの保守サービスを行う保守サービスプログラムであって、
コンピュータに、
マルチベンダシステム監視通報サーバが、
前記マルチベンダシステムを監視して障害を検出する機能、
障害情報をプライマリ保守者端末と保守会社システムに通報する機能、
プライマリ保守者端末が、
前記マルチベンダシステム監視通報サーバから通報された障害情報を受信する機能、
障害処理を行う機能、
前記障害に関連する保守会社システムに障害解決処理の指示を行う機能、
障害の発生状況および解決状況に関する報告文書を作成してシステム管理者装置とエンドユーザクライアントと保守会社システムに発信する機能、
保守会社システムが、
前記マルチベンダシステム監視通報サーバから通報された障害情報を受信する機能、
前記プライマリ保守者端末から障害解決処理の指示を受ける機能、
前記マルチベンダシステムを構成する障害機器の保守を行う機能、
障害処理状況を前記プライマリ保守者端末に報告する機能、
を実現させるための保守サービスプログラム。
【請求項２５】
前記プライマリ保守者端末が、
定期点検のための運用停止情報，各機器の現在状態情報，システム運用関係情報，システム管理関係の報告情報ならびに点検および工事作業の工程情報を作成する機能、
前記作成した情報を前記マルチベンダシステム監視通報サーバを経由して電子メール発信する機能、
前記作成した情報を前記マルチベンダシステム監視通報サーバ上にウェブ掲載する機能、
を実現させるための請求項２４記載の保守サービスプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、保守サービス方式，方法およびプログラムに関し、特にマルチベンダシステムにおける保守サービス方式，方法およびプログラムに関する。
【０００２】
【従来の技術】
従来の保守サービスシステムは、ホストシステムの障害状況をホストシステム内の障害監視プログラム或いはホストシステム内の障害監視装置から通信回線を介し情報伝達を行い保守拠点にて監視している（例えば、特許文献１参照）。
【０００３】
また、ＬＡＮに接続された各機器の管理情報にて故障を感知し通信回線を介して保守拠点に通知し、保守拠点にて故障を診断解析し、インターネットにより保守条件、情報を得て保守修理サービス対応しているものもある（例えば、特許文献２参照）。
【０００４】
そして、これらの監視と保守サービス方法は、いずれも保守作業者側の便宜を主体とした方法である。
【０００５】
これらによれば、まず、特許文献１の遠隔障害監視システムに関し、図１９において、ホストシステム５１００自身、入出力装置５１３０、ネットワーク系装置５１４０、端末５１５０に障害が発生すると、ＯＳ（オペレーティングシステム）は、ハードログを採取してハードログファイル５１２０に格納すると共に、障害監視プログラム５２００に障害の発生を報告する。障害監視プログラム５２００は、ハードログで示される障害が被監視装置のもので、重要な障害である場合、メッセージファイル５１１１内の対応するメッセージと対応するログとをマージして、転送装置ファイル５３０１に格納する。ホストシステムのユーザからの通知により、保守拠点のパソコン５５００は、転送装置ファイル５３０１にアクセスを行って、転送装置ファイル５３０１内のメッセージとハードログを取り込んで、加工、編集して表示する。保守拠点の保守者は、表示された情報により、障害切り分け等の保守作業を行う。
【０００６】
次に、特許文献２の家電製品保守修理サービスシステムに関し、図２０において、家電製品の保守修理サービスセンター６００１のＷＷＷサーバ６１０１がＷＷＷインターネット網６００３に公開するホームページをアクセスし、必要な事項を登録して保守契約を結ぶ。この保守契約が成立すれば、その契約者は保守修理サービスセンター６００１の顧客データベース６１０３に登録される。そして一般家庭６００２における家電製品（テレビ６２０３，エアコン６２０４，…，照明器６２０５に組み込まれた自己故障診断手段が家電製品の各部の動作状態を監視し、故障発生部分があれば機器情報管理装置６２０１に通知し、これを受けた機器情報管理装置６２０１は自動的に電話網６００４を通じて保守修理サービスセンター６００１を呼び出し、その故障診断装置６１０２に故障情報を通報する。保守修理サービスセンター６００１では、故障診断装置６１０２が故障情報を受け取ると、故障診断データベース６１０４を検索して故障原因、それに必要な修理内容、交換部品等の情報を決定する。
【０００７】
また、近年、オープンシステムとして複数のメーカーの機器によりシステムが構築されるマルチベンダ情報処理システムが増加している。
【０００８】
このようなマルチベンダシステムにおいて、多種多数な情報処理装置と機器の障害を１つの自動通報装置に集約し、自動通報装置から保守拠点システムに通報している（例えば、特許文献３参照）。
【０００９】
【特許文献１】
特開平１１−２９６４８０号公報
【特許文献２】
特開２０００−１９６７６９号公報
【特許文献３】
特開２００１−３５６９２９号公報
【００１０】
【発明が解決しようとする課題】
しかしながら、上述した従来の技術では、以下のような問題点がある。
【００１１】
第１の問題点は、近年の情報処理システムにおいては、各処理装置自身が持つ、サービスプロセッサによる障害感知と処理の機能が充実しているため、特定メーカーの特定の機種の情報処理装置に対し、単独に障害の処理対応を行うことには有効に機能している。しかし、近年のサーバクライアント構成にてマルチベンダにより、ネットワーク接続で、システムが構築されてきている状況においては、各種ベンダの情報処理装置よりの障害情報を単独に取り扱っていることだけでは、システム全体としての障害の対応処理をするために有効な機能、および方法ではなくなって来ていることである。
【００１２】
その理由は、サーバクライアント構成で、かつ、マルチベンダにて構築された情報処理装置のシステム管理者にとって、ある特定単一装置の障害により、システム全体として、その特定装置の障害停止によって、システム全体への被害、影響を素早く把握し、多数のエンドユーザへの連絡と指示のアナウンスを即座に行う必要があるためである。
【００１３】
第２の問題点は、従来の保守サービスシステムおよび方法は、保守サービス拠点と保守サービス作業者のみの便宜を主体としたものであること、つまり障害情報を保守サービス拠点に対して伝達をすることが目的であり、障害時にシステム使用者側には何も異常情報が自動的に伝達出来なく、保守サービス拠点からの電話連絡などを介して行っていることである。
【００１４】
その理由は、異常状態をシステム使用者側のシステム管理者に、保守サービス拠点より電話などにて伝達するため、遅れが生じること、あるいは、保守拠点からの電話にての問い合わせ確認時、使用者側のシステム管理者が不在にて保守拠点よりシステムの状況がつかめない事態が発生し、保守作業者の対応行動の開始に遅れが生ずること、あるいは、使用者側のシステム管理者がエンドユーザへの対応に忙殺されシステム管理者から障害情報が得られず、保守作業者の障害対応の初期指示と行動に遅れが生じることとにより、障害状況の把握に時間がかかることが生ずるためである。
【００１５】
特に、情報処理装置の自動運転装置による無人運転化が進み、重要なサーバの設置場所、機器監視端末の設置場所に人が居なく、エンドユーザからの申告、または保守サービス拠点からの連絡にて、異常に初めて気付く場合に、この問題が顕著に現れている。
【００１６】
第３の問題点は、従来の保守サービスシステムおよび方法は、情報処理装置のみを主体として、保守拠点からの監視と対応に機能しているのみであり、情報処理装置以外の機器に対しては不十分であることである。
【００１７】
その理由は、情報処理装置の設置されている環境設備の異常状態、例えば空調機故障、温度上限・下限異常、湿度上限・下限異常、漏水などと、情報処理装置の付帯設備の異常状態、例えば無停電電源装置故障、分電盤ブレーカの漏電検知切断などに対する監視と保守サービスは、保守拠点にては対応できない形態、すなわち情報機器の設置されている部屋の表示盤、または運用管理部署の遠隔表示盤への異常表示ランプとブザーにて知らせているか、あるいは、保守拠点からの対応可能の機能を持ち合わせてはいるが、情報処理システム全体として、一括してではなく、環境設備あるいは付帯設備監視の単独の保守サービスのみとして、それぞれ単独処理をする形態となっているためである。それに、ネットワーク機器に関しても、ネットワーク機器単独にての、監視と保守サービスをしていることが多いためである。
【００１８】
第４の問題点は、従来の保守サービスシステムおよび方法は、サーバクライアント構成で、かつ、マルチベンダにて構築された情報処理装置の使用者とシステム管理者にとって、情報処理システムの機器のハードウェアとソフトウェアは、価格性能比からして最適なものを選択し構成出来るが、そのシステムの運用と保守と障害の管理に関しては、システム使用者の煩雑なベンダ、メーカーへの対応処理作業が発生することである。
【００１９】
その理由は、異なった複数のベンダ、メーカーにて構成される情報処理装間のネットワーク通信が異常の場合、システム管理者はそれぞれ複数の保守サービス者間に異常情報の伝達と状況を伝えなければならない手間が生ずる。
【００２０】
また、すべての運用と保守と障害に関する管理事項を、複数のベンダ、メーカーの装置で構成された情報処理システムを使用しているため、それぞれ各事項をそれぞれのベンダ、メーカーと協議しなければならない手間が生ずる。
【００２１】
例えば、ネットワークに新しく情報処理機器を追加増設したが動作しない場合、ネットワーク機器のルータのベンダ、メーカーに対し、情報処理機器側あるいは相手のネットワーク機器側ではこのように言っているが一度調べてもらえないかなど。たとえハードウェア自体は全く同一の機器であっても、複数のベンダ、メーカー間の調整作業が必要となるためである。
【００２２】
また、保守と運用と障害に関する、問題点管理とその仕様を定期的に会議を開催し協議、検討する場合、複数のベンダ、メーカーに対し全てが、一同に会し、会議を開催することには、それぞれの思惑と競合事項により難色を示し、特に故障保守に関しての議事に難色を示すことが多く、ベンダ、メーカー数の回数分の会議を何回も開催しなけれはならない場合が多く、会議内容により、あるベンダ、メーカーとその他のベンダ、メーカーの意見の調整と協議が再度必要になるためである。
【００２３】
更に、図２１を用いて説明する。図２１は従来におけるシステム管理者のマルチベンダ構成による情報処理システムに係わる各当事者との対応関係を示すブロック図である。
【００２４】
図２１において、マルチベンダ機器にて構成された情報処理システムの例えばシステム管理者３０１から各サーバ機器と付帯設備機器とを見た場合、その関連対応を各ブロック間の連結線で結んだ複数の煩雑な対応が必要となっている。
【００２５】
つまり、各メーカー・ベンダＡ３１２〜Ｄ３１５が、それぞれ演算サーバＡ３２０〜Ｄ３２３をそれぞれ対応し、また、ファイルサーバ３２４はメーカー・ベンダＢ３１３が対応し、ネットワーク機器３２５はメーカー・ベンダＡ３１２が対応している。
【００２６】
それぞれのメーカー・ベンダは、それぞれの保守会社Ａ３１６〜Ｄ３１９と１対１にて横につながっているが、それぞれの保守会社と演算サーバＡ３２０〜Ｄ３２３とファイルサーバ３２４とネットワーク機器３２５とは、１対１の直接の横のつながりは無い。
【００２７】
特に、情報処理システム機器の設置場所にある付帯設備機器、例えば、空調機３２６と電源設備３２７と監視盤３２８と監視装置３２９等は、管理部門Ａ３０６の設備課と呼ばれる部門の自営保守か、保守会社Ａ３１６〜Ｄ３１９にそれぞれ対応し管理運営されており、情報処理システム機器の保守とは、分離されている場合が多く、それぞれの保守会社ごとに縦割りの体制となっている。
【００２８】
従って、システム管理者３０１は各メーカー・ベンダとの対応・指示・会議・報告Ａ３０８〜Ｄ３１１をばらばらに各メーカー・ベンダＡ３１２〜Ｄ３１５に対して行わなくてはならないため、非常に手間を要しており不効率な業務処理に係わらなくてはならない状況となっている。また、エンドユーザＡ３０２〜Ｄ３０５、および管理部門Ａ３０６〜Ｂ３０７に対するシステム管理者３０１の係わりも同様である。
【００２９】
第５の問題点は、従来の保守サービスシステムおよび方法は、保守サービス対象範囲がメーカー、ベンダの単位にて区別されており、大規模システムにおける保守作業において、非効率な場合が生じている。
【００３０】
その理由は、オペレーティングシステムが同一、あるいは類似のものを使用することが多くなり、あるひとつのベンダ、メーカーの技術者のスキルにてエラーログの採取などは出来るようになってきている。
【００３１】
そのため、異常発生時にシステム管理者、あるいは異常装置のベンダ、メーカーの技術者によることなく、第一次の対応者は通常のスキルと経験があれば異常の一時的回避、エラーログの収集を行うことが可能であり、特定のひとつのベンダ、メーカーの保守サービス、つまり一人の技術者のみで、システム管理者よりも深い技術レベル、すなわちシステム全体を、その装置のベンダ、メーカーに近い技術レベルにて保守状況の把握が可能であり、複数障害窓口をひとつにすることが出来て効率化が可能であるからである。
【００３２】
また、ハードウェアの定期点検、ソフトウェアメンテナンスにおける作業工程管理と指示は、そのシステムで最も重要なサーバ、例えばファイルサーバ、ネットワークサーバを受け持つベンダ、メーカーが必然的にシステム全体の運用と停止の主導権を持つわけであるため、そこが一括して、請け負うことにより、システムの保守サービスの効率がさらに高まり、システム使用者の手間を省くことが可能であるからである。
【００３３】
本発明の第１の目的は、マルチベンダシステムにてネットワーク接続によるサーバクライアント構成の情報処理システムにおいて、従来のサービスプロセッサによる各個別システム装置にて単独で扱い、障害感知と通報をしていたものを、システム全体としての被害状況を即時に把握が可能とすることにあり、システム管理者と保守者の障害対応作業の負担を軽減することにある。
【００３４】
本発明の第２の目的は、従来の上記の情報システムにおいての、障害感知と通報の方法は、保守サービス拠点と保守サービス作業者の便宜を主としたものであり、システム管理者と使用者には、電話等により保守サービス関係の拠点の作業者より、障害の伝達と確認が行われており、障害現場にいる障害対応者は保守サービス拠点からの電話対応とエンドユーザに対する対応に忙殺され、障害回復のための初期行動に遅れが生じていたことに対し、システム全体を総括してシステム管理者の監視が可能であり、さらにシステム管理者とエンドユーザへの障害通報を行うことを可能とすることにある。
【００３５】
本発明の第３の目的は、従来の上記の情報システムにおいての、障害感知と通報の方法は、情報処理装置のみを主体としての障害監視と通報であるため、システム全体として見ると、その機能として不十分であったものを、情報処理装置の設置場所の環境設備関係と付帯設備に関する障害監視と通報、およびネットワーク関係装置の障害監視と通報機能を持たせ機能を充実させるとともに、関係部署と保守修理会社に自動的に伝達することにより、各装置機器にて単独に動作していた障害の監視と通報機能をまとめシステム全体を網羅し一括管理する機能を持つことを目的とする。
【００３６】
本発明の第４の目的は、マルチベンダ化によりシステム管理者がそれぞれベンダ、メーカーに対して個別に対応することを余儀なくされている状況を回避するために、例えばシステム全体を見てシステム管理上の重要な機能のサーバーを受け持つベンダ、メーカーが主体となって一括管理をすることができる方法を構築し、システム管理者と使用者の便宜と効率の向上をはかることである。
【００３７】
本発明の第５の目的は、マルチベンダによる大規模システムにおけるオペレーティングシステムは、同じものとなってきているので、ソフトウェアメンテナンス、およびハードウェアのエラーメッセージとエラーログの収集は、ある特定ベンダ、メーカーのシステムエンジニアによりシステム障害時の初期の一時的対応は可能であるため、システム全体を一括し、あるベンダ、メーカーがシステムメンテナンスの請け負いを可能とするための方法を構築し、保守サービスの効率を高めることにある。
【００３８】
【課題を解決するための手段】
本願第１の発明の保守サービス方式は、マルチベンダシステムの保守サービスを行う保守サービス方式であって、複数のベンダから納入された各種の機器から構成され情報処理を行うマルチベンダシステムと、前記マルチベンダシステムと接続し前記マルチベンダシステムの障害を検出し障害情報を通報するマルチベンダシステム監視通報サーバと、プライマリ保守者が管理操作し前記マルチベンダシステム監視通報サーバから通報された障害情報を受信し前記障害に関連する保守会社システムに障害解決処理の指示を行い前記障害の発生状況および解決状況に関する報告文書を作成して発信するプライマリ保守者端末と、前記マルチベンダシステム監視通報サーバから通報された障害情報を受信し前記マルチベンダシステムを構成する機器の保守を行う保守会社システムと、を備える。
【００３９】
本願第２の発明の保守サービス方式は、第１の発明において前記マルチベンダシステム監視通報サーバは、前記各種の機器が出力する障害自動通報メッセージあるいは自動通報信号を入力して障害メッセージに変換するインターフェイス変換装置と、ＲＳ送信要求信号を感知して前記インターフェイス変換装置に送出するＲＳ信号感知部と、前記障害メッセージを通報する障害自動通報装置と、障害メールサーバと、を有する。
【００４０】
本願第３の発明の保守サービス方式は、第２の発明において前記各種の機器が、サーバ機器とクライアント機器と付帯設備機器から成る。
【００４１】
本願第４の発明の保守サービス方式は、第３の発明において前記サーバ機器はＳＶＰ（サービスプロセッサ）を備え、前記ＳＶＰは障害を検出しモデム経由で前記インターフェイス変換装置と前記保守会社システムに通知する手段を有する。
【００４２】
本願第５の発明の保守サービス方式は、第３の発明において前記サーバ機器はＳＶＰを備え、前記ＳＶＰとモデム間のインターフェイスケーブルであるＤＴＥケーブルを前記ＲＳ信号感知部を中継して接続する構成を成し、前記ＳＶＰは障害を検出して前記モデム経由で前記保守会社システムに通知する手段を有し、前記ＤＴＥケーブルに送出した前記モデムへのＤＴＥインターフェイス信号のうちＲＳ送信要求信号を前記ＲＳ信号感知部を経由して前記インターフェイス変換装置が感知して障害発生を認知することを特徴とする。
【００４３】
本願第６の発明の保守サービス方式は、第３の発明において前記サーバ機器は、オペレーティングシステムが障害を検出しモデム経由で前記インターフェイス変換装置と前記保守会社システムに通知する手段を有する。
【００４４】
本願第７の発明の保守サービス方式は、第３の発明において前記サーバ機器は、前記サーバ機器とモデム間のインターフェイスケーブルであるＤＴＥケーブルを前記ＲＳ信号感知部を中継して接続する構成を成し、前記サーバ機器は障害を検出して前記モデム経由で前記保守会社システムに通知する手段を有し、前記ＤＴＥケーブルに送出した前記モデムへのＤＴＥインターフェイス信号のうちＲＳ送信要求信号を前記ＲＳ信号感知部を経由して前記インターフェイス変換装置が感知して障害発生を認知することを特徴とする。
【００４５】
本願第８の発明の保守サービス方式は、第３の発明において前記サーバ機器は、障害を検出しＲＳ２３２Ｃシリアルインターフェイス信号により前記インターフェイス変換装置にメッセージ通知する手段を有することを特徴とする。
【００４６】
本願第９の発明の保守サービス方式は、第３の発明において前記付帯設備は、障害検出時にＲＳ２３２Ｃシリアルインターフェイス信号により前記インターフェイス変換装置にメッセージ通知する手段を有する。
【００４７】
本願第１０の発明の保守サービス方式は、第３の発明において前記付帯設備は、障害時に接点を閉じ正常時は接点を開放する接点信号により前記インターフェイス変換装置に通知する手段を有する。
【００４８】
本願第１１の発明の保守サービス方式は、第５，第７，第８，第９または第１０の発明において前記インターフェイス変換装置は、前記信号を感知して前記信号に対応する障害メッセージ変換・付加を行う手段を有する。
【００４９】
本願第１２の発明の保守サービス方式は、第１の発明においてシステム管理者が前記マルチベンダシステムを管理するためにシステムコンソールと運用監視サーバとメールサーバとを含むシステム管理者装置を備える。
【００５０】
本願第１３の発明の保守サービス方式は、第１２の発明において前記システムコンソールと前記運用監視サーバは、前記前記システムコンソールと前記運用監視サーバが受信したメッセージの中から障害用語を含むメッセージを検出し前記プライマリ保守者端末に伝達する手段を有する。
【００５１】
本願第１４の発明の保守サービス方法は、複数のベンダから納入された各種の機器から構成され情報処理を行うマルチベンダシステムの保守サービスを行う保守サービス方法であって、マルチベンダシステム監視通報サーバは、前記マルチベンダシステムを監視して障害を検出し、障害情報をプライマリ保守者端末と保守会社システムに通報し、前記プライマリ保守者端末は、前記マルチベンダシステム監視通報サーバから通報された障害情報を受信し、障害分析および障害処理を行い、前記障害に関連する保守会社システムに障害解決処理の指示を行い、障害の発生状況に関する報告文書を作成してシステム管理者装置とエンドユーザクライアントと保守会社システムに発信し、保守会社システムは、前記マルチベンダシステム監視通報サーバから通報された障害情報を受信し、前記プライマリ保守者端末から障害解決処理の指示を受け、前記マルチベンダシステムを構成する障害機器の保守を行い、障害処理状況を前記プライマリ保守者端末に報告し、前記プライマリ保守者端末は、障害の解決状況に関する報告文書を作成してシステム管理者装置とエンドユーザクライアントと保守会社システムに発信する、ことを特徴とする。
【００５２】
本願第１５の発明の保守サービス方法は、第１４の発明においてプライマリ保守者は前記プライマリ保守者端末を使用して定期点検のための運用停止情報，各機器の現在状態情報，システム運用関係情報，システム管理関係の報告情報ならびに点検および工事作業の工程情報を作成し、前記マルチベンダシステム監視通報サーバを経由して電子メール発信、あるいは前記マルチベンダシステム監視通報サーバ上にウェブ掲載することを特徴とする。
【００５３】
本願第１６の発明の保守サービス方法は、第１４の発明においてプライマリ保守者は、前記障害処理が完了したら、前記プライマリ保守者端末を使用してテストランジョブをリモート起動して実行し、障害の完了を確認し、運用業務再開の操作をすることを特徴とする。
【００５４】
本願第１７の発明の保守サービス方法は、第１４の発明において前記障害処理は、プライマリ保守者が全てを行うことを特徴とする。
【００５５】
本願第１８の発明の保守サービス方法は、第１４の発明において前記障害処理は、マルチベンダシステムの全体を把握したプライマリ保守者の主導にて行い、プライマリ保守者とセカンダリ以降の保守者が分担して行うことを特徴とする。
【００５６】
本願第１９の発明の保守サービス方法は、第１４の発明において前記障害処理は、プライマリ保守者がシステム管理者とエンドユーザへの窓口処理を行い、プライマリ保守者が前記障害処理をセカンダリ以降の保守者に渡し前記セカンダリ以降の保守者が行うことを特徴とする。
【００５７】
本願第２０の発明の保守サービス方法は、第１７の発明において前記障害処理は、プライマリ保守者が、障害発生したシステムサーバ機器の業務内容と障害事象内容により、運用続行優先の場合は、再立ち上げ操作を行い、再立ち上げが成功して運用業務が続行した場合は、間欠障害とみなして業務を続行し、その障害の原因を究明し故障・不良に対する調査・処置のためのマシンタイムを確保して運用停止の条件が整ったときに運用を停止し、再立ち上げ操作にて障害が回復しなかった場合あるいは再立ち上げしても短時間に障害が再発する場合は間欠障害ではなく固定障害であるとみなして障害処理を行うために運用停止操作をし、運用続行優先でない場合は、障害発生の原因を究明し処置を優先してシステムサーバ機器を停止し、障害エラーログを収集し、アサインした技術支援部門の技術者あるいはプライマリ保守者自身によりエラーログ解析を行い、エラーログ解析にて故障個所が判明した場合には故障部品を手配し、故障個所が判明しなかった場合には障害事象やエラーログなどにより故障の原因と予測される部品を確定し確定した部品を手配し、運搬された部品を受け取り、故障部品あるいは故障予測部品を交換し、障害処理状況や復旧見込みの障害処理情報をシステム管理者とエンドユーザに報告する、ことであることを特徴とする。
【００５８】
本願第２１の発明の保守サービス方法は、第１８の発明において前記障害処理は、プライマリ保守者が、システムサーバ機器の運用に関係する操作である再立ち上げ操作と運用停止操作と調査マシンタイム確保停止とエラーログの収集を行い、セカンダリ以降の保守者が、エラーログを解析し、故障部品を特定し、前記部品を手配し、前記部品を運搬し、前記部品交換を行い、前記プライマリ保守者に障害処理状況を報告し、プライマリ保守者が、前記セカンダリ以降の保守者から経過報告を受け、プライマリ保守者の状況判断を加えて障害処理状況や復旧見込みの障害処理情報をシステム管理者とエンドユーザに報告する、ことであることを特徴とする。
【００５９】
本願第２２の発明の保守サービス方法は、第１９の発明において前記障害処理は、セカンダリ以降の保守者が、再立ち上げ操作を行い、運用停止を操作を行い、エラーログを収集し、エラーログを解析し、故障部品を特定し、前記部品を手配し、前記部品を運搬し、前記部品交換を行い、前記プライマリ保守者に障害処理状況を報告し、プライマリ保守者が、前記セカンダリ以降の保守者から経過報告を受け、プライマリ保守者の状況判断を加えて障害処理状況や復旧見込みの障害処理情報をシステム管理者とエンドユーザに報告する、ことであることを特徴とする。
【００６０】
本願第２３の発明の保守サービス方法は、第２０，第２１または第２２の発明においてソフトウェア障害については、障害ダンプデータ収集を行い、前記ダンプデータ解析を行い、ソフトウェア障害に対するパッチ修正物件の作成を依頼し、前記パッチ修正物件を入手し、前記パッチ修正物件を適用する、ことを特徴とする。
【００６１】
本願第２４の発明の保守サービスプログラムは、複数のベンダから納入された各種の機器から構成され情報処理を行うマルチベンダシステムの保守サービスを行う保守サービスプログラムであって、コンピュータに、マルチベンダシステム監視通報サーバが、前記マルチベンダシステムを監視して障害を検出する機能、障害情報をプライマリ保守者端末と保守会社システムに通報する機能、プライマリ保守者端末が、前記マルチベンダシステム監視通報サーバから通報された障害情報を受信する機能、障害処理を行う機能、前記障害に関連する保守会社システムに障害解決処理の指示を行う機能、障害の発生状況および解決状況に関する報告文書を作成してシステム管理者装置とエンドユーザクライアントと保守会社システムに発信する機能、保守会社システムが、前記マルチベンダシステム監視通報サーバから通報された障害情報を受信する機能、前記プライマリ保守者端末から障害解決処理の指示を受ける機能、前記マルチベンダシステムを構成する障害機器の保守を行う機能、障害処理状況を前記プライマリ保守者端末に報告する機能、を実現させる。
【００６２】
本願第２５の発明の保守サービスプログラムは、第２４の発明において前記プライマリ保守者端末が、定期点検のための運用停止情報，各機器の現在状態情報，システム運用関係情報，システム管理関係の報告情報ならびに点検および工事作業の工程情報を作成する機能、前記作成した情報を前記マルチベンダシステム監視通報サーバを経由して電子メール発信する機能、前記作成した情報を前記マルチベンダシステム監視通報サーバ上にウェブ掲載する機能、を実現させる。
【００６３】
【発明の実施の形態】
最初に、本発明の保守サービス方式および保守サービス方法の概念について、図面を参照して説明する。
【００６４】
先ず、本発明の保守サービス方式の概念について、図１を用い説明する。
図１は本発明の保守サービス方式の概念を説明する図である。
【００６５】
図１を参照すると、本発明の保守サービス方式は、マルチベンダシステム１と、システム管理者装置２と、第１ネットワーク３と、マルチベンダシステム監視通報サーバ４と、プライマリ保守者端末５と、第２ネットワーク６と、各メーカー／ベンダ／保守会社システム７と、を備えている。
【００６６】
マルチベンダシステム１は、各種サーバ装置１１と各種クライアント装置１２と各種付帯設備１３（空調設備，無停電電源装置，監視装置など）とを含み、情報処理を行うシステムである。マルチベンダシステムを構成するこれらの装置は複数のベンダから納入されている。各種クライアント装置１２は、エンドユーザが使用する装置であり、各種サーバ装置１１にＬＡＮ（ローカルエリアネットワーク）等のネットワークで接続されている。
【００６７】
システム管理者装置２は、システム管理者がマルチベンダシステム１を管理するための装置であり、システムコンソール，運用監視サーバ，メールサーバ等を含んでいる。
【００６８】
第１ネットワーク３は、マルチベンダシステム１とシステム管理者装置２とマルチベンダシステム監視通報サーバ４とを結ぶＬＡＮ等の通信網である。
【００６９】
マルチベンダシステム監視通報サーバ４は、マルチベンダシステム１と接続され、マルチベンダシステム１の障害を検出し、障害情報をプライマリ保守者端末５，システム管理者装置２，各メーカー／ベンダ／保守会社システム７に通報する。マルチベンダシステム監視通報サーバ４は、プライマリ保守者（一次保守者）が管理操作する。
【００７０】
プライマリ保守者端末５は、プライマリ保守者用の端末であり、マルチベンダシステム監視通報サーバ４とＬＡＮ等のネットワークで接続されている。プライマリ保守者端末５は、マルチベンダシステム監視通報サーバ４から通報された障害情報を受信する機能、障害に関連する各メーカー／ベンダ／保守会社システム７に障害解決および経過報告の指示を電子メールや電話等で行う機能、障害の発生状況および解決状況等を報告する文書を作成しマルチベンダシステム監視通報サーバ４のメール機能を経由して関連者にメールを発信する機能、稼動実績や定期保守情報などのシステム運用管理情報のＷｅｂ（ウェブ）コンテンツを作成しＷｅｂブラウザで閲覧できるようにマルチベンダシステム監視通報サーバ４のＷｅｂ機能に登録する機能、などを有する。
【００７１】
プライマリ保守者とは、マルチベンダシステムに関係する各メーカー／ベンダ／保守会社を取りまとめて保守対応窓口となり保守を統括する者のことである。例えば、マルチベンダシステムを構成する機器がベンダＡ，ベンダＢ，ベンダＣおよびベンダＤから納入されていた場合に、保守対応窓口となるベンダを１つ決めて（例えば、ベンダＡ）プライマリ保守者とし、残りのベンダＢ，ベンダＣおよびベンダＤがセカンダリ以降の保守者となる。プライマリ保守者は、システム管理者と各ベンダとの協議で決定されるが、通常は主要な機器を納入したベンダが選ばれる。
【００７２】
第２ネットワーク６は、マルチベンダシステム監視通報サーバ４と各メーカー／ベンダ／保守会社システム７とを結ぶ通信網であり、例えば、ＬＡＮ，公衆回線，ＩＳＤＮ回線，インターネット等である。
【００７３】
各メーカー／ベンダ／保守会社システム７は、マルチベンダシステム１を構成する機器の保守サービスを担当する各メーカー／ベンダ／保守会社のシステムである。各メーカー／ベンダ／保守会社システム７は、マルチベンダシステム監視通報サーバ４から通報された障害情報を受信する機能を有する。また、プライマリ保守者端末５から障害解決および経過報告の指示を受け、障害の解決処理を行い、経過報告や解決報告をプライマリ保守者端末５に行う。
【００７４】
図２にマルチベンダシステムの例を示す。図２はマルチベンダシステム機器により構成されたスーパーコンピュータシステムの例である。演算サーバ機器として、スーパーコンピュータにおいては各メーカーのアーキテクチャの違いにより得意とする演算性能をもつので、構成される演算サーバは当然ながら別メーカー、すなわちマルチベンダによるシステム構成となっている。図２を参照すると、Ａ社製ベクトル共有メモリ機２０１とＢ社製ベクトル分散メモリ機２０２とＣ社製スカラ分散メモリ機２０３とＤ社製スカラ共有メモリ機２０４とが、それぞれＥ社製ネットワーク装置２０５にてＦ社製ＦＤＤＩ−ＬＯＯＰ／ＡＴＭ−ＬＡＮ２０６に接続されている。そして、エンドユーザクライアント２１０はＦ社製ＦＤＤＩ−ＬＯＯＰ／ＡＴＭ−ＬＡＮ２０６あるいはＥＴＨＥＲ−ＬＡＮ２１８にて各サーバと接続されている。また、遠隔地のエンドユーザクライアント２１０はルータ２０７を介したＷＡＮ・インターネット２０８と接続されている。
【００７５】
そして、システム管理者がマルチベンダシステムを管理するシステム管理者装置として、ネットワーク監視サーバ２１６と、各サーバのシステムコンソール２２０と、業務実行状態，課金，ユーザ登録等を行う運用監視サーバ２２１と、システム使用者のための業務連絡，メンテナンス情報連絡，質問対応，問い合わせ対応等のためのメールサーバ２２２，などがＥＴＨＥＲ−ＬＡＮ２１８を介し接続されている。
【００７６】
続いて、本発明の保守サービス方法の概念について、図１を参照して説明する。
【００７７】
本発明の保守サービス方法は、プライマリ保守者がシステム管理者からマルチベンダシステム１に関する保守サービスを一括して請け負うものである。プライマリ保守者は、マルチベンダシステム１の使用者側（システム管理者・エンドユーザ）とマルチベンダシステム１の機器提供者側（メーカー・ベンダ・保守会社）との間を請け負い、マルチベンダシステム監視通報サーバ４とプライマリ保守者端末５を使用してマルチベンダシステム１の障害処理等（通報・対応・支援など）を一括して行う。
【００７８】
すなわち、プライマリ保守者は、マルチベンダシステム監視通報サーバ４とプライマリ保守者端末５を使用して、マルチベンダシステム１の障害を監視し、発生した障害の情報を一括管理し、自分自身あるいはセカンダリ以降の保守者（二次保守者、三次保守者等）と分担して障害の解決処理を行い、システム管理者等の関連者に適宜状況の報告を行う。また、稼動実績や定期保守情報などのシステム運用管理情報を作成して関連者（システム管理者、エンドユーザ、メーカー・ベンダ・保守会社）に通知する。更に、システム管理者等の使用者側とシステムの機器提供者側との間の調整等（例えば、会議日程の調整）を行う。
【００７９】
図３にシステム使用者側とシステム機器提供者側とプライマリ保守者との関係を示す。図３を参照すると、プライマリ保守者がシステム使用者側とシステム機器提供者側との間を取り持つ位置にいることが示されている。
【００８０】
更に、図４を用いて説明する。図４は、［発明が解決しようとする課題］で説明した図２１の複雑に関連したマルチベンダシステムをシングルベンダシステムの如くに扱うための方法を図示したものである。
【００８１】
まず、システムの使用者側に関し、すなわちシステム管理者３０１とエンドユーザＡ３０２〜エンドユーザＤ３０５と管理部門Ａ３０６〜管理部門Ｂ３０７との間の図２１で示される関係連結線での情報伝達収集を、インターネット情報収集伝達４０１にて行う。
【００８２】
また、各メーカー・ベンダと各サーバ機器とネットワーク機器と各保守会社と各付帯設備機器をひとまとめとして扱い、プライマリ保守者がマルチベンダ一括支援サービス４０６を行う。
【００８３】
更に、対応・指示・会議・報告Ａ３０８〜対応・指示・会議・報告Ｄ３１１をまとめ、プライマリ保守者が一括対応窓口４０５として対応する。
【００８４】
このように、プライマリ保守者は、マルチベンダ対応手段４０２としてのマルチベンダシステム監視通報サーバ４０３とプライマリ保守者端末４０４とを使用し、またインターネット情報収集伝達（Ｗｅｂ機能やメール機能）を利用して、マルチベンダシステム全体との間を一括した通報・対応・支援等の保守サービスを行う。
【００８５】
システム管理者は、保守関係業務をプライマリ保守者にアウトソーシングすることにより、本来の管理業務（例えば、システムチューニング，ジョブ入力キュー定数の変更，ユーザ登録認証管理など）に専念することができるようになる。
【００８６】
次に、本発明の実施の形態について図面を参照し詳細に説明する。
図５は、本発明の実施の形態の構成を示すブロック図である。
【００８７】
図５を参照すると、本発明の実施の形態は、マルチベンダシステム監視通報サーバ１５と、マルチベンダシステム７００と、公衆回線７０１と、ベンダシステム７０５と、インターネット７０８と、プライマリ保守者端末７０９と、ＬＡＮ７１５と、保守拠点システム７１８と、システム管理者装置７２２と、モデムｂ７０４２と、モデムｄ７０４４と、モデムｅ７０４５と、を備えている。
【００８８】
マルチベンダシステム７００は、マルチベンダシステムの一例であり、ＳＶＰ（サービスプロセッサ）ａ７０３１とモデムａ７０４１とを含むサーバＶ７０２と、ＳＶＰｂ７０３２を含むサーバＷ７０６と、サーバＸ７１０と、サーバＹ７１１と、サーバＺ７１２と、付帯設備７１４と、エンドユーザクライアント７１７と、を有している。
【００８９】
付帯設備７１４は、ある程度のインテリジェント機能を持った付帯設備監視装置と、ランプ表示あるいは警報ブザーを持った付帯設備監視盤と、エアコンなどの空調設備と、電力供給のための無停電電源装置などの付帯電源設備と、を含み、これらからの信号（ＲＳ２３２Ｃ７１３，接点信号７１６）をマルチベンダシステム監視通報サーバ１５のインターフェイス変換装置１６に接続する。例えば、付帯設備監視盤や空調設備等からの接点信号７１６、無停電電源装置等からのＲＳ２３２Ｃシリアルインターフェイス信号７１３、をマルチベンダシステム監視通報サーバ１５内のインターフェイス変換装置１６に送出する。
【００９０】
マルチベンダシステム監視通報サーバ１５は、プログラム制御で動作する情報処理装置で、インターフェイス変換装置１６と、障害自動通報装置１７と、障害メールサーバ１８と、モデムｃ７０４３と、ＲＳ信号感知部ａ７０７１と、ＲＳ信号感知部ｂ７０７２と、を有し、インターネット７０８あるいは公衆回線７０１あるいはＬＡＮ７１５を介してマルチベンダシステム７００，プライマリ保守者端末７０９，ベンダシステム７０５，保守拠点システム７１８，システム管理者装置７２２と接続する。マルチベンダシステム監視通報サーバ１５は、マルチベンダシステム７００の障害を検出し、障害情報をプライマリ保守者端末７０９，システム管理者装置７２２，ベンダシステム７０５，保守拠点システム７１８に通報する。更に、マルチベンダシステム監視通報サーバ１５は以下に示すような手段（機能）を有する。
・電子メールの作成および送受信を行うメール手段
・ウェブコンテンツの作成および掲載を行うＷｅｂ手段
・マルチベンダシステムを構成する各機器の状態を作成し表示する手段
・マルチベンダシステム設置場所の温度と湿度のグラフを作成し表示する手段
・マルチベンダシステムの構成を表す絵図を表示して障害が発生した機器の色を赤に変化させる手段および必要に応じてアラームを鳴動させる手段
・障害発生装置の色の変化表示機能とアラーム鳴動機能の状態監視を常時画面に表示する手段
・マルチベンダシステムのサーバにおいてストリームバッファの不足が発生して「演算サーバに一般ユーザーがログイン不可、ＮＩＳ（ネットワークインフォメーションシステム）にてユーザー名／グループ名の参照不可」の障害とならないように、サーバのストリームバッファの使用量を監視する手段
・マルチベンダシステムの稼働状況を示す値（図１５に示すようなジョブ件数，最大使用メモリ量，ディスク使用容量など）をサーバから取得する手段、等。
【００９１】
なお、上記の手段（機能）は、プライマリ保守者端末７０９に備えてもよいし、マルチベンダシステム監視通報サーバ１５とプライマリ保守者端末７０９が分担して備えてもよい。
【００９２】
インターフェイス変換装置１６は、異なる多種・多様なインターフェイス信号に対応し、モデムｃ７０４３が受信した障害情報、あるいはＲＳ信号感知部ａ７０７１とＲＳ信号感知部ｂ７０７２が感知したＲＳ信号、あるいはＲＳ２３２Ｃシリアルインターフェイス信号７１３、あるいは接点信号７１６などを入力し、インターフェイス変換を行い、障害を認知する。認知した障害情報を基に障害メッセージ変換・付加を行い、障害自動通報装置１７や障害メールサーバ１８に送出する。
【００９３】
障害自動通報装置１７は、インターフェイス変換装置１６に入力されたサーバＺ７１２またはクライアントなどからのＲＳ２３２Ｃシリアルインターフェイス信号、および付帯設備７１４よりのＲＳ２３２Ｃシリアルインターフェイス信号７１３や障害感知接点信号７１６、およびＬＡＮ７１５経由にてのマルチベンダシステム監視通報サーバ１５へのメッセージによる障害感知状況、などの各サーバ装置等の障害を、必要に応じ、ベンダシステム７０５やプライマリ保守者端末７０９等に通報する。障害自動通報装置１７は以下の機能を有する。
【００９４】
▲１▼公衆回線（モデム）接続とし、ＬＡＮ・ネットワーク関係の障害（ルーター、ハブなどの）とネットワーク機器故障と光ケーブル断線などの通信媒体の故障の場合、公衆回線７０１にて障害を通報する。
【００９５】
▲２▼公衆回線、ダイアルアップ通信で、最低限、１箇所に連絡、最低、ある一つ電話の呼び出し音を鳴らすだけでもよく、発信もとの番号通知などにて、とにかく、何かの、障害異常が発生したことを、プライマリ保守者端末７０９、ベンダシステム７０５、保守拠点システム７１８に通知する。
【００９６】
▲３▼通報する意味、内容は、障害の発生を喚起することを主体とする。通信内容と、通信先と、受信側の処理は障害に関すること、のみに特化する。
【００９７】
▲４▼メール通報は通報配信先に（障害の）通報が来たことに気付かない場合があり、また、他のメール受信と混在して障害通知であることを見逃すこともあるので、メール通報を補完する意味、機能を行う。
【００９８】
▲５▼障害ログ、診断などを収集する場合のセキュリティ機能を持たせ、外部、リモートアクセス通信を（ＳＶＰに直接アクセスするのと同様な機能を）行う（主に、図５のサーバＹおよびサーバＺの場合の機能を補助する）。
【００９９】
障害メールサーバ１８は、インターフェイス変換装置１６から送出される障害メッセージ、およびＬＡＮ７１５経由にてのマルチベンダシステム監視通報サーバ１５へのメッセージによる障害感知状況、などの各サーバ装置等の障害を、ベンダシステム７０５、プライマリ保守者端末７０９、システム管理者装置７２２等に通報する。また、メーラー機能、メーリングリストの保持と更新、メール送信先の選別などを行う。また、システムを構成するサーバ機器の障害メッセージログやシステムメッセージログなどのログファイルを常時監視し、例えば障害を意味する「ＤＡＮＧＥＲ」等の障害用語の文字つづりを適時に検索し、障害を感知してプライマリ保守者端末７０９に伝達する手段を有する。障害メールサーバ１８は以下の機能を有する。
【０１００】
▲１▼障害の発生したシステムのインターネット機能が正常であること、電子メールが配信出来る状態であることを前提に、多数の通報配信先に対し、メーリングリストをもとに、全て、あるグループあて、プライマリ保守者、エンドユーザ、システム管理者、保守会社等に同時配信（ブロードキャスト）を行う。
【０１０１】
▲２▼障害自動通報装置１７では、通報しえなかった、ある程度詳細な、専門家でなくても理解できる内容のメッセージを配信する。
【０１０２】
▲３▼プライマリ保守者が、障害の途中経過、障害処理完了予測時刻、被害状況、制限事項を、障害に対する処理を現地にて行った経過や結果を、適時に配信（ブロードキャスト）する。
【０１０３】
▲４▼管理運用情報、点検期日情報、点検完了予定時間の延長の通知（図１４の内容）などを配信する。
【０１０４】
▲５▼障害に関係する掲示板、電子黒板機能も持つ。
【０１０５】
▲６▼運用管理、関連情報など（図１５〜図１８）の情報開示（伝達）を行う。
【０１０６】
モデムｃ７０４３は、サーバ装置からの障害メッセージを公衆回線７０１経由で受信する。
【０１０７】
ＲＳ信号感知部ａ７０７１は、モデムｂ７０４２のＤＴＥインターフェイス信号のうちのＲＳ送信要求信号を感知してインターフェイス変換装置１６に送出する。
【０１０８】
ＲＳ信号感知部ｂ７０７２は、モデムｄ７０４４のＤＴＥインターフェイス信号のうちのＲＳ送信要求信号を感知してインターフェイス変換装置１６に送出する。
【０１０９】
プライマリ保守者端末７０９は、プログラム制御で動作するパソコン等の情報処理装置であり、インターネット７０８あるいは公衆回線７０１あるいはＬＡＮ７１５を介しマルチベンダシステム監視通報サーバ１５と接続し、また、マルチベンダシステム７００とも接続する。プライマリ保守者端末７０９は、保守窓口となり一次保守を担当するプライマリ保守者が管理操作する。プライマリ保守者端末７０９は、マルチベンダシステム監視通報サーバ１５から通報された障害情報を受信する機能、障害に関連するベンダシステム７０５等に障害解決および経過報告の指示を電子メールや電話等で行う機能、障害の発生状況および解決状況等を報告する文書を作成してマルチベンダシステム監視通報サーバ１５のメール機能を経由して関連者にメールを発信する機能、稼動実績や定期保守情報などのシステム運用管理情報のＷｅｂコンテンツを作成してＷｅｂブラウザで閲覧できるようにマルチベンダシステム監視通報サーバ１５のＷｅｂ機能に登録する機能、システム管理者等の使用者側とシステムの機器提供者側との間の調整等（例えば、会議日程の調整）を行う機能、などを有する。また、サーバやＳＶＰのエラーログを収集する手段、サーバやＳＶＰへ外部からリモートアクセスする手段、を有する。プライマリ保守者端末７０９は、マルチベンダシステム監視通報サーバ１５が存在する場所、またはベンダシステム７０５内、または保守拠点システム７１８内、または専用の設置場所内、または移動体内など、どこに設置してもよく、プライマリ保守者端末７０９は、ベンダシステム７０５，保守拠点システム７１８，システム管理者装置７２２などとインターネット７０８あるいは公衆回線７０１あるいはＬＡＮ７１５などを介して接続される。
【０１１０】
ベンダシステム７０５は、マルチベンダシステム７００を構成する機器を納入したベンダのシステムである。ベンダシステム７０５は、納入した機器が自動通報する障害情報を受信し、また、マルチベンダシステム監視通報サーバ１５から通報された障害情報を受信する。また、プライマリ保守者端末７０９から障害解決および経過報告の指示を受け、障害の解決処理を行い、経過報告や解決報告をプライマリ保守者端末７０９に行う。ベンダシステム７０５は、機器を納入したベンダごとに存在する。ベンダシステム７０５が保守拠点システム７１８を兼ねてもよい。
【０１１１】
保守拠点システム７１８は、納入した機器の保守を行う保守拠点のシステムである。交換部品や消耗品等の保守部品を在庫している。機器の保守を担当する保守会社ごとに存在する。保守拠点システム７１８がベンダシステム７０５を兼ねてもよい。
【０１１２】
システム管理者装置７２２は、システム管理者が管理操作する装置で、システムコンソール７１９と、運用監視サーバ７２０と、メールサーバ７２１と、を含んでいる。システム管理者装置７２２は、ＬＡＮ７１５を介し、マルチベンダシステム７００とマルチベンダシステム監視通報サーバ１５とに接続している。
【０１１３】
システムコンソール７１９は、各サーバ装置のオペレーティングシステムからのメッセージを表示する機能、オペレーティングメッセージの問い合わせに応答する機能などを有するシステム操作装置である。システム管理者のモニタ用装置でもある。システムコンソール７１９は、以下のような機能を有する。
【０１１４】
▲１▼システム立ち上げ操作（立ち上げコマンド）を投入する。
【０１１５】
▲２▼システム停止操作（シャットダウンコマンド）を投入する。
【０１１６】
▲３▼ＩＳＬ（イニシャルシステムローディング）あるいはＢＯＯＴ  ＬＯＡＤと呼ばれる立ち上げ中のメッセージの表示。
【０１１７】
▲４▼異常停止後の再立ち上げ時のディスク（ファイル）スキャンメッセージ表示。
【０１１８】
▲５▼システム障害メッセージ表示。
【０１１９】
▲６▼ネットワークファイルのエラーメッセージ（ネットワークファイルが読めません、ファイルサーバからの応答が有りません、など）の表示。
【０１２０】
▲７▼運用開始コマンド、ネットワークオンライン、エンドユーザーのアクセス（使用開始）許可コマンドの表示。
【０１２１】
▲８▼マルチＣＰＵ、アレイディスクの自動宿退、自動再立ち上げ、再試行成功の可否の表示。
【０１２２】
▲９▼各サーバ装置からの障害関係のメッセージ表示、等。
【０１２３】
システムコンソール７１９とマルチベンダシステム監視通報サーバ１５間の障害状況（メッセージ）の伝達手段は、以下のようにしてもよい。
（Ａ）マルチベンダシステム監視通報サーバ１５自身がコンソール機能を兼任し、障害メッセージ受信をにて、障害を感知する。
（Ｂ）コンソールメッセージをメッセージ文として、システムコンソール７１９からマルチベンダシステム監視通報サーバ１５に渡す。
（Ｃ）コンソールメッセージをシステムコンソール７１９がファイルに書き、書かれたファイルをマルチベンダシステム監視通報サーバ１５が読む。
【０１２４】
運用監視サーバ７２０は、マルチベンダシステム監視通報サーバ１５とのＬＡＮ通信により、マルチベンダシステム監視通報サーバ１５が持つ障害発生装置の色の変化表示機能とアラーム鳴動機能の状態監視を常時画面に表示する手段を有する。運用監視サーバ７２０は以下の機能を有する。
【０１２５】
▲１▼エンドユーザのＩＤ（Ｉｄｅｎｔ）の登録、承認、許可、変更、取り消しなどを行う。例えば、
・年度毎の登録更新、課金（ＣＰＵ使用許可時間、メモリ使用許可時間  ディスクファイル容量許可値）
・ＩＤＥＮＴ単位の実績把握、ＩＤＥＮＴのグループ所属：グループＩＤＥＮＴ設定
・各年度の資源使用要求申請と使用実績の把握（次年度の認可の基準とする）
・不正、悪徳利用者のＩＤＥＮＴ削除（排除）
・ＩＤＥＮＴ使用可能期間の設定と許可期間オーバーの警告と強制使用停止
・特別認可ジョブ、プロジェクトのため利用資源の設定変更とＩＤＥＮＴの設定
・課金料オーバー者への警告と、利用停止
・課金料オーバー者の再申請の認可、利用可能資源料の変更
・課金料の変更、更新。
【０１２６】
▲２▼システム利用の受付、門番、使用監視を行う。
【０１２７】
▲３▼ログインサーバといったサーバと連携させ、システムを有効利用、利用者に対する不公平の抑止、を（ログイン時）に制限優先を行う。
【０１２８】
▲４▼各サーバ間で、利用者を（意識的に）振り分けるための管理を行う。
【０１２９】
▲５▼プラグラム開発のためのＩＤＥＮＴ（ジョブキューの指定も含め）の指定。
【０１３０】
▲６▼テストランのジョブＩＤＥＮＴ（ジョブキューの指定も含め）などを指定。
【０１３１】
▲７▼時期により、優先ジョブを設定する。
【０１３２】
▲８▼利用者の優先度管理を行う。
【０１３３】
メールサーバ７２１は、障害メッセージを受信してエンドユーザクライアント７１７へのブロードキャスト配信を行い、更にシステム全体に対する指示、つまり定期点検の日程情報伝達、登録ユーザＩＤの年度更新によるシステム運用停止情報、ベンダとの定例会議内容、エンドユーザクライアント７１７への指示伝達、質問受付などの業務連絡を司る。また、マルチベンダシステム監視通報サーバ１５から配信した障害メールが適正に配信されているかどうかのモニターサーバーとしの役割を持つ。なお、定期点検の日程情報伝達は、各ベンダーとの日程協議や工程協議をプライマリ保守者が行い、最終承認と確認のために運用監視サーバ７２０へ伝える。エンドユーザーへの伝達は、運用監視サーバ７２０、メールサーバ７２１より配信する。また、登録ユーザＩＤの年度更新は、全て、運用監視サーバ７２０が司り、プライマリ保守者は、運用停止の期日、時間を、関係ベンダ・メーカーにマルチベンダシステム監視通報サーバ１５から伝達する。また、ベンダとの定例会議内容は、定例会議はプライマリ保守者が開催し、決議内容をまとめ、運用監視サーバ７２０へ伝える。システム管理者との定例会議はプライマリ保守者のみ出席する。必要に応じ、プライマリ保守者は、メーカ・ベンダ（セカンダリ保守者）を同席させ、対応する。また、エンドユーザ７１７への指示伝達、質問受付などの業務連絡は、運用監視サーバ７２０とメールサーバ７２１にて行う。従って、マルチベンダシステム監視通報サーバ１５からのメール配信はシステム管理者装置，各保守拠点システム，各ベンダシステムを主として行い、エンドユーザクライアントへは運用監視サーバ，メールサーバが、主として配信を行う。
【０１３４】
ここで、マルチベンダシステム監視通報サーバ１５とマルチベンダシステム７００との接続および障害認知方式について説明する。
【０１３５】
マルチベンダシステム監視通報サーバ１５は、マルチベンダシステム７００の設置場所の近くに設置され、マルチベンダシステム７００の各構成装置と接続される。つまり、サーバＶ７０２とサーバＷ７０６とサーバＸ７１０とサーバＹ７１１とサーバＺ７１２と付帯設備７１４とマルチベンダシステム監視通報サーバ１５とを接続し、マルチベンダシステム監視通報サーバ１５は異なるインターフェイスにて発信される信号をインターフェイス変換装置１６にて変換し、障害信号発生を認知する。
【０１３６】
信号変換と認知をするための方式は、一つ目として、サーバＶ７０２の場合は、ＳＶＰａ７０３１にて障害を認知し、それをモデムａ７０４１にて公衆回線で通報する。このとき、ＳＶＰａ７０３１の持つ機能として障害情報の通報先が一度に複数箇所の設定（例えば、１次通報先としてベンダシステム７０５、２次通報先としてマルチベンダシステム監視通報サーバ１５）可能で且つお互いの通信プロトコルが合致する場合には、サーバＶ７０２のＳＶＰａ７０３１のモデムａ７０４１から公衆回線７０１を介し、１次通報先としてベンダシステム７０５に通報し、２次通報先としてマルチベンダシステム監視通報サーバ１５のモデムｃ７０４３に接続してマルチベンダシステム監視通報サーバ１５に通報し、１度に２箇所に順次に障害情報を発信伝達することにより、ベンダシステム７０５とマルチベンダシステム監視通報サーバ１５は障害を認識する。マルチベンダシステム監視通報サーバ１５は障害情報を外部（例えば、プライマリ保守者端末７０９等）に通知する。
【０１３７】
二つ目として、サーバＷ７０６の場合は、サーバＷ７０６のＳＶＰｂ７０３２に通報先が１箇所しか設定できないとき或いは通報先が２箇所設定できるがお互いの通信プロトコルが合致しないときには、ＳＶＰｂ７０３２とモデムｂ７０４２間のインターフェイスケーブルであるＤＴＥケーブルをマルチベンダシステム監視通報サーバ１５において中継する。このとき、モデムｂ７０４２のＤＴＥインターフェイス信号のうちのＲＳ送信要求信号をＲＳ信号感知部ａ７０７１で感知し障害発生をマルチベンダシステム監視通報サーバ１５は知る。この場合の通報先はベンダシステム７０５の１箇所であり、マルチベンダシステム監視通報サーバ１５は障害のメッセージ内容を知り得なく、ＲＳ送信要求信号がオンとなったことのみを感知するだけであるため、マルチベンダシステム監視通報サーバ１５にて、該当装置の何らかの障害の通報が開始された事象を表現する障害メッセージを付加し、外部（例えば、プライマリ保守者端末７０９等）に通知する。
【０１３８】
三つ目として、サーバＸ７１０の場合は、サーバＸ７１０がＳＶＰを有していないが、サーバＸ７１０のオペレーティングシステムの機能により、障害情報をモデムｅ７０４５にて公衆回線７０１に接続し、オペレーティングシステムの通信ソフトウェアにより通報する場合である。この場合は、サーバＸ７１０のオペレーティングシステムが障害を感知し、それをモデムｅ７０４５により公衆回線７０１にて通報する構成であり、オペレーティングシステムの持つ機能として障害情報の通報先が１度に複数の設定（例えば、１次通報先としてベンダシステム７０５、２次通報先としてマルチベンダシステム監視通報サーバ１５）可能な場合で且つ通信プロトコルが合致する場合である。この場合は、サーバＸ７１０のモデムｅ７０４５から公衆回線７０１を介し、１次通報先としてベンダシステム７０５に通報し、２次通報先としてマルチベンダシステム監視通報サーバ１５のモデムｃ７０４３に接続してマルチベンダシステム監視通報サーバ１５に通報し、ソフトウェア通報として、１度に２箇所に順次に障害情報を発信伝達することにより、一つ目と同様に、ベンダシステム７０５とプライマリ保守者端末７０９は障害を認識する。
【０１３９】
四つ目として、サーバＹ７１１の場合は、サーバＹ７１１のソフトウェア通報の通報先が１箇所しか設定できないとき或いは通報先が２箇所設定できるがお互いの通信プロトコルが合致しないときには、サーバＹ７１１とモデムｄ７０４４間のインターフェイスケーブルであるＤＴＥケーブルを、マルチベンダシステム監視通報サーバ１５において中継する。このとき、モデムｄ７０４４のＤＴＥインターフェイス信号のうちのＲＳ送信要求信号をＲＳ信号感知部ｂ７０７２で感知し障害発生をマルチベンダシステム監視通報サーバ１５は知る。このときの通報先はベンダシステム７０５の１箇所であり、マルチベンダシステム監視通報サーバ１５は障害内容を知り得なく、ＲＳ送信要求信号がオンとなったことのみを感知するだけであるため、マルチベンダシステム監視通報サーバ１５にて、該当装置の何らかの障害の通報が開始された事象を表現する障害メッセージを付加し、外部（例えば、プライマリ保守者端末７０９等）に通知する。
【０１４０】
五つ目として、ザーバＺ７１２やクライアントなどの機器が、少しのインテリジェント機能しか持たず、例えば制御シーケンサによるＲＳ２３２Ｃシリアルインターフェイスなどを有しているときは、サーバＺ７１２から発信される装置異常のメッセージ信号をマルチベンダシステム監視通報サーバ１５のインターフェイス変換装置１６へ伝え、マルチベンダシステム監視通報サーバ１５にて、該当装置の何らかの障害の通報が開始された事象を表現する障害メッセージを付加し、外部（例えば、プライマリ保守者端末７０９等）に通知する。
【０１４１】
六つ目として、付帯設備７１４の場合の障害通知信号は、コンピュータ室内の環境制御監視盤などに装備されているプログラムシーケンサからのＲＳ２３２Ｃシリアルインターフェイス信号７１３と、障害時は接点を閉じ正常時は接点開放するアラーム接点信号７１６とを、マルチベンダシステム監視通報サーバ１５のインターフェイス変換装置１６に接続し、それぞれにの信号に対応する障害メッセージをマルチベンダシステム監視通報サーバ１５にて付加し、外部（例えば、プライマリ保守者端末７０９等）に通知する。
【０１４２】
上記で説明した複数の障害通報先の設定が可能な場合、通報の伝達先の優先順位は、障害保守体制、サーバ装置の処理内容の重要度などの必要に応じ、マルチベンダシステム監視通報サーバ１５かベンダシステム７０５のどちらが先かを決める。
【０１４３】
また、上記のサーバ装置等は、ＬＡＮ７１５に対するインターフェイスを有しているので、ＬＡＮ７１５経由にてマルチベンダシステム監視通報サーバ１５に障害通報情報を伝達する手段を各サーバ装置が有し、ＬＡＮ７１５経由で障害情報をマルチベンダシステム監視通報サーバ１５に伝えるようにしてもよい。
【０１４４】
また、逆に、マルチベンダシステム監視通報サーバ１５から各サーバ装置に対して正常動作の確認を行うため、マルチベンダシステム監視通報サーバ１５がネットワーク経由のリモートコマンドを用いたプログラムによるヘルスチェックを行う手段を有するようにしてもよい。
【０１４５】
また、各サーバ装置からシステムコンソール７１９あるいは運用監視サーバ７２０あるいはメールサーバ７１８に、障害関係のメッセージ、例えば「ＤＡＮＧＥＲ」「ＡＬＡＲＴ」「ＣＡＵＴＩＯＮ」「ＷＡＲＮＩＮＧ」「ＡＴＴＥＮＴＩＯＮ」「ＥＲＲＯＲ」「ＰＡＮＩＣ」「ＤＯＷＮ」といった障害用語を含むメッセージを出力した場合に、これらの用語を検出して障害メッセージをＬＡＮ７１５を介してマルチベンダシステム監視通報サーバ１５あるいはプライマリ保守者端末７０９に伝達する手段を、各サーバ装置あるいは運用監視サーバ７２０あるいはメールサーバ７１８あるいはシステムコンソール７１９に持たせるようにしてもよい。
【０１４６】
次に、本発明の実施の形態の動作について、図面を用いて詳細に説明する。
【０１４７】
最初に、図５〜図７を参照して、障害監視して通報する（障害を監視してプライマリ保守者やベンダに通報する）時の動作について説明する。
図６および図７は、障害監視して通報する時の動作の流れを示す図である。
【０１４８】
図６を参照すると、障害監視通報の動作は、システムの各サーバ機器と付帯設備機器との不規則に起こる障害発生（ステップＳ８０２）を、常時モニターする。
【０１４９】
先ず、サービスプロセッサ（ステップＳ８０３）を持ったサーバ機器に関して、サービスプロセッサ（ステップＳ８０３）の機能が働くような障害が発生したときは、サーバ装置自身が停止する可能性が高いため、ＬＡＮ７１５経由やインターネット７０８経由での通報は出来ないこととなり、モデムａ７０４１〜モデムｅ７０４５による接続にて公衆回線７０１により、ベンダシステム７０５あるいはマルチベンダシステム監視通報サーバ１５あるいはプライマリ保守者端末７０９あるいは関係する保守拠点システム７１８などに障害情報を通報する。
【０１５０】
通報時のサービスプロセッサ（ステップＳ８０３）の機能は、ハードウェアそのものに依存しているため、各ベンダ独自の仕様の場合が多い。プライマリ保守者がサーバ機器を提供したベンダに所属した（ステップＳ８１３のはい）場合は、その仕様として、当然サービスプロセッサ（ステップＳ８０３）の障害通報のための通信プロトコルは合致（ステップＳ８０９のはい）するので、ベンダシステム７０５およびマルチベンダシステム監視通報サーバ１５などの複数箇所に通報する。あるいは、プライマリ保守者がサーバ機器を提供したベンダに所属しなくても、サービスプロセッサ（ステップＳ８０３）の障害通報のための通信プロトコルが合致したとき（ステップＳ８０９のはい）は、サービスプロセッサ（ステップＳ８０３）の機能として公衆回線のダイヤル先の２箇所以上に順次接続つまり複数通信可能（ステップＳ８１１のはい）の場合には、ベンダシステム７０５およびマルチベンダシステム監視通報サーバ１５などの複数箇所に通報する。このとき、プライマリ保守者がベンダに所属する（ステップＳ８１３のはい）場合には、障害情報内容は、そののまま解読できるため、何も編集せず（ステップＳ８１４）に、障害メッセージ送信（ステップＳ８２０）し、プライマリ保守者端末７０９に通報（ステップＳ８１８）する。
【０１５１】
次に、サービスプロセッサ（ステップＳ８０３）の障害通報のための通信プロトコルが合致しない（ステップＳ８０９のいいえ）とき、つまりベンダ独自の仕様のプロトコルにて障害通報の通信をおこなっているとき、或いはサービスプロセッサ（ステップＳ８０３）の障害のダイヤル通報先を１箇所しか設定できないとき、或いは運用とか保守体制の制限などにて通報先を１箇所（例えば、ベンダ）しか設定しないとき、などにより複数通報不可能（ステップＳ８１１のいいえ）の場合には、モデムｂ７０４２かモデムｄ７０４４に対するＤＴＥインターフェイス信号のなかのＲＳ送信要求信号をマルチベンダシステム監視通報サーバ１５にて感知（ステップＳ８１２）する。つまり、送信要求信号がオンとなったことのみを感知するので、すなわち障害に関する何らかの通報の通信が開始されたことのみが判るだけであるので、マルチベンダシステム監視通報サーバ１５にて障害メッセージ変換・付加（ステップＳ８１７）を行う。障害メッセージ変換・付加（ステップＳ８１７）において、マルチベンダシステム監視通報サーバ１５にて感知したサービスプロセッサ（Ｓ８０３）のモデムｂ７０４２あるいはモデムｄ７０４４のＲＳ送信要求信号がオンの事象を、どのベンダのどの装置のモデム（つまり、モデムｂ７０４２かモデムｄ７０４４か）が通報の送信を開始したかが判別できる障害のメッセージ（例えば、「ＡＡ社のＢＢ装置にて障害通報を開始しました。」（ステップＳ８１５）のようなメッセージ）に変換し、障害メッセージ送信（ステップＳ８２０）として、プライマリ保守者端末７０９に通報（ステップＳ８１８）する。当然、ベンダシステム７０５に対しては、各モデムを介し、障害は自動通報される。
【０１５２】
次に、プライマリ保守者がベンダに所属しない（ステップＳ８１４のいいえ）ときは、サービスプロッセッサ（ステップＳ８０３）の障害通報のプロトコルが一致（ステップＳ８０９のはい）し、複数通報可能（ステップＳ８１１のはい）の場合であるので、通報先のひとつとしてマルチベンダシステム監視通報サーバ１５に、サービスプロセッサ（ステップＳ８０３）からの障害メッセージをおくり、マルチベンダシステム監視通報サーバ１５にて、障害メッセージがどのベンダのメッセージであるかの判別手段により、例えば「ＣＣ社のＤＤ装置にてメモリ障害発生。」（ステップＳ８１６）とのメッセージを付加する障害メッセージ変換・付加（ステップＳ８１７）を行い、障害メッセージ送信（ステップＳ８２０）にて、プライマリ保守者端末７０９に通報（ステップＳ８１８）をする。この場合は、複数通報可能（ステップＳ８１１のはい）であるので、サービスプロセッサ（ステップＳ８０３）からの障害通報メッセージは、装置を提供しているベンダシステム７０５にも通報（ステップＳ８１９）される。
【０１５３】
次に、ソフトウェアメッセージ（ステップＳ８０４）による障害の通報が行われる場合について説明する。
【０１５４】
ソフトウェアメッセージ（ステップＳ８０４）通報とは、ハードウェア障害を主体とするサービスプロセッサ（ステップＳ８０３）が関与しない障害の場合あるいはサーバ機器がサービスプロセッサ（ステップＳ８０３）を有しない場合に、サーバ機器のオペレーティングシステムの基本機能の通信ポートにモデムｅ７０４５を接続して公衆回線７０１を介し、障害メッセージの自動通報を行う場合である。これは、例として、ソフトウェアの不具合要因にてサーバシステムがダウンした場合にて通信機能には不具合の影響がおよばなかった場合、システムの周辺処理装置のアレイディスクのひとつが故障し縮退状態となった場合、サーバ間のオンラインネットワーク通信が出来なくなった場合、などがある。このモデムｅ７０４５通信にてのソフトウェアメッセージ（ステップＳ８０４）による障害通報は、サービスプロセッサ（ステップＳ８０３）の機能を、オペレーティングシステムの基本部分が働いて代替し、サービスプロセッサ（ステップＳ８０３）と同様の処理動作を行う場合であり、このソフトウェア通報可（ステップ８１０のはい）の場合は、前述したサービスプロセッサ（ステップＳ８０３）と同様に、プロトコル合致（ステップＳ８０９）、複数通報可能（ステップＳ８１１）、プライマリ保守者はベンダに所属（ステップＳ８１３）の流れにて処理する。
【０１５５】
ソフトウェア通報不可の場合（ステップＳ８１０のいいえ）、つまりサーバ機器が障害の自動通報を行うための専用のモデムによる公衆回線７０１を介して通信する機能を持たない場合は、サーバ機器がオンラインアクセスのためのＬＡＮを介する通信、すなわちメール通信機能を使用し通報する。
【０１５６】
そのメール発信可（ステップＳ８０８のはい）の場合は、メール機能を使用し障害をマルチベンダシステム監視通報サーバ１５に配信する。
【０１５７】
メール発信不可（ステップＳ８０８のいいえ）の場合は、その機器自身にて何も障害に関するメッセージを発信出来ないことであるので、通報機能のない機器（ステップＳ８０５）と同様に障害通報に関して処理をする。
【０１５８】
障害発生（ステップＳ８０２）が通報機能のない機器（ステップＳ８０５）にて起こった場合、例えばシステムの付帯設備７１２からの信号が接点信号／ＲＳ２３２Ｃ（ステップＳ９０２のはい）となっている場合（例えば、無停電電源装置の故障信号あるいは空調機の故障信号あるいは環境異常監視のためのコンピュータが設置されている部屋の温度が敷居値の上限を越えた場合の室温上限検出センサーからの信号）、その信号「ＯＮ」となったことをマルチベンダシステム監視通報サーバ１５にて検知（ステップＳ９０３）し、入力接点信号のインターフェイス変換装置１６の端子盤の接続する端子番号を監視する装置と対応させ、例えば端子番号０１には無停電電源装置からの接点信号を接続し、障害メッセージとして「ＥＥ社の無停電電源装置ＦＦにて重障害が発生しました。」とのメッセージを付加し、温度上限感知センサーからの接点信号であれば、「ＧＧ室の温度上限アラームを感知しました。」と言った障害メッセージ付加（ステップＳ９０１）をする。
【０１５９】
また、接点信号／ＲＳ２３２Ｃでない（ステップＳ９０２のいいえ）場合、すなわちシステム機器にてサービスプロセッサ（ステップＳ８０３）を持たなく且つソフトウェア通報不可（ステップＳ８１０のいいえ）で且つ障害状況を自分自身で配信しないがオンラインにてＬＡＮに接続されている場合は、マルチベンダシステム監視通報サーバ１５からプログラムによるリモートコマンドを使用し正常動作中であるかどうかのヘルスチェック（ステップＳ９０４）を行い、その状況により、例えば「ＦＦ社のＧＧサーバの応答が有りません。」（ステップＳ９０５）との障害メッセージを付加する。
【０１６０】
次に、ソフトウェアメッセージ（ステップＳ８０４）にて、障害通報専用のモデムによるソフトウェア通報は不可（ステップＳ８１０のいいえ）にて、自分自身で障害をメール発信可（ステップＳ８０８のはい）の場合は、必要に応じマルチベンダシステム監視通報サーバ１５にて障害データに、ベンダの区別をするアイテムを付けるなどのメッセージを編集（ステップＳ９０７）する。
【０１６１】
このマルチベンダシステム監視通報サーバ１５による、メッセージを編集（ステップＳ９０７）したもの、および障害メッセージ付加（ステップＳ９０１）したものが、自動通報専用のモデムによる公衆回線７０１を介し、自動通報が必要な場合（ステップＳ９０８のはい）、たとえば付帯設備７１２の空調機が故障し完全に停止してしまい、室温上昇にてシステム稼働に影響がでるほど重大な場合、あるいはシステムのネットワーク基幹をなすネットワーク装置の電源盤故障にて、オンライン通信が不能となった場合、あるいはメール配信では通報先が認知するのが遅れる場合などのときは、マルチベンダシステム監視通報サーバ１５内の障害自動通報装置１７にて障害通報をする（ステップＳ９０９）。
【０１６２】
このようにして、障害の監視と感知、および通報を行う。
【０１６３】
次に、図８を用いて、障害を監視し感知して通報した後における障害状況の伝達、すなわち被害状況や影響範囲や処理経過や回復見込み等を伝達する時の動作について説明する。
図８は、障害状況の伝達時の動作の流れを示す図である。
【０１６４】
ここでは、図６と図７にての障害監視通報（ステップＳ８０１）された障害情報を関係の各方面に配信する方法について述べる。
【０１６５】
サービスプロセッサ発信（ステップＳ１００２のはい）の場合で、サービスプロッセサからの障害通報がマルチベンダシステム監視通報サーバ１５に伝達可（ステップＳ１００４のはい）の場合は、マルチベンダシステム監視通報サーバ１５に伝達（ステップＳ１００６）とベンダシステム７０５に伝達（ステップＳ１０１１）とをする。
【０１６６】
また、サービスプロセッサ発信機能が無い（ステップＳ１００２のいいえ）場合にても、オペレーティングシステムの機能としてソフトウェア発信が可能（ステップＳ１００３のはい）で、障害通報がマルチベンダシステム監視通報サーバ１５に伝達可（ステップＳ１００４のはい）の場合は、障害情報をマルチベンダシステム監視通報サーバ１５に伝達（ステップＳ１００６）と、ベンダシステム７０５に伝達（ステップＳ１０１１）とをする。
【０１６７】
障害情報を通信プロトコルを介してマルチベンダシステム監視通報サーバ１５に伝達が出来ない場合（ステップＳ１００４のいいえ）は、マルチベンダシステム監視通報サーバ１５にて、モデムのＤＴＥ信号の内のＲＳ送信要求信号をモニターして感知し（ステップＳ１００５）、通信プロトコルを持たない場合、すなわちサービスプロセッサ発信が出来なく（ステップＳ１００２のいいえ）且つソフトウェア発信が不可能（ステップＳ１００３のいいえ）の場合には、例えば、付帯設備機器接点信号を感知し（ステップＳ１００７）、マルチベンダシステム監視通報サーバ１５にて障害を認識する（ステップＳ１００８）。
【０１６８】
そして、マルチベンダシステム監視通報サーバ１５は、マルチベンダシステム監視通報サーバ１５の持つ障害自動通報装置１７と障害メールサーバ１８とにより、障害メッセージを、プライマリ保守者とシステム管理者と使用者と各管理関係部署に伝達（ステップＳ１００９）と、エンドユーザクライアント７１７に伝達（ステップＳ１０１０）と、ベンダシステム７０５等に伝達（ステップＳ１０１１）とを行う。
【０１６９】
また、マルチベンダシステム監視通報サーバ１５が自動的に検知し通報・配信できないメッセージは、例えば、保守作業の経過、障害復旧予想時間、障害の被害状況、障害復旧アナウンス、障害にて発生した制限事項など（図１４に示すメッセージ内容等）、プライマリ保守者がプライマリ保守者端末７０９から配信内容を入力し、マルチベンダシステム監視通報サーバ１５のメール機能を経由して電子メールにて配信する。
【０１７０】
また、状況と配信メッセージ内容により、システム管理者が運用監視サーバ７２０にて配信内容を入力し、電子メールにて配信する。
【０１７１】
そして、プライマリ保守者は、障害全てを統括し障害の受付（ステップＳ１０１４）と、障害復旧（ステップＳ１０１５）の状況確認（ステップＳ１０１７）をし、障害処理の経過を監視しその情報提供と質問に対応し（ステップＳ１０１３）、状況をメール配信とウェブに掲載する（ステップＳ１０１６）。
【０１７２】
このようにして、図８の障害状況伝達方法により、関連者に障害の状況を通知する。
【０１７３】
次に、図９〜図１２を用いて、障害保守の処理動作について説明する。
図９は、障害保守の処理動作の全体の流れを示す図である。
図１０は、障害処理の第１の方法の動作の流れを示す図である。
図１１は、障害処理の第２の方法の動作の流れを示す図である。
図１２は、障害処理の第３の方法の動作の流れを示す図である。
【０１７４】
図８におけるプライマリ保守者が障害の全てを統括し障害の受付をする（ステップＳ１０１４）は、図９におけるプライマリ保守者が障害の受付をする（ステップＳ１１０１）に対応し、障害を受付けて、障害処理開始（ステップＳ１１０２）をする。
【０１７５】
ここで、障害保守の形態、すなわちシステムのサーバ機器、および付帯設備機器がＯＥＭ製品・販売代理・保守委託・保守体制などの関係とメーカー・保守会社の関係により、障害処理の方法の１例として３つに大別したものを述べる。
【０１７６】
その第１として、プライマリ保守者が障害処理の全てに対応する（ステップＳ１１０３のはい）場合である。例えば、保守会社がメーカー・ベンダのグループ会社に属し、オペレーティングシステム・サービスプロセッサ・保守技術者が、自社製品として扱えるシステムのサーバ機器・付帯設備機器の障害処理をする場合、およびＯＥＭ製品にて、プライマリ保守者が保守技術・保守部品の全てをメーカーから供給を受けられる場合の障害処理方法である。
【０１７７】
第２として、プライマリ保守者が障害処理の全てに対応出来なくて（ステップＳ１１０３のいいえ）、プライマリ保守者にて障害処理の一部に対応する（ステップＳ１１０４のはい）場合である。例えば、マルチベンダシステムのオペレーティングシステムが共通であり、プライマリ保守者が運用操作・障害状況判断が、できエラーログ等のデータの収集操作が可能な場合であり、保守技術・保守部品供給・部品交換をベンダ・メーカーが、セカンダリ以降の保守者として対応する場合の障害処理方法である。
【０１７８】
第３として、プライマリ保守者にて障害処理のほとんどが出来ない場合である。つまり、プライマリ保守者にて障害処理の一部にも対応出来ない場合（ステップＳ１１０４のいいえ）は、プライマリ保守者は障害処理をセカンダリ以降の保守者に渡す（ステップＳ１１０５）。例えば、マルチベンダシステム機器が特異なオペレーティングシステムにて動作している場合、および付帯設備は保守会社・保守部門が対応する場合の障害処理方法である。
【０１７９】
上述の第１と第２と第３の障害処理の方法については、それぞれ図１０と図１１と図１２を参照して後述する。
【０１８０】
障害処理が完了したら、プライマリ保守者はテストランジョブ等で障害の完了を確認し（ステップＳ１１０６）、運用業務再開の確認・操作をし（ステップＳ１１０７）、障害処理の結果、つまり障害の現象・原因・処置をマルチベンダシステム機器の使用者に電子メールにて報告し（ステップＳ１１０８）、障害による被害の報告（ステップＳ１１０９）と障害の修復状況を報告し（ステップＳ１１１０）、障害処理を完了する（ステップＳ１１１１）。なお、プライマリ保守者端末７０９にリモート起動実行手段を設け、テストランジョブはプライマリ保守者端末７０９からリモート起動実行してもよい。また、各種の報告は、プライマリ保守者端末７０９から入力作成し、マルチベンダシステム監視通報サーバ１５を経由して電子メール等で発信する。
【０１８１】
図１０を用いて、第１の処理方法の詳細について説明する。図１０は、前述した障害処理方法を３つに大別した第１の処理方法の詳細の１例であり、プライマリ保守者にて障害の全ての処理を行う方法（ステップＳ１２０１）を示し、図１０の左半分をプライマリ保守者の作業（ステップＳ１２０２）の流れ図とし、右半分をセカンダリ以降の保守者の作業（ステップＳ１２０３）の流れ図として、障害処理方法を示したものである。図１０はプライマリ保守者にて障害の全ての処理を行う方法（ステップＳ１２０１）であり、プライマリ保守者の作業（ステップＳ１２０２）に各障害処理ステップが全て含まれ、セカンダリ以降の保守者の作業（ステップＳ１２０３）は、何もないことを示している。
【０１８２】
図１０を参照すると、プライマリ保守者は、障害の発生をプライマリ保守者端末７０９にて通知され、障害発生を受付け、障害発生したシステムサーバ機器の業務内容と障害事象内容により、運用続行優先（ステップＳ１２０５のはい）の場合、再立ち上げ手段により再立ち上げ操作（ステップＳ１２０６）を行う。再立ち上げ操作には、システムサーバ機器のオペレーティングシステムの機能にて自動的に再立ち上げ動作が行われる場合も含む。
【０１８３】
手動あるいは自動にて再立ち上げが成功し、運用業務が続行した場合は、間欠障害（ステップＳ１２０７のはい）とみなし、ここは、運用続行優先の場合であるから業務を続行する。その障害の原因を究明し故障・不良に対する調査・処置のためのマシンタイムを確保し（ステップＳ１２０９）、運用停止の条件が整ったときに運用を停止する。なお、運用続行優先（ステップＳ１２０５のはい）で間欠障害（ステップＳ１２０７のはい）の場合は、運用停止の条件が整ったとき以後にしか障害処理作業を行えないので、試験・診断プログラムの実行による障害解析はすぐには出来ないので、運用状態にて採取可能なもののみのログ採取を行う。
【０１８４】
運用続行優先でない（ステップＳ１２０５のいいえ）場合は、どのような障害であろうとも一旦システムサーバ機器を停止し、障害発生の原因を究明する処置を優先する場合であり、たとえ自動的に再立上げ動作が行われても、運用停止手段により運用停止操作（ステップＳ１２０８）を行う。また、自動・手動にての再立ち上げ操作（ステップＳ１２０６）にて、障害が回復しなかった場合、および、再立ち上げしても短時間にて、障害が再発する場合は間欠障害ではなく（ステップＳ１２０７のいいえ）固定障害であるとし、障害処理を行うため運用停止操作（ステップＳ１２０８）をする。
【０１８５】
自動通報に障害エラーログが付加されて（ステップＳ１２１０のはい）通報される機能があるシステムサーバ機器の場合は、すぐに技術支援部門にての保守技術者を確保（ステップＳ１２１２）してログ解析（ステップＳ１２１３）、あるいはプライマリ保守者自身にてログ解析（ステップＳ１２１３）を行う。
【０１８６】
自動通報に障害エラーログが付加されない（ステップＳ１２１０のいいえ）場合は、ログ収集手段により障害エラーログを収集（ステップＳ１２１１）する。
【０１８７】
ログ解析手段によるログ解析（ステップＳ１２１３）にて故障個所が判明した（ステップＳ１２１４のはい）場合は、部品手配手段により故障部品の手配（ステップＳ１２１６）をする。
【０１８８】
故障個所が判明しなかった（ステップＳ１２１４のいいえ）場合は、障害事象やエラーログなどにより、故障の原因と予測される部品を確定（ステップＳ１２１５）し、その部品を手配する（ステップＳ１２１６）。
【０１８９】
運搬（ステップＳ１２１７）された部品を受け取り、故障部品、あるいは故障予測部品を交換（ステップＳ１２１８）する。
【０１９０】
また、プライマリ保守者端末７０９を使用して障害処理状況、復旧見込みなどの障害処理の経過情報を作成し、をシステム管理者とエンドユーザ等に適時、電子メール等で報告する（ステップＳ１２０４）。
【０１９１】
上記で説明した図１０と以降で説明する図１１および図１２のステップ数とステップ種別は同じである。つまり、図１０のステップＳ１２０５〜Ｓ１２１８は、図１１のステップＳ１３０５〜Ｓ１３１８、図１２のステップＳ１４０５〜Ｓ１４１８にそれぞれ対応して同一であり、各ステップの位置がプライマリ保守者の作業（ステップＳ１２０２・Ｓ１３０２・Ｓ１４０２）とするのか、セカンダリ以降の保守者の作業（ステップＳ１２０３・Ｓ１３０３・Ｓ１４０３）となるかが異なる。
【０１９２】
図１１を用いて、第２の処理方法の詳細について説明する。図１１は、プライマリ保守者にて障害の一部の処理を行う方法（ステップＳ１３０１）であり、プライマリ保守者の作業（ステップＳ１３０２）として、マルチベンダ機器で構成されたシステムの全体を把握したプライマリ保守者の主導による障害処理に関して、システム運用操作を主体とした操作を行う。すなわち、システムサーバ機器の運用に関係する操作、すなわち再立ち上げ操作（ステップＳ１３０６）と運用停止操作（ステップＳ１３０８）と調査マシンタイム確保停止（ステップＳ１３０９）とエラーログの収集（ステップＳ１３１１）を行う。セカンダリ以降の保守者の作業（ステップＳ１３０３）は、主にハードウェアの故障原因の解明と処置をすること、すなわち障害状況とエラーログを収集し障害内容を把握したうえで、故障の詳細ログ解析（ステップＳ１３１３）と部品手配（ステップＳ１３１６）と部品運搬（ステップＳ１３１７）と部品交換（ステップＳ１３１８）とを行う。
【０１９３】
そして、プライマリ保守者は電子メール等で適時セカンダリ以降の保守者に障害処理状況を確認し、その経過の報告（ステップＳ１３０４２）を受信し、プライマリ保守者の状況判断を加え、障害処理状況、復旧見込みなどの障害処理の経過をシステム管理者とエンドユーザ等に適時、電子メール等で報告する（ステップＳ１３０４１）。
【０１９４】
図１２を用いて、第３の処理方法の詳細について説明する。図１２は、プライマリ保守者が障害処理をセカンダリ以降の保守者に渡す方法（ステップＳ１４０１）であり、プライマリ保守者の作業（ステップＳ１４０２）は、マルチベンダシステム機器の管理者と使用者への窓口としてのみであり、セカンダリ以降の保守者の作業（ステップＳ１４０３）は、運用に関する操作とログ収集・解析からハードウェアの部品交換作業までをセカンダリ以降の保守者が行う。
【０１９５】
そして、プライマリ保守者は適時セカンダリ以降の保守者に障害処理状況を確認し、その経過の報告（ステップＳ１４０４２）を受け、プライマリ保守者の状況判断を加え、障害処理状況、復旧見込みなどの障害処理の経過をシステム管理者とエンドユーザ等に適時、報告する（ステップＳ１４０４１）。
【０１９６】
これは、特殊機器および付帯設備から成るシステムに関するプライマリ保守者の障害処理の作業の場合の１例である。
【０１９７】
なお、障害処理の方法を上述のように３つに大別して説明したが、障害処理の各ステップを、プライマリ保守者とセカンダリ以降の保守者とのどちらが行うかは、システムサーバ機器・付帯設備機器の保守体制・保守技術の特性により適宜分担するものとする。例えば、アレイディスクのディグレード故障は、部品供給のみセカンダリ保守者が行う、すなわち部品手配（ステップＳ１３１６）と部品運搬（ステップＳ１３１７）とをセカンダリ保守者が行い、部品交換（ステップＳ１３１８）はプライマリ保守者が行う、などである。
【０１９８】
上述した障害処理方法の図１０と図１１と図１２のステップ種別の内の、ログ収集（ステップＳ１２１１・Ｓ１３１１・Ｓ１４１１）を障害ダンプデータ収集とし、ログ解析（ステップＳ１２１３・Ｓ１３１３・Ｓ１４１３）をダンプデータ解析とし、部品手配（ステップＳ１２１６・Ｓ１３１６・Ｓ１４１６）をソフトウェア不具合に対するパッチ修正物件作成依頼とし、部品運搬（ステップＳ１２１７・Ｓ１３１７・Ｓ１４１７）をパッチ修正物件入手とし、部品交換（ステップＳ１２１８・Ｓ１３１８・Ｓ１４１８）をパッチ修正物件適用とすると、ソフトウェア障害に対する処理方法となる。
【０１９９】
次に、図１３を用いて、プライマリ保守者がマルチベンダシステム機器の障害を感知、認識し、受付をしたとき、インターネットを介して関係各方面に伝達する方法の１例を述べる。
図１３は、障害情報を伝達する方法の例を示す図である。
【０２００】
プライマリ保守者はプライマリ保守者端末７０９を介してマルチベンダシステム機器の障害を感知、認識し、受付をしたとき、プライマリ保守者端末７０９でマルチベンダシステム形態絵図に対する吹き出し記述およびマルチベンダシステム機器の状態一覧を作成し、マルチベンダシステム監視通報サーバ１５にウェブ掲載を行う。
【０２０１】
図１３を参照すると、例えばＢ社製ベクトル分散メモリ機２０２に障害ダウンが発生し停止た場合に、吹き出し記述にて「ダウン中」であることを示すダウン停止表示１５０１を行う。また、例えばＣ社製スカラ分散メモリ機２０３が業務事情やソフトウェア更新にてエンドユーザに対し使用制限の必要なときなどにおいて、吹き出し記述にて「運用制限中」であること示す運用制限中表示１５０３を行う。また、例えばＫ社製空調機２０５が点検中である場合に、同様に吹き出し記述にて「点検中」であることを、点検中表示１５０５にて示す。更に、機器状態選択ウインドウ１５０２においてもマルチベンダシステム機器の状態一覧表示を行う。
【０２０２】
このようにして、障害ダウン中、点検中、２重化機器の片系停止にて予備系機器に切り替わり中、システム機能の一部縮退中、一部業務都合やソフトウェア更新のためのクローズ使用中、ソフトウェア障害による一部運用形態制限中などを、システム形態絵図に対する吹き出し記述と機器状態選択ウインドウ１５０２でインターネットウェブ上に掲示するとともに、必要部署に掲示の内容の概要を電子メール配信１５０８にて状況の案内をする。
【０２０３】
マルチベンダシステム機器の利用者は、ウェブ表示をアクセスし、障害などの状況を見て、必要があれば、状態表示の吹き出しをマウスでクリック、あるいは機器状態選択ウインドウ１５０２の状態欄をマウスでクリックして、詳細の確認を行う。
【０２０４】
例えば、「制限」状態であれば、制限表示ウインドウ１５０４を表示し、まず概要の掲題として、「システム機器状態表示  ２００２年」、機器名「ＣＳＰＭ」、状態「制限」、運用制限「開始日時」、「解除予定日時」、制限事項「ＣＳＰＭノード＃３５  システム更新作業のためクローズ運用」を掲示する。詳細タグ選択にて、制限内容詳細、業務更新内容、更新履歴、オペレーティングシステムのバージョンアップによる機能強化点、業務操作不備・不具合改良点などの関連情報を掲示する。
【０２０５】
また、「ダウン」状態であれば、ダウン表示ウインドウ１５０６を表示し、同じように掲題、機器名、そして状態「ダウン」、ダウンの「発生時刻」、「復旧予定時刻」、障害の事象「ハードウェア故障  メインメモリチェック発生・部品交換処置」のように掲示する。詳細タグ選択にて、詳細な現象・原因・処置などが判明次第掲示し、この機器の障害履歴・稼働率なども掲示する。また、システム機器ダウンによる被害ジョブと被害を受けた利用者も掲示して、利用者自身が、復旧作業を要するか否か、さらに業務全体の遅れ状況をも掲示する。
【０２０６】
また、「点検」状態であれば、点検表示ウインドウ１５０７を表示し、点検の「開始日時」、「完了予定日時」、点検内容「定期通常点検運用停止」のように掲示する。詳細タグ選択にて、年間点検スケジュール、緊急特別点検の案内、点検完了予定時間延長の案内などを掲示する。
【０２０７】
そして、これらの表示ウインドウが、掲示された時点、内容が更新された時点、各種の作業が完了した時点に、適宜、必要部署への電子メール配信１５０８を行う。
【０２０８】
次に、図１４を用いて、障害、更新、点検作業の発生・開始時、完了時における電子メール通報・報告メッセージの１例を示す。
図１４は、電子メールによる配信メッセージの例を示す図である。
【０２０９】
図１４を参照すると、電子メールによる障害関係通報・配信メッセージ例と電子メールによる制限関係案内・配信メッセージ例と電子メールによる点検工事関係予定・配信メッセージ例と電子メールによる作業完了関係通知・配信メッセージ例が示されている。
【０２１０】
電子メールによる障害関係通報・配信メッセージ例には、障害が自動通報される場合、マルチベンダ機器に対する対応方法の詳細内容として以下のものが例示されている。
【０２１１】
▲１▼「ＡＡ社のＢＢ装置にて障害通報を開始しました。」
ＳＶＰによる自動通報、あるいはソフトウェアによるシステムの通信制御部に接続された自動通報のモデムが起動されたことを、マルチベンダシステム監視通報サーバにてＲＳ信号にて感知し、モデムのＤＴＥケーブルの接続されたハードウェアのＤＴＥコネクタの位置、場所により、それは「ＡＡ社のＢＢ装置にて」であることがあらかじめ、マルチベンダシステム監視通報サーバに設定してあるので、その設定値をメッセージに構成する。そして、ＲＳ信号を感知しか出来ない装置の通報開始のみの文言、すなわち「障害通報が開始されました。」がメッセージに構成される。この場合、障害メッセージの内容は、通報装置（ＲＳ信号のみ）からでは、判別できないので、障害装置のコンソールメッセージの自動監視通報サーバからの障害メール、または、手動にてコマンドを入力し、コンソールログ、サーバ自身の内部構成情報などを、プライマリ保守者が検索し、その内容を調べる必要が生じる場合がある。
【０２１２】
▲２▼「ＣＣ社のＤＤ装置にてメモリ障害発生。」
ＳＶＰなどによる通報の通信プロトコルが、マルチベンダシステム監視通報サーバ間にて通信できる場合であり、障害通報をメッセージは、自動通報データの内容を編集したもので構成すればよい。
【０２１３】
▲３▼「ＥＥ社の無停電電源装置ＦＦに重障害が発生しました。」
無停電電源装置（ＵＰＳ）の故障をマルチベンダシステム監視通報サーバが接点信号として受けとり、接点信号接続端子の位置、番号にてから「ＥＥ社の無停電電源装置ＦＦに重障害が発生しました。」と言う事実が判別し、このメッセージを配信する。この時、ＵＰＳの重障害であるということは、ＵＰＳの機能として、バイパス運転に、自動的に切り替わる動作をするので、繰り替え動作が成功した場合には、成功した意味をもつ接点信号がマルチベンダシステム監視通報サーバに入力されるので、マルチベンダシステム監視通報サーバは、後述の制限関係▲８▼項で、「ＶＶ無停電電源装置の故障のため、商用電力バイパス運転となりました。」とのメッセージを配信する。
【０２１４】
▲４▼「ＧＧ室の温度上限アラームを感知しました。」
マシン室の温度が上昇し、室内温度条件検知警告センサーが働いた場合であり、この場合の障害通報先は自局内のマシン室の空調設備機器担当部署の（担当者の）携帯電話へ、あるいは、空調機器の保守担当会社（セカンダリ保守者の携帯電話）へ自動通報発信、あるいは通報メールを配信する。
【０２１５】
▲５▼「ＨＨ社のＩＩサーバの応答が有りません。」
自動通報機能が備わっていない装置、あるいはシステムがストール状態にて、通報機能が動作出来ない、働かない場合に、マルチベンダシステム監視通報サーバのＬＡＮなどを介してのヘルスチェックにて、障害が検出される場合の通報メッセージである。この場合は、サーバのストールは、システム使用者がサーバにアクセスしないかぎり、通常は、ストール状態の検知は出来ないため、一定時間周期にて、サーバが生きているかを、リモートコマンドで、応答があるかをマルチベンダシステム監視通報サーバがおこなっており（ヘルスチェック）、応答がなくなった場合、この障害通報を行う。サーバ利用者からの申告以前に、保守者と管理者が障害の認知ができる。
【０２１６】
▲６▼「ＪＪ社のＫＫアレイディスク装置が縮退しました。」
ＳＶＰ機能やオペレーティングシステムの機能にて検知され、通常は業務の運用には差し支えない。そのため、この場合は、プライマリ保守者の保守拠点や、ベンダー・メーカ（セカンダリ保守者に対し、部品（ディスクユニット）の手配、入手（搬送）依頼の通報メッセージを同時に配信する。
【０２１７】
▲７▼「ＬＬ社のＭＭ号機の空調機故障が発生しました。」
空調機故障であるので、故障の接点信号をマルチベンダシステム監視通報サーバが受け取り通報する。上述の▲４▼項と同様である。なお、空調機が一台だけの場合は、室温上限を感知すると、システムを自動的にシャットダウンし、装置の電源オフまで行う、自動運転機能を持たせてもよい。
【０２１８】
▲８▼「ただいま瞬時停電がありました。各マシンへの影響をお知らせ下さい。」瞬時停電の発生の事象は、ＵＰＳ装置の接点信号からマルチベンダシステム監視通報サーバが知ることができる。ＵＰＳを経由していない（商用電源直結の）装置、マシン室空調エアコン、空調機の室外機、ワークステーションなどの端末機に対し、被害がないかを確認をするための、通報メールである。停電時間が長引いてＵＰＳのバッテリーが消耗する場合を考慮し、システムの自動シャットダウン停止の自動運転機能を備えてもよい。
【０２１９】
電子メールによる制限関係案内・配信メッセージ例には、マルチベンダ機器に対する対応方法の詳細内容として、以下のものが例示されている。
【０２２０】
▲１▼「ＣＳＰＭノード＃３５  システム更新作業のため使用出来ません。」
複数設置されている分散型演算サーバの一部、一つの装置（ノード）のみを、（全ノードの停止の必要はなく）エンドユーザの使用の停止にて運用する場合、つまり、単体ノードの入力ジョブキューの変更、ファイルに使用の最大値の変更などを行う場合の通報メールである。分散型演算サーバの利用の促進、効率的利用のため、システム管理者、あるいはプライマリ保守者の提言にて、更新作業のために停止する場合である。
【０２２１】
▲２▼「ネットワーク変更作業のため外部との通信は出来ません。」
自局内、同一ネットワーク、同一敷地内にての情報を合わせ通報する。
【０２２２】
▲３▼「ＮＮサーバ装置更新のため一時的に使用できなくなります。」
機器の更新作業のためにシステム管理者、とプライマリ保守者協議し停止を案内する場合である。
【０２２３】
▲４▼「ＰＰサーバ調査停止ためログインはＱＱサーバ経由で行って下さい。」
二重化システムにおける、片系のみの運用をする場合の案内である。
【０２２４】
▲５▼「ＲＲファイルオーバーフロー発生、ＳＳ業務の不用ファイルを削除願います。」
マルチベンダシステム監視通報サーバにて、サーバのコンソールメッセージを感知、あるいは、サーバのオペレーティングシステムのオペレータコール機能にて、検知して案内をするものである。
【０２２５】
▲６▼「大容量ファイルへのエディッターをＴＴサーバで実行しないで下さい。」マルチベンダによる、複数多種のサーバを組み合わせ、システムを構成すると、運用方法にて各サーバの利用方法を限定する場合が生じるので、プライマリ保守者は、サーバの運用上の利用制限を知らないユーザー、あるいは、利用制限を無視してジョブを実行する利用者を監視して見つけ出し警告を与える場合のものである。
【０２２６】
▲７▼「ＵＵサーバへのアクセス異常は、装置リブートにて、回復しました。」
ＵＵサーバをファイルサーバとして説明する。ファイルサーバの持つファイルの一部の範囲（ドメイン）に演算サーバーよりアクセスすると、ディスクユニットのハードウェア障害ではなく、ファイルの論理不正（ソフトウェア管理ディレクトリ乱れ）にて、データの入出力エラーが発生し、Ｉ／Ｏエラーのメッセージがファイルサーバ装置のコンソールに出力される。このＩ／Ｏエラーのメッセージを、マルチベンダシステム監視通報サーバが感知し、プライマリ保守者とシステム管理者に自動通報、あるいは障害通報メールが配信される。プライマリ保守者とシステム管理者は、演算サーバーの運用停止、ファイルサーバへのアクセスの全面停止操作を行う。同時にセカンダリ保守者にも通報され、セカンダリ保守者からリモートアクセスにて、エラー状況のデータを収集し内容を把握する。プライマリ保守者は、エラー状況を判断し、コンソールからコマンドを入力してファイルサーバ装置のリブート操作（再立ち上げ）を行い、ファイルサーバへのアクセス異常は回復した。
【０２２７】
▲８▼「ＶＶ無停電電源装置の故障のため、商用電力バイパス運転となりました。」
上述の障害関係▲３▼項を参照。
【０２２８】
電子メールによる点検工事関係予定・配信メッセージ例には、マルチベンダ機器に対する対応方法の詳細内容として、以下のものが例示されている。
【０２２９】
▲１▼「定期点検停止：ＷＷ月の定期点検はＸＸ日（Ｙ曜日）です。」
プライマリ保守者がマルチベンダ構成のサーバ機器と設備機器との保守点検作業内容を協議し、システム管理者の承認のもとに、配信する。
【０２３０】
▲２▼「定期点検中にトラブル発生、点検完了時刻を予定より２時間延長します。」
プライマリ保守者は、システム定期点検中（計画停止中）作業にて、作業状況を把握、監視し点検完了予定時間を超えてしまう場合に配信する。
【０２３１】
▲３▼「ＺＺファイルサーバの点検完了後、ＮＦＳ機能を確認願います。」
プライマリ保守者は、各サーバの機能と作業内容を把握し、システム全体から見て、各サーバの作業者が通常の点検作業に加え、最終確認操作が必要な場合配信する。ファイルサーバを更新したので、各演算サーバからネットワークファイルのマウントなどが、正常であるかを確認して、運用再開をして欲しいとの案内の配信である。
【０２３２】
▲４▼「特別点検：ハードウェア改造のため今週の日曜日は臨時運用停止とします。」
プライマリ保守者は、通常の定期点作業時間内にては、完了出来ない特別な保守作業が発生した場合、ベンダ・メーカと協議し、システム管理者の承認のもと、配信する。
【０２３３】
▲５▼「定期点検停止のため新キューイングを抑止し全ジョブ終了状態にします。」
定期点検完了時に、実行中のジョブが中断出来ない、パッチ修正が作業が発生した場合、プライマリ保守者は、点検開始前の実行中のジョブをすべて実行完了状態にする、つまり、すべてのジョブは完了し、吐かせて、空にするための、操作と案内を配信する。
【０２３４】
▲６▼「ｂｂサーバ不具合は、本日の点検時に修正パッチを適用しました。」
プライマリ保守者は、自分自身、および、セカンダリ保守者の支援を得て、不具合を把握、管理し、運用制限などにて、障害発生を抑止していたものが、完全に解決したことと、あわせて、システム全体から見て、問題がないかを検証しパッチ修正による二次障害のないことを確認後、配信する。被害を受けた利用者に、修正が適切であったかを確認する。
【０２３５】
▲７▼「全館停電予告：ｃｃ月ｄｄ日は電気設備点検のため終日停電となります。」
プライマリ保守者は、計画停電の情報を、管理者、設備の部門から入手し、おもに、ベンダ・メーカに対し停電の案内を配信し、停電停止時の留意、制限事項を把握し、復電時の対応と、障害を削減するために配信する。
【０２３６】
▲８▼「分電盤工事を定期点検日に実施します、ｅｅ室系統の電源は停電となります。」
プライマリ保守者は、建物、マシン室の電源設備の配線経路を把握し、設備更新記録も合わせ管理し、部分停電時の影響範囲の案内配信する。
【０２３７】
電子メールによる作業完了関係通知・配信メッセージ例には、マルチベンダ機器に対する対応方法の詳細内容として、以下のものが例示されている。
【０２３８】
▲１▼「ＡＡ社のＢＢ装置の障害は復旧しました。」
プライマリ保守者は、単に障害修理の報告を受け取るだけではなく、システム全体から見て、問題がないかを検証後、つまり、試行ユーザージョブ、負荷ランニングジョブなるものにて、障害保守修理の完全確認と保守作業により波及した二次障害のないことを確認し、運用再開後の配信する。
【０２３９】
▲２▼「ＣＣ社のＤＤ装置にてメモリ障害発生の処置が完了し運用を再開しました。」
上記▲１▼に同上。あわせて、プライマリ保守者は、マルチベンダ機器の全て障害履歴管理も行い、事例として掌握する。
【０２４０】
▲３▼「ＥＥ社の無停電電源装置ＦＦに重障害の修理が完了しました。」
上記▲１▼に同上。あわせて、プライマリ保守者は、ＵＰＳ装置のバッテリー（消耗）交換履歴管理と、交換期日を把握し、交換を促進する。
【０２４１】
▲４▼「ｆｆシステムにてエラー出力の件、本日恒久処置を完了しました。」
プライマリ保守者は、自分自身、および、セカンダリ保守者の支援を得て、バグなどの不具合を把握、管理し、運用制限などにて、障害発生を抑止していたものが、完全に解決したことを配信する。
【０２４２】
▲５▼「定期点検は予定通り完了し、ｈｈ：ｍｍに運用を再開しました。」
プライマリ保守者は、単に点検の完了を伝達するのではなく、点検完了報告を、各ベンダー・メーカ（セカンダリ保守者）から、メールなどで報告を受けたのち、システム全体の動作を確認し、運用を再開、つまり利用者がログイン可能としたことを配信する。
【０２４３】
▲６▼「ｇｇシステムは現在ｉｉファイル復旧中です、いましばらくお待ち下さい。」
プライマリ保守者は、障害復旧の長時間を要するもの、予定時間の見積もりより長時間かかってしまう障害復旧作業となった場合は、その経過情報を、適時配信する。
【０２４４】
▲７▼「ｉｉシステムダウンにより、バッチジョブ３件がリスタートとなりました。」
プライマリ保守者は、システムダウン時点の実行ジョブを把握し、運用再開時に、利用者がリスタートする必要なく、利用者の手間を煩わせることなく、被害ジョブを再実行させる運用方法や手段を持ち、ダウンによるリスタートジョブ名を配信する。
【０２４５】
▲８▼「リスタートジョブの課金の払い戻しを完了しました。」
プライマリ保守者は、システムダウン時点の実行ジョブを把握し、運用再開時に、利用者に対し、ダウン停止からのリスタートまでの課金の損失分の払い戻しを行い、その払い戻し情報を、システム管理者に伝達、利用者に配信する。
【０２４６】
プライマリ保守者は、障害保守サービス関係の情報を、システム管理者からの指示と協議、自分自身にて判断し、且つセカンダリ保守者から作業の把握や情報収集を行い、図１３と図１４で示すような表示内容の作成とメール配信をプライマリ保守者端末７０９から行う。
【０２４７】
次に、図１５〜図１８を用いて、保守サービス関係の事項を報告する方法について述べる。
図１５は、システム運用関係の報告内容ウインドウ表示例を示す図である。
図１６は、システム管理関係の報告内容ウインドウ表示例を示す図である。
なお、図１５と図１６は、その内容を月次報告として報告するフォーマットの１例を示す。
図１７は、定期点検および工事作業工程表の例（マルチベンダ各社のスケジュール一覧の例）を示す図である。なお、図１７は、プライマリ保守者がマルチベンダ各社の作業内容・人員・資材の状況を把握し、摺り合わせ、未来の予定・スケジュールとして表示する１例を示す。
図１８は、システムに関連する情報掲示内容の例を示す図である。
【０２４８】
プライマリ保守者は、自分自身による情報収集およびセカンダリ以降の保守者からの情報収集を行い、プライマリ保守者端末７０９を使用して保守サービス関係の事項のまとめを作成し、マルチベンダシステム監視通報サーバ１５にウェブ掲載し、あるいはマルチベンダシステム監視通報サーバ１５経由で電子メールにてシステム管理者やエンドユーザに配信する。
【０２４９】
図１５を参照すると、システム運用関係の報告内容ウインドウ表示例として、システム稼働時間一覧とＣＰＵ・ＭＥＭＯＲＹ・ＦＩＬＥ使用率グラフとシステムジョブ件数・キュー待ちグラフとシステム障害件数・障害率グラフとが示されている。
【０２５０】
システム稼働時間一覧の通電時間とは、ＹＹＹＹ年のＭＭ月度の実時間、即ち例えばＭＭ月が３１日であったとすると、近年にては、２４時間連続稼働が主であるので、２４時間運転を例として一ヶ月を時間にすると、２４時間×３１日＝７４４時間であり、この時間から、電源設備点検・更新などにて、システム機器への電力供給が停止、つまり停電した時間を引いたものとする。そして、通電時間より、定期点検・緊急点検などの時間と障害時間、つまりシステムがハードウェア故障とソフトウェアの不具合にて停止した時間を引いたものを稼働時間とする。この稼働時間をシステムの運用が可能であるべき時間とし、稼働・使用率を算出する基本とする。
【０２５１】
ＣＰＵ・ＭＥＭＯＲＹ・ＦＩＬＥ使用率グラフは、ＣＰＵ関係はシステム稼働可能時間時間とＣＰＵ関係の機器のランニング時間との比率をグラフ表示し、ＭＥＭＯＲＹ関係は、システム機器の実装全体、全種のＭＥＭＯＲＹ容量とジョブのランニングにより使用された容量との比率をグラフ表示したものである。
【０２５２】
システムジョブ件数・キュー待ちグラフは、例えばＵＮＩＸ（登録商標）オペレーティングシステムにおいては、全体のジョブ数、ジョブキュー別のジョブ数などをグラフ表示し、各々のジョブキュークラスにての実行キュー待ちのグラフ表示をしたものである。
【０２５３】
システム障害件数・障害率グラフは、システム別、あるいはシステムごとの障害関係の件数、障害率をグラフ表示する。
【０２５４】
図１６を参照すると、システム管理関係の報告ウインドウ表示例として、システム問題管理表と課金消費・利用者数推移状況グラフとネットワーク構成図・トラフィック量グラフと消費電力量グラフ・外気とマシン室温湿度情報とシステム自動運転設定情報とが示されている。
【０２５５】
システム問題管理表は、ハードウェア、ソフトウェアの区別なく、システム全体の問題点を管理・表示し、特に懸案、未解決の問題の表示を重点とする。例えば、ハードウェア間欠故障やハードウェア原因不明障害やファームウェア、ソフトウェアのバグの問題点の表示と、システムの仕様変更、カストマイズ更新、性能改善変更などの要望をマルチベンダ各社に対し、問題解決と対応処置するのか、したかを表示する。システム問題管理表のフォーマットの１例として、問題・要望事項の発生年月日と機器名と問題点・要望「ネットワークルータ装置にてパケットロス発生。」、状況・処置「ルータ装置のオペレーティングシステムのバグのため、バージョン更新して解決。」、問題点としては完了し「処置済み」であることが示されている。
【０２５６】
課金消費・利用者数推移状況グラフは、課金消費状況にてファイル容量などのシステム資源の有効活用、システム利用者に平等使用公正使用、優先使用などの算定データと合わせ、システム利用者の推移を示す。
【０２５７】
ネットワーク構成図・トラフィック量グラフは、システム機器構成のなかの、特にネットワーク機器の構成を図示し、ネットワーク全体の把握を容易にし、ネットワーク機器自身の障害と通信ラインの障害とシステムの全体のジョブ負荷を示すとともに、各サーバ間のネットワークファイルシステムの容量、ファイルシステムの適切なアクセス状況、ファイルシステムの負荷状況を示し、合わせて不合理なネットワークファイルアクセス使用状況を感知するために示す。
【０２５８】
消費電力量グラフ・外気とマシン室温湿度情報は、システム機器の稼働状態、負荷状態を示す。システム機器に使用されているＬＳＩ素子の種類によっても消費電力は大きく違ってくるので、経済的運用のためのシステム機器の更新時期の判断条件を知ることが出来る。特に空調機関係の消費電力は、気候・外気温度により大きく左右されるため、電気量・電気料金の補充などが可能となる外気とマシン室の温湿度情報を表示する。
【０２５９】
システム自動運転設定情報は、現在における、あるいは未来に設定予定のシステム機器の自動運転処理装置による無人自動運転情報を掲載する。オペレータやシステム管理担当者が不在、すなわち無人状態による運用形態として、例えば、何日の何時から何時まで自動停止する、あるいは、無人状態にてはセキュリティーロックが掛かり不法侵入者の検知がなされるとか、端末装置にログインしている利用者が居なくなるか、バッチジョブが全て終了すると自動的にシステムがシャットダウンされるとかの情報を示し、システム操作の無人省力機能の効率的運用のための情報を示す。
【０２６０】
図１７を参照すると、定期点検および工事作業工程表内容ウインドウ表示例（マルチベンダ各社のスケジュール一覧ウインドウ表示例）として、定期点検・工事工程表・作業内容報告と年間定期点検予定日とシステム更新運用停止工程案内と計画停電予定案内とが示されている。
【０２６１】
定期点検・工事工程表・作業内容報告は、今後に実施されるシステム機器の定期点検作業を行うため、プライマリ保守者が関係する各ベンダの作業者と打ち合わせ、作業時刻と時間を調整し効率的に定期点検・工事作業が進むように協議し、システム機器、付帯設備の停止時間を最小とし、利用者の便宜を最大に図った、工程内容を掲示する。定期点検の１例として、システム機器の計画停止の日に、機器名がＡＳＤＭの定期点検が９時００分〜１７時００分までの間にて実施され、主な作業内容として、ファンフィルターの清掃作業と、機器名がＣＳＰＭの定期点検が９時００分〜１７時００分までの間に実施され、主な作業内容としてハードウェアバグ、あるいは、間欠障害予測部品交換などのためのメインメモリの部品交換作業と、機器名がＤＳＳＭの定期点検が９時００分〜１７時３０分の間に実施され、おもな作業内容としたソフトウェアメンテナンス作業である、オペレーティングシステムのソフトウェアパッチ更新作業とがスケジュールされていることを示す。そして、工事内容の１例として、ネットワーク機器である機器名ＨＮＷＳのライン増設・変更工事と、マシン室の空調設備のである屋外のクーリングタワーのポンプ交換工事が、定期点検に合わせて全面的に運用を停止し、点検作業が完了する時刻を待ち、１８時００分〜１９時００分の間に工事作業がスケジューリングされていることを示し、空調機器の工事のため全面的のシステム機器が停止し利用者に案内・警告として「空調装置保守点検のためシステム停止」と「マシン室のパッケージエアコン装置全面停止」を示す。プライマリ保守者は、定期点検と工事作業においても、システム機器の障害処理対応と同様に、システム管理者と利用者に作業開始確認と作業経過確認と作業完了報告と運用再開時刻をメールおよびインターネットＷｅｂにて伝達する。特に、点検作業、あるいは工事作業にて、システム機器の故障や点検交換部品不良やパッチファイル不良などにより、作業が予定時間を越える場合が生じたときは、その旨の伝達と報告を障害処理フローと同様の手順を取ってメールおよびインターネットにて伝達する。
【０２６２】
年間定期点検予定日は、定期点検の実施日スケジュールの１年間分を、プライマリ保守者が決定し、マルチベンダの各社のハードウェア保守のための部品と、ソフトウェア保守のためのデータファイル・媒体などの準備計画の情報として示し、さらに、システム機器の利用者に対し、システム運用停止の日時などを早期に伝達すべき情報を示す。
【０２６３】
システム更新運用停止工程案内は、ハードウェアに関しては、システム機器の更新作業、つまり新規に機器の設置と現地調整作業、上位モデルへのリプレス作業、周辺機器の増設作業などで、ソフトウェアに関しては、オペレーティングシステムのバージョンアップ作業などにて、システム機器を長期間にわたり運用停止となることの把握を、前もって管理者・利用者に必要なスケジュール情報と作業工程情報などを示す。
【０２６４】
計画停電予定案内は、法定電気設備点検や電気設備の変更と更新作業にて、停電となる日時を示し、システムのサーバ機器のみならず、管理者と利用者のワークステーション機器と端末機器などを全てに渡り、停電のため機器停止作業を必要とすることを案内し、ベンダ各社が停電停止作業に対応を必要とする事項の有無などを示す。
【０２６５】
上述した図１７に示す情報は、電子メール等によりプライマリ保守者が各ベンダ等と協議・問い合わせした情報および各ベンダ等から提供された情報を基に、プライマリ保守者がプライマリ保守者端末７０９の各種ツール（スケジュールソフトなど）を使用して解析編集して作成し、メール発信やウェブ掲載などによりマルチベンダシステム監視通報サーバ１５を経由してシステム管理者やエンドユーザに情報として伝達する。
【０２６６】
図１８を参照すると、システムに関連する情報掲示内容ウインドウ表示例として、以下のものが示されている。
【０２６７】
システム関連情報掲示ウインドウには、目次項目・掲示内容一覧の項目例として１０項目を示す。
【０２６８】
第１項として、「システム利用の手引・利用マニュアル」に関し、詳細項目は、１）▲１▼利用向け▲２▼使用例▲３▼ＯＳマニュアル▲４▼言語マニュアルなどの資料を掲示する。
【０２６９】
第２項として、「システム利用・活用講習会の案内」に関し、詳細項目は、２）▲１▼基幹業務▲２▼データベース構造▲３▼アプリケーション内容の講習の案内などの資料を掲示する。
【０２７０】
第３項として、「システム部門によくある質問・回答集」に関し、詳細項目は、３）▲１▼環境設定▲２▼利用方法▲３▼処理中対応▲４▼関連用語集の質問・回答集など資料を掲示する。
【０２７１】
第４項として、「システム部門の担当者・電話メール一覧」に関し、詳細項目は、４）▲１▼教育▲２▼操作▲３▼運用▲４▼業務▲５▼開発▲６▼保守▲７▼設備の各部門の担当者・電話メール一覧などの資料を掲示する。
【０２７２】
第５項として、「システム利用検討会議・改善提案」に関し、詳細項目は、５）▲１▼業務システム操作性▲２▼操作上の問題点▲３▼不具合の検討結果・改善要求などの資料を掲示する。
【０２７３】
第６項として、「システム利用改善アンケート」に関し、詳細項目は、６）▲１▼利用度▲２▼応答性▲３▼有効性▲４▼操作性▲５▼データ精度に対するアンケート回答入力画面と入力依頼と集計結果などの資料を掲示する。
【０２７４】
第７項として、「各メーカー・ベンダの動向」に関し、詳細項目は、７）▲１▼ＸＸ機紹介▲２▼新分野への取り組み▲３▼ＹＹ言語の今後などの資料を掲示する。
【０２７５】
第８項として、「システムとネットワーク紹介・概要と構成」に関し、詳細項目は、８）▲１▼管理部門紹介▲２▼システム構成図▲３▼レイアウト図などの資料を掲示する。
【０２７６】
第９項として、「新型端末機器紹介・価格表」に関し、詳細構成は、９）▲１▼パソコン▲２▼サーバ▲３▼ネット機器▲４▼価格と購入方法などの資料を掲示する。
【０２７７】
第１０項として、「消耗品一覧・価格・購入要求」に関し、詳細項目は、１０）▲１▼カートリッジ▲２▼ディスク媒体▲３▼価格表▲４▼入手依頼などが、どの機器に対応した消耗品であるかの資料と、購入要求受付画面表示など、を掲示する。
【０２７８】
上述した図１８に示す情報は、プライマリ保守者がインターネットＷｅｂ検索や雑誌などにて収集した情報および電子メール等によりプ各ベンダ等から提供された情報を基に、プライマリ保守者がプライマリ保守者端末７０９にて作成し、マルチベンダシステム監視通報サーバ１５などにウェブ掲載し、管理者・利用者の要望に応え、便宜をはかるための掲示である。また、マニュアルの購入や消耗品サプライの購入の代理業務などをプライマリ保守者が行うようにしてもよい。
【０２７９】
また、図示していないが、マルチベンダシステム構成装置の掲示を行い、マルチベンダシステムの写真と機能概要を具体的な映像情報として示し、見学者のマシン室案内業務もプライマリ保守者が行うようにしてもよい。各機器の有効活用と合わせ、システム管理者が利用者に対する構成説明と見学者に対する案内説明の労力を軽減するとともに、マルチベンダ利用の実際を示すことができる。
【０２８０】
本発明による上述した実施の形態において、保守サービス方式の処理動作を実行するためのプログラム等を、データとしてコンピュータの磁気ディスクや光ディスク等の記録媒体（図示せず）に記録するようにし、記録されたデータを読み出して保守サービス方式を動作させるために用いる。このように、本発明による保守サービス方式を動作させるデータを記録媒体に記録させ、この記録媒体をインストールすることにより保守サービス方式の機能が実現できるようになる。
【０２８１】
このように、プライマリ保守者は、マルチベンダシステムの一次保守者となって保守窓口として保守全般を取りまとめ、マルチベンダシステム監視通報サーバおよびプライマリ保守者端末を使用して、マルチベンダシステムを構成する機器で発生する障害を監視し、障害の発生状況や解決状況の報告、更にシステム運用情報やシステム管理情報を作成してシステム管理者やエンドユーザやベンダ等に発信し、マルチベンダシステムの障害解決に当たり、正常運用を司る。この結果、システム管理者は障害処理から離れて本来のシステム管理業務に専任することができる。
【０２８２】
【発明の効果】
第１の効果は、マルチベンダシステムを構成するある特定単一装置の障害により、システム全体として、その特定装置の障害停止によって発生する、システム全体への被害、影響を素早く把握し、多数のエンドユーザへ連絡と指示のアナウンスをネットワークを介して即座に行うことが可能となることである。
【０２８３】
その理由は、マルチベンダによって構成された情報処理システムの障害監視と障害処理サービスのために、システム構成要素にマルチベンダシステム監視通報サーバを加え、マルチベンダシステム監視通報サーバのインターフェイス変換装置により情報処理システム機器のみならず機器設置場所の付帯設備も含めて障害監視を行い、マルチベンダ構成による多種多様な障害情報を認識し、マルチベンダシステム監視通報サーバの障害自動通報装置や障害メールサーバによりエンドユーザ等に通報するようにしたからである。
【０２８４】
第２の効果は、システム管理者はシステムの異常事態を早期に把握でき、保守作業者は障害状況を把握して障害対応の初期指示と行動に素早く対応できることである。
【０２８５】
その理由は、マルチベンダシステム監視通報サーバを設け、マルチベンダシステム監視通報サーバのインターフェイス変換装置によりマルチベンダシステムを構成する各機器の障害を検出し、マルチベンダシステム監視通報サーバの障害自動通報装置や障害メールサーバによりシステム管理者や保守者等に通報するようにしたからである。
【０２８６】
第３の効果は、サーバ等の情報処理装置以外の付帯設備機器に対しても十分に保守サービスを行い、情報処理システム全体として一括して保守サービスを行うことである。
【０２８７】
その理由は、マルチベンダシステム監視通報サーバを設け、マルチベンダシステム監視通報サーバのインターフェイス変換装置によりマルチベンダシステムを構成する各付帯設備機器等の障害を検出し、マルチベンダシステム監視通報サーバの障害自動通報装置や障害メールサーバにより関連者に通報するようにしたことにより、プライマリ保守者等が各付帯設備等の障害も認識するようにしたからである。
【０２８８】
第４の効果は、マルチベンダシステムの運用と保守と障害の管理に関して、システム管理者が煩雑なベンダやメーカー等への対応処理作業から離れて、本来の業務に専任できることである。
【０２８９】
その理由は、プライマリ保守者端末を設け、プライマリ保守者がプライマリ保守者端末等を使用して、マルチベンダシステムの各機器のベンダとマルチベンダシステムの運用と保守と障害に関して調整と協議を行い、マルチベンダシステムの一次保守者となって保守窓口として保守全般を取りまとめるようにしたからである。
【０２９０】
第５の効果は、第１次の対応者であるプライマリ保守者を設けて、複数の障害窓口をひとつにする効率化を可能としたことである。
【０２９１】
その理由は、プライマリ保守者が、システム全体の保守状況を把握し、異常の一時的回避やエラーログの収集を行い、ハードウェアの定期点検やソフトウェアメンテナンスにおける作業工程管理と指示を行うようにしたからである。
【０２９２】
第６の効果は、保守サービス品質を向上させ、顧客の満足度を高めることである。
【０２９３】
その理由は、マルチベンダシステム監視通報サーバの監視通報機能を利用し、情報処理業界関係の最新情報提供や、情報機器の購入代理業務やサプライ品の購入業務を案内し、情報提供業務や販売代理業務にも活用できるようにしたからである。
【図面の簡単な説明】
【図１】本発明の保守サービス方式の概念を説明する図
【図２】マルチベンダシステムの例を示す図
【図３】システム使用者側とシステム機器提供者側とプライマリ保守者との関係を示す図
【図４】複雑に関連したマルチベンダシステムをシングルベンダシステムの如くに扱うための方法を示す概念図
【図５】本発明の実施の形態についての構成に関する詳細な説明のブロック図
【図６】障害監視して通報する時の動作の流れを示す図
【図７】障害監視して通報する時の動作の流れを示す図
【図８】障害状況の伝達時の動作の流れを示す図
【図９】障害保守の処理動作の全体の流れを示す図
【図１０】障害処理の第１の方法の動作の流れを示す図
【図１１】障害処理の第２の方法の動作の流れを示す図
【図１２】障害処理の第３の方法の動作の流れを示す図
【図１３】障害情報を伝達する方法の例を示す図
【図１４】電子メールによる配信メッセージの例を示す図
【図１５】システム運用関係の報告内容ウインドウ表示例を示す図
【図１６】システム管理関係の報告内容ウインドウ表示例を示す図
【図１７】定期点検および工事作業工程表の例を示す図
【図１８】システムに関連する情報掲示内容の例を示す図
【図１９】従来の遠隔障害監視システムの構成を示すブロック図
【図２０】従来の家電製品の保守サービスシステムの構成を示すブロック図
【図２１】従来におけるシステム管理者のマルチベンダ構成による情報処理システムに係わる各当事者との対応関係を示すブロック図
【符号の説明】
１    マルチベンダシステム
２    システム管理者装置
３    第１ネットワーク
４    マルチベンダシステム監視通報サーバ
５    プライマリ保守者端末
６    第２ネットワーク
７    各メーカー／ベンダ／保守会社システム
１１    各種サーバ装置
１２    各種クライアント装置
１３    各種付帯設備
１５    マルチベンダシステム監視通報サーバ
１６    インターフェイス変換装置
１７    障害自動通報装置
１８    障害メールサーバ
２０１    Ａ社製ベクトル共有メモリ機
２０２    Ｂ社製ベクトル分散メモリ機
２０３    Ｃ社製スカラ分散メモリ機
２０４    Ｄ社製スカラ共有メモリ機
２０５    Ｅ社製ネットワーク装置
２０６    Ｆ社製ＦＤＤＩ−ＬＯＯＰ／ＡＴＭ−ＬＡＮ
２０７    ルータ
２０８    ＷＡＮ・インターネット
２１０    エンドユーザクライアント
２１８    ＥＴＨＥＲ−ＬＡＮ
２２０    システムコンソール
２２１    運用監視サーバ
２２２    メールサーバ
３０１    システム管理者
３０２    エンドユーザＡ
３０５    エンドユーザＤ
３０６    管理部門Ａ
３０７    管理部門Ｂ
３０８    対応・指示・会議・報告Ａ
３１１    対応・指示・会議・報告Ｄ
３１２    メーカー・ベンダＡ
３１３    メーカー・ベンダＢ
３１６    保守会社Ａ
３２０    演算サーバＡ
３２４    ファイルサーバ
３２５    ネットワーク機器
３２６    空調機
３２７    電源設備
３２８    監視盤
３２９    監視装置
４０１    インターネット情報収集伝達
４０２    マルチベンダ対応手段
４０３    マルチベンダシステム監視通報サーバ
４０４    プライマリ保守者端末
４０５    一括対応窓口
４０６    マルチベンダ一括支援サービス
７００    マルチベンダシステム
７０１    公衆回線
７０２    サーバＶ
７０５    ベンダシステム
７０６    サーバＷ
７０８    インターネット
７０９    プライマリ保守者端末
７１０    サーバＸ
７１１    サーバＹ
７１２    サーバＺ
７１３    ＲＳ２３２Ｃ
７１４    付帯設備
７１５    ＬＡＮ
７１６    接点信号
７１７    エンドユーザクライアント
７１８    保守拠点システム
７１９    システムコンソール
７２０    運用監視サーバ
７２１    メールサーバ
７２２    システム管理者装置
１５０１    ダウン停止表示
１５０２    機器状態選択ウインドウ
１５０３    運用制限中表示
１５０４    制限表示ウインドウ
１５０５    点検中表示
１５０６    ダウン表示ウインドウ
１５０７    点検表示ウインドウ
１５０８    電子メール配信
５１００    ホストシステム
５１１１    メッセージファイル
５１２０    ハードログファイル
５１３０    入出力装置
５１４０    ネットワーク系装置
５１５０    端末
５２００    障害監視プログラム
５３０１    転送装置ファイル
５５００    パソコン
６００１    保守修理サービスセンター
６００２    一般家庭
６００３    ＷＷＷインターネット網
６００４    電話網
６１０１    ＷＷＷサーバ
６１０２    故障診断装置
６１０３    顧客データベース
６１０４    故障診断データベース
６２０１    機器情報管理装置
６２０３    テレビ
６２０４    エアコン
６２０５    照明器
７０３１    ＳＶＰａ
７０３２    ＳＶＰｂ
７０４１    モデムａ
７０４２    モデムｂ
７０４３    モデムｃ
７０４４    モデムｄ
７０４５    モデムｅ
７０７１    ＲＳ信号感知部ａ
７０７２    ＲＳ信号感知部ｂ
【図１】
2004164389.tif 000003
【図２】
2004164389.tif 000004
【図３】
2004164389.tif 000005
【図４】
2004164389.tif 000006
【図５】
2004164389.tif 000007
【図６】
2004164389.tif 000008
【図７】
2004164389.tif 000009
【図８】
2004164389.tif 000010
【図９】
2004164389.tif 000011
【図１０】
2004164389.tif 000012
【図１１】
2004164389.tif 000013
【図１２】
2004164389.tif 000014
【図１３】
2004164389.tif 000015
【図１４】
2004164389.tif 000016
【図１５】
2004164389.tif 000017
【図１６】
2004164389.tif 000018
【図１７】
2004164389.tif 000019
【図１８】
2004164389.tif 000020
【図１９】
2004164389.tif 000021
【図２０】
2004164389.tif 000022
【図２１】
2004164389.tif 000023