JP2014048973A - 情報処理システム、情報処理方法およびプログラム - Google Patents

Abstract

【課題】障害対応管理者の負担を軽減可能な情報処理システム、情報処理方法およびプログラムを提供する。
【解決手段】本発明の情報処理システムは、情報処理装置による処理の実行中に発生した障害に関するメッセージを通知する情報処理システムであって、検出部と、判断部と、を備える。検出部は、障害を検出する。判断部は、検出部で検出された障害を示す障害情報を用いて、検出部で検出された障害が、ユーザー操作に起因して発生したのか情報処理装置に起因して発生したのかを判断する。
【選択図】図２

Description

本発明は、情報処理システム、情報処理方法およびプログラムに関する。

従来、システムにおける障害を監視し通知する技術が知られている。例えば特許文献１には、画像形成装置における障害を監視し通知する技術が開示されている。

しかしながら、特許文献１に開示された技術では、ユーザー操作に起因して障害が発生したのかシステム側の不具合に起因して障害が発生したのかを切り分けて検出していない。このため、障害発生の通知を受けた障害対応管理者は、ユーザー操作に起因して障害が発生したのかシステムに起因して障害が発生したのかを調査した上で、発生した障害の対応が可能な担当者を特定し、特定した担当者に対して、障害の対応を依頼する。これにより、障害対応管理者の負担が増大するという問題がある。

本発明は、上記に鑑みてなされたものであって、障害対応管理者の負担を軽減可能な情報処理システム、情報処理方法およびプログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、情報処理装置による処理の実行中に発生した障害に関するメッセージを通知する情報処理システムであって、前記障害を検出する検出部と、前記検出部で検出された前記障害を示す障害情報を用いて、前記検出部で検出された前記障害が、ユーザー操作に起因して発生したのか前記情報処理装置に起因して発生したのかを判断する判断部と、を備える。

本発明は、情報処理装置による処理の実行中に発生した障害に関するメッセージを通知する情報処理システムによる情報処理方法であって、前記障害を検出する検出ステップと、前記検出ステップで検出された前記障害を示す障害情報を用いて、前記検出ステップで検出された前記障害が、ユーザー操作に起因して発生したのか前記情報処理装置に起因して発生したのかを判断する判断ステップと、を含む。

本発明は、情報処理装置による処理の実行中に発生した障害に関するメッセージを通知する情報処理システムが有するコンピュータに、前記障害を検出する検出ステップと、前記検出ステップで検出された前記障害を示す障害情報を用いて、前記検出ステップで検出された前記障害が、ユーザー操作に起因して発生したのか前記情報処理装置に起因して発生したのかを判断する判断ステップと、を実行させるためのプログラムである。

本発明によれば、障害対応を管理する障害対応管理者の負担を軽減することができる。

図１は、実施形態の情報処理システムの概略構成例を示すブロック図である。 図２は、第１サーバ装置の機能構成例を示すブロック図である。 図３は、障害内容情報の一例を示す図である。 図４は、エラーメッセージの一例を示す図である。 図５は、第２サーバ装置の機能構成例を示すブロック図である。 図６は、メッセージの一例を示す図である。 図７は、従来の情報処理システムによる処理手順の一例を示すシーケンス図である。 図８は、実施形態の情報処理システムによる処理手順の一例を示すシーケンス図である。

以下、添付図面を参照しながら、本発明に係る情報処理システム、情報処理方法およびプログラムの実施形態を詳細に説明する。

図１は、本実施形態の情報処理システム１の概略構成例を示すブロック図である。図１に示すように、情報処理システム１は、互いに接続可能な第１サーバ装置１００、第２サーバ装置２００、および、複数の端末装置３００を備える。図１の例では、第１サーバ装置１００、第２サーバ装置２００、および、複数の端末装置３００の各々は、ネットワーク４００を介して接続されているが、この形態に限られるものではない。

第１サーバ装置１００は、バッチ処理などの処理を実行する。バッチ処理の方式は任意であり、例えば一定期間（もしくは一定量)に渡って処理対象となるデータを集め、処理を実行するタイミングに到達するたびに一括処理を行う処理方式であってもよいし、予め登録された一連の手順に従って、自動的に連続処理を行う処理方式であってもよい。第１サーバ装置１００の具体的な内容については後述する。この例では、第１サーバ装置１００は、請求項の「情報処理装置」に対応している。

