JP2019095946A - システム運用操作チェック装置 - Google Patents

Abstract

【課題】複数のチェック観点から複数種類ある運用操作の実行可否を判定する。【解決手段】予定操作とチェックリストを入力としてチェック部品を実行して予定操作及び関連要素をチェックし、チェック部品の実行結果を統合して予定操作の実行可否を判定するチェッカ構成・実行部１４０と、チェッカ構成・実行部１４０による予定操作の実行可否の判定結果を出力するチェック結果出力部１５０を有する。【選択図】図１

Description

本発明は、システム運用操作チェック装置に関する。

システム運用において、ジョブ、タスクと呼ばれるようなプログラムの実行時又は実行前に、システムで既に稼動している別のプログラムとの競合の観点から、該プログラムの実行可否を機械的に判定する必要がある。

このようなプログラムの実行可否を機械的に判定する技術として、例えば、特許文献１がある。

特許文献１は、事前に設定されたジョブ運用方式に応じてジョブと該ジョブがアクセスする資源との対応関係及び動作状況の管理情報を含む排他管理ファイルを用意しておき、ジョブの開始前に排他管理ファイルを検索して該ジョブの実行可能の可否をチェックする。これにより、コンピュータシステムの利用者によるジョブ又はファイルの排他管理を行うことを不要とする。

特開平９−３１９５９９号公報

ところで、システムの運用現場においては、例えば、ＯＳ、ミドルウェア、アプリケーションに実装されている機能のコマンド実行、該コマンドを纏めたバッチ（ジョブ）の実行、設定値の変更、ファイルのコピーや移動等の多種多様な運用操作が実行される。

これらの運用操作の失敗はシステム全体に影響を与え、障害事故を発生させる可能性がある。そのため、操作を実行する前には、操作が誤っていないか、他の実行中の操作やシステムの構成要素と互いに悪影響を与え合わないか、操作を実行する前提条件が全て満たされているか等、多くの事柄を事前に確認して操作の実行可否をチェックする必要がある。

このような運用操作チェック方法においては、チェックの数や種類が多いことや、個々のチェックに要するコストの観点から、チェックの機械化や効率化が必要となっている。

例えば、運用操作を実行する上では、操作同士の競合に限らず、操作の入力となるデータの存在の有無、操作がアクセスする外部機器の稼動状況等、様々な観点のチェックが必要となる。

特許文献１は、プログラムの競合という限定的なチェックの観点において運用操作をチェックしている。しかし、複数種類ある運用操作を対象にして、複数のチェック観点に則って操作の実行可否を判定することについては言及されていない。

本発明の目的は、複数のチェック観点から複数種類ある運用操作の実行可否を判定することにある。

本発明の一態様のシステム運用操作チェック装置は、システムで実行する運用操作の情報を予定操作として記憶する予定操作記憶部と、前記予定操作と、前記予定操作の関連要素と、前記予定操作及び前記関連要素のチェックに用いるチェック部品との対応関係を指定した情報を有するチェックリストを記憶するチェックリスト記憶部と、前記チェック部品を記憶するチェック部品記憶部と、前記予定操作記憶部から前記予定操作を取得し、前記チェックリスト記憶部から前記チェックリストを取得し、前記チェック部品記憶部から前記チェック部品を取得し、前記予定操作と前記チェックリストを入力として前記チェック部品を実行して前記予定操作及び前記関連要素をチェックし、前記チェック部品の実行結果を統合して前記予定操作の実行可否を判定するチェッカ構成・実行部と、前記チェッカ構成・実行部による前記予定操作の前記実行可否の判定結果を出力するチェック結果出力部とを有することを特徴とする。

本発明の一態様によれば、複数のチェック観点から複数種類ある運用操作の実行可否を判定することができる。

実施例１におけるシステム運用操作チェック装置の構成図である。 予定操作の一例を示す図である。 チェックリストの一例を示す図である。 チェック部品の一例を示す図である。 チェック部品インデックスの一例を示す図である。 チェッカ構成・実行部の内部構成の一例を示す図である。 チェック結果出力の一例を示す図である。 実施例２におけるシステム運用操作チェック装置の構成図である。 クラス指定チェックリストの一例を示す図である。 チェック部品特定ルールの一例を示す図である。 クラス定義・階層情報の一例を示す図である。 チェック部品特定部によるチェック部品特定の一例を示す図である。 実施例３におけるシステム運用操作チェック装置の構成図である。 クラス未指定チェックリストの一例を示す図である。 クラス特定ルールの一例を示す図である。 クラス・ＩＤ対応情報の一例を示す図である。 クラス特定部の出力するクラス指定チェックリストの一例を示す図である。 実施例１におけるシステム運用操作チェック装置の処理の一例を示すフローチャートである。 実施例２におけるチェック部品特定処理の一例を示すフローチャートである。 実施例３におけるクラス特定処理の一例を示すフローチャートである。

以下、図面を用いて実施例について詳細に説明する。

図１〜図７、図１８を参照して、実施例１のシステム運用操作チェック装置の構成について説明する。

＜実施例１におけるシステム運用操作チェック装置の構成＞
図１は、実施例１のシステム運用操作チェック装置１００の構成図である。
図１に示すように、システム運用操作チェック装置１００は、予定操作記憶部１１０と、チェックリスト記憶部１２０と、チェック部品記憶部１３０と、チェッカ構成・実行部１４０と、チェック結果出力部１５０とを有する。

予定操作記憶部１１０、チェックリスト記憶部１２０およびチェック部品記憶部１３０は、ＲＡＭやＲＯＭ等の揮発性記憶素子や、ＨＤＤやＳＳＤ等の不揮発性記憶素子から成る記憶装置で構成される。

予定操作記憶部１１０は、これから実行しようとしている運用操作である予定操作２００（図２参照）の情報を記憶する。チェックリスト記憶部１２０は、予定操作２００の実行可否を判定する上で必要なチェック観点をチェックレコード３１０（図３参照）として列挙したチェックリスト３００の情報を記憶する。

