JP2014203294A - 障害対応システムおよび障害対応方法 - Google Patents

Abstract

【課題】ネットワーク上の複数装置間でアプリケーションが連携する環境において、障害発生時に障害発生箇所を効率的に特定して、状況に応じた適宜な障害対応をユーザに促し、障害の影響を効果的に抑制可能とする。【解決手段】ネットワーク２０上の情報処理装置１０が、アプリケーション呼び出し毎にトランザクションＩＤを含む通信ログを格納し、障害発生時にエラー内容とトランザクションＩＤを含むアプリログを格納し、障害検知時にアプリログが含むトランザクションＩＤをキーに、障害発生時に利用された第２の情報処理装置１３０を特定し、第２の情報処理装置１３０に対しアプリログ取得と第３の情報処理装置１５０に向けたモジュールの動作確認の少なくとも何れかを要求し、トランザクションＩＤに対応付いたアプリログとモジュール動作確認結果の少なくとも何れかの情報を取得して障害箇所を特定し、障害箇所に応じた対応動作を実行する。【選択図】図１

Description

本発明は、障害対応システムおよび障害対応方法に関するものであり、具体的には、ネットワーク上の複数装置間でアプリケーションが連携する環境において、障害発生時に障害発生箇所を効率的に特定して、状況に応じた適宜な障害対応をユーザに促し、障害の影響を効果的に抑制可能とする技術に関する。

システム障害が発生した場合、発生した障害の原因を特定するために、該当システムにおけるアプリケーション実行時に出力されているログを分析し、その障害状況に応じた処理を実施して障害の影響を低減する技術思想がある。

このような技術としては、例えば、障害通知処理を組み込んだアプリケーションプログラムからの情報を収集する情報収集手段が、障害の発生したアプリケーションプログラムからの障害通知を受けた場合、該受けた障害通知に対応する障害収集処理プログラムを障害通知側に送付する障害情報収集装置（特許文献１参照）などが提案されている。

また、他に、エラーを一意に識別するためのエラーコードとエラーの種類であるエラーレベルとを対応づけたエラーレベル対応表を記憶する記憶手段と、アプリケーションプログラムにおいてエラーが発生すると、該エラーのエラーコードをキーとしてエラーレベル対応表を検索してエラーレベルを取得し、該エラーレベルに応じた障害復旧処理を行うエラーレベル判定手段とを備える障害自動復旧システム（特許文献２参照）なども提案されている。

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

一方、昨今ではスマートフォンやタブレット端末等の高機能な携帯端末が増加しており、これらの携帯端末は、ユーザによるアプリケーションのインストールが端末購入後に自由に実行できる、アプリケーション実行基盤を備えている。また、一部のカーナビゲーション装置も、その購入後にユーザがアプリケーションを自由にインストールできる機能を有している。更に、そうしたカーナビゲーション装置のうち、テレマティクスサービス（ｔｅｌｅｍａｔｉｃｓ ｓｅｒｖｉｃｅ）に接続するものは、スマートフォンで動作するアプリケーションと連携してユーザに機能を提供できるものがある。このスマートフォンで動作するアプリケーションも、カーナビゲーション装置購入後にユーザが自由に追加可能となっている。

上述した、携帯端末、携帯端末と接続したカーナビゲーション装置などの各種装置、および、携帯端末（のキャリア）を介して各種装置に情報提供を行うサーバ、のように、複数の装置がネットワーク上で互いに協働し、しかも装置購入後にユーザが自由にインストールした複数のアプリケーションが実行されるといったシステムに関して、従来の障害対応手法を採用するとしても課題が残されていた。

例えば、従来技術においては、障害情報を収集する対象が、障害の発生したアプリケーションが動作するサーバとなっており、障害発生箇所が不明な場合にネットワーク上で連携して動作する複数の装置から障害情報を自動収集して原因箇所を特定し、必要な対応処理を行うことは実現されていない。また、障害発生時のエラーコードに基づいて状況を判断し、必要な対応処理を行う場合、プログラム品質の問題等によりエラーコードが正しく出力されない、或いは障害によってエラーコードの出力自体が実行されない、といった事態に対応することはできない。また、障害発生時に、被害を受けたユーザの状況を踏まえた適切なメッセージを、適切なタイミングに調整して出力するといった、障害復旧以外の幅広い目的に対応することも出来なかった。

そこで本発明の目的は、ネットワーク上の複数装置間でアプリケーションが連携する環境において、障害発生時に障害発生箇所を効率的に特定して、状況に応じた適宜な障害対応をユーザに促し、障害の影響を効果的に抑制可能とする技術を提供することにある。

上記課題を解決する本発明の障害対応システムは、ネットワークを介しアプリケーションを互いに連携させる複数の情報処理装置を含むシステムであって、各情報処理装置は、アプリケーション実行時に、他の情報処理装置たる第２の情報処理装置のアプリケーションの呼び出しが発生する度に、情報処理装置間を跨る処理の識別子と情報処理装置間の送受信関係とを含む通信ログを記憶装置に格納する処理と、障害発生時に、エラー内容と前記識別子とを含むアプリログを記憶装置に格納する処理と、障害検知時に、前記アプリログが含む前記識別子をキーとして前記通信ログでの検索を行い、障害発生時に前記識別子に対応した処理で利用された第２の情報処理装置を特定する処理と、前記特定した第２の情報処理装置に対し、当該第２の情報処理装置が保持する、前記識別子に対応付いたアプリログの取得と、当該第２の情報処理装置が前記識別子に対応付いた処理での通信相手とした第３の情報処理装置に向けたモジュールの動作確認と、の少なくとも何れかを要求する処理と、前記要求が前記第２の情報処理装置で実行されて返信された結果として、前記識別子に対応付いたアプリログと、前記第３の情報処理装置におけるモジュールに関する動作確認結果との少なくとも何れかの情報を取得し、当該取得した情報に基づいて、正常動作を行っていない情報処理装置のアプリケーションないしモジュールを障害箇所として特定する処理と、障害箇所に応じて予め定められた対応動作の内容に基づいて、前記特定した障害箇所に応じた対応動作を特定し、該当対応動作を実行する処理と、を実行する演算装置を備えることを特徴とする。

また、本発明の障害対応方法は、ネットワークを介しアプリケーションを互いに連携させる各情報処理装置が、アプリケーション実行時に、他の情報処理装置たる第２の情報処理装置のアプリケーションの呼び出しが発生する度に、情報処理装置間を跨る処理の識別子と情報処理装置間の送受信関係とを含む通信ログを記憶装置に格納する処理と、障害発生時に、エラー内容と前記識別子とを含むアプリログを記憶装置に格納する処理と、障害検知時に、前記アプリログが含む前記識別子をキーとして前記通信ログでの検索を行い、障害発生時に前記識別子に対応した処理で利用された第２の情報処理装置を特定する処理と、前記特定した第２の情報処理装置に対し、当該第２の情報処理装置が保持する、前記識別子に対応付いたアプリログの取得と、当該第２の情報処理装置が前記識別子に対応付いた処理での通信相手とした第３の情報処理装置に向けたモジュールの動作確認と、の少なくとも何れかを要求する処理と、前記要求が前記第２の情報処理装置で実行されて返信された結果として、前記識別子に対応付いたアプリログと、前記第３の情報処理装置におけるモジュールに関する動作確認結果との少なくとも何れかの情報を取得し、当該取得した情報に基づいて、正常動作を行っていない情報処理装置のアプリケーションないしモジュールを障害箇所として特定する処理と、障害箇所に応じて予め定められた対応動作の内容に基づいて、前記特定した障害箇所に応じた対応動作を特定し、該当対応動作を実行する処理と、を実行することを特徴とする。

