JP5657475B2 - 運用管理装置、及び方法 - Google Patents

Description

データセンタにおけるサーバ等の機器に対する運用管理オペレーション検証を最適化し、運用管理を効率化する技術に関する。

通信ネットワークの発達と普及が急速に進み、ネットワークを介した情報システム利用を実現するクラウドコンピューティングが急速に普及しつつある。その結果、情報システムを格納するデータセンタの規模拡大やグローバルな拠点展開等により、その運用管理面でのコストが大きな問題となりつつある。例えば、データセンタの運用管理においては、膨大な数のサーバやネットワーク機器に対する、機器の動作状態の確認、再起動、バッチ処理やディスクのバックアップ、異常時の対応、またそれらのオペレーションに対する顧客報告等、オペレーションの内容は幅広く、またさらにサーバ等のＩＴ（Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｌｏｇｙ）機器だけでなく空調や電源の管理、セキュリティ監視や入退出管理までをも含み、これらのオペレーション効率化は必須の状況となっている。そこで、現在運用管理ストの低減を目指した、運用管理ミドルウェアによるシステム運用管理の一元化や、ＩＴＩＬ（Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｌｉｂｒａｒｙ）による運用管理プロセスの標準化、ランブック自動化（Ｒｕｎ Ｂｏｏｋ Ａｕｔｏｍａｔｉｏｎ）による運用業務手順の自動化、といった運用管理効率化の取組みがなされている。

しかしながら、これらの取組みは、例えば定期的な業務アプリケーションによる処理やディスクのバックアップのといったレベルの自動化であり、個々の機器に対する例えば再起動や設定等のシステムメンテナンス等のコマンドレベルの自動化にまでは至っておらず、人手によるオペレーションが中心となっている。しかしながら、人手による管理では、ヒューマンエラーに起因するオペレーションの誤りが発生することは避けられず、誤り発生時の対応にさらに工数が必要になるという問題も生じている。また、前述の通りサーバやネットワーク等の情報システムだけではなく、空調や電源の管理、セキュリティ監視や入退出管理まで、業務の幅は広くオペレーションも異種となり、それぞれを連動させた管理は誤り発生の可能性を高めている。また、複数の管理者が運用管理に携わる際に、互いの意思疎通に齟齬が発生し、誤りの発生を招く原因にもなっている。またさらに、誤りが発生したとしても、どの操作が原因であるかを追究するには、過去の操作を各機器が持つログを解析しながら辿る必要があるなど、非常に困難である。

これまで、障害発生防止のためのコマンドを自動実行する手法が提案されている。例えば、特許文献１では、手順作成の作業者に依存することなく、未然に不正手順の作り込みを防止するための運用手順作成時の不正手順チェックアウト方法を開示している。サーバの構成や顧客情報を構成情報として、実施時間帯による手順実施可否をポリシとして登録し、不正手順の作りこみを防止する。また、特許文献２では、コマンド実行判定手段を持ち、運用ルール定義による実行条件と管理対象のリソース情報により、実行の可否を判定する方法を開示している。

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

上述した先行技術を踏まえ、現在のデータセンタ運用管理においては、従来の運用管理対象機器に対するオペレーション業務をより一層効率化することが課題となっている。まず機器を操作する際に、例えば操作の前提条件を確認せずに作業を進めてしまい、操作自体を間違える、または操作に関わるパラメータに誤りが生じるという問題がある。次に、複数の運用管理者が機器のオペレーションに携わるとき、機器に対する複数の操作間に例えば実行順序の依存関係があることを運用管理者間で情報共有できずに誤りが発生するという問題がある。また、同一の運用管理者が複数の機器に対し同時にオペレーションを行うときに、同様に複数の操作間に例えば実行順序の依存関係があり、それを見落としてしまって誤りが生じるという問題がある。また、操作に対する結果の確認を行うタイミング、つまり操作が終了するタイミングがわからず、オペレーションに必要以上の時間が掛かってしまうという問題がある。また、操作に対する結果の確認において、機器の稼動状況から適切な検証項目を抽出し、操作の正しさを確認することは手間が掛かるという問題がある。

本発明の目的は、上述の課題を解決し、複数の運用管理対象機器に対する複数の運用管理操作に対し、実行前に操作の検証と操作順の最適化を行うことで、機器の運用管理を効率化することが可能な運用管理装置、及び方法を提供することにある。

上記の目的を達成するため、本発明においては、複数の運用管理対象機器に対し操作を行う運用管理部を備える運用管理装置であって、運用管理部は、記憶部と処理部とを備え、記憶部に、操作により変化が伴う運用管理対象機器の状態と、操作毎の処理時間と、操作に必要な状態条件を記憶し、処理部は、複数の操作が入力されたとき、記憶した運用管理対象機器の状態と処理時間と状態条件に応じて複数の操作の操作順を決定する運用管理装置を提供する。

また、上記の目的を達成するため、複数の運用管理対象機器に対し操作を行う運用管理機器による運用管理方法であって、操作により変化が伴う運用管理対象機器の状態と、操作毎の処理時間と、操作に必要な状態条件を記憶し、複数の操作が入力されたとき、当該複数の操作を、記憶した運用管理対象機器の状態と処理時間と状態条件に応じて操作順を決定する運用管理方法を提供する。

運用管理対象機器の状態と操作をモデル化し、操作に必要なリソース、操作条件と操作時間を記憶させることで、複数の操作が入力された際の操作の正しさを実行前に検証できる。また、当該複数の操作の実行が最短となるよう実行順を最適化できる。また個々の操作に対し、実行の終了タイミングと運用管理対象機器の稼動状況から確認すべき項目を出力することで、当該操作の正しさ確認が容易化できる。以上より、データセンタの運用管理業務を効率化できる。

第１の実施例の、データセンタにおけるオペレーション検証・最適化システムの全体構成を示した図である。 第１の実施例に係る、各種サーバの代表的な構成例を説明する図である。 第１の実施例に係る、機器種別テーブルを説明する図である。 第１の実施例に係る、状態テーブルを説明する図である。 第１の実施例に係る、状態ルールテーブルを説明する図である。 第１の実施例に係る、機器定義テーブルを説明する図である。 第１の実施例に係る、依存テーブルを説明する図である。 第１の実施例に係る、操作テーブルを説明する図である。 第１の実施例に係る、操作時刻予測テーブルを説明する図である。 操作コ 第１の実施例に係る、マンド変換テーブルを説明する図である。 第１の実施例に係る、状態記録テーブルを説明する図である。 第１の実施例に係る、操作記録テーブルを説明する図である。 第１の実施例に係る、オペレーション検証及び最適化の処理フローを示した図である。 第１の実施例に係る、オペレーション実施時以外の稼動状況及び機器状態チェックの処理フローを示した図である。 第１の実施例に係る、ログからの稼働状況の取得と状態更新の詳細フローを説明する図である。 第１の実施例に係る、オペレーションの実例を説明する図である。 第１の実施例に係る、操作依存グラフを説明する図である。 第１の実施例に係る、操作スケジューリング結果を説明する図である。 第１の実施例に係る、物理サーバのログ出力の例を説明する図である。 第１の実施例に係る、オペレーション入力画面を説明する図である。 第１の実施例に係る、オペレーション確認画面を説明する図である。 第１の実施例に係る、オペレーション実行前に検出されたエラーを表示する画面を説明する図である。 ステップ実行時のオペレーション確認画面を説明する図である。 第１の実施例に係る、期待状態と一致している場合の状態確認画面を説明する図である。 第１の実施例に係る、期待状態と一致していない場合の状態確認画面を説明する図である。 第１の実施例に係る、全オペレーションの実行状況を表示する画面を説明する図である。

