特開 2022-170879 故障原因推定システム、及び故障原因推定方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022170879

(43)【公開日】2022-11-11

(54)【発明の名称】故障原因推定システム、及び故障原因推定方法

(51)【国際特許分類】

   G06Q 50/10 20120101AFI20221104BHJP

【ＦＩ】

G06Q50/10

【審査請求】未請求

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2021077151

(22)【出願日】2021-04-30

(71)【出願人】

【識別番号】000233295

【氏名又は名称】株式会社日立情報通信エンジニアリング

(74)【代理人】

【識別番号】110002365

【氏名又は名称】特許業務法人サンネクスト国際特許事務所

(72)【発明者】

【氏名】王 夢如

(72)【発明者】

【氏名】吉田 美徳

(72)【発明者】

【氏名】張 程

【テーマコード（参考）】

5L049

【Ｆターム（参考）】

5L049CC15

(57)【要約】      （修正有）

【課題】対象システムのインシデント管理において、属人化の解消と、故障対応作業の効率化と、を両立した故障原因推定システムを提供する。
【解決手段】故障原因推定システム１において、システム監視部１０は、複数の機器から構成されたシステムを対象に監視する。実データ収集部２０は、システムを監視した監視データをシステム監視部１０から取得し記憶する。学習部４０は、実データ収集部２０からの監視データに基づいて故障原因推定モデルを作成する。故障原因検出部３０は、システム監視部１０から取得する監視データと故障原因推定モデルとから、システムの故障原因を特定する。
【選択図】図１

【特許請求の範囲】

【請求項1】

複数の機器から構成されたシステムを対象に監視するシステム監視部と、
前記システムを監視した監視データを前記システム監視部から取得し記憶する実データ収集部と、
前記実データ収集部からの前記監視データに基づいて故障原因推定モデルを作成する学習部と、
前記システム監視部から取得する前記監視データと、前記故障原因推定モデルと、から前記システムの故障原因を特定する故障原因検出部と、を備える
故障原因推定システム。

【請求項2】

請求項１に記載の故障原因推定システムであって、
前記監視データは、前記システムの稼働状況を表す稼働状況監視データと、前記システムの故障現象を表す現象監視データと、を含み、
前記実データ収集部は、前記システムが正常に動作しているときの前記稼働状況監視データから、前記システムの機器間の依存関係を導出する機器間依存関係導出部を有する
故障原因推定システム。

【請求項3】

請求項２に記載の故障原因推定システムであって、
前記機器間依存関係導出部は、前記複数の機器のうち第１の機器から第２の機器へデータが送信されることが観測される場合、前記第２の機器は前記第１の機器に依存すると定義し、通信関係のない前記機器間には前記依存関係を定義しない
故障原因推定システム。

【請求項4】

請求項２に記載の故障原因推定システムであって、
前記実データ収集部は、前記複数の機器に対して、様々な種類の故障を疑似的に生成する故障生成部を有し、
前記学習部は、疑似的に生成された前記故障と前記依存関係とに基づいて、前記機器間において前記故障に関連する障害が発生する機器の順番である故障発生経路を特定する学習データ前処理部を有する
故障原因推定システム。

【請求項5】

請求項４に記載の故障原因推定システムであって、
前記学習部は、前記学習データ前処理部で特定された前記故障発生経路に基づいて前記故障原因推定モデルを作成するモデル学習部を有する
故障原因推定システム。

【請求項6】

請求項５に記載の故障原因推定システムであって、
前記学習データ前処理部は、前記故障発生経路の特定を、前記複数の機器のうち、前記依存関係において最も下流の機器から開始し、
まず、特定対象の前記機器に前記障害の発生があるかどうかを確認し、次に、前記依存関係の階層構造において、特定対象の前記機器と同じ階層にあるすべての機器に前記障害の発生があるかどうかを確認し、その確認を終えると、一つ上の階層の機器において前記障害の発生があるかどうかを確認するサイクルを繰り返す
故障原因推定システム。

【請求項7】

請求項５に記載の故障原因推定システムであって、
前記学習データ前処理部は、ランダムに前記故障発生経路を一つ選定して、前記故障発生経路上の機器を他の機器に置き換えてネガティブサンプルを作成し、
前記学習部は、前記現象監視データ、前記故障発生経路および前記ネガティブサンプルに基づいて前記故障原因推定モデルを作成する
故障原因推定システム。

【請求項8】