本発明によれば、ネットワーク上の複数装置間でアプリケーションが連携する環境において、障害発生時に障害発生箇所を効率的に特定して、状況に応じた適宜な障害対応をユーザに促し、障害の影響を効果的に抑制することができる。

本実施形態における障害対応システムの構成例を示す図である。 本実施形態におけるユーザ端末の構成例を示す図である。 本実施形態におけるサーバの構成例を示す図である。 本実施形態における管理サーバの構成例を示す図である。 本実施形態における障害対応方法の処理手順例１を示す図である。 本実施形態における通信ログの出力例を示す図である。 本実施形態におけるアプリログの出力例を示す図である。 本実施形態における障害対応方法の処理手順例２を示す図である。 本実施形態における障害対応方法の処理手順例３を示す図である。 本実施形態における障害対応方法の処理手順例４を示す図である。 本実施形態の障害状況調査結果の例を示す図である。 本実施形態のモジュール確認方法データの例を示す図である。 本実施形態の障害対応方法ＤＢのデータ構成例を示す図である。 本実施形態のユーザプロファイルのデータ構成例を示す図である。

以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態の障害対応システム１の構成例を示す図である。図１に示す障害対応システム１は、ネットワーク上の複数装置間でアプリケーションが連携する環境において、障害発生時に障害発生箇所を効率的に特定して、状況に応じた適宜な障害対応をユーザに促し、障害の影響を効果的に抑制可能とするコンピュータシステムである。

ここでは、ユーザが利用するユーザ端末１０とデータセンタ１００の各サーバ装置らをキャリアネットワーク２０で接続したネットワーク構成を前提とする。また、ユーザ端末１０と上述のサーバ装置の各々に所定のプログラムを配置することで、アプリケーション実行基盤を実現し、このアプリケーション実行基盤上で動作するアプリケーションに障害が発生した時に、適切な障害対策を自動的に実施するのが本実施形態の障害対応システム１となる。

図１に示すネットワーク構成において、ユーザ端末１０は、アプリケーションのユーザが利用する情報処理装置である。このユーザ端末１０は、キャリアネットワーク２０経由で、データセンタ１００に配置したサーバ装置の機能を利用する。本実施形態では、ユーザ端末１０としてカーナビゲーション機能を提供する車載機を想定する。

なお、ユーザ端末１０とデータセンタ１００との間を接続するネットワークとして、図１の例では、携帯電話回線であるキャリアネットワーク２０を想定しているが、勿論、ユーザ端末１０とデータセンタ１００との間の通信プロトコルに応じて適宜なネットワークを採用すればよい。

一方、データセンタ１００には、負荷分散器１１０、Ａ１サーバ１３０、Ａ２サーバ１４０、Ｂサーバ１５０、管理サーバ１２０が配置され、各装置はネットワークで接続さている。こデータセンタ１００におけるネットワークは、ユーザ端末１０と通信できるように上述のキャリアネットワーク２０と接続している。また、これらのデータセンタ１００の各装置１１０〜１５０は、物理サーバ装置または仮想情報処理装置のいずれかである。

こうしたネットワーク構成において、上述のユーザ端末１０に配置したユーザ端末アプリから所定の処理要求を出すと、Ａ１サーバ１３０又はＡ２サーバ１４０、及びＢサーバ１５０に配置したサーバアプリが連携して処理を行い、上述の処理要求に対する応答をユーザ端末１０のユーザ端末アプリに送返信することとなる。

なお、上述の負荷分散器１１０は、ユーザ端末１０で実行するユーザ端末アプリからの処理要求を複数のサーバ１３０、１４０のいずれかに振り分ける機能を持つ。本実施形態では、Ａ１サーバ１３０及びＡ２サーバ１４０は同様のサーバアプリ機能を有することを想定しており、従って、負荷分散器１１０は、ユーザ端末１０で動作するユーザ端末アプリからの処理要求を受けた場合、Ａ１サーバ１３０又はＡ２サーバ１４０に処理を振り分ける。この振り分けの処理は、例えば、ユーザ端末１０から処理要求を受け取る順序に従って交互に振り分け先を切り替えたり、各サーバに所定の処理要求を送信し応答を受け取るまでにかかった時間を計測し、その時間が短い方に振り分けたりする方法を取る。

また、Ｂサーバ１５０のサーバアプリは、Ａ１サーバ１３０又はＡ２サーバ１４０に配置したアプリケーションから利用する機能を有している。例えば、Ａ１サーバ１３０及びＡ２サーバ１４０にはＷｅｂサーバ機能とＷｅｂサーバが受け取った処理要求に応じて所定の処理を実行するアプリの実行機能を配置し、このアプリの実行時に当該アプリが利用するデータをＡ１サーバ１３０とＡ２サーバ１４０で共通化するため、データベース機能をＢサーバ１５０に配置して連携するものとする。

図２にユーザ端末１０の構成例を示す。ユーザ端末１０は情報処理装置であり、ＣＰＵ２０１、メモリ２０２、記憶装置２２０、表示装置２０３、入力装置２０４、位置測位装置２０５、通信装置２０６、加速度センサ２０７、ジャイロセンサ２０８、車両情報取得装置２０９で構成する。記憶装置２２０は、本実施形態の障害対応システム１を構成する情報処理装置としての機能を実装するためのプログラム２２５、２２１や、各データを格納している。また、ＣＰＵ２０１は、記憶装置２２０に保存されたプログラム２２５、２２１やデータを適宜メモリ２０２に読み込んで処理する。

また、表示装置２０３は、上述のプログラム２２５、２２１の実行結果をユーザに示す装置でありディスプレイ装置を想定できる。また、入力装置２０４はユーザからの指示を受け付ける装置であり、キーボードやマウス等の装置を想定できる。

また、位置測位装置２０５は、ユーザ端末１０が存在する位置を測位する装置であり、ＧＰＳユニット等を想定出来る。また、通信装置２０６は、キャリアネットワーク２０を介してデータセンタ１００のサーバ類とデータを送受信する装置である。

また、加速度センサ２０７は、ユーザ端末１０の加速度を測定する装置であり、ジャイロセンサ２０８は、ユーザ端末１０の角速度を測定する装置である。

また、車両情報取得装置２０９は、当該ユーザ端末１０が搭載された車両の制御に用いられる車内ネットワークに接続し、車両状態等に関する車両情報（例：アクセルやブレーキの踏み込み度合いや車両の速度等の情報）を取得するために用いる装置である。

次に、記憶装置２２０に格納するプログラムとデータについて説明する。ユーザ端末アプリ２２１は、ユーザが利用するアプリケーションを実現するプログラムである。また、プログラム２２５は、本実施形態の障害対応システム１を構成する情報処理装置として必要な機能を実装するためのプログラムとなる。

また、ユーザプロファイル２３１は、該当情報処理装置のユーザの属性（例：年齢１４０２、性別１４０３、住所１４０４など）を格納したデータベースである（図１４参照）。

また、通信ログファイル２３２は、プログラムの動作を追跡可能とするために用いる通信ログを保存するファイルであり、アプリログファイル２３３は、プログラム実行中に発生した障害情報を表すアプリログを保存するファイルである。なお、通信ログファイル２３２、アプリログファイル２３３は、ファイルではなくＤＢ等を用いても良い。

また、障害対応方法ＤＢ２３４は、障害の状況に応じた振る舞いを格納するデータベースである。この障害対応方法ＤＢ２３４は、ＤＢではなくファイルを用いても良い。

図３に、Ａ１サーバ１３０、Ａ２サーバ１４０、およびＢサーバ１５０の各サーバ装置の構成例を示す。各サーバは、ＣＰＵ３０１、メモリ３０２、記憶装置３２０、表示装置３０３、入力装置３０４、通信装置３０５を、上述のユーザ端末１０と同様に備えている。また、記憶装置３２０には、サーバアプリ３２１、および、障害対応システム１を構成する情報処理装置として必要な機能を実装するためのプログラム３２５、通信ログファイル３２６、アプリログファイル３２７を格納する。

