JP7135969B2 - 情報処理方法及び情報処理装置 - Google Patents

Description

本発明は、情報処理方法及び情報処理装置に関する。

最近、ＩｏＴ（Internet of Things）の拡大に伴い、情報処理装置に対して、多種多様なデバイスが多種多様な通信方式で接続されるようになっている。このような状況においては、接続されるデバイスの種別、通信方式、周辺の無線状況、利用アプリ等により、発生する障害（例えば、デバイスのハードウェア障害やソフトウェア障害、通信障害）は様々となる。このため、時々刻々と変化するＩｏＴ環境においては、デバイスのハードウェア性能、ソフトウェア性能、通信性能等を監視し、障害原因を特定し、運用管理者に通知することが重要である。

障害原因を特定する際には、デバイスやネットワークから、運用管理情報（通信性能、端末性能等）やセンサ（温湿度等）の計測値（データ）を収集し、収集したデータを分析して、障害原因を特定する。ここで、運用管理情報には、通信性能情報として、受信信号強度（RSSI）、パケットエラー率（PER）、リンク品質（Link Quality）、応答時間、再送回数、チャネル利用率、アクティブノード数等が含まれる。また、運用管理情報には、端末性能情報として、ＣＰＵ使用率、メモリ使用率、ＨＤＤ使用率、バッテリ残量、デバイス内温度、内部処理時間等が含まれる。また、障害原因を特定するために収集したデータを分析する手法としては、ルールベース（閾値、ツリーモデル等を用いた方法)や、機械学習（相関／回帰／周期特性分析、クラスタリング、学習モデル等)が含まれる。

特開２００９－１４７１８３号公報 特開２０１３－０６５０８４号公報

上述した分析方法においては、共通して、分析用のパラメータや学習モデルが必要である。分析用パラメータには、例えば、閾値、有意差、ウィンドウサイズ、ウィンドウ移動量等があり、従来は、収集するデータと判定する障害原因を予め想定して分析用パラメータを設定している。また、例えば、学習モデルの場合は、“正常時”や、ある障害Ａを人為的に発生させた際の“障害Ａ発生時”等、収集データにラベルを付けて、学習モデルを生成している。

しかしながら、設置デバイスが様々であり、かつ無線使用状況等、周辺環境が時々刻々と変化するＩｏＴの現場においては、どのような異常や障害が発生するのか不明であるため、予め設定した分析用パラメータを使用すると判定精度が低くなる可能性が高い。また、予め生成した学習モデルも使えない可能性が高い。

例えば、上記特許文献１では、予め目視で決定された異常発生数と等しくなるかでパラメータを評価しているが、どのような異常や障害が発生するのかが不明な現場には適用することはできない。

１つの側面では、本発明は、障害原因の特定に用いる分析用のパラメータを必要に応じて自動的に変更することが可能な情報処理方法及び情報処理装置を提供することを目的とする。

一つの態様では、情報処理方法は、管理対象装置から定期的に収集した前記管理対象装置の性能に関する運用管理情報を含む情報に基づいて異常発生を検出するとともに、異常内容に基づいて障害種別を推定し、分析用のパラメータを用いて前記運用管理情報を分析して、前記管理対象装置の障害原因を特定し、推定した前記障害種別に対応する障害原因が特定されたか、又は特定した前記障害原因に対応する障害種別が推定されたかを判定し、前記判定の結果、推定した前記障害種別に対応する障害原因が特定されなかった、又は特定した前記障害原因に対応する障害種別が推定されなかった場合に、推定した前記障害種別又は特定した前記障害原因に対応するパラメータの優先順位に従って、前記分析用のパラメータを変更する、処理をコンピュータが実行する情報処理方法である。

障害原因の特定に用いる分析用のパラメータを必要に応じて自動的に変更することができる。

第１の実施形態に係る情報処理システムの構成を概略的に示す図である。 ゲートウェイのハードウェア構成を示す図である。 センサノード及びゲートウェイ等の機能ブロック図である。 運用管理情報ＤＢを示す図である。 計測値ＤＢを示す図である。 図６（ａ）、図６（ｂ）は、異常発生の検出方法について説明するための図である。 異常内容－障害種別対応表を示す図である。 パラメータ管理ＤＢを示す図である。 異常－障害原因特定対応表を示す図である。 障害種別－障害原因対応表を示す図である。 パラメータ変更部の処理を示すフローチャートである。 図１２（ａ）は、端末用の変更順を示す図であり、図１２（ｂ）は、通信用の変更順を示す図である。 第２の実施形態に係る異常－障害原因特定対応表を示す図である。 図１４（ａ）は、第２の実施形態に係る端末用の変更順を示す図であり、図１４（ｂ）は、第２の実施形態に係る通信用の変更順を示す図である。 第３の実施形態に係る異常内容－障害種別対応表を示す図である。 第４の実施形態に係る効果管理テーブルを示す図である。

≪第１の実施形態≫
以下、情報処理システムの第１の実施形態について、図１～図１２に基づいて詳細に説明する。

図１には、第１の実施形態に係る情報処理システム１００の構成が概略的に示されている。情報処理システム１００は、インターネットなどのネットワーク８０に接続されたルータ１０及びサーバ６０と、ハブ１２０を介してルータ１０に有線接続されたＷｉ－Ｆｉアクセスポイント１３０、センサノード７０、情報処理装置としてのゲートウェイ１１０と、Ｗｉ－Ｆｉアクセスポイント１３０及びハブ１２０経由でルータ１０と無線通信可能なセンサノード７０と、を備える。

サーバ６０は、ネットワーク８０上に存在している複数のゲートウェイ１１０から送信されてくる情報を取得して、管理する装置である。

センサノード７０は、センサと、データ処理機能や通信機能を実装した装置である。例えば、センサノード７０は、製造工場内に設置され、温度、湿度、振動などを計測し、計測値をゲートウェイ１１０に対して有線通信にて送信したり、Ｗｉ－Ｆｉアクセスポイント１３０経由でゲートウェイ１１０に対して無線通信にて送信する。また、センサノード７０は、センサノード７０の性能（ハードウェア性能、ソフトウェア性能）やゲートウェイ１１０とセンサノードとの間の通信品質を示す性能値を計測する。

図３には、センサノード７０及びゲートウェイ１１０の機能ブロック図が示されている。なお、図３には、ルータ１０、ハブ１２０、Ｗｉ－Ｆｉアクセスポイント１３０の性能値計測に関する機能についても図示されている。

