WO2019244733A1

WO2019244733A1 - オペレーション装置、および、オペレーション方法

Info

Publication number: WO2019244733A1
Application number: PCT/JP2019/023235
Authority: WO
Inventors: 直幸丹治
Original assignee: 日本電信電話株式会社
Priority date: 2018-06-21
Filing date: 2019-06-12
Publication date: 2019-12-26
Also published as: JP7047621B2; US20210266238A1; US11349730B2; JP2019219983A

Abstract

【課題】オペレーション自動化の開発コストを低減させる。【解決手段】オペレーション装置１は、オペレーションとして実行される運用プロセスを部品化した、複数種類の運用部品の間でやり取りされるメッセージを保存するメッセージ保存部３１と、運用部品の各々に適用されるルールを保存する発火ルール保存部３２と、運用部品の各々の動作内容を示すアクションを保存するアクション保存部３３と、メッセージ保存部３１および発火ルール保存部３２を参照して、発火ルールが存在すれば、アクション保存部から当該発火ルールに該当するアクションを選択する処理を、運用部品ごとに実行するルール実行部２２と、選択されたアクションを、運用部品ごとに実行するアクション実行部２３と、実行したアクションの実行結果に基づいて、他の運用部品宛のメッセージを作成する処理を、運用部品ごとに実行する送信メッセージ処理部２４と、を備える。

Description

オペレーション装置、および、オペレーション方法

　本発明は、オペレーション装置、および、オペレーション方法に関する。

　ネットワーク上で提供されるサービスの保守として、ネットワーク機器の障害対応や、サービスを利用するユーザの申告対応などのオペレーションが行われる。オペレーションを、保守者の知識や判断による人手対応で行った場合、対応時間の長期化によるサービス品質の低下、保守者スキルの揺らぎに起因するサービス品質の揺らぎ、保守者の稼働増大に伴う運用コスト増加、といったデメリットが存在する。

　そこで、近年、保守者の判断を自動化できるように支援し、保守者の知識や判断の必要性を低減させることで、上記デメリットを解消するオペレーション自動化技術の開発が進んでいる。オペレーション自動化技術では、オペレーションとして実行される運用プロセスの、判断基準および手順が明確であれば、保守者の知識や判断を定式化することができる。そこで、運用プロセスの契機（入力）から結果（出力）に至る一連の手順を、ルールベースでワークフローを定義することにより表現することで、オペレーション自動化を実現するオペレーション自動化システムの開発が進んでいる。保守者は、オペレーション自動化システムが判断して出力した結果報告を閲覧し、必要に応じて、特定のオペレーションに対する許可操作をするだけで済むため、保守負担は小さい。

　オペレーション自動化技術の具体例は、多く知られている。例えば、対象プロセスが、ソフトウェアのインストールや、設定などの構築となるプロセスに対しては、Ansibleなどの構成管理ツールが知られている。また、対象プロセスが、ハードウェアの性能の監視やプロセス死活状態の監視となるプロセスに対しては、Zabbixなどのネットワーク管理ソフトウェアが知られている。また、対象プロセスが、ソフトウェア開発における検証（継続的開発）や障害対応となるプロセスに対しては、JenkinsやStackStormなどの継続的インテグレーションツールが知られている。また、対象プロセスが、サービス構築や設定投入などのサービスオーダとなるプロセスに対しては、特許文献１が知られている。

特開２０１７－１４３４５２号公報

　一般的には、保守者の知識や判断による条件分岐は非常に複雑である。例えば、障害切り分けなどの試行錯誤型の運用プロセスが有する条件分岐が該当する。このため、判断基準および手順が明確な運用プロセスであっても、当該運用プロセスを表現するために定義するワークフローは、大規模かつ複雑である。このため、従来のオペレーション自動化は多大な開発コストを伴う、という問題がある。

　そこで、本発明は、上記事情に鑑みて、オペレーション自動化の開発コストを低減させることを課題とする。

　前記課題を解決するために、請求項１に記載の発明は、ネットワーク上のサービスに関するオペレーションを実行するオペレーション装置であって、前記オペレーションとして実行される運用プロセスを部品化した、複数種類の運用部品の間でやり取りされるメッセージを保存するメッセージ保存部と、前記運用部品の各々に適用されるルールを保存する発火ルール保存部と、前記運用部品の各々の動作内容を示すアクションを保存するアクション保存部と、前記メッセージ保存部および前記発火ルール保存部を参照して、前記ルールとして実行可能な発火ルールが存在すれば、前記アクション保存部から当該発火ルールに該当するアクションを選択する処理を、前記運用部品ごとに実行するルール実行部と、前記選択されたアクションを、前記運用部品ごとに実行するアクション実行部と、前記実行したアクションの実行結果に基づいて、他の前記運用部品宛のメッセージを作成する処理を、前記運用部品ごとに実行する送信メッセージ処理部と、を備える、ことを特徴とする。

　また、請求項４に記載の発明は、ネットワーク上のサービスに関するオペレーションを実行するオペレーション装置におけるオペレーション方法であって、前記オペレーション装置は、前記オペレーションとして実行される運用プロセスを部品化した、複数種類の運用部品の間でやり取りされるメッセージを保存するメッセージ保存部と、前記運用部品の各々に適用されるルールを保存する発火ルール保存部と、前記運用部品の各々の動作内容を示すアクションを保存するアクション保存部と、を有しており、前記メッセージ保存部および前記発火ルール保存部を参照して、前記ルールとして実行可能な発火ルールが存在すれば、前記アクション保存部から当該発火ルールに該当するアクションを選択する処理を、前記運用部品ごとに実行するステップと、前記選択されたアクションを、前記運用部品ごとに実行するステップと、前記実行したアクションの実行結果に基づいて、他の前記運用部品宛のメッセージを作成する処理を、前記運用部品ごとに実行するステップと、を実行する、ことを特徴とする。

　請求項１，４に記載の発明によれば、運用プロセスを部品化した運用部品の各々が自律的に動作した結果としてワークフロー全体を成立させることができるため、大規模かつ複雑なワークフローの全体そのものを定義する必要が無くなる。
　したがって、オペレーション自動化の開発コストを低減させることができる。