請求項５に記載の故障原因推定システムであって、
前記学習データ前処理部は、ランダムに前記故障発生経路を一つ選定して、前記故障発生経路と関連している前記故障現象を別の現象と置き換えてネガティブサンプルを作成し、
前記学習部は、前記現象監視データ、前記故障発生経路および前記ネガティブサンプルに基づいて前記故障原因推定モデルを作成する
故障原因推定システム。

【請求項9】

複数の機器から構成されたシステムを対象に監視し、正常な動作時の前記システムの稼働状況から前記システムの機器間の依存関係を導出する第１のステップと、
前記システムの前記複数の機器に対して様々な種類の故障を疑似的に生成する第２のステップと、
疑似的に生成された前記故障と前記依存関係とに基づいて、前記機器間において前記故障に関連する障害が発生する機器の順番である故障発生経路を特定し、特定された前記故障発生経路に基づいて故障原因推定モデルを作成する第３のステップと、
前記故障原因推定モデルを用いて前記システムの故障原因を推定する第４のステップと、を有する
故障原因推定方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、故障原因推定システム、及び故障原因推定方法に関する。

【背景技術】

【0002】

近年、ＩＴ機器の分野でのシステムの規模の拡大および複雑化に伴い、システムログをはじめとした運用データが大規模化しており、それらを監視するために、システムの運用に求められる人的コストが増大の一途をたどっているという問題を抱えている。特に、システム障害の対応での原因究明を行うために、対応するシステム管理オペレーターには深い知識と経験が求められているが、そのような人材を早期に育成することが困難な課題も重なり、インシデント管理において、運用データの監視の一部または全部を自動化する動きが見られる。

【0003】

本願発明の背景技術として、下記の特許文献１では、装置の故障原因を提示する故障原因提示技術に関し、故障原因を推定するために、ログデータの単位時間当たりの変化が正常か否かを判別する手段が開示されている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００３－２１６２３８号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

特許文献１に記載の技術では、機器の故障の際に観測される現象と故障原因の関連付けを行う際、機器間の依存関係に基づく故障発生の経路を考慮できずに、適切な現象と故障原因の関連付けができない可能性がある。また、システム管理者が行う既存の故障原因探索方法として、キーワード入力での過去事例検索があるが、この手段には、キーワード入力者のキーワード選定の恣意性が含まれることによって、有効な過去事例を特定するという保証が薄く、正確な故障原因を特定するための対応作業に時間がかかることが課題である。

【0006】

これを鑑みて本発明は、対象システムのインシデント管理において、属人化の解消と、故障対応作業の効率化と、を両立した故障原因推定システムおよび故障原因推定方法を提供することが目的である。

【課題を解決するための手段】

【0007】

本発明の故障原因推定システムは、複数の機器から構成されたシステムを対象に監視するシステム監視部と、前記システムを監視した監視データを前記システム監視部から取得し記憶する実データ収集部と、前記実データ収集部からの前記監視データに基づいて故障原因推定モデルを作成する学習部と、前記システム監視部から取得する前記監視データと、前記故障原因推定モデルと、から前記システムの故障原因を特定する故障原因検出部と、を備える。
また、本発明の故障原因推定方法は、複数の機器から構成されたシステムを対象に監視し、正常な動作時の前記システムの稼働状況から前記システムの機器間の依存関係を導出する第１のステップと、前記システムの前記複数の機器に対して様々な種類の故障を疑似的に生成する第２のステップと、疑似的に生成された前記故障と前記依存関係とに基づいて、前記機器間において前記故障に関連する障害が発生する機器の順番である故障発生経路を特定し、特定された前記故障発生経路に基づいて故障原因推定モデルを作成する第３のステップと、前記故障原因推定モデルを用いて前記システムの故障原因を推定する第４のステップと、を有する。

【発明の効果】

【0008】

対象システムのインシデント管理において、属人化の解消と、補修作業の効率化と、を両立した故障原因推定システムおよび故障原因推定方法を提供できる。

【図面の簡単な説明】

【0009】

【図1】本発明の一実施形態に係る、故障原因推定システムのブロック図。

【図2】本発明の一実施形態に係る、故障発生経路の探索を説明する図。

【図3】対象システム１１での各機器間の通信関係を示す図。

【図4】故障原因推定モデル作成のための学習データの前処理を説明するための図。

【図5】学習部の処理手順を説明するためのフローチャート。

【図6】実データ収集部を説明するためのフローチャート。

【0010】

