JP6861881B1 - 通知装置、通知方法及び通知プログラム - Google Patents

Abstract

【課題】所定のサービスが提供する機能を利用する他のサービスが適切に提供されているかを適切に判定する。【解決手段】本願に係る通知装置は、サービスの提供者により管理されるサーバとは異なる所定のサーバにより提供される機能であって、当該サービスにおいて利用される機能が稼働するか否かを判定する判定部と、判定部により機能が稼働していないと判定された場合は、サービスに対応する通知先に対して機能が稼働していない旨を通知する通知部とを有することを特徴とする。【選択図】図１

Description

本発明は、通知装置、通知方法及び通知プログラムに関する。

従来、通信ネットワークの発達に伴い、通信ネットワークに接続された情報機器の稼働を監視するための技術が提案されている。このような技術の一例として、データ処理を実行するサーバの作成済みファイルの一覧に基づいて当該データ処理が進行しているか否かを判断し、データ処理が進行していないと判断した回数のカウント値が所定の閾値を超えた場合に、当該サーバが正常に稼働していないと判断する技術が提案されている。

特開２０１６−１１０２０３号公報

しかしながら、上記の従来技術では、所定のサービスが提供する機能を利用する他のサービスが適切に提供されているかを適切に判定することができない場合がある。

例えば、複数の機能を提供する第１サービスを利用して、利用者に対し各種の第２サービスを提供するといった態様が考えられる。このような態様において、第１サービスが提供する機能のうちいずれかの機能に障害が発生した場合には、障害が発生した機能を利用する第２サービスのみが適切に提供されなくなる。しかしながら、上記の従来技術では、サーバが正常に稼働しているか否かを判断しているに過ぎないため、第１サービスが提供する機能のうちいずれかの機能に障害が発生したとしても、第２サービスのうちどの第２サービスが適切に提供されなくなるかを特定することができない。

本願は、上記に鑑みてなされたものであって、所定のサービスが提供する機能を利用する他のサービスが適切に提供されているかを適切に判定する通知装置、通知方法及び通知プログラムを提供することを目的とする。

本願に係る通知装置は、サービスの提供者により管理されるサーバとは異なる所定のサーバにより提供される機能であって、当該サービスにおいて利用される機能が稼働するか否かを判定する判定部と、前記判定部により前記機能が稼働していないと判定された場合は、前記サービスに対応する通知先に対して前記機能が稼働していない旨を通知する通知部とを有することを特徴とする。

実施形態の一態様によれば、所定のサービスが提供する機能を利用する他のサービスが適切に提供されているかを適切に判定できるという効果を奏する。

図１は、実施形態に係る通知処理の一例を示す図である。 図２は、情報処理装置により提供されるコンテンツの一例を示す図である。 図３は、実施形態に係る情報処理装置の構成例を示す図である。 図４は、実施形態に係る稼働状況データベースの一例を示す図である。 図５は、実施形態に係る通知処理の手順の一例を示すフローチャートである。 図６は、情報処理装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

以下に本願に係る通知装置、通知方法及び通知プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る通知装置、通知方法及び通知プログラムが限定されるものではない。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。

〔１．実施形態〕
図１を用いて、本実施形態の通知装置等により実現される通知処理について説明する。図１は、実施形態に係る通知処理の一例を示す図である。なお、図１では、本実施形態に係る通知装置の一例である情報処理装置１０によって、実施形態に係る通知処理などが実現されるものとする。

図１に示すように、実施形態に係る通知システム１は、情報処理装置１０と、サーバ１００と、サービスサーバ２００と、管理者端末３００とを含む。情報処理装置１０、サーバ１００、サービスサーバ２００及び管理者端末３００は、ネットワークＮ（例えば、図３参照）を介して有線または無線により相互に通信可能に接続される。ネットワークＮは、例えば、インターネットなどのＷＡＮ（Wide Area Network）である。なお、図１に示した通知システム１には、複数台の情報処理装置１０、複数台のサーバ１００、複数台のサービスサーバ２００及び複数台の管理者端末３００が含まれていてもよい。

図１に示す情報処理装置１０は、通知処理を行う情報処理装置であり、例えば、サーバ装置やクラウドシステム等により実現される。例えば、情報処理装置１０は、各種サービスにおいて利用される機能であって、サーバ１００によりＡＰＩ（Application Programming Interface）を介して提供される機能が稼働するか否かを判定し、判定結果に基づく情報を所定の通知先に通知する。

