JP2017153015A - 故障解析装置、故障解析プログラムおよび故障解析方法 - Google Patents

Abstract

【課題】１つ以上の事業者ネットワークを利用して通信サービスを提供する通信ネットワークにおいて、より精度よく故障箇所を推定する。【解決手段】故障解析装置１は、サービス監視情報および部分監視情報を取得する情報取得部１２２と、サービス監視情報、部分監視情報のそれぞれが異常情報であるか正常情報であるかを判定するサービス異常判定部１２３と、サービス監視情報、部分監視情報のそれぞれが異常情報であると判定された場合に、当該サービスの区間における仮定のノード構成に基づく分割区間に被疑ポイントを加算し、正常情報であると判定された場合に、当該分割区間に正常ポイントを加算し、被疑ポイントの合計と正常ポイントの合計とに基づき、分割区間について被疑度合に応じた順位付けを行い、故障被疑箇所を推定する情報解析部１２５と、を備える。【選択図】図２

Description

本発明は、サービス提供事業者が複数の事業者ネットワーク（ＮＷ：Network）を利用して通信サービスを提供する通信ネットワークにおいて故障箇所を解析する技術に関する。

近年、新たなデジタルサービスを創出するにあたり、全てを自社の設備で構築するのではなく、他事業者のデジタルサービスを利用してエンドユーザにサービスを提供する、Ｂ２Ｂ２Ｘモデルの通信サービスが盛んになっている。

このようなＢ２Ｂ２Ｘモデルの通信サービスでは、複数のサービス提供事業者が、それぞれ複数の事業者ネットワークに跨って構築された自社のネットワークの範囲内の障害を検知することができる。
しかし、このような障害検知では、事業者ネットワークが提供するネットワークリソースの障害の一部分を複数のサービス提供事業者が個々に検知しているにすぎないため、事業者ネットワーク内において故障の可能性が高いノード（故障箇所）を推定することは困難であった。特に、事業者ネットワーク内で当該事業者が把握できない故障、つまり、サービスに障害が発生しているにもかかわらず、事業者ネットワーク内で故障が検知されないサイレント故障の場合、より問題は深刻となる。

例えば、図１９に示すように、サービス提供事業者が、アクセスネットワーク事業者Ａ、コアネットワーク事業者、クラウド事業者Ａを介して、サービス利用者にサービスを提供しているとする。この場合において、そのサービスに障害が発生すると、複数の他事業者の設備を利用しているため、特に事業者側から故障情報がないときに、どこが故障原因かを把握することが困難となる。

この問題を解決するため、非特許文献１に記載の故障箇所推定手法が提案されている。
非特許文献１に記載の故障箇所推定手法では、図２０（ａ）に示すように、まず、複数の事業者と跨ったエンドツーエンド（Ｅ２Ｅ）の品質を示すようなサービス監視情報（以下、「Ｅ２Ｅ監視情報」と称する場合がある。）を収集する。次に、警報が監視された区間について、事業者毎の区間に分解する。図２０（ａ）では、ノード「Ａ」−「Ｄ」間を、事業者Ａ、事業者Ｂ、事業者Ｃの区間に分解した例を示している。続いて、事業者内の簡易トポロジ（３階梯（全国、県単位、市町村単位））を用いて、通過ノードに、被疑ポイントを加算する。この処理を、サービス監視情報毎に実行する。そして、最も被疑ポイントの多い箇所を故障被疑箇所と推定するものである。

図２０（ｂ）に示す例では、ネットワーク事業者Ａ，Ｂ，Ｃのノードのうち、最も被疑ポイントが多い、ネットワーク事業者Ａのノードｘ（５４ポイント）が故障被疑箇所と推定される。
また、被疑ポイントが多い箇所が複数存在する場合には、以下のようにして故障被疑箇所を推定する。
図２０（ｃ）に示すように、上位ノード（ノードｙ_１）と下位ノード（ノードｙ_２，ｙ_３）のすべてが同じ最大値の被疑ポイントである場合には、上位ノード（ノードｙ_１）を故障被疑箇所とする。これは、下位ノード（ノードｙ_２，ｙ_３）の被疑ポイントが高いのは、上位ノード（ノードｙ_１）が故障していることの影響であると推定されるためのである。
図２０（ｄ）に示すように、上位ノード（ノードｚ_１）とその下位に属する一部のノード（ノードｚ_２）のみが被疑ポイントの最大値を有する場合には、一部の下位ノード（ノードｚ_２）を故障被疑箇所とする。これは、上位ノード（ノードｚ_１）の被疑ポイントが高いのは、下位ノード（ノードｚ_２）が故障していることの影響であると推定されるためである。

大西浩行、尾居愛子、「Ｂ２Ｂ２Ｘサービスにおける故障個所推定方法」、電子情報通信学会、２０１５年電子情報通信学会通信ソサイエティ大会、２０１５年９月、Ｂ−１４−６

しかしながら、非特許文献１に記載の故障箇所推定手法では、推定した故障被疑箇所と各ネットワーク事業者からの障害発生通知や性能情報とを突き合わせ、より適切に（精度よく）故障箇所を推定する手法は提案されていない。そのため、故障被疑箇所の推定後に、ネットワーク事業者等からの障害発生通知や性能情報を受信したときには、それらと故障被疑箇所とをさらに突き合わせて最終的に故障箇所を特定することや、その影響範囲の算出、サービス提供事業者への通知等は、オペレータが行う必要があった。

また、非特許文献１に記載の故障箇所推定手法では、ネットワーク事業者内のノード構成（ネットワークトポロジ）を推定するために、あらかじめ３階梯のツリー型ネットワーク構成モデルを仮定し、被疑ポイントの同一性から、ツリー構造を随時更新していく手法（詳細は後記する。）を用いる。しかしながら、このツリー型ネットワーク構成モデルの更新は、故障発生に伴うサービス監視情報を収集してなされるため、正しいツリー構成になるまでに時間を要し、その間の故障被疑箇所の推定（以下、「被疑箇所推定」と称する。）が精度よくできないという問題があった。
さらに、非特許文献１に記載の故障箇所推定手法では、図２１に示すような、１つのサービスに関して複数の事業者ネットワークを経由する可能性がある場合では、いろいろなネットワーク事業者の組み合わせパターンのサービスが想定できるため、故障被疑箇所を１つに特定することが難しく、また、絞り込みにも多くのサンプルを要する問題があった。

このような背景に鑑みて本発明がなされたのであり、本発明は、１つ以上の事業者ネットワークを利用して通信サービスを提供する通信ネットワークにおいて、より精度よく故障箇所を推定することができる、故障解析装置、故障解析プログラムおよび故障解析方法を提供することを課題とする。

前記した課題を解決するため、請求項１に記載の発明は、１つ以上の事業者ネットワークを利用してサービス提供事業者がサービスを提供する通信ネットワークにおいて、前記サービスの故障を解析する故障解析装置であって、前記サービスのエンドツーエンドの性能に関する情報を示すサービス監視情報、および、前記サービスが利用する前記１つ以上の事業者ネットワークの一部区間の監視情報を示す部分監視情報を取得する情報取得部と、前記サービス監視情報および前記部分監視情報を記憶する記憶部と、前記サービス監視情報、前記部分監視情報のそれぞれが異常情報であるか正常情報であるかを所定のロジックを用いて判定するサービス異常判定部と、前記サービス監視情報、前記部分監視情報のそれぞれが監視対象とする前記通信ネットワーク内の区間において、前記サービス監視情報、前記部分監視情報のそれぞれが異常情報であると判定された場合に、当該区間における仮定のノード構成に基づき設定された前記サービスが利用する区間を分割した分割区間に被疑ポイントを加算し、前記サービス監視情報、前記部分監視情報のそれぞれが正常情報であると判定された場合に、当該分割区間に正常ポイントを加算し、前記被疑ポイントの合計と前記正常ポイントの合計とに基づき、前記分割区間について被疑度合に応じた順位付けを行い、故障被疑箇所を推定する情報解析部と、を備えることを特徴とする故障解析装置とした。

また、請求項６に記載の発明は、１つ以上の事業者ネットワークを利用してサービス提供事業者がサービスを提供する通信ネットワークにおいて、前記サービスの故障を解析する故障解析装置の故障解析方法であって、前記故障解析装置が、前記サービスのエンドツーエンドの性能に関する情報を示すサービス監視情報、および、前記サービスが利用する前記１つ以上の事業者ネットワークの一部区間の監視情報を示す部分監視情報を取得し、記憶手段に記憶するステップと、前記サービス監視情報、前記部分監視情報のそれぞれが異常情報であるか正常情報であるかを所定のロジックを用いて判定するステップと、前記サービス監視情報、前記部分監視情報のそれぞれが監視対象とする前記通信ネットワーク内の区間において、前記サービス監視情報、前記部分監視情報のそれぞれが異常情報であると判定された場合に、当該区間における仮定のノード構成に基づき設定された前記サービスが利用する区間を分割した分割区間に被疑ポイントを加算し、前記サービス監視情報、前記部分監視情報のそれぞれが正常情報であると判定された場合に、当該分割区間に正常ポイントを加算し、前記被疑ポイントの合計と前記正常ポイントの合計とに基づき、前記分割区間について被疑度合に応じた順位付けを行い、故障被疑箇所を推定するステップと、を実行することを特徴とする故障解析方法とした。

