JP2017102870A - システム運用自動化装置、システム運用自動化プログラム及びシステム運用自動化方法 - Google Patents

Abstract

【課題】複数の管理対象装置に対する申請の適用や障害対応を、人為的ミスや運用ノウハウの属人化を排除して迅速かつ確実に反映させ、実行された新たな反映情報をリアルタイムに共有可能とする。【解決手段】複数の管理対象装置３０の識別情報と、各管理対象装置で運用される運用情報、各管理対象装置で運用可能な申請情報、各管理対象装置で発生する可能性のある障害に関する障害対応情報を、端末装置２０の表示部に選択可能に表示させ、入力操作に応じて申請情報が選択されると、当該申請を対応する管理対象装置に反映させるとともに、管理対象装置において障害が発生すると、対応する障害対応情報に係る障害対応を、当該管理対象装置に反映させ、申請実行手段で反映された申請及び障害対応実行手段で反映された障害対応に係る情報を、対応する管理対象装置の情報として更新して記憶・表示させる統合プロセス管理装置１０を備える。【選択図】図１

Description

本発明は、企業や官公庁，公共団体などの業務運営に必要となるデータシステムを正確かつ効率的に運用するためのシステム運用自動化装置に関し、特に、大企業や複数の企業・団体等の大量のデータを取り扱うシステム運用に好適なシステム運用自動化装置、システム運用自動化プログラム及びシステム運用自動化方法に関する。

一般に、企業や官公庁，公共団体などの多くの組織・団体では、業務の運営に必要となる膨大な情報を電子データとして保有しており、その電子データを業務の運営に使用するためのデータシステム（業務システム）が運用されている。
このようなデータシステムは、個々の企業等が自己で所有するコンピュータシステムによって運営・運用される場合もあり、また、複数の企業等のデータシステムの運用を業務として請け負う、所謂システム・インテグレータと呼ばれる情報システム企業が所有する巨大なサーバシステム群によって管理・運用される場合もある。

いずれの場合であっても、データシステムを運用する場合には、管理対象となる装置で保持・運用されている膨大なデータを、漏洩や消失等させることなく、正確かつ安全に管理対象装置を稼動させることが最も重要となる。
また、データシステムで管理・運用されるデータは時々刻々と変化・更新されるものであり、それに応じて管理対象装置のシステム構成や機能等の変更や追加，拡張，バージョンアップ，メンテナンス等、必要な変更・改善を随時行う必要があり、そのような変更等は、正当性のある内容を正確かつ可能な限り迅速に反映・実行させる必要がある。
さらに、データシステムの運用には不測の障害やトラブル等の発生を絶無にすることは困難であり、障害等が発生した場合には、迅速かつ的確な対応・復旧が求められる。

このような背景から、従来のデータシステムの運用に際しては、一般に以下のような対応が取られていた。
まず、データシステムを運用している管理対象装置に対して、新たな構成や機能等を追加・変更等する場合には、図１１（ａ）に示すように、データシステムの開発担当者が、管理対象装置に追加・変更等したい構成や機能について、紙の運用申請書を起票して申請を行い、開発部署内で開発管理者からの承認を得た後、その申請が運用部署に回付され、運用部署において運用担当者・運用管理者による申請の受付や申請内容の正当性のチェック・承認が行われる。その上で、運用部署で承認された申請内容を、管理対象装置に実装されている本番システムへ反映させるために、オペレーション担当者（オペレータ）の手作業による本番システムの変更作業が行われ、作業結果が運用担当者に連絡される。
その後、運用担当者は、本番システムに実行・反映された作業結果を開発担当者に連絡し、開発担当者は自己が申請した申請内容が本番システムに反映されていることを確認できるようになる。

また、運用中のデータシステムにおいて障害が発生した場合には、図１１（ｂ）に示すように、管理対象装置で運用中のデータシステムでのアラートが監視システムによって検知されると、運用部署においてアラートの内容が確認され、予め定められた運用ルールに則ってオペレーション担当者への対応依頼や開発担当者への連絡が行われる。
開発部署では、運用部署から連絡されたアラートの内容が開発担当者によって確認され、過去の経験・ノウハウ等に基づく調査が行われ、障害への対応内容が運用担当者へ指示される。
また、オペレーション担当者側では、障害の調査のための本願システムへの必要な作業が実施され、その結果が運用担当者に連絡されるとともに、必要に応じて開発担当者からの指示に則って本番システムへの変更の反映等の作業が実施される。

このように、データシステムの運用の現場では、開発担当者・開発承認者・運用担当者・運用管理者・オペレーション担当者と、複数の部署と担当者・管理者を経ることで、適切・正当な申請がチェック・承認され、不用意・不適切なシステム変更等が行われないようになっている。
また、複数の部署・担当者による役割分担や責任分界点が明確に定められることで、データシステムの心臓部となる本番システムには、オペレーション担当者のみがアクセス可能となり、開発担当者等が勝手に本番システムに触れるようなことは困難乃至不可能となり、例えば本番システムの内容が開発担当者の一存で変更されるようなことが防止されることになる。

ここで、以上のようなデータシステムの運用における作業性の向上を目的として、特許文献１には、管理対象装置に対して行うメンテナンス作業の申請について、申請を行う開発担当者とそれを承認する開発承認者の間をオンラインで結び、申請・承認作業をオンライン上で実行し、承認を受けたメンテナンス作業を自動で実行する「メンテナンス作業支援装置」が提案されている。
この特許文献１の技術では、上述した開発担当者と開発承認者との間で行われる申請・承認の作業がオンライン化されるとともに、申請が承認されると、承認されたメンテナンス作業が自動実行されるようになる。このため、運用担当者・運用管理者による申請内容の確認や承認、オペレーション担当者による本番システムに対する作業が不要となり、全体として管理対象装置に対するメンテナンス作業が効率化されるようになる。

特開２０１４−０４８８６０号公報

しかしながら、上述したような従来のデータシステムの運用には、以下のような問題があった。
まず、管理対象装置のシステム変更等の申請の対応に際して、開発部署・運用部署・オペレーション担当者のように、複数の部署と担当者を経る必要がある従来の運用では、変更等の申請が行われてから最終的に本番システムへの反映が完了するまでに時間がかかるという問題があった。

具体的には、開発担当者からの申請に対して、まず開発部署で一又は二以上の開発管理者による承認が必要となる上、開発部署で承認された申請について、さらに運用部署において内容の正当性チェックや承認が行われることになる。運用部署では、管理対象装置となる運用管理サーバ名や管理対象機器名が正確か、サーバ間の親子関係の記述が適切か等を運用担当者がチェックする必要があり、時間もかかり、記載不備を見落とすなど手戻りのリスクなどもあった。その上で、運用部署のチェック・承認を経た後に、オペレーション担当者による本番システムへの実装作業が行われることなり、開発担当者が申請を行ってから最終的に申請内容が本番システムに反映されるまでに長い時間がかかる場合が少なくなかった。

また、申請した内容が本番システムに正しく反映されたか否かについても、開発担当者は直接に本番システムにアクセスできないことから、専用のコンソール等を介して本番システムのサーバ情報やログ情報を参照しなければならず、申請内容が反映されていることの確認にも時間がかかるという問題があった。
これらの点は、複数の部署と担当者・管理者を経る必要のある従来システムにおける構造的・物理的な問題であり、特許文献１で提案されているような支援装置を導入したとしても、根本的に解決することはできなかった。
また、このような運用工程の遅延は、特に迅速な対応が求められるシステム提供業者等のサービスの拡大・変更に対して、サービスレベルの低下に直結するリスクに繋がるおそれがあった。

また、申請内容や作業結果の確認や承認は人為的チェックによって行われることから、人為的ミスが発生することは回避できず、また、本番システムに対してオペレーション担当者が手作業で変更を加えることについても、人為的ミスの発生を完全になくすことは困難であった。
また、システム運用のノウハウは属人化しやすく、人の入れ替わりが激しい運用現場においては、常に標準的なシステム運用レベルを維持することが困難となるという問題もあった。

