JP2007004337A - 自律運用管理システム、自律運用管理方法及びプログラム - Google Patents

Abstract

【課題】 運用管理ポリシに基づいて自律的にシステム運用管理を行う自律運用管理システムにおいて、ポリシやポリシによって起動されるワークフローの問題によって起こる不適切な自律制御シーケンスを検知し、問題のある箇所に対する自律制御機能を部分的に停止し、管理者によるポリシ制御のデバッグ作業を効率化する。
【解決手段】 判断手段１３は、運用管理ポリシ１６１に記述されたワークフローの実行を要求し、要求されたワークフローを実行する実行手段２３は、停止判断ルール２６１に基づいて、ポリシ記述に現れない制約に基づいた異常状態を検知する。実行手段２３は、異常状態を検知すると、特定の判断手段１３からの要求又は特定の制御対象に対する要求に従うワークフローの実行を停止することによって、部分的に自律制御を停止し、管理者などによるデバッグ作業を効率化する。
【選択図】図１

Description

本発明は自律運用管理システム、自律運用管理方法及びプログラムに関し、特に、計算機システムの自律制御に際して部分的に自律制御を停止することができる自律運用管理システム、自律運用制御方法及びプログラムに関する。

分散資源計算機システムでは、自律運用管理システムを導入する例が増えている。自律運用管理システムは、ネットワークで接続された複数の計算機資源に対する煩雑な管理作業を自動化するものであり、制御対象のシステム状態を監視し、予め設定された運用規則（以下、ポリシと記述する）に基づき、システム環境に適応した運用手順（以下、ワークフローと記述する）を自動的に実行する。特許文献１では、ストレージシステムの運用において、システム環境の変化に適応して自動的に運用を継続する手法を示している。また、特許文献２では、宇宙機の自律的制御を実現するための手法を示している。

上記特許文献に記載された従来の自律運用管理システムは、企業内のシステム管理や一つの宇宙機システムの制御において有効に機能する。しかし、これら自律運用管理システムでは、ポリシを作る際に必要な情報が全て取得できる状況にあることや、ポリシで呼び出すワークフローと実際に制御を実行するワークフローの実装との間に食い違いがないことが前提となっている。この前提が成り立たなければ、意図した状況とは異なる状況でポリシ制御が実行され、或いは、意図した制御とは異なる制御をワークフローが実行してしまうことがあり得る。

例えば、データセンタや大企業の社内システムにおいて、複数の管理者やサービス運用者がシステムの一部を共有して使っている状況を考える。各管理者や運用者は、業務の目的や、セキュリティの要件により、それぞれの運用管理ポリシに基づいてシステムを自律的に管理することを要求する。このような状況下では、ある管理者は別の管理者がどのような制御を実行しているかといった情報や、他の管理者に割り当てられている資源の情報を、必ずしも全ては知ることができない。また、ポリシによって起動されるワークフローは、人間のミスやシステム環境の変化により、ポリシの制御と整合性が常に取れているとは限らない。

従って、先に述べた前提は、複数の独立したポリシ制御によって一つのシステムを運用管理する場合や、仮想化した制御対象に対してポリシを定義する場合などでは、満たされない可能性がある。このような場合には、ポリシ制御とその効果との不整合を防ぐために、ポリシ記述者がその不整合を把握するための仕組みが必要となる。現在の自律運用管理システムは、人手を介さずに自動的に運用を継続することをその目的としており、このため、ポリシ制御とその効果との不整合を検出してポリシ記述者に通知し、ポリシやワークフローの実装を管理者などが修正する仕組みが存在しない。
特開２００４−２２７３５９ 特開平１０−３２９８００

従来の自律運用管理システムにおける第１の問題点は、複数の自律制御機能によって運用管理されるシステムでは、ある自律制御機能が他の自律制御機能によって、ポリシ記述者の意図しない制御シーケンスが生じたときに、対処する方法が存在しないことである。その理由は、他の自律制御の制御情報を把握できない環境では、意図しない制御シーケンスが生じる理由を解析できないためである。

第２の問題点は、仮想化又は抽象化された情報やワークフロー定義に基づいてポリシによる自律制御をするシステムでは、仮想化や抽象化の過程で抜け落ちた情報間の制約によって、ポリシ記述者の意図しない制御結果を招いたときに、対処する方法が存在しないことである。その理由は、情報の仮想化や抽象化によって全ての情報が把握できない環境では、意図しない制御結果が生じた際の原因を解析できないためである。

第３の問題点は、ワークフローを実行する個々の資源に対する制御スクリプトに誤りがあった場合や、ポリシ記述者の意図した制御とは異なる制御が実装されていた場合に、生じた問題を確認し、ポリシ記述者に通知するための仕組みが存在しないことである。その理由は、ポリシ記述者はポリシ記述時点での、制御スクリプトの外部仕様に基づいてポリシを記述するため、制御スクリプトの動作環境が変化した場合や、外部仕様と実装とで不整合がある場合に、意図しない制御結果が生じた原因を解析できないためである。

上記従来の自律運用管理システムにおける問題に鑑み、本発明の目的は、複数の自律制御機能によって運用管理されるシステムで、ある自律制御機能が他の自律制御機能によって、ポリシ記述者の意図しない制御シーケンスが生じたことを判断し、問題のある自律制御機能を部分的に停止し、ポリシ記述者、システム管理者に対応を要求することが出来る自律運用管理システム、方法、及びプログラムを提供することを目的とする。

本発明の他の目的は、仮想化又は抽象化された情報やワークフロー定義に基づいてポリシによる自律制御をするシステムで、仮想化や抽象化される過程で抜け落ちた情報間の制約によって、ポリシ記述者の意図しない制御が行われたことを判断し、問題のある自律制御機能を部分的に停止し、ポリシ記述者、システム管理者に対応を要求することが出来る自律運用管理システム、方法、及び、プログラムを提供することを目的とする。

本発明のさらに他の目的は、ワークフローを実行する個々の資源に対する制御スクリプトに誤りがあった場合や、ポリシ記述者の意図した制御とは異なる制御が実装されていた場合に、生じた問題を確認し、問題のある自律制御機能を部分的に停止し、ポリシ記述者や、システム管理者など（以下、総称して管理者と呼ぶこともある）に対応を要求することが出来る自律運用管理システム、方法、及び、プログラムを提供することを目的とする。

更に、本発明の他の目的は、上記自律運用管理システムに用いられる方法及びプログラムを提供することを目的とする。

上記目的を達成するために、本発明の第１の視点に係る自律運用管理システムは、制御対象の状態を監視する状態監視部と、該状態監視部による監視情報とポリシ記憶部に記憶された運用管理ポリシとに基づいて制御対象に必要な制御を決定する制御決定部と、該制御決定部の決定に基づいて制御対象を制御する制御実行部とを備える自律運用管理システムにおいて、
制御対象の自律制御を停止する停止条件を記述した停止判断ルールを記憶するルール記憶装置と、前記監視情報及び停止判断ルールに基づいて停止条件の成立を検知する停止判断手段とを備え、
前記停止判断手段は、前記停止条件の成立を検知すると、前記制御実行部による制御実行機能、及び、前記状態監視部から前記制御実行部に与える監視情報の少なくとも一方を制限することを特徴とする。

