JP6394032B2 - 処理管理プログラム、処理管理装置及び処理管理方法 - Google Patents

Description

本発明は、情報処理装置で実行される処理の管理に関する。

企業内の情報テクノロジー（IT）システムやデータセンターにおいて、運用管理作業の軽減化のために運用管理の自動化（Run Book Automation）を行うソフトウェアを利用してサーバの電源管理等の自動化を実施している。このような運用管理自動化に関して、例えば、以下の技術がある。

第１の技術として、人間系作業と装置系作業とが混在した複数の運用作業の個々の作業の依存関係、矛盾、リスクを可視化して出力し、適切な管理ができる技術がある（例えば、特許文献１）。第１の技術では、入力部、作業時間決定部、プロセス定義生成部、抽出部、出力情報生成を含むシステムが記載されている。入力部は、装置の作業及び人間の作業を含む複数の作業と、複数の作業の順序とを有する運用作業の情報を受け入れる。作業時間決定部は、複数の作業の各々に要する作業時間を、時間決定規則に基づいて決定する。プロセス定義生成部は、決定された各作業時間を、対応する装置の作業又は人間の作業にそれぞれ対応付けた複数のプロセス定義を生成する、運用作業の情報に含ませることによって生成される。抽出部は、複数のプロセス定義と分析規則に基づいて複数の作業の各々の間の依存関係、及び／又はリスクを抽出する。出力情報生成部は、依存関係、及び／又はリスクを可視的に出力するための出力情報を生成する。

また、第２の技術として、再利用しやすく柔軟なプログラム制御情報生成に関する技術がある（例えば、特許文献２）。第２の技術では、業務フロー制御情報生成ステップとプログラム連携情報生成ステップおよびシステム構成情報生成ステップを分離することにより再利用や構成変更を容易とし、さらにそれぞれから取得される定義情報をリポジトリに格納して統合的に管理し、定義情報間の関連から情報を得ている。

また、第３の技術として、サービス指向アーキテクチャ（ＳＯＡ：Ｓｅｒｖｉｃｅ Ｏｒｉｅｎｔｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）を用いるシステムにおいて、サービスに障害が発生した際に影響を受ける業務を判定する技術がある（例えば、特許文献３）。第３の技術では、構成情報及び判断知識に、業務において実行されるサービスの実行条件が示される。サービス運用管理サーバ装置は、ＥＳＢ（Ｅｎｔｅｒｐｒｉｓｅ Ｓｅｒｖｉｃｅ Ｂｕｓ）サーバ装置からサービス実行状況を示す実行ログを入力する。実行ログ１０３１の解析の結果、サービスに障害が発生したと判断した場合に、サービス運用管理サーバ装置は、障害発生時の状況が障害発生サービスの実行条件に合致するか否かを業務ごとに判断する。実行条件に合致しない業務についてはサービスが実行されていた可能性がないので障害の影響がないと判定される。実行条件に合致する業務についてはサービスが実行されていた可能性があるので障害の影響があると判定される。

特開２０１３−１８２４３２号公報 特開２００２−０４９４９３号公報 特開２０１１−１４１７８９号公報 特開平６−２３６３５０号公報

情報処理装置の運用管理は、クラウド時代に対応するため、１以上の情報処理装置が処理を順次実行するようにプロセス定義（ワークフロー）を作成して運用管理作業を自動化することにより、データセンターの運用管理を行っている。運用管理者は、現在動作しているワークフローが、これから動作する予定の後続のワークフローに影響を与えて正常に動作出来ない場合、正常に動作できるよういち早く対処を行う必要がある。例えば、現在動作しているワークフローの停止が必要であるかどうか、またはこれから動作する予定のワークフロー実行の延期が必要かどうかを判定することが求められる場合がある。そのためには現在動作しているワークフローが他のワークフローに及ぼす影響を把握することが必要である。

本発明は、一側面として、いずれかのワークフローにて発生した異常により影響を受ける動作予定のワークフローを特定する技術を提供する。

処理管理プログラムは、コンピュータに、以下の処理を実行させる。コンピュータは、複数の処理手順を順次処理する管理対象のシステムにおける異常の発生を検知する。コンピュータは、異常の発生の検知に応じて、当該異常の発生した処理を含む処理手順を複数の処理手順のうちから特定する。コンピュータは、複数の処理手順の処理内容および処理順序を規定する処理手順情報を参照し、順次処理される複数の処理手順のうち特定した処理手順よりも後に処理される処理手順であって、特定した処理手順で発生した異常の影響を受ける処理手順である後段処理手順を特定する。コンピュータは、複数の処理手順による出力情報のうち、前記特定した処理手順、または、前記後段処理手順に関連した出力情報を特定する。なお、後段処理手順の特定においては、処理が異常となる原因が発生するか否かを判定する確認方法と、確認方法において処理が異常となる原因が発生するとの判定を下す異常条件とを処理毎に含む異常確認情報が格納された記憶部から取得した異常確認情報を用いて、順次処理される複数の処理手順のうち特定した処理手順よりも後に処理される処理手順に含まれる処理に対し、処理に応じた確認方法を実行して、処理が異常となる原因が発生するか否かを処理に応じた異常条件に基づき判定し、異常となる原因が発生する処理がある場合、特定した処理手順よりも後に処理される処理手順を後段処理手順として特定する。

本発明の一側面によれば、いずれかのワークフローにて発生した異常により影響を受ける動作予定のワークフローを特定することができる。

第１の技術が解決する事例を説明するための図（その１）である。 第１の技術が解決する事例を説明するための図（その２）である。 第１の技術では解決できない事例を説明するための図である。 第２及び第３の技術を組合わせても解決できない事例を説明するための図である。 異常が発生したワークフローの作業対象全てを使用する他のワークフローはその異常の影響を受けると判断する方法を適用した技術（第４の技術）について説明するための図である。 第４の技術では解決できない事例について説明するための図である。 本実施形態における処理管理装置の一例を示す。 本実施形態における自動化フローシステムを説明するための図である。 本実施形態におけるワークフローの一例を示す。 本実施形態における自動化フローシステムのシステム構成のブロック図の一例を示す。 本実施形態におけるプロセス定義テーブルの一例を示す。 本実施形態における影響範囲リストの一例を示す。 本実施形態におけるＷＦ管理テーブルの一例を示す。 本実施形態における異常判断テーブルの一例（その１）を示す。 本実施形態における異常判断テーブルの一例（その２）を示す。 本実施形態における実行結果テーブルの一例を示す。 本実施形態における影響作業対象リストの一例を示す。 本実施形態における全体の処理のフローチャートである。 本実施形態におけるワークフロー監視処理（Ｓ３）の詳細フローチャートである。 本実施形態におけるＷＦ内原因取得処理（Ｓ１８）の詳細を示すフローチャートである。 本実施形態における他ＷＦ原因取得処理（Ｓ１９）の詳細を示すフローチャートである。 本実施形態における表示処理（Ｓ２０）の詳細を示すフローチャートである。 本実施形態におけるトラブルが発生したプロセス定義の表示処理（Ｓ６１）の詳細を示すフローチャートである。 本実施形態におけるトラブルが発生したノードの影響を受けるプロセス定義の表示処理（Ｓ６２）の詳細のフローチャートである。 Ｓ９８の詳細処理を示すフローチャートである。 本実施形態におけるトラブルが発生したワークフロー上のノードについて、確認手段の実行結果の評価について説明するための図である。 本実施形態におけるトラブルが発生したワークフロー以外のワークフロー上のノードについて、確認手段の実行結果の評価について説明するための図である。 本実施形態における表示例である。 本実施形態の実施例におけるプログラムを実行するコンピュータのハードウェア環境の構成ブロック図の一例である。

データセンターの運用作業をワークフローとして記述し、複数のワークフローが稼動する場合に、先行のワークフローが後続のワークフローへ及ぼす影響によって後続のワークフローが正常に終了できない場合がある。例えば、管理対象サーバの起動作業が失敗することによって、他ワークフローに記述している、管理対象サーバ上のサービス起動作業が失敗することが考えられる。

このようなワークフローの作業間の依存関係を自動で管理し、相互に及ぼす影響を可視化するために、例えば、第１の技術では、ワークフロー上の作業に影響する情報を管理している。例えば、サーバＡ，Ｂ，Ｃが存在するシステム構成があるとする。ワークフロー上の各作業は、サーバＡ，Ｂ，Ｃに対して操作を行うことにより、サーバＡ，Ｂ，Ｃにより行われる。ワークフロー上の各作業には、開始予定時刻、完了予定時刻が設定され、スケジュール管理されている。

