JP2009181496A - ジョブ処理システムおよびジョブ管理方法 - Google Patents

Abstract

【課題】ジョブのバッチ処理時に発生した障害の原因を究明するのは困難である。
【解決手段】ジョブ処理を行うシステムに含まれる各サーバにおいて、利用リソース情報取得部３４は、ユーザが登録したジョブフローに基づき、各ジョブが利用するリソースなどを抽出して、利用リソース情報のテーブルを作成する。実行状況記憶部４４は過去に処理されたジョブの実行状況を蓄積して記憶する。ジョブ処理時に障害が発生した際、障害原因検出部３８は、過去の実行状況からジョブ同士の相対的な関係における「通常状態」を定義し、今回の状況と比較することにより「異常状態」を検出する。さらに利用リソース情報のテーブル、エラーログ、過去の発生頻度といった観点から多角的に評価を行い、障害原因となり得る確率を取得する。
【選択図】図３

Description

本発明は情報処理技術に関し、特にジョブのバッチ処理時に発生する異常を管理するジョブ管理方法および当該方法を適用したジョブ処理システムに関する。

近年の情報処理技術の発展およびネットワーク環境の充実化に伴い、様々な情報がネットワークを行き来し、企業、社内の部門など端末に入力された個々のデータを統括管理する組織には、入力された膨大なデータおよび用いるシステムを厳密に管理する技術が必要不可欠となっている。データバックアップ、各種数値算出などデータを管理するための処理やシステムメンテナンスなどは一般的に、毎日、毎月、など定期的に行われるルーチン処理である。そのため、あらかじめ指定した複数のジョブをバッチで処理するように設定しておくことにより、夜間などに自動で行われることが多い。

ジョブをバッチ処理する場合、システムの処理能力、効率性、ジョブ同士の依存関係、優先順位などに基づき、ジョブの処理順序をあらかじめ決定しておく。そして各ジョブの処理内容、すなわちジョブフローとその実行順序とをシステムに登録しておくことにより、基本的には所望の時間に所望の処理が自動で終了していることになる。これにより人件費を削減しつつ、各種処理の効率化が望める（例えば特許文献１）。
特開平５−１２０３７号公報

一方で、バッチ処理の途中で何らかの障害が発生した場合、その復旧は困難な作業となることが多い。例えば、あるジョブが途中で停止してしまった場合、その原因は当該ジョブそのものにある場合ばかりでなく、その前に実行されたジョブあるいはさらに前に実行されたジョブにある場合もある。複数のジョブを並列で実行していた場合などは、原因のの可能性を有するジョブの数がさらに増加する。ジョブのバッチ処理自体は多くの人員を必要としないことを前提としているが、ひとたび障害が発生すると、原因究明および復旧は人手に頼らざるを得ない部分が多い。このジレンマが、復旧をより困難なものとしている。

そのため一般的には、障害原因を分析できる高スキルを有する人員を確保したり、余裕をもたせた人員配置を行ったり、緊急時の別のジョブフローを何重にも用意したり、といったことを障害の発生に備えて行っている。このことは結果として人件費、システム開発費、メンテナンス費などのコストの増大を招く。この問題は、バッチ処理を営業開始時間までに終了させなければいけないなど処理の制約が多いほど、またシステムが大規模化するほど顕著となる。また障害発生時に対応策を誤ると、正常処理されていたジョブに障害が及ぶなどの二次災害が発生する危険性もある。一方で、そのような事態を生じさせないようなシステム設計やジョブフローの設定を行うために、システム開発者の負担も増している。

本発明はこうした状況に鑑みてなされたものであり、その目的は、コストを増大させることなく安全に障害発生に対処することのできるジョブ管理技術を提供することにある。

本発明のある態様は、ジョブ処理システムに関する。このジョブ処理システムは、ジョブをバッチ処理するジョブ処理システムであって、ジョブを処理する都度、ジョブの実行状況の情報を蓄積して記憶する実行状況記憶部と、処理中のジョブのいずれかに異常が発生した際、実行状況の情報を参照して、異常が発生したジョブと、同バッチ処理において処理されていたその他のジョブの処理時間の相対的な関係が、過去の実績において所定のしきい値を超えた確率で発生している通常状態からはずれた異常状態となっている事象を原因候補として検出する障害原因検出部と、障害原因検出部が検出した、原因候補に係る情報を出力する出力部と、を備えたことを特徴とする。

ここで「実行状況の情報」とは、ジョブの処理開始時刻、終了時刻、リソースへのアクセス開始時刻、終了時刻、エラー情報など、一般的なログで記録される情報のいずれでもよい。

本発明の別の態様は、ジョブ管理方法に関する。このジョブ管理方法は、ジョブ処理システムにおいてバッチ処理されるジョブと各ジョブが利用するリソースに係る情報とを対応づけた利用リソース情報を取得するステップと、ジョブを処理する都度、ジョブの実行状況の情報を蓄積して記憶するステップと、処理中のジョブのいずれかに異常が発生した際、利用リソース情報および実行状況の情報を参照して、当該ジョブが利用するリソースのエラーの有無と、当該ジョブと同一のリソースを利用する他のジョブの実行状況と、障害が発生したジョブと当該ジョブと同一のリソースを利用する他のジョブの処理時間の相対的な関係の通常状態からの変化の有無と、障害が発生したジョブに対し過去に障害原因となった頻度と、の少なくともいずれかを確認することにより、障害原因の候補を検出するステップと、前記障害原因の候補に係る情報を出力するステップと、を含むことを特徴とする。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システムなどの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、障害発生に備えるためのコストを増大させることなくジョブの処理を行うことができる。

図１は本実施の形態を適用できるシステムの構成例を示している。同図においてジョブ処理システム１０は第１サーバ１２、第２サーバ１４、第３サーバ１６、第４サーバ１８の４つのサーバを含む。また第１サーバ１２はデータベース２０に接続している。ユーザは各サーバの端末などを操作し設定、登録を行うことにより、所望のジョブを所望の時間に処理させる。なお、サーバやデータベースの数、データベースの接続先は図１に示したものに限らず、ジョブを処理できるシステムであればいかなる構成においても本実施の形態を適用できる。また各サーバにさらにクライアント端末などが接続していてもよい。

第１サーバ１２、第２サーバ１４、第３サーバ１６、第４サーバ１８はそれぞれ、一以上のＣＰＵとメモリ、記憶装置、入出力装置、表示装置など、あるいはそのいずれかの組み合わせを備えた一般的な情報処理装置であればよく、パーソナルコンピュータ、汎用大型コンピュータなどその規模は限定されない。同図は一例として第１サーバ１２がハードディスク１３を、第２サーバ１４がハードディスク１５をそれぞれ備えた構成を示している。また第１サーバ１２〜第４サーバ１８はネットワーク２２に接続され、互いにデータを送受することができる。

