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

Abstract

【課題】時限つきジョブを含むジョブのバッチ処理時に障害が発生すると復旧が困難である。
【解決手段】ジョブのバッチ処理中に障害により処理が停止し、以後処理が予定されていたジョブに時限つきジョブがあった場合（Ｓ１０、Ｓ１２）、時限つきジョブの完了時限から逆算して障害ジョブの再実行を開始する時限を算出する（Ｓ１６）。残り時間がしきい値以上であれば障害ジョブの復旧および再実行を試みる処理を開始する（Ｓ２０のＹ、Ｓ２２）。しきい値未満であれば（Ｓ２０のＮ）、以後に処理が予定されていたジョブのうち障害ジョブを前提としないジョブを検出し、当該ジョブまで処理をスキップする（Ｓ２８、Ｓ３０のＹ、Ｓ３２）。障害ジョブを前提としないジョブがない場合は、障害ジョブに替わる簡易的なジョブを臨時ジョブとして作成し、処理を続行する（Ｓ３０のＮ、Ｓ３４）。
【選択図】図６

Description

本発明は情報処理技術に関し、特にユーザの登録に従いバッチ処理を行うジョブ処理システムおよびジョブ処理方法に関する。

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

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

営業時間外の夜間にジョブをバッチ処理させるようなシステムにおいては、営業開始時間までに終了していないと営業開始に支障をきたすジョブが含まれることがある。このような場合、バッチ処理中に何らかの障害が発生し、そのジョブの完了が予定外に遅延したり、ジョブ自体が実行されるに至らなかったりすると、営業上、大きな問題となってしまう。一方で、バッチ処理はその性質上、監視体制が限定的であるため、ひとたび障害が発生するとその復旧は困難な作業となることが多い。

上記のような時限つきジョブを含むジョブをバッチ処理するようなシステムでは、障害の復旧に時間的な制約があるため、短時間で障害原因を分析できる高スキルを有する人員を確保したり、人員配置に余裕をもたせたり、緊急用の別のジョブを何重にも用意したり、といったことを障害の発生に備えて行う必要があった。このことは結果として、人件費、システム開発費、メンテナンス費などのコストの増大を招く。さらに、実際に障害が発生した場合は、障害原因の究明、障害の克服、障害に応じた緊急用ジョブの作成、実行などを短時間で行わなければならず、システムの規模が大きくなるほど、システム運用者、開発者などの人的負担が大きくなっていた。

本発明はこうした状況に鑑みてなされたものであり、その目的は、ジョブのバッチ処理において障害が発生した際の対応を支援することのできるジョブ処理技術を提供することにある。

本発明のある態様は、ジョブ処理システムに関する。このジョブ処理システムは、処理内容が登録されたジョブを登録された処理順でバッチ処理するジョブ処理システムであって、登録された各ジョブの処理内容から、各ジョブが利用するリソースおよびファイル操作に係る情報を抽出して記憶する利用リソース情報取得部と、バッチ処理時に障害が発生した際、以後に処理予定のジョブのうち、障害が発生したジョブの出力結果を利用しないジョブを、登録された処理順と各ジョブが利用するリソースおよびファイル操作に係る情報から検出し、検出したジョブから処理を再開することを特徴とする。

本発明の別の態様は、ジョブ処理方法に関する。このジョブ処理方法は、ユーザの設定に従いジョブをバッチ処理するステップと、設定された各ジョブの処理内容から、各ジョブが利用するリソースおよびファイル操作に係る情報を抽出しメモリに格納するステップと、バッチ処理時に障害が発生した際、以後に処理予定のジョブのうち、障害が発生したジョブの出力結果を利用しないジョブを、登録された処理順と各ジョブが利用するリソースおよびファイル操作に係る情報から検出し、検出したジョブから処理を再開するステップと、を含むことを特徴とする。

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

本発明によれば、バッチ処理時の障害発生に対する人的負担を軽減することができる。

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

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

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

図２はジョブ処理システム１０でバッチ処理されるジョブの処理順の例を模式的に示している。ジョブの処理順は上述のとおりユーザが設定し、ジョブ処理システム１０が例えば図２に示すようなジョブネット図の形式で記憶する。同図では、各矩形が一つのジョブを表し、矢印によってその処理順を示している。すなわち同図のジョブネット図９０の例では、「ジョブＡ」、「ジョブＢ」をこの順で処理したあと、「ジョブＣ」と「ジョブＥ」を並列で処理し、「ジョブＣ」の後に「ジョブＤ」を、「ジョブＥ」の後に「ジョブＦ」、「ジョブＺ」をそれぞれ処理するように設定されている。

ユーザは各ジョブのジョブフローを、ジョブネット図９０とは別に設定する。このときジョブ処理システム１０は、例えばジョブネット図を参照しながら各ジョブのジョブフローを呼び出すことにより、バッチ処理を進捗させる。以後、図２に示したジョブネット図９０に含まれるジョブのうち、「ジョブＺ」が時限つきジョブである場合を考える。時限つきジョブとは例えば、ある時刻までに完了していないと、営業開始やオンラインサービス開始に支障をきたすジョブをいう。このようなジョブが含まれるジョブのバッチ処理において、例えば「ジョブＢ」の処理中に障害が発生し処理が停止してしまった場合などは、障害復旧のための作業時間に応じて「ジョブＺ」の処理開始時刻が遅延することになる。

このような場合、一般的には運用担当者、障害担当者、システム開発担当者などが緊急対応し、「ジョブＺ」を時限までに終了させようと策を講じる必要があるが、場合によっては間に合わないというリスクを孕んだ作業となる。システムの規模が大きくなるほどこのリスクも大きくなる。例えば第１サーバ１２と第２サーバ１４とが別の部門で管理されていたり、異なる場所に備えられていたりすると、第１サーバ１２が処理していたジョブの異常終了の原因が第２サーバ１４の内部にあったとしてもそれを見いだすことは容易でない。また、障害が発生したジョブが第１サーバ１２で処理されていて、時限つきジョブが第２サーバ１４で処理予定であった場合なども、時限つきジョブの存在を考慮した障害対応を行うことが難しくなる。

