JP2012168687A

JP2012168687A - 情報処理装置及び情報処理方法及びプログラム

Info

Publication number: JP2012168687A
Application number: JP2011028350A
Authority: JP
Inventors: Ryoko Kawagishi; 諒子川岸
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2011-02-14
Filing date: 2011-02-14
Publication date: 2012-09-06

Abstract

【課題】障害の発生原因において関連のある障害を正確に判定し、障害状態の設定を自動的に更新する。
【解決手段】障害関連性情報記憶部４０１５は、情報システムで発生する障害に対して、障害発生原因において関連のある障害を関連障害として定義する障害関連性情報を記憶している。解析結果情報記憶部４０１２は、情報システムで発生した障害と、障害状態とを示す解析結果情報を記憶している。クライアントＩ／Ｆ部４０１３が、障害状態が変化した障害と、新たな障害状態が示される更新要求を入力し、障害関連性判定部４０１４が、解析結果情報において当該障害の障害情報を新たな障害状態に更新するとともに、障害関連性情報において当該障害に関連障害が定義されている場合に、解析結果情報において当該関連障害の障害状態を新たな障害状態に更新する。
【選択図】図２

Description

本発明は、データ処理システムにおいて、発生した障害の関連性を判定する技術に関する。

近年、業務プロセス管理などの考えに基づき、業務プロセスの変更に対して、柔軟に対応できる情報システムが求められており、サービス指向アーキテクチャ（ＳＯＡ：ＳｅｒｖｉｃｅＯｒｉｅｎｔｅｄＡｒｃｈｉｔｅｃｔｕｒｅ）が注目されている。
ＳＯＡとは、アプリケーションやソフトウェアが提供する機能を、業務の視点でサービスという機能単位に部品化し、これらを必要に応じて組み合わせることによって、業務プロセスの変更に対しても迅速かつ柔軟に対応可能な情報システムを構築する手法である。
ＳＯＡでは、自社だけでなく他社が提供するサービスを組み合わせることによって情報システムを構築する（特許文献１）。
ＳＯＡシステムを実現するためのＳＯＡ基盤を提供するミドルウェア製品として、ＥＳＢ（ＥｎｔｅｒｐｒｉｓｅＳｅｒｖｉｃｅＢｕｓ）と呼ばれるものがある。
ＥＳＢは、要求元からサービスの要求を受け付け、その要求を該当サービスへ割り振り、結果を要求元に返却する。
ＳＯＡによって構築された情報システムでは、自社だけでなく他社のサービスを利用したり、ＥＳＢなどのミドルウェアの機能によりサービスを振り分ける。
そのため、サービスの依存関係（呼び出し関係）が複雑になっている。

ＳＯＡで構築された情報システムでは、障害が単独で発生することや、１件の障害が原因となって複数のサービスで障害が検出されることがある。
ＳＯＡにより構築された情報システムで１００件の障害が検出された場合を考える。
この時、該当システムの運用管理業務を行っている運用監視者が、検出された１００件のうちの１件である障害Ａに対する処置を実施し、その障害を回復させたとする。
この時、残り９９件の障害は、（１）回復した障害が原因で障害と検出された障害、（２）全く異なる原因で障害と検出された障害の２種類に分けられる。
（１）の障害は障害Ａが原因で障害と検出されていたため、障害Ａの回復と同時に回復するが、（２）の障害は異なる原因で障害と検出されたため回復しないはずである。
ＳＯＡで構築された情報システムで発生した障害では、サービスの依存関係が複雑であるため、障害の因果関係も複雑となっており、（１）と（２）を自動的に判定することは難しい。

一般的な運用管理業務では、検出された障害情報とともに、その障害状態（例えば障害発生、処置中、回復済、処置不要など）の管理を行う必要がある。
多くの運用管理装置が、このような障害管理を行う機能を備えている。

図１０は運用管理装置の運用管理画面の一例を示す。
画面には、障害状態を設定するためのボタン（処置中、回復済、処置不要）と、検出された障害情報の一覧が表示されている。
障害情報の一覧では、１行が１件の障害を示しており、障害状態、障害発生日時、障害の検出されたサービス名と業務名、セッション名、障害名称などを表示する。
従来の運用管理装置では、運用監視者が、図１０のような画面から、一覧表示された障害情報の１件１件に対して、手動で障害状態を設定していた。

障害が発生した場合にその影響を自動で判定する技術として、管理対象の依存関係を利用した障害影響判定方法がよく用いられている（特許文献２）。
この方法では、管理対象を包含関係（親子関係）として管理することで影響の有無を判定する。
図１１に例を示す。
図１１は、ある会社の支社のサーバ構成を表しており、関東支社にはサーバＡ、Ｂ、Ｃがあり、関東支社（親）とサーバ（子）が包含関係にあることを示している。
管理対象がこのような従来の包含関係では、サーバ（子）に障害が発生した場合、子の障害を親に伝搬させることにより、親にも影響があることを示す。
子の障害を親に伝搬させる時には、一定の伝搬係数をかけて伝搬する。
伝搬係数の決め方は様々であるが、例えば子の重要度を考慮にいれた伝搬係数を事前に定義ファイルに定義しておき、その値を参照する方法が考えられる。
親は障害が発生した子ノードとその伝搬係数をかけたものの総和から、あらかじめ定義しておいた親の障害閾値と比較して、障害影響を表示する。
図１１では、サーバＢで障害が発生し、その影響として関東支社が部分障害と判定された例を示している。

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

サービス運用管理においても、一般的な運用管理業務と同様に、障害状態を管理する必要がある。
ＳＯＡで構築された情報システムは、一般的な情報システムよりも障害の因果関係が複雑になるため、運用監視者は、サービスの依存関係や障害内容、障害の発生順序など様々な情報から障害の因果関係を判定した上で、障害状態を判断し、障害を管理する必要がある。
従来通り、運用監視者が障害１件１件に対して手動で障害状態を設定する場合、障害の関連性判定には、手間や時間がかかり、運用監視者の負荷が高くなるという課題がある。