特に、大企業や複数の企業等の大量のデータを取り扱うデータシステムにおいては、数百台〜数千台，数万台に上るサーバ装置等の管理対象装置が備えられ、それらを数人の運用担当者やオペレータで管理・担当する場合もあり、膨大な数のシステム群の中から対象となるシステムや装置・機器を正しく抽出・判断することは困難な場合も少なくなく、対象装置の選択ミス等が発生することは必然的・構造的な問題ともいえるものであった。
そして、このような問題は、特許文献１の支援装置を採用して一部の作業がオンライン化・自動化されたとしても、人為的ミスの発生を完全になくすことは不可能であった。

さらに、システムの障害発生時においても、上記と同様の問題が発生することとなった。
システム障害発生時には、より迅速な対応が求められるが、近年対応すべき情報システムの規模は膨大になっており、システム運用を人為的な判断に頼って実施することは、対応箇所の特定や対応操作において判断ミスや操作ミスが起こりやすいという問題があった。
特に、緊急な対応が求められる障害発生の場面では、本番システムに手作業で変更を加えることによるオペレーション担当者によるミスが起こりやすかった。

また、障害発生の場合、障害内容の確認や調査指示から本番システムでの調査実施までに時間がかかる上に、開発部署・運用部署間での確認・指示等のやり取りの回数も多くなることから、結果的に対応が後手々々になりやすいという問題もあった。
また、障害対応には人手を介する工程が多いことによる連携ミスや、誤認識が発生しやすいという問題もあった。
一方、障害の内容によっては、頻繁に発生する軽微な問題であって、実際にはオペレーション担当者のみの対応で解消可能な場合でも、その都度、運用部署・開発部署側に対応内容を確認する必要があることから、その点からも手間と時間がかかるという問題があった。

さらには、障害対応については、開発担当者側の経験やノウハウが属人化している場合もあり、例えば経験の浅い新入社員等、応答した担当者によっては、適切な対応指示を出すことができないことや、判断に時間がかかる等の問題もあった。
そして、このような障害発生時の対応において生ずる問題については、特許文献１の支援装置では全く対応することはできなかった。特許文献１の支援装置は、管理対象装置に対するメンテナンス処理の申請承認と反映作業を効率化させるために、管理装置から管理対象装置への上流から下流への一方的な命令（設定）はできても、管理対象装置で障害が発生した場合に、その通知を受けた管理装置側から管理対象装置に対して何らかの対応を自動で行うようなことはできなかった。

本発明は、以上のような従来の技術が有する課題を解決するために提案されたものであり、複数の管理対象装置に対する新たな申請の適用や障害対応を、人の介在とそれに伴う人為的ミスや運用ノウハウの属人化等を可能な限り排除して、誤りなく迅速かつ確実に実行・反映させることができるとともに、実行された新たな反映情報をリアルタイムに出力・表示して共有することができる、特に大企業や複数の企業・団体等の大量のデータを取り扱うサーバ等の管理対象装置を多数備えた大規模データシステムの運用に好適な、システム運用自動化装置、システム運用自動化プログラム及びシステム運用自動化方法の提供を目的とする。

上記目的を達成するため、本発明のシステム運用自動化装置は、データシステムを運用する複数の管理対象装置に接続された情報処理装置であって、前記複数の管理対象装置の識別情報と、各管理対象装置で運用されるデータシステムの運用情報、各管理対象装置で運用可能な申請に関する申請情報、各管理対象装置で発生する可能性のある障害に関する障害対応情報を記憶する記憶手段と、前記複数の管理対象装置の識別情報，運用情報，申請情報及び障害対応情報を、所定の表示部に選択可能に表示させる表示制御手段と、入力操作に応じて前記申請情報が選択されると、当該申請情報に係る申請を、対応する管理対象装置に反映させる申請実行手段と、前記管理対象装置において障害が発生すると、対応する前記障害対応情報に係る障害対応を、当該管理対象装置に反映させる障害対応実行手段と、を備え、前記記憶手段は、前記申請実行手段で反映された申請及び前記障害対応実行手段で反映された障害対応に係る情報を、対応する管理対象装置の情報として更新して記憶し、前記表示制御手段は、前記記憶手段で更新された情報を表示させる構成としてある。

また、本発明のシステム運用自動化プログラムは、データシステムを運用する複数の管理対象装置に接続された情報処理装置を構成するコンピュータを、前記複数の管理対象装置の識別情報と、各管理対象装置で運用されるデータシステムの運用情報、各管理対象装置で運用可能な申請に関する申請情報、各管理対象装置で発生する可能性のある障害に関する障害対応情報を記憶する記憶手段、前記複数の管理対象装置の識別情報，運用情報，申請情報及び障害対応情報を、所定の表示部に選択可能に表示させる表示制御手段、入力操作に応じて前記申請情報が選択されると、当該申請情報に係る申請を、対応する管理対象装置に反映させる申請実行手段、前記管理対象装置において障害が発生すると、対応する前記障害対応情報に係る障害対応を、当該管理対象装置に反映させる障害対応実行手段、として機能させるとともに、前記記憶手段に、前記申請実行手段で反映された申請及び前記障害対応実行手段で反映された障害対応に係る情報を、対応する管理対象装置の情報として更新して記憶させ、前記表示制御手段に、前記記憶手段で更新された情報を表示させる構成としてある。

さらに、本発明は、上記のような本発明に係るシステム運用自動化装置及びシステム運用自動化プログラムによって実施可能なシステム運用自動化方法として構成することもできる。

本発明によれば、複数の管理対象装置に対する新たな申請の適用や障害対応を、人の介在とそれに伴う人為的ミスや運用ノウハウの属人化等を可能な限りなくして、誤りなく迅速かつ確実に実行・反映させることができ、実行された新たな反映情報をリアルタイムに表示して共有することができる。
これによって、特に大企業や複数の企業・団体等の大量のデータを取り扱うサーバ等の管理対象装置を多数備えた大規模データシステムの運用に好適なシステム運用自動化装置、システム運用自動化プログラム及びシステム運用自動化方法を提供することができる。

本発明の一実施形態に係るシステム運用自動化装置を備えたシステム構成を模式的に示す説明図である。 本発明の一実施形態に係るシステム運用自動化装置におけるシステム運用の申請時／障害発生時の対応の流れを模式的に示す説明図である。 本発明の一実施形態に係るシステム運用自動化装置に備えられるデータベースのイメージを示す説明図であり、（ａ）は申請情報テーブル、（ｂ）は承認ワークフロー管理テーブル、（ｃ）はユーザマスタテーブルの一例である。 図３とともに本発明の一実施形態に係るシステム運用自動化装置に備えられるデータベースのイメージを示す説明図であり、（ａ）は申請メニュー管理テーブル、（ｂ）は申請内容チェックルール管理テーブルの一例である。 図３，４とともに本発明の一実施形態に係るシステム運用自動化装置に備えられるデータベースのイメージを示す説明図であり、（ａ）はシステム構成管理テーブル、（ｂ）はジョブ制御情報管理テーブル、（ｃ）は自動対応（ＲＢＡ）マスタ管理テーブルの一例である。 本発明の一実施形態に係るシステム運用自動化装置で表示・閲覧されるポータル画面のインタフェースのイメージを示す説明図で、問合せ・申請メニュー画面の一例である。 図６から引き続いて本発明の一実施形態に係るシステム運用自動化装置で表示・閲覧されるポータル画面のインタフェースのイメージを示す説明図で、（ａ）は選択された申請内容の詳細画面、（ｂ）は対象となる機器やジョブ等の検索画面、（ｃ）は申請が運用システム上で処理・反映された結果の確認画面の一例である。 本発明の一実施形態に係るシステム運用自動化装置を備えたシステムにおける申請時の動作の一例を示すフローチャートである。 図８から引き続いて本発明の一実施形態に係るシステム運用自動化装置を備えたシステムにおける申請時の動作の一例を示すフローチャートである。 本発明の一実施形態に係るシステム運用自動化装置を備えたシステムにおける障害発生時の動作の一例を示すフローチャートである。 従来技術におけるシステム運用の申請時／障害発生時の対応の流れを模式的に示す説明図であり、（ａ）は申請時、（ｂ）障害発生時の場合である。