以下、本発明の各種の実施形態を図面に従い説明する。以下の説明においては、本発明の対象となるＩＴシステムとしてデータセンタを例示するが、本発明はその他のＩＴシステムにも適用できるものである。

第１の実施例として、データセンタに適用したオペレーション検証最適化システムを説明する。
＜全体の構成＞
図１は実施例１のデータセンタにおけるオペレーション検証システム構成の一例を示す図である。データセンタにおいては、本検証システムの運用管理対象となる装置、すなわち運用管理対象機器として、データセンタの運用設備系機器と、サーバ装置等のＩＴ機器がある。このデータセンタの運用設備系機器としては、図１の右上に示したような、空調機器１０４、無停電電源装置・電源安定化装置等を含む電源装置１０５、監視カメラ・人感センサ等を含む監視装置１０６、入出力ゲート等を含むセキュリティ装置１０７等がある。また、データセンタのＩＴ機器には、同図の右下に示すように、サーバ装置１０８、ディスク装置１０９、ルータ１１０等が上げられる。データセンタ内において、これらのＩＴ機器と運用設備系機器は互いに強調して動作することで、省エネや運用管理省力化の点で効果を得ることができる。

さらに本検証システムは、これらの運用管理対象機器に対して、遠隔でコマンド発行や実行状況の確認を行うことができるよう、ユーザが通常ＩＴ機器へのアクセスで使用する場内ネットワーク１１４と分離された、管理ネットワーク１１３を敷設し、各機器・装置に接続する。管理ネットワーク１１３には、各機器を管理する運用管理サーバ１００、各機器に対するオペレーションの有効性を検証し最適化する処理を実施するオペレーション検証サーバ１０１、機器の運用管理とオペレーション検証及び最適化に必要な各種情報を格納・管理する運用モデル管理サーバ１０２を接続する。本明細書において、運用管理サーバ１００、オペレーション検証サーバ１０１、及び運用モデル管理サーバ１０２を纏めて、運用管理機器、或いは運用管理部と呼ぶ場合がある。この運用管理機器、あるいは運用管理部は、本実施例の検証システムの運用管理機能、すなわち運用管理対象機器の運用管理と、オペレーション検証及び最適化の機能を備えている。

運用管理サーバ１００には、運用管理者がオペレーションを実施する端末１０３が接続される。なお、運用管理部の各種サーバ１００〜１０２はすべて、またはその一部を１台のサーバ装置上で実行する構成としても良い。例えば、運用管理サーバ１００とオペレーション検証サーバ１０１を一台のサーバ装置とする、運用管理サーバ１００、オペレーション検証サーバ１０１、及び運用モデル管理サーバ１０２を一台のサーバ装置としても良い。または管理対象とする機器の規模に応じて、当該各種サーバを機能の細分化や処理の並列化により、さらに複数台に分散させる構成としても良い。

図２に本実施例のオペレーション検証最適化システムにおける各種サーバの代表的な構成例を示す。サーバ１００、１０１、１０２は、処理部として演算処理を実行する中央演算装置（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ：ＣＰＵ）１５１、記憶部として一時的にプログラム・データを記憶するメモリ１５２、各種インタフェースに対する制御を行うコントローラ１５３、記憶部として各種データ・プログラムを保持するハードディスクドライブ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ：ＨＤＤ）などの記憶装置１５４、外部ネットワークと接続するネットワークインタフェース１５５、ディスプレイやキーボード等の周辺装置を接続する周辺装置インタフェース１５６から構成される。

また、図１の管理ネットワーク１１３は、ファイアウォール／ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）装置１１１を介して、場外ネットワーク１１５に接続される。従って、上記で述べた管理対象とする各種機器１０４〜１１０、または管理を行う各種サーバ１００〜１０２の一部、もしくはすべてが場外ネットワーク１１５を介して別のデータセンタ等に設置されていても良い。すなわち、遠隔で他のデータセンタに存在する各種機器を、当該のデータセンタで管理する構成でも良く、また管理に必要な一部のサーバ、またはすべてのサーバが遠隔のデータセンタに設置されて当該データセンタの各種機器を管理する構成としても良い。また、場内ネットワーク１１４も同じくファイアウォール／ＶＰＮ装置１１２を解して場外ネットワーク１１５に接続される。

運用管理サーバ１００は、運用管理者に対する対象機器のオペレーションを実施するためのインタフェースを提供する。つまり、接続された端末１０３を介して、運用管理者に対してオペレーションの入力手段、及び当該機器の稼動状況やオペレーション実行状況を表示する手段を提供する。また、オペレーション検証や最適化を行うための、運用管理対象機器の構成、状態、操作、操作記録、状態記録を作成し、運用モデル管理サーバ１０２の記憶部である記憶装置１５４上に格納される各種モデルテーブル１２０〜１２９を作成・更新する。オペレーション検証サーバ１０１におけるオペレーション検証及び最適化の手順詳細については、後述する。

＜モデルテーブルについて＞
次に、運用モデル管理サーバ１０２上で管理される各種モデルテーブル１２０〜１２９に関して説明する。運用管理対象機器の構成や状態をモデル化してテーブルで表現することにより、運用管理者が入力するオペレーションの有効性を検証したり、オペレーションを最適化したりすることを可能とする。つまり、各テーブルの構成要素は、例えば検証対象とするオペレーションの種類によって変わるため、目的とする検証や最適化機能に合わせて、それぞれのテーブルの構成要素を定義する必要がある。なお、これらの各種モデルテーブル１２０〜１２９は、上述した運用モデル管理サーバ１０２の記憶部に蓄積される。

＜機器種別テーブル＞
まず、図３を用いて、機器種別テーブル１２０の構成を説明する。当該テーブル１２０は、運用管理対象とする機器の種別を定義する。また、このとき各機器が取り得る状態、即ち機器種別毎にモデル化すべき状態も合わせて定義する。なお、状態の種類に関しては、図４に示す状態テーブル１２１で定義する。機器種別テーブル１２０は、機器種別を表す列項目２００、当該機器種別に対し取り得る状態を定義する列項目２０１で構成される。

図３では、各行で定義した機器の種別を説明する列項目２０２を付している。例えば、機器種別名ｐｓｅｒｖｅｒは物理サーバを意味し、取り得る状態として、電源状態を表すｐｏｗｅｒ、ネットワークアドレスを表すｎｗ＿ａｄｒｓ、温度を表すｔｅｍｐ、ユーザプロセス数を表すｕｓｅｒ＿ｐｒｏｃｅｓｓである。また、機器種別名ｖｓｅｒｖｅｒは仮想サーバを意味し、取り得る状態として、電源状態を表すｐｏｗｅｒ、ネットワークアドレスを表すｎｗ＿ａｄｒｓ、ユーザプロセス数を表すｕｓｅｒ＿ｐｒｏｃｅｓｓ、ホストサーバ名を表すｈｏｓｔ＿ｓｒｖである。以下、同様にルータｒｏｕｔｅｒ、空調機ａｉｒｃｏｎｄ、電源装置ｕｐｓ、ディスク装置ｓｔｏｒａｇｅ、監視カメラｃａｍｅｒａ、セキュリティゲートｓｇａｔｅが定義されている。