また、本発明の第２の視点に係る自律運用管理システムは、ネットワークにより接続された複数の計算機を自律的に運用管理する自律運用管理システムにおいて、
システム内の管理対象の情報を収集する情報収集手段と、
前記情報収集手段によって収集された情報と記憶装置に記憶された運用管理ポリシとに基づいて自律的に制御を決定する制御決定手段と、
前記制御決定手段からの制御要求に基づいて前記管理対象の制御を実行する制御実行手段と、
前記制御実行手段による制御の実行状態、及び、前記情報収集手段によって収集された制御対象の情報の少なくとも一方と、記憶装置に記憶された停止条件とに基づいて、自律制御停止の判断をする停止判断手段とを備え、
前記停止判断手段は、前記自律制御停止の判断をしたときには、前記制御実行手段の機能、及び、前記制御決定手段に与える監視情報の少なくとも一方を制限するこことを特徴とする。

また、本発明の自律運用管理方法は、ネットワークにより接続された複数の計算機から成るシステムを自律的に運用管理する方法において、
システムの監視装置から得られる監視情報及び記憶装置に記憶された運用管理ポリシに基づいて、制御実行手段が制御のワークフローを実行するステップと、
前記制御実行手段が、前記制御のワークフローを実行するにあたり、前記監視情報と、記憶装置に記憶された、制御対象の自律制御を停止する停止条件を記述した停止判断ルールとに基づいて、停止条件の成立の有無を検知するステップと、
前記停止条件の成立を検知すると、前記制御実行手段が実行する制御実行機能、及び、前記監視装置が前記制御実行手段に与える監視情報の少なくとも一方を制限するステップとを備えることを特徴とする。

本発明のプログラムは、ネットワークにより接続された複数の計算機を自律的に運用管理する制御コンピュータのためのプログラムであって、前記制御コンピュータに、
システムの監視装置から得られる監視情報及び記憶装置に記憶された運用管理ポリシに基づいて、制御のワークフローを実行する処理と、
前記制御のワークフローを実行する処理にあたり、前記監視情報と、記憶装置に記憶された、制御対象の自律制御を停止する停止条件を記述した停止判断ルールとに基づいて、停止条件の成立の有無を検知する処理と、
前記停止条件の成立を検知すると、前記制御のワークフローの実行機能、及び、前記監視装置から前記前記制御のワークフローを実行する処理の際に与える監視情報の少なくとも一方を制限する処理とを実行させることを特徴とする。

本発明の第１及び第２の視点に係る自律運用管理システム、本発明の自律運用管理方法、及び、プログラムによると、ワークフローの実行手段による制御の実行機能、及び、システム内の情報を監視する監視装置（情報収集手段）からワークフローの実行手段に与える監視情報の少なくとも一方を制限する構成により、制御停止条件が満たされた場合にも、制御実行手段における監視情報及び運用管理ポリシから制御のワークフローを決定する制御決定機能には直接的な操作を加えることなく、間接的に自律制御動作を停止できるので、ポリシ記述者などの意図しない制御シーケンスが発生した場合には、ポリシ記述者などによる原因解析が可能になる。

本発明では、特に停止判断ルールには、他の実行手段の制御に起因する制御状態や、一般に運用管理ポリシには含まれない抽象化されていない情報を含めることができるため、運用管理ポリシでは判断できない停止条件の成立の有無を監視することができる。また、実行手段の機能を制限することにより、或いは、監視装置から実行手段の実行決定機能に与える監視情報を制限することにより、実行手段の制御決定機能に複雑な制御を実装することなく、自律制御機能を停止することができる。

ここで、実行機能及び監視情報の「制限」とは、実行機能及び監視情報の少なくとも一部を停止することをいう。また、「制御の実行状態」とは、特に情報収集手段からの監視情報によらなくとも、システム内で自明な情報により判別可能なシステムの状態、例えば、制御のワークフローが開始する前または後などをいう。なお、これら状態の情報は、監視情報として監視装置から停止判断手段に与えられる。「機器に依存する設定情報の制約」とは、システム内に存在する機器の特殊性などのために、その機器に特別な設定を付け加えたことにより、発生する制約をいう。このような制約は、一般化、抽象化されるべきポリシにはなじまないので、個別の業務処理などに特に必要な停止条件などと共に、停止判断ルールに加えられることが好ましい。

前記停止判断手段又は実行手段は、前記停止条件が成立すると、システムの管理者に警報を発生することが好ましい。この場合、意図しない制御状態などについて、管理者などによる迅速な原因解析が可能になる。

前記停止条件には、前記運用管理ポリシに記述できない機密保持された情報、及び、システム内の機器に依存する設定情報の制約などを含ませることが出来る。この場合、運用管理ポリシには記述できない情報や、運用管理ポリシに記述すべきではない特殊な情報などを含ませることにより、一般化、抽象化した運用管理ポリシのみによる制御が可能になる。

前記停止条件に、前記運用管理ポリシで想定した制御スクリプトの実行効果と実際の実行効果とが異なる場合を含ませることが出来る。この場合、自律制御における問題点の発見が迅速になる。

前記停止判断手段は、前記自律制御停止の判断をしたときには、前記情報収集手段から前記制御決定手段に提供される全ての監視情報の提供を停止させること、或いは、前記情報収集手段から前記制御決定手段に提供される監視情報の一部の提供を停止させること、或いは、前記情報収集手段から前記制御決定手段に提供される監視情報に、制御停止の対象を示す情報を加えて提供させることも出来る。このようにすることで、システムの構成に応じた停止状況、或いは、所望の自律制御の停止状況が得られる。

前記停止判断手段は、その少なくとも一部を、ワークフローの実行状態に応じて起動される監視タスクによって実現することが出来る。この場合、きめ細かな停止条件の成立の有無の判断が可能になる。

前記制御実行手段は、監視状態の変化に基づいて制御のワークフローを実行するにあたり、該ワークフローの実行に先だって、該ワークフローのために定義された事前条件、及び、前記運用管理ポリシによって制御が決定された際の判断条件の少なくとも一方が満たされていることを確認することも好ましい。この場合、一般化、抽象化した運用管理ポリシを修正することなく、特殊な停止条件で自律制御を停止することが出来る。また、一方のシステム運用者の運用管理ポリシにより、他方のシステム運用者にとって不適切な制御が行われる事態を避けることも出来る。

前記停止判断手段は、監視状態の変化に基づいて制御のワークフローが実行された後に、該ワークフローに定義された事後条件が満たされているか否かを判定することも好ましい。この場合、一方のシステム運用者の運用管理ポリシにより、他方のシステム運用者にとって不適切な制御が行われた場合に、迅速に発見が可能である。

