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

Abstract

【課題】ジョブのバッチ処理時に発生した障害を復旧するのは困難である。
【解決手段】ジョブ処理を行うシステムに含まれる各サーバにおいて、利用リソース情報取得部３４は、ジョブ登録部３２においてユーザが登録したジョブフローに基づき、各ジョブが利用するリソースなどを抽出して、利用リソース情報のテーブルを作成する。既存のジョブについてはジョブ処理時のスナップショットなどに基づき利用リソース情報のテーブルを作成する。ジョブ処理時に障害が発生した際、障害原因検出部３８は、利用リソース情報のテーブルとエラーログなどを参照して、異常となったジョブが利用しているリソースに基づき原因を検出する。
【選択図】図２

Description

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

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

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

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

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

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

本発明のある態様は、ジョブ処理システムに関する。このジョブ処理システムは、ジョブをバッチ処理するジョブ処理システムであって、登録されたジョブフローから、ジョブ処理システムにおいて処理されるジョブと、当該ジョブが利用するリソースに係る情報とを対応づけた利用リソース情報を取得する利用リソース情報取得部と、処理中のジョブのいずれかに異常が発生した際、利用リソース情報を参照して当該ジョブが利用するリソースを特定し、それに基づきジョブ処理システムが記録するログ情報の少なくともいずれかを異常発生時から時間を遡って参照して、特定したリソースに関連するエラー情報を取得することにより、異常となった原因と推定される要因を検出する障害原因検出部と、障害原因検出部が検出した、原因と推定される要因に係る情報を出力する出力部と、を備えたことを特徴とする。

ここでジョブ処理システムは複数のサブシステム、サーバなどかで構成されていてよく、その場合、利用リソース情報はサブシステム間、サーバ間で共通の情報であってよい。「異常」とは、ジョブの停止、処理完了の遅延、出力データの誤り、処理速度の低下など、通常の状態や予定と異なる状態であり、ユーザによって異なる基準であってもよい。また「リソース」とはハードディスク、データベース、ＬＡＮカード、ネットワーク、ＣＰＵ、など、ジョブの処理において用いられる物的、時間的リソースのいずれでもよい。さらに「利用する」とは、読み出し、書き込み、アクセス、使用、転送、など、ジョブとリソースとを関連づける動作であればその種別は限定されない。

本発明の別の態様も、ジョブ処理システムに関する。このジョブ処理システムは、ジョブをバッチ処理するジョブ処理システムであって、登録されたジョブフローから、ジョブ処理システムにおいて処理されるジョブと、当該ジョブが利用するリソースに係る情報とを対応づけた利用リソース情報を取得する利用リソース情報取得部と、処理中のジョブのいずれかに異常が発生した際、利用リソース情報を参照して、当該ジョブが利用するリソースと関連のあるジョブを特定し、それに基づきあらかじめ登録されたジョブの処理順序情報を参照することにより、以後に処理が予定されているジョブのうち関連のあるジョブを、影響の及ぶジョブとして検出する障害影響検出部と、障害影響検出部が検出した影響の及ぶジョブに係る情報を出力する出力部と、を備えたことを特徴とする

本発明のさらに別の態様は、ジョブ管理方法に関する。このジョブ管理方法は、ジョブ処理システムにおいてバッチ処理されるジョブと各ジョブが利用するリソースとを対応づけた利用リソース情報を取得するステップと、処理中のジョブのいずれかに異常が発生した際、利用リソース情報を参照して当該ジョブが利用するリソースを特定し、それに基づきジョブ処理システムが記録するログ情報の少なくともいずれかを異常発生時から時間を遡って参照して、特定したリソースに関連するエラー情報を取得することにより、異常となった原因と推定される要因を検出するステップと、原因と推定される要因に係る情報を出力するステップと、を含むことを特徴とする。

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

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

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

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

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

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

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

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

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

図２は第１サーバ１２の構成をより詳細に示している。第２サーバ１４、第３サーバ１６、第４サーバ１８も同様の構成としてよい。第１サーバ１２は、ユーザがジョブフローなどを登録するジョブ登録部３２、各ジョブが利用するリソースの情報を抽出する利用リソース情報取得部３４、ジョブフローや利用リソース情報を記憶するジョブ情報記憶部４２、登録されたジョブを処理するジョブ処理部３６、障害発生時にその原因を検出する障害原因検出部３８、検出した原因に係る情報を出力する出力部４０を含む。

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

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

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

抽出不能なフォーマットでジョブフローが登録済みの場合やマシンコード化されていてジョブフローが明らかでない場合など、利用リソースの抽出が困難な場合は、各ジョブを実際に処理しながらジョブ処理システム１０の各種内部情報を取得することにより利用リソースおよび処理内容を特定する。詳細な手法については後述する。作成した利用リソース情報のテーブルもジョブ情報記憶部４２に格納する。

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

ジョブ処理部３６は、ユーザが登録したジョブフロー、ジョブの処理順序などの情報をジョブ情報記憶部４２から読み出し、実行する。これはジョブを処理する一般的なシステムで用いられる手法を適用することができる。

障害原因検出部３８は障害発生時に、利用リソース情報取得部３４が作成した利用リソース情報のテーブルをジョブ情報記憶部４２から読み出し、異常となったジョブが利用しているリソース、および当該リソースを利用している他のジョブを抽出する。そして抽出したリソースを備えたサーバや抽出した他のジョブを処理していたサーバの各種ログをもとに障害原因の絞り込みを行う。このとき、原因として複数の現象を検出した場合は、あらかじめ設定した基準により原因である確率も取得する。詳細な手法は後述する。

