JP6210010B2 - 情報処理プログラム、装置及び方法 - Google Patents

Description

本発明は、ソフトウエアのインストール時に発生するエラーに対処するための技術に関する。

今までインストールしたことがないソフトウエアをインストールする際、インストールの手順やパラメータの設定を誤ることによりエラーメッセージが出力されることがある。インストールしたことがないソフトウエアのエラーメッセージに対する対処方法が不明な場合、操作者は、典型的には、インターネットなどで検索する等して対処法を探すことになる。しかしながら、対処法が見つからなかったり、見つかったとしてもエラーが解決しない対処法であったりして、早期に適切な対処法にたどり着くのは難しい。

通常運用時におけるエラーに対して対処法を蓄積して再利用するような技術は存在しているが、インストール時に発生するエラーに着目したものはない。インストール時は、関連するソフトウエア構成が整っていないためにエラーが発生することがあるが、通常運用時にはソフトウエア構成が整っていないためにエラーが発生するわけではない。知識のない操作者にとっては、あるソフトウエアをインストールする際に求められるソフトウエア構成がどのような状態であってもそのための対処法が提示される方が好ましい。

特開２００５−３４６３３１号公報 特開２００３−１１４８１１号公報

従って、本発明の目的は、一側面によれば、複数の装置に対して共通して適用可能な対処データを生成できるようにするための技術を提供することである。

本発明に係る情報処理方法は、（Ａ）ソフトウエアの被インストール装置から、ソフトウエアの識別子と、ソフトウエアのインストール中に発生したエラーの識別子と、当該エラーの発生時における被インストール装置の第１の構成データと、エラーの解消時における被インストール装置の第２の構成データとを取得し、（Ｂ）ソフトウエアの識別子に対応付けて格納部にソフトウエアのインストール時に行うべき対処ステップを含む既存の対処データが格納されている場合には、当該既存の対処データと第１の構成データ及び第２の構成データとに基づき、ソフトウエアの識別子及びエラーの識別子に対応する対処データを更新し、（Ｃ）格納部に既存の対処データが格納されていない場合には、第１の構成データ及び第２の構成データとの差分から対処データを生成し、ソフトウエアの識別子及びエラーの識別子に対応付けて格納部に格納する処理を含む。

一側面としては、複数の装置に対して共通して適用可能な対処データを生成できるようになる。

図１は、実施の形態に係るシステムの概要を示す図である。 図２は、運用管理サーバの構成例を示す図である。 図３は、第１の例においてパッケージ管理ＤＢに格納されるデータの例を示す図である。 図４は、第１の例において構成ＤＢに格納されるデータの例を示す図である。 図５は、第１の例においてログデータとパッケージ管理ＤＢと構成ＤＢとの関係を示す図である。 図６は、第２の例においてパッケージ管理ＤＢに格納される初期的なデータの例を示す図である。 図７は、第２の例におけるログデータとパッケージ管理ＤＢと構成ＤＢとの関係を示す図である。 図８は、第２の例においてパッケージ管理ＤＢに格納されるデータの例を示す図である。 図９は、第２の例において構成ＤＢに格納されるデータの例を示す図である。 図１０は、第３の例においてパッケージ管理ＤＢに格納される初期的なデータの例を示す図である。 図１１は、第３の例におけるログデータとパッケージ管理ＤＢと構成ＤＢとの関係を示す図である。 図１２は、第３の例においてパッケージ管理ＤＢに格納されるデータの例を示す図である。 図１３は、第３の例において構成ＤＢに格納されるデータの例を示す図である。 図１４は、ソフトウエアパッケージのインストール時における処理の処理フローを示す図である。 図１５は、ソフトウエア管理表の一例を示す図である。 図１６は、エラー検出時の処理の処理フローを示す図である。 図１７は、サーバから運用管理サーバへ送信するデータのフォーマット例を示す図である。 図１８は、対処１におけるエラー発生時の構成データ例を示す図である。 図１９は、対処１におけるエラー解消時の構成データ例を示す図である。 図２０は、対処２におけるエラー発生時の構成データ例を示す図である。 図２１は、対処２におけるエラー解消時の構成データ例を示す図である。 図２２は、対処３におけるエラー発生時の構成データ例を示す図である。 図２３は、対処３におけるエラー解消時の構成データ例を示す図である。 図２４は、対処データの更新のための処理の処理フローを示す図である。 図２５は、対処１についての初期対処データを示す図である。 図２６は、対処２についての初期対処データを示す図である。 図２７は、対処３についての初期対処データを示す図である。 図２８は、対処データの更新例を示す図である。 図２９は、対処４についての初期対処データを示す図である。 図３０は、対処データの更新例を示す図である。 図３１は、対処データの更新のための処理の処理フローを示す図である。 図３２は、対処データの更新例を示す図である。 図３３は、対処ＤＢに登録される対処データの一例を示す図である。 図３４は、ある装置の構成データを示す図である。 図３５は、別のある装置の構成データを示す図である。 図３６は、検索処理の処理フローを示す図である。 図３７は、ある装置の場合に提示される対処候補例を示す図である。 図３８は、別のある装置の場合に提示される対処候補例を示す図である。 図３９は、コンピュータの機能ブロック図である。

本発明の実施の形態に係るシステムの概要を図１に示す。ネットワーク２００には、あるソフトウエアパッケージのインストール先となる１又は複数のサーバ３００が接続されており、さらに本実施の形態に係る主要な処理を実行する運用管理サーバ１００も接続されている。ユーザ端末４００は、サーバ３００に対してソフトウエアパッケージをインストールする際にユーザにより操作される端末装置であり、ユーザ端末４０２のようにサーバ３００に接続されている場合もあれば、ユーザ端末４０１にようにネットワーク２００に接続されている場合もある。なお、インストール時にエラーが発生した場合に、ユーザ端末４００のオペレータは、ユーザ端末４００に運用管理サーバ１００にアクセスさせ、対処方法のデータを取得するようになっている。