次に、発明を実施するための最良の形態について図面を参照して詳細に説明する。図１を参照すると、本発明の第１の実施形態に係る自律運用管理システムは、自律運用のための判断手段を備える複数の計算機１０と、自律運用のための実行手段（制御実行手段）を備える計算機２０と、複数の制御対象の計算機３０と、これらを接続するネットワーク４０とで構成される。

計算機１０は、システム運用者又は管理者からデータの入力を受け付ける入力装置１１と、システム運用者又は管理者に対して情報を提供する表示装置１５と、運用管理ポリシ１６１を格納する記憶装置１６と、運用管理ポリシに基づいて自律的にワークフローを起動する判断手段１３を含む処理装置１２と、ネットワーク４０を介して計算機２０と通信するための通信装置（通信インターフェイス）１４とを備える。計算機２０は、システム運用者又は管理者からデータの入力を受け付ける入力装置２１と、システム運用者又は管理者に対して情報を提供する表示装置２５と、判断手段１３による要求を解釈して実行する実行手段（制御実行手段）２３を有する処理装置２２と、停止判断ルール２６１を格納する記憶装置２６と、ネットワーク４０を介して他の計算機１０、３０と通信するための通信装置２４を備える。制御対象の計算機３０は、ネットワークを介して計算機２０と制御されて自律業務を行う複数の計算機として構成される。

図２は、計算機１０の判断手段１３及び記憶装置１６の詳細な構成を示した図である。判断手段１３はネットワークを介して収集した制御対象の情報を監視する情報監視部１３１と、監視情報と運用管理ポリシ１６１とに基づいて、ワークフローを起動する制御決定部１３２と、制御決定部１３２で指定されたワークフローを作成するためのワークフロー定義１６３を記憶装置１６から読み出し、そのワークフロー定義から作成したワークフローの実行を実行手段２３に要求する制御要求部１３３とからなる。記憶装置１６には、情報監視部１３１が利用する監視設定情報１６２と、制御決定部１３２が利用する前記運用管理ポリシ１６１と、制御要求部１３３が利用する前記ワークフロー定義１６３とが格納される。

図３は、計算機２０の実行手段２３及び記憶装置２６の詳細な構成を示したブロック図である。実行手段２３は、ネットワーク４０を介して複数の計算機１０の判断手段１３から要求されるワークフロー実行要求を受け付けて、調停を行う要求処理部２３４と、要求処理部２３４から渡される各制御対象計算機３０への制御を、ネットワーク４０を介して実行する要求実行部２３５と、ネットワーク４０を介して各制御対象計算機３０から情報を収集する情報収集部（監視装置）２３２と、情報収集部２３２が集めた情報を変換及び加工し、ネットワーク４０を介して複数の判断手段１３に情報を提供する情報提供部２３１と、要求実行部２３５から受け取る制御の実行状態情報と、情報収集部２３２から受け取る監視情報と、記憶装置２６から読み出した停止判断ルール２６１とから、自律制御停止の判断をし、要求処理部２３４及び／又は情報提供部２３１の機能を制限する停止判断部２３３とから構成される。記憶装置２６には、停止判断部２３３が制御の実行状態通知に応じて監視タスクを開始するための、ワークフローに付随する制約条件２６２と、該制約条件２６２をチェックした後の停止処置を記述した停止判断ルール２６１とが格納される。

計算機１０の判断手段１３は、計算機２０の実行手段２３を介して制御対象の情報を監視し、運用管理ポリシ１６１に基づいて自律的にワークフローを決定し、実行手段２３にワークフロー実行要求を送る。ワークフロー実行要求を受理した実行手段２３は、ネットワーク４０を介して制御対象の計算機３０にアクセスし、その制御を実行する。また、制御対象の計算機３０から、制御対象の負荷情報や障害情報や構成情報を収集し、情報を変換及び加工して判断手段１３に提供する。判断手段１３と実行手段２３の連携により、制御が継続的に且つ自律的に実行される。

次に、第１の実施形態の動作について詳細に説明する。はじめに、自律運用管理を要求するアプリケーションやサービスの運用者、システムの一部の管理を任されるネットワーク管理者やサーバ管理者などは、それぞれの組織が持つ運用管理ポリシに基づいて、自律制御を行うための運用管理ポリシを作成し、計算機１０の入力装置１１を介して、記憶装置１６に、運用管理ポリシ１６１及び情報の監視設定情報１６２と、制御プログラムとを格納する。

図４に、記憶装置１６に記憶された運用管理ポリシ１６１、監視設定情報１６２、及び、ワークフロー定義部１６３の例を示す。運用管理ポリシ１６１は、少なくとも条件部と制御部とを持ち、ルール形式で記述される。このルールの条件部に現れる情報を監視するための設定情報が監視設定情報１６２であり、監視の対象や監視の時間間隔などを設定する。監視情報は実行手段２３によって生成されて提供されるものである。また、ルールの制御部に現れるワークフローを実行するための設定情報がワークフロー定義１６３であり、ワークフロー定義１６３は、ワークフローの操作手順のテンプレートとして利用される。得られたワークフローは、実行手段２３によって、機器を制御するための詳細な制御手順に変換されて実行される。

次に、一つのデータセンタや、企業システムを安定運用させる責任を持つシステム管理者は、自律制御の挙動に異変が生じた時に、自律制御機能を停止してシステム管理者が介在して問題解析を行うための停止判断ルールを用意し、計算機２０の入力装置２１を介して、記憶装置２６に停止判断ルール２６１を格納する。

停止判断ルール２６１及びそれに含まれる停止条件の例を図５に示す。停止判断ルール２６１は、ワークフローや詳細な制御手順に付随する事前条件、事後条件、及び、いかなる制御要求を受け付けたときでも常に成立していなければならない不変条件などを使って記述される。

事前条件と事後条件は、運用管理ポリシやワークフローの詳細から一部を自動生成することができ、それ以外にも、管理者が追加することができる。例えば、図５の例では、管理者が事前条件として、ネットワーク機器を制御するためのプログラムが利用可能な状態であることを事前条件に加えている。この条件は、nwController.status = runで表現されている。停止判断ルールでは、これらの条件がどのようなタイミングで違反した場合に、どの自律制御を停止するかを指定する。例えば、２行目の停止判断ルールは、ワークフロー実行後、制御が成功しているにもかかわらず、事後条件が２分間経っても満たされない場合に、停止処置を実行することを示している。ここで、行う停止処置は、全ての資源に対するこの要求者からの制御要求を停止し（要求停止（All,要求者））、要求者に対する全ての資源情報の提供を停止し（情報フィルタ（All,要求者））、管理者に対して停止処置を講じた旨を通報すること（通報（管理者））を示している。

