JP2011118575A - 障害対策情報取得方法および管理サーバ - Google Patents

Abstract

【課題】Ｗｅｂサイトから商用ソフトウェアやオープンソースソフトウェアに関する最新の障害情報を入手し、その情報を元にタイムリーに更新され続けるデータベースを活用することで、システムで発生している障害の原因・対策情報を導き出すことができる障害対策情報導出方法を提供する。
【解決手段】障害情報Ｗｅｂサイト１２２から収集した障害情報を持つサイト情報ＤＢ１１７と、障害のカテゴリごとに原因究明に有効な情報が公開されているＷｅｂサイトの情報を持つ原因候補ＤＢ１１６を参照して、システム１２０の状態確認で得られた情報を情報導出用キーワードとして、障害の原因・対策情報を導き出す。また、障害情報Ｗｅｂサイト１２２の情報が更新された場合に、サイト情報ＤＢ１１７に登録されている情報を合わせて更新することで、データベースの内容を最新の状態に保つ。
【選択図】図１

Description

本発明は、システムにおける障害の原因や対策の情報を取得する障害対策情報取得方法および管理サーバに関するものである。

システム管理者（以下、管理者という。）は、システムに障害が発生した際に障害の原因と対策を割り出し、効率良く対処することが求められる。熟練した管理者であれば、エラー内容やシステムリソースの使用状況から障害の内容を正確に読み取り対処することが可能だが、経験の浅い管理者の場合は原因および対策を素早く導き出すことは難しい。

こういった場合、管理者は、あらかじめ用意されたシステムの状態確認手順を実行し、得られた情報を既知の障害情報データベースと照らし合わせて、システムで発生している障害の原因と対策を明らかにするという方法が考えられる。これを自動化する従来技術として、特許文献１には、障害発生時の原因を特定するための確認項目情報を取得し、各項目情報に示された条件を満たすオブジェクトについて推定原因情報をデータベースから読み出す方法が記載されている。

特開２００７−１４８７２８号公報

特許文献１の技術は、システムの状態を確認して既知の原因情報の中から合致すると思われる情報を導き出す技術であるが、原因情報の内容はデータベース構築時に一度だけ登録されるのみで、その後の情報の動的な追加や更新は考慮されていない。

特にオープンソースソフトウェアを使用するシステムの場合、様々な障害情報を提供するＷｅｂサイトでオープンソースソフトウェアに関する新規の障害報告が日々なされ、かつ既知情報が更新され続けているため、管理者は、最新の障害情報を日々チェックし、データベースを更新し続けなければならない。システムで扱うソフトウェアの種類が増えるほど、この作業量が膨大になり、管理者に大きな負担を強いることになる。

本発明は、前記の課題を解決するための発明であって、システムで発生している障害の原因・対策情報を適切に導き出すことができる障害対策情報導出方法および管理サーバを提供することを目的とする。

前記目的を達成するため、本発明は、Ｗｅｂサイトから収集した障害の原因・対策情報を持つデータベース（例えば、サイト情報ＤＢ１１７）と、障害のカテゴリごとに原因究明に有効なＷｅｂサイトの情報を持つデータベース（例えば、原因候補ＤＢ１１６）を参照して、システムの状態確認で得られた情報を情報導出用キーワードとして活用することで、障害の原因と対策を導き出すことを特徴とする。

また、Ｗｅｂサイトの情報が更新された場合に、データベースに登録されている情報を合わせて更新することで、データベースの内容を最新の状態に保つことができる。

本発明によれば、システムで発生している障害の原因・対策情報を適切に導き出すことができる。

本発明におけるシステム障害の原因・対策情報の管理システムの全体構成を示す図である。 管理対象となるシステムの構成内容を示す図である。 チェック項目一覧テーブルの構成内容を示す図である。 情報取得手順テーブルの構成内容を示す図である。 サイト取得情報テーブルの構成内容を示す図である。 取得情報格納テーブルの構成内容を示す図である。 静的情報ＤＢの構成内容を示す図である。 動的情報ＤＢの構成内容を示す図である。 原因候補ＤＢの構成内容を示す図である。 サイト情報ＤＢの構成内容を示す図である。 原因・対策情報を導き出す処理を示すフローチャートである。 ＤＢ更新部がサイト情報ＤＢを更新する処理と、原因・対策情報導出部がサイト情報ＤＢおよび原因候補ＤＢを参照して原因・対策情報を導き出す処理の流れを示す図である。 ＤＢ更新部がサイト情報ＤＢの更新処理を示すフローチャートである。 状態チェック部がシステムの状態変化をチェックする処理の一例を示すフローチャートである。 システム情報取得部が情報導出用キーワードを取得する処理の一例を示すフローチャートである。 原因・対策情報導出部が導き出した原因・対策情報のコンソール出力例を示す図である。

以下、本発明を実施するための形態について図面を用いて詳細に説明する。
図１は、本発明におけるシステム障害の原因・対策情報の管理システムの全体構成を示す図である。障害原因・対策情報の管理システムの制御の中心部は、管理サーバ１０２である。管理サーバ１０２は、メモリ１０３、プロセッサ１１８、外部記憶装置１３０（記憶部）、ＮＩＣ１１９がバス１３１を介して接続されており、コンソール１０１を有している。なお、ＮＩＣはNetwork Interface Cardの略である。また、コンソール１０１とは、管理サーバ１０２を操作するために使う入出力装置のセットであり、ディスプレイなどの表示装置、キーボードなどの入力装置で構成される。

外部記憶装置１３０には、静的情報ＤＢ１１４（図７参照）、動的情報ＤＢ１１５（図８参照）、原因候補ＤＢ１１６（図９参照）、サイト情報ＤＢ１１７（図１０参照）が記憶されている。なお、ＤＢはData Baseの略である。

メモリ１０３には、原因・対策情報取得機構部１０４、テーブル群１０９が記憶されている。原因・対策情報取得機構部１０４は、ＤＢ更新部１０５、状態チェック部１０６、システム情報取得部１０７、原因・対策情報導出部１０８から構成される。テーブル群１０９は、チェック項目一覧テーブル１１０（図３参照）、情報取得手順テーブル１１１（図４参照）、サイト取得情報テーブル１１２（図５参照）、取得情報格納テーブル１１３（図６参照）を含んで構成される。なお、チェック項目一覧テーブル１１０、情報取得手順テーブル１１１、取得情報格納テーブル１１３は、外部記憶装置１３０に記憶しておき、必要に応じてメモリ１０３に読み出して格納してもよい。

管理サーバ１０２は、ネットワーク２０５を介して、複数のシステム１２０、複数の障害情報Ｗｅｂサイト１２２（障害情報提供サイト）と接続されている。システム１２０は、例えば、業務システムであり、システムエージェント１２１を有している。システムエージェント１２１は、システム１２０に常駐して、ＯＳ（Operating System）種別やインストール済みアプリケーション名、設定パラメータなどシステム１２０における静的情報、およびＣＰＵ（Central Processing Unit）利用率やメモリ利用率などシステム１２０における動的情報を取得し、管理サーバ１０２のシステム情報取得部１０７に送信する。