第２サーバ装置２００は、第１サーバ装置１００による処理の実行中に発生した障害に関するメッセージを端末装置３００へ通知する。第２サーバ装置２００の具体的な内容については後述する。端末装置３００は、情報処理システム１のユーザーが使用するクライアント端末であり、パーソナルコンピュータ（ＰＣ：Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）などで実現される。端末装置３００は、ネットワーク４００を介して、第１サーバ装置１００または第２サーバ装置２００が提供するＵＩ画面（Ｗｅｂページなど）を閲覧することもできるし、操作デバイスを介して各種の操作入力を行い、その操作入力に対する応答結果を得ることもできる。つまり、端末装置３００は、当該端末装置３００を使用するユーザーに対して、ユーザーインタフェース機能を提供することが可能な装置である。

次に、第１サーバ装置１００の具体的な内容を説明する。図２は、第１サーバ装置１００が有する機能の一例を示す機能ブロック図である。図２に示すように、第１サーバ装置１００は、処理部１１０と、検出部１２０と、記憶部１３０と、判断部１４０と、メッセージテーブル１５０と、送信部１６０と、未処理化部１７０とを有する。本実施形態では、第１サーバ装置１００には、ＣＰＵ、ＲＯＭ、ＲＡＭ等を備えたコンピュータが搭載され、ＣＰＵがＲＯＭ等に格納されたプログラムをＲＡＭ上に展開して実行することにより、上述の各機能（処理部１１０、検出部１２０、判断部１４０、送信部１６０、未処理化部１７０）が実現される。なお、これに限らず、例えば上述の各機能（処理部１１０、検出部１２０、判断部１４０、送信部１６０、未処理化部１７０）のうちの少なくとも一部が、記憶部１３０およびメッセージテーブル１５０と同様に、専用のハードウェア回路で実現される形態であってもよい。

処理部１１０は、各種のバッチ処理を実行する。検出部１２０は、処理部１１０によるバッチ処理の実行中に発生した障害を検出し、検出した障害の内容を示す障害内容情報を生成する。検出部１２０は、生成した障害内容情報を判断部１４０へ渡す。

図３は、検出部１２０により生成された障害内容情報の一例を示す図である。ここでは、「出荷実績取込」のバッチ処理中に発生した障害の内容を示す障害内容情報が例示されている。図３の例では、障害内容情報には、配布リスト名（バッチ処理の種類）を示す情報「出荷実績取込」と、障害の発生日時を示す情報「2011年10月21日 19時41分45秒」と、カンパニーの種別を示す情報「TMC」と、アラーム種別（障害の種別）を示す情報「在庫不足」と、受注番号を示す情報「854747-3.1」と、出荷品目を示す情報「581622」と、出荷ロットを示す情報「1515402X-0」と、出荷数量を示す情報「１」と、第１サーバ装置１００上で管理される在庫を示す情報「０」と、出荷指示を識別する情報「0000000001 21 51 41」と、が含まれる。なお、この例では、アラーム種別を示す情報が、請求項の「障害情報」に対応する。

再び図２に戻って説明を続ける。記憶部１３０は、複数の障害情報ごとに、ユーザー操作に起因して障害が発生したのか第１サーバ装置１００に起因して（例えば第１サーバ装置１００で実行されるプログラム上のバグ等に起因して）障害が発生したのかを判断する際に用いられる判断情報を対応付けて記憶する。本実施形態では、記憶部１３０は、複数のアラーム種別を示す情報ごとに、障害の原因を示すエラーメッセージを対応付けて記憶する。この例では、エラーメッセージが、請求項の「判断情報」に対応する。

図４は、図３に例示されたアラーム種別を示す情報「在庫不足」に対応するエラーメッセージを示す図である。図４に例示されたエラーメッセージは、対応する障害情報「在庫不足」の原因を示し、後述の判断部１４０による判断処理において利用される。

