JP6378653B2 - サービス影響原因推定装置、サービス影響原因推定プログラム、及びサービス影響原因推定方法 - Google Patents

Description

本発明は、サービス影響原因推定装置、サービス影響原因推定プログラム、及びサービス影響原因推定方法に関する。

通信ネットワークを介してサービスを提供するのに際して、通信ネットワーク中の故障又は品質劣化が発生している箇所を推定する技術が知られている。

特許文献１には、ユーザからの通信ネットワーク上でのトラブル発生の申告を契機に、利用端末と情報ソース（サーバに相当）の間に配置される複数のサービス構成要素（物理的な設備）からなる設備モデルを生成し、全サービス構成要素が正常な場合の通信シーケンスと、サービス構成要素それぞれが故障した場合の通信シーケンスとを生成し、これらの通信シーケンスと故障申告時における観測情報とを比較することで、故障したサービス構成要素を推定する技術について開示されている（詳細は「第１の比較例」として後述）。

また、通信ネットワーク上の装置間のパケットをキャプチャし、キャプチャしたパケットを解析することで、ユーザの体感品質に影響を与える種々の特性値（リオーダ幅、トラヒック流量、ＲＴＴ（Round-Trip Time）、パケットロス、ジッタ、セッション確立率、ウィンドウサイズ、サーバの応答時間）を算出し、その算出した値に基づいて当該特性値の正常性の判定を行い、前記装置間の通信品質劣化の原因箇所を推定する技術も知られている（詳細は「第２の比較例」として後述）。

さらに、非特許文献１には、仮想化された通信ネットワーク機能の選択的利用を可能とする柔軟な経路制御技術であるＳＦＣ（Service Function Chaining）技術を用いて、各フローに対し試験パケットを送信し、当該試験パケットが通過した転送機能部（物理／仮想ルータ又は物理／仮想スイッチに相当）及びアプリケーションのＩＤを、試験パケットが備えるリストにそれぞれ格納し、そのＩＤが格納されたリストと事前に設定した情報とを比較することで故障箇所を推定する技術について開示されている（詳細は「第３の比較例」として後述）。

しかしながら、前記第１〜第３の比較例の技術では、仮想化設備やアプリケーションソフトといったソフトウェアに故障や劣化が生じていても異常を検出できないこと（特許文献１）、ＩＤを付与できない設備に対しては故障診断ができないこと（非特許文献１）、作業が煩雑になること、装置規模が大規模になること、サービス品質の劣化が生じている場合に原因箇所の推定をすることができないこと等の不具合点が存在する。

これに対し、特許文献２には、分岐と端末とで構成されるツリー型のネットワークトポロジにおいて、ある分岐からツリー先端へ向かう全ての仮想側端末の故障が検出された場合に、当該分岐部分が故障箇所であると推定する技術について開示されている。

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

Y. Jiang他、"Fault Management in Service Function Chaining"、[online]、２０１４年１０月２７日、The Internet Engineering Task Force、[平成２７年１月２７日検索]、インターネット<URL：https://datatracker.ietf.org/doc/draft-jxc-sfc-fm/?include_text=1>

しかし、特許文献２に記載の技術では、故障箇所の推定がツリー型のネットワーク構成であることに依存しており、汎用性がない。

また、通信ネットワーク上でデータが受け渡しされる物理設備及びソフトウェアをサービス構成要素として、一以上のサービス構成要素を用いて構成される複数のフローが正常フローであるか異常フローであるかを判定した際に、サービス影響の原因の可能性がある故障被疑箇所が、異常フロー内に複数含まれる場合がある。
しかし、二以上の故障被疑箇所のうち、どれが実際に故障している可能性がより高いのかが分からないため、例えば故障被疑箇所であるサービス構成要素のＩＤ順等で検索順序を決めることとなり、故障箇所の検索及び特定のため作業を効率化することができない。

本発明は、前記事情に鑑みて創案されたものであり、サービス影響のある異常フローが二以上の故障被疑箇所を備える場合に、二以上の故障被疑箇所間での優先度付けを好適に行うことが可能なサービス影響原因推定装置、サービス影響原因推定プログラム、及びサービス影響原因推定方法を提供することを目的とする。

前記目的を達成するために、本発明のサービス影響原因推定装置は、通信ネットワーク上でデータが受け渡しされる物理設備及びソフトウェアをサービス構成要素として、一以上の前記サービス構成要素を用いて構成される複数のフローに対して試験パケットを前記フローごとに送信するパケット送信部と、前記フローを通過する前記試験パケットのリプライパケットを受信するパケット受信部と、受信した前記リプライパケットに基づいて、前記フローが正常フローであるか異常フローであるかを判定するグループ構成部と、前記異常フローにおいて前記ネットワーク上でのサービス影響の原因となる故障被疑箇所を推定する故障被疑箇所推定部と、を備え、前記故障被疑箇所推定部は、前回の前記試験パケットに関して、前記異常フローに共通する前記サービス構成要素を前記故障被疑箇所と推定し、前回の前記試験パケットに関して、前記故障被疑箇所と推定された前記サービス構成要素が二以上存在するとともに、今回の前記試験パケットに関して、新たに異常フローと判定された前記フローにおいて、前回の前記試験パケットにおいて前記故障被疑箇所と推定された一以上の前記サービス構成要素が含まれる場合に、前回の前記試験パケットにおける異常フローにおける前記故障被疑箇所の最前方位置である前回最前方位置と、今回の前記試験パケットにおける新たな異常フローにおける前記故障被疑箇所の最前方位置である今回最前方位置と、を前記故障被疑箇所ごとに比較し、前記今回最前方位置が前記前回最前方位置よりも前方となる前記故障被疑箇所の故障被疑度を、前記今回最前方位置が前記前回最前方位置と同じ位置又は前記今回最前方位置が前記前回最前方位置よりも後方となる前記故障被疑箇所の故障被疑度よりも高く設定することを特徴とする。

かかる構成によると、前回の試験パケットによる異常フローに二以上の故障被疑箇所があり、かつ、今回の試験パケットで前回の故障被疑箇所を含む新たな異常フローが発生した場合に、故障被疑箇所の最前方位置に応じて故障被疑度を設定するので、二以上の故障被疑箇所間での優先度付けすなわち故障被疑度の設定を好適に行うことができる。

前記故障被疑箇所推定部は、前記サービス構成要素間のリンクの長さに基づいて、前記前回最前方位置と前記今回最前方位置とを比較することが望ましい。また、前記故障被疑箇所推定部は、前記試験パケットの各回における前記フローごとの送信時刻の差分に基づいて、前記前回最前方位置と前記今回最前方位置とを比較することが望ましい。

かかる構成によると、異常フローのリンク長及び／又は試験パケットの送信時刻の差分を考慮して故障被疑箇所の最前方位置を抽出するので、故障被疑度の設定をより好適に行うことができる。

前記故障被疑箇所推定部は、今回の前記試験パケットに関して、新たに異常フローと判定された前記フローにおいて、前回の前記試験パケットにおいて前記故障被疑箇所と推定された前記サービス構成要素が一つのみ含まれる場合には、当該故障被疑箇所の故障被疑度を、前回の前記試験パケットにおいて前記故障被疑箇所と推定されて新たに異常フローと判定された前記フローには含まれない前記故障被疑箇所の故障被疑度よりも高く設定することが望ましい。

かかる構成によると、前回の試験パケットによる異常フローに二以上の故障被疑箇所があり、かつ、今回の試験パケットで前回の故障被疑箇所を含む新たな異常フローが発生した場合であって、今回の新たな異常フローに含まれる故障被疑箇所の故障被疑度を、今回の新たな異常フローには含まれない故障被疑箇所の故障被疑度よりも高く設定するので、二以上の故障被疑箇所間での優先度付けすなわち故障被疑度の設定を好適に行うことができる。

また、本発明のサービス影響原因推定プログラムは、コンピュータを、通信ネットワーク上でデータが受け渡しされる物理設備及びソフトウェアをサービス構成要素として、一以上の前記サービス構成要素を用いて構成される複数のフローに対して試験パケットを前記フローごとに送信するパケット送信部、前記フローを通過する前記試験パケットのリプライパケットを受信するパケット受信部、受信した前記リプライパケットに基づいて、前記フローが正常フローであるか異常フローであるかを判定するグループ構成部、及び、前記異常フローにおいて前記ネットワーク上でのサービス影響の原因となる故障被疑箇所を推定する故障被疑箇所推定部、として機能させ、前記故障被疑箇所推定部は、前回の前記試験パケットに関して、前記異常フローに共通する前記サービス構成要素を前記故障被疑箇所と推定し、前回の前記試験パケットに関して、前記故障被疑箇所と推定された前記サービス構成要素が二以上存在するとともに、今回の前記試験パケットに関して、新たに異常フローと判定された前記フローにおいて、前回の前記試験パケットにおいて前記故障被疑箇所と推定された一以上の前記サービス構成要素が含まれる場合に、前回の前記試験パケットにおける異常フローにおける前記故障被疑箇所の最前方位置である前回最前方位置と、今回の前記試験パケットにおける新たな異常フローにおける前記故障被疑箇所の最前方位置である今回最前方位置と、を前記故障被疑箇所ごとに比較し、前記今回最前方位置が前記前回最前方位置よりも前方となる前記故障被疑箇所の故障被疑度を、前記今回最前方位置が前記前回最前方位置と同じ位置又は前記今回最前方位置が前記前回最前方位置よりも後方となる前記故障被疑箇所の故障被疑度よりも高く設定することを特徴とする。