ユーザは第１サーバ１２、第２サーバ１４、第３サーバ１６、第４サーバ１８のいずれかに対しジョブフロー、バッチ処理時の処理の順序、処理開始時間などの設定を行うことにより、ジョブ処理システム１０にジョブを処理させる。ひとつのジョブを第１サーバ１２、第２サーバ１４、第３サーバ１６、第４サーバ１８のいずれかひとつのサーバで処理するようにしてもよいし、複数のサーバで処理するようにしてもよい。各ジョブをどのサーバでどのような順序で処理させるか、また、並列に複数のジョブを処理させるかどうかなどは、ＣＰＵの処理能力やネットワークの帯域など利用可能なリソースや、データベースへのアクセス順といった処理内容などに鑑み、ユーザが設定を行う。これらの手続きは、ジョブの処理に際し行われる 一般的な手法を用いることができる。

このような構成にあっては、複数のサーバ、データベースなどのハードウェアと、複数のジョブが複雑に連携しあって処理が進捗する。このときあるサーバ、例えば第１サーバ１２で処理していたジョブが何らかの障害により停止してしまった場合、その原因が、停止したジョブ自体にある場合もあれば、全く別のところにある場合もある。例えば、停止したジョブの前のジョブが出力した誤ったデータを読み込んだ場合、第２サーバ１４におけるジョブ処理でハードディスク１５のドライブＥの空き容量が不足し書き込みを行えない場合、並列で処理しているジョブとの競合でネットワーク接続にタイムアウトが発生した場合、ハードウェアの故障が生じた場合、などその原因は様々考えられる。一般的には人手によってそれらの要因を逐一検証し、原因を突き止めて問題点を克服し、もう一度ジョブの処理をやり直す必要がある。

原因究明に時間を要すると、予定していた全てのジョブを予定時間に終了させることができなくなり、場合によっては翌日の営業、作業に支障をきたすこともあり得る。このことはシステムの規模が大きくなるほど大きなリスクを生む。例えば第１サーバ１２と第２サーバ１４とが別の部門で管理されていたり、異なる場所に備えられていたりすると、第１サーバ１２が処理していたジョブの異常終了の原因が第２サーバ１４の内部にあったとしてもそれを見いだすことは容易でない。原因を究明しているうちに第２サーバ１４における問題がそれを管理する部門によって克服されてしまうと、第１サーバ１２では結局何が原因でジョブが異常終了したのかがうやむやになってしまう。

益々加速する様々な業務のオンライン化、自動化に伴い、処理するデータの量が膨大となり、システムの規模も大きくなるにつれ、上記のような問題が深刻化し、システム開発者、障害担当者などの負担が増している。そこで本実施の形態では、障害が発生したジョブと関連性のあるジョブを自動で検出し、障害発生の原因の絞り込みを自動化することにより、復旧作業の効率的な支援を行う。このとき関連性の拠り所として、（１）障害が発生したジョブ（以後、「障害ジョブ」と呼ぶ）が利用していたリソース（以後、「利用リソース」と呼ぶ）のエラー情報、（２）障害ジョブと同じリソースを利用するジョブ（以後、「同リソース利用ジョブ」と呼ぶ）の状況、（３）障害ジョブと同リソース利用ジョブとの相対的な状況、（４）同様の障害の発生頻度、の４つの観点の少なくとも１つに着目する。

処理内容の見地からはジョブ同士に直接的なつながりはなくとも、障害発生の見地からは偶発的に関連性が生じることも多い。そのようなジョブの障害上の関連性は、ジョブの処理順序や処理するデータ量など様々な要因で発生しうるため、あらかじめ予測することが難しい。また障害が発生した後でも対象となるサーバやジョブのログのみでは関連性を見出しにくい。そこで本実施の形態では、障害が発生した段階で上記４つの観点を評価することによりそれらを媒介としてジョブ同士を紐づけ、障害上の関連性を見出す。そしてジョブ処理システム全体から、障害が発生した原因となったジョブおよびリソースを検出する。

図２は上記４つの観点のうち（３）障害ジョブと同リソース利用ジョブとの相対的な状況、が変化することによって障害上の関連性が発生した場合を模式的に示している。同図において横軸は時間の経過を表しており、ジョブＡ、ジョブＢ、ジョブＸなる３つのジョブが処理された時間をそれぞれの矩形で表している。この例ではジョブＡ、ジョブＢがこの順序で処理され、ジョブＸはそれらのジョブと並列に処理されるものとする。これらのジョブは同一のサーバで処理されていてもよいし、別のサーバで処理されていてもよい。このような処理順序でジョブのバッチ処理を行っている環境において、ジョブＸが異常終了した、すなわちジョブＸが障害ジョブとなった場合を考える。通常は人手によりジョブＸと直接関係を有する、アクセスしたリソースのエラーログや、同じサーバでジョブＸの前に処理されていたジョブのログなどを逐一調べていく必要がある。

一方、このような一見して障害原因と認識できる要因以外にも原因となりうる事象は多々あり、その一つが同リソース利用ジョブとの相対的な状況である。図２の例では、「通常状態」（図の上段）においてはジョブＸはジョブＡの処理中、すなわちジョブＢの開始時刻ｔ２より早い時刻ｔ１で終了する。ところがジョブＸに障害が発生した「異常状態」（図の下段）では、ジョブＸの開始が何らかの要因で遅延したか、ジョブＸ自体の処理時間が長くなったことにより、ジョブＸの処理終了時刻ｔ３がジョブＢの開始時刻ｔ２より遅くなっている。ここで「通常状態」とは、ある着目点に対し過去の運用実績において最も高い確率で発生する状態であり、「異常状態」とはそれ以外の状態である。実際には発生確率にしきい値を設けそれ以上の状態を「通常状態」、それ未満の状態を「異常状態」としてよい。また「通常状態」に２以上の状態が含まれていてもよい。

このような状況において、同図に示すようにジョブＢとジョブＸが同じデータベース２０へアクセスするジョブであった場合、すなわちジョブＢが同リソース利用ジョブであった場合、ジョブＸが異常終了することがあり得る。これは、通常状態ではジョブＢとジョブＸが全く異なる時刻にデータベース２０へアクセスするのに対し、ジョブＢとジョブＸの処理時間が時刻ｔ２からｔ３において重なることにより、ジョブＸがデータベース２０へアクセスできなかったり、ジョブＢにより予定外の上書きがされてジョブＸが正規のデータを参照できなかったりすることが考えられるためである。このような場合に、ジョブＸとジョブＢには障害上の関連性が発生するが、直接的な関連性がないうえ、そもそもジョブＸの処理時間が通常時よりずれていたという事実を認識することも難しいため、その関連性を人手で探索するのは容易ではない。

さらににジョブＡ、ジョブＢと、ジョブＸが異なるサーバで処理されていたり管理部門が異なっていたりすると、ジョブＸの異常終了の原因をジョブＢとの処理時間の重なり、と結論づけることは一層困難となる。並列に処理されているジョブの数が増えるほど、実行状況の変化が影響を及ぼす範囲の把握が困難となり、原因の特定が不可能に近くなっていく。そこで本実施の形態では、障害発生時に上記４つの観点から、偶発的ともいうべき関連性の発生を検出する。そして当障害に影響を与えている可能性のあるジョブとリソースの組み合わせ（以後、「原因候補」とも呼ぶ）を抽出し、それが障害原因となり得る確率をユーザに示すことにより原因究明の効率を上げ、復旧作業の支援を行う。なお「原因候補」は検出した状況によってはジョブのみ、リソースのみの場合もある。