チェック部品記憶部１３０は、予定操作２００の実行可否を様々な観点からチェックする部品としてチェック部品４００（図４参照）を記憶する。

なお、予定操作２００、チェックリスト３００およびチェック部品４００は、それぞれ複数個記憶しても良いが、以降の説明においては予定操作２００およびチェックリスト３００は１個、チェック部品４００は複数個記憶するものとする。

チェッカ構成・実行部１４０は、予定操作記憶部１１０が記憶する予定操作２００の情報とチェックリスト記憶部１２０が記憶するチェックリスト３００の情報を入力として、チェック部品記憶部１３０が記憶するチェック部品４００を制御して予定操作２００の実行可否を判定する。チェッカ構成・実行部１４０は、例えば、予定操作２００の実行可否を判定する一連の機能に対して、該機能のアルゴリズムを記憶する記憶装置と、該機能を制御するＣＰＵ等の演算装置で構成される。

なお、チェッカ構成・実行部１４０の有する記憶装置は、予定操作記憶部１１０、チェックリスト記憶部１２０およびチェック部品記憶部１３０の記憶装置と同一のものを用いてもよい。

チェック部品記憶部１３０は、チェック部品４００を一意に識別するＩＤを示すチェック部品ＩＤ３４０とチェック部品４００の実体を紐付ける情報として、チェック部品インデックス５００を有してもよい（図５参照）。チェック部品４００の実体の例としては、例えば、チェックのアルゴリズム又はアルゴリズムの実行ファイル等がある。

なお、チェック部品インデックス５００は、チェッカ構成・実行部１４０の記憶装置が有してもよいが、以降の説明においては、チェック部品記憶部１３０がチェック部品インデックス５００を有するものとする。

チェック結果出力部１５０は、ディスプレイ等の出力装置で構成され、システム運用操作チェック装置１００による予定操作２００の実行可否の判定結果等の情報を、チェック結果出力７００（図７参照）の様な形式で出力する。なお、ディスプレイ上に結果画面として表示する他にも、結果内容を印刷した帳票を出力しても良い。

＜予定操作＞
図２は、予定操作２００の一例を示す図である。
図２に示すように、予定操作２００は、該操作を一意に識別するＩＤを示す予定操作ＩＤ２１０を有する。予定操作ＩＤ２１０は、予定操作２００を一意に識別するＩＤとして、例えばバッチプログラムを識別するプログラム名やプログラムＩＤに当たる「ＢＡＴＣＨ＿Ｉ０３００」という文字列情報を有する。

その他の予定操作ＩＤ２１０の例としては、ＯＳ、ミドルウェア、アプリケーション等に実装されている機能を実行するためのコマンド文字列情報、各運用現場で個別に定義している運用操作の識別名称等がある。

なお、ＩＤの識別性を確保する為に、例えばプログラム実行ファイルのファイル名をＩＤとして用いる場合には、システム上における該ファイルの絶対パスの文字列をＩＤとして指定することが必要となる可能性もある。しかし、本実施例では簡単の為、以降は、「ＢＡＴＣＨ＿Ｉ０３００」の様な短い文字列をＩＤとして用いて説明する。

予定操作２００は、該操作の属性情報を示す予定操作属性情報２２０を有してもよい。予定操作属性情報２２０は、属性項目２２１と属性値２２２から構成される。属性項目２２１は、予定操作２００の属性項目として、例えば、予定操作２００の実行環境サーバに当たる「実行サーバ」という文字列情報や、予定操作２００の実行予定時刻に当たる「実行時刻」という文字列情報を有する。その他の属性項目２２１の例としては、例えば、予定操作２００が何かしらのコマンド実行である場合には、オプションパラメタ等がある。

属性値２２２は、属性項目２２１に対応する属性値として、例えば、属性項目２２１「実行サーバ」に対しては「サーバＡ」という文字列情報、属性項目２２１「実行時刻」に対しては「２０１７／６／２６ ２０：００」という文字列情報を有する。
以上のように、予定操作２００を、運用操作やその属性情報を一意に識別可能なＩＤを指定するという形式とすることで、運用操作の種別を制限せずに済む。

＜チェックリスト＞
図３は、チェックリスト３００の一例を示す図である。
図３に示すように、チェックリスト３００は、１つ以上のチェックレコード３１０から構成される。各チェックレコード３１０は、予定操作指定項目３２０と、関連要素指定項目３３０と、チェック部品ＩＤ３４０とを有する。
予定操作指定項目３２０は、チェックレコード３１０のチェック対象となる予定操作２００を指定する情報を有する。

関連要素指定項目３３０は、チェックレコード３１０のチェック対象となる予定操作２００に関連し共にチェック対象となるシステム要素を指定する情報を有する。システム要素は、例えば、予定操作２００以外の他の運用操作や、予定操作２００が利用するデータやマシンリソースなどのシステム資源、予定操作２００がアクセスする機器や外部システム等がある。

予定操作指定項目３２０は、チェックレコード３１０のチェック対象となる予定操作２００を識別するためのＩＤ項目を有する。ＩＤ項目は、例えばバッチプログラムを識別する「ＢＡＴＣＨ＿Ｉ０３００」という文字列情報を有する。
同様にして、関連要素指定項目３３０は、予定操作２００の関連要素を識別するためのＩＤ項目を有する。ＩＤ項目は、例えばファイルを識別する「ＤＢｂａｃｋｕｐ．ｌｏｇ」という文字列情報を有する。

チェック部品ＩＤ３４０は、チェックレコード３１０のチェックを実行するチェック部品４００を識別するＩＤ項目を有する。ＩＤ項目は、例えば、関連要素指定項目３３０で関連要素として指定されたファイルのサイズをチェックするチェック部品４００を示す「ファイルサイズチェック部品」という文字列を有する。