第１の技術によれば、図１に示すように、ワークフロー１において、サーバＡに対してサーバ停止を指示してトラブルが発生し、作業完了時刻が作業完了予定時刻を超過した場合、システムは時刻超過を検知し、他に影響する作業の解析を開始する。このとき、作業開始時刻が遅延する場合、ワークフロー１上の後続作業に影響がある（時間による影響を受ける作業）。

また、未開始のワークフロー（ワークフロー２）の各作業において、トラブル発生時の作業対象（サーバＡ）が同一である。そのため、トラブル発生により作業が正常に完了しない可能性があるため、作業に影響があると検出される（作業対象による影響を受ける作業）。

また、上記はトラブルが発生しても正常ルートへ進んだ場合であるが、通常の場合、トラブルが発生すると、図２に示すように、異常ルートへ進む。その場合、ワークフロー１のサーバＢ、サーバＣに対する作業は実施されないため、第１の技術では作業に対する影響が無いと判断される。しかし、トラブルが発生した作業の作業対象がサーバＡのため、未開始のワークフロー（ワークフロー２）のサーバＡへの影響があることは検知できる。

次に、第１の技術の解決しない事例を、図３に示すように、ワークフロー１とワークフロー３を用いて説明する。サーバＢに対する作業を自動化したフロー（ワークフロー３）が存在した事例において、ワークフロー１のサーバＡに対してサーバ起動を実行させるとトラブルが発生し、完了予定時刻までに作業が完了して異常ルートに進んだ場合を想定する。その場合、ワークフロー１のサーバＢ、サーバＣに対する作業は実施されないため、第１の技術では作業影響が無いと判断される。

作業対象のサーバがサーバＢだけでなる未開始のワークフロー３は、時間の影響を受けないことと、作業対象のサーバがトラブルが発生した作業対象のサーバとも異なることから、影響無しと判断される。

しかし、ワークフロー１においてサーバＢに対するサーバ起動を実施させていないため、ワークフロー３が開始してしまうとサーバＢに対するサービス停止の作業は失敗し、異常が発生する可能性がある。

このように、ワークフロー１が正常に動作しない場合、ワークフロー３が受ける影響を検知できないという課題が残る。

次に、第２の技術では、３つのステップに分けて定義情報をテーブルに分けることによって別の計算機のシステム設計に再利用できるようにしている。その定義情報の中に、ビジネスプロセス（業務フロー）とプログラムを対応付けて定義を行っている。トラブル発生時において、この定義された情報を使用することにより、プログラムが動作している計算機で動く作業名と業務フロー名を導き出し、業務フロー上に障害が発生したことを図示している。

しかし、トラブルが発生した計算機上で動作する作業のみを取得して影響があると判断しているだけなので、トラブルにより実行されない作業による他のフローへ及ぼす影響がわからないという課題が残る。

また、第３の技術では、障害が発生したサービス（作業）が他の業務（ワークフロー）に影響を与えるかどうかについて、判定表を用いて影響の程度と影響の範囲を割り出している。しかし、トラブルが発生した作業を起点としたワークフローへの影響を判断しているだけのため、トラブルにより実行されない作業による他のフローへ及ぼす影響がわからないという課題が残る。

また、第２の技術の技術と第３の技術の技術を組み合わせても、次の問題がある。図４では、サーバAにて障害（仮想サーバに中央演算処理装置（ＣＰＵ）が設定されていなくて起動が失敗した）が発生した場合、第３の技術を使用して、判定知識ＩＤを用いてワークフロー１が業務に影響があるかどうかの判定式を実行する。これにより、ワークフロー１が業務に影響を与えるかどうかが判断される。この例ではＣＰＵが設定されていないため、判定条件に一致せず、利用フラグが１になるため、影響ありと判断される。しかしながら、その影響があるとの判断は、あくまでワークフロー１についてであり、ワークフロー３への影響については、判断する仕組みが無く、影響が無いと判断される。

また、第２の技術を使用して他の同作業対象を使用しているワークフローについて影響が確認されるが、ワークフロー３はトラブル発生作業対象を使用していないため、やはりワークフロー３について影響が無いと判断される。

上述した技術を使用し、異常が発生したワークフローに関連したワークフローを特定する方法として、影響する作業対象を管理し、異常が発生したワークフローの作業対象全てを使用する他のワークフローを導く方法が考えられる。これにより、トラブルが発生して通らない正常ルートの作業が、どのワークフローに影響があるのかを検出することが出来る。

例えば、図５に示すように、異常が発生したワークフローの作業対象全てを使用する他のワークフローは影響があると判断する方法を適用した場合について考える。この場合、ワークフロー３のサービス停止は、ワークフロー１のトラブルの影響を受けて失敗する。そのため、トラブルが発生したワークフロー１上の作業対象を全て影響する作業対象とみなすことにより、そのトラブルとワークフロー３の作業対象（サーバＢ）と関連付くため、ワークフロー３の作業にも影響があると判断できる。運用管理者はワークフロー３に影響があることが分かると、ワークフロー３を一時停止する。

しかしながら、この方法を使用すると影響のないワークフローも影響があると判断してしまう場合がある。例えば、図６に示すように、ワークフロー４ではサーバＢのサーバ起動についてのトラブルの発生により、サーバＢのサーバ起動を実施していない作業が存在した場合でも、他のワークフロー上のサーバＢのサーバ起動作業が影響する、と判断される。しかし、サーバＢのサーバ起動作業はトラブルにより実施していないため、作業は失敗せずサーバ起動作業は成功する。運用管理者は、ワークフロー４に作業影響があると分かると、作業影響のないワークフロー４を一時停止してしまう。

このように、作業対象の影響波及を見るだけでは、正しく動作する作業についてまで影響があると判断してしまう問題がある。

前述した通り、作業の異常が発生した際は、速やかに後続の作業への影響を把握する必要がある。異常ルートへ遷移したことによって正常ルートで本来実施される予定の作業が実施されないことにより、後続の作業へ影響を受けるため、実施されない作業の影響を考慮することが求められる。

トラブル発生後に異常ルートを通る場合、後続の作業へどのような影響を及ぼすかどうかを判断するためには、作業対象の情報を蓄積した過去データを使用して統計的に後続作業への影響を判断する方法がある。

ところが、蓄積された過去の動作履歴情報を活用して後続業務への影響を分析しようとした場合、異常ルート走行時の後続業務への影響を分析出来ない場合がある。その理由は、異常ルートの走行経験が無い場合、異常ルート時の動作履歴が存在せず、分析の入力となる情報を得られないためである。

第２の技術及び第３の技術を組み合わせた技術は、ワークフロー定義情報、及びそれに付随する定義情報（図４に記載しているように、ワークフローと作業対象との関係情報と影響を判断するための条件情報）から直接解る影響範囲の見極めに留まっている。

ワークフロー定義情報、およびそれに付随する定義情報のみでは、異常によって本来実施されるはずの後続の正常ルートが実施されないことによる間接的な影響範囲を見極められない。その問題を解決するためには、過去のデータを使用した推測が必要となる。第３の技術では、トラブルが発生した原因の特定方法として実行ログを調べているが、ログ情報は「蓄積された過去の動作履歴情報」となるため、上述したように、過去データを用いた場合は異常ルート走行経験が無いため、後続業務への影響を分析できない。

そこで、本実施形態では、いずれかのワークフローにて発生した異常により影響を受ける動作予定のワークフローを判定する技術について説明する。

図７は、本実施形態における処理管理装置の一例を示す。処理管理装置１は、検知部２、処理特定部３、手順特定部４、出力特定部５を含む。

検知部２は、複数の処理手順（ワークフロー）を順次処理する管理対象のシステム８における異常の発生を検知する。検知部２の一例としては、Ｓ１６の処理を実行するＷＦ監視部１７として機能する制御部１３が挙げられる。管理対象のシステム８は、例えば、１以上の管理対象サーバ群を示す。

処理特定部３は、異常の発生の検知に応じて、当該異常の発生した、複数の処理手順（ワークフロー）に含まれる処理（ここでの処理とは後述する運用操作部品を示す）を特定する。処理特定部３の一例としては、Ｓ１７の処理を実行するＷＦ監視部１７として機能する制御部１３が挙げられる。

手順特定部４は、複数の処理手順（ワークフロー）の処理内容および処理順序を規定する処理手順情報を参照し、複数の処理手順のうち、特定した処理（運用操作部品）で発生した異常の影響を受ける後段処理手順を特定する。手順特定部４の一例としては、Ｓ１９、Ｓ１０２〜Ｓ１０６の処理を実行するＷＦ監視部１７として機能する制御部１３が挙げられる。処理手順情報の一例としては、ＷＦ管理テーブル２１が挙げられる。

