JP6988304B2 - 運用管理システム、監視サーバ、方法およびプログラム - Google Patents

Description

本発明は、ＩＣＴシステムの運用管理を行う運用管理システム、管理サーバ、運用管理方法および運用管理プログラムに関する。

ＩＣＴ（Information and Communication Technology）システムの多くでは、システム管理者が、ＩＣＴシステムが正常に稼動していることを運用管理システムにより監視している。システム管理者は、ＩＣＴシステムの障害を検知した場合、適切な対処を行って直ちに復旧を行う必要がある。

このようなＩＣＴシステム障害に対応するための技術の一例が特許文献１，２に記載されている。特許文献１に記載の方法は、複数の処理装置がそれぞれ、自装置において障害が発生した時に障害に関与する稼動データを収集し、障害箇所や障害状況を示すデータと併せて診断データを作成して記憶部に一時的に蓄積する。そして、診断エンジンが、診断対象とされる処理装置の診断データと類似するデータを、同様の診断データを診断データベースに蓄積した内容から抽出することにより、障害発生状況の類似性を基に障害対処に有益な情報を提供する。

また、特許文献２に記載の方法は、内部状態を示すパラメータに対して、値の変化に因果関係があるパラメータ間のある一定機関の相関係数を時系列に数値化して相関データ列を作成し、２つの相関データ列が閾値を超えた場合に、それらの相関データに共通するパラメータを特定して、該パラメータに予め対応づけられた障害を予測する。また、該方法は、共通するパラメータがない場合、それらの相関データ列の距離の相関の類似度を計算しなおし、障害原因とする共通パラメータを特定する。

特開２００４−０２１３９６号公報 特開２０１３−０４１１７３号公報

しかし、ナレッジデータベースから適切な対処方法を抽出するためには、障害が発生した時にその障害に対する全ての原因事象が正しく特定される必要がある。

例えば、ＣＰＵ使用率が高負荷になった影響で障害が起きるのであれば、監視対象のＣＰＵ使用率の閾値を設定すればよい。しかし、ＩＣＴシステムの多くは複数のサーバからなり、１台あたりがＣＰＵやＤｉｓｋ、ネットワークといった複数の計算資源を有する。このため、監視対象の稼動状況を示す数値（ＣＰＵ使用率やＤｉｓｋ使用量など）の数は膨大になる。それら稼動状況を示す数値の中のうち１つもしくは複数の数値の組み合わせにより表される原因事象を、障害発生の度に管理者が適切に判断することは非常に困難である。

そのため、運用管理システム側で、障害に対する全て原因事象を抽出することが求められるが、特許文献１，２に記載の方法は、障害に対して全ての原因事象を特定するには、以下の点で不十分である。

ある障害に対する原因事象を漏れなく特定するためには、情報収集、収集されたデータの加工および類否判定を、漏れなくかつ適切に行う必要があるが、例えば、特許文献１に記載の方法は、障害を検知した処理装置の稼動データしか診断データに含めない。このため、ネットワークを介して処理装置間が通信しながら行う処理で発生した障害に対して、適切な診断が下せない場合がある。

また、特許文献２に記載の方法は、障害発生時に、内部状態を示すパラメータに対して値の変化に因果関係があるパラメータを特定した上で、該パラメータ間のある一定期間の相関係数を時系列に数値化して相関データ列を作成する。そして、過去の相関データ列との間で共通するパラメータを障害原因として特定する。このため、例えば、因果関係をもつ複数のパラメータが同時に異常値を示すような障害に対しては相関係数が変化しないため、障害原因とするパラメータを特定できないという問題がある。

本発明は、上述した課題に鑑み、管理者が原因事象を特定しなくても、現在の事象に対して適切な対処方法を管理者に提示できる運用管理システム、監視サーバ、運用管理方法および運用管理プログラムを提供することを目的とする。

本発明による運用管理システムは、予め定められた１つまたは複数の監視対象もしくは監視対象のうち特定の監視対象に代えて当該監視対象をモニタリングする特定のモニタ装置と管理用ネットワークで接続される監視サーバを備え、監視サーバは、監視対象の少なくともいずれかにおける障害発生時に、監視対象の稼動状況を示す情報を収集する稼動情報収集手段と、稼動情報収集手段が収集した情報を基に、障害発生時の状況を示すベクトルであって、収集された全ての監視対象の稼動状況を示す情報の数以上の次元数を有するベクトルである特徴ベクトルを生成する特徴ベクトル生成手段と、監視対象の少なくともいずれかにおいて過去に発生した障害を対象に、当該障害を識別する情報と、当該障害が発生したときの特徴ベクトルと、当該障害を復旧させるために実施した対処方法を示す情報とを対応づけて記憶するナレッジ記憶手段と、監視対象の少なくともいずれかにおいて新たに障害が発生すると、ナレッジ記憶手段に記憶された同種の過去の障害への対処方法の中から、当該新たな障害が発生したときの特徴ベクトルである第１特徴ベクトルとの類似度が高い特徴ベクトルと対応づけられた対処方法を優先して提示する対処方法提示手段とを含むことを特徴とする。

本発明による監視サーバは、予め定められた１つまたは複数の監視対象もしくは監視対象のうち特定の監視対象に代えて当該監視対象をモニタリングする特定のモニタ装置と管理用ネットワークで接続され、監視対象の少なくともいずれかにおける障害発生時に、監視対象の稼動状況を示す情報を収集する稼動情報収集手段と、稼動情報収集手段が収集した情報を基に、障害発生時の状況を示すベクトルであって、収集された全ての監視対象の稼動状況を示す情報の数以上の次元数を有するベクトルである特徴ベクトルを生成する特徴ベクトル生成手段と、監視対象の少なくともいずれかにおいて過去に発生した障害を対象に、当該障害を識別する情報と、当該障害が発生したときの特徴ベクトルと、当該障害を復旧させるために実施した対処方法を示す情報とを対応づけて記憶するナレッジ記憶手段と、監視対象の少なくともいずれかにおいて新たに障害が発生すると、ナレッジ記憶手段に記憶された同種の過去の障害を対象に、当該新たな障害が発生したときの特徴ベクトルである第１特徴ベクトルとの類似度が高い特徴ベクトルと対応づけられた対処方法を優先して提示する対処方法提示手段とを備えたことを特徴とする。

