JP2016015111A - 評価プログラム、評価方法、および評価装置 - Google Patents

Abstract

【課題】過去に実施された対処への評価の信頼性を向上させる。
【解決手段】算出手段１１は、複数のシステムそれぞれについての非機能要件に関する値に基づいて、複数のシステムそれぞれで各々の対処を実施したときの、当該対処を実施したシステムが安定運用できている度合いを示す成熟度を算出する。評価手段１２は、複数のシステム１ａ，１ｂ，１ｃそれぞれで実施された各々の対処について、特定のシステムと当該対処が実施されたシステムとの構成の類似度、当該対処の実施時期、当該対処による効果、および実施時期における成熟度に基づき、特定のシステム２に対する有用度を評価する。
【選択図】図１

Description

本発明は、評価プログラム、評価方法、および評価装置に関する。

マシンリソースを必要なときに必要なだけ調達することができるクラウドコンピューティングが知られている。クラウドコンピューティングでは、リソースを複数人で共有することが行われる。

また、クラウドコンピューティングでは、テナント（例えば、クラウドユーザごとなどに設けられるシステム）ごとに、個別に自動運用をする運用形態を採ることができる。例えば、予め各種の対処方法が作成され、作成された対処方法を用いて、システムが自動運用される。ここで、対処方法とは、例えば自動運用するための各種のルールであり、どのような障害やエラー発生などの現象（イベント）に対して、どのように対処を行うかを記述したものである。

なお、障害などへの対処結果を活用する技術として、例えば、トラブル処置の効果を評価値として算出するとともに、類似装置間での共有参照を可能とする技術がある。
また、障害対処ルールの適用評価値を算出し、算出した適用評価値と自己の障害復旧装置の適用基準値を比較することで、有効なルールを取捨選択する技術がある。

さらに、自律運用管理に向けたポリシリファイン手法として、ポリシとシステム構成の相関を管理するデータモデルを用いたシステム構成の類似性判定によって、流用可能なポリシか否かを判定する技術がある。

障害などの対処の結果を活用する場合、システムに障害があるのかどうかを正しく判断することも重要である。そこで、例えば将来の障害検出における判断基準を付与するときのシステム管理者にとっての負担を軽減する技術が考えられている。また原因の特定方法が必ずしも明らかではない種々の異常を予知することのできる異常状態検知装置も考えられている。

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

大野允裕、加藤清志、平池龍一、「自律運用管理に向けた障害対処ポリシの適用制御/流用手法」、電子情報通信学会技術研究報告、2005年07月29日、第105巻、第227号、p.13-18

特定のシステム用の対処方法を作成する際には、他の多くのシステムに実際に実施した対処を参考にして作成するのが効率的である。その場合、過去に多数行われた対処それぞれについて、特定のシステムに対して有用であるかどうかを適切に評価することで、特定のシステムに有用な対処方法を作成することができる。

過去に行われた対処の評価基準の１つとして、どのようなタイミングで実施された対処なのかに関する基準を用いることができる。例えば、システムの運用開始（リリース）直後は重大な障害に対する有用な対処を実施することが多く、また直近に実施された対処は、最新の技術を用いた有用な対処であることが多い。そこで、対処を実施した時期と、運用開始時期または現在との差が小さいほど、その対処の有用性を示す値（有用度）を高くすることで、評価の信頼性を向上させることができる。

ここで、システムに実施した対処の実施時期の違いに応じて、有用度にどの程度の差を設けるかについて、いずれのシステムに実施した対処であっても一律に決めておくこともできる。しかし、そのように一律に決めておくことが不適切な場合がある。

例えば、十分な開発・テスト期間を取って運用開始されたシステムと、短期間で開発・テストを行って運用開始されたシステムとでは、システムの運用を開始してから安定運用に入るまでの期間（成熟する速度）が異なる。そのため、システムの運用開始から所定期間経過後に実施した対処に関し、そのシステムが高速に成熟していれば、安定運用後の実施となるが、そのシステムが時間をかけて成熟していれば、安定運用前の実施となるような場合がある。安定運用前の対処と安定運用後の対処とでは、その対処の重要性も異なっており、それらの対処に対して有用度を同じに評価したのでは、評価の信頼性が損なわれてしまう。

１つの側面では、本発明は、過去に実施された対処への評価の信頼性を向上させることを目的とする。

１つの案では、複数のシステムにおいて実施された対処の、特定のシステムに対する有用度を評価する評価プログラムが提供される。この評価プログラムに基づいてコンピュータは、まず複数のシステムそれぞれについての非機能要件に関する値に基づいて、複数のシステムそれぞれで各々の対処を実施したときの、その対処を実施したシステムが安定運用できている度合いを示す成熟度を算出する。次にコンピュータは、複数のシステムそれぞれで実施された各々の対処について、特定のシステムとその対処が実施されたシステムとの構成の類似度、その対処の実施時期、その対処による効果、および実施時期における成熟度に基づき、特定のシステムに対する有用度を評価する。

１案によれば、過去に実施された対処への評価の信頼性が向上する。

第１の実施の形態に係る装置の機能構成例を示す図である。 第２の実施の形態のシステム構成例を示す図である。 第２の実施の形態に用いるサーバのハードウェアの一構成例を示す図である。 対処グラフの一例を示す図である。 開発手法によるシステムの成熟度の違いを示す図である。 成熟度の違いによる処理の実施時期とタイミング評価値との関係の変化を示す図である。 第２の実施の形態を実現するための機能を示すブロック図である。 対処履歴ＤＢのデータ構造の一例を示す図である。 システム構成情報記憶部のデータ構造の一例を示す図である。 対処方法記憶部のデータ構造の一例を示す図である。 障害履歴記憶部のデータ構造の一例を示す図である。 対処方法の作成手順を示すフローチャートである。 成熟度関数算出処理の手順の一例を示すフローチャートである。 有用度算出処理の手順の一例を示すフローチャートである。 採用適否判定処理の手順の一例を示すフローチャートである。 システムの追加例を示す図である。 対象システムの構成情報の登録例を示す図である。 標本とするシステムの抽出例を示す図である。 累積障害度数分布の一例を示す図である。 成熟度関数の生成例を示す図である。 タイミング評価値の計算例を示す図である。 効果の有無の取得例を示す図である。 対処グラフの作成例を示す図である。 運用開始からの経過時間に応じた成熟度の計算例を示す図である。 スケールアウトの例を示す図である。 システムが安定しているかどうかの第１の判定手法を示す図である。 システムが安定しているかどうかの第２の判定手法を示す図である。 第２の判定方法における各サーバの安定・不安定の判断例を示す図である。 状態ベクトルの例を示す図である。 システムの安定・不安定の判断例を示す図である。 システムが安定しているかどうかの第３の判定手法を示す図である。 第３の実施の形態のサーバの機能を示すブロック図である。 監視履歴記憶部のデータ構造の一例を示す図である。 成熟度関数生成処理の手順の一例を示すフローチャートである。 安定期間長の算出例を示す図である。 安定期間長と成熟度との関係を示す図である。 日ごとの成熟度の算出例を示す図である。 成熟度の変化例を示す図である。 第３の実施の形態におけるタイミング評価値の計算例を示す図である。

以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
まず、第１の実施の形態について説明する。第１の実施の形態は、対処を実施したシステムの成熟度を加味して、その対処を他のシステムに実施することの有用度を算出することで、有用度の信頼性を向上させるものである。

図１は、第１の実施の形態に係る装置の機能構成例を示す図である。評価装置１０は、既存システム群１に含まれるシステム１ａ，１ｂ，１ｃに実施した対処が、別のシステム２に有用かどうかを示す有用度を算出することで、その対処が有用かどうかを評価する。評価装置１０は、算出手段１１、および評価手段１２を有する。

算出手段１１は、複数のシステム１ａ，１ｂ，１ｃそれぞれについての非機能要件に関する値に基づいて、複数のシステム１ａ，１ｂ，１ｃそれぞれで各々の対処を実施したときの、対処を実施したシステムが安定運用できている度合いを示す成熟度を算出する。非機能要件は、システムに求められる機能面以外の要件である。例えば非機能要件には、信頼性、効率性などに関する要件が含まれる。非機能要件に関する値には、例えば障害の発生状況に関する値や、システムの負荷に関する値が含まれる。また運用中のシステムを監視し、非機能要件に関する値として、システムの動作状態を示す値を取得してもよい。

算出手段１１は、例えば、生成手段１１ａと成熟度算出手段１１ｂとを含む。
生成手段１１ａは、複数のシステム１ａ，１ｂ，１ｃそれぞれについて、システムの稼働開始からの障害の累積発生状況に基づいて、システムの運用期間と、システムの成熟度との関係を示す関係情報を生成する。例えば生成手段１１ａは、システムの運用期間が長いほど成熟度が高くなるような関係情報を生成する。

関係情報は、関数式で表すことができる。その場合、生成手段１１ａは、システムの障害発生状況の時間変化に基づいて、システムの運用期間の長さに応じた成熟度合い（成熟速度）を示す成熟度係数を求め、定数として成熟度係数を設定した関数式を生成する。成熟度係数としては、例えば、システムに対する障害発生数の累積値を所定間隔で求め、運用期間の長さに応じた該累積値の増加度合いを示す値が用いられる。

例えば生成手段１１ａは、既存システム群１に含まれるシステム１ａ，１ｂ，１ｃそれぞれの障害発生状況を示す障害件数情報３を参照する。障害件数情報３には、システムの運用期間ごとに、それまでにシステムで発生した障害の件数（累積障害件数）が設定されている。生成手段１１ａは、障害件数情報３に基づいて、システムが安定運用に入った時期（十分に成熟した時期）を判断する。例えば累積障害件数がほとんど増加しなくなれば、成熟したものと判断できる。図１の例では、運用期間が２５日で成熟したものとする。生成手段１１ａは、成熟したときの累積障害件数を、所定の成熟度に決定し、その運用期間と累積障害件数との関係を例えば一次関数で表す。関係情報を一次関数で表す場合、生成手段１１ａは、障害件数情報３に基づいて、１次関数の傾きなどの係数を、成熟度係数として求めることになる。

成熟度算出手段１１ｂは、複数のシステム１ａ，１ｂ，１ｃそれぞれで実施された各々の対処について、その対処を実施したシステムについて求められた関係情報に基づいて、その対処を実施したときのシステムの運用期間に対応する成熟度を算出する。例えば生成手段１１ａにおいて、運用期間と成熟度との関係を示す関数式が生成された場合、成熟度算出手段１１ｂは、その関数式に運用期間を代入することで成熟度を得る。

運用期間は、例えば、対処を実施したシステム１ａの稼働開始日時と、その対処に関する対処履歴４に含まれる対処日時とに基づいて算出できる。すなわち成熟度算出手段１１ｂは、対処日時から稼働開始日時を減算した値を、運用期間とする。なお対処履歴には、対処日時以外に、対処したシステムの識別子、対処の識別子、対処の結果などが含まれる。対処の結果には、例えば対処の効果があった場合「１」が設定され、対処の効果がなかった場合「０」が設定される。

