5722163 インシデント管理システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5722163

(24)【登録日】2015年4月3日

(45)【発行日】2015年5月20日

(54)【発明の名称】インシデント管理システム

(51)【国際特許分類】

   G06Q 10/00 20120101AFI20150430BHJP

【ＦＩ】

   G06Q10/00 120

【請求項の数】2

【全頁数】11

(21)【出願番号】特願2011-192087(P2011-192087)

(22)【出願日】2011年9月2日

(65)【公開番号】特開2013-54530(P2013-54530A)

(43)【公開日】2013年3月21日

【審査請求日】2014年1月29日

(73)【特許権者】

【識別番号】000155469

【氏名又は名称】株式会社野村総合研究所

(74)【代理人】

【識別番号】100105924

【弁理士】

【氏名又は名称】森下 賢樹

(72)【発明者】

【氏名】大平 亮

(72)【発明者】

【氏名】岡山 亮

(72)【発明者】

【氏名】白石 勇樹

(72)【発明者】

【氏名】水鳥 裕太

【審査官】 松野 広一

(56)【参考文献】

【文献】 特開２００２−０３２３３７（ＪＰ，Ａ）

【文献】 特開２０００−０２９７４４（ＪＰ，Ａ）

【文献】 特開２０１０−１３４５５６（ＪＰ，Ａ）

【文献】 特開２００８−１２９９７３（ＪＰ，Ａ）

【文献】 ＣＭＤＢ上で一連のプロセスを自動化。ＩＴＩＬの導入を強力にサポートするＪＰ１ Ｖｅｒｓｉｏｎ ７ｉ，ＩＴ Ｐｒｏｆｅｓｓｉｏｎａｌｓ，日本，日経ＢＰ社，２００５年１１月 １日，第４２号，ｐ．７０，７１

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００−５０／３４

(57)【特許請求の範囲】

【請求項1】

情報処理システムにおいて発生した複数のインシデントの情報を保持するインシデント情報保持部と、
前記複数のインシデントの中からユーザへ通知すべきインシデントを抽出するためにユーザが予め定めた抽出条件を保持する抽出条件保持部と、
前記抽出条件にもとづき前記複数のインシデントの中からインシデントを抽出する抽出部と、
前記抽出部により抽出されたインシデントの情報を通知する通知部と、を備え、
前記通知部は、前記抽出部によりインシデントが抽出された場合、前記抽出部により過去抽出されたインシデントと今回抽出されたインシデントの片方にだけ含まれるインシデントの情報を、今回抽出されたインシデントの情報とは別に通知することを特徴とするインシデント管理システム。

【請求項2】

情報処理システムにおいて発生した複数のインシデントの情報を保持するインシデント情報保持部と、
前記複数のインシデントの中からユーザへ通知すべきインシデントを抽出するためにユーザが予め定めた抽出条件を保持する抽出条件保持部と、
前記抽出条件にもとづき前記複数のインシデントの中からインシデントを抽出する抽出部と、
前記抽出部により抽出されたインシデントの情報を通知する通知部と、を備え、
前記通知部は、前記抽出部によりインシデントが抽出された場合、前記抽出部により過去抽出されたインシデントに含まれるが、今回抽出されたインシデントには含まれないインシデントの情報を、今回抽出されたインシデントの情報とは別に通知することを特徴とするインシデント管理システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明はデータ処理技術に関し、特に、情報処理システムのインシデント管理を支援する技術に関する。

【背景技術】

【0002】

ＩＴインフラが幅広いユーザ層に活用されるようになってきているなか、ＩＴサービスマネジメントがこれまで以上に重要になってきている。ＩＴサービスマネジメントに関して、英国商務局（ＯＧＣ:Office of Government Commerce）はＩＴＩＬ（Information Technology Infrastructure Library）（登録商標）と呼ばれるベストプラクティス集を公表している。最近では、ＩＴＩＬに従ってＩＴサービスマネジメントの改善に取り組む企業が増えている。

【0003】

ＩＴＩＬの中核の一つにサービスサポートがある。サービスサポートは日常的なシステム運用およびユーザサポートに関して記載されたもので、１つの機能と５つのプロセスからなる。機能としては、ユーザからの問い合わせ窓口となるサービスデスク、プロセスとしてはインシデント管理、問題管理、変更管理、リリース管理および構成管理が規定されている。

