JP2021039686A - インシデント診断対応支援装置 - Google Patents

Abstract

【課題】情報処理システムにおけるインシデント対応に有効な診断手順を、効率よく選び出しやすくする。【解決手段】インシデント診断対応支援装置は、インシデントが発生した保守対象システムから異常又は警告を知らせる複数のメッセージを取得する取得部と、一又は複数のメッセージタイプに分類する分類部と、診断手順に沿って実施された障害検出の成否を特定する特定部と、一又は複数のメッセージタイプと、診断手順の識別子とを入力変数とし、障害検出の成否を出力変数とする教師データを用いて生成された学習モデルによって、候補の診断手順による障害検出の成否の予測値を得る予測値算出部と、を備える。【選択図】図４

Description

本発明は、情報処理システムのインシデント診断を支援する技術に関する。

たとえば企業の情報処理システムにおいて、一部の機能が停止したとか、正常に動作しないなどのインシデントが発生した場合、保守業者にシステムの復旧が依頼される。

保守業者は、保守対象である情報処理システムにおいて発生しているエラーメッセージなどを手掛かりとして、インシデントの原因となっている障害を検出し、その障害から修復させる作業を行う。

特に、早期に原因となっている障害を特定することは、システム復旧の迅速化において重要なことである。そこで、障害検出の観点から情報処理システムを診断する手順をナレッジ化して、作業の効率化を図ることが考えられる。

特開２０１８−１１２８７５号公報 特開２０１８−１１２８７６号公報 特開２０１８−１９５１２７号公報

しかし、実際に起こりうる障害は多岐にわたるため、一律に適用できる診断手順を設けることは妥当でない。そのため、起こりうる障害毎に具体的な診断手順を別個に定めた診断ナレッジを備えるようにする。

このように、検出対象とする障害を限定した診断手順を多数備える場合、インシデント対応においてどの診断手順を優先して用いるべきかを判断しなければならない。的外れな診断手順を選択すれば、折角診断ナレッジを用いても原因に至らずインシデント対応に結びつかない。

本発明は、上記課題認識に基づいて完成された発明であり、その主たる目的は、情報処理システムにおけるインシデント対応に有効な診断手順を、効率よく選び出すことである。

本発明のある態様におけるインシデント診断対応支援装置は、保守対象システムにおけるインシデントの原因となる障害を検出するための複数の診断手順を記憶する記憶部と、教師データ収集段階および学習モデル適用段階において、インシデントが発生した保守対象システムから、異常又は警告を知らせる複数のメッセージを取得する取得部と、教師データ収集段階および学習モデル適用段階において、インシデントの発生に伴い取得した複数のメッセージを、一又は複数のメッセージタイプに分類する分類部と、教師データ収集段階において、複数の診断手順のうちのいずれかの診断手順に沿って実施されたインシデントの障害検出の成否を特定する特定部と、教師データ収集段階において発生したインシデントに関して、取得した複数のメッセージから分類された一又は複数のメッセージタイプと、障害検出に用いられた診断手順の識別子とを入力変数とし、当該診断手順に沿って実施された障害検出の成否を出力変数とする教師データを用いて、学習モデルを生成する学習モデル生成部と、学習モデル適用段階において発生したインシデントに関して、取得した複数のメッセージから分類された一又は複数のメッセージタイプと、候補の診断手順の識別子とを入力変数とし、学習モデルを用いて、候補の診断手順に沿って障害検出を実施した場合の成否に関する予測値を得る予測値算出部と、を備える。

本発明の別の態様におけるインシデント診断対応支援装置は、保守対象システムにおけるインシデントの原因となる障害を検出するための複数の診断手順を記憶する記憶部と、教師データ収集段階および学習モデル適用段階において、インシデントが発生した保守対象システムから、異常又は警告を知らせる複数のメッセージを取得する取得部と、教師データ収集段階および学習モデル適用段階において、インシデントの発生に伴い取得した複数のメッセージを、一又は複数のメッセージタイプに分類する分類部と、教師データ収集段階において、複数の診断手順のうちのいずれかの診断手順に沿って実施されたインシデントの障害検出の成否を特定する特定部と、教師データ収集段階において発生したインシデントに関して、取得した複数のメッセージから分類された一又は複数のメッセージタイプを入力変数とし、障害検出が成功した診断手順の識別子を出力変数とする教師データを用いて、学習モデルを生成する学習モデル生成部と、学習モデル適用段階において発生したインシデントに関して、取得した複数のメッセージから分類された一又は複数のメッセージタイプを入力変数とし、学習モデルを用いて、障害検出が成功すると見込まれる診断手順を推定する推定部と、を備える。

本発明によれば、情報処理システムにおけるインシデント対応に有効な診断手順を、効率よく選び出しやすくなる。

保守対象システムにおける障害によってメッセージが発生する様子を示す図である。 診断ナレッジと対応ナレッジの概要を示す図である。 見本メッセージの使い方を示す図である。 学習モデルによる診断ナレッジのリコメンドの概要を示す図である。 保守支援システムの構成例を示す図である。 実施形態に係るフェーズを示す図である。 リコメンド画面の例を示す図である。 診断パターンと修復ナレッジの関係を示す図である。 診断ナレッジ画面の例を示す図である。 子ナレッジ画面の例を示す図である。 手順書データの例を示す図である。 保守支援サーバの機能ブロック図である。 保守支援サーバの機能ブロック図である。 保守支援サーバの機能ブロック図である。 ユーザ端末の機能ブロック図である。 ユーザ端末の機能ブロック図である。 保守支援サーバのメイン処理過程を示すフローチャート図である。 保守支援サーバのメイン処理過程を示すフローチャート図である。 保守支援サーバのメイン処理過程を示すフローチャート図である。 診断ナレッジ自動実行処理過程を示すフローチャート図である。 実施形態におけるニューラルネットワークの構成図である。 学習モデルを利用したリコメンド処理過程を示すフローチャート図である。 変形例１におけるニューラルネットワークの構成図である。 変形例２におけるニューラルネットワークの構成図である。 変形例２において学習モデルを利用したリコメンド処理過程を示すフローチャート図である。 インシデント対応の完全自動処理過程を示すフローチャート図である。

図１は、保守対象システム２００における障害によってメッセージが発生する様子を示す図である。
保守の対象となるシステムを、以下では「保守対象システム２００」という。対象システムでは、複数のホストコンピュータ１００が、ＬＡＮ（Local Area Network）に接続している。この例では、ホストコンピュータ１００ａ、ホストコンピュータ１００ｂ、ホストコンピュータ１００ｃ、ホストコンピュータ１００ｄ、ホストコンピュータ１００ｅ、ホストコンピュータ１００ｆ、ホストコンピュータ１００ｇ、ホストコンピュータ１００ｈが、ＬＡＮに接続している。ホストコンピュータ１００ａ〜１００ｈ等をまとめて言うときや特に区別しないときには「ホストコンピュータ１００」と総称する。

ホストコンピュータ１００は、他のホストコンピュータ１００と連携して動作することがある。図１に示した連結線は、連携する関係を示している。この例で、ホストコンピュータ１００ａは、ホストコンピュータ１００ｂ、ホストコンピュータ１００ｃ、ホストコンピュータ１００ｄ、ホストコンピュータ１００ｅと連携する。

ホストコンピュータ１００ａで障害が発生すると、ホストコンピュータ１００ａでメッセージａ、メッセージｂおよびメッセージｃ等が発生する。ホストコンピュータ１００ａと連携するホストコンピュータ１００ｂでメッセージｄ、メッセージｅおよびメッセージｆ等が発生する。同様に、ホストコンピュータ１００ｃでメッセージｇ、メッセージｈおよびメッセージｉ等が発生する。同様に、ホストコンピュータ１００ｄでメッセージｊ、メッセージｋおよびメッセージｌ等が発生する。同様に、ホストコンピュータ１００ｅでメッセージｍ、メッセージｎおよびメッセージｏ等が発生する。

但し、これらのメッセージは、障害を直接示す内容であるとは限らない。メッセージは、メッセージの発生源であるモジュールが検出した異常現象や警告に相当する事態に関する報告にすぎない。メッセージの発生源であるモジュールは、どのような障害が起きているかを関知してないこともある。したがって、保守員は、これらのメッセージから状況および障害を推測する必要がある。

図２は、診断ナレッジと対応ナレッジの概要を示す図である。
保守員が状況や障害を推測する場合、リモート操作によってホストコンピュータ１００のＯＳ（Operating System）に付属するツールやその他の計測ツールなどを使って、ツールの出力に基づく判断を行う。本実施形態では、保守員の作業を軽減化するための診断ナレッジを用いる。診断ナレッジには、リモート操作の内容と確認事項などを含む診断手順が定義されている。

また、障害を解消してシステムを修復するための手順を定めた修復ナレッジも用いる。修復の作業は、リモート操作だけで行える場合もあるし、リモート操作だけでは対応しきれないこともある。特にハードウェアの故障などの場合には、リモート操作では修復できない。装置や部品の交換などの物理的作業が必要になる。差異インストールやデータの復旧については、復旧ツールがあればリモート操作で対応することができる。

図示するように、障害Ａを検出するための診断ナレッジＡが用意されているものとする。障害Ａに対する修復を行うための修復ナレッジＡも用意されているものとする。したがって、診断ナレッジＡに修復ナレッジＡを対応付けることができる。そして、診断ナレッジＡで障害Ａを検出したときに、対応する修復ナレッジＡで修復を図るという一連の流れで対処できる。障害Ｂについても同様に、障害Ｂを検出するための診断ナレッジＢと障害Ｂに対する修復を行うための修復ナレッジＢが用意されている。したがって、診断ナレッジＢで障害Ｂを検出したときに、診断ナレッジＢに対応する修復ナレッジＢで修復を図ることができる。

しかし、障害Ａが発生している場合に、診断ナレッジＢでは検出できない。同様に、障害Ｂが発生している場合に、診断ナレッジＡでは検出できない。つまり、発生している障害に応じた診断ナレッジを用いることが、システムを早く復旧させる上での鍵となる。

障害が発生した場合、現象的にはインシデントとして表れる。インシデントとは、システムの利用において、業務や機能の利用が正常に行えない事態を意味する。インシデントは、上述した障害を原因とする。インシデントが起きたときには、その原因となっている障害に対応する診断ナレッジを保守員が選択して検査する必要がある。診断ナレッジを選択する際のヒントとして、見本メッセージが用いられる。

図３は、見本メッセージの使い方を示す図である。
診断ナレッジには、見本メッセージが対応付けられている。見本メッセージは、診断ナレッジが対象とする障害に応じて発生する可能性が高いメッセージの例である。たとえば、診断ナレッジＡには、診断ナレッジＡが検出対象とする障害Ａによって発生すると見込まれるメッセージの代表例として、見本メッセージＡが対応付けられている。同様に、診断ナレッジＢには見本メッセージＢが対応付けられ、診断ナレッジＣには見本メッセージＣが対応付けられ、診断ナレッジＤには見本メッセージＤが対応付けられ、診断ナレッジＥには見本メッセージＥが対応付けられている。

保守員がインシデントの発生の知らせを受けた時点で、障害は特定されていない。そこで、いずれかの診断ナレッジを使って障害を特定しようとする場合、保守員はまず保守対象システム２００で発生したメッセージ（以下、「発生メッセージ」という。）と、各見本メッセージを比較して、近似する見本メッセージを選別する。そして、選別した見本メッセージに対応する診断ナレッジを使って検査を行う。診断ナレッジが、発生している障害を検出対象とするものであれば、障害検出が成功する。しかし、診断ナレッジが、発生している障害を検出対象とするものでなければ、障害検出が失敗し、別の診断ナレッジを試し直すことになる。診断ナレッジの選別を効率よく行うために、本実施形態では、発生メッセージに応じて診断ナレッジをリコメンド（推奨）する。

発生メッセージを検索キーとして見本メッセージを検索する機能を用いれば、発生メッセージに近似する見本メッセージを自動的に選別することができる。メッセージの検索方式は、一般的な文検索の従来技術であっても構わない。比較する２つのメッセージの近似度を出力する全文検索方式を採用してもよい。そして、発生メッセージと近似度が高い見本メッセージに対応する診断ナレッジを優先的にリコメンドすることが考えられる。

しかし、メッセージの近似度がリコメンドの確信の程度を示すとは限らない。メッセージの近似度を基準としてリコメンドされる診断ナレッジによって、障害を検出できないケースも多い。以下、その理由について説明する。

ここでいう発生メッセージは、メッセージの発生元であるホストコンピュータ１００における不都合を示す異常メッセージや警戒を示す警告メッセージである。たとえば、障害を起こした連携相手のホストコンピュータ１００が正常に動作しない場合に発生するメッセージは、「レスポンス待ちのタイムアウトが発生しました。」などのように、メッセージの発生元における不都合を示す。このような異常メッセージでは、連携相手のホストコンピュータ１００でどのような事態になっているかがわからず、相手側の障害内容を特定することはできない。レスポンスを返さない相手側で生じている障害は、複数考えられる。

つまり、連携相手のホストコンピュータ１００が正常に動作しないためにメッセージを発生させる場合、その連携相手において想定される障害が１種類であるとは限らない。想定される複数種類の障害のうちのいずれかが生じているに過ぎない。メッセージの種類と障害の種類は、１対１の関係を前提としていない。よって、ある診断ナレッジの見本メッセージはその診断ナレッジが対象とする障害によらず、別の障害によって発生する可能性がある。

また、ホストコンピュータ１００において障害が生じると、障害を起こしたホストコンピュータ１００だけでなく、他のホストコンピュータ１００においても２次的な不具合が起きることがある。そして、２次的な不具合を原因とするメッセージも発生する。もしも検索キーとして用いた発生メッセージが、２次的な不具合に起因するものであったとすれば、その発生メッセージに基づいてリコメンドされる診断ナレッジは、２次的な不具合を検出するが、根本的な障害を検出したことにはならない。したがって、その診断ナレッジに対応する修復ナレッジでは根本的な障害に対処できないので、インシデントを解消できない。

