JP6375679B2 - サーバ情報管理装置，サーバ情報管理プログラム，及びサーバ情報管理方法 - Google Patents

Description

本発明は、サーバ情報管理装置，サーバ情報管理プログラム，及びサーバ情報管理方法に関する。

データセンタは、例えば、ユーザからデータやサーバを預かり、インターネットへの接続回線や保守運用サービスなどを提供する施設として機能する。データセンタは、複数の業務システム（サーバ群）から構築され、各業務システムは、相互に通信可能に接続された複数種類のサーバ（ノード）を含む。例えば、各業務システムは、ウエブ（Ｗｅｂ）サーバ，アプリケーション（ＡＰ）サーバ，データベース（ＤＢ）サーバからなる３階層構造を有する。なお、以下では、業務システムを構成する各サーバがＷｅｂサーバ，ＡＰサーバ，ＤＢサーバのいずれであるかを示す情報のことを、「サーバ種別」または「サーバの属性」または「サーバの役割」という場合がある。また、上述した３種類のサーバ種別は、それぞれＷｅｂ，ＡＰ，ＤＢと表記する。

上述のようなデータセンタでは、システムの大規模化に伴い、管理コストを低減する自動運用ソフトウェア（例えばＲＢＡ (run book automation))が用いられる。ＲＢＡのような管理ツールでは、操作対象サーバが業務システム単位や役割単位で認識され、認識された操作対象サーバの自動運用が種々のフローに従って実行される。各「フロー」は、運用の最小単位である「部品」を用いて作成される。「部品」としては、例えば「構成情報の抽出」を行なう部品や「サービス起動確認」を行なう部品が挙げられる。

図２７は「フロー」の一例として業務システム単位に汎用化された正常稼働確認フローを示す。図２７に示すフローは、「サーバ抽出」を行なう部品と「サービス起動確認」を行なう部品とを交互に配置して作成されている。そして、図２７における３つの「サーバ抽出」部品はそれぞれＷｅｂサーバ，ＡＰサーバ，ＤＢサーバを抽出し、抽出された各サーバについて「サービス起動確認」部品がサービス起動確認を行なう。

ところで、近年、システムのクラウド化に伴い、既存の業務システムに対するサーバの追加（導入）が頻繁に行なわれるようになっている。既存の業務システムにサーバが追加された場合、上述のようなフローを実行すべく、追加されたサーバの役割を判別する必要がある。このとき、追加サーバの役割の判別は、上述した管理ツールによって、以下のように行なうことが可能である。つまり、既存の業務システムにサーバが追加されると、管理ツールは、サーバの追加を検知し、追加されたサーバと他のサーバとの通信状況に基づき、追加されたサーバの役割を判別する。

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

上述したように、追加されたサーバの役割を、追加されたサーバと他のサーバとの通信状況に基づいて判別すると、図２８を参照しながら以下に説明するような不具合が生じる場合がある。図２８は当該不具合について説明する図である。図２８に示す例では、管理サーバによって管理される業務サーバとして６台のサーバＳ１〜Ｓ６が備えられている。既存の業務システム（サーバ群）Ａは、ＷｅｂサーバＳ１，ＡＰサーバＳ２およびＤＢサーバＳ３から構成されている。また、既存のＷｅｂサーバＳ４およびＤＢサーバＳ６を有する業務システム（サーバ群）Ｂでは、ＡＰサーバＳ５を動的に追加すべくＡＰサーバＳ５のセットアップ作業が実行中であるとする。なお、この時点で、管理サーバは、サーバＳ５の追加を検知することは可能であるが、追加されるサーバＳ５の種別がＡＰであることや、サーバＳ５が業務システムＢに属していることは認識できていない。

追加サーバＳ５のセットアップ中には、図２８の下段に示すように、追加サーバＳ５から他の業務システムＡに属するＡＰサーバＳ２の情報を参照する通信が行なわれる場合がある。当該通信は、セットアップ済みのＡＰサーバＳ２における情報（環境等）を、追加サーバＳ５のセットアップの参考に用いる際に生じることがある。このような通信が生じると、追加されるＡＰサーバＳ５の通信状況に、当該サーバＳ５の属する業務システムＢとは異なる業務システムＡにおけるＡＰサーバＳ２との通信が混じり込む。その結果、通信状況から判定される追加サーバＳ５の役割と、他サーバの構成情報（役割等）から判定される追加サーバＳ５の役割との間に矛盾が発生する。

つまり、管理サーバは、業務システムＢに追加されるサーバＳ５を、業務システムＡに属するＤＢサーバと誤認して構成情報に登録してしまう。このため、管理サーバは、業務システムＡに対する正常稼働確認フローを実行する際、図２８の上段に示すように、業務システムＢに属するＡＰサーバＳ５をＤＢサーバとして抽出し、誤認された追加サーバＳ５に対しフロー制御（サービス起動確認）を実行することになる。したがって、管理サーバは、業務システムＡに対する正常稼働確認フローを正しく実行することができない。

また、このとき、追加サーバＳ５は、セットアップ中でありサービスを提供できない状態であるにもかかわらず、正常稼働確認フローの操作対象（ＤＢサーバ）として抽出されてしまう。このため、たとえ追加サーバＳ５の役割等が正確に判別されたとしても、管理サーバは、サービスの提供を行なえないセットアップ中の追加サーバＳ５に対しフロー制御（例えばサービス起動確認）を実行し、追加サーバＳ５が異常状態（エラー）であると誤認するおそれがある。

一つの側面で、本発明は、業務システムに追加されるサーバの属性を正確に判別することを目的とする。

本件のサーバ情報管理装置は、検知部および第１特定部を有する。前記検知部は、管理対象のシステムへのサーバの追加を検知する。前記第１特定部は、追加を検知された追加サーバの通信状況としてのセットアップログファイルに含まれるセットアップ時の通信ログと、前記追加サーバに関する管理情報と、前記追加サーバの通信先サーバに関する管理情報とに基づき、前記追加サーバの属性を特定する。

業務システムに追加されるサーバの属性が正確に判別される。

本実施形態のサーバ情報管理装置（管理サーバ）のハードウェア構成例および機能構成例を示すブロック図である。 本実施形態の管理サーバの機能および動作を概略的に説明する図である。 本実施形態の分析処理部（第１特定部および第２特定部）による、送受信先サーバのサーバ種別および稼働状態を抽出する機能を説明する図である。 サーバ種別の決定理由を説明する図である。 サーバの稼働状態を説明する図である。 本実施形態のサーバ種別決定リストを説明する図である。 本実施形態の分析処理部（第１特定部）による、サーバを追加される業務システムのサーバ構成を判断する機能を説明する図である。 本実施形態における業務システムの稼働状況判定テーブルの一例を示す図である。 本実施形態の分析処理部（設定部）による、サーバ間の関係性情報を設定する機能を説明する図である。 本実施形態の管理サーバの第１動作例を説明する図である。 本実施形態の分析処理部（判断部）による、ｈｔｔｐリクエスト結果による業務システムの状態判断を説明する図 本実施形態の分析処理部（判断部）による、ダイジェスト認証のリクエスト結果による業務システムの状態判断を説明する図である。 本実施形態の管理サーバの第２動作例を説明する図である。 本実施形態の管理サーバによる処理全体の概要を説明するフローチャートである。 本実施形態の管理サーバ（実行部）による、構成情報の最新化処理を説明するフローチャートである。 本実施形態の管理サーバ（実行部および分析処理部）による、汎用化されたフローの実行処理を説明するフローチャートである。 本実施形態の分析処理部（検知部）による、追加サーバの判断処理を説明するフローチャートである。 本実施形態の分析処理部による処理の概要を説明するフローチャートである。 本実施形態の分析処理部による、送受信先ノードのサーバ種別／稼働状態取り出し処理を説明するフローチャートである。 本実施形態の分析処理部（第１特定部）による、業務システム構成を特定する処理を説明するフローチャートである。 本実施形態の分析処理部（第１特定部，第２特定部，設定部）による、追加サーバのサーバ種別を特定する処理、および、追加サーバの属する業務システムを決定する処理を説明するフローチャートである。 本実施形態の分析処理部（第２特定部）による、業務システムの状態判定処理を説明するフローチャートである。 本実施形態の分析処理部（判断部および設定部）による、業務システムのサービス利用可能状態の判断処理を説明するフローチャートである。 本実施形態の分析処理部（判断部）による、業務システムのＷｅｂサーバの応答／無応答を判断する処理を説明するフローチャートである。 本実施形態の分析処理部（判断部）による、業務システムのサービス利用可能／不可能を判断する処理を説明するフローチャートである。 本実施形態における構成情報の関係を示すとともにフロー実行履歴およびサーバ種別決定リストを示す図である。 業務システム単位に汎用化された正常稼働確認フローを示す図である。 追加されたサーバの役割を追加されたサーバの通信状況に基づいて判別することで生じる不具合について説明する図である。

以下に、図面を参照し、本願の開示するサーバ情報管理装置，サーバ情報管理プログラム，及びサーバ情報管理方法の実施形態について、詳細に説明する。ただし、以下に示す実施形態は、あくまでも例示に過ぎず、実施形態で明示しない種々の変形例や技術の適用を排除する意図はない。すなわち、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。また、各図は、図中に示す構成要素のみを備えるという趣旨ではなく、他の機能を含むことができる。そして、各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

〔１〕本実施形態の管理サーバの基本的な構成／機能／動作
まず、図１，図２および図２６を参照しながら、本実施形態のサーバ情報管理装置（以下「管理サーバ」という）１の基本的な構成／機能／動作について説明する。図１は、本実施形態の管理サーバ１のハードウェア構成例および機能構成例を示すブロック図である。図２は、本実施形態の管理サーバ１の機能および動作を概略的に説明する図である。図２６は、本実施形態における構成情報の関係を示すとともにフロー実行履歴およびサーバ種別決定リスト２３を示す図である。

図１に示すように、管理サーバ１は、複数（図中６台）のサーバＳ１〜Ｓ６を有する業務サーバ２を管理する。管理サーバ１は、ＰＣ（Personal Computer）等のコンピュータである。管理サーバ１は、少なくとも、ＣＰＵ（Central Processing Unit），ＭＰＵ（Micro-Processing Unit）等の処理部（プロセッサ）１０と、ＲＡＭ（Random Access Memory），ＨＤＤ（Hard Disk Drive），ＳＳＤ（Solid State Device）等の記憶部（メモリ）２０とを有している。

処理部１０は、記憶部２０から所定のアプリケーションプログラム（サーバ情報管理プログラム）を読み出して実行することで、後述する実行部１１および分析処理部１２としての機能を果たす。さらに、分析処理部１２は、後述する検知部１２１，第１特定部１２２，第２特定部１２３，設定部１２４，判断部１２５，抽出部１２６としての機能を果たす。

なお、前記所定のアプリケーションプログラムは、例えばフレキシブルディスク，ＣＤ（ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−ＲＷなど），ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−Ｒ，ＤＶＤ−ＲＷ，ＤＶＤ＋Ｒ，ＤＶＤ＋ＲＷなど），ブルーレイディスク等のコンピュータ読取可能な記録媒体に記録された形態で提供される。この場合、処理部１０は、当該記録媒体からプログラムを読み取って内部記憶装置または外部記憶装置としての記憶部２０に転送し格納して用いる。

記憶部２０は、前記所定のアプリケーションプログラムを保存するほか、処理部１０による処理に必要な各種情報等を保存する。例えば、記憶部２０は、前記各種情報等として、後述する構成情報データベース２１，フロー実行履歴データベース２２，サーバ種別決定リスト２３，稼働状況判定テーブル２４，セットアップログ格納領域２５を保存する。なお、以下では、業務システムの構成情報を格納する「構成情報データベース」をＣＭＤＢ（Configuration Management DataBase；構成管理データベース）と表記する。

管理サーバ１の管理対象であるサーバＳ１〜Ｓ６のうち、サーバＳ１，Ｓ４の種別（属性，役割）はＷｅｂであり、サーバＳ２，Ｓ５の種別はＡＰであり、サーバＳ３，Ｓ６の種別はＤＢである。サーバＳ１〜Ｓ３は、既存の稼働中の業務システム（サーバ群）Ａを構成している。サーバＳ４〜Ｓ６は、セットアップ中の業務システムＢを構成している。

