JP5942481B2 - 運用作業管理システム、方法、及びプログラム - Google Patents

Description

本発明は、運用作業の管理システム、方法、及びプログラムに関する。

従来から、業務の進捗状況を管理すると共に、業務スケジュールの変更にも対応できるスケジュール管理技術が存在している。

例えば、複数の業務を管理するための、プロジェクトマネジメントツールとして様々なソフトウエアが存在する。このプロジェクトマネジメントツールを用いることにより、例えば、情報システム開発プロジェクトを遂行する際の様々な業務を管理することができる。プロジェクトの各工程における作業の進捗状態などをグラフ化して表示したり、プロジェクト全体の進捗状況を把握したりすることができるようになっている。

しかしながら、データセンタなどで、複数サーバなどの装置が実行を担当する運用作業と、オペレータなどの人間が担当する運用作業が複雑に絡み合って、一つの運用作業が遂行される環境においては、その運用作業を管理することは容易ではない。しかも、通常、複数の運用作業が並行して存在している。この複数の運用作業は、密接に関連している場合もある。あるいは、相互に全く関連していない業務もある。近年においては、さらに仮想化技術の進展により、外見上は全く関連していない業務であっても、同一のサーバに複数の仮想マシンが動作している場合には、相互に動作環境において影響を及ぼすことがある。

このように、例えば、データセンタなどにおいて、計算機資源を用いる運用作業では、１つの運用作業の中に装置系作業と、人間系作業（例えば、承認作業や装置系作業の結果確認等）が混在している。この場合、オペレータ（作業者）は、通常、作業手順書を見てこれらの作業を実施している。

このうち装置系作業については、例えば、ジョブ管理ツールにより自動化され、作業管理もツールによって行われる。しかしながら、人間系作業はジョブ管理ツールで作業管理をすることは行われていない。また、上述のプロジェクトマネジメントツールは、人間の業務を中心に管理を行うために設計されている。したがって、プロジェクトマネジメントツールは、装置系作業が絡んだ業務に対する管理には向いていない。

このため、人間系作業と装置系作業が混在した運用作業の管理は、その多くの部分が人手で行われているのが現状である。管理対象作業の数や規模が巨大化した場合、全ての運用作業を追跡し管理するには時間と手間がかかり過ぎてしまう。また、人手による管理では、運用作業に内在しているリスクを見落としてしまう場合がある。加えて、突発的なシステムトラブルなどに対して、適切な対応が行えず、業務の中断が長期化してしまう場合もある。したがって、例えば装置系作業が何らかのトラブルにより遅延した場合に、人間系作業を含む全体の運用作業にどのような影響があるのかも簡単に把握することができない場合が多い。

従来、運用作業を構成する複数の作業工程の処理履歴を記録したイベントレコードを時系列順に配したイベントログから、作業工程の処理順序に関する時系列パターンを生成する時系列パターンを生成する技術が知られている。この技術では、作業の履歴情報に基づいて業務を分析するシステムに適用することができる。特に、案件ごとに履歴情報を抽出することを可能としているため、複数の業務の履歴情報が混在するシステムに適用できる（特許文献１参照）。

特開２００７―３２８７１２号公報

本願発明の１つの側面では、複数の運用作業を適切に管理することを目的とする。

本発明の１つの側面は、装置の作業及び人間の作業を含む複数の作業と、前記複数の作業の順序とを有する運用作業の情報を受け入れる入力部と、前記複数の作業の各々に要する作業時間を、時間決定規則に基づいて決定する、作業時間決定部と、前記決定された各作業時間を、対応する前記装置の作業又は前記人間の作業にそれぞれ対応付けた複数のプロセス定義を生成する、前記運用作業の情報に含ませることによって生成される、プロセス定義生成部と、前記複数のプロセス定義と分析規則に基づいて前記複数の作業の各々の間の依存関係、及び／又はリスクを抽出する抽出部と、前記依存関係、及び／又は前記リスクを可視的に出力するための出力情報を生成する出力情報生成部と、を有するシステムを提供する。

本発明の１つの側面によれば、複数の運用作業を適切に管理することができる。

運用作業を示すプロセス定義の一例を示した図である。 本発明に従った一実施形態のブロック図である。 本発明に従った実施形態のフローを示す図である。 新たな運用作業を受け入れる場合の実施形態の全体フローを示す図である。 人間系ノードの分析に関する実施形態のフローを示す図である。 装置系ノードの分析に関する実施形態のフローを示す図である。 作業監視に関する一実施形態のフローを示す図である。 トラブル発生に関する一実施例のフローを示す図である。 波及分析に関する一実施例のフローを示す図である。 一実施例におけるプロセス定義をフローと木構造で表現す図である。 一実施例におけるノードの依存関係とリスクを示す表である。 一実施例におけるメッセージ情報を示す表である。 一実施例におけるハードウェア構成を示す図である。

図１は、運用作業を示すプロセス定義の一例を示している。データセンタ等においては、人間の運用作業（人間系作業）と、装置の作業（装置系作業）とが混在して、１つのワークフローを形成している。本明細書では、人間系作業と装置系作業を含むワークフローを「プロセス定義」と呼ぶ。そして、プロセス定義内の個々の運用作業の構成要素を「ノード」と呼ぶ。

図１では、開始ノード１０２から始まる。開始ノード１０２は、例えば、このプロセス定義の開始時刻（年月日時刻）を含んでもよい。次の人間系作業１０４は、人間が行う運用作業を示している（人間系作業のノードを人間系ノードと呼ぶ）。このノードには、作業者、作業内容（例えば、申請、承認、確認）に関する情報が含まれる。これらの情報は、プロセス定義の際に、オペレータにより入力されてもよい。また、この作業にかかる時間、作業開始時刻、作業終了時刻等の情報は、所定のデフォルト値や、過去の同じ作業の情報を蓄積しておき、例えば平均値を求めることにより、システムが自動的に設定してもよい。