なお、予定操作指定項目３２０及び関連要素指定項目３３０は、ＩＤ項目に加えて、属性項目、比較式、比較値、等の情報を有しても良い。例えば、＃４のチェックレコード３１０は、予定操作２００「ＢＡＴＣＨ＿Ｉ０３００」の関連要素であるファイル「ＤＢｂａｃｋｕｐ．ｌｏｇ」の属性項目として「サイズ」という文字列情報を有し、比較式として「＜」という文字列情報を有し、比較値として「１０ＭＢ」という文字列情報を有する。

予定操作指定項目３２０及び関連要素指定項目３３０に指定される情報は、チェッカ構成・実行部１４０によって、チェック部品ＩＤ３４０で指定されるチェック部品４００に送信されることになる。
なお、実施例１では、チェックレコード３１０は予定操作指定項目３２０と関連要素指定項目３３０を１つずつ有しているが、それぞれ２つ以上有してもよい。

以上のように、チェックリスト３００において、チェック対象や、チェック対象が満たすべき条件等を、予定操作指定項目３２０及び関連要素指定項目３３０に指定し、チェックを機械的に実施するために必要なチェック部品４００をチェック部品ＩＤ３４０に指定する。これにより、予定操作２００の実行可否を判定する上で事前確認が必要な様々なチェック観点を、共通的な様式で表現することができる。

＜チェック部品＞
図４は、チェック部品４００の一例を示す図である。
図４に示すように、チェック部品４００は、入力パラメータ４１０と、出力パラメータ４２０と、チェック処理内容４３０とから構成される。実施例１では、チェック対象となるファイルのサイズが比較式や比較値で構成される条件を満たすかチェックする実行ファイル「ＦｉｌｅＳｉｚｅＣｈｅｃｋｅｒ．ｅｘｅ」を、チェック部品４００の一例として説明する。

チェック部品４００は、対象ファイル、比較式、比較値を入力パラメータ４１０として与えられると、チェック処理内容４３０に従って、チェック処理を実行する。チェック処理内容４３０の最初の処理ステップとして、対象ファイルのサイズを実測値として取得する。ファイルサイズの取得方法としては、例えば、ＯＳのファイルサイズ取得コマンドや、市販のファイル管理アプリケーションの機能を用いてよい。
チェック部品４００は、取得した実測値を、比較式と比較値を用いて評価し、評価結果をチェック判定結果として実測値と共に、出力パラメータ４２０として出力する。

以上のように、チェック対象や、チェック対象が満たすべき条件等を入力として、必要に応じてチェック対象の情報をシステムや関連機器から取得し、それらを基にチェック判定結果を出力として返すチェック部品４００を複数使い分ける。これにより、多様な運用操作やチェック観点を対象としたチェックが可能となる。

＜チェック部品インデックス＞
図５は、チェック部品インデックス５００の一例を示す図である。
図５に示すように、チェック部品インデックス５００は、チェック部品ＩＤ５１０と、チェック部品実体５２０と、入力パラメータインタフェース５３０とから構成される。チェック部品インデックス５００は、チェッカ構成・実行部１４０が、チェックレコード３１０のチェック部品ＩＤ３４０で指定されたチェック部品４００の実体と、チェック部品４００に入力すべき入力パラメータ４１０を特定するために使用する。

チェック部品ＩＤ５１０は、チェック部品４００を識別するためのＩＤである。ＩＤは、例えば、チェックリスト３００のチェック部品ＩＤ３４０の例と同様に、「ファイルサイズチェック部品」という文字列情報を有する。

チェック部品実体５２０は、チェック部品４００の実体を示す。例えば、チェック部品実体５２０は、「ＦｉｌｅＳｉｚｅＣｈｅｃｋｅｒ．ｅｘｅ」という実行ファイル名を有する。

入力パラメータインタフェース５３０は、チェック部品４００に入力すべき入力パラメータ４１０を、予定操作２００やチェックリスト３００の構成要素を用いて指定するものである。

例えば、図５のチェック部品インデックス５００の＃１の例では、「ＦｉｌｅＳｉｚｅＣｈｅｃｋｅｒ．ｅｘｅ」の入力パラメータ４１０において、対象ファイルとして関連要素指定項目３３０のＩＤを、比較式として関連要素指定項目３３０の比較式を、比較値として関連要素指定項目３３０の比較値を、それぞれ指定している。

なお、実施例１においては、入力パラメータインタフェース５３０にチェック部品４００の入力パラメータ４１０を全て明記している。しかし、チェック部品４００が、プログラミング言語の関数の引数指定のように、入力パラメータ４１０の順番を、例えば（対象ファイル、比較式，比較値）といった形で定義している場合には、入力パラメータインタフェース５３０には、（関連要素．ＩＤ、関連要素．比較式、関連要素．比較値）という情報だけ指定するようにしてもよい。

以上のように、チェック部品インデックス５００として、チェック部品４００の実体とインタフェース情報を、チェック部品４００を識別するためのＩＤと関連付けて記憶しておくことで、チェックリスト３００にはＩＤのみをチェック部品ＩＤ３４０として指定すればよい。この結果、チェックリスト３００の作成者は、チェック部品４００の実体やインタフェースを意識せずに、チェックリスト３００を作成することが可能となる。

＜チェッカ構成・実行部＞
図６は、チェッカ構成・実行部１４０の内部構成の一例を示す図である。
図６に示すように、チェッカ構成・実行部１４０は、チェックレコードフィルタリング部６１０と、チェック部品取得部６２０と、チェック部品実行部６３０と、チェック結果統合部６４０とから構成される。

チェックレコードフィルタリング部６１０は、始めに、予定操作記憶部１１０から予定操作２００を、チェックリスト記憶部１２０からチェックリスト３００をそれぞれ取得する。そして、チェックリスト３００から、予定操作２００の予定操作ＩＤ２１０が予定操作指定項目３２０のＩＤと一致するチェックレコード３１０を抽出し、一致しないチェックレコード３１０は破棄する。

