JP7423942B2 - 情報処理システム - Google Patents

Description

本発明は、情報処理システムに関する。

従来、対象システムにおいて発生したインシデントに応じて、該当または類似するインシデントを特定し、かかるインシデントに対する対応を支援するシステムが提案されている。

特許文献１には、対象システムで発生したインシデントの情報をもとに、データベースに格納されている情報を自動的に検索し、該当する既知のインシデントの対応手順等を含む情報を取得し、取得した情報を、発生したインシデントに適用するための情報として出力し、対応者の端末へ表示または通知等する処理を行うことが開示されている。

特許文献２には、ユーザコンピュータシステムから受信したインシデントに含まれるエラーメッセージに紐付けされたテンプレートＩＤを抽出し、このテンプレートＩＤから運用テンプレートの実行に必要な引数情報を抽出し、この引数情報を基に構成管理データベースから運用テンプレートの引数を抽出して運用プロセスを実行することが開示されている。

特許文献３には、情報処理システムにおいて発生したインシデントごとに動作状態情報を保持するデータ保持部を参照し、複数のインシデントの中から選択された選択インシデントに類似する類似インシデントを特定することが開示されている。

特開２０１１－７６１６１号公報 特開２０１３－８１７８号公報 特開２０１８－８１４０３号公報

監視対象システムで発生した障害に対して運用者が対応する場合、運用者の負担となっていた。既知の障害に対して自動対応するシステムにおいても、既知の障害と類似する障害に対しては、同じ対応で済むとは限らない。したがって、対応方法や対応の必要性を運用者が判断したり、運用者による対応が必要となったりするため、運用者の負担となっていた。

本発明は、監視対象システムで発生した障害に関して、既知の情報に基づいて自動対応を行い、対応処理の結果に応じて運用者への通知を行うことにより、運用者の負担を軽減することを目的とする。

請求項１に係る本発明は、
監視対象システムにおいて発生した障害の情報を取得する障害情報取得手段と、
前記監視対象システムに発生し得ると想定される障害に対する対処方法を記述した対処方法定義を保持する対処方法定義保持手段と、
前記障害情報取得手段により取得された情報に基づき、前記対処方法定義保持手段に保持された前記対処方法定義のうち、前記監視対象システムに発生した障害に対応する対処方法定義を選択する選択手段と、
前記選択手段により選択された対処方法定義にしたがって対応処理を自動実行する実行手段と、
前記実行手段による対応処理の実行結果が、障害の解決の成否ではなく、動作ログの存在が予め定められた内容か否かを対応処理の内容に応じて規定したパラメータに基づいて判断する対処結果判断手段と、
前記対処結果判断手段により、前記実行結果が予め定められた内容である場合は運用者による対応が必要ない旨の情報を出力し、当該実行結果が予め定められた内容でない場合は、運用者による対応が必要である旨の情報を出力する出力手段と、
を備えることを特徴とする、情報処理システムである。
請求項２に係る本発明は、
前記選択手段は、前記監視対象システムで発生した事象の発生状況に基づく分類により、当該監視対象システムに発生した障害に対応する対処方法を選択することを特徴とする、請求項１に記載の情報処理システムである。
請求項３に係る本発明は、
前記障害情報取得手段は、前記監視対象システムの動作ログを取得し、
前記選択手段は、前記障害情報取得手段により取得された動作ログのテキストから予め定められた文字列を検索し、検出された文字列により前記監視対象システムで発生した事象の発生状況を分類することを特徴とする、請求項２に記載の情報処理システムである。
請求項４に係る本発明は、
前記監視対象システムの障害に対して運用者による対応処理が行われた場合に、当該対応処理の実行履歴を保持する対応履歴保持手段と、
前記対応履歴保持手段に保持された前記実行履歴に基づき、前記障害に対する前記対処方法定義を作成する定義作成手段と、
をさらに備えることを特徴とする、請求項１に記載の情報処理システムである。
請求項５に係る本発明は、
前記対応履歴保持手段により保持された前記実行履歴を提示し、運用者による編集操作を受け付ける編集操作受け付け手段をさらに備えることを特徴とする、請求項４に記載の情報処理システムである。
請求項６に係る本発明は、
前記監視対象システムの障害に対して運用者により行われた対応処理の情報の入力操作を受け付ける入力操作受け付け手段をさらに備え、
前記対応履歴保持手段は、少なくとも前記実行履歴の一部として、前記入力操作受け付け手段により受け付けた情報を保持することを特徴とする、請求項４に記載の情報処理システムである。

請求項１の発明によれば、監視対象システムで発生した障害に関して、運用者に対応させる場合と比較して、既知の情報に基づいて自動対応を行い、対応処理の結果に応じて運用者への通知を行うことにより、運用者の負担を軽減することができる。
請求項２の発明によれば、予め定められた障害に対してのみ自動対応を行う場合と比較して、対処方法の特定条件を、実際に発生した事象の具体的な発生状況に基づいて柔軟に設定することができる。
請求項３の発明によれば、発生した事象を動作条件等に基づいて判断する場合と比較して、動作ログに対するテキスト解析により事象の発生状況を特定することができる。
請求項４の発明によれば、予め定められた障害に対してのみ自動対応を行う場合と比較して、類似する同種の障害に対し、以後、自動対応することができる。
請求項５の発明によれば、予め定められた障害に対してのみ自動対応を行う場合と比較して、運用者の編集操作により、より有効な対処方法定義の作成に適した実行履歴の作成を支援することができる。
請求項６の発明によれば、予め定められた障害に対してのみ自動対応を行う場合と比較して、運用者により行われた対応処理に基づき、より有効な対処方法定義の作成に適した実行履歴の作成を支援することができる。

