JP2009003742A - 業務遅延予測システム - Google Patents

Abstract

【課題】逐次実行される業務プログラムが周期的に実行されることに着目して、日々業務の稼働状態を収集して、過去の稼働傾向から今日までの稼働傾向の増加傾向を比較することで、今後リソースが枯渇（閾値を超える）する時期を予測して、業務の遅延を防止するための事前対処が可能となるシステムを提供する。
【解決手段】監視対象のリソース１０から業務の稼働データを収集して蓄積する稼動データ収集手段２１と、稼動データ収集手段２１が収集した１日単位の業務の稼働データから、稼動基準値を超える連続的な時間のデータを１ブロックとして切り出し、稼動パターンを作成し格納する稼動パターン作成格納手段３１、３２と、過去の稼動パターンを時系列に並べて業務の稼動データの変化推移量を算出し、最新の稼動パターンと変化推移量を基にリソースにおける業務の遅延を予測する遅延予測手段３７とを備える業務遅延予測支援システム１。
【選択図】図１

Description

本発明は、業務遅延予測支援システムに関し、特にリソースが枯渇する時期を予想し、業務の遅延を防止することを支援する、コンピュータリソースの枯渇時期および業務遅延予測システムに関する。

リソースを利用する業務を監視することが行われており、現行の監視システムなどでの監視作業では、例えばサーバのメモリやＣＰＵ（中央処理装置）などのシステムリソースの枯渇（利用率が閾値を超えて、通常運用に耐えられなくなること）を検出すると、リソースの増強などの対処を実施することでシステムの運用ができるように対応を実施している。

しかし、このような従来のリソースの枯渇の対処方法においては、システムリソースの閾値のオーバーの異常を検知した後では、先の現象から業務の遅延などが既に発生してしまっており、システムの運用に少なからず影響を与えてしまう。
これに対して、リソースの稼動傾向から異常に至る予測をする技術が提案されている（例えば、特許文献１参照）。
特開２００５−１８２６９７号公報

上記従来の技術では、業務が稼動しているある時点からの稼動状況の変化から将来の稼動率を予測して、リソースの枯渇時期を求めている。このため、上記従来の技術では、以下の課題がある。
（１）将来の稼動率は、ある一時期からの稼動状況の変化傾向のみから予測するために、実際には、そのある一時期からの稼動状況の変化傾向が継続するという確立が低いので、リソースの枯渇時期が正確に得られないおそれがある。
（２）上記（１）に示す将来の稼動率の予測からでは、リソースの利用状況による遅延などの稼動時間を予測することができない。

そこで、上記課題を解消するために、本発明は、本発明者らは逐次実行される業務プログラムが周期的に実行されることに着目して、日々業務の稼動状態を収集して、過去の稼動傾向から今日までの稼動傾向の増加傾向を比較することで、今後リソースが枯渇（閾値を超える）する時期を予測して、この予測したリソースが枯渇する時期から業務の遅延を防止するための事前対処が可能となる業務遅延予測支援システムを提供することを目的とする。

上記課題を解消するために、本発明は、監視対象のリソースから業務の稼動データを収集する稼動データ収集手段と、前記稼動データ収集手段が収集した１日単位の業務の稼動データから、所定の稼動基準値を超える連続的な時間のデータを、１ブロックとして切り出し、稼動パターンを作成し格納する稼動パターン作成格納手段と、最新の稼動パターンについて、前記稼動パターン作成格納手段が格納する過去の稼動パターンの中からパターンマッチングするものを検索し、パターンマッチングした過去の稼動パターンを時系列に並べて業務の稼動データの変化推移量を算出し、前記最新の稼動パターンと前記業務の稼動データの変化推移量を基に前記リソースにおける業務の遅延を予測する遅延予測手段と、を備える業務遅延予測支援システムである。

また、本発明は、前記遅延予測手段は、前記稼動パターン作成格納手段が格納する過去の稼動パターンを前記最新の稼動パターンと比較し、前記過去の稼動パターンの稼動開始時間と稼動終了時間が許容範囲内に収まっているときパターンマッチングするものと判断し、パターンマッチングした過去の稼動パターンと前記最新の稼動パターンとを比較して、前記リソースの利用率又はプロセス数の増加傾向を求め、通常運用に耐えられなくなる前記リソースの枯渇時期と、業務の遅延傾向を求める業務遅延予測支援システムである。

