JP2022045833A - 対処種別推定システム、方法、及びプログラム - Google Patents

Abstract

【課題】保守員の負荷を軽減する。【解決手段】対処種別推定システム１００は、監視サーバ１０３と、対処種別推定サーバ１０２と、を備える。監視サーバ１０３は、監視対象システム１０４で発生した障害に関する障害メッセージを送信する。対処種別推定サーバ１０２は、監視サーバ１０３から受信した障害メッセージに応じた対処種別を、複数の障害メッセージ毎に対処種別を格納した記憶部から機械学習手法を用いて推定する対処種別推定サーバ１０２と、を備える。【選択図】図１

Description

本発明は、対処種別推定システム、方法、及びプログラムに関する。

特許文献１には、事例ＤＢ（データベース）を検索することによって、被監視機器で発生するインシデントへの自動化対応の可否、及び運用形態によるエスカレーション先の分岐を可能とする方法が開示されている。

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

対処種別推定システムは、被監視機器である各監視対象システムから送信された障害メッセージに基づいて、実機対処が必要か、または管理者にエスカレーションを実行するかを判断する。保守員は、対処種別推定システムの判断に応じた対処種別を実行する。対処種別推定システムは、すべての障害メッセージに基づいてすぐに対処種別を判別することができない。対処種別推定システムが対処種別を判別することができない障害メッセージを受信した場合、保守員は、膨大なマニュアルから該当する過去の対処種別の手順があるかを調べたうえで、対処種別を判断する必要がある。このため、監視対象システムの保守作業は、保守員にとって大きな負荷となっている。

特許文献１に記載の技術では、インシデントに基づいて障害に対する対処を決定することができる。しかし、特許文献１に記載の技術では、完全に一致する過去の対処事例が事例ＤＢに格納されていなければ、対処を検索することができない。数多くの被監視機器を備えるデータセンタでは、考慮する要素も膨大になるため、十分な対処事例を事例ＤＢに登録することが難しい。

本発明は、上記課題を解決するためのものであり、その目的は、保守員の負荷を軽減することができる技術を提供することである。

上記目的を達成するために、本発明は、監視対象システムで発生した障害に関する障害メッセージを送信する監視サーバと、前記監視サーバから受信した前記障害メッセージに応じた対処種別を、複数の前記障害メッセージ毎に前記対処種別を格納する記憶部から機械学習手法を用いて推定する対処種別推定サーバと、を備える。

本願発明では、保守員の負荷を低減することができる。

対処種別推定システムの全体構成図。 対処種別推定サーバの機能構成図。 対処推定処理を示すシーケンス図。 対処種別推定処理のフローチャート。 事例データＤＢの構成図。 対処種別推定機能に入力される入力データの構成図。 故障メッセージマスタの構成図。

以下、本願発明の実施例を、図面を用いて詳細に説明する。

図１は、対処種別推定システムの全体構成図である。

対処種別推定システム１００は、「表示端末」の一例としての保守員端末１０１と、対処種別推定サーバ１０２と、監視サーバ１０３とを備えている。保守員端末１０１と、対処種別推定サーバ１０２と、監視サーバ１０３とは、監視対象システム群１０４とネットワークを介して相互に通信可能に接続されている。監視対象システム群１０４は、複数の監視対象システム１～ｎから構成されている。対処種別推定システム１００は、複数の監視対象システム１～ｎの保守運用を実行する、データセンタであってよい。

保守員端末１０１は、画面を備えており、監視対象システム１～ｎの保守業務にあたる従業員等の保守員に画面が操作されて使用される。保守員端末１０１は、ノートＰＣであってよい。しかし、保守員端末１０１は、ノートＰＣに限定されるものではない。保守員端末１０１は、例えば、デスクトップＰＣまたはタブレット端末でもよい。

対処種別推定サーバ１０２は、保守員が実行する対処種別を推定する。対処種別推定サーバ１０２の機能の詳細は、図２に後述する。

監視サーバ１０３は、各監視対象システム１～ｎが有する複数の電子機器を監視する。監視サーバ１０３は、監視対象システム１～ｎでエラーが発生した場合、監視対象システム１～ｎから「障害メッセージ」の一例としてのエラー情報を受信する。

監視対象システム１０４は、サーバ、ストレージ及びスイッチを含む電子機器群から構成されている。各電子機器は、障害が発生した際、エラー情報及び監視対象システム１０４の状態を監視サーバ１０３に送信する。なお、電子機器が送信するメッセージ及び方法は、電子機器毎に異なる。