この課題を解決するために、上述の従来の障害影響判定方法を適用し、障害の関連性判定を自動化することを考える。
障害影響判定方法を、サービスの障害回復時における障害の関連性判定にそのまま適用した場合、サービスの親子関係のみで障害の関連性を判定することになる。
そのため、親子の障害が独立して発生している場合に、誤った判定をしてしまうという課題がある。

本発明は、上記のような課題を解決することを主な目的としており、障害の発生原因において関連のある障害を正確に判定し、障害に対する対処状況の設定を自動的に更新する構成を実現することを主な目的とする。

本発明に係る情報処理装置は、
管理対象システムで発生する障害に対して、障害発生原因において関連のある障害を関連障害として定義する関連障害情報を記憶する関連障害情報記憶部と、
前記管理対象システムで発生した障害と、発生した障害に対する対処状況とを示す対処状況情報を記憶する対処状況情報記憶部と、
対処状況が変化した障害を状況変化障害として示すとともに、前記状況変化障害の新たな対処状況を示す更新要求を入力する入力部と、
前記対処状況情報において前記状況変化障害の対処状況を前記更新要求に示される新たな対処状況に更新するとともに、前記関連障害情報において前記状況変化障害に関連障害が定義されている場合に、前記対処状況情報において当該関連障害の対処状況を前記更新要求に示される新たな対処状況に更新する対処状況更新部とを有することを特徴とする。

本発明によれば、障害発生原因において関連のある障害を関連障害として定義し、状況変化障害に関連障害が存在する場合に、状況変化障害とともに関連障害の対処状況を新たな対処状況に更新するため、運用監視者が、障害の因果関係を判定し、関連障害を抽出し、関連障害の対処状況を手動で更新する必要がなくなる。これにより、運用監視者の負荷の軽減が見込める。

実施の形態１に係るシステム構成例を示す図。実施の形態１に係るサービス運用管理サーバ装置の構成例を示す図。実施の形態１に係る障害定義情報の例を示す図。実施の形態１に係る障害関連性情報の例を示す図。実施の形態１に係る業務フローとＥＳＢによるサービスの振り分けの例を示す図。実施の形態１に係る障害関連性判定部の動作例を示すフローチャート。実施の形態１に係る障害関連性判定部の動作例を示すフローチャート。実施の形態１に係る解析結果情報の例を示す図。実施の形態１に係るサービス運用管理サーバ装置のハードウェア構成例を示す図。検出された障害情報一覧表示の例。従来の障害影響判定方法を適用できる包含関係にある管理対象の例。

実施の形態１．
本実施の形態では、障害の関連性判定を正確に行うことを可能とし、障害状態の設定を自動化する構成を説明する。
より具体的には、障害の関連性を判定するための障害関連性情報を保管し、障害関連性情報を元に、発生している障害と障害の関連性を判定する手段を備える構成を説明する。
そして、本実施の形態に係る構成によれば、回復したある障害に対して障害状態を手動で設定すると、回復した障害と関連して発生した障害が特定され、その障害の障害状態が、回復済や処置不要などに自動的に設定される。
そのため運用監視者は、ある障害が回復した時に、回復した障害と他の障害との因果関係を判定し、関連する障害を検出し、関連する障害の障害状態を手動で設定する必要がなくなる。
これにより、運用監視者の負荷軽減による作業時間の短縮の効果が期待できる。

図１は、本実施の形態に係るシステム構成例を示す。
本実施の形態に係るシステムは、業務用クライアント装置１０１と情報システム２０、管理用クライアント装置３０１と運用管理装置４０の４つの装置から構成される。

業務用クライアント装置１０１は、システム利用者が業務を行うために利用するクライアント装置である。
情報システム２０は、ＳＯＡで構築された情報システムである。
情報システム２０は、管理対象システムの例である。

管理用クライアント装置３０１は、システム運用監視者が運用管理のために利用するクライアント装置である。

運用管理装置４０はサービスの運用管理を行う装置であり、サービス運用管理サーバ装置４０１及び情報記憶装置４０２で構成される。
サービス運用管理サーバ装置４０１は、情報処理装置の例である。

情報システム２０において、業務サーバ装置２０１は、業務用クライアント装置１０１からの要求を受け付け、業務フローに従い、ＥＳＢ（ＥｎｔｅｒｐｒｉｓｅＳｅｒｖｉｃｅｓＢｕｓ）サーバ装置２０２に対してサービスの呼び出しを行い、業務を実行するサーバ装置である。
ＥＳＢサーバ装置２０２は、業務サーバ装置２０１から要求を受け付け、適切なサービスを呼び出す機能を搭載したサーバ装置である。

実行ログ２０２１は、ＥＳＢサーバ装置２０２で記録されるサービスに関連する実行ログである。
実行ログ２０２１には、業務サーバ装置２０１がどのサービスを呼び出し、呼び出したサービスが正常に値を返したか、異常があったか、などの情報が記録されている。

ネットワーク２０３は、各サーバ装置が接続されているインターネットやイントラネットなどのネットワークである。

サーバ装置Ａ２０４やサーバ装置Ｂ２０５は、自社または他社にあるサービスを提供しているサーバ装置である。
サービスＡ１（２０４１）、サービスＡ２（２０４２）、サービスＢ１（２０５１）、サービスＢ２（２０５２）はデータ処理サービスの実体である。
各サービスは、ＥＳＢサーバ装置２０２を介して業務サーバ装置２０１から利用可能となるようインタフェースを公開しているソフトウェアである。

運用管理装置４０において、サービス運用管理サーバ装置４０１は、実行ログ２０２１を受け取り、情報記憶装置４０２内の障害定義情報４０２１を元に、実行ログ２０２１から障害を検出し、管理用クライアント装置３０１に検出した結果を表示する。
また、表示した画面から障害状態の入力を受け付け、管理を行う。
画面から障害状態が入力された時には、情報記憶装置４０２内の障害関連性情報４０２２を利用して、現在発生している障害の関連性を判定し、関連障害の障害状態も合わせて設定する。

