システム改善支援システム
【課題】 対象システムの問題点を特定していくに際して対象システムに課せられる負荷を必要最小限に留めて、対象システムを利用するユーザへのサービスの低下を防止しながら、システム改善案を提示することができるシステム改善支援システムを提供する。
【解決手段】 システム改善支援システム１は、構成要素２１〜２４監視項目について監視する監視装置２６を備えた対象システム２０を、監視装置２５によって得られた構成要素２１〜２４の稼働情報に基づいて、問題を指摘し改善案を提示するという支援及び行う。評価装置７において、監視対象とされた構成要素が当該構成要素の稼働情報に基づいて性能劣化しているか否かを判定する性能判定処理が行われ、性能判定処理において構成要素が性能劣化と判定されるときのみ構成要素が依存する構成要素を更なる監視対象として自動追加する自動追加処理が行われる。したがって、システムの監視負担が軽減される。
【解決手段】 システム改善支援システム１は、構成要素２１〜２４監視項目について監視する監視装置２６を備えた対象システム２０を、監視装置２５によって得られた構成要素２１〜２４の稼働情報に基づいて、問題を指摘し改善案を提示するという支援及び行う。評価装置７において、監視対象とされた構成要素が当該構成要素の稼働情報に基づいて性能劣化しているか否かを判定する性能判定処理が行われ、性能判定処理において構成要素が性能劣化と判定されるときのみ構成要素が依存する構成要素を更なる監視対象として自動追加する自動追加処理が行われる。したがって、システムの監視負担が軽減される。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、対象システムの稼働情報を監視して、その結果に基づいて対象システムの改善案を提示することをシステム的に可能にするシステム改善支援システムに関する。
【背景技術】
【０００２】
従来、いくつかの構成要素から成る対象システムの稼働状態を当該対象システムに備わる監視装置によって監視し、得られた対象システムの稼働情報を専用回線やインターネット等の通信手段を通じて収集し、対象システムに生じた問題点を改善・支援するシステム改善支援システムが知られている。システム改善支援システムは、対象システムの外部に置かれており、複数の顧客の対象システムを対象として改善・支援サービスを提供することができる。
【０００３】
既存のシステム改善支援システムの構成の一例が、図１８に示されている。図１８を参照すると、対象システム２０は、一つ又は複数の構成要素２１〜２４（ここでは４つの構成要素を示したが、これは説明を簡略にするためであって、通常は相当の数の構成要素を備える）、これらの構成要素２１〜２４を監視する監視装置２５、及び構成要素２１〜２４についての監視項目が登録されている監視項目データベース２６から成っている。監視装置２５は、監視項目データベース（「データベース」は「ＤＢ」と略す。以下同じ）２６にアクセスし、そこに登録されている監視項目に従って、対象システムの構成要素２１〜２４を監視している。
【０００４】
対象システムのシステム構成の一例が、図１９に示されている。図１９に示す対象システム２０は、ポータルサーバ（ＷＥＢサーバ。以下、括弧内は分類名）と、ポータルサーバに繋がるＭＡＩＬサーバ（メールサーバ）とＭＡＩＬ＿ＤＢサーバ（ＤＢサーバ）、及びＳＣＨＥＤＵＬＥサーバ（スケジュールサーバ）とＳＣＨＥＤＵＬＥ＿ＤＢサーバ（ＤＢサーバ）とを備えている。
【０００５】
一方、対象システム２０の改善を行うシステム改善支援システム１０が、ネットワークや通信回線を通じて対象システムに繋がっている。監視項目ＤＢ２６において登録される監視項目は、システム改善支援システム１０の入力装置２を操作することによって追加、削除、変更が可能である。監視装置２５が監視することで取得・収集・蓄積された対象システム２０の稼働情報は、システム改善支援システム１０の収集装置３に送られて、稼働情報ＤＢ４に蓄積される。システム改善者は、稼働情報ＤＢ４にアクセスし、出力装置５によって対象システム２０の構成情報や稼働情報をモニタ又はプリントさせることができる。システム改善者は、構成情報や稼働情報に基づいて対象システム２０の分析と改善を提案することができる。
【０００６】
上記のシステム改善支援システム１０は、監視装置２５がすべての構成要素２１〜２４を決められた順序で監視して回り、しかもシステム改善支援システム１０との間のデータの遣り取りを行っている。一方、対象システム２０の稼働能力や通信能力は時間経過とともに劣化するのは避けられない。対象システム２０のＣＰＵや通信回線が負う負荷については無視できないものがあり、その結果、監視装置２５の監視作業負担に起因して、ユーザが使用可能なシステム能力が低下し、ユーザの通常業務に影響が出るのが避けられないという問題がある。
【０００７】
顧客へのサービスの管理の一例として、サービス構成情報とサービスレベル契約と、サービスレベル管理レポートの設定に基づき、自動的にサービス毎のサービス品質の算定を行い、運用者又は顧客へ提示するサービス管理レポートを作成するサービス管理方法及びシステムが提案されている（特許文献１）。このサービス管理方法及びシステムによれば、サービス構成情報（ネットワーク機器とサービスとの組合せ情報）、サービスレベル契約情報、ネットワーク機器からのアラーム情報をもとに、サービス単位に品質を算出し、サービス管理レポートを提出している。
【特許文献１】特開２００１−３２０３７０号公報（段落［００２２］〜［００４２］、図３、図4）
【発明の開示】
【発明が解決しようとする課題】
【０００８】
そこで、複数の構成要素から構成される対象システムの各構成要素の稼働状態を監視し、その結果に基づいてシステム改善案を作成するシステム改善支援システムにおいて、監視対象となる構成要素が性能劣化を生じた際にその原因となっている対象システムの問題点を特定するに当たって、下位の構成要素への劣化原因の探索程度を限定する方策を採ることで、対象システムの負荷を必要最小限に留めることを可能にする点で解決すべき課題がある。
【０００９】
この発明の目的は、構成要素が性能劣化を生じたときに対象システムの問題点を特定していくに際して、対象システムに課せられる負荷を必要最小限に留めて、対象システムを利用するユーザへのサービスの低下を防止しながら、システム改善案を提示することができるシステム改善支援システムを提供することである。
【課題を解決するための手段】
【００１０】
上記の課題を解決するため、この発明によるシステム改善支援システムは、複数の構成要素及び前記各構成要素をその監視項目について監視する監視装置を備えた対象システムを前記監視装置によって得られた前記構成要素の稼働情報に基づいて改善するのを支援するシステム改善支援システムであって、監視対象とされた前記構成要素が当該構成要素の前記稼働情報に基づいて性能劣化しているか否かを判定する性能判定処理と、前記性能判定処理において前記構成要素が性能劣化と判定されるときのみ前記構成要素が依存する前記構成要素を更なる前記監視対象として自動追加する自動追加処理とを行うことから成っている。
【００１１】
このシステム改善支援システムによれば、性能判定処理において、ユーザが利用するシステムの監視対象とされた構成要素が当該構成要素の稼働情報に基づいて性能劣化しているか否かを判定する。そして、性能判定処理において構成要素が性能劣化と判定されるときのみ構成要素が依存する構成要素を更なる監視対象として自動追加する自動追加処理が行われる。したがって、監視装置が常時、すべての構成要素を決められた順序で監視して回るのと異なり、監視対象の経時変化等に起因した性能劣化時のみ、その監視対象が依存する構成要素を更なる監視対象として追加する。対象システムの問題点を特定するに当たってこうした劣化原因の探索範囲と深さを限定する対処の仕方によって、対象システムが探索のために負う負担が軽減され、対象システムを利用するユーザへのサービス低下を防止することができる。
【００１２】
このシステム改善支援システムにおいて、前記自動追加処理において前記監視対象として前記構成要素が追加されたとき、追加された前記構成要素についての前記性能判定処理と、当該構成要素が性能劣化と判定されるときに当該構成要素が依存する前記構成要素を更なる前記監視対象に追加する前記自動追加処理とを繰り返して行うことができる。こうした性能判定処理と自動追加処理とを繰り返すことにより、探索範囲と深さが可及的に限定され、対象システムへの負荷を軽減した状態で劣化原因の探索が繰り返される。
【００１３】
上記の性能判定処理と自動追加処理とを繰り返すシステム改善支援システムにおいて、前記監視対象として追加された前記構成要素が性能劣化していないと前記性能判定処理において判定されるとき、当該構成要素を前記監視対象から削除する監視対象削除処理を行うことが好ましい。監視対象として複数の構成要素が追加されることがあるが、追加された構成要素のうち性能劣化していないものが存在し得る。性能判定処理において性能劣化していないと判定される構成要素については監視対象から削除する監視対象削除処理が行われる。したがって、監視対象が追加される際に、監視対象となる構成要素の数の増加を緩和させることができ、監視に要する対象システムの負荷の増大を抑制することができる。
【００１４】
上記の繰り返される一連の前記自動追加処理において、前記監視対象削除処理で前記監視対象から削除された前記構成要素については、前記監視対象として自動追加しないことが好ましい。監視対象削除処理において監視対象から削除された構成要素については、性能判定処理において性能劣化しているか否かの監視対象として自動追加しないことで、監視に要する対象システムの負荷を軽減することができる。
【００１５】
上記システム改善支援システムにおいて、前記対象システムを利用するエンドユーザに最も近い前記構成要素のみを、前記監視装置による監視開始初期における初期監視対象とすることができる。対象システムの監視に際して対象システムを利用するエンドユーザに最も近い構成要素のみを初期監視対象とすることにより、監視開始初期の段階において監視に要する対象システムの負荷を軽減することができる。
【００１６】
上記初期監視対象を特定するシステム改善支援システムにおいて、前記初期監視対象とされた前記構成要素の性能劣化が正常値に改善されたとき、当該構成要素以外のすべての前記構成要素についての前記監視装置による監視を終了することが好ましい。初期監視対象とされるエンドユーザに最も近い構成要素の性能劣化が正常値に改善されたときは、初期監視対象以外の構成要素の監視をする必要がないと判断される。したがって、エンドユーザに最も近い構成要素以外の構成要素についての監視を終了することで、監視に要する対象システムの負荷を軽減することができる。
【００１７】
上記初期監視対象を特定するシステム改善支援システムにおいて、前記初期監視対象が前記性能判定処理において性能劣化と判定されるときに、その旨をシステム改善者にメールにて自動送信することが好ましい。システム改善者への自動メール送信によって、システム改善者は対象システムに問題が生じていることを早期に知ることができる。
【００１８】
上記システム改善支援システムの自動追加処理において、前記対象システムに備わっていて前記各構成要素の前記監視項目を登録可能であり且つ前記監視装置が監視する前記構成要素について前記監視項目を提供する監視項目データベースに、更なる前記監視対象となる前記構成要素とその監視項目とを自動追加することができる。システム改善支援システムは、その自動追加処理において、対象システムに備わる監視項目データベースをそのまま利用して、更なる監視対象となる構成要素とその監視項目とを自動的に追加させることができる。
【００１９】
上記システム改善支援システムの性能判定処理において、前記監視項目毎の目標基準値が予め記憶されている目標基準値テーブルを備えており、前記性能判定処理において、前記構成要素が性能劣化しているか否かを、当該構成要素の前記稼働情報が前記目標基準値テーブルに記憶されている前記目標基準値と比較・評価することで判定することができる。予め目標基準値テーブルに監視項目毎の目標基準値として記憶させていることにより、構成要素が性能劣化しているか否かは、構成要素の稼働情報を目標基準値テーブルの目標基準値と比較・評価することで直ちに判定することができる。
【発明の効果】
【００２０】
この発明によるシステム改善支援システムは、上記のように監視対象とされた構成要素が当該構成要素の稼働情報に基づいて性能劣化しているか否かを判定する性能判定処理と、当該性能判定処理において構成要素が性能劣化と判定されるときのみ当該構成要素が依存する構成要素を更なる監視対象として自動追加する自動追加処理とを行う構成とされているので、下位の構成要素への劣化原因の探索程度が限定され、対象システムの問題点を特定していくに際して対象システムに課せられる負荷を必要最小限に留めることができる。したがって、対象システムを利用するユーザへのサービスの低下を防止しながら、システム改善案を提示することができる。
【発明を実施するための最良の形態】
【００２１】
以下、添付した図面に基づいて、この発明によるシステム改善支援システムの実施例を説明する。図１はこの発明によるシステム改善支援システムのシステム構成図である。ここでは、「構成要素」は、サーバ、ネットワーク機器、各機器の中で稼働するソフトウェア等の要素を示す。「構成情報」は、（ａ）各構成要素の関係をサービス観点で表した論理的な構成としてのサービス構成、（ｂ）サーバのＩＰアドレス・ホスト名・型名及びソフトウェアの名称等から成る各構成要素の詳細、（ｃ）ＣＰＵ稼働率・メモリ使用量、応答時間等の各構成要素の安定稼働を表す指標値としての、各構成要素の稼働に関する目標値、並びに（ｄ）「ソフトウェアＡはサーバＢ上で稼働している」、「ソフトウェアＣはポートＤを利用している」等で表される各構成要素間の依存関係から成っている。また、「監視対象」は、稼働情報の監視対象となる構成要素を指す。「監視項目」は、「サーバＥはＣＰＵ稼働率・メモリ使用量」、「ネットワーク機器Ｆは応答時間」等の、構成要素の品質を評価するための項目を指す。更に、「目標値」は、「サーバＧのＨＴＴＰ応答時間の目標値は２秒以内」等の、構成要素の品質が正常であると判断する値であって、監視項目毎に設定される値をいう。
【００２２】
システム改善支援システムの構成が、図１に示されている。図１に示すように、システム改善支援システム１は、図１８に示す既存のシステム１０と比較して、構成情報ＤＢ６、評価装置７、システム改善者ＤＢ８及びメール送信装置９を新たに備えている。対象システム２０の構成及びシステム改善支援システム１のうち既存のシステム改善支援システム１０と共通する構成については、既に説明したとおりであるので、再度の説明を省略する。
【００２３】
図２には、図１に示すシステム改善支援システム１の（１）システム改善者ＤＢ８、（２）構成情報ＤＢ６及び（４）稼働情報ＤＢ４、（３）対象システム２０の監視項目ＤＢ２６についてのデータ構造が示されている。システム改善者ＤＢ８においては、システム改善者テーブルが用意され、一例として、図示のように改善者名とメールアドレスがデータとして設定されている。構成情報ＤＢ６においては、システムを構成する構成要素の分類名、監視項目、及び目標基準値のデータから成る監視目標基準値テーブルが用意される。分類名のものが正常か異常かについては、監視項目とされる事項が目標基準値（２秒以内）を満たすか否かによって判定される。構成情報ＤＢ６には、その外に、構成要素一覧テーブル、構成要素属性テーブル、依存関係テーブルがあり、それぞれ図示されているテーブル構造を持つ。特に、依存関係テーブルでは、依存先構成要素分類に応じて依存先監視項目（ＣＰＵ使用率、メモリ使用量）が定められている。監視項目ＤＢ２６及び稼働情報ＤＢ４は、既存のシステム１０，２０でも備わっているＤＢであるが、監視項目ＤＢ２６では構成要素毎に監視項目が設定され、正常・異常の判断となる目標値が設定されている。また、稼働情報ＤＢ４では、監視日時と、その日時における監視項目の稼働値がテーブル上に記録される。
【００２４】
図１に示されているシステム改善支援システム１に戻ると、システム改善者は、入力装置２にメールアドレスを入力することで、システム改善者ＤＢ８に登録することができる。また、システム改善者は、入力装置２に構成情報を入力することにより、構成情報ＤＢ６に登録することができる。更に、システム改善者は、既存のシステム１０の場合と同様に、入力装置２に監視対象を入力して監視項目ＤＢ２６に登録可能である。評価装置７は監視対象を評価して、監視対象を監視項目ＤＢ２６において追加登録することができる。システム改善支援システム１は、システム改善者ＤＢから得られたメールアドレス宛にメール送受信装置９を通じてメールで対象システム２０の情報を通知する。
【００２５】
図３は、対象システムの依存関係を示す階層構成図である。図３に示されているシステムの依存関係は、第１階層から第６階層まであり、各階層において、上段が監視項目を、下段が構成要素名（分類名）を表している。矢印で結ばれた構成要素は、矢印元が依存元構成要素であり、矢印先が依存先構成要素である。上下の階層間に跨がって囲んだ範囲は、一つの物理的な機器（サーバ）の範囲である。
【００２６】
第１階層においては、構成要素であるポータルサーバ（Ｗｅｂサーバ）が監視対象の構成要素であり、ＨＴＴＰ応答時間がその監視項目として設定されている。通常は、監視装置２５はポータルサーバ（Ｗｅｂサーバ）を監視対象としており、これに異常が生じた場合には、下位の第２階層に存在する構成要素をより深く監視する。ポータルサーバ（Ｗｅｂサーバ）の依存先構成要素としては、ポータルサーバリソース（Ｗｅｂサーバリソース）とＰｏｒｔａｌアプリケーション（Ｗｅｂサーバアプリケーション）とがあり、前者における監視項目はＣＰＵ使用率とメモリ使用量とであり、後者における監視項目はＣＰＵ使用率である。
【００２７】
第３階層においては、第２階層のＰｏｒｔａｌアプリケーション（Ｗｅｂサーバアプリケーション）を依存元として、ＭＡＩＬサーバ（メールサーバ）とＳＣＨＥＤＵＬＥサーバ（スケジュールサーバ）とが依存先構成要素とされている。ＭＡＩＬサーバ（メールサーバ）とＳＣＨＥＤＵＬＥサーバ（スケジュールサーバ）とにおいては、ＨＴＴＰ応答時間が監視項目に設定されている。
【００２８】
第４階層においては、ＭＡＩＬサーバ（メールサーバ）を依存元構成要素として、ＭＡＩＬサーバリソース（メールサーバリソース）とＭｒ＿Ｍａｉｌｅｒ（メールサーバサーバアプリケーション）とが依存先構成要素とされている。この場合、前者における監視項目はＣＰＵ使用率とメモリ使用量とであり、後者における監視項目はＣＰＵ使用率である。また、ＳＣＨＥＤＵＬＥサーバ（スケジュールサーバ）を依存元構成要素として、ＳＣＨＥＤＵＬＥサーバリソース（スケジュールサーバリソース）とＭｒ＿Ｓｃｈｅｄｕｌｅｒ（スケジュールサーバアプリケーション）とが依存先構成要素とされている。この場合、前者における監視項目はＣＰＵ使用率とメモリ使用量とであり、後者における監視項目はＣＰＵ使用率である。
【００２９】
第５階層においては、第４階層のＭｒ＿Ｍａｉｌｅｒ（メールサーバサーバアプリケーション）を依存元構成要素として、Ｍａｉｌ＿ＤＢサーバ（ＤＢサーバ）が依存先構成要素とされ、第４階層のＳＣＨＥＤＵＬＥサーバリソース（スケジュールサーバリソース）を依存元構成要素として、ＳＣＨＥＤＵＬＥ＿ＤＢサーバ（ＤＢサーバ）が依存先構成要素とされている。いずれの依存先構成要素でも、監視項目としてＳＱＬクエリの応答時間が設定されている。
【００３０】
第６階層においては、第５階層のＭａｉｌ＿ＤＢサーバ（ＤＢサーバ）を依存元構成要素として、Ｍａｉｌ＿ＤＢサーバリソース（ＤＢサーバリソース）とｏｒａｃｌｅ＿メール（ＤＢアプリケーション）とが依存先構成要素とされている。この場合、前者における監視項目はディスク使用量とディスクＩＯ時間とであり、後者における監視項目はＣＰＵ使用率である。また、第５階層のＳＣＨＥＤＵＬＥ＿ＤＢサーバ（ＤＢサーバ）を依存元構成要素として、ＳＣＨＥＤＵＬＥ＿ＤＢサーバリソース（ＤＢサーバリソース）とｏｒａｃｌｅ＿ＳＣＨＥＤＵＬＥ（ＤＢアプリケーション）とが依存先構成要素とされている。この場合、前者における監視項目はディスク使用量とディスクＩＯ時間とであり、後者における監視項目はＣＰＵ使用率である。
【００３１】
次に、本システム改善支援システムにおけるシステム改善プロセスについて説明する。本システム改善プロセスにおいては、先ず、システム改善者が顧客情報を収集する。顧客情報は、例えば、（ａ）システム構成図や構成要素毎の情報等から成る構成情報、（ｂ）社員向けにグループウェアを提供するなどの業務内容、（ｃ）システムの性能の監視や、性能劣化時における問題点の提示や改善案の提示などのニーズが挙げられる。
【００３２】
システム改善者は、顧客情報に基づいて初期の監視対象となる構成要素を選定する。初期の監視対象は、エンドユーザから見たサービスとしてのグループウェアである。したがって、初期監視対象となる構成要素は、グループウェアを提供する構成要素の中でエンドユーザに最も近いポータルサーバであり、その監視項目はＨＴＴＰ応答時間である。
【００３３】
次に、システム改善者はシステム改善支援システム１に情報を設定する。このシステム改善支援システムにおける情報設定については、図４〜図７に示すフローチャートを参照して説明する。図４は、この発明におけるシステム改善支援システムの全体の処理の流れの一例を示すフローチャートである。図４において、人手で設定される情報については、次のステップＳ１〜Ｓ６に示されている。
【００３４】
先ず、すべての対象システム２０で共通となる構成要素の分類毎の監視項目と目標値とを監視目標値基準テーブルに登録装置で設定する（ステップ１；「Ｓ１」と略す。以下同じ）。この設定は初回のみの設定である。図８には、監視目標値基準テーブルの一例（［１］−１）が示されている。図８に示すように、この監視目標値基準テーブル（［１］−１）には、分類として、Ｗｅｂサーバ、メールサーバ、スケジュールサーバ、ＤＢサーバ等の各種構成要素の分類が示されている。また、監視項目として、ＨＴＴＰ応答時間、ＳＭＴＰ応答時間、ＳＱＬクエリの応答時間、ＣＰＵ使用率、メモリ使用量等が掲げられている。更に、目標基準値として、監視項目の目標値が掲げられている。監視目標値基準テーブル（［１］−１）は一例であり、顧客に要望に応じて各項目が追加・変更可能である。
次に、システム改善者のメールアドレス等がシステム改善者テーブルに登録装置で設定される（Ｓ２）。図９には、システム改善者テーブルの一例（［２］−２）が示されている。システム改善者テーブル（［２］−２）は、改善者名とそのメールアドレスとから構成されている。
次に、対象システムに含まれる構成要素の情報を構成要素一覧テーブルに登録装置で設定する（Ｓ３）。初期監視項目と監視済項目の欄において、初期監視分の構成要素のみがｔｒｕｅに設定（初期監視と監視済みの項目がオンの状態となる）される。図１０には、構成要素一覧テーブルの一例（［３］−３）が示されている。構成要素一覧テーブル（［３］−３）においては、構成要素ＩＤ、構成要素名、分類名、初期監視及び監視済の項目から成っている。ポータルサーバについてのみ、初期監視項目と監視済項目とがｔｒｕｅに設定されている。
【００３５】
次に、対象システム２０に含まれる各構成要素の属性情報を構成要素属性テーブルに登録装置で設定する（Ｓ４）。図１２には、構成要素属性テーブルの一例（［４］−４）が示されている。構成要素属性テーブル（［４］−４）は、項目として名構成要素ＩＤ、属性名及びその属性の値から成っている。
次に、対象システムに含まれる構成要素間の依存関係を依存関係テーブルに登録装置で設定する（Ｓ５）。図１３には、関係テーブルの一例（［５］−５）が示されている。依存関係テーブル（［５］−５）は、基準構成要素ＩＤ、依存先構成要素ＩＤ、依存先構成要素分類名及び依存先監視項目から成っており、依存先監視項目は、監視目標値基準テーブルにあるものが使用される。
更に、最初に監視する構成要素として構成要素一覧テーブル（［３］−３）の初期監視項目がｔｒｕｅのものを取得後、その監視項目と目標値を監視項目基準テーブル（［１］−１）から取得し、監視項目設定テーブルに設定する（Ｓ６）。図１４には、監視項目設定テーブルの一例（［６］−６）が示されている。初期の設定では、図１４に示す監視項目設定テーブル（［６］−６）に示すように、項目「構成要素ＩＤ」、「監視項目」及び「目標値」として「ｓｅｒｖｅｒ＿ｐｏｒｔａｌ」、「ＨＴＴＰ応答時間」、及び「２秒以内」が設定される。
【００３６】
Ｓ１〜Ｓ６における入力による設定の完了後、システム改善支援システム１が稼働する。フローチャートに従えば、Ｓ６において監視項目設定テーブル（［６］−６）で設定された構成要素及び監視項目について、監視装置２５で監視を行い、稼働情報が稼働情報テーブルに登録される（Ｓ７）。図１５には、稼働情報テーブルの一例（［７］−７００）が示されている。Ｓ７の段階では、稼働情報テーブル（［７］−７００）は、監視項目設定テーブルに対応して、項目「構成要素ＩＤ」、「監視日時」、「監視項目」及び「稼働値」から成り、図１５に示す稼働情報テーブル（［７］−７００）に示すように、「ｓｅｒｖｅｒ＿ｐｏｒｔａｌ」が各監視日時において、ＨＴＴＰ応答時間が監視され登録される。
【００３７】
次に、システム改善支援システム１の評価装置７が、図１５に示す稼働情報テーブル（［７］−７００）に示す稼働値と図１４の監視項目設定テーブル（［６］−６）に示す目標値とを比較する。評価装置７は、稼働値が目標値よりも悪い値であるときには、その構成要素を「性能劣化している」と評価する（Ｓ８）。次いで、性能劣化している構成要素が有るか否かを判定し（Ｓ９）、性能劣化している構成要素が無ければＳ７に戻って監視装置２５による監視を継続し、性能劣化している構成要素が有れば性能劣化時処理（Ｓ１０）に移行する。この例では、構成要素ＩＤである「ｓｅｒｖｅｒ＿ｐｏｒｔａｌ」は、記載の日時において、そのＨＴＴＰ応答時間が目標値である「２秒以内」を逸脱して、２．１秒に劣化したことが判る。
【００３８】
Ｓ９で性能劣化している構成要素が有ると判定されたときの性能劣化時処理を行うフローチャートの一例が、図５に示されている。性能劣化時処理においては、先ず、システム改善者テーブルから、設定されているメールアドレスを取得し、初期監視対象となっている構成要素が性能劣化している旨がシステム改善者宛にメール送信して知らされる（Ｓ１００）。
【００３９】
次に、図１３に示している依存関係テーブル（［５］−５）に、性能劣化している構成要素が依存する下位の構成要素が存在しているか否かを判定する（Ｓ２００）。Ｓ２００の判定で依存先構成要素が存在していれば（Ｙｅｓの場合におけるループのＩ順目）、監視対象自動追加処理、即ち、その構成要素を監視項目設定テーブルに追加設定する処理が行われる（Ｓ３００）。Ｓ２００の判定で依存先構成要素が存在していなければ、Ｓ４００に移行する。
【００４０】
Ｓ３００での監視対象自動追加処理を行うフローチャートの一例が、図６に示されている。この処理では、先ず、依存関係テーブル（［５］−５）から「性能劣化している構成要素」が依存する依存先構成要素が取得される（Ｓ１０００）。この例では、第１階層のポータルサーバが性能劣化を呈しているので、その原因を探るべく、図１３に示す依存関係テーブル（［５］−５）からその依存先構成要素である第２階層のポータルサーバリソースとＰｏｒｔａｌアプリケーションとが取得される。その構成要素がＳ３で設定された構成要素一覧テーブル（［３］−３）において、監視済み項目でｔｒｕｅであるか否かが判定される（Ｓ２０００）。ポータルサーバリソースとＰｏｒｔａｌアプリケーションとはまだ監視済み項目がｆａｌｓｅであるので、Ｓ２０００の判定結果はＮＯとなる。次に、依存関係テーブル（［５］−５）からポータルサーバリソースとＰｏｒｔａｌアプリケーションとの監視項目が取得され、Ｓ１で設定された監視目標値基準テーブル（［１］−１）から目標基準値が取得され、監視項目設定テーブルに追加設定される（Ｓ３０００）。図１４には、追加設定された監視項目設定テーブル（［６］−３００１）が示されている。監視項目設定テーブル（［６］−３００１）においては、構成要素ＩＤとして、テーブル（［６］−６）のときの「ｓｅｒｖｅｒ＿ｐｏｒｔａｌ」に加えて、構成要素名「ポータルサーバリソース」と「Ｐｏｒｔａｌアプリケーション」にそれぞれ対応した「ｒｅｓｏｕｒｃｅ＿ｐｏｒｔａｌ」と「ａｐｐ＿ｐｏｒｔａｌ」とが追加設定されている。ポータルサーバリソースとＰｏｒｔａｌアプリケーションとの監視済み項目がｆａｌｓｅからｔｒｕｅに変更し設定されることに対応して、構成要素一覧テーブルが、図１０に示す（［３］−３）から図１１に示す（［３］−４００１）に更新される（Ｓ４０００）。
【００４１】
監視対象自動追加処理が終了すると、性能劣化時処理に戻って、Ｓ３０００において図１４に示す監視項目設定テーブル（［６］−３００１）に設定された構成要素及び監視項目について監視装置２５によって監視を行い、追加された構成要素の分を含めて稼働情報を稼働情報テーブルに登録する（Ｓ４００）。図１６に示す自動追加処理後の稼働情報テーブル（［７］−４０１）に示すように、監視項目設定テーブル（［６］−３００１）に設定された構成要素及び監視項目について所定の時間毎に監視が行われ、その結果が稼働値として登録される。
【００４２】
次に、初期から監視されている構成要素の性能劣化が続いているか否かが判定される（Ｓ５００）。システムが改善されて性能劣化が続いていない場合にはＳ８００に移行するが、性能劣化が続いている場合には、Ｓ３００で監視が追加された構成要素の性能劣化が続いているか否かが更に判定される（Ｓ６００）。Ｓ６００の判定でＹｅｓの場合には、直ちにＳ２００に戻り、Ｓ６００の判定でＮｏの場合には、品質が目標値以内である（良い）追加監視分の構成要素を監視項目設定テーブルから削除する処理を行い（Ｓ７００）、その後、Ｓ２００に戻る。
【００４３】
図１６に示す稼働情報テーブル（［７］−４０１）の例では、初期から監視されている構成要素（ＩＤが「ｓｅｒｖｅｒ＿ｐｏｒｔａｌ」）のＨＴＴＰ応答時間の稼働値が２．０秒以上であって性能劣化が続いている。したがって、Ｓ５００の判定ではＹｅｓと判定される。監視が追加された構成要素のうち構成要素ＩＤ「ｒｅｓｏｕｒｃｅ＿ｐｏｒｔａｌ」については、監視項目「ＣＰＵ使用率」の稼働値が５６％であって、対応する分類名「Ｗｅｂサーバリソース」の監視項目「ＣＰＵ使用率」の目標基準値「７０％以下」を充足しており、監視項目「メモリ使用量」の稼働値が「物理メモリの容量の７５〜８２％」であって、対応する分類名Ｗｅｂサーバリソースのメモリ使用量の目標基準値「物理メモリの容量の１５０％以下」を充足している。しかしながら、追加設定された構成要素ＩＤ「ａｐｐ＿ｐｏｒｔａｌ」については、監視項目「ＣＰＵ使用率」の稼働値が５８％であって、対応する分類名「Ｗｅｂサーバアプリケーション」の監視項目「ＣＰＵ使用率」の目標基準値「５０％以下」を上回っており、性能劣化を示している。したがって、Ｓ６００の性能劣化継続の判定では、構成要素ＩＤ「ｒｅｓｏｕｒｃｅ＿ｐｏｒｔａｌ」についてはＮｏと判定され、Ｓ７００において監視項目設定テーブルから削除される。その結果、監視項目設定テーブル（［６］−７０１）で設定される構成要素は、ＩＤで「ｓｅｒｖｅｒ＿ｐｏｒｔａｌ」と「ａｐｐ＿ｐｏｒｔａｌ」とのみになる。Ｓ６００の判定で構成要素ＩＤ「ａｐｐ＿ｐｏｒｔａｌ」についてはＹｅｓと判定されるので、Ｓ２００からのフローが繰り返される。
【００４４】
性能劣化している構成要素ＩＤ「ａｐｐ＿ｐｏｒｔａｌ」については、図１３に示している依存関係テーブル（［５］−５）において、依存する構成要素が第３階層中に有るか否かが判定される（Ｓ２００）。本例の場合、依存関係テーブル（［５］−５）から、依存先構成要素である「Ｍａｉｌサーバ（分類名「メールサーバ」）」と、「ＳＣＨＥＤＵＬＥサーバ（分類名「スケジュールサーバ」）とが存在しており、Ｓ２００の判定がＹｅｓの場合におけるループのＩＩ順目に入る。続いて、監視対象自動追加処理が行われ（Ｓ３００）、これらの構成要素が監視項目設定テーブルに追加設定される。具体的には、依存関係テーブルから上記二つの依存先構成要素が取得され（Ｓ１０００）、両構成要素が図１１に示す自動追加処理後の構成要素一覧テーブル（［３］−４００１）で「監視済み」項目がｔｒｕｅであるか否かが判定される（Ｓ２０００）。本例の場合「否」であるので、図１３に示す依存関係テーブル（［５］−５）から分類名に対応する監視項目（Ｍａｉｌサーバの監視項目は「ＳＭＴＰ応答時間」、ＳＣＨＥＤＵＬＥサーバの監視項目は「ＨＴＴＰ応答時間」）が取得され、また図８に示す監視目標基準値テーブル（［１］−１）からその監視項目の目標値が取得されて、構成要素が監視項目設定テーブルに追加設定される（Ｓ３０００）。図１４には、このときの監視項目設定テーブルが（［６］−３００２）に示されている。前回の監視項目設定テーブル（［６］−７０１）に対して、二つの構成要素ＩＤ（「ｓｅｒｖｅｒ＿ｍａｉｌ］」と「ｓｅｒｖｅｒ＿ｓｃｈｅｄｕｌｅ」）が追加設定されているのが判る。また、構成要素一覧テーブルで、その追加構成要素の「監視済み」項目が新たにｔｒｕｅに変更される。変更された構成要素一覧テーブルが図１１において（［３］−４００２）に示されている。
【００４５】
監視項目設定テーブル（［６］−３００２）に従って監視装置２５が監視を行い、稼働情報が稼働情報テーブルに登録される。登録された稼働情報テーブルが図１６において（［７］−４０２）に示されている。稼働情報テーブル［７］−４０２）からすると、Ｓ５００の判断において、初期監視の対象となっている構成要素ＩＤ「ｓｅｒｖｅｒ＿ｐｏｒｔａｌ」と「ａｐｐ＿ｐｏｒｔａｌ」は性能劣化した状態が続いていると判定される。次のＳ６００の判断において、追加された監視対象となった構成要素ＩＤ「ｓｅｒｖｅｒ＿ｍａｉｌ］」と「ｓｅｒｖｅｒ＿ｓｃｈｅｄｕｌｅ」は、稼働値が目標値に納まっているので、性能劣化状態ではないと判断され、Ｓ７００に移行する。Ｓ７００においては、品質が目標値以内である追加監視の対象となった構成要素が監視項目設定テーブルから削除される。削除された監視項目設定テーブルが図１４において（［６］−７０２）に示されており、監視項目設定テーブル（［６］−３００２）では追加されていた構成要素ＩＤ「ｓｅｒｖｅｒ＿ｍａｉｌ］」と「ｓｅｒｖｅｒ＿ｓｃｈｅｄｕｌｅ」が削除されていることが判る。
【００４６】
Ｓ７００における処理の後、フローはＳ２００に戻る。性能劣化している構成要素は存在しているので、Ｓ３００の監視対象自動追加処理に移行するが、その構成要素が構成要素一覧テーブルにおける「監視済み」項目が既にｔｒｕｅであるので、Ｓ２０００の判断でＹｅｓと判定され、追加設定は行われない。次に、Ｓ５００において、既存の監視対象となっている構成要素の性能劣化が継続しているか否かが判定されるが、システムの改善が行われるので、いずれはＮｏの判定となる。ＩＩＩ順目の稼働情報テーブルが図１６における（［７］−４０３）に示されており、ここではシステムの改善が行われていることが示されている。
【００４７】
以上のように、Ｓ７から開始されるシステム改善支援システム１の稼働に伴い、Ｓ１０の性能劣化時の一連の処理が行われ、システム改善者がシステム改善支援システム１に稼働情報を出力させ、対象システム２０の問題となっている構成要素を特定する。例えば、ポータルサーバのＨＴＴＰ応答時間の遅延はシステムのバックボーンにあるＰｏｒｔａｌアプリケーションに起因している旨の特定がなされる。システム改善者は、このレポートを見て顧客に対象システム２０の改善を提案する。
【００４８】
Ｓ５００でのＮｏの判定を受けて、Ｓ８００において監視対象初期化処理が行われる。図７は、監視対象初期化処理を行うフローチャートの一例を示す図である。図７のフローチャートに示すように、Ｓ８００では、監視項目設定テーブルから、「追加監視分の構成要素」の設定がすべて削除される（Ｓ５０００）。「追加監視分の構成要素」の設定を削除した後の監視項目設定テーブルが図１４における（［６］−５０００）に示されている。監視項目設定テーブル（［６］−５０００）によれば、当初の監視項目設定テーブル（［６］−６）に戻っていることが判る。次に、構成要素一覧テーブルで「追加監視分の構成要素」の「監視済み」項目をすべて「ｆａｌｓｅ」に設定する（Ｓ６０００）。この設定後の構成要素一覧テーブルが，図１１において（［３］−６０００）（内容は、既説明の構成要素一覧テーブル（［３］−３）に同じ）に示されている。
【００４９】
監視対象初期化処理（Ｓ８００）の終了を受けて、システム改善者テーブル（［２］−２）からメールアドレスを取得し、初期監視対象となった構成要素の品質が目標値以内に戻ったことをメール送信してシステムのユーザに知らせて、性能劣化時処理を終了する。
【００５０】
図１７は、本システム改善支援システムと既存の同システムとのプロセスの異なる点を表形式にまとめた図である。
「１．情報収集」については、そのプロセス内容は、システム改善者が顧客情報（構成情報、業務内容、ニーズ等）を収集することであり、両システムとも、同じである。
「２及び３．監視対象設定」については、既存システムでは、プロセス内容は、システム改善者が顧客情報に基づいて監視対象となる構成要素を対象システム全体の中から複数選定しているのに対して、本システムでは、システム改善者が顧客情報を基に初期の監視対象となる構成要素を選定している。
「４及び５．情報設定」については、既存システムでは、システム改善者が監視対象となる構成要素の情報をシステム改善支援システムに設定しているが、本システムでは、それに加えて、更に、システム改善者が必要な情報を対象システムに置かれる監視装置２５ではなくシステム改善支援システム側に設定している。設定する情報としては、監視目標基準値、システム改善者のメールアドレス、構成要素毎の情報、構成要素間の依存関係が挙げられる。
「６．監視」については、既存のシステムも本システムも、共に、監視装置２５（システム改善支援装置）が、設定された構成要素を監視する。
「７〜９. 監視対象追加」については、既存のシステムでは、監視対象は予め設定されており、追加はできなかったのに対して、本システムでは、
「７」システム改善支援装置が監視対象構成要素の性能劣化時に、監視結果と設定された情報を基に、新しく監視対象となる構成要素を選定し、システム改善支援装置に設定することができる。
「８」上記順番６〜７．を繰り返す。
「９」システム改善支援装置が、初期の監視対象構成要素の性能劣化時に、システム改善者宛にメールを送信して知らせることができる。
「１０．問題要素特定」については、既存のシステムも本システムも、システム改善者が監視結果と構成情報とを基に、対象システムの問題となっている構成要素を特定する。
「１１．改善提案」については、既存のシステムも本システムも、システム改善者が、顧客へ対象システムの改善案を提案する。
【図面の簡単な説明】
【００５１】
【図１】この発明によるシステム改善支援システムのシステム構成図。
【図２】図１に示すシステム改善支援システムの各データベースのデータ構造図。
【図３】システム改善支援システムが対象とする対象システムの依存関係を示す階層構成図。
【図４】この発明におけるシステム改善支援システムの全体の処理の流れの一例を示すフローチャート。
【図５】この発明におけるシステム改善支援システムによる性能劣化時処理の一例を示すフローチャート。
【図６】この発明におけるシステム改善支援システムによる監視対象自動追加処理の一例を示すフローチャート。
【図７】この発明におけるシステム改善支援システムによる監視対象初期化処理の一例を示すフローチャート。
【図８】監視目標値基準テーブルの一例を示す図。
【図９】システム改善者テーブルの一例を示す図。
【図１０】構成要素一覧テーブルの一例を示す図。
【図１１】自動追加処理後の構成要素一覧テーブルを示す図。
【図１２】構成要素属性テーブルの一例を示す図。
【図１３】依存関係テーブルの一例を示す図。
【図１４】監視項目設定テーブルの一例を示す図。
【図１５】稼働情報テーブルの一例を示す図。
【図１６】自動追加処理の後の稼働情報テーブルを示す図。
【図１７】システム改善支援システムと既存のシステムとのプロセスの同異を表形式にまとめた図。
【図１８】既存のシステム改善支援システムの一例を示すシステム構成図である。
【図１９】対象システムの一例を示すシステム構成図である。
【符号の説明】
【００５２】
１ システム改善支援システム
２ 入力装置
３ 収集装置
４ 稼働情報データベース
５ 出力装置
６ 構成情報データベース
７ 評価装置
８ システム改善者データベース
９ メール送受信装置
１０ 既存のシステム改善支援システム
２０ 対象システム
２１〜２４ 構成要素
２５ 監視装置
２６ 監視項目データベース
【技術分野】
【０００１】
この発明は、対象システムの稼働情報を監視して、その結果に基づいて対象システムの改善案を提示することをシステム的に可能にするシステム改善支援システムに関する。
【背景技術】
【０００２】
従来、いくつかの構成要素から成る対象システムの稼働状態を当該対象システムに備わる監視装置によって監視し、得られた対象システムの稼働情報を専用回線やインターネット等の通信手段を通じて収集し、対象システムに生じた問題点を改善・支援するシステム改善支援システムが知られている。システム改善支援システムは、対象システムの外部に置かれており、複数の顧客の対象システムを対象として改善・支援サービスを提供することができる。
【０００３】
既存のシステム改善支援システムの構成の一例が、図１８に示されている。図１８を参照すると、対象システム２０は、一つ又は複数の構成要素２１〜２４（ここでは４つの構成要素を示したが、これは説明を簡略にするためであって、通常は相当の数の構成要素を備える）、これらの構成要素２１〜２４を監視する監視装置２５、及び構成要素２１〜２４についての監視項目が登録されている監視項目データベース２６から成っている。監視装置２５は、監視項目データベース（「データベース」は「ＤＢ」と略す。以下同じ）２６にアクセスし、そこに登録されている監視項目に従って、対象システムの構成要素２１〜２４を監視している。
【０００４】
対象システムのシステム構成の一例が、図１９に示されている。図１９に示す対象システム２０は、ポータルサーバ（ＷＥＢサーバ。以下、括弧内は分類名）と、ポータルサーバに繋がるＭＡＩＬサーバ（メールサーバ）とＭＡＩＬ＿ＤＢサーバ（ＤＢサーバ）、及びＳＣＨＥＤＵＬＥサーバ（スケジュールサーバ）とＳＣＨＥＤＵＬＥ＿ＤＢサーバ（ＤＢサーバ）とを備えている。
【０００５】
一方、対象システム２０の改善を行うシステム改善支援システム１０が、ネットワークや通信回線を通じて対象システムに繋がっている。監視項目ＤＢ２６において登録される監視項目は、システム改善支援システム１０の入力装置２を操作することによって追加、削除、変更が可能である。監視装置２５が監視することで取得・収集・蓄積された対象システム２０の稼働情報は、システム改善支援システム１０の収集装置３に送られて、稼働情報ＤＢ４に蓄積される。システム改善者は、稼働情報ＤＢ４にアクセスし、出力装置５によって対象システム２０の構成情報や稼働情報をモニタ又はプリントさせることができる。システム改善者は、構成情報や稼働情報に基づいて対象システム２０の分析と改善を提案することができる。
【０００６】
上記のシステム改善支援システム１０は、監視装置２５がすべての構成要素２１〜２４を決められた順序で監視して回り、しかもシステム改善支援システム１０との間のデータの遣り取りを行っている。一方、対象システム２０の稼働能力や通信能力は時間経過とともに劣化するのは避けられない。対象システム２０のＣＰＵや通信回線が負う負荷については無視できないものがあり、その結果、監視装置２５の監視作業負担に起因して、ユーザが使用可能なシステム能力が低下し、ユーザの通常業務に影響が出るのが避けられないという問題がある。
【０００７】
顧客へのサービスの管理の一例として、サービス構成情報とサービスレベル契約と、サービスレベル管理レポートの設定に基づき、自動的にサービス毎のサービス品質の算定を行い、運用者又は顧客へ提示するサービス管理レポートを作成するサービス管理方法及びシステムが提案されている（特許文献１）。このサービス管理方法及びシステムによれば、サービス構成情報（ネットワーク機器とサービスとの組合せ情報）、サービスレベル契約情報、ネットワーク機器からのアラーム情報をもとに、サービス単位に品質を算出し、サービス管理レポートを提出している。
【特許文献１】特開２００１−３２０３７０号公報（段落［００２２］〜［００４２］、図３、図4）
【発明の開示】
【発明が解決しようとする課題】
【０００８】
そこで、複数の構成要素から構成される対象システムの各構成要素の稼働状態を監視し、その結果に基づいてシステム改善案を作成するシステム改善支援システムにおいて、監視対象となる構成要素が性能劣化を生じた際にその原因となっている対象システムの問題点を特定するに当たって、下位の構成要素への劣化原因の探索程度を限定する方策を採ることで、対象システムの負荷を必要最小限に留めることを可能にする点で解決すべき課題がある。
【０００９】
この発明の目的は、構成要素が性能劣化を生じたときに対象システムの問題点を特定していくに際して、対象システムに課せられる負荷を必要最小限に留めて、対象システムを利用するユーザへのサービスの低下を防止しながら、システム改善案を提示することができるシステム改善支援システムを提供することである。
【課題を解決するための手段】
【００１０】
上記の課題を解決するため、この発明によるシステム改善支援システムは、複数の構成要素及び前記各構成要素をその監視項目について監視する監視装置を備えた対象システムを前記監視装置によって得られた前記構成要素の稼働情報に基づいて改善するのを支援するシステム改善支援システムであって、監視対象とされた前記構成要素が当該構成要素の前記稼働情報に基づいて性能劣化しているか否かを判定する性能判定処理と、前記性能判定処理において前記構成要素が性能劣化と判定されるときのみ前記構成要素が依存する前記構成要素を更なる前記監視対象として自動追加する自動追加処理とを行うことから成っている。
【００１１】
このシステム改善支援システムによれば、性能判定処理において、ユーザが利用するシステムの監視対象とされた構成要素が当該構成要素の稼働情報に基づいて性能劣化しているか否かを判定する。そして、性能判定処理において構成要素が性能劣化と判定されるときのみ構成要素が依存する構成要素を更なる監視対象として自動追加する自動追加処理が行われる。したがって、監視装置が常時、すべての構成要素を決められた順序で監視して回るのと異なり、監視対象の経時変化等に起因した性能劣化時のみ、その監視対象が依存する構成要素を更なる監視対象として追加する。対象システムの問題点を特定するに当たってこうした劣化原因の探索範囲と深さを限定する対処の仕方によって、対象システムが探索のために負う負担が軽減され、対象システムを利用するユーザへのサービス低下を防止することができる。
【００１２】
このシステム改善支援システムにおいて、前記自動追加処理において前記監視対象として前記構成要素が追加されたとき、追加された前記構成要素についての前記性能判定処理と、当該構成要素が性能劣化と判定されるときに当該構成要素が依存する前記構成要素を更なる前記監視対象に追加する前記自動追加処理とを繰り返して行うことができる。こうした性能判定処理と自動追加処理とを繰り返すことにより、探索範囲と深さが可及的に限定され、対象システムへの負荷を軽減した状態で劣化原因の探索が繰り返される。
【００１３】
上記の性能判定処理と自動追加処理とを繰り返すシステム改善支援システムにおいて、前記監視対象として追加された前記構成要素が性能劣化していないと前記性能判定処理において判定されるとき、当該構成要素を前記監視対象から削除する監視対象削除処理を行うことが好ましい。監視対象として複数の構成要素が追加されることがあるが、追加された構成要素のうち性能劣化していないものが存在し得る。性能判定処理において性能劣化していないと判定される構成要素については監視対象から削除する監視対象削除処理が行われる。したがって、監視対象が追加される際に、監視対象となる構成要素の数の増加を緩和させることができ、監視に要する対象システムの負荷の増大を抑制することができる。
【００１４】
上記の繰り返される一連の前記自動追加処理において、前記監視対象削除処理で前記監視対象から削除された前記構成要素については、前記監視対象として自動追加しないことが好ましい。監視対象削除処理において監視対象から削除された構成要素については、性能判定処理において性能劣化しているか否かの監視対象として自動追加しないことで、監視に要する対象システムの負荷を軽減することができる。
【００１５】
上記システム改善支援システムにおいて、前記対象システムを利用するエンドユーザに最も近い前記構成要素のみを、前記監視装置による監視開始初期における初期監視対象とすることができる。対象システムの監視に際して対象システムを利用するエンドユーザに最も近い構成要素のみを初期監視対象とすることにより、監視開始初期の段階において監視に要する対象システムの負荷を軽減することができる。
【００１６】
上記初期監視対象を特定するシステム改善支援システムにおいて、前記初期監視対象とされた前記構成要素の性能劣化が正常値に改善されたとき、当該構成要素以外のすべての前記構成要素についての前記監視装置による監視を終了することが好ましい。初期監視対象とされるエンドユーザに最も近い構成要素の性能劣化が正常値に改善されたときは、初期監視対象以外の構成要素の監視をする必要がないと判断される。したがって、エンドユーザに最も近い構成要素以外の構成要素についての監視を終了することで、監視に要する対象システムの負荷を軽減することができる。
【００１７】
上記初期監視対象を特定するシステム改善支援システムにおいて、前記初期監視対象が前記性能判定処理において性能劣化と判定されるときに、その旨をシステム改善者にメールにて自動送信することが好ましい。システム改善者への自動メール送信によって、システム改善者は対象システムに問題が生じていることを早期に知ることができる。
【００１８】
上記システム改善支援システムの自動追加処理において、前記対象システムに備わっていて前記各構成要素の前記監視項目を登録可能であり且つ前記監視装置が監視する前記構成要素について前記監視項目を提供する監視項目データベースに、更なる前記監視対象となる前記構成要素とその監視項目とを自動追加することができる。システム改善支援システムは、その自動追加処理において、対象システムに備わる監視項目データベースをそのまま利用して、更なる監視対象となる構成要素とその監視項目とを自動的に追加させることができる。
【００１９】
上記システム改善支援システムの性能判定処理において、前記監視項目毎の目標基準値が予め記憶されている目標基準値テーブルを備えており、前記性能判定処理において、前記構成要素が性能劣化しているか否かを、当該構成要素の前記稼働情報が前記目標基準値テーブルに記憶されている前記目標基準値と比較・評価することで判定することができる。予め目標基準値テーブルに監視項目毎の目標基準値として記憶させていることにより、構成要素が性能劣化しているか否かは、構成要素の稼働情報を目標基準値テーブルの目標基準値と比較・評価することで直ちに判定することができる。
【発明の効果】
【００２０】
この発明によるシステム改善支援システムは、上記のように監視対象とされた構成要素が当該構成要素の稼働情報に基づいて性能劣化しているか否かを判定する性能判定処理と、当該性能判定処理において構成要素が性能劣化と判定されるときのみ当該構成要素が依存する構成要素を更なる監視対象として自動追加する自動追加処理とを行う構成とされているので、下位の構成要素への劣化原因の探索程度が限定され、対象システムの問題点を特定していくに際して対象システムに課せられる負荷を必要最小限に留めることができる。したがって、対象システムを利用するユーザへのサービスの低下を防止しながら、システム改善案を提示することができる。
【発明を実施するための最良の形態】
【００２１】
以下、添付した図面に基づいて、この発明によるシステム改善支援システムの実施例を説明する。図１はこの発明によるシステム改善支援システムのシステム構成図である。ここでは、「構成要素」は、サーバ、ネットワーク機器、各機器の中で稼働するソフトウェア等の要素を示す。「構成情報」は、（ａ）各構成要素の関係をサービス観点で表した論理的な構成としてのサービス構成、（ｂ）サーバのＩＰアドレス・ホスト名・型名及びソフトウェアの名称等から成る各構成要素の詳細、（ｃ）ＣＰＵ稼働率・メモリ使用量、応答時間等の各構成要素の安定稼働を表す指標値としての、各構成要素の稼働に関する目標値、並びに（ｄ）「ソフトウェアＡはサーバＢ上で稼働している」、「ソフトウェアＣはポートＤを利用している」等で表される各構成要素間の依存関係から成っている。また、「監視対象」は、稼働情報の監視対象となる構成要素を指す。「監視項目」は、「サーバＥはＣＰＵ稼働率・メモリ使用量」、「ネットワーク機器Ｆは応答時間」等の、構成要素の品質を評価するための項目を指す。更に、「目標値」は、「サーバＧのＨＴＴＰ応答時間の目標値は２秒以内」等の、構成要素の品質が正常であると判断する値であって、監視項目毎に設定される値をいう。
【００２２】
システム改善支援システムの構成が、図１に示されている。図１に示すように、システム改善支援システム１は、図１８に示す既存のシステム１０と比較して、構成情報ＤＢ６、評価装置７、システム改善者ＤＢ８及びメール送信装置９を新たに備えている。対象システム２０の構成及びシステム改善支援システム１のうち既存のシステム改善支援システム１０と共通する構成については、既に説明したとおりであるので、再度の説明を省略する。
【００２３】
図２には、図１に示すシステム改善支援システム１の（１）システム改善者ＤＢ８、（２）構成情報ＤＢ６及び（４）稼働情報ＤＢ４、（３）対象システム２０の監視項目ＤＢ２６についてのデータ構造が示されている。システム改善者ＤＢ８においては、システム改善者テーブルが用意され、一例として、図示のように改善者名とメールアドレスがデータとして設定されている。構成情報ＤＢ６においては、システムを構成する構成要素の分類名、監視項目、及び目標基準値のデータから成る監視目標基準値テーブルが用意される。分類名のものが正常か異常かについては、監視項目とされる事項が目標基準値（２秒以内）を満たすか否かによって判定される。構成情報ＤＢ６には、その外に、構成要素一覧テーブル、構成要素属性テーブル、依存関係テーブルがあり、それぞれ図示されているテーブル構造を持つ。特に、依存関係テーブルでは、依存先構成要素分類に応じて依存先監視項目（ＣＰＵ使用率、メモリ使用量）が定められている。監視項目ＤＢ２６及び稼働情報ＤＢ４は、既存のシステム１０，２０でも備わっているＤＢであるが、監視項目ＤＢ２６では構成要素毎に監視項目が設定され、正常・異常の判断となる目標値が設定されている。また、稼働情報ＤＢ４では、監視日時と、その日時における監視項目の稼働値がテーブル上に記録される。
【００２４】
図１に示されているシステム改善支援システム１に戻ると、システム改善者は、入力装置２にメールアドレスを入力することで、システム改善者ＤＢ８に登録することができる。また、システム改善者は、入力装置２に構成情報を入力することにより、構成情報ＤＢ６に登録することができる。更に、システム改善者は、既存のシステム１０の場合と同様に、入力装置２に監視対象を入力して監視項目ＤＢ２６に登録可能である。評価装置７は監視対象を評価して、監視対象を監視項目ＤＢ２６において追加登録することができる。システム改善支援システム１は、システム改善者ＤＢから得られたメールアドレス宛にメール送受信装置９を通じてメールで対象システム２０の情報を通知する。
【００２５】
図３は、対象システムの依存関係を示す階層構成図である。図３に示されているシステムの依存関係は、第１階層から第６階層まであり、各階層において、上段が監視項目を、下段が構成要素名（分類名）を表している。矢印で結ばれた構成要素は、矢印元が依存元構成要素であり、矢印先が依存先構成要素である。上下の階層間に跨がって囲んだ範囲は、一つの物理的な機器（サーバ）の範囲である。
【００２６】
第１階層においては、構成要素であるポータルサーバ（Ｗｅｂサーバ）が監視対象の構成要素であり、ＨＴＴＰ応答時間がその監視項目として設定されている。通常は、監視装置２５はポータルサーバ（Ｗｅｂサーバ）を監視対象としており、これに異常が生じた場合には、下位の第２階層に存在する構成要素をより深く監視する。ポータルサーバ（Ｗｅｂサーバ）の依存先構成要素としては、ポータルサーバリソース（Ｗｅｂサーバリソース）とＰｏｒｔａｌアプリケーション（Ｗｅｂサーバアプリケーション）とがあり、前者における監視項目はＣＰＵ使用率とメモリ使用量とであり、後者における監視項目はＣＰＵ使用率である。
【００２７】
第３階層においては、第２階層のＰｏｒｔａｌアプリケーション（Ｗｅｂサーバアプリケーション）を依存元として、ＭＡＩＬサーバ（メールサーバ）とＳＣＨＥＤＵＬＥサーバ（スケジュールサーバ）とが依存先構成要素とされている。ＭＡＩＬサーバ（メールサーバ）とＳＣＨＥＤＵＬＥサーバ（スケジュールサーバ）とにおいては、ＨＴＴＰ応答時間が監視項目に設定されている。
【００２８】
第４階層においては、ＭＡＩＬサーバ（メールサーバ）を依存元構成要素として、ＭＡＩＬサーバリソース（メールサーバリソース）とＭｒ＿Ｍａｉｌｅｒ（メールサーバサーバアプリケーション）とが依存先構成要素とされている。この場合、前者における監視項目はＣＰＵ使用率とメモリ使用量とであり、後者における監視項目はＣＰＵ使用率である。また、ＳＣＨＥＤＵＬＥサーバ（スケジュールサーバ）を依存元構成要素として、ＳＣＨＥＤＵＬＥサーバリソース（スケジュールサーバリソース）とＭｒ＿Ｓｃｈｅｄｕｌｅｒ（スケジュールサーバアプリケーション）とが依存先構成要素とされている。この場合、前者における監視項目はＣＰＵ使用率とメモリ使用量とであり、後者における監視項目はＣＰＵ使用率である。
【００２９】
第５階層においては、第４階層のＭｒ＿Ｍａｉｌｅｒ（メールサーバサーバアプリケーション）を依存元構成要素として、Ｍａｉｌ＿ＤＢサーバ（ＤＢサーバ）が依存先構成要素とされ、第４階層のＳＣＨＥＤＵＬＥサーバリソース（スケジュールサーバリソース）を依存元構成要素として、ＳＣＨＥＤＵＬＥ＿ＤＢサーバ（ＤＢサーバ）が依存先構成要素とされている。いずれの依存先構成要素でも、監視項目としてＳＱＬクエリの応答時間が設定されている。
【００３０】
第６階層においては、第５階層のＭａｉｌ＿ＤＢサーバ（ＤＢサーバ）を依存元構成要素として、Ｍａｉｌ＿ＤＢサーバリソース（ＤＢサーバリソース）とｏｒａｃｌｅ＿メール（ＤＢアプリケーション）とが依存先構成要素とされている。この場合、前者における監視項目はディスク使用量とディスクＩＯ時間とであり、後者における監視項目はＣＰＵ使用率である。また、第５階層のＳＣＨＥＤＵＬＥ＿ＤＢサーバ（ＤＢサーバ）を依存元構成要素として、ＳＣＨＥＤＵＬＥ＿ＤＢサーバリソース（ＤＢサーバリソース）とｏｒａｃｌｅ＿ＳＣＨＥＤＵＬＥ（ＤＢアプリケーション）とが依存先構成要素とされている。この場合、前者における監視項目はディスク使用量とディスクＩＯ時間とであり、後者における監視項目はＣＰＵ使用率である。
【００３１】
次に、本システム改善支援システムにおけるシステム改善プロセスについて説明する。本システム改善プロセスにおいては、先ず、システム改善者が顧客情報を収集する。顧客情報は、例えば、（ａ）システム構成図や構成要素毎の情報等から成る構成情報、（ｂ）社員向けにグループウェアを提供するなどの業務内容、（ｃ）システムの性能の監視や、性能劣化時における問題点の提示や改善案の提示などのニーズが挙げられる。
【００３２】
システム改善者は、顧客情報に基づいて初期の監視対象となる構成要素を選定する。初期の監視対象は、エンドユーザから見たサービスとしてのグループウェアである。したがって、初期監視対象となる構成要素は、グループウェアを提供する構成要素の中でエンドユーザに最も近いポータルサーバであり、その監視項目はＨＴＴＰ応答時間である。
【００３３】
次に、システム改善者はシステム改善支援システム１に情報を設定する。このシステム改善支援システムにおける情報設定については、図４〜図７に示すフローチャートを参照して説明する。図４は、この発明におけるシステム改善支援システムの全体の処理の流れの一例を示すフローチャートである。図４において、人手で設定される情報については、次のステップＳ１〜Ｓ６に示されている。
【００３４】
先ず、すべての対象システム２０で共通となる構成要素の分類毎の監視項目と目標値とを監視目標値基準テーブルに登録装置で設定する（ステップ１；「Ｓ１」と略す。以下同じ）。この設定は初回のみの設定である。図８には、監視目標値基準テーブルの一例（［１］−１）が示されている。図８に示すように、この監視目標値基準テーブル（［１］−１）には、分類として、Ｗｅｂサーバ、メールサーバ、スケジュールサーバ、ＤＢサーバ等の各種構成要素の分類が示されている。また、監視項目として、ＨＴＴＰ応答時間、ＳＭＴＰ応答時間、ＳＱＬクエリの応答時間、ＣＰＵ使用率、メモリ使用量等が掲げられている。更に、目標基準値として、監視項目の目標値が掲げられている。監視目標値基準テーブル（［１］−１）は一例であり、顧客に要望に応じて各項目が追加・変更可能である。
次に、システム改善者のメールアドレス等がシステム改善者テーブルに登録装置で設定される（Ｓ２）。図９には、システム改善者テーブルの一例（［２］−２）が示されている。システム改善者テーブル（［２］−２）は、改善者名とそのメールアドレスとから構成されている。
次に、対象システムに含まれる構成要素の情報を構成要素一覧テーブルに登録装置で設定する（Ｓ３）。初期監視項目と監視済項目の欄において、初期監視分の構成要素のみがｔｒｕｅに設定（初期監視と監視済みの項目がオンの状態となる）される。図１０には、構成要素一覧テーブルの一例（［３］−３）が示されている。構成要素一覧テーブル（［３］−３）においては、構成要素ＩＤ、構成要素名、分類名、初期監視及び監視済の項目から成っている。ポータルサーバについてのみ、初期監視項目と監視済項目とがｔｒｕｅに設定されている。
【００３５】
次に、対象システム２０に含まれる各構成要素の属性情報を構成要素属性テーブルに登録装置で設定する（Ｓ４）。図１２には、構成要素属性テーブルの一例（［４］−４）が示されている。構成要素属性テーブル（［４］−４）は、項目として名構成要素ＩＤ、属性名及びその属性の値から成っている。
次に、対象システムに含まれる構成要素間の依存関係を依存関係テーブルに登録装置で設定する（Ｓ５）。図１３には、関係テーブルの一例（［５］−５）が示されている。依存関係テーブル（［５］−５）は、基準構成要素ＩＤ、依存先構成要素ＩＤ、依存先構成要素分類名及び依存先監視項目から成っており、依存先監視項目は、監視目標値基準テーブルにあるものが使用される。
更に、最初に監視する構成要素として構成要素一覧テーブル（［３］−３）の初期監視項目がｔｒｕｅのものを取得後、その監視項目と目標値を監視項目基準テーブル（［１］−１）から取得し、監視項目設定テーブルに設定する（Ｓ６）。図１４には、監視項目設定テーブルの一例（［６］−６）が示されている。初期の設定では、図１４に示す監視項目設定テーブル（［６］−６）に示すように、項目「構成要素ＩＤ」、「監視項目」及び「目標値」として「ｓｅｒｖｅｒ＿ｐｏｒｔａｌ」、「ＨＴＴＰ応答時間」、及び「２秒以内」が設定される。
【００３６】
Ｓ１〜Ｓ６における入力による設定の完了後、システム改善支援システム１が稼働する。フローチャートに従えば、Ｓ６において監視項目設定テーブル（［６］−６）で設定された構成要素及び監視項目について、監視装置２５で監視を行い、稼働情報が稼働情報テーブルに登録される（Ｓ７）。図１５には、稼働情報テーブルの一例（［７］−７００）が示されている。Ｓ７の段階では、稼働情報テーブル（［７］−７００）は、監視項目設定テーブルに対応して、項目「構成要素ＩＤ」、「監視日時」、「監視項目」及び「稼働値」から成り、図１５に示す稼働情報テーブル（［７］−７００）に示すように、「ｓｅｒｖｅｒ＿ｐｏｒｔａｌ」が各監視日時において、ＨＴＴＰ応答時間が監視され登録される。
【００３７】
次に、システム改善支援システム１の評価装置７が、図１５に示す稼働情報テーブル（［７］−７００）に示す稼働値と図１４の監視項目設定テーブル（［６］−６）に示す目標値とを比較する。評価装置７は、稼働値が目標値よりも悪い値であるときには、その構成要素を「性能劣化している」と評価する（Ｓ８）。次いで、性能劣化している構成要素が有るか否かを判定し（Ｓ９）、性能劣化している構成要素が無ければＳ７に戻って監視装置２５による監視を継続し、性能劣化している構成要素が有れば性能劣化時処理（Ｓ１０）に移行する。この例では、構成要素ＩＤである「ｓｅｒｖｅｒ＿ｐｏｒｔａｌ」は、記載の日時において、そのＨＴＴＰ応答時間が目標値である「２秒以内」を逸脱して、２．１秒に劣化したことが判る。
【００３８】
Ｓ９で性能劣化している構成要素が有ると判定されたときの性能劣化時処理を行うフローチャートの一例が、図５に示されている。性能劣化時処理においては、先ず、システム改善者テーブルから、設定されているメールアドレスを取得し、初期監視対象となっている構成要素が性能劣化している旨がシステム改善者宛にメール送信して知らされる（Ｓ１００）。
【００３９】
次に、図１３に示している依存関係テーブル（［５］−５）に、性能劣化している構成要素が依存する下位の構成要素が存在しているか否かを判定する（Ｓ２００）。Ｓ２００の判定で依存先構成要素が存在していれば（Ｙｅｓの場合におけるループのＩ順目）、監視対象自動追加処理、即ち、その構成要素を監視項目設定テーブルに追加設定する処理が行われる（Ｓ３００）。Ｓ２００の判定で依存先構成要素が存在していなければ、Ｓ４００に移行する。
【００４０】
Ｓ３００での監視対象自動追加処理を行うフローチャートの一例が、図６に示されている。この処理では、先ず、依存関係テーブル（［５］−５）から「性能劣化している構成要素」が依存する依存先構成要素が取得される（Ｓ１０００）。この例では、第１階層のポータルサーバが性能劣化を呈しているので、その原因を探るべく、図１３に示す依存関係テーブル（［５］−５）からその依存先構成要素である第２階層のポータルサーバリソースとＰｏｒｔａｌアプリケーションとが取得される。その構成要素がＳ３で設定された構成要素一覧テーブル（［３］−３）において、監視済み項目でｔｒｕｅであるか否かが判定される（Ｓ２０００）。ポータルサーバリソースとＰｏｒｔａｌアプリケーションとはまだ監視済み項目がｆａｌｓｅであるので、Ｓ２０００の判定結果はＮＯとなる。次に、依存関係テーブル（［５］−５）からポータルサーバリソースとＰｏｒｔａｌアプリケーションとの監視項目が取得され、Ｓ１で設定された監視目標値基準テーブル（［１］−１）から目標基準値が取得され、監視項目設定テーブルに追加設定される（Ｓ３０００）。図１４には、追加設定された監視項目設定テーブル（［６］−３００１）が示されている。監視項目設定テーブル（［６］−３００１）においては、構成要素ＩＤとして、テーブル（［６］−６）のときの「ｓｅｒｖｅｒ＿ｐｏｒｔａｌ」に加えて、構成要素名「ポータルサーバリソース」と「Ｐｏｒｔａｌアプリケーション」にそれぞれ対応した「ｒｅｓｏｕｒｃｅ＿ｐｏｒｔａｌ」と「ａｐｐ＿ｐｏｒｔａｌ」とが追加設定されている。ポータルサーバリソースとＰｏｒｔａｌアプリケーションとの監視済み項目がｆａｌｓｅからｔｒｕｅに変更し設定されることに対応して、構成要素一覧テーブルが、図１０に示す（［３］−３）から図１１に示す（［３］−４００１）に更新される（Ｓ４０００）。
【００４１】
監視対象自動追加処理が終了すると、性能劣化時処理に戻って、Ｓ３０００において図１４に示す監視項目設定テーブル（［６］−３００１）に設定された構成要素及び監視項目について監視装置２５によって監視を行い、追加された構成要素の分を含めて稼働情報を稼働情報テーブルに登録する（Ｓ４００）。図１６に示す自動追加処理後の稼働情報テーブル（［７］−４０１）に示すように、監視項目設定テーブル（［６］−３００１）に設定された構成要素及び監視項目について所定の時間毎に監視が行われ、その結果が稼働値として登録される。
【００４２】
次に、初期から監視されている構成要素の性能劣化が続いているか否かが判定される（Ｓ５００）。システムが改善されて性能劣化が続いていない場合にはＳ８００に移行するが、性能劣化が続いている場合には、Ｓ３００で監視が追加された構成要素の性能劣化が続いているか否かが更に判定される（Ｓ６００）。Ｓ６００の判定でＹｅｓの場合には、直ちにＳ２００に戻り、Ｓ６００の判定でＮｏの場合には、品質が目標値以内である（良い）追加監視分の構成要素を監視項目設定テーブルから削除する処理を行い（Ｓ７００）、その後、Ｓ２００に戻る。
【００４３】
図１６に示す稼働情報テーブル（［７］−４０１）の例では、初期から監視されている構成要素（ＩＤが「ｓｅｒｖｅｒ＿ｐｏｒｔａｌ」）のＨＴＴＰ応答時間の稼働値が２．０秒以上であって性能劣化が続いている。したがって、Ｓ５００の判定ではＹｅｓと判定される。監視が追加された構成要素のうち構成要素ＩＤ「ｒｅｓｏｕｒｃｅ＿ｐｏｒｔａｌ」については、監視項目「ＣＰＵ使用率」の稼働値が５６％であって、対応する分類名「Ｗｅｂサーバリソース」の監視項目「ＣＰＵ使用率」の目標基準値「７０％以下」を充足しており、監視項目「メモリ使用量」の稼働値が「物理メモリの容量の７５〜８２％」であって、対応する分類名Ｗｅｂサーバリソースのメモリ使用量の目標基準値「物理メモリの容量の１５０％以下」を充足している。しかしながら、追加設定された構成要素ＩＤ「ａｐｐ＿ｐｏｒｔａｌ」については、監視項目「ＣＰＵ使用率」の稼働値が５８％であって、対応する分類名「Ｗｅｂサーバアプリケーション」の監視項目「ＣＰＵ使用率」の目標基準値「５０％以下」を上回っており、性能劣化を示している。したがって、Ｓ６００の性能劣化継続の判定では、構成要素ＩＤ「ｒｅｓｏｕｒｃｅ＿ｐｏｒｔａｌ」についてはＮｏと判定され、Ｓ７００において監視項目設定テーブルから削除される。その結果、監視項目設定テーブル（［６］−７０１）で設定される構成要素は、ＩＤで「ｓｅｒｖｅｒ＿ｐｏｒｔａｌ」と「ａｐｐ＿ｐｏｒｔａｌ」とのみになる。Ｓ６００の判定で構成要素ＩＤ「ａｐｐ＿ｐｏｒｔａｌ」についてはＹｅｓと判定されるので、Ｓ２００からのフローが繰り返される。
【００４４】
性能劣化している構成要素ＩＤ「ａｐｐ＿ｐｏｒｔａｌ」については、図１３に示している依存関係テーブル（［５］−５）において、依存する構成要素が第３階層中に有るか否かが判定される（Ｓ２００）。本例の場合、依存関係テーブル（［５］−５）から、依存先構成要素である「Ｍａｉｌサーバ（分類名「メールサーバ」）」と、「ＳＣＨＥＤＵＬＥサーバ（分類名「スケジュールサーバ」）とが存在しており、Ｓ２００の判定がＹｅｓの場合におけるループのＩＩ順目に入る。続いて、監視対象自動追加処理が行われ（Ｓ３００）、これらの構成要素が監視項目設定テーブルに追加設定される。具体的には、依存関係テーブルから上記二つの依存先構成要素が取得され（Ｓ１０００）、両構成要素が図１１に示す自動追加処理後の構成要素一覧テーブル（［３］−４００１）で「監視済み」項目がｔｒｕｅであるか否かが判定される（Ｓ２０００）。本例の場合「否」であるので、図１３に示す依存関係テーブル（［５］−５）から分類名に対応する監視項目（Ｍａｉｌサーバの監視項目は「ＳＭＴＰ応答時間」、ＳＣＨＥＤＵＬＥサーバの監視項目は「ＨＴＴＰ応答時間」）が取得され、また図８に示す監視目標基準値テーブル（［１］−１）からその監視項目の目標値が取得されて、構成要素が監視項目設定テーブルに追加設定される（Ｓ３０００）。図１４には、このときの監視項目設定テーブルが（［６］−３００２）に示されている。前回の監視項目設定テーブル（［６］−７０１）に対して、二つの構成要素ＩＤ（「ｓｅｒｖｅｒ＿ｍａｉｌ］」と「ｓｅｒｖｅｒ＿ｓｃｈｅｄｕｌｅ」）が追加設定されているのが判る。また、構成要素一覧テーブルで、その追加構成要素の「監視済み」項目が新たにｔｒｕｅに変更される。変更された構成要素一覧テーブルが図１１において（［３］−４００２）に示されている。
【００４５】
監視項目設定テーブル（［６］−３００２）に従って監視装置２５が監視を行い、稼働情報が稼働情報テーブルに登録される。登録された稼働情報テーブルが図１６において（［７］−４０２）に示されている。稼働情報テーブル［７］−４０２）からすると、Ｓ５００の判断において、初期監視の対象となっている構成要素ＩＤ「ｓｅｒｖｅｒ＿ｐｏｒｔａｌ」と「ａｐｐ＿ｐｏｒｔａｌ」は性能劣化した状態が続いていると判定される。次のＳ６００の判断において、追加された監視対象となった構成要素ＩＤ「ｓｅｒｖｅｒ＿ｍａｉｌ］」と「ｓｅｒｖｅｒ＿ｓｃｈｅｄｕｌｅ」は、稼働値が目標値に納まっているので、性能劣化状態ではないと判断され、Ｓ７００に移行する。Ｓ７００においては、品質が目標値以内である追加監視の対象となった構成要素が監視項目設定テーブルから削除される。削除された監視項目設定テーブルが図１４において（［６］−７０２）に示されており、監視項目設定テーブル（［６］−３００２）では追加されていた構成要素ＩＤ「ｓｅｒｖｅｒ＿ｍａｉｌ］」と「ｓｅｒｖｅｒ＿ｓｃｈｅｄｕｌｅ」が削除されていることが判る。
【００４６】
Ｓ７００における処理の後、フローはＳ２００に戻る。性能劣化している構成要素は存在しているので、Ｓ３００の監視対象自動追加処理に移行するが、その構成要素が構成要素一覧テーブルにおける「監視済み」項目が既にｔｒｕｅであるので、Ｓ２０００の判断でＹｅｓと判定され、追加設定は行われない。次に、Ｓ５００において、既存の監視対象となっている構成要素の性能劣化が継続しているか否かが判定されるが、システムの改善が行われるので、いずれはＮｏの判定となる。ＩＩＩ順目の稼働情報テーブルが図１６における（［７］−４０３）に示されており、ここではシステムの改善が行われていることが示されている。
【００４７】
以上のように、Ｓ７から開始されるシステム改善支援システム１の稼働に伴い、Ｓ１０の性能劣化時の一連の処理が行われ、システム改善者がシステム改善支援システム１に稼働情報を出力させ、対象システム２０の問題となっている構成要素を特定する。例えば、ポータルサーバのＨＴＴＰ応答時間の遅延はシステムのバックボーンにあるＰｏｒｔａｌアプリケーションに起因している旨の特定がなされる。システム改善者は、このレポートを見て顧客に対象システム２０の改善を提案する。
【００４８】
Ｓ５００でのＮｏの判定を受けて、Ｓ８００において監視対象初期化処理が行われる。図７は、監視対象初期化処理を行うフローチャートの一例を示す図である。図７のフローチャートに示すように、Ｓ８００では、監視項目設定テーブルから、「追加監視分の構成要素」の設定がすべて削除される（Ｓ５０００）。「追加監視分の構成要素」の設定を削除した後の監視項目設定テーブルが図１４における（［６］−５０００）に示されている。監視項目設定テーブル（［６］−５０００）によれば、当初の監視項目設定テーブル（［６］−６）に戻っていることが判る。次に、構成要素一覧テーブルで「追加監視分の構成要素」の「監視済み」項目をすべて「ｆａｌｓｅ」に設定する（Ｓ６０００）。この設定後の構成要素一覧テーブルが，図１１において（［３］−６０００）（内容は、既説明の構成要素一覧テーブル（［３］−３）に同じ）に示されている。
【００４９】
監視対象初期化処理（Ｓ８００）の終了を受けて、システム改善者テーブル（［２］−２）からメールアドレスを取得し、初期監視対象となった構成要素の品質が目標値以内に戻ったことをメール送信してシステムのユーザに知らせて、性能劣化時処理を終了する。
【００５０】
図１７は、本システム改善支援システムと既存の同システムとのプロセスの異なる点を表形式にまとめた図である。
「１．情報収集」については、そのプロセス内容は、システム改善者が顧客情報（構成情報、業務内容、ニーズ等）を収集することであり、両システムとも、同じである。
「２及び３．監視対象設定」については、既存システムでは、プロセス内容は、システム改善者が顧客情報に基づいて監視対象となる構成要素を対象システム全体の中から複数選定しているのに対して、本システムでは、システム改善者が顧客情報を基に初期の監視対象となる構成要素を選定している。
「４及び５．情報設定」については、既存システムでは、システム改善者が監視対象となる構成要素の情報をシステム改善支援システムに設定しているが、本システムでは、それに加えて、更に、システム改善者が必要な情報を対象システムに置かれる監視装置２５ではなくシステム改善支援システム側に設定している。設定する情報としては、監視目標基準値、システム改善者のメールアドレス、構成要素毎の情報、構成要素間の依存関係が挙げられる。
「６．監視」については、既存のシステムも本システムも、共に、監視装置２５（システム改善支援装置）が、設定された構成要素を監視する。
「７〜９. 監視対象追加」については、既存のシステムでは、監視対象は予め設定されており、追加はできなかったのに対して、本システムでは、
「７」システム改善支援装置が監視対象構成要素の性能劣化時に、監視結果と設定された情報を基に、新しく監視対象となる構成要素を選定し、システム改善支援装置に設定することができる。
「８」上記順番６〜７．を繰り返す。
「９」システム改善支援装置が、初期の監視対象構成要素の性能劣化時に、システム改善者宛にメールを送信して知らせることができる。
「１０．問題要素特定」については、既存のシステムも本システムも、システム改善者が監視結果と構成情報とを基に、対象システムの問題となっている構成要素を特定する。
「１１．改善提案」については、既存のシステムも本システムも、システム改善者が、顧客へ対象システムの改善案を提案する。
【図面の簡単な説明】
【００５１】
【図１】この発明によるシステム改善支援システムのシステム構成図。
【図２】図１に示すシステム改善支援システムの各データベースのデータ構造図。
【図３】システム改善支援システムが対象とする対象システムの依存関係を示す階層構成図。
【図４】この発明におけるシステム改善支援システムの全体の処理の流れの一例を示すフローチャート。
【図５】この発明におけるシステム改善支援システムによる性能劣化時処理の一例を示すフローチャート。
【図６】この発明におけるシステム改善支援システムによる監視対象自動追加処理の一例を示すフローチャート。
【図７】この発明におけるシステム改善支援システムによる監視対象初期化処理の一例を示すフローチャート。
【図８】監視目標値基準テーブルの一例を示す図。
【図９】システム改善者テーブルの一例を示す図。
【図１０】構成要素一覧テーブルの一例を示す図。
【図１１】自動追加処理後の構成要素一覧テーブルを示す図。
【図１２】構成要素属性テーブルの一例を示す図。
【図１３】依存関係テーブルの一例を示す図。
【図１４】監視項目設定テーブルの一例を示す図。
【図１５】稼働情報テーブルの一例を示す図。
【図１６】自動追加処理の後の稼働情報テーブルを示す図。
【図１７】システム改善支援システムと既存のシステムとのプロセスの同異を表形式にまとめた図。
【図１８】既存のシステム改善支援システムの一例を示すシステム構成図である。
【図１９】対象システムの一例を示すシステム構成図である。
【符号の説明】
【００５２】
１ システム改善支援システム
２ 入力装置
３ 収集装置
４ 稼働情報データベース
５ 出力装置
６ 構成情報データベース
７ 評価装置
８ システム改善者データベース
９ メール送受信装置
１０ 既存のシステム改善支援システム
２０ 対象システム
２１〜２４ 構成要素
２５ 監視装置
２６ 監視項目データベース
【特許請求の範囲】
【請求項１】
複数の構成要素及び前記各構成要素をその監視項目について監視する監視装置を備えた対象システムを前記監視装置によって得られた前記構成要素の稼働情報に基づいて改善するのを支援するシステム改善支援システムにおいて、監視対象とされた前記構成要素が当該構成要素の前記稼働情報に基づいて性能劣化しているか否かを判定する性能判定処理と、前記性能判定処理において前記構成要素が性能劣化と判定されるときのみ前記構成要素が依存する前記構成要素を更なる前記監視対象として自動追加する自動追加処理とを行うことから成るシステム改善支援システム。
【請求項２】
前記自動追加処理において前記監視対象として前記構成要素が追加されたとき、追加された前記構成要素についての前記性能判定処理と、当該構成要素が性能劣化と判定されるときに当該構成要素が依存する前記構成要素を更なる前記監視対象に追加する前記自動追加処理とを繰り返して行うことから成る請求項１に記載のシステム改善支援システム。
【請求項３】
前記監視対象として追加された前記構成要素が性能劣化していないと前記性能判定処理において判定されるとき、当該構成要素を前記監視対象から削除する監視対象削除処理を行うことから成る請求項２に記載のシステム改善支援システム。
【請求項４】
繰り返される一連の前記自動追加処理において、前記監視対象削除処理において前記監視対象から削除された前記構成要素は前記監視対象として自動追加しないことから成る請求項３に記載のシステム改善支援システム。
【請求項５】
前記対象システムを利用するエンドユーザに最も近い前記構成要素のみを、前記監視装置による監視開始時における初期監視対象とすることから成る請求項１に記載のシステム改善支援システム。
【請求項６】
前記初期監視対象とされた前記構成要素の性能劣化が正常値に改善されたとき、当該構成要素以外のすべての前記構成要素についての前記監視装置による監視を終了することから成る請求項５に記載のシステム改善支援システム。
【請求項７】
前記初期監視対象が前記性能判定処理において性能劣化と判定されるときに、その旨をシステム改善者にメールにて自動送信することから成る請求項５に記載のシステム改善支援システム。
【請求項８】
前記自動追加処理において、前記対象システムに備わっていて前記各構成要素の前記監視項目を登録可能であり且つ前記監視装置が監視する前記構成要素について前記監視項目を提供する監視項目データベースに、更なる前記監視対象となる前記構成要素とその監視項目とを自動追加することから成る請求項１に記載のシステム改善支援システム。
【請求項９】
前記監視項目毎の目標基準値が予め記憶されている目標基準値テーブルを備えており、前記性能判定処理において、前記構成要素が性能劣化しているか否かを、当該構成要素の前記稼働情報が前記目標基準値テーブルに記憶されている前記目標基準値と比較・評価することで判定することから成る請求項１に記載のシステム改善支援システム。
【請求項１】
複数の構成要素及び前記各構成要素をその監視項目について監視する監視装置を備えた対象システムを前記監視装置によって得られた前記構成要素の稼働情報に基づいて改善するのを支援するシステム改善支援システムにおいて、監視対象とされた前記構成要素が当該構成要素の前記稼働情報に基づいて性能劣化しているか否かを判定する性能判定処理と、前記性能判定処理において前記構成要素が性能劣化と判定されるときのみ前記構成要素が依存する前記構成要素を更なる前記監視対象として自動追加する自動追加処理とを行うことから成るシステム改善支援システム。
【請求項２】
前記自動追加処理において前記監視対象として前記構成要素が追加されたとき、追加された前記構成要素についての前記性能判定処理と、当該構成要素が性能劣化と判定されるときに当該構成要素が依存する前記構成要素を更なる前記監視対象に追加する前記自動追加処理とを繰り返して行うことから成る請求項１に記載のシステム改善支援システム。
【請求項３】
前記監視対象として追加された前記構成要素が性能劣化していないと前記性能判定処理において判定されるとき、当該構成要素を前記監視対象から削除する監視対象削除処理を行うことから成る請求項２に記載のシステム改善支援システム。
【請求項４】
繰り返される一連の前記自動追加処理において、前記監視対象削除処理において前記監視対象から削除された前記構成要素は前記監視対象として自動追加しないことから成る請求項３に記載のシステム改善支援システム。
【請求項５】
前記対象システムを利用するエンドユーザに最も近い前記構成要素のみを、前記監視装置による監視開始時における初期監視対象とすることから成る請求項１に記載のシステム改善支援システム。
【請求項６】
前記初期監視対象とされた前記構成要素の性能劣化が正常値に改善されたとき、当該構成要素以外のすべての前記構成要素についての前記監視装置による監視を終了することから成る請求項５に記載のシステム改善支援システム。
【請求項７】
前記初期監視対象が前記性能判定処理において性能劣化と判定されるときに、その旨をシステム改善者にメールにて自動送信することから成る請求項５に記載のシステム改善支援システム。
【請求項８】
前記自動追加処理において、前記対象システムに備わっていて前記各構成要素の前記監視項目を登録可能であり且つ前記監視装置が監視する前記構成要素について前記監視項目を提供する監視項目データベースに、更なる前記監視対象となる前記構成要素とその監視項目とを自動追加することから成る請求項１に記載のシステム改善支援システム。
【請求項９】
前記監視項目毎の目標基準値が予め記憶されている目標基準値テーブルを備えており、前記性能判定処理において、前記構成要素が性能劣化しているか否かを、当該構成要素の前記稼働情報が前記目標基準値テーブルに記憶されている前記目標基準値と比較・評価することで判定することから成る請求項１に記載のシステム改善支援システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【公開番号】特開２００６−１８３６９（Ｐ２００６−１８３６９Ａ）
【公開日】平成１８年１月１９日（２００６．１．１９）
【国際特許分類】
【出願番号】特願２００４−１９２７８４（Ｐ２００４−１９２７８４）
【出願日】平成１６年６月３０日（２００４．６．３０）
【出願人】（０００２３３４９１）日立電子サービス株式会社 (394)
【Ｆターム（参考）】
【公開日】平成１８年１月１９日（２００６．１．１９）
【国際特許分類】
【出願日】平成１６年６月３０日（２００４．６．３０）
【出願人】（０００２３３４９１）日立電子サービス株式会社 (394)
【Ｆターム（参考）】
[ Back to top ]