このようにすることで、故障解析装置は、サービスのエンドツーエンドの性能に関する情報を示すサービス監視情報だけでなく、通信ネットワークの一部区間の監視情報を示す部分監視情報を含めて被疑箇所推定を実行するため、より精度よく故障被疑箇所を推定することが可能となる。

請求項２に記載の発明は、前記推定された故障被疑箇所および当該故障被疑箇所を利用するサービスの情報を含むトラブルチケット情報を発行し、前記発行したトラブルチケット情報と、前記故障被疑箇所を示す被疑箇所推定情報と、前記サービス監視情報および前記部分監視情報と、を関連付けるサービス状態管理部を、さらに備えることを特徴とする請求項１に記載の故障解析装置とした。

このようにすることで、故障解析装置は、トラブルチケット情報と、被疑箇所推定情報と、サービス監視情報および部分監視情報と、を関連付けることができる。よって、障害が発生したサービスの影響範囲の把握や、障害発生の通知をより的確に行うことが可能となる。

請求項３に記載の発明は、前記情報取得部は、前記事業者ネットワークから故障エリアを含む異常情報を取得し、前記記憶部に記憶し、前記サービス状態管理部は、前記故障被疑箇所と前記異常情報の前記故障エリアが一部でも重なる場合に、前記異常情報と、前記被疑箇所推定情報と、前記トラブルチケット情報と、前記サービス監視情報および前記部分監視情報と、を関連付けることを特徴とする請求項２に記載の故障解析装置とした。

このようにすることで、故障解析装置は、事業者ネットワークから取得した異常情報で示される故障エリアと、故障被疑箇所が一部でも重なる場合に、同一の故障原因であるとして、その異常情報と、被疑箇所推定情報と、トラブルチケット情報と、サービス監視情報および部分監視情報と、を関連付けることができる。よって、障害が発生したサービスの影響範囲の把握や、障害発生の通知をより的確に行うことが可能となる。

請求項４に記載の発明は、前記仮定のノード構成を、前記事業者ネットワークのノードそれぞれの位置情報を用いて更新する構成情報更新部を、さらに備えることを特徴とする請求項１ないし請求項３のいずれか１項に記載の故障解析装置とした。

このようにすることで、故障解析装置は、ネットワーク内のノード構成をより現実に近いものに設定した上で、被疑箇所推定を行うことができる。よって、故障被疑箇所の推定にかかる時間を低減させ、より精度よく故障箇所を推定することが可能となる。

請求項５に記載の発明は、コンピュータを、請求項１乃至請求項４のいずれか一項に記載の故障解析装置として機能させるための故障解析プログラムとした。

このようにすることで、一般的なコンピュータを、請求項１乃至４のいずれか一項に記載の故障解析装置として機能させることができる。

本発明によれば、１つ以上の事業者ネットワークを利用して通信サービスを提供する通信ネットワークにおいて、より精度よく故障箇所を推定する、故障解析装置、故障解析プログラムおよび故障解析方法を提供することができる。

本実施形態に係る故障解析装置を含む故障解析システムの全体構成を示す図である。 本実施形態に係る故障解析装置の構成例を示す機能ブロック図である。 本実施形態に係る故障解析装置の情報取得設定部が設定する情報取得設定情報のデータ構成例を示す図である。 事業者ネットワーク内に配置される装置が送信する警報情報の通知パターンを説明するための図である。 本実施形態に係る故障解析装置の情報取得部が、異常情報の通知を正規化した上で取得することを説明するための図である。 本実施形態に係る故障解析装置の情報取得部が取得する性能情報のデータ構成例を示す図である。 本実施形態に係る故障解析装置の構成情報更新部が実行する位置情報を用いたノード構成の初期設定を説明するための図である。 本実施形態に係る故障解析装置の構成情報更新部による、ネットワークトポロジの更新について説明するための図である。 本実施形態に係る被疑箇所推定のサービスモデルと区間分割を説明するための図である。 本実施形態に係る被疑箇所推定のサービスモデルと区間分割を説明するための図である。 本実施形態に係る故障解析装置の情報解析部が生成する被疑箇所推定情報のデータ構成例を示す図である。 本実施形態に係る故障解析装置のサービス状態管理部が発行するトラブルチケット情報のデータ構成例を示す図である。 本実施形態に係る故障解析装置の情報取得部が各ネットワーク内のＯｐＳ等から受信する異常情報のデータ構成例を示す図である。 本実施形態に係る故障解析装置の全体の処理の流れを示すフローチャートである。 本実施形態に係る故障解析装置が実行する異常確認処理の流れを示すフローチャートである。 本実施形態に係る故障解析装置が実行する異常確認処理の流れを示すフローチャートである。 本実施形態に係る故障解析装置が実行する異常回復確認処理の流れを示すフローチャートである。 本実施形態に係る故障解析装置のサービス状態管理部により関連付けられた各情報を説明するための図である。 Ｂ２Ｂ２Ｘモデルの通信サービスにおける課題を説明するための図である。 従来技術の被疑箇所推定を説明するための図である。 従来技術の被疑箇所推定の問題点を説明するための図である。

次に、本発明を実施するための形態（以下、「本実施形態」という）における故障解析装置１等について説明する。

＜概要＞
図１は、本実施形態に係る故障解析装置１を含む故障解析システム１０００の全体構成を示す図である。
本実施形態に係る故障解析システム１０００は、複数のネットワーク事業者２０（図１においては、アクセスネットワーク事業者２０ａ（「Ａ」，「Ｂ」）、コアネットワーク事業者２０ｂ、クラウド事業者２０ｃ（「Ａ」，「Ｂ」））と、そのネットワーク事業者２０のネットワーク（事業者ネットワーク）を利用してユーザにサービスを提供するサービス提供事業者１０と、故障解析装置１とを含んで構成される。
故障解析装置１は、サービス提供事業者１０と各ネットワーク事業者２０との間で通信可能に接続される。なお、図１に示す、アクセスネットワーク事業者２０ａ、コアネットワーク事業者２０ｂ、クラウド事業者２０ｃ等の個々の事業ネットワークを管理する事業者をまとめて、上記のように、ネットワーク事業者２０と称する。
この故障解析装置１が実行する処理は、Ｂ２Ｂ２Ｘモデルにおいて、複数のネットワーク事業者２０のリソースを組み合わせてサービスを提供するアーキテクチャ（連携機能部）が備える機能の一部としてもよい。

本実施形態に係る故障解析装置１は、サービス提供事業者１０若しくは上記した連携機能部（以下、「サービス提供事業者１０等」と称する。）から取得したサービス監視情報（Ｅ２Ｅ監視情報）と、一部区間の監視情報（以下、「部分監視情報」と称する。詳細は後記する。）とを組み合わせることにより、より精度の高い故障被疑箇所推定を行う。さらに、故障解析装置１は、故障被疑箇所の推定結果と、各ネットワーク事業者２０からの障害発生通知（異常情報）とを突合させ、より正確な故障による影響範囲の把握や通知を可能とする。
具体的には、故障解析装置１は、ネットワーク事業者２０から障害発生通知（異常情報）が出ていない場合において、サービス提供事業者１０等からサービス障害に関するサービス監視情報を受信したときに、そのサービスの提供において利用されるどのネットワーク事業者２０のどのエリア（ノード）が原因であるかを特定するための被疑箇所推定を行う。そして、故障解析装置１は、被疑箇所推定によって絞り込んだネットワーク事業者２０に対して、トラブルチケット（詳細は後記する。）を発行し、詳細な障害発生箇所と障害発生原因の調査を依頼する。

また、故障解析装置１は、ネットワーク事業者２０から受信した障害発生通知（異常情報）で示される故障エリアと、被疑箇所推定によって絞り込んだ被疑エリアとが一部でも重なる場合には、その障害発生の原因が同一事象であるとみなし、その異常情報とトラブルチケットと被疑箇所推定の情報（後記する「被疑箇所推定情報」）とを関連付ける。これにより、故障原因、その影響の及ぶエリア、そのネットワーク事業者２０、そして、影響が及ぶサービスに関する情報（サービスＩＤ等）を関連付けて把握し、サービス提供事業者１０や各ネットワーク事業者２０に通知することができる。

さらに、故障解析装置１は、障害が復旧し、ネットワーク事業者２０から、異常回復情報を取得した場合に、該当サービスや該当エリアにおきてcloseされていない（閉じられていない）トラブルチケットが存在する場合に、その異常回復情報に関連付けて、トラブルチケットをcloseする。つまり、故障解析装置１は、障害が復旧（回復）したことを把握し、サービス提供事業者１０や各ネットワーク事業者２０に通知することができる。

また、従来技術では、事業ネットワーク内のノード構成（ネットワークトポロジ）をあらかじめ３階梯のツリー型ネットワーク構成モデルとして仮定し被疑箇所推定をしていたのに対し、本実施形態に係る故障解析装置１では、ネットワーク利用契約の申込時に取得した各ネットワーク事業者の拠点における住所情報や、性能情報取得時に一緒に取得した位置情報（GeoLocation API等を利用して取得）を用いて、そのネットワーク事業者内におけるトポロジについてのノードの割り当てを行う。これにより、より現実に近いノード構成（ネットワークトポロジ）を初期状態とし、各ネットワーク事業者のノード構成モデルを設定できる。よって、従来よりも短時間で、より現実に近い事業者内のノード構成を把握することが可能となる。

