特開 2024-117591 サービスに影響のある事象に対する障害原因特定装置、方法、及びプログラム

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

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

(11)【公開番号】P2024117591

(43)【公開日】2024-08-29

(54)【発明の名称】サービスに影響のある事象に対する障害原因特定装置、方法、及びプログラム

(51)【国際特許分類】

   G06F 11/07 20060101AFI20240822BHJP

   G06N 20/00 20190101ALI20240822BHJP

【ＦＩ】

G06F11/07 190

G06F11/07 140R

G06F11/07 193

G06N20/00

【審査請求】未請求

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2023023767

(22)【出願日】2023-02-17

(71)【出願人】

【識別番号】000208891

【氏名又は名称】ＫＤＤＩ株式会社

(71)【出願人】

【識別番号】000003207

【氏名又は名称】トヨタ自動車株式会社

(74)【代理人】

【識別番号】100166338

【弁理士】

【氏名又は名称】関口 正夫

(72)【発明者】

【氏名】青松 祐亮

(72)【発明者】

【氏名】伊藤 雅典

(72)【発明者】

【氏名】吉田 琢也

(72)【発明者】

【氏名】大野 允裕

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

5B042

【Ｆターム（参考）】

5B042HH30

5B042KK15

5B042KK17

5B042MA08

5B042MC13

5B042MC22

(57)【要約】

【課題】サービスに影響のある事象を自動的に復旧させること。
【解決手段】ステップＳ６０１において、ＳＬＡ（サービス品質保証）違反が発生する。また、ＩＭＥＩ（国際移動体装置識別番号）などの通信機能を有する端末を特定する識別情報を含むトレース情報を取得する。ステップＳ６０２において、前記トレース情報と、前記トレース情報の期間と同じ期間のメトリック情報と、構成管理情報とに基づいて障害原因を特定する。車載機ドメイン、ネットワークドメイン、クラウドドメインの各ドメインは、各々自己修復機能を持っている。しかし、各ドメインが、メトリックス情報やログ情報を監視しているだけでは、サービスに影響を与える事象を検出できない。本発明では、サービス視点のトレース情報を使っているので、サービスに影響を与える事象を検出できる。
【選択図】図６

【特許請求の範囲】

【請求項1】

通信機能を有する端末を特定するＩＤを含むトレース情報と、前記トレース情報に対応する期間のメトリック情報と、構成管理情報とを収集する監視情報収集部と、
障害発生時に、前記監視情報収集部が収集した前記トレース情報と、前記メトリック情報と、前記構成管理情報とに基づいて、障害原因を特定する障害原因特定部と、
を備えた障害原因特定装置。

【請求項2】

前記障害原因特定部は、トレース情報と前記トレース情報に紐付いたメトリック情報を入力データとし、特定済みの障害原因をラベルデータとする訓練データを使って、教師あり機械学習により作成される学習済モデルを備える、請求項１に記載の障害原因特定装置。

【請求項3】

前記障害原因特定部は、プラットフォームの特徴に基づいて設定された重み付けにより、前記学習済モデルが出力した複数の障害原因候補に順位を付けることで障害原因を特定することを特徴とする、請求項２に記載の障害原因特定装置。

【請求項4】

コンピュータにより、
通信機能を有する端末を特定するＩＤを含むトレース情報と、前記トレース情報に対応する期間のメトリック情報と、構成管理情報とを収集する監視情報収集ステップと、
障害発生時に、前記監視情報収集ステップで収集した前記トレース情報と、前記メトリック情報と、前記構成管理情報とに基づいて、障害原因を特定する障害原因特定ステップと、
を含む障害原因特定方法。

【請求項5】

前記障害原因特定ステップは、トレース情報と前記トレース情報に紐付いたメトリック情報を入力データとし、特定済みの障害原因をラベルデータとする訓練データを使って、教師あり機械学習により作成される学習済モデルにより、障害原因候補を出力するステップを含む、請求項４に記載の障害原因特定方法。

【請求項6】

前記障害原因特定ステップは、プラットフォームの特徴に基づいて設定された重み付けにより、前記学習済モデルが出力した複数の障害原因候補に順位を付けることで障害原因を特定するステップを含むことを特徴とする、請求項５に記載の障害原因特定方法。

【請求項7】