再び図２に戻って説明を続ける。判断部１４０は、検出部１２０で検出された障害を示す障害情報を用いて、検出部１２０で検出された障害が、ユーザー操作に起因して発生したのか第１サーバ装置１００に起因して（第１サーバ装置１００側の不具合に起因して）発生したのかを判断する。より具体的には、判断部１４０は、検出部１２０で検出された障害を示す障害情報に対応する判断情報を特定し、特定した判断情報を用いて、検出部１２０で検出された障害が、ユーザー操作に起因して発生したのか第１サーバ装置１００に起因して発生したのかを判断する。

さらに詳述すれば以下のとおりである。判断部１４０は、検出部１２０で生成された障害内容情報から障害情報（アラーム種別を示す情報）を抽出し、記憶部１３０に記憶されたエラーメッセージのうち、その抽出した障害情報に対応するエラーメッセージを特定する。判断部１４０は、特定したエラーメッセージを用いて、検出部１２０で検出された障害が、ユーザー操作に起因して発生したのか第１サーバ装置１００に起因して発生したのかを判断する。

本実施形態では、各エラーメッセージが、ユーザー操作に起因して障害が発生したことを示すのか、第１サーバ装置１００に起因して障害が発生したことを示すのかは、過去に発生した障害内容とその原因を示す障害履歴情報の蓄積に基づき、判断部１４０による判断処理時に実行されるプログラム（ＣＰＵが実行するプログラム）上で予め定められている。つまり、判断部１４０は、予め定められた規則に従って、特定したエラーメッセージが、ユーザー操作に起因して障害が発生したことを示すエラーメッセージであるのか、第１サーバ装置１００に起因して障害が発生したことを示すエラーメッセージであるのかを判断する。

そして、判断部１４０は、特定したエラーメッセージと、ユーザー操作に起因して障害が発生したのか第１サーバ装置１００に起因して障害が発生したのかを示す判断結果情報（判断結果を示す情報）とを対応付けたエラー情報をメッセージテーブル１５０に保存する。送信部１６０は、メッセージテーブル１５０に保存されたエラー情報を、第２サーバ装置２００へ送信する。

未処理化部１７０は、処理部１１０によるバッチ処理の対象となるデータ（図３の例では取り込むべき出荷実績データ）のうち処理の実行中に障害が検出されたデータについては、次回のバッチ処理の対象となるように設定してスキップ（次のデータの処理へ移行）する。例えば未処理化部１７０は、バッチ処理の実行中に障害が検出されたデータについては、当該データに対して、未処理のデータであることを示す未処理フラグ情報を設定してスキップすることもできる。これにより、障害の原因が解消されない限り、未処理の状態が継続する。以上が、第１サーバ装置１００の具体的な内容である。

次に、第２サーバ装置２００の具体的な内容を説明する。図５は、第２サーバ装置２００が有する機能の一例を示すブロック図である。図５に示すように、第２サーバ装置２００は、受信部２１０と、生成部２２０と、特定部２３０と、通知部２４０とを有する。本実施形態では、第２サーバ装置２００には、ＣＰＵ、ＲＯＭ、ＲＡＭ等を備えたコンピュータが搭載され、ＣＰＵがＲＯＭ等に格納されたプログラムをＲＡＭ上に展開して実行することにより、上述の各機能（受信部２１０、生成部２２０、特定部２３０、通知部２４０）が実現される。なお、これに限らず、例えば上述の各機能（受信部２１０、生成部２２０、特定部２３０、通知部２４０）のうちの少なくとも一部が、専用のハードウェア回路で実現される形態であってもよい。

受信部２１０は、第１サーバ装置１００（送信部１６０）からのエラー情報を受信する。生成部２２０は、受信したエラー情報に含まれるエラーメッセージに対して、障害を解消するための手順を示すリカバリー手順（手順情報）を付加したメッセージを生成する。図６は、生成部２２０により生成されたメッセージの一例を示す図である。

