JPH1083382A

JPH1083382A - 分散システム運用保守支援装置および運用保守支援方法

Info

Publication number: JPH1083382A
Application number: JP8237721A
Authority: JP
Inventors: Yukiteru Nozawa; 幸輝野澤
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 1996-09-09
Filing date: 1996-09-09
Publication date: 1998-03-31

Abstract

(57)【要約】【課題】分散システムの運用保守を効果的、経済的か
つ計画的に行えるようにした分散システム運用保守支援
装置および運用保守支援方法を提供する。【解決手段】本発明に係る分散システム運用保守支援
装置１１は、運用保守支援を開始し、さらにその後に続
く運用保守支援の一連の動作を制御する運用保守制御手
段１１０と、業務を体現するアプリケーションとそれが
実装される分散システムとの間の対応関係を所定の仕様
として管理し、所定の業務情報及び所定の構成要素情報
の少なくともいずれか一方を提供する業務仕様管理手段
１１１と、運用保守が必要な分散システムの構成要素に
対して、将来的な動向を予測する予測手段１１２と、分
散システムから収集した運用保守情報を予測手段に伝え
る監視手段１１３とから構成されている。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複数の計算機およ
びその周辺機器をネットワークを介して構成した分散シ
ステムの運用保守を支援するための分散システム運用保
守支援装置および運用保守支援方法に関する。

【０００２】

【従来の技術】従来、複数の計算機およびその周辺機器
をネットワークを介して構成した分散システム（以下、
分散システムと総称する）については、いかにして分散
システムの処理性能を上げるか、あるいは信頼性を上げ
るかといった観点からの研究開発に重点が置かれてい
た。しかし、この分散システムをどのように運用保守し
ていくべきかという点も非常に重要である。

【０００３】ここで、上記「分散システムの運用保守」
とは、「分散システムの利用者であるエンドユーザが、
分散システム上に実装された業務アプリケーションを、
十分有効に、かつ支障なく利用できるようにするため
に、分散システムの管理者が、既にサービスの提供を実
施している分散システムの構成要素を適切に維持してい
くこと」と定義される。

【０００４】たとえば、ある業務において重要な役割を
担うサーバがある場合、当サーバが十分なパフォーマン
スを発揮しつづけられるように、当サーバのディスクや
メモリ、あるいは当サーバに関係するネットワークなど
のシステムリソースを、必要に応じて強化していくとい
った、ハードウェアに対する作業が挙げられる。また、
別の例としては、ある業務に関連したトランザクション
を構成するプロセスについて、その実行をクライアント
側からサーバ側へ移すといった、ソフトウェアに対する
作業が挙げられる。

【０００５】このような分散システムの運用保守に関す
る技術としては、例えば、特開平６−１４９７３７号公
報に示された発明がある。この発明は、負荷分散による
処理性能の向上や、危険分散による信頼性の向上、ある
いはいわゆるダウンサイジングによるコストの抑制な
ど、分散システムの利点を活かしつつ、集中管理方式を
導入することで、分散システムの運用保守を容易にする
ことを目的としている。

【０００６】また、前記集中管理方式の導入にあたって
は、まず、島と呼ばれる任意数の計算機およびその周辺
機器からなる管理単位を設定し、この島毎にコントロー
ルサーバと呼ばれる管理システムを割り当てる。さら
に、任意数の島を一括して管理するために、マスターサ
ーバと呼ばれる管理システムを割り当てる。

【０００７】このように構成することによって、マスタ
ーサーバによる集中的／一元的な運用保守が可能とな
り、マスターサーバの過負荷が問題になるような場合で
も、ある島に特有の運用保守は、その島に割り当てられ
ているコントロールサーバに任せることで、マスターサ
ーバの過負荷を防ぐことを可能としている。また、この
ような集中管理方式を採用することによる効果として、
ユーザ管理、アカウント管理、プログラム配布、ネット
ワーク構成管理、ネットワーク状況監視、障害対応、周
辺機器の管理などを、効果的かつ容易に行うことができ
るとしている。

【０００８】しかし、分散システムの運用保守にあたっ
て、前記発明によっても解決されない課題がいくつか存
在する。すなわち、前記発明においては、分散システム
を、その上に実装されている業務アプリケーションの持
つ「意味」とは無関係に運用保守しているので、業務上
重要と思われる管理対象と、さほど重要と思われない管
理対象とが、同レベルで等しく管理されることになる。
その結果、分散システムのエンドユーザが「もっとも重
要である」と考えている業務に関連した運用保守対象が
優先して運用保守されないという問題が生じていた。ま
た、すべての管理対象が同レベルで管理されるため、運
用保守にかかるコストに無駄が生じるといった問題も生
じていた。

【０００９】例えば、前記発明に示されているサーバの
障害検知の実施例についてみると、前記発明において
は、分散システムのエンドユーザがもっとも重要である
と考えている業務のためのサービスを、どのサーバが請
け負っているのかについて把握することができないた
め、エンドユーザにとって重要度の高い業務に関連した
サーバが優先して運用保守されなかった。また、分散シ
ステムの管理者は、分散システムに含まれるすべてのサ
ーバについて、一様なコストをかけて管理しなければな
らず、分散システムの運用保守にかかるコストに無駄が
生じていた。

【００１０】さらに、前記発明においては、分散システ
ム内で発生した障害などについての運用保守上必要な情
報は、それらの障害などが起こったあとに初めて分散シ
ステムの管理者によって把握されるので、運用保守が常
に後手にまわってしまうという問題が生じていた。その
結果、分散システムのエンドユーザは、分散システム内
で発生した障害などによって、本来受けられるべきサー
ビスが突然受けられなくなったり、あるいは非常に低い
処理性能のもとでしかサービスを受けられなくなったり
するなど、本来の品質を保ったサービスを受けることが
できず、多大な不利益を被る危険性が高かった。

【００１１】すなわち、前記発明によって得られる運用
保守装置においては、各サーバのディスク使用量などの
情報を監視できることが示されているものの、その情報
をどのように扱うかについての詳細が記述されておら
ず、上述したような運用保守が後手にまわってしまうと
いう問題を解決できていない。

【００１２】次に、分散システムの運用保守に関する他
の技術としては、例えば、特開平７−２１０５９号公報
に示された発明がある。この発明は、分散システム内で
発生する障害などについての情報を、一括して採取／収
集／編集／転送できるような集中管理方式を導入するこ
とで、分散システムの構成要素単位ではなく、分散シス
テム全体にわたる運用保守を可能にすることを目的とし
ている。

【００１３】また、前記集中管理方式の導入にあたって
は、上述した特開平６−１４９７３７号公報に示された
発明とほぼ同じく、最上位の統合サーバ、営業店毎の営
業店サーバ、そしてクライアントからなる階層を構成
し、運用保守上必要な情報が下位の階層から上位の階層
に転送されていくようにすることで、集中管理を可能と
している。さらに、この発明においては、運用保守上必
要な情報の形式および内容を、オブジェクト指向の考え
方に基づいて規定することを提案している。これによ
り、運用保守上必要な情報を、特定のソフトウェアなど
の環境に依存しない形で管理することができるようにし
ている。

【００１４】しかし、分散システムの運用保守にあたっ
て、前記発明によっても解決されない課題がいくつか存
在する。すなわち、業務毎に異なる特性が意識されない
ことに起因して、重点を置くべき運用保守対象が優先さ
れて処理されず、また、すべての運用保守対象を同レベ
ルで扱うため、無駄なコストが発生するという点であ
る。すなわち、この発明においても、業務アプリケーシ
ョンの「意味」と分散システムとを関連付ける技術につ
いてはなんら示されておらず、結果として、優先的に運
用保守を行うべき対象を特定することができないまま、
無駄な運用保守コストが発生している。