サーバアプリ３２１は、ユーザ端末アプリ２２１と連携してユーザに機能を提供するプログラムである。ここでは、Ａ１サーバ１３０、Ａ２サーバ１４０には同じサーバアプリ３２１が稼働し、Ｂサーバ１５０には、Ａ１サーバ１３０、Ａ２サーバ１４０とは異なるサーバアプリ３２１が稼働することを想定する。なお、通信ログファイル３２６、アプリログファイル３２７は、図２のユーザ端末１０の記憶装置２２０に格納した同名のプログラム、データと同様の構成、役割を持つ。

図４に管理サーバ１２０の構成例を示す。この管理サーバ１２０においても、ＣＰＵ４０１、メモリ４０２、記憶装置４１０、表示装置４０３、入力装置４０４、通信装置４０５を、ユーザ端末１０等と同様に備えている。このうち、記憶装置４１０には、障害対応システム１を構成する情報処理装置として必要な機能を実装するためのプログラム４２５、統合通信ログＤＢ４１３、および統合アプリログＤＢ４１４を格納する。統合通信ログＤＢ４１３、統合アプリログＤＢ４１４はファイルで実現しても良い。プログラム４２５は、上述のＡ１サーバ１３０、Ａ２サーバ１４０、Ｂサーバ１５０らから送信された通信ログ又はアプリログを受信し、統合通信ログＤＢ４１３又は統合アプリログＤＢ４１４に格納する処理と、統合通信ログＤＢ４１３又は統合アプリログＤＢ４１４から条件に合致するログを検索する処理とを実装するためのプログラムとなる。

続いて、上述したネットワーク構成においてユーザ端末１０のユーザ端末アプリ２２１と、Ａ１サーバ１３０（ないしＡ２サーバ１４０）とが連携し、更には、Ａ１サーバ１３０（ないしＡ２サーバ１４０）とＢサーバ１５０とが連携する処理の流れについて説明する。図５は本実施形態における障害対応方法の処理手順例１を示す図であり、具体的には、アプリの処理の流れを示す図である。

この場合、ユーザ端末１０は、ユーザ端末アプリ２２１における処理（５０１）で、サーバへの通信が必要であるとき、まずトランザクションＩＤ（以降、ＴＩＤとする）を生成する（５０２）。以降、このＴＩＤは情報処理装置に跨った通信時に他の情報処理装置に引き渡すこととし、ユーザ端末１０やＡ１サーバ１３０、Ａ２サーバ１４０、Ｂサーバ１５０らは、通信ログやアプリログ等の出力時に、このＴＩＤを一緒に出力する。

次に、ユーザ端末１０は、通信ログ（要求送信）を出力（５０３）した上で、Ａサーバ処理要求（５０４）をキャリアネットワーク２０に送信する。Ａサーバ処理要求（５０４）は、その宛先に従って負荷分散器１１０に到達することになる。

この時、負荷分散器１１０では、サーバ振り分け先の特定処理（５０５）を実施し、Ａ１サーバ１３０又はＡ２サーバ１４０のどちらへＡサーバ処理要求を送信すべきか決定する。負荷分散器１１０は、決定した送信先（本例ではＡ１サーバ１３０とする）にＡサーバ処理要求を送信する（５０６）。

Ａ１サーバ１３０は、上述のＡサーバ処理要求を受けると、通信ログ（要求受信）を出力（５０７）し、上述のサーバアプリ３２１によるＡサーバアプリ処理（５０８）を実施する。また、Ａ１サーバ１３０は、Ｂサーバ処理要求を出す場合は、通信ログ（要求送信）を出力（５０９）し、Ｂサーバ処理要求をＢサーバ１５０に送信する（５１０）。

Ｂサーバ１５０は、上述のＢサーバ処理要求を受信すると、通信ログ（要求受信）を出力（５１１）する。Ｂサーバ１５０は、自身のサーバアプリによるＢサーバアプリ処理を実施し終えたら、応答を返す前に、通信ログ（応答送信）を出力（５１３）し、要求元たるＡ１サーバ１３０に応答を返す。

この場合、Ａ１サーバ１３０はＢサーバ１５０から応答を受け取って、通信ログ（応答受信）を出力（５１４）し、サーバアプリ３２１によるＡサーバアプリ処理（５１５）を実行する。Ａ１サーバ１３０は、要求元たるユーザ端末１０に応答する際、通信ログ（応答送信）を出力（５１６）して応答を返す。

一方、ユーザ端末１０では、Ａ１サーバ１３０からの応答を受信し、通信ログ（応答受信）を出力（５１７）して、ユーザ端末アプリ２２１によるユーザ端末アプリ処理（５１８）を実行する。こうして、各情報処理装置のアプリケーション間での一連の処理に伴う、通信ログの出力がなされることとなる。なお、図５の例では、ＴＩＤをユーザ端末アプリ２２１による通信の開始時に生成しているが、ユーザ端末アプリ２２１へのユーザの入力が発生するたびに生成するとしても良い。また、ＨＴＴＰでアクセスしたときに動作するサーバアプリ処理は、ＡＰサーバ上で実施することが一般的であり、ＡＰサーバと連携し、ＡＰサーバが要求を受け取ったときに、通信ログ（要求受信）出力を自動的に実施する方法も考えられる。

このような図５に示すシーケンスを実行した結果、出力される通信ログの例を、図６に示す。図６に示す通信ログ６００の例では、ユーザ端末１０にて生成されたＴＩＤが「１２３４５６ａｂｃ」であり、ユーザ端末１０のＩＰアドレスが「１２３．１．１．１０」、負荷分散器１１０のＩＰアドレスが「２１０．１．１．１１０」、Ａ１サーバ１３０のＩＰアドレスが「２１０．１．１．１３０」、Ｂサーバ１５０のＩＰアドレスが「２１０．１．１．１５０」となっている。

また、この通信ログ６００は、Ａ１サーバ１３０又はＡ２サーバ１４０のＡサーバアプリは、ポート番号「８０」で公開し、Ａ１サーバ１３０又はＡ２サーバ１４０のＡサーバアプリへは負荷分散器１１０を通して、「ｈｔｔｐ：／／ａｂｃ．ｃｏｍ／ａｐｐ」のＵＲＬでアクセスできるように構成されていることを示している。また、Ｂサーバ１５０のＢサーバアプリは、ポート番号「８０」で公開し、「ｈｔｔｐ：／／２１０．１．１．１５０／ａｐｐＢ」のＵＲＬでアクセスできるよう構成されている。

この通信ログ６００における項目は、日時６０１、通信種別６０２、ＴＩＤ６０３、クライアントＩＰ６０４、クライアントポート番号６０５、サーバＩＰ６０６、サーバポート番号６０７、プログラム種別６０８、ＵＲＬ６０９である。このうち日時６０１は、ログが出力された日時を表す。また、通信種別６０２は、通信ログの種別を表す情報であり、ＳＮＤ＿ＲＥＱ（要求を送信したことを表す）、ＲＣＶ＿ＲＥＱ（要求を受信したことを表す）、ＳＮＤ＿ＲＥＳ（応答を送信したことを表す）、ＲＣＶ＿ＲＥＳ（応答を受信したことを表す）、といった種類がある。

また、ＴＩＤ６０３は、トランザクションＩＤであり、複数の情報処理装置に跨った一連の処理を一意に特定するために用いるＩＤである。また、クライアントＩＰ６０４は、ＨＴＴＰ通信におけるクライアント側のＩＰアドレスであり、クライアントポート番号６０５は、ＨＴＴＰ通信におけるクライアントのポート番号である。