チェック部品取得部６２０は、チェックレコードフィルタリング部６１０で抽出したチェックレコード３１０のチェック部品ＩＤ３４０を用いて、チェック部品記憶部１３０に記憶されるチェック部品インデックス５００を走査し、チェック部品ＩＤ３４０と一致するチェック部品ＩＤ５１０に対応するチェック部品実体５２０と入力パラメータインタフェース５３０の情報を取得する。

チェック部品実行部６３０は、取得した入力パラメータインタフェース５３０に指定された情報を予定操作２００とチェックレコード３１０から取得し、該情報を入力パラメータ４１０として、チェック部品実体５２０で指定されたチェック部品４００に与えてチェック部品４００を実行する。

チェック結果統合部６４０は、まず、チェックレコードフィルタリング部６１０で抽出した全てのチェックレコード３１０に対応するチェック部品実行部６３０で実行したチェック部品４００の出力パラメータ４２０を取得する。そして、それら全てを統合することで予定操作２００の実行可否を判定して実行可否の判定結果をチェック結果出力部１５０に送信する。

予定操作２００の実行可否の判定においては、例えば、全てのチェック部品４００の出力パラメータ４２０が、ＯＫ、ＮＧいずれか２値を取り得るパラメータをチェックレコード３１０のチェック判定結果として含むとするならば、チェック結果統合部６４０が取得した全てのチェック判定結果がＯＫであれば予定操作２００は実行可能と判定する。チェック判定結果の内、一つでもＮＧを含むのであれば実行不可と判定する。

なお、実行可否判定結果に加えて、例えば、チェック判定結果がＮＧとなったチェックレコード３１０の情報をチェック結果出力部１５０に送信してもよい。また、その時に、チェックレコード３１０に対応するチェック部品４００の出力パラメータ４２０を併せてチェック結果出力部１５０に送信してもよい。さらに、チェック判定結果に関わらず、チェックレコードフィルタリング部６１０で抽出した全てのチェックレコード３１０と、チェック部品実行部６３０で実行した全てのチェック部品４００の出力パラメータ４２０を併せてチェック結果出力部１５０に送信してもよい。

以上のように、チェッカ構成・実行部１４０が、予定操作２００とチェックリスト３００の情報を基に、複数種類のチェック部品４００を制御することで、同一装置上での複数観点の運用操作チェックが可能となる。

＜チェック結果出力部＞
図７は、チェック結果出力部１５０が出力するチェック結果出力７００の一例を示す図である。
図７に示すように、チェック結果出力７００は、予定操作ＩＤ７１０と予定操作実行可否判定結果７２０を有する。

予定操作ＩＤ７１０は、チェッカ構成・実行部１４０が実行可否を判定した予定操作２００を識別するＩＤである。予定操作実行可否判定結果７２０は、チェッカ構成・実行部１４０による予定操作２００の実行可否判定結果である。例えば、図７の例では、予定操作ＩＤ７１０が「ＢＡＴＣＨ＿Ｉ０３００」であるバッチプログラムの実行を示す予定操作２００は、予定操作実行可否判定結果７２０として実行不可と判定されている。

なお、チェック結果出力部１５０が、チェッカ構成・実行部１４０から、チェックレコードフィルタリング部６１０で抽出した全てのチェックレコード３１０と、チェック部品実行部６３０で実行した全てのチェック部品４００の出力パラメータ４２０を受信するならば、チェック結果出力７００は、個別チェック結果７３０を有してもよい。

個別チェック結果７３０は、例えば、チェックレコードフィルタリング部６１０で抽出した全てのチェックレコード３１０に加えて、チェックレコード３１０に対応するチェック部品４００の出力パラメータ４２０の内、チェック判定結果と実測値を有してもよい。

以上のように、チェック結果出力部１５０が、予定操作実行可否判定結果７２０を表示することで、システム運用者の予定操作２００の実行に関する意思決定を支援することが可能となる。

また、チェック結果出力部１５０が個別チェック結果７３０を表示することで、仮に予定操作実行可否判定結果７２０が実行不可となっていても、システム運用者が予定操作２００を実行可とするための気づきを与えることが可能となる。

＜処理フロー＞
図１８は、システム運用操作チェック装置１００の処理の一例を示すフローチャートである。
最初に、予定操作記憶部１１０から予定操作２００を、チェックリスト記憶部１２０からチェックリスト３００を、それぞれ取得する（Ｓ１８０１）。

次に、予定操作２００の予定操作ＩＤ２１０をキーとして前記チェックリスト３００を走査し、前記チェックリスト３００の予定操作指定項目３２０のＩＤが予定操作ＩＤ２１０と一致するチェックレコード３１０を抽出し、一致しないチェックレコード３１０はフィルタリングして破棄する（Ｓ１８０２）。

次に、Ｓ１８０３：抽出した前記チェックレコード３１０のチェック部品ＩＤ３４０をキーとしてチェック部品記憶部１３０に記憶されるチェック部品インデックス５００を走査し、チェック部品インデックス５００のチェック部品ＩＤ５１０がチェック部品ＩＤ３４０と一致した場合、チェック部品ＩＤ５１０と対応付けられたチェック部品実体５２０と入力パラメータインタフェース５３０の情報を取得する。

次に、取得した前記入力パラメータインタフェース５３０に指定された情報を予定操作２００とチェックレコード３１０から取得し、該情報を入力パラメータ４１０として、チェック部品実体５２０で指定されたチェック部品４００に与えてチェック部品４００を実行する（Ｓ１８０４）。

次に、抽出した全てのチェックレコード３１０に対して、実行したチェック部品４００の出力パラメータ４２０を取得し、それら全てを統合することで予定操作２００の実行可否を判定する（Ｓ１８０５）。
次に、予定操作２００の実行可否判定結果を含むチェック結果を出力し（Ｓ１８０６）、本処理を終了する。