　また、請求項２に記載の発明は、請求項１に記載のオペレーション装置であって、前記オペレーションは、前記サービスが提供されるネットワークにおける障害復旧を実現するオペレーションであり、前記運用部品は、前記サービスを提供するネットワーク構成から情報を収集する情報収集部品と、前記収集した情報を解析する情報解析部品と、前記収集した情報を加工する情報加工部品と、前記ネットワークにおける障害確認用の試験を行う試験部品と、前記ネットワーク構成を変更する構成変更部品と、を含む、ことを特徴とする。

　また、請求項５に記載の発明は、請求項４に記載のオペレーション方法であって、前記オペレーションは、前記サービスが提供されるネットワークにおける障害復旧を実現するオペレーションであり、前記運用部品は、前記サービスを提供するネットワーク構成から情報を収集する情報収集部品と、前記収集した情報を解析する情報解析部品と、前記収集した情報を加工する情報加工部品と、前記ネットワークにおける障害確認用の試験を行う試験部品と、前記ネットワーク構成を変更する構成変更部品と、を含む、ことを特徴とする。

　請求項２，５に記載の発明によれば、障害復旧を実現するオペレーション自動化の開発コストを低減させることができる。

　また、請求項３に記載の発明は、請求項１または請求項２に記載のオペレーション装置であって、前記運用部品の各々の動作を保守者が許可するメッセージを、前記運用部品の各々に送信する保守者ＵＩ（ユーザインタフェース）を、前記運用部品として含む、ことを特徴とする。

　また、請求項６に記載の発明は、請求項４または請求項５に記載のオペレーション方法であって、前記運用部品の各々の動作を保守者が許可するメッセージを、前記運用部品の各々に送信する保守者ＵＩを、前記運用部品として含む、ことを特徴とする。

　請求項３，６に記載の発明によれば、自動化されるオペレーションに保守者の判断を介入させる手段を提供することができ、サービスの品質保証を支援することができる。

　本発明によれば、オペレーション自動化の開発コストを低減させることができる。

本実施形態のオペレーション装置の機能構成図である。本実施形態のオペレーション装置が実行するメッセージ処理のフローチャートである。具体例におけるサービスを提供するＮＷ構成の例、および、運用部品群のアーキテクチャの例を示す図である。具体例におけるメッセージのデータ構造の例である。具体例における発火ルール保存部のデータ構造の例を示す図である。具体例におけるアクション保存部のデータ構造の例を示す図である。（ａ）が、具体例の定常状態における運用部品群の動作例の説明図であり、（ｂ）が、やり取りされるメッセージ群の関連性の説明図である。（ａ）が、具体例のアラーム発生時における運用部品群の動作例（その１）の説明図であり、（ｂ）が、やり取りされるメッセージ群の関連性の説明図である。（ａ）が、具体例のアラーム発生時における運用部品群の動作例（その２）の説明図であり、（ｂ）が、やり取りされるメッセージ群の関連性の説明図である。

　本発明を実施するための形態（実施形態）について、図面を参照しながら詳細に説明する。
　本実施形態では、サービス保守のオペレーションとして実行される運用プロセスを機能単位に分類し、運用プロセスを部品化する。機能ごとに分類された運用プロセスの部品を「運用部品」と呼ぶ。また、運用部品ごとに閉じたワークフロー（ワークフロー部品）を定義し、個別のルールに従って運用部品を動作させることで運用部品を自律化する。運用部品の各々は、所定のＩＦ（インタフェース）を介して疎結合し、運用部品間のメッセージのやり取りを可能にする。本実施形態は、各運用部品が自律的に動作した結果としてワークフロー全体を成立させる自律制御ループ方式を提案する。この方式によれば、大規模かつ複雑なワークフローの全体そのものを定義する必要が無くなるため、オペレーション自動化の開発コストを低減させることができる。

≪構成≫
　まず、本実施形態のオペレーション装置の構成について説明する。図１に示すように、本実施形態のオペレーション装置１は、入出力部１０と、処理部２０と、記憶部３０といったハードウェアを備えている。処理部２０の具体例となるＣＰＵ（Central Processing Unit）が、記憶部３０の具体例となるメモリ上に読み込んだプログラムを実行することにより、本実施形態に係るオペレーション装置１の機能を実現する。

　入出力部１０は、メッセージ受信部１１と、メッセージ送信部１２とを備える。また、処理部２０は、受信メッセージ処理部２１と、ルール実行部２２と、アクション実行部２３と、送信メッセージ処理部２４とを備える。また、記憶部３０は、メッセージ保存部３１と、発火ルール保存部３２と、アクション保存部３３と、共通データ保存部３４とを備える。

　メッセージ受信部１１は、入力装置２から入力されたメッセージを受信するインタフェースである。入力装置２は、例えば、保守者が操作する管理コンソールや、オペレーション装置１自身である（例えば、オペレーション装置１が有する運用部品間でやり取りされるメッセージを受信する）が、これらに限定されず、例えば、管理コンソールとは別体の計算機でもよい。また、メッセージは、運用部品間で情報のやり取りをするための情報媒体である。

　メッセージ送信部１２は、処理部２０の処理結果を出力する。処理部２０の処理結果は、例えば、ファイルｆとして出力されるが、これに限定されず、例えば、電文でもよい。また、処理部２０の処理結果は、例えば、オペレーション装置１が有する運用部品が作成したメッセージであり、つまり、送信メッセージ処理部２４が作成したメッセージであるが、これに限定されず、例えば、処理部２０が有する図示しない機能部の出力結果でもよい。

　受信メッセージ処理部２１は、メッセージ受信部１１が受信したメッセージをメッセージ保存部３１に保存する。

　ルール実行部２２は、メッセージ保存部３１および発火ルール保存部３２を参照し、発火ルール保存部３２に保存されているルールのうち、メッセージ保存部３１に保存されているメッセージに対して、実行可能な（発火した）ルール（発火ルール）を実行する。ルールは、運用部品の自律的な動作を定義するものである。ルールは、運用部品ごとに用意されている。

　また、ルール実行部２２は、アクション保存部３３を参照し、実行したルールに該当するアクション（当該ルールで要求されるアクション）を選択する。アクションは、運用部品の動作内容を示すものであり、運用プロセスを機能単位に分類したときの各機能に相当する。アクションは、運用部品ごとに用意されている。また、ルール実行部２２は、選択したアクションの実行指示をアクション実行部２３に出力する。

