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

Abstract

【課題】ＳＯＡを用いるシステムにおいて、サービスに障害が発生した際に影響を受ける業務を判定する。
【解決手段】構成情報２０２及び判断知識２０３に、業務において実行されるサービスの実行条件が示され、サービス運用管理サーバ装置２０１は、ＥＳＢサーバ装置１０３からサービス実行状況を示す実行ログ１０３１を入力し、実行ログ１０３１の解析の結果、サービスに障害が発生したと判断した場合に、障害発生時の状況が障害発生サービスの実行条件に合致するか否かを業務ごとに判断し、実行条件に合致しない業務についてはサービスが実行されていた可能性がないので障害の影響がないと判定でき、実行条件に合致する業務についてはサービスが実行されていた可能性があるので障害の影響があると判定することができ、障害による業務への影響を正確に判定することができる。
【選択図】図１

Description

本発明は、データ処理サービスに障害が発生した場合に、障害の影響度を判定する技術に関する。

近年、ビジネスプロセス管理などの考えに基づき、アプリケーションやソフトウェアが提供する機能をビジネスプロセスの構成単位に合わせた形で整理し、これらをデータ処理サービス（以下、単にサービスともいう）という形でネットワークを介して標準化された手順により呼び出すことで、システムを構築する手法、すなわち、サービス指向アーキテクチャ（ＳＯＡ：Ｓｅｒｖｉｃｅ Ｏｒｉｅｎｔｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）が注目を集めている。
ＳＯＡによるシステム構築では、必要なサービスを組み合わせて、システムを構築し、そのシステム上で業務を実行する。
業務に必要なサービスは、他社から提供されることもある。
また、ＳＯＡシステムを実現するためのミドルウェア製品としてＥＳＢ（Ｅｎｔｅｒｐｒｉｓｅ Ｓｅｒｖｉｃｅ Ｂｕｓ）と呼ばれるものがある。
ＥＳＢは、要求元からのサービス要求を受け付け、該当サービスへ要求を割り振り、その結果を要求元に返すＳＯＡの基盤を提供するものである。
前述のように、ＳＯＡでは、これまでのように自社のみで情報システムを構築するのではなく、他社の提供するサービスを利用して、情報システムを組み上げることがある（特許文献１）。
他社のサービスを利用したり、ＥＳＢなどのミドルウェアの機能により、サービスを振り分けたりするため、従来以上に、障害が発生したときに、どこで障害が発生したか、その障害はどの程度か、業務への影響範囲はどの程度なのかなどを特定することが難しい。

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

前述したように、ＳＯＡを用いて構築されたシステムでは、障害が発生したときに、どこで障害が発生したか、その障害はどの程度か、業務への影響範囲はどの程度なのかなどを特定することが難しいという課題がある。
障害が発生したことは、従来の技術でも検知することはできる。例えば、社外のサービスで障害が発生した場合でも、ＥＳＢなどのサービスを集約している基盤機能のログの内容などにより、どのサービスで障害が発生したかを知ることができる。
しかし、そのサービスで障害が発生したことにより、実際の業務ではどこまで障害の影響があるかを判断することができないという課題がある。

具体的な例で説明する。
例えば、ＳＯＡを用いたシステムにて、図３のような業務フローで表される業務Ｘ１があるとする。
業務Ｘ１はサービスａ、ｂ、ｃからなっており、この順番で呼び出される。
実際には、それぞれのサービスがＥＳＢサーバ装置を通して、ネットワーク外にあるサーバ装置で動作しており、各サービスを呼び出すことにより、業務Ｘ１が成り立っている。
業務Ｘ１においてサービスａを呼び出すとき、業務Ｘ１を実施する業務クライアント装置又は業務サーバ装置はサービスａがどこにあるか（例えば、サービスａはサーバ装置Ａで動作する）は知らなくてもよい。
業務Ｘ１を実施する業務クライアント装置又は業務サーバ装置はＥＳＢサーバ装置に対して、サービスａを呼び出すだけである。
ＥＳＢサーバ装置は、ＳＯＡシステム構築の基盤となる機能を提供しており、ＥＳＢサーバ装置は、各サービスがどこにあるかを管理している。
ＥＳＢサーバ装置は、業務Ｘ１からサービスａを要求されたときに、その要求を受け付け、サービスａはサーバ装置Ａで動作していることを知っているので、サーバ装置Ａを呼び出す。
サーバ装置Ａ上で実際のサービスａが実行され、その結果が、ＥＳＢサーバ装置を通して、業務クライアント装置又は業務サーバ装置に返ってくる。
以上が通常のＳＯＡシステムでの動作である。
一般にこれらを管理するには、図４に示すような「業務Ｘ１はサービスａ、ｂ、ｃからなる」という業務サービス関連表を、構成管理ＤＢにもつ。