サーバ３００は、収集部３０６と、構成管理部３０４と、パッケージ管理部３０８と、構成データベース（ＤＢ）３０５と、パッケージ管理ＤＢ３０９とを有する。

ユーザ端末４００のオペレータは、サーバ３００に、ソフトウエアパッケージをインストールする。インストール時に、例えばＯＳ（Operating System）から通知を受けた収集部３０６は、そのソフトウエアパッケージに含まれるプログラム３０１のログ出力先（例えばログファイル３０２）及びパラメータの格納場所（例えばパラメータファイル３０３）のデータを例えばソフトウエアパッケージのパッケージ情報から取得して、ソフトウエア管理表３０７に登録する。本実施の形態では、プログラム３０１が出力するログをモニタするので、ログの出力先が特定できない場合には、収集部３０６は、ソフトウエア管理表３０７にソフトウエアパッケージのデータを登録しない。また、パラメータ格納場所のデータが取得できない場合にも、ソフトウエア管理表３０７にソフトウエアパッケージのデータを登録しない。

構成管理部３０４は、例えばソフトウエア管理表３０７から、プログラム３０１のパラメータ格納場所（例えばパラメータファイル３０３）を特定し、そのパラメータ格納場所からパラメータを読み出して、構成ＤＢ３０５に格納する。但し、構成管理部３０４は、ソフトウエア管理表３０７ではなく別途取得したパラメータ格納場所からパラメータを読み出して、構成ＤＢ３０５に格納しても良い。パッケージ管理部３０８は、例えばＯＳからインストールされたソフトウエアパッケージのデータを取得して、パッケージ管理ＤＢ３０９に格納する。

収集部３０６は、ログの出力先からログを読み出し、エラーの発生を検出すると、構成ＤＢ３０５及びパッケージ管理ＤＢ３０９から構成データを読み出す。また、収集部３０６は、ログからエラーの解消を検出すると、再度構成ＤＢ３０５及びパッケージ管理ＤＢ３０９から構成データを読み出す。そして、収集部３０６は、ソフトウエアパッケージ名、エラーメッセージ（エラーの識別子の相当）、エラー発生時の構成データ及びエラー解消時の構成データを、運用管理サーバ１００に送信する。さらに、収集部３０６は、エラーが発生した時又は定期的に、構成ＤＢ３０５及びパッケージ管理ＤＢ３０９から構成データを読み出して、運用管理サーバ１００へ送信する。

図２に、運用管理サーバ１００の機能ブロック構成を示す。運用管理サーバ１００は、受信部１０１と、第１構成データ格納部１０２と、対処データ更新部１０３と、対処ＤＢ１０４と、第２構成データ格納部１０５と、検索部１０６とを有する。

受信部１０１は、各サーバ３００から、エラー発生時及びエラー解消時の構成データを受信すると第１構成データ格納部１０２に格納し、ある時点の構成データを受信すると第２構成データ格納部１０５に格納する。

対処データ更新部１０３は、初期対処データ生成部１０３１と、第１更新部１０３２と、第２更新部１０３３とを有する。

初期対処データ生成部１０３１は、第１構成データ格納部１０２に格納されているエラー発生時及びエラー解消時の構成データから初期的な対処データを生成する。第１更新部１０３２は、対処ＤＢ１０４に既に登録されている、同じソフトウエアパッケージ且つ同じエラーメッセージについての対処データを、初期的な対処データで更新する。第２更新部１０３３は、対処ＤＢ１０４に既に登録されている、同じソフトウエアパッケージ且つ異なるエラーメッセージについての対処データで、今回のエラーメッセージについての対処データを更新する。

検索部１０６は、ユーザ端末４００から、ソフトウエアパッケージの識別子と、エラーメッセージと、サーバ３００の識別子（ユーザ毎に構成が異なる場合にはユーザ識別子を含む）とを含む検索要求を受信すると、対処ＤＢ１０４に格納されている対処データと、第２構成データ格納部１０５に格納された構成データとから、実行すべき対処ステップの候補を抽出して、ユーザ端末４００に返信する。

次に、図３乃至図１３を用いて、サーバ３００に対して行われるインストールの手順について具体例を説明する。

ここではソフトウエアパッケージａｐｐｔｏを導入する場合を説明する。このａｐｐｔｏを導入する場合には、以下のような手順が実行される。
（１）ｌｉｂｘｙｚ−５．１をインストール
（２）ｏｐｅｎｄｂをインストール
（３）ｏｐｅｎｄｂのパスワードをセット（例えばｓｅｃｒｅｔ）
（４）ｏｐｅｎｄｂをスタート
（５）ａｐｐｔｏをインストール
（６）ａｐｐｔｏのｃｏｎｎｅｃｔｔｏパラメータに、ｌｏｃａｌｈｏｓｔ：３３６０をセット
（７）ａｐｐｔｏのｄｂｐａｓｓｗｄパラメータのセット（（３）と同じパスワード）
（８）ａｐｐｔｏをスタート

このような正しい操作を行うと、パッケージ管理ＤＢ３０９には、インストールしたソフトウエアパッケージの順で図３に示すようなデータが格納されるようになる。図３の例では、ソフトウエアパッケージ名と、そのバージョンとが登録される。上で述べた（１）（２）（５）に対応するデータが登録されている。

また、構成ＤＢ３０５には、図４に示すようなデータが、操作の順に登録される。図４の例では、コンポーネント名と、パラメータと、そのパラメータの値とが登録されるようになっている。上で述べた（３）（６）（７）についてのデータが登録されている。

これに対してログファイル３０２と、パッケージ管理ＤＢ３０９及び構成ＤＢ３０５に格納されているデータとの対応関係を図５に示す。