また、本発明のサービス影響原因推定方法は、通信ネットワーク上でデータが受け渡しされる物理設備及びソフトウェアをサービス構成要素として、一以上の前記サービス構成要素を用いて構成される複数のフローに対して試験パケットを前記フローごとに送信するパケット送信ステップと、前記フローを通過する前記試験パケットのリプライパケットを受信するパケット受信ステップと、受信した前記リプライパケットに基づいて、前記フローが正常フローであるか異常フローであるかを判定するグループ構成ステップと、前記異常フローにおいて前記ネットワーク上でのサービス影響の原因となる故障被疑箇所を推定する故障被疑箇所推定ステップと、を含み、前記故障被疑箇所推定ステップにおいて、前回の前記試験パケットに関して、前記異常フローに共通する前記サービス構成要素を前記故障被疑箇所と推定し、前回の前記試験パケットに関して、前記故障被疑箇所と推定された前記サービス構成要素が二以上存在するとともに、今回の前記試験パケットに関して、新たに異常フローと判定された前記フローにおいて、前回の前記試験パケットにおいて前記故障被疑箇所と推定された一以上の前記サービス構成要素が含まれる場合に、前回の前記試験パケットにおける異常フローにおける前記故障被疑箇所の最前方位置である前回最前方位置と、今回の前記試験パケットにおける新たな異常フローにおける前記故障被疑箇所の最前方位置である今回最前方位置と、を前記故障被疑箇所ごとに比較し、前記今回最前方位置が前記前回最前方位置よりも前方となる前記故障被疑箇所の故障被疑度を、前記今回最前方位置が前記前回最前方位置と同じ位置又は前記今回最前方位置が前記前回最前方位置よりも後方となる前記故障被疑箇所の故障被疑度よりも高く設定することを特徴とする。

本発明によれば、サービス影響のある異常フローが二以上の故障被疑箇所を備える場合に、二以上の故障被疑箇所間での優先度付けを好適に行うことができる。

本発明の一実施形態にかかるシステムの全体の構成図である。 本発明の一実施形態にかかるサービス影響原因推定装置のハードウェア構成の概要を示すブロック図である。 本発明の一実施形態にかかるサービス影響原因推定プログラムに基づいて中央処理装置が実行する機能を説明する機能ブロック図である。 本発明の一実施形態にかかるサービス影響原因推定装置の設備情報ＤＢに登録されているデータ構成の説明図である。 本発明の一実施形態にかかるサービス影響原因推定装置のソフトウェア情報ＤＢに登録されているデータ構成の説明図である。 本発明の一実施形態にかかるフローモデルの一例を示す説明図である。 本発明の一実施形態にかかる試験パケットの例を説明する。 本発明の一実施形態にかかる各フローをグループ分けする処理のフローチャートである。 図８のグループ分けにおける判断を示す状態遷移図である。 本発明の一実施形態におけるサービス影響の原因推定処理を説明する説明図である。 本発明の一実施形態において第１原因特定部を用いるか、第２原因特定部を用いるかを選択するためのフローチャートである。 本発明の一実施形態におけるサービス影響の原因推定処理の変形例を説明する説明図である。 本発明の一実施形態におけるサービス影響の原因推定処理の変形例を説明する説明図である。 本発明の一実施形態におけるサービス影響の原因推定処理の変形例を説明する説明図である。 本発明の一実施形態における故障被疑度の設定例を説明する説明図である。 本発明の一実施形態における故障被疑度の設定例を説明する説明図である。 本発明の一実施形態における故障被疑度を設定する処理のフローチャートである。 本発明の一実施形態における故障被疑度の設定例を説明する説明図である。 本発明の一実施形態における故障被疑度の設定例を説明する説明図である。 第１の比較例の技術内容を説明する説明図である。 第２の比較例の技術内容を説明する説明図である。 第３の比較例の技術内容を説明する説明図である。

まず、本実施形態を説明する前に本実施形態に対する比較例を複数例説明する。
［比較例］
（第１の比較例）
本明細書において、サービス品質に「劣化」が生じているとは、ネットワーク管理者側で異常の発生を示すアラームを確認できないような異常が発生している場合であり、サービス品質に「故障」が生じているとは、ネットワーク管理者側で当該アラームを確認できる異常が発生している場合である。

図２０は、第１の比較例（特許文献１）の技術内容を説明する説明図である。このネットワークサービス故障診断方法及び装置では、ユーザがサービスを利用する際にその端末と情報ソースとの間に配置される複数のサービス構成要素のそれぞれに関する役割を記述している設備情報データベース（ＤＢ）２０１と、各サービス構成要素に関する正常時及び故障時の動作を記述している設計情報データベース（ＤＢ）２０２とを備えている。設備情報ＤＢ２０１の登録情報の例は符号２０３で示している。

まず、通信ネットワークのユーザ（ユーザＡ）の申告により、そのユーザＩＤと利用サービス名で検索を要求すると（Ｓ２１１）、設備情報ＤＢ２０１に基づいて、当該ユーザＡのEnd-to-Endの設備モデルを、サービス構成要素（物理的装置）を単位として出力する（Ｓ２１２）。そして、設計情報ＤＢ２０２を参照して、当該設備モデルに基づいて、全サービスの構成要素が正常なときの通信シーケンスを生成する（Ｓ２１３）。また、各サービスの構成要素が故障した際の通信シーケンスを、設計情報ＤＢ２０２を参照して生成する（Ｓ２１４）。

次に、正常時の通信シーケンス（Ｓ２１３）、異常時の通信シーケンス（Ｓ２１４）と、観測情報（通信システムの保守者の入力した情報）とを比較して、両者に共通の情報が含まれる通信シーケンスを抽出する。そして、各サービス構成要素のうち、本来の役割を果たさなかったサービス構成要素を抽出する（Ｓ２１５，Ｓ２１６）。この例では、Ｓ２１５で、Ｎｏ．４８のＮＩＣ（Network Interface Controller）の故障時の通信シーケンスが通信シーケンス番号１〜４として示されている。これらは、様々な故障パターンの通信シーケンス例である。また、Ｓ２１６で保守者の入力した情報は、「アラームＡ」という警告が表示されたこと、「メッセージＢ」というメッセージ（Ｓ２１４における「ホストからの応答がありません」というメッセージ）が表示されたこと、及び「○○が動かない」とのユーザＡからの申告である。
この例では、正常／異常時の通信シーケンスと観測情報との比較により、シーケンス番号１，３で一致し、これを抽出する。そして、シーケンス番号１，３の通信シーケンスにおいて、どのサービス構成要素が本来の役割を果たさないのかを判断して、異常箇所の推定を行う。

しかしながら、このような第１の比較例は、予め故障時の通信シーケンスを網羅的に用意する必要があるため、作業が煩雑である。また、第１の比較例は、仮想化設備やアプリケーションソフトといったソフトウェアがサービス構成要素の対象外とされている（対象とされているのは物理的装置だけ）ため、例えば、同一サーバ内に複数の仮想化設備やアプリケーションソフトが設定されている場合、これを設備モデルに変換する際に、ある物理的装置に同居して存在する仮想化設備又はアプリケーションソフトなのか、ある物理的装置に単一で存在する仮想化設備又はアプリケーションソフトなのかを区別できないため、人手による1つ1つの確認作業が必要となってしまい、作業が煩雑である。さらに、第１の比較例は、通信シーケンスの異常を判断するものであるため、通信シーケンスは正常だがサービス品質に劣化が生じている場合に、原因となるサービス構成要素を推定できないという不具合もある。

（第２の比較例）
図２１は、第２の比較例の技術内容を説明する説明図である。この品質劣化原因推定方法は、図２１（ａ）に示すように、ユーザ端末３０１とサーバ３０２がネットワーク３０３を介して接続されている。そして、ネットワーク３０３に設けられた品質劣化原因推定装置３０４がユーザ端末３０１、サーバ３０２間のパケットＰ３１１をキャプチャし、キャプチャしたパケットＰ３１１を解析することで、ユーザの体感品質に影響を与える種々の特性値（リオーダ幅、トラヒック流量、ＲＴＴ（Round-Trip Time）、パケットロス、ジッタ、セッション確立率、ウィンドウサイズ、サーバの応答時間）を算出し、その算出した値に基づいて特性値の正常性判定を行い、ユーザ端末３０１、サーバ３０２間の通信品質劣化の原因箇所を推定するものである。

図２１（ｂ）は、特性値がセッション確立率の例である場合の判定処理のフローチャートである。特性値がセッション確立率であるときは、まず、品質劣化原因推定装置３０４は、セッション確立失敗率が所定の閾値より大きいか否か判断する（Ｓ３２１）。大きくないときは（Ｓ３２１のＮ）、品質劣化原因推定装置３０４は、ネットワーク３０３は正常であると判断する（Ｓ３２２）。大きいときは（Ｓ３２１のＹ）、品質劣化原因推定装置３０４は、セッション終端装置があるか否か判断する（Ｓ３２３）。セッション終端装置がある場合は（Ｓ３２３のＹ）、セッション終端装置に異常の原因がある可能性があるので、品質劣化原因推定装置３０４は、セッション終端装置のログを確認する必要があると判断する（Ｓ３２４）。セッション終端装置がない場合は（Ｓ３２３のＮ）、品質劣化原因推定装置３０４は、サーバ３０２に原因があると判断する（Ｓ３２５）。

図２１（ｃ）は、特性値がウィンドウサイズの例である場合の判定処理のフローチャートである。特性値がウィンドウサイズであるときは、まず、品質劣化原因推定装置３０４は、ウィンドウサイズが所定の閾値より小さいか否か判断する（Ｓ３３１）。閾値以上であるときは（Ｓ３３１のＮ）、品質劣化原因推定装置３０４は、ネットワーク３０３は正常であると判断する（Ｓ３３２）。閾値より小さいときは（Ｓ３３１のＹ）、品質劣化原因推定装置３０４は、帯域制御装置があるか否か判断する（Ｓ３３３）。帯域制御装置がある場合は（Ｓ３３３のＹ）、帯域制御装置に異常の原因がある可能性があるので、品質劣化原因推定装置３０４は、帯域制御装置のログを確認する必要があると判断する（Ｓ３３４）。帯域制御装置がない場合は（Ｓ３３３のＮ）、品質劣化原因推定装置３０４は、サーバ３０２に原因があると判断する（Ｓ３３５）。