　アクション実行部２３は、アクション保存部３３に保存されているアクションを参照し、ルール実行部２２が選択したアクションを実行する。また、アクション実行部２３は、アクションの実行結果に応じたメッセージの送信指示を送信メッセージ処理部２４に出力する。また、アクション実行部２３は、アクションの実行結果や、アクション実行に伴う運用部品の各々の状態を示す状態情報を共通データ保存部３４に保存する。

　送信メッセージ処理部２４は、メッセージ保存部３１および共通データ保存部３４を参照し、アクション実行部２３によるアクションの実行結果に基づくメッセージを作成し、メッセージ送信部１２に出力する。作成するメッセージは、メッセージ保存部３１に保存されたメッセージ（メッセージ受信部１１で受信したメッセージ）に応答するメッセージを含む。

　ルール実行部２２、アクション実行部２３、および、送信メッセージ処理部２４が実行する処理は、運用部品ごとに繰り返される。送信メッセージ処理部２４が作成するメッセージは、複数種類の運用部品の各々で作成されるメッセージであるが、ある運用部品で作成されたメッセージは残りの運用部品にブロードキャストで送信される。

　メッセージ保存部３１は、受信メッセージ処理部２１を介して、メッセージ受信部１１が受信したメッセージを保存する。
　発火ルール保存部３２は、運用部品に適用されるルールを保存する。
　アクション保存部３３は、運用部品の動作内容を示すアクションを保存する。
　共通データ保存部３４は、各運用部品が利用可能なデータを共通データとして保存する。共通データは、例えば、アクション実行部２３によるアクションの実行結果や、アクション実行に伴う運用部品の各々の状態を示す状態情報であるが、これらに限定されない。

≪処理≫
　次に、本実施形態のオペレーション装置１が実行する処理ついて、図２を参照して説明する。図２に示す処理は、各運用部品に対して用意されたルール、つまり、発火ルール保存部３２に保存されているルールに従って開始するが、例えば、所定の時間経過後に開始したり、メッセージを受信した場合に開始したりする。

　オペレーション装置１は、複数種類の運用部品ごとに、ステップＳ１ａ～ステップＳ１ｂのループ処理を実行する。以下、運用部品ごとの処理として説明を続ける。

　次に、オペレーション装置１は、ルール実行部２２によって、メッセージ保存部３１および発火ルール保存部３２を参照し、発火ルールが存在するか否か判定する（ステップＳ２）。発火ルールが存在しない場合（ステップＳ２でＮｏ）、対象の運用部品において図２の処理を終了し、別の運用部品について図２の処理を開始する。

　発火ルールが存在する場合（ステップＳ２でＹｅｓ）、オペレーション装置１は、ルール実行部２２によって、アクション保存部３３を参照し、発火ルールに該当するアクションを選択する（ステップＳ３）。

　次に、オペレーション装置１は、アクション実行部２３によって、ルール実行部２２が選択したアクションを実行する（ステップＳ４）。

　次に、オペレーション装置１は、送信メッセージ処理部２４によって、メッセージ保存部３１および共通データ保存部３４を参照し、アクションの実行結果に基づくメッセージを作成し、メッセージ送信部１２に出力する（ステップＳ５）。

　以上で、対象の運用部品において図２の処理が終了し、すべての運用部品について図２の処理が繰り返される。メッセージ送信部１２は、送信メッセージ処理部２４から入力されたメッセージを残りの運用部品にブロードキャストで送信する。

　本実施形態によれば、運用プロセスを部品化した運用部品の各々が自律的に動作した結果としてワークフロー全体を成立させることができるため、大規模かつ複雑なワークフローの全体そのものを定義する必要が無くなる。
　したがって、オペレーション自動化の開発コストを低減させることができる。

　なお、運用部品の各々を表現するために定義するワークフロー部品は、それほど大規模でもなく、また、それほど複雑でもないため、オペレーション自動化のために多大な開発コストを必要としない。
　また、オペレーション自動化の対象となる運用プロセスを表現するワークフロー全体の設計は、従来手法で行われるが、本実施形態の運用部品を表現するワークフロー部品の設計も、従来手法と同様に行うことができる。このため、運用部品の作成方法そのものの説明は省略する。

≪具体例≫
　次に、本実施形態の具体例として、保守対象のサービスが提供されるネットワークにおける障害復旧を実現するオペレーション自動化について説明する。

　具体例のサービスを提供するＮＷ（ネットワーク）構成は、図３の上部に示す通りである。具体例のＮＷ構成は、複数のサービス利用者拠点とサービス提供拠点とがＮＷを介して接続する構成である。サービス提供拠点に配置されているＮＷ機器ｅ４、アプリＡ（ｅ５）、アプリＢ（ｅ６）、および、データベースｅ７と、サービス利用者拠点に配置されている端末ｅ１，ｅ２、および、ＮＷ機器ｅ３との間で情報のやり取りが行われることで、端末ｅ１，ｅ２のユーザにサービスが提供される。

　本具体例は、障害復旧のオペレーションとして実行される運用プロセスを、図３の下部に示す通り、情報収集ｐ１（情報収集部品：collector）、情報解析ｐ２（情報解析部品：analyzer）、情報加工ｐ３（情報加工部品：editor）、試験ｐ４（試験部品：tester）、構成変更ｐ５（構成変更部品：maintainer）、および、保守者ＵＩ（ユーザインタフェース）ｐ６（administrator）、という６つの運用部品に分類する。図３の下部に示す通り、６つの運用部品がメッセージバスｐ７を介してメッセージのやり取りを可能とするインタフェースを設けることで、自律的に動作する６つの運用部品を疎結合させるアーキテクチャを構成する。

　情報収集ｐ１は、ＮＷ構成（を担う各種ネットワーク機器（図３中符号ｅ１～ｅ７））から、サービス保守用の情報を収集する機能部である。情報収集ｐ１は、タイムスタンプの付与、差分値算出、といった可逆的な情報処理を実行することができる。

　情報解析ｐ２は、情報収集ｐ１が収集した情報を解析したり、既存の情報（情報収集ｐ１が収集した情報を含む）を演算処理して新しい情報を生成したりする機能部である。演算処理には、例えば、分類（例：異常判定、クラスタリング）、予測が含まれるが、これらに限定されず、例えば、状態推定を含めてもよい。