情報記憶装置４０２は、障害定義情報４０２１および障害関連性情報４０２２を記憶している。
障害定義情報４０２１は、サービス運用管理サーバ装置４０１が障害を検出する時に使用する情報である。
障害定義情報４０２１には、検出対象のサービス名と検出する障害名、障害検出条件などの情報が格納される。
障害関連性情報４０２２は、サービス運用管理サーバ装置４０１が障害の関連性を判定する時に使用する情報である。
障害関連性情報４０２２には、関連して発生することのある障害に対して、対象障害と関連障害および関連性の判定条件などの情報が格納される。
つまり、障害関連性情報４０２２は、情報システム２０で発生する障害に対して、障害発生原因において関連のある障害を関連障害として定義する情報である。
障害関連性情報４０２２は、関連障害情報の例である。

本実施の形態では、障害関連性情報４０２２に、障害の関連性を判定するための情報が格納されており、この情報を元に、サービス運用管理サーバ装置４０１が障害の関連性を判定する。
サービス運用管理サーバ装置４０１は、ＥＳＢサーバ装置２０２からサービスの実行状況を示す実行ログ２０２１を入力として受け取り、障害定義情報４０２１を元に実行ログ２０２１の解析を行い、サービスに障害が発生したと検知する。
検知した障害に対し、運用監視者が処置を実施し、回復した場合には、障害関連性情報４０２２を元に、まだ処置を実施していない障害に対して障害の関連性判定条件に合致するか否かを判定し、関連障害を特定する。
障害関連性情報の判定条件に合致しない障害については、回復した障害と関連のない障害と判定でき、合致した障害については、回復した障害が原因となって発生した障害であると判定することができる。

図２は、サービス運用管理サーバ装置４０１の詳細な構成例を示す図である。

図２において、解析部４０１１は、実行ログ２０２１を受け取り、情報記憶装置４０２内の障害定義情報４０２１を元に実行ログを解析し、実行時に障害が発生したサービスを障害発生サービスとして検出する。
検出した障害情報は解析結果情報として解析結果情報記憶部４０１２に保管する。

解析結果情報記憶部４０１２は、解析部４０１１が実行ログを解析した結果、障害として検出された情報（解析結果情報）を保管するための記憶装置である。
解析結果情報が、サービス運用管理において管理対象となる障害情報である。
検出された障害は全て解析結果情報記憶部４０１２に保管され、障害１件１件に対して、障害に対する対処状況である障害状態が付けられ、管理される。
解析部４０１１にて検出された障害には、例えば、障害状態のデフォルト値（例えば、障害発生）が設定され、解析結果情報記憶部４０１２に保管される。
デフォルト値である「障害発生」は、障害に対して未対処の状態であることを示している。
運用監視者によってある障害の状態が「回復済」に設定された場合には、解析結果情報記憶部４０１２に保管されている該当障害の障害状態が「回復済」に更新される。
解析結果情報は、このように、情報システム２０で発生した障害と、発生した障害に対する対処状況とを示す情報であり、対処状況情報の例である。
また、解析結果情報記憶部４０１２は、対処状況情報記憶部の例である。

図８は、本実施の形態に係る解析結果情報の例を示す。
図８において、「障害状態」の欄には、発生した障害に対する対処状況が示され、例えば、「障害発生」、「処置中」、「処置不要」、「回復済」等が示される。
「障害発生日時」の欄には、障害が発生した日時が示される。
「サービス名」の欄は、障害が発生したサービスの名称が示される。
「業務名」の欄は、「サービス名」に示されるサービスが実施されていた業務の名称が示される。
「セッション」の欄には、「サービス名」に示されるサービスが実施されていたセッションが示される。
セッションとは、情報システム２０において複数のデータ処理を対応付けて管理する単位であり、例えば、業務用クライアント装置１０１が業務サーバ装置２０１に接続／ログインしてから、切断／ログオフするまでの一連の操作、データ処理、通信をまとめて１セッションという。
「障害ＩＤ」の欄は、障害の識別子である障害ＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）が示される。
「障害ＩＤ」の欄に示されるＩＤは、後述する図３に示す障害ＩＤ、図４に示す対象障害ＩＤ及び関連障害ＩＤに対応する。
障害ＩＤの詳細は、図３及び図４とともに説明する。

クライアントＩ／Ｆ（インタフェース）部４０１３は、解析部４０１１の解析結果である解析結果情報を受け取り、表示するための画面を提供する。
また、クライアントＩ／Ｆ部４０１３は、表示した障害に対して、障害状態を手動で設定するためのインタフェースを持つ。
例えば、図１０のように解析結果情報記憶部４０１２に対応する障害情報を管理用クライアント装置３０１に一覧表示する。
運用監視者は、この情報１件１件に対して、障害状態を設定して障害管理を行う。
また、クライアントＩ／Ｆ部４０１３は、管理用クライアント装置３０１から更新要求を入力する。
更新要求は、障害状態が変化した障害（状況変化障害）が示されるとともに、当該障害の新たな障害状態が示される。
例えば、図１０の１行目に示されている障害（障害状態：障害発生、障害発生日時：１０／０９／２９０９：５０、サービス名：サービスＢ１）に対して処置が行われ、障害状態が「処置中」に変化した場合に、更新要求には、図１の１行目に示されている障害を識別するための情報と、新たな障害状態である「処置中」が管理用クライアント装置３０１からクライアントＩ／Ｆ部４０１３に入力される。
クライアントＩ／Ｆ部４０１３は、入力部及び出力部の例である。

