IT サービス・マネジメント・アーキテクチャーとオートノミック・コンピューティング

IT インフラストラクチャー・ライブラリー®によって、情報技術 (IT) サービスをビジネス・ニーズに合わせて調整するための一連のベスト・プラクティスが定義され、IT サービス・マネジメント (ITSM) 用のフレームワークが構成されます。このフレームワークによって、組織は、標準的な設計パターンと必要なカスタマイズを使用した IT サービスの管理が容易になります。本稿では、ITSM アーキテクチャーとインフラストラクチャーの定義と実装に対するオートノミック・コンピューティングの貢献度について説明します。最初に、ITSM の論理アーキテクチャーに関するオートノミック・コンピューティングのアーキテクチャー・パターンと仕様を紹介します。次に、問題判別、影響評価、およびソリューション展開に関する一連の ITSM ベースのケース・スタディーを通して、オートノミック・コンピューティングがどのように価値を提供するかを示します。

オートノミック・コンピューティングは、2001 年の National Academy of Engineers 会議の基調講演で初めて発表された Paul Horn 博士の「Autonomic Computing Manifesto」の中の 8 つの重要な要素、つまり、命題から始まります¹。博士のプレゼンテーションでは、オートノミック・コンピューティングが、IBM 社内だけでなく、情報技術 (IT) 業界全体にとっての大きな課題であるとされました。

2003 年に、IBM Systems Journal は、その時点で最新のオートノミック・コンピューティングに関するさまざまなテクノロジーを特集しました。オートノミック・コンピューティングを紹介する「The Dawning of the Autonomic Computing Era (オートノミック・コンピューティング時代の幕開け)」で、Ganek と Corbi ² が、オートノミック・コンピューティングに関する市場と業界の推進要因について検証しています。

それ以来、オートノミック・コンピューティング・イニシアチブは、商業領域において大きな成功を収め³-⁶、研究者のコミュニティーで幅広く受け入れられ⁷-¹¹、グリッドと Web サービス、パーベイシブ・コンピューティングとユビキタス・コンピューティング、およびサービス指向アーキテクチャー (SOA) ¹²-¹⁴を含む他の重要なアーキテクチャー・イニシアチブと組み合わせて活用されています。また、オートノミック・コンピューティング関連の標準化団体内部でさまざまな活動が行われています¹⁵,¹⁶。

拡大図

広い意味で、オートノミック・コンピューティングは、IT の複雑さを解決するアーキテクチャー、テクノロジー、および標準の漸進的変化です。この複雑さは、システム設計と IT 管理の複雑さの増大、競争に迅速に対応するためのビジネス・ニーズの増加、および相互に関連し合う世界の拡大がもたらした行動の複雑さによってさらに促進されます。

本稿では、オートノミック・コンピューティングが、主として、情報技術インフラストラクチャー・ライブラリー** (ITIL**)¹⁷ に記載されたエンティティー、プロセス、および規則に基づく IT プロセスの効率性をどのように解決するかを中心に説明します （ここで言う IT プロセスの効率性とは、コストや時間に関する効率性だけでなく、プロセスによってビジネス目標が適切に解決される有効性も意味します¹⁸）。つまり、IT サービス・マネジメントに対するオートノミック・コンピューティングの貢献度を検証します。本稿の目的は、ITIL ベースのプロセスを自動化するケース・スタディーを通して、アーキテクチャーの側面から IT サービス・マネジメントに対するオートノミック・コンピューティングの現在と将来の貢献度に焦点を当てることです。加えて、これらのケース・スタディーを使用して、IT アーキテクトにサービス・デリバリー・ニーズに対する追加的な視野と知見を提供します。さらに、派生的なアーキテクチャー・パターンと関連仕様を含むオートノミック・コンピューティング・リファレンス・アーキテクチャーと IT サービス・マネジメント (ITSM) の論理アーキテクチャーの関係を簡単に検証します。

上に戻る

オートノミック・コンピューティング・リファレンス・アーキテクチャー (ACRA)¹⁹ の概念ビューは、オートノミック・システムを構築するための一連のアーキテクチャー要素、システムの観点でこれらの要素を使用するためのパターン、および統合を促進するインターフェース仕様とデータ交換仕様の 3 つの部分で構成されます。

図 1 に示されているように、ACRA は、一連のリソースを管理するマネージャーの階層セットを含む基本的なシステム管理トポロジーを提供します。オーケストレイティング・マネージャーがリソース・マネージャーの管理オペレーションを制御し、リソース・マネージャーが一連のリソースに対する管理サポートを提供します。どちらのマネージャーも、オートノミック・マネージャー機能を実装して、1 つ以上のマニュアル・マネージャー要素を通してユーザーとの相互作用をサポートすることができます。また、これらのマネージャーは、図 1 の右側に示されているように、1 つ以上の知識ソースから管理データにアクセスすることができます。

拡大図

図 1 の一番下の行に示されている管理対象リソースには、自己管理機能を備えたものと備えていないものがあります (自己管理機能を備えたリソースが自己管理リソースです)。マネージャーとリソース間の相互作用は、直接的な場合と間接的な場合 (エージェントを使用) があり、Web Services Distributed Management (WSDM)²⁰ や Common Information Model (CIM) などの管理容易性に関する標準を導入することによって簡素化されます。 ²¹

ACRA の中心的な構成要素は、オートノミック・マネージャーです (図 2)。このマネージャーは、特定の管理機能を自動化し、それらの機能を管理標準で定義された動作に従って外部化します。

オートノミック・マネージャーは、監視、分析、計画、および実行の 4 つの機能を実装したインテリジェント制御ループを備えています。監視機能が、管理対象リソースに関する詳細情報を収集します。分析機能が、収集された情報を使って変更が必要な場所を特定します。計画機能が必要な計画の策定を担当し、実行機能が計画された変更に必要な処置を実施します。

オートノミック・マネージャーの外部インターフェースが、サポートする機能にアクセスするための標準的な手段を提供します。2 種類の論理外部インターフェースがあり、どちらもセンサーとエフェクターを備えています。論理的にオートノミック・マネージャーの下部に位置するインターフェースは、センサー・インターフェースを通してリソースからデータを取得したり、エフェクター・インターフェースを通してリソースに対するオペレーションを実行する管理対象リソースとの相互作用に使用されます。論理的にオートノミック・マネージャーの上部に位置するインターフェースは、他のマネージャーが、オートノミック・マネージャーが管理対象リソースと相互作用する方法とほとんど同じ方法で、センサーを使ってオートノミック・マネージャーから情報を取得したり、エフェクターを使ってオートノミック機能を構成するために使用されます。たとえば、エフェクター・インターフェースは、オートノミック・マネージャーが順守すべきポリシーを設定したり、オートノミック・マネージャーが検出すべき症状定義を設定するために使用することができます (症状定義は、管理対象環境内で起こり得る問題や状況を特定するために使用されます。この詳細については後述します)。

