JP2009230458A - 構成チェックシステム - Google Patents

Abstract

【課題】負荷分散システムにおいて、サーバ間には構成ファイルの差異がない場合であっても、構成ファイルの意図しない変更を検知できる構成チェックシステム等を提供する。
【解決手段】ＡＰサーバ３−１は、リリース管理サーバ５からリリース対象リストを取得する。次に、ＡＰサーバ３−１は、自らが有するファイルについて前回チェック時との差分を確認する。ＡＰサーバ３−１は、確認結果が「差異あり」の場合、差異がリリース対象リストに存在するかどうか確認する。更に、ＡＰサーバ３−１は、確認結果が「存在する」の場合、現在の比較ファイル（今回比較ファイル）を記憶部２３に保存する。
【選択図】図３

Description

本発明は、サーバの構成をチェックする構成チェックシステムに関する。

現在、多くの企業、学校、自治体などが、サーバの負荷を分散する負荷分散システムを運用している。負荷分散システムにおけるサーバは、基本的には同一の構成である。ここで、構成とは、サーバが保持する様々な構成ファイルの記述内容を指す。構成ファイルとは、サーバが用いる各種のプロトコルに必要な設定ファイル、サーバの製造供給元であるベンダが独自に準備する設定ファイル、サーバが提供するアプリケーションに必要な設定ファイルなど全てを含むものとする。更に、構成ファイルには、例えばフォルダ構成など設定ファイルに記述されない設定も含む概念とする。

このような負荷分散システムにおいて、例えば、システムが提供するアプリケーションのバージョンアップ、不具合対応などによって、構成ファイルを修正する場合がある。このとき、システムに含まれる一部のサーバに対して構成ファイルが修正されなかった場合、障害発生の原因となる。そして、このような原因によって障害が発生した場合、障害の原因（サーバ間の構成ファイルに差異があること）を突き止めることは非常に困難である。

そこで、二つのサーバ間の構成ファイルに差異があることを検知する仕組みが考案されている（特許文献１参照）。
特許文献１に記載の仕組みでは、構成が同じ２つのサーバが存在する場合において、一方のサーバに何らかの障害（構成ファイルの一部が意図せず書き換えられていること）が発生した場合等に、これら２つのサーバの構成ファイルの差異を検知する。
特開２００５−２６６９１６号公報

しかしながら、特許文献１に記載の仕組みでは、二つのサーバ間の構成ファイルに差異があることしか検知できない。従って、例えば、（１）全てのサーバがウィルス感染し、全てのサーバの構成ファイルが同じように書き換えられたケース、（２）人為的なミスによって全てのサーバに対してリリースを失敗し、全てのサーバの構成ファイルが古いバージョンとなっているケース、などでは、異常であることを検知することができない。

本発明は、前述した問題点に鑑みてなされたもので、その目的は、負荷分散システムにおいて、サーバ間には構成ファイルの差異がない場合であっても、構成ファイルの意図しない変更を検知できる構成チェックシステム等を提供することである。また、副次的な目的として、リリース管理を効率的に行うことができる構成チェックシステム等を提供することである。

前述した目的を達成するために第１の発明は、アプリケーションサーバと、アプリケーションのリリースを管理するリリース管理サーバと、システム全体の運用を監視する運用監視サーバとが互いに接続されており、アプリケーションサーバの構成をチェックする構成チェックシステムであって、リリース管理サーバは、特定のリリース作業においてリリース対象となった変更箇所のリストであるリリース対象リストを保持する手段、を具備し、アプリケーションサーバは、前回チェック対象とした比較ファイルである前回比較ファイルを保持する前回分保持手段と、現在インストールされているファイル群から今回チェック対象とする比較ファイルである今回比較ファイルを生成する比較ファイル生成手段と、前記比較ファイル生成手段によって生成した今回比較ファイルと、前記前回分保持手段が保持する前回比較ファイルとの差分を確認する第１の差分確認手段と、前記第１の差分確認手段による確認結果が差異ありの場合、リリース管理サーバからリリース対象リストを取得し、差異がリリース対象リストに存在するかどうかを確認するリリース対象確認手段と、前記リリース対象確認手段による確認結果が不存在の場合、運用監視サーバに異常があることを通知する第１の異常通知手段と、を具備することを特徴とする構成チェックシステムである。

前記前回分保持手段は、前記第１の差分確認手段によって差分を確認した後、確認結果に関わらず、前記第１の差分確認手段によって生成した今回比較ファイルを、前回比較ファイルとして保持することが望ましい。また、アプリケーションサーバは、前記前回分保持手段が保持した前回比較ファイルを履歴データとして蓄積する履歴蓄積手段、を更に具備することが望ましい。また、リリース管理サーバは、リリースごとのファイルの変更の履歴データを保持する変更履歴保持手段、を更に具備し、アプリケーションサーバは、前記変更履歴保持手段によってリリース管理サーバが保持する履歴データと、前記履歴蓄積手段によってアプリケーションサーバが保持する履歴データとを比較する履歴比較手段、を更に具備することが望ましい。また、リリース管理サーバは、特定のバージョンのファイル群から比較元ファイルを生成する比較元ファイル生成手段、を更に具備し、アプリケーションサーバは、リリース管理サーバから比較元ファイルを取得し、取得した比較元ファイルと今回比較ファイルとの差分を確認する第２の差分確認手段と、前記第２の差分確認手段による確認結果が差異ありの場合、運用監視サーバに異常があることを通知する第２の異常通知手段と、を更に具備することが望ましい。

また、前記比較ファイル生成手段が生成する今回比較ファイル、及び、前記比較元ファイル生成手段が生成する比較元ファイルは、それぞれの対象とするファイル群を要約したものであっても良い。また、前記比較ファイル生成手段は、対象のファイル群から各ファイルが属するソフトウェアのレイヤごとに区分して、今回比較ファイルを生成するものであっても良い。また、前記比較ファイル生成手段は、対象のファイル群から各ファイルが属するソフトウェアのレイヤごとに区分して、今回比較ファイルを生成し、かつ、前記比較元ファイル生成手段は、対象のファイル群から各ファイルが属するソフトウェアのレイヤごとに区分して、比較元ファイルを生成するものであっても良い。