本実施形態が適用される情報処理システムの全体構成を示す図である。 監視対象システムの機能構成を示す図である。 障害対応システムの機能構成を示す図である。 対応処理部の処理機能の例を示す図である。 障害対応システムの動作を示すフローチャートである。 対象方法定義の例を示す図である。 ＵＩ画面における主操作画面の例を示す図である。 関連ログ表示画面の例を示す図である。 エスカレーション実行画面の例を示す図である。 結果表示画面の例を示す図である。 運用者の手動操作による対応処理の履歴情報の例を示す図である。

以下、添付図面を参照して、本発明の実施の形態について詳細に説明する。
＜システム構成＞
図１は、本実施形態が適用される情報処理システムの全体構成を示す図である。本実施形態の情報処理システムは、障害対応システム１００と、障害データベース（ＤＢ）２００と、監視対象システム３００とを備える。

障害対応システム１００は、監視対象システム３００を監視する情報処理システムである。障害対応システム１００は、監視対象システム３００にエラー等の障害が発生した場合に対応処理を行う。障害対応システム１００は、監視対象システム３００で発生した障害が自動実行可能な対応処理により対応できる場合には、必要な対応処理を自動実行して対応する。一方、障害対応システム１００は、監視対象システム３００で発生した障害が自動実行可能な対応処理では対応できない場合には、監視対象システム３００の運用者に通知を行い、運用者による対応を促す。

障害ＤＢ２００は、監視対象システム３００で発生した障害に関する情報を保存し管理するデータベースである。障害ＤＢ２００には、障害の発生から障害に対する対応が完了するまでの情報が記録される。障害ＤＢ２００としては、ネットワークを介して利用可能な種々の態様によるデータベースシステムを用いて良い。障害ＤＢ２００としてクラウドサーバ等のデータベースサーバを利用する場合、ＡＰＩ（Application Programming Interface）により外部（障害対応システム１００）から操作可能であることが必要である。図１に示す例では、１つの障害ＤＢ２００が記載されているが、障害ＤＢ２００は複数あっても良い。

監視対象システム３００は、障害対応システム１００による監視の対象となる情報処理システムである。監視対象システム３００は、動作を障害対応システム１００により監視して障害が発生したことを検知可能な構成を有していれば、どのような情報処理システムであっても良い。

図１に示した構成において、障害対応システム１００は、例えば、ネットワーク上に構築されたサーバにより実現される。また、監視対象システム３００は、ネットワーク上に構築されたサーバにより実現しても良いし、ネットワークを介して障害対応システム１００と接続されていれば、監視対象システム３００自体はローカルなシステムであっても良い。障害対応システム１００および監視対象システム３００は、単一のハードウェア（サーバマシン等）による構成に限定されず、複数のハードウェアや仮想マシンに分散して構成しても良い。

＜監視対象システム３００の機能構成＞
図２は、監視対象システム３００の機能構成を示す図である。監視対象システム３００は、機能実行部３１０と、ログ管理部３２０と、検出部３３０とを備える。監視対象システム３００を実現するサーバは、例えば、コンピュータにより実現され、ハードウェアとして、演算手段であるＣＰＵ（Central Processing Unit）と、記憶手段である主記憶装置（メイン・メモリ）および外部記憶装置を備える。ＣＰＵは、外部記憶装置に格納されたプログラムを主記憶装置に読み込んで、実行する。主記憶装置としては、例えばＲＡＭ（Random Access Memory）が用いられる。外部記憶装置としては、例えば磁気ディスク装置やＳＳＤ（Solid State Drive）等が用いられる。

機能実行部３１０は、例えば、ＣＰＵがアプリケーションプログラムを実行することにより実現される。機能実行部３１０は、アプリケーションプログラムの制御により、各種の機能によるデータ処理や制御を実行する。また、機能実行部３１０は、実行した処理や制御に応じて動作ログを生成する。

ログ管理部３２０は、機能実行部３１０の動作に応じて生成された動作ログを保存し、管理する。機能実行部３１０による処理や制御の実行において、障害が発生した場合は、この障害の発生を表す情報も動作ログに記録される。

検出部３３０は、ログ管理部３２０に保存された動作ログを解析して特定の文字列を検出し、特定の処理を実行する。特定の文字列とは、機能実行部３１０による処理や制御においてエラー等の特定の障害が発生する際に、動作ログの記述に出現する文字列である。例えば、「ＦＡＴＡＬ」や「ＳＥＶＥＲＥ」等の文字列を特定の文字列としても良い。特定の処理とは、動作ログからこれらの特定の文字列が検出された場合に実行することが定められている処理である。例えば、運用者に障害の発生を知らせる電子メールを送信したり、障害対応システム１００に障害の発生を通知したりする等の処理である。

また、検出部３３０は、検出された特定の文字列を含む特定の範囲の動作ログを、障害対応システム１００に引き渡す。引き渡される動作ログの範囲は、例えば、検出された文字列や特定された障害の種類に応じて定められる。