【００１５】さらに、この発明においても、運用保守上
必要な情報が管理者に伝わるのが、障害などが発生した
後になってしまうので、運用保守が常に後手にまわって
しまうという問題も生じていた。なお、この発明におい
ては、「予防保守」という表現によって、運用保守が後
手にまわってしまう課題を意識していることが表わされ
ているが、定期的かつ定量的に分散システムの構成要素
を管理すること以上の、具体的な運用保守の方法につい
ては言及されておらず、運用保守が後手にまわってしま
う課題を解決できているとはいえない。

【００１６】また、分散システムの運用保守の観点に基
づく他の技術としては、米国Ｈｅｗｌｅｔｔ−Ｐａｃｋ
ａｒｄ社の、ＨＰＯｐｅｎＶｉｅｗという製品がある
（日経データプロ・ソフト１９９５年２月号ｐ．
２５１−２６９）。この製品は大きくネットワーク管理
製品群とシステム管理製品群に分かれている。ネットワ
ーク管理製品群の中核となるのは、ＨＰＯｐｅｎＶｉ
ｅｗネットワーク・ノード・マネージャと呼ばれる製
品であり、ＳＮＭＰ（ＳｉｍｐｌｅＮｅｔｗｏｒｋ
ＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ）ベースで、
ネットワークについての障害管理、構成管理、性能管理
を行う。また、システム管理製品群の中核となるのは、
ＨＰＯｐｅｎＶｉｅｗＯｐｅｒａｔｉｏｎｓＣｅ
ｎｔｅｒと呼ばれる製品であり、ＳＮＭＰベースで、シ
ステムについてのイベント管理、ソフトウェア配布、フ
ァイル等のバックアップ、負荷状況の把握などを行う。

【００１７】しかし、この製品によっても先に示した運
用保守上の課題は解決されない。すなわち、この製品に
おいても、分散システム上に実装されている業務アプリ
ケーションの「意味」と分散システムとを明示的に関連
付ける手段は提供されておらず、重点を置くべき運用保
守対象が優先されて処理されず、また、すべての運用保
守対象を同レベルで扱うため、無駄なコストが発生する
という問題が生じている。

【００１８】確かに、ネットワーク管理のサブ製品であ
るＨＰＯｐｅｎＶｉｅｗＨｉｓｔｏｒｙＡｎａ
ｌｙｚｅｒでは、特定のサービスを多く利用している
ユーザの状況を把握でき、このことによって一部の局面
では、業務の「意味」と分散システムの関連付けはなさ
れているということができるが、業務のもつ重要性は、
ユーザのサービス利用数とは直接相関関係にあるとはい
えない。例えば、非常に重要な基幹業務などは、ごく限
られたユーザがごく限られたタイミングでしかサービス
を受けないものと考えられるからである。

【００１９】さらに、この製品においては、システム管
理のサブ製品であるＨＰＰｅｒ−ｆＲＸおよび
ＨＰＰＣＳと呼ばれる製品によって、分散システム
の構成要素に対しての性能管理データの収集および将来
動向予測などのデータ分析を可能にしている。しかし、
業務の特性を意識した、重点をおくべき運用保守対象を
特定できていないため、データ分析を適切に行えず、結
果として適切でない分析結果による運用保守が行われて
しまう危険性があった。

【００２０】

【発明が解決しようとする課題】上述したように、従来
の分散システムの運用保守支援技術は、どの業務が重要
であるかといった業務のもつ「意味」と、分散システム
の構成要素を適切に関連付けるための十分な手段を提供
しておらず、また、分散システムに対する適切な分析手
段を提供しないまま、運用保守を支援していた。

【００２１】その結果、解決すべき課題として次の３点
が挙げられる。すなわち、（１）分散システムのエンド
ユーザがもっとも重要であると考えている業務に関連し
た運用保守対象が、優先して運用保守されない。（２）
重要でない業務に関連した運用保守対象も、すべて平等
に運用保守されてしまい、運用保守コストに無駄が発生
してしまう。（３）運用保守対象を特定するための分析
が適切に行えず、有効な運用保守計画を立案することが
できない。

【００２２】本発明は、上述したような従来技術の問題
点を解決するために提案されたもので、その目的は、分
散システムの運用保守を効果的、経済的かつ計画的に行
えるようにした分散システム運用保守支援装置および運
用保守支援方法を提供することにある。

【００２３】

【課題を解決するための手段】上記の目的を達成するた
めに、請求項１に記載の発明は、複数の計算機およびそ
の周辺機器をネットワークを介して構成した分散システ
ムに対する運用保守支援装置であって、前記分散システ
ムの運用保守支援を開始し、さらにその後に続く運用保
守支援動作を制御する運用保守制御手段と、前記分散シ
ステムの構成要素とその分散システムに実装される業務
アプリケーションとの間の対応関係を所定の仕様として
管理し、前記運用保守制御手段からの問い合わせに応じ
て、所定の業務情報及び所定の構成要素情報の少なくと
もいずれか一方を提供する業務仕様管理手段と、前記分
散システムから、運用保守支援のために必要な運用保守
情報を収集する監視手段とを備えたことを特徴とするも
のである。

【００２４】また、請求項５に記載の発明は、請求項１
に記載の発明を方法の観点から捉えたものであり、複数
の計算機およびその周辺機器をネットワークを介して構
成した分散システムに対する運用保守支援方法であっ
て、前記分散システムの運用保守支援を開始し、さらに
その後に続く運用保守支援動作を制御する運用保守制御
ステップと、前記分散システムの構成要素とその分散シ
ステムに実装される業務アプリケーションとの間の対応
関係を所定の仕様として管理し、前記運用保守制御ステ
ップにおける問い合わせに応じて、所定の業務情報及び
所定の構成要素情報の少なくともいずれか一方を提供す
る業務仕様管理ステップと、前記分散システムから、運
用保守支援のために必要な運用保守情報を収集する監視
ステップとを含むことを特徴とするものである。

【００２５】このような構成を有する請求項１に記載の
分散システム運用保守支援装置あるいは請求項５に記載
の分散システム運用保守支援方法においては、運用保守
支援を進める上での全体的な流れを、運用保守制御手段
が制御する。この流れは、運用保守制御手段内に保持さ
れている起動を司る仕組みによって開始され、それとと
もに分散システムのエンドユーザがもっとも重要である
と考えている業務が何であるかについての情報とそれに
付随する情報が取得される。この段階で、エンドユーザ
にとって優先されるべき運用保守が正しく実施されるこ
とが保証され、効果的な運用保守が可能となる。さら
に、業務仕様管理手段によって、分散システムのエンド
ユーザがもっとも重要であると考えている業務と、運用
保守が必要になるかも知れない分散システム内の構成要
素が関連づけられる。この段階で、無駄な運用保守コス
トの発生を抑えることができるようになり、経済的な運
用保守が可能となる。

【００２６】請求項２に記載の発明は、複数の計算機お
よびその周辺機器をネットワークを介して構成した分散
システムに対する運用保守支援装置であって、前記分散
システムの運用保守支援を開始し、さらにその後に続く
運用保守支援動作を制御する運用保守制御手段と、前記
分散システムの構成要素とその分散システムに実装され
る業務アプリケーションとの間の対応関係を所定の仕様
として管理し、前記運用保守制御手段からの問い合わせ
に応じて、所定の業務情報及び所定の構成要素情報の少
なくともいずれか一方を提供する業務仕様管理手段と、
前記分散システムの構成要素の内、運用保守制御手段に
より指示された構成要素の将来的な動向を予測する予測
手段と、前記分散システムから、運用保守支援のために
必要な運用保守情報を収集する監視手段とを備えたこと
を特徴とするものである。

