(57)【要約】【課題】ネットワーク上で提供されているサービスの自動復旧を実現する。【解決手段】複数のネットワーク装置から収集したフローデータを用いてサービスを監視し、サービスの異常があれば復旧するサービス復旧装置１は、サービスを復旧させるためのネットワーク設定変更を記憶する記憶部３０と、収集したフローデータから得られる定常性からの逸脱度合いを求めることによって、サービスの異常を判定するサービス品質判定部１３と、記憶部３０から、サービスの復旧に寄与するネットワーク設定変更を１または複数組み合わせた対策案を導出する対策案導出部１５と、対策案導出部１５が導出した対策案を、ネットワーク装置が配置されるネットワークに適用する対策案適用部１６と、を備える。【選択図】図２
2018133688.tif 000002
【特許請求の範囲】
【請求項１】
複数のネットワーク装置から収集したフローデータを用いてサービスを監視し、前記サービスの異常があれば復旧するサービス復旧装置であって、
前記サービスを復旧させるためのネットワーク設定変更を記憶する記憶部と、
前記収集したフローデータから得られる定常性からの逸脱度合いを求めることによって、前記サービスの異常を判定する判定部と、
前記記憶部から、前記サービスの復旧に寄与するネットワーク設定変更を１または複数組み合わせた対策案を導出する対策案導出部と、
前記対策案導出部が導出した対策案を、前記ネットワーク装置が配置されるネットワークに適用する対策案適用部と、を備える、
ことを特徴とするサービス復旧装置。
【請求項２】
前記対策案が適用され、前記サービスが復旧した場合に、前記記憶部に記憶されているネットワーク設定変更の評価値を、前記サービスの復旧の寄与に応じて増減させる対策案評価部を備える、
ことを特徴とする請求項１に記載のサービス復旧装置。
【請求項３】
複数のネットワーク装置から収集したフローデータを用いてサービスを監視し、前記サービスの異常があれば復旧するサービス復旧装置におけるサービス復旧方法であって、
前記サービス復旧装置の記憶部が、前記サービスを復旧させるためのネットワーク設定変更を記憶しており、
前記サービス復旧装置は、
前記収集したフローデータから得られる定常性からの逸脱度合いを求めることによって、前記サービスの異常を判定する判定ステップと、
前記記憶部から、前記サービスの復旧に寄与するネットワーク設定変更を１または複数組み合わせた対策案を導出する対策案導出ステップと、
前記対策案導出ステップで導出した対策案を、前記ネットワーク装置が配置されるネットワークに適用する対策案適用ステップと、を実行する、
ことを特徴とするサービス復旧方法。
【請求項４】
前記サービス復旧装置は、
前記対策案が適用され、前記サービスが復旧した場合に、前記記憶部に記憶されているネットワーク設定変更の評価値を、前記サービスの復旧の寄与に応じて増減させる対策案評価ステップ、を実行する、
ことを特徴とする請求項３に記載のサービス復旧方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービス復旧装置およびサービス復旧方法に関する。
【背景技術】
【０００２】
ネットワークの運用管理において、現在提供中のサービスを監視することが非常に重要であり、ネットワーク上で提供されているサービスの異常を検出するさまざまな異常検出方法が従来から知られている。例えば、特許文献１には、「複数のネットワーク装置から収集したフローデータを用いて、サービスを監視するサービス監視装置であって、前記収集したフローデータから、前記サービスに対する、要求トラフィックおよび応答トラフィックを抽出する抽出部と、前記抽出された、要求トラフィックおよび応答トラフィックに基づいて、前記要求トラフィックおよび前記応答トラフィックとの間の定常性を算出する定常性算出部と、特定期間内での前記要求トラフィックおよび前記応答トラフィックとの間の関係性が、前記算出された定常性からどれだけ逸脱しているかによって、前記サービスの品質を判定する判定部と、を備える、ことを特徴とするサービス監視装置」が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１６−１４４１５３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、特許文献１によれば、サービスの異常を検出した場合、サービスの復旧のために、異常の原因分析や対策案の検討、実施といったオペレーションを保守者自ら行う必要がある。このため、サービスの復旧には多くの時間を要してしまう。
【０００５】
このような背景を鑑みて本発明がなされたのであり、本発明は、ネットワーク上で提供されているサービスの自動復旧を実現することを課題とする。
【課題を解決するための手段】
【０００６】
前記した課題を解決するため、請求項１に記載の発明は、複数のネットワーク装置から収集したフローデータを用いてサービスを監視し、前記サービスの異常があれば復旧するサービス復旧装置であって、前記サービスを復旧させるためのネットワーク設定変更を記憶する記憶部と、前記収集したフローデータから得られる定常性からの逸脱度合いを求めることによって、前記サービスの異常を判定する判定部と、前記記憶部から、前記サービスの復旧に寄与するネットワーク設定変更を１または複数組み合わせた対策案を導出する対策案導出部と、前記対策案導出部が導出した対策案を、前記ネットワーク装置が配置されるネットワークに適用する対策案適用部と、を備える、ことを特徴とする。
【０００７】
また、請求項３に記載の発明は、複数のネットワーク装置から収集したフローデータを用いてサービスを監視し、前記サービスの異常があれば復旧するサービス復旧装置におけるサービス復旧方法であって、前記サービス復旧装置の記憶部が、前記サービスを復旧させるためのネットワーク設定変更を記憶しており、前記サービス復旧装置は、前記収集したフローデータから得られる定常性からの逸脱度合いを求めることによって、前記サービスの異常を判定する判定ステップと、前記記憶部から、前記サービスの復旧に寄与するネットワーク設定変更を１または複数組み合わせた対策案を導出する対策案導出ステップと、前記対策案導出ステップで導出した対策案を、前記ネットワーク装置が配置されるネットワークに適用する対策案適用ステップと、を実行する、ことを特徴とする。
【０００８】
請求項１，３に記載の発明によれば、発生したサービスの異常に対して、予め用意したネットワーク設定変更を種々組み合わせた対策案をネットワークに順次適用することができる。
したがって、ネットワーク上で提供されているサービスの自動復旧を実現することができる。
【０００９】
また、請求項２に記載の発明は、請求項１に記載のサービス復旧装置であって、前記対策案が適用され、前記サービスが復旧した場合に、前記記憶部に記憶されているネットワーク設定変更の評価値を、前記サービスの復旧の寄与に応じて増減させる対策案評価部を備える、ことを特徴とする。
【００１０】
また、請求項４に記載の発明は、請求項３に記載のサービス復旧方法であって、前記サービス復旧装置は、前記対策案が適用され、前記サービスが復旧した場合に、前記記憶部に記憶されているネットワーク設定変更の評価値を、前記サービスの復旧の寄与に応じて増減させる対策案評価ステップ、を実行する、ことを特徴とする。
【発明の効果】
【００１１】
本発明によれば、ネットワーク上で提供されているサービスの自動復旧を実現することができる。
【図面の簡単な説明】
【００１２】
【図１】ネットワークの全体構成図である。
【図２】本実施形態のサービス復旧装置の機能構成図である。
【図３】設定変更候補リストのデータ構造図である。
【図４】実行済設定変更リストのデータ構造図である。
【図５】設定変更キューのデータ構造図である。
【図６】本実施形態のサービス復旧装置の処理を示すフローチャートである。
【図７】図６の対策案導出処理の詳細を示すフローチャートである。
【発明を実施するための形態】
【００１３】
＜考え方＞
ＳＤＮ（Software Defined Network）、ＳＤＷＡＮ（Software-Defined Wide Area Networking）、ＡＷＳ（Amazon Web Services。「Amazon」は登録商標）に代表されるクラウドサービスは、SoftwareDefinedの形態でサービスの提供がなされる。この場合、装置交換、パッケージ交換、物理配線の差し替え、とった物理的なオペレーションはとらず、ソフトウェア的オペレーションのみで、サービスの異常からの復旧に必要な制御、例えば、ＮＷの構成変更や設定変更などを実現することができる。このため、サービスを異常状態から復旧させるために、必ずしも保守者が、対策案の検討・実施を行う必要はない。本発明では、サービスの異常状態から復旧するまで、予め定義されたＮＷの設定変更の候補を用いた対策案の導出および適用を行い、サービスの復旧を目指す。ＮＷの設定変更は、単に、「設定変更」または「ネットワーク設定変更」と呼ぶ場合がある。
【００１４】
＜構成＞
図１に示すように、本実施形態のサービス復旧装置１は、ネットワーク装置群Ｇのネットワーク装置２の各々からフローデータを収集し、収集したフローデータを用いて、サーバ３から端末４へ提供中のサービス（図１中の符号Ｘ，Ｙを付した矢印で表現）を監視する。また、サービス復旧装置１は、監視の結果、サービスの異常が検出された場合は、復旧する。フローデータの収集方法は、NetFlow,sFlowなどといった周知の方法である（例えば、参考文献１：B. Claise, "Cisco Systems NetFlow Services Export Version9," IETF RFC3954, October 2004. http://www.ietf.org/rfc/rfc3954や、参考文献２：P. Phaal, S. Panchen, and N. McKee, "InMon Corporation's sFlow:A Method for Monitoring Traffic in Switched and Routed Networks," IETF RFC3176, September 2001. http://www.ietf.org/rfc/rfc3176、などを参照）。
【００１５】
フローデータは、送信元ＩＰアドレス、宛先ＩＰアドレス（または、送信先ＩＰアドレス）、送信元ポート番号、宛先ポート番号（または、送信先ポート番号）、プロトコルの種類、パケット数、バイト数などの情報を一部または全部含む。フローデータの収集は、所定の時間単位で行われ、収集時刻をフローデータに含めることもできる。なお、フローデータの送信元ポート番号または宛先ポート番号を特定することで、サービス品質を判定したい提供中のサービスを特定することができる。
【００１６】
本実施形態のサービス復旧装置１は、例えば、ＩＰＦＩＸ（Internet Protocol Flow Information Export）のフローコレクタとして機能し、ネットワーク装置２の各々からフローデータを収集することができる。
ネットワーク装置２は、例えば、ルータ、ブリッジ、リピータ、ゲートウェイである。ネットワーク装置２は、例えば、ＩＰＦＩＸのフローエクスポータとして機能する。なお、ネットワーク装置群Ｇにおいて、フローエクスポータとして機能しないネットワーク装置２が含まれていてもよい。このようなネットワーク装置２でのトラフィック状態は、フローエクスポータとして機能するネットワーク装置２が提供するフローデータを周知の方法で解析することで間接的に特定することができる。
【００１７】
サーバ３は、例えば、ＤＮＳ(Domain Name System)サーバ３ａ、Ｗｅｂサーバ３ｂ、ＤＢサーバ３ｃであり、端末４に所定のサービスを提供する。なお、サーバ３にフローエクスポータの機能を持たせてもよい。
端末４は、ユーザがサービスを利用するために操作する装置である。なお、端末４にフローエクスポータの機能を持たせてもよい。
ＨＭＩ装置５は、オペレータがサービス復旧装置１を制御するための管理コンソールである。サービス復旧装置１は、ネットワーク装置２から収集したフローデータに基づいて必要に応じて異常通知や復旧通知などをＨＭＩ装置５に出力する。
【００１８】
図２に示すように、本実施形態のサービス復旧装置１は、処理部１０、入出力部２０、および記憶部３０を備える。サービス復旧装置１は、処理部１０の具体例となるＣＰＵが、記憶部３０の具体例となるメモリ上に読み込んだプログラムを実行することにより、各種機能部を動作させる。
【００１９】
処理部１０は、サービス復旧装置１の処理を司る。処理部１０は、トラフィック抽出部１１、定常性算出部１２、サービス品質判定部１３（判定部）、対策案評価部１４、対策案導出部１５、対策案適用部１６、および、結果出力部１７、といった機能部を備える。これらの機能部については後記する。
入出力部２０は、サービス復旧装置１の入出力インターフェースを構成する。入出力部２０は、入力部２１および出力部２２を備える。入力部２１は、ＨＭＩ装置５からの入力やネットワーク装置２からのフローデータなどの取得を行う。出力部２２は、処理部１０による処理結果をファイルｆ等で出力する。
記憶部３０は、所定のデータを所定の形式で記憶する。記憶部３０は、フローデータ保存部３１、定常性データ保存部３２、サービス品質低下状況保存部３３、設定変更候補リスト３４、および、実行済設定変更リスト３５といった機能部を備える。これらの機能部については後記する。
【００２０】
トラフィック抽出部１１は、ネットワーク装置２から収集したフローデータから、提供中の所定のサービスに対する要求トラフィックおよび応答トラフィックを抽出する。
【００２１】
「要求トラフィック」とは、サービスを利用する端末４からサービスを提供するサーバ３へ向けられた、サービス実現に必要な情報である。要求トラフィックを送信する端末４は、フローデータの送信元ＩＰアドレスから識別できる。要求トラフィックを受信するサーバ３は、フローデータの宛先ＩＰアドレスから識別できる。
【００２２】
「応答トラフィック」とは、サービスを提供するサーバ３からサービスを利用する端末４へ向けられた、サービス実現に必要な情報である。応答トラフィックを送信するサーバ３は、フローデータの送信元ＩＰアドレスから識別できる。応答トラフィックを受信する端末４は、フローデータの宛先ＩＰアドレスから識別できる。
【００２３】
定常性算出部１２は、トラフィック抽出部１１が抽出した、要求トラフィックおよび応答トラフィックに基づいて、要求トラフィックおよび応答トラフィックとの間の定常性を算出する。サーバ３から端末４へのサービスの提供が正常に行われている場合、要求トラフィックおよび応答トラフィックの間には一定の傾向が発生し、所定の定常状態が形成されると考えられる。定常性算出部１２が算出する定常性は、この定常状態を定量的に表現したものである。もし、ＤｏＳ（Denial of Service attack）攻撃などによりサーバ３がサービスを提供できない場合には、要求トラフィックに対して、応答トラフィックが極端に少なくなり定常性が破綻しているといえる。
なお、定常性算出部１２による定常性の算出は、所定の単位時間ごとに行われる。また、定常性の算出方法はさまざまであるが、詳細は、特許文献１に記載されており、説明を省略する。本実施形態では、定常性の算出方法は、特許文献１に記載ものを用いるとするが、これに限定されない。
【００２４】
サービス品質判定部１３は、特定期間内での要求トラフィックおよび応答トラフィックの間の関係性が、定常性算出部１２が算出した定常性からどれだけ逸脱しているかによって、サービスの品質を判定する。「特定期間」とは、例えば、定常性算出部１２が定常性を算出する際に対象とした期間よりも後の期間とすることができる。「要求トラフィックおよび応答トラフィックの間の関係性」は、定常性算出部１２が算出した定常性と同じ物理量で表現される。サービス品質判定部１３が用いる関係性と、定常性算出部１２が算出した定常性との逸脱度合いが大きいほどサービスの品質が低下しているとする。例えば、ＤｏＳ攻撃などが発生している場合、サービス品質判定部１３が用いる関係性が、定常性算出部１２が算出した定常性よりも大きく逸脱するため、対象とするサービスの品質は低下していると判定することができる。
【００２５】
対策案評価部１４は、対策案適用部１６が対策案を適用することによって、異常状態であったサービスが正常である（復旧した）と（サービス品質判定部１３によって）判定された場合、適用された対策案を評価する。
対策案導出部１５は、設定変更候補リスト３４を参照して、異常状態のサービスを復旧するための対策案を導出する。
対策案適用部１６は、対策案導出部１５が導出した対策案を、ネットワーク装置２が配置されるネットワークに適用する。
【００２６】
結果出力部１７は、サービスの異常からの復旧のために実行した対策案に関する詳細データを出力する。詳細データには、例えば、対象とするサービスを提供しているサーバ３のホスト名、そのサービスを利用する端末４の数、異常を検出した箇所、実行したＮＷの設定変更の内容など、さまざまなデータが含まれる。ＨＭＩ装置５は、サービス復旧装置１を制御して、オペレータが所望する詳細データを取得することができる。また、出力部２２は、取得した詳細データを処理部１０による処理結果としてファイルｆ等で出力する。
【００２７】
フローデータ保存部３１は、サービス復旧装置１が収集したフローデータを所定の形式で保存する。トラフィック抽出部１１は、フローデータ保存部３１にアクセスして要求トラフィックおよび応答トラフィックの抽出を行う。
定常性データ保存部３２は、定常性算出部１２が算出した定常性を所定の形式で保存する。
サービス品質低下状況保存部３３は、例えば、サービス品質判定部１３によってサービス品質が低下していると判定されたサービスに関する詳細データ（サービス品質低下状況を表現するデータを含む）を所定の形式で保存する。
【００２８】
設定変更候補リスト３４は、サービスの異常状態を解消するための候補となるＮＷの設定変更の一覧を保存する。設定変更候補リスト３４が保存する設定変更の各々は、対策案導出部１５が導出する対策案の構成要素となる。設定変更候補リスト３４が保存する設定変更の各々は、例えば、保守者が事前に定義することもできるし、運用時に適宜修正、更新することもできる。
【００２９】
図３に示すように、設定変更候補リスト３４は、「項番」、「変更内容」、「変更方法」、「制約事項」、「保守者の判断待ちフラグ」、「評価値（優先度）」といった欄を有し、設定変更の種類ごとにエントリが作成されるように構成することができる。
「項番」の欄には、設定変更の各々を識別する番号が登録される。
「変更内容」の欄には、対応する設定変更の説明が登録される。
「変更方法」の欄には、対応する変更内容を実行するためのソフトウェア的オペレーションが登録される。
【００３０】
「制約事項」の欄には、対応する設定変更を実行する際の制約が登録される。
「保守者の判断待ちフラグ」の欄には、対応する設定変更を実行するために保守者の判断を要することを示す値「１：確認要」または保守者の判断を要しないことを示す値「０：確認不要」が登録される。
「評価値（優先度）」の欄には、対応する設定変更に付与された評価値が登録される。登録される評価値は、対策案評価部１４が決定する。評価値は、例えば、０〜１の値をとる。
【００３１】
実行済設定変更リスト３５は、異常状態のサービスを復旧するために実行したＮＷの設定変更の一覧を保存する。具体的には、対策案適用部１６が適用した対策案を構成する設定変更が実行済設定変更リスト３５に保存される。対策案を構成する設定変更は１つでもよいし複数でもよい。
【００３２】
図４に示すように、実行済設定変更リスト３５は、「項番」、「日時」、「設定変更内容」といった欄を有し、設定変更内容ごとにエントリが作成されるように構成することができる。
「項番」の欄には、対応する設定変更内容を識別する記号が登録される。
「日時」の欄には、対応する設定変更内容が実行された年月日時分秒（ＪＳＴ：Japan Standard Time）が登録される。
「設定変更内容」の欄には、対策案適用部１６が適用した対策案を構成する設定変更の項番（図４の設定変更候補リスト３４に示す項番）が登録される。
なお、実行済設定変更リスト３５に登録されるエントリは、実行の都度、図４中下部に順次登録されるが、実行される設定変更内容の順番について、図４に示すものは１例であり、これに限らない。
【００３３】
対策案導出部１５は、対策案を導出する際、設定変更キュー１５ａを保持することができる。設定変更キュー１５ａは、設定変更の実行または取り消しに関する情報をまとめたキューである。「設定変更の取り消し」とは、変更がなされた設定を変更前に戻すことをいう。
【００３４】
図５に示すように、設定変更キュー１５ａは、項番（設定変更候補リスト３４の項番）と、対応する設定変更の扱い（実行、取り消し）の組のデータを１または複数含む。例えば、図５中「項番３：実行」のキューは、項番３の設定変更（Configの切り替え）を指示するキューである。設定変更キュー１５ａに入力されたデータが古いほど、図６中の下方に位置している。対策案導出部１５が設定変更キュー１５ａを対策案適用部１６に送信し、対策案適用部１６が設定変更キュー１５ａを参照することで、該当する設定変更が古いものから順次実行される。
なお、設定変更キュー１５ａに追加されるキューは、設定変更候補リスト３４に合わせて図５中上部に追加されるが、図５に示すものは１例であり、これに限定されない。
【００３５】
＜処理＞
図６に示すように、本実施形態のサービス復旧装置１は、本実施形態のサービス復旧装置１の処理（全体処理）は以下の通りである。この処理は、ステップＳ１から開始する。
【００３６】
ステップＳ１にて、トラフィック抽出部１１は、収集したフローデータから、要求トラフィックおよび応答トラフィックを抽出する。ステップＳ１の後、ステップＳ２に進む。
【００３７】
ステップＳ２にて、定常性算出部１２は、抽出された、要求トラフィックおよび応答トラフィックの間の定常性を算出する。ステップＳ２の後、ステップＳ３に進む。
【００３８】
ステップＳ３にて、サービス品質判定部１３は、特定期間内での要求トラフィックおよび応答トラフィックとの間の関係性が、定常性算出部１２が算出した定常性からどれだけ逸脱しているかによって、サービスの品質を判定する。なお、サービス品質判定部１３は、サービス品質判定部１３が用いる関係性と、定常性算出部１２が算出した定常性との逸脱度合いに関する閾値となる許容誤差を用いてサービスの品質を判定することができる。許容誤差については、特許文献１に記載されており、説明を省略する。ステップＳ３の後、ステップＳ４に進む。
に進む。
【００３９】
ステップＳ４にて、サービスの品質の低下を引き起こす異常があった場合（Ｙｅｓ）、ステップＳ５に進む。一方、サービスの品質の低下を引き起こす異常が無かった場合（Ｎｏ）、サービスが正常である（サービスが元々正常である、または、異常状態から復旧した）ことを意味し、ステップＳ６に進む。
【００４０】
ステップＳ５にて、対策案導出部１５および対策案適用部１６は、対策案実行処理を実行する。対策案実行処理の詳細は、後記する。結果的には、ネットワークに対して、対策案を構成する設定変更が実行される。ステップＳ５の後、ステップＳ２に戻る。
【００４１】
ステップＳ６にて、対策案評価部１４は、サービスの復旧に対して、設定変更候補リスト３４に保存されている設定変更を評価する。対策案評価部１４は、評価の際、サービス品質低下状況保存部３３が保存する詳細データを参照することができる。詳細データの保存、設定変更の評価の詳細については、後記する。結果的には、設定変更候補リスト３４に保存されている設定変更の各々の「評価値（優先度）」の欄に登録される値が変更する。ステップＳ６の後、本処理を終了する。
【００４２】
図６に示す処理によれば、サービスを監視して異常が発見された場合でも自動復旧することができる。
【００４３】
［対策案実行処理の詳細］
図７に示すように、対策案実行処理（図６のステップＳ５）の詳細は、以下の通りである。この処理は、ステップＡ１から開始する。
【００４４】
ステップＡ１にて、対策案導出部１５は、すべての対策案が実行されたか否かの判定となる終了判定を行う。具体的には、全体処理（図６）１回分を通じて実行済設定変更リスト３５に登録されたことのあるエントリ（ＮＷの設定変更の組合せからなる対策案。）の数が、設定変更候補リスト３４に登録された設定変更を組み合わせて作り出すことができる対策案の数（４Ｃ１＋４Ｃ２−１＋３Ｃ３×２＝１１）よりも多いか否かを判定する。多い場合、対策案導出部１５は、結果出力部１７に「適切な対策案の導出が不可能」を示すメッセージをＨＭＩ装置５に送信し、保守者に通知し、処理を終了する。当該終了をしない場合は、ステップＡ２に進む。
【００４５】
ステップＡ２にて、対策案導出部１５は、許容誤差より大きくサービス品質が変動しているネットワーク装置２についての詳細データを、品質低下が発生している箇所の情報として収集し、サービス品質低下状況保存部３３に保存する。ステップＡ２の後、ステップＡ３に進む。
【００４６】
ステップＡ３にて、対策案導出部１５は、設定変更のリセット処理を行う。具体的には、実行済設定変更リスト３５に登録されたエントリに該当する設定変更の取り消し動作（「項番Ｘ：取り消し」で示すキュー（図５参照））を設定変更キュー１５ａに追加する。ステップＡ３の処理により、別の対策案を実行する際、以前実行した設定変更の影響を除くことができる。ステップＡ３の後、ステップＡ４に進む。
【００４７】
ステップＡ４にて、対策案導出部１５は、設定変更候補リスト３４からＮ個の設定変更を取得する。Ｎは自然数であり、初期値は１である。図３に従えば、設定変更のエントリは４つあるので、Ｎは１〜４の値をとる。
【００４８】
例えば、対策案導出部１５は、Ｎ＝１として、設定変更候補リスト３４（図３）からＮ個の設定変更（組合せ）を取得する。本実施形態では、１つの設定変更の取得順として、例えば、「評価値（優先度）」（図３）が高いものを優先的に取得するというポリシを設定することもできるが、これに限定されない。各Ｎについて、すべての設定変更を取得した後、まだ、異常から復旧できる対策案が無かった場合には、Ｎ＝Ｎ＋１としてステップＡ４の処理を再度行う。Ｎが２以上の場合、取得される設定変更の組合せの評価値は、該当する各設定変更の「評価値（優先度）」（図３）の合計値とすることができるが、これに限らない。
ステップＡ４の後、ステップＡ５に進む。
【００４９】
ステップＡ５にて、対策案導出部１５は、取得したＮ個の設定変更（組合せ）が、全体処理（図６）１回分を通じて実行済設定変更リスト３５に登録されたことがあるか否かを判定する。この判定は、実行済設定変更リスト３５の登録の履歴を辿るという周知の技術で判定することができる。登録されたことがある場合（ステップＡ５／Ｙｅｓ）、該当のＮ個の設定変更はすでに実行済である。よって、重複実行を避けるため、ステップＡ４に戻り、対策案導出部１５は、新たなＮ個の設定変更を取得する。一方、登録されたこと無い場合（ステップＡ５／Ｎｏ）、対策案導出部１５は、未実行の設定変更として判定し、ステップＡ６に進む。
【００５０】
ステップＡ６にて、対策案導出部１５は、該当の設定変更の実行動作を設定変更キュー１５ａに追加する。具体的には、対策案導出部１５は、設定変更キュー１５ａに、ステップＡ５で未実行と判定された設定変更を実行させるキュー（例：「項目○，○：実行」（図５参照））を追加する。ステップＡ６の後、ステップＡ７に進む。
【００５１】
ステップＡ７にて、対策案導出部１５は、保守者の実施可否確認処理を実行する。具体的には、対策案導出部１５は、対象のＮ個の設定変更について、設定変更候補リスト３４の「保守者の判断待ちフラグ」の値が「１：確認要」である設定変更が含まれている場合、保守者からの指示があるまで、対象のＮ個の設定変更の実行を保留する。保守者からの指示は、例えば、ＨＭＩ装置５からの入力によって実現することができる。保守者からの指示があった後、ステップＡ８に進む。
【００５２】
ステップＡ８にて、対策案導出部１５は、設定変更キュー１５ａを対策案適用部１６に送信する。ステップＡ８の後、ステップＡ９に進む。
【００５３】
ステップＡ９にて、対策案適用部１６は、対策案導出部１５から受信した設定変更キュー１５ａを参照して、該当する設定変更を実行する。ステップＡ９の後、ステップＡ１０に進む。
【００５４】
ステップＡ１０にて、対策案適用部１６は、実行した設定変更を実行済設定変更リスト３５（図４）に登録する。具体的には、実行した変更内容について、「項番」、「日時」、「設定変更内容」を登録する。
ステップＡ１０の後、本処理を終了し、ステップＳ２（図６）に戻る。
【００５５】
図７に示す処理によれば、サービスの異常からの復旧するための対策案を一通り試行することができる。
【００５６】
＜設定変更の評価の詳細＞
ステップＳ６にて、対策案評価部１４が設定変更候補リスト３４に保存されている設定変更を評価する際、例えば、サービスの復旧に寄与した設定変更内容については、評価値を増加させることができる。また、例えば、サービスの復旧に寄与しなかった設定変更内容については、評価値を減少させることができる。また、評価値は、サービスの異常検出箇所に応じて増減させることができる。
【００５７】
［評価方法１：固定値の増減］
例えば、以下の規則に従って、評価値を増減する。
規則１：対策案を構成するＮ個の設定変更の組合せがサービスの復旧に寄与しなかった場合、0.1／Ｎ２を、各設定変更の設定値から引く。ただし、評価値が０を下回る場合は、０とする。
規則２：対策案を構成するＮ個の設定変更の組合せがサービスの復旧に寄与した場合、0.3／Ｎを、各設定変更の設定値に加える。ただし、評価値が１を上回る場合は、１とする。
【００５８】
図３に示す設定変更候補リスト３４にしたがって、サービスの復旧までに試行した対策案の試行結果の例と、対応する評価値の増減は、以下の通りであったとする。
項番１のみの対策案試行で復旧せず  →  -0.1/12 ＝ -0.1
項番３のみの対策案試行で復旧せず  →  -0.1/12 ＝ -0.1
項番４のみの対策案試行で復旧せず  →  -0.1/12 ＝ -0.1
項番２のみの対策案試行で復旧せず  →  -0.1/12 ＝ -0.1
項番１、３からなる対策案試行で復旧せず  →  -0.1/22 ＝ -0.025
項番１、４からなる対策案試行で復旧せず  →  -0.1/22 ＝ -0.025
項番３、４からなる対策案試行で復旧  →  +0.3/2 ＝ +0.15
【００５９】
このとき、各設定変更（項番１〜４）の評価値の増減値は以下の通りになる。
項番１の設定変更の増減値：-0.1 -0.025 -0.025 = -0.15
項番２の設定変更の増減値：-0.1
項番３の設定変更の増減値：-0.1 -0.025 +0.15 = +0.025
項番４の設定変更の増減値：-0.1 -0.025 +0.15 = +0.025
【００６０】
［評価方法２：発生した異常個所に対応する増減］
サービスの異常が発生した箇所の情報に応じて、評価値の増減値を変動させることができる。例えば、異常が発生したネットワーク装置２に収容されているエンドユーザ数に応じて、最終的な評価値の増減値に係数を乗ずることができる。
【００６１】
異常検出箇所の収容ユーザ数をＭ、サービス全体のユーザ数をＭ_maxとしたとする。
対策案を構成するＮ個の設定変更の組合せがサービスの復旧に寄与しなかった場合、（0.1／Ｎ２）×（Ｍ／Ｍ_max）を、各設定変更の設定値から引く。ただし、評価値が０を下回る場合は、０とする。
一方、対策案を構成するＮ個の設定変更の組合せがサービスの復旧に寄与した場合、（0.3／Ｎ）×（Ｍ／Ｍ_max）を、各設定変更の設定値に加える。ただし、評価値が１を上回る場合は、１とする。
【００６２】
上記のように、対策案評価部１４が各設定変更について、評価値を更新することで、サービスの異常からの復旧に寄与する設定変更の寄与率を定量的に決定することができる。
【００６３】
＜まとめ＞
本実施形態によれば、発生したサービスの異常に対して、予め用意したネットワーク設定変更を種々組み合わせた対策案をネットワークに順次適用することができる。
したがって、ネットワーク上で提供されているサービスの自動復旧を実現することができる。
【００６４】
また、ネットワーク設定変更の各々に評価値を設定することで、サービスの異常からの復旧に寄与するネットワーク設定変更の寄与率を定量的に決定することができる。
【００６５】
≪その他≫
（１）：設定変更候補リスト３４（図３）に登録される設定変更について、同じ設定変更であっても、サービスの異常発生個所に応じて別々のエントリを作成してもよい。具体的には、設定変更候補リスト３４について、「項番」、「変更内容」、「変更方法」、「制約事項」、「保守者の判断待ちフラグ」、「評価値（優先度）」といった欄の他に、「サービスの異常検出箇所」の欄を用意してもよい。これにより、サービスの異常検出箇所ごとに評価値を設定することができ、サービスの異常からの復旧に寄与する設定変更の寄与率をより定量的に決定することができる。
【００６６】
また、本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
また、本実施形態で説明したソフトウェアをハードウェアとして実現することもでき、ハードウェアをソフトウェアとして実現することもできる。
その他、ハードウェア、ソフトウェア、フローチャートなどについて、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。
【符号の説明】
【００６７】
１    サービス復旧装置
２    ネットワーク装置
３    サーバ
４    端末
５    ＨＭＩ装置
１０    処理部
１１    トラフィック抽出部
１２    定常性算出部
１３    サービス品質判定部（判定部）
１４    対策案評価部
１５    対策案導出部
１５ａ  設定変更キュー
１６    対策案適用部
１７    結果出力部
２０    入出力部
２１    入力部
２２    出力部
３０    記憶部
３１    フローデータ保存部
３２    定常性データ保存部
３３    サービス品質低下状況保存部
３４    設定変更候補リスト
３５    実行済設定変更リスト
【図１】
2018133688.tif 000003
【図２】
2018133688.tif 000004
【図３】
2018133688.tif 000005
【図４】
2018133688.tif 000006
【図５】
2018133688.tif 000007
【図６】
2018133688.tif 000008
【図７】
2018133688.tif 000009