ＤＢ更新部１０５は、ソフトウェアで発生する障害の原因や対策、影響の深刻度、影響するバージョンなどの情報を掲載しており、Ｗｅｂサイト検索用キーワードによる情報検索機能を提供する障害情報Ｗｅｂサイト１２２から収集した最新の障害の原因・対策情報を、サイト取得情報テーブル１１２に一時格納する。そして、サイト情報ＤＢ１１７に格納されている原因・対策情報との差分を抽出して、差分がある情報についてサイト情報ＤＢ１１７の内容を追加・更新した後にサイト取得情報テーブル１１２の内容を破棄する。

状態チェック部１０６は、静的情報ＤＢ１１４と動的情報ＤＢ１１５に格納されているシステム１２０の静的情報および動的情報について、チェック項目一覧テーブル１１０に格納されているチェック基準およびチェック方法に従ってチェックを実行し、障害発生と考えられる変化が確認された場合は内容に応じたフラグを立てる。なお、静的情報および動的情報についてのチェック基準およびチェック方法を格納したチェック項目一覧テーブル１１０があらかじめ構築済みであるものとする。

システム情報取得部１０７は、システムエージェント１２１から受信したシステム１２０の静的情報、動的情報をそれぞれ静的情報ＤＢ１１４と動的情報ＤＢ１１５に格納する。また、システム情報取得部１０７は、原因・対策情報導出部１０８がシステム１２０で発生している障害の原因・対策情報を導き出すために必要な情報を、情報取得手順テーブル１１１に格納されている取得手順に従って、システムエージェント１２１を介してシステム１２０から取得する。なお、情報の取得手順を格納した情報取得手順テーブル１１１があらかじめ構築済みであるものとする。

原因・対策情報導出部１０８は、システム１２０で発生している障害の原因・対策情報を、原因候補ＤＢ１１６とサイト情報ＤＢ１１７を参照して抽出し、取得情報格納テーブル１１３に格納する。取得情報格納テーブル１１３に格納された障害の原因・対策情報は、抽出処理が完了した後にコンソール１０１に出力される。

原因候補ＤＢ１１６には、障害の概要を表す概要キーワードと、その障害に関する情報を収集する上で有効であると考えられる障害情報Ｗｅｂサイト１２２の名前、障害の原因・対策情報を得るのに、何階層までチェックすれば必要な情報が揃うかを示す値（探索深度９０４）が登録されている。探索深度９０４については、図９において後述する。なお、これらの情報を格納した原因候補ＤＢ１１６があらかじめ構築済みであるものとする。

サイト情報ＤＢ１１７には、情報を収集したサイト名とＵＲＬ（Uniform Resource Locator）、障害の概要を表す概要キーワード、その障害について障害情報Ｗｅｂサイト１２２から抽出した原因・対策情報、それらの原因・対策情報をいくつ参照すれば必要十分な情報量が得られるかを示す数値（チェック候補数）が登録されている。なお、これらの情報を格納したサイト情報ＤＢ１１７があらかじめ構築済みであるものとする。

本実施形態は、システム１２０で発生した障害の原因・対策情報を、障害情報Ｗｅｂサイト１２２から収集した原因・対策情報の中から抽出して、取得情報格納テーブル１１３に格納し、格納した情報をコンソール１０１に出力する機能を、管理者に提供する。

図２は、管理対象となるシステムの構成内容を示す図である。システム１２０は、メモリ２０１、プロセッサ２０３、ＮＩＣ２０４がバス２１０を介して接続されている。メモリ２０１には、例えば、業務システムで使用するアプリケーション２０２、システムエージェント１２１が記憶されている。

図３は、チェック項目一覧テーブルの構成内容を示す図である。図３には、システム１２０に障害が発生しているかを確認する基準と方法を格納する、チェック項目一覧テーブル１１０の構成内容を示している。チェック項目一覧テーブル１１０は、項目３０１、項番１（＃１）のカラム３０２、項番２（＃２）のカラム３０３、および項番３（＃３）以降のカラムから構成される。項目３０１には、メモリやＣＰＵなど、システム１２０についてチェックする内容の大枠を示す概要キーワードが登録されている。項番１のカラム３０２、項番２のカラム３０３、および項番３以降のカラムには、システム１２０からシステムエージェント１２１が取得した情報を元に、システム１２０に障害が発生しているかをチェックする基準とチェック方法が登録されている。

例えば、項目３０１のメモリにおける項番１（＃１）は、ＰＳ（Process Status）コマンドを実行することにより、メモリリソースを９０％以上占有しているプロセスがあるか否かをチェックすることを意味する。

図４は、情報取得手順テーブルの構成内容を示す図である。図４には、システム１２０で発生している障害に関する情報の取得方法を格納する、情報取得手順テーブル１１１の構成内容を示している。情報取得手順テーブル１１１は、項目４０１、現象４０２、情報取得手順４０３から構成される。項目４０１には、メモリやＣＰＵなど、情報を取得する対象を示す「概要キーワード」が登録されている。現象４０２には、システム１２０に障害が発生しているかをチェックした際に、確認された障害に対応して立てるフラグの内容が登録されている。情報取得手順４０３には、現象４０２に登録されているフラグが立てられた場合に、障害の原因・対策情報を導き出す処理で必要になる「情報導出用キーワード」を取得する手順が登録されている。

図５は、サイト取得情報テーブルの構成内容を示す図である。図５には、障害情報Ｗｅｂサイト１２２から取得した障害情報を格納する、サイト取得情報テーブル１１２の構成内容を示している。サイト取得情報テーブル１１２は、サイト名５０１、Ｗｅｂサイト検索用キーワード５０２、項番１（＃１）のカラム５０３、および項番２（＃２）以降のカラムから構成される。サイト名５０１には、障害情報を取得した障害情報Ｗｅｂサイト１２２の名前を登録する。Ｗｅｂサイト検索用キーワード５０２には、サイト名５０１に登録されているＷｅｂサイトで障害情報を取得する際の検索実行時に使用した単語を登録する。項番１のカラム５０３、および項番２以降のカラムには、Ｗｅｂサイト検索用キーワード５０２に登録されている単語でＷｅｂサイトを検索した結果、収集した障害の内容および原因・対策情報を登録する。なお、サイト取得情報テーブル１１２は初期状態では情報が格納されておらず、ＤＢ更新部１０５が障害情報Ｗｅｂサイト１２２にアクセスして障害情報を取得した際に、取得した情報が格納される。

図６は、取得情報格納テーブルの構成内容を示す図である。図６には、原因・対策情報導出部１０８が導き出した障害の原因・対策情報を格納する、取得情報格納テーブル１１３の構成内容を示している。取得情報格納テーブル１１３は、項番６０１、現象６０２、原因・対策情報候補１のカラム６０３、原因・対策情報候補２のカラム６０４、および原因・対策情報候補３以降のカラムから構成される。現象６０２には、サイト情報ＤＢ１１７（図１０参照）の現象１００４から抽出した障害の内容を登録する。原因・対策情報候補１のカラム６０３、原因・対策情報候補２のカラム６０４、および原因・対策情報候補３以降のカラムには、サイト情報ＤＢ１１７（図１０参照）の原因・対策情報候補１のカラム１００５、原因・対策情報候補２のカラム１００６、および原因・対策情報候補３以降のカラムから抽出した障害の原因・対策情報を登録する。なお、取得情報格納テーブル１１３は、初期状態では情報が格納されておらず、原因・対策情報導出部１０８が障害の原因・対策情報を抽出した際に、抽出した情報が格納される。