図２は、対処種別推定サーバの機能構成図である。

対処種別推定サーバ１０２は、演算部２０１と、記憶部２０２とを備えている。演算部２０１は、対処種別推定機能２０３を備えている。記憶部２０２は、事例データベース（以下、事例ＤＢ）２０４と、故障メッセージマスタ２０５とを備えている。

対処種別推定機能２０３は、エラー情報と、監視対象システム１０４の状態とに応じて、保守員が実行する対処種別を推定するための機能である。対処種別推定機能２０３の詳細は、図４で後述する。

事例ＤＢ２０４は、過去にエラーが発生したときのエラー情報及び監視対象システム１０４の状態と、実行した対処種別とを含むデータテーブルである。事例ＤＢ２０４の詳細は、図５で後述する。

故障メッセージマスタ２０５は、監視対象システム１０４のハードウェアで発生した「障害」の一例としての故障を表すイベントＩＤと、監視対象システム１０４のハードウェアで故障が発生したことが報告される連絡先ベンダとをまとめたデータテーブルである。障害は、故障に限定されない。障害は、例えば、通信障害でもよい。故障メッセージマスタ２０５の詳細は、図７で後述する。

図３は、対処種別推定処理を示すシーケンスである。

監視対象システム１０４は、電子機器でエラーが発生した場合、エラー情報を監視サーバ１０３に送信する（Ｓ３０１）。エラー情報には、ＯＳイベントログ（エラーログ）と、ＳＮＭＰトラップ（電子機器の情報）とが含まれてよい。監視サーバ１０３は、受信したエラー情報を入力データのフォーマットに変換し、変換した入力データを対処種別推定サーバ１０２に送信する（送信ステップ；Ｓ３０２）。入力データの詳細は、図６で後述する。

対処種別推定サーバ１０２は、受信した入力データに基づいて、機械学習手法を用いて、事例ＤＢ２０４に格納された複数の対処種別から保守員が実行する対処種別を推定し、推定した対処種別を保守員端末１０１に送信する（Ｓ３０３）。Ｓ３０３の詳細は、図４で後述する。保守員端末１０１は、対処種別推定サーバ１０２から送信された対処種別を画面に表示する。これにより、保守員は、画面に表示された対処種別を確認し、その対処種別を実行することができる。

図４は、対処種別推定処理のフローチャートである。

対処種別推定サーバ１０２は、管理さーな１０３から送信された入力データを受信する（４０１）。対処種別推定サーバ１０２は、まず、監視対象システム１０４のハードウェアの故障メッセージであるかを判別するために、入力データのメッセージＩＤを故障メッセージマスタ２０５と突合する（Ｓ４０２）。対処種別推定サーバ１０２は、メッセージＩＤが故障メッセージマスタ２０５に存在する否かを判定する（Ｓ４０３）。

Ｓ４０３の判定結果が真の場合（Ｓ４０３：ＹＥＳ）、監視対象システム１０４のハードウェアの故障であり、対処種別推定サーバ１０２は、以降の対処種別推定処理を実行しない。このため、対処種別推定サーバ１０２は、故障の内容と連絡先のベンダとを保守員端末１０１に送信する。保守員端末１０１は、受信した故障の内容と連絡先のベンダとを画面に表示し、対処種別推定処理を終了する（Ｓ４０４）。

Ｓ４０３の判定結果が偽の場合（Ｓ４０３：ＮＯ）、対処種別推定サーバ１０２は、入力データに基づいて、対処種別毎のスコアを計算する（選定ステップ：Ｓ４０５）。対処種別推定サーバ１０２は、事例ＤＢ２０４に格納された対処種別毎に機械学習手法による確率モデル(数式の例は別途説明する)を用いてスコアを算出する。スコアが高いほど、正しい対処種別である可能性が高い。このため、対処種別推定サーバ１０２は、スコアが最も高い対処種別を選定し、選定した対処種別を保守員端末１０１に送信する。保守員端末１０１は、受信した対処種別を画面に表示して、対処種別推定処理を終了する。

対処種別には、「対処不要」（Ｓ４０７）と、「実機対処」（Ｓ４０８）と、「エスカレーション」（Ｓ４０９）とが含まれる。「対処不要」は、保守員による対処が不要なメッセージであることを示す。「実機対処」は、マニュアルに沿った実機対処が必要であることを示す。「エスカレーション」は、管理者へのエスカレーションが必要であることを示す。