また、本発明による運用管理方法は、予め定められた１つまたは複数の監視対象もしくは監視対象のうち特定の監視対象に代えて当該監視対象をモニタリングする特定のモニタ装置と管理用ネットワークで接続される監視サーバが、監視対象の少なくともいずれかにおける障害発生時に、監視対象の稼動状況を示す情報を収集し、収集した情報を基に、障害発生時の状況を示すベクトルであって、収集された全ての監視対象の稼動状況を示す情報の数以上の次元数を有するベクトルである特徴ベクトルを生成し、監視対象の少なくともいずれかにおいて過去に発生した障害について、当該障害を識別する情報と、当該障害が発生したときの特徴ベクトルと、当該障害を復旧させるために実施した対処方法を示す情報とを対応づけて記憶するナレッジ記憶手段を検索して、ナレッジ記憶手段に記憶された同種の過去の障害への対処方法の中から、新たな障害が発生したときの特徴ベクトルである第１特徴ベクトルとの類似度が高い特徴ベクトルと対応づけられた対処方法を優先して提示することを特徴とする。

また、本発明による運用管理プログラムは、予め定められた１つまたは複数の監視対象もしくは監視対象のうち特定の監視対象に代えて当該監視対象をモニタリングする特定のモニタ装置と管理用ネットワークで接続されるコンピュータに、監視対象の少なくともいずれかにおける障害発生時に、監視対象の稼動状況を示す情報を収集する処理、収集した情報を基に、障害発生時の状況を示すベクトルであって、収集された全ての監視対象の稼動状況を示す情報の数以上の次元数を有するベクトルである特徴ベクトルを生成する処理、および監視対象の少なくともいずれかにおいて過去に発生した障害について、当該障害を識別する情報と、当該障害が発生したときの特徴ベクトルと、当該障害を復旧させるために実施した対処方法を示す情報とを対応づけて記憶するナレッジ記憶手段を検索して、ナレッジ記憶手段に記憶された同種の過去の障害への対処方法の中から、新たな障害が発生したときの特徴ベクトルである第１特徴ベクトルとの類似度が高い特徴ベクトルと対応づけられた対処方法を優先して提示する処理を実行させることを特徴とする。

本発明によれば、管理者が原因事象を特定しなくても、現在の事象に対して適切な対処方法を管理者に提示できる。

第１の実施形態の運用管理システムの構成例を示す模式構成図である。 監視サーバ１のより詳細な構成例を示すブロック図である。 第１の実施形態の運用管理システムの動作の一例を示すフローチャートである。 障害発生時点の各監視対象マシンの稼動状況を示す情報の例を示す説明図である。 ナレッジＤＢ１０５に格納されるデータの例を示す説明図である。 ナレッジＤＢ１０５内の特徴ベクトルと今回の障害発生時の特徴ベクトルとの間のユークリッド距離の計算結果を示す説明図である。 ナレッジＤＢ１０５内の対処ＩＤを類似度の高い順に並び変えた例を示す説明図である。 類似度を基にした対処方法の提示例を示す説明図である。 類似度補正係数更新後の類似度計算結果の例を示す説明図である。 収集された各監視対象マシンの稼動状況を示す情報の例を示す説明図である。 ナレッジ更新部１０８によるナレッジＤＢ１０５への対処方法登録処理の処理フローの例を示すフローチャートである。 登録された新たな対処方法の例を示す説明図である。 更新後のナレッジＤＢ１０５の例を示す説明図である。 本発明の実施形態にかかるコンピュータの構成例を示す概略ブロック図である。 本発明の運用管理システムの概要を示すブロック図である。

実施形態１．
以下、図面を参照して本発明の実施形態について説明する。図１は、第１の実施形態の運用管理システムの構成例を示す模式構成図である。図１に示す運用管理システムは、監視サーバ１と、１つまたは複数の監視対象マシン２とを含む。監視サーバ１と監視対象マシン２の各々とは、管理用ネットワーク３を介して接続されている。

監視対象マシン２の各々（監視対象マシン２−１〜２−ｎ）には、所定のエージェントプログラムが配置されており、該エージェントプログラムが動作することにより自マシンの稼動状況を示す１つまたは複数の情報を定期的に収集する。エージェントプログラムが収集したこれらの情報は、監視サーバ１に集められる。

なお、図１は、本実施形態の運用管理システムを模式的に説明するための例示であって、システム構成を制限するものではない。例えば、監視対象マシン２は３台に限定されない。また、監視対象となるマシン（コンピュータ）に限らず、ネットワークやストレージも含む。

図２は、監視サーバ１のより詳細な構成例を示すブロック図である。図２に示す例は、監視サーバ１内部で動作する本実施形態のプログラムの論理的な構成の例を表したものである。図２に示す例では、監視サーバ１は、稼動情報収集部１０１と、障害検知部１０２と、特徴処理部１０３と、類似度処理部１０４と、ナレッジＤＢ（DataBase）１０５と、ＵＩ（User Interface）処理部１０６と、操作処理部１０７と、ナレッジ更新部１０８と、類似度計算学習処理部１０９と、類似度計算手段格納部１１０とを含む

稼動情報収集部１０１は、監視対象マシン２の各々について、管理用ネットワーク３を介して稼動状況を示す情報を取得する。また、稼動情報収集部１０１は、ＵＩ処理部１０６を介して収集した稼動情報を示す情報をシステム管理者に提示する。

以下では、稼動情報収集部１０１が、監視対象マシン２の稼動状況を示す情報として、ＣＰＵ使用率、メモリ使用率、Ｄｉｓｋ Ｉ／Ｏ（Input／Output）性能およびＮＷ（Network） Ｉ／Ｏ性能を収集する例を示すが、稼動状況を示す情報はこれらに限定されない。