【0004】

サービスデスク業務では、エンドユーザからどのような問い合わせがあったのか、それに対してどのように対応したのか、その問い合わせは処理が終わってクローズしたのか、といった様々なことを記録していく。このようなサービスデスク業務を支援するため、エンドユーザからの問い合わせをインシデントとして蓄積していくインシデント管理システムが実用化されている（例えば、特許文献１）。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２００８−１２９９７３号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

サービスデスク業務を行う運用部門の担当者は、運用部門で抱えるインシデントの状況を監視する必要がある。現状一般に、監視すべきインシデントを手動で特定してリスト化しておき、そのステータス等の進展状況を継続的に監視している。

【0007】

しかし、その方法では、監視すべきインシデントが新たに発生していないか、または既存インシデントの属性が変化し監視すべきインシデントとなっていないかを逐次確認し、リストに追加しなければならい。また、逆にインシデントがクローズされたことなどにより監視の必要がなくなった場合は、リストから削除しなければならない。このような作業は、多くのインシデントの状況を監視しなければならない担当者にとっては大きな負荷となる。

【0008】

本発明はこうした課題に鑑みてなされたものであり、その主な目的は、情報処理システムにおいて発生したインシデントの効率的な管理を支援するための技術を提供することにある。

【課題を解決するための手段】

【0009】

上記課題を解決するために、本発明のある態様のインシデント管理システムは、情報処理システムにおいて発生した複数のインシデントの情報を保持するインシデント情報保持部と、複数のインシデントの中からユーザへ通知すべきインシデントを抽出するためにユーザが予め定めた抽出条件を保持する抽出条件保持部と、抽出条件にもとづき複数のインシデントの中からインシデントを抽出する抽出部と、抽出部により抽出されたインシデントの情報を通知する通知部と、を備える。

【0010】

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。

【発明の効果】

【0011】

本発明によれば、情報処理システムにおいて発生したインシデントの効率的な管理を支援できる。

【図面の簡単な説明】

【0012】

【図1】実施の形態のインシデント管理システムを含む運用管理システムの全体構成を示す図である。

【図2】図１のインシデント管理システムの機能構成を示す図である。

【図3】図２のインシデント情報保持部に保持されたインシデントのデータ構造を示す図である。

【図4】図２の抽出条件保持部に保持された抽出条件を示す図である。

【図5】図２の抽出結果保持部に保持された抽出結果のデータ構造を示す図である。

【図6】図２の通知部により通知された抽出結果の画面を示す図である。

【図7】実施の形態においてインシデントが発生した場合の処理の流れを示すフローチャートである。

【図8】実施の形態においてインシデントを抽出する処理の流れを示すフローチャートである。

【発明を実施するための形態】

【0013】

本発明の実施の形態は、情報処理システムで発生した複数のインシデントを管理するためのシステムに関する。インシデント管理システムは、運用担当者（以下、「ユーザ」ともよぶ）が監視すべきインシデント、すなわちユーザへ通知すべきインシデントを抽出するためにユーザが予め定めた抽出条件を保持する。インシデント管理システムは、複数のインシデントの中から当該抽出条件に該当するインシデントを抽出し、ユーザに通知する。また、過去に抽出されたが今回抽出されなかったインシデントと、過去に抽出されなかったが今回抽出されたインシデントとを、差分インシデントとしてユーザに通知する。

【0014】

図１は、本実施の形態に係るインシデント管理システム３００を含む運用管理システム５００の全体構成を示す。情報処理システム１００ａ、１００ｂ、・・・、１００ｃ（以下、まとめて「情報処理システム１００」とよぶ）は、企業の基幹系システムや情報系システムを含む。運用管理システム５００は、情報処理システム１００に運用管理サービスを提供する。運用管理システム５００は、監視装置２００と、インシデント管理システム３００と、運用端末４００ａ、４００ｂ、・・・、４００ｃ（以下、まとめて「運用端末４００」とよぶ）を含む。

【0015】

インシデント管理システム３００は、情報処理システム１００で発生したインシデントを管理する。インシデント管理システム３００の詳細な機能構成は図２に関連して後述する。

【0016】

