JP7389370B2 - 運用装置、保守管理システム、運用方法およびプログラム - Google Patents

Description

本発明は、運用装置、保守管理システム、運用方法およびプログラムに関する。

ネットワーク環境の普及により、ネットワークを介して提供されるサービスの利用が拡大している。サービスの品質および障害発生の有無を監視し、必要に応じて解析および復旧を行うサービス保守作業が行われている。サービス保守作業は、作業者の知見とノウハウに基づく判断が中心となって実現されており手間や時間がかかる。特に近年は、Ｂ２Ｂ２Ｘの普及に伴い、複数サービスを連携させて提供するサービスが増加している。サービス保守作業も複数サービスを連携した保守および運用が必要となっている。

非特許文献１には、サービス保守作業を自動化する技術として、保全オペレーションの機能を部品化し、自律化することで、新たな運用部品をシステムに組み込むだけで自律的に動作を決定する自律制御ループ方式が提案されている。非特許文献１では、機能別に分けられた運用部品間でメッセージを送受信する。各運用部品は、受信したメッセージに基づいて自律的に動作する。

丹治直幸、外２名、「保守機能の部品化と自律化による自律制御ループ方式の提案」、電子情報通信学会技術研究報告、一般社団法人電子情報通信学会、2018年7月, Vol. 118, No. 118, pp. 13-18

非特許文献１の運用部品が実行する処理は、一から作りこんだ独自の処理であるため、システムに運用部品を追加するには期間とコストを要するという問題があった。新たに登場したサービスや既存のサービスなどの外部のシステムを利用する場合も、外部のシステムと連携する方法が確立されていないため、運用部品のそれぞれを外部のシステムに合わせて個別に作る必要がある。

本発明は、上記に鑑みてなされたものであり、自律制御ループ方式において、機能別に分けられた運用部品を短期間・低コストで導入することを目的とする。

本発明の一態様の運用装置は、サービスを保守管理する保守管理システムの一部として、メッセージを送受信して自律的に動作する運用装置であって、他の運用装置との間でブロードキャストによりメッセージを送受信するメッセージ送受信部と、アクションの実行契機および実行するアクションを含む発火ルールを保持する発火ルール保存部と、受信したメッセージを実行契機とする前記発火ルールのアクションを実行するアクション実行部と、を備え、前記アクション実行部は、アクションを実行する１つ以上のアクションモジュールと、前記発火ルールのアクションに対応するアクションモジュールのいずれかに前記アクションを実行させる実行部と、前記アクションモジュールの実行結果をメッセージに格納して他の運用装置へブロードキャスト送信する送信部と、を備え、前記発火ルールは、外部のシステムのインタフェースを示すアクションの実行形式と実行形式ごとに決められたアクション情報を含み、前記実行部は、前記実行形式に対応するアクションモジュールに前記アクション情報に基づくアクションを実行させる。

本発明によれば、自律制御ループ方式において、機能別に分けられた運用部品を短期間・低コストで導入することができる。

図１は、本実施形態の保守管理システムの全体構成の一例を示す図である。 図２は、保守管理システムが備える運用部品の構成例を示す図である。 図３は、アクション実行部の構成例を示す図である。 図４Ａは、発火ルールの一例を示す図である。 図４Ｂは、発火ルールの一例を示す図である。 図４Ｃは、発火ルールの一例を示す図である。 図５は、送受信されるメッセージの共通部の一例を示す図である。 図６は、完了後発行メッセージを定義した発火ルールの一例を示す図である。 図７は、運用部品の処理の流れを示すシーケンス図である。 図８は、運用部品のハードウェア構成の一例を示す図である。

図１を参照し、本実施形態の保守管理システムについて説明する。本実施形態の保守管理システムは、互いに接続関係を持たない運用部品１０－１～１０－６が、能動的にサービスおよびアラームの状況を確認し、必要な処理を自律的に判断して実行する自律制御ループ方式を採用している。