このように見本メッセージに頼ったリコメンドは、必ずしも精度が高くない。そこで、本実施形態では診断ナレッジの使用実績に基づく学習モデルを使って、より障害の検出確率が高まるように診断ナレッジをリコメンドする。そうすれば、保守員の経験に頼らずに、早期に障害を検出してインシデントが解消されると期待できる。

図４は、学習モデルによる診断ナレッジのリコメンドの概要を示す図である。
本実施形態では、学習モデルによる診断ナレッジのリコメンドを行う。学習モデルは、たとえばニューラルネットワークを用いる。学習処理における教師データとして、診断ナレッジを用いて診断を行ったときの実績データを用いる。実績データの収集段階で使用される診断ナレッジは、メッセージの検索によってリコメンドされたものであってもよいし、保守員が判断して選択したものであってもよい。

学習モデルにおける入力変数は、複数の発生メッセージから分類された一または複数のメッセージタイプと、障害検出のために使用した診断ナレッジの種類である。診断ナレッジの種類は、診断ナレッジＩＤで特定される。

メッセージタイプについて説明する。たとえば、障害を起こしたホストコンピュータ１００ａと連携するホストコンピュータ１００ｂがホストコンピュータ１００ａに対するリクエストを送信し、そのリクエストが拒否された場合に、ホストコンピュータ１００ｂはリクエストが拒否された旨の異常メッセージを発生させる。その後もホストコンピュータ１００ｂがリトライを繰り返せば、同種のメッセージが発生することになる。また、他のホストコンピュータ１００ｃが同様にホストコンピュータ１００ａを利用しようとすれば、同じくリクエストが拒否された旨の異常メッセージが発生する。このように、同種のメッセージが多数発生する。これらは、同じメッセージタイプとして分類することができる。したがって、インシデントに伴い発生した多数のメッセージをメッセージタイプに分類すれば、全体的なメッセージの発生状況を捉えやすくなる。

学習モデルにおける出力変数は、診断ナレッジを用いた検査における障害検出の成否である。図２に関連して説明したとおり、起きている障害に合った診断ナレッジを用いれば、障害検出が成功し、起きている障害に合っていない診断ナレッジを用いれば、障害検出が失敗する。

教師データにおけるサンプルは、一のインシデントに関して、複数のメッセージから分類された一または複数のメッセージタイプと、障害検出に用いられた診断ナレッジＩＤと、診断ナレッジによる障害検出の成否とを含む。第１段階では、実績を示す多数のサンプルを蓄積する。

第２段階では、教師データを用いた学習処理によって、学習モデルを生成する。具体的には、ニューラルネットワークにおける各ノード間の連結の強さを示す重みデータが生成される。学習処理の詳細については、後述する。

第３段階では、発生したインシデントに関して、複数のメッセージから分類された一または複数のメッセージタイプと、障害検出に用いる候補となる診断ナレッジの種類、つまり診断ナレッジＩＤとを入力変数として学習モデルに適用し、出力変数として候補の診断ナレッジにおいて障害検出を実施した場合の成否に関する予測値を得る。予測値が高ければ、その診断ナレッジを用いれば障害が検出される可能性が高いことを意味する。各診断ナレッジについて予測値を求め、予測値が高いものから優先的にリコメンドする。

端的に言うと、インシデントが発生している保守対象システム２００における現象的特性を、メッセージタイプの組み合わせで捉える。障害検出の成否は、現象的特性と診断ナレッジとの相性を表す。この相性は、診断ナレッジが対象とする障害と、その障害による現象的特性との関係に基づく。この関係には再現性があるので、学習モデルによる診断ナレッジのリコメンドは有意義である。

つまり、保守対象システム２００における現象的特性を、メッセージタイプの組み合わせによって捉えやすくし、試行した診断ナレッジによる障害検出の成功実績と失敗実績を学習させ、間接的に現象的特性に応じて診断ナレッジの適性の程度を求められるようにする。失敗実績も学習するので、同じような過ちを避けて成功の可能性を高める点で、有利な側面がある。

なお、ここでいう現象的特性は、根本的な障害に起因する現象だけではなく、障害から誘発される二次的不具合に伴う現象に関する特性も含んでいる。二次的不具合に伴う現象は、保守対象システム２００の構成や動作に依存するものであって、いわば保守対象システム２００の癖に相当する。このような保守対象システム２００における独特な振る舞いも加味して判断を行える点でも、本実施形態は有利な一面がある。

また、本実施形態では、診断ナレッジに含まれる手順の部分的な自動化と全体的な自動化の工夫もする。後に、機械学習の態様に関する変形例１および２を挙げる。更に、変形例３では、診断と修復も含むインシデント対応の完全な自動化にも及ぶ。

図５は、保守支援システムの構成例を示す図である。
保守支援システムは、保守支援サーバ３００とユーザ端末４００ａ〜４００ｃ等によって構成される。保守支援サーバ３００とユーザ端末４００ａ〜４００ｃ等は、ネットワークに接続する機能を備えている。ユーザ端末４００ａ〜４００ｃ等をまとめて言うときや特に区別しないときには「ユーザ端末４００」と総称する。ユーザ端末４００は、たとえば、パーソナルコンピュータ、タブレット端末やスマートフォンなどの携帯電話端末でもよい。

ユーザ端末４００は、保守員が使用する端末である。保守員は、ユーザ端末４００を用いて保守対象システム２００におけるインシデントに対処する保守作業を行う。保守支援サーバ３００は、保守員による保守対象システム２００の保守作業を支援する。具体的には、保守対象システム２００で発生したインシデントに対処する作業を支援する。

保守支援サーバ３００とユーザ端末４００は、ネットワークを介して接続している。保守支援サーバ３００とユーザ端末４００を接続するネットワークは、たとえばインターネット、ＬＡＮあるいは専用回線などのいずれであってもよい。

保守支援サーバ３００は、保守対象システム２００とネットワークを介して接続している。保守支援サーバ３００と保守対象システム２００を接続するネットワークは、たとえばインターネット、ＬＡＮあるいは専用回線などのいずれであってもよい。

ユーザ端末４００も保守対象システム２００とネットワークを介して接続している。ユーザ端末４００と保守対象システム２００を接続するネットワークは、たとえばインターネット、ＬＡＮあるいは専用回線のいずれなどであってもよい。

たとえば、保守支援システムと、保守対象システム２００とが別の拠点にあれば、保守支援サーバ３００とユーザ端末４００がＬＡＮに接続し、保守対象システム２００と保守支援システムがインターネットや専用線で接続する形態が考えられる。

図６は、実施形態に係るフェーズを示す図である。
上述した第１段階を教師データ収集フェーズという（Ｓ１０）。教師データ収集フェーズでは、インシデントに対処する作業に伴い実績データを収集する。教師データ収集フェーズでは、メッセージの検索によって診断ナレッジをリコメンドする。保守員は、リコメンドされた診断ナレッジおよび修復ナレッジを用いて保守作業を行う。教師データ収集フェーズでは、学習モデルを使用しない。

上述した第２段階を学習モデル生成フェーズという（Ｓ１２）。学習モデル生成フェーズでは、収集した実績データを教師データとして用いて学習モデルを生成する。学習モデル生成フェーズは、インシデントに対処する作業を伴わない。

上述した第３段階を学習モデル適用フェーズという（Ｓ１４）。学習モデル適用フェーズでは、インシデントに対処する作業において、生成した学習モデルを用いて診断ナレッジのリコメンドを行う。学習モデル適用フェーズにおけるリコメンドは、教師データ収集フェーズにおけるリコメンドよりも精度が高まる。つまり、リコメンドされた診断ナレッジによって障害が検出される可能性が高くなる。

診断ナレッジに含まれる手順の部分的な自動化と全体的な自動化については、教師データ収集フェーズ（Ｓ１０）および学習モデル適用フェーズ（Ｓ１４）のいずれにおいても実施可能である。また、診断と修復も含むインシデント対応の完全な自動化についても教師データ収集フェーズ（Ｓ１０）および学習モデル適用フェーズ（Ｓ１０４）のいずれにおいても実施可能である。つまり、自動化の仕組みは、リコメンドの方式に依存しない。詳しくは、後述する。

続いて、ユーザ端末４００のディスプレイに表示される画面の例などを示して、ユーザインターフェースおよび機能の概要について説明する。

図７は、リコメンド画面の例を示す図である。
インシデントが発生し、リコメンドされる診断ナレッジが選択されると、リコメンド画面がユーザ端末４００に表示される。

診断ナレッジ名表示領域５００ａ〜５００ｃには、推薦される診断ナレッジの名前が表示される。リコメンド指標表示領域５０２ａからリコメンド指標表示領域５０２ｃには、診断ナレッジ毎のリコメンド指標が表示される。リコメンド指標は、リコメンドの程度を表す。

この例で、リコメンド指標が大きいものから順に３つの診断ナレッジが表示される。リコメンド指標が８０である「メールボックス異常診断」が、最も推奨される診断ナレッジとして先頭に表示される。次に推奨される診断ナレッジとしてリコメンド指標が７０である「オペレーティングシステムハングアップ診断」が表示される。続いて推奨される診断ナレッジとしてリコメンド指標が６０である「ネットワークリンクダウン診断」が表示される。

保守員は、診断ナレッジ名表示領域５００ａ〜５００ｃのいずれかにタッチして、使用する診断ナレッジを決める。保守員が手作業で診断を行おうとする場合には、診断ナレッジ表示ボタン５０４を選択する。診断ナレッジ表示ボタン５０４がタッチされると、診断ナレッジ画面が表示される。診断ナレッジ画面については、図９に関連して後述する。

診断ナレッジを自動実行させる場合には、保守員は診断ナレッジ自動実行ボタン５０６を選択する。診断ナレッジ自動実行ボタン５０６がタッチされると、診断ナレッジが自動実行される。診断ナレッジ自動実行ボタン５０６は、診断ナレッジの自動化がされている場合に限って選択できる。診断ナレッジが自動化されていないときには、診断ナレッジ自動実行ボタン５０６は薄い色で表示され、タッチされても反応しない。つまり、診断ナレッジ自動実行ボタン５０６は、非アクティブになっている。

保守員の手作業または自動実行による診断を終えると、診断結果表示領域５０８ａ〜５０８ｃに診断結果が表示される。診断結果表示領域５０８ａ〜５０８ｃには、検出した障害の種類あるいは「障害非検出」が表示される。診断ナレッジによる診断がされていない段階では、診断結果表示領域５０８ａ〜５０８ｃには何も表示されない。なお、診断ナレッジが手作業で行われる場合あるいは自動実行される場合のいずれであっても、診断結果は、所定の診断パターンによって決定される。診断パターンについては、図８に関連して後述する。

診断によって障害が検出された場合には、修復ナレッジの手順に沿って修復が行われ、修復結果表示領域５１０ａ〜５１０ｃに修復の状況が表示される。修復に関する操作については、後述する。具体的には、修復結果表示領域５１０ａ〜５１０ｃに「未了」または「完了」が表示される。保守作業を終える場合、保守員は閉じるボタン５１２にタッチし、リコメンド画面を閉じる。

診断ナレッジ画面について説明する前に、診断ナレッジにおける診断パターンと修復ナレッジの関係について説明する。

図８は、診断パターンと修復ナレッジの関係を示す図である。
診断ナレッジには、複数の診断パターンが設定されている。診断パターンは、障害の種類を特定するための条件である。診断パターンは、診断ナレッジのパーツである子ナレッジの判定結果によって定まる。つまり、子ナレッジによる判定結果が、障害検出の基礎となる。診断ナレッジに定義される手順は、一または複数の子ナレッジから構成される。子ナレッジは、ある技術的事項に関する判定手順を定める。一つの子ナレッジによる判定結果だけで障害が特定されることもあるし、複数の子ナレッジによる判定結果の組み合わせによって障害が特定されることもある。また、一または複数の子ナレッジの判定結果によって、障害が検出されないと判定されることもある。この場合は、この診断ナレッジでインシデントの原因となっている障害の検出に失敗したことを意味する。診断ナレッジ自体や保守員の作業に問題があるわけではない。

図示した診断ナレッジＣは、子ナレッジｃ１と子ナレッジｃ２を含む。子ナレッジｃ１の手順に沿って手作業あるいは自動実行をすれば、子ナレッジｃ１の判定結果として＜異常＞または＜正常＞が定まる。子ナレッジｃ２についても、同様に子ナレッジｃ２の判定結果として＜異常＞または＜正常＞が定まる。

この例では、診断パターン１から診断パターン３が設定されている。診断パターン１では、子ナレッジｃ１による判定結果が＜異常＞である場合に、障害Ｃ１が発生していると判定する。診断パターン１は、子ナレッジｃ２による判定結果に依存しない。このように、診断パターン１に合致すれば、診断ナレッジＣによって障害Ｃ１が検出される。

診断パターン２では、子ナレッジｃ１による判定結果が＜正常＞であって、且つ子ナレッジｃ２による判定結果が＜異常＞である場合に、障害Ｃ２が発生していると判定する。このように、診断パターン２に合致すれば、診断ナレッジＣによって障害Ｃ２が検出される。

診断パターン３では、子ナレッジｃ１による判定結果が＜正常＞であって、且つ子ナレッジｃ２による判定結果も＜正常＞である場合に、診断ナレッジＣが対象とする障害は発生していないと判定する。つまり、診断パターン３に合致すれば、診断ナレッジＣによって障害が検出されない。この場合、診断ナレッジＣに関しては問題が無いが、保守対象システム２００において一切障害が無いということではない。診断ナレッジＣでは、障害を検出できないので、他の診断ナレッジによって障害を見つける必要がある。つまり、インシデント対応として障害検出に失敗したことを意味する。

また、障害検出に成功する診断パターン１と診断パターン２には、検出した障害について修復手順を定めた修復ナレッジが対応付けられている。この例で、診断パターン１には、障害Ｃ１から修復させるための修復ナレッジＣ１が対応付けられている。したがって、診断パターン１に合致した場合には、修復ナレッジＣ１の手順に沿って修復作業を行えば、障害Ｃ１が解消される。また、診断パターン２には、障害Ｃ２から修復させるための修復ナレッジＣ２が対応付けられている。したがって、診断パターン２に合致した場合には、修復ナレッジＣ２の手順に沿って修復作業を行えば、障害Ｃ２が解消される。障害を検出しない診断パターン３には、修復ナレッジが対応付けられていない。修復対象の障害が特定されていないからである。