オートノミック・マネージャーは、自己管理型であり、ポリシーを使用して自らの振る舞いを管理します²²。加えて、オートノミック・マネージャーは、知識ソースを活用して、ポリシーや症状定義などの管理データにアクセスし、そのデータを使って管理機能を実行します。

オートノミック・マネージャーに加えて、ACRA には、図 1 に示されているような要素も含まれています。

• マニュアル・マネージャー - IT プロフェッショナルが一部の管理機能を手動で実行できるようにするユーザー・インターフェースの実装
• 管理対象リソース - IT インフラストラクチャーを構成するシステム・コンポーネント。これらのコンポーネントによって、リソースの状態や管理オペレーションにアクセスできるようになります。
• 自己管理リソース - 統合型インテリジェント制御ループを備えた管理対象リソースの種類
• 知識ソース - アーキテクチャーで規定されたインターフェースに従って知識へのアクセスを提供するレジストリー、辞書、データベース、またはその他のリポジトリーの実装

拡大図

ACRA と ITSM の関係を図 3 に示します。上部は、変更管理、構成管理、問題管理、および可用性管理に関連付けられたプロセスなどの ITIL ベースのプロセスで構成された層です。これらのプロセスはワークフローで構成され、ワークフローはアクティビティーで構成され、さらに、アクティビティーはタスクで構成されます。特定のタスクが、最終的にインフラストラクチャー層内の管理対象リソースと自己管理リソースの両方と相互作用するドメイン固有の運用管理ツールと相互作用します。

図 3 の下部に示されているように、管理対象リソースと自己管理リソースはどちらも IT インフラストラクチャー層に位置します。これらのプロセスにとっては、構成管理データベース (CMDB) が ACRA で定義された知識ソースの役割を担っています。

図 3 の左側は、ITSM 環境、運用管理ツール、および IT インフラストラクチャー層と相互作用するさまざまなユーザーの役割用のユーザー・インターフェースです。ここでは、ACRA マニュアル・マネージャーのアーキテクチャー要素を実現する管理ツールを見つけることができます。右側は、3 つすべての論理アーキテクチャーのレベルと CMDB と相互作用する開発ツールを含む統合ツールの層です。

次は、アーキテクチャー要素から派生し、必要な仕様と標準をサポートするアーキテクチャー・パターンを検証します。

オートノミック・コンピューティング・アーキテクチャー・パターン

このセクションでは、オートノミック・コンピューティングの原則を用いるための一般的なパターンについて説明します。ここでは、オートノミック・コンピューティングに関連したすべてのアーキテクチャー・パターンについて説明するわけではなく、後述の ITSM ケース・スタディーで使用されるパターンだけを取り上げます。

部分的なオートノミック・マネージャー

オートノミック・マネージャーの内部と外部のインターフェースによって、オートノミック制御ループの部分的な実装がサポートされます。このことは、既存の運用管理ツールが提供する機能 (監視、分析、計画、および実行) に適した論理インターフェースだけでなく、それらの機能へのアクセスを可能にする標準的な外部インターフェースを実装することによって、制御ループで既存の運用管理ツールが使用できる点で重要です。つまり、単一の製品またはコンポーネントで制御ループ全体を実装する必要がありません。他の製品やコンポーネントと組み合わせて完全なループを形成することができます。

加えて、制御ループ内の機能間の論理インターフェースを通して、特定の種類の知識が転送されます。たとえば、監視機能は、リソースから詳細情報を収集して、それらを分析が必要な症状 (後述) に整理します。変更が必要な場合は、分析機能が変更要求を計画機能に転送します。変更要求には、分析コンポーネントが結果的に必要または望ましいと考える変更内容が記述されます。計画機能が、該当する変更計画を実行機能に転送します (変更計画は、管理可能リソースに対して必要な一連の変更を提示します)。

部分的な制御ループのサポートによって、オートノミック・マネージャーは、変更管理や問題管理などの管理規則による調整を通して、顧客の組織構造を反映させることができます。部分的なオートノミック・マネージャーは、複数のコンテキストで再利用することができます。たとえば、変更管理用の計画および実行エンジンは、複数の監視・分析エンジンで促進することができます。部分的なオートノミック・マネージャーは、問題判別用の新しいオートノミック機能を実現する新しい症状定義の追加などの自己管理オートノミック機能の段階的な提供を支援します。

委任

委任では、IT システムの管理に関連した複雑さを削減するという目標とともに、手動管理からオートノミック管理に前進するための一連のパターンが定義されます。委任とは、IT プロフェッショナルが責任を負っているタスクを割り当てるときに実施する内容を、自己管理オートノミック機能を備えた運用管理製品が理解できる用語で記述するプロセスを意味します。たとえば、委任は、IT プロフェッショナルが、特定の種類の変更の事前承認を許可し、人間が介在しないタスクの完了を可能にするポリシーを設定するために使用することができます。IT プロフェッショナルがタスクを委任するときは、管理ツールに含まれる自己管理オートノミック機能を利用することになります。これは、彼らがオートノミック・テクノロジーによってタスクが介在なしで正しく実行されると信じていることを意味します。ただし、彼らは、いつでも必要なときに、委任したタスクの制御を取り戻すことができます。IT プロフェッショナルは、委任するタスクに最後まで責任を負う必要があります。

表 1 に示されているように、委任するタスクには、手動処理 (IT プロフェッショナルによって管理されるタスク) からオートノミック処理 (IT プロフェッショナルとの直接的な相互作用なしで自動的に実行されるタスク) までの範囲が関連付けられます。この 2 つの処理の間には、複数のレベルの自動化が存在します。

タスクの委任を取り消せる能力は、オートノミック・システムの信頼性を高める上で重要な要素です。委任したタスクが主要なシステム・メトリックに照らして必要な効果を発揮しない場合があるため、この能力によって、IT プロフェッショナルが委任したタスクの制御を取り戻すことができます。加えて、委任されたタスク側は、管理者に選択肢や推奨事項を提示したり、決定した内容や実施した処置を記録することができる必要があります。これによって、管理者は、委任したタスクの結果を検証して、委任パターンの信頼性を確認することができます。

自己管理リソース

自己管理リソースには、特定のオートノミック管理機能が組み込まれています。つまり、制御対象ドメイン内のエンティティーを管理するための制御ループが含まれています。これが、一連のリソースに対して外部オートノミック管理を提供する管理ツールとの違いです。

アプリケーション・サーバー、データベース・サーバー、およびストレージ・サーバーはすべて自己管理リソースにすることができます。たとえば、自己管理オートノミック機能をデータベース・サーバーに組み込むことによって、ドメイン内の状態を検出して、そのドメイン内の不正な状態を管理ツールからの介在を必要とせずに是正するための処置を実施することができます。