第２の発明は、アプリケーションサーバと、アプリケーションのリリースを管理するリリース管理サーバと、システム全体の運用を監視する運用監視サーバとが互いに接続されており、アプリケーションサーバの構成をチェックする構成チェックシステムであって、アプリケーションサーバは、現在インストールされているファイル群から今回チェック対象とする比較ファイルである今回比較ファイルを生成し、生成した今回比較ファイルをリリース管理サーバに送信する比較ファイル送信手段、を具備し、リリース管理サーバは、特定のリリース作業においてリリース対象となった変更箇所のリストであるリリース対象リストを保持する手段と、前回チェック対象とした比較ファイルである前回比較ファイルを保持する前回分保持手段と、アプリケーションサーバから受信した今回比較ファイルと、前記前回分保持手段が保持する前回比較ファイルとの差分を確認する第１の差分確認手段と、前記第１の差分確認手段による確認結果が差異ありの場合、リリース管理サーバからリリース対象リストを取得し、差異がリリース対象リストに存在するかどうかを確認するリリース対象確認手段と、前記リリース対象確認手段による確認結果が不存在の場合、運用監視サーバに異常があることを通知する第１の異常通知手段と、を具備することを特徴とする構成チェックシステムである。

また、前記前回分保持手段は、前記第１の差分確認手段によって差分を確認した後、確認結果に関わらず、アプリケーションサーバから受信した今回比較ファイルを、前回比較ファイルとして保持することが望ましい。また、リリース管理サーバは、特定のバージョンのファイル群から比較元ファイルを生成する比較元ファイル生成手段と、前記比較元ファイル生成手段によって生成した比較元ファイルと、アプリケーションサーバから受信した今回比較ファイルとの差分を確認する第２の差分確認手段と、前記第２の差分確認手段による確認結果が差異ありの場合、運用監視サーバに異常があることを通知する第２の異常通知手段と、を更に具備することが望ましい。

第３の発明は、アプリケーションサーバと、システム全体の運用を監視する運用監視サーバとが互いに接続されており、アプリケーションサーバの構成をチェックする構成チェックシステムであって、アプリケーションサーバは、特定のリリース作業においてリリース対象となった変更箇所のリストであるリリース対象リストを保持する手段と、前回チェック対象とした比較ファイルである前回比較ファイルを保持する前回分保持手段と、現在インストールされているファイル群から今回チェック対象とする比較ファイルである今回比較ファイルを生成する比較ファイル生成手段と、前記比較ファイル生成手段によって生成した今回比較ファイルと、前記前回分保持手段が保持する前回比較ファイルとの差分を確認する第１の差分確認手段と、前記第１の差分確認手段による確認結果が差異ありの場合、リリース管理サーバからリリース対象リストを取得し、差異がリリース対象リストに存在するかどうかを確認するリリース対象確認手段と、前記リリース対象確認手段による確認結果が不存在の場合、運用監視サーバに異常があることを通知する第１の異常通知手段と、を具備することを特徴とする構成チェックシステムである。

本発明により、負荷分散システムにおいて、サーバ間には構成ファイルの差異がない場合であっても、構成ファイルの意図しない変更を検知できる構成チェックシステム等を提供することができる。また、リリース管理を効率的に行うことができる構成チェックシステム等を提供することができる。

以下図面に基づいて、本発明の実施形態を詳細に説明する。

＜第１の実施形態＞
最初に、図１から図４を参照しながら、第１の実施形態について説明する。また、図５、図６を参照しながら、第１の実施形態に係る実施例について説明する。

図１は、第１の実施形態に係る構成チェックシステム１の概要を示す図である。図１に示すように、構成チェックシステム１は、ＡＰ（アプリケーション）サーバ３−１、ＡＰサーバ３−２、・・・、ＡＰサーバ３−３、リリース管理サーバ５、運用監視サーバ７が内部ネットワーク９−１を介して接続している。また、ＡＰサーバ３−１、ＡＰサーバ３−２、・・・、ＡＰサーバ３−３は、負荷分散システムを構成しており、負荷分散装置１１、外部ネットワーク９−２を介して、端末１３−１、端末１３−２、・・・、端末１３−３からの要求に応答している。

ＡＰサーバ３−１、ＡＰサーバ３−２、・・・、ＡＰサーバ３−３は、同一の機能を有するサーバ群であり、負荷分散システムにおける負荷分散ノード（＝負荷分散装置１１によって負荷が分散されるサーバ）である。負荷分散ノードの数は、例えば、数台から数百台であり、本発明は、小規模な負荷分散システムから大規模な負荷分散システムまで適用可能である。ＡＰサーバ３−１、ＡＰサーバ３−２、・・・、ＡＰサーバ３−３は、例えば、外部ネットワーク９−２を介して特定のアプリケーションを提供するウェブアプリケーションシステム、特定のサービスを提供するウェブサービスシステムなどの応答側の役割を果たす。

リリース管理サーバ５は、ＡＰサーバ３−１、ＡＰサーバ３−２、・・・、ＡＰサーバ３−３が提供するアプリケーション（ウェブサービスシステムによって提供するサービスも含む。以下、同様とする。）のリリースを管理する。ここで、リリースとは、アプリケーションの仕様変更、不具合対応などによって、アプリケーションに含まれるファイル（構成ファイル等）に変更を加える必要が生じた場合、本番環境（ユーザに対して実際にアプリケーションを提供している環境）に変更を加えたファイルを配置することである。また、リリース管理サーバ５は、ファイルの変更も管理する。

運用監視サーバ７は、負荷分散システムの運用を監視する。具体的には、ＡＰサーバ３−１、ＡＰサーバ３−２、・・・、ＡＰサーバ３−３、リリース管理サーバ５、負荷分散装置１１などの動作状態を一元的に監視し、異常が発生したときに関係者に通知する。通常、監視対象のサーバには、エージェントと呼ばれるソフトウェアをインストールする。そして、運用監視サーバ７は、エージェントの機能によって、各サーバのプロセス、メモリ、ハードディスクの利用状況、提供するアプリケーションの稼働状況のデータを収集する。

内部ネットワーク９−１は、いわゆるファイアウォール（図示しない）によって外部からの侵入を防御されているネットワークである。内部ネットワーク９−１は、例えば、構成チェックシステム１の配置場所に敷設されたＬＡＮ（Ｌｏｃａｌ
Ａｒｅａ Ｎｅｔｗｏｒｋ）である。

負荷分散装置１１は、端末１３−１、端末１３−２、・・・、端末１３−３からの要求を、ＡＰサーバ３−１、ＡＰサーバ３−２、・・・、ＡＰサーバ３−３に送信する。また、負荷分散装置１１は、ＡＰサーバ３−１、ＡＰサーバ３−２、・・・、ＡＰサーバ３−３からの応答を、端末１３−１、端末１３−２、・・・、端末１３−３に送信する。負荷分散装置１１は、要求を各サーバに分散し、一定の応答速度を維持する。また、負荷分散装置１１は、一部のサーバに異常が発生した場合であっても、提供するアプリケーションの稼動を維持する。