【００２７】また、請求項６に記載の発明は、請求項２
に記載の発明を方法の観点から捉えたものであり、複数
の計算機およびその周辺機器をネットワークを介して構
成した分散システムに対する運用保守支援方法であっ
て、前記分散システムの運用保守支援を開始し、さらに
その後に続く運用保守支援動作を制御する運用保守制御
ステップと、前記分散システムの構成要素とその分散シ
ステムに実装される業務アプリケーションとの間の対応
関係を所定の仕様として管理し、前記運用保守制御ステ
ップにおける問い合わせに応じて、所定の業務情報及び
所定の構成要素情報の少なくともいずれか一方を提供す
る業務仕様管理ステップと、前記分散システムの構成要
素の内、運用保守制御ステップにおいて指示された構成
要素の将来的な動向を予測する予測ステップと、前記分
散システムから、運用保守支援のために必要な運用保守
情報を収集する監視ステップとを含むことを特徴とする
ものである。

【００２８】このような構成を有する請求項２に記載の
分散システム運用保守支援装置あるいは請求項６に記載
の分散システム運用保守支援方法においては、請求項１
あるいは請求項５に記載の発明と同様に、運用保守制御
手段によって全体的な流れが制御され、業務仕様管理手
段によって業務と分散システム内の構成要素が関連づら
れる。次に、予測手段において、運用保守が必要になる
かも知れない分散システム内の構成要素の将来動向を予
測し、運用保守が必要であることが判明した分散システ
ム内の構成要素のみを特定する。この段階で、請求項１
あるいは請求項５に記載した発明よりも、さらに無駄な
運用保守コストの発生を抑えることができるようにな
り、より経済的な運用保守が可能となる。また、それと
同時に、予測結果をもとにした適切な分析によって、有
効な運用保守計画を立案することができるようになり、
計画的な運用保守が可能となる。

【００２９】請求項３に記載の発明は、請求項２に記載
の分散システム運用保守支援装置において、前記予測手
段が、前記監視手段によって収集された運用保守情報
と、予測に当てはめられる予測モデルとに基づいて、分
散システムの構成要素の将来的な動向を予測するように
構成されていることを特徴とするものである。

【００３０】また、請求項７に記載の発明は、請求項３
に記載の発明を方法の観点から捉えたものであり、請求
項６に記載の分散システム運用保守支援方法において、
前記予測ステップが、前記監視ステップによって収集さ
れた運用保守情報と、予測に当てはめられる予測モデル
とに基づいて、分散システムの構成要素の将来的な動向
を予測するように構成されていることを特徴とするもの
である。

【００３１】このような構成を有する請求項３に記載の
分散システム運用保守支援装置あるいは請求項７に記載
の分散システム運用保守支援方法においては、適切な予
測モデルから得られた予測結果をもとにして、適切な分
析を行うことができるので、有効な運用保守計画を立案
することができるようになり、計画的な運用保守が可能
となる。

【００３２】請求項４に記載の発明は、請求項１乃至請
求項３のいずれか一に記載の分散システム運用保守支援
装置において、前記運用保守制御手段が、運用保守対象
とすべき業務の重要度を自動的に設定するように構成さ
れていることを特徴とするものである。

【００３３】また、請求項８に記載の発明は、請求項４
に記載の発明を方法の観点から捉えたものであり、請求
項５乃至請求項７のいずれか一に記載の分散システム運
用保守支援方法において、前記運用保守制御ステップ
が、運用保守対象とすべき業務の重要度を自動的に設定
するように構成されていることを特徴とするものであ
る。

【００３４】このような構成を有する請求項４に記載の
分散システム運用保守支援装置あるいは請求項８に記載
の分散システム運用保守支援方法においては、管理者が
当初はあまり重要でないと考えていた業務を見逃す危険
性を低く抑えることができるようになるので、より確実
な運用保守を実施することが可能となる。

【００３５】

【発明の実施の形態】以下、本発明の実施形態につい
て、図面を参照して具体的に説明する。

【００３６】［１．本発明による運用保守支援の全体
像］図１は、本発明による運用保守支援の全体像を示し
たものである。すなわち、運用保守の対象となる分散シ
ステム（以下、運用保守対象分散システムと称する）１
０は、エンドユーザ１２によって各種業務に利用され、
また、本発明に係る運用保守支援装置１１によってその
挙動が監視され、さらに、管理者１３によって運用保守
される。一方、運用保守支援装置１１は、前記運用保守
対象分散システム１０の挙動を監視し、管理者１３に対
して運用保守支援を行う。また、エンドユーザ１２は、
運用保守対象分散システム１０を業務に利用する上で、
管理者１３に対して、どの業務が重要かといった業務の
「意味」を要求として伝え、また、管理者１３から、運
用保守対象分散システム１０をどのように運用保守する
かについてアナウンスを受ける。さらに、管理者１３
は、運用保守対象分散システム１０を運用保守支援装置
１１の支援を受けながら運用保守し、また、エンドユー
ザ１２に運用保守対象分散システム１０をどのように運
用保守するかについてアナウンスし、エンドユーザ１２
からどの業務が重要かといった業務の「意味」を要求と
して受けとる。

【００３７】なお、前記運用保守対象分散システム１０
と運用保守支援装置１１は、物理的に同じシステム上に
実装されても、分けて実装されても良いし、さらには、
一部混在する形で実装されても良い。論理上、運用保守
対象分散システム１０と運用保守支援装置１１の間の区
別がつけば良い。また、同様に、エンドユーザ１２と管
理者１３が、実際には同一の個人、あるいは複数からな
るグループでも構わない。

【００３８】［２．運用保守対象分散システムの構成］
図２は、運用保守対象分散システム１０の詳細を示した
ものである。すなわち、運用保守対象分散システム１０
は、複数の計算機１００（ＣＰＵ１０３あるいはメモリ
１０４などを含む）、およびその周辺機器であるディス
ク１０５、ネットワーク１０６などから構成されてい
る。ここで、前記計算機１００については、分散システ
ムのアーキテクチャあるいはモデルによって、サーバ１
０１やクライアント１０２といった区別を持たせること
ができる。なお周辺機器については、運用保守の必要性
に応じてどのようなものを対象にするかが決まり、図２
に示したディスク１０５に限定されるものではない。

【００３９】また、この運用保守対象分散システム１０
には、本発明に係る運用保守支援装置１１と連携するた
めの、分散システム内監視手段１０７が含まれている。
この分散システム内監視手段１０７は、ＣＰＵ１０３や
メモリ１０４、ディスク１０５、ネットワーク１０６な
どから、運用保守対象分散システムに必要な運用保守情
報を収集する。すなわち、分散システム内監視手段１０
７は、単にデータを収集する手段であり、既存の技術に
よって容易に構築できる部位である。例えば、従来の技
術の項において挙げたＨＰＯｐｅｎＶｉｅｗで
は、ＨＰＯｐｅｎＶｉｅｗＴｒａｆｆｉｃＥｘｐ
ｅｒｔ／ＵＸという製品によって、ＬＡＮを流れるト
ラフィックを監視することができる。なお、分散システ
ム内監視手段１０７が行う収集の方法などについては、
本発明に係る運用保守支援装置１１から指示を受けて決
定されるように構成されている。