（センサノード７０）
センサノード７０は、図３に示すように、１又は複数のセンサ７２と、制御部７４と、を備える。

センサ７２は、温度や湿度などを計測するセンサや、振動を計測するセンサなどを含む。

制御部７４は、ＣＰＵ（Central Processing Unit）がプログラムを実行することにより、性能値計測部７５、センサ計測部７６、通信部７７の機能を有する。

性能値計測部７５は、通信部７７を介してゲートウェイ１１０（運用管理情報取得部１２）から通知されたサンプリング間隔と取得コマンドに基づいて、センサノード７０のハードウェアやソフトウェアの性能を示す性能データの値（性能値）を計測する。なお、ハードウェアやソフトウェアの性能を示す性能データには、例えば、ＣＰＵ使用率、メモリ使用率、ＨＤＤ（Hard Disk Drive）使用率、バッテリ残量、センサノード内温度、内部処理時間などが含まれる。

また、性能値計測部７５は、ゲートウェイ１１０（運用管理情報取得部１２）から通信性能を示す性能データの値（性能値）を取得するためのコマンド（サンプリングコマンド）を受信したときに、通信性能を示す性能値を計測する。なお、通信性能を示す性能データには、電波強度（ＲＳＳＩ：Received Signal Strength Indicator）、リンク品質（ＬＱ：Link Quality）、パケットエラー率（ＰＥＲ：Packet Error Rate）、ビットエラー率（ＢＥＲ：Bit Error Rate）、応答時間、再送回数、チャネル利用率、アクティブノード数などが含まれる。

センサ計測部７６は、ゲートウェイ１１０（センサ計測値取得部１３）から通知されたサンプリング間隔と取得コマンドで、センサ７２により計測された値（センサ計測値）を取得する。

性能値計測部７５及びセンサ計測部７６は、運用管理情報取得部１２やセンサ計測値取得部１３から通知されたデータ送信間隔ごとに、未送信のデータをまとめて通信部７７を介して送信する。なお、性能値計測部７５及びセンサ計測部７６は、運用管理情報取得部１２やセンサ計測値取得部１３からデータ要求コマンドを受信したときに、未送信のデータをまとめて、通信部７７を介してゲートウェイ１１０に向けて送信することとしてもよい。

なお、ルータ１０、ハブ１２０、Ｗｉ－Ｆｉアクセスポイント１３０は、ＣＰＵがプログラムを実行することにより、性能値計測部１２２及び通信部１２４としての機能を有する。これら性能値計測部１２２と通信部１２４は、センサノード７０が有する性能値計測部７５及び通信部７７と同様である。したがって、性能値計測部１２２は、各装置の性能データの値（性能値）を計測し、通信部１２４を介してゲートウェイ１１０に送信する。なお、各装置の性能値には、装置の性能（ハードウェア性能、ソフトウェア性能）を示す性能値や、他の装置との間の通信品質を示す性能値が含まれる。

（ゲートウェイ１１０）
ゲートウェイ１１０は、例えば、製造工場内などに設置されるネットワークノードである。ゲートウェイ１１０は、センサノード７０や、ルータ１０、ハブ１２０、Ｗｉ－Ｆｉアクセスポイント１３０において計測された性能値や、センサノード７０で計測されたセンサ計測値を受信する。そして、ゲートウェイ１１０は、受信した情報に基づいて、センサノード７０やネットワークの異常有無を判定する。すなわち、センサノード７０、ルータ１０、ハブ１２０、Ｗｉ－Ｆｉアクセスポイント１３０は、ゲートウェイ１１０における管理対象装置であるといえる。また、ゲートウェイ１１０は、異常が発生したと判定した場合に、異常内容から障害種別を推定するとともに、障害原因を特定し、その旨をサーバ６０や運用管理者が利用する端末（不図示）に通知する。更に、ゲートウェイ１１０は、必要に応じて障害原因を特定する際に用いる分析用のパラメータを変更する。

図２には、ゲートウェイ１１０のハードウェア構成が示されている。図２に示すように、ゲートウェイ１１０は、ＣＰＵ９０、ＲＯＭ（Read Only Memory）９２、ＲＡＭ（Random Access Memory）９４、記憶部（ここではＨＤＤ）９６、通信インタフェース９７、及び可搬型記憶媒体用ドライブ９９等を備えている。ゲートウェイ１１０の構成各部は、バス９８に接続されている。ゲートウェイ１１０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラムをＣＰＵ９０が実行することにより、図３に示す各部の機能が実現される。なお、図３の各部の機能は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現されてもよい。

ゲートウェイ１１０は、図３に示すように、ＣＰＵ９０がプログラムを実行することで、通信部１１、運用管理情報取得部１２、センサ計測値取得部１３、推定部としての異常有無判定部１４、特定部としての障害原因特定部１５、判定部としてのパラメータ変更必要性判定部１６、変更部としてのパラメータ変更部１７、通知部１８として機能する。なお、図３において図示されている、運用管理情報ＤＢ３０、計測値ＤＢ３２、パラメータ管理ＤＢ３４は、ＨＤＤ９６等に格納されている。なお、ゲートウェイ１１０は、定期的に又は不定期に外部から送信されてくるネットワークの設計情報を受信して、管理しているものとする。設計情報には、情報処理システム１００に含まれる各装置（デバイス）のデバイスＩＤや各デバイスが接続されているデバイスのデバイスＩＤ（親デバイスＩＤ）、設置位置、受信信号強度（ＲＳＳＩ：Received Signal Strength Indicator）の設計値の設計範囲（上限及び下限）等が含まれる。なお、設計情報には、ＲＳＳＩ以外の設計範囲の情報が含まれていてもよい。例えば、ＲＳＳＩ以外の設計範囲としては、通信性能情報（リンク品質（ＬＱ）、パケットエラー率（ＰＥＲ）、ビットエラー率（ＢＥＲ）、応答時間、再送回数、チャネル利用率、アクティブノード数）などが含まれてもよい。また、設計範囲としては、端末性能情報（ＣＰＵ使用率、メモリ使用率、ＨＤＤ使用率、バッテリ残量、センサノード内温度、内部処理時間）などが含まれてもよい。