＜障害対応システム１００の機能構成＞
図３は、障害対応システム１００の機能構成を示す図である。障害対応システム１００は、監視部１１０と、対処方法実行制御部１２０と、対処方法定義保持部１３０と、対応処理部１４０と、対処方法定義管理部１５０と、対処結果出力部１６０と、障害ＤＢアクセス部１７０とを備える。また、障害対応システム１００は、障害調査ＵＩ部１８１と、障害ＤＢ更新部１８２と、障害調査処理履歴保持部１８３と、対処方法生成部１８４とを備える。

監視部１１０は、監視対象システム３００を監視し、検出部３３０から動作ログを取得する。動作ログには、監視対象システム３００において発生した障害の情報が含まれている。監視部１１０は、障害の情報が含まれた動作ログを取得すると、障害に対応するための対処方法実行制御部１２０を起動させる。また、監視部１１０は、障害ＤＢアクセス部１７０を介して障害ＤＢ２００にアクセスし、動作ログから得られた障害の情報を障害ＤＢ２００に登録する。監視部１１０は、障害情報取得手段の一例である。

対処方法実行制御部１２０は、監視対象システム３００において検出された障害情報と障害に対する対処方法定義とに基づいて、実行する障害の対処方法を特定し、特定した対処方法の実行を制御する。具体的には、対処方法実行制御部１２０は、まず、監視部１１０により取得された動作ログに記録された障害情報に基づき、監視対象システム３００に発生した障害に対応する対処方法定義を選択する。そして、対処方法実行制御部１２０は、選択された対処方法定義にしたがって対応処理部１４０を呼び出し、対応処理を自動実行させる。対処方法定義とは、障害に応じて実行すべき対処方法の情報である。

対処方法定義の選択についてさらに説明すると、対処方法実行制御部１２０は、監視対象システム３００で発生した障害の発生状況に基づく分類により、監視対象システム３００に発生した障害に対応する対処方法定義を選択する。障害の発生状況とは、障害の発生時および発生に至るまでに監視対象システム３００において発生した事象の集合である。具体的には、一または複数の特定事象の発生時刻、発生回数や発生間隔などが挙げられる。より詳細には、対処方法実行制御部１２０は、監視部１１０により取得された動作ログのテキストから予め定められた文字列を検索し、検出された文字列により監視対象システム３００で発生した事象の発生状況を分類する。対処方法実行制御部１２０は、選択手段の一例である。

対処方法定義保持部１３０は、障害に対する対処方法定義を保持する。対処方法定義保持部１３０は、対処方法定義保持手段の一例である。対処方法定義には、監視対象システムに発生し得ると想定される障害に対する対処方法が記述されている。具体的には、例えば、エラー情報に基づいて適用すべき対処方法を特定する条件（フィルタ条件）、特定した対処方法に応じた実行手段およびパラメータ、対処の実行結果が想定に合致した場合に、障害ＤＢ２００に書き込む情報、対処の実行結果が想定に合致しなかった場合に、障害ＤＢ２００に書き込む情報などが記述される。ここで、想定される実行結果とは、例えば、自動対応により復旧（正常復帰）した場合の状態や状況である。対処方法定義の詳細については後述する。

対応処理部１４０は、対処方法実行制御部１２０により呼び出される具体的な処理機能である。対処方法実行制御部１２０および対応処理部１４０は、対応処理実行手段の一例である。対応処理部１４０の処理機能には、障害の種類に応じて種々の機能が用意される。対応処理部１４０の処理機能の詳細については後述する。

対処方法定義管理部１５０は、対処方法定義保持部１３０に保持されている対処方法定義を管理する。対処方法定義管理部１５０は、対処方法生成部１８４により生成された対処方法定義を対処方法定義保持部１３０に追加したり、生成された対処方法定義により既存の対処方法定義を更新したり、不要となった対処方法定義を削除したりする。

対処結果出力部１６０は、対処方法実行制御部１２０および対応処理部１４０により実行された対応処理の実行結果について、想定内か想定外かを判断する。また、対処結果出力部１６０は、判断結果を出力し、障害ＤＢアクセス部１７０を介して障害ＤＢ２００へ格納する。より詳細には、対処結果出力部１６０は、対応処理の実行結果が予め定められた内容（想定内）であると判断した場合は、運用者による対応が必要ない旨の情報を出力して障害ＤＢ２００に格納させる。一方、対応処理の実行結果が予め定められた内容でない（想定外）と判断した場合は、運用者による対応が必要である旨の情報を出力して障害ＤＢ２００に格納させる。対処結果出力部１６０は、対処結果判断手段の一例であり、出力手段の一例である。

障害ＤＢアクセス部１７０は、障害ＤＢ２００にアクセスして、情報の追加、更新などを行う。具体的には、障害ＤＢアクセス部１７０は、対処結果出力部１６０の判断結果を障害ＤＢ２００に送信する。また、障害ＤＢアクセス部１７０は、障害ＤＢ更新部１８２の制御により、障害ＤＢ２００に保存された情報を更新する。障害ＤＢ更新部１８２による障害ＤＢ２００の更新については後述する。

障害調査ＵＩ部１８１は、障害調査を行うためのＵＩ（User Interface）としての操作画面（ＵＩ画面）を生成する。生成された操作画面は、運用者が操作する端末装置に送られ、表示される。障害調査ＵＩ部１８１が提供するＵＩにより、運用者は、対応処理部１４０の各機能を呼び出して対応処理を実行させ得る。すなわち、対応処理部１４０による監視対象システム３００の障害に対する対応処理の実行手段として、対処方法実行制御部１２０の制御による自動実行とは別に、操作画面に対する運用者の手動操作による実行が可能である。操作画面から呼び出して実行された対応処理の実行結果は、障害ＤＢ更新部１８２に渡される。