評価手段１２は、特定のシステム２と、対処が実施されたシステム１ａとの構成の類似度、その対処の実施時期、その対処による効果、およびシステム１ａのその対処の実施時期における成熟度を用いて、システム２に対する有用度を算出する。評価手段１２は、対処が有用かどうかを、算出した有用度により評価することもできる。例えば評価手段１２は、対処の時期が運用開始時または現在のいずれかに近いほど、有用度を高く評価する。その際、評価手段１２は、対処が実施されたシステムの成熟度が高いほど、対処の時期が運用開始時または現在のいずれかへの近さによる有用度の差を大きくする。

例えば評価手段１２は、成熟度と対処の実施時期とを変数とする式を用いて、タイミング評価値を計算する。このタイミング評価値を求める式では、成熟度が低ければ、対処の実施時期に関し、全期間を通じてタイミング評価値が高い値となる。またタイミング評価値を求める式では、成熟度が高ければ、対処の実施時期が運用開始直後と直近の期間だけ、タイミング評価値は高い値となり、対処の実施時期がその他の期間であれば、タイミング評価値は低い値となる。

評価手段１２は、このようにして求めたタイミング評価値を用いて、有用度を計算する。例えば評価手段１２は、対処を実施したシステム１ａと、その対処の実施の検討対象であるシステム２との構成の類似度を算出する。そして評価手段１２は、類似度とタイミング評価値と対処の結果とを乗算した値を、有用度とする。評価手段１２は、対処に対して求めた有用度を、例えば所定の閾値と比較し、その対処が有用かどうかを判定する。

このような評価装置１０は、例えば既存システム群１のいずれかのシステムで発生した障害に対して実施された対処が、新たに作成するシステム２で有用かどうかの評価指示に応じて、評価を開始する。評価が開始されると、まず生成手段１１ａにより、各システム１ａ，１ｂ，１ｃそれぞれに関して、運用期間と成熟度との関係を示す関係情報が生成される。次に成熟度算出手段１１ｂにより、各システム１ａ，１ｂ，１ｃそれぞれに対して実施された対処ごとに、その対処を実施したときの、対処を実施したシステムの成熟度が算出される。そして評価手段１２により、システムの成熟度を加味した各対処の有用度が算出され、その有用度に応じて、その対処がシステム２に対して有用かどうかが評価される。

このような評価装置１０によれば、処理の有用度の計算に、その処理を実施したときのシステムの成熟度が反映されているため、有用度を用いた評価の信頼性が向上する。
例えば、システムの成熟度が低いほど全体を通じて高く評価することで、運用開始からの経過時間が短い、もしくは、利用実績の少ないシステムほど、開発から稼働後を通じて実施された対処が総じて重要になるように評価することができる。また成熟度が高いほど運用開始直後および直近の対処を高く評価し、その他のタイミングでの対処の評価を下げることで、より重要な評価のみを抽出できる。例えば安定運用されているシステムであっても、運用開始直後は重大な障害が発生しやすいため、その時期に実施した対処は重要であると考えられる。また安定運用されているシステムにおいて直近に実施された対処は、重大な脆弱性の解消のような重要な対処が含まれるものと考えられる。

他方、安定運用されているシステムの運用開始直後でも直近でもない期間に行われた対処は、その後の別の対処で不要となっている場合が多々あるため、重要度は高くない。例えばあるバージョンのソフトウェアの不具合に対する対処が過去に行われていても、そのソフトウェアのバージョンアップが行われた場合、バージョンアップ前の対処は不要となる。

またシステムの過去の障害の発生状況から、運用期間と成熟度との関係情報を作成するため、システムごとの開発・運用期間の違いを考慮した、適切な成熟度が算出可能である。

なお図１に示す例では、非機能要件に関する値として累積障害件数を用い、累積障害件数に基づいて成熟度を算出しているが、非機能要件に関する値として、システムを監視することで取得した、システムの動作状態を示す値を用いることもできる。システムの動作状態を示す値としては、ＣＰＵ使用率、メモリ使用率、エラーログの数、バグ修正数などである。

算出手段１１は、システムの動作状態を示す値に基づいて、例えば、単位期間（例えば１日）ごとの当該システムの動作の安定性を判定する。そして算出手段１１は、対処の実施時までの所定期間内の各単位期間のシステムの安定性に基づいて、システムの成熟度を算出する。このように対処の実施時までの所定期間内の単位期間ごとのシステムの安定性に基づいて成熟度を算出することで、システムの運用期間と成熟度との相関関係が低い場合であっても、正しい成熟度を算出することができる。

なお、生成手段１１ａ、成熟度算出手段１１ｂ、および評価手段１２は、例えば評価装置１０が有するプロセッサにより実現することができる。また、図１に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。

〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、クラウドコンピューティングシステム（以下、クラウドシステム）において構築したテナントごとのシステムに対して実施した対処から、新たに作成するシステムに有用な対処を抽出するものである。

図２は、第２の実施の形態のシステム構成例を示す図である。ネットワーク２０を介して、サーバ１００、データベース（ＤＢ）サーバ２００、クラウドシステム３００、および端末装置４００が接続されている。サーバ１００は、クラウドシステム３００内で構築されたシステムに対して実施した対処について、新たに導入するシステムへの有用度を評価する。ＤＢサーバ２００は、クラウドシステム３００内で構築されたシステムに対して実施した対処の履歴（対処履歴）を記憶、および管理する。

クラウドシステム３００は、内部に、複数のテナントそれぞれに対応するシステムを構築する。テナントごとのシステムを構築するため、クラウドシステム３００は、テナント用運用管理サーバ３１０、複数のアプリケーションサーバ３２０、およびＤＢサーバ３３０を有している。

テナント用運用管理サーバ３１０は、例えばクラウドシステム３００を利用するユーザごとの既存システムの運用形態（テナント情報）、運用状況、運用履歴などを管理する。テナント用運用管理サーバ３１０は、端末装置４００などから新システムの配備依頼を受け取ると新システムの構成を決定することもできる。アプリケーションサーバ３２０は、例えば端末装置４００からの要求に応じて、所定のアプリケーションソフトウェアを用いて対応する処理を実行する。ＤＢサーバ３３０は、クラウドシステム３００上で実行された実行履歴や入力データ、処理実行結果などの各種データを記憶する。

端末装置４００は、システム全体又は各テナントなどを管理する管理者が使用するコンピュータである。端末装置４００は、例えばブラウザ機能やコマンドラインなどを用いて、サーバ１００やクラウドシステム３００に新システムの構成情報を送信し、新システムに対する運用対処方法の作成を行わせる。端末装置４００としては、タブレット端末、スマートフォンなどの情報通信端末を用いることもできる。

次にサーバ１００のハードウェア構成について説明する。
図３は、第２の実施の形態に用いるサーバのハードウェアの一構成例を示す図である。サーバ１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。

メモリ１０２は、サーバ１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に必要な各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。

バス１０９に接続されている周辺機器としては、ＨＤＤ（Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。

ＨＤＤ１０３は、内蔵したディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、サーバ１００の補助記憶装置として使用される。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、補助記憶装置としては、フラッシュメモリなどの不揮発性の半導体記憶装置を使用することもできる。

グラフィック処理装置１０４には、モニタ２１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置などがある。

入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。

機器接続インタフェース１０７は、サーバ１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。

ネットワークインタフェース１０８は、ネットワーク２０に接続されている。ネットワークインタフェース１０８は、ネットワーク２０を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。

以上のようなハードウェア構成によって、第２の実施の形態の処理機能を実現することができる。なお図３には、代表としてサーバ１００のハードウェア構成例を示したが、ＤＢサーバ２００、テナント用運用管理サーバ３１０、アプリケーションサーバ３２０、ＤＢサーバ３３０、および端末装置４００も、サーバ１００と同様のハードウェアで実現できる。また、第１の実施の形態に示した評価装置１０も、図３に示したサーバ１００と同様のハードウェアにより実現することができる。

サーバ１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。サーバ１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、サーバ１００に実行させるプログラムをＨＤＤ１０３に格納しておくことができる。プロセッサ１０１は、ＨＤＤ１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。またサーバ１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ＨＤＤ１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。

このような構成のシステムにおいて、クラウドシステム３００内にテナントごとのシステムが稼働する。クラウドシステム３００内に構築されたテナントごとのシステムは、可能な限り自動運用される。システムの自動運用を実現するために、障害発生時の対処方法が、予め用意される。対処方法を用意しておくことで、システムの自動運用を促進することができる。対処方法は、例えば対処グラフで表すことができる。

図４は、対処グラフの一例を示す図である。対処グラフ３１，３２，３３，・・・は、例えばアプリケーションサーバで実行されるアプリケーションソフトウェアごとに生成される。

対処グラフ３１，３２，３３，・・・は、ノード（矩形または円形の図形）とエッジ（ノード間を接続する矢印）で構成される。円形で示したノードが開始ノードである。開始ノードからは、障害を示すノードが接続されている。障害のノードの先には、障害発生時のシステムの状況を示すノードがエッジで接続されている。そして、最後尾には、障害発生時の対処を示すノードが接続されている。対処を示すノードには、アクションノードと質問ノードとがある。アクションノードは、障害を除去するための対処を直接的に示している。質問ノードは、障害の原因を追及するための、管理者への確認事項が示されている。

クラウドシステム３００内のシステムの運用中に障害が発生すると、例えばテナント用運用管理サーバ３１０が、障害が発生したアプリケーション用の対処グラフを参照し、そのとき観測されているイベントに従って、開始ノードからノードを辿っていく。そしてテナント用運用管理サーバ３１０は、終端のノードに示された対処を実行する。図５の例であれば、アプリケーションサーバ３２０のレスポンス悪化を検知した場合、テナント用運用管理サーバ３１０は、ロードバランサの設定を確認するメッセージを、システム管理者宛てに送信する。またＤＢサーバ３３０のレスポンス悪化を検知した場合であって、誤ったＳＱＬ（Structured Query Language）の存在を確認した場合、テナント用運用管理サーバ３１０は、ＳＱＬの変更処理を行う。

クラウドシステム３００内で運用しているシステムは、運用方式に影響するような構成変更が行われることがある。またクラウドシステム３００内に、新規のテナント用に、新たなシステムを構築する場合もある。このような場合、新たなシステムに適合した対処方法を作成することになる。

新たなシステムの対処方法を作成する場合、既存の対処グラフに含まれる対処方法を流用することで、対処グラフの作成が容易となる。既存の対処方法を流用する場合、新たなシステムでは無用な対処方法まで流用すると、まったく使われないか、もしくは使われる頻度が極めて低い対処までも含まれてしまう。例えば、代替案のある時代遅れとなった対処方法や、長期間に渡って安定稼働しているシステムにおける過去の対処方法は、今後まったく使われないか、使われたとしても極めて希である。このような不要な対処方法が対処グラフに含まれていると、障害に応じた対処方法を探索する際に、誤った結果を導き出す要因となってしまう。