また、サーバＩＰ６０６は、ＨＴＴＰ通信におけるサーバ側のＩＰアドレスであり、サーバポート番号６０７は、ＨＴＴＰ通信におけるサーバ側のポート番号である。

また、プログラム種別６０８は、ログを出力したプログラムの種別であり、ＵＲＬ６０９は、サーバ側のアプリすなわちサーバアプリ３２１にアクセスするためのＵＲＬである。本実施形態では通信ログ６００の出力例を表形式で記述したが、スペース区切りのテキストファイルで出力した形態であるとしてもよい。

一方、上述のユーザ端末１０やデータセンタ１００のＡ１サーバ１３０、Ａ２サーバ１４０、Ｂサーバ１５０らにおける各アプリの処理で障害が発生した場合、各装置はアプリログに障害の内容を記録することとなる。図７にアプリログ７００の出力例を示す。このアプリログ７００において、日時７０１はログが出力された日時を表し、重要度７０２は、アプリログの重要度を表す。また、重要度７０２には、例えば、ＦＡＴＡＬ（アプリの動作を続行できない障害の発生を表す）、ＥＲＲＯＲ（トランザクション処理を続行できない障害の発生を表す）、ＷＡＲＮＩＮＧ（トランザクション処理は続行できるが、注意を要する事象の発生を表す）、ＩＮＦＯＲＭＡＴＩＯＮ（アプリの内部状態の変化の発生を表す）、ＤＥＢＵＧ（デバッグ用のメッセージの発生を表す）、といった値がある。

また、ＴＩＤ７０３は、トランザクションＩＤであり、複数の情報処理装置に跨った処理の流れを一意に特定するために用いるＩＤである。

また、プログラム種別７０４は、ログを出力したプログラムの種別であり、ＩＰ７０５はログを出力した情報処理装置のＩＰアドレスであり、情報処理装置（ユーザ端末１０やサーバ類）を識別するために用いる。

また、メッセージＩＤ７０６は、発生したエラーを識別するためのＩＤであり、内容７０７は、発生したエラー内容を表す文字列である。

本例ではアプリログ７００の出力例を表形式の形態として記述したが、スペース区切りのテキストファイルで出力する形態も考えられる。

なお、上述の各サーバ、すなわちＡ１サーバ１３０、Ａ２サーバ１４０、Ｂサーバ１５０らは、自身のサーバアプリ３２１が出力したログを検知し、該当ログを管理サーバ１２０に送信するものとする。この場合の処理の流れを図８に例示する。

図８にて示すように、Ａ１サーバ１３０、Ａ２サーバ１４０、Ｂサーバ１５０らは、プログラム３２５を実行することで実装される機能として、サーバアプリ３２１が出力したログを検知し（８０１）、検知したログを管理サーバ１２０に送信する（８０２）。他方、ログ管理サーバ１２０は、Ａ１サーバ１３０、Ａ２サーバ１４０、Ｂサーバ１５０らから受信したログを、記憶装置４２０における統合通信ログＤＢ４１３または統合アプリログＤＢ４１４に保存する（８０３）。

なお、Ａ１サーバ１３０、Ａ２サーバ１４０、Ｂ１５０で出力されたログを、ログ管理サーバ１２０で一括管理することと同様に、ユーザ端末１０で発生したログも管理サーバ１２０に送信し、管理サーバ１２０にて収集するとしてもよい。

続いて、上述のネットワーク構成において、いずれかの情報処理装置にて障害が発生した際の処理について説明する。図９は、本実施形態における障害対応方法の処理手順例３を示す図である。

ここではまず、ユーザ端末１０がユーザ端末アプリ２２１の障害を検知（９０１）する。この障害検知の手法としては、例えば、ユーザ端末１０が、プログラム２２５を実行して得られる所定機能により（以下、各処理について同様）、ユーザ端末アプリ２２１に関して収集しているアプリログファイル２３３を監視し、アプリログファイル２３３が含む重要度７０２の値が「ＥＲＲＯＲ」又は「ＦＡＴＡＬ」のときに障害であると検知する、といった手法が採用できる。

次に、ユーザ端末１０は、重要度７０２の値が「ＥＲＲＯＲ」又は「ＦＡＴＡＬ」である上記アプリログ２３３におけるＴＩＤ７０３の値を読み出し、このＴＩＤ７１３の値が対応付いている通信ログを、通信ログファイル２３２から読み出し、該当通信ログから、障害発生時の通信相手を特定する（９０２）。図７の例であれば、例えば、重要度７０２の値が「ＥＲＲＯＲ」であるアプリログにおけるＴＩＤ７０３の値「２３４５６７ｂｃｄ」を読み出し、このＴＩＤ７１３の値「２３４５６７ｂｃｄ」が対応付いている通信ログを、通信ログファイル２３２から読み出る。そしてここで出力した各通信ログのクライアントＩＰ６０４，サーバＩＰ６０６の各値から、障害発生時のユーザ端末１０（ＩＰアドレスが、“１２３．１．１．１０”）の通信相手たるサーバを、例えば、負荷分散器１１０（ＩＰアドレスが、“１２３．１．１．１１０”）などと特定できる。

次に、ユーザ端末１０は、モジュール確認の処理（９０３）を実施する。この処理は、通信相手の情報処理装置、この場合はすなわち負荷分散器１１０で稼働するモジュールの動作をチェックする処理である。当該処理の詳細については後述する。

続いて、ユーザ端末１０は、障害状況調査要求を通信相手の負荷分散器１１０に送信する（９０４）。一方、負荷分散器１１０は、ユーザ端末１０から処理を受けると、上述したようなサーバ振り分け先の特定処理を実施し、振り分け先とした通信先（ここではＡ２サーバ１４０とする）に対し、ユーザ端末１０から受けた上述の障害状況調査要求を送信する（９０６）。

続いて、Ａ２サーバ１４０では、上述の障害状況調査要求を負荷分散器１１０から受信し、上述したステップ９０２〜９０４と同様に、障害状況調査要求が含む上述のＴＩＤ「２３４５６７ｂｃｄ」の値が対応付いている通信ログを、通信ログファイル３２６から読み出し、該当通信ログから、障害発生時の通信相手（ここではＢサーバ１５０とする）を特定する処理（９０７）、Ａ２サーバ１４０の通信相手たるＢサーバ１５０におけるモジュール確認の処理（９０８）、障害状況調査要求を通信相手のＢサーバ１５０に送信する処理（９０９）を実施する。

一方、Ａ２サーバ１４０から上述の障害状況調査要求を受けたＢサーバ１５０は、上述のステップ９０２やステップ９０７と同様に通信相手の特定（９１０）を行うが、図９に示すシーケンスの例では、更なる通信先が存在しないため、ステップ９０８、９０９に相当する処理は実施しない。

他方、Ｂサーバ１５０は、障害があったときのアプリログを上述のＴＩＤ「２３４５６７ｂｃｄ」をキーに自身のアプリログファイル３２７から取得し（９１１）、これを障害状況調査要求の送り元であるＡ２サーバ１４０に返す。

一方、Ａ２サーバ１４０でもＢサーバ１５０同様に、上述のＴＩＤ「２３４５６７ｂｃｄ」をキーに自身のアプリログファイル３２７からアプリログの取得を実施し（９１２）、障害状況調査要求を受けた上述のユーザ端末１０に返す。また、このユーザ端末１０でもアプリログの取得処理を実施する（９１３）。

以上のように障害状況の調査処理は、障害が発生したトランザクションに参加した情報処理装置（ユーザ端末１０、負荷分散器１１０、Ａ２サーバ１４０、Ｂサーバ１５０）に跨って実施され、モジュールの動作確認の結果やアプリログの情報がユーザ端末１０に収集される。