コンピュータを、
通信機能を有する端末を特定するＩＤを含むトレース情報と、前記トレース情報に対応する期間のメトリック情報と、構成管理情報とを収集する監視情報収集部、
障害発生時に、前記監視情報収集部が収集した前記トレース情報と、前記メトリック情報と、前記構成管理情報とに基づいて、障害原因を特定する障害原因特定部、
として機能させるための障害原因特定プログラム。

【請求項8】

前記障害原因特定部は、トレース情報と前記トレース情報に紐付いたメトリック情報を入力データとし、特定済みの障害原因をラベルデータとする訓練データを使って、教師あり機械学習により作成される学習済モデルを備える、請求項７に記載の障害原因特定プログラム。

【請求項9】

前記障害原因特定部は、プラットフォームの特徴に基づいて設定された重み付けにより、前記学習済モデルが出力した複数の障害原因候補に順位を付けることで障害原因を特定することを特徴とする、請求項８に記載の障害原因特定プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、クラウドネイティブな環境でのサービスに影響のある事象に対する障害原因特定装置に関する。クラウドネイティブとは、コンテナやマイクロサービスなど、クラウドに関するさまざまな技術を活用するソフトウェア開発のアプローチのことである。

【背景技術】

【0002】

近年、スマートフォンやＩｏＴ（Internet of Things）機器など通信機能を有する端末が、ネットワークによりクラウドにあるサーバと接続されて、そのサーバからのサービスを受けるようになってきている。この通信機能を有する端末の一例として、自動車に搭載される車載機がある。
図１は、そのような車載機がネットワークに接続されている状態を示すサービス提供システム１００を示す図である。図１を参照すると、クラウドサーバ１１０が、ネットワーク１２０により自動車１３０の車載機１４０の中の通信モジュールと接続されている。車載機１４０は、例えば、カーナビゲーション・システムである。車載機１４０の中の通信モジュールの例としては、特許文献１の地図生成用データ収集装置と通信可能な通信部が挙げられる。

【0003】

図１のような接続状態は、例えば、図２のような構成になっている。ドメインの観点からは、車載機ドメイン２２０、ネットワークドメイン２３０、及びクラウドドメイン２４０に分けられる。また、ユーザに対するレイヤという観点からは、プラットフォームとサービスに分けることができる。

【0004】

車載機ドメイン２２０のプラットフォームには、ＯＳ（Operating System）２２１が存在する。オプションで、仮想化技術（例：ＶＭ（Virtual Machine）２２２やコンテナ）
が使用されることもある。車載機には、複数のＥＣＵ（Electronic Control Unit）が搭載されており、そのうち内の一部のＥＣＵは、外部インターネットと通信するＤＣＭ（Data Communication Module）である。また、車載機ドメイン２２０のプラットフォームとしての自己修復機能２２３を備えている。

【0005】

ネットワークドメイン２３０のプラットフォームには、複数のスライス（例えば、スライス１～３）が存在し、ネットワークドメイン２３０のプラットフォームとしての自己修復機能２３２を備えている。
クラウドドメイン２４０のプラットフォームには、ＯＳ２４１が存在する。また、一例として、ＶＭ２４１やコンテナ基盤２４３等によって制御されるコンテナが存在しうる。コンテナ基盤２４３は、複数のコンテナを自動的に配備するプログラムであって、kubernetes（登録商標）やopenshift（登録商標）がその一例である。コンテナアプリケーションは、コンテナ基盤２４３によって生成されたコンテナノード（図示せず）上で実行される。すなわち、コンテナノードは、コンテナアプリケーションを実行しているマシンである。コンテナノード自体は、１台の物理サーバ又は仮想マシンである。以下では、コンテナノードのことを「ノード」と略称する。また、クラウドドメイン２４０のプラットフォームとしての自己修復機能２４４を備えている。

【0006】

出願人は、２０２３年に、物理サーバの電源を落としたとしても、トランザクション需要の増加前に物理サーバを起動させるサーバ管理装置及びサーバ管理方法の出願を行っている。本願の図１のクラウドドメイン２４０のプラットフォームは、前記「サーバ管理装置及びサーバ管理方法」の物理サーバ／コンテナ基盤／コンテナノードに対応する。本願の図１のクラウドドメイン２４０のサービス（ＡＰＩ関連）は、前記「サーバ管理装置及びサーバ管理方法」のコンテナアプリに対応する。

【0007】