＜状態テーブル＞
次に、図４を用いて、状態テーブル１２１の構成を説明する。当該テーブル１２１は、各運用管理対象機器の状態と、それに対応して取り得る値や、実システムの状態を更新する、標準の更新頻度を定義する。状態テーブル１２１は、状態名を表す列項目２１０、状態に対応する値の種類や範囲を表す列項目２１１、当該状態名に対しさらに細分化した状態であるサブ状態を定義する列項目２１２、細分化した状態に対応する値の種類や範囲を表す列項目２１３、各状態の実機上での状況をテーブル上の状態に反映させるための更新頻度を表す列項目２１４で構成されている。なお図４では、各行で定義した状態を説明する列項目２１５を付している。例えば、状態名ｐｏｗｅｒは電源状態を表しており、取り得る値は“ｏｎ”または“ｏｆｆ”の何れかである。更新頻度２１４は１ｍｓとなっており、別途指定が無い限り１ミリ秒毎に実機の電源状態を確認し当該テーブルに反映させる。また状態名ｔｅｍｐは温度を表しており、対応する値の取り得る範囲は-30〜60であり、更新頻度は１０秒毎となっている。

また、例えば状態名ｎｗ＿ａｄｒｓは細分化したサブ状態２１２を持ち、ＩＰアドレスｉｐ、サブネットマスクｓｕｂｎｅｔ、ゲートウェイアドレスｇｗを定義する。それぞれの状態の取り得る値は、ＩＰｖ４のアドレス範囲０〜２＾３２の整数となる。なお、更新頻度はＯＰとあるが、これはネットワークアドレスに関わるオペレーションが発生した都度、実機のネットワーク状態を確認し当該テーブルに反映させる。なお、本例で示した数値範囲等の表現は一例であり、当該項目を定義するための必要な表現を適宜実装することになる。

＜状態ルールテーブル＞
次に、図５を用いて、状態ルールテーブル１２２の構成を説明する。当該テーブル１２２は、各運用管理対象機器における状態間の定常的な関係を定義する。オペレーション毎や状態の更新毎に、本テーブルで定義された状態間の関係性をチェックすることで、システム状態の正しさを確認できる。状態ルールテーブル１２２は、状態ルール名を表す列項目２２０、基準状態を表す列項目２２１、当該基準項目に対し関係する状態条件を表す列項目２２２で構成される。なお図５では、各行で定義した状態ルールを説明する項目２２３を付している。例えば、状態ルール名ｒｌ＿ｐｓｒｖ＿ｐｏｗｅｒは、基準状態をｐｓｅｒｖｅｒ．ｐｏｗｅｒ＝ｏｎ、つまり物理サーバの電源がＯＮ状態としている。このときの状態条件はｐｓｅｒｖｅｒ＃ｕｐｓ．ｐｏｗｅｒ＝ｏｎ＆ｐｓｅｒｖｅｒ＃ａｉｒｃｏｎｄ．ｐｏｗｅｒ＝ｏｎ、つまり当該物理サーバが依存する（接続される）電源装置の電源がＯＮである、かつ当該物理サーバが依存する（冷却される）空調機器の電源がｏｎであるべきことを示している。

また、例えば状態ルール名ｒｌ＿ｐｓｒｖ＿ｉｐ＿ａｄｒｓは、基準状態をｐｓｅｒｖｅｒ．ｉｐ＿ａｄｒｓ＝＊、つまり物理サーバのＩＰアドレス（値は任意）としている。このときの状態条件はｐｓｅｒｖｅｒ．ｉｐ＿ａｄｒｓ＝［１０．０．１０．１−９］、つまり当該物理サーバのＩＰアドレスが１０．０．１０．１〜９の範囲に設定されるべきことを示している。なお、以上で示した数値範囲や、機器や状態の関連性を表す方法は一例であり、当該項目を定義するための必要な表現を適宜実装することになる。

＜機器定義テーブル＞
次に、図６を用いて、機器定義テーブル１２３の構成を説明する。当該テーブル１２３は、運用管理対象とする実機器を定義するものであり、初期状態を併せて定義可能である。機器定義テーブルは、機器名を表す列項目２３０、機器種別テーブル１２０で定義した機器種別を表す列項目２３１、各機器上の状態を表す列項目２３２で構成される。例えば、機器名ｐｓ１は機器種別がｐｓｅｒｖｅｒ、つまり物理サーバであり、その状態はｐｏｗｅｒ＝ｏｆｆ（電源ＯＦＦ）、ｕｓｅｒ＿ｐｒｏｃｅｓｓ＝０（ユーザプロセスは無し）、ｎｗ＿ａｄｒｓ［０］−＞ＩＰ＝１０．０．１０．１０（ポート０番のＩＰアドレスは１０．０．１０．１０）となっている。同様に、本例では物理サーバｐｓ２、ｐｓ３、仮想サーバｖｍ１、電源装置ｕｐｓ１、ルータｒｏｕｔｅｒ１、空調機器ａｉｒｃ１、ディスク装置ｓｔｒ１、ｓｔｒ２、監視カメラｃａｍ１、セキュリティゲートｓｇａｔｅ１を定義している。

＜依存テーブル＞
次に、図７を用いて依存テーブル１２４の構成を説明する。当該テーブル１２４は、機器間の論理的または物理的な、依存関係であるトポロジまたは接続関係を定義する。例えば、主従関係を持つサーバ間や、サーバとそれに接続される周辺機器、等の依存関係を定義する。依存テーブルは、依存元の機器名を表す列項目２４０、依存先の機器名を表す列項目２４１、依存関係の種類を表す列項目２４２で構成される。

図７の例では、機器名が物理サーバｐｓ１、ｐｓ２、ｐｓ３及びディスク装置ｓｔｒ１、ｓｔｒ２に対し、依存先が電源装置ｕｐｓ１となっており、また種別が物理的に接続されていることを表すＰＨＹＳＩＣＡＬＬＹ＿ＣＯＮＮＥＣＴＥＤとなっている。これは、当該物理サーバ及び当該ディスク装置が、当該電源装置ｕｐｓ１に接続され、依存していることを表す。また、機器名がディスク装置ｓｔｒ１、ｓｔｒ２に対し、依存先が物理サーバｐｓ１、ｐｓ２、ｐｓ３、仮想サーバｖｍ１、ｖｍ２となっており、また種別が論理的に接続されていることを示すＬＯＧＩＣＡＬＬＹ＿ＣＯＮＮＥＣＴＥＤとなっている。これは、当該ディスク装置が当該物理サーバまたは当該仮想サーバに論理的に接続され、依存していることを示す。また、機器名が仮想サーバｖｍ１、ｖｍ２に対し、依存先が物理サーバｐｓ１、ｐｓ２、ｐｓ３となっており、また種別が当該仮想サーバをホストする物理サーバであることを示すＨＯＳＴＥＤとなっている。これは、当該仮想サーバが当該物理サーバ上で動作することを示す。

＜操作テーブル＞
次に、図８を用いて操作テーブル１２５の構成を説明する。当該テーブル１２５は、運用管理者による対象機器のオペレーションであるコマンド操作を定義する。コマンド操作は、対応する機器状態を変更することを意味し、コマンド操作をモデル上での状態変更と対応付けることで、オペレーション検証を可能とする。操作テーブルは操作名を表す列項目２５０、操作対象の機器種別を表す列項目２５１、操作におけるパラメータ等の変数を表す列項目２５２、操作時の状態条件を表す列項目２５３、操作による変更後の状態を表す列項目２５４、操作に掛かる時間を表す列項目２５５で構成される。

