JP2012003406A - 障害原因判定ルール検証装置及びプログラム - Google Patents

Abstract

【課題】障害原因解析システムで使用する障害原因判定ルールの有効性をリアルタイムに検証可能とする。
【解決手段】障害原因判定ルールを見直すための時間間隔を与える時間窓を自動的に設定する。直近の時間窓内に発生したイベントに基づいて一時障害分類木を作成する。この後、作成された一時障害分類木と障害原因判定ルールの障害分類木（登録障害分類木）を比較し、比較結果に基づいて運用に使用する障害原因判定ルールを更新する。
【選択図】図７−２

Description

本発明は、過去のイベントログに基づいて、障害原因解析システムにて利用される障害原因解析ルールを検証する装置及び当該装置をソフトウェア的に実現するプログラムに関する。

システム障害発生時における復旧作業の遅延は、企業の業績や社会インフラに大きな影響を与える。システム障害の迅速な復旧には、早期の障害原因の特定と復旧手順の決定が重要となる。

そこで、障害の迅速な復旧を支援する障害原因解析システムが提案されている（特許文献１）。このシステムは、特定の障害時に発生するイベントと復旧手順とを対応付けた障害原因判定ルールを有し、当該ルールを用いて障害イベントを解析することにより適切な復旧手順を復旧担当者に提供する。

しかし、人手による障害原因判定ルールの作成には困難を伴う。そこで、イベントログから障害原因判定ルールを自動的に生成する手法が提案されている（特許文献２及び３）。特許文献２には、特定イベントの発生頻度を利用する方法が記載されている。特許文献３には、イベントの生起パターンを利用する方法が記載されている。

国際公開第２００４／０６１６８１号 特開２００８−４１０４１号公報 特開２００６−４３４６号公報

Fisher, Douglas H. "Knowledge acquisition via incremental clustering", Machine Learning 2, 139-172, 1987

ところが、一度作成して登録した障害原因判定ルールであっても、次のような理由により、登録内容の更新が必要となる。
（１）新規ＩＴサービスの追加／既存ＩＴサービスの廃止
新規のＩＴサービスの運用が開始されると、当該サービスに関係するシステム障害が新たに発生するようになる。この場合、新規なシステム障害に対応する障害原因判定ルールを作成し、既存の障害原因判定ルールに追加する必要がある。反対に、既存のＩＴサービスが廃止された場合、当該サービスに関係するシステム障害はそれ以降発生しなくなる。この場合、今後発生しなくなる障害に対応する障害原因判定ルールを、既存の障害原因判定ルールから削除する必要がある。
（２）ＩＴ基盤構成の変更
システムの運用過程では、提供されるＩＴサービス自体に変更が存在しなくとも、ＩＴ基盤が変更されることがある。例えばハードウェアの交換やネットワーク構成の変更などが生じることがある。このようにシステム構成に変更が生じると、同じ原因に起因するシステム障害であったとしても、発生するイベントの属性値やイベントの出現の仕方が影響を受けることになる。すなわち、障害原因判定ルールへの変更が必要となる。
（３）システム障害に対する認識の変化
当然ながら、障害原因判定ルールの作成時には、その時点で利用可能な情報に基づいて障害原因判定ルールが作成される。しかし、システム障害に関する情報量の不足から誤った障害原因判定ルールが生成される可能性がある。例えば同じ原因に起因すると判定されていたシステム障害Ａとシステム障害Ｂが、その後、異なる原因に起因するものであると判明することがある。反対に、当初は異なる原因に起因する障害として判定されていたものが、その後、同じ原因に起因する障害であると判明することがある。

しかるに従来手法は、障害原因判定ルールを自動生成するものであっても、その後のメンテナンスを考慮していない。すなわち、障害原因判定ルールの作成後もその有効性を常に検証し、必要に応じてルールを更新することは何ら考慮されていない。

そこで、発明者は、障害原因判定ルールを運用状況に応じて自動的に更新するための仕組みを提供する。具体的には、障害原因判定ルールを見直すための時間間隔を与える時間窓を自動的に設定する処理と、直近の時間窓内に発生したイベントに基づいて一時障害分類木を作成する処理と、作成された一時障害分類木と運用中の障害原因判定ルールに対応する障害分類木（登録障害分類木）を比較し、比較結果に基づいて運用に使用する障害原因判定ルールを更新する処理とを有する仕組みを提供する。

本発明によれば、運用に使用する障害原因判定ルールを運用状況の変化に応じて自動的に最適化できる。

障害原因解析システムのシステム構成例を示す図。 ログＤＢが保持するイベントテーブルの具体例を説明する図。 障害原因判定ルールＤＢが保持する障害分類木及び障害原因判定ルールテーブルを説明する図。 障害原因判定ルールＤＢが保持する障害ノードテーブルを説明する図。 障害原因判定ルール検証コンピュータのシステム構成例を示す図。 障害原因解析プロセスの概要を示すフローチャート。 イベントブロックの特徴テーブル例を示す図。 障害原因判定ルールにおけるスケジューリングプロセスの実行手順例を示すフローチャート。 障害原因判定ルールにおける検証・更新プロセスの実行手順例を示すフローチャート。 障害原因判定ルールの更新処理の概念を説明する図。 更新処理の具体例を説明する図。 障害原因判定ルールの追加処理の概念を説明する図。 障害原因判定ルールの削除処理の概念を説明する図。 障害原因判定ルールの統合処理の概念を説明する図。 統合処理の具体例を説明する図。 障害原因判定ルールの分割処理の概念を説明する図。 分割処理の具体例を説明する図。