以下、本発明に係るシステム運用自動化装置の実施形態について、図面を参照しつつ説明する。
ここで、以下に示す本発明のシステム運用自動化装置は、プログラム（ソフトウェア）の命令によりコンピュータで実行される処理，手段，機能によって実現される。プログラムは、コンピュータの各構成要素に指令を送り、以下に示す本発明に係る所定の処理や機能等を行わせることができる。すなわち、本発明における各処理や手段，機能は、プログラムとコンピュータとが協働した具体的手段によって実現される。
なお、プログラムの全部又は一部は、例えば、磁気ディスク，光ディスク，半導体メモリ，その他任意のコンピュータで読取り可能な記録媒体により提供され、記録媒体から読み出されたプログラムがコンピュータにインストールされて実行される。また、プログラムは、記録媒体を介さず、通信回線を通じて直接にコンピュータにロードし実行することもできる。また、本発明に係るシステム運用自動化装置は、単一の情報処理装置（例えば１台のパーソナルコンピュータ等）で構成することもでき、複数の情報処理装置（例えば複数台のサーバコンピュータ群等）で構成することもできる。

図１は、本発明の一実施形態に係るシステム運用自動化装置を備えたシステム構成を模式的に示す説明図である。
また、図２は、本発明の一実施形態に係るシステム運用自動化装置におけるシステム運用の申請時／障害発生時の対応の流れを模式的に示す説明図である。
これらの図に示すように、本発明の一実施形態に係るシステム運用自動化装置は、統合プロセス管理装置１０として構成されている。

［システム構成］
統合プロセス管理装置１０は、例えばサーバコンピュータやパーソナルコンピュータ等の情報処理装置によって構成されており、まず、開発担当者・開発管理者・運用担当者・運用管理者がそれぞれ操作可能な複数の端末装置２０と通信可能に接続されている。
また、統合プロセス管理装置１０は、管理・運営の対象となるデータシステムが実装・運用されている管理対象装置３０と通信可能に接続されている。
これら統合プロセス管理装置１０と閲覧用端末装置２０，管理対象装置３０とは、例えばインターネットや社内ＬＡＮなどのネットワークを介してデータ通信可能に接続されている。

［端末装置］
端末装置２０（２０ａ，２０ｂ〜２０ｎ）は、開発担当者・開発管理者・運用担当者・運用管理者等がそれぞれ操作可能な情報処理装置からなり、例えばパーソナルコンピュータや携帯電話，スマートフォン，タブレット等によって構成することができる。
この端末装置２０において、統合プロセス管理装置１０で生成・出力される出力情報、具体的には後述するポータル・インタフェース（図６，７参照）を表示・閲覧・入力等の操作を行うことができる。
また、端末装置２０は、統合プロセス管理装置１０から所定の承認依頼通知や障害発生通知が送信される受信側装置となっており、本発明に係る承認者装置，障害対応者装置を構成する。

具体的には、各端末装置２０が統合プロセス管理装置１０にアクセス・ログインすることにより、端末装置２０が備える表示部（液晶ディスプレイ等）に、統合プロセス管理装置１０が提供するポータル・インタフェースが表示されるようになっている。
そして、各端末装置２０が操作されることで、統合プロセス管理装置１０が提供するポータル・インタフェースから所定のデータ入力が可能となっており、例えば、開発担当者による申請や障害対応の内容の設定、開発担当者による障害対応設定の承認、運用管理者による申請の承認などを入力・設定することができる。
また、各端末装置２０を介して統合プロセス管理装置１０のポータル・インタフェースが表示・閲覧されることで、例えば、開発担当者が行った申請や、障害発生に対して自動実行された対応内容を参照・確認することができるようになっている。

ここで、複数の端末装置２０は、上述した従来のデータシステムの運用に携わる複数の担当者や管理者、例えば開発担当者・開発管理者・運用担当者・運用管理者等が個々に操作する複数の情報処理装置によって構成され、各担当者や管理者に割り当てられたログイン用のＩＤやパスワードを入力することで、統合プロセス管理装置１０のポータル・インタフェースを表示・閲覧できるようになっている。
なお、端末装置２０は、データシステムの運用に携わる担当者・管理者ごとに備えられる複数の情報処理装置によって構成することが好ましいが、例えば複数の担当者で共用する情報処理装置によって構成することもできる。したがって、本実施形態に係る端末装置２０は、少なくとも一台が備えられていれば本発明を実施することができる。

［管理対象装置］
管理対象装置３０は、本発明に係るシステム運用自動化装置の管理対象となるデータシステムが実装・運用される情報処理装置からなり、例えば、自社のデータシステムを運用する企業等が所有するコンピュータシステムや、複数の企業等のデータシステムの運用を業務として請け負う情報システム企業（システム・インテグレータ）が所有する大規模なサーバシステム群等によって構成することができる。
図１に示す例では、管理対象装置３０は、統合プロセス管理装置１０とネットワークを介して接続された複数の運用管理サーバ３０ａ〜３０ｎと、各運用管理サーバ３０ａ〜３０ｎと接続される複数の管理対象機器３０−１ａ〜ｎ，３０−２ａ〜ｎ・・・３０−Ｎａ〜ｎによって構成されている。

現実の管理対象装置３０としては、数台のコンピュータで構成される場合から、数百台〜数千台，数万台のサーバシステム群からなる情報処理装置によって構成される場合もあり、いずれの場合にも、企業等の業務・運営に必要とされるアプリケーション・システムや基盤システムなどのデータシステムが業務システムとして実装・運用されるものである。
そして、このような複数の情報処理装置からなる管理対象装置３０で運用されるデータシステム（業務システム）が、本発明に係るシステム運用自動化装置によって、効率的に運用されるように管理・制御されるようになっている。

具体的には、管理対象装置３０に対しては、開発担当者の端末装置２０から統合プロセス管理装置１０に対して新たな申請が入力・選択されると、その申請内容が統合プロセス管理装置１０によって実行され、対象となる管理対象装置３０に対してその申請内容が自動で反映されるようになる。
また、管理対象装置３０のいずれかのいずれかの管理対象機器３０−１ａ〜ｎ，３０−２ａ〜ｎ・・・３０−Ｎａ〜ｎに障害が発生すると、その管理対象機器からアラートが出されて、その機器を管理する運用管理サーバ３０ａ〜３０ｎを介して、アラートが統合プロセス管理装置１０に送信・通知され、それに対応する障害対応の内容が抽出され、障害が発生した管理対象機器に対して必要な障害対応処理が自動で実施・実行されるようになる。

統合プロセス管理装置１０には、管理対象装置３０に実装可能な申請内容のデータや、想定される障害発生に対する対応内容のデータが設定・記憶されるようになっており、端末装置２０からの選択操作や管理対象装置３０から通知されるアラートに応じて、該当する申請や障害対応の内容が抽出され、対応する管理対象機器に対して必要な申請内容や障害対応の処理が実行・反映されることになる。
例えば、新たな申請や障害対応の処理内容を記述したスクリプトが統合プロセス管理装置１０に記憶・設定されており、端末装置２０からの申請の選択操作や、管理対象装置３０から上げられたアラートに応じて、そのスクリプトが実行されて、対応する管理対象装置３０のいずれかの管理対象機器３０−１ａ〜ｎ，３０−２ａ〜ｎ・・・３０−Ｎａ〜ｎにその内容が実行・反映されるようになる。