図１に示すサーバ１００は、各種の機能を実現する情報処理装置であり、サーバ装置やクラウドシステム等により実現される。例えば、サーバ１００は、情報処理の要求をＡＰＩによって受け付け、情報処理の結果を要求元へ返すＡＰＩサーバである。具体的な例を挙げると、サーバ１００は、地図ＡＰＩにより店舗の位置をサービスサーバ２００に返す。また、サーバ１００は、天気ＡＰＩにより一日の気温をサービスサーバ２００に返す。

なお、サーバ１００は、電子決済に関する決済処理を実行する情報処理装置であってもよい。例えば、サーバ１００は、利用者が利用する利用者端末を用いる電子決済に関する電子決済サービスを提供する。例えば、サーバ１００は、取引対象の提供者（事業者）や取引対象が提供される利用者の口座を管理しており、利用者からの決済要求に従って、口座間において電子マネーの移行等を行うことで、各種決済を実現する。なお、電子マネーとは、例えば、各種企業が独自に用いるポイントや通貨等であってもよく、日本円やドル等の国家により提供される貨幣を電子的に取引可能としたものであってもよい。

また、サーバ１００は、ＡＰＩを介して、電子決済サービスに関する各種の機能をサービスサーバ２００に提供してもよい。

図１に示すサービスサーバ２００は、各種サービスを利用者に提供するサーバ装置である。サービスサーバ２００は、例えば、ポータルサービスや、検索サービス、ショッピングサービス、オークションサービス、ピックアップサービス、フードデリバリーサービス、情報提供サービス（例えば、地図情報サービス、ナビゲーションサービス、ニュースサービス、天気予報サービス）、スケジュールを登録するカレンダーサービスなどの各種サービスを利用者に提供する。

図１に示す管理者端末３００は、サービスサーバ２００を管理する管理者によって利用される情報処理装置である。管理者端末３００は、例えば、スマートフォンや、タブレット型端末、ノート型ＰＣ（Personal Computer）、デスクトップＰＣ、携帯電話機、ＰＤＡ（Personal Digital Assistant）等により実現される。また、管理者端末３００は、情報処理装置１０やサーバ１００によって配信される情報を、ウェブブラウザやアプリケーションにより表示する。なお、図１に示す例では、管理者端末３００がノート型ＰＣである場合を示すが、ウェブユーザインターフェースを用いて管理者が利用する任意の端末装置がネットワークＮに接続されてよい。

なお、管理者端末３００は、所定の情報処理を実現する制御情報を情報処理装置１０やサーバ１００から受け取った場合には、制御情報に従って情報処理を実現する。ここで、制御情報は、例えば、ＪａｖａＳｃｒｉｐｔ（登録商標）等のスクリプト言語やＣＳＳ（Cascading Style Sheets）等のスタイルシート言語により記述される。なお、情報処理装置１０やサーバ１００から配信される所定のアプリケーションそのものを制御情報とみなしてもよい。

〔１−１．利用者端末を用いた決済について〕
ここで、情報処理装置１０が実行する通知処理に先立ち、サーバ１００を用いた決済（電子決済）の一例について説明する。なお、以下の説明では、店舗に配置された２次元コード（ＱＲコード（登録商標））であって、店舗を識別する店舗識別情報を示す２次元コードを用いて、利用者が利用者端末を用いた決済を行う例について説明するが、実施形態は、これに限定されるものではない。例えば、店舗識別情報は、ＱＲコードのみならず、バーコードや所定のマーク、番号等であってもよい。

例えば、利用者が店舗にて各種の商品やサービスといった決済対象（取引対象）の利用や購入に伴う決済を行う場合、利用者は、利用者端末に予めインストールされた決済アプリを起動する。そして、利用者は、決済アプリを介して、店舗に設置された店舗識別情報を撮影する。このような場合、利用者端末は、決済対象の価格を入力するための画面を表示し、利用者或いは店舗の店員から決済金額の入力を受け付ける。そして、利用者端末は、利用者を識別する利用者識別情報と、店舗識別情報（若しくは、店舗識別情報が示す情報、すなわち、店舗を示す情報（例えば、店舗ＩＤ））と、決済金額とを示す決済情報をサーバ１００へと送信する。

このような場合、サーバ１００は、利用者識別情報が示す利用者の口座から、店舗識別情報が示す店舗の口座へと、決済金額が示す額の電子マネーを移行させる。そして、サーバ１００は、決済が完了した旨の通知を利用者端末へと送信する。このような場合、利用者端末は、決済が完了した旨の画面や所定の音声を出力することで、電子マネーによる決済が行われた旨を通知する。