端末１３−１、端末１３−２、・・・、端末１３−３は、アプリケーションのユーザが利用する。端末１３−１、端末１３−２、・・・、端末１３−３は、ユーザの指示に従い、負荷分散装置１１（最終的には、ＡＰサーバ３−１、ＡＰサーバ３−２、・・・、ＡＰサーバ３−３）に対し、要求を送信する。

外部ネットワーク９−２は、いわゆるファイアウォール外のネットワークであり、例えば、インターネットである。

図２は、ＡＰサーバ３−１、ＡＰサーバ３−２、・・・、ＡＰサーバ３−３、リリース管理サーバ５、運用監視サーバ７等を実現するコンピュータのハードウェア構成図である。尚、図２のハードウェア構成は一例であり、用途、目的に応じて様々な構成を採ることが可能である。

コンピュータは、制御部２１、記憶部２３、メディア入出力部２５、通信制御部２７、入力部２９、表示部３１、周辺機器Ｉ／Ｆ部３３等が、バス３５を介して接続される。

制御部２１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成される。

ＣＰＵは、記憶部２３、ＲＯＭ、記録媒体等に格納されるプログラムをＲＡＭ上のワークメモリ領域に呼び出して実行し、バス３５を介して接続された各装置を駆動制御し、ＡＰサーバ３−１、ＡＰサーバ３−２、・・・、ＡＰサーバ３−３、リリース管理サーバ５、運用監視サーバ７等が行う後述する処理を実現する。
ＲＯＭは、不揮発性メモリであり、コンピュータのブートプログラムやＢＩＯＳ等のプログラム、データ等を恒久的に保持している。
ＲＡＭは、揮発性メモリであり、記憶部２３、ＲＯＭ、記録媒体等からロードしたプログラム、データ等を一時的に保持するとともに、制御部２１が各種処理を行う為に使用するワークエリアを備える。

記憶部２３は、ＨＤＤ（ハードディスクドライブ）であり、制御部２１が実行するプログラム、プログラム実行に必要なデータ等が格納される。プログラムに関しては、ＯＳ（オペレーティングシステム）に相当する制御プログラムや、後述する処理をコンピュータに実行させるためのアプリケーションプログラムが格納されている。
これらの各プログラムコードは、制御部２１により必要に応じて読み出されてＲＡＭに移され、ＣＰＵに読み出されて各種の手段として実行される。

メディア入出力部２５（ドライブ装置）は、データの入出力を行い、例えば、ＣＤドライブ（−ＲＯＭ、−Ｒ、−ＲＷ等）、ＤＶＤドライブ（−ＲＯＭ、−Ｒ、−ＲＷ等）、ＭＯドライブ等のメディア入出力装置を有する。

通信制御部２７は、通信制御装置、通信ポート等を有し、コンピュータとネットワーク９（内部ネットワーク９−１、外部ネットワーク９−２）間の通信を媒介する通信インタフェースであり、ネットワーク９を介して、他のコンピュータ間との通信制御を行う。

入力部２９は、データの入力を行い、例えば、キーボード、マウス等のポインティングデバイス、テンキー等の入力装置を有する。
入力部２９を介して、コンピュータに対して、操作指示、動作指示、データ入力等を行うことができる。

表示部３１は、ＣＲＴモニタ、液晶パネル等のディスプレイ装置、ディスプレイ装置と連携してコンピュータのビデオ機能を実現するための論理回路等（ビデオアダプタ等）を有する。

周辺機器Ｉ／Ｆ（インタフェース）部１５は、コンピュータに周辺機器を接続させるためのポートであり、周辺機器Ｉ／Ｆ部３３を介してコンピュータは周辺機器とのデータの送受信を行う。周辺機器Ｉ／Ｆ部３３は、ＵＳＢやＩＥＥＥ１３９４やＲＳ−２３２Ｃ等で構成されており、通常複数の周辺機器Ｉ／Ｆを有する。周辺機器との接続形態は有線、無線を問わない。

バス３５は、各装置間の制御信号、データ信号等の授受を媒介する経路である。

次に、図３、図４を参照しながら、本発明における定時差分確認処理およびリリース時差分確認処理について説明する。
図３は、定時差分確認処理におけるＡＰサーバ３−１のアクティビティ図である。尚、ＡＰサーバ３−２、・・・、ＡＰサーバ３−３も、同様に図３に示す処理を行う。

図３に示す処理は、運用上、定期的に行うものである。図３に示す処理は、例えば、日次バッチによって行っても良い。また、運用監視サーバ７がＡＰサーバ３−１等に実行開始命令を送信するようにしても良い。また、管理者がいずれかの装置（ＡＰサーバ３−１、リリース管理サーバ５、監視サーバ７等）の入力部２９を介して実行開始命令を入力するようにしても良い。

ＡＰサーバ３−１は、定時差分確認処理を開始すると（５１）、リリース管理サーバ５からリリース対象リストを取得する（５２）。リリース対象リストとは、特定のリリース作業においてリリース対象となった変更箇所のリストである。リリース対象リストは、例えば、特定のリリース作業においてリリース対象となったファイル単位のリストでも良い。また、リリース対象リストは、例えば、特定のリリース作業において変更が行われた箇所（例えば、データ項目単位）のリストであっても良い。

次に、ＡＰサーバ３−１は、自らが有するファイルについて前回チェック時との差分を確認する（５３）。具体的には、ＡＰサーバ３−１は、記憶部２３に前回チェック対象とした比較ファイルである前回比較ファイルを保持しておく（前回分保持手段）。そして、ＡＰサーバ３−１は、現在インストールされているファイル群から今回チェック対象とする比較ファイルである今回比較ファイルを生成する（比較ファイル生成手段）。次に、比較ファイル生成手段によって生成した今回比較ファイルと、前回分保持手段が保持する前回比較ファイルとの差分を確認する（第１の差分確認手段）。

ＡＰサーバ３−１は、第１の差分確認手段による確認結果が「差異なし」の場合（５４の[差異なし]）、定時差分確認処理を終了する（５９）。
一方、ＡＰサーバ３−１は、第１の差分確認手段による確認結果が「差異あり」の場合（５４の[差異あり]）、差異がリリース対象リストに存在するかどうか確認する（リリース対象確認手段）（５５）。