出力部４０は一般的な表示装置やプリンタなどの出力装置でよく、障害原因検出部３８が検出した障害原因、あるいは検出した現象とその原因たる確率を出力する。さらに、後述するように利用リソース情報取得部３４が、具体的な処理内容が不明のジョブの処理内容を特定した場合に、特定した情報に基づき新たなジョブフローの図を出力する。

次に上記の構成によるジョブ処理システム１０の動作について説明する。図３はジョブフローの登録からジョブの処理までの手順を示すフローチャートである。同図は前提として、処理するジョブの利用リソース情報が作成されていない場合を示している。まずユーザは、新規ジョブを処理する場合（Ｓ１０のＹ）、第１サーバ１２などのジョブ登録部３２に対しジョブフローの登録を行う（Ｓ１２）。このとき必要に応じてジョブの処理順序や処理開始時間などについても登録を行う。

すると利用リソース情報取得部３４は、登録されジョブ情報記憶部４２に記憶されたジョブフローの情報を参照して利用リソース情報を作成する（Ｓ１４）。このとき、すでに他のジョブの利用リソース情報のテーブルがジョブ情報記憶部４２に格納済みであれば、当該テーブルに追加で書き込む。格納済みでなければ新たにテーブルを作成してジョブ情報記憶部４２に格納する。利用リソース情報のテーブルの具体例は後に詳述する。

一方、既にジョブ処理が可能な既存のシステムに本実施の形態を導入した際など、新規のジョブを登録する必要がない場合（Ｓ１０のＮ）において、利用リソース情報取得部３４が対応できるフォーマットにてジョブフローが登録済みであれば（Ｓ１８のＹ）、利用リソース情報取得部３４は同様に利用リソース情報を作成する（Ｓ１４）。一方、登録済みのジョブフローフォーマットが利用リソース情報取得部３４の対応可能フォーマットと異なる場合は（Ｓ１８のＮ）、そのままでは利用リソース情報を作成できないため、少なくとも１度ジョブを処理してジョブの前後を含む所定のタイミングでジョブ処理システム１０の内部情報を取得することによりジョブの処理内容を特定する（Ｓ２０）。この際のジョブ処理は、開発機でテスト処理として行ってもよいし、実際の運用における処理を利用してもよい。

そして得られた処理内容から利用リソース情報を作成する（Ｓ１４）。ここで作成したジョブフローは、ジョブの詳細な処理内容が失われている場合などにおいてもそれを確認する手だてとなるとともに、適宜フォーマットの変換を行い別のシステムに当該ジョブを移植することも可能となる。Ｓ２０の処理内容の特定手法については後に詳述する。

利用リソース情報が作成されたら、Ｓ１２で登録したジョブ処理の順序や処理の開始時間などに則り、ジョブ処理部３６が実機におけるジョブ処理を実行する（Ｓ１６）。Ｓ１６のジョブ処理は複数のジョブのバッチ処理でよい。また同図においてＳ１６のジョブ処理には、障害発生によるジョブの異常終了があった際の、障害原因検出部３８による原因の検出、出力部４０への原因の表示、ユーザによる復旧なども含まれてよい。障害発生時の障害原因検出部３８の動作については後に詳述する。

図４は図３のＳ１２において登録されるジョブフローの図の一例を示している。この例のジョブフローは、第１ステップ５０および第２ステップ５２の２段階の処理によって構成されている。第１ステップ５０は、第１サーバ１２のハードディスク１３のドライブＤに格納されたファイルを、シェル５４によって同じくドライブＤに別名で保存する処理である。同図の例は、前日に作成された入出金明細のファイル「ａａａ．ｔｘｔ」を、作成された年月日を表す数列「ｙｙｙｙｍｍｄｄ」を含むファイル名「ａａａ．ｔｘｔ．ｙｙｙｙｍｍｄｄ」を有するファイルとして保存する。すなわち入出金明細のバックアップファイルを作成する。

第２ステップは、プログラム５６により、第１サーバ１２に接続したデータベース２０から新たな入出金明細のデータを作成し、第１サーバ１２のハードディスク１３のドライブＤにそのファイルを格納する処理である。同図の例では、第１ステップ５０でバックアップを作成しておいたファイル「ａａａ．ｔｘｔ」を当日分のデータで上書きする。以上の処理を含むジョブを例えば毎日所定の時間に処理することにより、ドライブＤには日々の入出金明細のデータがファイル名に日付を含む形で蓄積されていくことになる。

第１ステップにおいて入出金明細のファイル「ａａａ．ｔｘｔ」をバックアップファイル「ａａａ．ｔｘｔ．ｙｙｙｙｍｍｄｄ」として保存するためのシェル５４は、ユーザ自身が作成してジョブ情報記憶部４２に登録してもよいし、対話式の登録手段を用いてジョブ登録部３２が自動で作成してジョブ情報記憶部４２に格納してもよい。第２ステップにおいて新たな入出金明細ファイルを作成するプログラム５６は、あらかじめ作成しておいたものをジョブ情報記憶部４２に格納しておいてもよいし、図示しない他の記憶装置から呼び出してロードするようにしてもよい。

