JP5271761B2

JP5271761B2 - 障害対処方法及び装置

Info

Publication number: JP5271761B2
Application number: JP2009059172A
Authority: JP
Inventors: 正明大門
Original assignee: Fujitsu FSAS Inc
Current assignee: Fujitsu FSAS Inc
Priority date: 2009-03-12
Filing date: 2009-03-12
Publication date: 2013-08-21
Anticipated expiration: 2029-03-12
Also published as: JP2010211674A

Description

本技術は、障害の通知情報であるインシデント情報に対して中長期的な視点で対処するための情報処理技術に関する。

現在、企業の多くが何らかのシステムを使用しているが、様々な原因でシステムに障害等のトラブルが発生し、その対応は発生後直ぐに行うのが通常である。

しかしながら、運用管理者側では、トラブルの報告が多数同時期に発生する場合があるため、様々な観点から優先度を与えて優先度の高いものから対処している。

その一手法としては以下のような技術が存在する。具体的には、サービス管理装置は、所定のサービスを提供するシステムに対する顧客からのインシデントを受け取ったオペレータによってインシデント毎に作成される、インシデントに関するデータを含むインシデントチケットを管理するインシデント管理部と、インシデントチケットのうちオペレータでは対応できないと判断されたインシデントに関するインシデントチケットと関連付けされる、システムの開発者が対応すべき問題に関するデータを含む問題チケットを管理する問題管理部と、問題チケットのうち、問題の解決のためにシステムのメンテナンスを必要とする問題チケットと関連付けされる、システムの運用担当者が実施すべき変更に関するデータを含む変更チケットを管理する変更管理部とを備える。インシデント管理部は、オペレータによるインシデント処理の優先順位を決定するための指標であるインシデントインパクトを算出するインシデントインパクト算出部を備える。問題管理部は、開発者による問題の処理の優先順位を決定するための指標である問題インパクトを算出する問題インパクト算出部を備える。変更管理部は、運用担当者による変更の処理の優先順位を決定するための指標である変更インパクトを算出する変更インパクト算出部を備える。インシデントインパクトまたは問題インパクトが変更されると、インシデントチケット、問題チケットおよび変更チケットの関連付けに応じて問題インパクトまたは変更インパクトが修正される。

さらに、他の手法としては、どの障害がどの業務に影響を及ぼすかという影響範囲を特定するだけでなく、その業務がどの程度重要な業務であるかをリアルタイムに運用管理者に提示し、熟練しかつビジネスへの理解度の高い運用管理者でなくても、迅速に且つビジネス上の損失を最小限に抑えた分散システムの運用管理を行うための技術も存在している。

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

しかしながら、上で述べたような文献には、障害の通知に応じて本来であれば直ぐに実施すべき処置についての優先順位付けについては開示されているが、障害が発生したシステムなどに内在する問題の根本解決及び当該システムの顧客対策の観点でどのように対処すべき顧客又は機種若しくは機器を特定すべきかについては考察されていない。

従って、本技術の目的は、障害が発生したシステムなどに内在する問題の根本解決及び当該システムの顧客対策の観点で対処すべき顧客又は機種若しくは特定の機器を特定するための技術を提供することである。

本障害対処方法は、障害の受け付け時刻又は発生時刻である基準時刻と顧客識別子と対象物識別子と障害状態と障害の影響度とを含む第１のインシデント情報の新規登録を検出するステップと、インシデント情報を格納するインシデント情報格納部を、第１のインシデント情報に含まれる顧客識別子と対象物識別子の少なくとも一部とで検索して、第１のインシデント情報に含まれる顧客識別子と対象物識別子の少なくとも一部と一致する対象物識別子とを含み且つ第１のインシデント情報に含まれる基準時刻から所定期間内に発生又は受け付けたインシデント情報を抽出する抽出ステップと、所定件数以上の件数のインシデント情報が抽出された場合、第１のインシデント情報及び抽出されたインシデント情報の各々について、障害状態の各状態及び影響度の各レベルに対応付けてリスクポイントが登録されているリスクポイントテーブルからインシデント情報に含まれる障害状態及び影響度が該当するリスクポイントを読み出し、当該リスクポイントを合計することにより総合リスクポイントを算出する算出ステップと、総合リスクポイントが所定の閾値を超えた場合には、第１のインシデント情報を特定する情報又は対象物識別子を少なくとも含むアラームを管理コンピュータに出力するステップとを含む。

