(57)【要約】【課題】共通の原因による障害情報の判定条件を自動的に学習し、対処すべきインシデントに絞り込み登録することにより、バーストに関わる対応工数と作業ミスの削減、ならびにシステム復旧遅延を低減する。【解決手段】インシデント管理システム１０は、バースト判定処理部１２および類似判定処理部１３を有する。バースト判定処理部１２は、障害検知におけるバースト発生を判定し、該バースト発生時における障害情報発生件数に基づいて、バースト判定の条件を示す類似障害情報判定条件を生成する。類似判定処理部１３は、バースト判定処理部が生成した類似障害情報判定条件に基づいて、入力された障害情報について、バースト起因の親インシデントであるか、バーストに付属する子インシデントであるか、あるいはバーストに関与しない通常インシデントであるかを判定する。【選択図】図２
2015060254.tif 000002
【特許請求の範囲】
【請求項１】
障害検知におけるバースト発生を判定し、前記バースト発生時における障害情報発生件数に基づいて、バースト判定の条件を示す類似障害情報判定条件を生成するバースト判定処理部と、
前記バースト判定処理部が生成した類似障害情報判定条件に基づいて、入力された障害情報について、バースト起因の親インシデントであるか、バーストに付属する子インシデントであるか、あるいはバーストに関与しない不関与インシデントであるかを判定する類似判定処理部と、
を有する、インシデント管理システム。
【請求項２】
請求項１記載のインシデント管理システムにおいて、
前記バースト判定処理部は、前記障害情報のバースト発生を判断してから前記障害情報のバースト収束までのバースト期間中の障害情報に含まれる発生元名称とオブジェクト識別子との組み合わせ単位で発生件数を集計し、集計した前記発生件数のうち、予め設定された割合に含まれる発生件数の組み合わせを前記類似障害情報判定条件として生成し、前記類似障害情報判定条件のうち、最多の前記発生元名称と前記オブジェクト識別子との組み合わせをトリガイベントとして設定する、インシデント管理システム。
【請求項３】
請求項２記載のインシデント管理システムにおいて、
前記バースト判定処理部は、単位時間当たりの前記障害情報の発生件数を算出し、算出した前記発生件数が予め設定されたしきい値を超えた際にバースト発生と判断し、集計した前記発生件数のうち、前記トリガイベントの障害情報が発生しなくなった際に、バースト収束と判定する、インシデント管理システム。
【請求項４】
請求項２記載のインシデント管理システムにおいて、
前記類似判定処理部は、受信した障害情報と前記バースト判定処理部が生成した前記類似障害情報判定条件とを照合し、前記類似障害情報判定条件に設定されたトリガイベントに合致し、前記トリガイベントによるバーストが発生していない場合に、当該障害情報を前記親インシデントと判定し、バースト発生中に前記トリガイベントに合致する障害情報を受信した場合、または前記トリガイベント以外の組み合わせに合致した場合に当該障害情報を前記子インシデントと判定し、前記障害情報が前記親インシデントまたは前記子インシデントのいずれでもない場合に当該障害情報を前記不関与インシデントと判定する、インシデント管理システム。
【請求項５】
請求項４記載のインシデント管理システムにおいて、
前記類似判定処理部は、前記不関与インシデントと判定してバーストが収束した際に、前記バースト期間中の障害情報の収束率である障害情報収束率を算出し、前記障害情報収束率が設定値を下回った回数が、設定しきい値以上となった際に、前記類似障害情報判定条件から、前記不関与インシデントと判定した前記発生元名称および前記オブジェクト識別子を削除する、インシデント管理システム。
【請求項６】
障害検知におけるバースト判定の条件を示す類似障害情報判定条件を生成するバースト判定処理を実行するバースト判定処理部と、前記類似障害情報判定条件に基づいて、受信した障害情報のインシデント種別を判定する類似判定処理を実行する類似判定処理部と、を有するコンピュータシステムによるインシデント管理方法であって、
前記バースト判定処理部において、障害情報に基づいて、バースト判定の条件を示す類似障害情報判定条件を生成するステップと、
類似判定処理部において、前記バースト判定処理部が生成した前記類似障害情報判定条件に基づいて、入力された障害情報がバースト起因の親インシデントであるか、バーストに付属する子インシデントであるか、あるいはバーストに関与しない不関与インシデントであるかを判定するステップと、
を有するインシデント管理方法。
【請求項７】
請求項６記載のインシデント管理方法において、
前記類似障害情報判定条件を生成するステップは、
前記障害情報のバースト発生を判断してから前記障害情報のバースト収束までのバースト期間中の障害情報に含まれる発生元名称とオブジェクト識別子との組み合わせ単位で発生件数を集計するステップと、
集計した前記発生件数のうち、予め設定された割合に含まれる発生件数の組み合わせを前記類似障害情報判定条件として生成するステップと、
生成した前記類似障害情報判定条件のうち、最多の前記発生元名称および前記オブジェクト識別子の組み合わせをトリガイベントとして設定するステップと、
を有するインシデント管理方法。
【請求項８】
請求項７記載のインシデント管理方法において、
前記バースト発生は、単位時間当たりの前記障害情報の発生件数が予め設定されたしきい値を超えた際に判断し、
前記バースト収束は、集計した前記発生件数のうち、発生件数が最多となる前記トリガイベントの障害情報が発生しなくなった際に判定する、インシデント管理方法。
【請求項９】
請求項７記載のインシデント管理方法において、
前記親インシデント、前記子インシデント、または前記不関与インシデントを判定するステップは、
受信した障害情報と前記バースト判定処理部が生成した前記類似障害情報判定条件とを照合するステップと、
照合の結果、前記類似障害情報判定条件に設定されたトリガイベントに合致し、前記トリガイベントによるバーストが発生していない場合に当該障害情報を前記親インシデントと判定するステップと、
バースト発生中に前記トリガイベントに合致する障害情報を受信した場合、または前記トリガイベント以外の組み合わせに合致した場合に当該障害情報を前記子インシデントと判定するステップと、
前記障害情報が前記親インシデントまたは前記子インシデントのいずれでもない場合に当該障害情報を前記不関与インシデントと判定するステップと、
を有するインシデント管理方法。
【請求項１０】
請求項９記載のインシデント管理方法において、
さらに、前記不関与インシデントと判定してバーストが収束した際に、前記バースト期間中の障害情報の収束率である障害情報収束率を算出し、前記障害情報収束率が設定値を下回った回数が、設定しきい値以上となった際に、前記類似障害情報判定条件から、前記不関与インシデントと判定した前記発生元名称および前記オブジェクト識別子を削除するステップを有する、インシデント管理方法。
【請求項１１】
障害検知におけるバースト判定の条件を示す類似障害情報判定条件を生成するバースト判定処理と、前記類似障害情報判定条件に基づいて、受信した障害情報のインシデント種別を判定する類似判定処理と、をコンピュータシステムに実行させるプログラムであって、
前記バースト判定処理において、障害情報に基づいて、バースト判定の条件を示す類似障害情報判定条件を生成するステップと、
類似判定処理において、前記バースト判定処理にて生成した前記類似障害情報判定条件に基づいて、入力された障害情報がバースト起因の親インシデントであるか、バーストに付属する子インシデントであるか、あるいはバーストに関与しない不関与インシデントであるかを判定するステップと、
を有するプログラム。
【請求項１２】
請求項１１記載のプログラムにおいて、
前記類似障害情報判定条件を生成するステップは、
前記障害情報のバースト発生を判断してから前記障害情報のバースト収束までのバースト期間中の障害情報に含まれる発生元名称とオブジェクト識別子との組み合わせ単位で発生件数を集計するステップと、
集計した前記発生件数のうち、予め設定された割合に含まれる発生件数の組み合わせを前記類似障害情報判定条件として生成するステップと、
生成した前記類似障害情報判定条件のうち、最多の前記発生元名称および前記オブジェクト識別子の組み合わせをトリガイベントとして設定するステップと、
を有するプログラム。
【請求項１３】
請求項１２記載のプログラムにおいて、
前記バースト発生は、単位時間当たりの前記障害情報の発生件数が予め設定されたしきい値を超えた際に判断し、
前記バースト収束は、集計した前記発生件数のうち、発生件数が最多となる前記発生元名称と前記オブジェクト識別子との組み合わせの障害情報が発生しなくなった際に判定する、プログラム。
【請求項１４】
請求項１２記載のプログラムにおいて、
前記親インシデント、前記子インシデント、または前記不関与インシデントを判定するステップは、
受信した障害情報と前記バースト判定処理部が生成した前記類似障害情報判定条件とを照合するステップと、
照合の結果、前記類似障害情報判定条件に設定されたトリガイベントに合致し、前記トリガイベントによるバーストが発生していない場合に当該障害情報を前記親インシデントと判定するステップと、
バースト発生中に前記トリガイベントに合致する障害情報を受信した場合、または前記トリガイベント以外の組み合わせに合致した場合に当該障害情報を前記子インシデントと判定するステップと、
前記障害情報が前記親インシデントまたは前記子インシデントのいずれでもない場合に当該障害情報を前記不関与インシデントと判定するステップと、
を有するプログラム。
【請求項１５】
請求項１４記載のプログラムにおいて、
さらに、前記不関与インシデントと判定した際に、前記バースト期間中の障害情報の収束率である障害情報収束率を算出し、前記障害情報収束率が設定値を下回った回数が、設定しきい値以上となった際に、前記類似障害情報判定条件から、前記不関与インシデントと判定した前記発生元名称および前記オブジェクト識別子を削除するステップを有する、プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インシデント管理システム、インシデント管理方法、およびプログラムに関し、特に、情報処理システムのインシデント管理運用業務におけるインシデント対応工数削減、および作業ミス削減に有効な技術に関する。
【背景技術】
【０００２】
データセンタでは、お客様からお預かりした情報システムのインシデント発生を通報すると共に、システム復旧に努める、インシデント管理運用業務が存在する。当業務の従事者は、システムを迅速に復旧し、顧客業務への影響を最低限に抑えなければならない。
【０００３】
インシデントからシステムを早急に復旧する仕組みとしては、例えば特開２０１１−７６１６１号公報などが知られている。この技術は、監視対象から発生した障害情報をインシデントとして登録し、システム復旧までの処理状況を可視化してインシデント管理運用業務の効率化を促すものである。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１１−７６１６１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところが、上記のようなインシデント管理運用技術では、次のような問題点があることが本発明者により見い出された。
【０００６】
データセンタには、数多くの監視対象機器が存在しており、短期間で多数の障害情報が発生する、いわゆるバーストに陥ることがある。バースト状況下では、共通の原因に影響を受けるシステムから、多種多様なインシデントが連続的に大量発生する。
【０００７】
発生した障害情報の全てが個々のインシデントとして登録されてしまうと、担当者が既出インシデントとの関係を調査し、既出インシデントで障害として対処中であることを記載する、もしくは、全く別現象のインシデントとして対処する必要がある。
【０００８】
この人に依存する判断と対処が作業量と作業ミスを増やす問題が発生する。また、多発したインシデントに別原因のインシデントが埋もれてしまい、バーストとは別原因のシステムの復旧が遅れる問題も併発することになる。
【０００９】
例え、既出インシデントで対処中の現象か否かを判定してインシデントを登録する仕組みを有していても、手作業による多数の判定条件更新を必要とするならば、既存設定内容を踏まえた判定条件の検討と設定作業工数が増え、新たな障害としての対処を必要とするインシデントを対処済と誤判断させるような設定ミスも増える結果につながる。
【００１０】
このように、対応工数や設定ミスなどが増加すると、バーストに関与しないシステムの復旧が遅延する可能性が高まるという問題がある。加えて、インシデント登録判定条件の手動更新に必要な工数増加および設定ミスによる事故発生率が高まる恐れも生じてしまう。
【００１１】
本発明の目的は、共通の原因による障害情報の判定条件を自動的に学習し、対処すべきインシデントに絞り込み登録することにより、バーストに関わる対応工数と作業ミスの削減、ならびにシステム復旧遅延を低減する技術を提供することにある。
【００１２】
本発明の前記ならびにその他の目的と新規な特徴については、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１３】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、次のとおりである。
【００１４】
すなわち、代表的なものの概要は、インシデント管理システムに適用され、以下のような特徴を有するものである。
【００１５】
インシデント管理システムは、バースト判定処理部および類似判定処理部を有する。バースト判定処理部は、障害検知におけるバースト発生を判定し、該バースト発生時における障害情報発生件数に基づいて、バースト判定の条件を示す類似障害情報判定条件を生成する。類似判定処理部は、バースト判定処理部が生成した類似障害情報判定条件に基づいて、入力された障害情報について、バースト起因の親インシデントであるか、バーストに付属する子インシデントであるか、あるいはバーストに関与しない不関与インシデント（通常インシデント）であるかを判定する。
【００１６】
また、本発明は、類似する障害情報の判定条件を自動的に生成し、精度の高い類似障害情報判定条件を生成するシステムによる方法や、前記システムとしてコンピュータシステムを機能させるプログラムにも適用することができる。
【発明の効果】
【００１７】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００１８】
（１）対応工数および作業ミスを低減することができる。
【００１９】
（２）バーストに関与しないシステムの復旧遅延の発生を低減することができる。
【図面の簡単な説明】
【００２０】
【図１】一実施の形態による単位時間内の障害情報発生状況を示した説明図である。
【図２】一実施の形態によるデータセンタにおける構成の一例を示す説明図である。
【図３】図２のインシデントデータベースが有するインシデント情報テーブルの構成例を示す説明図である。
【図４】図２の類似障害情報データベースが有する類似障害情報テーブルの構成例を示す説明図である。
【図５】図２のインシデント管理システムに設けられたバースト判定処理部が実行するバースト判定処理の一例を示すフローチャートである。
【図６】図２のインシデント管理システムに設けられた類似判定処理部が実行する類似判定処理の一例を示すフローチャートである。
【図７】図６に続くフローチャートである。
【発明を実施するための形態】
【００２１】
以下の実施の形態においては便宜上その必要があるときは、複数のセクションまたは実施の形態に分割して説明するが、特に明示した場合を除き、それらはお互いに無関係なものではなく、一方は他方の一部または全部の変形例、詳細、補足説明等の関係にある。
【００２２】
また、以下の実施の形態において、要素の数等（個数、数値、量、範囲等を含む）に言及する場合、特に明示した場合および原理的に明らかに特定の数に限定される場合等を除き、その特定の数に限定されるものではなく、特定の数以上でも以下でもよい。
【００２３】
さらに、以下の実施の形態において、その構成要素（要素ステップ等も含む）は、特に明示した場合および原理的に明らかに必須であると考えられる場合等を除き、必ずしも必須のものではないことは言うまでもない。
【００２４】
同様に、以下の実施の形態において、構成要素等の形状、位置関係等に言及するときは特に明示した場合および原理的に明らかにそうではないと考えられる場合等を除き、実質的にその形状等に近似または類似するもの等を含むものとする。このことは、上記数値および範囲についても同様である。
【００２５】
また、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。なお、図面をわかりやすくするために平面図であってもハッチングを付す場合がある。
【００２６】
〈概要〉
まず、図１を用いて、本実施の形態の概要を説明する。
【００２７】
図１は、本実施の形態による単位時間内の障害情報発生状況を示した説明図である。図１において、オブジェクト識別子であるＯＩＤ（Object IDentifier）は、監視対象機器が障害情報に含める、異常に関する情報の種別を一意に示す値である。ＯＩＤは、監視対象機器の異常発生箇所を知る手がかりになる。
【００２８】
障害情報バースト時の発生元名称とＯＩＤの組み合わせ件数から、ある異常のおおよその影響範囲を推測できる。例えば図１の発生件数上位９割を同一原因の影響によりバーストした障害情報とみなし、この範囲に属する障害情報の発生元名称とＯＩＤの組み合わせを類似障害情報判定条件として記録する。特に、最多の組み合わせは、トリガイベントとして記録する。以後、類似障害情報判定条件をバーストした障害情報の類似判定に用いる。
【００２９】
具体的には、トリガイベントと同じ発生元名称とＯＩＤを含む障害情報が発生したら、この障害情報を親インシデントとして登録すると共に、同一原因でバーストした障害情報の判定を開始する。
【００３０】
判定開始後、類似障害情報判定条件の発生元名称とＯＩＤを含む障害情報は、類似とみなし、登録済親インシデントの子インシデントとして登録する。トリガイベントが例えば１分間発生しなければ、バースト収束と見なし判定を打ち切る。
【００３１】
また、類似障害情報の収束率を高めるため、例えば収束率５０％未満が３回続いたら、この類似障害情報判定条件を破棄する。破棄した後、障害情報のバースト再発により、類似障害情報判定条件を自動的に再生成する。これにより、より精度の高い類似障害情報判定条件の学習が可能になる。
【００３２】
インシデント管理システム１０は、インシデント情報テーブル２１および類似障害情報テーブル３１などを用いて、バーストした障害情報の類似障害情報判定条件を抽出し、バースト再発時の障害情報収束率に基づいて類似障害情報判定条件を見直し、より精度の高い類似障害情報判定条件を自動的に習得する。
【００３３】
インシデント管理システム１０は、単位時間当たりの障害情報発生件数を測定し、設定したしきい値を超過した場合、バースト発生と判断する。この単位時間内の障害情報発生件数を発生元名称およびＯＩＤの組み合わせ毎に集計する。特に、発生最多の組み合わせをトリガイベントとして扱う。
【００３４】
バースト後、単位時間当たりのトリガイベント発生が０件であると、バーストが収束したと判断する。バースト収束後は、改めてバースト中の障害情報発生件数を発生元名称とＯＩＤとの組み合わせ毎に集計する。
【００３５】
そして、発生件数が高い順に組み合わせを列挙し、その上位９割に含まれる組み合わせを類似障害情報テーブル３１に登録する。また、最多の組み合わせは、トリガイベントとして登録する。
【００３６】
以後、インシデント管理システム１０が受信した障害情報に含まれる発生元名称とＯＩＤとの組み合わせがトリガイベントと同じであれば、バースト再発と見なし、インシデント情報テーブル２１に障害情報を親インシデントとして登録すると共に、同一原因で発生した障害情報の判定を開始する。
【００３７】
類似障害情報テーブル３１にトリガイベントと同一グループにて登録している発生元名称とＯＩＤとの組み合わせを同一原因により発生した障害情報と判定し、インシデント情報テーブルに子インシデントとして登録する。
【００３８】
再発したバーストが終了した後、バースト期間中に親子設定した障害情報件数／バースト期間中の全障害情報件数の算出により、障害情報の収束率を求める。収束率が５０％未満であれば、類似障害情報テーブル３１内のトリガイベントレコードの収束率５０％未満回数を繰り上げる。収束率が９０％以上であれば、収束率５０％未満回数を０クリアする。
【００３９】
収束率５０％未満の回数が３に達したら、そのトリガイベントを含む類似障害情報判定条件を類似障害情報テーブル３１から削除する。削除された類似障害情報判定条件は、冒頭の単位時間当たりの障害情報発生件数しきい値超過によるバースト検知プロセスにより再習得する。
【００４０】
これらにより、収束率の高い類似障害情報判定条件を自動的に学習し、インシデントの発生件数を抑えることができる。
【００４１】
〈インシデント管理運用システムの構成例〉
図２は、本実施の形態によるデータセンタにおける構成の一例を示す説明図である。
【００４２】
データセンタ１は、図示するように、複数の監視対象機器２、障害監視装置３、運用端末４、インシデント管理システム１０、インシデントデータベース２０、および類似障害情報データベース３０を有する。なお、図２では、監視対象機器２が３つであるが、監視対象機器２の台数は複数台であればよい。
【００４３】
また、インシデント管理システム１０は、障害情報入力部１１、バースト判定処理部１２、および類似判定処理部１３を有する。インシデントデータベース２０には、インシデント情報テーブル２１が格納されている。類似障害情報データベース３０には、類似障害情報テーブル３１が格納されている。
【００４４】
３つの監視対象機器２は、障害監視装置３にそれぞれ接続されている。この障害監視装置３には、インシデント管理システム１０における障害情報入力部１１が接続されている。運用端末４は、インシデント管理システム１０に接続されている。
【００４５】
障害情報入力部１１には、インシデントデータベース２０が接続されている。バースト判定処理部１２には、類似障害情報データベース３０が接続されている。類似判定処理部１３には、インシデントデータベース２０および類似障害情報データベース３０がそれぞれ接続されている。
【００４６】
監視対象機器２は、たとえば、情報処理システムなどの電子システムからなる。障害監視装置３は、監視対象機器２にて発生した障害を自動的に収集し、インシデント管理システム１０の障害情報入力部１１に送信する。インシデント管理システム１０における障害情報入力部１１は、障害監視装置３が送信した障害情報を受信する。
【００４７】
バースト判定処理部１２は、バースト判定の条件を生成する処理であるバースト判定処理を行う。具体的には、単位時間当たりの障害情報発生件数を算出し、その算出値が予め設定されたしきい値を超える場合に、障害情報のバースト発生と判断する。そして、バースト収束後、バースト期間中の障害情報に含まれる発生元名称とＯＩＤとの組み合わせ単位で発生件数を集計する。発生件数の多い順にソートし、上位から全体の９割に含まれる組み合わせを類似障害情報判定条件として、類似障害情報データベース３０が有する類似障害情報テーブル３１に登録する。特に、最多の組み合わせには、トリガイベントのフラグを設定する。
【００４８】
類似判定処理部１３は、類似判定処理を実行する。この類似判定処理は、障害監視装置３から受信した障害情報が類似障害情報データベース３０が有する類似障害情報テーブル３１に登録されている組み合わせか否かを照合する。
【００４９】
そして、類似障害情報テーブル３１におけるトリガイベントフラグが設定された組み合わせに合致し、同イベントによるバーストが発生していない場合に、バーストの引き金である親インシデントと判定する。
【００５０】
バースト発生中にトリガイベントの組み合わせに合致する障害情報を受信した場合、もしくはトリガイベント以外の組み合わせに合致した場合は、子インシデントと判定する。上記のいずれにも合致しない場合には、バーストに関与しない不関与インシデントである通常インシデントと判定する。また、類似判定処理部１３は、判定結果を含むインシデントをインシデントデータベース２０のインシデント情報テーブル２１に登録する。
【００５１】
〈インシデント情報テーブルの構成例〉
図３は、図２のインシデントデータベース２０が有するインシデント情報テーブル２１の構成例を示す説明図である。
【００５２】
インシデント情報テーブル２１は、図３に示すように、インシデントＩＤ、発生時刻、発生元名称、ＯＩＤ、ステータス、類似判定条件、親子、およびメッセージの項目を有する。
【００５３】
インシデントＩＤは、インシデントを一意に識別するための文字列などである。発生時刻は、障害情報の発生した時刻を示す。発生元名称は、障害情報の発生元名称である。ＯＩＤは、発生した障害の識別子である。ステータスは、インシデントの対応状況を示す。類似判定条件は、親子の判定に用いた類似障害情報判定条件の識別子である。親子は、親子の判定結果を示す。この親子の項目の値は、親インシデントに○、子インシデントは、親になるインシデントＩＤ、通常インシデントは、空欄を収めるものとする。メッセージは、メッセージを記入する項目である。
【００５４】
〈類似障害情報テーブルの構成例〉
図４は、図２の類似障害情報データベース３０が有する類似障害情報テーブル３１の構成例を示す説明図である。
【００５５】
類似障害情報テーブル３１は、図４に示すように、類似判定条件ＩＤ、発生元名称、ＯＩＤ、トリガイベント、および収束率５０％未満回数の項目を有する。
【００５６】
類似判定条件ＩＤは、一群の類似障害情報判定条件を識別する文字列などである。発生元名称は、バースト時に障害情報を発生させる発生元の名称である。ＯＩＤは、バースト時に発生する障害情報の識別子である。トリガイベントは、バースト開始の判定条件であることを示す。収束率５０％未満回数は、類似障害情報判定条件を適用してもバーストしたメッセージの収束率が５０％未満にとどまった回数を記録する。
【００５７】
なお、以下に、図５〜図７により説明するバースト判定処理部１２および類似判定処理部１３における処理機能は、例えばインシデント管理システム１０に設けられたプログラム格納メモリ（図示せず）などに記憶されているプログラム形式のソフトウェアを、該インシデント管理システムの図示しないＣＰＵ（Central Processing Unit）などが実行することにより実現する。
【００５８】
〈バースト判定処理部の処理例〉
図５は、図２のインシデント管理システム１０に設けられたバースト判定処理部１２が実行するバースト判定処理の一例を示すフローチャートである。
【００５９】
バースト判定処理部１２は、図５に示すフローチャートに従い、障害情報のバースト発生を検知する。そして、バースト期間中に受信した障害情報に含まれる発生元名称とＯＩＤとの組み合わせの一部を類似障害情報判定条件として類似障害情報データベース３０の類似障害情報テーブル３１に格納する。
【００６０】
以下、バースト判定処理について説明する。
【００６１】
まず、バースト判定処理部１２は、前日同時同分の障害情報発生件数を算出する（ステップＳ１０１）。障害情報発生件数の算出は、例えば１分間当たりの件数（Ａ件／分）であり、８時００分の場合には、前日の８時００分から８時０１分までの１分間当たりの障害情報発生件数を算出する。
【００６２】
続いて、運用者がインシデント管理システム１０に予め設定したバーストしきい値（Ｂ件／分）を取得する（ステップＳ１０２）。そして、バースト判定処理部１２は、ステップＳ１０１の処理において算出した障害情報発生件数（Ａ件／分）が、ステップＳ１０２の処理において取得したバーストしきい値（Ｂ件／分）以上ならば、バースト発生と判定する（ステップＳ１０３）。
【００６３】
バースト発生と判定した場合、バースト判定処理部１２は、ステップＳ１０１の処理にて件数算出対象にした分内に含まれる障害情報の発生件数を発生元名称とＯＩＤとの組み合わせで集計する（ステップＳ１０４）。ステップＳ１０３の処理において、バースト発生でないと判定した際には、バースト判定処理が終了となる。
【００６４】
続いて、バースト判定処理部１２は、ステップＳ１０４の処理にて集計した組み合わせのうち、発生件数が最多となる組み合わせを取り出し（ステップＳ１０５）、取り出した組み合わせが、類似障害情報データベース３０の類似障害情報テーブル３１にトリガイベントとして登録されているか否か確認する（ステップＳ１０６）。
【００６５】
トリガイベントとして登録されている場合には、バースト判定処理を終了する。また、トリガイベントとして登録されていない場合には、バースト開始時刻として、ステップＳ１０１の処理にて件数算出対象にした時刻を記録する（ステップＳ１０７）。
【００６６】
バースト開始時刻以降、ステップＳ１０５の処理にて取り出した発生元名称とＯＩＤとを含む障害情報が発生しなくなる時刻を探索し、その時刻をバーストが収束した時間、すなわちバースト終了時刻として記録する（ステップＳ１０８）。
【００６７】
その後、バースト判定処理部１２は、ステップＳ１０７の処理におけるバースト開始時間からステップＳ１０８の処理のバースト終了時間までのバースト期間中に発生した障害情報の件数を算出し、算出した全件数のうち、例えば上位９０％が何件になるか算出する（ステップＳ１０９）。このステップＳ１０９の処理における件数の算出は、９０％に限定されるものではない。
【００６８】
そして、バースト判定処理部１２は、バースト期間中に発生した障害情報の発生元名称とＯＩＤとの組み合わせ別件数を集計し（ステップＳ１１０）、集計した発生件数を例えば昇順にてソートする（ステップＳ１１１）。
【００６９】
続いて、バースト判定処理部１２は、ステップＳ１０９の処理において算出した全件の上位９０％を構成する組み合わせを取得し（ステップＳ１１２）、取得した組み合わせを、類似障害情報判定条件として類似障害情報テーブル３１に登録する（ステップＳ１１３）。ステップＳ１１３の処理にて登録した組み合わせのうち、ステップＳ１０５の処理において取り出した最多発のイベントにトリガイベントのフラグを立てる（ステップＳ１１４）。
【００７０】
以上により、バースト判定の条件を生成するバースト判定処理が終了となる。
【００７１】
〈類似判定処理部の処理例〉
続いて、類似判定処理について説明する。
【００７２】
図６および図７は、図２のインシデント管理システム１０に設けられた類似判定処理部１３が実行する類似判定処理の一例を示すフローチャートである。
【００７３】
類似判定処理部１３は、図６および図７に示すフローチャートに従って類似判定処理を実行する。この類似判定処理は、検知した各々の障害情報について、バースト起因の親インシデント、バーストに付属する子インシデント、もしくはバーストに関与しない通常インシデントであるかを判定し、インシデントデータベース２０が有するインシデント情報テーブル２１に登録する。また、バースト収束率が低い類似障害情報判定条件は、類似障害情報データベース３０が有する類似障害情報テーブル３１から削除する。
【００７４】
以下、類似判定処理について、図２、図６および図７を用いて説明する。
【００７５】
まず、図６において、類似判定処理部１３は、障害情報入力部１１が受信した障害情報から、発生元名称とＯＩＤとを取り出し（ステップＳ２０１）、取り出した発生元名称およびＯＩＤをバースト中認定障害情報と照合する（ステップＳ２０２）。このバースト中認定障害情報は、障害情報がバースト中であるか否かを判定する情報である。例えばステップＳ２０１の処理の発生元名称およびＯＩＤがバースト中認定障害情報に含まれている場合には、その障害情報は、バースト中であると判断する。
【００７６】
発生元名称およびＯＩＤがバースト中認定障害情報に含まれていないと判断した際には、ステップＳ２０４の処理に進み、バースト中認定障害情報に含まれると判断した場合には、図７に示すステップＳ２１９の処理に進む（ステップＳ２０３）。
【００７７】
続いて、類似判定処理部１３は、ステップＳ２０１の処理における発生元名称およびＯＩＤの組み合わせを、類似障害情報テーブル３１に登録されている類似障害情報判定条件に含まれるトリガイベントから検索する（ステップＳ２０４）。
【００７８】
トリガイベントに合致すると判定した場合には、ステップＳ２０６の処理に進み、トリガイベントに合致しないと判定した場合には、ステップＳ２０９の処理に進む（ステップＳ２０５）。
【００７９】
トリガイベントに合致すると判定すると、類似判定処理部１３は、ステップＳ２０６の処理にて合致したトリガイベントを含む類似障害情報判定条件を類似障害情報テーブル３１から取りだし、バースト中認定障害情報の配列に加える（ステップＳ２０６）。
【００８０】
ここで、類似障害情報判定条件は、トリガイベント起因のバーストで発生する障害情報に含まれる発生元名称とＯＩＤとの組み合わせである。この条件に合致する障害情報を親子インシデントとして収束する。
【００８１】
そして、類似判定処理部１３は、ステップＳ２０１の処理における障害情報をバースト開始の親インシデントとして、インシデント情報テーブル２１に登録する（ステップＳ２０７）。
【００８２】
続いて、類似判定処理部１３は、ステップＳ２０５の処理にてトリガイベントに合致すると判定したことにより、トリガイベントが発生してバーストが開始したと見なし、親インシデントＩＤ、トリガイベントの最新発生時刻、および類似認定件数を有するバーストカウンタを生成し、類似判定処理を終える（ステップＳ２０８）。このバーストカウンタは、例えばインシデント管理システム１０に設けられた図示しないメモリなどを用いる。
【００８３】
ステップＳ２０５の処理にてトリガイベントに合致しないと判定した場合、ステップＳ２０１の処理の障害情報をバーストに関与しない通常インシデントとして、インシデント情報テーブル２１に登録する（ステップＳ２０９）。
【００８４】
類似判定処理部１３は、前述したバーストカウンタを確認し、トリガイベント最新発生時刻から１分以上経過しているか確認する（ステップＳ２１０）。１分以上経過している場合には、ステップＳ２１２の処理に進み、１分以上経過していない場合には、類似判定処理を終了する（ステップＳ２１１）。
【００８５】
ステップＳ２１０の処理にてトリガイベント最新発生時刻から１分以上経過している場合には、トリガイベントが１分以上発生しておらず、バーストは収束したと見なし、対象のバースト中認定障害情報を削除する（ステップＳ２１２）。
【００８６】
その後、類似判定処理部１３は、バースト期間中の収束率を算出する（ステップＳ２１３）。この収束率の算出は、例えばバースト期間中に発生し、類似と認定した障害情報件数の全障害情報件数による商を求めることにより、バースト期間中の障害情報収束率を求める。
【００８７】
ステップＳ２１３の処理にて算出した収束率が、例えば９０％未満であれば、ステップＳ２１５の処理に進み、収束率が９０％以上であれば、図７に示すステップＳ２１８の処理に進む（ステップＳ２１４）。なお、９０％は、一例を示したものであり、この数字に限定されるものではない。
【００８８】
ステップＳ２１４の処理において、収束率が９０％未満の場合には、類似障害情報テーブル３１のトリガイベントレコードに含まれる収束率５０％未満の回数をインクリメントする（ステップＳ２１５）。ここでも、５０％は、一例を示したものであり、この数字に限定されるものではない。
【００８９】
そして、更新後収束率５０％未満の回数が３以上であるか否かを判定する（ステップＳ２１６）。ここで、判定回数である３についても、限定されるものではない。判定の結果、更新後収束率５０％未満の回数が３未満であれば、類似判定処理を終了する。また、更新後収束率５０％未満の回数が３以上であれば、類似障害情報テーブル３１から、更新したトリガイベントを含む類似障害情報判定条件レコードを削除する（ステップＳ２１７）。そして、削除の後、類似判定処理は終了となる。
【００９０】
ステップＳ２１４の処理において、収束率が９０％以上の場合、類似判定処理部１３は、図７に示すように、類似障害情報テーブル３１のトリガイベントレコードに含まれる収束率５０％未満の回数を０に更新し（ステップＳ２１８）、類似判定処理を終了する。
【００９１】
ステップＳ２０３の処理にて発生元名称およびＯＩＤがバースト中認定障害情報に含まれると判断した場合、図７に示すように、類似判定処理部１３は、ステップＳ２０１の処理における障害情報を発生中バーストの子インシデントとして、インシデント情報テーブル２１に登録する（ステップＳ２１９）。
【００９２】
その後、類似判定処理部１３は、バーストカウンタの類似認定件数をインクリメントする（ステップＳ２２０）。続いて、類似判定処理部１３は、ステップＳ２０１の処理による発生元名称およびＯＩＤの組み合わせが、類似障害情報判定条件に含まれるトリガイベントであるか判定する（ステップＳ２２１）。
【００９３】
類似障害情報判定条件に含まれるトリガイベントの場合、類似判定処理部１３は、バーストカウンタにおけるトリガイベントの最新発生時刻を更新する（ステップＳ２２２）。ステップＳ２２２の処理後、またはステップＳ２２１の処理にて類似障害情報判定条件に含まれないトリガイベントであると判定した際には、類似判定処理が終了となる。
【００９４】
以上のように、バーストした障害情報の類似障害情報判定条件を抽出し、バースト再発時の障害情報収束率に基づいて類似障害情報判定条件を見直すことにより、より精度の高い類似障害情報判定条件を自動的に習得することができる。
【００９５】
それにより、バーストが多発した際においてもインシデントの発生件数を抑えることができるので、インシデント対応に関わる工数および作業ミスを低減することができる。また、対応工数や作業ミスなどが低減することによって、監視対象機器２の早期復旧を実現することができる。
【００９６】
さらに、インシデントの発生件数を抑えることによって、多発したインシデントとは別原因のインシデントを早期に発見することが可能となり、バーストとは別原因の監視対象機器２における復旧の遅延を防止することができる。
【００９７】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【００９８】
なお、本発明は上記した実施の形態に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。
【００９９】
また、ある実施の形態の構成の一部を他の実施の形態の構成に置き換えることが可能であり、また、ある実施の形態の構成に他の実施の形態の構成を加えることも可能である。また、各実施の形態の構成の一部について、他の構成の追加、削除、置換をすることが可能である。
【符号の説明】
【０１００】
１  データセンタ
２  監視対象機器
３  障害監視装置
４  運用端末
１０  インシデント管理システム
１１  障害情報入力部
１２  バースト判定処理部
１３  類似判定処理部
２０  インシデントデータベース
２１  インシデント情報テーブル
３０  類似障害情報データベース
３１  類似障害情報テーブル
【図１】
2015060254.tif 000003
【図２】
2015060254.tif 000004
【図３】
2015060254.tif 000005
【図４】
2015060254.tif 000006
【図５】
2015060254.tif 000007
【図６】
2015060254.tif 000008
【図７】
2015060254.tif 000009