(57)【要約】【課題】  本発明はシステムの運用管理に関し、より詳細にはシステムの管理者によって入力されたイベント設定情報に基づいてイベントに関連する連携サーバにイベントの通知を行い、連携サーバからイベント実施に伴う措置完了の通知を受けてイベントの処理を実行する運用管理プログラムおよび運用管理方法に関する。【解決手順】  本発明は、イベント設定情報を予め用意したイベント定義ファイルにより解析し、解析結果により連携するサーバにイベント通知情報を通知し、連携サーバからのイベントに関する措置完了通知を得てイベントを実施するよう構成する。【選択図】    図１
2007133545.tif 000002
【特許請求の範囲】
【請求項１】
１つ以上のサーバがネットワークを介して接続されるイベントサーバの運用管理プログラムであって、
前記イベントサーバに、
前記イベントサーバで実行されるイベントの内容が記述されたイベント設定情報を予め用意されたイベント定義ファイルに基づいて解析するイベント解析手順と、
前記解析の結果に基づいて、前記１つ以上のサーバの中で前記イベントに関連する連携サーバにイベント通知情報を作成し、通知するイベント通知手順と、
前記連携サーバから、前記イベントに伴って該連携サーバ側で対処されるべき措置が完了した旨の措置完了通知を受信する措置完了通知受信手順と、
前記イベント情報通知を通知した全ての連携サーバから前記措置完了通知を受信したとき、前記イベントの処理を実行するイベント実行手順と、
を実行させるための運用管理プログラム。
【請求項２】
前記運用管理プログラムは、さらに
前記１つ以上のサーバからイベント通知情報を受信したとき、該サーバとは別のサーバで該イベント通知情報のイベントに関連する連携サーバに該イベント通知情報を転送し、該イベントに伴う措置を行った後に該連携サーバでの該イベントに伴う措置が完了した旨の通知を受けて措置完了通知を該サーバに返信する、
ことを特徴とする請求項１記載の運用管理プログラム。
【請求項３】
前記運用管理プログラムは、さらに
前記イベント実行手順におけるイベントの実行後に該イベントのシステムを再開し、前記連携サーバと該連携サーバの管理者と前記利用者とにシステム再開の通知を行うシステム再開通知手順と、
を有することを特徴とする請求項１または請求項２記載の運用管理プログラム。
【請求項４】
前記イベント通知手順は、
前記解析の結果に基づいて、前記１つ以上のサーバの中で前記イベントに関連する連携サーバにイベント通知情報を作成して通知を行うと共に、該連携サーバの管理者と前記イベントサーバの利用者とに対して該イベント通知情報の内容を通知する、
ことを特徴とする請求項１乃至請求項３記載の運用管理プログラム。
【請求項５】
１つ以上のサーバがネットワークを介して接続されるイベントサーバの運用管理方法であって、
前記イベントサーバが、
前記イベントサーバで実行されるイベントの内容が記述されたイベント設定情報を予め用意されたイベント定義ファイルに基づいて解析するイベント解析手順と、
前記解析の結果に基づいて、前記１つ以上のサーバの中で前記イベントに関連する連携サーバにイベント通知情報を作成して通知するイベント通知手順と、
前記連携サーバから、前記イベントに伴って該連携サーバ側で対処されるべき措置が完了した旨の措置完了通知を受信する措置完了通知受信手順と、
前記イベント情報通知が通知された全ての連携サーバから前記措置完了通知を受信したとき、前記イベントの処理を実行するイベント実行手順と、
前記１つ以上のサーバから該サーバ側で実行されるイベントのイベント通知情報を受信したとき、該サーバとは別のサーバで該イベントに関連する連携サーバに該イベント通知情報を転送し、該イベントに伴う措置を行った後に該イベント通知情報を送信したサーバに措置完了通知を通知する連携イベント措置手順と、
を有することを特徴とする運用管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、システムの運用管理に関し、より詳細にはシステムの管理者によって入力されたイベント設定情報に基づいてイベントに関連する連携サーバにイベントの通知を行い、連携サーバからイベント実施に伴う措置完了の通知を受けてイベントの処理を実行する運用管理プログラムおよび運用管理方法に関する。
【背景技術】
【０００２】
パソコンとネットワークの普及は目ざましいものがあり、利用者は種々の場において多くのサービスの提供を受けることが可能となった。これらのシステムは複数のシステムが互いに連携し合ってサービスを提供しており、さらにそれぞれのシステムにおいては１台以上のサーバが各々の役割を分担した構成（マルチサーバ）とすることが一般的となっている。システムは利用者からのサービスの拡大要求に答えて、システムの増加と分散が行われ、全体として複雑化の方向にある。
【０００３】
システムの運用管理をする部門の担当者（以後、管理者と言う）は、自身が管理するシステム（以降、自システムと言う）の保守や障害に対して責任を持って対応することが求められる。例えば、自システムにおいてあるアプリケーションのパッチを早急に当てる必要が生じた場合にシステムを停止する必要があり、自システムのユーザへのシステム停止のアナウンスとともに自システムと連携している他のシステム（以後、連携しているシステムを連携システムと言う）の管理者に対して通知を行う必要がある。そして、連携システムにおいて関連するＪＯＢの停止や連携システムのユーザへのアナウンス等の作業が行われ、連携システムの管理者からそれらの作業の終了したことの通知を受けて自システムの作業を行うことが可能となる。自システムの作業が終了してシステムを立ち上げたときには、同様の流れでシステム再開の伝達（自システムのユーザと連携システムに対し伝達）と連携システム側の対応が必要となる。
【０００４】
また、逆に連携システムにおいて保守や障害等に対する作業が行われる場合に、連携システムの管理者から通知を受けると、上述した連携システムでの作業を自システムで行う必要がある。これらの通知の手段は電話や電子メールが用いられること一般的である。
【０００５】
複数のサーバから構成するシステムにおいて、各サーバで生じた事象（イベント）を集中的に管理し、自動的に利用者に通知する管理装置が提案されている。これは、サーバの一つに共通記憶手段を設け、それぞれのサーバで発生した事象を検知して共通記憶手段に送信して記憶し、この情報を利用者に通知するもので、システム管理者の負担を軽減することを目的とするものである（例えば、特許文献１）。
【特許文献１】特開平１０−２４７９１１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記に示したようにサービスを提供するシステムは複数のシステムと連携し、それぞれのシステムは１台以上のサーバで構成されることが、一般的になってきている。そして、そのシステムの管理者は、保守や障害の際に連携システムの管理者と連絡を取りながら作業に当たる必要があり、システムの複雑化が進む中で多大の工数を要するようになっている。
【０００７】
このような課題に対処するために提案された特許文献１は、ユーザへの通知が自動化できるためシステム管理者の負担を軽減するものである。しかし、集中管理を行うためシステム全体を常に把握しておく必要があり、システムの変動がある場合の配慮がなされていない。例えば、連携するサーバが増設された場合にその度設定を行う必要があり煩雑となる。特に、システム全体が巨大化してくると全体の把握は困難となることが考えられる。
【０００８】
本発明は、システム全体が複雑化してもそれとは関係なく連携システムとの運用の情報伝達が可能な運用管理プログラムおよび運用管理方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の運用管理プログラムおよび運用管理方法は以下のように構成される。
（１）第１の発明
第１の発明は、保守や障害等のイベントに対処する必要が生じたイベントサーバは、そのサーバと連携しているサーバにイベントのあることを通知し、連携しているサーバ側でのイベント実施に伴う措置の完了を確認してイベントの処理を実行する運用管理プログラムである。また、連携しているサーバからサーバ側で実施されるイベントの通知を受けたとき、そのイベント実施に伴う措置を行い、完了通知をそのサーバに回答する。
【００１０】
その原理を図１を用いて説明する。第１の発明は、１つ以上のサーバとネットワークを介して接続するサーバ（イベントサーバという）の運用管理プログラムであり、図１に示すようにイベント情報解析手順１０、イベント通知手順２０、措置完了通知受信順３０およびイベント実行手順４０で構成する。
【００１１】
イベント情報解析手順１０は、イベントの内容が記述されたイベント設定情報を予め用意されたイベント定義ファイルに基づいて解析することを行う。イベント設定情報は、例えばイベントＩＤ、イベント処理時間、イベント実施理由等が記述されたものである。また、イベント定義ファイルには、例えばイベントＩＤ毎に対象のサービス内容や処理の内容、連携するサーバ名等が記述されたものである。
【００１２】
イベント通知手順２０は、イベント情報解析手順１０の解析結果に基づいて、連携サーバに対してイベント通知情報を作成し、その情報を通知する。
【００１３】
措置完了通知受信順３０は、連携サーバから、通知したイベントに伴って連携サーバ側で対処されるべき措置が完了した旨の措置完了通知を受信する。例えば、イベント通知情報を通知したイベントがデータ収集を行うアプリケーションを一時停止する内容であったとき、そのアプリケーションと連携してデータの送信を行っている連携サーバはデータの送信を一時停止する措置を講じておく必要があり、その措置を行った後に措置完了通知を通知し、イベントサーバがそれを受信するものである。
【００１４】
イベント実行手順４０は、イベント情報通知を通知した全ての連携サーバから措置完了通知を受信したとき、イベントの処理を実行する。即ち、イベントサーバは連携サーバの何れもがそのイベントに伴う措置を完了していることを確認した上でイベントの処理を実行する。
（２）第２の発明
第２の発明は、接続しているサーバからイベント通知情報を受け取ったとき、そのイベントに伴う措置をして措置完了通知を返信するものである。
【００１５】
図２は、その原理を示すものでイベント情報解析手順１０、イベント通知手順２０、措置完了通知受信順３０、イベント実行手順４０および連携イベント措置手順５０で構成する。
【００１６】
イベント情報解析手順１０〜イベント実行手順４０は、第１の発明と同様で説明が重複するのでここでは省略する。
【００１７】
連携イベント措置手順５０は、接続している１つのサーバからイベント通知情報を受信したとき、そのサーバとは別のサーバでイベント通知情報のイベントに関連する連携サーバにイベント通知情報を転送する。そして、そのイベントに伴う措置を行った後に、連携サーバから連携サーバ側でのイベントに伴う措置が完了した旨の通知を受けて措置完了通知をサーバ（イベント通知情報を送信したサーバ）に返信する。即ち、サーバＡからイベント通知情報を受信したとき、サーバＢとＣがそのイベントに関連する連携サーバであればそのサーバＢとＣとにイベント通知情報を転送し、サーバＢとＣからサーバＢとＣ側の措置が完了したことの通知を受けて、サーバＡに措置完了通知を送信（返信）するものである。
（３）第３の発明
第３の発明は、第１の発明または第２の発明の構成に加えてイベントサーバの再開通知を行うものである。図３は第２の発明に再開通知の構成を加えた構成を示すもので、イベント情報解析手順１０、イベント通知手順２０、措置完了通知受信手順３０、イベント実行手順４０、連携イベント措置手順５０およびシステム再開通知手順６０で構成する。
【００１８】
イベント情報解析手順１０〜連携イベント措置手順５０は第２の発明と同じ内容であるので説明は省略する。
【００１９】
システム再開通知手順６０は、イベント実行手順におけるイベントを実行した後にそのイベントのシステムを再開し、連携サーバ、連携サーバの管理者、およびイベントサーバの利用者に対してシステム再開の通知を行う。
（４）第４の発明
第４の発明は、第１の発明〜第４の発明のイベント通知手順において、連携サーバにイベント通知情報を通知するとともに、連携サーバのシステムの管理者と自身のイベントサーバの利用者にイベント通知情報の内容を通知するものである。
（５）第５の発明
第５の発明は、第１の発明の運用管理方法である。
【発明の効果】
【００２０】
第１の発明により、保守や障害に対するイベント設定情報を作成するとそのイベントに関連のある連携サーバに通知が行われ、連携サーバからの回答を確認してイベントサーバでのイベントの実行を行うので、管理者の連絡、確認に要する工数を削減する運用管理プログラムの提供ができる。また、運用管理プログラムは、イベントの内容によっては連携サーバの管理者が不在であってもイベントの処理に対する対応ができる。
【００２１】
第２の発明により、接続しているサーバそれぞれが第２の発明の運用プログラムを実装することにより、イベントサーバは直接連携している連携サーバにのみ通知すれば、そのイベントに関連するサーバの全てに通知が行き、そのための措置が行われるので、直接連携するサーバのみを意識していればよく管理者の負担を軽減する。即ち、イベントに関連するサーバが連携サーバの先で追加が行われていても、意識する必要はなくなる。
【００２２】
第２の発明により、イベントの通知は関連する連携サーバの管理者と自身のイベントサーバの利用者に通知が自動的になされるので、管理者の連絡に要する工数を削減する運用管理プログラムの提供ができる。
【００２３】
第３の発明により、イベント実行後のシステム再開の通知を関連する連携サーバとその管理者、イベントサーバの利用者に通知が自動的になされるので、管理者の連絡に要する工数を削減する運用管理プログラムの提供ができる。
【００２４】
第４の発明により、イベント実行に際して関係者（連携サーバの管理者、イベントサーバの利用者）への通知が自動的に行われるので、イベントサーバの管理者の工数を削減する運用管理プログラムの提供ができる。
【００２５】
第５の発明により、第１の発明と同様に管理者の連絡、確認に要する工数を削減できる運用管理の方法の提供ができる。
【発明を実施するための最良の形態】
【００２６】
本発明の実施例について図４から図１１を用いて説明する。
【００２７】
まず最初にイベントサーバと連携サーバの関係を図４を用いて説明する。図４では、システムＡ〜Ｅのシステムが図に示すように接続されているものとする。システムＡ、Ｂ、Ｄ、Ｅは１システム１サーバ、システムＣは１システム２サーバで構成している。システムＡのサーバＡは、サーバＢ、Ｃ１、Ｄと接続（図４で太線で接続を示している）しており、サーバＡにおいてあるイベントの実施が必要となったときサーバＡをイベントサーバと言い、そのイベントがサーバＢとサーバＣ１と関連して処理を行うものであればサーバＢとサーバＣ１を連携サーバと言う（図４で、網点を掛けて示したサーバが連携サーバである）。サーバＤはサーバＡと接続しているが、この時のイベントと関連して処理を行うことをしないので連携サーバとは言わない。また、このイベントがサーバＢを介してさらにサーバＥに関連していても、連携サーバとは言わない。各サーバともフラットな関係にあり、サーバＢがイベントサーバになってサーバＡが連携サーバになることもある。各サーバには運用管理プログラムが実装されているものとする。
【００２８】
図５は、イベントサーバ１００の構成例を示すもので、プログラムやデータ、入出力機器を制御するＣＰＵ１１０、ネットワーク１２１を介して接続しているサーバとの通信を制御する通信制御部１２０、キーボード１３１およびディスプレイ１３２を制御する入出力制御部１３０、イベントの定義を記述したイベント定義情報記憶部１４０、イベント実施に伴う各種の履歴情報を格納する履歴情報記憶部１５０および運用管理プログラム１６０から構成する。
【００２９】
運用管理プログラム１６０は、イベント設定部１６１、イベント設定情報解析部１６２、イベント通知部１６３、措置完了通知受信部１６４、イベント実行部１６５および連携イベント措置部１６６で構成する。これらの個々のプログラムの概要を次に説明する。
【００３０】
イベント設定部１６１は、イベント設定情報の作成に対するエディタ機能を有してシステム管理者を支援し、作成された情報を所定の記憶領域に記憶する。イベント設定情報は例えばＸＭＬ（eXtensible Markup Language）で作成される。
【００３１】
イベント設定情報解析部１６２は、イベント設定部１６１で作成されたイベント設定情報をイベント定義情報記憶部１４０を参照して解析を行う。解析により通知すべき連携サーバやその管理者のメールアドレス等を取得する。
【００３２】
イベント通知部１６３は、取得した連携サーバ、その管理者、更には自サーバの利用者に対してイベント通知情報を作成して通知を行う。連携サーバに対しては、連携サーバに実装している運用管理プログラムに対して通信し、管理者や利用者に対しては電子メールを自動発信する。そして、通知した連携サーバ名を設定した通知テーブル（図示していない）を作成する。
【００３３】
措置完了通知受信部１６４は、通知した連携サーバから、連携サーバ側でイベントに伴う措置の措置完了通知を受信する。連携サーバは１つ以上のサーバであり、それらサーバが発信した措置完了通知を受信することになる。措置完了通知を受信すると、通知テーブルの該当する連携サーバ名に措置が完了したことを示す完了フラグを立てる。
【００３４】
イベント実行部１６５は、通知テーブルにおいて全ての連携サーバ名に対して完了フラグが設定されたとき、自サーバの管理者に対してイベント実行に対する準備完了の通知を行う。そして、設定された時間にイベントの実行を行う。
【００３５】
連携イベント措置部１６６は、連携しているサーバからのイベント通知情報を受信し、そのイベント通知情報をイベント定義情報記憶部１４０を参照して解析を行う。解析結果に基づいて、そのイベントに伴う措置を実行する。また、そのイベントにさらに連携するサーバがあるときは、そのサーバに対して受信したイベント通知情報を転送する。自サーバのイベントに伴う措置の実行の完了と、転送した連携サーバからの措置完了通知の受信を得て、イベント通知情報を送信したサーバに措置完了通知を返信する。
【００３６】
次に、イベント設定部１６１で作成されたイベント設定情報の例を説明する。図６は、図４のサーバＡがイベントサーバとなり、そのサーバＡで作成されたイベント設定情報の例を示している。このイベント設定情報はＸＭＬで作成され、タグとそのタグに対する情報とで構成している。サーバはこのタグを基にその情報を識別し、さらは後述するイベントの定義情報を取得する。まず<event>は、イベント設定情報であることを示すタグであり、<event>と</event>の間に書かれた情報がイベントに対する設定情報である。<event-id>はイベントを識別する情報を、<event type>はイベントの区分を、<status>はイベント実行によりどのような状態になるかを示すタグである。さらに、<execution time>はイベントを実施する時間、<comment>はイベント実施の理由など管理者のコメントを表すタグである。図６の情報は、識別番号0001のイベントは保守に区分されるもので、イベントの実施中は利用が不可能であり、2005年9月1日の0時から5時までイベントの実施を予定し、具体的なイベントはデータベースの修正パッチ適用であることを示している。
【００３７】
続いて、連携サーバに通知するために作成されたイベント通知情報について図７を用いて説明する。図７の例は、サーバＡから連携サーバＢとＣ１に通知されるイベント通知情報で、図６のイベント設定情報と後述するイベント定義情報とを基に作成されたものである。図６に較べて<event server>と<person in charge>のタグが追加されており、<event server>はイベントが実施されるサーバ名で、この場合サーバＡである。<person in charge>はイベントが実施されるサーバＡの管理者の名前と、メールアドレスである。連携サーバはイベントがサーバＡで実施され、連絡をとる必要が生じた場合は担当者である富士太郎に連絡すれば良い、ことを知ることができる。
【００３８】
次に、イベント定義情報記憶部１４０のデータ例について図８を用いて説明する。イベント定義情報は、以下に示すフィールドから構成している。イベント設定情報に記述されたイベントを識別するためのＩＤを格納する「イベントＩＤ」、そのイベントの対象とするサービスを格納する「対象サービス」、運用時間の制限と内容を示す「日付制限」、「曜日制限」および「時間帯」、利用者名とメールアドレスを格納したファイル名を格納する「利用者」、イベント対象のサービスに関連するサーバ名を格納する「連携サーバ」、その連携サーバが対象とするサービスを格納する「連携サーバ対象サービス」、連携サーバの管理者のメールアドレスを格納する「管理者通知先」、イベントの実行内容を格納する「処理」である。この例では、イベントＩＤ「０００１」のイベントは、対象サービスがデータベース・サービスであり、運用時間帯は０時から２３時５９分まであり、日付と曜日の制限は設けられていない。このデータベースのサービスを受ける利用者の名前とメールアドレスはＵＳＥＲ−Ａと言う名称のファイルにあり、連携サーバはサーバＢとサーバＣ１でそれぞれが対象とするサービスはデータ取得とデータ提供である。また、それぞれの管理者の通知先はjiro@jp.aa.comとhana@jp.bb.comである。イベントの処理内容は図８に示すもので、処理対象のプログラム名やバージョン、格納アドレス等が指定されている。イベントは、この処理内容に基づいて実行されることになる。
【００３９】
次に、イベントサーバの処理フローについて図９と図１０を用いて説明する。
【００４０】
図９は、イベントサーバがイベント通知情報を連携サーバに送信し、その連携サーバから連携サーバ側での措置完了を確認してイベントを実行するフローを示すものである。まず、イベントサーバの管理者によって作成されたイベント設定情報を読み込む。そして、イベント設定情報に記述されたイベントＩＤを基にイベント定義情報記憶部１４０を参照し、該当するイベント定義情報を取り出す（Ｓ１００、Ｓ１１０）。
【００４１】
取り出したイベント定義情報を調べて、設定されたイベントに関連する連携サーバがあれば通知の必要があると判断し、イベント通知情報を作成してその連携サーバに送信する。イベント通知情報は、イベント定義情報に設定された全ての連携サーバに対して通知される。通知後、通知テーブルを作成する。通知テーブルは、イベントサーバから連携サーバへのイベント通知情報の通知に対して、通知したことと連携サーバ側でイベントに伴う措置完了の通知を受信したことを示すテーブルで、連携サーバ名とそれに完了フラグが設定できるものであればよい。連携サーバへの通知が必要ない場合（イベント定義情報に連携サーバが設定されていない場合）は、これらの処理（イベント通知情報の通知と通知テーブルの作成）を行わず、次のステップに進む（Ｓ１２０−Ｓ１４０）。
【００４２】
次に、利用者への通知が必要かどうかを調べる。イベント定義情報の利用者通知先フィールドに利用者の通知先ファイル名が格納されていれば必要有りと判断し、そのファイルに記述されている利用者のメールアドレスにイベント設定情報の内容を電子メールで送信する。利用者への通知が不要の場合は、次のステップに進む（Ｓ１５０、Ｓ１６０）。
【００４３】
ここで、イベントサーバは先にイベント通知情報を送信した連携サーバからの措置完了通知を待つ。連携サーバから送信された措置完了通知を受信すると、通知テーブルのその措置完了通知を送信した連携サーバ名に完了フラグを設定する。全ての連携サーバから措置完了通知を受信するまで通知待ちを行う（Ｓ１７０−Ｓ１９０）。
【００４４】
全ての連携サーバから措置完了通知を受信したら（通知テーブルの完了フラグを参照することにより判断できる）、イベントサーバの管理者に対して連携サーバのイベントに伴う措置が完了し、イベント実行の準備が完了した旨の通知を行う。これは、イベントサーバが管理者に対して電子メールを自動送信するようにすれば良い。
【００４５】
設定した時間が来ると、イベント定義情報の処理に設定された内容に基づいてイベントの処理を実行する。この処理は、イベントサーバが自動で処理できるものもあれば、管理者からの何らかの入力を必要とする場合もある。後者の場合は、例えばイベントサーバは必要とする入力段階まで処理を行い、入力待ちの状態で待機するようなことを行う。イベントの処理が終了し、対象のサービスの再開を行った段階でイベントサーバは連携サーバに再開通知を送信する。また、連携サーバの管理者とイベントサーバの利用者に対しても再開の通知を行う（Ｓ２００−Ｓ２２０）。
【００４６】
次に、連携サーバがイベントサーバからイベント通知情報を受け取った場合の連携サービスの処理フローについて図１０を用いて説明する。
【００４７】
まず、接続しているイベントサーバからイベント通知情報を受信する。そして、イベント通知情報に記述されたイベントＩＤを基にイベント定義情報記憶部１４０を参照し、該当するイベント定義情報を取り出す（Ｓ３００、Ｓ３１０）。
【００４８】
取り出したイベント定義情報の連携サーバを調べて、その連携サーバがイベントサーバ以外の連携サーバ（この処理フローの連携サーバと区別するため、ここでは第２の連携サーバと言う）があれば通知の必要があると判断し、その第２の連携サーバにイベント通知情報を転送する。通知後、通知テーブルを作成する。通知テーブルは、第２の連携サーバ名とそれに完了フラグが設定できるものであればよい。第２の連携サーバへの通知が必要ない場合（イベント定義情報に連携サーバが設定されていない場合）は、次のステップに進む（Ｓ３２０−Ｓ３４０）。
【００４９】
次に、利用者への通知が必要かどうかを調べる。イベント定義情報の利用者通知先フィールドに利用者の通知先ファイル名が格納されていれば必要有りと判断し、そのファイルに記述されている利用者のメールアドレスにイベント通知情報の内容を電子メールで送信する。利用者への通知が不要の場合は、次のステップに進む。ここでの利用者は、連携サーバにおける当該イベントに関連するサービスの利用者である（Ｓ３５０、Ｓ３６０）。
【００５０】
連携サーバは、連携サーバの管理者にイベント通知情報の内容を電子メールで自動送信する。続いて、イベントに伴う措置を実行する。例えば、そのイベントが対象とするサービスのプログラムを停止する（Ｓ３７０、Ｓ３８０）。
【００５１】
ここで、連携サーバは先にイベント通知情報を転送した第２の連携サーバからの措置完了通知を待つ。第２の連携サーバから送信された措置完了通知を受信すると、通知テーブルのその措置完了通知を送信した第２の連携サーバ名に完了フラグを設定する。通知を行った全ての第２の連携サービスから措置完了通知を受信するまで通知待ちを行う（Ｓ３９０−Ｓ４１０）。
【００５２】
全ての第２の連携サーバから措置完了通知を受信したら（通知テーブルの完了フラグを参照することにより判断）、イベントサーバに措置完了通知を送信する（Ｓ４２０）。
【００５３】
続いて連携サーバは、イベントサーバからの再開通知を待ち、その通知を受信したら例えばイベントの措置で停止したサービスのプログラムを立ち上げ、利用者に対して再開通知の電子メールを送信する（Ｓ４３０、Ｓ４４０）。
【００５４】
図９と図１０で説明したフローは、サーバがその時の立場でイベントサーバになったり連携サーバになったりするので、それぞれのサーバには両方のプログラムが実装される。
【００５５】
また、図９で説明したフローでのイベントサーバと連携サーバで通知されるイベント通知情報と措置完了通知の例を図１１に示した。この図１１は、図５のイベントサーバと連携サーバにおいて通知される例である。イベントサーバであるサーバＡからはイベント通知情報が連携サーバＢとＣ１とに対して通知され、連携サーバＢとＣ１からイベントサーバに対しては措置完了通知が通知される。また、図示していないがそれぞれのシステムの管理者に対してもイベントの通知、再開の通知が電子メールで通知される。また、図示していないそれぞれのシステムの利用者に対しても、サービスの停止や再開かの通知が電子メールで通知される。
【００５６】
図９と図１０のフローで説明していないが、運用管理プログラムはイベント設定情報、イベント通知情報、措置完了通知、実行されたイベント等の履歴を適切なタイミングで履歴記憶部１５０に記憶している。この履歴情報は、例えばイベントの実行がなされた後日に問題が発生したとき、問題解析の情報や作業履歴の情報とするためである。
【００５７】
以上の実施例に関し、さらに以下の付記を開示する。
（付記１）
１つ以上のサーバがネットワークを介して接続されるイベントサーバの運用管理プログラムであって、
前記イベントサーバに、
前記イベントサーバで実行されるイベントの内容が記述されたイベント設定情報を予め用意されたイベント定義ファイルに基づいて解析するイベント解析手順と、
前記解析の結果に基づいて、前記１つ以上のサーバの中で前記イベントに関連する連携サーバにイベント通知情報を作成し、通知するイベント通知手順と、
前記連携サーバから、前記イベントに伴って該連携サーバ側で対処されるべき措置が完了した旨の措置完了通知を受信する措置完了通知受信手順と、
前記イベント情報通知を通知した全ての連携サーバから前記措置完了通知を受信したとき、前記イベントの処理を実行するイベント実行手順と、
を実行させるための運用管理プログラム。
（付記２）
前記運用管理プログラムは、さらに
前記１つ以上のサーバからイベント通知情報を受信したとき、該サーバとは別のサーバで該イベント通知情報のイベントに関連する連携サーバに該イベント通知情報を転送し、該イベントに伴う措置を行った後に該連携サーバでの該イベントに伴う措置が完了した旨の通知を受けて措置完了通知を該サーバに返信する、
ことを特徴とする付記１記載の運用管理プログラム。
（付記３）
前記運用管理プログラムは、さらに
前記イベント実行手順におけるイベントの実行後に該イベントのシステムを再開し、前記連携サーバと該連携サーバの管理者と前記利用者とにシステム再開の通知を行うシステム再開通知手順と、
を有することを特徴とする付記１または付記２記載の運用管理プログラム。
（付記４）
前記イベント通知手順は、
前記解析の結果に基づいて、前記１つ以上のサーバの中で前記イベントに関連する連携サーバにイベント通知情報を作成して通知を行うと共に、該連携サーバの管理者と前記イベントサーバの利用者とに対して該イベント通知情報の内容を通知する、
ことを特徴とする付記１乃至付記３記載の運用管理プログラム。
（付記５）
１つ以上のサーバがネットワークを介して接続されるイベントサーバの運用管理方法であって、
前記イベントサーバが、
前記イベントサーバで実行されるイベントの内容が記述されたイベント設定情報を予め用意されたイベント定義ファイルに基づいて解析するイベント解析手順と、
前記解析の結果に基づいて、前記１つ以上のサーバの中で前記イベントに関連する連携サーバにイベント通知情報を作成して通知するイベント通知手順と、
前記連携サーバから、前記イベントに伴って該連携サーバ側で対処されるべき措置が完了した旨の措置完了通知を受信する措置完了通知受信手順と、
前記イベント情報通知が通知された全ての連携サーバから前記措置完了通知を受信したとき、前記イベントの処理を実行するイベント実行手順と、
前記１つ以上のサーバから該サーバ側で実行されるイベントのイベント通知情報を受信したとき、該サーバとは別のサーバで該イベントに関連する連携サーバに該イベント通知情報を転送し、該イベントに伴う措置を行った後に該イベント通知情報を送信したサーバに措置完了通知を通知する連携イベント措置手順と、
を有することを特徴とする運用管理方法。
（付記６）
１つ以上のサーバがネットワークを介して接続されるイベントサーバの運用管理装置であって、
前記イベントサーバで実行されるイベントの内容が記述されたイベント設定情報を予め用意されたイベント定義ファイルに基づいて解析するイベント解析手段と、
前記解析の結果に基づいて、前記１つ以上のサーバの中で前記イベントに関連する連携サーバにイベント通知情報を作成して通知するイベント通知手段と、
前記連携サーバから、前記イベントに伴って該連携サーバ側で対処されるべき措置が完了した旨の措置完了通知を受信する措置完了通知受信手段と、
前記イベント情報通知が通知された全ての連携サーバから前記措置完了通知を受信したとき、前記イベントの処理を実行するイベント実行手段と、
前記１つ以上のサーバから該サーバ側で実行されるイベントのイベント通知情報を受信したとき、該サーバとは別のサーバで該イベントに関連する連携サーバに該イベント通知情報を転送し、該イベントに伴う措置を行った後に該イベント通知情報を送信したサーバに措置完了通知を通知する連携イベント措置手段と、
を有することを特徴とする運用管理装置。
【００５８】
（付記７）
前記イベント実行手順は、前記イベント情報通知が通知された全ての連携サーバから前記措置完了通知を受信したとき、前記イベントサーバの管理者に前記イベントの実行が可能の旨の実行準備完了通知を行うと共に、前記イベントの処理を実行する
ことを特徴とする付記１乃至付記４の運用管理プログラム。
【００５９】
（付記８）
前記サーバ運用管理プログラムは、さらに、
前記イベント設定情報、前記イベント通知情報、前記措置完了通知および実行されたイベントの履歴を記憶する履歴記憶手順、
を有することを特徴とする付記１乃至付記４記載の運用管理プログラム。
【図面の簡単な説明】
【００６０】
【図１】第１の発明の原理図である。
【図２】第２の発明の原理図である。
【図３】第３の発明の原理図である。
【図４】イベントサーバと連携サーバ例である。
【図５】イベントサーバの構成例ある。
【図６】イベント設定情報例である。
【図７】イベント通知情報例である。
【図８】イベント定義情報のデータ例ある。
【図９】イベントサーバの処理フロー例ある。
【図１０】連携サーバの処理フロー例である。
【図１１】イベントサーバと連携サーバ間の通知例である。
【符号の説明】
【００６１】
１０    イベント情報解析手順
２０    イベント通知手順
３０    措置完了通知受信手順
４０    イベント実行手順
５０    連携イベント措置手順
６０    システム再開通知手順
１００  イベントサーバ
１１０  ＣＰＵ
１２０  通信制御部
１２１  ネットワーク
１３０  入出力制御部
１３１  キーボード
１３２  ディスプレイ
１４０  イベント定義情報記憶部
１５０  履歴情報記憶部
１６０  運用管理プログラム
１６１  イベント設定部
１６２  イベント設定情報解析部
１６３  イベント通知部
１６４  措置完了通知受信部
１６５  イベント実行部
１６６  連携イベント措置部
【図１】
2007133545.tif 000003
【図２】
2007133545.tif 000004
【図３】
2007133545.tif 000005
【図４】
2007133545.tif 000006
【図５】
2007133545.tif 000007
【図６】
2007133545.tif 000008
【図７】
2007133545.tif 000009
【図８】
2007133545.tif 000010
【図９】
2007133545.tif 000011
【図１０】
2007133545.tif 000012
【図１１】
2007133545.tif 000013