(57)【要約】【課題】管理対象の装置における障害の発生を通知するかどうかの制御において、その装置における障害への対応実績に基づいた制御を実現する。【解決手段】障害情報管理部３０は、障害情報取得部１０が取得した障害に関する情報をデータ記憶部２０に記憶して管理する。管理対象装置における障害とその障害への対応の要否とを関連付けた情報が、データ記憶部２０に記憶され、障害情報管理部３０によって管理される。通知制御部４０は、管理対象装置で発生した障害が検知された場合に、データ記憶部２０に記憶された情報を参照することにより、検知された障害の発生を通知するかどうかを制御する。【選択図】図２
2019159984.tif 000002
【特許請求の範囲】
【請求項１】
管理対象の装置で発生した障害に関する情報である障害情報を取得する取得手段と、
前記管理対象の装置における障害と、当該障害への対応の要否とを関連付けて記憶する記憶手段と、
前記記憶手段に記憶された情報を参照することにより、前記発生した障害への対応が必要と判断される場合に前記障害の発生を通知し、前記障害への対応が不要と判断される場合に前記通知を抑制するよう制御する制御手段と、
を有する情報処理装置。
【請求項２】
請求項１に記載の情報処理装置において、
前記記憶手段には、前記管理対象の装置において過去に発生した障害に対して過去に行われた対応の履歴と過去に前記障害への対応を必要と判断したか否かとが対応付けて記憶される、
ことを特徴とする情報処理装置。
【請求項３】
請求項２に記載の情報処理装置において、
前記制御手段は、前記管理対象の装置で発生した過去の障害への対応が一定の条件を満たす障害への対応が不要と前記記憶手段に記憶されている場合に、前記障害への対応を不要と判断する、
ことを特徴とする情報処理装置。
【請求項４】
請求項２に記載の情報処理装置において、
前記制御手段は、前記管理対象の装置で発生した障害との関係が一定の条件を満たす障害への対応内容が対応中で所定期間経過している旨の情報が前記記憶手段に記憶されている場合に、前記障害への対応を不要と判断する、
ことを特徴とする情報処理装置。
【請求項５】
請求項３または４に記載の情報処理装置において、
前記制御手段は、前記管理対象の装置で発生した障害との関係が一定の条件を満たす障害が前記記憶手段に記憶されている場合であっても、当該記憶された障害の発生から所定期間経過している場合には、前記障害への対応が必要と判断する、
ことを特徴とする情報処理装置。
【請求項６】
請求項１から５のいずれか１項に記載の情報処理装置において、
ユーザインタフェースを介して得られるユーザの指示に応じて、前記記憶手段に記憶される障害への対応の要否を変更する変更手段をさらに有する、
ことを特徴とする情報処理装置。
【請求項７】
請求項１から６のいずれか１項に記載の情報処理装置において、
ユーザインタフェースを介して得られるユーザの指示に応じて、前記制御手段が前記通知を抑制する条件を変更する、
ことを特徴とする情報処理装置。
【請求項８】
管理対象の装置で発生した障害に関する情報である障害情報を取得する機能と、
前記管理対象の装置における障害と、当該障害への対応の要否とを関連付けて記憶手段に記憶する機能と、
前記記憶手段に記憶された情報を参照することにより、前記発生した障害への対応が必要と判断される場合に前記障害の発生を通知し、前記障害への対応が不要と判断される場合に前記通知を抑制するよう制御する機能と、
をコンピュータに実現させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置およびプログラムに関する。
【背景技術】
【０００２】
特許文献１には、一定時間内に同一の監視対象サーバに発生した同一のアラートを一つのアラートにフィルタリングするとともに、一定時間内に同一の監視対象サーバに発生した複数種類のアラートを一つのアラートにフィルタリングして格納する監視システムが記載されている。
【０００３】
また、特許文献２には、障害情報が報告された際に、記憶された障害情報の中から有効期限を過ぎた障害情報を削除した後に、記憶された障害情報の点数の累計値が閾値に達するか否かを判断し、その累計値が閾値に達したと判断された場合に、記憶された障害情報を監視元へ通知する情報処理装置が記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−０５５４７９号公報
【特許文献２】特開２００８−０７７３１５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
例えば特許文献１，２に記載されるように、管理対象となる装置で発生する障害を監視して障害の発生を通知する技術が従来から知られている。
【０００６】
本発明の目的は、管理対象の装置における障害の発生を通知するかどうかの制御において、その装置における障害への対応実績に基づいた制御を実現することにある。
【課題を解決するための手段】
【０００７】
請求項１に係る発明は、管理対象の装置で発生した障害に関する情報である障害情報を取得する取得手段と、前記管理対象の装置における障害と、当該障害への対応の要否とを関連付けて記憶する記憶手段と、前記記憶手段に記憶された情報を参照することにより、前記発生した障害への対応が必要と判断される場合に前記障害の発生を通知し、前記障害への対応が不要と判断される場合に前記通知を抑制するよう制御する制御手段と、を有する情報処理装置である。
【０００８】
請求項２に係る発明は、請求項１に記載の情報処理装置において、前記記憶手段には、前記管理対象の装置において過去に発生した障害に対して過去に行われた対応の履歴と過去に前記障害への対応を必要と判断したか否かとが対応付けて記憶されることを特徴とする情報処理装置である。
【０００９】
請求項３に係る発明は、請求項２に記載の情報処理装置において、前記制御手段は、前記管理対象の装置で発生した過去の障害への対応が一定の条件を満たす障害への対応が不要と前記記憶手段に記憶されている場合に、前記障害への対応を不要と判断することを特徴とする情報処理装置である。
【００１０】
請求項４に係る発明は、請求項２に記載の情報処理装置において、前記制御手段は、前記管理対象の装置で発生した障害との関係が一定の条件を満たす障害への対応内容が対応中で所定期間経過している旨の情報が前記記憶手段に記憶されている場合に、前記障害への対応を不要と判断することを特徴とする情報処理装置である。
【００１１】
請求項５に係る発明は、請求項３または４に記載の情報処理装置において、前記制御手段は、前記管理対象の装置で発生した障害との関係が一定の条件を満たす障害が前記記憶手段に記憶されている場合であっても、当該記憶された障害の発生から所定期間経過している場合には、前記障害への対応が必要と判断する、ことを特徴とする情報処理装置である。
【００１２】
請求項６に係る発明は、請求項１から５のいずれか１項に記載の情報処理装置において、ユーザインタフェースを介して得られるユーザの指示に応じて、前記記憶手段に記憶される障害への対応の要否を変更する変更手段をさらに有することを特徴とする情報処理装置である。
【００１３】
請求項７に係る発明は、請求項１から６のいずれか１項に記載の情報処理装置において、ユーザインタフェースを介して得られるユーザの指示に応じて、前記制御手段が前記通知を抑制する条件を変更することを特徴とする情報処理装置である。
【００１４】
請求項８に係る発明は、管理対象の装置で発生した障害に関する情報である障害情報を取得する機能と、前記管理対象の装置における障害と、当該障害への対応の要否とを関連付けて記憶手段に記憶する機能と、前記記憶手段に記憶された情報を参照することにより、前記発生した障害への対応が必要と判断される場合に前記障害の発生を通知し、前記障害への対応が不要と判断される場合に前記通知を抑制するよう制御する機能と、をコンピュータに実現させるプログラムである。
【発明の効果】
【００１５】
請求項１に係る発明により、管理対象の装置における障害の発生を通知するかどうかの制御において、その装置における障害への対応実績に基づいた制御が実現される。
【００１６】
請求項２に係る発明により、過去に発生した障害への対応の履歴に基づいて障害への対応の要否が記憶される。
【００１７】
請求項３に係る発明により、発生した障害との関係が一定の条件を満たす障害への対応が不要と記憶されている場合に、発生した障害への対応が不要と判断される。
【００１８】
請求項４に係る発明により、発生した障害との関係が一定の条件を満たす障害への対応が対応中で所定期間経過している場合に、発生した障害への対応が不要と判断される。
【００１９】
請求項５に係る発明により、発生した障害との関係が一定の条件を満たす場合であっても、記憶された障害の発生から所定期間経過している場合には、発生した障害への対応が必要と判断される。
【００２０】
請求項６に係る発明により、記憶される障害への対応の要否をユーザの指示に応じて変更できるようになる。
【００２１】
請求項７に係る発明により、通知を抑制する条件をユーザの指示に応じて変更できるようになる。
【００２２】
請求項８に係る発明により、管理対象の装置における障害への対応実績に基づいて、その装置における障害の発生を通知するかどうかを制御するプログラムが提供される。
【図面の簡単な説明】
【００２３】
【図１】障害監視装置を備えたシステムの具体例を示す図である。
【図２】障害監視装置の具体例を示す図である。
【図３】障害監視装置による障害監視処理の具体例を示す図である。
【図４】障害情報の具体例を示す図である。
【図５】インシデント情報の具体例を示す図である。
【図６】通知判定処理の具体例を示す図である。
【図７】条件設定画面の具体例を示す図である。
【図８】条件設定画面に含まれる条件１〜３の具体例を示す図である。
【発明を実施するための形態】
【００２４】
図１は、本発明の具体的な実施態様の一例を示す図である。図１には、障害監視装置１００とサービス提供装置２００と１台以上のサービス利用装置３００を備えたシステムの具体例が図示されている。障害監視装置１００とサービス提供装置２００は、互いに通信接続されてデータ（情報）を遣り取りする。また、サービス提供装置２００とサービス利用装置３００は、例えばインターネットなどの通信回線（通信ネットワーク）４００を介して互いに接続されてデータ（情報）を遣り取りする。
【００２５】
障害監視装置１００は、本発明に係る情報処理装置の具体例の一つである。障害監視装置１００は、サービス提供装置２００において発生する障害を監視し、障害が発生した場合に、必要に応じて、サービス提供装置２００の運用者などに障害の発生を通知する。
【００２６】
サービス提供装置２００は、障害監視装置１００によって障害の発生を監視される管理対象装置の一つである。サービス提供装置２００は、様々なサービスをサービス利用装置３００に提供する。例えば、サービス利用装置３００の安定稼動のためのリモートによる点検、サービス利用装置３００の日常的な運用管理のサポートなどのサービスが、サービス提供装置２００からサービス利用装置３００に提供される。
【００２７】
サービス利用装置３００は、サービス提供装置２００から提供されるサービスを利用する装置である。サービス利用装置３００の具体例の一つが印刷機能とスキャナ機能とコピー機能などの複数の画像出力機能を備えた複合型の装置である。サービス利用装置３００が複合型の装置の場合には、例えばコンビニエンスストアなどの店舗に設置されて不特定多数の顧客に利用されてもよい。
【００２８】
図２は、障害監視装置１００（図１）の具体例を示す図である。図２に示す具体例において、障害監視装置１００は、障害情報取得部１０とデータ記憶部２０と障害情報管理部３０と通知制御部４０とユーザインタフェース（ＵＩ）部５０を備えている。
【００２９】
障害情報取得部１０は、管理対象であるサービス提供装置２００（図１）で発生した障害に関する情報を取得する。障害情報取得部１０が取得した障害に関する情報は、データ記憶部２０に記憶されて障害情報管理部３０によって管理される。
【００３０】
データ記憶部２０には、障害情報管理部３０によって管理される障害に関する情報などが記憶される。また、データ記憶部２０には、障害監視装置１００によって管理される各種の情報も記憶される。データ記憶部２０は、例えば、ハードディスクドライブや半導体メモリなどの記憶デバイスを利用して実現される。
【００３１】
障害情報管理部３０は、障害情報取得部１０が取得した障害に関する情報をデータ記憶部２０に記憶して管理する。例えば、サービス提供装置２００（図１）における障害とその障害への対応の要否とを関連付けた情報が、データ記憶部２０に記憶され、障害情報管理部３０によって管理される。
【００３２】
通知制御部４０は、サービス提供装置２００で発生した障害が検知された場合に、データ記憶部２０に記憶された情報を参照することにより、検知された障害の発生を通知するかどうかを制御する。その制御に応じて、サービス提供装置２００の運用者などに障害の発生が通知される。通知する場合には、例えば、サービス提供装置２００の運用者や保守作業者などが利用する携帯端末装置などに対して、障害の発生を知らせるメッセージなどが送信される。もちろん、通知制御部４０が通知を抑制する制御を行った場合には障害の発生の通知が抑制される。
【００３３】
ユーザインタフェース（ＵＩ）部５０は、障害監視装置１００のユーザからの操作を受け付け、また、障害監視装置１００における各種の情報を参照できるようにユーザに提示する。ユーザインタフェース（ＵＩ）部５０は、例えば、ユーザから操作を受け付ける操作デバイスやディスプレイなどの表示デバイスを利用して実現される。例えば、タッチパネルなどのデバイスによりユーザインタフェース（ＵＩ）部５０が実現されてもよい。
【００３４】
図２に示す具体例の障害監視装置１００は、例えば１台以上のコンピュータを利用して実現することができる。そのコンピュータは、ＣＰＵ等の演算デバイス、メモリやハードディスク等の記憶デバイス、インターネット等の通信回線を利用する通信デバイス、光ディスクや半導体メモリ等の記憶媒体からデータを読み取りデータを書き込むデバイス、ディスプレイ等の表示デバイス、ユーザから操作を受け付ける操作デバイス等のハードウェア資源を備えている。
【００３５】
そして、例えば、図２に例示する障害監視装置１００が備える符号を付した複数部分のうちの少なくとも一部の機能に対応したプログラム（ソフトウェア）がコンピュータに読み込まれ、そのコンピュータが備えるハードウェア資源と読み込まれたソフトウェアとの協働により、障害監視装置１００の少なくとも一部の機能がコンピュータにより実現される。そのプログラムは、例えば、インターネット等の通信回線を介してコンピュータ（障害監視装置１００）に提供されてもよいし、光ディスクや半導体メモリやカードメモリ等の記憶媒体に記憶されてコンピュータ（障害監視装置１００）に提供されてもよい。
【００３６】
図１に例示するシステムと図２に例示する障害監視装置１００の全体構成は以上のとおりである。次に、図１のシステムと図２の障害監視装置１００により実現される機能等について詳述する。なお、図１，図２に示した構成（部分）については、以下の説明において図１，図２の符号を利用する。
【００３７】
図３は、障害監視装置１００による障害監視処理の具体例を示す図である。図３には、障害監視装置１００が備える各部において実行される処理の具体例が図示されている。
【００３８】
障害情報取得部１０は、管理対象であるサービス提供装置２００で発生した障害に関する情報である障害情報を取得する（Ｓ１０１）。サービス提供装置２００は、自身がサービス利用装置３００に提供するサービス処理において何らかの障害（エラー）が起きたことを検知すると、ログファイルにその障害に関する障害情報（エラー情報）を出力する。障害情報取得部１０は、例えば定期的にサービス提供装置２００のログファイルを読み込み、ログファイルに新たな障害情報が出力されていることを検知した場合に、その障害情報を取得する。
【００３９】
図４は、障害情報の具体例を示す図である。図４には、サービス提供装置２００のログファイルに出力され、障害情報取得部１０が取得する障害情報（エラー情報）の具体例が図示されている。図４に示す具体例において、障害情報に含まれる各種情報の内容は以下のとおりである。
【００４０】
エラーコードは、障害（エラー）を識別するための識別情報であり、発生日時は、障害が発生した日時の情報である。エラー箇所は、障害が発生した場所を示す情報であり、エラーアプリは、どのアプリケーションで障害が発生したのかを示す情報である。そして、エラー内容には、障害の内容をユーザに知らせるメッセージ等が記録される。なお、図４に例示する具体例以外の情報が障害情報に含まれてもよい。
【００４１】
図３に戻り、障害情報管理部３０は、障害情報取得部１０が取得した障害に関する情報をデータ記憶部２０に記憶して管理する（Ｓ３０１）。障害情報管理部３０は、例えば、取得された障害情報から、サービス提供装置２００における障害とその障害への対応の要否とを関連付けたインシデント情報を生成し、取得された障害情報に対応したインシデント情報をデータ記憶部２０に記憶することにより、障害に関する情報を管理する。
【００４２】
図５は、インシデント情報の具体例を示す図である。図５には、障害情報管理部３０が生成してデータ記憶部２０に記憶して管理するインシデント情報の具体例が図示されている。障害情報管理部３０は、障害情報取得部１０が取得した障害情報に基づいて、サービス提供装置２００における障害とその障害への対応の要否とを関連付けたインシデント情報を生成する。図５に示す具体例において、インシデント情報に含まれる各種情報の内容は以下のとおりである。
【００４３】
インシデント名称は、インシデント情報に付された名称であり、ユーザシステム名は、インシデント情報が示す障害が発生したユーザシステム（例えばサービス提供装置２００）の名称である。
【００４４】
エラーコードは、インシデント情報が示す障害のエラーコード（図４参照）であり、発生日時は、その障害が発生した日時の情報（図４参照）であり、更新日時は、インシデント情報が更新された日時の情報である。
【００４５】
ステータスは、インシデント情報が示す障害への対応の要否に関する情報である。図５には、ステータスに示される情報内容（ステータスの値域）の具体例が示されている。障害が新規のものであり未だ対応の要否が決まっていない場合には、ステータスは「新規登録」となる。障害への対応が必要でありその対応の内容が対応中であれば、ステータスは「対応中」となる。
【００４６】
障害への対応が必要であり対応作業（保守対応の作業など）が終了していれば、ステータスは「対応完了（作業あり）」となる。また、障害への対応が必要であるものの、対応作業がなく通知のみが行われた場合に、ステータスは「対応完了（通知のみ）」となる。そして、障害への対応が不要である場合には、ステータスは「対応不要」となる。
【００４７】
また、図５に例示する具体例では、更新者、インシデント内容、インシデント対応履歴などの情報がインシデント情報に含まれている。もちろん、図５に例示する具体例以外の情報がインシデント情報に含まれてもよい。
【００４８】
図３に戻り、障害情報管理部３０は、障害情報が取得される度に、その障害情報に対応したインシデント情報を生成し、生成したインシデント情報をデータ記憶部２０に記憶して管理する。こうして、例えばサービス提供装置２００において過去に発生した複数の障害に関する複数のインシデント情報がデータ記憶部２０に記憶され、過去に発生した複数の障害に関する情報が障害情報管理部３０によって管理される。
【００４９】
通知制御部４０は、例えば定期的に、障害情報管理部３０によって管理されるインシデント情報を確認する。そして、例えば前回の確認では存在しなかった新たな障害に関するインシデント情報が検知されると（Ｓ４０１）、通知制御部４０は、データ記憶部２０に記憶されて障害情報管理部３０によって管理される過去に発生した障害のインシデント情報を参照し（Ｓ４０２）、通知判定処理を実行する（Ｓ４０３）。通知判定処理の具体例については後に詳述する。
【００５０】
Ｓ４０３の通知判定処理により通知が必要であると判定されると、通知制御部４０は、Ｓ４０１で検知した新たな障害の発生を通知する（Ｓ４０４ａ）。例えば、サービス提供装置２００の運用者（または保守作業者など）が利用する携帯端末装置などに対して、障害の発生を知らせるメッセージなどが送信される。
【００５１】
障害の通知を受けた運用者（または保守作業者）は、その障害への保守対応を行い、対応内容をユーザインタフェース（ＵＩ）部５０に入力する。ユーザインタフェース（ＵＩ）部５０は、運用者（または保守作業者）によって入力された対応内容を障害情報管理部３０に報告する（Ｓ５０１）。そして、障害情報管理部３０は、報告された対応内容に応じて障害情報（障害情報に基づくインシデント情報）を更新する（Ｓ３０２ａ）。
【００５２】
一方、Ｓ４０３の通知判定処理により通知が不要であると判定されると、通知制御部４０は、障害への対応が不要でありその障害の通知が行われなかったことを障害情報管理部３０に報告する（Ｓ４０４ｂ）。障害情報管理部３０は、報告された対応不要の内容に応じて障害情報（障害情報に基づくインシデント情報）を更新する（Ｓ３０２ｂ）。
【００５３】
図６は、通知判定処理（図３のＳ４０３）の具体例を示す図である。新たな障害に関するインシデント情報を検知し（図３のＳ４０１）、過去に発生した障害のインシデント情報を参照すると（図３のＳ４０２）、通知制御部４０は、図６のフローチャートにおけるＳ１からＳ５に示す判定処理を実行する。
【００５４】
通知制御部４０は、過去に発生した障害の中に、新たに発生した障害との関係が一定の条件を満たす障害があるかどうかを判定する（Ｓ１）。例えば、新たに発生した障害と同一（実質的に同じ場合を含む）の障害があるかどうかが確認される。例えば、過去に発生した障害の中に、新たに発生した障害とエラーコードが一致する障害があるか否かが判定される。
【００５５】
Ｓ１の判定において一定の条件を満たす障害がなければ、通知制御部４０は、新たに発生した障害への対応が必要であり、通知が必要と判断して新たな障害の発生を通知する（図３のＳ４０４ａ）。一方、Ｓ１の判定において一定の条件を満たす障害があれば、Ｓ２の判定が実行される。
【００５６】
通知制御部４０は、新たに発生した障害との関係が一定の条件を満たす障害の中で、直近の障害への対応が「対応不要」であるかどうかを判定する（Ｓ２）。例えば、新たに発生した障害とエラーコードが一致する過去の障害の中で、直近の５件への対応が「対応不要」であるかどうかが確認される。
【００５７】
Ｓ２の判定において、例えば直近の障害の中に「対応必要」である障害があれば、Ｓ３の判定が実行される。一方、Ｓ２の判定において、直近の障害の中に「対応必要」である障害がなければ、直近の障害への対応が「対応不要」であると判断され、Ｓ４の判定が実行される。
【００５８】
Ｓ３の判定において、通知制御部４０は、新たに発生した障害との関係が一定の条件を満たす障害の中で、直近の障害への対応が「対応中」で未更新かどうかを判定する。例えば、新たに発生した障害とエラーコードが一致する過去の障害の中で、直近の５件への対応が「対応中」のまま、障害の発生日時から所定期間（例えば１０日間）経過しても更新されていない場合に、未更新であると判定される。
【００５９】
Ｓ３の判定において未更新でなければ（更新されていれば）、通知制御部４０は、新たに発生した障害への対応が必要であり、通知が必要と判断して新たな障害の発生を通知する（図３のＳ４０４ａ）。一方、Ｓ３の判定において未更新であれば、Ｓ４の判定が実行される。
【００６０】
Ｓ４の判定において、通知制御部４０は、前回の同じ障害の発生から所定期間経過しているかどうかを判定する。例えば、新たに発生した障害とエラーコードが一致する前回の障害の発生日時から所定期間（例えば３ヶ月）経過しているかどうかが判定される。
【００６１】
Ｓ４の判定において経過していれば、通知制御部４０は、新たに発生した障害への対応が必要であり通知が必要と判断して新たな障害の発生を通知する（図３のＳ４０４ａ）。一方、Ｓ４の判定において経過していなければＳ５の判定が実行される。
【００６２】
Ｓ５の判定において、通知制御部４０は、前回の同じ障害の発生から管理対象の装置に関する更新があるかどうかを判定する。例えば、新たに発生した障害とエラーコードが一致する前回の障害の発生日時以降に、サービス提供装置２００に関する装置の更新（ソフトウェアのバージョンアップを含む）があるかどうかが判定される。
【００６３】
Ｓ５の判定において更新があれば、通知制御部４０は、新たに発生した障害への対応が必要であり、通知が必要と判断して新たな障害の発生を通知する（図３のＳ４０４ａ）。一方、Ｓ５の判定において更新がなければ、通知制御部４０は、新たに発生した障害への対応が不要であり、その障害の通知が行われなかったことを障害情報管理部３０に報告する（Ｓ４０４ｂ）。
【００６４】
このように、通知制御部４０は、例えば図６に例示するフローチャートに従って、障害情報管理部３０によって管理される過去の障害への対応実績を参照することにより、新たに発生した障害への対応が必要か不要かを判定し、最終的に障害への対応が不要と判定された場合に、通知が不要であると判断して通知を抑制する。
【００６５】
また、障害情報管理部３０によって管理される障害に関する情報は、必要に応じて更新される（図３のＳ３０２ａ，Ｓ３０２ｂ参照）。そのため、運用状況の変化などにも柔軟に対応できるようになる。例えば、運用開始当初は、対応が必要であると判断されていた障害（エラー）であっても、運用後の保守作業の見直し等により、その障害への対応が不要となる場合もある。このような場合であっても、対応実績として参照される情報が、例えば運用状況の変化に従って必要に応じて更新されるため（図３のＳ３０２ａ，Ｓ３０２ｂ参照）、運用後の保守作業の見直し等にも柔軟に対応できるようになる。
【００６６】
なお、通知が必要かどうかを判定するための判定条件についても、例えばサービス提供装置２００の運用状況などに応じて変更できるようにしてもよい。例えば、判定条件を変更するための設定を受け付ける条件設定画面がユーザインタフェース（ＵＩ）部５０に表示され、障害監視装置１００またはサービス提供装置２００の運用者などが、表示される条件設定画面を利用して、通知が必要かどうかを判定するための判定条件を変更できるようにしてもよい。
【００６７】
図７は、条件設定画面の具体例を示す図である。図７には、新たに発生した障害の通知を抑制するための条件（ルール）を変更する際に利用される条件設定画面の具体例が図示されている。図７に例示する条件設定画面は、例えば、ユーザインタフェース（ＵＩ）部５０に表示される。なお、条件（ルール）の変更には新たな条件の追加も含まれる。
【００６８】
図７に例示する条件設定画面には、３つのルールＲ１〜Ｒ３が示されており、例えば３つの条件１〜３の組み合わせで１つのルールが決定される。
【００６９】
図８は、図７の条件設定画面に含まれる条件１〜３の具体例を示す図である。例えば運用者などのユーザは、図７に例示する条件設定画面を利用して、図８に例示する条件１〜３の選択候補の中から各条件の内容を選択することができる。
【００７０】
例えば、図７の条件設定画面内において条件１に対応したメニューボタンが操作されると、図８に例示する条件１のカテゴリ１〜３に含まれる複数候補がプルダウンメニューで表示される。ユーザは、プルダウンメニューで表示される複数候補の中から条件１の内容を選択する。
【００７１】
また、図７の条件設定画面内において条件２のメニューボタンが操作されると、図８に例示する条件２の複数候補がプルダウンメニューで表示される。なお、条件１の候補が既に選択されている場合には、条件１の選択結果に応じて、条件１と同じカテゴリで条件２の選択内容が制限されてもよい。
【００７２】
例えば、条件１としてカテゴリ１に属する「新規登録」「対応中」「対応完了（作業あり）」「対応完了（通知のみ）」「対応不要」のいずれかが選択されている場合には、条件２においてカテゴリ１に属する「連続で起きた」または「過去に起きた」が選択候補とされる。また、条件１としてカテゴリ２の「発生日時」または「更新日時」が選択されている場合には、条件２においてカテゴリ２の「より前」または「より後」が選択候補とされる。
【００７３】
図７，図８に示す具体例において、条件３はフリーテキストエリアとされる。但し、条件３において入力可能な文字列などを条件１（または条件１と条件２の組み合わせ）に応じて制限するようにしてもよい。例えば、条件１，条件２と同じカテゴリの候補に制限されてもよい。
【００７４】
例えば運用者などのユーザは、図７に例示する条件設定画面を利用して、図８に例示する条件１〜３の選択候補の中から各条件の内容を選択して変更する。そして、例えば図７の条件設定画面の「登録」ボタンが操作されると、その条件設定画面で設定される条件１〜３の内容でルールＲ１〜Ｒ３が更新される。
【００７５】
また、図７の条件設定画面において「削除」のチェックボックスをチェックした状態で「登録」ボタンが操作されるとチェックされたルールが削除される。なお、図７の条件設定画面において「キャンセル」ボタンが操作されると設定途中の条件がクリアされる。
【００７６】
以上、本発明の好適な実施形態を説明したが、上述した実施形態は、あらゆる点で単なる例示にすぎず、本発明の範囲を限定するものではない。本発明は、その本質を逸脱しない範囲で各種の変形形態を包含する。
【符号の説明】
【００７７】
１０  障害情報取得部、２０  データ記憶部、３０  障害情報管理部、４０  通知制御部、５０  ユーザインタフェース部、１００  障害監視装置、２００  サービス提供装置、３００  サービス利用装置。
【図１】
2019159984.tif 000003
【図２】
2019159984.tif 000004
【図３】
2019159984.tif 000005
【図４】
2019159984.tif 000006
【図５】
2019159984.tif 000007
【図６】
2019159984.tif 000008
【図７】
2019159984.tif 000009
【図８】
2019159984.tif 000010