図９は、診断ナレッジ画面の例を示す図である。
図７に示したリコメンド画面において、いずれかの診断ナレッジ名表示領域５００が選択され、診断ナレッジ表示ボタン５０４がタッチされると、その診断ナレッジに関する診断ナレッジ画面が表示される。

診断ナレッジ名表示領域６００には、保守員によって選択された診断ナレッジの名前が表示される。診断ナレッジ概要表示領域６０２には、保守員によって選択された診断ナレッジの概要が表示される。この例では、「メールボックス異常診断」という名前の診断ナレッジが、「メールボックスに関する異常を検出する」ものであることを示している。

子ナレッジ名表示領域６０４ａ、ｂには、診断ナレッジに含まれる子ナレッジの名前が表示される。例示した「メールボックス異常診断」の診断ナレッジには、２つの子ナレッジが設定されている。子ナレッジ名表示領域６０４ａは、１番目の子ナレッジが「メールＤＢの接続確認」であることを示し、子ナレッジ名表示領域６０４ｂは、２番目の子ナレッジが「メールキューの滞留確認」であることを示している。

各子ナレッジ名表示領域６０４ａ，ｂの下には、子ナレッジ手順表示ボタン６０６ａ，ｂと子ナレッジ自動実行ボタン６０８ａ，ｂが表示される。保守員が子ナレッジ手順表示ボタン６０６ａ，ｂをタッチすると、子ナレッジの手順を示す子ナレッジ画面（図１０参照）が表示される。保守員が子ナレッジ自動実行ボタン６０８ａ，ｂをタッチすると、子ナレッジの手順が自動的に実行される。子ナレッジ自動実行ボタン６０８ａ，ｂは、子ナレッジの自動化がされている場合に限って選択できる。子ナレッジが自動化されていないときには、子ナレッジ自動実行ボタン６０８ａ，ｂは薄い色で表示され、タッチされても反応しない。つまり、子ナレッジ自動実行ボタン６０８ａ，ｂは、非アクティブになっている。

この例で、保守員が手動で「メールＤＢの接続確認」を行う場合には、子ナレッジ手順表示ボタン６０６ａをタッチする。子ナレッジ手順表示ボタン６０６ａがタッチされると、「メールＤＢの接続確認」の手順を含む子ナレッジ画面（図１０参照）が表示される。保守員は、この手順に沿って「メールＤＢの接続確認」の作業を行う。保守員が自動で「メールＤＢの接続確認」を実行させる場合には、子ナレッジ自動実行ボタン６０８ａにタッチする。子ナレッジ自動実行ボタン６０８ａがタッチされると、「メールＤＢの接続確認」の手順が自動的に実行される。

保守員が手動で作業する場合でも、自動で実行させる場合でも、「メールＤＢの接続確認」において、正常にメールＤＢが接続されていることを確認すると、「１：接続中＜正常＞」という判定結果になる。一方、正常にメールＤＢが接続されていないことが判明すると、「２：非接続＜異常＞」という判定結果になる。

同様に、保守員が手動で「メールキューの滞留確認」を行う場合には、子ナレッジ手順表示ボタン６０６ｂをタッチする。子ナレッジ手順表示ボタン６０６ｂがタッチされると、「メールキューの滞留確認」の手順を含む子ナレッジ画面が表示される。保守員は、この手順に沿って「メールキューの滞留確認」の作業を行う。保守員が自動で「メールＤＢの接続確認」を実行させる場合には、子ナレッジ自動実行ボタン６０８ｂにタッチする。子ナレッジ自動実行ボタン６０８ｂがタッチされると、「メールキューの滞留確認」の手順が自動的に実行される。

保守員が手動で作業する場合でも、自動で実行させる場合でも、「メールキューの滞留確認」において、メールキューの滞留が起きていないことを確認すると、「１：滞留無し＜正常＞」という判定結果になる。一方、メールキューの滞留が起きていると判明すると、「２：滞留有り＜異常＞」という判定結果になる。

診断ナレッジでは、診断ナレッジで用いる子ナレッジにおける判定結果に応じて診断結果を導く。上述のとおり、診断結果を導くためのパターンを「診断パターン」という。診断ナレッジ画面では、診断パターンも表示する。例示した「メールボックス異常診断」の診断ナレッジでは、診断パターン１、診断パターン２および診断パターン３が設けられている。初期段階で、診断パターン１に対応する修復ナレッジボタン６１６ａおよび診断パターン２に対応する修復ナレッジボタン６１６ｂは、非アクティブである。つまり、薄い色で表示され、タッチされても反応しない。

診断パターン１について説明する。子ナレッジ「メールＤＢの接続確認」に関して、保守員が手動で作業し、あるいは自動で実行して、判定結果が「２：非接続＜異常＞」になると、第１子ナレッジ判定結果表示領域６１０ａが反転表示になる。「メールＤＢの接続確認」の判定結果が「２：非接続＜異常＞」であれば診断パターン１に該当し、診断結果が「メールＤＢ非接続」となる。そして、診断パターン１の診断結果「メールＤＢ非接続」を示す診断結果表示領域６１４ａが反転表示になる。これによって、「メールＤＢ非接続」という障害が検出されたことがわかる。なお、診断パターン１に該当する場合には、「メールキューの滞留確認」について実行する必要はない。

また、「メールＤＢの再接続」と示された修復ナレッジボタン６１６ａがアクティブ化される。つまり、修復ナレッジボタン６１６ａが濃い色で表示され、タッチによって反応する状態になる。これにより、障害「メールＤＢ非接続」を修復するために修復ナレッジ「メールＤＢの再接続」を使用できることがわかる。

この段階で、保守員が修復ナレッジボタン６１６ａをタッチすれば、「メールＤＢの再接続」の修復ナレッジ画面へ移る。この修復ナレッジ画面には、「メールＤＢ非接続」の障害を修復させる手順が表示される。保守員は、この手順を参照しながら、修復作業を行うことができる。また、修復ナレッジの手順が自動化されている場合には、修復ナレッジ自動実行ボタンを選択することもできる。修復ナレッジ自動実行ボタンがタッチされると、修復ナレッジの自動実行プログラムが実行される。修復ナレッジ画面については、図示しない。

診断パターン２について説明する。子ナレッジ「メールＤＢの接続確認」の判定結果が「１：接続中＜正常＞」であれば、第１子ナレッジ判定結果表示領域６１０ｂおよび第１子ナレッジ判定結果表示領域６１０ｃが反転表示になる。次に子ナレッジ「メールキューの滞留確認」に関して、保守員が手動で作業し、あるいは自動で実行して、判定結果が「２：滞留有り＜異常＞」になると、第２子ナレッジ判定結果表示領域６１２ｂが反転表示になる。

「メールＤＢの接続確認」の判定結果が「１：接続中＜正常＞」であって、且つ「メールキューの滞留確認」の判定結果が「２：滞留有り＜異常＞」であれば診断パターン２に該当し、診断結果が「メールキュー滞留」となる。そして、診断パターン２の診断結果「メールキュー滞留」を示す診断結果表示領域６１４ｂが反転表示になる。これによって、「メールキュー滞留」という障害が検出されたことがわかる。

また、「問題プロセスの再起動」と示された修復ナレッジボタン６１６ｂがアクティブ化される。これにより、障害「メールキュー滞留」を修復するために修復ナレッジ「問題プロセスの再起動」を使用できることがわかる。

この段階で、保守員が修復ナレッジボタン６１６ｂをタッチすれば、「問題プロセスの再起動」の修復ナレッジ画面へ移る。この修復ナレッジ画面には、「メールキュー滞留」の障害から修復させる手順が表示される。修復ナレッジ画面については、上述のとおりである。

診断パターン３について説明する。子ナレッジ「メールキューの滞留確認」の判定結果が「１：滞留無し＜正常＞」であれば、第２子ナレッジ判定結果表示領域６１２ｃが反転表示になる。

「メールＤＢの接続確認」の判定結果が「１：接続中＜正常＞」であって、且つ「メールキューの滞留確認」の判定結果が「１：滞留無し＜正常＞」であれば診断パターン３に該当し、診断結果が「障害非検出」となる。そして、診断パターン３の診断結果「障害非検出」を示す診断結果表示領域６１４ｃが反転表示になる。これによって、診断ナレッジ「メールボックス異常診断」によって障害が検出されなかったことがわかる。この場合には、診断ナレッジ「メールボックス異常診断」がインシデントの原因を見つけるために適していなかったことを意味する。保守員が戻るボタン６１８にタッチすれば、リコメンド画面に戻り、診断ナレッジを選び直すことができる。

図１０は、子ナレッジ画面の例を示す図である。
この例は、図９に示した診断ナレッジ画面において、子ナレッジ手順表示ボタン６０６ａがタッチされた場合に表示される子ナレッジ画面を示している。

子ナレッジ名表示領域７００には、子ナレッジの名前が表示される。子ナレッジ概要表示領域７０２には、子ナレッジの概要が表示される。この例では、「メールＤＢの接続確認」という名前の子ナレッジが、「メールＤＢの接続状態を確認する」ものであることを示している。

子ナレッジ手順表示領域７０４には、子ナレッジにおける作業手順が表示される。作業手順には、１または複数の作業項目が含まれる。この例では、「１．ホスト名を確認する。」と「２．メールＤＢが接続中であることを確認する。」という作業項目が含まれる。作業項目には、リモート操作するユーザ端末４００における入出力データが示される。打鍵コマンドは、ユーザ端末４００のキーボードから入力するコマンドである。入力されたコマンドは、保守対象システム２００へ送信される。出力例は、保守対象システム２００においてコマンドを実行した結果、リターンコードと共にユーザ端末４００へ返信され、ユーザ端末４００のディスプレイに表示される出力コードの例である。更に、作業項目には、保守員が確認すべき内容も示される。つまり、保守員が正常であると確認するための条件が示される。保守員は、保守対象システム２００におけるいずれのホストコンピュータ１００にアクセスするか自ら判断してもよいし、保守支援サーバ３００またはユーザ端末４００において、アクセスするホストコンピュータ１００を自動的に選択してもよい。アクセスするホストコンピュータ１００については、発生メッセージに含まれるホスト名や保守対象システム２００のシステム構成データに基づいて決められてもよい。

１番目の作業項目では、保守員がユーザ端末４００に「ｈｏｓｔｎａｍｅ」と入力し、「ＴＩＧＥＲ１２３」のようにホスト名が出力されることを示している。また、同時に出力されるリターンコードが「０」であれば、正常であることを示している。この作業項目に関して、リターンコードが「０」でなければ、異常である。

２番目の作業項目では、保守員がユーザ端末４００に「＄Ｓｅｓｓｉｏｎ；Ｇｅｔ−ＭａｉｌｂｏｘＤａｔａｂａｓｅ」を含むコマンドを入力する。図中、「（中略）」と示した部分には、具体的な命令コードが示される。ここでは、説明の簡略のため省略する。また、「"Ｓｅｒｖｅｒ：ＴＩＧＥＲ１２３"」というラインと、「"Ｍｏｕｎｔｅｄ：Ｔｒｕｅ"」というラインを含むパラメータリストが出力されることを示している。図中、「（中略）」と示した部分には、具体的なパラメータ名とパラメータの値が示すラインが含まれる。ここでは、説明の簡略のため省略する。また、出力されたパラメータリストにおけるパラメータ「Ｍｏｕｎｔｅｄ」の値が「Ｔｒｕｅ」であれば、正常であることを示している。この作業項目に関して、パラメータ「Ｍｏｕｎｔｅｄ」の値が「Ｔｒｕｅ」でなければ、異常である。

子ナレッジ手順表示領域７０４に表示された各作業項目について保守員が作業を行い、いずれの正常条件も満たすことを確認した場合には、保守員は、この子ナレッジについて正常と判定する。１つでも正常条件を満たさない場合には、保守員は、この子ナレッジについて異常と判定する。

この例で、１番目の作業項目に関してリターンコードが「０」以外であれば、子ナレッジ「メールＤＢの接続確認」について、保守員は異常と判定する。また、１番目の作業項目に関してリターンコードが「０」であっても、２番目の作業項目に関して「Ｍｏｕｎｔｅｄ」が「Ｔｒｕｅ」でなければ、保守員は異常と判定する。つまり、１番目の作業項目に関してリターンコードが「０」であって、且つ２番目の作業項目に関して「Ｍｏｕｎｔｅｄ」が「Ｔｒｕｅ」である場合に限って、保守員は「メールＤＢの接続確認」について正常と判定する。

保守員が正常と判定した場合には、「１：接続中＜正常＞」と示された子ナレッジ判定結果ボタン７０６ａにタッチする。保守員が異常と判定した場合には、「２：非接続＜異常＞」と示された子ナレッジ判定結果ボタン７０６ｂにタッチする。子ナレッジ判定結果ボタン７０６ａまたは子ナレッジ判定結果ボタン７０６ｂがタッチされると、子ナレッジ画面が閉じて診断ナレッジ画面に戻る。子ナレッジ判定結果ボタン７０６ａまたは子ナレッジ判定結果ボタン７０６ｂのタッチによって特定された判定結果は、上述のとおり診断ナレッジ画面（図９参照）に反映される。

また、子ナレッジの使用実績が増えた場合には、子ナレッジの手順を自動化することができる。保守員は、子ナレッジ使用回数表示領域７０８に表示された子ナレッジの使用回数を参照して、この子ナレッジの手順を自動化してもよいか判断する。使用回数が多ければ、この子ナレッジの手順に関して問題がないと推測できる。子ナレッジの手順を自動化させる場合には、保守員が子ナレッジ自動化ボタン７１０にタッチする。そして、子ナレッジを自動実行するためのホスト定義ファイルが生成される。ホスト定義ファイルの生成については、図１１に関連して後述する。ホスト定義ファイルが生成され、子ナレッジの自動実行が可能になると、診断ナレッジ画面（図９参照）における子ナレッジ自動実行ボタン６０８がアクティブ化される。