上で述べた例ではエラーは発生していないので、ａｐｐｔｏのログファイル３０２には、（８）ａｐｐｔｏをスタートに応じて［ｉｎｆｏ］ｐｒｅｐａｒｉｎｇ及び［ｉｎｆｏ］ｓｔａｒｔｉｎｇのみが登録される。一方、パッケージ管理ＤＢ３０９には上で述べたように（１）（２）（５）に対応するデータが登録される。よって、パッケージ管理ＤＢ３０９から、（１）に対応する操作である対処ステップ「Ｉｎｓｔａｌｌ ｌｉｂｘｙｚ−５．１」と、（２）に対応する操作である対処ステップ「Ｉｎｓｔａｌｌ ｏｐｅｎｄｂ−４．２」と、（５）に対応する操作である対処ステップ「Ｉｎｓｔａｌｌ ａｐｐｔｏ−１．５」とが得られる。

また、構成ＤＢ３０５には上で述べたように（３）（６）（７）に対応するデータが登録される。よって、構成ＤＢ３０５から、（３）に対応する操作である対処ステップである「ｏｐｅｎｄｂ，ｐａｓｓｗｄ＝ｓｅｃｒｅｔ」と、（６）に対応する操作である対処ステップ「ａｐｐｔｏ，ｃｏｎｎｅｃｔｔｏ＝ｌｏｃａｌｈｏｓｔ：３３６０」と、（７）に対応する操作である対処ステップ「ａｐｐｔｏ，ｄｂｐａｓｓｗｄ＝ｓｅｃｒｅｔ」とが得られる。

一方、正しい操作が行われない場合も示す。例えば、（１）のｌｉｂｘｙｚのインストールを忘れて、（３）のｏｐｅｎｄｂのパスワードのセットを忘れ、無駄にｌｉｂａｂｃ−３．３をインストールしてしまった場合を示す。本例では、さらにｏｐｅｎｄｂについては既にインストール済みであるものとする。すなわち、１０：１４の時点で、図６に示すようなパッケージ管理ＤＢ３０９の状態になっている。

図７に、ａｐｐｔｏのログを示す。この例では、１０：１５でａｐｐｔｏ−１．５をインストールして、いきなりａｐｐｔｏをスタートさせたので、ａｐｐｔｏのログには、エラーメッセージ「ｍｉｓｓｉｎｇ ｌｉｂｒａｒｙ」が登録される。これに対して、オペレータは、１０：１７にｌｉｂｘｙｚ−５．１をインストールすると共に１０：１８にｌｉｂａｂｃ−３．３をインストールしている。従って、パッケージ管理ＤＢ３０９には、図８に示すようなデータが格納されるようになる。この時点で、パッケージ管理ＤＢ３０９からは、既にインストールされていた分を除き、図７に示すような２つの対処ステップが得られる。

１０：１９で再度ａｐｐｔｏをスタートさせたので、ａｐｐｔｏのログには、エラーメッセージ「ｃｏｕｌｄ ｎｏｔ ｃｏｎｎｅｃｔ ｔｏ ｄａｔａｂａｓｅ」が登録される。これに対して、オペレータは、ｏｐｅｎｄｂ及びａｐｐｔｏについてのパラメータの設定を行うので、構成ＤＢ３０５に図９に示すようなデータが格納される。

このようにしてからａｐｐｔｏをスタートさせると、１０：２３に［ｉｎｆｏ］ｓｔａｒｔｉｎｇというログが格納される。これによってエラーが解消したことが分かる。

また、別の例も示しておく。例えば、図１０に示すように、既にｏｐｅｎｄｂ及びｌｉｂｘｙｚがインストール済みであるものとする。

図１１に、ａｐｐｔｏのログを示す。この例では、１０：１５でｏｐｅｎｄｂについてパラメータの設定を行い、１０：１６でａｐｐｔｏをインストールしている。なお、この段階で、パッケージ管理ＤＢ３０９に図１２に示すようなデータが格納される。

さらに、１０：１７で、ａｐｐｔｏについてパラメータの設定し、１０：１８でａｐｐｔｏをスタートさせた。しかしながら、ａｐｐｔｏについてパラメータｄｂｐａｓｓｗｄの設定が行われていないので、エラーメッセージ「ｃｏｕｌｄ ｎｏｔ ｃｏｎｎｅｃｔ ｔｏ ｄａｔａｂａｓｅ」がログとして登録される。

これに対して、オペレータは、１０：１９でａｐｐｔｏのパラメータｄｂｐａｓｓｗｄの設定を行うが、パスワードの綴りが間違っているので、１０：２０で再度ａｐｐｔｏをスタートさせても同じエラーメッセージが出力され、ログファイル３０２に登録される。これに対して、オペレータは、１０：２１に正しいパラメータの設定を行ったので、１０：２２でａｐｐｔｏをスタートさせると、［ｉｎｆｏ］ｓｔａｒｔｉｎｇというログが格納される。これによってエラーが解消したことが分かる。１０：２１で、パラメータの修正が行われているので、構成ＤＢ３０５には、図１３に示すようなデータが格納される。

このようにパッケージ管理ＤＢ３０９及び構成ＤＢ３０５には、ソフトウエアパッケージをインストールして動作させるために行われた操作に対応するデータが蓄積される。

図７の例では、１０：１６でエラーが発生した時点におけるパッケージ管理ＤＢ３０９及び構成ＤＢ３０５の内容と、１０：２３でエラーが解消した時点におけるパッケージ管理ＤＢ３０９及び構成ＤＢ３０５の内容との差は、図７の３行目から８行目までに対処ステップとして示されており、この部分を抽出することで、エラーに対するこの場合の対処データとなる。

同様に、図１１の例では、１０：１８でエラーが発生した時におけるパッケージ管理ＤＢ３０９及び構成ＤＢ３０５の内容と、１０：２２でエラーが解消した時点におけるパッケージ管理ＤＢ３０９及び構成ＤＢ３０５の内容との差は、７行目の対処ステップで表される。５行目の対処ステップは、構成ＤＢ３０５ではマージされているので、現れない。従って、７行目を抽出することで、エラーに対するこの場合の対処データとなる。

このような特質に基づき、以下に示す処理を行うことで、複数の装置で適用可能な対処データを抽出して、再利用できるようにする。

まず、サーバ３００側の処理について、図１４乃至図１７を用いて説明する。

まず、図１４を用いて、ソフトウエアパッケージのインストール時における収集部３０６の処理について説明する。