しかしながら、このような第２の比較例は、フローごとに、End-to-Endで、ネットワーク３０３内の個々の装置も含めた原因箇所推定を行う場合に、ネットワーク３０３内の装置に設けるキャプチャポイントが多くなってしまい、キャプチャしたパケットＰ３１１のデータの保存量及び判定処理にかかる負荷が増大してしまうので、作業が煩雑となり、装置規模が大規模になってしまう。このため、通信キャリアといった大規模なネットワークにおいては適用が困難である。

（第３の比較例）
図２２は、第３の比較例の技術内容を説明する説明図である。この仮想化機構を含む故障診断方法は、図２２（ａ）に示すように、ネットワーク４０１中に、複数台のサーバ４０２、複数台のスイッチ（ネットワークスイッチ）４０３が配置されている。検出ノード４０４は、ネットワーク４０１中のノードのひとつである。サーバ４０２は、データ転送を行う転送機能部（仮想スイッチに相当）４１１と、アプリケーションソフト４１２とを備えている。ＳＦＦ１〜ＳＦＦ３は、各転送機能部４１１のＩＤであり、ＳＦ１〜ＳＦ５は、各アプリケーションソフト４１２のＩＤである。

本技術は、仮想化されたネットワーク機能の選択的利用を可能とする柔軟な経路制御技術であるＳＦＣ（Service Function Chaining）を用いている。検出ノード４０４は、各フローに対して試験パケットを１つ送信する。この試験パケットは、転送機能部４１１とアプリケーションソフト４１２のＩＤを格納するリストを備えている。試験パケットを受信したサーバ４０２では、当該試験パケットのリストに自身の転送機能部４１１のＩＤを格納し、当該格納後のリストをコピーし、コピーしたリストを送信元の検出ノード４０４にリプライする。その後、当該コピー元のリストを備えた試験パケットを同一サーバ４０２のアプリケーションソフト４１２に転送し、ここでも転送機能部４１１と同様にリストのコピー、コピーしたリストの送信元の検出ノード４０４へのリプライが行われる。さらに別のサーバ４０２に試験パケットが転送される場合も同様である。

図２２（ｂ）には、検出ノード４０４に予め格納されている設定情報４２１の例を示している。この設定情報４２１は、あるフローを転送される試験パケットの通過経路の各部のＩＤを通過する順に上から並べて示している。この例では、ＩＤがＳＦＦ１の転送機能部４１１を備えたサーバ４０２に試験パケットが転送され、その転送機能部４１１、アプリケーションソフト４１２を試験パケットが順次通過した後、ＩＤがＳＦＦ２の転送機能部４１１を備えたサーバ４０２に試験パケットが転送され、その転送機能部４１１、アプリケーションソフト４１２を試験パケットが順次通過する例である。そのため、当該試験パケットが通過する予定の各部のＩＤを順に示すと、“ＳＦＦ１→ＳＦ１→ＳＦＦ１→ＳＦＦ２→ＳＦ２→ＳＦＦ２→ＳＦ３→ＳＦＦ２”となる。

図２２（ｃ）は、試験パケットに基づいて、検出ノード４０４にリプライされたリストの例である。リスト１はＩＤがＳＦＦ１の転送機能部４１１からリプライされ、リスト２はＩＤがＳＦ１のアプリケーションソフト４１２からリプライされ、リスト３はＩＤがＳＦＦ１の転送機能部４１１からリプライされ、リスト４はＩＤがＳＦＦ２の転送機能部４１１からリプライされたものである。

これらのリストと設定情報４２１とを比較することにより、各転送機能部４１１、アプリケーションソフト４１２のうち、異常が存在する部位はどれであるかを判定することができる。リスト１〜リスト４は、設定情報４２１と比較すれば、いずれも検出ノード４０４に正しくリプライされたものであることがわかる。すなわち、リスト１〜リスト４の各最下段のＩＤは設定情報４２１中に存在し、当該ＩＤが当該リストのリプライ元であるから、そのリプライ元の転送機能部４１１又はアプリケーションソフト４１２は正常に動作していると判定できる。
ここで、仮に、ＩＤがＳＦＦ２である転送機能部４１１に異常が存在していると、最下段にＩＤのＳＦＦ２が記録されたリスト４はリプライされないので、リスト４のリプライの不存在をもって、ＩＤがＳＦＦ２である転送機能部４１１に異常があると判定することになる。

しかしながら、このような第３の比較例は、ＩＤを付与可能な転送機能部４１１及びアプリケーションソフト４１２のみを異常診断の対象としているため，それ以外のＩＤを付与できない物理的な装置やソフト的な設備に対しては異常診断ができないという不具合がある。また、転送機能部４１１及びアプリケーションソフト４１２のＩＤが格納されたリストと設定情報４２１との比較だけでは、サービス品質の劣化が生じている場合に原因箇所の推定をすることができないという不具合もある。

［実施形態］
次に、第１〜第３の比較例における不具合を解消した本実施形態の技術内容について説明する。
（システム構成の概要）
図１は、本実施形態の全体のシステム構成図である。インターネットなどの通信ネットワーク１０上には複数のサーバ１１が設置され、これらのサーバ１１は、スイッチ（ネットワークスイッチ）１２、リンク１３を介して接続されている。各サーバ１１には、いずれもソフトウェアである仮想スイッチ（ｖＳＷ）２１、アプリケーションソフト（ＡＰＬ）２２が用意されている。これらの通信ネットワーク１０中の各構成要素には、そのＩＤを、例えば「ＩＤ：ｓｖ０１」のように図示している。

サービス影響原因推定装置１は、この例ではサーバ１１に接続されて設けられている。しかし、本発明はこれに限定されるものではなく、サービス影響原因推定装置１をサーバ１１とは独立させて通信ネットワーク１０中に配置してもよい。

図２は、サービス影響原因推定装置１のハードウェア構成の概要を示すブロック図である。サービス影響原因推定装置１は、各種演算及び制御を行う中央処理装置（ＣＰＵ）３１と、中央処理装置３１の作業領域となる主記憶装置３２と、各種データを記憶する補助記憶装置（ＨＤＤ等）３３と、通信ネットワーク１０と通信を行う通信インターフェイス（Ｉ／Ｆ）３４とを備えている。補助記憶装置３３には、サービス影響原因推定装置１における下記に説明する特徴的な処理を実行するためのプログラムであるサービス影響原因推定プログラム４５が格納されている。

図３は、サービス影響原因推定プログラム４５に基づいて中央処理装置３１が実行する機能を説明する機能ブロック図である。
すなわち、サービス影響原因推定装置１は、記憶部５０と、処理部６０と、管理部７０とを備えている。
記憶部５０には、設備情報データベース（ＤＢ）５１と、ソフトウェア情報データベース（ＤＢ）５２とが設けられている。これら各部の詳細な機能は後述する。
処理部６０は、後述のフローモデルに関する処理を行う。処理部６０には、モデル生成部６１と、構成要素抽出方法決定部６２と、構成要素抽出部６３と、抽出要素格納部６４とが設けられている。構成要素抽出部６３は、第１原因特定部６３１と、第２原因特定部６３２とを備えている。これら各部の詳細な機能は後述する。

管理部７０は、各種データの管理に関する処理を行う。管理部７０には、設定情報管理部７１と、グループ管理部７２と、閾値管理部７３と、試験パケット管理部７４と、記録部７５とが設けられている。グループ管理部７２には、グループ構成部７２１と、グループ格納部７２２とが設けられている。閾値管理部７３は、レスポンスタイム閾値格納部７３１と、リプライカウント数閾値格納部７３２と、故障フロー数閾値格納部７３３と、性能劣化フロー数閾値格納部７３４とが設けられている。試験パケット管理部７４は、試験パケット生成部７４１と、リスト生成部７４２と、パケット送信部７４３と、パケット受信部７４４と、リプライ格納部７４５とが設けられている。記録部７５は、レスポンスタイム格納部７５１と、リプライカウント数格納部７５２と、故障フロー数格納部７５３と、性能劣化フロー数格納部７５４とが設けられている。これら各部の詳細な機能は後述する。

以下では、サービス影響原因推定装置１が実行する処理であるサービス影響原因推定方法について順次説明する。
（サービス影響原因推定方法の概要）
図４は、設備情報ＤＢ５１（図３）に登録されているデータ構成の説明図である。設備情報ＤＢ５１には、フローＩＤと物理設備ＩＤとが関連付けられて登録される。フローＩＤは、通信ネットワーク１０において、転送装置や通信ケーブル等の物理設備と、仮想マシンや仮想スイッチ等の仮想化された設備及びアプリケーションソフト等のソフトウェアとのうち（図１の例では、サーバ１１、スイッチ１２、リンク１３、仮想スイッチ２１、アプリケーションソフト２２）の少なくとも１つ以上を用いて構成されるフローを識別する識別子である。物理設備ＩＤは、通信ネットワーク１０において、前記各フロー中の物理設備（図１の例では、サーバ１１、スイッチ１２、リンク１３）を識別する識別子である。物理設備ＩＤは、データが流れる物理設備のＩＤをデータが流れる順番に左から右に連結して示している。

図５は、ソフトウェア情報ＤＢ５２（図３）に登録されているデータ構成の説明図である。ソフトウェア情報ＤＢ５２には、前記のフローＩＤと、サーバＩＤと、ソフトウェアＩＤとが関連付けられて登録される。サーバＩＤは、サーバ１１を識別する識別子である。ソフトウェアＩＤは、各サーバＩＤが示すサーバ１１に搭載されている仮想マシンや仮想スイッチ等の仮想化された設備及びアプリケーションソフト等のソフトウェア（図１の例では、仮想スイッチ２１、アプリケーションソフト２２）を識別する識別子である。ソフトウェアＩＤは、データが流れるソフトウェアのＩＤをデータが流れる順番に左から右に連結して示している。ソフトウェアＩＤは、各サーバ１１のサーバＩＤと関連付けられていて、当該サーバＩＤの示すサーバ１１内のソフトウェアのＩＤのみで示されている。