なお図８では、各行で定義した操作の内容を説明する列項目２５６を付している。例えば物理サーバの電源をＯＮにする操作ｐｏｗｅｒ＿ｏｎについて説明する。操作対象とする機器種別はｐｓｅｒｖｅｒであり物理サーバを示す。操作パラメータはＳＥＲＶ：ｐｓｅｒｖｅｒであり、ＳＥＲＶが指定される物理サーバ名となる。次に、操作条件ＳＥＲＶ．ｐｏｗｅｒ＝ｏｆｆより、当該操作を行うための状態条件として、当該サーバの電源がＯＦＦであることを定義している。次に操作後の状態ＳＥＲＶ．ｐｏｗｅｒ＝ｏｎより、当該操作により当該サーバの電源状態をＯＮに変更することを定義している。次に、操作時間の定義がＲＥＦ（参照）となっているが、これは操作時間予測テーブル１２６を参照し操作時間を算出することを示している。

次のファイルのコピー／バックアップを行う操作ｃｏｐｙ＿ｆｉｌｅについて説明する。捜査対象とする機器種別はｓｔｏｒａｇｅでありディスク装置を示す。操作パラメータはＦＲＯＭ：ｓｔｏｒａｇｅ，ＴＯ：ｓｔｏｒａｇｅ，ＦＩＬＥ：ＬＩＳＴであり、ＦＲＯＭがコピー元のディスク装置、ＴＯがコピー先のディスク装置、ＦＩＬＥがリスト表現によるファイル名となる。次に、操作条件Ｅｘｉｓｔ（ＦＩＬＥ，ＦＲＯＭ．ｆｉｌｅ）より、当該操作を行うための状態条件として、ディスク装置ＦＲＯＭにファイルＦＩＬＥが存在することを定義している。なお、Ｅｘｉｓｔは、リスト操作（存在確認）を行う関数を意味している。次に捜査後の状態をＡｐｐｅｎｄ（ＦＩＬＥ，ＴＯ．ｆｉｌｅ），ＴＯ．ｖｏｌ＿ｕｓｅｄ＋＝ＦＲＯＭ．ｆｉｌｅ［ＦＩＬＥ］−＞ｓｉｚｅより、ファイルＦＩＬＥのディスク装置ＴＯのファイルリストへの追加、及びディスク装置ＴＯの使用容量の対象ファイルサイズ分の増加を定義している。次に、操作時間の定義がＲＥＦとなっているが、これは操作時間予測テーブル１２６を参照し操作時間を算出することを示している。

同様に、図８では例として物理サーバの電源ＯＦＦ（ｐｏｗｅｒ＿ｏｆｆ）、仮想サーバの割り当て（ａｓｓｉｇｎ＿ｖｍ）、仮想サーバの起動（ｐｏｗｅｒ＿ｏｎ）、アプリケーションの起動（ｓｔａｒｔ＿ａｐｐｌｉ）、アプリケーションの停止（ｓｔｏｐ＿ａｐｐｌｉ）、バッチの実行（ｅｘｅｃ＿ｂａｔｃｈ）を定義している。なお、以上で示した操作条件の表現、各種関数は一例であり、当該項目を定義するための必要な表現・関数を適宜実装することになる。

＜操作時間予測テーブル＞
次に、図９を用いて、操作時間予測テーブル１２６の構成を説明する。当該テーブル１２６は、操作テーブル１２５で定義した操作に対し、操作時間の計算式、または操作時間そのものを定義し、種類として予測型と実測型がある。操作時間予測テーブルは、識別名を表す列項目２６０、時刻予測対象とする操作を表す列項目２６１、操作時間の表現が算出式か時間かを表す列項目２６２、算出式または操作時間を表す列項目２６３で構成される。例えば識別名ｔｉｍｅ＿ｆｉｌｅ＿ｃｏｐｙは、ファイルコピーに掛かる時間を表し、操作対象は操作テーブル１２５で定義されているｃｏｐｙ＿ｆｉｌｅとなる。種類はＥｓｔｉｍａｔｅｄＥＱであり、これは予測算出式で表現されることを表す。本例では、算出式はＳｕｍ（ＦＩＬＥ．ｆｉｌｅ＿ｓｉｚｅ）／Ｍｉｎ（ＦＲＯＭ．ｔｒｏｕｇｈｐｕｔ，ＴＯ．ｔｈｒｏｕｇｈｐｕｔ）と定義されており、コピー対象のすべてのファイルＦＩＬＥのサイズ合計値を、ディスク装置ＦＲＯＭまたはＴＯのスループット（バイト／秒）のうち小さい方のスループットで割った値を、操作時間としている。なお、Ｓｕｍは合計値を求める関数、Ｍｉｎは最小値を求める関数である。また、スループットは装置の仕様値を用いるか、または当該操作時に測定することで求める。

次に、例えば識別名ｔｉｍｅ＿ｓｔａｒｔ＿ａｐｐｌｉは、アプリケーション起動に掛かる時間を表し、操作対象は操作テーブル１２５で定義されているｓｔａｒｔ＿ａｐｐｌｉとなる。種類はＭｅａｓｕｒｅｄＶＬであり、これは実測による操作時間で表現されることを表す。本例では、（ＳＥＲＶ＝＝ｖｍ１＆＆ＡＰＰ＝ａｐｐｌｉ１）：２５ｓ、（ＳＥＲＶ＝＝ｐｓ１＆＆ＡＰＰ＝＝ａｐｐｌｉ２）：２０ｓと定義され、実行サーバＳＥＲＶが仮想サーバＶＭ１でかつ実行対象のアプリケーションＡＰＰがａｐｐｌｉ１であるとき操作時間は２５秒、実行サーバＳＥＲＶが物理サーバｐｓ１でかつ実行対象のアプリケーションＡＰＰがａｐｐｌｉ２であるとき操作時間は２０秒となる。

同様に図９では他の例として、電源ＯＮ（ｔｉｍｅ＿ｐｏｗｅｒ＿ｏｎ）、電源オフ（ｔｉｍｅ＿ｐｏｗｅｒ＿ｏｆｆ）、バッチ実行（ｔｉｍｅ＿ｂａｔｃｈ＿ｅｘｅｃ）、アプリケーション停止（ｔｉｍｅ＿ｓｔｏｐ＿ａｐｐｌｉ）の各操作時間を定義している。

次に操作コマンド変換テーブル１２７の構成を、図１０を用いて説明する。当該テーブル１２７は、操作テーブル１２５で定義した操作に対応した、実機上でのコマンドを定義する。操作コマンド変換テーブル１２７は、操作テーブル１２５で定義した対応操作名を表す列項目２７０、対象となる機器を表す列項目２７１、及び生成コマンドを定義する列項目２７２で構成される。例えば、電源ＯＮ操作ｐｏｗｅｒ＿ｏｎは、対象機器が物理サーバｐｓ１であり、そのとき生成するコマンドはｐｓ１を制御するサービスプロセッサに対する遠隔電源ＯＮを意味する／ｓｂｉｎ／ｐｏｗｅｒｏｎ ｛ＰＳＥＲＶ．ｎｗ＿ａｄｒｓ［０］．ｉｐ｝ ｎｏｗを定義している。同様に、図１０の例ではファイルコピー（ｃｏｐｙ＿ｆｉｌｅ）、電源ＯＦＦ（ｐｏｗｅｒ＿ｏｆｆ）、仮想サーバの割り当て（ａｓｓｉｇｎ＿ｖｍ）の生成コマンドを定義している。なお、以上で示した算出式や操作時間の表現、各種関数は一例であり、当該項目を定義するための必要な表現・関数を適宜実装することになる。