次の装置系作業１０６は、サーバ等の装置が行う作業を示している（装置系作業のノードを装置系ノードと呼ぶ）。このノードには、例えば、サーバを特定する情報、処理内容（例えば、サーバの起動、サーバの停止、ＶＭの起動）に関する情報が含まれる。これらの情報は、プロセス定義の際に、オペレータにより入力されてもよい。また、この作業にかかる時間、作業開始時刻、作業終了時刻等の情報は、所定のデフォルト値や、過去の同じ作業の情報を蓄積しておき、その時刻におけるサーバの負荷の推定等を基にして求めることにより、システムが自動的に設定してもよい。その後の装置系作業１０８、人間系作業１１０についても同様である。終了ノード１０２には、このプロセス定義の終了予定時刻を格納してもよい。

なお、人間系作業であるか装置系作業であるかの切り分けは、その作業主体によって行ってもよい。言葉を換えて表現すれば、運用作業の主語が人間であれば人間系作業であり、運用作業の主語が装置であれば装置系作業である。

図２は、本発明に従った一実施形態のブロック図を示している。入力部２０２は、プロセス定義を作成するための運用作業の流れをオペレータから受け取る（図１参照）。まず、その運用作業の開示予定時刻が入力され、開始ノードが作成される。そして、プロセス定義の各ノードの情報が入力される。人間系作業であれば、作業者名、作業内容（例えば、申請、承認、確認）に関する情報が入力されてもよい。装置系作業であれば、処理内容（例えば、サーバの名称、サーバの起動、サーバの停止、ＶＭの起動）に関する情報が入力されてもよい。

作業時間決定部２０４は、各ノードの作業時間を決定する。例えば、人間系ノードの分析処理の初めに、過去３年間の作業実績（プロセス定義の稼動実績）があるかどうかをデーベースＤＢ２１０に問い合わせる。作業実績を利用する理由は、分析対象ノードの作業時間を精度よく推測することができるようにするためである。過去に実績がある場合は、過去３年間の作業実績時間の例えば平均値を、分析対象ノードの作業時間としてもよい。作業実績が無い場合は、所定のデフォルト値を作業時間としてもよい。作業時間の予測はプロセス定義の実績がＤＢ２１０に蓄積されるほど精度が上昇していく。ＤＢ２１０は記憶部の具体例である。

なお、この推定された作業時間に、環境負荷割合による補正を加えてもよい。特に装置系ノードの場合には、サーバが複数の運用作業のプログラムを同時に実行している場合がある。また、１つのサーバが複数の仮想マシンを稼働させている場合もある。環境負荷割合とは、作業負荷（作業負荷度合）から算出される補正値（追加する時間)であり、作業環境のマシン性能および作業負荷の高さに応じて、推定された作業時間に所定の算出式を用いて補正値を計算して加えてもよい。また、人間系ノードにおいても、例えば、メールを書く作業と監視を行う作業とでは、作業負荷（作業負荷度合）が異なる。したがって、作業負荷に応じて、推定された作業時間に所定の算出式を用いて補正値を計算して加えてもよい。

プロセス定義生成部２０６は、作業時間決定部２０４からの作業時間の推定値を用いて、各ノードの作業開始時刻、作業終了時刻を含む情報を算出し、プロセス定義を生成する。開始ノードの開始時刻は、オペレータにより与えられるため、その後につづくノードの開始時刻と終了時刻とは、作業時間を使って順次算出することができる。

生成されたプロセス定義は、ＤＢ２１０に格納してもよい。ＤＢ２１０に格納されるプロセス定義の情報は、図１１に示される情報が含まれる。なお、図１１については後述する。

プロセス定義生成部２０６には、プロセス定義修正部２０８が含まれる。プロセス定義修正部は、障害発生があった場合や、運用作業の定期的な監視において運用作業の遅れが発見された場合等に、作業時間決定部２０４と連携しながら、プロセス定義の修正を行う。

ＤＢ２１０は、上述のようにプロセス定義を格納してもよい。また、過去のプロセスの実績を蓄積し、作業時間の決定のために、その蓄積データを提供してもよい。ＤＢ２１０は、人間系作業のデータと装置系作業のデータを分けて蓄積してもよい。ＤＢ２１０に格納されるデータは、テーブル形式であってもよい（図１１参照）。なお、各ノードが、どのプロセス定義で用いられるかを判別するために、各ノードのデータには、プロセス定義毎にユニークなキーを保存してもよい。

また、ＤＢ２１０には、運用作業の矛盾を発見するための規則を格納してもよい。例えば、「サーバを起動する」という作業と、「サーバを停止する」と言う作業は、重なる時間帯で作業を行うと矛盾を生じてしまう。このような矛盾の規則をＤＢ２１０に蓄積してもよい。また、運用作業の遅れの許容範囲を判断するために、運用作業に対応して、ＤＢ２１０に遅れの閾値を格納してもよい。また、トラブルが発生した場合に、回復時間を予測するために、過去におけるトラブルの種別とその回復時間を、ＤＢ２１０に蓄積してもよい。また、新規なトラブルのために、回復時間のデフォルト値を格納してもよい。ＤＢ２１０には、本明細書に記載する各種実施形態において利用されるその他の規則、閾値、デフォルト値等を格納してもよい。

抽出部２１２は、プロセス定義を分析規則（例えば、上述の過去の情報、閾値、デフォルト値、矛盾の規則等）を用いて分析を行う。そして、抽出部２１２は、各ノード間の依存関係、及び／又は、リスク（例えば、矛盾の存在、遅れの存在等）を抽出する。この分析及び抽出のために、ＤＢ２１０に蓄積された情報が利用される。

