JP2006309615A - 障害解決支援システム - Google Patents

Abstract

【課題】既知の障害のみならず、未知の障害に対しても迅速な対応を支援することのできる障害解決支援システムを提供する。
【解決手段】管理コンピュータ２は、過去に発生した障害に関する事例情報を対応に当たった担当者名を付して記録した事例ＤＢ１３と、発生する障害の系統を分類するキーワード毎に担当者の障害対応回数を記録したキーワードＤＢ１４と、ユーザシステムより障害メッセージを受付ける案件受付部４１と、該障害メッセージに基づいて担当者となり得る候補者を事例ＤＢ１３及び／又はキーワードＤＢ１４から複数人リストアップし、リストアップした候補者の中から担当者を所定数にて割り当てる担当割当部４２と、障害案件毎にチャットチャンネルを開設し、同チャンネル内での障害対処状況を記録するチャンネル制御部４３と、事例ＤＢ１３及びキーワードＤＢ１４の記録内容を更新するＤＢ更新部４４と、を備える。
【選択図】 図２

Description

本発明は、障害解決支援システムにかかり、詳しくは、障害発生時における迅速な障害対応を支援するシステムに関する。
情報技術（ＩＴ：Information Technology）の普及に伴い、企業活動等におけるネットワークシステムは今や不可欠な存在になってきている。このようなＩＴ環境においては、ネットワークに接続される機器や常駐アプリケーション（ファイルシステム等）等に障害が発生するとその影響が大きくなる。特に近年はネットワーク規模の拡大、複雑化が進み、そのような障害発生の把握や対応の遅れは、多大な損失を招く要因となる。このため、障害の発生をいち早く検知して、その対処を迅速に行うためのシステムの導入が要望されている。

従来、ネットワーク内機器の状況把握や障害解決を支援するシステム（以下、支援システムという）には、種々の方法が提案されている（例えば、特許文献１〜３参照）。これらの支援システムでは、監視対象とするネットワーク内の機器に障害が発生すると、その旨を各機器のエキスパート（熟練者）に通知し、それを受け取った担当者が交替しながら対処に当たることで、障害の原因特定や復旧処理を行うものとなっている。
特開２００４−１３５９４号公報 特開２００４−２９９５４号公報 特開２００４−１１０４９６号公報

しかしながら、上記のような特許文献１〜３に記載の構成では、管理センタから送信される障害発生通知（一般にはメール）がそれを受け取る担当者によって閲覧されなければ障害発生が認知されないため、対応の遅れとなることが懸念される。この対策としてメール送付先の担当者を増員することも考えられるが、その場合には誰が対応に当たるのかが不明瞭となる問題がある。

また、特許文献１や特許文献２に記載の構成では、過去に発生した障害を事例情報としてデータベースに蓄積し、過去の事例情報に基づいて各障害の対応に当たる担当者を割り当てることで、復旧処理の迅速化を図るようにしている。しかし、この方法では、データベースに蓄積のない（つまりは過去に事例のない）未知の障害が発生した場合には、その対応に適切な担当者を割り当てることが困難となる。そればかりか、他からの技術協力を得るべく、担当者を新たに増員するといったことも容易ではない。このため、そのような未知の障害の場合には復旧作業が長びくといった問題があった。

本発明は、このような従来の実情に鑑みてなされたものであって、その目的は、未知の障害が発生する場合にも、迅速な障害対応を支援することのできる障害解決支援システムを提供することにある。

上記の目的を達成するため、請求項１に記載の発明によれば、事例データベースには、過去に発生した障害事例がその対応に当たった担当者名と共に蓄積され、キーワードデータベースには、発生する障害の系統を分類するキーワードが該キーワード毎に各担当者の障害対応回数と共に登録される。これにより、発生した障害が既知の障害である場合には、受信した障害メッセージに基づいて、その対処に当たる候補者が少なくとも事例データベースより抽出され、その候補者の中から担当者が所定数にて割り当てられる。又、発生した障害が未知の障害の場合には、受信した障害メッセージに基づいて、その対処に当たる候補者がキーワードデータベースより抽出され、その候補者の中から担当者が所定数にて割り当てられる。これにより、既知の障害のみならず未知の障害に対しても迅速な障害対応を支援することができる。又、本構成では、発生した障害案件毎に開設されるチャットチャンネル上にて障害対処作業が行われる。その結果、複数の担当者間で情報をリアルタイムに共有して、より迅速な障害の解決を支援することができる。又、このようなチャットを利用すれば、他の担当者からの技術協力（担当者の増員）も容易に得ることができる。