そして、本発明は、前記遅延予測手段は、前記リソースの枯渇時期を予測する際に、１日の中で複数の前記ブロックがある場合に、前記ブロック毎に同様のブロックを抽出して比較対象とする業務遅延予測支援システムである。

更に、本発明は、前記リソースの枯渇時期の予測および前記業務の遅延予測の分析結果を表示するための端末を備える業務遅延予測支援システムである。

本発明によれば、逐次実行される業務プログラムが周期的に実行されることに着目し、日々業務の稼動状態を収集し、過去の稼動傾向から今日までの稼動傾向の増加傾向を比較することで、今後リソースが枯渇（閾値を超える）する時期を予測し、この予測したリソースが枯渇する時期から業務の遅延を防止するための事前対処が可能となる。

本発明を実施するための最良の形態を、図面を参照して説明する。
本発明の業務遅延予測支援システムの実施例について、図面を用いて説明する。

実施例を説明する。本実施例の業務遅延予測支援システムのシステム構成図を、図１に示す。本実施例の業務遅延予測支援システム１は、監視対象である顧客（お客様）コンピュータ１０に対して接続され、情報収集コンピュータ２０と、予測コンピュータ３０と、運用管理者の操作用の端末４４を備える。

お客様コンピュータ１０は、リソースとしてのＣＰＵ（中央処理装置）、メモリ、その他にＤＩＳＫ、プロセス（図示せず）などを備えている。業務が稼動しているお客様コンピュータ１０では、ＣＰＵの稼動状況が、稼動データＣＰＵとして、データベース（ＤＢ）１１に、日々記録される。同様に、メモリの稼動状況が、稼動データメモリとして、データベース（ＤＢ）１２に、日々記録される。このように、お客様コンピュータ１０は、各リソースに対応した稼動状況を記録するＤＢ１１、１２を備えている。

情報収集コンピュータ２０は、情報収集部２１と稼動データベース（ＤＢ）２２を有している。情報収集部２１は、例えばお客様コンピュータ１０のＤＢ１１に記録されたＣＰＵの稼動状況と、ＤＢ１２に記録されたメモリの稼動状況を収集し、稼動データとして稼動ＤＢ２２に格納するようになっている。

予測コンピュータ３０は、移動パターン作成部３１と、業務実行状況抽出部３２と、稼動パターンデータベース（ＤＢ）３３と、業務実行状況データベース（ＤＢ）３４と、変化推移データベース（ＤＢ）３５と、基準値データベース（ＤＢ）３６と、予測部３７を備える。

移動パターン作成部３１と業務実行状況抽出部３２は、稼動ＤＢ２２に接続されている。稼動パターン作成部３１は、情報収集コンピュータ２０の稼動ＤＢ２２に蓄積されている１日分の稼動データから稼動基準ＷＬの値を超える連続的な時間のデータを稼動パターンである１ブロックとして切り出して、予測コンピュータ３０の稼動パターンＤＢ３３に格納する。予測コンピュータ３０では、本処理を繰り返すことにより、過去（古い日）から最新日までの複数日の稼動パターンが作成される。

業務実行状況抽出部３２は、稼動ＤＢ２２からの稼動データに基づいて業務実行状況を抽出し、業務実行状況を業務実行状況ＤＢ３４に格納する。業務実行状況抽出部３２は、予測コンピュータ３０の稼動パターンＤＢ３３に格納された１ブロックの稼動開始時間から稼動終了時刻までの業務プロセス数を、情報収集コンピュータ２０の稼動データＤＢ２２から抽出し、抽出した業務プロセス数は、予測コンピュータ３０の業務実行状況ＤＢ３４に記録される。

