JP6549959B2 - 障害切り分け方法および障害切り分けを行う管理サーバ - Google Patents

Description

本発明は、ネットワークシステムにおいて発生する障害を特定する技術に関する。

ネットワークシステムにおいて発生する障害を特定する場合、ルールに基づき、障害原因分析を行う技術（Root Cause Analysis：RCA)が知られている（特許文献１）。

特開２０１２−２５６３５５号公報

ネットワークシステムにおいて発生する障害を特定する場合、ネットワーク中の特定の対象に対して操作を行い（この操作を「アクション」という）、アクションに対応して生じる事象（「イベント」という）を取得し、取得したイベントを所定のルールに当てはめて、障害の内容や個所を特定する必要がある。

RCAでは、イベント発生を条件として障害原因を切り分けるため、アラート（障害を示すイベント）が得られないケースや、ルール化できていない障害では原因分析できないケースがある。このため、原因分析の精度向上が一つの課題である。

また、アクションはネットワーク資源を利用して、特定対象に対する操作を行うものである。ネットワークシステム中に発生する障害は多種多様であり、全ての障害に対してこれを特定するアクションを行うことは、トラフィックを圧迫し、リソースを大量に消費することになる。

一方、限定された対象にのみアクションを行えば、トラフィックを圧迫はしないが、障害の内容や個所を精度よく特定することが困難となる。特に、クラウドおよびネットワークの仮想化が進んでいる現状では、仮想化された各種リソースを用いてサービスが構築されるため、障害が発生したときの切り分けが困難である。

本発明の目的は、リソースの消費を抑制しつつ、ネットワーク中の障害の内容や個所を精度よく特定することにある。

上記課題を解決する本発明の一側面は、監視対象に対して、可能性のある障害を根本原因イベントとして抽出する障害切り分け方法である。この方法では、監視対象に対して、所定の動作を指示するアクションを実行し、アクションの結果として得られる障害イベントを収集する、アクション実行ステップと、障害イベントに基づいて、監視対象に対して、所定の動作を指示する追加のアクションを実行し、追加のアクションの結果として得られる追加の障害イベントを収集する追加アクション実行ステップと、追加の障害イベントを、予め定められた障害原因分析ルールに基づいて分析し、根本原因イベントおよびその確信度を判定する障害原因分析ステップと、根本原因イベントおよびその確信度に基づいて、分析完了判定を行う分析完了判定ステップ、を備える。

さらに具体的な構成例を例示すると、分析完了判定ステップにおいて、確信度が所定要件を満たさない場合、追加アクション実行ステップと、障害原因分析ステップと、分析完了判定ステップを再度実行する。

さらに具体的な構成例を例示すると、追加アクション実行ステップの前に、追加アクション判定ステップを備え、追加アクション判定ステップは、障害イベントに基づいて、予めレベル分けされて準備された追加のアクションのうちから、追加アクション実行ステップと、障害原因分析ステップと、分析完了判定ステップの実行回数に応じたレベルのアクションから、実行すべき追加のアクションを判定する。

さらに具体的な構成例を例示すると、障害原因分析ルールは、根本原因イベントに対応して、根本原因発生成立条件を列挙した情報であり、障害原因分析ステップは、障害イベントと根本原因発生条件の対応を示した、障害イベント−根本原因発生条件対応マップを用いて、追加の障害イベントにより、前記根本原因発生成立条件を抽出する。また、抽出された根本原因発生成立条件と障害原因分析ルールに基づいて、根本原因イベントおよびその確信度を判定する。

さらに具体的な構成例を例示すると、追加アクション判定ステップは、根本原因イベントと追加のアクションを対応付けた根本原因イベント番号−追加アクション対応表を用い、障害原因分析ステップで判定された根本原因イベントに対応する、追加のアクションを判定する。

さらに具体的な構成例を例示すると、分析完了判定ステップは、障害原因分析ステップで判定された前記根本原因イベントの、最上位候補と次点候補の確信度の差が所定要件を満たしているか否か、および、最上位候補の確信度が所定要件を満たしているか否か、の少なくとも一つの要件を用いて、前記分析完了判定を行う。

さらに具体的な構成例を例示すると、分析完了判定ステップは、障害原因分析ステップで判定された根本原因イベントの、最上位候補と他の候補の確信度の差が所定閾値未満の場合、最上位候補との確信度の差が前記所定閾値未満の候補を残し、他の候補を削除する。

さらに具体的な構成例を例示すると、根本原因イベント番号−追加アクション対応表は、出現頻度情報を有し、出願頻度情報には、分析完了判定ステップで分析完了判定した際に、絞り込んだ根本原因イベントの出現頻度に対応した情報を格納し、追加アクション判定ステップでは、出現頻度情報を用いて追加のアクションを判定する。

さらに具体的な構成例を例示すると、監視対象間の関係を示す情報であるトポロジー情報を取得し、トポロジー情報に基づいて、障害原因分析ルール、障害イベント−根本原因発生条件対応マップ、および、根本原因イベント番号−追加アクション対応表を、追加または修正する。

本発明の他の一側面は、監視対象に対して、可能性のある障害を根本原因イベントとして抽出する障害切り分け方法である。この方法では、監視対象に対して所定のアクションを行い、アクションの結果である障害イベントを収集し、障害イベントを障害原因分析ルールに当てはめて、根本原因イベントを確信度とともに絞り込む第１のステップ、第1のステップの結果、絞り込まれた根本原因イベントおよび確信度が、所定の要件を満たし絞り込みが完了したかどうかを判定する第２のステップ、第２のステップの結果、絞り込みが完了していない場合、監視対象に対して所定の追加のアクションを行い、追加のアクションの結果である追加の障害イベントを収集し、当該追加の障害イベントを前記障害原因分析ルールに当てはめて、根本原因イベントを確信度とともに絞り込む第３のステップ、を備え、第３のステップを第1のステップとして、第２のステップに回帰させ、前記絞り込みが完了するまで、処理を継続する。

本発明の他の一側面は、監視対象に対して、可能性のある障害を根本原因イベントとして抽出する障害切り分けを行う管理サーバである。このサーバは、監視対象に対して、所定の動作を指示するアクションを実行し、アクションの結果として得られる障害イベントを収集する、アクション実行モジュールと、障害イベントに基づいて、監視対象に対して、所定の動作を指示する追加のアクションを実行し、追加のアクションの結果として得られる追加の障害イベントを収集する追加アクション実行モジュールと、追加の障害イベントを、予め定められた障害原因分析ルールに基づいて分析し、根本原因イベントおよびその確信度を判定する障害原因分析モジュールと、根本原因イベントおよびその確信度に基づいて、分析完了判定を行う分析完了判定モジュール、を備える。

リソースの消費を抑制しつつ、ネットワーク中の障害の内容や個所を精度よく特定することができる。