ユーザはジョブ登録部３２に対し、図４のようなジョブフローを対話形式で、あるいはスクリプトファイルを自作するなどしてジョブの名前とともに登録する。ジョブ登録部３２は登録されたジョブの名前などをファイル名として、各ジョブフローをジョブ情報記憶部４２に格納する。以下の説明では、図４で示したジョブの名前を「ジョブＡ」とする。

図５は利用リソース情報取得部３４が作成する利用リソース情報のデータ構造の例を示している。利用リソース情報テーブル１００は、ジョブ名欄１０２、利用サーバ欄１０４、利用リソース種類欄１０６、リソース詳細欄１０８、および備考欄１１０を含む。前述の通り利用リソース情報取得部３４は、新たなジョブフローが登録されるたびに、利用リソース情報テーブル１００にエントリを追加していく。また、ジョブフローがない場合はスナップショットの差分により利用リソース情報を取得してエントリを追加する。

ジョブ名欄１０２には、ユーザが登録を行ったジョブの名前を記載する。利用サーバ欄１０４にはそれぞれのジョブが利用するリソースが属するサーバの名前を記載する。利用リソース種類欄１０６には利用するリソースの種類、例えばハードディスク、データベース、ＬＡＮカードなどを識別する情報を記載する。リソース詳細欄１０８には、具体的なリソースの識別情報を記載する。備考欄１１０には当該リソースを利用する際の処理の概要を記載する。

図４で示した「ジョブＡ」の場合、第１ステップ５０では第１サーバ１２のハードディスク１３のドライブＤにアクセスし、入出金明細ファイルのバックアップを作成しているため、図５に示した利用リソース情報テーブル１００の３行目において、利用サーバ欄１０４には「第１サーバ」、利用リソース種類欄１０６にはハードディスクを示す「ＤＩＳＫ」、リソース詳細欄１０８には「ドライブＤ」、備考欄１１０には「バックアップ」と記載されている。また同ジョブは、第２ステップ５２において新たに作成した入出金ファイルを同ドライブＤに格納しているため、備考欄１１０にはさらに「入出金明細作成」と記載されている。

また「ジョブＡ」は、第２ステップ５２において新たなファイルを作成する際、第１サーバ１２に接続したデータベース２０を参照しているため、利用リソース情報テーブル１００の２行目において、利用サーバ欄１０４には「第１サーバ」、利用リソース種類欄１０６にはデータベースへのアクセスを示す「ＤＢＭＳ」、リソース詳細欄１０８には「データベース」、備考欄１１０には「データ参照」と記載されている。図５に示された「ジョブＢ」、「ジョブＺ」も同様の記載がなされている。

利用リソース情報のデータ構造は図５に示したものに限らない。例えばＣＰＵ使用率、ハードディスクの利用率、データベースを参照するのみか更新するかを識別する情報などを記録してもよい。さらに、利用するリソースごとに利用頻度を記録してもよい。ＣＰＵ使用率やハードディスクの利用率など、ジョブフローから特定が困難なパラメータは、開発機や実機において実際にジョブを処理した際の各パラメータの変化量や実績を取得することによって得ることができる。このような詳細な記録を利用リソース情報に含めるほど原因検出の精度が向上する。

次に、図３のＳ２０においてジョブの処理内容を特定する手法について説明する。図６は、利用リソース情報取得部３４が実際のジョブ処理によって処理内容を特定する処理手順を示すフローチャートである。まず実機または開発機において対象となるジョブを処理する（Ｓ７０）。これは利用リソース情報取得部３４がジョブ処理部３６を制御して処理を開始させてもよいし、通常の運用ベースで当該ジョブの処理が開始したことを利用リソース情報取得部３４が検知するようにしてもよい。

そして、ドライブログ、ジョブログ、ＯＳのauditログ、Oracle（登録商標）のRedoログなど、ジョブの進捗に応じたジョブ処理システム１０の内部の変化を記録した内部情報のうち獲得したい情報に応じた内部情報を、所定の複数のタイミングで取得する（Ｓ７２）。これにはOracleのスナップショットなどの機能を利用することができる。取得するタイミングは、ジョブ処理の開始直前、開始直後、ログに何らかの書き込みが行われた時点、ジョブ処理の終了直前、終了直後などから、取得する情報に応じて適宜設定しておく。また所定の時間間隔で取得するようにしてもよい。

次に、取得した内部情報から、取得する情報に応じたタイミングの内部情報を２つ抽出し、それらの差分をとる（Ｓ７４）。２つの内部情報を取得した時刻の間隔をＴとすると、先に取得した内部情報に時間Ｔの間の処理を加えたものが後の内部情報になっている。これを利用して、２つのタイミングの内部情報の差分から、時間Ｔにおけるジョブの処理内容を特定する（Ｓ７６）。具体的には、データベースやファイルが作成されたか読み出されたか更新されたか削除されたか、を示すＣＲＵＤ（Create, Read, Update, Delete）などを取得する。

図７は図４で示したジョブＡ処理時の３つのタイミングにおけるジョブログの例を示している。同図では時刻の早い順に、時刻ｔ＝ｔ０におけるジョブログ６０、時刻ｔ＝ｔ１におけるジョブログ６２、時刻ｔ＝ｔ２におけるジョブログ６４を並べて示している。例えばこれらを内部情報として取得すると、ジョブログ６２とジョブログ６０との差分から、時刻ｔ０からｔ１の間に１つのファイルがコピーされていることがわかる。またジョブログ６４とジョブログ６２との差分から、時刻ｔ１から時刻ｔ２の間に入出金明細のファイルが作成されていることがわかる。