このように、各ドメインのプラットフォームは、自己修復機能を備えており、ＣＰＵ使用率、メモリ使用率などのメトリック情報や、イベントエラーなどのログ情報の運用情報に対して閾値を設定して、宣言型（インテント型）の自己修復を実現している。
このように構成することで、各プラッフォームでの障害の自己修復が可能となる。しかしながら、メトリック情報やログ情報を閾値と比較しているだけでは、Ｅ２Ｅ（End to End）でのサービスに対する影響の有無を認識することは困難である。

【先行技術文献】

【特許文献】

【0008】

【特許文献1】特許第７１３６１３８号公報

【発明の概要】

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

【0009】

各プラットフォームが有している自己修復機能で障害が復旧できなかった場合、ユーザが遅れを認識できる等のサービスに影響を与える事象が発生する。しかし、上述のように、メトリック情報やログ情報を閾値と比較しているだけでは、ユーザが遅れを認識できる状態等のサービスに影響を与える事象が発生しているか否かを判定できない。

【0010】

本発明は、サービスに影響のある事象を認識し、自動的に復旧する方法を確立することを目的とする。

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

【0011】

本発明の特徴は三点ある。
まず、第１点は、Ｏｐｅｎ ｔｅｌｅｍｅｔｒｙのトレース情報に、ＩＭＥＩ（International Mobile Equipment Identifier：国際移動体装置識別番号）などの通信機能を有する端末を特定する識別情報を埋め込むことである。
Ｏｐｅｎ ｔｅｌｅｍｅｔｒｙは、クラウドネイティブアプリケーションとそのインフラのパフォーマンス及び健全性を示すテレメータデータを収集するためのツールである。

【0012】

Ｏｐｅｎ ｔｅｌｅｍｅｔｒｙのテレメータデータには、トレース情報が含まれており、場合によってはメトリック情報及びログも含まれている。Ｏｐｅｎ ｔｅｌｅｍｅｔｒｙのテレメータデータにメトリック情報及びログが含まれていない場合は、従来と同じように、アプリケーションが、メトリック情報及びログを取得するように構成すればよい。トレース情報とは、分散システムにおけるリクエストの処理経路をＥ２Ｅで表すデータである。トレース情報は、例えばあるリクエストに対するスパンのまとまりを示すデータであり、スパン毎の処理時間を例えば時系列で親子関係を持たせてトレースというひとまとまりの情報として保存することができる。
リクエストが実行されるときには、さまざまな操作が実行されるが、その操作は「スパン（Span）」と呼ばれる。スパンは、例えばリクエスト内の各処理の状況である処理名、実行時間、ステータスコード等を含む。リクエスト全体の処理は、個々のコンポーネントが連携して行われるため、スパンで個々のコンポーネントの処理を前記のように時系列により記録することで、エラーが発生した場合のエラー発生個所を特定しやすくすることができる。
メトリック情報は、一定の期間にわたって測定された、システムの状態を表す数値である。

【0013】

トレース情報にＩＭＥＩなどの通信機能を有する端末を特定する識別情報を埋め込むことにより、５ＧスライスのＣａｌｌ Ｔｒａｃｅ Ｌｏｇ情報によって、ネットワークドメインにおいて、トランザクションを特定することが可能となる。したがって、トレース情報によって、リアルタイムで効率的なＥ２Ｅトランザクションを監視することができる。

【0014】

第２点は、自動的に障害原因を特定できなかった場合に、人間が手動にて障害原因を特定し、その障害原因を特定するためのメトリック情報を新しく設けることである。メトリック情報とは、例えばＰｏｄ単位に予め定義した指標の情報であって、例えばＣＰＵ利用率、メモリ使用率、通信セッション滞留数等を含むようにしてもよい。なお、Ｐｏｄは、kubernetesにおいて１つ以上のコンテナを管理する単位である。

【0015】

第３点は、トレース情報と、そのトレース情報の期間と同じ期間のメトリック情報とを紐付けることである。これにより、同じ障害原因の場合、次回からは自動で障害原因を特定できるようになる。

【0016】

本発明者らは、通信機能を有する端末を特定するＩＤを含むトレース情報によって、サービスに影響を与える事象の発生を検出し、トレース情報、そのトレース情報に紐付いたメトリック情報、及び構成管理情報に基づいて障害原因を特定することを見出し、本発明を完成するに至った。ここで構成管理情報は、どのＡＰＩがどのノード又はどのＰｏｄで動作しているかに関する情報を含む。

【0017】