自己管理リソースのメリットは、リソースが、パフォーマンス・ニーズや可用性ニーズを含む運用能力に影響を与えるイベントやリソース状態データを管理できることです。また、自己管理リソースは、リソース内部の詳細の一部を処理し、システム規模のリソース・モニターや IT プロフェッショナルを情報の渦に巻き込むことなく、特定の問題からどのように回復すべきかを判断することによって、システム全体の複雑さを削減します。

自己管理リソースは、部分的なオートノミック・マネージャー・パターンを実装することができます。これによって、自己管理リソースは、委任パターンに参加することができます。たとえば、自己管理リソースが推奨されている処置を管理者に提示し、それを受けた管理者がその処置を承認するか、別の処置を実施するかを選択することができます。また、上位の管理ツールから自己管理リソースに管理責任を委任することもできます。

階層型オートノミック・マネージャー

オートノミック・マネージャーは、IT プロフェッショナルの編成方法を反映するために階層で編成することができます。階層が管理ツールに対して使用可能な唯一のトポロジーではありませんが、この編成によって、オートノミック・マネージャーは、パフォーマンス、可用性、セキュリティーなどの単一の関心ドメイン内の特定の分野に重点を置くことができます。階層型オートノミック・マネージャーは、各オートノミック・マネージャーが関心分野に集中できるようにすることによって、一定レベルの効率性を提供しますが、複数のオートノミック・マネージャーを階層に編成することによって、完全なオートノミック・システムを構築するための機能も提供します。

オートノミック・マネージャー間の階層関係は、一連のオートノミック・マネージャーによって提供されるサービスを調整するために使用することもできます。たとえば、システム全体のサービス・レベル目標に責任のあるオートノミック・マネージャーは、他のオートノミック・マネージャーにそれぞれの分野に固有の目標を達成するように指示することができます。分野固有のオートノミック・マネージャーのすべてがそれぞれの目標を達成すれば、システム全体の目標に責任のあるオートノミック・マネージャーがその目標を達成したことになります。

この階層型オートノミック・マネージャー・パターンは、前述した外部インターフェースを使用して実現することができます。1 つのオートノミック・マネージャーが、リソースを管理する場合と同様に、オートノミック・マネージャーの外部インターフェースのセンサーとエフェクターを使用して、他のオートノミック・マネージャーを管理したり、他のオートノミック・マネージャーから管理されることができます。

オートノミック・コンピューティング仕様

表 2 は、後述の ITSM ベースのケース・スタディーに関連したインターフェースとデータ交換フォーマットに関する仕様を示しています。この表は基本的な内容を示しているに過ぎません。これに関する詳細やオートノミック・コンピューティング関連のその他の仕様については、参考文献を参照してください。

上に戻る

このケース・スタディーでは、ACRA に組み込まれた機能が、いくつかの IT 運用サービス・プロセスに対してどのように新しいメリットと追加の価値を提供するかを示します。これらのサービスは、IBM Tivoli* Unified Process (ITUP)²⁹ の観点で研究されており、インシデント管理、イベント管理、および問題管理で構成されます。インシデント管理は、インシデントの検出、記録、分類、調査、診断、および解決 (回復処置を含む) を実施します。イベント管理は、イベントの特定と優先順位付けを実施して、インシデントを引き起こしかねないイベントへの対応の特定を支援します。問題管理は、問題と既知のエラーの制御、積極的な問題の対処、問題の監視と報告、問題管理フレームワークの確立、問題管理パフォーマンスの評価、およびインシデントと問題の根本原因の特定を実施します。

このケース・スタディーでは、リソースの監視タスクに対する委任パターンと部分的なオートノミック・マネージャー・パターンの適用、中断の自動検出と対処、および問題診断を使用した支援のすべてを段階的かつ柔軟な方法で実施するメリットを示します。このケース・スタディーの 2 つ目のシナリオでは、問題判別知識共有に対して階層型オートノミック・マネージャー・パターンを使用するメリットを示します。

上に戻る

このシナリオでは、重要な顧客に直接対応する Web ベース・アプリケーションを実行しているサーバーがシステム・リソース不足に陥った結果、アプリケーションが使用できなくなったケースについて説明します。この問題は、数週間前から断続的に発生しており、根本原因はまだ特定されていませんが、次善策 (サーバーのリブート) は特定されています。運用スタッフは、この検出と次善策を自動化してダウン時間を最小化するように求められています。サービスを提供しているサーバーが、システム・リソースを使い果たそうとしています。イベント監視ソフトウェアが、サーバーの故障イベントを検出、記録、調査、およびフィルタリングします。これらのイベントは、他のソースからのイベントと関連付けられ、運用コンソールにエスカレートされます。

拡大図

図 4 は、問題判別シナリオ 1 で ACRA のアーキテクチャー要素がどのように利用されるかを示しています。管理対象リソースを監視している一連の部分的なオートノミック・マネージャー (監視ツール) が、知識ソースに保存された症状定義に基づいて症状を検出します。これらのオートノミック・マネージャーには、検出した症状の詳細分析の実施に責任のあるオートノミック・マネージャー (分析ツール) との階層関係が設定されています。この上位マネージャーによる分析によって、変更管理プロセスを起動する変更要求 (RFC) が生成されるか、インシデント管理プロセスを起動するインシデントが生成されます。インシデントが生成された場合は、根本原因分析データが、インシデント管理プロセス期間に参照できるように知識ソースに保存されます。

以降のセクションでは、現行プロセスのアクティビティーと、ACRA で定義された機能を活用するオートノミック・プロセスを対比します

(この場合のオートノミック・プロセスは、オートノミック機能を含むように拡張されたプロセスを意味します)。我々のアプローチの機能を使えば、自動化の拡大を通してインシデント管理アクティビティーをより効率的かつ効果的にすることができます。

インシデント管理フレームワークの構築

現行プロセスでは、人間の管理者が、IT インフラストラクチャー、管理ツールの機能、および人間の管理者の能力に基づいて、インシデント管理に関するルールと手順を決定します。サーバーの場合は、これにシステム・リソース不足インシデントが発生した場合の次善策 (サーバーのリブート) が含まれます。これらのポリシーは、人間の管理者が適用できるように文書化されます。

オートノミック・プロセスでは、システム・リソース不足インシデントが発生した場合の次善策 (サーバーのリブート) の自動化を含む管理ツールで展開すべき症状定義と、そのインシデントの検出に使用される相関パターンを決定することによって、手動管理を自動化することができます。

インシデントの検出と記録

現行プロセスでは、イベント監視ツールを使用したオペレーターの観察に基づいてインシデント・レコードが開かれます。