図６は、フローモデルの一例を示す説明図である。フローモデルもフローＩＤが識別子となり、図６においては、フローＩＤごとのフローモデル例を示している。フローモデルは、モデル生成部６１により生成される。すなわち、モデル生成部６１は、あるフローＩＤのフローモデルを作成するに際して、設備情報ＤＢ５１（図４）とソフトウェア情報ＤＢ５２（図５）とを参照して、それぞれ対象となるフローＩＤと関連付けられている、物理設備ＩＤが示す物理設備と、サーバＩＤ及びソフトウェアＩＤが示すソフトウェアとを、データが流れる順番に左から右に連結して示している。すなわち、モデル生成部６１は、各フローについてデータが流れる物理設備及びソフトウェアのＩＤと当該データが流れる順番を特定するモデルである。

本実施形態では、処理部６０及び管理部７０が推定部に相当し、この処理部６０及び管理部７０の実行する処理により、前記のフローモデル同士を比較して当該比較結果から、通信ネットワーク１０上での劣化、故障のようなサービス影響の原因となる物理設備又はソフトウェアを推定するものである。以下では、サービス影響原因推定装置１が実行する詳細な処理、特に、推定部となる処理部６０及び管理部７０が実行する具体的な処理について説明する。

（試験パケット）
通信ネットワーク１０上での劣化、故障のようなサービス影響の原因となる物理設備又はソフトウェアを推定するために用いる試験パケットの例を説明する。
まず、リスト生成部７４２がソフトウェアＩＤを格納できる、図７（ａ）に示すようなリストを生成する。このリストには、対象となるフローモデルのフローＩＤとソフトウェアＩＤとが、試験パケットが当該ソフトウェアを通過した際に記載される。そして、試験パケット生成部７４１が、当該リストを備えた試験パケットを生成する。この試験パケットのヘッダには、該当するフローの設備情報ＤＢ５１及びソフトウェア情報ＤＢ５２を参照して、当該試験パケットが通過する物理設備の物理設備ＩＤ、ソフトウェアのソフトウェアＩＤが格納されている。
パケット送信部７４３は、この生成した試験パケットをフローごとに所定時間内に所定数送信する。具体的には、１フローにつき複数個の同一の試験パケットが送信される。
また、パケット送信部７４３は、同一回（後記するＮ−１回目、Ｎ回目）の試験パケット送信において、全てのフローに対して同時又は段階的に試験パケットを送信する。

これにより、各フローにおいて、フローモデルの最後の構成要素がリプライパケットを生成し、送信する。リプライパケットには、対応する試験パケットが通過したソフトウェアのＩＤをそれぞれ格納した、図７（ｂ）に示すようなリストが添付される。リプライパケットはパケット受信部７４４が受信する。そして、リプライ格納部７４５は、当該リプライパケットのリストを格納する。
この試験パケットのレスポンスタイムの実測値はレスポンスタイム格納部７５１に格納され、また、試験パケットのリプライパケットのカウント数はリプライカウント数格納部７５２に格納される。

（グループ分け）
次に、前記試験パケットの送信の結果に基づいて、各フローをグループ分けする。グループ分けは、まず、異常が存在しないフローと判断する「正常グループ」と、異常が存在するフローと判断する「異常グループ」である「性能劣化グループ」及び「故障グループ」とに分類する。グループ構成部７２１は、この正常グループ、異常グループ、性能劣化グループのグループ分けを行う。グループ格納部７２２は、このグループ分けの結果を格納する。また、設定情報管理部７１には、設備情報ＤＢ５１、ソフトウェア情報ＤＢ５２の登録情報を設定情報として取り込む。

図８は各フローをグループ分けする処理のフローチャートである。本処理では、レスポンスタイム格納部７５１に格納されている試験パケットのレスポンスタイムの実測値の閾値としてＮ１，Ｎ２（Ｎ１＜Ｎ２）、リプライカウント数格納部７５２に格納されている試験パケットのリプライパケットのカウント数の閾値としてＣ１，Ｃ２，Ｃ３（Ｃ１＞Ｃ２＞Ｃ３）を用いる。

ここで、レスポンスタイム閾値格納部７３１に格納されるレスポンスタイムに用いる所定値である閾値Ｎ１，Ｎ２は、所定時間内に前記のとおり所定の値だけ送信された試験パケットに対するレスポンスタイムについて平均値をとる又は所定の統計的手法を用いることで求めるものである。同様に、リプライカウント数閾値格納部７３２に格納されるリプライパケットのカウント数に用いる所定値である閾値Ｃ１，Ｃ２，Ｃ３は、所定時間内に前記所定の値だけ送信された試験パケットに対するカウント数の平均値をとる又は所定の統計的手法を用いることで求めるものである。

まず、フローごとに図８に示す処理を行う。すなわち、グループ構成部７２１は、レスポンスタイム格納部７５１に格納されているレスポンスタイムの実測値が閾値Ｎ１より小さいか否かを判断する（Ｓ１）。レスポンスタイムの実測値が閾値Ｎ１より小さいときは（Ｓ１のＹｅｓ）、グループ構成部７２１は、リプライカウント数格納部７５２に格納されているリプライパケットのカウント数が閾値Ｃ１以上か否かを判断する（Ｓ２）。リプライパケットのカウント数が閾値Ｃ１以上であるときは（Ｓ２のＹｅｓ）、グループ構成部７２１は、リプライ格納部７４５に格納されているリプライパケットのリストが設定情報管理部７１に格納されている設定情報と完全に一致するか否かを判断する（Ｓ３）。リプライパケットのリストと設定情報とが完全に一致するときは（Ｓ３のＹｅｓ）、レスポンスが良く、リプライパケットは十分な数が返ってきて、試験パケットは該当するフロー中の物理設備、ソフトウェアを全て正常に経由しているので、グループ構成部７２１は、そのフローを正常グループに分類する（Ｓ４）。

一方、リプライパケットのカウント数が閾値Ｃ１を下回ったときは（Ｓ２のＮｏ）、グループ構成部７２１は、Ｓ３と同様にリプライ格納部７４５に格納されているリプライパケットのリストが設定情報管理部７１に格納されている設定情報と完全に一致するか否かを判断する（Ｓ５）。リプライパケットのリストと設定情報とが完全に一致するときは（Ｓ５のＹｅｓ）、リプライパケットは十分な数が返ってきていないが、試験パケットは該当するフロー中の物理設備、ソフトウェアを全て正常に経由しているので、グループ構成部７２１は、そのフローを性能劣化グループに分類する（Ｓ６）。リプライパケットのリストと設定情報とで一致しないものがあるときは（Ｓ５のＹｅｓ）、リプライパケットは十分な数が返ってきておらず、試験パケットは該当するフロー中の物理設備、ソフトウェアで正常に経由していないものであるので、グループ構成部７２１は、そのフローを故障グループに分類する（Ｓ７）。Ｓ３で、リプライパケットのリストと設定情報とで一致しないものがあるときも（Ｓ３のＮｏ）、リプライパケットは十分な数が返ってきてはいるが、試験パケットは該当するフロー中の物理設備、ソフトウェアで正常に経由していないものであるので、グループ構成部７２１は、そのフローを故障グループに分類する（Ｓ７）。

レスポンスタイムの実測値が閾値Ｎ１以上であるときは（Ｓ１のＮｏ）、グループ構成部７２１は、レスポンスタイムの実測値が閾値Ｎ１以上で、かつ、閾値Ｎ２未満であるか否かを判断する（Ｓ８）。レスポンスタイムの実測値が閾値Ｎ１以上で、かつ、閾値Ｎ２未満であるときは（Ｓ８のＹｅｓ）、グループ構成部７２１は、リプライカウント数格納部７５２に格納されているリプライパケットのカウント数が閾値Ｃ２以上か否かを判断する（Ｓ９）。リプライパケットのカウント数が閾値Ｃ２以上であるときは（Ｓ９のＹｅｓ）、グループ構成部７２１は、リプライ格納部７４５に格納されているリプライパケットのリストが設定情報管理部７１に格納されている設定情報（記憶部５０の情報）と完全に一致するか否かを判断する（Ｓ１０）。リプライパケットのリストと設定情報とが完全に一致するときは（Ｓ１０のＹｅｓ）、レスポンスがそれほど良くはないリプライパケットが複数返ってきており、かつ、試験パケットは該当するフロー中の物理設備、ソフトウェアを全て正常に経由しているので、グループ構成部７２１は、そのフローを性能劣化グループに分類する（Ｓ６）。リプライパケットのリストと設定情報とで一致しないものがあるときは（Ｓ１０のＮｏ）、レスポンスがそれほど良くはないリプライパケットが複数返ってきており、かつ、試験パケットは該当するフロー中の物理設備、ソフトウェアで正常に経由していないものがあるので、グループ構成部７２１は、そのフローを故障グループに分類する（Ｓ７）。リプライパケットのカウント数が閾値Ｃ２未満であるときは（Ｓ９のＮｏ）、グループ構成部７２１は、前記のＳ３の判断により、正常グループと性能劣化グループとにグループ分けする。

レスポンスタイムの実測値が閾値Ｎ１以上で、かつ、閾値Ｎ２未満ではないときは（Ｓ８のＮｏ）、グループ構成部７２１は、レスポンスタイムの実測値が閾値Ｎ２以上であるか否かを判断する（Ｓ１１）。レスポンスタイムの実測値が閾値Ｎ２以上であるときは（Ｓ１１のＹｅｓ）、リプライパケットのカウント数が閾値Ｃ３以上か否かを判断する（Ｓ１２）。リプライパケットのカウント数が閾値Ｃ３以上のときは（Ｓ１２のＹｅｓ）、レスポンスが悪いリプライパケットが所定数以上返ってきているので、グループ構成部７２１は、当該フローを故障グループに分類する（Ｓ７）。リプライパケットのカウント数が閾値Ｃ３未満のときは（Ｓ１２のＹｅｓ）、グループ構成部７２１は、前記のＳ１０の判断により、性能劣化グループと故障グループとに分類する。
以上のグループ分けの結果は、グループ格納部７２２に格納される。