そこで、既存の対処方法に示されている対処のうち、新たなシステムに対しても有効に利用できる対処のみを含む対処グラフを作成することが重要となる。例えば、既存のシステムに対して過去に実施された対処の新たなシステムに対する有用度を求め、その有用度の高い対処を採用することが考えられる。有用度の算出には、例えば以下のような評価基準が用いられる。
・評価基準１：対処が実施されたシステムが新規に運用方式を作成するシステムに類似するほど、その対処の有用度を高くする。
・評価基準２：対処が実施されたタイミングが直近もしくはシステムのリリース直後であるほど、その対処の有用度を高くする。
・評価基準３：実施した結果、効果があった（問題が解決した）対処ほど有用度を高くする。

このような評価基準を用いれば、ある程度有用な対処に絞り込むことができる。ただし上記の評価基準だけでは十分とは言えない。すなわち、上記の評価基準では、システムの成熟度に関わらずリリース直後と直近の対処の重みづけ度合いが一定であり、システムの成熟度に応じた評価がなされず、有用度の高い対処を漏らしてしまう。ここでシステムの成熟度とは、システムがバグを出しやすいかどうかなどの、システムの安定性を意味する。例えばシステムがリリースされた直後であったり、安定しないアプリケーションを動かしていたりする場合、そのシステムは成熟度が低い。また実績のある動作環境のシステムであり、リリースされて十分な時間が経過している場合、そのシステムは成熟度が高い。

一般にシステムリリース後もバグ修正などによる改善が行われるため、開発から稼働後も時間経過に応じて成熟度が高まる。例えば、ソフトウェアの信頼性評価モデルとして、成長曲線というものがある。具体的には、コンペルツ曲線やロジスティック曲線などが使われている。このような成長曲線と同様に、成熟度も高まると考えられる。

このような成熟度を利用すれば、対処の有用性の評価の信頼性をさらに向上させることができる。例えば成熟度が低いシステムで起きた対処は総じて有用度を高くし、成熟度が高いシステムで起きた対処はリリース直後と直近の対処のみの有用度を高くすることが考えられる。すなわち、成熟度が低い段階では、どの対処も重要であるため、上記の評価基準１，２を採用しないか、その評価基準の重要度を下げることで、有用な対処が漏れるのを防ぐことができる。

ところが、システムの特性に応じて成熟する速度は変わってくる。
図５は、開発手法によるシステムの成熟度の違いを示す図である。図５の上段には、ウォーターフォール・モデルと呼ばれるソフトウェアの開発手法で開発したシステムの開発スケジュールを示している。また下段には、ＤｅｖＯｐｓと呼ばれるソフトウェアの開発手法で開発したシステムの開発スケジュールを示している。ＤｅｖＯｐｓは、開発（Development）と運用（Operations）を連携させた、システムのリリース形態である。

従来のシステム開発は、ウォーターフォール型開発が主流である。この開発手法では、開発初期で要件が確定するため、スケジュールの変動要因は小さい。例えば、図５に示すように、商習慣によって４半期、半期、通年で予算確定し、予め想定された開発期間を守るように開発が進められる。そのため、システムの成熟過程をシステムの特性によらず見積り可能であり、システムの成熟速度を固定して、成熟度を判断することが可能である。

他方、クラウドを使ったシステムの開発では、ＤｅｖＯｐｓ型の開発スタイルを採用する企業が増えている。ＤｅｖＯｐｓ型の開発では、突発的で開発期間がまちまちな開発案件が発生する。例えば、図５の例では、成熟期間が「案件１」では半期であるのに対し、「案件２」はおよそ四半期である。そのため、開発期間が異なれば、システムの成熟速度も異なる。しかも「案件２」をリリース後、しばらくしてから、「案件３」の機能が「案件２」に追加されている。このような複雑な開発過程を辿ったシステムは、「案件１」と成熟の速度も異なってくる。例えば、「案件１」と同様の基準で「案件２」の成熟度を判断し、その成熟度に基づいて対処を評価すると、対処全体を実際より高く評価してしまう可能性がある。すなわち「案件２」は、成熟度が高いにも拘わらず、成熟度が低いと判断されるおそれがある。その結果、成熟後に実施された対処のうち、対処が実施されたタイミングが直近もしくはシステムのリリース直後の何れでもない対処についてまで、新たに作成する対処方法に含める対象として採用されてしまう。

クラウドシステムが一般化した現在では、システムごとに適切な成熟度の判定基準を設けることが重要となる。そこで、第２の実施の形態では、システムごとに成熟度の進み方を個別に解析して、成熟度の算出式を生成する。これにより、対処を実施した時点でのシステムの成熟度を適切に判断し、有用性の評価の信頼性を向上させる。

例えば、有用度の評価基準として、成熟度を用いた以下の基準を追加する。
＜成熟度利用評価基準１＞
システムの成熟度が低いほど、対処の実施時期に関する全期間を通じて、対処の有用度を高く評価する。これにより、リリースからの経過時間が短い、もしくは、利用実績の少ないシステムほど、運用期間全体を通し、実施された対処が総じて重要になる。

＜成熟度利用評価基準２＞
成熟度が高いほど、運用開始直後および直近の対処を高く評価し、その他のタイミングでの対処の評価を低くする。これにより、運用開始からの十分に経過時間が経つ、もしくは利用実績が多いシステムほど、運用開始直後と直近の対処が重要になり、それ以外の対処は不要と判定される。

なお、第２の実施の形態では、システムは過去の実績から、システムの特性ごとに成熟度係数を算出し、それに応じた成熟度を用いる。
次に、成熟度を加味した有用度の算出方法について説明する。ある対処について、過去にＮ個のシステム（Ｎは１以上の整数）に対して実施されているとき、その対処の有用度（Usefulness）は、以下の式で算出することができる。

ここでSimilarity（Ｓ₀，Ｓ_n）は、対処方法の作成対象となるシステム（Ｓ₀）と、ｎ番目（ｎは１以上Ｎ以下の整数）のシステム（Ｓ_n）との間の構成の類似度である。システム間の類似度は、例えば、コサイン関数ベース（Cosine-based similarity）、相関関係ベース（Correlation-based similarity）、または調整コサインベース（Adjusted cosine-based similarity）などの方法で計算することができる。

Timing（ｔ）は、対処の実施時期に関する評価値（タイミング評価値）である。ｔは、対処を実施した時期を示す実数である（０≦ｔ≦１）。運用開始時を示すｔの値は「０」であり、現在を示すｔの値は「１」である。Resultは、対処による効果の有無を示す値である。効果があればResultは「１」となり、効果が無ければResultは「０」となる。

タイミング評価値は、例えば以下の式で算出することができる。

式（２）の右辺の括弧内の左側の項は、直近の対処ほど重要と評価する式である。また括弧内の右側の項は、システムの運用開始直後の対処ほど重要と評価する式である。Ｍは、対処を実施したシステムの実施時期の成熟度である。成熟度Ｍは、例えば以下の式で表される。
Ｍ＝ｃ×ｔ₀＋ｂ ・・・（３）
ｃ，ｂは、成熟度係数である。成熟度係数は、過去の障害履歴から時間経過に伴う累積障害件数の推移に基づいて、成熟度の変化特性が、累積障害件数の変化特性に一致するように調整する定数である。ｔ₀は、システムの運用開始から対処実施時期までの経過時間である（例えば経過日数）。対処を実施したシステムの成熟度Ｍの値が大きいほど、そのシステムの成熟が進んでおり、安定運用されていることを意味する。

式（２）によりタイミング評価値を計算することで、対処を実施したときのシステムの成熟度に応じた適切なタイミング評価値が得られる。
図６は、成熟度の違いによる処理の実施時期とタイミング評価値との関係の変化を示す図である。図６の例では、横軸にｔ、縦軸にタイミング評価値（Timing（ｔ））を取ったグラフが示されている。そのグラフには、成熟度が異なる複数のタイミング評価値についての処理の実施時期との関係が示されている。

図６に示すように、式（２）を用いてタイミング評価値を算出することで、成熟度Ｍが大きいほど、運用開始直後または直近に実施された対処が際立って重要と評価される。一方、未熟な（成熟度Ｍが低い）システムでは、成熟したシステムと比べ、対処の実施時期の違いに応じたタイミング評価値の差が少ない。そして、未熟なシステムでは、対処の実施時期全体を通して、タイミング評価値が高くなる。

これは、未成熟なシステムでは、システムの運用開始から直近まで無視できる対処がほとんどないことを意味する。逆に、成熟したシステムは、成熟までの過程で実施された処理は、対処方法の作成の際に考慮に入れなくてもよいことを意味している。

なお、タイミング評価値の計算式は、式（３）以外の式であってもよい。例えば式（３）は一次関数の式であるが、以下のような指数関数の式でタイミング評価値を計算することもできる。
Ｍ＝Ｋ／（１＋ｂｅ^-ct） ・・・（４）
Ｋは、最大成熟度を示す実数である（Ｋ＞０）。ｅは自然対数の底（ネイピア数）である。指数関数を用いることで、例えば、運用開始直後には成熟度が急速に高まり、運用を継続するうちに、成熟度の上昇率が徐々に緩やかになる様子を、的確に表すことができる。

以下、第２の実施の形態における各装置の機能について説明する。
図７は、第２の実施の形態を実現するための機能を示すブロック図である。ＤＢサーバ２００は、対処履歴ＤＢ２１０を有している。対処履歴ＤＢ２１０には、クラウドシステム３００内に構築されたいずれかのシステムで発生した障害に対する対処の履歴が格納されている。

サーバ１００は、システム構成情報記憶部１１０、対処方法記憶部１２０、障害履歴記憶部１３０、標本抽出部１４０、成熟度関数生成部１５０、有用度決定部１６０、採用適否判定部１７０、および対処方法作成部１８０を有する。

システム構成情報記憶部１１０は、クラウドシステム３００内に構築されたシステムそれぞれの構成を示す構成情報を記憶する。構成情報には、例えば、システムに含まれるサーバの種類が示されている。また構成情報には、そのシステムで処理しているリクエストの量などの運用状況を含めることもできる。

対処方法記憶部１２０は、クラウドシステム３００内に構築したシステムの障害に対する対処方法の一覧を記憶する。対処方法には、例えば対処を実施するかどうかの判断基準についても示されている。

障害履歴記憶部１３０は、クラウドシステム３００内に構築されたシステムにおいて発生した障害の履歴情報（障害履歴）を記憶する。障害履歴には、例えば発生した障害に対して対処した日時が含まれる。

標本抽出部１４０は、ＤＢサーバ２００に保持されている対処履歴の中から、作成する対処方法に流用する対処履歴を抽出する。例えば標本抽出部１４０は、無作為に対処履歴を抽出する。また標本抽出部１４０は、クラウドシステム３００内に構築されたシステムの一部のシステムを標本として抽出し、そのシステムに関する対処履歴を抽出するようにしてもよい。例えば標本抽出部１４０は、対処方法の作成対象となっているシステムの間で構成が類似するシステムに対して実施された対処履歴を抽出する。標本抽出部１４０は、標本として抽出したシステムの識別情報（テナントＩＤ）と、そのシステムの対処履歴とを、有用度決定部１６０に送信する。また標本抽出部１４０は、標本として抽出したシステムの識別情報（テナントＩＤ）を、成熟度関数生成部１５０に送信する。