図７は、静的情報ＤＢの構成内容を示す図である。図７には、システム１２０の静的情報を格納する、静的情報ＤＢ１１４の構成内容を示している。静的情報ＤＢ１１４は、システムＩＤ７０１、ＯＳ種別７０２、インストールアプリ７０３、設定パラメータ７０４、およびその他の静的情報を格納するカラムから構成される。

図８は、動的情報ＤＢの構成内容を示す図である。図８には、システム１２０の動的情報を格納する、動的情報ＤＢ１１５の構成内容を示している。動的情報ＤＢ１１５は、システムＩＤ８０１、ＣＰＵ使用率８０２、メモリ使用率８０３、Ｉ／Ｏ状態８０４、ログ情報８０５、およびその他の動的情報を格納するカラムから構成される。ＣＰＵ使用率８０２およびメモリ使用率８０３には、時系列のデータを折れ線グラフで登録される。なお、Ｉ／ＯはInput/Outputの略である。

図９は、原因候補ＤＢの構成内容を示す図である。図９には、障害の原因・対策情報を取得するために有効な障害情報Ｗｅｂサイト１２２の情報を格納する、原因候補ＤＢ１１６の構成内容を示している。原因候補ＤＢ１１６は、原因候補９０１、優先度１のカラム９０２、優先度２のカラム９０３、および優先度３以降のカラム、探索深度９０４から構成される。原因候補９０１には、システム１２０で発生した障害の内容に関連する概要キーワードが登録されている。優先度１のカラム９０２、優先度２のカラム９０３、および優先度３以降のカラムには、原因候補９０１の概要キーワードに関連する障害の原因・対策情報を収集するために有効な障害情報Ｗｅｂサイト１２２の名前が登録されている。

探索深度９０４には、原因候補９０１の概要キーワードに関連する障害の原因・対策情報について、何階層までチェックすれば必要な情報が揃うかを示す値が登録されている。ここでいう「階層」とは、処理の観点から言えば、原因候補ＤＢ１１６およびサイト情報ＤＢ１１７を参照して、どれだけ深く掘り下げたか、ということを意味する。具体的な説明は、図１２を参照して後述する。

図１０は、サイト情報ＤＢの構成内容を示す図である。図１０には、障害情報Ｗｅｂサイト１２２から収集した障害の原因・対策情報を格納する、サイト情報ＤＢ１１７の構成内容を示している。サイト情報ＤＢ１１７は、サイト名１００１、ＵＲＬ１００２、原因ＩＤ１００３、現象１００４、原因・対策情報候補１のカラム１００５、原因・対策情報候補２のカラム１００６、および原因・対策情報候補３以降のカラムから構成される。

サイト名１００１には、障害情報Ｗｅｂサイト１２２の中から情報を収集したＷｅｂサイトの名前が登録されている。ＵＲＬ１００２には、サイト名１００１で示すＷｅｂサイトのＵＲＬが登録されている。原因ＩＤ１００３には、サイト情報ＤＢ１１７に登録されている情報の項番が登録されている。

現象１００４にはシステム１２０で発生した障害の内容および障害を表す概要キーワードと、チェック候補数が登録されている。チェック候補数は、概要キーワードに関連する障害についてサイト情報ＤＢ１１７に登録されている原因・対策情報を何個チェックすれば、必要な情報が揃うかを示す値である。この値は、過去に障害情報Ｗｅｂサイト１２２で障害の原因・対策情報を検索した際の経験則から割り出したものであり、且つ正しい数値であるという前提の元に、前提のサイト情報ＤＢ１１７の構築時に概要キーワードごとにあらかじめ設定している。

原因・対策情報候補１のカラム１００５、原因・対策情報候補２のカラム１００６、および原因・対策情報候補３以降のカラムには、障害の原因を表す概要キーワードと、１つ以上の原因・対策情報および原因・対策情報の重み値（重み）、チェック候補数が登録されている。原因・対策情報の重み値は、障害情報Ｗｅｂサイト１２２に内容が公開されてから１ヶ月未満の情報は３、１ヶ月以上２ヶ月未満の情報は２、２ヶ月以上の情報は１とする。これらの値は、障害情報Ｗｅｂサイト１２２に公開されている障害の原因・対策情報の中で、より新しい情報ほど緊急度が高く、注目すべきであるという前提を元に設定している。

次に各種処理について説明する。
図１１は、原因・対策情報を導き出す処理を示すフローチャートである。ステップＳ１１０１において、ＤＢ更新部１０５は、障害情報Ｗｅｂサイト１２２に公開されている障害の内容および原因・対策情報を収集して、サイト情報ＤＢ１１７に登録されている内容と照合し、差分がある場合はサイト情報ＤＢ１１７に登録されている内容を最新の情報に更新する。ステップＳ１１０１の詳細は図１３を参照して後述する。

ステップＳ１１０２において、状態チェック部１０６は、チェック項目一覧テーブル１１０を参照して静的情報ＤＢ１１４と動的情報ＤＢ１１５に格納されている情報をチェックし、障害発生と考えられる変化がシステム１２０上で起こっているかを確認する。ステップＳ１１０２の詳細は図１４を参照して後述する。

ステップＳ１１０３において、状態チェック部１０６は、システム１２０上で障害発生と考えられる変化が起こっているか判定する。変化がない場合（ステップＳ１１０３，Ｎｏ）、処理を終了する。変化がある場合（ステップＳ１１０３，Ｙｅｓ）、ステップＳ１１０４において、システム情報取得部１０７は、変化の内容に合わせたフラグを立て、情報取得手順テーブル１１１を参照して、静的情報ＤＢ１１４と動的情報ＤＢ１１５からフラグに応じた情報導出用キーワードを取得する。

ステップＳ１１０５において、システム情報取得部１０７は、必要となる全ての情報導出用キーワードが静的情報ＤＢ１１４と動的情報ＤＢ１１５から取得済みであるか判定する。取得済みの場合（ステップＳ１１０５，Ｙｅｓ）、ステップＳ１１０７に進む。

取得済みでない場合（ステップＳ１１０５，Ｎｏ）、ステップＳ１１０６において、システム情報取得部１０７は、システムエージェント１２１を介してシステム１２０から情報を収集し、不足分（未取得）の情報導出用キーワードを取得する。ステップＳ１１０６の詳細は図１５を参照して後述する。

ステップＳ１１０７において、原因・対策情報導出部１０８は、取得した情報導出用キーワードを元に原因候補ＤＢ１１６（図９参照）を参照して、システム１２０で発生した障害の原因・対策情報を取得するために有効（原因究明に有効）な障害情報Ｗｅｂサイト１２２を判別する。

ステップＳ１１０８において、原因・対策情報導出部１０８は、システム１２０で発生した現象の障害の原因・対策情報を、ステップＳ１１０７で判別した障害情報Ｗｅｂサイト１２２から収集した障害情報で構築されたサイト情報ＤＢ１１７（図１０参照）に登録されている原因・対策情報候補１のカラム１００５、原因・対策情報候補２のカラム１００６、および原因・対策情報候補３以降のカラムから取得し、取得情報格納テーブル１１３に格納する。

ステップＳ１１０９において、システム情報取得部１０７は、次順の原因候補の情報導出用キーワードを取得する。

ステップＳ１１１０において、原因・対策情報導出部１０８は、システム１２０で発生した障害の原因・対策情報の取得処理が、原因候補ＤＢ１１６から取得した探索深度９０４の最大値に未達かを判定する。取得した探索深度９０４の最大値に未達でない場合（ステップＳ１１１０，Ｎｏ）、ステップＳ１１１３に進む。探索深度９０４の最大値に未達である場合（ステップＳ１１１０，Ｙｅｓ）、ステップＳ１１１１に進む。