【００４０】［３．運用保守支援装置の構成］図３は、
本発明の対象である運用保守支援装置１１の構成を示し
たものである。すなわち、運用保守支援装置１１は、以
下に詳述する運用保守制御手段１１０、業務仕様管理手
段１１１、予測手段１１２、監視手段１１３とから構成
されている。

【００４１】ここで、前記運用保守制御手段１１０は、
管理者１３から明示的な運用保守支援依頼を受けるか、
内部的な動機が発生することによって、運用保守支援を
開始し、さらにその後に続く運用保守支援の一連の動作
を制御するものである。また、前記業務仕様管理手段１
１１は、業務を体現するアプリケーションと、それが実
装される分散システムとの間の対応関係を仕様として管
理しており、前記運用保守制御手段１１０からの問い合
わせに応じて、必要な情報を提供するものである。さら
に、前記予測手段１１２は、前記運用保守制御手段１１
０から指示された、運用保守が必要と思われる分散シス
テムの構成要素に対して、将来的な動向を予測するもの
である。また、監視手段１１３は、運用保守対象分散シ
ステム１０内に含まれている前記分散システム内監視手
段１０７に、データウェアハウスとしての側面を与え
る。すなわち、運用保守上必要なデータの収集の仕方に
関して指示を与え、前記予測手段１１２が必要とする運
用保守情報を収集させ、収集された運用保守情報を予測
手段１１２に伝えるものである。

【００４２】なお、運用保守対象分散システム１０内の
監視手段１０７は、単なるデータ収集の手段であった
が、これに対して、運用保守支援装置１１内の監視手段
１１３は、分散システム内監視手段１０７から取り出し
たデータを、運用保守上利用しやすいような形式に変換
するといった付加的な機能を有している。

【００４３】［３−１．運用保守制御手段の構成］図４
は、前記運用保守制御手段１１０の構成を示したもので
ある。すなわち、運用保守制御手段１１０は、以下に詳
述する窓口１１００あるいはタイマ１１０１、またはそ
の両方と、運用保守制御リスト１１０２、予測対象リス
ト１１０３、要求特性データ１１０４、予測データ１１
０５、判断部１１０６および運用保守対象リスト１１０
７とから構成されている。

【００４４】（窓口）窓口１１００は、管理者１３が明
示的／意識的に、運用保守対象分散システム１０の運用
保守支援を受けようと考えたときの窓口となる。すなわ
ち、管理者１３が、窓口１１００から、どの業務につい
て運用保守を行うかを入力することによって、運用保守
制御手段１１０による制御が開始される。

【００４５】ここで、図５は、窓口１１００で行われる
前記入力処理を受け付ける画面の一例を示したものであ
る。すなわち、図５に示した例においては、「業務」
と、その業務が投入される「ノード」が入力できるよう
になっている。また、ボタン２０は、運用保守の必要が
あるかどうかが頻繁にチェックされる業務をまとめて指
定できるボタンである。一方、運用保守の必要があるか
どうかを個別にチェックしたい場合には、リストボック
ス２１から所望の「業務」を個別に選んで指定すること
もできる。さらに、ボタン２２は、ボタン２０あるいは
リストボックス２１で選ばれた業務が通常投入されるノ
ードをまとめて指定できるボタンである。一方、業務投
入ノードを個別に指定したい場合には、リストボックス
２３から指定することもできる。なお、窓口１１００か
ら入力される情報、および窓口１１００が提供するガイ
ダンスは、必ずしも上記の通りでなくとも良い。

【００４６】（タイマ）タイマ１１０１は、管理者１３
が明示的／意識的に運用保守を行おうとしない場合で
も、運用保守支援装置１１として自発的に運用保守支援
を行うために必要とされるものである。すなわち、予め
タイマ１１０１に設定された日時／時刻になると、運用
保守制御手段１１０による制御が開始されるように構成
されている。

【００４７】（運用保守制御リスト）前記窓口１１００
あるいはタイマ１１０１によって、運用保守制御手段１
１０が起動されると、運用保守制御リスト１１０２に記
述された内容にしたがって、どの業務を運用保守の対象
とするかが決定される。

【００４８】ここで、図６は、運用保守制御リスト１１
０２の一例を示したものである。すなわち、窓口１１０
０においてデフォルト業務が指定されたときには、受注
業務と発注業務を対象とし、さらに窓口１１００におい
てデフォルトノードが指定されたときには、東京都と大
阪を対象とすることが記述されている。また、図６の例
では、タイマ１１０１によって起動される場合、毎月１
日の午前４時と毎日午前５時に運用保守制御手段１１０
を起動し、それぞれの場合に対象とすべき業務が何であ
るのかが記述されている。なお、運用保守制御リスト１
１０２記述する内容および記述の方法は、必ずしも上記
の通りでなくとも良い。

【００４９】（予測対象リストおよび要求特性データ）
運用保守制御手段１１０は、前記運用保守制御リスト１
１０２の内容をもとに、業務仕様管理手段１１１に問い
合わせを行い、業務に関連して運用保守の対象となり得
る分散システムの構成要素（ＣＰＵ１０３やメモリ１０
４、ディスク１０５、ネットワーク１０６など）を記述
した予測対象リスト１１０３、およびそれらの構成要素
が満たすべき特性を要求として記述した要求特性データ
１１０４を得る。

【００５０】ここで、図７は、予測対象リスト１１０３
の一例を示したものである。すなわち、図７の例では、
予測を行うべき運用保守対象分散システム１０内の構成
要素として、“ｓｖｒ１”と名付けられているサーバの
ＣＰＵ、メモリ、ディスク、および“ｃｌｉ１”、“ｃ
ｌｉ２”と名付けられているクライアントのＣＰＵ、メ
モリ、ディスク、および“ｓｖｒ１”と“ｃｌｉ１”を
結ぶネットワーク、および“ｓｖｒ１”と“ｃｌｉ２”
とを結ぶネットワークが指示されている。なお、予測対
象リスト１１０３に記述する内容および記述の方法は、
必ずしも上記の通りでなくとも良い。

【００５１】また、図８は、要求特性データ１１０４の
一例を示したものである。すなわち、図８の例では、予
測を行うべき運用保守対象分散システム１０内の構成要
素が満たしていなければならない特性として、“ｓｖｒ
１”と名付けられているサーバについて、そのＣＰＵの
最大負荷／平均負荷がどのようでなければならないか、
およびメモリの最大ページフォールト数／平均ページフ
ォールト数がどのようでなければならないか、およびデ
ィスクの許容量がどのようでなければならないかといっ
た情報が示されている。また、同様の内容が、“ｃｌｉ
１”、“ｃｌｉ２”と名付けられているクライアントに
ついても示されている。さらに、“ｓｖｒ１”と“ｃｌ
ｉ１”を結ぶネットワーク、および“ｓｖｒ１”と“ｃ
ｌｉ２”とを結ぶネットワークについて、それらの間を
流れる最大パケット数／平均パケット数がどのようでな
ければならないかが示されている。なお、この要求特性
データ１１０４に載せられるデータは、後述する業務仕
様管理手段１１１から得られるように構成されている。
また、要求特性データ１１０４に記述する内容および記
述の方法は、必ずしも上記の通りでなくとも良い。

【００５２】（予測データ）さらに、運用保守制御手段
１１０は、予測対象リスト１１０３の内容を前記予測手
段１１２に引き渡し、それぞれの分散システムの構成要
素の予測動向を、予測データ１１０５として得る。この
予測データ１１０５は、ある時系列なデータとして得ら
れる。