オートノミック・プロセスでは、実稼働レベルの症状定義に記録された監視イベント・パターンに基づいてインシデント・レコードが開かれます。通常は、単純なシングル・ドメイン症状定義 (サーバーのリブートなど) によって、イベントの簡単なフィルタリングが実施されます。また、ACRA で記述され、症状定義で表現された共通問題パターンの記録によって、断続的に発生する問題の迅速な特定が可能になります。

インシデントの分類

現行プロセスでは、前回のアクティビティーで記録されたインシデント・レコードは、次に、人間の管理者によって分析され、その原因が特定されます。インシデントは、既知のエラーや問題を調査して入力パラメーターを検査するか、影響、緊急性、優先順位などの新しいパラメーターを割り当てることによって、分類する必要があります。このプロセスによって、どの程度の是正措置が必要かが決定されます。

オートノミック・プロセスは、特定のインシデント (適切な症状定義が存在するインシデント) に関する分類を自動化することができます。症状パターンが一致したら、症状定義内の補足情報によって、影響、緊急性、優先順位を含むインシデント分類情報、インシデントに関連付けられたリソースに関する情報、およびそのインシデントと他のインシデントを相互に関連付けるための追加情報が提供されます。ACRA で記述され、症状定義で表現された共通インシデント分類の記録によって、インシデント分類の自動化が可能になります。さらに、この機能は、WEF などの共通のイベント・フォーマットを利用して、症状を認識するためのイベント相関とパターン・マッチングの自動化を促進します。

この自動化 (および以降のセクションで説明する自動化機能) は、人間の管理者がオートノミック・マネージャーにタスク (この場合はインシデントの分類) を委任する委任パターンを示しています。

インシデントの調査と診断

現行プロセスにおけるインシデント診断は、人間の管理者に、ビジネスを継続させるための手段を提供しなくてはならず、それはサービスの品質の低下を伴うこともあります。インシデントのビジネスに対する影響を最小限に抑え、構造的な解決策を調査および考案する時間を確保するために、一時的な次善策 (サーバーのリブート) が提供されます。

オートノミック・プロセスでは、シングル・ドメイン症状定義と、問題解決情報をインシデント・レコードに関連付ける他のシングル・ドメインまたはクロスドメイン症状定義を相互に関連付けることができます。インシデントに関連付ける症状には、推奨されている是正措置を含めることができます。このシナリオでは、対応する症状定義の中で特定の次善策 (サーバーのリブート) が特定されます。また、ACRA で記述され、症状定義で表現された共通問題是正措置の記録によって、断続的に発生する問題の次善策の自動化が可能になります。

インシデントの分類のための監視やインシデント診断のための分析を使用することで、部分的なオートノミック・マネージャー・パターンの使用が明らかになります。図 4 に示されているように、これらのインテリジェント制御ループの機能は、全く異なる 2 つの管理ツールに分けることができます。

インシデントの解決とサービスの回復

現行プロセスにおける次善策と回復処置 (サーバーのリブート) は、よく専門スタッフ (第 2 または第 3 レベルのサポート) によって行われることが多くなっています。

拡大図

オートノミック・プロセスでは、サーバーのプログラム制御を通して、前回の診断で特定された自動対応 (サーバーのリブート) が実施されます。次善策の実行後は、イベント監視機能によって、サーバーの正常動作の復帰が示されます。これに基づいて、インシデントが閉じられます。ACRA には、リソースに対する次善策の実施を自動処理するための WSDM などの標準の管理容易性インターフェースが記述されます。

問題判別シナリオ 2 - 問題診断

このケース・スタディーのシナリオ 2 はシナリオ 1 に似ていますが、このケースでは、特定された自動対応ではインシデントが解決されないため、インシデントの発生を繰り返さないための追加の分析が必要になります。このシナリオでは、シナリオ 1 を拡張して、サーバー・ソフトウェアにメモリー・リークが存在し、問題を解決するためにソフトウェア・パッチを適用する必要があると判断します。

図 5 は、ACRA のアーキテクチャー要素が問題判別シナリオ 2 でどのように使用されるかを示しています。このシナリオでは、部分的なオートノミック・マネージャーの問題判別 (PD) ツールが、管理対象リソースと自己管理リソースから受け取った状態情報、メトリック、およびイベントを使用して PD を実施します。自己管理リソースは、症状定義に基づいて分析を実施することができるため、PD ツールで分析が必要な症状を生成することもできます。PD ツールで実施される分析では、さまざまな知識ソースから取得したデータも使用されます。これには、症状定義と、前回検出された症状、イベント、インシデントなどの履歴データが含まれます。PD ツールで実施された症状ベースの分析の結果、変更管理プロセスを起動するための RFC が生成されます。

以降のセクションでは、シナリオ 1 と同じ方法で現行プロセスとオートノミック・プロセスのアクティビティーを対比します。我々のアプローチの機能を使えば、自動化の拡大を通して問題管理アクティビティーをより効率的かつ効果的にすることができます。

問題管理フレームワークの構築

現行プロセスでは、人間の管理者が、IT インフラストラクチャー、管理ツールの機能、および人間の管理者の機能に基づいて、問題管理に関するポリシーと手順を決定します。サーバーの場合は、これに、システム・リソース不足インシデントが発生した場合の既知のエラーのリストと、新しい問題の調査のために従うべき追加の分析手順が含まれます。

オートノミック・プロセスでは、管理ツールに組み込む症状定義を決定することによって手作業を自動化することができます。これらの症状定義には、システム・リソース不足問題が発生したときに適用すべき RFC (このケースではソフトウェア・パッチを適用する) と問題の検出に使用される相関パターンが含まれます。

このような相関パターンは、本質的に、同様のインシデント検出パターン (問題判別シナリオ 1 で説明した) よりも複雑であり、多くの場合、問題を効率的に特定するために構成アイテム (CI) の構成データと依存関係を参照します。このアクティビティーは、根本原因分析として知られています。

問題の検出と記録

現行プロセスでは、インシデントが既知のエラーと比較されます。インシデントに関連付けられた既知のエラーが存在しない場合は、管理ツールを使用したオペレーターの観察に基づいて問題レコードが開かれます。

オートノミック・プロセスでは、このようなプロセスに関する症状定義に記録されたインシデント・イベント管理からの相関パターンに基づいて問題レコードが開かれます(インシデント管理における症状の使用方法については、問題判別シナリオ 1 を参照してください)。

問題の分類とエラーの評価

現行プロセスでは、記録された情報に基づいて既知のエラーが評価されます。問題の原因を特定するために、前回のアクティビティーで記録された問題レコードが分析されます。シナリオ 1 で説明したインシデントの分類と同様のプロセスで問題を分類する必要があります。

オートノミック・プロセスでは、問題分類を自動化することができます。症状パターンが特定されたら、症状定義内の補足情報によって、影響、緊急性、優先順位を含む問題分類情報、問題に関連付けられたリソースに関する情報、およびその問題と他の問題を相互に関連付けるために使用できる追加情報が提供されます。