図９は、図８のグループ分けにおける判断を示す状態遷移図である。正常グループ、性能劣化グループ、故障グループにグループ分けする各判断の項目８１〜８９において、（１）は前記のレスポンスタイムの判断、（２）は前記のリプライパケットのカウント数の判断、（３）は前記した設定情報とリストの一致性をそれぞれ示している。

（サービス影響の原因推定）
構成要素抽出部６３は、第１原因特定部６３１と、第２原因特定部６３２とを備えている。構成要素抽出部６３は、フローモデル同士を比較して当該比較結果から通信ネットワーク１０上でのサービス影響の原因となる物理設備又は前記ソフトウェアを推定する。構成要素抽出部６３の第１原因特定部６３１と、第２原因特定部６３２とは、それぞれ異なる手法で当該推定を行う。
まず、第１原因特定部６３１は、前記のように分類された性能劣化グループ内又は故障グループ内で各フローについて、フローモデル同士を比較し、共通する要素となる物理設備又はソフトウェアを抽出し、当該抽出した物理設備又はソフトウェアをサービス影響の原因として推定する。
図１０（ａ）の例では、性能劣化グループ内又は故障グループ内で、フローＩＤがＰ１１とＰ１２のフローモデル同士を比較し、共通する要素となる物理設備ＩＤがｐｓ９５のスイッチ１２を抽出している。

第２原因特定部６３２は、前記のように分類された性能劣化グループ又は故障グループと、正常グループとの間で各フローのフローモデル同士を比較して、共通する物理設備又はソフトウェアはサービス影響の原因の候補から除外し、残った物理設備又はソフトウェアを抽出して、当該抽出した物理設備又はソフトウェアをサービス影響の原因として推定する。

図１０（ｂ）の例では、性能劣化グループ又は故障グループのフローＩＤがＰ２１のフローモデルと、正常グループのフローＩＤがＰ２２のフローモデルとを比較し、共通の要素である、ソフトウェアＩＤが“ｂｋ２”のアプリケーションソフト２２、物理設備ＩＤが“ｐｓ９５”のスイッチ１２を共通するものとして除外し、残った要素である物理設備又はソフトウェアを抽出している。
このようにして、第１原因特定部６３１又は第２原因特定部６３２により抽出された構成要素は抽出要素格納部６４に格納される。

図１１は、構成要素抽出部６３の第１原因特定部６３１を用いるか、第２原因特定部６３２を用いるかを選択するためのフローチャートである。
すなわち、構成要素抽出方法決定部６２が図１１の処理により、第１原因特定部６３１を用いるか、第１原因特定部６３１及び第２原因特定部６３２の両方を用いるかを選択する。この場合に後述の故障フロー数に関する閾値Ｄ１が故障フロー数閾値格納部７３３に格納されていて、同様に後述の性能劣化フロー数に関する閾値Ｄ２が性能劣化フロー数閾値格納部７３４に格納されていて、本処理では当該各閾値を用いる。

構成要素抽出方法決定部６２は、各フローについて図１１の処理を実行する。まず、当該フローが性能劣化グループに分類されているときは（Ｓ２１のＹｅｓ）、構成要素抽出方法決定部６２は、性能劣化グループに分類されたフローの数である性能劣化フロー数を、その閾値である閾値Ｄ１以上であるか否か判断する（Ｓ２２）。性能劣化フロー数が閾値Ｄ１以上であるときは（Ｓ２２のＹｅｓ）、構成要素抽出方法決定部６２は、第１原因特定部６３１を使用する（Ｓ２３）。性能劣化フロー数が閾値Ｄ１未満であるときは（Ｓ２２のＮｏ）、構成要素抽出方法決定部６２は、第１原因特定部６３１を使用した後（Ｓ２４）、第２原因特定部６３２を使用する（Ｓ２５）。

一方、該当するフローが故障グループに分類されているときは（Ｓ２６のＹｅｓ）、構成要素抽出方法決定部６２は、故障グループに分類されたフローの数である故障フロー数を、その閾値である閾値Ｄ２以上であるか否か判断する（Ｓ２７）。故障フロー数が閾値Ｄ２以上であるときは（Ｓ２７のＹｅｓ）、構成要素抽出方法決定部６２は、第１原因特定部６３１を使用する（Ｓ２３）。故障フロー数が閾値Ｄ２未満であるときは（Ｓ２７のＮｏ）、構成要素抽出方法決定部６２は、第１原因特定部６３１を使用した後（Ｓ２４）、第２原因特定部６３２を使用する（Ｓ２５）。
以上のように、第１原因特定部６３１又は第２原因特定部６３２が使用されて、前記のとおり構成要素となる物理設備又はソフトウェアが抽出されると、その抽出した構成要素をサービス影響の原因の可能性がある特定箇所すなわち故障被疑箇所と推定する（Ｓ２８）。

（サービス影響の原因推定の変形例）
図１２〜図１４を参照して前記したサービス影響の原因推定の処理の変形例について説明する。

図１２は、当該変形例を説明する説明図である。図１２（ａ）には、正常グループと故障グループ（性能劣化グループ）のフローモデルの例を示している。本例では、まず、構成要素抽出部６３が、前記の性能劣化グループ内又は前記の故障グループ内で、各フローのフローモデル同士を比較し、共通する物理設備又はソフトウェアの数をそれぞれカウントする。図１２（ｂ）には、そのカウント結果の例を示している。例えば、ソフトウェアＩＤが“ａ１”のアプリケーションソフト２２についてはカウント数が“２１”、物理設備ＩＤが“ｖｓ３”のスイッチ１２についてはカウント数が“１７”であるという例を示している。

その後、構成要素抽出部６３は、このような比較をした性能劣化グループ又は故障グループと、正常グループとの間で各フローのフローモデル同士を比較し、共通する物理設備又はソフトウェアについては、図１２（ｃ）に例示するようにカウントの数を０とする。図１２（ｃ）の例では、ソフトウェアＩＤが“ａ１”のアプリケーションソフト２２については、性能劣化グループ又は故障グループと、正常グループとの間で共通していたのでカウント数が“２１”から“０”に変更され、物理設備ＩＤが“ｖｓ３”のスイッチ１２については、性能劣化グループ又は故障グループと、正常グループとの間で共通していなかったので、カウント数が“１７”のままであるという例を示している（いずれも「合計」）。

そして、構成要素抽出部６３は、最終的に前記のカウントの数が最大である物理設備又はソフトウェアを抽出し、当該抽出した物理設備又はソフトウェアをサービス影響の原因の可能性がある故障被疑箇所として推定する。図１２（ｃ）の例では、カウントの数が最大である物理設備又はソフトウェアは、物理設備ＩＤが“ｓ３”のスイッチ１２のカウント数“４５”であり、これが「最終結果」となる。そのため、構成要素抽出部６３は、物理設備ＩＤが“ｓ３”のスイッチ１２が、サービス影響の原因の可能性がある故障被疑箇所として推定する。
このような処理において、最終的に前記のカウントの数が最大である物理設備又はソフトウェアを抽出し、その抽出した物理設備又はソフトウェアが複数個になる場合もある。

この場合に、抽出した複数個の物理設備又はソフトウェアについて説明する。まず、図１を参照して前記したように、通信ネットワーク１０上の各部にＩＤ（物理設備ＩＤ、サーバＩＤ、ソフトウェアＩＤ）が付されている。
これに対して、物理設備ＩＤ及びソフトウェアＩＤとして、当該ＩＤが示す物理設備又はソフトウェアと、当該物理設備又はソフトウェアと親子関係又は接続関係にある他の物理設備、ソフトウェア、又はサーバとの相関関係を示すものを用いるようにする。

図１３は、図１の例において、物理設備ＩＤ、ソフトウェアＩＤとして、このような相関関係のあるＩＤを用いた例を示す図である。例えば、物理設備ＩＤが“ｌ１：ｓｖ０１：ｓ１”であるリンク１３において、物理設備ＩＤの“ｌ１”の部分は当該リンク１３自体を示しており、これに続く“ｓｖ０１”の部分は当該スイッチ１２と接続関係にあるサーバ１１のＩＤを示し、同様に、“ｓ１”の部分は当該スイッチ１２と接続関係にあるスイッチ１２のＩＤを示している。
このような物理設備ＩＤ及びソフトウェアＩＤを用いることで、当該ＩＤから当該ＩＤと親子関係又は接続関係にある他の物理設備、ソフトウェア、又はサーバを認識することができる。

図１４は、図１３のＩＤを用いて実行する処理の説明図である。この例では、図１２の処理で求めた今回の結果が、物理設備ＩＤ又はソフトウェアＩＤ（の図１の例に相当する部分だけを図１４に示している）が、それぞれ“ｂ２”、“ｖｓ２”、“ｌ２”の場合の物理設備又はソフトウェアのカウントの数がいずれも“２５”である。すなわち、前記のサービス影響の原因である物理設備又はソフトウェアが複数推定された場合である。この場合に、構成要素抽出部６３は、今回の当該複数の物理設備又はソフトウェア同士、又は、前回行われた処理で推定された物理設備又はソフトウェアと今回行われた処理で推定された物理設備又はソフトウェアとについて前記の親子関係又は接続関係がある場合に、今回行われて複数推定された物理設備又はソフトウェアのカウントの数に優先度をつける。