以下、図面を参照して本発明の実施形態を説明する。以下の記載および図面は、本発明を説明するための例示であって、説明の明確化のため、適宜、省略および簡略化がなされている。本発明は、他の種々の形態でも実施する事が可能である。特に限定しない限り、各構成要素は単数でも複数でも構わない。

【0011】

図面において示す各構成要素の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面に開示された位置、大きさ、形状、範囲などに限定されない。

【0012】

（一実施形態と故障原因推定システムの構成）
図１は、本発明の一実施形態に係る、故障原因推定システムのブロック図である。

【0013】

故障原因推定システム１は、システム監視部１０、実データ収集部２０、故障原因検出部３０、学習部４０、を有する。

【0014】

システム監視部１０は、稼働状況監視部１２、現象監視部１３、を有し、監視対象となる複数の機器から構成された任意の対象システム１１の稼働状況を監視している。なお、対象システム１１の稼働状況とは、例えば、ＣＰＵ使用量、メモリー使用量、ディスク使用量、機器間の通信量といったメトリックス、もしくは、ログメッセージなどを指す。

【0015】

対象システム１１は、サーバ、データベースなどの複数の機器から構成され、構成要素である各機器の稼働状況を時系列順に出力する機能を有している。

【0016】

稼働状況監視部１２は、対象システム１１の稼働状況を表すデータ（稼働状況監視データ）であるメトリックスやログメッセージを、時系列順に沿って収集して監視する機能を備える。稼働状況監視部１２は、対象システム１１を、ログメッセージの緊急度やメトリックスごとに定められた閾値をもとに、故障が発生していないかどうか監視する。

【0017】

稼働状況監視部１２は、対象システム１１が正常に動作している場合は、実データ収集部２０の入力受付部２８に稼働状況監視データを送信し、対象システム１１で故障が検知された場合は、実データ収集部２０の故障時稼働状況記憶部２２に故障時の稼働状況監視データを送信する。

【0018】

現象監視部１３は、故障発生時に対象システム１１のユーザであるクライアントから観測された現象について、画像、数値データ、ログメッセージ、入力されたテキストのメッセージを受信する機能を備えている。これらの観測データ（現象監視データ）は、実データ収集部２０の故障時稼働状況記憶部２２に送信される。また、これらの観測データは、故障原因検出部３０にも送信され、システム管理者に対して対象システム１１が故障している警告を発信する。

【0019】

実データ収集部２０は、対象システム１１が正常に動作している場合に用いられる、入力受付部２８と正常時稼働状況記憶部２１と機器間依存関係導出部２３と依存関係記憶部２５と故障生成部２７と、対象システム１１の故障発生時に用いられる、故障時稼働状況記憶部２２と故障機器検出部２４と故障データ記憶部２６と、を有する。

【0020】

対象システム１１が正常に動作している場合の実データ収集部２０の各機能部について説明する。入力受付部２８では、対象システム１１のユーザであるクライアントからの命令を受け付ける。この命令は、対象システム１１の現象についてのテキストデータであり、例えば、自然言語で入力された入力内容、画面タッチ式のボタンによって入力された入力内容などである。入力受付部２８は、入力された命令に従って、対象システム１１の稼働状況を監視した稼働状況監視データを、受け付けるかどうかを判断する機能を備えている。なお、対象システム１１が正常に動作する場合、データを多く出力することが見込まれているため、データ過多を避けるためにユーザによって指定された一定期間のデータのみ受け付ける。

【0021】

正常時稼働状況記憶部２１は、入力受付部２８で取得した対象システム１１の稼働状況監視データ（メトリックス）を収集し、格納する機能を有する。

【0022】

機器間依存関係導出部２３は、正常時稼働状況記憶部２１に格納された対象システム１１の稼働状況を表すメトリックスに基づき、対象システム１１を構成する各機器間の通信によって決まる機器間の依存関係を導出する機能を備える。なお、一般的な統計的な手法を用いて機器間の依存関係を導出してもよい。

【0023】

機器間の依存関係とは、例えば、機器k_nから機器k_mへと、データが送信されることが観測される場合、機器k_mがk_nに依存すると定義する。なお、それらの機器間の関係を、k_m→k_nと表記する。通信方向が逆の場合は、機器k_nがk_mに依存（k_n→k_m）する。また、通信しない機器の間に依存関係は存在しないと定義される。

【0024】

依存関係記憶部２５は、機器間依存関係導出部２３が出力した機器間の依存関係を格納する機能を備える。また、依存関係記憶部２５は格納した依存関係を、故障生成部２７、故障データ記憶部２６、学習部４０の学習データ前処理部４１、に送信する。