請求項２に記載の発明によれば、過去に同じ障害事例についてその対応経験を持つ者が最優先に担当者として割り当てられ、次いで、キーワードにより特定される障害系統についてその対応経験を持つ者が対応回数の上位順に担当者として割り当てられる。これにより、既知の障害や、過去に発生した障害系統と同系統の障害が発生した場合には、それら各障害の対応にそれぞれ適した者を担当者として割り当てることができる。これにより、迅速なる障害解決を支援することができる。

請求項３に記載の発明によれば、キーワードデータベース内に登録されているキーワードのうち、広範囲のキーワードに該当する者がキーワード該当数の上位順に候補者として抽出されることにより、過去に発生したことのない未知の系統の障害に対してもその対応を迅速に行うことができる。

請求項４に記載の発明によれば、担当者数決定表に従って各障害の対処にそれぞれ最適な担当者数（上記所定数）が決定される。これにより、より迅速なる障害の解決を支援することができる。

請求項５に記載の発明によれば、担当割当機能により割り当てられた全担当者の担当者端末がネットワーク上に確認できない場合には、同割り当てられている担当者の中から少なくとも１名が選出されて、その担当者宛の連絡メッセージが作成される。これにより、担当者が不在の場合において、次回接続時に対処依頼の通知を行うことができる。

上記の発明によれば、既知の障害のみならず、未知の障害に対しても迅速な障害対応を支援することのできる障害解決支援システムを提供することができる。

以下、本発明を具体化した一実施の形態を図面に従って説明する。
図１は、本実施の形態に係る障害解決支援システムを示す概略構成図である。
障害解決支援システム１は、管理コンピュータ２、担当者端末３及びユーザシステム４を含み、それらはネットワーク５を介して相互に接続されている。なお、本実施の形態においてはネットワーク５としてインターネットの利用を想定しているが、その他として、例えばＬＡＮ（Local Area Network）を利用することもできる。

管理コンピュータ２は、サーバコンピュータであって、担当者端末３やユーザシステム４との間のネットワーク５を通じたデータの授受を所定の通信プロトコル（例えばＴＣＰ／ＩＰ）に従って行う。なお、この管理コンピュータ２は、それが提供するサーバ機能の全部又は一部を負荷等に応じて機能的又は物理的に分散／統合することにより、任意の単位（１又は複数のコンピュータ）で構成することができる。

ユーザシステム４は、管理コンピュータ２がネットワーク５を通じて監視する監視対象の機器を一又は複数含み構成されている。ユーザシステム４におけるネットワーク構成は任意である。管理コンピュータ２は、ユーザシステム４内の機器やアプリケーション等に障害が発生すると、その障害に関するメッセージ（以下、障害メッセージという）をネットワーク５を介してユーザシステム４より受信する。なお、障害メッセージの受信態様は任意である。例えば、本実施の形態ではＳＮＭＰ（Simple Network Management Protocol）を利用したログメッセージの態様にて受信するが、その他、メール（E-mail）等により障害メッセージを受信する態様であってもよい。

担当者端末３は、ユーザシステム４にて発生した障害に対してその対応に当たる担当者が使用する端末であり、例えば、パーソナルコンピュータにて構成される。なお、担当者端末３は、ネットワーク５上に一又は複数台接続される。管理コンピュータ２は、ユーザシステム４より障害メッセージを受信すると、その障害の対応に当たる担当者を所定数にて割り当て、その担当者の担当者端末３（一又は複数台）と管理コンピュータ２との間でネットワーク５上に電子会議室を開設する。この電子会議室は、具体的には各案件に個別に開設されるチャットチャンネル（以下、案件チャンネルという）である。管理コンピュータ２は、この電子会議室（案件チャンネル）を開設することにより、担当者に障害対処を依頼する。

管理コンピュータ２は、案件キュー１１、ログファイル記憶部１２、事例データベース（以下、事例ＤＢという）１３、キーワードデータベース（以下、キーワードＤＢという）１４を記憶部として有する。これら各記憶部（１１，１２，１３，１４）は、管理コンピュータ２が提供する各種機能を実現するためのプログラム，データを機能的に分割して格納したものである。なお、必ずしもこの分割の態様に限定されない。