運用部品１０－１～１０－６は、自律的に動作する装置またはプロセスである。運用部品１０－１～１０－６のそれぞれは、保守機能の単位で部品化されたものであり、各自が特定の保守機能を有する。例えば、運用部品１０－１～１０－６は、情報収集、情報加工、情報解析、試験、構成変更、および保守者ＵＩの６つの機能種別に分類される。各種別の運用部品の概要を以下に示す。

［情報収集］保守対象のサービス環境から情報収集を行う。
［情報加工］ノイズ除去、相関関係算出、特徴・キーワード抽出、および統計処理など不可逆的な時系列・文字列処理と可視化を行う。
［情報解析］異常判定やクラスタリングのための分類、予測、および状態推定などの情報解析と解析結果の生成を行う。
［試験］試験トラフィックの生成と送信を行う。
［構成変更］サービスに対する具体的な変更オペレーションを行う。
［保守者ＵＩ］保守者が運用部品を制御するためのユーザインタフェースを提供する。

なお、保守管理システムは、上記の６つの種別の運用部品を全て備えなくてもよいし、上記の種別以外の運用部品を備えてもよい。また、保守管理システムは、同じ種別の運用部品を複数備えてもよい。例えば、複数のサービスを連携させて提供されるサービスを保守する場合、複数のサービスのそれぞれについて、上記の種別の運用部品を備える。

運用部品１０－１～１０－６は、メッセージバス３０を介してメッセージを送受信する。運用部品１０－１～１０－６は、メッセージと自身の保持する発火ルールに基づき、アクションを実行するか、何もしないかを決定する。

メッセージは、メッセージバス３０を介して全ての運用部品１０－１～１０－６にブロードキャストされる。メッセージは、ＸＭＬやＪＳＯＮなどの構造体である。メッセージは、全てのメッセージに共通する共通部と、メッセージ種別ごとに異なる個別部から構成される。共通部は、例えば、メッセージを識別するＩＤ、メッセージ種別、メッセージの送信時刻、およびメッセージ送信元の運用部品の機能種別と名称などを含む。本実施形態では、共通部を拡張し、メッセージ種別に応じたデータを設定する領域を設ける。この領域にアクション実行結果を格納する。例えば、個別部は、メッセージ種別がＲｅｐｌｙであれば、返信元のメッセージ識別子と応答内容を含む。個別部は、メッセージ種別がＲｅｑｕｅｓｔであれば、情報の収集間隔など要求内容を含む。

発火ルールは、運用部品１０－１～１０－６のそれぞれが適切なアクションを実行するための判断基準であり、アクションの実行契機と実行するアクションに関する情報を含む。アクションとは、運用部品１０－１～１０－６のそれぞれが実行する処理である。本実施形態では、発火ルールを拡張し、発火ルールに、アクションの実行形式およびメッセージに格納するアクション実行結果の定義を含ませる。運用部品１０－１～１０－６のそれぞれは、個別に発火ルールを保持する。

具体例として、運用部品１０－１～１０－６のそれぞれが保持する発火ルールの概要の一例を以下に示す。

［情報収集］一定時間の経過を契機に、収集アクションを実行する。
［情報加工］収集通知を契機に、可視化アクションを実行する。
［情報解析］収集通知を契機に、異常検知アクションを実行する。試験の実施通知を契機に、試験結果判断アクションを実行する。
［試験］異常検知の結果通知を契機に、試験の実施可否を伺うメッセージを送信する。試験の実施許可通知を契機に、試験アクションを実行する。
［構成変更］試験結果を契機に、再起動アクションまたは変更アクションの実施可否を伺うメッセージを送信する。実施可否メッセージに対する応答を契機に、対応するアクションを実行する。
［保守者ＵＩ］保守者判断が必要な実施可否メッセージを契機に、保守者を呼び出すアクションを実行する。

ここで、各運用部品１０－１～１０－６の連携例を示す。以下では、運用部品１０－１～１０－６のそれぞれを「情報収集機能部品」、「情報加工機能部品」、「情報解析機能部品」、「試験機能部品」、「構成変更機能部品」、および「保守者ＵＩ機能部品」として説明する。