抽出部２１２は、プロセス定義生成部２０６の出力によって起動されてもよい。典型的な例としては、入力部が新たな運用作業の情報を受け取った場合が挙げられる。新たな運用作業の情報は、プロセス定義生成部でプロセス定義が生成される。そして、生成されたプロセス定義は、抽出部２１２において、他のプロセス定義と比較分析される。そして、依存関係とリスクが抽出される。これによって、オペレータは、入力した運用作業が他のプロセス定義とどのような関係を持つか、リスクが存在するか否かをチェックすることができる。オペレータは、この結果を基に、新たな運用作業の見直しを行ってもよい。

また、抽出部２１２は、抽出部起動部２１４によって、定期的に起動されてもよい。典型的な例としては、抽出部起動部２１４のタイマによって、一定間隔で抽出部を起動してもよい。抽出部２１２の定期的な起動によって、データセンタ等の大規模な業務を定期的に診断することができる。抽出部２１２は、現在動作しているノードをチェックして、実行予定の情報と比較を行なう。抽出部２１２は、この場合、例えば、あるノードの遅れが、所定の閾値よりも大きい場合、リスクありと判断する。そして、そのリスクが他のプロセス定義にどのように波及するかをチェックしてもよい。この結果得られたリスクの情報は、出力情報生成部２１６によって加工され、オペレータに分かりやすい形で出力してもよい。オペレータは、この出力を基にして、適切な対応をとることができる。

出力情報生成部２１６は、抽出されたノード間の依存関係、及び／又は、リスクをオペレータに分かりやすい形式の出力情報に変換する。出力情報としては、木構造（図１０（Ｂ）参照）や、メッセージ情報（図１２参照）を採用してもよい。この出力情報は、例えば、ディスプレイで表示するための情報、プリンタで印刷するための情報、Ｅ−ｍａｉｌでの送信するための情報などである。

図３は、本発明に従った実施形態のフローを示している。

ステップ３０２において、運用作業の情報を受け入れる。運用作業の開始予定時刻が入力される。そして、人間系作業であれば、作業者、作業内容等が入力される。装置系作業であれば、サーバを特定する情報、作業内容等が入力される。

ステップ３０４において、所定の時間決定規則に従って、各運用作業の作業時間が決定される。所定の時間決定規則としては、上述のように、過去の実績値の平均やデフォルト値、環境負荷割合、作業負荷度合等が利用されてもよい。

ステップ３０６において、プロセス定義が生成される。また、上述のように、すでに生成されたプロセス定義が修正されてもよい。決定された作業時間に基づいて、各ノードの作業開始時刻、及び作業終了時刻が算出され、これらの値がプロセス定義に加えられる。

ステップ３０８において、運用作業の依存関係、及び／又は、リスクが抽出される。上述のように、所定の分析規則が適宜用いられてもよい。なお、依存関係は、例えば、同一のサーバに係るノードや、同一作業者に係るノードによって分析を行ってもよい。

ステップ３１０において、リスクがあるか否かが判断される。「いいえ」であれば、ステップ３１４に進む。また、「はい」である場合には、ステップ３１２に移る。

ステップ３１２において、分析が全て終了しているかがチェックされる。「いいえ」であれば、ステップ３０４に戻る。この場合には、リスクが存在するため、その波及を調べる必要がある。このため、再度ステップ３０４において、波及するプロセス定義を調べ、作業時間の再算出が行われ、それ以下一連の処理が再度行われる。ステップ３１２において、全ての分析が終了した場合（新たなリスクが、未分析のプロセス定義で発見されなくなった場合）、ステップ３１４に移る。

ステップ３１４においては、依存関係、及び／又は、リスクの出力情報を生成する。

ステップ３１６においては、生成された出力情報が、ディスプレイ等の出力装置に出力される。

また、ステップ３２０は、障害発生のイベントによりアクティベートされる。障害は突発的に発生した場合には、ステップ３０４において、障害回復時間が推定される。この推定においては、過去の同様の障害に対する回復時間の情報の平均値を用いてもよい。あるいは、所定のデフォルト値を用いてもよい。あるいは、オペレータにより設定（又は修正）された値を用いてもよい。

ステップ３３０は、監視のための起動指示のイベントによりアクティベートされる。この起動指示によって、ステップ３０８が動作し、例えば、現在実行中のノードが遅れているか否かがチェックされてもよい。遅れているか否かは、遅れている時間と所定の閾値とを比較して、判断してもよい。遅れが所定の閾値を超えていれば、リスクありと判断される。その後の処理は、上述と同様であり、リスクの波及についてもチェックがなされてもよい。

図４は、新たな運用作業を受け入れる場合の実施形態の全体フローを示している。

ステップ４０２において、新たな運用作業が受け入れられる。そして、プロセス定義の生成がなされる。

ステップ４０４において、受け入れたプロセス定義の先頭のノードが選択される。そして、先頭のノードの分析が開始される。

ステップ４０６において、ノードの分類が行われる。すなわち、ノードは、人間系作業であるか、装置系作業であるかに振り分けられる。

ステップ４０８においては、人間系ノードの分析が行われる。この分析の詳細は、図５において説明する。

ステップ４１０においては、装置系ノードの分析が行われる。この分析の詳細は、図６において説明する。

ステップ４１２において、プロセス定義の終端か否かがチェックされる。「いいえ」であれば、ステップ４２０において、次のノードにフォーカスを移し、ステップ４０６に戻る。「はい」であれば、ステップ４１４に移る。