以下、図面に基づいて、本発明の実施の形態を説明する。なお、後述する装置構成や処理動作の内容は発明を説明するための一例である。本発明は、後述する装置構成同士の組み合わせ、後述する装置構成と既知の技術の組み合わせ、後述する装置構成の一部と既知の技術との組み合わせも包含する。

（障害原因解析システムの全体構成）
図１に、障害原因判定ルール検証コンピュータ１０７を実装する障害原因解析システムの構成例を示す。図１に示す障害原因解析システムは、監視対象サーバ群１０１と、監視サーバ１０２と、ログデータベース（ＤＢ）１０３と、障害原因判定ルール生成コンピュータ１０４と、障害原因解析コンピュータ１０５と、障害原因判定ルールＤＢ１０６と、障害原因判定ルール検証コンピュータ１０７と、復旧手順書データベース（ＤＢ）１０８と、復旧手順書閲覧コンピュータ１０９とを有している。

このうち、監視サーバ１０２は、監視対象サーバ群１０１の状態（死活など）を監視し、状態に応じたイベントを生成する機能を提供する。監視サーバ１０２が生成したイベントはログデータベース（ＤＢ）１０３に格納される。障害原因判定ルール生成コンピュータ１０４は、ログＤＢ１０３からイベントログを読み出し、障害原因判定ルールを生成する機能を提供する。障害原因判定ルール生成コンピュータ１０４が生成した障害原因判定ルールは、障害原因判定ルールＤＢ１０６に格納される。障害原因解析コンピュータ１０５は、障害原因判定ルールＤＢ１０６が格納する障害原因判定ルールに基づいてイベントを解析し、障害に対する復旧手順書を特定する機能を提供する。障害原因判定ルール検証コンピュータ１０７は、監視サーバ１０２が生成したイベントを解析し、障害原因判定ルールＤＢ１０６が格納する障害原因判定ルールの有効性を検証する。復旧手順書データベース（ＤＢ）１０８は、障害時の復旧手順に関する文書を格納する。ここでの文書には、障害発生時のトラブルシューティングを記述したマニュアル（ハードウェアかソフトウェアかを問わない）だけでなく、過去の障害に対する保守担当者の対応記録、報告書その他の障害から復旧するための手順に関する文書も含まれる。復旧手順書閲覧コンピュータ１０９は、障害原因解析コンピュータ１０５によって特定された復旧手順書を画面上に表示する機能を提供する。

（イベントテーブルの具体例）
図２に、ログＤＢ１０３に格納されるイベントテーブル２００の具体例を示す。イベントテーブル２００は、イベントを一意に特定する識別子(ID)２０１、イベントが発生した日時を特定する発生日時２０２、個々のイベントの属性値の集合であるイベント２０３から構成される。この形態例の場合、イベント２０３の属性は、<種類>、<ソース>、<イベント番号>、<ユーザ>、<コンピュータ>で定義される。このうち、<種類>はイベントの重要度を示している。<ソース>はイベントを発生させたプロセスやアプリケーション等の発生源を示している。<イベント番号>はイベントの内容を特定する番号を示している。<ユーザ>はイベントの発生源となったプロセスやアプリケーションを実行していたユーザを示している。<コンピュータ>はイベントの発生源となった監視対象サーバ群１０１内のサーバを示している。

（障害原因判定ルールＤＢの具体例）
図３−１及び図３−２に、障害原因判定ルールＤＢ１０６の構成例を示す。障害原因判定ルールＤＢ１０６は、障害原因解析コンピュータ１０５に登録されている障害原因判定ルールとそれに関連する情報を格納しているＤＢである。障害原因判定ルールＤＢ１０６は、登録障害分類木３００と、障害原因判定ルールテーブル３１０と、障害ノードテーブル３２０とから構成される。

登録障害分類木３００は、障害原因解析コンピュータ１０５に登録されている障害原因判定ルールの生成時に作成される。登録障害分類木３００では、障害時に発生した単数又は複数のイベントの集合（以下、「イベントブロック」という。）が共通に有する特徴に基づいて障害が分類され、分類木として表現される。登録障害分類木３００のノードを障害ノードと呼ぶ。同じ障害ノードに分類された障害同士は、発生したイベント及び発生の仕方が類似しているので、同じ障害原因による障害であると考えられる。

障害原因判定ルールテーブル３１０は、障害原因解析コンピュータ１０５に登録されている障害原因判定ルールを格納するデータテーブルである。障害原因判定ルールテーブル３１０は、登録障害分類木３００の障害ノード３１１と、対象障害ノードに分類される障害に適用される障害原因判定ルール３１２から構成される。障害原因判定ルール３１２は、単数又は複数の判定イベント３１３と、判定時間３１４と、復旧手順書３１５とで構成される。判定イベント３１３は、対象障害ノードを特徴付けるイベントの属性の集合である。判定時間３１４は、判定イベント３１３を満たすイベントが発生する時間間隔である。復旧手順書３１５は、判定時間３１４内に判定イベント３１３を満たすイベントが発生した場合に復旧手順書閲覧コンピュータ１０９に表示される文書である。

