JP2012094049A - インシデント管理システムおよびインシデント管理プログラム - Google Patents

Abstract

【課題】１つのシステム障害に起因して複数の障害メッセージが出力される場合に、関連性のあるこれらの障害メッセージをまとめて取り扱うことを可能とするインシデント管理システムを提供する。
【解決手段】障害監視システム３が出力した障害メッセージに基づいて、これをインシデントとして登録して管理するインシデント管理システム１であって、障害メッセージに基づいて障害事象をインシデントとしてインシデントＤＢ１１に登録するインシデント登録部１０と、障害メッセージについて関連性ルールＤＢ２１に予め登録されている、各障害メッセージとその関連障害メッセージに係る情報を検索して関連障害メッセージの情報を取得し、障害監視システム３における障害発生時近辺の所定の範囲の障害メッセージの出力内容を検索し、取得した関連障害メッセージが出力されている場合は、インシデントＤＢ１１に追加して記録する関連性判定部２０とを有する。
【選択図】図１

Description

本発明は、コンピュータシステムの運用管理の技術に関し、特に、障害検知からの対応実施の支援や対応状況の管理などを行うインシデント管理システムおよびこれに用いられるインシデント管理プログラムに適用して有効な技術に関するものである。

大規模なコンピュータシステムやデータセンター等、多数のコンピュータ機器からなるシステムでは、その継続的な安定稼働のために障害監視等を行う仕組みが構築される。このような仕組みでは一般的に、稼働中のサーバ機器等の障害を監視する監視サーバ等が障害を検知した場合に、オペレータは一次対応として、例えば、障害メッセージに対応して予め定められた対応手順や、過去の同様の障害履歴を参照して得られる対応手順などを取得してこれを実施する。また、当該障害の内容を記録するとともにその対応状況等を管理する。

また、一次対応の実施と同時に、もしくは一次対応の手順がないあるいは手順を実施しても効果がないような場合に、アプリケーションやシステム基盤などの開発担当者等に連絡（コール）し、二次対応を依頼する。これらの作業の実施を支援するための仕組みとして、インシデント（障害）管理システムが構築される場合がある。なお、システムの規模などによっては、オペレータ以外にこのような一次対応の判断や二次対応の依頼コールなどを含むインシデントの管理作業を専属で行うサポートデスク等を設置する場合もある。

このような障害監視と（一次）対応手順の判断に係る技術としては、例えば、特開２００９−２６０５２号公報（特許文献１）には、エージェント装置とマネージャ装置とを備え、エージェント装置が、自装置の状態を示すメッセージをマネージャ装置に対して送信する監視手段を備え、マネージャ装置が、障害を回復するための対処法の種別毎に定義された状態グループの状態を表示する表示装置と、メッセージをそれが関連する状態グループに分類するための分類定義が登録された分類定義蓄積部と、エージェント装置から受信したメッセージを分類定義に従って１以上の状態グループに分類する分類手段と、表示装置に表示された状態グループの状態の内、分類手段によってメッセージが分類された状態グループの状態を変更する状態表示変更手段とを備えることで、エージェント装置に障害が発生した場合、障害を復旧するためにどのような種別の対処法を実施したら良いのかを管理者が短時間で認識できるようにする障害監視システムが開示されている。

特開２００９−２６０５２号公報

多数のコンピュータ機器からなるシステムでは、１つの原因から生じた障害によって多数の機器やコンポーネントが連鎖的に影響を受ける場合がある。この場合、上記の特許文献１のような仕組みも含めて、通常の障害監視の仕組みにおいてはそれぞれの機器等から障害メッセージが連続的に多数出力されることになる。

しかしながら、システムの運用監視を行うオペレータは、システムの構成やアプリケーションの内容などの情報に精通している訳ではないため、これらの障害メッセージ間の関連性を判断することができず、これらが１つの障害から出力されたものと判断することができない。またそのような判断を独自に行うことは危険でもあるため、オペレータとしては、多数の障害メッセージをそれぞれ別の障害事象として取り扱い、対応手順等を個別に検索したり、開発者やサポートデスク等へのコールを障害メッセージ毎に個別に行ったりすることになる。このような状況は各担当者にとって負荷が非常に大きく、システム障害という緊急時の対応に影響を及ぼす場合も生じ得る。

そこで本発明の目的は、１つのシステム障害に起因して複数の障害メッセージが出力される場合に、関連性のあるこれらの障害メッセージをまとめて取り扱うことを可能とするインシデント管理システムおよびインシデント管理プログラムを提供することにある。本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態によるインシデント管理システムは、多数のコンピュータ機器からなる情報処理システムに対して、その障害を監視する障害監視システムが前記コンピュータ機器の障害事象を検知して出力した障害メッセージに基づいて、これをインシデントとして登録して障害状況の管理および障害対応に係る作業の支援を行うシステムであって、以下の特徴を有するものである。