障害関連性判定部４０１４は、クライアントＩ／Ｆ部４０１３から入力されたある障害に対する障害状態と、解析結果情報記憶部４０１２と、情報記憶装置４０２内の障害関連性情報４０２２を元に、障害の関連性を判定し、関連して発生した障害を特定する。
障害関連性判定部４０１４は、運用監視者が処置を実施して回復した障害に対して、クライアントＩ／Ｆ部４０１３へ更新要求を入力することがトリガとなって動作する。
運用監視者から更新要求が入力された際に、対象となる障害、当該障害の新たな障害状態（回復済み等）、当該障害のセッション等の情報が障害関連性判定部４０１４に入力される。
障害関連性判定部４０１４は、情報記憶装置４０２から障害関連性情報４０２２を読み出し、障害の関連性判定条件に合致するか否かを判定し、関連障害を特定する。
障害の関連性判定条件に合致しない障害については、回復した障害と関連のない障害と判定できる。
合致した障害については、回復した障害が原因となって発生した障害であると判定することができる。
関連性があると判定された障害に対しては、障害関連性判定部４０１４が自動的に解析結果情報記憶部４０１２に対して、障害状態の更新を行う。
このように、障害関連性判定部４０１４は、更新要求に示される障害（状況変化障害）の障害状態を解析結果情報において更新要求に示される新たな障害状態に更新するとともに、障害関連性情報４０２２において当該障害（状況変化障害）に関連障害が定義されている場合に、解析結果情報において当該関連障害の障害状態を更新要求に示される新たな障害状態に更新する。
なお、障害関連性判定部４０１４は、対処状況更新部の例である。

障害関連性情報記憶部４０１５は、障害関連性判定部４０１４により情報記憶装置４０２から読み出された障害関連性情報４０２２を記憶する記憶領域である。
障害関連性情報記憶部４０１５は、関連障害情報記憶部の例である。

次に、障害定義情報４０２１、障害関連性情報４０２２の詳細を説明する。
これらの情報はそれぞれ図３、図４に示すデータ構造を持っている。
なお、図３、図４において、「（ア）項目の説明」は、各データの項目名および各項目の内容を説明しており、「（イ）データの例」は、実際のデータの内容例を示している。

図３の障害定義情報４０２１の障害サービス関連表は、障害とサービスの関連を示す表である。
図３の（ア）に示す通り、障害サービス関連表の項目は、障害ＩＤ、障害を検出する対象サービス名、検出する障害名、検出する際に使用する障害検出条件から構成される。
実行ログ２０２１が障害検出条件に該当する場合、障害として検出する。
障害ＩＤは、障害サービス関連表の情報を一意に決めるＩＤであり、障害関連性情報４０２２でも使用する。
図３の（イ）にデータ例を示す。
例えば１行目のデータは、サービスＢでサービス応答なしの障害を検出するための条件は検出条件１であることを示している。
検出条件は、正規表現や式など、いろいろな形で表現できる。
解析部４０１１は、サービスＢの実行ログ２０２１を受け取った時に、この障害定義情報４０２１を取得し、検出条件１に該当する実行ログだった場合は、サービス応答なしの障害が発生していると解析し、その解析結果を解析結果情報に書き込む。

図４は障害関連性情報４０２２を示している。
障害関連性情報は、（１）関連性対応表と（２）関連性判定条件表の２つがある。
（１）関連性対応表は、障害状態が変化した（例えば、回復した）障害（対象障害）と障害発生原因において関連のある障害（関連障害）、障害間の関連性を判定するための判定条件の対応を示す表である。
対象障害と関連障害のサービスの依存関係は、業務やサービスの構成情報やフロー情報からほぼ一意に決まるため、（１）関連性対応表では、サービスの依存関係を考慮した上で、判定条件を定義する。

図４（１）の（ア）に示す通り、（１）関連性対応表の項目は、対象障害ＩＤ、対象障害のサービス名、対象障害の業務名、関連障害ＩＤ、関連障害のサービス名、関連障害の業務名と、判定条件ＩＤである。
判定条件ＩＤ以外の項目がプライマリキーとなるため、対象障害と関連障害の種類、障害発生サービス、障害発生業務ごとに関連性判定条件を設定することが出来る。
対象障害ＩＤ、関連障害ＩＤは、図３の障害定義情報で示した障害ＩＤである。
図４（１）の（イ）にデータ例を示す。
このデータ例で想定しているサービスの依存関係は図５である。
図５は、業務Ｘ１がサービスＡ、Ｂ、Ｃの３つのサービスから構成されており、サービスＢに関しては、ＥＳＢによるサービスの振り分けにより、実際にはサービスＢ１とＢ２が呼び出されていることを示している。
ここで、ＥＳＢによるサービスの呼び出し関係を親子関係、その他の呼び出し関係は兄弟関係と呼ぶことにする。
例えば、サービスＢにとってサービスＢ１、Ｂ２は子であり、サービスＢ１、Ｂ２にとってサービスＢは親である。
サービスＡ、Ｂ、Ｃは兄弟関係であり、サービスＢ１、サービスＢ２も兄弟関係である。
図４（１）の（イ）の１行目のデータは、業務Ｘ１のサービスＢでｅｉｄ１（図３よりサービス応答なし）の障害が発生した場合、業務Ｘ１のサービスＢ１のｅｉｄ３（図３よりサービス応答なし）は、関連性判定条件ｃｉｄ２を満たせば、関連性があることを示している。
これは、図５より親子関係の場合の関連性を表している。
関連性は、障害が兄弟関係の場合や、他業務の同じサービスで障害発生した場合も、親子関係の時と同様に定義することが出来る。
図４（１）の（イ）の２行目のデータは、兄弟関係の場合のデータ例であり、業務Ｘ１のサービスＢでｅｉｄ２（図３より値不正）の障害が発生した場合、業務Ｘ１のサービスＣのｅｉｄ５（図３より値不正）は、判定条件ｃｉｄ１を満たせば、関連性があることを示している。
図４（１）の（イ）の３行目のデータは、他業務の同じサービスで障害発生した場合のデータ例であり、業務Ｘ１のサービスＢでｅｉｄ１（図３よりサービス応答なし）の障害が発生した場合、業務Ｘ２のサービスＢのｅｉｄ１（図３よりサービス応答なし）は、判定条件ｃｉｄ１を満たせば、関連性があることを示している。