ＡＰサーバ３−１は、リリース対象確認手段による確認結果が「存在する」の場合（５６の[存在する]）、現在の比較ファイル（今回比較ファイル）を記憶部２３に保存し（前回分保持手段）（５８）、定時差分確認処理を終了する（５９）。
一方、ＡＰサーバ３−１は、リリース対象確認手段による確認結果が「存在しない」の場合（５６の[存在しない]）、運用監視サーバ７に異常があることを通知する（第１の異常通知手段）（５７）。そして、ＡＰサーバ３−１は、現在の比較ファイル（今回比較ファイル）を記憶部２３に保存し（前回分保持手段）（５８）、定時差分確認処理を終了する（５９）。

図３では、ＡＰサーバ３−１は、リリース管理サーバ５からリリース対象リストを取得することとしたが、ＡＰサーバ３−１がリリース対象リストを保持しておくようにしても良い。例えば、リリース作業の際、ＡＰサーバ３−１は、リリース前の構成と、リリース後の構成との差分を取得し、この差分がある箇所（ファイル単位でも良いし、データ項目単位でも良い。）のリストをリリース対象リストとして保持しておくようにしても良い。この場合、リリース管理サーバ５が存在しなくても、ＡＰサーバ３−１は、図３に示す定時差分確認処理を実行することができる。

図３では、リリース対象確認手段による確認を行うこととしたが、この確認を行わないようにしても良い。すなわち、第１の差分確認手段による確認結果が「差異あり」の場合、ＡＰサーバ３−１は、リリース対象確認手段による確認を行わず、運用監視サーバ７に異常があることを通知するようにしても良い。

前述のように、前回分保持手段は、第１の差分確認手段によって差分を確認した後、確認結果に関わらず、第１の差分確認手段によって生成した今回比較ファイルを、前回比較ファイルとして保持する。

更に、ＡＰサーバ３−１は、前回分保持手段が保持した前回比較ファイルを履歴データとして蓄積するようにしても良い（履歴蓄積手段）。また、更に、ＡＰサーバ３−１は、リリース管理サーバ５が保持するリリースごとのファイルの変更の履歴データ（通常、バージョン情報を有する。）と、履歴蓄積手段によって蓄積した履歴データとを比較する機能（履歴比較手段）を具備しても良い。

例えば、あるファイルのデータ項目の変更について、リリース管理サーバ５では、１００（Ｖｅｒ１．０）−＞１０１（Ｖｅｒ１．１）−＞１０２（Ｖｅｒ１．２）−＞１０３（Ｖｅｒ１．３）という履歴データを保持しているとする。一方、ＡＰサーバ３−１では、１００（Ｖｅｒ１．０のリリース日）−＞１１１（Ｖｅｒ１．１のリリース日）−＞１１２（Ｖｅｒ１．２のリリース日）−＞１１３（Ｖｅｒ１．３のリリース日）という履歴データを保持しているとする。

前述の状況において、ＡＰサーバ３−１が具備する履歴比較手段による追跡調査について説明する。ＡＰサーバ３−１は、リリース管理サーバ５が保持するＶｅｒ１．０の値「１００」と、ＡＰサーバ３−１が保持するＶｅｒ１．０のリリース日の値「１００」とを比較し、両者が一致することを確認する。次に、ＡＰサーバ３−１は、リリース管理サーバ５が保持するＶｅｒ１．１の値「１０１」と、ＡＰサーバ３−１が保持するＶｅｒ１．１のリリース日の値「１１１」とを比較し、両者が一致しないことを確認する。そして、ＡＰサーバ３−１は、Ｖｅｒ１．１のリリース日において、ファイルが一致していないことを出力する。この場合、Ｖｅｒ１．１のリリース時に不正ファイルがインストールされたことが分かる。つまり、履歴比較手段によって、アプリケーションに含まれるファイルがいつ不正に変更されたかを過去に遡って追跡調査することもできる。

このように、図３に示す定時差分確認処理を行うことで、例えば、（１）全てのサーバがウィルス感染し、全てのサーバの構成ファイルが同じように書き換えられたケース、（２）人為的なミスによって全てのサーバに対してリリースを失敗し、全てのサーバの構成ファイルが古いバージョンとなっているケース、などであっても、異常を検知し、更に、詳細な追跡調査を行うことができる。

図４は、リリース時差分確認処理におけるＡＰサーバ３−１のアクティビティ図である。尚、ＡＰサーバ３−２、・・・、ＡＰサーバ３−３も、同様に図４に示す処理を行う。

図４に示す処理は、運用上、リリース時に行うものである。図４に示す処理の実行は、例えば、管理者がいずれかの装置（ＡＰサーバ３−１、リリース管理サーバ５、監視サーバ７等）の入力部２９を介して実行開始命令を入力するようにしても良い。図４に示す処理の前処理として、リリース管理サーバ５は、特定のバージョン（管理者が比較を行いたいバージョン）のファイル群から比較元ファイルを生成しておく（比較元ファイル生成手段）。比較元ファイル生成手段の実行は、例えば、管理者がいずれかの装置（ＡＰサーバ３−１、リリース管理サーバ５、監視サーバ７等）の入力部２９を介して実行開始命令を入力するようにしても良い。

ＡＰサーバ３−１は、リリース時差分確認処理を開始すると（７１）、リリース管理サーバ５から比較元ファイルを取得する（７２）。次に、ＡＰサーバ３−１は、現在インストールされているファイル群からチェック対象とする比較ファイルを生成し（７３）、比較ファイルと比較元ファイルとを比較し、差分を確認する（第２の差分確認手段）（７４）。

ＡＰサーバ３−１は、第２の差分確認手段による確認結果が「差異なし」の場合（７５の[差異なし]）、リリース時差分確認処理を終了する（７７）。
一方、ＡＰサーバ３−１は、第２の差分確認手段による確認結果が「差異あり」の場合（７５の[差異あり]）、運用監視サーバ７に異常を通知し（第２の異常通知手段）（７６）、リリース時差分確認処理を終了する（７７）。

このように、図４に示すリリース時差分確認処理を行うことで、本番環境の構成が、特定のバージョンのファイル群の構成と一致するかどうかを確認することができる。

次に、図５、図６を参照しながら、第１の実施形態に係る実施例について説明する。
図５は、第１の実施形態に係る実施例の全体構成を示す図である。本実施例は、負荷分散システムに構成チェックシステム１を組み込んだものとなっている。