１つの障害ノード３１１に複数の判定イベント３１３が指定されている場合は、障害原因判定ルールテーブル３１０に記述されている順番に判定イベント３１３が出現するものとする。図３−１の（２）の場合、「障害ノード１−１」に対する障害原因判定ルール３１２として、（「警戒」、「process71」、「80」、「user2」、「server9」）の属性値を有するイベントの発生後に、（「*」、「process39」、「*」、「user4」、「server8」）の属性値を有するイベントが判定時間「２分９秒」以内に発生したら、「復旧手順A.doc」を復旧手順閲覧コンピュータ１０９に表示するというルールが設定されている。ここで、属性値「*」は、値が不定であることを意味し、任意の値を取り得ることを示す。

障害ノードテーブル３２０は、登録障害分類木３００を構築する際に訓練データとして使用したイベントブロックを格納する。障害ノードテーブル３２０は、障害ノード３１１と、当該障害ノードに分類されたイベントブロック３２１と、当該イベントブロック３２１内に含まれるイベント２０３とから構成される。

（障害原因判定ルール検証コンピュータの構成例）
図４に、障害原因判定ルール検証コンピュータ１０７の構成例を示す。障害原因判定ルール検証コンピュータ１０７は、コンピュータ本体４００と、入力装置４３０と、表示装置４３１と、通信装置４３２とから構成される。なお、通信装置４３２は、監視サーバ１０２、ログＤＢ１０３及び障害原因判定ルールＤＢ１０６と通信する。

コンピュータ本体４００は、データ演算をするＣＰＵ４０１、ＲＯＭ４０２、ＲＡＭ４１０、ハードディスク駆動装置４２０、これらデバイス間のデータ転送を実現するＣＰＵバス４０７、これらデバイスとＣＰＵバス４０７とを結合するインターフェース４０３〜４０６で構成される。

ＲＡＭ４１０には、ＣＰＵ４０１に演算処理をさせる障害原因判定ルール検証プログラム４１１の実行領域と、検算時に一時的に生成させるデータを格納する作業領域４１２とが少なくとも確保される。また、ハードディスク駆動装置４２０の記憶領域には、障害原因判定ルール検証プログラムの格納領域としてのプログラム格納部４２１と、監視サーバ１０２及び障害原因判定ルールＤＢ１０６から取得したデータを一時的に格納しておくデータ格納部４２２が少なくとも確保される。

(障害原因解析動作)
図５に、障害原因解析システム全体の障害原因解析プロセスの概略を示す。
（ステップ５０１）
障害原因判定ルール生成コンピュータ１０４は、ログＤＢ１０３からイベントログを取得して障害原因判定ルールを生成し、障害原因判定ルールＤＢ１０６に保存する。ここで、障害原因判定ルールの作成は、（１）障害分類木の作成、（２）頻出イベントパターンの発見、（３）復旧手順書検索の順番に行う。

（１）障害分類木の作成
障害原因判定ルール生成コンピュータ１０４は、ログＤＢ１０３から取得したイベントを障害別に分類する。障害別に分類された状態のイベントをイベントブロックという。次に、障害原因判定ルール生成コンピュータ１０４は、各イベントブロックから特徴を抽出し、抽出された特徴に基づいて教師なしのクラスタリングを行い、分類木を構築する。この分類木が、障害原因判定ルールＤＢ１０６の登録障害分類木３００に相当する。この場合のクラスタリング手法としては、非特許文献１に記載されている概念クラスタリングＣＯＢＷＥＢなどがある。

（２）頻出イベントパターンの発見
障害原因判定ルール生成コンピュータ１０４は、指定された分類木の障害ノードに分類される複数のイベントブロックに単数又は複数の頻出するイベントを発見する。さらに、頻出イベントが複数ある場合には、頻出イベントが出現する順番と時間間隔を求める。これらが、障害原因判定ルールＤＢ１０６の障害原因判定ルールテーブル３１０の障害原因判定ルール３１２における判定イベント３１３及び判定時間３１４に相当する。

図６に、各イベントブロックの特徴を抽出することで作成したイベントブロックの特徴テーブル６００の構成例を示す。特徴テーブル６００は、イベントブロックを特定するイベントブロックＩＤ６０１、各イベントブロックに対する特徴である属性リスト６０２で構成される。属性リスト６０２は、イベント２０３を構成する属性毎にイベントブロック内で最も頻出する属性値と次に頻出する属性値で構成される。このため、「種類」、「ソース」、「イベント」、「ユーザ」、「コンピュータ」の各属性にそれぞれ２つの属性値が割り当てられている。

（３）復旧手順書の検索
障害原因判定ルール生成コンピュータ１０４は、（２）で求めた頻出イベントの属性値に基づいて検索キーを生成する。例えば５つの属性、すなわち「種類」、「ソース」、「イベント」、「ユーザ」、「コンピュータ」のそれぞれについて最も頻出する属性値の組み合わせを検索キーに設定する。次に、障害原因判定ルール生成コンピュータ１０４は、生成された検索キーを用いて復旧手順書ＤＢ１０８を検索し、適切な復旧手順書を取得する。ここでの復旧手順書が、障害原因判定ルールテーブル３１０（図３−１）の障害原因判定ルール３１２における復旧手順書３１５に相当する。

（ステップ５０２）
障害原因解析コンピュータ１０５は、障害原因判定ルール生成コンピュータ１０４により障害原因判定ルールＤＢ１０６が更新されたのを検知すると、障害原因判定ルールＤＢ１０６から障害原因判定ルールテーブル３１０の障害原因判定ルール３１２（図３−１）を取得し、登録する。