なお、利用者端末を用いた決済は、上述した処理に限定されるものではない。例えば、利用者端末を用いた決済は、店舗に設置された店舗端末を用いたものであってもよい。例えば、利用者端末は、利用者を識別するための利用者識別情報を画面上に表示させる。このような場合、店舗に設置された店舗端末は、利用者端末に表示された利用者識別情報を読み取り、利用者識別情報（若しくは、利用者識別情報が示す情報、すなわち、利用者を示す情報（例えば、利用者ＩＤ））と、決済金額と、店舗を識別する情報とを示す決済情報をサーバ１００へと送信する。このような場合、サーバ１００は、利用者識別情報が示す利用者の口座から、店舗の口座へと、決済金額が示す額の電子マネーを移行させ、店舗端末或いは利用者端末に対し、決済が完了した旨の画面や所定の音声を出力させることで、決済が行われた旨を通知してもよい。

また、利用者端末を用いた決済は、利用者が予め電子マネーをチャージした口座から店舗の口座へと電子マネーを移行させる処理のみならず、例えば、利用者が予め登録したクレジットカードを用いた決済であってもよい。このような場合、例えば、利用者端末は、店舗の口座に対して決済金額の電子マネーを移行させるとともに、利用者のクレジットカードの運用会社に対し、決済金額を請求してもよい。

〔１−２．実施形態の概要について〕
ここで、従来、通信ネットワークに接続された情報機器の稼働を監視するための技術として、データ処理を実行するサーバの作成済みファイルの一覧に基づいて当該データ処理が進行しているか否かを判断し、データ処理が進行していないと判断した回数のカウント値が所定の閾値を超えた場合に、当該サーバが正常に稼働していないと判断する技術が提案されている。しかしながら、このような技術では、サーバが正常に稼働しているか否かを判断しているに過ぎないため、例えば、複数の機能を提供する第１サービスを利用して、利用者に対し各種の第２サービスを提供するといった態様において、第１サービスが提供する機能のうちいずれかの機能に障害が発生したとしても、第２サービスのうちどの第２サービスが適切に提供されなくなるかを特定することができない。

そこで、情報処理装置１０は、実施形態に係る通知処理を実行する。以下、図１を用いて、情報処理装置１０が実行する通知処理について説明する。なお、以下の説明では、それぞれ異なるサービスを提供するサービスサーバ２００−１〜２００−３により、利用者に各種のサービスが提供される例を示す。また、以下の説明において、サービスサーバ２００−１〜２００−３は、それぞれサーバ１００により提供されるＡＰＩ群＃１〜＃３を介して電子決済サービスに関する機能を利用し、利用者にサービスを提供するものとする。また、以下の説明では、サービスサーバ２００−１〜２００−３について、特に区別なく説明する場合には、サービスサーバ２００と記載する。なお、通知システム１は、４台以上のサービスサーバ２００を有していてもよい。

また、以下の説明において、サービスサーバ２００−１〜２００−３は、それぞれ管理者端末３００−１〜３００−３を利用する管理者により管理されるものとする。また、以下の説明では、管理者端末３００−１〜３００−３について、特に区別なく説明する場合には、管理者端末３００と記載する。

まず、情報処理装置１０は、サーバ１００が提供する各機能に関する情報を収集する（ステップＳ０）。例えば、情報処理装置１０は、サーバ１００が提供する機能群の動作内容であって、サービスサーバ２００が提供する各サービスにおける動作内容を収集する。

続いて、情報処理装置１０は、サーバ１００が提供する機能が稼働するか否かを所定期間（例えば、１時間）ごとに判定する（ステップＳ１）。所定の期間は、秒、分、時間の単位で任意に設定できる。情報処理装置１０は、各サービスサーバ２００が提供するサービスごとに、当該サービスにおいて利用される機能群が正常に稼働するか否かを判定する。具体的な例を挙げると、情報処理装置１０は、ＡＰＩ群＃１を介したサービスサーバ２００−１からサーバ１００へのアクセスを実行する。そして、情報処理装置１０は、ＡＰＩ群＃１に対応する機能群のうち、サーバ１００からの応答がなかった機能を正常に稼働していない機能と判定する。同様に、情報処理装置１０は、ＡＰＩ群＃２及び＃３に関しても、それぞれサービスサーバ２００−２及び２００−３によるアクセスを実行し、ＡＰＩ群＃２及び＃３に対応する機能群が稼働するか否かを判定する。

なお、情報処理装置１０は、ステップＳ０において収集した情報に基づいてテストケースを作成し、作成したテストケースに基づいて機能が正常に稼働するか否かを判定してもよい。

続いて、情報処理装置１０は、機能の稼働状況を示す情報を収集する（ステップＳ２）。例えば、情報処理装置１０は、稼働していないと判定された機能と、当該機能が機能していないと判定された日時とを含む情報を稼働状況として収集し、自装置の記憶部に格納する。

