(57)【要約】【課題】ＩＴサービスの運用に関するイベントの情報を、その運用に関わる複数のユーザのそれぞれへ適切に提供することを支援する。【解決手段】運用管理装置１４の通知条件保持部２６は、管理対象装置１０の運用に関するイベントの情報をユーザへ通知すべき状況を定めた通知条件であって、職責が異なる複数のユーザの中から通知先ユーザを定めた通知条件を保持する。判定部２８は、イベントの発生から終了までの状況の推移にもとづいて通知条件が充足されたか否かを判定する。イベント通知部３０は、通知条件が充足された場合に、イベントに関する情報を通知先ユーザの端末へ提供する。【選択図】図４
2014026364.tif 000002
【特許請求の範囲】
【請求項１】
ＩＴサービスの運用に関するイベントについて、その発生から終了までの状況の推移を管理する情報処理装置であって、
前記イベントに関する情報をユーザへ通知すべき状況を定めた通知条件であって、職責が異なる複数のユーザの中から通知先ユーザを定めた通知条件の保持部と、
前記イベントの状況の推移にもとづいて前記通知条件が充足されたか否かを判定する判定部と、
前記通知条件が充足された場合に、前記イベントに関する情報を前記通知先ユーザの端末へ提供するイベント情報提供部と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記通知条件は、前記イベントの発生時に、前記イベントの詳細情報を担当者権限のユーザへ通知することを定めたものであり、かつ、前記イベントの発生後に前記イベントが所定の状況になった場合に、前記イベントの概要情報を管理者権限のユーザへ通知することを定めたものであることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記詳細情報は、前記イベントの状況を終了へ向けて進展させることを支援するためのナレッジ情報である一方、前記概要情報は、前記イベントの現在状況を示す情報であることを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記イベント情報提供部は、担当者権限のユーザが参照中のイベント管理用のウェブページに前記詳細情報を表示させる一方、前記概要情報を記した電子メールを管理者権限のユーザの端末へ送信することを特徴とする請求項２または３に記載の情報処理装置。
【請求項５】
前記イベントはＩＴサービスの運用に関するインシデントもしくは問題であり、
前記通知条件は、前記インシデントもしくは問題の影響範囲が判明した場合に、その影響を受ける関係者へ前記インシデントもしくは問題を示す情報を通知することをさらに定めたものであることを特徴とする請求項２から４のいずれかに記載の情報処理装置。
【請求項６】
ＩＴサービスの運用に関するイベントについて、その発生から終了までの状況の推移を管理する情報処理装置に、
前記イベントに関する情報をユーザへ通知すべき状況を定めた通知条件であって、職責が異なる複数のユーザの中から通知先ユーザを定めた通知条件を保持する機能と、
前記イベントの状況の推移にもとづいて前記通知条件が充足されたか否かを判定する機能と、
前記通知条件が充足された場合に、前記イベントに関する情報を前記通知先ユーザの端末へ提供する機能と、
を実現させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ処理技術に関し、ＩＴサービスの管理を支援する技術に関する。
【背景技術】
【０００２】
ＩＴサービスの運用管理の分野においてＩＴＩＬ（Information Technology Infrastructure Library）が浸透してきている。ＩＴＩＬは、ＩＴサービスの運用において発生したインシデントを管理するためのフレームワークや、ＩＴサービスが抱える問題を管理するためのフレームワーク等を提示する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１１−１１８６８６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ＩＴサービスの運用に関するインシデントや問題等のイベントの発生から、そのクローズに至るまでの間に、イベントの状況は刻々と変化する。本発明者は、イベントの内容や対応の状況に応じて、適切なユーザに対して適切な情報を通知して対応漏れや周知漏れを防止することが、ＩＴサービスに対する運用管理の品質を高めるために重要であると考えた。
【０００５】
しかし、どのタイミングで誰に通知を行なうべきかを、人手で都度判断することは負荷が大きく、判断ミスによる通知漏れのリスクもある。また、通知先のユーザによって、適切な通知方法や通知内容も異なり、これを人手で都度判断することは負荷が大きく、判断ミスが生じるリスクも高いと本発明者は考えた。
【０００６】
本発明は発明者の上記課題認識にもとづきなされたものであり、その主な目的は、ＩＴサービスの運用に関するイベントの情報を、その運用に関わる複数のユーザのそれぞれへ適切に提供することを支援する技術を提供することである。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明のある態様の情報処理装置は、ＩＴサービスの運用に関するイベントについて、その発生から終了までの状況の推移を管理する情報処理装置である。この装置は、イベントに関する情報をユーザへ通知すべき状況を定めた通知条件であって、職責が異なる複数のユーザの中から通知先ユーザを定めた通知条件の保持部と、イベントの状況の推移にもとづいて通知条件が充足されたか否かを判定する判定部と、通知条件が充足された場合に、イベントに関する情報を通知先ユーザの端末へ提供するイベント情報提供部と、を備える。
【０００８】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【０００９】
本発明によれば、ＩＴサービスの運用に関するイベントの情報を、その運用に関わる複数のユーザのそれぞれへ適切に提供することを支援できる。
【図面の簡単な説明】
【００１０】
【図１】実施の形態の情報システムの構成を示す図である。
【図２】管理ページを示す図である。
【図３】管理ページを示す図である。
【図４】図１の運用管理装置の機能構成を示すブロック図である。
【図５】イベント詳細ページを示す図である。
【図６】関連インシデント情報を示す図である。
【図７】通知条件の一例を示す図である。
【図８】通知条件の一例を示す図である。
【図９】イベント通知用のポップアップダイアログを示す図である。
【図１０】イベント通知用のメールデータを示す図である。
【図１１】イベント通知用のメールデータを示す図である。
【図１２】運用管理装置の動作を示すフローチャートである。
【発明を実施するための形態】
【００１１】
ＩＴサービスの運用に伴って発生するインシデント・問題・構成変更等のイベントについて、イベントの状況は、その発生（言い換えれば起票）から終了（言い換えればクローズ・解決・終票）に至るまでの間に刻々と変化する。例えば、起票→原因特定作業→原因特定→担当者による対応→影響範囲特定→影響を受ける関係者による対応→クローズといった複数のステータスに亘り推移することもある。なお、特定のステータスに長時間とどまることも、所定時間以上ステータスの変化がない状態に推移したとして、実施の形態では状況の推移としてとらえる。
【００１２】
本発明者は、イベントの状況が刻々と変化することを前提として、イベントの状況の推移に応じて、適切なタイミングで、適切なユーザへ、適切な情報を提供することがＩＴサービスのＳＬＡ（Service Level Agreement）達成のために重要であると考えた。例えば、インシデントの解析作業や暫定・本格対処を効率的に実施すべき担当者に対しては、それらの作業を支援するための細かい粒度での情報をインシデント発生時に提供することが望ましいと考えた。これに対して、運用管理の全体状況を効率的に管理すべき管理者に対しては、インシデントの現在状況を示す概要レベルの情報を、インシデントの状況が推移した際に提供することが望ましいと考えた。
【００１３】
本発明者は、イベントの状況の推移に応じた適切な情報提供を実現するための具体的な方法はこれまで十分に提案されてこなかったと認識し、以下、実施の形態の情報システム１００を提案する。
【００１４】
図１は、実施の形態の情報システム１００の構成を示す。管理対象装置１０は、エンドユーザのＰＣや携帯情報端末等のエンドユーザ端末１２に対してＩＴサービスを提供する情報処理装置である。例えば、ウェブページによる情報提供サービスを実行するウェブサーバである。運用管理装置１４は、管理対象装置１０の運用に関する各種のイベントを管理する情報処理装置であり、具体的にはＩＴＩＬに則したインシデント管理・問題管理・変更管理（以下、総称して「イベント管理」とも呼ぶ。）に関するデータ処理を実行し、イベントの状況の推移を管理する。
【００１５】
管理対象装置１０には、ＩＴサービス管理アプリケーションのエージェントソフトウェアがインストールされてもよい。また運用管理装置１４には、そのエージェントソフトウェアと適宜通信するマネージャソフトウェアがインストールされてもよい。
【００１６】
運用管理装置１４は、ＩＴサービスマネジメント装置であり、管理対象装置１０に関するイベント管理のための各種情報（以下「管理情報」、「イベント情報」とも呼ぶ。）を運用担当者へ提示するウェブページ（以下「管理ページ」とも呼ぶ。）を担当者ＰＣ１６へ提供して表示させる。管理ページは、運用担当者にイベントの管理情報を参照・編集させるためのウェブページである。
【００１７】
担当者ＰＣ１６は、ＩＴサービス管理部門において担当者権限のユーザ（以下、単に「担当者」と呼ぶ。）により操作される担当者ＰＣ１６ａ、担当者ＰＣ１６ｂ、担当者ＰＣ１６ｃの総称であり、運用管理装置１４から提供された管理ページをディスプレイに表示させる。担当者は、管理対象装置１０に関するイベントを解決済（クローズ）のステータスへ移行させるための解析作業等（以下、「イベント解決作業」とも呼ぶ。）を実施すべき職責を有する。典型的に担当者は、イベント解決作業のために管理ページを常時表示させ、イベント管理のための管理情報を随時参照し、また入力する。
【００１８】
図２および図３は管理ページを示す。図２は、担当者別の担当インシデントを一覧表示した管理ページ１１０を示し、具体的には担当者「野村太郎」に割り当てられた複数インシデントのリストを示す管理ページ１１０を示している。図３は、システム別の発生インシデントを一覧表示した管理ページ１１０を示しており、具体的には管理対象装置１０としての「営業管理システム」で発生した複数インシデントのリストを示す管理ページ１１０を示している。なお運用担当者が図２もしくは図３の管理ページ１１０から特定のインシデントを選択すると、そのインシデントの詳細情報を示すウェブページ（以下、「イベント詳細ページ」とも呼ぶ。）が表示される。運用担当者は、イベント詳細ページにおいて、インシデントの詳細情報を随時参照し、また入力する。イベント詳細ページは図５に関連して後述する。
【００１９】
図１に戻り、担当者ＰＣ１６ａ〜担当者ＰＣ１６ｃは、職責が異なる複数の運用担当者のそれぞれに割り当てられたものである。具体的には、担当者ＰＣ１６ａはイベントへの初期対応やイベント情報の更新を担当するオペレータ、担当者ＰＣ１６ｂはハードウェア担当者、担当者ＰＣ１６ｃはネットワーク担当者により操作されることとする。
【００２０】
管理者ＰＣ１８は、ＩＴサービス管理部門の管理者権限を有するユーザ（以下、単に「管理者」と呼ぶ。）により操作されるＰＣである。管理者は、管理対象装置１０についてのイベントの状況を把握し、運用担当者による作業を監督する職責を有する。典型的に管理者は、会議等で端末を離席することも多く、管理ページ１１０を常時確認することはなく、管理対象装置１０に関するイベントの進捗状況を、運用管理装置１４から送信された電子メールにより確認する。
【００２１】
図１の各装置は、ＬＡＮ・ＷＡＮ・インターネット等の通信網を介して接続される。また管理対象装置１０・運用管理装置１４・担当者ＰＣ１６・管理者ＰＣ１８は、システム運用サービス（アウトソーシングサービス）を提供するＳＩ企業に設置されてもよく、各装置の物理的な設置位置は問わない。
【００２２】
図４は、図１の運用管理装置１４の機能構成を示すブロック図である。運用管理装置１４は、イベント情報保持部２０と、管理画面提供部２２と、イベント情報更新部２４と、通知条件保持部２６と、判定部２８と、イベント通知部３０を備える。
【００２３】
本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、図４の各機能ブロックは、ＩＴサービス管理のためのマネージャソフトウェアの一部を構成するプログラムモジュールとして記録媒体に格納され、運用管理装置１４のストレージへインストールされてもよい。そして、運用管理装置１４のメインメモリに読み込まれて、運用管理装置１４のＣＰＵが実行することで、各機能ブロックの機能が発揮されてもよい。
【００２４】
イベント情報保持部２０は、管理対象装置１０の運用に関するイベント情報、具体的には、管理対象装置１０の運用に伴うインシデント管理・問題管理・変更管理のための情報を保持する記憶領域である。例えば、図２および図３の管理ページ１１０の各種情報項目に対して運用担当者が入力したデータや、運用管理装置１４のマネージャソフトウェアや管理対象装置１０のエージェントソフトウェアが自動設定したイベント情報を保持する。
【００２５】
本実施の形態のイベント情報は、イベントＩＤ（例えばインシデントＩＤ）、イベント発生システム名（すなわち管理対象装置１０の名称）、タイトル、事象（インシデントや問題の内容）、ステータス、優先度、原因、経過情報、影響範囲、関連する連絡先、起票日時、最終更新日時等の情報項目を含むものである。イベント情報は、例えばＩＴＩＬで規定・推奨される管理項目を含むものであってよい。また上記のステータスは、「新規」→「原因分析中」→「原因分析完了」→「対策中」→「クローズ」等の状態を含むものとする。担当者は、担当者ＰＣ１６に管理ページを表示させてイベント情報を参照し、その管理ページを介してイベント情報を設定・更新する。
【００２６】
管理画面提供部２２は、担当者ＰＣ１６から管理ページの提供要求を受け付けると、イベント情報保持部２０が保持するイベント情報を、予め定められたフォーマットにしたがって配置した管理ページのデータを要求元の担当者ＰＣ１６へ送信して表示させる。また管理画面提供部２２は、図２および図３で示したイベントの一覧ページで担当者が特定のイベントを選択した場合に、選択イベントのＩＤを担当者ＰＣ１６から受け付け、選択イベントの情報をイベント情報保持部２０から取得する。そして選択イベントの情報を所定のフォーマットにしたがって配置したイベント詳細ページのデータを設定し、イベント詳細ページのデータを担当者ＰＣ１６へ送信して表示させる。
【００２７】
図５は、イベント詳細ページを示す。同図のイベント詳細ページ１３０には、ＩＤ「００２３７」のインシデントの詳細情報が配置されている。管理画面提供部２２は、イベント詳細ページ１３０を提供した際にそのイベントＩＤと最終提供日時を対応づけて所定の記憶領域へ記録しておく。管理画面提供部２２は、新たにイベント詳細ページ１３０を提供する際に、そのイベントＩＤと対応づけられた最終提供日時を記録済みか否かを確認し、記録済みの場合、その最終提供日時とイベント情報の最終更新日時とを比較する。そしてイベント情報の最終更新日時の方が新しい場合、言い換えれば、あるイベントのイベント詳細ページ１３０を最後に提供した後に、そのイベント情報が更新されていた場合、その旨を示す情報更新インジケータ１３４をイベント詳細ページ１３０に配置する。
【００２８】
また管理画面提供部２２は、イベント詳細ページ１３０での表示対象イベントについて、そのステータスを解決へ向けて進展させるためのナレッジ情報であり、言い換えれば、イベントに対する担当者の作業を支援するための参考情報を特定する。例えば、表示対象イベントのタイトル欄や内容欄に記録された文字列（に含まれるキーワード）と整合する文字列が記録された過去のインシデントや問題に関する情報や、ＦＡＱ（Frequently Asked Questions）情報をナレッジ情報として特定してもよく、その他、公知の手法によりナレッジ情報を特定してもよい。管理画面提供部２２は、特定したナレッジ情報へのリンク文字列をナレッジ情報フィールド１３２へ設定する。
【００２９】
図５のナレッジ情報フィールド１３２では、検知されたネットワーク障害を解決するための作業手順書へのリンクと、関連する他のインシデントの情報へのリンクが含まれる。すなわちナレッジ情報として、作業手順書と関連インシデント情報を担当者へ提示している。担当者が作業手順書へのリンクをクリックすると、運用管理装置１４もしくは他の情報サーバに保持された作業手順書ファイルが、担当者ＰＣ１６へダウンロードされて表示される。また、担当者が関連インシデント情報へのリンクをクリックすると、運用管理装置１４もしくは他の情報サーバに保持された関連インシデント情報が担当者ＰＣ１６のウェブブラウザ上に表示される。図６は関連インシデント情報を示し、具体的には、インシデント対応におけるＦＡＱ情報のウェブページを提供する例を示している。
【００３０】
図４に戻り、イベント情報更新部２４は、管理ページ（例えばイベント詳細ページ）の各情報項目に運用担当者が入力したイベント情報を担当者ＰＣ１６から取得し、イベント情報保持部２０が保持するイベント情報を更新する。言い換えれば、運用担当者による管理ページへの入力データを、イベント情報保持部２０が保持するイベント情報へ反映させる。
【００３１】
また管理対象装置１０から自動的にイベント情報が送信される場合、イベント情報更新部２４は、そのイベント情報を受け付けてイベント情報保持部２０が保持するイベント情報を更新する。イベント情報の取得・更新処理は、公知のＩＴサービス管理アプリケーションの仕組み（エージェントソフトウェアとマネージャソフトウェアの連携）により実現されてもよい。
【００３２】
通知条件保持部２６は、イベント情報保持部２０に保持されたイベントに関する情報をオペレータや管理者、関係者（例えばハードウェア担当者やネットワーク担当者）へ通知すべき状況を定めた通知条件を保持する。通知条件は、イベント情報を通知すべきタイミング、通知先ユーザ、通知内容、および通知方法を定めたものであると言える。図７、８に関連して後述するように、実施の形態において通知条件は、通知処理の実施を決定する条件である決定条件と、通知タイミング・通知先ユーザ・通知方法・通知内容を定めた通知規則と、決定条件と通知規則との対応関係を定めたマッピング規則の組合わせにより実現される。
【００３３】
判定部２８は、イベント情報保持部２０に保持されたイベントの状況の推移にしたがって、通知条件保持部２６の通知条件が充足されたか否かを判定する。具体的には、判定部２８は、イベント情報保持部２０のイベント情報を常時監視し、イベント情報がオペレータにより更新、もしくは、エンドユーザ端末１２のエージェントソフトウェアにより自動更新されたことを検出する。判定部２８は、情報更新がなされたイベントごとに、通知条件保持部２６の決定条件を充足するか否か、および、通知規則が定める通知タイミングに至ったか否かを判定し、両方を満たす場合に通知条件が充足されたと判定する。
【００３４】
通知条件が充足された場合、判定部２８は、通知規則で定められた通知先ユーザへ、通知規則で定められた通知方法により、通知規則で定められた情報を通知するようイベント通知部３０へ指示する。具体的には、イベント情報の通知を指示するデータ（以下、「通知指示」とも呼ぶ。）をイベント通知部３０へ送出する。通知指示では、状況が更新されたイベント、言い換えれば、通知対象のイベントのＩＤ、例えばインシデントＩＤも指定する。なお、判定部２８は、情報更新がなされたイベントごとに、通知条件保持部２６の決定条件を充足するか否かを判定し、決定条件が満たされた場合に通知条件が充足されたものとして、通知規則が定めるタイミングにおいて、決定条件が満たされたイベントの情報を通知するようイベント通知部３０へ指示するとも言える。
【００３５】
以下、図７および図８を参照して、判定部２８の処理の具体例を説明する。
図７は通知条件の一例を示す。図７（ａ）は決定条件テーブルを示し、図７（ｂ）は通知規則テーブルを示し、図７（ｃ）はマッピング規則テーブルを示している。ここで、Ａ社の営業システムにてハード障害のインシデントが発生したケースを考える。このインシデントの情報がイベント情報保持部２０に新規に登録されると、判定部２８は、まず決定条件テーブルを参照し、優先順位が高い順に（優先順位「１」が最も高い優先順位とする）決定条件が充足されたか否かを順次判定する。ここでは優先順位「１」の決定条件「ｘｘｘ１」が充足されたと判定し、この場合、優先順位「１」の決定条件が充足されたため、優先順位「２」以下の決定条件の充足判定はスキップする。
【００３６】
判定部２８は、次にマッピング規則テーブルを参照し、決定条件「ｘｘｘ１」に対応づけられた通知規則「ｙｙｙ１」を特定する。そして通知規則テーブルを参照し、イベントの状況（例えばステータス推移の状況）が、通知規則「ｙｙｙ１」が定める通知タイミングを充足したか否かを判定する。
【００３７】
図７の例では、判定部２８は、起票から（例えばステータスが「新規」になってから」）１時間が経過した場合に、管理者権限のユーザ（管理者ＰＣ１８）へ、電子メールにより、管理者向けレイアウト（時間経過通知用のフォーマット）にしたがった文面を通知すべき旨をイベント通知部３０へ指示する。なお判定部２８は、イベントが起票されたこと、例えばステータスが「新規」のイベント情報がイベント情報保持部２０へ新たに記録されたことを最初に検出した際に、通知規則の通知タイミングで規定される時間（例えば１時間）のタイマを起動してもよい。そしてタイマにより１時間の経過を検出した場合に、通知タイミング「起票から１時間」が充足されたと判定してもよい。
【００３８】
また通知規則「ｙｙｙ１」について、判定部２８は、インシデントのステータスが「原因分析完了」となった場合、別の態様としてはインシデント情報の原因コード欄に値が設定された場合に、その原因に関連する担当者へ、管理ページを介したウェブ通知にて、作業手順書の情報を通知すべき旨をイベント通知部３０へ指示する。例えば、原因コードがハードウェア障害を示すものである場合、ハードウェア担当者の端末（担当者ＰＣ１６ｂ）を通知先としてもよく、原因コードがネットワーク障害を示すものである場合、ネットワーク担当者の端末（担当者ＰＣ１６ｃ）を通知先としてもよい。
【００３９】
図８も通知条件の一例を示す。図８（ａ）は決定条件テーブルを示し、図８（ｂ）は通知規則テーブルを示し、図８（ｃ）はマッピング規則テーブルを示している。ここでは第１ステップとして、管理対象装置１０である営業システムにおいてハード障害のアラートを自動検知し、その旨を示すインシデントのデータが、イベント情報更新部２４を介して、運用管理装置１４のイベント情報保持部２０へ自動登録されたこととする。
【００４０】
このとき判定部２８は、決定条件テーブルを参照して、決定条件「ａａａ１」が充足されたと判定し、マッピング規則テーブルを参照して、決定条件「ａａａ１」に対応づけられた通知規則「ｂｂｂ１」を特定する。判定部２８は、通知規則テーブルを参照して、通知規則「ｂｂｂ１」が定める通知タイミングに至ったと判定し、オペレータ（担当者ＰＣ１６ａ）へ、管理ページを介したウェブ通知にて、初期対応手順を示す文面を通知すべき旨をイベント通知部３０へ指示する。
【００４１】
次に第２ステップとして、オペレータがインシデント情報の原因コードを「ハード障害」に設定し、ステータスを「対応中」に設定したとする。このとき判定部２８は、決定条件「ａａａ１」は非充足となる一方、決定条件「ａａａ２」が充足されたと判定し、マッピング規則テーブルを参照して、決定条件「ａａａ２」に対応づけられた通知規則「ｂｂｂ２」を特定する。判定部２８は、通知規則テーブルを参照して、通知規則「ｂｂｂ２」が定める通知タイミング「即時」を充足したと判定する。そして、ハードウェア担当者（担当者ＰＣ１６ｂ）へ、電子メールにより、関係者向けレイアウト（障害原因通知用フォーマット）にしたがった文面を通知すべき旨をイベント通知部３０へ指示する。
【００４２】
なお第２ステップにおいて、通知規則「ｂｂｂ２」における通知タイミング「ステータス変更から１時間経過」のレコードは非充足であるが、判定部２８は、１時間のタイマを起動する。例えば、上記レコードにタイマを設定すべきことを示すフラグが予め設定されていてもよく、判定部２８はそのフラグを参照して、通知タイミングが規定する時間をカウントするタイマを起動してもよい。
【００４３】
次に第３ステップとして、原因判明から１時間経過したものの状況に変化がない、具体的には、第２ステップにおいて設定した１時間のタイマが終了しても、インシデント情報のステータスに変化がないとする。このとき判定部２８は、決定条件テーブルを参照して、決定条件「ａａａ２」が充足されたと判定し、マッピング規則テーブルを参照して、決定条件「ａａａ２」に対応づけられた通知規則「ｂｂｂ２」を特定する。判定部２８は、通知規則テーブルを参照して、通知規則「ｂｂｂ２」が定める通知タイミング「ステータス変更から１時間経過」を充足したと判定する。そして、管理者（例えば営業システムの管理者であり、管理者ＰＣ１８）へ、電子メールにより、管理者向けレイアウトにしたがった文面を通知すべき旨をイベント通知部３０へ指示する。
【００４４】
次に第４ステップとして、インシデントが示す障害の影響範囲が特定されて、インシデントのステータスが「影響範囲特定完了」へ変更されたとする。このとき判定部２８は、決定条件テーブルを参照して、決定条件「ａａａ２」が充足されたと判定し、マッピング規則テーブルを参照して、決定条件「ａａａ２」に対応づけられた通知規則「ｂｂｂ２」を特定する。判定部２８は、通知規則テーブルを参照して、通知規則「ｂｂｂ２」が定める通知タイミング「ステータスが「影響範囲特定完了」」を充足したと判定する。そして、インシデントが示す障害の影響を受ける関係者（ここではネットワーク担当者であり、担当者ＰＣ１６ｃとする）へ、電子メールにより、関係者向けレイアウト（影響範囲通知用フォーマット）にしたがった文面を通知すべき旨をイベント通知部３０へ指示する。
【００４５】
図４に戻り、イベント通知部３０は、判定部２８からの通知指示にしたがって、イベント情報保持部２０に保持されたイベント情報を担当者ＰＣ１６および管理者ＰＣ１８へ送信する。例えば、通知指示で指定されたイベントの管理情報の中から、通知指示で指定されたフォーマットにより規定された情報項目を抽出し、抽出したイベント情報を、通知指示で指定された方法（手段）を介してオペレータや関係者、管理者へ提供する。イベント通知部３０はウェブ通知部３２とメール通知部３４を含む。
【００４６】
ウェブ通知部３２は、判定部２８からの通知指示において通知方法が「ウェブ」と指定された場合に、通知指示で指定されたイベントＩＤで特定されるイベント情報をイベント情報保持部２０から取得する。ウェブ通知部３２は、イベント情報を担当者ＰＣ１６でポップアップ表示させるためのデータ、例えばイベント情報を含むポップアップダイアログを担当者ＰＣ１６のウェブブラウザに表示させるコードを含むＪＡＶＡ  Ｓｃｒｉｐｔ（登録商標）プログラムを設定する。そして、設定したポップアップ表示用データを担当者ＰＣ１６へ送信して、管理ページに重ねてポップアップダイアログを表示させる。
【００４７】
図９は、イベント通知用のポップアップダイアログを示す。実施の形態のポップアップダイアログ１２０は、新規イベントの情報として、インシデントのＩＤ、タイトル、および詳細表示ボタン１２２を含む。ウェブ通知部３２は、詳細表示ボタン１２２に、判定部２８からの通知指示で指定されたイベントＩＤで特定されるイベントの情報を表示するイベント詳細ページへのリンクを設定する。これにより、ポップアップダイアログ１２０において担当者が詳細表示ボタン１２２をクリックすると、ポップアップダイアログ１２０で通知されたイベントの情報を示すイベント詳細ページ１３０が表示される。
【００４８】
ここでポップアップダイアログを担当者ＰＣ１６に表示させる方法を説明する。担当者ＰＣ１６ａにおいて、オペレータは管理ページを常時表示させた状態で作業を行なう。実施の形態の管理ページには、定期的（例えば１分が経過するたび）に運用管理装置１４へアクセスし、イベントの更新確認を行なうプログラムコード（例えばＡｊａｘコード）が設定される。判定部２８からの通知指示において、通知先「オペレータ」・通知方法「ウェブ」が指定された場合に、ウェブ通知部３２は、通知指示にしたがってポップダイアログのプログラムを設定しておく。そして、担当者ＰＣ１６ａからイベントの更新確認を受け付けた場合に、ポップアップダイアログのプログラムを担当者ＰＣ１６ａへ送信し、そのプログラムを担当者ＰＣ１６ａのウェブブラウザに実行させる。これにより、担当者ＰＣ１６ａにおいてポップアップダイアログを表示させ、イベント情報を通知する。
【００４９】
図４に戻り、メール通知部３４は、判定部２８からの通知指示において通知方法が「メール」と指定された場合に、通知指示で指定されたイベントＩＤで特定されるイベント情報をイベント情報保持部２０から取得する。そして、通知指示で指定されたメールフォーマットにしたがってイベント情報を配置したメールデータを、通知指示で指定されたユーザの端末（担当者ＰＣ１６や管理者ＰＣ１８）へ送信する。
【００５０】
図１０は、イベント通知用のメールデータを示す。同図は、管理者ＰＣ１８へ送信されるメールデータである管理者向けメール１５０を示している。メール通知部３４は、通知指示で指定された宛先が管理者（管理者権限ユーザ）であった場合、管理者向けに予め定められた文書フォーマットにしたがって、イベント情報のうち、イベントの概要を示す情報（具体的にはイベントの現在のステータスや優先度、イベント発生からの経過情報）を配置したメール文書を設定する。そして、そのメール文書を管理者ＰＣ１８へ送信し、管理者にイベントの概要情報を非同期に確認させる。例えば、図８の通知規則「ｂｂｂ２」が充足された場合は、ステータス変更から１時間が経過したものの次のステータスへの変更が滞っている状況であることを示す経過情報が設定されてもよい。
【００５１】
図１１も、イベント通知用のメールデータを示す。同図は、ハードウェア担当者の担当者ＰＣ１６ｂやネットワーク担当者の担当者ＰＣ１６ｃへ送信されるメールデータとして、具体的には、関係者へイベント情報を通知するための関係担当者向けメール１５２を示している。メール通知部３４は、通知指示で指定された宛先が関係者（担当者権限ユーザで、例えばインシデントによる影響を受ける分野の担当者）であった場合、関係者向け（影響範囲通知用）の文書フォーマットにしたがって、イベント情報のうち、イベントの影響範囲に関する情報（具体的には、事象や原因、影響範囲、関連連絡先）を配置したメール文書を設定する。そして、そのメール文書を担当者ＰＣ１６（図１１の例では担当者ＰＣ１６ｃ）へ送信し、関係者（図１１の例ではネットワーク担当者）にイベントの影響範囲を非同期に確認させる。
【００５２】
なお通知条件で規定されるメールフォーマット、すなわち職責や権限が異なるユーザ向けの複数のメールフォーマットは、図示しない所定の記憶領域に予め保持されてもよい。例えば、メール通知部３４は、図１０および図１１の墨付き括弧で示すフィールドに、項目名に対応するイベント情報を設定することにより、メールフォーマットにしたがったメール文書を作成してもよい。
【００５３】
以上の構成による動作を以下説明する。
図１２は、運用管理装置１４の動作を示すフローチャートである。同図には不図示であるが、管理ページ（例えば図２・図３の管理ページ１１０や図５のイベント詳細ページ１３０）の提供要求を担当者ＰＣ１６から受け付けると、管理画面提供部２２は、イベント情報保持部２０が保持するイベント情報を配置した管理ページのデータを設定する。そして管理ページのデータを担当者ＰＣ１６へ提供して表示させる。
【００５４】
担当者が管理ページ（典型的には図５のイベント詳細ページ１３０）における各イベント情報の項目において、原因コードやステータス、影響範囲、経過情報等のデータを入力・変更すると、イベント情報更新部２４は、その入力データを担当者ＰＣ１６から受け付けてイベント情報保持部２０へ格納する。また、管理対象装置１０にインストールされたエージェントソフトウェアがイベント情報を運用管理装置１４のマネージャソフトウェアへ通知すると、イベント情報更新部２４は、そのイベント情報をイベント情報保持部２０へ格納する。運用管理装置１４は、管理対象装置１０に関するイベント管理のステータスが終了に至るまで、当該イベントの進捗状況を管理する。例えば、イベント管理のステータスに応じた所定のタスクを運用担当者へ割り当て、そのタスク情報を担当者ＰＣ１６へ通知してもよい。
【００５５】
運用管理装置１４はイベント管理処理の終了を指示するユーザ操作を受け付けると（Ｓ１０のＹ）、すなわち運用管理装置１４においてＩＴサービス管理アプリケーションの実行がユーザにより終了されると、本図のフローを終了する。イベント管理処理が継続され（Ｓ１０のＮ）、イベント情報が更新されると（Ｓ１２のＹ）、判定部２８は、更新されたイベントについて、その発生から終了までの状況の推移が、通知条件保持部２６が保持する通知条件を充足したか否かを確認する（Ｓ１６）。イベント情報が未更新であっても（Ｓ１２のＮ）、先に決定条件を充足したイベントについて通知タイミングで規定された時間の経過を検出した場合に（Ｓ１４のＹ）、Ｓ１６を実行する。上記の時間経過を未検出であれば（Ｓ１４のＮ）、Ｓ１０へ戻る。
【００５６】
特定のイベントが通知条件を充足したことを判定部２８が検出し（Ｓ１８のＹ）、その通知条件が通知方法としてウェブ通知を規定していた場合（Ｓ２０のＹ）、ウェブ通知部３２は、通知条件を充足したイベントの情報を、担当者ＰＣ１６で常時表示されている管理ページにポップアップ表示させる（Ｓ２２）。このとき、ポップアップダイアログで表示されるイベント情報がリンク先とするイベント詳細ページのデータとして、管理画面提供部２２は、対応者がイベントの状況を解決に向けて進展させることを支援するためのナレッジ情報を設定する。その一方、充足された通知条件が通知方法としてメール通知を規定していた場合（Ｓ２０のＮ）、メール通知部３４は、通知条件を充足したイベントの情報を、通知条件が指定する宛先へ電子メールにより通知する（Ｓ２４）。通知条件を充足したイベントが未検出であれば（Ｓ１８のＮ）、Ｓ１０に戻る。
【００５７】
例えば、宛先が管理者の場合、イベントの進捗状況や経過情報を示す概要情報をメール通知する。また宛先がイベントが示す事象の影響を受ける関係者の場合、イベントが示す事象の影響範囲を示す情報をメール通知する。なお、関係者もオペレータと同様に常時管理ページを表示させて作業する場合は、通知方法としてウェブ通知が規定されてもよいことはもちろんである。
【００５８】
本実施の形態の運用管理装置１４によると、イベントの発生からクローズに至るまでの一連のイベント管理フローの中で、イベントの内容や対応状況に応じて、適切な通知先へ、適切なタイミングで、適切な方法により、適切な情報を提供することができる。これにより、イベントの対応に関わる複数のユーザであり（例えばオペレータ、管理者、関係者）の作業の効率化を実現でき、ＳＬＡ達成率を向上させやすくなる。
【００５９】
具体的には、運用管理装置１４によると、イベントの状況の推移に応じた情報通知を自動化することで人為的なミスを低減でき、例えば、担当者による対応漏れや、関係者への周知漏れ、管理者への報告漏れ等の発生を抑制できる。また、通知先別に通知内容を自動的に選別することにより、必要な情報の通知漏れや、逆に不必要な情報や過剰な情報の提供を抑制できる。すなわち、立場や職責、権限等が異なる複数のユーザのそれぞれが必要とする情報を、必要なタイミングで、効率的な確認を支援する態様で提供することができる。
【００６０】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００６１】
請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。例えば、請求項に記載のイベント情報提供部は、実施の形態で示した管理画面提供部２２とイベント通知部３０の連携により実現されてよい。
【符号の説明】
【００６２】
１０  管理対象装置、  １４  運用管理装置、  １６  担当者ＰＣ、  １８  管理者ＰＣ、  ２０  イベント情報保持部、  ２２  管理画面提供部、  ２４  イベント情報更新部、  ２６  通知条件保持部、  ２８  判定部、  ３０  イベント通知部、  １００  情報システム。
【図１】
2014026364.tif 000003
【図２】
2014026364.tif 000004
【図３】
2014026364.tif 000005
【図４】
2014026364.tif 000006
【図５】
2014026364.tif 000007
【図６】
2014026364.tif 000008
【図７】
2014026364.tif 000009
【図８】
2014026364.tif 000010
【図９】
2014026364.tif 000011
【図１０】
2014026364.tif 000012
【図１１】
2014026364.tif 000013
【図１２】
2014026364.tif 000014