そして、故障解析装置１は、対象となるサービスを複数の構成区間に分割し、性能情報（性能異常情報および性能正常情報）を用いて、区間ごとに被疑ポイントおよび正常ポイントを加算することで、各区間の被疑度合を算出する。その際、クラウドＡＰＩ等から取得できる情報などの部分的な監視情報（部分監視情報）も利用する。これにより、より正確に被疑箇所を推定することが可能となる。

＜故障解析装置＞
次に、本実施形態に係る故障解析装置１について説明する。故障解析装置１は、複数のネットワーク事業者２０を利用したサービスに関する故障を解析し、故障箇所（故障ノードや故障エリア）を推定し、当該故障に関係するサービス提供事業者１０やネットワーク事業者２０等に通知を行う装置である。
なお、以下の説明においては、サービス提供事業者１０は１事業者として説明するが、複数の事業者であってもよい。複数のサービス提供事業者１０の場合であっても、それぞれのサービス提供事業者１０に対し、以下において説明する処理を同様に実行する。
また、以下の説明においては、複数のネットワーク事業者２０を利用したサービスを前提として説明するが、１つのネットワーク事業者２０であってもよく、その場合であっても、故障解析装置１が、サービス監視情報や部分監視情報等を用いて、被疑箇所を推定することができる。特に、装置側から異常情報があがってこないサイレント故障の場合に有効となる。

図２は、本実施形態に係る故障解析装置１の構成例を示す機能ブロック図である。故障解析装置１は、入出力部１１と、制御部１２と、記憶部１３とを備える。

入出力部１１は、通信回線を介して情報の送受信を行う通信インタフェースと、不図示のキーボード等の入力手段やモニタ等の出力手段等との間で情報の入出力を行う入出力インタフェースとから構成される。
この入出力部１１を介して、故障解析装置１は、サービス提供事業者１０、ログ収集サーバ３０、各ネットワーク事業者２０等との間で、性能情報や、警報情報、各種の通知等の送受信を行う。なお、ログ収集サーバ３０については、後記する。

ここで、故障解析装置１が取得する情報の定義について説明する。
本実施形態において、サービス提供事業者１０等から得られる、当該サービス提供事業者１０がユーザに提供するサービスの性能に関する情報を「性能情報」と称する。この性能情報には、後記する異常判定の結果に基づき、正常値と判定される「性能正常情報」と、異常値と判定される「性能異常情報」とがある。また、各ネットワーク事業者２０から送信されてくる警報情報、故障発生情報等を単に「異常情報」と称する。このサービス提供事業者１０等からの「性能情報」と、各ネットワーク事業者２０からの「異常情報」とを併せて、「異常関連情報」と称する場合がある。

記憶部１３は、ハードディスクや、フラッシュメモリ、ＲＡＭ（Random Access Memory）等の記憶手段からなり、情報取得設定情報１００、性能情報２００、被疑箇所推定情報３００、トラブルチケット情報４００、異常情報５００等を含む各情報が記憶される。なお、これらの各情報の詳細は後記する。また、この記憶部１３には、後記するサービス異常判定部１２３が用いる性能情報の異常判定のための所定のロジックや、後記するサービス状態管理部１２６が、性能情報２００、被疑箇所推定情報３００、トラブルチケット情報４００、異常情報５００それぞれを対応付けるための情報（詳細は後記する図１８参照）が格納される。

制御部１２は、故障解析装置１全体の制御を司り、情報取得設定部１２１と、情報取得部１２２と、サービス異常判定部１２３と、構成情報更新部１２４と、情報解析部１２５と、サービス状態管理部１２６とを含んで構成される。
なお、この制御部１２は、例えば、記憶部１３に格納されたプログラム（故障解析プログラム）をＣＰＵ（Central Processing Unit）が不図示のＲＡＭに展開し実行することで実現される。

情報取得設定部１２１は、サービス提供事業者１０やネットワーク事業者２０等から、性能情報や異常情報等の異常関連情報を取得する際の、情報取得元（情報取得内容）、取得契機、取得間隔を設定する。

図３は、本実施形態に係る故障解析装置１の情報取得設定部１２１が設定する情報取得設定情報１００のデータ構成例を示す図である。
図３に示すように、情報取得設定情報１００には、レイヤ、種別、情報取得元（情報取得内容）、取得契機、取得間隔等の各項目が格納される。
ここで、「レイヤ」は、取得先のレイヤ（階層）を示し、例えば、「複数事業者間」、「１事業者」、「ＩＰ（レイヤ）」「イーサ（レイヤ）」「伝送（レイヤ）」の各レイヤが設定される。なお、「複数事業者間」のレイヤから取得する情報に、複数の事業者を跨ったエンドツーエンド（Ｅ２Ｅ）の品質を示すサービス監視情報（Ｅ２Ｅ監視情報）が含まれる。また、「１事業者」のレイヤから取得する情報に、一部区間の監視情報（部分監視情報）が含まれる。
「種別」には、「性能情報」、「異常情報」、「位置情報」等が設定される。
「情報取得元」には、その情報の取得元となるＡＰＩ（Application Programming Interface）や、各事業者ネットワークを管理するＯｐＳ（Operation System）が取得元として設定される。
「取得契機」には、ユーザがそのサービスを利用する毎（「ユーザアクセス契機」）や、所定の時間間隔で取得することを示す「定期取得」、異常やその異常箇所の検証のためにその時々で行われることを示す「随時取得」、対象とするネットワーク事業者２０側を契機として送信されてくることを示す「通知」等が設定される。
「取得間隔」には、取得契機において、「定期取得」が設定された場合における、その時間間隔が格納される。

例えば、情報取得元が「Navigation Timing API」は、Ｗｅｂページの読み込み時間に関し、ユーザ端末からサーバを通ってユーザ端末に戻ってくるまでの一連の時間を取得するＡＰＩである。よって、この情報を監視することにより、性能劣化を判断することができる。なお、この「Navigation Timing API」の情報は、故障解析システム１０００内に設けられたログ収集サーバ３０（図２参照）において収集される。故障解析装置１は、ログ収集サーバ３０で収集された「Navigation Timing API」の情報を取得する。
また、「GeoLocation API」は、ユーザ端末やサーバの位置情報を取得するためのＡＰＩである。この位置情報は、ネットワーク事業者のサーバ構成の初期設定に利用する（詳細は後記）。
「CloudWatch API」は、ＡＷＳ（Amazon Web Services（商標））が提供するＡＰＩであり、例えばクラウド区間内の往復の処理時間等が取得できる。
「PM/SQM API」は、パフォーマンス情報やサービス品質情報を収集するＡＰＩである。
「TroubleTicket API」は、ネットワーク内で発生した障害に関する情報を記録し、そのネットワークの状況や作業の進行状況を把握するためのＡＰＩである。
「SLA Management API」は、サービス品質保証に関しネットワーク事業者やクラウド事業者が、その保証契約に違反（品質劣化）した場合に、その内容を通知するためのＡＰＩである。
その他、故障解析装置１は、ＩＰレイヤ、イーサレイヤ、伝送レイヤにおける各ネットワーク内の装置から、異常を示す情報の有無を定期取得したり、必要に応じて随時取得したりすることができる。

情報取得部１２２は、情報取得設定部１２１が設定した情報取得設定情報１００に基づき、性能情報や、異常情報等の異常関連情報、異常回復情報を取得し、記憶部１３に記憶する。
この情報取得部１２２は、後記する情報解析部１２５による被疑箇所推定によって絞り込んだ被疑エリアを持つネットワーク事業者に対して、異常が発生しているか否かを確認する要求（異常確認要求）を送信することにより、性能情報や異常情報を随時取得することもできる。

また、情報取得部１２２は、複数の事業者ネットワーク内に存在する様々な装置の警報情報の通知パターンに対応して、その通知パターン毎に、当該装置の状況を把握（当該通知を適正に受信）するための機能を備える。以下、ネットワーク内の各装置の警報情報の通知パターンを説明し、情報取得部１２２が、警報情報を正規化した上で取得する機能を備えることを説明する。

図４は、事業者ネットワーク内に配置される装置が送信する警報情報の通知パターンを説明するための図である。
図４（ａ）は、正常・故障にかかわらず、常に装置状態が所定の時間間隔で（定期的に）通知されるパターンである。
図４（ｂ）は、故障時にのみ警報が定期的に通知されるパターンである。
図４（ｃ）は、正常時にのみ警報が定期的に通知されるパターンである。
図４（ｄ）は、故障発生時に警報が通知され、その故障警報に対応する回復時に回復報が通知されるパターンである。
図４（ｅ）は、故障発生時にのみ警報が通知され、その故障警報に対応する回復時には、回復報が通知されないパターンである。
図４（ｆ）は、故障発生時に警報は通知されず、故障が回復し正常起動時に通知があるパターンである。

図４（ａ）〜（ｆ）に示すように、各装置若しくはそれを設定する事業者によって、異常情報を通知するパターンが異なる。よって、複数のネットワーク事業者２０の各装置からの警報情報を取得する故障解析装置１は、警報情報の認証や解析が煩雑になってしまう。そこで、情報取得部１２２は、装置や事業者を予め登録しておくことに加えて、上記の通知パターンのうちのどのパターンに該当するかを判別する機能を備えるとともに、異常情報の通知パターンの違いを吸収する機能（メディエータ）を備えるものとする。