本実施形態の管理サーバ１による処理開始時点において、ＷｅｂサーバＳ４およびＤＢサーバＳ６を配備済みの業務システムＢに対し、ＡＰサーバ（追加サーバ）Ｓ５を追加する作業（セットアップ）が実行されているものとする。したがって、当該時点において、サーバＳ１〜Ｓ４，Ｓ６に係る構成情報等はＣＭＤＢ２１に既に設定されており、サーバＳ１〜Ｓ４，Ｓ６の属する業務システムは特定されている。しかし、追加サーバＳ５の種別は未だ特定されておらず、追加サーバＳ５に係る構成情報はＣＭＤＢ２１に未設定であり、追加サーバＳ５の属する業務システム（つまり業務システムＡ，Ｂのいずれに属するか）は未だ特定されていないものとする。

本実施形態の管理サーバ１の処理概要は、以下の通りである。つまり、「業務システム単位に汎用化されたフロー」（例えば図２７参照）の「対象サーバ抽出」部品によって操作対象サーバが抽出されると、本実施形態の管理サーバ１は、大きく分けて以下の３つの処理(11)〜(13)を実行する。

(11)管理サーバ１は、「対象サーバ抽出」部品によって抽出される操作対象サーバが、「追加サーバ」であるか否かを自動的に判断する。

(12)管理サーバ１は、「追加サーバ」の種別（分析，役割）を特定し、「追加サーバ」の属する業務システムのサーバ構成を特定するとともに、「追加サーバ」の属する業務システム（サーバ群）を特定する。

(13)管理サーバ１は、「追加サーバ」の属する業務システムのサービス利用可能状態を把握する。

上述した処理(11)〜(13)を実行すべく、管理サーバ１は、以下のような機能を有している。以下、管理サーバ１における、実行部１１および分析処理部１２（検知部１２１，第１特定部１２２，第２特定部１２３，設定部１２４，判断部１２５，抽出部１２６）の基本的な機能／動作について、説明する。

実行部１１は、例えば図２７を参照しながら前述した正常稼働確認フロー等のフローを操作対象サーバに実行させるとともに、当該フローの実行履歴を記憶部２０のフロー実行履歴ＤＢ２２に格納する。実行部１１は、ＣＭＤＢ２１における構成情報を最新化すべく、管理対象の業務サーバ２から構成情報を定期的に自動収集する（図２の矢印ａ１１，ａ１２参照）。

なお、フローの実行履歴には、図２６に示すように、操作ノード名（操作対象サーバのサーバ名），実行フロー名，フローの実行日付，フローの実行結果が含まれるほか、操作対象サーバ種別，操作対象サーバ総数が含まれる。

また、ＣＭＤＢ２１には、図２６に示すように、ある業務システムに属するサーバに係る構成情報が、サーバ毎に、当該業務システムの業務システム名に関連付けられて保存される。各サーバに係る構成情報には、以下のような情報(21)〜(23)が含まれる。

(21)サーバ種別： 例えばＡＰ，Ｗｅｂ，ＤＢ等のサーバ種別
(22)サーバ間の関係性情報： 例えば「ＩＰ（Internet Protocol）アドレス192.168.0.2のノードは、ＩＰアドレス192.168.0.1のＷｅｂサーバおよびＩＰアドレス192.168.0.3のＤＢサーバと接続し、３階層構造を成す関係性にある」といった情報を、ＣＭＤＢ２１上のリレーションとしてもつ。なお、図２６中では、矢印ａ３１，ａ３２によって、サーバ間の関係性情報が示されている。
(23)業務システム情報： ３階層システム、セットアップ有無などの情報を、ＣＭＤＢ２１上のリレーションとしてもつ。

また、ＣＭＤＢ２１には、新規ノード検出時には、下記の構成情報(31)〜(33)が格納されている。
(31)ノード情報： ＩＰアドレス
(32)システム情報： ハードウェア構成情報やインストール済みソフトウェアなど
(33)システム設定： Ｗｅｂ同時アクセス数，認証ユーザ，ＤＢセッション数など

分析処理部１２は、記憶部２０に予め格納されるサーバ種別決定リスト２３や、フロー実行履歴に基づき、ＣＭＤＢ２１に、サーバ間の関係性情報を格納する処理を行なう。なお、サーバ種別決定リスト２３は、図６を参照しながら後述するごとく、送信先サーバ種別および受信元サーバ種別からサーバ種別を決定するために用いられるもので、サーバ種別ＡＰ，ＤＢ，Ｗｅｂのそれぞれについて作成される。なお、サーバ種別決定リスト２３には、インストール済みソフトウェアの名称や、当該ソフトウェアが出力するセットアップログファイルの格納先（セットアップログ位置）や、稼働確認情報などが含まれる（図２６参照）。

検知部１２１は、管理対象の業務システムへのサーバＳ５の追加を検知する、つまり、管理対象の業務システムにおいてサーバ追加が実行されていることを検知する。このとき、検知部１２１は、前述したように、実行フローの「対象サーバ抽出」部品によって操作対象サーバが抽出されると、当該操作対象サーバが追加サーバであるか否かを判断することで、追加サーバＳ５を検知する。なお、検知部１２１の詳細な機能／動作については、下記項目〔２−１〕において説明する。

第１特定部１２２は、検知部１２１によって追加を検知された追加サーバＳ５の通信状況と、追加サーバＳ５に関する管理情報と、追加サーバＳ５の通信先サーバに関する管理情報とに基づき、追加サーバＳ５の属性（役割／種別）を特定する。なお、追加サーバＳ５の通信先サーバ（通信先ノード）としては、追加サーバＳ５から情報を送信される送信先サーバ（送信先ノード）と、追加サーバＳ５へ情報を送信する受信元サーバ（受信元ノード）とがある。以下の説明では、送信先サーバ（送信先ノード）と受信元サーバ（受信元ノード）との２つをまとめて「通信先サーバ（通信先ノード）」または「送受信先サーバ（送受信先ノード）」という。

このとき、追加サーバＳ５の通信状況は、例えば、セットアップログファイルに含まれるセットアップ時の通信ログを含む。追加サーバＳ５に関する管理情報は、例えば、追加サーバＳ５へのインストール済みソフトウエア情報を含む。追加サーバＳ５の通信先サーバに関する管理情報は、送受信先サーバの構成情報を含む。

特に、第１特定部１２２は、下記２種類の手法で特定された追加サーバＳ５の属性(41)と属性(42)とが一致するか否かを判断し、当該２つの属性(41), (42)が一致する場合、当該属性(41), (42)を、追加サーバＳ５の属性として特定する。ここで、属性(41)は、追加サーバＳ５に関する構成情報に含まれる追加サーバＳ５へのインストール済みソフトウエア情報に基づき特定される追加サーバＳ５の属性（下記手順〔２−１−２〕参照）である。属性(42)は、追加サーバＳ５の通信状況および送受信先サーバに関する構成情報に基づき特定される追加サーバＳ５の属性（下記手順〔２−２−３〕の(71)〜(73)参照）である。

なお、第１特定部１２２の詳細な機能／動作については、下記項目〔２−１〕，〔２−２〕において、図３〜図７を参照しながら説明する。

第２特定部１２３は、第１特定部１２２によって特定された追加サーバＳ５の属性と当該追加サーバＳ５の送受信先サーバの属性および稼動状態と当該送受信先サーバに接続される既存サーバの属性および稼動状態（下記手順〔２−２−３〕の(74),(75)）とに基づき、前記追加サーバの属する業務システムを特定する（下記手順〔２−２−４〕の(82)〜(84)参照）。なお、以下では、当該追加サーバＳ５の送受信先サーバに接続される既存サーバのことを、当該追加サーバＳ５に関連するという意味で、「関連サーバ」という。

特に、第２特定部１２３は、追加サーバＳ５の属性と送受信先サーバの属性および稼動状態と追加サーバＳ５の関連サーバの属性および稼動状態とに基づき、関連サーバを含む既存の業務システムが運用可能状態であるか否かを判断する。そして、第２特定部１２３は、既存の業務システムが運用可能状態であると判断した場合、当該既存の業務システムを追加サーバＳ５の属する業務システムとして特定する。このとき、第２特定部１２３は、例えば、記憶部２０に予め保存されている稼働状況判定テーブル２４を用いて、既存の業務システムが運用可能状態であるか否かの判断を行なう。なお、第２特定部１２３の詳細な機能／動作および稼働状況判定テーブル２４については、下記項目〔２−２〕において、図３〜図８を参照しながら説明する。

設定部１２４は、第２特定部１２３によって特定された、追加サーバＳ５の属する業務システムおよび追加サーバＳ５の送受信先サーバと、追加サーバＳ５とを関連付け、追加サーバＳ５に関する管理情報（追加サーバＳ５の構成情報）として設定する（下記手順〔２−２−５〕参照）。なお、第２特定部１２３による業務システム特定時における設定部１２４の詳細な機能／動作については、下記項目〔２−２−５〕において、図９を参照しながら説明する。

判断部１２５は、第２特定部１２３によって特定された、追加サーバＳ５の属する業務システムがサービス利用可能状態であるか否かを判断する（下記手順〔２−３−１〕および〔２−３−２〕参照）。特に、判断部１２５は、当該業務システムに属するＷｅｂサーバが応答可能であり、且つ、当該業務システムに対するログインが可能である場合、サービスを利用可能な状態であると判断する。なお、判断部１２５の詳細な機能／動作については、下記項目〔２−３〕において、図１１および図１２を参照しながら説明する。

抽出部１２６は、判断部１２５によってサービス利用可能状態であると判断された場合、当該業務システムに属する追加サーバＳ５と当該追加サーバＳ５の送受信先サーバとを操作対象サーバとして抽出する（下記手順〔２−３〕および〔２−３−３〕参照）。抽出部１２６としての機能は、図２７を参照しながら前述した正常稼働確認フローを成す「サーバ抽出」部品によって実現されてもよい。なお、抽出部１２６の詳細な機能／動作については、下記項目〔２−３〕において説明する。

設定部１２４は、判断部１２５によって業務システムがサービス利用可能状態であると判断された場合、追加サーバＳ５に関する構成情報における追加サーバＳ５の稼動状態を稼動可能に設定する。一方、サービス利用可能状態でないと判断された場合、設定部１２４は、追加サーバＳ５に関する構成情報における追加サーバＳ５の稼動状態に対する設定を行なわない、もしくは、当該稼働状態を稼動不可に設定する。なお、判断部１２５による判断結果に対する設定部１２４の詳細な機能／動作については、下記項目〔２−３〕において説明する。

なお、記憶部２０におけるセットアップログ格納領域２５には、下記項目〔２−２−１〕において説明するように、追加サーバと判断された操作対象サーバから、分析処理部１２によって抽出されたセットアップログファイルが格納される（図２の矢印ａ１３参照）。

〔２〕本実施形態の管理サーバの詳細な機能／動作
次に、図３〜図１３を参照しながら、本実施形態の管理サーバ１の詳細な機能／動作について説明する。

〔２−１〕サーバ追加の自動判断
まず、実行部１１が「業務システム単位に汎用化されたフロー」の「対象サーバ抽出」部品を実行すると、分析処理部１２は、当該部品によって抽出された操作対象サーバが「追加されたサーバ」か否かを自動的に判断する。このとき、分析処理部１２において、検知部１２１が、ＣＭＤＢ２１における構成情報、および、フロー実行履歴ＤＢ２２における実行履歴に基づき、以下の手順〔２−１−１〕〜〔２−１−４〕で、追加サーバ（本実施形態では図１，図２のサーバＳ５）を検知する。

〔２−１−１〕実行部１１が自動収集によりノードを検出する。
実行部１１は、スケジューリングによって、管理対象の業務サーバ２（サーバＳ１〜Ｓ６）の構成情報について定期的な自動収集を実行することで（図２の矢印ａ１１，ａ１２参照）、ＣＭＤＢ２１における構成情報を常に最新状態に保っている。定期的な自動収集によって新たなノードが検出されると、ＣＭＤＢ２１には、上述した構成情報(31)〜(33)が格納される。ここでは、ノード情報(31)であるＩＰアドレスとしては、例えば、192.168.0.4が格納される。

〔２−１−２〕分析処理部１２（第１特定部１２２）が操作対象サーバ種別のノードを抽出する。
実行部１１によってフローが実行されると、分析処理部１２は、操作対象サーバを絞り込むために、構成情報の「インストール済みソフトウェア」に基づき、業務サーバ２に含まれる各サーバＳ１〜Ｓ６の「サーバ種別」を特定する。そして、分析処理部１２は、「インストール済みソフトウェア」に基づいて特定したサーバ種別を参照し、「対象サーバ抽出」部品が要求するサーバ種別（例えばＡＰ）のノード（サーバ）を抽出する。分析処理部１２は、「対象サーバ抽出」部品が要求するサーバ種別のノードを抽出できない場合、別のサーバ種別（例えばＡＰ以外のＷｅｂまたはＤＢ）のノードを抽出する。全てのサーバ種別についてノードを抽出できない場合、分析処理部１２は、抽出処理を終了する。