図３は第１サーバ１２の構成をより詳細に示している。第２サーバ１４、第３サーバ１６、第４サーバ１８も同様の構成としてよい。第１サーバ１２は、ハードディスク１３の他、ユーザがジョブフローなどを登録するジョブ登録部３２、各ジョブが利用するリソースの情報を取得する利用リソース情報取得部３４、ジョブフローや利用リソース情報などを記憶するジョブ情報記憶部４２、登録されたジョブを処理するジョブ処理部３６、障害発生時にその原因を検出する障害原因検出部３８、障害が発生した際のバッチ処理における各種ログと過去の実行状況を記憶する実行状況記憶部４４、状況ごとに設定した、障害原因となり得る確率を記憶する原因確率記憶部４６、検出した障害原因に係る情報を出力する出力部４０を含む。

図３において、様々な処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、ＣＰＵ、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、演算やファイル操作、ネットワーク通信などを行うプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。

ジョブ登録部３２は、ジョブフロー、すなわち各ジョブにおいてなされる処理内容や、バッチ処理における複数のジョブの処理の順序など、ジョブの処理に必要な情報をユーザが登録するためのインターフェースである。ジョブ登録部３２は、登録画面を表示した表示装置と、キーボード、ポインティングデバイスなど登録画面に対して入力を行う入力装置との組み合わせなどでよく、ジョブを処理する一般的なシステムで用いられる装置を適用することができる。登録された情報はジョブ情報記憶部４２に格納する。

利用リソース情報取得部３４は、ジョブ登録部３２が登録を受け付けたジョブフローから各ジョブが利用するリソースなどを抽出して、利用リソース情報のテーブルを作成する。利用リソース情報のテーブルは、ジョブ処理システム１０においてバッチで処理されるジョブの名前とそれらが利用するリソース、サーバ、リソースの利用率などを対応づけたテーブルである。ジョブ登録部３２がジョブフローのデータを、入出力を行うハードディスク、アクセスするサーバなどのフィールドを有する所定のフォーマットでジョブ情報記憶部４２に格納することにより、利用リソース情報取得部３４は、当該データの所定のフィールドからサーバ名、利用リソースなどを抽出する。このようにして作成した利用リソース情報のテーブルもジョブ情報記憶部４２に格納する。利用リソース情報により、障害ジョブが利用しているリソース、同リソース利用ジョブ、同リソース利用ジョブのリソース利用率等が判明し、原因検出に用いられる。

ジョブ処理部３６は、ユーザが登録したジョブフロー、ジョブの処理順序などの情報をジョブ情報記憶部４２から読み出し、実行する。これはジョブを処理する一般的なシステムで用いられる手法を適用することができる。ジョブ処理部３６はジョブの処理内容に応じてハードディスク１３に対しデータの書き込みおよび読み出しを行う。ハードディスク１３は他のサーバ、すなわち第２サーバ１４、第３サーバ１６、第４サーバ１８からもネットワーク２２を介してアクセスが可能であるとする。

ジョブ処理部３６は、ジョブの処理中に、当日の実行状況を表すジョブのログやエラーログなど実行状況の情報を実行状況記憶部４４に記憶させる。実行状況記憶部４４は、障害が発生した際のバッチ処理において記録されたログと、過去にバッチ処理を行った際のログに含まれる情報を実行状況の情報として蓄積して記憶する。過去のバッチ処理時の実行状況を蓄積しておくことにより、それを利用して統計的に「通常状態」であるのか「異常状態」であるのかの判定を行う。

図２において、「通常状態」ではジョブＸはジョブＢの処理時間と重なることがない、という判断は、ジョブＡ、ジョブＢとジョブＸとの直接的な関連性が低いほど、前もって設定できる性質のものではなくなる。そのため、一般的にジョブＸとジョブＢの処理時間の重なりが「異常状態」であると判断することができず、図２のジョブＸの異常終了の原因を、処理時間の重なりに求めることを困難にしている。そこで実行状況の過去のデータから「通常状態」を定義したうえ、障害発生時には、そのときのバッチ処理の実行状況のうち「通常状態」と異なっていた事象を抽出することにより障害原因を検出する。

過去の実行状況の情報は、ジョブ処理部３６がバッチ処理を行う都度記録するログの形式でもよいし、原因検出に用いる情報のみを抽出したものでもよい。例えば各ジョブの開始時刻、終了時刻を記憶することにより、図２で示したような環境における「通常状態」がどのような状態であるかを定義することができる。実行状況の情報として、各ジョブ処理中のファイル転送の開始時刻と終了時刻、ハードディスクなどリソースへのアクセスの開始時刻と終了時刻などを記憶させ、処理時間をさらに微視的に評価してもよい。その他の具体例は後に述べる。

実行状況記憶部４４はさらに、過去に障害ジョブとなったジョブと、その障害が発生した際、原因となり得る確率が所定のしきい値以上となった原因候補とを対応づけて記憶する。この情報は、過去に障害を発生させる原因となった頻度から、今回の障害の原因候補が原因となり得る確率を評価するために用いる。障害が発生した後、真の原因を究明できた場合はその原因をユーザが実行状況記憶部４４に登録することにより、発生頻度のデータの正確性を高めてもよい。

原因確率記憶部４６は、上記４つの観点での評価における原因候補の状況と、その状況がどの程度障害原因となり得るかを確率で表した数値とを対応づけた原因確率情報を記憶する。原因確率情報は、それまでの経験値や、本番実行環境での実績、テスト結果などに基づきあらかじめ設定しておく。または各状況が影響する範囲などを考慮して理論的に設定してもよい。具体例は後述する。

障害原因検出部３８は障害発生時に、利用リソース情報および実行状況の情報を参照して、上記４つの観点から当障害の原因と考えられる原因候補を検出する。そして原因確率記憶部４６が記憶する原因確率情報に基づき、それぞれが障害原因となり得る確率を取得する。具体的な手法は後述する。

本実施の形態では、サーバを超えて障害原因の検出を行うため、どのサーバでどのジョブが処理されているかに関わらず、ジョブ処理システム１０でバッチ処理している全てのジョブについて、利用リソース情報と実行状況の情報を第１サーバ１２、第２サーバ１４、第３サーバ１６、第４サーバ１８間で共有する。そのために、あるサーバでそれらの情報が更新されるたびに、その更新情報を他のサーバに送信して各自が保持する情報を更新する。あるいは、あるサーバのジョブ情報記憶部４２や実行状況記憶部４４を他のサーバからアクセス可能とすることにより同一の情報を参照する。

出力部４０は一般的な表示装置やプリンタなどの出力装置でよく、障害原因検出部３８が検出した原因候補とそれが障害原因となり得る確率を出力する。

次に上記の構成によるジョブ処理システム１０の動作について説明する。図４は障害発生時の処理手順を示すフローチャートである。なお同図では、上記４つの観点からの評価を全て行うことにより多角的に障害原因の確率を求める場合について示しているが、いずれか１つ、あるいはいずれか複数の組み合わせで評価を行ってもよい。