まず、情報収集機能部品は、自身の発火ルール（例えばタイマー満了など）により情報収集を実施し、情報収集した結果を含むメッセージをブロードキャストする。

情報収集結果を契機として、情報加工機能部品が収集された情報を加工し、加工後の情報を含むメッセージをブロードキャストする。

情報の加工を契機として、情報解析機能部品は、加工された情報から異常を検知し、異常検知結果を含むメッセージをブロードキャストする。

異常検知結果を契機として、試験機能部品は、試験を選定し、選定した試験の実施伺いメッセージをブロードキャストする。

実施伺いメッセージを契機として、保守者ＵＩ機能部品は、保守者から試験の実施許可を得て、実施許可メッセージをブロードキャストする。

実施許可を契機として、試験機能部品は、試験を実施し、試験結果を含むメッセージをブロードキャストする。

試験結果を契機として、構成変更機能部品は、検知された異常について、構成変更機能部品が実施可能なオペレーションを選定し、選定したオペレーションの実施伺いメッセージをブロードキャストする。

実施伺いメッセージを契機として、保守者ＵＩ機能部品は、保守者からオペレーションの実施許可を得て、実施許可メッセージをブロードキャストする。

実施許可を契機として、構成変更機能部品は、オペレーションを実施し、実施結果を含むメッセージをブロードキャストする。

このように、保守管理システムでは、運用部品１０－１～１０－６が能動的に状況を確認し、必要なアクションを自律的に判断して動作する。

運用部品１０－１～１０－６は、運用部品１０－１～１０－６のそれぞれで共通的に活用する情報を共通データ保存部２０に保存するとともに、共通データ保存部２０から情報を取得して利用する。

図２を参照し、保守管理システムが備える運用部品の構成について説明する。図１の運用部品１０－１～１０－６は、図２に示す運用部品１０と同じ構成である。以下、運用部品１０－１～１０－６を区別する必要がない場合は、単に運用部品１０と称することもある。

運用部品１０は、メッセージ送受信部１１、データ・状態保存部１２、発火ルール保存部１３、ルール実行部１４、およびアクション実行部１５を備える。

メッセージ送受信部１１は、メッセージバス３０を介して、メッセージを送受信する。メッセージは、メッセージバス３０を介して、全ての運用部品１０－１～１０－６にブロードキャストされる。

データ・状態保存部１２は、受信したメッセージ、アクション実行部１５の実行結果などのデータおよび状態を保持する。データ・状態保存部１２は、共通データ保存部２０から取得したデータを保持してもよいし、共通データ保存部２０に格納するデータを一時的に保持して、共通データ保存部２０にデータを格納してもよい。データ・状態保存部１２の保持するデータおよび状態は、アクション実行部１５がアクションを実行する際に利用してもよい。

発火ルール保存部１３は、アクションの実行契機、アクションに関する情報を運用部品１０－１～１０－６ごとに個別に定義した発火ルールを保持する。発火ルールは、アクションに関する情報として、アクション実行形式とアクション完了時のメッセージに含める実行結果の定義を含む。発火ルールは、送信するリクエストの内容または実行するコマンドなどの実行形式ごとに決められたアクション情報を含む。発火ルールの詳細については後述する。

ルール実行部１４は、受信したメッセージと発火ルール保存部１３に保存された発火ルールに基づき、アクションの実行契機を監視する。ルール実行部１４は、実行すべきアクションを認識すると、該当するアクションの実行をアクション実行部１５に指示する。より具体的には、ルール実行部１４は、メッセージ送受信部１１が受信したメッセージの種別をアクションの実行契機とする発火ルールが発火ルール保存部１３に保存されているか否か判定する。該当する発火ルールが保存されている場合、ルール実行部１４は、発火ルールからアクション実行形式とアクションに関する情報を取得してアクション実行部１５に通知する。ルール実行部１４は、発火ルールをアクション実行部１５に渡して、アクションの実行を指示してもよい。また、ルール実行部１４は、アクションの実行契機となったメッセージをアクション実行部１５に渡してもよい。