次に、計算機１０の判断手段と計算機２０の実行手段２３とが運用を開始することにより、運用管理ポリシ１６１に基づいた自律運用管理が開始される。監視情報、運用管理ポリシ、ワークフローに不整合がなく、他の自律制御機能による制御が混入しなければ、人手を介すことなく、継続的に自律運用管理が実行される。

図６は、計算機１０の判断手段１３における制御ループをフローチャートで示している。情報監視部１３１が監視設定情報１６２を読み込み（ステップＳ１）、それに基づいて監視を開始し（ステップＳ２）、監視情報を制御決定部１３２に入力する（ステップＳ３）。制御決定部１３２では、入力された監視情報や制御要求部１３３からのワークフロー実行結果などと、記憶装置１６に記憶された運用管理ポリシ１６１とを照らし合わせ、条件にマッチする運用管理ポリシがあるか否かを判定する（ステップＳ４）。ステップＳ４で、該当する運用管理ポリシがあった場合には、そのポリシの制御部に記述されたワークフローを、制御要求部１３３に入力として与え（ステップＳ５）、ステップＳ６に進む。条件にマッチする運用管理ポリシが存在しない場合には、何もせずに監視ステップＳ２に戻る。ステップＳ６では、制御要求部１３３は、実行手段２３に対して、制御決定部１３２から入力されたワークフローの実行を要求し、その実行結果を受け取る（ステップＳ７）。実行手段２３から受け取った実行結果は、制御決定部１３２に入力として与え（ステップＳ８）、その後ステップＳ４に戻り、更に運用管理ポリシにマッチする監視状態の発生を監視する。

図７は、実行手段２３における監視情報取得提供処理をフローチャートで示す。図６の処理に基づいて、判断手段１３から監視情報の取得が要求されたとき、実行手段２３では情報提供部２３１がこの要求を受け取る（ステップＳ１１）。情報提供部２３１では、要求元の判断手段１３の権限や、要求された情報の内容をチェックし、提供可能な情報を生成するために必要な情報を収集する要求を情報収集部２３２に対して発行する（ステップＳ１２）。情報収集部２３２は、複数の制御対象から、要求された情報を収集し（ステップＳ１３）、収集した情報を情報提供部２３１に返す（ステップＳ１４）。情報提供部２３１は、必要に応じて情報の内容を加工及び修正して（ステップＳ１５）、情報要求元の判断手段１３に監視情報を結果として返す（ステップＳ１６）。

図８は、実行手段２３におけるワークフロー実行処理をフローチャートで示す。図６の処理に基づいて、判断手段１３からワークフロー実行要求が入力されたとき、実行手段２３では、要求処理部２３４がこの要求を受け取る。要求処理部２３４は、ワークフロー実行要求を実行するための詳細な制御手順を生成し（ステップＳ２２）、要求実行部２３５に入力する（ステップＳ２３）。要求実行部２３５は、実際に制御対象に対して制御を開始する前に、停止判断部２３３に制御を開始することを通知する（ステップＳ２４）。また、要求実行部２３５で、実際に制御を行い（ステップＳ２５）、その制御が終了した後に（ステップＳ２６）、制御結果を要求処理部２３４に返す前に、停止判断部２３３に制御が終了したことを通知する（ステップＳ２７）。要求処理部２３４は、制御結果を要求実行部２３５から受け取り（ステップＳ２８）、受け取った制御結果をワークフロー実行結果として判断手段１３に返す（ステップＳ２９）。

実行手段２３は、複数の判断手段１３から、監視情報取得要求とワークフロー実行要求とを非同期で受け付ける。このため、実行手段２３による図７及び図８の処理は、それぞれ複数が同時に実行されることがある。次に、停止判断ルールに基づいて自律制御機能を停止する際の動作を示す。

図９は、実行手段２３における自律制御停止処理をフローチャートで示す。図８の処理に基づいて、停止判断部２３３は、要求実行部２３５から制御開始通知を受け取る（ステップＳ３１）。停止判断部２３３は、その制御を開始しようとしているワークフローに付随する制約条件を読み込む（ステップＳ３２）。始めに、ワークフローを実行する前に満たされているべき事前条件が定義されているかどうかを調べ（ステップＳ３３）、定義されている場合には、その事前条件をチェックするための監視タスクを開始する（ステップＳ３４）。次いで、停止判断ルールに基づいて、自律制御機能を停止する必要があるか否かを判断する（ステップＳ３５）。ステップＳ３５で、停止が必要と判断された場合には、ステップＳ４３から始まる共通の自律制御停止処理フローに進む。停止の必要がない場合には、ステップＳ３６に進み、更に不変条件の有無をチェックする。不変条件は、ワークフロー処理中に満たされているべき条件を記述したもので、制御終了通知が通知されるまでは継続してチェックし続ける（ステップＳ３７、Ｓ３８）。停止判断ルールに基づいて、自律制御機能を停止する必要があると判断された場合には、ステップＳ４３から始まる共通の自律制御停止処理フローに進む。停止不要と判断され、更に制御終了通知が要求実行部２３５から通知されると（ステップＳ３９）、事後条件の指定の有無を判断する（ステップＳ４０）。事後条件が指定されている場合には、事後条件をチェックするための監視タスクを開始する（ステップＳ４１）。事後条件で停止の必要の有無を判定し、停止が必要であれば、ステップＳ４３から始まる共通の自律制御停止処理に進む。停止が不要であれば、一連の処理が終了し、自律運用管理システムは自律制御を継続する。

上記各条件チェック（ステップＳ３５、Ｓ３８、Ｓ４２）で、記述された停止判断ルールに基づいて、自律制御機能を停止する必要があると判断されると、プロセスは、ステップ４３で始まる共通の自律制御停止処理フローに進む。停止の必要がなければ処理を終了する。自律制御停止処理は、停止判断ルールに記述された方法に基づいて行われる。停止判断ルールに、特定の判断手段１３からの要求、或いは特定の制御対象に対する制御要求を停止するという記述が存在する場合には、停止判断部２３３は、要求処理部２３４の設定を変更し、要求処理機能に制限をかける。また、停止判断ルールに、特定の判断手段１３に対して監視情報の提供を制限する、或いは、特定の制御対象の情報提供を制限するという記述が存在する場合には、停止判断部２３３は、情報提供部２３１の設定を変更し、情報提供機能に制限をかける。

上記実施形態の自律運用管理システムでは、停止判断ルールに記述された全ての停止処理が完了したら、停止判断部２３３は、処理を終了する。この停止処理は、停止判断部２３３や判断手段１３などの直接的な要求によって自律制御を停止するのではなく、要求処理機能や情報提供機能に制限をかけることによって、部分的に自律制御機能を停止させるものである。また、この停止の情報は、計算機システムの管理者に通知される。このため、判断手段１３の誤判断によってシステムの構成変更が行われることがないため、管理者による復旧作業が効率化できる。