障害が発生したシステムなどに内在する問題の根本解決及び当該システムの顧客対策の観点で対処すべき顧客又は機種若しくは機器を特定することができるようになる。

図１は、実施の形態におけるシステム概要図である。図２は、実施の形態のメインフローを示す図である。図３は、障害情報ＤＢに格納されるデータの一例を示す図である。図４は、実施の形態のメインフローを示す図である。図５は、換算テーブルの一例を示す図である。図６は、重みテーブルの一例を示す図である。図７は、導入日テーブルの一例を示す図である。図８は、実施の形態のメインフローを示す図である。図９は、月別障害件数テーブルの一例を示す図である。図１０は、コンピュータの機能ブロック図である。

図１に、本技術の実施の形態に係るシステムの機能ブロック図を示す。例えば、インターネットや電話回線網などの外部ネットワークには障害受付システム１０が接続されている。この障害受付システム１０では、以下で述べるインシデント情報をオペレータが生成するか又は自動的に生成する。また、障害受付システム１０には、本実施の形態における主要な処理を実施する障害管理システム２０が接続されている。さらに、障害管理システム２０は、ＬＡＮ（Local Area Network）３０等を介して１又は複数の管理者端末４０に接続されている。

障害管理システム２０は、障害発生毎に障害受付システム１０によって生成されるインシデント情報を格納する障害情報ＤＢ２１と、障害受付システム１０によるインシデント情報の新規登録の際に障害情報ＤＢ２１を検索して以下で説明する条件を満たすインシデント情報を抽出する処理を実施するインシデント抽出処理部２２と、顧客毎の月別障害件数を格納し、インシデント抽出処理部２２により参照される月別障害件数テーブル２３と、インシデント抽出処理部２２による処理結果を格納する抽出インシデント格納部２４と、クレームリスクポイントの算出で用いられる重みデータ等を格納する重みデータ格納部２６と、クレームリスクポイントの算出及びアラーム出力の判断のために用いられる閾値及び換算テーブルを格納する閾値及び換算テーブル格納部２７と、インシデント抽出処理部２２からの指示に応じて重みデータ格納部２６と閾値及び換算テーブル格納部２７と抽出インシデント格納部２４とに格納されているデータを用いてクレームリスクポイントの算出及びアラーム出力の判断を実施するクレームリスクポイント算出部２５と、クレームリスクポイント算出部２５により指示されると抽出インシデント格納部２４に格納されているデータを用いて所定の宛先（ここでは管理者端末４０宛。又はメールでアラームを出力する場合には管理者端末４０の管理者宛で図示しないメールサーバに送信）にアラームを出力するアラーム出力部２８と、アラーム出力部２８が出力するアラームデータを格納するアラームデータ格納部２９とを有する。

管理者端末４０は、例えばパーソナルコンピュータであって、アラームがメールで送信される場合には、メールクライアントプログラムを実行しており、アラームが管理者端末４０に送信される場合には障害管理システム２０と連携する専用のプログラムを実行しているものとする。

次に、図２乃至図９を用いて図１に示したシステムの動作について説明する。最初に、障害受付システム１０は、顧客からの電話又は顧客システムからのメールなどによる障害通知を受け付け、オペレータにより又は自動的にインシデント情報を生成し、障害管理システム２０の障害情報ＤＢ２１に登録する。インシデント情報は、インシデント番号、日時（障害の発生時刻又は障害通知の受付時刻）、障害が発生したシステムを使用する顧客の顧客コード、障害が発生した機器の機種を表す機種コードと、障害が発生した機器を特定するための装置番号と、障害の状態（例えば、Ｓ：システムダウン、Ｍ：マシンダウン、Ｎ：ノーダウン（障害が発生したがシステムは動作している状態））と、障害がシステムに対して与える影響度のレベル（例えば、Ａ：全社の基幹システムがダウンし、全社的又は社会的な影響が出ているレベル、Ｂ：Ａより低いが業務に影響があるレベル、Ｃ：業務影響なし）とが含まれる。

障害の状態及び影響度のレベルについては、例えば障害の通知を受け付けたオペレータなどが、通知内容から設定するようにしても良い。また、例えば図示しない顧客毎及び機器毎の契約データを保持しておき、例えば契約データに基づき、障害に係る顧客及び機器の組み合わせが、必要復旧時間が１分未満であれば、影響度のレベルを「Ａ」に設定し、必要復旧時間が１時間以内であるものであれば、影響度のレベルを「Ｂ」に設定し、必要復旧時間が１日以内であるものであれば、影響度のレベルを「Ｃ」に設定する。