案件キュー１１には、管理コンピュータ２がユーザシステム４より受信した障害メッセージに基づき作成した案件レコード２１（図２参照）が格納される。ログファイル記憶部１２には、担当者による電子会議室（案件チャンネル）内での障害対処の状況（ログ）を記録したログファイル２２（図２参照）がそれぞれ案件別に格納される。事例ＤＢ１３には、過去に発生した障害に関する事例情報がそれぞれ対応に当たった担当者名と共に記録される。キーワードＤＢ１４には、ユーザシステム４にて発生する障害の系統を分類する複数のキーワードが登録されるとともに、それらキーワード毎に各担当者の障害対応回数をカウントした値が記録される。詳細については後述する。

図３は、管理コンピュータ２のハードウェア構成を示すブロック図である。管理コンピュータ２は、ＣＰＵ３１を含み、ＣＰＵ３１は、メモリ３２、入力装置３３、出力装置３４、記憶装置３５、ドライブ装置３６及び通信装置３７と接続されている。

ＣＰＵ３１は、メモリ３２を利用してプログラムを実行することで、管理コンピュータ２が提供する各種機能の実現に必要な処理を行う。本実施の形態においては、ＣＰＵ３１は、案件受付機能、担当割当機能、チャンネル制御機能、データベース更新機能としての機能を実現する。メモリ３２には、プログラムとデータが格納される。このメモリ３２には、通常、キャッシュメモリ、システムメモリ及びディスプレーメモリが含まれる。

入力装置３３は、キーボード及びマウス装置（図示せず）を含み、ユーザからの要求や指示の入力に用いられる。出力装置３４は、モニタ及びプリンタを含み、画面等の出力に用いられる。

記憶装置３５は、通常、磁気ディスク装置、光ディスク装置及び光磁気ディスク装置を含む。この記憶装置３５には、上述したプログラム，データが格納され、ＣＰＵ３１は、入力装置３３による指示に応答して必要なプログラムとデータをメモリ３２へ転送し、それを実行する。なお、上述の各記憶部（１１，１２，１３，１４）は、この記憶装置３５に格納されたプログラム及びデータが占める領域にて実現される。勿論、記憶装置３５のみに限定されず、他の複数の記憶装置を利用して実現することも可能である。

ドライブ装置３６は、記録媒体３８を駆動し、その記憶内容にアクセスする。記録媒体３８としては、メモリカード、フレキシブルディスク、光ディスク（CD-ROM,DVD-ROM,…）、光磁気ディスク（MO,MD,…）等、任意のコンピュータ読み取り可能な記録媒体を使用することができる。この記録媒体３８に、上述のプログラムやデータを格納しておき、必要に応じてメモリ３２にロードして使用することもできる。

通信装置３７は、ネットワーク５の接続に用いられ、通信に伴うデータ変換等を行って他の装置（担当者端末３あるいはユーザシステム４内の機器）との間でプログラムやデータの送受信を行う。

図２は、管理コンピュータ２の機能構成を示すブロック図である。
管理コンピュータ２は、案件受付部４１（案件受付機能）、担当割当部４２（担当割当機能）、チャンネル制御部４３（チャンネル制御機能）、ＤＢ更新部４４（データベース更新機能）を有する。

案件受付部４１は、ユーザシステム４から障害メッセージを受付け、該受付けた障害メッセージから同メッセージ内容を含む案件レコード２１を作成してそれを対処すべき障害案件として案件キュー１１に登録する。

担当割当部４２は、案件キュー１１から案件レコード２１を読み込み、それに記録されている障害メッセージに基づいて、各案件を担当する担当者をそれぞれ案件毎に最適とする人数にて割り当てる。具体的な処理については後述するが、この担当割当部４２における処理の概要は以下のとおりである。

まず、担当割当部４２は、障害メッセージの内容を解析する。次に、この解析結果をもとに、その案件で担当者となり得る候補者を事例ＤＢ１３及び／又はキーワードＤＢ１４から複数人リストアップして、担当候補リスト４５に登録する。この担当候補リスト４５には、各候補者が担当者として選択される際の優先度の高い順に記載される。次に、予め用意されている担当者数決定表４６と、先のメッセージ解析結果とに基づいて、その案件の担当者数を決定する。この担当者数決定表４６には、発生する障害の系統に応じて、それぞれの対処に最適とする人数が事前設定されている。担当割当部４２は、この担当者数決定表４６に従って決定した担当者数にて、上述の担当候補リスト４５から優先度の高い順に担当者を選出することで、担当者の割り当てを行う。

チャンネル制御部４３は、案件キュー１１から案件レコード２１を読み込み、案件毎に電子会議室（案件チャンネル）を開設する。そして、上記担当割当部４２にて割り当てられた各案件の担当者をそれぞれ対応する案件チャンネル内にチャットにて呼び出し、当該担当者による同チャンネル内での対処状況をログファイル２２に記録する。

