(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-11-21
(45)【発行日】2023-11-30
(54)【発明の名称】運用装置、保守管理システム、運用方法およびプログラム
(51)【国際特許分類】
G06F 11/07 20060101AFI20231122BHJP
【FI】
G06F11/07 193
(21)【出願番号】P 2021554530
(86)(22)【出願日】2019-11-08
(86)【国際出願番号】 JP2019043807
(87)【国際公開番号】W WO2021090470
(87)【国際公開日】2021-05-14
【審査請求日】2022-04-04
(73)【特許権者】
【識別番号】000004226
【氏名又は名称】日本電信電話株式会社
(74)【代理人】
【識別番号】100083806
【氏名又は名称】三好 秀和
(74)【代理人】
【識別番号】100129230
【氏名又は名称】工藤 理恵
(72)【発明者】
【氏名】池谷 友基
(72)【発明者】
【氏名】高橋 謙輔
(72)【発明者】
【氏名】近藤 悟
【審査官】吉田 歩
(56)【参考文献】
【文献】特開2015-026154(JP,A)
【文献】特開2012-043121(JP,A)
【文献】米国特許出願公開第2017/0091007(US,A1)
【文献】田中 慎司,はてな流!システム管理のツボ,SoftwareDesign,日本,(株)技術評論社,2008年10月18日,第216号,pp.172-177,ISSN:0916-6297
(58)【調査した分野】(Int.Cl.,DB名)
G06F 11/07
(57)【特許請求の範囲】
【請求項1】
サービスを保守管理する保守管理システムの一部として、メッセージを送受信して自律的に動作する運用装置であって、
他の運用装置との間で
ブロードキャストによりメッセージを送受信するメッセージ送受信部と、
アクションの実行契機および実行するアクションを含む発火ルールを保持する発火ルール保存部と、
受信したメッセージを実行契機とする前記発火ルールのアクションを実行するアクション実行部と、を備え、
前記アクション実行部は、
アクションを実行する1つ以上のアクションモジュールと、
前記発火ルールのアクションに対応するアクションモジュールのいずれかに前記アクションを実行させる実行部と、
前記アクションモジュールの実行結果をメッセージに格納して
他の運用装置へブロードキャスト送信する送信部と、を備え
、
前記発火ルールは、外部のシステムのインタフェースを示すアクションの実行形式と実行形式ごとに決められたアクション情報を含み、
前記実行部は、前記実行形式に対応するアクションモジュールに前記アクション情報に基づくアクションを実行させる
運用装置。
【請求項2】
請求項
1に記載の運用装置であって、
前記メッセージは、前記アクションの実行結果を含む領域を有し、
前記発火ルールは、前記アクションの実行結果を前記メッセージに含める定義を有する
運用装置。
【請求項3】
メッセージを送受信して自律的に動作する複数の運用装置を備えてサービスを保守管理する保守管理システムであって、
前記運用装置は、
他の運用装置との間で
ブロードキャストによりメッセージを送受信するメッセージ送受信部と、
アクションの実行契機および実行するアクションを含む発火ルールを保持する発火ルール保存部と、
受信したメッセージを実行契機とする前記発火ルールのアクションを実行するアクション実行部と、を備え、
前記アクション実行部は、
アクションを実行する1つ以上のアクションモジュールと、
前記発火ルールのアクションに対応するアクションモジュールのいずれかに前記アクションを実行させる実行部と、
前記アクションモジュールの実行結果をメッセージに格納して
他の運用装置へブロードキャスト送信する送信部と、を備え
、
前記発火ルールは、外部のシステムのインタフェースを示すアクションの実行形式と実行形式ごとに決められたアクション情報を含み、
前記実行部は、前記実行形式に対応するアクションモジュールに前記アクション情報に基づくアクションを実行させる
保守管理システム。
【請求項4】
サービスを保守管理する保守管理システムの一部として、メッセージを送受信して自律的に動作する運用装置の実行する運用方法であって、
前記運用装置は、アクションの実行契機および実行するアクションを含む発火ルールを保持しており、
他の運用装置との間で
ブロードキャストによりメッセージを送受信するステップと、
受信したメッセージを実行契機とする前記発火ルールのアクションを実行するステップと、を有し、
前記アクションを実行するステップでは、
前記発火ルールのアクションに対応するアクションモジュールのいずれかに前記アクションを実行させるステップと、
前記アクションモジュールの実行結果をメッセージに格納して
他の運用装置へブロードキャスト送信するステップと、を有
し、
前記発火ルールは、外部のシステムのインタフェースを示すアクションの実行形式と実行形式ごとに決められたアクション情報を含み、
前記アクションを実行させるステップでは、前記実行形式に対応するアクションモジュールに前記アクション情報に基づくアクションを実行させる
運用方法。
【請求項5】
請求項
4に記載の運用方法であって、
前記メッセージは、前記アクションの実行結果を含む領域を有し、
前記発火ルールは、前記アクションの実行結果を前記メッセージに含める定義を有する
運用方法。
【請求項6】
請求項
1または2に記載の運用装置としてコンピュータを動作させるプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、運用装置、保守管理システム、運用方法およびプログラムに関する。
【背景技術】
【0002】
ネットワーク環境の普及により、ネットワークを介して提供されるサービスの利用が拡大している。サービスの品質および障害発生の有無を監視し、必要に応じて解析および復旧を行うサービス保守作業が行われている。サービス保守作業は、作業者の知見とノウハウに基づく判断が中心となって実現されており手間や時間がかかる。特に近年は、B2B2Xの普及に伴い、複数サービスを連携させて提供するサービスが増加している。サービス保守作業も複数サービスを連携した保守および運用が必要となっている。
【0003】
非特許文献1には、サービス保守作業を自動化する技術として、保全オペレーションの機能を部品化し、自律化することで、新たな運用部品をシステムに組み込むだけで自律的に動作を決定する自律制御ループ方式が提案されている。非特許文献1では、機能別に分けられた運用部品間でメッセージを送受信する。各運用部品は、受信したメッセージに基づいて自律的に動作する。
【先行技術文献】
【非特許文献】
【0004】
【文献】丹治直幸、外2名、「保守機能の部品化と自律化による自律制御ループ方式の提案」、電子情報通信学会技術研究報告、一般社団法人電子情報通信学会、2018年7月, Vol. 118, No. 118, pp. 13-18
【発明の概要】
【発明が解決しようとする課題】
【0005】
非特許文献1の運用部品が実行する処理は、一から作りこんだ独自の処理であるため、システムに運用部品を追加するには期間とコストを要するという問題があった。新たに登場したサービスや既存のサービスなどの外部のシステムを利用する場合も、外部のシステムと連携する方法が確立されていないため、運用部品のそれぞれを外部のシステムに合わせて個別に作る必要がある。
【0006】
本発明は、上記に鑑みてなされたものであり、自律制御ループ方式において、機能別に分けられた運用部品を短期間・低コストで導入することを目的とする。
【課題を解決するための手段】
【0007】
本発明の一態様の運用装置は、サービスを保守管理する保守管理システムの一部として、メッセージを送受信して自律的に動作する運用装置であって、他の運用装置との間でブロードキャストによりメッセージを送受信するメッセージ送受信部と、アクションの実行契機および実行するアクションを含む発火ルールを保持する発火ルール保存部と、受信したメッセージを実行契機とする前記発火ルールのアクションを実行するアクション実行部と、を備え、前記アクション実行部は、アクションを実行する1つ以上のアクションモジュールと、前記発火ルールのアクションに対応するアクションモジュールのいずれかに前記アクションを実行させる実行部と、前記アクションモジュールの実行結果をメッセージに格納して他の運用装置へブロードキャスト送信する送信部と、を備え、前記発火ルールは、外部のシステムのインタフェースを示すアクションの実行形式と実行形式ごとに決められたアクション情報を含み、前記実行部は、前記実行形式に対応するアクションモジュールに前記アクション情報に基づくアクションを実行させる。
【発明の効果】
【0008】
本発明によれば、自律制御ループ方式において、機能別に分けられた運用部品を短期間・低コストで導入することができる。
【図面の簡単な説明】
【0009】
【
図1】
図1は、本実施形態の保守管理システムの全体構成の一例を示す図である。
【
図2】
図2は、保守管理システムが備える運用部品の構成例を示す図である。
【
図3】
図3は、アクション実行部の構成例を示す図である。
【
図5】
図5は、送受信されるメッセージの共通部の一例を示す図である。
【
図6】
図6は、完了後発行メッセージを定義した発火ルールの一例を示す図である。
【
図7】
図7は、運用部品の処理の流れを示すシーケンス図である。
【
図8】
図8は、運用部品のハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【0010】
図1を参照し、本実施形態の保守管理システムについて説明する。本実施形態の保守管理システムは、互いに接続関係を持たない運用部品10-1~10-6が、能動的にサービスおよびアラームの状況を確認し、必要な処理を自律的に判断して実行する自律制御ループ方式を採用している。
【0011】
運用部品10-1~10-6は、自律的に動作する装置またはプロセスである。運用部品10-1~10-6のそれぞれは、保守機能の単位で部品化されたものであり、各自が特定の保守機能を有する。例えば、運用部品10-1~10-6は、情報収集、情報加工、情報解析、試験、構成変更、および保守者UIの6つの機能種別に分類される。各種別の運用部品の概要を以下に示す。
【0012】
[情報収集]保守対象のサービス環境から情報収集を行う。
[情報加工]ノイズ除去、相関関係算出、特徴・キーワード抽出、および統計処理など不可逆的な時系列・文字列処理と可視化を行う。
[情報解析]異常判定やクラスタリングのための分類、予測、および状態推定などの情報解析と解析結果の生成を行う。
[試験]試験トラフィックの生成と送信を行う。
[構成変更]サービスに対する具体的な変更オペレーションを行う。
[保守者UI]保守者が運用部品を制御するためのユーザインタフェースを提供する。
【0013】
なお、保守管理システムは、上記の6つの種別の運用部品を全て備えなくてもよいし、上記の種別以外の運用部品を備えてもよい。また、保守管理システムは、同じ種別の運用部品を複数備えてもよい。例えば、複数のサービスを連携させて提供されるサービスを保守する場合、複数のサービスのそれぞれについて、上記の種別の運用部品を備える。
【0014】
運用部品10-1~10-6は、メッセージバス30を介してメッセージを送受信する。運用部品10-1~10-6は、メッセージと自身の保持する発火ルールに基づき、アクションを実行するか、何もしないかを決定する。
【0015】
メッセージは、メッセージバス30を介して全ての運用部品10-1~10-6にブロードキャストされる。メッセージは、XMLやJSONなどの構造体である。メッセージは、全てのメッセージに共通する共通部と、メッセージ種別ごとに異なる個別部から構成される。共通部は、例えば、メッセージを識別するID、メッセージ種別、メッセージの送信時刻、およびメッセージ送信元の運用部品の機能種別と名称などを含む。本実施形態では、共通部を拡張し、メッセージ種別に応じたデータを設定する領域を設ける。この領域にアクション実行結果を格納する。例えば、個別部は、メッセージ種別がReplyであれば、返信元のメッセージ識別子と応答内容を含む。個別部は、メッセージ種別がRequestであれば、情報の収集間隔など要求内容を含む。
【0016】
発火ルールは、運用部品10-1~10-6のそれぞれが適切なアクションを実行するための判断基準であり、アクションの実行契機と実行するアクションに関する情報を含む。アクションとは、運用部品10-1~10-6のそれぞれが実行する処理である。本実施形態では、発火ルールを拡張し、発火ルールに、アクションの実行形式およびメッセージに格納するアクション実行結果の定義を含ませる。運用部品10-1~10-6のそれぞれは、個別に発火ルールを保持する。
【0017】
具体例として、運用部品10-1~10-6のそれぞれが保持する発火ルールの概要の一例を以下に示す。
【0018】
[情報収集]一定時間の経過を契機に、収集アクションを実行する。
[情報加工]収集通知を契機に、可視化アクションを実行する。
[情報解析]収集通知を契機に、異常検知アクションを実行する。試験の実施通知を契機に、試験結果判断アクションを実行する。
[試験]異常検知の結果通知を契機に、試験の実施可否を伺うメッセージを送信する。試験の実施許可通知を契機に、試験アクションを実行する。
[構成変更]試験結果を契機に、再起動アクションまたは変更アクションの実施可否を伺うメッセージを送信する。実施可否メッセージに対する応答を契機に、対応するアクションを実行する。
[保守者UI]保守者判断が必要な実施可否メッセージを契機に、保守者を呼び出すアクションを実行する。
【0019】
ここで、各運用部品10-1~10-6の連携例を示す。以下では、運用部品10-1~10-6のそれぞれを「情報収集機能部品」、「情報加工機能部品」、「情報解析機能部品」、「試験機能部品」、「構成変更機能部品」、および「保守者UI機能部品」として説明する。
【0020】
まず、情報収集機能部品は、自身の発火ルール(例えばタイマー満了など)により情報収集を実施し、情報収集した結果を含むメッセージをブロードキャストする。
【0021】
情報収集結果を契機として、情報加工機能部品が収集された情報を加工し、加工後の情報を含むメッセージをブロードキャストする。
【0022】
情報の加工を契機として、情報解析機能部品は、加工された情報から異常を検知し、異常検知結果を含むメッセージをブロードキャストする。
【0023】
異常検知結果を契機として、試験機能部品は、試験を選定し、選定した試験の実施伺いメッセージをブロードキャストする。
【0024】
実施伺いメッセージを契機として、保守者UI機能部品は、保守者から試験の実施許可を得て、実施許可メッセージをブロードキャストする。
【0025】
実施許可を契機として、試験機能部品は、試験を実施し、試験結果を含むメッセージをブロードキャストする。
【0026】
試験結果を契機として、構成変更機能部品は、検知された異常について、構成変更機能部品が実施可能なオペレーションを選定し、選定したオペレーションの実施伺いメッセージをブロードキャストする。
【0027】
実施伺いメッセージを契機として、保守者UI機能部品は、保守者からオペレーションの実施許可を得て、実施許可メッセージをブロードキャストする。
【0028】
実施許可を契機として、構成変更機能部品は、オペレーションを実施し、実施結果を含むメッセージをブロードキャストする。
【0029】
このように、保守管理システムでは、運用部品10-1~10-6が能動的に状況を確認し、必要なアクションを自律的に判断して動作する。
【0030】
運用部品10-1~10-6は、運用部品10-1~10-6のそれぞれで共通的に活用する情報を共通データ保存部20に保存するとともに、共通データ保存部20から情報を取得して利用する。
【0031】
図2を参照し、保守管理システムが備える運用部品の構成について説明する。
図1の運用部品10-1~10-6は、
図2に示す運用部品10と同じ構成である。以下、運用部品10-1~10-6を区別する必要がない場合は、単に運用部品10と称することもある。
【0032】
運用部品10は、メッセージ送受信部11、データ・状態保存部12、発火ルール保存部13、ルール実行部14、およびアクション実行部15を備える。
【0033】
メッセージ送受信部11は、メッセージバス30を介して、メッセージを送受信する。メッセージは、メッセージバス30を介して、全ての運用部品10-1~10-6にブロードキャストされる。
【0034】
データ・状態保存部12は、受信したメッセージ、アクション実行部15の実行結果などのデータおよび状態を保持する。データ・状態保存部12は、共通データ保存部20から取得したデータを保持してもよいし、共通データ保存部20に格納するデータを一時的に保持して、共通データ保存部20にデータを格納してもよい。データ・状態保存部12の保持するデータおよび状態は、アクション実行部15がアクションを実行する際に利用してもよい。
【0035】
発火ルール保存部13は、アクションの実行契機、アクションに関する情報を運用部品10-1~10-6ごとに個別に定義した発火ルールを保持する。発火ルールは、アクションに関する情報として、アクション実行形式とアクション完了時のメッセージに含める実行結果の定義を含む。発火ルールは、送信するリクエストの内容または実行するコマンドなどの実行形式ごとに決められたアクション情報を含む。発火ルールの詳細については後述する。
【0036】
ルール実行部14は、受信したメッセージと発火ルール保存部13に保存された発火ルールに基づき、アクションの実行契機を監視する。ルール実行部14は、実行すべきアクションを認識すると、該当するアクションの実行をアクション実行部15に指示する。より具体的には、ルール実行部14は、メッセージ送受信部11が受信したメッセージの種別をアクションの実行契機とする発火ルールが発火ルール保存部13に保存されているか否か判定する。該当する発火ルールが保存されている場合、ルール実行部14は、発火ルールからアクション実行形式とアクションに関する情報を取得してアクション実行部15に通知する。ルール実行部14は、発火ルールをアクション実行部15に渡して、アクションの実行を指示してもよい。また、ルール実行部14は、アクションの実行契機となったメッセージをアクション実行部15に渡してもよい。
【0037】
アクション実行部15は、ルール実行部14からの指示を受けて、指定の実行形式でアクションを実行する。アクションが完了すると、アクション実行部15は、メッセージ送受信部11に対して、アクションの実行結果を含むメッセージの送信を指示する。
【0038】
図3を参照し、アクション実行部15について説明する。同図に示すように、アクション実行部15は、アクションモジュール実行部151、メッセージ送信指示部152、および1つ以上のアクションモジュール153-1~153-3を備える。
【0039】
アクションモジュール実行部151は、指定の実行形式に対応するアクションモジュール153-1~153-3に、アクションに関する情報を渡して、アクションを実行させる。アクションモジュール実行部151は、アクションの実行に必要な情報をデータ・状態保存部12および共通データ保存部20から取得してアクションモジュール153-1~153-3に渡してもよい。
【0040】
メッセージ送信指示部152は、メッセージ送受信部11に対して、アクションモジュール153-1~153-3の実行結果を格納したメッセージの送信を指示する。
【0041】
アクションモジュール実行部151とメッセージ送信指示部152でアクション連携部150を構成する。運用部品10-1~10-6のそれぞれは、共通のアクション連携部150を備える。
【0042】
アクションモジュール153-1~153-3は、運用部品10-1~10-6が担う機能を実現するアクションを実行するモジュールである。
図3では、3つのアクションモジュール153-1~153-3を示しているが、これに限定するものではない。
【0043】
アクションモジュールは、独自の処理を実行するアクションモジュール153-1と、決められた実行形式で処理を実行するアクションモジュール153-2,153-3に分類される。アクションモジュール153-2,153-3のぞれぞれは、異なる実行形式で処理を実行する。アクションモジュール153-2,153-3は、決められた実行形式で、外部の保守システム50-2,50-3に対する処理を実行する。
図3では、アプリケーションプログラミングインタフェース(API)により処理を実行するアクションモジュール153-2と、コマンドラインインタフェース(CLI)により処理を実行するアクションモジュール153-3を図示している。保守システム50-2は、APIによりサービスを提供するシステムである。保守システム50-3は、コマンドを受け付けてサービスを提供するシステムである。
【0044】
保守システム50-2,50-3の実行形式ごとにアクションモジュール153-2,153-3を用意することで、運用部品10-1~10-6は、共通のアクションモジュール153-2,153-3を用いることができる。例えば、HTTPリクエストによりサービスを提供する外部のシステムにはアクションモジュール153-2を用いることができ、コマンドによりサービスを提供する外部のシステムにはアクションモジュール153-3を用いることができる。外部のシステムを利用する運用部品10-1~10-6は、外部のシステムのインタフェースに合わせたアクションモジュール153-2,153-3を備え、発火ルールに外部のシステムを利用するためのリクエストまたはコマンドを記載すればよい。
【0045】
図4A、
図4B、および
図4Cを参照し、アクションモジュール153-1~153-3に対応するアクション実行形式を含む発火ルールについて説明する。
【0046】
図4A,
図4B,および
図4Cは、発火ルール保存部13が保持する発火ルールの一例を示す図である。発火ルールは、メッセージ種別、アクション実行形式、アクション、およびアクション個別情報を含む。メッセージ種別には、アクションを実行する契機となるメッセージを定義する。アクション実行形式には、アクションを実行するアクションモジュール153-1~153-3を特定するための情報を定義する。アクションには、アクションモジュール153-1~153-3が実行するアクションを定義する。アクション個別情報には、アクションの実行に必要な情報を定義する。
【0047】
図4Aは、アクションモジュール153-1が独自の処理のアクションを実行する発火ルールの一例である。アクション実行部15は、
図4Aのアクションをアクションモジュール153-1に渡す。アクションモジュール153-1は指定されたアクションを実行する。
【0048】
図4Bは、アクションモジュール153-2がAPIを用いてアクションを実行する発火ルールの一例である。アクション実行部15は、
図4Bのアクションおよびアクション個別情報をアクションモジュール153-2に渡す。アクションモジュール153-2は、アクションで指定されたURLにアクション個別情報に記載された内容のリクエストを送信する。また、アクション個別情報には、“{sampleId}”のように、メッセージ内容で置換される変数値を含めてもよい。
【0049】
図4Cは、アクションモジュール153-3がコマンドを入力してアクションを実行する発火ルールの一例である。アクション実行部15は、
図4Cのアクションをアクションモジュール153-3に渡す。アクションモジュール153-3は、保守システム50-3にアクセスし、アクションで指定されたコマンドを入力して実行する。アクション個別情報に、コマンドに付加するオプションを定義してもよい。
【0050】
非特許文献1の従来技術では、発火ルールにメッセージ種別とアクションのみを含んでいた。アクション実行部は、アクションが指定されると、アクション実行部に定義された独自の処理を実行していた。本実施形態では、発火ルールにアクション実行形式を含めることで、アクションを実行するアクションモジュールを指定可能とし、運用部品10-1~10-6間でアクションモジュールを共通化できる。運用部品10-1~10-6が、外部のシステムを利用せずに、独自の処理を実行する場合は、独自の処理を実行するアクションモジュール153-1を作成すればよい。
【0051】
図5,6を参照し、アクションの個別の実行結果を同一フォーマットでメッセージ化する方法について説明する。
【0052】
図5に示すメッセージの共通部は、メッセージ種別に応じたデータを設定する領域(uniqueData)を含む。メッセージ送信指示部152は、アクションモジュール153-1~153-3からアクションの実行結果を受け取ると、この領域にアクションの実行結果を含めたメッセージの送信をメッセージ送受信部11に指示する。
【0053】
図6に示すように、発火ルールに、メッセージに含めるアクションの実行結果を定義しておく。
図6は、
図4Bの発火ルールを拡張したものである。完了後発行メッセージには、アクションの実行結果を含めるメッセージ種別を定義する。完了後発行メッセージ個別情報には、メッセージ共通部のuniqueDataに格納する実行結果を定義する。完了後発行メッセージ個別情報には、“{$result}”のように、実行結果の情報で置換される変数値を含めてもよい。例えば、アクションモジュール153-2が送信したリクエストに対するレスポンスの本体部分を含める。
【0054】
なお、
図4Aおよび
図4Cの発火ルールにも完了後発行メッセージを定義してもよい。
【0055】
図7を参照し、運用部品10の動作について説明する。
【0056】
ステップS10にて、メッセージ送受信部11は、メッセージバス30からメッセージを受信する。
【0057】
ステップS11にて、ルール実行部14は、発火ルール保存部13にメッセージに該当する発火ルールが存在するか否か、つまりアクションの実行契機であるか否かを判定する。受信したメッセージがアクションの実行契機でない場合は、運用部品10は処理を終了する。
【0058】
メッセージに該当する発火ルールが存在する場合、ステップS12にて、ルール実行部14は、アクションモジュール実行部151に対して、発火ルールのアクション実行形式で、指定のアクションを実行する指示を出す。
【0059】
ステップS13にて、アクションモジュール実行部151は、アクション実行形式に該当するアクションモジュール153-1~153-3を選択し、指定のアクションを実行させる。
【0060】
独自の処理を実行するアクションモジュール153-1が選択された場合、ステップS14-1にて、アクションモジュール153-1は、独自の処理を実行し、保守対象のサービス環境から情報を取得したり、サービス環境に対して試験を行ったりする。アクションモジュール153-1は、サービス環境に対する処理以外の処理を行ってもよい。
【0061】
ステップS15-1にて、アクションモジュール153-1は、サービス環境からアクション実行結果を得る。
【0062】
APIを用いるアクションモジュール153-2が選択された場合、ステップS14-2にて、アクションモジュール153-2は、保守システム50-2に対して、APIを用いたリクエストを送信する。保守システム50-2は、リクエストに応じた処理を実行する。
【0063】
ステップS15-2にて、アクションモジュール153-2は、保守システム50-2からレスポンスを受信する。
【0064】
CLIを用いるアクションモジュール153-3が選択された場合、ステップS14-3にて、アクションモジュール153-3は、保守システム50-3に対して、指定のコマンドの実行を依頼する。保守システム50-3は、コマンドに応じた処理を実行する。
【0065】
ステップS15-3にて、アクションモジュール153-3は、保守システム50-3からコマンドの実行結果を得る。
【0066】
ステップS16にて、メッセージ送信指示部152は、アクションモジュール153-1~153-3からアクション実行結果を取得する。
【0067】
ステップS17にて、メッセージ送信指示部152は、メッセージ送受信部11に対して、アクション実行結果を含むメッセージの送信を指示する。
【0068】
ステップS18にて、メッセージ送受信部11は、メッセージバス30に対して、アクション実行結果を含むメッセージを送信する。
【0069】
メッセージバス30に送信されたメッセージは、全ての運用部品10-1~10-6にブロードキャストされる。各運用部品10-1~10-6は、メッセージを受信し、ステップS10からの処理を実行する。
【0070】
以上説明したように、本実施形態の運用部品10は、サービスを保守管理する保守管理システムの一部として、メッセージを送受信して自律的に動作する運用部品10であって、他の運用部品10との間でメッセージを送受信するメッセージ送受信部11と、アクションの実行契機および実行するアクションを含む発火ルールを保持する発火ルール保存部13と、受信したメッセージを実行契機とする発火ルールのアクションを実行するアクション実行部15と、を備える。アクション実行部15は、アクションを実行する1つ以上のアクションモジュール153-1~153-3と、発火ルールのアクションに対応するアクションモジュール153-1~153-3のいずれかにアクションを実行させるアクションモジュール実行部151と、アクションモジュールの実行結果をメッセージに格納して送信するメッセージ送信指示部152を備える。これにより、発火ルールを作成し、発火ルールのアクションを実行するアクションモジュール153-1~153-3を作成するだけで、運用部品10を導入することができる。
【0071】
本実施形態の運用部品10は、発火ルールがアクション実行形式と実行形式ごとに決められたアクション情報を含み、アクションモジュール実行部151が、実行形式に対応するアクションモジュール153-2,153-3にアクション情報に基づくアクションを実行させる。これにより、運用部品10は、アクションモジュール153-2,153-3を備えるだけで、HTTPリクエストまたはシェルコマンドなど、様々な形式の外部のシステムを容易に利用できるので、外部のシステムを利用する運用部品10を短期間・低コストで導入できる。
【0072】
本実施形態の運用部品10は、メッセージにアクションの実行結果を含む領域を有し、発火ルールに、メッセージに含めるアクションの実行結果を定義する。これにより、運用部品10の個別の実行結果をメッセージ化でき、運用部品10間で実行結果を利用しやすくなる。
【0073】
上記説明した運用部品10には、例えば、
図8に示すような、中央演算処理装置(CPU)901と、メモリ902と、ストレージ903と、通信装置904と、入力装置905と、出力装置906とを備える汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、CPU901がメモリ902上にロードされた所定のプログラムを実行することにより、運用部品10が実現される。このプログラムは磁気ディスク、光ディスク、半導体メモリ等のコンピュータ読み取り可能な記録媒体に記録することも、ネットワークを介して配信することもできる。
【0074】
なお、1台のコンピュータが1つの運用部品10として動作してもよいし、複数の運用部品10として動作してもよい。また、クラウド上で動作する仮想マシンを運用部品10として動作させてもよい。
【符号の説明】
【0075】
10,10-1~10-6…運用部品
11…メッセージ送受信部
12…データ・状態保存部
13…発火ルール保存部
14…ルール実行部
15…アクション実行部
150…アクション連携部
151…アクションモジュール実行部
152…メッセージ送信指示部
153-1~153-3…アクションモジュール
20…共通データ保存部
30…メッセージバス