成熟度関数生成部１５０は、標本とするシステムの障害履歴に基づいて、成熟度を算出するための関数式（成熟度関数）を、システムごとに生成する。成熟度関数は、例えばシステムの運用期間を変数とした関数である。

成熟度関数生成部１５０は、例えばシステムにおける障害発生件数の累積値（累積障害発生件数）の推移に基づいて、そのシステムの成熟の速度を示すパラメータ（成熟度係数）を算出し、そのパラメータを定数として含む関数式を生成する。成熟度関数生成部１５０は、生成した成熟度関数を、有用度決定部１６０に送信する。

有用度決定部１６０は、標本抽出部１４０が抽出した対処履歴に示される対処の有用度を決定する。有用度決定部１６０は、有用度の決定の際には、システム構成情報記憶部１１０を参照し、対処フラグの作成対象であるシステムの構成と、対処を実施したシステムの構成との類似度を算出し、その類似度を考慮に入れる。また有用度決定部１６０は、有用度の決定の際には、対処を実施したシステムの成熟度を考慮に入れる。成熟度は、成熟度関数生成部１５０により生成された成熟度関数によって算出できる。有用度決定部１６０は、決定した有用度を採用適否判定部１７０に送信する。

採用適否判定部１７０は、各対処の有用度に基づいて、作成する対処方法の流用元として採用するかどうかを決定する。例えば採用適否判定部１７０は、有用度が所定の閾値以上の対処を採用する。採用適否判定部１７０は、採用すると判定した対処に関する情報を、対処方法作成部１８０に送信する。

対処方法作成部１８０は、採用すると判定された対処に関する情報を用いて、新たな対処方法を作成する。対処方法は、例えば対処グラフで表される。例えば対処方法作成部１８０は、因果関係にある事象（障害などのイベント、または観測されるシステムの状態）を示すノード同士をエッジで接続する。また対処方法作成部１８０は、対処のノードとその対処に直接的に因果関係がある事象のノードとをエッジで接続することで、対処グラフを生成する。対処方法作成部１８０は、作成した対処方法を、例えば端末装置４００に送信する。

このような構成により、過去に実施された対処を適切に評価し、有用な対処を行うための対処方法を生成することができる。
なお、図７に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。図７に示す成熟度関数生成部１５０は、図１に示した第１の実施の形態の生成手段１１ａの一例である。図７に示す有用度決定部１６０は、図１に示した第１の実施の形態の成熟度算出手段１１ｂの一例である。図７に示す採用適否判定部１７０は、図１に示した第１の実施の形態の評価手段１２の一例である。また、図７に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。

次に、対処の評価および対処方法の作成に使用する情報について具体的に説明する。
図８は、対処履歴ＤＢのデータ構造の一例を示す図である。対処履歴ＤＢ２１０には、例えば対処履歴管理テーブル２１１が格納されている。対処履歴管理テーブル２１１には、クラウドシステム３００内に構築されたシステムに対して実施された対処ごとのレコードが、対処履歴として登録されている。対処履歴管理テーブル２１１には、テナントＩＤ、対処実績、対処、対処日、および対処結果の欄が設けられている。

テナントＩＤの欄には、システムに一意に設定されたテナントの識別子（テナントＩＤ）が設定される。テナントＩＤは、システムの識別子でもある。対処実績の欄には、対処履歴の識別番号が設定される。対処の欄には、テナントＩＤで示されるシステムに対して実施した対処の識別子が設定される。対処日の欄には、対処を行った期日が設定される。対処結果の欄には、対処の結果、目的が達成できたか否かを示すフラグが設定される。図８の例では、目的が達成できた場合、対処結果の欄に丸印が設定される。また目的が達成できなかった場合、対処結果の欄にバツ印が設定される。なお対処の目的とは、例えば対処を実施する原因となった障害を取り除くか、その障害による悪影響を緩和することである。

図９は、システム構成情報記憶部のデータ構造の一例を示す図である。システム構成情報記憶部１１０には、例えば構成管理テーブル１１１が格納されている。構成管理テーブル１１１には、テナントに対応するシステムの構成や運用状況が格納されている。構成管理テーブル１１１には、テナントＩＤ、システム作成日時、システム構成、アクセスパターン（平均リクエスト数）、およびアクセスパターン（リクエスト数の分散）の欄が設けられている。

テナントＩＤの欄には、クラウドシステム３００内に構成されたシステムに対応するテナントのテナントＩＤが設定される。システム作成日時の欄には、システムが作成された日時が設定される。

システム構成の欄には、システムに含まれる機能が設定される。図９の例では、ロードバランサ（ＬＢ）、アプリケーションサーバ（ＡＰ１，ＡＰ２，ＡＰ３）、データベースサーバ（ＤＢ）、およびキャッシュサーバ（Ｃａｃｈｅ）それぞれの有無が、システム構成の欄に設定されている。対応する機能がある場合「１」が設定され、対応する機能がなければ「０」が設定される。

アクセスパターン（平均リクエスト数）の欄には、システムへの外部からの単位時間当たりの平均リクエスト数が設定される。図９の例では、平均リクエスト数の多さが「小」、「中」、「大」の３段階に分けられている。単位時間当たりの平均リクエスト数が「１５０」未満のシステムは、平均リクエスト数「小」に分類される。単位時間当たりの平均リクエスト数が「１５０」以上「３００」未満のシステムは、平均リクエスト数「中」に分類される。単位時間当たりの平均リクエスト数が「３００」以上のシステムは、平均リクエスト数「大」に分類される。

アクセスパターン（リクエスト数の分散）の欄には、システムへの外部からのリクエスト数の分散の度合いが設定される。図９の例では、リクエスト数の分散の度合いが「小」、「中」、「大」の３段階に分けられている。リクエスト数の分散の値が第１の閾値未満のシステムは、リクエスト数の分散「小」に分類される。リクエスト数の分散の値が第１の閾値以上第２の閾値（第１の閾値＜第２の閾値）未満のシステムは、リクエスト数の分散「中」に分類される。リクエスト数が第２の閾値以上のシステムは、リクエスト数の分散「大」に分類される。

図１０は、対処方法記憶部のデータ構造の一例を示す図である。対処方法記憶部１２０には、対処方法一覧１２１が格納されている。対処方法一覧１２１には、実施可能な対処方法に関する情報が設定されている。対処方法一覧１２１は、例えば、既存のシステム用に作成されている対処グラフ４１，４２，４３，・・・に基づいて作成することができる。

対処方法一覧１２１には、対処ＩＤ、対処、および複数の監視項目の欄が設けられている。対処ＩＤの欄には、対処の識別子（対処ＩＤ）が設定される。対処の欄には、対処内容が設定される。複数の監視項目の欄には、その対処を実施する場合の判断基準とするための監視項目が設定される。対処方法一覧１２１の各レコードは、運用しているシステムが、監視項目の欄に示されている現象（イベント）が発生した場合に、対処の欄に示されている対処を実施することを示している。

例えば対処グラフ４１には、「クラウド管理者へ問い合わせる」という対処を実施するための対処方法と、「Ｃａｃｈｅ化」という対処を実施するための対処方法との、２つの対処方法が含まれている。そこで対処グラフ４１に基づいて、２つの対処方法それぞれを示すレコードが対処方法一覧１２１に設定されている。

図１１は、障害履歴記憶部のデータ構造の一例を示す図である。障害履歴記憶部１３０には、障害履歴管理テーブル１３１が格納されている。障害履歴管理テーブル１３１には、テナントＩＤ、障害実績、および対処日の欄が設けられている。テナントＩＤの欄には、クラウドシステム３００内に構築されたシステムに対応するテナントのテナントＩＤが設定される。障害実績の欄には、発生した障害の識別情報が設定される。対処日の欄には、障害に対して対処した期日が設定される。

以上のような情報を用いて、サーバ１００により、クラウドシステム３００内の任意のシステムに対応する対処方法が作成される。例えば、クラウドシステム３００内に新たなシステムを追加する際に、そのシステムに対応する対処方法が作成される。

以下、対処方法の作成手順について説明する。
図１２は、対処方法の作成手順を示すフローチャートである。
［ステップＳ１０１］サーバ１００は、例えば端末装置４００から、対処方法作成の対象となるシステム（対象システム）の構成情報を受け付ける。後述する図１６の例であれば、システム３５０の構成情報が、端末装置４００から入力される。

［ステップＳ１０２］サーバ１００の標本抽出部１４０は、システム構成情報記憶部１１０に構成情報が登録されたシステムの中から、標本とするシステムを抽出する。抽出されるシステムは、例えばクラウドシステム３００で管理されている既存システムのすべてでもよく、所定の条件に当てはまるシステムでもよい。例えば標本抽出部１４０は、クラウドシステム３００に既に構築されているシステムと対象システムとの類似度を計算し、対象システムとの類似度が所定値以上のシステムを抽出する。また標本抽出部１４０は、所定期間内に新規に追加されたり、構成が変更されたりしたシステムを、標本として抽出してもよい。

［ステップＳ１０３］標本抽出部１４０は、標本として抽出したシステムそれぞれで実施された対処履歴を、ＤＢサーバ２００の対処履歴ＤＢ２１０から抽出する。標本抽出部１４０は、例えば、標本として抽出したシステムそれぞれのテナントＩＤと対処履歴とを、有用度決定部１６０に送信する。また標本抽出部１４０は、例えば、標本として抽出したシステムそれぞれのテナントＩＤとを、成熟度関数生成部１５０に送信する。

［ステップＳ１０４］成熟度関数生成部１５０は、標本のシステムの対処履歴に基づいて、成熟度関数を生成する。例えば成熟度関数生成部１５０は、システムが成熟する速度などの特性を示す成熟度係数を算出する。そして成熟度関数生成部１５０は、算出した成熟度係数を定数として含めた関数式を、成熟度関数として生成する。成熟度関数生成部１５０は、生成した成熟度関数を有用度決定部１６０に送信する。成熟度関数生成処理の詳細は後述する（図１３参照）。

［ステップＳ１０５］有用度決定部１６０は、標本のシステムの対処履歴に示される対処それぞれについて、対象システムに対する有用度を算出する。有用度算出の際には、標本のシステムと対象システムとの構成情報や、標本のシステムの成熟度関数などが用いられる。有用度決定部１６０は、各対処の有用度を採用適否判定部１７０に送信する。有用度算出処理の詳細は後述する（図１４参照）。

［ステップＳ１０６］採用適否判定部１７０は、各対処について、対処方法作成時の流用元として採用することについての適否を判定する。例えば採用適否判定部１７０は、有用度が所定値以上の対処を採用する。採用適否判定部１７０は、採用する対処を対処方法作成部１８０に通知する。採用適否判定処理の詳細は後述する（図１５参照）。

［ステップＳ１０７］対処方法作成部１８０は、採用する対処の対処方法に基づいて、対象システムの運用管理に用いる対処方法を示す対処グラフを作成する。
図１３は、成熟度関数算出処理の手順の一例を示すフローチャートである。