【００５３】図９は、予測データ１１０５の一例を示し
たものである。すなわち、予測が行われた運用保守分散
システム１０内の構成要素の予測動向として、一日単位
で各構成要素がどのように推移するかが示されている。
なお、予測データ１１０５に記述する内容、記述の方法
および予測の時間間隔／期限などは、必ずしも上記の通
りでなくとも良い。

【００５４】（判断部）さらに、運用保守制御手段１１
０は、判断部１１０６において、運用保守制御リスト１
１０２と要求特性データ１１０４と予測データ１１０５
の内容を比較することにより、管理者１３に通告すべき
運用保守対象リスト１１０７を作成する。

【００５５】ここで、前記判断部１１０６の動作につい
て、図１０乃至図１２に示したフローチャートに基づい
て説明する。まず、要求特性データ１１０４からデータ
を一つ取り出す（ステップ１００１）。例えば、図８に
示した要求特性データ１１０４の例では、「“ｓｖｒ
１”のＣＰＵについての平均負荷が０．１以下でなけれ
ばならない」といったデータを取り出す。次に、予測デ
ータ１１０５のうち、現在に最も近い予測時点を選び
（ステップ１００２）、予測データ１１０５から該当す
るデータを取り出す（ステップ１００３）。例えば、図
９に示した予測データ１１０５の例では、現在に最も近
い予測時点である翌日（＝１ｄａｙ）を選ぶ。そして、
その時点での予測値が、前記要求特性データ１１０４に
示された要求値を越えているか否かを判定し（ステップ
１００４）、越えている場合には、その構成要素を「問
題あり」として記録する（ステップ１００５）。例え
ば、図９に示した予測データ１１０５の翌日（＝１ｄａ
ｙ）の例では、“ｓｖｒ１”のＣＰＵについての平均負
荷は“０．１２”であり、図８に示された要求特性デー
タ１１０４の要求値である“０．１”を越えているの
で、その旨記録する。そして、要求を越えていたことが
わかった場合には、その時点をもってその構成要素の問
題発生時点とし、それ以降については、その構成要素に
ついては調べない。

【００５６】一方、要求を越えていなければ次の予測時
点に移り（ステップ１００６）、その予測時点における
予測値が、前記要求特性データ１１０４に示された要求
値を越えているか否かを判定し（ステップ１００４）、
越えている場合には、その構成要素を「問題あり」とし
て記録する（ステップ１００５）。そして、同様の処理
を予測データが尽きるまで調べる（ステップ１００
７）。例えば、図９に示した予測データ１１０５の場合
には、問題が発見されない限り、１００日後（＝１００
ｄａｙｓ）まで調べ続けられる。上記の処理を、要求特
性データ１１０４に示されたすべてのデータについて繰
り返す（ステップ１００８、ステップ１００９）。

【００５７】要求特性データ１１０４に示されたすべて
のデータについて、上記の処理が終了した後、判断部１
１０６においては、運用保守制御リスト１１０２から重
要業務を一つ取り出す（ステップ１０１０）。例えば、
図６に示した運用保守制御リスト１１０２の例では、重
要業務として「受注業務」が選ばれる。さらに、事前の
処理（ステップ１００１〜ステップ１００９）による記
録から、問題が発生する構成要素を一つ取り出す（ステ
ップ１０１１）。例えば、先の例では、「“ｓｖｒ１”
のＣＰＵ」が選ばれる。

【００５８】このとき、後述する業務仕様管理手段１１
１に問い合わせて、重要業務がその構成要素を含んでい
るか否かを判断する（ステップ１０１２）。そして、重
要業務がその構成要素を含んでいる場合には、その構成
要素に問題が発生する時点が、その重要業務を構成する
他の構成要素に問題が発生する時点より早いか否かを調
べ（ステップ１０１３）、それらのどれよりも早い発生
時点であれば、その構成要素を問題発生の原因とし、か
つ、その発生時点を重要業務の問題発生時点とし（ステ
ップ１０１４）、「どの重要業務に、いつ、何の問題が
発生するか」を、運用保守対象リスト１１０７に載せる
（ステップ１０１５）。例えば、先の例では、『重要業
務として選ばれた「受注業務」が、「“ｓｖｒ１”のＣ
ＰＵ」の平均負荷の増大により、翌日には問題を引き起
こす』といった内容が、運用保守対象リスト１１０７に
記述される。

【００５９】また、原因に対する対策を示すことができ
る場合には、合わせてその対策も運用保守対象リスト１
１０７に示される（ステップ１０１６、ステップ１０１
７）。このような対策を示すためには、様々な方法が考
えられるが、一つの方法としては、個々の構成要素毎
に、それが原因となった場合の対策についての情報を持
たせ、これを業務仕様管理手段１１１において直接管理
させる方法が考えられる。また、判断部１１０６内に判
断知識をルール化したものを置き、それを参照させる方
法なども考えられる。

【００６０】以上の対応付けを、事前の処理（ステップ
１００１〜ステップ１００９）による記録のすべてにつ
いて繰り返す（ステップ１０１８、ステップ１０１
９）。さらに、運用保守制御リスト１１０２に挙げられ
たすべての重要業務について、上記処理を繰り返す（ス
テップ１０２０、ステップ１０２１）。

【００６１】（運用保守対象リスト）次に、前記運用保
守対象リスト１１０７について説明する。すなわち、図
１３は、運用保守対象リスト１１０７の一例を示したも
のであるが、この例では、将来的に支障が出る業務とそ
の日時および原因、さらに運用保守が必要な分散システ
ム１０内の構成要素が指摘されており、これが管理者１
３に通告されることになる。

【００６２】管理者１３は、この運用保守対象リスト１
１０７を参照することによって、運用保守対象分散シス
テム１０に問題が発生する前にそれを検知し、運用保守
が必要な構成要素についてだけ、計画的に運用保守を実
施することができるようになる。さらに、エンドユーザ
１２は、運用保守対象リスト１１０７にしたがってなさ
れる管理者１３からのアナウンスによって、突然十分な
サービスを受けられなくなる状況を回避できるようにな
る。

【００６３】［３−２．運用保守制御手段における制御
の流れ］図１４は、運用保守制御手段１１０における制
御の流れを示したものである。すなわち、管理者１３
が、窓口１１００から、どの業務について運用保守を行
うかを入力することによって、運用保守制御手段１１０
による制御が開始される（ステップ１４１）。あるい
は、所定の日時／時刻を設定したタイマ１１０１によっ
て、運用保守制御手段１１０による制御が自動的に開始
される（ステップ１４２）。

【００６４】続いて、運用保守制御リスト１１０２に記
述された内容にしたがって、どの業務を運用保守の対象
とするかが決定され（ステップ１４３）、また、運用保
守制御リスト１１０２の内容をもとに、業務仕様管理手
段１１１に問い合わせることにより、運用保守の対象と
なり得る分散システムの構成要素を記述した予測対象リ
スト１１０３、およびそれらの構成要素が満たすべき特
性を要求として記述した要求特性データ１１０４が得ら
れる（ステップ１４４）。

【００６５】次に、予測手段１１２に予測を依頼するこ
とにより、それぞれの分散システムの構成要素の予測動
向が、予測データ１１０５として得られる（ステップ１
４５）。また、判断部１１０６において、運用保守制御
リスト１１０２と要求特性データ１１０４と予測データ
１１０５の内容が比較され（ステップ１４６）、運用保
守対象リスト１１０７が作成されて、管理者１３に通告
される（ステップ１４７）。