まずジョブの処理中に障害が発生する（Ｓ３２）。すると障害原因検出部３８は、利用リソースに関するエラーの情報を収集し、エラー内容ごとに原因となり得る確率を取得することにより、利用リソースのエラーによる評価を行う（Ｓ３４）。具体的には、ジョブ情報記憶部４２の利用リソース情報を参照し、障害ジョブの利用リソースを抽出する。さらに障害発生時から時間を遡ってエラーログを参照していき、利用リソースのエラーログを収集する。次にエラーログに記載されたエラー内容に基づき原因確率記憶部４６に記憶された原因確率情報を参照し、エラーごとにそれが原因となり得る確率を取得する。

次に障害原因検出部３８は、同リソース利用ジョブの状況による評価を行う（Ｓ３６）。具体的には、利用リソース情報を参照し、同リソース利用ジョブと当該ジョブの利用リソースに対する利用率を取得する。そして利用率ごとに同ジョブが障害原因となり得る確率を原因確率情報から取得する。ここでは同リソース利用ジョブの状況として、同リソース利用ジョブのリソース利用率を代表として挙げたが、それに限る趣旨ではなく、同リソース利用ジョブの処理の状況で、かつ障害に関連のあるパラメータであればよい。例えば同リソース利用ジョブの平均処理時間に対する当日の処理時間の割合などでもよい。この場合、平均処理時間はジョブごとに実行状況記憶部４４に記憶させておく。

次に障害原因検出部３８は、障害ジョブと同リソース利用ジョブの相対的な状況による評価を行う（Ｓ３８）。具体的には、障害ジョブと同リソース利用ジョブの処理時間の相対的な関係が「異常状態」にあるか否かの判定を行い、「異常状態」であった場合はその状況ごとに同ジョブが障害原因となり得る確率を原因確率情報から取得する。詳細な手順は後に述べる。さらに障害原因検出部３８は、実行状況記憶部４４を参照して、障害ジョブが過去に障害を発生させた際、各原因候補が原因となった頻度、あるいは原因と推定された頻度に基づき、各々が障害原因となり得る確率を取得することにより、過去の発生頻度による評価を行う（Ｓ４０）。

上記４つの観点からの評価によりそれぞれの原因候補が原因となり得る確率を取得したら、それらの確率を原因候補ごとに掛け合わせることにより、原因候補が障害原因となり得る最終的な確率を算出する（Ｓ４２）。ただしこれまでの説明における「確率」やそれを掛け合わせる処理は一例であり、多角的な評価により重み付けを行い、評価結果を総合的に集計する手法であれば算出手法は限定されない。例えば「確率」を「影響度」に置き換え、１を中心とした分布を有する指数で表してもよい。また、ある観点からの評価による確率が所定のしきい値を超えた場合は、その原因候補の最終的な確率が高くなるように重み付けをするなどの補正を施してもよい。

そして出力部４０は、原因候補とそれが原因となり得る確率を対応づけて出力する（Ｓ４４）。ユーザは当該出力結果を確認して、例えば確率が高い順に検証作業を行うなどして障害原因を究明し、問題を克服することにより障害対応を実施することができる（Ｓ４６）。

次にＳ３８の、障害ジョブと同リソース利用ジョブの相対的状況による評価の手法をより詳細に説明する。図５は障害原因検出部３８が障害ジョブと同リソース利用ジョブの相対的な処理状況によって障害原因を検出、評価する処理手順を示している。まず「通常状態」、「異常状態」を判定する対象であるジョブの絞り込みを行う（Ｓ５０）。具体的には、図４のＳ３６において利用リソース情報を参照して得られた、同リソース利用ジョブを対象ジョブとする。

次に実行状況記憶部４４から過去の実行状況の情報を読み出し、障害ジョブと対象ジョブとの相対関係について「通常状態」を定義する（Ｓ５２）。「通常状態」か否かの判定対象となる項目（以後、「判定項目」と呼ぶ）は、障害を起こす可能性のある事象のうち相対関係の変化によって検出できる事象をあらかじめ設定して実行状況記憶部４４に記憶させておく。例えば図２に示したような障害の原因を検出するためには、判定項目に「ジョブの処理時間の重なり」を含めておけばよい。すると、ジョブＸとジョブＢの処理時間が重ならないことが「通常状態」として定義される。

ジョブの処理時間の重なりは、実効状況の情報のうち、各ジョブの終了時刻、開始時刻から算出できる。同様に、ファイル転送時間の重なり、リソースへのアクセス時間の重なりなどを判定項目としてもよい。これらの時間の重なりは、多少なりとも重なる時間があるか否かの２事象で通常・異常を判定してもよいし、どの程度重なるかといったより詳細な情報で判定してもよい。

いずれの場合も、実績として発生確率が所定のしきい値以上となった事象を「通常の状態」として定義する。例えば図２の場合に、ジョブＢとジョブＸの処理時間が全く重ならない確率が８０％以上であった場合、その状態を「通常状態」として定義する。あるいはどの程度重なるかを分散で表したときの標準偏差で定義してもよい。また、最も発生確率の高い事象を「通常状態」としてもよい。その他、統計的ないかなる手段を用いて定義してよい。図２で示した例以外の障害事例と、その原因を検出するために設定する判定項目の具体例は後に述べる。

次に実行状況記憶部４４に格納された、今回のバッチ処理のログを読み出し、「通常状態」の定義を行った判定項目のうち、「通常状態」からはずれた状態にある事象を「異常状態」として抽出する（Ｓ５４）。図２の例では、ジョブＸとジョブＢの処理時間が重なっている、という事象が「異常状態」として検出できる。そして、原因確率記憶部４６にあらかじめ記憶させた、事象ごとの障害の原因となり得る確率を参照することにより、Ｓ５４で抽出した事象を発生させた原因候補が障害の原因となり得る確率を取得する（Ｓ５６）。

次に、図２で示した障害以外の障害事例を挙げて、原因検出に用いられる判定項目を例示する。図６、図７はジョブの相対的な状況の評価により原因を検出できる障害事例を説明する図である。同図の表示方法は図２と同様であり、上段が「通常状態」、下段が「異常状態」を示している。図６の例では、「通常状態」においてジョブＡが処理されている間にジョブＸが処理される。またジョブＡの処理終了後、ジョブＢの処理が開始される。図に示す通り、ジョブＸはあるハードディスクのファイルを削除する処理を含み、ジョブＢはファイルを作成して同ハードディスクに格納する処理を含むとする。

このような態様において、ジョブＸが削除する対象が大きなサイズのファイルであった場合、ジョブＢのファイルが格納される前にジョブＸがファイルを削除しておかないと、ハードディスクの容量を超えてしまう事が考えられる。このとき、ファイルが格納できずジョブＢが異常終了してしまうことがあり得る。図５の「異常状態」はその様子を示しており、何らかの原因によりジョブＸの処理開始時刻が遅延してジョブＢの処理開始時刻以後にずれ込み、それによりジョブＢが異常終了している。ジョブＢの開始時刻が早まったり、ジョブＸの処理時間が長期化した場合も同様の障害が起こりうる。このような場合に、ジョブＢの異常終了の原因を検出するためには、判定項目にジョブ同士の前後関係を含めればよい。