続いて、ユーザ端末１０は、こうして収集した情報と、ユーザプロファイル２３１やユーザ端末１０が搭載された車両状態等の情報を組み合わせて、障害への対応動作を特定する（９１４）。この対応動作の特定処理の詳細については後述する。最後に、ユーザ端末１０は、ステップ９１４で特定した障害への対応動作を実行する（９１５）。この対応動作についても詳細は後述する。

次に、上述した障害状況調査要求に応じて情報処理装置にて実行される障害状況調査のフローについて説明する。図１０は本実施形態における障害対応方法の処理手順例４を示す図である。このフローは、ユーザ端末１０、Ａ１サーバ１３０、Ａ２サーバ１４０、およびＢ１５０で実施する処理となる。なお、本フローは、障害が発生したトランザクションのＴＩＤが分かっていることを前提としている。

また、障害状況調査とは、図９のシーケンスで例示した通信相手の特定（９０２、９０７、９１０）、モジュールの動作確認（９０３、９０８）、障害状況調査要求（９０４、９０９）、およびアプリログ取得（９１１、９１２、９１３）の各処理を含んでいる。当該フローチャートの左側に各々の処理に対応する箇所を示している。

この場合まず、障害状況調査要求を受けた情報処理装置は、自情報処理装置の記憶装置にて、上述のＴＩＤ（障害が発生したトランザクションのもの）が対応付いた通信ログが存在することを確認する（１００１）。この処理により、上述のＴＩＤが対応付いた通信ログを特定できなければ（１００１：Ｎ）、情報処理装置は、管理サーバ１２０に対し、上述のＴＩＤとＵＲＬが対応付いたログが存在することを確認する（１００２）。なお、ユーザ端末１０でステップ１００２を実行する場合、ステップ１００２の結果は常に「Ｎ」、すなわち対応するログは無い結果となる。

ステップ１００２の結果、上述のＴＩＤとＵＲＬが対応付いたログが管理サーバ１２０にて特定できた場合（１００２：Ｙ）、情報処理装置は、管理サーバ１２０にて特定できたログが示す通信相手の情報処理装置は冗長構成が取られていると特定し、障害状況調査結果１１００（図１１）の冗長構成１１０４の値として「あり」と記録する（１００３）。

また、情報処理装置は、通信種別６０２の値が「ＳＮＤ＿ＲＥＱ」である全通信ログのサーバＩＰ６０６の値を、通信相手のＩＰとして取得する（１００４）。他方、上述のステップ１００２の結果、上述のＴＩＤとＵＲＬが対応付いたログが管理サーバ１２０にて特定できなかった場合（１００２：Ｎ）、情報処理装置は、障害状況調査結果１１００の障害箇所１１０３の値として「通信」と記録する（１００５）。

続いて、情報処理装置は、上述のステップ１００４で得ている全ての通信相手のＩＰごとに、通信相手のモジュールを特定する（１００７）。この通信相手のモジュールの特定処理は、例えば、図１２に示すモジュール確認方法ＤＢ１２００を用いて実施する。この場合、情報処理装置は、ステップ１００４で得ている通信相手のＩＰが、モジュール確認方法ＤＢ１２００において処理装置ＩＰ１２０１の値が一致するエントリを取得する。なお、このモジュール確認方法ＤＢ１２００におけるモジュール１２０２の値は、モジュールの名称であり、確認順序１２０３の値は、モジュール間で動作確認を行う順序であり、確認方法１２０４の値は、モジュールの動作確認を行う際の方法を示している。

例えば、図１２の例のうち、処理装置ＩＰが「２１０．１．１．１５０」の情報処理装置、すなわちＢサーバ１５０は、「ＯＳ」と「ＤＢサーバ」がモジュールとして稼働しており、「ＯＳ」、「ＤＢサーバ」の順で動作確認すべきであることを示している。また、この場合の「ＯＳ」の動作確認は、ｐｉｎｇコマンドのｒｅｐｌｙ有無で実施し、「ＤＢサーバ」の動作確認は、ＤＢへの接続成功か否かにより実施することが示されている。

なお、図１２のモジュール確認方法ＤＢ１２００の例では、分かり易さのために確認方法１２０４の値を文章で記述しているが、プログラム等の情報処理装置で実行可能な形式で格納するとしてもよい。また、処理装置ＩＰ１２０１毎にモジュールを管理しているが、アプリにアクセスするときに用いる識別子であるＵＲＬ毎に管理するとしてもよい。

情報処理装置は、上述のステップ１００７を実行後、各モジュールの確認順序１２０３の値と確認方法１２０４の値に従って、通信相手のモジュールに関するチェック（動作確認）を実行する（１００９）。このチェックの結果、該当モジュールが正常であれば（１０１０：Ｙ）、情報処理装置は処理をステップ１００８に戻し、次のモジュールの動作確認を実施する。情報処理装置は、こうしたモジュールの動作確認の処理を、モジュール数分繰り返し、終了したかどうかを確認する（１００８）。

なお、本実施形態では、モジュールのチェック（１００９）の処理を、通信元の情報処理装置から通信相手の情報処理装置に対して実施するように構成したが、自情報処理装置で稼働するモジュールを自情報処理装置内に閉じてチェックするとしてもよい。つまり、障害状況調査要求を受けたら、自情報処理装置で稼働するモジュールを特定し、その動作確認を行うのである。

説明をステップ１００８に戻す。モジュール数分の動作確認が終了していなければ（１００８：Ｎ）、情報処理装置は、ステップ１００９、１０１０を実行する。他方、モジュール数分の動作確認が終了していれば（１００８：Ｙ）、情報処理装置は、処理をステップ１００６に戻し、上述のステップ１００７〜ステップ１０１０の処理を、ステップ１００４で取得した通信相手数分だけ繰り返し実行する。

他方、上述のステップ１００７〜ステップ１０１０の処理を、ステップ１００４で取得した通信相手数分だけ実行済みとなれば（１００６：Ｙ）、情報処理装置は、処理をステップ１０１３に進める。

なお、上述のステップ１０１０の処理の結果、該当モジュールが正常ではなかった場合（１０１０：Ｎ）、情報処理装置は、障害状況調査結果１１００の障害箇所１１０３の値として、正常ではなかったモジュールの名称を記録し（１０１１）、ステップ１００４で得ている通信相手のうち処理の済んでいない通信相手に、障害状況調査要求を送信する（１０１２）。このとき情報処理装置は、上述のステップ１００１又はステップ１００２で特定した通信ログの情報を相手先に送信する。

次に、ステップ１０１３において情報処理装置は、上述のＴＩＤ（障害が発生したトランザクションのＴＩＤ）が対応付いたアプリログを、自身の記憶装置にて取得する。該当情報処理装置がユーザ端末１０であれば、自身の記憶装置に格納されたアプリログファイル２３３中からログを取得し、サーバ（Ａ１サーバ１３０、Ａ２サーバ１４０、Ｂサーバ１５０）であれば管理サーバ１２０に要求し、管理サーバ１２０の統合アプリログＤＢ４１から取得する。

次に、情報処理装置は、障害状況調査結果１１００の処理装置ＩＰ１１０１の値として、自情報処理装置のＩＰを記録し（１０１４）、障害状況調査結果１１００を、障害状況調査要求の送り元に返して（１０１５）、処理を終了する。

なお、以上の処理（１００１〜１０１５）を情報処理装置が実施した結果、図１１に示す障害状況調査結果１１００を生成し、これを障害状況調査要求の送り元に返すことになる。この障害状況調査結果１１００は、障害の発生したトランザクション内で利用された情報処理装置毎に、処理装置ＩＰ１１０１、該当処理装置で発生したアプリログ１１０２、障害箇所１１０３、および冗長構成１１０４の各値から構成されている。各値の設定手法については上述した通りである。なお、本実施形態では、この障害状況調査結果１１００を表形式にて表現しているが、ＸＭＬやＪＳＯＮ等の構造化データとして記載するとしてもよい。