ＤＢ更新部４４は、ログファイル記憶部１２からログファイル２２を読み込み、このログファイル２２の記録内容に基づいて事例ＤＢ１３及びキーワードＤＢ１４の内容を更新する。

次に、上記各機能部（４１〜４４）における具体的処理を個々に説明する。
まず、案件受付部４１について説明する。
図４は、案件受付部４１における処理を示すフローチャートである。上記したように、案件受付部４１は、ユーザシステム４から障害メッセージを受付けると（ステップ１００）、その障害メッセージから案件レコード２１を作成してそれを案件キュー１１に登録する（ステップ１１０）。

図５は、案件レコード２１のデータ構造を示す概念図である。
案件レコード２１は、案件番号２１ａ、メッセージ２１ｂ、トピックス２１ｃ、担当者リスト２１ｄ、先送り日時２１ｅ、開始日時２１ｆ、終了日時２１ｇをフィールドとして有して構成される。

案件番号２１ａには、案件の識別番号が記録される。メッセージ２１ｂには、受信した障害メッセージが記録される。トピックス２１ｃには、障害内容に関する題目が記録される。なお、トピックス２１ｃには、障害メッセージの内容から題目が自動で設定される。担当者リスト２１ｄには、案件の担当者名（本例では担当者のニックネーム）が記録される。先送り日時２１ｅには、案件がその担当者により後述する先送り案件として処理された場合に、次の再開予定とする日時が記録される。開始日時２１ｆには、対処を開始した日時が記録される。終了日時２１ｇには、対処が完了した日時が記録される。案件受付部４１は、メッセージの受信時には、これらのうち、案件番号２１ａ、メッセージ２１ｂ、トピックス２１ｃに関する情報を記録して案件レコード２１を作成する。

次に、担当割当部４２について説明する。
図６は、担当割当部４２における処理を示すフローチャートである。
担当割当部４２は、まず、案件キュー１１から案件レコード２１を読み込み（ステップ２００）、その案件レコード２１に記録されている障害メッセージ（全文）を定型メッセージに変換する定型化処理を行う（ステップ２１０）。

次に、障害メッセージを障害系統を表す一又は複数のキーワードに分解する（ステップ２２０）。なお、キーワード分解するメッセージは定型化処理前及び定型化処理後のいずれのメッセージとしてもよい。

次に、得られたキーワードの組み合わせから、担当者数決定表４６をもとにその案件に割り当てる担当者数を決定する（ステップ２３０）。
詳述すると、図７に示すように、担当者数決定表４６には、管理コンピュータ２が監視対象とする機器の種類（図に装置名で示す）とそれらに発生する障害系統とに基づいて、各機器で発生する障害の対処にそれぞれ最適とする担当者数が予め設定されている。機器の種類は、障害メッセージの内容から判断される。また、障害系統は、複数のキーワードの組み合わせにて判断される。例えば、障害メッセージがキーワードｋ１，ｋ２，ｋ３を含む場合にはネットワーク系（Ｎｅｔ系）、キーワードｋ４，ｋ５を含む場合には電源系、キーワードｋ６，ｋ７を含む場合にはディスク系（ＤＩＳＫ系）、キーワードｋ８，ｋ９を含む場合にはリブート系として障害系統が判断される。なお、それ以外の組み合わせの場合には分類不能として判断される。担当割当部４２は、このような担当者数決定表４６に従って、各案件の対処にそれぞれ最適とする担当者数を決定する。

次に、担当割当部４２は、上記定型化処理後の障害メッセージに基づいて、その障害メッセージに該当する障害事例を過去担当した経験を持つ担当者を事例ＤＢ１３から検索する（ステップ２４０）。

事例ＤＢ１３について説明すると、図８に示すように、事例ＤＢ１３には、過去発生した障害に関する複数の事例情報５１が記録されている。事例情報５１は、事例番号５１ａ、担当者ニックネーム５１ｂ、発生日時５１ｃ、メッセージ５１ｄ（定型化処理済のもの）、ログ保存場所５１ｅをフィールドとして構成されている。事例番号５１ａには、事例情報５１の識別番号が記録される。担当者ニックネーム５１ｂには、障害の対応に当たった担当者のニックネームが記録される。発生日時５１ｃには、障害の発生した日時が記録される。メッセージ５１ｄには、上記定型化処理後の障害メッセージが記録される。ログ保存場所５１ｅには、障害の対処状況を記したログファイル２２のファイル名が記録される。