まず、収集部３０６は、例えばＯＳからの通知により、新規ソフトウエアパッケージのインストールを検出する（図１４：ステップＳ１）。ここで、パッケージ管理部３０８も、例えばＯＳからの通知により、新規ソフトウエアパッケージのインストールを検出して、パッケージ管理ＤＢ３０９に登録する。

そして、収集部３０６は、そのソフトウエアパッケージのパッケージ情報に、ログの出力先が規定されているか否かを判断する（ステップＳ３）。ログの出力先が規定されていない場合には、本ソフトウエアパッケージについては構成データを抽出できないので、処理を終了する。一方、ログの出力先が規定されている場合には、収集部３０６は、パッケージ情報からログの出力先（例えばログファイル３０２）を特定する（ステップＳ５）。

また、収集部３０６は、パッケージ情報に、パラメータの格納場所が規定されているか否かを判断する（ステップＳ７）。本実施の形態では、パラメータの格納場所が規定されていない場合には、処理を終了する。

一方、パラメータの格納場所が規定されていれば、収集部３０６は、パラメータの格納場所（例えばパラメータファイル３０３）を特定する（ステップＳ９）。

そして、収集部３０６は、ソフトウエア管理表３０７に、ソフトウエア名と、ログ出力先と、パラメータ格納場所とを登録する（ステップＳ１１）。そして処理を終了する。

例えば、ソフトウエア管理表３０７の一例を図１５に示す。図１５の例では、上で述べたように、ソフトウエア名と、ログ出力先と、パラメータ格納場所とが格納される。このようなソフトウエア管理表３０７に従って、収集部３０６は、ログの監視を行う。また、構成管理部３０４は、パラメータファイル３０３を特定して、更新があれば、構成ＤＢ３０５を更新する。

次に、図１６を用いて、エラー検出時の処理を説明する。

収集部３０６は、ログファイル３０２から未処理のログを読み出す（ステップＳ２１）。例えば新たに登録されたログを読み出す。また、収集部３０６は、エラー発生後且つエラー解消前の状態であるか否かを表す対処中フラグの状態をチェックする（ステップＳ２３）。

そして、収集部３０６は、対処中フラグがオフとなっており且つログにエラーが発生したか否かを判断する（ステップＳ２５）。エラー発生はエラーメッセージが登録されているか否かで判断する。

この条件を満たす場合には、エラー解消後に新たにエラーが発生した場合を示しているので、収集部３０６は、対処中フラグをオンにセットする（ステップＳ２７）。また、収集部３０６は、対処前（エラー発生時）の構成データを、構成ＤＢ３０５及びパッケージ管理ＤＢ３０９から取得する（ステップＳ２９）。具体的には、構成ＤＢ３０５から、その時点における構成情報を読み出し、パッケージ管理ＤＢ３０９からパッケージ管理データを読み出す。そして処理はステップＳ３９に移行する。

一方、対処中フラグがオフとなっており且つエラーが発生したと判断しなかった場合、収集部３０６は、対処中フラグがオンで且つログが正常稼働中であることを示しているか否かを判断する（ステップＳ３１）。正常稼働中は、上で述べた例では［ｉｎｆｏ］ｓｔａｒｔｉｎｇといった予め定められたメッセージが登録されているか否かで判断する。この条件を満たさない場合には、処理はステップＳ３９に移行する。

一方、対処中フラグがオンで且つログが正常稼働中である場合には、エラーが解消したことになるので、収集部３０６は、対処中フラグをオフにセットする（ステップＳ３３）。また、収集部３０６は、対処後（エラー解消後）の構成データを、構成ＤＢ３０５及びパッケージ管理ＤＢ３０９から取得する（ステップＳ３５）。具体的には、構成ＤＢ３０５から、その時点における構成情報を読み出し、パッケージ管理ＤＢ３０９からパッケージ管理データを読み出す。

そして、収集部３０６は、対処前後の構成データを、運用管理サーバ１００へ送信する（ステップＳ３７）。例えば図１７に示すようなデータを、運用管理サーバ１００へ送信する。

図１７の例では、ユーザＩＤ及びサーバＩＤと、ソフトウエア名と、エラーメッセージと、対処前の構成データ（パッケージ管理データ及び構成情報）と、対処後の構成データ（パッケージ管理データ及び構成情報）とを含む。

そして、収集部３０６は、処理終了が指示されたか否かを判断する（ステップＳ３９）。処理終了でなければ処理はステップＳ２１に戻る。一方、処理終了が指示されると処理は終了する。

このような処理を行うことで、エラー発生時の構成データと、エラー解消後の構成データとを確実に取得でき、運用管理サーバ１００へ送信できる。

次に、運用管理サーバ１００における処理について図１８乃至図３３を用いて説明する。まず、以下の説明で用いる具体例について説明しておく。

図１８は、エラーメッセージｍｉｓｓｉｎｇ ｌｉｂｒａｒｙのエラーが発生したときの構成データ例を示す図である。なお、構成ＤＢ３０５における構成情報については省略されている。一方、図１９は、エラーメッセージｍｉｓｓｉｎｇ ｌｉｂｒａｒｙのエラーが解消した時の構成データ例を示す図である。図１８と同様に、構成ＤＢ３０５における構成情報については省略されている。そして、パッケージ管理ＤＢ３０９におけるパッケージ管理データにおいて太線で囲まれた部分が、図１８に示したエラー発生時とは異なる部分である。なお、図１８及び図１９で示した構成データを、対処１の構成データと呼ぶことにする。

図２０は、エラーメッセージｃｏｕｌｄ ｎｏｔ ｃｏｎｎｅｃｔ ｄａｔａｂａｓｅのエラーが発生したときの構成データ例を示す図である。なお、構成ＤＢ３０５における構成情報については省略されている。一方、図２１は、エラーメッセージｃｏｕｌｄ ｎｏｔ ｃｏｎｎｅｃｔ ｄａｔａｂａｓｅのエラーが解消した時の構成データ例を示す図である。構成情報については、太線で囲まれた追加された部分のみ具体的に示している。そして、構成ＤＢ３０５における構成情報において太線で囲まれた部分が、図２０に示したエラー発生時とは異なる部分である。なお、図２０及び図２１で示した構成データを、対処２の構成データと呼ぶことにする。