出力特定部５は、複数の処理手順による出力情報のうち、特定した処理、または、後段処理手順に関連した出力情報を特定する。出力特定部５の一例としては、Ｓ７９、Ｓ１０６の処理を実行するＷＦ監視部１７として機能する制御部１３が挙げられる。

このように構成することにより、いずれかのワークフローにて発生した異常により影響を受ける動作予定のワークフローを特定することができる。

処理特定部３は、管理対象のシステム８に含まれる情報処理装置９から、特定した処理に基づいて処理を実行する情報処理装置９を特定する。当該情報処理装置９の一例として、例えば、Ｓ７３〜Ｓ７４等の処理で得られた影響作業対象リストに示される対象サーバ３０が挙げられる。このとき、手順特定部４は、特定された情報処理装置９に対する処理を含む、異常の発生の検知後に実行予定の他の処理手順のうち、他の処理手順の実行結果に応じて、特定した処理で発生した異常の影響を受ける処理手順の判定を行う。当該判定処理は、例えば、Ｓ１９、Ｓ９１〜Ｓ９８等の処理に対応する。

処理管理装置１は、さらに、記憶部６を含む。記憶部６は、処理に異常が発生した場合にその異常を確認する確認方法と該確認により異常と判定する異常条件とを含む異常確認情報を格納する。記憶部６の一例として、記憶部１８が挙げられる。異常確認情報の一例として、異常判定テーブル２２が挙げられる。このとき、処理特定部３は、記憶部６から取得した異常確認情報を用いて、異常の発生の検出以降に実行される処理手順に対する確認方法を実行して実行結果を取得する。当該取得処理は、例えば、Ｓ１９，Ｓ５５、Ｓ３７に対応する。

このように構成することにより、異常が検出された以降に実行されるワークフローに含まれる運用操作部品に対して確認方法を実行し、その実行結果を得ることができる。

手順特定部４は、特定された情報処理装置９に対する処理を含む、異常の発生の検出以降の他の処理手順を特定する。それから、手順特定部４は、特定した他の処理手順に含まれる処理に対応する確認方法による実行結果のいずれかが異常条件を満たす場合、他の処理手順を、その処理で発生した異常の影響を受ける処理手順であると判定する。当該判定処理は、例えば、Ｓ１０４〜Ｓ１０６の処理に対応する。

このように構成することにより、いずれかのワークフローにて発生した異常により影響を受ける動作予定のワークフローを判定することができる。

処理管理装置１は、さらに、表示制御部７を含む。表示制御部７は、特定した処理で発生した異常の影響を受ける後段処理手順を表示する。表示制御部７の一例としては、Ｓ８０、Ｓ１０７の処理を実行するＷＦ監視部１７として機能する制御部１３が挙げられる。

このように構成することにより、いずれかのワークフローにて発生した異常により影響を受ける動作予定のワークフローを表示することができる。

異常確認情報は、さらに、確認方法と異常情報とに関係付けて、異常条件に該当した場合の異常の原因を示す情報を含む。表示制御部７は、後段処理手順に含まれる処理のうち、確認方法による実行結果のいずれかが異常条件を満たす処理を取得する。それから、表示制御部７は、異常確認情報から、取得した処理に対応する異常の原因を示す情報を取得し、後段処理手順と共に、取得した該異常の原因を示す情報を表示する。当該表示処理は、例えば、Ｓ１０６，Ｓ１０７の処理に対応する。

このように構成することにより、いずれかのワークフローにて発生した異常により影響を受ける動作予定のワークフローと共に、異常の理由も表示することができる。

図８は、本実施形態における自動化フローシステムを説明するための図である。自動化フローシステムは、１以上の管理対象のサーバに対する操作を定義した操作情報を含む一連の操作手順をワークフローで表現することを自動化したアプリケーションプログラムによって実現されるシステムである。図８において、自動化フローの始点は「Ｓ」で表され、終点は「Ｅ」で表されている。

ノードとは、自動化フローシステムにおいて、管理対象のサーバに対して処理を実施するワークフロー上の各段階をいう。あるノードでの処理が完了して次のノードへ処理が遷移するが、本実施形態では、ワークフローにおけるノード間の遷移は、矢印で表現されている。分岐は、ノードの処理結果に応じて、遷移先のノードが異なる場合に用いられる。

図９は、本実施形態におけるワークフローの一例を示す。ワークフローを形成するノードには、運用操作部品が設定されている。運用操作部品とは、ワークフローを構成する各処理を管理対象サーバに自動的に実行させるように、管理対象サーバに対する運用操作を自動的に実行するよう記述したスクリプトである。

ノードからノードへの遷移を表す情報として、図８で説明したように、矢印情報が用いられている。矢印情報には、ノードにおける処理結果が正常である場合に遷移するノードへのルート（正常ルート）を示す「成功」矢印情報、ノードにおける処理結果が異常である場合に遷移するノードへルート（異常ルート）を示す「失敗」矢印情報がある。

図１０は、本実施形態における自動化フローシステムのシステム構成のブロック図の一例を示す。自動化フローシステム１１は、運用管理サーバ（以下、「管理サーバ」と称する。）１２、管理対象サーバ（以下、「対象サーバ」と称する）３０を含む。

管理サーバ１２は、自動化フローシステム１１を実行し、かつそれを制御するサーバである。対象サーバ３０は、ワークフローによる運用自動化において管理対象とする１以上のサーバである。管理サーバ１２と対象サーバ３０とは、ＬＡＮ（local area network）、Ｉｎｔｅｒｎｅｔ等の通信ネットワークで接続されている。

管理サーバ１２は、制御部１３、記憶部１８を含む。制御部１３は、本実施形態にかかるプログラムを記憶部１８から読み出して実行することにより、ＷＦ制御部１４、ＷＦ監視部１７として機能する。ＷＦ制御部１４、ＷＦ監視部１７については、後述する。

記憶部１８には、プロセス定義テーブル１９、影響範囲リスト２０、ワークフロー（ＷＦ）管理テーブル２１、異常判断テーブル２２、実行結果テーブル２３、影響作業対象リスト２４が格納されている。プロセス定義テーブル１９には、自動化フローシステム１１にて使用されるプロセス定義（ワークフロー）１５に関する情報が登録されており、ワークフローを形成する運用操作部品（ノード）１６が登録されている。

以下、データベースを「ＤＢ」と称する。また、以下では、ワークフローを「ＷＦ」と称する場合もある。

図１１は、本実施形態におけるプロセス定義テーブルの一例を示す。プロセス定義テーブル１９は、「プロセス定義名」１９−１、「ノード名」１９−２、「運用操作部品名」１９−３、「ノードＩＤ」１９−４、「ノードタイプ」１９−５、「矢印名」１９−６、「遷移先」１９−７のデータ項目を含む。

「プロセス定義名」１９−１には、ワークフローを識別する情報が格納される。「ノード名」１９−２には、ノードの種別が格納される。「運用操作部品名」１９−３には、開始ノード及び終了ノードを除いたノードについて、運用操作部品の名称が格納される。「ノードＩＤ」１９−４には、ノードを識別する情報が格納される。「ノードタイプ」１９−５には、ノードの種類名が格納される。「矢印名」１９−６には、上述したように、正常ルートの場合の「成功」矢印情報、異常ルートの場合の「失敗」矢印情報が格納される。「遷移先」１９−７には、遷移先のノードのノードＩＤが格納される。

図１２は、本実施形態における影響範囲リストの一例を示す。影響範囲リスト２０は、ノードが影響を及ぼす作業を管理するために、予め登録されたリスト情報であり、「ノード名」２０−１、「影響する作業」２０−２のデータ項目を含む。「ノード名」２０−１には、ノードの名称が格納される。「影響する作業」２０−２には、「ノード名」２０−１の実行が影響する作業が格納される。

図１３は、本実施形態におけるＷＦ管理テーブルの一例を示す。ＷＦ管理テーブル２１は、「プロセス定義名」２１−１、「ノード名」２１−２、「作業開始時刻」２１−３、「作業終了時刻」２１−４、「影響する作業」２１−５、「作業対象」２１−６のデータ項目を含む。

「プロセス定義名」２１−１には、ワークフローを識別する情報が格納される。「ノード名」２１−２には、ノードの名称が格納される。「作業開始時刻」２１−３には、そのノードの作業開始予定時刻が格納される。「作業終了時刻」２１−４には、そのノードの作業終了予定時刻が格納される。「影響する作業」２１−５には、ＷＦ管理テーブル２１においてそのノードに対応する「影響する作業」２１−５の内容が格納される。「作業対象」２１−６には、作業対象となるサーバまたはサービスの名称が格納される。