【００６６】［３−３．業務仕様管理手段の構成及び作
用］図１５は、業務仕様管理手段１１１の構成を示した
ものである。すなわち、業務仕様管理手段１１１は、そ
の内部に「業務」とその業務に関連した運用保守対象分
散システム１０の構成要素との関係を保持したデータベ
ース１１１０を保持している。また、このデータベース
１１１０では、業務１１１１、プロセス１１１２、テー
ブル１１１３、ノード１１１４、ＣＰＵ１１１５、メモ
リ１１１６、ディスク１１１７、ネットワーク１１１８
の各構成要素と、各構成要素間の関係が管理されてい
る。なお、図１５に示したデータベースにおいては、そ
れぞれの関係をエンティティリレーションシップ図を用
いて表している。また、ここでいう「ノード」とは、例
えば、一つのＩＰアドレスを持つような計算機のことを
意味している。

【００６７】次に、前記データベース１１１０をリレー
ショナルデータベースとして構築したときに、業務１１
１１やプロセス１１１２などがどのように格納されるか
について、図１６〜図２３を参照して説明する。

【００６８】すなわち、図１６には、「業務」について
記述したテーブル（Ａ）と、業務に関連する「プロセ
ス」を記述したテーブル（Ｂ）の２つが示されている。
そして、この２つのテーブルから、「ある業務がどのよ
うなプロセスから構築されているか」、また「その業務
がどれだけの時間で処理を終えなければならないか」に
ついての情報を得ることができる。

【００６９】また、図１７には、「プロセス」について
記述したテーブル（Ａ）と、プロセスが配置されている
「ノード」を記述したテーブル（Ｂ）と、プロセスが処
理の対象とする「テーブル」およびその配置先を記述し
たテーブル（Ｃ）の３つが示されている。そして、この
３つのテーブルから、「どのプロセスがどのノードで実
行され」、「どのノードにあるどのテーブルにアクセス
するか」、また「実行にあたって、どれだけの処理時間
とメモリを消費するか」についての情報を得ることがで
きる。なお、処理時間としては、仮定されたある処理性
能を有する標準的な計算機によって処理が実行された場
合に、必要とされる時間が表示されている。

【００７０】次に、図１８には、「テーブル」について
記述したテーブル（Ａ）と、テーブルが配置されている
「ノード」を記述したテーブル（Ｂ）の２つが示されて
いる。また、図１９には、「ノード」について記述した
テーブル（Ａ）と、ノードが保持しているＣＰＵ、メモ
リ、ディスク、ネットワークとの関連を記述したテーブ
ル（Ｂ）〜（Ｅ）の５つが示されている。さらに、図２
０には「ＣＰＵ」について記述したテーブルが記述さ
れ、図２１には「メモリ」について記述したテーブルが
記述されている。また、図２２には、「ディスク」につ
いて記述したテーブルが記述され、図２３には、「ネッ
トワーク」について記述したテーブルが記述されてい
る。

【００７１】そして、上記の図２０から図２３までに示
された各テーブルの値は、図１６で示された業務１１１
１のレスポンスタイムを満たすことができるように決定
されている。例えば、受注業務（業務ＩＤ＝１００）の
レスポンスタイムは３秒であることが要求されており
（図１６参照）、このとき受注業務によって使用される
受注プロセス（プロセスＩＤ＝１０１）の処理時間が３
００であり（図１７参照）、さらに、“ｓｖｒ１”のＣ
ＰＵについてみると、その性能は標準として設定された
ＣＰＵの２倍の性能であることから（図２０参照）、
『“ｓｖｒ１”のＣＰＵがそれぞれ最大負荷が２、平均
負荷が０．１を越えていては受注業務に要求されている
レスポンスタイムを実現できない』といった判断を管理
者１３が行うことで、値が決定される。

【００７２】なお、業務仕様管理手段１１１あるいはデ
ータベース１１１０が管理する、上記図１６から図２３
までに示されている構成要素の種類、管理方法について
は、必ずしも上記の通りでなくとも良い。

【００７３】［３−４．予測手段の構成及び作用］図２
４は、予測手段１１２の構成を示したものである。すな
わち、予測手段１１２は、その内部に、運用保守制御手
段１１０から引き継いだ予測対象リスト１１０３と、各
構成要素毎に適用される予測モデル１１２１、各構成要
素毎の過去の推移リスト１１２０、各構成要素毎の予測
データ１１２２、および運用保守制御手段１１０に引き
渡す予測データ１１０５を保持している。

【００７４】ここで、各構成要素毎に適用される予測モ
デル１１２１は、予測を行いたい構成要素の過去の推移
リスト１１２０と、他の構成要素の過去の推移リスト１
１２０とを組み合わせて使用される。例えば、ＣＰＵの
負荷予測を行うことを考えた場合、当然のことながらＣ
ＰＵ自身の過去の推移も参照するべきであるし、また、
メモリの影響を受けるのであれば、メモリについての過
去の推移を参照しても良い。さらに予測モデル１１２１
は、統計的な算術式によるものでも良いし、いわゆるニ
ューラルネットワークモデルに基づくような自己学習型
の予測手段をモデル化したものでも良い。

【００７５】そして、最終的に予測手段１１２は、各構
成要素毎の予測データ１１２２を編集してまとめ、予測
データ１１０５として運用保守制御手段１１０に引き渡
すように構成されている。

【００７６】（統計的な手段を用いた予測モデルの一
例）ここで、統計的な手段を用いた予測モデルの一例と
して、ディスク１０５の使用量の将来動向の予測を扱っ
てみる。なお、予測にあたっては、次の２つの前提を置
く。すなわち、（１）ディスク１０５の使用量は、ユー
ザ数と強い相関関係にある。（２）ユーザ数は、時間と
共に直線的に増加する。

【００７７】このような前提のもとでは、先にユーザ数
の変化を予測し、それを基にディスク１０５の使用量の
変化を予測することになる。まず、ある時刻ｘ_iのもと
でユーザ数がｙ_iであったとすると、前提（２）より、
両者の関係は次のように表わされる。

【００７８】

【数１】ｙ＝ａｘ＋ｂ …（１）上式における“ａ”および“ｂ”は、増加（あるいは減
少）傾向を表すための係数である。この“ａ”および
“ｂ”を最小２乗法によって求めるために、以下の連立
方程式を解く。

【００７９】

【数２】すると、解は、以下のようになる。

【００８０】

【数３】次に、以上によって求められたユーザ数ｙ_iを基に、デ
ィスク１０５の使用量ｚ_iを求める。前提（１）より、
両者の関係は以下のような回帰直線によって表わされ
る。なお、この回帰直線は、ｚのｙへの回帰直線とす
る。

【００８１】

【数４】上式において、σ_yはｙの標準偏差、σ_zはｚの標準偏
差、ρ_yzはｙとｚの相関係数を表し、ｙの平均値はｙの
上にバーを付し、ｚの平均値はｚの上にバーを付して表
している。

【００８２】以上に示した一連の式（１）から式（４）
が予測モデルとして機能することによって、ディスク１
０５の使用量の将来動向を予測することが可能となる。

【００８３】（自己学習的な手段を用いた予測モデルの
一例）次に、自己学習的な手段を用いた予測モデルの一
例として、ネットワーク１０６の負荷の将来動向の予測
を扱ってみる。なお、ここでは自己学習型の予測手段と
して、図２５に示すような多層型ニューラルネットワー
ク３０を採用するものとする。また、予測にあたって、
ネットワーク１０６の負荷は、自己の過去の推移から予
測可能であるという前提を置く。さらに、このニューラ
ルネットワーク３０を構成するニューロン３２は、図２
６に示すようなシグモイド関数３１と呼ばれる非線型モ
デルによって表現されるものとする。