　情報加工ｐ３は、情報収集ｐ１が収集した情報を加工したり、既存の情報（情報収集ｐ１が収集した情報を含む）に対する不可逆的な情報処理を実行する機能部である。不可逆的な情報処理には、例えば、ノイズ除去、相関関係算出、特徴抽出、キーワード抽出が含まれるが、これらに限定されず、例えば、統計処理を含めてもよい。また、情報加工ｐ３は、不可逆的な情報処理の処理結果を可視化する処理（例：グラフ表示、画面表示）を実行することができる。

　試験ｐ４は、ネットワークにおける障害確認用の試験を行う機能部である。試験には、例えば、ping、curl、traceroute、1callが含まれるが、これらに限定されない。試験ｐ４は、試験用の試験呼を発行することができる。

　構成変更ｐ５は、ＮＷ構成に対する変更オペレーションを発行し、ＮＷ構成を変更する機能部である。変更オペレーションには、例えば、ユーザ収容変更、リソース追加、サービス再作成が含まれるが、これらに限定されない。

　保守者ＵＩ（ｐ６）は、保守者が操作する管理コンソールＭが、他の運用部品（ｐ１～ｐ５）と、メッセージバスｐ７を介したメッセージのやり取りを行うＵＩを提供する機能部である。保守者ＵＩ（ｐ６）は、各運用部品（ｐ１～ｐ５）の動作を保守者が許可するメッセージを、各運用部品（ｐ１～ｐ５）に送信することができる。保守者ＵＩ（ｐ６）によって、自動化されるオペレーションに保守者の判断を介入させる手段を提供することができ、サービスの品質保証を支援することができる。

　各運用部品（ｐ１～ｐ６）は、既に説明した、受信メッセージ処理部２１と、ルール実行部２２と、アクション実行部２３と、送信メッセージ処理部２４の機能を有する。
　なお、説明の便宜上、各運用部品（ｐ１～ｐ６）にあてはまる場合、各運用部品（ｐ１～ｐ６）を「共通」（all-parts）と呼ぶ場合がある。

＜メッセージの詳細＞
　各運用部品（ｐ１～ｐ６）がやり取りするメッセージは、キー（key）と、値（value）と、メタデータ（metadata）の組を複数種類有して構成されている。具体例で扱うkey、value、metadataの組の例を図４に示す。図４に示すように、keyには、src、dst、src_type、dst_type、id、relation_msg、msg_type、expect_state、current_state、response_codeといった種類が存在するが、これらに限定されない。また、図４中、各keyに紐付けられたvalue、metadataの内容は例示である。metadataについては、keyの種類によっては存在しない場合があり、図４ではブランクで示す。

　srcは、メッセージの送信元を表しており、紐付けられたvalueには、送信元となる運用部品の識別子が格納される。
　dstは、メッセージの送信先を表しており、紐付けられたvalueには、送信先となる運用部品の識別子が格納される。

　src_typeは、メッセージの送信元の種別を表しており、紐付けられたvalueには、送信元となる運用部品の種別が格納される。
　dst_typeは、メッセージの送信先の種別を表しており、紐付けられたvalueには、送信先となる運用部品の種別が格納される。
　本具体例では、メッセージに含まれる、運用部品の種別は、collector、analyzer、editor、tester、maintainer、administratorである。

　idは、対象のメッセージを表しており、紐付けられたvalueには、対象のメッセージの識別子が格納される。

　relation_msgは、対象のメッセージ（idで識別されるメッセージ）に関連するメッセージを表しており、紐付けられたvalueには、当該関連するメッセージの識別子を表している。関連するメッセージとして、例えば、parent_msg（親メッセージ）、sibling_msg（兄弟関係のメッセージ）、child_msg（子メッセージ）が存在するがこれらに限定されない。

　msg_typeは、対象のメッセージのメッセージ種別を表しており、紐付けられたvalueには、当該メッセージ種別が格納される。メッセージ種別には、例えば、request（要求）、info（通知）、reply（応答）が存在するがこれらに限定されない。

　expect_stateは、msg_typeがrequestとなるメッセージが有するkeyであり、当該メッセージが処理されることより期待される結果を表している。紐付けられたvalueには、期待される結果の具体的数値、文字列が格納され、紐付けられたmetadataに示す形式に従う。紐付けられたmetadataには、数値の単位や意味などの記述内容の補足情報が格納される。

　current_stateは、msg_typeがinfoまたはreplyとなるメッセージが有するkeyであり、当該メッセージが処理されたときの処理結果を表している。紐付けられたvalueには、期待される結果の具体的数値、文字列が格納され、紐付けられたmetadataに示す形式に従う。紐付けられたmetadataには、数値の単位や意味などの記述内容の補足情報が格納される。

　response_codeは、msg_typeがreplyとなるメッセージが有するkeyであり、非同期処理の受領など、メッセージ間の関係性を表している。紐付けられたvalueには、メッセージ間の関係性を示すコード番号、受領先のＵＲＩなどが格納される。

＜発火ルール保存部の詳細＞
　本具体例における発火ルール保存部３２は、運用部品（ｐ１～ｐ６）ごとに用意されたルールを保存している。本具体例における発火ルール保存部３２が保存するルールの例を図５に示す。図５に示すように、各ルールは、当該ルールの識別番号を示す「項番」と、当該ルールで動作する運用部品の種別を示す「運用部品」と、当該ルールによる動作のトリガを示す「if」と、当該ルールよる運用部品の動作内容を示す「then」との関連付けで表現される。

　１番のルールは、各運用部品（ｐ１～ｐ６）に共通に用いられるルールである。１番のルールによって、各運用部品（ｐ１～ｐ６）は、新しいメッセージ（例えば、他の運用部品が、送信メッセージ処理部２４によって作成したメッセージ）を受信した場合、当該メッセージをメッセージ保存部に保存する。

　２番のルールは、情報収集ｐ１に用いられるルールである。２番のルールによって、情報収集ｐ１は、前回の収集から所定期間経過した場合、定期収集を実行する。また、情報収集ｐ１は、定期収集の成功後、他の運用部品に収集完了メッセージを送信する。

　３番のルールは、情報収集ｐ１に用いられるルールである。３番のルールによって、情報収集ｐ１は、例えば、保守者からの情報収集依頼を受信し、かつ、依頼対象の情報を自身で処理可能である場合、依頼受領の旨、および、保存先を示す情報を送信元（依頼者）に返信する。また、情報収集ｐ１は、依頼対象の情報を依頼された期間収集し、共通データ保存部３４に保存する。また、情報収集ｐ１は、収集完了後、送信元に関連情報（処理成否など）を返信する。