＜状態記録テーブル＞
次に、図１１を用いて状態記録テーブル１２８を説明する。当該テーブルは、運用管理対象機器の各状態を保存し、機器状態の更新を記録する。状態記録テーブル１２８は、機器定義テーブル１２３と同じく、機器名を表す列項目２８０、機器の種別を表す列項目２８１、記録時の状態を表す列項目２８２と、さらに記録時の通し番号である状態番号と記録時間を表すヘッダ情報２８３で構成される。記録状態２８２における状態項目は機器定義テーブル１２３における初期状態２３２で定義した状態項目そのものである。このように、例えば一定時間毎、または状態変化時、またはオペレーションの前後のタイミングにおいて、各状態を記録しておくことで、エラーや不具合等の原因追及やオペレーションの検証に役立てることができる。

＜操作記録テーブル＞
次に、図１２を用いて、操作記録テーブル１２９を説明する。当該テーブルはオペレーション（操作）の履歴を記録する。操作記録テーブル１２９は、時間を表す列項目２９０、操作テーブル１２５で定義された操作名を表す列項目２９１、操作パラメータを表す列項目２９２、操作前後の状態を記録した状態記録テーブル１２８の状態番号２８３を表す列項目２９３で構成される。このように、操作の履歴を記録しておくことで、操作に起因した不具合の原因追及に役立てることができる。

＜オペレーション検証・最適化の処理フロー＞
図１３を用いて、運用管理サーバ１００、オペレーション検証サーバ１０１、及び運用モデル管理サーバ１０２における、運用管理者が入力したオペレーションの検証・最適化の処理フローを説明する。この処理フローは、運用管理部を構成する、運用管理サーバ１００、オペレーション検証サーバ１０１、及び運用モデル管理サーバ１０２内のＣＰＵのプログラム処理等で実現されるものであり、運用管理部の運用管理サーバ１００、またはオペレーション検証サーバ１０１、または運用モデル管理サーバ１０１のいずれかで実行、または個々の処理で各サーバに分散して実行されるものである。

まず、運用管理者は運用管理対象機器に対するオペレーション（操作）を、運用管理サーバ１００に接続されたオペレーション端末１０３上で入力する（３０１）。なおオペレーションは、事前に操作テーブル１２５にて定義した操作を選択的に入力することで、行う。このとき、複数の管理者が同一または相違の機器を対象としたオペレーションを同じタイミングで行ったり、一人の管理者が複数のオペレーションを同時に行ったりすることが考えられる。そこで、オペレーションをある時間やオペレーションの種類、または対象機器に応じてグループ化し、グループ単位で検証・最適化を行う。

オペレーション入力後、まず操作対象機器の最新の状態を取得し、モデル上の状態を更新する（３０２）。具体的には、機器定義テーブル１２３の状態定義２３２にて定義された各種状態値を更新する。なお、稼動状況の取得方法としては、対象機器に保持される各種ログを解析する、または各種機器上でエージェントプログラム等を実行させることで取得する方法が考えられる。次に入力、グループ化された複数オペレーションは、オペレーション検証サーバ１０１により、まずオペレーション間の依存解析を行う（３０３）。オペレーションは、操作テーブル１２５で定義された各操作と対応付けられ、操作単位での依存解析を行うことになる。オペレーション検証サーバ１０１における依存解析は、操作テーブル１２５における操作条件２５３と依存テーブル１２４の依存関係を用いて、操作を行う際の前提条件を満たしているか、また操作後の状態に対して状態ルールテーブル１２２を用いて操作後状態条件を満たしているかを確認することで、操作間の実行順序や並列実行可能性を決定するための操作依存グラフを作成する（３０４）。次に、オペレーション検証サーバ１０１上で、各操作に対する実行時間予測を行う（３０５）。実行時間予測は、操作時間予測テーブル１２６を用いて決定する。実行時間は、当該テーブル上の算出式または過去の実測による時間情報を用いて決定する。

次に、オペレーション検証サーバ１０１は、操作依存グラフと、操作時間予測から、操作の実行順序とタイミングを決定する操作スケジューリングを行う（３０６）。操作スケジューリングにより、各操作の実行順序、実行タイミング、及び各操作の実行終了タイミングを求めることができる。次に、オペレーション検証サーバ１０１は、オペレーション実行後の状態として、操作による状態変更に基づき、最終的な状態を予測する（３０７）。次に、オペレーション検証サーバ１０１は、当該状態が当該オペレーションに対する期待状態となっているか、また状態ルールテーブル１２２または依存テーブル１２４を用いて状態間の定常条件を満たしているかをモデルチェックすることで確認する（３０８）。

その結果、当該操作による変更後状態が期待通りとならない場合（３０９）は、運用管理サーバ１００は、運用管理者へその旨通知し、入力した操作に誤りが無いかを確認するよう促す（３１６）。また、モデルチェック３０８の結果、当該操作による変更後状態が期待通りとなる場合（３０９）は、運用管理サーバ１００は、操作スケジューリング３０６の結果から得られた各操作の終了予測タイミングと、操作テーブル１２５の操作後状態２５４から得られる、各操作においてその実行が正しく行われたかを検証するために確認すべき状態項目を、運用管理者に通知する（３１０）。これによって、これらの操作を実機上で実行する際、運用管理者は実行状況を逐次確認するためのタイミングと、確認すべき状態項目を知ることが可能となる。

その後、例えば運用管理サーバ１００から、操作スケジューリング３０６のタイミングで、各機器に対する操作が発行され、それぞれの操作が実行される（３１１）。１個の操作が終了した段階で、操作対象機器の最新の状態を取得し、モデル上の状態を更新する（３１２）。そして、オペレーション検証サーバ１０１は、モデルチェックにより、実機上で行われた操作による変更後状態が期待通りとなるかを確認する（３１３）。もし期待状態となっていなければ（３０９）は、操作を中断し、その旨を運用管理サーバ１００を介して運用管理者へ通知し、また入力した操作に誤りが無いかを確認するよう促す（３１６）。当該操作による変更後状態が期待通りとなる場合（３０９）は、処理３１２で取得した機器の状態及び操作を、運用モデル管理サーバ１０２の状態記録テーブル１２８、及び操作記録テーブル１２９にそれぞれ記録させる（３１５）。

その後、すべての操作がまだ終了していなければ（３１７）、次の操作実行を繰り返し（３１１〜３１５）、すべての操作が終了していれば（３１７）、運用管理サーバ１００は、正常終了を運用管理者へ通知し（３１６）、オペレーション入力待ち状態に戻る。なお、ここでは操作毎に逐次、操作対象機器の最新状態の取得と、操作による変更後状態のモデルチェックを繰り返す処理フローとしているが、複数の操作群を実行後に一括して、当該操作群による変更後状態のモデルチェックを行う処理フローとしても良い。

＜オペレーション実施時以外の処理フロー＞
次に、図１４を用いて、運用管理対象機器に対するオペレーション実施時以外の、定常時における機器状態検証処理フローを説明する。本処理フローは、運用管理部を構成する、運用管理サーバ１００、またはオペレーション検証サーバ１０１、または運用モデル管理サーバ１０１いずれかで実行、または個々の処理で各サーバに分散して実行される。