問題の調査と診断

現行プロセスでは、問題調査アクティビティーとインシデント調査アクティビティーが似ていますが、主目的は全く異なります。インシデント調査の目的はサービスを迅速に復元することであるのに対して、問題調査の目的は根本原因を診断することです。多くの場合、問題調査では、CI 構成データと依存関係が徹底的に分析されます。この例では、問題調査スタッフが、サーバー上に展開されたソフトウェア・リソースを調査して、診断の結果、根本的な問題がメモリー・リークであることを突き止めます。

オートノミック・プロセスでは、問題調査アクティビティーとインシデント調査アクティビティー (問題判別シナリオ 1 で説明した) が似ていますが、問題の根本原因を特定するためにより複雑な症状定義が使用されます。通常、問題関連症状定義は、前後関係 (CI 構成や依存関係など)、状態データ、イベント、およびログ・レコードを複雑な症状定義に関連付けることによって処理されます。このような複雑な症状定義が、実稼働環境に展開されていない場合があります。テスト環境または実稼働環境で検証済みの新しく作成された症状定義を含むオフライン症状カタログを調査する場合に、問題管理ツールを起動することができます。この拡張知識ベースへのアクセスによって、手動インシデント管理プロセスで特定されたことのない症状が特定される可能性があります。推定原因と一致する症状の数が少なければ、迅速かつ正確に特定することができます。履歴データに基づいて、これらの症状の 1 つが、問題の最も可能性の高い根本原因として選択されます。根本原因症状に含まれる情報を使って問題レコードが生成されます。この例では、根本原因症状が、メモリー・リーク状態であると特定されたことを示しています。

未知のエラーの根本原因は、ACRA に記述された共通のイベント・フォーマットと症状知識を利用する開発ツールによって、より迅速に特定することができます。自動症状分析と処理戦略を使用するメリットには、より大規模な知識ベースにアクセスできることによってより正確な診断が可能になり、症状分析プロセスの結果として自動是正措置が実行できることが含まれます。

問題の解決と解決策の記録

現行プロセスでは、変更マネージャーによる承認後に問題リカバリー RFC (ソフトウェア・パッチの適用) が実施され、新しく検出および診断された問題が既知のエラーとして問題解決専門スタッフなどによって記録されます。そして、問題レコードと関連するインシデント・レコードが閉じられます。

オートノミック・プロセスの場合は、根本原因症状定義から修正 RFC (ソフトウェア・パッチの適用) が抽出され、実施のために提出されます。パッチの適用には変更管理プロセス (次のケース・スタディーで説明する) が関与し、変更管理プロセスにはいくつかの自動化の形態を含めることもできます。RFC の処理後は、イベント管理監視機能によって、サーバーの正常動作の復帰が示されます。そして、イベント、インシデント、および問題が閉じられます。加えて、問題が特定された新しい症状定義が新しい既知のエラーとして実稼働レベルの知識ベースに移行されるため、今後、関連するインシデントが発生した場合は、インシデント管理によって処理されることになります (これによって、積極的な問題管理が構成されます)。また、ACRA に記述され、症状定義で表現された共通問題是正措置の記録によって、問題の自動解決が可能になります。さらに、この機能を使えば、オペレーション中に検出された未知の問題と関連する解決策を既知のエラーに移行することによって、今後は自動的に処理できるようになります。

上に戻る

ITIL ソリューション展開ケース・スタディーでは、オートノミックの概念とテクノロジーが ITUP ソリューション展開プロセスにおいてどのように使用できるかを示します。構成管理プロセスが、IT コンポーネント (ハードウェア、ソフトウェア、およびドキュメント) の特定、記録、および報告に使用されます。これには、バージョン、構成要素、および関係が含まれます。変更管理プロセスによって、インフラストラクチャー変更の評価と承認が管理されます。また、リリース管理プロセスによって、関連する許可された変更の収集が管理されます。

このケース・スタディーでは、ITSM ソリューションを設計して統合すれば、委任アーキテクチャー・パターンと部分的なオートノミック・マネージャー・アーキテクチャー・パターンによって、段階的かつ柔軟な方法でオートノミック機能が構成できることを示します。また、階層型オートノミック・マネージャー・アーキテクチャー・パターンと、組織境界の適応も示します。

これらのパターンのメリットを示すことに加えて、このケース・スタディーでは、SDD (ソリューション展開記述子) をソリューション展開と依存関係知識の両方の正規表現として使用することの重要性を示します。この知識は、ソリューション展開プロセス内の主要タスクの分析、計画、および実行で使用されることになります。これらのタスクには、依存関係および影響分析、構成ドリフト分析、およびリリース計画が含まれます。

このケース・スタディーは、2 つのシナリオで構成されます。図 6 に示されているように、シナリオ 1 の全体フローは、リリース・ビルダーがソフトウェア・パッケージとその対応する SDD を作成したところから始まります。ソフトウェア・パッケージと SDD は、構成ライブラリアンによって確定版ソフトウェアの保管庫 (DSL) に保存され、CMDB に登録され、展開に使用できるようになります。新しいソフトウェア・リリースに関する RFC を処理する変更アナリストが、CMDB 内の情報を基に、変更の影響を分析するための評価ツールを使用します。その後で、リリース・プランナーが、リリースのロールアウトを計画するための計画ツールを使用して RFC を処理します。

シナリオ 2 では、リリースのロールアウトが処理されます。ロールアウト計画がリリースの実装者に渡されます。リリースの実装者は、1 つ以上のローカル・インストール・ツールによって展開を調整するオーケストレーション・ツールを使用してターゲット・リソースにソフトウェアをインストールします。

以降のセクションでは、これらのシナリオの詳細について説明します。他のケース・スタディーと同様に、シナリオ内の各アクティビティーについては、現行プロセスと、オートノミック機能によって拡張されたプロセス (オートノミック・プロセス) を対比することによって説明します。

ソリューション展開シナリオ 1 - ソフトウェア・リリース管理

ソリューション展開シナリオ 1 では、人的リソース (HR) アプリケーションと展開先の Web アプリケーション・プラットフォームへのアップグレードで構成される新しいソフトウェア・リリースの開発および計画をサポートするためのオートノミック・テクノロジーの利用方法を検証します。

拡大図

HR アプリケーションのメインのアプリケーション・コードは、J2EE** サーバー上に展開されます。HR アプリケーションの最初のリリースは、3 カ所に展開する必要があります。そのうちの 2 カ所は全く新規の展開になります。3 カ所目には、2 つの既存のアプリケーションを実行している旧バージョンの標準 Web プラットフォームがインストールされています。新しい 2 つの場所では 1 つの J2EE サーバーを共有し、3 つ目の場所では専用の J2EE サーバーと Web サーバーを維持する予定です。