ここで障害が発生した場合を考える。
例えば、サービスｂで障害が発生した場合、「業務とサービスの関連」からサービスｂを利用している業務Ｘ１に障害の影響があることがわかる。
従来はこのようにして、障害の影響を判断していた。
しかし、図５のような業務Ｘ２を考えた場合、サービスｂに障害があっても、サービスｄが正常に動作していれば、必ずしも、業務Ｘ２へ影響があるとは限らない。
また、影響があっても小さいものかもしれない。
従来は、このような場合を含めて、業務への影響の有無を正確に判断することができないという課題がある。

本発明は、上記のような課題を解決することを主な目的の一つとし、データ処理サービスに障害が発生したときの業務への影響の有無を正確に特定することを主な目的とする。

本発明に係る情報処理装置は、
業務において実行されるデータ処理サービスが示されるとともに当該データ処理サービスの実行に要求される実行条件が示される条件情報を記憶する情報記憶装置に接続され、
実行時に障害が発生したデータ処理サービスを障害発生データ処理サービスとして検出する障害検出部と、
前記障害検出部により前記障害発生データ処理サービスが検出された際に前記情報記憶装置から前記条件情報を読み出し、障害発生時の状況が前記条件情報に示される前記障害発生データ処理サービスの実行条件に合致しているか否かを業務ごとに判断し、実行条件に合致している業務は前記障害発生データ処理サービスの障害の影響を受けると判定し、実行条件に合致していない業務は前記障害発生データ処理サービスの障害の影響を受けないと判定する障害影響度判定部を有することを特徴とする。

本発明によれば、データ処理サービスに障害が発生した場合に、障害発生時の状況が障害データ処理サービスの実行条件に合致するか否かを業務ごとに判断し、実行条件に合致しない業務については障害発生サービスが実行されていた可能性がないので障害の影響がないと判定でき、実行条件に合致する業務については障害発生サービスが実行されていた可能性があるので障害の影響があると判定することができ、障害による業務への影響を正確に判定することができる。

実施の形態１に係るシステム構成例を示す図。 実施の形態１に係るサービス運用管理サーバ装置の構成例を示す図。 業務Ｘ１の構成を示す図。 従来の業務サービス関連表の例を示す図。 業務Ｘ２の構成を示す図。 実施の形態１に係る業務サービス影響度対応表及び業務影響度表の例を示す図。 実施の形態１に係るノードサービス表の例を示す図。 実施の形態１に係るプロセスフロー表の例を示す図。 業務Ｘ１及び業務Ｘ２の構成を示す図。 実施の形態１に係る業務判断知識対応表及び判断知識表の例を示す図。 実施の形態１に係るサービス運用管理サーバ装置の動作例を示すフローチャート図。 実施の形態１に係るサービス運用管理サーバ装置の動作例を示すフローチャート図。 業務Ｘ２の条件式を示す図。 実施の形態２に係るサービス運用管理サーバ装置の構成例を示す図。 実施の形態２に係るサービス運用管理サーバ装置の構成例を示す図。 実施の形態１に係る業務判断知識対応表及び判断知識表の例を示す図。 実施の形態１に係るサービス運用管理サーバ装置の動作例を示すフローチャート図。 実施の形態１〜３に係るサービス運用管理サーバ装置のハードウェア構成例を示す図。

実施の形態１．
図１は、本実施の形態に係るシステム構成例を示す。
図１において、情報システム１０はＳＯＡで構築された情報システムである。
情報システム１０は、業務に用いられるクライアント装置やサーバ装置で構成される。
運用管理装置２０は、サービス運用管理サーバ装置２０１及び情報記憶装置２０４で構成される。
サービス運用管理サーバ装置２０１は、情報処理装置の例である。
管理用クライアント装置３０１は、システム運用管理者が運用管理のために用いるクライアント装置である。

