"複数の運用管理対象機器に対し操作を行う運用管理部を備える運用管理装置であって、前記運用管理部は、記憶部と処理部とを備え、前記記憶部は、前記操作により変化が伴う前記運用管理対象機器の状態と、前記操作毎の操作時間と、前記操作に必要な状態条件を記憶し、前記処理部は、複数の前記操作が入力されたとき、前記記憶部に記憶された、前記運用管理対象機器の前記状態と前記操作時間と前記状態条件に応じて入力された複数の前記操作の操作順を決定する、ことを特徴とする運用管理装置。請求項1に記載の運用管理装置であって、前記処理部は、複数の前記操作の操作順を決定する際に、前記操作条件を満たさない操作を検出することで、入力された前記操作に誤りがあることを検知する、ことを特徴とする運用管理装置。請求項1に記載の運用管理装置であって、前記処理部は、複数の前記操作各々の操作の終了時間を出力することにより、前記操作各々の操作を確認するタイミングを提示する、ことを特徴とする運用管理装置。請求項3に記載の運用管理装置であって、表示部を更に備え、前記表示部は、前記処理部からの複数の前記操作各々の終了時間に基づく確認タイミングと、当該確認タイミング時の状態期待値を表示する、ことを特徴とする運用管理装置。請求項1に記載の運用管理装置であって、前記処理部は、前記運用管理対象機器の稼動状況を監視し、前記運用管理対象機器の前記状態が変更されたことを検知した時点で、前記記憶部に記憶する前記状態を更新する、ことを特徴とする運用管理装置。請求項5に記載の運用管理装置であって、前記処理部は、前記運用管理対象機器に保持されたログの解析結果に基づき、前記状態が変更されたことを検知する、ことを特徴とする運用管理装置。請求項1に記載の運用管理装置であって、前記記憶部に記憶される前記運用管理対象機器の前記状態は、当該状態に対応する値の種類、或いは範囲を含む、ことを特徴とする運用管理装置。請求項7に記載の運用管理装置であって、前記記憶部に記憶される前記運用管理対象機器の前記状態は、当該状態の更新頻度を更に含み、前記処理部は、前記更新頻度に基づいて、前記状態条件の判定に必要な前記運用管理対象機器の前記状態を取得する、ことを特徴とする運用管理装置。請求項1に記載の運用管理装置であって、前記記憶部に記憶される前記状態条件は、当該状態条件の基準状態を含む、ことを特徴とする運用管理装置。請求項1に記載の運用管理装置であって、前記記憶部に記憶される前記操作時間は、時刻予想対象とする操作名と対応づけて記憶される、ことを特徴とする運用管理装置。複数の運用管理対象機器に対し操作を行う運用管理機器による運用管理方法であって、前記操作により変化が伴う前記運用管理対象機器の状態と、前記操作毎の処理時間と、前記操作に必要な状態条件を記憶し、複数の前記操作が入力されたとき、前記運用管理対象機器の前記状態と前記処理時間と前記状態条件に応じて、前記複数の操作の操作順を決定する、ことを特徴とする運用管理方法。請求項11に記載の運用管理方法であって、前記操作順を決定する際に、前記操作条件を満たさない操作を検出することで、前記操作に誤りがあることを検知する、ことを特徴とする運用管理方法。請求項11に記載の運用管理方法であって、前記複数の操作における個々の操作の終了時間を出力することで、前記個々の操作を確認するタイミングを提示する、ことを特徴とする運用管理方法。請求項11に記載の運用管理方法であって、前記状態条件の判定に必要な前記運用管理対象機器の前記状態を取得するために、前記運用管理機器が記憶する状態更新頻度に基づいて、前記運用管理対象機器の稼動状況から、前記運用管理対象機器の前記状態を更新する、ことを特徴とする運用管理方法。請求項11に記載の運用管理方法であって、前記状態条件の判定に必要な前記運用管理対象機器の前記状態を取得するために、前記運用管理対象機器の稼動状況を監視し、前記運用管理対象機器の前記状態に対応する前記稼動状況が変更されたことを検知した時点で、前記運用管理対象機器の前記状態を更新する、ことを特徴とする運用管理方法。上述した先行技術を踏まえ、現在のデータセンタ運用管理においては、従来の運用管理対象機器に対するオペレーション業務をより一層効率化することが課題となっている。まず機器を操作する際に、例えば操作の前提条件を確認せずに作業を進めてしまい、操作自体を間違える、または操作に関わるパラメータに誤りが生じるという問題がある。次に、複数の運用管理者が機器のオペレーションに携わるとき、機器に対する複数の操作間に例えば実行順序の依存関係があることを運用管理者間で情報共有できずに誤りが発生するという問題がある。また、同一の運用管理者が複数の機器に対し同時にオペレーションを行うときに、同様に複数の操作間に例えば実行順序の依存関係があり、それを見落としてしまって誤りが生じるという問題がある。また、操作に対する結果の確認を行うタイミング、つまり操作が終了するタイミングがわからず、オペレーションに必要以上の時間が掛かってしまうという問題がある。また、操作に対する結果の確認において、機器の稼動状況から適切な検証項目を抽出し、操作の正しさを確認することは手間が掛かるという問題がある。本発明の目的は、上述の課題を解決し、複数の運用管理対象機器に対する複数の運用管理操作に対し、実行前に操作の検証と操作順の最適化を行うことで、機器の運用管理を効率化することが可能な運用管理装置、及び方法を提供することにある。上記の目的を達成するため、本発明においては、複数の運用管理対象機器に対し操作を行う運用管理部を備える運用管理装置であって、運用管理部は、記憶部と処理部とを備え、記憶部に、操作により変化が伴う運用管理対象機器の状態と、操作毎の処理時間と、操作に必要な状態条件を記憶し、処理部は、複数の操作が入力されたとき、記憶した運用管理対象機器の状態と処理時間と状態条件に応じて複数の操作の操作順を決定する運用管理装置を提供する。また、上記の目的を達成するため、複数の運用管理対象機器に対し操作を行う運用管理機器による運用管理方法であって、操作により変化が伴う運用管理対象機器の状態と、操作毎の処理時間と、操作に必要な状態条件を記憶し、複数の操作が入力されたとき、当該複数の操作を、記憶した運用管理対象機器の状態と処理時間と状態条件に応じて操作順を決定する運用管理方法を提供する。運用管理対象機器の状態と操作をモデル化し、操作に必要なリソース、操作条件と操作時間を記憶させることで、複数の操作が入力された際の操作の正しさを実行前に検証できる。また、当該複数の操作の実行が最短となるよう実行順を最適化できる。また個々の操作に対し、実行の終了タイミングと運用管理対象機器の稼動状況から確認すべき項目を出力することで、当該操作の正しさ確認が容易化できる。以上より、データセンタの運用管理業務を効率化できる。以下、本発明の各種の実施形態を図面に従い説明する。以下の説明においては、本発明の対象となるITシステムとしてデータセンタを例示するが、本発明はその他のITシステムにも適用できるものである。第1の実施例として、データセンタに適用したオペレーション検証最適化システムを説明する。<全体の構成>図1は実施例1のデータセンタにおけるオペレーション検証システム構成の一例を示す図である。データセンタにおいては、本検証システムの運用管理対象となる装置、すなわち運用管理対象機器として、データセンタの運用設備系機器と、サーバ装置等のIT機器がある。このデータセンタの運用設備系機器としては、図1の右上に示したような、空調機器104、無停電電源装置電源安定化装置等を含む電源装置105、監視カメラ人感センサ等を含む監視装置106、入出力ゲート等を含むセキュリティ装置107等がある。また、データセンタのIT機器には、同図の右下に示すように、サーバ装置108、ディスク装置109、ルータ110等が上げられる。データセンタ内において、これらのIT機器と運用設備系機器は互いに強調して動作することで、省エネや運用管理省力化の点で効果を得ることができる。さらに本検証システムは、これらの運用管理対象機器に対して、遠隔でコマンド発行や実行状況の確認を行うことができるよう、ユーザが通常IT機器へのアクセスで使用する場内ネットワーク114と分離された、管理ネットワーク113を敷設し、各機器装置に接続する。管理ネットワーク113には、各機器を管理する運用管理サーバ100、各機器に対するオペレーションの有効性を検証し最適化する処理を実施するオペレーション検証サーバ101、機器の運用管理とオペレーション検証及び最適化に必要な各種情報を格納管理する運用モデル管理サーバ102を接続する。本明細書において、運用管理サーバ100、オペレーション検証サーバ101、及び運用モデル管理サーバ102を纏めて、運用管理機器、或いは運用管理部と呼ぶ場合がある。この運用管理機器、あるいは運用管理部は、本実施例の検証システムの運用管理機能、すなわち運用管理対象機器の運用管理と、オペレーション検証及び最適化の機能を備えている。運用管理サーバ100には、運用管理者がオペレーションを実施する端末103が接続される。なお、運用管理部の各種サーバ100~102はすべて、またはその一部を1台のサーバ装置上で実行する構成としても良い。例えば、運用管理サーバ100とオペレーション検証サーバ101を一台のサーバ装置とする、運用管理サーバ100、オペレーション検証サーバ101、及び運用モデル管理サーバ102を一台のサーバ装置としても良い。または管理対象とする機器の規模に応じて、当該各種サーバを機能の細分化や処理の並列化により、さらに複数台に分散させる構成としても良い。図2に本実施例のオペレーション検証最適化システムにおける各種サーバの代表的な構成例を示す。サーバ100、101、102は、処理部として演算処理を実行する中央演算装置CentralProcessingUnit:CPU151、記憶部として一時的にプログラムデータを記憶するメモリ152、各種インタフェースに対する制御を行うコントローラ153、記憶部として各種データプログラムを保持するハードディスクドライブHardDiskDrive:HDDなどの記憶装置154、外部ネットワークと接続するネットワークインタフェース155、ディスプレイやキーボード等の周辺装置を接続する周辺装置インタフェース156から構成される。また、図1の管理ネットワーク113は、ファイアウォール/VPNVirtualPrivateNetwork装置111を介して、場外ネットワーク115に接続される。従って、上記で述べた管理対象とする各種機器104~110、または管理を行う各種サーバ100~102の一部、もしくはすべてが場外ネットワーク115を介して別のデータセンタ等に設置されていても良い。すなわち、遠隔で他のデータセンタに存在する各種機器を、当該のデータセンタで管理する構成でも良く、また管理に必要な一部のサーバ、またはすべてのサーバが遠隔のデータセンタに設置されて当該データセンタの各種機器を管理する構成としても良い。また、場内ネットワーク114も同じくファイアウォール/VPN装置112を解して場外ネットワーク115に接続される。運用管理サーバ100は、運用管理者に対する対象機器のオペレーションを実施するためのインタフェースを提供する。つまり、接続された端末103を介して、運用管理者に対してオペレーションの入力手段、及び当該機器の稼動状況やオペレーション実行状況を表示する手段を提供する。また、オペレーション検証や最適化を行うための、運用管理対象機器の構成、状態、操作、操作記録、状態記録を作成し、運用モデル管理サーバ102の記憶部である記憶装置154上に格納される各種モデルテーブル120~129を作成更新する。オペレーション検証サーバ101におけるオペレーション検証及び最適化の手順詳細については、後述する。<モデルテーブルについて>次に、運用モデル管理サーバ102上で管理される各種モデルテーブル120~129に関して説明する。運用管理対象機器の構成や状態をモデル化してテーブルで表現することにより、運用管理者が入力するオペレーションの有効性を検証したり、オペレーションを最適化したりすることを可能とする。つまり、各テーブルの構成要素は、例えば検証対象とするオペレーションの種類によって変わるため、目的とする検証や最適化機能に合わせて、それぞれのテーブルの構成要素を定義する必要がある。なお、これらの各種モデルテーブル120~129は、上述した運用モデル管理サーバ102の記憶部に蓄積される。<機器種別テーブル>まず、図3を用いて、機器種別テーブル120の構成を説明する。当該テーブル120は、運用管理対象とする機器の種別を定義する。また、このとき各機器が取り得る状態、即ち機器種別毎にモデル化すべき状態も合わせて定義する。なお、状態の種類に関しては、図4に示す状態テーブル121で定義する。機器種別テーブル120は、機器種別を表す列項目200、当該機器種別に対し取り得る状態を定義する列項目201で構成される。図3では、各行で定義した機器の種別を説明する列項目202を付している。例えば、機器種別名pserverは物理サーバを意味し、取り得る状態として、電源状態を表すpower、ネットワークアドレスを表すnw_adrs、温度を表すtemp、ユーザプロセス数を表すuser_processである。また、機器種別名vserverは仮想サーバを意味し、取り得る状態として、電源状態を表すpower、ネットワークアドレスを表すnw_adrs、ユーザプロセス数を表すuser_process、ホストサーバ名を表すhost_srvである。以下、同様にルータrouter、空調機aircond、電源装置ups、ディスク装置storage、監視カメラcamera、セキュリティゲートsgateが定義されている。<状態テーブル>次に、図4を用いて、状態テーブル121の構成を説明する。当該テーブル121は、各運用管理対象機器の状態と、それに対応して取り得る値や、実システムの状態を更新する、標準の更新頻度を定義する。状態テーブル121は、状態名を表す列項目210、状態に対応する値の種類や範囲を表す列項目211、当該状態名に対しさらに細分化した状態であるサブ状態を定義する列項目212、細分化した状態に対応する値の種類や範囲を表す列項目213、各状態の実機上での状況をテーブル上の状態に反映させるための更新頻度を表す列項目214で構成されている。なお図4では、各行で定義した状態を説明する列項目215を付している。例えば、状態名powerは電源状態を表しており、取り得る値はonまたはoffの何れかである。更新頻度214は1msとなっており、別途指定が無い限り1ミリ秒毎に実機の電源状態を確認し当該テーブルに反映させる。また状態名tempは温度を表しており、対応する値の取り得る範囲は30~60であり、更新頻度は10秒毎となっている。また、例えば状態名nw_adrsは細分化したサブ状態212を持ち、IPアドレスip、サブネットマスクsubnet、ゲートウェイアドレスgwを定義する。それぞれの状態の取り得る値は、IPv4のアドレス範囲0~2^32の整数となる。なお、更新頻度はOPとあるが、これはネットワークアドレスに関わるオペレーションが発生した都度、実機のネットワーク状態を確認し当該テーブルに反映させる。なお、本例で示した数値範囲等の表現は一例であり、当該項目を定義するための必要な表現を適宜実装することになる。<状態ルールテーブル>次に、図5を用いて、状態ルールテーブル122の構成を説明する。当該テーブル122は、各運用管理対象機器における状態間の定常的な関係を定義する。オペレーション毎や状態の更新毎に、本テーブルで定義された状態間の関係性をチェックすることで、システム状態の正しさを確認できる。状態ルールテーブル122は、状態ルール名を表す列項目220、基準状態を表す列項目221、当該基準項目に対し関係する状態条件を表す列項目222で構成される。なお図5では、各行で定義した状態ルールを説明する項目223を付している。例えば、状態ルール名rl_psrv_powerは、基準状態をpserver.power=on、つまり物理サーバの電源がON状態としている。このときの状態条件はpserverups.power=onpserveraircond.power=on、つまり当該物理サーバが依存する接続される電源装置の電源がONである、かつ当該物理サーバが依存する冷却される空調機器の電源がonであるべきことを示している。また、例えば状態ルール名rl_psrv_ip_adrsは、基準状態をpserver.ip_adrs=、つまり物理サーバのIPアドレス値は任意としている。このときの状態条件はpserver.ip_adrs=[10.0.10.1-9]、つまり当該物理サーバのIPアドレスが10.0.10.1~9の範囲に設定されるべきことを示している。なお、以上で示した数値範囲や、機器や状態の関連性を表す方法は一例であり、当該項目を定義するための必要な表現を適宜実装することになる。<機器定義テーブル>次に、図6を用いて、機器定義テーブル123の構成を説明する。当該テーブル123は、運用管理対象とする実機器を定義するものであり、初期状態を併せて定義可能である。機器定義テーブルは、機器名を表す列項目230、機器種別テーブル120で定義した機器種別を表す列項目231、各機器上の状態を表す列項目232で構成される。例えば、機器名ps1は機器種別がpserver、つまり物理サーバであり、その状態はpower=off電源OFF、user_process=0ユーザプロセスは無し、nw_adrs[0]->IP=10.0.10.10ポート0番のIPアドレスは10.0.10.10となっている。同様に、本例では物理サーバps2、ps3、仮想サーバvm1、電源装置ups1、ルータrouter1、空調機器airc1、ディスク装置str1、str2、監視カメラcam1、セキュリティゲートsgate1を定義している。<依存テーブル>次に、図7を用いて依存テーブル124の構成を説明する。当該テーブル124は、機器間の論理的または物理的な、依存関係であるトポロジまたは接続関係を定義する。例えば、主従関係を持つサーバ間や、サーバとそれに接続される周辺機器、等の依存関係を定義する。依存テーブルは、依存元の機器名を表す列項目240、依存先の機器名を表す列項目241、依存関係の種類を表す列項目242で構成される。図7の例では、機器名が物理サーバps1、ps2、ps3及びディスク装置str1、str2に対し、依存先が電源装置ups1となっており、また種別が物理的に接続されていることを表すPHYSICALLY_CONNECTEDとなっている。これは、当該物理サーバ及び当該ディスク装置が、当該電源装置ups1に接続され、依存していることを表す。また、機器名がディスク装置str1、str2に対し、依存先が物理サーバps1、ps2、ps3、仮想サーバvm1、vm2となっており、また種別が論理的に接続されていることを示すLOGICALLY_CONNECTEDとなっている。これは、当該ディスク装置が当該物理サーバまたは当該仮想サーバに論理的に接続され、依存していることを示す。また、機器名が仮想サーバvm1、vm2に対し、依存先が物理サーバps1、ps2、ps3となっており、また種別が当該仮想サーバをホストする物理サーバであることを示すHOSTEDとなっている。これは、当該仮想サーバが当該物理サーバ上で動作することを示す。<操作テーブル>次に、図8を用いて操作テーブル125の構成を説明する。当該テーブル125は、運用管理者による対象機器のオペレーションであるコマンド操作を定義する。コマンド操作は、対応する機器状態を変更することを意味し、コマンド操作をモデル上での状態変更と対応付けることで、オペレーション検証を可能とする。操作テーブルは操作名を表す列項目250、操作対象の機器種別を表す列項目251、操作におけるパラメータ等の変数を表す列項目252、操作時の状態条件を表す列項目253、操作による変更後の状態を表す列項目254、操作に掛かる時間を表す列項目255で構成される。なお図8では、各行で定義した操作の内容を説明する列項目256を付している。例えば物理サーバの電源をONにする操作power_onについて説明する。操作対象とする機器種別はpserverであり物理サーバを示す。操作パラメータはSERV:pserverであり、SERVが指定される物理サーバ名となる。次に、操作条件SERV.power=offより、当該操作を行うための状態条件として、当該サーバの電源がOFFであることを定義している。次に操作後の状態SERV.power=onより、当該操作により当該サーバの電源状態をONに変更することを定義している。次に、操作時間の定義がREF参照となっているが、これは操作時間予測テーブル126を参照し操作時間を算出することを示している。次のファイルのコピー/バックアップを行う操作copy_fileについて説明する。捜査対象とする機器種別はstorageでありディスク装置を示す。操作パラメータはFROM:storage,TO:storage,FILE:LISTであり、FROMがコピー元のディスク装置、TOがコピー先のディスク装置、FILEがリスト表現によるファイル名となる。次に、操作条件ExistFILE,FROM.fileより、当該操作を行うための状態条件として、ディスク装置FROMにファイルFILEが存在することを定義している。なお、Existは、リスト操作存在確認を行う関数を意味している。次に捜査後の状態をAppendFILE,TO.file,TO.vol_used=FROM.file[FILE]->sizeより、ファイルFILEのディスク装置TOのファイルリストへの追加、及びディスク装置TOの使用容量の対象ファイルサイズ分の増加を定義している。次に、操作時間の定義がREFとなっているが、これは操作時間予測テーブル126を参照し操作時間を算出することを示している。同様に、図8では例として物理サーバの電源OFFpower_off、仮想サーバの割り当てassign_vm、仮想サーバの起動power_on、アプリケーションの起動start_appli、アプリケーションの停止stop_appli、バッチの実行exec_batchを定義している。なお、以上で示した操作条件の表現、各種関数は一例であり、当該項目を定義するための必要な表現関数を適宜実装することになる。<操作時間予測テーブル>次に、図9を用いて、操作時間予測テーブル126の構成を説明する。当該テーブル126は、操作テーブル125で定義した操作に対し、操作時間の計算式、または操作時間そのものを定義し、種類として予測型と実測型がある。操作時間予測テーブルは、識別名を表す列項目260、時刻予測対象とする操作を表す列項目261、操作時間の表現が算出式か時間かを表す列項目262、算出式または操作時間を表す列項目263で構成される。例えば識別名time_file_copyは、ファイルコピーに掛かる時間を表し、操作対象は操作テーブル125で定義されているcopy_fileとなる。種類はEstimatedEQであり、これは予測算出式で表現されることを表す。本例では、算出式はSumFILE.file_size/MinFROM.troughput,TO.throughputと定義されており、コピー対象のすべてのファイルFILEのサイズ合計値を、ディスク装置FROMまたはTOのスループットバイト/秒のうち小さい方のスループットで割った値を、操作時間としている。なお、Sumは合計値を求める関数、Minは最小値を求める関数である。また、スループットは装置の仕様値を用いるか、または当該操作時に測定することで求める。次に、例えば識別名time_start_appliは、アプリケーション起動に掛かる時間を表し、操作対象は操作テーブル125で定義されているstart_appliとなる。種類はMeasuredVLであり、これは実測による操作時間で表現されることを表す。本例では、SERV==vm1APP=appli1:25s、SERV==ps1APP==appli2:20sと定義され、実行サーバSERVが仮想サーバVM1でかつ実行対象のアプリケーションAPPがappli1であるとき操作時間は25秒、実行サーバSERVが物理サーバps1でかつ実行対象のアプリケーションAPPがappli2であるとき操作時間は20秒となる。同様に図9では他の例として、電源ONtime_power_on、電源オフtime_power_off、バッチ実行time_batch_exec、アプリケーション停止time_stop_appliの各操作時間を定義している。次に操作コマンド変換テーブル127の構成を、図10を用いて説明する。当該テーブル127は、操作テーブル125で定義した操作に対応した、実機上でのコマンドを定義する。操作コマンド変換テーブル127は、操作テーブル125で定義した対応操作名を表す列項目270、対象となる機器を表す列項目271、及び生成コマンドを定義する列項目272で構成される。例えば、電源ON操作power_onは、対象機器が物理サーバps1であり、そのとき生成するコマンドはps1を制御するサービスプロセッサに対する遠隔電源ONを意味する/sbin/poweron{PSERV.nw_adrs[0].ip}nowを定義している。同様に、図10の例ではファイルコピーcopy_file、電源OFFpower_off、仮想サーバの割り当てassign_vmの生成コマンドを定義している。なお、以上で示した算出式や操作時間の表現、各種関数は一例であり、当該項目を定義するための必要な表現関数を適宜実装することになる。<状態記録テーブル>次に、図11を用いて状態記録テーブル128を説明する。当該テーブルは、運用管理対象機器の各状態を保存し、機器状態の更新を記録する。状態記録テーブル128は、機器定義テーブル123と同じく、機器名を表す列項目280、機器の種別を表す列項目281、記録時の状態を表す列項目282と、さらに記録時の通し番号である状態番号と記録時間を表すヘッダ情報283で構成される。記録状態282における状態項目は機器定義テーブル123における初期状態232で定義した状態項目そのものである。このように、例えば一定時間毎、または状態変化時、またはオペレーションの前後のタイミングにおいて、各状態を記録しておくことで、エラーや不具合等の原因追及やオペレーションの検証に役立てることができる。<操作記録テーブル>次に、図12を用いて、操作記録テーブル129を説明する。当該テーブルはオペレーション操作の履歴を記録する。操作記録テーブル129は、時間を表す列項目290、操作テーブル125で定義された操作名を表す列項目291、操作パラメータを表す列項目292、操作前後の状態を記録した状態記録テーブル128の状態番号283を表す列項目293で構成される。このように、操作の履歴を記録しておくことで、操作に起因した不具合の原因追及に役立てることができる。<オペレーション検証最適化の処理フロー>図13を用いて、運用管理サーバ100、オペレーション検証サーバ101、及び運用モデル管理サーバ102における、運用管理者が入力したオペレーションの検証最適化の処理フローを説明する。この処理フローは、運用管理部を構成する、運用管理サーバ100、オペレーション検証サーバ101、及び運用モデル管理サーバ102内のCPUのプログラム処理等で実現されるものであり、運用管理部の運用管理サーバ100、またはオペレーション検証サーバ101、または運用モデル管理サーバ101のいずれかで実行、または個々の処理で各サーバに分散して実行されるものである。まず、運用管理者は運用管理対象機器に対するオペレーション操作を、運用管理サーバ100に接続されたオペレーション端末103上で入力する301。なおオペレーションは、事前に操作テーブル125にて定義した操作を選択的に入力することで、行う。このとき、複数の管理者が同一または相違の機器を対象としたオペレーションを同じタイミングで行ったり、一人の管理者が複数のオペレーションを同時に行ったりすることが考えられる。そこで、オペレーションをある時間やオペレーションの種類、または対象機器に応じてグループ化し、グループ単位で検証最適化を行う。オペレーション入力後、まず操作対象機器の最新の状態を取得し、モデル上の状態を更新する302。具体的には、機器定義テーブル123の状態定義232にて定義された各種状態値を更新する。なお、稼動状況の取得方法としては、対象機器に保持される各種ログを解析する、または各種機器上でエージェントプログラム等を実行させることで取得する方法が考えられる。次に入力、グループ化された複数オペレーションは、オペレーション検証サーバ101により、まずオペレーション間の依存解析を行う303。オペレーションは、操作テーブル125で定義された各操作と対応付けられ、操作単位での依存解析を行うことになる。オペレーション検証サーバ101における依存解析は、操作テーブル125における操作条件253と依存テーブル124の依存関係を用いて、操作を行う際の前提条件を満たしているか、また操作後の状態に対して状態ルールテーブル122を用いて操作後状態条件を満たしているかを確認することで、操作間の実行順序や並列実行可能性を決定するための操作依存グラフを作成する304。次に、オペレーション検証サーバ101上で、各操作に対する実行時間予測を行う305。実行時間予測は、操作時間予測テーブル126を用いて決定する。実行時間は、当該テーブル上の算出式または過去の実測による時間情報を用いて決定する。次に、オペレーション検証サーバ101は、操作依存グラフと、操作時間予測から、操作の実行順序とタイミングを決定する操作スケジューリングを行う306。操作スケジューリングにより、各操作の実行順序、実行タイミング、及び各操作の実行終了タイミングを求めることができる。次に、オペレーション検証サーバ101は、オペレーション実行後の状態として、操作による状態変更に基づき、最終的な状態を予測する307。次に、オペレーション検証サーバ101は、当該状態が当該オペレーションに対する期待状態となっているか、また状態ルールテーブル122または依存テーブル124を用いて状態間の定常条件を満たしているかをモデルチェックすることで確認する308。その結果、当該操作による変更後状態が期待通りとならない場合309は、運用管理サーバ100は、運用管理者へその旨通知し、入力した操作に誤りが無いかを確認するよう促す316。また、モデルチェック308の結果、当該操作による変更後状態が期待通りとなる場合309は、運用管理サーバ100は、操作スケジューリング306の結果から得られた各操作の終了予測タイミングと、操作テーブル125の操作後状態254から得られる、各操作においてその実行が正しく行われたかを検証するために確認すべき状態項目を、運用管理者に通知する310。これによって、これらの操作を実機上で実行する際、運用管理者は実行状況を逐次確認するためのタイミングと、確認すべき状態項目を知ることが可能となる。その後、例えば運用管理サーバ100から、操作スケジューリング306のタイミングで、各機器に対する操作が発行され、それぞれの操作が実行される311。1個の操作が終了した段階で、操作対象機器の最新の状態を取得し、モデル上の状態を更新する312。そして、オペレーション検証サーバ101は、モデルチェックにより、実機上で行われた操作による変更後状態が期待通りとなるかを確認する313。もし期待状態となっていなければ309は、操作を中断し、その旨を運用管理サーバ100を介して運用管理者へ通知し、また入力した操作に誤りが無いかを確認するよう促す316。当該操作による変更後状態が期待通りとなる場合309は、処理312で取得した機器の状態及び操作を、運用モデル管理サーバ102の状態記録テーブル128、及び操作記録テーブル129にそれぞれ記録させる315。その後、すべての操作がまだ終了していなければ317、次の操作実行を繰り返し311~315、すべての操作が終了していれば317、運用管理サーバ100は、正常終了を運用管理者へ通知し316、オペレーション入力待ち状態に戻る。なお、ここでは操作毎に逐次、操作対象機器の最新状態の取得と、操作による変更後状態のモデルチェックを繰り返す処理フローとしているが、複数の操作群を実行後に一括して、当該操作群による変更後状態のモデルチェックを行う処理フローとしても良い。<オペレーション実施時以外の処理フロー>次に、図14を用いて、運用管理対象機器に対するオペレーション実施時以外の、定常時における機器状態検証処理フローを説明する。本処理フローは、運用管理部を構成する、運用管理サーバ100、またはオペレーション検証サーバ101、または運用モデル管理サーバ101いずれかで実行、または個々の処理で各サーバに分散して実行される。まず、状態テーブル121及び機器定義テーブル123で定義された状態に対応する、運用管理対象機器の実機状況を監視する321。監視の方法は、当該機器が保持するログを解析することで対象の状態変化を検出する、または当該機器上でエージェントプログラム等を実行させ対象の状態変化を検出する、等の方法が考えられる。また、状態監視以外に、定期的に状態チェック及び更新を行っても良い321。この場合は、状態テーブル121で定義された更新頻度214の時間毎に機器の稼動状況をチェックするか、または当該更新頻度で次の処理ステップ322に移行しても良い。監視対象の状態が変化後、または更新頻度時間が到来後、当該対象機器の稼動状況の取得と機器定義テーブル123の状態定義232に対応する仮の機器定義テーブルへ状態更新を行う322。その後、当該状態をあるべき定常状態を定義する機器定義テーブル123の状態定義232と比較し一致しているか、また状態ルールテーブル122または依存テーブル124を用いて状態間の定常条件を満たしているかをモデルチェックする。その結果、不一致や違反が無ければ、再度状態変化の検知またはチェックタイミングの監視321を繰り返す。もし、不一致や違反があれば、前記仮の機器定義テーブルにおける状態定義を、状態記録テーブル128として記録し325、運用管理サーバ100を介して、運用管理者へ通知する326。<ログ解析による状態取得のフロー>次に、図15を用いて、図13、図14における、稼働状況の取得と状態更新302、312、322の詳細フローを説明する。前述の通り、本処理では操作対象機器の最新の状態を取得し、機器定義テーブル123の状態定義232にて定義された各種状態値を更新する。図15は運用管理対象機器104~110に保持されるログを解析することで状態を取得更新するフローである。以下の説明において、本フローはオペレーション検証サーバ101が実行するとするが、運用管理サーバ100または運用モデル管理サーバ102で実行しても良い。また、一部の処理を、ログを保持する操作対象機器側で分担して実行する構成としても良い。まず、図15において、管理ネットワーク113を介して運用管理対象機器に保持されているログを取得する331。なお取得するログは、前回取得時からの差分とすることで、取得にかかる時間を抑えることができる。次に、取得したログを解析する332。ログの解析は、予め取得対象となる状態情報に対応したキーワードを入力しておき、ログの内容をキーワードと照らし合わせることで、ログの意味づけと対応するパラメータの抽出を行う。なお、前述したとおりステップ331及び332を、ログを保持する運用管理対象機器側で実行しても良い。これにより、管理ネットワーク113を流通する情報量を小さくできるため、遠隔管理においては有利であるが、当該対象機器の演算リソースを一部占有してしまうという欠点もある。次に、ログの意味とパラメータ抽出の結果から、状態テーブル121を検索し、当該テーブル上で登録された状態を検索する333。その結果、もし登録済みの状態と抽出された状態に差分がある場合は、差分があったことを記録し334、当該テーブル121上の状態を更新する335。<オペレーション最適化の具体例>次に、図16を用いて、本実施例にける、オペレーション最適化の具体例として、3種類の運用管理業務を実施する例を説明する。図16のテーブル400において、401~403はそれぞれ3種類の運用管理業務A、B、Cを示している。なお、当該の3業務を3人の運用管理者が同時に行う、または当該の業務を1人の管理者が同時に行うことを想定する。業務A401はサーバ再起動及び仮想サーバを起動する。業務Aで実施する操作は、まず業務Aでは物理サーバps1を対象とし電源OFFの操作410、次にps1に対する電源ONの操作411、仮想サーバvm1に対するホストサーバ指定の操作412と、以下当該テーブル400のオペレーションリストに示す通り定義されている。なお、本例ではオペレーションリストにおける操作は、掲載されている順に操作されるとする。つまり、業務内の操作では、同時に実行可能な操作は含まない。ただし、同時に実行可能な操作を含めることもできる。その場合には、オペレーション入力時に同時実行可能な操作群として定義する必要がある。また業務B402は定時バッチ処理を、業務C403は定時バックアップ処理を行う。各業務には、優先度を設定でき、操作スケジューリング306の際、複数の操作が可能な条件において、当該操作の実行順を決定するために用いられる。本例では、優先度を1~10で表し、数字が大きいほど優先度が高い。<操作依存グラフの例>次に、図13で説明した処理フローに基づき、テーブル400で示す種類の運用業務の操作を最適化する。当該操作間の依存解析を行い303、操作間の依存関係を表す操作依存グラフの例を図17に示す。図17の操作依存グラフは、図8で示した操作テーブル125から作成される。円が操作を表し、矢印が依存関係を表す。また、円の右下に示す数値は、操作時間を表す。例えば、業務A401の操作411物理サーバps1の電源ONは操作410ps1の電源OFFに依存し、操作410の後に有効となる。同様に、例えば業務B402の操作416ps1上でのアプリ2起動は、ps1が起動状態である必要から、業務Aの操作411ps1の電源ONに依存し、操作411後に有効となる。また、業務C403の操作415ディスク装置str1のバックアップは、依存する操作が無いため、例えば業務A401の操作410と同時に実行することが可能である。このように、すべての操作間での依存関係をグラフ化することで、実行順の決定や、並列に実行可能な操作の抽出ができる。なお、もし性能上の理由等で同時に実行させない場合は、操作テーブル125の操作条件253に対応する条件を明記する必要がある。<操作スケジューリング結果の例>図12の操作スケジューリング306では、図17の操作依存グラフと、各操作の操作時間から、最終的な各操作の発行のタイミングを決定する。スケジューリングの結果例を図18に示す。図18において、横軸は時間で、長方形が1つの操作を表す。また、Cの文字が書かれた長方形は、直前の操作結果を確認するタイミングを表す。スケジューリングは、操作依存グラフの上部から順に割り当てる。ただし、同一の機器に対する別業務の複数操作が同時に発行可能となる場合には、前述の通り業務別の優先度を利用して、割り当てを決定する。図17の操作依存グラフより、まず操作410物理サーバps1の電源OFFと操作415ディスク装置str1のバックアップがまず実行可能であり、操作を割り当てる。操作410の操作時間は図17より30秒であり、また操作415は155秒である。従って、30秒後には操作410の実行確認が可能となり、その後に操作411ps1の電源ONを割り当てることができる。続いて操作411の操作時間は45秒であり、当該時間後に操作411の確認が可能となる。その後、操作412仮想サーバvm1のps1割り当てと操作416ps1上でのアプリ2起動を割り当てることができる。操作412と操作416は同時に実行可能であるため、同時に操作を割り当てる。操作412の操作時間は10秒、操作416の操作時間は20秒であり、操作412終了後、操作413vm1の起動が割り当てられる。以上、同様に操作416終了後に操作417ps1上でバッチ1実行、操作413終了後、操作414vm1上でアプリ1起動が割り当てられる。また、操作417終了後、操作418ps1上でのアプリ2停止が割り当てられる。業務Cの操作419は、依存先の操作415が終了した時点でもう一方の依存先の操作411が終了しているため、操作依存グラフ上では操作415の終了直後に割り当てが可能となっている。しかしながら、操作テーブル125のバッチ実行操作exec_batchにおける操作条件253にて定義されているSERV.user_process<=2より、ps1では既に仮想サーバvm1及びアプリ2の計2プロセスが稼動状態のため、操作415終了直後の割り当てはできない。従って、操作418のアプリ2停止後に、操作419が割り当てられる。<運用管理対象機器上のログの例>図19に、図18で示したスケジューリング結果に基づきオペレーションを実施した際の、物理サーバps1上で取得されたログの例450である。図中、最左の数字は行番号を表している。ログは、日時、時間、機器名、サービス名、メッセージで構成される。たとえは、2行目は5月2日10時10分02秒において、物理サーバps1上で実行されるカーネルサービスのメッセージとして、システムシャットダウンが開始されたことを示している。<オペレーション入力確認画面>次に、運用管理者によるオペレーションの入力、及びオペレーション検証結果の確認方法を、オペレーション端末103上での画面構成例を示して説明する。図20はオペレーション入力画面500の一例を示す図である。本画面を運用管理者毎、または運用管理業務毎に表示して、各操作を入力する。本例では、運用管理者別の画面として構成している。運用管理者は、まず操作対象機器の選択501で機器の選択を行う。操作対象機器を選択すると、当該機器に対し実施可能な操作の一覧がオペレーションの選択502に表示される。従って、当該機器上で実施する操作を選択する。選択を行うと、操作に必要なパラメータ項目がパラメータ入力503に表示される。パラメータを選択すると、運用管理者に対し対応するパラメータを入力するよう促す画面が別途表示される。また、操作対象機器の選択501で選択された機器の、現在の状態を取得し参照することもできる。状態情報504に表示された状態項目を選択し、状態確認ボタン517を押すことで、当該機器の当該状態が別画面で表示される。1操作の入力が完了した後、追加ボタン511を押すことで、オペレーションリストに登録が可能である。以上を繰り返すことにより、複数の操作群からなるオペレーションの入力を行う。なお、オペレーションリスト中の操作の修正削除は、対象となる操作を選択した上でそれぞれ修正ボタン512、削除ボタン513を押すことで行う。すべてのオペレーションの入力が終了後、連続実行ボタン514またはステップ実行ボタン515を押すことでオペレーション検証、最適化、及び実機上での実行を開始する。なお、連続実行514では、オペレーションリスト中の操作群に対し検証最適化が行われた後、問題が無ければ一括して操作が発行され、実行状況を表す画面520が表示される。すべての操作の実行が終了後、結果を確認する画面が表示される。またステップ実行515では、当該操作群に対し検証最適化が行われた後、問題が無ければ実行状況を表す画面520が表示され、1操作ずつ順に実行を指示する。さらに当該操作実行の都度、結果を確認する画面530が表示される。また、操作実行前のオペレーション検証段階でエラーが検出された場合は、オペレーションエラー通知画面550を表示する。次に、図21を用いて、オペレーションの状況を表示する画面520について説明する。運用管理者または運用管理業務別に発行したオペレーションに対し、オペレーション発行状況521と確認タイミング及び状態期待値522を示す。オペレーション発行状況521では、各操作の発行時刻と対象機器及び操作内容のリストが表示される。現在実行中の操作は、ハイライトされて示される。確認タイミングと状態期待値522では、各操作の結果を確認するための時刻と確認すべき状態、及びその期待値が表示される。例えば、リスト522最上段は確認時刻が10:00:30、対象機器は物理サーバps1、確認すべき状態項目はpower、状態期待値はoffとなる。なお、実行途中でオペレーションを中止する場合は、中止ボタン526を押す。また、オペレーション入力画面500にてステップ実行515を選択した場合は、各操作の発行終了毎に待ち状態となり、実行ボタン525が有効になる。オペレーション確認画面530で確認後、次の操作を実行する際は、当該実行ボタン525を押す。なお、オペレーション入力画面500にて連続実行514を選択した場合は、実行ボタン525は有効にならない。次に、図22を用いて、オペレーション実行前にエラーが検出された時の確認画面540について説明する。オペレーションエラー表示画面540では、図20に示す通りオペレーション検証段階にて検出されたエラーを表示する。エラーが発生した操作を示す画面541と、エラー内容を示す画面542で構成される。本例のエラー内容542では、物理サーバps1の電源OFF操作に対して、ps1の電源状態がonとなっていないことを示している。エラーを受けて、オペレーションを中止する場合には、確認中止ボタン545を押し、エラーを無視する場合は無視ボタン546を押す。図23に示す通り、ステップ実行時のオペレーション結果の確認画面530では、確認すべき操作を表示する画面531と、確認すべき状態情報を示す画面532が表示される。また、状態を確認する画面533も表示される。確認すべき状態情報に基づき、対象状態が画面533に表示され、状態確認ボタン535を押すと、当該状態が取得され別画面でその内容が表示される。別の状態、または別の機器の状態を確認したい場合は、他の状態を取得するを選択し、状態確認ボタン535を押すことで、別途状態を確認する画面が表示される。その結果、問題なければ確認ボタン536を押すことで、当該操作の実行確認が終了し、次の操作の実行へ移る。もし、期待状態と相違がある等問題があれば中止ボタン537を押すことで、オペレーションを中止できる。次に、図24により、状態確認ボタン535を押すと表示される画面について説明する。図24は確認すべき状態が、実際の機器状態と一致している場合つまりオペレーションエラーがない場合の状態確認画面560を示す。期待状態を表す画面561と、取得した運用管理対象機器の状態を表す画面562、また当該取得状態の根拠となる、当該運用管理対象機器上で出力されたログの対応部分を表す画面563が表示される。本例は、物理サーバps1の電源が投入され、正常にブートされていることを示している。これにより、実行後の結果が正しいことを運用管理者が逐次確認できる。なお、確認ボタン564を押すことで、状態確認画面は終了する。また、図25は確認すべき状態が、実際の機器状態と一致していない場合つまりオペレーションエラーがある場合の状態確認画面570を示す。同じく期待状態を表す画面561と、取得した運用管理対象機器の状態を表す画面562、また当該取得状態の根拠となる、当該運用管理対象機器上で出力されたログの対応部分を表す画面563が表示される。本例では、物理サーバps1上でのバッチbatch1の実行が最後まで正しく実行されず、期待状態と一致していないため、エラーが出力されている。これにより、実行結果に以上があることを運用管理者が逐次確認できる。なお、確認ボタン574を押すことで、状態確認画面は終了する。図26に示す通り、全オペレーション状況表示画面550では、複数の運用管理者によるオペレーションが入力されているときに、すべての操作とその実行状況を表示する。本画面は、運用管理者により、任意のタイミングで呼び出すことができる。操作はリストとして、実行時刻、発行者、対象機器、操作内容、実行状況の項目を表示する。本例では、ハイライトされている部分が、既に実行を終了している操作となる。これらの操作を実行途中で止めたい場合は、中止ボタン555を押す。以上、本発明の一実施例のオペレーション検証システムを詳述したが、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したのであり、必ずしも説明の全ての構成を備えるものに限定されものではない。上述の実施例中にも説明したように、本システム中の運用制御部は、複数のサーバ装置で構成しても良いし、一個のサーバ装置で構成しても良いことは言うまでもない。また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、それぞれの機能を実現するプログラムをCPUが実行することによりソフトウェアで実現する例を主体に説明したが、各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク装置のみならず、SSDSolidStateDrive等の記録装置、または、ICカード、SDカード、DVD等の記録媒体におくことができるし、必要に応じてネットワーク等を介してダウンロード、インストロールすることも可能である。"