すなわち、インシデント管理システムは、前記障害監視システムが出力した障害メッセージに基づいて、障害事象をインシデントとしてインシデント記録手段に登録するインシデント登録部と、前記インシデント登録部によって前記インシデント記録手段に登録されたインシデントに係る障害メッセージについて、関連性ルール記録手段に予め登録されている、各障害メッセージとその障害事象に起因して出力される一連の障害メッセージである関連障害メッセージに係る情報を検索し、対象のインシデントに係る障害メッセージに対する関連障害メッセージの情報を取得し、取得した関連障害メッセージの情報に基づいて、前記障害監視システムにおける障害発生時近辺の所定の範囲の障害メッセージの出力内容を検索し、取得した関連障害メッセージが出力されている場合は、出力されている関連障害メッセージの情報を前記インシデント記録手段に登録された対象のインシデントの情報に追加して記録する関連性判定部とを有することを特徴とするものである。

また、本発明は、コンピュータを上記のようなインシデント管理システムとして機能させるプログラムにも適用することができる。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

本発明の代表的な実施の形態によれば、１つのシステム障害に起因して複数の障害メッセージが出力される場合に、関連性のあるこれらの障害メッセージをまとめて取り扱うことを可能とするインシデント管理システムおよびインシデント管理プログラムを実現することが可能となる。

本発明の一実施の形態であるインシデント管理システムおよびこれを含む情報処理システムの構成例の概要について示した図である。 本発明の一実施の形態における障害メッセージの取り扱いの例について概要を示した図である。 本発明の一実施の形態におけるインシデントＤＢのデータ構成の例について示した図である。 本発明の一実施の形態における関連性ルールＤＢのデータ構成の例について示した図である。 本発明の一実施の形態における対応手順ＤＢのデータ構成の例について示した図である。 本発明の一実施の形態における担当者ＤＢのデータ構成の例について示した図である。 本発明の一実施の形態におけるインシデントに対する対応手順の取得処理の流れの例について概要を示したフローチャートである。 従来のインシデント管理システムにおける障害メッセージの取り扱いの例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。

＜概要＞
本発明の一実施の形態であるインシデント管理システムは、多数のサーバ等のコンピュータ機器からなるシステムに対して、その障害を監視する障害監視システムが障害事象を検知して出力した障害メッセージに基づいて、これをインシデントとして登録し、障害の内容等を記録するとともに、対応状況のステータス管理や、一次対応としての対応手順の検索、二次対応のための開発者等へのコール等、障害状況の管理および障害対応に係る作業の支援を行うシステムである。

図８は、従来のインシデント管理システムにおける障害メッセージの取り扱いの例について概要を示した図である。システムの障害を監視する障害監視システム３では、サーバ等の機器における障害の検知を起因として端末やコンソールなどのオペレータ画面に障害メッセージを出力する。この障害メッセージの情報は、図示しないが、自動もしくは手動によりインシデント管理システム１にインシデントとして登録され、対応状況のステータス管理などが行われる。

このとき、インシデント管理システム１では、例えば、予めデータベース等に登録・蓄積されている対応手順の中から対象の障害メッセージに対する対応手順があるか否かを検索して出力し、その内容をオペレータ等が一次対応として実施するということが行われる。対応手順は、例えば、各障害メッセージに対してシステムの開発者等が予め定義しておいた処理手順や、過去のインシデントにおける対応内容の履歴などが利用される。このような各障害メッセージに対する対応手順の情報を、例えば対応手順ＤＢ３１などのデータベースに保持しておき、これを対応手順検索部３０などのソフトウェアプログラムによって自動もしくは手動により検索することで、障害メッセージに対する一次対応としての対応手順を取得して出力する。

図８の例において、障害監視システム３のオペレータ画面に出力された障害メッセージのうち、障害メッセージ“ＡＡＡ”、および“ＸＸＸ”、“ＹＹＹ”、“ＺＺＺ”が、例えば“サーバａ”での１つの障害事象に起因して出力された一連の障害メッセージである（すなわち「関連性」がある）場合であっても、従来のインシデント管理システム１では、これらの障害メッセージの関連性を判断することができず、それぞれを個別の障害事象として取り扱う。すなわち、各障害メッセージについて個別にインシデントの登録が行われ、それぞれについて対応手順検索部３０により対応手順ＤＢ３１の検索が都度行われて、対応手順が個別に出力される。