特定部２３０は、判断部１４０による判断結果から、検出部１２０で検出された障害の対応が可能なユーザーを特定する。より具体的には、特定部２３０は、受信部２１０で受信したエラー情報に含まれる判断結果情報が、ユーザー操作に起因して障害が発生したことを示す場合は、ユーザー操作に起因して発生した障害を解決／修正することができるユーザー（例えば当該操作を行ったユーザー）を特定することができる。一方、判断結果情報が、第１サーバ装置１００に起因して障害が発生したことを示す場合は、特定部２３０は、第１サーバ装置１００側の不具合を解決／修正することができるユーザー（例えばシステム担当者）を特定することができる。

通知部２４０は、生成部２２０により生成されたメッセージを、特定部２３０により特定されたユーザーへ通知する。以上が、第２サーバ装置２００の具体的な内容である。

ここで、従来の情報処理システムの動作例を説明する。図７は、従来の情報処理システムによる処理手順の一例を示すシーケンス図である。従来の情報処理システムは、第１サーバ装置、障害管理システム、および、複数の端末装置が、ネットワークを介して互いに接続されている。図７の例では、バッチ処理「出荷実績取込」の実行中に、図３に例示された内容の障害が発生した場合の処理手順を示している。

まず、第１サーバ装置は、発生した障害の内容を示す障害内容情報を、障害監視システムへ通知する（ステップＳ１）。障害内容情報の通知を受けた障害監視システムは、その障害内容情報が記載されたメール（障害メール）を、障害対応を管理する障害対応管理者の端末へ送信する（ステップＳ２）。障害対応管理者は、障害メールの受信を確認すると、障害メールに記載された障害内容情報を、障害管理データベース（障害管理ＤＢ）に登録する作業を行う（ステップＳ３）。

次に、障害対応管理者は、障害管理ＤＢに登録された障害履歴情報を参照しながら障害の原因を調査し（ステップＳ４）、ユーザー操作に起因して障害が発生したのか、第１サーバ装置に起因して障害が発生したのかを切り分ける（ステップＳ５）。そして、障害の原因を示す情報（ユーザー操作に起因して障害が発生したのか第１サーバ装置に起因して障害が発生したのかを示す情報も含む）を、障害管理ＤＢに登録する。障害管理ＤＢには、障害の内容を示す障害内容情報と、障害の原因を示す情報とが対応付けられた障害履歴情報が蓄積される。

次に、障害対応管理者は、発生した障害の対応が可能なユーザーを特定し（ステップＳ６）、特定したユーザーの端末装置のアドレスを指定して、発生した障害の対応を依頼する対応依頼メールを送信する（ステップＳ７）。対応依頼メールが送信された端末装置のユーザーは、対応依頼メールの受信を確認すると、発生した障害を解決／修正する作業を行う（ステップＳ８）。図３に例示された障害では、ユーザーの誤操作により在庫数が「０」になっているため、障害対応を行うユーザー（例えば誤操作を行ったユーザー）は、在庫数が「１」以上となるようにデータの修正作業を行う。また、障害対応管理者は、再発防止の徹底を依頼するメール（再発防止徹底依頼メール）を、各ユーザーの端末装置へ送信する（ステップＳ９）。

図７の例では、現在発生している障害が、ユーザー操作に起因して発生しているのか、第１サーバ装置に起因して発生しているのかについて、障害対応管理者が障害内容を確認して切り分けを行っているので、障害対応管理者の負担が増大するという問題がある。特に、ユーザー操作に起因して発生する障害については、システムで再発防止を施すことができないので、発生の都度、障害対応管理者は、上述のステップＳ３〜Ｓ７の作業を行う必要があるので、障害対応管理者の負担が大きなものとなる。さらに、ユーザーは、障害対応管理者からの対応依頼メールを受けて対応するために受動的であり、再発防止策を提示しても徹底できないという問題がある。

図８は、本実施形態の情報処理システム１による処理手順の一例を示すシーケンス図である。図８の例では、バッチ処理「出荷実績取込」の実行中に、図３に例示された内容の障害が発生した場合の処理手順を示している。