そこで本実施の形態におけるジョブ処理システム１０は、障害が発生した際、（１）時限つきジョブの処理予定をシステム内の全サーバから検出し、（２）検出した時限つきジョブを時限までに完了させるために障害対応に許容される時間を算出する。そして、当該許容時間と、障害の内容、障害が発生したジョブから時限つきジョブまでに処理する予定のジョブ同士の関連性とを考慮して、最善の対策を決定し、場合によっては自律的に対応処理を行う。具体的には、（１）障害が発生したジョブの再実行、（２）ジョブのスキップ処理、（３）臨時ジョブ処理、のいずれかを行う。

このような処理をジョブ処理システム１０に含まれる全サーバを対象として効率的に行うために、本実施の形態では各サーバが利用するリソースに着目する。処理内容の見地からはジョブ同士に直接的なつながりはなくとも、障害発生の見地からは偶発的に関連性が生じることも多い。そのようなジョブの障害上の関連性は、ジョブの処理順序や処理するデータ量など様々な要因で発生しうるため、あらかじめ予測することが難しい。また障害が発生した後でも対象となるサーバやジョブのログのみでは関連性を見出しにくい。そこで本実施の形態では、各ジョブが利用するリソースを抽出して利用リソース情報を生成することにより、リソースを媒介としてジョブ同士を紐づけ、障害上の関連性を見出す。また逆に、利用リソース情報によって、ジョブネット図では前後関係があっても、処理内容として関連性のないジョブを検出する。

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

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

ジョブ登録部３２は、ジョブフローやジョブネット図など、ジョブの処理に必要な情報をユーザが登録するためのインターフェースである。ジョブ登録部３２は、登録画面を表示した表示装置と、キーボード、ポインティングデバイスなど登録画面に対して入力を行う入力装置との組み合わせなどでよく、ジョブを処理する一般的なシステムで用いられる装置を適用することができる。ジョブフロー登録時、登録画面には、利用リソース情報取得部３４が利用リソース情報のテーブルを作成するうえで必要となる項目を表示し、ジョブごとに、各項目についてユーザが入力を行えるようにする。さらに、ジョブネット図を登録する際などに、時限つきジョブがあればその時限を設定できるようにする。登録された情報はジョブ情報記憶部４２に格納する。

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

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

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

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

障害対応部３９は上述したように、障害発生時に、時限つきジョブが以後の処理予定に含まれているか否かを確認し、含まれている場合に障害対応にかけることのできる許容時間を算出する。そして許容時間、障害の状況、以後に処理が予定されているジョブの特徴などを評価して、最善の対応策を決定する。決定した対応策は必要に応じてユーザに確認を促したうえで実行する。

出力部４０は、ジョブ処理に障害が発生した場合に、障害原因検出部３８が検出した障害原因に係る情報や、障害対応部３９が算出した障害対応に対する許容時間などを出力してユーザに通知する。また決定した対応策の実行可否の確認をユーザに促す。出力部４０は一般的な表示装置やプリンタなどの出力装置でもよいし、電子メールやファクシミリなどの通信機器をさらに含んでもよい。さらに、対応策の実行可否を選択するユーザからの入力を受け付けるキーボード、マウス、ボタンなどの入力装置を含んでもよい。

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

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

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

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

図５は利用リソース情報取得部３４が作成する利用リソース情報のデータ構造の例を示している。利用リソース情報テーブル１００において、１つのジョブに含まれる所定単位の処理が１行分のデータとなる。図５の例では、リソースへのアクセス、例えばファイルの読み出し（参照）や書き込み（更新）を１つの単位として記載している。利用リソース情報テーブル１００は、ジョブ名欄１０２、ステップ名欄１０３、利用サーバ欄１０４、利用リソース種類欄１０６、リソース詳細欄１０８、処理内容欄１０９、参照先ファイル欄１１０、更新先ファイル欄１１１、時限つきジョブ欄１１２、前提ジョブ欄１１４、単純再実行欄１１６を含む。前述の通り利用リソース情報取得部３４は、新たなジョブフローが登録されるたびに、当該ジョブフローから必要な情報を抽出し、利用リソース情報テーブル１００にエントリを追加していく。

ジョブ名欄１０２には、ユーザが登録を行ったジョブの名前を記載する。ステップ名欄１０３には、ジョブフローを複数のステップに細分化して登録できるようにした場合に、各ステップの名前を記載する。例えば「第１ステップ」、「第２ステップ」・・・といった名前をつけることで、「第１」、「第２」・・・の順に処理を行うようにあらかじめ規則づけておく。

利用サーバ欄１０４にはそれぞれのジョブが利用するリソースが属するサーバの名前を記載する。利用リソース種類欄１０６には利用するリソースの種類、例えばハードディスク、データベース、ＬＡＮカードなどを識別する情報を記載する。リソース詳細欄１０８には、具体的なリソースの識別情報を記載する。処理内容欄１０９には、リソース詳細欄１０８に記載したリソースを利用して行われる具体的な処理内容を記載する。ここでは前述のとおり、リソースへのアクセスごとに行を設けているため、「参照」や「更新」が記載されている。ここで「更新」とは新たなファイルの作成処理も含む。また、参照と更新からなる１対の処理が、バックアップなどを目的とする、ファイルのコピーである場合は、それらの処理を他と区別できるように記載する。図５の例では、「参照（コピー）」、「更新（コピー）」なる表記がそれにあたる。処理内容欄１０９にはその他、リソースへのアクセス内容を表す「転送」、「出力」などを適宜記載する。

参照先ファイル欄１１０には、ファイルの参照処理において参照されるファイルの名前を記載する。更新先ファイル欄１１１には、ファイルの更新処理よって更新、または新たに作成されるファイルの名前を記載する。さらに各ジョブの特徴として、時限つきジョブ欄１１２にはジョブが時限つきジョブである場合にその時限を、前提ジョブ欄１１４には前提ジョブのジョブ名を、単純再実行欄１１６には単純再実行が可能か否かを記載する。