運用管理情報取得部１２は、各管理対象装置（７０、１０、１２０、１３０）において計測された性能値を取得し、運用管理情報として運用管理情報ＤＢ３０に格納する。ここで、運用管理情報取得部１２は、性能値を取得する場合に、通信部１１を介して、センサノード７０にサンプリング間隔（性能値の計測間隔）等を通知する。そして、運用管理情報取得部１２は、通知したサンプリング間隔等に従ってセンサノード７０において計測された各種性能値が送信されてくると、該性能値を取得し、運用管理情報として運用管理情報ＤＢ３０に格納する。また、運用管理情報取得部１２は、運用管理情報ＤＢ３０を更新した場合には、異常有無判定部１４に対して運用管理情報ＤＢ３０の更新を通知する。

図４には、運用管理情報ＤＢ３０のデータ構造が示されている。図４に示すように、運用管理情報ＤＢ３０においては、あるエンドデバイス（ＥＤ０１００１）の運用管理情報として、「デバイスＩＤ」、「タイムスタンプ」、「ＲＳＳＩ」、「ＬＱ」、「応答時間」、「再送回数」、「バッテリ残量」などを管理している。また、運用管理情報ＤＢ３０においては、あるアクセスポイント（ＡＰ１２３４５）の運用管理情報として、「デバイスＩＤ」、「タイムスタンプ」、「ＲＳＳＩ」、「ＬＱ」、「応答時間」、「ＣＰＵ使用率」、「メモリ使用率」などを管理している。「デバイスＩＤ」は、運用管理情報の取得先であるデバイス（センサノード７０やＷｉ－Ｆｉアクセスポイント１３０等）の識別情報である。「タイムスタンプ」は、運用管理情報の取得日時である。「ＲＳＳＩ」、「ＬＱ」などその他の情報は、各デバイスから取得された性能値である。

センサ計測値取得部１３は、センサノード７０から、センサ７２が計測したデータ（センサ計測値）を受信する。また、センサ計測値取得部１３は、受信したセンサ計測値を計測値ＤＢ３２に格納する。計測値ＤＢ３２においては、図５に示すように、運用管理情報ＤＢ３０と同様、「デバイスＩＤ」及び「タイムスタンプ」が管理されるとともに、各種センサ計測値（「温度」、「湿度」、「振動」…等）が管理される。センサ計測値取得部１３は、計測値ＤＢ３２を更新した場合には、異常有無判定部１４に対して計測値ＤＢ３２の更新を通知する。

異常有無判定部１４は、センサ計測値取得部１３から計測値ＤＢ３２の更新通知を受信するか、運用管理情報取得部１２から運用管理情報ＤＢ３０の更新通知を受信すると、異常有無判定処理を実行する。具体的には、異常有無判定部１４は、計測値ＤＢ３２又は運用管理情報ＤＢ３０から直近データを取得して、異常の有無を判定する。そして、異常有無判定部１４は、異常発生を検知すると、異常内容に基づいて障害種別を推定する。

ここで、異常有無判定部１４は、例えば、センサ計測値や運用管理情報の取得失敗（データの欠落）、運用管理情報の閾値超え、エラーメッセージ受信などがあった場合に、異常発生を検知する（判定する）。例えば、図６（ａ）の太線枠内のように、ＲＳＳＩの値が閾値（例えば－６０）未満である場合や、図６（ｂ）の太線枠内のように、ＲＳＳＩ、ＬＱ、応答時間を取得できなかった（取得に失敗した）場合などにおいて、異常有無判定部１４は異常発生を検知する。なお、異常有無判定部１４は抽出した直近の複数のセンサ計測値や運用管理情報から平均値や分散値を算出し、算出した平均値や分散値が閾値を超えるか否かにより、異常の発生を判定してもよい（例えば、国際公開第２０１８／０６６０４１参照）。

また、異常有無判定部１４は、障害種別を推定する場合、図７に示すような異常内容－障害種別対応表を参照する。ここで、異常内容－障害種別対応表においては、異常内容と、障害種別とが対応付けられている。例えば、異常内容－障害種別対応表からは、異常を検出した際の異常内容がデータ取得失敗であり、その後の自然復旧が無かった場合には、障害種別を「端末」と推定することができる。また、異常内容－障害種別対応表からは、例えば、異常を検出した際の異常内容がデータ取得失敗であり、その後の自然復旧が有った場合には、障害種別を「通信」と推定することができる。また、異常内容－障害種別対応表からは、例えば、異常内容が、ある性能値が閾値を超えていたことであった場合には、障害種別をその性能値に対応するものと推定することができる。すなわち、閾値を超えていた性能値がＲＳＳＩやＬＱであれば、障害種別を「通信」と推定することができ、閾値を超えていた性能値がＣＰＵ使用率やメモリ使用率であれば、障害種別を「端末」と推定することができる。

異常有無判定部１４は、異常発生を検知するとともに障害種別を推定すると、障害原因特定部１５に対して、異常発生と判定した元データ（デバイスＩＤ、タイムスタンプ、データ名、データ値）を通知する。また、異常有無判定部１４は、パラメータ変更必要性判定部１６に、推定した障害種別を通知する。

例えば、異常有無判定部１４が、図６（ａ）のデータから障害種別を「通信」と推定した場合、障害原因特定部１５に対して、異常発生と判定した元データ（デバイスＩＤ＝「ED01001」、タイムスタンプ＝「2019/1/1 00:00:00.400」、データ名＝「ＲＳＳＩ」、データ値＝「－６５」）を通知する。また、異常有無判定部１４は、パラメータ変更必要性判定部１６に対して、障害種別＝「通信」を通知する。

また、例えば、異常有無判定部１４が、図６（ｂ）のデータから障害種別を「通信」と推定した場合、障害原因特定部１５に対して、異常発生と判定した元データ（デバイスＩＤ＝「AP12345」、タイムスタンプ＝「2019/1/1 00:00:00.500」、データ名＝「ＲＳＳＩ」、「ＬＱ」、「応答時間」、データ値＝「null」）を通知する。また、異常有無判定部１４は、パラメータ変更必要性判定部１６に対して、障害種別＝「通信」を通知する。

図３に戻り、障害原因特定部１５は、異常有無判定部１４から異常発生検知時の通知を受信すると、通知されたデバイスＩＤの通知されたタイムスタンプの直近データを運用管理情報ＤＢ３０から１個以上取得する。そして、障害原因特定部１５は、パラメータ管理ＤＢ３４に登録されている分析用のパラメータを利用して、取得した情報を分析して、障害原因を判定する。障害原因が判定できた場合、障害原因特定部１５は、通知部１８とパラメータ変更必要性判定部１６に障害原因の情報（デバイスＩＤ、障害発生日時、障害原因）を通知する。