図５に示すように、本実施例では、構成チェックシステム１は、ＡＰサーバ３、リリース管理サーバ５、運用監視サーバ７等を備える。また、オペレータ１５は、ＡＰサーバ３が提供するアプリケーションを監視している。但し、オペレータ１５は、ＡＰサーバ３が提供するアプリケーションに係る知識を必要としない。また、オペレータ１５は、障害が発生したときに、１７−１の担当者Ｘ、１７−２の担当者Ｙに連絡する手段（電話、ＦＡＸ、電子メールなどであるが、本実施例では、連絡手段を特に限定しない。）を有している。担当者Ｘ、担当者Ｙは、ＡＰサーバ３が提供するアプリケーションに係る知識を有するものである。

最初に、ステップ１０１、ステップ１０２、ステップ３０１によって示される定時差分確認処理の流れについて説明する。

＜ステップ１０１＞
ＡＰサーバ３が有する日次バッチのスケジュール機能によって、定時差分確認処理の実行開始指示がなされると、ＡＰサーバ３は、比較対象ファイル９１から今回比較ファイルを生成し、生成した今回比較ファイルと、記憶部２３上の保管ディレクトリ１９に記憶されている前回比較ファイル９２との差分を確認する。

ここで、今回比較ファイルの生成基準について説明する。今回比較ファイルは、例えば、比較対象ファイル９１を要約したダイジェスト比較ファイルである。ダイジェスト比較ファイルとは、例えば、比較対象ファイル９１ごとにハッシュ関数によってハッシュ値を算出し、算出したハッシュ値を、例えば、ソフトウェアのレイヤごとにまとめたものである。

＜ステップ１０２＞
ＡＰサーバ３は、ステップ１０１における確認結果が「差異あり」の場合、例えば、生成した今回比較ファイルの種別（例えば、どのソフトウェアのレイヤに係る比較対象ファイル９１を基に生成したかを示すもの）を識別する識別子を埋め込んだメッセージを運用監視サーバ７に送信する。これに対し、運用監視サーバ７は、担当者情報９５を有している。担当者情報９５は、識別子をキーとして、担当者の氏名、担当者の連絡先などを有する。

＜ステップ３０１＞
運用監視サーバ７は、ＡＰサーバ３から受信したメッセージに従い、オペレータ１５に障害を通知するため、表示部３１にメッセージの内容、および担当者情報９５を表示する。また、運用監視サーバ７は、合わせて、警告灯としてのパトランプ（図示しない。）に対して、点灯指示を示す制御信号を送信するようにしても良い。これに対して、オペレータ１５は、表示部３１に表示されているメッセージの内容、および担当者情報９５を確認し、担当者を特定する。そして、オペレータ１５は、特定した担当者へ、障害が発生していることを連絡する。これによって、オペレータ１５がＡＰサーバ３によって提供されるアプリケーションに係る知識を有していなくても、迅速に障害対応を行うことができる。尚、運用監視サーバ７が、特定した担当者に係るメールアドレスを宛先とした電子メールを送信するようにしても良い。

次に、ステップ２０１、ステップ２０２、ステップ２０３、ステップ２０４、ステップ３０１によって示される定時差分確認処理の流れについて説明する。尚、以下の説明において、ＡＰサーバ３には、リリース管理サーバ５が保持するＶｅｒ２．０のファイル群がインストールされているものとする。

＜ステップ２０１＞
リリース管理サーバ５は、特定のバージョンのファイル群であるＶｅｒ２．０のファイル群９３−３から、比較元ファイルであるダイジェストファイル９４ｂを生成する。ダイジェストファイル９４ｂは、Ｖｅｒ２．０のファイル群９３−３を要約したものである。ここで、ファイル群９３−３の中には、サーバごとに異なるデータ項目、例えば、コンピュータ名（内部ネットワーク９−２上で識別可能な名称）、ＩＰアドレスなどが含まれている場合がある。この場合、リリース管理サーバ５は、これらのデータ項目を削除したワークファイルを生成し、生成したワークファイルに対してハッシュ値を算出する。そして、リリース管理サーバ５は、算出したハッシュ値を、ソフトウェアのレイヤごとにまとめて、ダイジェストファイル９４ｂとする。

＜ステップ２０２＞
ＡＰサーバ３は、比較対象ファイル９１からチェック対象とするダイジェストファイル９４ａを生成する。ダイジェストファイル９４ａの生成基準は、ステップ２０１におけるダイジェストファイル９４ｂの生成基準と同一とする。すなわち、サーバごとに異なるデータ項目については、これらのデータ項目を削除したワークファイルを生成し、生成したワークファイルに対してハッシュ値を算出する。そして、ＡＰサーバ３は、算出したハッシュ値を、ソフトウェアのレイヤごとにまとめて、ダイジェストファイル９４ａとする。

＜ステップ２０３＞
ＡＰサーバ３は、ダイジェストファイル９４ａとダイジェストファイル９４ｂとの差分を確認する。ダイジェストファイル９４ａおよびダイジェストファイル９４ｂがソフトウェアのレイヤごとにまとめていることから、ＡＰサーバ３は、差異がある場合には、どのソフトウェアのレイヤに差異があるかを判別可能となっている。

＜ステップ２０４＞
ＡＰサーバ３は、ステップ２０３における確認結果が「差異あり」の場合、例えば、生成した今回比較ファイルの種別（例えば、どのソフトウェアのレイヤに係る比較対象ファイル９１を基に生成したかを示すもの）を識別する識別子を埋め込んだメッセージを運用監視サーバ７に送信する。これに対し、運用監視サーバ７は、担当者情報９５を有している。担当者情報９５は、識別子をキーとして、担当者の氏名、担当者の連絡先などを有する。識別子の埋め込み処理については、図６の説明にて後述する。

＜ステップ３０１＞
運用監視サーバ７は、ＡＰサーバ３から受信したメッセージに従い、オペレータ１５に障害を通知するため、表示部３１にメッセージの内容、および担当者情報９５を表示する。また、運用監視サーバ７は、合わせて、警告灯としてのパトランプ（図示しない。）に対して、点灯指示を示す制御信号を送信するようにしても良い。

図６は、担当者への障害通知の一例を示す図である。図６に示す例では、構成チェックシステム１がチェック対象とするＡＰサーバ３のソフトウェアのレイヤは、ＯＳ、ミドルウェア、アプリケーションである。また、構成ファイルである比較対象ファイルは、ソフトウェアのレイヤごとに、共通ファイルと個別ファイルに分けられる。共通ファイルとは、全てのＡＰサーバ３に共通する構成を記述したファイルである。また、個別ファイルとは、各ＡＰサーバ固有の構成を記述したファイルである。