図８〜図１２、図１９を参照して、実施例２のシステム運用操作チェック装置の構成について説明する。

実施例２は、実施例１のチェックリスト３００のチェックレコード３１０におけるチェック部品ＩＤ３４０を、チェックレコード３１０の予定操作指定項目３２０と関連要素指定項目３３０の情報を基に特定することで、チェックリスト３００を効率良く生成するものである。以降は、実施例１と同じ構成や入出力情報に関しては説明を省略し、変更店及び追加点のみ説明する。

＜実施例２におけるシステム運用操作チェック装置の構成＞
図８は、本実施例におけるシステム運用操作チェック装置８００の構成図である。
図８に示すように、システム運用操作チェック装置８００は、実施例１で説明したシステム運用操作チェック装置１００の構成に加えて、クラス指定チェックリスト記憶部８１０と、チェック部品特定ルール記憶部８２０と、クラス定義・階層情報記憶部８３０と、チェック部品特定部８４０とを有する。

クラス指定チェックリスト記憶部８１０、チェック部品特定ルール記憶部８２０およびクラス定義・階層情報記憶部８３０は、ＲＡＭやＲＯＭ等の揮発性記憶素子や、ＨＤＤやＳＳＤ等の不揮発性記憶素子から成る記憶装置で構成される。なお、記憶装置は、実施例１で説明したシステム運用操作チェック装置１００の構成部品と同一の記憶装置を用いてもよい。

クラス指定チェックリスト記憶部８１０は、チェックリスト３００における予定操作や関連要素のクラスを指定するクラス指定チェックリスト９００を記憶する。クラスとは、システム要素の種別を意味し、例えば、操作であれば「コマンド」や「バッチ」、システム資源であれば「ファイル」や「ＤＢテーブル」等がある。

チェックリスト３００では、システム要素の具体としてＩＤを指定しているが、システム運用操作チェック装置８００では、各システム要素のクラスも合わせて指定する。
チェック部品特定ルール記憶部８２０は、クラス指定チェックリスト９００の情報から各チェックレコードに対応するチェック部品４００を特定するためのルールとして、チェック部品特定ルール１０００を記憶する。
クラス定義・階層情報記憶部８３０は、クラスの階層関係情報を保持するクラス定義・階層情報１１００を記憶する。

チェック部品特定部８４０は、クラス指定チェックリスト記憶部８１０が記憶するクラス指定チェックリスト９００の情報と、チェック部品特定ルール記憶部８２０が記憶するチェック部品特定ルール１０００の情報と、クラス定義・階層情報記憶部８３０が記憶するクラス定義・階層情報１１００の情報とを入力してチェックリスト３００を生成する。

チェックリスト３００を生成する機能は、該機能のアルゴリズムを記憶する記憶装置と、該機能を制御するＣＰＵ等の演算装置で構成される。なお、該記憶装置と該演算装置は、実施例１で説明したシステム運用操作チェック装置１００の構成部品と同一の記憶装置及び演算装置を用いてもよい。
チェック部品特定部８４０が生成したチェックリスト３００はチェックリスト記憶部１２０が記憶し、実施例１で説明した通り、チェッカ構成・実行部１４０の入力として用いる。

＜クラス指定チェックリスト＞
図９は、クラス指定チェックリスト９００の一例を示す図である。
図９に示すように、クラス指定チェックリスト９００は、チェックリスト３００のチェックレコード３１０の構成要素の内、予定操作指定項目３２０と関連要素指定項目３３０を基本として、それぞれにクラス指定項目９４０を追加した予定操作指定項目９２０と関連要素指定項目９３０から成るクラス指定チェックレコード９１０を有する。なお、全て、または一部のクラス指定チェックレコード９１０が、チェックリスト３００のチェックレコード３１０と同様にチェック部品ＩＤ３４０を有してもよい。

クラス指定項目９４０には、予定操作指定項目９２０や関連要素指定項目９３０で指定する予定操作および関連要素のＩＤに対して、該ＩＤにより識別されるシステム要素のクラスを指定する。

例えば、図９のクラス指定チェックリスト９００における＃４のクラス指定チェックレコード９１０では、予定操作指定項目９２０には、クラスが「バッチ」であり、ＩＤが「ＢＡＴＣＨ＿Ｉ０３００」であるバッチを指定し、関連要素指定項目９３０には、クラスが「ファイル」であり、ＩＤが「ＤＢｂａｃｋｕｐ．ｌｏｇ」であるファイルを指定している。

＜チェック部品特定ルール＞
図１０は、チェック部品特定ルール１０００の一例を示す図である。
図１０に示すように、チェック部品特定ルール１０００は、予定操作指定項目パターン１０１０と、関連要素指定項目パターン１０２０と、チェック部品ＩＤ１０３０とを有する。

予定操作指定項目パターン１０１０と関連要素指定項目パターン１０２０の各項目は、クラス指定チェックレコード９１０の予定操作指定項目９２０と関連要素指定項目９３０とそれぞれ対応している。これらの項目はチェック部品特定部８４０にて、クラス指定チェックレコード９１０とチェック部品特定ルール１０００の間で照合するが、詳細はチェック部品特定部８４０の説明にて後述する。

なお、図１０で、予定操作指定項目パターン１０１０と関連要素指定項目パターン１０２０に用いられている「＊」はワイルドカードを示しているが、この表現方法に限定されるものではない。また、正規表現のようなパターン文字列を指定してもよい。

チェック部品ＩＤ１０３０は、予定操作指定項目パターン１０１０と関連要素指定項目パターン１０２０にマッチするクラス指定チェックレコード９１０に対応するチェック部品４００を識別するＩＤ項目を有する。

＜クラス定義・階層情報＞
図１１は、クラス定義・階層情報１１００の一例を示す図である。
図１１に示すように、クラス定義・階層情報１１００は、クラス間の階層関係情報を有する。例えば、図１１の例では、「業務系バッチ」クラスは「バッチ」クラスに属しており、「バッチ」クラスは「操作」クラスに属する。