ジョブ同士の前後関係は厳密には開始時刻の前後関係、開始時刻と終了時刻の前後関係、ハードディスクへアクセスする時刻の前後関係など、より詳細な基準を判定項目としてもよい。ジョブ同士の前後関係を判定項目とすることにより、過去の実行状況の情報から、ジョブＸはジョブＢの処理開始時刻より前に終了していることが「通常状態」として定義される。そして当日の実効状況の情報から、ジョブＸの処理開始時刻がジョブＢの処理開始時刻より後になっていることを「異常状態」として検出できる。同図のような障害の場合、ジョブＸ自体は処理開始時刻が遅延したのみで特にエラーが発生する状況にないため、エラーログなどを確認したのみでは障害原因を究明することが難しい。本実施の形態では上述のとおり、ジョブＸの処理開始の遅延が障害原因である可能性を容易に見出すことができる。

図７の例では、「通常状態」においてジョブＡが処理されている間にジョブＸおよびジョブＹが処理される。またジョブＡの処理終了後、ジョブＢの処理が開始される。図に示す通り、ジョブＢ、ジョブＸ、ジョブＹは全て、同じネットワーク、あるいはバスを介してファイルを転送する処理を含むとする。このような態様において、ジョブＸとジョブＹによるファイルの転送でネットワークの使用可能帯域の大半を使用してしまう場合、さらにジョブＢがファイルの転送をしようとしても、ネットワークの輻輳により転送エラーとなりジョブＢが異常終了してしまうことがあり得る。

図７の「異常状態」はその様子を示しており、何らかの原因によりジョブＸおよびジョブＹの処理開始時刻が遅延してジョブＸ、ジョブＹ、およびジョブＢのファイル転送が同時期に重なり、それによりジョブＢが異常終了している。このような場合に、ジョブＢの異常終了の原因としてジョブＸ、ジョブＹの処理開始時刻の遅延を検出するためには、前述したように各ジョブの処理時間の重なりや、ファイル転送時間の重なりなどを判定項目に含めてもよいし、並列で処理されたファイル転送を伴うジョブの数を判定項目に含めてもよい。

ファイル転送を伴うジョブは、ジョブフローを登録する際にユーザに入力させてジョブに識別情報を付加することにより他と識別してもよいし、利用リソース情報取得部３４がジョブフローを解析して前述の利用リソース情報に含めてもよい。あるいは実際に処理した際のジョブのログからファイル転送を行うか否かの情報を取得してもよい。そして「通常状態」において、ファイル転送を伴うジョブの処理時間の重なりを開示時刻、終了時刻から判断し、同時に処理されるジョブの最大数を定義する。図７の例では、前日までの実行状況の情報から、最大２つのファイル転送を伴うジョブが同時に処理可能であることが定義できる。そして当日の実効状況の情報から、ジョブＢの処理開始時刻がジョブＸ、ジョブＹの処理終了時刻より前となっていて、同時に３つのファイル転送を伴うジョブが処理されていることを「異常状態」として検出できる。

このような障害の場合も、ジョブＸやジョブＹ自体はエラーが発生する状況にないため、ジョブＢの異常終了の原因として認識しづらく、一般的な手法では原因究明に時間を要する。結局、再度ジョブ処理を行ってみて検証するなどの方策がとられるが、再現性に乏しい場合、原因が究明できずに終わることもあり得る。上述のように「通常状態」を定義し、障害が発生したときの状況と比較することで「異常状態」を割り出すようにすれば、効率的な原因究明および復旧作業が可能となる。図７はネットワークを用いた転送処理を行うジョブについて示しているが、ネットワークをメモリや出力装置などに置き換えても同様の検出が可能である。

次に、利用リソース情報について説明する。図８は利用リソース情報取得部３４が作成する利用リソース情報のデータ構造の例を示している。利用リソース情報テーブル１００は、ジョブ名欄１０２、利用サーバ欄１０４、利用リソース欄１０６、リソース利用率欄１０８、および備考欄１１０を含む。利用リソース情報取得部３４は、新たなジョブフローが登録されるたびに、利用リソース情報テーブル１００にエントリを追加していく。

ジョブ名欄１０２には、ユーザが登録を行ったジョブの名前を記載する。利用サーバ欄１０４にはそれぞれのジョブが利用するリソースが属するサーバの名前を記載する。利用リソース欄１０６には利用するリソースの識別情報を記載する。リソース利用率欄には、各ジョブが利用リソース欄１０６に記載されたリソースを利用する際のリソースの容量に対する利用率を記載する。ただしデータベースの参照など、同時アクセスが可能な処理に対しては設定しなくてもよい。備考欄１１０には当該リソースを利用する際の処理の概要を記載する。上述したとおり、各欄に記載されるデータは、基本的には利用リソース情報取得部３４がジョブフローのデータを解析して取得できる。一方、リソース利用率欄１０８に記載するリソース利用率は、利用リソース情報取得部３４が、実際にジョブを処理した際のジョブ処理前後のスナップショットの差分などに基づき自動で算出してもよいし、開発機などでの実績値をユーザが登録するようにしてもよい。

図８において、例えばジョブ名が「ジョブＢ」なるジョブは、第１サーバ１２のデータベース２０に、データを参照するためにアクセスを行う（３行目）。また、データを作成して第１サーバ１２のハードディスク１３のドライブＤに格納する（４行目）。このときドライブＤを１０％利用して書き込みを行う。さらにＬＡＮカードを利用してデータ転送を行う（５行目）。このときのＬＡＮカードの利用率は３０％である。「ジョブＡ」、「ジョブＸ」、「ジョブＹ」も同様である。

利用リソース情報のデータ構造は図８に示したものに限らず、処理内容、ジョブ処理システムの構成、それまでの障害発生の事例などを検討し、ジョブについてあらかじめ判明している性質を有し、かつ障害原因の検出に用いることのできるパラメータを適宜選択する。このような詳細な記録を利用リソース情報に含めると、より精度の高い障害原因検出を行うことができる。

次に、図５のＳ５６で「異常状態」として検出された事象を発生させた原因候補が障害原因となり得る確率を取得する際、障害原因検出部３８が参照する原因確率情報について説明する。図９は「異常状態」である事象に対して設定され原因確率記憶部４６に格納される、実行状況別原因確率テーブルの例を示している。実行状況別原因確率テーブル１２０は、関連リソース欄１２２、事象欄１２４、および確率欄１２６を含む。

ジョブの前後関係が同じような「異常状態」となっていても、それらのジョブがどのリソースを介して障害へ結びついたかによって、原因となり得る確率も異なってくる。したがって利用リソースによって「異常状態」の影響の度合いを検討し、より正確な確率設定を行うことが望ましい。そのため関連リソース欄１２２には、障害ジョブと対象ジョブが共通で利用するリソースが設定され、確率もそれに依存して設定できるようにする。さらに事象欄１２４には「異常状態」として抽出されると予想される事象が、確率欄１２６には各事象が原因となり得る確率が設定される。