図２２は、エラーメッセージｃｏｕｌｄ ｎｏｔ ｃｏｎｎｅｃｔ ｄａｔａｂａｓｅのエラーが発生したときの構成データ例を示す図である。なお、構成ＤＢ３０５における構成情報については一部省略されている。一方、図２３は、エラーメッセージｃｏｕｌｄ ｎｏｔ ｃｏｎｎｅｃｔ ｄａｔａｂａｓｅのエラーが解消した時の構成データ例を示す図である。そして、構成ＤＢ３０５における構成情報において太線で囲まれた部分が、図２２に示したエラー発生時とは異なる部分である。なお、図２２及び図２３で示した構成データを、対処３の構成データと呼ぶことにする。

次に、図２４乃至図３３を用いて運用管理サーバ１００において対処データを対処ＤＢ１０４に登録する又は対処ＤＢ１０４に登録済みの対処データを更新する際の処理について説明する。

受信部１０１は、サーバ３００から、対処前後の構成データを受信し、第１構成データ格納部１０２に格納する（図２４：ステップＳ４１）。なお、この段階で対処後の構成データを、第２構成データ格納部１０５に格納するようにしても良い。

そして、対処データ更新部１０３の初期対処データ生成部１０３１は、対処前後の構成データの差分を抽出して、初期対処データを生成する（ステップＳ４３）。

例えば対処１の場合、図２５に示すような初期対処データが生成される。図２５の例では、図１９において太線で示したパッケージ管理データの差分に対応する対処ステップ１及び２が含まれる。なお、区別するため、ソフトウエア名及びエラーメッセージについても共に示している。

同様に、対処３の場合、図２７に示すような初期対処データが生成される。図２７の例では、図２３において太線で示した構成データの差分に対応する対処ステップ１が含まれる。なお、区別するため、ソフトウエア名及びエラーメッセージについても共に示している。

さらに、対処２の場合、図２６に示すような初期対処データが生成される。図２６の例では、図２１において太線で示した構成データの差分に対応する対処ステップ１乃至３が含まれる。なお、区別するため、ソフトウエア名及びエラーメッセージについても共に共に示している。

そして、対処データ更新部１０３の第１更新部１０３２は、同じソフトウエアパッケージで発生する同じエラーについて対処データが対処ＤＢ１０４に登録されているか判断する（ステップＳ４５）。

この条件が満たされる場合には、第１更新部１０３２は、既存の対処データに含まれないが初期対処データに含まれる対処ステップを、既存の対処データに追加する（ステップＳ４７）。そして処理はステップＳ４９に移行する。一方、同じソフトウエアパッケージで発生する同じエラーについて対処データが未だ登録されていない場合には、処理はステップＳ４９に移行する。

例えば、最初に、ソフトウエアパッケージ「ａｐｐｔｏ」のエラーメッセージ「ｃｏｕｌｄ ｎｏｔ ｃｏｎｎｅｃｔ ｄａｔａｂａｓｅ」についての対処３から生成された初期対処データ（図２７）がそのまま対処ＤＢ１０４に登録されているものとする。次に同じソフトウエアパッケージで同じエラーメッセージについての対処２から生成された初期対処データ（図２６）が生成されると、図２６における初期対処データにおける対処ステップ１及び２が、ステップＳ４７の条件を満たすことが分かる。従って、既存の対処データに、初期対処データにおける対処ステップ１及び２が追加される。すなわち、図２８に示すようなデータに対処データが更新される。なお、対処後の構成データについては、後の処理で用いられるので、この例の場合対処２の構成データ（図２１）が保持される。

また、この後に、図２９に示すような対処４の初期対処データが得られたものとする。そうすると、対処４の初期対処データにおける対処ステップ１はステップＳ４７の条件を満たすが、対処ステップ２はステップＳ４７の条件を満たさないことが分かる。従って、ステップＳ４７を行えば、図３０に示すように対処データが更新される。すなわち、図３０における対処ステップ２が挿入される。なお、同じ種類のコンポーネント名の対処ステップが並ぶように、対処データ内でソートされている。

このような処理を行うことで、エラー発生時の状態によってこれまで抽出されなかった対処ステップを、いずれの装置においても漏れなく行うように追加することができるようになる。

図２４の処理の説明に戻って、第２更新部１０３３は、同じソフトウエアパッケージで発生する異なるエラーについて対処データが登録済みであるか否かを判断する（ステップＳ４９）。この条件を満たす場合には、処理は端子Ａを介して図３１の処理に移行する。

一方、この条件を満たさない場合には、対処データ更新部１０３は、更新後の対処データ（同じソフトウエアパッケージに対して何も登録されていなかった場合には初期対処データそのもの）を、対処ＤＢ１０４に登録する（ステップＳ５１）。なお、対処データに対応する対処後の構成データについても、対処ＤＢ１０４に登録する。そして処理は終了する。

次に、図３１を用いて端子Ａの後の処理について説明する。第２更新部１０３３は、未処理のエラーについて登録済みの対処データを特定する（ステップＳ５３）。今回のエラーに対して複数の異なるエラーについて対処データが登録されている場合があるので、例えば登録順に、登録済みの対処データを処理するものである。

そして、第２更新部１０３３は、処理対象の対処データに対応する対処後の構成データと、特定された対処データに対応する対処後の構成データとを比較して、差分を特定する（ステップＳ５５）。

例えば、図２８に示すような対処データが登録済みの対処データであり、対応する対処後の構成データが図２３に示すような構成データであるものとする。これに対して、対処１についての対処データ（図２５）が初期対処データとしてそのまま図３１の処理対象となった場合、対応する対処後の構成データは図１９に示すようなものであるとする。

そうすると、図２３と図１９を比較して、構成情報については差異がないとすると、対処１のパッケージ管理データにおいて「ｌｉｂａｂｃ」が余分に追加されているということが分かる。