〔２−１−３〕分析処理部１２（検知部１２１）が、手順〔２−１−２〕で抽出したノードが追加サーバか否かを判断する。
分析処理部１２（検知部１２１）は、手順〔２−１−２〕で抽出した操作対象ノードについて、以下の４つの条件(51)〜(54)の全てが満たされている場合、手順〔２−１−２〕で抽出した操作対象ノードが追加サーバであると判断することができる。なお、操作対象ノードが追加サーバである場合、分析処理部１２は、項目〔２−２〕以降の処理を実行する。一方、操作対象ノードが追加サーバでない場合、分析処理部１２は、項目〔２−２〕以降の処理を実行することなく、実行部１１が、操作対象ノードに対し通常のフロー制御を行なう。

(51)抽出した操作対象ノードの構成情報に「業務システム」の設定がない場合、かつ
(52)抽出した操作対象ノードの構成情報に「サーバ種別」の設定がない場合、かつ
(53)抽出した操作対象ノードがフロー実行履歴に「操作ノード名」として記録されていない場合、かつ
(54)抽出した操作対象ノードについての「実行結果」がフロー実行履歴に記録されていない場合。

〔２−１−４〕分析処理部１２がＣＭＤＢ２１にサーバ種別を設定する。
分析処理部１２は、操作対象ノードが追加サーバである場合、手順〔２−１−２〕で抽出した操作対象ノード（追加サーバ）について、「インストール済みソフトウェア」に基づいて特定したサーバ種別をＣＭＤＢ２１に設定する。

〔２−２〕業務システムのサーバ構成およびサーバ種別の分析
検知部１２１が追加サーバを検知した場合、分析処理部１２は、当該追加サーバのセットアップログファイルとＣＭＤＢ２１における構成情報とを解析することによって、当該追加サーバのサーバ種別と当該追加サーバの属する一の業務システムとを抽出する。また、分析処理部１２は、抽出した業務システムのサーバ間の関係性を確認し、セットアップログに基づき特定した「サーバ種別」および「業務システム」が正しいことを確認する。そして、分析処理部１２は、確認した「サーバ種別」を、構成情報におけるソフトウェア情報と、セットアップログにおける通信状況（通信ログ）と、ＣＭＤＢ２１に格納されている業務システムのサーバ構成情報とに基づき確定する。この後、分析処理部１２（設定部１２４）は、確定したサーバ間の関係性情報と追加サーバに関する情報をＣＭＤＢ２１に設定する。なお、設定の際の追加サーバの状態は「不明」として登録設定される。

なお、通常、業務システムとして構築される３階層構造では、セットアップ時に、ＷｅｂサーバはＡＰサーバに、ＡＰサーバはＤＢサーバに、ＤＢサーバはＡＰサーバに対し接続およびデータ送受信を行なう。セットアップログには、各サーバの接続先つまり/データの送受信先のノード情報（ＩＰアドレス）が記録される。例えば、ＩＰアドレス192.168.0.4の追加サーバ（ＡＰサーバ）のセットアップログには、“To 192.168.0.3 ＳＱＬ（Structured Query Language）発行”や“From 192.168.0.1 レスポンス”が記録される。ここで、前者のログは、当該追加サーバの送信先サーバのＩＰアドレスが192.168.0.3（ＤＢサーバ）であることを示す。また、後者のログは、当該追加サーバの受信元サーバのＩＰアドレスが192.168.0.1（Ｗｅｂサーバ）であることを示す。

分析処理部１２（第１特定部１２２および第２特定部１２３）は、以下の手順〔２−２−１〕〜〔２−２−５〕で、当該追加サーバのサーバ種別を特定するとともに、追加サーバの属する一の「業務システム」を特定する。

〔２−２−１〕分析処理部１２が追加サーバのセットアップログを抽出する。
つまり、分析処理部１２は、業務システム構成を判断するために、手順〔２−１−３〕で追加サーバであると判断されたノード（操作対象サーバ）から、当該ノードのセットアップログファイルを抽出する（図２の矢印ａ１３参照）。抽出されたセットアップログファイルは、記憶部２０におけるセットアップログ格納領域２５に格納される。

〔２−２−２〕分析処理部１２が、ＣＭＤＢ２１から、追加サーバと送受信関係にある送受信先ノードの「サーバ種別」等を抽出する。つまり、分析処理部１２は、以下の手順(61)〜(64)で、手順〔２−２−１〕で抽出したセットアップログを解析し、送信先／受信元ノードの「サーバ種別」および「稼働状態」をＣＭＤＢ２１から抽出する。

(61)分析処理部１２は、追加サーバのセットアップログから、送信先／受信元ノードの情報（ＩＰアドレス）を抽出する（図３の矢印ａ２１およびａ２２参照）。

(62)分析処理部１２は、手順(61)で抽出したノード情報に基づき、ＣＭＤＢ２１から送信先／受信元ノードの「サーバ種別」および「稼働状態」を抽出する（図３の矢印ａ２１およびａ２２参照）。図３に示す例では、送信先ノードの「サーバ種別」および「稼働状態」としてそれぞれ「ＤＢ」および「稼働中」が抽出され、受信元ノードの「サーバ種別」および「稼働状態」としてそれぞれ「Ｗｅｂ」および「稼働中」が抽出される。

(63)分析処理部１２は、手順(62)で抽出した送信先／受信元ノードの「サーバ種別」および「稼働状態」を、後述する手順〔２−２−４〕で用いるために、記憶部２０の所定領域等に記録する。「サーバ種別」および「稼働状態」の情報が構成情報に設定されていない場合、分析処理部１２は、「サーバ種別」および「稼働状態」を「不明」として記録する。

なお、図３は、本実施形態の分析処理部１２（第１特定部１２２および第２特定部１２３）による、送受信先サーバのサーバ種別および稼働状態を抽出する機能を説明する図である。図３に示すＣＭＤＢの構成情報においては、項目〔２−１〕で検知された追加サーバについて、手順〔２−１−２〕で抽出されたサーバ種別（ＡＰ）が、手順〔２−１−４〕で設定されている。また、図３に示すＣＭＤＢの構成情報においては、稼働中の業務システムに属するサーバＳ１，Ｓ２，Ｓ３に係る情報も設定されている。

ここで、図４を参照しながら、サーバ種別を決定する理由について説明するとともに、図５を参照しながら、サーバの稼働状態について説明する。

図４に示すように、対象サーバの「サーバ種別」がＷｅｂサーバ，ＡＰサーバ，ＤＢサーバのいずれであるかは、サーバ種別決定リスト２３（図６を参照しながら後述）内のソフトウェア情報や、サーバ間の関係性によって決定される。対象サーバにソフトウェアがインストールされていないなどの理由で「サーバ種別」が未決定の場合、対象サーバの「サーバ種別」は「不明」に設定される。

また、図５に示すように、サーバの稼働状態「不明」は、セットアップ中などの理由で、稼働状態の判定ができていない状態である（追加サーバについては、稼働状態が確認されるまで稼働状態は「不明」となる）。稼働状態「稼働可能」には、３つの状態「稼働中」，「停止中」，「メンテナンス中」がある。稼働状態「稼働中」は、サーバが、決められた役割（ＤＢまたはＡＰまたはＷｅｂ）を果たしている状態である。稼働状態「停止中」は、サーバが、決められた役割（ＤＢまたはＡＰまたはＷｅｂ）を果たしていない状態である。稼働状態「メンテナンス中」は、ユーザが何らかの理由でメンテナンスを行なっている状態である。

〔２−２−３〕分析処理部１２が、通信ログに基づき、業務システム構成を判断する。つまり、分析処理部１２（第１特定部１２２）は、以下の手順(71)〜(75)で、手順〔２−２−１〕で抽出されたセットアップログの通信ログを解析し、追加先の業務構成、つまり追加サーバを追加される業務システムのサーバ構成を判断する。

なお、以下では、図７を参照しながら、手順(71)〜(75)について説明する。図７は、本実施形態の分析処理部１２（第１特定部１２２）による、追加サーバを追加される業務システムのサーバ構成（業務システム構成）を判断する機能を説明する図である。図７においては、運用中の業務システムＡ（図２参照）に、追加サーバとしてのＡＰサーバＳ５（図２参照）を追加する例が示されている。

(71)分析処理部１２は、追加サーバのセットアップログにおける通信ログから当該追加サーバの送受信先ノードの通信方向情報Ｄ１，Ｄ２（図７参照）を抽出する。

(72)分析処理部１２は、ＣＭＤＢ２１から送受信先ノードの「サーバ種別」を抽出する。このとき、分析処理部１２は、通信方向情報Ｄ１に基づき、受信元ノード（ＩＰアドレス192.169.0.1）のサーバ種別「Ｗｅｂサーバ」を抽出する（図７の矢印Ａ１，Ａ３参照）。また、分析処理部１２は、通信方向情報Ｄ２に基づき、送信先ノード（ＩＰアドレス192.169.0.3）のサーバ種別「ＤＢサーバ」を抽出する（図７の矢印Ａ２，Ａ４参照）。

(73)分析処理部１２は、上記手順(72)で抽出した、送受信先ノードのサーバ種別をキーとして、サーバ種別決定リスト２３を検索することで、通信宛先および通信方向から、「サーバ間の関係性」を判断する。これにより、追加サーバを追加される業務システムの階層構造（３階層など）と追加サーバのサーバ種別とが判断される（図７の矢印Ａ５，Ａ６）。図７に示す例では、追加サーバのサーバ種別はＡＰサーバであると判断され（矢印Ａ７参照）、追加サーバを追加される業務システムは、Ｗｅｂサーバ，ＡＰサーバ，ＤＢサーバから成る３階層構造であると判断される。

(74)分析処理部１２は、送受信先ノードと関係のあるノードのうち、追加サーバと同じサーバ種別のノード（既存サーバ，関連サーバ）を、ＣＭＤＢ２１から抽出するとともに、当該ノードの稼働状態を取得する。図７に示す例では、ＩＰアドレス192.168.0.2のＡＰサーバＳ２が関連サーバとして抽出され、当該ＡＰサーバＳ２の稼働状態（稼働中）が取得される。

(75)分析処理部１２は、上記手順(73)で判断された追加サーバの「サーバ種別」と、上記手順(74)で取得した関連サーバの「稼働状態」とを、後述する手順〔２−２−４〕で用いるために、記憶部２０の所定領域等に記録する。通信方向情報に基づき送受信先ノードを判断できない場合や、追加サーバを追加される業務システムの階層構造を判断できない場合、分析処理部１２は、追加サーバの「サーバ種別」および関連サーバの「稼働状態」を「不明」として記録する。

以上のような手順により、追加サーバに対するデータの通信方向と、追加サーバの通信相手先ノードの情報とに基づいて、追加サーバの「サーバ種別」および「サーバ間の関係性」を自動判別でき、ひいては追加サーバの属する業務システム構成を自動判断することができる。

図７に示す例では、ＡＰサーバを操作対象の「追加サーバ」とした場合に、「追加サーバ」は、ＤＢサーバＳ３に対して送信し、ＷｅｂサーバＳ１から受信している。このような情報をサーバ種別決定リスト２３と照合し、「追加サーバ」は、３階層構造の業務システムのうちの「ＡＰサーバ」であると判断することができる。さらに、送受信相手のＷｅｂサーバＳ１およびＤＢサーバＳ３は、ＡＰサーバＳ２と関係を持っていることがＣＭＤＢ２１から抽出することができる。

なお、手順(73)で用いられるサーバ種別決定リスト２３には、図６に示すような情報が格納されている。図６は、本実施形態のサーバ種別決定リスト２３を説明する図である。サーバ種別決定リスト２３は、送信先サーバ種別および受信元サーバ種別からサーバ種別を決定するために用いられるものである。図６に示すように、サーバ種別決定リスト２３には、サーバ種別に、当該サーバ種別のサーバの送受信先となるサーバの送信先サーバ種別および受信元サーバ種別が対応付けられて保存されている。例えば図７に示すように、サーバ種別「ＡＰ」には、送信先サーバ種別「ＤＢ」および受信元サーバ種別「Ｗｅｂ」が対応付けられる。また、サーバ種別決定リスト２３には、インストール済みソフトウェアの名称，バージョン，パッチレベル，セットアップログファイルの格納先などの情報も含まれる。このようなサーバ種別決定リスト２３は、サーバ種別ＡＰ，ＤＢ，Ｗｅｂのそれぞれについて作成される。ソフトウェア情報は、必要な分だけ繰り返し記録されている。