また、障害調査ＵＩ部１８１が提供するＵＩは、監視対象システム３００の障害に対して運用者の手動操作により行われた対応処理部１４０による対応処理の情報の入力操作を受け付ける。そして、障害調査ＵＩ部１８１が提供するＵＩは、入力操作により入力された情報を障害調査処理履歴保持部１８３に保持させる。また、障害調査ＵＩ部１８１が提供するＵＩは、障害調査処理履歴保持部１８３により保持された実行履歴を提示し、運用者による編集操作を受け付ける。障害調査処理履歴保持部１８３については後述する。障害調査ＵＩ部１８１は、入力操作受け付け手段の一例であり、編集操作受け付け手段の一例である。

障害ＤＢ更新部１８２は、障害調査ＵＩ部１８１から渡された情報を、障害調査処理履歴に追記する。そして、障害ＤＢ更新部１８２は、障害ＤＢアクセス部１７０を介して障害ＤＢ２００にアクセスし、追記した障害調査処理履歴に基づいて障害ＤＢ２００を更新する。

障害調査処理履歴保持部１８３は、障害調査ＵＩ部１８１から渡された情報を記録した障害調査処理履歴を保持する。さらに詳細には、障害調査処理履歴保持部１８３は、監視対象システム３００の障害に対して運用者の手動操作による対応処理が行われた場合に、対応処理の実行履歴を保持する。障害調査処理履歴保持部１８３は、対応履歴保持手段の一例である。

対処方法生成部１８４は、障害調査処理履歴保持部１８３に保持された実行履歴に基づき、障害に対する対処方法定義を生成する。すなわち、対処方法生成部１８４は、過去に発生した障害と同様の障害が次に起きた場合に備えて、障害調査処理履歴を参照して対処方法定義を自動生成する。より詳細には、対処方法生成部１８４は、過去に手動操作により実施された対応処理から、有効だったと判断される処理を運用者が特定して、特定された処理を実施した順序の通りに行うように対処方法定義を生成する。自動生成された対処方法定義は、運用者により内容を確認され、問題が無ければ、対処方法定義管理部１５０により対処方法定義保持部１３０に追加される。対処方法生成部１８４は、定義作成手段の一例である。

＜対応処理部１４０の処理機能＞
図４は、対応処理部１４０の処理機能の例を示す図である。対応処理部１４０には、ログ情報取得部１４１、ユーザ情報取得部１４２、エスカレーション実行部１４３、動作確認テスト実行部１４４、連携先システム稼働確認部１４５等の処理機能が用意される。

ログ情報取得部１４１は、障害が発生した事象の前後のログ情報（動作ログ）を取得する機能である。ログ情報取得部１４１は、障害ＤＢ２００や監視対象システム３００のログ管理部３２０から動作ログを取得する。

ユーザ情報取得部１４２は、動作ログに出力されたユーザ識別子から、動作ログに記録された操作を指示したユーザの属性情報（以下、ユーザ情報）を取得する機能である。ユーザ情報としては、例えば、ユーザの名前、ユーザが属するグループのグループ名、ユーザに与えられた権限の情報等が挙げられる。ユーザ情報は、ユーザ識別子により特定して取得できれば良く、ユーザ情報自体が保持されている保持手段の構成は限定しない。例えば、事前に障害対応システム１００に保持していても良いし、監視対象システム３００から取得しても良いし、外部に用意されたユーザ情報ＤＢから取得しても良い。

エスカレーション実行部１４３は、予め指定された送信先に、報告や依頼のメッセージを送信する機能である。メッセージの送信には、例えば電子メール、トラッキング・ツール、コミュニケーション・ツールなどが用いられる。エスカレーションとは、監視対象システム３００の障害を解決するために、より専門的な知識あるいは権限を有するスタッフに委ね、より早く解決策を見つけることである。機能的エスカレーションと階層的エスカレーションとがある。階層的エスカレーションとは、上位者（より権限を有するマネージャ等）に判断を仰ぐことである。定められた手順では、目標時間内に障害を解決できない場合や、コストがかかる場合等に適用される。機能的エスカレーションとは、開発担当者等（より専門的な知識を有する者）に、調査依頼等を行い、障害の解決を委ねることである。インシデントを解決するために必要な知識が不足している場合等に適用される。

動作確認テスト実行部１４４は、障害の発生が検出された監視対象システム３００に対する自動テストを実行する。自動テストとは、監視対象システム３００の機能実行部３１０によりアプリケーションプログラムによる動作が正常に行われているか否かを確認する操作である。自動テストとしては、例えば、アプリケーションが停止状態（完全停止または一部停止）であるかどうかを確認することを目的とする軽いテストや、いくつかの代表的なシナリオで動作を確認するテスト等が行われる。

連携先システム稼働確認部１４５は、監視対象システム３００の連絡先システムが停止していないか否かを確認する操作である。連携先システムとは、監視対象システム３００の機能により連携して処理や制御を行う外部システムである。連携先システムの稼働状態を直接的に確認する他、連携先システムにおいてメンテナンス案内が出ていないかを確認することで代替しても良い。