まず、検出部１２０は、発生した障害を検出し、検出した障害の内容を示す障害内容情報を生成する。そして、生成した障害内容情報を判断部１４０へ渡す（ステップＳ１１）。判断部１４０は、検出部１２０から渡された障害内容情報に含まれる障害情報を用いて、検出部１２０で検出された障害が、ユーザー操作に起因して発生したのか第１サーバ装置１００に起因して発生したのかを判断する判断処理を行う（ステップＳ１２）。具体的には、判断部１４０は、検出部１２０から渡された障害内容情報から障害情報を抽出し、記憶部１３０に記憶されたエラーメッセージのうち、その抽出した障害情報に対応するエラーメッセージを特定する。判断部１４０は、特定したエラーメッセージを用いて、検出部１２０で検出された障害が、ユーザー操作に起因して発生したのか第１サーバ装置１００に起因して発生したのかを判断する。この例では、判断部１４０は、障害情報「在庫不足」に対応するエラーメッセージとして図４のエラーメッセージを特定し、その特定したエラーメッセージを参照することで、発生した障害がユーザー操作に起因して発生したと判断することができる。

そして、判断部１４０は、特定したエラーメッセージと、ユーザー操作に起因して障害が発生したのか第１サーバ装置１００に起因して障害が発生したのかを示す判断結果情報とを対応付けたエラー情報をメッセージテーブル１５０に保存する（ステップＳ１３）。次に、送信部１６０は、メッセージテーブル１５０に保存されたエラー情報を、第２サーバ装置２００へ送信する（ステップＳ１４）。

第２サーバ装置２００の受信部２１０は、第１サーバ装置１００（送信部１６０）からのエラー情報を受信する（ステップＳ１５）。生成部２２０は、受信したエラー情報に含まれるエラーメッセージに対して、障害を解消するための手順を示すリカバリー手順を付加した図６のようなメッセージを生成する（ステップＳ１６）。次に、特定部２３０は、発生した障害の対応が可能なユーザーを特定する（ステップＳ１７）。この例では、受信部２１０で受信したエラー情報に含まれる判断結果情報は、ユーザー操作に起因して障害が発生したことを示すので、特定部２３０は、ユーザー操作に起因して発生した障害を解決／修正することができるユーザーを特定する。

通知部２４０は、生成部２２０により生成されたメッセージを、特定部２３０により特定されたユーザーの端末装置３００へ送信する（ステップＳ１８）。メッセージが送信された端末装置３００のユーザーは、メッセージの受信を確認すると、当該メッセージに含まれるリカバリー手順を参照しながら、発生した障害を解決／修正する作業を行う（ステップＳ１９）。

また、第１サーバ装置１００の未処理化部１７０は、バッチ処理である出荷実績取込処理の対象となる出荷実績データのうち障害が検出されたデータ（「該当処理データ」）については、次回の出荷実績取込処理の対象となるように設定してスキップする（ステップＳ２０）。

以上に説明したように、図８の例では、現在発生している障害が、ユーザー操作に起因して発生しているのか、第１サーバ装置１００に起因して発生しているのかを判断する判断処理が、第１サーバ装置１００（判断部１４０）により自動的に行われるので、図７の例に比べて、障害対応管理者の負担を大幅に軽減できる。

また、図８の例では、現在発生している障害の対応が可能なユーザーの端末装置３００に対して、その障害を解消するための手順を示すリカバリー手順をエラーメッセージに付加したメッセージを送信するので、そのメッセージを受信したユーザーは、対応すべき内容を直ちに把握することができ、対応ミスを減らすことができる。さらに、図８の例では、障害が発生した場合、該当処理データについては、次回の出荷実績取込処理の対象となるように設定（例えば上述の未処理フラグ情報を設定）してスキップするので、障害対応が完了しない限り、同様の障害が検出される。これにより、発生した障害の対応漏れを防止できるので、運用品質を向上させることができる。

以上、本発明に係る実施形態について説明したが、本発明は上述の実施形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内で種々の変形が可能である。

（変形例１）
例えば、現在発生している障害が、ユーザー操作に起因して発生しているのか、第１サーバ装置１００に起因して発生しているのかを判断する機能が、第１サーバ装置１００側ではなくて第２サーバ装置２００側に搭載される形態であってもよい。この場合、例えば第１サーバ装置１００には、上述の処理部１１０、検出部１２０、送信部１６０、未処理化部１７０が搭載され、第２サーバ装置２００には、上述の記憶部１３０、判断部１４０、メッセージテーブル１５０、受信部２１０、生成部２２０、特定部２３０、通知部２４０が搭載される形態であってもよい。