ここで「前提ジョブ」とは、ジョブの処理開始の前提となるジョブのことである。先行する一のジョブの出力結果を後続の一のジョブが何らかの形で利用するような場合、その先行ジョブは後続ジョブの前提ジョブとなる。前提ジョブは例えば、ジョブネット図において処理順が前のジョブのうち、同一のファイルを操作するジョブを抽出することによって得られる。あるいは、ジョブネット図の登録時などにユーザによって設定できるようにしてもよい。

また、「単純再実行が可能」なジョブとは、何度実行しても処理結果が同じとなるジョブのことである。このようなジョブが障害ジョブとなった場合は、障害原因が復旧したあと、単に再実行すればその処理結果は通常処理時と同じ状態となる。例えば図４において示したジョブフローの例のうち、第１ステップ５０のみからなるジョブは単純再実行が可能なジョブである。ドライブＤに格納されたファイル「ａａａ．ｔｘｔ」をファイル「ａａａ．ｔｘｔ．ｙｙｙｙｍｍｄｄ」として保存する処理が障害により途中で停止したとしても、障害原因を取り除いて最初から実行しなおせば、最終的なファイル「ａａａ．ｔｘｔ．ｙｙｙｙｍｍｄｄ」の内容は障害が発生しなかった場合と同一になるためである。

一方、図４に示した第１ステップ５０および第２ステップ５２からなるジョブの場合、ファイル「ａａａ．ｔｘｔ」は参照先ファイルであると同時に更新先のファイルでもある。そのため、第２ステップ５２においてファイル「ａａａ．ｔｘｔ」に途中まで書き込みがなされた状態で、障害により処理が停止した場合、障害克服後、単純に再実行したのみでは、書きかけのファイル「ａａａ．ｔｘｔ」を第１ステップ５０で読み出すことになり、中間データであるファイル「ａａａ．ｔｘｔ．ｙｙｙｙｍｍｄｄ」および最終的なファイル「ａａａ．ｔｘｔ」の内容が、障害が発生しなかった場合と異なってしまう。このようなジョブは単純再実行が不可である。

利用リソース情報取得部３４は、登録された各ジョブフローにおいて、例えば同一のファイルが参照先と更新先に含まれる場合、そのジョブは単純再実行が不可と判断し、単純再実行欄１１６にその旨の情報を記載する。あるいは単純再実行の可否をジョブフロー登録時にユーザに登録させるようにしてもよい。時限つきジョブ欄１１２に記載する時限は、ジョブ登録部３２に対しユーザが行った登録情報をそのまま記載できる。

図５に示した利用リソース情報テーブル１００のうち「ジョブＢ」なるジョブは、図４で示したジョブに対応する。すなわち、第１ステップ５０では第１サーバ１２のハードディスク１３のドライブＤにアクセスし、入出金明細ファイル「ａａａ．ｔｘｔ」のバックアップファイル「ａａａ．ｔｘｔ．ｙｙｙｙｍｍｄｄ」を作成しているため、図５に示した利用リソース情報テーブル１００の４、５行目において、ステップ名欄１０３には「第１ステップ」、利用サーバ欄１０４には「第１サーバ」、利用リソース種類欄１０６にはハードディスクを示す「ＤＩＳＫ」、リソース詳細欄１０８には「ドライブＤ」、処理内容欄１０９には「参照（コピー）」および「更新（コピー）」、参照先ファイル欄１１０には「ａａａ．ｔｘｔ」、更新先ファイル欄１１１には「ａａａ．ｔｘｔ．ｙｙｙｙｍｍｄｄ」と記載されている。

また「ジョブＢ」は、第２ステップ５２において、バックアップファイル「ａａａ．ｔｘｔ．ｙｙｙｙｍｍｄｄ」と、第１サーバ１２に接続したデータベース２０を参照して新たなファイル「ａａａ．ｔｘｔ」を作成しているため、利用リソース情報テーブル１００の６、７、８行目において、ステップ名欄１０３には「第２ステップ」、利用サーバ欄１０４には「第１サーバ」、利用リソース種類欄１０６にはハードディスクを示す「ＤＩＳＫ」、およびデータベースへのアクセスを示す「ＤＢＭＳ」、リソース詳細欄１０８には「ドライブＤ」および「データベース」、処理内容欄１０９には「参照」および「更新」、参照先ファイル欄１１０には「ａａａ．ｔｘｔ．ｙｙｙｙｍｍｄｄ」および参照するデータベース名である「会計ＤＢ」、更新先ファイル欄１１１には「ａａａ．ｔｘｔ」と記載されている。

さらに「ジョブＢ」は時限つきジョブではないとして、時限つきジョブ欄１１２は無記入とし、前提ジョブが「ジョブＡ」であるとして前提ジョブ欄１１４には「ジョブＡ」と記載されている。そして上述のとおり、単純再実行欄１１６には単純再実行が不可である旨の「不可」が記載されている。「ジョブＡ」、「ジョブＺ」なども同様に記載され、特に「ジョブＺ」は時限つきジョブであるとして、その時限が「４：００ＡＭ」、すなわち午前４時と記載されている。

利用リソース情報取得部３４は、図２で示したようなジョブネット図に登録されている全ジョブについて同様の情報を抽出し、利用リソース情報テーブル１００を完成させる。なお、利用リソース情報のデータ構造は図５に示したものに限らない。例えばＣＰＵ使用率、ハードディスクの利用率、データベースを参照するのみか更新するかを識別する情報などを記録してもよい。ＣＰＵ使用率やハードディスクの利用率など、ジョブフローから特定が困難なパラメータは、開発機や実機において実際にジョブを処理した際の各パラメータの変化量を取得することによって得ることができる。利用リソース情報に含まれる情報を詳細にするほど、原因検出の精度や障害対応の効率が向上する。また、各欄の記載手法は図５に示したものに限らず、内容を識別できればよい。

