JP2018060332A - インシデント分析プログラム、インシデント分析方法、情報処理装置、サービス特定プログラム、サービス特定方法及びサービス特定装置 - Google Patents

インシデント分析プログラム、インシデント分析方法、情報処理装置、サービス特定プログラム、サービス特定方法及びサービス特定装置 Download PDF

Info

Publication number
JP2018060332A
JP2018060332A JP2016196731A JP2016196731A JP2018060332A JP 2018060332 A JP2018060332 A JP 2018060332A JP 2016196731 A JP2016196731 A JP 2016196731A JP 2016196731 A JP2016196731 A JP 2016196731A JP 2018060332 A JP2018060332 A JP 2018060332A
Authority
JP
Japan
Prior art keywords
request
incident
service
response time
service system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
JP2016196731A
Other languages
English (en)
Inventor
和典 神谷
Kazunori Kamiya
和典 神谷
清志 ▲高▼下
清志 ▲高▼下
Kiyoshi Takashita
洋 伊與部
Hiroshi Iyobe
洋 伊與部
孝昭 中澤
Takaaki Nakazawa
孝昭 中澤
俊一 大日方
Shunichi Obinata
俊一 大日方
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2016196731A priority Critical patent/JP2018060332A/ja
Priority to US15/700,812 priority patent/US20180095819A1/en
Publication of JP2018060332A publication Critical patent/JP2018060332A/ja
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0787—Storage of error reports, e.g. persistent data storage, storage using memory protection
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0727—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a storage system, e.g. in a DASD or network based storage system

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Debugging And Monitoring (AREA)

Abstract

【課題】異なるクラウドベンダのサーバセンタ内に構築されたサービスシステムを有するサービスシステムに発生したインシデントの原因サービスシステムを推定する。
【解決手段】サービスシステムのユーザ端末装置３４、または第１のクラウドサービスの運用者端末装置３０から新規インシデントについての報告または分析依頼があると、インシデント分析装置１３は、そのインシデントに関連するリクエストを抽出して新規インシデント関連リクエストデータベースを生成し、過去のインシデント関連リクエストデータベースを参照して、新規インシデントの原因と推定される原因サービスシステムを特定する。
【選択図】図２

Description