（２）関連性判定条件表は、（１）関連性対応表の判定条件ＩＤに対応する評価式を示している。
図４（２）の（ア）に示す通り、（２）関連性判定条件表の項目は、判定条件ＩＤ、判定を行う評価項目、条件、評価値である。
評価項目、条件、評価値に当てはまる場合、障害の関連性があると判定する。
図４（２）の（イ）にデータ例を示す。
例えば１行目のデータは、対象障害の発生日時が、関連障害の発生日時よりも前（過去）であったら関連性があることを示している。
ここでは、障害発生日時による比較条件しか例として記述していないが、これに限らない。

障害定義情報４０２１のデータは、システム管理者などにより人手で登録・更新を行うことを想定している。
新規の業務やサービスが登場した場合に、システム管理者が業務フローを定義し、業務サーバ装置２０１に登録することになるわけだが、これと同時に情報記憶装置４０２にも情報を登録する。
障害関連性情報４０２２についても同様に人手で登録・更新を行う。
障害関連性情報４０２２は、業務とサービスの構成情報や、サービスの外部仕様などの情報から障害の関連性を洗い出すことが出来ると考えられるため、新しい業務が業務サーバ装置２０１に登録されるタイミングで障害関連性情報４０２２に登録する。
あるいは、実際にサービスの障害管理を行っていくなかで、実際の障害管理で培ったノウハウから障害関連性情報４０２２に蓄積していくという運用方法も考えられる。

次に動作について説明する。
図２において、障害関連性判定部４０１４は、運用監視者が、クライアントＩ／Ｆ部４０１３が提供する画面を利用して、管理用クライアント装置３０１から、ある障害についての更新要求を入力した時に、この動作がトリガとなって動作する。
例えば、運用監視者が図１０に例示されている画面のいずれかの行を指定し、「処置中」、「回復済」、「処置不要」のうちのいずれかのボタンを押すことにより、管理用クライアント装置３０１から更新要求がサービス運用管理サーバ装置４０１に送信される。
更新要求には、例えば、対象となっているレコードを特定する情報（何行目であるかを示す情報）と、新たな障害状態（運用監視者がボタンを押した障害状態）の情報が含まれる。
このため、サービス運用管理サーバ装置４０１では、障害状態の更新の対象となる障害、当該障害の新たな障害状態、当該障害が発生したサービス名、業務名、セッションを特定することができる。

サービス運用管理サーバ装置４０１では、クライアントＩ／Ｆ部４０１３が更新要求を受信し、受信した更新要求を障害関連性判定部４０１４に渡す。
障害関連性判定部４０１４は、更新要求に基づき、解析結果情報において対象障害の障害状態を更新するとともに、障害の関連性の判定と関連性があると判定された障害に対する障害状態の更新を行う。
ＳＯＡで構築された情報システムで発生する障害は、業務、セッションなどの一連の処理の流れの中で発生すると考えられるため、障害をセッション単位に分類し、関連性の判定を行う。
セッションとは、前述したように、ユーザが情報システム内で行う一連の行動をまとめた単位である。

図６及び図７のフローチャートを用いて、障害関連性判定部４０１４の動作について説明する。
なお、図６及び図７のフローチャートに示す手順の開始前に、障害関連性判定部４０１４は、障害関連性情報４０２２を情報記憶装置４０２から読み出し、障害関連性情報記憶部４０１５に格納しておく（関連障害情報読み出しステップ）。

クライアントＩ／Ｆ部４０１３が管理用クライアント装置３０１からの更新要求を受信した際に（入力ステップ）、障害関連性判定部４０１４は、クライアントＩ／Ｆ部４０１３から更新要求を取得し、Ｓ０１において、取得した更新要求に基づき、処置が実施された障害（例えば、セッションＣのサービスＢで発生した障害ｅｉｄ１）に対して、新たな障害状態（例えば、回復済）を解析結果情報記憶部４０１２の解析結果情報に設定する（対処状況更新ステップ）。
Ｓ０２では、障害関連性判定部４０１４は、障害の関連性をセッション単位で判定するため、回復した障害と同じセッション（ここではセッションＣ）で発生している障害を解析結果情報において検索する。
Ｓ０３では、障害関連性判定部４０１４は、Ｓ０２で検索した結果、該当する障害があるかどうかを確認する。
該当する障害がある場合（Ｓ０３でＹＥＳ）はＳ０４に進む。
該当する障害がない場合（Ｓ０３でＮＯ）は、同じセッション内で障害が発生していないため、Ｓ０９に進む。

Ｓ０４では、障害関連性判定部４０１４は、Ｓ０１で障害状態を設定した障害（ここではサービスＢで発生した障害ｅｉｄ１）とＳ０２の検索によって取得した障害に該当する障害関連性情報４０２２を図４（１）の関連性対応表から検索する。
Ｓ０５では、障害関連性判定部４０１４は、Ｓ０４で検索した結果、該当する障害関連性情報があるかどうかを確認する。
つまり、Ｓ０１で障害状態を設定した障害の障害ＩＤ（ここでは障害ｅｉｄ１）が対象障害ＩＤとして示され、Ｓ０２の検索によって取得した障害の障害ＩＤが関連障害ＩＤとして示され、また、業務名やサービスＩＤが一致しているレコードが（１）関連性対応表に存在するかを確認する。
該当する障害関連性情報がある場合（Ｓ０５でＹＥＳ）はＳ０６に進む。
該当する障害関連性情報がない場合（Ｓ０５でＮＯ）はＳ０３に戻り、同じセッション内で発生している障害のうち、まだ関連性の判定をしていない障害があるかどうかを確認する。
例えば、Ｓ０２の検索によって取得した障害の障害ＩＤがｅｉｄ３であり、業務名やサービスＩＤが一致していれば、図４（１）の（イ）の１行目に対応しており、Ｓ０５でＹＥＳとなる。

Ｓ０６では、障害関連性判定部４０１４は、障害関連性情報記憶部４０１５から該当する判定条件を取得し、評価式によって回復の判定を行う。
Ｓ０７では、障害関連性判定部４０１４は、Ｓ０６の判定結果より、関連性があるかどうかを確認する。
関連性がある場合（Ｓ０７のＹＥＳ）はＳ０８に進む。
関連性がない場合（Ｓ０７のＮＯ）はＳ０３に戻る。