図５は、本実施形態に係る故障解析装置１の情報取得部１２２が、異常情報の通知を正規化した上で取得することを説明するための図である。
図５（ａ）は、図４（ａ）の通知パターンに対応している。ここでは、メディエータが、定期的に受信する通知の時間間隔を学習しておき、直前の通知と内容が同じであれば、単なる定期的なメッセージとみなし、情報取得部１２２には出力しない処理を行う。また、故障中においても、定期的に受信する通知の時間間隔を学習しておき、直前の通知と内容が同じであれば、単なる定期的なメッセージとみなし、情報取得部１２２には出力しない処理を行う。

図５（ｂ）は、図４（ｂ）の通知パターンに対応している。ここでは、メディエータが、故障中において、定期的に受信する通知の時間間隔を学習しておき、直前の通知と内容が同じであれば、定期的なメッセージとみなし、情報取得部１２２には出力しない処理を行う。さらに、メディエータは、定期的に通知されるはずの故障通知が受信できない場合に、ステータスが変わったと判定し、正常通知を情報取得部１２２に出力する。

図５（ｃ）は、図４（ｃ）の通知パターンに対応している。ここでは、メディエータが、正常時において、定期的に受信する通知の時間間隔を学習しておき、直前の通知と内容が同じであれば、定期的なメッセージとみなし、情報取得部１２２には出力しない処理を行う。さらに、メディエータは、定期的に通知されるはずの正常通知が受信できない場合に、ステータスが変わったと判定し、異常通知を情報取得部１２２に出力する。

図５（ｄ）は、図４（ｄ）の通知パターンに対応している。ここでは、メディエータが、特に正規化を行わず、故障発生時に受信した異常通知を情報取得部１２２に出力し、その異常通知に対応する回復時に受信した正常通知を情報取得部１２２に出力する。

図５（ｅ）は、図４（ｅ）の通知パターンに対応している。ここでは、メディエータが、複数のネットワーク事業者間でのエンドツーエンド（Ｅ２Ｅ）での監視（図５においては、「Ｅ２Ｅ監視」と称する。）が正常に戻ったときに、対象の装置から正常通知が受信できなければ、メディエータが当該装置に対し試験を行い、正常を確認して正常通知を情報取得部１２２に出力する。

図５（ｆ）は、図４（ｆ）の通知パターンに対応している。ここでは、メディエータが、複数のネットワーク事業者間でのエンドツーエンドでの監視が異常となったときに、対象の装置から異常通知を受信できなければ、メディエータが当該装置に対し試験を行い、異常を確認して異常通知を情報取得部１２２に出力する。

このように、情報取得部１２２は、ネットワーク事業者２０等から受信する各装置からの警報の通知パターンをメディエータにより正規化して取得することができる。よって、故障情報や正常情報を適切に把握することが可能となる。

図２に戻り、サービス異常判定部１２３は、サービス提供事業者１０等から性能情報を受信した場合に、その性能情報に示される測定値（例えば、処理時間や、トラフィック量、ＣＰＵ使用率、メモリ使用率等）を参照し、その性能情報で示される値が異常か正常かを判定（以下、「異常判定」と称する。）する。
このサービス異常判定部１２３による異常判定は、既存の技術を利用することができる。例えば、ある対象となる測定値に閾値を設定し、その閾値を上回る若しくはその閾値以下の場合に、異常と判定するようにしてもよい。その他にも、複数の関連するデータの相関係数を用いて、相関係数が所定値以下の場合に、異常と判定してもよい。また、ＬＯＦ（Local Outlier Factor）も用いて、データの密度を考慮し、他の点と比べて密度が小さいことをもって異常と判定してもよい。なお。ＬＯＦについては、参考文献（M.M.Breunig, et.al., “LOF : Identifying Density-Based Local Outliers,”In Proceedings of the ACM SIGMOD International Conference on Management of Data. ACM Press, 2000）に詳しい。

なお、サービス異常判定部１２３は、後記する図６のように、異常と判定した性能情報については、異常フラグを「ＦＡＬＳＥ」とすることにより、その性能情報に判定結果を紐付ける。そして、サービス異常判定部１２３により、異常と判定された性能情報が、「性能異常情報」である。一方、サービス異常判定部１２３が、異常と判定しなかった、つまり、正常であると判定した性能情報が、「性能正常情報」である。

図６は、情報取得部１２２が取得する性能情報２００のデータ構成例を示す図である。
性能情報２００には、図６に示すように、受信した各性能情報について、性能情報ＩＤ、サービスＩＤ、そのサービスの始点、終点、始点の緯度経度、計測値、異常フラグ等の情報が格納される。サービス異常判定部１２３は、異常判定した結果を、異常フラグの項目に、「ＦＡＬＳＥ」（異常）または「ＴＲＵＥ」（正常）として格納する。

図２に戻り、構成情報更新部１２４は、故障箇所を推定するための前提となる各事業者ネットワークのノード構成（ネットワークトポロジ）を、後記する位置情報を用いて、より最適に初期設定した上で、サービス監視情報（性能異常情報・性能正常情報）に基づき、更新し精度を高める。
具体的には、図７（ｃ）および図２０で示すような、比較例である非特許文献１に記載の故障箇所推定手法においては、事業者内のネットワークトポロジについて、一般的な３階梯（全国、県単位、市町村単位）の簡易モデルを適用している。本実施形態における故障解析装置１の構成情報更新部１２４は、ネットワーク事業者の契約時（申込時）の拠点の住所情報や性能情報取得時に一緒に取得できる位置情報を用いて、事業者内の構成におけるノードの割り当てを、より実際のトポロジに近い配置に設定する。なお、性能情報取得時においては、例えば、GeoLocation API等（以下、「位置情報取得機能」と称する。）を用いて、対象となるノードの位置情報（緯度・経度）を取得することが可能である。

構成情報更新部１２４は、図７（ａ）に示すような位置情報を、契約時の拠点情報若しくは位置情報取得機能を用いて取得し、同じ都道府県であれば１つのノード（県単位代表ノード）の下に配置する。例えば、図７（ｂ）に示すように、拠点１（練馬区）に位置するノードと、拠点２（武蔵野市）に位置するノードは、同じ東京都代表ノードの配下に配置する。拠点３（千葉市）のノードと、拠点４（札幌市）のノードは、同じ県単位代表ノードの配下に配置するのではなく、別々の県単位代表ノード配下に設置する。このように、各ノードの位置情報を予め取得することにより、明らかに異なる地域に配置されているノードを、異なる県単位代表ノードの配下として初期設定することができる。

構成情報更新部１２４は、上記のようにして初期設定したネットワークトポロジを用いて、非特許文献１に記載の故障箇所推定手法と同様の被疑ポイントを用いた故障被疑箇所の推定を行うことにより、ネットワークトポロジをより実際の構成に近いものに更新する処理を実行する。
具体的には、構成情報更新部１２４は、まず、図２０において示した非特許文献１に記載の故障箇所推定手法と同様の手法により、サービス監視情報における通過ノードに、被疑ポイントを加算する処理を行い、それをサービス監視情報毎に繰り返し実行する。そして、最も被疑ポイントの多い箇所を故障被疑箇所と推定する。以下、ネットワークトポロジの更新例について説明する。

図８は、本実施形態に係る故障解析装置１の構成情報更新部１２４による、ネットワークトポロジの更新について説明するための図である。ここで、構成情報更新部１２４の上記した位置情報に基づき、図８（ａ）に示すネットワークトポロジ（ノード構成）が初期設定されたものとする。なお、図８において、「ＡＫ」は全国を束ねるノード（親ノード）、「ＡＬ」は県単位のノード（子ノード）、「ＡＭ」は市町村単位のノード（孫ノード）を示す。

ここで、図８（ａ）に示すトポロジを用いて、サービス毎に故障被疑箇所推定を行った場合に、最も被疑ポイントが多い箇所の発生パターンとして以下に示すケースが生じる場合がある。
・ノードＡＬ１，ＡＭ１，ＡＭ２の被疑ポイントのみがともに最大値となるような故障（例えば、ノードＡＬ１，ＡＭ１，ＡＭ２の被疑ポイントが５４ポイントで最大値、ノードＡＬ２，ＡＭ３，ＡＭ４の被疑ポイントは３６ポイント）が発生している。
・ノードＡＬ２，ＡＭ３，ＡＭ４の被疑ポイントのみがともに最大値となるような故障（例えば、ノードＡＬ２，ＡＭ３，ＡＭ４の被疑ポイントが５４ポイントで最大値、ノードＡＬ１，ＡＭ１，ＡＭ２の被疑ポイントは３６ポイント）が発生している。
・ノードＡＬ１，ＡＬ２，ＡＭ１，ＡＭ２，ＡＭ３，ＡＭ４の被疑ポイントがともに最大値となるような故障（例えば、ノードＡＬ１，ＡＭ１，ＡＭ２，ＡＬ２，ＡＭ３，ＡＭ４の被疑ポイントが５４ポイントで最大値）が発生している。
このようなケースでは、構成情報更新部１２４は、親ノードＡＫ１と子ノードＡＬ１，ＡＬ２との間に、子ノードＡＬ１，ＡＬ２を束ねる１．５次階梯となるノードＡＮ１があると推定する（図８（ｂ）参照）。これにより、構成情報更新部１２４は、事業者内のネットワークトポロジを更新する。

