(57)【要約】【課題】分散システムの障害が影響を及ぼす業務の重要度をリアルタイムに提示し、迅速に、ビジネス上の損失を最小限に抑えることを可能とする。【解決手段】分散システムを統合的に監視する統合管理部２００に加え、システム上で実行される業務とそれを構成するリソースとの関係を所定の情報として管理し、統合管理部からの要求を受けて当該イベントによって影響を受ける業務の情報を返す役割を担う業務影響管理部２１０と、各業務の重要度を所定のルールや評価式に基づいて作成し、統合管理部からの要求に応じて業務の重要度を返す役割を担う重要度管理部２２０を設け、イベントの発生と共に当該イベントによって影響を受ける業務の重要度を統合管理部のイベント表示部２０１に表示する。【選択図】      図２
2005031893.tif 000002
【特許請求の範囲】
【請求項１】
複数の計算機を有する分散コンピュータシステムの運用管理装置における運用管理方法において、前記計算機で実行される業務とその業務が使用するシステムリソース群との対応関係と、障害が発生した前記システムリソースと関係のある業務の情報及び業務の重要度情報とを管理し、前記システムリソースの障害の発生時に、その障害情報と、障害が発生したシステムリソースと関係のある業務の重要度情報とを表示することを特徴とする運用管理方法。
【請求項２】
前記業務の重要度情報は、ビジネス上の損失を考慮に入れた業務重要度を所定のルールに基づいて算出されることを特徴とする請求項１記載の運用管理方法。
【請求項３】
前記所定のルールに基づいた業務の重要度情報の算出は、重要度算出に必要なデータに変数が含まれる場合、前記変数の更新の度に行われることを特徴とする請求項２記載の運用管理方法。
【請求項４】
前記業務の重要度情報は、予め定めた所定のデータとして保持されていることを特徴とする請求項１記載の運用管理方法。
【請求項５】
前記業務の重要度情報は、一部の業務について予め定めた所定のデータとして保持され、その他の業務についてビジネス上の損失を考慮に入れた業務重要度を所定のルールに基づいて算出されることを特徴とする請求項１記載の運用管理方法。
【請求項６】
複数の計算機を有する分散コンピュータシステムの運用管理装置において、システム全体の監視を行うと共に、業務を実行する計算機からのシステムリソース障害をイベント情報として表示する統合管理部と、分散コンピュータシステム上で実行される業務とその業務が使用するシステムリソース群との対応関係を所定の仕様として管理し、前記統合管理部からの問い合わせに応じて、障害が発生したシステムリソースと関係のある業務情報とを提供する業務影響管理部と、前記業務が停止した場合のビジネス上の損失を考慮に入れた業務重要度を所定のルールに基づいて算出し、前記統合管理部からの問い合わせに応じて、業務重要度情報を提供する重要度管理部とを備えたことを特徴とする運用管理装置。
【請求項７】
複数の計算機を有する分散コンピュータシステムの運用管理を行うプログラムであって、計算機で実行される業務とその業務が使用するシステムリソース群との対応関係を所定の仕様として管理する処理ステップと、障害が発生したシステムリソースと関係のある業務の情報及び業務の重要度情報を管理する処理ステップと、システムリソースの障害の発生時に、その障害情報と、障害が発生したシステムリソースと関係のある業務の重要度情報とを表示する処理ステップとを有し、前記各処理ステップを実行することにより、分散コンピュータシステムの運用管理を行うことを特徴とするプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、分散コンピュータシステムの運用管理方法及び装置に係り、特に、業務の重要度をシステムの運用管理に活用することを可能とした分散コンピュータシステムの運用管理技術に関する。
【０００２】
【従来の技術】
近年、インターネットの急速な普及やコンピュータの処理性能の飛躍的な向上等により、コンピュータやその周辺機器が企業等に大きく浸透し、多数の重要な業務がこれらコンピュータシステム上で行われるようになってきている。これに伴い、コンピュータシステム上で発生する障害は、企業の業務、ビジネスに大きな影響をもたらすものとなり、企業全体に散らばった分散コンピュータシステム（以下、分散システムという）を効率良く安全に運用することが企業にとって大きな関心事になっている。
【０００３】
従来、前述したような分散システムの管理は、一般に、統合システム運用管理（以下、運用管理という）製品を利用して行われている。この従来技術は、分散システム上に配置された業務サーバ等の監視対象に対して、エージェントと呼ばれる監視ソフトウェアを配備し、このエージェントを通じて障害や異常発生の情報（以下、イベントという）を中央のイベント監視コンソールに表示して監視するようにしたものである。
【０００４】
図１０は従来技術によるイベント監視コンソールの表示画面の表示例を説明する図、図１１は従来技術によるイベント毎の重要度の算出基準の定義について説明する図である。
【０００５】
従来技術によるイベント監視コンソールには、図１０に示すような情報が表示される。ここで表示される情報は、イベントの発生毎に、障害の重要度１０００、障害の発生時刻１００１、イベントメッセージ１００２を組としたレコードにより構成される。障害の重要度１０００は、イベントである障害の重要度を表す指標、発生時刻１００１は、イベントが発生した時刻、イベントメッセージ１００２は、イベントの内容をそれぞれ示している。例えば、図１０の２行目のレコードは、サーバ０８のメモリ使用率が９５％を超えたというイベント１０２２が２００３年１月１７日の１０時２６分に発生（１０２１）し、その障害の重要度が“緊急”（１０２０）であることを示している。
【０００６】
障害の重要度１０００は、通常、“注意”、“警告”、“緊急”等の多段階に分けられており、図１１に示すようにイベント毎に予め定義されている。ここに示している定義例は、イベント項目１１００、注意１１０１、警告１１０２、緊急１１０３からなり、イベント項目１１００には、ＣＰＵ使用率、メモリ使用率、ディスク使用率、サーバ、アプリケーション等の項目があり、これらの各項目の状態に対して、注意１１０１、警告１１０２、緊急１１０３の障害の重要度が定義されている。例えば、イベント項目のディスク使用率１１３０を見ると、ディスク使用率が７５％を超えたら“注意”、８５％を超えたら“警告”、９０％を超えたら“緊急”のように定義されている。これらは、言い換えれば個々のシステムリソースにおける障害の重大度を表すものであり、運用管理者が監視対象の状態を把握するための指標として利用される。前述した図１０に示すような表示を行うタイプのイベント監視コンソールを「基本タイプ」と定義することとする。
【０００７】
しかし、前述したような「基本タイプ」により表示される障害の重要度は、分散システムの管理という視点で運用管理者が分散システムを管理しやすいように定義したものであり、企業にとっての重要業務への影響を示唆するものではない。従って、複数の障害が同時に発生した場合、前述のように表示される重要度に基づいて管理者が障害に対処したとしても、業務上の損失を最小限に抑えることにはならない恐れがある。
【０００８】
また、近年、分散システムの運用管理にビジネスの視点を取り入れようとする試みがある。この分散システムの運用管理は、分散システム上で実施している業務と、それを構成するサーバ、ストレージ機器、ネットワーク機器、業務アプリケーション、データベース等のコンピュータ機器（以下、リソース）との関係を予め定義しておき、あるリソースに障害が発生した場合、その障害がどの業務に影響を及ぼす可能性があるかをイベント監視コンソールに表示するというものである。
【０００９】
図１２は前述したような従来技術による業務とリソースとの関係を定義した例を説明する図、図１３はリソースの障害がどの業務に影響を及ぼすかをイベント監視コンソールに表示した例を説明する図である。
【００１０】
図１２に示す業務とリソースとの関係を定義した例は、業務Ａ１２００が、サーバ１２０１、１２０２、データベースＡ１２０３、ストレージ１２０４、１２０５、アプリケーション１２０６〜１２０８、ルータ１２０９、１２１０等の合計１０個のリソースによって構成されているシステムにより実行されることを表している。このような定義は、業務毎に行われて備えられている。また、図１３に示す表示例は、図１２に示すリソースの障害がどの業務に影響を及ぼす可能性があるかを表示しており、図示例では、アプリケーションＢ１２０７に障害が発生した場合に、このアプリケーションを構成要素として持つ業務Ａ１２００、業務Ｂ１３００、業務Ｃ１３１０に支障を来たす恐れがあることを示している。前述した図１３に示すような表示を行うタイプのイベント監視コンソールを「障害影響表示タイプ」と定義することとする。
【００１１】
図１３に示す「障害影響表示タイプ」の例は、「基本タイプ」をよりビジネスに近い観点で捉えたものであり、あるリソースにおける障害がどの業務に影響を及ぼすかを把握することは可能であるが、どの業務が企業にとって重要であるかまでは把握することはできない。通常、運用管理者は、分散システム上で行われている個々の業務の重要性までは精通していない。従って、運用管理者は、前記したような「障害影響表示タイプ」のイベント監視コンソールを使用したとしても、複数の障害が同時に発生した場合に、影響の及ぶ可能性のある業務を調べた上で、現在、どの業務が重要であるのかを経営者や各業務の担当者に確認しなければ、障害対処の優先順位を自ら決定することができない。その結果、障害対処に余計な時間を浪費し、ビジネス上の損失を拡大してしまうことになる。
【００１２】
なお、分散システムの利用者から見た業務の重要度への取り組みに関する従来技術として、例えば、特許文献１等に記載された技術が知られている。この従来技術は、システムの運用保守という発想で、業務を構成する構成要素の将来的な動向を予測し、障害発生前にメモリやディスクの増設をする等の対策を打つことを目的としており、分散システム上で今、実際に発生している障害に対する対処を行うという点について考慮されていないものである。
【００１３】
また、他の従来技術として、例えば、特許文献２等に記載された技術が知られている。この従来技術は、時々刻々、大量に発生するイベントに対し、その重要度や内容に応じて自動的に分類・ランク付けを行い発生した障害への対処時間の短縮を試みるというものである。しかし、この従来技術は、考慮される重要度が前述したシステムリソースの障害の重大度を表す重要度であって、その障害によって影響を受ける可能性のある業務がどれであるか、また、その業務の持つ意味やその業務の停止が企業のビジネスへもたらす影響の度合いを考慮したものではない。
【００１４】
【特許文献１】
特開平１０−８３３８２号公報
【００１５】
【特許文献２】
特開平１０−６３５３９号公報
【００１６】
【発明が解決しようとする課題】
前述したように、従来の分散システムに対する運用管理の技術は、そのシステム上で実現されているどの業務がどれほど重要であるかという業務そのものの重要性を考慮して障害対処の優先順位を示唆するまでには至っていない。
【００１７】
このため、従来技術による分散システムの運用管理技術は、複数の障害が発生した場合、図１０により説明したようなイベント監視コンソールが提供する重要度に従って、重要とされるものから順に対処しても、この重要度がビジネス上の重要性を考慮したものではないため、ビジネス上の損失を最小限に抑えることができないという問題点を有している。
【００１８】
本発明の目的は、前述した従来技術の問題点を解決し、どの障害がどの業務に影響を及ぼすかという影響範囲を特定するだけでなく、その業務がどの程度重要な業務であるかをリアルタイムに運用管理者に提示し、熟練しかつビジネスへの理解度の高い運用管理者でなくても、迅速に、かつ、ビジネス上の損失を最小限に抑えた分散システムの運用管理を行うことを可能にした分散システムの運用管理方法及び装置を提供することにある。
【００１９】
【課題を解決するための手段】
本発明によれば前記目的は、複数の計算機を有する分散コンピュータシステムの運用管理装置における計算機運用管理方法において、前記計算機で実行される業務とその業務が使用するシステムリソース群との対応関係と、障害が発生した前記システムリソースと関係のある業務の情報及び業務の重要度情報とを管理し、前記システムリソースの障害の発生時に、その障害情報と、障害が発生したシステムリソースと関係のある業務の重要度情報とを表示することにより達成される。
【００２０】
また、前記目的は、複数の計算機をネットワークにより接続して構成された分散コンピュータシステムの運用管理装置において、システム全体の監視を行うと共に、業務を実行する計算機からのシステムリソース障害をイベント情報として表示する統合管理部と、分散コンピュータシステム上で実行される業務とその業務が使用するシステムリソース群との対応関係を所定の仕様として管理し、前記統合管理部からの問い合わせに応じて、障害が発生したシステムリソースと関係のある業務情報とを提供する業務影響管理部と、前記業務が停止した場合のビジネス上の損失を考慮に入れた業務重要度を所定のルールに基づいて算出し、前記統合管理部からの問い合わせに応じて、業務重要度情報を提供する重要度管理部とを備えたことにより達成される。
【００２１】
【発明の実施の形態】
以下、本発明による分散システムの運用管理方法及び装置の実施形態を図面により詳細に説明する。
【００２２】
図１は本発明の一実施形態による分散システムの運用管理方法によりイベント監視コンソールに表示された表示画面の例を説明する図である。
【００２３】
なお、以下に説明する本発明の実施形態は、図１に示すようなイベントメッセージを表示するタイプのイベント監視コンソールを例としているが、本発明は、それ以外のタイプ、例えば、業務やリソースをアイコンによりツリー構造で表示し、システム全体の障害をＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）上で監視するタイプの監視コンソールであってもよい。
【００２４】
本発明の実施形態は、図１０により説明した従来技術によるイベント監視コンソール画面の代わりに、図１に示すような表示を提供することを可能にしたものであり、図１は、図１０に示している監視状態をそのまま用いて、本発明で提供する業務の重要度を付与したイベント監視コンソールでの表示例である。ここで表示される情報は、イベントの発生毎に、業務の重要度１００、イベントとしての障害の発生時刻１０１、発生したイベントの内容を示すイベントメッセージ１０２を組としたレコードにより構成される。業務の重要度１００は、Ａ、Ｂ、Ｃ、……等として表され、Ａ＞Ｂ＞Ｃ＞……のように重要度がランク付けされる。なお、この表示には、対応する障害により影響を受ける業務の名称を示していないが、必要に応じて障害の影響を受ける可能性のある業務の名称を併せて表示してもよい。
【００２５】
同一の内容を持つイベントについて、図１０に示しているものと図１に示しているものとを比較すると明らかなように、図１０の例で“緊急”１０２０と表示される「サーバ０８のメモリ使用率が９５％を超えた」というイベント１０２２は、図１に示す本発明の実施形態の場合、業務の重要度が“Ｃ”と評価されている。これは、イベント１０２２として発生した「サーバ０８」の障害は、リソースの障害としては重大な障害であっても、重要な業務には使われていないサーバの障害であることを意味している。従って、業務への影響を最小限に抑えるという観点から捉えれば、このイベント１０２２は、図１０に示すような緊急に対処すべき障害では必ずしもないものである。
【００２６】
同様に、図１０に示す“注意”１０３０のレベルでしかなかったイベント「アプリケーション０３のレスポンスの低下」１０３２は、業務への影響を考慮した図１に示す例では、“Ａ”ランクの極めて重要なイベントとして表示されている。このことは、イベント１０３２でレスポンスが低下していると通知された「アプリケーション０３」が重要な業務で使われており、リソースの障害としては重大な障害でなくても、業務への影響を考慮した場合には看過すことができない重要なイベントであることを示している。もし、分散システムを管理する運用管理者が、図１０に示すイベント監視コンソールが示す重要度に従って、“注意”と表示されたイベント１０３２ではなく“緊急”と表示されたイベント１０２２から対処した場合、ビジネス上の損失を拡大させることになり得る。
【００２７】
前述したように、本発明の実施形態による分散システムの運用管理方法によるイベント監視コンソールの表示は、従来技術によるイベント監視コンソールが示す情報からでは見抜くことができないビジネス上の重要な障害を、的確に運用管理者に提示することができる。これにより、運用管理者は、イベントメッセージと共に提供される業務の重要度を判断基準として障害に対処して行くことにより、障害による業務停止で発生する損失を最小限に抑えることが可能となる。
【００２８】
図２は本発明の一実施形態による分散システムの運用管理方法を適用した分散システムの構成を示すブロック図である。図２において、２００は統合管理部、２０１はイベント表示部、２０２はイベント管理部、２０３はイベントデータベース、２１０は業務影響管理部、２１１は関係定義部、２１２は業務定義データベース、２２０は重要度管理部、２２１は重要度データ管理部、２２２はルールテーブル管理部、２２３はテーブルデータ取得部、２２４は業務重要度データベース、２５０、２６０、２７０は業務サーバＡ〜Ｃ、２５１、２６１、２７１はエージェント部、２５２、２６２、２７２はデータベースである。
【００２９】
図２に示す分散システムは、統合管理部２００と、業務影響管理部２１０と、重要度管理部２２０と、監視対象であり業務を実行する複数の業務サーバによる業務サーバ群とが、図示しないネットワークを介して接続されて構成される。業務サーバ群は、業務サーバＡ２５０、業務サーバＢ２６０、業務サーバＣ２７０等の複数の業務サーバからなる。前述の業務サーバは、業務毎に１つのコンピュータ（計算機）が用いられてもよいし、複数の業務が１つのコンピュータ内に構成されてもよい。また、統合管理部２００、業務影響管理部２１０、重要度管理部２２０は、それぞれが１つのコンピュータ（計算機）内に構成されてもよいが、これらは、１つのコンピュータ内に構成されていてもよい。さらに、図２には示していないが、図示していないネットワークに各種の周辺機器が接続されていてもよい。
【００３０】
なお、前述した従来技術における「基本タイプ」のイベント監視コンソールは、業務サーバ群と統合管理部２００とにより構成され、「障害影響表示タイプ」のイベント監視コンソールは、「基本タイプ」の構成に業務影響管理部２１０を追加して構成されることになる。
【００３１】
監視対象となる業務サーバ群を構成する各業務サーバ２５０、２６０、２７０は、各業務サーバを監視するためのエージェント２５１、２６１、２７１が配置され、また、各業務サーバが作成したデータを格納するデータベース２５２、２６２、２７２を備えている。
【００３２】
統合管理部２００は、イベント表示部２０１、イベント管理部２０２、イベントデータベース２０３からなる。イベント表示部２０１は、イベント管理部２０２が保有する情報を図示しないイベント監視コンソールに表示する。イベント管理部２０２は、業務サーバ２５０、２６０、２７０等のエージェント部２５１、２６１、２７１から送信されるイベントを受信し、不要なイベントのフィルタリングや関連イベントを集約する等の必要な処理を実施すると共に、必要に応じて、イベントデータベース２０３に格納する。なお、イベント表示部２０１とイベント管理部２０２とは、別のコンピュータ上に構成し、ネットワークにより接続されていてもよい。
【００３３】
業務影響管理部２１０は、関係定義部２１１と業務定義データベース２１２とからなる。関係定義部２１１は、図１２に示して前述で説明したように、分散システム上で実施される業務とそれを構成するリソースとの関係を定義情報として管理し、業務定義データベース２１２に保管する。また、関係定義部２１１は、統合管理部２００のイベント管理部２０２からの問い合わせに対し、受信したイベントが発生したリソースを構成要素に持つ業務名称のリストをイベント管理部２０２へ返す役割を担う。
【００３４】
重要度管理部２２０は、業務影響管理部２１０で定義されている業務の重要度を作成し、管理する役割を持ち、重要度データ管理部２２１、ルールテーブル管理部２２２、テーブルデータ取得部２２３及び業務重要度データベース２２４から構成される。重要度データ管理部２２１は、統合管理部２００のイベント管理部２０２からの要求に対し、当該イベントにより影響を受ける可能性のある業務について、業務重要度データベース２２４を参照し、業務の重要度を提供する。なお、影響を受ける業務が複数ある場合、それぞれの業務の重要度を比較し、一番重要度の高いものをイベント管理部２０２へ返す。
【００３５】
また、重要度データ管理部２２１は、業務重要度データを作成し、業務重要度データベース２２４に格納する役割も担い、業務重要度が時間や日付等の要因によって変化する場合、所定の間隔で業務重要度データの更新を繰り返し実施し、業務重要度データベース２２４のデータを最新状態に保つ。ルールテーブル管理部２２２は、後述する業務重要度作成のためのルール及び評価式を管理し、実際に業務重要度を算出する役割を持つ。テーブルデータ取得部２２３は、ルールテーブル管理部２２２が業務重要度データを算出する際に、必要に応じて入力パラメータとなるデータを業務サーバ２５０、２６０、２７０などが保持するデータベース２５２、２６２、２７２等から取得する。
【００３６】
次に、重要度管理部２２０が業務重要度データを算出するプロセスについて具体的に説明する。
【００３７】
図３は業務重要度データベース２２４に格納されている業務重要度データの例を示す図、図４はルールテーブル定義表の構成を示す図、図５はルールテーブルの構成を示す図、図６は変数データの最新のものが格納されている場所を示す所在テーブルの構成を示す図、図７は業務の重要度を算出する定義式を示す図である。
【００３８】
業務重要度データベース２２４には、図３に示すような業務重要度データが格納されている。業務重要度データベース２２４は、業務名称３００と業務重要度３０１とにより構成される。業務名称３００は、分散システム上で実施される業務の名称を示し、具体的な項目として、「インターネット販売サイトＡ」３１０、「製品Ａ生産管理システム」３２５等が格納される。これらは、業務影響管理部２１０の業務定義データベース２１２で管理している業務名称と同一でなければならない。図３では、１０種の業務がある場合を例としているが、業務の数は幾つあってもよい。業務重要度３０１は、対応する業務の重要度を示し、Ａ、Ｂ、Ｃ、……等として表され、Ａ＞Ｂ＞Ｃ＞……のように重要度がランク付けされている。図３に示す例では、「インターネット販売サイトＡ」３１０の業務重要度は「Ａ」３１１となっており、重要な業務であることを意味している。
【００３９】
前述の業務重要度３０１は、以下に説明する手順で評価され、算出された結果を格納したものである。
【００４０】
業務重要度３０１の算出は、図４〜図６に示す複数のテーブル及び図７に示す業務重要度評価式を用いて行われる。図４に示すルールテーブル管理表は、図５に示す１つまたは複数存在するルールテーブルを管理するためのデータを保持するものである。図４において、業務名称４００は、業務の名称であり、テーブルＮｏ．４０１は、図５に示す複数のルールテーブルのうち該当する業務が含まれるルールテーブルの番号を示し、評価項目数４０２は、該当する業務の重要度を算出する上で必要な評価項目の数を規定している。例えば、「インターネット販売サイトＡ」３１０という業務は、「１」番目（４１１）のルールテーブルに規定されており、その評価項目が「３」つ（４１２）あることが表されている。
【００４１】
図５に示す各ルールテーブルは、各業務の重要度を決める上で必要な評価項目のリストとなっている。なお、ルールテーブルは、通常、全ての業務を同じ評価項目で規定できるわけではないため、同じ項目で規定することができる業務をグループとし、各業務グループ毎に設けられる。図５には、テーブル名称として、＜テーブル１＞４１１、＜テーブル２＞４２１、＜テーブル３＞４３１を持つ３つのテーブルを示している。
【００４２】
＜テーブル１＞４１１における業務名称５００は、テーブル１で規定される業務の名称を表す項目である。「月平均売上（円）＜Ｐ１１＞」５０１、「キャンペーン期間＜Ｐ１２＞」５０２、「期間中売上率（％）＜Ｐ１３＞」５０３は、テーブル１に含まれる業務の重要度を左右する項目名であり、Ｐ１１、Ｐ１２、Ｐ１３は、表中に与えられたデータを値とする業務重要度の変数である。業務名称「インターネット販売サイトＡ」３１０は、「月平均売上」５０１、「キャンペーン期間」５０２、「期間中売上率」５０３の３つの評価項目で重要度が規定され、その値は、それぞれ「５０，０００，０００」５１１、「１２／１〜１２／２４」５１２、「３０」５１３である。これらの値は、事前に分散システムのユーザから提供された値である。
【００４３】
また、＜テーブル２＞４２１に記述されるれる業務は、「在庫数（個）＜Ｐ２１＞」５４１、「最低在庫数（個）＜Ｐ２２＞」５４２の２つの項目で業務の重要度が規定される。業務名「製品Ａ生産管理システム」３２５は、「在庫数」５４１が  「ｖａｒ＿１」５５１、「最低在庫数」５４２が「１０」５５２となっている。ここで、  「ｖａｒ＿１」５５１は、固定値ではなく変数として与えられており、後述する図６で最新データの格納場所が提供されている。  「ｖａｒ＿２」５６１、  「ｖａｒ＿３」５７１も同様に変数として与えられている。このように、ルールテーブルは、変数の使用が認められており、該当項目が時間や日付で変化するような場合に使用することができる。
【００４４】
前述したようなルールテーブルで変数を使用する場合、図６に示すように最新データの格納場所を予め規定しておかなければならない。図６において、変数名６００は、図５に示すルールテーブルで用いられた変数の名称であり、データ所在６０１は、分散システム上にあるデータの格納場所をパス等により指定したものである。図６に示す例では、  「ｖａｒ＿１」５５１の値が、「ｓｅｒｖｅｒ＿Ｋ￥ｓｅｉｓａｎ￥ｓｅｉｈｉｎ＿Ａ．ｄｂ」  ６１１というパスで指定される場所にあるデータベースに格納されていることを示している。
【００４５】
業務の重要度は、図７に示す定義式（１）〜（３）を使用して算出することができる。例えば、図５に示すテーブル１に含まれる業務についての業務の重要度Ｆ１は、図５に示すテーブル１の中のデータＰ１１、Ｐ１２、Ｐ１３から図７の式（１）より算出することができる。同様に、図５に示すテーブル２に含まれる業務の重要度Ｆ２は、データＰ２１、Ｐ２２と式（２）とから算出することができ、テーブル３に含まれる業務の重要度Ｆ３は、データＰ３１、Ｐ３２と式（３）とから算出することができる。図３に示した各業務の重要度は、図５において、日付が２月２０日（木）で、  ｖａｒ＿１，  ｖａｒ＿２，  ｖａｒ＿３の値がそれぞれ１３、１８、３０の場合を想定し、図７の評価式に適用して得られた結果である。
【００４６】
なお、図５に示すルールテーブル１、３に含まれる業務は、日付や曜日が業務の重要度の算出に関係するため、日付が変わる度に業務の重要度データの更新が必要であり、日付が変わる度に重要度の算出が行われる。
【００４７】
図８は前述した本発明の実施形態における業務サーバでのイベント発生から業務の重要度と共に発生したイベントを表示するまでの処理をシーケンスとして示した図であり、次に、これについて説明する。
【００４８】
（１）業務サーバ２５０、２６０、２７０のエージェント部２５１、２６１、２７１は、自業務サーバ内でリソース不足等のイベントが発生すると、そのイベントの情報と、リソースの情報とを統合管理部２００に送り、統合管理部２００のイベント管理部２０２がこれらの情報を受信する（シーケンス▲１▼）。
【００４９】
（２）統合管理部２００のイベント管理部２０２は、業務とリソースとの関係を管理している業務影響管理部２１０の関係定義部２１１にリソース情報を送信して影響業務の照会を行う（シーケンス▲２▼）。
【００５０】
（３）業務影響管理部２１０の関係定義部２１１は、シーケンス▲２▼での影響業務の照会に対して、受信したイベントが発生したリソースを構成要素に持つ業務名称のリストを、影響業務情報としてイベント管理部２０２へ返し、イベント管理部２０２がこの情報を受信する（シーケンス▲３▼）。
【００５１】
（４）統合管理部２００のイベント管理部２０２は、シーケンス▲３▼で受信した業務について、その業務の重要度を、重要度管理部２２０の重要度データ管理部２２１に問い合わせる（シーケンス▲４▼）。
【００５２】
（５）重要度管理部２２０の重要度データ管理部２２１は、シーケンス▲４▼での問い合わせに対して、業務の重要度データを統合管理部２００のイベント管理部２０２に返送し、統合管理部２００のイベント管理部２０２は、このデータを受信する（シーケンス▲５▼）。
【００５３】
（６）その後、統合管理部２００は、イベント表示部２０１に、シーケンス▲５▼で受信した業務の重要度と対応するイベントとを表示させる。
【００５４】
図９は重要度管理部２２０の重要度データ管理部２２１が業務重要度データベース２２４のデータを更新する処理を説明するフローチャートであり、次に、これについて説明する。
【００５５】
（１）重要度管理部２２０の重要度データ管理部２２１が、業務の重要度データの更新を開始する場合、まず、ルールテーブル管理部２２２が、重要度算出に使用するテーブルデータの更新を開始する（ステップ９０１、９０２）。
【００５６】
（２）テーブルデータ取得部２２３は、重要度を算出するために必要なルールテーブル内の変数データの所在情報を参照して指定の業務サーバのデータベースにアクセスする（ステップ９０３）。
【００５７】
（３）ステップ９０３のアクセスに対して、業務サーバのデータベースが変数のデータを応答として返してくるので、テーブルデータ取得部２２３は、その応答のデータを取得する（ステップ９０４、９０５）。
【００５８】
（４）ルールテーブル管理部２２２は、ステップ９０５で、テーブルデータ取得部２２３が取得した変数データを使用して、テーブルデータを更新する（ステップ９０６）。
【００５９】
（５）ルールテーブル管理部２２２は、更新されたテーブルデータを用いて業務重要度を算出する（ステップ９０７）。
【００６０】
（６）重要度データ管理部２２１は、ステップ９０７の処理でルールテーブル管理部２２２が算出した業務重要度データを、業務重要度データベースへ格納する（ステップ９０８、９０９）。
【００６１】
前述した本発明の実施形態における各処理は、処理プログラムとして構成することができ、この処理プログラムは、ＨＤ、ＤＡＴ、ＦＤ、ＭＯ、ＤＶＤ−ＲＯＭ、ＣＤ−ＲＯＭ等の記録媒体に格納して提供することができる。
【００６２】
前述した本発明の実施形態は、図３に示す業務の重要度を図４〜図６に示す複数のテーブル及び図７に示す業務重要度評価式を用いて算出するものとして説明したが、業務の重要度が算出するまでもなく明白な場合や、ルールテーブルに変数データを含まず、かつ、業務重要度評価式において日時等の変数を含まない場合、本発明は、図３に示す各業務に対応するその業務の重要度を所定のデータとして保持することも可能である。
【００６３】
この場合、例えば、図３に示す業務「インターネット販売サイトＡ」３１０の重要度は算出するまでもなく「Ａ」３１１であるとしてしまってよく、業務重要度算出のプロセスを必要としない。図３で扱う全ての業務に対し、事前に業務重要度を提供することができる場合、図３を所定のデータとして保持し、イベント管理部２０２からの要求に応じて業務重要度を返すだけでよい。この場合、図２に示すルールテーブル管理部２２２とテーブルデータ取得部２２３とは不要である。
【００６４】
また、本発明は、図３に示す各業務の一部の重要度について図４〜図６に示す複数のテーブル及び図７に示す業務重要度評価式を用いて算出し、他の一部の業務に対応する、その業務の重要度を所定のデータとして保持することも可能である。
【００６５】
この場合、例えば、図５に示すルールテーブルにおいて、テーブル３（４３１）の重点期間５８１は、値に日付や曜日といった変数データを含んでいるため、テーブル３で規定される業務の重要度を所定のデータとして提供することができない。しかし、仮にテーブル３に含まれる業務が重点期間５８１に関係なく、信頼喪失度５８２だけで業務の重要度が決まるような業務であるならば、テーブル３で規定される４種類の業務については、その重要度を所定のデータとして提供することができることになる。このような場合、図３に示す業務「顧客向けＷｅｂサイト」３４０、「従業員向けＷｅｂサイト」３４５、「勤休管理システム」３５０、「給与計算システム」３５５については、その重要度を所定のデータとして図３に保持しておき、残りの６種類の業務の重要度が必要になった場合に、図４〜図７に示すテーブル及び評価式から重要度を算出するようにすればよい。
【００６６】
さらに、本発明は、前述で説明した図３に示す業務の重要度を図４〜図６に示す複数のテーブル及び図７に示す業務重要度評価式を用いて算出する本発明の実施形態による分散システムの運用管理方法を、サービス、例えば、分散システムの運用管理サービスを提供するサービスプロバイダに適用することができる。
【００６７】
そして、そのサービスの１つとして、業務重要度に基づいた障害への優先対処をユーザに対して約束し、業務の重要度の高い業務を実施しているユーザに対して、より多くの対価を要求する料金体系を採用するサービスがある。また、本発明を用いて、業務の重要度毎に要した障害対処時間を毎月レポートし、業務の重要度Ａの業務に関する一月当たりの障害対処時間を１時間以内とするなど、業務重要度をＳＬＡ（サービスレベルアグリーメント）の評価項目として利用するサービスを提供することもできる。
【００６８】
前述した本発明の実施形態によれば、従来のイベント監視コンソールが提示するシステム管理上の障害の重要度と異なり、その障害によって影響を受ける可能性のある業務がどれほど重要なものであるかを指標とする業務の重要度を提供することができ、これにより、運用管理者が、イベントメッセージと共に表示される業務重要度を判断基準として障害に対処して行くことができ、分散システムの障害による業務停止で発生する損失を最小限に抑えることが可能となる。
【００６９】
【発明の効果】
以上説明したように本発明によれば、分散システムにおける業務がどの程度重要な業務であるかを運用管理者に提示することにより、運用管理者は、それぞれのシステム障害による業務への影響を考慮した運用管理を実現できる。
【図面の簡単な説明】
【図１】本発明の一実施形態による分散システムの運用管理方法によりイベント監視コンソールに表示された表示画面の例を説明する図である。
【図２】本発明の一実施形態による分散システムの運用管理方法適用した分散システムの構成を示すブロック図である。
【図３】業務重要度データベースに格納されている業務重要度データの例を示す図である。
【図４】ルールテーブル定義表の構成を示す図である。
【図５】ルールテーブルの構成を示す図である。
【図６】変数データの最新のものが格納されている場所を示す所在テーブルの構成を示す図である。
【図７】業務の重要度を算出する定義式を示す図である。
【図８】本発明の実施形態における業務サーバでのイベント発生から業務の重要度と共に発生したイベントを表示するまでの処理をシーケンスとして示した図である。
【図９】重要度管理部の重要度データ管理部が業務重要度データベースのデータを更新する処理を説明するフローチャートである。
【図１０】従来技術によるイベント監視コンソールの表示画面の表示例を説明する図である。
【図１１】従来技術によるイベント毎の重要度の算出基準の定義について説明する図である。
【図１２】前述したような従来技術による業務とリソースとの関係を定義した例を説明する図である。
【図１３】リソースの障害がどの業務に影響を及ぼすかをイベント監視コンソールに表示した例を説明する図である。
【符号の説明】
２００  統合管理部
２０１  イベント表示部
２０２  イベント管理部
２０３  イベントデータベース
２１０  業務影響管理部
２１１  関係定義部
２１２  業務定義データベース
２２０  重要度管理部
２２１  重要度データ管理部
２２２  ルールテーブル管理部
２２３  テーブルデータ取得部
２２４  業務重要度データベース
２５０、２６０、２７０  業務サーバＡ〜Ｃ
２５１、２６１、２７１  エージェント部
２５２、２６２、２７２  データベース
【図１】
2005031893.tif 000003
【図２】
2005031893.tif 000004
【図３】
2005031893.tif 000005
【図４】
2005031893.tif 000006
【図５】
2005031893.tif 000007
【図６】
2005031893.tif 000008
【図７】
2005031893.tif 000009
【図８】
2005031893.tif 000010
【図９】
2005031893.tif 000011
【図１０】
2005031893.tif 000012
【図１１】
2005031893.tif 000013
【図１２】
2005031893.tif 000014
【図１３】
2005031893.tif 000015