この場合、例えば対応手順の検索を手動で条件を指定して柔軟に行う必要があるような場合には、オペレータ等の負荷が非常に大きくなる。また、個別に出力された各対応手順についてもオペレータ等がこれらの関連性を判断できないため、各対応手順を有機的に連携させて効率よく実行することができないというような場合も生じ得る。

そこで、本実施の形態であるインシデント管理システムでは、図２に示すように、各障害メッセージについて関連性のある障害メッセージ（以下では「関連障害メッセージ」と記載する場合がある）に係る情報を関連性ルールＤＢ２１などのデータベースに予め登録しておく。障害事象が発生し、障害監視システム３に出力された障害メッセージ（例えば“ＡＡＡ”）に基づいてインシデント管理システム１にインシデントとして登録され、これに対する一次対応としての対応手順を検索する際に、対象の障害メッセージ（“ＡＡＡ”）に対する関連障害メッセージ（例えば“ＸＸＸ”、“ＹＹＹ”、および“ＺＺＺ”）の情報を関連性判定部２０などのソフトウェアプログラムによって自動もしくは手動により関連性ルールＤＢ２１から取得する。

さらに、取得した関連障害メッセージが障害監視システム３において出力されているか否かを検索し、出力されている場合はこれらを１つの障害事象に起因して出力された一連の障害メッセージと判断し、元の障害メッセージ（“ＡＡＡ”）とまとめて取り扱う。これにより、一連の障害メッセージに対する対応手順についてもまとめて出力することが可能となる。また、必要に応じてインシデントとしてもまとめて管理することが可能となり、オペレータ等の負荷を軽減し、効率的・効果的な障害対応を行うことが可能となる。

＜システム構成＞
図１は、本実施の形態であるインシデント管理システムおよびこれを含む情報処理システムの構成例の概要について示した図である。図１において、情報処理システムは、例えばデータセンター等に配置され、多数のサーバ機器等からなるサーバ群２を有する。このサーバ群２は、例えば、業務アプリケーションを稼働させることでユーザにサービスを提供するサーバ機器や、クラウドコンピューティングサービスとしてユーザにコンピュータリソースを提供するサーバ機器等からなる。

このサーバ群２に対して、ＬＡＮ（Local Area Network）等の内部ネットワーク４を介して、サーバ群２の障害監視を行うコンピュータシステムである障害監視システム３、および障害事象をインシデントとして管理するコンピュータシステムであるインシデント管理システム１が接続されている。

障害監視システム３では図示しない障害監視プログラムが稼働し、サーバ群２での障害事象を検知して、オペレータ７に対して端末やコンソールのオペレータ画面上に障害メッセージを出力することで通知する。障害監視プログラムとしてはそれ以外の機能に特に限定はなく、ベンダー等から提供される一般的な障害監視・管理製品等を利用することができる。

インシデント管理システム１は、例えば、ソフトウェアプログラムによって実装されるインシデント登録部１０、関連性判定部２０、対応手順検索部３０、コール部４０、およびデータ管理部５０などの各部と、インシデントＤＢ１１、関連性ルールＤＢ２１、対応手順ＤＢ３１、および担当者ＤＢ４１などの各データベースを有する。なお、図示しないが、これら以外に当然にＯＳ（Operating System）やデータベース管理プログラムなどの各種ミドルウェアからなる基盤部なども有している。

インシデント管理システム１は、例えば、障害時の一次対応の判断や二次対応の依頼コールなどを含むインシデントの管理作業を専属で行うサポートデスク等の担当者であるコール担当者６の操作によって各種機能が実行される。このようなサポートデスク等を有さず、オペレータ７が直接操作する構成であってもよい。

インシデント登録部１０は、障害監視システム３が検知して出力した障害メッセージに基づいて、障害事象をインシデントとして管理するためにインシデントＤＢ１１に登録する。障害メッセージに基づくインシデントの登録は、インシデント管理システム１が障害監視システム３と連携して自動で行ってもよいし、コール担当者６もしくはオペレータ７がインシデント管理システム１によって提供されるインシデント管理用のユーザインタフェース（画面）を利用して手動で行ってもよい。

関連性判定部２０は、インシデント登録部１０によってインシデントＤＢ１１に登録されたインシデントに係る障害メッセージについて、関連性ルールＤＢ２１に予め登録された、各障害メッセージと関連性のある関連障害メッセージに係る情報を検索し、インシデントに係る障害メッセージに対する関連障害メッセージの情報を取得する。この情報に基づいて障害監視システム３における障害発生時近辺の所定の範囲（例えば、障害発生時の前後５分など）の障害メッセージの出力内容を検索し、関連障害メッセージが出力されているか否かを判定する。