図６は、ジョブ処理システム１０において障害が発生した際、主に障害原因検出部３８、障害対応部３９、出力部４０が行う障害対応処理の手順を示している。まず、例えば図２のジョブネット図９０のようにジョブのバッチ処理が行われている際、「ジョブＢ」の実行中に障害が発生し、処理が停止したとする（Ｓ１０）。このとき障害対応部３９は、以後に処理が予定されているジョブの中に時限つきジョブが含まれているか否かを、ジョブ情報記憶部４２に格納した、ジョブネット図９０および利用リソース情報テーブル１００の時限つきジョブ欄１１２から判定する（Ｓ１２）。

時限つきジョブが存在する場合は（Ｓ１２のＹ）、当該ジョブを時限以前に完了させるために遅くとも障害が発生したジョブ（以後、「障害ジョブ」と呼ぶ）を再実行させなければならない時刻、すなわち再実行の開始時限を算出する（Ｓ１６）。開始時限を算出するためにジョブ処理部３６は、ジョブをバッチ処理する都度、各ジョブの平均処理時間を算出し、ジョブ情報記憶部４２に格納するようにしてもよい。そして時限つきジョブの完了時限から、障害が発生したジョブを含む、以後に処理が予定されていたジョブの平均処理時間の和を差し引いた時刻が、障害ジョブ再実行の開始時限となる。

図２で示したジョブネット図９０の場合、「ジョブＢ」、「ジョブＥ」、「ジョブＦ」、「ジョブＺ」の各平均処理時間の和を、時限つきジョブである「ジョブＺ」の完了時限から差し引く。結果的に現在時刻から障害ジョブ再実行の開始時限までの時間が、障害復旧にかけることのできる許容時間となる。

各ジョブの平均処理時間は、並列で同時に処理されているジョブの数やその処理内容、日程等の条件によって変動することが考えられる。例えば入出金の管理システムなどでは、経理上の締め日や年度末にはデータが増加し平均処理時間が増加することが考えられる。また、並列処理されているジョブの数が増加するほど、リソースへのアクセスの排他制御などによって平均処理時間が増加することが考えられる。したがって、システム固有の運用形態によってあらかじめ設定した状況別に平均処理時間を記録するようにしてもよい。例えば一ヶ月で平均処理時間が周期的に変動するようなシステムにおいては、各月の同日の処理時間を平均して記録する。この場合、障害が発生した日と同日の平均処理時間を用いて障害ジョブ再実行の開始時限を算出する。

平均処理時間が周期的な変動をしない場合などは特定の状況を設定せず、バッチ処理の進捗速度のパターンなどで平均処理時間を集計するようにしてもよい。例えばジョブごとに処理時間のしきい値を設定しておき、全てのジョブ処理時間が当該しきい値を超えているパターンや当該しきい値を下回っているパターンなどごとに平均処理時間を集計する。そして障害が発生した日の、障害が発生するまでに処理されていたジョブの処理時間から、同じ処理順、かつ同程度の処理時間でバッチ処理が進捗している過去のパターンを抽出し、その平均処理時間を利用するようにしてもよい。

障害ジョブ再実行の開始時限を算出したら、その情報を含む、障害に係る情報を出力部４０などによりユーザに通知する（Ｓ１８）。障害に係る情報には、障害が発生したジョブの内容やエラーログ、あるいは後述する、障害原因と考えられるリソースの障害原因たる確率などの情報を含めてもよい。

次に、現在時刻と障害ジョブ再実行の開始時限との差分から得られる残り時間と、あらかじめ定めたしきい値とを比較する（Ｓ２０）。ここでしきい値は、障害原因の特定および当障害の復旧作業を行ったうえで障害ジョブの再実行を開始するのに最低限必要と考えられる時間をそれまでの実績などからあらかじめ定めておくものであり、一般的には１時間程度の時間である。残り時間がしきい値以上であれば（Ｓ２０のＹ）、まだ復旧作業に時間的余裕があると判断し、障害ジョブの再実行を試みる処理を行う（Ｓ２２）。ここでは障害原因を特定し、復旧させたうえで障害ジョブを再実行させる。この処理も本実施の形態ではその一部を障害対応部３９が行う。詳細は後に述べる。

障害の復旧、障害ジョブの再実行が実現していないうちは（Ｓ２４のＮ）、常時あるいは所定の時間間隔で再実行開始時限までの残り時間を監視し、ユーザへの通知を更新するとともに残り時間としきい値とを比較する（Ｓ１８、Ｓ２０）。残り時間が依然、しきい値以上であれば、Ｓ２２の障害ジョブの再実行の試みを継続する。復旧作業の結果、障害ジョブが再実行できたら（Ｓ２４のＹ）、障害ジョブ以後、通常のバッチ処理を進捗させる（Ｓ２６）。一方、Ｓ１２において以後に予定されているジョブの中に時限つきジョブがない場合は（Ｓ１２のＮ）、Ｓ２２と同様、障害ジョブの再実行を試みる（Ｓ１４）。この場合、残り時間の監視等は行わない。ただし、障害に係る情報のユーザへの通知は適宜行ってよい。この場合も障害ジョブの再実行後は通常のバッチ処理へ移行する（Ｓ２６）。

Ｓ２０において残り時間がしきい値未満となり、復旧作業に時間的余裕がないと判断した場合は（Ｓ２０のＮ）、まず、スキップ処理の可否を判定する（Ｓ２８）。ここでスキップ処理とは、以後に処理が予定されていたジョブのうち、障害ジョブを直接的または間接的に前提とするジョブの処理を省略し、障害ジョブを前提とせず、障害ジョブが完了していなくても正常に処理が可能なジョブからバッチ処理を再開することをいう。