ステップＳ１１１１において、原因・対策情報導出部１０８は、システム１２０で発生した障害の原因・対策情報の取得処理が、サイト情報ＤＢ１１７の現象１００４、原因・対策情報候補１のカラム１００５、原因・対策情報候補２のカラム１００６、および原因・対策情報候補３以降のカラムに登録されているチェック候補数の最大値に対して未達であるかを判定する。チェック候補数の最大値に未達でない場合（ステップＳ１１１１，Ｎｏ）、ステップＳ１１１３に進む。チェック候補数の最大値に未達である場合（ステップＳ１１１１，Ｙｅｓ）、ステップＳ１１１２に進む。

ステップＳ１１１２において、追加取得可能な情報がないかを判定する。具体的には、ステップＳ１１０９において、次順の原因候補の情報導出用キーワードがあったか否かを判定する。追加取得可能な情報がなかった場合（ステップＳ１１１２，Ｙｅｓ）、ステップＳ１１１３に進む。追加取得可能な情報があった場合（ステップＳ１１１２，Ｎｏ）、ステップＳ１１０５に戻る。

ステップＳ１１１３において、原因・対策情報導出部１０８は、原因・対策情報の取得処理を完了し、取得情報格納テーブル１１３に格納された情報をコンソール１０１に出力して処理を終了する。

図１１に示した各ステップ、特に、ステップＳ１１０１からステップＳ１１０７の具体例について、さらに説明する。ステップＳ１１０１において、ＤＢ更新部１０５により、Ｗｅｂ公開済みの最新の障害内容および原因・対策情報を取得して、サイト情報ＤＢ１１７に反映する。ステップＳ１１０２において、状態チェック部１０６により、障害発生と考えられる変化（メモリ使用率の異常な増加など）が、システム１２０に発生していないかチェックする。チェック対象は、静的情報ＤＢ１１４（図７参照）と動的情報ＤＢ１１５（図８参照）であり、チェック内容はチェック項目一覧テーブル１１０（図３参照）の内容に従う。ステップＳ１１０３において、状態チェック部１０６により、状態変化の有無を判定する。

ステップＳ１１０４において、システム情報取得部１０７により、変化がある場合、フラグ（メモリ使用率増大、など）を立ててフラグをキーとして情報導出用キーワードの取得を開始する。情報の取得元は、静的情報ＤＢ１１４および動的情報ＤＢ１１５である。

「メモリ使用率の増大」のフラグＡが立った場合の例（図１４参照）では、情報取得手順テーブル１１１の内容に従い、以下の情報を、情報導出用キーワードとして取得する。
・メモリを占有しているプロセス名
・該当するプロセスのログファイル中に含まれるエラーに関連するメッセージ
前記の２つの情報は、図８に示す「メモリ使用率」の現時点でもっともメモリを占有しているプロセス名と、「ログ情報」の中で該当するプロセスのログの中から取得することになる。プロセス名の絞り込み方法、およびログの中からメッセージを抽出する方法については、情報取得手順テーブル１１１の内容に従うことになる。なお、この例では、図７には取得対象の情報がないため何も取得しないことになる。

ステップＳ１１０５において、システム情報取得部１０７により、情報取得手順テーブル１１１（図４参照）に記載されている、「フラグＡに対応する情報導出用キーワード」が全て取得済みかチェックする。メモリ使用率増大のフラグＡの場合は、「メモリを占有しているプロセス名」と「プロセスのログ中のエラーメッセージ」が対象となる。

ステップＳ１１０６において、静的情報ＤＢ１１４および動的情報ＤＢ１１５から情報導出用キーワードを全て取得できていない場合、システム情報取得部１０７は、システムエージェント１２１を介して不足している情報導出用キーワードを新たに取得する。取得する情報および取得方法は、情報取得手順テーブル１１１の内容に従う。ステップＳ１１０６の詳細については後述する（図１５参照）。

そして、ステップＳ１１０７以降において、取得した情報導出用キーワードを元に原因・対策情報を収集することになる。ステップＳ１１０８から処理内容の具体例については、図１２のステップＳ１２０２およびステップＳ１２０３において説明する。

図１２は、ＤＢ更新部がサイト情報ＤＢを更新する処理と、原因・対策情報導出部がサイト情報ＤＢおよび原因候補ＤＢを参照して原因・対策情報を導き出す処理の流れを示す図である。すなわち、図１２には、原因候補ＤＢ１１６およびサイト情報ＤＢ１１７を交互に参照して、システム１２０で発生した障害の原因・対策情報を導き出す処理の流れを示している。サイト情報ＤＢ１１７は、複数のサイト情報ＤＢがあり、具体的には、サイトＡ情報ＤＢ（１１７Ａ）、サイトＢ情報ＤＢ（１１７Ｂ）、サイトＣ情報ＤＢ（１１７Ｃ）、・・・がある。

まず、ＤＢ更新部１０５は、サイト情報ＤＢ１１７に登録されている原因・対策情報の更新処理を実行する。ＤＢ更新部１０５は、障害情報Ｗｅｂサイト１２２にアクセスして、Ｗｅｂサイトに公開されている最新の障害原因・対策情報を取得し、サイト取得情報格納テーブル１１２（図５参照）に格納する。

次に、ＤＢ更新部１０５は、サイト取得情報テーブル１１２に一時格納した原因・対策情報と、サイト情報ＤＢ１１７（図１０参照）の原因・対策情報候補１のカラム１００５、原因・対策情報候補２のカラム１００６、および原因・対策情報候補３以降のカラムとの内容を比較して、差分がある場合は、差分のあるカラムの内容をサイト取得情報テーブル１１２の中の該当する内容で更新する。

このとき、ステップＳ１２０１において、原因・対策情報候補１のカラム１００５、原因・対策情報候補２のカラム１００６、および原因・対策情報候補３以降の、各カラムに登録されている原因・対策情報の数（員数）、または、各カラムに登録されている各原因・対策情報の重み値の合計が大きい原因候補は、現象１００４の概要キーワードで表す障害の原因である可能性が高いものと見なし、順序を並び替える。なお、各原因・対策情報の重み値の合計とは、図１２の例においては、各カラムにひとつの原因・対策情報しか表示していないが、ひとつのカラムに複数の原因・対策情報がはいっている場合がある。この場合、各原因・対策情報の重み値を合計することを意味する。

例として、サイトＡ情報ＤＢ（１１７Ａ）で概要キーワード「セマフォ」で表される原因・対策情報と、概要キーワード「ＯＳ障害」で表される原因・対策情報を比較すると、登録されている原因・対策情報の数はどちらも１だが、割り当てられている重み値は３と１で異なる。このため、サイトＡ情報ＤＢ（１１７Ａ）の内容が更新された時点で概要キーワード「セマフォ」で表される原因・対策情報が原因・対策情報候補２のカラム１００６に、概要キーワード「ＯＳ障害」で表される原因・対策情報が原因・対策情報候補１のカラム１００５に格納されていた場合、重み値が大きい概要キーワード「セマフォ」で表される原因・対策情報が原因・対策情報候補１のカラム１００５に、重み値が小さい概要キーワード「ＯＳ障害」で表される原因・対策情報が原因・対策情報候補２のカラム１００６に格納されるように、並び替えが実行される。なお、「セマフォ」とは、並列に動作しているプロセス間で同期を取り、割り込み処理の制御を行う機構をいう。