関連障害メッセージが出力されている場合は、これらの障害メッセージの情報も合わせてインシデント登録部１０を介する等によりインシデントＤＢ１１の該当のレコードに追加して記録することで、これらをまとめて取り扱うことが可能である。なお、関連性の判定処理は、インシデント登録部１０によりインシデントＤＢ１１にインシデントが登録されたことをトリガとして自動で行ってもよいし、コール担当者６等による、インシデント管理システム１によって提供されるユーザインタフェースを利用した手動での指示に基づいて行ってもよい。

対応手順検索部３０は、予め対応手順ＤＢ３１に登録・蓄積されている障害内容毎の対応手順の中から、対象のインシデントに係る障害メッセージに対応する対応手順があるか否かを検索してコール担当者６等の画面等に出力する。関連性判定部２０によって１つにまとめられ、インシデントＤＢ１１に記録されている関連障害メッセージについては、それぞれについて同様に対応手順ＤＢ１１を検索して取得した対応手順を１つにまとめて出力する。なお、対応手順の検索処理は、インシデント登録部１０によりインシデントＤＢ１１にインシデントが登録され、もしくは関連性判定部２０により関連障害メッセージが検索されたことをトリガとして自動で行ってもよいし、コール担当者６等による、インシデント管理システム１によって提供されるユーザインタフェースを利用した手動での指示に基づいて行ってもよい。

コール部４０は、対象のインシデントについて担当者ＤＢ４１の情報に基づいて自動もしくはコール担当者６からの指示により設定された二次対応を行う開発者８等に対して障害内容を通知する。通知に際しては、例えば、社内のネットワーク５を介して開発者８等に電子メールを送信する。コール担当者６等が電話や他の手段で開発者８等にコールする構成であってもよい。

データ管理部５０は、関連性ルールＤＢ２１、対応手順ＤＢ３１、および担当者ＤＢ４１など、予めデータを登録・更新しておく必要があるデータベースに対してそのためのユーザインタフェースを提供する。インタフェースについては特に限定されず、登録・更新用のデータ入力画面を提供するものであってもよいし、ファイルによるインポート等により登録・更新するものであってもよい。

＜データ構成＞
以下では、インシデント管理システム１における各データベースのデータ構成について説明する。図３は、インシデントＤＢ１１のデータ構成の例について示した図である。インシデントＤＢ１１は、障害監視システム３が検知して出力した障害メッセージに基づいて、障害事象をインシデントとして登録し管理するテーブルであり、例えば、インシデントＩＤ、件名、発生日時、受付日時、連絡日時、完了日時、受付担当者、二次対応担当者、対象システム、障害ノード、障害メッセージ、障害メッセージ日時、関連障害メッセージ、関連障害メッセージ日時、受付状況、障害状況、適用対応手順ＩＤ、対応内容、更新者、および更新日時などの項目を有する。キー項目はインシデントＩＤである。

インシデントＩＤの項目は、例えばインシデント管理システム１のインシデント登録部１０によって障害メッセージに係る障害事象の管理を受け付けてインシデントとして登録する際に割り振られ、各インシデントを一意に識別することができるＩＤの情報を保持する。件名の項目は、対象のインシデントについての内容の把握を容易にするためにコール担当者６等により設定されたタイトルの情報を保持する。

発生日時、受付日時、連絡日時、および完了日時の項目は、それぞれ、対象のインシデントに係る障害事象が発生した日時（障害メッセージが出力された日時）、対象のインシデントの管理を受け付けた日時（インシデントとして登録した日時）、二次対応のために開発者８等に連絡を行った日時、および対象のインシデントについての対応を完了した日時の情報を保持する。受付担当者、および二次対応担当者の項目は、それぞれ、対象のインシデントの管理を受け付けたコール担当者６等、および二次対応を行う開発者８等を識別するユーザＩＤや氏名等の情報を保持する。対象システム、および障害ノードの項目は、それぞれ、対象のインシデントに係る障害事象が発生したシステム、およびノードを識別することができる名称やＩＤなどの情報を保持する。

障害メッセージ、および障害メッセージ日時の項目は、それぞれ、対象のインシデントに係る障害事象を障害監視システム３が検知して出力した障害メッセージを識別するＩＤ等の情報、および出力された日時の情報を保持する。また、関連障害メッセージ、および関連障害メッセージ日時の項目は、それぞれ、対象のインシデントに係る上記の障害メッセージについて関連性判定部２０によって検索された関連障害メッセージが障害監視システム３に出力されている場合に、その関連障害メッセージを識別するＩＤ等の情報、および出力された日時の情報を保持する。なお、関連障害メッセージに係る情報は複数保持できるようにする。これらにより、障害メッセージと関連障害メッセージを１つにまとめて取り扱うことが可能となる。