続いて、情報処理装置１０は、機能の稼働状況を管理者端末３００に通知する（ステップＳ３）。例えば、ＡＰＩ群＃１に対応する機能群のいずれかが稼働していないと判定された一方で、ＡＰＩ群＃２及び＃３に対応する機能群が稼働していると判定された場合、情報処理装置１０は、管理者端末３００−１に対し、サービスサーバ２００−１が利用する機能が稼働していない旨を通知する。

なお、情報処理装置１０は、サービスサーバ２００が利用する機能の稼働状況を示すコンテンツを管理者端末３００に通知（提供）してもよい。ここで、図２を用いて、情報処理装置１０により提供され、管理者端末３００に表示されるコンテンツについて説明する。図２は、情報処理装置により提供されるコンテンツの一例を示す図である。

図２の例において、管理者端末３００は、サーバ１００が提供する機能＃１の稼働状況を示すコンテンツＣ１を表示する。例えば、管理者端末３００は、直近の６０日間における各日ごとの機能＃１の稼働状況を所定のオブジェクトにより示す領域ＡＲ１と、コンテンツＣ１の表示態様の変更を指示するためのボタンＢ１及びＢ２とを含むコンテンツＣ１を表示する。

図２の例において、領域ＡＲ１に表示されるオブジェクトＯｂ１は、対応する日付において機能＃１に対応する情報が存在しなかった（Ｎ／Ｄ：No Data）ことを示す。また、オブジェクトＯｂ２は、対応する日付において機能＃１が所定期間稼働していなかったことを示す。また、オブジェクトＯｂ３は、機能＃１が対応する日付において完全に稼働していなかったことを示す。また、オブジェクトＯｂ１〜Ｏｂ３以外のオブジェクトは、機能＃１が正常に稼働していたことを示す。

また、図２の例において、ボタンＢ１が管理者に押下された場合、管理者端末３００は、ひと月ごとの機能＃１の稼働状況が表示されるように、領域ＡＲ１の表示態様を変更する。ボタンＢ２が管理者に押下された場合、管理者端末３００は、直近の所定期間（例えば、２４時間）における１時間ごとの機能＃１の稼働状況が表示されるように、領域ＡＲ１の表示態様に変更する。

なお、図２に示す領域ＡＲ１のオブジェクトのいずれかが押下された場合、管理者端末３００は、対応する日付における１時間ごとの機能＃１の稼働状況が表示されるよう、領域ＡＲ１の表示態様に変更してもよい。

以上のように、実施形態に係る情報処理装置１０は、サーバ１００が提供するＡＰＩに対しサービスサーバ２００よるアクセスを実行することで、ＡＰＩに対応する機能が稼働するか否かを判定する。これにより、実施形態に係る情報処理装置１０は、上述の実施形態のように、サーバ１００によって複数の機能が他の各種サービスに提供されるといった態様であっても、いずれのサービスに提供している機能に障害が発生したかを判定することができる。すなわち、実施形態に係る情報処理装置１０は、所定のサービスが提供する機能を利用する他のサービスが適切に提供されているかを適切に判定できる。

〔２．情報処理装置の構成〕
次に、図３を用いて、情報処理装置１０の構成について説明する。図３は、実施形態に係る情報処理装置の構成例を示す図である。図３に示すように、情報処理装置１０は、通信部２０と、記憶部３０と、制御部４０とを有する。

（通信部２０について）
通信部２０は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。そして、通信部２０は、ネットワークＮと有線または無線で接続され、サーバ１００や、サービスサーバ２００、管理者端末３００等との間で情報の送受信を行う。

（記憶部３０について）
記憶部３０は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。図３に示すように、記憶部３０は、稼働状況データベース３１と、モデルデータベース３２とを有する。

（稼働状況データベース３１について）
稼働状況データベース３１は、サーバ１００が提供する機能の稼働状況を示す情報を記憶する。ここで、図４を用いて、稼働状況データベース３１が記憶する情報の一例を説明する。図４は、実施形態に係る稼働状況データベースの一例を示す図である。図４の例において、稼働状況データベース３１は、「機能ＩＤ」、「稼働状況」といった項目を有する。

「機能ＩＤ」は、機能を識別するための識別子を示す。「稼働状況」は、機能の稼働状況に関する情報を示し、例えば、機能が稼働するか否かを判定した日時や、当該日時において当該機能が稼働していたか否かを示す情報などが格納される。

すなわち、図３では、機能ＩＤ「ＡＩＤ＃１」によって識別される機能の稼働状況が「稼働状況＃１」である例を示す。