（ステップ５０３）
監視サーバ１０２は、監視対象サーバ群１０１を監視している。監視サーバ１０２は、監視対象サーバ群１０１内のサーバに障害に起因する異常を発見すると、該当するサーバの状態に応じたイベントを生成する。監視サーバ１０２は、生成したイベントをログＤＢ１０３に保存すると共に、障害原因解析コンピュータ１０５及び障害原因判定ルール検証コンピュータ１０７にそのイベントを送信する。

（ステップ５０４）
障害原因解析コンピュータ１０５は、受信したイベントと、障害原因判定ルール３１２とのマッチング処理を実行する。障害原因判定ルール３１２に登録されたいずれかの障害ノードと受信したイベントが一致した場合、障害原因解析コンピュータ１０５は、一致が確認された傷害ノードについて登録されている復旧手順書３１５を復旧手順書ＤＢ１０８から取得し、復旧手順書閲覧コンピュータ１０９に送信する。

（ステップ５０５）
復旧手順書閲覧コンピュータ１０９は、障害原因解析コンピュータ１０５から受信した復旧手順書３１５を表示装置上に表示する。

（ステップ５０６）
障害原因判定ルール検証コンピュータ１０７は、監視サーバ１０２からイベントを受信すると、設定された時間窓内のイベント集合から障害原因判定ルールを作成し、障害原因判定ルールＤＢ１０６を更新する。この処理内容の詳細は後述する。

（ステップ５０７）
障害原因解析コンピュータ１０５は、障害原因判定ルール検証コンピュータ１０７により障害原因判定ルールＤＢ１０６が更新されたことを検知した場合、障害原因判定ルールＤＢ１０７から障害原因判定ルール３１２を取得し、現在利用している障害原因判定ルールと置き換える。

（障害原因判定ルール検証動作）
図７−１及び図７−２に、障害原因判定ルール検証プログラム４１１を通じて実行される障害原因判定ルールの検証・更新プロセスの概要を示す。まず、図７−１に、検証プロセスのスケジューリング処理の内容を示す。

（スケジューリングの詳細動作）
（ステップ７００）
障害原因判定ルール検証プログラム４１１の実行は、障害原因判定ルール生成コンピュータ１０４が、障害原因判定ルールＤＢ１０６の更新を通信装置４３２経由で検知することにより開始される。

（ステップ７０１）
障害原因判定ルール検証コンピュータ１０７は、障害の発生時間間隔の境界時間ｔｂを計算する。境界時間ｔｂとは、最後に障害が発生してから、時間間隔の境界時間ｔｂ以内に、同じ障害原因による障害が発生しなければ、以降も発生しないと考えられる時間間隔である。障害の発生時刻は、対応するイベントブロックの最初のイベントの発生日時とする。この境界時間tbは、次の（１）から（３）の手順で決める。

（１）登録障害分類木の取得
障害原因判定ルール検証コンピュータ１０７は、通信装置４３２を介して障害原因判定ルールＤＢ１０６から登録障害分類木３００、障害原因判定ルールテーブル３１０、障害ノードテーブル３２０を取得する。これらの情報に基づいて、障害原因判定ルール検証コンピュータ１０７は、登録障害分類木３００を構築する際に訓練データとして使用した最初のイベントの発生日時ｔ０と最後のイベントの発生日時との時間差を算出する。この時間差を、障害原因判定ルール検証コンピュータ１０７は、障害分類木を作成する際におけるイベントの時間範囲を与える分類木構築時間Δとする。

（２）検証障害ノードの障害発生時間間隔
障害原因判定ルール検証コンピュータ１０７は、障害原因判定ルールテーブル３１０のうち障害原因判定ルール３１２が設定されている障害ノード３１１を検証対象に設定する。この検証対象としての障害ノードを、以下、「検証障害ノード」という。この後、障害原因判定ルール検証コンピュータ１０７は障害ノードテーブル３２０にアクセスし、検証障害ノードに対応するイベントブロック３２１に関する障害の発生時間間隔を計算する。

（３）境界時間ｔｂの計算
障害原因判定ルール検証コンピュータ１０７は、（２）で求めた発生時間間隔の分布から、仮説「ある障害ノードに分類される障害が発生してからｔｂ後に発生した障害がその障害ノードに分類される」が有意水準１％の確率で棄却されるような境界値である境界時間ｔｂを、仮説検定を用いて求める。

（ステップ７０２）
障害原因判定ルール検証コンピュータ１０７は、通信装置４３２を介してログＤＢ１０３から、日時（ｔ０＋ｔｂ）から日時（ｔ０＋Δ）までのイベントを取得する。

（ステップ７０３）
障害原因判定ルール検証コンピュータ１０７は、ステップ７０２で取得したイベントを訓練データとして一時障害分類木を作成する。ここで、一時障害分類木は、障害原因判定ルール検証コンピュータ１０７で一時的に作成される障害分類木であり、登録障害分類木３００と同様の方法で作成される。この一時障害分類木の場合も、障害原因判定ルールＤＢ１０６と同様に、障害原因判定ルールテーブル、障害ノードテーブルが同時に作成される。作成された一時障害分類木、対応する障害原因判定ルールテーブル、障害ノードテーブルは、作業領域４１０に格納される。