アクション実行部１５は、ルール実行部１４からの指示を受けて、指定の実行形式でアクションを実行する。アクションが完了すると、アクション実行部１５は、メッセージ送受信部１１に対して、アクションの実行結果を含むメッセージの送信を指示する。

図３を参照し、アクション実行部１５について説明する。同図に示すように、アクション実行部１５は、アクションモジュール実行部１５１、メッセージ送信指示部１５２、および１つ以上のアクションモジュール１５３－１～１５３－３を備える。

アクションモジュール実行部１５１は、指定の実行形式に対応するアクションモジュール１５３－１～１５３－３に、アクションに関する情報を渡して、アクションを実行させる。アクションモジュール実行部１５１は、アクションの実行に必要な情報をデータ・状態保存部１２および共通データ保存部２０から取得してアクションモジュール１５３－１～１５３－３に渡してもよい。

メッセージ送信指示部１５２は、メッセージ送受信部１１に対して、アクションモジュール１５３－１～１５３－３の実行結果を格納したメッセージの送信を指示する。

アクションモジュール実行部１５１とメッセージ送信指示部１５２でアクション連携部１５０を構成する。運用部品１０－１～１０－６のそれぞれは、共通のアクション連携部１５０を備える。

アクションモジュール１５３－１～１５３－３は、運用部品１０－１～１０－６が担う機能を実現するアクションを実行するモジュールである。図３では、３つのアクションモジュール１５３－１～１５３－３を示しているが、これに限定するものではない。

アクションモジュールは、独自の処理を実行するアクションモジュール１５３－１と、決められた実行形式で処理を実行するアクションモジュール１５３－２，１５３－３に分類される。アクションモジュール１５３－２，１５３－３のぞれぞれは、異なる実行形式で処理を実行する。アクションモジュール１５３－２，１５３－３は、決められた実行形式で、外部の保守システム５０－２，５０－３に対する処理を実行する。図３では、アプリケーションプログラミングインタフェース（ＡＰＩ）により処理を実行するアクションモジュール１５３－２と、コマンドラインインタフェース（ＣＬＩ）により処理を実行するアクションモジュール１５３－３を図示している。保守システム５０－２は、ＡＰＩによりサービスを提供するシステムである。保守システム５０－３は、コマンドを受け付けてサービスを提供するシステムである。

保守システム５０－２，５０－３の実行形式ごとにアクションモジュール１５３－２，１５３－３を用意することで、運用部品１０－１～１０－６は、共通のアクションモジュール１５３－２，１５３－３を用いることができる。例えば、ＨＴＴＰリクエストによりサービスを提供する外部のシステムにはアクションモジュール１５３－２を用いることができ、コマンドによりサービスを提供する外部のシステムにはアクションモジュール１５３－３を用いることができる。外部のシステムを利用する運用部品１０－１～１０－６は、外部のシステムのインタフェースに合わせたアクションモジュール１５３－２，１５３－３を備え、発火ルールに外部のシステムを利用するためのリクエストまたはコマンドを記載すればよい。

図４Ａ、図４Ｂ、および図４Ｃを参照し、アクションモジュール１５３－１～１５３－３に対応するアクション実行形式を含む発火ルールについて説明する。

図４Ａ，図４Ｂ，および図４Ｃは、発火ルール保存部１３が保持する発火ルールの一例を示す図である。発火ルールは、メッセージ種別、アクション実行形式、アクション、およびアクション個別情報を含む。メッセージ種別には、アクションを実行する契機となるメッセージを定義する。アクション実行形式には、アクションを実行するアクションモジュール１５３－１～１５３－３を特定するための情報を定義する。アクションには、アクションモジュール１５３－１～１５３－３が実行するアクションを定義する。アクション個別情報には、アクションの実行に必要な情報を定義する。

図４Ａは、アクションモジュール１５３－１が独自の処理のアクションを実行する発火ルールの一例である。アクション実行部１５は、図４Ａのアクションをアクションモジュール１５３－１に渡す。アクションモジュール１５３－１は指定されたアクションを実行する。

