(57)【要約】【課題】従来の管理システムにおいて、障害が発生した場合、障害情報を実績として蓄積するために、障害受付担当者は問合せ者からの情報を元に障害情報を獲得し、不足情報がある場合はヒアリングによってその情報を取得する。また発生した現象に関して、環境に依存する問題であれば、問合せ者から構成情報を取得する。本発明は、障害情報が蓄積されたデータベースを効率よく活用する手段を提供する。【解決手段】類似事例を検索する際などに用いる中間ＤＢである関連ＤＢを作成し、関連ＤＢを対象に検索操作を行うことで、障害情報を効率よく活用する手段を提供する。【選択図】図１
2009043029.tif 000002
【特許請求の範囲】
【請求項１】
管理システムのマシン構成を管理する構成管理データと、管理システム内で発生した障害情報を管理する障害情報データを関連付けるデータ構造の生成方法。
【請求項２】
管理システム内で新規に発生した障害と、管理システム内で実績として記録されている障害情報データを関連付ける方法。
【請求項３】
類似言語の集合を格納した類似言語データを使用して、管理システム内で新規に発生した新規障害情報と、管理システム内で実績として記録されている障害情報データを、同一情報と判断する検索条件の拡張方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＴシステムで発生した事象を登録するシステムの既知情報を抽出するための手段である。
【背景技術】
【０００２】
従来の管理システムにおいて、障害が発生した場合、障害情報を実績として蓄積するために、障害受付担当者は問合せ者からの情報を元に障害情報を獲得し、不足情報がある場合はヒアリングによってその情報を取得する。また発生した現象に関して、環境に依存する問題であれば、問合せ者から構成情報を取得する。
【０００３】
格納された障害情報に関して、その現象の対応策である対処を調査することになるが、障害管理ＤＢに参考となる類似障害事例が蓄積されている可能性があるため、蓄積された障害情報から類似障害情報の検索を行う。検索処理はキーワード一致検索で行われる。検索結果で得られた類似障害事例に対して、人手で構成情報等を確認して候補の絞込みと、妥当性の判断を行う。従来技術において、複数のデータベースを管理する場合、管理の提言に関する手法などは提供されていた。
【０００４】
【特許文献１】特開２００６-２７７５７９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
問合せ者から得られる情報はあいまいであり、情報が不十分である場合が多い。障害情報を実績として蓄積する際には、その不足情報は障害受付者によって補完されるため、その受付担当者のノウハウに依存した情報となる。また、障害事例の調査には多種多様な情報が必要となり、情報の補完を行う必要がある。
【０００６】
発生した現象に対して、その対応策としての対処を調査する際の検索においては、検索と登録とは独立して行われる。その際の検索条件としては、ユーザーが入力したキーワードを用いて完全一致の検索を行うため、表示ゆれの問題も多く、的確な類似障害事例に到達しない場合が多い。従来技術では、システム名などを定型化、入力必須項目などを設け、文検索することでヒット率を高めるなどの対応を行っている。
【０００７】
障害管理ＤＢを対象にキーワード一致検索を行った場合は、同件と判断できる障害情報を複数取得してしまう問題や、現象には類似性が見られるが、発生要因が異なり雑音と見做せる事例も取得してしまうという問題を含んでいる。同件が複数検索結果として取得されてしまうことにより、その都度同件であるかの判断が必要となる。また、発生要因が明らかに異なる事例を取得してしまうことにより、検索結果の妥当性の検証がその都度必要となる。その結果、意図する類似事例が埋もれてしまい、対処に到達するまでに時間を要してしまう。従来技術では、構成情報を確認し、検索結果の妥当性についての検証を人手で行っていたが、これは構成情報などを用いてある程度絞り込むことが出来る。
【０００８】
障害対処は、障害情報の蓄積が十分である場合、過去の障害情報の対処方法を参考に行う例が多いが、システムが変更された場合には、必ずしも正しい対処とは限らない。このため、過去の障害情報と発生している障害情報のシステム構成などの差異から正しい対処方法であるか確認する必要がある。従来は、これらを人手により実施していた。
【課題を解決するための手段】
【０００９】
類似障害事例を検索するためには、蓄積されている情報に不足情報が少ないことが望ましい。そのために不足情報の補完を行う。逐一、構成情報を障害が発生したユーザーに確認し、入力するのではなく、確認項目をホスト名に限定する。そして障害の発生元の構成情報を、構成管理ＤＢから補完する。補完とは、ホスト名から、関連するアイテム、つまりアプリケーション名、バージョン情報、ネットワーク構成などを、構成管理ＤＢから取得し、追加情報として登録することである。
【００１０】
類似障害事例を検索する際には、関連語を検索条件キーワードとして拡張し、検索を行うことで表記ゆれの問題や、同義語、類似語などに対しての対処を行う。障害情報の現象などは、ある程度定型化された文章ではあるが、受付担当者によって使用する単語が異なる場合があるので、検索時にその表記ゆれを考慮して検索を行うことで、類似障害事例の検索漏れを少なくする。また、障害情報の分野では、対象をホスト名で表現する場合や、ＩＰアドレス、ＵＲＬ等で表現する場合もあるので、そういった情報も類似語として検索を行うことで、取得漏れを少なくする。
【００１１】
また、検索や調査などに使用する中間ＤＢである関連ＤＢを作成し、このＤＢに障害の現象、対処、要因とその関連性に関する情報を格納する。これによって検索結果の冗長性を解消し、同様の構成に対し複数発生する可能性のある現象を管理する。また、構成情報から要因に関連する構成情報のみを保持することにより、システムが更新された場合の差異などの比較にも対応できる。
【００１２】
過去事例から類似事例が見つかった場合は、構成情報を用いて類似障害事例の絞込みを行う。絞込みに使用する構成情報とは、関連ＤＢに格納されている現象の要因となる要因構成情報と、構成管理ＤＢによって補完された障害事例の構成情報である。既知の事例に関しては、その現象を引き起こす可能性のある構成情報が単数、または競合条件としての組み合わせで存在することが判明している。関連ＤＢには、これを要因構成情報として格納している。障害が発生している対象の構成情報と、関連語辞書を用いたキーワード拡張検索で得られた過去現象を引き起こす可能性のある構成である要因構成情報を比較することで、その過去の現象が、障害が発生している現象に関連を持つかどうかの判定を行うことが出来る。
【００１３】
検索で過去類似事例が見つからなかった場合には、新規現象と判断し、対処に関しては別途調査する必要があるため、障害情報を調査中状態で登録する。調査中状態で登録された障害事例の対処が判明した場合は、対処が既知のものであるかの判断を行うために、関連語辞書を用いたキーワード拡張を用いて類似対処の検索を行う。類似対処が取得できなかった場合は、その対処は新規対処として関連ＤＢに登録し、関連ＤＢを更新する。類似対処が取得できた場合は、その対処の関連を更新する。更新された関連ＤＢを対象に、同様の操作を行うことで関連ＤＢの拡張を行う。
【００１４】
こうして拡張された関連ＤＢには、障害情報に関する現象と対処とその要因に関する関連性の情報が格納され、検索や障害調査などに使用することが出来る。
【発明の効果】
【００１５】
本発明を適用することにより、ＩＴシステムの発生事例をＤＢに格納する際に，事例抽出を効率よく行うことが出来る。
【発明を実施するための最良の形態】
【００１６】
図を用いて発明の実施形態を説明する。
【００１７】
図１に本発明の構成を示した。メモリ（102）上に読み込まれた障害情報の登録、表示を行う登録表示部（103）、対処一覧表示部（104）を有した表示装置（101）がネットワーク（107）を介して管理装置（108）に接続されている。管理装置（108）のメモリ（111）上には障害情報から対処候補を提示する対処候補検索処理部（112）、対処が確定した場合の登録処理を行う対処登録処理部（113）が含まれる。管理装置（108）は個々の障害情報が格納されている障害管理ＤＢ（115）、管理対象の構成情報（118）が格納されている構成管理ＤＢ（117）、検索などに使用する中間ＤＢである関連ＤＢ（119）が接続されている。関連ＤＢ（119）には関連語辞書（120）、関連現象（121）が格納されている。
【００１８】
その構成上で、障害が発生した場合の登録処理フローを図２に示した。この処理は対処候補検索処理部（112）で処理される。まずユーザーから得られた情報を、受付担当者が入力し障害情報として登録する。その障害情報は障害情報テーブル（図８）の形式で管理する。構成情報に関してヒアリング、または自動的に取得したホスト名情報を元に補完を行う。具体的には、障害が発生した対象の構成情報をホスト名をキー情報として検索を行い、得られた構成情報を用いてユーザーから得られた情報を補完する（202）。構成管理ＤＢ（118）に格納されている構成情報テーブルの構成は図９である。ユーザーから得られた情報を構成管理ＤＢ（118）から補完した情報を用いて、障害管理ＤＢ（118）から対処候補の検索を行う（203）。検索の詳細なフローに関しては後述する。検索した結果、類似現象が存在した場合は、対処候補として対処一覧をユーザーに提示する（206）。検索結果が存在しなかった場合は、類似現象が障害管理ＤＢに存在しないので、未知の現象と判断できる。その場合、発生した障害情報を調査中の状態で、障害管理ＤＢに格納する（205）。
【００１９】
現象からの対象検索（203）から呼び出される処理の詳細なフローを図３に示した。まず、現象として入力された情報から単語ベースにキーワードを抽出し、そのキーワードを関連ＤＢの関連語辞書（121）を用いて拡張を行う（302）。拡張されるキーワードは、類似語テーブル（図１０、図１１）に格納されている情報から取得する。その拡張したキーワードをＯＲ条件として設定し（303）、関連ＤＢ（120）の現象テーブルを対象にキーワード一致検索を行う（304）。例えば、検査キーワード「ホスト名+動かない」が取得された場合、類似後テーブル（図１０、図１１）を用いると、検索条件は（“host（ホスト名）”or“192.168.0.**”or“http://****”or…）and（“動かない”or“止まっている”or“反応がない”or…）となる。このような検索条件で検索を行うことで、「hostが止まっている」、「192.168.0.**の反応がない」などといった事例も検索結果として取得することができる。この検索結果が得られるかどうかを判定する（305）。類似現象が取得できた場合は、現象・発生条件マッピングテーブル（図１６）、発生条件・対処マッピングテーブル（図１７）を用いて対処ＩＤリストを取得する（306）。この時点で取得できた対処リストは現象の観点からの対処候補である。これを、現象を引き起こす要因構成と現象が発生した攻勢を比較することにより、構成の観点から絞込みを行う（307）。この詳細なフローは図５で説明する。絞込みを行った結果対処候補が存在するかを判定し（308）、対処候補が存在する場合は、その対処を図１３の対処の一覧の形式でユーザーに提示する（310）。対処候補が存在しなかった場合は、類似事例が存在しないと判断し、事例を図８の形式で対処が不明の調査中の状態で登録する（309）。
【００２０】
対処候補の絞込み（307）から呼び出される処理の詳細なフローを図４に示した。対処候補は複数取得できる可能性があるので、最初の対処候補を取得する（402）。取得した対処候補から、発生条件・対処マッピングテーブル（図１７）、発生条件・要因構成マッピングテーブル（図１８）を用いて、その対処が関連している要因構成（図１４）を取得する（403）。要因構成（図１４）には、構成要素単独に障害を発生する要因がある場合と要因構成が複数競合することにより発生する場合がある。要因構成が単独か複数競合かを判定し（404）、単独で発生する構成要素に関しては、現象が発生している構成情報の特定の種別とマッチングを行うことにより判断できる（405）。要因構成が複数存在する場合は、複数要因構成すべてにおいて、マッチングを行う（406）。マッチングに関しては、図１４に分類されている障害影響度の高い、ネットワーク情報、サーバ情報、ＯＳ情報、ドライバ情報、ミドルウェア情報、ＡＰ情報の順でマッチングを行う。個々の要素に対してのマッチング条件は、構成要素名が一致する、かつバージョン情報が存在する場合は、バージョン情報は要因構成情報以下であることである。そしてマッチングの可否について判定し（407）、マッチングが成立した場合は対処候補が構成の観点において適当であると判断でき、提示する対処候補を図１３の一覧の形式で取得する（409）。マッチングが成立しなかった場合はその対処は構成の観点から不適当であると判断でき、対処候補として取得しない。そして、対処に関連する別の要因構成が存在するかの判定を行い（408）、存在する場合は、対処に関連する別の要因構成において同様のマッチング操作を行う。すべての要因構成にマッチング操作を行った場合、次の対処候補に関して同様の操作を行う。そうして、すべての対処候補に対して構成の観点においての絞込みが行える。例えば、現象が発生した構成情報がＯＳ１（ＯＳ情報）、ＡＰ１（ＵＰ情報）、ＡＰ２（ＡＰ情報）であったとする。検索結果の対処候補が、要因構成“ＡＰ３（ＵＰ情報）”のみに関連していた場合、または要因構成“ＯＳ１+ＡＰ３”のみに関連していた場合は、その対処候補は適当でないと判断する。また、要因構成“ＯＳ１”に関連する対処候補、要因構成“ＡＰ１+ＡＰ２”に関連する対処候補は、適当な対処である可能性があるため、対処候補として適当であると判断する。
【００２１】
障害情報ＤＢにおいて、調査中で登録されていた事例に対処が判明した場合のフローを図５に示した。この処理は対処登録処理部（113）で処理される。まず、既知の現象であるかを判定するために、類似現象の検索を行う（502）。処理の詳細は図６で後述する。類似現象が存在しなかった場合は、その現象は未知のものであるので、関連ＤＢに新規登録を行う（504）。類似現象が存在した場合は、その現象は既知のものであるので、新規登録は行わない。対処に関して類似対処の検索を行う（505）。処理の詳細は図７で後述する。既知、未知の判断を行い未知であれば、対処を図１３の形式で新規登録を行う（507）。そして、再現手順等の現象の発生条件を図１５の形式で登録する（508）。さらに要因構成（図１４）の登録を行い（509）、マッピングテーブルを更新する（510）。要因構成は要因構成テーブル（図１４）の形式で格納される。要因情報テーブル（図１４）は要因構成ＩＤ（1401）、対象の名称（1402）、構成情報（1403）で構成される。構成情報（1403）には、直接その現象の発生要因となった構成情報のみが格納され、現象の要因に無関係な構成情報は格納されない。
【００２２】
類似現象の検索フローを図６に示した。図５の類似現象検索（502）から処理が開始される（601）。まず入力された現象キーワードを取得する（602）。そして取得したキーワードが関連語辞書に存在するか一致検索を行う（603）。キーワードごとに一致検索を行い、関連語辞書に存在するかを判定（604）。存在すれば、検索を行うための拡張キーワードとして取得する（605）。存在しなければそのキーワードは拡張は行わない。そうして得られたキーワードをＯＲ条件に指定する（606）。生成した検索条件を元に現象テーブルの一致検索を行い、結果を取得する（608）。
【００２３】
図７は類似対処の検索フローである。図５の類似対処検索（505）から処理が開始される（701）。まず入力された現象キーワードを取得する（702）。そして取得したキーワードが関連語辞書に存在するか一致検索を行う（703）。キーワードごとに一致検索を行い、関連語辞書に存在するかを判定（704）。存在すれば、検索を行うための拡張キーワードとして取得する（705）。存在しなければそのキーワードは拡張は行わない。そうして得られたキーワードをＯＲ条件に指定する（706）。生成した検索条件を元に対処テーブルの一致検索を行い、結果を取得する（708）。
【００２４】
こうして拡張された関連ＤＢ（120）を用いて一連の操作を行う。
【００２５】
障害情報を管理する障害管理テーブルを図８に示した。障害情報テーブルでは、現象や対処、発生した対象のホスト名と構成情報、その障害の重要度などの情報を管理する。検索キーとなるホスト名情報と、障害発生時の構成情報も、この障害情報テーブルに格納する。
【００２６】
構成管理情報を管理する構成管理テーブルを図７に示した。構成情報テーブル（図７）には、管理対象が特定のマシンである場合、インストールされているソフトウェア、バージョン、パッチ情報、メーカーなどが種別毎に格納されている。構成情報は各構成の相関関係を表す状態で格納されており、この構成情報テーブル（図７）を参照することにより、障害発生時の影響範囲を推測することができる。この構成管理ＤＢを入力されたホスト名で検索し、構成情報（119）から構成情報をすべて取得し、障害情報として格納する。
【００２７】
構成管理ＤＢ（118）に格納される類似語テーブルを図１０、図１１に示した。類似後テーブルは代表語（1001、1102）と類似語（1002、1102）の対から構成される。格納されている語の種類は、語義上で類似語と判断できるもの（図１０）と、障害情報の分野で類似語と判断できるもの（図１１）に分類される。ホスト名などの情報はＩＰやＵＲＬなどで表現されることもあるため、構成管理ＤＢ（118）から取得した類似語情報も関連語辞書（121）に格納する。
【００２８】
現象は現象テーブル（図１２）の形式で格納される。現象テーブルはマッピングテーブルに用いられる現象マッピングテーブルに用いられる現象ＩＤ（1201）と、具体的な現象内容の現象（1202）で構成される。
【００２９】
対処は対処テーブル（図１３）の形式で格納される。対処テーブルはマッピングテーブルに用いられる対処ＩＤ、具体的な対処法である対処（1302）、その対処が解決する要因（1303）で構成される。要因（1303）は拡張キーワード検索の対象となる。
【００３０】
図１４に要因構成テーブルを示した。この要因構成テーブルには障害を発生させる要因となった構成情報が格納される。テーブル構成は、マッピングテーブルに用いられる要因構成ＩＤ（1401）、具体的に障害が発生したその際、構成情報（1403）は構成情報テーブル（図７）と同様に、構成情報は分類されて格納される。構成情報テーブル（図７）との差異は、構成情報テーブル（図７）では、対象を構成する構成情報すべてが格納されているのに対し、要因構成テーブル（図１４）では障害発生に関連する可能性のある構成情報のみが格納されていることである。
【００３１】
こうして拡張された関連ＤＢを元に一連の操作を繰り返す。
【図面の簡単な説明】
【００３２】
【図１】本発明基本構成図。
【図２】現象発生時の処理フロー。
【図３】対処候補検索処理フロー。
【図４】対処候補絞込みフロー。
【図５】対処判明時の処理フロー。
【図６】類似現象検索フロー。
【図７】類似対処検索フロー。
【図８】障害情報テーブル。
【図９】構成管理テーブル。
【図１０】関連語辞書テーブル１。
【図１１】関連語辞書テーブル２。
【図１２】現象テーブル。
【図１３】対処テーブル。
【図１４】要因構成テーブル。
【図１５】発生条件テーブル。
【図１６】現象・発生条件マッピングテーブル。
【図１７】発生条件・対処マッピングテーブル。
【図１８】発生条件・要因構成マッピングテーブル。
【符号の説明】
【００３３】
101…表示装置、102…メモリ、103…登録表示部、104…対処一覧表示部、105…プロセッサ、106…通信インターフェイス、107…ネットワーク、108…管理装置、109…通信インターフェイス、110…プロセッサ、111…メモリ、112…対処候補検索処理部、113…対処登録処理部、114…ディスクインターフェイス、115…障害管理ＤＢ、116…障害情報、117…構成管理ＤＢ、118…構成情報、119…関連ＤＢ、120…関連語辞書、121…関連現象。
【図１】
2009043029.tif 000003
【図２】
2009043029.tif 000004
【図３】
2009043029.tif 000005
【図４】
2009043029.tif 000006
【図５】
2009043029.tif 000007
【図６】
2009043029.tif 000008
【図７】
2009043029.tif 000009
【図８】
2009043029.tif 000010
【図９】
2009043029.tif 000011
【図１０】
2009043029.tif 000012
【図１１】
2009043029.tif 000013
【図１２】
2009043029.tif 000014
【図１３】
2009043029.tif 000015
【図１４】
2009043029.tif 000016
【図１５】
2009043029.tif 000017
【図１６】
2009043029.tif 000018
【図１７】
2009043029.tif 000019
【図１８】
2009043029.tif 000020