障害対応システム１００を実現するサーバは、例えば、コンピュータにより実現され、ハードウェアとして、演算手段であるＣＰＵと、記憶手段である主記憶装置および外部記憶装置とを備える。ＣＰＵは、外部記憶装置に格納されたプログラムを主記憶装置に読み込んで、実行する。主記憶装置としては、例えばＲＡＭが用いられる。外部記憶装置としては、例えば磁気ディスク装置やＳＳＤ等が用いられる。上述した監視部１１０、対処方法実行制御部１２０、対応処理部１４０、対処方法定義管理部１５０、対処結果出力部１６０、障害ＤＢアクセス部１７０、障害調査ＵＩ部１８１、障害ＤＢ更新部１８２および対処方法生成部１８４の各機能は、例えば、ＣＰＵがプログラムを実行することにより実現される。また、対処方法定義保持部１３０および障害調査処理履歴保持部１８３は、プログラムを実行するＣＰＵと、記憶手段である主記憶装置や外部記憶装置により実現される。

＜障害対応システム１００の動作＞
図５は、障害対応システム１００の動作を示すフローチャートである。監視対象システム３００の検出部３３０により障害が検出されると、障害対応システム１００の監視部１１０が、監視対象システム３００から動作ログを取得して、障害の発生を検知する（Ｓ５０１）。そして、対処方法実行制御部１２０が、各対処方法定義のフィルタ条件（対処方法定義を適用する条件）と取得した動作ログとを比較して合致判定を行い、動作ログに合致するフィルタ条件を特定する（Ｓ５０２）。

次に、対処方法実行制御部１２０は、フィルタ条件が合致する全ての対処方法定義を順次適用し、障害の内容に応じたパラメータを指定して対応処理部１４０を呼び出し、対応処理を実行する（Ｓ５０３、Ｓ５０４）。フィルタ条件が合致する全ての対処方法定義を適用した後、対処結果出力部１６０が、対応処理の実行結果が想定内か否かを判定する。想定内であった場合（Ｓ５０５でＹＥＳ）、対処結果出力部１６０は、障害ＤＢアクセス部１７０を介して障害ＤＢ２００にアクセスし、想定内の情報で障害ＤＢ２００を更新する（Ｓ５０６）。一方、対応処理の実行結果が想定外であった場合（Ｓ５０５でＮＯ）、対処結果出力部１６０は、障害ＤＢアクセス部１７０を介して障害ＤＢ２００にアクセスし、想定外の情報で障害ＤＢ２００を更新する（Ｓ５０７）。

＜対処方法定義の構成例＞
図６は、対象方法定義の例を示す図である。図６に示す対処方法定義には、定義番号（「Ｎｏ．」）、適用順、フィルタ条件、説明、対応処理部、パラメータ、障害ＤＢ更新処理の各項目が記録されている。定義番号（「Ｎｏ．」）は、各対処方法実行の識別情報である。「適用順」は、複数の対処方法定義のフィルタ条件が動作ログに合致する場合における各対処方法定義の適用順を示す。例えば、フィルタ条件が合致する対処方法定義のうち、適用順の数値の小さい方から順に適用される。

「フィルタ条件」は、各対処方法定義を適用する条件であり、具体的な条件は、動作ログに出現する文字列が指定される。例えば、図６に示す定義番号２１の対処方法定義は、動作ログに「xxx.invoker: endpoint timed out」という文字列が記述されていた場合に適用される。「説明」は、フィルタ条件の内容の説明である。運用者がフィルタ条件の内容を理解するために記録される。例えば、定義番号２１の対処方法定義では、上述したフィルタ条件で指定された動作ログの記述が、連携先システムとの通信でタイムアウトが発生したこと（図では「連携先システムからのタイムアウト」と記載）を意味することが、説明の項目に記録されている。また、定義番号１～３の対処方法定義は、フィルタ条件が指定されていない。そのため、他の対処方法定義のフィルタ条件が合致しなかった場合に適用対象となる。そして、これらの対処方法定義が「未知のエラーについての処理」であることが説明の項目に記録されている。

「対応処理部」は、対処方法定義が適用される場合に実行される（呼び出される）対応処理部１４０を示す。例えば、図６に示す定義番号２２の対処方法定義が適用される場合、動作ログを取得して参照する対応処理部１４０（図では「ログ取得／参照機能」と記載）と、動作確認テストを実行する対応処理部１４０（図では「動作確認テスト実施」と記載）とが呼び出されて実行される。なお、図６に示す例では、「対応処理部」の項目に対して「ＡＮＤ」という属性が与えられており、これらの対応処理の何れか一方ではなく、両方が実行される。

「パラメータ」は、対応処理部１４０の処理内容に応じて必要となるパラメータを規定する。例えば、図６に示す定義番号２２の対処方法定義に基づき対応処理「ログ取得／参照機能」が実行される場合、「パラメータ」として「規定時間＝６０秒」、「条件＝以上前」、「フィルタ条件＝"PUT,/aaa/bbb/cccc/""<<フィールド5>>"」、「想定＝ログあり」が規定されている。したがって、定義番号２２の「フィルタ条件」である文字列「Unexpected Error」が動作ログに出現する６０秒以上前に、動作ログのフィールド５に文字列「PUT,/aaa/bbb/cccc/」があるか否かが判断される。動作ログのフィールド５に該当する文字列があれば実行結果は想定内であり、無ければ実行結果は想定外である。また、定義番号１の対処方法定義に基づき対応処理「ユーザ情報取得」が実行される場合、「パラメータ」として「フィールド＝９」が規定されているため、動作ログのフィールド９に記載されている情報が取得される。