【0025】

故障生成部２７は、対象システム１１の構成要素である各機器に対して、疑似的に障害を引き起こす機能を備える。故障生成部２７を用いて疑似的に障害を引き起こす目的は、対象システム１１の機器のパフォーマンスを監視するためであり、疑似的な障害で対象システム１１に故障が出た場合、それが対象システム１１の故障として稼働状況監視部１２により検知され、後述の故障時稼働状況記憶部２２に、故障の種類と、対象システム１１の稼働状況に関する稼働状況監視データと、故障発生時にクライアントで観測された現象に関する現象監視データとが、システム１１を監視して得られた監視データとして格納される。

【0026】

なお、故障生成部２７が引き起こす人工的な障害の種類は、例えば、データベースに負荷をかけることにより引き起こされた障害、メモリーリソースを消耗することにより引き起こされた障害、リクエスト数を異常まで増やすことにより引き起こされた障害、停電により引き起こされた障害、などである。

【0027】

つづいて、対象システム１１に故障が発生している場合の実データ収集部２０の各機能部について説明する。故障時稼働状況記憶部２２は、対象システム１１の故障時に、対象システム１１の稼働状況を表す稼働状況監視データであるメトリックスを稼働状況監視部１２から、対象システム１１のユーザであるクライアント側から観測された故障現象を表す現象監視データを現象監視部１３から、それぞれ収集して格納する機能を有する。

【0028】

故障機器検出部２４は、故障時稼働状況記憶部２２に格納されたこれらのデータをもとにして、故障生成部２７から対象システム１１の各機器へ引き起こされた疑似的な障害が、各機器で起きたかどうかの判断を行う機能を備える。例えば、対象システム１１が有する機器k_tには、観測メトリックスが数種類あるとする。故障機器検出部２４では、各機器に付随するすべてのメトリックスに対して、時系列に沿って、障害発生の判別を行う障害発生判別に用いる指標として、事前に定めた閾値を用いる。そして、一定期間内において、メトリックスの観測値と、正常時に観測された値の平均値との差分の累積和が、閾値を超える場合、機器k_tに障害が起きたと判断する。なお、正常時に観測された値の平均値は、正常時稼働状況記憶部２１に格納されたデータをもとに算出できる。

【0029】

故障データ記憶部２６は、故障機器検出部２４で検知された故障機器と、故障時稼働状況記憶部２２に格納された故障現象とのペアを示すデータを格納する。また、故障機器検出部２４において故障機器が複数検出された場合、故障データ記憶部２６は、依存関係記憶部２５に格納されている機器間の依存関係に従い故障機器の前後関係を決め、故障機器と故障時に観測された現象とのペアを示すデータを格納する。

【0030】

学習部４０は、故障時に観測された現象から故障原因を推定するために、故障原因推定モデルの学習を行う機能部である。学習部４０は、学習データ前処理部４１、モデル学習部４２、経路選択部４３、モデル記憶部４４、を備えている。

【0031】

学習データ前処理部４１は、故障原因推定モデルの学習を行うための学習データ（特定した故障発生経路）を用意する機能を備える。学習データ前処理部４１では、学習データを用意するために、実データ収集部２０の故障データ記憶部２６から故障時の観測現象と故障機器のペアを示すデータを、依存関係記憶部２５から機器間の依存関係を、それぞれ読み込む。学習データ前処理部４１は、それらの情報に基づいて故障に関連する障害が発生する機器の順番を決めて（ソーティング）、故障発生経路を特定し、故障原因推定モデルの学習を行うための学習データを用意する。

【0032】

故障発生経路の特定とは、機器間の依存関係でみるときに、最も下流にある機器から、故障の根本的な原因（root cause）と思われる機器の方向へ故障原因を探索して、機器名のシーケンスを抽出していくことである。

【0033】

モデル学習部４２は、学習データ前処理部４１で特定した故障発生経路をもとに、故障原因推定モデルの学習を行う機能を備える。

【0034】

経路選択部４３は、モデル学習部４２で学習された故障原因推定モデルを基にして、複数に存在する故障発生経路から現象に対応する経路のみを抽出する。

【0035】

モデル記憶部４４は、モデル学習部４２で学習済みのモデルを格納する機能を備えている。モデル記憶部４４に格納した学習済みの故障原因推定モデルは、故障原因検出部３０において、対象システム１１の故障原因の特定に用いられる。

【0036】

故障原因検出部３０は、管理者インターフェース３１と、故障原因特定部３２と、原因表示部３３と、経路表示部３４と、出力インターフェース３５と、を備えている。