また、図８（ａ）に示すトポロジにおいて、最も被疑ポイントが多い箇所の発生パターンとして、以下に示すケースが生じる場合がある。
・ノードＡＬ３，ＡＬ４，ＡＭ５，ＡＭ６，ＡＭ７，ＡＭ８の被疑ポイントがともに最大値となるような故障（例えば、ノードＡＬ３，ＡＭ５，ＡＭ６，ＡＬ４，ＡＭ７，ＡＭ８の被疑ポイントが５４ポイントで最大値）が発生している。
・ノードＡＬ３，ＡＭ５，ＡＭ６の被疑ポイントのみがともに最大値となるような故障（例えば、ノードＡＬ３，ＡＭ５，ＡＭ６の被疑ポイントが５４ポイントで最大値、ノードＡＬ４，ＡＭ７，ＡＭ８の被疑ポイントは３６ポイント）は発生していない。
・ノードＡＬ４，ＡＭ７，ＡＭ８の被疑ポイントのみがともに最大値となるような故障（例えば、ノードＡＬ４，ＡＭ７，ＡＭ８の被疑ポイントが５４ポイントで最大値、ノードＡＬ３，ＡＭ５，ＡＭ６の被疑ポイントは３６ポイント）は発生していない。
このようなケースでは、構成情報更新部１２４は、子ノードＡＬ３，ＡＬ４が一つの子ノードＡＬ５であると推定する（図８（ｃ）参照）。構成情報更新部１２４は、子ノードＡＬ３，ＡＬ４に代えて孫ノードＡＭ５，ＡＭ６，ＡＭ７，ＡＭ８を束ねる子ノードＡＬ５を有するネットワークトポロジに更新する。

以上のようにすることで、構成情報更新部１２４は、サービス監視情報を用いて、事業者ネットワークのノード構成を、正確なネットワークトポロジとして更新することができる。

図２に戻り、情報解析部１２５は、本実施形態に係る被疑箇所推定を行い、性能情報、異常情報、および、トラブルチケット情報の突合を行い、当該故障の影響範囲を算出する。
本実施形態に係る情報解析部１２５が行う被疑箇所推定は、非特許文献１に記載の故障箇所推定手法において、事業者間を跨った監視情報（サービス監視情報）のみを用いて故障箇所を推定していたのと異なり、サービス監視情報に加えて、各ネットワーク事業者から送信される１事業者内（一部区間）の監視情報（部分監視情報）も組み合わせて被疑箇所推定を行うことにより、より精度の高い故障箇所の推定を行うことを特徴とする。以下、具体的に説明する。

（被疑箇所推定手順）
情報解析部１２５は、以下に示すステップに沿って処理を実行する。なお、ここで想定するサービスとしては、図９に示すように、エンドユーザが、ネットワーク事業者「１」、ネットワーク事業者「２」、クラウド事業者「１」を介して、クラウド上のアプリケーション（ＡＰＬ）であるＷｅｂサーバにアクセスするというモデルとする。また、このサービスにおいて、クラウド上のサーバ内の何れかで異常が発生し、サービスに影響がでているものとする。

・ＳＴＥＰ１：対象とするサービスについて、それを構成する「区間」に分割する。
ここでは、サービス１が、区間ｅ_１，ｅ_２，…，ｅ_９で構成されるものとする。区間ｅ_１，ｅ_２，…，ｅ_９は、図９で示すように、それぞれユーザ端末内、ネットワーク事業者「１」区間、ネットワーク事業者「２」区間、クラウド事業者「１」区間、サーバ内に対応する。なお、図９および後記する図１０において、分割された区間（分割区間）を「ｅ」で表わし、ノードを「ｖ」で表わす。また、図９の説明では、ユーザ端末から送信される、クラウド事業者内のサーバ側のＡＰＬに対するリクエストに基づき、ＡＰＬからユーザ端末にレスポンスが返信されるモデルであるため、各区間には上りと下りの２つの向きがある。さらに、図９においては、以下の説明を平易にするため、ネットワーク事業者やクラウド事業者の区間を１つとしているが、情報解析部１２５による実際の処理においては、構成情報更新部１２４により更新された最新のネットワークトポロジ（ノード構成）を用いて、図１０のネットワーク事業者「２」内において例示するように、さらに細かい区間に分割して処理を行う。これにより、故障被疑箇所をより正確に特定することが可能となる。
なお、ここでは、Ｗｅｂサーバにアクセス（Ｗｅｂページ閲覧）を例として説明するが、例えば、ＩＰ電話サービス、動画配信サービス等のそれぞれのサービスに応じて、区間の設定に関するテンプレートを用意しておき、「区間」の分割処理を効率化するようにしてもよい。このテンプレートは、故障解析装置１の記憶部１３に記憶される。

・ＳＴＥＰ２：ＳＴＥＰ１で定義した区間（分割区間）を用い、各監視情報（性能異常情報）に対して、被疑となる区間ごとに１ポイントずつ被疑ポイントを付与する。
情報解析部１２５は、複数の事業者を跨ったサービス監視情報と１事業者内（一部区間）の監視情報（部分監視情報）を統一的に表現するために、異常を示す情報ｎ（以下、「異常監視情報ｎ」と称する。）を表わすベクトルＡ_ｎを定義する。Ａ_ｎの要素数は区間の数であり、その１つの要素である要素ｍは、区間ｅ_ｍが被疑であれば「１」、そうでなければ「０」とする。例えば、異常監視情報１として、Ｗｅｂページの読み込み時間の異常がある場合、被疑区間は区間ｅ_１，…，ｅ_９とのなる（図９の異常監視情報「１」参照）。異常監視情報「２」として、クラウド内の応答遅延がある場合には、被疑区間は、区間ｅ_４，ｅ_５，ｅ_６となる。また、異常監視情報「３」として、クラウド上のサーバの流出トラフィック量に異常がある場合には、その上流である、区間ｅ_１，…，ｅ_５が被疑区間となる。これらをベクトルで表現すると、式（１）〜式（３）となる。

Ａ_１ ＝ ［１ １ １ １ １ １ １ １ １］ … 式（１）
Ａ_２ ＝ ［０ ０ ０ １ １ １ ０ ０ ０］ … 式（２）
Ａ_３ ＝ ［１ １ １ １ １ ０ ０ ０ ０］ … 式（３）

・ＳＴＥＰ３：被疑ポイントを合計することで、区間ごとの被疑度合を表わす異常ポイントとする。
情報解析部１２５は、ＳＴＥＰ２で算出した被疑ポイントを区間ごとに合計することにより、区間ごとの被疑度合を示す異常ポイントＡを算出する。
Ａ ＝ ΣＡ_ｉ ＝ ［２ ２ ２ ３ ３ ２ １ １ １］ … 式（４）

・ＳＴＥＰ４：異常ポイントが付与された区間のうち、正常であることがわかっている区間については被疑度合が低いと考えられるため、被疑区間の並べ替えにより優先度付けを行う。
具体的には、情報解析部１２５は、ＳＴＥＰ４−１として、ＳＴＥＰ２およびＳＴＥＰ３と同様に、正常であることを示す情報（例えば、性能正常情報であり、ここでは、正常を示す情報を「正常監視情報」と称する。）についても、区間ごとに正常度合を示す正常ポイントを算出する。例えば、図９の正常監視情報「１」として、クラウド上のサーバへの流入トラフィック量が正常値である場合には、正常ポイントＮは、以下の式（５）で表わされる。
Ｎ ＝ ΣＮ_ｉ ＝ ［１ １ １ １ ０ ０ ０ ０ ０］ … 式（５）

ＳＴＥＰ４−２として、情報解析部１２５は、異常ポイントＡおよび正常ポイントＮに基づき、区間ｅ_１，…，ｅ_９について被疑の高い順に並べ替えを行う。この際、異常ポイントＡが付与された区間のうち、正常であることがわかっている区間（正常ポイントＮが付与された区間）については、被疑度合を低くするため、以下のルールに基づいて被疑区間の並べ替えを行う。

（ルール１）
異常ポイントＡのうち、正常ポイントＮが「０」である要素（すなわち、正常を示す情報がない区間）について、降順にソートする。なお、値が同一の場合は、上流側の優先度を高くする。
（ルール２）
異常ポイントＡのうち、正常ポイントＮが「０」でない要素（すなわち、正常を示す情報がある区間）について、降順にソートする。なお、値が同一の場合は、正常ポイントＮの値が低い方の優先度を高くする。正常ポイントＮの値も同一の場合は、上流側の優先度を高くする。