〔２−２−４〕分析処理部１２（第１特定部１２２および第２特定部１２３）は、以下の手順(81)〜(84)で、追加サーバの「サーバ種別」を確定するとともに、追加サーバの属する業務システムを判断する。その際、上記手順〔２−２−２〕の(63)で記録された送信先／受信元ノードの「サーバ種別」および「稼働状態」と、手順〔２−２−３〕の(75)で記録された追加サーバの「サーバ種別」および関連サーバの「稼働状態」とが用いられる。

(81)分析処理部１２（第１特定部１２２）は、上記手順〔２−２−３〕の(73)で抽出された「サーバ種別」と、上記手順〔２−１−２〕で「インストール済みソフトウェア」に基づき決定された「サーバ種別」とが一致するか否かを判断する。これらの「サーバ種別」が一致しない場合、通信ログに基づいて判断される業務システム（追加サーバの属性）と、ＣＭＤＢ２１の構成情報に基づいて判断される業務システム（追加サーバの属性）との間に矛盾がある。このため、分析処理部１２は、上記手順〔２−１−２〕から再実行する。例えば、操作対象サーバをサーバ種別ＡＰに絞って上述の手順を実行した結果、「サーバ種別」が不一致の場合、分析処理部１２は、操作対象サーバを、ＡＰ以外のサーバ種別ＤＢまたはＷｅｂに絞って、上述の手順を再実行する。

(82)分析処理部１２（第２特定部１２３）は、上記手順(81)で２つの「サーバ種別」が一致すると判断された場合、つまり上記矛盾がなくなった場合、「追加サーバ」が属している業務システムの状態を判断する。その際、矛盾の無い追加サーバの「サーバ種別」と、上記手順〔２−２−２〕の(63)で記録された送信先／受信元ノードの「サーバ種別」および「稼働状態」と、上記手順〔２−２−３〕の(75)で記録された追加サーバの「サーバ種別」および関連サーバの「稼働状態」とが用いられる。上記手順(82)での判断は、図８に示す業務システムの稼働状況判定テーブル２４を用いて実行される。

(83)分析処理部１２（第２特定部１２３）は、上記手順(82)で既存の業務システムの運用状態が運用不可であると判断した場合、「追加サーバ」は既存のシステムに属さないと判断し、「追加サーバ」のＣＭＤＢ２１への反映を行なわない。

(84) 分析処理部１２（第２特定部１２３）は、上記手順(82)で既存の業務システムの運用状態が運用可能であると判断した場合、送受信先サーバの属する既存の「業務システム」（例えば業務システムＡ）をＣＭＤＢ２１から抽出し、「追加サーバ」の属し先「業務システム」とする。

ここで、上記手順(82)での判断、つまり業務システムの状態判定は、図８に示す業務システムの稼働状況判定テーブル２４を用いて実行される。図８は、本実施形態における業務システムの稼働状況判定テーブル２４の一例を示す図である。なお、図８では、上記手順〔２−１−２〕で「インストール済みソフトウェア」に基づき決定された追加サーバの「サーバ種別」が「ＡＰ」である場合の稼働状況判定テーブル２４が示されている。また、「サーバ種別」が「ＤＢ」または「Ｗｅｂ」である場合の稼働状況判定テーブル２４も、同様に作成されている。

分析処理部１２（第２特定部１２３）は、手順〔２−１−２〕で決定された追加サーバの「サーバ種別」と、手順〔２−２−２〕で抽出された送信先／受信元ノードの「サーバ種別」および「稼働状態」と、手順〔２−２−３〕で抽出された追加サーバの「サーバ種別」および関連サーバの「稼働状態」とをキーにして、テーブル２４を検索する。これによって、分析処理部１２（第２特定部１２３）は、追加サーバを追加される既存の業務システムの運用状態（運用不可か運用可能か）を判断する。

図８に示す稼働状況判定テーブル２４では、下記条件(91)と下記条件(92)との両方を満たす場合、追加サーバの属する既存の「業務システム」の運用状態は「運用可能」状態であると判断される（図８の太線枠参照）。それ以外の場合、追加サーバの属する既存の「業務システム」の運用状態は「運用不可」状態であると判断される。

(91)上記手順〔２−２−２〕で抽出された送信先サーバおよび受信元サーバのうち、いずれかの「サーバ種別」に「不明」以外の運用可能なサーバ種別が設定されており、且つ、「稼働状態」に「稼働可能」状態が設定されていること。
(92)上記手順〔２−２−３〕で抽出された同種の「サーバ種別」の関連サーバの「稼働状態」に「稼働可能」状態が設定されていること。
なお、同種の「サーバ種別」の関連サーバの「稼働状態」が「稼働可能」状態ではない場合、「業務システム」全体が「稼働可能状態ではない」と判断でき、「業務システム」は「運用不可」の状態であると判断することができる。

以上のようにして、送受信先ノードの「サーバ種別」や「サーバ間の関係性」などに基づき、「追加サーバ」の属する業務システムを、「追加サーバ」が稼働する前に自動で判断することができる。

〔２−２−５〕分析処理部１２（設定部１２４）がＣＭＤＢ２１へサーバ間の関係性情報を設定する。つまり、分析処理部１２（設定部１２４）は、上記手順〔２−２−４〕の(84)において「追加サーバ」の属し先業務システムを判断できた場合、図９に示すように、以下の手順(101)〜(103)で、判断結果をＣＭＤＢ２１の構成情報に反映する。図９は、本実施形態の分析処理部１２（設定部１２４）による、サーバ間の関係性情報を設定する機能を説明する図である。

(101) 「追加サーバ」の稼働状態を「不明」に設定する（図９の符号(1)参照）。なお、「追加サーバ」の稼働状態は、下記項目〔２−３〕の手順〔２−３−３〕で設定される。
(102) 上記手順〔２−２−２〕で判断された送受信先サーバと手順〔２−２−３〕で判断された「追加サーバ」とを関係付ける（図９の矢印(2)参照）。
(103) 上記手順〔２−２−４〕の(84)で判断された属し先の「業務システム」と「追加サーバ」とを関係付ける（図９の矢印(3)参照）。

〔２−２−６〕本実施形態の管理サーバの第１動作例
図１０は、本実施形態の管理サーバ１の第１動作例を説明する図である。
図１０に示す例においても、図２８に示す例と同様、追加サーバＳ５から他の業務システムＡに属するＡＰサーバＳ２の情報を参照する通信が行なわれる場合がある。このような通信が生じると、追加されるＡＰサーバＳ５の通信状況に、当該サーバＳ５の属する業務システムＢとは異なる業務システムＡにおけるＡＰサーバＳ２との通信が混じり込む。その結果、通信状況から判定される追加サーバＳ５の役割と、他サーバの構成情報（役割等）から判定される追加サーバＳ５の役割との間に矛盾が発生する場合がある。

このため、図２８に示す例では、業務システムＢに追加されるサーバＳ５を、ＤＢサーバＳ５と誤認するとともに、業務システムＡに属するものと誤認して構成情報に登録してしまう。

これに対し、本実施形態の管理サーバ１を用いた場合、図１０に示すように、通信ログを含むセットアップログ、および、ＣＭＤＢ２１の構成情報を用いた解析を行なうことにより、上述したような矛盾を回避することができる。したがって、管理サーバ１は、業務システムＡにサーバＳ１，Ｓ２，Ｓ３が属するとともに、業務システムＢにサーバＳ４，Ｓ５，Ｓ６が属するものと正しく判断することができる。これにより、実行部１１は、業務システムＡに対する正常稼働確認フローを実行する際、図１０の上段に示すように、業務システムＡに属するサーバＳ１，Ｓ２，Ｓ３を操作対象サーバとして抽出し、業務システムＡに対する正常稼働確認フローを正しく実行することができる。

〔２−３〕業務システムの状態把握
ところで、上述のようにして追加サーバの役割（属性，サーバ種別）および追加サーバの属する業務システムが特定されると、セットアップ中の追加サーバを含む業務システムがサービス利用不可能な状態でユーザに提供される場合がある。このような場合、実行部１１は、サービス利用不可能な状態の追加サーバを、操作対象サーバとして抽出することがある。このため、実行部１１は、サービスの提供を行なえないセットアップ中の追加サーバに対しフロー制御（例えばサービス起動確認）を実行し、追加サーバが異常状態（エラー）であると誤認するおそれがある。

そこで、本実施形態では、分析処理部１２（判断部１２５）が、業務システムを成すＷｅｂサーバの「システム情報」を用いて、当該Ｗｅｂサーバにｈｔｔｐ（hypertext transfer protocol）リクエストを発行し、総合的に業務システムの状態を判断する。これによって、分析処理部１２は、業務システムがサービス利用可能状態であるか否かを把握する。

ここで、業務システムのサービス利用可能状態とは、個々のサーバのセットアップが完了し、ユーザがＷｅｂサーバにログインして業務システムを利用することができる状態である。ただし、複数のサーバから業務システムが構成されている場合には、業務システムを停止させることなく、サーバの追加を行なう場合がある。このような場合には、ログインの確認だけでは、追加されたサーバの稼働状態を確認することはできない。したがって、稼働状態の確認を可能にすべく、稼働確認用部品からログインを実行し当該部品からの要求が追加サーバのみに到達するようにネットワークを事前に設定する操作を行なう。

追加サーバ（業務システム）がサービス利用可能な状態である場合、設定部１２４が、ＣＭＤＢ２１における追加サーバのステータスを利用可能状態（稼働可能）に設定する。そして、抽出部１２６（「対象サーバ抽出」部品）が、当該業務システムに属するサーバを操作対象サーバとして抽出する。

追加サーバ（業務システム）がサービス利用不可能な状態である場合、設定部１２４が、ＣＭＤＢ２１における追加サーバのステータスを利用不可能状態に設定する。この場合、抽出部１２６（「対象サーバ抽出」部品）は、当該業務システムに属するサーバを操作対象サーバとして抽出しない。

分析処理部１２（判断部１２５および設定部１２４）は、以下の手順〔２−３−１〕〜〔２−３−３〕で、業務システムがサービス利用可能状態であるか否かを判断するとともに、当該判断結果をＣＭＤＢ２１に設定する。

〔２−３−１〕分析処理部１２（判断部１２５）が、業務システムのＷｅｂサーバが応答するか否かを判断する。つまり、分析処理部１２は、業務システムの状態を確認するために、手順〔２−２−３〕で導いた「業務システム構成」に基づきＷｅｂサーバの情報をＣＭＤＢ２１から取得する。そして、分析処理部１２は、取得したＷｅｂサーバの「システム情報」を用い、実行部１１からｈｔｔｐリクエストをＷｅｂサーバに対し発行し、その結果から業務システムの状態を、図１１に示すように解析する。

図１１は、本実施形態の分析処理部１２（判断部１２５）による、ｈｔｔｐリクエスト結果による業務システムの状態判断（業務システムのＷｅｂサーバの応答／無応答を判断する機能）を説明する図である。図１１に示すように、ｈｔｔｐリクエスト結果としては、例えば、コード2xx, 3xx, 4xx, 5xxのいずれかが取得される。ここで、コード2xxは、「成功」を意味し、Ｗｅｂサーバからの応答があって業務システムはサービス利用可能な状態であることを示す。コード3xxは、「リダイレクション」を意味し、Ｗｅｂサーバからの応答がなく業務システムは代替えの業務サービス利用可能な状態であることを示す。コード4xxは、「クライアント・エラー」を意味し、Ｗｅｂサーバからの応答がなく業務システムは無効（サービス停止中）であることを示す。コード5xxは、「サーバ・エラー」を意味し、Ｗｅｂサーバからの応答がなく業務システムは無効（サービス停止中）であることを示す。

〔２−３−２〕分析処理部１２（判断部１２５）が、業務システムがサービス利用可能な状態であるか否かを判断する。上述した手順〔２−３−１〕において、追加サーバの属する業務システムを成すＷｅｂサーバが応答するか否かは、ｈｔｔｐリクエスト結果コード2xxが取得されるか否かによって判断可能である。Ｗｅｂサーバが応答可能である場合、分析処理部１２は、実行部１１により稼働確認用部品からダイジェスト認証のhttpリクエストを実施し、その結果から業務システムの状態を、図１２に示すように解析する。分析処理部１２で認証が成功すれば、分析処理部１２は、業務システム（Ｗｅｂサーバ）へのログインを行なえたと判断することができ、業務システムがサービス利用可能な状態であると判断することができる。