次に、要求処理部２３４によって、判断手段１３の制御機能を抑制する動作について説明する。図１０は、停止判断部２３３から停止設定が行われた要求処理部２３４の動作をフローチャートで示す。要求処理部２３４は、判断手段１３からワークフロー実行要求を受け付けると（ステップＳ５１）、詳細な制御手順を生成する（ステップＳ５２）。次いで、その制御手順による処理が、停止判断部２３３によって設定された拒否条件に該当するか否かをチェックする（ステップＳ５３）。拒否された判断手段１３からの制御要求である場合、或いは、拒否された制御対象への処理を含む場合は、このワークフロー実行要求を拒否し（ステップＳ５５）、処理を終了する。また、そのような処理に該当しない場合には、生成した制御手順を実行する（ステップＳ５４）。

次に、情報提供部２３１によって、判断手段１３の制御機能を抑制する動作について説明する。図１１は、停止判断部２３３によって停止設定が行われた情報提供部２３１の動作をフローチャートで示す。情報提供部２３１では、判断手段１３から監視情報取得要求を受けたあと、情報収集部２３２から制御対象の情報を取得する。そこで、停止判断部２３３によって設定されたフィルタ条件をチェックする。情報の提供を制限している判断手段１３からの要求である場合や、情報の提供を制限している制御対象の情報を含んでいる場合には、その情報を削除する、或いは、利用不可能であることを示す情報を付加して、提供すべき情報を生成する。これにより、判断手段１３が誤判断を引き起こす元情報が断たれるため、誤ったシステム構成を未然に防止し、管理者による復旧作業を効率化することが可能になる。

上記実施形態では、自律制御システムの相互作用によって顕在化しにくいシステム管理上の問題を早期に発見し、発見後は部分的に自律制御機能を停止していくことで、問題の箇所を絞りこみ、管理者が復旧作業や運用管理ポリシを見直すことを容易にする。

次に、本発明の第２の実施形態について図面を参照して詳細に説明する。図１２は、第２の実施形態に係る自律運用管理システムを示す。第１の実施形態と異なる点は、判断手段と実行手段とが同一の計算機上で動作する点である。その他の構成は、図１と同様である。自律運用管理システムは、判断手段及び実行手段を備える計算機５０と、制御対象の複数の計算機３０と、これらを接続するネットワーク４０とから構成される。本実施形態の判断手段５３及び実行手段５４の構成は、それぞれ図２及び図３に示した判断手段１３及び実行手段２３の構成と同様である。判断手段５３は、記憶装置５５に記憶された運用管理ポリシ５５１を参照して、システムが実行すべき自律制御を判断し、実行手段５４は、記憶装置５５に記憶された停止判断ルール５５２に基づいて、自律運用停止の必要の有無を判断する。

次に、本実施形態の動作について説明する。始めに、サービスを運用するための運用管理ポリシ５５１と、自律運用を停止して人間の操作を介入させるための停止判断ルール５５２とを、入力装置５１を介して記憶装置５５に格納する。運用管理ポリシ５５１ができるだけ少ない記述でより多くの状況判断に対応できるように、実行手段５４は、抽象化、集約化、仮想化された情報（以下では抽象化された情報と呼ぶ）を参照して、抽象化、集約化、仮想化されたワークフロー（以下では抽象化されたワークフローと呼ぶ）を実行する。実行手段５４は、抽象化されたワークフローを詳細な制御手順に展開して実行し、制御対象から収集した情報から抽象化された情報を生成して、判断手段５３に提供する。

判断手段５３及び実行手段５４の運用を開始することにより、運用管理ポリシに基づいた自律運用管理が開始する。監視情報、運用管理ポリシ、制御プログラムに不整合がなければ、人手を介すことなく、継続的に自律運用管理が実行される。

判断手段５３における制御ループは、図６のフローチャートで示される。実行手段における監視情報提供処理は、図７のフローチャートで示される。ここで判断手段５３に提供される情報は抽象化された情報を含む。実行手段５４におけるワークフロー実行処理は、図８のフローチャートで示される。ここで判断手段が要求するワークフローは抽象化されたワークフローを含む。

次に、停止判断ルールに基づいて自律制御機能を停止する際の動作を示す。実行手段５３における自律制御停止処理は図９のフローチャートで示される。ワークフローに付随した制約条件は、抽象化される前の情報を含む。停止判断部２３３では抽象化されてチェックできない条件に関し、停止判断ルール５５２が詳細な条件を指定することで補う。

次に、要求処理部２３４によって、判断手段５３の制御機能を抑制する動作について説明する。 停止判断部２３３によって、停止設定が行われた要求処理部２３４の動作は図１０のフローチャートで示される。抽象化されたワークフローは、要求処理部２３４で詳細な制御手順に展開されたあと（ステップＳ５２）、実際に制御を行う上で拒否条件に違反がないか否かがチェックされる（ステップＳ５３）。

次に、情報提供部２３１によって、判断手段１３の制御機能を抑制する動作について説明する。 停止判断部２３３によって、停止設定が行われた情報提供部２３１の動作は、図１１のフローチャートで示される。抽象化された情報に拒否条件を満たすような情報が含まれていないか否かがチェックされる（ステップＳ６３）。

本実施形態では、抽象化、集約化された情報だけでは判断できない異常な状態を検知し、問題箇所と関連する自律制御機能を部分的に停止することで、管理者が運用管理ポリシや制御プログラムを改善していくことを容易にする。

次に、本発明の第１の実施形態に係る自律運用管理システムの具体的実施例について図面を参照して説明する。図１３は、計算機システム上で、アプリケーションを運用するアプリケーション運用者と、サーバの管理を担当しているサーバ管理者がそれぞれ、計算機ＰＣ１（１０）及びＰＣ２（１０）を使用し、リモートモで管理作業を行う状況を示している。計算機ＰＣ１、ＰＣ２はそれぞれ、それぞれの管理者が持つ運用管理ポリシに基づいて自律的に運用管理を継続するために、判断手段１３を搭載している。各計算機ＰＣ１、ＰＣ２の判断手段１３によって要求される監視情報取得要求や、ワークフロー実行要求は、別の計算機である管理サーバ２０に送られる。管理サーバ２０は、判断手段１３から要求された内容を解釈して実行するために、実行手段２３を搭載する。実行手段２３は、ネットワーク４０を介して、制御対象となるサーバ、host01（３０）、host02（３０）、host03（３０）に制御コマンドを発行し、また、これらホスト３０から構成情報や性能情報を集める。各管理者の計算機１０上で動作する判断手段１３と管理サーバ２０上で動作する実行手段２３とによって、それぞれの自律運用管理が実行されている。

ここで、アプリケーション運用者は、host03上でアプリケーションを稼動させており、サーバの負荷が軽いときには、アプリケーションの可用性を向上させるような制御を行うポリシを登録している。このポリシでは、サーバの負荷が軽いときには、例えば、同時に実行するスレッドの数を増加させる。逆に、サーバの負荷が高くなったときには、アプリケーションの動作制限を行うようなポリシも登録してある。このポリシでは、サーバの負荷が高くなったときには、例えば、同時に実行するスレッドの数を減らす。