さらに、ジョブログに何らかの書き込みが行われた都度、ドライブDやデータベース２０のログを取得するようにすれば、その差分から時刻ｔ０からｔ１の間にファイル「ａａａ．ｔｘｔ．ｙｙｙｙｍｍｄｄ」が生成されていることがわかり、当該ファイルが第１ステップのコピー先であることが判明する。同様に、時刻ｔ１からｔ２の間にファイル「ａａａ．ｔｘｔ」が更新されていることがわかり、当該ファイルが生成された入出金明細であることがわかる。同時にデータベース２０が参照されていることがわかる。

さらに、ファイル読み出しや書き込みなどの処理に対するタイムスタンプ、ファイルのサイズ、誤り検出で一般的に用いられるチェックサムなどのファイルの付加情報を取得することにより、２つのファイルの同一性等を判定すれば、ファイルの関係を把握することもできる。例えばファイル「ａａａ．ｔｘｔ」およびファイル「ａａａ．ｔｘｔ．ｙｙｙｙｍｍｄｄ」のサイズやチェックサムが同一であれば、これらのファイルは同一のファイルのコピー元、コピー先であると判定でき、時刻ｔ０からｔ１の間で「ａａａ．ｔｘｔ」バックアップ処理がなされたことを特定できる。

あるいは、一般的に用いられるファイルの名付けルールに基づき、ファイル名に含まれやすい文字列、数列をあらかじめ用意しておき、処理されたファイルの名前にそれらの文字列、数列が含まれているか否かを解析するようにしてもよい。例えば「ａａａ．ｔｘｔ．ｙｙｙｙｍｍｄｄ」に含まれる「ｙｙｙｙｍｍｄｄ」は、実際には「２００７１１０７」などという数字が充てられるが、これが日付であることを数列の構成から判断する。日付の他に、追い番などでも同様である。すると、ファイル名「ａａａ．ｔｘｔ」とファイル名「ａａａ．ｔｘｔ．ｙｙｙｙｍｍｄｄ」とを比較したとき、後者は前者のファイル名に日付を付加したものであるため、後者が前者をコピーしたファイルである確率が高くなる。

このように、スナップショットの差分、ファイルの付加情報、ファイル名の特徴などにより多角的に判断を行うことにより、各ジョブがどのリソース、ファイルに対しどのような操作を行ったかを特定できるため、それをもとに図４で示したようなジョブフローおよび図５で示したような利用リソース情報を作成することができる。ジョブフローの図はあらかじめ規定したフォーマットに得られた情報を代入していくことで、ユーザの出力指示に従い出力部４０が出力する。

運用ベースでジョブの処理を行う場合、複数のジョブが並列に処理されており、かつジョブログに更新内容が出力されないことが考えられる。このような状況でのジョブの処理を利用してジョブフロー、利用リソース情報を作成する場合、必要な情報が得られにくい場合がある。例えばＣＰＵ使用率などは、並列で処理されているジョブがある場合にはどのジョブでＣＰＵを使用しているのか区別が困難となる。このように、どのジョブがどのようにリソースを利用したか特定が困難な場合は、対象のジョブが処理される別の機会に情報の取得を何度か試みることによりサンプリング回数を増加させる。

その結果、対象のジョブが単独で処理されるタイミングが発生すれば、当該ジョブについての情報を取得することができる。またあらかじめサンプリング回数に上限を設定しおき、上限に達するまで利用リソース情報を作成することができない場合は、ユーザにその旨を通知してもよい。これによりユーザは当該ジョブを単独で処理して、ジョブ処理システム１０に利用リソース情報を作成させるなどの方策を立てることができる。

またサンプリング回数の上限に達した際は、利用リソース情報取得部３４がジョブ処理部３６を制御して、対象のジョブ以外のジョブを一旦停止させ、その間に対象のジョブのスナップショット等を取得するようにしてもよい。この場合、停止時間をジョブの処理時間の一部の時間とし、停止時間を徐々にずらして何度もサンプリングを行うことにより、最終的に対象ジョブの全貌を把握できるようにする。これにより他のジョブの処理完了が遅延するなど運用上の影響を最小限にすることができる。

上述のとおり、本実施の形態では実際にジョブを処理することにより、その処理内容をジョブフローの形式で自動的に取得することができる。これにより、利用リソース情報の作成が可能となるほか、ジョブフローが明確でなかったり設計書やソースコードが現存しないジョブの処理内容の詳細を特定することができる。このようなことを目的とする場合、利用リソース情報が必要でなければ図３の利用リソース情報作成処理（Ｓ１４）やその後のジョブ処理（Ｓ１６）を省略してよい。そして特定した処理内容を、図４で示したようなジョブフロー図に適宜落とし込み、出力部４０において出力することにより、処理内容をユーザが把握できるようにする。

次に利用リソース情報を利用して障害原因を検出する手法について説明する。図８は本実施の形態における障害発生時の処理手順を示す。同図は、第１サーバ１２において「ジョブＢ」の処理を行い、第２サーバ１４において「ジョブＺ」の処理を行った場合を示している。ここで「ジョブＢ」は図５の利用リソース情報テーブル１００における「ジョブＢ」に対応し、「ジョブＺ」は同利用リソース情報テーブル１００における「ジョブＺ」に対応している。すなわち「ジョブＢ」は第１サーバ１２のハードディスク１３のドライブＤを参照し、第２サーバ１４のドライブＥへファイルの送信を行う。また「ジョブＺ」は第２サーバ１４のハードディスク１５のドライブＥにファイルの書き込みを行う。