これによって、申請対象となる機器や障害が発生した機器に対して、必要な対応処理が統合プロセス管理装置１０によって自動実行されるようになる。これによって、従来はオペレーション担当者（図１１参照）が行っていた本番システムへの手作業による入力・設定等が不要となり、その結果、図２に示すように、オペレーション担当者自体を不要乃至大幅に削減できるようになる。
そして、以上のように統合プロセス管理装置１０によって管理対象装置３０に対して自動実行された申請や障害対応の内容が、統合プロセス管理装置１０のポータル・インタフェースに出力・表示され、本システムに接続されている各担当者・管理者の端末装置２０において参照・確認することができる。

［統合プロセス管理装置］
統合プロセス管理装置１０は、本発明に係るシステム運用自動化装置を構成する装置であり、例えばパーソナルコンピュータやサーバシステム等の一又は二以上の情報処理装置によって構成されている。
そして、上述のとおり、統合プロセス管理装置１０は、ネットワークを介して、開発担当者等が操作する一又は二以上の端末装置２０、管理・運営の対象となるデータシステムが実装・運用されている管理対象装置３０と通信可能に接続されている。
このような統合プロセス管理装置１０を備えることにより、統合プロセス管理装置１０に接続され管理されている複数の管理対象装置３０（運用管理サーバ・管理対象機器）に関する情報が、ポータル・インタフェースの形式で生成・出力・更新されて、任意の端末装置２０の表示部において表示・閲覧・入力操作が可能となる。

これによって、各端末装置２０において、管理対象装置３０に関する情報がリアルタイムに共有して参照・確認することができるとともに、各管理対象装置３０に対して必要となる申請や障害対応も、各端末装置２０からポータル・インタフェースに対して入力・設定するだけで、対象となる管理対象装置３０に対して自動的に実行・反映させることができ、その反映結果もポータル・インタフェースを通じて、各端末装置２０で随時確認することができるようになる。

具体的には、本実施形態に係る統合プロセス管理装置１０は、図１に示すように、記憶手段１１，表示制御手段１２，申請実行手段１３，障害対応実行手段１４の各手段として機能するように構成・制御される。
記憶手段１１は、複数の管理対象装置３０の識別情報と、各管理対象装置３０で運用されるデータシステムの運用情報、各管理対象装置３０で運用可能な申請に関する申請情報、各管理対象装置３０で発生する可能性のある障害に関する障害対応情報を記憶・更新する手段であり、本発明に係る記憶手段を構成している。
そして、この記憶手段１１は、後述する申請実行手段で反映された申請及び障害対応実行手段で反映された障害対応に係る情報を、対応する管理対象装置３０の情報として更新して記憶するようになっている。
この記憶手段１１に記憶されるデータで構成されるデータベースの詳細については、図３〜５を参照しつつ後述する。

表示制御手段１２は、複数の管理対象装置３０を構成する運用管理サーバ３０ａ〜３０ｎや管理対象機器３０−１ａ〜３０−Ｎｎの識別情報や、実装されるシステムの運用情報，システムに適用可能な申請情報及び障害対応情報を、端末装置２０に備えられる液晶ディスプレイ等の所定の表示部に選択可能に表示させる手段であり、本発明に係る表示制御手段を構成している。
そして、この表示制御手段１２は、上述した記憶手段１１で更新された情報を端末装置２０側において表示させるようになっている。この表示制御手段１２の制御により生成・出力される表示内容は、対象となる管理対象装置３０に関する情報を選択可能に表示させるポータル・インタフェースとして表示されるようなっている。
この表示制御手段１２によって生成・表示されるポータル・インタフェースの詳細については、図６，７を参照しつつ後述する。

申請実行手段１３は、入力操作に応じて申請情報が選択されると、当該申請情報に係る申請を、対応する管理対象装置に反映させる手段であり、本発明に係る申請実行手段を構成している。
また、申請実行手段１３は、入力操作に応じて申請情報が選択されると、当該申請情報に対応する承認者が操作する端末装置２０（承認者装置）に、所定の承認依頼通知を電子メール等で送信・通知するようになっている。

障害対応実行手段１４は、管理対象装置３０において障害が発生すると、対応する障害対応情報に係る障害対応を、当該管理対象装置に反映させる手段であり、本発明に係る障害対応実行手段を構成している。
また、障害対応実行手段１４は、管理対象装置３０において障害が発生すると、当該管理対象装置３０に対応する障害対応者が操作する端末装置２０（障害対応者装置）に、所定の障害発生通知を電子メール等で送信する。
さらに、障害対応実行手段１４は、入力操作に応じて新たな障害対応情報が設定されると、当該障害対応情報に対応する承認者が操作する端末装置２０（承認者装置）に、所定の承認依頼認通知を電子メール等で送信するようになっている。
これら申請実行手段１３及び障害対応実行手段１４で自動実行される申請及び障害対応の詳細については、図８〜１０を参照しつつ後述する。

［データベース］
次に、上述した統合プロセス管理装置１０の記憶手段１１に記憶されるデータで構成されるデータベースのイメージについて図３〜５を参照しつつ説明する。
図３〜５は、本発明の一実施形態に係るシステム運用自動化装置に備えられるデータベースのイメージを示す説明図であり、図３（ａ）は申請情報テーブル、図３（ｂ）は承認ワークフロー管理テーブル、図３（ｃ）はユーザマスタテーブルの一例である。
また、図４（ａ）は申請メニュー管理テーブル、（ｂ）は申請内容チェックルール管理テーブルの一例である。
また、図５（ａ）はシステム構成管理テーブル、図５（ｂ）はジョブ制御情報管理テーブル、図５（ｃ）は自動対応（ＲＢＡ）マスタ管理テーブルの一例である。

［申請情報テーブル］
図３（ａ）に示すように、申請情報テーブルは、管理対象装置３０に対して適用・反映することができる申請種類ごとに複数のデータで構成されている。
具体的には、申請情報テーブルは、運用申請のチケット(トランザクション情報)を管理するテーブルであり、申請チケットＩＤ・申請種類・対象システム・対象ジョブ・運用日付・対象サーバ・対象ＲＢＡ（ＲｕｎＢｏｏｋＡｕｔｏｍａｔｉｏｎ：運用自動化）・対象チェックパターン等の情報が記憶されるようになっている。

図３（ａ）の上段の例では、管理対象装置３０に適用可能な申請として「ジョブｓｋｉｐ申請」について、申請チケットＩＤ・申請種類・対象システム・対象ジョブ・運用日付等の情報が関連付けて記憶されている。
図３（ａ）の中段の例では、管理対象装置３０に適用可能な申請として「ＲＢＡ（障害自動対応設定）申請」について、申請チケットＩＤ・申請種類・対象システム・対象サーバ・対象ＲＢＡ等の情報が関連付けて記憶されている。
図３（ａ）の下段の例では、管理対象装置３０の障害が発生した場合の対応として「障害メッセージ１次切り分け」について、申請チケットＩＤ・申請種類・対象システム・対象サーバ・対象チェックパターン等の情報が関連付けて記憶されている。

このような申請情報テーブルが構成されることで、管理対象装置３０に対する適用可能な申請と障害発生時の対応が管理され、システムに従って関係者の権限を判定することができるとともに、申請された情報について管理することができる。
また、この申請情報テーブルが、後述する「ジョブ制御情報管理テーブル」と紐付けられることで、申請だけでなく、申請内容を本番システムへ反映した実行結果も、ポータル・インタフェース上で確認することができるようになる。

［承認ワークフロー管理テーブル］
図３（ｂ）に示すように、承認ワークフロー管理テーブルは、業務システム、申請の種類ごとに適用される承認ワークフローを定義するテーブルであり、申請者、承認者をユーザの役職ごとに設定することができる。
図３（ｂ）の例では、対象システム「金融Ａシステム」についての承認ワークフローとして、承認ワークフローＩＤ・対象システム・開発承認役職・運用承認役職等の情報が関連付けて記憶されている。