ステップ４１４においては、各ノードの分析・抽出結果をマージして、記憶部（ＤＢ）に格納する。なお、この場合、人間系ノードと装置系ノードとで、別の記憶領域にデータを格納してもよい。

ステップ４１６において、分析・抽出結果である依存関係／リスクの出力情報を生成する。

ステップ４１８において、ディスプレイ等の出力装置に出力情報を出力する。

図５は、人間系ノードの分析に関する実施形態のフローを示している。図５の処理は、図４のステップ４０８の処理内容を示している点に留意する必要がある。

ステップ５０２において、作業者、作業内容、作業開始時刻等の情報をノードから取得する。これらの情報は、オペレータにより入力される情報である。

ステップ５０４において、例えば作業者と作業内容をキーとして、ＤＢ２１０に過去の作業実績の情報が存在するか否かが判断される。「はい」であれば、ステップ５０６に進む。「いいえ」であれば、ステップ５１０に進む。

ステップ５０６において、ＤＢ２１０における過去の蓄積情報から、例えば、平均作業時間をこのノードの作業時間とする。なお、ノードの作業者と作業負荷（作業負荷度合）により、所定の規則によってこの作業時間を補正してもよい。

ステップ５１０において、作業毎の所定のデフォルト値をこのノードの作業時間としてもよい。デフォルト値は、予め作業毎に定めておき、ＤＢ２１０に格納しておいてもよい。なお、新たな作業項目であれば、オペレータによるデフォルト値の入力を促してもよい。

ステップ５１２において、ステップ５０２において取得された作業者をキーに、記憶部（ＤＢ）の他のプロセス定義のノードを検索する。この処理によって、他のプロセス定義における同じ作業者のノードが全て抽出される。

ステップ５１４において、抽出されたノード間で、作業時間の重複があるか否かが判断される。「はい」であれば、ステップ５１６に進む。「いいえ」であれば、ステップ５１８に進む。

ステップ５１６において、作業にリスクありと判定される。なぜなら、同じ作業者に作業の重複がある場合には、作業者がこの重複した作業を実行することが非常に困難であると予想されるからである。このリスクに関係するノードが特定され。記憶される。

ステップ５１８において、作業リスクなしと判定される。作業リスクが無い場合には、特にこの「作業リスクなし」という情報を記憶しなくてもよい。なお、ノードの対応関係は、依存関係として利用できる。

ステップ５２０において、分析（抽出）された結果を記憶部に格納する。

図６は、装置系ノードの分析に関する実施形態のフローを示している。図６の処理は、図４のステップ４１０の処理内容を示している点に留意する必要がある。

ステップ６０２において、作業対象サーバ、作業内容、作業開始時刻の情報等を取得する。これらの情報は、オペレータにより入力される情報である。

ステップ６０４において、例えば作業者と作業内容をキーとして、ＤＢ２１０に過去の作業実績の情報が存在するか否かが判断される。「はい」であれば、ステップ６０６に進む。「いいえ」であれば、ステップ６０８に進む。

ステップ６０６において、ＤＢ２１０における過去の蓄積情報から、例えば、平均作業時間をこのノードの作業時間とする。

ステップ６１０において、作業予測時間の間に作業対象サーバで実行される作業の数、作業内容から、環境負荷割合を算出し、作業予測時間を補正した結果を作業時間とする。上述のように、特に装置系ノードの場合には、サーバが複数の運用作業のプログラムを同時に実行している場合がある。また、１つのサーバが複数の仮想マシンを稼働させている場合もある。環境負荷割合は、これらの点を考慮して決定してもよい。

ステップ６１２において、作業対象サーバをキーに、記憶部の他のプロセス定義のノードを検索する。この処理によって、他のプロセス定義における同じサーバのノードが全て抽出される。

ステップ６１４において、抽出されたノード間で、作業時間の重複があるか否かが判断される。「はい」であれば、ステップ６１６に進む。「いいえ」であれば、ステップ５２０に進む。

ステップ６１６において、作業内容の矛盾があるか否かがチェックされる。例えば、「サーバを起動する」という作業と「サーバを停止する」という作業は、作業時間の重複があってはならない作業である。このような作業は、相互に矛盾する作業（リスクがある作業）と判断される。この判断が「いいえ」であればステップ６２０に進む。この判断が「はい」であれば、ステップ６１８に進む。

ステップ６１８において、作業リスクありと判定される。このリスクに関係するノードが特定される。

ステップ６３０において、作業リスクなしと判断される。

ステップ６２２において、分析（抽出）された結果を記憶部に格納する。

以上、図４ないし図６を用いて、新たな運用作業が入力された場合の処理について説明した。この場合には、新たに入力された運用作業が、他の既存のプロセス定義とどのように依存しているのか、及び／又は、リスクが存在するのかをオペレータに示している。オペレータは、この結果を基に、運用作業の再計画を立てることが必要となる。

なお、後述するように、突発的なトラブルの発生の場合や、定期的なチェックでトラブルが発見された場合には、トラブルが他のプロセス定義に連鎖的に影響を与えることとなる。このため、波及分析についても行うことが必要となる。これに対して、新たに入力された運用作業は、事前チェックとしての性格を持つため、波及分析については、チェックしないこととしてもよい。新たな運用作業と他の既存のプロセス定義との依存関係及びその問題点をまず指摘し、運用作業の計画の再検討を促すことが重要である。もちろん。以下に述べる、波及分析を実行してもよいことは言うまでもない。

図７は、作業監視に関する一実施形態のフローを示している。

ステップ７０２において、実行中のプロセス定義の一覧を取得する。

ステップ７０４において、実行中のプロセス定義の一覧から、未分析のプロセスを１つ選択する。