［ステップＳ１１１］成熟度関数生成部１５０は、標本として抽出されたシステムのうち、未選択のシステムの１つを選択する。標本のシステムは、例えば対象システムと構成が類似するシステムである。

［ステップＳ１１２］成熟度関数生成部１５０は、選択したシステムの過去の障害履歴を障害履歴記憶部１３０から収集する。
［ステップＳ１１３］成熟度関数生成部１５０は、収集した障害履歴から、累積障害度数分布を求める。累積障害度数分布は、標本のシステムの運用開始からの障害発生件数の累積値を、所定期間単位で集計したものである（図１９参照）。

［ステップＳ１１４］成熟度関数生成部１５０は、累積障害度数分布に基づいて成熟度係数を算出する。例えば成熟度関数生成部１５０は、障害発生件数の累積値の単位期間当たりの増加量を、成熟度係数とする。

［ステップＳ１１５］成熟度関数生成部１５０は、一次関数、指数関数などの所定の形式の関数式の定数に成熟度係数を設定して、成熟度関数を生成する（図２０参照）。
［ステップＳ１１６］成熟度関数生成部１５０は、標本として抽出されたシステムすべてについて、成熟度関数を生成したか否かを判断する。すべてのシステムの成熟度関数が生成済みの場合、成熟度関数生成処理が終了する。成熟度関数を生成していないシステムがある場合、処理がステップＳ１１１に進められる。

このような手順で、標本として抽出されたシステムそれぞれの成熟度関数が生成される。生成された成熟度関数を用いて、各システムで対処が実施されたときのそのシステムの成熟度が算出できる。そして成熟度を用いて、対処ごとの有用度が算出される。

図１４は、有用度算出処理の手順の一例を示すフローチャートである。
［ステップＳ１２１］有用度決定部１６０は、標本として抽出された複数の対処履歴のいずれかに示される対処のうち、未選択の対処を１つ選択する。

［ステップＳ１２２］有用度決定部１６０は、標本として抽出された複数の対処履歴の中から、選択した対処を実施した対処履歴のうちの未選択の対処履歴の１つを選択する。
［ステップＳ１２３］有用度決定部１６０は、選択した対処履歴において対処を行ったシステムと、対象システムとの間の構成の類似度を算出する。

［ステップＳ１２４］有用度決定部１６０は、選択した対処履歴に示されている対処が実施されたタイミングを評価する。タイミングの評価には、選択した対処履歴に示されている対処が実施されたときの、実施されたシステムの成熟度が用いられる。例えば有用度決定部１６０は、対処の実施時期を示す値ｔ、または運用開始からの経過時間ｔ₀を、対処を実施したシステムの成熟度関数（式（３）または式（４））に代入して、そのときの成熟度を算出する。そして有用度決定部１６０は、算出した成熟度と、対処の実施時期を示す値ｔとをタイミング評価値の計算式（式（２））に代入し、タイミング評価値を算出する。

［ステップＳ１２５］有用度決定部１６０は、選択した対処履歴に示される対処の効果の有無を取得する。有効な対処であれば「１」が取得され、効果のない対処であれば「０」が取得される。

［ステップＳ１２６］有用度決定部１６０は、ステップＳ１２３で算出した類似度、ステップＳ１２４で算出したタイミング評価値、およびステップＳ１２５で取得した効果の有無を乗算し、乗算結果を、選択した対処の有用度の値に加算する。

［ステップＳ１２７］有用度決定部１６０は、選択した対処に関する対処履歴のうち、未選択の対処履歴があるか否かを判断する。未選択の対処履歴があれば、処理がステップＳ１２２に進められる。すべての対処履歴に応じた値を計算し、有用度に加算済みであれば、現在選択している対処に関する有用度の計算が終了し、処理がステップＳ１２８に進められる。

［ステップＳ１２８］有用度決定部１６０は、未評価の対処があるか否かを判断する。標本として抽出された複数の対処履歴のいずれかに示される対処すべてについて有用度の計算が完了していれば、有用度算出処理が終了する。未評価の対処があれば、処理がステップＳ１２１に進められる。なお有用度決定部１６０は、有用度算出処理の終了時に、対処ごとの有用度を採用適否判定部１７０に送信する。

このような手順で、各対処の有用度が算出される。そして算出された有用度に基づいて、各対処の採用適否が判断される。
図１５は、採用適否判定処理の手順の一例を示すフローチャートである。

［ステップＳ１３１］採用適否判定部１７０は、採用適否の判定に用いる閾値を計算する。例えば採用適否判定部１７０は、各対処の有用度の平均値を閾値とする。
［ステップＳ１３２］採用適否判定部１７０は、各対処の有用度と閾値とを比較し、その対処の採用の適否を判定する。例えば採用適否判定部１７０は、対処の有用度が閾値以上であれば、その対処を採用するものと判定する。

このようにして採用する対処が確定すると、採用する対処についての対処方法に基づいて、対象システム用の対処方法が作成される。
以下、具体例を用いて、対処方法の作成例を説明する。例えば、新たに追加するテナント用のシステムの構成情報がサーバ１００に入力されたとき、図１２に示した対処方法作成処理が開始される。

図１６は、システムの追加例を示す図である。クラウドシステム３００には、テナントごとのシステム３０１，３０２，３０３，・・・が設けられている。これらのシステム３０１，３０２，３０３，・・・は、テナントの意向に合わせた構成となっている。例えばシステム３０１は、ロードバランサ（ＬＢ）、アプリケーション（ＡＰ）サーバ、データベース（ＤＢ）サーバ、それぞれ１台ずつで構成されている。システム３０２は、システム３０１と同様の構成に対して、アプリケーション（ＡＰ）サーバとキャッシュ（Cache）とが追加されている。システム３０３は、システム３０１と同様の構成に対して、アプリケーション（ＡＰ）サーバが追加されている。

このようなクラウドシステム３００内のテナントごとのシステム３０１，３０２，３０３，・・・を構成する各サーバは、物理マシンまたは仮想マシンである。例えばクラウドシステム３００内に多数の仮想マシンを立ち上げることで、テナントの要求に合わせた構成のシステムを容易に構築可能となる。

ここで、クラウドシステム３００内に新テナント用のシステム３５０を新たに追加構築する場合を考える。例えば、管理者の操作に応じた端末装置４００からクラウドシステム３００への指示に従って、クラウドシステム３００内に新たなシステムが追加される。

このときサーバ１００は、新たに追加されるシステム３５０を自動運用するために、システム３５０用の対処方法を作成する。なお、図１６の例では、システム３０１，３０２，３０３の各機器構成が示されているが、システム数や機器構成などについては、これに限定されるものではない。また、各システムに関する情報は、例えばＤＢサーバ３３０に記憶され、テナント用運用管理サーバ３１０により管理される。

対象システムの構成情報は、サーバ１００にも入力される（ステップＳ１０１）。対象システムの構成情報が入力された場合、入力された構成情報は、例えば標本抽出部１４０によってシステム構成情報記憶部１１０に登録される。

図１７は、対象システムの構成情報の登録例を示す図である。例えば図１６に示すような新テナント用のシステム３５０に関する構成情報に関するレコードが、構成管理テーブル１１１に追加登録される。

対象システムの構成情報が入力されると、標本とするシステムの抽出が行われる（ステップＳ１０２）。
図１８は、標本とするシステムの抽出例を示す図である。図１８の例では、対象システム（テナントＩＤ：新テナント）との間で構成が類似するシステムを、標本として抽出している。類似性の判断方法は、有用度の計算に用いる類似度「Similarity（Ｓ₀，Ｓ_n）」を用いることができる。また、類似度の計算には、システム構成の類似性に限らず、アクセスパターンの類似性も考慮に入れることができる。

類似度の計算をコサイン関数ベースで計算した場合、「新テナント」と「テナント１」それぞれのシステム間の類似度は以下の通りとなる。

また、「新テナント」と「テナント２」それぞれのシステム間の類似度は以下の通りとなる。

式（５）、式（６）におけるαは、比較対象のシステムの構成情報を示すベクトル間の角度である。この角度αが小さいほど類似度が大きくなる。構成情報を示すベクトルは、システム構成やアクセスパターンの欄に設定されている各値を要素としたものである。図１８の例では、「テナント１」のシステムの類似度と「テナント２」の類似度とが所定値以上となり、「テナント１」と「テナント２」とのシステムが標本として抽出されている。

標本とするシステムが抽出されると、対処履歴ＤＢ２１０からそれらのシステムの対処履歴が抽出され（ステップＳ１０３）、システムごとの成熟度関数が生成される（ステップＳ１０４）。成熟度関数を生成する場合、まず障害履歴に基づいて、累積障害度数分布が生成される。

図１９は、累積障害度数分布の一例を示す図である。図１９には、「テナント１」の累積障害度数分布を示している。例えば障害履歴に示される各障害の対処日から、運用開始から障害の発生までの経過日数と、そのときまでの障害発件数の累積値（累積件数）との関係が集計される。その集計結果に基づいて、累積障害度数分布５１が生成される。累積障害度数分布５１は、例えば横軸に経過日数、縦軸に障害発生件数の累積値を採ったグラフで表される。そして、累積障害度数分布５１に基づいて、成熟度関数が求められる。

成熟度関数を生成する際には、まず累積件数に対応する成熟度が求められる。このとき、システムの障害発生状況が所定の条件を満たしたときの成熟度を所定の値とする。例えば１日当たりの障害発生件数が所定値以下となったときの成熟度を「１」とする。また障害が検出されない期間が所定の期間以上となったときの成熟度を「１」とすることもできる。また、システムの管理者が、システムがある程度成熟した時期を指定し、指定された時期の成熟度を所定の値（例えば「１」）としてもよい。

そして、システムの障害発生状況が所定の条件を満たしたときの累積件数に対する、経過日数ごとの累積件数の割合により、累積件数に応じた成熟度が算出される。図１９の例では、経過日数「２５日」のときに成熟度が「１」となっており、そのときの累積件数は「１１件」である。経過日数「１日」のときの累積件数は「３件」であるため、そのときの成熟度は「１×３／１１＝０．２７２７２７」となる。同様に他の経過日数に関しても、累積件数に応じた成熟度が算出される。

そして、累積障害度数分布５１における累積件数を成熟度に変換して、線形近似を行うことで、成熟度関数を生成できる。
図２０は、成熟度関数の生成例を示す図である。累積障害度数分布５１を示すグラフの縦軸を成熟度とし、経過日数ごとの累積件数を成熟度に変換したグラフが生成される。このグラフの経過日数ごとの成熟度を示す近似曲線が求められる。例えば式（３）に示した式がモデル関数とされ、最小二乗法により、残差の二乗和が最小となるような成熟度係数ｃ、ｂが算出される。図２０の例では、ｃ＝０．００３２、ｂ＝０．２となったものとする。この場合、成熟度関数は「Ｍ＝０．００３２ｔ₀＋０．２」となる。

システムごとの成熟度関数が生成されると、各システムに対して実施された対処の有用度が算出される（ステップＳ１０５）。有用度の算出では、対象システムと、対処が実施されたシステムとの類似度が計算される。なお標本とするシステムの抽出に類似度を用いていれば、そのとき計算した類似度（図１８参照）を用いることができる。