保守員が作業を中断する場合には、戻るボタン７１２にタッチする。戻るボタン７１２がタッチされると、子ナレッジ画面を閉じて、診断ナレッジ画面に戻る。この場合には、判定結果は特定されず、診断ナレッジ画面の表示内容は元のままである。

図１１は、手順書データの例を示す図である。
子ナレッジ画面の子ナレッジ手順表示領域７０４に表示される内容は、子ナレッジデータに含まれる手順書データに記述されている。手順書データは、マークアップ言語（例えば、ＨＴＭＬ（HyperText Markup Language））で記述される。子ナレッジ画面表示処理部４３６は、マークアップ言語の記述ルールに従って手順書データから解釈された内容を表示する。

図示するように、１番目の作業項目について、打鍵コマンドに関する「ｃｍｄ」と「ｈｏｓｔｎａｍｅ」という記述と、出力例に関する「ｒｅｓｕｌｔ」と「ＴＩＧＥＲ１２３」という記述と、正常条件に関する「正常条件：リターンコードが『０』であること」が含まれる。また、２番目の作業項目について、打鍵コマンドに関する「ｃｍｄ」と「＄Ｓｅｓｓｉｏｎ；Ｇｅｔ−ＭａｉｌｂｏｘＤａｔａｂａｓｅ」という記述と、出力例に関する「ｒｅｓｕｌｔ」と「"Ｓｅｒｖｅｒ：ＴＩＧＥＲ１２３"」と「"Ｍｏｕｎｔｅｄ：Ｔｒｕｅ"」という記述と、正常条件に関する「正常条件リターンコードが『Ｍｏｕｎｔｅｄ』が『Ｔｒｕｅ』であること」という記述が含まれる。打鍵コマンドおよび出力例に関するその他の記述については、説明の簡略のため省略する。

手順書データは、子ナレッジ画面における手順表示に使用される以外に、ホスト定義ファイルの生成においても使用される。つまり、手順書データを元データとして変換を行うことによって、ホスト定義ファイルが生成される。

ホスト定義ファイルは、後述する構成管理ツールにおいて適用される。構成管理ツールは、ホスト定義ファイルにしたがって、保守対象システム２００に対するリモート操作を行い、さらに保守対象システム２００から出力されるデータに基づいて、各作業項目に関する判定を行う。そして、作業項目に関する判定結果に基づいて、子ナレッジの判定結果を出力する。つまり、構成管理ツールは、リモート操作モジュールに相当し、ホスト定義ファイルは、構成管理ツールにおいて動作する子ナレッジ自動実行プログラムに相当する。

具体的には、各作業項目について、コマンドに関するマークアップ言語の記述を、ホスト定義ファイルにおける記述形式に改める。コマンドは、一義的に置き換え可能であって、記述の変換は所定の変換ルールによって行われる。手順書データに記述されている出力例については、ホスト定義ファイルに含めなくてもよい。子ナレッジ画面の子ナレッジ手順表示領域７０４に表示される出力例は、保守員の作業を円滑にするための参考情報であって、保守対象システム２００のリモート操作において必要がないからである。

また、手順書データでは、正常条件に関する記述の前後をｄｉｖタグで挟んでいる。マークアップ言語の記述ルールによれば、ｄｉｖタグの記述は表示されないが、表示スタイルの指定や自由記述などを付加することができる。この例で、ｄｉｖタグによって、正常条件に関する表示スタイルを指定する他、正常条件の判定を行うプロシージャに関する自由記述が付加されている。ホスト定義ファイルの生成処理において、プロシージャに関する自由記述に基づいて、正常条件に関して所定の判定用プロシージャが付加される。判定用プロシージャは複数用意されており、判定の仕方に応じて使い分けられる。「ｐｒｏｃ ｃｏｎｆｉｒｍ＝」によって指定されている番号は、判定用プロシージャの種類を示す。

この例で「ｐｒｏｃ ｃｏｎｆｉｒｍ＝"０１"」で指定される判定用プロシージャは、リターンコードの正否を判定する機能を有する。このとき「ｒｃ＝」で指定されるコードは、正常値を示している。この例では「ｒｃ＝"０"」と記述されているので、リターンコードが「０」である場合に正常と判定し、リターンコードが「０」以外である場合に異常と判定するプロシージャが、ホスト定義ファイルにおける１番目の作業項目の判定ロジックとして付加される。

この例で「ｐｒｏｃ ｃｏｎｆｉｒｍ＝"１１"」で指定される判定用プロシージャは、出力コードに所定コードが含まれるか否かを判定する機能を有する。「ｓｔｒｉｎｇ＝」で指定される所定コードが含まれていれば、正常と判定する。この例では「ｓｔｒｉｎｇ＝"Ｍｏｕｎｔｅｄ：Ｔｒｕｅ"」と記述されているので、出力コードに「ｓｔｒｉｎｇ＝"Ｍｏｕｎｔｅｄ：Ｔｒｕｅ"」というコードが含まれている場合に正常と判定し、このコードが含まれていない場合に異常と判定するプロシージャが、ホスト定義ファイルにおける２番目の作業項目の判定ロジックとして付加される。

ホスト定義ファイルには、いずれかの作業項目において異常と判定された場合に、子ナレッジの判定結果として異常を出力し、いずれの作業項目においても正常と判定された場合に、子ナレッジの判定結果として正常を出力するように設定される。

なお、ホスト定義ファイルを生成するとともに、「ｐｒｏｃ ｃｏｎｆｉｒｍ＝」によって指定されている番号と、確認のためのパラメータ（「ｒｃ＝"０"」や「ｓｔｒｉｎｇ＝"Ｍｏｕｎｔｅｄ：Ｔｒｕｅ"」）をまとめたコーディングチェック用のデータを生成してもよい。このデータを用いて手順書データをチェックすればコーディングミスを防ぎやすくなる。

続いて、保守支援システムにおける処理の詳細について説明する。
保守支援システムに含まれる保守支援サーバ３００およびユーザ端末４００の各構成要素は、ＣＰＵ（Central Processing Unit）および各種コプロセッサなどの演算器、メモリやストレージといった記憶装置、それらを連結する有線または無線の通信線を含むハードウェアと、記憶装置に格納され、演算器に処理命令を供給するソフトウェアによって実現される。コンピュータプログラムは、デバイスドライバ、オペレーティングシステム、それらの上位層に位置する各種アプリケーションプログラム、また、これらのプログラムに共通機能を提供するライブラリによって構成されてもよい。以下に説明する各ブロックは、ハードウェア単位の構成ではなく、機能単位のブロックを示している。

図１２〜図１４は、保守支援サーバ３００の機能ブロック図である。
保守支援サーバ３００は、通信部３０４、データ処理部３０６およびデータ格納部３０８を含む。図１２は、通信部３０４の詳細を示す。図１３は、データ処理部３０６の詳細を示す。図１４は、データ格納部３０８の詳細を示す。

通信部３０４は、ネットワークを介して保守対象システム２００およびユーザ端末４００との通信処理を担当する。データ格納部３０８は各種データを格納する。データ処理部３０６は、通信部３０４により取得されたデータと、データ格納部３０８に格納されているデータに基づいて各種処理を実行する。データ処理部３０６は、通信部３０４およびデータ格納部３０８のインタフェースとしても機能する。

図１２に示すように通信部３０４は、データを送信する送信部３３０と、データを受信する受信部３４０を含む。
送信部３３０は、リコメンド画面送信部３３２、診断ナレッジ画面送信部３３４、子ナレッジ画面送信部３３６およびホスト定義ファイル送信部３３８を含む。
リコメンド画面送信部３３２は、リコメンド画面データをユーザ端末４００へ送信する。診断ナレッジ画面送信部３３４は、診断ナレッジ画面データをユーザ端末４００へ送信する。子ナレッジ画面送信部３３６は、子ナレッジ画面データをユーザ端末４００へ送信する。ホスト定義ファイル送信部３３８は、ホスト定義ファイルをユーザ端末４００へ送信する。

受信部３４０は、インシデント通知受信部３４２、リコメンド画面イベント受信部３４４、診断ナレッジ画面イベント受信部３４６、子ナレッジ画面イベント受信部３４８、修復結果受信部３４９および子ナレッジ判定結果受信部３５０を含む。
インシデント通知受信部３４２は、ホストコンピュータ１００からインシデント通知を受信する。リコメンド画面イベント受信部３４４は、ユーザ端末４００からリコメンド画面で発生したイベントを受信する。診断ナレッジ画面イベント受信部３４６は、ユーザ端末４００から診断ナレッジ画面で発生したイベントを受信する。子ナレッジ画面イベント受信部３４８は、ユーザ端末４００から子ナレッジ画面で発生したイベントを受信する。修復結果受信部３４９は、ユーザ端末４００から修復結果を受信する。子ナレッジ判定結果受信部３５０は、ユーザ端末４００から子ナレッジの判定結果を受信する。

図１３に示すようにデータ処理部３０６は、メッセージ取得部３６２、リコメンド処理部３６４、リコメンド画面生成部３６６、診断ナレッジ画面生成部３６８、子ナレッジ画面生成部３７０、ホスト定義ファイル生成部３７２、実績記録処理部３７４、メッセージ分類部３７６、診断パターン判定部３７８および学習モデル生成部３９２を含む。
メッセージ取得部３６２は、インシデントに伴い発生したメッセージを保守対象システム２００から取得する。リコメンド処理部３６４は、リコメンドする診断ナレッジを選択する。リコメンド処理部３６４は、メッセージ検索部３６５と学習モデル利用部３９８を含む。メッセージ検索部３６５は、教師データ収集フェーズ（Ｓ１０）において、発生メッセージに類似する見本メッセージを検索する。学習モデル利用部３９８は、学習モデルを利用して候補となる診断ナレッジにおける障害の検出成否の予測値を求める。

リコメンド画面生成部３６６は、リコメンド画面データを生成する。診断ナレッジ画面生成部３６８は、診断ナレッジ画面データを生成する。子ナレッジ画面生成部３７０は、子ナレッジ画面データを生成する。ホスト定義ファイル生成部３７２は、ホスト定義ファイルを生成する。実績記録処理部３７４は、実績データを記録する。メッセージ分類部３７６は、発生メッセージをメッセージタイプに分類する。診断パターン判定部３７８は、診断パターンの判定を行う。学習モデル生成部３９２は、学習エンジン３９４を用いて学習モデルを生成する。

図１４に示すようにデータ格納部３０８は、システム構成データ記憶部３８０、メッセージ記憶部３８２、診断ナレッジデータ記憶部３８４、子ナレッジデータ記憶部３８６、修復ナレッジデータ記憶部３８７、実績データ記憶部３８８、メッセージタイプ定義記憶部３９０および学習モデル記憶部３９６を含む。
システム構成データ記憶部３８０は、保守対象システム２００のシステム構成データを記憶する。システム構成データは、保守対象システム２００に含まれるホストコンピュータ１００のホスト名、搭載している機能モジュール、ネットワークアドレスおよびハードウェア資源などの情報を含む。メッセージ記憶部３８２は、取得した発生メッセージを記憶する。

診断ナレッジデータ記憶部３８４は、診断ナレッジデータを記憶する。診断ナレッジデータは、診断ナレッジＩＤ、診断ナレッジの名前、診断ナレッジの概要、１以上の子ナレッジＩＤおよび診断パターン情報を含む。診断パターン情報は、診断パターン毎に、１以上の子ナレッジに関する判定条件、診断結果および修復ナレッジＩＤを対応付ける。

子ナレッジデータ記憶部３８６は、子ナレッジデータを記憶する。子ナレッジデータは、子ナレッジＩＤ、子ナレッジの名前、子ナレッジの概要および手順書データなどの情報を含む。修復ナレッジデータ記憶部３８７は、修復ナレッジデータを記憶する。修復ナレッジデータは、修復ナレッジＩＤ、修復ナレッジの名前、修復ナレッジの概要および修復の手順書データなどの情報を含む。修復ナレッジデータは、修復ナレッジ自動実行プログラムを含んでもよい。

実績データ記憶部３８８は、実績データを記憶する。実績データは、上述したように一または複数のメッセージタイプと、診断ナレッジＩＤと、診断ナレッジによる障害検出の成否とを含むサンプルを多数含む。メッセージタイプ定義記憶部３９０は、メッセージタイプを定義するデータを記憶する。たとえば、各メッセージタイプの型を定義してもよい。メッセージタイプの型には、メッセージにおける可変部分と固定部分が定義されている。可変部分は、たとえばホスト名や発生日時などが設定される箇所である。固定部分は、たとえば「読み込みエラーが発生しました。」のような文やファンクションＩＤのような所定パラメータなどに相当する。あるいは、各メッセージタイプの典型を定義してもよい。学習モデル記憶部３９６は、学習モデルを定義するニューラルネットワークの重みデータを記憶する。

図１５および図１６は、ユーザ端末４００の機能ブロック図である。
ユーザ端末４００は、ユーザインターフェース処理部４０２、通信部４０４、データ処理部４０６およびデータ格納部４０８を含む。
図１５は、ユーザインターフェース処理部４０２、データ処理部４０６およびデータ格納部４０８の詳細を示す。ユーザインターフェース処理部４０２は、キーボードやタッチパネルなどの入力デバイスを介してユーザからの操作を受け付けるほか、画像表示や音声出力など、ユーザインターフェースに関する処理を担当する。通信部４０４は、ネットワークを介して保守対象システム２００および保守支援サーバ３００との通信処理を担当する。データ格納部４０８は、各種データを格納する。データ処理部４０６は、通信部４０４により取得されたデータ、ユーザインターフェース処理部４０２を介して入力された操作指示およびデータ格納部４０８に格納されているデータに基づいて各種処理を実行する。データ処理部４０６は、通信部４０４、ユーザインターフェース処理部４０２およびデータ格納部４０８のインタフェースとしても機能する。データ格納部４０８は、アプリケーションプログラムや上述したデータなどの各種データを格納する。