並び替えの実行の際、「各カラムに登録されている原因・対策情報の数（員数）」と「各カラムに登録されている各原因・対策情報の重み値の合計」とが、相反する場合がある。例えば、原因・対策情報候補１のカラム１００５には、員数が３であるが、その重み値が３（＝１＋１＋１）であり、原因・対策情報候補２のカラム１００６には、員数が２であるが、その重み値が４（＝３＋１）である。このときには、「各カラムに登録されている各原因・対策情報の重み値の合計」を優先適用するとよい。

次に、原因・対策情報導出部１０８は、システム１２０で障害が発生した場合に、障害の原因と対策を導き出す処理を実行する。システム情報取得部１０７は、障害の原因と対策を導き出すために必要となる情報導出用キーワードを、静的情報ＤＢ１１４、動的情報ＤＢ１１５、システムエージェント１２１を介して取得する。

続けて、ステップＳ１２０２で、システム情報取得部１０７は、原因候補９０１の中から情報導出用キーワードと一致するものを検索し、一致した原因候補９０１に対応する優先度１のカラム９０２、優先度２のカラム９０３、および優先度３以降のカラムに登録されている障害情報Ｗｅｂサイト１２２の情報を、サイト情報ＤＢ１１７から収集する。この時点では探索深度は０である。

情報導出用キーワードが「Ｗｅｂサーバ（例えば、Ａｐａｃｈｅ）」、「ｓｔａｒｔ ｆａｉｌｅｄ」の場合、原因候補ＤＢ１１６の「Ｗｅｂサーバ」の行を参照して、優先度１のサイトＡを情報の収集先とする。情報の収集先がサイトＡの場合、現象１００４の中からあらかじめ取得済みの情報導出用キーワードと一致するものを検索し、一致した現象１００４に対応する原因・対策情報候補１のカラム１００５、原因・対策情報候補２のカラム１００６、および原因・対策情報候補３以降のカラムの内容を参照する。ここで参照する原因候補の数は、現象１００４のチェック候補数に従う。まず先頭の原因・対策情報候補１のカラム１００５に登録されている原因・対策情報を参照し、原因・対策情報と現象１００４に登録されている現象の内容を、取得情報格納テーブル１１３に格納する。このときの「Ｗｅｂサーバ」の探索深度は１である。

同様に、原因候補ＤＢ１１６の「Ｗｅｂサーバ」の行を参照して、優先度２のサイトＤを情報の収集先とする。このときの「Ｗｅｂサーバ」の探索深度は１のままである。

次に、システム情報取得部１０７は、原因・対策情報候補１のカラム１００５に登録されている概要キーワードを参照して、その概要キーワードについて情報を収集するために必要な情報導出用キーワードを、情報取得手順テーブル１１１を参照して確認し、静的情報ＤＢ１１４と動的情報ＤＢ１１５から取得する。必要な情報導出用キーワードが静的情報ＤＢ１１４や動的情報ＤＢ１１５から取得できなかった場合は、システム情報取得部１０７がシステムエージェント１２１を介して、情報を新規取得する。

具体的には、原因・対策情報候補１のカラム１００５に登録されている概要キーワードは、「セマフォ」であり、システム情報取得部１０７は、図４に示す項目４０１が「セマフォ」となっている部分を参照し、該当する情報取得手順４０３に従い、静的情報ＤＢ１１４と動的情報ＤＢ１１５から、必要な情報導出用キーワードを取得する。あるいは、システム情報取得部１０７が、システムエージェント１２１を介して必要な情報導出用キーワードを新規取得することになる。

なお、図７および図８に記載されている項目は一例であり、記載例以外に何種類もの項目が用意されている。「セマフォ」などいくつもの概要キーワードに対応する項目がある。その後、図９に示す原因候補ＤＢ１１６の原因候補９０１が「セマフォ」となっているサイトのサイト情報ＤＢ１１７を参照し、その中で現象１００４に、情報導出用キーワードと合致する原因・対策情報を収集することになる。

すなわち、必要な情報導出用キーワードを全て取得完了後、ステップＳ１２０３において、原因・対策情報導出部１０８は、原因候補９０１の中で原因・対策情報候補１のカラム１００５に登録されている概要キーワードと一致するものを検索し、一致した原因候補９０１に対応する優先度１のカラム９０２、優先度２のカラム９０３、および優先度３以降のカラムに登録されている障害情報Ｗｅｂサイト１２２の情報を、サイト情報ＤＢ１１７から収集する。このときの「Ｗｅｂサーバ」の探索深度は２となる。

探索深度について、図１２の例をさらに詳細に説明する。まず、原因候補ＤＢ１１６の「Ｗｅｂサーバ」という情報導出用キーワードで該当する行を参照し、サイトＡ、サイトＤなどの情報を格納したサイト情報から、原因・対策情報候補を取得する。この時点で、探索深度は１になる。続けて、原因・対策情報候補１に登録されている概要キーワード「セマフォ」、原因・対策情報候補２に登録されている「ＯＳ障害」を元に、再び原因候補ＤＢ１１６を参照する。「セマフォ」であれば、サイトＢ、サイトＥなどの情報を格納したサイト情報ＤＢ１１７から原因・対策情報候補を取得する。同様に、「ＯＳ障害」であれば、サイトＣ、サイトＦなどの情報を格納したサイト情報から原因・対策情報候補を取得する。この時点で、探索深度は２になる。

つまり、最初に参照した「Ｗｅｂサーバ」の欄が探索深度１であり、探索深度１のサイトから取得した情報を元に、更に派生情報を取得すべく参照した「セマフォ」や「ＯＳ障害」の欄が探索深度２となる。探索深度２のサイトから取得した情報を元に、更に派生情報を取得しに参照した欄が探索深度３というようにカウントしていく。こうして掘り下げを続けていき、探索深度１の欄に登録されている最初の原因候補（例えば、Ｗｅｂサーバ）の探索深度９０４（ここでは、１０）に到達するまで、原則として掘り下げを行うことになる。

一方、ここで、原因・対策情報候補１のカラム１００５に登録されている概要キーワードに関連する情報をサイト情報ＤＢ１１７から収集する際に、参照する原因候補の数は、原因・対策情報候補１のカラム１００５に登録されているチェック候補数に従う。具体的には、図１２の例のチェック候補数は、「start failed」の場合は「３」、「セマフォ」の場合は「２」、「ＯＳ障害」の場合は「１」である。

これらの、原因候補ＤＢ１１６とサイト情報ＤＢ１１７を交互に参照する処理を、探索深度９０４に登録されている探索深度の最大値に達するまで（図１１のステップＳ１１１０，Ｎｏに相当）、あるいは、チェック候補数の最大値に達するまで（図１１のステップＳ１１１１，Ｎｏに相当）まで繰り返し、最終的に取得情報格納テーブル１１３に格納された情報をコンソール１０１に出力する。なお、図１２の例のステップＳ１１１０の探索深度の最大値は「１０」で変化はしないが、ステップＳ１１１１のチェック候補数の最大値は、「ｓｔａｒｔ ｆａｉｌｅｄ」の場合は「３」、「セマフォ」の場合は「２」、「ＯＳ障害」の場合は「１」と変化する。