なお、障害原因の分析については種々の分析手法を利用することができる。例えば、分析手法として平均値、中央値、分散値などを利用したり、特徴量の比較や閾値超えの有無を利用したりしてもよい。また、クラスタ分析やトレンド分析、正常時の学習パターンやクラスタとの比較を利用してもよい。クラスタ分析としては例えばＫ－Ｍｅａｎｓ法、Ｘ－Ｍｅａｎｓ法などがある。トレンド分析としては例えば最小二乗法や近似１次直線などがある。（例えば、特開２０１７－１２３１２４号公報、国際公開第２０１８／０６６０４１参照）。

ここで、製造工場内においては、製造ラインが変更されることが多いため、用いるセンサノードは無線通信できるものが多い。このような無線通信可能なセンサノードにおいては、障害原因として、大きな装置による「無線遮蔽」や、周辺からの「無線干渉」といった通信障害が特定されることがある。また、安価なセンサノードやデータ集中用ゲートウェイデバイスを利用している場合、障害原因として、ハードウェアやソフトウェアのスペック不足（「ＣＰＵ負荷」や「ＨＤＤ不足」など）や「故障」といった端末起因の障害が特定されることがある。

図８には、パラメータ管理ＤＢ３４のデータ構造の一例が示されている。図８に示すように、パラメータ管理ＤＢ３４には、デバイスＩＤ及びデータ名の組み合わせごとに、障害原因の分析に用いるパラメータの情報が格納されている。

パラメータ変更必要性判定部１６は、異常有無判定部１４から、異常発生時の通知（異常有り通知）と、推定した障害種別を受信する。また、パラメータ変更必要性判定部１６は、障害原因特定部１５から障害原因の通知を受信する。パラメータ変更必要性判定部１６は、異常有り通知を受信後の一定期間内において、対応する障害原因の情報の通知を受信しなかった場合に、パラメータ変更部１７に異常発生日時と障害種別とを通知する。なお、異常有り通知を受信した後の一定期間としては、デフォルト値（例えば１０分）を用いることができる。ただし、これに限らず、一定期間としては、異常有り通知において通知された障害種別に応じた期間を用いることとしてもよい。例えば、障害種別が「端末」の場合であれば、１時間など、比較的長い時間を用いることとし、例えば、障害種別が「通信」の場合であれば、１分など、比較的短い時間を用いることとしてもよい。このように、障害種別が「端末」の場合の一定期間を比較的長い時間とするのは、障害が端末に発生している場合には、比較的長い時間に得られる大量のデータを分析しないと、障害原因がわからない場合が多いからである。また、障害種別が「通信」の場合の一定期間を比較的短い時間とするのは、通信に関する運用管理情報は、値の変化が激しいものが多く、比較的短時間に得られるデータから障害原因を特定できる場合が多いからである。

なお、上述した例では、パラメータ変更必要性判定部１６は、対応する障害原因の通知を、異常有り通知受信後の一定期間内に受信したか判断することとしたが、これに限られるものではない。例えば、パラメータ変更必要性判定部１６は、異常有り通知を受信した前後の一定期間内において、対応する障害原因の情報の通知を受信したかを判断することとしてもよい。

図９には、パラメータ変更必要性判定部１６が管理している異常－障害原因特定対応表が示されている。パラメータ変更必要性判定部１６は、異常有無判定部１４から異常発生日時と障害種別が通知されると、異常－障害原因特定対応表に格納する。また、パラメータ変更必要性判定部１６は、格納した異常発生日時を基準とする一定時間の間に障害原因特定部１５から障害原因が通知されると、対応する行に障害原因特定日時と障害原因の情報を格納する。そして、パラメータ変更必要性判定部１６は、一定時間内に障害原因が入力されなかった場合や、一定時間内に障害原因が入力されたものの、障害種別と障害原因が対応していない場合に、パラメータ変更部１７に対して異常発生日時と障害種別とを通知する。なお、パラメータ変更必要性判定部１６は、障害種別と障害原因が対応するか否かは、図１０に示す障害種別－障害原因対応表を参照して判断する。図１０の障害種別－障害原因対応表においては、障害種別（端末、通信、…）と当該障害種別を引き起こす障害原因とが対応付けられている。

パラメータ変更部１７は、パラメータ変更必要性判定部１６から、通知を受信すると、異常発生日時付近の運用管理情報を運用管理情報ＤＢ３０から取得し、障害種別に対応する障害原因が特定されるように、分析用のパラメータを変更する。なお、分析用のパラメータの変更方法の詳細については後述する。

パラメータ変更部１７は、パラメータを変更すると、変更後のパラメータを障害原因特定部１５に通知する。通知を受けた障害原因特定部１５は、変更後のパラメータをパラメータ管理ＤＢ３４に登録（更新）する。

通知部１８は、障害原因特定部１５から障害原因の情報の通知を受け付けると、受け付けた障害原因の情報をサーバ６０や運用管理者が利用する端末等に送信する。

（パラメータ変更部１７の処理について）
次に、パラメータ変更部１７の処理について、図１１のフローチャートに沿って、その他図面を適宜参照しつつ詳細に説明する。

図１１の処理が開始されると、まず、ステップＳ１０において、パラメータ変更部１７は、パラメータ変更必要性判定部１６から異常発生日時と障害種別の通知を受信するまで待機する。なお、パラメータ変更必要性判定部１６は、前述のように、異常発生日時を基準とする一定時間内に障害原因が入力されなかった場合や、一定時間内に障害原因が入力されたが、障害種別と障害原因が対応していなかった場合に、パラメータ変更部１７に対して上記通知を行う。

パラメータ変更部１７は、上記通知を受信すると、ステップＳ１２に移行し、障害種別が「端末」であるか否かを判断する。このステップＳ１２の判断が肯定された場合には、ステップＳ１４に移行する。

ステップＳ１４に移行すると、パラメータ変更部１７は、変更順を端末用とする。ここで、パラメータの変更順には、図１２（ａ）に示すような端末用の変更順と、図１２（ｂ）に示すような通信用の変更順があるものとする。障害種別が「端末」の場合には、図１２（ａ）の端末用の変更順（優先順位）に従ってパラメータを変更することで、適切な障害原因が特定されやすくなる。また、障害種別が「通信」の場合には、図１２（ｂ）の通信用の変更順（優先順位）に従ってパラメータを変更することで、適切な障害原因が特定されやすくなる。このステップＳ１４では、パラメータ変更部１７は、図１２（ａ）の変更順を以下において用いるように設定する。