（モデルデータベース３２について）
モデルデータベース３２は、日時をモデルに入力した場合に、当該日時における機能の稼働状況を出力するモデルを記憶する。なお、モデルデータベース３２は、サーバ１００が提供する機能ごとに学習されたモデルを記憶してもよく、単一のモデルを記憶してもよい。

（制御部４０について）
制御部４０は、コントローラ（controller）であり、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、情報処理装置１０内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部４０は、コントローラであり、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。実施形態に係る制御部４０は、図２に示すように、判定部４１と、学習部４２と、推定部４３と、通知部４４とを有し、以下に説明する情報処理の機能や作用を実現または実行する。

（判定部４１について）
判定部４１は、サービスの提供者により管理されるサーバとは異なる所定のサーバにより提供される機能であって、当該サービスにおいて利用される機能が稼働するか否かを判定する。例えば、図１の例において、判定部４１は、各種サービスの提供者（管理者）より管理されるサービスサーバ２００とは異なるサーバ１００により提供される機能であって、当該各種サービスにおいて利用される機能が稼働するか否かを判定し、判定結果を稼働状況データベース３１に格納する。

また、判定部４１は、所定のサーバにより提供される機能のうち、サービスが利用する機能群が稼働するか否かを判定してもよい。例えば、図１の例において、判定部４１は、サーバ１００により提供される機能のうち、サービスサーバ２００が提供するサービスが利用する機能群が稼働するか否かを判定する。

また、判定部４１は、所定のサーバにより提供される機能が複数のサービスにおいて利用される場合は、サービスごとに当該サービスにおいて利用される機能が稼働するか否かを判定してもよい。例えば、図１の例において、判定部４１は、サービスサーバ２００−１からサーバ１００へのアクセスを実行する。そして、情報処理装置１０は、サービスサーバ２００−１が提供するサービスにおいて利用される機能群のうち、サーバ１００からの応答がなかった機能を稼働していない機能と判定する。

また、判定部４１は、ＡＰＩを介して所定のサーバにより提供される機能が稼働するか否かを判定してもよい。例えば、図１の例において、判定部４１は、ＡＰＩ群＃１を介したサービスサーバ２００−１からサーバ１００へのアクセスを実行することにより、サーバ１００により提供される機能が稼働するか否かを判定する。

（学習部４２について）
学習部４２は、判定部４１により稼働していないと判定された機能と、当該機能が稼働しなかった日時とをモデルに学習させる。例えば、学習部４２は、稼働状況データベース３１に格納された情報を正解データとし、サーバ１００が提供する各機能に対応するモデルに学習させる。具体的な例を挙げるとは、学習部４２は、所定の期間と、対応する期間における対象の機能の稼働状況（例えば、図２の例における領域ＡＲ１に表示されるオブジェクトの出現パターン）との組を正解データとしてモデルに学習させる。すなわち、学習部４２は、日時をモデルに入力した際に、当該日時における対象の機能の稼働状況、若しくは、稼働状況に対応する情報（例えば、図２に示すように、機能の稼働状況をオブジェクトＯｂ１〜Ｏｂ３等により示すコンテンツ）を出力するように、バックプロパゲーション等の技術を用いてモデルの学習を行う。

なお、学習部４２が学習させるモデルは、任意の種別のモデルが採用可能である。例えば、学習部４２は、ＳＶＭ（Support Vector Machine）やＤＮＮ（Deep Neural Network）をモデルとして採用してもよい。ここで、ＤＮＮは、ＣＮＮ（Convolutional Neural Network）やＲＮＮ（Recurrent Neural Network）であってもよい。また、ＲＮＮは、ＬＳＴＭ（Long short-term memory）等であってもよい。また、モデルは、ＣＮＮとＲＮＮとを組み合わせたモデル等、複数のモデルを組み合わせることで実現されてもよい。

（推定部４３について）
推定部４３は、学習部４２により学習されたモデルに基づいて、判定部４１により稼働していないと判定された機能が稼働しないタイミングを推定する。例えば、推定部４３は、学習済みのモデルに対し、日時及び機能ＩＤを入力し、モデルが出力した情報を推定結果とする。

（通知部４４について）
通知部４４は、判定部４１により機能が稼働していないと判定された場合は、サービスに対応する通知先に対して機能が稼働していない旨を通知する。例えば、通知部４４は、判定部４１により機能が稼働していないと判定された場合は、当該機能を利用するサービスに対応する通知先に対して、当該機能が稼働していない旨を通知する。具体的な例を挙げると、通知部４４は、サーバ１００の管理者に対して機能が稼働していない旨を通知する。

また、通知部４４は、所定のサーバの管理者に対し、機能が稼働していない旨を通知してもよい。例えば、図１の例において、通知部４４は、サービスサーバ２００を管理する管理者が利用する管理者端末３００に対し、機能が稼働していない旨を通知する。