また他の方法としては、メールなどで障害発生時に自動的に障害通知が障害受付システム１０に対して行われ、さらに顧客に対してもアラームを出力するようなシステムの場合には、障害通知の受信時刻と顧客からの電話通報との差が例えば１０分以内であれば影響度のレベルを「Ａ」に設定し、差が例えば１時間以内であれば影響度のレベルを「Ｂ」に設定し、差が例えば１時間より長い又は電話通報無しであれば影響度のレベルを「Ｃ」に設定する。

また、障害の状態についても、メールなどで障害発生が通知される場合には、障害受付システム１０が、障害発生の通知に含まれるエラーコードと予め定められた対応テーブル等から自動的に判断して設定するようにしても良い。

障害受付システム１０による登録処理によって障害情報ＤＢ２１には例えば図３に示すようなデータが格納される。図３の例では、例えば障害通知の受信順に発行されるインシデント番号と、障害通知の受付日時又は障害の発生日時である日時と、顧客コードと、機種コードと、装置番号と、障害状態と、影響度とを登録するようになっている。例えば、このようなテーブルを顧客毎に用意するようにしても良い。

そして、インシデント抽出処理部２２は、障害受付システム１０による新規インシデント情報の登録を検出すると（図２：ステップＳ１）、障害情報ＤＢ２１を新規インシデント情報に含まれる顧客コードと機種コードと装置番号とで検索し、当該顧客コードと機種コードと装置番号とに一致し且つ新規インシデント情報に含まれる日時（以下基準時刻と呼ぶ）から第１の期間（例えば１月）以内に発生したインシデント情報を抽出する（ステップＳ３）。そして、インシデント抽出処理部２２は、抽出インシデント情報の件数が第１の閾値（例えば２。すなわち新規インシデント情報以外にもう１件登録されている状態を検出。）以上となっているか判断する（ステップＳ５）。抽出インシデント情報の件数が第１の閾値以上となっていれば、抽出インシデント情報を抽出インシデント格納部２４に格納する。

そして、インシデント抽出処理部２２は、動作モードを第１モードに設定して（ステップＳ７）、クレームリスクポイント算出部２５に処理開始を指示する。そして、端子Ａを介して図４の処理に移行する。図４の説明に移行して、クレームリスクポイント算出部２５は、閾値及び換算テーブル格納部２７において、動作モードに応じた換算テーブル及び閾値を特定する（ステップＳ１５）。換算テーブルは、例えば図５に示すようなテーブルである。図５の例では、影響度の各レベルと障害状態の各状態との各組み合わせについて、第１のモードについて予め定められたリスクポイント値が登録されている。影響度のレベルは、上から順番に影響度のレベルが下がるように並べられており、障害状態の状態は、左から右に障害状態が軽くなるように並べられているので、左上が最もリスクポイントが高くなり、右下が最もリスクポイントが小さくなるようになっている。また、図５の例の場合、閾値は例えば「５０」である。図５の換算テーブルではリスクポイントの最高値は「１３」であり、インシデント情報１件だけではそのリスクポイントは閾値を超えることはない。これは、本実施の形態の目的が、発生した障害に個別に対応するのが目的ではなく、障害が発生したシステムなどに内在する問題の根本解決及び当該システムの顧客対策の観点で対処すべき事象であるのかどうかを判断することが目的であるためである。従って、本実施の形態の第１のモードでは、例えば換算テーブルの最高ポイントの２倍以上の値を閾値に設定する。

その後、クレームリスクポイント算出部２５は、抽出されたインシデント情報のうち未処理のインシデント情報を１件特定する（ステップＳ１７）。そして、特定されたインシデント情報について換算テーブルから該当ポイントを特定する（ステップＳ１９）。すなわち、インシデント情報に含まれる障害状態及び影響度に対応するリスクポイント値を読み出す。