次いで、ステップＳ１６では、パラメータ変更部１７は、同タイミングで複数デバイスに異常が発生したか否かを判断する。このステップＳ１６の判断が否定された場合、すなわち、１つのデバイスで異常が発生した場合には、ステップＳ１８に移行し、パラメータを変更する対象のデバイスを、異常が発生したデバイスとする。一方、ステップＳ１６の判断が肯定された場合、すなわち、同タイミングにおいて複数のデバイスに異常が発生した場合には、ステップＳ２０に移行し、パラメータ変更部１７は、パラメータを変更する対象のデバイスを、異常が発生した複数のデバイスの上位デバイスとする。この場合、例えば、Ｗｉ－Ｆｉアクセスポイント１３０に接続されている複数のセンサノード７０において異常が同タイミングで発生した場合には、複数のセンサノード７０の上位デバイスであるＷｉ－Ｆｉアクセスポイント１３０に原因がある可能性が高い。したがって、上位デバイスをパラメータ変更の対象デバイスとする。ステップＳ１８又はＳ２０の処理が実行された後は、ステップＳ２２に移行する。

ステップＳ２２に移行すると、パラメータ変更部１７は、変更順に並ぶパラメータのうち先頭の未選択パラメータを選択する。例えば、図１２（ａ）の変更順が設定されている場合、パラメータ変更部１７は、「１－１．ＣＰＵ負荷」を選択する。

次いで、ステップＳ２４では、パラメータ変更部１７は、選択したパラメータの値を障害原因が特定される値まで変更する。「１－１．ＣＰＵ負荷」が選択されている場合には、パラメータ変更部１７は、障害原因が特定されるように、ＣＰＵ負荷の閾値を減らす。

次いで、ステップＳ２６では、パラメータ変更部１７は、パラメータを変更した結果、異常発生無しの日時に障害原因が特定されたか否かを判断する。すなわち、パラメータ変更部１７は、障害発生日時を基準とした所定時間内に得られた運用管理情報を運用管理情報ＤＢ３０から取得して、障害原因を特定する。この結果、異常が発生していない日時に障害原因が新たに特定されなかった場合には、パラメータ変更が適切に行われたことを意味する。この場合、ステップＳ２６の判断は否定されて、ステップＳ４６に移行する。ステップＳ４６では、パラメータ変更部１７は、障害原因特定部１５にパラメータ変更を通知して、障害原因特定部１５にパラメータ管理ＤＢ３４を更新させる。すなわち、パラメータの変更を確定する。その後は、図１１の全処理を終了する。

これに対し、ステップＳ２６において、異常が発生していない日時に障害原因が新たに特定されたため、判断が肯定されると、ステップＳ２８に移行する。ステップＳ２８に移行する場合とは、パラメータ変更が適切でなかったことを意味する。このステップＳ２８においては、パラメータ変更部１７は、未選択のパラメータがあるか否かを判断する。このステップＳ２８の判断が肯定されると、ステップＳ３０に移行し、パラメータ変更部１７は、変更したパラメータを元に戻し、ステップＳ２２に移行する。

ステップＳ２２に移行すると、パラメータ変更部１７は、次のパラメータを選択する。例えば、前回「１－１．ＣＰＵ負荷」を選択していた場合には、パラメータ変更部１７は、次の「１－２．メモリ／ＨＤＤ使用率」を選択する。その後は、ステップＳ２４以降の処理を繰り返す。そして、繰り返しの間にステップＳ２６の判断が否定されることなく、ステップＳ２８の判断が否定された場合には、ステップＳ３２に移行する。この場合、パラメータの変更ができなかったことを意味するため、パラメータ変更部１７は、パラメータ変更不可を障害原因特定部１５に通知する。この通知を受けた障害原因特定部１５は、通知部１８を介して、サーバ６０や運用管理者が利用する端末等へパラメータの変更ができなかったこと等を通知する。

ところで、障害種別が「端末」ではなかった場合には、ステップＳ１２の判断が否定され、ステップＳ３４に移行する。ステップＳ３４に移行すると、パラメータ変更部１７は、障害種別が「通信」であるか否かを判断する。このステップＳ３４の判断が肯定された場合には、ステップＳ３６に移行し、パラメータ変更部１７は、変更順を通信用とする。すなわち、パラメータ変更部１７は、図１２（ｂ）の変更順を以下において用いるように設定する。

次いで、ステップＳ４０では、パラメータ変更部１７は、同タイミングで複数デバイスに異常が発生したか否かを判断する。このステップＳ４０の判断が否定された場合、すなわち、１つのデバイスで異常が発生した場合には、ステップＳ４２に移行し、パラメータを変更する対象のデバイスを、異常が発生したデバイスとする。一方、ステップＳ４０の判断が肯定された場合、すなわち、同タイミングにおいて複数のデバイスに異常が発生した場合には、パラメータを変更する対象のデバイスを、同タイミングにおいて異常が発生した複数のデバイスとする。このようにするのは、同タイミングで複数のデバイスに通信に関する異常が発生した場合、各デバイスに障害原因がある可能性が高いからである。

その後は、ステップＳ２２に移行し、上述したようにステップＳ２２以降の処理を実行する。この場合、パラメータ変更部１７は、図１２（ｂ）の変更順に沿ってパラメータを変更するものとする。

ステップＳ３４において判断が否定された場合、すなわち、障害種別が「該性能」であった場合には、パラメータ変更部１７は、ステップＳ３８に移行し、パラメータの変更順を対応する性能値のパラメータのみとする。その後は、ステップＳ４０以降の処理を上記と同様に実施する。なお、障害種別が「該性能」の場合、変更すべきパラメータが１つしかないため、ステップＳ２６の判断が肯定された場合には、ステップＳ２８をスキップして、ステップＳ３２に移行するようにしてもよい。

以上のように図１１の処理が実行されることで、障害原因の分析用のパラメータを適切に変更することが可能となっている。なお、図１１の処理は、繰り返し実行されるようになっている。

なお、図１１のフローチャートは、障害種別が「端末」、「通信」、「該性能」の３つである場合の処理を示している。ただし、本実施形態がこれに限られるものではなく、実際の障害種別の数に合わせて、図１１のフローチャートを適宜変更することができる。