［ユーザマスタテーブル］
図３（ｃ）に示すように、ユーザマスタテーブルは、ユーザごとの担当業務システム・役職、連絡先情報を定義するテーブルである。
図３（ｃ）の例では、ユーザ「ＸＸＸＸＸ」について、ユーザＩＤ・氏名・権限・役職・メールアドレス等の情報が関連付けて記憶されている。

［申請メニュー管理テーブル］
図４（ａ）に示すように、申請メニュー管理テーブルは、業務システム、役職ごとに申請することが可能なメニューを定義するテーブルである。
図４（ａ）の例では、業務システム「金融Ａシステム」の担当役職「開発部門担当者」について、「ジョブｓｋｉｐ申請：○」・「監視申請：○」・「障害自動対応：×」等の情報が関連付けて記憶されている。
この申請メニュー管理テーブルでは、ユーザごとに申請、承認等、実施可能なアクションが定義され、ユーザマスタの権限及び機器構成テーブルのシステム設定と、申請メニュー管理テーブルとの情報に基づいて、統合プロセス管理装置１０のポータル・インタフェースには、各ユーザ単位で、そのユーザが利用可能な申請のみをメニュー表示することができるようになる。

［申請内容チェックルール管理テーブル］
図４（ｂ）に示すように、申請内容チェックルール管理テーブルは、申請項目ごとのチェック内容を定義するテーブルである。
図４（ｂ）の例では、対象システム「金融Ａシステム」について、対象項目「対象サーバ名」については、チェック内容として「半角英数字８バイド」が設定され、対象項目「運用日時」については、チェック内容として「申請日時の３０分後以降」が設定されている。
この申請内容チェックルール管理テーブルに定義されたチェック内容に基づいて、申請内容に不備がないかが統合プロセス管理装置１０で自動的にチェックされるようになる。
これによって、新たな申請を行おうとする申請者（開発担当者）は、申請に不備等があれば申請の際に即時に申請不備があることが分かり、手戻りなく迅速かつ正確な申請が行えるようになり、申請をチェック・承認する運用部門側でも、申請内容のチェック等に時間が取られることがなく、迅速な申請の承認処理を行えるようになる。

［システム構成管理テーブル］
図５（ａ）に示すように、システム構成管理テーブルは、最新の機器構成情報を管理するテーブルである。
図５（ａ）の例では、対象となるシステム「金融Ａシステム」について、システム名・運用管理サーバ・制御対象サーバ・ジョブ情報等の情報が関連付けて記憶されている。
このようなシステム構成管理テーブルを備えることで、システムの構成情報がシステム別に定義されるため、ユーザの役職・権限に応じて、申請可能な機器情報のみを申請対象の選択肢として表示させることができる。
これによって、申請者は、ポータル・インタフェース上に表示される、許可されたリストから申請の実施対象を選ぶだけでよいので、手動入力による記載ミスや、運用分門側での申請者の権限チェックなどの手間を省くことができるようになる。

［ジョブ制御情報管理テーブル］
図５（ｂ）に示すように、ジョブ制御情報管理テーブルは、申請された運用制御情報と実施結果の情報を管理するテーブルである。
図５（ｂ）の例では、対象システム「金融Ａシステム」について、システム名・対象ジョブ・ジョブ指示内容・運用日付・実施ステータス・実施ログ等の情報が関連付けて記憶されている。
このようなジョブ制御情報管理テーブルで情報が管理されることで、申請を行った開発担当者は、端末装置２０から統合プロセス管理装置１０にアクセスすることで、ポータル・インタフェース上で、自身が行った申請の実施結果等をリアルタイムに確認・参照することができるようになる。

［自動対応（ＲＢＡ）マスタ管理テーブル］
図５（ｃ）に示すように、自動対応（ＲＢＡ）マスタ管理テーブルは、管理対象装置３０について障害が発生した場合の自動対象処理の起動条件や対応内容を定義するテーブルである。
図５（ｃ）の例では、対象システム「金融Ａシステム」について、ＲＢＡ−ＩＤ・起動条件・自動実施内容等の情報が関連付けて記憶されている。
この自動対応マスタ管理テーブルの情報に基づいて、管理対象装置３０のいずれかに障害が発生した場合には、統合プロセス管理装置１０が、発生した対象の機器・サーバや発生した事象を検知して、自動実施内容に基づいて対処・実行する処理を自動で判断して実行する。なお、この自動対応マスタ管理テーブルに設定される条件や実施内容は、予め開発部門から行われた申請に基づいて、所定の内容・情報が登録される。
これによって、障害発生時の初期動作が自動化され、システム障害への対応が大幅に短縮されることになる。

また、このような自動対応マスタ管理テーブルを備えることで、統合プロセス管理装置１０では、障害発生時の対応手順がパッケージ化されることになり、開発担当者等が簡単に使える（選べる）ようにすることができる。
従来のシステムでは、障害発生時の対応手順は高度な運用の経験やノウハウ等が必要で、ノウハウ等を有する熟練の開発担当者等からダイレクトに障害時対応を本番にシステムに反映させることはできなかった。本実施形態では、障害対応の判断や実施事項等をシステム化しパッケージ化することができ、障害対応の容易化と適切化を図ることができるようになる。

なお、図５（ａ）〜（ｃ）に示したシステム構成管理テーブル・ジョブ制御情報管理テーブル・自動対応（ＲＢＡ）マスタ管理テーブルについては、データシステムが実装・運用される管理対象装置３０に関する運用システム側のデータである。
したがって、これらのデータは、管理対象装置３０の運用管理サーバ３０ａ〜３０ｎで保持・記憶して、統合プロセス管理装置１０からデータを参照するようにすることもできる。
あるいは、これらのデータを統合プロセス管理装置１０側で保持・記憶して、管理対象装置３０側から参照するようにしても良い。
さらに、これらのデータを、統合プロセス管理装置１０と管理対象装置３０の双方で、同じデータを保持して、同期して更新・管理することもできる。

［ポータル・インタフェース］
次に、上述した統合プロセス管理装置１０の表示制御手段１２によって生成され端末装置２０で閲覧・表示可能なポータル・インタフェースの表示例について図６及び７を参照しつつ説明する。
図６，７は、本発明の一実施形態に係るシステム運用自動化装置で表示・閲覧されるポータル画面のインタフェースのイメージを示す説明図で、図６は問合せ・申請メニュー画面、図７（ａ）は選択された申請内容の詳細画面、図７（ｂ）は対象となる機器やジョブ等の検索画面、図７（ｃ）は申請が運用システム上で処理・反映された結果の確認画面を、それぞれ例示している。

開発担当者・管理者，運用担当者・管理者等のユーザが、端末装置２０を介して統合プロセス管理装置１０にアクセスして、所定のログインＩＤやパスワードを入力してポータル・インタフェースにログインすると、例えば図６に示すような画面が表示される。
図６の画面例では、ログインしたユーザごとに割り当てられた「問合せ・申請メニュー」が表示されており、当該ユーザが選択可能な「申請」の情報が表示される。
したがって、ユーザは、自己が操作する端末装置２０において選択・入力操作を行うことで、予め設定された自己に許可された範囲のみから、所望の申請内容や申請対象機器を選択することができる。
これによって、対象システムに対して、誤りなく正当・適切な申請を簡易かつ迅速に適用させることができるようになる。

図７（ａ）の画面例は、図６の画面から「ジョブ制御申請」が選択された場合の遷移後の画面である。この画面では、選択された「ジョブ制御申請」の詳細内容が表示され、対象システムの情報や申請者の情報，申請承認者の情報等が、この画面で参照・確認できるようになる。
図７（ｂ）の画面例は、所定の検索条件を指定・入力することで、対象となるジョブやフレーム・ネットワーク等を検索・抽出するための画面である。この検索画面から、予め設定された範囲のみから申請内容、申請対象機器を検索して選択することができるようになる。