例えば障害ジョブと、当該ジョブと同じ「データベース」を利用している対象ジョブの処理時間の前後関係が、「異常状態」であったとする。「通常状態」では対象ジョブは障害ジョブより後に処理されると定義された一方、当日は同時に処理されていたとする。この場合、同時に処理されたという事象が障害原因である確率は、図９の例では実行状況別原因確率テーブル１２０の２行目に示されるとおり「９０％」と設定されている。この状況は図２に示した障害の場合であり、データベースへのアクセスの競合が発生するため、原因となり得る確率を高く設定している。

一方、対象ジョブが処理されなかったことが「異常状態」として抽出されても、アクセスの競合は発生しないため、それが原因で障害が発生するとは考えにくい。そのため、実行状況別原因確率テーブル１２０の３行目に示されるとおり確率は「０％」と設定されている。共通して利用するリソースがハードディスクやＬＡＮカードの場合も、同様にそれぞれに対して抽出された事象ごとに確率を設定する。

ただし、４つの観点から評価した確率を原因候補ごとに掛け合わせる場合、「通常状態」の原因確率を０％にしてしまうと、他の観点でどれだけ確率が高くても最終的に算出する確率が０％になってしまう。このような場合に備え、例えば図９の実行状況別原因確率テーブル１２０の６行目にあるように、「通常状態」のときは原因である確率を「５０％」などと設定してもよい。「通常状態」に対する確率の設定も、共通して利用するリソースごとに異ならせてよい。この場合、障害原因検出部３８は、「通常状態」のときも実行状況別原因確率テーブル１２０を参照して確率を取得する。

実行状況別原因確率テーブル１２０を含む原因確率情報は、基本的なものをあらかじめ設定して原因確率記憶部４６に記憶させておき、実際の運用に即した判定項目や確率の値となるようにユーザが更新できるようにしてもよい。

前述のとおり、「通常状態」として定義する状態は、実績として発生確率が所定のしきい値以上となった事象である。このしきい値は、共通して利用するリソース、サーバ、ジョブの処理内容などに応じて適宜個別に設定してもよい。例えばアクセスの順序が多少変化してもそれによって障害が発生することが考えにくいようなジョブばかりを処理する場合、少しの変化を「異常状態」と抽出してしまうと原因の絞り込みがしづらくなる。このような場合は、「通常状態」と判定される事象の範囲を広げるため、しきい値を低く設定する。このようにジョブの処理内容やリソースなどによって「異常状態」として抽出すべき事象の割合を調整することにより、意味のない事象の抽出を防止し、原因検出の効率を上げる。

同様の理由により障害原因検出部３８は、ある判定項目について「異常状態」となった事象を抽出し、実行状況別原因確率テーブル１２０から当該事象が原因となり得る確率を取得した後、当該判定項目の「通常状態」の実績としての発生確率に応じて、取得した原因確率を補正してもよい。例えば、「通常状態」のしきい値がＸ％と設定されているときに、実際には「通常状態」の発生確率がＹ％であるような判定項目に対し「異常状態」が抽出され、それが原因となり得る確率がＺ％であった場合、補正後の原因となり得る確率Ｚ’％は以下のように導出する。
Ｚ’＝Ｚ＋（１−Ｚ）×｜Ｙ−Ｘ｜／（１−Ｘ）

これにより、実際の発生確率Ｙ％がしきい値Ｘ％より大きく、ほとんどが「通常状態」となるような判定項目は、「異常状態」として抽出された事象の異常性が高いため、障害原因となり得る確率を増加させる。例えば、しきい値が８０％、「通常状態」の発生確率が８４％、原因となり得る確率が９０％であった場合、補正後の原因となり得る確率は９２％となる。このような補正を行うことにより、より精度の高い原因確率を示すことができる。なお上記の式は例示であり、例えば開発機でのテストや実際の運用時において、判定項目の「通常状態」の発生確率Ｙ％とその項目の「異常状態」が障害原因となった確率が近似直線で分布することが判明している場合などに用いることができる。補正に用いる式はその他に、様々な確率分布に基づき導出される関数を適宜選択してよい。

次に、上記４つの観点のうち、障害ジョブの利用リソースのエラー情報から障害原因を検出する具体例を説明する。図１０は図４のＳ３４で障害原因検出部３８が参照する原因確率情報である、リソース別確率テーブルの例を示す。リソース別確率テーブル１３０はリソース欄１３２、エラー内容欄１３４、および確率欄１３６を含む。リソース欄１３２に記載された利用リソースに対しエラー内容欄１３４に記載されたエラー内容がエラーログに記録されていたら、確率欄１３６に記載された確率が当該エラーが原因である確率となる。実際にはリソース欄１３２に記載された一つのリソースに対し、エラー内容欄１３４に複数のエラー内容を設定してよく、エラー内容ごとに確率欄１３６に確率を設定してよい。

図２で示した障害の場合、図８で示した利用リソース情報テーブル１００から、障害が発生したジョブＸはデータベースを利用していることがわかる。つぎに当該データベースのエラーログを見て、「スナップショットが古すぎます」という内容のエラーが記録されていたら、当該データベースが障害原因となり得る確率を「９５％」とする。

次に、上記４つの観点のうち、同リソース利用ジョブ自体の状況から障害原因を検出する具体例を説明する。図１１は図４のＳ３６で障害原因検出部３８が参照する原因確率情報である、リソース利用率別確率テーブルの例を示す。リソース利用率別確率テーブル１４０は、リソースの空きスペースに対する利用率の欄１４２、および確率欄１４４を含む。リソースの空きスペースに対する利用率は、利用リソース情報テーブル１００のリソース利用率欄１０８に設定した、各ジョブのリソース利用率を、ジョブ処理直前の当該リソースの空きスペースに対する利用率に換算したものである。

空きスペースは、リソースがハードディスクやメモリであればデータが格納されていない記憶領域の容量、ネットワークであれば使用されていない帯域に対応し、他のジョブやデータに占有されていない、自身のジョブが利用できる領域のことである。ジョブ処理直前のリソースの空きスペースは一般的なオペレーションシステムで提供されるスナップショットの機能により取得することができる。

空きスペースに対する利用率が増加するほど、他のジョブは当該リソースを利用できなくなり障害が発生しやすくなる。従って、リソース利用率別確率テーブル１４０もそのように設定する。またリソース利用率別確率テーブル１４０はリソースごとに用意してもよい。図７で示した障害の場合、図８で示した利用リソース情報テーブル１００から、障害ジョブであるジョブＢと同じＬＡＮカードを利用しているジョブがジョブＸ、ジョブＹであること、ジョブＸとジョブＹの当該ＬＡＮカードに対する利用率がそれぞれ「６０％」、「３０％」であることがわかる。したがって各ジョブがＬＡＮカードを単独で利用していた場合でも、ジョブＸとＬＡＮカードが原因である確率、ジョブＹとＬＡＮカードが原因である確率はいずれも、「９５％」となる。