ユーザインターフェース処理部４０２は、ユーザからの入力を受け付ける入力部４１０と、ユーザに対して画像や音声などの各種情報を出力する出力部４３０を含む。
出力部４３０は、リコメンド画面表示処理部４３２、診断ナレッジ画面表示処理部４３４および子ナレッジ画面表示処理部４３６を含む。
リコメンド画面表示処理部４３２は、リコメンド画面をディスプレイに表示する。診断ナレッジ画面表示処理部４３４は、診断ナレッジ画面をディスプレイに表示する。子ナレッジ画面表示処理部４３６は、子ナレッジ画面をディスプレイに表示する。

入力部４１０は、リコメンド画面操作受付部４１２、診断ナレッジ画面操作受付部４１４および子ナレッジ画面操作受付部４１６を含む。
リコメンド画面操作受付部４１２は、リコメンド画面におけるユーザ操作を受け付ける。診断ナレッジ画面操作受付部４１４は、診断ナレッジ画面におけるユーザ操作を受け付ける。子ナレッジ画面操作受付部４１６は、子ナレッジ画面におけるユーザ操作を受け付ける。

データ処理部４０６は、リモート処理部４８０、診断ナレッジ自動実行部４８２、子ナレッジ自動実行部４８４、修復ナレッジ実行部４８６および構成管理ツール４８８を含む。
リモート処理部４８０は、保守対象システム２００のホストコンピュータ１００とＳＳＨ（Secure SHell）接続し、ホストコンピュータ１００に対するリモート操作を実現する。診断ナレッジ自動実行部４８２は、診断ナレッジを自動実行する。子ナレッジ自動実行部４８４は、子ナレッジを自動実行する。修復ナレッジ実行部４８６は、修復ナレッジ処理を実行する。修復ナレッジ処理で修復ナレッジの手順を示す修復ナレッジ画面を表示して、保守員が手作業で修復を行ってもよいし、修復ナレッジ処理で修復ナレッジ自動実行プログラムを自動実行してもよい。

構成管理ツール４８８は、本来保守対象システム２００の構成管理に用いられるものである。但し、ここでは保守対象システム２００へのリモート操作を行う手段として用いる。構成管理ツール４８８は、たとえばＡｎｓｉｂｌｅ（登録商標）であって、リモート処理部４８０を介して保守対象システム２００のホストコンピュータ１００を自動的にリモート操作するリモート操作モジュールの例である。構成管理ツール４８８にホスト定義ファイル（たとえば、Ａｎｓｉｂｌｅに用いられるＰｌａｙＢｏｏｋ）を適用することによって、保守対象システム２００のホストコンピュータ１００における設定や操作を自動的に行える。

データ格納部４０８は、診断ナレッジ自動実行プログラム記憶部４９０、ホスト定義ファイル記憶部４９２および修復ナレッジ自動実行プログラム記憶部４９４を含む。
診断ナレッジ自動実行プログラム記憶部４９０は、診断ナレッジを自動実行するためのプログラムを記憶する。ホスト定義ファイル記憶部４９２は、ホスト定義ファイルを記憶する。修復ナレッジ自動実行プログラム記憶部４９４は、修復ナレッジを自動実行するためのプログラムを記憶する。

図１６は、通信部４０４の詳細を示す。通信部４０４は、データを送信する送信部４５０とデータを受信する受信部４６０を含む。
送信部４５０は、リコメンド画面イベント送信部４５２、診断ナレッジ画面イベント送信部４５４、子ナレッジ画面イベント送信部４５６、子ナレッジ判定結果送信部４５８および修復結果送信部４５９を含む。
リコメンド画面イベント送信部４５２は、リコメンド画面で発生したイベントを保守支援サーバ３００へ送信する。診断ナレッジ画面イベント送信部４５４は、診断ナレッジ画面で発生したイベントを保守支援サーバ３００へ送信する。子ナレッジ画面イベント送信部４５６は、子ナレッジ画面で発生したイベントを保守支援サーバ３００へ送信する。子ナレッジ判定結果送信部４５８は、子ナレッジの判定結果を保守支援サーバ３００へ送信する。修復結果送信部４５９は、修復結果を保守支援サーバ３００へ送信する。

受信部４６０は、リコメンド画面受信部４６２、診断ナレッジ画面受信部４６４、子ナレッジ画面受信部４６６およびホスト定義ファイル受信部４６８を含む。
リコメンド画面受信部４６２は、保守支援サーバ３００からリコメンド画面データを受信する。診断ナレッジ画面受信部４６４は、保守支援サーバ３００から診断ナレッジ画面データを受信する。子ナレッジ画面受信部４６６は、保守支援サーバ３００から子ナレッジ画面データを受信する。ホスト定義ファイル受信部４６８は、保守支援サーバ３００からホスト定義ファイルを受信する。

図１７〜図１９は、保守支援サーバ３００のメイン処理過程を示すフローチャート図である。
以下、保守支援サーバ３００における処理について説明し、さらに保守支援サーバ３００と連動するユーザ端末４００の処理についても併せて述べる。

なお、教師データ収集フェーズ（Ｓ１０）および学習モデル適用フェーズ（Ｓ１４）において、保守支援サーバ３００のメイン処理過程は、大筋において共通である。教師データ収集フェーズ（Ｓ１０）と学習モデル適用フェーズ（Ｓ１４）とでは、リコメンドの方式が異なる。教師データ収集フェーズ（Ｓ１０）では、メッセージの検索によってリコメンドする診断ナレッジを決める。学習モデル適用フェーズ（Ｓ１４）では、学習モデルを用いてリコメンドする診断ナレッジを決める。

インシデント通知受信部３４２が保守対象システム２００からインシデント通知を受信すると（Ｓ２０）、メッセージ取得部３６２は、保守対象システム２００からメッセージを取得する（Ｓ２２）。取得したメッセージは、メッセージ記憶部３８２に記憶される。

保守支援サーバ３００のリコメンド処理部３６４は、リコメンド処理を実行する（Ｓ２４）。リコメンド処理では、まず発生メッセージの中から検索キーとするメッセージを特定する。たとえば、発生メッセージの一覧をユーザ端末４００に送信し、ユーザ端末４００において表示された発生メッセージの一覧の中から保守員が着目するメッセージを選択してもよい。あるいは、保守支援サーバ３００において自動的に着目する発生メッセージを選別してもよい。たとえば、同種のメッセージが多数発生している場合に、発生頻度が高いメッセージを選択してもよい。

リコメンド処理部３６４は、選択した発生メッセージを検索キーとして、各見本メッセージとの類似判定を行う。検索キーの発生メッセージと見本メッセージの類似判定の方法は、任意であり、文類似判定の従来技術を用いてもよい。たとえば、エラスティックサーチ（登録商標）という全文検索エンジンを用いてもよい。リコメンド処理部３６４は、文類似判定により、発生メッセージと見本メッセージの類似度を求めることができる。リコメンド処理部３６４は、類似度が高い順に所定数の見本メッセージを選択する。リコメンド処理部３６４は、発生メッセージおよび選択した見本メッセージをそれぞれ単語に分割する。そして、発生メッセージと見本メッセージの各組み合わせにおいて、それぞれのメッセージに含まれる単語間の関連度を示すシンプソン係数を算出する。そして、シンプソン係数に基づいてリコメンド指標を算出する。たとえば、すべての単語の組み合わせについてシンプソン係数を求めて、その平均値をリコメンド指標としてもよい。あるいは、シンプソン係数の大きいものを所定数だけ抽出して、その平均値をリコメンド指標としてもよい。

このようにすれば、検索キーのメッセージに含まれる単語と意味的に近い単語を含む見本メッセージのリコメンド指数が大きい値を示すようになる。そして、リコメンド指数が大きい順にその見本メッセージに対応する診断ナレッジを優先的に推薦する。なお、診断ナレッジ毎にキーワードを設定しておき、発生メッセージにそのキーワードが含まれる場合に、その診断メッセージのリコメンド指標を高めるように補正してもよい。単純な例では、類似度をリコメンド指標としてもよい。

また、すべての発生メッセージを検索キーとして、それぞれに発生メッセージに対して推薦される診断メッセージを特定し、推薦回数が多いものを優先的に推薦するようにしてもよい。

リコメンド画面生成部３６６は、リコメンド処理の結果に基づいて、リコメンド画面データを生成する（Ｓ２６）。リコメンド画面生成部３６６は、リコメンド指数が大きい順に３つの診断ナレッジ名を、診断ナレッジ名表示領域５００ａ〜５００ｃに設定し、それらに対応するリコメンド指数をリコメンド指標表示領域５０２ａ〜５０２ｃに設定する。リコメンド画面送信部３３２は、生成したリコメンド画面データをユーザ端末４００へ送信する。

ユーザ端末４００のリコメンド画面受信部４６２がリコメンド画面データを受信すると、リコメンド画面表示処理部４３２は、リコメンド画面（図７参照）を表示する。リコメンド画面操作受付部４１２が、リコメンド画面における診断ナレッジ名表示領域５００の選択操作と、診断ナレッジ表示ボタン５０４へのタッチを受け付けると、リコメンド画面イベント送信部４５２は、診断ナレッジ表示イベントを保守支援サーバ３００へ送信する。

保守支援サーバ３００のリコメンド画面イベント受信部３４４が診断ナレッジ表示イベントを受信すると、図１８のＳ３４の処理へ移る（Ｓ２８のＹ）。Ｓ３０およびＳ３２については、説明の便宜のため後述する。

図１８の説明に移る。保守支援サーバ３００の診断ナレッジ画面生成部３６８は、診断ナレッジデータ記憶部３８４に基づいて、診断ナレッジ画面データを生成する（Ｓ３４）。診断ナレッジ画面送信部３３４は、生成した診断ナレッジ画面データをユーザ端末４００へ送信する。

ユーザ端末４００の診断ナレッジ画面受信部４６４が診断ナレッジ画面データを受信すると、診断ナレッジ画面表示処理部４３４は、受信したリコメンド画面データを用いてリコメンド画面を表示する。診断ナレッジ画面操作受付部４１４は、子ナレッジ手順表示ボタン６０６へのタッチ操作を受け付けると、診断ナレッジ画面イベント送信部４５４は、子ナレッジ手順表示イベントを保守支援サーバ３００へ送信する。

保守支援サーバ３００の診断ナレッジ画面イベント受信部３４６が子ナレッジ手順表示イベントを受信すると（Ｓ３６のＹ）、子ナレッジ画面生成部３７０は、子ナレッジデータ記憶部３８６に基づいて子ナレッジ画面データを生成する（Ｓ３８）。子ナレッジ画面送信部３３６は、生成した子ナレッジ画面データをユーザ端末４００へ送信する。

ユーザ端末４００の子ナレッジ画面受信部４６６が子ナレッジ画面データを受信すると、子ナレッジ画面表示処理部４３６は、受信した子ナレッジ画面データを用いて、子ナレッジ画面を表示する。子ナレッジ画面操作受付部４１６は、子ナレッジ判定結果ボタン７０６へのタッチ操作を受け付けると、子ナレッジ画面イベント送信部４５６は、子ナレッジ判定結果（＜正常＞または＜異常＞）を保守支援サーバ３００へ送信する。

保守支援サーバ３００の子ナレッジ判定結果受信部３５０が子ナレッジ判定結果を受信すると（Ｓ４０のＹ）、診断ナレッジ画面生成部３６８は、図９に関連して説明したとおり子ナレッジ判定結果に応じて診断ナレッジ画面データを更新する（Ｓ４２）。診断ナレッジ画面送信部３３４は、更新された診断ナレッジ画面データをユーザ端末４００へ送信する。受信したユーザ端末４００の処理および保守支援サーバ３００は、Ｓ３４からＳ３６までの場合と同様である。

ユーザ端末４００の子ナレッジ画面操作受付部４１６が子ナレッジ自動化ボタン６０８への操作を受け付けると（Ｓ４４のＹ）、子ナレッジ画面イベント送信部４５６は、子ナレッジ自動化イベントを保守支援サーバ３００へ送信する。

保守支援サーバ３００の子ナレッジ画面イベント受信部３４８が子ナレッジ自動化イベントを受信すると（Ｓ４０）、ホスト定義ファイル生成部３７２は、上述したように、診断ナレッジの手順書データをホスト定義ファイルへ変換して、ホスト定義ファイルを生成する（Ｓ４６）。ホスト定義ファイル送信部３３８は。ホスト定義ファイルをユーザ端末４００へ送信する。

ユーザ端末４００のホスト定義ファイル受信部４６８がホスト定義ファイルを受信すると、受信したホスト定義ファイルをホスト定義ファイル記憶部４９２に記憶する。

また、保守支援サーバ３００の診断ナレッジ画面生成部３６８は、子ナレッジ自動実行ボタン６０８をアクティブ化するように、診断ナレッジ画面データを更新する（Ｓ４８）。診断ナレッジ画面送信部３３４は、更新された診断ナレッジ画面データをユーザ端末４００へ送信する。受信したユーザ端末４００の処理および保守支援サーバ３００の処理は、Ｓ３４からＳ３６までの場合と同様である。

Ｓ３６において、保守支援サーバ３００の診断ナレッジ画面イベント受信部３４６が子ナレッジ手順表示イベントを受信していない場合には（Ｓ３６のＹ）、図１９に示したＳ５０の処理へ移る。

図１９の説明に移る。ユーザ端末４００の子ナレッジ画面操作受付部４１６がリコメンド画面の子ナレッジ自動実行ボタン６０８へのタッチ操作を受け付けると、子ナレッジ自動実行部４８４は、選択された子ナレッジの手順を自動実行する。具体的には、子ナレッジ自動実行部４８４は、ホスト定義ファイル記憶部４９２において子ナレッジに対応付けられているホスト定義ファイルを構成管理ツール４８８に適用させ、構成管理ツール４８８に自動的なリモート操作処理を行わせる。そして、子ナレッジ判定結果送信部４５８は、構成管理ツール４８８から出力される子ナレッジ判定結果を保守支援サーバ３００へ送信する。

保守支援サーバ３００の子ナレッジ判定結果受信部３５０が子ナレッジ判定結果を受信すると（Ｓ５０）、診断ナレッジ画面生成部３６８は、図９に関連して説明したとおり子ナレッジ判定結果に応じて診断ナレッジ画面データを更新する（Ｓ５２）。診断ナレッジ画面送信部３３４は、更新された診断ナレッジ画面データをユーザ端末４００へ送信する。受信したユーザ端末４００の処理および保守支援サーバ３００は、図１８のＳ３４からＳ３６までの場合と同様である。