情報システム１０において、業務クライアント装置１０１は、業務を実行するシステム利用者が利用するクライアント装置である。
業務サーバ装置１０２は、業務クライアント装置１０１から要求を受け付け、各業務のビジネスプロセスに従い、ＥＳＢサーバ装置１０３に対してサービスの呼び出しを行い、業務を実行するサーバ装置である。
ＥＳＢサーバ装置１０３は、業務サーバ装置１０２からの要求を受け付け、適切なサービスを呼び出す機能を搭載したサーバ装置である。ＥＳＢサーバ装置１０３は、サービス実行管理装置の例である。
実行ログ１０３１は、ＥＳＢサーバ装置１０３上で記録されるサービスに関連する実行ログである。
実行ログ１０３１には、どの業務サーバ装置がどのサービスを呼び出し、呼び出したサービスが正常に値を返したか、異常があったか、などが記録されている。
ネットワーク１０４は、各サーバ装置が接続されるインターネットやイントラネットなどのネットワークである。
サーバ装置Ａ１０５やサーバ装置Ｂ１０６は、自社または他社にあるサービスを提供しているサーバ装置である。
サービスａ（１０５１）、サービスａ２（１０５２）、サービスｂ（１０６１）、サービスｂ２（１０６２）はデータ処理サービスの実体である。各サービスは、ＥＳＢサーバ装置１０３を介して業務サーバ装置１０２から利用可能となるようインターフェイスを公開しているソフトウェアである。

運用管理装置２０において、サービス運用管理サーバ装置２０１は、実行ログ１０３１を受け取り、その内容を解析し、情報記憶装置２０４内の構成情報２０２や判断知識２０３を利用して、障害発生時に、どの業務にどの程度の影響があったかを判断する。

情報記憶装置２０４は、構成情報２０２及び判断知識２０３を記憶している。

構成情報２０２は、業務サーバ装置１０２がもつ業務情報や、サーバ装置Ａ、Ｂがもつサービス情報などの情報である。
構成情報２０２は、例えば、図６、図７、図８に示される情報であり、業務ごとに、業務に含まれる複数の業務プロセスの構成と、業務プロセスで実行されるサービス（データ処理サービス）が示される。
また、構成情報２０２には、業務と、障害が当該業務に影響を与えるサービスとの組み合わせや、業務と、障害が当該業務に影響を与える可能性のあるサービスとの組み合わせが定義されている。
構成情報２０２は、業務構成情報及び影響業務情報の例である。
なお、図６、図７、図８の詳細は後述する。

判断知識２０３は障害発生時にどの業務に本当に影響があるかを判断するための情報である。
判断知識２０３は、例えば、図１０に示される情報であり、業務において実行されるサービスが示されるとともに当該サービスの実行に要求される実行条件が示されている。
サービス運用管理サーバ装置２０１は、いずれかのサービスに障害が発生した場合に、判断知識２０３を参照し、障害発生時の状況が障害が発生したサービス（以下、障害発生サービスともいう）の実行条件に合致するか否かを判断して、業務に対する影響の可能性を判断する。
判断知識２０３は条件情報の例である。
なお、図１０の詳細は後述する。

本実施の形態では、このように、構成情報２０２及び判断知識２０３に、業務において実行されるサービスの実行条件が示されている。
そして、サービス運用管理サーバ装置２０１は、ＥＳＢサーバ装置１０３からサービス実行状況を示す実行ログ１０３１を入力し、実行ログ１０３１の解析の結果、サービスに障害が発生したと判断した場合に、障害発生時の状況が障害発生サービスの実行条件に合致するか否かを業務ごとに判断する。
実行条件に合致しない業務についてはサービスが実行されていた可能性がないので障害の影響がないと判定でき、実行条件に合致する業務についてはサービスが実行されていた可能性があるので障害の影響があると判定することができる。

図２は、本実施の形態に係るサービス運用管理サーバ装置２０１の詳細な構成例を示す図である。

解析部２０１１は、実行ログ１０３１を受け取り、ログを解析し、実行時に障害が発生したサービスを障害発生サービス（障害発生データ処理サービス）として検出する。
解析部２０１１は、障害検出部の例である。