障害検知部１０２は、各監視対象マシン２における障害の発生／復旧を検知する。障害検知部１０２における各監視対象マシン２における障害の発生／復旧の検知方法は特に限定されない。障害検知部１０２は、例えば、監視対象マシン２から収集した稼動状況を示す情報を基に、該監視対象マシン２の障害の発生／復旧を検知してもよいし、監視対象マシン２または他のマシン（ＮＷ上の隣接するマシン、ストレージ管理マシン、ＮＷ管理マシン等）から送信される監視対象マシン２上での障害の発生／復旧を知らせる障害通知を基に、該監視対象マシン２の障害の発生／復旧を検知してもよい。

障害検知部１０２は、障害の発生または復旧を検知すると、特徴処理部１０３とナレッジ更新部１０８とに対してその旨（検知した内容）を示す障害情報または復旧情報を通知する。また、障害検知部１０２は、ＵＩ処理部１０６を介して検知した障害情報または復旧情報をシステム管理者に提示する。障害情報または復旧情報には、例えば、どこで、どのような障害が発生または復旧したかを示す情報が含まれる。このとき、どのような障害が発生したか（障害の種別）は、システム管理者が登録することも可能である。

特徴処理部１０３は、稼動情報収集部１０１により収集された各監視対象マシン２の稼動状況を示す情報から、それらの情報をまとめた１つまたは複数の特徴ベクトルを生成する。特徴ベクトルは、監視対象マシン２ごとに生成されてもよいし、監視対象マシン２をグループ化した上でそれらグループごとに生成することも可能である。前者の場合、特徴処理部１０３は、例えば、１つの監視対象マシン２から収集した複数の項目を含む稼動状況を示す情報を１つにまとめて、１つの特徴ベクトルを生成する。後者の場合、特徴処理部１０３は、例えば、関連する複数の監視対象マシン２から収集した、それぞれ複数の項目を含む稼動状況を示す情報をまとめて１つの特徴ベクトルを生成する。このとき、特徴処理部１０３は、予めグループ分けされた結果、同一グループに属する監視対象マシン２から収集した、それぞれ複数の項目を含む稼動状況を示す情報をまとめて１つの特徴ベクトルを生成してもよい。なお、このとき１つの監視対象マシン２が複数のグループに属してもよい。１つの障害発生時に生成される特徴ベクトルの総次元数（複数の特徴ベクトルが生成される場合は各特徴ベクトルの次元数の和）は、全ての監視対象マシン２の稼動状況を示す情報の数と同じかまたはそれよりも多いのが好ましい。なお、複数の特徴ベクトルを生成する場合、以降の処理ではそれらを連結したものを１つの特徴ベクトルとして扱えばよい。

類似度処理部１０４は、特徴処理部１０３から障害情報と特徴ベクトルを受信し、後述するナレッジＤＢ１０５から過去の障害に対して実施された対処方法を示す情報を検索する。

ナレッジＤＢ１０５は、過去の障害に関する対処方法の履歴として、障害情報、特徴ベクトルおよび障害復旧のための対処方法を示す情報を含む情報を格納する。

ＵＩ処理部１０６は、障害検知部１０２から受信した障害情報と、類似度処理部１０４から受信した対処方法の候補（一覧）とをシステム管理者に提示して、障害が発生したことを知らせるとともに、システム管理者が行った今回の障害への対処方法に関する情報である対処情報の入力を受け付ける。

操作処理部１０７は、ＵＩ処理部１０６が受け付けたシステム管理者の対処情報を、関連する監視対象マシン２や対処の対象マシンに送信するとともに、ナレッジ更新部１０８に送信する。

類似度計算手段格納部１１０は、特徴処理部１０３が生成した障害発生時の特徴ベクトルと、ナレッジＤＢ１０５に格納された特徴ベクトルとの類似度計算に用いる手段（類似度計算手段）に関する情報（パラメータ等）を格納する。

次に、本実施形態の動作を説明する。図３は、本実施形態の運用管理システムの動作の一例を示すフローチャートである。図３に示す例は、監視対象マシン２のいずれかで障害が発生した時に監視サーバ１内で行われる、システム管理者への対処方法提示処理の例である。本例の対処方法提示処理は、障害検知部１０２が、監視対象マシン２の少なくともいずれかで障害が発生したことを検知し、特徴処理部１０３に障害情報を送信するところから開始される。なお、本例では、障害検知部１０２が障害「Ｗｅｂページのアクセス失敗（タイムアウト）」を検知したとする。また、本例では、監視対象が、監視対象マシン２−１、監視対象マシン２−２および監視対象マシン２−３の３台であるとする。

図３に示すように、特徴処理部１０３は、障害検知部１０２から障害情報を受信すると、障害発生時の監視対象の稼動状況を示す情報を取得する（ステップＳ１０１）。本例では、稼動情報収集部１０１が監視対象マシン２の各々から稼動状況を示す情報として、ＣＰＵ使用率、メモリ使用率、Ｄｉｓｋ Ｉ／ＯおよびＮＷ Ｉ／Ｏを取得していた。ステップＳ１０１では、特徴処理部１０３が、これらの情報すなわち各監視対象マシン２のＣＰＵ使用率、メモリ使用率、Ｄｉｓｋ Ｉ／ＯおよびＮＷ Ｉ／Ｏを取得する。

図４に、障害発生時点の各監視対象マシンの稼動状況を示す情報の例を示す。なお、本例では、監視対象マシンの稼動状況を示す情報が全て数値で収集される例を示しているが、監視対象マシンの稼動状況を示す情報は、数値に限定されず、例えば、文字列等のテキスト形式の情報が含まれていてもよい。

