インシデント管理システム
【課題】情報処理システムにおいて発生したインシデントの管理を支援する。
【解決手段】フォーマット保持部３２４は、対応者に対するインシデントの通知に使用すべき通知ファイルのフォーマットを保持する。取得部３０４は、通知するインシデントに関して、フォーマットで指定された属性情報を取得し、生成部３０６はそれらが記入された通知ファイルを生成する。送信部３０８は、通知ファイルを電子メールに添付して対応者に送信する。受信部３１０は、対応者により回答が記入された通知ファイルが添付された電子メールを受信する。抽出部３１２は、回答が記入された通知ファイルから回答を抽出し、更新部３１４は、抽出部３１２が抽出した回答内容をインシデントの属性情報として反映する。
【解決手段】フォーマット保持部３２４は、対応者に対するインシデントの通知に使用すべき通知ファイルのフォーマットを保持する。取得部３０４は、通知するインシデントに関して、フォーマットで指定された属性情報を取得し、生成部３０６はそれらが記入された通知ファイルを生成する。送信部３０８は、通知ファイルを電子メールに添付して対応者に送信する。受信部３１０は、対応者により回答が記入された通知ファイルが添付された電子メールを受信する。抽出部３１２は、回答が記入された通知ファイルから回答を抽出し、更新部３１４は、抽出部３１２が抽出した回答内容をインシデントの属性情報として反映する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ処理技術に関し、特に、情報処理システムのインシデント管理を支援する技術に関する。
【背景技術】
【０００２】
ＩＴインフラが幅広いユーザ層に活用されるようになってきているなか、ＩＴサービスマネジメントがこれまで以上に重要になってきている。それに伴い、ＩＴサービスマネジメントを実行する上での業務プロセスの効率化が求められている。ＩＴサービスマネジメント・運用規則に関して、英国商務局（ＯＧＣ:Office of Government Commerce）はＩＴＩＬ（Information Technology Infrastructure Library）（登録商標）と呼ばれるベストプラクティス集を公表しており、最近では、ＩＴＩＬに従ってＩＴサービスマネジメントの改善に取り組む企業が増えている。
【０００３】
ＩＴＩＬの中核の一つにサービスサポートがある。サービスサポートは日常的なシステム運用およびユーザサポートに関して記載されたもので、一つの機能と五つのプロセスからなる。機能としては、ユーザからの問い合わせ窓口となるサービスデスク、プロセスとしてはインシデント管理、問題管理、変更管理、リリース管理および構成管理が規定されている。
【０００４】
サービスデスク業務では、ユーザからどのような問い合わせがあったのか、それに対してどのように対応したのか、その問い合わせは処理が終わってクローズしたのか、といった様々なことを記録していく。このようなサービスデスク業務を支援するため、ユーザからの問い合わせをインシデントとして蓄積していくインシデント管理システムが実用化されている（例えば、特許文献１）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−１２９９７３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
インシデントの中にはサービスデスク業務を行う運用部門の担当者（以下「運用担当者」とよぶ）では解決できないものもある。このようなインシデントについては、ハードウェア、ミドルウェア、業務アプリケーションを保守する外部の企業（以下、「ベンダ」とよぶ）に対応を依頼する場合がある。この場合、運用担当者はどのベンダに対応を依頼すべきかの切り分けを行った後、ベンダに対応を依頼をする。
【０００７】
運用部門とベンダのような企業間の通信では、セキュリティ上の制約の少ない電子メールだけ許可されることがある。この場合、ベンダはネットワークを介して運用部門のインシデント管理システムにアクセスできない。そのためベンダに対応を依頼するときには、運用担当者は、インシデント管理システムで管理しているインシデントの情報のうち必要な情報をメールに転記し、ベンダに送る必要がある。また、インシデントに対しどのように対応すればよいか、どのように対応したかといった回答をベンダからメールで受け付け、運用担当者がそれをインシデント管理システムに反映する必要がある。このような作業は、多数のインシデントを管理しなければならない運用担当者にとっては大きな負荷となる。
【０００８】
本発明はこうした課題に鑑みてなされたものであり、その主な目的は、情報処理システムにおいて発生したインシデントの効率的な管理を支援するための技術を提供することにある。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、本発明のある態様のインシデント管理システムは、情報処理システムにおいて発生したインシデントに関する複数の属性情報を保持するインシデント情報保持部と、インシデントの対応者に対するインシデントの通知に使用すべき通知ファイルのフォーマットを保持するフォーマット保持部と、インシデントの複数の属性情報の中からフォーマットで指定された属性情報をインシデント情報保持部から取得する取得部と、取得部が取得した属性情報が記入された通知ファイルを生成する生成部と、生成部が生成した通知ファイルを電子メールに添付して対応者の電子メールアドレス宛に送信する送信部と、送信部が送信した通知ファイルであって、フォーマットで指定された箇所に対応者により回答内容が記載された通知ファイルを添付した電子メールを受信する受信部と、受信部が受信した電子メールに添付された通知ファイルから対応者が記載した回答内容を抽出する抽出部と、抽出部が抽出した回答内容をインシデントの属性情報として反映する更新部と、を備える。
【００１０】
本発明の別の態様もまた、インシデント管理システムである。本システムは、情報処理システムにおいて発生したインシデントに関する複数の属性情報を保持するインシデント情報保持部と、照会元のユーザに対するインシデントの属性情報の提供に使用される情報提供ファイルのフォーマットであって、複数の照会元のユーザに対応した複数種類のフォーマットを保持するフォーマット保持部と、照会元のユーザから送信されたインシデントの照会を求める電子メールを受信する受信部と、照会元のユーザから照会を求める電子メールを受信した場合、インシデントの複数の属性情報の中から、フォーマットで指定された属性情報を取得する取得部と、取得部が取得した属性情報が記入された情報提供ファイルを生成する生成部と、生成部が生成した情報提供ファイルを電子メールに添付して照会元のユーザの電子メールアドレス宛に送信する送信部と、を備える。
【００１１】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１２】
本発明によれば、情報処理システムにおいて発生したインシデントの効率的な管理を支援できる。
【図面の簡単な説明】
【００１３】
【図１】実施の形態のインシデント管理システムを含む運用管理システムの全体構成を示す図である。
【図２】図１のインシデント管理システムの機能構成を示す図である。
【図３】インシデント情報画面を示す図である。
【図４】図２の対応関係保持部に保持された対応関係情報のデータ構造を示す図である。
【図５】図２のフォーマット保持部に保持されたフォーマットの一例を示す図である。
【図６】図２のフォーマット保持部に保持された対応者リストのデータ構造を示す図である。
【図７】実施の形態の通知ファイルの一例を示す図である。
【図８】図２の回答保持部に保持された通知ファイルの一例を示す
【図９】対応者の回答が反映されたインシデントを表示するインシデント情報画面を示す図である。
【図１０】実施の形態において対応者にインシデントの対応を依頼するときの処理の流れを示すフローチャートである。
【図１１】実施の形態において対応者から回答を受信したときの処理の流れを示すフローチャートである。
【図１２】実施の形態において対応者からの回答内容をインシデントの属性情報として反映するときの処理の流れを示すフローチャートである。
【図１３】図２のフォーマット保持部に保持された照会ユーザリストのデータ構造を示す図である。
【図１４】実施の形態においてインシデントの照会要求があったときの処理の流れを示すフローチャートである。
【発明を実施するための形態】
【００１４】
実施の形態に係るインシデント管理システムの概要は以下のとおりである。
本インシデント管理システムは、運用部門では解決できないインシデントについてその内容を通知してベンダに対応を依頼する作業と、インシデントの原因が何であるか、インシデントに対しどのように対応すればよいか、どのように対応したかといったベンダからの回答内容をインシデントに反映する作業を支援する（以下「対応依頼支援機能」とよぶ）。この目的のために、本システムは、インシデントの対応をベンダに依頼する際に、インシデントの内容をベンダに通知するのに使用する通知ファイルのフォーマットを保持する。本システムは、通知するインシデントに関して、フォーマットで指定された属性情報を取得し、それらが記入された通知ファイルを生成する。生成した通知ファイルを電子メールに添付して対応を依頼するベンダ（以下「対応者」とよぶ）に送信する。そして、対応者により回答が記入された通知ファイルが添付された電子メールを受信すると、そのファイルから対応者が記入した回答を抽出し、抽出した内容をインシデントの属性情報として反映する。
【００１５】
また、本システムは、当該システムにアクセスできない者からインシデントの状況についての照会要求があったときに、インシデントの情報を提供する作業を支援する（以下「インシデント照会機能」とよぶ）。この目的のために、本システムは、照会元のユーザにインシデントの情報を提供するのに使用する情報提供ファイルのフォーマットを保持する。本システムは、照会元のユーザからインシデントの照会を求めるメールを受信する。そして、照会を求められたインシデントに関して、フォーマットで指定された属性情報を取得し、それらが記入された情報提供ファイルを生成する。生成した情報提供ファイルを電子メールに添付して紹介元のユーザに送信する。
【００１６】
図１は、本実施の形態に係るインシデント管理システム３００を含む運用管理システム６００の全体構成を示す。情報処理システム１００ａ、１００ｂ、・・・、１００ｃ（以下、まとめて「情報処理システム１００」とよぶ）は、企業の基幹系システムや情報系システムを含む。ベンダ端末５００ａ、５００ｂ、・・・、５００ｃ（以下、まとめて「ベンダ端末５００」とよぶ）は、情報処理システム１００を構成するサーバ、ストレージ、ネットワーク機器等のハードウェアを保守するベンダ、データベース管理システム、トランザクションモニター等のミドルウェアを保守するベンダ、業務アプリケーションを保守するベンダの情報処理端末を含む。運用管理システム６００は、情報処理システム１００に運用管理サービスを提供する。運用管理システム６００は、監視装置２００と、インシデント管理システム３００と、運用担当者端末４００を含む。
【００１７】
インシデント管理システム３００は、情報処理システム１００で発生したインシデントを管理する。インシデント管理システム３００は、ベンダ端末５００とインターネット等の通信網を介して接続されており、具体的には電子メールによりデータの送受信が可能に構成されている。インシデント管理システム３００の詳細な機能構成は図２に関連して後述する。
【００１８】
監視装置２００は、情報処理システム１００の動作状態を監視し、例えば死活監視処理やハードウェアリソースの使用状況の監視処理を実行する。情報処理システム１００の動作状態が所定の異常状態になった場合、監視装置２００は、新たなインシデントを起票してそのインシデントの情報をインシデント管理システム３００へ送信する。また監視装置２００は、インシデントを起票済の情報処理システム１００の動作状態が変化した場合、そのインシデントの更新情報をインシデント管理システム３００へ送信する。
【００１９】
運用担当者端末４００は、運用担当者により操作される情報処理端末であり、運用担当者から所定の情報や指示を受け付ける。そして、その情報をインシデント管理システム３００へ送信する。
【００２０】
図２は、図１のインシデント管理システム３００の機能構成を示す。これら各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、図２の各機能ブロックは、インシデント管理プログラムとして記録媒体に格納され、インシデント管理システム３００のストレージへインストールされてもよい。そして、インシデント管理プログラムの起動時に、各機能ブロックに対応するプログラムモジュールがメインメモリに読み出されてＣＰＵにより実行されてもよい。
【００２１】
インシデント管理システム３００は、インシデント情報表示部３０２、取得部３０４、生成部３０６、送信部３０８、受信部３１０、抽出部３１２、更新部３１４、インシデント情報受付部３１６、インシデント情報保持部３２０、対応関係保持部３２２、フォーマット保持部３２４、回答保持部３２６を含む。以下、各部材の構成についてインシデント対応依頼機能、インシデント照会機能それぞれを実現する場合に分けて説明する。
【００２２】
[１]インシデント対応依頼機能
インシデント情報受付部３１６は、監視装置２００および運用担当者端末４００からインシデントの情報を受け付け、受け付けたインシデントの情報をインシデント情報保持部３２０へ格納する。
【００２３】
インシデント情報保持部３２０は、複数の情報処理システム１００において発生した複数のインシデントに関する属性情報を保持する。この属性情報は、後述する図３のインシデント情報画面で示す各種情報項目であり、例えば、システム名・ステータス・優先度等を含む。
【００２４】
インシデント情報表示部３０２は、インシデント情報保持部３２０に保持された複数のインシデントのうち、運用担当者端末４００で指定されたインシデントの属性情報を表示するインシデント情報画面のデータを、運用担当者端末４００へ送信する。そして運用担当者端末４００に表示する。
【００２５】
図３は、インシデント情報画面を示す。インシデント情報画面は、インシデント情報保持部３２０に保持された複数のインシデントのうち、運用担当者に従って運用担当者端末４００が選択したインシデントの情報を表示する。インシデント情報画面は、エスカレーションボタン７００を備える。エスカレーションボタン７００は、インシデント情報画面で表示されたインシデントについて、対応者に対応を依頼するときに選択される。
【００２６】
図２に戻り、対応関係保持部３２２は、インシデントに関する複数種類の属性それぞれの項目（以下、「属性項目」とも呼ぶ。）と、各属性を示すシンボルとしての文字列（以下、単に「シンボル」とも呼ぶ。）との対応関係情報を保持する。属性項目は、「システム名」・「ステータス」・「優先度」等の属性名称であり、インシデント情報保持部３２０におけるカラム名に相当する。図４は、対応関係保持部３２２に保持された対応関係情報のデータ構造を示す。対応関係保持部３２２は、シンボル７１０と属性項目７１２とを対応づけて保持する。シンボル７１０はシンボルを示し、属性項目７１２は属性項目を示す。対応関係保持部３２２は、例えば、属性項目「システム名」とシンボル「%ICD:SYSTEM%」、属性項目「ステータス」とシンボル「%ICD:STATUS%」、属性項目「優先度」とシンボル「%ICD:PRI_LEVEL%」を対応づけて保持する。
【００２７】
図２に戻り、フォーマット保持部３２４は、複数の対応者に対応した複数種類の通知ファイルのフォーマットを保持する。図５は、フォーマット保持部３２４に保持されているフォーマットの一例を示す。属性項目７２０は、属性項目を示す。属性値７２２は、各属性の属性値が表示される領域であり、シンボルが埋め込まれている。後述するごとく、通知ファイルを生成するときに、このシンボルが実際の属性値に置き換えられる。属性値７２２にシンボルが埋め込まれていない回答７２４は対応者に回答を記入してもらう属性項目であり、ここでは、影響範囲、原因、ワークアラウンドおよび結果、対応および結果、備考、参考ＵＲＬが含まれる。
【００２８】
複数の対応者に応じた複数種類のフォーマットを保持するのは、対応者によっては受け付けるフォーマットを独自のものに限定することがあるためである。また、対応者ごとの契約の違いにより、対応者によって開示できる情報が異なる場合があるためである。例えば、図５に示すフォーマットにはシステム名が含まれるが、契約上システム名を開示できない対応者がある場合は、システム名を含まないフォーマットも保持する。もちろんシステム名を含むフォーマットとしつつ、特定の文字や記号でマスキングされるようにしてもよい。
【００２９】
なお、フォーマットは運用担当者が自由に設計できるので、例えば、運用部門内でインシデントに関する報告会を行うときの報告資料の一部としてそのまま使用できる様式にしてもよい。
【００３０】
図２に戻り、フォーマット保持部３２４は、対応者の名称と、サポート対象と、対応者の宛先と、その対応者への通知に使用される通知ファイルのフォーマットとを対応づけた対応者リスト３５０も保持する。図６は、対応者リスト３５０のデータ構造を示す。対応者７３０は、対応者の名称を示し、サポート対象７３２は対応者が対応する対象のインシデントの分類を示し、メールアドレス７３４は対応者のメールアドレスを示す。また、フォーマット７３６はその対応者にインシデントを通知するときに使用する通知ファイルのフォーマットを示す。
【００３１】
図２に戻り、取得部３０４は、対応を依頼するインシデントと対応者の情報を運用担当者端末４００から受け付ける。取得部３０４は、対応者リスト３５０を参照して、受け付けた対応者に対応するフォーマットを特定する。例えば、対応者リスト３５０が図６の場合で、対応者として「ＤＥＦ社」を受け付けたときは、「フォーマット１」がフォーマットとして特定される。
【００３２】
取得部３０４は、特定したフォーマットの中のシンボル（ここでは「%」に挟まれた文字列）を検出する。取得部３０４は、対応関係保持部３２２に保持される対応関係情報を参照して、検出したシンボルに対応する属性項目を特定する。そして、特定した属性項目の値（属性値）をインシデント情報保持部３２０から取得する。取得部３０４は、特定したフォーマットの情報および取得した属性値を生成部３０６に渡す。
【００３３】
生成部３０６は、取得部３０４が特定したフォーマットをフォーマット保持部３２４からコピーする。そして、コピーしたファイル内のシンボルを、取得部３０４が取得した属性値に置き換える。こうして、通知ファイルを生成する。図７は、生成部３０６が生成した通知ファイルの一例を示す。図４のフォーマットと比較すると、例えば、属性項目「タイトル」のシンボル「%ICD:TITLE%」が、通知ファイルでは「ストレージ障害」に置き換えられている。また、属性項目「優先度」のシンボル「%ICD:PRI_LEVEL%」が、通知ファイルでは「大」に置き換えられている。生成部３０６は生成した通知ファイルを送信部３０８に渡す。
【００３４】
図２に戻り、送信部３０８は、対応者リストを参照して、取得部３０４が受け付けた対応者に対応するメールアドレスを特定する。そして、生成部３０６が生成した通知ファイルを添付した電子メールを、特定したメールアドレス宛に送信する。
【００３５】
受信部３１０は、送信部３０８が対応者に送信した通知ファイルであって対応者が回答を記入した通知ファイルが添付された電子メールを受信する。受信部３１０は、受信した通知ファイルを後述の回答保持部３２６に格納する。
【００３６】
回答保持部３２６は、対応者により回答が記入された通知ファイルを保持する。図８は、回答保持部３２６が保持している通知ファイルの一例を示す。図７の対応者が記入する前の通知ファイルと比較すると、回答７４０に回答が記入されている。
【００３７】
抽出部３１２は、回答内容をインシデントに反映する通知ファイルの選択を、運用担当者端末４００から受け付ける。抽出部３１２は、回答保持部３２６が保持する通知ファイルのうち運用担当者端末４００が選択した通知ファイルから、対応者の回答内容を抽出する。通知ファイルの回答元の対応者に対応づけられたフォーマットの回答７２４に記入された内容を抽出する。図８に示す通知ファイルが選択された場合、例えば、原因として「ディスク故障」、対応および結果として「8/10に故障したディスクを交換」を抽出する。また抽出部３１２は、インシデント情報保持部３２０からそのインシデントの属性情報を取得する。抽出部３１２は、抽出した回答内容および取得した属性情報を更新部３１４に渡す。なお、選択された通知ファイルに対応するインシデントがインシデント情報保持部３２０に存在しないとき、すなわち、通知ファイルに記載されているインシデントＩＤのインシデントがインシデント情報保持部３２０に存在せず抽出できなかったときは、抽出部３１２は処理を中止し、その旨を運用担当者端末４００に通知する。
【００３８】
更新部３１４は、抽出部３１２が抽出した回答内容を運用担当者端末４００に通知して回答内容をインシデントの属性情報として反映することの許否を問い合わせる。運用担当者端末４００から反映を許可する情報を受け付けた場合、更新部３１４は、対応者からの回答を属性情報として反映する。図９は、対応者からの回答が反映されたインシデントのインシデント情報画面の一例を示す。図３の回答が反映される前のインシデント情報画面と比較すると、影響範囲、原因、ワークアラウンドおよび結果、対応および結果、備考、参考ＵＲＬに対応者からの回答が反映されている。
【００３９】
以上の構成によるインシデント管理システムの動作を説明する。図１０は対応者にインシデントの対応を依頼するときの処理フローを示し、図１１は対応者から回答を受信したときの処理フローを示し、図１２は対応者からの回答内容をインシデントの属性情報として反映するときの処理フローを示す。ここでは、図３に示すインシデントＩＤ「３５」のインシデントを例に説明する。運用担当者がこのインシデントは自部門では解決できないと判断し、ストレージを保守するベンダ（ＤＥＦ社）に対応を依頼する場合を考える。そして、依頼を受けたＤＥＦ社は、ディスク故障が原因であると特定し、その対応としてディスク交換を行い、その旨を運用担当者から送られた通知ファイルそのものに記載して回答する場合を考える。
【００４０】
図１０のごとく、取得部３０４は、通知するインシデントのインシデントＩＤ「３５」と対応者「ＤＥＦ社」を運用担当者端末４００から受け付ける（Ｓ１０）。取得部３０４は、図６に示す対応者リスト３５０を参照し、受け付けた対応者「ＤＥＦ社」に対応するフォーマットである「フォーマット１」を特定する（Ｓ２０）。ここでは、図５のフォーマットがフォーマット１であるとする。取得部３０４は特定したフォーマット１の中のシンボルを検出し、対応関係保持部３２２に保持された対応関係情報を参照して、シンボルに対応する属性項目を特定する（Ｓ３０）。例えば、シンボル「%ICD:TITLE%」を検出し、対応する属性項目として「タイトル」を特定する。そして、特定した属性項目の値（属性情報）をインシデント情報保持部３２０から取得する（Ｓ４０）。例えば、インシデントＩＤ「３５」のインシデントの属性項目「タイトル」の値として「ストレージ障害」を取得する。生成部３０６は、フォーマット保持部３２４からフォーマット１をコピーし、コピーしたファイル内のシンボル文字列を、取得部３０４が取得した属性情報に置き換え、通知ファイルを生成する（Ｓ５０）。図７が生成された通知ファイルとすると、例えば、シンボル「%ICD:TITLE%」が「ストレージ障害」に置き換えられている。送信部３０８は、生成部３０６が生成した通知ファイルを添付した電子メールを対応者である「ＤＥＦ社」に送信する（Ｓ６０）。こうして、運用担当者は、ストレージに関するインシデントについて、それを保守するベンダにインシデントの内容を通知し、対応依頼することができる。
【００４１】
図１１のごとく、受信部３１０は対応者により回答が記載された通知ファイルが添付された電子メールを受信し（Ｓ７０）、その通知ファイルを回答保持部３２６に格納する（Ｓ８０）。ここでは、図８の通知ファイルを受信したとする。
【００４２】
図１１のごとく、抽出部３１２は、回答内容をインシデントに反映する通知ファイルの選択を運用担当者端末４００から受け付ける（Ｓ９０）。ここでは、図８の通知ファイルが選択されたとする。抽出部３１２は、回答保持部３２６に格納された図８の通知ファイルから、対応者の回答内容を抽出する（Ｓ１００）。例えば、原因「ディスク故障」、対応および結果「8/10に故障したディスクを交換」が抽出される。また、抽出部３１２は、インシデント情報保持部３２０からそのインシデントの属性情報を取得する（Ｓ１１０）。当該インシデントがインシデント情報保持部３２０に存在する場合（Ｓ１２０のＹ）、抽出部３１２は、抽出した回答内容および取得した属性情報を更新部３１４に渡す。インシデントが存在しない場合（Ｓ１２０のＮ）、抽出部３１２は処理を中止し、その旨を運用担当者端末４００に通知する（Ｓ１６０）。更新部３１４は、抽出部が抽出した回答内容を運用担当者端末４００に通知して回答内容をインシデントの属性情報として反映することの許否を問い合わせる（Ｓ１３０）。運用担当者端末４００から反映を許可する情報を受け付けた場合（Ｓ１４０のＹ）、更新部３１４は、対応者からの回答を属性情報として反映する（Ｓ１５０）。図９のごとく、例えば、原因「ディスク故障」、対応および結果「8/10に故障したディスクを交換」が反映される。更新を許可しない情報を受け付けた場合（Ｓ１４０のＮ）、更新部３１４は処理を中止する。このようして、運用担当者は、対応者の回答を反映することができる。
【００４３】
以上の構成によれば、フォーマットに従って、インシデントの属性情報が記入された通知ファイルが生成される。このため、インシデントの対応を依頼するときにその内容をメールに転記するといった作業が不要となるので、運用担当者の作業負荷が軽減される。また、対応を依頼するのに必要十分な属性項目が含まれるフォーマットを用意しておけば、それらが記入された通知ファイルが生成されるため、運用担当者は必要な情報を対応者に提供できる。このため、不足している情報を対応者から要求され、運用担当者がそれに対応する、といった余計なやり取りを減らすことができ、運用担当者の負担が軽減される。また、通知ファイルに記入された対応者からの回答が抽出され、インシデントに反映される。このため、対応者からの回答を手動で入力する必要がないため、運用担当者の作業負荷が軽減される。
【００４４】
[２]インシデント照会機能
インシデント照会機能では、受信部３１０、取得部３０４、生成部３０６、送信部３０８、インシデント情報受付部３１６、インシデント情報保持部３２０、対応関係保持部３２２、フォーマット保持部３２４が主に使用される。インシデント対応依頼機能と同じ構成の部材についてはその説明を省略する。また、「通知ファイル」を「情報提供ファイル」と読み替えることによって同様の説明が当てはまる部材につても説明を省略する。
【００４５】
フォーマット保持部３２４は、複数の照会元のユーザに応じた複数種類の情報提供ファイルのフォーマットを保持する。情報提供ファイルのフォーマットは、通知ファイルのフォーマットと同様である。複数の照会元のユーザに応じた複数種類のフォーマットを保持するのは、照会元のユーザによって開示できる情報が異なる場合があるためである。情報提供ファイルのフォーマットは運用担当者が自由に設計できるので、ユーザに応じた範囲の情報が開示されるようにフォーマットを用意すればよい。
【００４６】
フォーマット保持部３２４は、インシデントの照会要求があった場合にインシデントの情報を提供するユーザと、そのユーザのメールアドレスと、開示する際に使用する情報提供ファイルのフォーマットの情報との対応関係を示す照会ユーザリスト３６０を保持する。図１３は、照会ユーザリスト３６０のデータ構造を示す。ユーザ７５０は照会要求があった場合にインシデントの情報を提供するユーザを示し、メールアドレス７５２はそのユーザのメールアドレスを示す。また、フォーマット７５４は、そのユーザにインシデントの情報を開示する際に使用する情報提供ファイルのフォーマットを示す。ユーザはベンダに限らず、さまざまな者を含めることができる。ここでは、運用部門の部門長である「運用部門長００１」をユーザとして含めている。
【００４７】
図２に戻り、受信部３１０は、インシデントの照会を求める電子メールを受信する。ここでは、照会を求めるメールの件名には、インシデントＩＤが記載されているものとする。例えば、インシデントＩＤ「３５」のインシデントの照会を求める場合は、件名に「３５」と記載される。
【００４８】
取得部３０４は、照会を求めるインシデントのインシデントＩＤと照会元のユーザのメールアドレスを受信部３１０から受け付ける。取得部３０４は、照会ユーザリスト３６０を参照して、受け付けたメールアドレスに対応するフォーマットを特定する。例えば、照会ユーザリスト３６０が図１３の場合で、メールアドレスとして「bumontyou001@pqr.co.jp」を受け付けたときは、「フォーマット２」がフォーマットとして特定される。
【００４９】
送信部３０８は、情報提供ファイルが添付された電子メールを、照会元のユーザに送信する。
【００５０】
以上の構成によるインシデント管理システムの動作を説明する。図１４は、インシデントの照会要求があったときの処理フローを示す。ここでは、インシデント管理システム３００に社内のＬＡＮではアクセスできずインターネットを介してアクセスせざるを得ないロケーションにいる運用部門長００１（メールアドレスは「bumontyou001@pqr.co.jp」）が、図９に示すインシデントＩＤ「３５」のインシデントの照会要求をした場合を例に説明する。
【００５１】
図１４のごとく、受信部３１０は、件名に「３５」が記載されたメールを受信したとする（Ｓ１７０）。取得部３０４は、照会ユーザリスト３６０を参照し、受信部３１０から受け付けたメールアドレス「bumontyou001@pqr.co.jp」に対応するフォーマット「フォーマット２」を特定する（Ｓ１８０）。取得部３０４は特定したフォーマット２の中のシンボルを検出し、対応関係保持部３２２に保持された対応関係情報を参照して、シンボルに対応する属性項目を特定する（Ｓ１９０）。そして、特定した属性項目の値（属性情報）をインシデント情報保持部３２０から取得する（Ｓ２００）。生成部３０６は、フォーマット保持部３２４からフォーマット２をコピーし、コピーしたファイル内のシンボル文字列を、取得部３０４が取得した属性情報に置き換え、情報提供ファイルファイルを生成する（Ｓ２１０）。送信部３０８は、生成部３０６が生成した情報提供ファイルを添付した電子メールを照会元のユーザである「運用担当者００１」の宛先に送信する（Ｓ２２０）。このように、運用担当者がインシデントの情報をメールに転記して応答するといった作業をするまでもなく、運用部門長００１は、インシデントＩＤ「３５」のインシデントの状況を確認することができる。
【００５２】
以上の構成によれば、フォーマットに従って、インシデントの属性情報が記入された情報提供ファイルが生成され、照会もとのユーザに送信される。このため、運用担当者は、インシデントの照会要求に対してインシデントの情報をメールに転記して応答するといった作業が不要となるので、運用担当者の作業負担が軽減される。
【００５３】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を示す。
【００５４】
請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要件の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【符号の説明】
【００５５】
１００ 情報処理システム、 ２００ 監視装置、 ３００ インシデント管理システム、 ３０２ インシデント情報表示部、 ３０４ 取得部、 ３０６ 生成部、 ３０８ 送信部、 ３１０ 受信部、 ３１２ 抽出部、 ３１４ 更新部、 ３１６ インシデント情報受付部、 ３２０ インシデント情報保持部、 ３２２ 対応関係保持部、 ３２４ フォーマット保持部、 ３２６ 回答保持部、 ４００ 運用担当者端末、 ５００ ベンダ端末、 ６００ 運用管理システム。
【技術分野】
【０００１】
本発明はデータ処理技術に関し、特に、情報処理システムのインシデント管理を支援する技術に関する。
【背景技術】
【０００２】
ＩＴインフラが幅広いユーザ層に活用されるようになってきているなか、ＩＴサービスマネジメントがこれまで以上に重要になってきている。それに伴い、ＩＴサービスマネジメントを実行する上での業務プロセスの効率化が求められている。ＩＴサービスマネジメント・運用規則に関して、英国商務局（ＯＧＣ:Office of Government Commerce）はＩＴＩＬ（Information Technology Infrastructure Library）（登録商標）と呼ばれるベストプラクティス集を公表しており、最近では、ＩＴＩＬに従ってＩＴサービスマネジメントの改善に取り組む企業が増えている。
【０００３】
ＩＴＩＬの中核の一つにサービスサポートがある。サービスサポートは日常的なシステム運用およびユーザサポートに関して記載されたもので、一つの機能と五つのプロセスからなる。機能としては、ユーザからの問い合わせ窓口となるサービスデスク、プロセスとしてはインシデント管理、問題管理、変更管理、リリース管理および構成管理が規定されている。
【０００４】
サービスデスク業務では、ユーザからどのような問い合わせがあったのか、それに対してどのように対応したのか、その問い合わせは処理が終わってクローズしたのか、といった様々なことを記録していく。このようなサービスデスク業務を支援するため、ユーザからの問い合わせをインシデントとして蓄積していくインシデント管理システムが実用化されている（例えば、特許文献１）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−１２９９７３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
インシデントの中にはサービスデスク業務を行う運用部門の担当者（以下「運用担当者」とよぶ）では解決できないものもある。このようなインシデントについては、ハードウェア、ミドルウェア、業務アプリケーションを保守する外部の企業（以下、「ベンダ」とよぶ）に対応を依頼する場合がある。この場合、運用担当者はどのベンダに対応を依頼すべきかの切り分けを行った後、ベンダに対応を依頼をする。
【０００７】
運用部門とベンダのような企業間の通信では、セキュリティ上の制約の少ない電子メールだけ許可されることがある。この場合、ベンダはネットワークを介して運用部門のインシデント管理システムにアクセスできない。そのためベンダに対応を依頼するときには、運用担当者は、インシデント管理システムで管理しているインシデントの情報のうち必要な情報をメールに転記し、ベンダに送る必要がある。また、インシデントに対しどのように対応すればよいか、どのように対応したかといった回答をベンダからメールで受け付け、運用担当者がそれをインシデント管理システムに反映する必要がある。このような作業は、多数のインシデントを管理しなければならない運用担当者にとっては大きな負荷となる。
【０００８】
本発明はこうした課題に鑑みてなされたものであり、その主な目的は、情報処理システムにおいて発生したインシデントの効率的な管理を支援するための技術を提供することにある。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、本発明のある態様のインシデント管理システムは、情報処理システムにおいて発生したインシデントに関する複数の属性情報を保持するインシデント情報保持部と、インシデントの対応者に対するインシデントの通知に使用すべき通知ファイルのフォーマットを保持するフォーマット保持部と、インシデントの複数の属性情報の中からフォーマットで指定された属性情報をインシデント情報保持部から取得する取得部と、取得部が取得した属性情報が記入された通知ファイルを生成する生成部と、生成部が生成した通知ファイルを電子メールに添付して対応者の電子メールアドレス宛に送信する送信部と、送信部が送信した通知ファイルであって、フォーマットで指定された箇所に対応者により回答内容が記載された通知ファイルを添付した電子メールを受信する受信部と、受信部が受信した電子メールに添付された通知ファイルから対応者が記載した回答内容を抽出する抽出部と、抽出部が抽出した回答内容をインシデントの属性情報として反映する更新部と、を備える。
【００１０】
本発明の別の態様もまた、インシデント管理システムである。本システムは、情報処理システムにおいて発生したインシデントに関する複数の属性情報を保持するインシデント情報保持部と、照会元のユーザに対するインシデントの属性情報の提供に使用される情報提供ファイルのフォーマットであって、複数の照会元のユーザに対応した複数種類のフォーマットを保持するフォーマット保持部と、照会元のユーザから送信されたインシデントの照会を求める電子メールを受信する受信部と、照会元のユーザから照会を求める電子メールを受信した場合、インシデントの複数の属性情報の中から、フォーマットで指定された属性情報を取得する取得部と、取得部が取得した属性情報が記入された情報提供ファイルを生成する生成部と、生成部が生成した情報提供ファイルを電子メールに添付して照会元のユーザの電子メールアドレス宛に送信する送信部と、を備える。
【００１１】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１２】
本発明によれば、情報処理システムにおいて発生したインシデントの効率的な管理を支援できる。
【図面の簡単な説明】
【００１３】
【図１】実施の形態のインシデント管理システムを含む運用管理システムの全体構成を示す図である。
【図２】図１のインシデント管理システムの機能構成を示す図である。
【図３】インシデント情報画面を示す図である。
【図４】図２の対応関係保持部に保持された対応関係情報のデータ構造を示す図である。
【図５】図２のフォーマット保持部に保持されたフォーマットの一例を示す図である。
【図６】図２のフォーマット保持部に保持された対応者リストのデータ構造を示す図である。
【図７】実施の形態の通知ファイルの一例を示す図である。
【図８】図２の回答保持部に保持された通知ファイルの一例を示す
【図９】対応者の回答が反映されたインシデントを表示するインシデント情報画面を示す図である。
【図１０】実施の形態において対応者にインシデントの対応を依頼するときの処理の流れを示すフローチャートである。
【図１１】実施の形態において対応者から回答を受信したときの処理の流れを示すフローチャートである。
【図１２】実施の形態において対応者からの回答内容をインシデントの属性情報として反映するときの処理の流れを示すフローチャートである。
【図１３】図２のフォーマット保持部に保持された照会ユーザリストのデータ構造を示す図である。
【図１４】実施の形態においてインシデントの照会要求があったときの処理の流れを示すフローチャートである。
【発明を実施するための形態】
【００１４】
実施の形態に係るインシデント管理システムの概要は以下のとおりである。
本インシデント管理システムは、運用部門では解決できないインシデントについてその内容を通知してベンダに対応を依頼する作業と、インシデントの原因が何であるか、インシデントに対しどのように対応すればよいか、どのように対応したかといったベンダからの回答内容をインシデントに反映する作業を支援する（以下「対応依頼支援機能」とよぶ）。この目的のために、本システムは、インシデントの対応をベンダに依頼する際に、インシデントの内容をベンダに通知するのに使用する通知ファイルのフォーマットを保持する。本システムは、通知するインシデントに関して、フォーマットで指定された属性情報を取得し、それらが記入された通知ファイルを生成する。生成した通知ファイルを電子メールに添付して対応を依頼するベンダ（以下「対応者」とよぶ）に送信する。そして、対応者により回答が記入された通知ファイルが添付された電子メールを受信すると、そのファイルから対応者が記入した回答を抽出し、抽出した内容をインシデントの属性情報として反映する。
【００１５】
また、本システムは、当該システムにアクセスできない者からインシデントの状況についての照会要求があったときに、インシデントの情報を提供する作業を支援する（以下「インシデント照会機能」とよぶ）。この目的のために、本システムは、照会元のユーザにインシデントの情報を提供するのに使用する情報提供ファイルのフォーマットを保持する。本システムは、照会元のユーザからインシデントの照会を求めるメールを受信する。そして、照会を求められたインシデントに関して、フォーマットで指定された属性情報を取得し、それらが記入された情報提供ファイルを生成する。生成した情報提供ファイルを電子メールに添付して紹介元のユーザに送信する。
【００１６】
図１は、本実施の形態に係るインシデント管理システム３００を含む運用管理システム６００の全体構成を示す。情報処理システム１００ａ、１００ｂ、・・・、１００ｃ（以下、まとめて「情報処理システム１００」とよぶ）は、企業の基幹系システムや情報系システムを含む。ベンダ端末５００ａ、５００ｂ、・・・、５００ｃ（以下、まとめて「ベンダ端末５００」とよぶ）は、情報処理システム１００を構成するサーバ、ストレージ、ネットワーク機器等のハードウェアを保守するベンダ、データベース管理システム、トランザクションモニター等のミドルウェアを保守するベンダ、業務アプリケーションを保守するベンダの情報処理端末を含む。運用管理システム６００は、情報処理システム１００に運用管理サービスを提供する。運用管理システム６００は、監視装置２００と、インシデント管理システム３００と、運用担当者端末４００を含む。
【００１７】
インシデント管理システム３００は、情報処理システム１００で発生したインシデントを管理する。インシデント管理システム３００は、ベンダ端末５００とインターネット等の通信網を介して接続されており、具体的には電子メールによりデータの送受信が可能に構成されている。インシデント管理システム３００の詳細な機能構成は図２に関連して後述する。
【００１８】
監視装置２００は、情報処理システム１００の動作状態を監視し、例えば死活監視処理やハードウェアリソースの使用状況の監視処理を実行する。情報処理システム１００の動作状態が所定の異常状態になった場合、監視装置２００は、新たなインシデントを起票してそのインシデントの情報をインシデント管理システム３００へ送信する。また監視装置２００は、インシデントを起票済の情報処理システム１００の動作状態が変化した場合、そのインシデントの更新情報をインシデント管理システム３００へ送信する。
【００１９】
運用担当者端末４００は、運用担当者により操作される情報処理端末であり、運用担当者から所定の情報や指示を受け付ける。そして、その情報をインシデント管理システム３００へ送信する。
【００２０】
図２は、図１のインシデント管理システム３００の機能構成を示す。これら各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、図２の各機能ブロックは、インシデント管理プログラムとして記録媒体に格納され、インシデント管理システム３００のストレージへインストールされてもよい。そして、インシデント管理プログラムの起動時に、各機能ブロックに対応するプログラムモジュールがメインメモリに読み出されてＣＰＵにより実行されてもよい。
【００２１】
インシデント管理システム３００は、インシデント情報表示部３０２、取得部３０４、生成部３０６、送信部３０８、受信部３１０、抽出部３１２、更新部３１４、インシデント情報受付部３１６、インシデント情報保持部３２０、対応関係保持部３２２、フォーマット保持部３２４、回答保持部３２６を含む。以下、各部材の構成についてインシデント対応依頼機能、インシデント照会機能それぞれを実現する場合に分けて説明する。
【００２２】
[１]インシデント対応依頼機能
インシデント情報受付部３１６は、監視装置２００および運用担当者端末４００からインシデントの情報を受け付け、受け付けたインシデントの情報をインシデント情報保持部３２０へ格納する。
【００２３】
インシデント情報保持部３２０は、複数の情報処理システム１００において発生した複数のインシデントに関する属性情報を保持する。この属性情報は、後述する図３のインシデント情報画面で示す各種情報項目であり、例えば、システム名・ステータス・優先度等を含む。
【００２４】
インシデント情報表示部３０２は、インシデント情報保持部３２０に保持された複数のインシデントのうち、運用担当者端末４００で指定されたインシデントの属性情報を表示するインシデント情報画面のデータを、運用担当者端末４００へ送信する。そして運用担当者端末４００に表示する。
【００２５】
図３は、インシデント情報画面を示す。インシデント情報画面は、インシデント情報保持部３２０に保持された複数のインシデントのうち、運用担当者に従って運用担当者端末４００が選択したインシデントの情報を表示する。インシデント情報画面は、エスカレーションボタン７００を備える。エスカレーションボタン７００は、インシデント情報画面で表示されたインシデントについて、対応者に対応を依頼するときに選択される。
【００２６】
図２に戻り、対応関係保持部３２２は、インシデントに関する複数種類の属性それぞれの項目（以下、「属性項目」とも呼ぶ。）と、各属性を示すシンボルとしての文字列（以下、単に「シンボル」とも呼ぶ。）との対応関係情報を保持する。属性項目は、「システム名」・「ステータス」・「優先度」等の属性名称であり、インシデント情報保持部３２０におけるカラム名に相当する。図４は、対応関係保持部３２２に保持された対応関係情報のデータ構造を示す。対応関係保持部３２２は、シンボル７１０と属性項目７１２とを対応づけて保持する。シンボル７１０はシンボルを示し、属性項目７１２は属性項目を示す。対応関係保持部３２２は、例えば、属性項目「システム名」とシンボル「%ICD:SYSTEM%」、属性項目「ステータス」とシンボル「%ICD:STATUS%」、属性項目「優先度」とシンボル「%ICD:PRI_LEVEL%」を対応づけて保持する。
【００２７】
図２に戻り、フォーマット保持部３２４は、複数の対応者に対応した複数種類の通知ファイルのフォーマットを保持する。図５は、フォーマット保持部３２４に保持されているフォーマットの一例を示す。属性項目７２０は、属性項目を示す。属性値７２２は、各属性の属性値が表示される領域であり、シンボルが埋め込まれている。後述するごとく、通知ファイルを生成するときに、このシンボルが実際の属性値に置き換えられる。属性値７２２にシンボルが埋め込まれていない回答７２４は対応者に回答を記入してもらう属性項目であり、ここでは、影響範囲、原因、ワークアラウンドおよび結果、対応および結果、備考、参考ＵＲＬが含まれる。
【００２８】
複数の対応者に応じた複数種類のフォーマットを保持するのは、対応者によっては受け付けるフォーマットを独自のものに限定することがあるためである。また、対応者ごとの契約の違いにより、対応者によって開示できる情報が異なる場合があるためである。例えば、図５に示すフォーマットにはシステム名が含まれるが、契約上システム名を開示できない対応者がある場合は、システム名を含まないフォーマットも保持する。もちろんシステム名を含むフォーマットとしつつ、特定の文字や記号でマスキングされるようにしてもよい。
【００２９】
なお、フォーマットは運用担当者が自由に設計できるので、例えば、運用部門内でインシデントに関する報告会を行うときの報告資料の一部としてそのまま使用できる様式にしてもよい。
【００３０】
図２に戻り、フォーマット保持部３２４は、対応者の名称と、サポート対象と、対応者の宛先と、その対応者への通知に使用される通知ファイルのフォーマットとを対応づけた対応者リスト３５０も保持する。図６は、対応者リスト３５０のデータ構造を示す。対応者７３０は、対応者の名称を示し、サポート対象７３２は対応者が対応する対象のインシデントの分類を示し、メールアドレス７３４は対応者のメールアドレスを示す。また、フォーマット７３６はその対応者にインシデントを通知するときに使用する通知ファイルのフォーマットを示す。
【００３１】
図２に戻り、取得部３０４は、対応を依頼するインシデントと対応者の情報を運用担当者端末４００から受け付ける。取得部３０４は、対応者リスト３５０を参照して、受け付けた対応者に対応するフォーマットを特定する。例えば、対応者リスト３５０が図６の場合で、対応者として「ＤＥＦ社」を受け付けたときは、「フォーマット１」がフォーマットとして特定される。
【００３２】
取得部３０４は、特定したフォーマットの中のシンボル（ここでは「%」に挟まれた文字列）を検出する。取得部３０４は、対応関係保持部３２２に保持される対応関係情報を参照して、検出したシンボルに対応する属性項目を特定する。そして、特定した属性項目の値（属性値）をインシデント情報保持部３２０から取得する。取得部３０４は、特定したフォーマットの情報および取得した属性値を生成部３０６に渡す。
【００３３】
生成部３０６は、取得部３０４が特定したフォーマットをフォーマット保持部３２４からコピーする。そして、コピーしたファイル内のシンボルを、取得部３０４が取得した属性値に置き換える。こうして、通知ファイルを生成する。図７は、生成部３０６が生成した通知ファイルの一例を示す。図４のフォーマットと比較すると、例えば、属性項目「タイトル」のシンボル「%ICD:TITLE%」が、通知ファイルでは「ストレージ障害」に置き換えられている。また、属性項目「優先度」のシンボル「%ICD:PRI_LEVEL%」が、通知ファイルでは「大」に置き換えられている。生成部３０６は生成した通知ファイルを送信部３０８に渡す。
【００３４】
図２に戻り、送信部３０８は、対応者リストを参照して、取得部３０４が受け付けた対応者に対応するメールアドレスを特定する。そして、生成部３０６が生成した通知ファイルを添付した電子メールを、特定したメールアドレス宛に送信する。
【００３５】
受信部３１０は、送信部３０８が対応者に送信した通知ファイルであって対応者が回答を記入した通知ファイルが添付された電子メールを受信する。受信部３１０は、受信した通知ファイルを後述の回答保持部３２６に格納する。
【００３６】
回答保持部３２６は、対応者により回答が記入された通知ファイルを保持する。図８は、回答保持部３２６が保持している通知ファイルの一例を示す。図７の対応者が記入する前の通知ファイルと比較すると、回答７４０に回答が記入されている。
【００３７】
抽出部３１２は、回答内容をインシデントに反映する通知ファイルの選択を、運用担当者端末４００から受け付ける。抽出部３１２は、回答保持部３２６が保持する通知ファイルのうち運用担当者端末４００が選択した通知ファイルから、対応者の回答内容を抽出する。通知ファイルの回答元の対応者に対応づけられたフォーマットの回答７２４に記入された内容を抽出する。図８に示す通知ファイルが選択された場合、例えば、原因として「ディスク故障」、対応および結果として「8/10に故障したディスクを交換」を抽出する。また抽出部３１２は、インシデント情報保持部３２０からそのインシデントの属性情報を取得する。抽出部３１２は、抽出した回答内容および取得した属性情報を更新部３１４に渡す。なお、選択された通知ファイルに対応するインシデントがインシデント情報保持部３２０に存在しないとき、すなわち、通知ファイルに記載されているインシデントＩＤのインシデントがインシデント情報保持部３２０に存在せず抽出できなかったときは、抽出部３１２は処理を中止し、その旨を運用担当者端末４００に通知する。
【００３８】
更新部３１４は、抽出部３１２が抽出した回答内容を運用担当者端末４００に通知して回答内容をインシデントの属性情報として反映することの許否を問い合わせる。運用担当者端末４００から反映を許可する情報を受け付けた場合、更新部３１４は、対応者からの回答を属性情報として反映する。図９は、対応者からの回答が反映されたインシデントのインシデント情報画面の一例を示す。図３の回答が反映される前のインシデント情報画面と比較すると、影響範囲、原因、ワークアラウンドおよび結果、対応および結果、備考、参考ＵＲＬに対応者からの回答が反映されている。
【００３９】
以上の構成によるインシデント管理システムの動作を説明する。図１０は対応者にインシデントの対応を依頼するときの処理フローを示し、図１１は対応者から回答を受信したときの処理フローを示し、図１２は対応者からの回答内容をインシデントの属性情報として反映するときの処理フローを示す。ここでは、図３に示すインシデントＩＤ「３５」のインシデントを例に説明する。運用担当者がこのインシデントは自部門では解決できないと判断し、ストレージを保守するベンダ（ＤＥＦ社）に対応を依頼する場合を考える。そして、依頼を受けたＤＥＦ社は、ディスク故障が原因であると特定し、その対応としてディスク交換を行い、その旨を運用担当者から送られた通知ファイルそのものに記載して回答する場合を考える。
【００４０】
図１０のごとく、取得部３０４は、通知するインシデントのインシデントＩＤ「３５」と対応者「ＤＥＦ社」を運用担当者端末４００から受け付ける（Ｓ１０）。取得部３０４は、図６に示す対応者リスト３５０を参照し、受け付けた対応者「ＤＥＦ社」に対応するフォーマットである「フォーマット１」を特定する（Ｓ２０）。ここでは、図５のフォーマットがフォーマット１であるとする。取得部３０４は特定したフォーマット１の中のシンボルを検出し、対応関係保持部３２２に保持された対応関係情報を参照して、シンボルに対応する属性項目を特定する（Ｓ３０）。例えば、シンボル「%ICD:TITLE%」を検出し、対応する属性項目として「タイトル」を特定する。そして、特定した属性項目の値（属性情報）をインシデント情報保持部３２０から取得する（Ｓ４０）。例えば、インシデントＩＤ「３５」のインシデントの属性項目「タイトル」の値として「ストレージ障害」を取得する。生成部３０６は、フォーマット保持部３２４からフォーマット１をコピーし、コピーしたファイル内のシンボル文字列を、取得部３０４が取得した属性情報に置き換え、通知ファイルを生成する（Ｓ５０）。図７が生成された通知ファイルとすると、例えば、シンボル「%ICD:TITLE%」が「ストレージ障害」に置き換えられている。送信部３０８は、生成部３０６が生成した通知ファイルを添付した電子メールを対応者である「ＤＥＦ社」に送信する（Ｓ６０）。こうして、運用担当者は、ストレージに関するインシデントについて、それを保守するベンダにインシデントの内容を通知し、対応依頼することができる。
【００４１】
図１１のごとく、受信部３１０は対応者により回答が記載された通知ファイルが添付された電子メールを受信し（Ｓ７０）、その通知ファイルを回答保持部３２６に格納する（Ｓ８０）。ここでは、図８の通知ファイルを受信したとする。
【００４２】
図１１のごとく、抽出部３１２は、回答内容をインシデントに反映する通知ファイルの選択を運用担当者端末４００から受け付ける（Ｓ９０）。ここでは、図８の通知ファイルが選択されたとする。抽出部３１２は、回答保持部３２６に格納された図８の通知ファイルから、対応者の回答内容を抽出する（Ｓ１００）。例えば、原因「ディスク故障」、対応および結果「8/10に故障したディスクを交換」が抽出される。また、抽出部３１２は、インシデント情報保持部３２０からそのインシデントの属性情報を取得する（Ｓ１１０）。当該インシデントがインシデント情報保持部３２０に存在する場合（Ｓ１２０のＹ）、抽出部３１２は、抽出した回答内容および取得した属性情報を更新部３１４に渡す。インシデントが存在しない場合（Ｓ１２０のＮ）、抽出部３１２は処理を中止し、その旨を運用担当者端末４００に通知する（Ｓ１６０）。更新部３１４は、抽出部が抽出した回答内容を運用担当者端末４００に通知して回答内容をインシデントの属性情報として反映することの許否を問い合わせる（Ｓ１３０）。運用担当者端末４００から反映を許可する情報を受け付けた場合（Ｓ１４０のＹ）、更新部３１４は、対応者からの回答を属性情報として反映する（Ｓ１５０）。図９のごとく、例えば、原因「ディスク故障」、対応および結果「8/10に故障したディスクを交換」が反映される。更新を許可しない情報を受け付けた場合（Ｓ１４０のＮ）、更新部３１４は処理を中止する。このようして、運用担当者は、対応者の回答を反映することができる。
【００４３】
以上の構成によれば、フォーマットに従って、インシデントの属性情報が記入された通知ファイルが生成される。このため、インシデントの対応を依頼するときにその内容をメールに転記するといった作業が不要となるので、運用担当者の作業負荷が軽減される。また、対応を依頼するのに必要十分な属性項目が含まれるフォーマットを用意しておけば、それらが記入された通知ファイルが生成されるため、運用担当者は必要な情報を対応者に提供できる。このため、不足している情報を対応者から要求され、運用担当者がそれに対応する、といった余計なやり取りを減らすことができ、運用担当者の負担が軽減される。また、通知ファイルに記入された対応者からの回答が抽出され、インシデントに反映される。このため、対応者からの回答を手動で入力する必要がないため、運用担当者の作業負荷が軽減される。
【００４４】
[２]インシデント照会機能
インシデント照会機能では、受信部３１０、取得部３０４、生成部３０６、送信部３０８、インシデント情報受付部３１６、インシデント情報保持部３２０、対応関係保持部３２２、フォーマット保持部３２４が主に使用される。インシデント対応依頼機能と同じ構成の部材についてはその説明を省略する。また、「通知ファイル」を「情報提供ファイル」と読み替えることによって同様の説明が当てはまる部材につても説明を省略する。
【００４５】
フォーマット保持部３２４は、複数の照会元のユーザに応じた複数種類の情報提供ファイルのフォーマットを保持する。情報提供ファイルのフォーマットは、通知ファイルのフォーマットと同様である。複数の照会元のユーザに応じた複数種類のフォーマットを保持するのは、照会元のユーザによって開示できる情報が異なる場合があるためである。情報提供ファイルのフォーマットは運用担当者が自由に設計できるので、ユーザに応じた範囲の情報が開示されるようにフォーマットを用意すればよい。
【００４６】
フォーマット保持部３２４は、インシデントの照会要求があった場合にインシデントの情報を提供するユーザと、そのユーザのメールアドレスと、開示する際に使用する情報提供ファイルのフォーマットの情報との対応関係を示す照会ユーザリスト３６０を保持する。図１３は、照会ユーザリスト３６０のデータ構造を示す。ユーザ７５０は照会要求があった場合にインシデントの情報を提供するユーザを示し、メールアドレス７５２はそのユーザのメールアドレスを示す。また、フォーマット７５４は、そのユーザにインシデントの情報を開示する際に使用する情報提供ファイルのフォーマットを示す。ユーザはベンダに限らず、さまざまな者を含めることができる。ここでは、運用部門の部門長である「運用部門長００１」をユーザとして含めている。
【００４７】
図２に戻り、受信部３１０は、インシデントの照会を求める電子メールを受信する。ここでは、照会を求めるメールの件名には、インシデントＩＤが記載されているものとする。例えば、インシデントＩＤ「３５」のインシデントの照会を求める場合は、件名に「３５」と記載される。
【００４８】
取得部３０４は、照会を求めるインシデントのインシデントＩＤと照会元のユーザのメールアドレスを受信部３１０から受け付ける。取得部３０４は、照会ユーザリスト３６０を参照して、受け付けたメールアドレスに対応するフォーマットを特定する。例えば、照会ユーザリスト３６０が図１３の場合で、メールアドレスとして「bumontyou001@pqr.co.jp」を受け付けたときは、「フォーマット２」がフォーマットとして特定される。
【００４９】
送信部３０８は、情報提供ファイルが添付された電子メールを、照会元のユーザに送信する。
【００５０】
以上の構成によるインシデント管理システムの動作を説明する。図１４は、インシデントの照会要求があったときの処理フローを示す。ここでは、インシデント管理システム３００に社内のＬＡＮではアクセスできずインターネットを介してアクセスせざるを得ないロケーションにいる運用部門長００１（メールアドレスは「bumontyou001@pqr.co.jp」）が、図９に示すインシデントＩＤ「３５」のインシデントの照会要求をした場合を例に説明する。
【００５１】
図１４のごとく、受信部３１０は、件名に「３５」が記載されたメールを受信したとする（Ｓ１７０）。取得部３０４は、照会ユーザリスト３６０を参照し、受信部３１０から受け付けたメールアドレス「bumontyou001@pqr.co.jp」に対応するフォーマット「フォーマット２」を特定する（Ｓ１８０）。取得部３０４は特定したフォーマット２の中のシンボルを検出し、対応関係保持部３２２に保持された対応関係情報を参照して、シンボルに対応する属性項目を特定する（Ｓ１９０）。そして、特定した属性項目の値（属性情報）をインシデント情報保持部３２０から取得する（Ｓ２００）。生成部３０６は、フォーマット保持部３２４からフォーマット２をコピーし、コピーしたファイル内のシンボル文字列を、取得部３０４が取得した属性情報に置き換え、情報提供ファイルファイルを生成する（Ｓ２１０）。送信部３０８は、生成部３０６が生成した情報提供ファイルを添付した電子メールを照会元のユーザである「運用担当者００１」の宛先に送信する（Ｓ２２０）。このように、運用担当者がインシデントの情報をメールに転記して応答するといった作業をするまでもなく、運用部門長００１は、インシデントＩＤ「３５」のインシデントの状況を確認することができる。
【００５２】
以上の構成によれば、フォーマットに従って、インシデントの属性情報が記入された情報提供ファイルが生成され、照会もとのユーザに送信される。このため、運用担当者は、インシデントの照会要求に対してインシデントの情報をメールに転記して応答するといった作業が不要となるので、運用担当者の作業負担が軽減される。
【００５３】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を示す。
【００５４】
請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要件の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【符号の説明】
【００５５】
１００ 情報処理システム、 ２００ 監視装置、 ３００ インシデント管理システム、 ３０２ インシデント情報表示部、 ３０４ 取得部、 ３０６ 生成部、 ３０８ 送信部、 ３１０ 受信部、 ３１２ 抽出部、 ３１４ 更新部、 ３１６ インシデント情報受付部、 ３２０ インシデント情報保持部、 ３２２ 対応関係保持部、 ３２４ フォーマット保持部、 ３２６ 回答保持部、 ４００ 運用担当者端末、 ５００ ベンダ端末、 ６００ 運用管理システム。
【特許請求の範囲】
【請求項１】
情報処理システムにおいて発生したインシデントに関する複数の属性情報を保持するインシデント情報保持部と、
インシデントの対応者に対するインシデントの通知に使用すべき通知ファイルのフォーマットを保持するフォーマット保持部と、
前記インシデントの複数の属性情報の中から前記フォーマットで指定された属性情報を前記インシデント情報保持部から取得する取得部と、
前記取得部が取得した属性情報が記入された通知ファイルを生成する生成部と、
前記生成部が生成した通知ファイルを電子メールに添付して対応者の電子メールアドレス宛に送信する送信部と、
前記送信部が送信した通知ファイルであって、前記フォーマットで指定された箇所に対応者により回答内容が記載された通知ファイルを添付した電子メールを受信する受信部と、
前記受信部が受信した電子メールに添付された通知ファイルから対応者が記載した回答内容を抽出する抽出部と、
前記抽出部が抽出した回答内容を前記インシデントの属性情報として反映する更新部と、
を備えることを特徴とするインシデント管理システム。
【請求項２】
前記フォーマット保持部は、複数の対応者に対応した複数種類のフォーマットを保持し、
前記取得部は、前記インシデントの複数の属性情報の中から、前記インシデントの対応者に対応するフォーマットで指定された属性情報を取得することを特徴する請求項１に記載のインシデント管理システム。
【請求項３】
前記更新部は、更に、前記インシデントの管理者に対してインシデントに対する属性情報の反映許否を問い合わせ、前記インシデントの管理者から前記インシデントに対する属性情報の反映が許可された場合、前記抽出部が抽出した回答内容を前記インシデントの属性情報として反映することを特徴とする請求項１または２に記載のインシデント管理システム。
【請求項４】
情報処理システムにおいて発生したインシデントに関する複数の属性情報を保持するインシデント情報保持部と、
照会元のユーザに対するインシデントの属性情報の提供に使用される情報提供ファイルのフォーマットであって、複数の照会元のユーザに対応した複数種類のフォーマットを保持するフォーマット保持部と、
照会元のユーザから送信されたインシデントの照会を求める電子メールを受信する受信部と、
照会元のユーザから照会を求める電子メールを受信した場合、前記インシデントの複数の属性情報の中から、前記フォーマットで指定された属性情報を取得する取得部と、
前記取得部が取得した属性情報が記入された情報提供ファイルを生成する生成部と、
前記生成部が生成した情報提供ファイルを電子メールに添付して照会元のユーザの電子メールアドレス宛に送信する送信部と、
を備えることを特徴とするインシデント管理システム。
【請求項５】
情報処理システムにおいて発生したインシデントに関する複数の属性情報を保持する機能と、
インシデントの対応者に対するインシデントの通知に使用すべき通知ファイルのフォーマットを保持する機能と、
前記インシデントの複数の属性情報の中から前記フォーマットで指定された属性情報を取得する機能と、
取得した属性情報が記入された通知ファイルを生成する機能と、
生成した通知ファイルを電子メールに添付して対応者の電子メールアドレス宛に送信する機能と、
送信した通知ファイルであって、前記フォーマットで指定された箇所に対応者により回答内容が記載された通知ファイルを添付した電子メールを受信する機能と、
受信した電子メールに添付された通知ファイルから対応者が記載した回答内容を抽出する機能と、
抽出した回答内容を前記インシデントの属性情報として反映する機能と、
をコンピュータに実現させるためのコンピュータプログラム。
【請求項１】
情報処理システムにおいて発生したインシデントに関する複数の属性情報を保持するインシデント情報保持部と、
インシデントの対応者に対するインシデントの通知に使用すべき通知ファイルのフォーマットを保持するフォーマット保持部と、
前記インシデントの複数の属性情報の中から前記フォーマットで指定された属性情報を前記インシデント情報保持部から取得する取得部と、
前記取得部が取得した属性情報が記入された通知ファイルを生成する生成部と、
前記生成部が生成した通知ファイルを電子メールに添付して対応者の電子メールアドレス宛に送信する送信部と、
前記送信部が送信した通知ファイルであって、前記フォーマットで指定された箇所に対応者により回答内容が記載された通知ファイルを添付した電子メールを受信する受信部と、
前記受信部が受信した電子メールに添付された通知ファイルから対応者が記載した回答内容を抽出する抽出部と、
前記抽出部が抽出した回答内容を前記インシデントの属性情報として反映する更新部と、
を備えることを特徴とするインシデント管理システム。
【請求項２】
前記フォーマット保持部は、複数の対応者に対応した複数種類のフォーマットを保持し、
前記取得部は、前記インシデントの複数の属性情報の中から、前記インシデントの対応者に対応するフォーマットで指定された属性情報を取得することを特徴する請求項１に記載のインシデント管理システム。
【請求項３】
前記更新部は、更に、前記インシデントの管理者に対してインシデントに対する属性情報の反映許否を問い合わせ、前記インシデントの管理者から前記インシデントに対する属性情報の反映が許可された場合、前記抽出部が抽出した回答内容を前記インシデントの属性情報として反映することを特徴とする請求項１または２に記載のインシデント管理システム。
【請求項４】
情報処理システムにおいて発生したインシデントに関する複数の属性情報を保持するインシデント情報保持部と、
照会元のユーザに対するインシデントの属性情報の提供に使用される情報提供ファイルのフォーマットであって、複数の照会元のユーザに対応した複数種類のフォーマットを保持するフォーマット保持部と、
照会元のユーザから送信されたインシデントの照会を求める電子メールを受信する受信部と、
照会元のユーザから照会を求める電子メールを受信した場合、前記インシデントの複数の属性情報の中から、前記フォーマットで指定された属性情報を取得する取得部と、
前記取得部が取得した属性情報が記入された情報提供ファイルを生成する生成部と、
前記生成部が生成した情報提供ファイルを電子メールに添付して照会元のユーザの電子メールアドレス宛に送信する送信部と、
を備えることを特徴とするインシデント管理システム。
【請求項５】
情報処理システムにおいて発生したインシデントに関する複数の属性情報を保持する機能と、
インシデントの対応者に対するインシデントの通知に使用すべき通知ファイルのフォーマットを保持する機能と、
前記インシデントの複数の属性情報の中から前記フォーマットで指定された属性情報を取得する機能と、
取得した属性情報が記入された通知ファイルを生成する機能と、
生成した通知ファイルを電子メールに添付して対応者の電子メールアドレス宛に送信する機能と、
送信した通知ファイルであって、前記フォーマットで指定された箇所に対応者により回答内容が記載された通知ファイルを添付した電子メールを受信する機能と、
受信した電子メールに添付された通知ファイルから対応者が記載した回答内容を抽出する機能と、
抽出した回答内容を前記インシデントの属性情報として反映する機能と、
をコンピュータに実現させるためのコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１３−５４５３１（Ｐ２０１３−５４５３１Ａ）
【公開日】平成２５年３月２１日（２０１３．３．２１）
【国際特許分類】
【出願番号】特願２０１１−１９２０８８（Ｐ２０１１−１９２０８８）
【出願日】平成２３年９月２日（２０１１．９．２）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
【公開日】平成２５年３月２１日（２０１３．３．２１）
【国際特許分類】
【出願日】平成２３年９月２日（２０１１．９．２）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
[ Back to top ]