一方、サーバ管理者は、host03を含むいくつかのサーバ３０のメンテナンスをしており、各サーバ３０の稼動を脅かすような異常を検知して、対処を行うようなポリシを登録している。このポリシは、例えば、アプリケーションがリソースを浪費していると、そのアプリケーションを再起動する。

上記のようなポリシによって自律運用管理が行われるとき、従来の自律運用管理システムでは、次のような問題が発生し得る。始めに、アプリケーション運用者の判断手段１３が、自律的にアプリケーションの可用性を向上させる制御を行ったとする。この設定はメモリに保持され、ファイルなどに書き出されない一時的な設定情報である。しかし、この設定変更によって、アプリケーションの負荷が急激に上昇してしまったとする。アプリケーション運用者の判断手段１３は、何れかの時点で負荷の上昇を検知して、この設定を元に戻す処理を起動する。このとき、同時にサーバ管理者の判断手段１３は、負荷の情報を検知しており、その運用ポリシ１６１に従って、アプリケーションの再起動処理を実行する可能性がある。

どちらの要求が先に管理サーバ２０の実行手段２３に届くかは、事前に予測することができない。ここで、サーバ管理者の判断手段１３による再起動処理が先に実行されたとすると、アプリケーションは初期状態に戻り、負荷も低い状態になる。これに遅れて、アプリケーション運用者の判断手段１３からの設定変更要求が実行されると、この処理自体は問題なく終了し、通常通りの運用が開始される。

ここで問題となるのは、アプリケーション運用者の判断手段１３とサーバ管理者の判断手段１３の双方は、互いがどのような制御を実行したかを把握していないことである。 アプリケーション運用者の判断手段１３は、サーバの負荷が下がった理由が再起動によるものであることを把握しておらず、サーバ管理者の判断手段１３は、アプリケーションの負荷上昇がアプリケーションの自動的な設定変更によるものであることを把握していない。このため、この一連の制御は、繰り返し何度も実行される可能性がある。本来は、アプリケーションの設定変更のパラメタを見直す必要があると考えられるが、双方の自律制御機能は運用管理ポリシ通りに正しく動作しているため、このような現象が生じていること自体を把握することが難しい。この例は単純な例の一つであり、このような、一つの判断手段が他の判断手段の制御を把握できないことに起因する、想定外の自律制御シーケンスは一般的に存在し得る。

上記実施例の自律運用管理システムでは、次のような動作により、上記の問題を解消する。アプリケーションの設定変更、及び、アプリケーションの再起動要求は何れも、管理サーバ２０の実行手段２３の要求処理部（２３４、図３）に届く。要求処理部２３４では、これらのワークフロー実行要求を詳細な制御手順に展開し、要求実行部２３５に入力する。

ここで、要求実行部２３５は、停止判断部２３３に要求の実行を開始することを通知する。停止判断部２３３は、要求の内容から、停止判断ルールを検索し、監視タスクを起動する。監視タスクは、要求実行部２３５より通知される要求処理の状態と、情報収集部２３２を介して取得する監視情報とを継続的にチェックする。

図１４は、アプリケーション運用管理者の運用管理ポリシ１６１、及び、“removeThread”処理に対応する事前条件及び停止判断ルールを示す。 “removeThread”は、アプリケーションの負荷を軽減することを目的とした設定変更処理であり、事前条件では、運用管理ポリシ１６１の判断部と同じ条件である、サーバhost03のＣＰＵ負荷が９０％以上で、現在のスレッド数制限が１００であるという条件を記述している。

アプリケーション運用者のみがシステム管理を行うという環境であれば、事前条件違反は起こりにくいが、サーバ管理者など他の管理者による管理も介在する可能性がある場合では、実行時に事前条件が満たされているという保障はない。“removeThread”処理に対応する停止判断ルールでは、事前条件に違反した項目がある場合には、アプリケーション運用者の判断手段１３に対してhost03の情報提供を制限し、host03に対する制御を制限し、アプリケーション運用者に通知するということが定義されている。サーバ管理者の判断手段１３によって、“removeThread”処理が実行される前にアプリケーション再起動処理が実行された場合には、このアプリケーションのスレッド数の設定は初期状態に戻り、負荷の問題も解消されるため、事前条件が満たされないことがわかる。したがって、停止判断ルールに基づいた停止処理が施され、アプリケーション運用者の判断手段１３のhost03への制御が制限される。アプリケーション運用者への通知によって、何らかの外部要因によって、意図した状況と異なる状況になっていることを知らせ、アプリケーション運用者が、問題を解析する。アプリケーション運用者が、ポリシ等を修正したあと、実行手段２３の停止設定を解除することで、自律制御を再開させる。復旧に至るまでは、host03のみが自律制御の対象外となり、それ以外の通常の自動化された業務は継続されて実行される。

次に、本発明の第２の実施形態に係る自律運用管理システムにおける具体的実施例を説明する。図１５は、この具体例を示すもので、システム上にあるアプリケーションを利用してサービスを運用しているサービス運用管理者が、管理サーバ５０を通じてシステム管理を行っている状況を示している。管理サーバ５０には判断手段５３と実行手段５４とが搭載され、サービス運用管理者は、仮想化された情報で制御可能な範囲のサービス運用管理ポリシ５５１を判断手段５３に関連して登録している。

例えば、サービスの運用管理者は、サービスの可用性を向上させるため、負荷分散対象サーバ３０の負荷上昇／降下に応じて、サーバの追加／削除を行うようなポリシを用意していたとする。図１６に、サーバ追加／削除の運用管理ポリシ５５２の例を示す。アプリケーションの負荷は、ＣＰＵ利用率やクライアント数のような具体的な数値データではなく、アプリケーション負荷のような抽象化された形で表記される。例えば、サーバの追加／削除を指示する制御コマンドも、“addHost”、“removeHost”で表され、具体的にどのサーバ３０を追加するか、どのような手順で追加するかといった情報は、ポリシ記述には現れない。情報を仮想化することによって、ポリシの記述は単純化され、サービス運用管理者の負担は軽減される。しかし、上記のようなポリシによって自律運用管理が行われるとき、従来の自律運用管理システムでは、次のような問題が発生し得る。この運用管理ポリシにおいて、サービスの運用管理者は、“addHost”を呼び出すことによって、アプリケーションの負荷分散対象のサーバが新規に割り当てられ、アプリケーション負荷が低下するという効果を期待する。

ところが、従来の自律運用管理システムでは、実行手段５４によって、“addHost”を解釈して実行するとき、制御プログラムにバグがあり、プログラム自体は正常終了するにもかかわらず、期待した効果が得られた旨のデータが得られないとすると、判断手段５３では、この不整合に対処することができなくなってしまう。図１６の運用管理ポリシ５５１によって“addHost”が起動し、ワークフローが正常終了したにもかかわらず、アプリケーションの負荷が“high”のままであると、繰り返し何度もこのポリシによる制御が行われることになる。 アプリケーションの負荷が実際に継続して“high”の場合には、この動作は正しいが、制御プログラムのバグである場合には、問題を特定してデバッグする必要がある。