以上、詳細に説明したように、本第１の実施形態によると、異常有無判定部１４は、センサノード７０やルータ１０などの管理対象装置から定期的に収集した運用管理情報やセンサ計測値に基づいて、異常を検出するとともに、異常内容から障害種別を推定する。また、障害原因特定部１５は、分析用のパラメータを用いて運用管理情報を分析して、管理対象装置の障害原因を特定する。また、パラメータ変更必要性判定部１６は、異常発生が検出された日時を基準とする一定時間内に、障害種別に対応する障害原因が特定されたかを判定する。そして、パラメータ変更部１７は、当該判定の結果、対応する障害原因が特定できていなければ、推定した障害種別に応じたパラメータの優先順位（変更順）に従って、分析用のパラメータを変更する。これにより、本実施形態では、どのような異常や障害が発生するのかが不明なＩｏＴ環境であっても、システム運用中に収集される運用管理情報に基づいて、適切に障害原因を特定することができるパラメータを自動的に決定することができる。したがって、時々刻々と変化するＩｏＴ環境において高い精度で障害原因を特定することができる。この場合、推定した障害種別に応じたパラメータの変更順（図１２（ａ）、図１２（ｂ））に従ってパラメータを変更するため、障害種別に合った適切な順番でパラメータを効率的に変更することができる。

また、本実施形態では、パラメータ変更部１７は、対応する障害原因の特定結果が得られるように分析用のパラメータを変更する。そして、パラメータ変更部１７は、変更後の分析用のパラメータを用いて、過去の所定期間に得られた運用管理情報を分析し、異常が検出されなかった日時において障害原因が特定されなければ、分析用のパラメータの変更を確定する（Ｓ２６：否定、Ｓ４６）。これにより、誤った障害原因の特定が行われないように、パラメータ変更を適切に行うことができる。

《第２の実施形態》
次に、第２の実施形態について、図１３～図１４（ｂ）に基づいて、詳細に説明する。本第２の実施形態では、障害原因特定部１５が、常時障害原因を特定する処理を実行する。この場合、異常有無判定部１４によって異常が検出されないタイミングにおいても、障害原因特定部１５が障害原因を特定することがある。このような場合には、異常が発生する前の段階で、障害予兆が行われていると考えることもできる。

しかし、同じ障害原因が短期間に何度も判定されるにもかかわらず、異常発生有と検知されないような場合は、障害原因が誤って特定されている可能性が高い。本第２の実施形態は、このような障害原因が誤って特定されることを抑制するために、パラメータ変更部１７がパラメータを変更する。

本第２の実施形態においては、パラメータ変更必要性判定部１６は、障害原因に対応する障害種別の異常が発生していないことが、所定回数以上（例えば１回以上）繰り返されたことを検出すると、パラメータ変更部１７に対して通知を行う。具体的には、パラメータ変更必要性判定部１６は、図１３に示すように、異常－障害原因特定対応表において障害原因が格納されているにも関わらず、対応する障害種別が一定期間以上格納されていない行がある場合に、パラメータ変更部１７に通知する。

ここで、一定期間はデフォルト値（例えば1時間）であってもよいし、障害原因に対応する障害種別に応じて異なる値を用いてもよい。例えば、障害原因に対応する障害種別が「端末」の場合には、例えば２時間等と比較的長く設定し、障害原因に対応する障害種別が「通信」の場合には、例えば３０分等と比較的短くしてもよい。障害原因に対応する障害種別が「端末」の場合と「通信」の場合とで上記のように一定時間の長さを異ならせる理由については、上記第１の実施形態において説明したとおりである。なお、一定期間は、障害原因を受信した後の時間であってもよいし、障害原因の前後の時間であってもよい。

なお、所定回数は、１回に限らず、２回や３回などであってもよい。また、所定回数は障害原因に対応する障害種別に応じて異なる回数を用いてもよい。たとえば、障害原因に対応する障害種別が「端末」の場合、比較的回数を少なく（例えば１回）し、障害原因に対応する障害種別が「通信」の場合、比較的回数を多く（例えば５回）してもよい。このようにすることで、障害種別に応じた障害予兆の出方を考慮して、所定回数を適切な値とすることができる。

パラメータ変更部１７は、第１の実施形態と同様、図１１のフローチャートに沿った処理を実行する。ここで、ステップＳ１２、Ｓ３４では、障害種別が端末か通信かを判断するが、本第２の実施形態では障害種別が推定されていない。したがって、パラメータ変更部１７は、特定されている障害原因に対応する障害種別を図１０の障害種別－障害原因対応表に基づいて特定する。そして、特定した障害種別に基づいて、ステップＳ１２、Ｓ３４を実行する。本第２の実施形態では、端末用の変更順が図１４（ａ）に示すような順であり、通信用の変更順が図１４（ｂ）に示すような順であるものとする。

図１４（ａ）と図１２（ａ）とは、変更順については同一であるが、パラメータ（閾値等）を減らすか増やすかが逆となっている。図１４（ｂ）と図１２（ｂ）についても同様であり、パラメータ（閾値等）を増やすか減らすかが逆となっている。

なお、第１の実施形態では、図１１のステップＳ２６において、パラメータ変更部１７は、パラメータを変更した結果、過去の所定時間内の異常発生無しの日時に障害原因が特定されたか否かを判断することとしていた。これに対し、本第２の実施形態では、パラメータ変更部１７は、パラメータを変更した結果、過去の所定時間内の異常発生有りの日時に障害原因が特定されなくなったか否かを判断することとする。このようにすることで、パラメータを変更した結果、障害原因が特定されなくなった場合に、そのパラメータの変更を採用しないようにすることができる。

以上説明したように、本第２の実施形態によると、異常有無判定部１４は、センサノード７０やルータ１０などの管理対象装置から定期的に収集した運用管理情報やセンサ計測値に基づいて、異常発生を検出するとともに、異常内容から障害種別を推定する。また、障害原因特定部１５は、分析用のパラメータを用いて運用管理情報を分析して、管理対象装置の障害原因を特定する。また、パラメータ変更必要性判定部１６は、障害原因が特定されたタイミングを基準とする一定時間内に、障害原因に対応する障害種別が推定されたかを判定する。そして、パラメータ変更部１７は、判定の結果、対応する障害種別が推定されていなければ、障害原因に対応する障害種別に応じたパラメータの優先順位に従って、分析用のパラメータを変更する。これにより、どのような異常や障害が発生するのかが不明なＩｏＴ環境であっても、システム運用中に収集される運用管理情報に基づいて、適切に障害原因を特定可能なパラメータを自動的に決定することができる。したがって、時々刻々と変化するＩｏＴ環境において高い精度で障害原因を特定することができる。この場合、特定した障害原因に対応する障害種別に応じたパラメータの変更順（図１４（ａ）、図１４（ｂ））に従ってパラメータを変更するため、障害種別に合った適切な順番でパラメータを効率的に変更することができる。