図１２は、本実施形態の分析処理部１２（判断部１２５）による、ダイジェスト認証のリクエスト結果による業務システムの状態判断（業務システムへのログイン可能／不可能を判断する機能）を説明する図である。図１２に示すように、ｈｔｔｐリクエスト結果としては、例えば、コード2xx, 4xx, 5xxのいずれかが取得される。ここで、コード2xxは、「成功」を意味し、ログインに成功し業務システムはサービス利用可能な状態であることを示す。コード4xxは、「クライアント・エラー」を意味し、ログインに失敗し業務システムはサービス利用不可能な状態であることを示す。コード5xxは、「サーバ・エラー」を意味し、ログインに失敗し業務システムはサービス利用不可能な状態であることを示す。

〔２−３−３〕分析処理部１２（設定部１２４）が、業務システム情報をＣＭＤＢ２１に設定する。上述した手順〔２−３−２〕で業務システムがサービス利用可能であると判断されると、当該業務システムのセットアップが完了したと判断することが可能になる。これにより、業務システム向けフローで抽出した追加サーバは、操作対象ノードとして扱うことができる。そこで、分析処理部１２は、手順〔２−１−３〕で判断された追加ノードの「業務システム情報」と、手順〔２−２−３〕で導出された送受信先ノードの「業務システム情報」とに、Ｗｅｂサーバのノード名を、業務システムの識別子である業務システム名（例えば業務システム_192.168.0.1）として設定する。これにより、抽出部１２６（「対象サーバ抽出」部品）は、当該業務システムに属するサーバを操作対象サーバとして抽出する。

〔２−３−４〕本実施形態の管理サーバの第２動作例
図１３は、本実施形態の管理サーバ１の第２動作例を説明する図である。
本実施形態の管理サーバ１によれば、図１３に示すように、図１０に示す第１動作例と同様、業務システムＡにサーバＳ１〜Ｓ３が属し業務システムＢにサーバＳ４〜Ｓ６が属すると正しく判断することができる。さらに、本実施形態の管理サーバ１では、追加サーバＳ５がセットアップ中である場合、当該追加サーバＳ５の属する業務システムＢがサービス利用不可能な状態であることが認識される。つまり、分析処理部１２は、リクエスト応答解析によって追加サーバＳ５が運用不可であることを認識し、追加サーバＳ５の属する業務システムＢが運用不可であることを構成情報のステータスに設定し、矛盾を回避することができる。

したがって、図１３の上段に示すように、実行部１１が、セットアップ中の追加サーバＳ５を含む業務システムＢに対する正常稼働確認フローを実行しようとしても、業務システムＢに属するサーバは、操作対象サーバとして抽出されることがない。このため、実行部１１がサービスの提供を行なえないセットアップ中の追加サーバに対しフロー制御を実行することを確実に抑止することができる。

上述したように、本実施形態の管理サーバ１では、追加サーバがサービス利用可能な業務システムに属したか否かを自動的に判断することができる。そして、業務システムがサービス利用可能状態になった時点で、追加サーバへのネットワーク的経路が有効となり、業務システムのサービスを利用することが可能になる。これにより、ＣＭＤＢ２１の構成情報から操作対象サーバを動的に抽出して動作する、汎用的な業務システム向けフローに、業務システムを適用することが可能になる。

〔３〕本実施形態の管理サーバの具体的な動作
次に、図１４〜図２５を参照しながら、本実施形態の管理サーバ１の具体的な動作について説明する。
まず、図１４に示すフローチャート（ステップＳ１０〜Ｓ１６）に従って、本実施形態の管理サーバ１による処理全体の概要について説明する。

図１４に示すように、本実施形態の管理サーバ１においては、実行部１１が、スケジューリングによって、管理対象の業務サーバ２（サーバＳ１〜Ｓ６）の構成情報を自動収集する（ステップＳ１０；矢印Ａ１１参照）。これにより、ＣＭＤＢ２１における構成情報が常に最新状態に保たれる。

そして、実行部１１が、運用操作を行ない（ステップＳ１１）、「対象サーバ抽出」部品を実行させると、特定のサーバ種別の操作対象サーバがＣＭＤＢ２１から抽出される（ステップＳ１２；矢印Ａ１２参照）。このとき、分析処理部１２（検知部１２１）が、操作対象ノードが追加サーバであるか否かを判断することで、追加サーバを検知する（ステップＳ１３）。

操作対象ノードが追加サーバでない場合（ステップＳ１３の「無」ルート）、実行部１１が、操作対象ノードに対し通常のフロー制御を行なう（ステップＳ１４；矢印Ａ１３参照）。一方、操作対象ノードが追加サーバである場合（ステップＳ１３の「有」ルート）、分析処理部１２が、追加サーバのサーバ種別や追加サーバの属する業務システムの特定を行なった上で、特定した業務システムのサービス利用が可能か否かを判断する（ステップＳ１５）。

特定した業務システムのサービス利用が可能である場合（ステップＳ１５の「利用可」ルート）、実行部１１が、操作対象ノードに対し通常のフロー制御を行なう（ステップＳ１４；矢印Ａ１３参照）。一方、特定した業務システムのサービス利用が不可能である場合（ステップＳ１５の「利用不可」ルート）、実行部１１は、操作対象ノードに対するフロー制御を行なうことなく、次の運用操作を行なう（ステップＳ１６）。

〔３−１〕サーバ追加の自動判断処理
ついで、図１４〜図１７を参照しながら、上記項目〔２−１〕で説明した、サーバ追加の自動判断処理について、より具体的に説明する。

〔３−１−１〕ＣＭＤＢの最新化処理
まず、図１５に示すフローチャート（ステップＳ２０）に従って、本実施形態の管理サーバ１（実行部１１）による、構成情報（ＣＭＤＢ２１）の最新化処理について説明する。つまり、管理サーバ１では、実行部１１が、スケジューリングによって、記憶部２０に記憶される自動収集プログラムを実行する（ステップＳ２０）。これにより、上記手順〔２−１−１〕で前述した通り、管理対象の業務サーバ２（サーバＳ１〜Ｓ６）の構成情報について定期的な自動収集が実行され、ＣＭＤＢ２１における構成情報が常に最新状態に保たれる。

〔３−１−２〕汎用化されたフローの実行処理
次に、図１６に示すフローチャート（ステップＳ２１〜Ｓ２８）に従って、本実施形態の管理サーバ１（実行部１１および分析処理部１２）による、汎用化されたフローの実行処理について説明する。

実行部１１が運用操作を行ない「対象サーバ抽出」部品が実行されると、分析処理部１２は、構成情報に含まれるインストール済みソフトウェア情報に基づき、特定のサーバ種別の操作対象サーバをＣＭＤＢ２１から抽出する（ステップＳ２１；上記手順〔２−１−２〕参照）。つまり、手順〔２−１−２〕で前述した通り、分析処理部１２は、インストール済みソフトウェア情報に基づいて特定したサーバ種別を参照し、「対象サーバ抽出」部品が要求するサーバ種別のサーバを抽出する。

分析処理部１２は、抽出した操作対象サーバの全情報（ノード情報，システム情報）をＣＭＤＢ２１内から取得する（ステップＳ２２）。そして、分析処理部１２（検知部１２１）は、取得したノード（操作対象サーバ）が追加サーバであるか否かを判断する処理を実行する（ステップＳ２３）。ステップＳ２３の判断処理については、下記項目〔３−１−３〕において、図１７を参照しながら後述する。

ステップＳ２３の判断処理の結果、操作対象サーバが追加サーバでない場合（ステップＳ２４のＮＯルート）、実行部１１は、操作対象サーバに対するフロー処理を実行し（ステップＳ２７）、フロー実行履歴ＤＢ２２に操作ノード名や実行結果などを保存し（ステップＳ２８）、処理を終了する。一方、操作対象ノードが追加サーバである場合（ステップＳ２４のＹＥＳルート）、分析処理部１２は、追加サーバのサーバ種別や追加サーバの属する業務システムの特定を行なった上で、特定した業務システムのサービス利用が可能か否かを判断する処理を実行する（ステップＳ２５）。ステップＳ２５の判断処理については、下記項目〔３−２〕および〔３−３〕において、図１８〜図２５を参照しながら後述する。

ステップＳ２５の判断処理の結果、操作対象サーバの属する業務システムがサービス利用可能状態である場合（ステップＳ２６のＹＥＳルート）、実行部１１は、操作対象サーバに対するフロー処理を実行し（ステップＳ２７）、フロー実行履歴ＤＢ２２に操作ノード名や実行結果などを保存し（ステップＳ２８）、処理を終了する。一方、操作対象サーバの属する業務システムがサービス利用不可能状態である場合（ステップＳ２６のＮＯルート）、実行部１１は、操作対象サーバに対するフロー処理を実行することなく、処理を終了する。

〔３−１−３〕追加サーバの判断処理
次に、図１７に示すフローチャート（ステップＳ３０〜Ｓ４０）に従って、本実施形態の分析処理部１２（検知部１２１）による、追加サーバの判断処理について説明する。当該追加サーバの判断処理は、上記手順〔２−１−３〕で説明した処理に相当し、図１６のステップＳ２３の判断処理に対応する処理である。

分析処理部１２は、操作対象ノードについてＣＭＤＢ２１内に「業務システム」が設定されているか否かを判定する（ステップＳ３０）。「業務システム」が設定されている場合、つまり上記条件(51)を満たさない場合（ステップＳ３１のＮＯルート）、分析処理部１２は、操作対象ノードが追加サーバではないと判断し（ステップＳ４０）、処理を終了する。

「業務システム」が設定されていない場合、つまり上記条件(51)を満たす場合（ステップＳ３１のＹＥＳルート）、分析処理部１２は、操作対象ノードについてＣＭＤＢ２１内に「サーバ種別」が設定されているか否かを判定する（ステップＳ３２）。「サーバ種別」が設定されている場合、つまり上記条件(52)を満たさない場合（ステップＳ３３のＮＯルート）、分析処理部１２は、操作対象ノードが追加サーバではないと判断し（ステップＳ４０）、処理を終了する。

「サーバ種別」が設定されていない場合、つまり上記条件(51)および(52)を満たす場合（ステップＳ３３のＹＥＳルート）、分析処理部１２は、操作対象ノードについての「操作ノード名」がフロー実行履歴に記録されているか否かを判定する（ステップＳ３４）。「操作ノード名」が記録されている場合、つまり上記条件(53)を満たさない場合（ステップＳ３５のＮＯルート）、分析処理部１２は、操作対象ノードが追加サーバではないと判断し（ステップＳ４０）、処理を終了する。

「操作ノード名」が記録されていない場合、つまり上記条件(51)〜(53)を満たす場合（ステップＳ３５のＹＥＳルート）、分析処理部１２は、操作対象ノードについての「実行結果」がフロー実行履歴に記録されているか否かを判定する（ステップＳ３６）。操作対象ノードについての「実行結果」が記録されている場合、つまり上記条件(54)を満たさない場合（ステップＳ３７のＮＯルート）、分析処理部１２は、操作対象ノードが追加サーバではないと判断し（ステップＳ４０）、処理を終了する。

「実行結果」が記録されていない場合、つまり上記条件(51)〜(54)の全てを満たす場合（ステップＳ３７のＹＥＳルート）、分析処理部１２は、ＣＭＤＢ２１に操作対象ノードのサーバ種別を設定する（ステップＳ３８）。そして、分析処理部１２は、操作対象ノードが追加サーバであると判断し（ステップＳ３９）、処理を終了する。

〔３−２〕業務システムのサーバ構成およびサーバ種別の分析処理
〔３−２−１〕分析処理部による処理の概要
次に、図１８に示すフローチャート（ステップＳ１００〜Ｓ５００）に従って、本実施形態の分析処理部１２による処理の概要、具体的には図１６のステップＳ２５の処理の概要について説明する。ここで、図１６のステップＳ２５の処理は、前述した通り、追加サーバの属する業務システムを特定した上で特定した業務システムがサービス利用可能かを判断する処理である。

まず、分析処理部１２は、上記手順〔２−２−１〕で前述した通り、操作対象サーバである追加サーバから、当該追加サーバのセットアップログファイルを抽出し取得する（ステップＳ１００）。