また、通知部４４は、機能を利用するサービスの提供者に対し、当該機能が稼働していない旨を通知してもよい。例えば、図１の例において、通知部４４は、稼働していないと判定された機能を利用するサービスの提供者（管理者）の管理者端末３００に対し、当該機能が稼働していない旨を通知する。

また、通知部４４は、判定部４１により機能群が稼働していないと判定された場合は、サービスに対応する通知先に対して機能群が稼働していない旨を通知してもよい。例えば、図１の例において、ＡＰＩ群＃１に対応する機能群のいずれかが稼働していないと判定された場合、通知部４４は、管理者端末３００−１に対し、サービスサーバ２００−１が利用する機能が稼働していない旨を通知する。

また、通知部４４は、複数のサービスのうち、判定部４１により機能が稼働していないと判定されたサービスに対応する通知先に対して機能が稼働していない旨を通知してもよい。例えば、図１の例において、ＡＰＩ群＃１に対応する機能群のいずれかが稼働していないと判定された一方で、ＡＰＩ群＃２及び＃３に対応する機能群が稼働していると判定された場合、通知部４４は、管理者端末３００−１に対し、サービスサーバ２００−１が利用する機能が稼働していない旨を通知する。

また、通知部４４は、判定部４１により稼働していないと判定された機能を利用するサービスに対応する通知先に対して当該機能が稼働しないタイミングを通知してもよい。例えば、通知部４４は、推定部４３による推定結果を、対応する通知先に通知する。

〔３．通知処理のフロー〕
次に、図５を用いて、実施形態に係る情報処理装置１０の通知処理の手順について説明する。図５は、実施形態に係る通知処理の手順の一例を示すフローチャートである。

図５に示すように、情報処理装置１０は、所定のサーバにより提供される各機能に関する情報を収集する（ステップＳ１０１）。続いて、情報処理装置１０は、サーバ１００の機能が稼働するか否かを判定する所定のタイミングであるか判定する（ステップＳ１０２）。所定のタイミングでない場合（ステップＳ１０３；Ｎｏ）、情報処理装置１０は、所定のタイミングとなるまで待機する。

一方、所定のタイミングである場合（ステップＳ１０２；Ｙｅｓ）、情報処理装置１０は、所定のサービスにおいて利用されるサーバ１００の機能が稼働するか否かを判定する（ステップＳ１０３）。稼働すると判定した場合（ステップＳ１０３；Ｙｅｓ）、情報処理装置１０は、処理を終了する。

一方、稼働しないと判定した場合（ステップＳ１０３；Ｎｏ）、情報処理装置１０は、所定のサービスに対応する通知先に対して機能が稼働していない旨を通知し（ステップＳ１０４）、処理を終了する。

〔４．変形例〕
上述の実施形態は一例を示したものであり、種々の変更及び応用が可能である。

〔４−１．機能が稼働するか否かの判定について〕
上述の実施形態において、判定部４１が、ＡＰＩ群を介したサービスサーバ２００からサーバ１００へのアクセスを実行することにより、機能が稼働するか否かを判定する例を示したが、判定部４１の機能はこのような例に限定されない。例えば、判定部４１は、ヘルスチェックやウェブフックなどを利用してサーバ１００が提供する機能が稼働する否かを判定してもよい。

〔４−２．通知部４４による処理について〕
上述の実施形態において、通知部４４が、所定の通知先に対して機能が稼働していない旨を通知する処理や、機能の稼働状況を示すコンテンツを管理者端末３００に提供する処理を実行する例を示したが、通知部４４の機能はこのような例に限定されず、任意の態様で機能の稼働に関する情報を通知してもよい。例えば、通知部４４は、Ｓｌａｃｋ（登録商標）等の各種チームコミュニケーションツールや、ＳＮＳ、掲示板、メールやショートメッセージサービス等の各種プラットフォームを介して通知を行ってよい。

なお、チームコミュニケーションツールにおいて通知を行う場合、通知部４４は、稼働していない機能と対応するチームや所定の人物に対して通知してもよく、稼働していない機能と対応するサービスと対応するチームや所定の人物に対して通知してもよい。ここで、通知部４４が通知を行うチームとは、サーバ１００を管理する組織に属する人物により構成されるチーム、サービスサーバ２００を管理する組織に属する人物により構成されるチーム、サーバ１００やサービスサーバ２００により提供されるサービスを利用する一般利用者により構成されるチームなどであってもよい。また、通知部４４が通知を行う所定の人物とは、サーバ１００を管理する管理者、サービスサーバ２００を管理する管理者、一般利用者であってもよい。