図２に示したジョブネット図９０において、「ジョブＢ」を障害ジョブとすると、時限つきジョブである「ジョブＺ」の前提ジョブが「ジョブＦ」であり、「ジョブＦ」の前提ジョブがない場合、「ジョブＢ」、「ジョブＥ」の処理を省略して「ジョブＦ」の処理を開始するスキップ処理が可能、と判定する。「ジョブＦ」の前提ジョブが「ジョブＡ」であっても同様である。スキップ処理により、最低限「ジョブＺ」の処理を時限までに完了させることが可能となる。判定手法の詳細は後述する。

スキップ処理が可能と判定されたら（Ｓ３０のＹ）、スキップ処理を開始する（Ｓ３２）。この際、障害対応部３９は、処理を省略するジョブを除いた緊急のジョブネット図を作成し、ジョブ処理部３６に通知することによりその処理を実施させる。なおＳ３２のスキップ処理の開始前に、スキップ処理を行う旨の警告をユーザに対し出力し、ユーザが続行を指示したときにのみ実際のスキップ処理を行うようにしてもよい。

全てのジョブが直接的あるいは間接的に障害ジョブを前提としていて、スキップ処理が不可能であると判定されたら（Ｓ３０のＮ）、臨時ジョブ処理を行う（Ｓ３４）。ここで臨時ジョブ処理とは、バッチ処理を進捗させるために障害ジョブが最低限すべき簡易的な処理のみを行う臨時ジョブを、障害ジョブの代替ジョブとしたうえでバッチ処理を続行する処理である。例えば図２に示したジョブネット図９０において、「ジョブＥ」が「ジョブＢ」の出力結果であるファイルのファイル名をヘッダとするファイルを出力する処理であった場合、「ジョブＥ」は、最低限「ジョブＢ」が出力するファイルのファイル名があれば処理を開始することができる。そこで障害ジョブである「ジョブＢ」に替わり、ファイル名のみを有する空のファイルを出力する臨時ジョブを作成し、ジョブネット図上で「ジョブＢ」と入れ替える。

これにより「ジョブＥ」は、臨時ジョブが出力したファイルのファイル名を用いて処理を開始することができ、結果として「ジョブＺ」まで処理が進捗することになる。このような動作は、各出力結果のデータ内容より、時限までに「ジョブＺ」の処理を完了させることを優先する場合の応急処置となる。臨時ジョブが行う処理内容は、障害と推定されるリソースによっては空ファイルでなくてもよく、障害原因のリソースごとに異なる臨時ジョブを作成するようにしてもよい。障害対応部３９は、利用リソース情報を参照して臨時ジョブを作成しジョブネット図を更新することにより、ジョブ処理部３６に処理させる。詳細は後述する。

なおＳ３４の臨時ジョブ処理の前、あるいは臨時ジョブ作成後に、臨時ジョブ処理を行う旨の警告をユーザに対し出力し、ユーザが続行を指示したときにのみ実際の臨時ジョブ処理を行うようにしてもよい。

図７は図６のＳ２２において障害ジョブの再実行を試みる処理手順を示している。まず障害対応部３９は、利用リソース情報の単純再実行欄１１６を参照し、障害ジョブの単純再実行が可能であるか否かを判定する（Ｓ４０、Ｓ４２）。再実行が不可能な場合は（Ｓ４２のＮ）、障害ジョブの戻し処理を行う（Ｓ４４）。障害ジョブの戻し処理とは、途中で停止してしまったジョブが操作していたファイルを元の状態に戻す処理をいう。図８は図４で示したジョブフローを有するジョブの戻し処理のジョブフローを示している。

上述のとおり、図４に示したジョブにおいて、ファイル「ａａａ．ｔｘｔ」が書きかけの状態で停止すると、次に再実行したときに当該ファイルが読み出され、最終結果が変化してしまう。したがって戻し処理においては図８に示すとおり、ファイル「ａａａ．ｔｘｔ」のバックアップファイルであるファイル「ａａａ．ｔｘｔ．ｙｙｙｙｍｍｄｄ」をファイル「ａａａ．ｔｘｔ」として保存することにより、ファイル「ａａａ．ｔｘｔ」の内容を元に戻す。

障害対応部３９は、利用リソース情報テーブルから、戻し処理を行うシェル６０を作成して戻し処理のジョブフロー５８を生成する。図５に示した利用リソース情報テーブル１００の場合、ファイル「ａａａ．ｔｘｔ」が参照先ファイルであるとともに、単なるコピーではない更新処理がなされていることを、「ジョブＢ］の参照先ファイル欄１１０および更新先ファイル欄１１１から検出する。次に当該ファイルのコピーがファイル「ａａａ．ｔｘｔ．ｙｙｙｙｍｍｄｄ」として保存されていることを処理内容欄１０９の「参照（コピー）」、「更新（コピー）」の対から検出する。それらの情報から、ファイル「ａａａ．ｔｘｔ．ｙｙｙｙｍｍｄｄ」をファイル「ａａａ．ｔｘｔ」として保存するためのシェル６０、およびジョブフロー５８を作成する。

上述の、参照先ファイルであると同時に単なるコピーではない更新処理がなされているファイルの検出、そのファイルのコピー先ファイルの検出、コピー先ファイルから元のファイルへのコピーを行う戻し処理の実行、といった基本的な手順は、実際にはあらかじめプログラムなどで定義しておいてよい。そして障害発生時は、利用リソース情報テーブル１００を参照して必要なファイル名を抽出し、定義しておいた手順に代入していくことにより具体的な処理内容を決定してよい。あるいは、元のジョブフローにおいてコピーされているファイルは戻し処理が必要なファイルである可能性が高いため、常にコピー先ファイルから元のファイルへの戻し処理を行うように定義しておいてもよい。または、戻し処理が必要なファイルをユーザが指定するようにしてもよい。データベースの場合も同様に、バックアップのデータベースがあった場合に、バックアップ先から元のデータベースへ戻すように定義しておく。