【００８４】まず、本予測手段１１２を含んだ運用保守
支援装置１１の利用に先立って準備を行う。すなわち、
ネットワーク１０６の負荷の過去の推移を教師値とし
て、対応する入力層３３の値３４（＝ｘ）およびネット
ワークの重みに基づく出力層３７の値３８（＝ｚ）との
誤差が最小になるように、ニューロン間の重み係数３９
（＝ｗ）を更新しておく。

【００８５】なお、この学習のためには、バックプロパ
ゲーション法が用いられる。また、予測を行うには、予
測を行おうとする時点および、それより過去の時点のネ
ットワーク１０６の負荷からなる値のリストｘ＝
（ｘ₁，ｘ₂，ｘ₃，．．．．，ｘ_n）を入力として、
以下の式（５）から式（８）によってネットワークの出
力値３８（＝ｚ）が求められる。

【００８６】

【数５】

【数６】

【数７】

【数８】なお、入力値３４や中間値３６、あるいは出力値３８
は、実際の値から正規化／逆正規化して扱う必要があ
る。すなわち、ネットワーク１０６の負荷の場合、実際
に流れるパケットの量を表す数百や数千といった値を正
規化して０近傍の値に変換してから入力値３４とした
り、０から１の間までの値として出力された出力値も逆
正規化して実際のパケット量を表すようにしてやる必要
がある。この正規化／逆正規化は、ニューラルネットワ
ークの反応性を高めるという意味からも必要なものであ
る。

【００８７】以上に示した多層型ニューラルネットワー
クが予測モデルとして機能することによって、ネットワ
ーク１０６の負荷の将来動向を予測することが可能とな
る。また、このような自己学習型の予測モデルを採用す
ることで、どの時間帯に業務が集中するかといった情報
を明示的に示さなくても、それらの情報を考慮できるよ
うになる。

【００８８】［４．本実施形態の運用保守支援装置の効
果］上述したように、本実施形態の運用保守支援装置に
おいては、この装置を構成する上記各手段によって、
「どの業務を運用保守の対象とすべきか」、「その業務
に関連する分散システム内の構成要素は何か」、「その
構成要素が満たすべき特性はどのようなものか」、「そ
の構成要素の将来的な動向はどのようなものか」といっ
た観点で、分散システムの運用保守を支援する処理が進
められる。

【００８９】その結果、重要な業務に関連した運用保守
対象を優先して運用保守することができ、また、運用保
守に対して優先度をつけることができるので、無駄な運
用保守コストの発生を抑えることができる。さらに、運
用保守を行うための分析が適切に行えるので、有効な運
用保守計画を立てることができる。

【００９０】

【実施例】以下に、より具体的な実施例を用いて、運用
保守が想定される幾つかの場面において、本発明が提案
する運用保守支援装置および方法によって得られる作用
・効果について説明する。

【００９１】まず始めの例として、ＷｏｒｌｄＷｉｄ
ｅＷｅｂを利用した情報提供を行うための分散システ
ムを取り上げる。図２７は、この分散システムの概要を
示したものである。すなわち、図２７において、分散シ
ステム５０では、ネットワーク５３に接続された多数の
クライアント５２が、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ
ＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）サーバ５１ａ
および５１ｂへアクセスする。また、この分散システム
５０のエンドユーザ５４は、この分散システム５０を利
用して、情報検索を行うものとする。

【００９２】ここで、情報検索には２種類あり、随時頻
繁に行われ、結果も数秒で返ってこなければならない検
索処理５０ａと、不定期でそれほど頻繁でもなく、結果
も翌日返ってくればよい検索処理５０ｂがあるものとす
る。なお、想定している状況では、クライアント５２の
台数が、なおも日に日に増加している最中であるとす
る。

【００９３】これまでの運用保守技術では、クライアン
ト５２の台数の増加に伴って、分散システム５０内のす
べての構成要素の増強を検討しなければならず、その結
果、実施する運用保守も必ずしも適切なものであるとい
う保証はなかった。

【００９４】しかしながら、本発明による運用保守技術
では、管理者５５が運用保守支援装置から運用保守支援
を受けることにより、業務の「意味」を考慮した適切な
運用保守を行うことができるようになる。すなわち、上
述した図１から図２４にしたがって説明すると、管理者
５５が任意の時点で運用保守支援を受けるために窓口１
１００を介するか、あるいはタイマ１１０１に設定され
た日時になるかのいずれかによって、運用保守支援装置
１１が起動される。この運用保守支援装置１１内の運用
保守制御手段１１０は、窓口１１００あるいは運用保守
制御リスト１１０２から得られる情報（業務や、それに
対する付随情報）により、運用保守の対象となる業務を
特定し、業務仕様管理手段１１１に運用保守の必要があ
るかも知れない分散システム５０内の構成要素の選択を
依頼する。

【００９５】続いて、業務仕様管理手段１１１は、指定
された業務と、業務仕様管理手段１１１内で管理されて
いるデータベース１１１０内の情報と照らし合わせるこ
とで、分散システム５０内において運用保守が必要にな
るかもしれない構成要素のみを選びだす。本例において
は、重要な業務であると考えられる検索処理５０ａに関
連した構成要素のみが選びだされ、検索処理５０ｂだけ
に関連した構成要素は選びだされない。

【００９６】この結果、運用保守制御手段１１０は、検
索処理５０ａが行われるＨＴＴＰサーバ５１ａについて
記載した予測対象リスト１１０３と、「検索処理５０ａ
は数秒で処理を終えなければならない」という要求特性
データ１１０４を得る。さらに、運用保守制御手段１１
０は、予測手段１１２に対して、ＨＴＴＰサーバ５１ａ
に関して、それに接続されるクライアント５２の増加に
関連したＣＰＵやメモリ、あるいはディスク、ネットワ
ークなどの構成要素の将来動向を、それぞれの過去の推
移状況とモデルに照らし合わせて予測するよう依頼す
る。

【００９７】この予測の結果は、予測データ１１０５と
して運用保守制御手段１１０に渡され、判断部１１０６
が運用保守制御リスト１１０２および要求特性データ１
１０４と照らし合わせることで、運用保守上問題が発生
する箇所とその時期を判断し、運用保守対象リスト１１
０７としてまとめ、最終的に管理者５５に提示される。

【００９８】［５．他の実施形態］本発明は、上述した
実施形態に限定されるものではなく、運用保守支援装置
を運用保守制御手段１１０、業務仕様管理手段１１１及
び監視手段１１３のみから構成することも可能である。
なお、この場合は、分散システムのエンドユーザがもっ
とも重要であると考えている業務に関連した運用保守対
象が優先して運用保守され、かつ、重要な業務に関連し
た運用保守対象が重点的に運用保守されることで、無駄
な運用保守コストの発生を抑えることができる。

【００９９】また、前記運用保守制御手段１１０に設け
られる窓口において、運用保守すべき業務の重要度を自
動的に設定できるように構成することもできる。すなわ
ち、図２８に示したように、窓口１１００には、保守指
示履歴データベース１１０００と閾値１１００１が備え
られている。なお、この保守指示履歴データベース１１
０００は、窓口１１００から管理者１３が運用保守対象
業務及び業務投入ノード等を明示するたびに、その業務
が明示されたのは何回目か、あるいはその業務に対して
そのノードが指定されたのは何回目なのかといった情報
を格納するものである。また、閾値１１００１は、窓口
１１００に予め設定されており、業務あるいは業務とノ
ードの組み合わせについての保守指示回数がこの値を越
えた場合には、運用保守制御リスト１１０２にその業務
を重要業務として記載すべきか否かの検討が必要である
との判断を下す基準となるものである。