障害影響度判定部２０１２は、解析部２０１１から渡されるデータと、構成情報２０２及び判断知識２０３を元に、障害の影響度を判定する。
つまり、障害影響度判定部２０１２は、解析部２０１１により障害発生サービスが検出された際に情報記憶装置２０４から構成情報２０２及び判断知識２０３を読み出し、構成情報２０２に障害発生サービスに対して障害の影響を受ける可能性のある業務が定義されているか否かを判断する。
障害の影響を受ける可能性のある業務が定義されている場合は、当該業務に対して、障害発生時の状況が判断知識２０３に示される障害発生サービスの実行条件に合致しているか否かを判断する。
そして、障害影響度判定部２０１２は、実行条件に合致している業務は障害発生サービスの障害の影響を受けると判定し、実行条件に合致していない業務は障害発生サービスの障害の影響を受けないと判定する。
なお、構成情報２０２に障害発生サービスに対して障害の影響を受ける業務が定義されている場合は、当該業務に対しては、判断知識２０３を用いた判断を行うことなく、当該業務は障害発生サービスの障害の影響を受けると判定する。

障害影響箇所表示部２０１３は、解析部２０１１のデータと障害影響度判定部２０１２の結果を元に、障害の影響範囲を表示する。

次に、構成情報２０２及び判断知識２０３の詳細を説明する。

構成情報２０２は、図６〜図８に示す構造のデータを持っている。
なお、図６〜図８において、「（ア）項目の説明」は、各データの項目名及び各項目の内容を説明しており、「（イ）データの例」は、実際のデータの内容例を示している。

図６の（１）業務サービス影響度対応表は、業務名、サービス名、影響度ＩＤからなり、各業務がどのサービスを利用しているか、また、障害が発生した場合にどの影響度ＩＤに関連するかを示すものである。
図６の（２）業務影響度表は、影響度ＩＤ、影響度レベル、影響度名からなり、影響度ＩＤで示される影響度のレベルを表すものである。図６の例では、影響度としては、「影響あり」、「可能性あり」、「影響なし」の３種類となっている。
図７の（３）のノードサービス表は、業務名、ノード名、タイプ、サービス名からなり、各業務がどのような業務フローとなるかの構成要素を表しており、図８の（４）プロセスフロー表で利用される。
図８の（４）プロセスフロー表は、業務名、ノード名、ノード元からなり、各業務がどの順番でサービスを呼び出すか、そのフローを表すものである。
図９に（３）ノードサービス表と（４）プロセスフロー表を用いた業務フローの例を示す。
図９（ａ）は業務Ｘ１の業務フローを示し、図９（ｂ）は業務Ｘ２の業務フローを示す。
なお、各業務フローにおいて、１〜５（図９（ａ））及び１〜７（図９（ｂ））は、図７の（３）ノードサービス表に示す各ノードである。

判断知識２０３は、図１０に示す構造のデータを持っている。
（１）業務判断知識対応表は、業務名、サービス名、判断知識ＩＤからなり、障害が発生したサービスと、それに関連する業務において、障害の影響があるかどうか、つまり、そのサービスが利用されているかどうかを判断知識ＩＤから判断する。なお、（１）業務判断知識対応表に記述されている業務とサービスの組は、図６の（２）業務影響度表において影響度が「可能性あり」とされている業務とサービスの組である。
（２）判断知識表は、判断知識ＩＤ、評価項目、条件、評価値、利用からなり、判断知識ＩＤで示される判断知識が、（１）業務判断知識対応表の判断知識ＩＤに対応する。
ここで示すように、判断知識の一つは日時情報である。
図１０の例では、ｃｉｄ１は、障害発生日の日付が２５日以降であれば、障害発生サービスは業務に影響しないことを示している。ｃｉｄ２は、障害発生日の日付が２５日よりも前であれば、障害発生サービスは業務に影響しないことを示している。ｃｉｄ３は、障害発生日の日付が２５日よりも前であれば、障害発生サービスが業務に影響することを示している。

ここで、構成情報２０２のデータ（業務サービス影響度対応表（図６（１））や業務影響度表（図６（２））は、システム管理者などの人間が登録・更新等を行う。
すなわち、新規の業務が登場した場合、業務フローを定義し、業務サーバ装置１０２に登録することになるが、これと同時に、情報記憶装置２０４にも情報を登録する。
また、判断知識２０３についても同様に人間がデータを生成・管理し、また、情報記憶装置２０４に登録する。
構成情報２０２、判断知識２０３のデータを管理するのが、図１４で示すサービス運用管理サーバ装置２０１にある構成情報・判断知識管理部２０１４である。