実施例１の全体フローの概要を示す流れ図。 実施例１の全体システムの概要を示すブロック図。 実施例１の具体的な適用例を説明するブロック図。 根本原因イベント一覧を示す表図。 トランシーバ故障についての障害原因分析ルールを示す表図。 トランシーバ故障についての障害原因分析ルールを示す表図（つづき）。 ＬＩＮＫ断についての障害原因分析ルールを示す表図。 ＬＩＮＫ断についての障害原因分析ルールを示す表図（つづき）。 障害イベントの一覧の例を示す表図。 障害イベント−根本原因発生条件対応マップの例を示す表図。 障害イベント−根本原因発生条件対応マップの例を示す表図（つづき）。 障害イベント−根本原因発生条件対応マップの例を示す表図（つづき）。 障害イベント−根本原因発生条件対応マップの例を示す表図（つづき）。 障害イベント−根本原因発生条件対応マップの例を示す表図（つづき）。 障害イベント−根本原因発生条件対応マップの例を示す表図（つづき）。 障害イベント−根本原因発生条件対応マップの例を示す表図（つづき）。 障害イベント−根本原因発生条件対応マップの例を示す表図（つづき）。 障害イベント−根本原因発生条件対応マップの例を示す表図（つづき）。 根本原因イベント番号−追加アクション対応表を示す表図。 根本原因イベント番号−追加アクション対応表を示す表図（つづき）。 追加アクションの一覧を示す表図。 追加アクションと障害イベント番号対応表を示す表図。 追加アクションと障害イベント番号対応表を示す表図（つづき）。 本実施例の障害原因切り分けの流れの概要を示す図。 本実施例の障害原因切り分けの流れの概要を示す図（つづき）。 分析終了判定処理（S1204）のフローの一例を示す流れ図。 実施例１で想定する故障の判定実行例概念図。 コンポーネント管理テーブルの実施例を示す表図。 実施例２の全体フローの概要を示す流れ図。 実施例２の全体システムの概要を示すブロック図。 ネットワークトポロジーにおける接続関係を把握する概念図。 リンク接続関係管理テーブルの例を示す表図。 実施例１で想定するクライアント追加の概念図。 追加・変更されるコンポーネント管理テーブルの実施例を示す表図。 追加・変更されるリンク接続関係管理テーブルの例を示す表図。 リンク接続関係管理テーブルの内容を、図４〜図１１の各情報に反映する方法を説明する概念図。 実施例３の根本原因イベント番号−追加アクション対応表を示す表図。

実施の形態について、図面を用いて詳細に説明する。ただし、本発明は以下に示す実施の形態の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。

以下に説明する発明の構成において、同一部分又は同様な機能を有する部分には同一の符号を異なる図面間で共通して用い、重複する説明は省略することがある。

本明細書等における「第１」、「第２」、「第３」などの表記は、構成要素を識別するために付するものであり、必ずしも、数または順序を限定するものではない。また、構成要素の識別のための番号は文脈毎に用いられ、一つの文脈で用いた番号が、他の文脈で必ずしも同一の構成を示すとは限らない。また、ある番号で識別された構成要素が、他の番号で識別された構成要素の機能を兼ねることを妨げるものではない。

図面等において示す各構成の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面等に開示された位置、大きさ、形状、範囲などに限定されない。

以下で説明する実施例では、異種仮想化環境が混在するサービスシステムの切り分けにおいて、ルールベースで障害原因分析を行い、障害確率の高いコンポーネントを絞り込み、その後、コンポーネントに対応するシナリオを用いて追加アクションを実施する例を説明する。

追加アクションとしては、切り分けテストを行う方法と、追加情報を取得する方法がある。切り分けテストを実施する方法では、テストシナリオのマッチングにおいて、障害原因分析結果と、その障害の発生した時の論理・物理の対応関係を用いることで、障害発生時のコンポーネントを特定してテストを行う。

追加情報を取得する場合には、追加で収集が必要な情報及びその対象装置を、障害原因分析結果と、その障害の発生した時の論理・物理の対応関係を用いることで、障害発生時のコンポーネントを特定し、追加情報の取得を行う。

更に、これら追加アクションを実施することで得られた結果に対して、再度障害原因分析を実施する。これらの動作を繰り返し、分析結果の精度が一定の基準以上高まった場合に、分析結果とする。

本実施例では、このように、障害原因分析結果と論物マッピング表を用いてコンポーネントテストを実施して推論精度を向上することにより、効率よく、かつ推論の精度を向上できる。

また、障害発見テストを自動化しようとした場合、被疑箇所を想定してアクションを実行するため、大規模環境では多くの個所からアラートが上がる場合に、全てのコンポーネントについてテストを行う必要があり、効率が悪い。すなわち、被疑箇所の特定がもうひとつの課題であり、本実施例はこの課題にも対応できる要素を含む。

＜処理の概要＞
図１は本実施例の全体フローの概要を示す図である。

まず、障害切り分けの処理を開始する。これは、オペレータの指示を契機にしてもよいし、所定時刻に自動的に行ってもよい（S101）。最初に所定のアクションを行い、イベントを収集し、当該イベントをルールに当てはめて、根本原因イベントを絞り込む（S102）。絞込み手法としては、確信度の上位３件のみの候補に絞り込む、確信度が50%以上の候補に限定して絞り込む、複数候補の確信度の差が30%を上回ったら、確信度が低い候補を根本原因から除外して絞り込む、などがある。

次に根本原因の絞り込みが完了したかどうかを判定する（S103）。判定条件は任意であるが、例えば、根本原因の確信度が99%を上回ったら完了とする。完了したら、結果を出力して終了する（S104）。

絞り込みが完了していない場合は、さらに絞込み処理を行うため、抽出したコンポーネントに関連して、どのような追加のアクションを行うかを判定するために、追加アクション判定シナリオを取得し（S107）、追加のアクションを判定する（S108）。そして、追加アクションを実行し、対応するイベントを収集する（S109）。

その後、処理（S102）に戻り、根本原因の絞り込みが完了するまで処理を繰り返す。