第１サーバ１２のジョブ処理部３６および第２サーバ１４のジョブ処理部３６においてこのようなジョブの処理をそれぞれ開始した状態で（Ｓ３０、Ｓ３２）、第２サーバ１４のハードディスク１５のドライブＥの格納データがディスクの容量に達した「フル」の状態になり、エラーログに出力されたとする（Ｓ３４）。一方、その後のあるタイミングで第１サーバ１２の「ジョブＢ」が異常終了したとする（Ｓ３６）。このとき第１サーバ１２の障害原因検出部３８は原因検出処理を次のように実行する。まず、ジョブ情報記憶部４２に格納した利用リソース情報テーブル１００を参照して、ジョブＢが利用するリソースを特定する（Ｓ３８）。その結果、ジョブＢは第１サーバ１２のハードディスク１３のドライブＤを参照し、第２サーバ１４のハードディスク１５のドライブＥにデータ送信を行っていることが判明する。

次に障害原因検出部３８は、第１サーバ１２、第２サーバ１４、第３サーバ１６、第４サーバ１８の全サーバのエラーログを参照する（Ｓ４０）。エラーログは第１サーバ１２〜第４サーバ１８で常時共有できるようにそれらのシステムがアクセス可能なメモリ（図示せず）などに格納するようにしてもよいし、必要に応じて他のサーバに要求信号を送信することにより取得してもよい。その結果、第２サーバ１４のドライブＥのディスクが「フル」の状態であることを検出する。そして利用リソース情報およびエラーログに基づき障害原因を検出する（Ｓ４２）。上記の例ではジョブＢがドライブＥにデータ送信を行うこと、ドライブＥが「フル」の状態であることに基づき、ドライブＥを障害原因として検出する。

利用リソース情報を参照すれば、まずドライブＤ、ドライブＥに原因を求めることができるため、Ｓ４０の処理は該当するサーバあるいはハードディスクのエラーログのみを取得して参照するようにしてもよい。またエラーの収集方法は、エラーログ以外のログを利用してもよいし、ジョブ処理部３６で動作しているジョブスケジューラが直接取得するようにしてもよい。障害原因はジョブＢの異常終了が発生した時点より前にあるため、リソースによる紐づけを利用して、その時点から時間を遡るようにエラーログを逆読みしていくことにより、効率のよい原因検出を実現できる。

次に出力部４０は、障害原因検出部３８が検出した原因についての情報を取得し、表示装置に表示したりプリンタに出力したりすることにより、運用オペレータへ通知する（Ｓ４４）。あるいはネットワークを介して接続した表示装置に表示して障害担当者に通知したり、電子メールを自動送信したりする。

上記のようなシンプルな例ではドライブＥの「フル」状態が原因であると推定できるが、実際には細かい異変を含めエラーが記録されているリソースが複数あり、それらをジョブＢが利用しているために、複数のエラーが障害原因として検出される場合も考えられる。そのような場合に備え、エラーの内容ごとにジョブの障害原因である確率をあらかじめ設定しておく。確率として設定する数値は、それまでの経験値や開発機によるテスト結果などに基づき決定してもよいし、そのエラーが影響する範囲などを考慮して理論的に決定してもよい。具体例は後述する。

そして障害原因検出部３８は、障害原因として検出された全エラーの、原因である確率の設定値を取得し、出力部４０は、それらを一覧として出力するようにしてもよい。また、過去の障害事例のデータを蓄積しておき、今回障害原因として検出された全エラーのうち、過去にもジョブＢの異常終了と同時期に発生しているエラーを抽出し、その発生頻度からジョブＢの異常終了との関連性を推測してもよい。この場合も、検出されたエラーと、その関連の強さを示す指数とを対応づけて一覧として出力する。

上述の例では、ジョブの利用リソース情報とリソースのエラーとを関連づけて、障害の直接的な原因となっているリソースを検出したが、ドライブの監視を行っていない場合など、リソースのエラーログに直接的な原因が記録されていない場合もある。このような場合に備え、障害原因検出部３８は、他のジョブの異常についての情報をさらに取得してもよい。そして利用リソース情報テーブル１００を参照し、同じリソースを利用しているジョブに異常が発生している場合は、当該リソースに原因がある可能性ありと判断し、原因である確率を、あらかじめ設定した値、例えば「５０％」などと表示してもよい。

また、異常となったジョブと同一のリソースＡを利用しているジョブが別のリソースＢも利用しており、リソースＢが根本の障害原因である可能性もある。さらにリソースＢを利用しているまた別のジョブがさらに別のリソースＣを利用しており当該リソースＣが根本の障害原因である可能性もある。本実施の形態では、利用リソース情報によってそのようなリソースを介したジョブ同士のつながりを順次辿り、ログとの突き合わせをおこなうことにより、そのような間接的な障害原因を全て検出することが可能となる。

運用オペレータや障害担当者は、出力部４０が出力した障害の原因に基づき障害対応を適宜行う（Ｓ４６）。例えば原因である確率が高いエラーの順に、そのエラーとジョブＢの異常終了との因果関係を検証していき、原因を絞ったところでその復旧作業を行う。それによりジョブＢの処理が再開される（Ｓ４８）。