ステップ７０６において、選択されたプロセスの中で、現在実行中のノードを特定する。

ステップ７０８において、その実行中のノードの作業が予定より遅れているか否かを判断する。この判断は、例えば、実行中のノードの開始時期と、プロセス定義中に明記されているノードの開始時刻との差を算出してもよい。なぜなら、この実行中のプロセスは、開始時刻の遅れと同じ時間だけ、遅れて終了すると予測されるからである。この判断が「いいえ」であれば、ステップ７３０に移る。この判断が「はい」であれば、ステップ７１０に移る。

ステップ７１０において、その算出された遅れが、所定の閾値を超えているかが判断される。この閾値は、ノード毎に予め定めておいてもよい。あるいは、プロセス定義毎に定めてもよい。あるいは、運用作業毎に定めてもよい。この判断が「はい」であれば、ステップ７１２に移る。この判断が「いいえ」であれば、ステップ７３０に移る。

ステップ７１２において、ノードの作業時間を再計算し、記憶部のノードの情報を更新し、ノードを「波及分析リスト」に追加する処理を行う。作業の遅れが閾値を越え、無視できない量であるため、そのノードの作業時間を再計算し、ノードの開始及び終了時刻を更新する。

ステップ７１４において、プロセス定義の終端であるかが判断される。「はい」であればステップ７１８に移る。「いいえ」であれば、ステップ７１６に移る。

ステップ７１６において、次のノードにフォーカスを移し、ステップ７１２に戻る。この処理によって、遅れの時間の影響を、後続のノードにも適用し、プロセス定義の終わりまで、順次ノードの開始、及び終了時刻を更新することができる。

ステップ７１８において、全プロセス定義の分析が完了したか否かが判断される。この判断が「いいえ」であれば、ステップ７３０に移る。この判断が「はい」であれば、ステップ７２０に移る。

ステップ７３０において、選択されたプロセス定義を分析済とし、ステップ７０４に戻る。

ステップ７２０において、波及分析リストに情報があるか否かが判断される。波及分析リストに情報がある場合には、ステップ７１２を通過したことを意味する。そして、これは、作業監視において、作業の遅れが閾値よりも大きいノードが１つ以上存在していることを意味する。この判断において、「いいえ」であれば、処理は終了する。この判断において「はい」であれば、ステップ７２２に移る。

ステップ７２２において、トラブル波及分析が実行される。すなわち、発見されたノードの遅れが他のプロセスのノードの作業に影響を与えるか（波及するか）を分析する必要がある。この分析の詳細は図９において説明する。

図８は、トラブル発生に関する一実施例のフローを示している。

ステップ８０２において、トラブルが発生したサーバの情報と発生事象を特定する。

ステップ８０４において、発生事象に基づいて、トラブル収束時間を推定し、トラブルが発生したノード（これを、仮にノードＡとする）の情報を更新し、分析時間範囲の特定を行う。トラブルの収束時間は、トラブルの発生事象に基づいて、例えば、ＤＢ２１０に蓄積された同種の過去のトラブルの平均値を用いて推定してもよい。また、新規のトラブルであれば、所定のデフォルト値を採用してもよい。あるいは、オペレータからの入力を促してもよい。この収束時間の推定値に基づいて、トラブルが発生したノードの開始時刻、及び終了時刻を更新する。なお、上述の分析時間範囲は、トラブル発生の分析の時間範囲を決定するための値である。たとえば、現時点から、トラブルが発生したノードのトラブル収束時刻までを分析時間範囲としてもよい。

ステップ８０６において、サーバ情報と分析時間範囲をキーに分析の必要があるプロセス定義を検索する。

ステップ８５０では、以下の処理を行ってもよい。検索された全てのプロセス定義の全てのノードのうち分析時間範囲内の各ノード（これを、仮にノードＢとする）について実行するステップを示している。処理の内容は以下の通りである。

（１）検索された全てのプロセス定義について順に選定し、
（２）選定された１つのプロセスの全てのノードのうち分析時間範囲内の各ノードについて１つずつ（ノードＢとする）以下の処理（ａ）（ｂ）を実行する。
（ａ）ノードＡとＢの作業が矛盾する場合
作業リスクありと判定し、ノードＢの作業時間にトラブル収束時間を加え、以降のノードの開始・終了時刻を再計算して、該当プロセスを更新する。ノードＢを「波及分析リスト」に追加する。ノードの作業時間が分析時間範囲外となる場合は、作業リスクありと判定し、該当するノードＤを「波及分析リスト」に加える。該当プロセス定義に分析済フラグを立てる。
（ｂ）上記（ａ）以外の場合
作業リスクなしと判定する。
ステップ８０８において、波及分析リストに情報があるか否かが判断される。判断が「いいえ」であれば、処理は終了する。判断が、「はい」であれば、ステップ８１０に移行する。

ステップ８１０において、トラブル波及分析を実行する。この分析の詳細は、図９において説明する。

図９は、波及分析に関する一実施例のフローを示している。

ステップ９０２において、分析時間範囲の特定が行われる。分析時間範囲とは、特定の処理時間範囲を表し、分析を行うひとまとまりの時間帯を意味する。例えば、当日の現在時刻（例えば、現在時刻１６：００〜ネットワークサービス終了時刻１１：００）を設定する。この分析時間範囲は、予め定められていてもよい。或いは、トラブル時において、オペレータからの入力を促してもよい。

ステップ９０４において、波及分析リストの受け入れを行う。この波及分析リストは、図７の作業監視、図８のトラブル発生の検知の場合に、作成されることは、上述したとおりである。その他、必要な場合に波及分析リストが作成されてもよい。

ステップ９０６において、波及分析リストから１つのノード（これを仮にノードＣと呼ぶ）を選択する。