図１４Ａ及び図１４Ｂは、本実施形態における異常判断テーブルの一例を示す。図１４Ａは、運用操作部品名が「仮想サーバを起動」である場合の異常判断テーブルの例である。図１４Ｂは、運用操作部品名が「サービスを停止」である場合の異常判断テーブルの例である。

異常判断テーブル２２は、「部品名」２２−１、「操作対象」２２−２、「異常になる直接の原因」２２−３、「結果」２２−４、「確認手段」２２−５、「異常値」２２−６、「矢印名」２２−７、「分類」２２−８のデータ項目を含むテーブルである。

「部品名」２２−１には、運用操作部品の名称が格納される。「操作対象」２２−２には、操作対象となるサーバまたはサービス名が格納される。「異常になる直接の原因」２２−３には、異常になる直接の原因についての内容が格納される。「結果」２２−４には、「異常になる直接の原因」２２−３に起因する実行結果が格納される。

「確認手段」２２−５には、その異常が発生した作業を確認するための手段が格納される。「異常値」２２−６には、異常か否かを判断するための情報が格納される。「矢印名」２２−７には、上述したように、正常ルートの場合の「成功」矢印情報、異常ルートの場合の「失敗」矢印情報が格納される。「分類」２２−８には、その異常の種類（分類）が格納される。

図１５は、本実施形態における実行結果テーブルの一例を示す。実行結果テーブル２３は、「プロセス定義名」２３−１、「ノード名」２３−２、「作業対象」２３−３、「ノードＩＤ」２３−４、「確認手段」２３−５、「実行結果」２３−６のデータ項目を含む。

「プロセス定義名」２３−１には、ワークフローを識別する情報が格納される。「ノード名」２３−２には、ノードの名称が格納される。「作業対象」２３−３には、作業対象となるサーバまたはサービスの名称が格納される。

「ノードＩＤ」２３−４には、ノードを識別する情報が格納される。「確認手段」２３−５には、その異常が発生した作業を確認するための手段が格納される。「実行結果」２３−６には、確認手段を実行した結果、得られた値が格納される。

図１６は、本実施形態における影響作業対象リストの一例を示す。影響作業対象リスト２４には、トラブルが発生したノードによるトラブルの影響を受ける作業対象のサーバ名が格納される。

以下では、図２５〜図２７を参照しながら、図１７〜図２４のフローチャートについて説明する。

図１７は、本実施形態における全体の処理のフローチャートである。まず、ＷＦ制御部１４は、自動化フローシステム１１に登録されているプロセス定義を解析する（Ｓ１）。ここでは、ＷＦ制御部１４は、自動化フローシステム１１のプロセス定義にノードが登録または更新される場合、プロセス定義テーブル１９に、各ノードについての登録情報または更新情報を格納する。

ＷＦ制御部１４は、自動化フローシステム１１に登録されているプロセス定義（ワークフロー）を形成する運用操作部品（ノード）から、「運用操作部品名」、「作業開始時刻」、「作業終了時刻」等を取得する。それから、ＷＦ制御部１４は、その取得した情報と、プロセス定義テーブル１９と影響範囲リスト２０とを用いて、運用操作部品（ノード）についての解析を行う。

ここでは、ＷＦ制御部１４は、その取得した情報と、プロセス定義テーブル１９と影響範囲リスト２０とを用いて、プロセス定義にある運用操作部品（ノード）の影響を受けるかどうかを判定するための情報をＷＦ管理テーブル２１に格納する。影響を受けるかどうかを判定するための情報とは、運用操作部品毎に規定されている作業情報のことである。ＷＦ制御部１４は、プロセス定義テーブル１９から、例えば、ノード名「サーバ起動（Ａ）」を取得し、影響範囲リスト２０から「サーバ起動」に対応する「影響する作業」を取得する。ＷＦ制御部１４は、取得した「サーバ起動」と、取得した「影響する作業」とを関係付けてＷＦ管理テーブル２１に格納する。また、ＷＦ制御部１４は、ノード名「サーバ起動（Ａ）」から作業対象となるサーバを特定し、特定した作業対象を「作業対象」２１−６に格納する。また、ＷＦ制御部１４は、プロセス定義テーブル１９から、そのノードに設定された作業開始時刻、作業終了時刻を取得し、ＷＦ管理テーブル２１に格納する。

次に、ＷＦ制御部１４は、運用操作部品の機能が停止した理由を一覧化した異常判断テーブル２２を記憶部１８に格納する（Ｓ２）。ＷＦ制御部１４は、図１４に示すように、各ノードにおいて、運用操作部品が異常になる直接の原因と、その異常を判断するための確認手段とを一覧化した異常判断テーブル２２を予め記憶部１８に格納しておく。これにより、ＷＦ制御部１４は、動作中のワークフローにて運用操作部品の異常が発生した際、運用操作部品の異常が発生した作業について、異常判断テーブル２２の「確認手段」を実施することができる。そして、ＷＦ制御部１４は、取得した値を、異常判断テーブル２２の「異常値」と比較することで「異常」であることを判別することができる。

次に、ＷＦ監視部１７は、ワークフローの監視を行う（Ｓ３）。プロセス定義（ワークフロー）の起動後に、あるノードにてトラブルが発生し、ワークフローで管理される処理が異常ルートへ遷移したことを契機に、ＷＦ監視部１７は、以下の処理を行うことにより、影響する作業の抽出から遷移先の確定及び表示まで行う。Ｓ３の詳細について、図１８で説明する。

図１８は、本実施形態におけるワークフロー監視処理（Ｓ３）の詳細フローチャートである。ＷＦ監視部１７は、まず、トラブルが発生したノードを特定する（Ｓ１１〜Ｓ１７）。ここでは、ＷＦ監視部１７は、動作しているワークフローにおいて、動作中であるノードから異常ルートへ遷移するかどうかを、定期的に監視する。そして、ＷＦ監視部１７は、動作中のノードから異常ルートへ処理が遷移したことを検知すると、遷移元となるノードをプロセス定義テーブル１９から特定する。

例えば、ワークフロー１において、サーバＡに対する「サーバ起動」ノードにて異常が発生し、処理が異常ルートを示す矢印へ遷移したとする。この場合、ＷＦ監視部１７は、異常ルートへの矢印の遷移を検知し、異常ルートの矢印の遷移元であるサーバＡに対する「サーバ起動」ノードをトラブル発生ノードとして特定する。

具体的には、ＷＦ監視部１７は、自動化フローシステムにおいて現在動作しているワークフローの一覧を、自動化フローシステム１１から取得する（Ｓ１１）。ＷＦ監視部１７は、Ｓ１１で取得した動作中のワークフローの一覧から、Ｓ１４以降について未処理のワークフローを１つ取得する（Ｓ１２、Ｓ１３で「Ｙｅｓ」）。Ｓ１４以降について未処理のワークフローがない場合には（Ｓ１３で「Ｎｏ」）、図１８の処理は終了する。

Ｓ１４以降について未処理のワークフローを１つ取得した場合、ＷＦ監視部１７は、次の処理を行う。すなわち、ＷＦ監視部１７は、動作しているワークフローのプロセス定義名を用いて、プロセス定義テーブル１９を検索し、プロセス定義テーブル１９にて定義されている異常ルートの矢印情報の一覧を取得する（Ｓ１４）。

ＷＦ監視部１７は、動作しているワークフローから、動作した直近の矢印情報を取得する（Ｓ１５）。

異常ルートの矢印情報の一覧と動作した直近のノードとを比較し、動作した直近のノードが正常ルートを示す成功矢印情報である場合（Ｓ１６で「Ｎｏ」）、ＷＦ監視部１７は、Ｓ１２の処理へ戻る。動作した直近のノードが異常ルートを示す失敗矢印情報である場合（Ｓ１６で「Ｙｅｓ」）、ＷＦ監視部１７は、プロセス定義テーブル１９から、その矢印から遷移元ノードのノードＩＤを取得する（Ｓ１７）。

次に、ＷＦ監視部１７は、トラブルが発生したノードが属するワークフローにおいて、そのトラブルが発生したノードより後のノードについてトラブルの影響を受ける作業対象であるかどうかを調べる（ＷＦ内原因取得処理）（Ｓ１８）。トラブルが発生したノードが属するワークフローにおいて、トラブルが発生したノード以降に動作予定のノードは、正常ルートと異常ルートとに分岐され、木構造となっている場合が多い。その場合、どのルートのノードも後続フローに影響する可能性がある。そのため、その矢印のヘッド以降にあるノード全てについて、運用操作部品が異常になる直接の原因を特定する。