受付状況の項目は、対象のインシデントに係る障害事象の通知をコール担当者６（もしくはオペレータ７）等が受け付けた際の通知内容や経緯、連絡状況等の情報をメモとして保持する。また、障害状況の項目は、対象のインシデントに係る障害事象の内容や状況等の情報をテキストとして保持する。適用対応手順ＩＤ、および対応内容の項目は、それぞれ、対象のインシデントに係る障害メッセージについて対応手順検索部３０によって検索され、一次対応として実施した対応手順を識別するＩＤ等の情報、および具体的な対応内容のテキスト情報を保持する。これらのテキスト情報は、例えば、インシデント管理システム１によって提供されるユーザインタフェースを利用してコール担当者６等により入力される。

更新者、および更新日時の項目は、それぞれ、対象のインシデントに係るエントリの内容を更新したユーザ（コール担当者６やオペレータ７）を識別するＩＤ等の情報、および更新した日時の情報を保持する。なお、インシデントＤＢ１１に係る上記の各項目は一例であり、他のデータ構成によって該当の情報を管理するものであってもよいことは当然である。

図４は、関連性ルールＤＢ２１のデータ構成の例について示した図である。関連性ルールＤＢ２１は、障害監視システム３が出力する各障害メッセージについて、それに関連性のある関連障害メッセージに係る情報を関連性ルールとして登録し保持するテーブルであり、例えば、ルールＩＤ、障害メッセージ、サーバ種別、関連障害メッセージ、関連サーバ種別、差分時間範囲、更新者、および更新日時などの項目を有する。キー項目はルールＩＤである。

ルールＩＤの項目は、例えばインシデント管理システム１のデータ管理部５０が対象の関連性ルールを登録する際に割り振られ、各関連性ルールを一意に識別することができるＩＤの情報を保持する。障害メッセージ、およびサーバ種別の項目は、それぞれ、対象の関連性ルールに係る判定元の障害メッセージを識別するＩＤ等の情報、および当該障害メッセージに係る障害事象が発生するサーバ等の種別の情報を保持する。

関連障害メッセージ、関連サーバ種別、および差分時間範囲の項目は、それぞれ、対象の関連性ルールに係る上記の判定元の障害メッセージに対して関連性のある（同一の障害事象に起因して出力された一連の障害メッセージである）関連障害メッセージを識別するＩＤ等の情報、当該関連障害メッセージに係る障害事象が発生するサーバ等の種別、および当該関連障害メッセージが出力された日時と、対象の関連性ルールに係る判定元の障害メッセージが出力された日時との差分の時間範囲の情報を保持する。この差分時間範囲の項目については、対象の関連性ルールに係る判定元の障害メッセージが出力された日時から一定時間以上間隔が空いて出力された障害メッセージについては、もはや関連性がなく、別の障害事象に起因して出力されたものとして取り扱えるようにするため有している。なお、上記の関連障害メッセージに係る情報は複数保持できるようにする。

更新者、および更新日時の項目は、それぞれ、対象の関連性ルールに係るエントリの内容を登録・更新したユーザ（開発者８やコール担当者６等）を識別するＩＤ等の情報、および更新した日時の情報を保持する。なお、関連性ルールＤＢ２１に係る上記の各項目は一例であり、他のデータ構成によって該当の情報を管理するものであってもよいことは当然である。

図５は、対応手順ＤＢ３１のデータ構成の例について示した図である。対応手順ＤＢ３１は、障害監視システム３が出力する各障害メッセージなどによって識別される各障害内容について、これに対する一次対応としての対応手順に係る情報を登録し保持するテーブルであり、例えば、対応手順ＩＤ、種別、障害メッセージ、関連障害メッセージ、キーワード、対応システム、対応サーバ種別、対応手順、関連対応手順ＩＤ、更新者、および更新日時などの項目を有する。キー項目は対応手順ＩＤである。

対応手順ＩＤの項目は、例えばインシデント管理システム１のデータ管理部５０が対象の対応手順を登録する際に割り振られ、各対応手順を一意に識別することができるＩＤの情報を保持する。種別の項目は、対象の対応手順の種別に係る情報を保持する。この種別の内容としては、例えば、開発者等により予め定義された処理手順や、過去のインシデントにおける対応内容の履歴への参照、それらの履歴の分析等により得られたノウハウなどによる区分が考えられる。