ステップ９０８において、ノードＣの作業者又は作業対象サーバ及び分析時間範囲をキーにして関連する他のプロセス定義を検索し、リスト化する。このプロセスのリストは、次のステップ９５０で使用される。

ステップ９５０では、以下の処理を行ってもよい。

（１）検索された全てのプロセス定義について順に選定し、
（２）選定された１つのプロセスの全てのノードのうち波及分析範囲内の各ノードについて１つずつ（ノードＤ）以下の処理（ａ）（ｂ）を実行。
（ａ）ノードＣとＤの作業が矛盾する場合
作業リスクありと判定し、ノードＤの作業時間にトラブル収束時間を加え、以降のノードの開始・終了時刻を再計算して、該当プロセスを更新する。ノードＤを「再波及分析リスト」に追加する。ノードの作業時間が分析時間範囲外となる場合は、作業リスクありと判定し、該当するノードＤを「再波及分析リスト」に加える。該当プロセス定義に分析済フラグを立てる。
（ｂ）上記（ａ）以外の場合
作業リスクなしと判定する。
ステップ９１０においては、波及分析リストの分析が終了したか否かがチェックされる。チェック結果が「いいえ」であれば、ステップ９０６に戻る。チェック結果が「はい」であれば、ステップ９１２に移る。

ステップ９１２では、再波及分析リストに情報があるか否かが判断される。判断が「いいえ」であれば、処理は終了する。判断が「はい」であれば、ステップ９１４に進む。

ステップ９１４では、一時記憶場所として利用していた再波及分析リストを波及分析リストに上書きコピーして、ステップ９０４に入力する。その後、再波及分析リストをクリアする。

そして、再分析済みフラグを分析済みフラグに追加する。この処理によって、再分析済みフラグの立っているプロセス定義も分析済みの状態となる。そして、処理が繰り返される。このループ処理は、再波及分析リストに情報がなくなるまで続けられる。

以上の処理で、トラブルの波及したノードが抽出できる。このフローにおいて抽出したノードは、抽出された旨がＤＢ２１０に記憶される。

図１０は、一実施例におけるプロセス定義をフローと木構造で表現した図である。

図１０（Ａ）はプロセス定義をフローとして表現したものである。フローだけが示されているが、実際のプロセス定義においては、図１１に示す情報も含めた多くの情報が格納されている。

図１０（Ｂ）は、各ノードの依存関係を木構造で示した図である。破線で囲まれた範囲は、プロセス定義Ａの木構造を示している。例えば、プロセス定義Ａの人間系作業１は、プロセスＢの人間系作業ａと装置系作業ｂと依存関係があることが分かる。依存関係を規定する規則には、様々なものが定義されてもよい。例えば、プロセス定義Ａの人間系作業１とプロセス定義Ｂの装置系作業ｂが依存関係となっている。これは、例えば、人間系作業の作業者と、装置系作業ｂに関わる作業者が同一であるという関係で依存関係を形成している場合を示している。

図１０（Ｂ）のように、木構造で人間系運用作業と装置系運用作業を一体として、木構造で出力することにより、システム全体の依存関係が容易に把握できる。また、トラブル時において、影響範囲の把握や、回復措置の手当を迅速に行うための手助けとなり得る。

図１１は、ＤＢ２１０に格納された依存関係とリスクを表形式で表現した図である。プロセス定義名、ノード名が明記され、その開始時刻と終了時刻が記入されている。また、このノード名に関連する関連プロセス定義名（親）、関連ノード名（親）、及び矛盾内容が記載されている。なお、「（親）」とは、二つの関連するノードのうち開始時刻の速いほうを該当欄に記入することを意味する。依存関係があるノードのうち、開始時刻が早いノードを親ノード、遅い方のノードを子ノードと呼んでいる。したがって、関連プロセス定義名（親）、関連ノード名（親）、の欄には、子ノードの欄に、親ノードが記載されるようになっている。

図１１において、矛盾内容の欄には、矛盾の内容が記載されている。例えば、最下段のプロセスＣの欄には、矛盾内容として「サーバｗの停止作業中にＶＭ１の起動作業（矛盾）」と記載されている。これは、仮想マシンであるＶＭ１は、サーバｗ上で動作することとなっている。このため、重複した時間帯に、サーバｗの停止作業と、ＶＭ１の起動作業を行うことは、不可能であり、矛盾を起こしていることが分かる。

図１２は、出力情報生成部２１６が生成する出力情報（メッセージ情報）の例を示している。図に示されるように、プロセス定義Ａについて、開始時刻の順に作業内容がまとめられている。そして関連プロセス定義、その作業内容、及びメッセージ情報が列挙されている。

例えば、メッセージ情報１２０２に示されるように「同時刻に複数の作業有り危険！」というメッセージが示されている。オペレータ１は、開始時刻１３：００においてプロセス定義Ａの運用作業として「作業申請」を行うこととなっており、かつ、関連プロセス定義Ｂでは、同じ時間帯に「サーバ電源の見回り」を行うこととなっている。したがって、オペレータは、同じ時間帯に二つの業務作業を行わなければならず、実行できない可能性もある。

また、１３：４５分には、メッセージ情報として「サーバ甲で作業矛盾有り危険！」が示されている。プロセス定義Ａではサーバ甲が、自身を停止する動作を行う必要ガル。そして、この時間帯と同じ時期に、プロセス定義Ｄでは、管理者へメールを送信する予定となっている。この場合には、サーバ甲は、メールを送ることができない可能性が高い。従ってリスクが存在することとなる。