　４番のルールは、情報解析ｐ２に用いられるルールである。４番のルールによって、情報解析ｐ２は、情報収集ｐ１からの収集完了メッセージまたは情報加工ｐ３からの加工完了メッセージを受信し、かつ、解析対象の情報を自身で処理可能である場合、共通データ保存部３４から情報を取得し、解析する。また、情報解析ｐ２は、解析完了後、他の運用部品に解析完了メッセージを送信する。

　５番のルールは、情報解析ｐ２に用いられるルールである。５番のルールによって、情報解析ｐ２は、共通データ保存部３４から取得した情報の解析の結果、得られた算出値が閾値を超過した場合、他の運用部品にアラームメッセージを送信する。

　６番のルールは、情報加工ｐ３に用いられるルールである。６番のルールによって、情報加工ｐ３は、情報収集ｐ１からの収集完了メッセージを受信し、かつ、加工対象の情報を自身で処理可能である場合、共通データ保存部３４から情報を取得し、加工する。また、情報加工ｐ３は、加工完了後、共通データ保存部３４に新規保存する。また、情報加工ｐ３は、他の運用部品に加工完了メッセージを送信する。

　７番のルールは、試験ｐ４に用いられるルールである。７番のルールによって、試験ｐ４は、アラームメッセージを受信し、かつ、アラーム対象に関する試験条件が満たされている場合（例えば、試験実行の許可が保守者から得られている場合）、アラーム対象の試験（疎通試験、死活試験など）を実行する。また、試験ｐ４は、試験完了後、他の運用部品に試験結果メッセージを送信する。

　８番のルールは、試験ｐ４に用いられるルールである。８番のルールによって、試験ｐ４は、アラームメッセージを受信し、かつ、アラーム対象に関する試験条件が満たされていない場合（例えば、試験実行の許可が保守者から得られていない場合）、他の運用部品に、試験に必要な要件を示すメッセージを送信する。また、試験ｐ４は、その後の返信で試験条件が満たされた場合、自身の状態を更新し、共通データ保存部３４に保存する。

　９番のルールは、試験ｐ４に用いられるルールである。９番のルールによって、試験ｐ４は、試験の結果がＮＧであった場合、他の運用部品に、ＮＧ箇所の情報を付与したアラームメッセージを送信する。

　１０番のルールは、構成変更ｐ５に用いられるルールである。１０番のルールによって、構成変更ｐ５は、アラームメッセージを受信し、かつ、ＮＧ箇所に対する変更手段を有している場合、当該変更手段を実行する。

　１１番のルールは、構成変更ｐ５に用いられるルールである。１１番のルールによって、構成変更ｐ５は、ネットワーク機器のping応答はあるが、アプリケーションの応答は無く、かつ、当該アプリケーションの再起動手段を有している場合、当該アプリケーションの再起動を実行する。

　１２番のルールは、保守者ＵＩ（ｐ６）に用いられるルールである。１２番のルールによって、保守者ＵＩ（ｐ６）は、メッセージを受信した場合、受信したメッセージをログとして保存する。

　１３番のルールは、保守者ＵＩ（ｐ６）に用いられるルールである。１３番のルールによって、保守者ＵＩ（ｐ６）は、保守者から試験ｐ４による試験実行の許可を取得した場合、他の運用部品に試験実行許可メッセージを送信する。

＜アクション保存部の詳細＞
　本具体例におけるアクション保存部３３は、運用部品（ｐ１～ｐ６）ごとに用意されたアクション（機能）を保存している。本具体例におけるアクション保存部３３が保存するアクションの例を図６に示す。図６に示すように、各アクションは、当該アクションの識別番号を示す「項番」と、当該アクションを実行する運用部品の種別を示す「運用部品」と、当該アクションの名称となる「機能」と、当該アクションの実行に必要な引数を示す「実行に必要な引数」との関連付けで表現される。

　１番のアクションは、各運用部品（ｐ１～ｐ６）が共通して実行する「メッセージ送信」である。「メッセージ送信」は、メッセージの内容等を引数とし、メッセージの送信を行う。「メッセージ送信」の実行に必要な引数は、メッセージの種別と、内容と、送信先となる運用部品の識別子と、当該運用部品の種別である。

　２番のアクションは、各運用部品（ｐ１～ｐ６）が共通して実行する「メッセージ受信」である。「メッセージ受信」は、メッセージバスｐ７（図３）からメッセージを取得し、メッセージ保存部３１に保存する。「メッセージ受信」の実行に必要な引数は、メッセージバスｐ７の識別子となるメッセージバスＩＤである。

　３番のアクションは、情報収集ｐ１が実行する「サーバ情報収集」である。「サーバ情報収集」は、サーバ機器からの情報収集を行う。「サーバ情報収集」の実行に必要な引数は、対象のサーバ機器のＩＰアドレスと、収集するメトリクス（収集した情報を定量化したデータ）である。

　４番のアクションは、情報収集ｐ１が実行する「ＮＷ情報収集」である。「ＮＷ情報収集」は、ＮＷ機器からの情報収集を行う。「ＮＷ情報収集」の実行に必要な引数は、対象のネットワーク機器のＩＰアドレスと、収集するメトリクスである。

　５番のアクションは、情報解析ｐ２が実行する「時系列データに対する外れ値検知」である。「時系列データに対する外れ値検知」は、所定の閾値に対する外れ値検知を行い、外れ値を検知した時刻を出力とする。「時系列データに対する外れ値検知」の実行に必要な引数は、時系列データと、解析対象の期間である。

　６番のアクションは、情報解析ｐ２が実行する「アラームメッセージ送信」である。「アラームメッセージ送信」は、アラームメッセージを作成し、「メッセージ送信」を用いて送信する。「アラームメッセージ送信」の実行に必要な引数は、対象メトリクス（例：アラームの起因となる外れ値を定量化したデータ）と、アラーム対象期間（例：外れ値を検知した時刻を含む所定期間）である。

　７番のアクションは、情報加工ｐ３が実行する「統計処理（代表値の算出）」である。「統計処理（代表値の算出）」は、平均値や中央値、分散など時系列データの代表値を算出する。「統計処理（代表値の算出）」の実行に必要な引数は、時系列データと、出力する代表値である。