担当割当部４２は、このような事例情報５１を、上記定型化処理後の障害メッセージをキーに事例ＤＢ１３から検索し、該当する事例情報５１が有るかどうか、つまり、過去に同じ障害事例について対応経験を持つ担当者が存在するかどうかを判断する（ステップ２５０）。

事例有りの場合には、その事例情報５１に記録されている担当者（担当者ニックネーム）を第１候補者として抽出し、それを担当候補リスト４５（図２参照）に記載する（ステップ２６０）。この第１候補者は、担当割り当て時における筆頭候補者として最も高い優先度に設定される。

一方、事例無しの場合には、上記障害メッセージから得られたキーワードに基づいて、そのキーワードに該当する障害に過去対応した経験を持つ担当者をキーワードＤＢ１４から検索する（ステップ２７０）。

キーワードＤＢ１４について説明すると、図９に示すように、キーワードＤＢ１４には複数のキーワード情報５２が記録されている。各キーワード情報５２は、キーワード５２ａ、候補名５２ｂをフィールドとして構成されている。キーワード５２ａには、上記障害メッセージから得られたキーワードが記録される。候補名５２ｂには、キーワードに該当する障害に過去対応した経験を持つ担当者のニックネームとその対応回数とが記録される。なお、候補名５２ｂは担当者毎に設けられている。

担当割当部４２は、このようなキーワード情報５２を、上記障害メッセージから得られた１又は複数のキーワードをキーにキーワードＤＢ１４から検索し、該当するキーワード情報５２が有るかどうか、つまり、発生した障害と関連する系統の障害について過去対応経験を持つ担当者が存在するかどうかを判断する（ステップ２８０）。

該当するキーワード有りの場合には、そのキーワード情報５２に記録されている担当者（担当者ニックネーム）を対応回数の上位順に優先度を付して抽出し、それを第２候補者として担当候補リスト４５に記載する（ステップ２９０）。この第２候補者は、上記第１候補者よりも優先度が低く設定される。

一方、該当するキーワード無しの場合には、キーワードＤＢ１４に登録されているキーワード情報５２のうち、より多くのキーワード情報５２に記録されている担当者、つまりは、広範囲の障害に関する知識を持つ担当者（担当者ニックネーム）をキーワード該当数の上位順に優先度を付して抽出し、それを第３候補者として担当候補リスト４５に記載する（ステップ３００）。この第３候補者は、上記第２候補者よりも優先度が低く設定される。

次に、担当割当部４２は、上記担当候補リスト４５にリストアップした担当者（候補者）の中から、上記担当者数決定表４６に従って決定した人数分にて優先度の高い順に担当者の割り当てを行う（ステップ３１０）。そして、この割り当てを行った担当者の担当者ニックネームを案件レコード２１の担当者リスト２１ｄに記録すると共に、対応するログファイル２２に記録する。

次に、チャンネル制御部４３について説明する。
図１０は、チャンネル制御部４３における処理を示すフローチャートである。
チャンネル制御部４３は、まず案件キュー１１から案件レコード２１を読み込み（ステップ４００）、その案件が先送り案件か否かを判断する（ステップ４１０）。即ち、案件レコード２１に先送り日時２１ｅの設定が有り、且つその設定日時を経過していない場合には先送り案件として判断する。

先送り案件であると判断した場合には、処理を終了する。一方、先送り案件でないと判断した場合には、上記担当割当部４２にて割り当てられた担当者の担当者端末３がネットワーク５に接続されているかを確認する（ステップ４２０）。

ここで、担当者が全員不在の場合（該当する担当者端末３の接続がネットワーク５上に確認できないとき）には（ステップ４３０）、チャンネル制御部４３は、後述する図１１に示す連絡案件発生処理に移る。一方、一人でも担当者が確認できた場合には、電子会議室（案件チャンネル）を開設し（ステップ４４０）、その担当者をチャットにてチャンネル内に呼び出し障害対処を依頼する（ステップ４５０）。その際、この案件に関する障害事例が事例ＤＢ１３に存在する場合、つまり既知の障害である場合には、その事例情報５１に記録されているログファイル２２のファイル名、及び前回対処に要した時間を同チャンネル内に表示する（ステップ４６０）。

以降、チャンネル制御部４３は、案件チャンネル内での担当者による対処状況を監視（ロギング）し、逐次取得したログ情報をログファイル２２に記録する（ステップ４７０）。なお、ここでは上記担当者による障害対処方法については特に限定しないが、例えば、作業用端末ソフトウェア（Telnet等）６１を用いて、それによる操作状況をロギングするといった方法を採用することができる。