上記は同リソース利用ジョブ自体の状況としてリソース利用率を採用した場合であるが、前述のとおり、本実施の形態に利用できる同リソース利用ジョブの状況はそれに限らない。例えば同リソース利用ジョブの処理時間に着目してもよいし、それらを組み合わせて評価してもよい。図１２は同リソース利用ジョブの平均処理時間に対する当日の処理時間の割合ごとに確率を設定した処理時間別確率テーブルの例を示す。処理時間別確率テーブル１５０は、当日の処理時間／平均処理時間の欄１５２および確率欄１５４を含む。

同テーブルにより、過去の平均処理時間に対する当日の処理時間の割合に基づき、同リソース利用ジョブが障害原因となり得る確率を取得する。同リソース利用ジョブの処理時間が通常より長くなっているほど、リソースに何らかの問題が発生していたり障害ジョブに影響を与えやすいと考えられるため、処理時間別確率テーブル１５０もそのように設定する。各ジョブの平均処理時間はジョブ処理部３６がジョブの処理を行う都度、計算して実行状況記憶部４４に格納しておく。当日の処理時間はジョブ処理部３６が実行状況記憶部４４に格納した当日のジョブのログから、障害原因検出部３８が導出する。

次に、上記４つの観点のうち、同様の障害の発生頻度から障害原因を検出する具体例を説明する。図１３は図４のＳ４０で障害原因検出部３８が参照する原因確率情報である、発生頻度別確率テーブルの例を示す。発生頻度別確率テーブル１６０は、発生頻度欄１６２と確率欄１６４を含む。上述のとおり、障害が発生した際、高確率で原因と推定された原因候補、あるいは真の原因と確定したジョブやリソースは蓄積して記憶しておく。そして障害発生時は、障害ジョブに対し過去に原因として記憶された頻度に基づき、原因候補が障害原因となり得る確率を取得する。図１３に示すように、発生頻度が高ければそれが原因である確率も高く設定する。障害原因検出部３８は、障害発生時に、実行状況記憶部４４を参照して各原因候補ごとの発生頻度を取得し、次に発生頻度別確率テーブル１６０を参照して、原因候補ごとの確率を取得する。

図１４は以上述べた４つの観点から障害原因の評価を行い、最終的に各原因候補が原因となり得る確率を算出した例を示している。障害確率算出テーブル１７０は、原因ジョブ欄１７２、確率欄１７４、原因リソース欄１７６、リソースエラーによる確率欄１７８、同リソース利用ジョブの状況による確率欄１８０、障害ジョブ・同リソース利用ジョブの相対状況による確率欄１８２、発生頻度による確率欄１８４を含む。障害原因検出部３８は、障害確率算出テーブル１７０のリソースエラーによる確率欄１７８、同リソース利用ジョブの状況による確率欄１８０、障害ジョブ・同リソース利用ジョブの相対状況による確率欄１８２、発生頻度による確率欄１８４を埋めるように、各観点から評価を行い、原因候補ごとに取得した原因確率を取得する。そしてそれらの確率を掛け合わせて、確率欄１７４に示すように最終的な確率を算出する。ここでは前述のとおり、掛け合わせ以外の手法を用いてもよい。

出力部４０が出力するデータは、原因ジョブ欄１７２、確率欄１７４、原因リソース欄１７６のみでもよいし、障害確率算出テーブル１７０を全て出力してもよい。前者の場合、実際には障害確率算出テーブル１７０を作成せず、各観点からの評価による確率はレジスタなどに一時保存して最終的な確率を算出するようにしてもよい。図１４に示した例では、「ジョブＢ」が障害原因となり「データベース」を媒介して障害が発生した確率は、リソースエラーによる確率が「９５％」、同リソース利用ジョブの状況による確率が「９５％」、障害ジョブ・同リソース利用ジョブの相対状況による確率が「９０％」、発生頻度による確率が「９８％」であることが各欄からわかる。そして最終的な確率が「７９．６０％」となっており、他の原因候補よりその確率が高い。したがってユーザはジョブＢとデータベースに着目し、障害原因を集中的に検証していくことができる。

これまでの説明は、障害ジョブの同リソース利用ジョブに障害が発生していないことを前提にしていたが、図４のＳ３６において利用リソース情報を参照して同リソース利用ジョブを取得したら、当該ジョブの当日のログを参照して障害の有無を確認するようにしてもよい。共通するリソースを利用する２つのジョブに障害が発生していたら、当該リソースに何らかの問題が発生し、障害原因となっている確率が高い。したがって、同リソース利用ジョブに障害が発生していた場合は、当該利用リソースが障害の原因である確率を高くするように重み付けを行う。

同リソース利用ジョブが同じ利用リソースに対して複数存在する場合は、それら全てのジョブの障害の有無を確認する。そして障害が発生している同リソース利用ジョブの数が増加するほど、それらが共通して利用するリソースの原因確率を高くする。あるいは、所定数以上の同リソース利用ジョブに障害が発生していることが判明した場合、それらが共通して利用するリソースが障害の原因であることは明らかと考えてもよい。例えばドライブＤを利用するジョブＢ、ジョブＸ、ジョブＺの３つのジョブに障害が発生していた場合、ドライブＤに何らかの問題が生じ障害を発生させていると考える。

この場合は、以後の障害原因の評価を行わずに、当該リソースに原因があることを出力部４０に出力してユーザに通知したうえ、以後に処理が予定されていた、あるいは処理中の、当該リソースを利用するジョブの処理を自動的に停止するようにしてもよい。この操作は、障害原因検出部３８がジョブ処理部３６を制御することによって行う。このようにすることで、障害原因を検出しその確率を出力するばかりでなく、一のリソースが障害原因であることを判断し、ユーザが対応するより早く他のジョブを停止することができ、障害が伝搬していくという二次災害を防止することができる。

以上、述べた本実施の形態によれば、処理するジョブと利用するリソースとを対応づけた利用リソース情報をあらかじめ用意する。障害発生時にはその情報に基づき、障害原因の候補を検出し、各候補が原因となり得る確率を出力する。確率は、利用リソースのエラー、同リソース利用ジョブの状況、障害ジョブと同リソース利用ジョブとの相対的な状況、同様障害の発生頻度、の４つの観点の少なくともいずれかを評価することにより取得する。これにより、一見関連性を見いだせないジョブ同士の障害上のつながりを容易に取得することができ、ユーザによる障害対応に有効な情報を提示することができる。

また利用リソース情報をサーバ間で共通とすることにより、管理部門が異なったり別の場所に設置されたサーバにおいて処理されているジョブにも原因を求めることができる。また４つの観点での評価を全て行った場合は、多角的な評価によって確率の精度が向上する。確率を表示することにより、ユーザは検証作業の優先順位づけを容易に行え、復旧作業の効率が上がる。

障害ジョブと同リソース利用ジョブとの相対的な状況を評価する際は、実行状況を蓄積して記憶しておき、それに基づき「通常状態」を定義する。そして「通常状態」に対する「異常状態」を判定することにより、ログなどからは「異常」と認識されない事象をも障害原因として検出することができる。「通常状態」か否かを判定する対象となるジョブは、利用リソース情報を参照して得られる同リソース利用ジョブとすることで、効率的な原因候補の絞り込みを行うことができる。