まず、状態テーブル１２１及び機器定義テーブル１２３で定義された状態に対応する、運用管理対象機器の実機状況を監視する（３２１）。監視の方法は、当該機器が保持するログを解析することで対象の状態変化を検出する、または当該機器上でエージェントプログラム等を実行させ対象の状態変化を検出する、等の方法が考えられる。また、状態監視以外に、定期的に状態チェック及び更新を行っても良い（３２１）。この場合は、状態テーブル１２１で定義された更新頻度２１４の時間毎に機器の稼動状況をチェックするか、または当該更新頻度で次の処理ステップ３２２に移行しても良い。

監視対象の状態が変化後、または更新頻度時間が到来後、当該対象機器の稼動状況の取得と機器定義テーブル１２３の状態定義２３２に対応する仮の機器定義テーブルへ状態更新を行う（３２２）。その後、当該状態をあるべき定常状態を定義する機器定義テーブル１２３の状態定義２３２と比較し一致しているか、また状態ルールテーブル１２２または依存テーブル１２４を用いて状態間の定常条件を満たしているかをモデルチェックする。その結果、不一致や違反が無ければ、再度状態変化の検知またはチェックタイミングの監視（３２１）を繰り返す。もし、不一致や違反があれば、前記仮の機器定義テーブルにおける状態定義を、状態記録テーブル１２８として記録し（３２５）、運用管理サーバ１００を介して、運用管理者へ通知する（３２６）。

＜ログ解析による状態取得のフロー＞
次に、図１５を用いて、図１３、図１４における、稼働状況の取得と状態更新３０２、３１２、３２２の詳細フローを説明する。前述の通り、本処理では操作対象機器の最新の状態を取得し、機器定義テーブル１２３の状態定義２３２にて定義された各種状態値を更新する。図１５は運用管理対象機器１０４〜１１０に保持されるログを解析することで状態を取得・更新するフローである。以下の説明において、本フローはオペレーション検証サーバ１０１が実行するとするが、運用管理サーバ１００または運用モデル管理サーバ１０２で実行しても良い。また、一部の処理を、ログを保持する操作対象機器側で分担して実行する構成としても良い。

まず、図１５において、管理ネットワーク１１３を介して運用管理対象機器に保持されているログを取得する（３３１）。なお取得するログは、前回取得時からの差分とすることで、取得にかかる時間を抑えることができる。次に、取得したログを解析する（３３２）。ログの解析は、予め取得対象となる状態情報に対応したキーワードを入力しておき、ログの内容をキーワードと照らし合わせることで、ログの意味づけと対応するパラメータの抽出を行う。なお、前述したとおりステップ３３１及び３３２を、ログを保持する運用管理対象機器側で実行しても良い。これにより、管理ネットワーク１１３を流通する情報量を小さくできるため、遠隔管理においては有利であるが、当該対象機器の演算リソースを一部占有してしまうという欠点もある。次に、ログの意味とパラメータ抽出の結果から、状態テーブル１２１を検索し、当該テーブル上で登録された状態を検索する（３３３）。その結果、もし登録済みの状態と抽出された状態に差分がある場合は、差分があったことを記録し（３３４）、当該テーブル１２１上の状態を更新する（３３５）。

＜オペレーション最適化の具体例＞
次に、図１６を用いて、本実施例にける、オペレーション最適化の具体例として、３種類の運用管理業務を実施する例を説明する。図１６のテーブル４００において、４０１〜４０３はそれぞれ３種類の運用管理業務Ａ、Ｂ、Ｃを示している。なお、当該の３業務を３人の運用管理者が同時に行う、または当該の業務を１人の管理者が同時に行うことを想定する。業務Ａ（４０１）はサーバ再起動及び仮想サーバを起動する。業務Ａで実施する操作は、まず業務Ａでは物理サーバｐｓ１を対象とし電源ＯＦＦの操作４１０、次にｐｓ１に対する電源ＯＮの操作４１１、仮想サーバｖｍ１に対するホストサーバ指定の操作４１２と、以下当該テーブル４００のオペレーションリストに示す通り定義されている。なお、本例ではオペレーションリストにおける操作は、掲載されている順に操作されるとする。つまり、業務内の操作では、同時に実行可能な操作は含まない。ただし、同時に実行可能な操作を含めることもできる。その場合には、オペレーション入力時に同時実行可能な操作群として定義する必要がある。また業務Ｂ（４０２）は定時バッチ処理を、業務Ｃ（４０３）は定時バックアップ処理を行う。各業務には、優先度を設定でき、操作スケジューリング３０６の際、複数の操作が可能な条件において、当該操作の実行順を決定するために用いられる。本例では、優先度を１〜１０で表し、数字が大きいほど優先度が高い。

＜操作依存グラフの例＞
次に、図１３で説明した処理フローに基づき、テーブル４００で示す種類の運用業務の操作を最適化する。当該操作間の依存解析を行い（３０３）、操作間の依存関係を表す操作依存グラフの例を図１７に示す。

図１７の操作依存グラフは、図８で示した操作テーブル１２５から作成される。円が操作を表し、矢印が依存関係を表す。また、円の右下に示す数値は、操作時間を表す。例えば、業務Ａ（４０１）の操作４１１（物理サーバｐｓ１の電源ＯＮ）は操作４１０（ｐｓ１の電源ＯＦＦ）に依存し、操作４１０の後に有効となる。同様に、例えば業務Ｂ（４０２）の操作４１６（ｐｓ１上でのアプリ２起動）は、ｐｓ１が起動状態である必要から、業務Ａの操作４１１（ｐｓ１の電源ＯＮ）に依存し、操作４１１後に有効となる。また、業務Ｃ（４０３）の操作４１５（ディスク装置ｓｔｒ１のバックアップ）は、依存する操作が無いため、例えば業務Ａ（４０１）の操作４１０と同時に実行することが可能である。このように、すべての操作間での依存関係をグラフ化することで、実行順の決定や、並列に実行可能な操作の抽出ができる。なお、もし性能上の理由等で同時に実行させない場合は、操作テーブル１２５の操作条件２５３に対応する条件を明記する必要がある。

＜操作スケジューリング結果の例＞
図１２の操作スケジューリング３０６では、図１７の操作依存グラフと、各操作の操作時間から、最終的な各操作の発行のタイミングを決定する。スケジューリングの結果例を図１８に示す。

図１８において、横軸は時間で、長方形が１つの操作を表す。また、Ｃの文字が書かれた長方形は、直前の操作結果を確認するタイミングを表す。スケジューリングは、操作依存グラフの上部から順に割り当てる。ただし、同一の機器に対する別業務の複数操作が同時に発行可能となる場合には、前述の通り業務別の優先度を利用して、割り当てを決定する。

図１７の操作依存グラフより、まず操作４１０（物理サーバｐｓ１の電源ＯＦＦ）と操作４１５（ディスク装置ｓｔｒ１のバックアップ）がまず実行可能であり、操作を割り当てる。操作４１０の操作時間は図１７より３０秒であり、また操作４１５は１５５秒である。従って、３０秒後には操作４１０の実行確認が可能となり、その後に操作４１１（ｐｓ１の電源ＯＮ）を割り当てることができる。続いて操作４１１の操作時間は４５秒であり、当該時間後に操作４１１の確認が可能となる。