ユーザ端末４００の診断ナレッジ画面操作受付部４１４がリコメンド画面の修復ナレッジボタン６１６へのタッチ操作を受け付けると、修復ナレッジ実行部４８６は、修復ナレッジ処理を実行する。修復ナレッジ処理では、修復ナレッジ画面を表示する。保守員は、修復ナレッジ画面に表示された手順に沿って、修復作業を行う。修復作業を終えて修復結果ボタンが選択されると、修復結果送信部４５９は、修復結果（「完了」または「未了」）を保守支援サーバ３００へ送信する。修復ナレッジ画面で自動実行を指示された場合には、修復ナレッジの自動実行プログラムを実行する。修復結果送信部４５９は、自動実行による修復結果を保守支援サーバ３００へ送信する。

保守支援サーバ３００の子ナレッジ判定結果受信部３５０が修復結果を受信すると（Ｓ５４）、実績記録処理部３７４は、検出成功を示す実績データを記録する（Ｓ５６）。修復結果を受信したということは、障害が検出されたことを前提としているからである。

このとき、メッセージ分類部３７６は、インシデントに伴い発生したメッセージをメッセージタイプに分類する。具体的には、発生メッセージを、メッセージタイプ定義記憶部３９０に記憶されている各メッセージタイプの型と比較する。メッセージタイプの型に合致すれは、そのメッセージタイプに属すると判断する。メッセージタイプの型には、上述したようにメッセージにおける可変部分と固定部分が定義されている。可変部分は任意であるので比較を行わない。固定部分が一致した場合に、その型に合致すると判定する。あるいは、発生メッセージと、メッセージタイプ定義記憶部３９０に記憶されている各メッセージタイプの典型メッセージとの類似判定を行って、最も高い類似度が得られた典型メッセージのタイプに分類するようにしてもよい。発生メッセージをメッセージタイプに分類する方法は、任意であって他の従来技術を用いてもよい。

実績記録処理部３７４は、一つのサンプルとして、一または複数のメッセージタイプと、診断ナレッジＩＤと、検出成功とを含むサンプルを実績データ記憶部３８８に記憶する。実績記録処理部３７４は、更に修復結果として「完了」または「未了」を記録してもよい。

ユーザ端末４００の診断ナレッジ画面操作受付部４１４が診断ナレッジ画面の戻るボタン６１８へのタッチ操作を受け付けると、子ナレッジ画面イベント送信部４５６は、リターンイベントを保守支援サーバ３００へ送信する。リターンイベントは、検出成功を示す場合と、検出失敗を示す場合と、中断を示す場合とがある。図９で説明したように、診断パターン１又は２に合致して「メールＤＢ非接続」あるいは「メールキュー滞留」が判定された場合のように、診断結果として障害が特定されている場合には、検出成功を示すリターンイベントが送られる。診断パターン３に合致して「障害非検出」と判定された場合には、検出失敗を示すリターンイベントが送られる。これら以外の場合には、中断を示すリターンイベントが送られる。

保守支援サーバ３００の子ナレッジ画面イベント受信部３４８がリターンイベントを受信し（Ｓ５８のＹ）、リターンイベントが検出成功を示している場合には、Ｓ５６の場合と同様に検出成功を示す実績データを記録する（Ｓ６０）。リターンイベントが検出失敗を示している場合には、実績記録処理部３７４は、検出失敗を示す実績データを記録する（Ｓ６０）。このときメッセージ分類部３７６は、上述したように、インシデントに伴い発生したメッセージをメッセージタイプに分類する。実績記録処理部３７４は、一つのサンプルとして、一または複数のメッセージタイプと、診断ナレッジＩＤと、検出失敗とを含むサンプルを実績データ記憶部３８８に記憶する。リターンイベントが中断を示している場合には、実績データを記録しない。そして、図１７に示したＳ２８の処理へ移る。

図１７の説明に戻る。ユーザ端末４００のリコメンド画面操作受付部４１２が、リコメンド画面における診断ナレッジ名表示領域５００の選択操作と、診断ナレッジ自動実行ボタン５０６へのタッチを受け付けると、診断ナレッジ自動実行部４８２は、診断ナレッジを自動実行する。診断ナレッジ自動実行処理については、図２０に関連して後述する。診断ナレッジ自動実行処理の最後に、修復結果送信部４５９は、診断結果（「メールＤＢ非接続」、「「メールキュー滞留」または「障害非検出」）と共に、診断ナレッジ自動実行処理による修復結果（「完了」または「未了」）を保守支援サーバ３００へ送信する。

保守支援サーバ３００の子ナレッジ判定結果受信部３５０が修復結果を受信すると（Ｓ３０のＹ）、Ｓ２６に戻って、リコメンド画面生成部３６６は、修復結果を設定したリコメンド画面データを生成する。リコメンド画面データの送信およびリコメンド画面の表示の処理については、上述のとおりである。これにより、修復結果が反映されたリコメンド画面が表示される。

ユーザ端末４００のリコメンド画面操作受付部４１２が、リコメンド画面の閉じるボタン５１２へのタッチを受け付けると、リコメンド画面イベント送信部４５２は、終了イベントを保守支援サーバ３００へ送信する。そして、ユーザ端末４００は、リコメンド画面を閉じて処理を終える。

保守支援サーバ３００のリコメンド画面イベント受信部３４４が終了イベントを受信すると（Ｓ３２のＹ）、保守支援サーバ３００におけるメイン処理を終える。

図２０は、診断ナレッジ自動実行処理過程を示すフローチャート図である。
診断ナレッジ自動実行部４８２が、診断ナレッジ自動実行プログラム記憶部４９０に記憶されている診断ナレッジ自動実行プログラムに従って、診断ナレッジ自動実行処理を制御する。図示した例は、診断ナレッジ「メールボックス異常診断」に関する診断ナレッジ自動実行プログラムにしたがって、診断ナレッジ自動実行部４８２が診断ナレッジ「メールボックス異常診断」を自動実行する処理を示している。

診断ナレッジ自動実行部４８２は、子ナレッジ「メールＤＢの接続確認」を子ナレッジ自動実行部４８４に自動実行させる（Ｓ７０）。子ナレッジ自動実行部４８４における子ナレッジ自動実行処理については、上述のとおりである。

子ナレッジ「メールＤＢの接続確認」の自動実行による判定結果が「２：非接続＜異常＞」であれば（Ｓ７２のＹ）、実績記録処理部３７４は、検出成功を示す実績データを記録する（Ｓ７４）。そして、診断ナレッジ自動実行部４８２は、修復ナレッジ実行部４８６に修復ナレッジ「メールＤＢの再接続」を自動実行させる。そして、修復結果送信部４５９は、修復ナレッジ実行部４８６による修復結果を保守支援サーバ３００へ送信する。修復ナレッジ「メールＤＢの再接続」が正常に終了すれば、修復結果は「完了」となる。修復ナレッジ「メールＤＢの再接続」が正常終了しなければ、修復結果は「未了」となる。「メールＤＢの再接続」を阻む他の障害があれば、修復ナレッジ「メールＤＢの再接続」が正常に終了しないこともある。修復結果送信部４５９は、診断結果（障害の種類：「メールＤＢ非接続」）も併せて送る。

子ナレッジ「メールＤＢの接続確認」の自動実行による判定結果が「１：接続中＜正常＞」であって、「２：非接続＜異常＞」でない場合には（Ｓ７２のＮ）、診断ナレッジ自動実行部４８２は、子ナレッジ「メールキューの滞留確認」を子ナレッジ自動実行部４８４に自動実行させる（Ｓ７８）。

子ナレッジ「メールキューの滞留確認」の自動実行による判定結果が「２：滞留有り＜異常＞」であれば（Ｓ８０のＹ）、実績記録処理部３７４は、検出成功を示す実績データを記録する（Ｓ８２）。診断ナレッジ自動実行部４８２は、修復ナレッジ実行部４８６に修復ナレッジ「問題プロセスの再起動」を自動実行させる。そして、修復結果送信部４５９は、修復ナレッジ実行部４８６による修復結果を保守支援サーバ３００へ送信する（Ｓ８８）。修復ナレッジ「問題プロセスの再起動」が正常に終了すれば、修復結果は「完了」となる。修復ナレッジ「問題プロセスの再起動」が正常終了しなければ、修復結果は「未了」となる。「問題プロセスの再起動」を阻む他の障害があれば、修復ナレッジ「問題プロセスの再起動」が正常に終了しないこともある。修復結果送信部４５９は、診断結果（障害の種類：「メールキュー滞留」）も併せて送る。

子ナレッジ「メールキューの滞留確認」の自動実行による判定結果が「１：滞留無し＜正常＞」であって、「２：滞留有り＜異常＞」でない場合には（Ｓ８０のＹ）、実績記録処理部３７４は、検出失敗を示す実績データを記録する（Ｓ８６）。この場合、修復結果送信部４５９は、「障害非検出」の診断結果と「未了」の修復結果を保守支援サーバ３００へ送信する（Ｓ８８）。

続いて、学習モデル生成フェーズ（Ｓ１２）について説明する。まず、ニューラルネットワークの構成について述べる。

図２１は、実施形態におけるニューラルネットワークの構成図である。
実施形態におけるニューラルネットワークは、各メッセージタイプおよび各診断ナレッジに対応する複数の入力ノードと、複数の中間ノードと、検出結果に対応する１つの出力ノードを有する。この例では、メッセージタイプＩＤがＭＴ００１からＭＴ１００までのメッセージタイプに対応する１００個の入力ノードが設けられ、さらに診断ナレッジＩＤがＤＮ００１からＤＮ０５０までの５０個の入力ノードが設けられている。

学習モデル生成フェーズ（Ｓ１２）で、学習モデル生成部３９２は、教師データの各サンプルについて、サンプルに含まれるメッセージタイプおよび診断ナレッジに対応する入力ノードに「１」を設定し、それ以外の入力ノードに「０」を設定する。また、検出結果が「成功」である場合に出力ノードに「１」を設定し、検出結果が「失敗」である場合に出力ノードに「０」を設定する。そして、学習モデル生成部３９２は、各サンプルに関して重みデータを調整する。重みデータは、学習モデル記憶部３９６に記憶される。

たとえば、あるインシデントにおいて発生したメッセージが、メッセージタイプＩＤがＭＴ０１０、ＭＴ０２０およびＭＴ０３０のメッセージタイプに分類され、診断ナレッジＩＤがＤＮ０４０の診断ナレッジによって診断した結果、障害を検出できなかったことを示すサンプルがあった場合、メッセージタイプＩＤのＭＴ０１０に対応する入力ノード、ＭＴ０２０に対応する入力ノードおよびＭＴ０３０に対応する入力ノードに「１」を設定し、メッセージタイプＩＤのＭＴ００１〜ＭＴ００９に対応する各入力ノード、ＭＴ０１１〜ＭＴ０１９に対応する各入力ノード、ＭＴ０２１〜ＭＴ０２９に対応する各入力ノードおよびＭＴ０３１〜ＭＴ１００に対応する各入力ノードに「０」を設定する。さらに、診断ナレッジＩＤのＤＮ０４０に対応する入力ノードに「１」を設定し、診断ナレッジＩＤのＤＮ００１〜ＤＮ０３９に対応する各入力ノードおよびＤＮ０４１〜ＤＮ０５０に対応する各入力ノードに「０」を設定し、検出結果に対応する出力ノードに「０」を設定する。そして、重みデータを調整する。

さらに、同じインシデントに関して、診断ナレッジＩＤがＤＮ０４１の診断ナレッジによって診断した結果、障害を検出できたことを示すサンプルがあった場合、各メッセージタイプＩＤに対応する入力ノードについては、前回と同様に設定し、診断ナレッジＩＤのＤＮ０４１に対応する入力ノードに「１」を設定し、診断ナレッジＩＤのＤＮ００１〜ＤＮ０４０に対応する各入力ノードおよびＤＮ０４２〜ＤＮ０５０に対応する各入力ノードに「０」を設定し、検出結果に対応する出力ノードに「１」を設定する。そして、重みデータを調整する。

このようにして、ニューラルネットワークで最適解となる重みデータを学習させる。重みデータは、学習モデル記憶部３９６に記憶される。ニューラルネットワークを用いた学習の手順自体は、従来技術である。

続いて、学習モデル適用フェーズ（Ｓ１４）について説明する。学習モデル適用フェーズ（Ｓ１４）では、リコメンド処理部３６４は、メッセージ検索部３６５を用いずに、学習モデル利用部３９８を用いる。

図２２は、学習モデルを利用したリコメンド処理過程を示すフローチャート図である。
まず、メッセージ分類部３７６が、発生メッセージをメッセージタイプに分類する（Ｓ９０）。分類方法は、教師データ収集フェーズ（Ｓ１０）で実績データを記録した場合の分類方法と同様である。

学習モデル利用部３９８は、各診断ナレッジを候補として、診断ナレッジ毎に学習モデルを利用して検出成功の予測値を求める。そのために学習モデル利用部３９８は、診断ナレッジを１つずつ特定する（Ｓ９２）。

学習モデル利用部３９８は、メッセージタイプおよび候補とする診断ナレッジに対応する入力ノードに「１」を設定し、それ以外の入力ノードに「０」を設定する。そして、学習済みの重みデータを使用してニューラルネットワークの演算を行い、検出結果の出力ノードから候補の診断ナレッジによる検出成功の予測値を得る（Ｓ９４）。