「障害ＤＢ更新処理」は、対応処理の実行後に行われる障害ＤＢ２００の更新処理を示す。更新処理は、対応処理の実行結果が想定内であった場合の処理と、想定外であった場合の処理とが規定される。例えば、図６に示す定義番号２２の対処方法定義に基づき対応処理が実行され、想定内の実行結果であった場合、「Status＝完了」、「Substatus＝レビュー待ち」、「IncidentLevel=3」、「Note＝既知のエラーNo.22に該当」、「<<該当行>>」という情報が障害ＤＢ２００に記録される。「<<該当行>>」は、動作ログにおいて、定義番号２２のフィルタ条件の文字列「Unexpected Error」が出現する行を示す。また、想定外の実行結果であった場合、「Note＝既知のエラーNo.22には該当せず」、「６０秒以上前にPUT：<<結果1>>」、「動作確認テスト実施：<<結果2>>」という情報が障害ＤＢ２００に記録される。

なお、対処方法定義によっては、一部の項目がブランクとなっている場合がある。例えば、図６に示す定義番号２１の対処方法定義では、フィルタ条件が該当した場合、特に対応処理は実行されず、障害ＤＢ２００に「Status＝完了」、「Substatus＝完了」、「IncidentLevel=3」、「Note＝既知のエラーNo.21に該当」という情報が障害ＤＢ２００に記録される。対応処理が実行されないため、対応処理部およびパラメータの各項目はブランクとなっている。また、障害ＤＢ更新処理では、想定内の処理に上記の更新内容が記載され、想定外の処理はブランクとなっている。

＜対処方法定義の適用例＞
図６に示した対処方法定義を用いた障害対応システム１００の動作を説明する。動作例として、対応処理部１４０の呼び出しが行われない簡単な動作例と、対応処理部１４０による対応処理が行われる複雑な動作例を示す。前者の例としては、図６に示す定義番号２１の対処方法定義が該当する場合の動作例を説明し、後者の例としては、同定義番号２２の対処方法定義が該当する場合の動作例を説明する。

・定義番号２１の対処方法定義が該当する場合の動作例
監視対象システム３００の動作において、連携先システムからの応答がタイムアウトとなり、この事象が障害として検出されたものとする。最初に検出された動作ログに文字列「xxx.invoker: endpoint timed out」が含まれている場合は、定義番号２１の対処方法定義に該当する。そしてこの場合は、対応処理部１４０を呼び出すまでもなく、障害の内容を判断できる。この事例は、監視対象システム３００とその連携先システムとの間、すなわちクライアント-サーバ間の通信で、通信経路の途中でタイムアウトが発生した、という事象である。この場合は、運用者が実施すべき対応処理は無く、特に復旧作業等を行う必要はない。そのため、障害ＤＢに記録を残して、障害対応を完了とする。

・定義番号２２の対処方法定義が該当する場合の動作例
監視対象システム３００の動作において障害が検出され、監視部１１０が動作ログを取得し、対処方法実行制御部１２０が動作ログを調べる。この事象において判断できる条件は、以下の通りである。
１．検出された動作ログの中に文字列「Unexpected Error」が含まれる（フィルタ条件参照）。
２．リクエストＩＤ（フィールド５に出力される）が同じで、「PUT,/aaa/bbb/cccc/」という文字列を含むログが、６０秒以上前に出力されている（パラメータ参照）。
３．動作確認テストが正常終了する。テスト対象は、フィールド１１に出力される（パラメータ参照）。

以下、次の手順で処理が行われる。
（１）取得した動作ログに、Unexpected Errorという文字列が含まれているか否かを文字列検索により確認する。含まれていた場合は、この対処方法定義に該当するものとして、対応処理部１４０を呼び出して対応処理を開始する。
（２）動作ログの５番目のフィールドから値を取得する。ここでは、５番目のフィールドにリクエストＩＤが記述されているものと想定している。
（３）取得した値（リクエストＩＤ）があり、かつ文字列「PUT,/aaa/bbb/cccc/」が出力されている動作ログ（行）が、発生した障害の６０秒以上前に存在する（想定＝ログあり）場合は、想定内と判断する。例えば、１２０秒前にログがあった場合は、６０秒以上前なので想定内となり、３０秒前に発生していた場合は、６０秒未満であるので想定外となる。
（４）動作ログの１１番目のフィールドから値を取得する。ここでは、１１番目のフィールドに動作確認テストの対象を識別するコードが記述されているものと想定している。
（５）テスト対象パラメータに、取得した値（識別コード）を指定して、動作確認テストを実行する。実行結果が成功の場合（想定＝テスト成功）は、想定内と判断する。
（６）動作ログと動作確認テストの両方が（ＡＮＤ）想定内だった場合は、既知のエラーと判断して、「想定内の場合」の情報で障害ＤＢの障害情報を更新し、障害対応を完了する。その他の場合は、「想定外の場合」の情報で障害ＤＢの障害情報を更新し、障害対応を完了する。

＜障害調査ＵＩ画面の構成例＞
次に、障害調査ＵＩ部１８１により提供されるＵＩ画面について説明する。ＵＩ画面は、運用者が使用する端末装置（不図示）の表示装置に表示される。運用者の端末装置は、障害対応システム１００に接続され、障害調査ＵＩ部１８１からＵＩ画面を取得して表示すると共に、このＵＩ画面を用いて行われた運用者の操作を受け付けて、対処方法生成部１８４や障害ＤＢ更新部１８２に対して指示を行う。運用者の操作は、例えば、キーボード、マウス、タッチパネル等の入力装置を用いて行われる。