さらに、どのスコアも低い場合、学習データが不十分であり、正解率が低くなることが想定される。このため、スコアに閾値を設けて、どのスコアも閾値以下であった場合、最も安全である「エスカレーション」を表示する（Ｓ４０９）。閾値は、求められる正解率に応じて運用中にチューニングする必要がある。なお、対処種別は、実際の対処に応じて定義されてよく、前述の３種類以外の項目が含まれてもよい。

例えば、対処種別推定サーバ１０２は、実行した対処種別の対処結果に基づいて閾値を更新してよい。これにより、閾値の精度が高まり、対処種別の推定精度を高めることができる。
さらに、対処種別推定サーバ１０２は、新たに実行した対処種別の対処結果に基づいて記憶部２０２に格納された対処種別を更新してよい。これにより、記憶部２０２に格納された対処種別の精度が高まり、対処種別の推定精度を高めることができる。

図５は、事例ＤＢの構成図である。

事例ＤＢ２０４のデータテーブル５００には、過去に発生した障害の情報が格納されている。事例ＤＢ２０４のデータテーブル５００には、項目値（カラム値）として、Ｆ１ログの種類５０１～Ｆ９サービス起動状態５１０と、Ｃ実行した対処種別５１１と、を含んでよい。

ログの種類５０１は、イベントログの種類を示す列である。レベル５０２は、イベントのレベルを示す列である。イベントＩＤ５０３は、イベントを一意に識別するIDを示す列である。ソース５０４は、イベントの発生元のプロセスを示す列である。エラーコード５０５は、エラーコードを示す列である。変数５０６は、詳細な区別をするための変数を示す列である。発生システム５０７は、発生システムの種類を示す列である。ＣＰＵ状態５０８は、ＣＰＵの使用状況を表す列である。メモリ状態５０９は、メモリ使用状況を表す列である。サービス起動状態５１０は、サービスの起動状態を表す列である。実行した対処種別５１１は、ＯＳイベントに対し過去に実行した対処種別５１２の列である。

一例として、事例ＤＢ２０４のデータテーブル５００の１行目を説明する。１行目は、受信したログの種類５０１が「OS(アプリケーション)」に関するものである。そのときに発生していたイベントのレベル５０２は「警告」、そのイベントID５０３が「0x000A」、ソース５０４が「XXX.exe」、エラーコード５０５が「32」、変数５０６が「10」、発生システム５０７が「A」、CPU状態５０８が「80%未満」、メモリ状態５０９が「80%未満」、サービス起動状態５１０が「ON」であり、このイベントに対し「実機対処(C1)」の対処種別５１１が実行されたことを意味している。

なお、Ｆ１ログの種類５０１～Ｆ９サービス起動状態５１０は、エラーを検出したときに監視サーバ１０３が取得する情報である。対処種別推定システム１００が取得できる情報に応じて項目は変更されてもよい。

図６は、対処種別推定機能に入力される入力データの構成図である。

データテーブル６００には、障害が発生したときに監視サーバ１０３が取得したＦ１ログの種類６０１～Ｆ９サービス起動状態６１０が格納されている。Ｆ１ログの種類６０１～Ｆ９サービス起動状態６１０は、これらの項目値６０１～６１０を用いて事例データからスコアを算出するため、事例ＤＢ２０４のデータデータテーブル５００のＦ１ログの種類５０１～Ｆ９サービス起動状態５１０と同じ項目である。

図７は、故障メッセージマスタの構成図である。

故障メッセージマスタのデータテーブル７００は、監視対象システム２０４のハードウェアが故障したときのイベントＩＤの一覧が格納されている。故障メッセージマスタのデータテーブル７００には、項目値（カラム値）として、ログの種類７０１と、イベントＩＤ７０２と、連絡先７０３と、障害内容７０４と、を含んでよい。ログの種類７０１は、イベントログが発生した出力機種の情報を示す列である。イベントＩＤ７０２は、発生したイベントのＩＤを示す列である。連絡先７０３は、保守員の上位者に報告する連絡先を示す列である。障害内容７０４は、障害内容を示す列である。

一例として、データテーブル７０１の１行目を説明する。１行目は、発生したログの種類７０１が「Server」で、イベントＩＤ７０２が「0x000D」、連絡先７０３がA社で、障害内容７０４が「マザーボード故障」であることを示している。

監視対象システム２０４のハードウェアの故障は、明確なメッセージIDで通知されることが多く、ベンダに保守交換の依頼する対処種別に限られる。このため、対処種別推定サーバ１０２は、対処種別を推定する前に、本データテーブルを用いてＳ４０３を実行する。