図６に示す構成チェック処理では、ＡＰサーバ３は、比較対象ファイルをソフトウェアのレイヤごと、及び共通ファイルか個別ファイルかに区分し、リリース管理サーバ５が保持する特定のバージョンのファイル群を比較対象とする。
具体的には、ＡＰサーバ３は、自らのアプリケーションの共通ファイル９１−１ａとリリース管理サーバ５のアプリケーションの共通ファイル９１−１ｂを比較する。また、ＡＰサーバ３は、自らのアプリケーションの個別ファイル９１−２ａとリリース管理サーバ５のアプリケーションの個別ファイル９１−２ｂを比較する。
また、ＡＰサーバ３は、自らのミドルウェアの共通ファイル９１−３ａとリリース管理サーバ５のミドルウェアの共通ファイル９１−３ｂを比較する。また、リリース管理サーバ５は、自らのミドルウェアの個別ファイル９１−４ａとリリース管理サーバ５のミドルウェアの個別ファイル９１−４ｂを比較する。
また、ＡＰサーバ３は、自らのＯＳの共通ファイル９１−５ａとリリース管理サーバ５のＯＳの共通ファイル９１−５ｂを比較する。また、ＡＰサーバ３は、自らのＯＳの個別ファイル９１−６ａとリリース管理サーバ５のＯＳの個別ファイル９１−６ｂを比較する。

ＡＰサーバ３は、共通ファイル同士の比較であれば、例えば、一致しない箇所が存在する場合、すなわち、両ファイルに差異がある場合、異常があると判定する。一方、ＡＰサーバ３は、個別ファイル同士の比較であれば、例えば、一致しない箇所が存在しない場合、すなわち、両ファイルに差異がない場合、異常があると判定する。これによって、例えば、サーバごとに異なるＩＰアドレス、サーバ名などの設定漏れ（基にしたファイルの内容を変更せずにそのままインストールしてしまった場合など）を検知することができる。

そして、ＡＰサーバ３は、アプリケーションに関する比較結果に異常があった場合、担当者Ｘに障害を通知するため、生成した比較ファイルの種別としてアプリケーションを示す識別子を埋め込んだメッセージを運用監視サーバ７に送信する。
一方、ＡＰサーバ３は、ミドルウェアおよび／またはＯＳに関する比較結果に異常があった場合、担当者Ｙに障害を通知するため、生成した比較ファイルの種別としてミドルウェアおよび／またはＯＳを示す識別子を埋め込んだメッセージを運用監視サーバ７に送信する。

＜第２の実施形態＞
次に、図７から図９を参照しながら、第２の実施形態について説明する。以下では、第１の実施形態に係る構成要素と同様の構成要素については同一の番号を付し、重複した説明を避けることとする。

図７は、第２の実施形態に係る構成チェックシステム１ｃの概要を示す図である。図７に示すように、構成チェックシステム１ｃは、ＡＰサーバ３−１ｃ、ＡＰサーバ３−２ｃ、・・・、ＡＰサーバ３−３ｃ、リリース管理サーバ５ｃ、運用監視サーバ７が内部ネットワーク９−１を介して接続している。

第１の実施形態に係る構成チェックシステム１では、構成チェックプログラム２がＡＰサーバ３−１、ＡＰサーバ３−２、・・・、ＡＰサーバ３−３にインストールされていたが、第２の実施形態に係る構成チェックシステム１ｃでは、構成チェックプログラム２ｃがリリース管理サーバ５ｃにインストールされている。従って、図３に示す定時差分確認処理、及び図５に示すリリース時差分確認処理は、リリース管理サーバ５ｃが行う。

次に、図８、図９を参照しながら、本発明における定時差分確認処理およびリリース時差分確認処理について説明する。
図８は、定時差分確認処理におけるリリース管理サーバ５ｃのアクティビティ図である。
以下では、ＡＰサーバ３−１ｃに対する定時差分確認処理について説明するが、ＡＰサーバ３−２ｃ、ＡＰサーバ３−３ｃに対しても同様の処理を行う。図８に示す処理の前提として、ＡＰサーバ３−１ｃは、今回チェック対象とする今回分比較ファイルを生成し、生成した今回比較ファイルをリリース管理サーバ５ｃに送信している（比較ファイル送信手段）。従って、図８に示す処理は、例えば、リリース管理サーバ５ｃが今回比較ファイルを受信すると実行するようにしても良い。また、管理者がリリース管理サーバ５ｃの入力部２９を介して実行開始命令を入力するようにしても良い。

リリース管理サーバ５ｃは、定時差分確認処理を開始すると（６１）、現在の比較ファイルである今回比較ファイルを取得する（６２）。

次に、リリース管理サーバ５ｃは、前回チェック時との差分を確認する（６３）。具体的には、リリース管理サーバ５ｃは、記憶部２３に前回チェック対象とした比較ファイルである前回比較ファイルを保持しておく（前回分保持手段）。そして、今回比較ファイルと、前回分保持手段が保持する前回比較ファイルとの差分を確認する（第１の差分確認手段）。

リリース管理サーバ５ｃは、第１の差分確認手段による確認結果が「差異なし」の場合（６４の[差異なし]）、定時差分確認処理を終了する（６９）。
一方、リリース管理サーバ５ｃは、第１の差分確認手段による確認結果が「差異あり」の場合（６４の[差異あり]）、差異がリリース対象リストに存在するかどうか確認する（リリース対象確認手段）（６５）。リリース対象リストは、リリース管理サーバ５ｃの記憶部２３に保持している。

リリース管理サーバ５ｃは、リリース対象確認手段による確認結果が「存在する」の場合（６６の[存在する]）、現在の比較ファイル（今回比較ファイル）を記憶部２３に保存し（前回分保持手段）（６８）、定時差分確認処理を終了する（６９）。
一方、リリース管理サーバ５ｃは、リリース対象確認手段による確認結果が「存在しない」の場合（６６の[存在しない]）、運用監視サーバ７に異常があることを通知する（第１の異常通知手段）（６７）。そして、リリース管理サーバ５ｃは、現在の比較ファイル（今回比較ファイル）を記憶部２３に保存し（前回分保持手段）（６８）、定時差分確認処理を終了する（６９）。

前述のように、前回分保持手段は、第１の差分確認手段によって差分を確認した後、確認結果に関わらず、第１の差分確認手段によって生成した今回比較ファイルを、前回比較ファイルとして保持する。更に、リリース管理サーバ５ｃは、前回分保持手段が保持した前回比較ファイルを履歴データとして蓄積するようにしても良い（履歴蓄積手段）。これによって、障害が発生した場合であっても、アプリケーションに含まれるファイルがいつ変更されたかを過去に遡って追跡調査することができる。