また、ステップＳ１１１２において、複数の情報導出用キーワード（例えば、「セマフォ」、「ＯＳ障害」）があり、追加取得可能な情報があると判定された場合（ステップＳ１１１２、Ｎｏ）、優先度１として「セマフォ」、優先度２として、「ＯＳ障害」とする。複数の情報導出用キーワードに対して、それぞれ、図１１の以下の処理ステップＳ１１０５からステップＳ１１１２を繰り返すことになる。なお、図１１の処理フローは、処理の流れをわかりやすくするため、単一の情報導出用キーワードに対しての処理フローとして、示している。

図１３は、ＤＢ更新部がサイト情報ＤＢの更新処理を示すフローチャートである。図１３には、サイト情報ＤＢ１１７に登録されている情報の更新処理の流れを示している。ステップＳ１３０１において、ＤＢ更新部１０５は、最初に、サイト情報ＤＢ１１７のＵＲＬ１００２（図１０参照）を参照してＵＲＬ情報を取得する。ステップＳ１３０２において、ＤＢ更新部１０５は、ステップＳ１３０１で取得したＵＲＬの障害情報Ｗｅｂサイト１２２にアクセスする。

ステップＳ１３０３において、ＤＢ更新部１０５は、サイトで公開されている障害情報の中から、サイト取得情報テーブル１１２（図５参照）のＷｅｂサイト検索用キーワード５０２に登録されている単語でヒットする障害の内容および原因・対策情報を抽出し、項番１のカラム５０３、および項番２以降のカラムに格納する。

ステップＳ１３０４において、ＤＢ更新部１０５は、サイト情報ＤＢ１１７（図１０参照）の原因・対策情報候補１のカラム１００５、原因・対策情報候補２のカラム１００６、および原因・対策情報候補３以降のカラムに登録されている情報と、サイト取得情報テーブル１１２（図５参照）の項番１のカラム５０３、および項番２以降のカラムに格納した情報とを照合する。

ステップＳ１３０５において、ＤＢ更新部１０５は、照合した情報に差分があるか判定する。差分がない場合（ステップＳ１３０５，Ｎｏ）、ステップＳ１３１０に進む。差分がある場合（ステップＳ１３０５，Ｙｅｓ）、ステップＳ１３０６において、該当する障害情報についてサイト情報ＤＢ１１７に登録されている内容を、サイト取得情報テーブル１１２に格納した内容で追記・更新する。

ステップＳ１３０７において、ＤＢ更新部１０５は、原因・対策情報候補１のカラム１００５、原因・対策情報候補２のカラム１００６、および原因・対策情報候補３以降のカラムに登録されている原因・対策情報の数（員数）または原因・対策情報の重み値の合計が、更新処理の前後で変更されたか判定する。変更されていない場合（ステップＳ１３０７，Ｎｏ）、ステップＳ１３０９に進む。変更されている場合（ステップＳ１３０７，Ｙｅｓ）、ステップＳ１３０８において、登録されている原因・対策情報の数、または、原因・対策情報の重み値の合計の降順に原因候補が並ぶよう、順序のソート処理を実行する。ステップＳ１３０８の詳細は図１２のステップＳ１２０１に示した。

ステップＳ１３０９において、ＤＢ更新部１０５は、差分のある全情報について更新済みか否かを判定する。すなわち、差分がある全ての情報について追記・更新処理およびソート処理が実行済みか判定する。実行済みでない場合（ステップＳ１３０９，Ｎｏ）、ステップＳ１３０６に戻る。実行済みの場合（ステップＳ１３０９，Ｙｅｓ）、ステップＳ１３１０に進む。

ステップＳ１３１０において、ＤＢ更新部１０５は、サイト取得情報テーブル１１２の内容を破棄する。そして、ステップＳ１３１１において、全Ｗｅｂサイトをチェック済みであるかを判定する。具体的には、サイトＡ、サイトＢ、サイトＣ、およびサイトＤ以降と、順に障害情報Ｗｅｂサイト１２２について、差分のチェック、追記・更新処理およびソート処理が実行済みか判定する。実行済みでない場合（ステップＳ１３１１，Ｎｏ）、ステップＳ１３０２に戻る。実行済みの場合（ステップＳ１３１１，Ｙｅｓ）、処理を終了する。

図１４は、状態チェック部がシステムの状態変化をチェックする処理の一例を示すフローチャートである。図１４には、メモリ使用率を判定するルーチンを例に、システム１２０の状態変化をチェックする処理の流れを示している。ステップＳ１４０１において、状態チェック部１０６は、静的情報ＤＢ１１４（図７参照）と動的情報ＤＢ１１５（図８参照）の内容を参照する。ステップＳ１４０２において、状態チェック部１０６は、チェック項目一覧テーブル１１０（図３参照）の内容を読み込む。

ステップＳ１４０３において、状態チェック部１０６は、ステップＳ１４０２で読み込んだチェック基準およびチェック方法に従い、システム１２０で障害が発生していないかをチェックする。図１４の例では、メモリ使用率に関するチェックとして、ステップＳ１４０４で「１プロセスにおけるメモリ使用率が９０％を超えるプロセスがあるか」を判定する。プロセスがない場合（ステップＳ１４０４，Ｎｏ）、ステップＳ１４０６に進む。プロセスがある場合（ステップＳ１４０４，Ｙｅｓ）、ステップＳ１４０５に進む。

ステップＳ１４０５において、状態チェック部１０６は、メモリ使用率の増大を示すフラグを立てる。ステップＳ１４０６において、状態チェック部１０６は、メモリに関する他のチェック項目、およびＣＰＵやＩ／Ｏなどに関するチェック項目について判定を実行する。全てのチェック項目について判定の実行およびフラグ立てを完了した時点で処理を終了する。

図１５は、システム情報取得部が情報導出用キーワードを取得する処理の一例を示すフローチャートである。図１５には、メモリ使用率に関する情報導出用キーワードを抽出するルーチンを例に、システムエージェント１２１がシステム１２０の状態をチェックして未取得の情報導出用キーワードを取得する処理の流れを示している。

ステップＳ１５０１において、システム情報取得部１０７は、原因候補ＤＢ１１６（図９参照）およびサイト情報ＤＢ１１７（図１０参照）を参照するために必要な情報導出用キーワードの中で、既に取得済みのものを確認する。図１５の例では必要な全ての情報導出用キーワードを取得していないため、ステップＳ１５０２において、システム情報取得部１０７は、情報取得手順テーブル１１１（図４参照）の内容を参照して、静的情報ＤＢ１１４と動的情報ＤＢ１１５に登録されていない情報導出用キーワードをシステム１２０から新たに取得するための手順を読み込む。

ステップＳ１５０３において、システム情報取得部１０７は、ステップＳ１５０２において読み込んだ手順に従い、未取得の情報導出用キーワードの取得を開始する。図１５の例では、ステップＳ１５０４において、メモリ使用率の増大を示すフラグが立っているか（フラグがＯＮか）を判定する。フラグが立っていない場合（ステップＳ１５０４，Ｎｏ）、ステップＳ１５１２に進む。フラグが立っている場合（ステップＳ１５０４，Ｙｅｓ）、ステップＳ１５０５において、システム情報取得部１０７は、メモリ使用率に関する情報を取得する処理を行い、この例では、ＰＳコマンドを実行してその結果からメモリリソースを多く占有しているプロセス名を特定する。