また有用度の計算では、対処履歴ごとにタイミング評価値が計算される。例として対処「Ｏｐ１」を実施した対処履歴のタイミング評価値を計算する場合を想定する。
図２１は、タイミング評価値の計算例を示す図である。対処履歴管理テーブル２１１を参照すると、対処「Ｏｐ１」が実施された対処履歴は「Tenant1＿Record1」、「Tenant2＿Record1」、「Tenant3＿Record1」、「Tenant4＿Record1」、「Tenant5＿Record1」である。ただし、標本として抽出されていないシステムの対処履歴は、有用度算出に用いられない。そこで２つの対処履歴「Tenant1＿Record1」、「Tenant2＿Record1」に基づいて、対処「Ｏｐ１」の有用度が算出される。対処「Ｏｐ１」の有用度の算出に当たり、対処履歴「Tenant1＿Record1」、「Tenant2＿Record1」それぞれのタイミング評価値が計算される。

まず対処履歴「Tenant1＿Record1」のタイミング評価値の計算例について説明する。対処履歴「Tenant1＿Record1」の場合、「テナント１」のシステムの運用開始日から対処を実施した日までの経過期間が１２箇月である。また「テナント１」のシステムは現在（２０１２／０２／０１）まで、１６箇月運用している。従って、対処履歴「Tenant1＿Record1」の対処の実施時期は「ｔ＝１２／１６」となる。そしてｔ₀を日単位で表すものとし、１箇月を３０日と換算すると、運用開始から実施までの経過期間は「ｔ₀＝１２×３０」となる。これらの値を、成熟度Ｍを算出する式（３）と、タイミング評価値を算出する式（２）とに代入することで、以下のようにしてタイミング評価値が得られる。

次に対処履歴「Tenant2＿Record1」のタイミング評価値の計算例について説明する。なお「テナント２」のシステムの成熟度関数は、「テナント１」のシステムと同様に「Ｍ＝０．００３２ｔ₀＋０．２」であるものとする。

対処履歴「Tenant2＿Record1」の場合、「テナント２」のシステムの運用開始日から対処を実施した日までの経過期間が１０箇月である。また「テナント２」のシステムは現在（２０１２／０２／０１）まで、１４箇月運用している。従って、対処履歴「Tenant2＿Record1」の対処の実施時期は「ｔ＝１０／１４」となる。そして、１箇月を３０日と換算すると、運用開始から実施までの経過期間は「ｔ₀＝１０×３０」となる。これらの値を、成熟度Ｍを算出する式（３）と、タイミング評価値を算出する式（２）とに代入することで、以下のようにしてタイミング評価値が得られる。

また対処履歴ごとに、その対処による効果の有無が取得される。
図２２は、効果の有無の取得例を示す図である。対処履歴管理テーブル２１１には、対処履歴「Tenant1＿Record1」、「Tenant2＿Record1」それぞれに関して、どちらも効果があったことが示されている。効果があった場合「Result=1」と設定される。効果がなかった場合であれば、「Result=0」となる。

以上のようにして対処履歴「Tenant1＿Record1」、「Tenant2＿Record1」それぞれに関して、類似度（Similarity（Ｓ₀，Ｓ_n））、タイミング評価値（Timing（ｔ））および効果の有無が得られる。得られた値を用いて式（１）を計算することで、対処「Ｏｐ１」の有用度が得られる。計算結果は、以下の通りである。

このようにして得られた有用度を、所定の閾値と比較することで、対処「Ｏｐ１」を、対処方法作成時の流用元として採用するか否かが判定される。閾値は、管理者が予め設定した値でもよく、計算によって求めた値でもよい。例えば、対処ごとに算出した有用度の平均値を閾値とすることができる。

採用する対処が決定すると、それらの対処に関する対処方法に基づいて、対象システム用の対処方法が作成される。対処方法は、例えば対処グラフで表される。
図２３は、対処グラフの作成例を示す図である。例えば対処方法一覧１２１から、採用すると判定された対処の対処方法が抽出される。図２３の例では、対処「Ｏｐ１」と「Ｏｐ２」とが採用すると判定された場合を想定している。抽出された対処方法それぞれに基づいて、対処グラフ６１，６２が生成される。そして生成された対処グラフ６１，６２の共通のノードを共有させることで、複数の対処グラフ６１，６２がマージ（統合）される。マージされた対処グラフにスタートノードが追加され、対象システム用の対処グラフ６３となる。

以上のように成熟度を加味して有用度を評価することで、有用度の評価の信頼性が向上する。そして、信頼性の高い評価結果に基づいて対処方法を作成することにより、精度の高い対処方法を作成可能になる。

〔第３の実施の形態〕
次に第３の実施の形態について説明する。第３の実施の形態は、システムの運用開始からの経過時間ではなく、所定期間内にシステムが実際に安定運用している度合いに応じて成熟度を計算するものである。

すなわち第３の実施の形態では、システムの運用開始からの経過時間に基づいて、そのシステムの成熟度が計算される。そして例えば、システムの変更があれば、運用開始からの経過時間がリセットされ、成熟度も０にリセットされる。

図２４は、運用開始からの経過時間に応じた成熟度の計算例を示す図である。図２４の例では、経過時間とともに成熟度が単調増加している。すなわち運用開始からの経過時間が長いほど、システムの安定性が増すものと推定されている。経過時間が短ければ、成熟度は低く、タイミングの評価値（Timing（ｔ））において、対処の実施時期によらず高い評価値となる。他方、経過時間が長ければ、成熟度が高く、タイミングの評価値（Timing（ｔ））において、運用開始直後と、直近との評価値が際立って高く評価されるようになる。そして、システムの変更により、成熟度がリセットされる。

しかしシステムの変更の中には、システムの安定性に影響を与えないものもある。例えば、非機能要件を変更しても、システムの安定性は維持されることが多い。非機能要件とは、システムに求められる要件のうち、性能、信頼性、拡張性、運用性、セキュリティなどに関する要件である。非機能要件は、システムの機能は変更されない。コンピュータのシステム上、機能の変更がなければ、新たなプログラムの追加もなく、システムを不安定化させる要因は少ない。例えばシステムをスケールアウトする場合を考える。

図２５は、スケールアウトの例を示す図である。テナントの変更前のシステム３０４は、キャッシュなしのＷｅｂ３階層システムであり、アプリケーションサーバが２台含まれている。変更後のシステム３０５には、アプリケーションサーバが１台追加されている。

このようなスケールアウトは負荷の分散が目的であり、スケールアウト後はシステムが安定化する。システムの安定化を図るような変更が行われたときに成熟度が「０」にリセットされると、その後に算出される成熟度が不正確となる。このように、非機能要件の変更があったときにまで成熟度をリセットすると、システムの成熟度の正確性が損なわれてしまう。その結果、そのシステムに対して行われた対処の有用度の判定の正確性も悪化する。

そこで、第３の実施の形態では、過去の一定期間内に安定して稼働した期間に応じて、システムの成熟度を評価する。例えば、過去の一定期間のうちの多くの期間において安定して稼働したシステムについては、成熟度が高いと判断される。他方、過去の一定期間のうち、安定して稼働した期間が少ないシステムについては、成熟度が低いと判断される。

システムが安定して動作しているかどうかの判断手法としては、以下の３つの手法が考えられる。
第１の判定方法は、外部から観察された状態に基づいて判定する方法である。例えばシステムで提供されるサービスが、予め定めたサービスレベルに達しているかどうかに基づいて安定しているかどうかを判断することができる。サービスのレベルは、例えばリクエストに対するレスポンスタイムで図ることができる。

第２の判定方法は、システム内部で観測できる状態が、超不安定状態との差異がどの程度であるかにより判定する方法である。例えばシステム内の複数のサーバそれぞれについて、通常時の動作状態を求めておき、通常時と異なる動作状態になったサーバについて不安定状態とする。そしてシステム内のすべてのサーバが不安定であるとき、そのシステムが超不安定状態であると定義し、システムの状態と超不安定状態との差異がどの程度かにより、システムが安定運用されているかどうかが判定される。

第３の判定方法は、システムの内部観測および外部観測の結果を組み合わせて判定する手法である。例えば過去の内部観測および外部観測の実績から、安定状態が学習され、観測結果が学習した安定状態に属するかどうかにより、システムが安定しているかどうかが判定される。

以下３つの手法それぞれについて詳細に説明する。
図２６は、システムが安定しているかどうかの第１の判定手法を示す図である。例えばサーバ１００ａが、システム３０４の構成を変更する前に、システム３０４に対してリクエストを送信し、そのリクエストに対するレスポンスタイムを計測する。またサーバ１００ａは、変更後のシステム３０５に対してもリクエストを送信し、そのリクエストに対するレスポンスタイムを計測する。サーバ１００ａは、レスポンスタイムが所定時間を超えた場合、そのシステムは不安定であると判断する。

なおレスポンスタイムは、外部から観測できる観測ポイントの一例である。第１の手法では、観測ポイントの値に応じて安定・不安定を識別するための境界値ε₀が予め設定される。時刻ｔの時点での観測状態をｃ（例えばレスポンスタイム）としたとき、時刻ｔでのシステムの安定性Ｓ_tは、以下の式で判定できる。

式（１０）によれば、システムが安定している時には、安定性Ｓ_tの判定結果が「１」となる。システムが不安定であれば、安定性Ｓ_tの判定結果が「−１」となる。
次に、システムが安定しているかどうかの第２の判定手法について説明する。

図２７は、システムが安定しているかどうかの第２の判定手法を示す図である。例えばサーバ１００ａは、各システム３０４，３０５に含まれるサーバから、ＣＰＵの状態を示す情報を取得する。例えばＣＰＵ使用率が取得される。そしてサーバ１００ａは、ＣＰＵ使用率に基づいて、各サーバが安定しているか不安定かを判断する。

またサーバ１００ａは、各システム３０４，３０５を複数の階層に分け、各階層を監視区分とし、各階層内の各サーバを監視対象とする。そしてサーバ１００ａは、変更前後のシステム３０４，３０５の階層ごとに、安定性を示す状態ベクトルを生成する。各ベクトルは、対応する階層の属するサーバそれぞれの状態を示す値を要素として含む。例えばシステム３０４のロードバランサは１台であるため、ロードバランサの層の状態ベクトル（ＬＢ状態ベクトル）には、１つの要素が含まれる。またシステム３０４のアプリケーションサーバは２台あるため、アプリケーション層の状態ベクトル（ＡＰ状態ベクトル）には、２つの要素が含まれる。システム３０４のＤＢサーバは１台であるため、ＤＢ層の状態ベクトル（ＤＢ状態ベクトル）には、１つの要素が含まれる。変更後のシステム３０５では、アプリケーションサーバが追加されているため、ＡＰ状態ベクトルには３つの要素が含まれる。