このように、図８に示す定時差分確認処理を行うことで、例えば、（１）全てのサーバがウィルス感染し、全てのサーバの構成ファイルが同じように書き換えられたケース、（２）人為的なミスによって全てのサーバに対してリリースを失敗し、全てのサーバの構成ファイルが古いバージョンとなっているケース、などであっても、異常を検知することができる。

図９は、リリース時差分確認処理におけるリリース管理サーバ５ｃのアクティビティ図である。
以下では、ＡＰサーバ３−１ｃに対する定時差分確認処理について説明するが、ＡＰサーバ３−２ｃ、ＡＰサーバ３−３ｃに対しても同様の処理を行う。図９に示す処理の前処理として、ＡＰサーバ３−１ｃは、現在インストールされているファイル群から比較ファイルを生成し、生成した比較ファイルをリリース管理サーバ５ｃに送信している（比較ファイル生成手段）。従って、図９に示す処理は、例えば、リリース管理サーバ５ｃが比較ファイルを受信すると実行するようにしても良い。また、管理者がリリース管理サーバ５ｃの入力部２９を介して実行開始命令を入力するようにしても良い。

リリース管理サーバ５ｃは、リリース時差分確認処理を開始すると（８１）、特定のバージョン（管理者が比較を行いたいバージョン）のファイル群から比較元ファイルを生成する（８２）。次に、リリース管理サーバ５ｃは、比較ファイルを取得する（８３）。次に、リリース管理サーバ５ｃは、比較ファイルと比較元ファイルとを比較し、差分を確認する（第２の差分確認手段）（８４）。

リリース管理サーバ５ｃは、第２の差分確認手段による確認結果が「差異なし」の場合（７５の[差異なし]）、リリース時差分確認処理を終了する（８７）。
一方、リリース管理サーバ５ｃは、第２の差分確認手段による確認結果が「差異あり」の場合（８５の[差異あり]）、運用監視サーバ７に異常を通知し（第２の異常通知手段）（８６）、リリース時差分確認処理を終了する（８７）。

このように、図９に示すリリース時差分確認処理を行うことで、本番環境の構成が、特定のバージョンのファイル群の構成と一致するかどうかを確認することができる。

第２の実施形態では、リリース管理サーバ５ｃが図８に示す定時差分確認処理、及び図９に示すリリース時差分確認処理を行うことで、ＡＰサーバ３−１ｃ等の構成をチェックする。第２の実施形態のように、リリース管理サーバ５ｃが構成チェック処理を行うことで、ＡＰサーバ３−１ｃ等に過度な負荷を与えることはない。従って、２４時間稼動のシステムなど、稼働中に構成チェックを行う場合であっても、システム全体に大きな影響を与えずに、ＡＰサーバ３−１ｃ等の構成をチェックすることができる。

以上、様々な実施の形態について説明したが、全ての実施の形態に適用可能な運用例について説明する。例えば、本発明によって、全てのサーバがウィルス感染し、全てのサーバの構成ファイルが同じように書き換えられたケースなどを検知する為に、定時差分確認処理を実行することができる。また、例えば、本発明によって、人為的なミスによって全てのサーバに対してリリースを失敗し、全てのサーバの構成ファイルが古いバージョンとなっているケース、などを検知するためにリリース時差分確認処理を実行することができる。また、例えば、本発明に係るリリース管理サーバを用いると、最新のバージョンに不具合があっても、リリース管理サーバが旧バージョンを保持していることから、旧バージョンを迅速にインストールすることができる。また、例えば、本発明によって、障害が発生した場合であっても、アプリケーションに含まれるファイルがいつ変更されたかを過去に遡って追跡調査することができる。

また、ＡＰサーバが備える履歴蓄積手段（前回分保持手段が保持した前回比較ファイルを履歴データとして蓄積する手段）を用いると、リリース管理を効率的に行うことができる。例えば、サーバのレンタルを行うサービスを提供する場合を考える。この場合、レンタル対象のサーバは、本発明に係る定時差分確認処理を行うことで、ユーザ（レンタルサーバを借りている者）によってファイルが更新されたかどうかを確認し、更新内容を履歴データとして蓄積しておくことができる。更に、ファイルの更新ごとに課金する仕組みの場合、レンタル対象のサーバは、履歴データを利用して、ユーザに対する課金処理を行うことができる。

以上、添付図面を参照しながら、本発明に係る構成チェックシステム等の好適な実施形態について説明したが、本発明はかかる例に限定されない。当業者であれば、本願で開示した技術的思想の範疇内において、各種の変更例又は修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。

第１の実施形態に係る構成チェックシステム１の概要を示す図 コンピュータのハードウェア構成図 定時差分確認処理におけるＡＰサーバ３−１のアクティビティ図 リリース時差分確認処理におけるＡＰサーバ３−１のアクティビティ図 第１の実施形態に係る実施例の全体構成を示す図 担当者への障害通知の一例を示す図 第２の実施形態に係る構成チェックシステム１ｃの概要を示す図 定時差分確認処理におけるリリース管理サーバ５ｃのアクティビティ図 リリース時差分確認処理におけるリリース管理サーバ５ｃのアクティビティ図

符号の説明

１、１ｃ………構成チェックシステム
３、３−１、３−２、３−３、３−１ｃ、３−２ｃ、３−３ｃ………ＡＰサーバ
５、５ｃ………リリース管理サーバ
７………運用監視サーバ
９………ネットワーク
９−１………内部ネットワーク
９−２………外部ネットワーク
１１………負荷分散装置
１３−１、１３−２、１３−３………端末
１５………オペレータ
１７−１………担当者Ｘ
１７−２………担当者Ｙ
１９………保管ディレクトリ
２１………制御部
２３………記憶部
２５………メディア入出力部
２７………通信制御部
２９………入力部
３１………表示部
３３………周辺機器Ｉ／Ｆ部
３５………バス
９１………比較対象ファイル
９２………前回比較ファイル
９３−１、９３−２、９３−３………ファイル群
９４ａ、９４ｂ………ダイジェストファイル
９５………担当者情報

Claims (13)