ここで、スコアの算出手法について説明する。スコアの算出は、例えば、代表的な確率モデルである、以下の数１～３を用いたナイーブベイズ分類機を採用してよい。

ここで、Ｃ_１～Ｃ_ｎは対処種別（例えば、Ｃ_１は実機対処、Ｃ_２は対処不要、Ｃ_３はエスカレーション）、Ｆ_１～Ｆ_ｍは入力データの各要素の値を表す。

それぞれの対処種別に応じて、入力データの各要素の値が事例データの中で発生している確率の総乗を求めることで、その対処種別のスコアを算出する。スコアが高い程、その対処種別が正解である確率が高いことを表す。このため、全ての対処種別の中で、最も高いスコアの対処種別を選定することによって、対処種別を推定できる。

尚、対処種別の推定手法は、ナイーブベイズ分類機に限定されない。対処種別の推定手法は、あらゆる機械学習手法、または統計手法でもよい。

１００…、１０１…保守員端末、１０２…対処推定サーバ、１０３…監視サーバ、１０４…監視対象システム、２０２…記憶部

Claims (11)

1. 監視対象システムで発生した障害に関する障害メッセージを送信する監視サーバと、
   前記監視サーバから受信した前記障害メッセージに応じた対処種別を、複数の前記障害メッセージ毎に前記対処種別を格納した記憶部から機械学習手法を用いて推定する対処種別推定サーバと、
   を備える対処種別推定システム。
2. 前記対処種別推定サーバは、前記監視サーバから受信した前記障害メッセージのスコアを前記複数の対処種別毎に算出し、算出した前記スコアが最も高い対処種別を前記複数の対処種別から選定する、
   請求項１に記載の対処種別推定システム。
3. 前記障害メッセージには、識別情報が含まれており、
   前記対処種別推定サーバは、前記監視サーバから受信した前記障害メッセージの識別情報が前記記憶部に格納された前記複数の障害メッセージのうちの何れかの障害メッセージの識別情報と一致する場合、
   前記対処種別推定サーバは、前記対処種別を推定する前に、前記識別情報が一致した対処種別を前記対処種別として選定する
   請求項１に記載の対処種別推定システム。
4. 前記対処種別には、保守員の上位者に報告するエスカレーションが含まれており、
   前記対処種別推定サーバは、前記スコアが閾値未満の場合、前記エスカレーションを前記対処種別として選択する。
   請求項２に記載の対処種別推定システム。
5. 前記対処種別推定サーバは、実行した前記対処種別の対処結果に基づいて前記閾値を更新する、
   請求項４に記載の対処種別推定システム。
6. 前記対処種別推定サーバが選定した前記対処種別を受信し、受信した前記対処種別を保守員に表示する表示端末を更に備える、
   請求項１に記載の対処種別推定システム。
7. 前記対処種別には、前記保守員による対応が必要な実機対処が含まれており、
   前記対処種別推定サーバは、推定した前記対処種別が前記実機対処であり、且つ前記スコアが前記閾値以上である場合、推定した前記対処種別を前記表示端末に送信する、
   請求項４に記載の対処種別推定システム。
8. 前記対処種別には、前記保守員による対応が不要な対処不要が含まれており、
   前記対処種別推定サーバは、推定した前記対処種別が前記対処不要であり、且つ前記スコアが前記閾値以上である場合、前記対処不要である旨を前記表示端末に送信する、
   請求項４に記載の対処種別推定システム。
9. 前記対処種別推定サーバは、新たに実行した前記対処種別の対処結果に基づいて前記記憶部に格納された前記対処種別を更新する、
   請求項１に記載の対処種別推定システム。
10. 監視対象システムで発生した障害に関する障害メッセージを送信し、
    受信した前記障害メッセージのスコアを、複数の前記障害メッセージ毎に記憶部に格納された対処種別毎に算出し、算出した前記スコアが最も高い対処種別を前記記憶部から選定する対処種別推定方法。
11. 監視サーバと、監視対象システムで発生した障害に関する複数の障害メッセージ毎に対応種別を格納する記憶部を有する対処種別推定サーバとを備える対処種別推定システムのプログラムであって、
    前記監視サーバに、前記障害メッセージを送信する送信ステップを実行させ、
    前記対処種別推定サーバに、受信した前記障害メッセージのスコアを複数の前記対処種別毎に算出し、算出した前記スコアが最も高い対処種別を前記記憶部から選定する選定ステップを実行させる対処種別推定システムのプログラム。
    
    

Images