本発明は，インシデント分析プログラム、インシデント分析方法、情報処理装置、サービス特定プログラム、サービス特定方法及びサービス特定装置に関する。
サービスシステムは、サーバ（または物理マシン）、ストレージ、オペレーティングシステム（OS：Operating System）、アプリケーションの組み合わせで構築される。従来のサービスシステムは、自社内のハードウエア資源を使用して構築されるので、サービスシステムにインシデントが発生した場合、サービスシステム内に発生した全てのメッセージ、エラー内容を解析し、インシデントの発生原因を特定する。
以下の特許文献は、インシデントの検出について開示する。
国際公開第２０１４／０３３８９４号 国際公開第２０１４／０２０９０８号
クラウドコンピューティングサービス（以下クラウドサービスと称する）の普及に伴い、サービスシステムがクラウドサービスを提供するクラウドサービスベンダ（以下クラウドベンダと称する）のサーバセンタのハードウエア、OS、ミドルウエア等により構築されようになった。特に、サービスシステムが、複数のクラウドベンダのサーバセンタ内に構築した複数のサービスシステムをネットワークで接続して構築されると、発生したインシデントの原因を解析することが困難になる。
例えば、第１のクラウドベンダの第１のサーバセンタ内のサービスシステムでインシデントが発生した場合、第１のクラウドベンダの運用者は、第１のサーバセンタ内のエラー内容を把握できるが、第１のクラウドベンダとは異なる第２のクラウドベンダの第２のサーバセンタ内のエラー内容を把握することは困難である。そのため、インシデントの原因が第２のサーバセンタ内のどのサービスシステムにあるのかを判定することができない。
そこで、一つの側面では、本発明は、異なるクラウドベンダのサーバセンタ内に構築されたサービスシステムを有するサービスシステムに発生したインシデントの原因サービスシステムを推定するインシデント分析プログラム、その方法、およびそれを実行する情報処理装置を提供することを目的とする。
１つの態様では、第１のクラウドサービスベンダのサーバセンタ内に構築された複数の第１のサービスシステムを発行元とし、前記第１のクラウドサービスベンダと異なる第２のクラウドサービスベンダのサーバセンタ内に構築された複数の第２のサービスシステムを発行先とするリクエストと、前記リクエストのレスポンス時間と、前記リクエストの時刻とを関連付けたリクエストデータを有するリクエスト管理データベースから、前記複数の第１のサービスシステムのいずれかで発生した新規インシデントの発生元の第１のサービスシステムに関連する発行元第１のサービスシステムから発行先第２のサービスシステムに発行したリクエストデータであり、さらに前記新規インシデントが発生した時のリクエストデータを、抽出して、新規インシデント関連リクエストデータベースを生成する処理と、
過去に発生した複数のインシデントそれぞれに対して生成された複数の過去のインシデント関連リクエストデータベースから、前記新規インシデント関連リクエストデータベースに含まれる発行元と発行先が同じリクエストデータのレスポンス時間の推移傾向と、所定の相関性を有するレスポンス時間の推移傾向を有する過去のインシデント関連リクエストデータベースを抽出する処理と、
前記抽出された過去のインシデント関連リクエストデータベースの過去のインシデントの原因と推定された第２のサービスシステムの情報を特定し、出力する処理と、をコンピュータに実行させるインシデント分析プログラムである。
上記の１つの側面によれば、異なるクラウドベンダのサーバセンタ内に構築されたサービスシステムを有するサービスシステムに発生したインシデントの原因サービスシステムを推定することができる。
異なるクラウドサービスベンダのサーバセンタ内に構築されたサービスシステムの構成例を示す図である。 第１の実施の形態におけるサービスシステムの構成例を示す図である。 管理サーバ１０の構成例を示す図である。 インシデント分析プログラムと各データベースの関係を示す図である。 本実施の形態におけるインシデント分析プログラムの概略処理を示すフローチャート図である。 リクエスト発行プログラム２２１によるダミーリクエストについて説明する図である。 インシデント原因推定プログラムにおける上記の工程S4, S5, S8の詳細なフローチャートを示す図である。 工程S9の詳細フローチャートを示す図である。 工程S10の詳細フローチャートを示す図である。 工程S11,S12の詳細フローチャートを示す図である。 リクエスト管理データベース２４の例を示す図である。 インシデントデータベース２６の一例を示す図である。 新規インシデント関連リクエストデータベースの例を示す図である。 過去のインシデント関連リクエストデータベース２５の一例を示す図である。 レスポンス時間の変化率の２つの波形間の相関性を説明する図である。 第２の実施の形態におけるインシデント分析プログラムのフローチャート図である。 第２の実施の形態における新規インシデント関連リクエストデータベース２５の一例を示す図である。
図１は、異なるクラウドサービスベンダのサーバセンタ内に構築されたサービスシステムの構成例を示す図である。図１には、第1のクラウドサービスベンダのクラウドサービスCS_1のセンタ（サーバセンタ）と、第1のクラウドサービスベンダとは異なる第２のクラウドサービスベンダのクラウドサービスCS_2のセンタ（サーバセンタ）とが示されている。また、図１において、クラウドサービスを利用するクラウドユーザが、クラウドサービスCS_1のサーバセンタ内の物理マシン（物理コンピュータ）PM_0−PM_2に生成した仮想マシンVM0-VM5により構築した３つの第１のサービスシステムS_A,S_B,S_Cと、クラウドサービスCS_2のサーバセンタ内に構築した３つの第２のサービスシステムS_1,S_2,S_3とを、ネットワークNWを介して通信可能に接続してサービスシステムを構築している。また、クラウドサービスCS_1のサーバセンタには、物理マシンや仮想マシンを管理する管理サーバ１０が設けられ、管理サーバ１０は、クラウドサービス管理装置１１やクラウドポータルサイト１２などを提供する。
一例として、クラウドサービスCS_1のサーバセンタ側のサービスシステムS_Aが電子商取引サイトのウエブサービスを提供し、サービスシステムS_Bが電子商取引サイトの顧客管理サイトのウエブサービスを提供し、サービスシステムS_Cが電子商取引サイトの繁忙度管理サイトのウエブサービスを提供する。一方、クラウドサービスCS_2のサーバセンタ側のサービスシステムS_1が電子商取引サイトのためのデータベースサービスを提供し、サービスシステムS_2がロードバランサのサービスを提供し、サービスシステムS_3がサービスシステムS_B,S_Cの監視サービスを提供する。
このようなサービスシステムにおいて、サービスシステムのユーザ端末装置３４は、ネットワークNWを介して、第１のサービスシステムS_A,S_B,S_Cにそれぞれアクセスし、それぞれのサービスを利用する。サービスシステムのユーザ端末装置３４からのアクセスに応答して、各第１のサービスシステムS_A,S_B,S_Cは、第２のサービスシステムであるデータベースシステムS_1、ロードバランサS_2、繁忙度管理サービスS_3などに適宜リクエストを発行し、リクエストの応答に基づいてそれぞれのサービスに必要な処理を実行する。したがって、各第１のサービスシステムS_A,S_B,S_Cが発行するリクエストのレスポンスが遅くなると、各第１のサービスシステムS_A,S_B,S_Cによるサービスシステムのユーザ端末装置３４に対するレスポンスも遅くなる場合がある。
一方、第１のクラウドサービスのユーザ端末３２は、ネットワークNWを介して、クラウドポータルサイト１２にアクセスし、仮想マシンVM0-VM5の生成と起動をクラウドサービス管理装置１１に依頼して、第１のサービスシステムS_A,S_B,S_Cの構築と起動を行う。さらに、第１のクラウドサービスCS_1の運用者端末３０は、ネットワークNWを介してクラウドサービス管理装置１１にアクセスし、第１のサービスシステムS_A,S_B,S_Cの運用管理を行う。運用管理には、サービスシステムS_A,S_B,S_Cで発生したインシデントを分析することなどが含まれる。
一般に、異なるベンダによる２つのクラウドサービスのセンタ間では、互いのクラウドサービスのセンタで生じたエラー情報は互いに公開されず秘密に保たれる。そのため、第１のクラウドサービスCS_1の運用者が、第１のサービスシステムS_A,S_B,S_Cで発生したインシデントを分析する場合、第１のクラウドサービスCS_1のサーバセンタ内の第１のサービスシステムS_A,S_B,S_Cで発生したエラー情報については全て把握することはできるが、第２のクラウドサービスCS_2のサーバセンタ内の第２のサービスシステムS_1,S_2,S_3で発生したエラー情報については把握することはできない。その結果、インシデントの原因となっているサービスシステムを特定することは工数を要するか、または困難もしくは不可能である。
［第１の実施の形態］
図２は、第１の実施の形態におけるサービスシステムの構成例を示す図である。図２の構成例において、図１と異なる構成は、管理サーバ１０がインシデント分析装置１３を有することである。サービスシステムのユーザ端末装置３４から第１のサービスシステムS_A,S_B,S_Cに発生したインシデントについての報告があると、インシデント分析装置１３は、そのインシデントの原因と推定される原因サービスシステムを特定する。第１のクラウドサービスの運用者端末装置３０は、インシデントの報告があると、インシデント分析装置１３にアクセスし、インシデントの分析を依頼する。この分析依頼に応じて、インシデント分析装置１３は、インシデントの原因と推定される原因サービスシステムを特定し、運用者端末装置３０に原因サービスシステムを返信する。
図３は、管理サーバ１０の構成例を示す図である。管理サーバ１０は、プロセッサであるCPU１４と、メインメモリであるRAM１５と、ネットワークNWとのインターフェースデバイス１６と、大容量の補助記憶装置群２０−２６とを有し、それらはバス２８を介して接続される。
補助記憶装置群には、クラウドサービス管理プログラム２０と、インシデント分析プログラム２２と、リクエスト管理データベース２４と、インシデント関連リクエストデータベース２５と、インシデントデータベース２６とを記憶する。クラウドサービス管理プログラム２０と、インシデント分析プログラム２２は、メインメモリ１５に展開されプロセッサ１４により実行される。プロセッサ１４がクラウドサービス管理プログラム２０を実行することで、図２のクラウドサービス管理装置１１が構築される。また、プロセッサがインシデント分析プログラム２２を実行することで、図２のインシデント分析装置１３が構築される。
プロセッサ１４はクラウドサービス管理プログラム２０を実行し、例えば、クラウドサービスのユーザ端末装置３２からの第１のサービスシステムSC_A-SC_Cの起動依頼に応答して、物理マシンPM_0-PM_2のハイパバイザHV_1-HV_2に各サービスシステムを構成する仮想マシンVM0-VM5の起動を実行させる。また、クラウドサービスの運用者端末装置３０からの第１のサービスシステムSC_A-SC_Cの監視依頼に応答して、端末装置３０による各サービスシステムのエラーメッセージの監視を可能にする。
プロセッサ１４はインシデント分析プログラム２２を実行し、例えば、サービスシステムのユーザ端末装置３４からのインシデント報告に応答して、インシデントデータベース２６に新たに発生したインシデントのデータを追加する。また、所定の時間間隔で第１のサービスシステムを発行元とし第２のサービスシステムを発行先とする複数種類のダミーのリクエストを発行し、そのダミーのリクエストに対するレスポンス時間や応答メッセージなどを有するリクエストデータを、リクエスト管理データベース２４に追加する。さらに、クラウドサービスの運用者端末装置３０からのインシデントの原因分析依頼に応答して、インシデント関連リクエストデータベース２５を生成し、新規のインシデントに関連するリクエストの振る舞い（レスポンス時間やメッセージ）に基づいて、原因と推定される第２のサービスシステムを特定する。
図４は、インシデント分析プログラムと各データベースの関係を示す図である。インシデント分析プログラム２２は、クラウドサービスの運用者端末装置３０に対するインシデント管理サイトのインターフェースを提供するインシデント管理インターフェース２２０を有する。このインターフェース２２０は、運用者端末装置３０からのインシデント管理サイトへのアクセスに応答して、インシデント管理画面を提供する。運用者端末装置３０は、このインシデント管理画面において、サービスシステムのユーザ端末装置３４から報告された新規インシデントについての詳細情報を表示する。また、インターフェース２２０は、運用者端末装置３０からの新規インシデント分析依頼に応答して、インシデント原因推定プログラム２２３を呼び出す。
インシデント分析プログラム２２は、リクエスト発行プログラム２２１を有する。プロセッサはリクエスト発行プログラム２２１を実行して、第１のサービスシステムS_A-S_Cを発行元とし第２のサービスシステムS_1-S_3を発行先とするダミーのリクエストを所定時間毎に順次発行する。リクエスト発行プログラム２２１は、順次発行したダミーのリクエストのレスポンス時間を計測し、応答メッセージを取得する。
インシデント分析プログラム２２は、リクエストデータ収集プログラム２２２を有する。プロセッサはリクエストデータ収集プログラム２２２を実行して、ダミーのリクエストを、リクエストの発行元サービスシステム（S_S）と発行先サービスシステム（D_S）と、リクエスト発行時刻(time)と、レスポンス時間（RT)とを関連付けたリクエストデータを収集し、リクエスト管理データベース２４に加える。リクエストデータにはリクエストに対する応答メッセージ（MES）が含まれても良い。
プロセッサはインシデント原因推定プログラム２２３を実行して、リクエスト管理データベース２４から、新規インシデント発生時のリクエストデータを抽出してインシデント関連リクエストデータベース２５を生成する。抽出するリクエストデータは、新規インシデントの発生元サービスシステムの動作に影響を与える可能性のあるものである。動作に影響を与える可能性のあるリクエストデータについては後述する。したがって、インシデント関連リクエストデータベース２５は、新規インシデント発生時のインシデント関連リクエスト群と、過去のインシデント発生時のインシデント関連リクエスト群とを有する。
また、プロセッサはインシデント原因推定プログラムを実行して、新規インシデントが発生すると、そのインシデントの発生時刻(time)と、インシデントの発生元第１サービスシステム（S_S）と、インシデントの現象（PH）とを関連付けたインシデントデータを、インシデントデータベース２６に追加する。このインシデントデータベース２６の各インシデントには、インシデント関連リクエストデータベース２５が対応付けられる。また、インシデントデータベース２６には、過去のインシデントについてはインシデントの原因と推定された原因サービスシステム（CoI）の情報が含まれ、新規のインシデントについては、インシデント原因推定プログラムにより推定された原因サービスシステムの情報が追加される。
図５は、本実施の形態におけるインシデント分析プログラムの概略処理を示すフローチャート図である。図５には、インシデント分析プログラム２２に加えて、サービスシステムのユーザ端末装置３４、クラウド運用者端末装置３０における処理も示されている。
［リクエストデータの収集］
まず、管理サーバ１０のプロセッサは、リクエスト発行プログラム２２１とリクエストデータ収集プログラム２２２を常時実行し、一定時間間隔でダミーのリクエストを発行し（S1）、ダミーリクエストのレスポンス時間と応答メッセージを有するログを出力する（S2）。そして、ダミーリクエストと、その発行元第１のサービスシステムと発行先第２のサービスシステムと、発行時刻と、そのレスポンス時間と、応答メッセージとを関連付けたリクエストデータを収集し、リクエスト管理データベース２４に追加する（S3）。
図６は、リクエスト発行プログラム２２１によるダミーリクエストについて説明する図である。図６においても、図２と同様に第1のクラウドサービスCS_1のサーバセンタには３つの第1のサービスシステムS_A,S_B,S_Cが生成され、第２のクラウドサービスCS_2のサーバセンタには３つの第２のサービスシステムS_1,S_2,S_3が生成され、第１のサービスシステムと第２のサービスシステム間で通信接続される。
また、図６の例では、第１のクラウドサービスCS_1は例えばPaaS（Platform as a Service）であり、第２のクラウドサービスCS_2は例えばIaaS(Infrastructure as a Service)である。但し、第１のクラウドサービスのベンダーと第２のクラウドサービスのベンダーとが異なる場合に、第１のクラウドサービスのベンダーが、第１のサービスシステムで発生したインシデントの原因が、第２のサービスシステムのいずれであるかの推定を行うことが目的であるので、第１、第２のクラウドサービスがPaaSまたはIaaSのいずれでもよい。但し、異なるクラウドサービスベンダが提供するサービスである。
図６の例では、第１のクラウドサービスCS_1で構築された第１のサービスシステムS_Aが、第２のクラウドサービスCS_2で構築された２つの第２のサービスシステムS_1,S_2にリクエストR_A1, R_A2を発行している。また、第１のサービスシステムS_Bが、３つの第２のサービスシステムS_1, S_2, S_3にリクエストR_B1, R_B2, R_B3を発行し、第１のサービスシステムS_Cが１つの第２のサービスシステムS_3にリクエストR_C3を発行している場合を想定する。この場合、３つの第１のサービスシステムが第２のサービスシステムのいずれかに発行しているリクエストが６種類存在する。
そこで、第１のクラウドサービス内のインシデント分析装置１３のインシデント分析プログラム２２は、リクエスト発行プログラム２２１とリクエストデータ収集プログラム２２２とを有する。リクエスト発行プログラム２２１が実行されると、５分毎など一定時間毎に、上記と同じ６種類のダミーリクエストDRを第２のサービスシステムに発行し、各リクエストのレスポンス（応答メッセージとレスポンス時間）のログを出力する。また、リクエストデータ収集プログラム２２２が実行されると、６種類のダミーリクエストの時刻（発行時刻または測定時刻）、発行元サービスシステム、発行先サービスシステム、応答メッセージ、レスポンス時間を関連付けたリクエストデータを収集し、リクエスト管理データベース２４に追加する。
図１１は、リクエスト管理データベース２４の例を示す図である。リクエスト管理データベース２４は、６種類のダミーリクエストの時刻（発行時刻または測定時刻）、発行元サービスシステム名、発行先サービスシステム名、応答メッセージ、レスポンス時間を関連付けたリクエストデータの集合である。図１１の例では、２０１６年５月１２日１０：００に、上記の６種類のダミーリクエストが発行され、その５分後の２０１６年５月１２日１０：０５に、同様の６種類のダミーリクエスト（図１１にはそのうち４種類が示される）が発行されている。そして、時刻１０：００に発行された６種類のダミーリクエストは、応答メッセージが全て成功（Success）であり、レスポンス時間がそれぞれ３，３，２，２，３，４秒と比較的短い。それに対して、５分後の時刻１０：０５に発行された６種類のダミーリクエストは、発行元がサービスシステムS_A、発行先がサービスシステムS_1とS_2の２つのダミーリクエストは応答メッセージが不良リクエスト（Bad Request）で、レスポンス時間が６０秒と比較的長く、発行元がS_B、発行先がS_1,S_2の２つのダミーリクエストは応答メッセージは成功だが、レスポンス時間が１０秒と比較的長くなっている。残りの２つのダミーリクエストの記録は、図１１中省略されている。
このように、リクエスト管理データベースは、発行元サービスシステムと発行先サービスシステムの組み合わせ別に、ダミーのリクエストのリクエストデータを収集する。また、リクエスト発行プログラム２２１とリクエストデータ収集プログラム２２２により、クラウドサービスのユーザシステムによるリクエストの発行とは別に、ダミーのリクエストを定期的に発行することで、ユーザシステムの動作への影響を最小限にとどめながら、第２のクラウドサービスのサーバセンタのサービスシステムの状態をダミーのリクエストの応答情報により収集することができる。
［インシデントデータの収集］
図５に戻り、インシデントの発生が報告されると、インシデント分析プログラム２２のインシデント原因推定プログラム２２３がプロセッサにより実行される。例えば、図５に示される通り、サービスシステムのユーザ端末装置３４から第１のサービスシステムのいずれかでインシデントが発生していることが通知される（S4）。この通知に応答して、プロセッサがインシデント原因推定プログラム２２３を実行し、発生したインシデントに、インシデントの発生時刻と、インシデント発生元サービスシステムと、インシデントの現象とを関連付けたインシデントデータを、インシデントデータベース２６に追加する（S5）。インシデントの現象とは、例えばサービスシステムの動作が遅くなりアクセスに対するレスポンスが遅くなった、アクセスに対して正しくない応答がでる、アクセスに対してエラーが発生するなどである。
［インシデントの原因推定］
一方、クラウドサービスの運用者端末装置３０には、過去のインシデントと新規発生したインシデントのリストが表示される（S6）。運用者端末装置において、運用者が新規発生したインシデントを指定して分析依頼を発行すると（S7）、プロセッサはインシデント原因推定プログラムを実行して、以下の処理を行う。以下の処理は、必ずしも新規のインシデントが発生したときに行う必要はなく、新規のインシデント発生後の所定のタイミングで行われる。但し、新規インシデントが発生した直後に行うことで、その後に発生するインシデントの原因推定に役立てることができるので、発生直後に行うのが好ましい。
［インシデント関連リクエストデータの抽出］
まず、プロセッサはインシデント原因推定プログラムを実行して、リクエスト管理データベース２４から、新規インシデントの発生元の第１のサービスシステムに関連するリクエストデータであり且つ新規インシデントが発生した時（発生した時間帯）のリクエストデータを抽出し、インシデント関連リクエストデータベース２５を生成する（S8）。
図７は、インシデント原因推定プログラムにおける上記の工程S4, S5, S8の詳細なフローチャートを示す図である。前述のとおり、新規インシデントが発生すると（S4）、プロセッサはインシデント原因推定プログラムの実行により、発生後の所定のタイミングで、新規インシデントのデータをインシデントデータベース２６に追加する（S5）。
図１２は、インシデントデータベース２６の一例を示す図である。図１２の例は、インシデント番号が００００１が新規インシデントのデータであり、インシデント番号００００２，０００００３が過去のインシデントのデータである。各インシデントデータは、その発生日時と、インシデントの発生元サービス名と、インシデントの現象とが関連付けられる。インシデントの原因と推定される原因サービスは、過去のインシデントでは推定されるサービス名が記録されているが、新規のインシデント（００００１）には未分析であるので未記録である。また、各インシデントに関連するリクエストデータベースが、リクエストデータベース内のリクエストデータの時間帯情報により各インシデントに関連付けられている。
図１２の例は、全てのインシデントデータが、発生元サービス名がS_Aであり、現象が「S_Aのレスポンスが悪化しました。」である。つまり、サービスシステムの利用者がサービスシステムS_Aを利用中にアクセスに対するレスポンスが悪化した現象を見出し、「S_Aのレスポンスが悪化した」という現象のインシデントを報告した例である。また、過去のインシデント（００００２）で推定された原因サービスがS_1であり、過去のインシデント（００００３）で推定された原因サービスがS_1、S_2である。
図７に戻り、プロセッサはインシデント原因推定プログラムの実行により、リクエスト管理データベースから、新規インシデントが発生した時間帯（発生時の前後約１時間）のリクエストデータであり、新規インシデントの発生元のPaaS側サービスシステムと関連するIaaS側サービスシステムを抽出する（S8_1）。つまり、新規インシデントの発生元サービスシステムを発行元とするリクエストの発行先サービスシステムの情報を抽出する。図１２の例では、新規インシデントの発生元PaaS側サービスシステムはS_Aであるので、図１１の例では、サービスシステムS_Aを発行元とするリクエストの発行先サービスシステムS_1, S_2が抽出される。
さらに、プロセッサは、リクエスト管理データベースから、上記抽出したIaaS側サービスシステム（S_1）と関連するPaaS側サービスシステムを抽出する（S8_2）。つまり、抽出したサービスシステムを発行先とするリクエストの発行元サービスシステムS_A,S_Bを抽出する。図１１の例では、サービスシステムS_1, S_2を発行先とするリクエストの発行元サービスシステムS_A, S_Bが抽出される。
そして、プロセッサは、リクエスト管理データベース２４から、インシデントの発生元のPaaS側サービス（S_A）と、抽出したPaaS側サービス（S_A,S_B）及びIaaS側サービス（S_1,S_2）に関連するリクエストデータを抽出して、新規インシデント関連リクエストデータベース２５を生成する（S8_3）。
上記の抽出されたリクエストデータについて説明すると、図６の例において、新規インシデントが発生したサービスシステムS_Aを発行元とするリクエストはリクエストR_A1,R_A2の２種類である。この２種類のリクエストのレスポンスは、新規インシデントの直接の原因になる可能性がある。そして、これら２種類のリクエストの発行先サービスシステムS_1, S_2を発行先とするリクエストはリクエストR_B1, R_B2の２種類である。この２種類のリクエストは、それぞれサービスシステムS_1,S_2の動作に影響を与える可能性があり、新規インシデントの原因となるIaaS側のサービスシステムの分析に必要なリクエストである。
そして、仮にリクエストR_A1とR_B1のレスポンスに問題が生じていて、リクエストR_A2とR_B2のレスポンスに問題が生じていなければ、IaaS側のサービスシステムS_1に原因があると推定することができる。または、仮にリクエストR_A1とR_A2のレスポンスに問題が生じていて、リクエストR_B1とR_B2のレスポンスに問題が生じていないと、PaaS側のサービスシステムS_Aに何らかの原因があると推定することができる。このように、プロセッサは、新規インシデントの原因と推定されるサービスシステムを絞り込むに必要なダミーリクエストのリクエストデータを、新規インシデントの時間帯に絞ってリクエスト管理データベース２４から抽出して、新規インシデント関連リクエストデータベース２５を生成する。
図１３は、新規インシデント関連リクエストデータベースの例を示す図である。前述のとおり、新規インシデントの発生元がPaaS側のサービスシステムS_Aであったので、新規インシデントが発生した時間２０１６年５月１２日１０：０５前後約１時間内の４種類のリクエストR_A1, R_A2, R_B1, R_B2のリクエストデータが、リクエスト管理データベース２４（図１１）から抽出され、新規インシデント関連リクエストデータベース２５（図１３）が生成される。
図１３の新規インシデント関連リクエストデータベース２５には、レスポンス変化率と異常判断の欄（コラム）があるが、これらの欄の情報は、新規インシデント関連リクエストデータベース２５を生成した後に、適宜計算または判断されて記憶される。したがって、新規インシデント関連リクエストデータベースを生成した工程S8では、これらの欄の情報は未だ記憶されていない。
［各リクエストデータの正常、異常判定］
図５に戻り、プロセッサはインシデント原因推定プログラムの実行により、新規インシデント関連リクエストデータベースの各リクエストデータのレスポンス時間が、新規インシデント発生時前後（約１時間）で収集している同じ発行元発行先リクエストのレスポンス時間の平均値より所定閾値を超える場合は異常状態、平均値より所定閾値内の場合は正常状態と判定する（S9）。前記のレスポンス時間の平均値は、同じ発行元発行先のリクエスト毎に算出される。また、レスポンス時間の平均値は、直前の正常時に収集したレスポンス時間の平均値でもよい。
図８は、工程S9の詳細フローチャートを示す図である。プロセッサはインシデント原因推定プログラムの実行により、図１３の新規インシデント関連リクエストデータベース２５内の全てのリクエストデータに対して、次の処理を実行する。すなわち、各レスポンス時間が、常時収集している同じ発行先発行元リクエストのレスポンス時間の平均値より所定閾値超えているか、またはレスポンスメッセージが不良（Bad）か否かを判定する（S9_1）。いずれかがYESであれば、そのリクエストデータは異常と判定し（S9_2）、いずれもNOであれば、そのリクエストデータは正常と判定する（S9_3）。そして、判定した正常または異常を、図１３に示す通り、リクエストDB２５の異常判定の欄に記録する（S9_4）。
図１３には、時刻２０１６／５／１２、１０：００以前のリクエストデータは正常、１０：０５以降のリクエストデータは異常と記録されている。この判定から、インシデントの発生時刻が１０：００〜１０：０５の間であると推定できる。この推定されたインシデント発生時刻に基づいて、後述する新規インシデントと過去のインシデントのインシデント関連レスポンスDBにおける各リクエスト毎に（同じ発行元発行先リクエスト毎に）、レスポンス時間の推移傾向、例えばレスポンス時間の変化率の相関性が判定される。
［レスポンス変化率の算出］
図５に戻り、プロセッサはインシデント原因推定プログラムの実行により、新規インシデント関連リクエストデータベース２５の発行元と発行先が同じリクエストのレスポンス時間の変化率を算出する（S10）。
図９は、工程S10の詳細フローチャートを示す図である。プロセッサは、新規インシデント関連リクエストデータベース２５（図１３）内の、インシデント発生推定時刻前後の所定時間（約１０分：例えば２セットのリクエストデータ）のリクエストデータに対して、以下の処理を行ってレスポンス時間の変化率を算出する。まず、プロセッサは、同じリクエスト発行元サービスシステムとリクエスト発行先サービスシステムのリクエストのペアで、時間的に隣接するペアを検出する（S10_1）。図１３の例では、例えば、発行元サービスシステムS_B、発行先サービスシステムS_1のリクエストで、時刻１０：００と１０：０５のリクエストのペアを検出する。
そして、プロセッサは、検出したペアのリクエストのレスポンス時間の変化率を算出する（S10_2）。レスポンス時間の変化率は、ペアのリクエストのレスポンス時間の差分を時間差で除算して求める。図１３中○を記した２つのレスポンス時間の場合は、レスポンス時間の変化率は、
変化率＝（１０−２）／（１０：０５−１０：００）＝１．６s/min
である。したがって、変化後のリクエストデータのレスポンス変化率の欄に、算出した１．６が記録される（S10_3）。図１３のレスポンス変化率の欄の値は、上記と同様に算出された値である。例えば、時刻１０：００の４つのリクエストデータのレスポンス変化率は、図示されていない時刻９：５５の４つのリクエストデータのレスポンス時間からの変化率である。一方、時刻１０：０５の４つのリクエストデータのレスポンス変化率の値は、時刻１０：００の４つのリクエストデータのレスポンス時間からの変化率である。
［類似する過去のインシデントの検出］
図５に戻り、プロセッサはインシデント原因推定プログラムの実行により、新規インシデントと同じ発生元サービスシステムで、同じ現象を有する過去のインシデントを、インシデントデータベース２６から抽出する（S11）。さらに、プロセッサは、抽出した過去のインシデントのうち、新規インシデントのレスポンス時間の変化率が相関性を有する（例えば類似する）過去のインシデントを検出する（S12）。この相関性は、同じ発行元発行先のリクエストの相関性であり、インシデント発生時刻を基準にして新規インシデントと過去のインシデントのリクエスト間を対応付けて算出される相関性である。
図１０は、工程S11,S12の詳細フローチャートを示す図である。プロセッサはインシデント原因推定プログラムの実行により、インシデントデータベース２６から、新規インシデントと同じ発生元サービスシステムで、同じまたは類似する現象を有する過去のインシデントを抽出する（S11_1）。このとき、類似する現象を有する過去のインシデントがあれば（S11_2のYES）、プロセッサは、新規インシデントと過去のインシデントのレスポンス変化率（レスポンス時間の変化率）の相関を計算する（S12_1）。
図１４は、過去のインシデント関連リクエストデータベース２５の一例を示す図である。この例は、時刻２０１６年５月１０日９：００〜９：０５の時間帯のリクエストデータベースである。前述のとおり、インシデントデータベースからインシデント発生元のサービスシステムが同じ過去のインシデントを抽出しているので、過去のインシデントに関連付けられたインシデント関連リクエストデータベースには、新規インシデント関連リクエストデータベース（図１３）と同じ４種類のリクエストのデータが記憶されている。
次に、新規インシデントと過去のインシデントのレスポンス変化率（レスポンス時間の変化率）の相関の計算は、例えば、以下のような相関係数の計算である。
相関係数＝［｛Σ（F(k)-F'）(G(k)-G')｝/n］÷[√｛Σ（F(k)-F'）2/n｝√｛Σ（G(k)-G'）2/n｝]
ここで、除数の２つのルート（√）はそれぞれ｛Σ（F(k)-F'）2/n｝、｛Σ（G(k)-G'）2/n｝の平方根である。また、ｎはサンプル数、Σはｎ個のサンプルの累積、F'、G'は平均値である。
具体的に説明すると、図１３の新規インシデント関連リクエストデータベースの発行元S_B、発行先S_1のリクエストの隣接時間のペアのレスポンス変化率は「０．４」と「１．６」であり、図１４の過去のインシデント関連リクエストデータベースの同じ発行元S_B、発行先S_1のリクエストの隣接時間のペアのレスポンス変化率も「０．４」と「１．６」である。この場合、上記相関係数の式によって算出される相関係数は「１．０」になり、相関係数は非常に高くなる。
上記の相関係数は、２つの波形の各サンプル点での値について算出して２つの波形の相関性を求めるものであり、一般に、相関係数が０．４−０．７であれば高い相関があり、０．７−１．０であればかなり高い相関があるとされている。
図１５は、レスポンス時間の変化率の２つの波形間の相関性を説明する図である。例えば、実線が新規のインシデントのある発行元・発行先リクエストのレスポンス時間の変化率の波形を示し、破線が過去のインシデントの同じ発行元・発行先リクエストのレスポンス時間の変化率の波形を示す。各サンプル点で変化率が変動している。
そして、前述の判定工程S9で正常と判定された最後のサンプル点SPL1と異常と判定された最初のサンプル点SPL2の間がインシデントの推定発生時刻と見なして、推定発生時刻を基準にして対応付けた前後複数のサンプル点での変化率について、上記の相関係数の式により両波形の相関性を求める。
例えば、インシデントの類似性に最も影響を与えると考えられるサンプル点SPL1とSPL2のレスポンス時間の変化率が一致または類似すれば、２つのインシデントの波形は相関性が高いと判定する。さらに、サンプル点SPL1以前の正常時のレスポンス時間の変化率の波形や、サンプル点SPL2以降の異常時のレスポンス時間の変化率の波形が一致または類似するか否かを判定することで、類似する過去にインシデントの抽出精度をより高くすることができる。
このようにインシデント発生時刻を基準にして２つのインシデントの対応するリクエスト間でそのレスポンス時間の変化率の時間に対する波形（パターン）が類似するか否かを、相関値が高いか否かで判定する。
ここで、図１３の新規インシデント関連リクエストDBと図１４の過去のインシデント関連リクエストDBのレスポンス時間とレスポンス時間の変化率について説明する。
図１３の新規インシデント関連リクエストDBでは、各リクエストデータのレスポンス時間は、「３，３，２，２，６０，６０，１０，１０」となっている。これに対して、図１４の過去のインシデント関連リクエストDBでは、「６，６，４，４，６３，６３，１２，１２」である。この例では、たとえば、過去のインシデントが発生した時間帯２０１６年５月１０日９：００−９：０５での各リクエストのレスポンス時間は長かったが、その後、ロードバランサがIaaS側のサービスシステムS_1,S_2に対してスケールアウトを実行し、各サービスシステムの仮想マシン数を増大した結果、新規インシデント発生時間帯の２０１６年5月１２日１０：００−１０：０５でのレスポンス時間は短くなっている。
しかし、両インシデントの発生元のサービスシステムは同じであり現象も同じである一方、レスポンス時間は異なるが、レスポンス時間の変化率の波形は類似している。このような場合、本実施の形態では、両インシデントは同じ原因サービスシステムに起因して発生した類似のインシデントと判定する。このように、クラウドサービスにおいて構築されたサービスシステムの一つの特徴として、ロードバランサが適宜スケールアウトを実施してレスポンス時間を短くしたり、スケールイン（仮想マシン数を減少させる）を実施してレスポンス時間を長くしたりする。したがって、両インシデントの相関性をチェックする際、レスポンス時間そのものの相関性よりもレスポンス時間の変化率の相関性をチェックすることが、ロードバランサの制御による影響を薄めることができ、好ましい。
また、相関性の計算において、新規インシデントと過去のインシデントとで４種類のダミーリクエストのレスポンス時間の変化率それぞれについて相関性を算出して、類似する過去のインシデントを検出するようにしてもよい。
図５に戻り、プロセッサがインシデント原因推定プログラムを実行することで、新規インシデントのレスポンス時間の変化率が相関する過去のインシデントを検出すると（S12）、インシデントDBを参照し、検出した過去のインシデントに対して特定されている原因サービスシステムの情報を抽出し、インシデント管理インターフェースが、その原因サービスシステムを新規インシデントの推定される原因サービスシステムとして表示し、運用者に分析依頼の回答を行う（S13）。
図１２、図１３、図１４の例によれば、図１２のインシデントデータベースのインシデント番号００００２が、新規インシデント００００１とレスポンス時間の変化率について相関性があると判定され、インシデント番号００００２の過去のインシデントの原因サービスシステムS_1が、新規インシデントの原因として推定される。そして、インシデントデータベース２６内の新規インシデント００００１に対し推定された原因サービスシステムの情報が記憶される。
以上、第１の実施の形態によれば、管理サーバのインシデント分析装置が、第１のクラウドサービスの第１のサービスシステムから第２のクラウドサービスの第２のサービスシステム宛てのダミーリクエストを所定時間毎に発行し、ダミーリクエストに発行元と発行先情報及びその応答メッセージやレスポンス時間、発行時刻を関連付けたリクエストデータをリクエスト管理DBに追加する。そして、インシデントが発生すると、インシデント発生時間帯のインシデント発生元のサービスシステムに関連するリクエストデータをリクエスト管理DBから抽出して、新規インシデント関連リクエストDBを生成する。そして、過去のインシデントのうち、新規インシデントのダミーリクエストのレスポンス時間の変化率が相関する過去のインシデントを検出し、その過去のインシデントの原因サービスシステムを新規インシデントの原因と推定する。
クラウドサービスの一つの特徴として各サービスシステムの構成が時間の経過と共に変化する。本実施の形態では、そのようなサービスシステムの構成変更によるレスポンス時間の変動を考慮して、レスポンス時間の変化率の相関性により、インシデント間の相関性をチェックする。
［第１の実施の形態の変形例］
第１の実施の形態の変形例として、新規インシデントと類似する過去のインシデントの特定処理において、それぞれのインシデント関連リクエストデータ内の同じ発行元発行先リクエスト間で、レスポンス時間の変化率の相関性が高いことに加えて、応答メッセージが同じ、正常・異常の判定結果が同じであることも判定基準に加えても良い。さらに、複数の発行元発行先リクエストそれぞれについて、上記の判定基準で相関性を有するか否かを判定しても良い。
［第２の実施の形態］
図１６は、第２の実施の形態におけるインシデント分析プログラムのフローチャート図である。第２の実施の形態では、プロセッサがインシデント分析プログラムを実行して、第１のクラウドサービスCS_1の第１のサービスシステムS_A, S_B, S_Cから第２のクラウドサービスCS_2の第２のサービスシステムS_1,S_2,S_3宛てのダミーリクエストを所定時間毎に発行し(S1)、ダミーリクエストに発行元と発行先情報及びその応答メッセージやレスポンス時間、発行時刻を関連付けたリクエストデータをリクエスト管理DBに追加する(S3)。この点は、第１の実施の形態と同様である。
そして、新規インシデントの発生が報告されると（S4）、プロセッサはインシデントデータベース２６に新規インシデントのデータを追加する（S5）。さらに、クラウドサービスの運用者端末装置３０がインシデントリストの表示画面（S6）から新規インシデントを指定してそのインシデントの分析依頼を受信すると（S7）、プロセッサはインシデント原因推定プログラムを実行して、新規インシデントについてインシデント関連リクエストデータベース２５を生成する（S8）。新規インシデント関連リクエストデータベースの生成は、第１の実施の形態と同様である。
さらに、プロセッサは、新規インシデント関連リクエストデータベースの各リクエストのレスポンス時間が、平均値より閾値を超えている場合は異常、閾値以内であれば正常と判定し、判定結果をデータベースに追加する（S9）。この処理も第１の実施の形態の処理と同様である。
最後に、プロセッサは、新規インシデント関連リクエストデータベースの各リクエストのレスポンス時間、応答メッセージ、正常・異常判定結果に基づいて、インシデントの原因となっている第２のサービスシステムを推定する（S20）。そして、インシデント管理インターフェースにより推定された原因サービスを表示する（S13）。
図１７は、第２の実施の形態における新規インシデント関連リクエストデータベース２５の一例を示す図である。この例によれば、時刻１０：０５以降のリクエストにレスポンスメッセージが「Bad Request」になったり、レスポンス時間が平均値より閾値を超えるほど異なり異常判定が異常になったりしたものが存在する。具体的にはリクエスト発行元と発行先のサービスシステムの組み合わせが、S_AとS_１、S_BとS_1は異常である。一方、リクエスト発行元と発行先の組み合わせが、S_AとS_2、S_BとS_2は正常である。
このような場合、インシデント原因推定プログラムを実行するプロセッサは、サービスシステムS_1に何らかの問題が発生し、新規インシデントの原因サービスシステムであると推定する。
同様に、応答メッセージが「Bad Request」のリクエストの発行元と発行先に基づいて、上記と同様の解析をして、新規インシデントの原因サービスシステムを推定してもよい。
以上の通り、第２の実施の形態では、他人の第２のクラウドサービスで構築された第２のサービスシステムのエラー情報や動作情報を入手できなくても、自分の第１のクラウドサービスのインシデント分析装置が発行元を第１のサービスシステムとし発行先を第２のサービスシステムとするダミーのリクエストを所定時間毎に発行し、その応答情報を含むリクエストデータをリクエスト管理データベースに蓄積する。そして、インシデントが発生した場合、インシデント発生元のサービスシステムに影響を与えるリクエストデータを抽出し、分析することで、インシデントの原因と推定される第２のサービスシステムを特定する。
上記のインシデント分析プログラム、同方法、同装置は、いずれも原因となるインシデントを特定するプログラム、同方法、同装置に対応する。
以上の実施の形態をまとめると，次の付記のとおりである。
（付記１）
第１のクラウドサービスベンダのサーバセンタ内に構築された複数の第１のサービスシステムを発行元とし、前記第１のクラウドサービスベンダと異なる第２のクラウドサービスベンダのサーバセンタ内に構築された複数の第２のサービスシステムを発行先とするリクエストと、前記リクエストのレスポンス時間と、前記リクエストの時刻とを関連付けたリクエストデータを有するリクエスト管理データベースから、前記複数の第１のサービスシステムのいずれかで発生した新規インシデントの発生元の第１のサービスシステムに関連する発行元第１のサービスシステムから発行先第２のサービスシステムに発行したリクエストデータであり、さらに前記新規インシデントが発生した時のリクエストデータを、抽出して、新規インシデント関連リクエストデータベースを生成する処理と、
過去に発生した複数のインシデントそれぞれに対して生成された複数の過去のインシデント関連リクエストデータベースから、前記新規インシデント関連リクエストデータベースに含まれる発行元と発行先が同じリクエストデータのレスポンス時間の推移傾向と、所定の相関性を有するレスポンス時間の推移傾向を有する過去のインシデント関連リクエストデータベースを抽出する処理と、
前記抽出された過去のインシデント関連リクエストデータベースの過去のインシデントの原因と推定された第２のサービスシステムの情報を特定し、出力する処理と、
をコンピュータに実行させるインシデント分析プログラム。
（付記２）
さらに、
前記複数の第１のサービスシステムを発行元とし、前記複数の第２のサービスシステムを発行先とする複数のリクエストを所定のタイミングで発行し、前記発行したリクエストの前記リクエストデータを前記リクエスト管理データベースに追加する処理を有する、付記１に記載のインシデント分析プログラム。
（付記３）
前記過去のインシデント関連リクエストデータベースを抽出する処理は、
過去のインシデントについて、インシデント発生元識別情報と、インシデントの現象情報と、インシデントの原因と推定される原因第２サービスシステムとを関連付けたインシデントデータベースから、新規インシデントと同じ発生元第１サービスシステムと、新規インシデントと類似する現象とを有する過去のインシデントを抽出し、
前記抽出した過去のインシデントに対応する前記複数の過去のインシデント関連リクエストデータベースから、前記相関性を有する前記過去のインシデント関連リクエストデータベースを抽出する処理を有する、付記１に記載のインシデント分析プログラム。
（付記４）
前記新規インシデント関連リクエストデータベースを生成する処理は、
前記新規インシデントの発生元の第１のサービスシステムを発行元とする第１のリクエストと、前記第１のリクエストの発行先第２サービスシステムを発行先とし前記第１のリクエストを除いた第２のリクエストのリクエストデータであり、且つ前記新規インシデントが発生した時のリクエストデータを、前記リクエスト管理データベースから抽出する処理を有する、付記１に記載のインシデント分析プログラム。
（付記５）
前記レスポンス時間の推移傾向は、発行元と発行先が同じ一対のリクエストのレスポンス時間の単位時間に対する変化量を示すレスポンス時間の変化率である、付記１に記載のインシデント分析プログラム。
（付記６）
前記相関性は、インシデント発生前と発生後の前記レスポンス時間の変化率の相関性である、付記５に記載のインシデント分析プログラム。
（付記７）
前記過去のインシデント関連リクエストデータベースを抽出する処理の前に、
新規インシデント関連リクエストデータベース内の各リクエストデータのレスポンス時間が平均値より閾値以内の場合に正常と、前記平均値より閾値を超える場合に異常と判定し、
正常のリクエストデータと異常のリクエストデータの境界の時刻の前後所定時間内のリクエストデータについて、前記レスポンス時間の変化率を算出する処理を有する、付記１に記載のインシデント分析プログラム。
（付記８）
前記過去のインシデント関連リクエストデータベースを抽出する処理は、
前記境界の時刻の前後所定時間内の複数のリクエストデータの前記レスポンス変化率の時間に対するパターンが類似する場合、所定の相関性を有すると判定する処理を有する、付記６に記載のインシデント分析プログラム。
（付記９）
第１のクラウドサービスベンダのサーバセンタ内に構築された複数の第１のサービスシステムを発行元とし、前記第１のクラウドサービスベンダと異なる第２のクラウドサービスベンダのサーバセンタ内に構築された複数の第２のサービスシステムを発行先とするリクエストと、前記リクエストのレスポンス時間と、前記リクエストの時刻とを関連付けたリクエストデータを有するリクエスト管理データベースから、前記複数の第１のサービスシステムのいずれかで発生した新規インシデントの発生元の第１のサービスシステムに関連する発行元第１のサービスシステムから発行先第２のサービスシステムに発行したリクエストデータであり、さらに前記新規インシデントが発生した時のリクエストデータを、抽出して、新規インシデント関連リクエストデータベースを生成する処理と、
過去に発生した複数のインシデントそれぞれに対して生成された複数の過去のインシデント関連リクエストデータベースから、前記新規インシデント関連リクエストデータベースに含まれる発行元と発行先が同じリクエストデータのレスポンス時間の推移傾向と、所定の相関性を有するレスポンス時間の推移傾向を有する過去のインシデント関連リクエストデータベースを抽出する処理と、
前記抽出された過去のインシデント関連リクエストデータベースの過去のインシデントの原因と推定された第２のサービスシステムの情報を特定し、出力する処理と、
を有するインシデント分析方法。
（付記１０）
第１のクラウドサービスベンダのサーバセンタ内に構築された複数の第１のサービスシステムを発行元とし、前記第１のクラウドサービスベンダと異なる第２のクラウドサービスベンダのサーバセンタ内に構築された複数の第２のサービスシステムを発行先とするリクエストと、前記リクエストのレスポンス時間と、前記リクエストの時刻とを関連付けたリクエストデータを有するリクエスト管理データベースから、前記複数の第１のサービスシステムのいずれかで発生した新規インシデントの発生元の第１のサービスシステムに関連する発行元第１のサービスシステムから発行先第２のサービスシステムに発行したリクエストデータであり、さらに前記新規インシデントが発生した時のリクエストデータを、抽出して、新規インシデント関連リクエストデータベースを生成する処理部と、
過去に発生した複数のインシデントそれぞれに対して生成された複数の過去のインシデント関連リクエストデータベースから、前記新規インシデント関連リクエストデータベースに含まれる発行元と発行先が同じリクエストデータのレスポンス時間の推移傾向と、所定の相関性を有するレスポンス時間の推移傾向を有する過去のインシデント関連リクエストデータベースを抽出する処理部と、
前記抽出された過去のインシデント関連リクエストデータベースの過去のインシデントの原因と推定された第２のサービスシステムの情報を特定し、出力する処理部と、
を有するインシデント分析を行う情報処理装置。
（付記１１）
第１のクラウドサービスベンダのサーバセンタ内に構築された複数の第１のサービスシステムを発行元とし、前記第１のクラウドサービスベンダと異なる第２のクラウドサービスベンダのサーバセンタ内に構築された複数の第２のサービスシステムを発行先とする複数のリクエストを所定のタイミングで発行し、前記発行したリクエストに前記リクエストのレスポンス時間と前記リクエストの時刻とを関連付けたリクエストデータをリクエスト管理データベースに追加する処理と、
前記複数の第１のサービスシステムのいずれかで発生した新規インシデントの発生元の第１のサービスシステムに関連する発行元第１のサービスシステムから発行先第２のサービスシステムに発行したリクエストデータであり、さらに前記新規インシデントが発生した時のリクエストデータを、前記リクエスト管理データベースから抽出して、新規インシデント関連リクエストデータベースを生成する処理と、
前記新規インシデント関連リクエストデータベースに含まれるリクエストデータのレスポンス時間に基づいて、前記新規インシデントの原因となる第２のサービスシステムを推定する処理と、
をコンピュータに実行させるインシデント分析プログラム。
（付記１２）
前記新規インシデント関連リクエストデータベースを生成する処理は、
前記新規インシデントの発生元の第１のサービスシステムを発行元とする第１のリクエストと、前記第１のリクエストの発行先第２サービスシステムを発行先とし前記第１のリクエストを除いた第２のリクエストとを有し、さらに前記新規インシデントが発生した時のリクエストデータを、前記リクエスト管理データベースから抽出する処理を有する、付記１１に記載のインシデント分析プログラム。
（付記１３）
サービスが発行した要求に対する応答時間に関するインシデントの発生に応じて出力された前記サービスの識別情報を取得し、
サービスの識別情報と、該サービスが発行した要求の発行先である発行先サービスの識別情報と、該要求に対する応答時間とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた発行先サービスの識別情報及び応答時間を取得し、
サービスの識別情報と、該サービスが発行した要求に対する応答時間に関するインシデントの原因となった原因サービスの識別情報と、該インシデントの発生前に生じた要求に対する応答時間の遷移傾向を示す情報とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた原因サービスのうち、応答時間の遷移傾向を示す情報が、取得した前記応答時間の遷移傾向に対して所定の相関性を有する原因サービスを特定し、
特定した前記原因サービスの識別情報を出力する、
処理をコンピュータに実行させることを特徴とするサービス特定プログラム。
（付記１４）
サービスが発行した要求に対する応答時間に関するインシデントの発生に応じて出力された前記サービスの識別情報を取得し、
サービスの識別情報と、該サービスが発行した要求の発行先である発行先サービスの識別情報と、該要求に対する応答時間とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた発行先サービスの識別情報及び応答時間を取得し、
サービスの識別情報と、該サービスが発行した要求に対する応答時間に関するインシデントの原因となった原因サービスの識別情報と、該インシデントの発生前に生じた要求に対する応答時間の遷移傾向を示す情報とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた原因サービスのうち、応答時間の遷移傾向を示す情報が、取得した前記応答時間の遷移傾向に対して所定の相関性を有する原因サービスを特定し、
特定した前記原因サービスの識別情報を出力する、
サービス特定方法。
（付記１５）
サービスが発行した要求に対する応答時間に関するインシデントの発生に応じて出力された前記サービスの識別情報を取得する第１の取得部と、
サービスの識別情報と、該サービスが発行した要求の発行先である発行先サービスの識別情報と、該要求に対する応答時間とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた発行先サービスの識別情報及び応答時間を取得する第２の取得部と、
サービスの識別情報と、該サービスが発行した要求に対する応答時間に関するインシデントの原因となった原因サービスの識別情報と、該インシデントの発生前に生じた要求に対する応答時間の遷移傾向を示す情報とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた原因サービスのうち、応答時間の遷移傾向を示す情報が、取得した前記応答時間の遷移傾向に対して所定の相関性を有する原因サービスを特定する特定部と、
特定した前記原因サービスの識別情報を出力する出力部とを有するサービス特定装置。
上記付記１３，１４，１５の「サービス」はサービスシステムに、「要求」はリクエストにそれぞれ対応する。また、「サービスが発行した要求に対する応答時間に関するインシデント」とは、サービスシステムが発行したリクエストの応答時間が長くなったインシデントに対応する。そして、「サービスの識別情報」及び「出力された前記サービスの識別情報」は、要求を発行したサービスの識別情報に対応する。
CS_1：第１のクラウドサービス（第１のサーバセンタ）
CS_2：第２のクラウドサービス（第２のサーバセンタ）
１０：管理サーバ
１１：クラウドサービス管理装置
１２：クラウドポータルサイト
１３：インシデント分析装置
３０：クラウドサービスCS_1の運用者端末装置
３２：クラウドサービスCS_1のユーザ端末装置
３４：サービスシステムのユーザ端末
ＮＷ：ネットワークシステム
２０：クラウドサービス管理プログラム
２２：インシデント分析プログラム
２２０：インシデント管理インターフェース
２２１：リクエスト発行プログラム
２２２：リクエストデータ収集プログラム
２２３：インシデント原因推定プログラム
２４：リクエスト管理データベース（DB）
２５：インシデント関連リクエストデータベース（DB）
２６：インシデントデータベース（DB）
R_A1：リクエスト
DR：ダミーリクエスト