図７（ｃ）の画面例は、統合プロセス管理装置１０によって管理対象装置３０の本番システムに対して実行された申請や障害対応について、その実行結果を示す画面である。この画面により、自己が選択・申請した新しい申請や、障害発生の通知を受けた障害対応について、本番システム上で実施された処理の結果を確認することができる。これによって、開発担当者は、管理対象装置３０の本番システムに直接アクセスする必要がなく、また、現場のオペレータ等に問い合わせる必要もなく、統合プロセス管理装置１０にアクセスしてポータル・インタフェースを閲覧・参照するだけで、自己が申請した申請内容の実行結果等を確認することができる。

なお、図６，７に示した表示画面は一例であり、これらの画面例以外に、他の画面表示を生成・出力できることは言うまでもない。
また、図６，７の画面例についても、表示項目や表示レイアウトなど、画面構成は任意に設定・変更できることも勿論である。
ユーザの端末装置２０からアクセスして、表示部を介して閲覧・参照可能な表示画面であって、統合プロセス管理装置１０で実行・制御される処理の内容を画面表示で確認できるものであれば、画面の表示項目や表示態様・レイアウト等は、特に限定されるものではない。

［動作］
次に、以上のような構成からなる本実施形態に係るシステム運用自動化装置の動作（システム運用自動化方法）について、図８〜１０を参照しつつ説明する。
図８及び９は、本発明の一実施形態に係るシステム運用自動化装置を備えたシステムにおける申請時の動作の一例を示すフローチャートである。
また、図１０は、本発明の一実施形態に係るシステム運用自動化装置を備えたシステムにおける障害発生時の動作の一例を示すフローチャートである。

［申請時］
管理対象装置３０に対する新たな機能の追加や変更・削除等の申請を行う場合には、まず、開発担当者が端末装置２０を操作して、所定のアプリケーションプログラムを起動して、統合プロセス管理装置１０のポータル・インタフェースにログインを行う（ステップ１）。ログインは、開発担当者等の各ユーザに割り当てられたログインＩＤやパスワードを入力・指定して行われる。
端末装置２０からログイン操作が行われると、統合プロセス管理装置１０では、ログイン画面が起動され（ステップ２）、端末装置２０から入力・送信されたログインＩＤやパスワードについての認証処理が行われる（ステップ３）。

ログインＩＤやパスワードの認証が正しく行われると、統合プロセス管理装置１０では、そのユーザに関連付けられたデータベース（記憶手段１１）の申請メニュー管理テーブル（図４（ａ）参照）が参照されて、申請可能メニューの判定が行われ（ステップ４）、当該ユーザに対応した申請メニュー一覧画面が生成され（ステップ５）、ユーザ側の端末装置２０の表示部に当該画面が表示される（図６参照）。
端末装置２０では、ユーザの入力操作に応じて申請メニューが選択されると（ステップ６）、選択された申請についての具体的な申請内容の入力が行える申請新規入力画面（チケット１）が生成・表示される（ステップ７〜８）。このとき、申請に係る対象サーバなどは、画面に表示されている当該ユーザに選択・指定が許可された範囲から選択されることになる（図７（ａ）参照）。

申請新規入力画面（ステップ８）に対して入力操作が行われると、統合プロセス管理装置１０では、入力内容のチェックが行われる（ステップ９）。このとき、統合プロセス管理装置１０のデータベース（記憶手段１１）の申請内容チェックルール管理テーブル（図４（ｂ）参照）が参照されて、入力内容のチェックが行われる。
そして、申請内容に修正が必要な場合には（ステップ１０）、例えば「申請当日分のジョブスキップを申請することはできません。翌日以降の日付を指定してください。」というように、修正を促す警告や通知が統合プロセス管理装置１０から端末装置２０側に送信・出力される。

必要な修正が行なわれて、申請内容が完備されると、例えば「申請内容に不備はありません。」というように、申請が正常に行われたことを示す通知等が統合プロセス管理装置１０から端末装置２０側に送信・出力される。
申請処理が完了すると、ユーザが端末装置２０を入力操作して、申請新規入力画面（チケット１）から所定の承認申請の操作を行う（ステップ１１）。

端末装置２０で承認申請操作が行われると、統合プロセス管理装置１０では、データベースの承認ワークフロー管理テーブル（図３（ｂ）参照）が参照されて、承認対象者の判定が行われ（ステップ１２）、判定・抽出された承認対象者に対して、登録されたメールアドレスへの承認依頼のメール通知が行われる（ステップ１３）。
承認対象者（開発管理者）が操作する端末装置２０側では、統合プロセス管理装置１０から送信される承認要求メールが受領されると（ステップ１４）、端末装置２０上において所定の承認操作が行われる（ステップ１５）。

この承認操作は、承認対象者が、上述した申請を行う開発担当者の場合と同様に、自己が操作する端末装置２０から統合プロセス管理装置１０のポータル・インタフェースにログインを行い、所定の承認画面（チケット１）上で入力操作を行うことにより実行される（ステップ１６）。
ここで、承認対象者が複数存在する場合には、統合プロセス管理装置１０では、次の承認対象者への承認依頼のメール通知が行われ（ステップ１７）、全ての承認対象者の承認処理が完了するまで、ステップ１２〜１７の工程が繰り返される。

そして、最後の承認対象者となる運用管理者の端末装置２０での承認要求メールの受領（ステップ１８）と、承認画面（チケット１）への承認操作の入力（ステップ１９〜２０）が完了すると、統合プロセス管理装置１０では、データベースのシステム構成管理テーブル（図５（ａ）参照）が参照されて、対応する管理対象装置３０の運用管理サーバ３０ａ〜３０ｎに対して申請に係る処理依頼が実行される（ステップ２１）。
統合プロセス管理装置１０から申請に係る処理依頼を受信した運用管理サーバ３０ａ〜３０ｎでは、対象となる管理対象機器３０−１ａ〜３０−Ｎｎに対して申請内容の反映が実行され（ステップ２２）、申請が反映された管理対象機器３０−１ａ〜３０−Ｎｎでは、例えばジョブのスッキプといった、申請された処理の内容が実施される（ステップ２３）。

その後、申請処理が実施された管理対象機器３０−１ａ〜３０−Ｎｎからは、対応する運用管理サーバ３０ａ〜３０ｎへ処理結果が通知され（ステップ２４）、当該運用管理サーバ３０ａ〜３０ｎから統合プロセス管理装置１０へ、同様に処理結果を通知される（ステップ２５）。
統合プロセス管理装置１０では、運用管理サーバ３０ａ〜３０ｎから受信した申請に係る処理結果をデータベース（記憶手段１１）のジョブ制御情報管理テーブル（図５（ｂ）参照）へ反映させて、データベースを更新する（ステップ２６）。
また、統合プロセス管理装置１０からは、申請者の電子メールアドレスへ、申請に係る処理結果がメールで通知される（ステップ２７）。

処理完了メールを受領・受信した申請者は（ステップ２８）、端末装置２０から統合プロセス管理装置１０のポータル・インタフェースにログインして、申請結果を示す確認画面（チケット１）を表示部に表示させて（図７（ｃ）参照）、自己の申請内容の処理結果を確認することができる（ステップ２９〜３０）。
以上により申請処理は完了となる。

［障害発生時］
管理対象装置３０で発生する障害対応については、まず、予め発生が想定される障害に対する対応について、開発担当者等のユーザが端末装置２０から統合プロセス管理装置１０にアクセス・ログインして、障害発生時に自動実行される処理の内容等を、申請・設定処理を行う。
この障害対応の申請・設定処理は、上述した新たな申請を適用する場合のステップ１〜２１の工程と同様であるので重複する説明は省略する。
設定された障害対応の内容は、統合プロセス管理装置１０のデータベース（記憶手段１１）の自動対応（ＲＢＡ）マスタ管理テーブルに記憶される（図５（ｃ）参照）。