そして、チャンネル制御部４３は、担当者により「障害対処完了」の入力がなされたことを検知すると（ステップ４８０）、その時対処に当たっていた全ての担当者をログファイル２２に記録して（ステップ４９０）、その案件チャンネルを閉設し（ステップ５００）、同対処済の案件レコード２１を案件キュー１１から削除して処理を終了する（ステップ５１０）。

また、チャンネル制御部４３は、担当者により「案件先送り：日時（次の再開予定とする日時）」の入力がなされたことを検知する場合には（ステップ５２０）、その時対処に当たっていた全ての担当者をログファイル２２に記録して（ステップ５３０）、その案件チャンネルを一時中断（閉設）し（ステップ５４０）、同入力された日時を案件レコード２１の先送り日時２１ｅに記録して処理を終了する（ステップ５５０）。

図１１は、チャンネル制御部４３における連絡案件発生処理を示すフローチャートである。上記したように、この処理は、案件チャンネルの開設時に担当者が全員不在の場合（図１０参照）に実施される処理である。

この処理では、チャンネル制御部４３は、上記担当割当部４２にて割り当てられた担当者のうちいずれか１名を選出して、その担当者宛の連絡メッセージ６２（図１２：例えば「案件ＮについてＡ氏に連絡」といったメッセージ内容）を作成し（ステップ６００）、この連絡メッセージ６２を含む連絡案件レコード６３を作成して案件キュー１１に登録する（ステップ６１０）。これにより、この連絡案件レコード６３がその後、案件キュー１１から読み出された際に、上記連絡メッセージ６２が担当者に送信される。

図１３は、チャンネル制御部４３における案件再開処理を示すフローチャートである。この処理は、先送り案件として設定されている案件を再開処理する際に実施される処理である。

チャンネル制御部４３は、先送り案件として設定されている案件について、担当者による「案件再開：案件番号」の入力を既設の案件チャンネル（チャンネルは任意）内に検知すると（ステップ７００）、その案件番号を持つ案件レコード２１に記録されている先送り日時２１ｅの設定内容をクリアする（ステップ７１０）。これにより、この案件レコード２１がその後、案件キュー１１から読み出された際に直ちにはその対処に移される。

次に、ＤＢ更新部４４について説明する。
図１４は、ＤＢ更新部４４における処理を説明するフローチャートである。
ＤＢ更新部４４は、事例情報５１の事例ＤＢ１３への追加（ステップ８００）と、キーワード情報５２のキーワードＤＢ１４への追加（ステップ８１０）とを行う。これら事例ＤＢ１３及びキーワードＤＢ１４の記録更新は発生した障害案件毎に行う。

次に、上記障害解決支援システム１における一連の処理の流れについて説明する。ここでは、障害１件分の処理を代表して説明する。
図１５に示すように、まず、案件受付部４１は、ユーザシステム４からの障害メッセージを受信する（ステップ９００）。

次に、担当割当部４２は、案件受付部４１にて受信された障害メッセージに基づいて、その対応に当たる担当者を最適人数にて割り当てる（ステップ９１０）。
次に、チャンネル制御部４３は、電子会議室（案件チャンネル）を開設し（ステップ９２０）、担当割当部４２にて割り当てられた担当者にその障害案件についての障害対処を依頼する（ステップ９３０）。以降、チャンネル制御部４３は、担当者による同チャンネル内での対処状況をロギングし、そのログ取得内容から、対処が完了したかどうか、つまり、障害解決に至ったかどうかを判断する（ステップ９４０）。この障害解決に至るまでの過程において、対処中の担当者は、他のエキスパートからの技術協力を得るべく、割り当て以外の担当者を同チャンネル内にチャットにて呼び出し、対処に当たる担当者の追加を随時任意に行うことができる（ステップ９５０）。

そして、チャンネル制御部４３にて対処が完了したことが検知されると、ＤＢ更新部４４は、同案件について事例ＤＢ１３及びキーワードＤＢ１４の記録内容を更新する（ステップ９６０）。これにより、障害１件分の対処を完了する。

以上記述したように、本実施の形態によれば、以下の効果を奏する。
（１）障害メッセージの内容に基づいてその対応に当たる担当者を事例ＤＢ１３及び／又はキーワードＤＢ１４から自動で割り当て、各案件個別の電子会議室（案件チャンネル）を開設するようにした。この構成によれば、発生した障害が既知の障害である場合には、受信した障害メッセージに基づいて、その対応に適任とする者を少なくとも事例ＤＢ１３より抽出して担当者として割り当てることができる。また、発生した障害が過去に発生した障害系統と同系統の障害である場合には、受信した障害メッセージに基づいて、その対応に適任とする者をキーワードＤＢ１４より抽出して担当者として割り当てることができる。これにより、既知の障害のみならず、未知の障害に対してもそれぞれの対応に適任とする担当者の割り当てを行うことができる。