（ステップ７０４）
障害原因判定ルール検証コンピュータ１０７は、検証開始日時ｔｖｓを計算する。検証開始日時ｔｖｓは、ｔ０＋Δ＋ｔｂとする。

（ステップ７０５）
障害原因判定ルール検証コンピュータ１０７は、監視対象サーバ群１０１内に障害を検知した監視サーバ１０２が送信したイベントを、通信装置４３２を介して受信する。

（ステップ７０６）
障害原因判定ルール検証コンピュータ１０７は、受信したイベントの発生日時ｔｅと検証開始日時ｔｖｓとを比較する。イベントの発生日時ｔｅが検証開始日時ｔｖｓ以下の場合、障害原因判定ルール検証コンピュータ１０７は、ステップ７１０を実行する。イベント発生日時ｔｅが検証開始日時ｔｖｓより大きい場合、障害原因判定ルール検証コンピュータ１０７は、ステップ７０７を実行する。

（ステップ７０７）
障害原因判定ルール検証コンピュータ１０７は、障害原因判定ルールＤＢ１０６の障害原因判定ルールテーブル３１０内の検証対象である障害ノードに設定されている障害原因判定ルール３１２の有効性を検証し、必要があれば障害原因判定ルールＤＢ１０６の内容を更新する。この処理内容の詳細は後述する。

（ステップ７０８）
障害原因判定ルール検証コンピュータ１０７は、新しい検証開始日時ｔｖｓを設定する。新しい検証開始日時ｔｖｓは、次のように求める。まず、ステップ７０９で作成した一時障害分類木の検証障害ノードに対し、障害原因判定ルール検証コンピュータ１０７は、ステップ７０１の（２）及び（３）と同じ方法により、障害の発生時間間隔の境界時間ｔｂ’を計算する。次に、障害原因判定ルール検証コンピュータ１０７は、ｔｖｓ＋ｔｂ’を計算し、これを新しい検証開始日時ｔｖｓとする。

（ステップ７０９）
障害原因判定ルール検証コンピュータ１０７は、作業領域４１２に格納されている現在の一時障害分類木の障害ノードテーブルから時間範囲（ｔｖｓ−Δ〜ｔｅ）に発生したイベントを取得する。次に、障害原因判定ルール検証コンピュータ１０７は、取得したイベントを訓練データとして新規の一時障害分類木、障害原因判定ルールテーブル及び障害ノードテーブルを作成し、作業領域４１２に格納する。その後、障害原因判定ルール検証コンピュータ１０７は、現在の一時障害分類木及び対応する障害原因判定ルールテーブル、障害ノードテーブルは削除する。

（ステップ７１０）
障害原因判定ルール検証コンピュータ１０７は、受信したイベントからイベントブロックを作成し又は更新し、一時障害分類木を更新する。同時に、障害原因判定ルール検証コンピュータ１０７は、この一時障害分類木に対応する障害原因判定ルールテーブル及び障害ノードテーブルも更新する。

（検証プロセスの詳細動作）
次に、図７−２に示す検証・更新プロセスの詳細動作を説明する。
（ステップ７５０）
障害原因判定ルール検証コンピュータ１０７は、一時障害分類木と障害原因判定ルールＤＢ１０６の登録障害分類木３００とを比較する。すなわち、一時的に生成した分類木と運用中の分類木を比較する。両分類木の構成が一致している場合、障害原因判定ルール検証コンピュータ１０７はステップ７６０を実行する。一方、不一致の場合、障害原因判定ルール検証コンピュータ１０７はステップ７７０を実行する。登録障害分類木と一時障害分類木との対応づけは、次のように行う。登録障害分類木作成時に訓練データとして使用した障害のイベントブロックを、登録分類木と一時障害分類木の両方で分類する。同じイベントブロックが分類された登録分類木の障害ノードと一時障害分類木の障害ノードとを対応する障害ノードとする。これにより、登録障害分類木の障害ノードが、一時障害分類木のどの障害ノードに対応しているかを判断できる。

（ステップ７６０）
障害原因判定ルール検証コンピュータ１０７は、一時障害分類木の検証障害ノードに、登録障害分類木の対応する障害ノードにない新しい障害が分類されているか否か判定する。一時障害分類木のみに存在する障害が存在しない場合、障害原因判定ルール検証コンピュータ１０７はステップ７６１を実行する。一方、一時障害分類木にのみ存在する障害が存在する場合、障害原因判定ルール検証コンピュータ１０７はステップ７６２を実行する。

（ステップ７６１）
障害原因判定ルール検証コンピュータ１０７は、障害原因判定ルールＤＢ１０６を更新する。すなわち、障害原因判定ルール検証コンピュータ１０７は、障害原因判定ルールテーブル３１０から検証障害ノードに対応する障害原因判定ルールを削除する。なお、ここでの一時障害分類木は、登録障害分類木が作成されてから時間間隔の境界時間ｔｂ以降に作成されたものである。従って、同じ障害ノードに分類される障害が発生しなければ、今後この障害ノードに分類される障害は発生しないと判断できる。このため、検証障害ノードに設定された障害原因判定ルールを削除しても問題ない。

（ステップ７６２）
障害原因判定ルール検証コンピュータ１０７は、一時障害分類木の検証障害ノードに対する障害原因判定ルールをステップ５０１の（２）及び（３）で記述した方法で生成する。障害原因判定ルール検証コンピュータ１０７は、生成した一時障害分類木の検証障害ノードの障害原因判定ルールと、障害原因判定ルールテーブル３１０の障害原因判定ルールを比較し、一致していない場合はステップ７６３を実行する。