さらにサーバ１００ａは、階層ごとに超不安定状態を示すベクトルを定義する。そしてサーバ１００ａは、階層ごとに、状態ベクトルと超不安定状態を示すベクトルとの差を計算することで、システムの状態の超不安定状態との差異を、ベクトルが配置された空間における距離で表す。例えばロードバランサの状態の超不安定状態からの距離Ｄ₀、アプリケーションサーバの状態の超不安定状態からの距離Ｄ₁、ＤＢサーバの状態の超不安定状態からの距離Ｄ₂が算出される。これらの距離に基づいて、システム全体の安定・不安定が判断される。

第２の判定手法における各サーバが安定か不安定かの判断は、例えば正常時の実績との差を用いて行われる。
図２８は、第２の判定方法における各サーバの安定・不安定の判断例を示す図である。サーバ１００ａは、例えば監視対象のサーバの動作が正常であるときのそのサーバのＣＰＵ使用率を一定期間観測する。そして正常時に観測されるＣＰＵ使用率の範囲を判断する。例えば図２８の例では、正常時のＣＰＵ使用率は、０％〜３０％である。

次にサーバ１００ａは、運用時のサーバのＣＰＵ使用率を観測し、所定期間内に観測されたＣＰＵ使用率の範囲を判断する。図２８の例では、「区間１」の期間には、ＣＰＵ使用率が４０％に達しているときがある。そのため、「区間１」においてサーバが不安定であると判断される。また「区間２」では、ＣＰＵ使用率は０％〜３０％の範囲内に収まっている。そのため、「区間２」ではサーバは安定していると判断される。

各サーバの安定・不安定が判断されると、階層ごとに、その階層に属するサーバの状態ベクトルが生成される。
図２９は、状態ベクトルの例を示す図である。図２９の例では、「要素Ａ」、「要素Ｂ」、「要素Ｃ」の３つの要素を含む状態ベクトルＦ_asisが生成されている。「要素Ａ」、「要素Ｂ」、「要素Ｃ」は、それぞれサーバに対応し、対応するサーバが安定か不安定かを示す。例えばサーバが安定していれば、対応する要素の値は「１」となる。またサーバが不安定であれば、対応する要素の値は「０」となる。

図２９に示すような、各要素を軸とする直交座標系において、超安定点を示す超安定ベクトルＦ_tobeと超不安定点を示す超不安定ベクトルＦ_not#tobeとが定義される。ここで超不安定点を原点（０，０，０）にすると、超不安定ベクトルＦ_not#tobeは０ベクトルとなる。また安定ベクトルＦ_tobeの各要素の値は（１，１，１）となる。このとき、要素ごとのサーバの観測により得られた観測点への状態ベクトルＦ_asisの長さを、超安定ベクトルＦ_tobeの長さで除算した結果が、距離Ｄとなる。距離Ｄは、以下の式で表される。

システムの階層ごとの距離（Ｄ₀，Ｄ₁，Ｄ₂）が求まると、境界値ε₁とすべての距離の積を比較して、システム全体として安定しているか不安定なのかが判断される。例えば時刻ｔの時点でのシステムの安定性Ｓ_tは、以下の式で表される。

このように監視区分（階層）ごとの距離の積によって安定・不安定を判断することで、すべての監視区分のうち１カ所でも超不安定点に一致する（距離が０）監視区分があれば、判定された安定性Ｓ_tは「０」となり、不安定と判断される。

図３０は、システムの安定・不安定の判断例を示す図である。図３０の例では、ロードバランサのＣＰＵ使用率は安定している。また２台あるアプリケーションサーバのうち、１台はＣＰＵ使用率が安定しているが、他の１台はＣＰＵ使用率が不安定である。さらにＤＢサーバのＣＰＵ使用率は安定している。

このシステム３０４の状態を抽出すると、ロードバランサの層の状態ベクトルは、（１）となる（１次元のベクトル）。アプリケーションサーバの層の状態ベクトルは、（１，０）となる（２次元のベクトル）。ＤＢサーバの層の状態ベクトルは、（１）となる（１次元のベクトル）。

各状態ベクトルに基づいて、監視区分ごとの超不安定状態からの距離が算出される。ロードバランサの距離Ｄ₀は、「１」である。アプリケーションサーバの距離Ｄ₁は「１／２^1/2」である。ＤＢサーバの距離Ｄ₂は「１」である。

監視区分ごとの距離の積は「１／２^1/2」となる。ここで閾値が３／４であるとすると、距離の積は閾値より小さくなる。すなわちシステム３０４は不安定であると判断される。

次に、システムが安定しているかどうかの第３の判定手法について詳細に説明する。
図３１は、システムが安定しているかどうかの第３の判定手法を示す図である。第３の手法では、サーバ１００ａは、内部および外部で観測された状態を用いて、過去の実績から安定状態と不安定状態とを学習する。この学習により、安定・不安定を判断するためのモデルが構築される。そして構築されたモデルを用いて、その後に観測された状態が安定状態なのか、不安定状態なのかが判断される。

図３１の例では、システムの内部状態と外部状態とを１時間ごとに観測している。内部状態としては、アプリケーションサーバとＤＢサーバとのＣＰＵ使用率が観測されている。外部状態としては、例えばリクエストに対するレスポンスタイムが観測され、レスポンスタイムが所定値を超えるかどうかにより、安定か不安定かが判断されている。そして、サーバ１００ａは、外部観察で安定と判断したときの内部状態と、外部観察で不安定と判断したときの内部状態とを区別して、履歴ごとの内部状態をグラフ７１にプロットする。そしてグラフ７１中で、安定のときの内部状態が集まった領域と、不安定のときの内部状態が集まった領域との境界となる線の式「ｙ＝φ・ｘ＋ａ」が、判定用のモデルとして求められる。ｘは、アプリケーションサーバのＣＰＵ使用率、ｙはＤＢサーバのＣＰＵ使用率である。φとａは、定数である。

運用時のシステムから観測された内部状態が、モデルに示された線の上か下かにより、その時点でのシステムの安定性が判定できる。図３１のグラフ７１に示した例であれば、観測された内部状態が線の下になれば安定であり、上になれば不安定である。運用中に加速されたアプリケーションサーバのＣＰＵ使用率をｘ₀とし、ＤＢサーバのＣＰＵ使用率をｙ₀とすると、判定された安定性Ｓ_tは以下の式で表される。

このように内部状態と外部状態とを組み合わせて、システムが安定しているか不安定なのかを判断できる。
以上のような第１〜第３のいずれかの手法で、個別の時点でのシステムの安定性を判定し、システムに対する対処の実施前の所定期間の判定結果を総合的に判断して、対処時点でのシステムの成熟度を求めることができる。例えばサーバ１００ａは、過去の一定の期間（Ｔ₀からＴ_n）において成熟化した期間の長さ（安定期間長ｐ）が次の式で求められる。

以下、システムが安定しているかどうかを第２の判定手法で判断する場合を例に採って、第３の実施の形態について詳細に説明する。なお第３の実施の形態におけるシステム構成は、図２に示した第２の実施の形態のシステムと同様である。ただし第２の実施の形態のサーバ１００に代えて、第３の実施の形態を実現するサーバ１００ａが用いられる。第３の実施の形態のサーバ１００ａは、図３に示した第２の実施の形態のサーバ１００のハードウェア構成と同様のハードウェア構成で実現できる。

図３２は、第３の実施の形態のサーバの機能を示すブロック図である。図３２において、図７に示した第２の実施の形態のサーバ１００内の要素と同じ機能の要素には、同じ符号を付し、説明を省略する。

サーバ１００ａは、第２の実施の形態と異なる機能を有する要素として、監視部１５１、監視履歴記憶部１９０、成熟度関数生成部１５２、および有用度決定部１６１を有する。

監視部１５１は、クラウドシステム内の各テナントのシステムに属するサーバの動作状態を監視する。例えば監視部１５１は、アプリケーションサーバ３２０やＤＢサーバ３３０のＣＰＵ使用率を、各サーバから定期的に取得する。

監視履歴記憶部１９０は、監視部１５１による監視履歴を記憶する。例えば、メモリ１０２やＨＤＤ１０３の記憶領域の一部が、監視履歴記憶部１９０として使用される。
成熟度関数生成部１５２は、前述の第２の判定手法によりシステムが安定しているかどうかを判断して、所定期間（例えば１日）ごとに、その期間における安定期間長ｐを、式（１４）により求める。そして、成熟度関数生成部１５２は、成熟度期間長ｐを用い、所定期間（例えば１日）ごとに、その期間内に実施された対処に適用する成熟度関数を生成する。

有用度決定部１６１は、第２の実施の形態の有用度決定部１６０と同様の処理を行う。ただし第３の実施の形態における有用度決定部１６１は、対処の有用度の計算の際に、その対処の実施時を含む期間に対応する成熟度関数が用いられる。

図３３は、監視履歴記憶部のデータ構造の一例を示す図である。監視履歴記憶部１９０には、内部状態管理テーブル１９１が格納されている。内部状態管理テーブル１９１には、テナントＩＤ、装置、およびＣＰＵ使用率の欄が設けられている。テナントＩＤの欄には、監視する対象のシステムの識別情報（テナントＩＤ）が設定される。装置の欄には、対応するシステムに含まれる装置の名称が設定される。ＣＰＵ使用率の欄には、対応する装置から所定間隔で計測されたＣＰＵ使用率が設定される。

以上のようなシステムにより第３の実施の形態が実現される。第３の実施の形態では、成熟度関数生成処理が、第２の実施の形態と異なる。
図３４は、成熟度関数生成処理の手順の一例を示すフローチャートである。

［ステップＳ２１１］成熟度関数生成部１５２は、標本として抽出されたシステムのうち、未選択のシステムの１つを選択する。標本のシステムは、例えば対象システムと構成が類似するシステムである。なお標本として抽出されるのは、例えば状態を監視可能なすべてのシステムである。またSimilarityの値が閾値を超えているシステムを標本とすることもできる。またSimilarityの値が閾値を超えていることに加え、構成変更の変遷も似ているシステムを標本としてもよい。

［ステップＳ２１２］成熟度関数生成部１５２は、選択したシステムの過去の監視履歴を監視履歴記憶部１９０から収集する。
［ステップＳ２１３］成熟度関数生成部１５２は、収集した監視履歴に基づいて、選択したシステムの監視区分ごとの状態の超不安定状態からの距離を計算する。そして成熟度関数生成部１５２は、監視区分ごとの距離の積を、単位期間（例えば日）ごとに計算する。

［ステップＳ２１４］成熟度関数生成部１５２は、日ごとの距離の積に基づいて、選択したシステムが安定か不安定かを、日ごとに判断する。例えば成熟度関数生成部１５２は、日ごとの積が閾値より大きければ安定状態、閾値以下であれば不安定状態と判断する。

［ステップＳ２１５］成熟度関数生成部１５２は、日ごとの安定・不安定の判断結果に基づいて、日ごとの安定期間長ｐを算出する。例えば成熟度関数生成部１５２は、ある日を特定し、その日から過去数日間の安定性の判断結果（安定状態「１」または不安定状態「０」を合計し、合計した結果を特定した日の安定期間長ｐとする。