障害メッセージ、関連障害メッセージ、およびキーワードの項目は、それぞれ、対象の対応手順が対応する障害メッセージおよび関連障害メッセージを識別するＩＤ等の情報、および検索のための１つ以上のキーワードを保持する。ある障害メッセージが単独で出力された場合と、関連障害メッセージとともに出力された場合とでは異なる対応手順となる場合も想定されるため、これらのＩＤ等の情報を対応手順検索部３０が対応手順を検索する際の複合的なキーとして取り扱えるようにする。さらに、障害事象に係る任意のキーワードを利用して検索できるようにすることで、障害メッセージや関連障害メッセージのＩＤ等の合致によらずとも類似するような障害事象についての対応手順を検索することが可能となる。

対応システム、および対応サーバ種別の項目は、それぞれ、対象の対応手順が対応するシステム、およびサーバ等の種別の情報を保持する。これらの項目は、異なる種別のサーバ機器等が同様の障害メッセージを出力したり、同一種別のサーバ機器でも稼働するシステムによって異なる対応手順をとったりする場合もあり、これらを判定可能とするため有している。対応手順、および関連対応手順ＩＤの項目は、それぞれ、対象の対応手順の内容についてのテキスト情報、およびこれに関連もしくは類似する他の対応手順がある場合の当該対応手順を識別する１つ以上のＩＤ等の情報を保持する。なお、障害発生時の時間帯に応じて対応手順が異なったり、サービス時間外等で対応不要となったりするような場合には、時間帯毎に複数の対応手順を登録可能なようにしてもよい。

更新者、および更新日時の項目は、それぞれ、対象の対応手順に係るエントリの内容を登録・更新したユーザ（開発者８やコール担当者６等）を識別するＩＤ等の情報、および更新した日時の情報を保持する。なお、対応手順ＤＢ３１に係る上記の各項目は一例であり、他のデータ構成によって該当の情報を管理するものであってもよいことは当然である。

図６は、担当者ＤＢ４１のデータ構成の例について示した図である。担当者ＤＢ４１は、システムに関係するユーザや担当者（コール担当者６やオペレータ７、開発者８など）に係るマスタ情報を保持するテーブルであり、例えば、ユーザＩＤ、担当者氏名、所属部署、所属チーム、電話番号、およびメールアドレスなどの項目を有する。キー項目はユーザＩＤである。

ユーザＩＤの項目は、例えばインシデント管理システム１のデータ管理部５０が対象の担当者を登録する際に割り振られ、もしくは他のユーザ管理システム等によって割り振られ、各担当者（もしくはユーザ）を一意に識別することができるＩＤの情報を保持する。担当者氏名、所属部署、および所属チームの項目は、それぞれ、対象の担当者の氏名、所属する部署、および所属するチームやグループなどの属性情報を保持する。さらに、担当するシステムやサーバなどの詳細な属性情報を有していてもよい。これらの情報に基づいて、コール部４０は、自動もしくはコール担当者６等からの指示に基づいて二次対応を依頼する開発者８等を決定することができる。

電話番号、およびメールアドレスの項目は、それぞれ、対象の担当者に対する連絡先の情報として、電話番号、および電子メールアドレスの情報を保持する。なお、担当者ＤＢ４１に係る上記の各項目は一例であり、他のデータ構成によって該当の情報を管理するものであってもよいことは当然である。

＜処理フロー＞
図７は、本実施の形態のインシデント管理システム１におけるインシデントに対する対応手順の取得処理の流れの例について概要を示したフローチャートである。障害監視システム３において障害事象を検知して障害メッセージが出力されると、まず、出力された障害メッセージに基づいて、インシデント管理システム１のインシデント登録部１０は、インシデントＤＢ１１にインシデントの情報を登録する（Ｓ０１）。

ここでは、上述したように、障害監視システム３とインシデント管理システム１が連携して自動で登録するように構成することも可能であるし、コール担当者６もしくはオペレータ７が手動で登録するように構成してもよい。またこのとき、対象の障害メッセージが、以前の他の障害メッセージに関連する関連障害メッセージであるとして、既にインシデントＤＢ１１に登録され処理されている場合もある。この場合はそのまま処理を終了するようにしてもよい。

ステップＳ０１でのインシデント情報の登録の際もしくは登録の後、自動もしくはコール担当者６等による指示に基づいて、関連性判定部２０は、登録されたインシデントに係る障害メッセージについて関連性ルールＤＢ２１を検索し、当該インシデントに係る障害メッセージについての関連障害メッセージの情報（関連性ルール）を取得する（Ｓ０２）。さらに、関連性判定部２０は、障害監視システム３における障害発生時近辺の障害メッセージの出力内容を検索し（Ｓ０３）、取得した関連性ルールの条件に合致する関連障害メッセージが出力されているか否かを判定する（Ｓ０４）。

