(57)【要約】【課題】障害が発生したことを全てのユーザに通知する場合と比較して、障害が復旧するまでにアクセスする可能性が低いユーザへ通知がなされることを抑制する。【解決手段】本発明の障害通知システムは、ユーザによるアクセスの履歴を取得するサービス情報取得部と、ユーザに提供されるサービスに障害が発生すると、上記履歴に含まれるユーザによるアクセスの態様に基づいて、障害が生じたことを通知する対象となるユーザである通知対象ユーザを特定する対象ユーザ特定部とを有する。この対象ユーザ特定部は、障害が復旧するまでの時間を推定して、対象ユーザの特定をする。【選択図】図３
2018046422.tif 000002
【特許請求の範囲】
【請求項１】
ユーザによるアクセスの履歴を取得する履歴取得部と、
ユーザに提供されるサービスに障害が発生すると、前記履歴に含まれるユーザによるアクセスの態様に基づいて、当該障害が生じたことを通知する対象となるユーザである通知対象ユーザを特定する特定部と
を有する障害通知装置。
【請求項２】
前記障害が復旧に要する時間である復旧所要時間を推定する推定部を有し、
前記特定部は、前記推定部により推定された前記復旧所要時間と、前記ユーザによるアクセスの態様とに基づき、前記通知対象ユーザを特定する
ことを特徴とする請求項１記載の障害通知装置。
【請求項３】
前記サービスにおいて発生した障害の履歴を記憶するとともに、各障害が発生してから復旧するまでの経過時間を記憶する障害情報記憶部を有し、
前記推定部は、前記経過時間に基づいて、前記復旧所要時間を推定する
ことを特徴とする請求項２記載の障害通知装置。
【請求項４】
前記履歴取得部は、特定のユーザからアクセスを受けた時刻であるアクセス時刻を記憶し、
前記特定部は、前記アクセス時刻に基づいて、前記障害が生じたことを前記特定のユーザに通知するか判断する
ことを特徴とする請求項１乃至３のいずれか１項記載の障害通知装置。
【請求項５】
前記特定部は、前記障害が発生する前に前記サービスに関する情報がユーザに通知されていた場合に、当該情報の通知がなされたユーザを前記通知対象ユーザに含める
ことを特徴とする請求項１記載の障害通知装置。
【請求項６】
前記情報の通知は、前記サービスに関するアクセス先の情報を含み、
前記特定部は、前記情報の通知が行われたユーザのうち、当該情報の通知に応じて前記アクセス先にアクセスをしたユーザを特定し、当該特定されたユーザを前記通知対象ユーザに含める
ことを特徴とする請求項５記載の障害通知装置。
【請求項７】
ユーザによるアクセスの履歴を取得する履歴取得部と、
ユーザに提供されるサービスに障害が発生すると、前記履歴に含まれるユーザによるアクセスの態様に関する情報を取得するアクセス態様取得部と、
前記障害が復旧に要する時間である復旧所要時間を推定する推定部と、
前記アクセス態様取得部が取得する前記アクセスの態様と、前記推定部により推定された前記復旧所要時間とに基づいて、当該障害が生じたことを通知する対象となるユーザである通知対象ユーザを特定する特定部と、
前記障害が発生する前に前記サービスに関する情報がユーザに通知されていた場合に、当該情報の通知を行ったユーザを特定し、当該特定されたユーザに基づいて前記特定部によって特定された前記通知対象ユーザを更新する更新部と
を有する障害通知装置。
【請求項８】
ユーザによるアクセスの履歴を取得する履歴取得部と、
ユーザに予め定めたサービスを提供する提供部と、
前記サービスに障害が発生すると、前記履歴に含まれるユーザによるアクセスの態様に基づいて、当該障害が生じたことを通知する対象となるユーザである通知対象ユーザを特定する特定部と
を有する障害通知システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、障害通知装置および障害通知システムに関する。
【背景技術】
【０００２】
特許文献１には、情報取得部で取得した起動時刻と、履歴記録部に記録された過去に取得した起動時刻の履歴から、エラー検知部においてエラー発生の可能性を検知し、その検知状態に応じて、情報提示部で提示することで、従来検知できなかったエラーについても、その発生可能性を検知し、サポート情報を提供することができるサポート情報提示装置が記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００８−２５０３９０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、ユーザに提供されるサービスにおいて障害が発生した場合、例えばメールなどによりユーザに対して障害の発生を通知することがある。一方で、ユーザによるサービスの利用態様によっては、そのユーザにとって必要性の低い通知を受けることがある。
【０００５】
そこで、本発明では、障害が発生したことを全てのユーザに通知する場合と比較して、障害が復旧するまでにアクセスする可能性が低いユーザへ通知がなされることを抑制することを目的とする。
【課題を解決するための手段】
【０００６】
請求項１に記載の発明は、ユーザによるアクセスの履歴を取得する履歴取得部と、ユーザに提供されるサービスに障害が発生すると、前記履歴に含まれるユーザによるアクセスの態様に基づいて、当該障害が生じたことを通知する対象となるユーザである通知対象ユーザを特定する特定部とを有する障害通知装置である。
請求項２に記載の発明は、前記障害が復旧に要する時間である復旧所要時間を推定する推定部を有し、前記特定部は、前記推定部により推定された前記復旧所要時間と、前記ユーザによるアクセスの態様とに基づき、前記通知対象ユーザを特定することを特徴とする請求項１記載の障害通知装置である。
請求項３に記載の発明は、前記サービスにおいて発生した障害の履歴を記憶するとともに、各障害が発生してから復旧するまでの経過時間を記憶する障害情報記憶部を有し、前記推定部は、前記経過時間に基づいて、前記復旧所要時間を推定することを特徴とする請求項２記載の障害通知装置である。
請求項４に記載の発明は、前記履歴取得部は、特定のユーザからアクセスを受けた時刻であるアクセス時刻を記憶し、前記特定部は、前記アクセス時刻に基づいて、前記障害が生じたことを前記特定のユーザに通知するか判断することを特徴とする請求項１乃至３のいずれか１項記載の障害通知装置である。
請求項５に記載の発明は、前記特定部は、前記障害が発生する前に前記サービスに関する情報がユーザに通知されていた場合に、当該情報の通知がなされたユーザを前記通知対象ユーザに含めることを特徴とする請求項１記載の障害通知装置である。
請求項６に記載の発明は、前記情報の通知は、前記サービスに関するアクセス先の情報を含み、前記特定部は、前記情報の通知が行われたユーザのうち、当該情報の通知に応じて前記アクセス先にアクセスをしたユーザを特定し、当該特定されたユーザを前記通知対象ユーザに含めることを特徴とする請求項５記載の障害通知装置である。
請求項７に記載の発明は、ユーザによるアクセスの履歴を取得する履歴取得部と、ユーザに提供されるサービスに障害が発生すると、前記履歴に含まれるユーザによるアクセスの態様に関する情報を取得するアクセス態様取得部と、前記障害が復旧に要する時間である復旧所要時間を推定する推定部と、前記アクセス態様取得部が取得する前記アクセスの態様と、前記推定部により推定された前記復旧所要時間とに基づいて、当該障害が生じたことを通知する対象となるユーザである通知対象ユーザを特定する特定部と、前記障害が発生する前に前記サービスに関する情報がユーザに通知されていた場合に、当該情報の通知を行ったユーザを特定し、当該特定されたユーザに基づいて前記特定部によって特定された前記通知対象ユーザを更新する更新部とを有する障害通知装置である。
請求項８に記載の発明は、ユーザによるアクセスの履歴を取得する履歴取得部と、ユーザに予め定めたサービスを提供する提供部と、前記サービスに障害が発生すると、前記履歴に含まれるユーザによるアクセスの態様に基づいて、当該障害が生じたことを通知する対象となるユーザである通知対象ユーザを特定する特定部とを有する障害通知システムである。
【発明の効果】
【０００７】
請求項１の発明によれば、障害が発生したことを全てのユーザに通知する場合と比較して、障害が復旧するまでにアクセスする可能性が低いユーザへ通知がなされることを抑制することができる。
請求項２の発明によれば、障害が復旧するまでにアクセスする可能性が低いユーザをより精度よく特定することができる。
請求項３の発明によれば、障害が復旧するまでにアクセスする可能性が低いユーザをより精度よく特定することができる。
請求項４の発明によれば、ユーザのアクセス時間の履歴により、障害が復旧するまでにアクセスする可能性が低いユーザをより精度よく特定することができる。
請求項５の発明によれば、情報の通知を受けアクセスする可能性が高いユーザをより確実に通知対象ユーザに含めることができる。
請求項６の発明によれば、情報の通知を受けアクセスする可能性が高いユーザをより確実に通知対象ユーザに含めることができる。
請求項７の発明によれば、障害が発生したことを全てのユーザに通知する場合と比較して、障害が復旧するまでにアクセスする可能性が低いユーザへ通知がなされることを抑制することができる。
請求項８の発明によれば、障害が発生したことを全てのユーザに通知する場合と比較して、障害が復旧するまでにアクセスする可能性が低いユーザへ通知がなされることを抑制することができる。
【図面の簡単な説明】
【０００８】
【図１】本実施の形態が適用される障害通知システムの全体構成例を示した図である。
【図２】サーバの構成例を説明するための図である。
【図３】サーバの動作例を示したフローチャートである。
【図４】（ａ）乃至（ｆ）はサーバの動作に関する情報を説明するための図である。
【図５】サーバのハードウェア構成例を示した図である。
【発明を実施するための形態】
【０００９】
以下、添付図面を参照して、本発明の実施の形態について説明する。
＜障害通知システム１＞
図１は、実施の形態が適用される障害通知システム１の全体構成例を示した図である。
この障害通知システム（サービスシステム、障害通知装置）１は、第１クライアント１１、第２クライアント１２および第３クライアント１３を含むクライアント群１０と、サーバ２０と、ヘルプデスク３０とを有する。クライアント群１０と、サーバ２０とは、ネットワーク４０を介して接続されている。また、ヘルプデスク３０は、サーバ２０と接続されている。
【００１０】
クライアント群１０を構成する第１クライアント１１〜第３クライアント１３のそれぞれは、デスクトップ型コンピュータ、ノート型コンピュータ、タブレット型コンピュータやスマートフォンなどのコンピュータ装置によって構成される。なお、第１クライアント１１〜第３クライアント１３は、所謂コンピュータ装置に限定されるものではなく、用紙に画像を形成する画像形成装置、用紙に形成された画像を読み取る読取装置、あるいは画像形成、画像読み取り、ＦＡＸなど複数の機能を備える複合機などであってもよい。また、図示の例では、クライアント群１０を３台のクライアントで構成しているが、クライアントの台数についてはこれに制限されない。
【００１１】
サーバ２０は、コンピュータ装置によって構成される。本実施の形態のサーバ２０は、第１クライアント１１〜第３クライアント１３に提供されるユーザ向けのサービス（ユーザサービス）において、障害が発生したことを検知し、ユーザに通知する機能を備えている。
なお、ここでのサービスは、ネットワーク４０を介して提供されるサービスであれば、特に限定されない。このサービスを提供する主体（提供元、提供部）は、サーバ２０であってもよいし、ネットワーク４０に含まれるサーバ２０以外のコンピュータ装置であってもよい。
【００１２】
ヘルプデスク３０は、第１クライアント１１〜第３クライアント１３のユーザをサポートする。例えば、ヘルプデスク３０は、情報端末装置（不図示）を備え、ユーザからのメールや電話による問い合わせなどに応答するとともに、ユーザに対してメールや電話により宣伝やレポートなどを行う。
このヘルプデスク３０は、ユーザをサポートするために必要な情報が格納された、各種データベースを有するコンピュータ装置を有する。なお、このヘルプデスク３０は、オペレータ（ヘルプデスク担当者）が情報端末装置を使用しながら、ユーザからの問い合わせへの応答などをしてもよい。
なお、図示の例において、ヘルプデスク３０はサーバ２０に接続されているが、ネットワーク４０に接続されてもよい。
【００１３】
＜サーバ２０＞
＜サーバ２０の構成例＞
図２は、サーバ２０の構成例を説明するための図である。
次に、図１および図２を参照しながらサーバ２０の構成例について説明をする。
本実施の形態のサーバ２０は、入出力部２０１と、サービス監視部２０３と、サービス情報取得部２０５と、障害検知部２０７と、ヘルプデスク情報取得部２０９と、ユーザ連絡部２１１と、対象ユーザ特定部２１３と、アクセス履歴記憶部２２１と、ユーザ属性記憶部２２３と、障害情報記憶部２２５と、ヘルプデスク情報記憶部２２７とを有する。
【００１４】
入出力部２０１は、ネットワーク４０との間で各種データを入出力する。
サービス監視部２０３は、ネットワーク４０を介して第１クライアント１１〜第３クライアント１３に提供されるサービスを監視する。なお、以下の説明においては、サービス監視部２０３が監視する対象となるサービスを、監視対象サービスということがある。
【００１５】
履歴取得部の一例であるサービス情報取得部２０５は、サービス監視部２０３を介して、監視対象サービスに関する情報を取得する。より具体的には、サービス情報取得部２０５は、アクセス履歴情報およびユーザ属性情報を取得する。なお、サービス情報取得部２０５は、アクセス態様取得部の一例である。
【００１６】
ここで、アクセス履歴情報とは、ユーザ（特定のユーザの一例）が監視対象サービスのウェブサイト（アクセス先）などへアクセスした履歴に関する情報である。
具体的には、アクセス履歴情報は、ユーザが監視対象サービスのウェブサイトにアクセスした時刻、アクセスの頻度、アクセスの経路、アクセスの際にユーザが確認した画面（表示画面）などに関する情報である。なお、アクセスした時刻とは、アクセスした時刻（時分）そのものだけでなく、時間帯（例えば、午前、午後、早朝、深夜）など時間の区分、言い替えると時間に関する情報であってもよい。
【００１７】
また、アクセス履歴情報は、ヘルプデスク３０から宣伝（プロモーション）などのメールを送信した後（詳細は後述）に、そのメールを受信したユーザがウェブサイトにアクセスしたか、アクセスしている場合メール送信後ウェブサイトにそのアクセスするまでの経過時間についての情報を含む。また、上記アクセスの経路に関する情報には、送信されたメールに含まれるアクセス経路（例えば、リンク先のＵＲＬ）の情報を含む。
【００１８】
ユーザ属性情報とは、監視対象サービスのユーザの属性に関する情報である。
具体的には、ユーザ属性情報は、ユーザの名称（氏名）、監視対象サービスの種別、ユーザが参照できる画面（操作画面）、障害発生時のユーザへの通知方法、特別な扱いを必要とするユーザ（プレミアムユーザ、特約店）である場合にはその種別などに関する情報を含む。なお、ユーザへの通知方法としては、例えば電話やメールに加えて、サービス画面にアラート（ポップアップ）を表示するなどがある。これらの通知方法は、発生した障害の影響度（サービス影響度）に応じて、個々設定してもよい。また、特別な扱いを必要とするユーザとしては、障害が発生した場合、サービス影響度（障害の影響度）に関係なく連絡することが必要なユーザを含む。
【００１９】
障害検知部２０７は、サービス監視部２０３を介して、監視対象サービスにおける障害の発生を検知するとともに、発生した障害に関する情報である障害情報を取得する。
ここで、障害情報としては、障害内容、障害対象画面、障害が発生した時刻（障害発生時刻）、障害から復旧した時刻（復旧時刻）、障害発生から復旧までに要した時間（障害復旧時間、経過時間）などを含む。なお、障害発生時刻および障害復旧時刻は、時刻そのものだけでなく、時間帯（例えば、午前、午後、早朝、深夜）など時間の区分であってもよい。
【００２０】
ここで、障害内容は、発生した障害の種別に関する情報であり、例えば取り込みファイルの障害や未着、あるいはその他障害などを区別する情報である。
障害対象画面は、障害が発生したクライアントにおいて表示される画面（操作画面）である。言い替えると、サービス提供に問題が生じた画面である。
【００２１】
なお、監視対象サービスにおける障害としては、例えば、この第１クライアント１１〜第３クライアント１３が複合機の場合、複合機で使用する消耗品のデータに異常があり、消耗品に関するデータがサービス画面に表示されないことなどがある。
また、障害検知部２０７による障害の検知、あるいは復旧（収束）などについては、バッチの再実行や、ユーザの手動による操作（例えば、クリック）などにより検知される。
【００２２】
また、障害が発生したことをサーバ２０が検知可能であれば、図示の例とは異なり、サーバ２０が障害検知部２０７（およびサービス監視部２０３）を有しなくともよい。例えば、ネットワーク４０に含まれるサーバ２０以外のコンピュータ装置（不図示）が障害検知部２０７の機能を備えてもよい。そして、このコンピュータ装置が障害を検知すると信号を出力するとともに、この出力された信号をサーバ２０が受信してもよい。
【００２３】
ヘルプデスク情報取得部２０９は、ヘルプデスク３０によるサポートに関する情報であるヘルプデスク情報を取得する。具体的には、ヘルプデスク情報は、ヘルプデスク３０からユーザに送信されたメールについての情報であるメール情報（メール発行情報）、あるいはヘルプデスク３０がユーザから受けたクレーム（フィードバック）についての情報であるクレーム情報などを含む。このメール情報には、メール送信の日時、メールの種別（内容）、メール本文におけるアクセス先（例えば、リンク先のＵＲＬ）の情報の有無、メール本文に含まれるアクセス先へのアクセス情報（アクセスの有無、アクセス時刻、アクセス頻度（回数））などがある。
【００２４】
なお、ヘルプデスク３０からユーザに送信されるメールの種別としては、受信したユーザがサービスを利用しようと考える契機となるものであれば特に限定されない。例えば、この種別としては、提供するサービスの宣伝メール、データ更新やメンテナンスなど提供するサービスに関するレポート（報告）の連絡メールなどがある。
また、クレーム情報は、例えばヘルプデスク３０がクレームを受けた日時、あるいはクレームの内容などの情報を含む。
【００２５】
ユーザ連絡部２１１は、入出力部２０１を介して、障害発生後にユーザへの連絡を実行する。このユーザ連絡部２１１は、第１クライアント１１〜第３クライアント１３の表示手段（画面、不図示）に表示される情報であるサービス画面情報を有する。また、ユーザ連絡部２１１は、障害発生時に、ユーザへ送信されるメールなどのテンプレートの情報を保持する。そして、ユーザ連絡部２１１が保持する情報に基づき、ユーザ連絡部２１１がユーザへの連絡（通知）を実行する。また、ユーザ連絡部２１１は、通知を行ったユーザのリストである通知リストを作成し記憶する。なお、ユーザ連絡部２１１によるユーザへの連絡の実行は、サーバ２０のオペレータによる操作を契機としてもよい。また、オペレータによる連絡を、ユーザ連絡部２１１が補助する態様であってもよい。あるいは、サーバ２０以外のコンピュータ装置（不図示）によって、上記ユーザへの連絡が実行されてもよい。
【００２６】
特定部および推定部の一例である対象ユーザ特定部２１３は、上記各情報（監視対象サービス、ユーザ属性情報、障害情報、アクセス履歴情報、ヘルプデスク情報）などの一部または全部を収集して、分析する。より具体的には、対象ユーザ特定部２１３は、上記各情報に基づいて、障害発生を通知する対象であるユーザ（対象ユーザ、通知対象ユーザ）を特定する（詳細は後述）。
【００２７】
アクセス履歴記憶部２２１は、サービス情報取得部２０５が取得したアクセス履歴情報を記憶する。
ユーザ属性記憶部２２３は、サービス情報取得部２０５が取得したユーザ属性情報を記憶する。
障害情報記憶部２２５は、障害検知部２０７が検知した障害に関する障害情報を記憶する。
ヘルプデスク情報記憶部２２７は、ヘルプデスク情報取得部２０９が取得したヘルプデスク情報を記憶する。
【００２８】
ここで、障害情報記憶部２２５は、障害が発生するごとに障害情報を蓄積（更新）する。さらに説明をすると、障害情報記憶部２２５は、例えば障害情報が更新されることを契機として、障害内容ごとの障害復旧時間の平均値（平均復旧時間）を算出し記憶する。また、障害情報記憶部２２５は、障害内容ごとに参考復旧時間を記憶する。この参考復旧時間は、障害情報記憶部２２５に記憶される件数が少ない場合（例えば、２件以下）などに、平均復旧時間の代替として用いられる時間であり、予め定めた時間が設定されている。なお、この参考復旧時間は、任意に定められるものであり、障害内容ごとに予め定められる態様のほか、全ての障害内容で一律に定められてもよい。ここで、障害復旧時間は、復旧所要時間の一例である。
【００２９】
なお、障害検知部２０７は、障害発生時の影響を受けるサービスを判断する手段として捉えることができる。また、障害検知部２０７およびユーザ連絡部２１１は、障害を検知し、通知する手段として捉えることができる。また、対象ユーザ特定部２１３は、サービスに障害が発生した際この障害が収束するまでの時間を予測する手段、あるいはアクセス履歴から予測した時間内にアクセスがあるユーザを絞る手段、あるいは障害が発生した際にアクセス履歴からメール送信後のアクセス率や時間を予測する手段として捉えることができる。
【００３０】
また、対象ユーザ特定部２１３およびユーザ連絡部２１１は、障害のレベルによって、ユーザにアナウンス（通知）を行う手段として捉えることができる。また、アクセス履歴記憶部２２１は、ユーザのサービスへのアクセス履歴を記憶する手段として捉えることができる。また、障害情報記憶部２２５は、サービスの障害発生と収束までの時間を記憶する手段として捉えることができる。ヘルプデスク情報記憶部２２７は、サポートに関するメールを送信した履歴、リンク先などを記憶する手段として捉えることができる。
【００３１】
＜サーバ２０の動作例＞
図３は、サーバ２０の動作例を示したフローチャートである。
さて、第１クライアント１１〜第３クライアント１３に提供されるサービスに障害が発生した場合、例えばメールなどによって、障害が発生したことをユーザに通知することがある。しかしながら、通知を受けたユーザと発生した障害との関連性が低い場合、そのユーザが、通知を煩わしく感じることがある。ここで、発生した障害との関連性が低いとは、障害が発生したサービスをそのユーザが利用しない（利用頻度が低い）場合に加えて、そのユーザが障害の発生したサービスを次に利用するタイミングが、障害が復旧した後となる場合などがある。
【００３２】
そこで、本実施の形態におけるサーバ２０は、障害が発生した時間（時間帯）に応じて、障害発生を通知するユーザを絞り込む。より具体的には、障害復旧時刻を推定（予測）し、その障害復旧時刻に基づいて、障害発生を通知することの要否をユーザごとに決定する。なお、障害復旧時刻を予測することにより、障害発生を通知すべきユーザをより精度よく特定し得る。
【００３３】
以下、図１乃至図３を参照しながら、サーバ２０の動作例について説明をする。
なお、ここでは、第１クライアント１１〜第３クライアント１３において、監視対象サービスが提供されているものとする。また、サーバ２０の障害検知部２０７が、監視対象サービスにおける障害の有無を監視しているものとする。
【００３４】
まず、サーバ２０の障害検知部２０７が、監視対象サービスにおける障害が発生したことを検知すると（ステップ３０１でＹＥＳ）、障害検知部２０７は発生した障害の障害情報を特定（取得）する（ステップ３０２）。より具体的には、障害検知部２０７は、障害内容の特定、および障害発生時刻を取得し、障害情報記憶部２２５に記憶させる。
【００３５】
次に、対象ユーザ特定部２１３は、特定した障害内容と一致する障害が障害情報記憶部２２５に記憶されているかを判断する（ステップ３０３）。そして、特定した障害内容と一致する障害が、障害情報記憶部２２５に記憶されている場合（ステップ３０３でＹＥＳ）、対象ユーザ特定部２１３は、特定した障害内容が、履歴の中に３件以上含まれているかを判断する（ステップ３０４）。そして、履歴の中に３件以上含まれている場合（ステップ３０４でＹＥＳ）、対象ユーザ特定部２１３は、障害情報記憶部２２５に記憶されている特定した障害の平均復旧時間を取得する（ステップ３０５）。そして、取得した平均復旧時間、およびステップ３０２で取得した障害発生時刻に基づき、推定復旧時刻を算出する（ステップ３０６）。
【００３６】
一方、特定した障害内容が障害情報記憶部２２５に記憶されていない場合（ステップ３０３でＮＯ）、あるいは履歴の中に３件以上含まれていない場合（ステップ３０４でＮＯ）、対象ユーザ特定部２１３は、障害情報記憶部２２５に記憶されている参考復旧時間を取得する（ステップ３０７）。そして、取得した参考復旧時間、およびステップ３０２で取得した障害発生時刻に基づき、推定復旧時刻を算出する（ステップ３０６）。
【００３７】
次に、対象ユーザ特定部２１３は、算出された推定復旧時刻に基づいて、対象ユーザを特定する（ステップ３０８）。詳細は後述するが、対象ユーザ特定部２１３は、アクセス履歴記憶部２２１およびユーザ属性記憶部２２３に記憶されている情報に基づいて、推定復旧時刻までに障害が発生した監視対象サービスを利用する可能性が高いユーザを絞りこむ。
【００３８】
次に、対象ユーザ特定部２１３は、ヘルプデスク情報記憶部２２７が記憶するヘルプデスク情報に基づき、予め定めた期間内におけるヘルプデスク履歴があるかを判断する（ステップ３０９）。例えば、対象ユーザ特定部２１３は、障害発生時刻よりも前の予め定めた期間（例：２４時間）において、ヘルプデスク３０からユーザにメールが送信されているかを判断する。
【００３９】
そして、ヘルプデスク履歴がある場合（ステップ３０９でＹＥＳ）、対象ユーザ特定部２１３は、送信したメールの本文にリンク先の情報が含まれているかを判断する（ステップ３１０）。そして、リンク先の情報が含まれている場合（ステップ３１０でＹＥＳ）、対象ユーザ特定部２１３は対象ユーザの更新を行う（ステップ３１１）。すなわち、リンク先が含まれたメールにおける送信先のユーザを、対象ユーザに追加する。そして、特定された対象ユーザのリストである対象ユーザリストを作成する（ステップ３１２）。
【００４０】
一方、ヘルプデスク履歴がない場合（ステップ３０９でＮＯ）、あるいはリンク先の情報が含まれていない場合（ステップ３１０でＮＯ）、対象ユーザ特定部２１３は、ステップ３０８で特定された対象ユーザに基づき、対象ユーザリストを作成する（ステップ３１２）。
【００４１】
次に、ユーザ連絡部２１１は、ユーザ属性記憶部２２３に記憶されるユーザ属性情報に基づき、対象ユーザリストに含まれるユーザごとに、障害発生の際の通知方法がメールであるかを判断する（ステップ３１３）。そして、この通知方法がメールである場合（ステップ３１３でＹＥＳ）、ユーザ連絡部２１１は、障害発生を通知するメールをそのユーザに送信する（ステップ３１４）。
【００４２】
一方、障害発生の際の通知方法がメールでない場合（ステップ３１３でＮＯ）、ユーザ連絡部２１１は、障害発生をメール以外の方法で通知する（ステップ３１５）。図示の例においては、サービス画面にポップアップ表示を行う設定をする。
そして、ユーザ連絡部２１１は、障害発生の通知方法の履歴（リスト）である通知リストを作成し記憶する（ステップ３１６）。
【００４３】
次に、障害検知部２０７は、推定復旧時刻が経過したかを判断する（ステップ３１７）。そして、推定復旧時刻を経過した場合（ステップ３１７でＹＥＳ）、障害検知部２０７は、障害が終了したか、すなわち障害から復旧したかを判断する（ステップ３１８）。そして、障害から復旧した場合（ステップ３１８でＹＥＳ）、本処理フローは終了する。
一方、障害から復旧していない場合（ステップ３１８でＮＯ）、ステップ３０２へ移行する。なお、この移行した後のステップ３０２における障害特定では、障害発生時刻を、上記移行する前のステップ３０６で算出した推定復旧時刻に置き替えて各処理を行う。
【００４４】
＜サーバ２０の処理情報＞
図４（ａ）乃至（ｆ）は、サーバ２０の動作に関する情報を説明するための図である。
次に、図４（ａ）乃至（ｆ）を参照しながら、サーバ２０の動作にともない処理される情報について説明をする。
なお、ここでは例として、２０１５年１２月２５日午前４時に複合機サービスを提供するサーバ（不図示）において、インターフェイス画面遅延による障害（以下、画面障害）が発生したものとする。
【００４５】
図４（ａ）は、障害情報記憶部２２５に記憶される障害情報の一例を示す。
この図４（ａ）に示す障害情報は、障害の履歴情報である。具体的には、この障害情報は、参照番号、障害のアラート（エラーコード）、障害内容、発生日時、サービスの影響、および時刻の情報を含む。なお、サービスの影響は、サービス画面の種別、レポートの種別を含む。また、時刻は、障害の発生時刻（障害発生時刻）、障害の終了時刻（復旧時刻）を含む。
【００４６】
ここで、上記図３のステップ３０１およびステップ３０２で説明したように、サーバ２０の障害検知部２０７が障害の発生を検知すると、障害情報を取得し障害情報記憶部２２５に記憶させる。
この例においては、図４（ａ）における「ＮＯ．１」（参照番号１）に、上記画面障害が記憶される。この画面障害のアラートは、「Ａ０００１」である。なお、図示の例においては、画面障害が発生した直後であり、画面障害は未だ終了していないため、終了時刻は記録がない状態である（図中矢印参照）。
【００４７】
ここで、アラート「Ａ０００１」の画面障害は、約６ヶ月前（２０１５年６月６日）および約１１ヶ月前（２０１５年１月２０日）にも発生している。付言すると、この画面障害は、年２回ほど発生しており、過去２回とも午前４時に発生し、午前１０時までに復旧している。
また、この過去２回の画面障害の平均復旧時間は、「５時間４８分」である。そして、この場合、障害発生時刻から平均復旧時間が経過した時刻である推定復旧時刻は、「２０１５年１２月２５日午前４時」の「５時間４８分」後、すなわち「２０１５年１２月２５日午前９時４８分」と算出される（ステップ３０６参照）。
【００４８】
図４（ｂ）は、ユーザ属性記憶部２２３に記憶されるユーザ属性情報の一例を示す。
図示のユーザ属性情報は、ユーザの名称、利用サービスの種別、ユーザが参照できる画面の種別、条件（プレミアムユーザ、特約店）の情報を含む。
図４（ｃ）は、対象ユーザ特定部２１３によって特定される対象ユーザ情報の一例を示す。
【００４９】
上記図３のステップ３０８で説明したように、対象ユーザ特定部２１３は、障害情報記憶部２２５に記憶される障害情報と、ユーザ属性記憶部２２３に記憶されるユーザ属性情報と、算出された推定復旧時刻とに基づいて、対象ユーザを特定する。
上記の例においては、障害発生時刻である「２０１５年１２月２５日午前４時」から、推定復旧時刻である「２０１５年１２月２５日午前９時４８分」までの間にアクセスし得るユーザが特定される。例えば、３０日以内に上記時間帯にアクセスしたユーザを、アクセスし得るユーザとする。なお、この例においては、１００人の対象ユーザが特定されるものとする。
【００５０】
図４（ｄ）は、ヘルプデスク情報記憶部２２７に記憶されるヘルプデスク情報の一例を示す。
図４（ｅ）は、対象ユーザ特定部２１３によって更新された対象ユーザ情報の一例を示す。
【００５１】
図４（ｄ）に示すヘルプデスク情報は、ユーザの名称、ユーザに送信されたメールの種別、リンク画面の種別、リンク先へアクセスした日付および時間の情報を含む。なお、このヘルプデスク情報（履歴）は、例えば障害発生時刻よりも前の予め定めた期間において、ユーザに送信されたメールに関する情報である。
【００５２】
ここで、上記図３のステップ３１１で説明したように、対象ユーザ特定部２１３は、ヘルプデスク情報に基づいて対象ユーザの更新を行う。
図４（ｄ）の例においては、ユーザ「ａｂｃ」およびユーザ「ｄｅｆ」に「データ更新」のメールが送信されている。そして、ユーザ「ａｂｃ」およびユーザ「ｄｅｆ」は、メール送信から３時間で、ユーザに送信されたメールに含まれるリンク先へアクセスしている。ここで、この「データ更新」のメールが、障害発生時刻の１時間前に送信されている場合を想定すると、ユーザ「ａｂｃ」およびユーザ「ｄｅｆ」は、メール送信日時である２０１５年１２月２５日午前３時から「３時間」後の「２０１５年１２月２５日午前６時」にアクセスする可能性がある（可能性が高い）。そして、この時刻は、上記の推定復旧時刻である「２０１５年１２月２５日午前９時４８分」よりも前である。
【００５３】
したがって、ユーザ「ａｂｃ」およびユーザ「ｄｅｆ」を対象ユーザとして特定する必要がある。ここで、図４（ｃ）の対象ユーザ情報においては、ユーザ「ａｂｃ」は含まれている一方で、ユーザ「ｄｅｆ」は含まれていない。
したがって、図４（ｅ）に示すように、対象ユーザ情報にユーザ「ｄｅｆ」が追加される（図中矢印参照）。ここでは、上記図４（ｃ）で特定された１００人に１人加え、１０１人の対象ユーザが特定されることとなる。
【００５４】
図４（ｆ）は、ユーザ連絡部２１１が作成し記憶する通知リストの一例を示す。
上記図３のステップ３１６で説明したように、ユーザ連絡部２１１は、通知リストを作成し記憶する。
図４（ｆ）に示す通知リストは、アラート、障害報告方法の種別を含む。
また、この例においては、ユーザ連絡部２１１は、図４（ｆ）に示す通知リストを作成しその情報を記憶するとともに、ヘルプデスク情報から障害対象の画面リンクがあるメールは送信できないよう、その機能を停止する。
【００５５】
上記の例においては、時間を測定して障害内容を通知することで、通知が不要なユーザに無駄な情報を通知（展開）することが抑制される。すなわち、障害情報が適切に通知される。
【００５６】
さて、一般的に、障害が発生した場合に、サービスを利用しようとしたユーザからヘルプデスク３０への連絡（メール、電話）が増加することがある。本実施の形態においては、上記のように障害発生にともないユーザに対して、ユーザが必要とする情報を予め伝達（通知）することで、ヘルプデスク３０の負担を軽減する。付言すると、ヘルプデスク３０の負担軽減により、ヘルプデスク３０のサポート率が高まり得る。
【００５７】
なお、本実施の形態とは異なる従来技術として、障害が発生する可能性を事前に検知する、あるいはユーザに適切な情報を自動的に提供する技術の存在が考えられる。しかしながら、本実施の形態においては、これらの技術とは異なり、障害が発生後の通知において、障害が発生したサービスにアクセスする可能性が高いユーザに絞って、通知する機能を有する。
【００５８】
また、一般的に、障害情報通知時に、その通知を必要とするユーザ、すなわち適切なユーザを把握することは難しい。さらに説明をすると、障害のレベルによって、サービス・画面の障害影響が異なるものの、障害レベルによって通知する機能がない。
一方、本実施の形態においては、障害が発生した時間から復旧までの時間を計算し、その時間の平均値から、障害が発生したサービスへアクセスする可能性が高いユーザを分析して、通知を行う。そして、このアクセスする可能性が高いユーザは、上述のようにアクセス・操作履歴、サポート情報などに基づいて特定される。
【００５９】
付言すると、本実施の形態においては、ユーザにより過去に実行されたアクセスの態様に基づいて、通知を行うユーザを特定する。例えば、あるユーザがサービスを利用する可能性が高い時間帯（アクセスする時刻）が、障害発生時刻から推定された障害復旧時刻までと重複している場合には、このユーザに対して通知を行う。
【００６０】
図５は、サーバ２０のハードウェア構成例を示した図である。
サーバ２０は、上述のようにコンピュータ装置により実現される。
図５に示すように、サーバ２０は、演算手段であるＣＰＵ（Central Processing Unit）２３１と、記憶手段であるメインメモリ２３３およびＨＤＤ（Hard Disk Drive）２３５とを備える。ここで、ＣＰＵ２３１は、ＯＳ（Operating System）やアプリケーションソフトウェア等の各種プログラムを実行する。また、メインメモリ２３３は、各種プログラムやその実行に用いるデータ等を記憶する記憶領域である。ＨＤＤ２３５は、各種プログラムに対する入力データや各種プログラムからの出力データ等を記憶する記憶領域である。
【００６１】
また、サーバ２０は、外部との通信を行うための通信インターフェイス（通信Ｉ／Ｆ）２３７を備えている。なお、ＣＰＵ２３１が実行するプログラムは、予めメインメモリ２３３に記憶させておく形態の他、例えばＣＤ−ＲＯＭ等の記憶媒体に格納してＣＰＵ２３１に提供したり、あるいは、ネットワーク４０（図１参照）を介してＣＰＵ２３１に提供したりすることも可能である。
【００６２】
＜その他＞
さて、想定外のユーザのアクセスがある場合、そのユーザからのアクセスを検知した時点で通知を実行してもよい。例えば、障害発生後で他のユーザへの通知は終了した後に、障害通知を実行していないユーザからのアクセスがアクセス履歴から確認できる場合、そのユーザに対して障害内容を即時通知してもよい。
【００６３】
また、上記の説明においては、推定復旧時刻を経過して障害から復旧していない場合（ステップ３１８でＮＯ）、事前に設定された時間であって、障害開始から復旧までの時間（参考復旧時間）が経過するまでに、アクセスする可能性が高いユーザを洗い出して対応を行ってもよい。
【００６４】
ここで、上記の説明においては、対象ユーザの更新（ステップ３１１）、言い換えると対象ユーザの追加あるいは削除は、ヘルプデスク履歴に基づいて実行されることを説明した。この対象ユーザの更新は、ユーザのサービス使用態様に基づいて実行されれば、特に限定されない。例えば、あるユーザが全くアクセスしない場合は、そのユーザに対して通知をしなくてもよい。また、例えば、あるユーザがプレミアムサービスを頻繁に利用する場合は、そのユーザに対してメールでの通知に加えて電話での連絡も行う態様でもよい。
【００６５】
さて、上記平均復旧時間の算出方法は、特に限定されない。例えば、同一の障害内容の履歴が３件以上ある場合に、最長の復旧時間および最短の復旧時間を除き、残りの平均値を算出してもよい。また、同一の障害内容に限らず、類似の障害内容をまとめて平均値を算出してもよい。また、障害内容とは異なる要素、例えば障害発生の時間帯ごとに、平均値を算出してもよい。
さらに、復旧時間の平均値に替えて、他の代表値を用いてもよい。例えば、最長の復旧時間や、最短の復旧時間などを用いてもよい。
【００６６】
また、障害が発生したことを通知するメールの内容としては、推定復旧時刻に関する情報を含めてもよい。例えば、上記の例においては「２０１５年１２月２５日午前９時４８分」に復旧予定という文面を含めてもよい。あるいは、推定復旧時刻をより幅をもたせて表現してもよい。例えば、「２０１５年１２月２５日午前中」に復旧予定という文面を含めてもよい。
また、上記の構成とは異なり、障害通知システム１がヘルプデスク３０を備えない構成であってもよい。
【００６７】
また、推定復旧時刻経過後に障害が終了していない場合（ステップ３１８でＮＯ）、ステップ３０２へ移行することを説明したが、これに限定されない。例えばステップ３１２で作成した対象ユーザリストに含まれるユーザに再度通知をしてもよい。あるいは、障害復旧がさらに遅れることでサービスを提供するシステム全体に影響を及ぼす可能性もあることから、推定復旧時刻経過後に障害が終了していない場合（ステップ３１８でＮＯ）、より多くのユーザ、例えば全てのユーザに通知をしてもよい。
また、推定復旧時刻経過後のステップ（ステップ３１７、ステップ３１８）は省略してもよい。
【００６８】
また、サービスを提供するシステム全体が停止した場合には、全てのユーザに通知をしてもよい。言い替えると、発生した障害の程度に応じて、上述のように障害発生時刻および推定復旧時刻とに基づいてユーザへ通知を実行する態様と、障害発生時刻および推定復旧時刻と関係なくユーザへ通知を実行する態様とを切り替えてもよい。
【００６９】
なお、上記では種々の実施形態および変形例を説明したが、これらの実施形態や変形例どうしを組み合わせて構成してももちろんよい。
また、本開示は上記の実施形態に何ら限定されるものではなく、本開示の要旨を逸脱しない範囲で種々の形態で実施することができる。
【符号の説明】
【００７０】
１…障害通知システム、１０…クライアント群、２０…サーバ、３０…ヘルプデスク、２０７…障害検知部、２１３…対象ユーザ特定部、２２１…アクセス履歴記憶部、２２３…ユーザ属性記憶部、２２５…障害情報記憶部
【図１】
2018046422.tif 000003
【図２】
2018046422.tif 000004
【図３】
2018046422.tif 000005
【図４】
2018046422.tif 000006
【図５】
2018046422.tif 000007