情報解析部１２５は、ＳＴＥＰ４の結果として、各区間を被疑度合の高い順に並べると、以下の式（６）となる。
Ｅ ＝ ［ｅ_５ ｅ_６ ｅ_７ ｅ_８ ｅ_９ ｅ_４ ｅ_１ ｅ_２ ｅ_３］ … 式（６）
このように、情報解析部１２５は、被疑ポイントの合計と正常ポイントの合計とに基づき、各区間（分割区間）について被疑度合に応じた順位付けを行う。この各区間を被疑度合の高い順に並べた情報を「被疑箇所リスト」として、以下において説明する。情報解析部１２５は、被疑箇所推定の結果として、この被疑箇所リストを生成し、記憶部１３に記憶する。
そして、情報解析部１２５は、被疑度合が最も高い区間（ここでは、区間ｅ_５、すなわちサーバ内区間）を被疑箇所（以下、「被疑エリア」とも称する。）と推定する。また、情報解析部１２５は、被疑エリアのネットワーク事業者２０等に、後記するサービス状態管理部１２６が、推定した被疑箇所（被疑エリア）についての故障を問い合わせた結果、当該推定した被疑箇所（被疑エリア）に故障がないことがわかった場合には、被疑度合の順位が次に高い区間（ここでは、区間ｅ_６、すなわちクラウド事業者「１」内）を被疑箇所（被疑エリア）と推定して処理することができる。このように情報解析部１２５は、被疑度合の高い順に、被疑箇所（被疑エリア）を順次推定することにより、正確な故障箇所を効率良く（短時間で）特定することが可能となる。なお、情報解析部１２５は、この被疑箇所リストにおいて、最上位から所定の順位までを、被疑箇所（被疑エリア）として推定し、処理するものとして予め設定しておく。

情報解析部１２５は、上記のＳＴＥＰ１〜４により被疑箇所推定した故障区間（被疑エリア）とそのサービスとを関連付けた被疑箇所推定情報３００を生成し、記憶部１３（図２参照）に記憶する。

図１１は、情報解析部１２５が生成する被疑箇所推定情報３００のデータ構成例を示す図である。
被疑箇所推定情報３００には、図１１に示すように、情報解析部１２５が被疑箇所推定した結果として、被疑箇所推定ＩＤ、被疑箇所ＩＤ、サービスＩＤ、被疑エリア等の情報が格納される。
被疑箇所推定ＩＤは、情報解析部１２５が被疑箇所推定を行う度に付される、１つの被疑箇所推定毎の固有の識別子である。被疑箇所ＩＤは、被疑区間（被疑エリア）に対応した固有の識別子である。サービスＩＤは、被疑箇所推定したサービスの識別子である。被疑エリアは、被疑箇所推定の結果として得られた最も被疑度合の高い区間を示す情報である。

図２に戻り、サービス状態管理部１２６は、情報解析部１２５が生成した被疑箇所推定情報３００に基づき、トラブルチケット（後記する図１２参照）を発行するとともに、その被疑箇所推定情報と各性能情報および異常情報を関連付けることによって、当該サービス故障の影響範囲を特定する。そして、当該サービス故障に関して、その原因として推定された被疑エリア等の情報を、サービス提供事業者１０と、当該被疑エリアのネットワーク事業者２０等に通知する。なお、この際、当該エリアのネットワーク事業者２０から、故障箇所（故障エリア）および故障原因を特定する情報（異常情報：後記する図１３参照）を受信した場合には、その情報がより正確であると判定し、その情報をサービス提供事業者１０に通知する。
また、サービス状態管理部１２６は、被疑エリア若しくは故障エリアのネットワーク事業者２０等から、当該故障が回復したエリア（回復エリア）が付された異常回復情報を受信した場合には、当該故障について発行したトラブルチケットをclosed状態にするとともに、その異常回復情報をサービス提供事業者１０に通知する。

図１２は、サービス状態管理部１２６が発行するトラブルチケット情報４００のデータ構成例を示す図である。このトラブルチケット情報４００は、ネットワーク上に発生した障害に関する情報を記録し、当該ネットワークの状況や作業の進行状況をネットワークの管理者等が把握するための情報である。トラブルチケット情報４００には、図１２に示すように、トラブルチケットＩＤ、ステータス、サービスＩＤ等の情報が格納される。
トラブルチケットＩＤは、サービス状態管理部１２６が発行した各トラブルチケットに固有の識別子である。ステータスは、対象となるサービスについての故障の進行状況が格納される。例えば、「In Progress」（調査進行中）、「Acknowledged」（承認）、「Closed」（終了）等がある。サービスＩＤには、故障の対象となるサービスのサービスＩＤが格納される。

図１３は、故障解析装置１の情報取得部１２２が各ネットワーク内のＯｐＳ等から受信する異常情報５００のデータ構成例を示す図である。
この異常情報５００には、図１３に示すように、異常情報ＩＤ、タイプ、サービスＩＤ、故障エリア、内容等の情報が格納される。
異常情報ＩＤは、各装置等において障害が発生するごとに付される固有の識別子である。タイプは、当該異常情報の種別を示し、例えば、「SLA Violation」は、サービス品質保証に関する違反を通知する情報であることを示す。また、「ＰＭ」は、個々のネットワーク機器の性能異常（パフォーマンス情報）を示す。サービスＩＤは、当該故障の対象となるサービスの識別子である。故障エリアは、当該故障の故障箇所（故障区間）を示す。また、内容は、当該故障の故障内容（故障原因）が格納される。

＜処理の流れ＞
次に、故障解析装置１の処理の流れについて説明する。
なお、故障解析装置１は、各ネットワーク事業者２０のＯｐＳ等から、障害の発生等を検知したことを示す異常情報５００（図１３参照）を随時受信し、記憶部１３内に格納しているものとする。また、故障解析装置１の構成情報更新部１２４は、各ネットワーク事業者やクラウド事業者との間の契約時の情報や、GeoLocation API等を用いた位置情報取得機能に基づき、各ネットワークのノード構成（ネットワークトポロジ）の初期状態を設定しておくものとする。

図１４は、本実施形態に係る故障解析装置１の全体の処理の流れを示すフローチャートである。
図１４に示すように、まず、故障解析装置１の情報取得設定部１２１は、サービス提供事業者１０やネットワーク事業者２０等から、性能情報や異常情報等の異常関連情報を取得する際の、情報取得元（情報取得内容）、取得契機、取得間隔などを、情報取得設定情報１００（図３参照）として設定する（ステップＳ１０）。そして、情報取得設定部１２１は、その情報取得設定情報１００を記憶部１３に記憶しておく。

次に、故障解析装置１の情報取得部１２２は、情報取得設定部１２１が設定した情報取得設定情報１００に基づき、エンドツーエンド（Ｅ２Ｅ）でのサービスに関するサービス監視情報（性能情報）や、１事業者内（一部区間）の監視情報（部分監視情報）を、記憶部１３に記憶しておく（ステップＳ２０）。
この各情報を取得する際に、情報取得部１２２は、上記したように、各情報の通知パターンに応じて、その警報情報を正規化して取得するようにしてもよい。

続いて、サービス異常判定部１２３は、所定のロジックに基づき、受信した性能情報２００を参照し、その性能情報２００（図６参照）で示される計測値が異常か否かの判定（異常判定）を行う（ステップＳ３０）。そして、サービス異常判定部１２３は、異常と判定した性能情報２００については、異常フラグを「ＦＡＬＳＥ」とする。これによりその性能情報２００は、「性能異常情報」と識別される。一方、サービス異常判定部１２３は、異常と判定しなかった性能情報２００、つまり正常と判定した性能情報２００については、異常フラグを「ＴＲＵＥ」とする。これによりその性能情報２００は、「性能正常情報」と識別される。

続いて、サービス異常判定部１２３は、ステップＳ３０において、異常と判定した性能情報２００、つまり性能異常情報と判定した性能情報があったか否かを判定する（ステップＳ４０）。ここで、異常と判定された性能情報２００がなかった場合には（ステップＳ４０→Ｎｏ）、ステップＳ７０に進む。一方、異常と判定された性能情報があった場合には（ステップＳ４０→Ｙｅｓ）、次にステップＳ５０に進む。

ステップＳ５０において、故障解析装置１の構成情報更新部１２４は、ステップＳ３０において性能異常情報と判定された情報を用いて、その性能異常情報における通過ノードに、被疑ポイントを加算する処理を行い、最も被疑ポイントの多い箇所を決定することにより、構成情報の更新を行う。これにより、故障解析装置１は、各ネットワーク事業者２０の構成情報を、より正確なノード構成（ネットワークトポロジ）に更新した上で、故障被疑箇所を推定することが可能となる。

続いて情報解析部１２５は、事業者間を跨ったサービス監視情報（Ｅ２Ｅ監視情報）と１事業者内（一部区間）の監視情報（部分監視情報）とを用いて、被疑箇所推定を行う（ステップＳ６０）。この際、情報解析部１２５は、上記したように、性能異常情報だけでなく、性能正常情報も用いて、被疑度合の高い順に被疑エリアを算出する（被疑箇所リストを生成する）ことにより、被疑度合の高い区間順に、被疑エリアとして推定することができる。
なお、情報解析部１２５は、被疑度合の高い区間順に、被疑エリアを推定する際に、情報取得部１２２を介して、その被疑エリアが存在する事業者内（一部区間）の管理情報（部分監視情報）を再要求（随時取得）してもよい。情報解析部１２５は、例えば、CloudWatch APIや、PM/SQM API等を用いて各性能情報を再要求（随時取得）し、再度ステップＳ６０の被疑箇所推定を行うことにより、被疑エリアを絞り込むことができる。