また、クレームリスクポイント算出部２５は、重みデータ格納部２６にデータの設定があれば、リスクポイント値の調整を実施する（ステップＳ２１）。例えば、図６のような重みテーブルを用いる。図６の例では、機種コード（機種コードの一部の場合もある）と、対応する重み値とが登録されている。図６の例では、機器の元々の信頼性が高いものについては、障害が発生すること自体が問題なので大きな重み値が設定されており（例えばＰＣやＰＣサーバよりＵＮＩＸ（登録商標）サーバの方が信頼性が高いので大きな重み値が設定され）、機器の信頼性が低いもの（例えばＰＣ）については、障害がある程度発生することが見込まれているので小さな重み値が設定されている。このような、重みテーブルが存在する場合には、ステップＳ１７で特定されたインシデント情報に含まれる機種コードと一致する又は部分一致する重み値が登録されていれば、当該重み値を読み出し、ステップＳ１９で特定されたリスクポイント値に乗ずることによって調整を行う。加算用の重み値（負の値もある）を用意して加算するようにしても良い。

また、図７に示すような機器の導入日（場合によって製造日）データが重みデータ格納部２６に格納されている場合には、このデータを用いてリスクポイント値を調整するようにしても良い。図７の例では、機種コードと装置番号とに対応して、導入日（又は製造日）を登録している。本実施の形態では、導入日（又は製造日）から所定期間（例えば６ヶ月）以内に発生した障害は、後々数多くの障害が発生する兆候であったり、大きな障害に繋がったりするので、早めに本格的な対処が必要ということで例えばステップＳ１９で特定されたリスクポイント値を２倍する。具体的には、ステップＳ１７で特定されたインシデント情報に含まれる機種コード及び装置番号とで図７のテーブルを検索して、該当する導入日（又は製造日）と、インシデント情報に含まれる日時とを比較して６ヶ月以内であるかどうかを判断する。６ヶ月以内であれば、ステップＳ２１では、ステップＳ１９で特定されたリスクポイント値を２倍する。所定の値を加算しても良い。

また、クレームリスクポイント算出部２５は、ステップＳ２１で調整されたリスクポイント値（ステップＳ２１が実施されない場合にはステップＳ１９で特定された値）を、従前のリスクポイント累積値に加算することにより、リスクポイント値を累積する（ステップＳ２３）。そして、全ての抽出インシデント情報を処理したか判断する（ステップＳ２５）。未処理のインシデント情報が存在する場合にはステップＳ１７に戻る。一方、全ての抽出インシデント情報について処理した場合には、リスクポイント累積値が、動作モードに応じた閾値を超えたか判断する（ステップＳ２７）。リスクポイント累積値が、動作モードに応じた閾値以下である場合には、処理した抽出インシデント情報についてはこれ以降では使用しないので抽出インシデント格納部２４から削除する（ステップＳ３１）。そしてステップＳ３３に移行する。

一方、リスクポイント累積値が、動作モードに応じた閾値を超えた場合には、クレームリスクポイント算出部２５は、例えば新規インシデント情報のインシデント番号等を含むアラーム出力指示をアラーム出力部２８に出力する。アラーム出力部２８は、クレームリスクポイント算出部２５からの指示に応じて、動作モードに応じたアラームのデータを生成して、アラームデータ格納部２９に格納すると共に、例えば管理者端末４０に出力する（ステップＳ２９）。

例えば、第１のモードでは、上で述べたように特定の顧客の特定の機器について問題を抽出するようになっているので、アラーム出力部２８は、顧客コードと機種コード及び装置番号とを少なくとも含むデータをアラームデータとして生成する。その他抽出されたインシデント情報をそのままアラームデータとして生成するようにしても良い。

ステップＳ２９の後又はステップＳ３１の後に、動作モードが第１モードであれば（ステップＳ３３：Ｙｅｓルート）、端子Ｂを介して図２のステップＳ９に移行する。一方、動作モードが第２モードであれば（ステップＳ３５：Ｙｅｓルート）、端子Ｃを介して図８の処理に移行する。また、動作モードが第２モードでなく第３モードであれば（ステップＳ３５：Ｎｏルート）、端子Ｄを介して図８の処理に移行する。

図２の処理フローの説明に戻って、ステップＳ５で抽出インシデント情報の件数が第１の閾値未満である場合、又は端子Ｂから遷移した後、インシデント抽出処理部２２は、新規インシデント情報に含まれる顧客コードと機種コードで障害情報ＤＢ２１を検索し、新規インシデント情報に含まれる顧客コード及び機種コードに一致し且つ新規インシデント情報に含まれる基準時刻から第２の期間（例えば１週間）以内に発生したインシデント情報を抽出する（ステップＳ９）。