［ステップＳ２１６］成熟度関数生成部１５２は、日ごとの安定期間長ｐに基づいて、日ごとの成熟度関数を生成する。例えば成熟度関数生成部１５２には、安定期間長ｐの値を変数の１つに含む関数式が予め用意されている。そして成熟度関数生成部１５２は、予め用意された関数式の安定期間長ｐとしてステップＳ２１５で得られた日ごとの値を代入することで、日ごとの成熟度関数を生成する。

［ステップＳ２１７］成熟度関数生成部１５２は、標本として抽出されたシステムすべてについて、成熟度関数を生成したか否かを判断する。すべてのシステムの成熟度関数が生成済みの場合、成熟度関数生成処理が終了する。成熟度関数を生成していないシステムがある場合、処理がステップＳ２１１に進められる。

このように、第３の実施の形態では、距離の積、安定・不安定の判断、安定期間長の算出が日付ごとに行われ、日付ごとに、その日に実施された対象の有用度の計算に用いる成熟度関数が生成される。以下、図３５から図３８を参照し、日ごとの成熟度関数を生成する過程について、具体的に説明する。

図３５は、安定期間長の算出例を示す図である。図３５の例では、観測項目ごとの距離の積（ΠＤ_n）が、１日ごとに算出されている。日ごとに、距離の積が閾値ε₀以上であれば、その日のシステムは安定であると判断される。また距離の積が閾値ε₀未満であれば、その日のシステムは不安定であると判断される。図３５の例では、閾値ε₀を「３／４」としている。システムが安定の場合システムの安定性は「１」であり、システムが不安定の場合、システムの安定性は「−１」である。なお図３５の例では、１２月９日にシステムに機能的な変更が加えられ、安定性を含む成熟度に関する情報がリセットされている。

図３５の例において、１２月５日（１２／５）における安定期間長ｐを求める場合を考える。この例では、過去の５日間の安定度に基づいて安定期間長ｐを算出するものとする。すなわち１２月１日から１２月５までの安定性Ｓ_tの合計値「−１」が、１２月５日の安定期間長ｐとなる。

安定期間長ｐを用いて、例えば次の式で成熟度Ｍが求められる。

式（１５）のＫは最大成熟度であり、ｃは成熟化係数である。なお式（１５）が、第３の実施の形態における成熟度関数である。
図３６は、安定期間長と成熟度との関係を示す図である。図３６の上段に、安定期間長と成熟度との関係を示すグラフを示し、下段に、所定の成熟度のときのタイミング評価値のグラフを示している。図３６の例では、最大成熟度Ｋを「１６」としている。この場合、安定期間長が例えば「−１」であれば、成熟度Ｍは、ほぼ「４」となる。成熟度Ｍが決まれば、前述の式（２）により、対処時点でのタイミング評価値（Timing（ｔ））が定まる。

このような安定期間長ｐと成熟度Ｍとは、所定の期間ごと（例えば１日ごと）に求められる。
図３７は、日ごとの成熟度の算出例を示す図である。日ごとの安定性に基づいて、日ごとの安定期間長ｐが求められ、式（１５）に基づいて日ごとの成熟度Ｍが求められる。例えば１２月１日から１２月５日までの期間の安定性に基づいて算出すると、１２月５日の安定期間長ｐは「−１」となり、成熟度Ｍは「４．３０」となる。また例えば１２月２日から１２月６日までの期間の安定性に基づいて算出すると、１２月６日の安定期間長ｐは「−３」となり、成熟度Ｍは「０．７６」となる。日付ごとに、その日から過去５日間の安定性に基づいて、成熟度が求められる。

このようにして成熟度を算出することで、成熟度は、安定度の変化に応じて増減する。すなわち成熟度は、単調増加ではなくなる。
図３８は、成熟度の変化例を示す図である。図３８の例では、ある月の１日の成熟度が「４」であっても、翌日（２日）の成熟度は「１」に下がっている。その後、成熟度がさらに下がるが、４日に成熟度が「１」に戻っている。その翌日（５日）には、成熟度が「４」まで回復している。この場合、その月の１日と５日とに実施した対処のタイミング評価値を計算する際の成熟度は「４」であり、その月の２日と４日とに実施した対処のタイミング評価値を計算する際の成熟度は「１」である。

このように、日付ごとに、その日に実施された対処の有用度の計算に適用する成熟度関数が生成される。対処を評価する際には、その対処を実施した日の成熟度関数を用いて、成熟度が計算される。そして、計算された成熟度を用いて、タイミング評価値が計算される。

図３９は、第３の実施の形態におけるタイミング評価値の計算例を示す図である。図３９は、図２１に示した例と同様に、対処「Ｏｐ１」の有用度の算出に当たり、対処履歴「Tenant1＿Record1」、「Tenant2＿Record1」それぞれのタイミング評価値が計算される場合を想定している。

まず対処履歴「Tenant1＿Record1」のタイミング評価値の計算例について説明する。対処履歴「Tenant1＿Record1」の場合、「テナント１」のシステムの運用開始日から対処を実施した日までの経過期間が１２箇月である。また「テナント１」のシステムは現在（２０１２／０２／０１）まで、１６箇月運用している。従って、対処履歴「Tenant1＿Record1」の対処の実施時期は「ｔ＝１２／１６」となる。この対処の対処日「2011/10/05」における成熟度は「４．３０」であるものとする。これらの値を、タイミング評価値を算出する式（２）に代入することで、以下のようにしてタイミング評価値が得られる。

次に対処履歴「Tenant2＿Record1」のタイミング評価値の計算例について説明する。対処履歴「Tenant2＿Record1」の場合、「テナント２」のシステムの運用開始日から対処を実施した日までの経過期間が１２箇月である。また「テナント２」のシステムは現在（２０１２／０２／０１）まで、１４箇月運用している。従って、対処履歴「Tenant2＿Record1」の対処の実施時期は「ｔ＝１２／１４」となる。この対処の対処日「2011/12/10」における成熟度は「１１．７」であるものとする。これらの値を、タイミング評価値を算出する式（２）に代入することで、以下のようにしてタイミング評価値が得られる。

タイミング評価値が計算されると、第２の実施の形態と同様に、式（１）に基づいて対処の有用度が算出される。そして有用度が所定値以上の対処の履歴に基づいて、新たに作成したシステム用の対処グラフが生成される（図２３参照）。

このように第３の実施の形態では、システムの実際の運用状態の監視結果に基づいて、システムの成熟度を計算するようにしたため、成熟度の正確性が向上する。対処を実施した時点でのシステムの成熟度が正確に求まれば、その対処の有用度の正確性も向上する。その結果、より適切な対処グラフを生成できるようになる。

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

１ 既存システム群
１ａ，１ｂ，１ｃ，２ システム
３ 障害件数情報
４ 対処履歴
１０ 評価装置
１１ 算出手段
１１ａ 生成手段
１１ｂ 成熟度算出手段
１２ 評価手段

Claims (11)

1. 複数のシステムにおいて実施された対処の、特定のシステムに対する有用度を評価する評価プログラムであって、
   コンピュータに、
   前記複数のシステムそれぞれについての非機能要件に関する値に基づいて、前記複数のシステムそれぞれで各々の対処の実施時期における、当該対処を実施したシステムが安定運用できている度合いを示す成熟度を算出し、
   前記複数のシステムそれぞれで実施された前記各々の対処について、前記特定のシステムと当該対処が実施されたシステムとの構成の類似度、当該対処の実施時期、当該対処による効果、および前記実施時期における前記成熟度に基づき、前記特定のシステムに対する有用度を評価する、
   処理を実行させる評価プログラム。
2. 前記成熟度の算出では、前記複数のシステムそれぞれについての前記非機能要件に関する値に基づいて、当該システムの運用期間と、当該システムの前記成熟度との関係を示す関係情報を生成し、
   前記複数のシステムそれぞれで実施された前記各々の対処について、前記関係情報に基づいて、当該対処を実施したときの当該システムの運用期間に対応する前記成熟度を算出する、
   請求項１記載の評価プログラム。
3. 有用度の評価では、前記複数のシステムそれぞれで実施された前記各々の対処について、当該対処の実施時期が運用開始時または現在のいずれかに近いほど、有用度を高く評価し、当該対処が実施されたシステムの前記成熟度が高いほど、当該対処の実施時期の運用開始時または現在のいずれかへの近さの差に応じた有用度の差を大きくすることを特徴とする請求項１または２記載の評価プログラム。
4. 前記成熟度の算出では、システムの運用期間が長いほど前記成熟度を高くすることを特徴とする請求項１乃至３のいずれかに記載の評価プログラム。
5. 前記非機能要件に関する値は、システムの稼働開始からの障害の累積発生状況を示す値である請求項１乃至４のいずれかに記載の評価プログラム。
6. 前記成熟度の算出では、システムの障害発生状況の時間変化に基づいて、当該システムの運用期間の長さに応じた成熟度合いを示す成熟度係数を求め、定数として前記成熟度係数を設定した関数式を生成し、前記関数式に基づいて、前記複数のシステムそれぞれで実施された各々の対処について、当該対処を実施したときの当該システムの運用期間に対応する前記成熟度を算出する請求項５記載の評価プログラム。
7. 前記成熟度の算出では、システムに対する障害発生の累積件数の時間変化を求め、運用期間の長さに応じた当該累積件数の増加度合いを、前記成熟度係数とすることを特徴とする請求項６記載の評価プログラム。
8. 前記成熟度の算出では、評価対象の対処を実施したシステムの前記非機能要件に関する値に基づいて、単位期間ごとの当該システムの動作の安定性を判定し、当該対処の実施時までの所定期間内の各単位期間の当該システムの安定性に基づいて、当該対処の前記成熟度を算出する請求項１乃至３のいずれかに記載の評価プログラム。
9. 前記非機能要件に関する値は、前記複数のシステムを監視することで得られた、前記複数のシステムそれぞれの動作状態を示す値である請求項１乃至４のいずれかまたは請求項８に記載の評価プログラム。
10. 複数のシステムにおいて実施された対処の、特定のシステムに対する有用度を評価する評価方法であって、
    コンピュータが、
    前記複数のシステムそれぞれについての非機能要件に関する値に基づいて、前記複数のシステムそれぞれで各々の対処の実施時期における、当該対処を実施したシステムが安定運用できている度合いを示す成熟度を算出し、
    前記複数のシステムそれぞれで実施された前記各々の対処について、前記特定のシステムと当該対処が実施されたシステムとの構成の類似度、当該対処の実施時期、当該対処による効果、および前記実施時期における前記成熟度に基づき、前記特定のシステムに対する有用度を評価する、
    評価方法。
11. 複数のシステムにおいて実施された対処の、特定のシステムに対する有用度を評価する評価装置であって、
    前記複数のシステムそれぞれについての非機能要件に関する値に基づいて、前記複数のシステムそれぞれで各々の対処の実施時期における、当該対処を実施したシステムが安定運用できている度合いを示す成熟度を算出する算出手段と、
    前記複数のシステムそれぞれで実施された前記各々の対処について、前記特定のシステムと当該対処が実施されたシステムとの構成の類似度、当該対処の実施時期、当該対処による効果、および前記実施時期における前記成熟度に基づき、前記特定のシステムに対する有用度を評価する評価手段と、
    を有する評価装置。

Images