1. アプリケーションサーバと、アプリケーションのリリースを管理するリリース管理サーバと、システム全体の運用を監視する運用監視サーバとが互いに接続されており、アプリケーションサーバの構成をチェックする構成チェックシステムであって、
   リリース管理サーバは、
   特定のリリース作業においてリリース対象となった変更箇所のリストであるリリース対象リストを保持する手段、
   を具備し、
   アプリケーションサーバは、
   前回チェック対象とした比較ファイルである前回比較ファイルを保持する前回分保持手段と、
   現在インストールされているファイル群から今回チェック対象とする比較ファイルである今回比較ファイルを生成する比較ファイル生成手段と、
   前記比較ファイル生成手段によって生成した今回比較ファイルと、前記前回分保持手段が保持する前回比較ファイルとの差分を確認する第１の差分確認手段と、
   前記第１の差分確認手段による確認結果が差異ありの場合、リリース管理サーバからリリース対象リストを取得し、差異がリリース対象リストに存在するかどうかを確認するリリース対象確認手段と、
   前記リリース対象確認手段による確認結果が不存在の場合、運用監視サーバに異常があることを通知する第１の異常通知手段と、
   を具備することを特徴とする構成チェックシステム。
2. 前記前回分保持手段は、前記第１の差分確認手段によって差分を確認した後、確認結果に関わらず、前記第１の差分確認手段によって生成した今回比較ファイルを、前回比較ファイルとして保持することを特徴とする請求項１に記載の構成チェックシステム。
3. アプリケーションサーバは、
   前記前回分保持手段が保持した前回比較ファイルを履歴データとして蓄積する履歴蓄積手段、
   を更に具備することを特徴とする請求項２に記載の構成チェックシステム。
4. リリース管理サーバは、
   リリースごとのファイルの変更の履歴データを保持する変更履歴保持手段、
   を更に具備し、
   アプリケーションサーバは、
   前記変更履歴保持手段によってリリース管理サーバが保持する履歴データと、前記履歴蓄積手段によってアプリケーションサーバが保持する履歴データとを比較する履歴比較手段、
   を更に具備することを特徴とする請求項３に記載の構成チェックシステム。
5. リリース管理サーバは、
   特定のバージョンのファイル群から比較元ファイルを生成する比較元ファイル生成手段、
   を更に具備し、
   アプリケーションサーバは、
   リリース管理サーバから比較元ファイルを取得し、取得した比較元ファイルと今回比較ファイルとの差分を確認する第２の差分確認手段と、
   前記第２の差分確認手段による確認結果が差異ありの場合、運用監視サーバに異常があることを通知する第２の異常通知手段と、
   を更に具備することを特徴とする請求項１に記載の構成チェックシステム。
6. 前記比較ファイル生成手段が生成する今回比較ファイルは、対象とするファイル群を要約したものであることを特徴とする請求項１に記載の構成チェックシステム。
7. 前記比較ファイル生成手段が生成する今回比較ファイル、及び、前記比較元ファイル生成手段が生成する比較元ファイルは、それぞれの対象とするファイル群を要約したものであることを特徴とする請求項５に記載の構成チェックシステム。
8. 前記比較ファイル生成手段は、対象のファイル群から各ファイルが属するソフトウェアのレイヤごとに区分して、今回比較ファイルを生成することを特徴とする請求項１に記載の構成チェックシステム。
9. 前記比較ファイル生成手段は、対象のファイル群から各ファイルが属するソフトウェアのレイヤごとに区分して、今回比較ファイルを生成し、かつ、前記比較元ファイル生成手段は、対象のファイル群から各ファイルが属するソフトウェアのレイヤごとに区分して、比較元ファイルを生成することを特徴とする請求項５に記載の構成チェックシステム。
10. アプリケーションサーバと、アプリケーションのリリースを管理するリリース管理サーバと、システム全体の運用を監視する運用監視サーバとが互いに接続されており、アプリケーションサーバの構成をチェックする構成チェックシステムであって、
    アプリケーションサーバは、
    現在インストールされているファイル群から今回チェック対象とする比較ファイルである今回比較ファイルを生成し、生成した今回比較ファイルをリリース管理サーバに送信する比較ファイル送信手段、
    を具備し、
    リリース管理サーバは、
    特定のリリース作業においてリリース対象となった変更箇所のリストであるリリース対象リストを保持する手段と、
    前回チェック対象とした比較ファイルである前回比較ファイルを保持する前回分保持手段と、
    アプリケーションサーバから受信した今回比較ファイルと、前記前回分保持手段が保持する前回比較ファイルとの差分を確認する第１の差分確認手段と、
    前記第１の差分確認手段による確認結果が差異ありの場合、リリース管理サーバからリリース対象リストを取得し、差異がリリース対象リストに存在するかどうかを確認するリリース対象確認手段と、
    前記リリース対象確認手段による確認結果が不存在の場合、運用監視サーバに異常があることを通知する第１の異常通知手段と、
    を具備することを特徴とする構成チェックシステム。
11. 前記前回分保持手段は、前記第１の差分確認手段によって差分を確認した後、確認結果に関わらず、アプリケーションサーバから受信した今回比較ファイルを、前回比較ファイルとして保持することを特徴とする請求項１０に記載の構成チェックシステム。
12. リリース管理サーバは、
    特定のバージョンのファイル群から比較元ファイルを生成する比較元ファイル生成手段と、
    前記比較元ファイル生成手段によって生成した比較元ファイルと、アプリケーションサーバから受信した今回比較ファイルとの差分を確認する第２の差分確認手段と、
    前記第２の差分確認手段による確認結果が差異ありの場合、運用監視サーバに異常があることを通知する第２の異常通知手段と、
    を更に具備することを特徴とする請求項１０に記載の構成チェックシステム。
13. アプリケーションサーバと、システム全体の運用を監視する運用監視サーバとが互いに接続されており、アプリケーションサーバの構成をチェックする構成チェックシステムであって、
    アプリケーションサーバは、
    特定のリリース作業においてリリース対象となった変更箇所のリストであるリリース対象リストを保持する手段と、
    前回チェック対象とした比較ファイルである前回比較ファイルを保持する前回分保持手段と、
    現在インストールされているファイル群から今回チェック対象とする比較ファイルである今回比較ファイルを生成する比較ファイル生成手段と、
    前記比較ファイル生成手段によって生成した今回比較ファイルと、前記前回分保持手段が保持する前回比較ファイルとの差分を確認する第１の差分確認手段と、
    前記第１の差分確認手段による確認結果が差異ありの場合、リリース管理サーバからリリース対象リストを取得し、差異がリリース対象リストに存在するかどうかを確認するリリース対象確認手段と、
    前記リリース対象確認手段による確認結果が不存在の場合、運用監視サーバに異常があることを通知する第１の異常通知手段と、
    を具備することを特徴とする構成チェックシステム。

Images