このように、オペレータは、ユーザインターフェースを介して、複数のプロセスが並行して動作する環境において、それぞれの運用作業の依存関係を容易に把握できると共に、クリティカルなリスクを容易に知ることができる。この情報を入手することによって、リスクを未然に防止したり、突発的なトラブルを迅速にかつ容易に解決したりすることが可能となろう。

図１３は、一実施形態のハードウェア構成を示している。ハードウウェアは、ＣＰＵ１３１０、メモリ１３１５、入力装置１３２０、出力装置１３２５、外部記憶装置１３３０、可搬記録媒体駆動装置１３３５、ネットワーク接続装置１３４５が含まれる。そして、それぞれの機器は、バス１３５０によって接続されている。また、可搬記録媒体駆動装置１３３５は、可搬記録媒体１３４０を読み書きすることができる。そして、ネットワーク接続装置１３４５には、ネットワーク１３６０が接続されている。

なお、本実施形態のプログラムは、可搬記録媒体１３４０に格納することができる。可搬記録媒体１３４０とは、構造（structure）を有する１つ以上の非一時的（non-transitory）な、有形（tangible）な、記憶媒体を言う。例示として、可搬記録媒体１３４０としては、磁気記録媒体、光ディスク、光磁気記録媒体、不揮発性メモリなどがある。磁気記録媒体には、ＨＤＤ、フレキシブルディスク（ＦＤ）、磁気テープ（ＭＴ）などがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc-Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。また、光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。

なお、本明細書に開示した、各実施形態は、それぞれの構成要件を自由に組み合わせることも可能である。したがって、請求項に定義された発明は、実施形態の構成に限定されるものではない。

また、方法の発明、プログラムの発明、プログラムを記憶した記憶媒体の発明は、矛盾が生じない限りその構成要件を入れ替えてもよい。そして、その入れ替えたものも、添付の特許請求の範囲に記載された発明の技術的範囲に属することは言うまでもない。また、当業者であれば、本願明細書に記載されていない実施形態についても、当業者の能力の範囲で構成することができ、そのような構成も、特許請求の範囲に記載された発明の技術的範囲に属することは言うまでもない。

上記実施形態に関し、以下の付記を開示する。
（付記１）
装置の作業及び人間の作業を含む複数の作業と、前記複数の作業の順序とを有する運用作業の情報を受け入れる入力部と、
前記複数の作業の各々に要する作業時間を、時間決定規則に基づいて決定する、作業時間決定部と、
前記決定された各作業時間を、対応する前記装置の作業又は前記人間の作業にそれぞれ対応付けた複数のプロセス定義を生成する、プロセス定義生成部と、
前記複数のプロセス定義と分析規則に基づいて前記複数の作業の各々の間の依存関係、及び／又はリスクを抽出する抽出部と、
前記依存関係、及び／又は前記リスクを可視的に出力するための出力情報を生成する出力情報生成部と、
を有するシステム。
（付記２）
前記抽出部は、前記分析規則として、前記複数の作業の各々の間での、装置の同一性又は人間の同一性を判断することを含む規則を用いて、前記依存関係を抽出する付記１記載のシステム。
（付記３）
前記抽出部は、前記分析規則として、前記複数の作業における、作業矛盾、作業負荷の増大、又は作業時間の増加を判断することを含む規則を用いて、前記リスクを抽出する付記１又は２記載のシステム。
（付記４）
前記時間決定規則は、予め定義されたデフォルト値又は過去の作業時間の情報に基づき、前記作業時間を決定する、付記１ないし３のうちいずれか１項記載のシステム。
（付記５）
所定の時刻に、前記抽出部を起動させる、抽出部起動部を更に有する、付記１ないし４のうちいずれか1項記載のシステム。
（付記６）
前記プロセス定義生成部は、障害発生を含むイベントが発生したこと、及び／又は前記抽出部において前記リスクが抽出されたことに応答して、既に作成された前記プロセス定義を修正する、プロセス定義修正部を含み、前記修正されたプロセス定義は、前記抽出部に渡される、
付記１ないし５のうちいずれか１項記載のシステム。
（付記７）
運用作業管理のための方法であって、
装置の作業及び人間の作業を含む複数の作業と、前記複数の作業の順序とを有する運用作業の情報を受け入れ、
前記複数の作業の各々に要する作業時間を、時間決定規則に基づいて決定し、
前記決定された各作業時間を、対応する前記装置の作業又は前記人間の作業にそれぞれ対応付けた複数のプロセス定義を生成し、
前記複数のプロセス定義と分析規則に基づいて前記複数の作業の各々の間の依存関係、及び／又はリスクを抽出し、
前記依存関係、及び／又は前記リスクを可視的に出力するための出力情報を生成する、
処理を有する方法。
（付記８）
前記抽出する処理は、前記分析規則として、前記複数の作業の各々の間での、装置の同一性又は人間の同一性を判断することを含む規則を用いて、前記依存関係を抽出する、付記７記載の方法。
（付記９）
前記抽出する処理は、前記分析規則として、前記複数の作業における、作業矛盾、作業負荷の増大、又は作業時間の増加を判断することを含む規則を用いて、前記リスクを抽出する付記７又は８記載の方法。
（付記１０）
前記時間決定規則は、予め定義されたデフォルト値又は過去の作業時間の情報に基づき、前記作業時間を決定する、付記７ないし９のうちいずれか１項記載の方法。
（付記１１）
所定の時刻に、前記抽出する処理を起動させる処理を更に有する付記７ないし１０のうちいずれか1項記載の方法。
（付記１２）
前記定義する処理は、障害発生を含むイベントが発生したこと、及び／又は前記抽出する処理において前記リスクが抽出されたことに応答して、既に作成された前記プロセス定義を修正する処理を含み、前記修正されたプロセス定義は、前記抽出部に渡される、
付記７ないし１１のうちいずれか１項記載の方法。
（付記１３）
運用作業管理のためのプログラムであって、
装置の作業及び人間の作業を含む複数の作業と、前記複数の作業の順序とを有する運用作業の情報を受け入れ、
前記複数の作業の各々に要する作業時間を、時間決定規則に基づいて決定し、
前記決定された各作業時間を、対応する前記装置の作業又は前記人間の作業にそれぞれ対応付けた複数のプロセス定義を生成し、
前記複数のプロセス定義と分析規則に基づいて前記複数の作業の各々の間の依存関係、及び／又はリスクを抽出し、
前記依存関係、及び／又は前記リスクを可視的に出力するための出力情報を生成する、
処理をコンピュータに実行させるプログラム。
（付記１４）
前記抽出する処理は、前記分析規則として、前記複数の作業の各々の間での、装置の同一性又は人間の同一性を判断することを含む規則を用いて、前記依存関係を抽出する付記１３記載のプログラム。
（付記１５）
前記抽出する処理は、前記分析規則として、前記複数の作業における、作業矛盾、作業負荷の増大、又は作業時間の増加を判断することを含む規則を用いて、前記リスクを抽出する付記１３又は１４記載のプログラム。
（付記１６）
前記時間決定規則は、予め定義されたデフォルト値又は過去の作業時間の情報に基づき、前記作業時間を決定する、付記１３ないし１５のうちいずれか１項記載のプログラム。
（付記１７）
所定の時刻に、前記抽出する処理を起動させる処理を更にコンピュータに実行させる付記１３ないし１６のうちいずれか1項記載のプログラム。
（付記１８）
前記定義する処理は、障害発生を含むイベントが発生したこと、及び／又は前記抽出する処理において前記リスクが抽出されたことに応答して、既に作成された前記プロセス定義を修正する処理を含み、前記修正されたプロセス定義は、前記抽出部に渡される、
付記１３ないし１７のうちいずれか１項記載のプログラム。