図７は、ＵＩ画面における主操作画面の例を示す図である。主操作画面４００は、障害表示欄４０１と、ログ表示欄４０２と、操作オブジェクト４０３とを有する。障害表示欄４０１には、検出された障害に関する情報が表示される。図７に示す例では、障害ＩＤ、発生時刻、障害が記述された動作ログを含むロググループの各情報が表示されている。ログ表示欄４０２には、障害が検出された動作ログが表示される。

操作オブジェクト４０３は、運用者の手動操作による対応処理の指示を行うためのオブジェクトである。図７に示す例では、操作オブジェクト４０３として、「関連ログ」、「ユーザ情報取得」、「エスカレーション」、「自動テスト実施」の４つのボタンオブジェクトと、自動テストを実行する機能（対応処理部１４０）選択するチェックボックスとが設けられている。

「関連ログ」ボタンは、障害表示欄４０１およびログ表示欄４０２に示された動作ログに関連する動作ログ（以下、関連ログ）を取得して表示することを指示する操作オブジェクト４０３である。「関連ログ」ボタンが操作されると、関連ログ表示画面に移行する。「ユーザ情報取得」ボタンは、ユーザ情報を取得することを指示する操作オブジェクト４０３である。「ユーザ情報取得」ボタンが操作されると、動作ログに記録された操作を指示したユーザの情報が取得される。「エスカレーション」ボタンは、エスカレーションを実行することを指示する操作オブジェクト４０３である。「エスカレーション」ボタンが操作されると、エスカレーション実行画面に移行する。「自動テスト実施」ボタンは、自動テストの実行を指示する操作オブジェクト４０３である。「自動テスト」ボタンが操作されると、チェックボックスで選択された機能（対応処理部１４０）による自動テストが実行され、実行結果を示す結果表示画面に移行する。

図８は、関連ログ表示画面の例を示す図である。関連ログ表示画面４１０は、フィルタ表示画面４１１と、ログ表示欄４１２とを有する。フィルタ表示画面４１１には、関連ログを取得するためのフィルタとなる文字列が表示される。ログ表示欄４１２には、フィルタ表示画面４１１に表示された文字列が含まれる関連ログが表示される。すなわち、フィルタ表示画面４１１に表示された文字列を検索キーとして検索された動作ログが関連ログとしてログ表示欄４１２に表示される。図８に示す例では、フィルタ表示画面４１１に、文字列「F8E6002D70E457CE」が表示されており、このフィルタにより、特定された５つの動作ログが関連ログとしてログ表示欄４１２に示されている。

ここで、この障害の動作ログに対し、図６に示した定義番号２２の対処法定義のフィルタ条件が該当する場合を考える。図８に示す例では、ログ表示欄４１２に表示された関連ログのうち５番目の動作ログは、定義番号２２の対処法定義のフィルタ条件である文字列「Unexpected Error」を含む。また、文字列「Unexpected Error」が動作ログに出現する６０秒以上前に、動作ログのフィールド５に文字列「PUT,/aaa/bbb/cccc/」があるかを調べる。すると、１番目の関連ログは、５番目の関連ログの９０秒前に記録され、フィールド５に文字列「PUT,/aaa/bbb/cccc/」を含む。したがって、この１番目と５番目の関連ログが、この障害に関わる動作ログとして特定される。各関連ログの表示欄には「報告」ボタンが設けられており、運用者が「報告」ボタンを操作すると、操作された「報告」ボタンが設けられている表示欄の関連ログが障害に関わる動作ログであることを示す情報が、障害対応システム１００の障害ＤＢ更新部１８２および対処方法生成部１８４へ送信される。

なお、図８において、２番目から４番目の動作ログは、文字列「F8E6002D70E457CE」を含むためにログ表示欄４１２に表示されたが、障害に関連する動作ログではないものとする。そのため、図８では、ｌｏｇ２、ｌｏｇ３、ｌｏｇ４と略記し、具体的なログの記載を省略している。

図９は、エスカレーション実行画面の例を示す図である。エスカレーション実行画面４２０は、書誌情報入力欄４２１と、メッセージ入力欄４２２とを有する。図９に示す例では、エスカレーションのための通知として電子メールを用いる例が示されている。書誌情報入力欄４２１には、メッセージの送信元（Ｆｒｏｍ）、件名（Ｓｕｂｊｅｃｔ）、送信先（Ｔｏ）等の書誌情報を入力する入力ボックスが設けられている。また、メッセージ入力欄４２２には、エスカレーションの相手へのメッセージを入力する入力ボックスが設けられている。

図１０は、結果表示画面の例を示す図である。結果表示画面４３０は、実行ログ表示欄４３１と、結果表示欄４３２と、「報告」ボタン４３３とを有する。実行ログ表示欄４３１には、自動テストの実行ログが表示される。図１０に示す例では、主操作画面４００で選択された機能１（図７参照）の自動テストを実行して成功したことを示す文字列「機能1 Test is successed.」が実行ログに記述されている。結果表示欄４３２には、自動テストの結果が表示される。図１０に示す例では、実行ログの記述に基づき、自動テストの実行結果が成功であることを示す内容が記載されている。「報告」ボタン４３３は、自動テストの実行結果を障害対応システム１００へ送信する操作オブジェクトである。運用者が「報告」ボタンを操作すると、自動テストの実行結果が障害対応システム１００の障害ＤＢ更新部１８２および対処方法生成部１８４へ送信される。