Ｓ０８では、障害関連性判定部４０１４は、関連すると判定された障害の障害状態を設定する（対処状況更新ステップ）。
つまり、解析結果情報において、関連すると判定された障害の障害状態を、Ｓ０１で設定した障害状態に更新する。
その後、障害関連性判定部４０１４は、Ｓ０３に戻り、同じセッション内で発生している障害のうち、まだ関連性の判定をしていない障害があるかどうかを確認する。
そして、障害関連性判定部４０１４は、同じセッション内で発生している全ての障害に対して、Ｓ０１で障害状態を設定した障害（ここではサービスＢで発生した障害ｅｉｄ１）との関連性判定が終わるまで、上述した処理を繰り返す。

Ｓ０９では、障害関連性判定部４０１４は、別セッションに対して、障害状態を設定した障害と同じサービス（ここではサービスＢ）で発生している障害（例えば、セッションＣ以外のセッションで発生したサービスＢの障害ｅｉｄ１）を、解析結果情報から検索する。
Ｓ１０では、障害関連性判定部４０１４は、Ｓ０９で検索した結果、該当する障害があるかどうかを確認する。
該当する障害がある場合（Ｓ１０でＹＥＳ）はＳ１１に進む。
該当する障害がない場合（Ｓ１０でＮＯ）は関連する障害がないため終了する。

Ｓ１１では、障害関連性判定部４０１４は、障害状態を設定した障害（ここではセッションＣのサービスＢで発生した障害ｅｉｄ１）とＳ０９の検索によって取得した障害（例えば、セッションＤのサービスＢで発生した障害ｅｉｄ１）に該当する障害関連性情報４０２２を（１）関連性対応表から検索する。
Ｓ１２では、障害関連性判定部４０１４は、Ｓ１１で検索した結果、該当する障害関連性情報があるかどうかを確認する。
つまり、Ｓ０１で障害状態を設定した障害の障害ＩＤ（ここでは障害ｅｉｄ１）が対象障害ＩＤとして示され、Ｓ０９の検索によって取得した障害の障害ＩＤ（ここでは障害ｅｉｄ１）が関連障害ＩＤとして示されるレコードが（１）関連性対応表に存在するかを確認する。
該当する障害関連性情報がある場合（Ｓ１２でＹＥＳ）はＳ１３に進む。
該当する障害関連性情報がない場合（Ｓ１２のＮＯ）はＳ１０に戻り、他セッションに該当する障害があるかどうかを確認する。
この場合、図４（１）の（イ）の３行目に示す業務名が一致していれば、Ｓ１２でＹＥＳとなる。

Ｓ１３では、障害関連性判定部４０１４は、障害関連性情報記憶部４０１５の（２）関連性判定条件表から該当する判定条件を取得し、評価式によって回復の判定を行う。
Ｓ１４では、障害関連性判定部４０１４は、Ｓ１３の判定結果より、関連性があるかどうかを確認する。
関連性がある場合（Ｓ１４のＹＥＳ）はＳ０１に戻り、関連すると判定された障害の障害状態を設定する（対処状況更新ステップ）。
関連性がない場合（Ｓ１４のＮＯ）は終了する。

Ｓ０９以降では、処置を実施した障害とは別のセッションに対して障害状態の設定を行うため、そのセッション内でも、発生した障害を取得し、関連性を判定する処理を繰り返す必要がある。
最初に障害状態を設定した障害（セッションＣで発生したサービスＢの障害ｅｉｄ１）と同じサービスで発生した障害（例えば、セッションＤで発生したサービスＢの障害ｅｉｄ１）と、その障害が発生したセッション（ここではセッションＤ）内で発生した他の障害に対して、関連性の判定が全て終わると処理が終了となる。

そして、障害状態が更新された最新の解析結果は、図１０に例示する画面により、図２のクライアントＩ／Ｆ部４０１３によって運用監視者に表示される。

以上のように、本実施の形態により、処置を実施した障害に対して、運用監視者が、クライアントＩ／Ｆ部を介して障害状態を手動で設定することにより、障害状態を設定された障害と関連して発生した障害が特定され、その障害の障害状態が自動的に設定される。
そのため運用監視者は、障害状態設定のたびに、障害の因果関係を判定し、全ての障害状態を手動で設定する必要がなくなる。
これにより、運用監視者の負荷軽減による作業時間の短縮の効果が期待できる。
クライアントＩ／Ｆ部においては、処置を必要としない障害（例えば、障害状態が回復済や処置不要）を非表示にすることにより、より効率的なサービスの運用管理が可能となる。
障害関連性情報を定義し、セッション毎に障害の関連性を判定することにより、親子などのサービス依存関係のみによる関連性の判定よりも、より正確な判定が可能となる。

以上、本実施の形態では、
ＥＳＢの実行ログを入力とし、実行ログから障害を検出して解析結果を出力する解析部と、解析部の解析結果を表示し、表示した障害情報に対して手動による障害状態の設定を行うインタフェースを提供するクライアントＩ／Ｆ部と、クライアントＩ／Ｆ部から設定された障害状態と解析結果、障害関連性情報を入力とし、障害の関連性を判定し、自動で障害状態を設定する障害関連性判定部を備えるサービス運用管理サーバ装置、サービス運用管理方法及びサービス運用管理プログラムを説明した。

最後に、本実施の形態に示したサービス運用管理サーバ装置４０１のハードウェア構成例について説明する。
図９は、本実施の形態に示すサービス運用管理サーバ装置４０１のハードウェア資源の一例を示す図である。
なお、図９の構成は、あくまでもサービス運用管理サーバ装置４０１のハードウェア構成の一例を示すものであり、サービス運用管理サーバ装置４０１のハードウェア構成は図９に記載の構成に限らず、他の構成であってもよい。