この後、分析処理部１２は、送受信先ノードのサーバ種別／稼働状態取り出し処理を実行し（ステップＳ２００）、追加サーバのサーバ種別を特定するとともに業務システム構成を特定する処理を実行する（ステップＳ３００）。そして、分析処理部１２は、追加サーバの属する業務システムを決定する処理を実行してから（ステップＳ４００）、業務システムがサービス利用可能状態であるか判断する処理を実行する（ステップＳ５００）。

ステップＳ２００の処理は、上記手順〔２−２−２〕で説明した処理に相当し、ステップＳ２００の処理については、下記手順〔３−２−２〕において、図１９を参照しながら後述する。

ステップＳ３００の処理は、上記手順〔２−２−３〕で説明した処理に相当し、ステップＳ３００の処理については、下記手順〔３−２−３〕において、図２０を参照しながら後述する。

ステップＳ４００の処理は、上記手順〔２−２−４〕および〔２−２−５〕で説明した処理に相当し、ステップＳ４００の処理については、下記手順〔３−２−４〕および〔３−２−５〕において、図２１および図２２を参照しながら後述する。

ステップＳ５００の処理は、上記項目〔２−３〕で説明した処理に相当し、ステップＳ５００の処理については、下記項目〔３−３〕において、図２３〜図２５を参照しながら後述する。

〔３−２−２〕送受信先ノードのサーバ種別／稼働状態取り出し処理
次に、図１９に示すフローチャート（ステップＳ２０１〜Ｓ２１７）に従って、本実施形態の分析処理部１２による、送受信先ノードのサーバ種別／稼働状態取り出し処理（図１８のステップＳ２００）について説明する。図１９に示す処理は、上記手順〔２−２−２〕で説明した処理に相当する。

分析処理部１２は、追加サーバのセットアップログから、追加サーバの送信先ノードの情報（ＩＰアドレス）を取得する（ステップＳ２０１）。そして、分析処理部１２は、取得した送信先ノード情報に基づき、送信先ノードの全情報（ノード情報，システム情報）をＣＭＤＢ２１から取得する（ステップＳ２０２）。

この後、分析処理部１２は、送信先ノードにＣＭＤＢ２１内の「サーバ種別」が設定されているか否かを判定する（ステップＳ２０３）。「サーバ種別」が設定されていない場合（ステップＳ２０４のＮＯルート）、分析処理部１２は、送信先ノードのサーバ種別を「不明」として認識する（ステップＳ２０５）。

サーバ種別を「不明」として認識した後、または、「サーバ種別」が設定されている場合（ステップＳ２０４のＹＥＳルート）、分析処理部１２は、送信先ノードの「稼働状態」が設定されているか否かを判定する（ステップＳ２０６）。「稼働状態」が設定されていない場合（ステップＳ２０７のＮＯルート）、分析処理部１２は、送信先ノードの稼働状態を「不明」として認識する（ステップＳ２０８）。

稼働状態を「不明」として認識した後、または、「稼働状態」が設定されている場合（ステップＳ２０７のＹＥＳルート）、分析処理部１２は、追加サーバの受信元ノードについても、同様の処理を行なう。

つまり、分析処理部１２は、追加サーバのセットアップログから、追加サーバの受信元ノードの情報（ＩＰアドレス）を取得する（ステップＳ２０９）。そして、分析処理部１２は、取得した受信元ノード情報に基づき、受信元ノードの全情報（ノード情報，システム情報）をＣＭＤＢ２１から取得する（ステップＳ２１０）。

この後、分析処理部１２は、受信元ノードにＣＭＤＢ２１内の「サーバ種別」が設定されているか否かを判定する（ステップＳ２１１）。「サーバ種別」が設定されていない場合（ステップＳ２１２のＮＯルート）、分析処理部１２は、受信元ノードのサーバ種別を「不明」として認識する（ステップＳ２１３）。

サーバ種別を「不明」として認識した後、または、「サーバ種別」が設定されている場合（ステップＳ２１２のＹＥＳルート）、分析処理部１２は、受信元ノードの「稼働状態」が設定されているか否かを判定する（ステップＳ２１４）。「稼働状態」が設定されていない場合（ステップＳ２１５のＮＯルート）、分析処理部１２は、受信元ノードの稼働状態を「不明」として認識する（ステップＳ２１６）。

稼働状態を「不明」として認識した後、または、「稼働状態」が設定されている場合（ステップＳ２１５のＹＥＳルート）、分析処理部１２は、ステップＳ２０１〜Ｓ２１６の処理によって得られた、送受信ノードの「サーバ種別」および「稼働状態」に関する情報を記録する（ステップＳ２１７；上記手順(63)参照）。「サーバ種別」および「稼働状態」が設定されている場合には、設定内容が記録される一方、「サーバ種別」および「稼働状態」が設定されていない場合には、「不明」が記録される。

以上の処理によって、分析処理部１２は、追加サーバのセットアップログを解析し、ＣＭＤＢ２１から、追加サーバと送受信関係にある送受信先ノードの「サーバ種別」および「稼動状態」を抽出して記録する。

〔３−２−３〕業務システム構成を特定する処理
次に、図２０に示すフローチャート（ステップＳ３０１〜Ｓ３１１）に従って、本実施形態の分析処理部１２（第１特定部１２２）による、業務システム構成（業務システムのサーバ構成）を特定する処理（図１８のステップＳ３００）について説明する。図２０に示す処理は、上記手順〔２−２−３〕で説明した処理に相当する。

分析処理部１２は、追加サーバのセットアップログにおける通信ログから、当該追加サーバの送受信先ノードおよび通信方向情報（図７のＤ１，Ｄ２参照）を取り出す（ステップＳ３０１）。また、分析処理部１２は、送受信先ノード情報に基づき、ＣＭＤＢ２１から送受信先ノードの「サーバ種別」を取り出す（ステップＳ３０２）。

この後、分析処理部１２は、サーバ種別決定リスト２３（図６参照）に、ステップＳ３０２で抽出した送受信先ノードの「サーバ種別」と一致する「送信先サーバ種別」および「受信元サーバ種別」に対応付けられたサーバ種別情報が存在するか否かを判定する（ステップＳ３０３）。このようなサーバ種別情報が存在する場合（ステップＳ３０４のＹＥＳルート）、分析処理部１２は、検索したサーバ種別情報を、追加サーバの「サーバ種別」として取り出す（ステップＳ３０５；上記手順(73)参照）。

例えば、上記手順〔３−２−３〕で図６および図７を参照しながら前述したように、サーバ種別決定リスト２３の一つにおいては、サーバ種別「ＡＰ」に、送信先サーバ種別「ＤＢ」と受信元サーバ種別「Ｗｅｂ」とが対応付けられている。このとき、ステップＳ３０２で抽出された送信先ノードおよび送受信先ノードの「サーバ種別」がそれぞれＤＢサーバおよびＷｅｂサーバである場合、当該サーバ種別決定リスト２３に、送受信先ノードの「サーバ種別」と一致するサーバ種別「ＡＰ」が存在することになる。したがって、サーバ種別「ＡＰ」が追加サーバのサーバ種別として抽出される。これにより、追加サーバを追加される業務システムが３階層構造であり、追加サーバのサーバ種別がＡＰサーバであることが判断される。

追加サーバの「サーバ種別」を取り出した後、分析処理部１２は、ＣＭＤＢ２１の構成情報から、追加サーバの送受信先ノードと関連するノードのリストを作成する（ステップＳ３０６）。そして、分析処理部１２は、作成したリストに、追加サーバの「サーバ種別」と同じ「サーバ種別」のノード（以下「既存サーバ」または「関連サーバ」という）が存在するか否かを判定する（ステップＳ３０７）。

関連サーバが存在する場合（ステップＳ３０８のＹＥＳルート）、分析処理部１２は、ステップＳ３０５で取り出された追加サーバの「サーバ種別」と、関連サーバの「稼働状態」と、追加サーバと送受信先サーバとの関係性とに関する情報を記録する（ステップＳ３０９；上記手順(75)参照）。ここで、関連サーバの「稼働状態」は、関連サーバのＩＰアドレス等に基づき、ＣＭＤＢ２１から読み出される。また、追加サーバと送受信先サーバとの関係性は、追加サーバを追加される業務システムの構造や、当該業務システムを成すサーバ種別に関する情報である。なお、関連サーバの「サーバ種別」は、ステップＳ３０５で取り出された追加サーバの「サーバ種別」と同一であるので、関連サーバの「サーバ種別」の記録は行なっていない。

一方、関連サーバが存在しない場合（ステップＳ３０８のＮＯルート）、分析処理部１２は、ステップＳ３０５で取り出された追加サーバの「サーバ種別」と、上記関係性とに関する情報を記録するとともに、関連サーバの「稼働状態」に「不明」を記録する（ステップＳ３１０；上記手順(75)参照）。

また、ステップＳ３０３で上述したサーバ種別情報が存在しないと判定された場合（ステップＳ３０４のＮＯルート）、分析処理部１２は、追加サーバの「サーバ種別」や関連サーバの「稼働状態」や追加サーバと送受信先サーバとの関係性に「不明」を記録する（ステップＳ３１１；上記手順(75)参照）。

以上の処理によって、分析処理部１２は、追加サーバの「サーバ種別」および「サーバ間の関係性」を自動判別でき、ひいては追加サーバの属する業務システム構成を自動判断することができる。

〔３−２−４〕追加サーバのサーバ種別を特定する処理、および、追加サーバの属する業務システムを決定する処理
次に、図２１に示すフローチャート（ステップＳ４０１〜Ｓ４１０）に従って、本実施形態の分析処理部１２（第１特定部１２２，第２特定部１２３，設定部１２４）による、追加サーバのサーバ種別を特定する処理、および、追加サーバの属する業務システムを決定する処理（図１８のステップＳ４００）について説明する。図２１に示す処理は、上記手順〔２−２−４〕および〔２−２−５〕で説明した処理に相当する。

分析処理部１２は、図２０のステップＳ３０５で抽出された追加サーバの「サーバ種別」と図１６のステップＳ２１で決定された追加サーバの「サーバ種別」とが一致するか否かを判定する（ステップＳ４０１）。ここで、図２０のステップＳ３０５で抽出された「サーバ種別」は、ステップＳ３０９またはＳ３１０で記録されており、上記手順(73)で抽出し上記手順(75)で記録された「サーバ種別」に相当する。また、図１６のステップＳ２１で決定された「サーバ種別」は、上記手順〔２−１−２〕で特定される「サーバ種別」に相当する。

ステップＳ４０１による判定結果が不一致である場合（ステップＳ４０２のＮＯルート）、上記手順(81)で前述した通り、通信ログに基づいて判断される業務システム（追加サーバの属性）と、ＣＭＤＢ２１の構成情報に基づいて判断される業務システム（追加サーバの属性）との間に矛盾がある。このため、分析処理部１２は、図１６のステップＳ２１から再実行する（ステップＳ４０３）。例えば、操作対象サーバをサーバ種別ＡＰに絞って判定処理を実行した結果、「サーバ種別」が不一致の場合、分析処理部１２は、操作対象サーバを、ＡＰ以外のサーバ種別ＤＢまたはＷｅｂに絞って、図１６のステップＳ２１以降の処理を再実行する。

ステップＳ４０１による判定結果が一致である場合（ステップＳ４０２のＹＥＳルート）、つまり上記矛盾がなくなった場合、分析処理部１２は、上記手順(82)で前述した通り、「追加サーバ」が属している業務システムの状態を判定する（ステップＳ４０４）。ステップＳ４０４での業務システムの状態判定処理については、下記項目〔３−２−５〕において、図２２を参照しながら後述する。

分析処理部１２は、ステップＳ４０４での判定処理結果を受け、業務システムが運用可能な状態であるか否かを判定する（ステップＳ４０５）。業務システムが運用不可能な状態である場合（ステップＳ４０６のＮＯルート）、分析処理部１２は、上記手順(83)で前述した通り、「追加サーバ」は既存のシステムに属さないと判断し、「追加サーバ」のＣＭＤＢ２１への反映を行なうことなく処理を終了する。

業務システムが運用可能な状態である場合（ステップＳ４０６のＹＥＳルート）、分析処理部１２は、上記手順(84)で前述した通り、追加サーバの送受信先サーバが属する既存の業務システムをＣＭＤＢ２１から抽出し、「追加サーバ」の属し先「業務システム」とする（ステップＳ４０７）。

この後、分析処理部１２は、ＣＭＤＢ２１の追加サーバの稼働状態を「不明」に設定する（ステップＳ４０８；上記手順(101)および図９の符号(1)参照）。この追加サーバの稼働状態は、図２３のステップＳ５０６で設定される。