ステップＳ５５の処理で差分が特定されなければ処理はステップＳ６１に移行する。一方、ステップＳ５５の処理で差分が特定されると、第２更新部１０３３は、特定された差分に対応する対処ステップを、対処データから削除する（ステップＳ５９）。具体的には、図２５において対処ステップ２が、差分に対応する対処ステップなので、その対処ステップが削除されて、図３２に示すような対処データに更新される。なお、構成データについては更新せずそのまま用いる。

そして、第２更新部１０３３は、未処理のエラーが存在するか否かを判断する（ステップＳ６１）。未処理のエラーが存在する場合には、処理はステップＳ５３に戻る。一方、未処理のエラーが存在しない場合には、端子Ｂを介して図２４の処理に戻る。

以上のような処理を行うことで、どのような装置に対しても共通して適用可能な対処データが生成されるようになる。

なお、パスワードのような具体的な値が対処ステップに含まれる場合には、そのまま対処ＤＢ１０４に登録するのは好ましくないので、図３３に示すように、「％ｓ」のように変数化している。

次に、検索時の処理について図３４乃至図３８を用いて説明する。なお、図３３に示すような対処データが対処ＤＢ１０４に登録されており、第２構成データ格納部１０５には、図３４及び図３５のような構成データが格納されているものとする。

図３４の例では、ユーザ「ｕ０７００」のサーバ「ｉ３０００」の構成情報を示しており、図３５の例では、ユーザ「ｕ０８００」のサーバ「ｉ４０００」の構成情報を示している。このように、エラー発生時の構成情報に差異があるものとする。

図３６を用いて処理内容を説明する。まず、検索部１０６は、ユーザ端末４００から、エラー内容（ソフトウエア名及びエラーメッセージ）及びユーザデータ（ユーザＩＤ及びサーバＩＤ）を受信する（ステップＳ１０１）。場合によっては、この段階で構成データを受信するようにしても良い。

そして、検索部１０６は、エラー内容で対処ＤＢ１０４を検索することで、対応する対処データを抽出する（ステップＳ１０５）。ここで、対処データが抽出できなければ（ステップＳ１０５：Ｎｏルート）、検索部１０６は、対処候補無しを、ユーザ端末４００へ送信する（ステップＳ１０７）。そして処理は終了する。

一方、対処データが抽出されると（ステップＳ１０５：Ｙｅｓルート）、検索部１０６は、抽出された対処データに含まれる対処ステップのうち、ユーザデータで第２構成データ格納部１０５において特定される構成データにおいて、対応する構成データが含まれている対処ステップを削除する（ステップＳ１０９）。

そして、検索部１０６は、残余の対処ステップを対処候補として含むデータを、ユーザ端末４００に送信する（ステップＳ１１１）。ユーザ端末４００は、このようなデータを受信し、表示装置に表示する。

例えば、図３７上段に示すように、ユーザ「ｕ０７００」のサーバ「ｉ３０００」について、ソフトウエア名「ａｐｐｔｏ」でエラーメッセージが「ｃｏｕｌｄ ｎｏｔ ｃｏｎｎｅｃｔ ｄａｔａｂａｓｅ」である旨の検索要求を受信すると、図３４のような構成データが読み出される。対処データは図３３に示すような対処データが抽出される。図３４の構成データからは、ｏｐｅｎｄｂに対してパスワードは設定済みであることが分かるので、図３３の対処データのうち対処ステップ１は削除される。従って、対処ステップ２及び３のみが残る。従って、図３７下段に示すように、ユーザ端末４００の表示装置には、対処ステップ２及び３が対処候補１及び２として提示されるようになる。

一方、図３８上段に示すように、ユーザ「ｕ０８００」のサーバ「ｉ４０００」について、ソフトウエア名「ａｐｐｔｏ」でエラーメッセージが「ｃｏｕｌｄ ｎｏｔ ｃｏｎｎｅｃｔ ｄａｔａｂａｓｅ」である旨の検索要求を受信すると、図３５のような構成データが読み出される。対処データは図３３に示すような対処データが抽出される。図３５の構成データからは、ｏｐｅｎｄｂに対してパスワードは設定済みで、ａｐｐｔｏについてｃｏｎｎｅｃｔｔｏというパラメータには設定が成されていることが分かるので、図３３の対処データのうち対処ステップ１及び２は削除される。従って、対処ステップ３のみが残る。従って、図３８下段に示すように、ユーザ端末４００の表示装置には、対処ステップ３が対処候補１として提示されるようになる。

以上のようにすれば、オペレータがインストールしたソフトウエアパッケージ及びその装置の構成に応じた適切な対処候補が提示されるようになる。

以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、図１及び２に示した機能ブロック構成は一例であって、プログラムモジュール構成と一致しない場合もある。また、処理フローについては、処理結果が変わらない限り、処理ステップの実行順番を入れ替えたり、複数の処理ステップを並列に実行するようにしても良い。

さらに、サーバ３００の一部の処理については、運用管理サーバ１００で行うようにしても良い。

さらに、上で述べた実施の形態はソフトウエアのインストール時を想定しているが、通常運用時のエラーへの対処についても適用可能な場合もある。

また、運用管理サーバ１００の構成については、複数のコンピュータによって機能分担を行う場合もある。

なお、上で述べた運用管理サーバ１００やサーバ３００は、コンピュータ装置であって、図３９に示すように、メモリ２５０１とＣＰＵ（Central Processing Unit）２５０３とハードディスク・ドライブ（ＨＤＤ：Hard Disk Drive）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

以上述べた本実施の形態をまとめると、以下のようになる。