（１）通信機能を有する端末を特定するＩＤを含むトレース情報と、前記トレース情報に対応する期間のメトリック情報と、構成管理情報とを収集する監視情報収集部と、
障害発生時に、前記監視情報収集部が収集した前記トレース情報と、前記メトリック情報と、前記構成管理情報とに基づいて、障害原因を特定する障害原因特定部と、
を備えた障害原因特定装置。

【0018】

（２）前記障害原因特定部は、トレース情報と前記トレース情報に紐付いたメトリック情報を入力データとし、特定済みの障害原因をラベルデータとする訓練データを使って、教師あり機械学習により作成される学習済モデルを備える、上記（１）の障害原因特定装置。特に、トレース情報としてリクエスト毎の処理時間の時系列情報を、またメトリック情報として予め定義した指標の統計値の時系列情報を入力データとしてもよい。

【0019】

（３）前記障害原因特定部は、プラットフォームの特徴に基づいて設定された重み付けにより、前記学習済モデルが出力した複数の障害原因候補に順位を付けることで障害原因を特定することを特徴とする、上記（２）の障害原因特定装置。

【0020】

（４）コンピュータにより、通信機能を有する端末を特定するＩＤを含むトレース情報と、前記トレース情報に対応する期間のメトリック情報と、構成管理情報とを収集する監視情報収集ステップと、
障害発生時に、前記監視情報収集ステップで収集した前記トレース情報と、前記メトリック情報と、前記構成管理情報とに基づいて、障害原因を特定する障害原因特定ステップと、
を含む障害原因特定方法。

【0021】

（５）前記障害原因特定ステップは、トレース情報と前記トレース情報に紐付いたメトリック情報を入力データとし、特定済みの障害原因をラベルデータとする訓練データを使って、教師あり機械学習により作成される学習済モデルにより、障害原因候補を出力するステップを含む、上記（４）の障害原因特定方法。

【0022】

（６）前記障害原因特定ステップは、プラットフォームの特徴に基づいて設定された重み付けにより、前記学習済モデルが出力した複数の障害原因候補に順位を付けることで障害原因を特定するステップを含むことを特徴とする、上記（５）の障害原因特定方法。

【0023】

（７）コンピュータを、
通信機能を有する端末を特定するＩＤを含むトレース情報と、前記トレース情報に対応する期間のメトリック情報と、構成管理情報とを収集する監視情報収集部、
障害発生時に、前記監視情報収集部が収集した前記トレース情報と、前記メトリック情報と、前記構成管理情報とに基づいて、障害原因を特定する障害原因特定部、
として機能させるための障害原因特定プログラム。

【0024】

（８）前記障害原因特定部は、トレース情報と前記トレース情報に紐付いたメトリック情報を入力データとし、特定済みの障害原因をラベルデータとする訓練データを使って、教師あり機械学習により作成される学習済モデルを備える、上記（７）の障害原因特定プログラム。

【0025】

（９）前記障害原因特定部は、プラットフォームの特徴に基づいて設定された重み付けにより、前記学習済モデルが出力した複数の障害原因候補に順位を付けることで障害原因を特定することを特徴とする、上記（８）の障害原因特定プログラム。

【発明の効果】

【0026】

本発明によれば、Ｅ２Ｅトランザクションをリアルタイムで監視し、Ｅ２Ｅトランザクション監視情報から、障害の原因を正しく特定でき、また障害の原因を特定するのに要する時間を短縮できる。

【図面の簡単な説明】

【0027】

【図1】本発明の実施形態のシステム全体を示す図である。

【図2】本発明の実施形態のサービスとプラットフォームの構成を示す図である。

【図3】本発明の実施形態の障害原因特定装置の機能を示す機能ブロック図である。

【図4】本発明の実施形態の概念図である。

【図5】本発明の実施形態の初めての障害原因の場合の処理の流れを示す図である。

【図6】本発明の実施形態の２回目以降の障害原因の場合の処理の流れを示す図である。

【図7】本発明の実施形態の障害原因特定部の動作を示す図である。

【発明を実施するための形態】

【0028】

以下、図面を用いて、本発明の実施形態について説明する。
図１は、本発明の実施形態のサービス提供システム全体を示す図である。図１に示すように、サービス提供システム１００は、クラウドサーバ１１０とネットワーク１２０と、自動車１３０と、を備える。ここで、自動車１３０は、例えばコネクテッドカーである。

【0029】