（ステップ７６３）
障害原因判定ルール検証コンピュータ１０７は、障害原因判定ルールＤＢ１０６を更新する。すなわち、障害原因判定ルール検証コンピュータ１０７は、検証障害ノードに設定された障害原因判定ルールを、ステップ７６２で作成された障害原因判定ルールに置き換える。

図８−１及び図８−２は、障害原因判定ルールの更新処理を説明した図である。図８−１の（１）は２００９年１月から３月に発生したイベントから作成した登録障害分類木８００であり、検証対象である「障害ノード１−１」８０１に対して、図８−２の（Ａ−１）の障害原因判定ルール８２０が設定されている。図８−１の（２）は２００９年１０月から１２月に発生したイベントから作成した一時分類木８１０であり、この「障害ノード１−１’」８１１に対して、図８−２の（Ｂ−１）の障害原因判定ルール８３０が生成された。このとき、登録分類木８００と一時分類８１０の構成は一致している。さらに「障害ノード１−１」に分類される２００９年１月から３月に発生したイベントから作成したイベントブロックは全て一時障害分類木８１０に分類され、「障害ノード１−１」８１１’と「障害ノード１−１’」８１１とが対応しているとする。

このとき、「障害ノード１−１」８０１の障害原因判定ルール８２０と、「障害ノード１−１’」８１１の障害原因判定ルール８３０とを比較すると、２番目の判定イベントの属性「コンピュータ」の属性値が、「障害ノード１−１」では「server8」８２１であるのに対し、「障害ノード１−１’」では「server25」であり異なっている。以上の場合、障害原因判定ルールテーブル３１０に登録されている「障害ノード１−１」８０１の障害原因判定ルール８２０を、「障害ノード１−１’」８１１の障害原因判定ルール８３０で置換する。関連して障害ノードテーブル３２０も更新される。

（ステップ７７０）
障害原因判定ルール検証コンピュータ１０７は、一時障害分類木と登録障害分類木との差分を求める。一時障害分類木に登録障害分類木３００にない障害ノードが存在する場合、障害原因判定ルール検証コンピュータ１０７は、ステップ７７１を実行する。登録障害分類木３００に存在していた障害ノードが一時障害分類木には存在しない場合、障害原因判定ルール検証コンピュータ１０７は、ステップ７７２を実行する。登録障害分類木３００に存在していた複数の障害ノードが一時障害分類木では一つの障害ノードにまとめられている場合、障害原因判定ルール検証コンピュータ１０７は、ステップ７７３を実行する。登録障害分類木３００では一つの障害ノードが一時障害分類木では複数の障害ノードに分割された場合、障害原因判定ルール検証コンピュータ１０７は、ステップ７７４を実行する。

（ステップ７７１）
障害原因判定ルール検証コンピュータ１０７は、障害原因判定ルールＤＢ１０６を更新する。すなわち、障害原因判定ルール検証コンピュータ１０７は、一時障害分類木に追加された新規の障害ノードに対してステップ５０１の（２）及び（３）の手順で障害原因判定ルールを作成し、作成された障害原因判定ルールを障害原因判定ルールテーブル３１０に追加する。

図９は、障害原因判定ルールの追加処理を説明した図である。図９の（１）は２００９年１月から３月に発生したイベントから作成した登録障害分類木９００であり、図９の（２）は２００９年１０月から１２月に発生したイベントから作成した一時障害分類木９１０である。登録障害分類木９００と一時障害分類木９１０とを比較すると、登録障害分類木９００には存在しないが、一時障害分類木９１０には「障害ノード３’」９１１が存在することが分かる。

このとき、障害原因判定ルール検証コンピュータ１０７は、「障害ノード３’」９１１に対して障害原因判定ルールを作成し、障害原因判定ルールテーブル３１０に登録する。この登録に関連して、障害原因判定ルール検証コンピュータ１０７は、登録障害分類木３００と障害ノードテーブル３２０も更新する。

（ステップ７７２）
障害原因判定ルール検証コンピュータ１０７は、障害原因判定ルールＤＢ１０６を更新する。すなわち、障害原因判定ルール検証コンピュータ１０７は、一時障害分類木には存在しないが、登録障害分類木３００の検証障害ノード３１１には設定されている障害原因判定ルールテーブル３１０の障害原因判定ルール３１２を削除する。

図１０は、障害原因判定ルールの削除処理を説明した図である。図１０の（１）は２００９年１月から３月に発生したイベントから作成した登録障害分類木１０００であり、図１０の（２）は２００９年１０月から１２月に発生したイベントから作成した一時障害分類木１０１０である。登録障害分類木１０００と一時障害分類木１０１０とを比較すると、登録障害分類木１０００に存在した障害ノード１００１は、一時障害分類木１０１０では無くなっていることが分かる。

このとき、障害原因判定ルール検証コンピュータ１０７は、「障害ノード２」１００１に設定されていた障害原因判定ルールを、障害原因判定ルールテーブル３１０から削除する。この削除に関連し、障害原因判定ルール検証コンピュータ１０７は、登録障害分類木３００及び障害ノードテーブル３２０も更新する。