＜チェック部品特定部＞
図１２は、チェック部品特定部８４０によるチェック部品特定の一例を示す図である。
図１２に示すように、チェック部品特定部８４０は、クラス指定チェックリスト記憶部８１０からクラス指定チェックリスト９００を取得し、クラス指定チェックリスト９００の各クラス指定チェックレコード９１０に対応するチェック部品４００を特定する。なお、クラス指定チェックレコード９１０に既にチェック部品ＩＤ３４０が指定されている場合は、該クラス指定チェックレコード９１０に対してチェック部品４００の特定は実施しない。

チェック部品特定部８４０は、クラス指定チェックレコード９１０に対応するチェック部品４００を特定するために、クラス指定チェックレコード９１０の予定操作指定項目９２０及び関連要素指定項目９３０の有する各項目が、予定操作指定項目パターン１０１０及び関連要素指定項目パターン１０２０に全てマッチするチェック部品特定ルール１０００を特定する。
なお、上記マッチング時には、値の完全一致に加えて、ワイルドカードや正規表現でのマッチングを用いてもよい。

また、チェック部品特定部８４０は、クラス定義・階層情報記憶部８３０からクラス定義・階層情報１１００を取得し、上記マッチングに活用してもよい。例えば、クラス指定チェックレコード９１０に指定されたクラスに対して、該クラスが属する上位クラスがチェック部品特定ルール１０００に指定されている場合は、該クラス項目はマッチしているとみなしてもよい。

例えば、図１２の例では、クラス指定チェックレコード９１０は、チェック部品特定ルール１０００の＃１とマッチしている。予定操作指定項目パターン１０１０のクラス「操作」は、予定操作指定項目９２０のクラス「バッチ」の上位クラスであることがクラス定義・階層情報１１００に定義されている。

予定操作指定項目９２０のＩＤ、関連要素指定項目９３０のＩＤ、比較式、比較値は、ワイルドカード「＊」によって、チェック部品特定ルール１０００の＃１の各項目とマッチしているとみなしている。残りの項目は値が完全一致している。

チェック部品特定部８４０は、マッチングの結果特定したクラス指定チェックレコード９１０に対応するチェック部品４００のチェック部品ＩＤ１０３０をクラス指定チェックレコード９１０と結合し、チェックレコード３１０を生成する。生成した全てのチェックレコード３１０と、初めからチェック部品ＩＤ３４０が指定されていた全てのクラス指定チェックレコード９１０を統合し、チェックリスト３００としてチェックリスト記憶部１２０に記憶する。

＜チェック部品特定処理フロー＞
図１９は、チェック部品特定処理の一例を示すフローチャートである。
最初に、クラス指定チェックリスト記憶部８１０からクラス指定チェックリスト９００を、チェック部品特定ルール記憶部８２０からチェック部品特定ルール１０００を、クラス定義・階層情報記憶部８３０からクラス定義・階層情報１１００をそれぞれ取得する（Ｓ１９０１）。

次に、クラス指定チェックリスト９００の各クラス指定チェックレコード９１０に対して、予定操作指定項目９２０及び関連要素指定項目９３０の有する各項目が、前記チェック部品特定ルール１０００の予定操作指定項目パターン１０１０及び関連要素指定項目パターン１０２０に全てマッチするチェック部品特定ルール１０００を特定する（Ｓ１９０２）。パターンのマッチングには、前記クラス定義・階層情報１１００に指定されるクラス間の階層関係も適用する。

次に、マッチングの結果特定したチェック部品特定ルール１０００のチェック部品ＩＤ１０３０を、クラス指定チェックレコード９１０と結合し、チェックレコード３１０を生成した後、これらのレコードを全て統合してチェックリスト３００としてチェックリスト記憶部１２０に記憶し（Ｓ１９０３）、処理を終了する。

図１３〜図１７、図２０を参照して、実施例３のシステム運用操作チェック装置の構成について説明する。

実施例３は、実施例２のクラス指定チェックリスト９００に指定するクラスを、システム要素の具体を示すＩＤ項目を基に特定することで、クラス指定チェックリスト９００を効率良く生成するものである。以降は、実施例１および実施例２と同じ構成や入出力情報に関しては説明を省略し、変更点及び追加点のみ説明する。

＜実施例３におけるシステム運用操作チェック装置の構成＞
図１３は、実施例３におけるシステム運用操作チェック装置１３００の構成図である。
システム運用操作チェック装置１３００は、実施例２で説明したシステム運用操作チェック装置８００の構成に加えて、クラス未指定チェックリスト記憶部１３１０と、クラス特定情報記憶部１３２０と、クラス特定部１３３０とを有する装置である。

クラス未指定チェックリスト記憶部１３１０及びクラス特定情報記憶部１３２０は、ＲＡＭやＲＯＭ等の揮発性記憶素子や、ＨＤＤやＳＳＤ等の不揮発性記憶素子から成る記憶装置で構成される。なお、記憶装置は、実施例１で説明したシステム運用操作チェック装置１００や実施例２で説明したシステム運用操作チェック装置８００の構成部品と同一の記憶装置を用いてもよい。

クラス未指定チェックリスト記憶部１３１０は、クラスの情報を除いてはクラス指定チェックリスト９００と同様の項目を有するクラス未指定チェックリスト１４００を記憶する。

クラス特定情報記憶部１３２０は、クラス未指定チェックリスト１４００で指定されるシステム要素の具体を示すＩＤ項目を基に、該システム要素に対応するクラスを特定するための情報として、クラス特定ルール１５００やクラス・ＩＤ対応情報１６００を記憶する。

クラス特定部１３３０は、クラス未指定チェックリスト１４００と、クラス特定ルール１５００またはクラス・ＩＤ対応情報１６００を入力として、クラス指定チェックリスト９００を生成する。クラス指定チェックリスト９００を生成する機能は、該機能のアルゴリズムを記憶する記憶装置と、該機能を制御するＣＰＵ等の演算装置で構成される。