ステップＳ０４において、障害メッセージのＩＤやサーバ種別、差分時間などの関連性ルールの条件が合致する関連障害メッセージが出力されている場合は、当該関連障害メッセージの情報をインシデント登録部１０を介してインシデントＤＢ１１の対象のインシデントのエントリに登録し（Ｓ０５）、次の処理に移る。上述したように、これにより障害メッセージと関連障害メッセージとを１つにまとめて取り扱うことが可能となる。ステップＳ０４において条件に合致する関連障害メッセージが出力されていない場合は、そのまま次の処理に移る。

次に、対応手順検索部３０は、自動もしくはコール担当者６等による指示に基づいて、まとめて取り扱われる障害メッセージ、すなわち、登録されたインシデントに係る障害メッセージ、およびステップＳ０５で登録した各関連障害メッセージについて処理を繰り返すループ処理を実行する。当該ループ処理では、対応手順検索部３０は、対象の障害メッセージについて対応手順ＤＢ３１を検索し、該当する対応手順の情報を取得する（Ｓ０６）。

なお、図７の例では、当該ループ処理において、各障害メッセージ（および関連障害メッセージ）について個別にステップＳ０６にて対応手順を取得するものとしているが、上述の図５において示したように、ある障害メッセージが単独で出力された場合と、関連障害メッセージとともに出力された場合とでは異なる対応手順となる場合も想定される。従って、当該ループ処理において、まず障害メッセージまたは関連障害メッセージを組み合わせた複合的なキーとして対応手順ＤＢ３１を検索し、該当する対応手順の情報を取得するようにしてもよい。

例えば、図２に示すような障害メッセージが出力された場合、まず、（“ＡＡＡ”“ＸＸＸ”“ＹＹＹ”“ＺＺＺ”）をキーとして対応手順ＤＢ３１を検索する。対応手順が得られればループ処理を終了する。対応手順が得られなければ、次に、（“ＡＡＡ”“ＸＸＸ”“ＹＹＹ”）および“ＺＺＺ”と、（“ＡＡＡ”“ＸＸＸ”“ＺＺＺ”）および“ＹＹＹ”と、（“ＡＡＡ”“ＹＹＹ”“ＺＺＺ”）および“ＸＸＸ”と、（“ＸＸＸ”“ＹＹＹ”“ＺＺＺ”）および“ＡＡＡ”との４とおりのキーの組を作成して、キーの組毎に対応手順ＤＢ３１を検索する。例えば、（“ＡＡＡ”“ＸＸＸ”“ＹＹＹ”）および“ＺＺＺ”というキーの組について、（“ＡＡＡ”“ＸＸＸ”“ＹＹＹ”）についての対応手順と、“ＺＺＺ”についての対応手順とのいずれもが得られたなど、いずれかのキーの組について、キーの組を構成する各キーの対応手順がそれぞれ得られた場合にはループ処理を終了する。

いずれかのキーの対応手順が得られない場合は、次に、（“ＡＡＡ”“ＸＸＸ”）および（“ＹＹＹ”“ＺＺＺ”）などのキーの組を作成して、キーの組毎に対応手順ＤＢ３１を検索し、いずれかのキーの組について、キーの組を構成する各キーの対応手順がそれぞれ得られた場合にはループ処理を終了する。いずれかのキーの対応手順が得られない場合は、次に、（“ＡＡＡ”“ＸＸＸ”）、“ＹＹＹ”および“ＺＺＺ”などのキーの組を作成して、同様にキーの組毎に対応手順ＤＢ３１を検索し、いずれかのキーの組について、キーの組を構成する各キーの対応手順がそれぞれ得られた場合にはループ処理を終了する。いずれかの対応手順が得られない場合は、上述の通り、各障害メッセージ(および関連障害メッセージ)である“ＡＡＡ”、“ＸＸＸ”、“ＹＹＹ”、“ＺＺＺ”について個別に対応手順を検索する。

全ての障害メッセージについて対応手順を取得する処理を繰り返すとループ処理を終了し、取得した対応手順を１つにまとめてインシデント管理システム１が提供するユーザインタフェースを介して一次対応手順の内容として出力し（Ｓ０７）、処理を終了する。これにより、コール担当者６やオペレータ７は、関連障害メッセージ毎にインシデントとしての登録や対応手順の検索処理を個別に行うことなく障害対応を行うことができる。

以上に説明したように、本発明の一実施の形態であるインシデント管理システム１によれば、各障害メッセージについて関連性のある関連障害メッセージに係る情報を予め関連性ルールＤＢ２１に登録しておく。障害事象が発生し、障害監視システム３に出力された障害メッセージに基づいてインシデント管理システム１のインシデント登録部１０がインシデントＤＢ１１にインシデントとして登録する際に、関連性判定部２０によって自動もしくは手動により関連性ルールＤＢ２１から対象の障害メッセージに対する関連障害メッセージに係る情報を検索して取得する。