そして作成したジョブフロー５８をジョブ情報記憶部４２に保存したうえでジョブ処理部３６にその旨の情報を通知することにより、ジョブ処理部３６がジョブフロー５８を参照して戻し処理を実行する。

図７に戻り、障害ジョブが単純再実行可能であった場合（Ｓ４２のＹ）、あるいは障害ジョブの戻し処理を実行した場合（Ｓ４４）、障害原因検出部３８は、障害原因候補を抽出し、それが障害原因である確率を取得する（Ｓ４６）。まず障害原因候補の抽出は、障害ジョブが利用するリソースを利用リソース情報から取得し、当該リソースのエラーログを参照することによって行うことができる。ここで各リソースのエラーログは、第１サーバ１２〜第４サーバ１８で常時共有できるようにそれらのシステムがアクセス可能なメモリ（図示せず）などに格納するようにしてもよいし、必要に応じて他のサーバに要求信号を送信することにより取得してもよい。障害ジョブの利用リソースにエラーが記録されていれば、当該リソースが障害原因であると推定できる。

リソースによっては、エラーが記録されていたとしてもジョブの処理にはあまり影響しないこともあり得る。またジョブの利用の仕方がそのエラーの影響の及ぶ範囲外であれば障害原因とは考えにくい。このような点を考慮し、各リソースのエラーに対して障害原因である確率をあらかじめ設定することにより、抽出した候補が障害原因である確率を取得する。原因確率の設定例は後に述べる。

障害原因検出部３８は、Ｓ４６で抽出した障害原因候補のリソースのうち、真の障害原因と推定できるリソースがあるか否かを判定する（Ｓ４８）。判定は、各候補が障害原因となり得る確率を、あらかじめ定めたしきい値と比較することにより行う。例えばしきい値８０％を超える障害原因候補のリソースがある場合は、当該リソースを障害原因と推定する。障害原因と推定できるリソースがある場合は（Ｓ４８のＹ）、ユーザにその情報を出力することにより、ユーザは当該リソースに絞って障害の復旧処理を行う事ができる（Ｓ５０）。

ユーザによる復旧処理が完了したら、ユーザが所定の入力を第１サーバ１２などに対し行うことにより、障害対応部３９がそれを検知し、ジョブ処理部３６に障害ジョブの再実行を許可して、ジョブ処理部３６が再実行を行う（Ｓ５２）。この際、障害対応部３９は、Ｓ４２において障害ジョブが単純再実行可能なジョブであったか、あるいはＳ４４において戻し処理を前もって行っていること、Ｓ４８において障害原因と推定できるリソースがあったこと、の２点を根拠に、障害ジョブの自動再実行を許可する。すなわちユーザは、ジョブ処理システム１０から提示された障害リソースを復旧させ、復旧した旨の入力を行うのみでよく、その後の再実行可否判断は障害対応部３９が行う。

障害原因がネットワークの輻輳であった場合などは、一般的に行われる通信の再トライのみでユーザの関与なく障害が復旧する場合もある。したがって障害対応部３９はユーザからの障害が復旧した旨の入力を待つばかりでなく、定期的に障害原因と推定されるリソースの状態をチェックするようにしてもよい。この場合、ジョブ処理システム１０内で自律的に障害が復旧すれば、完全にユーザの関与なくジョブ処理の再実行が可能となる。なお障害対応部３９は、障害ジョブの再実行可の判断をした後、ユーザにその旨の通知を行い、ユーザが最終的な可否判断を行うようにしてもよい。

Ｓ４８において障害原因と推定できるリソースがなかった場合は（Ｓ４８のＮ）、Ｓ４６で抽出した障害原因候補やその原因確率などの情報を出力することによりユーザに通知し、ユーザは当該情報に基づき障害原因の究明および復旧処理を行う（Ｓ５４）。この場合は、復旧処理をしながら障害ジョブを実行させ、復旧したか否かの確認を行うなどの処理が必要なため、ユーザが自ら障害ジョブを再実行させる（Ｓ５６）。ただし、Ｓ５４において明らかな障害原因が特定できた場合など、場合によっては障害対応部３９が自動で再実行するＳ５２の処理に移行するようにしてもよい。

図９は図７のＳ４６において参照する、各エラーが障害原因となりうる確率の設定例を示している。原因確率テーブル１２０は、エラー内容欄１２２、影響欄１２４、および確率欄１２６を含む。エラー内容欄１２２に記載された各エラー内容に対し、それによる影響が影響欄１２４に、そのエラーが原因である確率が確率欄１２６に記録される。原因確率テーブル１２０は、あらかじめジョブ情報記憶部４２に格納しておく。障害原因検出部３８は障害ジョブの利用リソースなどにおいて障害原因となりうるエラーを検出したあと、原因確率テーブル１２０を参照して、当該エラーが障害原因となり得る確率を取得する。

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

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

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

確率欄１２６に設定する、各エラーが原因である確率は、理論的に算出してもよいし、開発機でのテスト結果や実機での経験値を採用してもよい。図９において「ＬＡＮカード不調」のエラーより「ネットワーク輻輳」のエラーの方が原因となる確率が低いのは、ＴＣＰ／ＩＰの機能により通信確立が自動的にリトライされることにより、エラー状態の持続時間が短いためである。また図９に示した影響欄１２４の記載は、実際にはさらに詳細化し、処理によって細分化してもよい。原因確率テーブル１２０は、まず各サーバに共通の汎用的なものを用意しておき、個々の運用形態によってユーザがカスタマイズできるようにしてもよい。

図１０は、図６のＳ２８においてスキップ処理の可否を判定する手順を示している。まず障害対応部３９は、利用リソース情報テーブル１００の前提ジョブ欄１１４を参照し、障害ジョブを直接的、または間接的に前提ジョブとしないジョブを、時限つきジョブから遡って探索する（Ｓ６０、Ｓ６２）。あるジョブの前提ジョブの前提ジョブが障害ジョブであれば、それは間接的に障害ジョブを前提ジョブとしている。したがって、時限つきジョブの前提ジョブを前提ジョブ欄１１４から取得し、さらにそのジョブの前提ジョブを前提ジョブ欄１１４から取得する、という処理を繰り返し、最終的に障害ジョブに到達しない前提ジョブのうち、障害ジョブの後に処理が予定されているジョブを検出する。