次に図１１及び図１２のフローチャートを用いて、動作について説明する。
実行ログ１０３１は、リアルタイムに、解析部２０１１に出力され、解析部２０１１は実行ログを入力する（Ｓ０１）。
解析部２０１１が実行ログ１０３１を解析した結果、障害が発生したサービスを検出した場合（Ｓ０２でＹＥＳ）（障害検出ステップ）、解析部２０１１は、障害影響度判定部２０１２に障害発生サービスを通知する。
実行ログ１０３１には、どのサービスでエラーが発生したかが記録されている。
以降では、サービスｂで障害が発生した場合を想定して説明を進める。

解析部２０１１から障害発生サービスの通知を受けた障害影響度判定部２０１２は、情報記憶装置２０４から構成情報２０２を読み出す（Ｓ０３）。
そして、障害影響度判定部２０１２は、業務サービス影響度対応表（図６（１））を元に、サービスｂが関連するレコードを検索し、そこから業務名を抽出する（Ｓ０４、Ｓ０５）。
この段階で、障害の影響の可能性がある業務が抽出される。
この例では、業務Ｘ１と業務Ｘ２が抽出される。
Ｓ０５においてレコードが抽出されなかった場合は、障害影響度判定部２０１２は、この障害で影響のある業務はないと判定する（Ｓ０６）。
次に、障害影響度判定部２０１２は、本当に影響がどの程度あるかを判断する。
障害影響度判定部２０１２は、障害が発生したサービスと業務を元に、業務影響度表（図６（１））から、影響度を判断する（Ｓ０７、Ｓ０８）。
この例では、サービスｂで障害が発生した場合、業務Ｘ１は影響度レベルが１であるので、「影響あり」となり、障害影響度判定部２０１２は、サービスｂの障害により業務Ｘ１に影響が及ぶと判断する（Ｓ０９）。
また、業務Ｘ２は影響度レベルが２であるので、「可能性あり」となり、次のステップへ進む。
なお、影響度レベルが３の場合は、発生した障害は業務に影響を与えないと判定する（Ｓ１０）。

Ｓ０８において影響度レベルが２であった場合は、障害影響度判定部２０１２は、情報記憶装置２０４から判断知識２０３を読みだす（Ｓ１１）（情報読み出しステップ）。
次に、障害影響度判定部２０１２は、読み出した判断知識２０３を参照する。
具体的には、障害影響度判定部２０１２は、業務判断知識対応表（図１０（１））を元に、業務名とサービス名で検索を行う（Ｓ１２、Ｓ１３）（障害影響度判定ステップ）。
該当するレコードがない場合は、障害影響度判定部２０１２は、業務への影響の可能性があると判断する（Ｓ１４）。
該当するレコードがあれば、障害影響度判定部２０１２は、その判断知識ＩＤを元に、判断知識表（図１０（２））を検索し、評価項目にある値を取得し、条件を評価する（Ｓ１５、Ｓ１６）（障害影響度判定ステップ）。
評価した結果として、利用がない（値が０）の場合は、障害が発生したサービスは利用していない可能性が高いので、障害影響度判定部２０１２は、業務への影響はないと判断する（Ｓ１８）（障害影響度判定ステップ）。
逆に利用があれば、障害影響度判定部２０１２は、業務への影響があると判断する（Ｓ１７）（障害影響度判定ステップ）。
この例では、業務Ｘ２、サービス名ｂのレコードとして、判断知識ＩＤがｃｉｄ１と一致し、判断知識表（図１０（２））により、障害発生日が２５日以降であれば、サービスｂは業務Ｘ２において利用されていないということになる。
例えば、障害が発生した日が、１１月２７日であれば、図１２のＳ１５の処理にて、２７日の「２７」が取得される。
この値が実行条件の「２５」以上なので、サービスｂは業務Ｘ２では利用されていないことになり、障害の影響はないと判断できる。
図１３は、この例に適用したときの業務フローのイメージ図である。
つまり、業務Ｘ２は、サービスａの実行後に、条件式により、１日〜２４日の間はサービスｂが実行されるが、２５日以降はサービスｄが実行されるという業務フローを持つ。