また、上述の例では、ネットワーク上の情報処理装置の冗長構成有無を、障害が発生したときに呼び出された情報処理装置と、障害状況調査時に呼び出された情報処理装置が異なることをもって判断した例を示しているが、予め代表ＩＰアドレス（負荷分散器１１０のＩＰアドレス）又はＵＲＬと冗長構成有無のテーブルを用意し、クライアントのアクセス先のＵＲＬから、冗長構成の有無を判定する方法も採用できる。

続いて、障害対応方法ＤＢ２３４について説明する。図１３は本実施形態の障害対応方法ＤＢ２３４のデータ構成例を示す図である。ここで例示する障害対応方法ＤＢ２３４は、アプリログ１３０１、障害箇所（観測箇所）１３０２、冗長構成１３０３、ユーザプロファイル１３０４、車両状態１３０５、アプリ性質１３０６、および対応方法１３０７の各値から構成されている。

このうちアプリ性質１３０６は、アプリ（ユーザ端末アプリ２２１、サーバアプリ３２１）を公開するＵＲＬ毎に管理する属性であり、ユーザ操作（ユーザが操作したことをトリガーとして呼び出されるアプリであることを示す。例：飲食店の検索アプリ）、バックグラウンド（ユーザの操作がなくてもバックグラウンドで呼び出されるアプリであることを示す。例：カーナビゲーション装置の地図上に表示する渋滞情報を取得するアプリ）といった種類があることを想定する。なお、ＤＢ中の「−」は何れであっても良いことを表す。また、図１３の例では、対応方法を文章で表現したが、ユーザ端末１０等の情報処理装置で実行できるプログラムで記述することができる。

このような障害対応方法ＤＢ２３４を利用する情報処理装置は、図１０のフローにより得られた障害状況調査結果１１００が含む、処理装置ＩＰ１１０１、アプリログ１１０２、障害箇所１１０３、冗長構成１１０４と、自身の記憶装置にて保持するユーザプロファイル２３１、当該情報処理装置が搭載された車両の制御に用いられる車内ネットワークに接続して得た車両状態の情報、通信ログに記録したＵＲＬで公開されているアプリの性質１３０６とを、上述の障害対応方法ＤＢ２３４（に格納した条件である、アプリログ１３０１、障害箇所（観測箇所）１３０２、冗長構成１３０３、ユーザプロファイル１３０４、車両状態１３０５、アプリ性質１３０６の各値）に照合し、各値がマッチする対応方法１３０７の値を取得することとなる。また、情報処理装置は、取得した対応方法１３０７の値に対応した動作を実行する。

例えば、図１３の障害対応方法ＤＢ２３４における各行のうち、「＃１」と「＃２」のエントリは、アプリログ１３０１に「ユーザ端末が通信不可に設定されており通信できない」内容のログが出力されており、アプリ性質１３０６が「ユーザ操作」であった場合の対応動作を規定したものである。この場合は、情報処理装置は、ユーザプロファイル１３０４の年齢１４０２の値を参照し、該当ユーザの年齢が「６０以上」であれば、該当ユーザに対しサポートセンタの電話番号を含むメッセージを表示装置２０３にて表示し、一方、年齢が「６０未満」であればユーザに対しサポートセンタの電話番号を含まないメッセージを表示装置２０３にて表示することになる。こうした制御を行うことにより、サポートセンタへの問い合わせ数を制御することができる。

また、「＃３」のエントリは、障害箇所１３０２がサーバの通信であった場合に対応したものとなる。サーバに関して、障害箇所１３０２の値が「通信」になる場合は、障害状況調査時には通信が通ったことを示す。つまり、障害時には不通であったが、障害状況調査時には、疎通したことが予想できる。そのため、この場合の情報処理装置は、ユーザ端末からの要求を再送する対応方法１３０７を実行することになる。

また、「＃４」のエントリは、障害箇所１３０２が「ＯＳ」であり、障害箇所（観測箇所）は「ユーザ端末」であり、アプリ性質１３０６が「ユーザ操作」であった場合に対応したものとなる。こうした状況は、キャリアネットワーク２０の電波状況が悪いことが考えられる。そのため、この場合の情報処理装置は、ユーザに対し、電波状況を確認することを示すメッセージを表示装置２０３にて示す対応方法１３０７を実行することになる。

また、「＃５」、「＃６」のエントリは、モジュールの動作確認処理において、「Ｗｅｂサーバ／ＡＰサーバ／ＤＢサーバ」の何れかが不正であり、かつ冗長構成が「ない」場合に対応したものとなる。Ｗｅｂサーバ／ＡＰサーバ／ＤＢサーバのミドルウェアにおける障害は、再起動により復旧する可能性がある。そのため、この場合の情報処理装置は、アプリ性質１３０６が「ユーザ操作」であった場合、ユーザに対し、５分以上（再起動に要するであろう時間）経ってから該当処理を再実行することを表示装置２０３にて示し、他方、アプリ性質１３０６が「バックグラウンド」であった場合、５分経過後に自動的に該当処理を再実行する対応方法１３０７を実行する。

また、「＃７」のエントリは、障害箇所１３０２が存在しない（つまりチェックしたモジュールは正常であった）場合に対応したものとなる。このとき、冗長構成が取られていれば、次回は正常なサーバに処理を割り振られる可能性がある。そのため、情報処理装置は、自動的に要求を再送するとの対応方法１３０７を実行する。

また、「＃８」のエントリは、障害箇所１３０２が存在せず、冗長構成が「ない」場合に対応したものとなる。この時、モジュールは正常であることから、アプリケーションに障害が発生したことが考えられ、この場合、障害復旧には時間がかかることが考えられる。そのため、アプリ性質１３０６が「ユーザ操作」であれば、情報処理装置は、ユーザに対し、しばらく要求しないように該当メッセージを表示装置２０３にて示し、ユーザが操作しても３０分間は同ＵＲＬに要求を送信しないように抑止する。一方、アプリ性質１３０６が「バックグラウンド」であれば、情報処理装置は、３０経過後要求を再送する。

また、「＃１０」、「＃１１」のエントリは、アプリログ１３０１があり、車両状態１３０５が「運転中」かどうかにより、アプリログの内容を表示するか否かを決定するものとなる。また、「＃１２」のエントリは、アプリログがなく、かつ、他にマッチする条件が障害対応方法ＤＢ２３４内に存在しない場合に対応したものとなる。この場合は、原因不明のエラーであるため、情報処理装置は、ユーザに対し、サポートセンタに問い合わせを行うようにメッセージを表示装置２０３にて表示する対応方法１３０７を実行する。

以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。

こうした本実施形態によれば、ネットワーク上の複数装置間でアプリケーションが連携する環境において、障害発生時に障害発生箇所を効率的に特定して、状況に応じた適宜な障害対応をユーザに促し、障害の影響を効果的に抑制可能となる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち本実施形態の障害対応システムにおける情報処理装置の演算装置は、当該情報処理装置が保持する、前記識別子に対応付いたアプリログの取得と、前記特定した第２の情報処理装置に向けたモジュールの動作確認と、の少なくとも何れかを実行し、前記障害箇所を特定する処理において、前記第２の情報処理装置から得た、前記識別子に対応付いたアプリログおよび、前記第３の情報処理装置におけるモジュールに関する動作確認結果の少なくとも何れかの情報と、当該情報処理装置自身で得た、前記識別子に対応付いたアプリログおよび、前記第２の情報処理装置におけるモジュールの動作確認結果との少なくともいずれかの情報と、に基づいて、正常動作を行っていない情報処理装置のアプリケーションないしモジュールを障害箇所として特定するものである、としてもよい。