次に、特徴処理部１０３は、取得した情報を基に、特徴ベクトルを生成する（ステップＳ１０２）。本例では、特徴処理部１０３は、全ての監視対象マシンの稼動状況を示す情報の数を次元の数とする特徴ベクトルを生成する。したがって、本例の特徴ベクトルは１２次元となる。また、特徴ベクトルの元の各値には、取得した稼動状況の情報をそのまま用いる。なお、稼動状況の情報として数値以外の情報が含まれていた場合には、当該情報を数値に変換した上で元として用いてもよい。また、特徴ベクトルは、元として、さらに取得した稼動状況の情報に関する統計値を含んでいてもよい。このとき、統計値は、障害発生時の稼動状況の情報に加えて、過去の稼動状況の情報を用いて計算されてもよい。以下に、本例の特徴ベクトルの構成例を示す。

特徴ベクトル：（監視対象マシン２−１のＣＰＵ使用率，監視対象マシン２−１のメモリ使用量，監視対象マシン２−１のＤｉｓｋ Ｉ／Ｏ，監視対象マシン２−１のＮＷ Ｉ／Ｏ，監視対象マシン２−２のＣＰＵ使用率，・・・，監視対象マシン２−３のＮＷ Ｉ／Ｏ）＝（８０，６０，１０，６０，８０，９０，２０，８０，１０，６０，３０，２０）

また、特徴処理部１０３は、生成した特徴ベクトルを、障害情報とともに類似度処理部１０４に送信する。

次いで、類似度処理部１０４は、特徴処理部１０３から障害情報と特徴ベクトルを取得すると、ナレッジＤＢ１０５を検索して、今回の障害が既知の事象であるか否かを判定する（ステップＳ１０３）。

図５は、ナレッジＤＢ１０５に格納されるデータの例を示す説明図である。類似度処理部１０４は、例えば、ナレッジＤＢ１０５に、今回の障害「Ｗｅｂページへのアクセス失敗（タイムアウト）」の対処方法を示す情報が格納されているかを検索し、１件でも格納されていれば、既知の障害（既知事象）であると判定する。

図５に示す例では、障害「Ｗｅｂページへのアクセス失敗（タイムアウト）」の対処方法として、対処ＩＤ＝Ａ，Ｂ，Ｃの３件の情報が蓄積されているため、既知事象と判定する。

今回の障害が既知事象である場合（ステップＳ１０３のＹｅｓ）、類似度処理部１０４は、特徴処理部１０３が生成した今回の障害発生時の特徴ベクトルと、ナレッジＤＢ１０５に記憶されている、同じ障害発生時の特徴ベクトルとの類似度を計算する類似度計算処理を行う（ステップＳ１０４）。なお、類似度の計算処理は、ナレッジＤＢ１０５の中で、障害事象が一致するナレッジ（レコード）のみを対象として行う。

本例では、図５に示すレコード、すなわち障害が「Ｗｅｂページのアクセス失敗（タイムアウト）」であるナレッジ（対処ＩＤ＝Ａ，Ｂ，Ｃのレコード）が類似度計算処理の対象とされる。

また、本例では、類似度計算の方法として、ユークリッド距離を用いる。ここで、ユークリッド距離が小さいほど特徴ベクトル間の類似度が高くなる。

図６に、ナレッジＤＢ１０５内の特徴ベクトルと今回の障害発生時の特徴ベクトルとの間のユークリッド距離の計算結果を示す。図６に示すように、ユークリッド距離はＢ＜Ｃ＜Ａとなり、Ｂ→Ｃ→Ａの順で類似度が高い結果となった。

次いで、類似度処理部１０４は、今回の障害に対する対処方法の候補として、特徴ベクトルの類似度の高い対処方法を優先して提示する（ステップＳ１０５）。

具体的に、類似度処理部１０４は、求めた類似度を基に、ナレッジを並べ替える。本例では、類似度処理部１０４は、類似度が高い順（本例では、ユークリッド距離が小さい順）に、類似度の算出対象としたナレッジを並べ替える。その後、類似度処理部１０４は、ＵＩ処理部１０６を介して、システム管理者に、優先順位の高い順に対処方法を提示する。図７は、ナレッジＤＢ１０５内の対処ＩＤを類似度の高い順に並び変えた例を示す説明図である。また、図８は、対処方法の提示例を示す説明図である。本例では、本実施例では類似度の高い対処方法ほどリストの上部に表示されるようにするものとする。

システム管理者は、表示されたリストの中で上位の対処方法ほど適切な対処方法であるとして、実際に実行する対処方法を選択し、実行する。このとき、システム管理者は、実行した対処方法の情報を、ＵＩ処理部１０６を介して監視サーバ１に入力する。ＵＩ処理部１０６は、例えば、リスト表示した対処方法の中から実行した対処方法をユーザに選択してもらう選択形式を用いて、該情報を入力させてもよいし、リスト表示した方法以外の対処方法を実行した場合等には自由形式でユーザに情報を入力させることも可能である。

該情報は、操作処理部１０７により受け付けられる。操作処理部１０７は、システム管理者がどの対処方法を実行したかを示す情報をナレッジ更新部１０８に送信する。

実行した対処方法により障害が復旧すると（ステップＳ１０６のＹｅｓ）、障害検知部１０２からナレッジ更新部１０８に復旧情報が通知され、ステップＳ１０７に進む。

以下では、まずＵＩ処理部１０６が表示した対処方法の中から選択された対処方法の実行により障害が復旧した場合を述べる。

ステップＳ１０７で、ナレッジ更新部１０８は、システム管理者が実行した対処方法が、提示した中で類似度が最も高いものか否かを判定する。なお、本例では、対処ＩＤ＝Ｂの対処方法が最も類似度の高いものである。

ナレッジ更新部１０８は、操作処理部１０７より、システム管理者がどの対処方法を実行したかを示す情報を受け付けており、その情報と復旧情報とを基に、一番上に表示されたナレッジすなわち特徴ベクトルの類似度が最も高かったナレッジの対処方法の実行により障害が復旧したか否かを判定すればよい。