予測部３７は、予測コンピュータ３０の稼動パターンＤＢ３３から、古い日から最新日までの稼動時間帯が同様なブロック同士（開始、終了時間が許容範囲内に収まっているもの）を時系列に並べて比較し、その山の高さ（利用率）の変移、山の幅（時間）の変化推移量を算出し、予測コンピュータ３０の変化推移ＤＢ３５に記録する。

基準値ＤＢ３６に格納されている基準値は、予測部３７に供給される。予測部３７がこの変化推移を分析する際に最新の稼動パターンと過去の稼動パターンを比較する場合に、この基準値が用いられる。

予測部３７は、上述したように求めた稼動時間帯が同様なブロックの稼動状況を、運用管理者の端末４４のディスプレイ４０にグラフで表示させる。予測部３７は、上述したように求めた変化推移量と最新の稼動パターンを基に、リソースが枯渇する時期（利用率が閾値を超えて、通常運用に耐えられなくなる日、すなわち閾値をオーバーする日）を求め、そのリソースの枯渇する時期の推定稼動状況を変化推移ＤＢ３５の変化推移から計算して、グラフ化してディスプレイ４０にグラフ表示させる。

予測部３７は、上述したのと同様に比較したブロックの業務プロセス数の状況を、業務実行状況ＤＢ３４から取り出して、運用管理者の端末のディスプレイ４０にグラフ表示する。

予測部３７は、ディスプレイ４０に表示されたリソースの枯渇する時期の業務プロセス数の状況を、業務実行状況ＤＢ３４から計算して、運用管理者の端末４４のディスプレイ４０にグラフ表示させる。

従って、運用管理者は、上述したようにディスプレイ４０に表示されたディスプレイ４０の表示内容を基にして、リソースの増強、業務スケジュールの変更などを事前対処することで、リソースの枯渇などの問題を未然に防ぐことができる。

次に、図２を参照して、基準値ＤＢ３６における基準値の設定手順を説明する。図２は基準値の設定フローの一例を示している。図２において実線で示すステップは、本実施例の改善支援装置の処理であり、破線で示すステップは運用管理者の作業である。［ｘ−ｎ］は、具体例と対応した番号である。

ステップＳ１では、運用管理者は、各リソース１１，１２の基準値の設定を行う。この基準値とは、後で使用する図７に例示している稼動基準ＷＬと、閾値ＳＬである。ステップＳ２では、基準値ＤＢ３６に基準値情報を登録する。

次に、図３と図４と図５と図６を参照して、稼動パターン作成と、業務実行状況の抽出を説明する。図３は、稼動パターン作成を具体的に示しており、図４は、変化推移の分析例を示している。図５は、稼動パターン作成と、業務実行状況の抽出フローの一例を示している。図６は、稼動パターンの作成フローの一例を示している。

なお、図５と図６においては、実線で示すステップは本発明の実施例の図１に示す改善支援装置の処理であり、破線で示すステップは運用管理者の作業である。［ｘ−ｎ］は、具体例と対応した番号である。図５と図６のフローは、ステップＳ１０〜ステップＳ１７を有しているが、図５と図６に示す作業は、逐次実行される業務プログラムが周期的に実行されることに着目して、１日に１回定期的に実行する。

まず、図３と図５に示すように、稼動パターンの作成、すなわち稼動しているブロックの抽出を行う。図５のステップＳ１０では、図３の［Ａ−１］に示すように、稼動ＤＢ１３，１４から、前日１日分の稼動データ１００を求める。ステップＳ１１では、図３の［Ａ−２］に示すように、基準値ＤＢ３６から、リソース特定と稼動基準値１０１を求める。リソースの例としては、サーバのＣＰＵ１１やメモリ１２であり、稼動基準値１０１としては、稼動基準値、稼動継続基準、閾値、開始許容時間、終了許容時間である。

ステップＳ１２では、１日分のリソースの処理が終了したら、ステップＳ１３に移り、図３の［Ａ−１］に示す稼動ＤＢ１３，１４から１日分の業務プロセス数を抽出して、図３の［Ａ−４］に示すように業務実行状況ＤＢ３４に１日分の業務プロセス数を記録して終了する。すなわち、業務実行状況の抽出では、ブロック毎にプロセス数の状況を抽出して業務実行状況ＤＢ３４に１日分の業務プロセス数を記録する。