この形態においては、第１サーバ装置１００の送信部１６０は、検出部１２０で生成された障害内容情報を第２サーバ装置２００へ送信し、第２サーバ装置２００の受信部２１０は、第１サーバ装置１００からの障害内容情報を受信する。また、判断部１４０は、受信部２１０で受信した障害内容情報から障害情報を抽出し、記憶部１３０に記憶されたエラーメッセージのうち、その抽出した障害情報に対応するエラーメッセージを特定する。判断部１４０は、特定したエラーメッセージを用いて、上述の判断処理を行う。そして、判断部１４０は、特定したエラーメッセージと、ユーザー操作に起因して障害が発生したのか第１サーバ装置１００に起因して障害が発生したのかを示す判断結果情報とを対応付けたエラー情報をメッセージテーブル１５０に保存する。

生成部２２０は、メッセージテーブル１５０に保存されたエラー情報に含まれるエラーメッセージに対してリカバリー手順を付加したメッセージを生成する。特定部２３０は、メッセージテーブル１５０に保存されたエラー情報に含まれる判断結果情報が、ユーザー操作に起因して障害が発生したことを示す場合は、当該障害を解決／修正することができるユーザー（例えば当該操作を行ったユーザー）を特定し、判断結果情報が、第１サーバ装置１００に起因して障害が発生したことを示す場合は、第１サーバ装置１００側の不具合を解決／修正することができるユーザー（例えばシステム担当者）を特定する。通知部２４０は、生成部２２０により生成されたメッセージを、特定部２３０により特定されたユーザーの端末装置３００へ通知する。

また、以上の形態においては、メッセージテーブル１５０が設けられない構成であってもよい。この場合、例えば判断部１４０は、特定したエラーメッセージを生成部２２０へ渡し、判断結果情報を特定部２３０へ渡すこともできる。生成部２２０は、判断部１４０から渡されたエラーメッセージを解析し、そのエラーメッセージに対してリカバリー手順を付加したメッセージを生成することができる。特定部２３０は、判断部１４０から渡された判断結果情報が、ユーザー操作に起因して障害が発生したことを示す場合は、ユーザー操作に起因して発生した障害を解決／修正することができるユーザーを特定する一方、判断部１４０から渡された判断結果情報が、第１サーバ装置１００に起因して障害が発生したことを示す場合は、第１サーバ装置１００側の不具合を解決／修正することができるユーザーを特定することができる。

つまり、上述の検出部１２０、および、上述の判断部１４０は、第１サーバ装置１００と第２サーバ装置２００に分散されて搭載される形態であってもよい。要するに、本発明に係る情報処理システムは、情報処理装置による処理の実行中に発生した障害に関するメッセージを通知する情報処理システムであって、障害を検出する検出部と、検出部で検出された障害を示す障害情報を用いて、検出部で検出された障害が、ユーザー操作に起因して発生したのか情報処理装置に起因して発生したのかを判断する判断部と、を備える形態であればよい。

（変形例２）
上述の実施形態では、過去に発生した障害内容とその原因を示す障害履歴情報の蓄積に基づき、各エラーメッセージが、ユーザー操作に起因して障害が発生したことを示すのか、第１サーバ装置１００に起因して障害が発生したことを示すのかを、判断部１４０による判断処理時に実行されるプログラム（ＣＰＵが実行するプログラム）上で予め定めているが、これに限られるものではない。例えば各障害情報が、ユーザー操作に起因して障害が発生したことを示すのか、第１サーバ装置１００に起因して障害が発生したことを示すのかを、判断部１４０による判断処理時に実行されるプログラム上で予め定めておく形態であってもよい。この形態においては、判断部１４０は、検出部１２０で検出された障害を示す障害情報から、検出部１２０で検出された障害が、ユーザー操作に起因して発生したのか第１サーバ装置１００に起因して発生したのかを直接判断することができるので、上述の実施形態のように記憶部１３０にアクセスする必要が無い。