図１４の例では、ソフトウェアＩＤが“ｂ２（図１３では、“ｂ２：ｖｓ２”）”のアプリケーションソフト２２と、ソフトウェアＩＤが“ｖｓ２（図１３では、“ｖｓ２：ｂ１：ｂ２”）”の仮想スイッチ２１との間には親子関係（前者が子、後者が親）があるため、親であるソフトウェアＩＤが“ｖｓ２（図１３では、“ｖｓ２：ｂ１：ｂ２”）”の仮想スイッチ２１の優先度を＋１だけ上げる。また、物理設備ＩＤが“ｌ２（図１３では、“ｌ２：ｓｖ０２：ｓ１”）”のリンク１３の前回の結果と、ソフトウェアＩＤが“ｖｓ２（図１３では、“ｖｓ２：ｂ１：ｂ２”）”の仮想スイッチ２１の今回の結果との間には直接的な接続関係があるため、物理設備ＩＤが“ｌ２（図１３では、“ｌ２：ｓｖ０２：ｓ１”）”のリンク１３の影響が波及したと推定し、ソフトウェアＩＤが“ｖｓ２（図１３では、“ｖｓ２：ｂ１：ｂ２”）”の仮想スイッチ２１の今回の結果の優先度を−０．５下げる。
物理設備ＩＤが“ｓ３（図１３では、“ｓ３：ｌ４：ｌ５”）”のスイッチ１２の前回の結果と、今回の結果との間には、親子関係又は接続関係がないため、当該スイッチ１２が単独で故障していると推定し、＋１だけ優先度を上げる。

これらの結果、ソフトウェアＩＤが“ｂ２（図１３では、“ｂ２：ｖｓ２”）”のアプリケーションソフト２２の最終結果は“２５”、ソフトウェアＩＤが“ｖｓ２（図１３では、“ｖｓ２：ｂ１：ｂ２”）”の仮想スイッチ２１の最終結果は“２５．５”、物理設備ＩＤが“ｓ３（図１３では、“ｓ３：ｌ４：ｌ５”）”のスイッチ１２の最終結果は“２６”となる。

以上の処理により、物理設備及びソフトウェアの探索順序は、最終結果の値が大きい物理設備ＩＤが“ｓ３（図１３では、“ｓ３：ｌ４：ｌ５）”のスイッチ１２、ソフトウェアＩＤが“ｖｓ２（図１３では、“ｖｓ２：ｂ１：ｂ２）”の仮想スイッチ２１、ソフトウェアＩＤが“ｂ２（図１３では、“ｂ２：ｖｓ２”）”のアプリケーションソフト２２の順番となる。

以上説明した本実施形態によれば、ソフトウェアの故障や劣化も検出でき、作業が簡易で、装置規模が比較的小規模であり、サービス品質の劣化が生じている原因箇所の推定もできるサービス影響原因推定装置１、サービス影響原因推定プログラム４５、及びサービス影響原因推定方法を提供することができる。

＜故障被疑度の設定＞
続いて、サービス影響原因推定装置１による故障被疑度の設定について説明する。以下の例では、異常フローが初めて検出される回までは、構成要素抽出部６３の第１原因特定部６３１のみが異常フローの故障被疑箇所を推定し、それ以降の回では、構成要素抽出部６３の第１原因特定部６３１及び第２原因特定部６３２の両方が異常フローの故障被疑箇所を推定する。

サービス影響原因推定装置１は、前回（Ｎ−１回目（Ｎは２以上の整数））の試験パケットに関して異常に分類された異常フローと、今回（Ｎ回目）の試験パケットに関して新たに異常に分類された異常フローと、を用いて、故障被疑箇所と推定されたサービス構成要素の故障被疑度を設定する。
故障被疑度は、当該故障被疑度が高いほど、対応するサービス構成要素がサービス影響の原因である可能性が高いことを示すものである。
サービス影響原因推定装置１は、故障被疑度が高い故障被疑箇所を優先して検索することによって、サービス影響の原因をより迅速に特定することができるようになる。

図３に示すように、サービス影響原因推定装置１の試験パケット管理部７４は、試験パケット回数格納部７４６をさらに備える。
試験パケット回数格納部７４６は、複数のフローに対して送信された試験パケットが何回目のものであるかを示す試験パケット回数を格納する。かかる試験パケット回数は、リプライ格納部７４５に格納されたリプライパケットとともに他の機能部へ提供され、正常又は異常と分類されたフローが何回目の試験パケットによる分類であるのかが認識可能となっている。

また、処理部６０は、故障被疑度を設定するための機能部として、最前方位置抽出部６５と、最前方位置格納部６６と、最前方位置比較部６７と、故障被疑度管理部６８と、をさらに備える。

最前方位置抽出部６５は、モデル生成部６１によって生成されたフローモデルと、抽出要素格納部６４に格納された抽出要素と、を取得し、取得されたフローモデル及び抽出要素に基づいて、同一の試験パケット回数における故障被疑箇所の最前方位置を抽出する。

より詳細には、最前方位置抽出部６５は、ある試験パケット回数の試験パケットに関して異常に分類された異常フローにおいて、二以上の故障被疑箇所がある場合に、故障被疑箇所と推定されたサービス構成要素ごとに、最前方位置を抽出する。
また、最前方位置抽出部６５は、その後に新たに異常フローが発生し、かつ、新たな異常フローに以前の異常フローの故障被疑箇所が二以上含まれる場合に、新たな異常フローにおける故障被疑箇所の最前方位置を抽出する。

最前方位置格納部６６は、最前方位置抽出部６５によって抽出された故障被疑箇所の最前方位置を格納する。

最前方位置比較部６７は、最前方位置格納部６６に格納された前回の試験パケット及び今回の試験パケットの最前方位置を読み出し、前回の試験パケットにおける異常フローにおける故障被疑箇所の最前方位置である前回最前方位置と、今回の試験パケットにおける新たな異常フローにおける故障被疑箇所の最前方位置である今回最前方位置と、を故障被疑箇所ごとに比較し、比較結果を故障被疑度管理部６８へ出力する。

故障被疑度管理部６８は、最前方位置比較部６７の比較結果に基づいて、前回の試験パケットにおける二以上の故障被疑箇所に関して、故障被疑度を設定する。
より詳細には、故障被疑度管理部６８は、今回最前方位置が前回最前方位置よりも前方となる故障被疑箇所の故障被疑度を、今回最前方位置が前回最前方位置と同じ位置又は今回最前方位置が前回最前方位置よりも後方となる故障被疑箇所の故障被疑度よりも高く設定する。
また、故障被疑度管理部６８は、今回のパケットに関して、新たに異常フローと判定されたフローにおいて、前回の試験パケットにおいて故障被疑箇所と推定されたサービス構成要素が一つのみ含まれる場合には、当該故障被疑箇所の故障被疑度を、前回の試験パケットにおいて故障被疑箇所と推定されて新たに異常フローと判定されたフローには含まれない故障被疑箇所の故障被疑度よりも高く設定する。

＜故障被疑度の設定例その１：新たな異常フローに二以上の故障被疑度が含まれる場合＞
続いて、故障被疑度の設定例について、各フローは、５個のサービス構成要素（図中の○印）を同一長さのリンクで接続したものであり、同一回における試験パケットの送信時刻は全フローに対して同一である場合を例にとって説明する。

図１５（ａ）に示すように、前回（Ｎ−１回目（Ｎは２以上の整数））の試験パケットにおいて、グループ構成部７２１は、フローＰ０１，Ｐ０２が異常フローであると判定している。また、構成要素抽出部６３は、フローＰ０１，Ｐ０２に共通して含まれるサービス構成要素Ａ，Ｂを故障被疑箇所として抽出している。なお、図１５（ａ）では、説明を分かりやすくするため、Ｎ−１回目では異常フローであると判定されず、Ｎ回目に新たに異常フローであると判定されるフローＰ１７も図示されている（後記する図１６（ａ）、図１８（ａ）、図１９（ａ）についても同様）。フローＰ０１，Ｐ０２及び後記するフローＰ１７において、サービス構成要素Ａ，Ｂ以外のサービス構成要素は、それぞれ異なるものとなっている。

フローＰ０１は、故障被疑箇所であるサービス構成要素Ｂを３番目、故障被疑箇所であるサービス構成要素Ａを４番目に備えている。
また、フローＰ０２は、故障被疑箇所であるサービス構成要素Ｂを３番目、故障被疑箇所であるサービス構成要素Ａを５番目に備えている。
したがって、最前方位置抽出部６５は、前回の試験パケットにおいて、故障被疑箇所Ａの最前方位置Ａ_Ｎ−１としてフローＰ０１における故障被疑箇所Ａの位置を抽出し、故障被疑箇所Ｂの最前方位置Ｂ_Ｎ−１として、フローＰ０１，Ｐ０２における故障被疑箇所Ｂの位置を抽出する。

続いて、図１５（ｂ）に示すように、今回（Ｎ回目）の試験パケットにおいて、グループ構成部７２１は、フローＰ０１，Ｐ０２に加え、新たにフローＰ１７が異常フローであると判定する。

フローＰ１７は、故障被疑箇所であるサービス構成要素Ａを２番目、故障被疑箇所であるサービス構成要素Ｂを４番目に備えている。
したがって、最前方位置抽出部６５は、今回の試験パケットにおいて、新たな異常フローにおける故障被疑箇所Ａの最前方位置Ａ_Ｎとして、フローＰ１７における故障被疑箇所Ａの位置を抽出し、故障被疑箇所Ｂの最前方位置Ｂ_Ｎとして、フローＰ１７における故障被疑箇所Ｂの位置を抽出する。

最前方位置比較部６７は、故障被疑箇所Ａ，Ｂのそれぞれに関して、前回と今回の最前方位置を比較し、比較結果を故障被疑度管理部６８へ出力する。前回と今回の最前方位置を比較する際には、前回の試験パケットの最初の送信タイミングと今回の試験パケットの最初の送信タイミングとが同位置となるように位置合わせが行われる。