ここでは、同一顧客で同一機種について短期間で障害が多発しているという事象を抽出している。このように、同一顧客で同一機種について障害が多発している場合には、当然ながらこの機種については今後も同様に問題を生ずる可能性があるので根本的な対処が望まれる。また、顧客対応としても、特定の顧客に短期間で障害が多発するようであれば、顧客に対する釈明も必要となる。従って、このような障害についてのリスクを計量して、必要であれば対処するものである。

そして、インシデント抽出処理部２２は、抽出インシデント情報の件数が第２の閾値（例えば３。すなわち新規インシデント情報以外にもう２件登録されているか。）以上となっているか判断する（ステップＳ１１）。抽出インシデント情報の件数が第２の閾値以上となっていれば、抽出インシデント情報を抽出インシデント格納部２４に格納する。

そして、インシデント抽出処理部２２は、動作モードを第２モードに設定して（ステップＳ１３）、クレームリスクポイント算出部２５に処理開始を指示する。そして、端子Ａを介して図４の処理に移行する。図４の処理は上で述べたのと同じであるので詳細な説明は省略する。

但し、閾値及び換算テーブル格納部２７から第２モードに応じた閾値及び換算テーブルを読み出すわけであるが、第２モードでは第１モードよりも抽出されるインシデント情報の件数が多いので、アラームを出すべきインシデント情報出現態様に基づき閾値と換算テーブル中の値との関係を調整する。例えば、換算テーブルの最高値の３倍以上に閾値を設定する。但し、同じ換算テーブルを用いて閾値のみを調整する場合もある。

さらに、ステップＳ２９では、第２モードに応じたアラームデータを生成する。第２モードでは、少なくとも新規インシデント情報に含まれる顧客コード及び機種コードを含むアラームデータを生成する。但し、抽出されたインシデント情報をそのままアラームデータとして用いるようにしても良い。

また、第２モードなので図４の処理からは端子Ｃを介して図８の処理に移行する。また、ステップＳ１１で、抽出インシデント情報の件数が第２の閾値未満である場合には、端子Ｃを介して図８の処理に移行する。

図８の処理の説明に移行して、インシデント抽出処理部２２は、月別障害件数テーブル２３において、新規インシデント情報に含まれる顧客コードについての今月の障害件数を１インクリメントする（ステップＳ４１）。月別障害件数テーブル２３は、例えば図９のようなテーブルである。図９の例では、月別に、各顧客コードについて、発生した障害の件数が登録されている。

また、インシデント抽出処理部２２は、新規インシデント情報に含まれる顧客コードで月別障害件数を検索して、例えば６ヶ月分のデータを抽出する（ステップＳ４３）。そして、予め定められた障害急増の条件を満たしているか判断する（ステップＳ４５）。例えば、今月の障害件数が６ヶ月間における最低障害発生件数月の件数の例えば３倍以上になっているか判断する。但し、極端に少ない件数（例えば０や１など）についてはそのような値を用いずに次に大きな値を用いるように調整する場合もある。このような条件を満たす場合には、障害情報ＤＢ２１を、新規インシデント情報に含まれる顧客コードで検索し、新規インシデント情報に含まれる顧客コードに一致し且つ今月発生したインシデント情報を抽出し、抽出インシデント格納部２４に格納する（ステップＳ４７）。

さらに、インシデント抽出処理部２２は、動作モードを第３モードに設定し（ステップＳ４９）、端子Ａを介して図４の処理に移行する。図４の処理は上で述べたのと同じであるので詳細な説明は省略する。

但し、閾値及び換算テーブル格納部２７から第３モードに応じた閾値及び換算テーブルを読み出すわけであるが、第３モードでは第１モードよりも抽出されるインシデント情報の件数が非常に多いので、アラームを出すべきインシデント情報出現態様を想定してそれに併せて閾値と換算テーブル中の値との関係を調整する。但し、同じ換算テーブルを用いて閾値のみを調整する場合もある。

さらに、ステップＳ２９では、第３モードに応じたアラームデータを生成する。第３モードでは、少なくとも新規インシデント情報に含まれる顧客コードを含むアラームデータを生成する。但し、抽出されたインシデント情報をそのままアラームデータとして用いるようにしても良い。

また、第３モードなので図４の処理からは端子Ｄを介して図８の処理に移行して処理を終了する。また、ステップＳ４５で、抽出インシデント情報の件数が急増の条件を満たしていないと判断された場合には、処理を終了する。具体的には、次のインシデント情報の新規登録を待つ。