ＷＦ監視部１７は、トラブルが発生したノードを起点として、各ノードの作業対象の情報を異常判断テーブル２２に記載済みの「確認手段」を用いて、確認手段による実行結果を取得し、取得した実行結果（値）を実行結果テーブル２３の実行結果に格納する。このＷＦ内原因取得処理（Ｓ１８）の詳細については、図１９を用いて説明する。ＷＦ内原因取得処理（Ｓ１８）には、トラブルが発生したノードのノードＩＤが引数として渡される。

図１９は、本実施形態におけるＷＦ内原因取得処理（Ｓ１８）の詳細を示すフローチャートである。ＷＦ監視部１７は、引数として渡されたノードＩＤを用いて、プロセス定義テーブル１９から、引数のノードＩＤから出ている矢印の一覧を取得する（Ｓ３１）。Ｓ３１において矢印の一覧が取得されない場合、すなわち、引数のノードＩＤが示すノードがそのワークフロー内での終了ノードである場合（Ｓ３２で「Ｙｅｓ」）、図１９のフローは終了する。

Ｓ３１において矢印の一覧が取得された場合（Ｓ３２で「Ｎｏ」）、ＷＦ監視部１７は、プロセス定義テーブル１９から、引数のノードＩＤに対応する運用操作部品名を取得する（Ｓ３３）。

ＷＦ監視部１７は、異常判断テーブル２２から、運用操作部品名に一致するレコードを検索し、運用操作部品名に対応する確認手段の一覧を取得する（Ｓ３４）。ＷＦ監視部１７は、Ｓ３４で取得した一覧から確認手段を１つ取り出す（Ｓ３５）。ＷＦ監視部１７は、取得した一覧から確認手段を取り出した場合（Ｓ３６で「Ｙｅｓ」）、確認手段に記載された手続きを実行し、実行した結果を実行結果テーブル２３に格納する（Ｓ３７）。ＷＦ監視部１７は、Ｓ３７の処理を、Ｓ３４で取得した確認手段の数だけ繰り返す。

Ｓ３４で取得した確認手段の全てについて、Ｓ３７の処理が終了した場合、ＷＦ監視部１７は、Ｓ３１で取得した矢印の一覧から矢印を１つ取り出す（Ｓ３８）。矢印が取り出ない場合（Ｓ３９で「Ｎｏ」）、図１９のフローは終了する。矢印が取り出せた場合（Ｓ３９で「Ｙｅｓ」）、ＷＦ監視部１７は、プロセス定義テーブル１９から、その矢印の遷移先のノードＩＤを取得する（Ｓ４０）。

ＷＦ監視部１７は、再び、ＷＦ内原因取得処理（Ｓ１８）を呼び出し、Ｓ４０で取得したノードＩＤを引数としてＷＦ内原因取得処理（Ｓ１８）を行う（Ｓ４１）。

ＷＦ監視部１７は、Ｓ３１で取得した一覧の矢印全てについて、Ｓ４０−Ｓ４１の処理を繰り返す。

再び、図１８のフローチャートに戻る。ＷＦ監視部１７は、トラブルが発生したワークフロー以外のワークフローについて、トラブルの影響を受ける作業対象があるかどうかを調べる（他ＷＦ原因取得処理）（Ｓ１９）。ここでは、未開始のワークフローについて、開始ノードから終了ノードまで順に、トラブルの影響を受ける作業対象があるかどうかの確認が行われる。ＷＦ監視部１７は、各ノードの作業対象の情報に関して、異常判断テーブル２２に記載済みの「確認手段」を用いて実行した実行結果を取得し、取得した実行結果（値）を実行結果テーブル２３に格納する。他ＷＦ原因取得処理（Ｓ１９）の詳細については、図２０を用いて、説明する。

図２０は、本実施形態における他ＷＦ原因取得処理（Ｓ１９）の詳細を示すフローチャートである。ＷＦ監視部１７は、ＷＦ管理テーブル２１から、動作予定のワークフローの一覧を取得する（Ｓ５１）。一覧に含まれる動作予定のワークフローのそれぞれについて、プロセス定義テーブル１９から、開始ノードから遷移するノードを取得する（Ｓ５２〜Ｓ５４）。

ＷＦ監視部１７は、ＷＦ内原因取得処理（Ｓ１８）を呼び出し、Ｓ５４で取得したノードＩＤを引数としてＷＦ内原因取得処理（Ｓ１８）を行う（Ｓ５５）。ＷＦ内原因取得処理（Ｓ１８）の処理については、図１９で説明したので、省略する。

再び、図１８のフローチャートに戻る。ＷＦ監視部１７は、Ｓ１８及びＳ１９にて収集した情報を用いて、矢印の遷移先をグラフィカルユーザインターフェース（ＧＵＩ）に表示する（Ｓ２０）。本実施形態では、一例として、矢印の遷移先をＷｅｂグラフィカルユーザインターフェース（ＷｅｂＧＵＩ）に表示するが、これに限定されない。この表示処理（Ｓ２０）の詳細については、図２１を用いて、説明する。

図２１は、本実施形態における表示処理（Ｓ２０）の詳細を示すフローチャートである。ＷＦ監視部１７は、トラブルが発生したプロセス定義（ワークフロー）の表示処理を行う（Ｓ６１）。トラブルが発生したワークフローでは、トラブル発生ノードと、正常ルートが動作しないノードとが存在する。ＷＦ監視部１７は、トラブル発生ノードについて、実行結果テーブル２３から「実行結果」を取得し、異常判断テーブル２２から「異常値」を取得する。「実行結果」が「異常値」に当てはまる場合は、ＷＦ監視部１７は、異常と判断する。また、Ｓ６１では、また、ＷＦ監視部１７は、正常ルートが動作しないノードについては、ＷＦ管理テーブル２１よりノードの運用操作部品名から作業対象を取得し、図１６に示すように、影響する作業対象リスト２４に格納する。Ｓ６１の処理について、図２５で後述する。

次に、ＷＦ監視部１７は、トラブルが発生したノードの影響を受けるプロセス定義を表示する（Ｓ６２）。影響作業対象リスト２４に、トラブルが発生したノードの影響を受ける作業対象が格納されているため、ＷＦ監視部１７は、その作業対象が含まれるプロセス定義の一覧をＷＦ管理テーブル２１より取得する。ＷＦ監視部１７は、取得したプロセス定義の開始ノードより順に、実行結果テーブル２３に設定された「実行結果」と、異常判断テーブル２２に設定された「異常値」とを取得する。ＷＦ監視部１７は、「実行結果」が「異常値」に当てはまる場合は、ノードの実行結果が異常と判断する。Ｓ６２の処理について、図２６で後述する。

図２５は、本実施形態におけるトラブルが発生したワークフロー上のノードについて、確認手段の実行結果の評価について説明するための図である。図２６は、本実施形態におけるトラブルが発生したワークフロー以外のワークフロー上のノードについて、確認手段の実行結果の評価について説明するための図である。図２５、図２６は、Ｓ６１及びＳ６２に関して、実行結果と異常値を比べて、異常値に当てはまる実行結果を分かりやすく示したものである。

例えば、図２５では、トラブル発生ノードがワークフロー１のノード「サーバ起動」（作業対象をサーバＡとする）であるとする。仮想マシンの設定情報の取得処理の実行結果（ＣＰＵ：なし）が、それに対応する「異常値」に当てはまるので、ＷＦ監視部１７は、異常と判断する。図２６についても同様に、仮想マシンの設定情報の取得処理の実行結果（ＣＰＵ：なし）が、それに対応する「異常値」に当てはまる場合（太枠で囲んだ部分）、ＷＦ監視部１７は、その異常値に対応するノードは異常であると判断する。

また、図２５では、ワークフロー１において、トラブルによって実行されなかったノード（サーバＢに対するサーバ起動）についても示している。サーバＢに対するサーバ起動は、異常を示す実行結果は得られなかったため、ＷＦ監視部１７は、ワークフロー１については影響が無いと判断する。ワークフロー４のサーバＢに対するサーバ起動でも同様の実行結果が得られることから、ＷＦ監視部１７は、ワークフロー４についても影響が無いと判断する。

ＷＦ監視部１７は、図２７に示すように、トラブルが発生したノードについては、ワークフロー上に矢印の遷移先を図示するとともに、運用操作部品が異常になる直接の原因をポップアップ等で表示する。

以下では、トラブルが発生したプロセス定義の表示処理（Ｓ６１）の詳細について、図２２を用いて詳述する。

図２２は、本実施形態におけるトラブルが発生したプロセス定義の表示処理（Ｓ６１）の詳細を示すフローチャートである。ＷＦ監視部１７は、プロセス定義テーブル１９から、トラブルが発生したノードのノードＩＤに対応する正常ルートの矢印情報を取り出す（Ｓ７１）。