（ステップ７７３）
障害原因判定ルール検証コンピュータ１０７は、障害原因判定ルールＤＢ１０６を更新する。すなわち、障害原因判定ルール検証コンピュータ１０７は、統合される登録障害分類木３００の複数の障害ノードに設定されていた障害原因判定ルール３１２を、障害原因判定ルールテーブル３１０から削除する。さらに、障害原因判定ルール検証コンピュータ１０７は、一時障害分類木の統合された障害ノードに対してステップ５０１の（２）及び（３）の手順で障害原因判定ルールを作成し、障害原因判定ルールテーブル３１０に追加する。ただし、作成した一時障害分類木の障害ノードの障害原因判定ルールの復旧手順書は、実績のある登録障害分類木３００の障害ノード３１１に設定されていた障害原因判定ルール３１２の復旧手順３１５を活用する。

図１１−１及び図１１−２は、障害原因判定ルールの統合処理を説明した図である。図１１−１の（１）は２００９年１月から３月に発生したイベントから作成した登録障害分類木１１００であり、図１１−１の（２）は２００９年１０月から１２月に発生したイベントから作成した一時障害分類木１１１０である。２００９年１月から３月に発生したイベントから作成したイベントブロックは、「障害ノード１−１」１１０１に１０個、「障害ノード１−２」１１０２に５個分類されている。これら１５個のイベントブロックを一時障害分類木１１０１で分類すると、１５個全てのイベントブロックが「障害ノード１’」１１０１に分類されている。すなわち、「障害ノード１−１」と「障害ノード１−２」が統合されて「障害ノード１’」になっている。「障害ノード１−１」１１０１及び「障害ノード１−２」１１０２に設定されている障害原因判定ルールは、それぞれ図１１−２の（Ａ−１）の１１２０及び図１１−２の（Ａ−２）の１０２１に対応する。

また、障害原因判定ルール検証コンピュータ１０７は、２００９年１０月から１２月に発生したイベントから「障害ノード１’」１１１１の障害原因判定ルール１１３０を作成する。ただし、障害原因判定ルール１０３０の復旧手順書１０３１には、より多くのイベントブロックが分類され、かつ、実績のあった「障害ノード１−１」に対応する障害原因判定ルール１０２０の復旧手順書１０２１を採用する。

このとき、障害原因判定ルールテーブル３１０からは「障害ノード１−１」１１０１及び「障害ノード１−２」１１０２に対応する障害原因判定ルール１１２０及び１１３０を削除し、新たに作成された「障害ノード１’」の障害原因判定ルール１０３０を追加する。関連して登録障害分類木３００及びイベントブロックテーブル３２０も更新する。

（ステップ７７４）
障害原因判定ルール検証コンピュータ１０７は、障害原因判定ルールＤＢ１０６を更新する。すなわち、障害原因判定ルール検証コンピュータ１０７は、分割される登録障害分類木３００の障害ノードに設定されていた障害原因判定ルール３１２を、障害原因判定ルールテーブル３１０から削除する。さらに、障害原因判定ルール検証コンピュータ１０７は、一時障害原因分類木の分割された複数の障害ノードに対してステップ５０１の（２）及び（３）の手順で障害原因判定ルールを作成し、障害原因判定ルールテーブル３１０に追加する。ただし、作成した一時障害分類木の障害ノードの障害原因判定ルールの復旧手順書は、実績のある登録分類木３００の障害ノード３１１について設定されていた障害原因判定ルール３１２の復旧手順書３１５を活用する。

図１２−１及び図１２−２は、障害原因判定ルールの分割処理を説明した図である。図１２−１の（１）は２００９年１月から３月に発生したイベントから作成した登録障害分類木１２００であり、図１２−１の（２）は２００９年１０月から１２月に発生したイベントから作成した一時障害分類木１２１０である。２００９年１月から３月に発生したイベントから作成したイベントブロックのうち１０個が「障害ノード１−１」１２０１に分類されている。一時障害分類木１２１０では、これら１０個のイベントブロックのうちの６個が「障害ノード１−１−１’」１２１１に、４個が「障害ノード１−１−２’」１２１２に分類される。「障害ノード１−１」１２０１に設定されている障害原因判定ルールは、図１２−２の（Ａ−１）の１２２０であり、２００９年１０月から１２月に発生したイベントから生成した「障害ノード１−１−１’」１２１１及び「障害ノード１−１−２’」１２１２の障害原因判定ルールは、それぞれ図１２−２の（Ｂ−１）の１２２１及び図１２−２の（Ｂ−２）の１２３１である。ただし、「障害ノード１−１」１２０１に分類されたイベントブロックがより多く分類された「障害ノード１−１−１’」１２１１の障害原因判定ルール１２２１の属性「復旧手順書」に「障害ノード１−１」１２０１の障害原因判定ルール１１２０の属性「復旧手順書」で指定された実績のある障害復旧手順書を割り当てる。

このとき、障害原因判定ルール検証コンピュータ１０７は、障害原因判定ルールテーブル３１０から「障害ノード１−１」１２０１に対応する障害原因判定ルール１２２０を削除し、「障害ノード１−１−１’」１２１１及び「障害ノード１−１−２’」１２１２に対応する障害原因判定ルール１２２１と１２３１を追加する。関連して登録障害分類木３００及びイベントブロックテーブル３２０も更新する。

１０１…監視対象サーバ群
１０２…監視サーバ
１０３…ログデータベース（ＤＢ）
１０４…障害原因判定ルール生成コンピュータ
１０５…障害原因解析コンピュータ
１０６…障害原因判定ルールＤＢ
１０７…障害原因判定ルール検証コンピュータ
１０８…復旧手順書データベース（ＤＢ）
１０９…復旧手順書閲覧コンピュータ