Claims (13)

  1. 第１のクラウドサービスベンダのサーバセンタ内に構築された複数の第１のサービスシステムを発行元とし、前記第１のクラウドサービスベンダと異なる第２のクラウドサービスベンダのサーバセンタ内に構築された複数の第２のサービスシステムを発行先とするリクエストと、前記リクエストのレスポンス時間と、前記リクエストの時刻とを関連付けたリクエストデータを有するリクエスト管理データベースから、前記複数の第１のサービスシステムのいずれかで発生した新規インシデントの発生元の第１のサービスシステムに関連する発行元第１のサービスシステムから発行先第２のサービスシステムに発行したリクエストデータであり、さらに前記新規インシデントが発生した時のリクエストデータを、抽出して、新規インシデント関連リクエストデータベースを生成する処理と、
    過去に発生した複数のインシデントそれぞれに対して生成された複数の過去のインシデント関連リクエストデータベースから、前記新規インシデント関連リクエストデータベースに含まれる発行元と発行先が同じリクエストデータのレスポンス時間の推移傾向と、所定の相関性を有するレスポンス時間の推移傾向を有する過去のインシデント関連リクエストデータベースを抽出する処理と、
    前記抽出された過去のインシデント関連リクエストデータベースの過去のインシデントの原因と推定された第２のサービスシステムの情報を特定し、出力する処理と、
    をコンピュータに実行させるインシデント分析プログラム。
  2. さらに、
    前記複数の第１のサービスシステムを発行元とし、前記複数の第２のサービスシステムを発行先とする複数のリクエストを所定のタイミングで発行し、前記発行したリクエストの前記リクエストデータを前記リクエスト管理データベースに追加する処理を有する、請求項１に記載のインシデント分析プログラム。
  3. 前記過去のインシデント関連リクエストデータベースを抽出する処理は、
    過去のインシデントについて、インシデント発生元識別情報と、インシデントの現象情報と、インシデントの原因と推定される原因第２サービスシステムとを関連付けたインシデントデータベースから、新規インシデントと同じ発生元第１サービスシステムと、新規インシデントと類似する現象とを有する過去のインシデントを抽出し、
    前記抽出した過去のインシデントに対応する前記複数の過去のインシデント関連リクエストデータベースから、前記相関性を有する前記過去のインシデント関連リクエストデータベースを抽出する処理を有する、請求項１に記載のインシデント分析プログラム。
  4. 前記新規インシデント関連リクエストデータベースを生成する処理は、
    前記新規インシデントの発生元の第１のサービスシステムを発行元とする第１のリクエストと、前記第１のリクエストの発行先第２サービスシステムを発行先とし前記第１のリクエストを除いた第２のリクエストのリクエストデータであり、且つ前記新規インシデントが発生した時のリクエストデータを、前記リクエスト管理データベースから抽出する処理を有する、請求項１に記載のインシデント分析プログラム。
  5. 前記レスポンス時間の推移傾向は、発行元と発行先が同じ一対のリクエストのレスポンス時間の単位時間に対する変化量を示すレスポンス時間の変化率である、請求項１に記載のインシデント分析プログラム。
  6. 前記相関性は、インシデント発生前と発生後の前記レスポンス時間の変化率の相関性である、請求項５に記載のインシデント分析プログラム。
  7. 前記過去のインシデント関連リクエストデータベースを抽出する処理の前に、
    新規インシデント関連リクエストデータベース内の各リクエストデータのレスポンス時間が平均値より閾値以内の場合に正常と、前記平均値より閾値を超える場合に異常と判定し、
    正常のリクエストデータと異常のリクエストデータの境界の時刻の前後所定時間内のリクエストデータについて、前記レスポンス時間の変化率を算出する処理を有する、請求項１に記載のインシデント分析プログラム。
  8. 第１のクラウドサービスベンダのサーバセンタ内に構築された複数の第１のサービスシステムを発行元とし、前記第１のクラウドサービスベンダと異なる第２のクラウドサービスベンダのサーバセンタ内に構築された複数の第２のサービスシステムを発行先とするリクエストと、前記リクエストのレスポンス時間と、前記リクエストの時刻とを関連付けたリクエストデータを有するリクエスト管理データベースから、前記複数の第１のサービスシステムのいずれかで発生した新規インシデントの発生元の第１のサービスシステムに関連する発行元第１のサービスシステムから発行先第２のサービスシステムに発行したリクエストデータであり、さらに前記新規インシデントが発生した時のリクエストデータを、抽出して、新規インシデント関連リクエストデータベースを生成する処理と、
    過去に発生した複数のインシデントそれぞれに対して生成された複数の過去のインシデント関連リクエストデータベースから、前記新規インシデント関連リクエストデータベースに含まれる発行元と発行先が同じリクエストデータのレスポンス時間の推移傾向と、所定の相関性を有するレスポンス時間の推移傾向を有する過去のインシデント関連リクエストデータベースを抽出する処理と、
    前記抽出された過去のインシデント関連リクエストデータベースの過去のインシデントの原因と推定された第２のサービスシステムの情報を特定し、出力する処理と、
    を有するインシデント分析方法。
  9. 第１のクラウドサービスベンダのサーバセンタ内に構築された複数の第１のサービスシステムを発行元とし、前記第１のクラウドサービスベンダと異なる第２のクラウドサービスベンダのサーバセンタ内に構築された複数の第２のサービスシステムを発行先とするリクエストと、前記リクエストのレスポンス時間と、前記リクエストの時刻とを関連付けたリクエストデータを有するリクエスト管理データベースから、前記複数の第１のサービスシステムのいずれかで発生した新規インシデントの発生元の第１のサービスシステムに関連する発行元第１のサービスシステムから発行先第２のサービスシステムに発行したリクエストデータであり、さらに前記新規インシデントが発生した時のリクエストデータを、抽出して、新規インシデント関連リクエストデータベースを生成する処理部と、
    過去に発生した複数のインシデントそれぞれに対して生成された複数の過去のインシデント関連リクエストデータベースから、前記新規インシデント関連リクエストデータベースに含まれる発行元と発行先が同じリクエストデータのレスポンス時間の推移傾向と、所定の相関性を有するレスポンス時間の推移傾向を有する過去のインシデント関連リクエストデータベースを抽出する処理部と、
    前記抽出された過去のインシデント関連リクエストデータベースの過去のインシデントの原因と推定された第２のサービスシステムの情報を特定し、出力する処理部と、
    を有するインシデント分析を行う情報処理装置。
  10. 第１のクラウドサービスベンダのサーバセンタ内に構築された複数の第１のサービスシステムを発行元とし、前記第１のクラウドサービスベンダと異なる第２のクラウドサービスベンダのサーバセンタ内に構築された複数の第２のサービスシステムを発行先とする複数のリクエストを所定のタイミングで発行し、前記発行したリクエストに前記リクエストのレスポンス時間と前記リクエストの時刻とを関連付けたリクエストデータをリクエスト管理データベースに追加する処理と、
    前記複数の第１のサービスシステムのいずれかで発生した新規インシデントの発生元の第１のサービスシステムに関連する発行元第１のサービスシステムから発行先第２のサービスシステムに発行したリクエストデータであり、さらに前記新規インシデントが発生した時のリクエストデータを、前記リクエスト管理データベースから抽出して、新規インシデント関連リクエストデータベースを生成する処理と、
    前記新規インシデント関連リクエストデータベースに含まれるリクエストデータのレスポンス時間に基づいて、前記新規インシデントの原因となる第２のサービスシステムを推定する処理と、
    をコンピュータに実行させるインシデント分析プログラム。
  11. サービスが発行した要求に対する応答時間に関するインシデントの発生に応じて出力された前記サービスの識別情報を取得し、
    サービスの識別情報と、該サービスが発行した要求の発行先である発行先サービスの識別情報と、該要求に対する応答時間とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた発行先サービスの識別情報及び応答時間を取得し、
    サービスの識別情報と、該サービスが発行した要求に対する応答時間に関するインシデントの原因となった原因サービスの識別情報と、該インシデントの発生前に生じた要求に対する応答時間の遷移傾向を示す情報とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた原因サービスのうち、応答時間の遷移傾向を示す情報が、取得した前記応答時間の遷移傾向に対して所定の相関性を有する原因サービスを特定し、
    特定した前記原因サービスの識別情報を出力する、
    処理をコンピュータに実行させることを特徴とするサービス特定プログラム。
  12. サービスが発行した要求に対する応答時間に関するインシデントの発生に応じて出力された前記サービスの識別情報を取得し、
    サービスの識別情報と、該サービスが発行した要求の発行先である発行先サービスの識別情報と、該要求に対する応答時間とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた発行先サービスの識別情報及び応答時間を取得し、
    サービスの識別情報と、該サービスが発行した要求に対する応答時間に関するインシデントの原因となった原因サービスの識別情報と、該インシデントの発生前に生じた要求に対する応答時間の遷移傾向を示す情報とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた原因サービスのうち、応答時間の遷移傾向を示す情報が、取得した前記応答時間の遷移傾向に対して所定の相関性を有する原因サービスを特定し、
    特定した前記原因サービスの識別情報を出力する、
    サービス特定方法。
  13. サービスが発行した要求に対する応答時間に関するインシデントの発生に応じて出力された前記サービスの識別情報を取得する第１の取得部と、
    サービスの識別情報と、該サービスが発行した要求の発行先である発行先サービスの識別情報と、該要求に対する応答時間とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた発行先サービスの識別情報及び応答時間を取得する第２の取得部と、
    サービスの識別情報と、該サービスが発行した要求に対する応答時間に関するインシデントの原因となった原因サービスの識別情報と、該インシデントの発生前に生じた要求に対する応答時間の遷移傾向を示す情報とを対応付けて記憶する記憶部を参照して、取得した前記サービスの識別情報に対応付けられた原因サービスのうち、応答時間の遷移傾向を示す情報が、取得した前記応答時間の遷移傾向に対して所定の相関性を有する原因サービスを特定する特定部と、
    特定した前記原因サービスの識別情報を出力する出力部とを有するサービス特定装置。