図８のような状態においては一般的には、第２サーバ１４で発生した障害と第１サーバ１２で発生した障害とを紐づける手段をもたないことから、第１サーバ１２の運用オペレータは第１サーバ１２で発生したジョブＢの異常終了のみを障害担当者に連絡する。それにより第１サーバ１２で発生した障害の原因究明に手間取ることが多い。また、原因を究明しているうちに第２サーバ１４においてハードディスク１５のドライブＥが復旧し（Ｓ５０）、ジョブＺの処理が再開してしまうと（Ｓ５２）、障害担当者は原因を把握することができない。さらに各システムの障害担当者が、基盤障害担当者とアプリケーション障害担当者に別れている場合、ディスクフルの障害は基盤障害担当者に通知され、ジョブＢの障害はアプリケーション障害担当者に通知されてしまい、それらの連携が益々困難となることも多い。

一方、本実施の形態では、第１サーバ１２で処理するジョブＢと、第２サーバ１４におけるリソースであるドライブＥとを自動的に紐づけ、障害発生時にはその紐づけをたどって自動的に障害原因を検出することができる。これにより、障害対応において頻繁に発生している上記のような問題を容易に克服することができる。

利用リソース情報とエラーログとから、異常終了したジョブが利用するリソースがエラーを発生させていたとしても、利用の仕方がそのエラーの影響の及ぶ範囲外であれば障害原因から除外することができる。図９はこのような点を考慮したうえで、各エラーに対して設定される障害原因である確率の例を示している。原因確率テーブル１２０は、エラー内容欄１２２、影響欄１２４、および確率欄１２６を含む。エラー内容欄１２２に記載された各エラー内容に対し、それによる影響が影響欄１２４に、そのエラーが原因である確率が確率欄１２６に記録される。原因確率テーブル１２０は、あらかじめジョブ情報記憶部４２に格納しておく。障害原因検出部３８は図８のＳ４２において障害原因となりうるエラーを検出したあと、原因確率テーブル１２０を参照して、検出したエラーの障害原因である確率を取得する。

例えばエラー内容が、あるドライブの「ディスクフル」の場合、その影響として当該ドライブへの書き込みが不可となる。このようなエラーが記録されているドライブへの書き込みを行っているジョブが異常終了した場合、障害原因検出部３８はまず影響欄１２４に記録されている影響と異常終了したジョブが当該ドライブに対し行っている処理内容とが合致することを確認し、確率欄１２６から当該エラーが原因である確率を「８０％」と特定する。

ジョブの処理内容は、利用リソース情報テーブル１００の備考欄１１０における記載を参照できる。あるいは原因確率テーブル１２０の影響欄１２４における記載と対応がとれるように、利用リソース情報テーブル１００に詳細な処理内容を記載する欄を別に設けてもよい。異常終了したジョブが、「ディスクフル」のエラーが発生しているドライブにアクセスするジョブであっても、図９に示すようにそのエラーが及ぼす影響が当該ドライブへの書き込み不可のみであるなら、当該ドライブを参照するのみのジョブの障害原因からは除外することができる。このように、利用リソース情報テーブル１００に、各ジョブのリソースに対する処理内容を詳細に記録するほど、障害原因の絞り込みの精度が向上する。

エラー内容が「ＬＡＮカード不調」の場合は、例えば当該ＬＡＮカードを備えたサーバ内の全リソースを、他のサーバから利用することができなくなる。また当該ＬＡＮカードを備えたサーバからデータベースサーバへのアクセスが不可となる。従って、異常終了したジョブがそのようなリソースへのアクセスを行っているか否かを利用リソース情報テーブル１００を参照して確認したうえ、行っている場合は当該エラーが原因である確率をそれぞれ「７０％」とする。エラー内容が「ネットワーク輻輳」の場合も同様に、当該エラーが原因である確率をそれぞれ「４０％」とする。

確率欄１２６に設定する、各エラーが原因である確率は、理論的に算出してもよいし、開発機でのテスト結果や実機での経験値を採用してもよい。図９において「ＬＡＮカード不調」のエラーより「ネットワーク輻輳」のエラーの方が原因となる確率が低いのは、ＴＣＰ／ＩＰの機能により通信が自動的にリトライされることにより、エラー状態の持続時間が短いためである。また図９に示した影響欄１２４の記載は、実際にはさらに詳細化し、処理によって細分化してもよい。例えば、利用リソース情報に各ジョブのＣＰＵ使用率、ハードディスクの利用率、データベースを参照するのみか更新するかを識別する情報、リソースを利用する頻度などを記録した場合、それらの値に応じて設定する確率を変化させるようにしてもよい。原因確率テーブル１２０は、まず各サーバに共通の汎用的なものを用意しておき、個々の運用形態によってユーザがカスタマイズできるようにしてもよい。

上述した、「各エラーが原因である確率」は、「そのエラーがジョブの処理に影響を及ぼす確率」と捉えることもできる。すなわち、確率欄１２６に記録された数値が高いエラーが起きた場合、そのエラーが後のジョブに異常をもたらす確率が高いと考えられる。この性質を利用して、障害原因検出部３８は、エラー内容欄１２２に記載されるようなエラーが発生する都度、原因確率テーブル１２０を参照し、対応する確率欄１２６に記録された数値が高ければ、関連するジョブを前もって停止させるようにしてもよい。具体的には、エラーが発生したリソースを利用するジョブを利用リソース情報テーブル１００から抽出し、抽出したジョブのいずれかが開始される予定であればジョブ処理部３６に通知しそれを停止させる。あるいは処理中のジョブを中断する。図８の例では、Ｓ３４において第２サーバ１４にディスクフルのエラーが発生しているため、第１サーバ１２のジョブＢをその段階で中断する。