要するに、本発明の判断部は、検出部で検出された障害の種別を示す障害情報を用いて、検出部で検出された障害が、ユーザー操作に起因して発生したのか情報処理装置（例えば第１サーバ装置１００）に起因して発生したのかを判断する機能を有するものであればよい。

（変形例３）
上述の実施形態では、判断情報としてエラーメッセージが採用されているが、これに限られるものではない。例えば、ユーザー操作に起因して障害が発生したことを示すのか、第１サーバ装置１００に起因して障害が発生したことを示すのかを、判断処理時に実行されるプログラム上で識別可能な情報（例えばフラグ情報等）を、判断情報として採用する形態であってもよい。

以上の実施形態および各変形例は任意に組み合わせることもできる。

なお、上述の第１サーバ装置１００および第２サーバ装置２００の各々で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成してもよい。

さらに、上述の第１サーバ装置１００および第２サーバ装置２００の各々で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、上述の第１サーバ装置１００および第２サーバ装置２００の各々で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。

１ 情報処理システム
１００ 第１サーバ装置
１１０ 処理部
１２０ 検出部
１３０ 記憶部
１４０ 判断部
１５０ メッセージテーブル
１６０ 送信部
１７０ 未処理化部
２００ 第２サーバ装置
２１０ 受信部
２２０ 生成部
２３０ 特定部
２４０ 通知部
３００ 端末装置
４００ ネットワーク

特開２００４−１３０７９０号公報

Claims (6)

1. 情報処理装置による処理の実行中に発生した障害に関するメッセージを通知する情報処理システムであって、
   前記障害を検出する検出部と、
   前記検出部で検出された前記障害を示す障害情報を用いて、前記検出部で検出された前記障害が、ユーザー操作に起因して発生したのか前記情報処理装置に起因して発生したのかを判断する判断部と、を備える、
   情報処理システム。
2. 複数の前記障害情報ごとに、ユーザー操作に起因して前記障害が発生したのか前記情報処理装置に起因して前記障害が発生したのかを判断する際に用いられる判断情報を対応付けて記憶する記憶部をさらに備え、
   前記判断部は、前記検出部で検出された前記障害の種別を示す前記障害情報に対応する前記判断情報を特定し、特定した前記判断情報を用いて、前記検出部で検出された前記障害が、ユーザー操作に起因して発生したのか前記情報処理装置に起因して発生したのかを判断する、
   請求項１の情報処理システム。
3. 前記判断情報は、前記障害の原因を示す情報を含み、
   前記検出部で検出された前記障害の種別を示す前記障害情報に対応する前記判断情報に対して、前記障害を解消するための手順を示す手順情報を付加した前記メッセージを生成する生成部と、
   前記判断部による判断結果から、前記検出部で検出された前記障害の対応が可能な前記ユーザーを特定する特定部と、
   前記生成部により生成された前記メッセージを、前記特定部により特定された前記ユーザーへ通知する通知部と、をさらに備える、
   請求項２の情報処理システム。
4. 前記処理の対象となるデータのうち前記処理の実行中に前記障害が検出された前記データについては、次回の前記処理の対象となるように設定する未処理化部をさらに備える、
   請求項１の情報処理システム。
5. 情報処理装置による処理の実行中に発生した障害に関するメッセージを通知する情報処理システムによる情報処理方法であって、
   前記障害を検出する検出ステップと、
   前記検出ステップで検出された前記障害を示す障害情報を用いて、前記検出ステップで検出された前記障害が、ユーザー操作に起因して発生したのか前記情報処理装置に起因して発生したのかを判断する判断ステップと、を含む、
   情報処理方法。
6. 情報処理装置による処理の実行中に発生した障害に関するメッセージを通知する情報処理システムが有するコンピュータに、
   前記障害を検出する検出ステップと、
   前記検出ステップで検出された前記障害を示す障害情報を用いて、前記検出ステップで検出された前記障害が、ユーザー操作に起因して発生したのか前記情報処理装置に起因して発生したのかを判断する判断ステップと、を実行させるためのプログラム。