　８番のアクションは、情報加工ｐ３が実行する「可視化」である。「可視化」は、時系列データのグラフを作成し、グラフを参照するためのＵＲＬを出力とする。「可視化」の実行に必要な引数は、時系列データと、対象期間である。

　９番のアクションは、試験ｐ４が実行する「機器に対するＬ３死活監視」である。「機器に対するＬ３死活監視」は、Ｌ３（Layer 3）死活監視（例：ping）を行う。「機器に対するＬ３死活監視」の実行に必要な引数は、対象機器のＩＰアドレスである。

　１０番のアクションは、試験ｐ４が実行する「Ｌ４ポート監視」である。「Ｌ４ポート監視」は、Ｌ４（Layer 4）ポートの死活監視（例：curl）を行う。「Ｌ４ポート監視」の実行に必要な引数は、対象機器のＩＰアドレスと、対象のポートと、プロトコルである。

　１１番のアクションは、構成変更ｐ５が実行する「ＶＭのスペック変更」である。「ＶＭのスペック変更」は、ＮＷ構成の一部となるＶＭ（Virtual Machine：仮想マシン）のスペックの変更を行う。「ＶＭのスペック変更」の実行に必要な引数は、対象ＶＭの識別子と、変更後の内容（例：スペックの目標値）である。なお、ＶＭのスペックの変更手段そのものは既存のものを用いることができ、説明を省略するが、構成変更ｐ５は、当該変更手段を適宜選択することができる。

　１２番のアクションは、構成変更ｐ５が実行する「アプリ再起動」である。「アプリ再起動」は、ＮＷ構成の一部となるアプリケーションの再起動を行う。「アプリ再起動」の実行に必要な引数は、対象機器のＩＰアドレスと、再起動方法である。

＜具体例の運用部品群の動作例＞
　具体例の運用部品（ｐ１～ｐ６）の動作例について、図７～図９を参照して説明する。本動作例は、障害アラームが発生していない定常状態（図７）と、障害アラームが発生したときのアラーム発生時（図８、図９）とに分けることができる。

（定常状態）
　まず、定常状態の動作例について説明する。
　定常状態では、アクション保存部３３（図６）に保存されているアクションに基づいて、例えば、以下の手順ｘ１～ｘ３が実行される。

　手順ｘ１：情報収集ｐ１が、対象のＮＷ構成（図３）から情報収集。
　手順ｘ２：情報加工ｐ３が、収集情報を定期的に加工（可視化）
　手順ｘ３：情報解析ｐ２が、収集情報の解析（外れ値検知）

　図７（ａ）に示すように、手順ｘ１が実行されたとき、情報収集ｐ１は、メッセージバスｐ７を介して、他の運用部品（ｐ２～ｐ６）にメッセージ［１１］を送信する。メッセージ［１１］は、定期収集の完了通知を示すメッセージである。試験ｐ４、構成変更ｐ５は、メッセージ［１１］を受信しても、メッセージ［１１］で発火するルールを有しないため（図５参照）、メッセージ［１１］を破棄する。保守者ＵＩ（ｐ６）は、受信したメッセージ［１１］をログとして保存する（図５参照）。

　なお、上記の「メッセージ［１１］で発火するルールを有しないため（図５参照）」とは、「図５に示す１番～１３番のルールのうち、２番～１３番のルールを有しないため、」という意味であり、１番のルールは対象外とする。つまり、運用部品の種別が「共通」である１番のルールは必ず適用され、各運用部品（ｐ１～ｐ６）が受信した新しいメッセージは、メッセージ保存部３１に保存されることとし、保存前に破棄されることはない。本動作例で以降に説明する他のメッセージ（メッセージ［１２］，［１３］，［１］～［７］）に対しても上記の意味が適用される。

　情報加工ｐ３は、メッセージ［１１］で発火するルールを有しているため（図５参照）、メッセージ［１１］の受信を契機にして、収集情報の可視化（手順ｘ２）を開始する。手順ｘ２が実行されたとき、情報加工ｐ３は、メッセージバスｐ７を介して、他の運用部品（ｐ１、ｐ２、ｐ４～ｐ６）にメッセージ［１２］を送信する。メッセージ［１２］は、可視化の完了通知を示すメッセージである。情報収集ｐ１、情報解析ｐ２、試験ｐ４、構成変更ｐ５は、メッセージ［１２］を受信しても、メッセージ［１２］で発火するルールを有しないため（図５参照）、メッセージ［１２］を破棄する。保守者ＵＩ（ｐ６）は、受信したメッセージ［１２］をログとして保存する（図５参照）。

　情報解析ｐ２は、メッセージ［１１］で発火するルールを有しているため（図５参照）、メッセージ［１１］の受信を契機にして、外れ値検知（手順ｘ３）を開始する。手順ｘ３が実行されたとき、情報解析ｐ２は、メッセージバスｐ７を介して、他の運用部品（ｐ１、ｐ３～ｐ６）にメッセージ［１３］を送信する。メッセージ［１３］は、解析結果（解析完了）を示すメッセージである。情報収集ｐ１、情報加工ｐ３、試験ｐ４、構成変更ｐ５は、メッセージ［１３］を受信しても、メッセージ［１３］で発火するルールを有しないため（図５参照）、メッセージ［１３］を破棄する。保守者ＵＩ（ｐ６）は、受信したメッセージ［１３］をログとして保存する（図５参照）。

　図７（ｂ）には、メッセージ［１１］～［１３］間の関連性が示されている。この関連性は、メッセージ［１１］～［１３］の各々が有するkey、value、metadataに基づいて決定される（図４、および、図４を参照した説明を参照）。

　上記のように、各運用部品（ｐ１～ｐ６）は、メッセージバスｐ７を介して疎結合されており、定常状態で発生するメッセージ［１１］～［１３］を一通り受信することができるとともに、発火するルールに従って自律的にアクションを実行することができる。その結果、定常状態における障害復旧のワークフロー全体を成立させることができ、オペレーション自動化を達成することができる。

（アラーム発生時）
　次に、アラーム発生時の動作例について説明する。
　アラーム発生時では、アクション保存部３３（図６）に保存されているアクションに基づいて、例えば、以下の手順１～６が実行される。