このように、本実施の形態により、障害が発生した場合に、その障害により、どの業務に影響があるかを判断することができる。
つまり、サービスに障害が発生した場合に、障害発生時の状況がサービスの実行条件に合致するか否かを業務ごとに判断し、実行条件に合致しない業務についてはサービスが実行されていた可能性がないので障害の影響がないと判定でき、実行条件に合致する業務についてはサービスが実行されていた可能性があるので障害の影響があると判定することができ、障害による業務への影響を正確に判定することができる。
また、業務に影響を与えるタイミングを判断できるので、すぐに影響はないが、そのうち影響があるなどもわかるので、障害に対応する優先順位や場合によっては期限などを知ることもできる。
このように、システム運用管理者は、影響範囲を把握することができるので、業務の利用者へ障害の通知を行う、障害対応の優先順位を決めるといった処理が可能になる。

なお、上記の業務サービス影響度対応表（図６（１））、業務影響度表（図６（２））、業務判断知識対応表（図１０（１））、判断知識表（図１０（２））を統合して、図１６の（１）業務判断知識対応表、（２）判断知識表のようにしてもよい。
図１６の（１）業務判断知識対応表は、図６の（１）業務サービス影響度対応表の業務名とサービス名と、図１０の（１）業務判断知識対応表を組み合わせたものである。
つまり、図１６の（１）業務判断知識対応表は、全業務について、業務ごとに実行されるサービス名が示されるとともに、業務とサービスの組に対して判断知識ＩＤが設定されている。
図１６の（２）判断知識表は、図６の（２）判断知識表と同じ構成であるが、内容が異なる。
図１６の（２）判断知識表では、図１６の（１）業務判断知識対応表に示されている全ての業務とサービスの組に対応する実行条件が示されている。
より具体的には、ｃｉｄ１〜ｃｉｄ３は、図６のものと同様であるが、ｃｉｄ４は常に影響あり（毎月１日〜末日まで業務においてサービスが実行されている）という実行条件を示す。
例えば、図６の例では、業務名：Ｘ１とサービス名：ａの組は、常に「影響度あり」（ｅｉｄ１）と判定されるが、図１６の例でも、業務名：Ｘ１とサービス名：ａの組は、判断知識ＩＤとしてｃｉｄ４が設定されており、ｃｉｄ４は、前述のように、常に影響あり（毎月１日〜末日まで業務においてサービスが実行されている）と定義されている。
このように、業務サービス影響度対応表（図６（１））、業務影響度表（図６（２））、業務判断知識対応表（図１０（１））、判断知識表（図１０（２））を統合して、図１６の（１）業務判断知識対応表、（２）判断知識表のようにしても同様の取り扱いが可能である。

また、図１６の判断知識２０３を用いる場合は、サービス運用管理サーバ装置２０１の動作フローは、例えば、図１７のようになる。
つまり、図１１の場合と同様に、解析部２０１１が実行ログ１０３１を入力し（Ｓ０１）、障害が発生したサービスを検出した場合（Ｓ０２でＹＥＳ）は、障害影響度判定部２０１２は、情報記憶装置２０４から図１６に示す判断知識２０３を読み出し（Ｓ１１）、以降は、図１１及び図１２のＳ１２〜Ｓ１８を実行する。
このように、図１６の判断知識を用いた場合は、図１１のＳ４〜Ｓ８の処理を省略することができ、処理時間を短縮することができ、また、少ない計算機資源で処理を行うことができる。

以上、本実施の形態では、次の手段を備えている運用管理方式を説明した。
障害影響範囲を特定するために、障害が発生したサービスが特定されることがわかる実行ログなどの情報を解析し、どのサービスで障害が発生したかを解析する解析部（これにより、障害が発生したサービスの名前がわかる）
下記を有する障害影響度判定部
業務、サービス、障害の影響度などの構成を管理する構成情報
業務への影響を判断するための判断知識
障害による業務への影響を表示する障害影響箇所表示部。

実施の形態２．
実施の形態１では、構成情報２０２は、業務を設計した設計者や業務を熟知している者から業務の内容をヒアリングなどして、データを投入する。
実施の形態２では、ある程度自動的にデータを登録する。
本実施の形態は、図１４に示す構成情報・判断知識管理部２０１４（情報生成部）に関する。