図１５の例では、ステップＳ１５０６において、システム情報取得部１０７は、ステップＳ１５０５において特定したプロセスがＷｅｂサーバのプロセスか判定する。Ｗｅｂサーバのプロセスでない場合（ステップＳ１５０６，Ｎｏ）、ステップＳ１５１１に進む。Ｗｅｂサーバのプロセスである場合（ステップＳ１５０６，Ｙｅｓ）、ステップＳ１５０７に進む。

ステップＳ１５０７において、システム情報取得部１０７は、Ｗｅｂサーバのログファイルにエラーメッセージが出力されているか検索する。図１５の例では、ステップＳ１５０８において、システム情報取得部１０７は、Ｗｅｂサーバのログファイルに“ｓｔａｒｔ ｆａｉｌｅｄ”の表記があるか判定する。表記がない場合（ステップＳ１５０８，Ｎｏ）、ステップＳ１５１０に進む。表記がある場合（ステップＳ１５０８，Ｙｅｓ）、ステップＳ１５０９に進む。

ステップＳ１５０９において、システム情報取得部１０７は、“Ｗｅｂサーバ名”と“ｓｔａｒｔ ｆａｉｌｅｄ”を情報導出用キーワードとして取得する。すなわち、具体的には、メモリ使用率増大のフラグが立っており、メモリを占有しているプロセスがＡｐａｃｈｅの場合、プロセス名（＝Ｗｅｂサーバ名）「Ａｐａｃｈｅ」と、Ａｐａｃｈｅのログに記載されているメモリ周りの障害に関連するエラーメッセージ（“ｓｔａｒｔ ｆａ
ｉｌｅｄ”）の２つが、情報導出用キーワードになる。

ステップＳ１５１０において、システム情報取得部１０７は、Ｗｅｂサーバのログファイルに、“ｓｔａｒｔ ｆａｉｌｅｄ”以外のエラーメッセージが出力されているか（別メッセージ）を検索する。

ステップＳ１５１１において、システム情報取得部１０７は、Ｗｅｂサーバ以外のプロセスについて調査を実行する（調査に移る）。ステップＳ１５１２において、システム情報取得部１０７は、メモリ使用率の増大を示すフラグ以外のフラグ（別フラグ）について調査を実行する（調査に移る）。そして、必要となる情報導出用キーワードを全て取得した時点で処理を終了する。

図１６は、原因・対策情報導出部が導き出した原因・対策情報のコンソールへの出力例を示す図である。図１６には、コンソール１０１に出力する内容の例を示している。原因・対策情報導出部１０８は、システム１２０で発生している障害の原因・対策情報を導き出した後に、取得情報格納テーブル１１３の内容をコンソール１０１に出力する。すなわち、障害原因・対策情報一覧の表が、コンソール１０１の表示装置に表示される。

本実施形態の管理サーバ１０２は、Ｗｅｂサイトから商用ソフトウェアやオープンソースソフトウェアに関する最新の障害情報を入手し、その情報を元にタイムリーに更新され続けるデータベースを活用することで、システム１２０で発生している障害の原因・対策情報を導き出すことができる。

具体的には、障害の現象として「Ｗｅｂサーバが起動しない」場合、原因・対策情報の第１の候補（候補１）として、「セマフォを開放していないため」と考えられ、その対策としては、「Ｗｅｂサーバの使用リソースを開放する」ことがわかる。また、原因・対策情報の第２の候補（候補２）として、「ＯＳに障害が発生しているため」と考えられ、その対策としては、「ＯＳを再起動する」ことがわかる。

図１６に示す例では、＃１に、最初に参照した「Ｗｅｂサーバ」の欄（探索深度１）であり、チェック候補数３であるため、原因・対策情報候補が最大３つ表示される。該当する原因・対策候補となる情報は２つであることが示されている。また、＃２および＃３に、探索深度１のサイトから取得した情報を元に、更に派生情報を取得すべく参照した「セマフォ」や「ＯＳ障害」の欄（探索深度２）であり、それぞれチェック候補数２およびチェック候補数１であるため、該当欄に、原因・対策情報候補が２つおよび原因・対策情報候補が１つ表示されている。

図１６に示すコンソール１０１の出力内容を表形式として示しているが、＃１の原因・対策情報候補に対し、次の原因・対策情報候補を示すツリー形式に表示してもよい。この場合、＃１の現象「Ｗｅｂサーバ・・・」のブロックと、複数の＃１の原因・対策情報候補のブロックとが連係し、＃１の原因・対策情報候補１の「セマフォ・・・」のブロックと、複数の＃２の原因・対策情報候補のブロックとが連係する。各ブロックをマウスなどでクリックすると詳細な原因・対策情報を表示するとよい。

本実施形態の障害対策情報導出方法は、運用しているシステム１２０と、障害情報を提供する障害情報Ｗｅｂサイト１２２（障害情報提供サイト）と、ネットワーク２０５を介して接続される管理サーバ１０２において、ＤＢ更新部１０５（データベース更新部）と、状態チェック部１０６（状態監視部）と、システム情報取得部１０７と、原因・対策情報導出部１０８とにより、システムの障害の原因・対策情報を障害情報提供サイトから取得し、障害の原因・対策情報の候補を導出する。