２０２ 入力部
２０４ 作業時間決定部
２０６ プロセス定義生成部
２０８ プロセス定義修正部
２１２ 抽出部
２１４ 抽出部起動部
２１６ 出力情報生成部

Claims (8)

1. 装置の作業、及び、装置の作業を伴わない人間の作業を含む複数の作業と、前記複数の作業の順序とを有する運用作業の情報を受け入れる入力部と、
   前記複数の作業の各々に要する作業時間を、時間決定規則に基づいて決定する、作業時間決定部と、
   少なくとも前記決定された各作業時間を、対応する前記装置の作業又は前記人間の作業にそれぞれ対応付け、それぞれに人間の作業と装置の作業とを含む複数のプロセス定義を生成する、プロセス定義生成部と、
   前記複数のプロセス定義と分析規則に基づいて前記複数の作業の各々の間の依存関係、及び／又はリスクを抽出する抽出部と、
   前記依存関係、及び／又は前記リスクを可視的に出力するための出力情報を生成する出力情報生成部と、
   を有するシステム。
2. 前記抽出部は、前記分析規則として、前記複数の作業の各々の間での、装置の同一性又は人間の同一性を判断することを含む規則を用いて、前記依存関係を抽出する請求項１記載のシステム。
3. 前記抽出部は、前記分析規則として、前記複数の作業における、作業矛盾、作業負荷の増大、又は作業時間の増加を判断することを含む規則を用いて、前記リスクを抽出する請求項１又は２記載のシステム。
4. 前記時間決定規則は、予め定義されたデフォルト値又は過去の作業時間の情報に基づき、前記作業時間を決定する、請求項１ないし３のうちいずれか１項記載のシステム。
5. 所定の時刻に、前記抽出部を起動させる、抽出部起動部を更に有する、請求項１ないし４のうちいずれか1項記載のシステム。
6. 前記プロセス定義生成部は、障害発生を含むイベントが発生したこと、及び／又は前記抽出部において前記リスクが抽出されたことに応答して、既に作成された前記プロセス定義を修正する、プロセス定義修正部を含み、前記修正されたプロセス定義は、前記抽出部に渡される、
   請求項１ないし５のうちいずれか１項記載のシステム。
7. 運用作業管理のための方法であって、
   装置の作業、及び、装置の作業を伴わない人間の作業を含む複数の作業と、前記複数の作業の順序とを有する運用作業の情報を受け入れ、
   前記複数の作業の各々に要する作業時間を、時間決定規則に基づいて決定し、
   少なくとも前記決定された各作業時間を、対応する前記装置の作業又は前記人間の作業にそれぞれ対応付け、それぞれに人間の作業と装置の作業とを含む複数のプロセス定義を生成し、
   前記複数のプロセス定義と分析規則に基づいて前記複数の作業の各々の間の依存関係、及び／又はリスクを抽出し、
   前記依存関係、及び／又は前記リスクを可視的に出力するための出力情報を生成する、
   処理を有する方法。
8. 運用作業管理のためのプログラムであって、
   装置の作業、及び、装置の作業を伴わない人間の作業を含む複数の作業と、前記複数の作業の順序とを有する運用作業の情報を受け入れ、
   前記複数の作業の各々に要する作業時間を、時間決定規則に基づいて決定し、
   少なくとも前記決定された各作業時間を、対応する前記装置の作業又は前記人間の作業にそれぞれ対応付け、それぞれに人間の作業と装置の作業とを含む複数のプロセス定義を生成し、
   前記複数のプロセス定義と分析規則に基づいて前記複数の作業の各々の間の依存関係、及び／又はリスクを抽出し、
   前記依存関係、及び／又は前記リスクを可視的に出力するための出力情報を生成する、
   処理をコンピュータに実行させるプログラム。

Images