さらに、取得した関連障害メッセージが障害監視システム３において出力されているか否かを検索し、出力されている場合はこれらを１つの障害事象に起因して出力された一連の障害メッセージと判断し、インシデントＤＢ１１に登録する。これにより、１つのインシデントについて関連性のある一連の障害メッセージをまとめて取り扱うことが可能となる。さらに、まとめて取り扱われる一連の障害メッセージに対する対応手順についてもまとめて取得して出力することが可能となり、オペレータ７やコール担当者６等の負荷を軽減し、効率的・効果的な障害対応を行うことが可能となる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

本発明は、障害検知からの対応実施の支援や対応状況の管理などを行うインシデント管理システムおよびこれに用いられるインシデント管理プログラムに利用可能である。

１…インシデント管理システム、２…サーバ群、３…障害監視システム、４…内部ネットワーク、５…ネットワーク、６…コール担当者、７…オペレータ、８…開発者、
１０…インシデント登録部、１１…インシデントＤＢ、
２０…関連性判定部、２１…関連性ルールＤＢ、
３０…対応手順検索部、３１…対応手順ＤＢ、
４０…コール部、４１…担当者ＤＢ、
５０…データ管理部。

Claims (4)

1. 多数のコンピュータ機器からなる情報処理システムに対して、その障害を監視する障害監視システムが前記コンピュータ機器の障害事象を検知して出力した障害メッセージに基づいて、これをインシデントとして登録して障害状況の管理および障害対応に係る作業の支援を行うインシデント管理システムであって、
   前記障害監視システムが出力した障害メッセージに基づいて、障害事象をインシデントとしてインシデント記録手段に登録するインシデント登録部と、
   前記インシデント登録部によって前記インシデント記録手段に登録されたインシデントに係る障害メッセージについて、関連性ルール記録手段に予め登録されている、各障害メッセージとその障害事象に起因して出力される一連の障害メッセージである関連障害メッセージに係る情報を検索し、対象のインシデントに係る障害メッセージに対する関連障害メッセージの情報を取得し、取得した関連障害メッセージの情報に基づいて、前記障害監視システムにおける障害発生時近辺の所定の範囲の障害メッセージの出力内容を検索し、取得した関連障害メッセージが出力されている場合は、出力されている関連障害メッセージの情報を前記インシデント記録手段に登録された対象のインシデントの情報に追加して記録する関連性判定部とを有することを特徴とするインシデント管理システム。
2. 請求項１に記載のインシデント管理システムにおいて、
   さらに、対応手順記録手段に予め登録されている障害内容毎の対応手順の中から、対象のインシデントに係る障害メッセージおよび前記インシデント記録手段に記録された関連障害メッセージに対する対応手順の有無をそれぞれ検索し、取得した各対応手順をまとめて出力する対応手順検索部を有することを特徴とするインシデント管理システム。
3. 多数のコンピュータ機器からなる情報処理システムに対して、その障害を監視する障害監視システムが前記コンピュータ機器の障害事象を検知して出力した障害メッセージに基づいて、これをインシデントとして登録して障害状況の管理および障害対応に係る作業の支援を行うインシデント管理システムとしてコンピュータを動作させるインシデント管理プログラムであって、
   前記障害監視システムが出力した障害メッセージに基づいて、障害事象をインシデントとしてインシデント記録手段に登録するインシデント登録処理と、
   前記インシデント登録処理によって前記インシデント記録手段に登録されたインシデントに係る障害メッセージについて、関連性ルール記録手段に予め登録されている、各障害メッセージとその障害事象に起因して出力される一連の障害メッセージである関連障害メッセージに係る情報を検索し、対象のインシデントに係る障害メッセージに対する関連障害メッセージの情報を取得し、取得した関連障害メッセージの情報に基づいて、前記障害監視システムにおける障害発生時近辺の所定の範囲の障害メッセージの出力内容を検索し、取得した関連障害メッセージが出力されている場合は、出力されている関連障害メッセージの情報を前記インシデント記録手段に登録された対象のインシデントの情報に追加して記録する関連性判定処理とを実行することを特徴とするインシデント管理プログラム。
4. 請求項３に記載のインシデント管理プログラムにおいて、
   さらに、対応手順記録手段に予め登録されている障害内容毎の対応手順の中から、対象のインシデントに係る障害メッセージおよび前記インシデント記録手段に記録された関連障害メッセージに対する対応手順の有無をそれぞれ検索し、取得した各対応手順をまとめて出力する対応手順検索処理を実行することを特徴とするインシデント管理プログラム。