そして、情報解析部１２５は、推定した被疑エリアの情報を用いて、被疑箇所推定情報３００（図１１参照）を生成し記憶部１３に記憶する。さらに、情報解析部１２５は、生成した被疑箇所推定情報３００と、性能異常情報および性能正常情報との関連付けを行う。具体的には、後記する図１８に示す、性能情報−被疑箇所対応情報２５０を生成し記憶部１３に記憶する。

次に、故障解析装置１のサービス状態管理部１２６は、各ネットワーク事業者２０等からの異常情報５００（図１３参照）等に基づく、異常確認処理（ステップＳ７０）と、同じく各ネットワーク事業者２０等からの異常回復情報等に基づく、異常回復確認処理（ステップＳ８０）を実行して処理を終える。
この異常確認処理（ステップＳ７０）については、後記する図１５および図１６を参照して詳細に説明する。また、異常回復確認処理（ステップＳ８０）については、後記する図１７を参照して詳細に説明する。なお、この異常確認処理（ステップＳ７０）と異常回復確認処理（ステップＳ８０）は、図１４に示すように、ステップＳ７０，Ｓ８０の順で逐次処理してもよいし、並行処理してもよい。

＜異常確認処理＞
図１５および図１６は、本実施形態に係る故障解析装置１が実行する異常確認処理の流れを示すフローチャートである。

まず、図１５に示すように、故障解析装置１のサービス状態管理部１２６は、各ネットワーク事業者２０等からの異常情報５００（図１３）を受信しているか否かを判定する（ステップＳ７０１）。ここで、異常情報５００を受信していない場合は、図１６のステップＳ７２０に進む。一方、異常情報５００を受信している場合には、ステップＳ７０２に進む。

ステップＳ７０２において、サービス状態管理部１２６は、その異常情報５００を参照して、故障エリアを抽出する。そして、その故障エリアに対応する被疑箇所推定情報３００があるか否かを判定する。つまり、サービス状態管理部１２６は、被疑箇所推定情報３００を参照し、異常情報５００で示されるサービスＩＤと同一のサービスＩＤであり、異常情報５００で示される故障エリアと、同一若しくは一部でも重なる対象エリア（被疑エリア）を持つ被疑箇所推定情報３００があるか否かを判定する。なお、サービス状態管理部１２６は、ステップＳ６０（図１４）の被疑箇所推定で生成された被疑箇所リストのうちの最上位の被疑箇所についての被疑箇所推定情報３００を、最初の判定の対象とする。
そして、サービス状態管理部１２６は、異常情報５００で示される故障エリアに対応する被疑箇所推定情報３００がある場合には（ステップＳ７０２→Ｙｅｓ）、その異常情報５００と、被疑箇所推定情報３００との関連付けを行う（ステップＳ７０３）。そして、ステップＳ７０４に進む。

次に、サービス状態管理部１２６は、ステップＳ７０４〜Ｓ７０９において、異常情報５００で示される故障エリアと、被疑箇所推定情報３００で示される被疑エリアと重なった故障箇所それぞれについて、処理を繰り返す。

ステップＳ７０５において、サービス状態管理部１２６は、当該故障に関連するcloseされていない既存のトラブルチケット情報４００（図１２参照）があるか否かを判定する。そして、既存のトラブルチケット情報４００がある場合には（ステップＳ７０５→Ｙｅｓ）、異常情報５００とトラブルチケット情報４００との関連付けを行う（ステップＳ７０６）。具体的には、後記する図１８に示す、トラチケ−異常情報対応情報４５０を生成し記憶部１３に記憶する。

一方、既存のトラブルチケット情報４００がない場合には（ステップＳ７０５→Ｎｏ）、サービス状態管理部１２６は、新規のトラブルチケット情報４００を発行する（ステップＳ７０７）。つまり、新たなトラブルチケット情報４００を生成する。
続いて、サービス状態管理部１２６は、故障による影響箇所を算出し、サービス提供事業者１０や関係するネットワーク事業者２０に通知する（ステップＳ７０８）。そして、すべての故障箇所について処理を行い（ステップＳ７０４〜Ｓ７０９）、異常確認処理を終了する。

一方、サービス状態管理部１２６は、ステップＳ７０２において、異常情報５００に示される故障エリアに対応する被疑箇所推定情報３００がない場合には（ステップＳ７０２→Ｎｏ）、ステップＳ７１０に進む。

ステップＳ７１０において、サービス状態管理部１２６は、ステップＳ７０２において異常情報５００で示される故障エリアとの対応を判定した被疑箇所推定情報３００の被疑箇所（被疑エリア）が、被疑箇所リストについて設定された最上位からの所定の順位における最下位であるか否かを判定する。
ここで、サービス状態管理部１２６は、最下位であれば（ステップＳ７１０→Ｙｅｓ）、被疑箇所（被疑エリア）についての処理がすべて終わったものとして処理を終了する。一方、サービス状態管理部１２６は、最下位でなければ（ステップＳ７１０→Ｎｏ）、被疑箇所リストにおいて、現時点で設定されている被疑箇所の１つ下位の被疑箇所（被疑エリア）を選択する（ステップＳ７１１）。そして、サービス状態管理部１２６は、選択した被疑箇所の被疑箇所推定情報３００について、ステップＳ７０２に戻り処理を続ける。

次に、ステップＳ７０１において、サービス状態管理部１２６が、異常情報５００を受信していない場合（ステップＳ７０１→Ｎｏ）以降の処理ついて、図１６を参照して説明する。

まず、サービス状態管理部１２６は、ステップＳ６０において生成された被疑箇所推定情報３００があるか否かを判定する（ステップＳ７２０）、ここで、生成された被疑箇所推定情報３００がない場合（ステップＳ７２０→Ｎｏ）、つまり、故障解析装置１が性能異常情報を受信していない場合には、故障解析装置１は、異常確認処理を終了する。一方、被疑箇所推定情報がある場合には（ステップＳ７２０→Ｙｅｓ）、ステップＳ７２１に進む。

次に、サービス状態管理部１２６は、ステップＳ７２１〜Ｓ７２６において、ステップＳ７２０で存在を確認した被疑箇所推定情報３００で示される被疑箇所（被疑エリア）それぞれについて、処理を繰り返す。

ステップＳ７２２において、サービス状態管理部１２６は、当該被疑箇所に関連するcloseされていない既存のトラブルチケット情報４００（図１２参照）があるか否かを判定する。そして、既存のトラブルチケット情報４００がある場合には（ステップＳ７２２→Ｙｅｓ）、被疑箇所推定情報３００と既存のトラブルチケット情報４００との関連付けを行う（ステップＳ７２３）。具体的には、後記する図１８に示す、トラチケ−被疑箇所推定対応情報３５０を生成し記憶部１３に記憶する。

一方、既存のトラブルチケット情報４００がない場合には（ステップＳ７２２→Ｎｏ）、サービス状態管理部１２６は、新規のトラブルチケット情報４００を発行する（ステップＳ７２４）。つまり、新たなトラブルチケット情報４００を生成する。
続いて、サービス状態管理部１２６は、被疑箇所推定情報３００の被疑箇所（被疑エリア）に基づき影響箇所を算出し、サービス提供事業者１０や関係するネットワーク事業者２０に通知する（ステップＳ７２５）。そして、すべての被疑箇所（被疑エリア）について処理を行い（ステップＳ７２１〜Ｓ７２６）、異常確認処理を終了する。

＜異常回復確認処理＞
次に、図１４のステップＳ８０において実行される異常回復確認処理について説明する。
図１７は、本実施形態に係る故障解析装置１が実行する異常回復確認処理の流れを示すフローチャートである。

まず、故障解析装置１のサービス状態管理部１２６は、closeされていない既存のトラブルチケット情報４００（図１２参照）を抽出する（ステップＳ８０１）。

次に、サービス状態管理部１２６は、ステップＳ８０２〜Ｓ８１２において、ステップＳ８０１で抽出したトラブルチケット情報４００に紐付く被疑箇所推定情報３００の被疑箇所（被疑エリア）それぞれについて、処理を繰り返す。なお、トラチケ−被疑箇所推定対応情報３５０（図１８）を参照することにより、トラブルチケット情報４００に紐付く被疑箇所推定情報３００の被疑箇所（被疑エリア）を特定することができる。

続いて、サービス状態管理部１２６は、当該被疑箇所（被疑エリア）についての異常回復情報を受信しているか否かを判定する（ステップＳ８０３）。ここで、異常回復情報を受信している場合には（ステップＳ８０３→Ｙｅｓ）、ステップＳ８０４に進む。

ステップＳ８０４において、サービス状態管理部１２６は、その異常回復情報を参照して、故障が回復したエリア（回復エリア）と抽出する。そして、その回復エリアについて、図１４のステップＳ６０における被疑箇所推定において推定結果が正常とされた被疑箇所（対象エリア）があるか否かを判定する。ここで、被疑箇所推定において推定結果が正常とされた被疑箇所（対象エリア）は、例えば、被疑箇所リストにおいて、最上位から所定の順位までとして設定された被疑箇所（被疑エリア）以外の各区画において、被疑度合の低い順に所定の順位までを、推定結果が正常である対象エリアとして設定する。