その後、操作４１２（仮想サーバｖｍ１のｐｓ１割り当て）と操作４１６（ｐｓ１上でのアプリ２起動）を割り当てることができる。操作４１２と操作４１６は同時に実行可能であるため、同時に操作を割り当てる。操作４１２の操作時間は１０秒、操作４１６の操作時間は２０秒であり、操作４１２終了後、操作４１３（ｖｍ１の起動）が割り当てられる。以上、同様に操作４１６終了後に操作４１７（ｐｓ１上でバッチ１実行）、操作４１３終了後、操作４１４（ｖｍ１上でアプリ１起動）が割り当てられる。また、操作４１７終了後、操作４１８（ｐｓ１上でのアプリ２停止）が割り当てられる。

業務Ｃの操作４１９は、依存先の操作４１５が終了した時点でもう一方の依存先の操作４１１が終了しているため、操作依存グラフ上では操作４１５の終了直後に割り当てが可能となっている。しかしながら、操作テーブル１２５のバッチ実行操作ｅｘｅｃ＿ｂａｔｃｈにおける操作条件２５３にて定義されているＳＥＲＶ．ｕｓｅｒ＿ｐｒｏｃｅｓｓ＜＝２より、ｐｓ１では既に仮想サーバｖｍ１及びアプリ２の計２プロセスが稼動状態のため、操作４１５終了直後の割り当てはできない。従って、操作４１８のアプリ２停止後に、操作４１９が割り当てられる。

＜運用管理対象機器上のログの例＞
図１９に、図１８で示したスケジューリング結果に基づきオペレーションを実施した際の、物理サーバｐｓ１上で取得されたログの例（４５０）である。図中、最左の数字は行番号を表している。ログは、日時、時間、機器名、サービス名、メッセージで構成される。たとえは、２行目は５月２日１０時１０分０２秒において、物理サーバｐｓ１上で実行されるカーネルサービスのメッセージとして、システムシャットダウンが開始されたことを示している。

＜オペレーション入力確認画面＞
次に、運用管理者によるオペレーションの入力、及びオペレーション検証結果の確認方法を、オペレーション端末１０３上での画面構成例を示して説明する。図２０はオペレーション入力画面５００の一例を示す図である。本画面を運用管理者毎、または運用管理業務毎に表示して、各操作を入力する。本例では、運用管理者別の画面として構成している。

運用管理者は、まず操作対象機器の選択５０１で機器の選択を行う。操作対象機器を選択すると、当該機器に対し実施可能な操作の一覧がオペレーションの選択５０２に表示される。従って、当該機器上で実施する操作を選択する。選択を行うと、操作に必要なパラメータ項目がパラメータ入力５０３に表示される。パラメータを選択すると、運用管理者に対し対応するパラメータを入力するよう促す画面が別途表示される。

また、操作対象機器の選択５０１で選択された機器の、現在の状態を取得し参照することもできる。状態情報５０４に表示された状態項目を選択し、状態確認ボタン５１７を押すことで、当該機器の当該状態が別画面で表示される。１操作の入力が完了した後、追加ボタン５１１を押すことで、オペレーションリストに登録が可能である。以上を繰り返すことにより、複数の操作群からなるオペレーションの入力を行う。なお、オペレーションリスト中の操作の修正・削除は、対象となる操作を選択した上でそれぞれ修正ボタン５１２、削除ボタン５１３を押すことで行う。

すべてのオペレーションの入力が終了後、連続実行ボタン５１４またはステップ実行ボタン５１５を押すことでオペレーション検証、最適化、及び実機上での実行を開始する。なお、連続実行５１４では、オペレーションリスト中の操作群に対し検証・最適化が行われた後、問題が無ければ一括して操作が発行され、実行状況を表す画面５２０が表示される。すべての操作の実行が終了後、結果を確認する画面が表示される。またステップ実行５１５では、当該操作群に対し検証・最適化が行われた後、問題が無ければ実行状況を表す画面５２０が表示され、１操作ずつ順に実行を指示する。さらに当該操作実行の都度、結果を確認する画面５３０が表示される。また、操作実行前のオペレーション検証段階でエラーが検出された場合は、オペレーションエラー通知画面５５０を表示する。

次に、図２１を用いて、オペレーションの状況を表示する画面５２０について説明する。運用管理者または運用管理業務別に発行したオペレーションに対し、オペレーション発行状況５２１と確認タイミング及び状態期待値５２２を示す。オペレーション発行状況５２１では、各操作の発行時刻と対象機器及び操作内容のリストが表示される。現在実行中の操作は、ハイライトされて示される。確認タイミングと状態期待値５２２では、各操作の結果を確認するための時刻と確認すべき状態、及びその期待値が表示される。例えば、リスト５２２最上段は確認時刻が１０：００：３０、対象機器は物理サーバｐｓ１、確認すべき状態項目はｐｏｗｅｒ、状態期待値はｏｆｆとなる。なお、実行途中でオペレーションを中止する場合は、中止ボタン５２６を押す。また、オペレーション入力画面５００にてステップ実行５１５を選択した場合は、各操作の発行終了毎に待ち状態となり、実行ボタン５２５が有効になる。オペレーション確認画面５３０で確認後、次の操作を実行する際は、当該実行ボタン５２５を押す。なお、オペレーション入力画面５００にて連続実行５１４を選択した場合は、実行ボタン５２５は有効にならない。

次に、図２２を用いて、オペレーション実行前にエラーが検出された時の確認画面５４０について説明する。オペレーションエラー表示画面５４０では、図２０に示す通りオペレーション検証段階にて検出されたエラーを表示する。エラーが発生した操作を示す画面５４１と、エラー内容を示す画面５４２で構成される。本例のエラー内容５４２では、物理サーバｐｓ１の電源ＯＦＦ操作に対して、ｐｓ１の電源状態がｏｎとなっていないことを示している。エラーを受けて、オペレーションを中止する場合には、確認（中止）ボタン５４５を押し、エラーを無視する場合は無視ボタン５４６を押す。

図２３に示す通り、ステップ実行時のオペレーション結果の確認画面５３０では、確認すべき操作を表示する画面５３１と、確認すべき状態情報を示す画面５３２が表示される。また、状態を確認する画面５３３も表示される。確認すべき状態情報に基づき、対象状態が画面５３３に表示され、状態確認ボタン５３５を押すと、当該状態が取得され別画面でその内容が表示される。別の状態、または別の機器の状態を確認したい場合は、「他の状態を取得する」を選択し、状態確認ボタン５３５を押すことで、別途状態を確認する画面が表示される。その結果、問題なければ確認ボタン５３６を押すことで、当該操作の実行確認が終了し、次の操作の実行へ移る。もし、期待状態と相違がある等問題があれば中止ボタン５３７を押すことで、オペレーションを中止できる。

次に、図２４により、状態確認ボタン５３５を押すと表示される画面について説明する。図２４は確認すべき状態が、実際の機器状態と一致している場合（つまりオペレーションエラーがない場合）の状態確認画面５６０を示す。期待状態を表す画面５６１と、取得した運用管理対象機器の状態を表す画面５６２、また当該取得状態の根拠となる、当該運用管理対象機器上で出力されたログの対応部分を表す画面５６３が表示される。本例は、物理サーバｐｓ１の電源が投入され、正常にブートされていることを示している。これにより、実行後の結果が正しいことを運用管理者が逐次確認できる。なお、確認ボタン５６４を押すことで、状態確認画面は終了する。

