JP2011141789A - 情報処理装置及び情報処理方法及びプログラム - Google Patents
情報処理装置及び情報処理方法及びプログラム Download PDFInfo
- Publication number
- JP2011141789A JP2011141789A JP2010002675A JP2010002675A JP2011141789A JP 2011141789 A JP2011141789 A JP 2011141789A JP 2010002675 A JP2010002675 A JP 2010002675A JP 2010002675 A JP2010002675 A JP 2010002675A JP 2011141789 A JP2011141789 A JP 2011141789A
- Authority
- JP
- Japan
- Prior art keywords
- failure
- business
- information
- data processing
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
Abstract
【課題】SOAを用いるシステムにおいて、サービスに障害が発生した際に影響を受ける業務を判定する。
【解決手段】構成情報202及び判断知識203に、業務において実行されるサービスの実行条件が示され、サービス運用管理サーバ装置201は、ESBサーバ装置103からサービス実行状況を示す実行ログ1031を入力し、実行ログ1031の解析の結果、サービスに障害が発生したと判断した場合に、障害発生時の状況が障害発生サービスの実行条件に合致するか否かを業務ごとに判断し、実行条件に合致しない業務についてはサービスが実行されていた可能性がないので障害の影響がないと判定でき、実行条件に合致する業務についてはサービスが実行されていた可能性があるので障害の影響があると判定することができ、障害による業務への影響を正確に判定することができる。
【選択図】図1
【解決手段】構成情報202及び判断知識203に、業務において実行されるサービスの実行条件が示され、サービス運用管理サーバ装置201は、ESBサーバ装置103からサービス実行状況を示す実行ログ1031を入力し、実行ログ1031の解析の結果、サービスに障害が発生したと判断した場合に、障害発生時の状況が障害発生サービスの実行条件に合致するか否かを業務ごとに判断し、実行条件に合致しない業務についてはサービスが実行されていた可能性がないので障害の影響がないと判定でき、実行条件に合致する業務についてはサービスが実行されていた可能性があるので障害の影響があると判定することができ、障害による業務への影響を正確に判定することができる。
【選択図】図1
Description
本発明は、データ処理サービスに障害が発生した場合に、障害の影響度を判定する技術に関する。
近年、ビジネスプロセス管理などの考えに基づき、アプリケーションやソフトウェアが提供する機能をビジネスプロセスの構成単位に合わせた形で整理し、これらをデータ処理サービス(以下、単にサービスともいう)という形でネットワークを介して標準化された手順により呼び出すことで、システムを構築する手法、すなわち、サービス指向アーキテクチャ(SOA:Service Oriented Architecture)が注目を集めている。
SOAによるシステム構築では、必要なサービスを組み合わせて、システムを構築し、そのシステム上で業務を実行する。
業務に必要なサービスは、他社から提供されることもある。
また、SOAシステムを実現するためのミドルウェア製品としてESB(Enterprise Service Bus)と呼ばれるものがある。
ESBは、要求元からのサービス要求を受け付け、該当サービスへ要求を割り振り、その結果を要求元に返すSOAの基盤を提供するものである。
前述のように、SOAでは、これまでのように自社のみで情報システムを構築するのではなく、他社の提供するサービスを利用して、情報システムを組み上げることがある(特許文献1)。
他社のサービスを利用したり、ESBなどのミドルウェアの機能により、サービスを振り分けたりするため、従来以上に、障害が発生したときに、どこで障害が発生したか、その障害はどの程度か、業務への影響範囲はどの程度なのかなどを特定することが難しい。
SOAによるシステム構築では、必要なサービスを組み合わせて、システムを構築し、そのシステム上で業務を実行する。
業務に必要なサービスは、他社から提供されることもある。
また、SOAシステムを実現するためのミドルウェア製品としてESB(Enterprise Service Bus)と呼ばれるものがある。
ESBは、要求元からのサービス要求を受け付け、該当サービスへ要求を割り振り、その結果を要求元に返すSOAの基盤を提供するものである。
前述のように、SOAでは、これまでのように自社のみで情報システムを構築するのではなく、他社の提供するサービスを利用して、情報システムを組み上げることがある(特許文献1)。
他社のサービスを利用したり、ESBなどのミドルウェアの機能により、サービスを振り分けたりするため、従来以上に、障害が発生したときに、どこで障害が発生したか、その障害はどの程度か、業務への影響範囲はどの程度なのかなどを特定することが難しい。
前述したように、SOAを用いて構築されたシステムでは、障害が発生したときに、どこで障害が発生したか、その障害はどの程度か、業務への影響範囲はどの程度なのかなどを特定することが難しいという課題がある。
障害が発生したことは、従来の技術でも検知することはできる。例えば、社外のサービスで障害が発生した場合でも、ESBなどのサービスを集約している基盤機能のログの内容などにより、どのサービスで障害が発生したかを知ることができる。
しかし、そのサービスで障害が発生したことにより、実際の業務ではどこまで障害の影響があるかを判断することができないという課題がある。
障害が発生したことは、従来の技術でも検知することはできる。例えば、社外のサービスで障害が発生した場合でも、ESBなどのサービスを集約している基盤機能のログの内容などにより、どのサービスで障害が発生したかを知ることができる。
しかし、そのサービスで障害が発生したことにより、実際の業務ではどこまで障害の影響があるかを判断することができないという課題がある。
具体的な例で説明する。
例えば、SOAを用いたシステムにて、図3のような業務フローで表される業務X1があるとする。
業務X1はサービスa、b、cからなっており、この順番で呼び出される。
実際には、それぞれのサービスがESBサーバ装置を通して、ネットワーク外にあるサーバ装置で動作しており、各サービスを呼び出すことにより、業務X1が成り立っている。
業務X1においてサービスaを呼び出すとき、業務X1を実施する業務クライアント装置又は業務サーバ装置はサービスaがどこにあるか(例えば、サービスaはサーバ装置Aで動作する)は知らなくてもよい。
業務X1を実施する業務クライアント装置又は業務サーバ装置はESBサーバ装置に対して、サービスaを呼び出すだけである。
ESBサーバ装置は、SOAシステム構築の基盤となる機能を提供しており、ESBサーバ装置は、各サービスがどこにあるかを管理している。
ESBサーバ装置は、業務X1からサービスaを要求されたときに、その要求を受け付け、サービスaはサーバ装置Aで動作していることを知っているので、サーバ装置Aを呼び出す。
サーバ装置A上で実際のサービスaが実行され、その結果が、ESBサーバ装置を通して、業務クライアント装置又は業務サーバ装置に返ってくる。
以上が通常のSOAシステムでの動作である。
一般にこれらを管理するには、図4に示すような「業務X1はサービスa、b、cからなる」という業務サービス関連表を、構成管理DBにもつ。
例えば、SOAを用いたシステムにて、図3のような業務フローで表される業務X1があるとする。
業務X1はサービスa、b、cからなっており、この順番で呼び出される。
実際には、それぞれのサービスがESBサーバ装置を通して、ネットワーク外にあるサーバ装置で動作しており、各サービスを呼び出すことにより、業務X1が成り立っている。
業務X1においてサービスaを呼び出すとき、業務X1を実施する業務クライアント装置又は業務サーバ装置はサービスaがどこにあるか(例えば、サービスaはサーバ装置Aで動作する)は知らなくてもよい。
業務X1を実施する業務クライアント装置又は業務サーバ装置はESBサーバ装置に対して、サービスaを呼び出すだけである。
ESBサーバ装置は、SOAシステム構築の基盤となる機能を提供しており、ESBサーバ装置は、各サービスがどこにあるかを管理している。
ESBサーバ装置は、業務X1からサービスaを要求されたときに、その要求を受け付け、サービスaはサーバ装置Aで動作していることを知っているので、サーバ装置Aを呼び出す。
サーバ装置A上で実際のサービスaが実行され、その結果が、ESBサーバ装置を通して、業務クライアント装置又は業務サーバ装置に返ってくる。
以上が通常のSOAシステムでの動作である。
一般にこれらを管理するには、図4に示すような「業務X1はサービスa、b、cからなる」という業務サービス関連表を、構成管理DBにもつ。
ここで障害が発生した場合を考える。
例えば、サービスbで障害が発生した場合、「業務とサービスの関連」からサービスbを利用している業務X1に障害の影響があることがわかる。
従来はこのようにして、障害の影響を判断していた。
しかし、図5のような業務X2を考えた場合、サービスbに障害があっても、サービスdが正常に動作していれば、必ずしも、業務X2へ影響があるとは限らない。
また、影響があっても小さいものかもしれない。
従来は、このような場合を含めて、業務への影響の有無を正確に判断することができないという課題がある。
例えば、サービスbで障害が発生した場合、「業務とサービスの関連」からサービスbを利用している業務X1に障害の影響があることがわかる。
従来はこのようにして、障害の影響を判断していた。
しかし、図5のような業務X2を考えた場合、サービスbに障害があっても、サービスdが正常に動作していれば、必ずしも、業務X2へ影響があるとは限らない。
また、影響があっても小さいものかもしれない。
従来は、このような場合を含めて、業務への影響の有無を正確に判断することができないという課題がある。
本発明は、上記のような課題を解決することを主な目的の一つとし、データ処理サービスに障害が発生したときの業務への影響の有無を正確に特定することを主な目的とする。
本発明に係る情報処理装置は、
業務において実行されるデータ処理サービスが示されるとともに当該データ処理サービスの実行に要求される実行条件が示される条件情報を記憶する情報記憶装置に接続され、
実行時に障害が発生したデータ処理サービスを障害発生データ処理サービスとして検出する障害検出部と、
前記障害検出部により前記障害発生データ処理サービスが検出された際に前記情報記憶装置から前記条件情報を読み出し、障害発生時の状況が前記条件情報に示される前記障害発生データ処理サービスの実行条件に合致しているか否かを業務ごとに判断し、実行条件に合致している業務は前記障害発生データ処理サービスの障害の影響を受けると判定し、実行条件に合致していない業務は前記障害発生データ処理サービスの障害の影響を受けないと判定する障害影響度判定部を有することを特徴とする。
業務において実行されるデータ処理サービスが示されるとともに当該データ処理サービスの実行に要求される実行条件が示される条件情報を記憶する情報記憶装置に接続され、
実行時に障害が発生したデータ処理サービスを障害発生データ処理サービスとして検出する障害検出部と、
前記障害検出部により前記障害発生データ処理サービスが検出された際に前記情報記憶装置から前記条件情報を読み出し、障害発生時の状況が前記条件情報に示される前記障害発生データ処理サービスの実行条件に合致しているか否かを業務ごとに判断し、実行条件に合致している業務は前記障害発生データ処理サービスの障害の影響を受けると判定し、実行条件に合致していない業務は前記障害発生データ処理サービスの障害の影響を受けないと判定する障害影響度判定部を有することを特徴とする。
本発明によれば、データ処理サービスに障害が発生した場合に、障害発生時の状況が障害データ処理サービスの実行条件に合致するか否かを業務ごとに判断し、実行条件に合致しない業務については障害発生サービスが実行されていた可能性がないので障害の影響がないと判定でき、実行条件に合致する業務については障害発生サービスが実行されていた可能性があるので障害の影響があると判定することができ、障害による業務への影響を正確に判定することができる。
実施の形態1.
図1は、本実施の形態に係るシステム構成例を示す。
図1において、情報システム10はSOAで構築された情報システムである。
情報システム10は、業務に用いられるクライアント装置やサーバ装置で構成される。
運用管理装置20は、サービス運用管理サーバ装置201及び情報記憶装置204で構成される。
サービス運用管理サーバ装置201は、情報処理装置の例である。
管理用クライアント装置301は、システム運用管理者が運用管理のために用いるクライアント装置である。
図1は、本実施の形態に係るシステム構成例を示す。
図1において、情報システム10はSOAで構築された情報システムである。
情報システム10は、業務に用いられるクライアント装置やサーバ装置で構成される。
運用管理装置20は、サービス運用管理サーバ装置201及び情報記憶装置204で構成される。
サービス運用管理サーバ装置201は、情報処理装置の例である。
管理用クライアント装置301は、システム運用管理者が運用管理のために用いるクライアント装置である。
情報システム10において、業務クライアント装置101は、業務を実行するシステム利用者が利用するクライアント装置である。
業務サーバ装置102は、業務クライアント装置101から要求を受け付け、各業務のビジネスプロセスに従い、ESBサーバ装置103に対してサービスの呼び出しを行い、業務を実行するサーバ装置である。
ESBサーバ装置103は、業務サーバ装置102からの要求を受け付け、適切なサービスを呼び出す機能を搭載したサーバ装置である。ESBサーバ装置103は、サービス実行管理装置の例である。
実行ログ1031は、ESBサーバ装置103上で記録されるサービスに関連する実行ログである。
実行ログ1031には、どの業務サーバ装置がどのサービスを呼び出し、呼び出したサービスが正常に値を返したか、異常があったか、などが記録されている。
ネットワーク104は、各サーバ装置が接続されるインターネットやイントラネットなどのネットワークである。
サーバ装置A105やサーバ装置B106は、自社または他社にあるサービスを提供しているサーバ装置である。
サービスa(1051)、サービスa2(1052)、サービスb(1061)、サービスb2(1062)はデータ処理サービスの実体である。各サービスは、ESBサーバ装置103を介して業務サーバ装置102から利用可能となるようインターフェイスを公開しているソフトウェアである。
業務サーバ装置102は、業務クライアント装置101から要求を受け付け、各業務のビジネスプロセスに従い、ESBサーバ装置103に対してサービスの呼び出しを行い、業務を実行するサーバ装置である。
ESBサーバ装置103は、業務サーバ装置102からの要求を受け付け、適切なサービスを呼び出す機能を搭載したサーバ装置である。ESBサーバ装置103は、サービス実行管理装置の例である。
実行ログ1031は、ESBサーバ装置103上で記録されるサービスに関連する実行ログである。
実行ログ1031には、どの業務サーバ装置がどのサービスを呼び出し、呼び出したサービスが正常に値を返したか、異常があったか、などが記録されている。
ネットワーク104は、各サーバ装置が接続されるインターネットやイントラネットなどのネットワークである。
サーバ装置A105やサーバ装置B106は、自社または他社にあるサービスを提供しているサーバ装置である。
サービスa(1051)、サービスa2(1052)、サービスb(1061)、サービスb2(1062)はデータ処理サービスの実体である。各サービスは、ESBサーバ装置103を介して業務サーバ装置102から利用可能となるようインターフェイスを公開しているソフトウェアである。
運用管理装置20において、サービス運用管理サーバ装置201は、実行ログ1031を受け取り、その内容を解析し、情報記憶装置204内の構成情報202や判断知識203を利用して、障害発生時に、どの業務にどの程度の影響があったかを判断する。
情報記憶装置204は、構成情報202及び判断知識203を記憶している。
構成情報202は、業務サーバ装置102がもつ業務情報や、サーバ装置A、Bがもつサービス情報などの情報である。
構成情報202は、例えば、図6、図7、図8に示される情報であり、業務ごとに、業務に含まれる複数の業務プロセスの構成と、業務プロセスで実行されるサービス(データ処理サービス)が示される。
また、構成情報202には、業務と、障害が当該業務に影響を与えるサービスとの組み合わせや、業務と、障害が当該業務に影響を与える可能性のあるサービスとの組み合わせが定義されている。
構成情報202は、業務構成情報及び影響業務情報の例である。
なお、図6、図7、図8の詳細は後述する。
構成情報202は、例えば、図6、図7、図8に示される情報であり、業務ごとに、業務に含まれる複数の業務プロセスの構成と、業務プロセスで実行されるサービス(データ処理サービス)が示される。
また、構成情報202には、業務と、障害が当該業務に影響を与えるサービスとの組み合わせや、業務と、障害が当該業務に影響を与える可能性のあるサービスとの組み合わせが定義されている。
構成情報202は、業務構成情報及び影響業務情報の例である。
なお、図6、図7、図8の詳細は後述する。
判断知識203は障害発生時にどの業務に本当に影響があるかを判断するための情報である。
判断知識203は、例えば、図10に示される情報であり、業務において実行されるサービスが示されるとともに当該サービスの実行に要求される実行条件が示されている。
サービス運用管理サーバ装置201は、いずれかのサービスに障害が発生した場合に、判断知識203を参照し、障害発生時の状況が障害が発生したサービス(以下、障害発生サービスともいう)の実行条件に合致するか否かを判断して、業務に対する影響の可能性を判断する。
判断知識203は条件情報の例である。
なお、図10の詳細は後述する。
判断知識203は、例えば、図10に示される情報であり、業務において実行されるサービスが示されるとともに当該サービスの実行に要求される実行条件が示されている。
サービス運用管理サーバ装置201は、いずれかのサービスに障害が発生した場合に、判断知識203を参照し、障害発生時の状況が障害が発生したサービス(以下、障害発生サービスともいう)の実行条件に合致するか否かを判断して、業務に対する影響の可能性を判断する。
判断知識203は条件情報の例である。
なお、図10の詳細は後述する。
本実施の形態では、このように、構成情報202及び判断知識203に、業務において実行されるサービスの実行条件が示されている。
そして、サービス運用管理サーバ装置201は、ESBサーバ装置103からサービス実行状況を示す実行ログ1031を入力し、実行ログ1031の解析の結果、サービスに障害が発生したと判断した場合に、障害発生時の状況が障害発生サービスの実行条件に合致するか否かを業務ごとに判断する。
実行条件に合致しない業務についてはサービスが実行されていた可能性がないので障害の影響がないと判定でき、実行条件に合致する業務についてはサービスが実行されていた可能性があるので障害の影響があると判定することができる。
そして、サービス運用管理サーバ装置201は、ESBサーバ装置103からサービス実行状況を示す実行ログ1031を入力し、実行ログ1031の解析の結果、サービスに障害が発生したと判断した場合に、障害発生時の状況が障害発生サービスの実行条件に合致するか否かを業務ごとに判断する。
実行条件に合致しない業務についてはサービスが実行されていた可能性がないので障害の影響がないと判定でき、実行条件に合致する業務についてはサービスが実行されていた可能性があるので障害の影響があると判定することができる。
図2は、本実施の形態に係るサービス運用管理サーバ装置201の詳細な構成例を示す図である。
解析部2011は、実行ログ1031を受け取り、ログを解析し、実行時に障害が発生したサービスを障害発生サービス(障害発生データ処理サービス)として検出する。
解析部2011は、障害検出部の例である。
解析部2011は、障害検出部の例である。
障害影響度判定部2012は、解析部2011から渡されるデータと、構成情報202及び判断知識203を元に、障害の影響度を判定する。
つまり、障害影響度判定部2012は、解析部2011により障害発生サービスが検出された際に情報記憶装置204から構成情報202及び判断知識203を読み出し、構成情報202に障害発生サービスに対して障害の影響を受ける可能性のある業務が定義されているか否かを判断する。
障害の影響を受ける可能性のある業務が定義されている場合は、当該業務に対して、障害発生時の状況が判断知識203に示される障害発生サービスの実行条件に合致しているか否かを判断する。
そして、障害影響度判定部2012は、実行条件に合致している業務は障害発生サービスの障害の影響を受けると判定し、実行条件に合致していない業務は障害発生サービスの障害の影響を受けないと判定する。
なお、構成情報202に障害発生サービスに対して障害の影響を受ける業務が定義されている場合は、当該業務に対しては、判断知識203を用いた判断を行うことなく、当該業務は障害発生サービスの障害の影響を受けると判定する。
つまり、障害影響度判定部2012は、解析部2011により障害発生サービスが検出された際に情報記憶装置204から構成情報202及び判断知識203を読み出し、構成情報202に障害発生サービスに対して障害の影響を受ける可能性のある業務が定義されているか否かを判断する。
障害の影響を受ける可能性のある業務が定義されている場合は、当該業務に対して、障害発生時の状況が判断知識203に示される障害発生サービスの実行条件に合致しているか否かを判断する。
そして、障害影響度判定部2012は、実行条件に合致している業務は障害発生サービスの障害の影響を受けると判定し、実行条件に合致していない業務は障害発生サービスの障害の影響を受けないと判定する。
なお、構成情報202に障害発生サービスに対して障害の影響を受ける業務が定義されている場合は、当該業務に対しては、判断知識203を用いた判断を行うことなく、当該業務は障害発生サービスの障害の影響を受けると判定する。
障害影響箇所表示部2013は、解析部2011のデータと障害影響度判定部2012の結果を元に、障害の影響範囲を表示する。
次に、構成情報202及び判断知識203の詳細を説明する。
構成情報202は、図6〜図8に示す構造のデータを持っている。
なお、図6〜図8において、「(ア)項目の説明」は、各データの項目名及び各項目の内容を説明しており、「(イ)データの例」は、実際のデータの内容例を示している。
なお、図6〜図8において、「(ア)項目の説明」は、各データの項目名及び各項目の内容を説明しており、「(イ)データの例」は、実際のデータの内容例を示している。
図6の(1)業務サービス影響度対応表は、業務名、サービス名、影響度IDからなり、各業務がどのサービスを利用しているか、また、障害が発生した場合にどの影響度IDに関連するかを示すものである。
図6の(2)業務影響度表は、影響度ID、影響度レベル、影響度名からなり、影響度IDで示される影響度のレベルを表すものである。図6の例では、影響度としては、「影響あり」、「可能性あり」、「影響なし」の3種類となっている。
図7の(3)のノードサービス表は、業務名、ノード名、タイプ、サービス名からなり、各業務がどのような業務フローとなるかの構成要素を表しており、図8の(4)プロセスフロー表で利用される。
図8の(4)プロセスフロー表は、業務名、ノード名、ノード元からなり、各業務がどの順番でサービスを呼び出すか、そのフローを表すものである。
図9に(3)ノードサービス表と(4)プロセスフロー表を用いた業務フローの例を示す。
図9(a)は業務X1の業務フローを示し、図9(b)は業務X2の業務フローを示す。
なお、各業務フローにおいて、1〜5(図9(a))及び1〜7(図9(b))は、図7の(3)ノードサービス表に示す各ノードである。
図6の(2)業務影響度表は、影響度ID、影響度レベル、影響度名からなり、影響度IDで示される影響度のレベルを表すものである。図6の例では、影響度としては、「影響あり」、「可能性あり」、「影響なし」の3種類となっている。
図7の(3)のノードサービス表は、業務名、ノード名、タイプ、サービス名からなり、各業務がどのような業務フローとなるかの構成要素を表しており、図8の(4)プロセスフロー表で利用される。
図8の(4)プロセスフロー表は、業務名、ノード名、ノード元からなり、各業務がどの順番でサービスを呼び出すか、そのフローを表すものである。
図9に(3)ノードサービス表と(4)プロセスフロー表を用いた業務フローの例を示す。
図9(a)は業務X1の業務フローを示し、図9(b)は業務X2の業務フローを示す。
なお、各業務フローにおいて、1〜5(図9(a))及び1〜7(図9(b))は、図7の(3)ノードサービス表に示す各ノードである。
判断知識203は、図10に示す構造のデータを持っている。
(1)業務判断知識対応表は、業務名、サービス名、判断知識IDからなり、障害が発生したサービスと、それに関連する業務において、障害の影響があるかどうか、つまり、そのサービスが利用されているかどうかを判断知識IDから判断する。なお、(1)業務判断知識対応表に記述されている業務とサービスの組は、図6の(2)業務影響度表において影響度が「可能性あり」とされている業務とサービスの組である。
(2)判断知識表は、判断知識ID、評価項目、条件、評価値、利用からなり、判断知識IDで示される判断知識が、(1)業務判断知識対応表の判断知識IDに対応する。
ここで示すように、判断知識の一つは日時情報である。
図10の例では、cid1は、障害発生日の日付が25日以降であれば、障害発生サービスは業務に影響しないことを示している。cid2は、障害発生日の日付が25日よりも前であれば、障害発生サービスは業務に影響しないことを示している。cid3は、障害発生日の日付が25日よりも前であれば、障害発生サービスが業務に影響することを示している。
(1)業務判断知識対応表は、業務名、サービス名、判断知識IDからなり、障害が発生したサービスと、それに関連する業務において、障害の影響があるかどうか、つまり、そのサービスが利用されているかどうかを判断知識IDから判断する。なお、(1)業務判断知識対応表に記述されている業務とサービスの組は、図6の(2)業務影響度表において影響度が「可能性あり」とされている業務とサービスの組である。
(2)判断知識表は、判断知識ID、評価項目、条件、評価値、利用からなり、判断知識IDで示される判断知識が、(1)業務判断知識対応表の判断知識IDに対応する。
ここで示すように、判断知識の一つは日時情報である。
図10の例では、cid1は、障害発生日の日付が25日以降であれば、障害発生サービスは業務に影響しないことを示している。cid2は、障害発生日の日付が25日よりも前であれば、障害発生サービスは業務に影響しないことを示している。cid3は、障害発生日の日付が25日よりも前であれば、障害発生サービスが業務に影響することを示している。
ここで、構成情報202のデータ(業務サービス影響度対応表(図6(1))や業務影響度表(図6(2))は、システム管理者などの人間が登録・更新等を行う。
すなわち、新規の業務が登場した場合、業務フローを定義し、業務サーバ装置102に登録することになるが、これと同時に、情報記憶装置204にも情報を登録する。
また、判断知識203についても同様に人間がデータを生成・管理し、また、情報記憶装置204に登録する。
構成情報202、判断知識203のデータを管理するのが、図14で示すサービス運用管理サーバ装置201にある構成情報・判断知識管理部2014である。
すなわち、新規の業務が登場した場合、業務フローを定義し、業務サーバ装置102に登録することになるが、これと同時に、情報記憶装置204にも情報を登録する。
また、判断知識203についても同様に人間がデータを生成・管理し、また、情報記憶装置204に登録する。
構成情報202、判断知識203のデータを管理するのが、図14で示すサービス運用管理サーバ装置201にある構成情報・判断知識管理部2014である。
次に図11及び図12のフローチャートを用いて、動作について説明する。
実行ログ1031は、リアルタイムに、解析部2011に出力され、解析部2011は実行ログを入力する(S01)。
解析部2011が実行ログ1031を解析した結果、障害が発生したサービスを検出した場合(S02でYES)(障害検出ステップ)、解析部2011は、障害影響度判定部2012に障害発生サービスを通知する。
実行ログ1031には、どのサービスでエラーが発生したかが記録されている。
以降では、サービスbで障害が発生した場合を想定して説明を進める。
実行ログ1031は、リアルタイムに、解析部2011に出力され、解析部2011は実行ログを入力する(S01)。
解析部2011が実行ログ1031を解析した結果、障害が発生したサービスを検出した場合(S02でYES)(障害検出ステップ)、解析部2011は、障害影響度判定部2012に障害発生サービスを通知する。
実行ログ1031には、どのサービスでエラーが発生したかが記録されている。
以降では、サービスbで障害が発生した場合を想定して説明を進める。
解析部2011から障害発生サービスの通知を受けた障害影響度判定部2012は、情報記憶装置204から構成情報202を読み出す(S03)。
そして、障害影響度判定部2012は、業務サービス影響度対応表(図6(1))を元に、サービスbが関連するレコードを検索し、そこから業務名を抽出する(S04、S05)。
この段階で、障害の影響の可能性がある業務が抽出される。
この例では、業務X1と業務X2が抽出される。
S05においてレコードが抽出されなかった場合は、障害影響度判定部2012は、この障害で影響のある業務はないと判定する(S06)。
次に、障害影響度判定部2012は、本当に影響がどの程度あるかを判断する。
障害影響度判定部2012は、障害が発生したサービスと業務を元に、業務影響度表(図6(1))から、影響度を判断する(S07、S08)。
この例では、サービスbで障害が発生した場合、業務X1は影響度レベルが1であるので、「影響あり」となり、障害影響度判定部2012は、サービスbの障害により業務X1に影響が及ぶと判断する(S09)。
また、業務X2は影響度レベルが2であるので、「可能性あり」となり、次のステップへ進む。
なお、影響度レベルが3の場合は、発生した障害は業務に影響を与えないと判定する(S10)。
そして、障害影響度判定部2012は、業務サービス影響度対応表(図6(1))を元に、サービスbが関連するレコードを検索し、そこから業務名を抽出する(S04、S05)。
この段階で、障害の影響の可能性がある業務が抽出される。
この例では、業務X1と業務X2が抽出される。
S05においてレコードが抽出されなかった場合は、障害影響度判定部2012は、この障害で影響のある業務はないと判定する(S06)。
次に、障害影響度判定部2012は、本当に影響がどの程度あるかを判断する。
障害影響度判定部2012は、障害が発生したサービスと業務を元に、業務影響度表(図6(1))から、影響度を判断する(S07、S08)。
この例では、サービスbで障害が発生した場合、業務X1は影響度レベルが1であるので、「影響あり」となり、障害影響度判定部2012は、サービスbの障害により業務X1に影響が及ぶと判断する(S09)。
また、業務X2は影響度レベルが2であるので、「可能性あり」となり、次のステップへ進む。
なお、影響度レベルが3の場合は、発生した障害は業務に影響を与えないと判定する(S10)。
S08において影響度レベルが2であった場合は、障害影響度判定部2012は、情報記憶装置204から判断知識203を読みだす(S11)(情報読み出しステップ)。
次に、障害影響度判定部2012は、読み出した判断知識203を参照する。
具体的には、障害影響度判定部2012は、業務判断知識対応表(図10(1))を元に、業務名とサービス名で検索を行う(S12、S13)(障害影響度判定ステップ)。
該当するレコードがない場合は、障害影響度判定部2012は、業務への影響の可能性があると判断する(S14)。
該当するレコードがあれば、障害影響度判定部2012は、その判断知識IDを元に、判断知識表(図10(2))を検索し、評価項目にある値を取得し、条件を評価する(S15、S16)(障害影響度判定ステップ)。
評価した結果として、利用がない(値が0)の場合は、障害が発生したサービスは利用していない可能性が高いので、障害影響度判定部2012は、業務への影響はないと判断する(S18)(障害影響度判定ステップ)。
逆に利用があれば、障害影響度判定部2012は、業務への影響があると判断する(S17)(障害影響度判定ステップ)。
この例では、業務X2、サービス名bのレコードとして、判断知識IDがcid1と一致し、判断知識表(図10(2))により、障害発生日が25日以降であれば、サービスbは業務X2において利用されていないということになる。
例えば、障害が発生した日が、11月27日であれば、図12のS15の処理にて、27日の「27」が取得される。
この値が実行条件の「25」以上なので、サービスbは業務X2では利用されていないことになり、障害の影響はないと判断できる。
図13は、この例に適用したときの業務フローのイメージ図である。
つまり、業務X2は、サービスaの実行後に、条件式により、1日〜24日の間はサービスbが実行されるが、25日以降はサービスdが実行されるという業務フローを持つ。
次に、障害影響度判定部2012は、読み出した判断知識203を参照する。
具体的には、障害影響度判定部2012は、業務判断知識対応表(図10(1))を元に、業務名とサービス名で検索を行う(S12、S13)(障害影響度判定ステップ)。
該当するレコードがない場合は、障害影響度判定部2012は、業務への影響の可能性があると判断する(S14)。
該当するレコードがあれば、障害影響度判定部2012は、その判断知識IDを元に、判断知識表(図10(2))を検索し、評価項目にある値を取得し、条件を評価する(S15、S16)(障害影響度判定ステップ)。
評価した結果として、利用がない(値が0)の場合は、障害が発生したサービスは利用していない可能性が高いので、障害影響度判定部2012は、業務への影響はないと判断する(S18)(障害影響度判定ステップ)。
逆に利用があれば、障害影響度判定部2012は、業務への影響があると判断する(S17)(障害影響度判定ステップ)。
この例では、業務X2、サービス名bのレコードとして、判断知識IDがcid1と一致し、判断知識表(図10(2))により、障害発生日が25日以降であれば、サービスbは業務X2において利用されていないということになる。
例えば、障害が発生した日が、11月27日であれば、図12のS15の処理にて、27日の「27」が取得される。
この値が実行条件の「25」以上なので、サービスbは業務X2では利用されていないことになり、障害の影響はないと判断できる。
図13は、この例に適用したときの業務フローのイメージ図である。
つまり、業務X2は、サービスaの実行後に、条件式により、1日〜24日の間はサービスbが実行されるが、25日以降はサービスdが実行されるという業務フローを持つ。
このように、本実施の形態により、障害が発生した場合に、その障害により、どの業務に影響があるかを判断することができる。
つまり、サービスに障害が発生した場合に、障害発生時の状況がサービスの実行条件に合致するか否かを業務ごとに判断し、実行条件に合致しない業務についてはサービスが実行されていた可能性がないので障害の影響がないと判定でき、実行条件に合致する業務についてはサービスが実行されていた可能性があるので障害の影響があると判定することができ、障害による業務への影響を正確に判定することができる。
また、業務に影響を与えるタイミングを判断できるので、すぐに影響はないが、そのうち影響があるなどもわかるので、障害に対応する優先順位や場合によっては期限などを知ることもできる。
このように、システム運用管理者は、影響範囲を把握することができるので、業務の利用者へ障害の通知を行う、障害対応の優先順位を決めるといった処理が可能になる。
つまり、サービスに障害が発生した場合に、障害発生時の状況がサービスの実行条件に合致するか否かを業務ごとに判断し、実行条件に合致しない業務についてはサービスが実行されていた可能性がないので障害の影響がないと判定でき、実行条件に合致する業務についてはサービスが実行されていた可能性があるので障害の影響があると判定することができ、障害による業務への影響を正確に判定することができる。
また、業務に影響を与えるタイミングを判断できるので、すぐに影響はないが、そのうち影響があるなどもわかるので、障害に対応する優先順位や場合によっては期限などを知ることもできる。
このように、システム運用管理者は、影響範囲を把握することができるので、業務の利用者へ障害の通知を行う、障害対応の優先順位を決めるといった処理が可能になる。
なお、上記の業務サービス影響度対応表(図6(1))、業務影響度表(図6(2))、業務判断知識対応表(図10(1))、判断知識表(図10(2))を統合して、図16の(1)業務判断知識対応表、(2)判断知識表のようにしてもよい。
図16の(1)業務判断知識対応表は、図6の(1)業務サービス影響度対応表の業務名とサービス名と、図10の(1)業務判断知識対応表を組み合わせたものである。
つまり、図16の(1)業務判断知識対応表は、全業務について、業務ごとに実行されるサービス名が示されるとともに、業務とサービスの組に対して判断知識IDが設定されている。
図16の(2)判断知識表は、図6の(2)判断知識表と同じ構成であるが、内容が異なる。
図16の(2)判断知識表では、図16の(1)業務判断知識対応表に示されている全ての業務とサービスの組に対応する実行条件が示されている。
より具体的には、cid1〜cid3は、図6のものと同様であるが、cid4は常に影響あり(毎月1日〜末日まで業務においてサービスが実行されている)という実行条件を示す。
例えば、図6の例では、業務名:X1とサービス名:aの組は、常に「影響度あり」(eid1)と判定されるが、図16の例でも、業務名:X1とサービス名:aの組は、判断知識IDとしてcid4が設定されており、cid4は、前述のように、常に影響あり(毎月1日〜末日まで業務においてサービスが実行されている)と定義されている。
このように、業務サービス影響度対応表(図6(1))、業務影響度表(図6(2))、業務判断知識対応表(図10(1))、判断知識表(図10(2))を統合して、図16の(1)業務判断知識対応表、(2)判断知識表のようにしても同様の取り扱いが可能である。
図16の(1)業務判断知識対応表は、図6の(1)業務サービス影響度対応表の業務名とサービス名と、図10の(1)業務判断知識対応表を組み合わせたものである。
つまり、図16の(1)業務判断知識対応表は、全業務について、業務ごとに実行されるサービス名が示されるとともに、業務とサービスの組に対して判断知識IDが設定されている。
図16の(2)判断知識表は、図6の(2)判断知識表と同じ構成であるが、内容が異なる。
図16の(2)判断知識表では、図16の(1)業務判断知識対応表に示されている全ての業務とサービスの組に対応する実行条件が示されている。
より具体的には、cid1〜cid3は、図6のものと同様であるが、cid4は常に影響あり(毎月1日〜末日まで業務においてサービスが実行されている)という実行条件を示す。
例えば、図6の例では、業務名:X1とサービス名:aの組は、常に「影響度あり」(eid1)と判定されるが、図16の例でも、業務名:X1とサービス名:aの組は、判断知識IDとしてcid4が設定されており、cid4は、前述のように、常に影響あり(毎月1日〜末日まで業務においてサービスが実行されている)と定義されている。
このように、業務サービス影響度対応表(図6(1))、業務影響度表(図6(2))、業務判断知識対応表(図10(1))、判断知識表(図10(2))を統合して、図16の(1)業務判断知識対応表、(2)判断知識表のようにしても同様の取り扱いが可能である。
また、図16の判断知識203を用いる場合は、サービス運用管理サーバ装置201の動作フローは、例えば、図17のようになる。
つまり、図11の場合と同様に、解析部2011が実行ログ1031を入力し(S01)、障害が発生したサービスを検出した場合(S02でYES)は、障害影響度判定部2012は、情報記憶装置204から図16に示す判断知識203を読み出し(S11)、以降は、図11及び図12のS12〜S18を実行する。
このように、図16の判断知識を用いた場合は、図11のS4〜S8の処理を省略することができ、処理時間を短縮することができ、また、少ない計算機資源で処理を行うことができる。
つまり、図11の場合と同様に、解析部2011が実行ログ1031を入力し(S01)、障害が発生したサービスを検出した場合(S02でYES)は、障害影響度判定部2012は、情報記憶装置204から図16に示す判断知識203を読み出し(S11)、以降は、図11及び図12のS12〜S18を実行する。
このように、図16の判断知識を用いた場合は、図11のS4〜S8の処理を省略することができ、処理時間を短縮することができ、また、少ない計算機資源で処理を行うことができる。
以上、本実施の形態では、次の手段を備えている運用管理方式を説明した。
障害影響範囲を特定するために、障害が発生したサービスが特定されることがわかる実行ログなどの情報を解析し、どのサービスで障害が発生したかを解析する解析部(これにより、障害が発生したサービスの名前がわかる)
下記を有する障害影響度判定部
業務、サービス、障害の影響度などの構成を管理する構成情報
業務への影響を判断するための判断知識
障害による業務への影響を表示する障害影響箇所表示部。
障害影響範囲を特定するために、障害が発生したサービスが特定されることがわかる実行ログなどの情報を解析し、どのサービスで障害が発生したかを解析する解析部(これにより、障害が発生したサービスの名前がわかる)
下記を有する障害影響度判定部
業務、サービス、障害の影響度などの構成を管理する構成情報
業務への影響を判断するための判断知識
障害による業務への影響を表示する障害影響箇所表示部。
実施の形態2.
実施の形態1では、構成情報202は、業務を設計した設計者や業務を熟知している者から業務の内容をヒアリングなどして、データを投入する。
実施の形態2では、ある程度自動的にデータを登録する。
本実施の形態は、図14に示す構成情報・判断知識管理部2014(情報生成部)に関する。
実施の形態1では、構成情報202は、業務を設計した設計者や業務を熟知している者から業務の内容をヒアリングなどして、データを投入する。
実施の形態2では、ある程度自動的にデータを登録する。
本実施の形態は、図14に示す構成情報・判断知識管理部2014(情報生成部)に関する。
各業務フロー(業務プロセス)は、図7の(3)ノードサービス表と図8の(4)プロセスフロー表によって表すことができる。
例えば、業務X1(図3)や業務X2(図5)は、図7の(3)ノードサービス表及び図8の(4)プロセスフロー表のデータ例に示すように格納することで、図9の業務X1,X2を再現することができる。
また、例えば、図8(4)(イ)のデータ例で、ある業務において、ノード元が同じでノード名が異なるもの(この例では業務X2において、ノード元3が2つあり、それぞれ、ノード名は4と5である)がある場合には、業務フローが分岐や並列処理が発生していることがわかる。
例えば、業務X1(図3)や業務X2(図5)は、図7の(3)ノードサービス表及び図8の(4)プロセスフロー表のデータ例に示すように格納することで、図9の業務X1,X2を再現することができる。
また、例えば、図8(4)(イ)のデータ例で、ある業務において、ノード元が同じでノード名が異なるもの(この例では業務X2において、ノード元3が2つあり、それぞれ、ノード名は4と5である)がある場合には、業務フローが分岐や並列処理が発生していることがわかる。
したがって、業務を設計した設計者や業務を熟知している者から業務の内容をヒアリングなどして、図7の(3)ノードサービス表と図8の(4)プロセスフロー表を人間が登録する。
これにより、構成情報・判断知識管理部2014は、これらの情報から、図6の(1)業務サービス影響度対応表の業務名とサービス名を投入することができる。
また影響度IDについては、分岐や並列がある部分で影響度レベルが1以外になる可能性があるので、その部分以外は、影響度レベルを1として自動で設定することができる。
これにより、構成情報への登録作業を効率的に実施することができる。
これにより、構成情報・判断知識管理部2014は、これらの情報から、図6の(1)業務サービス影響度対応表の業務名とサービス名を投入することができる。
また影響度IDについては、分岐や並列がある部分で影響度レベルが1以外になる可能性があるので、その部分以外は、影響度レベルを1として自動で設定することができる。
これにより、構成情報への登録作業を効率的に実施することができる。
本実施の形態では、障害影響度判定部が、業務フローを再現するために、業務フローの各ノードとそのノードの元となる情報、及び、各ノードのタイプと呼び出されるサービスを管理する構成情報を有していることを説明した。
実施の形態3.
前述の通り、SOAなどにより構築されるシステムでは、業務フローはBPEL(Business Process Execution Language)などの標準的な記述様式で記述されることが一般的である。
BPELは、業務フローを記述するものである。
図15に示すように、一般にBPELは業務サーバ装置102上の定義ファイル(図番号1021)の記述に用いられる。
したがって、BPELで記述された業務フローを元に構成情報・判断知識管理部2014にて、自動的に、構成情報202のノードサービス表(3)とプロセスフロー表(4)を作成することができる。
前述の通り、SOAなどにより構築されるシステムでは、業務フローはBPEL(Business Process Execution Language)などの標準的な記述様式で記述されることが一般的である。
BPELは、業務フローを記述するものである。
図15に示すように、一般にBPELは業務サーバ装置102上の定義ファイル(図番号1021)の記述に用いられる。
したがって、BPELで記述された業務フローを元に構成情報・判断知識管理部2014にて、自動的に、構成情報202のノードサービス表(3)とプロセスフロー表(4)を作成することができる。
これにより、実施の形態2に示す構成よりも構成情報への登録作業を効率的に行うことができ、また、業務フローから自動で登録されるので、登録の間違いなどを減らすことができる。
本実施の形態では、障害影響度判定部が、BPEL等の標準的な業務フロー情報を元に、自動的に、業務フローの各ノードとそのノードの元となる情報、及び、各ノードのタイプと呼び出されるサービスを登録する手段を有すること、また、その情報を管理する構成情報を有していることを説明した。
最後に、実施の形態1〜3に示したサービス運用管理サーバ装置201のハードウェア構成例について説明する。
図18は、実施の形態1〜3に示すサービス運用管理サーバ装置201のハードウェア資源の一例を示す図である。
なお、図18の構成は、あくまでもサービス運用管理サーバ装置201のハードウェア構成の一例を示すものであり、サービス運用管理サーバ装置201のハードウェア構成は図18に記載の構成に限らず、他の構成であってもよい。
図18は、実施の形態1〜3に示すサービス運用管理サーバ装置201のハードウェア資源の一例を示す図である。
なお、図18の構成は、あくまでもサービス運用管理サーバ装置201のハードウェア構成の一例を示すものであり、サービス運用管理サーバ装置201のハードウェア構成は図18に記載の構成に限らず、他の構成であってもよい。
図18において、サービス運用管理サーバ装置201は、プログラムを実行するCPU911(Central Processing Unit、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう)を備えている。
CPU911は、バス912を介して、例えば、ROM(Read Only Memory)913、RAM(Random Access Memory)914、通信ボード915、表示装置901、キーボード902、マウス903、磁気ディスク装置920と接続され、これらのハードウェアデバイスを制御する。
更に、CPU911は、FDD904(Flexible Disk Drive)、コンパクトディスク装置905(CDD)、プリンタ装置906、スキャナ装置907と接続していてもよい。また、磁気ディスク装置920の代わりに、光ディスク装置、メモリカード(登録商標)読み書き装置などの記憶装置でもよい。
RAM914は、揮発性メモリの一例である。ROM913、FDD904、CDD905、磁気ディスク装置920の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。
実施の形態1〜3で説明した「情報記憶装置204」は、例えば、磁気ディスク装置920により実現される。
通信ボード915、キーボード902、マウス903、スキャナ装置907、FDD904などは、入力装置の一例である。
また、通信ボード915、表示装置901、プリンタ装置906などは、出力装置の一例である。
CPU911は、バス912を介して、例えば、ROM(Read Only Memory)913、RAM(Random Access Memory)914、通信ボード915、表示装置901、キーボード902、マウス903、磁気ディスク装置920と接続され、これらのハードウェアデバイスを制御する。
更に、CPU911は、FDD904(Flexible Disk Drive)、コンパクトディスク装置905(CDD)、プリンタ装置906、スキャナ装置907と接続していてもよい。また、磁気ディスク装置920の代わりに、光ディスク装置、メモリカード(登録商標)読み書き装置などの記憶装置でもよい。
RAM914は、揮発性メモリの一例である。ROM913、FDD904、CDD905、磁気ディスク装置920の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。
実施の形態1〜3で説明した「情報記憶装置204」は、例えば、磁気ディスク装置920により実現される。
通信ボード915、キーボード902、マウス903、スキャナ装置907、FDD904などは、入力装置の一例である。
また、通信ボード915、表示装置901、プリンタ装置906などは、出力装置の一例である。
通信ボード915は、ネットワークに接続されている。例えば、通信ボード915は、LAN(ローカルエリアネットワーク)、インターネット、WAN(ワイドエリアネットワーク)、SAN(ストレージエリアネットワーク)などに接続されていても構わない。
磁気ディスク装置920には、オペレーティングシステム921(OS)、ウィンドウシステム922、プログラム群923、ファイル群924が記憶されている。
プログラム群923のプログラムは、CPU911がオペレーティングシステム921、ウィンドウシステム922を利用しながら実行する。
プログラム群923のプログラムは、CPU911がオペレーティングシステム921、ウィンドウシステム922を利用しながら実行する。
また、RAM914には、CPU911に実行させるオペレーティングシステム921のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。
また、RAM914には、CPU911による処理に必要な各種データが格納される。
また、RAM914には、CPU911による処理に必要な各種データが格納される。
また、ROM913には、BIOS(Basic Input Output System)プログラムが格納され、磁気ディスク装置920にはブートプログラムが格納されている。
サービス運用管理サーバ装置201の起動時には、ROM913のBIOSプログラム及び磁気ディスク装置920のブートプログラムが実行され、BIOSプログラム及びブートプログラムによりオペレーティングシステム921が起動される。
サービス運用管理サーバ装置201の起動時には、ROM913のBIOSプログラム及び磁気ディスク装置920のブートプログラムが実行され、BIOSプログラム及びブートプログラムによりオペレーティングシステム921が起動される。
上記プログラム群923には、実施の形態1〜3の説明において「〜部」として説明している機能を実行するプログラムが記憶されている。プログラムは、CPU911により読み出され実行される。
ファイル群924には、実施の形態1〜3の説明において、「〜の判断」、「〜の判定」、「〜の計算」、「〜の比較」、「〜の検索」、「〜の評価」、「〜の更新」、「〜の設定」、「〜の登録」、「〜の選択」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。
「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してCPU911によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのCPUの動作に用いられる。
抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のCPUの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、実施の形態1〜3で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、RAM914のメモリ、FDD904のフレキシブルディスク、CDD905のコンパクトディスク、磁気ディスク装置920の磁気ディスク、その他光ディスク、ミニディスク、DVD等の記録媒体に記録される。また、データや信号は、バス912や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してCPU911によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのCPUの動作に用いられる。
抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のCPUの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、実施の形態1〜3で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、RAM914のメモリ、FDD904のフレキシブルディスク、CDD905のコンパクトディスク、磁気ディスク装置920の磁気ディスク、その他光ディスク、ミニディスク、DVD等の記録媒体に記録される。また、データや信号は、バス912や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
また、実施の形態1〜3の説明において「〜部」として説明しているものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。
すなわち、実施の形態1〜3で説明したフローチャートに示すステップ、手順、処理により、本発明に係る情報処理方法を実現することができる。
また、「〜部」として説明しているものは、ROM913に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、DVD等の記録媒体に記憶される。プログラムはCPU911により読み出され、CPU911により実行される。すなわち、プログラムは、実施の形態1〜3の「〜部」としてコンピュータを機能させるものである。あるいは、実施の形態1〜3の「〜部」の手順や方法をコンピュータに実行させるものである。
すなわち、実施の形態1〜3で説明したフローチャートに示すステップ、手順、処理により、本発明に係る情報処理方法を実現することができる。
また、「〜部」として説明しているものは、ROM913に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、DVD等の記録媒体に記憶される。プログラムはCPU911により読み出され、CPU911により実行される。すなわち、プログラムは、実施の形態1〜3の「〜部」としてコンピュータを機能させるものである。あるいは、実施の形態1〜3の「〜部」の手順や方法をコンピュータに実行させるものである。
このように、実施の形態1〜3に示すサービス運用管理サーバ装置201は、処理装置たるCPU、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータであり、上記したように「〜部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。
10 情報システム、20 運用管理装置、101 業務クライアント装置、102 業務サーバ装置、103 ESBサーバ装置、105 サーバ装置A、106 サーバ装置B、201 サービス運用管理サーバ装置、202 構成情報、203 判断知識、204 情報記憶装置、301 管理用クライアント装置、1031 実行ログ、2011 解析部、2012 障害影響度判定部、2013 障害影響箇所表示部、2014 構成情報・判断知識管理部。
Claims (9)
- 業務において実行されるデータ処理サービスが示されるとともに当該データ処理サービスの実行に要求される実行条件が示される条件情報を記憶する情報記憶装置に接続され、
実行時に障害が発生したデータ処理サービスを障害発生データ処理サービスとして検出する障害検出部と、
前記障害検出部により前記障害発生データ処理サービスが検出された際に前記情報記憶装置から前記条件情報を読み出し、障害発生時の状況が前記条件情報に示される前記障害発生データ処理サービスの実行条件に合致しているか否かを業務ごとに判断し、実行条件に合致している業務は前記障害発生データ処理サービスの障害の影響を受けると判定し、実行条件に合致していない業務は前記障害発生データ処理サービスの障害の影響を受けないと判定する障害影響度判定部を有することを特徴とする情報処理装置。 - 前記情報処理装置は、
業務と、障害が当該業務に影響を与える可能性のあるデータ処理サービスとの組み合わせが定義されている影響業務情報と、
前記影響業務情報において定義されている業務に対して、当該業務と組になっているデータ処理サービスの実行条件が示される条件情報を記憶している情報記憶装置と接続されており、
前記障害影響度判定部は、
前記障害検出部により前記障害発生データ処理サービスが検出された際に前記情報記憶装置から前記影響業務情報を読み出し、前記障害発生データ処理サービスに対して障害の影響を受ける可能性のある業務が定義されている場合に、当該業務に対して、障害発生時の状況が前記条件情報に示される前記障害発生データ処理サービスの実行条件に合致しているか否かを判断することを特徴とする請求項1に記載の情報処理装置。 - 前記情報処理装置は、
業務と、障害が当該業務に影響を与えるデータ処理サービスとの組み合わせが定義されている影響業務情報を記憶している情報記憶装置と接続されており、
前記障害影響度判定部は、
前記障害検出部により前記障害発生データ処理サービスが検出された際に前記情報記憶装置から前記影響業務情報を読み出し、前記障害発生データ処理サービスに対して障害の影響を受ける業務が定義されている場合に、当該業務に対して前記条件情報を用いた判断を行うことなく、当該業務は前記障害発生データ処理サービスの障害の影響を受けると判定することを特徴とする請求項1又は2に記載の情報処理装置。 - 前記情報処理装置は、更に、
業務ごとに、業務に含まれる複数の業務プロセスの構成と、業務プロセスで実行されるデータ処理サービスが示される業務構成情報に基づいて、前記影響業務情報を生成する情報生成部を有することを特徴とする請求項2又は3に記載の情報処理装置。 - 前記情報生成部は、
所定の記述形式に従って業務フローが記述されている業務フロー情報を入力し、入力した業務フロー情報を解析して、前記業務構成情報を生成することを特徴とする請求項4に記載の情報処理装置。 - 前記障害検出部は、
データ処理サービスの実行を管理するサービス実行管理装置からデータ処理サービスの実行状況を示すログデータを入力し、入力したログデータを解析して、いずれかのデータ処理サービスにおける障害の発生を検出することを特徴とする請求項1〜5のいずれかに記載の情報処理装置。 - 前記情報処理装置は、
実行条件として、業務におけるデータ処理サービスの実行タイミングが示されている条件情報を記憶している情報記憶装置に接続されており、
前記障害影響度判定部は、
障害発生時刻が前記条件情報に示されている前記障害発生データ処理サービスの実行タイミングに合致しているか否かを業務ごとに判断し、実行タイミングに合致している業務は前記障害発生データ処理サービスの障害の影響を受けると判定し、実行タイミングに合致していない業務は前記障害発生データ処理サービスの障害の影響を受けないと判定することを特徴とする請求項1〜6のいずれかに記載の情報処理装置。 - 業務において実行されるデータ処理サービスが示されるとともに当該データ処理サービスの実行に要求される実行条件が示される条件情報を記憶する情報記憶装置に接続されているコンピュータによる情報処理方法であって、
前記コンピュータが、実行時に障害が発生したデータ処理サービスを障害発生データ処理サービスとして検出する障害検出ステップと、
前記障害検出ステップにより前記障害発生データ処理サービスが検出された際に、前記コンピュータが前記情報記憶装置から前記条件情報を読み出す情報読み出しステップと、
前記コンピュータが、障害発生時の状況が前記条件情報に示される前記障害発生データ処理サービスの実行条件に合致しているか否かを業務ごとに判断し、実行条件に合致している業務は前記障害発生データ処理サービスの障害の影響を受けると判定し、実行条件に合致していない業務は前記障害発生データ処理サービスの障害の影響を受けないと判定する障害影響度判定ステップを有することを特徴とする情報処理方法。 - 業務において実行されるデータ処理サービスが示されるとともに当該データ処理サービスの実行に要求される実行条件が示される条件情報を記憶する情報記憶装置に接続されているコンピュータに、
実行時に障害が発生したデータ処理サービスを障害発生データ処理サービスとして検出する障害検出処理と、
前記障害検出処理により前記障害発生データ処理サービスが検出された際に前記情報記憶装置から前記条件情報を読み出す情報読み出し処理と、
障害発生時の状況が前記条件情報に示される前記障害発生データ処理サービスの実行条件に合致しているか否かを業務ごとに判断し、実行条件に合致している業務は前記障害発生データ処理サービスの障害の影響を受けると判定し、実行条件に合致していない業務は前記障害発生データ処理サービスの障害の影響を受けないと判定する障害影響度判定処理を実行させることを特徴とするプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010002675A JP2011141789A (ja) | 2010-01-08 | 2010-01-08 | 情報処理装置及び情報処理方法及びプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010002675A JP2011141789A (ja) | 2010-01-08 | 2010-01-08 | 情報処理装置及び情報処理方法及びプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2011141789A true JP2011141789A (ja) | 2011-07-21 |
Family
ID=44457574
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2010002675A Pending JP2011141789A (ja) | 2010-01-08 | 2010-01-08 | 情報処理装置及び情報処理方法及びプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2011141789A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2015197752A (ja) * | 2014-03-31 | 2015-11-09 | 富士通株式会社 | 処理管理プログラム、処理管理装置及び処理管理方法 |
-
2010
- 2010-01-08 JP JP2010002675A patent/JP2011141789A/ja active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2015197752A (ja) * | 2014-03-31 | 2015-11-09 | 富士通株式会社 | 処理管理プログラム、処理管理装置及び処理管理方法 |
US9881046B2 (en) | 2014-03-31 | 2018-01-30 | Fujitsu Limited | Recording medium having stored therein process managing program, process managing apparatus and process managing method |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20210352098A1 (en) | System for automatically discovering, enriching and remediating entities interacting in a computer network | |
US8291382B2 (en) | Maintenance assessment management | |
US9064056B2 (en) | Completing functional testing | |
US8898178B2 (en) | Solution monitoring system | |
US10467081B2 (en) | Enabling symptom verification | |
US10909023B2 (en) | Function-message oriented test case generation for supporting continuous globalization verification testing | |
US8140578B2 (en) | Multilevel hierarchical associations between entities in a knowledge system | |
US20070250525A1 (en) | Model-Based Event Processing | |
US20100095273A1 (en) | Analysis of effects of a software maintenance patch on configuration items of a cmdb | |
US9563545B2 (en) | Autonomous propagation of system updates | |
US20080155336A1 (en) | Method, system and program product for dynamically identifying components contributing to service degradation | |
US20080301486A1 (en) | Customization conflict detection and resolution | |
US20060271924A1 (en) | Method and apparatus for automating updates to dependencies | |
US9098290B2 (en) | Method and apparatus for facilitating diagnostic logging for software components | |
US20100131315A1 (en) | Resolving incident reports | |
US11074119B2 (en) | Automatic root cause analysis for web applications | |
US8539474B2 (en) | Method and system for management of interim software fixes | |
US20080126283A1 (en) | Method of capturing Problem Resolution for Subsequent Use in Managed Distributed Computer Systems | |
US7716531B2 (en) | System and method for fault mapping of exceptions across programming models | |
US8196102B2 (en) | Software supportability certification | |
US8438542B2 (en) | Generating a management pack at program build time | |
JP2011141789A (ja) | 情報処理装置及び情報処理方法及びプログラム | |
JP4510040B2 (ja) | インストール支援装置及びインストール支援プログラム及びインストール支援方法 | |
US11645137B2 (en) | Exception management in heterogenous computing environment | |
JP2012168687A (ja) | 情報処理装置及び情報処理方法及びプログラム |