（２）担当者の割り当てを行う候補者として、更に、キーワードＤＢ１４に登録されているキーワードのうち、より広範囲のキーワードに該当する者を同キーワードＤＢ１４より抽出するようにした。この構成によれば、過去に発生例のない未知の系統の障害が発生した場合にも、その対応に適任とする担当者の割り当てを行うことができる。

（３）各障害案件で割り当てる担当者数を担当者数決定表４６に従って決定するようにした。この担当者数決定表４６には、管理コンピュータ２が監視対象とする機器の種類と、発生する障害の系統とに基づいて、各障害の対処に当たる担当者数が予め設定されている。この構成によれば、発生する障害に応じて、対応に当たる担当者数を最適化できる。

（４）キーワードＤＢ１４にキーワードと共に各担当者の障害対応回数を記録し、キーワードＤＢ１４から候補者（第２候補者及び第３候補者）を抽出する場合には、障害対応回数の上位順に優先度を付して抽出するようにした。これにより、割り当てを行う担当者を最適化できる。

（５）障害案件毎に案件チャンネルを開設するようにしたことで、対応に当たる担当者が複数人の場合にもその作業報告を同チャンネル内で１つに纏め上げることができる。これにより、記録作業の効率を向上させることができる。

（６）電子会議室にチャットシステムを利用したことで、対応に当たる複数の担当者間で情報をリアルタイムに共有して、他の担当者への作業状況の通知を簡易に行うことができる。また、チャットを利用することで、他の担当者からの技術協力も容易に得られるようになる。

（７）担当割当部４２により割り当てられた全担当者の担当者端末３がネットワーク５上に確認できない場合（担当者全員不在の場合）には、同割り当てられている担当者の中から１名を選出してその担当者宛の連絡メッセージ６２を作成するようにした。これにより、担当者が不在の場合には、その担当者の次回接続時において、対処依頼を通知することができる。

なお、上記実施の形態は、以下に記載する変形例の態様で実施してもよい。
・管理コンピュータ２とユーザシステム４との間のネットワーク接続形態は上記実施の形態に限定されず、その他、任意の形態を採ることができる。

・事例ＤＢ１３の事例情報５１及びキーワードＤＢ１４のキーワード情報５２に記録する担当者名は担当者ニックネームに限定されない。各担当者が特定できればよい。
・案件レコード２１、ログファイル２２、事例情報５１、キーワード情報５２及び連絡案件レコード６３の構成は上記実施の形態に限定されず、本発明の技術的思想の範囲内において適宜変更することができる。

・事例ＤＢ１３から事例情報５１（具体的にはその担当者）を検索する方法、および、キーワードＤＢ１４からキーワード情報５２（具体的にはその担当者）を検索する手法としては、上記実施の形態に限定されず、本発明の技術的思想の範囲内において適宜変更することができる。

・担当者数決定表４６の構成は上記実施の形態に限定されない。例えば、障害メッセージから得られるキーワードをもとに、障害系統のみにより担当者数を設定してもよい。また、このような担当者数決定表４６は必ずしも必須ではない。割り当てる担当者数を一律に同じ（所定数）としてもよい。

・事例ＤＢ１３からリストアップする第１候補者、および、キーワードＤＢ１４からリストアップする第２候補者のみで担当者の割り当てが可能であれば、必ずしも第３候補者のリストアップを行わなくてもよい。

・担当者数決定表４６では、障害発生による影響の大きさを鑑みて機器毎に障害対応の重要度を設定し、重要度の高い機器つまりは障害発生時に早急な対応が望まれる機器ほどそれを上位に位置付けて表を作成し、その重要度に基づいて案件対処する順序を適宜変更する構成としてもよい。

・連絡メッセージ６２を作成する担当者を、担当割当部４２により割り当てられている担当者の中から少なくとも１名選出するようにしてもよい。
・図１５のステップ９５０では、対応中の担当者が新たに追加する担当者に対してチャットにて連絡することにより担当者の増員を行うようにしたが、例えば、担当割当部４２が担当候補リスト４５から優先度順に自動で追加するようにしてもよい。なお、追加するタイミングとしては、担当者からの指示のもとで行うようにしてもよいし、所定時間経過毎に行うようにしてもよい。