なお、該記憶装置と該演算装置は、実施例１で説明したシステム運用操作チェック装置１００や実施例２で説明したシステム運用操作チェック装置８００の構成部品と同一の記憶装置及び演算装置を用いてもよい。

クラス特定部１３３０が生成したクラス指定チェックリスト９００はクラス指定チェックリスト記憶部８１０が記憶し、以降、実施例２で説明した通り、チェック部品特定部８４０の入力として用いる。

＜クラス未指定チェックリスト＞
図１４は、クラス未指定チェックリスト１４００の一例を示す図である。
図１４に示すように、クラス未指定チェックリスト１４００は、１つ以上のクラス未指定チェックレコード１４１０を有する。クラス未指定チェックレコード１４１０は、予定操作指定項目１４２０及び関連要素指定項目１４３０から構成される。予定操作指定項目１４２０及び関連要素指定項目１４３０が有する項目については、予定操作指定項目３２０及び関連要素指定項目３３０と同様のため、その説明を省略する。

なお、全て、または一部のクラス未指定チェックレコード１４１０が、チェックリスト３００のチェックレコード３１０と同様にチェック部品ＩＤ３４０を有してもよい。同様にして、全て、または一部のクラス未指定チェックレコード１４１０が、クラス指定チェックリスト９００のクラス指定チェックレコード９１０と同様にクラスを指定する項目を有してもよい。

＜クラス特定ルール＞
図１５は、クラス特定ルール１５００の一例を示す図である。
図１５に示すように、クラス特定ルール１５００は、クラス１５１０及びクラス１５１０に対応するマッチングルール１５２０から構成される。クラス１５１０は、前述のように、システム要素の種別を示す情報である。あるシステム要素を識別するＩＤがマッチングルール１５２０に記載された条件を満たす場合、該システム要素のクラスは、該マッチングルール１５２０に対応するクラス１５１０として特定される。

図１５を用いて説明すると、例えば、「ＢＡＴＣＨ＿Ｉ０３００」というＩＤを持つシステム要素があるとすると、該ＩＤはクラス特定ルール１５００の＃１のマッチングルール１５２０に記載された正規表現とマッチングするため、該システム要素のクラス１５１０は「基盤系バッチ」として特定される。

なお、クラス特定ルール１５００におけるルールの記法は、上述の例に限定しない。例えば、クラス特定の判断材料として、ＩＤに加えて属性情報を用いてもよい。

＜クラス・ＩＤ対応情報＞
図１６は、クラス・ＩＤ対応情報１６００の一例を示す図である。
図１６に示すように、クラス・ＩＤ対応情報１６００は、クラス１６１０及びクラス１６１０に分類されるシステム要素のシステム要素ＩＤ１６２０を有する。例えば、「Ｓｅｔｔｉｎｇ．ｔｘｔ」というＩＤを持つシステム要素のクラス１６１０は「環境設定ファイル」として特定される。

＜クラス特定部＞
図１７は、クラス特定部１３３０の出力するクラス指定チェックリスト９００の一例を示す図である。
図１７に示すように、クラス特定部１３３０は、クラス未指定チェックリスト記憶部１３１０からクラス未指定チェックリスト１４００を取得し、各クラス未指定チェックレコード１４１０の予定操作指定項目１４２０及び関連要素指定項目１４３０に指定されるシステム要素のクラスを特定する。

なお、クラス未指定チェックレコード１４１０に既にクラスが指定されている場合は、クラス未指定チェックレコード１４１０に対してクラスの特定は実施しない。

クラス特定部１３３０は、クラス特定情報記憶部１３２０から、クラス特定ルール１５００又はクラス・ＩＤ対応情報１６００を取得し、これらの情報を基に各クラス未指定チェックレコード１４１０の予定操作指定項目１４２０及び関連要素指定項目１４３０に指定されるシステム要素に対して、クラスを特定する。

例えば、図１７の例では、クラス特定部１３３０は、図１４に記載のクラス未指定チェックリスト１４００を入力として、＃３のクラス未指定チェックレコード１４１０の関連要素ＩＤ「ＲＤＢ０１」と、＃４のクラス未指定チェックレコード１４１０の関連要素ＩＤ「ＤＢｂａｃｋｕｐ．ｌｏｇ」に対して、クラス・ＩＤ対応情報１６００により、それぞれのクラスを「ＤＢサーバ」と「ログファイル」として特定する。それ以外のシステム要素のＩＤについては、クラス特定ルール１５００によって、「基盤系バッチ」または「業務系バッチ」としてクラスを特定する。

クラス特定部１３３０は、特定した各クラスの情報を、クラス未指定チェックレコード１４１０の予定操作指定項目１４２０と関連要素指定項目１４３０に結合し、クラス指定チェックリスト９００としてクラス指定チェックリスト記憶部８１０に記憶する。

＜クラス特定処理フロー＞
図２０は、クラス特定処理の一例を示すフローチャートである。
最初に、クラス未指定チェックリスト記憶部１３１０からクラス未指定チェックリスト１４００を、クラス特定情報記憶部１３２０からクラス特定ルール１５００とクラス・ＩＤ対応情報１６００をそれぞれ取得する（Ｓ２００１）。

次に、クラス特定ルール１５００に指定されたＩＤのパターン情報や、クラス・ＩＤ対応情報１６００に指定された対応情報を基に、クラス未指定チェックリスト１４００の各クラス未指定チェックレコード１４１０の予定操作指定項目１４２０及び関連要素指定項目１４３０に指定されるシステム要素に対してクラスを特定する（Ｓ２００２）。

次に、特定した各クラスの情報を、クラス未指定チェックレコード１４１０に結合し、クラス指定チェックレコード９１０を生成した後、これらのレコードを全て統合してクラス指定チェックリスト９００としてクラス指定チェックリスト記憶部８１０に記憶し（Ｓ２００３）、処理を終了する。