　手順１：情報解析ｐ２が、アラームを発生（アプリＡ（ｅ５）（図３）のInトラヒック（入力されたトラヒック）で外れ値を検知）
　手順２：試験ｐ４が、アラームに対して試験を開始（準備）し、試験条件（試験実行の許可願い）を提示。
　手順３：保守者ＵＩ（ｐ６）が、保守者による試験実行の許可を返信。
　手順４：試験ｐ４が、死活監視の試験実行。死活監視の結果、死んでいるサービスを発見（pingは帰ってくる）
　手順５：構成変更ｐ５が、アプリケーション（アプリＡ（ｅ５）（図３））の再起動を実行。
　手順６：情報解析ｐ２が、アラームの解除を通知。

　図８（ａ）に示すように、手順１が実行されたとき、情報解析ｐ２は、メッセージバスｐ７を介して、他の運用部品（ｐ１、ｐ３～ｐ６）にメッセージ［１］を送信する。メッセージ［１］は、外れ値を検知したことを示すアラームメッセージである。情報収集ｐ１、情報加工ｐ３、構成変更ｐ５は、メッセージ［１］を受信しても、メッセージ［１］で発火するルールを有しないため（図５参照）、メッセージ［１］を破棄する。保守者ＵＩ（ｐ６）は、受信したメッセージ［１］をログとして保存する（図５参照）。

　試験ｐ４は、メッセージ［１］で発火するルールを有しているため（図５参照）、メッセージ［１］の受信を契機にして、試験を開始（準備）する（手順２）。試験を開始したとき、試験ｐ４は、メッセージバスｐ７を介して、他の運用部品（ｐ１～ｐ３、ｐ５、ｐ６）にメッセージ［２］を送信する。メッセージ［２］は、試験を開始することでアラームに対応することを示す通知メッセージである。情報収集ｐ１、情報解析ｐ２、情報加工ｐ３、構成変更ｐ５は、メッセージ［２］を受信しても、メッセージ［２］で発火するルールを有しないため（図５参照）、メッセージ［２］を破棄する。保守者ＵＩ（ｐ６）は、受信したメッセージ［２］をログとして保存する（図５参照）。

　また、試験ｐ４は、試験開始に関連して、試験条件（試験実行の許可願い）を提示する（手順２）。試験条件を提示したとき、試験ｐ４は、メッセージバスｐ７を介して、他の運用部品（ｐ１～ｐ３、ｐ５、ｐ６）にメッセージ［３］を送信する。メッセージ［３］は、試験条件として、試験実行の許可を保守者に求めるメッセージである。情報収集ｐ１、情報解析ｐ２、情報加工ｐ３、構成変更ｐ５は、メッセージ［３］を受信しても、メッセージ［３］で発火するルールを有しないため（図５参照）、メッセージ［３］を破棄する。保守者ＵＩ（ｐ６）は、受信したメッセージ［３］をログとして保存する（図５参照）。

　図８（ｂ）には、メッセージ［１］～［３］、および、後記するメッセージ［４］～［７］間の関連性が示されている。この関連性は、メッセージ［１］～［７］の各々が有するkey、value、metadataに基づいて決定される（図４、および、図４を参照した説明を参照）。メッセージ［２］、［３］が有するkey、value、metadataに基づいて、メッセージ［２］、［３］は兄弟関係にあり、メッセージ［２］が送信される場合、メッセージ［３］も送信されるように規定されている。

　図９（ａ）に示すように、手順２の後、手順３が実行されたとき、保守者ＵＩ（ｐ６）は、メッセージバスｐ７を介して、他の運用部品（ｐ１～ｐ５）にメッセージ［４］を送信する。メッセージ［４］は、試験実行を許可することを示す試験実行許可メッセージである。情報収集ｐ１、情報解析ｐ２、情報加工ｐ３、構成変更ｐ５は、メッセージ［４］を受信しても、メッセージ［４］で発火するルールを有しないため（図５参照）、メッセージ［４］を破棄する。

　試験ｐ４は、メッセージ［４］で発火するルールを有しているため（図５参照）、メッセージ［４］の受信を契機にして、死活監視の試験を実行する（手順４）。試験を実行したとき、試験ｐ４は、メッセージバスｐ７を介して、他の運用部品（ｐ１～ｐ３、ｐ５、ｐ６）にメッセージ［５］を送信する。メッセージ［５］は、試験結果（ＮＧ箇所がアプリＡ（ｅ５）（図３）であると判明）を示す通知メッセージである。情報収集ｐ１、情報解析ｐ２、情報加工ｐ３は、メッセージ［５］を受信しても、メッセージ［５］で発火するルールを有しないため（図５参照）、メッセージ［５］を破棄する。保守者ＵＩ（ｐ６）は、受信したメッセージ［５］をログとして保存する（図５参照）。

　なお、図９（ｂ）には、図８（ｂ）と同じとなる、メッセージ［１］～［７］間の関連性が示されている。メッセージ［２］、［５］が有するkey、value、metadataに基づいて、メッセージ［２］、［５］は親子関係にあり、メッセージ［２］（親）が送信された後、所定の条件を満たした場合に、メッセージ［５］（子）が送信されるように規定されている。

　構成変更ｐ５は、メッセージ［５］で発火するルールを有しているため（図５参照）、メッセージ［５］の受信を契機にして、アプリケーションの再起動を実行する（手順５）。手順５が実行されたとき、構成変更ｐ５は、メッセージバスｐ７を介して、他の運用部品（ｐ１～ｐ４、ｐ６）にメッセージ［６］を送信する。メッセージ［６］は、アプリケーションを実行したことを示す通知メッセージである。情報収集ｐ１、情報解析ｐ２、情報加工ｐ３、試験ｐ４は、メッセージ［６］を受信しても、メッセージ［６］で発火するルールを有しないため（図５参照）、メッセージ［６］を破棄する。保守者ＵＩ（ｐ６）は、受信したメッセージ［６］をログとして保存する（図５参照）。

　構成変更ｐ５がアプリケーションの再起動を実行したことで、障害が解消されたため、実質的に定常状態（図７）と同等の状態に暫定的に戻る。よって、オペレーション装置１は、既に説明した、手順ｘ１～ｘ３を実行する。