図９において、サービス運用管理サーバ装置４０１は、プログラムを実行するＣＰＵ９１１（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。
ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）９１３、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。
更に、ＣＰＵ９１１は、ＦＤＤ９０４（ＦｌｅｘｉｂｌｅＤｉｓｋＤｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７と接続していてもよい。また、磁気ディスク装置９２０の代わりに、ＳＳＤ（ＳｏｌｉｄＳｔａｔｅＤｒｉｖｅ）、光ディスク装置、メモリカード（登録商標）読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。
本実施の形態で説明した解析結果情報記憶部４０１２及び障害関連性情報記憶部４０１５は、例えば、ＲＡＭ９１４により実現される。
また、本実施の形態で説明した情報記憶装置４０２は、例えば、磁気ディスク装置９２０により実現される。
通信ボード９１５、キーボード９０２、マウス９０３、スキャナ装置９０７、ＦＤＤ９０４などは、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力装置の一例である。

通信ボード９１５は、例えば、ＬＡＮ（ローカルエリアネットワーク）、インターネット、ＷＡＮ（ワイドエリアネットワーク）、ＳＡＮ（ストレージエリアネットワーク）などに接続されている。

磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。
プログラム群９２３のプログラムは、ＣＰＵ９１１がオペレーティングシステム９２１、ウィンドウシステム９２２を利用しながら実行する。

また、ＲＡＭ９１４には、ＣＰＵ９１１に実行させるオペレーティングシステム９２１のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。
また、ＲＡＭ９１４には、ＣＰＵ９１１による処理に必要な各種データが格納される。

また、ＲＯＭ９１３には、ＢＩＯＳ（ＢａｓｉｃＩｎｐｕｔＯｕｔｐｕｔＳｙｓｔｅｍ）プログラムが格納され、磁気ディスク装置９２０にはブートプログラムが格納されている。
サービス運用管理サーバ装置４０１の起動時には、ＲＯＭ９１３のＢＩＯＳプログラム及び磁気ディスク装置９２０のブートプログラムが実行され、ＢＩＯＳプログラム及びブートプログラムによりオペレーティングシステム９２１が起動される。

上記プログラム群９２３には、本実施の形態の説明において「〜部」（「解析結果情報記憶部４０１２及び障害関連性情報記憶部４０１５」以外、以下同様）として説明している機能を実行するプログラムが記憶されている。
プログラムは、ＣＰＵ９１１により読み出され実行される。

ファイル群９２４には、本実施の形態の説明において、「〜の判断」、「〜の判定」、「〜の検索」、「〜の比較」、「〜の抽出」、「〜の更新」、「〜の設定」、「〜の選択」、「〜の入力」、「〜の受信」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。
「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。
ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出される。
そして、読み出された情報やデータや信号値や変数値やパラメータは、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。
抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、本実施の形態で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示す。
データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。
また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。

また、本実施の形態の説明において「〜部」として説明しているものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。
すなわち、本実施の形態で説明したフローチャートに示すステップ、手順、処理により、本発明に係る「情報処理方法」を実現することができる。
また、「〜部」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。
或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。
ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。
プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。
すなわち、プログラムは、本実施の形態の「〜部」としてコンピュータを機能させるものである。あるいは、本実施の形態の「〜部」の手順や方法をコンピュータに実行させるものである。

このように、本実施の形態に示すサービス運用管理サーバ装置４０１は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータである。
そして、上記したように「〜部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。

２０情報システム、４０運用管理装置、１０１業務用クライアント装置、２０１業務サーバ装置、２０２ＥＳＢサーバ装置、２０３ネットワーク、２０４サーバ装置Ａ、２０５サーバ装置Ｂ、３０１管理用クライアント装置、４０１サービス運用管理サーバ装置、４０２情報記憶装置、２０２１実行ログ、２０４１サービスＡ１、２０４２サービスＡ２、２０５１サービスＢ１、２０５２サービスＢ２、４０１１解析部、４０１２解析結果情報記憶部、４０１３クライアントＩ／Ｆ部、４０１４障害関連性判定部、４０１５障害関連性情報記憶部、４０２１障害定義情報、４０２２障害関連性情報。

Claims