JP2016196731A 2016-10-04 2016-10-04 インシデント分析プログラム、インシデント分析方法、情報処理装置、サービス特定プログラム、サービス特定方法及びサービス特定装置 Withdrawn JP2018060332A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2016196731A JP2018060332A (ja) 2016-10-04 2016-10-04 インシデント分析プログラム、インシデント分析方法、情報処理装置、サービス特定プログラム、サービス特定方法及びサービス特定装置
US15/700,812 US20180095819A1 (en) 2016-10-04 2017-09-11 Incident analysis program, incident analysis method, information processing device, service identification program, service identification method, and service identification device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2016196731A JP2018060332A (ja) 2016-10-04 2016-10-04 インシデント分析プログラム、インシデント分析方法、情報処理装置、サービス特定プログラム、サービス特定方法及びサービス特定装置

Publications (1)

Publication Number Publication Date
JP2018060332A true JP2018060332A (ja) 2018-04-12

Family

ID=61758057

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016196731A Withdrawn JP2018060332A (ja) 2016-10-04 2016-10-04 インシデント分析プログラム、インシデント分析方法、情報処理装置、サービス特定プログラム、サービス特定方法及びサービス特定装置

Country Status (2)

Country Link
US (1) US20180095819A1 (ja)
JP (1) JP2018060332A (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10685359B2 (en) * 2017-05-05 2020-06-16 Servicenow, Inc. Identifying clusters for service management operations
JP6898280B2 (ja) * 2018-08-31 2021-07-07 ファナック株式会社 知識作成システム
US11630684B2 (en) 2019-07-26 2023-04-18 Microsoft Technology Licensing, Llc Secure incident investigation workspace generation and investigation control
US11212300B2 (en) * 2019-07-26 2021-12-28 Microsoft Technology Licensing, Llc Secure incident investigation event capture
CN113283600B (zh) * 2021-05-13 2023-10-03 江苏南工科技集团有限公司 一种基于hook技术的安全事件状态分析方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8135995B2 (en) * 2007-10-19 2012-03-13 Oracle International Corporation Diagnostic data repository
US8560887B2 (en) * 2010-12-09 2013-10-15 International Business Machines Corporation Adding scalability and fault tolerance to generic finite state machine frameworks for use in automated incident management of cloud computing infrastructures
US9223632B2 (en) * 2011-05-20 2015-12-29 Microsoft Technology Licensing, Llc Cross-cloud management and troubleshooting
US9652326B1 (en) * 2014-01-24 2017-05-16 Amazon Technologies, Inc. Instance migration for rapid recovery from correlated failures
US10778720B2 (en) * 2015-06-12 2020-09-15 Teleputers, Llc System and method for security health monitoring and attestation of virtual machines in cloud computing systems
US9665420B2 (en) * 2015-07-31 2017-05-30 Ca, Inc. Causal engine and correlation engine based log analyzer
US10176034B2 (en) * 2016-02-16 2019-01-08 International Business Machines Corporation Event relationship analysis in fault management

Also Published As

Publication number Publication date
US20180095819A1 (en) 2018-04-05

Similar Documents

Publication Publication Date Title
US10346282B2 (en) Multi-data analysis based proactive defect detection and resolution
US8224624B2 (en) Using application performance signatures for characterizing application updates
EP2871574B1 (en) Analytics for application programming interfaces
JP2018060332A (ja) インシデント分析プログラム、インシデント分析方法、情報処理装置、サービス特定プログラム、サービス特定方法及びサービス特定装置
EP2523115B1 (en) Operation management device, operation management method, and program storage medium
US8661125B2 (en) System comprising probe runner, monitor, and responder with associated databases for multi-level monitoring of a cloud service
TW201941058A (zh) 異常檢測方法及裝置
JP5267749B2 (ja) 運用管理装置、運用管理方法、及びプログラム
US20090307347A1 (en) Using Transaction Latency Profiles For Characterizing Application Updates
US20160224400A1 (en) Automatic root cause analysis for distributed business transaction
EP2759938A1 (en) Operations management device, operations management method, and program
US20080307269A1 (en) Resolution of Computer Operations Problems Using Fault Trend Analysis
US20140164840A1 (en) Method and system for monitoring transaction execution on a computer network and computer storage medium
JPWO2013140608A1 (ja) イベントの根本原因の解析を支援する方法及びシステム
CN110618924A (zh) 一种web应用系统的链路压力测试方法
US9760467B2 (en) Modeling application performance using evolving functions
US20110302131A1 (en) Analysis-program storing recording medium, analyzing apparatus, and analytic method
KR101423030B1 (ko) 컴퓨터 실행 가능한 어플리케이션 객체 분석 방법, 이를 수행하는 어플리케이션 객체 분석 서버 및 이를 저장하는 기록매체
JP2018165857A (ja) 分析装置、分析システム、分析方法および分析プログラム
JP2016167259A (ja) システムの可用性、特にセーフティクリティカルシステムの可用性を解析するための方法および装置
US9652488B2 (en) Computer product, verification support method, and verification support apparatus
JP2017207894A (ja) 統合監視運用システムおよび方法
JP2016192185A (ja) なりすまし検出システムおよびなりすまし検出方法
EP3011454A1 (en) Generating a fingerprint representing a response of an application to a simulation of a fault of an external service
JP6802122B2 (ja) 原因推定方法およびプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190611

A761 Written withdrawal of application

Free format text: JAPANESE INTERMEDIATE CODE: A761

Effective date: 20191225