監視装置２００は、情報処理システム１００の動作状態を監視し、例えば死活監視処理やハードウェアリソースの使用状況の監視処理を実行する。情報処理システム１００の動作状態が所定の異常状態になった場合、監視装置２００は、新たなインシデントを起票してそのインシデントの情報をインシデント管理システム３００へ送信する。また監視装置２００は、インシデントを起票済の情報処理システム１００の動作状態が変化した場合、そのインシデントの更新情報をインシデント管理システム３００へ送信する。監視装置２００からインシデント管理システム３００へ送信される情報は、図３で示す。

【0017】

運用端末４００は、ユーザにより操作される情報処理端末であり、情報処理システムで発生したインシデントの情報（起票情報や更新情報）の入力をユーザから受け付ける。そして、その情報をインシデント管理システム３００へ送信する。運用端末４００からインシデント管理システム３００へ送信される情報は、監視装置２００からインシデント管理システム３００へ送信される情報と同様であり、図３で示す。また、運用端末４００は、図４で示すインシデントを抽出するための条件の入力をユーザから受け付け、その情報をインシデント管理システム３００へ送信する。

【0018】

図２は、図１のインシデント管理システム３００の機能構成を示す。これら各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、図２の各機能ブロックは、インシデント管理プログラムとして記録媒体に格納され、インシデント管理システムのストレージへインストールされてもよい。そして、運用管理支援プログラムの起動時に、各機能ブロックに対応するプログラムモジュールがメインメモリに読み出されてＣＰＵにより実行されてもよい。

【0019】

インシデント管理システム３００は、インシデント情報受付部３１０と、インシデント情報保持部３２０と、抽出条件受付部３３０と、抽出条件保持部３４０と、抽出部３５０と、抽出結果保持部３６０と、通知部３７０を含む。

【0020】

インシデント情報受付部３１０は、監視装置２００および運用端末４００からインシデントの情報を受け付け、受け付けたインシデントの情報をインシデント情報保持部３２０へ格納する。

【0021】

インシデント情報保持部３２０は、情報処理システム１００において発生したインシデントの情報を記憶する。図３は、インシデント情報保持部３２０に保持されるインシデントのデータ構造を示す。インシデント情報保持部３２０は、インシデントＩＤ６００と、属性情報６１０とを対応づけて保持する。インシデントＩＤ６００は、インシデントを一意に識別するためのＩＤである。属性情報６１０は、インシデントの内容や状況等を示す属性情報であり、ここでは、発生日時、タイトル、ステータス、担当者、緊急度を含む。

【0022】

図２に戻り、抽出条件受付部３３０は、インシデント情報保持部３２０に保持された複数のインシデントの中から、ユーザが監視すべきインシデント、すなわちユーザへ通知すべきインシデントを抽出するためにユーザが予め定めた条件（以下、「抽出条件」とよぶ）を運用端末４００から受け付ける。抽出条件受付部３３０は、受け付けた抽出条件を抽出条件保持部３４０へ格納する。

【0023】

抽出条件保持部３４０は、抽出条件を記憶する。図４は、抽出条件保持部３４０に保持された抽出条件を示す。抽出条件保持部３４０は、ユーザＩＤ７００と、抽出条件７１０とを対応付けて保持する。ユーザＩＤ７００は、ユーザを一意に識別するためのＩＤである。抽出条件７１０は、抽出条件となるインシデントの項目であり、ここでは、ステータス、担当者、緊急度を含む。

【0024】

図４において、同じレコードに含まれる抽出条件の各項目はＡＮＤ（論理積）で連結される。例えば、ユーザＩＤ「Ｕ００１」のユーザの場合、ステータス「クローズ以外」（すなわち継続中のインシデント）かつ担当者「山田一郎」かつ緊急度「高」という条件に該当するインシデントが抽出される。また、同じユーザＩＤのレコードが複数ある場合、それらはＯＲ（論理和）で連結される。例えば、ユーザＩＤ「Ｕ００２」のユーザの場合、ステータス「クローズ以外」かつ担当者「鈴木二郎」という条件と、ステータス「クローズ以外」かつ担当者「佐藤三郎」という条件と、ステータス「クローズ以外」かつ緊急度「高」という条件のいずれかに該当するインシデントが抽出される。

【0025】

図２に戻り、抽出結果保持部３６０は、後述する抽出部３５０により抽出されたインシデントの情報を抽出結果として記憶する。本実施の形態では、抽出結果保持部３６０は、ユーザごとに前回１回分の抽出結果を保持する。