〔４−３．処理態様について〕
上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、逆に、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

また、上記してきた各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

〔５．効果〕
上述してきたように、実施形態に係る情報処理装置１０は、判定部４１と、学習部４２と、推定部４３と、通知部４４とを有する。判定部４１は、サービスの提供者により管理されるサーバとは異なる所定のサーバにより提供される機能であって、当該サービスにおいて利用される機能が稼働するか否かを判定する。学習部４２は、判定部４１により稼働していないと判定された機能と、当該機能が稼働しなかった日時とをモデルに学習させる。推定部４３は、学習部４２により学習されたモデルに基づいて、判定部４１により稼働していないと判定された機能が稼働しないタイミングを推定する。通知部４４は、判定部４１により機能が稼働していないと判定された場合は、サービスに対応する通知先に対して機能が稼働していない旨を通知する。また、通知部４４は、判定部４１により稼働していないと判定された機能を利用するサービスに対応する通知先に対して当該機能が稼働しないタイミングを通知する。

これにより、実施形態に係る情報処理装置１０は、サーバ１００によって複数の機能が他の各種サービスに提供されるといった態様であっても、いずれのサービスに提供している機能に障害が発生したかを判定することができるため、所定のサービスが提供する機能を利用する他のサービスが適切に提供されているかを適切に判定できる。また、実施形態に係る情報処理装置１０は、機能が稼働しないタイミングを推定し、あらかじめ対応する通知先に通知することができるため、利便性を向上させることができる。

また、実施形態に係る情報処理装置１０において、例えば、通知部４４は、所定のサーバの管理者に対し、機能が稼働していない旨を通知する。また、通知部４４は、機能を利用するサービスの提供者に対し、当該機能が稼働していない旨を通知する。

これにより、実施形態に係る情報処理装置１０は、機能に障害が発生した場合には適切な通知先に機能が稼働していない旨を通知できるため、利便性を向上させることができる。

また、実施形態に係る情報処理装置１０において、例えば、判定部４１は、所定のサーバにより提供される機能のうち、サービスが利用する機能群が稼働するか否かを判定する。そして、通知部４４は、判定部４１により機能群が稼働していないと判定された場合は、サービスに対応する通知先に対して機能群が稼働していない旨を通知する。

これにより、実施形態に係る情報処理装置１０は、所定のサービスにおいて利用される機能群に障害が発生した場合には、当該サービスに対応する通知先に機能群が稼働していない旨を通知できるため、利便性を向上させることができる。

また、実施形態に係る情報処理装置１０において、例えば、判定部４１は、所定のサーバにより提供される機能が複数のサービスにおいて利用される場合は、サービスごとに当該サービスにおいて利用される機能が稼働するか否かを判定する。そして、通知部４４は、複数のサービスのうち、判定部４１により機能が稼働していないと判定されたサービスに対応する通知先に対して機能が稼働していない旨を通知する。

これにより、実施形態に係る情報処理装置１０は、障害が発生したサービスを特定して対応する通知先に機能が稼働していない旨を通知できるため、利便性を向上させることができる。

また、実施形態に係る情報処理装置１０において、例えば、判定部４１は、ＡＰＩを介して所定のサーバにより提供される機能が稼働するか否かを判定する。

これにより、実施形態に係る情報処理装置１０は、ＡＰＩを介した機能が正常に稼働するか否か判定できるため、利便性を向上させることができる。

〔６．ハードウェア構成〕
また、上述してきた各実施形態に係る情報処理装置１０は、例えば、図６に示すような構成のコンピュータ１０００によって実現される。以下、情報処理装置１０を例に挙げて説明する。図６は、情報処理装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＯＭ１２００、ＲＡＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。

ＣＰＵ１１００は、ＲＯＭ１２００又はＨＤＤ１４００に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１２００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を格納する。

ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を記憶する。通信インターフェイス１５００は、通信網５００（実施形態のネットワークＮに対応する）を介して他の機器からデータを受信してＣＰＵ１１００へ送り、また、通信網５００を介してＣＰＵ１１００が生成したデータを他の機器へ送信する。

ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、入出力インターフェイス１６００を介して生成したデータを出力装置へ出力する。

メディアインターフェイス１７００は、記録媒体１８００に格納されたプログラム又はデータを読み取り、ＲＡＭ１３００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１３００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

例えば、コンピュータ１０００が情報処理装置１０として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１３００上にロードされたプログラムを実行することにより、制御部４０の機能を実現する。また、ＨＤＤ１４００には、情報処理装置１０の記憶装置内の各データが格納される。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを記録媒体１８００から読み取って実行するが、他の例として、他の装置から所定の通信網を介してこれらのプログラムを取得してもよい。