提示した中で最も特徴ベクトル間の類似度が高かった対処方法で障害が復旧した場合（ステップＳ１０７のＹｅｓ）、ナレッジ更新部１０８はナレッジＤＢ１０５の更新を行わずに、障害対処提示処理を終了する。

一方、ナレッジ更新部１０８は、提示した中で最も特徴ベクトル間の類似度が高かった対処方法で障害が復旧しなかった場合、すなわち他の対処方法で障害が復旧した場合（ステップＳ１０７のＮｏ）、類似度計算学習処理部１０９に障害を復旧させた対処方法の情報を通知して、類似度計算処理の再学習をさせる（ステップＳ１０８）。

ステップＳ１０８では、類似度計算学習処理部１０９が、例えば、障害を復旧した対処方法の特徴ベクトルの類似度が、他に提示した対処方法の特徴ベクトルよりも高くなるように類似度計算手段（より具体的には、ナレッジＤＢ１０５内の類似度の計算方法を示す情報）を更新する。

また、今回発生した障害が既知の事象でない場合（ステップＳ１０３のＮｏ）またはステップＳ１０５で提示した対処方法以外の方法で、障害が復旧した場合（ステップＳ１０６のＮｏ）、類似度処理部１０４または操作処理部１０７は、ナレッジ更新部１０８にその旨を通知して対処方法の登録処理を行わせる（ステップＳ１０９）。

ステップＳ１０９では、ナレッジ更新部１０８が、例えば、今回の障害の障害情報と特徴ベクトルと操作処理部１０７から受け付けた今回の対処方法を示す情報とを対応づけて、新たな対処方法を含むナレッジとしてナレッジＤＢ１０５に格納する。

次に、類似度計算処理の再学習処理のより詳細な例を示す。本例において、各監視対象マシンの稼動状況を示す情報、ナレッジＤＢ１０５に格納される情報および特徴ベクトルのデータ構造は、上記と同様である。ただし、説明を簡単にするため、本例では、特徴ベクトルを次のように表す。

特徴ベクトル（１２次元）：（ａ，ｂ，ｃ，ｄ，ｅ，ｆ，ｇ，ｈ，ｉ，ｊ，ｋ，ｌ）

また、本例では、障害発生時の特徴ベクトルＶ_ｔと、ナレッジ中の特徴ベクトルＶ_ｎ＿ｉ（ｉはナレッジＤＢ１０５におけるナレッジの識別子）との類似度計算として以下の式（１）を用いる。なお、式（１）では、Ｖの添え字に用いた”ｔ”または“ｉ”を用いて、両者の特徴ベクトルの各元を区別している。例えば、ａ_ｔは、障害発生時の特徴ベクトルＶ_ｔの要素ａを表し、ａ_ｉはナレッジｉの特徴ベクトルＶ_ｎ＿ｉの要素ａを表す。また、αは類似度の補正係数である。本例では、学習前の補正係数α＝０とする。また、Δ_ｔｉが最も小さいナレッジが、類似度の最も高いものとする。

なお、上記の類似度計算式と補正係数αは、類似度計算手段格納部１１０に格納されている。

図８は、類似度を基にした対処方法の提示例を示す説明図である。今、図８に示すように、類似度の高い順に対処方法を提示した後で、ナレッジＣ（対処ＩＤ＝Ｃ）の対処方法で障害が復旧したとする。

本例のステップＳ１０７では、ナレッジ更新部１０８が、障害が復旧した際にシステム管理者が実行した対処方法が、提示した中で類似度が最も高いものか否かを判定した結果、そうでないと判定する。このとき、例えば、システム管理者により一番上に表示された対処方法が選択され実行されたが、障害が復旧しなかったとする。すると、ナレッジ更新部１０８は、図８の対処方法のうち一番上に表示されたナレッジＢ（対処ＩＤ＝Ｂ）が障害を復旧した対処方法ではないと判定してもよい。そして、ナレッジＢよりも特徴ベクトルの類似度が低いと計算されたナレッジＣの対処方法により障害が復旧したことを受けて、ナレッジ更新部１０８は、類似度が一番高い対処方法が障害を復旧していないと判定すると、類似度計算学習処理部１０９にナレッジＣが障害復旧に有効だったことを通知する。

類似度計算学習処理部１０９は、上記の通知を受けると、類似度計算手段格納部１１０内の類似度の補正係数αを更新する（ステップＳ１０８）。

類似度計算学習処理部１０９は、例えば、類似度処理部１０４から障害発生時の特徴ベクトルＶ_ｔと、類似度計算に利用したナレッジの特徴ベクトルＶ_ｎ＿ｉ（ｉ＝Ａ〜Ｃ）を取得し、障害を復旧させたナレッジ（本例では、ナレッジＣ）の類似度が最も高くなるように類似度補正係数α＝４０に更新する。

図９に、本例の類似度補正係数更新後の類似度計算結果を示す。なお、本例の類似度計算手段の再学習方法（補正方法）はあくまで一例であり、類似度計算手段の再学習方法は上記に限定されない。

次に、対処方法登録処理のより詳細な例を示す。本例において、各監視対象マシンの稼動状況を示す情報、ナレッジＤＢ１０５に格納される情報および特徴ベクトルのデータ構造は、上記の例と同様である。

ただし、本例において検知された障害は「ＤＢへのＩｎｓｅｒｔが失敗」であるとする。また、本例において障害発生時に収集された各監視対象マシンの稼動状況を示す情報は図１０の通りとする。図１０より、障害発生時の特徴ベクトルは次のようになる。なお、ナレッジＤＢ１０５内の情報は図５のままとする。

特徴ベクトル（１２次元）：（６０，３０，３０，６０，３０，４０，３０，８０，２０，５０，０，６０）