故障被疑度管理部６８は、かかる比較結果に基づいて、故障被疑箇所Ａ，Ｂに対して故障被疑度を設定する。

この例では、故障被疑箇所Ａの今回最前方位置Ａ_Ｎが前回最前方位置Ａ_Ｎ−1よりも前方に位置しており、故障被疑箇所Ｂの今回最前方位置Ｂ_Ｎが前回最前方位置Ｂ_Ｎ−１よりも後方に位置しているので、故障被疑箇所Ａの故障被疑度を故障被疑箇所Ｂの故障被疑度よりも高く設定する。

これは、２番目にサービス構成要素Ａが設けられたフローＰ１７が前回の試験パケットでは異常フローに分類されていないことから、試験パケットが２番目のサービス構成要素を通過して４番目のサービス構成要素に到達するまでの間にサービス構成要素Ａに故障が発生した可能性が高いと考えられるためである。

＜故障被疑度の設定例その２：新たな異常フローに故障被疑箇所が一種類のみ含まれる場合＞
図１６（ａ）（ｂ）に示すように、Ｎ回目の試験パケットで新たに異常フローであると判定されたフローＰ１７が、故障被疑箇所Ａのみを備えており故障被疑箇所Ｂを備えていない場合には、最前方位置の比較が行われることなく、故障被疑度管理部６８は、故障被疑箇所Ａの故障被疑度を故障被疑箇所Ｂの故障被疑度よりも高く設定する。

これは、新たな異常フローに１つの故障被疑箇所Ａのみが含まれる場合には、当該故障被疑箇所Ａの今回最前方位置は前回最前方位置よりも前方に位置するようになっており、また、２番目にサービス構成要素Ａが設けられたフローＰ１７が前回の試験パケットでは異常フローに分類されていないことから、試験パケットが２番目のサービス構成要素を通過して４番目のサービス構成要素に到達するまでの間にサービス構成要素Ａに故障が発生した可能性が高いと考えられるためである。

これらの設定例に鑑み、故障被疑度の設定順位（優先度）を高い方から並べると、以下のようになる。
（１）前回の異常フローにも今回の新たな異常フローにも含まれており、今回最前方位置が前回最前方位置よりも前方に位置する故障被疑箇所
（２）前回の異常フローにも今回の新たな異常フローにも含まれており、今回最前方位置が前回最前方位置と同じ位置であるか後方に位置する故障被疑箇所
（３）前回の異常フローに含まれているが今回の新たな異常フローには含まれていない故障被疑箇所

＜動作例＞
続いて、図１７を参照して、サービス影響原因推定装置１による故障被疑度設定方法について説明する。

まず、試験パケット生成部７４１が試験パケットを生成し、パケット送信部７４３が、各フローに対して、試験パケットをそれぞれ送信する（ステップＳ３１、パケット送信ステップ）。

続いて、パケット受信部７４４が、リプライパケットを受信し（パケット受信ステップ、設定情報管理部７０及び処理部６０が、前記した手法に基づいて、各フローを正常フローと異常フローとに分類し、異常フローにおける故障被疑箇所を推定する（ステップＳ３２、グループ構成ステップ、故障被疑箇所推定ステップ）。なお、以降のステップＳ３３〜ステップＳ４６も、本発明の故障被疑箇所推定ステップに相当する。

全てのフローが正常フローに分類されており、故障被疑箇所が無い場合（ステップＳ３３でＮｏ、かつ、ステップＳ３４でＮｏ）には、本フロー処理は、ステップＳ３１に戻る。
また、一以上のフローが異常フローに分類されており、かつ、故障被疑箇所であると推定されたサービス構成要素が一つである場合（ステップＳ３３でＮｏ、かつ、ステップＳ３４でＹｅｓ）には、本フロー処理は、終了する。
この場合には、サービス影響原因推定装置１は、故障被疑箇所であると推定された一のサービス構成要素を検索し、当該サービス構成要素がサービス影響の原因であるか否かの特定を行う。

また、一以上のフローが異常フローに分類されており、かつ、故障被疑箇所であると推定されたサービス構成要素が複数である場合（ステップＳ３３でＹｅｓ）には、最前方位置抽出部２４が、各故障被疑箇所において最前方位置を抽出し（ステップＳ３５）、抽出された各故障被疑箇所の最前方位置をパケット送信回数と関連付けて最前方位置格納部６６に格納させる。

ステップＳ３５の実行後、１回目の試験結果（すなわち、試験パケット送信回数１回目における最前方位置の抽出）である場合（ステップＳ３６でＹｅｓ）には、本フロー処理は、ステップＳ３１に戻る。

また、ステップＳ３５の実行後、１回目の試験結果ではない場合、すなわち、２回目の試験結果（すなわち、試験パケット送信回数２回目における最前方位置の抽出）である場合（ステップＳ３６でＮｏ）には、グループ構成部７２１が、前回試験結果と今回試験結果とを比較する（ステップＳ３７）。
詳細には、ステップＳ３７において、グループ構成部７２１が、今回試験結果における異常フローと、グループ格納部７２２に格納された前回試験結果における異常フローと、を比較し、今回試験結果において新たに異常フローに分類されたフローがあるか否かを判定する。

影響ありのサービスが新たに検出されていない場合、すなわち、新たに異常フローに分類されたフローがなく、異常フローの数が増えていない場合（ステップＳ３８でＮｏ）には、故障被疑度管理部６８は、異常フローの故障被疑箇所に故障被疑度を設定せず（ステップＳ３９）、又は、異常フローの故障被疑箇所の故障被疑度を全て同格に設定し、本フロー処理は終了する。
この場合には、サービス影響原因推定装置１は、故障被疑箇所であると推定された二以上のサービス構成要素の故障被疑度を同格とみなし、これら二以上のサービス構成要素を例えばサービス構成要素のＩＤ順等で検索し、当該サービス構成要素がサービス影響の原因であるか否かの特定を行う。

影響ありのサービスが新たに検出された場合、すなわち、新たに異常フローに分類されたフローがあり、異常フローの数が増えている場合（ステップＳ３８でＹｅｓ）であって、前回の二以上の故障被疑箇所のうち一つのみが新たな異常フローに含まれている場合（ステップＳ４０でＮｏ）には、故障被疑度管理部６８は、新たな異常フローに含まれている故障被疑箇所の故障被疑度を、新たな異常フローには含まれていない故障被疑箇所の故障被疑度よりも高く設定し（ステップＳ４１）、本フロー処理は終了する。
ステップＳ４０でＮｏ→ステップＳ４１の流れは、図１６で説明した例に該当する。

影響ありのサービスが新たに検出された場合、すなわち、新たに異常フローに分類されたフローがあり、異常フローの数が増えている場合（ステップＳ３８でＹｅｓ）であって、前回の二以上の故障被疑箇所のうち二以上が新たな異常フローに含まれている場合（ステップＳ４０でＹｅｓ）には、最前方位置抽出部２４が、新たな異常フローに関して各故障被疑箇所において最前方位置を抽出し（ステップＳ４２）、抽出された各故障被疑箇所の最前方位置をパケット送信回数と関連付けて最前方位置格納部６６に格納させる。

続いて、最前方位置比較部６７が、新たな異常フローに含まれる故障被疑箇所ごとに、前回最前方位置と今回最前方位置とを比較する（ステップＳ４３）。
新たな異常フローに含まれる故障被疑箇所の全てに関して、今回最前方位置が前回最前方位置と同じ位置か後方に位置する場合（ステップＳ４４でＮｏ）には、故障被疑度管理部６８は、新たな異常フローの故障被疑箇所に故障被疑度を設定せず（ステップＳ４６）、又は、新たな異常フローの故障被疑箇所の故障被疑度を全て同格に設定し、本フロー処理は終了する。

また、新たな異常フローに含まれる故障被疑箇所に関して、今回最前方位置が前回最前方位置よりも前方に位置するものがある場合（ステップＳ４４でＹｅｓ）には、故障被疑度管理部６８は、今回最前方位置が前回最前方位置よりも前方に位置する故障被疑箇所の故障被疑度を、それ以外の故障被疑箇所の故障被疑度よりも高く設定し（ステップＳ４５）、本フロー処理は終了する。
ステップＳ４０でＹｅｓ→ステップＳ４２→ステップＳ４４→ステップＳ４５の流れは、図１５で説明した例に該当する。

＜故障被疑度の設定例その３：リンク長を考慮した最前方位置抽出＞
図１８に示すように、最前方位置抽出部６５は、異常フローのリンク長を考慮して各故障被疑箇所の最前方位置を抽出する構成であってもよい。この場合、モデル生成部６１は、リンク長を考慮した各フローのモデルを生成する。
図１８の例では、フローＰ０１，Ｐ０２において、２番目のサービス構成要素と３番目のサービス構成要素との間のリンク長は、通常の４倍に相当する。
また、フローＰ１７において、４番目のサービス構成要素と５番目のサービス構成要素との間のリンク長は、通常の２倍に相当する。
なお、各設定例において、最前方位置の抽出に際して、サービス影響原因推定装置１から最初のサービス構成要素までのリンク長も考慮されている。

したがって、図１８（ｂ）に示すように、最前方位置比較部６７は、故障被疑箇所Ａの今回最前方位置Ａ_Ｎが前回最前方位置Ａ_Ｎ−１よりも前方に位置すると判定するとともに、故障被疑箇所Ｂの今回最前方位置Ｂ_Ｎが前回最前方位置Ｂ_Ｎ−１よりも前方に位置すると判定する。
この場合には、故障被疑度管理部６８は、故障被疑箇所Ａ，Ｂの故障被疑度を同格に設定する。