以上述べた本実施の形態によれば、ユーザが登録したジョブフローから、ジョブ処理システムにおてい処理されるジョブとそのジョブが利用するリソースとを対応づけた利用リソース情報を自動で取得し記憶しておく。そしてジョブ処理時に、あるジョブに異常が発生した場合、利用リソース情報を参照して当該ジョブが利用しているリソース、および同リソースを利用している他のジョブなど、リソースに基づく関連性を取得し、関連性のあるリソースやジョブなどのログを参照することにより、障害原因を効率的に検出できる。

また利用リソース情報は、実際にジョブを処理した際の各ログのスナップショットなど内部情報の差分によっても取得する。このとき、データサイズ、タイムスタンプ、チェックサムなどファイルの付加情報も多角的に考慮することにより、各ジョブがどのリソースを利用してどのようなファイル操作を行ったのかを特定する。これにより、ジョブフローの登録フォーマットが異なる装置へ本実施の形態を容易に適用することができるとともに、ジョブのソースコードや設計図が失われている場合でもジョブフローの形式で処理内容を把握でき、当該ジョブ自体を異なる開発言語の別のシステムへ移植することも可能となる。例えば、ホストのＪＣＬ（Job Control Language）を、ＵＮＩＸ（登録商標）のシェルに自動変換することも可能となる。

障害原因の検出にあたっては、ジョブが異常となった時刻から、利用するリソースに基づきログを遡るように参照していくことにより、原因検出の効率性が増す。また、あらかじめエラーとして記録され得る要因ごとに、当該要因が障害原因となる確率を設定しておくことにより、例えば複数の要因が障害原因として検出された場合でもその確率をユーザに提示することができ、ユーザによる原因検証の作業、ひいては障害復旧の作業を効率化できる。

本実施の形態は、このように検出した障害原因、あるいはその候補を、明確に出力するため、障害原因究明のスキルを持たないオペレータも、その後の対処が容易となる。また別の部署、場所のサーバに因果関係があったとしても、当該関係を即座に把握することができる。結果として、分業が進み個々人で全貌を把握することが困難な昨今の巨大化したシステムにおいても、サーバ、部署、担当などの垣根を越えて自動で障害原因を検出することができ、復旧までの時間短縮、効率化を実現できる。

さらに本実施の形態は、スナップショットやログ取得など、情報処理装置やデータベースで一般的に提供されている機能をそのまま利用して実現することができるため、新たなハードウェアを導入するなどのコストを必要とせず、容易に実現することができる。

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

例えば、本実施の形態ではあるジョブが異常終了した場合に、利用リソース情報に基づき、そのジョブと他のリソースまたはジョブとの関連性を取得し、障害原因を検出したが、同様の処理により、ジョブ処理完了が遅延した際にその因果関係を検出することができる。例えば、あるジョブＡの完了が予定時刻より遅延した場合、ジョブＡより前に処理された別のジョブＢの処理が遅れ、結果としてジョブＡの開始時刻が遅延したことで完了時刻も遅延する場合がある。ジョブＡが、直接的、あるいは間接的にジョブＢの出力結果を受けてなされる処理である場合などがこれにあたる。

このような場合、ジョブＡとジョブＢとが異なるサーバで処理される場合などは特に、ジョブＡの完了遅延の原因をジョブＢに求めることは、一般的には困難である。障害原因の究明と同様に、ジョブ処理システムに含まれるサーバの数が増大するほど原因の究明が難しくなる。これはジョブ同士の依存関係や前後関係を、全サーバを網羅して把握することが困難になることに起因する。そこで本実施の形態と同様に、ジョブの処理の完了が遅延した際、利用リソース情報を参照して同一のリソースを利用しているジョブを検出することによりジョブ同士の関連性を見出す。

そして関連性のあるジョブのうち以前に処理されていてかつ処理完了が遅延しているジョブを各サーバのログから検出する。場合によってはこの操作を繰り返すことにより、利用リソースによって紐づけられたジョブを順次辿っていき、最終的に根本の原因となったジョブを特定する。あるいは逆に、処理完了が遅延した際、利用リソース情報を参照し、これから処理されるジョブのうち、遅延の影響を受けるであろうジョブを利用リソースに基づき抽出し、前もって警告するようにしてもよい。

これらの処理も、本実施の形態における各サーバの障害原因検出部３８が、各サーバのログやジョブ情報記憶部４２に記憶されたジョブの処理順序などを参照して該当ジョブを抽出していく。そして原因と考えられるジョブや、影響を受けるジョブの情報を出力部４０が出力する。出力手法はウェブ画面表示や電子メール送信など一般的な手法を用いることができる。

これによりユーザは、遅延の影響の及ぶ範囲が最小限となるようにジョブ処理の順序を最適化したり、影響を受けると予測されるジョブを手動で動作させたり、といった対策をとることができる。ジョブのバッチ処理は一般的に、営業開始時刻より前に完了していなければならないなど、全体的な完了時刻の厳守が求められる場合が多く、ジョブ処理遅延に対するこのような効果は特に有意義である。所定時刻に必ず完了していなければならないジョブをあらかじめ設定しておき、該当ジョブが遅延すると予測される場合は特に重大な警告としてその他のジョブと区別するように出力してもよい。