本例では、ステップＳ１０３において、類似度処理部１０４が今回の障害情報と生成された特徴ベクトルＶ_ｔとを基にナレッジＤＢ１０５を検索した結果、今回発生した障害が既知の事象でないと判定する。すなわち、類似度処理部１０４は、ナレッジＤＢ１０５に障害「ＤＢへのＩｎｓｅｒｔが失敗」の対処方法が格納されているかを検索し、１件も格納されていないことから、既知障害でないと判定する。その結果、類似度処理部１０４は、ナレッジ更新部１０８に今回の障害が新規障害である旨を通知して、ステップＳ１０９に進む。

ステップＳ１０９では、ナレッジ更新部１０８が、新規障害であることの通知を受信すると、今回の障害情報と特徴ベクトルとを取得した上で、ナレッジＤＢ１０５を更新する。より具体的には、ナレッジ更新部１０８は、新規障害であることの通知を受けると、対処方法登録処理を開始する。

図１１は、ナレッジ更新部１０８による、ナレッジＤＢ１０５への対処方法登録処理の処理フローの例を示すフローチャートである。

図１１に示す例では、まず、ナレッジ更新部１０８または操作処理部１０７がシステム管理者による操作を記録する（ステップＳ２０１）。本例では、システム管理者による操作は、ＵＩ処理部１０６が障害発生時点または障害を通知した時点から受け付け、操作処理部１０７に随時送信される。操作処理部１０７は、ＵＩ処理部１０６から受信した操作内容（操作ログ等）を、今回の障害に対する復旧操作を示す情報としてナレッジ更新部１０８に送信する。

ナレッジ更新部１０８は、例えば、障害発生時点または障害を通知した時点から障害が復旧するまでの間に今回の障害に対する復旧動作として操作処理部１０７から受信した復旧操作を示す情報を、対処方法として記録する。ナレッジ更新部１０８は、このような対処方法の記録を、障害が復旧するまで繰り返す（ステップＳ２０２のＮｏ、ステップＳ２０１に戻る）。

そして、ナレッジ更新部１０８は、障害が復旧した場合に（ステップＳ２０２のＹｅｓ）、これまでに記録された対処方法をナレッジＤＢ１０５に格納する。なお、このとき、システム管理者が対処方法を編集できてもよい。

本例ではシステム管理者が以下の操作を実施したとする。
１．[確認] ＤＢサーバの空き容量
２．[実行] 新規ＨＤＤボリュームをマウント

そして、システム管理者が「新規ＨＤＤボリュームをマウント」操作を実行後、障害検知部１０２が障害復旧を検知したとする。ナレッジ更新部１０８は、障害検知部１０２から障害復旧の通知を受信すると、今回の障害への対処方法として、例えば、図１２に示す新たな対処方法を得る。

障害に対する新たな対処方法を得ると、ナレッジ更新部１０８は、今回の障害発生時の特徴ベクトルを、特徴処理部１０３より取得する（ステップＳ２０３）。なお、ステップＳ１０９等で既に特徴ベクトルを取得済みの場合は、ステップＳ２０３は省略される。

最後に、ナレッジ更新部１０８は、今回の障害の障害情報、障害発生時の特徴ベクトルおよび得られた対処方法を対応づけて、ナレッジＤＢ１０５に新たなナレッジとして格納することにより、ナレッジＤＢ１０５を更新する（ステップＳ２０４）。ナレッジ更新部１０８は、ナレッジＤＢ１０５を更新すると、対処方法登録処理が終了する。

図１３は、更新後のナレッジＤＢ１０５の例を示す説明図である。図５に示す例と比較すると、新たに対処ＩＤ＝Ｄのナレッジが追加されているのがわかる。

以上のように、本実施形態によれば、監視対象の各々またはそれ以外の装置から全ての管理対象の稼動状態を示す情報を収集し、障害発生時の該稼動状態を示す情報より特徴ベクトルを自動で生成する。そして、必要に応じてナレッジデータベースに障害事象、特徴ベクトルおよび対処方法を対応づけて保存して、その後に同様の障害が発生した際のナレッジとして利用する。その後、同様の障害が発生した場合、その時点の特徴ベクトルと、ナレッジＤＢに蓄積された同様の障害に対する対処方法のうち、特徴ベクトルの類似度が高いものから優先してシステム管理者に提示する。このため、監視対象の障害に対して原因事象を漏れなく検出するための条件の設定や相関係数の計算等を行わなくても、発生中の障害に対して有効な対処方法を提示できる。これは原因事象となりうる稼動状態を示す情報を間引かずに、１つまたは複数の特徴ベクトルとして保持するためである。

また、本実施形態によれば、特徴ベクトルの類似度が最も高い対処方法によって障害が復旧しなかった場合、類似度計算手段を更新する手段を有するので、同様の障害に対し有効な対処方法を提示する精度が向上する。

次に、本発明の実施形態にかかるコンピュータの構成例を示す。図１４は、本発明の実施形態にかかるコンピュータの構成例を示す概略ブロック図である。コンピュータ１０００は、ＣＰＵ１００１と、主記憶装置１００２と、補助記憶装置１００３と、インタフェース１００４と、ディスプレイ装置１００５と、入力デバイス１００６とを備える。

上述の実施形態の運用管理システムの各装置（監視サーバ１および監視対象マシン２）は、コンピュータ１０００に実装されてもよい。その場合、各ノードの動作は、プログラムの形式で補助記憶装置１００３に記憶されていてもよい。ＣＰＵ１００１は、プログラムを補助記憶装置１００３から読み出して主記憶装置１００２に展開し、そのプログラムに従って各実施形態における所定の処理を実施する。なお、ＣＰＵ１００１は、プログラムに従って動作する情報処理装置の一例であり、ＣＰＵ（Central Processing Unit）以外にも、例えば、ＭＰＵ（Micro Processing Unit）やＭＣＵ（Memory Control Unit）やＧＰＵ（Graphics Processing Unit）などを備えていてもよい。

補助記憶装置１００３は、一時的でない有形の媒体の一例である。一時的でない有形の媒体の他の例として、インタフェース１００４を介して接続される磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等が挙げられる。また、このプログラムが通信回線によってコンピュータ１０００に配信される場合、配信を受けたコンピュータは１０００がそのプログラムを主記憶装置１００２に展開し、各実施形態における所定の処理を実行してもよい。