このようなジョブがある場合は（Ｓ６２のＹ）、スキップ処理が可能と判断し（Ｓ６４）、なければ（Ｓ６２のＮ）スキップ処理が不可能と判断する（Ｓ６６）。

図１１は図６のＳ３４において臨時ジョブ処理を行う手順を示している。まず障害対応部３９は、利用リソース情報テーブル１００を参照することにより臨時ジョブのフローを作成する（Ｓ７０、Ｓ７２）。具体的にはまず、利用リソース情報テーブル１００の前提ジョブ欄１１４を参照して、障害ジョブを前提ジョブとしているジョブを抽出する。次に障害ジョブを前提としているジョブの参照先ファイル欄１１０に記載されいているファイルと、障害ジョブの更新先ファイル欄１１１に記載されているファイルとを比較し、同一のファイル名を有するファイルを抽出する。これにより、障害ジョブを前提としているジョブが必要とするファイルを特定でき、当該ファイルと同じ名前のファイルを簡易的に生成することができる。そして生成した簡易的なジョブを、障害ジョブのリソース詳細欄１０８に記載されたリソースに基づき、該当するドライブに格納したり、該当するネットワークを介して送信したりする臨時ジョブのフローを作成する。

ここで生成する簡易的なファイルは、本来のファイルと同じ名前で中身がない空ファイルでもよいし、あらかじめ用意した所定のデータを有するファイルの名前を本来のファイルと同じ名前に更新したものでもよい。簡易的なファイルのデータサイズを小さくすることにより、ドライブフルやネットワークの輻輳などのエラーに対して新たなエラーを発生させる可能性が低くなる。

次に障害対応部３９は、作成した臨時ジョブのジョブフローをジョブ情報記憶部４２に登録するとともに、ジョブネット図中の障害ジョブを臨時ジョブに入れ替える（Ｓ７４）。そしてジョブ処理部３６に対し更新したジョブネット図の処理順でジョブ処理を行うように要求し、ジョブ処理部３６がそれを実行することにより、臨時ジョブ、およびそれ以後のジョブの処理が進捗する（Ｓ７６）。なお、Ｓ７２において臨時ジョブを作成した後、障害対応部３９は出力部４０を制御してユーザに臨時ジョブのジョブフローを提示するようにしてもよい。このときユーザが当該ジョブフローを承認する入力を行ったときのみ、Ｓ７４の臨時ジョブの登録を行うようにしてもよい。

また、Ｓ７０、Ｓ７２、Ｓ７４の、利用リソース情報を参照して臨時ジョブを作成し、それをジョブ情報記憶部４２に登録するまでの処理は、障害発生時ではなく、バッチ処理開始以前にあらかじめ行っておいてもよい。この場合、障害発生時には、ジョブネット図において障害ジョブを臨時ジョブと入れ替える処理から開始することができる。

以上述べた本実施の形態によれば、ユーザが登録したジョブフローから、ジョブ処理システムにおいて処理されるジョブの利用リソース情報、ファイル操作に係る情報、時限つきジョブであるか否か、単純再実行が可能か否か、前提となるジョブは何か、といった情報を取得し記憶しておく。そしてバッチ処理時に、あるジョブが障害により停止した場合、まず時限つきジョブの有無を確認し、当該ジョブに至るまでに処理予定のジョブの平均処理時間から、障害ジョブの再実行開始時限を算出する。これをユーザに提示することにより、ユーザは時限つきジョブを完了させるための緊急度に応じた対応を準備することができる。

またシステム側で、障害ジョブの再実行開始時限までの残り時間に応じて、障害ジョブの復旧、再実行を試みるか、障害ジョブの復旧より後続のジョブの処理を優先させるかを判断する。再実行を試みる場合は、あらかじめ記憶しておいた情報に基づき、障害ジョブが単純再実行可能か否かの判断を行い、可能でなければ戻し処理を行うことにより、復旧後に備えて出力ファイルなどを元の状態に戻しておく。これにより、ジョブの処理内容を把握していない運用オペレータでも容易に対応ができるとともに、障害の復旧後に即座に処理を再開させることができる。

戻し処理は、あらかじめ定義した基本の手順に、障害ジョブのジョブフローが登録された際に抽出しておいた操作対象のファイル名を代入することで処理内容を決定し、実行する。一般的なシステムにおいては、戻し処理の必要性の確認、戻し処理の内容決定、実行、といった作業を障害担当者が行う。この際、障害担当者が操作するサーバが障害ジョブを処理していたサーバでなかった場合、リモートアクセスを行う必要があるが、リモートアクセスを許可する機会が増加すると、セキュリティ上の問題となり得る。一方、本実施の形態では、あらかじめ用意した情報に基づき戻し処理を自動で実行するため、障害担当者の負担が削減できるとともにリモートアクセスが必要な状況を最小限にすることができ、セキュリティ性を高めることができる。

さらに障害ジョブの復旧より後続のジョブの処理を優先させると判断した場合は、記憶しておいた情報に基づき、以後に処理が予定されていたジョブのうち、障害ジョブを前提としないジョブを探索して当該ジョブから処理を再開させる。多くのジョブが並列に処理されている大規模なシステムなどにおいては、ジョブ同士の関連性を把握するのは容易でないが、各ジョブの利用リソースに着目して関連性を見出す本手法により、人手に頼ることなく安全に処理を進捗させることができる。

障害ジョブを前提としないジョブがない場合は、記憶しておいた情報に基づき、障害ジョブの代替処理を行う臨時ジョブを作成し、障害ジョブと入れ替えて処理することにより、少なくとも時限つきジョブまで処理を進捗させることができる。