　手順ｘ１～ｘ３を実行したとき、情報解析ｐ２が外れ値を検知しなかった場合、図９（ａ）に示すように、情報解析ｐ２は、メッセージバスｐ７を介して、他の運用部品（ｐ１、ｐ３～ｐ６）にメッセージ［７］を送信する。メッセージ［７］は、解析結果（解析完了）を示すメッセージであり、アラーム解消を通知するものである。情報収集ｐ１、情報加工ｐ３、試験ｐ４、構成変更ｐ５は、メッセージ［７］を受信しても、メッセージ［７］で発火するルールを有しないため（図５参照）、メッセージ［７］を破棄する。保守者ＵＩ（ｐ６）は、受信したメッセージ［７］をログとして保存する（図５参照）。

　上記のように、各運用部品（ｐ１～ｐ６）は、メッセージバスｐ７を介して疎結合されており、アラーム発生時で発生するメッセージ［１］～［７］を一通り受信することができるとともに、発火するルールに従って自律的にアクションを実行することができる。その結果、アラーム発生時における障害復旧のワークフロー全体を成立させることができ、オペレーション自動化を達成することができる。

≪その他≫
　本具体例では、試験ｐ４が試験を実行する場合には、保守者の許可を必要とすることとして説明した（保守者ＵＩ（ｐ６）がメッセージ［４］を送信）。しかし、試験ｐ４は、保守者の許可なく試験を実行してもよい。例えば、試験と並行した情報取得ができること、試験に伴うサービスへの影響度が所定の閾値を下回るなどの試験条件を満たした場合、試験ｐ４は、保守者の許可なく試験を実行することができるとしてもよい。

　また、本具体例に対して、例えば、構成変更ｐ５がＮＷ構成を変更するために、保守者の許可を必要とすることとしてメッセージのやり取りを行うようにしてもよい。
　また、保守者ＵＩ（ｐ６）を除く運用部品（ｐ１～ｐ５）の各々が実行するプロセスについて、保守者ＵＩ（ｐ６）を介した保守者の許可を求めるようにしてもよいし、求めないようにしてもよい。

　また、本実施形態では、サービス保守のオペレーションとして実行される運用プロセスを機能単位に分類し、運用プロセスを部品化したが、機能単位に限らず、ワークフロー部品のサイズ単位など、所定の単位で分類してもよい。

　本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
　本実施形態で説明したソフトウェアをハードウェアとして実現することもでき、ハードウェアをソフトウェアとして実現することもできる。
　その他、ハードウェア、ソフトウェア、フローチャートなどについて、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。

　１　　　オペレーション装置
　１０　　入出力部
　１１　　メッセージ受信部
　１２　　メッセージ送信部
　２０　　処理部
　２１　　受信メッセージ処理部
　２２　　ルール実行部
　２３　　アクション実行部
　２４　　送信メッセージ処理部
　３０　　記憶部
　３１　　メッセージ保存部
　３２　　発火ルール保存部
　３３　　アクション保存部
　３４　　共通データ保存部

Claims

　ネットワーク上のサービスに関するオペレーションを実行するオペレーション装置であって、
　前記オペレーションとして実行される運用プロセスを部品化した、複数種類の運用部品の間でやり取りされるメッセージを保存するメッセージ保存部と、
　前記運用部品の各々に適用されるルールを保存する発火ルール保存部と、
　前記運用部品の各々の動作内容を示すアクションを保存するアクション保存部と、
　前記メッセージ保存部および前記発火ルール保存部を参照して、前記ルールとして実行可能な発火ルールが存在すれば、前記アクション保存部から当該発火ルールに該当するアクションを選択する処理を、前記運用部品ごとに実行するルール実行部と、
　前記選択されたアクションを、前記運用部品ごとに実行するアクション実行部と、
　前記実行したアクションの実行結果に基づいて、他の前記運用部品宛のメッセージを作成する処理を、前記運用部品ごとに実行する送信メッセージ処理部と、を備える、
　ことを特徴とするオペレーション装置。
　前記オペレーションは、前記サービスが提供されるネットワークにおける障害復旧を実現するオペレーションであり、
　前記運用部品は、
　前記サービスを提供するネットワーク構成から情報を収集する情報収集部品と、
　前記収集した情報を解析する情報解析部品と、
　前記収集した情報を加工する情報加工部品と、
　前記ネットワークにおける障害確認用の試験を行う試験部品と、
　前記ネットワーク構成を変更する構成変更部品と、を含む、
　ことを特徴とする請求項１に記載のオペレーション装置。
　前記運用部品の各々の動作を保守者が許可するメッセージを、前記運用部品の各々に送信する保守者ＵＩ（ユーザインタフェース）を、前記運用部品として含む、
　ことを特徴とする請求項１または請求項２に記載のオペレーション装置。
　ネットワーク上のサービスに関するオペレーションを実行するオペレーション装置におけるオペレーション方法であって、
　前記オペレーション装置は、
　前記オペレーションとして実行される運用プロセスを部品化した、複数種類の運用部品の間でやり取りされるメッセージを保存するメッセージ保存部と、
　前記運用部品の各々に適用されるルールを保存する発火ルール保存部と、
　前記運用部品の各々の動作内容を示すアクションを保存するアクション保存部と、を有しており、
　前記メッセージ保存部および前記発火ルール保存部を参照して、前記ルールとして実行可能な発火ルールが存在すれば、前記アクション保存部から当該発火ルールに該当するアクションを選択する処理を、前記運用部品ごとに実行するステップと、
　前記選択されたアクションを、前記運用部品ごとに実行するステップと、
　前記実行したアクションの実行結果に基づいて、他の前記運用部品宛のメッセージを作成する処理を、前記運用部品ごとに実行するステップと、を実行する、
　ことを特徴とするオペレーション方法。
　前記オペレーションは、前記サービスが提供されるネットワークにおける障害復旧を実現するオペレーションであり、
　前記運用部品は、
　前記サービスを提供するネットワーク構成から情報を収集する情報収集部品と、
　前記収集した情報を解析する情報解析部品と、
　前記収集した情報を加工する情報加工部品と、
　前記ネットワークにおける障害確認用の試験を行う試験部品と、
　前記ネットワーク構成を変更する構成変更部品と、を含む、
　ことを特徴とする請求項４に記載のオペレーション方法。
　前記運用部品の各々の動作を保守者が許可するメッセージを、前記運用部品の各々に送信する保守者ＵＩを、前記運用部品として含む、
　ことを特徴とする請求項４または請求項５に記載のオペレーション方法。