ＷＦ監視部１７は、取得した矢印情報を用いて、プロセス定義テーブル１９から、その矢印の遷移先のノードＩＤとノード名とを取得する（Ｓ７２）。ＷＦ監視部１７は、Ｓ７２で取得したノード名に基づいて、ＷＦ管理テーブル２１から、作業対象を取得する（Ｓ７３）。ＷＦ監視部１７は、Ｓ７３で取得した作業対象を、影響作業対象リスト２４に格納する（Ｓ７４）。

ＷＦ監視部１７は、プロセス定義テーブル１９から、Ｓ７２で取得したノードＩＤについて、正常ルートの矢印情報を取り出す（Ｓ７５）。ＷＦ監視部１７は、取得した正常ルートの矢印情報から、１つの矢印情報を取り出す（Ｓ７６）。Ｓ７６にて矢印情報がある場合（Ｓ７７で「Ｙｅｓ」）、ＷＦ監視部１７は、Ｓ７２の処理へ進み、その矢印によって示される遷移先のノードについて、Ｓ７２以降の処理を行う。トラブルが発生したノード以降のノードについて、順次Ｓ７２〜Ｓ７６の処理を繰り返す。

Ｓ７６にて、矢印情報がない場合（Ｓ７７で「Ｎｏ」）、すなわち、終了ノードの場合、ＷＦ監視部１７は、次の処理を行う。すなわち、ＷＦ監視部１７は、トラブル発生ノードについて、実行結果テーブル２３から「実行結果」と、異常判断テーブル２２から「異常値」とを取得する。ＷＦ監視部１７は、「実行結果」が「異常値」に当てはまる場合は、異常と判断する（Ｓ７８）。

ＷＦ監視部１７は、トラブル発生ノードのノードＩＤ、プロセス定義名を用いて、プロセス定義テーブル１９、ＷＦ管理テーブル２１から、開始予定時刻を取得する。さらに、ＷＦ監視部１７は、トラブル発生ノードのノードＩＤを用いて、異常判断テーブル２２から、Ｓ７８で異常と判断したレコードに対応する「異常になる直接の原因」を取得する（Ｓ７９）。

ＷＦ監視部１７は、Ｓ７９で取得した情報を用いて、ＷｅｂＧＵＩに、ノードの機能が停止する理由（異常になる直接の原因）を出力し、さらに、異常ルートの矢印を図示する（Ｓ８０）。

メール通知の設定がされている場合（Ｓ８１で「Ｙｅｓ」）には、ＷＦ監視部１７は、本文にＷｅｂＧＵＩのＵＲＬ（Uniform Resource Locator）を記載し、電子メールを予め設定されたメールアドレスへ送信する（Ｓ８２）。

次に、トラブルが発生したノードの影響を受けるプロセス定義の表示処理（Ｓ６２）の詳細について、図２３及び図２４を用いて詳述する。

図２３は、本実施形態におけるトラブルが発生したノードの影響を受けるプロセス定義の表示処理（Ｓ６２）の詳細のフローチャートである。ＷＦ監視部１７は、影響作業対象リスト２４から、作業対象の一覧を取得する（Ｓ９１）。ＷＦ監視部１７は、Ｓ９１で取得した一覧から作業対象を１つ取り出す（Ｓ９２）。Ｓ９１において、作業対象がない場合（Ｓ９３で「Ｎｏ」）、本フローは終了する。

取得した作業対象がある場合（Ｓ９３で「Ｙｅｓ」）、ＷＦ監視部１７は、ＷＦ管理テーブル２１から、その作業対象を使用するプロセス定義、かつトラブル開始時刻以降のプロセス定義の一覧を取得する（Ｓ９４）。

ＷＦ監視部１７は、Ｓ９４で取得した一覧からプロセス定義を１つ取り出す（Ｓ９５）。Ｓ９５において、取得できるプロセス定義がない場合（Ｓ９６で「Ｎｏ」）、ＷＦ監視部１７は、Ｓ９２へ戻り、Ｓ９１で取得した一覧から次の作業対象を１つ取り出し、Ｓ９３以降の処理を行う。

Ｓ９５において、取得できるプロセス定義がある場合（Ｓ９６で「Ｙｅｓ」）、ＷＦ監視部１７は、そのプロセス定義において、開始ノードから遷移するノードＩＤを取得する（Ｓ９７）。ＷＦ監視部１７は、Ｓ９７で取得したノードＩＤを用いて、プロセス定義内のノードを調査する（Ｓ９８）。Ｓ９８については、図２４を用いて説明する。

メール通知の設定がされている場合（Ｓ９９で「Ｙｅｓ」）には、ＷＦ監視部１７は、本文にＷｅｂＧＵＩのＵＲＬを記載し、電子メールを予め設定されたメールアドレスへ送信する（Ｓ１００）。
Ｓ９４で取得したプロセス定義の数だけ、Ｓ９５〜Ｓ１００の処理を繰り返す。

図２４は、Ｓ９８の詳細処理を示すフローチャートである。Ｓ９７で取得したノードＩＤが示すノードが、そのプロセス定義において、終了ノードである場合（Ｓ１０１で「Ｙｅｓ」）、図２４のフローは終了する。取得したノードＩＤが示すノードが、そのプロセス定義において、終了ノードでない場合（Ｓ１０１で「Ｎｏ」）、ＷＦ監視部１７は、そのノードＩＤに基づいて、プロセス定義テーブル１９から、運用操作部品名を取得する（Ｓ１０２）。

ＷＦ監視部１７は、プロセス定義名、ノードＩＤ、運用操作部品名に基づいて、実行結果テーブル２３に格納された実行結果と、異常判断テーブル２２に格納された異常値とを取得する（Ｓ１０３）。異常値に当てはまる実行結果が存在しない場合（Ｓ１０４で「Ｎｏ」）、Ｓ１０８の処理へ進む。

異常値に当てはまる実行結果が１つ以上存在する場合（Ｓ１０４で「Ｙｅｓ」）、ＷＦ監視部１７は、次の処理を行う。すなわち、ＷＦ監視部１７は、ＷＦ管理テーブル２１を参照して、Ｓ１０２で取得した運用操作部品が、影響作業対象リスト２４に格納された作業対象を使用した運用操作部品であるか判定する（Ｓ１０５）。Ｓ１０２で取得した運用操作部品が、影響作業対象リスト２４に格納された作業対象を使用した運用操作部品でない場合（Ｓ１０５で「Ｎｏ」）、Ｓ１０８の処理へ進む。

Ｓ１０２で取得した運用操作部品が、影響作業対象リスト２４に格納された作業対象を使用した運用操作部品である場合（Ｓ１０５で「Ｙｅｓ」）、ＷＦ監視部１７は、次の処理を行う。すなわち、ＷＦ監視部１７は、そのノードＩＤに基づいて、ＷＦ管理テーブル２１から「プロセス定義名」及び「開始予定時刻」、異常判断テーブル２２から「異常になる直接の原因」を取得する（Ｓ１０６）。

ＷＦ監視部１７は、Ｓ７９で取得した情報を用いて、ＷｅｂＧＵＩに、ノードの機能が停止する理由（異常になる直接の原因）を出力し、さらに、異常ルートの矢印を図示する（Ｓ１０７）。

ＷＦ監視部１７は、ＷＦ管理テーブル２１から、次に遷移するノードＩＤを取得し（Ｓ１０８）、Ｓ１０１の処理へ戻る。プロセス定義（ワークフロー）内の全ノードについて処理が終わるまで、Ｓ１０１〜Ｓ１０８の処理を繰り返す。

なお、本実施形態において、表示は、Ｗｅｂ−ＧＵＩに限定するものではなく、異常と判断したノード・遷移先・運用操作部品が異常になる直接の原因を、メールなど一般的な運用者への通知手段で通知することも可能である。この通知手段はメールだけではなく、他の機能（イベントログ通知、他のサーバへのメッセージ通知）に渡すことが可能である。

本実施形態によれば、トラブルにより正常ルートを走行しないことによる他のワークフローへの作業影響を把握することが出来る。また、後続作業への作業影響を把握するだけではなく、運用操作部品が異常になる直接の原因と遷移先を提示することが出来る。
また、トラブルの影響と運用操作部品が異常になる直接の原因が分かることにより、影響するワークフローが動作して正常に動かなくなる前に事前に対処する（影響が波及しないよう事前にワークフローを停止する／ワークフローの運用を延期する）ことが可能となる。