【0026】

図５は、抽出結果保持部３６０に保持された抽出結果のデータ構造を示す。抽出結果保持部３６０は、ユーザＩＤ８００と、インシデントＩＤ８１０とを対応付けて保持する。ユーザＩＤ８００は、ユーザを一意に認識するためのＩＤであり、インシデントＩＤ８１０は、インシデントを一意に識別するためのＩＤである。図５に示す例では、ユーザＩＤ「Ｕ００１」の抽出条件により、インシデントＩＤ「Ｉ０００２」、「Ｉ０００３」の２つのインシデントが前回抽出されたことを示している。

【0027】

図２に戻り、抽出部３５０は、インシデント情報保持部３２０に保持された複数のインシデントの中から対象となるユーザの抽出条件に該当するインシデントを抽出する。例えば、図４のユーザＩＤ「Ｕ００１」のユーザの場合、ステータス「クローズ以外」かつ担当者「山田一郎」かつ緊急度「高」の条件に該当するインシデントを抽出する。インシデント情報保持部３２０に保持されているインシデントが図３に示す状態の場合、インシデントＩＤ「Ｉ０００３」、「Ｉ０００７」の２つのインシデントが抽出される。抽出部３５０は、抽出したインシデントの情報を後述する通知部３７０へ渡す。

【0028】

抽出部３５０は、抽出結果保持部３６０に保持された抽出結果（前回の抽出結果）と、今回抽出したインシデントとを比較し、片方にだけ含まれるインシデントの情報を差分インシデントとして通知部３７０へ渡す。例えば、インシデント情報保持部３２０に保持されているインシデント、抽出結果保持部３６０に保持されている抽出結果がそれぞれ図３、５に示す状態であったとする。ユーザＩＤ「Ｕ００１」のユーザを例に考えると、前述のごとく、前回抽出されたインシデントは、インシデントＩＤ「Ｉ０００２」、「Ｉ０００３」の２つのインシデントである。一方、インシデントＩＤ「Ｉ０００３」、「Ｉ０００７」の２つのインシデントが今回抽出される。そうすると、この場合、前回の抽出したインシデントと今回の抽出したインシデントの片方にだけ含まれる、インシデントＩＤ「Ｉ０００２」、「Ｉ０００７」のインシデントの情報を通知部３７０へ渡す。

【0029】

抽出部３５０は、今回抽出した抽出結果を抽出結果保持部３６０に格納する。

【0030】

なお、抽出部３５０が、上述の処理を実行するタイミングは、ユーザが運用端末４００からインシデント管理システム３００にログインしたタイミングや、ログイン後に処理実行させる特定のボタンを押下したタイミング等いくつかのタイミングが考えられる。

【0031】

通知部３７０は、抽出部３５０が今回抽出したインシデントの情報と、差分インシデントの情報をそれぞれユーザに通知する。通知は、抽出結果の画面情報をユーザが使用している運用端末４００に送信して行う。もちろん、ユーザの電子メールアドレス宛に所定の情報を含む電子メールを送信してもよい。

【0032】

図６は、通知部３７０によりユーザが使用している運用端末４００に通知された抽出結果の画面を示す。抽出インシデント一覧９００は、抽出部３５０により今回抽出されたインシデントの情報を表示する。また、差分インシデント一覧９１０は、差分インシデントの情報を表示する。インシデントＩＤにはリンクが張られており、ユーザがリンクをクリックすることによってそのインシデントの詳細情報を示す画面（図示せず）が表示される。

【0033】

以上の構成によるインシデント管理システムの動作を説明する。図７はインシデントが発生したときの処理フローを示し、図８はインシデントを抽出したときの処理フローを示す。これらはインシデント管理システム３００の運用中の処理フローを表すものであり、監視すべきインシデントを抽出するための抽出条件の設定は完了していることを前提とする。また、ユーザＩＤが「Ｕ００１」である運用担当者「山田一郎」（以下「ユーザＵ００１」とよぶ）が抽出処理を実行した場合を例に説明する。

【0034】