RFC の提出とリリースへの暫定割り当て

現行プロセスを使用した場合は、アプリケーションを展開する必要のある 3 カ所に対して 3 つの RFC が提出されます。RFC ごとに、別々の承認が必要ですが、すべての RFC が単一のリリースに必要な部分です。

オートノミック・プロセスでは、開発チームが、必要な変更を記述するために HR アプリケーションに関する SDD をRFC に関連付けます。これによって、HR アプリケーションと環境の依存関係が記述された、開発とオペレーション間の「契約」が締結されます。RFC によって、この依存関係を満たすために、場所ごとに必要なターゲット環境が特定されます。

RFC の影響に対する評価

現行プロセスのアクティビティーでは、変更アナリストがサブジェクト・マター・エキスパートと協力して RFC の影響度を評価します。インストールするソフトウェアの依存関係とリリースによって影響を受ける可能性のある既存のソフトウェアの依存関係に関する正確な情報が不足している場合は、これを効果的に実行する能力が制限されます。このシナリオでは、新しいインストールが、ファイアウォール・ソフトウェアを備えた新しい専用サーバーにインストールされるため影響は小さいと評価されます。3 つ目のインストールは、既存のアプリケーションをホストするサーバーをアップグレードする必要があるため、影響は大きいと評価されます。最新バージョンの J2EE サーバーと既存のアプリケーションの 1 つは互換性があるが、その他はアップグレードが必要であると結論付けるためには、膨大な手作業による調査が必要です。これを解決するために追加の RFC が提出され、この新しい RFC がそれに依存する RFC に関連付けられます。

オートノミック・プロセスでは、変更アナリストが、自動影響評価ツールを自動支援モードで使用して、意図したターゲット環境が SDD で記述された依存関係を満たしているかどうかを検証し、影響を受ける可能性のあるアプリケーションが RFC 内で正しく特定されていることを確認します。図 6 に示されているように、評価ツールは、標準の WSDM インターフェースを使用して CMDB と DSL 内の情報にアクセスする部分的なオートノミック・マネージャーです。この分析の自動化は、SDD の作成者が要件を指定するためと、CMDB でリソース・インスタンスを記述するために使用されるリソース・タイプの一貫した定義が鍵になります。

新しいアプリケーションと既存のアプリケーションに関する SDD を分析して、CMDB 内の情報と比較することによって、評価ツールは最新バージョンの J2EE サーバーと既存のアプリケーションの 1 つは互換性があるが、その他はアップグレードが必要であると自動的に結論付けることができます。追加の RFC は、SDD 内の依存関係情報に基づいて自動的に生成されます。また、このツールでは、オペレーティング・システムとデータベース・ドライバーの更新に必要な RFC の特定と生成も行われます。

HR アプリケーション SDD によって、Web サーバー上のセキュリティー設定の必要性も特定されます。このレベルの詳細は CMDB に保存されないため、ツールから設定を調査する必要性が報告されます。変更アナリストが、構成変更とリサイクルの必要性を確認し、その変更を実行するための構成スクリプトを提供するアプリケーション・サーバー・サポート・チームに詳細を転送します。

変更の承認とスケジューリング

現行プロセスでは、リリース内の RFC が、変更審議会によって評価および承認され、予定されたリリース・サイクルの完了に続く最初の保守の時期にスケジュールされます。スケジューリング期間に、アプリケーション・リリースの 1 週間前に軽微なオペレーティング・システムの更新が行われることが決定されます。変更アナリストは、適切な専門家に相談して J2EE サーバーが新しいオペレーティング・システム・レベルをサポートしているかどうかを確認し、新しいオペレーティング・システム・レベルでテストを実施する必要があることをリリース・チームに伝達します。承認された RFC が実装のためにリリース管理に渡されます。

オートノミック・プロセスでは、前回のオートノミック・プロセスの変更評価アクティビティー期間に入手された補足情報を使って、Web サーバーのリサイクルの必要性と事前に必要な追加の RFC がスケジューリングで考慮されます。詳細な依存関係情報によって、保留中の変更に関する情報も考慮することができます。リリース前にオペレーティング・システムの更新が行われることが変更アナリストに通知されます。自動依存関係分析の結果、新しいオペレーティング・システム・レベルが J2EE サーバーでサポートされていることがわかります。

リリースの構築とテスト

現行プロセスでは、リリース・スペシャリストが必要なすべてのコンテンツを組み立て、テストし、リリースのビルド、インストール、およびロールバック用のスクリプトを作成します。この時点で、不明なまたは不正な依存関係が発見され、RFC の変更と再承認が必要になる場合があります。リリース・スペシャリストは、セキュリティー・スペシャリストなどの、開発チームおよび運用チームと緊密に連携して、アプリケーションが運用展開に対して適切に調整され、標準の Web プラットフォーム上で動作するように構成され、現行のセキュリティー・ポリシーに準拠していることを保証する必要があります。

HR アプリケーション・シナリオでは、リリース・テストによって、一部のオペレーティング・システムとデータベース・ドライバーを更新する必要があることが判明します。これらの変更は、提出された後に、同じ保守の期間に適用しなければならない前提条件としてのタグが付けられます。また、Web サーバーのセキュリティー設定をそのアプリケーションをサポートするように更新する必要があり、これらの設定を有効にするために Web サーバーをリサイクルする必要があることも判明します。そのため、追加の RFC の承認を獲得し、同じ保守の期間にスケジュールされた一部のより優先順位の低い変更を後回しにしてリサイクルの時間を確保する必要があります。許可およびテストされたアプリケーション・パッケージは、DSL に保存され、CMDB に登録されます。

オートノミック・プロセスを使用した場合は、リリース・ビルダーが、HR アプリケーション SDD、構成スクリプト、およびリリースを構成するその他のソフトウェア (事前に必要な更新や修正を含む) で構成されるソリューション・パッケージを構築します。この SDD は、リリースの受け入れバージョンを展開するために使用されます。受け入れテストが完了したら、新しいソフトウェア・パッケージと SDD が DSL に保存され、CMDB に登録されます。依存関係を処理するための手作業が排除または大幅に削減されます。

詳細なロールアウト計画の作成

現行プロセスでは、リリース・プランナーが、リリースの要素間の依存関係とそれらのインストール手順 (変更を有効化するためのサーバーのリサイクルの必要性など) を考慮しながら、リリースをインストールするための計画を策定します。シナリオ 2 では、このロールアウト計画の実行について説明します。

オートノミック・プロセスでは、リリース・ビルダーが、特定のターゲット上のソリューション SDD を適切な構成値でインスタンス化するために必要なインスタンス・パラメーターを各場所に提供します。リリースのソフトウェア面のロールアウト計画は、インスタンス・パラメーターとソリューション SDD の組み合わせから構成されます。SDD にはソフトウェアとその依存関係の展開を自動化するのに十分な情報が含まれているため、計画を作成するための手作業が大幅に削減されます。