図２は、本発明の実施形態のサービスとプラットフォームの構成を示す図である。前述したように、提供されるサービスは、車載機ドメイン２２０、ネットワークドメイン２３０、及びクラウドドメイン２４０から構成されるプラットフォーム上で実行される。

【0030】

図３は、本発明の実施形態の障害原因特定装置３００の機能ブロックを示す図である。図３に示すように、障害原因特定装置３００は、監視情報収集部３２０と障害原因特定部３３０とを備える。

【0031】

監視情報収集部３２０は、例えば、Ｏｐｅｎ ｔｅｌｅｍｅｔｒｙからテレメトリデータとして、通信機能を有する端末を特定するＩＤを含むトレース情報と、前記トレース情報の期間と同じ期間のメトリック情報と、構成管理情報とを収集する。通信機能を有する端末を特定するＩＤは、例えば、ＩＭＥＩである。トレース情報は、例えば、リクエスト毎の処理時間の時系列情報等である。メトリック情報は、例えば、予め定義した指標の統計値の時系列情報等である。構成管理情報は、例えば、どのＡＰＩがどのノード又はどのＰｏｄで動作しているかに関する情報等である。

【0032】

障害原因特定部３３０は、障害発生時に、監視情報収集部３２０が収集したトレース情報３１１と、メトリック情報３１２と、構成管理情報３１３とに基づいて、障害原因を特定し、特定した障害原因３１４を出力する。
障害原因特定部３３０は、例えば、トレース情報と、当該トレース情報の期間と同じ期間のメトリック情報を入力データとし、特定済みの障害原因をラベルデータとする訓練データにより機械学習させた学習済モデルを備えていてよい。障害が発生した期間のトレース情報とメトリック情報を学習済モデルに入力させることにより、学習済モデルから一つ又は複数の障害原因候補が得られる。

【0033】

障害原因特定部３３０は、メトリック情報の一種であるＰｏｄ単位の予め定義した指標の情報と構成管理情報とに基づいて、複数の障害原因候補から一つの障害原因を特定してもよい。障害原因特定部３３０の詳細については、図７を用いて後述する。

【0034】

図４は、本発明の実施形態の概念図である。
図４のトレース情報４１１、メトリック情報４１２、及び構成管理情報４１３は、それぞれ、図３のトレース情報３１１、メトリック情報３１２、及び構成管理情報３１３に対応する。また、図４の障害原因特定４２０は、図３の障害原因特定部３３０に対応する。また、図４の障害原因特定４２０から障害復旧対応４３０への矢印は、図３の特定した障害原因３１４に対応する。

【0035】

図４に示すように、予め教師あり機械学習により生成された学習済モデル（図示せず）にトレース情報４１１（例えばリクエスト毎の処理時間の時系列情報等）、メトリック情報４１２（例えば予め定義した指標の統計値の時系列情報等）を入力することで、障害原因候補を出力し、出力された障害原因候補から例えば動的な構成管理情報４１３（例えばどのＡＰＩがどのノード又はどのＰｏｄで動作しているかに関する情報等）に基づいて、ブロック４２０で、自動的に障害原因を特定する。
そして、特定された障害原因に基づいて、ブロック４３０で自動的に障害を復旧させるための対応の措置をとる。次に、更新されたトレース情報４４１、更新されたメトリック情報４４２、更新された動的な構成管理情報４４３に基づいて、ブロック４５０において、サービスが復旧したことを自動的に確認する。

【0036】

図４は、学習済モデル（図示せず）にトレース情報４１１（例えばリクエスト毎の処理時間の時系列情報等）、メトリック情報４１２（例えば予め定義した指標の統計値の時系列情報等）を入力することで障害原因候補を出力し、出力された障害原因候補から例えば動的な構成管理情報４１３（例えばどのＡＰＩがどのノード又はどのＰｏｄで動作しているかに関する情報等）に基づいて、自動的に障害原因が特定され、自動的に復旧するという流れを示しているが、常に自動的に障害原因が特定できるわけではない。自動的に障害原因を特定できない場合には、自動的に障害が復旧せず、単にサービスに影響を与え、障害が起きていることをユーザが認識できる状態になる。自動的に障害原因を特定できない場合には、人間が介入することが必要である。

【0037】