図４Ｂは、アクションモジュール１５３－２がＡＰＩを用いてアクションを実行する発火ルールの一例である。アクション実行部１５は、図４Ｂのアクションおよびアクション個別情報をアクションモジュール１５３－２に渡す。アクションモジュール１５３－２は、アクションで指定されたＵＲＬにアクション個別情報に記載された内容のリクエストを送信する。また、アクション個別情報には、“｛ｓａｍｐｌｅＩｄ｝”のように、メッセージ内容で置換される変数値を含めてもよい。

図４Ｃは、アクションモジュール１５３－３がコマンドを入力してアクションを実行する発火ルールの一例である。アクション実行部１５は、図４Ｃのアクションをアクションモジュール１５３－３に渡す。アクションモジュール１５３－３は、保守システム５０－３にアクセスし、アクションで指定されたコマンドを入力して実行する。アクション個別情報に、コマンドに付加するオプションを定義してもよい。

非特許文献１の従来技術では、発火ルールにメッセージ種別とアクションのみを含んでいた。アクション実行部は、アクションが指定されると、アクション実行部に定義された独自の処理を実行していた。本実施形態では、発火ルールにアクション実行形式を含めることで、アクションを実行するアクションモジュールを指定可能とし、運用部品１０－１～１０－６間でアクションモジュールを共通化できる。運用部品１０－１～１０－６が、外部のシステムを利用せずに、独自の処理を実行する場合は、独自の処理を実行するアクションモジュール１５３－１を作成すればよい。

図５，６を参照し、アクションの個別の実行結果を同一フォーマットでメッセージ化する方法について説明する。

図５に示すメッセージの共通部は、メッセージ種別に応じたデータを設定する領域（ｕｎｉｑｕｅＤａｔａ）を含む。メッセージ送信指示部１５２は、アクションモジュール１５３－１～１５３－３からアクションの実行結果を受け取ると、この領域にアクションの実行結果を含めたメッセージの送信をメッセージ送受信部１１に指示する。

図６に示すように、発火ルールに、メッセージに含めるアクションの実行結果を定義しておく。図６は、図４Ｂの発火ルールを拡張したものである。完了後発行メッセージには、アクションの実行結果を含めるメッセージ種別を定義する。完了後発行メッセージ個別情報には、メッセージ共通部のｕｎｉｑｕｅＤａｔａに格納する実行結果を定義する。完了後発行メッセージ個別情報には、“｛＄ｒｅｓｕｌｔ｝”のように、実行結果の情報で置換される変数値を含めてもよい。例えば、アクションモジュール１５３－２が送信したリクエストに対するレスポンスの本体部分を含める。

なお、図４Ａおよび図４Ｃの発火ルールにも完了後発行メッセージを定義してもよい。

図７を参照し、運用部品１０の動作について説明する。

ステップＳ１０にて、メッセージ送受信部１１は、メッセージバス３０からメッセージを受信する。

ステップＳ１１にて、ルール実行部１４は、発火ルール保存部１３にメッセージに該当する発火ルールが存在するか否か、つまりアクションの実行契機であるか否かを判定する。受信したメッセージがアクションの実行契機でない場合は、運用部品１０は処理を終了する。

メッセージに該当する発火ルールが存在する場合、ステップＳ１２にて、ルール実行部１４は、アクションモジュール実行部１５１に対して、発火ルールのアクション実行形式で、指定のアクションを実行する指示を出す。

ステップＳ１３にて、アクションモジュール実行部１５１は、アクション実行形式に該当するアクションモジュール１５３－１～１５３－３を選択し、指定のアクションを実行させる。

独自の処理を実行するアクションモジュール１５３－１が選択された場合、ステップＳ１４－１にて、アクションモジュール１５３－１は、独自の処理を実行し、保守対象のサービス環境から情報を取得したり、サービス環境に対して試験を行ったりする。アクションモジュール１５３－１は、サービス環境に対する処理以外の処理を行ってもよい。

ステップＳ１５－１にて、アクションモジュール１５３－１は、サービス環境からアクション実行結果を得る。