本実施の形態を適用できるシステムの構成例を示す図である。 本実施の形態における第１サーバの構成をより詳細に示す図である。 本実施の形態におけるジョブフローの登録からジョブの処理までの手順を示すフローチャートである。 本実施の形態において登録されるジョブフローの図の一例を示す図である。 本実施の形態において利用リソース情報取得部が作成する利用リソース情報のデータ構造の例を示す図である。 本実施の形態において利用リソース情報取得部が実際のジョブ処理によって処理内容を特定する処理手順を示すフローチャートである。 図４で示したジョブＡ処理時の３つのタイミングにおけるジョブログの例を示す図である。 本実施の形態における障害発生時の処理手順を示す図である。 本実施の形態において設定される各エラーが障害原因である確率を示すテーブルの例を示す図である。

符号の説明

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

Claims (9)

1. ジョブをバッチ処理するジョブ処理システムであって、
   登録されたジョブフローから、前記ジョブ処理システムにおいて処理されるジョブと、当該ジョブが利用するリソースに係る情報とを対応づけた利用リソース情報を取得する利用リソース情報取得部と、
   処理中のジョブのいずれかに異常が発生した際、前記利用リソース情報を参照して当該ジョブが利用するリソースを特定し、それに基づき前記ジョブ処理システムが記録するログ情報の少なくともいずれかを異常発生時から時間を遡って参照して、特定したリソースに関連するエラー情報を取得することにより、異常となった原因と推定される要因を検出する障害原因検出部と、
   前記障害原因検出部が検出した、原因と推定される要因に係る情報を出力する出力部と、
   を備えたことを特徴とするジョブ処理システム。
2. 前記障害原因検出部は、異常が発生したジョブが利用するリソースに関連するログを参照し、当該リソースのエラー情報を検出した場合に、当該リソースを、異常となった原因と推定される要因として検出することを特徴とする請求項１に記載のジョブ処理システム。
3. 前記障害原因検出部は、前記利用リソース情報を参照して、異常が発生したジョブが利用するリソースと同一のリソースを利用している他のジョブをさらに特定し、特定したジョブに関連するログを参照して当該ジョブのエラー情報を検出した場合に、前記同一のリソースを、異常となった原因と推定される要因として検出することを特徴とする請求項１に記載のジョブ処理システム。
4. 前記障害原因検出部は、前記利用リソース情報を参照して、同一のリソースを利用しているジョブの連鎖を異常が発生したジョブから辿り、その過程でジョブの連鎖を仲介するリソースに関連するログにエラー情報を検出した場合に、当該リソースを、異常となった原因と推定される要因として検出することを特徴とする請求項１に記載のジョブ処理システム。
5. ジョブに異常を発生させる原因となりうる要因と、当該要因が異常発生時にその原因となる確率とを対応づけた原因確率テーブルをあらじめ格納する記憶部をさらに備え、
   前記障害原因検出部は異常発生時に、前記原因確率テーブルをさらに参照して、検出した要因ごとに、当該要因が原因である確率を取得し、
   前記出力部は、前記要因と前記確率とを対応づけて出力することを特徴とする請求項１から４のいずれかに記載のジョブ処理システム。
6. 前記利用リソース情報取得部は、各ジョブと、当該ジョブが利用するリソースに対する処理内容を前記利用リソース情報としてさらに対応づけ、
   前記原因確率テーブルは、前記要因としてリソースのエラーと、前記原因となる確率とを、当該リソースに対するジョブの処理内容ごとに対応づけ、
   前記障害原因検出部は、前記利用リソース情報を参照して、異常が発生したジョブが利用するリソースに対する処理内容をさらに特定し、それに基づき前記原因確率テーブルをさらに参照して、検出した要因が原因である確率を前記リソースに対する処理内容に応じて取得することを特徴とする請求項５に記載のジョブ処理システム。
7. ジョブをバッチ処理するジョブ処理システムであって、
   登録されたジョブフローから、前記ジョブ処理システムにおいて処理されるジョブと、当該ジョブが利用するリソースに係る情報とを対応づけた利用リソース情報を取得する利用リソース情報取得部と、
   処理中のジョブのいずれかに異常が発生した際、前記利用リソース情報を参照して、当該ジョブが利用するリソースと関連のあるジョブを特定し、それに基づきあらかじめ登録されたジョブの処理順序情報を参照することにより、以後に処理が予定されているジョブのうち前記関連のあるジョブを、影響の及ぶジョブとして検出する障害影響検出部と、
   前記障害影響検出部が検出した前記影響の及ぶジョブに係る情報を出力する出力部と、
   を備えたことを特徴とするジョブ処理システム。
8. 前記障害影響検出部は、検出した前記影響の及ぶジョブの処理を中止させることを特徴とする請求項７に記載のジョブ処理システム。
9. ジョブ処理システムにおいてバッチ処理されるジョブと各ジョブが利用するリソースとを対応づけた利用リソース情報を取得するステップと、
   処理中のジョブのいずれかに異常が発生した際、前記利用リソース情報を参照して当該ジョブが利用するリソースを特定し、それに基づき前記ジョブ処理システムが記録するログ情報の少なくともいずれかを異常発生時から時間を遡って参照して、特定したリソースに関連するエラー情報を取得することにより、異常となった原因と推定される要因を検出するステップと、
   原因と推定される要因に係る情報を出力するステップと、
   を含むことを特徴とするジョブ管理方法。

Images