この状態で、管理対象装置３０のいずれかの管理対象機器３０−１ａ〜３０−Ｎｎで障害が発生すると（ステップ３１）、管理対象機器３０−１ａ〜３０−Ｎｎから障害発生を示すアラートが、対応する運用管理サーバ３０ａ〜３０ｎへ通知される（ステップ３２）。
なお、管理対象機器３０−１ａ〜３０−Ｎｎで障害が発生したか否かを、運用管理サーバ３０ａ〜３０ｎ側で監視している場合もある。その場合には、管理対象機器３０−１ａ〜３０−Ｎｎからのアラートの有無に関わらず、運用管理サーバ３０ａ〜３０ｎで障害の発生が検知されることになる。

障害発生を検知した運用管理サーバ３０ａ〜３０ｎからは、統合プロセス管理装置１０へ所定の障害メッセージが通知・出力される（ステップ３３）。
運用管理サーバ３０ａ〜３０ｎから障害メッセージを受信した統合プロセス管理装置１０では、障害管理用のチケット（チケット２）を起票（起動）するとともに、障害メッセージの内容を解析して、自動対応（ＲＢＡ）マスタ管理テーブル（図５（ｃ）参照）を参照して、自動対応パターンを判定する（ステップ３４）。
ここで判定される自動対応の内容としては、例えば「対象サーバに対して詳細情報収集スクリプトを実施する」や「該当システムの開発リーダへ情報をメール通知する」等である。

そして、統合プロセス管理装置１０では、判定された自動対応パターンに従って、管理対象装置３０の運用管理サーバ３０ａ〜３０ｎへ、対応する調査スクリプト等の実施を依頼する（ステップ３５）。
統合プロセス管理装置１０から実施依頼を受信した運用管理サーバ３０ａ〜３０ｎでは、該当する管理対象機器３０−１ａ〜３０−Ｎｎに対して所定のスクリプトが実施され（ステップ３６）。その施結果が、運用管理サーバ３０ａ〜３０ｎから統合プロセス管理装置１０へ通知される（ステップ３７）。

統合プロセス管理装置１０では、運用管理サーバ３０ａ〜３０ｎから受信したスクリプト実施の処理結果をデータベース（記憶手段１１）のジョブ制御情報管理テーブル（図５（ｂ）参照）へ反映させて、データベースを更新する（ステップ３８）。
また、統合プロセス管理装置１０では、実施されたスクリプトに関連する通知対象者がユーザマスタテーブル（図３（ｃ）参照）に基づいて判定され（ステップ３９）、例えば該当システムの開発リーダ等、自動対応内容の申請者が抽出される。
そして、統合プロセス管理装置１０からは、抽出された通知対象者（申請者）の電子メールアドレスへ、障害に対して自動実施された処理結果が障害通知メールとして通知される（ステップ４０）。

障害通知メールを受領・受信した通知対象者は（ステップ４１）、自己が操作する端末装置２０から統合プロセス管理装置１０のポータル・インタフェースにログインして、障害に対する自動対応の処理結果を示す確認画面（チケット２）を表示部に表示させて（図７（ｃ）参照）、発生した障害とそれに対する処理結果を確認することができる（ステップ４２〜４３）。
以上により障害発生時の処理は完了となる。

以上説明したように、本実施形態に係るシステム運用自動化装置によれば、統合プロセス管理装置１０で生成・提供されるポータル・インタフェースを介して、複数の管理対象装置３０に対する新たな申請の適用や障害対応を実行させることができる。
管理対象装置３０に新たな申請を適用する場合には、開発担当者が端末装置２０からポータル・インタフェースにアクセス・ログインを行い、予め設定されたメニューから対応内容を選択して申請を行うと、システム（統合プロセス管理装置１０）が適切な管理者や担当者を抽出・判断して、メール通知等により自動で承認依頼が行われる。

通知を受けた運用管理者等は、端末装置２０等を介して承認を実行でき、承認が行われると、ポータル・インタフェースで選択された申請内容に従って、予め設定された時間に指定（選択）された管理対象装置３０のシステムに対して、自動で申請内容が実行・反映される。自動実行の結果に異常がある場合にも、即時で所定の通知（メール送信等）が自動で行われる。
自動実行された管理対象装置３０の本番システムに反映された内容は、申請をした開発担当者や承認をした運用管理者等が、端末装置２０を介してポータル・インタフェースの申請画面内でいつでも確認することができる。

このように統合プロセス管理装置１０が提供するポータル・インタフェースを介して、管理対象装置３０に対する申請が自動実行されることで、人手による判断ミスや誤操作等を可能な限り軽減乃至排除することができるとともに、申請から本番システムへの反映までの所用時間を大幅に短縮することができる。
また、ポータル・インタフェースの表示画面に沿った選択・入力操作を行うだけで申請の起案・承認・実行が自動で実行され、申請内容の妥当性もシステム側で自動でチェックが行われるため、申請時にミスや誤り等に気付けるため、手戻りの負荷等をなくすことができる。
また、特に定型的な申請に対応する手間が簡略化され、運用担当者の作業負荷を大幅に軽減することができる。これによって、運用担当者等が本来行うべき業務や作業、例えば現場の運用改善等に時間を使うことができるようになる。
さらに、申請が自動実行されることにより、オペレータが不要（図２参照）、もしくはより少人数での運用が可能となる。

一方、管理対象装置３０において発生する可能性がある障害に対しては、まず、障害発生パターンごとに予め調査内容等を事前に申請・設定しておくことができる。障害対応が申請・設定されると、その設定内容に基づいて、システム（統合プロセス管理装置１０）が適切な管理者や担当者を抽出・判断して、メール通知等により自動で承認依頼が行われる。
また、障害対応の申請についても、設定内容の妥当性がシステムで自動チェックされ、ミスや誤り等があれば設定入力時に気付けるため、手戻りの負荷等をなくすことができる。
この障害対応の設定について運用管理者による承認が行われると、設定内容に従って、障害発生時の自動調査や自動対応の設定が、管理対象装置３０の本番システムへ自動で実行・反映される。

そして、いずれかの管理対象装置３０で障害が発生すると、管理対象装置３０から出力されるアラートにより障害発生が検知され、そのアラートの内容に応じて、統合プロセス管理装置１０が自動実行可能な対応手順の有無や内容を自動で判断し、所定の障害対応を管理対象装置３０に対して自動で実行・反映させる。また、障害対応の内容が、関係する現場の要員等へメール送信等によって通知される。
管理対象装置３０で発生したアラートの内容や、自動実行された対応内容の確認は、管理対象装置３０の本番システムにログイン等することなく、端末装置２０を介してポータル・インタフェースの画面内でいつでも確認することができる。

このようにして、管理対象装置３０の障害対応についても、統合プロセス管理装置が提供するポータル・インタフェースを介して障害対応を事前に設定することができ、かつ、障害発生時には、設定した対応内容が自動実行されるようになる。
これによって、障害発生から対応内容が本番システムへ実行・反映されるまでの時間を大幅に短縮できるとともに、障害発生時の影響拡大を防止することができる。
また、障害対応の内容は、予め想定される障害に対して適切な対応内容が開発担当者等によって設定・承認されており、障害発生と同時にその対応が自動実行されるので、人手による判断ミスや誤対応等を可能な限り軽減乃至排除することができ、また、運用ノウハウの属人化を防ぐこともできる。
さらに、障害対応の自動実行が行われることで、特に繰返し発生する軽微な問題に対応するための現場要員や運用担当等の作業負荷を大幅に軽減することができ、運用担当者等が本来実施すべき業務（運用改善等）に時間を使うことができるようになる。