図５は、自動的に障害原因が特定できず、人間が介入する場合の処理フローである。
図５に示すように、ステップＳ５０１において、ＳＬＡ（Service Level Agreement：サービス品質保証）に違反する状態が発生したことを検出して、トレース情報を取得する。この処理は、自動又は手動で行われる。なお、ステップＳ５０１において検出する状態は、ＳＬＡに違反する状態に加えて、ＳＬＯ（Service Level Objective：サービレベル目標）違反やＫＰＩ（Key Performance Indicator：重要業績評価指標）違反、及びメトリック情報が閾値を越えた状態などを含めてもよい。
ステップＳ５０３において、ログと構成管理情報に基づいて、人間が障害原因を特定する。

【0038】

ステップＳ５０５において、人間が障害を復旧させる。
ステップＳ５０７において、人間が障害チケット情報を更新する。この障害チケットは、障害が発生する毎に作成される障害処理票であり、障害が発生した時刻、障害の内容、障害を復旧させた時刻、障害の復旧を確認した時刻などを記録するものである。

【0039】

ステップＳ５０９において、障害原因を特定することが可能なメトリック情報を新しく設ける。新しく設けるメトリック情報としては、例えば、ＡＰＩ（Application Programming Interface）内部の処理滞留数である。

【0040】

このように、自動的に障害原因を特定できない場合（例えば、当該障害が初めてのケースである場合）は人間が介入することが必要であるが、ステップＳ５０９において、障害原因を特定することが可能なメトリック情報を新しく設け、さらに特定されたトレース情報４１１、メトリック情報４１２を入力データとし、障害原因をラベルデータとする訓練データにより機械学習することで得られる更新された学習済モデル（図示せず）を用いることで、次回に同じ障害が発生した場合、自動的に障害原因を特定し、自動的に障害を復旧させることができるようになる。

【0041】

図６は、図５のステップＳ５０９において、障害原因を特定することが可能なメトリック情報を新しく設けた後に、図５と同じ障害原因により障害が発生した場合の処理の流れである。
図６に示すようにステップＳ６０１において、ＳＬＡに違反する状態が発生したことを検出して、トレース情報を取得する。この処理は、自動で行われる。なお、ステップＳ５０１と同様に、ステップＳ６０１において検出する状態は、ＳＬＡに違反する状態に加えて、ＳＬＯ（Service Level Objective：サービレベル目標）違反やＫＰＩ（Key Performance Indicator：重要業績評価指標）違反、及びメトリック情報が閾値を越えた状態などを含めてもよい。

【0042】

ステップＳ６０３において、トレース情報とメトリック情報と構成管理情報とに基づいて、自動的に障害原因を特定する。この障害原因の特定には、具体的には、トレース情報とメトリック情報から作成された学習済モデルを使用するが、その詳細については後述する。
ステップＳ６０５において、特定された障害原因に基づいて、障害を自動的に復旧させる。

【0043】

ステップＳ６０７において、障害チケット情報を自動的に更新する。
ステップＳ６０９において、更新されたトレース情報に基づいて、障害が復旧していることを自動的に確認する。

【0044】

障害が復旧していることを確認したら、ステップＳ６１１において、チケット管理システムが自動的にチケット情報を更新する。
図６のステップＳ６０３においては、トレース情報とメトリック情報と構成管理情報とに基づいて、自動的に障害原因を特定している。

【0045】

図７は、ステップＳ６０３の処理を行う障害原因特定部３３０の詳細を説明する図である。
まず、リクエスト毎の処理時間の時系列情報であるトレース情報７１１と、予め定義した指標の統計値の時系列情報であるメトリック情報（１）７１２を入力データとし、特定済みの障害原因をラベルデータとする訓練データを使って、教師あり機械学習により学習済モデル７２０を作成しておく。

【0046】

この学習済モデル７２０が作成済みであるので、新規に入力されたトレース情報７１１と新規に入力されたメトリック情報（１）７１２に対して、学習済モデル７２０は複数の障害原因候補７３０を出力する。

【0047】

ステップＳ７０１では、トレース情報７１１のＡＰＩ毎の処理時間の時系列情報に基づいて、異常ＡＰＩを特定する。例えば、処理時間の長いＡＰＩを抽出して、異常ＡＰＩとして特定する。

【0048】

ステップＳ７０２では、どのＡＰＩがどのノード、どのＰｏｄで動作しているのかに関する情報である構成管理情報を使って、異常ＡＰＩが動作しているＰｏｄを特定する。

【0049】