たとえば、インシデント発生の通知を受けて取得したメッセージを分類した結果、メッセージタイプＩＤがＭＴ０４０、ＭＴ０５０およびＭＴ０６０のメッセージタイプにまとめられ、診断ナレッジＩＤがＤＮ０４２の診断ナレッジを用いることを想定する場合、メッセージタイプＩＤのＭＴ０４０に対応する入力ノード、ＭＴ０５０に対応する入力ノードおよびＭＴ０６０に対応する入力ノードに「１」を設定し、メッセージタイプＩＤのＭＴ００１〜ＭＴ０３９に対応する各入力ノード、ＭＴ０４１〜ＭＴ０４９に対応する各入力ノード、ＭＴ０５１〜ＭＴ０５９に対応する各入力ノードおよびＭＴ０６１〜ＭＴ１００に対応する各入力ノードに「０」を設定する。さらに、診断ナレッジＩＤのＤＮ０４２に対応する入力ノードに「１」を設定し、診断ナレッジＩＤのＤＮ００１〜ＤＮ０４１に対応する各入力ノードおよびＤＮ０４３〜ＤＮ０５０に対応する各入力ノードに「０」を設定し、学習済みの重みデータを使用してニューラルネットワークの演算を行えば、検出結果に対応するノードから診断ナレッジＩＤがＤＮ０４２の診断ナレッジによる検出成功の予測値を得ることができる。

検出成功の予測値は、０から１までの連続値を示す。検出成功の予測値が小さい値であれば、検出成功の可能性が低く、検出成功の予測値が大きい値であれば、検出成功の可能性が高いことを意味する。

学習モデル利用部３９８は、すべての診断ナレッジについて検出成功の予測値を求めるまで、Ｓ９２からＳ９６の処理を繰り返す。

リコメンド処理部３６４は、検出成功の予測値が大きい順に診断ナレッジの列を並び替え、上位から所定数の診断ナレッジをリコメンドするものとして選択する（Ｓ９８）。なお、検出成功の予測値を、リコメンド指数として用いる。

［変形例１］
変形例１では、実施形態の場合とニューラルネットワークの構成が異なる。変形例１におけるニューラルネットワークには、検出成功と検出失敗に対応する２つの出力ノードを設ける。

図２３は、変形例１におけるニューラルネットワークの構成図である。
変形例１におけるニューラルネットワークは、各メッセージタイプおよび各診断ナレッジに対応する複数の入力ノードと、複数の中間ノードと、検出成功と検出失敗に対応する２つの出力ノードを有する。つまり、出力ノードの構成のみが、実施形態の場合と異なる。

学習モデル生成フェーズ（Ｓ１２）で、学習モデル生成部３９２は、教師データの各サンプルについて、サンプルに含まれるメッセージタイプおよび診断ナレッジに対応する入力ノードに「１」を設定し、それ以外の入力ノードに「０」を設定する。また、検出結果が「成功」である場合に検出成功の出力ノードに「１」を設定し、検出失敗の出力ノードに「０」を設定する。検出結果が「失敗」である場合には、検出失敗の出力ノードに「１」を設定し、検出成功の出力ノードに「０」を設定する。そして、学習モデル生成部３９２は、各サンプルに関して重みデータを調整する。このようにして、ニューラルネットワークで最適解となる重みデータを学習させる。重みデータは、学習モデル記憶部３９６に記憶される。

実施形態で挙げたサンプル例と同様に、あるインシデントにおいて発生したメッセージが、メッセージタイプＩＤがＭＴ０１０、ＭＴ０２０およびＭＴ０３０のメッセージタイプに分類され、診断ナレッジＩＤがＤＮ０４０の診断ナレッジによって診断した結果、障害を検出できなかったことを示すサンプルがあった場合、メッセージタイプＩＤのＭＴ０１０に対応する入力ノード、ＭＴ０２０に対応する入力ノードおよびＭＴ０３０に対応する入力ノードに「１」を設定し、メッセージタイプＩＤのＭＴ００１〜ＭＴ００９に対応する各入力ノード、ＭＴ０１１〜ＭＴ０１９に対応する各入力ノード、ＭＴ０２１〜ＭＴ０２９に対応する各入力ノードおよびＭＴ０３１〜ＭＴ１００に対応する各入力ノードに「０」を設定する。さらに、診断ナレッジＩＤのＤＮ０４０に対応する入力ノードに「１」を設定し、診断ナレッジＩＤのＤＮ００１〜ＤＮ０３９に対応する各入力ノードおよびＤＮ０４１〜ＤＮ０５０に対応する各入力ノードに「０」を設定し、検出成功に対応する出力ノードに「０」を設定し、検出失敗に対応する出力ノードに「１」を設定する。そして、重みデータを調整する。

さらに、同じインシデントに関して、診断ナレッジＩＤがＤＮ０４１の診断ナレッジによって診断した結果、障害を検出できたことを示すサンプルがあった場合、各メッセージタイプＩＤに対応する入力ノードについては、前回と同様に設定し、診断ナレッジＩＤのＤＮ０４１に対応する入力ノードに「１」を設定し、診断ナレッジＩＤのＤＮ００１〜ＤＮ０４０に対応する各入力ノードおよびＤＮ０４２〜ＤＮ０５０に対応する各入力ノードに「０」を設定し、検出成功に対応する出力ノードに「１」を設定し、検出失敗に対応する出力ノードに「０」を設定する。そして、重みデータを調整する。

変形例１の学習モデル適用フェーズ（Ｓ１４）における学習モデルを利用したリコメンド処理過程について、図２２を参考にして説明する。発生メッセージの分類（Ｓ９０）および診断ナレッジの特定（Ｓ９２）については、実施形態の場合と同様である。変形例１の場合、Ｓ９４において検出成功の出力ノードから検出成功の予測値が得られるとともに、検出失敗の出力ノードから検出失敗の予測値も得られる。

実施形態で挙げた適用例と同様に、インシデント発生の通知を受けて取得したメッセージを分類した結果、メッセージタイプＩＤがＭＴ０４０、ＭＴ０５０およびＭＴ０６０のメッセージタイプにまとめられ、診断ナレッジＩＤがＤＮ０４２の診断ナレッジを用いることを想定する場合、メッセージタイプＩＤのＭＴ０４０に対応する入力ノード、ＭＴ０５０に対応する入力ノードおよびＭＴ０６０に対応する入力ノードに「１」を設定し、メッセージタイプＩＤのＭＴ００１〜ＭＴ０３９に対応する各入力ノード、ＭＴ０４１〜ＭＴ０４９に対応する各入力ノード、ＭＴ０５１〜ＭＴ０５９に対応する各入力ノードおよびＭＴ０６１〜ＭＴ１００に対応する各入力ノードに「０」を設定する。さらに、診断ナレッジＩＤのＤＮ０４２に対応する入力ノードに「１」を設定し、診断ナレッジＩＤのＤＮ００１〜ＤＮ０４１に対応する各入力ノードおよびＤＮ０４３〜ＤＮ０５０に対応する各入力ノードに「０」を設定し、学習済みの重みデータを使用してニューラルネットワークの演算を行えば、検出成功に対応するノードから診断ナレッジＩＤがＤＮ０４２の診断ナレッジによる検出成功の予測値を得て、さらに検出失敗に対応するノードから同診断ナレッジによる検出失敗の予測値を得ることができる。

検出成功の予測値は、０から１までの連続値を示す。検出成功の予測値が小さい値であれば、検出成功の可能性が低く、検出成功の予測値が大きい値であれば、検出成功の可能性が高いことを意味する。検出失敗の予測値も、０から１までの連続値を示す。検出失敗の予測値が小さい値であれば、検出失敗の可能性が低く、検出失敗の予測値が大きい値であれば、検出失敗の可能性が高いことを意味する。

学習モデル利用部３９８は、すべての診断ナレッジについて検出成功の予測値および検出失敗の予測値を求めるまで、Ｓ９２からＳ９６の処理を繰り返す。

リコメンド処理部３６４は、検出成功の予測値から検出失敗の予測値を引いた差分を基準値とする。その基準値が大きい順に診断ナレッジの列を並び替え、上位から所定数の診断ナレッジをリコメンドするものとして選択する。この基準値は、−１から１までの連続値を示す。リコメンド指数には、この基準値を用いる。

あるいは、リコメンド処理部３６４は、１から検出失敗の予測値を引いた差分を基準値としてもよい。その基準値が大きい順に診断ナレッジの列を並び替え、上位から所定数の診断ナレッジをリコメンドするものとして選択する。この基準値は、０から１までの連続値を示す。リコメンド指数に、この基準値を用いてもよい。

［変形例２］
学習モデルにおいて、上述したように診断ナレッジ毎に検出成功の予測値を求めるのではなく、一括して各診断ナレッジにおける検出成功の予測値を求めてもよい。

図２４は、変形例２におけるニューラルネットワークの構成図である。
変形例２におけるニューラルネットワークは、各メッセージタイプに対応する複数の入力ノードと、複数の中間ノードと、および各診断ナレッジに対応する複数の出力ノードを有する。そして、変形例２では、教師データのうち検出結果が「成功」であるサンプルのみを用いる。

変形例２の学習モデル生成フェーズ（Ｓ１２）で、学習モデル生成部３９２は、検出結果が「成功」である各サンプルについて、サンプルに含まれるメッセージタイプに対応する入力ノードに「１」を設定し、それ以外の入力ノードに「０」を設定する。また、サンプルに含まれる診断ナレッジＩＤに対応する出力ノードに「１」を設定し、それ以外の出力ノードに「０」を設定する。そして、学習モデル生成部３９２は、各サンプルに関して重みデータを調整する。このようにして、ニューラルネットワークに最適解となる重みデータを学習させる。重みデータは、学習モデル記憶部３９６に記憶される。

実施形態で挙げたサンプル例と同様に、あるインシデントにおいて発生したメッセージが、メッセージタイプＩＤがＭＴ０１０、ＭＴ０２０およびＭＴ０３０のメッセージタイプに分類され、診断ナレッジＩＤがＤＮ０４０の診断ナレッジによって診断した結果、障害を検出できなかったことを示すサンプルがあった場合、このサンプルは、学習に用いない。

さらに、同じインシデントに関して、診断ナレッジＩＤがＤＮ０４１の診断ナレッジによって診断した結果、障害を検出できたことを示すサンプルがあった場合、メッセージタイプＩＤのＭＴ０１０に対応する入力ノード、ＭＴ０２０に対応する入力ノードおよびＭＴ０３０に対応する入力ノードに「１」を設定し、メッセージタイプＩＤのＭＴ００１〜ＭＴ００９に対応する各入力ノード、ＭＴ０１１〜ＭＴ０１９に対応する各入力ノード、ＭＴ０２１〜ＭＴ０２９に対応する各入力ノードおよびＭＴ０３１〜ＭＴ１００に対応する各入力ノードに「０」を設定する。さらに、診断ナレッジＩＤのＤＮ０４１に対応する出力ノードに「１」を設定し、診断ナレッジＩＤのＤＮ００１〜ＤＮ０４０に対応する各出力ノードおよびＤＮ０４２〜ＤＮ０５０に対応する各出力ノードに「０」を設定する。そして、重みデータを調整する。

図２５は、変形例２において学習モデルを利用したリコメンド処理過程を示すフローチャート図である。
変形例２における学習モデルの利用は、一つのインシデントに関して１回で済む。まずメッセージ分類部３７６は、発生メッセージをメッセージタイプに分類する（Ｓ１００）。分類方法は、教師データ収集フェーズ（Ｓ１０）で実績データを記録した場合の分類方法と同様である。

学習モデル利用部３９８は、分類したメッセージタイプに対応する入力ノードに「１」を設定し、それ以外の入力ノードに「０」を設定する。そして、学習済みの重みデータを使用してニューラルネットワークの演算を行い、各出力ノードから診断ナレッジによる検出成功の予測値を得る（Ｓ１０２）。

実施形態で挙げた適用例と同様に、インシデント発生の通知を受けて取得したメッセージを分類した結果、メッセージタイプＩＤがＭＴ０４０、ＭＴ０５０およびＭＴ０６０のメッセージタイプにまとめられたことを想定する場合、メッセージタイプＩＤのＭＴ０４０に対応する入力ノード、ＭＴ０５０に対応する入力ノードおよびＭＴ０６０に対応する入力ノードに「１」を設定し、メッセージタイプＩＤのＭＴ００１〜ＭＴ０３９に対応する各入力ノード、ＭＴ０４１〜ＭＴ０４９に対応する各入力ノード、ＭＴ０５１〜ＭＴ０５９に対応する各入力ノードおよびＭＴ０６１〜ＭＴ１００に対応する各入力ノードに「０」を設定する。そして、学習済みの重みデータを使用してニューラルネットワークの演算を行えば、各診断ナレッジＩＤに対応する出力ノードからその診断ナレッジを用いた場合の検出成功の予測値を得ることができる。

検出成功の予測値は、０から１までの連続値を示す。検出成功の予測値が小さい値であれば、検出成功の可能性が低く、検出成功の予測値が大きい値であれば、検出成功の可能性が高いことを意味する。

リコメンド処理部３６４は、検出成功の予測値が大きい順に診断ナレッジの列を並び替え、上位から所定数の診断ナレッジをリコメンドするものとして選択する（Ｓ１０４）。検出成功の予測値がより大きい診断ナレッジを選択することは、障害検出が成功すると見込まれる診断ナレッジを推定することに相当する。なお、検出成功の予測値を、リコメンド指数として用いる。

［変形例３］
ユーザ端末４００を用いずに、保守支援サーバ３００の処理だけでインシデント対応を完全自動化してもよい。

変形例３では、保守支援サーバ３００のデータ処理部３０６において、ユーザ端末４００と同様のリモート処理部４８０、診断ナレッジ自動実行部４８２、子ナレッジ自動実行部４８４、修復ナレッジ実行部４８６、構成管理ツール４８８および完全自動実行制御部（不図示）を有する。また、保守支援サーバ３００のデータ格納部３０８において、ユーザ端末４００と同様の診断ナレッジ自動実行プログラム記憶部４９０、ホスト定義ファイル記憶部４９２および修復ナレッジ自動実行プログラム記憶部４９４を有する。

図２６は、インシデント対応の完全自動処理過程を示すフローチャート図である。
Ｓ１１０からＳ１１４の処理については、図１７に示したＳ２０からＳ２４の場合と同様である。

完全自動実行制御部は、リコメンド指標が大きい順に診断ナレッジを特定する（Ｓ１１６）。診断ナレッジ自動実行部４８２は、特定した診断ナレッジに関する診断ナレッジ自動実行処理を行なう（Ｓ１１８）。診断ナレッジ自動実行処理は、図２０に関連して説明したとおりである。修復ナレッジは、診断ナレッジ自動実行処理の中で自動実行される。完全自動実行制御部は、診断ナレッジ自動実行処理による修復結果が「完了」を示す場合には（Ｓ１２０のＹ）、インシデント対応の完全自動処理を終える。