また、図２５は確認すべき状態が、実際の機器状態と一致していない場合（つまりオペレーションエラーがある場合）の状態確認画面５７０を示す。同じく期待状態を表す画面５６１と、取得した運用管理対象機器の状態を表す画面５６２、また当該取得状態の根拠となる、当該運用管理対象機器上で出力されたログの対応部分を表す画面５６３が表示される。本例では、物理サーバｐｓ１上でのバッチｂａｔｃｈ１の実行が最後まで正しく実行されず、期待状態と一致していないため、エラーが出力されている。これにより、実行結果に以上があることを運用管理者が逐次確認できる。なお、確認ボタン５７４を押すことで、状態確認画面は終了する。

図２６に示す通り、全オペレーション状況表示画面５５０では、複数の運用管理者によるオペレーションが入力されているときに、すべての操作とその実行状況を表示する。本画面は、運用管理者により、任意のタイミングで呼び出すことができる。操作はリストとして、実行時刻、発行者、対象機器、操作内容、実行状況の項目を表示する。本例では、ハイライトされている部分が、既に実行を終了している操作となる。これらの操作を実行途中で止めたい場合は、中止ボタン５５５を押す。

以上、本発明の一実施例のオペレーション検証システムを詳述したが、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したのであり、必ずしも説明の全ての構成を備えるものに限定されものではない。上述の実施例中にも説明したように、本システム中の運用制御部は、複数のサーバ装置で構成しても良いし、一個のサーバ装置で構成しても良いことは言うまでもない。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、それぞれの機能を実現するプログラムをＣＰＵが実行することによりソフトウェアで実現する例を主体に説明したが、各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク装置のみならず、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体におくことができるし、必要に応じてネットワーク等を介してダウンロード、インストロールすることも可能である。

１００・・・運用管理サーバ
１０１・・・オペレーション検証サーバ
１０２・・・運用モデル管理サーバ
１０３・・・オペレーション端末
１０４・・・空調機器
１０５・・・電源装置
１０６・・・監視装置
１０７・・・セキュリティ装置
１０８・・・サーバ装置
１０９・・・ディスク装置
１１０・・・ルータ
１１１〜１１２・・・ファイアウォール／ＶＰＮ装置
１１３・・・管理ネットワーク
１１４・・・場内ネットワーク
１１５・・・場外ネットワーク
１２０・・・機器種別テーブル
１２１・・・状態テーブル
１２２・・・状態ルールテーブル
１２３・・・機器定義テーブル
１２４・・・依存テーブル
１２５・・・操作テーブル
１２６・・・操作時刻予測テーブル
１２７・・・操作コマンド変換テーブル
１２８・・・状態記録テーブル
１２９・・・操作記録テーブ
４００・・・運用管理業務の例と対応する操作を示すテーブル
５００・・・オペレーション入力画面
５２０・・・オペレーション状況表示画面
５３０・・・ステップ実行時オペレーション確認画面
５４０・・・オペレーションエラー表示画面
５５０・・・全オペレーション状況表示画面
５６０・・・状態確認画面（期待状態と取得状態が一致）
５７０・・・状態確認画面（期待状態と取得状態が不一致）

Claims (15)

1. 複数の運用管理対象機器に対し操作を行う運用管理部を備える運用管理装置であって、
   前記運用管理部は、記憶部と処理部とを備え、
   前記記憶部は、前記操作により変化が伴う前記運用管理対象機器の状態と、前記操作毎の操作時間と、前記操作に必要な状態条件を記憶し、
   前記処理部は、複数の前記操作が入力されたとき、前記記憶部に記憶された、前記運用管理対象機器の前記状態と前記操作時間と前記状態条件に応じて入力された複数の前記操作の操作順を決定する、ことを特徴とする運用管理装置。
2. 請求項１に記載の運用管理装置であって、
   前記処理部は、複数の前記操作の操作順を決定する際に、前記状態条件を満たさない操作を検出することで、入力された前記操作に誤りがあることを検知する、ことを特徴とする運用管理装置。
3. 請求項１に記載の運用管理装置であって、
   前記処理部は、複数の前記操作各々の操作の終了時間を出力することにより、前記操作各々の操作を確認するタイミングを提示する、ことを特徴とする運用管理装置。
4. 請求項３に記載の運用管理装置であって、
   表示部を更に備え、
   前記表示部は、前記処理部からの複数の前記操作各々の終了時間に基づく確認タイミングと、当該確認タイミング時の状態期待値を表示する、ことを特徴とする運用管理装置。
5. 請求項１に記載の運用管理装置であって、
   前記処理部は、前記運用管理対象機器の稼動状況を監視し、前記運用管理対象機器の前記状態が変更されたことを検知した時点で、前記記憶部に記憶する前記状態を更新する、ことを特徴とする運用管理装置。
6. 請求項５に記載の運用管理装置であって、
   前記処理部は、前記運用管理対象機器に保持されたログの解析結果に基づき、前記状態が変更されたことを検知する、ことを特徴とする運用管理装置。
7. 請求項１に記載の運用管理装置であって、
   前記記憶部に記憶される前記運用管理対象機器の前記状態は、当該状態に対応する値の種類、或いは範囲を含む、ことを特徴とする運用管理装置。
8. 請求項７に記載の運用管理装置であって、
   前記記憶部に記憶される前記運用管理対象機器の前記状態は、当該状態の更新頻度を更に含み、
   前記処理部は、前記更新頻度に基づいて、前記状態条件の判定に必要な前記運用管理対象機器の前記状態を取得する、ことを特徴とする運用管理装置。
9. 請求項１に記載の運用管理装置であって、
   前記記憶部に記憶される前記状態条件は、当該状態条件の基準状態を含む、ことを特徴とする運用管理装置。
10. 請求項１に記載の運用管理装置であって、
    前記記憶部に記憶される前記操作時間は、時刻予想対象とする操作名と対応づけて記憶される、ことを特徴とする運用管理装置。
11. 複数の運用管理対象機器に対し操作を行う運用管理機器による運用管理方法であって、
    前記操作により変化が伴う前記運用管理対象機器の状態と、前記操作毎の処理時間と、前記操作に必要な状態条件を記憶し、
    複数の前記操作が入力されたとき、前記運用管理対象機器の前記状態と前記処理時間と前記状態条件に応じて、前記複数の操作の操作順を決定する、ことを特徴とする運用管理方法。
12. 請求項１１に記載の運用管理方法であって、
    前記操作順を決定する際に、前記状態条件を満たさない操作を検出することで、前記操作に誤りがあることを検知する、ことを特徴とする運用管理方法。
13. 請求項１１に記載の運用管理方法であって、
    前記複数の操作における個々の操作の終了時間を出力することで、前記個々の操作を確認するタイミングを提示する、ことを特徴とする運用管理方法。
14. 請求項１１に記載の運用管理方法であって、
    前記状態条件の判定に必要な前記運用管理対象機器の前記状態を取得するために、前記運用管理機器が記憶する状態更新頻度に基づいて、前記運用管理対象機器の稼動状況から、前記運用管理対象機器の前記状態を更新する、ことを特徴とする運用管理方法。
15. 請求項１１に記載の運用管理方法であって、
    前記状態条件の判定に必要な前記運用管理対象機器の前記状態を取得するために、前記運用管理対象機器の稼動状況を監視し、前記運用管理対象機器の前記状態に対応する前記稼動状況が変更されたことを検知した時点で、前記運用管理対象機器の前記状態を更新する、ことを特徴とする運用管理方法。

Images