各業務フロー（業務プロセス）は、図７の（３）ノードサービス表と図８の（４）プロセスフロー表によって表すことができる。
例えば、業務Ｘ１（図３）や業務Ｘ２（図５）は、図７の（３）ノードサービス表及び図８の（４）プロセスフロー表のデータ例に示すように格納することで、図９の業務Ｘ１，Ｘ２を再現することができる。
また、例えば、図８（４）（イ）のデータ例で、ある業務において、ノード元が同じでノード名が異なるもの（この例では業務Ｘ２において、ノード元３が２つあり、それぞれ、ノード名は４と５である）がある場合には、業務フローが分岐や並列処理が発生していることがわかる。

したがって、業務を設計した設計者や業務を熟知している者から業務の内容をヒアリングなどして、図７の（３）ノードサービス表と図８の（４）プロセスフロー表を人間が登録する。
これにより、構成情報・判断知識管理部２０１４は、これらの情報から、図６の（１）業務サービス影響度対応表の業務名とサービス名を投入することができる。
また影響度ＩＤについては、分岐や並列がある部分で影響度レベルが１以外になる可能性があるので、その部分以外は、影響度レベルを１として自動で設定することができる。
これにより、構成情報への登録作業を効率的に実施することができる。

本実施の形態では、障害影響度判定部が、業務フローを再現するために、業務フローの各ノードとそのノードの元となる情報、及び、各ノードのタイプと呼び出されるサービスを管理する構成情報を有していることを説明した。

実施の形態３．
前述の通り、ＳＯＡなどにより構築されるシステムでは、業務フローはＢＰＥＬ（Ｂｕｓｉｎｅｓｓ Ｐｒｏｃｅｓｓ Ｅｘｅｃｕｔｉｏｎ Ｌａｎｇｕａｇｅ）などの標準的な記述様式で記述されることが一般的である。
ＢＰＥＬは、業務フローを記述するものである。
図１５に示すように、一般にＢＰＥＬは業務サーバ装置１０２上の定義ファイル（図番号１０２１）の記述に用いられる。
したがって、ＢＰＥＬで記述された業務フローを元に構成情報・判断知識管理部２０１４にて、自動的に、構成情報２０２のノードサービス表（３）とプロセスフロー表（４）を作成することができる。

これにより、実施の形態２に示す構成よりも構成情報への登録作業を効率的に行うことができ、また、業務フローから自動で登録されるので、登録の間違いなどを減らすことができる。

本実施の形態では、障害影響度判定部が、ＢＰＥＬ等の標準的な業務フロー情報を元に、自動的に、業務フローの各ノードとそのノードの元となる情報、及び、各ノードのタイプと呼び出されるサービスを登録する手段を有すること、また、その情報を管理する構成情報を有していることを説明した。

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

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

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

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

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

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

上記プログラム群９２３には、実施の形態１〜３の説明において「〜部」として説明している機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。

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

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

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

１０ 情報システム、２０ 運用管理装置、１０１ 業務クライアント装置、１０２ 業務サーバ装置、１０３ ＥＳＢサーバ装置、１０５ サーバ装置Ａ、１０６ サーバ装置Ｂ、２０１ サービス運用管理サーバ装置、２０２ 構成情報、２０３ 判断知識、２０４ 情報記憶装置、３０１ 管理用クライアント装置、１０３１ 実行ログ、２０１１ 解析部、２０１２ 障害影響度判定部、２０１３ 障害影響箇所表示部、２０１４ 構成情報・判断知識管理部。

Claims (9)

1. 業務において実行されるデータ処理サービスが示されるとともに当該データ処理サービスの実行に要求される実行条件が示される条件情報を記憶する情報記憶装置に接続され、
   実行時に障害が発生したデータ処理サービスを障害発生データ処理サービスとして検出する障害検出部と、
   前記障害検出部により前記障害発生データ処理サービスが検出された際に前記情報記憶装置から前記条件情報を読み出し、障害発生時の状況が前記条件情報に示される前記障害発生データ処理サービスの実行条件に合致しているか否かを業務ごとに判断し、実行条件に合致している業務は前記障害発生データ処理サービスの障害の影響を受けると判定し、実行条件に合致していない業務は前記障害発生データ処理サービスの障害の影響を受けないと判定する障害影響度判定部を有することを特徴とする情報処理装置。