そして、サービス状態管理部１２６は、被疑箇所推定の推定結果が正常とされた対象エリアがない場合は（ステップＳ８０４→Ｎｏ）、ステップＳ８０６に進む。一方、サービス状態管理部１２６は、被疑箇所推定の推定結果が正常とされた対象エリアがある場合は（ステップＳ８０４→Ｙｅｓ）、異常回復情報と被疑箇所推定の推定結果を関連付けて（ステップＳ８０５）、次のステップＳ８０６に進む。

ステップＳ８０６において、サービス状態管理部１２６は、処理対象とした被疑箇所（被疑エリア）の被疑箇所推定情報３００に関する既存のトラブルチケット情報４００をcloseする（ステップＳ８０６）。
続いて、サービス状態管理部１２６は、故障回復に伴う影響箇所を算出し、サービス提供事業者１０や関係するネットワーク事業者２０に通知する（ステップＳ８０７）。そして、すべての被疑箇所について処理が終わったかを確認し（ステップＳ８１２）、終わっていない場合に、ステップＳ８０２戻る。

一方、サービス状態管理部１２６は、ステップＳ８０３において、異常回復情報を受信していない場合には（ステップＳ８０３→Ｎｏ）、ステップＳ８０８に進む。
ステップＳ８０８において、サービス状態管理部１２６は、図１４のステップＳ６０における被疑箇所推定において推定結果が正常とされた被疑箇所（対象エリア）があるか否かを判定する。ここで、推定結果が正常とされた被疑箇所（対象エリア）がない場合は（ステップＳ８０８→Ｎｏ）、ステップＳ８１２に進む。一方、推定結果が正常とされた被疑箇所（対象エリア）がある場合は（ステップＳ８０８→Ｙｅｓ）、次のステップＳ８０９へ進む。

ステップＳ８０９において、サービス状態管理部１２６は、推定結果が正常とされた被疑箇所（対象エリア）の被疑箇所推定情報３００に関するトラブルチケット情報４００に、異常情報が紐付いているか否かを判定する。ここで、異常情報が紐付いている場合には（ステップＳ８０９→Ｙｅｓ）、サービス状態管理部１２６は、ネットワーク事業者２０等からの異常情報が存在するため、トラブルチケット情報４００をcloseする処理を行わず、ステップＳ８１２に進む。

一方、サービス状態管理部１２６は、異常情報が紐付いていない場合には（ステップＳ８０９→Ｎｏ）、処理対象とした被疑箇所（被疑エリア）の被疑箇所推定情報３００に関する既存のトラブルチケット情報４００をcloseする（ステップＳ８１０）。
続いて、サービス状態管理部１２６は、故障回復に伴う影響箇所を算出し、サービス提供事業者１０や関係するネットワーク事業者２０に通知する（ステップＳ８１１）。そして、すべての被疑箇所について処理が終わったかを確認し（ステップＳ８１２）、異常回復確認処理を終了する。

図１８は、本実施形態に係る故障解析装置１のサービス状態管理部１２６により関連付けられた各情報を説明するための図である。
図１８に示すように、性能情報２００と被疑箇所推定情報３００とが、性能情報−被疑箇所対応情報２５０により対応付けられる。性能情報−被疑箇所対応情報２５０は、性能情報ＩＤに被疑箇所推定ＩＤが紐付けられる情報である。
また、被疑箇所推定情報３００と、トラブルチケット情報４００とが、トラチケ−被疑箇所推定対応情報３５０により対応付けられる。トラチケ−被疑箇所推定対応情報３５０は、トラブルチケットＩＤに、被疑箇所推定ＩＤおよび被疑箇所ＩＤが紐付けられる情報である。
さらに、トラブルチケット情報４００と異常情報５００とは、トラチケ−異常情報対応情報４５０により対応付けられる。トラチケ−異常情報対応情報４５０は、トラブルチケットＩＤに、異常情報ＩＤが紐付けられる情報である。
このように、性能情報２００に基づき生成した被疑箇所推定情報３００と、トラブルチケット情報４００と、異常情報５００とが関連付けられることにより、障害の発生に伴い影響を受けるサービスやその影響範囲の把握が容易となる。

以上説明したように、本実施形態に係る故障解析装置１、故障解析プログラムおよび故障解析方法によれば、サービス提供事業者１０等から取得したサービス監視情報（Ｅ２Ｅ監視情報）と、一部区間の監視情報（部分監視情報）とを用いて、故障箇所推定の解析時間を低減するとともに、より精度の高い被疑箇所推定を行うことができる。さらに、故障解析装置１は、故障被疑箇所の推定結果を示す被疑箇所推定情報３００、トラブルチケット情報４００、サービス監視情報および部分監視情報（性能情報２００）、異常情報５００をそれぞれ関連付けることができる。よって、障害が発生したサービスの影響範囲の把握や、障害発生の通知をより的確に行うことが可能となる。

１ 故障解析装置
１０ サービス提供事業者
１１ 入出力部
１２ 制御部
１３ 記憶部
２０ ネットワーク事業者
３０ ログ収集サーバ
１００ 情報取得設定情報
１２１ 情報取得設定部
１２２ 情報取得部
１２３ サービス異常判定部
１２４ 構成情報更新部
１２５ 情報解析部
１２６ サービス状態管理部
２００ 性能情報
２５０ 性能情報−被疑箇所対応情報
３００ 被疑箇所推定情報
３５０ トラチケ−被疑箇所推定対応情報
４００ トラブルチケット情報
４５０ トラチケ−異常情報対応情報
５００ 異常情報
１０００ 故障解析システム

Claims (6)

1. １つ以上の事業者ネットワークを利用してサービス提供事業者がサービスを提供する通信ネットワークにおいて、前記サービスの故障を解析する故障解析装置であって、
   前記サービスのエンドツーエンドの性能に関する情報を示すサービス監視情報、および、前記サービスが利用する前記１つ以上の事業者ネットワークの一部区間の監視情報を示す部分監視情報を取得する情報取得部と、
   前記サービス監視情報および前記部分監視情報を記憶する記憶部と、
   前記サービス監視情報、前記部分監視情報のそれぞれが異常情報であるか正常情報であるかを所定のロジックを用いて判定するサービス異常判定部と、
   前記サービス監視情報、前記部分監視情報のそれぞれが監視対象とする前記通信ネットワーク内の区間において、前記サービス監視情報、前記部分監視情報のそれぞれが異常情報であると判定された場合に、当該区間における仮定のノード構成に基づき設定された前記サービスが利用する区間を分割した分割区間に被疑ポイントを加算し、前記サービス監視情報、前記部分監視情報のそれぞれが正常情報であると判定された場合に、当該分割区間に正常ポイントを加算し、前記被疑ポイントの合計と前記正常ポイントの合計とに基づき、前記分割区間について被疑度合に応じた順位付けを行い、故障被疑箇所を推定する情報解析部と、
   を備えることを特徴とする故障解析装置。
2. 前記推定された故障被疑箇所および当該故障被疑箇所を利用するサービスの情報を含むトラブルチケット情報を発行し、前記発行したトラブルチケット情報と、前記故障被疑箇所を示す被疑箇所推定情報と、前記サービス監視情報および前記部分監視情報と、を関連付けるサービス状態管理部を、
   さらに備えることを特徴とする請求項１に記載の故障解析装置。
3. 前記情報取得部は、前記事業者ネットワークから故障エリアを含む異常情報を取得し、前記記憶部に記憶し、
   前記サービス状態管理部は、前記故障被疑箇所と前記異常情報の前記故障エリアが一部でも重なる場合に、前記異常情報と、前記被疑箇所推定情報と、前記トラブルチケット情報と、前記サービス監視情報および前記部分監視情報と、を関連付けること
   を特徴とする請求項２に記載の故障解析装置。
4. 前記仮定のノード構成を、前記事業者ネットワークのノードそれぞれの位置情報を用いて更新する構成情報更新部を、
   さらに備えることを特徴とする請求項１ないし請求項３のいずれか１項に記載の故障解析装置。
5. コンピュータを、請求項１乃至請求項４のいずれか一項に記載の故障解析装置として機能させるための故障解析プログラム。
6. １つ以上の事業者ネットワークを利用してサービス提供事業者がサービスを提供する通信ネットワークにおいて、前記サービスの故障を解析する故障解析装置の故障解析方法であって、
   前記故障解析装置は、
   前記サービスのエンドツーエンドの性能に関する情報を示すサービス監視情報、および、前記サービスが利用する前記１つ以上の事業者ネットワークの一部区間の監視情報を示す部分監視情報を取得し、記憶手段に記憶するステップと、
   前記サービス監視情報、前記部分監視情報のそれぞれが異常情報であるか正常情報であるかを所定のロジックを用いて判定するステップと、
   前記サービス監視情報、前記部分監視情報のそれぞれが監視対象とする前記通信ネットワーク内の区間において、前記サービス監視情報、前記部分監視情報のそれぞれが異常情報であると判定された場合に、当該区間における仮定のノード構成に基づき設定された前記サービスが利用する区間を分割した分割区間に被疑ポイントを加算し、前記サービス監視情報、前記部分監視情報のそれぞれが正常情報であると判定された場合に、当該分割区間に正常ポイントを加算し、前記被疑ポイントの合計と前記正常ポイントの合計とに基づき、前記分割区間について被疑度合に応じた順位付けを行い、故障被疑箇所を推定するステップと、
   を実行することを特徴とする故障解析方法。

Images