図２８は、本実施形態の実施例におけるプログラムを実行するコンピュータのハードウェア環境の構成ブロック図の一例である。コンピュータ１１は、翻訳装置として機能する。コンピュータ１１は、ＣＰＵ４２、ＲＯＭ４３、ＲＡＭ４６、通信Ｉ／Ｆ４４、記憶装置４７、出力Ｉ／Ｆ４１、入力Ｉ／Ｆ４５、読み取り装置４８、バス４９、出力機器５１、入力機器５２によって構成されている。

ここで、ＣＰＵは、中央演算装置を示す。ＲＯＭは、リードオンリメモリを示す。ＲＡＭは、ランダムアクセスメモリを示す。Ｉ／Ｆは、インターフェースを示す。バス４９には、ＣＰＵ４２、ＲＯＭ４３、ＲＡＭ４６、通信Ｉ／Ｆ４４、記憶装置４７、出力Ｉ／Ｆ４１、入力Ｉ／Ｆ４５、及び読み取り装置４８が接続されている。読み取り装置４８は、可搬型記録媒体を読み出す装置である。出力機器４１は、出力Ｉ／Ｆ４１に接続されている。入力機器５２は、入力Ｉ／Ｆ４５に接続にされている。

記憶装置４７としては、ハードディスク、フラッシュメモリ、磁気ディスクなど様々な形式の記憶装置を使用することができる。記憶装置４７またはＲＯＭ４３には、ＣＰＵ４２を自動化フローシステム１１として機能させるプログラム、本実施形態に係るプログラムが格納されている。さらに、記憶装置４７には、記憶部１８として、プロセス定義テーブル１９、影響範囲テーブル２０、ＷＦ管理テーブル２１、異常判定テーブル２２、実行結果テーブル２３、影響作業対象リスト２４が格納されている。

ＣＰＵ４２は、記憶装置４７等に格納した上記実施形態で説明した処理を実現するプログラムを読み出して当該プログラムを実行し、ＷＦ制御部１４、ＷＦ監視部１７として機能する。

上記実施形態で説明した処理を実現するプログラムは、プログラム提供者側から通信ネットワーク５０、および通信Ｉ／Ｆ４４を介して、例えば記憶装置４７に格納されてもよい。また、上記実施形態で説明した処理を実現するプログラムは、市販され、流通している可搬型記憶媒体に格納されていてもよい。この場合、この可搬型記憶媒体は読み取り装置４８にセットされて、ＣＰＵ４２によってそのプログラムが読み出されて、実行されてもよい。可搬型記憶媒体としてはＣＤ−ＲＯＭ、フレキシブルディスク、光ディスク、光磁気ディスク、ＩＣカード、ＵＳＢメモリ装置など様々な形式の記憶媒体を使用することができる。このような記憶媒体に格納されたプログラムが読み取り装置４８によって読み取られる。

また、入力機器５２には、キーボード、マウス、電子カメラ、ウェブカメラ、マイク、スキャナ、センサ、タブレットなどを用いることが可能である。また、出力機器５１には、ディスプレイ、プリンタ、スピーカなどを用いることが可能である。また、ネットワーク５０は、インターネット、ＬＡＮ、ＷＡＮ、専用線、有線、無線等の通信網であってよい。

実施形態を適用しない場合、作業の完了予定時刻を遅延したトラブルのみ後続作業の影響を把握していたが、この方法では完了予定時刻を遅延しないトラブル発生時において後続への影響を把握するという要求に対応できない。

しかしながら、本実施形態を適用することにより、トラブルが発生した際の異常データに着目し、作業の影響を発生させる要因である運用操作部品が異常になる直接の原因を特定し、後続のノードの遷移先を特定することができる。これにより、正常ルートが走行しないことによる作業対象の今後の状態を正確に予測できるとともに、その作業情報に基づいて、他のワークフローへの影響を明らかにすることができる。

なお、本発明は、以上に述べた実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。

上記実施形態に関し、更に以下の付記を開示する。
（付記１）
コンピュータに、
複数の処理手順を順次処理する管理対象のシステムにおける異常の発生を検知し、
前記異常の発生の検知に応じて、当該異常の発生した、前記複数の処理手順に含まれる処理を特定し、
前記複数の処理手順の処理内容および処理順序を規定する処理手順情報を参照し、前記複数の処理手順のうち、前記特定した処理で発生した異常の影響を受ける後段処理手順を特定し、
前記複数の処理手順による出力情報のうち、前記特定した処理、または、前記後段処理手順に関連した出力情報を特定する、
処理を実行させる処理管理プログラム。
（付記２）
前記処理の特定において、前記管理対象のシステムに含まれる情報処理装置から、前記特定した処理に基づいて処理を実行する情報処理装置を特定し、
前記後段処理手順の特定において、特定された前記情報処理装置に対する処理を含む、前記異常の発生の検知後に実行予定の他の処理手順のうち、該他の処理手順の実行結果に応じて、前記特定した処理で発生した異常の影響を受ける処理手順の判定を行う
処理を実行させることを特徴とする付記１に記載の処理管理プログラム。
（付記３）
前記判定において、前記処理に異常が発生した場合にその異常を確認する確認方法と該確認により異常と判定する異常条件とを含む異常確認情報が格納された記憶部から取得した該異常確認情報を用いて、前記異常の発生の検出以降に実行される処理手順に対する確認方法を実行して実行結果を取得する
ことを特徴とする付記２に記載の処理管理プログラム。
（付記４）
前記判定において、特定された前記情報処理装置に対する処理を含む、前記異常の発生の検出以降の前記他の処理手順を特定し、特定した該他の処理手順に含まれる前記処理に対応する前記確認方法による実行結果のいずれかが前記異常条件を満たす場合、該他の処理手順を、該処理で発生した異常の影響を受ける処理手順であると判定する
ことを特徴とする付記３に記載の処理管理プログラム。
（付記５）
前記コンピュータに、さらに、
前記特定した処理で発生した異常の影響を受ける後段処理手順を表示する、
処理を実行させ、
前記異常確認情報は、さらに、前記確認方法と前記異常情報とに関係付けて、該異常条件に該当した場合の異常の原因を示す情報を含み、
前記表示をする場合、前記後段処理手順に含まれる処理のうち、前記確認方法による実行結果のいずれかが前記異常条件を満たす処理を取得し、該異常確認情報から、取得した該処理に対応する前記異常の原因を示す情報を取得し、前記後段処理手順と共に、取得した該異常の原因を示す情報を表示する
ことを特徴とする付記４に記載の処理管理プログラム。
（付記６）
複数の処理手順を順次処理する管理対象のシステムにおける異常の発生を検知する検知部と、
前記異常の発生の検知に応じて、当該異常の発生した、前記複数の処理手順に含まれる処理を特定する処理特定部と、
前記複数の処理手順の処理内容および処理順序を規定する処理手順情報を参照し、前記複数の処理手順のうち、前記特定した処理で発生した異常の影響を受ける後段処理手順を特定する手順特定部と、
前記複数の処理手順による出力情報のうち、前記特定した処理、または、前記後段処理手順に関連した出力情報を特定する出力特定部と、
処理を実行させる処理管理装置。
（付記７）
前記処理特定部は、前記管理対象のシステムに含まれる情報処理装置から、前記特定した処理に基づいて処理を実行する情報処理装置を特定し、
前記手順特定部は、前記後段処理手順の特定において、特定された前記情報処理装置に対する処理を含む、前記異常の発生の検知後に実行予定の他の処理手順のうち、該他の処理手順の実行結果に応じて、前記特定した処理で発生した異常の影響を受ける処理手順の判定を行う
処理を実行させることを特徴とする付記６に記載の処理管理プログラム。
（付記８）
前記処理管理装置は、さらに、
前記処理に異常が発生した場合にその異常を確認する確認方法と該確認により異常と判定する異常条件とを含む異常確認情報が格納された記憶部
を備え、
前記処理特定部は、前記記憶部から取得した該異常確認情報を用いて、前記異常の発生の検出以降に実行される処理手順に対する確認方法を実行して実行結果を取得する
ことを特徴とする付記７に記載の処理管理装置。
（付記９）
前記手順特定部は、特定された前記情報処理装置に対する処理を含む、前記異常の発生の検出以降の前記他の処理手順を特定し、特定した該他の処理手順に含まれる前記処理に対応する前記確認方法による実行結果のいずれかが前記異常条件を満たす場合、該他の処理手順を、該処理で発生した異常の影響を受ける処理手順であると判定する
ことを特徴とする付記８に記載の処理管理装置。
（付記１０）
前記処理管理装置は、さらに、
前記特定した処理で発生した異常の影響を受ける後段処理手順を表示する表示制御部
を備え、
前記異常確認情報は、さらに、前記確認方法と前記異常情報とに関係付けて、該異常条件に該当した場合の異常の原因を示す情報を含み、
前記表示制御部は、前記後段処理手順に含まれる処理のうち、前記確認方法による実行結果のいずれかが前記異常条件を満たす処理を取得し、該異常確認情報から、取得した該処理に対応する前記異常の原因を示す情報を取得し、前記後段処理手順と共に、取得した該異常の原因を示す情報を表示する
ことを特徴とする付記９に記載の処理管理装置。
（付記１１）
コンピュータが、
複数の処理手順を順次処理する管理対象のシステムにおける異常の発生を検知し、
前記異常の発生の検知に応じて、当該異常の発生した、前記複数の処理手順に含まれる処理を特定し、
前記複数の処理手順の処理内容および処理順序を規定する処理手順情報を参照し、前記複数の処理手順のうち、前記特定した処理で発生した異常の影響を受ける後段処理手順を特定し、
前記複数の処理手順による出力情報のうち、前記特定した処理、または、前記後段処理手順に関連した出力情報を特定する、
ことを特徴とする処理管理方法。
（付記１２）
前記処理の特定において、前記管理対象のシステムに含まれる情報処理装置から、前記特定した処理に基づいて処理を実行する情報処理装置を特定し、
前記後段処理手順の特定において、前記後段処理手順の特定において、特定された前記情報処理装置に対する処理を含む、前記異常の発生の検知後に実行予定の他の処理手順のうち、該他の処理手順の実行結果に応じて、前記特定した処理で発生した異常の影響を受ける処理手順の判定を行う
処理を実行させることを特徴とする付記１１に記載の処理管理方法。
（付記１３）
前記判定において、前記処理に異常が発生した場合にその異常を確認する確認方法と該確認により異常と判定する異常条件とを含む異常確認情報が格納された記憶部から取得した該異常確認情報を用いて、前記異常の発生の検出以降に実行される処理手順に対する確認方法を実行して実行結果を取得する
ことを特徴とする付記１２に記載の処理管理方法。
（付記１４）
前記判定において、特定された前記情報処理装置に対する処理を含む、前記異常の発生の検出以降の前記他の処理手順を特定し、特定した該他の処理手順に含まれる前記処理に対応する前記確認方法による実行結果のいずれかが前記異常条件を満たす場合、該他の処理手順を、該処理で発生した異常の影響を受ける処理手順であると判定する
ことを特徴とする付記１３に記載の処理管理方法。
（付記１５）
前記コンピュータが、さらに、前記特定した処理で発生した異常の影響を受ける後段処理手順を表示し、
前記異常確認情報は、さらに、前記確認方法と前記異常情報とに関係付けて、該異常条件に該当した場合の異常の原因を示す情報を含み、
前記コンピュータが前記表示をする場合、前記後段処理手順に含まれる処理のうち、前記確認方法による実行結果のいずれかが前記異常条件を満たす処理を取得し、該異常確認情報から、取得した該処理に対応する前記異常の原因を示す情報を取得し、前記後段処理手順と共に、取得した該異常の原因を示す情報を表示する
ことを特徴とする付記１４に記載の処理管理方法。