ソリューション展開シナリオ 2 - 自動オーケストレーション

ソリューション展開シナリオ 2 では、シナリオ 1 で計画および構築されたリリースの展開におけるオートノミック・テクノロジーの役割を検証します。

承認とスケジューリングが完了すると、リリース展開を調整するためのリリースの実装物が割り当てられます。リリースの実装者は、必要なすべての変更を実施する権限を与えられる場合と、組織の複数の領域のスペシャリストと連携しなければならない場合があります。

リリースの実装者が、スペシャリストと連携して、シナリオ 1 で定義されたロールアウト計画を実行します。この作業は、特に、ロールアウト計画が自動スクリプトで収集されたのではなく、文書化されただけの場合に、間違いの元になる可能性が高くなります。自動スクリプトが定義されている場合は、環境固有になっている可能性があり、実際の展開場所の多様性に対応できない可能性があります。

オートノミック・プロセスでは、リリースの実装者が、すべての作業を実施する権限を与えられ、自動展開ツールを使ってリリースを実装することを前提とします。図 6 に示されているように、これは、SDD からオーケストレーション・フローを生成可能なオーケストレーション・ツール (「計画」オートノミック・マネージャー) で構成されます。この最新の拡張機能は、まだ評価段階ですが、これまでのテストに基づけば、その機能には実稼働環境で使用するのに十分な信頼性があります。ただし、リリースの実装者はこのツールで作成された計画を検証する必要があります。そのため、オートノミック・マネージャーは、「監視下委任」モードで使用されます。

展開期間は、以下のアクティビティー・シーケンスに従います。

1. 場所ごとに、リリースの実装者が、ソリューション・パッケージとその展開用のインスタンス・パラメーターを特定するロールアウト計画を入手します。
2. 展開オーケストレーション・ツールを使用して、そのツールのデータ・モデルに基づいて、展開に使用される実際の物理ノードにリリース計画がマップされます。
3. 展開オーケストレーション・ツールが、関連する SDD を DSL から取り出し、(WSDM インターフェース経由で問い合わせることによって) CMDB またはローカル・データ・モデルから取得した既存のリソースの既知の構成に照らして SDD 要件をチェックします。問題があれば、リリースの実装者に報告します。
4. 展開オーケストレーション・ツールが、SDD を使用して、リリース計画内の物理的なターゲット情報とパラメーター化情報に基づいてオーケストレーション計画を作成します。
5. リリースの実装者が計画をレビューして承認します。
6. オーケストレーション・ツールが、(DSL から取り出した) ソフトウェアの配布とその後の展開を調整します。ソフトウェアがエンドポイントに配布されたら、オーケストレーション・ツールがそのエンドポイントでローカル・インストール・ツールを呼び出します (階層型オートノミック・マネージャー・パターンの実装)。
7. 各ローカル・インストール・ツールが、WSDM インターフェースを使用して、ローカルなターゲット・ソフトウェアに関する依存関係のチェック、計画、および実行を実施します。
8. 展開が完了すると、CMDB が、新しく展開または更新されたリソースを許可されたベースラインの一部として含むように更新されます。

リリースの実装に SDD とオートノミック・マネージャー機能を使用することによって、リリースの実装者は、信頼性の高い反復可能なリリースを展開し、人的エラーや伝達ミスを削減することができます。また、展開でのサブジェクト・マター・エキスパートの関与を減らすことができます。計画と実行の自動化を通して、実行期間を短縮し、実施された処置の明確な監査と自動ロールバックを実行可能な能力の両方を提供することができます。CMDB 承認済みベースラインを SDD 知識で更新することによって、構成監査問題の誤認が削減され、CMDB データの正確性が向上します。

上に戻る

オートノミック・コンピューティング・イニシアチブの発足以来、オートノミック機能は、実証可能なビジネス価値を提供するように設計された漸進的なモデルを基礎として成長および成熟してきました。ここで示したように、必要なオートノミック機能の提供は、ACRA の幅広い文脈の中の重要なテクノロジー、仕様、およびアーキテクチャー・パターンを基礎としています。

ITIL ベースのシナリオを通して示したように、オートノミック・コンピューティングの価値は、段階的な IT プロセス変換をもたらすその能力にあります。さらに重要なことは、リファレンス・アーキテクチャーと関連要素で記述されたオートノミック・コンピューティングによって、ビジネス主導の IT インフラストラクチャーと関連プロセスの漸進的変化をもたらすフレームワークが提供されることです。

上に戻る

本稿に記載された概念の発展に貢献された同僚の皆さんに感謝致します。特に、John Sweitzer、Dave Ehnebuske、Randy George、Jim Crosskey、Pat Rago、Hari Madduri、David Kaminsky、Jim Whitmore、Mark Weitzel、La Tondra Murray、および Ric Telfordに感謝します。

*IBM Corporation の商標または登録商標です。
**United Kingdom Office of Government Commerce または Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。

上に戻る

引用文献