このように本実施の形態では、時限つきジョブの有無、障害ジョブの再実行開始時限までの残り時間、単純再実行の可否、ジョブ同士の関連性などに基づきリアルタイムで最善の対応策を決定し実行する。結果的に、システムが人手に頼らず自律的に障害を克服する可能性が高くなり、システム運用者、開発者の負担が軽減する。また、障害担当者が呼び出され、解決策を模索しているうちに時限つきジョブの完了が間に合わなくなる、といった事態の発生を抑制でき、運用の安全性が高まる。また本実施の形態はソフトウェアとして１度導入するのみで、ジョブの処理内容に関わらず汎用的に上記の効果を得ることができるため、障害に備えた人員のための人件費や個々のジョブ開発費を軽減できる。

さらに複数のサーバを備えたシステムにおいては、各サーバが処理するジョブが利用するリソースやジョブの処理内容などの情報をサーバ間で共有しておき、障害対応に必要な処理の内容決定、遂行を自動で行う。これにより、セキュリティ上、リモートアクセスを不可としているシステムなど、運用オペレータが操作できるサーバと異なるサーバの情報を容易に参照できない状況にあっても、障害対応を安全かつ円滑に進捗させることができる。

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

本実施の形態を適用できるシステムの構成例を示す図である。 ジョブ処理システムでバッチ処理されるジョブの処理順の例を模式的に示す図である。 本実施の形態におけるサーバの構成をより詳細に示す図である。 本実施の形態において登録されるジョブフローの一例を示す図である。 本実施の形態において利用リソース情報取得部が作成する利用リソース情報のデータ構造の例を示す図である。 本実施の形態において障害が発生した際、主に障害原因検出部、障害対応部、出力部が行う障害対応処理の手順を示すフローチャートである。 図６のＳ２２において障害ジョブの再実行を試みる処理手順を示すフローチャートである。 図４で示したジョブフローを有するジョブの戻し処理のジョブフローを示す図である。 本実施の形態において設定される各エラーが障害原因となり得る確率を示すテーブルの例を示す図である。 図６のＳ２８においてスキップ処理の可否を判定する手順を示すフローチャートである。 図６のＳ３４において臨時ジョブ処理を行う手順を示すフローチャートである。

符号の説明

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

Claims (8)

1. 処理内容が登録されたジョブを登録された処理順でバッチ処理するジョブ処理システムであって、
   登録された各ジョブの処理内容から、各ジョブが利用するリソースおよびファイル操作に係る情報を抽出して記憶する利用リソース情報取得部と、
   バッチ処理時に障害が発生した際、以後に処理予定のジョブのうち、障害が発生したジョブの出力結果を利用しないジョブを、前記登録された処理順と前記各ジョブが利用するリソースおよびファイル操作に係る情報から検出し、検出したジョブから処理を再開することを特徴とするジョブ処理システム。
2. 前記利用リソース情報取得部は、完了時限が設定されている時限つきジョブの当該設定時限を取得して記憶し、
   前記障害対応部は障害発生時に、以後に処理予定のジョブから時限つきジョブを検出して、当該時限つきジョブを時限までに完了させるために障害復旧作業に許容される時間を、時限つきジョブおよびそれまでに処理予定の各ジョブの平均処理時間の実績値から算出し、前記許容される時間が所定のしきい値未満であるとき、前記検出したジョブから処理を再開することを特徴とする請求項１に記載のジョブ処理システム。
3. 前記障害対応部は、障害が発生したジョブの出力結果を利用しないジョブが検出されない場合、障害が発生したジョブと次に処理予定のジョブがそれぞれ利用するリソースおよびファイル操作に係る情報を参照して特定したジョブ同士の関連性に基づき生成した簡易的な処理内容のジョブを、障害が発生したジョブの代替ジョブとして臨時で処理することにより、次に処理予定のジョブの処理を可能とすることを特徴とする請求項１または２に記載のジョブ処理システム。
4. 前記障害対応部は、前記許容される時間が所定のしきい値以上であるとき、当該許容される時間をユーザに通知することにより障害復旧の作業開始を促すとともに、前記許容される時間の残り時間の監視を行い、当該残り時間が所定のしきい値未満となったとき、前記検出したジョブからの再開へ処理を移行することを特徴とすることを特徴とする請求項２に記載のジョブ処理システム。
5. 前記平均処理時間の実績値は、ジョブを処理する都度取得した処理時間をあらかじめ設定した複数の条件ごとに平均した値を記憶装置に記録しておき、
   前記障害対応部は、障害発生時の条件と合致する条件における平均処理時間の実績値を前記記憶装置から読み出すことを特徴とする請求項２に記載のジョブ処理システム。
6. 前記障害対応部は、前記検出したジョブから処理を再開することをユーザに対して通知し、ユーザからの承認を受け付けた後、処理を再開することを特徴とする請求項１に記載のジョブ処理システム。
7. ユーザの設定に従いジョブをバッチ処理するステップと、
   設定された各ジョブの処理内容から、各ジョブが利用するリソースおよびファイル操作に係る情報を抽出しメモリに格納するステップと、
   バッチ処理時に障害が発生した際、以後に処理予定のジョブのうち、障害が発生したジョブの出力結果を利用しないジョブを、前記登録された処理順と前記各ジョブが利用するリソースおよびファイル操作に係る情報から検出し、検出したジョブから処理を再開するステップと、
   を含むことを特徴とするジョブ処理方法。
8. 障害が発生した際、以後に処理予定のジョブに完了時限が設定されている時限つきジョブが含まれるか否かを特定するステップと、
   時限つきジョブが含まれる場合、当該時限つきジョブを時限までに完了させるために障害復旧作業に許容される時間を、時限つきジョブおよびそれまでに処理予定の各ジョブの平均処理時間の実績値から算出するステップと、をさらに含み、
   前記検出したジョブから処理を再開するステップは、前記許容される時間が所定のしきい値未満であった場合に実行することを特徴とする請求項７に記載のジョブ処理方法。

Images