また、共通のリソースを利用している複数のジョブに障害が発生した場合は、当該リソースが障害原因である確率が著しく高いと判断し、そのリソースを利用している未処理のジョブなどを停止する。これにより人手を借りずとも明白な障害に対し、緊急を要する対応を迅速に行うことができ、被害の拡大を防止できる。

本実施の形態は、新規のハードウェアを導入せずに実施することが可能であるため、安価で容易に既存のシステムに適用することが可能である。また、障害の原因となり得る要因を詳細に洗い出すことが可能であるため、運用機のみならず開発機でのテスト運用などに導入することにより、改善点を抽出するなど、システム開発に対する支援を行うこともできる。

以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

本実施の形態を適用できるシステムの構成例を示す図である。 障害ジョブと同リソース利用ジョブとの相対的な状況によって障害上の関連性が発生した場合を模式的に示す図である。 本実施の形態における第１サーバの構成をより詳細に示す図である。 本実施の形態における障害発生時の処理手順を示すフローチャートである。 本実施の形態において障害原因検出部が障害ジョブと同リソース利用ジョブの相対的な状況によって障害原因を検出、評価する処理手順を示すフローチャートである。 本実施の形態のジョブの相対関係の評価により原因を検出できる障害事例を説明する図である。 本実施の形態のジョブの相対関係の評価により原因を検出できる障害事例を説明する図である。 本実施の形態において利用リソース情報取得部が作成する利用リソース情報のデータ構造の例を示す図である。 本実施の形態において「異常状態」である事象に対して設定される実行状況別原因確率テーブルの例を示す図である。 図４のＳ３４で障害原因検出部が参照する原因確率情報である、リソース別確率テーブルの例を示す図である。 図４のＳ３６で障害原因検出部が参照する原因確率情報である、リソース利用率別確率テーブルの例を示す図である。 本実施の形態における同リソース利用ジョブの平均処理時間に対する当日の処理時間の割合ごとに確率を設定した処理時間別確率テーブルの例を示す図である。 図４のＳ４０で障害原因検出部３８が参照する原因確率情報である、発生頻度別確率テーブルの例を示す図である。 本実施の形態において４つの観点から障害原因の評価を行い、最終的に各ジョブ、リソースが原因となり得る確率を算出した例を示す図である。

符号の説明

１０ ジョブ処理システム、１２ 第１サーバ、 １３ ハードディスク、 １４ 第２サーバ、 ２０ データベース、 ３２ ジョブ登録部、 ３４ 利用リソース情報取得部、 ３６ ジョブ処理部、 ３８ 障害原因検出部、 ４０ 出力部、 ４２ ジョブ情報記憶部、 ４４ 実行状況記憶部、 ４６ 原因確率記憶部。

Claims (9)

1. ジョブをバッチ処理するジョブ処理システムであって、
   ジョブを処理する都度、ジョブの実行状況の情報を蓄積して記憶する実行状況記憶部と、
   処理中のジョブのいずれかに異常が発生した際、前記実行状況の情報を参照して、異常が発生したジョブと、同バッチ処理において処理されていたその他のジョブの処理時間の相対的な関係が、過去の実績において所定のしきい値を超えた確率で発生している通常状態からはずれた異常状態となっている事象を原因候補として検出する障害原因検出部と、
   前記障害原因検出部が検出した、原因候補に係る情報を出力する出力部と、を備えたことを特徴とするジョブ処理システム。
2. 異常状態として抽出されると予想される事象と、その事象が障害原因となり得る確率の設定値とを対応づけた実行状況別原因確率テーブルを記憶する原因確率記憶部をさらに備え、
   前記障害原因検出部は、前記実行状況別原因確率テーブルを参照して前記原因候補として検出した事象が障害原因となり得る確率を取得し、
   前記出力部は、前記原因候補として検出した事象とそれが障害原因となり得る確率とを対応づけて出力することを特徴とする請求項１に記載のジョブ処理システム。
3. 前記ジョブ処理システムにおいて処理されるジョブと、当該ジョブが利用するリソースとを対応づけた利用リソース情報を記憶するジョブ情報記憶部さらに備え、
   前記障害原因検出部は、前記利用リソース情報を参照して特定した、障害が発生したジョブが利用するリソースのログにエラーが記録されていた場合、前記原因候補として検出した事象のうち、エラーが記録されていたリソースが関連する事象が障害原因となり得る確率を高くするように重み付けを行うことを特徴とする請求項２に記載のジョブ処理システム。
4. 前記ジョブ処理システムにおいて処理されるジョブと、当該ジョブが利用するリソースおよび当該リソースを前記ジョブが利用する際の利用率とを対応づけた利用リソース情報を記憶するジョブ情報記憶部さらに備え、
   前記障害原因検出部は、前記利用リソース情報を参照して、障害が発生したジョブと同一のリソースを利用している他のジョブの当該リソースの利用率を特定し、障害が発生した際のバッチ処理における、前記他のジョブの、リソースの空きスペースに対する利用率の大きさに応じて、前記原因候補として検出した事象のうち、前記他のジョブが関連する事象が障害原因となり得る確率に重み付けを行うことを特徴とする請求項２に記載のジョブ処理システム。
5. 前記実行状況記憶部は、過去に障害が発生したジョブとその障害原因とを対応づけてさらに記憶し、
   前記障害原因検出部は、障害が発生したジョブに対し過去に障害原因となった頻度に応じて、前記原因候補として検出した事象が障害原因となり得る確率に重み付けを行うことを特徴とする請求項２に記載のジョブ処理システム。
6. 前記障害原因検出部は、過去の実績における通常状態が発生する確率と前記しきい値との差に応じて、前記原因候補として検出した事象が障害原因となり得る確率を補正することを特徴とする請求項２に記載のジョブ処理システム。
7. 前記障害原因検出部は、障害が発生したジョブと同一のリソースを利用しているジョブに障害が発生していた際、前記原因候補として検出した事象のうち、当該リソースが関連する事象が障害原因となり得る確率を高くするように重み付けを行うことを特徴とする請求項４に記載のジョブ処理システム。
8. 前記障害原因検出部は、障害が発生したジョブと同一のリソースを利用しているジョブのうち所定数以上のジョブに障害が発生していた場合、当該リソースを障害原因と推定し、当該リソースを利用する処理中および未処理のジョブを停止するよう制御を行うことを特徴とする請求項４または７に記載のジョブ処理システム。
9. ジョブ処理システムにおいてバッチ処理されるジョブと各ジョブが利用するリソースに係る情報とを対応づけた利用リソース情報を取得するステップと、
   ジョブを処理する都度、ジョブの実行状況の情報を蓄積して記憶するステップと、
   処理中のジョブのいずれかに異常が発生した際、前記利用リソース情報および前記実行状況の情報を参照して、当該ジョブが利用するリソースのエラーの有無と、当該ジョブと同一のリソースを利用する他のジョブの実行状況と、障害が発生したジョブと当該ジョブと同一のリソースを利用する他のジョブの処理時間の相対的な関係の通常状態からの変化の有無と、障害が発生したジョブに対し過去に障害原因となった頻度と、の少なくともいずれかを確認して、障害原因の候補を検出するステップと、
   前記障害原因の候補に係る情報を出力するステップと、
   を含むことを特徴とするジョブ管理方法。

Images