これに対して、ステップＳ１２において１日分のリソースの処理が終了していない場合には、ステップＳ１４において図３の［Ａ−２］に示す稼動状況が稼動基準値を超えているかどうかをみて、超えている場合には、図３の［Ａ−２］に示す稼動継続基準を超えているかをみる。

ステップＳ１５において稼動継続基準を超えていない場合には、ステップＳ１２に戻るが、ステップＳ１５において稼動継続基準を超えている場合には、稼動パターン作成処理（図６に示す稼動パターン作成フローによる処理）を行い、ステップＳ１２に戻る。

ステップＳ１４において図３の［Ａ−２］に示す稼動状況が稼動基準値を超えていない場合には、ステップＳ１７に移り、稼動していない状態として、稼動開始時刻をクリア処理して、ステップＳ１２に戻る。

ここで、図３と図６を参照して、稼動パターン作成処理を説明する。図６は、稼動パターン作成フローを示しており、ステップＳ３０〜ステップＳ３６を有している。
ステップＳ３０では、図３の［Ａ−３］に示す稼動パターンＤＢ３３に対して稼動開始日時を記録する。ステップＳ３１では、図３の［Ａ−１］に示す稼動ＤＢ１３，１４から稼動開始〜現在までの稼動状況を抽出して、図３の［Ａ−３］に示す稼動パターンＤＢ３３に記録する。

ステップＳ３２では、図３の［Ａ−１］に示す稼動ＤＢ１３，１４から次の稼動状況を抽出する。ステップＳ３３では、１日分のリソースの処理終了かどうかをみて、処理が終了であればステップＳ３４に移り、図３の［Ａ−３］に示す稼動パターンＤＢ３３に稼動終了日時を記録する。

そうでなく、ステップＳ３３において、１日分のリソースの処理が終了していなければ、ステップＳ３４に移る。ステップＳ３４では稼動状況が図３の［Ａ−２］に示す稼動基準値を超えている場合には、ステップＳ３６に移り、図３の［Ａ−１］に示す稼動ＤＢ１３，１４から１レコード分の稼動状況を、図３の［Ａ−３］に示す稼動パターンＤＢ３３に記録する。ステップＳ３４において、稼動状況が図３の［Ａ−２］に示す稼動基準値を超えていない場合には、ステップＳ３５に移り、図３の［Ａ−３］に示す稼動パターンＤＢ３３に稼動終了日時を記録する。

このように、図３の［Ａ−３］に示す１日分の各１つの稼動ブロック１５０の稼動パターンは、稼動開始日時と稼動終了日時を記録している。各ブロック１５０は、稼動データ１００において稼動基準値を連続して超えている稼動データを１ブロックとして抽出することで得られる。図３に示すように、１つのブロック１５０の抽出イメージとしては、例えば図３に例示する通りである。

図３に例示するようにブロック抽出イメージのグラフ１７０は、縦軸を利用率として、横軸を時間としている。このグラフ１７０には、閾値ＳＬと稼動基準ＷＬが記載されており、このグラフには利用率変化曲線２００が示されている。この利用率変化曲線２００が稼動基準ＷＬを越えている部分２０１，２０２，２０３，２０４は、デジタル化されて１つの稼動ブロック３０１，３０２，３０３，３０４として抽出される。この稼動ブロック３０１，３０２，３０３，３０４は、例えば２００７年３月１０日の分である。

図４は、稼動パターンの変化推移の分析例を示している。図４では、最新日の稼動パターン１２０と過去の稼動パターン１３０とのパターンマッチングの例を示している。デジタル化されている最新日の稼動パターン１２０とデジタル化されている過去の稼動パターン１３０のパターンマッチングの対象となるのは、開始時間と終了時間が許容範囲内に収まっているブロックである。最新日の稼動パターン１２０と過去の稼動パターン１３０は、例えば１０：００ではなく、１０：０５の開始時間に合わせ、そして１０：５０ではなく１０：４５の終了時間に合わせてマッチングを取る。そして、最新日の稼動パターン１２０と過去の稼動パターン１３０とのデジタル値の差から、増加推移（増加傾向）２５０を求めることができる。この増加推移２５０は、２００７年３月９日から２００７年３月１０日の増加推移であり、増加推移２５０は変化推移ＤＢ３５において変化推移２５１として格納される。