2. 前記情報処理装置は、
   業務と、障害が当該業務に影響を与える可能性のあるデータ処理サービスとの組み合わせが定義されている影響業務情報と、
   前記影響業務情報において定義されている業務に対して、当該業務と組になっているデータ処理サービスの実行条件が示される条件情報を記憶している情報記憶装置と接続されており、
   前記障害影響度判定部は、
   前記障害検出部により前記障害発生データ処理サービスが検出された際に前記情報記憶装置から前記影響業務情報を読み出し、前記障害発生データ処理サービスに対して障害の影響を受ける可能性のある業務が定義されている場合に、当該業務に対して、障害発生時の状況が前記条件情報に示される前記障害発生データ処理サービスの実行条件に合致しているか否かを判断することを特徴とする請求項１に記載の情報処理装置。
3. 前記情報処理装置は、
   業務と、障害が当該業務に影響を与えるデータ処理サービスとの組み合わせが定義されている影響業務情報を記憶している情報記憶装置と接続されており、
   前記障害影響度判定部は、
   前記障害検出部により前記障害発生データ処理サービスが検出された際に前記情報記憶装置から前記影響業務情報を読み出し、前記障害発生データ処理サービスに対して障害の影響を受ける業務が定義されている場合に、当該業務に対して前記条件情報を用いた判断を行うことなく、当該業務は前記障害発生データ処理サービスの障害の影響を受けると判定することを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記情報処理装置は、更に、
   業務ごとに、業務に含まれる複数の業務プロセスの構成と、業務プロセスで実行されるデータ処理サービスが示される業務構成情報に基づいて、前記影響業務情報を生成する情報生成部を有することを特徴とする請求項２又は３に記載の情報処理装置。
5. 前記情報生成部は、
   所定の記述形式に従って業務フローが記述されている業務フロー情報を入力し、入力した業務フロー情報を解析して、前記業務構成情報を生成することを特徴とする請求項４に記載の情報処理装置。
6. 前記障害検出部は、
   データ処理サービスの実行を管理するサービス実行管理装置からデータ処理サービスの実行状況を示すログデータを入力し、入力したログデータを解析して、いずれかのデータ処理サービスにおける障害の発生を検出することを特徴とする請求項１〜５のいずれかに記載の情報処理装置。
7. 前記情報処理装置は、
   実行条件として、業務におけるデータ処理サービスの実行タイミングが示されている条件情報を記憶している情報記憶装置に接続されており、
   前記障害影響度判定部は、
   障害発生時刻が前記条件情報に示されている前記障害発生データ処理サービスの実行タイミングに合致しているか否かを業務ごとに判断し、実行タイミングに合致している業務は前記障害発生データ処理サービスの障害の影響を受けると判定し、実行タイミングに合致していない業務は前記障害発生データ処理サービスの障害の影響を受けないと判定することを特徴とする請求項１〜６のいずれかに記載の情報処理装置。
8. 業務において実行されるデータ処理サービスが示されるとともに当該データ処理サービスの実行に要求される実行条件が示される条件情報を記憶する情報記憶装置に接続されているコンピュータによる情報処理方法であって、
   前記コンピュータが、実行時に障害が発生したデータ処理サービスを障害発生データ処理サービスとして検出する障害検出ステップと、
   前記障害検出ステップにより前記障害発生データ処理サービスが検出された際に、前記コンピュータが前記情報記憶装置から前記条件情報を読み出す情報読み出しステップと、
   前記コンピュータが、障害発生時の状況が前記条件情報に示される前記障害発生データ処理サービスの実行条件に合致しているか否かを業務ごとに判断し、実行条件に合致している業務は前記障害発生データ処理サービスの障害の影響を受けると判定し、実行条件に合致していない業務は前記障害発生データ処理サービスの障害の影響を受けないと判定する障害影響度判定ステップを有することを特徴とする情報処理方法。
9. 業務において実行されるデータ処理サービスが示されるとともに当該データ処理サービスの実行に要求される実行条件が示される条件情報を記憶する情報記憶装置に接続されているコンピュータに、
   実行時に障害が発生したデータ処理サービスを障害発生データ処理サービスとして検出する障害検出処理と、
   前記障害検出処理により前記障害発生データ処理サービスが検出された際に前記情報記憶装置から前記条件情報を読み出す情報読み出し処理と、
   障害発生時の状況が前記条件情報に示される前記障害発生データ処理サービスの実行条件に合致しているか否かを業務ごとに判断し、実行条件に合致している業務は前記障害発生データ処理サービスの障害の影響を受けると判定し、実行条件に合致していない業務は前記障害発生データ処理サービスの障害の影響を受けないと判定する障害影響度判定処理を実行させることを特徴とするプログラム。

Images