図７乃至図１０を参照して説明したＵＩ画面により、運用者の手動操作による対応処理が行われると、その対応処理の履歴情報が障害調査処理履歴保持部１８３に保持される。この履歴情報と、障害調査ＵＩ部１８１により受け付けた運用者の操作に基づき、対処方法生成部１８４が新たな対処方法定義を生成する。

図１１は、運用者の手動操作による対応処理の履歴情報の例を示す図である。この履歴情報には、履歴情報が記録された日時と、障害ＤＢ２００のＩＤ（図では、「障害ＤＢ－ＩＤ」と記載）と、実行した障害の調査および対応処理を示す情報（図では、「障害調査／対応機能」と記載）と、障害ＤＢ２００の更新記録の各項目が記録される。障害ＤＢ２００のＩＤは、障害ＤＢ２００が複数ある場合に、情報が記録されている障害ＤＢ２００を特定するために用いられる。障害の調査および対応処理を示す情報としては、実行した機能と、その機能を実行する際に用いたパラメータとが記録される。障害ＤＢ２００の更新記録では、事実と、根拠とが記録される。事実とは、各ＵＩ画面において運用者により実行された内容である。根拠とは、事実に示される内容を運用者が実行するに至った根拠である。

以上、本発明の実施形態について説明したが、本発明の技術的範囲は上記実施形態には限定されない。例えば、上記の実施形態では、監視対象システム３００に検出部３３０を設けて障害を検出し、障害対応システム１００の監視部１１０に動作ログを送ることとした。これに対し、監視対象システム３００に検出部３３０を設けず、障害対応システム１００の監視部１１０が監視対象システム３００の動作ログを取得して障害を検出しても良い。また、障害対応システム１００に監視部１１０を設けず、監視対象システム３００の検出部３３０により検出された障害に関する情報を含む動作ログのみを障害対応システム１００の対処方法実行制御部１２０が取得し、対応処理を実行するようにしても良い。その他、本発明の技術思想の範囲から逸脱しない様々な変更や構成の代替は、本発明に含まれる。

１００…障害対応システム、１１０…監視部、１２０…対処方法実行制御部、１３０…対処方法定義保持部、１４０…対応処理部、１４１…ログ情報取得部、１４２…ユーザ情報取得部、１４３…エスカレーション実行部、１４４…動作確認テスト実行部、１４５…連携先システム稼働確認部、１５０…対処方法定義管理部、１６０…対処結果出力部、１７０…障害ＤＢアクセス部、１８１…障害調査ＵＩ部、１８２…障害ＤＢ更新部、１８３…障害調査処理履歴保持部、１８４…対処方法生成部、２００…障害データベース（ＤＢ）、３００…監視対象システム

Claims (6)

1. 監視対象システムにおいて発生した障害の情報を取得する障害情報取得手段と、
   前記監視対象システムに発生し得ると想定される障害に対する対処方法を記述した対処方法定義を保持する対処方法定義保持手段と、
   前記障害情報取得手段により取得された情報に基づき、前記対処方法定義保持手段に保持された前記対処方法定義のうち、前記監視対象システムに発生した障害に対応する対処方法定義を選択する選択手段と、
   前記選択手段により選択された対処方法定義にしたがって対応処理を自動実行する実行手段と、
   前記実行手段による対応処理の実行結果が、障害の解決の成否ではなく、動作ログの存在が予め定められた内容か否かを対応処理の内容に応じて規定したパラメータに基づいて判断する対処結果判断手段と、
   前記対処結果判断手段により、前記実行結果が予め定められた内容である場合は運用者による対応が必要ない旨の情報を出力し、当該実行結果が予め定められた内容でない場合は、運用者による対応が必要である旨の情報を出力する出力手段と、
   を備えることを特徴とする、情報処理システム。
2. 前記選択手段は、前記監視対象システムで発生した事象の発生状況に基づく分類により、当該監視対象システムに発生した障害に対応する対処方法を選択することを特徴とする、請求項１に記載の情報処理システム。
3. 前記障害情報取得手段は、前記監視対象システムの動作ログを取得し、
   前記選択手段は、前記障害情報取得手段により取得された動作ログのテキストから予め定められた文字列を検索し、検出された文字列により前記監視対象システムで発生した事象の発生状況を分類することを特徴とする、請求項２に記載の情報処理システム。
4. 前記監視対象システムの障害に対して運用者による対応処理が行われた場合に、当該対応処理の実行履歴を保持する対応履歴保持手段と、
   前記対応履歴保持手段に保持された前記実行履歴に基づき、前記障害に対する前記対処方法定義を作成する定義作成手段と、
   をさらに備えることを特徴とする、請求項１に記載の情報処理システム。
5. 前記対応履歴保持手段により保持された前記実行履歴を提示し、運用者による編集操作を受け付ける編集操作受け付け手段をさらに備えることを特徴とする、請求項４に記載の情報処理システム。
6. 前記監視対象システムの障害に対して運用者により行われた対応処理の情報の入力操作を受け付ける入力操作受け付け手段をさらに備え、
   前記対応履歴保持手段は、少なくとも前記実行履歴の一部として、前記入力操作受け付け手段により受け付けた情報を保持することを特徴とする、請求項４に記載の情報処理システム。

Images