診断ナレッジ自動実行処理による修復結果が「完了」ではなく「未了」を示す場合には（Ｓ１２０のＮ）、次にリコメンド指標が大きい診断ナレッジを特定する（Ｓ１１６）。診断ナレッジ自動実行部４８２は、上述の診断ナレッジ自動実行処理をさらに実行する。

このようにして、修復結果が「完了」になるまでＳ１１６からＳ１２０の処理を繰り返す。所定数の診断ナレッジについて診断ナレッジ自動実行処理を行なった段階で終了するようにしてもよい。また、使用した診断ナレッジの種類、診断結果および修復結果を記録してもよい。

［その他の変形例］
機械学習アルゴリズムとして、ニューラルネットワークを用いる例を示したが、他の機械学習アルゴリズムを用いてもよい。

学習モデル適用フェーズ（Ｓ１４）においても実績データを蓄積して、増大した実績データから再度学習モデルを生成するようにしてもよい。

上述の例では、保守員がインシデント対応を行う例を示したが、例えばシステム管理者が構築中のシステムをテストする場合に、診断ナレッジや修復ナレッジを用いてもよい。

診断ナレッジおよび修復ナレッジを、保守員あるいはシステム管理者が作成したり、修正したりしてもよい。ベテランの保守員あるいはシステム管理者が診断ナレッジおよび修復ナレッジを作成し、あるいは修正すれば、さまざまな対応のノウハウが蓄積され、共有される。組織的なレベルアップを図れる面もある。

上述の例の中の図４では、メッセージを分類したメッセージタイプと診断ナレッジＩＤを入力データと、検出成否を出力データとする教師データによって学習モデルを形成したが、入力データとしては以下のバリエーションであってもよい。以下の一のバリエーションを入力データとする教師データを用いて学習モデルを形成してもよい。
＜１＞（一又は複数の）メッセージ、（一又は複数の）診断ナレッジＩＤ
＜２＞（一又は複数の）メッセージ、（一又は複数の）診断ナレッジ
＜３＞（一又は複数の）メッセージ要素、（一又は複数の）診断ナレッジＩＤ
＜４＞（一又は複数の）メッセージ要素、（一又は複数の）診断ナレッジ
＜５＞（一又は複数の）メッセージ、（一又は複数の）診断ナレッジ要素
＜６＞（一又は複数の）メッセージ要素、（一又は複数の）診断ナレッジ要素
ここで、メッセージとはテキストを含むメッセージそのものであり、診断ナレッジもテキスト含む診断ナレッジそのものであり、メッセージ要素とはメッセージを構成する要素であって、例えば、キーワードやメッセージの形態素であり、診断ナレッジ要素とは診断ナレッジを構成する要素であって、例えば、キーワードやメッセージの形態素である。

なお、本発明は上記実施形態や変形例に限定されるものではなく、要旨を逸脱しない範囲で構成要素を変形して具体化することができる。上記実施形態や変形例に開示されている複数の構成要素を適宜組み合わせることにより種々の発明を形成してもよい。また、上記実施形態や変形例に示される全構成要素からいくつかの構成要素を削除してもよい。

本実施形態では、インシデントに伴って発生するメッセージをタイプに分類し、そのタイプを入力変数として用いる学習モデルによって、診断手順による検出成功の見込みを立てるので、情報処理システムにおけるインシデント対応に有効な診断手順を、効率よく選び出しやすくなる。

また、リコメンドされる診断手順を自動的に実行するので、さらに作業効率がよくなる。

１００ ホストコンピュータ、２００ 対象システム、３００ 保守支援サーバ、４００ ユーザ端末、３０４ 通信部、３０６ データ処理部、３０８ データ格納部、３３０ 送信部、３３２ リコメンド画面送信部、３３４ 診断ナレッジ画面送信部、３３６ 子ナレッジ画面送信部、３３８ ホスト定義ファイル送信部、３３９ 修復ナレッジ送信部、３４０ 受信部、３４２ インシデント通知受信部、３４４ リコメンド画面イベント受信部、３４６ 診断ナレッジ画面イベント受信部、３４８ 子ナレッジ画面イベント受信部、３４９ 修復結果受信部、３５０ 子ナレッジ判定結果受信部、３６２ メッセージ取得部、３６４ リコメンド処理部、３６５ メッセージ検索部、３６６ リコメンド画面生成部、３６８ 診断ナレッジ画面生成部、３７０ 子ナレッジ画面生成部、３７２ ホスト定義ファイル生成部、３７４ 実績記録処理部、３７６ メッセージ分類部、３７８ 診断パターン判定部、３８０ システム構成データ記憶部、３８２ メッセージ記憶部、３８４ 診断ナレッジデータ記憶部、３８６ 子ナレッジデータ記憶部、３８７ 修復ナレッジデータ記憶部、３８８ 実績データ記憶部、３９０ メッセージタイプ定義記憶部、３９２ 学習モデル生成部、３９４ 学習エンジン、３９６ 学習モデル記憶部、３９８ 学習モデル利用部、４０２ ユーザインターフェース処理部、４０４ 通信部、４０６ データ処理部、４０８ データ格納部、４１０ 入力部、４１２ リコメンド画面操作受付部、４１４ 診断ナレッジ画面操作受付部、４１６ 子ナレッジ画面操作受付部、４３０ 出力部、４３２ リコメンド画面表示処理部、４３４ 診断ナレッジ画面表示処理部、４３６ 子ナレッジ画面表示処理部、４５０ 送信部、４５２ リコメンド画面イベント送信部、４５４ 診断ナレッジ画面イベント送信部、４５６ 子ナレッジ画面イベント送信部、４５８ 子ナレッジ判定結果送信部、４５９ 修復結果送信部、４６０ 受信部、４６２ リコメンド画面受信部、４６４ 診断ナレッジ画面受信部、４６６ 子ナレッジ画面受信部、４６８ ホスト定義ファイル受信部、４８０ リモート処理部、４８２ 診断ナレッジ自動実行部、４８４ 子ナレッジ自動実行部、４８６ 修復ナレッジ実行部、４８８ 構成管理ツール、４９０ 診断ナレッジ自動実行プログラム記憶部、４９２ ホスト定義ファイル記憶部、４９４ 修復ナレッジ自動実行プログラム記憶部、５００ 診断ナレッジ名表示領域、５０２ リコメンド指標表示領域、５０４ 診断ナレッジ表示ボタン、５０６ 診断ナレッジ自動実行ボタン、５０８ 診断結果表示領域、５１０ 修復結果表示領域、５１２ 閉じるボタン、６００ 診断ナレッジ名表示領域、６０２ 診断ナレッジ概要表示領域、６０４ 子ナレッジ名表示領域、６０６ 子ナレッジ手順表示ボタン、６０８ 子ナレッジ自動実行ボタン、６１０ 第１子ナレッジ判定結果表示領域、６１２ 第２子ナレッジ判定結果表示領域、６１４ 診断結果表示領域、６１６ 修復ナレッジボタン、６１８ 戻るボタン、７００ 子ナレッジ名表示領域、７０２ 子ナレッジ概要表示領域、７０４ 子ナレッジ手順表示領域、７０６ 子ナレッジ判定結果ボタン、７０８ 子ナレッジ使用回数表示領域、７１０ 子ナレッジ自動化ボタン、７１２ 戻るボタン

Claims (7)

1. 保守対象システムにおけるインシデントの原因となる障害を検出するための複数の診断手順を記憶する記憶部と、
   教師データ収集段階および学習モデル適用段階において、インシデントが発生した前記保守対象システムから、異常又は警告を知らせる複数のメッセージを取得する取得部と、
   前記教師データ収集段階および前記学習モデル適用段階において、前記インシデントの発生に伴い取得した前記複数のメッセージを、一又は複数のメッセージタイプに分類する分類部と、
   前記教師データ収集段階において、前記複数の診断手順のうちのいずれかの診断手順に沿って実施された前記インシデントの障害検出の成否を特定する特定部と、
   前記教師データ収集段階において発生した前記インシデントに関して、取得した前記複数のメッセージから分類された前記一又は複数のメッセージタイプと、前記障害検出に用いられた前記診断手順の識別子とを入力変数とし、当該診断手順に沿って実施された前記障害検出の成否を出力変数とする教師データを用いて、学習モデルを生成する学習モデル生成部と、
   前記学習モデル適用段階において発生したインシデントに関して、取得した前記複数のメッセージから分類された前記一又は複数のメッセージタイプと、候補の診断手順の識別子とを入力変数とし、前記学習モデルを用いて、前記候補の診断手順に沿って障害検出を実施した場合の成否に関する予測値を得る予測値算出部と、を備えることを特徴とするインシデント診断対応支援装置。
2. 保守対象システムにおけるインシデントの原因となる障害を検出するための複数の診断手順を記憶する記憶部と、
   教師データ収集段階および学習モデル適用段階において、インシデントが発生した前記保守対象システムから、異常又は警告を知らせる複数のメッセージを取得する取得部と、
   前記教師データ収集段階において、前記複数の診断手順のうちのいずれかの診断手順に沿って実施された前記インシデントの障害検出の成否を特定する特定部と、
   前記教師データ収集段階において発生した前記インシデントに関して、取得した前記複数のメッセージ又はメッセージ要素と、前記障害検出に用いられた前記診断手順又は診断手順要素とを入力変数とし、当該診断手順に沿って実施された前記障害検出の成否を出力変数とする教師データを用いて、学習モデルを生成する学習モデル生成部と、
   前記学習モデル適用段階において発生したインシデントに関して、取得した前記複数のメッセージ又はメッセージ要素と、候補の診断手順又は診断手順要素とを入力変数とし、前記学習モデルを用いて、前記候補の診断手順に沿って障害検出を実施した場合の成否に関する予測値を得る予測値算出部と、を備えることを特徴とするインシデント診断対応支援装置。
3. 保守対象システムにおけるインシデントの原因となる障害を検出するための複数の診断手順を記憶する記憶部と、
   学習モデル適用段階において、インシデントが発生した前記保守対象システムから、異常又は警告を知らせる複数のメッセージを取得する取得部と、
   前記学習モデル適用段階において、前記インシデントの発生に伴い取得した前記複数のメッセージを、一又は複数のメッセージタイプに分類する分類部と、
   教師データ収集段階において発生したインシデントに関し、前記保守対象システムから取得した異常又は警告を知らせる複数のメッセージから分類された一又は複数のメッセージタイプと、障害検出に用いられた診断手順の識別子とを入力変数とし、当該診断手順に沿って実施された当該障害検出の成否を出力変数とする教師データによって生成された学習モデルを用いて、前記学習モデル適用段階において発生した前記インシデントに関して、取得した前記複数のメッセージから分類された前記一又は複数のメッセージタイプと、候補の診断手順の識別子とを入力変数とし、前記候補の診断手順に沿って障害検出を実施した場合の成否に関する予測値を得る予測値算出部と、を備えることを特徴とするインシデント診断対応支援装置。
4. 診断手順を、前記保守対象システムに対するリモート操作内容を定めた自動実行プログラムに変換する自動実行プログラム生成部と、
   前記予測値に基づいて、推奨される診断手順を選別する推奨部と、
   推奨される前記診断手順から生成された自動実行プログラムを用いてリモート操作モジュールに当該診断手順を自動実行させる自動実行部と、を更に備えることを特徴とする請求項１ないし３のいずれかに記載のインシデント診断対応支援装置。
5. 保守対象システムにおけるインシデントの原因となる障害を検出するための複数の診断手順を記憶する記憶部と、
   教師データ収集段階および学習モデル適用段階において、インシデントが発生した前記保守対象システムから、異常又は警告を知らせる複数のメッセージを取得する取得部と、
   前記教師データ収集段階および前記学習モデル適用段階において、前記インシデントの発生に伴い取得した前記複数のメッセージを、一又は複数のメッセージタイプに分類する分類部と、
   前記教師データ収集段階において、前記複数の診断手順のうちのいずれかの診断手順に沿って実施された前記インシデントの障害検出の成否を特定する特定部と、
   前記教師データ収集段階において発生した前記インシデントに関して、取得した前記複数のメッセージから分類された前記一又は複数のメッセージタイプを入力変数とし、前記障害検出が成功した診断手順の識別子を出力変数とする教師データを用いて、学習モデルを生成する学習モデル生成部と、
   前記学習モデル適用段階において発生したインシデントに関して、取得した前記複数のメッセージから分類された前記一又は複数のメッセージタイプを入力変数とし、前記学習モデルを用いて、障害検出が成功すると見込まれる診断手順を推定する推定部と、を備えることを特徴とするインシデント診断対応支援装置。
6. 保守対象システムにおけるインシデントの原因となる障害を検出するための複数の診断手順を記憶する記憶部と、
   学習モデル適用段階において、インシデントが発生した前記保守対象システムから、異常又は警告を知らせる複数のメッセージを取得する取得部と、
   前記学習モデル適用段階において、前記インシデントの発生に伴い取得した前記複数のメッセージを、一又は複数のメッセージタイプに分類する分類部と、
   教師データ収集段階において発生したインシデントに関し、前記保守対象システムから取得した異常又は警告を知らせる複数のメッセージから分類された一又は複数のメッセージタイプを入力変数とし、障害検出が成功した診断手順の識別子を出力変数とする教師データによって生成された学習モデルを用いて、前記学習モデル適用段階において発生した前記インシデントに関して、取得した前記複数のメッセージから分類された前記一又は複数のメッセージタイプを入力変数とし、障害検出が成功すると見込まれる診断手順を推定する推定部と、を備えることを特徴とするインシデント診断対応支援装置。
7. 診断手順を、前記保守対象システムに対するリモート操作内容を定めた自動実行プログラムに変換する自動実行プログラム生成部と、
   推定された前記診断手順から生成された自動実行プログラムを用いてリモート操作モジュールに当該診断手順を自動実行させる自動実行部とを、更に備えることを特徴とする請求項５または６に記載のインシデント診断対応支援装置。

Images