次に、図３、図４、図７および図８を参照して、リソース枯渇予測と、業務遅延予測について説明する。図７は、リソースの枯渇予測および業務遅延の支援の例を示しており、ディスプレイ４０には、リソース枯渇、業務遅延予測表示、およびプロセス数の傾向表示用の画面４００が表示されている。図７に示す画面４００では、リソースの枯渇予測および業務遅延の支援を示すグラフ５００と、プロセス数の傾向を示すグラフ６００を表示している。

グラフ５００では、縦軸が利用率Ｒで、横軸が時間であり、閾値ＳＬと稼動基準ＷＬを示している。グラフ５００には、３月８日の利用率変化曲線５０１と、３月９日の利用率変化線５０２と、３月１０日の利用率変化曲線５０３と、そして３月１５日の利用率の予測線を表示している。これにより、３月１５日には、利用率Ｒが閾値ＳＬを越えてしまい、遅延時間としては１０分間生じることが予測できる。

グラフ６００では、縦軸がプロセス数Ｐで、横軸が時間である。グラフ６００には、３月８日のプロセス数変化曲線６０１と、３月９日のプロセス数変化線６０２と、３月１０日のプロセス数変化曲６０３と、そして３月１５日のプロセス数の予測線を表示している。これにより、３月１５日には、プロセス数が増加して、遅延時間としては１０分間生じることが予測できる。

図８は、リソース枯渇予測と、常務遅延予測を示すフローであり、ステップＳ４０〜ステップＳ４８を有している。実線で示すステップは本発明の実施例の図１に示す改善支援装置の処理であり、破線で示すステップは運用管理者の作業である。［ｘ−ｎ］は、具体例と対応した番号である。

ステップＳ４０では、図３の［Ａ−３］に示す稼動パターンＤＢ３３から最新日の稼動パターンを取り出す。ステップＳ４１では、１日分の稼動パターン予測が終了すれば処理が終わる。そうでなく、ステップＳ４１において１日分の稼動パターン予測が終了していなければ、ステップＳ４２に移り、図３の［Ａ−３］に示す稼動パターンＤＢ３３から過去の稼動パターンを取り出す。図４に示す例では、最新日の稼動パターン１２０は、２００７年３月１０日のものであり、過去の稼動パターン１３０は、２００７年３月９日のものである。

ステップ４３では、図４の［Ａ−３］に示す稼動パターンＤＢ１３，１４と図４の［Ａ−２］に示す基準値ＤＢ３６から、最新日の稼動パターン１２０と過去の稼動パターン１３０が同一かどうか、すなわち稼動期間が許容範囲かを判断して、稼動期間が許容範囲でなければステップＳ４２に戻る。そうでなく、ステップＳ４３における稼動期間が許容範囲であればステップＳ４４に移り、比較対象が１０日分揃ったか、もしくは過去の稼動データの終了でなければステップＳ４２に戻るが、比較対象が１０日分揃ったか、もしくは過去の稼動データの終了であれば、ステップＳ４５に移る。

ステップＳ４５では、図７の［Ａ−６］に示すように、稼動パターンが同一の稼動パターンをグラフ５００を表示する。ステップＳ４６では、図４の［Ａ−５］に示す変化推移ＤＢ３５の変化量の推移から、閾値を超える日を予測して、図７の［Ａ−６］に示すように、その日の稼動パターンをグラフ５００において、例えば２００７年３月１５日の予測線５０１を表示する。

ステップＳ４７では、稼動パターンが同一の稼動パターンの開始から終了までのプロセス数を、図３の［Ａ−４］に示す業務実行状況ＤＢ３４から取り出して、図７の［Ａ−６］に示すように、グラフ６００を表示する。
ステップＳ４８では、稼動パターンの稼動期間の推移から許容範囲を超える日を予測し、図７の［Ａ−６］に示すように、その日のプロセス数の変化傾向をグラフ６００には、例えば２００７年３月１５日の予測線６０１を表示して、ステップＳ４０に戻る。

