(57)【特許請求の範囲】
【請求項１】
ワークフローに含まれる複数の運用操作の並列実行可能性を判定する運用操作管理プログラムであって、コンピュータに、
前記ワークフローの実行開始後であって前記複数の運用操作のうちの第１の運用操作の実行開始の前に、前記第１の運用操作、および、前記第１の運用操作に後続する第２の運用操作について、前記複数の運用操作それぞれを、マシンまたは前記マシンにおけるリソースを示す動作対象、および、前記動作対象の状態変化を伴う第１の動作または前記動作対象の状態変化を伴わない第２の動作を示す動作内容に基づき区分した動作区分情報に基づき、前記第１の運用操作に対応する第１の区分および前記第２の運用操作に対応する第２の区分を特定し、
２つの区分の組に対応する２つの運用操作について、先行の運用操作および後続の運用操作の動作対象の一致または相違に応じた前記２つの運用操作の並列実行可能性の詳細判断対象の該否の判断基準の情報を示す判断基準情報を参照して、前記第１の区分および前記第２の区分の組に応じた前記判断基準を特定し、特定した前記判断基準で示される前記マシンの情報であって、前記第１の運用操作および前記第２の運用操作それぞれの前記動作対象に対応する前記マシンの情報の一致または相違を確認することで、前記詳細判断対象の該否を判別し、
前記詳細判断対象である場合は、前記第１の運用操作および前記第２の運用操作の、前記動作対象に関する関係、および、前記第１および前記第２の運用操作が関連する動作対象の動作状況に基づき、並列実行可能性を判断する、
処理を実行させる運用操作管理プログラム。
【請求項２】
前記動作対象に関する関係は、前記動作対象であるマシンと前記マシン上のリソースとの階層関係を含む、請求項１記載の運用操作管理プログラム。
【請求項３】
前記判断では、前記第１および前記第２の運用操作が関連する前記マシンおよび前記リソースそれぞれの動作状況を確認し、当該動作状況の組み合わせに基づいて、前記並列実行可能性を判断する、請求項２記載の運用操作管理プログラム。
【請求項４】
ワークフローに含まれる複数の運用操作の並列実行可能性を判定する運用操作管理装置であって、
前記複数の運用操作それぞれを、マシンまたは前記マシンにおけるリソースを示す動作対象、および、前記動作対象の状態変化を伴う第１の動作または前記動作対象の状態変化を伴わない第２の動作を示す動作内容に基づき区分した動作区分情報と、２つの区分の組に対応する２つの運用操作について、先行の運用操作および後続の運用操作の動作対象の一致または相違に応じた前記２つの運用操作の並列実行可能性の詳細判断対象の該否の判断基準の情報を示す判断基準情報とを記憶する記憶部と、
前記ワークフローの実行開始後であって前記複数の運用操作のうちの第１の運用操作の実行開始の前に、前記第１の運用操作、および、前記第１の運用操作に後続する第２の運用操作について、前記動作区分情報に基づき、前記第１の運用操作に対応する第１の区分および前記第２の運用操作に対応する第２の区分を特定し、前記判断基準情報を参照して、前記第１の区分および前記第２の区分の組に応じた前記判断基準を特定し、特定した前記判断基準で示される前記マシンの情報であって、前記第１の運用操作および前記第２の運用操作それぞれの前記動作対象に対応する前記マシンの情報の一致または相違を確認することで、前記詳細判断対象の該否を判別し、前記詳細判断対象である場合は、前記第１の運用操作および前記第２の運用操作の、前記動作対象に関する関係、および、前記第１および前記第２の運用操作が関連する動作対象の動作状況に基づき、並列実行可能性を判断する演算部と、
を有する運用操作管理装置。
【請求項５】
ワークフローに含まれる複数の運用操作の並列実行可能性を判定する運用操作管理方法であって、コンピュータが、
前記ワークフローの実行開始後であって前記複数の運用操作のうちの第１の運用操作の実行開始の前に、前記第１の運用操作、および、前記第１の運用操作に後続する第２の運用操作について、前記複数の運用操作それぞれを、マシンまたは前記マシンにおけるリソースを示す動作対象、および、前記動作対象の状態変化を伴う第１の動作または前記動作対象の状態変化を伴わない第２の動作を示す動作内容に基づき区分した動作区分情報に基づき、前記第１の運用操作に対応する第１の区分および前記第２の運用操作に対応する第２の区分を特定し、
２つの区分の組に対応する２つの運用操作について、先行の運用操作および後続の運用操作の動作対象の一致または相違に応じた前記２つの運用操作の並列実行可能性の詳細判断対象の該否の判断基準の情報を示す判断基準情報を参照して、前記第１の区分および前記第２の区分の組に応じた前記判断基準を特定し、特定した前記判断基準で示される前記マシンの情報であって、前記第１の運用操作および前記第２の運用操作それぞれの前記動作対象に対応する前記マシンの情報の一致または相違を確認することで、前記詳細判断対象の該否を判別し、
前記詳細判断対象である場合は、前記第１の運用操作および前記第２の運用操作の、前記動作対象に関する関係、および、前記第１および前記第２の運用操作が関連する動作対象の動作状況に基づき、並列実行可能性を判断する、
運用操作管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は運用操作管理プログラム、運用操作管理装置および運用操作管理方法に関する。
【背景技術】
【０００２】
情報処理システムでは、運用管理対象（例えば、コンピュータやソフトウェアなど）の数の大規模化や運用管理作業の複雑化が進んでいる。システムにおける運用作業を効率化するために、運用管理対象のコンピュータやソフトウェアなどへの運用操作（例えば、起動、起動確認および設定情報の作成など）を支援するソフトウェアが利用されている。当該ソフトウェアを実行するコンピュータは、ユーザの指示に応じてワークフローを作成する。ワークフローは、複数の運用操作および複数の運用操作それぞれを実行する順序の情報を含む。ワークフローにより、運用操作を自動化することで運用作業を効率化できる。
【０００３】
ところで、ある一連の処理の短縮化を図るために、一部の処理を並列化することがある。例えば、並列制御による処理が逐次制御による処理より短い時間で終了するか否かを判定する方法の提案がある。また、連続する２つの画像処理列それぞれについて、処理すべき画像データの位置に依存する画像処理であるか、画像データの位置に独立な画像処理であるかを判断することによって、並列処理可能性を判断する印刷処理装置の提案もある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１２−１２３６８８号公報
【特許文献２】特開平１０−３３７９３２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ワークフローを早期に実行完了させるために、ワークフローに含まれる複数の運用操作を、運用管理対象の複数の装置で並列実行させることが考えられる。
運用操作部品それぞれが並列実行可能であるかを適正に判断するために、全ての運用操作について前後の処理との優先度（順序）と、全ての対象の状態（操作対象の状態や操作対象と階層関係にある他の対象の状態）を組み合わせた判断を行うことが考えられる。しかし、全対象の状態の組み合わせは膨大であり、演算量が膨大となるため、全組み合わせに対して処理を行うと並列実行可能性の判断に時間を要し、ワークフロー実行中の判断方法としては現実的でないという問題がある。
【０００６】
一方、運用操作部品の並列実行可能性の判断を簡便に行うために、例えば各運用操作部品の操作内容と操作対象とに基づき、ワークフローの実行前に運用操作部品をモデル化しておき、モデル化した情報のみによりワークフロー実行中の判断を行うことも考えられる。しかし、操作対象の関係性、および、ワークフロー実行中に動的に変化する操作対象の状態を考慮しないと、並列実行可能か否かを適正に判断するのが難しい。例えば、並列実行可能か否かを明確に判断できずに効率が上がらない、あるいは、並列実行可能と誤判断し、ワークフローが正しく動作しない、という問題が生じる。
【０００７】
１つの側面では、本発明は、運用実行中の並列実行可能性の判断を可能とする運用操作管理プログラム、運用操作管理装置および運用操作管理方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
１つの態様では、ワークフローに含まれる複数の運用操作の並列実行可能性を判定する運用操作管理プログラムが提供される。この運用操作管理プログラムは、コンピュータに、ワークフローの実行開始後であって複数の運用操作のうちの第１の運用操作の実行開始の前に第１の運用操作、および、第１の運用操作に後続する第２の運用操作について、複数の運用操作それぞれを、マシンまたはマシンにおけるリソースを示す動作対象、および、動作対象の状態変化を伴う第１の動作または動作対象の状態変化を伴わない第２の動作を示す動作内容に基づき区分した動作区分情報に基づき、第１の運用操作に対応する第１の区分および第２の運用操作に対応する第２の区分を特定し、２つの区分の組に対応する２つの運用操作について、先行の運用操作および後続の運用操作の動作対象の一致または相違に応じた２つの運用操作の並列実行可能性の詳細判断対象の該否の判断基準の情報を示す判断基準情報を参照して、第１の区分および第２の区分の組に応じた判断基準を特定し、特定した判断基準で示されるマシンの情報であって、第１の運用操作および第２の運用操作それぞれの動作対象に対応するマシンの情報の一致または相違を確認することで、詳細判断対象の該否を判別し、詳細判断対象である場合は、第１の運用操作および第２の運用操作の、動作対象に関する関係、および、第１および第２の運用操作が関連する動作対象の動作状況に基づき、並列実行可能性を判断する、処理を実行させる。
【０００９】
また、１つの態様では、ワークフローに含まれる複数の運用操作の並列実行可能性を判定する運用操作管理装置が提供される。この運用操作管理装置は、記憶部と演算部とを有する。記憶部は、複数の運用操作それぞれを、マシンまたはマシンにおけるリソースを示す動作対象、および、動作対象の状態変化を伴う第１の動作または動作対象の状態変化を伴わない第２の動作を示す動作内容に基づき区分した動作区分情報と、２つの区分の組に対応する２つの運用操作について、先行の運用操作および後続の運用操作の動作対象の一致または相違に応じた２つの運用操作の並列実行可能性の詳細判断対象の該否の判断基準の情報を示す判断基準情報とを記憶する。演算部は、ワークフローの実行開始後であって複数の運用操作のうちの第１の運用操作の実行開始の前に、第１の運用操作、および、第１の運用操作に後続する第２の運用操作について、動作区分情報に基づき、第１の運用操作に対応する第１の区分および第２の運用操作に対応する第２の区分を特定し、判断基準情報を参照して、第１の区分および第２の区分の組に応じた判断基準を特定し、特定した判断基準で示されるマシンの情報であって、第１の運用操作および第２の運用操作それぞれの動作対象に対応するマシンの情報の一致または相違を確認することで、詳細判断対象の該否を判別し、詳細判断対象である場合は、第１の運用操作および第２の運用操作の、動作対象に関する関係、および、第１および第２の運用操作が関連する動作対象の動作状況に基づき、並列実行可能性を判断する。
【００１０】
また、１つの態様では、ワークフローに含まれる複数の運用操作の並列実行可能性を判定する運用操作管理方法が提供される。この運用操作管理方法では、コンピュータが、ワークフローの実行開始後であって複数の運用操作のうちの第１の運用操作の実行開始の前に、第１の運用操作、および、第１の運用操作に後続する第２の運用操作について、複数の運用操作それぞれを、マシンまたはマシンにおけるリソースを示す動作対象、および、動作対象の状態変化を伴う第１の動作または動作対象の状態変化を伴わない第２の動作を示す動作内容に基づき区分した動作区分情報に基づき、第１の運用操作に対応する第１の区分および第２の運用操作に対応する第２の区分を特定し、２つの区分の組に対応する２つの運用操作について、先行の運用操作および後続の運用操作の動作対象の一致または相違に応じた２つの運用操作の並列実行可能性の詳細判断対象の該否の判断基準の情報を示す判断基準情報を参照して、第１の区分および第２の区分の組に応じた判断基準を特定し、特定した判断基準で示されるマシンの情報であって、第１の運用操作および第２の運用操作それぞれの動作対象に対応するマシンの情報の一致または相違を確認することで、詳細判断対象の該否を判別し、詳細判断対象である場合は、第１の運用操作および第２の運用操作の、動作対象に関する関係、および、第１および第２の運用操作が関連する動作対象の動作状況に基づき、並列実行可能性を判断する。
【発明の効果】
【００１１】
１つの側面では、運用実行中の並列実行可能性の判断を可能とする。
【図面の簡単な説明】
【００１２】
【図１】第１の実施の形態の運用操作管理装置を示す図である。
【図２】第２の実施の形態の情報処理システムの例を示す図である。
【図３】運用サーバのハードウェア例を示す図である。
【図４】運用サーバの機能例を示す図である。
【図５】ワークフローの例を示す図である。
【図６】動作モデルの雛型の例を示す図である。
【図７】並列実行可能性の判断手順の例を示す図である。
【図８】第１の判断基準の例を示す図である。
【図９】第２の判断基準の例を示す図である。
【図１０】第３の判断基準の例を示す図である。
【図１１】テーブルの例を示す図である。
【図１２】ワークフロー管理テーブルの例を示す図である。
【図１３】運用操作部品定義テーブルの例を示す図である。
【図１４】変数管理テーブルの例を示す図である。
【図１５】インスタンス管理テーブルの例を示す図である。
【図１６】動作モデル定義テーブルの例を示す図である。
【図１７】動作モデル状態管理テーブルの例を示す図である。
【図１８】リソース種別の属性定義と状態の種類の例を示す図である。
【図１９】状態遷移定義テーブルの例を示す図である。
【図２０】並列実行判断基準定義テーブルの例を示す図である。
【図２１】サブ基準定義テーブルの例を示す図である。
【図２２】サーバ状態管理テーブルの例を示す図である。
【図２３】リソース状態管理テーブルの例を示す図である。
【図２４】ワークフローの実行例を示すフローチャートである。
【図２５】動作モデル選定例を示すフローチャートである。
【図２６】動作モデル選定の具体例を示す図である。
【図２７】動作モデルの中間形生成例を示すフローチャートである。
【図２８】動作モデルの中間形生成（詳細）例を示すフローチャートである。
【図２９】動作モデルの中間形生成の具体例を示す図である。
【図３０】中間形生成後の動作モデル状態管理テーブルの例を示す図である。
【図３１】サーバおよびリソースの状態更新例を示すフローチャートである。
【図３２】動作モデル更新例を示すフローチャートである。
【図３３】並列実行可能性の算出例を示すフローチャートである。
【図３４】直列実行または並列実行の例を示すフローチャートである。
【図３５】並列実行可能性の判断の第１の例を示す図である。
【図３６】並列実行可能性の判断の第１の例（続き）を示す図である。
【図３７】並列実行可能性の判断の第２の例を示す図である。
【図３８】並列実行可能性の判断の第２の例（続き）を示す図である。
【図３９】並列実行可能性の判断の第３の例を示す図である。
【図４０】並列実行可能性の判断の第３の例（続き）を示す図である。
【図４１】並列実行可能性の判断の第４の例を示す図である。
【図４２】並列実行可能性の判断の第４の例（続き）を示す図である。
【図４３】並列実行可能性の判断の第５の例を示す図である。
【図４４】並列実行可能性の判断の第５の例（続き）を示す図である。
【図４５】並列化の例を示す図である。
【図４６】並列化の比較例を示す図である。
【図４７】並列化の比較例（続き）を示す図である。
【発明を実施するための形態】
【００１３】
以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の運用操作管理装置を示す図である。運用操作管理装置１は、ネットワーク２を介して情報処理装置３，４と接続されている。運用操作管理装置１は、情報処理装置３，４の運用管理を行う。運用操作管理装置１による運用管理対象は、情報処理装置３，４のような物理的なコンピュータ（物理マシンと呼ばれることがある）でもよいし、物理マシン上で動作する仮想的なコンピュータ（仮想マシンと呼ばれることがある）でもよい。運用操作管理装置１による運用管理対象は、物理マシンまたは仮想マシンにより実行されるオペレーティングシステム（ＯＳ：Operating System）やアプリケーションなどのソフトウェアも含む。
【００１４】
運用操作管理装置１は、各運用管理対象に対する運用操作の実行を管理する。運用操作は、例えば物理マシンや仮想マシンの起動／停止、ソフトウェアの動作パラメータ設定、ソフトウェアのサービス起動／停止、バックアップ取得および電子メール送信などのシステム運用における様々な操作である。
【００１５】
情報処理システムでは、複数の運用操作を組み合わせた一連の操作（例えば、装置の起動、サービスの起動、アカウントの作成など）を運用管理対象により実行させることもある。運用操作管理装置１では、一連の運用操作をワークフローにより管理する。ワークフローは、複数の運用操作の集合であり、複数の運用操作の情報を含む。ワークフローに含まれる複数の運用操作それぞれを、運用操作部品と称することがある。また、ワークフローは、複数の運用操作それぞれを実行する順番の情報を含む。ワークフローの情報は、システムの管理者により、記憶部１ａに予め格納される。
【００１６】
運用操作管理装置１は、記憶部１ａおよび演算部１ｂを含む。記憶部１ａは、ＲＡＭ（Random Access Memory）などの揮発性記憶装置でもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性記憶装置でもよい。演算部１ｂは、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）などを含み得る。演算部１ｂはプログラムを実行するプロセッサであってもよい。ここでいう「プロセッサ」には、複数のプロセッサの集合（マルチプロセッサ）も含まれ得る。
【００１７】
記憶部１ａは、ワークフロー５の情報を記憶する。ワークフロー５は、運用操作Ｐ１，Ｐ２，Ｐ３，Ｐ４の情報を含む。ワークフロー５は、運用操作Ｐ１，Ｐ２，Ｐ３，Ｐ４の実行順を、運用操作Ｐ１，Ｐ２，Ｐ３，Ｐ４の順とする情報を含む。すなわち、ワークフロー５によれば、運用操作Ｐ１，Ｐ２，Ｐ３，Ｐ４を直列（逐次）実行できる。
【００１８】
運用操作Ｐ１，Ｐ２，Ｐ３，Ｐ４それぞれは、共通の装置（例えば、情報処理装置３）に対する運用操作でもよいし、異なる装置に対する運用操作（例えば、運用操作Ｐ１が情報処理装置３、運用操作Ｐ２が情報処理装置４に対する運用操作）でもよい。
【００１９】
記憶部１ａは、複数の運用操作それぞれを、動作対象、および、動作内容に基づき区分した動作区分情報を記憶する。動作対象は、例えば、物理マシンや仮想マシンなどのソフトウェアの実行主体（マシンと称する）である。また、動作対象は、例えば、ソフトウェアのサービスやサービスの実行に用いられる設定情報など（リソースと称する）でもよい。リソースはマシン上に実現されるので、マシンとリソースとは階層関係にあるといえる。動作内容は、例えば、動作対象に対する状態変化の有無に応じて定められる。例えば、動作対象を状態変化させる運用操作の動作内容を“操作”とし、動作対象を状態変化させない運用操作の動作内容を“参照”とする。
【００２０】
２パターンの動作対象（マシンおよびリソース）と、２パターンの動作内容（操作および参照）とで運用操作を区分する場合、運用操作は２×２＝４種類の動作区分（モデル）に区分される。より具体的には、第１の動作区分の運用操作は、マシンに対する操作（例えば、起動や停止など）を行う運用操作である。第２の動作区分の運用操作は、マシンに対する参照（例えば、起動や停止の確認など）を行う運用操作である。第３の動作区分の運用操作は、リソースに対する操作（例えば、サービス起動／停止やサービスの設定ファイルの作成など）を行う運用操作である。第４の動作区分の運用操作は、リソースに対する参照（例えば、サービス起動／停止や設定ファイル存在の確認など）を行う運用操作である。例えば、動作区分情報は、運用操作Ｐ１の動作区分、運用操作Ｐ２の動作区分、運用操作Ｐ３の動作区分および運用操作Ｐ４の動作区分の情報を含む。
【００２１】
演算部１ｂは、ワークフロー５の実行の際に、次に実行する第１の運用操作、および、第１の運用操作に後続する第２の運用操作について、動作区分情報に基づき、詳細判断対象の該否（詳細判断対象に該当するか否か）を判別する。ここで、詳細判断とは、後述するように、運用操作において動作対象の関係および状態（動作状況）を考慮して並列実行可能性の判断を行うことを示す。
【００２２】
例えば、演算部１ｂは、運用操作Ｐ１の実行前の段階において、次に実行する運用操作Ｐ１、および、運用操作Ｐ１に後続する運用操作Ｐ２について、動作区分情報に基づき、並列実行可能性の詳細判断対象に該当するか否かを判別する。より具体的には次の通りである。
【００２３】
運用操作Ｐ１，Ｐ２は、例えば共通のマシンに対する運用操作である。運用操作Ｐ１は、第１の動作区分の運用操作（マシンに対する操作を行う運用操作）である。運用操作Ｐ２は、第２の動作区分の運用操作（マシンに対する参照を行う運用操作）である。この場合、演算部１ｂは、運用操作Ｐ１，Ｐ２が並列実行可能性の詳細判断対象に該当しないと判定する。あるマシンに対する操作（運用操作Ｐ１）を行い、その後、同マシンに対する参照（運用操作Ｐ２）を行う場合、後者（運用操作Ｐ２）は前者（運用操作Ｐ１）の結果に対する運用操作である可能性が高く、詳細判断を行うまでもなく並列実行不可能と判断できるからである。
【００２４】
すると、演算部１ｂは、ワークフロー５において運用操作Ｐ１，Ｐ２を並列化せずに、運用操作Ｐ１を実行する。例えば、演算部１ｂは、該当のマシンに運用操作Ｐ１の実行を指示する。演算部１ｂは、運用操作Ｐ１の実行を完了した旨の通知を該当のマシンから受け付ける。すると、演算部１ｂは、運用操作Ｐ１を実行済とする。ワークフロー５ａは、運用操作Ｐ１，Ｐ２，Ｐ３，Ｐ４のうち、運用操作Ｐ１が実行済であり、運用操作Ｐ２，Ｐ３，Ｐ４が未実行である状態（運用操作Ｐ２を実行する直前の状態）を示す。
【００２５】
例えば、演算部１ｂは、運用操作Ｐ１の実行後で、運用操作Ｐ２の実行前の段階において、次に実行する運用操作Ｐ２、および、運用操作Ｐ２に後続する運用操作Ｐ３について、動作区分情報に基づき、並列実行可能性の詳細判断対象に該当するか否かを判別する。より具体的には次の通りである。
【００２６】
運用操作Ｐ２，Ｐ３は、共通するマシンに対する運用操作である。運用操作Ｐ２は、前述のように第２の動作区分の運用操作（マシンに対する参照を行う運用操作）である。運用操作Ｐ３は、第３の動作区分の運用操作（リソースに対する操作を行う運用操作）である。この場合、演算部１ｂは、運用操作Ｐ２，Ｐ３が並列実行可能性の詳細判断対象に該当すると判定する。あるマシンに対する参照（運用操作Ｐ２）を行い、その後、同マシン上のリソースに対する操作（運用操作Ｐ３）を行う場合、前者（運用操作Ｐ２）はマシンの変更を伴わず、後者（運用操作Ｐ３）は前者（運用操作Ｐ２）の結果とは関係なく実行開始できる可能性があるからである。
【００２７】
演算部１ｂは、第１の運用操作と第２の運用操作とが並列実行可能性の詳細判断対象である場合は、第１および第２の運用操作の、動作対象に関する関係、および、第１および第２の運用操作が関連する動作対象の動作状況に基づき、並列実行可能性を判断する。
【００２８】
例えば、演算部１ｂは、運用操作Ｐ２，Ｐ３の並列実行可能性の詳細判断を次のように行える。運用操作Ｐ２の動作対象はマシンである。運用操作Ｐ３の動作対象は当該マシン上のリソースである。マシンとリソースとは、上記のように階層関係にある。マシンが動作していなければ、リソースを利用することはできない。マシンはリソースよりも下位の階層であり、リソースはマシンよりも上位の階層であるということもできる。したがって、リソースに対する操作の可否は、マシンの動作状況による。
【００２９】
そこで、演算部１ｂは、運用操作Ｐ２の動作対象のマシン（運用操作Ｐ３の動作対象のリソースを提供するマシン）の動作状況を確認する。例えば、演算部１ｂは、同マシンが動作していれば（すなわち、動作状況が不定でなければ）運用操作Ｐ３を実行可能と判断する。
【００３０】
演算部１ｂは、運用操作Ｐ２，Ｐ３を並列実行可能と判断すると、ワークフロー５ａにおいて運用操作Ｐ２，Ｐ３を並列化して、運用操作Ｐ２，Ｐ３を実行する。ワークフロー５ｂは、運用操作Ｐ１，Ｐ２，Ｐ３，Ｐ４のうち、運用操作Ｐ２，Ｐ３を並列化した状態を示す。例えば、演算部１ｂは、該当のマシンに運用操作Ｐ２，Ｐ３の実行を指示する。演算部１ｂは、運用操作Ｐ２，Ｐ３の実行を完了した旨の通知を該当のマシンから受け付ける。すると、運用操作Ｐ２，Ｐ３を実行済とする。次の実行対象は運用操作Ｐ４になる。このようにして、運用操作管理装置１は、並列実行可能性の詳細判断対象とする運用操作を絞り込むことで、ワークフロー５の実行中での運用操作Ｐ２，Ｐ３の並列実行可能性の判断を可能とする。
【００３１】
上記の例では、運用操作Ｐ２の動作区分がマシンに対する参照を行う運用操作であり、運用操作Ｐ３の動作区分がリソースに対する操作を行う運用操作である場合に詳細判断対象と判断するものとしたが、他の場合も考えられる。例えば、運用操作Ｐ２の動作区分がリソースに対する操作（または参照）を行う運用操作であり、運用操作Ｐ３の動作区分がリソースに対する参照（または操作）を行う運用操作である場合に、対象のリソースの同一性に応じて詳細判断対象の該否を判別し得る。この場合、演算部１ｂは、対象のリソースを実現するマシンおよび当該リソースの状態を確認して、並列実行可能性の詳細判断を行う。
【００３２】
ところで、ワークフロー５の実行中に、全ての運用操作について、運用操作の優先度（順序）と、全ての対象の状態（動作対象の状態や動作対象と階層関係にある他の対象の状態）とを組み合わせた並列実行可能性の判断を行うことも考えられる。ところが、対象の状態の組み合わせは膨大であり、全ての運用操作に対し全組み合わせについての処理を行うと、並列実行可能性の判断に時間を要し、現実的ではない。すなわち、ワークフロー５の実行中に膨大な組み合わせに対する判断処理を行うことになり、ワークフロー５の完了までの時間が増大するおそれがある。
【００３３】
他方、ワークフローの実行前に、運用操作部品の並列実行可能性の判断を行っておき、並列実行可能なパターンを予め作成しておくことも考えられる。しかし、実際のワークフロー実行中における動作対象の状態などを考慮できないため、並列実行可能かどうかを明確に判断することが容易でなく、並列実行可能性の判断結果の精度が低い。例えば、動作対象の状態を考慮せずに複数の運用操作を並列化してしまうと、何れかの運用操作でエラーが生じる可能性が高まる。
【００３４】
そこで、運用操作管理装置１は、事前に設定した静的な情報で判断可能な部分（マシンやリソースなどの動作区分）と、動的に確認しなければ判断できない部分（リソースやマシン状態）とを組み合わせて並列実行可能性の判断を段階的に行う。運用操作管理装置１によれば、事前に全ての運用操作部品の組に対して並列実行可能性を決めておかなくてもよく、また、ワークフロー実行中に全ての運用操作部品の組について、並列実行可能性を検証しなくてもよい。事前に運用操作部品をある程度区分しておけば、並列実行可能性の詳細判断対象とする運用操作部品の組を、両運用操作部品の動作区分の関係によって絞り込める。これにより、全ての対象の状態の組み合わせについて並列実行可能性の判断を行うよりも、並列実行可能性の判断に伴う処理コストを軽減できる。その結果、ワークフロー５の実行中における各運用操作の並列実行可能性の判断を効率的に行える。
【００３５】
［第２の実施の形態］
図２は、第２の実施の形態の情報処理システムの例を示す図である。第２の実施の形態の情報処理システムは、運用サーバ１００および業務サーバ２００，２００ａ，２００ｂを含む。運用サーバ１００および業務サーバ２００，２００ａ，２００ｂは、ネットワーク１０に接続されている。ネットワーク１０は、例えば、ＬＡＮ（Local Area Network）である。ネットワーク１０は、インターネットやＷＡＮ（Wide Area Network）に接続されてもよい。
【００３６】
運用サーバ１００は、業務サーバ２００，２００ａ，２００ｂの運用管理を行うサーバコンピュータである。運用サーバ１００は、業務サーバ２００，２００ａ，２００ｂに対する運用操作の実行を管理する。
【００３７】
業務サーバ２００，２００ａ，２００ｂは、ユーザの業務処理を実行するサーバコンピュータである。例えば、業務サーバ２００，２００ａ，２００ｂは、ユーザの業務処理を支援するアプリケーションを実行する。ユーザは、ネットワーク１０に接続されたクライアントコンピュータ（図示を省略している）を操作して、業務サーバ２００，２００ａ，２００ｂが提供するサービスを利用できる。
【００３８】
業務サーバ２００，２００ａ，２００ｂは、仮想マシンを実行するサーバコンピュータでもよい。その場合、例えば業務サーバ２００，２００ａ，２００ｂは、ハイパーバイザと呼ばれるソフトウェアを実行する。ハイパーバイザは、物理的なコンピュータである業務サーバ２００，２００ａ，２００ｂが備えるＣＰＵの処理能力やＲＡＭの記憶領域を、演算のリソースとして、業務サーバ２００，２００ａ，２００ｂで動作する仮想マシンに割り振る。業務サーバ２００，２００ａ，２００ｂ上のアプリケーションは、仮想マシンによって実行されるものでもよい。
【００３９】
業務サーバ２００，２００ａ，２００ｂは、運用サーバ１００から指示された処理を実行する。業務サーバ２００，２００ａ，２００ｂは、運用サーバ１００からの指示を受け付けたり、処理の実行を制御したり、実行結果を運用サーバ１００に通知したりするエージェント機能を有する。
【００４０】
図３は、運用サーバのハードウェア例を示す図である。運用サーバ１００は、プロセッサ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力信号処理部１０５、媒体リーダ１０６および通信インタフェース１０７を有する。各ユニットは運用サーバ１００のバスに接続されている。業務サーバ２００，２００ａ，２００ｂも運用サーバ１００と同様のユニットを用いて実現できる。
【００４１】
プロセッサ１０１は、運用サーバ１００の情報処理を制御する。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ、ＤＳＰ、ＡＳＩＣまたはＦＰＧＡなどである。プロセッサ１０１は、ＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどのうちの２以上の要素の組み合わせであってもよい。
【００４２】
ＲＡＭ１０２は、運用サーバ１００の主記憶装置である。ＲＡＭ１０２は、プロセッサ１０１に実行させるＯＳのプログラムやアプリケーションプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０２は、プロセッサ１０１による処理に用いる各種データを記憶する。
【００４３】
ＨＤＤ１０３は、運用サーバ１００の補助記憶装置である。ＨＤＤ１０３は、内蔵した磁気ディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、ＯＳのプログラム、アプリケーションプログラム、および各種データを記憶する。運用サーバ１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の補助記憶装置を備えてもよく、複数の補助記憶装置を備えてもよい。
【００４４】
画像信号処理部１０４は、プロセッサ１０１からの命令に従って、運用サーバ１００に接続されたディスプレイ１１に画像を出力する。ディスプレイ１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイや液晶ディスプレイなどを用いることができる。
【００４５】
入力信号処理部１０５は、運用サーバ１００に接続された入力デバイス１２から入力信号を取得し、プロセッサ１０１に出力する。入力デバイス１２としては、例えば、マウスやタッチパネルなどのポインティングデバイス、キーボードなどを用いることができる。
【００４６】
媒体リーダ１０６は、記録媒体１３に記録されたプログラムやデータを読み取る装置である。記録媒体１３として、例えば、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤなどの磁気ディスク、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）を使用できる。また、記録媒体１３として、例えば、フラッシュメモリカードなどの不揮発性の半導体メモリを使用することもできる。媒体リーダ１０６は、例えば、プロセッサ１０１からの命令に従って、記録媒体１３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。
【００４７】
通信インタフェース１０７は、ネットワーク１０を介して業務サーバ２００，２００ａ，２００ｂを含む他の装置と通信を行う。通信インタフェース１０７は、有線通信インタフェースでもよいし、無線通信インタフェースでもよい。
【００４８】
図４は、運用サーバの機能例を示す図である。運用サーバ１００は、記憶部１１０、制御部１３０および実行部１４０を有する。記憶部１１０は、ＲＡＭ１０２やＨＤＤ１０３に確保された記憶領域として実現される。制御部１３０および実行部１４０は、ＲＡＭ１０２に記憶されたプログラムをプロセッサ１０１が実行することで実現される。
【００４９】
記憶部１１０は、制御部１３０および実行部１４０の処理に用いられる各種の情報を記憶する。記憶部１１０に記憶される情報は、ワークフローの定義情報、ワークフローの実行を管理するための情報、ワークフローに含まれる運用操作部品の並列実行可能性の判断に用いられる情報を含む。また、記憶部１１０は、運用操作部品における処理を実行するためのコマンドの情報や業務サーバ２００，２００ａ，２００ｂを指定してコマンドを送信するための情報なども予め記憶する。
【００５０】
制御部１３０は、実行部１４０によるワークフローの実行を制御する。制御部１３０は、ワークフローの実行指示をユーザの操作入力により受け付けたことを契機に、実行部１４０によるワークフローの実行を開始させてもよい。制御部１３０は、スケジュールされたタイミングで実行部１４０によるワークフローの実行を開始させてもよい。
【００５１】
制御部１３０は、記憶部１１０に記憶された情報に基づいて、ワークフローの実行中に、次に実行する第１の運用操作と第１の運用操作に後続する第２の運用操作との並列実行可能性を判断する。制御部１３０は、第１および第２の運用操作を並列実行可能と判断した場合、第１および第２の運用操作を並列実行するように実行部１４０に指示する。制御部１３０は、第１および第２の運用操作を並列実行不可能と判断した場合、第１の運用操作を実行するように実行部１４０に指示する。
【００５２】
実行部１４０は、制御部１３０の指示に応じて、ワークフローを実行する。ワークフローの実行は、ワークフローに含まれる運用操作を、対象のマシンに実行させることを含む。実行部１４０は、第１および第２の運用操作を並列実行するよう制御部１３０から指示された場合、第１および第２の運用操作を対象のマシン（同一のこともあるし、異なることもある）に並列実行させる。
【００５３】
図５は、ワークフローの例を示す図である。ワークフロー２０の最初の運用操作部品“Ｓｔａｒｔ”は、ワークフローの開始を示す（例えば、ワークフロー２０の実行前の運用サーバ１００における開始処理を示す）。ワークフロー２０の最後の運用操作部品“Ｅｎｄ”は、ワークフローの終了を示す（例えば、ワークフロー２０の実行後の運用サーバ１００における終了処理を示す）。
【００５４】
ワークフロー２０は、“Ｓｔａｒｔ”および“Ｅｎｄ”の運用操作部品の間に、運用操作部品２１，２２，２３，２４，２５，２６，２７を含む。ワークフロー２０は、運用操作部品２１，２２，２３，２４，２５，２６，２７をこの順番で直列に行うためのワークフローである。
【００５５】
運用操作部品２１は、ＯＳ再起動である。運用操作部品２１では、操作対象（動作対象ということもできる）のサーバ名として“Ｘ”が指定されている。運用操作部品２２は、サーバの起動確認である。運用操作部品２２では、操作対象のサーバ名として“Ｘ”が指定されている。
【００５６】
運用操作部品２３は、サービスの起動確認である。運用操作部品２３では、操作対象のサーバ名として“Ｘ”が指定されている。運用操作部品２３では、操作対象のサービス名として“Ｓ”が指定されている。
【００５７】
運用操作部品２４は、アカウントの作成である。運用操作部品２４では、操作対象のサーバ名として“Ｘ”が指定されている。運用操作部品２４では、操作対象のアカウント名として“Ａｃ”が指定されている。
【００５８】
運用操作部品２５は、アカウントの情報取得である。運用操作部品２５では、操作対象のサーバ名として“Ｘ”が指定されている。運用操作部品２５では、操作対象のアカウント名として“Ａｃ”が指定されている。
【００５９】
運用操作部品２６は、アカウントのホームディレクトリ確認である。運用操作部品２６では、操作対象のサーバ名として“Ｘ”が指定されている。運用操作部品２６では、操作対象のアカウント名として“Ａｃ”が指定されている。
【００６０】
運用操作部品２７は、ユーザによるログインである。運用操作部品２７では、操作対象のサーバ名として“Ｘ”が指定されている。運用操作部品２７では、操作対象のアカウント名として“Ａｃ”が指定されている。
【００６１】
ここで、各運用操作部品は、複数の動作モデルの何れかに区分される。
図６は、動作モデルの雛型の例を示す図である。運用操作部品の情報には、操作対象および操作内容（動作内容ということもできる）が含まれる。運用サーバ１００は、操作対象および操作内容それぞれを次のように区分する。
【００６２】
運用サーバ１００は、運用操作部品の操作対象を、「サーバ」および「リソース」に区分する。「サーバ」は、業務サーバ２００などの物理的なコンピュータ（物理マシン）でもよいし、業務サーバ２００上で動作する仮想的なコンピュータ（仮想マシン）でもよい。「リソース」は、ソフトウェアの実行に用いられる情報やソフトウェアの実行に伴って生成されるプロセスなど、様々な種別（リソース種別）に分類される。操作対象は、サーバ名およびリソース名によって識別される。リソース名は、サービス名、アカウント名、ファイル名およびプロセス名など種別毎の名称を含む。「リソース」は、「サーバ」上に実現される。このため、「リソース」の指定は「サーバ」の指定も含む。
【００６３】
運用サーバ１００は、運用操作部品による操作対象の状態変化の有無に応じて、操作内容を「操作」および「参照」に区分する。「操作」は、操作対象の状態（動作状況）を変化させるものである。例えば、サーバの起動、停止、設定変更は、操作対象であるサーバの状態を変化させる（起動から停止、停止から起動、所有ファイルが設定前から設定後へなどと変化させる）。また、リソースの更新、生成、削除は、操作対象であるリソースの状態（動作状況）を変化させる（ファイルの更新前から更新後、ファイルの無から有、ファイルの有から無へなどと変化させる）。「参照」は、操作対象の状態を変化させないものである。例えば、サーバの状態の確認は、確認するだけなので、操作対象であるサーバの状態を変化させない。また、リソースの状態の確認も、同様に確認するだけなので、操作対象であるリソースの状態を変化させない。
【００６４】
上記のように、運用サーバ１００は、運用操作部品の操作対象を「サーバ」および「リソース」の２種類、運用操作部品の操作内容を「操作」および「参照」の２種類に区分する。そして、運用サーバ１００は、各運用操作部品を、２×２＝４種類の動作モデルに区分する。
【００６５】
図６（Ａ）は動作モデルＡである。動作モデルＡは、「サーバ」に対する「操作」を行う動作モデルである。以下の説明では、「サーバ」に対する「操作」を「サーバ操作」と称することがある。
【００６６】
図６（Ｂ）は動作モデルＢである。動作モデルＢは、「サーバ」に対する「参照」を行う動作モデルである。以下の説明では、「サーバ」に対する「参照」を「サーバ参照」と称することがある。
【００６７】
図６（Ｃ）は動作モデルＣである。動作モデルＣは、「リソース」に対する「操作」を行う動作モデルである。以下の説明では、「リソース」に対する「操作」を「リソース操作」と称することがある。
【００６８】
図６（Ｄ）は動作モデルＤである。動作モデルＤは、「リソース」に対する「参照」を行う動作モデルである。以下の説明では、「リソース」に対する「参照」を「リソース参照」と称することがある。
【００６９】
図７は、並列実行可能性の判断手順の例を示す図である。ワークフローの実行の際、操作対象の状態が時間経過により変化する可能性があり、操作対象の状態が不定となる場合もある。操作対象に関係性があり、操作対象の状態が不定の場合に並列実行すると、ワークフローが正しく動作しない可能性がある。このため、運用サーバ１００は、並列実行可能性の判断に、操作対象であるサーバおよびリソースの関係および判断時における状態を考慮する。
【００７０】
運用サーバ１００は、操作対象の階層関係と操作対象（および、操作対象と階層関係にある他の対象）の状態を考慮した動作モデルの情報と、動作モデルに基づく並列実行可能性の判断基準の情報を記憶する。運用サーバ１００は、動作モデルの情報と判断基準の情報とに基づいて、各運用操作部品の並列実行可能性を判断する。
【００７１】
判断基準の情報は、第１の判断基準３１、第２の判断基準３２および第３の判断基準３３の情報を含む。第１の判断基準３１は、動作モデルの構造に基づいて運用操作部品の並列実行可能性を判断するための基準である。第１の判断基準３１は、図６で例示した動作モデル間の関係に応じた判断基準を含む。
【００７２】
第２の判断基準３２は、動作モデルの構造に基づいて運用操作部品の並列実行可能性を判断するための基準である。第２の判断基準３２は、リソース名やリソース種別の関係に応じた判断基準を含む。第１の判断基準３１および第２の判断基準３２は、静的な情報に基づく判断を行う判断基準であるといえる。
【００７３】
第３の判断基準３３は、操作対象の状態に基づいて運用操作部品の並列実行可能性を判断するための基準である。運用サーバ１００は、第１の判断基準３１や第２の判断基準３２から操作対象に関係性（階層関係）があると判断した場合、操作対象（リソース）や、操作対象と階層関係にある対象（サーバ）の状態を確認し、第３の判断基準に則って並列実行可能性を判断する。第３の判断基準３３は、判断時における動的な情報に基づく判断を行う判断基準であるといえる。
【００７４】
図８は、第１の判断基準の例を示す図である。第１の判断基準３１は、先行の動作モデル（先行の運用操作部品の動作モデル）と、後続の動作モデル（後続の運用操作部品の動作モデル）とに対する並列実行可能性の判断基準の情報を含む。具体的には以下の情報を含む。
【００７５】
先行が動作モデルＡであり、後続が動作モデルＡである場合は次のように判断する。操作対象のサーバ名が異なれば、並列実行可能（図中、並列可能と表記することがある）である。操作対象のサーバ名が同一であれば、並列実行不可能（図中、並列不可能と表記することがある）である。
【００７６】
先行が動作モデルＢであり、後続が動作モデルＡである場合は次のように判断する。操作対象のサーバ名が異なれば、並列実行可能である。操作対象のサーバ名が同一であれば、並列実行不可能である。
【００７７】
先行が動作モデルＣであり、後続が動作モデルＡである場合は次のように判断する。操作対象のサーバ名が異なれば、並列実行可能である。この場合、動作モデルＣ（先行の運用操作部品）の操作対象のリソースと、動作モデルＡ（後続の運用操作部品）の操作対象のサーバとは、階層関係にないともいえる。操作対象のサーバ名が同一であれば、並列実行不可能である。この場合、動作モデルＣ（先行の運用操作部品）の操作対象のリソースと、動作モデルＡ（後続の運用操作部品）の操作対象のサーバとは、階層関係にあるといえる。
【００７８】
先行が動作モデルＤであり、後続が動作モデルＡである場合は次のように判断する。操作対象のサーバ名が異なれば、並列実行可能である（両運用操作部品の操作対象が階層関係にない）。操作対象のサーバ名が同一であれば、並列実行不可能である（両運用操作部品の操作対象が階層関係にある）。
【００７９】
先行が動作モデルＡであり、後続が動作モデルＢである場合は次のように判断する。操作対象のサーバ名が異なれば、並列実行可能である。操作対象のサーバ名が同一であれば、並列実行不可能である。
【００８０】
先行が動作モデルＢであり、後続が動作モデルＢである場合は次のように判断する。操作対象のサーバ名が異なれば、並列実行可能である。操作対象のサーバ名が同一であれば、第３の判断基準３３のａ列（図１０で示す）に基づいて操作対象（サーバ）の状態を確認し、確認結果に応じて並列実行可能性を更に判断する（詳細判断対象とする）。
【００８１】
先行が動作モデルＣであり、後続が動作モデルＢである場合は次のように判断する。操作対象のサーバ名が異なれば、並列実行可能である（両運用操作部品の操作対象が階層関係にない）。操作対象のサーバ名が同一であれば（両運用操作部品の操作対象が階層関係にある）、第３の判断基準３３のｂ列に基づいて操作対象（サーバ）の状態を確認し、確認結果に応じて並列実行可能性を更に判断する（詳細判断対象とする）。
【００８２】
先行が動作モデルＤであり、後続が動作モデルＢである場合は次のように判断する。操作対象のサーバ名が異なれば、並列実行可能である（両運用操作部品の操作対象が階層関係にない）。操作対象のサーバ名が同一であれば（両運用操作部品の操作対象が階層関係にある）、第３の判断基準３３のｂ列に基づいて操作対象（サーバ）の状態を確認し、確認結果に応じて並列実行可能性を更に判断する（詳細判断対象とする）。
【００８３】
先行が動作モデルＡであり、後続が動作モデルＣである場合は次のように判断する。操作対象のサーバ名が異なれば、並列実行可能である（両運用操作部品の操作対象が階層関係にない）。操作対象のサーバ名が同一であれば、並列実行不可能である（両運用操作部品の操作対象が階層関係にある）。
【００８４】
先行が動作モデルＢであり、後続が動作モデルＣである場合は次のように判断する。操作対象のサーバ名が異なれば、並列実行可能である（両運用操作部品の操作対象が階層関係にない）。操作対象のサーバ名が同一であれば、第３の判断基準３３のｂ列に基づいて操作対象（サーバ）の状態を確認し、確認結果に応じて並列実行可能性を更に判断する（詳細判断対象とする）。
【００８５】
先行が動作モデルＣであり、後続が動作モデルＣである場合は次のように判断する。操作対象のサーバ名が異なれば、並列実行可能である。操作対象のサーバ名が同一であれば、第２の判断基準３２（図９で示す）に基づいて操作対象のリソース間の関連性の有無を確認し、確認結果に応じて並列実行可能性を更に判断する。
【００８６】
先行が動作モデルＤであり、後続が動作モデルＣである場合は次のように判断する。操作対象のサーバ名が異なれば、並列実行可能である。操作対象のサーバ名が同一であれば、第２の判断基準３２に基づいて操作対象のリソース間の関連性の有無を確認し、確認結果に応じて並列実行可能性を更に判断する。
【００８７】
先行が動作モデルＡであり、後続が動作モデルＤである場合は次のように判断する。操作対象のサーバ名が異なれば、並列実行可能である（両運用操作部品の操作対象が階層関係にない）。操作対象のサーバ名が同一であれば、並列実行不可能である（両運用操作部品の操作対象が階層関係にある）。
【００８８】
先行が動作モデルＢであり、後続が動作モデルＤである場合は次のように判断する。操作対象のサーバ名が異なれば、並列実行可能である（両運用操作部品の操作対象が階層関係にない）。操作対象のサーバ名が同一であれば、第３の判断基準３３のｂ列に基づいて操作対象（サーバ）の状態を確認し、確認結果に応じて並列実行可能性を更に判断する（詳細判断対象とする）。
【００８９】
先行が動作モデルＣであり、後続が動作モデルＤである場合は、次のように判断する。操作対象のサーバ名が異なれば、並列実行可能である。操作対象のサーバ名が同一であれば、第２の判断基準３２に基づいて操作対象のリソース間の関連性の有無を確認し、確認結果に応じて並列実行可能性を更に判断する。
【００９０】
先行が動作モデルＤであり、後続が動作モデルＤである場合は、次のように判断する。操作対象のサーバ名が異なれば、並列実行可能である。操作対象のサーバ名が同一であれば、第２の判断基準３２に基づいて操作対象のリソース間の関連性の有無を確認し、確認結果に応じて並列実行可能性を更に判断する。
【００９１】
図９は、第２の判断基準の例を示す図である。第２の判断基準３２は、並列実行可能性の判断対象となっている２つの運用操作部品について、操作対象のリソース間の関連性に応じた並列実行可能性の判断基準の情報を含む。リソース間の関連性は、リソース名およびリソース種別の比較結果に応じて表わされる。すなわち、リソース間の関連性は次の４つの場合に分類される。
【００９２】
第１には、並列実行可能性の判断対象となっている２つの運用操作部品において、操作対象のリソース名が同一であり、かつ、リソース種別が同一の場合である。第２には、操作対象のリソース名が異なり、かつ、リソース種別が同一の場合である。第３には、操作対象のリソース名が同一であり、かつ、リソース種別が異なる場合である。第４には、動作対象のリソース名が異なり、かつ、リソース種別が異なる場合である。
【００９３】
ここで、リソース種別には、属性をもつリソース種別と属性をもたないリソース種別とが存在する。属性とはリソースの処理対象によりリソース種別を更に区分した情報である。リソース種別の属性を考慮するとき、リソース種別の同一性は次のように判断される。
【００９４】
まず、先行の運用操作部品および後続の運用操作部品の操作対象のリソース種別の両方が属性をもつ場合である。この場合、両方のリソース種別の属性を比較し、一致すればリソース種別が同一であり、不一致であればリソース種別が異なる。
【００９５】
次に、先行の運用操作部品および後続の運用操作部品の操作対象のリソース種別の何れか一方のみが属性をもつ場合である。この場合、属性をもたない方のリソース種別と、属性をもつ方のリソース種別の属性とを比較し、一致すればリソース種別が同一であり、不一致であればリソース種別が異なる。
【００９６】
更に、先行の運用操作部品および後続の運用操作部品の操作対象のリソース種別の両方が属性をもたない場合である。この場合、両方のリソース種別を比較し、一致すればリソース種別が同一であり、不一致であればリソース種別が異なる。
【００９７】
第２の判断基準３２は、次の判断基準を含む。操作対象のリソース名が同一であり、かつ、リソース種別が同一の場合（第１の場合）、次のように判断する。何れの運用操作部品もリソース参照のみであれば、第３の判断基準３３のｄ列により操作対象（リソース）、および、操作対象と階層関係にある対象（サーバ）の状態を確認し、確認結果に応じて並列実行可能性を更に判断する（詳細判断対象とする）。何れかの運用操作部品がリソース操作を含んでいれば、並列実行不可能である。
【００９８】
操作対象のリソース名が異なり、かつ、リソース種別が同一の場合（第２の場合）、次のように判断する。何れの運用操作部品もリソース参照のみの場合、第３の判断基準３３のｃ列により操作対象（リソース）と階層関係にある対象（サーバ）の状態を確認し、確認結果に応じて並列実行可能性を更に判断する。何れかの運用操作部品がリソース操作を含んでいれば、第３の判断基準３３のｄ列により操作対象（リソース）、および、操作対象と階層関係にある対象（サーバ）の状態を確認し、確認結果に応じて並列実行可能性を更に判断する。
【００９９】
操作対象のリソース名が同一であり、かつ、リソース種別が異なる場合（第３の場合）、次のように判断する。何れの運用操作部品もリソース参照のみであれば、第３の判断基準３３のｃ列により操作対象（リソース）と階層関係にある対象（サーバ）の状態を確認し、確認結果に応じて並列実行可能性を更に判断する。何れかの運用操作部品がリソース操作を含んでいれば、第３の判断基準３３のｄ列により操作対象（リソース）、および、操作対象と階層関係にある対象（サーバ）の状態を確認し、確認結果に応じて並列実行可能性を更に判断する。
【０１００】
動作対象のリソース名が異なり、かつ、リソース種別が異なる場合（第４の場合）、第３の判断基準３３のｃ列により操作対象（リソース）と階層関係にある対象（サーバ）の状態を確認し、確認結果に応じて並列実行可能性を更に判断する。第２の判断基準３２では、第２，第３，第４の場合の何れも詳細判断対象と判断されることになる。
【０１０１】
図１０は、第３の判断基準の例を示す図である。第３の判断基準３３は、第１の判断基準３１および第２の判断基準３２を基に検出された操作対象の関係性毎に、サーバ状態およびリソース状態に応じた並列実行可能性を定めた情報である。
【０１０２】
第３の判断基準３３には、関係性“ａ”、“ｂ”、“ｃ”、“ｄ”が定められている。関係性“ａ”、“ｂ”、“ｃ”、“ｄ”それぞれは、第１の判断基準３１および第２の判断基準３２で説明した“ａ列”、“ｂ列”、“ｃ列”、“ｄ列”に対応する。
【０１０３】
関係性“ａ”は、２つの運用操作部品が同一のサーバに対してサーバ参照を行う関係である。
関係性“ｂ”は、２つの運用操作部品が同一のサーバに対して、一方がサーバ参照、他方がリソース操作を行う関係である。
【０１０４】
関係性“ｃ”は、２つの運用操作部品が同一サーバ上の、異なるリソースに対してリソース参照のみを行う関係である。なお、２つのリソースにおいて、リソース名およびリソース種別の少なくとも一方が相違する場合、両リソースは、互いに異なるリソースである。
【０１０５】
関係性“ｄ”は、第１の関係と第２の関係とを含む。第１の関係は、２つの運用操作部品が同一サーバ上の同じリソースに対してリソース参照のみを行う関係である。第２の関係は、２つの運用操作部品における各操作対象のリソースが、同一サーバ上にあり、リソース名およびリソース種別の何れか一方が同一であり、かつ、２つの運用操作部品の少なくとも一方がリソース操作を行う関係である。第３の判断基準３３は、各関係性に対して次の判断基準を含む。
【０１０６】
関係性“ａ”に対して、サーバ状態が不定の場合、両運用操作部品は並列実行不可能である。関係性“ａ”に対して、サーバ状態が不定以外の場合、両運用操作部品は並列実行可能である。
【０１０７】
関係性“ｂ”に対して、サーバ状態が不定の場合、両運用操作部品は並列実行不可能である。関係性“ｂ”に対して、サーバ状態が不定以外の場合、両運用操作部品は並列実行可能である。
【０１０８】
関係性“ｃ”に対して、サーバ状態が不定の場合、両運用操作部品は並列実行不可能である。関係性“ｃ”に対して、サーバ状態が不定以外の場合、両運用操作部品は並列実行可能である。
【０１０９】
関係性“ｄ”に対して、サーバ状態が不定の場合、両運用操作部品は並列実行不可能である。関係性“ｄ”に対して、サーバ状態が不定以外の場合、操作対象の何れかのリソースのリソース状態が不定であれば、両運用操作部品は並列実行不可能である。関係性“ｄ”に対して、サーバ状態が不定以外の場合、操作対象の何れのリソースもリソース状態が不定以外であれば、両運用操作部品は並列実行可能である。
【０１１０】
次に、ワークフロー２０を含むワークフロー、動作モデル、第１の判断基準３１、第２の判断基準３２および第３の判断基準３３に関する情報の具体例を説明する。
図１１は、テーブルの例を示す図である。記憶部１１０は、ワークフロー管理テーブル１１１、運用操作部品定義テーブル１１２、変数管理テーブル１１３、インスタンス管理テーブル１１４、動作モデル定義テーブル１１５、動作モデル状態管理テーブル１１６、状態遷移定義テーブル１１７、並列実行判断基準定義テーブル１１８、サーバ状態管理テーブル１１９およびリソース状態管理テーブル１２０を記憶する。
【０１１１】
ワークフロー管理テーブル１１１は、ワークフロー２０を含む複数のワークフローの管理情報である。ワークフロー管理テーブル１１１は、例えば、ワークフロー２０に含まれる運用操作部品名、運用操作部品を実行する順番、運用操作部品で用いられる変数の変数名などの情報を含む。
【０１１２】
運用操作部品定義テーブル１１２は、運用操作部品の管理情報である。運用操作部品定義テーブル１１２は、例えば、運用操作部品名、操作対象、操作内容および操作対象のリソース種別などの情報を含む。
【０１１３】
変数管理テーブル１１３は、運用操作部品の各変数に設定する変数値の管理情報である。インスタンス管理テーブル１１４は、現在実行中のワークフロー（ワークフローのインスタンスと称することがある）の管理情報である。インスタンス管理テーブル１１４は、例えば、該当のワークフローにおいて実行中の運用操作部品を示す情報を含む。
【０１１４】
動作モデル定義テーブル１１５は、動作モデルの定義情報である。動作モデル状態管理テーブル１１６は、動作モデルの状態（各ワークフローにおける各操作対象の状態）を管理するための情報である。なお、操作対象（サーバおよびリソース）の状態に関する情報も、記憶部１１０に予め格納される（詳細は後述される）。
【０１１５】
状態遷移定義テーブル１１７は、運用操作部品の実行による操作対象（サーバおよびリソース）の状態遷移を定義する情報である。並列実行判断基準定義テーブル１１８は、第１の判断基準３１、第２の判断基準３２および第３の判断基準３３を定義する情報である。
【０１１６】
サーバ状態管理テーブル１１９は、操作対象のサーバの状態を管理するための情報である。リソース状態管理テーブル１２０は、操作対象のリソースの状態を管理するための情報である。
【０１１７】
図１２は、ワークフロー管理テーブルの例を示す図である。ワークフロー管理テーブル１１１は、ワークフロー番号、部品番号、運用操作部品名、サーバ名、リソース名、動作モデルおよび次の部品番号の項目を含む。
【０１１８】
ワークフロー番号の項目には、ワークフローを識別する番号（ワークフロー番号）が登録される。例えば、ワークフロー２０のワークフロー番号は“１”である。部品番号の項目には、ワークフローに含まれる運用操作部品に付された番号（部品番号）が登録される。部品番号は、ワークフロー番号に対して一意である。運用操作部品名の項目には、運用操作部品を識別する名称（運用操作部品名）が登録される。サーバ名の項目には、操作対象のサーバを指定するための変数名が登録される。リソース名の項目には、操作対象のリソースを指定するための変数名が登録される。動作モデルの項目には、動作モデルを示す情報が登録される。次の部品番号の項目には、次に実行される運用操作部品の部品番号（同じワークフローに属する部品番号）が登録される。
【０１１９】
なお、ワークフローの開始を示す“Ｓｔａｒｔ”や終了を示す“Ｅｎｄ”に相当する運用操作部品に対しては、サーバ名、リソース名および動作モデルは設定なし“−”（ハイフン）となる。また、操作対象がサーバであり、リソースでない場合、リソース名は設定なし“−”となる。更に、操作対象がリソースである場合、リソースはサーバ上で実現されるので、サーバ名およびリソース名の両方が登録される。“Ｅｎｄ”に相当する運用操作部品に対しては、次の部品番号は設定なし“−”となる。例えば、ワークフロー管理テーブル１１１には、次のような情報が登録される。
【０１２０】
１つ目の例として、ワークフロー番号が“１”、部品番号が“０”、運用操作部品名が“Ｓｔａｒｔ”、サーバ名が“−”、リソース名が“−”、動作モデルが“−”、次の部品番号が“１”という情報が登録される。これは、ワークフロー２０の開始を示す運用操作部品であることを示す。当該レコードによれば、次に実行される運用操作は、ワークフロー番号“１”の部品番号“１”の運用操作部品２１（運用操作部品名“ＯＳ再起動”）である。
【０１２１】
２つ目の例として、ワークフロー番号が“１”、部品番号が“１”、運用操作部品名が“ＯＳ再起動”、サーバ名が“変数１”、リソース名が“−”、動作モデルが“Ａ”、次の部品番号が“２”という情報が登録される。これは、運用操作部品２１を示している。運用操作部品２１では、サーバ名の指定に“変数１”が用いられる。運用操作部品２１の操作内容はサーバ操作なので、リソース名を指定しなくてよく、リソース名の項目は設定なし“−”である。また、運用操作部品２１の操作内容はサーバ操作なので、動作モデル“Ａ”である。運用操作部品２１の次に実行される運用操作部品は、ワークフロー番号“１”の部品番号“２”の運用操作部品２２（運用操作部品名“サーバの起動確認”）である。運用操作部品２２の情報も、運用操作部品２１と同様にワークフロー管理テーブル１１１に登録されている（ワークフロー番号“１”、部品番号“２”のレコード）。
【０１２２】
３つ目の例として、ワークフロー番号が“１”、部品番号が“３”、運用操作部品名が“サービスの起動確認”、サーバ名が“変数１”、リソース名が“変数２”、動作モデルが“Ｄ”、次の部品番号が“４”という情報が登録される。これは、運用操作部品２３を示している。運用操作部品２３では、サーバ名の指定に“変数１”が用いられる。運用操作部品２３では、リソース名の指定に“変数２”が用いられる。運用操作部品２３の操作内容は、リソース参照なので、動作モデル“Ｄ”である。運用操作部品２３の次に実行される運用操作部品は、ワークフロー番号“１”の部品番号“４”の運用操作部品２４（運用操作部品名“アカウントの作成”）である。
【０１２３】
ワークフロー管理テーブル１１１には、運用操作部品２２，２４，２５，２６，２７についても、運用操作部品２１，２３と同様の情報が登録される。また、他のワークフロー（例えば、ワークフロー番号“２”）についても同様に定義できる。
【０１２４】
図１３は、運用操作部品定義テーブルの例を示す図である。運用操作部品定義テーブル１１２は、運用操作部品名、操作対象、操作内容および対象の種別の項目を含む。
運用操作部品名の項目には、運用操作部品名が登録される。操作対象の項目には、操作対象を示す情報が登録される。操作内容の項目には、操作内容を示す情報が登録される。対象の種別の項目には、操作対象が「リソース」の場合に、当該リソースの種別（リソース種別）を示す情報が登録される。なお、操作対象が「サーバ」の場合、対象の種別の項目は設定なし“−”となる。
【０１２５】
例えば、運用操作部品定義テーブル１１２には、次のような情報が登録される。
１つ目の例として、運用操作部品名が“ＯＳ再起動”、操作対象が“サーバ”、操作内容が“操作”、対象の種別が“−”という情報が登録される。これは、“ＯＳ再起動”の運用操作部品名で示される運用操作部品の操作対象がサーバであり、操作内容が操作（すなわち、サーバ操作）であることを示す。また、操作対象がサーバなので、対象の種別は設定なし“−”となる。
【０１２６】
２つ目の例として、運用操作部品名が“サーバの起動確認”、操作対象が“サーバ”、操作内容が“参照”、対象の種別が“−”という情報が登録される。これは、“サーバの起動確認”の運用操作部品名で示される運用操作部品の操作対象がサーバであり、操作内容が参照（すなわち、サーバ参照）であることを示す。また、操作対象がサーバなので、対象の種別は設定なし“−”となる。
【０１２７】
３つ目の例として、運用操作部品名が“サービスの起動確認”、操作対象が“リソース”、操作内容が“参照”、対象の種別が“Ｓｅｒｖｉｃｅ．Ａｃｃｏｕｎｔ”という情報が登録される。これは、“サービスの起動確認”の運用操作部品名で示される運用操作部品の操作対象がリソースであり、操作内容が参照（すなわち、リソース参照）であることを示す。また、操作対象のリソースの種別が“Ｓｅｒｖｉｃｅ．Ａｃｃｏｕｎｔ”であることを示す。なお、リソース種別の表記において、リソース種別がピリオド“．”を含む場合、ピリオド“．”よりも前がリソース種別を示し、ピリオド“．”よりも後が属性を示す。“Ｓｅｒｖｉｃｅ．Ａｃｃｏｕｎｔ”の例では、リソース種別“Ｓｅｒｖｉｃｅ”であり、属性“Ａｃｃｏｕｎｔ”が指定されていることになる。
【０１２８】
４つ目の例として、運用操作部品名が“アカウントの作成”、操作対象が“リソース”、操作内容が“操作”、対象の種別が“Ａｃｃｏｕｎｔ”という情報が登録される。これは、“アカウントの作成”の運用操作部品名で示される運用操作部品の操作対象がリソースであり、操作内容が操作（すなわち、リソース操作）であることを示す。また、操作対象のリソースの種別が“Ａｃｃｏｕｎｔ”であることを示す。
【０１２９】
他の運用操作部品の情報も、運用操作部品定義テーブル１１２に同様に登録される。
図１４は、変数管理テーブルの例を示す図である。変数管理テーブル１１３は、インスタンス番号、ワークフロー番号、変数名および変数値の項目を含む。
【０１３０】
インスタンス番号の項目には、ワークフローのインスタンスを識別する番号（インスタンス番号）が登録される。ワークフロー番号の項目には、ワークフロー番号が登録される。変数名の項目には、変数名が登録される。変数値の項目には、変数名で示される変数に代入する変数値が登録される。
【０１３１】
例えば、変数管理テーブル１１３には、インスタンス番号が“１”、ワークフロー番号が“１”、変数名が“変数１”、変数値が“Ｘ”という情報が登録される。これは、ワークフロー２０（ワークフロー番号“１”）のインスタンスに、インスタンス番号“１”が付与されていることを示す。また、ワークフロー２０の当該インスタンスに対して、“変数１”の変数名の変数に、変数値“Ｘ”を代入することを示す。この場合、変数値“Ｘ”は、サーバ名に相当する情報である。ワークフロー２０の当該インスタンスに用いられる他の変数および変数値も、変数管理テーブル１１３に同様に登録される。また、ワークフロー２０以外の他のワークフローのインスタンスに用いられる変数および変数値も、変数管理テーブル１１３に同様に登録される。
【０１３２】
図１５は、インスタンス管理テーブルの例を示す図である。インスタンス管理テーブル１１４は、インスタンス番号、ワークフロー番号、現在の部品番号および状態の項目を含む。
【０１３３】
インスタンス番号の項目には、インスタンス番号が登録される。ワークフロー番号の項目には、ワークフロー番号が登録される。現在の部品番号の項目には、次の実行対象である運用操作部品の部品番号が登録される。状態の項目には、ワークフローを実行中であるか否かを示す情報が登録される。
【０１３４】
例えば、インスタンス管理テーブル１１４には、インスタンス番号が“１”、ワークフロー番号が“１”、現在の部品番号が“１”、状態が“実行中”という情報が登録される。これは、ワークフロー２０を実行中であること、ワークフロー２０に含まれる複数の運用操作部品のうち、次の実行対象が運用操作部品２１（ワークフロー番号“１”の部品番号“１”）であることを示す。他のワークフローのインスタンスについても、インスタンス管理テーブル１１４に同様に登録される。
【０１３５】
図１６は、動作モデル定義テーブルの例を示す図である。動作モデル定義テーブル１１５は、操作対象、操作内容および動作モデルの項目を含む。操作対象の項目には、操作対象を示す情報が登録される。操作内容の項目には、操作内容を示す情報が登録される。動作モデルの項目には、動作モデルの識別情報が登録される。
【０１３６】
例えば、動作モデル定義テーブル１１５には、操作対象が“サーバ”、操作内容が“操作”、動作モデルが“Ａ”という情報が登録される。これは、サーバ操作を行う運用操作部品を動作モデルＡに区分することを示す。
【０１３７】
また、動作モデル定義テーブル１１５には、操作対象が“サーバ”、操作内容が“参照”、動作モデルが“Ｂ”という情報が登録される。これは、サーバ参照を行う運用操作部品を動作モデルＢに区分することを示す。
【０１３８】
また、動作モデル定義テーブル１１５には、操作対象が“リソース”、操作内容が“操作”、動作モデルが“Ｃ”という情報が登録される。これは、リソース操作を行う運用操作部品を動作モデルＣに区分することを示す。
【０１３９】
また、動作モデル定義テーブル１１５には、操作対象が“リソース”、操作内容が“参照”、動作モデルが“Ｄ”という情報が登録される。これは、リソース参照を行う運用操作部品を動作モデルＤに区分することを示す。
【０１４０】
図１７は、動作モデル状態管理テーブルの例を示す図である。動作モデル状態管理テーブル１１６は、番号、インスタンス番号、ワークフロー番号、部品番号、リソース名、リソース種別、リソース状態、サーバ名、サーバ状態、動作モデルおよび改善後の次の部品番号の項目を含む。
【０１４１】
番号の項目には、レコードを識別するための番号が登録される。インスタンス番号の項目には、インスタンス番号が登録される。ワークフロー番号の項目には、ワークフロー番号が登録される。部品番号の項目には、部品番号が登録される。リソース名の項目には、リソース名が登録される。リソース種別の項目には、リソースの種別（リソース種別）が登録される。リソース状態の項目には、リソースの状態（リソース状態）が登録される。サーバ名の項目には、サーバ名が登録される。サーバ状態の項目には、サーバの状態（サーバ状態）が登録される。動作モデルの項目には、動作モデルが登録される。改善後の次の部品番号の項目には、並列実行可能性の判断結果を反映した場合の次に実行する運用操作部品の部品番号が登録される。
【０１４２】
例えば、動作モデル状態管理テーブル１１６には、次のような情報が登録される。
１つ目の例として、番号が“１”、インスタンス番号が“１”、ワークフロー番号が“１”、部品番号が“０”、リソース名が“−”、リソース種別が“−”、リソース状態が“−”、サーバ名が“−”、サーバ状態が“−”、動作モデルが“−”、改善後の次の部品番号が“１”という情報が登録される。
【０１４３】
これは、ワークフロー２０の“Ｓｔａｒｔ”に相当する運用操作部品を示す。“Ｓｔａｒｔ”の運用操作部品は、単にワークフローの開始を示すものなので、操作対象や操作内容をもたない。このため、何れの動作モデルにも区分されない。“Ｓｔａｒｔ”の運用操作部品については、並列実行可能性の判断を行わなくてよい。したがって、改善後の次の部品番号は“１”のままである。
【０１４４】
２つ目の例として、番号が“２”、インスタンス番号が“１”、ワークフロー番号が“１”、部品番号が“１”、リソース名が“−”、リソース種別が“−”、リソース状態が“−”、サーバ名が“Ｘ”、サーバ状態が“不定”、動作モデルが“Ａ”、改善後の次の部品番号が“２”という情報が登録される。
【０１４５】
これは、ワークフロー２０の運用操作部品２１の実行直後の状態を示す。運用操作部品２１は、動作モデル“Ａ”に区分され、操作対象のサーバ名が“Ｘ”であること、運用操作部品２１の実行直後で次の運用操作部品を実行する前の段階におけるサーバ状態が“不定”であったことを示す。動作モデル“Ａ”はサーバ操作に相当するので、リソース名、リソース種別およびリソース状態の項目は設定なし“−”である。更に、運用操作部品２１の実行直後で次の運用操作部品を実行する前の段階において、次以降の運用操作部品の並列実行可能性を判断した結果、次の部品番号（改善後の次の部品番号）が“２”（運用操作部品２２）に決定されたことを示す。次の部品番号が１つであるということは、運用操作部品２２，２３に対して並列実行不可能と判断されたことを意味する。
【０１４６】
３つ目の例として、番号が“３”、インスタンス番号が“１”、ワークフロー番号が“１”、部品番号が“２”、リソース名が“−”、リソース種別が“−”、リソース状態が“−”、サーバ名が“Ｘ”、サーバ状態が“ＯＮ”、動作モデルが“Ｂ”、改善後の次の部品番号が“３”という情報が登録される。
【０１４７】
これは、ワークフロー２０の運用操作部品２２の実行直後の状態を示す。運用操作部品２２は、動作モデル“Ｂ”に区分され、操作対象のサーバ名が“Ｘ”、運用操作部品２２の実行直後で次の運用操作部品を実行する前の段階におけるサーバ状態が“ＯＮ”であったことを示す。動作モデル“Ｂ”はサーバ参照に相当するので、リソース名、リソース種別およびリソース状態の項目は設定なし“−”である。更に、運用操作部品２２の実行直後で次の運用操作部品を実行する前の段階において、次以降の運用操作部品の並列実行可能性を判断した結果、次の部品番号（改善後の次の部品番号）が“３”（運用操作部品２３）に決定されたことを示す。この場合も、番号“２”のレコードと同様に、運用操作部品２３，２４に対して並列実行不可能と判断されたことを意味する。
【０１４８】
４つ目の例として、番号が“４”、インスタンス番号が“１”、ワークフロー番号が“１”、部品番号が“３”、リソース名が“Ｓ”、リソース種別が“Ｓｅｒｖｉｃｅ．Ａｃｃｏｕｎｔ”、リソース状態が“ＳＴＡＲＴ”、サーバ名が“Ｘ”、サーバ状態が“ＯＮ”、動作モデルが“Ｄ”、改善後の次の部品番号が“４”という情報が登録される。
【０１４９】
これは、ワークフロー２０の運用操作部品２３の実行直後の状態を示す。運用操作部品２３は、動作モデル“Ｄ”に区分され、操作対象のリソース名が“Ｓ”、リソース種別が“Ｓｅｒｖｉｃｅ．Ａｃｃｏｕｎｔ”、操作対象のサーバ名が“Ｘ”であることを示す。ここで、例えばリソース名“Ｓ”はサービスを示す識別子であり、リソース種別“Ｓｅｒｖｉｃｅ．Ａｃｃｏｕｎｔ”はアカウント管理を行うサービスである。また、運用操作部品２３の実行直後で次の運用操作部品を実行する前の段階において、リソース状態が“ＳＴＡＲＴ”（起動中）であり、サーバ状態が“ＯＮ”であったことを示す。更に、運用操作部品２３の実行直後で次の運用操作部品を実行する前の段階において、次以降の運用操作部品の並列実行可能性を判断した結果、次の部品番号（改善後の次の部品番号）が“４”（運用操作部品２４）に決定されたことを示す。この場合も、番号“２”のレコードと同様に、運用操作部品２４，２５に対して並列実行不可能と判断されたことを意味する。
【０１５０】
５つ目の例として、番号が“５”、インスタンス番号が“１”、ワークフロー番号が“１”、部品番号が“４”、リソース名が“Ａｃ”、リソース種別が“Ａｃｃｏｕｎｔ”、リソース状態が“ＥＸＩＳＴ”、サーバ名が“Ｘ”、サーバ状態が“ＯＮ”、動作モデルが“Ｃ”、改善後の次の部品番号が“５，６”という情報が登録される。
【０１５１】
これは、ワークフロー２０の運用操作部品２４の実行直後の状態を示す。運用操作部品２４は、動作モデル“Ｃ”に区分され、操作対象のリソース名が“Ａｃ”、リソース種別が“Ａｃｃｏｕｎｔ”、操作対象のサーバ名が“Ｘ”であることを示す。ここで、リソース名“Ａｃ”はアカウントを示す識別子であり、リソース種別“Ａｃｃｏｕｎｔ”はアカウントの情報である。また、運用操作部品２４の実行直後で次の運用操作部品を実行する前の段階において、リソース状態が“ＥＸＩＳＴ”（該当のアカウント情報が存在している）であり、サーバ状態が“ＯＮ”であったことを示す。更に、運用操作部品２４の実行直後で次の運用操作部品を実行する前の段階において、次以降の運用操作部品の並列実行可能性を判断した結果、次の部品番号（改善後の次の部品番号）が“５，６”（運用操作部品２５，２６）に決定されたことを示す。すなわち、運用操作部品２５を実行する直前において、運用操作部品２５，２６が並列実行可能と判断されたことを意味する。
【０１５２】
運用操作部品２５（ワークフロー番号“１”の部品番号“５”）および運用操作部品２６（ワークフロー番号“１”の部品番号“６”）についても、動作モデル状態管理テーブル１１６に同様の情報が登録される。運用操作部品２５，２６は並列実行されるため、改善後の次の部品番号の項目には、何れも部品番号“７”（運用操作部品２７）が設定される。また、動作モデル状態管理テーブル１１６には、他のインスタンスに関する状態も同様に登録される。
【０１５３】
ここで、運用サーバ１００は、リソースやサーバのとり得る状態の情報（状態情報）を予め保持している。そこで、状態情報の例を説明する。
図１８は、リソース種別の属性定義と状態の種類の例を示す図である。状態情報１１６ａは、リソース種別とリソース種別の属性と状態との対応を示す情報である。状態情報１１６ａは、記憶部１１０に予め格納される（図１１では図示を省略している）。状態情報１１６ａは、リソース種別、リソース種別の属性および状態の項目を含む。
【０１５４】
リソース種別の項目には、リソース種別の名称が登録される。リソース種別の属性の項目には、リソース種別の属性の名称が登録される。ここで、リソース種別の属性は、リソース種別を更に詳細に区分する情報である。状態の項目には、リソース種別またはリソース種別の属性に対する状態の候補が登録される。
【０１５５】
例えば、状態情報１１６ａは、リソース種別が“Ｆｉｌｅ”、リソース種別の属性が“Ｆｉｌｅ．Ｆｉｌｅ”（操作対象のリソースがファイルであるという属性）、状態が“ＥＸＩＳＴ／ＮＯＮＥ／不定”という情報を含む。これは、リソース種別“Ｆｉｌｅ”における属性“Ｆｉｌｅ．Ｆｉｌｅ”に対し、“ＥＸＩＳＴ”（対象のファイルが存在する）、“ＮＯＮＥ”（対象のファイルが存在しない）、“不定”（対象のファイルが存在するか否か不明）の３つの状態の候補があることを示す。なお、図１８では、リソースの種別の属性を“Ｆｉｌｅ．Ｆｉｌｅ”のようにリソース種別も含めて示すが、このうち、属性の情報として取り扱われるのは、前述のようにピリオド“．”より後の“Ｆｉｌｅ”の部分となる（図１８において他も同様）。
【０１５６】
また、状態情報１１６ａは、リソース種別が“Ｆｉｌｅ”、リソース種別の属性が“Ｆｉｌｅ．Ｄｉｒｅｃｔｏｒｙ”（操作対象のリソースがディレクトリであるという属性）、状態が“ＥＸＩＳＴ／ＮＯＮＥ／不定”という情報を含む。これは、リソース種別“Ｆｉｌｅ”における属性“Ｆｉｌｅ．Ｄｉｒｅｃｔｏｒｙ”に対し、“ＥＸＩＳＴ”（対象のディレクトリが存在する）、“ＮＯＮＥ”（対象のディレクトリが存在しない）、“不定”（対象のディレクトリが存在するか否か不明）の３つの状態の候補があることを示す。
【０１５７】
状態情報１１６ａには、他のリソース種別の属性についても同様に状態が登録されている。例えば、リソース種別“Ｓｅｒｖｉｃｅ”（サービス）は、処理内容に応じてファイル管理（“Ｓｅｒｖｉｃｅ．Ｆｉｌｅ”）、イベント管理（“Ｓｅｒｖｉｃｅ．Ｅｖｅｎｔ”）、ジョブ管理（“Ｓｅｒｖｉｃｅ．Ｊｏｂ”）、アカウント管理（“Ｓｅｒｖｉｃｅ．Ａｃｃｏｕｎｔ”）およびシステム管理（“Ｓｅｒｖｉｃｅ．Ｓｙｓｔｅｍ”）などの複数の属性に区分され得る。リソース種別“Ｐｒｏｃｅｓｓ”（プロセス）も同様である。
【０１５８】
上記の説明では属性をもつリソース種別を例示したが、状態情報１１６ａには、属性をもたないリソース種別に対する状態も登録される。例えば、状態情報１１６ａは、リソース種別が“Ｅｖｅｎｔ”、リソース種別の属性が“−”（設定なし）、状態が“ＥＸＩＳＴ／ＮＯＮＥ／不定”という情報を含む。これは、リソース種別“Ｅｖｅｎｔ”に対し、“ＥＸＩＳＴ”（対象のイベントが存在する）、“ＮＯＮＥ”（対象のイベントが存在しない）、“不定”（対象のイベントが存在するか否か不明）の３つの状態の候補があることを示す。状態情報１１６ａには、リソース種別“Ｅｖｅｎｔ”以外にも、リソース種別“Ｊｏｂ”、“Ａｃｃｏｕｎｔ”、“Ｓｙｓｔｅｍ”といったリソース種別に対して状態の状態が登録される。また、他のリソース種別（例えば、“Ｆｉｌｅ”や“Ｓｅｒｖｉｃｅ”など）に対しても状態の情報が登録される。
【０１５９】
また、状態情報１１６ａでは、主にリソースに関する情報を例示したが、運用サーバ１００は、サーバの状態についても同様の情報を保持する。具体的には、記憶部１１０は、サーバの状態として、“ＯＮ／ＯＦＦ／不定”という情報を予め記憶する。状態“ＯＮ”は、サーバが起動中である（電源オンである）ことを示す。状態“ＯＦＦ”は、サーバが停止中である（電源オフである）ことを示す。状態“不定”は、起動中か停止中かが不明であることを示す。
【０１６０】
図１９は、状態遷移定義テーブルの例を示す図である。状態遷移定義テーブル１１７は、運用操作部品名、操作前のサーバ状態、操作後のサーバ状態、操作前のリソース状態および操作後のリソース状態の項目を含む。
【０１６１】
運用操作部品名の項目には、運用操作部品名が登録される。操作前のサーバ状態の項目には、運用操作部品を実行する前のサーバ状態が登録される。操作後のサーバ状態の項目には、運用操作部品を実行した後のサーバ状態が登録される。操作前のリソース状態の項目には、運用操作部品を実行する前のリソース状態が登録される。操作後のリソース状態の項目には、運用操作部品を実行した後のリソース状態が登録される。
【０１６２】
例えば、状態遷移定義テーブル１１７には、次のような情報が登録される。
１つ目の例として、運用操作部品名が“ＯＳ再起動”、操作前のサーバ状態が“ＯＮ”、操作後のサーバ状態が“不定”、操作前のリソース状態が“−”、操作後のリソース状態が“−”という情報が登録される。これは、運用操作部品名“ＯＳ再起動”である運用操作部品（例えば、運用操作部品２１）を実行する前のサーバ状態が“ＯＮ”の場合、当該運用操作部品を実行した後のサーバ状態が“不定”であることを示す。
【０１６３】
２つ目の例として、運用操作部品名が“ＯＳ再起動”、操作前のサーバ状態が“不定”、操作後のサーバ状態が“不定”、操作前のリソース状態が“−”、操作後のリソース状態が“−”という情報が登録される。これは、運用操作部品名“ＯＳ再起動”である運用操作部品（例えば、運用操作部品２１）を実行する前のサーバ状態が“不定”の場合、当該運用操作部品を実行した後のサーバ状態が“不定”であることを示す。
【０１６４】
３つ目の例として、運用操作部品名が“サーバの起動確認”、操作前のサーバ状態が“ＯＮ”、操作後のサーバ状態が“ＯＮ”、操作前のリソース状態が“−”、操作後のリソース状態が“−”という情報が登録される。これは、運用操作部品名“サーバの起動確認”である運用操作部品（例えば、運用操作部品２２）を実行する前のサーバ状態が“ＯＮ”の場合、当該運用操作部品を実行した後のサーバ状態が“ＯＮ”であることを示す。
【０１６５】
４つ目の例として、運用操作部品名が“サーバの起動確認”、操作前のサーバ状態が“不定”、操作後のサーバ状態が“ＯＮ”、操作前のリソース状態が“−”、操作後のリソース状態が“−”という情報が登録される。これは、運用操作部品名“サーバの起動確認”である運用操作部品（例えば、運用操作部品２２）を実行する前のサーバ状態が“不定”の場合、当該運用操作部品を実行した後のサーバ状態が“ＯＮ”であることを示す。
【０１６６】
５つ目の例として、運用操作部品名が“サービスの起動確認”、操作前のサーバ状態が“−”、操作後のサーバ状態が“−”、操作前のリソース状態が“ＳＴＡＲＴ”、操作後のリソース状態が“ＳＴＡＲＴ”という情報が登録される。これは、運用操作部品名“サービスの起動確認”である運用操作部品（例えば、運用操作部品２３）を実行する前のリソース状態が“ＳＴＡＲＴ”の場合、当該運用操作部品を実行した後のリソース状態が“ＳＴＡＲＴ”であることを示す。
【０１６７】
６つ目の例として、運用操作部品名が“サービスの起動確認”、操作前のサーバ状態が“−”、操作後のサーバ状態が“−”、操作前のリソース状態が“不定”、操作後のリソース状態が“ＳＴＡＲＴ”という情報が登録される。これは、運用操作部品名“サービスの起動確認”ある運用操作部品（例えば、運用操作部品２３）を実行する前のリソース状態が“不定”の場合、当該運用操作部品を実行した後のリソース状態が“ＳＴＡＲＴ”であることを示す。
【０１６８】
状態遷移定義テーブル１１７には、他の運用操作部品についても、同様にして、運用操作部品実行前のサーバまたはリソースの状態と、運用操作部品実行後のサーバまたはリソースの状態との対応が予め登録される。
【０１６９】
図２０は、並列実行判断基準定義テーブルの例を示す図である。並列実行判断基準定義テーブル１１８は、番号、先行の動作モデル、後続の動作モデル、サーバ同一、サーバ相違、サーバ同一／リソース名同一（種別同一）、サーバ同一／リソース名同一（種別相違）、サーバ同一／リソース名相違（種別同一）、サーバ同一／リソース名相違（種別相違）の項目を含む。
【０１７０】
番号の項目には、レコードを識別するための番号が登録される。先行の動作モデルの項目には、先行の運用操作部品の動作モデルを示す情報が登録される。後続の動作モデルの項目には、先行の運用操作部品に後続する運用操作部品の動作モデルを示す情報が登録される。サーバ同一の項目には、操作対象のサーバが同一である場合に並列実行可能であるか否かを示す情報が登録される。サーバ相違の項目には、操作対象のサーバが異なる場合に並列実行可能であるか否かを示す情報が登録される。サーバ同一／リソース名同一（種別同一）の項目には、操作対象のサーバ（サーバ名）、リソース名およびリソース種別が同一である場合に、並列実行可能であるか否かを示す情報が登録される。サーバ同一／リソース名同一（種別相違）の項目には、操作対象のサーバおよびリソース名が同一であり、リソース種別が異なる場合に、並列実行可能であるか否かを示す情報が登録される。サーバ同一／リソース名相違（種別同一）の項目には、操作対象のサーバおよびリソース種別が同一であり、リソース名が異なる場合に、並列実行可能であるか否かを示す情報が登録される。サーバ同一／リソース名相違（種別相違）の項目には、操作対象のサーバが同一であり、リソース名およびリソース種別が異なる場合に、並列実行可能であるか否かを示す情報が登録される。
【０１７１】
なお、サーバ同一、サーバ相違、サーバ同一／リソース名同一（種別同一）、サーバ同一／リソース名同一（種別相違）、サーバ同一／リソース名相違（種別同一）、サーバ同一／リソース名相違（種別相違）の各項目には、更に判定を行うためのサブ基準の識別子が登録されることもある。サブ基準は、操作対象に対する動的な状態の確認結果に応じた並列実行可能性の判断基準を定義した情報である（本例では、後述するようにサブ基準Ｊ１，Ｊ２，Ｊ３，Ｊ４が予め定義される）。
【０１７２】
例えば、並列実行判断基準定義テーブル１１８には、次のような情報が登録される。
１つ目の例として、番号が“０”、先行の動作モデルが“Ａ”、後続の動作モデルが“Ａ”、サーバ同一が“不可能”、サーバ相違が“可能”、サーバ同一／リソース名同一（種別同一）が“−”（設定なし）、サーバ同一／リソース名同一（種別相違）が“−”、サーバ同一／リソース名相違（種別同一）が“−”、サーバ同一／リソース名相違（種別相違）が“−”という情報が登録される。
【０１７３】
これは、先行の運用操作部品の動作モデルが“Ａ”であり、後続の運用操作部品の動作モデルが“Ａ”の場合、操作対象のサーバが同一であれば両運用操作部品を並列実行不可能であり、操作対象のサーバが異なれば両運用操作部品を並列実行可能と判断することを示す。
【０１７４】
２つ目の例として、番号が“５”、先行の動作モデルが“Ｂ”、後続の動作モデルが“Ｂ”、サーバ同一が“サブ基準Ｊ１”、サーバ相違が“可能”、サーバ同一／リソース名同一（種別同一）が“−”（設定なし）、サーバ同一／リソース名同一（種別相違）が“−”、サーバ同一／リソース名相違（種別同一）が“−”、サーバ同一／リソース名相違（種別相違）が“−”という情報が登録される。
【０１７５】
これは、先行の運用操作部品の動作モデルが“Ｂ”であり、後続の運用操作部品の動作モデルが“Ｂ”の場合、操作対象のサーバが同一であればサブ基準Ｊ１により並列実行可能性の判断を更に詳細に行うことを示す。また、同場合に、操作対象のサーバが異なれば両運用操作部品を並列実行可能と判断することを示す。
【０１７６】
３つ目の例として、番号が“６”、先行の動作モデルが“Ｂ”、後続の動作モデルが“Ｃ”、サーバ同一が“サブ基準Ｊ２”、サーバ相違が“可能”、サーバ同一／リソース名同一（種別同一）が“−”（設定なし）、サーバ同一／リソース名同一（種別相違）が“−”、サーバ同一／リソース名相違（種別同一）が“−”、サーバ同一／リソース名相違（種別相違）が“−”という情報が登録される。
【０１７７】
これは、先行の運用操作部品の動作モデルが“Ｂ”であり、後続の運用操作部品の動作モデルが“Ｃ”の場合、操作対象のサーバが同一であればサブ基準Ｊ２により並列実行可能性の判断を更に詳細に行うことを示す。また、同場合に、操作対象のサーバが異なれば両運用操作部品を並列実行可能と判断することを示す。
【０１７８】
４つ目の例として、番号が“１０”、先行の動作モデルが“Ｃ”、後続の動作モデルが“Ｃ”、サーバ同一が“−”、サーバ相違が“可能”、サーバ同一／リソース名同一（種別同一）が“不可能”、サーバ同一／リソース名同一（種別相違）が“サブ基準Ｊ４”、サーバ同一／リソース名相違（種別同一）が“サブ基準Ｊ４”、サーバ同一／リソース名相違（種別相違）が“サブ基準Ｊ３”という情報が登録される。
【０１７９】
これは、先行の運用操作部品の動作モデルが“Ｃ”であり、後続の運用操作部品の動作モデルが“Ｃ”の場合、操作対象のサーバが異なれば両運用操作部品を並列実行可能と判断することを示す。また、操作対象のサーバ、リソース名およびリソース種別が全て同一であれば、並列実行不可能と判断することを示す。また、操作対象のサーバおよびリソース名が同一でありリソース種別が異なれば、サブ基準Ｊ４により並列実行可能性の判断を更に詳細に行うことを示す。また、操作対象のサーバおよびリソース種別が同一であり、リソース名が異なれば、サブ基準Ｊ４により並列実行可能性の判断を更に詳細に行うことを示す。更に、サーバが同一であり、リソース名およびリソース種別が異なれば、サブ基準Ｊ３により並列実行可能性の判断を更に詳細に行うことを示す。
【０１８０】
並列実行判断基準定義テーブル１１８には、先行の動作モデルおよび後続の動作モデルの他の組み合わせについても、同様にして並列実行可能性の判断基準が登録される。
図２１は、サブ基準定義テーブルの例を示す図である。サブ基準定義テーブル１１８ａは、並列実行判断基準定義テーブル１１８とともに並列実行可能性の判断に用いられる情報である。サブ基準定義テーブル１１８ａは、記憶部１１０に予め記憶される（図１１では図示を省略している）。サブ基準定義テーブル１１８ａは、サブ基準ＩＤ（IDentifier）、対象サーバの状態、対象リソースの状態および並列実行可否の項目を含む。
【０１８１】
サブ基準ＩＤの項目には、サブ基準の識別情報（サブ基準ＩＤ）が登録される。対象サーバの状態の項目には、対象サーバの状態が登録される。対象リソースの状態の項目には、対象リソースの状態が登録される。並列実行可否の項目には、並列実行可能か否かを示す情報が登録される。
【０１８２】
例えば、サブ基準定義テーブル１１８ａには次の情報が登録される。
１つ目の例として、サブ基準ＩＤが“サブ基準Ｊ１”、対象サーバの状態が“不定”、対象リソースの状態が“−”（設定なし）、並列実行可否が“不可能”という情報が登録される。これは、サブ基準Ｊ１では、対象サーバの状態が不定であれば、先行および後続する運用操作部品を並列実行不可能と判断することを示す。
【０１８３】
２つ目の例として、サブ基準ＩＤが“サブ基準Ｊ１”、対象サーバの状態が“不定以外”、対象リソースの状態が“−”、並列実行可否が“可能”という情報が登録される。これは、サブ基準Ｊ１では、対象サーバの状態が不定以外であれば、先行および後続する運用操作部品を並列実行可能と判断することを示す。
【０１８４】
３つ目の例として、サブ基準ＩＤが“サブ基準Ｊ２”、対象サーバの状態が“不定”、対象リソースの状態が“−”、並列実行可否が“不可能”という情報が登録される。これは、サブ基準Ｊ２では、対象サーバの状態が不定であれば、先行および後続する運用操作部品を並列実行不可能と判断することを示す。
【０１８５】
４つ目の例として、サブ基準ＩＤが“サブ基準Ｊ２”、対象サーバの状態が“不定以外”、対象リソースの状態が“−”、並列実行可否が“可能”という情報が登録される。これは、サブ基準Ｊ２では、対象サーバの状態が不定以外であれば、先行および後続する運用操作部品を並列実行可能と判断することを示す。
【０１８６】
５つ目の例として、サブ基準ＩＤが“サブ基準Ｊ３”、対象サーバの状態が“不定”、対象リソースの状態が“−”、並列実行可否が“不可能”という情報が登録される。これは、サブ基準Ｊ３では、対象サーバの状態が不定であれば、先行および後続する運用操作部品を並列実行不可能と判断することを示す。
【０１８７】
６つ目の例として、サブ基準ＩＤが“サブ基準Ｊ３”、対象サーバの状態が“不定以外”、対象リソースの状態が“−”、並列実行可否が“可能”という情報が登録される。これは、サブ基準Ｊ３では、対象サーバの状態が不定以外であれば、先行および後続する運用操作部品を並列実行可能であると判断することを示す。
【０１８８】
７つめの例として、サブ基準ＩＤが“サブ基準Ｊ４”、対象サーバの状態が“不定”、対象リソースの状態が“−”、並列実行可否が“不可能”という情報が登録される。これは、サブ基準Ｊ４では、対象サーバの状態が不定であれば、先行および後続する運用操作部品を並列実行不可能と判断することを示す。
【０１８９】
８つ目の例として、サブ基準ＩＤが“サブ基準Ｊ４”、対象サーバの状態が“不定以外”、対象リソースの状態が“不定”、並列実行可否が“不可能”という情報が登録される。これは、サブ基準Ｊ４では、対象サーバの状態が不定以外であり、かつ、対象リソースの状態が不定であれば、先行および後続する運用操作部品を並列実行不可能と判断することを示す。
【０１９０】
９つ目の例として、サブ基準ＩＤが“サブ基準Ｊ４”、対象サーバの状態が“不定以外”、対象リソースの状態が“不定以外”、並列実行可否が“可能”という情報が登録される。これは、サブ基準Ｊ４では、対象サーバの状態および対象リソースの状態が何れも不定以外であれば、先行および後続する運用操作部品を並列実行可能と判断することを示す。
【０１９１】
運用サーバ１００は、並列実行判断基準定義テーブル１１８およびサブ基準定義テーブル１１８ａに基づいて並列実行可能性を判断することで、第１の判断基準３１、第２の判断基準３２および第３の判断基準３３による判断を行える。すなわち、並列実行判断基準定義テーブル１１８およびサブ基準定義テーブル１１８ａは、第１の判断基準３１、第２の判断基準３２および第３の判断基準３３を運用サーバ１００に実装するための具体的なデータ構造と考えることができる。更に、並列実行判断基準定義テーブル１１８において、サブ基準ＩＤは、並列実行可能性の詳細判断対象に該当することを示す情報であるといえる。サブ基準ＩＤが設定されていない場合は、並列実行可能性の詳細判断対象に該当しないことを示す。
【０１９２】
なお、サブ基準定義テーブル１１８ａは、並列実行判断基準定義テーブル１１８に対して追加的に設けられるものであり、サブ基準定義テーブル１１８ａの情報を並列実行判断基準定義テーブル１１８に含めてもよい。サブ基準定義テーブル１１８ａの情報を並列実行判断基準定義テーブル１１８に含める場合、サブ基準定義テーブル１１８ａを設けなくてよい。
【０１９３】
図２２は、サーバ状態管理テーブルの例を示す図である。サーバ状態管理テーブル１１９は、番号、インスタンス番号、ワークフロー番号、サーバ名および状態の項目を含む。
番号の項目には、レコードを識別するための番号が登録される。インスタンス番号の項目には、インスタンス番号が登録される。ワークフロー番号の項目には、ワークフロー番号が登録される。サーバ名の項目には、操作対象のサーバのサーバ名が登録される。状態の項目には、サーバの状態を示す情報が登録される。
【０１９４】
例えば、サーバ状態管理テーブル１１９には、番号が“１”、インスタンス番号が“１”、ワークフロー番号が“１”、サーバ名が“Ｘ”、状態が“不定”という情報が登録される。これは、ワークフロー２０を実行中のある段階において、操作対象であるサーバ名“Ｘ”のサーバの状態が不定であることを示す。
【０１９５】
サーバ状態管理テーブル１１９には、他のサーバの状態も、同様に登録される。あるインスタンスにおいて、操作対象のサーバが複数であれば、複数のサーバそれぞれに対するレコードがサーバ状態管理テーブル１１９に作成される。
【０１９６】
図２３は、リソース状態管理テーブルの例を示す図である。リソース状態管理テーブル１２０は、番号、インスタンス番号、ワークフロー番号、サーバ名、リソース名および状態の項目を含む。
【０１９７】
番号の項目には、レコードを識別するための番号が登録される。インスタンス番号の項目には、インスタンス番号が登録される。ワークフロー番号の項目には、ワークフロー番号が登録される。サーバ名の項目には、操作対象のサーバのサーバ名が登録される。リソース名の項目には、操作対象のリソースのリソース名が登録される。状態の項目には、リソースの状態が登録される。
【０１９８】
例えば、リソース状態管理テーブル１２０には、次のような情報が登録される。
１つ目の例として、番号が“１”、インスタンス番号が“１”、ワークフロー番号が“１”、サーバ名が“Ｘ”、リソース名が“Ｓ”、状態が“不定”という情報が登録される。これは、ワークフロー２０を実行中のある段階において、操作対象であるリソース名“Ｓ”のリソースの状態が不定であることを示す。
【０１９９】
２つ目の例として、番号が“２”、インスタンス番号が“１”、ワークフロー番号が“１”、サーバ名が“Ｘ”、リソース名が“Ａｃ”、状態が“不定”という情報が登録される。これは、ワークフロー２０を実行中のある段階において、操作対象であるリソース名“Ａｃ”のリソースの状態が不定であることを示す。
【０２００】
リソース状態管理テーブル１２０には、他のリソースの状態も同様に登録される。あるインスタンスにおいて、操作対象のリソースが複数であれば、複数のリソースそれぞれに対するレコードがリソース状態管理テーブル１２０に作成される。
【０２０１】
次に、運用サーバ１００の具体的な処理手順を例示する。以下の説明では、ワークフロー２０を実行する場合を例示するが、運用サーバ１００は他のワークフローも同様の手順により実行する。
【０２０２】
図２４は、ワークフローの実行例を示すフローチャートである。以下、図２４に示す処理をステップ番号に沿って説明する。
（Ｓ１）制御部１３０は、ワークフロー２０（ワークフロー番号“１”）の実行開始の指示を受け付ける。すると、制御部１３０は、ワークフロー２０に含まれる各運用操作部品の動作モデルを選定する。制御部１３０は、ワークフロー２０に含まれる運用操作部品の情報や実行に用いる変数の情報を、ワークフロー管理テーブル１１１、運用操作部品定義テーブル１１２および変数管理テーブル１１３に基づいて特定する。制御部１３０は、ワークフロー２０の実行開始に伴い、新たなインスタンス番号を付与したレコードをインスタンス管理テーブル１１４に登録する。また、制御部１３０は、特定した運用操作部品に対して、動作モデル定義テーブル１１５に基づいて動作モデルの選定を行う。
【０２０３】
（Ｓ２）制御部１３０は、各運用操作部品に対して選定した動作モデルに対し、動作モデルの中間形（インタプリタと称することがある）の情報を生成する。動作モデルの中間形は、動作モデル状態（例えば、操作対象であるサーバやリソースの状態）を管理するための情報であり、ワークフロー２０に関して動作モデル状態管理テーブル１１６に登録される初期情報である。
【０２０４】
（Ｓ３）制御部１３０は、ワークフロー管理テーブル１１１を参照して、ワークフロー２０において、実行する運用操作部品が存在するか否かを判定する。実行する運用操作部品が存在する場合、処理をステップＳ４に進める。実行する運用操作部品が存在しない場合、処理を終了する。当該判定は、現在着目している運用操作部品に対して行われる。例えば、最初にステップＳ３を実行する際に判定対象となる運用操作部品は、“Ｓｔａｒｔ”に相当する運用操作部品であり、次にステップＳ３を実行する際に判定対象となる運用操作部品は運用操作部品２１となる。なお、判定対象の運用操作部品が“Ｓｔａｒｔ”に相当する運用操作部品である場合は、以下のステップＳ４〜Ｓ７をスキップして、ステップＳ８を実行してよい。
【０２０５】
（Ｓ４）制御部１３０は、該当の運用操作部品について、操作対象であるサーバおよびリソースの状態を取得し、サーバ状態管理テーブル１１９およびリソース状態管理テーブル１２０により管理されるサーバおよびリソースの状態を更新する。
【０２０６】
（Ｓ５）制御部１３０は、サーバ状態管理テーブル１１９およびリソース状態管理テーブル１２０のサーバおよびリソースの状態の更新結果に基づいて、動作モデルの情報を更新する。具体的には、制御部１３０は、動作モデル状態管理テーブル１１６のサーバ状態およびリソース状態の設定値を更新する。
【０２０７】
（Ｓ６）制御部１３０は、動作モデル状態管理テーブル１１６、並列実行判断基準定義テーブル１１８およびサブ基準定義テーブル１１８ａに基づいて、次に実行する運用操作部品と当該運用操作部品に後続する運用操作部品との並列実行可能性を算出する。
【０２０８】
（Ｓ７）実行部１４０は、ステップＳ６の並列実行可能性の算出結果に基づいて、運用操作部品の直列実行または並列実行を行う。
（Ｓ８）制御部１３０は、ワークフロー２０における次の運用操作部品へ移動する。そして、処理をステップＳ３に進める。なお、現在の運用操作部品が“Ｅｎｄ”に相当する運用操作部品の場合、次の運用操作部品は存在しないことになる。この場合、制御部１３０は、ステップＳ３へ処理を進め、ステップＳ３を実行する。その結果、ステップＳ３において実行する運用操作部品が存在しないと判定され、ワークフロー２０の実行が完了することになる。
【０２０９】
なお、ステップＳ１では、実行対象のワークフロー２０の指定を受け付けることになる。制御部１３０は、当該指定を受け付けた際に、インスタンス管理テーブル１１４、サーバ状態管理テーブル１１９およびリソース状態管理テーブル１２０に、ワークフロー２０の新規インスタンスの実行を管理するためのレコードを追加する。
【０２１０】
図２５は、動作モデル選定例を示すフローチャートである。以下、図２５に示す処理をステップ番号に沿って説明する。以下の手順は、図２４のステップＳ１に相当する。
（Ｓ１１）制御部１３０は、ワークフロー管理テーブル１１１を参照して、ワークフロー２０について、運用操作部品が存在するか否かを判定する。運用操作部品が存在する場合、処理をステップＳ１２に進める。運用操作部品が存在しない場合、処理を終了する。当該判定は、現在着目している運用操作部品に対して行われる。例えば、最初に判定対象となる運用操作部品は、“Ｓｔａｒｔ”に相当する運用操作部品であり、次にステップＳ１１を実行する際に判定対象となる運用操作部品は運用操作部品２１となる。図２５の説明において、ステップＳ１１で存在すると判断された運用操作部品を「着目する運用操作部品」と称する。
【０２１１】
（Ｓ１２）制御部１３０は、運用操作部品定義テーブル１１２を参照して、着目する運用操作部品の操作対象および操作内容を取得する。運用操作部品２１の例でいえば、操作対象“サーバ”、操作内容“操作”を取得する。“Ｓｔａｒｔ”や“Ｅｎｄ”に相当する運用操作部品については、操作対象や操作内容は設定なし“−”を取得する。
【０２１２】
（Ｓ１３）制御部１３０は、動作モデル定義テーブル１１５を参照して、ステップＳ１２で取得した操作対象および操作内容に対し、着目する運用操作部品の動作モデルを選定する。動作モデル定義テーブル１１５によれば、操作対象“サーバ”、操作内容“操作”に対応する動作モデルは“Ａ”である。よって、制御部１３０は、運用操作部品２１を動作モデル“Ａ”に区分する。なお、“Ｓｔａｒｔ”や“Ｅｎｄ”に相当する運用操作部品については、操作対象や操作内容が設定なしであり、動作モデルも設定なし“−”となる。
【０２１３】
（Ｓ１４）制御部１３０は、ステップＳ１３で選定した動作モデルをワークフロー管理テーブル１１１の該当の運用操作部品のレコードに格納する。例えば、運用操作部品２１（ワークフロー番号“１”、部品番号“１”）のレコードの動作モデルの項目に“Ａ”を格納する。なお、制御部１３０は、“Ｓｔａｒｔ”や“Ｅｎｄ”に相当する運用操作部品に対しては、動作モデルを設定なし“−”とする。
【０２１４】
（Ｓ１５）制御部１３０は、ワークフロー２０における次の運用操作部品へ移動する。そして、処理をステップＳ１１に進める。なお、現在着目する運用操作部品が“Ｅｎｄ”に相当する運用操作部品の場合、次の運用操作部品は存在しないことになる。この場合、制御部１３０は、ステップＳ１１へ処理を進め、ステップＳ１１を実行する。その結果、ステップＳ１１において運用操作部品が存在しないと判定され、ワークフロー２０の各運用操作部品に対する動作モデルの選定が完了する。
【０２１５】
図２６は、動作モデル選定の具体例を示す図である。例えば、制御部１３０は、ワークフロー２０に対して、図２５の動作モデル選定の手順を実行することで、運用操作部品２１，２２，２３，２４，２５，２６，２７それぞれの動作モデルを次のように決定する。
【０２１６】
運用操作部品２１の動作モデルは“Ａ”である。運用操作部品定義テーブル１１２によれば、運用操作部品２１（運用操作部品名“サーバの起動確認”）の操作対象は“サーバ”であり、操作内容は“操作”だからである。
【０２１７】
運用操作部品２２の動作モデルは“Ｂ”である。運用操作部品定義テーブル１１２によれば、運用操作部品２２（運用操作部品名“サーバの起動確認”）の操作対象は“サーバ”であり、操作内容は“参照”だからである。
【０２１８】
運用操作部品２３の動作モデルは“Ｄ”である。運用操作部品定義テーブル１１２によれば、運用操作部品２３（運用操作部品名“サービスの起動確認”）の操作対象は“リソース”であり、操作内容は“参照”だからである。
【０２１９】
運用操作部品２４の動作モデルは“Ｃ”である。運用操作部品定義テーブル１１２によれば、運用操作部品２４（運用操作部品名“アカウントの作成”）の操作対象は“リソース”であり、操作内容は“操作”だからである。
【０２２０】
運用操作部品２５の動作モデルは“Ｄ”である。運用操作部品定義テーブル１１２によれば、運用操作部品２５（運用操作部品名“アカウントの情報取得”）の操作対象は“リソース”であり、操作内容は“参照”だからである。
【０２２１】
運用操作部品２６の動作モデルは“Ｄ”である。運用操作部品定義テーブル１１２によれば、運用操作部品２６（運用操作部品名“アカウントのホームディレクトリ確認”）の操作対象は“リソース”であり、操作内容は“参照”だからである。
【０２２２】
運用操作部品２７の動作モデルは“Ｃ”である。運用操作部品定義テーブル１１２によれば、運用操作部品２７（運用操作部品名“ユーザによるログイン”）の操作対象は“リソース”であり、操作内容は“操作”だからである。
【０２２３】
なお、ワークフロー２０における“Ｓｔａｒｔ”や“Ｅｎｄ”に相当する運用操作部品については、前述のように動作モデルは設定なし“−”となる。
図２７は、動作モデルの中間形生成例を示すフローチャートである。以下、図２７に示す処理をステップ番号に沿って説明する。以下の手順は、図２４のステップＳ２に相当する。
【０２２４】
（Ｓ２１）制御部１３０は、ワークフロー管理テーブル１１１を参照して、ワークフロー２０について、運用操作部品が存在するか否かを判定する。運用操作部品が存在する場合、処理をステップＳ２２に進める。運用操作部品が存在しない場合、処理を終了する。当該判定は、現在着目している運用操作部品に対して行われる。例えば、最初に判定対象となる運用操作部品は、“Ｓｔａｒｔ”に相当する運用操作部品であり、次にステップＳ２１を実行する際に判定対象となる運用操作部品は運用操作部品２１となる。図２７（および後述の図２８）の説明において、ステップＳ２１で存在すると判断された運用操作部品を「着目する運用操作部品」と称する。
【０２２５】
（Ｓ２２）制御部１３０は、着目する運用操作部品に対して、動作モデルの中間形の生成を行う。すなわち、制御部１３０は、当該運用操作部品に対するレコードを生成し、動作モデル状態管理テーブル１１６に登録する。詳細は後述される。
【０２２６】
（Ｓ２３）制御部１３０は、ワークフロー２０における次の運用操作部品へ移動する。そして、処理をステップＳ２１に進める。なお、現在着目する運用操作部品が“Ｅｎｄ”に相当する運用操作部品の場合、次の運用操作部品は存在しないことになる。この場合、制御部１３０は、ステップＳ２１へ処理を進め、ステップＳ２１を実行する。その結果、ステップＳ２１において運用操作部品が存在しないと判定され、ワークフロー２０の各運用操作部品に対する中間形の生成が完了する。
【０２２７】
図２８は、動作モデルの中間形生成（詳細）例を示すフローチャートである。以下、図２８に示す処理をステップ番号に沿って説明する。以下の手順は、図２７のステップＳ２２に相当する。
【０２２８】
（Ｓ３１）制御部１３０は、ワークフロー管理テーブル１１１を参照して、着目する運用操作部品に対して選定した動作モデルの情報を取得する。制御部１３０は、取得した動作モデルの情報を格納するためのレコードを動作モデル状態管理テーブル１１６に新たに作成し、当該動作モデルの情報を格納する。例えば、着目する運用操作部品が運用操作部品２１である場合、制御部１３０は、ワークフロー管理テーブル１１１から動作モデル“Ａ”を取得する。制御部１３０は、運用操作部品２１に対応するレコード（インスタンス番号“１”、ワークフロー番号“１”、部品番号“１”）を動作モデル状態管理テーブル１１６に作成し、当該レコードに動作モデル“Ａ”を格納する。制御部１３０は、当該レコードにおいて、改善後の次の部品番号の初期値を、ワークフロー管理テーブル１１１における当該運用操作部品２１の次の部品番号の設定値“２”とする。
【０２２９】
（Ｓ３２）制御部１３０は、ワークフロー管理テーブル１１１および変数管理テーブル１１３を参照して、着目する運用操作部品に対し、動作モデル状態管理テーブル１１６の“サーバ名”に格納する値を取得する。例えば、着目する運用操作部品が運用操作部品２１である場合、制御部１３０は、ワークフロー管理テーブル１１１からサーバ名に相当する変数名が“変数１”であると特定する。そして、制御部１３０は、変数管理テーブル１１３を参照して、“変数１”に対応する変数値が“Ｘ”であると特定する。なお、ワークフローによっては、着目する運用操作部品の操作対象のサーバ名が、この段階では確定しておらず、変数管理テーブル１１３の該当の変数値が設定なし“−”のこともある。ワークフローの実行段階で運用操作部品の実行に伴って、操作対象のサーバ名が確定されることもあるからである。
【０２３０】
（Ｓ３３）制御部１３０は、サーバ名が確定しているか否かを判定する。サーバ名が確定している場合、処理をステップＳ３４に進める。サーバ名が確定していない場合、処理をステップＳ４０に進める。ステップＳ３２において、変数管理テーブル１１３のサーバ名に相当する変数（例えば、“変数１”など）に何らかの変数値（例えば、“Ｘ”など）が設定されていればサーバ名が確定している。変数管理テーブル１１３において、サーバ名に相当する変数が設定なし“−”であれば、サーバ名が確定していない。
【０２３１】
（Ｓ３４）制御部１３０は、ステップＳ３２で取得したサーバ名を、動作モデル状態管理テーブル１１６の着目する運用操作部品のレコードに格納する。例えば、着目する運用操作部品が、運用操作部品２１であれば、動作モデル状態管理テーブル１１６の運用操作部品２１のレコードに、サーバ名“Ｘ”を格納する。
【０２３２】
（Ｓ３５）制御部１３０は、ステップＳ３１で取得した動作モデルに基づいて、着目する運用操作部品の操作対象がリソースであるか否かを判定する。リソースでない場合、処理をステップＳ３６に進める。リソースである場合、処理をステップＳ３７に進める。例えば、着目する運用操作部品が運用操作部品２１であれば、動作モデル“Ａ”であり、操作対象はサーバなので、本ステップはＮｏとなる（処理をステップＳ３６に進める）。一方、例えば、着目する運用操作部品が運用操作部品２３であれば、動作モデル“Ｄ”であり、操作対象はリソースなので、本ステップはＹｅｓとなる（処理をステップＳ３７に進める）。
【０２３３】
（Ｓ３６）制御部１３０は、動作モデル状態管理テーブル１１６の着目する運用操作部品について、リソース名、リソース種別、リソース状態に、不使用を示す値“−”を格納する。操作対象がリソースでなければ（操作対象がサーバであれば）、並列実行可能性の判断にリソースの情報は利用されないからである。そして、処理をステップＳ４０に進める。
【０２３４】
（Ｓ３７）制御部１３０は、ワークフロー管理テーブル１１１、運用操作部品定義テーブル１１２および変数管理テーブル１１３を参照して、着目する運用操作部品に対し、動作モデル状態管理テーブル１１６の“リソース名”および“リソース種別”に格納する値を取得する。例えば、着目する運用操作部品が運用操作部品２３である場合、制御部１３０は、ワークフロー管理テーブル１１１からリソース名に相当する変数名が“変数２”であると特定する。そして、制御部１３０は、変数管理テーブル１１３を参照して、“変数２”に対応する変数値が“Ｓ”であると特定する。また、この場合、制御部１３０は、運用操作部品定義テーブル１１２から運用操作部品２３（“サービスの起動確認”）におけるリソース種別が“Ｓｅｒｖｉｃｅ．Ａｃｃｏｕｎｔ”であると特定する。なお、ステップＳ３２と同様に、ワークフローによっては、着目する運用操作部品の操作対象のリソース名が、この段階では確定しておらず、変数管理テーブル１１３の該当の変数値が設定なし“−”のこともある。ワークフローの実行段階でワークフローの運用操作部品の実行に伴って、動作モデル状態管理テーブル１１６の各運用操作部品についてリソース名が確定されることもあるからである。そして、処理をステップＳ３８に進める。
【０２３５】
（Ｓ３８）制御部１３０は、リソース名が確定しているか否かを判定する。リソース名が確定している場合、処理をステップＳ３９に進める。リソース名が確定していない場合、処理をステップＳ４０に進める。ステップＳ３７において、変数管理テーブル１１３のリソース名に相当する変数（例えば、“変数２”など）に何らかの変数値（例えば、“Ｙ”など）が設定されていればリソース名が確定している。変数管理テーブル１１３において、リソース名に相当する変数が設定なし“−”であれば、サーバ名が確定していない。
【０２３６】
（Ｓ３９）制御部１３０は、ステップＳ３７で取得したリソース名およびリソース種別を、動作モデル状態管理テーブル１１６の着目する運用操作部品のレコードに格納する。例えば、着目する運用操作部品が運用操作部品２３であれば、動作モデル状態管理テーブル１１６の運用操作部品２３のレコードに、リソース名“Ｓ”、リソース種別“Ｓｅｒｖｉｃｅ．Ａｃｃｏｕｎｔ”を格納する。
【０２３７】
（Ｓ４０）制御部１３０は、動作モデル状態管理テーブル１１６において、動作モデルで値が未確定の箇所に“不定”の値を格納する。例えば、着目する運用操作部品が運用操作部品２１である場合、この段階ではサーバ状態が未確定である。したがって、動作モデル状態管理テーブル１１６の運用操作部品２１のレコードにおいて、サーバ状態を“不定”とする。前述のように、サーバ名が未確定の場合もあり、その場合はサーバ名も“不定”とする。また、例えば、着目する運用操作部品が運用操作部品２３である場合、この段階ではリソース状態が未確定である。したがって、動作モデル状態管理テーブル１１６の運用操作部品２３のレコードにおいて、リソース状態を“不定”とする。前述のように、リソース名が未確定の場合は、リソース名も“不定”とする。制御部１３０は、“Ｓｔａｒｔ”や“Ｅｎｄ”に相当する運用操作部品については、動作モデル状態管理テーブル１１６のサーバやリソースに関する項目を設定なし“−”のままとする。
【０２３８】
なお、ステップＳ３２，Ｓ３３，Ｓ３７，Ｓ３８の説明では、サーバ名およびリソース名が未確定の場合もある旨を説明した。その場合、各ステップでも説明したように、該当のワークフローに含まれる各運用操作部品の実行に伴って、変数管理テーブル１１３に変数値が設定されていくことになる。
【０２３９】
図２９は、動作モデルの中間形生成の具体例を示す図である。制御部１３０は、ワークフロー２０に対し、図２８の手順により中間形２１ａ，２２ａ，２３ａ，２４ａ，２５ａ，２６ａ，２７ａを生成する。
【０２４０】
中間形２１ａは、運用操作部品２１（動作モデルＡ：サーバ操作）に対する中間形である。ワークフロー管理テーブル１１１および変数管理テーブル１１３によれば、運用操作部品２１（運用操作部品名“ＯＳ再起動”）ではサーバ名“Ｘ”が確定している。また、中間形２１ａの生成段階では、サーバ状態は未確定である。このため、中間形２１ａでは、サーバ名“Ｘ”、サーバ状態“不定”となる。動作モデルＡは、操作対象がサーバなので、リソースに関する項目（リソース名、リソース種別およびリソース状態）は、不使用を示す“−”となる。
【０２４１】
中間形２２ａは、運用操作部品２２（動作モデルＢ：サーバ参照）に対する中間形である。ワークフロー管理テーブル１１１および変数管理テーブル１１３によれば、運用操作部品２２（運用操作部品名“サーバの起動確認”）ではサーバ名“Ｘ”が確定している。また、中間形２２ａの生成段階では、サーバ状態は未確定である。このため、中間形２２ａでは、サーバ名“Ｘ”、サーバ状態“不定”となる。動作モデルＢは、操作対象がサーバなので、リソースに関する項目は、不使用を示す“−”となる。
【０２４２】
中間形２３ａは、運用操作部品２３（動作モデルＤ：リソース参照）に対する中間形である。ワークフロー管理テーブル１１１および変数管理テーブル１１３によれば、運用操作部品２３（運用操作部品名“サービスの起動確認”）ではサーバ名“Ｘ”およびリソース名“Ｓ”が確定している。また、運用操作部品定義テーブル１１２によれば、運用操作部品２３では対象の種別（リソース種別）が“Ｓｅｒｖｉｃｅ．Ａｃｃｏｕｎｔ”である。更に、中間形２３ａの生成段階では、サーバ状態およびリソース状態は未確定である。このため、中間形２３ａでは、サーバ名“Ｘ”、サーバ状態“不定”、リソース名“Ｓ”、リソース種別“Ｓｅｒｖｉｃｅ．Ａｃｃｏｕｎｔ”、リソース状態“不定”となる。
【０２４３】
中間形２４ａは、運用操作部品２４（動作モデルＣ：リソース操作）に対する中間形である。ワークフロー管理テーブル１１１および変数管理テーブル１１３によれば、運用操作部品２４（運用操作部品名“アカウントの作成”）では、サーバ名“Ｘ”およびリソース名“Ａｃ”が確定している。また、運用操作部品定義テーブル１１２によれば、運用操作部品２４では対象の種別（リソース種別）が“Ａｃｃｏｕｎｔ”である。更に、中間形２４ａの生成段階では、サーバ状態およびリソース状態は未確定である。このため、中間形２４ａでは、サーバ名“Ｘ”、サーバ状態“不定”、リソース名“Ａｃ”、リソース種別“Ａｃｃｏｕｎｔ”、リソース状態“不定”となる。
【０２４４】
中間形２５ａは、運用操作部品２５（動作モデルＤ：リソース参照）に対する中間形である。ワークフロー管理テーブル１１１および変数管理テーブル１１３によれば、運用操作部品２５（運用操作部品名“アカウントの情報取得”）では、サーバ名“Ｘ”およびリソース名“Ａｃ”が確定している。また、運用操作部品定義テーブル１１２によれば、運用操作部品２５では対象の種別（リソース種別）が“Ａｃｃｏｕｎｔ”である。更に、中間形２５ａの生成段階では、サーバ状態およびリソース状態は未確定である。このため、中間形２５ａでは、サーバ名“Ｘ”、サーバ状態“不定”、リソース名“Ａｃ”、リソース種別“Ａｃｃｏｕｎｔ”、リソース状態“不定”となる。
【０２４５】
中間形２６ａは、運用操作部品２６（動作モデルＤ：リソース参照）に対する中間形である。ワークフロー管理テーブル１１１および変数管理テーブル１１３によれば、運用操作部品２６（運用操作部品名“アカウントのホームディレクトリ確認”）では、サーバ名“Ｘ”およびリソース名“Ａｃ”が確定している。また、運用操作部品定義テーブル１１２によれば、運用操作部品２６では対象の種別（リソース種別）が“Ａｃｃｏｕｎｔ”である。更に、中間形２６ａの生成段階では、サーバ状態およびリソース状態は未確定である。このため、中間形２６ａでは、サーバ名“Ｘ”、サーバ状態“不定”、リソース名“Ａｃ”、リソース種別“Ａｃｃｏｕｎｔ”、リソース状態“不定”となる。
【０２４６】
中間形２７ａは、運用操作部品２７（動作モデルＣ：リソース操作）に対する中間形である。ワークフロー管理テーブル１１１および変数管理テーブル１１３によれば、運用操作部品２７（運用操作部品名“ユーザによるログイン”）では、サーバ名“Ｘ”およびリソース名“Ａｃ”が確定している。また、運用操作部品定義テーブル１１２によれば、運用操作部品２７では対象の種別（リソース種別）が“Ａｃｃｏｕｎｔ”である。更に、中間形２７ａの生成段階では、サーバ状態およびリソース状態は未確定である。このため、中間形２７ａでは、サーバ名“Ｘ”、サーバ状態“不定”、リソース名“Ａｃ”、リソース種別“Ａｃｃｏｕｎｔ”、リソース状態“不定”となる。
【０２４７】
図３０は、中間形生成後の動作モデル状態管理テーブルの例を示す図である。動作モデル状態管理テーブル１１６ｂは、図２９で例示した中間形の情報の例である。このように、制御部１３０は、各運用操作部品の中間形の情報を生成し、動作モデル状態管理テーブル１１６ｂに登録する。制御部１３０は、ワークフロー２０の実行に伴って動的に変更する操作対象の状態を、中間形の情報を基に管理する。なお、“Ｓｔａｒｔ”または“Ｅｎｄ”に相当する運用操作部品については、リソース名、リソース種別、リソース状態、サーバ名、サーバ状態および動作モデルの項目は、設定なし“−”となる。
【０２４８】
図３１は、サーバおよびリソースの状態更新例を示すフローチャートである。以下、図３１に示す処理をステップ番号に沿って説明する。以下の手順は、図２４のステップＳ４に相当する。
【０２４９】
（Ｓ４１）制御部１３０は、ワークフロー２０（インスタンス番号“１”）の現在位置を取得する。具体的には、制御部１３０は、インスタンス管理テーブル１１４におけるインスタンス番号“１”のレコードの現在の部品番号が、ワークフロー２０の現在位置である。前述のように、インスタンス管理テーブル１１４の現在の部品番号の項目には、次に実行する運用操作部品の部品番号が登録されている。
【０２５０】
（Ｓ４２）制御部１３０は、直前に実行した運用操作部品の情報を取得する。例えば、現在の運用操作部品（現在位置）が運用操作部品２１の場合、直前に実行した運用操作部品は、“Ｓｔａｒｔ”に相当する運用操作部品である。また、例えば、現在の運用操作部品（現在位置）が運用操作部品２２の場合、直前に実行した運用操作部品は運用操作部品２１である。なお、直前に実行した運用操作部品が“Ｓｔａｒｔ”に相当する運用操作部品である場合、制御部１３０は、例外的に本状態更新の処理を終了する。
【０２５１】
（Ｓ４３）制御部１３０は、直前に実行した運用操作部品がサーバへの操作であるか否かを判定する。サーバへの操作である場合、処理をステップＳ４４に進める。サーバへの操作でない場合、処理をステップＳ４７に進める。具体的には、直前に実行した運用操作部品が動作モデルＡに区分される場合、当該運用操作部品はサーバへの操作である。また、直前に実行した運用操作部品が動作モデルＡ以外に区分される場合、当該運用操作部品はサーバへの操作ではない。
【０２５２】
（Ｓ４４）制御部１３０は、サーバ状態管理テーブル１１９を参照して、直前に実行した運用操作部品による操作対象のサーバの現在の状態を取得する。すなわち、制御部１３０は、直前に実行した運用操作部品による操作対象のサーバについて、サーバ状態管理テーブル１１９に現在設定されている状態を取得する。例えば、直前に実行した運用操作部品が運用操作部品２１である場合、ワークフロー管理テーブル１１１によれば、サーバ名に相当する変数が“変数１”である。変数管理テーブル１１３によれば“変数１”の変数値は“Ｘ”である。よって、制御部１３０は、直前に実行した運用操作部品２１による操作対象のサーバの現在の状態として、サーバ状態管理テーブル１１９のインスタンス番号“１”かつサーバ名“Ｘ”のレコードに設定された状態を取得する。
【０２５３】
（Ｓ４５）制御部１３０は、状態遷移定義テーブル１１７を参照して、直前に実行した運用操作部品による操作対象のサーバの状態変化情報を取得する。例えば、直前に実行した運用操作部品が運用操作部品２１（運用操作部品名“ＯＳ再起動”）である場合、状態遷移定義テーブル１１７によれば、２種類の状態変化情報が登録されている。１つ目は、操作前のサーバ状態“ＯＮ”から操作後のサーバ状態“不定”へ遷移するという状態遷移を示す。２つ目は、操作前のサーバ状態“不定”から操作後のサーバ状態“不定”へ遷移するという状態遷移を示す。
【０２５４】
（Ｓ４６）制御部１３０は、操作対象のサーバの状態を更新する。具体的には、制御部１３０は、ステップＳ４５で取得した状態変化情報に対し、ステップＳ４４で取得した現在の状態を、操作前のサーバ状態にあてはめて、操作後のサーバ状態を得る。上記の運用操作部品２１の例でいえば、ステップＳ４４で取得される状態が“ＯＮ”または“不定”の何れであっても、操作後のサーバ状態は“不定”であるので、操作後のサーバ状態は“不定”である。ただし、操作前のサーバ状態に応じて操作後のサーバ状態が異なることもある。その場合、制御部１３０は、操作前のサーバ状態に応じて操作後のサーバ状態を選択することになる。制御部１３０は、取得した操作後のサーバ状態をサーバ状態管理テーブル１１９に登録する。運用操作部品２１の例によれば、サーバ状態管理テーブル１１９のインスタンス番号“１”かつサーバ名“Ｘ”のレコードの状態が更新される（この場合、操作前のサーバ状態が“不定”であれば、操作後も“不定”のままになる）。これにより、直前に実行した運用操作部品の実行後における、操作対象のサーバの状態が、サーバ状態管理テーブル１１９に反映されることになる。そして、処理を終了する。
【０２５５】
（Ｓ４７）制御部１３０は、リソース状態管理テーブル１２０を参照して、直前に実行した運用操作部品による操作対象のリソースの現在の状態を取得する。すなわち、制御部１３０は、直前に実行した運用操作部品による操作対象のリソースについて、リソース状態管理テーブル１２０に現在設定されている状態を取得する。例えば、直前に実行した運用操作部品が運用操作部品２３である場合、ワークフロー管理テーブル１１１によれば、サーバ名に相当する変数が“変数１”であり、リソース名に相当する変数が“変数２”である。変数管理テーブル１１３によれば、“変数１”の変数値は“Ｘ”であり、“変数２”の変数値は“Ｓ”である。よって、制御部１３０は、直前に実行した運用操作部品２３による操作対象のリソースの現在の状態として、リソース状態管理テーブル１２０のインスタンス番号“１”、サーバ名“Ｘ”かつリソース名“Ｓ”のレコードに設定された状態を取得する。
【０２５６】
（Ｓ４８）制御部１３０は、状態遷移定義テーブル１１７を参照して、直前に実行した運用操作部品による操作対象のリソースの状態変化情報を取得する。例えば、直前に実行した運用操作部品が運用操作部品２３（運用操作部品名“サービスの起動確認”）である場合、状態遷移定義テーブル１１７によれば、２種類の状態変化情報が登録されている。１つ目は、操作前のリソース状態“Ｓｔａｒｔ”から操作後のリソース状態“Ｓｔａｒｔ”へ遷移するという情報遷移を示す。２つ目は、操作前のリソース状態“不定”から操作後のリソース状態“Ｓｔａｒｔ”へ遷移するという状態遷移を示す。
【０２５７】
（Ｓ４９）制御部１３０は、操作対象のリソースの状態を更新する。具体的には、制御部１３０は、ステップＳ４８で取得した状態変化情報に対し、ステップＳ４７で取得した現在の状態を、操作前のリソース状態にあてはめて、操作後のリソース状態を得る。上記の運用操作部品２３の例でいえば、ステップＳ４７で取得される状態が“Ｓｔａｒｔ”または“不定”の何れであっても、操作後のリソース状態は“Ｓｔａｒｔ”である。ただし、操作前のリソース状態に応じて操作後のリソース状態が異なることもある。その場合、制御部１３０は、操作前のリソース状態に応じて操作後のリソース状態を選択することになる。制御部１３０は、取得した操作後のリソース状態をリソース状態管理テーブル１２０に登録する。運用操作部品２３の例によれば、リソース状態管理テーブル１２０のインスタンス番号“１”、サーバ名“Ｘ”かつリソース名“Ｓ”のレコードの状態が更新される（この場合、操作前のサーバ状態が“Ｓｔａｒｔ”であれば、操作後も“Ｓｔａｒｔ”のままになる）。これにより、直前に実行した運用操作部品の実行後における、操作対象のリソースの状態が、リソース状態管理テーブル１２０に反映されることになる。そして、処理を終了する。
【０２５８】
図３２は、動作モデル更新例を示すフローチャートである。以下、図３２に示す処理をステップ番号に沿って説明する。以下の手順は、図２４のステップＳ５に相当する。
（Ｓ５１）制御部１３０は、ワークフロー管理テーブル１１１を参照して、ワークフロー２０について、次に実行する運用操作部品以降の運用操作部品（未実行の運用操作部品）が存在するか否かを判定する。当該運用操作部品が存在する場合、処理をステップＳ５２に進める。当該運用操作部品が存在しない場合、処理を終了する。例えば、直前の運用操作部品（例えば、“Ｓｔａｒｔ”に相当する運用操作部品）の後、最初に判定対象となる運用操作部品は、次に実行する運用操作部品（例えば、運用操作部品２１）である。その次にステップＳ５１を実行する際に判定対象となる運用操作部品は、その次に実行する運用操作部品（例えば、運用操作部品２２）である。図３２の説明において、ステップＳ５１で存在すると判断された運用操作部品を「着目する運用操作部品」と称する。なお、次に処理対象とする運用操作部品が“Ｅｎｄ”に相当する運用操作部品の場合、以降の処理を行わなくてよいので、処理を終了する。
【０２５９】
（Ｓ５２）制御部１３０は、動作モデル状態管理テーブル１１６から動作モデルを取得する。例えば、着目する運用操作部品が、運用操作部品２１であれば、運用操作部品２１に対応する動作モデル“Ａ”のレコード（インスタンス番号“１”、ワークフロー番号“１”、部品番号“１”のレコード）を動作モデル状態管理テーブル１１６から取得する。
【０２６０】
（Ｓ５３）制御部１３０は、ワークフロー管理テーブル１１１および変数管理テーブル１１３に基づいてサーバ名が確定しているか否かを判定する。サーバ名が確定している場合、処理をステップＳ５４に進める。サーバ名が確定していない場合、処理をステップＳ５１に進める。例えば、着目する運用操作部品が運用操作部品２１（運用操作部品名“サーバの再起動”）である場合、ワークフロー管理テーブル１１１によればサーバ名を示す変数が“変数１”である。変数管理テーブル１１３では“変数１”に対して変数値“Ｘ”が設定されている。この場合、サーバ名が確定していることになる。このとき、ステップＳ５２で取得した動作モデル状態管理テーブル１１６のレコードにおいて、サーバ名が不定であれば、変数管理テーブル１１３で特定した変数値をサーバ名に設定する（ワークフローの実行によりサーバ名が確定したことになる）。他方、変数管理テーブル１１３で該当の変数に対する変数値が不定であれば、サーバ名が確定していない。
【０２６１】
（Ｓ５４）制御部１３０は、サーバ状態管理テーブル１１９を参照して、ステップＳ５３で特定したサーバ名に対応する状態を取得する。
（Ｓ５５）制御部１３０は、動作モデル状態管理テーブル１１６におけるステップＳ５２で取得したレコードのサーバ状態の項目に、ステップＳ５４で取得した状態を設定する。これにより、動作モデル状態管理テーブル１１６において、操作対象のサーバの状態が更新される。
【０２６２】
（Ｓ５６）制御部１３０は、着目する運用操作部品の操作対象がリソースであるか否かを判定する。操作対象がリソースである場合、処理をステップＳ５７に進める。操作対象がリソースでない場合、処理をステップＳ５１に進める。着目する運用操作部品の動作モデルが“Ａ”、“Ｂ”であれば、操作対象はリソースではない。着目する運用操作部品の動作モデルが“Ｃ”、“Ｄ”であれば、操作対象はリソースである。
【０２６３】
（Ｓ５７）制御部１３０は、ワークフロー管理テーブル１１１および運用操作部品定義テーブル１１２を参照して、リソース名およびリソース種別に格納する値を取得する。例えば、着目する運用操作部品が運用操作部品２３（運用操作部品名“サービスの起動確認”）である場合、ワークフロー管理テーブル１１１によればリソース名を示す変数が“変数２”である。変数管理テーブル１１３では“変数２”に対して変数値“Ｓ”が設定されている。また、運用操作部品定義テーブル１１２によれば、運用操作部品２３の操作対象のリソース種別は“Ｓｅｒｖｉｃｅ．Ａｃｃｏｕｎｔ”である。
【０２６４】
（Ｓ５８）制御部１３０は、ステップＳ５７の取得結果に基づいて、リソース名が確定しているか否かを判定する。リソース名が確定している場合、処理をステップＳ５９に進める。リソース名が確定していない場合、処理をステップＳ５１に進める。例えば、ステップＳ５７で例示したように、リソース名を変数管理テーブル１１３から取得できる場合、リソース名が確定していることになる。このとき、ステップＳ５２で取得した動作モデル状態管理テーブル１１６のレコードにおいて、リソース名が不定であれば、変数管理テーブル１１３で特定した変数値をリソース名に設定する（ワークフローの実行によりリソース名が確定したことになる）。他方、変数管理テーブル１１３で該当の変数に対する変数値が不定であれば、リソース名が確定していない。
【０２６５】
（Ｓ５９）制御部１３０は、リソース状態管理テーブル１２０を参照して、ステップＳ５８で特定したリソース名に対応する状態を取得する。
（Ｓ６０）制御部１３０は、動作モデル状態管理テーブル１１６におけるステップＳ５２で取得したレコードのリソース状態の項目に、ステップＳ５９で取得した状態を設定する。これにより、動作モデル状態管理テーブル１１６において、操作対象のリソースの状態が更新される。
【０２６６】
（Ｓ６１）制御部１３０は、ワークフロー２０における次の運用操作部品へ移動する。そして、処理をステップＳ５１に進める。
図３２の手順により、次に実行する運用操作部品以降の運用操作部品に対して、動作モデル状態管理テーブル１１６のサーバ状態やリソース状態の設定値が更新される。
【０２６７】
図３３は、並列実行可能性の算出例を示すフローチャートである。以下、図３３に示す処理をステップ番号に沿って説明する。以下の手順は、図２４のステップＳ６に相当する。
【０２６８】
（Ｓ７１）制御部１３０は、ワークフロー２０（インスタンス番号“１”）の現在位置を取得する。具体的には、制御部１３０は、インスタンス管理テーブル１１４におけるインスタンス番号“１”のレコードの現在の部品番号が、ワークフロー２０の現在位置である。前述のように、インスタンス管理テーブル１１４の現在の部品番号の項目には、次に実行する運用操作部品の部品番号が登録されている。
【０２６９】
（Ｓ７２）制御部１３０は、次に実行する運用操作部品に対して後続の運用操作部品が存在するか否かを判定する。後続の運用操作部品が存在する場合、処理をステップＳ７３に進める。後続の運用操作部品が存在しない場合、制御部１３０は運用操作部品の実行を実行部１４０に指示して、処理を終了する。例えば、次に実行する運用操作部品が運用操作部品２１であれば、後続の運用操作部品は運用操作部品２２である。なお、次に実行する運用操作部品が“Ｅｎｄ”の場合、“Ｅｎｄ”に後続する運用操作部品は存在しないので、処理を終了する。
【０２７０】
（Ｓ７３）制御部１３０は、確認対象の動作モデルの情報を取得する。具体的には、制御部１３０は、次に実行する運用操作部品（例えば、運用操作部品２１）の動作モデル状態を動作モデル状態管理テーブル１１６から取得する。また、制御部１３０は、後続の運用操作部品（例えば、運用操作部品２１に対して運用操作部品２２）の動作モデル状態を動作モデル状態管理テーブル１１６から取得する。
【０２７１】
（Ｓ７４）制御部１３０は、並列実行判断基準定義テーブル１１８およびサブ基準定義テーブル１１８ａから、次に実行する運用操作部品と後続の運用操作部品との並列実行可能性の判断基準の定義情報（何れかのレコード）を取得する。判断基準の定義情報に当たり、制御部１３０は、両運用操作部品における操作対象のサーバ名、リソース名、リソース種別の異同の比較を行うことになる。サーバ名およびリソース名については、同一であるか異なるかを判断すればよい。リソース種別については、図９で例示したように次のように比較する。
【０２７２】
（１）両方の操作対象のリソース種別が属性とともに指定されている場合、両方のリソース種別の属性を比較し、同一であればリソース種別同一、異なればリソース種別相違となる。
【０２７３】
（２）一方の操作対象のリソース種別に属性が指定され、他方の操作対象で属性が指定されていない場合、一方で指定されたリソース種別の属性と、他方で指定されたリソース種別とを比較し、同一であればリソース種別同一、異なればリソース種別相違となる。
【０２７４】
（３）両方の操作対象のリソース種別に属性が指定されていない場合、両方で指定されたリソース種別を比較し、同一であればリソース種別同一、異なればリソース種別相違となる。
【０２７５】
（Ｓ７５）制御部１３０は、ステップＳ７４で取得した定義情報に基づいて、確認対象である各運用操作部品が並列実行可能か否かを算出する。例えば、次の運用操作部品が運用操作部品２４である場合、制御部１３０は、運用操作部品２４と後続の運用操作部品２５とを並列実行不可能と判断する。例えば、次の運用操作部品が運用操作部品２５である場合、制御部１３０は、運用操作部品２５と後続の運用操作部品２６とを並列実行可能と算出する。並列実行可能性の判断の具体例は後述される。
【０２７６】
（Ｓ７６）制御部１３０は、ステップＳ７５の算出結果から、確認対象の各運用操作部品が並列実行可能と算出されたか否かを判定する。並列実行可能と算出された場合、処理をステップＳ７７に進める。並列実行不可能と判定された場合、処理を終了する。
【０２７７】
（Ｓ７７）制御部１３０は、並列実行可能と判定された各運用操作部品に対して、ワークフロー２０の実行順序を更新する。具体的には、制御部１３０は、動作モデル状態管理テーブル１１６から直前に実行した運用操作部品のレコードを取得する。制御部１３０は、取得したレコードの改善後の次の部品番号に、次に実行する運用操作部品の部品番号と、ステップＳ７２で特定した後続の運用操作部品の部品番号とを登録する。例えば、次の運用操作部品が運用操作部品２５である場合、直前に実行した運用操作部品は運用操作部品２４であり、後続の運用操作部品は運用操作部品２６である。よって、制御部１３０は、動作モデル状態管理テーブル１１６の運用操作部品２４のレコードにおいて、改善後の次の部品番号に部品番号“５”（運用操作部品２５）および部品番号“６”（運用操作部品２６）を設定する。この場合、運用操作部品２５，２６が並列化されたことになる。
【０２７８】
（Ｓ７８）制御部１３０は、ワークフロー２０における次の運用操作部品へ移動する。そして、処理をステップＳ７２に進める。なお、ステップＳ７８における後続の運用操作部品が“Ｅｎｄ”に相当する運用操作部品の場合、後続の運用操作部品は存在しないことになる。この場合、制御部１３０は、ステップＳ７２へ処理を進め、ステップＳ７２を実行する。その結果、ステップＳ７２において後続の運用操作部品が存在しないと判定され、次に実行する運用操作部品に対する並列実行可能性の算出処理が完了する。
【０２７９】
図３３の手順によれば、制御部１３０は、次に実行する運用操作部品に対して、次に実行する運用操作部品と後続する複数の運用操作部品とを並列実行可能と判断することもある。例えば、ステップＳ７７で運用操作部品２５，２６を並列実行可能と判断した後、ステップＳ７２の実行時、制御部１３０は、後続する運用操作部品として運用操作部品２７を取得する。この場合、ステップＳ７３での確認対象は、運用操作部品２６，２７の組、および、運用操作部品２５，２７の組の２つの組である。ステップＳ７５の並列実行可能性の算出では、制御部１３０は、運用操作部品２６，２７が並列実行可能であり、かつ、運用操作部品２５，２７が並列実行可能である場合に、運用操作部品２５，２６，２７を並列実行可能と算出する。他方、制御部１３０は、運用操作部品２６，２７、または、運用操作部品２５，２７の少なくとも一方が並列実行不可能である場合に、運用操作部品２５，２６，２７を並列実行不可能と算出する。
【０２８０】
このように、制御部１３０は、第１の運用操作部品と、第１の運用操作部品に後続する第２の運用操作部品と、第２の運用操作部品に後続する第３の運用操作部品とがあり、第１および第２の運用操作部品が並列実行可能であるとき、第１および第３の運用操作部品の組、および、第２および第３の運用操作部品の組、の何れもが並列実行可能である場合に、第１，第２，第３の運用操作部品を並列実行可能であると判断する。
【０２８１】
図３４は、直列実行または並列実行の例を示すフローチャートである。以下、図３４に示す処理をステップ番号に沿って説明する。以下の手順は、図２４のステップＳ７に相当する。
【０２８２】
（Ｓ８１）実行部１４０は、動作モデル状態管理テーブル１１６において、直前に実行した運用操作部品の改善後の次の部品番号を参照することで、次に実行する運用操作部品を特定する。動作モデル状態管理テーブル１１６の例でいえば、直前に実行した運用操作部品が運用操作部品２２（インスタンス番号“１”、部品番号“２”）のとき、次に実行する運用操作部品は、運用操作部品２３である。また、直前に実行した運用操作部品が運用操作部品２４（インスタンス番号“１”、部品番号“４”）のとき、次に実行する運用操作部品は、運用操作部品２５，２６である。実行部１４０は、次に実行する運用操作部品の実行情報を取得する。実行情報は、運用操作部品による処理内容を示す情報である。例えば、実行情報は、操作対象に運用操作部品による処理（例えば、ＯＳ再起動やアカウント作成など）を実行させるためのコマンドの情報を含む。当該コマンドの情報は、運用操作部品名に対応付けて、記憶部１１０に予め格納される。また、実行情報は、変数管理テーブル１１３に登録された変数毎の変数値の情報を含む。
【０２８３】
（Ｓ８２）実行部１４０は、運用操作部品を並列実行するか否かを判定する。並列実行しない場合、処理をステップＳ８３に進める。並列実行する場合、処理をステップＳ８４に進める。例えば、実行部１４０は、ステップＳ８１で、次に実行する運用操作部品が１つであった場合、運用操作部品を並列実行しないと判定する。実行部１４０は、ステップＳ８２で、次に実行する運用操作部品が複数であった場合、運用操作部品を並列実行すると判定する。
【０２８４】
（Ｓ８３）実行部１４０は、運用操作部品を直列実行する。例えば、次に実行する運用操作部品が運用操作部品２３である場合、実行部１４０は、運用操作部品２３のみを実行する。実行部１４０による運用操作部品２３の実行により、運用操作部品２３に応じた処理の実行が操作対象のサーバ（例えば、業務サーバ２００など）に指示される。実行部１４０は、操作対象のサーバ（業務サーバ２００など）から、運用操作部品に応じた処理を完了した旨の通知を受け付けると、制御部１３０に該当の運用操作部品の実行が完了したことを通知する。制御部１３０は、インスタンス管理テーブル１１４において、現在の部品番号を更新する。例えば、運用操作部品２３（部品番号“３”）を実行完了したのであれば、インスタンス管理テーブル１１４の現在の部品番号を“３”から“４”に更新する。動作モデル状態管理テーブル１１６において、運用操作部品２３に対応する改善後の次の部品番号が“４”だからである。そして、処理を終了する。
【０２８５】
（Ｓ８４）実行部１４０は、運用操作部品を並列実行する。例えば、次に実行する運用操作部品が運用操作部品２５，２６である場合、実行部１４０は、運用操作部品２５，２６を並列に実行する。実行部１４０による運用操作部品２５，２６の実行により、運用操作部品２５，２６に応じた処理の実行が操作対象のサーバ（例えば、業務サーバ２００など）に指示される。実行部１４０は、操作対象のサーバ（業務サーバ２００など）から、並列実行対象の全ての運用操作部品に応じた処理を完了した旨の通知を受け付けると、制御部１３０に該当の運用操作部品の実行が完了したことを通知する。制御部１３０は、インスタンス管理テーブル１１４において、現在の部品番号を更新する。例えば、運用操作部品２５，２６（部品番号“５”、“６”）を実行完了したのであれば、インスタンス管理テーブル１１４の現在の部品番号を“５”から“７”に更新する。動作モデル状態管理テーブル１１６において、運用操作部品２５，２６に対応する改善後の次の部品番号が“７”だからである。
【０２８６】
このようにして、運用サーバ１００は、運用操作部品の実行を行う。なお、ステップＳ８３，Ｓ８４において、実行部１４０は、運用操作部品の実行結果に応じて、変数管理テーブル１１３に登録された変数名の変数値を新たに設定することもある。例えば、運用操作部品が、ある変数に設定する変数値を所定のファイルから取得する処理である場合もある。その場合、実行部１４０は、操作対象のサーバ（例えば、業務サーバ２００など）から当該変数値を取得し、変数管理テーブル１１３に設定することもできる。
【０２８７】
次に、第２の実施の形態で例示した判断基準による、ワークフロー２０に対する並列実行可能性の判断（図３３のステップＳ７５）の具体例を説明する。
図３５は、並列実行可能性の判断の第１の例を示す図である。制御部１３０は、運用操作部品２１の実行前に、運用操作部品２１，２２の並列実行可能性を判断する。先行の運用操作部品２１の動作モデルは“Ａ”である。後続の運用操作部品２２の動作モデルは“Ｂ”である。
【０２８８】
並列実行判断基準定義テーブル１１８によれば、先行の動作モデル“Ａ”および後続の動作モデル“Ｂ”に対応する判断基準は、番号“１”のレコードである。運用操作部品２１，２２では操作対象のサーバ名が“Ｘ”で同一であり、サーバ同一である。並列実行判断基準定義テーブル１１８の番号“１”のレコードは、サーバ同一の場合、並列実行不可能であることを示す。よって、制御部１３０は、運用操作部品２１，２２を並列実行不可能と判断する。
【０２８９】
図３６は、並列実行可能性の判断の第１の例（続き）を示す図である。図３５の例は、第１の判断基準３１によって、並列実行不可能と判断されたといえる。
すなわち、運用操作部品２１の“ＯＳ再起動”の実行前に各運用操作部品の操作対象の状態、および、操作対象と階層関係にある対象の状態を取得し、動作モデル状態を更新する。“ＯＳ再起動”の動作モデルと“サーバの起動確認”の動作モデルは、同一サーバに対する操作と参照の関係にある。よって、制御部１３０は、第１の判断基準３１に基づき、“ＯＳ再起動”の運用操作部品２１と、“サーバの起動確認”の運用操作部品２２とは並列実行不可能と判断する。
【０２９０】
実行部１４０は、制御部１３０による判断結果に基づいて、運用操作部品２１を直列実行する。運用操作部品２１は“ＯＳ再起動”である。状態遷移定義テーブル１１７によれば、運用操作部品２１の実行後のサーバ状態は“不定”となる。
【０２９１】
図３７は、並列実行可能性の判断の第２の例を示す図である。制御部１３０は、運用操作部品２１の実行後、運用操作部品２２を実行する直前に、運用操作部品２２，２３の並列実行可能性を判断する。先行の運用操作部品２２の動作モデルは“Ｂ”である。後続の運用操作部品２３の動作モデルは“Ｄ”である。
【０２９２】
並列実行判断基準定義テーブル１１８によれば、先行の動作モデル“Ｂ”および後続の動作モデル“Ｄ”に対応する判断基準は、番号“７”のレコードである。運用操作部品２２，２３では操作対象のサーバ名が“Ｘ”で同一であり、サーバ同一である。並列実行判断基準定義テーブル１１８の番号“７”のレコードは、サーバ同一の場合、サブ基準Ｊ２に従って並列実行可能性を判断することを示す。サブ基準定義テーブル１１８ａによれば、サブ基準Ｊ２は、操作対象のサーバの状態が“不定”の場合、並列実行不可能であることを示す。この段階において、操作対象のサーバの状態は“不定”である。よって、制御部１３０は、運用操作部品２２，２３を並列実行不可能と判断する。
【０２９３】
図３８は、並列実行可能性の判断の第２の例（続き）を示す図である。図３７の例は、第１の判断基準３１および第３の判断基準３３によって、並列実行不可能と判断されたといえる。
【０２９４】
すなわち、運用操作部品２１の実行により“ＯＳ再起動”が完了し、“サーバの起動確認”の実行前に再び各運用操作の状態、および、操作対象と階層関係にある対象の状態を取得し、動作モデル状態を更新する。この時点では、直前に実行した“ＯＳ再起動”により、操作対象であるサーバ状態が“不定”となっている。“サーバの起動確認”の動作モデルおよび“サービスの起動確認”の動作モデルについて、制御部１３０は、第１の判断基準３１から、対象サーバが同一であるため、動作モデル間で関係性（階層関係）があると判断し、操作対象の状態を確認する。操作対象のサーバ状態を確認すると、操作対象のサーバ状態が“不定”となっていることから、制御部１３０は、第３の判断基準に基づき、運用操作部品２２，２３を並列実行不可能と判断する。
【０２９５】
実行部１４０は、制御部１３０による判断結果に基づいて、運用操作部品２２を直列実行する。運用操作部品２２は“サーバの起動確認”である。状態遷移定義テーブル１１７によれば、運用操作部品２２の実行後のサーバ状態は“ＯＮ”となる。
【０２９６】
図３９は、並列実行可能性の判断の第３の例を示す図である。制御部１３０は、運用操作部品２２の実行後、運用操作部品２３の実行前に、運用操作部品２３，２４の並列実行可能性を判断する。先行の運用操作部品２３の動作モデルは“Ｄ”である。後続の運用操作部品２４の動作モデルは“Ｃ”である。
【０２９７】
並列実行判断基準定義テーブル１１８によれば、先行の動作モデル“Ｄ”および後続の動作モデル“Ｃ”に対応する判断基準は、番号“１４”のレコードである。運用操作部品２３，２４では操作対象のサーバ名が“Ｘ”で同一であり、サーバ同一である。また、操作対象のリソース名が、運用操作部品２３の“Ｓ”と運用操作部品２４の“Ａｃ”とで異なっている。更に、操作対象のリソースのリソース種別の属性とリソース種別とが、運用操作部品２３の“Ｓｅｒｖｉｃｅ．Ａｃｃｏｕｎｔ”と運用操作部品２４の“Ａｃｃｏｕｎｔ”とで同一（“Ａｃｃｏｕｎｔ”で同一）である。並列実行判断基準定義テーブル１１８の番号“１４”のレコードは、サーバ同一、リソース名相違、かつ、リソース種別同一の場合、サブ基準Ｊ４に従って並列実行可能性を判断することを示す。サブ基準定義テーブル１１８ａによれば、サブ基準Ｊ４は、操作対象のサーバおよびリソースの状態に応じた判断基準である。この段階において、サーバ状態は“ＯＮ”である。リソース状態は何れも“不定”である。サブ基準Ｊ４は、サーバ状態が“不定”以外であり、リソース状態が“不定”の場合、並列実行不可能であることを示す。よって、制御部１３０は、運用操作部品２３，２４を並列実行不可能と判断する。
【０２９８】
図４０は、並列実行可能性の判断の第３の例（続き）を示す図である。図３９の例は、第１の判断基準３１、第２の判断基準３２および第３の判断基準３３によって、並列実行不可能と判断されたといえる。
【０２９９】
すなわち、運用操作部品２２の実行により“サーバの起動確認”が完了し、“サービスの起動確認”の実行前に再び各運用操作部品の操作対象の状態、および操作対象と階層関係にある対象の状態を取得し、動作モデル状態を更新する。この時点では、直前に実行した“サーバの起動確認”により、操作対象と階層関係にある対象状態（サーバ状態）が“ＯＮ”となっている。“サービスの起動確認”の動作モデルと“アカウントの作成”の動作モデルとは、操作対象が同一サーバ上の異なるリソース名となっているため、第１の判断基準３１で示されるように、リソース間の関連性の有無を確認する。“サービスの起動確認”の動作モデルのリソース種別は“Ｓｅｒｖｉｃｅ．Ａｃｃｏｕｎｔ”であり、属性“Ａｃｃｏｕｎｔ”をもつ。制御部１３０は、第２の判断基準３２に基づき、当該属性と“アカウントの作成”の動作モデルのリソース種別“Ａｃｃｏｕｎｔ”とを比較し、同一と判断する。すなわち、運用操作部品２３，２４では操作対象のリソース間に関連性があると判断する。そこで、制御部１３０は、第３の判断基準３３に基づき、対象サーバと対象リソースの状態を確認する。前述のように、制御部１３０は、対象サーバの状態が“ＯＮ”、対象リソースの状態が何れも“不定”であるので、運用操作部品２３，２４を並列実行不可能と判断する。
【０３００】
実行部１４０は、制御部１３０による判断結果に基づいて、運用操作部品２３を直列実行する。状態遷移定義テーブル１１７によれば、運用操作部品２３の実行後のリソース名“Ｓ”、リソース種別“Ｓｅｒｖｉｃｅ．Ａｃｃｏｕｎｔ”のリソース状態は“ＳＴＡＲＴ”となる。
【０３０１】
運用操作部品２３の実行後、運用操作部品２４の実行前に、制御部１３０は、運用操作部品２４，２５の並列実行可能性を同様に判断する。この場合、制御部１３０は、上記と同様の手順により、並列実行判断基準定義テーブル１１８の番号“１１”のレコードに基づいて、運用操作部品２４，２５を並列実行不可能と判断する。運用操作部品２４，２５では、操作対象のサーバ名、リソース名およびリソース種別が全て同一だからである。
【０３０２】
実行部１４０は、制御部１３０による判断結果に基づいて、運用操作部品２４を直列実行する。状態遷移定義テーブル１１７によれば、運用操作部品２４の実行後のリソース名“Ａｃ”、リソース種別“Ａｃｃｏｕｎｔ”のリソース状態は“ＥＸＩＳＴ”となる（ただし、図１９では当該状態遷移のレコードの図示を省略している）。
【０３０３】
図４１は、並列実行可能性の判断の第４の例を示す図である。制御部１３０は、運用操作部品２４の実行後、運用操作部品２５を実行する前に、運用操作部品２５，２６の並列実行可能性を判断する。先行の運用操作部品２５の動作モデルは“Ｄ”である。後続の運用操作部品２６の動作モデルは“Ｄ”である。
【０３０４】
並列実行判断基準定義テーブル１１８によれば、先行の動作モデル“Ｄ”および後続の動作モデル”Ｄ”に対応する判断基準は、番号“１５”のレコードである。運用操作部品２５，２６では操作対象のサーバ名が“Ｘ”で同一であり、サーバ同一である。また、操作対象のリソース名が“Ａｃ”で同一であり、リソース同一である。更に、操作対象のリソースのリソース種別が“Ａｃｃｏｕｎｔ”で同一であり、リソース種別同一である。並列実行判断基準定義テーブル１１８の番号“１５”のレコードは、サーバ同一、リソース名同一、かつ、リソース種別同一の場合、サブ基準Ｊ４に従って並列実行可能性を判断することを示す。サブ基準定義テーブル１１８ａによれば、サブ基準Ｊ４は操作対象のサーバおよびリソースの状態に応じた判断基準である。この段階において、サーバ状態は“ＯＮ”である。リソース状態は“ＥＸＩＳＴ”である。サブ基準Ｊ４は、サーバ状態が“不定”以外であり、リソース状態が“不定”以外の場合、並列実行可能であることを示す。よって、制御部１３０は、運用操作部品２５，２６を並列実行可能と判断する。
【０３０５】
図４２は、並列実行可能性の判断の第４の例（続き）を示す図である。図４１の例は、第１の判断基準３１、第２の判断基準３２および第３の判断基準３３によって、並列実行可能と判断されたといえる。
【０３０６】
すなわち、運用操作部品２４の実行により“アカウントの作成”が完了し、“アカウントの情報取得”の実行前に再び各運用操作の操作対象の状態、および、操作対象と階層関係にある対象の状態を取得し、動作モデル状態を更新する。この時点において、“アカウントの情報取得”の動作モデルと“アカウントのホームディレクトリ確認”の動作モデルの構造から、互いに参照操作であるが、同一サーバ名である。このため、第１の判断基準３１に示す通り、制御部１３０は、対象リソースのリソース名とリソース種別（属性）および操作内容から、リソース間の関連性の有無を確認する。運用操作部品２５，２６では、対象のリソース名、および、リソース種別が同一であり、参照操作である。このため、第２の判断基準３２に示す通り、制御部１３０は、対象サーバと対象リソースの状態を更に確認する。対象サーバおよび対象リソースの状態を確認すると、操作対象であるサーバ状態が“ＯＮ”、リソース状態が“ＥＸＩＳＴ”である。第３の判断基準３３に示す通り、制御部１３０は、サーバ状態、および、リソース状態が“不定”ではないことから、運用操作部品２５，２６を並列実行可能と判断する。
【０３０７】
制御部１３０は、次に、運用操作部品２６（“アカウントのホームディレクトリ確認”）と運用操作部品２７（“ユーザによるログイン”）との組、および、運用操作部品２５（“アカウントの情報取得”）と運用操作部品２７（“ユーザによるログイン”）との組、それぞれに対して並列実行可能か否かを確認する。
【０３０８】
図４３は、並列実行可能性の判断の第５の例を示す図である。制御部１３０は、図４１，４２で例示した並列実行可能性の判断を行った後、運用操作部品２５の実行前に、運用操作部品２６，２７の並列実行可能性を判断する。先行の運用操作部品２６の動作モデルは“Ｄ”である。後続の運用操作部品２７の動作モデルは“Ｃ”である。
【０３０９】
並列実行判断基準定義テーブル１１８によれば、先行の動作モデル“Ｄ”および後続の動作モデル“Ｃ”に対応する判断基準は、番号“１４”のレコードである。運用操作部品２６，２７では操作対象のサーバ名が“Ｘ”で同一であり、サーバ同一である。また、操作対象のリソース名が“Ａｃ”で同一であり、リソース同一である。更に、操作対象のリソースのリソース種別が“Ａｃｃｏｕｎｔ”で同一であり、リソース種別同一である。並列実行判断基準定義テーブル１１８の番号“１４”のレコードは、サーバ同一、リソース名同一、かつ、リソース種別同一の場合、並列実行不可能であることを示す。よって、制御部１３０は、運用操作部品２６，２７を並列実行不可能と判断する。
【０３１０】
この場合、制御部１３０は、運用操作部品２５，２７も並列実行不可能と判断することになる。そして、制御部１３０は、運用操作部品２５，２６の２つについては並列実行可能であるが、運用操作部品２５，２６，２７の３つについては並列実行不可能と判断する。
【０３１１】
図４４は、並列実行可能性の判断の第５の例（続き）を示す図である。図４４の例は、第１の判断基準３１および第２の判断基準３２によって、並列実行不可能と判断されたといえる。
【０３１２】
すなわち、まず、制御部１３０は、“アカウントのホームディレクトリ確認”の動作モデルと“ユーザによるログイン”の動作モデルとを比較する。動作モデルの構造から、同一サーバ名であるため、制御部１３０は、第１の判断基準３１により、対象リソースのリソース名とリソース種別（属性）、操作内容からリソース間の関連性の有無を確認する。“アカウントのホームディレクトリ確認”と“ユーザによるログイン”とは、同一リソース名、および、同一リソース種別に対する操作と参照の関係にある。このため、第２の判断基準３２に示す通り、制御部１３０は両運用操作部品（運用操作部品２６，２７）を並列実行不可能と判断する。制御部１３０は、“アカウントの情報取得”（運用操作部品２５）および“ユーザによるログイン”（運用操作部品２７）も並列実行不可能と判断する。
【０３１３】
制御部１３０は、並列実行可能と判断した運用操作部品２５，２６の実行順序を変更する。
図４５は、並列化の例を示す図である。制御部１３０は、動作モデル状態管理テーブル１１６において、運用操作部品２４に相当するレコードの改善後の次の部品番号に部品番号“５，６”を設定することで、運用操作部品２５，２６を並列化する。ワークフロー２０ａは、ワークフロー２０の並列化後を示す。例えば、実行部１４０は、動作モデル状態管理テーブル１１６に格納された改善後の次の部品番号を参照して、運用操作部品２５，２６を並列実行する。
【０３１４】
図４６は、並列化の比較例を示す図である。ここで、ワークフローに含まれる各運用操作部品をモデル化したとき、単に連続するモデルの組み合わせのみに基づいて、並列実行可能か否かを判断することも考えられる。
【０３１５】
ワークフロー２０の例によれば、運用操作部品２１を操作系、運用操作部品２２を参照系、運用操作部品２３を参照系、運用操作部品２４を操作系、運用操作部品２５を参照系、運用操作部品２６を参照系、運用操作部品２７を操作系とモデル化し得る。そして、例えば、「連続する参照系の処理は、並列実行可能」という情報を事前に定義する。すると、並列実行可能なパターンが表れている箇所、運用操作部品２２，２３および運用操作部品２５，２６の２箇所を並列実行可能と判断し得る。しかし、例えお互いが参照操作であっても、該当の運用操作部品を並列実行してしまうと適正に動作しない可能性がある。具体的には次の通りである。
【０３１６】
図４７は、並列化の比較例（続き）を示す図である。ワークフロー２０ｂは、図４６で示した比較例の判断手法によってワークフロー２０を並列化した結果である。例えば、運用操作部品２３の“サービスの起動確認”の対象には、サーバ名“Ｘ”で示されるサーバ（例えば、業務サーバ２００など）と当該サーバ上のサービス名“Ｓ”のサービスという階層関係がある。したがって、サービス名“Ｓ”のサービスの起動確認は、サーバ名“Ｘ”のサーバの状態が明確になっている（不定状態ではない）ことが重要である。階層関係と操作対象の状態とを考慮せずに“サーバの起動確認”と“サービスの起動確認”とを同時実行する場合、操作対象であるサーバ名“Ｘ”のサーバの状態の確認前に、“サービスの起動確認”を実行すると、ワークフロー２０が正しく動作しない可能性があるからである。すなわち、異なる操作対象に対して参照する場合でも、それらの操作対象が階層の上下関係をもつ場合は、階層の上下関係に則った順序で参照すべきであり、並列（同時）参照すべきではない。
【０３１７】
それに加えて、操作対象の状態は運用作業中（ワークフロー実行中）に動的に変化する。しかし、図４６で示した比較例の方法では、ワークフローの実行前に、運用操作部品をモデル化している。そのため、並列実行可能か否かを判断する際に、階層関係を含めた操作対象の状態を考慮できない。操作対象の状態が時間により変化する場合、操作対象の状態が不定となる場合も存在する。このため、階層関係を含めた操作対象の状態を考慮しないと、並列実行可能性を適正に判断できない。
【０３１８】
他の方法として、並列実行可能か否かを判断するために、図４６のモデル化の方法を用いない方法も考えられる。例えば、全ての運用操作部品に対して前後の処理との優先度（順序）と、全ての対象の状態（操作対象の状態、および、操作対象と階層関係にある対象の状態）の組み合わせを考慮して、事前に定義しておくことが考えられる。しかし、考慮すべき状態の全ての組み合わせの数は膨大であり、全ての組み合わせを考慮して人手によって事前に定義するには多大な作業コストがかかり、現実的ではない。
【０３１９】
仮に定義したとしても、膨大なパターン定義に基づいて各運用操作部品の実行時に並列実行か否かを判断しようとすると、全ての運用操作部品に対して、総当たりの組み合わせを確認することになる。このため、並列実行可能か否かの判断のための演算コストが膨大となり、ワークフローの実行に要する時間が増えてしまう。
【０３２０】
本来、ワークフローをより早く実行するための手段として並列実行が考えられるが、並列実行可能か否かの判断に多くの時間を消費すると、ワークフローをより早く実行するという本来の目的に反してしまう。
【０３２１】
これに対し、運用サーバ１００によれば、運用操作部品の実行時に更新される動作モデルと、その動作モデルに基づいて定義した並列実行可能性の判断基準とに基づいて、各運用操作部品の並列実行可能性を動的に判断可能となる。運用サーバ１００は、動的に変化する情報を用いて並列実行可能性を判断する対象の運用操作部品を、運用操作部品の動作モデルの情報に基づいて絞り込む。これにより、運用操作部品間の並列実行可能性判断のための詳細検討を、特定のサーバやリソースの組み合わせの場合に限定できる。このため、ワークフローの実行中に運用操作部品の並列実行可能性を動的に判断する際に、全ての運用操作部品について、操作対象の状態の全組み合わせに対する膨大なパターン定義を用いて並列実行可能性の判断を行うよりも、演算コストを減らせる。また、直列（逐次）実行するワークフローに対して、ワークフロー実行時に並列可能な箇所を動的に並列実行することで、ワークフローをより早く実行できる。
【０３２２】
更に、例えば、並列実行するワークフローをユーザが定義する場合、ユーザは、運用操作部品の順序性や運用操作部品によって操作される情報の整合性などを考慮して並列実行するワークフローを定義することになる。このような作業をユーザに強いるとワークフロー定義において人為的なミスが生じ得る。これに対し、運用サーバ１００は、直列実行するよう定義されたワークフローに対して、ワークフローの実行に伴い並列実行箇所を動的に判断する。このため、運用操作部品の順序性や情報の整合性などを考慮して並列実行箇所を含むワークフロー定義を行うことを、ユーザに強いずに済む。よって、ワークフロー定義における人為的なミスを抑制できる。
【０３２３】
なお、第１の実施の形態の情報処理は、演算部１ｂにプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、プロセッサ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体１３に記録できる。
【０３２４】
例えば、プログラムを記録した記録媒体１３を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体１３に記録されたプログラムまたは他のコンピュータから受信したプログラムを、ＲＡＭ１０２やＨＤＤ１０３などの記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。
【０３２５】
以上の第１，第２の実施の形態を含む実施形態に関し、更に以下の付記を開示する。
（付記１）  ワークフローに含まれる複数の運用操作の並列実行可能性を判定する運用操作管理プログラムであって、コンピュータに、
次に実行する第１の運用操作、および、前記第１の運用操作に後続する第２の運用操作について、前記複数の運用操作それぞれを、動作対象、および、動作内容に基づき区分した動作区分情報に基づき、詳細判断対象の該否を判別し、
詳細判断対象である場合は、前記第１の運用操作および前記第２の運用操作の、前記動作対象に関する関係、および、前記第１および前記第２の運用操作が関連する動作対象の動作状況に基づき、並列実行可能性を判断する、
処理を実行させる運用操作管理プログラム。
【０３２６】
（付記２）  前記動作区分情報は、前記複数の運用操作それぞれを、前記動作対象および前記動作内容の組み合わせに応じて区分した動作区分の情報を含み、
前記判別では、先行の運用操作の動作区分と後続の運用操作の動作区分との組に応じた並列実行可能性の判断基準を示す判断基準情報のうち、前記第１および前記第２の運用操作の動作区分の組に対応する前記判断基準により前記詳細判断対象の該否を判別する、
付記１記載の運用操作管理プログラム。
【０３２７】
（付記３）  前記判断基準は、前記動作区分の組に対して、前記先行の運用操作および前記後続の運用操作の動作対象の一致または相違に応じた前記詳細判断対象の該否を示す情報を含み、
前記判別では、前記判断基準に基づいて、前記第１および前記第２の運用操作の動作対象の一致または相違により前記詳細判断対象の該否を判別する、
付記２記載の運用操作管理プログラム。
【０３２８】
（付記４）  前記動作対象は、運用操作の対象のマシンおよび前記マシン上のリソースを含み、
前記動作内容は、前記動作対象の状態を変更する操作処理および前記動作対象の状態を変更しない参照処理を含む、
付記１乃至３の何れか１つに記載の運用操作管理プログラム。
【０３２９】
（付記５）  前記動作対象に関する関係は、前記動作対象であるマシンと前記マシン上のリソースとの階層関係を含む、付記１乃至４の何れか１つに記載の運用操作管理プログラム。
【０３３０】
（付記６）  前記リソースは、リソース名および種別によって特定され、
前記階層関係は、更に、前記リソースの種別と前記リソースによる処理対象を更に区分した前記リソースの種別の属性との階層関係を含む、付記５記載の運用操作管理プログラム。
【０３３１】
（付記７）  前記判断では、前記第１および前記第２の運用操作が関連する前記マシンおよび前記リソースそれぞれの動作状況を確認し、当該動作状況の組み合わせに基づいて、前記並列実行可能性を判断する、付記５または６記載の運用操作管理プログラム。
【０３３２】
（付記８）  前記判断では、前記第１および前記第２の運用操作の前記動作対象および前記動作内容に応じて、前記マシンの動作状況が不定であれば前記第１および前記第２の運用操作を並列実行不可能と判断し、前記マシンの動作状況が不定以外であれば前記第１および前記第２の運用操作を並列実行可能と判断する、付記７記載の運用操作管理プログラム。
【０３３３】
（付記９）  前記判断では、更に、前記第１および前記第２の運用操作の前記動作対象および前記動作内容に応じて、前記マシンの動作状況が不定以外であり、かつ、前記リソースの動作状況が不定であれば前記第１および前記第２の運用操作を並列実行不可能と判断し、また、前記マシンの動作状況が不定以外であり、かつ、前記リソースの動作状況が不定以外であれば前記第１および前記第２の運用操作を並列実行可能と判断する、付記８記載の運用操作管理プログラム。
【０３３４】
（付記１０）  前記判断では、前記第１および前記第２の運用操作を並列実行可能と判断した場合、前記第２の運用操作に後続する第３の運用操作と、前記第１および前記第２の運用操作との並列実行可能性を更に判断する、付記１乃至９の何れか１つに記載の運用操作管理プログラム。
【０３３５】
（付記１１）  ワークフローに含まれる複数の運用操作の並列実行可能性を判定する運用操作管理装置であって、
前記複数の運用操作それぞれを、動作対象、および、動作内容に基づき区分した動作区分情報を記憶する記憶部と、
次に実行する第１の運用操作、および、前記第１の運用操作に後続する第２の運用操作について、前記動作区分情報に基づき、詳細判断対象の該否を判別し、詳細判断対象である場合は、前記第１の運用操作および前記第２の運用操作の、前記動作対象に関する関係、および、前記第１および前記第２の運用操作が関連する動作対象の動作状況に基づき、並列実行可能性を判断する演算部と、
を有する運用操作管理装置。
【０３３６】
（付記１２）  ワークフローに含まれる複数の運用操作の並列実行可能性を判定する運用操作管理方法であって、コンピュータが、
次に実行する第１の運用操作、および、前記第１の運用操作に後続する第２の運用操作について、前記複数の運用操作それぞれを、動作対象、および、動作内容に基づき区分した動作区分情報に基づき、詳細判断対象の該否を判別し、
詳細判断対象である場合は、前記第１の運用操作および前記第２の運用操作の、前記動作対象に関する関係、および、前記第１および前記第２の運用操作が関連する動作対象の動作状況に基づき、並列実行可能性を判断する、
運用操作管理方法。
【符号の説明】
【０３３７】
１  運用操作管理装置
１ａ  記憶部
１ｂ  演算部
２  ネットワーク
３，４  情報処理装置
５，５ａ，５ｂ  ワークフロー
【図１】
0006575099.tif 000002
【図２】
0006575099.tif 000003
【図３】
0006575099.tif 000004
【図４】
0006575099.tif 000005
【図５】
0006575099.tif 000006
【図６】
0006575099.tif 000007
【図７】
0006575099.tif 000008
【図８】
0006575099.tif 000009
【図９】
0006575099.tif 000010
【図１０】
0006575099.tif 000011
【図１１】
0006575099.tif 000012
【図１２】
0006575099.tif 000013
【図１３】
0006575099.tif 000014
【図１４】
0006575099.tif 000015
【図１５】
0006575099.tif 000016
【図１６】
0006575099.tif 000017
【図１７】
0006575099.tif 000018
【図１８】
0006575099.tif 000019
【図１９】
0006575099.tif 000020
【図２０】
0006575099.tif 000021
【図２１】
0006575099.tif 000022
【図２２】
0006575099.tif 000023
【図２３】
0006575099.tif 000024
【図２４】
0006575099.tif 000025
【図２５】
0006575099.tif 000026
【図２６】
0006575099.tif 000027
【図２７】
0006575099.tif 000028
【図２８】
0006575099.tif 000029
【図２９】
0006575099.tif 000030
【図３０】
0006575099.tif 000031
【図３１】
0006575099.tif 000032
【図３２】
0006575099.tif 000033
【図３３】
0006575099.tif 000034
【図３４】
0006575099.tif 000035
【図３５】
0006575099.tif 000036
【図３６】
0006575099.tif 000037
【図３７】
0006575099.tif 000038
【図３８】
0006575099.tif 000039
【図３９】
0006575099.tif 000040
【図４０】
0006575099.tif 000041
【図４１】
0006575099.tif 000042
【図４２】
0006575099.tif 000043
【図４３】
0006575099.tif 000044
【図４４】
0006575099.tif 000045
【図４５】
0006575099.tif 000046
【図４６】
0006575099.tif 000047
【図４７】
0006575099.tif 000048