【０１００】そして、この判断の結果、その保守指示回
数が閾値１１００１を越えた業務を重要業務として強制
的に運用保守制御リスト１１０２に追加しても良いし、
図２９に示したように、ダイアログボックスなどのユー
ザインターフェースを提供することにより、管理者１３
の了解を得たあとで運用保守制御リスト１１０２に追加
しても良い。

【０１０１】このように構成することにより、管理者１
３が当初はあまり重要でないと考えていた業務を見逃す
危険性を低く抑えることができるようになる。なお、前
記保守指示履歴データベース１１０００に格納する内容
は、上述したものに限定されるものではなく、また、閾
値１１００１についても、すべての業務あるいは業務と
ノードの組み合わせについて同じ値に設定しても、異な
る値に設定しても良い。

【０１０２】

【発明の効果】以上説明したように本発明によれば、分
散システム上に実装される業務の「意味」を意識するこ
とによって、分散システムのエンドユーザがもっとも重
要であると考えている業務に関連した運用保守対象が優
先して運用保守され、かつ、重要な業務に関連した運用
保守対象が重点的に運用保守されることで、無駄な運用
保守コストの発生を抑えることができ、かつ、運用保守
を行うための分析が適切に行え、有効な運用保守計画を
立てることができるようになる。

【図面の簡単な説明】

【図１】本発明による運用保守支援の全体像

【図２】運用保守対象分散システムの構成図

【図３】運用保守支援装置の構成図

【図４】運用保守制御手段の構成図

【図５】「窓口」で行われる入力処理を受け付ける画面
の一例を示す図

【図６】運用保守制御リストの一例を示す図

【図７】予測対象リストの一例を示す図

【図８】要求特性データの一例を示す図

【図９】予測データの一例を示す図

【図１０】判断部における制御の流れの前段部を示すフ
ローチャート

【図１１】判断部における制御の流れの中段部を示すフ
ローチャート

【図１２】判断部における制御の流れの後段部を示すフ
ローチャート

【図１３】運用保守対象リストの一例を示す図

【図１４】運用保守制御手段の制御の流れを示すフロー
チャート

【図１５】業務仕様管理手段の構成図

【図１６】業務の格納方法の一例を示す図

【図１７】プロセスの格納方法の一例を示す図

【図１８】テーブルの格納方法の一例を示す図

【図１９】ノードの格納方法の一例を示す図

【図２０】ＣＰＵの格納方法の一例を示す図

【図２１】メモリの格納方法の一例を示す図

【図２２】ディスクの格納方法の一例を示す図

【図２３】ネットワークの格納方法の一例を示す図

【図２４】予測手段の構成図

【図２５】多層型ニューラルネットワークの一例を示す
図

【図２６】ニューロンの一例を示す図

【図２７】本発明の一実施例を示す図

【図２８】本発明の他の実施形態における窓口の構成を
示す図

【図２９】本発明の他の実施形態における運用保守制御
リストの更新確認画面の一例を示す図

Claims

【特許請求の範囲】

【請求項１】複数の計算機およびその周辺機器をネッ
トワークを介して構成した分散システムに対する運用保
守支援装置であって、前記分散システムの運用保守支援を開始し、さらにその
後に続く運用保守支援動作を制御する運用保守制御手段
と、前記分散システムの構成要素とその分散システムに実装
される業務アプリケーションとの間の対応関係を所定の
仕様として管理し、前記運用保守制御手段からの問い合
わせに応じて、所定の業務情報及び所定の構成要素情報
の少なくともいずれか一方を提供する業務仕様管理手段
と、前記分散システムから、運用保守支援のために必要な運
用保守情報を収集する監視手段とを備えたことを特徴と
する分散システム運用保守支援装置。
【請求項２】複数の計算機およびその周辺機器をネッ
トワークを介して構成した分散システムに対する運用保
守支援装置であって、前記分散システムの運用保守支援を開始し、さらにその
後に続く運用保守支援動作を制御する運用保守制御手段
と、前記分散システムの構成要素とその分散システムに実装
される業務アプリケーションとの間の対応関係を所定の
仕様として管理し、前記運用保守制御手段からの問い合
わせに応じて、所定の業務情報及び所定の構成要素情報
の少なくともいずれか一方を提供する業務仕様管理手段
と、前記分散システムの構成要素の内、運用保守制御手段に
より指示された構成要素の将来的な動向を予測する予測
手段と、前記分散システムから、運用保守支援のために必要な運
用保守情報を収集する監視手段とを備えたことを特徴と
する分散システム運用保守支援装置。
【請求項３】前記予測手段が、前記監視手段によって
収集された運用保守情報と、予測に当てはめられる予測
モデルとに基づいて、分散システムの構成要素の将来的
な動向を予測するように構成されていることを特徴とす
る請求項２に記載の分散システム運用保守支援装置。
【請求項４】前記運用保守制御手段が、運用保守対象
とすべき業務の重要度を自動的に設定するように構成さ
れていることを特徴とする請求項１乃至請求項３のいず
れか一に記載の分散システム運用保守支援装置。
【請求項５】複数の計算機およびその周辺機器をネッ
トワークを介して構成した分散システムに対する運用保
守支援方法であって、前記分散システムの運用保守支援を開始し、さらにその
後に続く運用保守支援動作を制御する運用保守制御ステ
ップと、前記分散システムの構成要素とその分散システムに実装
される業務アプリケーションとの間の対応関係を所定の
仕様として管理し、前記運用保守制御ステップにおける
問い合わせに応じて、所定の業務情報及び所定の構成要
素情報の少なくともいずれか一方を提供する業務仕様管
理ステップと、前記分散システムから、運用保守支援のために必要な運
用保守情報を収集する監視ステップとを含むことを特徴
とする分散システム運用保守支援方法。
【請求項６】複数の計算機およびその周辺機器をネッ
トワークを介して構成した分散システムに対する運用保
守支援方法であって、前記分散システムの運用保守支援を開始し、さらにその
後に続く運用保守支援動作を制御する運用保守制御ステ
ップと、前記分散システムの構成要素とその分散システムに実装
される業務アプリケーションとの間の対応関係を所定の
仕様として管理し、前記運用保守制御ステップにおける
問い合わせに応じて、所定の業務情報及び所定の構成要
素情報の少なくともいずれか一方を提供する業務仕様管
理ステップと、前記分散システムの構成要素の内、運用保守制御ステッ
プにおいて指示された構成要素の将来的な動向を予測す
る予測ステップと、前記分散システムから、運用保守支援のために必要な運
用保守情報を収集する監視ステップとを含むことを特徴
とする分散システム運用保守支援方法。
【請求項７】前記予測ステップが、前記監視ステップ
によって収集された運用保守情報と、予測に当てはめら
れる予測モデルとに基づいて、分散システムの構成要素
の将来的な動向を予測するように構成されていることを
特徴とする請求項６に記載の分散システム運用保守支援
方法。
【請求項８】前記運用保守制御ステップが、運用保守
対象とすべき業務の重要度を自動的に設定するように構
成されていることを特徴とする請求項５乃至請求項７の
いずれか一に記載の分散システム運用保守支援方法。