なお、実施例においては、説明を簡単にするために、チェックリスト３００、クラス指定チェックリスト９００、クラス未指定チェックリスト１４００、そして、チェックリスト記憶部１２０、クラス指定チェックリスト記憶部８１０、クラス未指定チェックリスト記憶部１３１０をそれぞれ区別しているが、区別せずに同一のチェックリスト３００を参照して更新する形式としてもよい。

上記実施例によれば、運用操作やチェック観点の種類が各運用現場で異なっている場合や、時間の経過と共にそれらが変化していく場合においても、運用者は、各運用操作・チェック観点毎に専用のチェック装置又はチェック手法をそれぞれ使い分けたり、新たに使い方を学習したりする必要はない。様式が共通化されているチェックリストを作成・編集することで、多様な運用操作やチェック観点を対象としたチェックを機械的に行うことができる。

このようにして、運用操作やチェック観点の種類を限定せず、汎用性・拡張性に富んだシステム運用操作チェック装置を実現できる。

１００ システム運用操作チェック装置
１１０ 予定操作記憶部
１２０ チェックリスト記憶部
１３０ チェック部品記憶部
１４０ チェッカ構成・実行部
１５０ チェック結果出力部
８００ システム運用操作チェック装置
８１０ クラス指定チェックリスト記憶部
８２０ チェック部品特定ルール記憶部
８３０ クラス定義・階層情報記憶部
８４０ チェック部品特定部
１３００ システム運用操作チェック装置
１３１０ クラス未指定チェックリスト記憶部
１３２０ クラス特定情報記憶部
１３３０ クラス特定部

Claims (8)

1. システムで実行する運用操作の情報を予定操作として記憶する予定操作記憶部と、
   前記予定操作と、前記予定操作の関連要素と、前記予定操作及び前記関連要素のチェックに用いるチェック部品との対応関係を指定した情報を有するチェックリストを記憶するチェックリスト記憶部と、
   前記チェック部品を記憶するチェック部品記憶部と、
   前記予定操作記憶部から前記予定操作を取得し、前記チェックリスト記憶部から前記チェックリストを取得し、前記チェック部品記憶部から前記チェック部品を取得し、前記予定操作と前記チェックリストを入力として前記チェック部品を実行して前記予定操作及び前記関連要素をチェックし、前記チェック部品の実行結果を統合して前記予定操作の実行可否を判定するチェッカ構成・実行部と、
   前記チェッカ構成・実行部による前記予定操作の前記実行可否の判定結果を出力するチェック結果出力部と、
   を有することを特徴とするシステム運用操作チェック装置。
2. 前記予定操作の集合を表す予定操作指定項目パターンと、前記関連要素の集合を表す関連要素指定項目パターンと、前記予定操作指定項目パターン及び前記関連要素指定項目パターンの組合せに対応する前記チェック部品とを指定するチェック部品特定ルールを記憶するチェック部品特定ルール記憶部と、
   前記チェック部品特定ルールに基づいて、前記チェックリストに指定された前記予定操作と前記関連要素に対して、対応する前記チェック部品を特定し紐付けるチェック部品特定部と、
   を更に有することを特徴とする請求項１に記載のシステム運用操作チェック装置。
3. 前記チェックリストにおける指定要素の内、前記予定操作及び前記関連要素に対してそれぞれの種別を表すクラスの情報を追加指定するクラス指定チェックリストを記憶するクラス指定チェックリスト記憶部を更に有し、
   前記チェック部品特定部は、
   前記予定操作指定項目パターン及び前記関連要素指定項目パターンの指定に前記クラスの情報を使用し、前記クラスの情報を含む前記チェック部品特定ルールに基づいて、前記クラス指定チェックリストに指定された前記予定操作と前記関連要素に対して、対応する前記チェック部品を特定し紐付けることにより前記チェックリストを生成し、生成された前記チェックリストを前記チェックリスト記憶部に記憶することを特徴とする請求項２に記載のシステム運用操作チェック装置。
4. 前記クラスの間の階層関係としてクラス定義・階層情報を記憶するクラス定義・階層情報記憶部を更に有し、
   前記チェック部品特定部は、
   前記クラス定義・階層情報に基づき、前記クラス指定チェックリストに指定された前記予定操作と前記関連要素に対して指定された前記クラスが、前記予定操作指定項目パターン及び前記関連要素指定項目パターンに指定された前記クラス又は前記クラスの下位階層に属するクラスと一致する場合に、対応する前記チェック部品を特定し紐付けることを特徴とする請求項３に記載のシステム運用操作チェック装置。
5. 前記予定操作及び前記関連要素と前記クラスとの対応関係を有するクラス特定情報を記憶するクラス特定情報記憶部と、
   前記クラス特定情報に基づいて、前記クラス指定チェックリストに指定された前記予定操作と前記関連要素に対して、対応する前記クラスを特定し紐付けるクラス特定部と、
   を更に有することを特徴とする請求項３に記載のシステム運用操作チェック装置。
6. 前記チェックリストにおける指定要素の内、前記クラスを除く前記予定操作及び前記関連要素を記憶するクラス未指定チェックリスト記憶部を更に有し、
   前記クラス特定部は、
   前記クラス未指定チェックリスト記憶部から前記予定操作と前記関連要素を取得することを特徴とする請求項５に記載のシステム運用操作チェック装置。
7. 前記チェック結果出力部は、
   前記チェッカ構成・実行部が実行した少なくとも一つの前記チェック部品の実行結果と、前記実行可否の前記判定結果を出力することを特徴とする請求項１に記載のシステム運用操作チェック装置。
8. 前記チェック部品記憶部は、
   前記チェック部品を識別するためのチェック部品ＩＤと、前記チェック部品の実体と、前記チェック部品のインタフェース情報とを紐付けた情報としてチェック部品インデックスを記憶することを特徴とする請求項１に記載のシステム運用操作チェック装置。

Images