《第３の実施形態》
以下、第３の実施形態について、図１５に基づいて説明する。上記第１、第２の実施形態では、異常有無判定部１４が利用する異常内容－障害種別対応表が図７に示すような表である場合について説明したが、本実施形態では、図１５に示すような異常内容－障害種別対応表を用いる。

図７の異常内容－障害種別対応表は、異常内容に対応付けて異常種別が格納されていたが、本第３の実施形態の異常内容－障害種別対応表（図１５）は、異常内容と、デバイス種別と、通信方式との組み合わせに対応付けて、障害種別が定義されている。すなわち、異常内容が、デバイス種別（エンドデバイス、中継器、ゲートウェイ）により場合分けされるとともに、通信方式（有線ＬＡＮ、Ｗｉ－Ｆｉ、…）により場合分けされ、各場合に対して障害種別が定められている。なお、本第３の実施形態において利用する図１５以外の対応表についても、図１５と同様に細分化した障害種別が用いられるものとする。このように、障害種別を細分化して定義することにより、より精度よく障害原因判定を行うことが可能となる。

以上説明したように、本第３の実施形態によれば、異常内容とデバイス種別、通信方式に基づいて、障害種別を決定するため、より精度よく障害判定を行うことができる。

《第４の実施形態》
次に、第４の実施形態について、図１６に基づいて説明する。本第４の実施形態では、上記第１の実施形態においてパラメータ変更部１７がパラメータを変更した場合に、その変更の効果の履歴を記録し、変更の効果の履歴に基づいてパラメータの変更順を調整する。

なお、本第４の実施形態では、一例として、異常有無判定部１４は、第３の実施形態で説明した障害内容－障害種別対応表を利用する。このため、異常有無判定部１４では、図１５に示すような細分化された障害種別が推定される。また、パラメータ変更部１７の処理は、上記第１の実施形態（図１１）と同様である。

本第４の実施形態では、パラメータ変更部１７は、図１１のステップＳ４６においてパラメータ変更を障害原因特定部１５に通知する際、及びステップＳ３０において変更したパラメータを元に戻す際に、図１６に示す効果管理テーブルを更新する。

ここで、図１６の効果管理テーブルには、障害種別と、デバイスＩＤの組み合わせごとに、「効果無」のパラメータ変更と、「効果有」のパラメータ変更と、効果があったときのパラメータの「変更量」と、が格納される。すなわち、パラメータ変更部１７は、ステップＳ３０の処理が行われた場合に、元に戻したパラメータの情報（図１２（ａ）、図１２（ｂ）におけるパラメータの番号）を、対応する「効果無」の欄に格納する。また、パラメータ変更部１７は、ステップＳ４６の処理が行われた場合に、変更したパラメータの情報（図１２（ａ）、図１２（ｂ）におけるパラメータの番号）を、対応する「効果有」の欄に格納するとともに、パラメータの変更量を「変更量」の欄に格納する。

そして、パラメータ変更部１７は、同じ障害種別において、各デバイスの「効果有」のパラメータが共通している場合には、「効果有」のパラメータの優先順位（変更順）を上げるように、図１２（ａ）、図１２（ｂ）の変更順を更新する。これにより、どのパラメータを優先的に変更すればよいかを学習した結果に基づいて作成された変更順（図１２（ａ）、図１２（ｂ））を用いることで、変更効果の高いパラメータを優先的に変更することができるため、効率的なパラメータ変更が可能となる。

また、同じ障害種別において、各デバイスの「変更量」が共通するような場合には、当該共通する変更量を変更順（図１２（ａ）、図１２（ｂ））において定義することとしてもよい。また、同じ障害種別において、各デバイスの「変更量」が共通しなければ、同じ障害種別における各デバイスの「変更量」のうちで最小の値を変更順（図１２（ａ）、図１２（ｂ））において定義してもよいし、「変更量」の平均値を変更順において定義してもよい。

また、図１２（ａ）、図１２（ｂ）において変更量を定義する場合、時間帯ごとに変更量を定義してもよいし、平日／休日ごとに変更量を定義してもよいし、曜日ごとに定義してもよい。

また、障害種別が「端末」に関連するものであり、効果があったパラメータ変更が「通信性能情報」だった場合には、パラメータ変更部１７は、異常有無判定部１４に対して、該障害種別を「通信」に関連するものと変更するよう通知してもよい。同様に、障害種別が「通信」に関連するものであり、効果があったパラメータ変更が「端末性能情報」だった場合には、パラメータ変更部１７は、異常有無判定部１４に対して、該障害種別を「端末」に関連するものと変更するよう通知してもよい。

なお、上記第４の実施形態では、第１の実施形態において、パラメータの変更の効果の履歴を効果管理テーブル（図１６）に記録しておき、図１２（ａ）、図１２（ｂ）の変更順を効果管理テーブルに基づいて変更する場合について説明した。しかしながら、これに限られるものではなく、第２の実施形態において、パラメータの変更の効果の履歴を効果管理テーブル（図１６）に記録しておき、図１４（ａ）、図１４（ｂ）の変更順を効果管理テーブルに基づいて変更することとしてもよい。

なお、上記各実施形態では、図３のゲートウェイ１１０の機能をサーバ６０が有していてもよい。また、図３のゲートウェイ１１０の機能を複数の装置で分担して有するようにしてもよい。

なお、上記各実施形態では、パラメータ変更部１７は、分析用のパラメータを変更する際に、図１１の処理を行う場合について説明したが、これに限られるものではない。パラメータ変更部１７は、機械学習において利用する学習モデルを生成する際に、収集データに正常／異常のラベルを付与するために用いるパラメータを図１１の処理により変更することしてもよい。すなわち、図１１の処理により、学習モデルを変更することとしてもよい。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記憶媒体（ただし、搬送波は除く）に記録しておくことができる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記憶媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記憶媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記憶媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