1. 「Autonomic Computing: IBM’s Perspective on the State of Information Technology」、IBM Corporation, http://www.research.ibm.com/autonomic/manifesto/autonomic_computing.pdf.
2. A. G. Ganek、T. A. Corbi 共著、「The Dawning of the Autonomic Computing Era」、IBM Systems Journal 42, No. 1, 5-18 (2003 年)
3. 「IBM Paves the Way for Mainstream Adoption of Autonomic Computing」、IBM Corporation、http://www.ibm. com/autonomic/press_041905.shtml
4. 「Dynamic Systems Initiative」、Microsoft Corporation http://www.microsoft.com/business/dsi/default.mspx
5. 「Adaptive Enterprise」、Hewlett-Packard Development Company, L.P., http://h71028.www7.hp.com/ enterprise/cache/6842-0-0-225-121.html
6. 「Sun N1 Grid Engine 6」、Sun Microsystems Inc., http://www.sun.com/software/gridware/
7. 「Autonomic Computing」、IBM Research, http://www. research.ibm.com/autonomic/research/
8. 「The 3rd International Conference on Autonomic and Autonomous Systems」、Athens, Greece (2007 年 6 月), http://www.iaria.org/conferences2007/ICAS07.html
9. 「The 4th IEEE International Conference on Autonomic Computing」、Jacksonville, FL (2007 年 6 月), http://www.acis.ufl.edu/~icac2007/index.shtm.
10. 「International Conference on Self-Organization and Autonomous Systems in Computing and Communications」、Erfurt, Germany (2006 年 9 月), http://www.soas2006.org/
11. J. Kephart、J. O. Strassner 共著、「Autonomic Systems and Networks: Theory and Practice」、Proceedings of the IEEE/ IFIP Network Operations and Management SymposiumVancouver, Canada (2006 年), p. 588
12. R. Cutlip、C. Zabeu 共著、「Autonomic Computing: Strengthening Manageability for SOA Implementations」、ホワイト･ペーパー、IBM Corporation (2006 年 12 月), http://www.ibm.com/autonomic/pdfs/AC_SOA_EB.pdf
13. C. Draper 著、「Combine Autonomic Computing and SOA to Improve IT Management」、IBM Corporation (2006 年 4 月), http://www.ibm.com/developerworks/library/ac-mgmtsoa/index.html
14. R. Cutlip 著、「SOA and Autonomic Computing」、Proceedings of The Open Group: Enterprise Architecture Practitioners Conference, San Diego, CA (2007 年 1 月)
15. 「Autonomic Computing Industry Standards」、IBM Corporation, http://www.ibm.com/autonomic/industry.html
16. V. Tewari、M. Milenkovic 共著、「Standards for Autonomic Computing」、Intel Technology Journal 10, No. 4, 275-285 (2006 年)
17. 「Information Technology Infrastructure Library (ITIL)」、Office of Government Commerce, http://www.itil.org.uk.
18. K. Behr、G. Castner、G. Kim 共著、「The Value, Effective- ness, Efficiency, and Security of IT Controls: An Empirical Analysis」、http://www.itpi.org/docs/veesc.pdf
19. 「An Architectural Blueprint for Autonomic Computing」ホワイト・ペーパー、IBM Corporation (2006 年 6 月), http://www.ibm.com/autonomic/pdfs/AC_Blueprint_White_Paper_4th.pdf
20. 「OASIS Web Services Distributed Management」、Organization for the Advancement of Structured Information Standards (OASIS), http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm
21. 「Common Information Model (CIM) Standards」、Distributed Management Task Force,Inc., http://www.dmtf.org/standards/cim/
22. D. Kaminsky 著、「An Introduction to Policy for Autonomic Computing」、IBM Corporation, http://www.ibm.com/developerworks/autonomic/library/ac-policy.html
23. OASIS Standard wsdm-muws-part1-1.0「Web Services Distributed Management: Management Using Web Services」、W. Vambenepe (編集者)、Organization for the Advancement of Structured Information Standards (2005 年 3 月 9 日), http://docs.oasis-open.org/wsdm/2004/12/wsdm-muws-part1-1.0.pdf
24. H. Kreger 著、「A Little Wisdom About WSDM」、IBM Corporation, http://www.ibm.com/developerworks/webservices/library/ws-wisdom/
25. D. Ogle、H. Kreger、A. Salahshour、J. Cornpropst、E. Labadie、M. Chessell、B. Horn、J. Gerken、J. Schoech、M. Wamboldt 共著、「Canonical Situation Data Format: The Common Base Event V1.0.1」、IBM Corporation, http://www.eclipse.org/tptp/platform/documents/resources/cbe101spec/CommonBaseEvent_SituationData_V1.0.1.pdf
26. 「IBM Autonomic Computing Symptom Specification, Symptoms Reference Specification, Version 2.0」、IBM Corporation, http://download.boulder.ibm.com/ibmdl/pub/software/dw/opensource/btm/SymptomSpec_v2.0.pdf
27. M. Perazolo 著、「Symptoms Deep Dive, Part 1: The Autonomic Computing Symptoms Format」、IBM Corporation, http://www.ibm.com/developerworks/autonomic/library/ac-symptom1/
28. 「OASIS Solution Deployment Description (SDD)」、Technical Committee, Organization for the Advancement of Structured Information Standards (OASIS), http://www.oasis-open.org/committees/tc_home. php?wg_abbrev=sdd
29. 「IBM Tivoli Unified Process」、IBM Corporation, http://www-306.ibm.com/software/tivoli/governance/servicemanagement/itup/tool.html

2007 年 1 月 2 日に発表許可
2007 年 6 月 27 日にオンライン公開

Peter Brittenham
IBM Software Group, 4205 South Miami Boulevard, Research Triangle Park, North Carolina 27709。Brittenham 氏は、オートノミック・コンピューティング組織のシニア・テクニカル・スタッフ・メンバーです。現在は、IT サービス・マネジメントを可能にするための委任と自己管理リソースを中心としたオートノミック・コンピューティングのチーフ・プログラマーを務めています。Boston University で経営学の学士号を取得し、Marist College でコンピューター科学の修士号を取得しました。

R. Russell Cutlip
IBM Software Group, 4205 South Miami Boulevard, Research Triangle Park, North Carolina 27709。Cutlip 氏は、IBM オートノミック・コンピューティング・アーキテクチャー・チームのソフトウェア・アーキテクトです。最近の興味分野は、オートノミック・ビジネス・プロセスと SOA の相互作用です。2003 年に Addison-Wesley 社から出版された「Integrated Solutions with DB2」の共著者です。University of Pittsburgh で情報システムの管理と戦略的計画の経営学修士号を取得しました。

Christine Draper
IBM Software Group, 11501 Burnet Road, Austin, Texas 78758。Draper 氏は、IBM オートノミック・コンピューティング・アーキテクチャー・チームのシニア・テクニカル・スタッフ・メンバーで、社内の開発チームと共同でオートノミック・コンピューティング概念の IT サービス・マネジメントへの適用に取り組んでいます。OASIS の活動的なメンバーの一人である彼女は、ソリューション展開記述子の標準化に尽力しています。英国の University of Cambridge から優等賞を授与され自然科学の学士号を取得しました。

Brent A. Miller
IBM Software Group, 4205 South Miami Boulevard, Research Triangle Park, North Carolina 27709。IBM オートノミック・コンピューティング・アーキテクチャー・チームのシニア・テクニカル・スタッフ・メンバーである Miller 氏は、オートノミック・コンピューティングのリード・アーキテクトを務めながら、自己管理オートノミック・システムと ITSM に関連するテクノロジーと標準化の両方に取り組んでいます。Ohio State University でコンピューターおよび情報科学の学士号を取得しました。2000 年に Prentice-Hall 社から出版された「Bluetooth Revealed」の共著者です。

Samar Choudhary
IBM Software Group, 4205 South Miami Boulevard, Research Triangle Park, North Carolina 27709。Choudhary 博士は、現在、IBM の統合ソリューション・コンソール・プロジェクトのチーフ・アーキテクトを務めています。University of Minnesota でコンピューター科学の修士号を取得し、Northern Illinois University で数学の博士号を取得しました。

Marcelo Perazolo
IBM Software Group, 4205 South Miami Boulevard, Research Triangle Park, North Carolina 27709。Perazolo 氏は、IBM オートノミック・コンピューティング・アーキテクチャー・チームのメンバーで、症状、仮想化、および知識表現に関するシニア・アーキテクトを務めています。ブラジルの State University of Campinas で電気工学の学士号と修士号を取得しました。

目次へ戻る

上に戻る