インシデント管理システム３００の運用中に、情報処理システム１００の利用者から、システムにログインできないという連絡があったとする。図７のごとく、利用者からの連絡を受けた運用担当者が運用端末４００にその内容を入力すると、インシデント情報受付部３１０がその情報を受け付け、一意のインシデントＩＤと対応付けてインシデント情報保持部３２０にインシデントを登録する（Ｓ１０）。ここでは、図３のごとく、インシデントＩＤ「Ｉ０００７」が割り当てられたとする。ログインできないという事象は業務に直接影響を及ぼすため緊急度として「高」が設定され、担当者には、過去に同じ事象のインシデントに対応したことのある「山田一郎」がアサインされたとする。なお、ここではインシデントの情報を手動で入力する例を示したが、後述の変形例において、この入力を可能な限り自動化する例も示す。

【0035】

図８のごとく、ユーザＵ００１が、自身が監視すべきインシデントの状況を確認するために、抽出処理を実行させる特定のボタンを押下したとする（Ｓ２０）。ここでは、インシデントＩＤ「Ｉ０００７」のインシデント発生後、初めてインシデントの状況を確認したとする。抽出部３５０は、抽出条件保持部３４０に保持された抽出条件にもとづきインシデント情報保持部３２０に保持された複数のインシデントの中からインシデントを抽出し、通知部３７０に渡す（Ｓ３０）。図４のごとく、ユーザＵ００１の抽出条件は、ステータス「クローズ以外」かつ担当者「山田一郎」かつ緊急度「高」であるため、新たに発生したインシデントＩＤ「Ｉ０００７」のインシデントも抽出される。図８に戻り、抽出部３５０は、抽出結果保持部３６０に保持された前回の抽出結果と今回の抽出結果を比較し、片方にだけ含まれるインシデントの情報を差分インシデントとして通知部３７０に渡す（Ｓ４０）。前回抽出時には発生していなかったインシデントＩＤ「Ｉ０００７」のインシデントも差分インシデントとして抽出される。通知部４００は、図６のごとく、抽出部３５０から受け取った今回抽出されたインシデントの情報と差分インシデントを運用端末４００を介してユーザＵ００１に通知する（Ｓ５０）。これにより、ユーザＵ００１はインシデントの緊急度に応じた対応をすることができる。

【0036】

実施の形態のインシデント管理システムによれば、ユーザが監視すべきインシデントを抽出するためにユーザが予め定めた抽出条件によってインシデントが抽出される。このため、ユーザが監視すべきインシデントが新たに発生した場合やインシデントの属性情報が変化し監視すべきインシデントとなった場合にそれらのインシデントを手動で特定してリストに追加したり、逆にインシデントがクローズされたことなどにより監視する必要がなくなった場合にリストから削除したりする、といったユーザ自身によるメンテナンス作業が不要となり、ユーザの負荷が軽減される。また、前回抽出されたインシデントと今回抽出されたインシデントの片方にだけ含まれるインシデントの情報が、今回の抽出結果とともに通知される。このため、前回の抽出結果と今回の抽出結果が異なる場合に、インシデントのどの属性情報が変化したため抽出されなくなったか、どのインシデントが新たに抽出されたかが確認でき、より的確にインシデントの状況を把握できる。

【0037】

以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

【0038】

変形例１
実施の形態では、抽出結果保持部３６０に保持された前回の抽出結果と、今回の抽出結果のうち、片方にだけ含まれるインシデントの情報を差分インシデントとして通知部３７０へ渡す例を示した。しかし、今回抽出した結果にだけ含まれるインシデントの情報は差分インシデントとはせず、前回抽出したインシデントにだけ含まれるインシデントの情報を差分インシデントとして扱い、その差分インシデントの情報を通知部３７０へ渡すようにしてもよい。ユーザが設定した抽出条件は常に十分とは限らない。仮にそれが不十分だった場合、前回は抽出されたが、今回は抽出できなかったインシデントが発生しうる。そうしたインシデントは、監視すべき対象でなくなったために抽出されなくなったわけではなく、単に抽出漏れである。本変形例では、そうしたインシデントを明示することでユーザの確認を促すことができる。

【0039】

変形例２
実施の形態では、抽出結果保持部３６０は前回１回分の抽出結果のみ保持する例を示したが、所定回数分の過去の抽出結果を保持するようにしてもよい。そして、抽出部３５０は、前回以外の過去の抽出結果と今回の抽出結果とを比較するようにしてもよい。これにより、例えば、ある特定の日時だけで発生するインシデント、その他、システムの状況や環境に応じて発生するインシデントを特定できる場合がある。