管理対象システムで発生する障害に対して、障害発生原因において関連のある障害を関連障害として定義する関連障害情報を記憶する関連障害情報記憶部と、
前記管理対象システムで発生した障害と、発生した障害に対する対処状況とを示す対処状況情報を記憶する対処状況情報記憶部と、
対処状況が変化した障害を状況変化障害として示すとともに、前記状況変化障害の新たな対処状況を示す更新要求を入力する入力部と、
前記対処状況情報において前記状況変化障害の対処状況を前記更新要求に示される新たな対処状況に更新するとともに、前記関連障害情報において前記状況変化障害に関連障害が定義されている場合に、前記対処状況情報において当該関連障害の対処状況を前記更新要求に示される新たな対処状況に更新する対処状況更新部とを有することを特徴とする情報処理装置。
前記関連障害情報記憶部は、
関連障害の対処状況の更新を行うか否かの判定条件を関連性判定条件として定義する関連障害情報を記憶しており、
前記対処状況更新部は、
前記対処状況情報において前記状況変化障害の対処状況を前記更新要求に示される新たな対処状況に更新するとともに、前記状況変化障害の関連障害について関連性判定条件が成立するか否かを判定し、
関連性判定条件が成立する場合に、前記対処状況情報において当該関連障害の対処状況を前記更新要求に示される新たな対処状況に更新することを特徴とする請求項１に記載の情報処理装置。
前記対処状況情報記憶部は、
前記管理対象システムにおいて複数のデータ処理を対応付けて管理する単位であるセッションごとに、セッションにて発生した障害と、発生した障害に対する対処状況とを示す対処状況情報を記憶し、
前記入力部は、
前記状況変化障害と、前記状況変化障害の新たな対処状況とを示すとともに、前記状況変化障害が発生したセッションを更新対象セッションとして示す更新要求を入力し、
前記対処状況更新部は、
前記対処状況情報において前記更新対象セッションに対応する前記状況変化障害の対処状況を前記更新要求に示される新たな対処状況に更新するとともに、前記関連障害情報において前記状況変化障害の関連障害が定義されている場合に、前記対処状況情報において前記更新対象セッションに対応する当該関連障害の対処状況を前記更新要求に示される新たな対処状況に更新することを特徴とする請求項１又は２に記載の情報処理装置。
前記関連障害情報記憶部は、
関連障害の対処状況の更新を行うか否かの判定条件を関連性判定条件として定義する関連障害情報を記憶しており、
前記対処状況更新部は、
前記状況変化障害の関連障害について関連性判定条件が成立するか否かを判定し、
関連性判定条件が成立する場合に、前記対処状況情報において前記更新対象セッションに対応する当該関連障害の対処状況を前記更新要求に示される新たな対処状況に更新することを特徴とする請求項３に記載の情報処理装置。
前記対処状況更新部は、
前記更新対象セッション以外の他のセッションで発生したいずれかの障害が前記関連障害情報において前記状況変化障害の関連障害と定義されている場合に、前記対処状況情報において当該関連障害の対処状況を前記更新要求に示される新たな対処状況に更新することを特徴とする請求項３又は４に記載の情報処理装置。
前記対処状況更新部は、
前記更新対象セッション以外の他のセッションで発生した障害が前記関連障害情報において前記状況変化障害の関連障害と定義されており、当該関連障害に対する関連障害が前記関連障害情報において定義されている場合に、後者の関連障害の対処状況を前記更新要求に示される新たな対処状況に更新することを特徴とする請求項５に記載の情報処理装置。
前記関連障害情報記憶部は、
関連障害の対処状況の更新を行うか否かの判定条件を関連性判定条件として定義する関連障害情報を記憶しており、
前記対処状況更新部は、
関連障害について関連性判定条件が成立するか否かを判定し、
関連性判定条件が成立する場合に、前記対処状況情報において前記他のセッションで発生した関連障害の対処状況を前記更新要求に示される新たな対処状況に更新することを特徴とする請求項５又は６に記載の情報処理装置。
前記情報処理装置は、
サービスを提供するシステムを管理対象システムとしており、
前記関連障害情報記憶部は、
関連障害を、サービスと対応付けて定義する関連障害情報を記憶し、
前記対処状況情報記憶部は、
前記管理対象システムで発生した障害を、障害が発生した際に実行中であったサービスと対応付けて管理する対処状況情報を記憶し、
前記対処状況更新部は、
前記関連障害情報において前記状況変化障害の関連障害が定義されている場合に、当該関連障害が発生した際に実行中であったサービスが前記関連障害情報において当該関連障害に対応付けられているサービスと一致するか否かを前記対処状況情報に基づいて判定し、
両サービスが一致する場合に、前記対処状況情報において当該関連障害の対処状況を前記更新要求に示される新たな対処状況に更新することを特徴とする請求項１〜７のいずれかに記載の情報処理装置。
前記情報処理装置は、
業務を支援するサービスを提供するシステムを管理対象システムとしており、
前記関連障害情報記憶部は、
関連障害を、業務と対応付けて定義する関連障害情報を記憶し、
前記対処状況情報記憶部は、
前記管理対象システムで発生した障害を、障害が発生した際に実行中であったサービスが対象とする業務と対応付けて管理する対処状況情報を記憶し、
前記対処状況更新部は、
前記関連障害情報において前記状況変化障害の関連障害が定義されている場合に、当該関連障害が発生した際に実行中であったサービスが対象とする業務が前記関連障害情報において当該関連障害に対応付けられている業務と一致するか否かを前記対処状況情報に基づいて判定し、
両業務が一致する場合に、前記対処状況情報において当該関連障害の対処状況を前記更新要求に示される新たな対処状況に更新することを特徴とする請求項１〜８のいずれかに記載の情報処理装置。
前記情報処理装置は、
ＳＯＡ（ＳｅｒｖｉｃｅＯｒｉｅｎｔｅｄＡｒｃｈｉｔｅｃｔｕｒｅ）技術により構築されたシステムを管理対象システムとすることを特徴とする請求項８又は９に記載の情報処理装置。
前記情報処理装置は、
所定の端末装置に接続されており、
前記情報処理装置は、更に、
前記対処状況更新部により更新された後の対処状況を障害の名称とともに前記端末装置に出力する出力部を有することを特徴とする請求項１〜１０のいずれかに記載の情報処理装置。
管理対象システムで発生した障害と、発生した障害に対する対処状況とを示す対処状況情報を管理するコンピュータが行う情報処理方法であって、
前記管理対象システムで発生する障害に対して、障害発生原因において関連のある障害を関連障害として定義する関連障害情報を、前記コンピュータが所定の記憶領域から読み出す関連障害情報読み出しステップと、
前記コンピュータが、対処状況が変化した障害を状況変化障害として示すとともに、前記状況変化障害の新たな対処状況を示す更新要求を入力する入力ステップと、
前記コンピュータが、前記対処状況情報において前記状況変化障害の対処状況を前記更新要求に示される新たな対処状況に更新するとともに、前記関連障害情報において前記状況変化障害に関連障害が定義されている場合に、前記対処状況情報において当該関連障害の対処状況を前記更新要求に示される新たな対処状況に更新する対処状況更新ステップとを有することを特徴とする情報処理方法。
管理対象システムで発生した障害と、発生した障害に対する対処状況とを示す対処状況情報を管理するコンピュータに、
前記管理対象システムで発生する障害に対して、障害発生原因において関連のある障害を関連障害として定義する関連障害情報を、所定の記憶領域から読み出す関連障害情報読み出しステップと、
対処状況が変化した障害を状況変化障害として示すとともに、前記状況変化障害の新たな対処状況を示す更新要求を入力する入力ステップと、
前記対処状況情報において前記状況変化障害の対処状況を前記更新要求に示される新たな対処状況に更新するとともに、前記関連障害情報において前記状況変化障害に関連障害が定義されている場合に、前記対処状況情報において当該関連障害の対処状況を前記更新要求に示される新たな対処状況に更新する対処状況更新ステップとを実行させることを特徴とするプログラム。