Claims (10)

1. システム障害の発生時、監視対象であるサーバ群の状態に基づいて監視サーバが生成したイベントを取得する第一の処理部と、
   予め設定しておいた時間窓内に発生したイベントを障害別に分類し、一時障害分類木を生成する第二の処理部と、
   運用中の障害原因判定ルールに対応する登録障害分類木と一時障害分類木とを比較する第三の処理部と、
   前記登録障害分類木と前記一時障害分類木の間の差分及び前記一時障害分類木の障害ノードから生成される障害判定ルールと運用中の前記障害判定ルールの間の差分に基づいて、運用中の前記障害原因判定ルールを更新する第四の処理部と
   を有する障害原因判定ルール検証装置。
2. 前記第二の処理部は、
   一時障害分類木を作成する時間窓を、
   登録障害分類木内の検証対象の障害ノードに分類されている障害の出現間隔時間の統計量に基づき、当該時間内に同じ障害ノードに分類される障害が発生しないならば、今後同様の障害が発生しないと判断できる時間間隔の境界時間として計算する
   ことを特徴とする請求項１記載の障害原因判定ルール検証装置。
3. 前記第三の処理部は、
   登録障害分類木の訓練データとして使用したイベントブロックを、登録障害分類木と一時障害分類木のそれぞれについて分類した場合における同一イベントブロックの各分類先に該当する登録障害分類木の障害ノードと一時障害分類木の障害ノードとの比較により、登録分類木と一時障害分類木との間の前記比較を実行する
   ことを特徴とする請求項１に記載の障害原因判定ルール検証装置。
4. 前記第四の処理部は、
   運用中の障害原因判定ルールを設定するのに用いた登録分類木の障害ノードに対応する一時障害分類木の障害ノードに対して障害原因判定ルールを作成した場合にあって、両ルール間に違いが検出されたとき、
   運用中の前記障害原因判定ルールを、一時障害分類木の障害ノードに対して作成した障害原因判定ルールによって置換する
   ことを特徴とする請求項１に記載の障害原因判定ルール検証装置。
5. 前記第四の処理部は、
   運用中の障害原因判定ルールに対応する登録障害分類木に存在しない障害ノードが一時障害分類木には存在する場合、
   当該一時障害分類木にのみ存在する障害ノードに対する障害原因判定ルールを作成し、運用中の障害原因判定ルールに追加登録する
   ことを特徴とする請求項１に記載の障害原因判定ルール検証装置。
6. 前記第四の処理部は、
   登録障害分類木内の検証対象の障害ノードに分類されている障害の出現間隔時間の統計量に基づき、当該時間内に同じ障害ノードに分類される障害が発生しないならば、今後同様の障害が発生しないと判断できる時間間隔の境界時間を経過しても、検証対象の障害ノードに分類される障害が発生しない場合、
   当該障害ノードに対して設定されている障害原因判定ルールを、運用中の障害原因判定ルールから削除する
   ことを特徴とする請求項１に記載の障害原因判定ルール検証装置。
7. 前記第四の処理部は、
   運用中の障害原因判定ルールに対応する登録障害分類木に存在した障害ノードが一時障害分類木には存在しない場合、
   当該登録障害分類木にのみ存在する障害ノードに対して設定されている障害原因判定ルールを、運用中の障害原因判定ルールから削除する
   ことを特徴とする請求項１に記載の障害原因判定ルール検証装置。
8. 前記第四の処理部は、
   運用中の障害原因判定ルールに対応する登録障害分類木では複数の障害ノードに分類されていたものが、一時障害分類木では１つの障害ノードに分類されている場合、
   登録障害分類木の複数の障害ノードに設定されていた障害原因判定ルールを運用中の障害原因判定ルールから削除すると共に、一時障害分類木の障害ノードに対して作成した障害原因判定ルールを運用中の障害原因判定ルールに追加登録する
   ことを特徴とする請求項１に記載の障害原因判定ルール検証装置。
9. 前記第四の処理部は、
   運用中の障害原因判定ルールに対応する登録障害分類木では一つの障害ノードに分類されていたものが、一時障害分類木では複数の障害ノードに分割されていた場合、
   登録障害分類木の障害ノードに設定されていた障害原因判定ルールを運用中の障害原因判定ルールから削除すると共に、一時障害分類木で対応する複数の障害ノードのそれぞれについて作成さした各障害原因判定ルールを障害原因判定ルールに追加登録する
   ことを特徴とする請求項１に記載の障害原因判定ルール検証装置。
10. 障害原因判定ルール検証装置として機能するコンピュータに、
    システム障害の発生時、監視対象であるサーバ群の状態に基づいて監視サーバが生成したイベントを取得する第一の処理と、
    予め設定しておいた時間窓内に発生したイベントを障害別に分類し、一時障害分類木を生成する第二の処理と、
    運用中の障害原因判定ルールに対応する登録障害分類木と一時障害分類木とを比較する第三の処理と、
    前記登録障害分類木と前記一時障害分類木の間の差分及び前記一時障害分類木の障害ノードから生成される障害判定ルールと運用中の前記障害判定ルールの間の差分に基づいて、運用中の前記障害原因判定ルールを更新する第四の処理と
    を実行させるコンピュータプログラム。

Images