管理サーバ１０２は、システムの監視項目と、監視項目の監視方法とを含む監視項目一覧情報(例えば、チェック項目一覧テーブル１１０）と、システムの監視項目と、障害の現象と、障害の情報を導出のキーワードである情報導出用キーワードを取得する手順とを含む情報取得手順情報（例えば、情報取得手順テーブル１１１）と、障害情報提供サイトのサイト名、障害の現象、障害の原因・対策情報を格納するサイト情報（例えば、サイト情報ＤＢ１１７）と、原因候補と、探索する障害情報提供サイト名とを関連付ける原因候補情報（例えば、原因候補ＤＢ１１６）と、が記憶部（例えば、外部記憶装置１３０）に記憶されている。

ＤＢ更新部１０５は、障害情報提供サイトに公開されている障害の内容および原因・対策情報を収集して、サイト情報に登録されている内容と照合し、差分がある場合はサイト情報に登録されている内容を更新し（例えば、ステップＳ１１０１）、状態チェック部１０６は、システムから取得した静的情報（例えば、静的情報ＤＢ１１４）および動的情報（例えば、動的情報ＤＢ１１５）から、監視項目一覧情報に該当するものがあるか否かを判定し（例えば、ステップＳ１１０２）、システム情報取得部１０７は、情報取得手順情報に基づいて、システム１２０から情報を収集し、情報導出用キーワードを取得し（例えば、ステップ１１０４）、原因・対策情報導出部１０８は、原因候補情報から情報導出用キーワードに該当するサイトを特定し（例えば、ステップＳ１１０７）、サイト情報から特定されたサイトの情報導出用キーワードに該当する原因・対策情報の候補となる情報を取得する（例えば、ステップＳ１１０８）。

本実施形態の原因・対策情報導出部１０８は、原因・対策情報の候補となる情報の中に、現象に関連する関連情報の情報導出用キーワード（例えば、図１２の「セマフォ」）を抽出し、原因候補情報から関連情報の情報導出用キーワードに該当するサイトを特定し、サイト情報から特定されたサイトの情報導出用キーワードに該当する原因・対策情報の候補となる情報を取得する。

本実施形態の原因候補情報には、原因候補を探索する際の深さを表す探索深度の閾値（例えば、図９の探索深度９０４の値）が関連付けられており、原因・対策情報導出部１０８は、原因候補ごとの探索ごとに探索回数を加算し、探索深度の閾値に達するまで、原因・対策情報の候補となる情報を取得する（例えば、ステップＳ１１１０）。

本実施形態のサイト情報には、障害の現象を取得する際に、サイト情報に登録されている情報の中から参照する情報の員数（例えば、チェック候補数）が関連付けられており、原因・対策情報導出部１０８は、参照する情報の員数に達するまで、原因・対策情報の候補となる情報を取得する（例えば、ステップＳ１１１１）。

本実施形態のＤＢ更新部１０５は、サイト情報を更新する際に、更新する情報が障害情報提供サイトに内容が公開されてからの期間に応じて、原因・対策情報に関連付けて重み値を設定し、サイト情報における各サイトの障害の原因・対策情報の候補にあげられている原因・対策情報ごとの重み値の合計の降順に原因候補が並ぶように、原因・対策情報の候補の順序についてソート処理を実行する（例えば、ステップＳ１３０８）。

本実施形態では、Ｗｅｂサイトに公開されている障害情報の中から確度の高い情報を抽出することにより、システムに発生した障害の原因と対策を迅速かつ的確に導き出す効果がある。

１０１ コンソール
１０２ 管理サーバ
１０３ メモリ
１０４ 原因・対策情報取得機構部
１０５ ＤＢ更新部（データベース更新部）
１０６ 状態チェック部（状態監視部）
１０７ システム情報取得部
１０８ 原因・対策情報導出部
１０９ テーブル群
１１０ チェック項目一覧テーブル（監視項目一覧情報）
１１１ 情報取得手順テーブル（情報取得手順情報）
１１２ サイト取得情報テーブル
１１３ 取得情報格納テーブル
１１４ 静的情報ＤＢ（静的情報）
１１５ 動的情報ＤＢ（動的情報）
１１６ 原因候補ＤＢ（原因候補情報）
１１７ サイト情報ＤＢ（サイト情報）
１１８ プロセッサ
１１９ ＮＩＣ
１２０ システム
１２１ システムエージェント
１２２ 障害情報Ｗｅｂサイト（障害情報提供サイト）
１３０ 外部記憶装置（記憶部）
１３１ バス
２０５ ネットワーク
９０４ 探索深度

Claims (6)

1. 運用しているシステムと、障害情報を提供する障害情報提供サイトと、ネットワークを介して接続される管理サーバにおいて、データベース更新部と、状態監視部と、システム情報取得部と、原因・対策情報導出部とにより、前記システムの障害の原因・対策情報を前記障害情報提供サイトから取得し、前記障害の原因・対策情報の候補を導出する障害対策情報導出方法であって、
   前記管理サーバは、
   前記システムの監視項目と、前記監視項目の監視方法とを含む監視項目一覧情報と、
   前記システムの監視項目と、障害の現象と、前記障害の情報を導出のキーワードである情報導出用キーワードを取得する手順とを含む情報取得手順情報と、
   前記障害情報提供サイトのサイト名、前記障害の現象、前記障害の原因・対策情報を格納するサイト情報と、
   前記原因候補と、探索する障害情報提供サイト名とを関連付ける原因候補情報と、が記憶部に記憶されており、
   前記データベース更新部は、前記障害情報提供サイトに公開されている障害の内容および原因・対策情報を収集して、前記サイト情報に登録されている内容と照合し、差分がある場合は前記サイト情報に登録されている内容を更新し、
   前記状態監視部は、前記システムから取得した静的情報および動的情報から、前記監視項目一覧情報に該当するものがあるか否かを判定し、
   前記システム情報取得部は、前記情報取得手順情報に基づいて、前記システムから情報を収集し、前記情報導出用キーワードを取得し、
   前記原因・対策情報導出部は、前記原因候補情報から前記情報導出用キーワードに該当するサイトを特定し、前記サイト情報から前記特定されたサイトの前記情報導出用キーワードに該当する前記原因・対策情報の候補となる情報を取得する
   ことを特徴とする障害対策情報導出方法。
2. 前記原因・対策情報導出部は、前記原因・対策情報の候補となる情報の中に、前記現象に関連する関連情報の情報導出用キーワードを抽出し、前記原因候補情報から前記関連情報の情報導出用キーワードに該当するサイトを特定し、前記サイト情報から前記特定されたサイトの前記情報導出用キーワードに該当する前記原因・対策情報の候補となる情報を取得する
   ことを特徴とする請求項１に記載の障害対策情報導出方法。
3. 前記原因候補情報には、前記原因候補を探索する際の深さを表す探索深度の閾値が関連付けられており、
   前記原因・対策情報導出部は、前記原因候補ごとの探索ごとに探索回数を加算し、前記探索深度の閾値に達するまで、前記原因・対策情報の候補となる情報を取得する
   ことを特徴とする請求項２に記載の障害対策情報導出方法。
4. 前記サイト情報には、前記障害の現象を取得する際に、前記サイト情報に登録されている情報の中から参照する情報の員数が関連付けられており、
   前記原因・対策情報導出部は、前記参照する情報の員数に達するまで、前記原因・対策情報の候補となる情報を取得する
   ことを特徴とする請求項１に記載の障害対策情報導出方法。
5. 前記データベース更新部は、
   前記サイト情報を更新する際に、更新する情報が前記障害情報提供サイトに内容が公開されてからの期間に応じて、前記原因・対策情報に関連付けて重み値を設定し、
   前記サイト情報における各サイトの前記障害の原因・対策情報の候補にあげられている原因・対策情報ごとの前記重み値の合計の降順に原因候補が並ぶように、前記原因・対策情報の候補の順序についてソート処理を実行する
   ことを特徴とする請求項１に記載の障害対策情報導出方法。
6. 運用しているシステムと、障害情報を提供する障害情報提供サイトと、ネットワークを介して接続され、前記システムの障害の原因・対策情報を前記障害情報提供サイトから取得し、前記障害の原因・対策情報の候補を導出する管理サーバであって、
   前記システムの監視項目と、前記監視項目の監視方法とを含む監視項目一覧情報と、
   前記システムの監視項目と、障害の現象と、前記障害の情報を導出のキーワードである情報導出用キーワードを取得する手順とを含む情報取得手順情報と、
   前記障害情報提供サイトのサイト名、前記障害の現象、前記障害の原因・対策情報を格納するサイト情報と、
   前記原因候補と、探索する障害情報提供サイト名とを関連付ける原因候補情報と、を記憶した記憶部を有するとともに、
   前記障害情報提供サイトに公開されている障害の内容および原因・対策情報を収集して、前記サイト情報に登録されている内容と照合し、差分がある場合は前記サイト情報に登録されている内容を更新するデータベース更新部と、
   前記システムから取得した静的情報および動的情報から、前記監視項目一覧情報に該当するものがあるか否かを判定する状態監視部と、
   前記情報取得手順情報に基づいて、前記システムから情報を収集し、前記情報導出用キーワードを取得するシステム情報取得部と、
   前記原因候補情報から前記情報導出用キーワードに該当するサイトを特定し、前記サイト情報から前記特定されたサイトの前記情報導出用キーワードに該当する前記原因・対策情報の候補となる情報を取得する原因・対策情報導出部と、を有する
   ことを特徴とする管理サーバ。

Images