また、分析処理部１２は、図１９に示すフローチャートで判断された送受信先サーバと、図２０に示すフローチャートで判断された追加サーバとを、ＣＭＤＢ２１上で関係付ける（ステップＳ４０９；上記手順(102)および図９の矢印(2)参照）。

さらに、分析処理部１２は、ステップＳ４０７で抽出された追加サーバの属し先の「業務システム」と、当該追加サーバとを、ＣＭＤＢ２１上で関係付ける（ステップＳ４１０；上記手順(103)および図９の矢印(3)参照）。

〔３−２−５〕業務システムの状態判定処理
次に、図２２に示すフローチャート（ステップＳ４１１〜Ｓ４２７）に従って、本実施形態の分析処理部１２（第２特定部１２３）による、業務システムの状態判定処理（図２１のステップＳ４０４）について説明する。図２２に示す処理は、上記手順〔２−２−４〕で説明した、図８に示す稼働状況判定テーブル２４による状態判定処理に相当する。

分析処理部１２は、図２２に示すフローチャートに従って、下記３種類の情報(111)〜(113)に基づき、図８に示す稼働状況判定テーブル２４において業務システムの運用状態が「運用可能」状態（図８の太線枠の状態）になるか否かを判断する。つまり、上記手順〔２−２−４〕で前述した通り、上記条件(91)と上記条件(92)との両方を満たす場合、追加サーバの属する既存の「業務システム」の運用状態は「運用可能」状態であると判断される（図８の太線枠参照）。それ以外の場合、追加サーバの属する既存の「業務システム」の運用状態は「運用不可」状態であると判断される。

(111) 図１６のステップＳ２１で決定された追加サーバの「サーバ種別」（上記手順〔２−１−２〕の結果）
(112) 図１９のステップＳ２１７で記録された送信先／受信元ノードの「サーバ種別」および「稼働状態」（上記手順〔２−２−２〕の結果）
(113) 図２０のステップＳ３０９〜Ｓ３１１で記録された追加サーバの「サーバ種別」および関連サーバの「稼働状態」（上記手順〔２−２−３〕の結果）

まず、分析処理部１２は、送信先サーバに「不明」以外のサーバ種別が設定されているか否かを判定する（ステップＳ４１１）。「不明」以外のサーバ種別が設定されている場合（ステップＳ４１２のＹＥＳルート）、分析処理部１２は、送信先サーバが稼働可能状態であるか否かを判定する（ステップＳ４１３）。稼働可能状態である場合（ステップＳ４１４のＹＥＳルート）、分析処理部１２は、状態フラグに１を設定してから（ステップＳ４１５）、ステップＳ４１７の処理に移行する。一方、サーバ種別に「不明」が設定されている場合（ステップＳ４１２のＮＯルート）、または、送信先サーバが稼働可能状態でない場合（ステップＳ４１４のＮＯルート）、分析処理部１２は、状態フラグに０を設定してから（ステップＳ４１６）、ステップＳ４１７の処理に移行する。

また、分析処理部１２は、受信元先サーバに「不明」以外のサーバ種別が設定されているか否かを判定する（ステップＳ４１７）。「不明」以外のサーバ種別が設定されている場合（ステップＳ４１８のＹＥＳルート）、分析処理部１２は、受信元サーバが稼働可能状態であるか否かを判定する（ステップＳ４１９）。稼働可能状態である場合（ステップＳ４２０のＹＥＳルート）、分析処理部１２は、状態フラグの値に１を加算してから（ステップＳ４２１）、ステップＳ４２２の処理に移行する。一方、サーバ種別に「不明」が設定されている場合（ステップＳ４１８のＮＯルート）、または、受信元サーバが稼働可能状態でない場合（ステップＳ４２０のＮＯルート）、分析処理部１２は、ステップＳ４２２の処理に移行する。

そして、分析処理部１２は、状態フラグの値が１以上であるか否かを判定し（ステップＳ４２２）、１以上である場合（ステップＳ４２３のＹＥＳルート）、関連サーバが稼働可能状態であるか否かを判定する（ステップＳ４２４）。稼働可能状態である場合（ステップＳ４２５のＹＥＳルート）、分析処理部１２は、業務システムの運用状態は運用可能状態であると判断し（ステップＳ４２６）、処理を終了する。一方、状態フラグの値が０である場合（ステップＳ４２３のＮＯルート）、または、関連サーバが稼働可能状態でない場合（ステップＳ４２５のＮＯルート）、分析処理部１２は、業務システムの運用状態は運用不可状態であると判断し（ステップＳ４２７）、処理を終了する。

上述した手順〔３−２−４〕および〔３−２−５〕の処理によって、分析処理部１２は、送受信先ノードの「サーバ種別」や「サーバ間の関係性」などに基づき、追加サーバの属する業務システムを、「追加サーバ」が稼働する前に自動で判断することができる。

〔３−３〕業務システムの状態把握処理
次に、図２３に示すフローチャート（ステップＳ５０１〜Ｓ５０６）に従って、本実施形態の分析処理部１２（判断部１２５および設定部１２４）による、業務システムのサービス利用可能状態の判断処理について説明する。図２３に示す処理は、上記項目〔２−３〕や上記手順〔２−３−３〕で説明した処理に相当する。

分析処理部１２は、操作対象ノードの「サーバ間の関係性」情報に基づき、ＣＭＤＢ２１からＷｅｂサーバの全情報（ノード情報，システム情報）を取得する（ステップＳ５０１）。この後、分析処理部１２は、Ｗｅｂサーバが応答可能か否かを判断する（ステップＳ５０２）。ステップＳ５０２での判断処理については、下記項目〔３−３−１〕において、図２４を参照しながら後述する。

ステップＳ５０２による判断処理の結果、Ｗｅｂサーバが応答可能である場合（ステップＳ５０３のＹＥＳルート）、分析処理部１２は、業務システム（Ｗｅｂサーバ）へのログインが可能か否か、つまりは業務システムのサービスが利用可能か否かを判断する（ステップＳ５０４）。ステップＳ５０４での判断処理については、下記項目〔３−３−２〕において、図２５を参照しながら後述する。

ステップＳ５０４による判断処理の結果、業務システムへのログインが可能である場合、つまり業務システムのサービスが利用可能である場合（ステップＳ５０５のＹＥＳルート）、分析処理部１２は、上記手順〔２−３−３〕で前述した処理を実行する（ステップＳ５０６）。つまり、分析処理部１２は、ＣＭＤＢ２１において、図１７に示すフローチャートで判断された追加ノードの「業務システム情報」と、図２０に示すフローチャートで導出された送受信先ノードの「業務システム情報」とに、Ｗｅｂサーバのノード名を設定する。これにより、抽出部１２６（「対象サーバ抽出」部品）は、当該業務システムに属するサーバを操作対象サーバとして抽出することが可能になる。

なお、ステップＳ５０２による判断処理の結果、Ｗｅｂサーバの応答が無い場合（ステップＳ５０３のＮＯルート）、分析処理部１２は処理を終了する。同様に、ステップＳ５０４による判断処理の結果、業務システムへのログインが不可能である場合、つまり業務システムのサービスが利用不可能である場合（ステップＳ５０５のＮＯルート）、分析処理部１２は処理を終了する。

〔３−３−１〕Ｗｅｂサーバの応答／無応答を判断する処理
次に、図２４に示すフローチャート（ステップＳ５１１〜Ｓ５１９）に従って、本実施形態の分析処理部１２（判断部１２５）による、業務システムのＷｅｂサーバの応答／無応答を判断する処理（図２３のステップＳ５０２）について説明する。図２４に示す処理は、上記手順〔２−３−１〕で説明した処理に相当する。

分析処理部１２は、まず、Ｗｅｂサーバのシステム情報におけるＷｅｂポートやアクセスＵＲＬ（Uniform Resource Locator）からｈｔｔｐリクエスト文字列を組み立てる（ステップＳ５１１）。そして、分析処理部１２は、組み立てたｈｔｔｐリクエストをＷｅｂサーバに発行する（ステップＳ５１２）。分析処理部１２は、ｈｔｔｐリクエストの発行に伴い、当該ｈｔｔｐリクエストの結果コード（図１１参照）を取得し、その結果コードが2xx, 3xx, 4xx, 5xxのいずれであるかに基づき、Ｗｅｂサーバの応答／無応答を判断する（ステップＳ５１３〜Ｓ５１９）。

つまり、分析処理部１２は、結果コードが2xxの場合、Ｗｅｂサーバは応答可能な状態であると判断する（ステップＳ５１３，Ｓ５１４，Ｓ５１８）。一方、分析処理部１２は、結果コードが3xx, 4xx, 5xxのいずれかである場合、Ｗｅｂサーバは応答不可能な状態（無応答）であると判断する（ステップＳ５１３，Ｓ５１５〜Ｓ５１７，Ｓ５１９）。

〔３−３−２〕業務システムへのログイン可能／不可能を判断する処理
次に、図２５に示すフローチャート（ステップＳ５２１〜Ｓ５２９）に従って、本実施形態の分析処理部１２（判断部１２５）による、業務システムのサービス利用可能／不可能を判断する処理（図２３のステップＳ５０４）について説明する。図２５に示す処理は、上記手順〔２−３−２〕で説明した処理に相当する。なお、図２５に示す処理において、分析処理部１２は、業務システムへのログイン可能／不可能を判断することで、業務システムのサービスが利用可能か否かを判断している。

分析処理部１２は、まず、稼働確認用部品から、追加サーバに対してのみリクエストが届くよう、ネットワーク機器を設定する（ステップＳ５２１）。また、分析処理部１２は、サーバ種別決定リスト２３の稼働確認情報から、ｈｔｔｐリクエスト文字列を組み立てる（ステップＳ５２２）。そして、分析処理部１２は、組み立てたｈｔｔｐリクエストによって、ダイジェスト認証を実施する（ステップＳ５２３）。分析処理部１２は、ダイジェスト認証に伴い、当該ｈｔｔｐリクエストの結果コード（図１２参照）を取得し、その結果コードが2xx, 4xx, 5xxのいずれであるかに基づき、業務システム（Ｗｅｂサーバ）へのログインが可能か否かを判断する（ステップＳ５２４〜Ｓ５２９）。

つまり、分析処理部１２は、結果コードが2xxの場合、業務システムへのログインが可能で、業務システムのサービスが利用可能な状態であると判断する（ステップＳ５２４，Ｓ５２５，Ｓ５２８）。一方、分析処理部１２は、結果コードが4xx, 5xxのいずれかである場合、業務システムへのログインが不可能で、業務システムのサービスが利用不可能な状態であると判断する（ステップＳ５２６，Ｓ５２７，Ｓ５２９）。

〔４〕本実施形態の効果
本実施形態の管理サーバ１によれば、業務システムで追加サーバを検知すると、追加サーバのセットアップ時通信ログや、追加サーバのインストール済みソフトウェア情報や、追加サーバの送受信先サーバの構成情報に基づき追加サーバの種別が特定される。このとき、追加サーバへのインストール済みソフトウエア情報に基づき特定される追加サーバのバ種別と、追加サーバの通信ログや送受信先サーバの構成情報に基づき特定される追加サーバの種別とが一致する場合に、追加サーバの種別が特定される。したがって、業務システムに動的に追加されるサーバのサーバ種別を、正確に且つ自動的に判別することができる。

図２８を参照しながら前述したように、業務システムでは、サーバが動的に追加される際、業務システム上、関係のないサーバからの通信（環境の参照など）が追加サーバの通信ログに混じり込むことがある。これにより、実際に追加したサーバの役割や、追加したサーバの属する業務システムを誤認することがある。

これに対して、本実施形態の管理サーバ１では、追加されたサーバのセットアップログと、ＣＭＤＢ２１の構成情報とを解析することで、追加されたサーバの役割が正確に判断され、追加されたサーバの属する一つの業務システム構成が特定される。そして、特定された業務システム構成のサーバ間の関係性を判断することにより、動的に追加されたサーバの属する業務システムを、矛盾なく自動判断することができる。

また、追加サーバがサービスを提供できない状態でＣＭＤＢ２１の構成情報に登録されると、サービス提供ができない状態でも追加サーバに対してもフローが実行されてしまうおそれがあった。