このようにして、リソース枯渇予測と遅延予測では、１ブロックの稼動パターンをグラフ化して、１ブロックの稼動パターンが閾値をオーバーする日を変化推移ＤＢ３５から求めて、図７の［Ａ−６］に示すように、グラフ表示する。稼動時間帯の変化推移から遅延予測を行って、図７の［Ａ−６］に示すように、グラフ５００に予測線５０１として表示することで反映する。

また、プロセス数の変化予測では、稼動パターンの時間帯でのプロセス数の推移を業務実行状況ＤＢ３４から取り出して、図７の［Ａ−６］に示すように、グラフ６００に予測線６０１として表示することで反映する。リソース枯渇予測日のプロセス数を予測して、過去からの変化推移から予測して、図７の［Ａ−６］に示すように、グラフに表示する。

これにより、図７に示すように、利用率Ｒが、予め設定してある閾値ＳＬに到達する日を予測することで、図１の運用管理者は事前にリソースの増強などの対処を事前に行うことができる。また、図７に示すように、同様に稼動パターンの変化推移、すなわち稼動パターンの時間幅の広がりから、業務の遅延傾向を求め、遅延の許容値を超える時期も予想可能である。従って、リソースの枯渇予測、業務遅延予測により、リソースの支援システムや業務に異常が発生する前に対処が可能になる。

以上実施例で説明したが、本発明の業務遅延予測支援システムによれば、逐次実行される業務プログラムが周期的に実行されることに着目しており、日々のリソースの稼動状況から１日の稼動傾向を稼動パターンとしてパターン化して、過去から現在までのいつもの稼動傾向を求める。そして、過去の稼動パターンから現在の稼動パターンを積み重ねることにより、１日毎の変化量の変化推移からリソースの枯渇時期を予測する。

また、本発明のリソースの支援システムは、監視対象としてのお客様コンピュータ１０のリソース１１，１２についての業務の稼動データを、監視対象から収集して蓄積する情報収集コンピュータ２０と、情報収集コンピュータ２０からの稼動データから、稼動基準値を超える連続的な時間を１ブロック１５０として切り出して格納して、複数日の１日毎の稼動パターンを作成し、過去の稼動パターンと最新の稼動パターンを比較して差を取ることで過去の稼動パターンから最新の前記稼動パターンまでの増加傾向を得て、通常運用に耐えられなくなる日を予測する予測コンピュータ３０と、を備える。これにより、逐次実行される業務プログラムが周期的に実行されることに着目して、日々業務の稼動状態を収集して、過去の稼動傾向から今日までの稼動傾向の増加傾向を比較することで、今後リソースが枯渇（閾値を超える）する時期を予測して、この予測したリソースが枯渇する時期から業務の遅延を防止するための事前対処が可能となる。過去からの稼動パターンの変化推移から、リソースが枯渇する時期が予測可能である。同様に、過去からの稼動パターンの変化推移から、業務遅延の許容値を超える時期が予測可能である。リソースの枯渇予測、業務遅延予測により、運用管理者はシステムや業務に異常が発生する前に対処が可能になる。

また、予測コンピュータ３０は、過去の稼動パターンから最新の稼動パターンを比較する際に、１ブロックの稼動開始時間と稼動終了時間が許容範囲内に収まっている場合に同様なブロックと判断して、過去のブロック１３０から最新のブロック１２０同士を比較して、リソースの利用率およびリソースのプロセス数の増減傾向から、通常運用に耐えられなくなるリソースの枯渇時期と、業務の遅延傾向を求める予測部３７を、有する。これにより、過去の稼動パターンから最新の稼動パターンを比較する際に、１ブロックの稼動開始時間と稼動終了時間が許容範囲内に収まっている場合に同様なブロックと判断するので、過去のブロックと最新のブロックにおける比較精度を上げることができる。