以上述べたような処理を実施することによって、障害通知への即座の対応とは別に、例えば同一機器で連続して障害が発生している場合、同一顧客且つ同一機種で相次いで障害が発生している場合、同一顧客で障害が急増している場合といった、現システムに内在し且つ根本的な対策が必要で、顧客対策としても放置できないようなリスクの高い障害を抽出してアラームを出力できるようになる。

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

さらに、アラームとして出力するデータについては、必要に応じて変更することも可能である。さらに、管理者端末４０から障害情報ＤＢ２１の検索を指示できるようにしてもよい。

また、インシデント抽出処理部２２が抽出すべき事象については、様々なパターンが考えられる。例えば、月別の障害件数の顧客順位が所定の条件を満たしつつ上昇した場合といった条件で事象を抽出しても良い。さらに、例えば２以上の条件を組み合わせて事象を検出する場合もある。例えば、顧客を問わず同一機種で障害が増加しており、且つ同一顧客の同一機器で障害が連続した場合というような条件付けも可能である。また、同一顧客ではなく、全ての顧客についての障害について条件（例えば同一機種）をつけて抽出するようにしても良い。

さらに、換算テーブルは、より多くの状態やレベルについてのテーブルであってもよい。

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

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

上で述べたような条件を満たす複数件のインシデント情報が検出された場合には通常実施される対処療法的な処置ではシステムなどに潜在する問題を解決できず、結果的に顧客からのクレームを生じさせる可能性がある。従って、上で述べたような条件を満たす複数件のインシデント情報について設定されているリスクポイントテーブル及び所定の閾値から、顧客からのクレームを生じさせるほどの高いリスクがあるかを判別して、システムなどに潜在する問題の根本からの解決に取りかかるべきか否かのスクリーニングを自動的に行うものである。

なお、複数件のインシデント情報で特定される事象は、例えば同一顧客の同一機器について複数件のインシデント情報が例えば１月以内に検出された第１のケースや、同一顧客の同一機種について複数件のインシデント情報が例えば１週間以内に検出された第２のケースなど、潜在する問題の顕在化の兆候に相当する事象である。

なお、上で述べた対象物識別子が機種識別子及び機器識別子を含むようにしてもよい。その場合には、インシデント情報格納部を、第１のインシデント情報に含まれる顧客識別子と対象物識別子のうち機種識別子とで検索して、第１のインシデント情報に含まれる顧客識別子と対象物識別子の機種識別子が一致する対象物識別子とを含み且つ第１のインシデント情報に含まれる基準時刻から所定期間より短い第２の所定時間内に発生又は受け付けたインシデント情報を抽出するステップと、第２の所定件数以上の件数のインシデント情報が抽出された場合、第１のインシデント情報及び抽出されたインシデント情報の各々について、障害状態の各状態及び影響度の各レベルに対応付けて第２のリスクポイントが登録されている第２のリスクポイントテーブルからインシデント情報に含まれる障害状態及び影響度が該当する第２のリスクポイントを読み出し、当該第２のリスクポイントを合計することにより第２の総合リスクポイントを算出するステップと、第２の総合リスクポイントが第２の所定の閾値を超えた場合には、第１のインシデント情報を特定する情報又は対象物識別子の機種識別子を少なくとも含むアラームを管理コンピュータに出力するステップとをさらに含むようにしても良い。このように例えば上で述べた第１のケースに加え上で述べた第２のケースを検出してリスクを判別するようにしてもよい。

また、本障害対処法は、顧客識別子毎に第３の所定期間毎のインシデント情報の件数を格納するインシデント件数データ格納部から、第１のインシデント情報に含まれる顧客識別子についての、第４の所定期間内における第３の所定期間毎のインシデント情報の件数を抽出するステップと、第４の所定期間内における第３の所定期間毎のインシデント情報の件数が所定の条件を満たすように増加している場合には、インシデント情報格納部から第１のインシデント情報の基準時刻から第３の所定期間内又は基準時刻を含む第３の所定期間内に受け付けた又は発生した、第１のインシデント情報の顧客識別子と同一の顧客識別子を含むインシデント情報を検出するステップと、第１のインシデント情報及び抽出されたインシデント情報の各々について、障害状態の各状態及び影響度の各レベルに対応付けて第３のリスクポイントが登録されている第３のリスクポイントテーブルからインシデント情報に含まれる障害状態及び影響度が該当する第３のリスクポイントを読み出し、当該第３のリスクポイントを合計することにより第３の総合リスクポイントを算出するステップと、第３の総合リスクポイントが第３の所定の閾値を超えた場合には、第１のインシデント情報の顧客識別子を少なくとも含むアラームを管理コンピュータに出力するステップとをさらに含むようにしても良い。このように特定機種や特定機器に関係なく特定の顧客についてのインシデント情報が所定の条件を満たすように増加している場合には、当該特定の顧客からのクレームが発生する蓋然性が高くなるので、包括的な対策を講じるべきであるか否かについてリスクを判断するものである。