＜全体システム構成＞
図２は本実施例のシステム全体構成図である。本実施例では、管理サーバ200を用いて処理を実行する。監視対象201は、例えばネットワークシステムその他のシステムのコンポーネント(要素）である。先に述べたように物理的なものでも仮想的なものでもよい。また粒度も、装置単位（例えばサーバ装置）、装置に実装されるボード単位、ボード内の回路単位等任意である。

管理サーバは、通常のサーバ登用に、入力装置、出力装置、処理装置（ＣＰＵ），記憶装置等の要素を有する。管理サーバは、後に内容を詳細に説明する分析完了判定部202、追加アクション判定部203、追加アクション実行部204、障害分析結果出力部205、障害多段分析管理部206、障害監視部207、障害原因分析部208、障害詳細情報収集部209を備える。

これらの部分は、記憶装置に格納されたプログラムがプロセッサによって実行されることで、定められた処理を他のハードウェアと協働して行うことができる。本明細書では計算機などが実行するプログラムまたはその機能を実現する手段を、「機能」、「手段」、「部」、「モジュール」等と呼ぶ場合がある。

また、管理サーバは、分析完了判定基準210、追加アクション判定シナリオ211、追加アクション実行シナリオ212、コンポーネント管理テーブル213、障害原因分析ルール214、障害詳細情報215の情報を利用可能である。

以後の説明では「〜テーブル」、「〜リスト」、「〜ＤＢ（Ｄａｔａｂａｓｅ）」、「〜キュー」「表」等の表現にて本実施例で使用する情報を説明する場合があるが、これら情報はテーブル、リスト、ＤＢ、キュー、等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「〜テーブル」、「〜リスト」、「〜ＤＢ」、「〜キュー」等について「〜情報」と呼ぶことがある。また、実施例で例示される上記テーブル類は、必ずしも１つのファイルである必要はなく、識別子で関連付けされた複数のテーブルでもよい。あるいは、複数のテーブルが合体した1つのテーブルでもよい。

また、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ（ＩＤｅｎｔｉｆｉｃａｔｉｏｎ）」という表現を用いるが、これらについてはお互いに置換が可能である。

また、以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信制御デバイス）を用いながら行うため、プロセッサを主語とした説明とする場合がある。また、プログラムを主語として開示された処理は管理サーバ等の計算機、情報処理装置が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。

また、各種プログラムは、プログラム配布サーバや、計算機が読み取り可能な記憶メディアによって各計算機にインストールされてもよい。この場合、プログラム配布サーバは、プロセッサと記憶資源を含み、記憶資源はさらに配布プログラムと配布対象であるプログラムを記憶する。そして、配布プログラムをプロセッサが実行することで、プログラム配布サーバのプロセッサは、配布対象のプログラムを他の計算機に配布する。

また、入力装置や出力装置の例としてはディスプレイとキーボードとポインタデバイスが考えられるが、これ以外のデバイスであってもよい。また、入出力デバイスの代替としてシリアルインタフェースやイーサーネットインタフェースを入出力デバイスとし、当該インタフェースにディスプレイ又はキーボード又はポインタデバイスを有する表示用計算機を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力デバイスでの入力及び表示を代替してもよい。

＜適用イメージ＞
図３は本実施例の具体的な適用例を説明する図である。図３では適用例として、サーバ301および複数のクライアント303が対向し、それらの中継ノードとしてルータ302が介在するシステムを想定し、本発明を適用した例について説明する。

各ノード間には双方向の線路305（例えば２線式光ファイバなど）を想定している。線路305からの信号はトランシーバ304で送受信の終端を行う。この実施例では、サーバ301からクライアント１、クライアント２への通信は、例えばICMP pingプロトコルなどの接続確認信号306を定期的に配信し、接続確認を実施することを前提とする。またルーター302クライアント303間では、定期的には接続信号確認を行っていないことを前提とする。以下の説明では、この例で具体的な障害原因の切り分けを考える。

＜根本原因イベント一覧＞
図４は、図３の構成例のトポロジーにおける根本原因イベント一覧400を示すチャートである。図３の例においては、通信障害を検討する場合に、コンポーネントとしてトランシーバ304の故障とLINKの断障害を想定し、各コンポーネントで発生する可能性のある障害を根本原因イベントとしている。合計18種類の根本原因イベントが想定される。TXXはトランシーバ根本原因イベント番号401、LXXはLINK断根本原因イベント番号401をあらわす。

＜障害原因分析ルール＞
図５Ａおよび図５Ｂは、トランシーバ故障についての障害原因分析ルール214を示すチャートである。

図６Ａおよび図６Ｂは、ＬＩＮＫ断についての障害原因分析ルール214を示すチャートである。

この情報は、図4に示した根本原因イベント毎に、それらの成立条件を列挙したものである。これら各成立条件は発生イベントに対応する。すなわち、全ての条件が成立すると、その想定故障が発生したと確定的にみなすことができる。図中「Ｃ−Ｔ１．１Ａ」等は根本原因発生条件番号501である。根本原因発生条件番号501では、「Ｃ−」はルールを表し、Ｃ−Ｔx.yはトランシーバ故障Ｔxのルールを、Ｃ−Ｌx.yはＬｉｎｋ断障害Ｌxのルールを表す。ｙは各ルールにおける判定優先度を表す。各ルールは、論理和（OR）、論理積（AND）で構成される。括弧内は等しい判定優先度で記載され、たとえば２項目から成る場合にはＣ−Ｔx.yＡ、Ｃ−Ｔx.Ｂなどと記載している。

＜障害イベント一覧＞
図7は、障害詳細情報収集部209で収集する、障害イベント一覧表700の例を示す表図である。この情報は、発生しうるイベントの一覧を示す。障害イベント番号701に対して、イベント内容702が対応している。イベントは主に障害情報であるが、切り分けのための追加アクションの結果で「異常警報なし」であるというイベントを発生する場合もある。イベント番号701の先頭「EV」はイベントを示し、異常なしのイベント番号には、添え字「ｐ」を付している。

＜障害イベント−根本原因発生条件対応マップ＞
図８Ａ〜図８Ｉは、障害原因分析部208が用いる、障害イベント−根本原因発生条件対応マップ800の例を示す表図である。このマップは、図４〜図7の情報を統合して自動または手動で生成することができる。

図８Ａ〜図８Ｉは一つの表を横方向に分割している。この情報は、発生した障害イベント(番号）701から根本原因発生条件番号501を抽出するためのテーブルであり、抽出される項目に「１」が格納されている。この図から明らかなように、１つの障害イベント701から、複数の根本原因発生条件番号501が抽出される場合もある。このことは、１つの障害イベントだけでは、障害の原因となる根本原因が１つに絞れない場合があることを意味する。

＜根本原因イベント番号−追加アクション対応表＞
図９Ａおよび図９Ｂは、追加アクション判定シナリオ211の一部である、根本原因イベント番号−追加アクション対応表900を示す表図である。この情報は、追加アクション判定部203において、根本原因イベント（推定された根本原因）番号401および絞込みレベル901から、更に絞込みを行うための追加アクション（追加アクション番号902および追加アクション内容903）を特定するための対応表である。絞込みレベル901の説明は後述する。

＜追加アクション一覧＞
図１０は、追加アクション実行シナリオ212の一部である、追加アクション一覧1000を示す表図である。この情報には、追加アクション番号902に対応して、具体的に実施するためのアクション内容903および実施方法1001を格納する。

＜追加アクション−障害イベント番号対応表＞
図１１Ａおよび図１１Ｂは、追加アクション実行シナリオ212の一部である、追加アクション番号902、追加アクション内容903とその結果としての障害イベント番号対応表を示す表図である。この情報は、追加アクションに対応して、それらを実行した結果得られた結果を、障害イベント番号1101、障害イベント内容1102として対応付ける表である。

＜障害原因切り分け処理＞
図１２Ａ〜図１２Ｂは本実施例の障害原因切り分けの流れの概要を示す図である。図１２Ａにおいて、図２〜図１１を適宜参照しつつ、最初の障害検出から絞込み完了判定までの流れと各テーブルの役割を説明する。

ここで示す例では、最初の障害検出は、図３の「サーバ−クライアント１間の接続確認信号P１」、または、「サーバ−クライアント２間の接続確認信号P２」と想定している。

図２の管理サーバの障害監視部207は、公知の手法により監視対象201の監視を行い、監視結果を収集しているものとする。収集された監視結果は、障害多段分析管理部206の制御により、障害詳細情報収集部209へ送られる。障害詳細情報収集部209は、障害イベント一覧表700(図７参照）により障害イベント番号701を特定し、障害多段分析管理部206へ報告する（S1201）。なお、障害多段分析管理部206は処理の全体を管理しており、各部（モジュール）の処理を順次実行しているが、以下の説明では障害多段分析管理部206の説明を省略することがある。

障害原因分析部208では、障害イベント番号701から、根本原因および確信度を抽出する。そのために、障害イベント−根本原因発生条件対応マップ800(図８参照）を参照して、発生した障害イベント701に対応する根本原因発生条件番号501を特定する（S1202）。

そして、障害原因分析ルール214（図５〜図６参照）を参照して、障害イベント−根本原因発生条件対応マップ800(図８参照）で抽出された、１つまたは複数の根本原因発生条件(番号）501が成立する根本原因イベント番号401を抽出し、確信度判定を行う（S1203）。根本原因が複数の可能性がある場合もあり、その場合の確信度は100%未満として算出される。

根本原因イベント番号401と確信度1205は、分析完了判定部202に送られる。分析完了判定部202は分析が完了か否かを判定する。判定内容の詳細な例は図１３で後述する。

図１２Ｂにおいて、分析完了判定部202で根本原因を絞り込み未完了と判定した後の流れと各テーブルの役割を説明する
分析完了判定部202での判定の結果、分析が未完了で継続する場合には、絞り込みパラメータ（処理中で用いるパラメータであり、後に追加アクション判定部203で図９の絞込みレベル901と照合する）をインクリメントし、追加アクション判定部203に絞り込みパラメータおよび根本原因イベント番号401を入力する。なお、分析完了時には、絞込みパラメータをリセットし、障害分析結果出力部205に根本原因イベント番号401と確信度1205を渡し、障害分析結果出力部205で、出力装置のユーザインタフェース（例えばCUIやGUI）に出力する。

追加アクション判定部203では、根本原因イベント番号−追加アクション対応表900(図９参照）を用いて、入力された根本原因イベント番号401および絞込みパラメータに該当する、追加アクション番号902を抽出する（S1205）。絞込みパラメータで絞込みレベル901を指定することで、全てのアクションを一度に実施せずに、絞込みを進めて、必要最小限のアクションを実施する効果がある。

また、例えば図９Ａに示すように、根本原因イベント番号Lｌ、絞込みレベル４では、追加アクション番号ＡＣ−ＴＮＳ１．３およびＡＣ−ＴＮＲ１Ａ．１の２種類が存在するが、このように同じ優先度で複数アクションが存在する場合には、いずれも実施すべき追加アクションとみなし、それらの追加アクション番号の全てを抽出する。

先に述べたように、絞込みパラメータは、障害多段分析管理部206が、ループ回数をパラメータとして管理する（例えば自然数１，２，３）。初期状態、分析完了時にはデフォルトにリセット（例えば１）する。絞込みパラメータは、分析完了判定部で根本原因を絞り込み未完了と判定した場合に、インクリメント（例えば、２，３と加算）され、追加アクション判定部203に入力される。

追加アクション実行部204では、追加アクション一覧1000（図１０参照）を参照し、追加アクション判定部203が抽出した追加アクション番号902に従って、追加アクション内容903を実行する（S1206）。

追加アクションの結果であるイベントは、第１回のアクションの場合と同様に、図２の管理サーバの障害監視部207により収集され、監視結果は、障害多段分析管理部206の制御により、追加アクション実行部204へ送られる。追加アクション実行部204は、追加アクション実行シナリオ212の一部である、追加アクション番号−障害イベント番号対応表1100(図１１Ａ，Ｂ参照）により障害イベント番号1101を特定する（S1207）。

追加アクション判定部203が複数の追加アクション番号902を指定した場合には、追加アクション実行部204は、それらを全て実施し、その結果としての障害イベント番号1107も複数を同時に出力する。この場合、これらのアクションが全て完了してから同時に出力することで、一部情報による誤分析を防止する。

障害イベント番号1101は障害原因分析部208に送られる。それ以降の障害原因分析部208、分析完了判定部202での処理は図１２Ａで説明したものと同様である。これらの処理は、障害多段分析管理部206が順次実行させる。

以上の処理をループ状に繰り返し、分析完了判定部202での判定の結果、分析が未完了で継続する場合には、絞り込みパラメータをインクリメントし、追加アクション判定部203に絞り込みパラメータおよび根本原因イベント番号401を入力し、次の追加アクションの処理を継続する。

分析完了判定部202での判定の結果、分析完了時の場合には絞込みパラメータをリセットし、障害分析結果出力部205に根本原因イベント番号401と確信度を送信し、処理を終了する。

＜分析終了判定処理＞
図１３は、分析完了判定部202における、分析終了判定処理（S1204）のフローの一例を示す流れ図である。この例では、まず、絞り込み実行判断基準として、確信度最上位の根本原因イベント候補に対して、確信度の差が10%未満の根本原因イベント候補があるかどうかを判定する（S1301）。存在する場合には、確信度最上位の根本原因イベント候補および確信度の差が10%未満の根本原因イベント候補を残し、他候補は削除し（S1302）、処理S1303に進む。存在しない場合には、そのまま処理S1303に進む。

処理S1303では、最上位の根本原因イベント候補と第二位の根本原因イベント候補の
確信度の差が30%以上かどうかを判定する。確信度の差が30%以上ない場合は、分析継続、追加アクション要としてS1204の処理を終了する（S1304）。処理S1302で確信度の差が10%未満の根本原因イベント候補を残し、他候補は削除した場合は、当然に追加アクション要となるが、処理S1302では確信度の低い候補を除去することができ、その後の処理を効率化できる。

確信度の差が30%以上ある場合は、最上位の根本原因イベント候補の確信度が50%を超過しているかどうかを判定する（S1305）。超過している場合には、十分の確度を持つ候補が残ったとして分析終了とし、S1204の処理を終了する（S1306）。超過していない場合には、分析継続、追加アクション要としてS1204の処理を終了する（S1304）。

なお、図１３で例示した数値は一例であり、システムの性質や用途により、適宜変更することができる。例えば、管理サーバ200の入力装置には、数値を設定変更可能なインタフェースを備え、オペレータの操作により変更することを可能にしてもよい。また、判定のフローも図１３の例に限られるものではなく、他の手法を用いてもよい。

図１４は、本実施例で想定する故障の判定実行例を示す。この例は、図３のトポロジー上での想定障害例として、リンク断の状態を示している。既に説明した本実施例の動作を、具体的な例をもとにして再度説明する。

＜絞込みレベル１＞
まず、絞込みレベル１（第１回のアクションおよびイベント）では、サーバ301でクライアント１からの接続確認信号P1（往復）により信号断を検出する。

この検出情報は管理サーバ200で検出され、障害詳細情報収集部209において、障害イベント一覧表700（図7）により「障害イベント＝ＥＶ−ＬＮＰ１．１」として特定される（図１２Ａの処理S1201)。

特定された障害イベント番号701は、障害原因分析部208に送られる。障害原因分析部208では、障害イベント−根本原因発生条件対応マップ800(図８）を参照し、「障害イベントＥＶ−ＬＮＰ１．１」に対応する「根本原因発生条件＝Ｃ−Ｌ１．１Ａ、Ｃ−Ｌ２．１Ａ、Ｃ−Ｌ３．１、Ｃ−Ｌ４．１、Ｃ−Ｔ１．１Ａ、Ｃ−Ｔ２．１Ａ、Ｃ−Ｔ３．１Ａ、Ｃ−Ｔ４．１Ａ、Ｃ−Ｔ５．１、Ｃ−Ｔ６．１、Ｃ−Ｔ９．１、Ｃ−Ｔ１０．１」（計１２条件）を抽出する（図１２Ａの処理S1202)。

障害原因分析部208ではさらに、障害原因分析ルール214を参照し、根本原因発生条件によって可能性のある「根本原因イベント＝Ｌ１、Ｌ２、Ｌ３、Ｌ４、Ｔ１、Ｔ２、Ｔ３、Ｔ４、Ｔ５、Ｔ６、Ｔ９、Ｔ１０」（計12根本原因）を抽出し、確信度を算出する（図１２Ａの処理S1203)。

確信度の算出例として、この例の場合、100%を確実（疑義なし）と考えた場合、これに対して１２の根本原因が存在しているため、各根本原因の確信度は１００／１２＝８．３％と計算する。その結果、図１２Ａの処理S1204に例えば図１３の処理条件を用いると、絞込み未完と判定し分析を継続する。

＜絞込みレベル２＞
次に、絞込みレベル２（第２回目のアクションおよびイベント）では、ルータ302とクライアント１間の信号断（往復信号）を検出する。絞込みレベル２に際しては、障害多段分析管理部206は、絞込みパラメータをインクリメントし、絞込みパラメータは「２」となる。

根本原因イベント番号401と絞込みパラメータ「２」は追加アクション判定部203に入力される。追加アクション判定部203では、根本原因イベント番号−追加アクション対応表900（図９）を参照し、根本原因イベント番号401から追加アクション番号902を特定する（図１２Ｂの処理S1205）。

根本原因イベント番号が、Ｌ１、Ｌ２、Ｌ３、Ｌ４、Ｔ１、Ｔ２、Ｔ３、Ｔ４、Ｔ５、Ｔ６、Ｔ９、Ｔ１０であり、絞込みレベル２の追加アクション番号を抽出すると、Ｌ１：ＡＣ−ＬＮＳ１．１ 、Ｌ２：ＡＣ−ＬＮＳ１．１ 、Ｌ３：ＡＣ−ＬＮＳ２．１ 、Ｌ４：ＡＣ−ＬＮＳ２．１ 、Ｔ１：ＡＣ−ＬＮＳ１．１ 、Ｔ２：ＡＣ−ＬＮＳ１．１ 、Ｔ３：ＡＣ−ＬＮＳ１．１ 、Ｔ４：ＡＣ−ＬＮＳ１．１ 、Ｔ５：ＡＣ−ＬＮＳ２．１ 、Ｔ６：ＡＣ−ＬＮＳ２．１ 、Ｔ９：ＡＣ−ＬＮＳ２．１ 、Ｔ１０：ＡＣ−ＬＮＳ２．１となる。

但し、同一アクション（ＡＣ−ＬＮＳ１．１およびＡＣ−ＬＮＳ２．１）を重複指定しているため、ＡＣ−ＬＮＳ１．１およびＡＣ−ＬＮＳ２．１の２種類を実行指示する。この様に、複数根本原因イベントが複数アクションを指定した場合には、同一のアクションを複数回実行指示せず、必要最低限のアクションを実行指示すればよい。

追加アクション実行部204は、実行指示された追加アクションを実行する（図１２Ｂの処理S1206）。追加アクション実行部204は、追加アクション一覧1000(図１０）を、追加アクション番号902をキーに検索し、該当する追加アクション内容903をその実施方法1001に従って実行する。この例によると、追加アクション番号は「ＡＣ−ＬＮＳ１．１（サーバールータ間の接続確認(往復)）」および「ＡＣ−ＬＮＳ２．１（ルータ−クライアント１間の接続確認（往復信号））」であり、これらを実行する。具体的な実行方法は公知の技術による。

追加アクションの結果からの障害イベントを、追加アクション番号−障害イベント番号対応表1100(図１１Ａ，Ｂ）により特定する。この例では、追加アクション「ＡＣ−ＬＮＳ１．１」の結果は疎通あり（ＥＶ−ＬＮＳ１．１ｐ）、「ＡＣ−ＬＮＳ２．１」の結果は疎通断（ＥＶ−ＬＮＳ２．１）であった（図１２Ｂの処理S1207）。

そこで、障害イベント番号1101は障害要因分析部208に送られ、障害原因分析部208では、障害イベント−根本原因発生条件対応マップ800(図８）を参照し、「障害イベントＥＶ−ＬＮＳ１．１ｐに対応する根本原因発生条件＝なし」、「ＥＶ−ＬＮＳ２．１に対応する根本原因発生条件＝Ｃ−Ｌ３．２ 、Ｃ−Ｌ４．２ 、Ｃ−Ｔ１０．２、 Ｃ−Ｔ５．２、 Ｃ−Ｔ６．２、 Ｃ−Ｔ９．２ （計６条件）」を特定する（図１２Ｂの処理S1202）。

障害要因分析部208ではさらに、根本原因発生条件によって可能性のある「根本原因イベント＝Ｌ３、Ｌ４、Ｔ５、Ｔ６、Ｔ９、Ｔ１０（計６根本原因）を抽出し、確信度を算出する（図１２Ａの処理S1203)。

確信度の算出例として、100%を６で除し、根本原因＝１６．７％を得る（図１２Ａの処理S1203)。その結果、絞込み未完と判定し分析継続（図１２Ａの処理S1204)。

＜絞込みレベル３＞
次に、絞込みレベル３では、ルータ→クライアント１方向の信号断を検出する。絞込みパラメータはインクリメントされ、絞込みパラメータ「３」となる。

根本原因イベントから追加アクションを特定する（図１２Ｂの処理S1205）。絞込みレベル２の結果である６条件に対応して、「Ｌ３：ＡＣ−ＬＮＳ２．２ 、Ｌ４：ＡＣ−ＬＮＳ２．３ 、Ｔ５：ＡＣ−ＬＮＳ２．２ 、Ｔ６：ＡＣ−ＬＮＳ２．３ 、Ｔ９：ＡＣ−ＬＮＳ２．３ 、Ｔ１０：ＡＣ−ＬＮＳ２．２」が抽出される。

但し、同一アクション（ＡＣ−ＬＮＳ２．２およびＡＣ−ＬＮＳ２．３）を重複指定しているため、ＡＣ−ＬＮＳ２．２およびＡＣ−ＬＮＳ２．３の２種類を実行指示する。この様に、複数根本原因イベントが複数アクションを指定した場合には、同一のアクションを複数回実行を指示せず、必要最低限のアクションを実行指示する。

追加アクションを実行する（図１２Ｂの処理S1206）。ここでは、「追加アクションＡＣ−ＬＮＳ２．２（ルータ→クライアント１方向の接続確認信号発生（片道信号））」および「ＡＣ−ＬＮＳ２．３（ルータ←クライアント１方向の接続確認信号発生（片道信号））」を実行する。

追加アクションの結果からの障害イベントを判定する（図１２Ｂの処理S1207）。追加アクションの結果、「ＡＣ−ＬＮＳ２．２は疎通なし（ＥＶ−ＬＮＳ２．２）」、「ＡＣ−ＬＮＳ２．３は疎通あり（ＥＶ−ＬＮＳ２．３ｐ）」であった。

障害イベントに対応する根本原因発生条件を抽出する（図１２Ｂの処理S1202）。「障害イベントＥＶ−ＬＮＳ２．２に対応する根本原因発生条件＝Ｃ−Ｌ３．３、Ｃ−Ｔ１０．３、Ｃ−Ｔ５．３（計３条件）」、また「障害イベントＥＶ−ＬＮＳ２．３ｐに対応する根本原因発生条件＝なし」である。

根本原因発生条件によって可能性のある「根本原因イベント＝Ｌ３、Ｔ５、Ｔ１０（計３根本原因）」を抽出する（図１２Ｂの処理S1203）。また、確信度の算出例として、100%を３で除し確信度＝３３．３％を得る。その結果、絞込み未完と判定し分析継続（図１２Ｂの処理S1204）。

＜絞込みレベル４＞
次に絞込み絞込みレベル４では、ルータ、クライアント１の装置情報を取得する。その結果、装置異常ではないため、ルータ→クライアント１方向のリンク断と判定する。絞込みパラメータをインクリメントし、絞込みパラメータは「４」となる。

根本原因イベントから追加アクションを特定する（図１２Ｂの処理S1205）。「Ｌ３：ＡＣ−ＴＮＲ１Ｚ．２」および「ＡＣ−ＴＮＣ１．１ 、Ｔ５：ＡＣ−ＴＮＲ１Ｚ．２ 、Ｔ１０：ＡＣ−ＴＮＣ１．１」が抽出される。

但し、同一アクション（ＡＣ−ＴＮＲ１Ｚ．２およびＡＣ−ＴＮＣ１．１）を重複指定しているため、ＡＣ−ＴＮＲ１Ｚ．２およびＡＣ−ＴＮＣ１．１の２種類を実行指示する。

追加アクション実行（図１２Ｂの処理S1206）では、「追加アクションＡＣ−ＴＮＲ１Ｚ．２（ルータ内トランシーバＲ１Ｚ送信部異常警報収集）」および「ＡＣ−ＴＮＣ１．１（クライアント１内トランシーバＣ１受信部異常警報収集）」を実行する。

結果からの障害イベントを判定する（図１２Ｂの処理S1207）追加アクションの結果、「ＡＣ−ＴＮＲ１Ｚ．２は異常なし（ＥＶ−ＴＮＲ１Ｚ．２ｐ）」、「ＡＣ−ＴＮＣ１．１は異常なし（ＥＶ−TNC１．１ｐ）」であった。

障害イベント−根本原因発生条件対応マップ800を参照し、障害イベントＥＶ−ＴＮＲ１Ｚ．２ｐに対応する「根本原因発生条件＝Ｃ−Ｌ３．４Ａ、」、ＥＶ−TNC１．１ｐに対応する「根本原因発生条件＝Ｃ−Ｌ３．４Ｂ」（計２条件）を得る（図１２Ｂの処理S1202）。

根本原因発生条件によって可能性のある根本原因イベントを抽出すると「根本原因にイベント＝Ｌ３（計１根本原因）」が抽出される。

これについての確信度は、100%を１で除して１００％を得る。その結果、絞込み完了（図１２Ｂの処理S1204）。

＜コンポーネント管理テーブル＞
図１５は、コンポーネント管理のための管理テーブル1500の実施例を示す表図である。各構成要素（コンポーネント）はコンポーネント管理テーブル1500で管理を行う。コンポーネント管理テーブル1500は、図１５のように複数のテーブルの集合であってもよいし、他の形式でもよい。例えば追加アクションにおいて、IPアドレスを使用する場合、装置情報を持つ場合に参照する。以下は今回の実施例に合わせて記載している一例である。コンポーネント管理テーブルは、例えば管理者が予め設定しておき管理サーバの記憶装置に格納する。

トランシーバでは、受信部、送信部各々にIDを付与しておく。具体的な例としては、障害情報格納領域の情報を取得し、障害状態の判定を行い、結果を出力する実行単位（モジュール、ライブラリなど）を指定する。

コンポーネントの粒度は任意であり、例えばサーバの下位にトランシーバが位置する。さらに大きな粒度としてもよいし、小さな粒度としてもよい。また、コンポーネントは物理的なものでもよいし、仮想的なものでもよい。

本発明の実施例では、適用するネットワークは仮想でも非仮想でも適用可能である。また、トポロジーの変化に対しては、図４〜図１１の各情報を修正することで、対応可能である。修正は、手動で行ってもよいし、自動的にこれらを更新することも可能である。

トポロジーの動的変化への対応について、実施例２として説明する。実施例２として、リンク接続関係を管理するリンク接続関係管理テーブルを設け、リンク接続関係管理テーブルから、図４〜図１１の各情報を自動的に更新する方法の実施例を示す。

図１６は、実施例２の処理全体の概要を示すフロー図である。図１と同様の構成は同じ符号を付して説明を省略する。実施例２ではトポロジー履歴を取得する処理を備えている（S1601）。トポロジーとはシステムを構成するコンポーネント(要素）の関係を示す情報である。トポロジー履歴とは、トポロジーが動的に変化する場合には、その変化の履歴を含む情報である。図１６の例では、トポロジーが動的に変化する例とし、その時点で入手できる最新のトポロジーを利用するものとする。なお、コンポーネントは、物理的なもの（物理サーバ）でもよいし、仮想的なもの（物理サーバ上の仮想サーバ）でもよい。コンポーネント間の関係も、物理的なものであってもよいし、仮想的（論理的）なものであってもよい。

このようなトポロジー情報は、通常システムの管理に必要であり、管理サーバが自動的に収集する技術は知られている。

実施例２では、トポロジーを取得し（S1601）、これから、根本原因分析に関連するコンポーネントを抽出する（S1602）を含み、これに基づいて処理S102以降の処理を行う。

図１７は、実施例２のシステムの全体構成図である。図２と同様の構成は同じ符号をつけて説明を省略する。実施例２のシステムの管理サーバ200Bは、関連コンポーネント抽出部1701、アクション選択部1702、アクション実行部1703を有する。これらはソフトウェアで構成することができる。また、情報としてリンク接続関係管理テーブル1704、トポロジー履歴1705、アクションテーブル1706を備える。

図１８は、ネットワークトポロジーにおける接続関係を把握する概念の一例を示す図である。各ノードＡ，Ｂ，Ｃ間の接続（リンクと称する）の集合と考えることにより、複数リンクを含むリンクの定義も可能である。この図の例では、リンクｐ、リンクｑの上位リンクはリンクｒと考える。

また、障害切り分けへの活用を容易にするために、各々方向を区別し、また便宜的に往復経路も区別して管理する。すなわちＡ、Ｂ間のリンクでは、Ａ→Ｂ、Ｂ→Ａ、Ａ-Ｂ往復の３種類のリンクが存在するものとして管理する。

更に、経路上に存在する物理ポート、トランシーバを管理する。下位リンクが存在する場合には管理は不要とする。リンク接続関係管理テーブル1704では、これらの各々リンクと包含関係を管理する。

図１９は、リンク接続関係管理テーブル1704の例を示す表図である。トポロジー変更に対応するために、まず、ネットワークリンクの接続関係をリンク接続関係管理テーブルで管理しておく。

リンクは始点1901と終点1902の情報を持つ。関係性ＩＤ1903は、接続確認方法1907をアクションとした場合に得られる障害イベント(番号）701との関連性を示す。上位リンクがある場合は、上位リンク情報1904を持つ。また方向情報1905は、片方向と双方向の別を示す情報を有する。自リンクの経路上に物理ポートが存在する場合には、物理ポート情報1906として格納する。また、接続確認方法1907の情報を有する。

実施の具体例として、クライアント３が追加された場合を説明する。

図２０は図３の構成に対して、クライアント３が追加された状態を示している。クライアント３はトランシーバC3を内蔵しており、ルータのトランシーバR3Zと通信を行う。

管理サーバ201から各クライアント303へは、例えばICMP pingプロトコルなどの接続確認信号を定期的に配信し接続確認を実施することを前提としており、このため、クライアント３が追加された場合、管理サーバはこれを知ることができる。実施例２では、収集した情報をトポロジー履歴1705として管理サーバ200Bが利用可能である。

図２１は、クライアント３が追加された結果を、図１５のコンポーネント管理テーブル1500に反映した結果である。クライアント３のテーブル(f)、および、クライアント３が備えるトランシーバＣ３と、ルータ側のトランシーバＲ３Ｚのテーブル(e)が追加される。また、ルータのテーブル(d)には、実装トランシーバＲ３Ｚが追加される。

このように、実施例３では、図１７のコンポーネント管理テーブル213（1500）は、コンポーネント（構成要素）の追加・変更に対して、外部から取り込んだトポロジー情報を反映することができる。コンポーネント管理テーブル1500の実装方法としては、予め表形式でコンポーネント管理テーブル1500を記載することができる。あるいは、他データベースを参照してフォーマット変換を行う、あるいはコンポーネントを自動的に把握する手段と併せて、その結果を図１５や図２１の形式に変換する方法が考えられる。

図２２は、図２１のように追加クライアント３が追加された結果、追加・変更されるリンク接続関係管理テーブル1704を示す。下線部は図１９の状態（追加前）と比較した変更箇所である。これらの追加は、手動で行ってもよいが、上述のように、外部から取り込む情報を基に、予めこの表の形式でトポロジー構成を記載するか、他データベースを参照してフォーマット変換を自動的に行ってもよい。あるいはトポロジーを自動的に把握する手段と併せて、その結果を本表の形式に変換する方法が考えられる。

図２３で、追加・変更されるリンク接続関係管理テーブル1704を、図４〜図１１の各情報に反映する方法を説明する。

障害イベント一覧表700（図７）に対しては、新規追加された関係性IDの冒頭に”EV-”を付与して追加する。この例では、「EV-LNS4.3」が障害イベント一覧表700に追加される。追加部分の接続確認方法の例としては、接続確認を実行し、結果を出力する実行単位（モジュール、ライブラリなど）を指定してもよい。

障害原因分析ルール214(図５〜図６）に対しては、予め障害原因分析ルールテンプレート2301を準備しておき、これにリンクの特性を当てはめる。テンプレート2301の例として、図２３にはLINK障害テンプレートを挙げる。最上位リンクは根本原因としないことを前提として、このテンプレートは最上位リンクを定義しない。

テンプレート2301は、障害原因分析ルール214を一般化したものであるが、根本原因に対して条件がレベル順にAND条件で接続されている。このレベルは絞込みに対応しており、租から密へと配置することにより、これを順番に実行することで絞込みが可能となる。

障害原因分析ルール214(図５、図６）に対しては、図２３の例では、このテンプレート2301を用いて、根本原因として関係性ID「LNS4.3」を使用する。関係性IDは片方向毎に独立に定義しているため、関係性IDを根本原因として使用が可能である。

レベル１は、”上位リンク”欄で１つなので、１条件「Ｃ−LNS4.3.1A」を指定する（Ｃは条件（クライテリア）の略）。レベル２は、自リンクの往復接続確認として１条件「Ｃ−LNS4.3.2」を指定する。レベル３は、自リンクの片方向道接続確認として１条件「Ｃ−LNS4.3.3」を指定する。レベル４は、”線路上に存在する物理ポート”の数として２条件「（Ｃ−LNS4.3.4A AND Ｃ− LNS4.3.4B ）」を記載する。もっとも、ここに示すテンプレートは一例であり、さらに階層を深くしてレベル５以上を設けてもよいし、レベルを減らすことも可能である。

以上のように障害原因分析ルール214を追加し、これに基づいて、障害イベント−根本原因発生条件対応マップ800（図８）にデータを追加する。

障害イベント−根本原因発生条件対応マップ800（図８）では、レベル１の条件「Ｃ−LNS4.3.1A」に対しては、上位リンク「LNP3.3」の障害である「EV-LNP3.3.1」を指定する。レベル2の条件「Ｃ−LNS4.3.2」に対しては、自リンクの往復接続確認（サフィックス1）「EV-LNS4.1」を指定する。レベル３「Ｃ−LNS4.3.3」の条件は、自リンクの片方向道接続確認であり、サフィックスは関係性IDと同一の「3」を指定し、「EV-LNS4.3」となる。レベル４「LNS4.3.4A」「LNS4.3.4B」は、「線路上に存在する物理ポート”の異常なし（最後の文字=p）」を指定し、「EV-TNR3Z.1p」「EV-TNC3.2p」となる。

次に、根本原因イベント番号−追加アクション対応表900を障害イベント−根本原因発生条件対応マップ800から追加生成する。障害イベント−根本原因発生条件対応マップ800のEVをACとし、下記の様に変換する。
Ｃ−LNS4.3.1A＝EV-LNP3.3.1→レベル１は不要
Ｃ−LNS4.3.2＝EV-LNS4.1→レベル２ AC- LNS4.1
Ｃ−LNS4.3.3＝EV-LNS4.3 →レベル２ AC-LNS4.3
Ｃ−LNS4.3.4A＝EV-TNR3Z.1p →レベル４ AC-TNR3Z.1
Ｃ−LNS4.3.4B＝EV-TNC3.2p →レベル４ AC-TNC3.2
また、これに対応して、追加アクション一覧表1000には、追加アクション番号、追加アクション内容、その実施方法を定義する。新規追加された接続確認方法を、”AC-”(関係性ID)=AC-LNS4.3として登録する。また、結果を成功はEV-LNS4.3ｐ、失敗をEV-LNS4.3とする。

以上説明したように、関連コンポーネント抽出部1701は、トポロジー履歴1705から、
根本原因イベント一覧(図４）、障害原因分析ルール(図５、図６）、障害イベント一覧（図７）、障害イベント−根本原因発生条件対応マップ(図８）、根本原因イベント番号−追加アクション対応表（図９）、追加アクション一覧（図１０）、追加アクションと障害イベント番号対応表（図１１Ａ）を生成・変更する。障害原因分析ルール214以外は、アクションテーブル1706の一部とする。アクション選択部1702、アクション実行部1703は、アクションテーブ1706の情報を利用して、アクションを選択、実行するが、この処理は実施例２と同様でよい。

以上の説明と同様にトランシーバ故障についても、トランシーバ故障テンプレートを定義し、各トランシーバのコンポーネント管理テーブルから、根本原因イベント一覧(図４）、障害原因分析ルール(図５、図６）、障害イベント一覧（図７）、障害イベント−根本原因発生条件対応マップ(図８）、根本原因イベント番号−追加アクション対応表（図９）、追加アクション一覧（図１０）、追加アクションと障害イベント番号対応表（図１１Ａ）を生成することが可能である。

実施例３は上記実施例１〜２をベースに、レベル学習処理を取り入れた例を説明する。この例では、分析完了判定部202で分析完了判定した場合に、絞り込んだ根本原因イベント番号と絞込みレベルを記憶し、その出現頻度を集計する。頻度の高いレベルは絞込みレベルを昇格させ、上位の絞り込みレベル（小さい番号の絞込みレベル）として追加アクションを実行する。

図２３は、実施例３における根本原因イベント番号−追加アクション対応表900の構成を、実施例１（図９）の者と比較して示した表図である。上側のテーブルが実施例１の構成、下側のテーブルが実施例３の構成である。

実施例３の下側のテーブルの右端に「出現頻度」欄が追加されており、この欄は分析完了判定部202で分析完了した時点で更新する。図２３の例では、この欄に「高頻度」フラグが格納されている。「高頻度」の定義は任意であるが、例えば出現頻度が50％以上であった場合、高頻度と判定する。

この高頻度フラグが付された根本原因イベント番号に対応する追加アクションでは、絞込みレベルを格上げする処理を行う。例えば、出現頻度が高頻度と判断された場合には、レベル３であっても、レベル２のループ処理において、AC-LNS1.2も実行し、AC-LNS1.2に対応した結果イベントが発生することで、頻度の高い障害に対する判定の優先順位を上げることができる。これにより、絞り込み判定が早まることが期待できる。

なお、出現頻度を反映するために、出現頻度をさらにレベル分けし、絞込みレベルに対して段階的に重み付をすることも可能である。

以上の構成は、単体のコンピュータで構成してもよいし、あるいは、入力装置、出力装置、処理装置、記憶装置の任意の部分が、ネットワークで接続された他のコンピュータで構成されてもよい。発明の思想としては等価であり、変わるところがない。

本実施例中、ソフトウエアで構成した機能と同等の機能は、FPGA（Field Programmable Gate Array）、ASIC（Application Specific Integrated Circuit）などのハードウエアでも実現できる。そのような態様も本願発明の範囲に含まれる。

本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることが可能である。また、各実施例の構成の一部について、他の実施例の構成の追加・削除・置換をすることが可能である。

各種システムの障害原因特定の分野に利用可能である。

管理サーバ200、監視対象201、分析完了判定部202、追加アクション判定部203、追加アクション実行部204、障害分析結果出力部205、障害多段分析管理部206、障害監視部207、障害原因分析部208、障害詳細情報収集部209、分析完了判定基準210、追加アクション判定シナリオ211、追加アクション実行シナリオ212、コンポーネント管理テーブル213、障害原因分析ルール214、障害詳細情報215

Claims (15)

1. 監視対象に対して、可能性のある障害を根本原因イベントとして抽出する障害切り分け方法であって、
   前記監視対象に対して、所定の動作を指示するアクションを実行し、前記アクションの結果として得られる障害イベントを収集する、アクション実行ステップと、
   前記障害イベントに基づいて、前記監視対象に対して、所定の動作を指示する追加のアクションを実行し、前記追加のアクションの結果として得られる追加の障害イベントを収集する追加アクション実行ステップと、
   前記追加の障害イベントを、予め定められた障害原因分析ルールに基づいて分析し、前記根本原因イベントおよびその確信度を判定する障害原因分析ステップと、
   前記根本原因イベントおよびその確信度に基づいて、分析完了判定を行う分析完了判定ステップ、を備える、
   障害切り分け方法。
2. 前記分析完了判定ステップにおいて、前記確信度が所定要件を満たさない場合、
   前記追加アクション実行ステップと、前記障害原因分析ステップと、前記分析完了判定ステップを再度実行する、
   請求項１記載の障害切り分け方法。
3. 前記追加アクション実行ステップの前に、追加アクション判定ステップを備え、
   前記追加アクション判定ステップは、
   前記障害イベントに基づいて、予めレベル分けされて準備された追加のアクションのうちから、前記追加アクション実行ステップと、前記障害原因分析ステップと、前記分析完了判定ステップの実行回数に応じたレベルのアクションから、実行すべき追加のアクションを判定する、
   請求項２記載の障害切り分け方法。
4. 前記障害原因分析ルールは、
   前記根本原因イベントに対応して、根本原因発生成立条件を列挙した情報であり、
   前記障害原因分析ステップは、
   前記障害イベントと前記根本原因発生成立条件の対応を示した、障害イベント−根本原因発生条件対応マップを用いて、前記追加の障害イベントにより、前記根本原因発生成立条件を抽出し、
   抽出された前記根本原因発生成立条件と前記障害原因分析ルールに基づいて、前記根本原因イベントおよびその確信度を判定する、
   請求項３記載の障害切り分け方法。
5. 前記追加アクション判定ステップは、
   前記根本原因イベントと前記追加のアクションを対応付けた根本原因イベント番号−追加アクション対応表を用い、
   前記障害原因分析ステップで判定された前記根本原因イベントに対応する、追加のアクションを判定する、
   請求項４記載の障害切り分け方法。
6. 前記分析完了判定ステップは、
   前記障害原因分析ステップで判定された前記根本原因イベントの、最上位候補と次点候補の確信度の差が所定要件を満たしているか否か、および、最上位候補の確信度が所定要件を満たしているか否か、の少なくとも一つの要件を用いて、前記分析完了判定を行う、
   請求項５記載の障害切り分け方法。
7. 前記分析完了判定ステップは、
   前記障害原因分析ステップで判定された前記根本原因イベントの、最上位候補と他の候補の確信度の差が所定閾値未満の場合、前記最上位候補との確信度の差が前記所定閾値未満の候補を残し、他の候補を削除する、
   請求項５記載の障害切り分け方法。
8. 前記根本原因イベント番号−追加アクション対応表は、出現頻度情報を有し、
   前記出現頻度情報には、前記分析完了判定ステップで分析完了判定した際に、絞り込んだ前記根本原因イベントの出現頻度に対応した情報を格納し、
   前記追加アクション判定ステップでは、
   前記出現頻度情報を用いて追加のアクションを判定する、
   請求項５記載の障害切り分け方法。
9. 前記監視対象間の関係を示す情報であるトポロジー情報を取得し、
   前記トポロジー情報に基づいて、前記障害原因分析ルール、前記障害イベント−根本原因発生条件対応マップ、および、前記根本原因イベント番号−追加アクション対応表を、追加または修正する、
   請求項５記載の障害切り分け方法。
10. 監視対象に対して、可能性のある障害を根本原因イベントとして抽出する障害切り分け方法であって、
    前記監視対象に対して所定のアクションを行い、前記アクションの結果である障害イベントを収集し、当該障害イベントを障害原因分析ルールに当てはめて、前記根本原因イベントを確信度とともに絞り込む第１のステップ、
    前記第1のステップの結果、絞り込まれた前記根本原因イベントおよび前記確信度が、所定の要件を満たし絞り込みが完了したかどうかを判定する第２のステップ、
    前記第２のステップの結果、絞り込みが完了していない場合、前記監視対象に対して所定の追加のアクションを行い、前記追加のアクションの結果である追加の障害イベントを収集し、当該追加の障害イベントを前記障害原因分析ルールに当てはめて、前記根本原因イベントを確信度とともに絞り込む第３のステップ、を備え、
    前記第３のステップを前記第1のステップとして、前記第２のステップに回帰させ、前記絞り込みが完了するまで、処理を継続する、
    障害切り分け方法。
11. 監視対象に対して、可能性のある障害を根本原因イベントとして抽出する障害切り分けを行う管理サーバであって、
    前記監視対象に対して、所定の動作を指示するアクションを実行し、前記アクションの結果として得られる障害イベントを収集する、アクション実行モジュールと、
    前記障害イベントに基づいて、前記監視対象に対して、所定の動作を指示する追加のアクションを実行し、前記追加のアクションの結果として得られる追加の障害イベントを収集する追加アクション実行モジュールと、
    前記追加の障害イベントを、予め定められた障害原因分析ルールに基づいて分析し、前記根本原因イベントおよびその確信度を判定する障害原因分析モジュールと、
    前記根本原因イベントおよびその確信度に基づいて、分析完了判定を行う分析完了判定モジュール、を備える、
    障害切り分けを行う管理サーバ。
12. 前記分析完了判定モジュールにおいて、前記確信度が所定要件を満たさない場合、
    前記追加アクション実行モジュールと、前記障害原因分析モジュールと、前記分析完了判定モジュールによる処理を再度実行する、
    請求項１１記載の障害切り分けを行う管理サーバ。
13. 追加アクション判定モジュールを備え、
    前記追加アクション判定モジュールは、
    前記障害イベントに基づいて、予めレベル分けされて準備された追加のアクションのうちから、前記追加アクション実行モジュールによる処理と、前記障害原因分析モジュールによる処理と、前記分析完了判定モジュールによる処理の実行回数に応じたレベルのアクションから、実行すべき追加のアクションを判定する、
    請求項１２記載の障害切り分けを行う管理サーバ。
14. 前記障害原因分析ルールは、
    前記根本原因イベントに対応して、根本原因発生成立条件を列挙した情報であり、
    前記障害原因分析モジュールは、
    前記障害イベントと前記根本原因発生成立条件の対応を示した、障害イベント−根本原因発生条件対応マップを用いて、前記追加の障害イベントにより、前記根本原因発生成立条件を抽出し、
    抽出された前記根本原因発生成立条件と前記障害原因分析ルールに基づいて、前記根本原因イベントおよびその確信度を判定する、
    請求項１３記載の障害切り分けを行う管理サーバ。
15. 前記追加アクション判定モジュールは、
    前記根本原因イベントと前記追加のアクションを対応付けた根本原因イベント番号−追加アクション対応表を用い、
    前記障害原因分析モジュールで判定された前記根本原因イベントに対応する、追加のアクションを判定する、
    請求項１４記載の障害切り分けを行う管理サーバ。

Images