本実施の形態に係る情報処理方法は、（Ａ）ソフトウエアの被インストール装置から、ソフトウエアの識別子と、ソフトウエアのインストール中に発生したエラーの識別子と、当該エラーの発生時における被インストール装置の第１の構成データと、エラーの解消時における被インストール装置の第２の構成データとを取得し、（Ｂ）ソフトウエアの識別子に対応付けて格納部にソフトウエアのインストール時に行うべき対処ステップを含む既存の対処データが格納されている場合には、当該既存の対処データと第１の構成データ及び第２の構成データとに基づき、ソフトウエアの識別子及びエラーの識別子に対応する対処データを更新し、（Ｃ）格納部に既存の対処データが格納されていない場合には、第１の構成データ及び第２の構成データとの差分から対処データを生成し、ソフトウエアの識別子及びエラーの識別子に対応付けて格納部に格納する処理を含む。

このような処理によれば、複数の装置に共通して適用可能な対処データを、構成データから蓄積してゆくことができるようになる。

なお、上で述べた既存の対処データを更新する処理が、（ｂ１）第１の構成データと第２の構成データとの差分から第１の対処データを生成し、（ｂ２）ソフトウエアの識別子及びエラーの識別子に対応付けられている第１の既存の対処データに含まれないが第１の対処データに含まれる対処ステップが存在する場合には、当該対処ステップを第１の既存の対処データに追加することで第１の既存の対処データを更新する処理を含むようにしても良い。

これによって漏れが生じないように対処ステップを追加させることができるようになる。

さらに、上で述べた既存の対処データを更新する処理が、（ｂ３）格納部においてソフトウエアの識別子及びエラーの識別子とは異なるエラーの識別子に対応付けられている第２の既存の対処データに係る第２の構成データと、更新後の第１の既存の対処データ又は第１の対処データに係る第２の構成データとの差を特定し、（ｂ４）上記差に対応する、更新後の第１の既存の対処データ又は第１の対処データにおける対処ステップを削除する処理をさらに含むようにしても良い。これによって必須とは言えない対処ステップを除去できるようになる。

さらに、本情報処理方法は、（Ｄ）ソフトウエアの識別子とエラーの識別子と被インストール装置の識別子とを含む検索要求を受信し、（Ｅ）ソフトウエアの識別子及びエラーの識別子に対応付けられた対処データを格納部から抽出し、（Ｆ）抽出された対処データに含まれる対処ステップのうち、検索要求に係るエラー発生時における被インストール装置の第３の構成データにおいて対応するデータが含まれる対処ステップを削除し、（Ｈ）抽出された対処データを出力する処理をさらに含むようにしても良い。

これによって、被インストール装置の状態に応じた対処データが、オペレータに提示され、効果的な対処が成されるようになることが期待される。

なお、エラー発生時及びエラーの解消時が、ソフトウエアにより出力されるログを読み出すことで特定される場合もある。このようにすれば、正確にエラー発生時及びエラー解消時を検出できる。

なお、上で述べたような処理をコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭなどの光ディスク、光磁気ディスク、半導体メモリ（例えばＲＯＭ）、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、ＲＡＭ等の記憶装置に一時保管される。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）
ソフトウエアの被インストール装置から、前記ソフトウエアの識別子と、前記ソフトウエアのインストール中に発生したエラーの識別子と、当該エラーの発生時における前記被インストール装置の第１の構成データと、前記エラーの解消時における前記被インストール装置の第２の構成データとを取得し、
前記ソフトウエアの識別子に対応付けて格納部に前記ソフトウエアのインストール時に行うべき対処ステップを含む既存の対処データが格納されている場合には、当該既存の対処データと前記第１の構成データ及び前記第２の構成データとに基づき、前記ソフトウエアの識別子及び前記エラーの識別子に対応する対処データを更新し、
前記格納部に前記既存の対処データが格納されていない場合には、前記第１の構成データ及び前記第２の構成データとの差分から対処データを生成し、前記ソフトウエアの識別子及び前記エラーの識別子に対応付けて前記格納部に格納する
処理を、コンピュータに実行させるためのプログラム。

（付記２）
前記既存の対処データを更新する処理が、
前記第１の構成データと前記第２の構成データとの差分から第１の対処データを生成し、
前記ソフトウエアの識別子及び前記エラーの識別子に対応付けられている第１の既存の対処データに含まれないが前記第１の対処データに含まれる対処ステップが存在する場合には、当該対処ステップを前記第１の既存の対処データに追加することで前記第１の既存の対処データを更新する
処理を含む付記１記載のプログラム。

（付記３）
前記既存の対処データを更新する処理が、
前記格納部において前記ソフトウエアの識別子及び前記エラーの識別子とは異なるエラーの識別子に対応付けられている第２の既存の対処データに係る第２の構成データと、更新後の前記第１の既存の対処データ又は前記第１の対処データに係る第２の構成データとの差を特定し、
前記差に対応する、更新後の前記第１の既存の対処データ又は前記第１の対処データにおける対処ステップを削除する
処理をさらに含む付記２記載のプログラム。

（付記４）
ソフトウエアの識別子とエラーの識別子と被インストール装置の識別子とを含む検索要求を受信し、
前記ソフトウエアの識別子及び前記エラーの識別子に対応付けられた対処データを前記格納部から抽出し、
抽出された前記対処データに含まれる対処ステップのうち、前記検索要求に係るエラー発生時における前記被インストール装置の第３の構成データにおいて対応するデータが含まれる対処ステップを削除し、
抽出された前記対処データを出力する
処理をさらに前記コンピュータに実行させるための付記１乃至３のいずれか１つ記載のプログラム。

（付記５）
前記エラー発生時及び前記エラーの解消時が、前記ソフトウエアにより出力されるログを読み出すことで特定される
付記１乃至４のいずれか１つ記載のプログラム。

（付記６）
ソフトウエアの被インストール装置から、前記ソフトウエアの識別子と、前記ソフトウエアのインストール中に発生したエラーの識別子と、当該エラーの発生時における前記被インストール装置の第１の構成データと、前記エラーの解消時における前記被インストール装置の第２の構成データとを取得し、
前記ソフトウエアの識別子に対応付けて格納部に前記ソフトウエアのインストール時に行うべき対処ステップを含む既存の対処データが格納されている場合には、当該既存の対処データと前記第１の構成データ及び前記第２の構成データとに基づき、前記ソフトウエアの識別子及び前記エラーの識別子に対応する対処データを更新し、
前記格納部に前記既存の対処データが格納されていない場合には、前記第１の構成データ及び前記第２の構成データとの差分から対処データを生成し、前記ソフトウエアの識別子及び前記エラーの識別子に対応付けて前記格納部に格納する
処理を、コンピュータが実行する情報処理方法。