また、上で述べた算出ステップが、対象物識別子毎に当該対象物識別子で特定される機器の導入日又は製造日を格納する機器管理データ格納部から、インシデント情報の対象物識別子に対応する導入日又は製造日を抽出し、抽出された導入日又は製造日がインシデント情報の基準時刻（を含む日）から第５の所定期間内であるか判断するステップと、抽出された導入日又は製造日がインシデント情報の基準時刻（を含む日）から第５の所定期間内である場合には、読み出されたリスクポイントに所定値を加算又は乗算するステップとを含むようにしてもよい。製造日又は導入日から早期の段階で障害が報告される場合には今後のリスクが高いことが予見されるので、リスクポイントを増加させるものである。

さらに、上で述べた対象物識別子が、機種識別子及び機器識別子を含むようにしてもよい。その場合、上で述べた算出ステップが、機種識別子に対応付けて重み係数が格納されている機種重みデータ格納部から、インシデント情報に含まれる対象物識別子の機種識別子に対応付けられている重み係数を読み出すステップと、リスクポイントの合計値に重み係数を乗算するステップとを含むようにしてもよい。パーソナルコンピュータよりＵＮＩＸ（登録商標）などの機器の方がもともとの信頼性が高くなるように製造されているはずである。従って、機種によってリスクポイントを重み付けして合計のリスクポイントを算出するものである。

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

１０障害受付システム２０障害管理システム
３０ＬＡＮ４０管理者端末
２１障害情報ＤＢ２２インシデント抽出処理部
２３月別障害件数テーブル２４抽出インシデント格納部
２５クレームリスクポイント算出部２６重みデータ格納部
２７閾値及び換算テーブル格納部２８アラーム出力部
２９アラームデータ格納部

Claims