・その他上記実施の形態における設計的事項については、本発明の技術的思想の範囲内において適宜変更することができる

一実施の形態の障害解決支援システムを示す概略構成図。 管理コンピュータの機能構成を示すブロック図。 管理コンピュータのハードウェア構成を示すブロック図。 案件処理部における処理を示すフローチャート。 案件レコードの構造を示す概念図。 担当割当部における処理を示すフローチャート。 担当者数決定表を示すテーブル図。 事例データベースの構造を示す概念図。 キーワードデータベースの構造を示す概念図。 チャンネル制御部における処理を示すフローチャート。 チャンネル制御部における処理を示すフローチャート。 連絡案件レコードの構造を示す概念図。 チャンネル制御部における処理を示すフローチャート。 データベース更新部における処理を示すフローチャート。 障害解決支援システムにおける処理を示すフローチャート。

符号の説明

１ 障害解決支援システム
２ 管理コンピュータ
３ 担当者端末
４ ユーザシステム
５ ネットワーク
１１ 案件キュー
１２ ログファイル記憶部
１３ 事例ＤＢ（事例データベース）
１４ キーワードＤＢ（キーワードデータベース）
２１ 案件レコード
２２ ログファイル
４１ 案件受付部（案件受付機能）
４２ 担当割当部（担当割当機能）
４３ チャンネル制御部（チャンネル制御機能）
４４ ＤＢ更新部（データベース更新機能）
４５ 担当候補リスト
４６ 担当者数決定表
５１ 事例情報
５２ キーワード情報
６２ 連絡メッセージ
ｋ１〜ｋ９ キーワード

Claims (5)

1. 管理コンピュータと、障害対応に当たる担当者の担当者端末とをネットワークを介して接続し、前記管理コンピュータが監視するユーザシステムにて発生する障害の解決を支援する障害解決支援システムであって、
   前記管理コンピュータに、
   過去に発生した障害に関する事例情報をその対応に当たった担当者名を付して記録した事例データベースと、
   発生する障害の系統をキーワードにより分類し、該キーワード毎に各担当者の障害対応回数を記録したキーワードデータベースと、
   前記ユーザシステムより障害メッセージを受付ける案件受付機能と、
   前記障害メッセージに基づいて、前記担当者となり得る候補者を前記事例データベース及び／又は前記キーワードデータベースから複数人リストアップし、該リストアップした候補者の中から前記担当者を所定数にて割り当てる担当割当機能と、
   発生した障害案件毎にチャットチャンネルを開設し、前記割り当てられた担当者による同チャットチャンネルでの障害対処状況を記録するチャンネル制御機能と、
   前記事例データベース及び前記キーワードデータベースの記録内容を更新するデータベース更新機能と、
   を備えたことを特徴とする障害解決支援システム。
2. 前記担当割当機能は、前記障害メッセージをキーに、過去に同じ障害について対応経験のある担当者を第１候補者として前記事例データベースから検索するとともに、前記障害メッセージを分解して得られる前記キーワードをキーに、同キーワードに該当する障害について対応経験のある担当者を第２候補者として対応回数の上位順に前記キーワードデータベースから検索し、前記第１候補者、前記第２候補者の順に前記担当者を前記所定数まで割り当てる、
   請求項１記載の障害解決支援システム。
3. 前記担当割当機能は、前記キーワードデータベース内に登録されている前記キーワードのうち、より多くのキーワードに該当する担当者を第３候補者としてキーワード該当数の上位順に前記キーワードデータベースから検索し、前記第２候補者に続いて更に前記第３候補者を前記担当者として前記所定数まで割り当てる、
   請求項２記載の障害解決支援システム。
4. 前記管理コンピュータが監視する前記ユーザシステム内の機器の種類と、前記キーワードにより分類される前記障害の系統とに基づいて、各機器で発生する障害の対応にそれぞれ割り当てる担当者数を予め設定した担当者数決定表が備えられ、前記担当割当機能は、前記担当者数決定表に従って前記担当者の割り当てを行う前記所定数を決定する、
   請求項１乃至３のいずれか一項記載の障害解決支援システム。
5. 前記チャンネル制御機能は、前記担当割当機能により割り当てられた全担当者の担当者端末が前記ネットワーク上に確認できない場合には、同割り当てられている担当者の中から少なくとも１名を選出して連絡メッセージを作成する、
   請求項１乃至４のいずれか一項記載の障害解決支援システム。

Images