ステップＳ７０２における処理が終わった時点で、次の情報が明確になっていると想定される。
（１）どのＡＰＩでＫＰＩ（Key Performance Indicator：重要業績評価指標）違反が生じたか。
（２）どのノード（クラスタ情報を含む。）、どのＰｏｄで異常ＡＰＩが動作しているか。
（３）どの時間帯でＫＰＩ違反が生じたか。
（４）ＫＰＩ違反が生じた時間帯のメトリック情報の時系列変化パターンから、学習済モデル７２０により、いくつかの障害原因候補が挙がっている。

【0050】

異常ＡＰＩが動作するＰｏｄは、ＳＬＯ（Service Level Objective：サービレベル目標）により動作するクラスタが決まっている。したがって、複数の障害原因候補の中でも、障害原因である可能性の重みが異なると考えられる。その重みにより複数の障害原因候補に順位を付ける。

【0051】

ステップＳ７０３では、Ｐｏｄ単位の予め定義した指標の情報であるメトリック情報（２）７１４に基づいて、複数の障害原因候補７３０の中から障害原因を特定する。

【0052】

このステップＳ７０３における障害原因の選択については、例えば、次のように構成する。ＡＰＩが動作するＰｏｄは、ＳＬＯにより、動作するプラットフォームが決まっている。低速大容量のプラットフォームと、高速小容量のプラットフォームとでは、どのような障害原因が起き易いかは異なると考えられる。したがって、プラットフォームの特徴に基づいて、人間が障害原因候補に重みを付けておき、その重みにより自動的に障害原因を特定する。

【0053】

以上のように、本実施形態では、Ｅ２Ｅにおいて、Ｏｐｅｎ ｔｅｌｅｍｅｔｒｙのトレース情報のＩＭＥＩ、トレースＩＤ（Trace-ID）、及びスパンＩＤ（Span-ID）のみを常時収集可能であるので、ＩｏＴサービスにおいて常時監視が可能となる。

【0054】

また、本実施形態では、トレース情報は、ＡＰＩそのものから直接収集できるので、ログのフォーマットの不備に引きずられることがなくなり、ＡＰＩ開発を標準化することで、「Ｏｐｅｒａｔｉｏｎ Ａｓ ａ Ｓｅｒｖｉｃｅ」を実現できる。

【0055】

また、本実施形態では、［サービス視点のトレース情報］＋［プラットフォーム視点のメトリック情報］＋［構成管理情報］により、サービスに影響のある事象のサービス復旧自動化を実現できる。

【0056】

また、上述した実施形態の機能的構成を変形するようにしてもよい。すなわち、図３の機能的構成は例示に過ぎず、本実施形態の機能的構成を限定するものではない。すなわち、本発明の障害原因特定装置３００の機能に関する一連の処理を全体として実行できる機能が備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは特に図３の例に限定されない。
また、障害原因特定装置３００の備えるそれぞれの各機能は、適宜複数のサーバ装置に分散する、分散処理システムとしてもよい。また、クラウド上で仮想サーバ機能等を利用して、障害原因特定装置３００の各機能を実現するようにしてもよい。

【0057】

障害原因特定装置３００に係る機能は、ソフトウェアにより実現される。ソフトウェアによって実現される場合には、このソフトウェアを構成するプログラムが、情報処理装置（コンピュータ）にインストールされる。また、これらのプログラムは、ＣＤ－ＲＯＭのようなリムーバブルメディアに記録されてユーザに配布されてもよいし、ネットワークを介してユーザのコンピュータにダウンロードされることにより配布されてもよい。さらに、これらのプログラムは、ダウンロードされることなくネットワークを介したＷｅｂサービスとしてユーザのコンピュータに提供されてもよい。

【0058】

本発明により、情報通信技術というインフラの整備が行われるので、国連が主導する持続可能な開発目標（ＳＤＧｓ）の目標９「レジリエントな（resilient：柔軟な）インフラを整備し、持続可能な産業化を推進するとともに、イノベーションの拡大を図る。」に貢献することが可能となる。

【符号の説明】

【0059】

１００ サービス提供システム
１１０ クラウドサーバ
１２０ ネットワーク
１３０ 自動車
１４０ 車載機
３００ 障害原因特定装置
３２０ 監視情報収集部
３３０ 障害原因特定部
６１１ トレース情報
６１２ メトリック情報（１）
６１３ 構成管理情報
６１４ メトリック情報（２）

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】