【0040】

変形例３
実施の形態では、ユーザごとに一つの抽出条件を保持する例を示したが、抽出条件保持部３４０は、それぞれ独立した複数の抽出条件を保持できるようにしてもよい。そして、抽出部３５０で複数の抽出条件にて抽出された結果をディスプレイに並べて表示したり、切り替え可能に表示したりするようにしてもよい。この場合、どのような抽出条件を設定すればより的確に必要なインシデントを抽出できるかを検討しやすくなる。

【0041】

変形例４
インシデントの情報の入力は可能な限り自動化ないし簡略化することが望ましい。本変形例の概要は、インシデントのタイトルをプルダウンメニューから選択できるインシデント情報入力画面を運用端末４００に提供する。そして、インシデント毎に予め緊急度を対応付けておくことで、選択されたインシデントの緊急度を設定する。また、選択されたインシデントと同様のインシデントを過去に対応したことがある運用担当者を、当該インシデントの担当者として設定する。または、各運用担当者が有する技術分野にもとづいて、インシデント毎に予め担当者を対応付けておくことで、選択されたインシデントの担当者を設定するようにしてもよい。

【0042】

具体的には、インシデント情報保持部３２０に、インシデント（発生の予想されるインシデントやこれまでに発生したことのあるインシデント）と、その緊急度とを対応付けた緊急度リストを予め保持しておく。また、インシデントと、そのインシデントを過去に対応したことがある担当者とを対応付けた担当者履歴リストを予め保持しておく。または、各運用担当者が有する技術分野にもとづいて定めた、インシデントと担当者とを対応付けた担当者技術リストを予め保持しておく。

【0043】

インシデント情報受付部３１０は、例えば緊急度リストに記録されているインシデントにもとづき、インシデントのタイトルをプルダウンメニューから選択できるインシデント情報入力画面を運用端末４００に提供する。運用担当者は、インシデント情報入力画面においてプルダウンメニューからインシデントを選択し、インシデントを登録する。インシデント情報受付部３１０は、選択されたインシデントに対応する緊急度を緊急度リストから取得する。同様に、担当者履歴リストまたは担当者技術リストから選択されたインシデントに対応する担当者を取得する。そして、インシデント情報受付部３１０は、インシデントのタイトルと、緊急度と、担当者とを対応付けてインシデント情報保持部３２０に記録する。なお、担当者履歴リストや担当者技術リストにもとづいて自動で担当者を設定すると、特定の運用担当者に偏って設定される場合がある。そのため、例えば、担当者履歴リストや担当者技術リストにもとづいて取得された担当者が既に所定数以上のインシデントの担当者として設定されている場合は、インシデント情報受付部３１０は担当者履歴リストや担当者技術リストによらず、最も担当しているインシデントが少ない運用担当者を担当者として設定する等、特定の担当者に偏らないよう調整する機能を有するようにしてもよい。

【0044】

また、例えば以下のような、監視装置２００が検知できるインシデントについては、インシデントのタイトルの設定さえも自動化することができ、インシデント情報の登録を人手を介さずに実施できる。
・ハードウェア、ミドルウェアの異常停止
・ＣＰＵ、メモリ、ディスク等のハードウェアのリソース逼迫
・ジョブ管理ツールにより実行しているジョブの異常終了

【0045】

具体的には、上記のインシデントが発生したときに監視装置２００が検知するエラーメッセージと、インシデントとを対応付けたエラーメッセージリストをインシデント情報受付部３１０に予め保持する。インシデント情報受付部３１０は、監視装置２００からエラーメッセージを受け付けると、エラーメッセージに対応するインシデントのタイトルをエラーメッセージリストから取得する。

【0046】

請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要件の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。

【符号の説明】

【0047】

１００ 情報処理システム、 ２００ 監視装置、 ３００ インシデント管理システム、 ３１０ インシデント情報受付部、 ３２０ インシデント情報保持部、 ３３０ 抽出条件受付部、 ３４０ 抽出条件保持部、 ３５０ 抽出部、 ３６０ 抽出結果保持部、 ３７０ 通知部、 ４００ 運用端末、 ５００ 運用管理システム。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】