このようにして、本実施形態では、統合プロセス管理装置１０に対して障害対応を自動実行可能に事前設定できることで、障害対応時の自動対応手順をメニュー化することができ、例えば開発担当者は自動対応指示をポータル・インタフェースのメニューから選択するだけでよくなる。
従来のシステム運用では、障害発生時の対応手順には高度な運用の経験やノウハウ等が必要で、しかも、ノウハウ等を有する熟練の開発担当者等からダイレクトに障害時対応を本番にシステムに反映させることはできなかった。本実施形態では、障害対応の判断や実施事項等をシステム化しパッケージ化することが可能となり、経験やノウハウ等の少ない開発担当者でも簡単に使える（選べる）ようになり、障害対応の容易化と適切化を図ることができるようになる。
また、開発担当者によっては、例えば新入社員等、障害対応についての運用ノウハウが十分でない場合もあり、ポータル・インタフェースの簡略化したメニューで対応できるようにすることで、開発要員の教育負荷等を軽減できるという効果もある。

このように、本実施形態に係るシステム運用自動化装置によれば、人の介在とそれに伴う人為的ミスや運用ノウハウの属人化等を可能な限りなくして、管理対象装置３０について常に最新の機器構成等の情報を収集でき、例えば運用管理サーバ３０ａ〜３０ｎと管理対象機器３０−１ａ〜３０−Ｎｎとの間での紐付けがシステム（統合プロセス管理装置１０）で判断できるようになるため、申請内容等に応じて、対象機器や影響範囲の人為的誤り等を、予め申請を行う時点で防止することができる。
また、いつどんな障害が起きるかわからない管理対象装置３０に対して、いつ問題が起きても、発生した障害の内容に応じて自動対応が可能となり、かつ、その対応内容の設定や自動対応結果の確認等も、ポータル・インタフェースを介して開発担当者自身が自由に随時行えるようになる。

したがって、多数の管理対象装置３０を備えるデータシステム対しても、誤りなく迅速かつ確実に申請や障害対応を実行・反映させることができ、実行された新たな反映情報はリアルタイムに関係者間で共有することができる。
これによって、数百台〜数千台，数万台オーダーで多数の管理対象装置を備える大企業のデータシステムや、複数企業等の異なるデータを大量に取り扱うデータシステムの運用を業務として請け負う情報システム企業が所有する巨大なサーバシステム群についても、システムを安全に維持・管理して、安定的なシステム運用を実現することができる。

さらに、本実施形態に係るシステム運用自動化装置によれば、開発部署の担当者・管理者も、運用部署の担当者・管理者も、全て統合プロセス管理装置１０で提供されるポータル・インタフェースを確認するだけで、管理対象装置３０で運用されるデータシステムを安全に維持・管理することができ、管理対象装置３０の本番システム自体に直接アクセスすることがなくなる。
したがって、ポータル・インタフェースの閲覧・参照履歴がシステム監査に対する証跡となり、本実施形態に係るシステム自体が、セキュリティや責任分界点が正しく守られていることの証明乃至保証となるという効果もある。

以上、本発明について、好ましい実施形態を示して説明したが、本発明は、上述した実施形態に限定されるものではなく、本発明の範囲で種々の変更実施が可能であることは言うまでもない。
例えば、上述した実施形態では、本発明に係るシステム運用自動化装置が適用されるデータシステムとして、複数の管理対象装置において実装・運用される大規模データシステムを想定して説明したが、本発明が適用可能なデータシステムや管理対象装置は、その規模の大小やシステムの内容については特に限定されるものではない。
システム運用のために新たな申請が行われ、また、迅速な対応が必要な障害が発生する可能性のあるデータシステムや情報処理装置であれば、システムの規模や内容はどのようなものであっても本発明を適用・実施することができる。

１０ 統合プロセス管理装置（システム運用自動化装置）
１１ 記憶手段（データベース）
１２ 表示制御手段
１３ 申請実行手段
１４ 障害対応実行手段
２０ 端末装置
３０ 管理対象装置

Claims (6)

1. データシステムを運用する複数の管理対象装置に接続された情報処理装置であって、
   前記複数の管理対象装置の識別情報と、各管理対象装置で運用されるデータシステムの運用情報、各管理対象装置で運用可能な申請に関する申請情報、各管理対象装置で発生する可能性のある障害に関する障害対応情報を記憶する記憶手段と、
   前記複数の管理対象装置の識別情報，運用情報，申請情報及び障害対応情報を、所定の表示部に選択可能に表示させる表示制御手段と、
   入力操作に応じて前記申請情報が選択されると、当該申請情報に係る申請を、対応する管理対象装置に反映させる申請実行手段と、
   前記管理対象装置において障害が発生すると、対応する前記障害対応情報に係る障害対応を、当該管理対象装置に反映させる障害対応実行手段と、
   を備え、
   前記記憶手段は、前記申請実行手段で反映された申請及び前記障害対応実行手段で反映された障害対応に係る情報を、対応する管理対象装置の情報として更新して記憶し、
   前記表示制御手段は、前記記憶手段で更新された情報を表示させる
   ことを特徴とするシステム運用自動化装置。
2. 前記申請実行手段は、
   入力操作に応じて前記申請情報が選択されると、当該申請情報に対応する承認者装置に、所定の承認依頼通知を送信する
   ことを特徴とする請求項１記載のシステム運用自動化装置。
3. 前記障害対応実行手段は、
   前記管理対象装置において障害が発生すると、当該管理対象装置に対応する障害対応者装置に、所定の障害発生通知を送信する
   ことを特徴とする請求項１又は２記載のシステム運用自動化装置。
4. 前記障害対応実行手段は、
   入力操作に応じて新たな障害対応情報が設定されると、当該障害対応情報に対応する承認者装置に、所定の承認依頼認通知を送信する
   ことを特徴とする請求項１乃至３のいずれか一項記載のシステム運用自動化装置。
5. データシステムを運用する複数の管理対象装置に接続された情報処理装置を構成するコンピュータを、
   前記複数の管理対象装置の識別情報と、各管理対象装置で運用されるデータシステムの運用情報、各管理対象装置で運用可能な申請に関する申請情報、各管理対象装置で発生する可能性のある障害に関する障害対応情報を記憶する記憶手段、
   前記複数の管理対象装置の識別情報，運用情報，申請情報及び障害対応情報を、所定の表示部に選択可能に表示させる表示制御手段、
   入力操作に応じて前記申請情報が選択されると、当該申請情報に係る申請を、対応する管理対象装置に反映させる申請実行手段、
   前記管理対象装置において障害が発生すると、対応する前記障害対応情報に係る障害対応を、当該管理対象装置に反映させる障害対応実行手段、
   として機能させるとともに、
   前記記憶手段に、前記申請実行手段で反映された申請及び前記障害対応実行手段で反映された障害対応に係る情報を、対応する管理対象装置の情報として更新して記憶させ、
   前記表示制御手段に、前記記憶手段で更新された情報を表示させる
   ことを特徴とするシステム運用自動化プログラム。
6. データシステムを運用する複数の管理対象装置に接続された情報処理装置を構成するコンピュータを用いて、
   前記複数の管理対象装置の識別情報と、各管理対象装置で運用されるデータシステムの運用情報、各管理対象装置で運用可能な申請に関する申請情報、各管理対象装置で発生する可能性のある障害に関する障害対応情報を記憶する記憶手順、
   前記複数の管理対象装置の識別情報，運用情報，申請情報及び障害対応情報を、所定の表示部に選択可能に表示させる表示制御手順、
   入力操作に応じて前記申請情報が選択されると、当該申請情報に係る申請を、対応する管理対象装置に反映させる申請実行手順、
   前記管理対象装置において障害が発生すると、対応する前記障害対応情報に係る障害対応を、当該管理対象装置に反映させる障害対応実行手順、
   を実行するとともに、
   前記記憶手順において、前記申請実行手順で反映された申請及び前記障害対応実行手順で反映された障害対応に係る情報を、対応する管理対象装置の情報として更新して記憶し、
   前記表示制御手順において、前記記憶手段で更新された情報を表示させる
   ことを特徴とするシステム運用自動化方法。