１ 処理管理装置
２ 特定部
３ 判定部
４ 記憶部
５ 表示制御部
６ 情報処理装置
１１ 自動化フローシステム
１２ 管理サーバ
１３ 制御部
１４ ＷＦ制御部
１７ ＷＦ監視部
１８ 記憶部
１９ プロセス定義テーブル
２０ 影響範囲リスト
２１ ＷＦ管理テーブル
２２ 移行判断テーブル
２３ 実行結果テーブル
２４ 影響作業対象リスト
３０ 対象サーバ

Claims (4)

1. コンピュータに、
   複数の処理手順を順次処理する管理対象のシステムにおける異常の発生を検知し、
   前記異常の発生の検知に応じて、当該異常の発生した処理を含む処理手順を前記複数の処理手順のうちから特定し、
   前記複数の処理手順の処理内容および処理順序を規定する処理手順情報を参照し、順次処理される前記複数の処理手順のうち前記特定した処理手順よりも後に処理される処理手順であって、前記特定した処理手順で発生した異常の影響を受ける処理手順である後段処理手順を特定し、
   前記複数の処理手順による出力情報のうち、前記特定した処理手順、または、前記後段処理手順に関連した出力情報を特定する、
   処理を実行させ、
   前記後段処理手順の特定においては、処理が異常となる原因が発生するか否かを判定する確認方法と、該確認方法において該処理が異常となる原因が発生するとの判定を下す異常条件とを処理毎に含む異常確認情報が格納された記憶部から取得した該異常確認情報を用いて、順次処理される前記複数の処理手順のうち前記特定した処理手順よりも後に処理される処理手順に含まれる処理に対し、処理に応じた前記確認方法を実行して、処理が異常となる原因が発生するか否かを処理に応じた前記異常条件に基づき判定し、異常となる原因が発生する処理がある場合、前記特定した処理手順よりも後に処理される処理手順を前記後段処理手順として特定する
   ことを特徴とする処理管理プログラム。
2. 前記コンピュータに、さらに、
   前記後段処理手順を表示する、
   処理を実行させ、
   前記異常確認情報は、さらに、処理毎の前記確認方法と前記異常条件とに関係付けて、処理に対して該確認方法を実行した場合に発生するとの判定が該異常条件に基づき下される、該処理が異常となる原因を示す情報を含み、
   前記表示をする場合、前記後段処理手順に含まれる処理のうち、前記確認方法による実行結果のいずれかが前記異常条件を満たす処理を取得し、前記異常確認情報から、取得した該処理に対応する前記異常となる原因を示す情報を取得し、前記後段処理手順と共に、取得した該異常となる原因を示す情報を表示する
   ことを特徴とする請求項１に記載の処理管理プログラム。
3. 複数の処理手順を順次処理する管理対象のシステムにおける異常の発生を検知する検知部と、
   前記異常の発生の検知に応じて、当該異常の発生した処理を含む処理手順を前記複数の処理手順のうちから特定する処理特定部と、
   前記複数の処理手順の処理内容および処理順序を規定する処理手順情報を参照し、順次処理される前記複数の処理手順のうち前記特定した処理手順よりも後に処理される処理手順であって、前記特定した処理手順で発生した異常の影響を受ける処理手順である後段処理手順を特定する手順特定部と、
   前記複数の処理手順による出力情報のうち、前記特定した処理手順、または、前記後段処理手順に関連した出力情報を特定する出力特定部と、
   処理が異常となる原因が発生するか否かを判定する確認方法と該確認方法において該処理が異常となる原因が発生するとの判定を下す異常条件とを処理毎に含む異常確認情報が格納された記憶部と、
   を備え、
   前記手順特定部は、前記記憶部から取得した前記異常確認情報を用いて、順次処理される前記複数の処理手順のうち前記特定した処理手順よりも後に処理される処理手順に含まれる処理に対し、処理に応じた前記確認方法を実行して、処理が異常となる原因が発生するか否かを処理に応じた前記異常条件に基づき判定し、異常となる原因が発生する処理がある場合、前記特定した処理手順よりも後に処理される処理手順を前記後段処理手順として特定する
   ことを特徴とする処理管理装置。
4. コンピュータが、
   複数の処理手順を順次処理する管理対象のシステムにおける異常の発生を検知し、
   前記異常の発生の検知に応じて、当該異常の発生した処理を含む処理手順を前記複数の処理手順のうちから特定し、
   前記複数の処理手順の処理内容および処理順序を規定する処理手順情報を参照し、順次処理される前記複数の処理手順のうち前記特定した処理手順よりも後に処理される処理手順であって、前記特定した処理手順で発生した異常の影響を受ける後段処理手順を特定し、
   前記複数の処理手順による出力情報のうち、前記特定した処理手順、または、前記後段処理手順に関連した出力情報を特定し、
   前記後段処理手順の特定においては、処理が異常となる原因が発生するか否かを判定する確認方法と、該確認方法において該処理が異常となる原因が発生するとの判定を下す異常条件とを処理毎に含む異常確認情報が格納された記憶部から取得した該異常確認情報を用いて、順次処理される前記複数の処理手順のうち前記特定した処理手順よりも後に処理される処理手順に含まれる処理に対し、処理に応じた前記確認方法を実行して、処理が異常となる原因が発生するか否かを処理に応じた前記異常条件に基づき判定し、異常となる原因が発生する処理がある場合、前記特定した処理手順よりも後に処理される処理手順を前記後段処理手順として特定する
   ことを特徴とする処理管理方法。

Images