コンピュータが、
障害の受け付け時刻又は発生時刻である基準時刻と顧客識別子と対象物識別子と障害状態と障害の影響度とを含む第１のインシデント情報の新規登録を検出するステップと、
前記インシデント情報を格納するインシデント情報格納部を、前記第１のインシデント情報に含まれる前記顧客識別子と前記対象物識別子の少なくとも一部とで検索して、前記第１のインシデント情報に含まれる前記顧客識別子と前記対象物識別子の少なくとも一部と一致する対象物識別子とを含み且つ前記第１のインシデント情報に含まれる前記基準時刻から遡った所定期間内に発生又は受け付けたインシデント情報を抽出する抽出ステップと、
所定件数以上の件数の前記インシデント情報が抽出された場合、前記第１のインシデント情報及び抽出された前記インシデント情報の各々について、前記障害状態の各状態及び前記影響度の各レベルに対応付けてリスクポイントが登録されているリスクポイントテーブルから前記インシデント情報に含まれる前記障害状態及び前記影響度が該当するリスクポイントを読み出し、当該リスクポイントを合計することにより総合リスクポイントを算出する算出ステップと、
前記総合リスクポイントが所定の閾値を超えた場合には、前記第１のインシデント情報を特定する情報又は前記対象物識別子を少なくとも含むアラームを管理コンピュータに出力するステップと、
を実行する障害対処方法。
前記対象物識別子が機種識別子及び機器識別子を含み、
前記インシデント情報格納部を、前記第１のインシデント情報に含まれる前記顧客識別子と前記対象物識別子のうち前記機種識別子とで検索して、前記第１のインシデント情報に含まれる前記顧客識別子と前記対象物識別子の前記機種識別子が一致する対象物識別子とを含み且つ前記第１のインシデント情報に含まれる前記基準時刻から前記所定期間より短い第２の所定期間内に発生又は受け付けたインシデント情報を抽出するステップと、
第２の所定件数以上の件数の前記インシデント情報が抽出された場合、前記第１のインシデント情報及び抽出された前記インシデント情報の各々について、前記障害状態の各状態及び前記影響度の各レベルに対応付けて第２のリスクポイントが登録されている第２のリスクポイントテーブルから前記インシデント情報に含まれる前記障害状態及び前記影響度が該当する第２のリスクポイントを読み出し、当該第２のリスクポイントを合計することにより第２の総合リスクポイントを算出するステップと、
前記第２の総合リスクポイントが第２の所定の閾値を超えた場合には、前記第１のインシデント情報を特定する情報又は前記対象物識別子の前記機種識別子を少なくとも含むアラームを前記管理コンピュータに出力するステップと、
をさらに含む請求項１記載の障害対処方法。
前記顧客識別子毎に第３の所定期間毎の前記インシデント情報の件数を格納するインシデント件数データ格納部から、前記第１のインシデント情報に含まれる前記顧客識別子についての、第４の所定期間内における前記第３の所定期間毎の前記インシデント情報の件数を抽出するステップと、
前記第４の所定期間内における前記第３の所定期間毎の前記インシデント情報の件数が所定の条件を満たすように増加している場合には、前記インシデント情報格納部から前記第１のインシデント情報の前記基準時刻を含む前記第３の所定期間内に受け付けた又は発生した、前記第１のインシデント情報の前記顧客識別子と同一の顧客識別子を含む前記インシデント情報を抽出するステップと、
前記第１のインシデント情報及び抽出された前記インシデント情報の各々について、前記障害状態の各状態及び前記影響度の各レベルに対応付けて第３のリスクポイントが登録されている第３のリスクポイントテーブルから前記インシデント情報に含まれる前記障害状態及び前記影響度が該当する第３のリスクポイントを読み出し、当該第３のリスクポイントを合計することにより第３の総合リスクポイントを算出するステップと、
前記第３の総合リスクポイントが第３の所定の閾値を超えた場合には、前記第１のインシデント情報の前記顧客識別子を少なくとも含むアラームを前記管理コンピュータに出力するステップと、
をさらに含む請求項１又は２記載の障害対処方法。
前記算出ステップが、
前記対象物識別子毎に当該対象物識別子で特定される機器の導入日又は製造日を格納する機器管理データ格納部から、前記インシデント情報の前記対象物識別子に対応する前記導入日又は製造日を抽出し、抽出された前記導入日又は製造日が前記インシデント情報の前記基準時刻から第５の所定期間内であるか判断するステップと、
抽出された前記導入日又は製造日が前記インシデント情報の前記基準時刻から前記第５の所定期間内である場合には、読み出された前記リスクポイントに所定値を加算又は乗算するステップと、
を含む請求項１乃至３のいずれか１つ記載の障害対処方法。
前記対象物識別子が、機種識別子及び機器識別子を含み、
前記算出ステップが、
前記機種識別子に対応付けて重み係数が格納されている機種重みデータ格納部から、前記インシデント情報に含まれる前記対象物識別子の前記機種識別子に対応付けられている前記重み係数を読み出すステップと、
読み出された前記リスクポイントに前記重み係数を乗算するステップと、
を含む請求項１乃至３のいずれか１つ記載の障害対処方法。
請求項１乃至５のいずれか１つ記載の障害対処方法をコンピュータに実行させるためのプログラム。
障害の受け付け時刻又は発生時刻である基準時刻と顧客識別子と対象物識別子と障害状態と障害の影響度とを含む第１のインシデント情報の新規登録を検出する手段と、
前記インシデント情報を格納するインシデント情報格納部を、前記第１のインシデント情報に含まれる前記顧客識別子と前記対象物識別子の少なくとも一部とで検索して、前記第１のインシデント情報に含まれる前記顧客識別子と前記対象物識別子の少なくとも一部と一致する対象物識別子とを含み且つ前記第１のインシデント情報に含まれる前記基準時刻から遡った所定期間内に発生又は受け付けたインシデント情報を抽出する抽出手段と、
所定件数以上の件数の前記インシデント情報が抽出された場合、前記第１のインシデント情報及び抽出された前記インシデント情報の各々について、前記障害状態の各状態及び前記影響度の各レベルに対応付けてリスクポイントが登録されているリスクポイントテーブルから前記インシデント情報に含まれる前記障害状態及び前記影響度が該当するリスクポイントを読み出し、当該リスクポイントを合計することにより総合リスクポイントを算出する手段と、
前記総合リスクポイントが所定の閾値を超えた場合には、前記第１のインシデント情報を特定する情報又は前記対象物識別子を少なくとも含むアラームを管理コンピュータに出力する手段と、
を有する障害対処装置。