(57)【要約】【課題】運用管理システム（インシデント管理システム）に係わり、対象システムの特性や状況などに応じて効率的な対応を実現できる技術を提供する。【解決手段】本インシデント管理システム１０では、対象システム１で発生したインシデントの情報（対象システム１の特性や状況の情報を含む）を取得する。対応情報取得部３０は、そのインシデントについて、既知のインシデントの情報に該当するかどうかを、ＤＢ５０に格納されている情報を検索することにより判定し、既知のインシデントに該当する場合、当該既知のインシデントについての対応手順を含む対応情報を取得して出力する。また対応情報取得部３０は、上記検索結果に基づき、対象システム１の特性や状況、サービスレベル等から、適切な対応手順を導出する。そして、本システムは、上記対応情報等を、対応者（Ｕ１，Ｕ２）の端末に表示または通知する。【選択図】図１
2011076161.tif 000002
【特許請求の範囲】
【請求項１】
対象システムを運用管理するシステムの構成要素であり前記対象システムのインシデントを管理する処理をコンピュータを用いて行うインシデント管理システムであって、
前記対象システムで発生したインシデントの情報をもとに、データベースに格納されている既知のインシデントの情報を自動的に検索し、当該発生したインシデントが既知のインシデントに該当するかどうかを判定し、該当する既知のインシデントの対応手順を含む情報を取得し、前記発生したインシデントに適用するための情報として出力する処理を行うこと、を特徴とするインシデント管理システム。
【請求項２】
請求項１記載のインシデント管理システムにおいて、
前記対象システムで発生した第１のインシデントを検知し、当該対象システムの特性または状況の情報を含む当該第１のインシデントの情報を取得して、既知のインシデントの情報としてデータベースに格納し、当該第１のインシデントの情報を、対応者の端末に表示または通知する、第１の処理部と、
前記第１のインシデントの情報をもとに、前記データベースに格納されているインシデントの情報を自動的に検索することにより、当該第１のインシデントが既知のインシデントに一致または類似するかどうかを判定し、一致または類似する既知の第２のインシデントの対応手順を含む対応情報を、前記第１のインシデントの前記対象システムの特性または状況の情報に応じて導出または選択し、前記第１のインシデントに適用するための情報として出力する、第２の処理部と、
前記第１のインシデントに適用するための情報を、前記対応者の端末に表示または通知する、第３の処理部と、
前記対応者の操作に基づき、前記対象システムで発生したインシデントの情報及びそれに関連付けられる対応手順を含む対応情報と、未発生であっても想定されるインシデントの情報及びそれに関係付けられる対応手順を含む対応情報とを、前記データベースに前記既知のインシデントの情報として登録する、第４の処理部と、を有すること、を特徴とするインシデント管理システム。
【請求項３】
請求項２記載のインシデント管理システムにおいて、
前記第２の処理部は、前記第１のインシデントに関する発生日時及び発生部位を含む情報に応じて、前記第２のインシデントの対応手順と、当該対応手順の実行及び完了に係わる目標時間の情報と、を導出または選択し、前記対応情報として出力すること、を特徴とするインシデント管理システム。
【請求項４】
請求項２記載のインシデント管理システムにおいて、
前記対象システムは、日時及び部位に応じたサービスレベルの情報が規定されており、
前記第２の処理部は、前記第１のインシデントに関する前記サービスレベルの情報に応じて、前記第２のインシデントの対応手順と、当該対応手順の実行及び完了に係わる目標時間の情報と、を導出または選択し、前記対応情報として出力すること、を特徴とするインシデント管理システム。
【請求項５】
請求項２記載のインシデント管理システムにおいて、
前記第４の処理部は、前記対応者の操作に基づき、前記データベースに前記インシデント情報及び対応情報を登録する際、インシデントの関係における同件の関係を判定するためのキー情報を登録し、
前記第２の処理部は、前記キー情報を参照して検索することにより、前記第１のインシデントに対して同件と判定される前記第２のインシデントの情報を得ること、を特徴とするインシデント管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システムを対象とする運用管理システムなどの技術に関し、特に、対応者及びコンピュータにより行われるインシデント管理の技術に関する。
【背景技術】
【０００２】
従来技術例の運用管理システム（その構成要素であるインシデント管理システム）において、対象システムにおけるインシデント（エラーや障害、問題の問い合わせ等）が発生した際、サービスデスク（そのオペレータ）などの対応者は、そのインシデントが既知のインシデントに該当するかどうかについて、手動操作に基づきデータベース（既知のインシデントの情報が格納されている）からの検索処理を行って判断している。既知のインシデントとは、過去に発生したインシデント、あるいは過去に発生していなくとも想定済みのインシデントなどである。検索結果で該当したインシデント（その情報）がある場合、対応者は、該当したインシデントに関係付けられる対応手順（例えば障害状態からのシステム復旧等の手順）の情報を参照し、それに従った対応（インシデントレスポンス、例えばシステム復旧等）を実行または指示している。
【０００３】
対象システムとして例えば証券システムにおいては、業務（例えば株式情報提供サービス）を含むシステムの特性や状況として、例えば日時に関する特性や状況（営業日、サービス時間、場など）、構成要素（サーバなど）及びその重要性や稼働等の状況（利用者数など）、予め定められるサービスレベル（例えば可用性）、等があり、リアルタイムに変動する。
【０００４】
従って、上記対象システムの特性や状況などに応じて、インシデント発生の際の対応に関する、要求される対応手順や、その緊急性や重要性やインパクトなどが大きく異なってくる。例えば、証券システムにおける、場中、利用者数が多い状況で、銘柄検索サービスを提供するシステム（サーバ）での障害の時には、対応（復旧など）の緊急性や重要性などが高い。
【０００５】
インシデント管理システムに関する先行技術例としては、特開２００８−１２９９７３号公報（特許文献１）などがある。この技術例では、システムのインシデントに対応する、サービスデスクのオペレータ、システムの開発者、運用担当者などにおける、インシデント処理（業務工程）の管理において、インシデントの重要度を考慮、具体的にはインパクト（インシデント処理の優先順位を決定するための指標）を算出する旨が記載されている。
【０００６】
上記のような従来技術は、コンピュータにより自動的に過去（既知）のインシデント情報を考慮して対応を決定する技術ではない。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００８−１２９９７３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
前述のように、従来技術例の運用管理システム（インシデント管理システム）では、対象システムのインシデントに対して、対応者が手動で情報を検索して判断し対応を図っており、対応の効率性などが不十分である。
【０００９】
また前述のように、対象システムの特性や状況などに応じて、インシデントへの対応に要求される対応手順などの条件が異なってくる場合があるが、従来では、このような異なり（変動）を考慮したシステムではなく、このような場合における対応の効率性などが不十分である。
【００１０】
以上を鑑み、本発明の主な目的は、運用管理システム（インシデント管理システム）に係わり、対象システムの特性や状況などに応じて効率的な対応を実現できる技術を提供することである。
【課題を解決するための手段】
【００１１】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、次の通りである。
【００１２】
本発明のシステム（インシデント管理システム）は、対象システム（証券システム等）のインシデントの発生及びその検知に際して、対象システムの特性及び状況などのリアルタイムの変動などに応じた適合的なインシデント対応情報を、データベースに格納されている既知のインシデント（過去に発生したインシデントや、未発生であっても想定されるインシデント）の情報の参照・検索に応じて、自動的に取得し出力する。
【００１３】
本システムの形態は、例えば、対象システムを運用管理するシステムの構成要素であり対象システムのインシデントを管理する処理をコンピュータを用いて行うインシデント管理システムであって、対象システムで発生したインシデントの情報をもとに、データベースに格納されている情報（インシデント及び対応に関する管理情報）を自動的に検索し、当該発生したインシデントが既知のインシデントに該当（一致または類似）するかどうかを判定し、該当する既知のインシデントの対応手順等を含む情報を取得し、取得した情報を、発生したインシデントに適用するための情報として出力し、対応者の端末へ表示または通知等する処理を行う。
【発明の効果】
【００１４】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下の通りである。本発明によれば、運用管理システム（インシデント管理システム）に係わり、対象システムの特性や状況などに応じて効率的な対応を実現できる。
【図面の簡単な説明】
【００１５】
【図１】本発明の一実施の形態のシステム（インシデント管理システムを含む情報処理システム）の全体の構成を示す図である。
【図２】本システムで扱う情報データの概要を示す図である。
【図３】本システムにおけるデータベースの管理情報テーブル（インシデント情報、対応情報）の例（その１）を示す図である。
【図４】本システムにおけるデータベースの管理情報テーブル（インシデント情報、対応情報）の例（その２）を示す図である。
【図５】本システムにおけるデータベースの管理情報テーブル（（ａ）サービスレベル、（ｂ）場）の例を示す図である。
【図６】本システムにおける対応情報取得処理フロー例を示す図である。
【図７】本システムにおけるインシデント例における関係等を示す図である。
【図８】本システムにおける表示情報（インシデント情報、対応情報）の例（その１）を示す図である。
【図９】本システムにおける表示情報（インシデント情報、対応情報）の例（その２）を示す図である。
【図１０】本システムにおける表示情報（インシデント情報、対応情報）の例（その３）を示す図である。
【発明を実施するための形態】
【００１６】
以下、図面（図１〜図１０）に基づいて、本発明の一実施の形態のシステム（インシデント管理システム及びそれを含んで成る運用管理システム）について詳細に説明する。本システムで特徴的な構成は、特に、図１の対応情報取得部３０及びＤＢ５０である。対応情報取得部３０は、対象システム１での発生インシデント及びその時の特性や状況などに適合した対応情報（対応手順及び目標時間などを含む）を、ＤＢ５０に蓄積されている既知のインシデント情報５１（及び対応情報）を自動的に参照・検索することにより導出・取得し、対応者（Ｕ１，Ｕ２）へ出力する処理を行う。
【００１７】
＜システム＞
図１において、本システムの全体の構成を示している。全体は、対象システム１と運用管理システム２とを有する。運用管理システム２は、インシデント管理システム１０と、対応者及び対応システム３とを含んで成る。各システム間は通信接続される。Ａ１等は通信アクセスや動作や情報データの流れを示す。
【００１８】
対象システム１は、運用管理システム２による運用管理、及びインシデント管理システム１０によるインシデント管理の対象となる情報処理システムであり、ユーザＵ０（顧客等）が使用、運営する。対象システム１は、例えば証券システムであり、株式情報提供サイトなどを含む。対象システム１は、１つ以上のシステム（サービス）２０２を構成するサーバ２０３群などを有する。システム（サービス）２０２は例えば銘柄検索システム（サービス）である。サーバ２０３は当該サービスを提供する処理を行うプログラム等を備える。
【００１９】
システム（サービス）２０２の動作・履歴情報は、ログ２０１（ログファイル）に記録される。ログ２０１を参照することにより、インシデント、及びインシデントに関係する対象システム１の特性や状況、サービスレベル等の各種情報（図２）も取得または判定できる。また対象システム１は、所定のサービスレベルが設定されている（後述、図５）。サービスレベルは、対象システム１の部位（構成要素）や日時などの特性に応じて規定される。本システムは、対象システム１のサービスレベルについても、対応情報の取得の際の計算に考慮する。なお、インシデントは、対象システム１における各種の不具合、エラー、障害、性能劣化、それらの可能性、問い合わせ等によるものを含む。インシデントは、対象システム１での所定のサービスレベルを満たしたサービスの提供を阻害するものである。
【００２０】
対応者及び対応システム３は、対象システム１のインシデントに対する対応（Ａ１３）を行う対応者（Ｕ１，Ｕ２）、及び当該対応者が使用する情報処理システムである。例えばＰＣや携帯電話機などのコンピュータ端末（Ｗｅｂブラウザ等を備える）及びそれらを接続する通信ＬＡＮなどである。
【００２１】
第１の対応者Ｕ１は、例えばサービスデスクのオペレータであり、インシデントの発生・検知時や、ユーザＵ０（対象システム１）からの電話等による問い合わせ等（Ａ１１）を受けた時に、すぐに対応（問い合わせ回答や連携など）を行う者（１次対応者）である。Ｕ１は、例えば、業務時に常時、端末の画面の表示（画面表示部２０により提供されるＷｅｂ画面（Ｗｅｂページ）等）を閲覧して対応に備えている（Ａ３ａ）。問い合わせ等（Ａ１１）に対し、Ｕ１のレベルで対応（解決）ができない場合、Ｕ２へ対応の連携（エスカレーション）が行われる（Ａ１２）。
【００２２】
第２の対応者Ｕ２は、例えば対象システム１の開発者や運用者であり、通常は所定の業務を行っており、必要時、即ち本システムやＵ１からの通知（Ａ９ｂ，Ａ１２）等を受けて、対応を行う者（２次対応者）である。開発者は、対象システム１の構成要素（システム２０２、サーバ２０３やそのプログラム等）の開発者である。運用者は、対象システム１の構成要素の保守・運用業務の担当者である。Ｕ２は、例えば、Ｕ１のように端末の画面の表示をリアルタイムで閲覧すること（Ａ３ａ）はしておらず、上記通知によってインシデントや対応の必要性を認識する。
【００２３】
インシデント管理システム１０は、検知部（インシデント取得部）１１、対応情報取得部３０（検索部（インシデント検索部）１２、導出部（対応情報導出部）１３）、画面表示部２０（インシデント情報表示部２１、対応情報表示部２２）、対応情報通知部２３、登録部４０、ＤＢ（データベース）５０などを有する。各処理部は、サーバ等の装置やプログラム等により構成され、処理部間で情報データを通信する。
【００２４】
ＤＢ５０には、インシデント情報５１や対応情報を含む必要な管理情報が統合管理されている（後述、図２のテーブル６０等）。インシデント情報５１は、既知のインシデントの情報であり、過去に発生・取得したインシデントの情報（ＩＡ）や、過去に発生していなくとも想定済みのインシデントの情報（ＩＢ）などを含む。ＩＡは、本システム（検知部１１）を通じてコンピュータにより自動的に取得・格納される情報である。ＩＢは、登録部４０を通じて対応者（Ｕ２等）により手動で登録・編集される情報である。いずれの情報（ＩＡ，ＩＢ）も検索等の対象となる。インシデント情報５１に対しては、対応情報（インシデント対応情報）が関係付けられて管理される。本実施の形態では、インシデント情報５１の中（属性）に対応情報を含めて管理する形であるが、別個に管理する形でもよい。
【００２５】
検知部１１は、対象システム１から、ログ２０１等の定期的な監視によりインシデントの発生を検知し（Ａ１）、当該発生インシデントについてのインシデント情報を取得する（Ａ２）。ここで取得する情報は、その時点の対象システム１の特性や状況を示す情報（ログメッセージ、発生日時、発生部位など）を含む。なお、インシデント情報の中（属性）に、それらの特性や状況などの情報も含めて管理する。検知部１１は、取得したインシデント情報を、画面表示部２０のインシデント情報表示部２１に渡す（Ａ３）。また検知部１１は、取得したインシデント情報を、ＤＢ５０に格納する（Ａ４、ＩＡ）。
【００２６】
また検知部１１は、対象システム１から直接的に上記インシデント情報を取得する以外にも、対応者及び対応システム３を経由して、同様にインシデント情報を取得してもよい（Ａ１４）。例えば、ユーザＵ０から対応者Ｕ１への問い合わせ等（Ａ１１）によるインシデントを検知部１１へ通知してもよい。
【００２７】
画面表示部２０は、対応者Ｕ１の端末に対して、インシデント情報５１及び対応情報等をＷｅｂ画面（Ｗｅｂページ）等の形で表示する情報を提供する（後述、図８〜図１０）。インシデント情報表示部２１は、検知部１１からの情報（Ａ３）に基づき、現在の発生インシデントに関するインシデント情報の画面（例えば図８のインシデント情報（１））を作成、表示する。対応者（Ｕ１，Ｕ２）は、当該画面を閲覧すること（Ａ３ａ，Ａ３ｂ）により現在の発生インシデントを認識できる。当該画面表示等と共に、対応情報取得部３０へ連携が行われる（Ａ５）。
【００２８】
対応情報取得部３０は、現在の発生インシデントに対して、自動的にＤＢ５０の情報を参照・検索して、当該インシデントに関係するリアルタイムの対象システム１の状況等に適合した対応情報を導出・取得する処理を行う（後述、図６）。
【００２９】
検索部１２は、検知部１１からの発生インシデントの情報（Ａ５）に基づき、ＤＢ５０のインシデント情報５１の検索処理を行う（Ａ６）。検索部１２は、発生インシデントの情報を検索キー（照合元）として用い、ＤＢ５０内の既知のインシデント情報５１（ＩＡ，ＩＢを含む）（照合先）を検索して照合する。これにより、発生インシデントが既知のインシデントに該当（一致または類似）するかどうかを判定する。該当する場合、検索部１２は、導出部１３へ連携し、該当したインシデント（候補）の情報を含む検索・判定結果情報を導出部１３へ渡す（Ａ７）。
【００３０】
導出部１３は、検索部１２からの情報（Ａ７）、即ち、発生インシデント（その時の対象システム１の特性や状況などの情報を含む）及び該当インシデントの情報に基づき、その時の対象システム１の特性や状況やサービスレベル等に応じた、適切な対応手順等を導出または選択する処理を行う。導出部１３は、上記情報（Ａ７）及びＤＢ５０の情報等を利用して計算などを行うことにより、当該対応手順等を含んだ対応情報を取得する（Ａ８）。導出部１３は、発生インシデントに関する対応情報を、画面表示部２０の対応情報表示部２２及び対応情報通知部２３へ出力する（Ａ９）。
【００３１】
導出部１３では、少なくとも対応手順の情報、それに加えて、目標時間やインパクト等の情報を導出する。対応手順に対して、目標時間等の情報を関連付けて出力する。または、対応手順の決定に際して、目標時間等の情報を反映して決定する。導出部１３は、該当インシデント（候補）の対応手順等について、発生インシデントに適用する対応手順等として適切かどうかを判断する。即ち、導出部１３は、発生インシデントに係わる対象システム１の特性や状況、サービスレベル等の情報を確認し、当該対応手順に関する目標時間等を導出し、それらを照らし合わせて上記適切性を判断し、適用する対応手順等を決定する。
【００３２】
対応情報表示部２２は、導出部１３からの情報（Ａ９）をもとに、発生インシデントに関する対応情報の画面（例えば図８のインシデント対応手順（１））を表示する（Ａ９ａ）。対応者（Ｕ１等）は、当該画面を閲覧することにより発生インシデントに対する対応手順などを認識できる。
【００３３】
対応情報通知部２３は、開発者等の連携先の対応者Ｕ２の端末へ、発生インシデントに関するインシデント情報及び対応情報などを、電子メールや電話などの手段によって通知する（Ａ９ｂ）。通知情報は、例えば画面表示部２０（２１，２２）でのＷｅｂ画面情報と同様のものでもよいし、その表示情報を閲覧させる指示情報などでもよい。対応者（Ｕ２等）は、当該通知によって、発生インシデント及び実行すべき対応手順などを認識できる。なお、上記インシデント情報及び対応情報の表示や通知については、２種の対応者（Ｕ１，Ｕ２）の両方へ行っても構わない。
【００３４】
登録部４０（インシデント及び対応情報登録部）は、対応者（Ｕ１，Ｕ２）の手動入力操作に基づき、インシデント情報５１及びその属性としての対応情報を、ＤＢ５０（ＩＢ）に登録する処理を行う（Ａ１５）。登録部４０は、例えば、その登録のユーザインタフェース画面を提供する。この登録においては、開発者等の対応者Ｕ２は、実際に発生したインシデント（例えば障害）に対して実行した対応の対応手順（例えばシステム復旧手順）等の情報を、自由に登録及び編集することができる。また、発生していなくても想定されるインシデント及び対応手順等の情報を、予め登録及び編集することができる。想定されるものとして例えばサーバ２０３のプログラムから開発者が予見できるエラー及びその対応のスクリプト等がある。
【００３５】
また登録部４０からは、対応者により、インシデント同士を同件に指定（判定）するための同件キー等のキー情報（後述）を、インシデント情報５１の属性として登録・編集することができる。インシデントの対応の実績をもとに当該キー情報を登録しておけば、次回以降、検索部１２による検索処理で当該キー情報を用いて判定することにより、一致するインシデント（同件）を高速に取得することができる。
【００３６】
＜インシデント−対応手順＞
下記は、対応情報取得部３０において、発生インシデントに対し、対象システム１の特性や状況等に適合した対応手順等の対応情報を出力する場合の一例を示す。インシデントに関する発生部位、発生日時、稼働や障害の状況などに応じて、対応手順が異なってくる例である。
【００３７】
（例１）  インシデントとして、対象システム１における冗長化されている箇所（例えばシステム２０２のサーバ２０３）のハードウェア障害が発生した場合。この場合、インシデントの発生日時が所定の日時特性である［場中］に該当する場合には、対応手順ａとして、当該箇所のハードウェア交換をせずに、システム２０２の稼働を続け、重点的に当該箇所の監視を続ける。また、［場中以外］に該当する場合には、対応手順ｂとして、システム２０２を停止し、当該箇所のハードウェア交換をする。
【００３８】
（例２）  インシデントとして、対象システム１における所定箇所のアプリケーションのバグ（エラー）が発見された場合。この場合、インシデントの発生日時が所定の日時特性である［場中］に該当する場合には、対応手順ｃとして、システム２０２を停止することはできないので、該当する処理（当該バグ（エラー）により引き起こされる処理）が発生した場合に対応者により手動で当該データの書き換えをする。また、［場中以外］に該当する場合には、対応手順ｄとして、当該エラー箇所を修正し、当該アプリケーションのサービスの再起動を行う。
【００３９】
本システムでは、上記例のように、発生インシデントに関する対象システム１の特性や状況に応じた対応情報（例えば対応手順ａ〜ｄ）を選択可能なように、対応情報取得部３０の処理、及びＤＢ５０の情報が構成されている。例えば対応者により上記例に応じたインシデント及び対応情報をＤＢ５０（ＩＢ）に登録可能であり、対応情報取得部３０により上記状況等に応じて自動的に選択される。
【００４０】
＜目標時間、インパクト等＞
目標時間、インパクト等の例について説明する。対応情報取得部３０では、発生インシデント及びそれに関連する対象システム１の特性や状況等に基づき、対応手順等（対応情報）を決定する際、発生インシデント及び特性や状況等によるインパクト（影響）の違いが存在する場合、それを考慮・反映して当該対応情報を決定することができる（ＤＢ５０情報及び対応情報取得部３０の処理により自動的に実現される）。
【００４１】
前述のように、対象システム１の特性や状況などに応じて、インシデント発生の際の対応に関する、要求される対応手順や、その緊急性や重要性やインパクトなどが大きく異なってくる。これに対し、本システムでは、例えばインシデントの発生日時（日時特性）等によって当該インシデントのインパクトが異なることを考慮・反映して、対応情報（例えば対応手順と目標時間）を決定することができる。このような例について以下である。
【００４２】
（例１）  対象システム１（証券システム）のシステム２０２等において障害（ＩＡ）が発生し、その時点（発生日時）では、この障害（ＩＡ）が影響を与えるアプリケーション（サーバ２０３のプログラム等）は稼働していない場合。例えばその発生日時が［場中以外］に該当する場合である。この場合、この障害（ＩＡ）による影響は無い又は少ない（インパクトが小さい）と判断できる。よって、この事を考慮した内容の対応手順及びその目標時間（緊急性などが小さい）が導出される。例えば、次に［場中］（上記アプリケーションが稼働する時間）になるまでの時間の余裕に応じて目標時間を遅めにすることができる。
【００４３】
（例２）  対象システム１（証券システム）のシステム２０２等において障害（ＩＡ）が発生し、その時点（発生日時）がピーク時間帯であり、この障害（ＩＡ）が影響を与えるアプリケーション（サーバ２０３のプログラム等）が稼働している場合。例えばその発生日時が［場中］、あるいは利用者数が所定値以上、等に該当する場合である。この場合、この障害（ＩＡ）による影響は大きい（インパクトが大きい）と判断できる。よって、この事を考慮した内容の対応手順及びその目標時間（緊急性などが大きい）が導出される。例えば、他のインシデント（対応が必要な複数のインシデントが存在する場合）への対応（その目標時間等）よりも、当該インシデントへの対応についての時間的な優先度を上げるように目標時間等が導出される。例えば、上記優先度に応じて、目標時間を早めにすることができる。また例えば、複数のインシデントに関する複数の対応情報における目標時間や対応者を、上記優先度を考慮してスケジューリングしてもよい。これは例えば前記特許文献１の技術を用いてもよい。
【００４４】
また、本システムでは、発生インシデントへの対応（対応手順）を実行する対象となる時間（日時特性）などを考慮して対応情報を決定することができる。例えば、適用候補となる対応手順の内容、対象部位や所要時間、適用候補となる時間の日時特性やサービスレベルなどを考慮する。このような例について以下である。
【００４５】
（例１）  対象システム１（証券システム）のシステム２０２等において障害（ＩＡ）が発生した場合。この障害への対応（対応手順）として、例えば当該システムの復旧手順等を実行したいが、そのためには当該システムのリブートを伴う。よって、発生日時が［場中］の時には、当該対応手順をすぐに実行することは不適切である。従って、次に［場中以外］になる時間を見計らって当該対応手順を実行するべく、目標時間等が導出される。
【００４６】
（例２）  障害（ＩＡ）の発生日時が例えば８時３０分であり、次に［場中］になる時点（９時）の３０分前である。また、この障害への対応手順（復旧手順等）の所要時間が例えば１０分と見積もられる。この場合、次に［場中］になる前に当該対応手順を実行するべく、目標時間等が導出される。
【００４７】
（例３）  障害（ＩＡ）の発生日時が例えば８時５５分であり、次に［場中］になる時点（９時）の５分前である。また、この障害への対応手順（復旧手順等）の所要時間が例えば１０分と見積もられる。この場合、次に［場中］になる前に当該対応手順を実行及び完了することは不適切と判断し、例えば［場中］になった後におけるピーク時間帯を避けた時間に当該対応手順を実行するべく、目標時間等が導出される。
【００４８】
＜情報データ＞
図２では、本システムで扱う主な情報データについて示している。対象システム１では、ログ２０１やその他の管理情報の形で、インシデントに関連するシステム特性や状況、サービスレベル等の情報を有する。検知部１１は、それらの各種情報を把握、取得する。またそれらの各種情報は、インシデント管理システム１０側、検知部１１などで管理してもよい。ＤＢ５０のテーブル６０には、インシデント情報５１及び対応情報５２を含むレコードが記録される。インシデント情報５１及び対応情報５２は、対象システム１の特性や状況、サービスレベル等の情報と関連付けられる。
【００４９】
システム特性の情報として、例えば、構成要素（部位）の情報である、システム種別（例えばシステム２０２の種別）、サーバ名称（例えばサーバ２０３の名称）、それらの重要度などの情報や、日時特性の情報である、営業日、サービス時間、場などを規定する情報がある。システム状況の情報として、例えば、発生日時、発生部位（例えばシステム２０２、サーバ２０３等）、ログメッセージ、利用者数（例えばシステム２０２やサーバ２０３等の利用者数）、トランザクション数、等の情報がある。また、それらに関係する、サービスレベルを規定する情報がある。
【００５０】
インシデント情報５１は、属性として、インシデントのＩＤ、インシデントの発生有無（種別）、発生日時、発生部位（システム種別、サーバ名称など）、稼働や障害などの状況（ログメッセージ、利用者数など）、他インシデントとの関係（親子ＩＤなど）、キー情報（同件キー、補助同件キー）、等の情報がある。親子ＩＤは、同件の関係を示す情報である。キー情報は、同件の判定用の登録情報である。
【００５１】
対応情報５２としては、対応手順（手順、原因、コメント等）、対応の目標時間（予定、リミット等）、インパクト、対応者（表示先や通知先など）、等の情報を有する。目標時間は、対応の緊急性などに係わる情報である。インパクトは、インシデントや対応の影響度に係わる情報である。
【００５２】
図３〜図４では、ＤＢ５０のインシデント情報５１（対応情報５２を含む）のデータ構造例として、テーブル６０の詳細例を示している。インシデント及び対応毎に、インシデント情報のレコードが作成される。本テーブル６０には、実際に発生・検知したインシデント（ＩＡ）についてのレコードと、対応者（Ｕ２）により登録されたインシデント（ＩＢ）についてのレコードと、両方が格納される。
【００５３】
Ａ（ａ，ｂ）の情報は、基本的な管理情報である。ａは、インシデントのＩＤ（識別情報）である。ｂの「発生有無」は、インシデントの種別として、実際のインシデントの発生有無を区別する値であり、本システムが自動的に設定する。例えばＹ（有）は、実際に発生したインシデントを本システムが検知して自動的にＤＢ５０に格納した情報（ＩＡ）を示す。Ｎ（無）は、未発生のインシデントについて対応者（Ｕ２）が登録部４０から手動で登録した情報（ＩＢ）を示す。本例では、ＩＤ＝１のレコード（インシデントＩ１）は、［場中］に実際に発生した障害等のインシデント（ＩＡ）についてのレコードであり、ＩＤ＝２のレコード（インシデントＩ２）は、Ｉ１の発生に基づいて、開発者（Ｕ２）が、［場中以外］での対応情報を、想定済みのインシデント（ＩＢ）として手動で登録したものである。
【００５４】
Ｂ（ｃ〜ｇ）の情報は、対象システム１の特性や状況を示す情報であり、本システム（検知部１１）が対象システム１から自動で取得した値が格納される。ｃの「ログメッセージ」は、ログ２０１の情報であり、例えばエラーコード、障害内容、パターンなどを含む。ｄは、当該インシデントの発生日時（年月日、曜日、時刻など）である。ｄの値は、発生有無がＹ（ＩＡ）の場合に格納され、Ｎ（ＩＢ）の場合には格納されない（ＮＵＬＬ値）。なお図中の“−”はＮＵＬＬ値を示す。
【００５５】
ｅの「システム種別」は、対象システム１やそれを構成するシステム２０２等の種別や名称等の情報である。例えば、銘柄検索サービスを提供するシステム２０２を示す。ｆの「サーバ名称」は、対象システム１やシステム２０２を構成するサーバ２０３の種別や名称等の情報である。ｅやｆの情報は、インシデントの発生部位、対応対象部位などに係わる情報であり、当該要素の重要度も示している。例えば銘柄検索サービスに応じた所定の重要度を持つ。また当該重要度の情報を別に関連付けて保持し、対応情報取得処理で考慮してもよい。
【００５６】
ｇの「利用者数」は、当該インシデントの発生の時点で対象システム１（発生部位）を利用・アクセス等しているユーザの人数などである。その他、トランザクション数や負荷量などを管理して、対応情報取得処理で考慮してもよい。
【００５７】
Ｃ（ｈ，ｉ）の情報は、コンピュータ（検索部１２等）による自動判定処理、及び、対応者（Ｕ２等）による手動操作及び判断に基づき、インシデントの親子関係（同件の関係）を設定、管理するものである。例えば検索部１２は、検索処理の結果、発生インシデントが既知のインシデントに該当（一致または類似など）すると判定した場合、当該インシデント同士を親子関係に設定する。即ち、既知のインシデントを親インシデントとし、発生インシデントを子インシデントとする。具体的には、本システム（検索部１２）は、当該インシデントのレコードに対して、この親子ＩＤ（ｈ，ｉ）の値を自動的に付与し、格納する。ｈの「親ＩＤ」は、当該インシデント（子インシデント）のレコードに対する親インシデントのＩＤを示す。ｉの「子ＩＤ」は、当該インシデント（親インシデント）のレコードに対する子インシデントのＩＤを示す。
【００５８】
また開発者等（Ｕ２）は、既知のインシデントに対して次回以降のインシデントが発生し、それらのインシデント同士を同件のインシデントであると判断した場合に、登録部４０から手動で当該関係を登録することができる。その登録操作に応じて、上記同様に、本システム（登録部１２）は、当該インシデントのレコードに対して、この親子ＩＤ（ｈ，ｉ）の値を自動的に付与し、格納する。
【００５９】
Ｄ（ｊ〜ｌ）の情報は、同件キーである。また、Ｅ（ｍ〜ｏ）の情報は、補助同件キーである。それぞれ例として３種類（＃１〜＃３）のキー情報を設定した場合を示す（＃１等は識別番号）。これらのキー情報は、開発者等（Ｕ２）が登録部４０から手動で登録した値が格納される。これらのキー情報は、親インシデントの属性として持つことができる。これらのキー情報は、検索部１２による同件のインシデントの検索・判定の際に用いる情報であり、既知のインシデントに対してそれ以降に発生するインシデントについて、自分と同件であると判定させるための情報である。同件キーは、高速に検索・判定して対応情報を取得して表示するためには必須の設定値である。補助同件キーは、同件キーに対して補助的に用いる（後述）。なおこれらのキー情報を用いた検索処理でヒットしない場合、またはキー情報が設定されていない場合であっても、ＤＢ５０のインシデント情報を対象として全文検索等を行うことにより、既知（一致または類似）／未知の判定が可能である。
【００６０】
キー情報としては、対象システム１の特性や状況に関する各種情報を設定することができる。ｊの同件キー＃１は、前記ログメッセージ（エラーコード等）を設定した場合である。ｋの同件キー＃２は、前記システム種別（例えば“銘柄検索”）を設定した場合である。ｌの同件キー＃３は、前記サーバ名称（例えば“Server01”）を設定した場合である。ｍの補助同件キー＃１は、日時特性の１つである［営業日］（例えばＹは［営業日］、Ｎは［非営業日］）を設定した場合である。ｎの同件キー＃２は、日時特性の１つである［場中］（例えばＹは［場中］、Ｎは［場中以外］）を設定した場合である。ｏの同件キー＃３は、前記利用者数（例えば“１００人以上”、“５０人以下”）を設定した場合である。
【００６１】
Ｆ（ｐ〜ｔ）の情報は、開発者等（Ｕ２）が登録部４０から登録した値が格納される。ｐの「対応手順」は、対応手順を記述した情報である。例えば、Ｉ１のレコードの対応手順（手順１）のように、所定のスクリプトＡ，Ｂを順に実行させる指示及びコメント等である。ｑの「所要時間」は、ｐの「対応手順」の実行開始から終了までにかかる標準的な時間である。ｒの「ダウンタイム実績値」は、実際に発生した障害等のインシデントによるダウンタイム（正常にサービスを提供できない時間）の実績値である。ｓの「担当者」（対応者）は、ｐの「対応手順」を実行する対応者の名称やＩＤなどである。ｔの原因は、当該インシデントの原因（対応者が原因と判断したもの等）の情報である。
【００６２】
更に、図５では、対象システム１の管理情報テーブルの例として、図５（ａ）はサービスレベルのテーブル６１、図５（ｂ）は場のテーブル６２を示す。これらの情報は、例えば本システムのＤＢ５０内に管理される。
【００６３】
サービスレベルは、予め、対象システム１の顧客（Ｕ０）との契約時などに締結される。それに基づきテーブル６１の値が設定される。サービスレベルは、対象システム１の特性、例えばシステム種別（部位）及び日時特性などの単位ごとに、可用性（稼働率）によって規定される。可用性は、稼働率［％］で表す。例えば重要度の高いシステム２０２や時間帯であるほど、高い可用性が求められる。
【００６４】
場のテーブル６２において、証券システムにおける場（例えば東証前場、東証後場）の［場中］の開始及び終了の時間が規定されている。［場中］は株式取引時間内であり、利用者数などが高くなる。その他、同様に、［営業日］や［サービス時間］などが管理される。上記のような対象システム１の特性、状況、サービスレベル等の異なり（変動）に応じて、対応の緊急性（目標時間）なども変わってくる。
【００６５】
＜対応情報取得処理＞
図６において、対応情報取得部３０における処理フロー例を示している（Ｓは処理ステップを表す）。
【００６６】
（Ｓ１）  検知部１１からの発生インシデント（ＩＡ）に対し、検索部１２によるＤＢ５０（テーブル６０）の情報の検索、及び既知／未知のインシデントの判定の処理を行う。検索処理では、例えば、一致／類似の度合いが一番高いインシデント（及び対応情報）から順に、候補（適用する対応情報の選択・決定のための候補）として得る。ＤＢ５０の検索範囲は、インシデント情報５１のレコード群における親インシデントのカラム（親ＩＤ）がＮＵＬＬのもの（即ち子インシデント以外）となる。親ＩＤが設定されているレコードは子インシデントであり、親と関係付けられているので、検索範囲に含める必要は無い。
【００６７】
検索処理の際、検索範囲の中で、レコードに同件キー等のキー情報（図３、Ｄ，Ｅ）が設定されている場合は参照され、当該キー情報を用いた検索処理が行われる。当該キー情報によるヒットに応じて、同件のインシデントが判定される。キー情報を用いた場合、全文検索等が不要であるので、高速に結果が得られる。また、上記キー情報（Ｄ，Ｅ）が設定されていない場合は、例えば、システム種別やログメッセージ等の、対象システム１の特性や状況を示す情報（図３、Ｂ）を対象とした全文検索（曖昧検索）等の処理を適用し、照合により当該インシデント同士の一致／類似の度合いをみて、同件のインシデントを判定する。
【００６８】
検索結果で既知のインシデントにヒットした場合、導出部１３へ連携する。またヒットしなかった場合（即ち未知と判定した場合）、例えば、画面表示部２０や通知部２３と連携し、対応者の端末へ当該情報の表示や通知等を行う。
【００６９】
（Ｓ１−１）  検索部１２は、まず第１段階の検索として、同件キーの情報（Ｄ）を用いて、インシデント情報５１のレコード群を対象として、完全一致などの条件による検索を行う。これにより例えば複数のすべての同件キーがヒットする場合、当該レコードを同件のインシデントと判定する。
【００７０】
（Ｓ１−２）  また検索部１２は、第２段階の検索として、補助同件キーの情報（Ｅ）を用いて、インシデント情報５１のレコード群を対象として、部分一致などの条件による検索を行う。これによりヒットしたレコード（群）を、一致／類似の度合いなどによって順位付け、上位から候補として得る。候補のインシデントは、例えば、上位から順に複数の候補をリストとして出力してもよい。
【００７１】
上記検索処理結果に基づき、一旦、発生インシデントに対して適用するためのインシデント対応情報（対応手順）を１つの候補（例えば手順Ｘ）として決定する。
【００７２】
（Ｓ２）  導出部１３は、発生インシデントに関する発生日時・日時特性、発生部位、稼働等の状況、サービスレベル等の情報を抽出する（検知部１１またはＤＢ５０等から参照）。サービスレベルについては、部位や日時等に応じた可用性（稼働率）の値を図５のテーブル６１から抽出する。
【００７３】
（Ｓ３）  導出部１３により、上記手順Ｘに関する目標時間情報の１つとなる対応完了日時リミット（Ｔ１）を導出する。この際、Ｓ２で抽出した当該インシデントの発生日時等の情報を考慮して、当該時間情報を導出する。例えば、導出部１３は、日時特性及びサービスレベルに基づき、発生日時及び発生部位におけるダウンタイム許容時間を導出し、これにより対応完了日時リミット（Ｔ１）を導出する。
【００７４】
（Ｓ４）  また導出部１３により、上記手順Ｘに関する目標時間情報の１つとなる対応完了日時予定（Ｔ２）を導出する。例えば、導出部１３は、上記手順Ｘの所要時間（ｑ）を参照し、リミット（Ｔ１）に間に合うか確認し、対応完了日時予定（Ｔ２）を導出する。
【００７５】
（Ｓ５）  導出部１３は、上記手順Ｘに関する目標時間情報（Ｔ１，Ｔ２）に基づき、予定（Ｔ２）に到達するまでの時間におけるサービスレベル等の状況（変化）を確認する。例えば図５のテーブル６１のように日時に応じてサービスレベルの規定値の遷移が存在する。変化が無い場合にはＯＫとなり、変化がある場合、リミット（Ｔ１）に間に合わない等の場合にはＮＧとなる。
【００７６】
（Ｓ６）  導出部１３は、上記手順Ｘ及び目標時間情報（Ｔ１，Ｔ２）等に対し、適切性・妥当性を確認・判断する。例えば上記Ｓ５でＮＧの場合、Ｓ１の後に戻り、Ｓ１の結果から候補を再度選択し、Ｓ２〜Ｓ６の処理を繰り返す。
【００７７】
（Ｓ７）  上記Ｓ６の結果、ＯＫと判断した対応手順（手順Ｘ）及び目標時間情報（Ｔ１，Ｔ２）等の情報を、当該発生インシデントに対して適用する対応情報として決定し出力する。
【００７８】
＜処理ケース（１）＞
上記処理フロー及びテーブル６０等を前提として、以下、図７、並びに図８〜図１０を用いながら、各インシデントのケースにおける処理例を説明する。図７は、各ケースのインシデント（Ｉ１〜Ｉ５）の時系列上の関係等を簡単に表している。インシデントＩ１（ＩＡ），Ｉ２（ＩＢ）については、前述のテーブル６０の例の通りである（Ｉ１は［場中］の発生例、Ｉ２は［場中以外］に対応するための登録例）。図８〜図１０では、画面表示部２０（２１，２２）によるＷｅｂ画面表示情報（インシデント情報５１、インシデント対応手順（対応情報５２））の一例を示している。なお下線箇所は、わかりやすいように図８〜図１０で異なる情報の箇所を示している。
【００７９】
第１のケースとして、対象システム１（証券システム）の［営業日］、［サービス時間内］、［場中］において、下記のような障害等のインシデントＩ３が発生した場合である。Ｉ３も［場中］の発生例（種別はＩＡ）である。表示情報としては、図８のインシデント情報（１）、インシデント対応手順情報（１）のようになる。図８のインシデント情報（１）に示すように、インシデントＩＤは３、発生日時は２００９年８月１２日（水）１０時、発生部位として、システム種別が“銘柄検索”のシステム２０２、サーバ名称が“Server01”のサーバ２０３である。その他、状況として、ログメッセージや利用者数の通りである。
【００８０】
先に第１のケースの結果を示すと、図７のように、発生インシデントＩ３（ＩＡ）は、検索処理により、発生日時や発生部位、ログメッセージ等の値から、Ｉ１が一致（同件）と判定され、Ｉ１の対応手順（手順１）が、Ｉ３に適用される候補となる。次いで、手順１に関する目標時間情報（リミット（Ｔ１）、予定（Ｔ２）など）が、その時点の対象システム１の特性や状況、サービスレベル等を考慮して導出される。上記結果の適切性がＯＫと確認されると、上記Ｉ１の手順１及び目標時間情報等に決定される。同件の関係として、Ｉ１が親、Ｉ３が子（子１）となり、Ｉ３にＩ１の手順１が適用される。詳しい処理内容は以下である。
【００８１】
（Ｓ１）  検索部１２は、発生インシデントＩ３が既知のインシデントに該当するかどうかをＤＢ５０（テーブル６０）から検索する。第１段階（Ｓ１−１）の検索として、同件キー（Ｄ）（＃１〜＃３）を使用する。これにより、例えば図３〜図４のＩ１とＩ２のレコードがヒットする。第２段階（Ｓ１−２）の検索として、第１段階（Ｓ１−１）でヒットした結果（Ｉ１，Ｉ２）に対して、補助同件キー（Ｅ）（＃１〜＃３）を使用したマッチングを行う。これにより、例えばＩ１のレコードが、一致の度合いが一番高いものとしてヒットする（Ｉ３は［場中］の発生例であるため、Ｉ２よりもＩ１の内容に近い）。上記により、一旦、Ｉ１及びその対応手順（手順１）が、候補として選択される。
【００８２】
（Ｓ２）  導出部１３は、上記Ｉ１の手順１に関し、Ｉ３に関する対象システム１の特性や状況などを考慮した目標時間情報（リミット（Ｔ１）や予定（Ｔ２）等）を導出するために、Ｉ３に関する発生日時、発生部位、サービスレベル等の情報を抽出する。導出部１３は、Ｉ３の発生日時（８月１２日（水）１０時）及び発生部位（システム種別が“銘柄検索”のシステム２０２等）、サービスレベルのテーブル６１及び場のテーブル６２等に基づき、当該日時及び部位に応じた可用性（稼働率）の値を抽出する。当該日時及び部位では［営業日］［サービス時間］［場中］に該当するので、［サービス時間内場中可用性］（ｃ）に示すように、当該値は９５％となる。
【００８３】
（Ｓ３）  導出部１３は、上記Ｓ２に基づき、手順１に関するリミット（Ｔ１）を算出する。まず、導出部１３は、日単位のダウンタイム許容時間（Ｔ３）を計算する。１日の場の時間合計は、場のテーブル６２から、４．５時間（２７０分）である。［場中］の稼働率は上記９５％（ダウンタイム許容率で言えば５％）である。即ち、Ｔ３＝［１日の場の時間合計］×［１−稼働率］＝２７０分×（１−０．９５）＝１３．５分、と求まる。
【００８４】
導出部１３は、上記許容時間（Ｔ３）をもとに、リミット（Ｔ１）を計算する。即ち、Ｔ１＝［Ｉ３の発生日時］＋［Ｔ３］＝［１０：００］＋［１３．５分］＝１０時１３分３０秒、と求まる。
【００８５】
（Ｓ４）  導出部１３は、上記Ｓ３に基づき、手順１に関する予定（Ｔ２）を算出する。手順１における所要時間（ｑ）を確認すると、「３分」である。すぐに手順１を実行した場合の完了時間は、［Ｉ３の発生日時］＋［所要時間］＝［１０：００］＋［３分］＝［１０：０３］であり、この時間は、上記リミット（Ｔ１）に間に合う（言い換えれば所要時間がリミット内に収まる）。従って、導出部１３は、手順１の予定（Ｔ２）を、上記［１０：０３］とする。
【００８６】
（Ｓ５）  導出部１３は、予定（Ｔ２）に到達するまでの時間におけるサービスレベルの状況（変化）を確認する。例えば、テーブル６１から、Ｔ２＝［１０：０３］までにサービスレベルの変化は無い（同じ９５％）。
【００８７】
（Ｓ６，Ｓ７）  上記に基づき、導出部１３は、Ｉ３に適用する対応手順としてＩ１の手順１が適切（ＯＫ）であると判断する。これにより、対応情報取得部３０が出力して画面に表示する対応情報は、例えば図８のインシデント対応手順（１）の通りになる。なお、同件の関係として、Ｉ１のレコードの子ＩＤにはＩ３のＩＤ値が格納され、Ｉ３のレコードの親ＩＤにはＩ１のＩＤ値が格納される。
【００８８】
＜処理ケース（２）＞
第２のケースとして、対象システム１の［営業日］、［サービス時間内］において、「場中」の１５分前、即ち「場中以外」の時において、下記のような障害等のインシデントＩ４が発生した場合である。Ｉ４は［場中以外］の発生例（種別はＩＡ）である。表示情報としては、図９のインシデント情報（２）、インシデント対応手順情報（２）のようになる。インシデント情報の異なる箇所として、インシデントのＩＤが４、発生日時が８月１４日（金）８時４５分、利用者数が３０人、等である。
【００８９】
先に第２のケースの結果を示すと、図７のように、Ｉ４（ＩＡ）は、検索によりＩ１，Ｉ２が該当と判定され、Ｉ１，Ｉ２の対応手順（手順１，手順２）が候補となる。それらの目標時間情報（Ｔ１，Ｔ２など）も前述同様に導出される。上記結果の適切性の判断により、Ｉ２はＮＧ、Ｉ１がＯＫと判断される。よって、上記Ｉ１の手順１及び目標時間情報等に決定される。即ち、Ｉ１が親、Ｉ４が子（子２）の関係となり、Ｉ４にＩ１の手順１が適用される。詳しい処理内容は以下である。
【００９０】
（Ｓ１）  検索部１２は、Ｉ４につき前述同様に検索処理を行う。第１段階（Ｓ１−１）では、同件キー（Ｄ）の使用により、例えばＩ１とＩ２のレコードがヒットする。第２段階（Ｓ１−２）では、上記結果（Ｉ１，Ｉ２）に対して補助同件キー（Ｅ）を使用したマッチングにより、例えば、第１のケースとは異なり、Ｉ２のレコードが、一致／類似の度合いが一番高いものとしてヒットする（Ｉ４は［場中以外］の発生例であるため、Ｉ１よりもＩ２の内容に近い）。上記により、一旦、Ｉ２及びその対応手順（手順２）が、候補として選択される。
【００９１】
（Ｓ２）  導出部１３は、Ｉ４の情報に基づき、サービスレベルのテーブル６２から、可用性（稼働率）の値を抽出する。即ち、［場中以外］であり、［サービス時間内場中以外可用性］（ｄ）から、８０％となる。
【００９２】
（Ｓ３）  導出部１３は、上記Ｓ２に基づき、手順２に関するリミット（Ｔ１）を算出する。前述同様に、日単位のダウンタイム許容時間（Ｔ３）を計算する。［サービス時間内での場の時間合計］は、４５０分である。［場中以外］の稼働率は上記８０％である。即ち、Ｔ３＝［サービス時間内での場の時間合計］×［１−稼働率］＝４５０分×（１−０．８）＝９０分、と求まる。導出部１３は、上記許容時間（Ｔ３）をもとに、リミット（Ｔ１）を計算する。即ち、Ｔ１＝［Ｉ４の発生日時］＋［Ｔ３］＝［０８：４５］＋［９０分］＝［１０：１５］、と求まる。
【００９３】
（Ｓ４）  導出部１３は、上記Ｓ３に基づき、手順２に関する予定（Ｔ２）を算出する。手順２における所要時間（ｑ）を確認すると、「４５分」である。すぐに手順２を実行した場合の完了時間は、［Ｉ４の発生日時］＋［所要時間］＝［０８：４５］＋［４５分］＝［０９：３０］であり、この時間は、上記リミット（Ｔ１）に間に合う。従って、手順２の予定（Ｔ２）を上記［０９：３０］とする。
【００９４】
（Ｓ５）  導出部１３は、予定（Ｔ２）に到達するまでの時間におけるサービスレベルの状況（変化）を確認する。テーブル６１から、Ｔ２＝［０９：３０］までに、サービスレベルの規定値の変化がある。即ち、［場中以外］（８０％）から、９時以降［場中］（９５％）に切り替わる。これは、第１のケースで検討した通り、［場中］のダウンタイム許容時間（Ｔ３）が１３．５分であるため、間に合わない。
【００９５】
（Ｓ６，Ｓ７）  上記に基づき、導出部１３は、Ｉ４に適用する対応手順としてＩ２の手順２が不適切（ＮＧ）であると判断する。上記サービスレベルの変化において、切り替わり後のサービスレベルの方が高い場合、計算・判断に用いるサービスレベルの値にはその切り替わり後の値をセットする。
【００９６】
前記候補の選択に戻り、今度は、Ｓ１の結果で２番目に近い結果であったＩ１の手順１を候補として選択し、Ｓ２以降の処理を行う（第１のケースの場合と同様）。例えば、リミット（Ｔ１）は［０８：４８］、予定（Ｔ２）は［０８：５８］、と求まる。この結果、導出部１３は、Ｉ４に適用する対応手順としてＩ１の手順１が適切（ＯＫ）であると判断する。これにより、対応情報取得部３０が出力して画面に表示する対応情報は、例えば図９のインシデント対応手順（２）の通りになる。
【００９７】
＜処理ケース（３）＞
第３のケースとして、対象システム１の［非営業日］（休日）の時において、下記のような障害等のインシデントＩ５が発生した場合である。Ｉ５は［非営業日］［サービス時間外］の発生例（種別はＩＡ）である。表示情報としては、図１０のインシデント情報（３）、インシデント対応手順情報（３）のようになる。インシデント情報の異なる箇所として、インシデントのＩＤが５、発生日時が８月１６日（日）１０時００分、利用者数が２人、等である。
【００９８】
先に第３のケースの結果を示すと、図７のように、Ｉ５（ＩＡ）は、検索によりＩ２が該当と判定され、Ｉ２の対応手順（手順２）が候補となる。目標時間情報（Ｔ１，Ｔ２など）も前述同様に導出される。上記結果の適切性の判断により、Ｉ２はＯＫと判断される。よって、上記Ｉ２の手順２及び目標時間情報等に決定される。即ち、Ｉ２が親、Ｉ５が子（子１）の関係となり、Ｉ５にＩ２の手順２が適用される。詳しい処理内容は以下である。
【００９９】
（Ｓ１）  検索部１２は、Ｉ５につき前述同様に検索処理を行う。第１段階（Ｓ１−１）では、同件キー（Ｄ）の使用により、例えばＩ１とＩ２のレコードがヒットする。第２段階（Ｓ１−２）では、上記結果（Ｉ１，Ｉ２）に対して補助同件キー（Ｅ）を使用したマッチングにより、例えば、マッチング率（個数）が、Ｉ１につき０個、Ｉ２につき２個となり、Ｉ２の方が一致／類似の度合いが高いものとしてヒットする（Ｉ５は［非営業日］の発生例であるため、Ｉ１よりもＩ２の内容に近い）。上記により、一旦、Ｉ２及びその対応手順（手順２）が、候補として選択される。
【０１００】
（Ｓ２）  導出部１３は、Ｉ５の情報に基づき、サービスレベルのテーブル６２から、可用性（稼働率）の値を抽出する。即ち、［非営業日］であり、［サービス時間外可用性］（ｅ）から、０％となる。
【０１０１】
（Ｓ３）  導出部１３は、上記Ｓ２に基づき、可用性が０％の場合、次にサービスレベルが変化して可用性が０％以外になる日時を、手順２に関するリミット（Ｔ１）として決定する。即ち、テーブル６１から、Ｔ１＝８月１７日（月）８時、になる。
【０１０２】
（Ｓ４）  導出部１３は、上記Ｓ３に基づき、手順２に関する予定（Ｔ２）を算出する。手順２における所要時間（ｑ）を確認すると、「４５分」である。すぐに手順２を実行した場合の完了時間は、［Ｉ５の発生日時］＋［所要時間］＝［１０：００］＋［４５分］＝［１０：４５］であり、この時間は、上記リミット（Ｔ１）に間に合う。
【０１０３】
（Ｓ５）  導出部１３は、サービスレベルの状況（変化）を確認する。［非営業日］であるため、しばらくサービスレベルの変化は無い。上記のように可用性が０％の場合は、予定（Ｔ２）を表示する必要は無く、当該手順２の所要時間（「４５分」）の情報を表示する。
【０１０４】
（Ｓ６，Ｓ７）  上記に基づき、導出部１３は、Ｉ５に適用する対応手順としてＩ２の手順２が適切（ＯＫ）であると判断する。これにより、対応情報取得部３０が出力して画面に表示する対応情報は、例えば図１０のインシデント対応手順（３）の通りになる。
【０１０５】
＜実施の形態の効果等＞
本実施の形態によれば、インシデント発生時に、従来例のような対応者による手動の検索・判断の作業とは異なり、自動的にＤＢ５０の情報を検索・判定して対応情報を出力できるので、効率的な対応を実現できる。対応者による手動操作の手間や時間などを削減でき、またスキルの少ない対応者も対応業務がしやすい。また、従来例よりも効果的なように、ＤＢ５０の情報やインシデント及び対応情報の導出計算処理が構成されている。即ち、同じ発生インシデント（例えば障害）に対しても、リアルタイムの対象システム１の特性、状況、サービスレベル等を考慮した計算に応じて、異なる適切な対応情報（対応手順及び目標時間情報など）が得られる。
【０１０６】
＜変形例＞
上記実施の形態の変形例について以下が挙げられる。例えば、対応情報取得部３０の処理方法として、インシデント情報の類似の判定により、１つに限らず、複数のインシデント及び対応情報を決定し、それらの表示情報（リスト）を出力する形態としてもよい。例えば、対応者は、リストの中の対応情報を比較し、上位の対応情報から順に適用してみることができる。また、同件の関係を示す親インシデントがヒットした場合、それに関係付けられる子インシデントがある場合は自動的にリストアップしてそれらの複数のインシデント及び対応情報を出力してもよい。
【０１０７】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
【産業上の利用可能性】
【０１０８】
本発明は、運用管理システム、情報セキュリティ管理システムなどに利用可能である。
【符号の説明】
【０１０９】
１…対象システム、２…運用管理システム、３…対応者及び対応システム、１０…インシデント管理システム、１１…検知部（インシデント取得部）、１２…検索部（インシデント検索部）、１３…導出部（対応情報導出部）、２０…画面表示部、２１…インシデント情報表示部、２２…対応情報表示部、２３…対応情報通知部、３０…対応情報取得部、４０…登録部、５０…ＤＢ、５１…インシデント情報、５２…対応情報、６０，６１，６２…テーブル、２０１…ログ、２０２…システム、２０３…サーバ、Ｉ，ＩＡ，ＩＢ…インシデント（またはインシデント情報）、Ｕ０…ユーザ、Ｕ１，Ｕ２…対応者。
【図１】
2011076161.tif 000003
【図２】
2011076161.tif 000004
【図３】
2011076161.tif 000005
【図４】
2011076161.tif 000006
【図５】
2011076161.tif 000007
【図６】
2011076161.tif 000008
【図７】
2011076161.tif 000009
【図８】
2011076161.tif 000010
【図９】
2011076161.tif 000011
【図１０】
2011076161.tif 000012