【0037】

管理者インターフェース３１は、現象監視部１３から送信された対象システム１１の故障時の現象のデータを基に、故障に関する警報を管理者に知らせる機能を備える。

【0038】

故障原因特定部３２は、モデル記憶部４４から学習済みの故障原因推定モデルを、管理者インターフェース３１から出力される故障に関する警報を、それぞれ読み込み、類似事例を特定することで故障原因について特定を行う機能を備える。具体的には、学習済みの故障原因推定モデルによって示される故障時の観測現象と故障発生経路の関係を用いて、警報が出力された故障に対応する故障発生経路を予測する。これにより、対象システム１１で起きた故障原因を適切に推定する。

【0039】

原因表示部３３は、故障原因特定部３２から出力された推定原因の候補を、推定確率順でランキングして、出力インターフェース３５で対象システム１１の管理者に表示するためのコンテンツを用意する機能を備える。

【0040】

経路表示部３４は、故障原因特定部３２から出力された推定原因に関連した故障発生経路を、出力インターフェース３５で対象システム１１の管理者に表示するためのコンテンツを用意する機能を備える。

【0041】

出力インターフェース３５は、原因表示部３３と経路表示部３４とから送信されたコンテンツを、対象システム１１の管理者に提示する機能を備える。

【0042】

図２は、本発明の一実施形態に係る、故障発生経路の探索を説明する図である。また、図３は、対象システム１１での各機器間の通信関係を示す図である。また、図４は、故障原因推定モデル作成のための学習データの前処理を説明するための図である。また、図５は、学習部４０での処理手順を説明するためのフローチャートである。なお、図５の処理フローチャートは、図２～図４の説明に合わせて適宜フローを説明する。

【0043】

学習データ前処理部４１は、対象システム１１に異常が検知されると、その異常の原因を示す故障発生経路の探索のために、依存関係記憶部２５から読み込んだ機器間の依存関係において最も上流の機器（ノード）に異常があるかどうかを調べる。図２では、機器間の依存関係の最上流側にあたる機器（ノード）はｍ２である。しかし、このときｍ２を起点とする複数の経路が存在すると、故障現象として各経路の下流の階層にそれぞれ位置する機器（ノード）ｍ０、ｍ１、ｍ３にも異常が検出されることになり、これらの機器（ノード）ｍ０、ｍ１、ｍ３に同じタイミングで障害が起きる可能性もある。したがって、各機器（ノード）の異常を個別に判断すると、対象システム１１に起きている異常とは関係のない機器（ノード）まで異常であるという検出がされてしまうことがある。

【0044】

よって、図２では、故障データ記憶部２６から読み込んだデータが示す故障機器を含むすべての依存関係について、故障発生経路に該当するか否かを最も下流側の機器（ノード）から一つずつ調べる必要がある。図２で具体的に説明すると、最も下流側の機器（ノード）ｍ０から調べて、ｍ０→ｍ１、ｍ０→ｍ２、ｍ０→ｍ３、とそれぞれの依存関係を調べる。図２ではｍ０→ｍ２の依存関係に異常があることがわかった。このようにすることで、異常が検知されたときの現象と故障発生経路のペアを作ることができた。

【0045】