＜故障被疑度の設定例その４：試験パケットの送信時刻の差分（時刻差分）を考慮した最前方位置抽出＞
図１９に示すように、最前方位置抽出部６５は、試験パケットの送信時刻の差分を考慮して各故障被疑箇所の最前方位置を抽出する構成であってもよい。試験パケットの送信時刻の差分は、予め設定された記憶されていてもよく、パケット送信部７４３が実際に送信した時刻を計時したものであってもよい。
図１９の例では、パケット送信部７４３は、１回の試験パケット送信において、１０個のフローを１単位として試験パケットを送信する。そのため、１つ目の単位に含まれるフローＰ０１，Ｐ０２の試験パケット送信時刻に対して、２つ目の単位に含まれるフローＰ１７の試験パケット送信時刻が時刻差分だけ遅れている。

したがって、図１９（ｂ）に示すように、最前方位置比較部６７は、故障被疑箇所Ａの今回最前方位置Ａ_Ｎが前回最前方位置Ａ_Ｎ−１と同じ位置であると判定するとともに、故障被疑箇所Ｂの今回最前方位置Ｂ_Ｎが前回最前方位置Ｂ_Ｎ−１よりも後方に位置すると判定する。
この場合には、故障被疑度管理部６８は、故障被疑箇所Ａ，Ｂの故障被疑度を同格に設定する。

本発明の実施形態にかかるサービス影響原因推定装置１は、前回の試験パケットによる異常フローに二以上の故障被疑箇所があり、かつ、今回の試験パケットで前回の故障被疑箇所を含む新たな異常フローが発生した場合に、故障被疑箇所の最前方位置に応じて故障被疑度を設定するので、二以上の故障被疑箇所間での優先度付けすなわち故障被疑度の設定を好適に行うことができる。
また、サービス影響原因推定装置１は、前回の試験パケットによる異常フローに二以上の故障被疑箇所があり、かつ、今回の試験パケットで前回の故障被疑箇所を含む新たな異常フローが発生した場合であって、今回の新たな異常フローに含まれる故障被疑箇所の故障被疑度を、今回の新たな異常フローには含まれない故障被疑箇所の故障被疑度よりも高く設定するので、二以上の故障被疑箇所間での優先度付けすなわち故障被疑度の設定を好適に行うことができる。

また、サービス影響原因推定装置１は、異常フローのリンク長及び／又は試験パケットの送信時刻の差分を考慮して故障被疑箇所の最前方位置を抽出するので、故障被疑度の設定をより好適に行うことができる。

以上、本発明の実施形態について説明したが、本発明は前記実施形態に限定されず、本発明の要旨を逸脱しない範囲で適宜変更可能である。例えば、図１７のフローチャートにおいて、ステップＳ３５の処理を、ステップＳ３３とステップＳ３６との間ではなく、ステップＳ４２と同時（すなわち、ステップＳ４０とステップＳ４４との間）に行う構成であってもよい。
また、今回最前方位置が前回最前方位置よりも前にある故障被疑箇所が複数ある場合に、前方への移動量が大きいほど故障被疑度を高く設定する構成であってもよい。
また、故障被疑度の設定としては、「優先度の有無」や「高低」の２段階、「高中低」の３段階、数値化等が好適に利用可能である。
また、例えば異常フローが初めて検出された回において異常フローと分類されたフローの個数が所定個数以上である場合等には、それ以降の回においても第１原因特定部６３１のみが異常フローの故障被疑箇所を推定する構成であってもよい。

１ サービス影響原因推定装置
４５ サービス影響原因推定プログラム
５０ 記憶部
６０ 処理部（推定部、故障被疑箇所推定部）
７０ 管理部（推定部）
７２１ グループ構成部
７４３ パケット送信部
７４４ パケット受信部
７４６ 試験パケット回数格納部（故障被疑箇所推定部）

Claims (6)

1. 通信ネットワーク上でデータが受け渡しされる物理設備及びソフトウェアをサービス構成要素として、一以上の前記サービス構成要素を用いて構成される複数のフローに対して試験パケットを前記フローごとに送信するパケット送信部と、
   前記フローを通過する前記試験パケットのリプライパケットを受信するパケット受信部と、
   受信した前記リプライパケットに基づいて、前記フローが正常フローであるか異常フローであるかを判定するグループ構成部と、
   前記異常フローにおいて前記ネットワーク上でのサービス影響の原因となる故障被疑箇所を推定する故障被疑箇所推定部と、
   を備え、
   前記故障被疑箇所推定部は、
   前回の前記試験パケットに関して、前記異常フローに共通する前記サービス構成要素を前記故障被疑箇所と推定し、
   前回の前記試験パケットに関して、前記故障被疑箇所と推定された前記サービス構成要素が二以上存在するとともに、今回の前記試験パケットに関して、新たに異常フローと判定された前記フローにおいて、前回の前記試験パケットにおいて前記故障被疑箇所と推定された一以上の前記サービス構成要素が含まれる場合に、
   前回の前記試験パケットにおける異常フローにおける前記故障被疑箇所の最前方位置である前回最前方位置と、今回の前記試験パケットにおける新たな異常フローにおける前記故障被疑箇所の最前方位置である今回最前方位置と、を前記故障被疑箇所ごとに比較し、
   前記今回最前方位置が前記前回最前方位置よりも前方となる前記故障被疑箇所の故障被疑度を、前記今回最前方位置が前記前回最前方位置と同じ位置又は前記今回最前方位置が前記前回最前方位置よりも後方となる前記故障被疑箇所の故障被疑度よりも高く設定する
   ことを特徴とするサービス影響原因推定装置。
2. 前記故障被疑箇所推定部は、前記サービス構成要素間のリンクの長さに基づいて、前記前回最前方位置と前記今回最前方位置とを比較する
   ことを特徴とする請求項１に記載のサービス影響原因推定装置。
3. 前記故障被疑箇所推定部は、前記試験パケットの各回における前記フローごとの送信時刻の差分に基づいて、前記前回最前方位置と前記今回最前方位置とを比較する
   ことを特徴とする請求項１又は請求項２に記載のサービス影響原因推定装置。
4. 前記故障被疑箇所推定部は、
   今回の前記試験パケットに関して、新たに異常フローと判定された前記フローにおいて、前回の前記試験パケットにおいて前記故障被疑箇所と推定された前記サービス構成要素が一つのみ含まれる場合には、
   当該故障被疑箇所の故障被疑度を、前回の前記試験パケットにおいて前記故障被疑箇所と推定されて新たに異常フローと判定された前記フローには含まれない前記故障被疑箇所の故障被疑度よりも高く設定する
   ことを特徴とする請求項１に記載のサービス影響原因推定装置。
5. コンピュータを、
   通信ネットワーク上でデータが受け渡しされる物理設備及びソフトウェアをサービス構成要素として、一以上の前記サービス構成要素を用いて構成される複数のフローに対して試験パケットを前記フローごとに送信するパケット送信部、
   前記フローを通過する前記試験パケットのリプライパケットを受信するパケット受信部、
   受信した前記リプライパケットに基づいて、前記フローが正常フローであるか異常フローであるかを判定するグループ構成部、及び、
   前記異常フローにおいて前記ネットワーク上でのサービス影響の原因となる故障被疑箇所を推定する故障被疑箇所推定部、
   として機能させ、
   前記故障被疑箇所推定部は、
   前回の前記試験パケットに関して、前記異常フローに共通する前記サービス構成要素を前記故障被疑箇所と推定し、
   前回の前記試験パケットに関して、前記故障被疑箇所と推定された前記サービス構成要素が二以上存在するとともに、今回の前記試験パケットに関して、新たに異常フローと判定された前記フローにおいて、前回の前記試験パケットにおいて前記故障被疑箇所と推定された一以上の前記サービス構成要素が含まれる場合に、
   前回の前記試験パケットにおける異常フローにおける前記故障被疑箇所の最前方位置である前回最前方位置と、今回の前記試験パケットにおける新たな異常フローにおける前記故障被疑箇所の最前方位置である今回最前方位置と、を前記故障被疑箇所ごとに比較し、
   前記今回最前方位置が前記前回最前方位置よりも前方となる前記故障被疑箇所の故障被疑度を、前記今回最前方位置が前記前回最前方位置と同じ位置又は前記今回最前方位置が前記前回最前方位置よりも後方となる前記故障被疑箇所の故障被疑度よりも高く設定する
   ことを特徴とするサービス影響原因推定プログラム。
6. 通信ネットワーク上でデータが受け渡しされる物理設備及びソフトウェアをサービス構成要素として、一以上の前記サービス構成要素を用いて構成される複数のフローに対して試験パケットを前記フローごとに送信するパケット送信ステップと、
   前記フローを通過する前記試験パケットのリプライパケットを受信するパケット受信ステップと、
   受信した前記リプライパケットに基づいて、前記フローが正常フローであるか異常フローであるかを判定するグループ構成ステップと、
   前記異常フローにおいて前記ネットワーク上でのサービス影響の原因となる故障被疑箇所を推定する故障被疑箇所推定ステップと、
   を含み、
   前記故障被疑箇所推定ステップにおいて、
   前回の前記試験パケットに関して、前記異常フローに共通する前記サービス構成要素を前記故障被疑箇所と推定し、
   前回の前記試験パケットに関して、前記故障被疑箇所と推定された前記サービス構成要素が二以上存在するとともに、今回の前記試験パケットに関して、新たに異常フローと判定された前記フローにおいて、前回の前記試験パケットにおいて前記故障被疑箇所と推定された一以上の前記サービス構成要素が含まれる場合に、
   前回の前記試験パケットにおける異常フローにおける前記故障被疑箇所の最前方位置である前回最前方位置と、今回の前記試験パケットにおける新たな異常フローにおける前記故障被疑箇所の最前方位置である今回最前方位置と、を前記故障被疑箇所ごとに比較し、
   前記今回最前方位置が前記前回最前方位置よりも前方となる前記故障被疑箇所の故障被疑度を、前記今回最前方位置が前記前回最前方位置と同じ位置又は前記今回最前方位置が前記前回最前方位置よりも後方となる前記故障被疑箇所の故障被疑度よりも高く設定する
   ことを特徴とするサービス影響原因推定方法。

Images