しかし、判断手段５３によるポリシ制御は正常に動作しているため、このような状況を発見することは難しい。この例は単純な例の一つであり、制御プログラムや監視情報を仮想化、抽象化、集約化することに起因する、想定外の自律制御シーケンスは一般的に存在し得る。

上記実施例では、次のような動作により、上記の問題を解消する。図１６の運用管理ポリシ５５１で、起動される“addHost”のワークフロー実行要求は、実行手段５４の要求処理部（２３４、図３）に届く。 要求処理部２３４は、ワークフロー実行要求を詳細な制御手順に展開し、要求実行部２３５に詳細な制御手順を送る。ここで、要求実行部２３５は、停止判断部２３３に要求の実行を開始することを通知する。停止判断部２３３は、要求の内容から、停止判断ルールを検索し、監視タスクを起動する。監視タスクは、要求実行部２３５から通知される要求処理の状態と情報収集部２３２を介して取得する監視情報とを継続的にチェックする。

図１７は、負荷分散対象サーバ３０を追加した際の停止判断ルールを示す。停止判断ルールは、実行手段５４でチェックされるため、ポリシ記述とは異なり、抽象化、集約化されていない情報に対して、具体的な制約条件が設けられる。ここでは、ポリシ記述に現れるアプリケーション負荷の実体が、host03のＣＰＵ利用率である場合を示している。実行手段５４は、host03のＣＰＵ利用率が９０％以上のとき、アプリケーションの負荷が“high”であると、判断手段５３に通知する。

実行手段５４は、アプリケーション負荷がhighであるという状態が、host03のＣＰＵ利用率が９０％以上であることに対応することを把握しているため、事前条件、事後条件にhost03のＣＰＵ利用率に関する制約を加える。 また、“addHost”の効果として、host04のＩＰアドレスが10.2.0.3から10.1.3.2に変更されるということから、“addHost”の効果を事前条件、事後条件に加えることができる。これらの情報は、制御プログラムを展開する過程で自動的に生成することが可能であり、必要に応じて、人間が条件を追加して設定する。

制御プログラムのバグでも、プログラムは正常終了するが、システムが持つキャッシュ情報などによって、即座に設定が更新されないこともあるため、host04のＩＰアドレスが変更しなかった場合には、事後条件違反となり、要求処理部２３４において判断手段５３からの要求に対する応答を停止し、判断手段５３にアプリケーション負荷の情報を通知しないことにより、判断手段５３による制御を抑制する。

また、抽象化、集約化された情報からhost04が追加可能であると判断し、“addHost”が要求され、実行手段５４において、実際にＩＰアドレスの変更処理などにプログラムを展開した際に、追加可能でないことが発覚する場合がある。このような場合には、事前条件違反となり、要求処理部２３４において判断部からの要求を停止し、判断手段５３にアプリケーション負荷の情報を通知しないことにより、判断手段５３による制御を抑制、停止する。制御停止後に、サービス運用管理者が運用管理ポリシ５５１とそのポリシによって起動される制御プログラムの整合性に関して検査を行い、問題を究明し、ポリシ記述の改善、制御プログラムのデバッグを行う。

以上、本発明をその好適な実施形態例に基づいて説明したが、本発明の自律運用管理システム及び方法は、上記実施形態例の構成にのみ限定されるものではなく、上記実施形態例の構成から種々の修正及び変更を施したものも、本発明の範囲に含まれる。

本発明は、データセンタや企業システムを管理する自律運用管理ミドルウェアといった用途に適用できる。また、そのようなミドルウェアのデバッグツールとして利用することもできる。

本発明の第１の実施形態に係る自律運用管理システムの構成を示すブロック図である。 判断手段の詳細な構成を示すブロック図である。 実行手段の詳細な構成を示すブロック図である。 運用管理ポリシ、監視設定情報、ワークフロー定義の例を示す表である。 ワークフロー定義と制約条件、及び、停止判断ルールの例を示す表である。 判断手段における制御ループを示したフローチャートである。 実行手段における監視情報取得提供処理を示したフローチャートである。 実行手段におけるワークフロー実行処理を示したフローチャートである。 実行手段における自律制御停止判断と停止処理を示したフローチャートである。 停止判断部によって自律制御の停止設定がされた要求処理部の動作を示すフローチャートである。 停止判断部によって自律制御の停止設定がされた情報提供部の動作を示すフローチャートである。 本発明の第２の実施形態に係る自律運用管理システムの構成を示すブロック図である。 発明の第１の実施形態に係る自律運用管理システムの具体例を示すブロック図である。 図１３の運用管理システムにおける運用管理ポリシのルールと停止判断ルールの例を示す表である。 発明の第２の実施形態に係る自律運用管理システムの具体例を示すブロック図である。 図１５の自律運用管理システムにおける運用管理ポリシの例を示す表である。 図１５の自律運用管理システムにおける停止判断ルールの例を示す表である。

符号の説明

１０、２０、３０、５０：計算機（サーバ）
１１、２１、５１：入力装置
１２、２２：処理装置
１３、５３：判断手段
１３１：情報監視部
１３２：制御決定部
１３３：制御要求部
１４、２４、５６：通信装置
１５、２５、５２：表示装置
１６、２６、５５：記憶装置
１６１、５５１：運用管理ポリシ
１６２：監視設定情報
１６３：ワークフロー定義
２３、５４：実行手段
２３１：情報提供部
２３２：情報収集部
２３３：停止判断部
２３４：要求処理部
２３５：要求実行部
２６１、５５２：停止判断ルール
２６２：制約条件
４０：ネットワーク

Claims (28)

1. 制御対象の状態を監視する状態監視部と、該状態監視部による監視情報とポリシ記憶部に記憶された運用管理ポリシとに基づいて制御対象に必要な制御を決定する制御決定部と、該制御決定部の決定に基づいて制御対象を制御する制御実行部とを備える自律運用管理システムにおいて、
   制御対象の自律制御を停止する停止条件を記述した停止判断ルールを記憶するルール記憶装置と、前記監視情報及び停止判断ルールに基づいて停止条件の成立を検知する停止判断手段とを備え、
   前記停止判断手段は、前記停止条件の成立を検知すると、前記制御実行部による制御実行機能、及び、前記状態監視部から前記制御決定部に与える監視情報の少なくとも一方を制限することを特徴とする自律運用管理システム。