これによれば、障害発生を感知した情報処理装置における障害箇所についても特定可能であり、より効率的かつ的確な障害対応が可能となる。

また、上述の障害対応システムにおける前記第２の情報処理装置の演算装置は、前記要求を受けた際に、前記識別子に対応した処理で通信相手であった第３の情報処理装置を自身の通信ログで特定し、前記特定した第３の情報処理装置に対し、当該第３の情報処理装置が保持する、前記識別子に対応付いたアプリログの取得と、当該第３の情報処理装置が前記識別子に対応付いた処理での通信相手とした第４の情報処理装置に向けたモジュールの動作確認と、の少なくとも何れかの要求を更に行うものである、としてもよい。

これによれば、ネットワーク上でトランザクションＩＤなどの識別子を介して一連の処理を実行する情報処理装置の範囲をより幅広く把握することにつながり、ひいては、障害箇所特定の精度をより向上させ、更に的確な障害対応が可能となる。

また、上述の障害対応システムにおける前記情報処理装置の演算装置は、前記障害箇所を特定する処理において、前記識別子をキーとして送受信関係で連なった、少なくとも前記第２から前記第４の各情報処理装置間で前記要求に応じた処理が実行されて返信された結果として、前記連なった前記第２から前記第４の各情報処理装置らで出力した、前記識別子に対応付いたアプリログと、通信相手の情報処理装置におけるモジュールに関する動作確認結果との少なくとも何れかの情報を取得し、当該取得した情報と、当該情報処理装置自身で得た、前記識別子に対応付いたアプリログおよび、前記第２の情報処理装置におけるモジュールの動作確認結果との少なくともいずれかの情報とに基づいて、正常動作を行っていない情報処理装置のアプリケーションないしモジュールを障害箇所として特定するものである、としてもよい。

これによれば、ネットワーク上でトランザクションＩＤなどの識別子を介して一連の処理を実行する情報処理装置の範囲をより幅広く把握し、障害箇所特定の精度をより向上させ、更に的確な障害対応が可能となる。

また、上述の障害対応システムにおける各情報処理装置は、記憶装置において、少なくとも通信相手となりうる情報処理装置ないしアプリケーション毎に、該当情報処理装置に含まれる又はアプリケーションが利用している各モジュールの識別子と、各モジュールに関する前記動作確認の内容と、モジュール間での前記動作確認の実行順序とを規定した、モジュール確認方法データベースを格納しており、前記第２の情報処理装置の演算装置は、前記要求を受けた際に、当該要求が前記モジュールの動作確認を含むものであった場合、前記識別子をキーとして自身の通信ログでの検索を行い、前記識別子に対応した処理で通信相手であった前記第３の情報処理装置を特定し、前記特定した前記第３の情報処理装置の各モジュールについて、該当モジュールの動作確認の内容と各モジュール間での動作確認の実行順序とを前記モジュール確認方法データベースにて特定し、前記各モジュールに対する前記動作確認を前記実行順序に従って実行し、当該実行結果である、前記各モジュールに関する動作確認結果を前記要求の送信元である前記情報処理装置に宛てて返信する処理を実行するものである、としてもよい。

これによれば、情報処理装置に備わる複数のモジュールそれぞれについて、好適な実行順序の下、的確な動作確認を効率的に行うことが可能となり、障害箇所特定の効率と精度をより向上させ、更に的確な障害対応が可能となる。

また、上述の障害対応システムにおける前記情報処理装置は、障害検知時に、前記アプリログが含む前記識別子をキーとして、当該情報処理装置および前記第２の情報処理装置の各通信ログでの検索を行い、いずれの情報処理装置でも前記識別子が対応付いた通信ログが存在しなかった場合、前記第２の情報処理装置についてはネットワークにおいて冗長構成が取られていると特定する処理を実行し、前記対応動作の特定を行う処理において、障害箇所における冗長構成有無に応じて予め定められた対応動作の内容に基づいて、前記特定した障害箇所とその冗長構成有無に応じた対応動作を特定し、該当対応動作を実行するものである、としてもよい。

これによれば、ネットワーク上で広く存在する冗長構成について、これを対応動作の特定基準に含めることで、更に的確な障害対応が可能となる。

また、上述の記載の障害対応システムにおける前記情報処理装置は、前記記憶装置において、当該情報処理装置のユーザの属性情報を格納したユーザプロファイルと、ネットワーク上の障害箇所、当該情報処理装置のユーザの属性、および当該情報処理装置を備えた所定装置の状態、の少なくともいずれか又はそれらを組み合わせた条件と、該当条件時における対応動作とを対応付けた障害対応方法データベースとを格納しており、前記演算装置は、対応動作の特定を行う処理において、前記特定した障害箇所、前記ユーザプロファイルから得た当該情報処理装置のユーザの属性、および前記所定装置から所定のインターフェイスを介して取得した前記所定装置の状態、の少なくともいずれか又はそれらを組み合わせた情報を、前記障害対応方法データベースの前記条件に照合して対応動作を特定し、該当対応動作を実行するものである、としてもよい。

これによれば、障害発生時の様々な条件、すなわち障害箇所や、冗長構成の有無や、ユーザプロファイルや、ユーザの利用状況等に応じて、障害対応時のシステムの振る舞いを切り替えることが可能となり、障害発生時にユーザが取るべき行動を、よりきめ細やかにかつ適切に案内することができる。そのためユーザ満足度を向上できる。しかも、障害発生時にユーザが迷わず対策できれば、アプリケーション開発ベンダやシステムベンダが用意するサポートセンタへの問い合わせ数、頻度を低減できる効果もある。

また、上述の障害対応システムにおける前記情報処理装置は、ネットワーク上におけるユーザ端末であり、前記第２および第３の情報処理装置は、ネットワーク上におけるサーバ装置であるとしてもよい。これによれば、ユーザ端末のアプリケーションとサーバ装置のアプリケーションとの間の連携環境に関して障害箇所を特定し、的確かつ効率的な障害対応が可能となる。

１ 障害対応システム
１０ ユーザ端末（情報処理装置）
２０ キャリアネットワーク（ネットワーク）
１００ データセンタ
１１０ 負荷分散器
１２０ 管理サーバ
１３０ Ａ１サーバ（第２の情報処理装置）
１４０ Ａ２サーバ（第２の情報処理装置）
１５０ Ｂサーバ（第３の情報処理装置）
２０１、３０１、４０１ ＣＰＵ（演算装置）
２０２、３０２、４０２ メモリ
２０３、３０３、４０３ 表示装置
２０４、３０４、４０４ 入力装置
２０５ 位置測位装置
２０６、３０５、４０５ 通信装置
２０７ 加速度センサ
２０８ ジャイロセンサ
２０９ 車両情報取得装置
２２０、３２０、４２０ 記憶装置
２２５、３２５、４２５ プログラム
２３１ ユーザプロファイル
２３４ 障害対応方法ＤＢ
２３２、３２６ 通信ログファイル
２３３、３２７ アプリログファイル
４１３ 統合通信ログＤＢ
４１４ 統合アプリログＤＢ

Claims (9)