これに対して、本実施形態の管理サーバ１では、動的に追加されたサーバの属する業務システムの運用状態が正確に把握され、業務システムが運用可能（サービス利用可能）な状態である場合にのみ追加サーバに対しフロー制御が実行される。したがって、業務システムが運用不可（サービス利用不可）の状態では、追加サーバを含む業務システムへのフロー制御を抑制することができ、追加サーバが異常状態（エラー）であると誤認することを確実に抑止することができる。

さらに、本実施形態によれば、データセンタ等の管理／運用業務において、自動運用の操作対象サーバについて、業務システムの状態を把握し、業務システムを構成するサーバを自動的に認識することができる。これにより、人手による管理作業を行なう必要がなくなり、データセンタ等の管理コストを低減することができる。また、例えば図２７に示すようなフローにおいて、サーバ追加等のメンテナンスを考慮して実装する必要がないため、フローの作成／メンテナンスに要するコストも低減することができる。

〔５〕その他
以上、本発明の好ましい実施形態について詳述したが、本発明は、係る特定の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲内において、種々の変形、変更して実施することができる。

〔６〕付記
以上の実施形態に関し、さらに以下の付記を開示する。
（付記１）
管理対象のシステムへのサーバの追加を検知する検知部と、
追加を検知された追加サーバの通信状況、前記追加サーバに関する管理情報、および、前記追加サーバの通信先サーバに関する管理情報に基づき、前記追加サーバの属性を特定する第１特定部と、を備える、サーバ情報管理装置。

（付記２）
前記第１特定部は、前記追加サーバに関する管理情報に含まれる前記追加サーバへのインストール済みソフトウエア情報に基づき特定される前記追加サーバの属性と、前記追加サーバの通信状況および前記通信先サーバに関する管理情報に基づき特定される前記追加サーバの属性と、が一致するか否かを判断し、当該２つの属性が一致する場合、当該属性を、前記追加サーバの属性として特定する、付記１記載のサーバ情報管理装置。

（付記３）
前記第１特定部によって特定される前記追加サーバの属性と前記通信先サーバの属性および稼動状態と前記通信先サーバに接続される既存サーバの属性および稼動状態とに基づき、前記追加サーバの属するサーバ群を特定する第２特定部と、
前記第２特定部によって特定される前記サーバ群および前記通信先サーバと、前記追加サーバとを関連付け、前記追加サーバに関する管理情報として設定する設定部とを、さらに備える、付記１または付記２に記載のサーバ情報管理装置。

（付記４）
前記第２特定部は、前記追加サーバの属性と前記通信先サーバの属性および稼動状態と前記既存サーバの属性および稼動状態とに基づき前記既存サーバを含む既存サーバ群が運用可能状態であると判断した場合、当該既存サーバ群を前記追加サーバの属するサーバ群として特定する、付記３記載のサーバ情報管理装置。

（付記５）
前記第２特定部によって特定された前記サーバ群がサービス利用可能状態であるか否かを判断する判断部と、
前記判断部によって前記サービス利用可能状態であると判断された場合、前記サーバ群に属する前記追加サーバおよび前記通信先サーバを操作対象として抽出する抽出部と、をさらに備える、付記３または付記４に記載のサーバ情報管理装置。

（付記６）
前記設定部は、前記サービス利用可能状態であると判断された場合、前記追加サーバに関する管理情報における前記追加サーバの稼動状態を稼動可能に設定する、付記５記載のサーバ情報管理装置。

（付記７）
前記判断部は、前記サーバ群に属するウエブサーバが応答可能であり、且つ、前記サーバ群に対するログインが可能である場合、前記サービスを利用可能な状態であると判断する、付記５または付記６に記載のサーバ情報管理装置。

（付記８）
前記検知部は、前記管理対象のシステムに属する複数のサーバの中から操作対象として抽出された操作対象サーバが、前記追加サーバであるか否かを判断することで、前記追加サーバを検知する、付記１〜付記７のいずれか一項に記載のサーバ情報管理装置。

（付記９）
管理対象のシステムへのサーバの追加を検知し、
追加を検知された追加サーバの通信状況、前記追加サーバに関する管理情報、および、前記追加サーバの通信先サーバに関する管理情報とに基づき、前記追加サーバの属性を特定する、
処理をコンピュータに実行させる、サーバ情報管理プログラム。

（付記１０）
前記追加サーバに関する管理情報に含まれる前記追加サーバへのインストール済みソフトウエア情報に基づき特定される前記追加サーバの属性と、前記追加サーバの通信状況および前記通信先サーバに関する管理情報に基づき特定される前記追加サーバの属性と、が一致するか否かを判断し、当該２つの属性が一致する場合、当該属性を、前記追加サーバの属性として特定する、
処理を前記コンピュータに実行させる、付記９記載のサーバ情報管理プログラム。

（付記１１）
前記追加サーバの属性と前記通信先サーバの属性および稼動状態と前記通信先サーバに接続される既存サーバの属性および稼動状態とに基づき、前記追加サーバの属するサーバ群を特定し、
前記サーバ群および前記通信先サーバと、前記追加サーバとを関連付け、前記追加サーバに関する管理情報として設定する、
処理を前記コンピュータに実行させる、付記９または付記１０に記載のサーバ情報管理プログラム。

（付記１２）
前記追加サーバの属性と前記通信先サーバの属性および稼動状態と前記既存サーバの属性および稼動状態とに基づき前記既存サーバを含む既存サーバ群が運用可能状態であると判断した場合、当該既存サーバ群を前記追加サーバの属するサーバ群として特定する、
処理を前記コンピュータに実行させる、付記１１記載のサーバ情報管理プログラム。

（付記１３）
前記サーバ群がサービス利用可能状態であるか否かを判断し、
前記サービス利用可能状態であると判断された場合、前記サーバ群に属する前記追加サーバおよび前記通信先サーバを操作対象として抽出する、
処理を前記コンピュータに実行させる、付記１１または付記１２に記載のサーバ情報管理プログラム。

（付記１４）
前記サービス利用可能状態であると判断された場合、前記追加サーバに関する管理情報における前記追加サーバの稼動状態を稼動可能に設定する、
処理を前記コンピュータに実行させる、付記１３記載のサーバ情報管理プログラム。

（付記１５）
前記サーバ群に属するウエブサーバが応答可能であり、且つ、前記サーバ群に対するログインが可能である場合、前記サービスを利用可能な状態であると判断する、
処理を前記コンピュータに実行させる、付記１３または付記１４に記載のサーバ情報管理プログラム。

（付記１６）
前記管理対象のシステムに属する複数のサーバの中から操作対象として抽出された操作対象サーバが、前記追加サーバであるか否かを判断することで、前記追加サーバを検知する、
処理を前記コンピュータに実行させる、付記９〜付記１５のいずれか一項に記載のサーバ情報管理プログラム。

（付記１７）
コンピュータが、
管理対象のシステムへのサーバの追加を検知し、
追加を検知された追加サーバの通信状況、前記追加サーバに関する管理情報、および、前記追加サーバの通信先サーバに関する管理情報に基づき、前記追加サーバの属性を特定する、サーバ情報管理方法。

（付記１８）
前記コンピュータが、
前記追加サーバに関する管理情報に含まれる前記追加サーバへのインストール済みソフトウエア情報に基づき特定される前記追加サーバの属性と、前記追加サーバの通信状況および前記通信先サーバに関する管理情報に基づき特定される前記追加サーバの属性と、が一致するか否かを判断し、当該２つの属性が一致する場合、当該属性を、前記追加サーバの属性として特定する、付記１７記載のサーバ情報管理方法。

（付記１９）
前記コンピュータが、
前記追加サーバの属性と前記通信先サーバの属性および稼動状態と前記通信先サーバに接続される既存サーバの属性および稼動状態とに基づき、前記追加サーバの属するサーバ群を特定し、
前記サーバ群および前記通信先サーバと、前記追加サーバとを関連付け、前記追加サーバに関する管理情報として設定する、付記１７または付記１８に記載のサーバ情報管理方法。

（付記２０）
前記コンピュータが、
前記追加サーバの属性と前記通信先サーバの属性および稼動状態と前記既存サーバの属性および稼動状態とに基づき前記既存サーバを含む既存サーバ群が運用可能状態であると判断した場合、当該既存サーバ群を前記追加サーバの属するサーバ群として特定する、付記１９記載のサーバ情報管理方法。

１ 管理サーバ（サーバ情報管理装置，コンピュータ）
２ 業務サーバ
１０ 処理部（プロセッサ）
１１ 実行部
１２ 分析処理部
１２１ 検知部
１２２ 第１特定部
１２３ 第２特定部
１２４ 設定部
１２５ 判断部
１２６ 抽出部
２０ 記憶部（メモリ）
２１ ＣＭＤＢ（構成情報データベース）
２２ フロー実行履歴データベース
２３ サーバ種別決定リスト
２４ 稼働状況判定テーブル
２５ セットアップログ格納領域
Ｓ１，Ｓ４ Ｗｅｂサーバ
Ｓ２ ＡＰサーバ
Ｓ３，Ｓ６ ＤＢサーバ
Ｓ５ ＡＰサーバ（追加サーバ）

Claims (10)

1. 管理対象のシステムへのサーバの追加を検知する検知部と、
   追加を検知された追加サーバの通信状況としてのセットアップログファイルに含まれるセットアップ時の通信ログと、前記追加サーバに関する管理情報と、前記追加サーバの通信先サーバに関する管理情報とに基づき、前記追加サーバの属性を特定する第１特定部と、を備える、サーバ情報管理装置。
2. 前記第１特定部は、前記追加サーバに関する管理情報に含まれる前記追加サーバへのインストール済みソフトウエア情報に基づき特定される前記追加サーバの属性と、前記追加サーバの通信状況および前記通信先サーバに関する管理情報に基づき特定される前記追加サーバの属性と、が一致するか否かを判断し、当該２つの属性が一致する場合、当該属性を、前記追加サーバの属性として特定する、請求項１記載のサーバ情報管理装置。
3. 前記第１特定部によって特定される前記追加サーバの属性と前記通信先サーバの属性および稼動状態と前記通信先サーバに接続される既存サーバの属性および稼動状態とに基づき、前記追加サーバの属するサーバ群を特定する第２特定部と、
   前記第２特定部によって特定される前記サーバ群および前記通信先サーバと、前記追加サーバとを関連付け、前記追加サーバに関する管理情報として設定する設定部とを、さらに備える、請求項１または請求項２に記載のサーバ情報管理装置。
4. 前記第２特定部は、前記追加サーバの属性と前記通信先サーバの属性および稼動状態と前記既存サーバの属性および稼動状態とに基づき前記既存サーバを含む既存サーバ群が運用可能状態であると判断した場合、当該既存サーバ群を前記追加サーバの属するサーバ群として特定する、請求項３記載のサーバ情報管理装置。
5. 前記第２特定部によって特定された前記サーバ群がサービス利用可能状態であるか否かを判断する判断部と、
   前記判断部によって前記サービス利用可能状態であると判断された場合、前記サーバ群に属する前記追加サーバおよび前記通信先サーバを操作対象として抽出する抽出部と、をさらに備える、請求項３または請求項４に記載のサーバ情報管理装置。
6. 前記設定部は、前記サービス利用可能状態であると判断された場合、前記追加サーバに関する管理情報における前記追加サーバの稼動状態を稼動可能に設定する、請求項５記載のサーバ情報管理装置。
7. 前記判断部は、前記サーバ群に属するウエブサーバが応答可能であり、且つ、前記サーバ群に対するログインが可能である場合、前記サービスを利用可能な状態であると判断する、請求項５または請求項６に記載のサーバ情報管理装置。
8. 前記検知部は、前記管理対象のシステムに属する複数のサーバの中から操作対象として抽出された操作対象サーバが、前記追加サーバであるか否かを判断することで、前記追加サーバを検知する、請求項１〜請求項７のいずれか一項に記載のサーバ情報管理装置。
9. 管理対象のシステムへのサーバの追加を検知し、
   追加を検知された追加サーバの通信状況としてのセットアップログファイルに含まれるセットアップ時の通信ログと、前記追加サーバに関する管理情報と、前記追加サーバの通信先サーバに関する管理情報とに基づき、前記追加サーバの属性を特定する、
   処理をコンピュータに実行させる、サーバ情報管理プログラム。
10. コンピュータが、
    管理対象のシステムへのサーバの追加を検知し、
    追加を検知された追加サーバの通信状況としてのセットアップログファイルに含まれるセットアップ時の通信ログと、前記追加サーバに関する管理情報と、前記追加サーバの通信先サーバに関する管理情報とに基づき、前記追加サーバの属性を特定する、サーバ情報管理方法。

Images