2. 前記停止判断手段は、前記停止条件が成立すると、システムの管理者に警報を発生する、請求項１に記載の自律管理システム。
3. ネットワークにより接続された複数の計算機を自律的に運用管理する自律運用管理システムにおいて、
   システム内の管理対象の監視情報を収集する情報収集手段と、
   前記情報収集手段によって収集された監視情報と記憶装置に記憶された運用管理ポリシとに基づいて自律的に制御を決定する制御決定手段と、
   前記制御決定手段からの制御要求に基づいて前記管理対象の制御を実行する制御実行手段と、
   前記制御実行手段による制御の実行状態、及び、前記情報収集手段によって収集された監視情報の少なくとも一方と、記憶装置に記憶された停止条件とに基づいて、自律制御停止の判断をする停止判断手段とを備え、
   前記停止判断手段は、前記自律制御停止の判断をしたときには、前記制御実行手段による制御実行機能、及び、前記制御決定手段に与える監視情報の少なくとも一方を制限することを特徴とする自律運用管理システム。
4. 前記停止条件が、前記運用管理ポリシに記述できない機密保持された情報、及び、システム内の機器に依存する設定情報の制約の少なくとも一方を含む、請求項３に記載の自律運用管理システム。
5. 前記停止条件が、前記運用管理ポリシで想定した制御スクリプトの実行効果と実際の実行効果とが異なる場合を含む、請求項３に記載の自律運用管理システム。
6. 前記停止判断手段は、前記自律制御停止の判断をしたときには、前記情報収集手段から前記制御決定手段に提供される全ての監視情報の提供を停止させる、請求項３に記載の自律運用管理システム。
7. 前記停止判断手段は、前記自律制御停止の判断をしたときには、前記情報収集手段から前記制御決定手段に提供される監視情報の一部の提供を停止させる、請求項３に記載の自律運用管理システム。
8. 前記停止判断手段は、前記自律制御停止の判断をしたときには、前記情報収集手段から前記制御決定手段に提供される監視情報に、制御停止の対象を示す情報を加えて提供させる、請求項３に記載の自律運用管理システム。
9. 前記停止判断手段は、少なくともその一部がワークフローの実行状態に応じて起動される監視タスクによって実現される、請求項３に記載の自律運用管理システム。
10. 前記制御実行手段は、前記監視情報に基づいて制御のワークフローを実行するにあたり、該ワークフローの実行に先だって、該ワークフローのために定義された事前条件、及び、前記運用管理ポリシによって制御が決定された際の判断条件の少なくとも一方が満たされていることを確認する、請求項３に記載の自律運用管理システム。
11. 前記実行手段は、前記監視情報に基づいて制御のワークフローを実行した後に、該ワークフローに定義された事後条件が満たされているか否かを判定する、請求項３に記載の自律運用管理システム。
12. 前記停止判断手段は、前記停止条件が成立すると、システムの管理者に警報を発生する、請求項１に記載の自律管理システム。
13. ネットワークにより接続された複数の計算機から成るシステムを自律的に運用管理する方法において、
    システムの監視装置から得られる監視情報及び記憶装置に記憶された運用管理ポリシに基づいて、制御実行手段が制御のワークフローを実行するステップと、
    前記制御実行手段が、前記制御のワークフローを実行するにあたり、前記監視情報と、記憶装置に記憶された、制御対象の自律制御を停止する停止条件を記述した停止判断ルールとに基づいて、停止条件の成立の有無を検知するステップと、
    前記停止条件の成立を検知すると、前記制御実行手段が実行する制御実行機能、及び、前記監視装置が前記制御実行手段に与える監視情報の少なくとも一方を制限するステップとを備えることを特徴とする自律運用管理方法。
14. 前記停止条件が、前記運用管理ポリシで想定した制御スクリプトの実行効果と実際の実行効果とが異なる場合を含む、請求項１３に記載の自律運用管理方法。
15. 前記停止条件の成立を検知すると、前記監視装置が前記制御実行手段に提供する全ての情報の提供を停止する、請求項１３に記載の自律運用管理方法。
16. 前記停止条件の成立を検知すると、前記監視装置が前記制御決定手段に提供する情報の一部の提供を停止する、請求項１３に記載の自律運用管理方法。
17. 前記停止条件の成立を検知すると、前記監視装置が、前記制御実行手段に提供する情報に、制御停止の対象を示す情報を加えて提供する、請求項１３に記載の自律運用管理方法。
18. 前記停止条件の検知ステップを、ワークフローの実行状態に応じて起動される監視タスクによって実現する、請求項１３に記載の自律運用管理方法。
19. 前記制御実行手段が、前記ワークフローの実行ステップに先だって、前記ワークフローのために定義された事前条件、及び、前記運用管理ポリシによって制御が決定された際の判断条件の少なくとも一方が満たされていることを確認する、請求項１３に記載の自律運用管理方法。
20. 前記制御実行手段は、前記停止条件の成立を検知すると、システムの管理者に警報を発生する、請求項１３に記載の自律管理方法。
21. ネットワークにより接続された複数の計算機を含むシステムを自律的に運用管理する制御コンピュータのためのプログラムであって、前記制御コンピュータに、
    システムの監視装置から得られる監視情報及び記憶装置に記憶された運用管理ポリシに基づいて、制御のワークフローを実行する処理と、
    前記制御のワークフローを実行する処理にあたり、前記監視情報と、記憶装置に記憶された、制御対象の自律制御を停止する停止条件を記述した停止判断ルールとに基づいて、停止条件の成立の有無を検知する処理と、
    前記停止条件の成立を検知すると、前記制御のワークフローの実行機能、及び、前記監視装置から前記制御のワークフローを実行する処理の際に与える監視情報の少なくとも一方を制限する処理とを実行させることを特徴とするプログラム。
22. 前記停止条件が、前記運用管理ポリシで想定した制御スクリプトの実行効果と実際の実行効果とが異なる場合を含む、請求項２１に記載のプログラム。
23. 前記停止条件の成立を検知すると、前記監視装置から前記制御実行手段に提供される全ての監視情報の提供を停止する処理を更に前記制御コンピュータに実行させる、請求項２１に記載のプログラム。
24. 前記停止条件の成立を検知すると、前記監視装置から前記制御決定手段に提供される監視情報の一部の提供を停止する処理を更に前記制御コンピュータに実行させる、請求項２１に記載のプログラム。
25. 前記停止条件の成立を検知すると、前記監視装置から前記制御実行手段に提供される情報に、制御停止の対象を示す情報を加えて提供する処理を更に前記制御コンピュータに実行させる、請求項２１に記載のプログラム。
26. 前記停止条件の検知処理を、ワークフローの実行状態に応じて起動される監視タスクプログラムによって実現する、請求項２１に記載のプログラム。
27. 前記制御のワークフローを実行する処理に先だって、該ワークフローのために定義された事前条件、及び、前記運用管理ポリシによって制御が決定された際の判断条件の少なくとも一方が満たされていることを確認する処理を更に前記制御コンピュータに実行させる、請求項２１に記載のプログラム。
28. 前記停止条件の成立を検知すると、システムの管理者に警報を発生する処理を更に前記制御コンピュータに実行させる、請求項２１に記載のプログラム。

Images