なお、以上の第１～第４の実施形態の説明に関して、更に以下の付記を開示する。
（付記１） 管理対象装置から定期的に収集した前記管理対象装置の性能に関する運用管理情報を含む情報に基づいて異常発生を検出するとともに、異常内容に基づいて障害種別を推定し、
分析用のパラメータを用いて前記運用管理情報を分析して、前記管理対象装置の障害原因を特定し、
推定した前記障害種別に対応する障害原因が特定されたか、又は特定した前記障害原因に対応する障害種別が推定されたかを判定し、
前記判定の結果、推定した前記障害種別に対応する障害原因が特定されなかった、又は特定した前記障害原因に対応する障害種別が推定されなかった場合に、推定した前記障害種別又は特定した前記障害原因に対応するパラメータの優先順位に従って、前記分析用のパラメータを変更する、
処理をコンピュータが実行することを特徴とする情報処理方法。
（付記２） 前記判定する処理では、前記異常発生の検出と前記障害原因の特定のタイミングが合っており、特定した前記障害原因が推定した前記障害種別を引き起こすものであるかを判定する、ことを特徴とする付記１に記載の情報処理方法。
（付記３） 前記変更する処理では、
推定した前記障害種別に対応する障害原因が特定されるように、又は特定した前記障害原因に対応する障害種別が推定されるように、前記分析用のパラメータを変更し、
変更後の前記分析用のパラメータを用いて、過去における異常発生の検出及び過去における障害原因の特定結果に変更が生じなければ、前記分析用のパラメータの変更を確定する、ことを特徴とする付記１又は２に記載の情報処理方法。
（付記４） 前記変更する処理において、前記分析用のパラメータを変更したことによる効果に関する情報を記憶部に記憶し、
前記記憶部に記憶した情報に基づいて、前記優先順位を決定する、処理を前記コンピュータが更に実行することを特徴とする付記１～３のいずれかに記載の情報処理方法。
（付記５） 管理対象装置から定期的に収集した前記管理対象装置の性能に関する運用管理情報を含む情報に基づいて異常発生を検出するとともに、異常内容に基づいて障害種別を推定する推定部と、
分析用のパラメータを用いて前記運用管理情報を分析して、前記管理対象装置の障害原因を特定する特定部と、
推定した前記障害種別に対応する障害原因が特定されたか、又は特定した前記障害原因に対応する障害種別が推定されたかを判定する判定部と、
前記判定の結果、推定した前記障害種別に対応する障害原因が特定されなかった、又は特定した前記障害原因に対応する障害種別が推定されなかった場合に、推定した前記障害種別又は特定した前記障害原因に対応するパラメータの優先順位に従って、前記分析用のパラメータを変更する変更部と、
を備える情報処理装置。
（付記６） 前記判定部は、前記異常発生の検出と前記障害原因の特定のタイミングが合っており、特定した前記障害原因が推定した前記障害種別を引き起こすものであるかを判定する、ことを特徴とする付記５に記載の情報処理装置。
（付記７） 前記変更部は、
推定した前記障害種別に対応する障害原因が特定されるように、又は特定した前記障害原因に対応する障害種別が推定されるように、前記分析用のパラメータを変更し、
変更後の前記分析用のパラメータを用いて、過去における異常発生の検出及び過去における障害原因の特定結果に変更が生じなければ、前記分析用のパラメータの変更を確定する、ことを特徴とする付記５又は６に記載の情報処理装置。
（付記８） 前記変更部は、前記分析用のパラメータを変更したことによる効果に関する情報を記憶部に記憶し、前記記憶部に記憶した情報に基づいて、前記優先順位を決定する、ことを特徴とする付記５～７のいずれかに記載の情報処理装置。

１０ ルータ（管理対象装置）
１４ 異常有無判定部（推定部）
１５ 障害原因特定部（特定部）
１６ パラメータ変更必要性判定部（判定部）
１７ パラメータ変更部（変更部）
７０ センサノード（管理対象装置）
１１０ ゲートウェイ（情報処理装置）
１２０ ハブ（管理対象装置）
１３０ Ｗｉ－Ｆｉアクセスポイント（管理対象装置）

Claims (5)

1. 管理対象装置から定期的に収集した前記管理対象装置の性能に関する運用管理情報を含む情報に基づいて異常発生を検出するとともに、異常内容に基づいて障害種別を推定し、
   分析用のパラメータを用いて前記運用管理情報を分析して、前記管理対象装置の障害原因を特定し、
   推定した前記障害種別に対応する障害原因が特定されたか、又は特定した前記障害原因に対応する障害種別が推定されたかを判定し、
   前記判定の結果、推定した前記障害種別に対応する障害原因が特定されなかった、又は特定した前記障害原因に対応する障害種別が推定されなかった場合に、推定した前記障害種別又は特定した前記障害原因に対応するパラメータの優先順位に従って、前記分析用のパラメータを変更する、
   処理をコンピュータが実行することを特徴とする情報処理方法。
2. 前記判定する処理では、前記異常発生の検出と前記障害原因の特定のタイミングが合っており、特定した前記障害原因が推定した前記障害種別を引き起こすものであるかを判定する、ことを特徴とする請求項１に記載の情報処理方法。
3. 前記変更する処理では、
   推定した前記障害種別に対応する障害原因が特定されるように、又は特定した前記障害原因に対応する障害種別が推定されるように、前記分析用のパラメータを変更し、
   変更後の前記分析用のパラメータを用いて、過去における異常発生の検出及び過去における障害原因の特定結果に変更が生じなければ、前記分析用のパラメータの変更を確定する、ことを特徴とする請求項１又は２に記載の情報処理方法。
4. 前記変更する処理において、前記分析用のパラメータを変更したことによる効果に関する情報を記憶部に記憶し、
   前記記憶部に記憶した情報に基づいて、前記優先順位を決定する、処理を前記コンピュータが更に実行することを特徴とする請求項１～３のいずれか一項に記載の情報処理方法。
5. 管理対象装置から定期的に収集した前記管理対象装置の性能に関する運用管理情報を含む情報に基づいて異常発生を検出するとともに、異常内容に基づいて障害種別を推定する推定部と、
   分析用のパラメータを用いて前記運用管理情報を分析して、前記管理対象装置の障害原因を特定する特定部と、
   推定した前記障害種別に対応する障害原因が特定されたか、又は特定した前記障害原因に対応する障害種別が推定されたかを判定する判定部と、
   前記判定の結果、推定した前記障害種別に対応する障害原因が特定されなかった、又は特定した前記障害原因に対応する障害種別が推定されなかった場合に、推定した前記障害種別又は特定した前記障害原因に対応するパラメータの優先順位に従って、前記分析用のパラメータを変更する変更部と、
   を備える情報処理装置。

Images