ＡＰＩを用いるアクションモジュール１５３－２が選択された場合、ステップＳ１４－２にて、アクションモジュール１５３－２は、保守システム５０－２に対して、ＡＰＩを用いたリクエストを送信する。保守システム５０－２は、リクエストに応じた処理を実行する。

ステップＳ１５－２にて、アクションモジュール１５３－２は、保守システム５０－２からレスポンスを受信する。

ＣＬＩを用いるアクションモジュール１５３－３が選択された場合、ステップＳ１４－３にて、アクションモジュール１５３－３は、保守システム５０－３に対して、指定のコマンドの実行を依頼する。保守システム５０－３は、コマンドに応じた処理を実行する。

ステップＳ１５－３にて、アクションモジュール１５３－３は、保守システム５０－３からコマンドの実行結果を得る。

ステップＳ１６にて、メッセージ送信指示部１５２は、アクションモジュール１５３－１～１５３－３からアクション実行結果を取得する。

ステップＳ１７にて、メッセージ送信指示部１５２は、メッセージ送受信部１１に対して、アクション実行結果を含むメッセージの送信を指示する。

ステップＳ１８にて、メッセージ送受信部１１は、メッセージバス３０に対して、アクション実行結果を含むメッセージを送信する。

メッセージバス３０に送信されたメッセージは、全ての運用部品１０－１～１０－６にブロードキャストされる。各運用部品１０－１～１０－６は、メッセージを受信し、ステップＳ１０からの処理を実行する。

以上説明したように、本実施形態の運用部品１０は、サービスを保守管理する保守管理システムの一部として、メッセージを送受信して自律的に動作する運用部品１０であって、他の運用部品１０との間でメッセージを送受信するメッセージ送受信部１１と、アクションの実行契機および実行するアクションを含む発火ルールを保持する発火ルール保存部１３と、受信したメッセージを実行契機とする発火ルールのアクションを実行するアクション実行部１５と、を備える。アクション実行部１５は、アクションを実行する１つ以上のアクションモジュール１５３－１～１５３－３と、発火ルールのアクションに対応するアクションモジュール１５３－１～１５３－３のいずれかにアクションを実行させるアクションモジュール実行部１５１と、アクションモジュールの実行結果をメッセージに格納して送信するメッセージ送信指示部１５２を備える。これにより、発火ルールを作成し、発火ルールのアクションを実行するアクションモジュール１５３－１～１５３－３を作成するだけで、運用部品１０を導入することができる。

本実施形態の運用部品１０は、発火ルールがアクション実行形式と実行形式ごとに決められたアクション情報を含み、アクションモジュール実行部１５１が、実行形式に対応するアクションモジュール１５３－２，１５３－３にアクション情報に基づくアクションを実行させる。これにより、運用部品１０は、アクションモジュール１５３－２，１５３－３を備えるだけで、ＨＴＴＰリクエストまたはシェルコマンドなど、様々な形式の外部のシステムを容易に利用できるので、外部のシステムを利用する運用部品１０を短期間・低コストで導入できる。

本実施形態の運用部品１０は、メッセージにアクションの実行結果を含む領域を有し、発火ルールに、メッセージに含めるアクションの実行結果を定義する。これにより、運用部品１０の個別の実行結果をメッセージ化でき、運用部品１０間で実行結果を利用しやすくなる。

上記説明した運用部品１０には、例えば、図８に示すような、中央演算処理装置（ＣＰＵ）９０１と、メモリ９０２と、ストレージ９０３と、通信装置９０４と、入力装置９０５と、出力装置９０６とを備える汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵ９０１がメモリ９０２上にロードされた所定のプログラムを実行することにより、運用部品１０が実現される。このプログラムは磁気ディスク、光ディスク、半導体メモリ等のコンピュータ読み取り可能な記録媒体に記録することも、ネットワークを介して配信することもできる。

なお、１台のコンピュータが１つの運用部品１０として動作してもよいし、複数の運用部品１０として動作してもよい。また、クラウド上で動作する仮想マシンを運用部品１０として動作させてもよい。

