(57)【特許請求の範囲】
【請求項１】
コンピュータシステムを運用管理する複数のオペレーションからなる運用管理手続き、及び前記運用管理手続きの各オペレーションについて、オペレーションを実行する前提となる事前条件を示す情報、及びオペレーションを実行した結果、そのオペレーションの実行対象である構成要素において少なくとも満たされるべき事後条件を示す情報を少なくとも含むオペレーション知識と、コンピュータシステムの各構成要素間で成立する相関関係を示す情報を含む状態知識とを有する運用管理知識が夫々保存されたデータベースと、
前記運用管理手続きに従ってオペレーションが実行された結果、コンピュータシステムの各構成要素の実際の状態を示す情報が、前記データベースに保存された前記運用管理知識に基づいて導出される事後状態を示す情報と一致しているかいないかを判定する判定手段と、
前記判定手段により一致していないと判定されたときに、前記オペレーション実行後の各構成要素の実際の状態を示す情報と前記事後状態を示す情報との差分を解消し且つ前記状態知識を満たす状態を示すサブゴール状態を導出し、前記オペレーションの実行前に前記サブゴール状態に至ることが可能なオペレーションを、前記データベースに保存された前記オペレーション知識の前記事前条件の情報及び前記事後条件の情報から導出する導出手段と、
前記導出手段により導出されたオペレーションを提示する提示手段と、
を含んで構成されたシステム運用管理装置。
【請求項２】
前記導出手段は、実行されたオペレーションについて、推定された前記サブゴール状態を満たす条件を前記事前条件とするオペレーション知識をさらに導出し、
前記提示手段は、前記導出手段により導出されたオペレーション知識をさらに提示することを特徴とする請求項１記載のシステム運用管理装置。
【請求項３】
前記事後状態を示す情報は、オペレーションの実行対象である構成要素におけるオペレーション実行前の状態を示す情報に対し、そのオペレーションにおける前記オペレーション知識の事前条件を示す情報及び事後条件を示す情報の差分により特定される状態変化を示す情報を反映させるとともに、前記状態知識により示される相関関係を示す情報をさらに反映させることにより特定されることを特徴とする請求項１記載のシステム運用管理装置。
【請求項４】
前記判定手段は、オペレーション実行前の状態を示す情報が前記事前条件を満たしているが、オペレーション実行後に、そのオペレーションの実行対象である構成要素の実際の状態を示す情報が前記事後条件を満たしていない目標未達成の状態である場合に、コンピュータシステムの各構成要素の実際の状態を示す情報が前記事後状態を示す情報と一致していないと判定することを特徴とする請求項１記載のシステム運用管理装置。
【請求項５】
前記判定手段は、オペレーション実行前の状態を示す情報が前記事前条件を満たし、且つオペレーション実行後に、そのオペレーションの実行対象である構成要素の状態を示す情報が前記事後条件を満たしているが、各構成要素のうち、オペレーション実行後の状態を示す情報が前記事後状態を示す情報と一致していないものが存在している想定外副作用が発生した状態である場合に、コンピュータシステムの各構成要素の実際の状態を示す情報が前記事後状態を示す情報と一致していないと判定することを特徴とする請求項１記載のシステム運用管理装置。
【請求項６】
データベースに保存された、コンピュータシステムを運用管理する複数のオペレーションからなる運用管理手続きに従ってオペレーションが実行された結果、コンピュータシステムの各構成要素の実際の状態を示す情報が、前記データベースにさらに保存された、前記運用管理手続きの各オペレーションについて、オペレーションを実行する前提となる事前条件を示す情報、及びオペレーションを実行した結果、そのオペレーションの実行対象である構成要素において少なくとも満たされるべき事後条件を示す情報を少なくとも含むオペレーション知識と、コンピュータシステムの各構成要素間で成立する相関関係を示す情報を含む状態知識とを有する運用管理知識に基づいて導出される事後状態を示す情報と一致しているかいないかを判定する判定ステップと、
前記判定ステップにより一致していないと判定されたときに、前記オペレーション実行後の各構成要素の実際の状態を示す情報と前記事後状態を示す情報との差分を解消し且つ前記状態知識を満たす状態を示すサブゴール状態を導出し、前記オペレーションの実行前に前記サブゴール状態に至ることが可能なオペレーションを、前記データベースに保存された前記オペレーション知識の前記事前条件の情報及び前記事後条件の情報から導出する導出ステップと、
前記導出ステップにより導出されたオペレーションを提示する提示ステップと、
を実行することを特徴とするシステム運用管理方法。
【請求項７】
前記導出ステップは、実行されたオペレーションについて、推定された前記サブゴール状態を満たす条件を前記事前条件とするオペレーション知識をさらに導出し、
前記提示ステップは、前記導出ステップにより導出されたオペレーション知識をさらに提示することを特徴とする請求項６記載のシステム運用管理方法。
【請求項８】
前記事後状態を示す情報は、オペレーションの実行対象である構成要素におけるオペレーション実行前の状態を示す情報に対し、そのオペレーションにおける前記オペレーション知識の事前条件を示す情報及び事後条件を示す情報の差分により特定される状態変化を示す情報を反映させるとともに、前記状態知識により示される相関関係を示す情報をさらに反映させることにより特定されることを特徴とする請求項６記載のシステム運用管理方法。
【請求項９】
前記判定ステップは、オペレーション実行前の状態を示す情報が前記事前条件を満たしているが、オペレーション実行後に、そのオペレーションの実行対象である構成要素の実際の状態を示す情報が前記事後条件を満たしていない目標未達成の状態である場合に、コンピュータシステムの各構成要素の実際の状態を示す情報が前記事後状態を示す情報と一致していないと判定することを特徴とする請求項６記載のシステム運用管理方法。
【請求項１０】
前記判定ステップは、オペレーション実行前の状態を示す情報が前記事前条件を満たし、且つオペレーション実行後に、そのオペレーションの実行対象である構成要素の状態を示す情報が前記事後条件を満たしているが、各構成要素のうち、オペレーション実行後の状態を示す情報が前記事後状態を示す情報と一致していないものが存在している想定外副作用が発生した状態である場合に、コンピュータシステムの各構成要素の実際の状態を示す情報が前記事後状態を示す情報と一致していないと判定することを特徴とする請求項６記載のシステム運用管理方法。
【請求項１１】
コンピュータシステムを運用管理する複数のオペレーションからなる運用管理手続き、及び前記運用管理手続きの各オペレーションについて、オペレーションを実行する前提となる事前条件を示す情報、及びオペレーションを実行した結果、そのオペレーションの実行対象である構成要素において少なくとも満たされるべき事後条件を示す情報を少なくとも含むオペレーション知識と、コンピュータシステムの各構成要素間で成立する相関関係を示す情報を含む状態知識とを有する運用管理知識が夫々保存されたデータベースを備えたコンピュータに、
前記運用管理手続きに従ってオペレーションが実行された結果、コンピュータシステムの各構成要素の実際の状態を示す情報が、前記データベースに保存された前記運用管理知識に基づいて導出される事後状態を示す情報と一致しているかいないかを判定する判定ステップと、
前記判定ステップにより一致していないと判定されたときに、前記オペレーション実行後の各構成要素の実際の状態を示す情報と前記事後状態を示す情報との差分を解消し且つ前記状態知識を満たす状態を示すサブゴール状態を導出し、前記オペレーションの実行前に前記サブゴール状態に至ることが可能なオペレーションを、前記データベースに保存された前記オペレーション知識の前記事前条件の情報及び前記事後条件の情報から導出する導出ステップと、
前記導出ステップにより導出されたオペレーションを提示する提示ステップと、
を実現させることを特徴とするシステム運用管理プログラム。
【請求項１２】
前記導出ステップは、実行されたオペレーションについて、推定された前記サブゴール状態を満たす条件を前記事前条件とするオペレーション知識をさらに導出し、
前記提示ステップは、前記導出ステップにより導出されたオペレーション知識をさらに提示することを特徴とする請求項１１記載のシステム運用管理プログラム。
【請求項１３】
前記事後状態を示す情報は、オペレーションの実行対象である構成要素におけるオペレーション実行前の状態を示す情報に対し、そのオペレーションにおける前記オペレーション知識の事前条件を示す情報及び事後条件を示す情報の差分により特定される状態変化を示す情報を反映させるとともに、前記状態知識により示される相関関係を示す情報をさらに反映させることにより特定されることを特徴とする請求項１１記載のシステム運用管理プログラム。
【請求項１４】
前記判定ステップは、オペレーション実行前の状態を示す情報が前記事前条件を満たしているが、オペレーション実行後に、そのオペレーションの実行対象である構成要素の実際の状態を示す情報が前記事後条件を満たしていない目標未達成の状態である場合に、コンピュータシステムの各構成要素の実際の状態を示す情報が前記事後状態を示す情報と一致していないと判定することを特徴とする請求項１１記載のシステム運用管理プログラム。
【請求項１５】
前記判定ステップは、オペレーション実行前の状態を示す情報が前記事前条件を満たし、且つオペレーション実行後に、そのオペレーションの実行対象である構成要素の状態を示す情報が前記事後条件を満たしているが、各構成要素のうち、オペレーション実行後の状態を示す情報が前記事後状態を示す情報と一致していないものが存在している想定外副作用が発生した状態である場合に、コンピュータシステムの各構成要素の実際の状態を示す情報が前記事後状態を示す情報と一致していないと判定することを特徴とする請求項１１記載のシステム運用管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータシステムの運用管理技術に関する。
【背景技術】
【０００２】
近年、様々なサービスの提供によりコンピュータシステムが社会で担う役割が大きくなってきており、そのシステムは大規模化且つ複雑化してきている。そして、このように複雑化したシステムを人手で管理するのは非常に困難であり、運用管理におけるオペレーションに起因するシステム障害が後を絶たない。例えば、システムのダウンタイムの75%が、人手によるオペレーションに起因するという報告もある（非特許文献１）。このため、このようなオペレーションミスを減らすべく、運用管理を行うオペレーションを組み合わせた運用管理手続きをシステムに定義しておき、その運用管理手続きに従って運用管理を行なう、という手法が採用されている。【０００３】
ところで、コンピュータシステムの構成は、リソースの増強やセキュリティ強化などの理由により頻繁に変更されるものである。このため、システムにおいて定義された運用管理手続きは、このようなシステム構成の変更と整合性がとれるように修正される必要がある。そうしなければ、運用管理手続きに従ってオペレーションを行った結果、システムの実際の状態との不整合により障害が発生する可能性があるからである。このようなシステム構成の変更にあわせた運用管理手続きの修正を管理者が容易に行うことができるようにするため、システム構成の変更により運用管理手続きが何らかの影響を受ける場合、その影響の原因及び影響度合を示す情報を管理者に提供する技術がある（特許文献１）。
【特許文献１】特開２００７−８７２３２号公報
【非特許文献１】A.Brown, A Recovery-Oriented Approach to Dependable Services: Repairing Past Errors with System-Wide Undo, UC Berkeley Computer Science Division Technical Report, 2003.
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、システム構成の変更による運用管理手続きへの影響の原因及び影響度合を示す情報が管理者に提供されたとしても、それを参照した管理者が、適切に運用管理手続きを修正できないのが実状である。即ち、近年のシステムの複雑化により、システムのある構成要素に変更がなされると、その変更による運用管理手続きへの影響は、変更した構成要素のみならず、他の構成要素まで広範囲に及ぶことが多い。その一方で、例えばデータベースサーバやネットワーク等、システムにおける個々の構成要素自体が、高度な技術を用いた複雑なものになってきている。このため、これらの各構成要素の管理者たるドメインエキスパートには、その担当分野に特化した高度な知識が要求される。しかし、その反面、各管理者の担当外の分野の知識は乏しくなりがちである。このような状況では、管理者が、システム構成の変更により運用管理手続きが受ける影響の原因等を示す情報を参照しても、その影響が自分の担当外の構成要素の運用管理手続きに及んでいる場合には、運用管理手続きをどのように修正するべきかを正しく判断することは難しい。【０００５】
また、前述のようにシステムが複雑化しているため、運用管理手続きが修正されて新たなオペレーションが実行された結果、さらに他の構成要素に影響が及ぶ可能性もある。しかし、管理者は、自分の担当外の構成要素に関する知識が乏しいため、これを正確に予測した上で運用管理手続きを修正することは難しい。
このように、管理者にとって、システムの実際の状態と整合性がとれるように運用管理手続きを適切に修正することは難しかった。このため、運用管理手続きに従ってオペレーションを行うことにより発生する障害を未然に防止することは困難であった。また、このようにして実際に障害が発生してしまった場合においても、管理者が運用管理手続きを適切に修正するのは同様に難しかった。現に、障害の大部分は、過去に発生したことのあるものであるという報告がなされている（Mark Brodie, et al., Quickly Finding Known Software Problems via Automated Symptom Matching, Proc. of ICAC’05, 2005）。これは、過去に発生した障害から得られる経験が、運用管理において適切に反映されていないことに起因すると考えられる。【０００６】
そこで、本発明では、運用管理手続きに従って運用管理がなされた結果、障害が生じた場合に、同じ障害の再発を回避することが可能な情報を提示して管理者が運用管理手続きを適切に修正することができるようにし、障害の低減を実現することを目的とする。
【課題を解決するための手段】
【０００７】
このため、開示のシステムにおいては、コンピュータシステムの運用管理を行うオペレーションを組み合わせた運用管理手続きと、運用管理手続きに従ってオペレーションを実行した結果として想定されるコンピュータシステムの各構成要素の事後状態を少なくとも特定可能な運用管理知識と、をデータベースに保存しておく。そして、その運用管理手続きに基づいてオペレーションが実行された結果としてのコンピュータシステムの実際の状態が想定される事後状態と異なるときに障害が生じたと判定する。さらに、障害が生じたときには、運用管理手続きにおいてオペレーションが実行された結果としてのコンピュータシステムの実際の状態をオペレーションの事後状態に一致させることが可能なオペレーションを導出する。そして、そのオペレーションを提示する。
【発明の効果】
【０００８】
開示のシステムによれば、コンピュータシステムの運用管理において、運用管理手続きに従ってオペレーションを実行した結果、システムの実際の状態と整合性がとれていないことに起因して障害が生じたとき、その運用管理手続きにおいてこの障害を回避できるようなオペレーションが提示される。このため、管理者は、提示されたオペレーションを当該運用管理手続きに反映させるように修正すれば、運用管理手続きを適切に修正することができる。従って、各構成要素が相互に影響し合う複雑化したシステムであっても、システムの状態に合わせて運用管理手続きが適切に修正され、一度生じた障害が再発することを回避することができる。
【図面の簡単な説明】
【０００９】
【図１】システム構成変更の事例の概念図
【図２】システム構成変更時の状態遷移モデルの説明図
【図３】代替運用管理手続き及び代替オペレーション知識を示した説明図
【図４】運用管理装置の構成の説明図
【図５】運用管理手続き及びオペレーション知識を修正する流れを示した概念図
【図６】運用管理手続き及びオペレーション知識の修正方法を提示する処理を示すフローチャート
【図７】目標未達成の場合におけるシステム状態を示す説明図であり、（Ａ）は想定された状態、（Ｂ）はオペレーション実行後の実際の状態
【図８】想定外副作用の場合におけるシステム状態を示す説明図であり、（Ａ）は想定された状態、（Ｂ）はオペレーション実行後の実際の状態
【図９】運用管理手続き及びオペレーション知識の修正方法を提示する画面の説明図
【符号の説明】
【００１０】
１０    運用管理装置
１０Ａ  運用管理手続きＤＢ
１０Ｂ  ＳＫＤＢ
１０Ｃ  ＣＭＤＢ
１０Ｄ  実行結果チェック部
１０Ｅ  サブゴール状態推定部
１０Ｆ  修正方法導出部
１０Ｇ  修正方法提示部
【発明を実施するための最良の形態】
【００１１】
以下、添付された図面を参照して本発明を詳述する。
【００１２】
１．  システムの運用管理における問題
まず、本発明を適用すべき背景となる、システムの運用管理における問題点について説明する。ここでは、１つの事例を挙げると共に、その問題点を定式化して説明する。
【００１３】
１−１  システム変更事例の概要
図１は、企業の業務システムの運用管理においてシステム構成を変更する１つの事例を示す。この事例における運用管理対象システムは、アプリケーションサーバ，データベース（以下、「ＤＢ」という）サーバ，クライアント及びそれらを接続するインフラストラクチャを含んでいる。このようなシステムにおいて、ＤＢサーバの性能がボトルネックになっているため、満たされるべきサービスレベル（Service Level Agreement：以下、「ＳＬＡ」という）が満たされていないような状況を想定する。そして、ＤＢサーバのチューニングにより、ＳＬＡを改善するような場合について考える。【００１４】
このとき、ＤＢサーバの管理者により、ＤＢサーバの性能を改善して問題を解決するために、次のような運用管理手続きが設定され、実行されたとする（１）。
手順１：  ＤＢサーバの設定ファイル（configuration file）を変更する。
手順２：  ＤＢサーバを再起動する。【００１５】
しかし、管理者により手順１で設定ファイルが変更されたときに、その変更内容に文法的ミスがあったとする。この場合、手順２でＤＢサーバがリセットされても、ＤＢサーバが再起動しない（２）。このとき、運用管理手続きは、次のように修正されるべきである（３）。
（修正１）
手順１：  ＤＢサーバの設定ファイルを変更する。
手順２：  設定ファイルの文法チェックをする。（追加）
手順３：  ＤＢサーバを再起動する。
このように運用管理手続きが変更されれば、ＤＢサーバの再起動は成功し、ＤＢサーバの性能は向上する。【００１６】
しかし、これにより、今度はＤＢサーバの性能が向上したためにユーザリクエストが増加し、ネットワークに負荷がかかった場合を想定する。この場合、ＤＢサーバでなく、ネットワークがボトルネックになり、定められたＳＬＡを満たせなくなる（４）。そこで、運用管理手続きはさらに次のように修正される必要が生じる（５）。
（修正２）
手順１：  ＤＢサーバの設定ファイルを変更する。
手順２：  設定ファイルの文法チェックをする。
手順３：  ネットワークの帯域を増強する。（追加）
手順４：  ＤＢサーバを再起動する。
このように運用管理手続きが修正されれば、ようやく問題なくシステムが稼動する（６）。【００１７】
しかし、管理者が当初からこれらの障害が生じることを予測することは難しく、適切な運用管理手続きを定義することは困難である。特に、管理者たるドメインエキスパートの担当外の構成要素に関する問題については、障害が生じた後においても、その原因を特定することが難しく、運用管理手続きを適切に修正することは困難である。【００１８】
また、一度生じた障害と同様の障害が発生するのを防ぐためには、運用管理手続きに含まれるオペレーションに着目し、そのオペレーションが含まれる他の運用管理手続きについても、修正を行う必要がある。例えば、１−１節の事例の場合、ＤＢサーバの再起動を行なうオペレーションが含まれる他の運用管理手続きについても、同様の修正がなされるべきである。即ち、ＤＢサーバの設定ファイルに変更を加えた場合には、その後に設定ファイルのチェックを行った場合のみに再起動が許されるように修正がなされるべきである。しかしながら、これまでは、管理者が場当たり的に個々の運用管理手続きを修正するに過ぎず、システム全体としての体系的な改善は行なわれていなかった。
なお、この事例においては、企業の業務システムの運用管理を挙げているが、本発明が適用される運用管理対象のシステムは、このような構成のものに限られない。
【００１９】
１−２  システム変更により発生する問題の定式化
１−１節の事例のように、システムの運用管理において、何らかの作業を行ってシステムに変更を加えたときに問題が発生した場合、その問題は大きく分けて（Ａ）目標未達成、（Ｂ）想定外副作用、の２つに分類できる。【００２０】
（Ａ）の目標未達成は、システムに対して変更を加えても、変更されるべきところが期待通りに変更されなかったという場合を指す。例えば、１−１節の事例の場合、管理者は、設定ファイルを変更してＤＢサーバを再起動すれば、ＤＢの更新が完了すると考えていた。しかし、実際には、設定ファイルの変更時に管理者により設定ファイルのチェックがなされなかったために、文法ミスが見逃され、ＤＢサーバを再起動できなかった。このため、想定していたＤＢの更新が完了しなかった。このような問題は、事前に必要な準備や満たすべき事前条件を管理者が正しく把握せずに変更作業を行った場合に、発生しやすい。【００２１】
（Ｂ）の想定外副作用は、オペレーションの結果として期待していた変更結果は得られたものの、その結果が想定外の望ましくない変化をさらに引き起こしたような場合を指す。例えば、１−１節の事例においては、システムの性能を上げるために、ボトルネックになっているＤＢサーバの設定を変更した結果、ユーザリクエストが増加するという想定外の事象が引き起こされる。そして、今度はネットワークがボトルネックになってしまうという状況が発生する。この問題は、システムに対して行う変更の影響範囲について、管理者が正しく想定せずに変更作業を行った場合に発生することが多い。そして、この問題は、上述のように、システムを構成する要素ごとにその管理者たるドメインエキスパートが決まっており、ドメインエキスパートがシステムに対して行うオペレーションによる他の構成要素への影響を正しく把握していないことに起因する。【００２２】
（Ａ）の目標未達成及び（Ｂ）の想定外副作用の相違点を簡潔に述べると、システムに対して変更を加えた際に、（Ａ）は「変わるべきところが変わらなかった」、（Ｂ）は「変わるべきではないところが変わってしまった」と表現することができる。これらの問題を状態遷移モデルで示すと図２のように表現することができる。【００２３】
一般に、管理者がシステムに対して行うあるオペレーションαに対して、そのオペレーションを実行する前提となる事前条件Preと、オペレーションを実行した結果、そのオペレーションの実行対象である構成要素において少なくとも満たされるべき事後条件Postと、を想定した場合、オペレーションαを実行すると、システムの状態は、事前条件を満たし且つ事後条件を満たさない状態（¬Post∧Pre）から事後条件を満たす状態（Post）へ移行する。これは、図２の状態s1からd1への遷移T1のように表される。【００２４】
しかし、実際には、上記の（Ａ）目標未達成のように、オペレーション実行前のシステムの状態の不備により、オペレーションを実行しても、想定した事後条件を満たさない場合がある。即ち、オペレーションを実行するときに必要な事前条件の中に、管理者が気づいていないものが存在し、且つシステムの状態がその事前条件を満たしていない場合（¬Unnoticed）である。この場合は、状態s2からd2への遷移T2のように、オペレーションαを実行しても、事後条件Postを満たす状態へ到達できないような状況としてモデル化することができる。【００２５】
また、上記の（Ｂ）想定外副作用のように、オペレーションの実行対象である構成要素の状態は想定した事後条件を満たすものの、他の構成要素において、想定外の変化が生じる場合がある。１−１節の事例では、（修正１）で運用管理手続きを修正したことにより、想定していたＤＢの性能向上という目標は達成したものの、その結果、リクエストの増加とネットワークの性能不足という想定外の変化が生じたという状況が該当する。このような状況は、オペレーションを実行した結果、システムの状態は想定された事後条件Postを満たす状態へ遷移したものの、遷移前には生じていなかった別の問題が発生したと考えることができる。そして、この状況は、オペレーションαによって、状態s3からd3へ遷移する遷移T3のようにモデル化できる。ここでは、遷移前に満たされていた状態を満たさなくしてしまう要因が存在している（¬Factor∧Requisite）。しかし、その要因がオペレーションの実行前に管理者により見落とされていたことで、オペレーションが実行された結果、制約違反状態（¬Requisite）になったと考えることができる。
【００２６】
２．  運用管理手続き及びオペレーション知識の修正を行なう運用管理装置の概要
図３は、上述のような問題を回避可能な運用管理装置１０の構成を示す。運用管理装置１０は、少なくとも中央処理装置（ＣＰＵ）とメモリとを備えたコンピュータ上に構築される。また、運用管理装置１０は、運用管理手続きＤＢ１０Ａと、運用管理知識ＤＢ（System management knowledge database：SKDB，以下、「ＳＫＤＢ」という）１０Ｂと、構成管理ＤＢ（System configuration management database：CMDB，以下、「ＣＭＤＢ」という）１０Ｃと、を含む。さらに、運用管理装置１０では、メモリにロードされた運用管理プログラムが実行されることで、実行結果チェック部１０Ｄと，サブゴール状態推定部１０Ｅと，修正方法導出部１０Ｆと，修正方法提示部１０Ｇと、が夫々実現される。【００２７】
運用管理手続きＤＢ１０Ａは、コンピュータシステムを運用管理する複数のオペレーションからなる運用管理手続きが保存されるものである。オペレータは、この運用管理手続きに従ってオペレーションを実行させる。
ＳＫＤＢ１０Ｂは、各オペレーションについて、オペレーションの内容、オペレーションが実行可能な事前条件Pre及びオペレーション実行後の事後条件Postを示すオペレーション知識（operation knowledge）を含む。また、システムにおいて必然的に成立する各構成要素の相関関係、即ち、システムの特性上必然的に成立する関係や、常に守らなければならないパラメータの制約が、論理式等の形式で表現される状態知識（condition knowledge）を含む。なお、オペレーション知識及び状態知識のデータの具体例については後述する。
ＣＭＤＢ１０Ｃは、システムの各構成要素の実際の状態に関する情報がメタデータとして統合されて保存されるものであり、公知技術を用いたものである（例えば、CMDB Federation, http;//www.cmdbf.org/ に開示されている）。【００２８】
実行結果チェック部１０Ｄは、管理者により運用管理手続きが修正され、その運用管理手続きに基づいてオペレーションが行われたときに、ＣＭＤＢ１０Ｃに保存されたシステムの状態に関する情報とＳＫＤＢ１０Ａのオペレーション知識によって定められる想定された事後状態とを照合し、両者の差分を検出する。なお、実行結果チェック部１０Ｄが、判定手段及び判定ステップに相当する。
サブゴール推定部１０Ｅは、ＣＭＤＢ１０Ｃに保存されたシステムの実際の状態に関する情報とＳＫＤＢ１０Ｂのオペレーション知識によって特定される想定された事後状態とに差分が検出された状態、即ち、予期せぬ結果（障害）が生じた状態のときに、当該予期せぬ結果を回避することが可能なサブゴール（sub-goal）状態を推定する。
修正方法導出部１０Ｆは、推定されたサブゴール状態へ至ることが可能なオペレーションを導出すると共に、これが反映（追加）された代替運用管理手続きを、運用管理手続きの修正方法として導出する。また、修正方法導出部１０Ｆは、サブゴール状態を満たす条件で事前条件を修正した代替オペレーション知識を、オペレーション知識の修正方法として導出する。
なお、サブゴール推定部１０Ｅ及び修正方法導出部１０Ｆが、導出手段及び導出ステップに相当する。
修正方法提示部１０Ｇは、修正方法としての代替運用管理手続き及び代替オペレーション知識を管理者に提示する。なお、修正方法提示部１０Ｇが、提示手段及び提示ステップに相当する。【００２９】
図４は、このような運用管理装置１０を用いて、運用管理手続き及びオペレーション知識を更新する流れの概念図である。まず、運用管理知識を更新する処理を行なう前提として、運用管理の対象となるシステムの各構成要素（ネットワーク、アプリケーション、データベース等）の管理者たるドメインエキスパートの専門知識が、ＳＫＤＢ１０Ｂへ集約されている（１）。【００３０】
また、システムに対して何らかの変更を加える際には、ドメインエキスパートが、システムに対して実行するオペレーションを組み合わせて、運用管理手続き（System management procedure）を定義し、運用管理手続きＤＢ１０Ａに保存する（２）。オペレータは、その運用管理手続きに基づき、システムに対して運用管理のオペレーションを行う（３）。このオペレーションには、オペレータによるコマンド実行やバッチ処理の実行が含まれる。そして、オペレーションを行った結果としてのシステムの各構成要素の状態を示す情報が、ＣＭＤＢ１０Ｃに保存される（４）。さらに、実行結果チェック部１０Ｄで、そのＣＭＤＢ１０Ｂに保存された各構成要素の状態（システム構成情報）を参照する（５）。また、実行結果チェック部１０Ｄでは、ＳＫＤＢ１０Ｂのオペレーション知識及び状態知識に基づいて、オペレーションを実行した結果として想定されるコンピュータシステムの各構成要素の事後状態を特定する。そして、その事後状態及びＣＭＤＢ１０Ｃに保存された各構成要素の状態を比較し、両者が一致していない場合は、予期せぬ結果、即ち、障害が生じたと判定する。その場合には、サブゴール状態推定部１０Ｅが、その障害が生じた状態を回避することが可能なサブゴール状態を推定する（７）。さらに、修正方法導出部１０Ｆが、そのサブゴール状態へ至ることが可能であるオペレーションが反映された代替運用管理手続き及びサブゴール状態を満たす条件を事前条件とした代替オペレーション知識を、運用管理手続き及びオペレーション知識の修正方法として導出する（８）。そして、修正方法提示部１０Hが、その修正方法を管理者に提示する（９）。管理者は、提示された修正方法で運用管理手続きＤＢ１０Ａの運用管理手続き及びＳＫＤＢ１０Ｂのオペレーション知識を修正する（１０）。【００３１】
なお、図５は、１−２節で示した状態遷移モデルの例において、運用管理手続き及びオペレーション知識を修正する方法について示した概念図である。図５に示すように、あるオペレーションαについて、当該オペレーションαが、必要な事前条件を満たしており、且つ、想定外副作用を引き起こす要因を解決するような場合のみに実行されるように、事前条件に修正を加えた代替オペレーション知識α’を導出して提示する。また、この事前条件を満たすことが可能なオペレーションを運用管理手続きに反映させた代替運用管理手続きを導出して提示する。【００３２】
このように代替運用管理手続きが提示され、運用管理手続きに反映すべきオペレーションが具体的に提示されることで、管理者は、自らの担当外の構成要素が運用管理対象として含まれる場合であっても、適切に運用管理手続きを修正することができる。また、実行されたオペレーションについて、代替オペレーション知識が提示され、管理者がこれをオペレーション知識に反映させることで、同じオペレーションが含まれる他の運用管理手続きについても、同様の修正が行うことができる。このため、さらなる障害の低減を実現することができる。
【００３３】
３．  運用管理知識の表現方法
ここでは、運用管理知識としてのオペレーション知識及び状態知識について、定義及びモデル化する。その上で、上述した本発明の運用管理装置で用いる各知識の表現方法について、１−１節の事例を用いて説明する。
【００３４】
３−１  システムモデルの定義
運用管理知識を修正する処理においては、システムの状態と、そのシステムに対するオペレーションによって発生するシステムの状態の変化を、〈S，R，L，Σ〉という４項組みの状態遷移モデルによってモデル化する。Sはシステムの全ての状態の集合であり、Lは、Sの各状態 s∈S から、その状態において成立している性質（property）を表す命題の集合Ｐへの写像である(L:S→2P)。各状態におけるシステムの性質を表す命題の真理値は、ＣＭＤＢ１０Ｃに格納されているパラメータの値からすべて決定可能であると仮定する。例えば、ＳＬＡを満たしているという事象を表す述語があり、これはＣＭＤＢ１０Ｃに格納されているシステムのレスポンスタイムを表すパラメータResの値が1.0以上であれば偽で、それ未満であれば真であると定義されているものとする。このとき、ある状態sにおいて Res=0.5 であれば、その状態においては Satisfied(SLA)=True となる（s|=Satisfied(SLA)）。
また、R⊆S×Σ×Sは、システムに対して実行可能なアクション（Σ）と、それによる状態の変化を表す。例えば、システムの再起動という操作により、システムの状態がsからs’に変化する場合、（s,Reset,s’）∈Rである。
【００３５】
３−２  オペレーション知識（Operation Knowledge）
オペレーション知識は、ドメインエキスパートが想定しているシステムに対するオペレーションとその結果の状態変化を表す。具体的には、システムに対する不可分（atomic）なオペレーションOpiを、Opi =〈Prei，Acti，Posti〉という3項組で定義する。ActiはオペレーションOpiによってシステムに対して実行されるアクション、PreiとPostiはそれぞれアクションActiを実行する前提としての事前条件と、オペレーションの実行後の状態において真になることが想定される事後条件の述語論理式であり、正もしくは負のリテラル(単一の述語)のand結合によって構成される乗法標準形（conjunctive normal form：CNF、以下「ＣＮＦ」という）で表されるものとする。つまり、このオペレーション知識においては、s|= Preiである状態 s において、Actiというアクションを実行したら、s’|= Postiである状態 s’ へシステムの状態が変化することが、ドメインエキスパートによって想定されていることを表す。例えば、１−１節の事例における、「ＤＢの設定ファイルを編集すると、設定ファイルが変更される」というオペレーションは、以下のOpcfgDBのように定義できる。
OpcfgDB=〈¬changed(DBcfg), edit_DBcfg, changed(DBcfg)〉
【００３６】
なお、ここで注意が必要なのは、オペレーション知識は、管理者たるドメインエキスパートが想定している状態変化であり、それが必ずしも正しいとは限らないということである。つまり、〈f1，Actx，f2〉∈Onであり、 s1|=f1 且つ s2|=f2 であっても、
【数１】
0005434908.tif 000002
となる場合もありうる。また、以下では直感的な理解の助けのために、オペレーション知識Opi=〈Prei，Acti，Posti〉を、（Acti; Prei→Posti）と記述可能であるとする。【００３７】
１−１節の事例においては、上記のOpcfgDBの他にも、以下のようなオペレーションが定義されていると仮定する。
OprbtDB:（reboot_DB; ¬updated(DB)∧changed(DBcfg) → updated(DB)）
OpchkDB:（chkcfg_DBcfg; changed(DBcfg) → checked(DBcfg)）
OpupdNW:（update_NW; ¬updated(NW) → updated(NW)）
【００３８】
上記のOprbtDBは、ＤＢサーバの更新が終了していない状態で、且つＤＢサーバの設定ファイルが変更された状態において、サーバを再起動することにより、更新が完了するというオペレーションを表している。OpchkDBは、ＤＢサーバの設定ファイルが変更されている状態で、ＤＢサーバの設定チェックを行うことにより、ＤＢサーバの設定ファイルが正しいことが確認されるというオペレーションを表している。OpupdNWは、ネットワークの更新作業を行った後には、ネットワークの更新が完了した状態になるというオペレーションを表している。【００３９】
このようなオペレーション知識がＳＫＤＢ１０Ｂに集約されて保存されていることにより、管理者は、自らの担当外の構成要素に対するオペレーションについても、そのアクション、事前条件及び事後条件について知ることができる。このため、管理者が各オペレーションを組み合わせて運用管理手続きを定義するときに、このオペレーション知識を参照することで、適切なオペレーションを組み合わせることができるようになる。
【００４０】
３−３  状態知識（Condition knowledge）
状態知識（Condition knowledge）は、システムの各構成要素において必然的に満たされる相関関係（性質）を論理式で表したものである。この状態知識は、具体的には、各構成要素において生じる事象やパラメータ間の相関関係などが該当する。また、この状態知識は、各ドメインエキスパートが持っているシステムに関する知識や、サービス全体の責任者等によって決定される、求められるサービス品質要求定義などから抽出されるものとする。この状態知識を表す論理式の真理値は、システムが到達可能な全ての状態において真であることを仮定する。もしそれらが偽になる状態にシステムが到達した場合には、その状態知識が誤っているか、もしくはサービス品質などのシステムに対して求められる条件が満たされなくなった等の問題が発生したような事態を意味する。【００４１】
１−１節の事例においては、ＤＢサーバの管理者とネットワークの管理者、サービス全体の管理者が、それぞれ以下のような別々の状態知識を有しており、これをＳＫＤＢ１０Ｂの状態知識として保存されていたとする。
【００４２】
（１）ＤＢサーバ管理者知識
CDB1: satisfied(SLA) → enoughcapacity(DB)
CDB2: updated(DB) → checked(DBcfg)
CDB3: updated(DB) → enoughcapacity(DB)
CDB1は、サービスのＳＬＡが満たされているならば、ＤＢサーバは十分な性能を有しているという知識を示す。また、CDB2は、ＤＢサーバが更新されている状態であれば、その設定ファイルはチェック済であるべきであるという知識を示す。また、CDB3は、ＤＢサーバの更新が完了したら、そのＤＢサーバは十分な性能を有しているという知識を示す。
【００４３】
（２）ネットワーク管理者知識
CNW1: satisfied(SLA) → enoughcapacity(NW)
CNW2: updated(NW) → enoughcapacity(NW)
CNW1は、サービスのＳＬＡが満たされているならば、ネットワークは十分な性能を有しているという知識を示す。また、CNW2は、ネットワークが更新されている状態であれば、そのネットワークは十分な性能を有しているという知識を示す。
【００４４】
（３）サービス責任者知識
CSM1: enoughcapacity(NW)∧enoughcapacity(DB) → satisfied(SLA)
CSM1は、ネットワークとＤＢサーバの両方が十分な性能を持っていれば、ＳＬＡは満たされるという知識を示す。
【００４５】
このような状態知識がＳＫＤＢ１０Ｂに集約されて保存されていることにより、管理者は、自らの担当外の構成要素に関しても、システムの性質上必然的に満たされる条件について知識を得ることができる。このため、管理者が各オペレーションを組み合わせて運用管理手続きを定義するときに、この状態知識を参照することで、適切なオペレーションを組み合わせることができるようになる。
【００４６】
３−４  運用管理手続き（System management procedure）
３−２節において、システムに対して実行可能なオペレーションをオペレーション知識として定義した。ここで、一般的にシステムに対してある変更を加えるような場合には、目的とする作業に対して前処理や後処理が必要になることが多い。よって、管理者は、システムに対して何らかの変更を加える際には、オペレーション知識に蓄積されているオペレーションを組み合わせて、運用管理手続きを定義する。ここでは説明を簡略にするために、運用管理手続き（System management procedure）には条件分岐やループなどは存在せず、オペレーション知識内にあるオペレーションの列によって構成されるものとする。ただし、運用管理手続きにおいて、あるオペレーションの事後状態と、その次のオペレーションの事前条件の間に矛盾がないものとする。具体的には、手続きPr = (Op1,Op2,…,Opn) がｎ個のオペレーションで構成されているとき、
SiPost={s|s|=Posti}、Si+1Pre={s|s|=Prei+1} とすると、SiPost∩Si+1Pre≠{} でなければならない。【００４７】
１−１節の事例において、ＤＢサーバの管理者がＤＢサーバの性能不足を解消するために定めたＤＢサーバの更新を行なう運用管理手続きは、（１）ＤＢサーバの設定変更（２）サーバの再起動という２つの作業によって構成されているため、Pr=(OpcfgDB,OprbtDB) と定義できる。
【００４８】
４．  運用管理手続き及びオペレーション知識の修正方法を提示する処理の流れ
ここで、運用管理装置１０において実行される運用管理手続き及びオペレーション知識の修正方法を提示する処理について、図６に示すフローチャートを用いて説明する。なお、運用管理手続きＤＢ１０Ａには運用管理手続きが、ＳＫＤＢ１０Ｂにはオペレーション知識及び状態知識が夫々保存されていることを前提とする。そして、この処理は、運用管理手続きに従ってオペレーションが実行された後に実行される。【００４９】
ステップ１（図では「Ｓ１」と略記する。以下同様）では、実行された運用管理手続き及びＳＫＤＢ１０Ｂに保存されたオペレーション知識に基づいて、当該運用管理手続きにおいて想定されるオペレーション実行後の事後状態を特定する。
ステップ２では、ＣＭＤＢ１０Ｂを参照し、オペレーション実行後のシステムの各構成要素の実際の状態と、ステップ１で特定した事後状態と、を比較する。
ステップ３では、オペレーション実行後のシステムの各構成要素の実際の状態と、ステップ１で特定した事後状態が一致するか否かを判定する。両者が不一致であれば、ステップ４に進み（Ｙｅｓ）、両者が一致すれば、処理を終了する（Ｎｏ）。
なお、ステップ１〜３が実行結果チェック部１０Ｅによって実行され、判定手段及び判定ステップに相当する。【００５０】
ステップ４では、オペレーションの実行対象である構成要素が、オペレーション知識の事後条件を満たしていない状態、即ち、（Ａ）目標未達成であるか否かを判定する。（Ａ）目標未達成であれば、ステップ５に進み（Ｙｅｓ）、オペレーションの実行対象である構成要素が、オペレーション知識の事後条件を満たしている（Ｂ）想定外副作用の場合は、ステップ６に進む（Ｎｏ）。
ステップ５では、オペレーション実行後の状態とステップ１で特定した事後状態との差分から、システムが望ましい状態へ到達するために必要な（見落としていた）事前状態を推定する。【００５１】
ステップ６では、オペレーション実行後の状態とステップ１で特定した事後状態との差分から、想定していなかった副作用を推定する。
ステップ７では、ステップ５で推定した事前状態又はステップ６で推定した副作用を解消した状態をサブゴール状態として推定する。そして、運用管理手続き中でそのサブゴール状態を満たす条件で、オペレーション知識の事前条件を修正した代替オペレーション知識を導出する。また、その事前条件を満たすことが可能なオペレーションを導出し、それを運用管理手続きに反映させた代替運用管理手続きを導出する。
なお、ステップ４〜７が、サブゴール状態推定部１０Ｆ及び修正方法導出部１０Ｇにより実行され、導出手段に相当する。
ステップ８では、ステップ７で導出した代替運用管理手続き及び代替オペレーション知識を管理者に提示する。なお、ステップ８が、修正方法提示部１０Ｇにより実行され、提示手段及び提示ステップに相当する。
以下、上記の処理について、１−１節の事例を用いつつ、（Ａ）及び（Ｂ）の場合に分けて夫々詳述する。
【００５２】
４−１  （Ａ）目標未達成の場合
運用管理手続き（Op1,Op2,…Opn）において、m番目のオペレーションOpm(1≦m≦n)の実行後の実際の事後状態が、オペレーション知識で想定されていた事後条件Postmと異なっていた場合を考える。このような場合、まず、オペレーション知識で想定された事後状態と、ＣＭＤＢ１０Ｃに保持されている実際のシステムの状態の差分を明らかにする必要があるので、運用管理手続きにより定義されたオペレーションの列を実行した場合に、想定されたシステムの事後状態を導出する。具体的には、各オペレーションOpi=〈Prei，Acti，Posti〉における想定された事前状態eiPreと事後状態eiPostを、その状態において成立している述語の集合として、下記のアルゴリズムにより導出する。
【００５３】
段階１：初期設定
i=1, e0Post = Premise  とする。
段階２：事前状態の生成
eiPre = ei-1Post ∪ A(Prei)
段階３：事後状態の生成
eichanged = {l|l∈eiPre, ¬l∈A(Posti)}∪{¬l|l∈eiPre, l∈A(Posti)}
eiPost = Closure((eiPre−eichanged)∪A(Posti))
段階４；繰り返し
i++; goto 段階２ until i=m
【００５４】
上記アルゴリズムにおいて、Premiseは、運用管理手続きの実行前の状態において成立していることが想定されているリテラルの集合である。また、関数Aは、ＣＮＦ形式の論理式から、その論理式に含まれるリテラルの集合への写像A(P1∧P2∧…Px) = {P1,P2,…,Px}であり、関数Closureは、述語の集合から、その述語と状態知識から導出可能な述語の集合への写像である。【００５５】
上記アルゴリズムにおいては、まず、段階１の初期設定で、最初のオペレーションOp1の実行前に成立している論理式の集合Premiseをe0Postとする。次に、段階２では、Opi-1の実行後に成立している論理式と、Opiの事前条件Preiとの和集合により、Opiの実行前の状況において成立していると想定される論理式の集合eiPreを算出する。段階３においては、オペレーションOpiの実行の前後で真理値が変化することが期待されている述語の集合eiChangedを算出する。そして、それをeiPreから除いたものと、Opiの事後条件Posti及び、それらと状態知識によって導出可能な述語の集合により、Opiの実行後の事後状態eiPostを算出する。上記の計算を、i = mとなるまで繰り返すことで、各オペレーションの実行前と実行後に夫々成立していることが想定される事前状態及び事後状態を特定することができる。【００５６】
１−１節の事例において特定される、想定された事後状態を図７（Ａ）に示す。これは、ＤＢサーバがボトルネックになっているという初期状態Premise = {¬enoughcapacity(DB), enoughcapacity(NW)} において、定められた運用管理手続きPr = (OpcfgDB,OprbtDB) を実行したときにおける、各オペレーションの事前状態及び事後状態として想定された状態である。表において、「T」と示されているものは、想定された各状態においてそれが含まれている論理式であり、「F」で示されているものは、その否定が含まれているものである。例えば、オペレーションOpcfgDBとOprbtDBとを連続して実行した結果の状態を表すerbtDBPostにおいては、updated(DB) やsatisfied(SLA) が成立し、ＤＢサーバの更新が完了し、ＳＬＡが満たされているという状態が、運用管理知識によって想定されていたことを表す。【００５７】
一方で、実際のシステムの状態が保存されているＣＭＤＢ１０Ｃから、上記の論理式における実際の真理値状態（解釈）が導出可能であるとする。例えば、各オペレーションOpiを実際に実行した際の各オペレーションの事前状態と事後状態において成立している状態をＣＭＤＢ１０Ｃから導出してきたものを、それぞれsiPre、siPostと表す。そして、オペレーションOpiによって想定された結果が得られなかったということは、次のようなリテラルlが存在していたということを意味している。
【数２】
0005434908.tif 000003
【００５８】
例えば、１−１節の事例の場合には、図７（Ｂ）のような真理値表が得られたとする。この結果におけるオペレーションの事後状態srbtDBPostと、図７（Ａ）のerbtDBPostと、を比較すると、後者ではオペレーションOprbtDBの実行後にはupdated(DB)が真になっているが、前者では偽のままである(図７（Ｂ）の実線円で囲われた箇所)。これは、運用管理手続きに従い、ＤＢサーバに変更を加える作業をしたが、ＤＢサーバが正しく再起動せず、想定通りに更新が完了しなかったことを表している。【００５９】
このような場合、各構成要素の実際の状態と想定された事後状態の情報の差分を抽出し、その情報から、オペレーション知識において欠落していた、オペレーションの事前条件を導出する。具体的には、オペレーション知識で想定されているOpiの事後条件Posti以外にも、想定とは異なる結果になっている命題があれば、それらを抽出し、それらの中に目的が達成されない原因(unnoticed condition)があると仮定する。そして、その差分が解消された状態をサブゴール状態として設定し、問題の発生したオペレーションを実行する前に、そのサブゴール状態に到達するように、運用管理手続き及びオペレーション知識に修正を加える。【００６０】
その処理を以下にさらに具体的に示す。オペレーション によって想定された結果が得られなかった場合、各構成要素の実際の状態smPostと想定された事後状態emPostにおいて真理値が異なるリテラルの集合のうち、オペレーション知識の事後状態A(Postm)には含まれていないものを抽出する。これは、次のように表すことができる。
【数３】
0005434908.tif 000004
【００６１】
そして、Opm-1の事後状態で成立している述語の集合em-1Postに、上記のDの一部である「U⊆D」を加えたものを、サブゴール状態 esgoal として下記のように定義する。ただし、ei-1Postに「¬d∈U」が含まれる場合は、それを取り除く。また、状態知識により矛盾が導かれるものは、サブゴール状態とみなさない。
【数４】
0005434908.tif 000005
【００６２】
１−１節の事例の場合には、図７（Ａ）のerbtDBPostと図７（Ｂ）のsrbtDBPostを比べると、D = {checked(DBcfg), enoughcapacity(DB), satisfied(SLA)} （図７（Ｂ）の破線円で囲われた箇所）であることがわかり、これらのいずれかがOprbtDBの実行後の状態で偽であることが、その状態でupdated(DB) が成立していない原因として推測する。よって、上記の条件を満たすサブゴール状態として、以下の３つのサブゴール状態が候補として想定される。
e1sgoal = {changed(DBcfg), checked(DBcfg), ¬enoughcapacity(DB),
enoughcapacity(NW), ¬satisfied(SLA)}
e2sgoal = {changed(DBcfg), enoughcapacity(DB),
enoughcapacity(NW), satisfied(SLA)}
e3sgoal = {changed(DBcfg), checked(DBcfg), enoughcapacity(DB),
enoughcapacity(NW), satisfied(SLA)}
上記サブゴール状態の導出において、satisfied(SLA) を含みながら、¬enoughcapacity(DB) もしくは¬enoughcapacity(NW) を含むような状況は、状態知識CSM1と矛盾するので、サブゴール状態とはみなさない。【００６３】
上記のようにサブゴール状態を設定したら、そこへ至る手続きをプランニング（planning）によって導出する。なお、プランニングとは、Opm-1の事後状態em-1Postから、上記サブゴール状態のいずれかへ到達可能なオペレーションの列を導出する作業のことであり、「K.E.Maghraoui, et al., Model Driven Provisioning: Bridging the Gap Between Declarative Object Models and Procedural Provisioning Tools, Proc. of Middleware 2006, 2006.」に記載の手法等を利用することができる。ここで、この作業は、オペレーションOpmにより発生した問題を解決するものであるので、上記オペレーションの列においては、Opmは含まないようにするものとする。【００６４】
プランニングにより、オペレーションの列が導出されたら、その列を運用管理手続きのオペレーションOpmの前に挿入した代替運用管理手続きを提示する。また、そのサブゴール状態に含まれている U⊆D について、それらをオペレーション知識Opmの事前条件Preiに加えた代替オペレーション知識を提示する。
【００６５】
１−１節の事例の場合、サブゴールe2sgoalとeesgoalに至る手続き（enoughcapacity(DB)とsatisfied(SLA)を導く手続き）は、保存された知識からはプランニングにより導出不可能であったが、e1sgoalへ至るオペレーションの列としては、{OpchkDB}が候補として選択可能である。結果として、運用管理手続きPrと、オペレーション知識OprbtDBの修正方法、即ち、代替運用管理手続きPr’ 及び代替オペレーション知識Op’rbtDB としては、以下の内容が出力可能である。
Op’rbtDB(reboot_DB)：（¬updated(DB)∧changed(DBcfg)∧checked(DBcfg)
→updated(DB)）
Pr’ = (OpcfgDB, OpchkDB, Op’rbtDB)
これらの代替運用管理手続き及び代替オペレーション知識は、リブートによりＤＢサーバを更新する前には、必ず設定ファイルのチェックが必要であることを意味している。
【００６６】
このように、サブゴール状態を満たすことが可能なオペレーションが反映された代替運用管理手続きが提示されることで、管理者たるドメインエキスパートやサービスの責任者は、適切に運用管理手続きを修正することができる。このため、以降においてこの運用管理手続きを実行したときに、同じ障害が発生することを防ぐことができる。
また、事前条件が修正された代替オペレーション知識が提示され、これが管理者によってオペレーション知識に反映されることで、同じオペレーションを含む他の運用管理手続きにも同様の修正をすることが可能になり、他の運用管理手続きにおいても、同様の障害が発生することを防ぐことができる。
【００６７】
４−２  （Ｂ）想定外副作用の場合
次に、運用管理手続き（Op1,Op2,…Opn）において、m番目のオペレーションOpm（1≦m≦n）の実行後の実際の事後状態はPostmと合致しているものの、想定していなかったシステムの状態の変化により、上記のPostm以外の状態（property）に変化が起こり、想定外の結果が得られた場合について考える。【００６８】
この場合も、まず（Ａ）目標未達成の場合と同様にして、手続きに含まれる各オペレーションの前後において想定される事前状態及び事後状態を導出すると共に、ＣＭＤＢ１０Ｃから実際のシステムの情報を収集するものとする。例えば、１−１節の事例において、前節で示した修正済みの代替運用管理手続きPr’を実行した際に、想定された事後状態及び各構成要素の実際の状態が、夫々図８（Ａ）及び（Ｂ）のようになったとする。そして、想定された事後状態と実際の状態が異なり、かつオペレーションの前後でその真理値が変化したものを、想定外の変化が起きた命題の集合として、以下のようにして特定する。
【数５】
0005434908.tif 000006
【００６９】
１−１節の事例の場合は、D = {enoughcapacity(NW)} となる（図８（Ｂ）の実線円で囲まれた箇所）。また、これが原因で、satisfied(SLA) の真理値が図８（Ａ）及び（Ｂ）で異なる結果になっている（図８（Ｂ）の破線円で囲まれた箇所）。
発生した問題を回避するためには、上記のDの要素が、オペレーションOpmの実行後においても、真になっていることが保証されている必要がある。よって、これらが明示的に保証されるようにするサブゴール状態を設定し、そこを必ず通過するようにプランニングを行う。具体的には、以下の２つのサブゴール状態eAsgoal, eBsgoalを考える。
eAsgoal= em-1Post−D
eBsgoal= em-1Post
【００７０】
つまり、オペレーションOpm-1の実行後の状態において、Dの要素の真理値が不定であるようなサブゴールを設定し、その間を結ぶようなオペレーションの列を導出する。これにより、オペレーションOpm実行後にも、Dを成立させるための条件が満たされているので、Dが偽になることは無く、想定外の問題発生を回避することができる。【００７１】
上記の２つのサブゴール間を結ぶオペレーションの列（Op1sg,Op2sg,…Opnsg）をプランニングにより導出したら、それを、定義されたオペレーション（Op1,Op2,…Opn）のOpm-1とOpmの間に挿入する（Op1,…,Opm-1,Op1sg,…,Opxsg,Opm,…Opn）ことで、代替運用管理手続きの導出を行う。【００７２】
１−１節の事例の場合、enoughcapacity(NW) が成立していない(不確定の)状態eAsgoalから、それが成立している状態eBsgoalへの状態遷移のオペレーションの列としては、プランニングにより{OpupdNW}が選択可能である(OpupdNWの事後状態においては、updated(NW) が成立するため、状態知識CNW2により、enoughcapacity(NW) も成立する)。【００７３】
上記の運用管理手続きにおいて、オペレーションOpm-1とOpxsgの実行後に想定される状態em-1Postとesg_xPostを比較し、そこで成立している命題の差esg_xPost −em-1Postを特定する。それを、問題を回避するために必要な条件として抽出し、問題が発生したオペレーションOpmに加える。１−１節の事例の場合には、updated(NW)がそれに該当する。【００７４】
上記の変更を加えた結果、オペレーション知識と運用管理手続きは以下のように変更される。
Op’’rbtDB(reboot_DB)：（¬updated(DB)∧changed(DBcfg)∧checked(DBcfg)
∧updated(NW)  →updated(DB)）
Pr’’ = (OpcfgDB, OpchkDB, OpupdNW, Op’’rbtDB)
【００７５】
このように、運用管理手続きのオペレーションの直接の実行目的が達成されている場合のみならず、他の構成要素において想定外の状態変化が生じた場合であっても、障害の発生の再発を防ぐことが可能な代替運用管理手続きや代替オペレーション知識が提示される。このため、（Ａ）目標未達成の場合と同様に、管理者が運用管理手続きやオペレーション知識を適切に修正することができ、障害の低減を図ることができる。
【００７６】
５．  運用管理手続き及び運用管理知識の修正方法における具体的なデータ例
上述した知識を変更する方法について、具体的なデータ例を用いてさらに詳細に説明する。
【００７７】
５−１  入力
運用管理装置１０への入力としては、（１）運用管理手続きの定義（Procedure definition），（２）オペレーション知識（Operation knowledge），（３）状態知識（condition knowledge），（４）各オペレーションについて特定される事前状態及び事後状態の４つからなり、それぞれ以下のようなデータ構造を持つ。
【００７８】
（１）運用管理手続きの定義
typedef struct {
OP_KNOWLEDGE[] *operation; // 
Sequence of pointers 
to operation knowledge 
int[] premise_T;
int[] premise_F;
} PROCEDURE;
【００７９】
運用管理手続きは、手続きを構成するオペレーション知識へのポインタ参照の列によって構成される。例えば、ある手続きが、２つのオペレーションA及びBによって構成されていた場合、
operation[0] =*A, operation[1] = *B
となる。
また、この運用管理手続きが実行されるときの前提条件を、後述のオペレーション知識における前提条件と同様の方法により、premise_T及びpremise_Fにより指定する。
【００８０】
（２）オペレーション知識
typedef struct {
char[] name; // Name of operation
char[] command; // command executed 
by the operation
int[] pre_cond_T;
int[] pre_cond_F;
int[] post_cond_T
int[] post_cond_F;
} OP_KNOWLEDGE;
【００８１】
運用管理手続きを構成するオペレーションのオペレーション知識には、各オペレーションの名前、実際の処理内容（コマンドや人間に対して指示を与えるためのプロンプトの表示などの作業等）、そしてその手続きの事前条件及び事後条件によって構成される。
上記のデータ構造において、オペレーションの名前と処理内容はテキストで記述する。また、オペレーション知識や状態知識中で使用される述語が、配列Predicateで別途定義されているものとし、それぞれ番号が割り振られているものとする。そして、それぞれのオペレーションの実行前に成立(True)していなければならない事前条件として、配列pre_cond_Tにその述語を指す番号を入れておくものとする。同様に、オペレーションの実行前に不成立(False)でなければならない条件、実行後に成立及び不成立でなければならない事後条件を、それぞれpre_cond_F, post_cond_T, post_cond_Fに格納するものとする。
【００８２】
（３）状態知識
typedef struct {
int[] if_T;
int[] if_F;
int[] then_T
int[] then_F;
} COND_KNOWLEDGE;
状態知識においては、論理式における含意(imply)の左辺(条件)に含まれる正及び負リテラルを、if_T及びif_Fに、述語を示す番号として指定する。同様に、右辺(結果)に含まれる正及び負リテラルを、then_T, then_Fで指定する。
【００８３】
（４）各オペレーションについて特定される事前状態及び事後状態
typedef struct {
boolean[][] before_op;
boolean[][] after_op;
} SYSTEM_STATUS;
運用管理手続き中のi番目のオペレーションの実行前に、番号jで指定された述語が表す事実が成立していることがＣＭＤＢ１０Ｃにより判明していた場合、事前状態は、before_op[i][j]=Trueとなり、そうでない場合はFalseとなる。同様に、オペレーション実行後の事後状態はafter_opで表す。
【００８４】
５−２  出力
システムがユーザに対して提示する出力は、（１）代替運用管理手続き、及び（２）代替オペレーション知識であり、それぞれ以下のようなデータ構造を持つ。
【００８５】
（１）代替運用管理手続き
typedef struct {
PROCEDURE *orig_proc; // Pointer to
original procedure
OP_KNOWLEDGE[] *operation; // 
Sequence of pointers 
to operation knowledge 
} ALT_PROC;
代替運用管理手続きは、上記の運用管理手続きと同様、その手続きを構成するオペレーションの列へのポインタを持つ。また、運用管理手続きに加え、代替運用管理手続きが置き換える対象となる元の運用管理手続きへのポインタを持つ。
【００８６】
（２）代替オペレーション知識
typedef struct {
OP_KNOWLEDGE orig_op; // original
operation knowledge
char[] name; // Name of operation
char[] command; // command executed 
by the activity
int[] pre_cond_T;
int[] pre_cond_F;
int[] post_cond_T
int[] post_cond_F;
} ALT_OP_KNOWLEDGE;
代替オペレーション知識も、上記のオペレーション知識が持つ情報に加え、置き換えの対象となる元のオペレーション知識へのポインタを持つ。
【００８７】
５−３  代替運用管理手続き及び代替オペレーション知識を導出する演算
ここでは、１−１節の事例における（Ａ）目標未達成の場合について、上記のデータをもとに代替運用管理手続き及び代替オペレーション知識をコンピュータ上で導出する作業の流れを具体的に示す。なお、想定外副作用についても、同様の手続きで代替手続き及び代替オペレーション知識が導出可能なため、それについては省略する。
【００８８】
５−３−１  入力データ定義
ここでは入力として、以下のものが準備されているものと仮定する。
【００８９】
（１）運用管理手続き
PREDICATE[]={"changed(DBcfg)",
"updated(DB)",
"checked(DBcfg)",
"enoughcap(DB)",
"enoughcap(NW)",
"updated(NW)",
"satisfied(SLA)"}
上記配列Predicateにより、changed(DBcfg)からsatisfied(SLA)までの述語が、それぞれ0〜6までの整数により指定することが可能になる。
(例:PREDICATE[1]="update(DB)")
【００９０】
PROCEDURE pr = {
{*cfgDB, *rbtDB},
{4},{3}
}
上記運用管理手続きprは、その手続きがcfgDB, *rbtDBで示される２つのオペレーションの列によって定義されていること、またその実行開始時には、PREDICATE[4](enoughcap(NW))が成立しており、PREDICATE[3](enoughcap(DB))が成立していないことを仮定していることが定義されている。
【００９１】
（２）オペレーション知識
OP_KNOWLEDGE cfgDB ={
"edit DBcfg",
"vi DB.cfg",
{},{0},{0},{}}
上記のオペレーションcfgDBの定義においては、そのオペレーションの名称が"edit DBcfg"であること、実際の作業内容はviエディタでファイルDB.cfgを編集すること、また、その作業の前にはFalseであったPREDICATE[0](changed(DBcfg))の真理値がTrueに変化することが定義されている。他のオペレーション知識についても、同様に以下のように定義することができる。
【００９２】
OP_KNOWLEDGE rbtDB ={
"reboot DB",
"shutdown -r",
{0},{1},{1},{}}
OP_KNOWLEDGE chkDB ={
"chkcfg DBcfg",
"chkcfg DB.cfg",
{0},{2},{2},{}}
OP_KNOWLEDGE updNW ={
"update NW",
"Call NetworkExpert",
{},{5},{5},{}}
【００９３】
（３）状態知識
COND_KNOWLEDGE CN[0] ={
{6},{},{3},{} }
上記 CN[0]では、PREDICATE[6] ( satisfied(SLA))が成立している状態においては、enoughcap(DB)も成立しているはずであるという状態知識を表している。他の状態知識についても、同様に以下のように定義することができる。
【００９４】
COND_KNOWLEDGE CN[1] = {
{1},{},{2},{} }
COND_KNOWLEDGE CN[2] = {
{1},{},{3},{} }
COND_KNOWLEDGE CN[3] = {
{6},{},{4},{} }
COND_KNOWLEDGE CN[4] = {
{5},{},{4},{} }
COND_KNOWLEDGE CN[5] = {
{3,4},{},{6},{} }
【００９５】
（４）各オペレーションについて特定される事前状態及び事後状態
ここでは、手続きpr中の２つのオペレーションcfgDB，rbtDBを実行したとき、それぞれのオペレーションの事前状態及び事後状態が、下記のように特定されたと仮定する。
SYSTEM_STATUS ss = {
before_op[][] =
{ {F,F,F,F,T,F,F},
{T,F,F,F,T,F,F} };
after_op[][] = 
{ {T,F,F,F,T,F,F}, 
{T,F,F,F,T,F,F}};
}
【００９６】
上記の特定データは、最初のオペレーションcfgDB開始前には、enoughcap(NW)=Trueであり、その終了後にはchanged(DBcfg)もTrueになったということを表している。同様に、2つ目のオペレーションrbtDB終了後には、enoughcap(NW)とchanged(DBcfg)のみ成立していたということを表している。
【００９７】
５−３−２  演算処理
５−３−１節で示したデータを入力とし、出力を生成するまでの流れを具体的に示す。
【００９８】
（１）想定される事後状態の導出
ここでは、以下の処理により、i番目のオペレーションの実行前と実行後に成立していることが期待される述語を導出し、手続き実行時に期待される状態変化の列を導出する。
内部で保持するデータ構造は下記の通りである。
typedef struct {
int[][] before_op_T;
int[][] before_op_F;
int[][] after_op_T;
int[][] after_op_F;
} EXPECTED_STATUS;
【００９９】
例えばi番目のオペレーション実行前に、番号jとkで表される述語が成立していることが期待されていた場合、
before_op_T[i][0]=j;
before_op_T[i][1]=k;
となる。同様に、オペレーション実行前に偽であることが想定される述語はbefore_op_Fに登録される。オペレーション実行後については、同様にafter_op_T及びafter_op_Fに登録される。
具体的には、以下のようなステップで各状態を導出する。
【０１００】
段階１：初期設定
EXPECTED_STATUS exp_st;
想定される状態変化を表す上記構造体について、その初期状態を表す配列after_op_T[0][]及びafter_op_F[0][]については、定義された運用管理手続きprにおける初期状態から、以下のように設定する。
exp_st.after_op_T[0][x] = pr.premise_T[x];
exp_st.after_op_F[0][x] = pr.premise_F[x];
１−１節の事例の場合は、次のようになる。
exp_st.after_op_T[0][]={4}
exp_st.after_op_F[0][]={3}
【０１０１】
段階２：事前状態の生成
i番目のオペレーションの事前状態は、i-1番目のオペレーションの事後状態と、i番目のオペレーションの事前条件の和集合であるので、以下のように算出する。
【０１０２】
exp_st.before_op_T[i][] = { 
exp_st.after_op_T[i-1][],
pr.operation[i-1]
->pre_cond_T[]};
exp_st.before_op_F[i][] = { 
exp_st.after_op_F[i-1][],
pr.operation[i-1]
->pre_cond_F[]};
ただし、exp_st.before_op_T[i][]の中に同じ番号が２つ以上含まれる場合は、それらを1つにまとめる。exp_st.before_op_F[i][]についても同様である。
【０１０３】
１−１節の事例の場合、i=1のとき、1番目のオペレーションcfgDBの実行前に期待されるシステムの状態は下記のようになる。
exp_st.before_op_T[1][] = {4};
exp_st.before_op_F[1][] = {0,3};
【０１０４】
段階３：想定される事後状態の生成
事後状態after_op_T[i][]及びafter_op_F[i][]は、以下のように算出する。
（ａ）pr.operation[i]->post_cond_T[]に含まれる要素は、after_op_T[i][]に加え、pr.operation[i]->post_cond_F[]に含まれる要素はafter_op_F[i][]に加える。
（ｂ）before_op_T[i][]に含まれ、かつafter_op_F[i][]に含まれない要素は、after_op_T[i][]に加える。同様に、before_op_F[i][]に含まれ、かつafter_op_T[i][]に含まれない要素は、after_op_F[i][]に加える。
（ｃ）condition knowledge CN[j]について、CN[j].if_T[]に含まれる要素が全てafter_op_T[i][]に含まれ、かつCN[j].if_F[]に含まれる要素が全てafter_op_F[i][]に含まれる場合、CN[j].then_T[]をafter_op_T[i][]に加え、CN[j].then_F[]をafter_op_F[i][]に加える。
【０１０５】
１−１節の事例の場合、i=1のとき、1番目のオペレーションcfgDBの実行後に期待されるシステムの状態は下記のようになる。
exp_st.after_op_T[1][] = {0,4};
exp_st.after_op_F[1][] = {3};
【０１０６】
段階４：繰り返し
i++ とし、全てのオペレーションの想定される事前状態及び事後状態の計算が終了するまで繰り返す。
【０１０７】
１−１節の事例の場合、結果として以下のような配列が算出される。
exp_st.before_op_T[1][] = {4};
exp_st.before_op_F[1][] = {0,3};
exp_st.after_op_T[1][] = {0,4};
exp_st.after_op_F[1][] = {3};
exp_st.before_op_T[2][] = {0,4};
exp_st.before_op_F[2][] = {1,3};
exp_st.after_op_T[2][] = {0,1,2,3,4,6};
exp_st.after_op_F[2][] = {};
【０１０８】
（２）オペレーション実行後のシステムの実際の状態と想定される事後状態の比較による問題の発生の判定
もし、pr.operation[i-1]->post_cond_T[y]= z かつ、ss.after_op[i-1][z]=Fであった場合、i番目のオペレーションの目標が達成できなかったと判定できる(TとFを逆にした場合も同様)。
また、exp_st.before_op_T[i][]とexp_st.after_op_T[i][]にzが含まれるにも関わらず、ss.after_op[i-1][z]=Fの場合、意図しない副作用が発生したと判定できる(TとFを逆にした場合も同様)。
【０１０９】
１−１節の事例の場合には、i=2のとき、次のようになる。
pr.operation[i-1]->post_cond_T[]= {1}
ss.after_op[i-1][1] = F
このため、２番目のオペレーションrbtDBにより期待された状態変化が発生しなかった（目標未達成）と判定できる。
【０１１０】
（３）サブゴール状態の導出
目標未達成が発生した場合、想定された事後状態と実際の事後状態の差分を確認し、その差分を解消するためのサブゴール状態sgを推定する。
typedef struct {
int[][] sg_T;
int[][] sg_F;
} SUB_GOAL;
SUB_GOAL sg[];
【０１１１】
サブゴール状態の導出においては、まず以下の２つの条件の両方に合致する述語を表す番号zの集合を導出する。
（ａ）(exp_st.after_op_T[i][x]=zとなるxが存在し、かつss.after_op[i-1][z]=F ) もしくは(exp_st.after_op_F[i][x]=zとなるxが存在し、 かつss.after_op[i-1][z]=T )
（ｂ）(pr.operation[i-1]->post_cond_T[y]= z かつ、ss.after_op[i-1][z]=F となるyが存在しない)かつ(pr.operation[i-1]->post_cond_F[y]= z かつ、ss.after_op[i-1][z]=T となるyが存在しない)
【０１１２】
１−１節の事例においては、上記にあてはまるzの集合はz[]={2,3,6}となる。
そして、問題が発生したi番目のオペレーションにおいて想定された事後状態に、上記zの部分集合を加えたものをサブゴール状態の候補として算出する。zの部分集合は{2},{3},{6},{2,3},{3,6},{2,3,6}の6パターン存在する。そして、それぞれのパターンについて、exp_st.after_op_T[i][x]=z[j]となるz[j]については、そのz[j]とexp_st.after_op_T[i][]をsg[].sg_T[]の要素に加え、exp_st.after_op_F[i][x]=z[j]となるz[j]については、そのz[j]とexp_st.after_op_F[i][]をsg[].sg_F[]の要素に加えてサブゴール状態を推定する。ただし、exp_st.after_op_T[i][x]=z[j]かつ、そのz[j]がsg[].sg_F[]に含まれるような場合は、それを取り除く(TとFを逆にした場合も同様)。
【０１１３】
１−１節の事例においては、１番目のオペレーションの事後状態は次のように与えられる。
exp_st.after_op_T[1][] = {0,4};
exp_st.after_op_F[1][] = {3};
このため、上記６パターンについて、それぞれ下記の６パターンのサブゴールが生成される。
sg[0] = { {0,4,2}    ,{3} };
sg[1] = { {0,4,3}    ,{}  };
sg[2] = { {0,4,6}    ,{3} };
sg[3] = { {0,4,2,3}  ,{} };
sg[4] = { {0,4,3,6}  ,{} };
sg[5] = { {0,4,2,3,6}       ,{} };
【０１１４】
（４）サブゴール状態へ到達するオペレーション列の導出
i-1番目のオペレーションの事後に想定される状態から、上記で導出された各サブゴール状態に到達可能なオペレーションがあるかどうかを探索する。この探索においては、下記の条件を満たすものとする。【０１１５】
（ａ）各状態知識に矛盾する状態を含まないこと。つまり、CN[j].if_T[]に含まれる要素が全てsg[k].sg_T[]に含まれ、かつCN[j].if_F[]に含まれる要素が全てsg[k].sg_F[]に含まれるような場合に、CN[j].then_T[]に含まれる要素がsg[k].sg_F[]に含まれていたり、CN[j].then_F[]に含まれる要素がsg[k].sg_T[]に含まれていたりしてはいけない。
（ｂ）候補となるオペレーションの事前条件は、i-1番目のオペレーション実行後の想定された事後状態と矛盾しない。つまり、候補となるオペレーションalt_opについて、alt_op.pre_cond_T[]に含まれる要素がexp_st.after_op_F[i-1][]に含まれていたり、alt_op.pre_cond_F[]に含まれる要素がexp_st.after_op_T[i-1][]に含まれていたりしてはいけない。
（ｃ）候補となるオペレーションを、i-1番目のオペレーション実行後の想定された事後状態において実行した場合、そのオペレーションの結果の状態はサブゴール状態に等しい。
（ｄ）候補となるオペレーションには、問題を発生させたオペレーションそのものは含まれない。
【０１１６】
sg[0]〜sg[5]の全てのサブゴール状態について、上記の条件を満たすオペレーションを検索すると、サブゴール状態sg[0]に対してのみ、そのサブゴール状態へ到達するためのオペレーションの候補chkDBのみが検出される。
また、i-1番目のオペレーションの事後に想定される状態とサブゴール状態を結ぶ１つのオペレーションが導出できなかった場合は、複数のオペレーションを組み合わせてこれらを結ぶオペレーションの列を探索する。このようなオペレーションのプランニングにおいては、前述のように、公知技術の手法を利用することができる。
【０１１７】
（５）代替オペレーション知識の導出
サブゴール状態に到達するオペレーションが導出されたら、その到達可能なサブゴール状態とi-1番目のオペレーションの事後状態の差分から、問題を発生したオペレーション知識に不足していたと思われる事前条件を抽出し、それを新たに構成する代替オペレーション知識の事前条件に加える。具体的には、代替元のオペレーション知識opの事前条件op.pre_cond_Tに、exp_st.after_op_T [i][]に含まれず、かつsg.sg_T[]に含まれる要素を加え、op.pre_cond_Fに、exp_st.after_op_F[i][]に含まれず、かつsg.sg_F[]に含まれる要素を加える。【０１１８】
１−１節の事例においては、問題を発生したオペレーションはrbtDBであり、その設定は下記のようになっている。
OP_KNOWLEDGE rbtDB ={
"reboot DB",
"shutdown -r",
{0},{1},{1},{}}
これに対し、exp_st.after_op_T[1][] = {0,4}とsg[0].sg_T={0,4,2}の差分{2}を事前条件に加えた新たな代替オペレーション知識rbtDB2を、下記のように生成する。
OP_KNOWLEDGE rbtDB2 ={
*rbtDB,
"reboot DB",
"shutdown -r",
{0,2},{1},{1},{}}
【０１１９】
（６）代替手続きの導出
代替オペレーション知識が導出されたら、以下の手続きにより、定義された運用管理手続きprから代替運用管理手続きとしてのpr2を導出する。
（ａ）pr中で問題を発生したi番目のオペレーションの前に、導出されたサブゴール状態へ到達するオペレーション列を挿入する。
（ｂ）pr中で問題を発生したi番目のオペレーションを、導出された代替オペレーションで置き換える。
【０１２０】
１−１節の事例の場合は、運用管理手続きprは下記のように定義されていた。
PROCEDURE pr = {
{*cfgDB, *rbtDB},
{4},{3}
}
上記の運用管理手続きprに対し、下記pr2が代替運用管理手続きとして導出される。
ALT_PROC  pr2 = {
{*cfgDB, *chkDB, *rbtDB2},
{4},{3}
}
【０１２１】
（７）結果出力
上記の代替運用管理手続き及び代替オペレーション知識を導出したら、それを画面に出力する。図９は、代替運用管理手続き及び代替オペレーション知識を表示した画面イメージを示す。画面には、運用管理手続きとオペレーション知識の定義、運用管理手続き実行後に発生した不整合の内訳、そしてその不整合を解決可能な代替運用管理手続き及び代替オペレーション知識（修正方法）を表示する。【０１２２】
管理者は提示された代替案を確認し、それを運用管理手続きＤＢ１０Ａ及びＳＫＤＢ１０Ｂに反映するかどうかを判断する。管理者がそれを反映すると判断した場合には、元の運用管理手続きprとオペレーション知識rbtDBの内容（オペレーションの列の定義や、事前条件や事後条件の定義）を、代替運用管理手続きpr2と代替オペレーション知識rbtDB2の内容と一致するように修正する。
また、代替案が複数ある場合はそれらを全て提示し、その中から管理者が適切なものを選択できるようにする。
【０１２３】
なお、本実施例においては、導出した代替運用管理手続き及び代替オペレーション知識を管理者に提示し、管理者がその提示内容に基づいて、各ＤＢの運用管理手続き及びオペレーション知識を修正することを想定しているが、これに限られない。即ち、本運用管理装置１０において、さらに修正部を備え、直接、運用管理手続きＤＢ１０Ａ及びＳＫＤＢ１０Ｂを自動更新してもよい。そのようにすれば、管理者が各ＤＢの運用管理手続き及びオペレーション知識を修正する手間を省くことができる。【０１２４】
また、本実施例においては、障害が発生したときに、障害を回避可能な修正方法を提示する方法として、運用管理手続き及びオペレーション知識に夫々反映させた代替運用管理手続き及び代替オペレーション知識（修正方法）を提示する例について説明しているが、これに限られない。即ち、運用管理手続きの修正方法のみを提示してもよい。その場合であっても、少なくとも当該運用管理手続きについて、今後同じ障害が発生することを防ぐことができる。【０１２５】
さらに、オペレーション知識の修正方法のみを提示してもよい。この場合であっても、新たな運用管理知識を管理者が定義するときに、そのオペレーション知識を参照すれば、同様の障害を回避することが可能な適切な運用管理手続きを定義することができるようになる。また、そのオペレーションが含まれる他の運用管理手続きについて、今後同様の障害が発生するのを防ぐべく、さらに修正を行なうことができる。また、各オペレーションに関する運用管理知識が増えていくことで、様々な形でこれらの知識を活用することができ、体系的なシステム運用管理を実現させることができる。
【図１】
0005434908.tif 000007
【図２】
0005434908.tif 000008
【図３】
0005434908.tif 000009
【図５】
0005434908.tif 000010
【図６】
0005434908.tif 000011
【図７】
0005434908.tif 000012
【図８】
0005434908.tif 000013
【図９】
0005434908.tif 000014
【図４】
0005434908.tif 000015