また、プログラムは、上記の実施形態における所定の処理の一部を実現するためのものであってもよい。さらに、プログラムは、補助記憶装置１００３に既に記憶されている他のプログラムとの組み合わせで上記の実施形態における所定の処理を実現する差分プログラムであってもよい。

インタフェース１００４は、他の装置との間で情報の送受信を行う。また、ディスプレイ装置１００５は、ユーザに情報を提示する。また、入力デバイス１００６は、ユーザからの情報の入力を受け付ける。

また、実施形態における処理内容によっては、コンピュータ１０００の一部の要素は省略可能である。例えば、ノードがユーザに情報を提示しないのであれば、ディスプレイ装置１００５は省略可能である。例えば、ノードがユーザから情報入力を受け付けないのであれば、入力デバイス１００６は省略可能である。

また、各装置の各構成要素の一部または全部は、汎用または専用の回路（Circuitry）、プロセッサ等やこれらの組み合わせによって実施される。これらは単一のチップによって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。また、各装置の各構成要素の一部又は全部は、上述した回路等とプログラムとの組み合わせによって実現されてもよい。

各装置の各構成要素の一部又は全部が複数の情報処理装置や回路等により実現される場合には、複数の情報処理装置や回路等は、集中配置されてもよいし、分散配置されてもよい。例えば、情報処理装置や回路等は、クライアントアンドサーバシステム、クラウドコンピューティングシステム等、各々が通信ネットワークを介して接続される形態として実現されてもよい。

次に、本発明の概要を説明する。図１５は、本発明の運用管理システムの概要を示すブロック図である。図１５に示す運用管理システムは、予め定められた１つまたは複数の監視対象５１もしくはそれら監視対象５１のうち特定の監視対象５１に代えて当該監視対象５１をモニタリングする特定のモニタ装置５２と管理用ネットワーク５３で接続される監視サーバ５０を備える。

また、監視サーバ５０は、稼動情報収集手段５０１と、特徴ベクトル生成手段５０２と、ナレッジ記憶手段５０３と、対処方法提示手段５０４とを含む。

稼動情報収集手段５０１（例えば、稼動情報収集部１０１）は、監視対象の少なくともいずれかにおける障害発生時に、監視対象の稼動状況を示す情報を収集する。

特徴ベクトル生成手段５０２（例えば、特徴処理部１０３）は、稼動情報収集手段５０１が収集した情報を基に、障害発生時の状況を示すベクトルであって、収集された情報数以上の次元数を有するベクトルである特徴ベクトルを生成する。

ナレッジ記憶手段５０３（例えば、ナレッジＤＢ１０５）は、監視対象の少なくともいずれかにおいて過去に発生した障害を対象に、当該障害を識別する情報と、当該障害が発生したときの特徴ベクトルと、当該障害を復旧させるために実施した対処方法を示す情報とを対応づけたて記憶する。

対処方法提示手段５０４（例えば、類似度処理部１０４およびＵＩ処理部１０６）は、監視対象の少なくともいずれかにおいて新たに障害が発生すると、ナレッジ記憶手段５０３に記憶された同種の過去の障害への対処方法の中から、当該新たな障害が発生したときの特徴ベクトルである第１特徴ベクトルとの類似度が高い特徴ベクトルと対応づけられた対処方法を優先して提示する。

なお、ナレッジ記憶手段５０３は、監視サーバ５０と独立に設けられていてもよい。その場合、監視サーバ５０は、ナレッジ記憶手段５０３へのアクセス手段（図示せず）を有していればよい。

以上、本実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

本発明は、あらゆるＩＣＴシステムの運用管理に適用可能であるとともに、本発明を利用すれば、障害発生と因果関係のある稼動状況といった障害原因の特定が困難な複合的なシステムにおいて、特に好適に適用される。

１ 監視サーバ
２ 監視対象マシン
３ 管理用ネットワーク
１０１ 稼動情報収集部
１０２ 障害検知部
１０３ 特徴処理部
１０４ 類似度処理部
１０５ ナレッジＤＢ
１０６ ＵＩ処理部
１０７ 操作処理部
１０８ ナレッジ更新部
１０９ 類似度計算学習処理部
１１０ 類似度計算手段格納部
１０００ コンピュータ
１００１ ＣＰＵ
１００２ 主記憶装置
１００３ 補助記憶装置
１００４ インタフェース
１００５ ディスプレイ装置
１００６ 入力デバイス
５０ 監視サーバ
５０１ 稼動情報収集手段
５０２ 特徴ベクトル生成手段
５０３ ナレッジ記憶手段
５０４ 対処方法提示手段
５１ 監視対象
５２ モニタ装置
５３ 管理用ネットワーク

Claims (10)

1. 予め定められた１つまたは複数の監視対象もしくは前記監視対象のうち特定の監視対象に代えて当該監視対象をモニタリングする特定のモニタ装置と管理用ネットワークで接続される監視サーバを備え、
   前記監視サーバは、
   前記監視対象の少なくともいずれかにおける障害発生時に、前記監視対象の稼動状況を示す情報を収集する稼働状況収集手段と、
   前記稼働状況収集手段が収集した前記情報を基に、障害発生時の状況を示すベクトルであって、収集された全ての監視対象の稼動状況を示す情報の数以上の次元数を有するベクトルである特徴ベクトルを生成する特徴ベクトル生成手段と、
   前記監視対象の少なくともいずれかにおいて過去に発生した障害を対象に、当該障害を識別する情報と、当該障害が発生したときの特徴ベクトルと、当該障害を復旧させるために実施した対処方法を示す情報とを対応づけて記憶するナレッジ記憶手段と、
   前記監視対象の少なくともいずれかにおいて新たに障害が発生すると、前記ナレッジ記憶手段に記憶された同種の過去の障害への対処方法の中から、当該新たな障害が発生したときの特徴ベクトルである第１特徴ベクトルとの類似度が高い特徴ベクトルと対応づけられた対処方法を優先して提示する対処方法提示手段とを含む
   ことを特徴とする運用管理システム。