１０，１０－１～１０－６…運用部品
１１…メッセージ送受信部
１２…データ・状態保存部
１３…発火ルール保存部
１４…ルール実行部
１５…アクション実行部
１５０…アクション連携部
１５１…アクションモジュール実行部
１５２…メッセージ送信指示部
１５３－１～１５３－３…アクションモジュール
２０…共通データ保存部
３０…メッセージバス

Claims (6)

1. サービスを保守管理する保守管理システムの一部として、メッセージを送受信して自律的に動作する運用装置であって、
   他の運用装置との間でブロードキャストによりメッセージを送受信するメッセージ送受信部と、
   アクションの実行契機および実行するアクションを含む発火ルールを保持する発火ルール保存部と、
   受信したメッセージを実行契機とする前記発火ルールのアクションを実行するアクション実行部と、を備え、
   前記アクション実行部は、
   アクションを実行する１つ以上のアクションモジュールと、
   前記発火ルールのアクションに対応するアクションモジュールのいずれかに前記アクションを実行させる実行部と、
   前記アクションモジュールの実行結果をメッセージに格納して他の運用装置へブロードキャスト送信する送信部と、を備え、
   前記発火ルールは、外部のシステムのインタフェースを示すアクションの実行形式と実行形式ごとに決められたアクション情報を含み、
   前記実行部は、前記実行形式に対応するアクションモジュールに前記アクション情報に基づくアクションを実行させる
   運用装置。
2. 請求項１に記載の運用装置であって、
   前記メッセージは、前記アクションの実行結果を含む領域を有し、
   前記発火ルールは、前記アクションの実行結果を前記メッセージに含める定義を有する
   運用装置。
3. メッセージを送受信して自律的に動作する複数の運用装置を備えてサービスを保守管理する保守管理システムであって、
   前記運用装置は、
   他の運用装置との間でブロードキャストによりメッセージを送受信するメッセージ送受信部と、
   アクションの実行契機および実行するアクションを含む発火ルールを保持する発火ルール保存部と、
   受信したメッセージを実行契機とする前記発火ルールのアクションを実行するアクション実行部と、を備え、
   前記アクション実行部は、
   アクションを実行する１つ以上のアクションモジュールと、
   前記発火ルールのアクションに対応するアクションモジュールのいずれかに前記アクションを実行させる実行部と、
   前記アクションモジュールの実行結果をメッセージに格納して他の運用装置へブロードキャスト送信する送信部と、を備え、
   前記発火ルールは、外部のシステムのインタフェースを示すアクションの実行形式と実行形式ごとに決められたアクション情報を含み、
   前記実行部は、前記実行形式に対応するアクションモジュールに前記アクション情報に基づくアクションを実行させる
   保守管理システム。
4. サービスを保守管理する保守管理システムの一部として、メッセージを送受信して自律的に動作する運用装置の実行する運用方法であって、
   前記運用装置は、アクションの実行契機および実行するアクションを含む発火ルールを保持しており、
   他の運用装置との間でブロードキャストによりメッセージを送受信するステップと、
   受信したメッセージを実行契機とする前記発火ルールのアクションを実行するステップと、を有し、
   前記アクションを実行するステップでは、
   前記発火ルールのアクションに対応するアクションモジュールのいずれかに前記アクションを実行させるステップと、
   前記アクションモジュールの実行結果をメッセージに格納して他の運用装置へブロードキャスト送信するステップと、を有し、
   前記発火ルールは、外部のシステムのインタフェースを示すアクションの実行形式と実行形式ごとに決められたアクション情報を含み、
   前記アクションを実行させるステップでは、前記実行形式に対応するアクションモジュールに前記アクション情報に基づくアクションを実行させる
   運用方法。
5. 請求項４に記載の運用方法であって、
   前記メッセージは、前記アクションの実行結果を含む領域を有し、
   前記発火ルールは、前記アクションの実行結果を前記メッセージに含める定義を有する
   運用方法。
6. 請求項１または２に記載の運用装置としてコンピュータを動作させるプログラム。

Images