1. ネットワークを介しアプリケーションを互いに連携させる複数の情報処理装置を含むシステムであって、
   各情報処理装置は、
   アプリケーション実行時に、他の情報処理装置たる第２の情報処理装置のアプリケーションの呼び出しが発生する度に、情報処理装置間を跨る処理の識別子と情報処理装置間の送受信関係とを含む通信ログを記憶装置に格納する処理と、
   障害発生時に、エラー内容と前記識別子とを含むアプリログを記憶装置に格納する処理と、
   障害検知時に、前記アプリログが含む前記識別子をキーとして前記通信ログでの検索を行い、障害発生時に前記識別子に対応した処理で利用された第２の情報処理装置を特定する処理と、
   前記特定した第２の情報処理装置に対し、当該第２の情報処理装置が保持する、前記識別子に対応付いたアプリログの取得と、当該第２の情報処理装置が前記識別子に対応付いた処理での通信相手とした第３の情報処理装置に向けたモジュールの動作確認と、の少なくとも何れかを要求する処理と、
   前記要求が前記第２の情報処理装置で実行されて返信された結果として、前記識別子に対応付いたアプリログと、前記第３の情報処理装置におけるモジュールに関する動作確認結果との少なくとも何れかの情報を取得し、当該取得した情報に基づいて、正常動作を行っていない情報処理装置のアプリケーションないしモジュールを障害箇所として特定する処理と、
   障害箇所に応じて予め定められた対応動作の内容に基づいて、前記特定した障害箇所に応じた対応動作を特定し、該当対応動作を実行する処理と、
   を実行する演算装置を備えることを特徴とする障害対応システム。
2. 前記情報処理装置の演算装置は、
   当該情報処理装置が保持する、前記識別子に対応付いたアプリログの取得と、前記特定した第２の情報処理装置に向けたモジュールの動作確認と、の少なくとも何れかを実行し、
   前記障害箇所を特定する処理において、
   前記第２の情報処理装置から得た、前記識別子に対応付いたアプリログおよび、前記第３の情報処理装置におけるモジュールに関する動作確認結果の少なくとも何れかの情報と、当該情報処理装置自身で得た、前記識別子に対応付いたアプリログおよび、前記第２の情報処理装置におけるモジュールの動作確認結果との少なくともいずれかの情報と、に基づいて、正常動作を行っていない情報処理装置のアプリケーションないしモジュールを障害箇所として特定するものである、
   ことを特徴とする請求項１に記載の障害対応システム。
3. 前記第２の情報処理装置の演算装置は、
   前記要求を受けた際に、前記識別子に対応した処理で通信相手であった第３の情報処理装置を自身の通信ログで特定し、前記特定した第３の情報処理装置に対し、当該第３の情報処理装置が保持する、前記識別子に対応付いたアプリログの取得と、当該第３の情報処理装置が前記識別子に対応付いた処理での通信相手とした第４の情報処理装置に向けたモジュールの動作確認と、の少なくとも何れかの要求を更に行うものである、
   ことを特徴とする請求項２に記載の障害対応システム。
4. 前記情報処理装置の演算装置は、
   前記障害箇所を特定する処理において、
   前記識別子をキーとして送受信関係で連なった、少なくとも前記第２から前記第４の各情報処理装置間で前記要求に応じた処理が実行されて返信された結果として、前記連なった前記第２から前記第４の各情報処理装置らで出力した、前記識別子に対応付いたアプリログと、通信相手の情報処理装置におけるモジュールに関する動作確認結果との少なくとも何れかの情報を取得し、当該取得した情報と、当該情報処理装置自身で得た、前記識別子に対応付いたアプリログおよび、前記第２の情報処理装置におけるモジュールの動作確認結果との少なくともいずれかの情報とに基づいて、正常動作を行っていない情報処理装置のアプリケーションないしモジュールを障害箇所として特定するものである、
   ことを特徴とする請求項３に記載の障害対応システム。
5. 各情報処理装置は、
   記憶装置において、少なくとも通信相手となりうる情報処理装置ないしアプリケーション毎に、該当情報処理装置に含まれる又はアプリケーションが利用している各モジュールの識別子と、各モジュールに関する前記動作確認の内容と、モジュール間での前記動作確認の実行順序とを規定した、モジュール確認方法データベースを格納しており、
   前記第２の情報処理装置の演算装置は、前記要求を受けた際に、当該要求が前記モジュールの動作確認を含むものであった場合、前記識別子をキーとして自身の通信ログでの検索を行い、前記識別子に対応した処理で通信相手であった前記第３の情報処理装置を特定し、前記特定した前記第３の情報処理装置の各モジュールについて、該当モジュールの動作確認の内容と各モジュール間での動作確認の実行順序とを前記モジュール確認方法データベースにて特定し、前記各モジュールに対する前記動作確認を前記実行順序に従って実行し、当該実行結果である、前記各モジュールに関する動作確認結果を前記要求の送信元である前記情報処理装置に宛てて返信する処理を実行するものである、
   ことを特徴とする請求項１に記載の障害対応システム。
6. 前記情報処理装置は、
   障害検知時に、前記アプリログが含む前記識別子をキーとして、当該情報処理装置および前記第２の情報処理装置の各通信ログでの検索を行い、いずれの情報処理装置でも前記識別子が対応付いた通信ログが存在しなかった場合、前記第２の情報処理装置についてはネットワークにおいて冗長構成が取られていると特定する処理を実行し、
   前記対応動作の特定を行う処理において、障害箇所における冗長構成有無に応じて予め定められた対応動作の内容に基づいて、前記特定した障害箇所とその冗長構成有無に応じた対応動作を特定し、該当対応動作を実行するものである、
   ことを特徴とする請求項１に記載の障害対応システム。
7. 前記情報処理装置は、
   前記記憶装置において、
   当該情報処理装置のユーザの属性情報を格納したユーザプロファイルと、
   ネットワーク上の障害箇所、当該情報処理装置のユーザの属性、および当該情報処理装置を備えた所定装置の状態、の少なくともいずれか又はそれらを組み合わせた条件と、該当条件時における対応動作とを対応付けた障害対応方法データベースとを格納しており、
   前記演算装置は、対応動作の特定を行う処理において、
   前記特定した障害箇所、前記ユーザプロファイルから得た当該情報処理装置のユーザの属性、および前記所定装置から所定のインターフェイスを介して取得した前記所定装置の状態、の少なくともいずれか又はそれらを組み合わせた情報を、前記障害対応方法データベースの前記条件に照合して対応動作を特定し、該当対応動作を実行するものである、
   ことを特徴とする請求項１に記載の障害対応システム。
8. 前記情報処理装置は、ネットワーク上におけるユーザ端末であり、前記第２および第３の情報処理装置は、ネットワーク上におけるサーバ装置であることを特徴とする請求項１に記載の障害対応システム。
9. ネットワークを介しアプリケーションを互いに連携させる各情報処理装置が、
   アプリケーション実行時に、他の情報処理装置たる第２の情報処理装置のアプリケーションの呼び出しが発生する度に、情報処理装置間を跨る処理の識別子と情報処理装置間の送受信関係とを含む通信ログを記憶装置に格納する処理と、
   障害発生時に、エラー内容と前記識別子とを含むアプリログを記憶装置に格納する処理と、
   障害検知時に、前記アプリログが含む前記識別子をキーとして前記通信ログでの検索を行い、障害発生時に前記識別子に対応した処理で利用された第２の情報処理装置を特定する処理と、
   前記特定した第２の情報処理装置に対し、当該第２の情報処理装置が保持する、前記識別子に対応付いたアプリログの取得と、当該第２の情報処理装置が前記識別子に対応付いた処理での通信相手とした第３の情報処理装置に向けたモジュールの動作確認と、の少なくとも何れかを要求する処理と、
   前記要求が前記第２の情報処理装置で実行されて返信された結果として、前記識別子に対応付いたアプリログと、前記第３の情報処理装置におけるモジュールに関する動作確認結果との少なくとも何れかの情報を取得し、当該取得した情報に基づいて、正常動作を行っていない情報処理装置のアプリケーションないしモジュールを障害箇所として特定する処理と、
   障害箇所に応じて予め定められた対応動作の内容に基づいて、前記特定した障害箇所に応じた対応動作を特定し、該当対応動作を実行する処理と、
   を実行することを特徴とする障害対応方法。

Images