2. 前記監視サーバは、
   特徴ベクトルの類似度を算出する類似度算出手段と、
   新たな障害を復旧させるために実施した対処方法である実施対処方法と、提示した中で最も類似度が高い特徴ベクトルと対応づけられた対処方法である第１優先対処方法とが異なる場合に、前記類似度算出手段における特徴ベクトルの類似度の算出方法を学習する類似度算出学習手段とを含む
   請求項１記載の運用管理システム。
3. 前記類似度算出学習手段は、実施対処方法が、提示した中に含まれかつ第１対処方法でない場合に、同種の過去の障害の中で、第１特徴ベクトルと前記実施対処方法に対応づけられた特徴ベクトルの類似度が最も高くなるように、前記類似度算出手段における特徴ベクトルの類似度の算出方法を学習する
   請求項２に記載の運用管理システム。
4. 前記監視サーバは、
   新たな障害が発生した時に、同種の過去の障害への対処方法が前記ナレッジ記憶手段に記憶されていない場合に、前記新たな障害についての、当該障害を識別する情報と、当該障害が発生したときの特徴ベクトルと、当該障害を復旧させるために実施した対処方法を示す情報とを対応づけて前記ナレッジ記憶手段に追記するナレッジ更新手段を含む
   請求項１から請求項３のうちのいずれかに記載の運用管理システム。
5. 前記監視サーバは、
   実施対処方法の情報を受け付ける対処情報受付手段を含む
   請求項２から請求項４のうちのいずれかに記載の運用管理システム。
6. 予め定められた１つまたは複数の監視対象もしくは前記監視対象のうち特定の監視対象に代えて当該監視対象をモニタリングする特定のモニタ装置と管理用ネットワークで接続され、
   前記監視対象の少なくともいずれかにおける障害発生時に、前記監視対象の稼動状況を示す情報を収集する稼働状況収集手段と、
   前記稼働状況収集手段が収集した前記情報を基に、障害発生時の状況を示すベクトルであって、収集された全ての監視対象の稼動状況を示す情報の数以上の次元数を有するベクトルである特徴ベクトルを生成する特徴ベクトル生成手段と、
   前記監視対象の少なくともいずれかにおいて過去に発生した障害を対象に、当該障害を識別する情報と、当該障害が発生したときの特徴ベクトルと、当該障害を復旧させるために実施した対処方法を示す情報とを対応づけて記憶するナレッジ記憶手段と、
   前記監視対象の少なくともいずれかにおいて新たに障害が発生すると、前記ナレッジ記憶手段に記憶された同種の過去の障害を対象に、当該新たな障害が発生したときの特徴ベクトルである第１特徴ベクトルとの類似度が高い特徴ベクトルと対応づけられた対処方法を優先して提示する対処方法提示手段とを備えた
   ことを特徴とする監視サーバ。
7. 予め定められた１つまたは複数の監視対象もしくは前記監視対象のうち特定の監視対象に代えて当該監視対象をモニタリングする特定のモニタ装置と管理用ネットワークで接続される監視サーバが、
   前記監視対象の少なくともいずれかにおける障害発生時に、前記監視対象の稼動状況を示す情報を収集し、
   収集した前記情報を基に、障害発生時の状況を示すベクトルであって、収集された全ての監視対象の稼動状況を示す情報の数以上の次元数を有するベクトルである特徴ベクトルを生成し、
   前記監視対象の少なくともいずれかにおいて過去に発生した障害について、当該障害を識別する情報と、当該障害が発生したときの特徴ベクトルと、当該障害を復旧させるために実施した対処方法を示す情報とを対応づけて記憶するナレッジ記憶手段を検索して、前記ナレッジ記憶手段に記憶された同種の過去の障害への対処方法の中から、新たな障害が発生したときの特徴ベクトルである第１特徴ベクトルとの類似度が高い特徴ベクトルと対応づけられた対処方法を優先して提示する
   ことを特徴とする運用管理方法。
8. 前記監視サーバが、前記新たな障害を復旧させるために実施した対処方法である実施対処方法と、提示した中で最も類似度が高い特徴ベクトルと対応づけられた対処方法である第１優先対処方法とが異なる場合に、特徴ベクトルの類似度の算出方法を学習する
   請求項７に記載の運用管理方法。
9. 前記監視サーバが、前記ナレッジ記憶手段に同種の過去の障害への対処方法が記憶されていない場合に、前記新たな障害についての、当該障害を識別する情報と、当該障害が発生したときの特徴ベクトルと、当該障害を復旧させるために実施した対処方法を示す情報とを対応づけて前記ナレッジ記憶手段に追記する
   請求項７または請求項８に記載の運用管理方法。
10. 予め定められた１つまたは複数の監視対象もしくは前記監視対象のうち特定の監視対象に代えて当該監視対象をモニタリングする特定のモニタ装置と管理用ネットワークで接続されるコンピュータに、
    前記監視対象の少なくともいずれかにおける障害発生時に、前記監視対象の稼動状況を示す情報を収集する処理、
    収集した前記情報を基に、障害発生時の状況を示すベクトルであって、収集された全ての監視対象の稼動状況を示す情報の数以上の次元数を有するベクトルである特徴ベクトルを生成する処理、および
    前記監視対象の少なくともいずれかにおいて過去に発生した障害について、当該障害を識別する情報と、当該障害が発生したときの特徴ベクトルと、当該障害を復旧させるために実施した対処方法を示す情報とを対応づけて記憶するナレッジ記憶手段を検索して、前記ナレッジ記憶手段に記憶された同種の過去の障害への対処方法の中から、新たな障害が発生したときの特徴ベクトルである第１特徴ベクトルとの類似度が高い特徴ベクトルと対応づけられた対処方法を優先して提示する処理
    を実行させるための運用管理プログラム。

Images