〔７．その他〕
以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。

また、上述した情報処理装置１０は、機能によっては外部のプラットフォーム等をＡＰＩ（Application Programming Interface）やネットワークコンピューティングなどで呼び出して実現するなど、構成は柔軟に変更できる。

また、特許請求の範囲に記載した「部」は、「手段」や「回路」などに読み替えることができる。例えば、受付部は、受付手段や受付回路に読み替えることができる。

１０ 情報処理装置
２０ 通信部
３０ 記憶部
３１ 稼働状況データベース
３２ モデルデータベース
４０ 制御部
４１ 判定部
４２ 学習部
４３ 推定部
４４ 通知部
１００ サーバ
２００ サービスサーバ
３００ 管理者端末

Claims (8)

1. サービスの提供者により管理されるサーバとは異なる所定のサーバにより提供される機能であって、当該サービスにおいて利用される機能が稼働するか否かを判定する判定部と、
   前記判定部により前記機能が稼働していないと判定された場合は、前記サービスに対応する通知先に対して前記機能が稼働していない旨を通知する通知部と
   を有し、
   前記判定部は、
   前記所定のサーバにより提供される機能が複数のサービスにおいて利用される場合は、サービスごとに当該サービスにおいて利用される機能が稼働するか否かを判定し、
   前記通知部は、
   前記複数のサービスのうち、前記判定部により機能が稼働していないと判定されたサービスに対応する通知先に対して機能が稼働していない旨を通知する
   ことを特徴とする通知装置。
2. 前記通知部は、
   前記所定のサーバの管理者に対し、前記機能が稼働していない旨を通知する
   ことを特徴とする請求項１に記載の通知装置。
3. 前記通知部は、
   前記機能を利用するサービスの提供者に対し、当該機能が稼働していない旨を通知する
   ことを特徴とする請求項１または２に記載の通知装置。
4. 前記判定部は、
   前記所定のサーバにより提供される機能のうち、前記サービスが利用する機能群が稼働するか否かを判定し、
   前記通知部は、
   前記判定部により前記機能群が稼働していないと判定された場合は、前記サービスに対応する通知先に対して前記機能群が稼働していない旨を通知する
   ことを特徴とする請求項１から３のうちいずれか１つに記載の通知装置。
5. 前記判定部は、
   ＡＰＩ（Application Programming Interface）を介して前記所定のサーバにより提供される機能が稼働するか否かを判定する
   ことを特徴とする請求項１から４のうちいずれか１つに記載の通知装置。
6. 前記判定部により稼働していないと判定された機能と、当該機能が稼働しなかった日時とをモデルに学習させる学習部と
   前記学習部により学習されたモデルに基づいて、前記判定部により稼働していないと判定された機能が稼働しないタイミングを推定する推定部と
   を有し、
   前記通知部は、
   前記判定部により稼働していないと判定された機能を利用するサービスに対応する通知先に対して当該機能が稼働しないタイミングを通知する
   ことを特徴とする請求項１から５のうちいずれか１つに記載の通知装置。
7. コンピュータが実行する通知方法であって、
   サービスの提供者により管理されるサーバとは異なる所定のサーバにより提供される機能であって、当該サービスにおいて利用される機能が稼働するか否かを判定する判定工程と、
   前記判定工程により前記機能が稼働していないと判定された場合は、前記サービスに対応する通知先に対して前記機能が稼働していない旨を通知する通知工程と
   を含み、
   前記判定工程は、
   前記所定のサーバにより提供される機能が複数のサービスにおいて利用される場合は、サービスごとに当該サービスにおいて利用される機能が稼働するか否かを判定し、
   前記通知工程は、
   前記複数のサービスのうち、前記判定工程により機能が稼働していないと判定されたサービスに対応する通知先に対して機能が稼働していない旨を通知する
   ことを特徴とする通知方法。
8. サービスの提供者により管理されるサーバとは異なる所定のサーバにより提供される機能であって、当該サービスにおいて利用される機能が稼働するか否かを判定する判定手順と、
   前記判定手順により前記機能が稼働していないと判定された場合は、前記サービスに対応する通知先に対して前記機能が稼働していない旨を通知する通知手順と
   をコンピュータに実行させ、
   前記判定手順は、
   前記所定のサーバにより提供される機能が複数のサービスにおいて利用される場合は、サービスごとに当該サービスにおいて利用される機能が稼働するか否かを判定し、
   前記通知手順は、
   前記複数のサービスのうち、前記判定手順により機能が稼働していないと判定されたサービスに対応する通知先に対して機能が稼働していない旨を通知する
   ことを特徴とする通知プログラム。

Images