（付記７）
ソフトウエアの被インストール装置から、前記ソフトウエアの識別子と、前記ソフトウエアのインストール中に発生したエラーの識別子と、当該エラーの発生時における前記被インストール装置の第１の構成データと、前記エラーの解消時における前記被インストール装置の第２の構成データとを取得する取得部と、
前記ソフトウエアの識別子に対応付けて格納部に前記ソフトウエアのインストール時に行うべき対処ステップを含む既存の対処データが格納されている場合には、当該既存の対処データと前記第１の構成データ及び前記第２の構成データとに基づき、前記ソフトウエアの識別子及び前記エラーの識別子に対応する対処データを更新し、前記格納部に前記既存の対処データが格納されていない場合には、前記第１の構成データ及び前記第２の構成データとの差分から対処データを生成し、前記ソフトウエアの識別子及び前記エラーの識別子に対応付けて前記格納部に格納する更新部と、
を有する情報処理装置。

１０１ 受信部
１０２ 第１構成データ格納部
１０３ 対処データ更新部
１０４ 対処ＤＢ
１０５ 第２構成データ格納部
１０６ 検索部

Claims (7)

1. ソフトウエアの被インストール装置から、前記ソフトウエアの識別子と、前記ソフトウエアのインストール中に発生したエラーの識別子と、当該エラーの発生時における前記被インストール装置の第１の構成データと、前記エラーの解消時における前記被インストール装置の第２の構成データとを取得し、
   前記ソフトウエアの識別子に対応付けて格納部に前記ソフトウエアのインストール時に行うべき対処ステップを含む既存の対処データが格納されている場合には、当該既存の対処データと前記第１の構成データ及び前記第２の構成データとに基づき、前記ソフトウエアの識別子及び前記エラーの識別子に対応する対処データを更新し、
   前記格納部に前記既存の対処データが格納されていない場合には、前記第１の構成データ及び前記第２の構成データとの差分から対処データを生成し、前記ソフトウエアの識別子及び前記エラーの識別子に対応付けて前記格納部に格納する
   処理を、コンピュータに実行させるためのプログラム。
2. 前記既存の対処データを更新する処理が、
   前記第１の構成データと前記第２の構成データとの差分から第１の対処データを生成し、
   前記ソフトウエアの識別子及び前記エラーの識別子に対応付けられている第１の既存の対処データに含まれないが前記第１の対処データに含まれる対処ステップが存在する場合には、当該対処ステップを前記第１の既存の対処データに追加することで前記第１の既存の対処データを更新する
   処理を含む請求項１記載のプログラム。
3. 前記既存の対処データを更新する処理が、
   前記格納部において前記ソフトウエアの識別子及び前記エラーの識別子とは異なるエラーの識別子に対応付けられている第２の既存の対処データに係る第２の構成データと、更新後の前記第１の既存の対処データ又は前記第１の対処データに係る第２の構成データとの差を特定し、
   前記差に対応する、更新後の前記第１の既存の対処データ又は前記第１の対処データにおける対処ステップを削除する
   処理をさらに含む請求項２記載のプログラム。
4. ソフトウエアの識別子とエラーの識別子と被インストール装置の識別子とを含む検索要求を受信し、
   前記ソフトウエアの識別子及び前記エラーの識別子に対応付けられた対処データを前記格納部から抽出し、
   抽出された前記対処データに含まれる対処ステップのうち、前記検索要求に係るエラー発生時における前記被インストール装置の第３の構成データにおいて対応するデータが含まれる対処ステップを削除し、
   抽出された前記対処データを出力する
   処理をさらに前記コンピュータに実行させるための請求項１乃至３のいずれか１つ記載のプログラム。
5. 前記エラー発生時及び前記エラーの解消時が、前記ソフトウエアにより出力されるログを読み出すことで特定される
   請求項１乃至４のいずれか１つ記載のプログラム。
6. ソフトウエアの被インストール装置から、前記ソフトウエアの識別子と、前記ソフトウエアのインストール中に発生したエラーの識別子と、当該エラーの発生時における前記被インストール装置の第１の構成データと、前記エラーの解消時における前記被インストール装置の第２の構成データとを取得し、
   前記ソフトウエアの識別子に対応付けて格納部に前記ソフトウエアのインストール時に行うべき対処ステップを含む既存の対処データが格納されている場合には、当該既存の対処データと前記第１の構成データ及び前記第２の構成データとに基づき、前記ソフトウエアの識別子及び前記エラーの識別子に対応する対処データを更新し、
   前記格納部に前記既存の対処データが格納されていない場合には、前記第１の構成データ及び前記第２の構成データとの差分から対処データを生成し、前記ソフトウエアの識別子及び前記エラーの識別子に対応付けて前記格納部に格納する
   処理を、コンピュータが実行する情報処理方法。
7. ソフトウエアの被インストール装置から、前記ソフトウエアの識別子と、前記ソフトウエアのインストール中に発生したエラーの識別子と、当該エラーの発生時における前記被インストール装置の第１の構成データと、前記エラーの解消時における前記被インストール装置の第２の構成データとを取得する取得部と、
   前記ソフトウエアの識別子に対応付けて格納部に前記ソフトウエアのインストール時に行うべき対処ステップを含む既存の対処データが格納されている場合には、当該既存の対処データと前記第１の構成データ及び前記第２の構成データとに基づき、前記ソフトウエアの識別子及び前記エラーの識別子に対応する対処データを更新し、前記格納部に前記既存の対処データが格納されていない場合には、前記第１の構成データ及び前記第２の構成データとの差分から対処データを生成し、前記ソフトウエアの識別子及び前記エラーの識別子に対応付けて前記格納部に格納する更新部と、
   を有する情報処理装置。

Images