予測コンピュータ３０は、リソースの枯渇時期を予測する際に、１日の中で複数のブロックがある場合には、ブロック毎に同様のブロックを抽出して比較対象とする。これにより、１日の中で複数のブロックがあっても、ブロックごとに同様のブロックを抽出できるので、過去のブロックと最新のブロックの比較がより確実にできる。

リソースの枯渇時期の予測および業務の遅延予測の分析結果を表示するための端末４４を備える。これにより、運用管理者は端末４４の画面を見ることでリソースの枯渇時期の予測および業務の遅延予測の分析結果を視覚的に把握できる。

ところで、本発明は上記実施例に限定されず、例えば、本発明の業務遅延予測支援システムは、例えばマネージメントにおける予兆、予測のために適用できる。また、図１に示す例では、監視対象であるお客様コンピュータが１台示されているが、これに限らず、複数台のお客様コンピュータの日々業務の稼動状態を収集して、過去の稼動傾向から今日までの稼動傾向の増加傾向を比較することで、今後リソースが枯渇（閾値を超える）する時期を予測して、この予測したリソースが枯渇する時期から業務の遅延を防止するための事前対処ができるようにしても良い。

実施例の業務遅延予測支援システムのシステム構成の説明図。 実施例における基準値の設定フローを示しているフローの一例の説明図。 実施例における稼動パターン作成の一例の説明図。 実施例における変化推移の分析例の説明図。 実施例における稼動パターン作成と、業務実行状況の抽出フローの一例の説明図。 実施例における稼動パターン作成フローの一例の説明図。 実施例におけるリソース枯渇、業務遅延予測表示およびプロセス数の傾向表示用の画面の一例の説明図。 実施例におけるリソース枯渇予測と、常時遅延予測を示すフローの一例の説明図。

符号の説明

１ 業務遅延予測支援システム
１０ お客様コンピュータ（監視対象）
１１，１２ データベース
２０ 情報収集コンピュータ（情報収集手段）
３０ 予測コンピュータ（予測手段）
３３ 稼動パターンデータベース
３４ 業務実行状況データベース
３５ 変化推移データベース
３６ 基準値データベース
４０ 端末のディスプレイ
４４ 端末
１２０ 最新日のブロック
１３０ 過去のブロック
４００ 表示画面
５００ 利用率と時間の関係を示すグラフ
６００ プロセス数と時間の関係を示すグラフ

Claims (4)

1. 監視対象のリソースから業務の稼動データを収集する稼動データ収集手段と、
   前記稼動データ収集手段が収集した１日単位の業務の稼動データから、所定の稼動基準値を超える連続的な時間のデータを、１ブロックとして切り出し、稼動パターンを作成し格納する稼動パターン作成格納手段と、
   最新の稼動パターンについて、前記稼動パターン作成格納手段が格納する過去の稼動パターンの中からパターンマッチングするものを検索し、パターンマッチングした過去の稼動パターンを時系列に並べて業務の稼動データの変化推移量を算出し、前記最新の稼動パターンと前記業務の稼動データの変化推移量を基に前記リソースにおける業務の遅延を予測する遅延予測手段と、
   を備えることを特徴とする業務遅延予測支援システム。
2. 前記遅延予測手段は、前記稼動パターン作成格納手段が格納する過去の稼動パターンを前記最新の稼動パターンと比較し、前記過去の稼動パターンの稼動開始時間と稼動終了時間が許容範囲内に収まっているときパターンマッチングするものと判断し、パターンマッチングした過去の稼動パターンと前記最新の稼動パターンとを比較して、前記リソースの利用率又はプロセス数の増加傾向を求め、通常運用に耐えられなくなる前記リソースの枯渇時期と、業務の遅延傾向を求める請求項１に記載の業務遅延予測支援システム。
3. 前記遅延予測手段は、前記リソースの枯渇時期を予測する際に、１日の中で複数の前記ブロックがある場合に、前記ブロック毎に同様のブロックを抽出して比較対象とする請求項２に記載の業務遅延予測支援システム。
4. 前記リソースの枯渇時期の予測および前記業務の遅延予測の分析結果を表示するための端末を備える請求項３に記載の業務遅延予測支援システム。

Images