なお、以上のように調べて問題がない場合は、機器間の依存関係において同じ階層であるその隣の機器(ノード）に遷移して調べる。図２で具体的に説明すると、ｍ０ではなくｍ４から調べるということである。さらに、同じ階層にあるすべての機器に障害の発生があるかどうかを確認し、その確認を終えると、一つ上の階層の機器において障害の発生があるかどうかを確認するサイクルを繰り返す。このように、同じ機器間の依存関係において階層の機器（ノード）はすべて調べられ、依存元となる機器（ノード）がなくなるまで、もしくは、障害機器がなくなるまで繰り返して探索を続ける。このような手順によって、故障時の現象とそれに対応している故障発生経路のペアが得られる。この現象と故障発生経路のペアは、モデル学習部４２において故障原因推定モデルの作成および学習に利用される。

【0046】

また、故障原因の経路探索においては、経路の特定だけではなく、ネガティブサンプルを作り、同じタイミングで起きた別の種類の故障との区別をする。

【0047】

ネガティブサンプル作成方法は２つある。ネガティブサンプル作成方法の１つは、故障
データ記憶部２６から取得した故障時の現象とそれに対応している故障発生経路のペアである学習サンプルから、ランダムにサンプルを一つ選定して、経路上の機器を他の機器に置き換えることにより、ネガティブサンプルを作成する方法である。例えば、図２で具体的に説明すると、ｍ０→ｍ２の依存関係をｍ０→ｍ４という依存関係に置き換えて、ｍ４を異常のある機器（ノード）として新たな故障経路を作成し学習させる方法である。

【0048】

もう一つのネガティブサンプル作成方法は、学習サンプルから、ランダムにサンプルを一つ選定して、そのサンプルに書かれている故障現象を、別の現象と置き換える方法である。具体的には、ＢＬＥＵ（Bilingual Evaluation Understudy）や、ＲＩＢＥＳ（Rank-based Intuitive Bilingual Evaluation Score）などのテキスト類似度評価指標を用いて、現象の集合から当該故障時の現象と最も類似性の高い現象を抽出して置き換える。これにより、現象が似ているが故障原因が違うものを区別することができる。以上のネガティブサンプル作成により、効率よく学習を行うことができる。

【0049】

図３を用いて、実際の機器間の通信に置き換えて故障時の現象とそれに対応している故障発生経路のペアの特定を説明する。図３は、対象システム１１をそれぞれ構成するデータベースサーバ１０１、アプリケーションサーバ（支払いサービス）１０２、アプリケーションサーバ（オンラインゲーム）１０３、ウェブサーバデータベースサーバ１０４について、それぞれの機器（ノード）での通信関係が示されている。ここで、例えば、まず「支払いができない」という現象については、原因が図３のアプリケーションサーバ（支払いサービス）１０２側にあると判定し学習する。これを学習データグループ１とする。

【0050】

上記２つの作成方法のいずれかにより作成されたネガティブサンプルは、モデル学習部４２において、学習データ前処理部４１で得られた故障現象と故障発生経路のペアとともに、故障原因推定モデルの作成および学習に利用される。すなわちモデル学習部４２は、対象システム１１の故障時に得られた現象監視データおよび故障発生経路と、その故障発生経路から作成されたネガティブサンプルとに基づいて、故障原因推定モデルを作成、学習する。これにより効率よく故障原因推定モデルの作成や学習を行うことが可能になる。

【0051】

学習データグループ１を学習したあと、故障経路が複数存在する学習データグループ２について学習する。具体的には、学習データグループ１の学習のあと「支払い情報が閲覧できない」という現象が起きたとすると、図３において、アプリケーションサーバ（支払いサービス）１０２だけでなく、アプリケーションサーバ（オンラインゲーム）１０３にも原因がある可能性がある。しかし、これと似た現象である「支払いができない」という現象が前述した学習データグループ１で学習済みのため、「支払い情報が閲覧できない」という現象はアプリケーションサーバ（支払いサービス）１０２と関連度が高いと判断できる。このようにすることで、故障時の現象とそれに対応している故障発生経路のペアを取得したうえ、故障原因推定モデルの学習を行うことができる。

【0052】

なお、複数の機器があり、手前の機器から奥の機器の順番で異常のあるものを調べていく際に、次の訪問対象になるすべての機器に対してスコアを計算し、このスコアが最も低いノードをｙ_ｔとして次の訪問対象にする。ｙ_ｔは、後の計算で用いる。

【0053】

図４では、図２、図３で説明した故障時の現象と故障経路の対応付け（マッピング）を導き出すための処理について示されている。なお、現象４２１は対象システム１１のユーザであるクライアントが、現象についてテキスト（自然言語）で入力した内容が示されている。また、故障原因経路４２２は、図３での機器名から構成され、データベースサーバ１０１→アプリケーションサーバ（支払いサービス）１０２→ウェブサーバデータベースサーバ１０４という故障発生経路を表している。

【0054】

学習部４０の学習データ前処理部４１において、故障原因推定モデルの処理手順の第１段階として、抽出された故障原因経路４２２と現象４２１のペアが、エンコーダ４２３で、それぞれベクトル表現（４２４、４２５）に変換される。変換されたベクトル表現４２４，４２５を用いて下記の損失関数の式によって学習を行う。

【0055】

【数1】

【0056】

モデル学習部４２では、現象のベクトル表現ｘ_i４２４と、故障経路のベクトル表現ｙ_i４２５のマッチングを行い、損失関数の式によって算出したパラメータＷを学習する。このパラメータＷから、故障原因を推定し、発生経路と対応付け（マッピング）をする。

【0057】

損失関数のｙ_i ^′とは、ネガティブサンプルであり、前述したネガティブサンプルに基づく学習を行うことで、さらに学習を効率的に行うことが可能になる。これによって、例えば、ある現象とそれに対応している故障経路の間の距離（関連性）を縮めるほか、当該現象と対応していない故障経路の間の距離（関連度）を離すことができる。

【0058】

経路選択部４３は、前述した学習データグループ１にある個々のサンプルに対して、複数に存在する故障経路から、現象に対応する経路のみを抽出する作業を行う（前述した学習データグループ２）。具体的には以下の式を用いる。

【0059】

【数2】

【0060】

この式を用いることで、最適な経路を探索していく際に、同じ階層にある複数の機器に同時に障害が検出されたときに、提示された現象と最も関連性の高い機器を選択する効果がある。式２にしたがって、学習データグループ２にある個々のサンプルに対して経路選択を行った後、ネガティブサンプルを作成し、故障原因推定モデルの学習を行う。

【0061】

図６は、実データ収集部２０を説明するためのフローチャートである。

【0062】

故障生成部２７は、まず、対象システム１１の各機器に対して、疑似的に故障を引き起こし（ステップＳ２０１）、故障時の稼働状況データ（メトリックス）を収集する（ステップＳ２０２）。ステップＳ２０１とステップＳ２０２のフローは、対象システム１１の各機器に繰り返し行われる。

【0063】

次に、システム監視部１０の稼働状況監視部１２により、対象システム１１に障害が起きたか否かを判定する（ステップＳ２０３）。対象システム１１に障害が起きたと判定された場合は、実データ収集部２０の故障時稼働状況記憶部２２に、故障発生時の対象システム１１の機器の稼働状況を表すすべてのメトリックスを、対象システム１１の稼働状況を表す稼働状況監視データとして記録する（ステップＳ２０９）。そうでなければ、ステップＳ２０４へ進む。

【0064】

ステップＳ２０９に進んだ場合、対象システム１１の各機器が故障したかどうかの判別をする（ステップＳ２１０）。この判別には、事前に設定された閾値などが使われる。当該機器ｉに故障が起きたと判別された場合「１」とラベルを振る（ステップＳ２１１）。そうでない場合は「０」とラベルを振る（ステップＳ２１２）。機器ｉのラベル（０、１）と機器名を対応付けしたら、これらのデータをステップＳ２０９で記録したメトリックスと関連付けて、実データ収集部２０の故障データ記憶部２６に格納する（ステップＳ２１３）。このステップＳ２１０～ステップＳ２１３までのフローは、対象システム１１の各機器すべてに対して行われる。

【0065】

ステップＳ２０３において、対象システム１１に故障が検知されなかった場合、対象システム１１のユーザによって入力された命令に従って（ステップＳ２０４）、正常時の稼働状況を正常時稼働状況記憶部２１にて格納する（ステップＳ２０５）。また、ユーザによって入力された命令に従って（ステップＳ２０４）、機器間の通信状況を取得し（ステップＳ２０６）、そこから機器間の依存関係を抽出する（ステップＳ２０７）。最後に、抽出された機器間の依存関係に関する情報を依存関係記憶部２５に記録する（ステップＳ２０８）。

【0066】

以上のように、故障発生時に、故障原因に着目した類似事例を特定することができ、故障原因だけでなく、判断の根拠を提示するために故障発生経路についてもシステムユーザに提示することができるため、確認作業の効率化を図ることができる。さらに、故障原因と故障発生時の現象との対応関係を学習することができるため、さらに対応の迅速化と効率化を図れる。

【0067】

以上説明した本発明の一実施形態によれば、以下の作用効果を奏する。

【0068】

（１）故障原因推定システム１は、複数の機器から構成されたシステム１１を対象に監視するシステム監視部１０と、システム１１を監視した監視データをシステム監視部１０から取得し記憶する実データ収集部２０と、実データ収集部２０からの監視データに基づいて故障原因推定モデル１を作成する学習部４０と、システム監視部１０から取得する監視データと、故障原因推定モデルと、からシステ１１ムの故障原因を特定する故障原因検出部２４と、を備える。このようにしたことで、対象システム１１のインシデント管理において、属人化の解消と、補修作業の効率化と、を両立した故障原因推定システム１を提供できる。

【0069】

（２）故障原因推定システム１は、監視データは、システム１１の稼働状況を表す稼働状況監視データと、システム１１の故障現象を表す現象監視データと、を含み、実データ収集部２０は、システム１１が正常に動作しているときの稼働状況監視データから、システム１１の機器間の依存関係を導出する機器間依存関係導出部２３を有する。このようにしたことで、故障発生経路を推定するための機器間の関係性を定義できる。

【0070】

（３）機器間依存関係導出部２３は、複数の機器のうち第１の機器から第２の機器へデータが送信されることが観測される場合、第２の機器は第１の機器に依存すると定義し、通信関係のない機器間には依存関係を定義しない。このようにしたことで、故障発生経路を推定する準備ができる。

【0071】

（４）実データ収集部２０は、複数の機器に対して、様々な種類の故障を疑似的に生成する故障生成部２７を有し、学習部４０は、疑似的に生成された故障と機器間の依存関係とに基づいて、機器間において故障に関連する障害が発生する機器の順番である故障発生経路を特定する学習データ前処理部４１を有する。このようにしたことで、故障発生経路を推定する準備を行い、故障原因推定モデルの学習を行うための学習データを用意することができる。

【0072】

（５）学習部４０は、学習データ前処理部で特定された故障発生経路に基づいて故障原因推定モデルを作成するモデル学習部４２を有する。このようにしたことで、故障原因推定モデルの学習を行うことができる。

【0073】

（６）学習データ前処理部４１は、故障発生経路の特定を、複数の機器のうち、依存関係において最も下流の機器から開始し、まず、特定対象の機器に障害の発生があるかどうかを確認し、次に、依存関係の階層構造において、特定対象の機器と同じ階層にあるすべての機器に障害の発生があるかどうかを確認し、その確認を終えると、一つ上の階層の機器において障害の発生があるかどうかを確認するサイクルを繰り返す。このようにしたことで、確実に故障発生経路を推定することができる。

【0074】

（７）学習データ前処理部４１は、ランダムに故障発生経路を一つ選定して、故障発生経路上の機器を他の機器に置き換えてネガティブサンプルを作成し、学習部４０は、現象監視データ、故障発生経路およびネガティブサンプルに基づいて故障原因推定モデルを作成する。このようにしたことで、同じタイミングで起きた別の種類の故障との区別をすることができる。

【0075】

（８）学習データ前処理部４１は、ランダムに故障発生経路を一つ選定して、故障発生経路と関連している故障現象を別の現象と置き換えてネガティブサンプルを作成し、学習部４０は、現象監視データ、故障発生経路およびネガティブサンプルに基づいて故障原因推定モデルを作成する。このようにしたことで、現象が似ているが故障原因が違うものを区別することができる。

【0076】

（９）故障原因推定方法は、複数の機器から構成されたシステム１１を対象に監視し、正常な動作時のシステム１１の稼働状況からシステム１１の機器間の依存関係を導出する第１のステップと、システム１１の複数の機器に対して様々な種類の故障を疑似的に生成する第２のステップと、疑似的に生成された故障と依存関係とに基づいて、機器間において故障に関連する障害が発生する機器の順番である故障発生経路を特定し、特定された故障発生経路に基づいて故障原因推定モデルを作成する第３のステップと、故障原因推定モデルを用いてシステム１１の故障原因を推定する第４のステップと、を有する。このようにしたことで、対象システム１１のインシデント管理において、属人化の解消と、補修作業の効率化と、を両立した故障原因推定方法を提供できる。

【0077】

なお、本発明は上記の実施形態に限定されるものではなく、その要旨を逸脱しない範囲内で様々な変形や他の構成を組み合わせることができる。また本発明は、上記の実施形態で説明した全ての構成を備えるものに限定されず、その構成の一部を削除したものも含まれる。

【符号の説明】

【0078】

１ 故障原因推定システム
１０ システム監視部
１１ 対象システム
１２ 稼働状況監視部
１３ 現象監視部
２０ 実データ収集部
２１ 正常時稼働状況記憶部
２２ 故障時稼働状況記憶部
２３ 機器依存関係導出部
２４ 故障機器検出部
２５ 依存関係記憶部
２６ 故障データ記憶部
２７ 故障生成部
２８ 入力受付部
３０ 故障原因検出部
３１ 管理者インターフェース
３２ 故障原因特定部
３３ 原因表示部
３４ 経路表示部
３５ 出力インターフェース
４０ 学習部
４１ 学習データ前処理部
４２ モデル学習部
４３ 経路選択部
４４ モデル記憶部
１０１ データベースサーバ
１０２ アプリケーションサーバ（支払いサービス）
１０３ アプリケーションサーバ（オンラインゲーム）
１０４ ウェブサーバ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】