IT オートパイロットは、情報技術 (IT) システム管理サービスのデリバリーをサポートするための柔軟なアーキテクチャーです。複数のツールが必要な複雑なサービスでは、ツールと複数のツールを呼び出すことのできる自動プロセスを統合する必要があります。主に中堅企業向けに設計された IT オートパイロットのアーキテクチャーは、IT オートパイロットを柔軟で拡張可能なサービス・オファリングとして企業やサービス・プロバイダーから提供されるローカル・サービスとリモート・サービスのセットとして展開することを可能にします。IT オートパイロットを統合した IT サービス・マネジメント・プラットフォームは、異なるツールとサービスを組み合わせて個別にカスタマイズした IT サービス・ソリューションを作成することができます。たとえば、これに類似した飛行機のオートパイロットの場合は、パイロットが、まず、飛行機を離陸させるための一連の手動操作を実行します。その後は、通常の飛行操作の維持がオートパイロットに委ねられます。我々の構想では、初期の手動構成手順の後に、IT オートパイロットがお客様の通常の IT 運用状態を引き継いで維持します。本稿では、我々の構想を紹介し、我々が実装した試作システムについて説明します。
今日の経済活動では、大部分の専門職がコンピューター・リソースをフルに活用せざるを得なくなっています。コンピューターを単純なデータ入力あるいは複雑な分析のどちらに使用するかに関係なく、生産性を確保し、社内と社外の両方にサービスを提供するためにはコンピューターが不可欠です。中堅企業や大企業の中には、数百または数千ものコンピューター・システムをサポートしている場合があります。このようなシステムを管理するには、適切なレベルのセキュリティー・システムや災害時回復システムのように、システム管理に関するポリシーとプロセスが明確に定義されたインフラストラクチャー・アーキテクチャーが必要です。このような環境におけるシステム管理には、会社のポリシーに忠実にベスト・プラクティスを実装する、適切なスキルとツールを身に付け、十分な訓練を受けた情報技術 (IT) プロフェッショナルのスタッフが必要です。
成功するシステム管理
システム管理実装の成功の鍵は、展開するすべてのシステムを通して一貫したソフトウェア構成とハードウェア構成のメンテナンスと、一連のポリシーと手順の厳守です。システム管理プラクティス、ポリシー、および手順の実装に関しては、大企業と中堅企業で大きな違いがあります。一般的に、大企業環境のコンピューター・システムは、システムの正常動作に影響を与える可能性のあるプログラムやコンポーネントのインストールを禁止して、将来のアプリケーションやオペレーティング・システムの更新に伴う競合の可能性を最小限に抑えるために厳密に管理されています。大企業の IT 部門は、経営者と協議してコンピューター・アクセスに関するポリシーを設定するのに十分な規模とスキルを備えており、ポリシーを会社のネットワークを通して効果的に展開することができます。コンピューター・システムのロック・ダウンに加えて、会社側でユーザーのアクセスを特定の Web サイトや外部ネットワークに制限して、潜在的な問題を抑制しようとする場合もあります。
大企業で問題が発生した場合は、ユーザーが問題レポートやトラブル・チケットをサポート・システムに提出するように指示されます。一方、サポート・システムでは、問題が記録され、解決するまで追跡されます。この処理には、通常、会社のプラクティスを反映するように構成されたワークフロー・エンジンが必要であり、多くの場合、ベンダーからトレーニングを受けた上級サポート・プロフェッショナルが対応する階層型ヘルプ・デスク・サポート・システムが必要です。大企業の顧客サポート・チームは、ベンダーと共同してトラブルシューティングを実施したり、ソフトウェア・パッチや管理用修正を作成します。この間、大企業のチームは、ベンダーのテクニカル・サポート組織の豊富な知識ベースに間接的にアクセスします。更新や修正の場合は、まず、IT 組織が、会社の環境における適用可能性に関して修正の調査を行います。修正は、いくつかの重要でないマシン上で手動でテストされ、互換性の問題を引き起こしたり、ターゲット・システムの動作に悪影響を及ぼしたりしないことが確認されます。その後で、修正は、ネットワーク上のいくつかのテスト・マシンに電子的に展開され、IT スタッフがその結果を観察します。IT スタッフは、展開が必要なことと、何らかの問題や副次作用が発生しないことを確認したら、中断時間を最小限に抑えるために勤務時間外に修正を配信するようにスケジュールを決定します。
大企業の IT 組織の多くが、管理対象コンピューター・システムに明確な承認なしに何らかの処置を行うことを嫌います。彼らは、システムの構成を確実に管理し続けたいと思っています。このような組織は、システム管理ツールで自動的に変更を実施できる場合でも、責任者が構成変更を承認することを選択します。
大企業では、IT 組織が、所定の評価プロセスを通してシステム管理ツールを個別に選択できる点も中堅企業 (SMB) と異なります。戦略を実行に移すときに最適なソリューションを提供するためには、複数のソフトウェア・ベンダーからさまざまなツールやコンポーネントを購入してインストールしなければならない場合があります。各ツールの統合可能性ではなく、適合性に重点が置かれます。
SMB の IT 管理 - 問題の記述
通常、SMB は 50 ～ 2500 人のユーザーをサポートしています。大企業と違って、SMB には独立した IT 部門が存在しない場合があります。コスト意識が非常に高いためにシステム管理タスクをオーナーやプリンシパルが実行している場合や、友人や知人が実行している場合さえあります。会社が大きくなるほど、このようなポジションは、ある程度のコンピューター・スキルを持ち、別の業務を抱えている社内の他の人間に兼務させることが多くなります。会社が成長を続けていれば、このようなタスクは、最終的に、専任のサポート・スタッフが必要なほど重要度が高まり、多くの場合、高価な契約社員やサービス会社によって補強されることになります。IT 部門または IT グループの責任者は、システム管理に関する正式なトレーニングを受けておらず、そこに長く勤めているという理由だけで任されることになります。
このような環境内のコンピューター・システムは、通常さまざまなメーカーや年代の既製システムと特注システムの寄せ集めで構成されていて、多くの場合、異なるオペレーティング・システムやアプリケーションがインストールされています。コンピューターの交換や追加にはコストがかかるため、事業主の多くは、しぶしぶ、ほうきや FAX 装置を選ぶような感覚でコンピューターを購入します。このような環境では、多くのシステムが最新になっておらず、ウィルス、ワーム、キー・ロガー、スパイウェアなどに侵されている可能性があります。このようなシステムは、その整合性だけでなく、すべてのシステムが接続されたネットワーク全体の整合性を阻害する時代遅れのソフトウェアを実行している可能性があります。このような環境では、一貫したシステム構成が維持されないため、システム管理ソリューションのインストールに適したインフラストラクチャーの構築が困難です。したがって、一貫したハードウェアとソフトウェアの標準を規定した規律だけが、組織に多くのメリットを提供することができます。
SMB 環境では、通常、更新をレビュー、テスト、またはインストールするための正式な手順が存在しません。ユーザーは、更新が入手可能になればいつでもシステムを更新するように勧められます。彼らは、通常、最低週 1 回は、ウィルスやスパイウェアのシグニチャーを更新したり、アンチウィルス・プログラムやスパイウェア検出プログラムを実行するように勧められます。大企業では、これらのツールが、更新を自動的にダウンロードして予定時刻に実行するようにセットアップされることが多くありますが、このような環境でさえ、問題が検出された場合は、通常ユーザーがその是正措置を実施しなければなりません。
どのような商用コンピューター環境でも、適切なインフラストラクチャーと手順を準備して、破局的な障害が発生した場合のデータのリカバリーに活用する必要があります。これには、バックアップの整合性を保証するための定期的な自動バックアップとアーカイブ・サービスを含める必要があります。
システム管理インフラストラクチャーの整合性を維持するための重要な要素は、ベスト・プラクティスの導入です。大企業の IT 組織はベスト・プラクティスとその実装方法をよく理解していますが、150 人規模の医療機関の医師が IT に関するベスト・プラクティスに関心を持つ可能性はかなり低くなります。したがって、SMB 環境に展開されたシステム管理のツールおよびコンポーネントがベスト・プラクティスを採り入れることによって、IT 管理者が手動でシステムをインストール、構成、または維持する必要がなくなるようにすることが重要です。中堅企業の環境によっては、ベスト・プラクティスを実装して人の介在なしに実践する必要があります。このような環境では、システムと共同作業を行っているかのようにツールとやりとりできることがシステム・マネージャーの助けになります1。
中堅企業によっては、システム管理を担当する IT 組織を設置しているところもあります。IT スタッフは、会社のビジネスと IT が会社の「最終的な収益」に与える影響を理解しています。この状況では、ビジネスの中断を最小限に抑える方法でシステム管理のポリシーと手順が実装されます。ある程度のシステム管理の自動化の導入に対して、IT プロフェッショナル (その多くがシステム管理に携わっていたことがある) がかなりの疑念を抱く可能性があります。多くの IT プロフェッショナルが、最も影響の少ない変更でさえ大きな問題に発展することを知っているため、システム管理の自動化を歓迎しません。彼らは、システムを監視して問題が検出されたときに報告してほしいだけでなく、潜在的なソリューションやアクションを実装前に確認したいとも思っています。
スキルが高いまたは知識が豊富な IT スタッフのいない SMB では、できるだけ多くのオペレーションを自動化して、IT 管理よりもビジネスに集中できるようにしたいと考えています。大企業と違って、ほとんどの中堅企業は、自動化されたアクションが問題やビジネスの中断を引き起こさなければ、オートノミック・システム管理を必要なものと見なします。彼らは、個々のツールの操作や IT インフラストラクチャーの維持の詳細を理解できるリソースやスキルを持っていないだけでなく、環境の円滑な運用を維持するためのベスト・プラクティスの可能性を正しく評価していません。その結果、これらの企業の多くは、接続が容易で、構成方法や運用方法が統一された完全なパッケージであるトータル・ソリューションを選択することになります。
したがって、SMB 市場向けのシステム管理ツールとプロセスでは、展開と構成用のさまざまなオプションを提供する必要があります。統合と自動化の度合い、個々のシステム管理ツール、およびベスト・プラクティスのすべてが体系化され、お客様が選択できる必要があります。この領域での我々の調査では、既存のシステム管理ツール、スイート、およびパッケージはこれらのニーズを満たしていないという結論に達しました。
目標
IT オートパイロットは、システム管理に特有の IT サービス用の統一されたアーキテクチャーです。その目的は、高水準のシステム管理プロセスの複雑さ、特に、複数のシステム管理ツールが使用されるプロセスの複雑さに対応することです。これらの部分的にまたは完全に自動化されたプロセスは、ユーザーや管理者がシステム管理ツールを使用せずに呼び出すことができます。IT オートパイロットは、さまざまなツール間のデータの流れを管理し、例外状態に対するプロビジョンを含めることができます。また、統合された再利用可能なプロセス、ポリシー、および知識を保証します。
前述したように、SMB の多くは、システム管理用のポリシーや手順を開発して実装するために必要なスタッフや専門知識を持っていません。彼らには、通常、システムを管理するための複雑なツールを習得している時間がないだけでなく、システム管理用のベスト・プラクティスを実装して実践するための知識もありません。IT オートパイロットは、お客様の環境をスキャンして、ネットワーク上のシステムやアプリケーションの種類を特定し、ベスト・プラクティスに基づくシステム管理ポリシーの作成と実装を支援します。このように、IT オートパイロットは、システムを分析して、インフラストラクチャーを管理するための一連の手順を提供します。
お客様からのフィードバックによれば、お客様は、IT スペシャリストではない個人が構成および保守できるトータル・ソリューションを求めています。このようなお客様は、複数のベンダーから個別のツールを購入するのではなく、単一のベンダーから、共通の統合インターフェースを提供し、システム管理機能を実行するための基になるツールを抽象化する単一のソリューションを購入したいと考えています。IT オートパイロットは、基になるシステム管理ツールを抽象化するアーキテクチャーを提供します。主に、既存の管理ツールとテクノロジーに基づいて構築された IT オートパイロットは、これらのテクノロジーをさまざまな IT サービスとシナリオを提供可能な単一の総合プラットフォームに統合します。オートノミック・コンピューティング MAPE (監視、分析、計画、実行) モデル2に基づく IT オートパイロットは、お客様の環境に合わせてカスタマイズされベスト・プラクティスに忠実なポリシーをインスタンス化します。IT オートパイロットが明確に定義されたプロセスとポリシーに従ってお客様を支援するため、お客様はシステム管理タスクを実行するために必要なツールやテクノロジーを理解する必要がありません。
本稿の残りの部分では、引き続き、IT オートパイロットの構造と機能、統合アーキテクチャー、そしてサービスについて説明します。その後で、SMB に特有の IT 要件に対応する潜在的なサービスについて詳しく説明します。また、初期の試作とそれが解決する潜在的なシナリオについて説明します。これらのシナリオの 1 つ、環境の発見および不可欠な IT サービスの展開を調査し、統合アーキテクチャーとサービスが連携してエンドツーエンド・ソリューションを実装する方法を示します。さらに、仮想マシン・ベースのアプライアンスの使用を含む、IT オートパイロットに基づくサービス・デリバリーの形態について説明します。最後に、将来の研究に関連した研究とトピックについて説明します。
IT オートパイロットは、統合アーキテクチャーと IT オートパイロット・サービスの無制限のセットで構成されます。統合アーキテクチャーによって、そのコンポーネントは、複雑なシステム管理タスクのサポートに必要な方法で実行および相互作用が可能である必要があります。統合アーキテクチャーは、コンポーネントの実行を開始、終了、管理できる必要があり、コンポーネントが実行されるプラットフォーム (ハードウェアやオペレーティング・システム) の制限があってはなりません。システム全体をリサイクルせずに、新しいコンポーネントを追加したり、既存のコンポーネントを交換するために必要な工数を最小限に抑えることができることが望まれます。コンポーネントが遠隔地に存在している場合や、手動でしか実行できないタスクがプロセスに必要な場合があります。このような要件は、サービス指向アーキテクチャー (SOA)3 で解決される要件の代表的なものです。
IT オートパイロットのアーキテクチャー
SOA は、標準ベースの疎結合されたステートレスな粗いシステムといわれ、多くの場合 Web Services (WS) 標準に準拠しています。3。このアプローチは、ワークフローおよびポリシー・エンジン、コンポーネント・アダプター、ステートフル・サービス (過去のアクションと結果に関するデータを維持するサービス)、知識リポジトリーが追加された IT オートパイロットにとって理想的です。概念上、IT オートパイロットは、管理する IT システムから独立しており、コンポーネント・ツール経由で管理対象環境に接続されます。実際には、個々のツールの要件によって、この分離が概念上のみになる場合があります。
図 1 は、IT オートパイロットの統合アーキテクチャーとサービス、管理対象システム上で管理アクションを実行するシステム管理ツールを示しています。この図では、IT オートパイロット・サービスの 1 つであるアダプター・ライブラリーがリモートでホストされています。中央にある非 WS 対応システム管理ツールは、IT オートパイロットとの必要な互換性を実現するためにアダプターによってラップされています。もともと、このツールは、そのインターフェースからコントロールやデータに WS としてアクセスできるように設計されていませんでした。右端の灰色のボックスは、独自仕様の統合アーキテクチャーによってスイートの 3 つのツールが接続されたツール・スイートを表しています。オートパイロット SOA に含める必要があるため、このスイート全体がアダプターによってラップされています。
図 1. IT オートパイロット、ツール、管理対象システム
拡大図
これは、WS 標準に基づく SOA、具体的には、エンタープライズ・サービス・バス4です。この図のメッセージング・インフラストラクチャーは、パッケージ化するツールおよび IT オートパイロット・サービスによって、直接的かつ局所的な HTTP (Hypertext Transfer Protocol) のように単純な仕様に基づく場合とセキュリティーで保護されたメッセージングやキューイングのように高度な仕様に基づく場合があります。結合がゆるいこととツールの共通プラットフォームに関する要件がないことから、ツールの追加や交換が、すべてのツールがプラットフォームを共有するツール・スイートよりも容易です。アダプター・ライブラリーには、一般に使用可能なツールやスイートの事前に構築されたアダプターが保存されます。
IT オートパイロット SOA は、エンタープライズ・アプリケーションの統合によく使用される SOA に似ています。その主目的は、疎結合されたサービスの統合です。サービス間のデータ・フローを通して、複雑なツール間プロセスの実装が可能になります。
また、IT オートパイロットは、自動化するプロセスが企業の IT インフラストラクチャーの可用性と整合性に影響を与えるため、暗黙的な時間制約と明示的な時間制約の下で動作します。セキュリティーの脅威や障害に対処する場合、IT オートパイロットは、損害を最小限に抑え、IT インフラストラクチャーを正常な状態に戻すために迅速に機能する必要があります。
IT オートパイロットによって次の 3 つの新たな効果がもらされます。最初の効果は、ワークフロー・ベースの制御と、管理対象システム内での変更を可能にするサービスのオーケストレーションです。2 つ目の効果は、オートノミック・コンピューティング MAPE モデルに基づく特定の IT 管理サービスの自動化です。3 つ目の効果は、特定の SMB 要件に適合させるためのデフォルトのポリシーのカスタマイズです。
オートパイロットなどの自動システム管理ソリューション用のシステム管理ツールの選択は重要です。中堅企業の多くは、IT スタッフが複雑で多機能なツールをマスターするために必要なレベルのトレーニングに投資することはできません。そのため、機能性が低く、ユーザー・インターフェースが簡易な、より単純で理解しやすいツールを使用することになります。IT オートパイロットは、完全な機能を備えたツール向きです。ツールをプロセス手順としてプログラムで呼び出すことによってその複雑さを隠すことができます。ツールの制御方法に関する詳細は、プロセス定義と関連する知識ベースのどちらかに含めることができます。複雑で強力なツールにはコストがかかります。このようなツールは、他のツールと簡単に統合することができなかったり、特定の環境に合わせて構成することが難しかったり、初期の購入コストが高かったりします。
IT オートパイロットのサービス
統合アーキテクチャーのほかに、IT オートパイロットには、知識保守、プロセスとポリシー、コンソール、IT オートパイロット・データ、およびサービス・デスクに関するサービスが含まれています。これらのサービスは、複雑なツール間システム管理タスクのプロビジョンに特有です。今後、サービスの範囲が広がることを予測しています。
知識保守
IT オートパイロットは、エンジニアや管理者などのユーザーによって作成されたソリューションを保存する知識リポジトリーに含まれるデータを使って問題の解決やサービス要求への対応を支援することができます。IBM Tivoli* Monitoring 5 問題判別ワークフロー機能など、IBM のプラットフォームに統合可能なこのサービスを提供するソリューションが複数存在します。
プロセスとポリシー
IT オートパイロット・アーキテクチャー上のシステム管理タスクは、プロセス定義として表現したり、ポリシーによって変更したり、ワークフロー・エンジンによって実行することができます。このタスクの表現方法は、非常に柔軟で、保守と拡張が容易です。プロセス定義によって、IT 管理のビジネス・プロセスが規定されます。つまり、IT を会社内部のビジネスとしてとらえている場合は、そのビジネス・プロセスが IT オートパイロット・プロセスになります。
我々の目的では、プロセスはシステム管理タスクを実行する一連のシステム管理アクションを表します。代表的なタスクには、新しいユーザーを IT 環境に追加したり、特定のサーバーを予備のサーバーと交換するためのタスクがあります。プロセスは、IT インフラストラクチャー内の変更を表しているため、慎重に設定する必要があります。
可能な場合はいつでも、IT インフラストラクチャーの構成をプロセスが実行される前の状態に戻せる必要があります。
プロセスは、連続的にまたは同時に実行可能な一連の手順で構成されます。手順自体をプロセスにすることが可能で、その結果を次に実行する手順の決定に使用することができます。IT オートパイロットでは、プロセスとして定義されていない手順は、Web Services (WS) または目的が記載されたコード・フラグメントによって実行されます。
IT オートパイロット・アーキテクチャーでは、プロセスは、実行可能コード (ハードコーディングされたプロセス) として表現される場合と、IBM WebSphere* Process Server7 用に拡張された WS-BPEL (WS Business Process Execution Language) 標準6で記述される場合があります。プロセスの視覚表現は、IBM WebSphere Business Modeler8 を含むさまざまなツールを使って作成することができます。WebSphere Business Integration Collaborations9 が、制御された方法でカスタマイズが可能なビジネス・プロセス用の事前構築テンプレートを提供します。この種のテンプレートは、IT オートパイロットの汎用のシステム管理プロセスにとって理想的な表現方法です。テンプレートは、ベスト・プラクティス順守の強化に役立ちます。ベスト・プラクティスのソースの 1 つが IT インフラストラクチャー･ライブラリー** (ITIL**)10 です。この「ICT インフラストラクチャー管理」セクション11で IT オートパイロットに関係するテーマがとりあげられています。
我々の目的では、ポリシーはプロセスによって参照されるお客様固有のガイドラインです。ポリシーのコンピューター・ベースの表現方法は、IT オートパイロットで提供されるサービスのカスタマイズ可能性を向上させることができます (これは、包括的かつ全般的なプロセス定義、すべての管理対象リソースとそれらの依存関係の発見、包括的な知識ベースなどを必要とする積極的な目標です)。関連するコンピューター可読ポリシー表現には、Ponder12 や Policy Management for Autonomic Computing (PMAC)13 などがあります。Web Services Policy 1.2—Framework (WS-Policy) 標準14は、ガイドラインよりも WS の非機能的属性の仕様に深く関係します。ポリシーが本来あるべき場所はワークフロー・エンジンですが、残念ながら、この機能が組み込まれたワークフロー・エンジンは存在しません。
ポリシー参照は、ワークフロー内のポリシーが適用される各箇所に手順を追加することによって実現されます。または、ツールやハードコーディングされたプロセスのコード内に「決定点」を埋め込むことによってポリシーを参照することができます。
プロセス・インスタンスとは、プロセス定義をインスタンス化することによって作成されたシステム管理タスクのことです。IT オートパイロット・アーキテクチャーは、IT オートパイロット・コンソールを使用したシステム管理者との相互作用を通してか、またはプロセスを別のワークフロー内の手順としてプログラムで呼び出すことによる 2 つの方法で、インスタンス化するプロセス定義を選択します。このプログラマチックな選択は、存在する最良の問題解決手段に基づいてプロセス定義が選択される、問題の判別などに利用することができます。
IT オートパイロット・コンソール
IT オートパイロット・コンソールは、構成要素ツールからの情報をまとめ、システム管理者が IT オートパイロットやその基になるツールとやりとりできるようにします。このコンソールを使えば、管理者は、システム管理タスクの動作が規定されたプロセスやポリシーを表示または変更したり、実行されたシステム管理タスクとそのシステムへの影響を確認することができます。IT オートパイロット・コンソールは、IBM Tivoli Monitoring5 のコンポーネントである Tivoli Enterprise Portal Server (TEPS) を利用して開発されました。TEPS は Web ベースのテクノロジーです。
IT オートパイロット・データ
IT オートパイロットは、主に、構成要素ツール内に保存および管理されたデータを利用します。これには、長所と短所の両方があります。ツール内に保存されたデータが正確なことが長所です。ツールがデータ保守 (キャッシング、更新、複製など) を実行します。短所は、ツールが IT オートパイロット・レベルで必要なすべてのデータをアクセス可能にできるわけではなく、内部リポジトリーしか作成できないことです。また、ツールは、データを同期化したり、一貫したスキーマで体系化することができないため、重複したデータを保存する可能性があります。IT オートパイロットからアクセス可能な、ツールに保存されたデータの代表的な例が、一部の Tivoli ツールで使用および更新される IBM Tivoli Change and Configuration Management Database (CCMDB)8 です。IT オートパイロットが進化するにつれて、そのデータ・ニーズが増大することが予想され、ツールによって管理されるプライベート・データへの依存が問題になる可能性があります。この場合は、既存のデータ・リポジトリーに上位レイヤーを追加することによって、必要なデータのフェデレーションと管理を提供することができます。
サービス・デスクの統合
一般的に、サービス・デスクは、エンド・ユーザーとサービス・デスク担当者が IT インシデントを入力して追跡する手動サービスと自動サービスの組み合わせです。このサービスは、IT オートパイロット内でもお客様のインシデント・データの履歴を維持するという重要な役割を果たします。このサービスと他の IT オートパイロット・サービス間のやりとりは双方向です。IT オートパイロットは環境監視とポリシー・リポジトリーを共有し、サービス・デスク・コンポーネントは問題がポリシー違反の結果かどうかを共有します。
問題は、エンド・ユーザーが直接サービス・デスク・ポータルにアクセスする、エンド・ユーザーが直接サービス・デスク担当者に連絡する、または IT オートパイロットが直接検出するの 3 つの方法によってとりあげることができます。
これまでは、我々の IT 管理プラットフォームに統合可能な基本サービスの潜在的なプレイヤーを特定してきました。次のセクションでは、我々の試作の実装について詳しく説明します。
我々の最初のステップは、IT オートパイロットの試作を構築することでした。この試作の目的は、IBM Tivoli Monitoring (ITM)5 と Tivoli Application Dependency Discovery Manager (TADDM)15 の 2 つの管理ツールの機能を統合するメリットを示し、将来的により高度なサービスを実装するための基礎を確立することでした。Tivoli Enterprise Portal (TEP) は、システムのデータと制御の両方のための統合コンソールとして使用されます。同時に、お客様には、セルフ・サービス・ポータルが提供されます。このポータルでは、お客様が、コントローラーのプロセスの説明を読んだり、コントローラー内の特定のプロセスを有効/無効にすることができます。プロセスのそれぞれが、特定のシステム管理シナリオに対応しています。本稿では、2 つのシナリオを選択して実装します。最初のシナリオは、お客様の初期環境と新規導入リソースのための自動 ITM エージェントの展開と構成に関係します。2 つ目のシナリオは、初期のビジネスに不可欠なアプリケーションの発見に基づいて、セキュリティーやバックアップなどの不可欠な IT サービスのプロビジョニングに関するポリシー・ベースの推奨に関係します。
図 2. 初期の IT オートパイロット構成
拡大図
初期の試作は、WS ベースのアプローチを使って前述した 2 つのツールを統合します。ITM と TADDM によって、プログラマチックな制御と監視が WS として使用可能になりますが、WS インターフェース経由で必要な機能のすべてにアクセスできるわけではありません。したがって、これらのツールは、必要な機能を有効にするために拡張されました。
図 2 は、初期の IT オートパイロット構成の概要です。インテグレーターがこのシステムの中核です。インテグレーターは、WS を使用して TADDM および ITM と通信し、制御インターフェースからコンソールのグラフィカル・ユーザー・インターフェース (GUI) へのアクセスを可能にします。TADDM は、メイン・サーバー、CMDB (構成管理データベース)、および Windows ゲートウェイ経由で Windows システムのディスカバリーを可能にする Microsoft Windows** ゲートウェイ・サーバーで構成されます。ITM は、メイン・サーバー、統合コンソール、分散エージェント、およびいくつかのデータベース (Tivoli Data Warehouse と Enterprise Portal Database を含む) で構成されます。IT オートパイロットの最新バージョンでは、プレゼンテーション・レイヤーとして TEP が使用されます。図 3 は、IT オートパイロットのメイン・コンポーネントとそれらの相互作用を示しています。
このシナリオでは、システムが図 3 のようにお客様のネットワークに接続されている (「管理対象システム」) とします。IT 管理者が、お客様のネットワークのインターネット・プロトコル (IP) 構成パラメーターとシステムのアクセスに必要な資格情報を提供します (自動発見とエージェント展開を可能にするため)。その後で、管理者が、IT オートパイロットが対応すべき範囲 (IP アドレスやサブネット・マスクの範囲) を定義します。次に、IT オートパイロットが起動され、IT オートパイロット・インテグレーターが定義された範囲で TADDM の発見プロセスをトリガーします。その結果、お客様の環境の詳細情報を使って CMDB が生成されます。IT オートパイロット・インテグレーターが、発見の結果を分析し、環境内の物理インフラストラクチャーとインストール済みのソフトウェアに関する情報を抽出します。その後、発見されたデバイス・タイプ、オペレーティング・システム、およびソフトウェア・コンポーネントに基づいて ITM エージェントが展開されます。さらに、ビジネスに不可欠なアプリケーションの発見結果に基づいて、IT オートパイロットが、IT ベスト・プラクティスに関する提案を基礎とする、セキュリティー・サービスとバックアップ・サービスに関する推奨を提供します。お客様の選択に基づいて、新しく推奨されたサービス (Tivoli Storage Manager など) が展開されます。最後に、IT オートパイロット・インテグレーターが、ITM 監視プロセスを開始します。
図 3. IT オートパイロット・コンポーネント間の相互作用
拡大図
IT オートパイロット・インテグレーターが定期的に TADDM の発見プロセスをトリガーします。新しいリソースが環境に導入されると自動的に発見されます。インテグレーターが、その存在を認識して、新しく発見されたリソースに対して ITM エージェントの展開を開始します。その結果、監視コンポーネントが、オペレーターの介在なしで自動的に展開され構成されます。必要に応じて、IT 管理サービス更新が、展開前にオペレーターの承認を待ちます。
IT オートパイロット試作の可能性を十分発揮させるためには、次のサブセクションで説明するいくつかのシナリオを発展させる必要があります。シナリオの選択基準は、IT オートパイロットによって可能になる統合と複雑なツール間管理プロセスを定義する能力を活用することによって顧客価値を示すことでした。インテグレーターは、複数のソースからの異種データを結び付け、既知の結果、観察された結果、または計算された結果に基づいて仮説を立てたり、結論を導き出すことができます。
構成エラー
監視を通して、IT オートパイロットが、システムからインターネットに接続できないことを検出します。TADDM インベントリーを使用して、未接続のマシンの構成とテンプレートで表現された有効な構成が比較されます。違いが見つかった場合は、変更を実施するためのプロセスがディスパッチされ、問題のマシンが正しい構成に更新されます。違いが見つからなかった場合は、システムが、問題のマシンと同じサブネット上のマシンを検索します。マシンが見つかった場合は、システムがそのマシンに対してテストを実施してインターネットにアクセスできるかどうかを確認します。そのテスト・マシンもインターネットに接続できない場合は、IT オートパイロットがテスト・マシンの構成が正しいかどうかを確認します。その設定が正しかった場合は、IT オートパイロットが、問題がネットワーク上のどこかに存在すると判断して、ネットワーク問題イベントを発生させます。ネットワーク問題イベントが検出されると、適切なネットワーク問題解決モジュールに転送され、オプションで IT オートパイロット・コンソールに、解決には人の介入が必要な問題として記録されます。
トランザクション・エラー
IBM Tivoli Composite Application Manager (ITCAM)16,17 がトランザクションに伴う問題を検出します。IT オートパイロットは、TADDM インベントリーと依存データを使用して可能性のある構成変更を検出し、インテグレーターに報告します。また、ITM 非オペレーティング・システム (非 OS) エージェント (ITCAM for HTTP 16、ITCAM for Web-Sphere16、IBM DB2* エージェント18) を使用してトランザクションに参加している個々のリソースからデータを収集します。さらに、TADDM 依存データと ITM 非 OS エージェント監視データを組み合わせて、トランザクションの失敗に関与しているリソースを特定します。
セキュリティー
ローカル・ネットワーク上のトラフィックを監視し追跡するオプションのネットワーク監視モジュールが、システムがウィルスに感染していることを検出します。ネットワーク・モニターが、パケット検査、相関、パターン分析を組み合わせて、感染の種類を特定します。IT オートパイロットが、TADDM からの接続情報とセキュリティー情報を使用して、感染したマシンに接続し、アンチウィルスとスパイウェア・シグネチャーの更新を強制して、そのマシンのアンチウィルスとスパイウェア・スキャンを実施し、問題の脅威を除去し修復します。その後で、予防手段として、この更新をローカル・ネットワーク上のすべてのシステムにプッシュし、それらのシステムに対してスキャンを起動します。
ポリシーとセキュリティー
IT オートパイロットが、ITM とその他の手段のどちらか、またはその両方を使用して、共有制限に違反している、または、マシン上のポリシーに違反している権限が存在することを検出します。TADDM インベントリーを使用して、そのマシンの構成と許可された構成が比較されます。違いが見つかった場合は、ポリシーの順守を保証するための適切な変更が実施されます。
IT オートパイロットの究極の目的は、サービスのプロビジョンです。その柔軟性によって、さまざまな方法でサービスを提供することができます。このセクションでは、このような方法のいくつかとそれらを実現するためにしなければならないことについて説明します。
サービス・オファリング
IT オートパイロットは、アプライアンスとして、仮想マシン内にパッケージされた仮想アプライアンスとして、またはお客様やビジネス・パートナーが用意したハードウェア上で動作するソフトウェアとしてなどのさまざまな方法でインストール、構成、運用するように設計されています。最初のケースでは、IT オートパイロットが、ローカルに提供されるサービスのすべてを含むスタンドアロン・アプライアンスとしてインストールされます (アプライアンスは、ソフトウェアが、内蔵タイプのハードウェア・プラットフォームにインストールされて提供され、お客様の管理対象システムに事前構成および自己構成されることを意味します)。この場合は、IT オートパイロットが、問題の検出と解決に事前構成されたテンプレートを利用します。インストール時に知識ベースが提供されます。IT オートパイロットは、最新の問題検出および解決データベースをダウンロードすることによって更新することができます。
サービス・デリバリーのアプライアンス・モデルを使用したビジネス・モデルでは、アプライアンスがごくわずかなコストで提供され、ユーザーは定期的な更新のための契約料金を支払います。更新は、ユーザーがダウンロードしてインストールすることも、利用可能になった時点で自動的にインストールすることもできます。これは、携帯電話会社が導入した、サービス提供からの利益に重点が置かれたモデルに似ています。
IT オートパイロットは IT システム管理に重点を置いていますが、そのインフラストラクチャーはその他のサービスも提供できるように設計されています。IT オートパイロットのプラグイン・アーキテクチャーによって、お客様、ビジネス・パートナー、またはプロバイダーは、互換性のあるさまざまなツール、コンポーネント、およびサービスを追加または集約することができます。これによって、お客様は、信頼できる最適なパートナーから付加価値を得ることができます。また、プラグイン・アーキテクチャーを使用すれば、ユーザーは、利用可能なサービスのカタログから新しいサービスを選択して展開することができます。(これらのサービスは、地域の法令や規制またはブロードバンド・アクセスなどのリソースの可用性によって制限または制約される可能性があります)。
動的なサービス・デリバリー
IT オートパイロットは、経営方針やビジネス目標によって管理されたサービスを提供します。会社が午前8 時から午後 5 時までの生産性を最大化する必要がある場合は、IT オートパイロットが、より都合のよい時間まで更新やその他の中断を要するアクティビティーを延期します。IT オートパイロットは、たとえば、お客様が頻繁にウィルスの発生やスパイウェアの感染を経験している場合は 1 時間おきにシステムをチェックすることによって、より積極的な対策を講じるように構成することができます。バックアップおよびリストア・サービスを導入した税理士事務所では、会計タスクに関連したシステムとビジネスに不可欠なシステムのすべてを 1 時間おきにバックアップするように指定し、その他のあまり重要でないシステムは週 1 回バックアップするだけよいと指定する可能性があります。
アプライアンスとしての IT オートパイロット
今日の業界では、ソフトウェア・アプライアンスが普及しています。所定のサービスを提供するための設定が完了しており、後は (電源やネットワークなどに) 接続するだけですぐに使用可能なソリューションを導入するという考え方が主流になっています。理想的なソフトウェア・アプライアンスは、自宅でトースターをコンセントにつなぐように簡単に使える必要があります。
IT オートパイロットを自己完結型のアプライアンスにすることが最終的な目標です。この意味は、人の介在を最小限に抑えた価値あるサービスを提供する IT ツールを統合することによって、必要なものを完備したソリューションを構築することです。試作の取り組みでは、アプライアンス・モデルを念頭に置いて、手動構成と意思決定が必要な箇所を制限するために自動化を使用しました。
ハードウェアとソフトウェアのどちらのアプライアンスでも、現地でアップグレードするための手段が提供されるのが普通です。重大な欠陥が発見されたときに製品を回収するよりもこの方がはるかに簡単だからです。IT オートパイロットでは、サブスクリプション・モデルとして実施されるアップグレードを想定しています。IT ツールとサービスの更新や問題判別用の知識データの更新などのさまざまなコンポーネントに対する機能強化が、サブスクリプション・ベースの更新機能を通して IBM から提供できます。
IT オートパイロットのモデルをハードウェア・ベースのアプライアンスとして実装するための 1 つのアプローチは、IBM BladeCenter* のブレード上でサービスとツールを事前構成することです。お客様の建物内でのインストールには、さまざまなシステム管理ツールのネットワークへの接続と適切な構成が含まれます。IT オートパイロットの内部構成は事前に実施することができます。
従来のアプリケーションの構成と展開用にカスタマイズされた方法と比べて、アプライアンス・モデルは単純ですが、柔軟性に欠ける部分があります。アプライアンス・モデルは事前構成を容易にしますが、アプライアンスの事前構成中はまだ柔軟性があります。この柔軟性は、事前構成されたアプライアンス・テンプレートとイメージのリポジトリーを通して支援されます。
アプライアンスは、制限された構成ポイントをカスタマイズできるように設計されています。この特性によって、仮想アプライアンスをリポジトリーから複製してカスタマイズすれば、お客様の環境でのインストールを大幅に簡略化することができます。カスタマイズ操作は、ソフトウェア製品を使用して完全に自動化することも、単純なスクリプトを通して手動で呼び出すこともできます。
図 4. IT オートパイロットの VM アプライアンスとしての展開モデル
拡大図
複数の IT ツールを統合する場合は、Microsoft Windows や Linux** などの複数のプラットフォームが必要な場合があることに注意してください。IT オートパイロット・アプライアンスのインストールを簡略化するための例として、単一の物理サーバー上で IBM Tivoli TADDM (Linux が必要) と IBM Tivoli ITM (Windows が必要) を同時にホストするための仮想化テクノロジーを利用することができます。ソフトウェア・パッケージではなく、仮想マシンをインストールするため、構成工数は最小限に抑えられます。次のセクションでは、このオプションについてさらに詳しく説明します。
仮想マシン・ベースのアプライアンスとしての IT オートパイロット
仮想マシン (VM) アプライアンスは、ドメイン・エキスパートからの要件に対して事前構成された VM イメージのセットです。このようなアプライアンスには、ミドルウェアとアプリケーションの両方がインストール、構成、調整されたオペレーティング・システムが含まれます。仮想化テクノロジーが実際のハードウェアを隠すため、VM アプライアンスは、開始および実行が容易で、仮想化環境以上のインストールを必要としません。この環境が整ったら、VM イメージをダウンロードして新しいホスティング環境で VM を起動することによってアプライアンスを開始することができます。
アプリケーションとソリューションを事前構成された VM アプライアンス・イメージとして配信することによって、ソフトウェアのインストールやカスタマイズ中の間違いを起こしやすい手動手順のほとんどが排除され、お客様の作業が大幅に簡略化されます。複数の顧客環境で VM アプライアンスを使用するには、アクセス可能な構成ポイントを制限することによって、ある程度の構成とカスタマイズを提供する必要があります。このセクションでは、ミドルウェアとアプリケーションを仮想アプライアンスとして配信およびカスタマイズ可能にする非常に単純なプロセスと対応するツールについて説明します。仮想アプライアンスのカスタマイズの目的は、構成操作を簡略化することによって、お客様の要件の 90% を処理することです。
VM アプライアンスの作成とインスタンス化には、2 つのフェーズがあります。最初のフェーズのアプライアンスの作成では、必要なカスタマイズ機能を使って仮想アプライアンスを作成します。2 つ目のフェーズのアプライアンスのアクティベーションでは、作成した仮想アプライアンス・パッケージ内のメタデータとスクリプトを使用して、新しい環境に合わせて VM アプライアンスをカスタマイズしてアクティブにします。
図 4 は、IT オートパイロット内で VM ベースのアプライアンス・モデルを使用する方法を示しています。ITM と TADDM は、お客様側の配信とカスタマイズ用の VM イメージとしてインスタンス化されます (比較のために図 2 参照)。
SMB 市場向けの複雑な IT サービスの統合および自動化されたデリバリーは、新しい研究領域です。我々の知る限り、提案されているのはポイント・ソリューションだけです。大企業をターゲットにしているシステム管理ベンダーは、既存のツールを基に中堅企業向けの新しいツールの開発を始めていますが、前述したように、中堅企業は、使いやすさがかなり向上したすぐに使用可能なソリューションを求め、自律型のソリューションさえも求めています。
IT オートパイロットの目標は、複雑なツール間システム管理プロセスの統合です。Naik 他19 は、独立したシステム管理ツールの調整へのアプローチに関するさまざまなレビューを紹介しています。
よく使用されるシステム統合に適したシステム設計手法が SOA3,4 です。SOA によって、IT オートパイロット・アーキテクチャーの基盤となる柔軟なアーキテクチャーが定義されます。SOA の導入に使用可能なテクノロジーの 1 つが WS20 です。我々は、IT オートパイロットでこのテクノロジーを活用するベスト・プラクティスに従っています。
IT オートパイロットの重要な課題は、オートノミック、プロセスとポリシーの実装、ツールのフェデレーション、アプライアンス・モデル、サード・パーティー・プロバイダーのプロビジョンに関係します。解決すべき疑問と探求すべき領域が数多く残っています。
IT オートパイロットは、問題検出情報、重み付けされた可能性のあるソリューションと推奨されているソリューション、および重み付けされた結果を含むデータ・リポジトリーを使用します。問題を解決しようとしている間に、IT オートパイロットが別の問題を表面化させる可能性があります。このような問題は、比較的重要でない場合や簡単に修正できる場合がありますが、IT オートパイロットでは解決できない、人の介在を必要とするより深刻な問題が、適用されたソリューションによって引き起こされた場合はどうなるでしょうか。IT オートパイロットは、結果が不確かでも問題解決処理を実行すべきでしょうか。ソリューションの適用後に問題が発生した場合は、IT オートパイロットが実装したばかりの変更をロールバックすべきでしょうか。変更をロールバックできるでしょうか。また、問題解決の実施方法と時期を制御するポリシーを設定すべきでしょうか。解決策を勤務時間外に延期すべきでしょうか。それとも、現在の運用を中断しなければならないほど重大でしょうか。
データ・リポジトリーは知識に相当します。知識は他の人の役に立つように共有すべきです。知識ベースは、新しいシナリオや解決データを使って更新できる必要があります。データは、IT 組織が公開したり、ビジネス・パートナーやリセラーが提供したり、ホスティング・サービスが提供することができます。
問題が検出されて修正されると、リポジトリーが最新の検出データと解決データを使って更新されます。解決シナリオが失敗した場合は、その解決策の格付けが下げられ、より有効なソリューションに置き換えることができます。こうして、ベスト・ソリューションだけが残ることになります。実際には、IT オートパイロットがその間違いから学習する形になります。
この機能をフル活用するには、リポジトリー内のデータをお客様または IT 管理者が理解できる形式で編集および公開できるようなツールを提供する必要があります。シミュレーターは、展開前にソリューションをモデル化してテストできるように、ソリューションとデータ・フローを表示できる必要があります。また、シミュレーターは、これを静的なテンプレートに基づくのではなく、現行のシステム構成を使用して実行できる必要があります。
ポリシー決定点を IT オートパイロット・プロセスに導入することによって、プロセス・デザイナーのやるべきことのチェックをポリシーで制御することができます。実際には、これは大きな負担になる可能性があります。ポリシーの概念が有効なことがわかっている場合は、すべてのプロセス定義に対するポリシー決定点の自動導入を検討することによって、プロセス設計が簡略化される可能性があります。
ITIL には、すべての構成情報と管理情報のための中央リポジトリーとして CMDB が含まれています。IT オートパイロットはツール統合プラットフォームのため、ITM、TADDM、ITCAM などの異なるアプリケーションでそれぞれの処理に必要な情報を保存するために異なるデータベースが使用されます。この情報の一部が不要に複製される場合があります。情報によって、関連しているもの、依存関係にあるもの、相互にリンクする必要のあるものがあります。これらの情報を結合して統合ビューが提供できれば、プロセスで決定の基になるより一貫した完全な情報を使用することができます。今後の研究では、アプリケーション・データのシステム・ビューの形成、情報とデータベースの統合、情報プロバイダー (ツール) 間のリンクと依存関係の構築、および ITSM を促進するための一貫したビューの提示に取り組みます。
サービス・デリバリーのアプライアンス・モデルに対する我々の関心は、一部がリソース集約型のツールの選択と矛盾します。このようなリソース・ニーズが、お客様のインストール用のソフトウェアの提供とすぐに使用可能なソリューション用のハードウェアの提供の両方を困難にしています。大企業と比べてパフォーマンスに対するニーズがさほど高くない中堅企業には、役に立つ軽量なツールが必要です。また、お客様の構成を自動的に発見して、手動構成手順を最小限に抑えることが可能なツールが必要です。
理論上は、サード・パーティー・プロバイダーが、IT オートパイロット・ベースのシステム管理ソリューションに参加できる必要があります。責任の分担、リソース使用の制限、適切な請求処理などの厄介な問題がまだ解決されていませんが、オープンな統合アーキテクチャーが必ずサード・パーティー・プロバイダーの参加を可能にします。
複雑なツール間システム管理プロセスのプロビジョニングで異なるシステム管理ツールを調整するためのオープンな統合アーキテクチャーを紹介しました。このアーキテクチャーは、さまざまな理由で有益ですが、WS としてプログラムでアクセス可能な適切なインターフェースを備えたツールが必要です。SOA は、ツールがプラットフォームによって決定されるのではなく、ツールをその機能に基づいて選択できる柔軟性を提供します。ツール・レベルで下位コンポーネントを統合することによって、「ツールにとらわれない」アーキテクチャーが提供され、ツールの機能ではなく、ビジネス・ニーズに従ってオートパイロットでタスクを管理することができます。
このアーキテクチャーには、問題の検出と解決の専門的な支援を提供する知識リポジトリーが含まれています。SOA の柔軟性とオープンネスによって、お客様、プロバイダー、およびパートナーは、容易に、独自の知識や専門技術を知識ベースに登録して、自分たちの経験を他の人のために役立てることができます。
中堅企業と大企業の両方と一緒に仕事をしたことによって、システム管理ソリューションでは、会社の規模に応じてさまざまな自動化モデルをサポートしなければならないことがわかりました。中堅企業は、自動化を要求または期待する傾向があります。IT スタッフのいる会社といない会社があり、システムの管理経験がない場合があります。IT オートパイロットが提供する自動化によって、システム管理タスクではなく、中核のビジネスに集中することができます。通常、大企業には、システム管理に関する問題を定期的に処理する IT 組織があります。大企業にとっては、IT 環境の厳密な管理を維持することが重要です。コンプライアンスを保証するために、大企業の多くは、ユーザーのアプリケーションのインストールやシステム設定の変更を禁止しています。IT 管理者は、変更の展開前に、提案された変更をレビュー、テスト、および承認する必要があります。このような場合は、自動化を提供するのではなく推奨を実施して、承認されたときだけ選択されたシステム管理タスクを実行するように IT オートパイロットを構成することができます。幅広い自動化に対応するために、IT オートパイロットは、WS-BPEL ワークフロー、ポリシー、およびハードコーディングされたフラグメントを組み合わせて、システムを根本的に変更するのではなく、動作を根本的に変更する柔軟性を提供します。
中堅企業向けの IT システム管理とツールに関する専門知識を提供して下さった IBM Tivoli Division の Luis Casco-Arias、Jim Crosskey、Jim Fletcher の各氏に感謝致します。また、この取り組みを支援して下さった IBM Research の Manoj Kumar 氏に感謝致します。さらに、このプロジェクトに早くから参加して下さった IBM China Research Laboratory の Pei Sun、Yu Fei Ma、Zhong Bo Jiang の各氏に感謝致します。
*IBM Corporation の米国およびその他の国における商標または登録商標です。
**United Kingdom Office of Government Commerce、Microsoft Corporation、Linus Torvalds、または Sun Microsystems Inc. の米国およびその他の国における商標または登録商標です。
- D. M. Russell、P. P. Maglio、R. Dordick、C. Neti 共著、「Dealing with Ghosts: Managing the User Experience of Autonomic Computing」、IBM Systems Journal 42, No. 1, 177–188 (2003 年)
- 「Practical Autonomic Computing: Roadmap to Self Managing Technology」、IBM Corporation 向けに作成されたホワイト・ペーパー、Enterprise Management Associates, Boulder, CO (2006 年 1 月)
- M. Colan 共著、「Service-Oriented Architecture Expands the Vision of Web Services, Part 1」、developerWorks, IBM Corporation
- M. Keen、S. Bishop、A. Hopkins、S. Milinski、C. Nott、R. Robinson、J. Adams、P. Verschueren、A. Acharya 共著、「Patterns: Implementing an SOA Using an Enterprise Service Bus」、IBM Redbooks (2004 年)
- 「IBM Tivoli Monitoring」、IBM Corporation
- J. O. Kephart、D. M. Chess 共著、「The Vision of Autonomic Computing」、IEEE Computer 36, No. 1, 41–50 (2003 年)
- 「IBM WebSphere Process Server」、IBM Corporation
- 「IBM Tivoli Change and Configuration Management Database (CCMDB)」、IBM Corporation
- 「IBM WebSphere Business Integration Collaborations」、IBM Corporation
- 「IT Infrastructure Library」、U.K. Office of Government Commerce
- 「ICT Infrastructure Management」、IT Infrastructure Library Services, U.K. Office of Government Commerce, Her Majesty’s Stationery Office, Norwich、United Kingdom (2002 年 5 月), ISBN-10:0113308655
- N. Damianou、N. Dulay、E. Lupu、M. Sloman 共著、「The Ponder Policy Specification Language」、Proceedings of the International Workshop on Policies for Distributed Systems and Networks, Bristol, U.K. (2001 年), pp. 18–39
- 「IBM Policy Management for Autonomic Computing」、alphaWorks, IBM Corporation, www.alphaworks.ibm. com/tech/pmac
- 「Web Services Policy 1.2 - Framework (WS-Policy)」、S. Bajaj、D. Box、D. Chappell、F. Curbera、G. Daniels、P. Hallam- Baker、M. Hondo 他、W3C Member Submission (2006年 4 月 25 日)
- 「IBM Tivoli Application Dependency Discovery Manager」、IBM Corporation
- 「IBM Tivoli Composite Application Manager for Internet Service Monitoring」、IBM Corporation
- 「IBM Tivoli Composite Application Manager for WebSphere」、IBM Corporation
- 「IBM Tivoli Monitoring for Databases」、IBM Corporation
- V. K. Naik、A. Mohindra、D. F. Bantz 共著、「An Architecture for the Coordination of System Management Services」、IBM Systems Journal 43, No. 1, 78–96 (2004 年)
- 「Web Services Architecture Working Group」、World Wide Web Consortium
2007 年 2 月 6 日に発表許可
2007 年 7 月 13 日にオンライン公開
Steve Mastrianni
IBM Research Division, Thomas J. Watson Research Center, P.O. Box 218, Yorktown Heights, New York 10598。Mastrianni 博士は、オートノミック・ソフトウェアとサービス・ソフトウェアを開発しているシニア・ソフトウェア・エンジニアです。経営管理学の学士号を取得し、コンピューター・サイエンスの修士号と博士号を取得しました。数年にわたってソフトウェア開発およびコンサルティングの会社を経営しながら、オペレーティング・システム、デバイス・ドライバー、リアルタイム・アプリケーション、データ収集、およびコンピューター 3D グラフィックスの開発に携わったのち IBM Research に入社しました。3 冊のプログラミング教本、膨大な数の会議論文、および業界誌の 100 件を超える記事の執筆者です。20 件の特許を取得しています。
David F. Bantz
IBM Research Division, Thomas J. Watson Research Center, 19 Skyline Drive, Hawthorne, New York 10532。Bantz 博士は、立ち上げ後すぐの 1972 年から 2005 年まで研究グループのメンバーでした。2006 年に非常勤職員として IBM に再度入社しました。1970 年に Columbia University School of Engineering and Applied Science をエンジニアリング科学の博士号を取得して卒業し、その大学と University of Southern Maine で 30 年以上、非常勤教授として教鞭を執ってきました。29 件の特許を取得しています。彼の技術的興味は、ずっと、パーソナル・コンピューティング・アプリケーションとテクノロジーにあり、現在は、自動システム管理を研究しています。
Kirk A. Beaty
IBM Research Division, Thomas J. Watson Research Center, 19 Skyline Drive, Hawthorne, New York 10532。Beaty 氏は、シニア・ソフトウェア・エンジニアです。彼の研究と興味には、システムとネットワークの管理、データベース管理システム、ストレージ・エリア・ネットワーク・ストレージ・システム、および Lotus Notest スケーラビリティーが含まれます。1981 年にシステム・プログラマーとして IBM に入社し、IBM Cambridge Scientific Center と Watson Research Center の両方で 10 年以上、システム管理ソフトウェアの開発に携わってきました。インディアナ州の Manchester College で数学とコンピューター・サイエンスの学士号を取得し、Harvard University でソフトウェア・エンジニアリングの Certificate of Advanced Study を取得しました。
Tom Chefalas
IBM Research Division, Thomas J. Watson Research Center, P.O. Box 218, Yorktown Heights, New York 10598。Chefalas 氏は、サービス・テクノロジーのシニア・テクニカル・スタッフ・メンバーです。New York University で 1988 年にコンピューター・サイエンスの学士号を取得し、1992 年にコンピューター・サイエンスの修士号を取得しました。1987 年に IBM に入社しました。現在は、デスクトップ管理、オートノミック・コンピューティング、およびエンド・ユーザー・サービスを研究しています。
Srikant Jalan
IBM Research Division, Thomas J. Watson Research Center, P.O. Box 218, Yorktown Heights, New York 10598。Jalan 氏は、1989 年に Indian Institute of Technology でエンジニアリングの学士号を取得しました。1994 年に IBM に入社し、現在は、デスクトップ、サーバー、分散システム、およびグリッド・ベース・システム用のシステム管理ソフトウェアを開発しています。彼の興味には、デスクトップ管理、エンド・ユーザー・サービス、およびライフ・サイクル管理が含まれます。
Gautam Kar
IBM Research Division, Thomas J. Watson Research Center, P.O. Box 218, Yorktown Heights, New York 10598。Kar 博士は、Systems and Network Management Group のマネージャーです。Ohio State University でコンピューターおよび情報科学の博士号を取得しました。1983 年に Thomas J. Watson Research Center に入社しました。1989 年から 1993 年まで、ドイツのハイデルベルクにある IBM European Networking Center で Distributed Applications Research Group のマネージャーを務めていました。1994 年から 1999 年まで、IBM Global Network Services Division でネットワークおよびシステム管理のシニア・マネージャーを務めていました。彼の研究的興味には、分散システムのパフォーマンスと可用性、およびサービスが含まれます。
Andrzej Kochut
IBM Research Division, Thomas J. Watson Research Center, 19 Skyline Drive, Hawthorne, New York 10532。Kochut 博士は、研究グループのメンバーです。University of Warsaw でコンピューター科学の修士号を取得し、University of Maryland でコンピューター・サイエンスの博士号を取得しました。彼の研究的興味には、コンピューター・システムの設計とパフォーマンス評価、ネットワーク・プロトコル、システム・モデリング、問題判別、および分散システムが含まれます。
Dong Jun Lan
IBM Research Division, China Research Laboratory, Building 19, Zhongguancun Software Park, 8 Dongbeiwang West Road, Haidan District., Beijing 100094, People’s Republic of China。Lan 氏は、IBM China Research Laboratory の High Performance Solution チームの研究者です。中国の北京にある Tsinghua University で電気工学の修士号を取得しました。国際的な会議で 10 件を超える論文を発表し、5 件の特許を取得しています。
Larry O’Connell
IBM Global Small and Medium Business, 1551 So. Washington Avenue, Piscataway, New Jersey 08854。O’Connell 氏は、成長市場を専門とする IT アーキテクトのグローバル・チームのディレクターです。Stern School of Business of New York University で MBA を取得し、Manhattan College で機械工学の学士号と修士号を取得しました。ニューヨーク州の公認技術士です。1998 年に IBM に入社する前は、IP ベースの音声、ビデオ、およびデータのコラボレーション製品を市場に投入するために Lucent/Bell Lab Multimedia Communications チームを率いていました。
Anca Sailer
IBM Research Division, Thomas J. Watson Research Center, 19 Skyline Drive, Hawthorne, New York 10532。Sailer 博士は、2003 年に IBM に入社し、現在は、Systems and Network Management 部門の研究グループのメンバーです。2000 年にパリにある Pierre and Marie Curie University でコンピューター・サイエンスの博士号を取得しました。2001 年から 2003 年までは、Lucent Technology の Bell Labs の Networking Research Laboratory で研究員を務め、インターネット・サービス・トラフィックのエンジニアリングと監視を専門としていました。Sailer 博士の興味には、Web サービス・アーキテクチャー、システム監視、問題判別、および自己修復テクノロジーが含まれます。
Gang Wang
IBM Research Division, China Research Laboratory, Building 19, Zhongguancun Software Park, 8 Dongbeiwang West Road, Haidan District, Beijing 100094, People’s Republic of China。Wang 氏は、IBM China Research Laboratory の High Performance Solution チームの研究および開発エンジニアです。2003 年と 2006 年に、中国の北京にある Peking University でコンピューター・サイエンスの学士号と修士号をそれぞれ取得しました。2006 年に IBM に入社しました。
Qing Bo Wang
IBM Research Division, China Research Laboratory, Building 19, Zhongguancun Software Park, 8 Dongbeiwang West Road, Haidan District, Beijing 100094, People’s Republic of China。Wang 氏は、IBM China Research Laboratory の Distributed Infrastructure Group の研究および開発エンジニアです。2000 年と 2002 年に、中国のハルビンにある Harbin Institute of Technology でコンピューター・サイエンスの学士号と修士号をそれぞれ取得しました。現在は、仮想アプライアンス・テクノロジーを企業の IT 環境に適用することによるシステム管理の簡素化を研究しています。
Dennis G. Shea
IBM Research Division, Thomas J. Watson Research Center, 19 Skyline Drive, Hawthorne, New York 10532。Shea 博士は、Services Research 部門のシニア・マネージャーです。Rensselaer Polytechnic Institute で電気工学の学士号と修士号を取得し、Florida Atlantic University で MAS を取得し、University of Pennsylvania でコンピューター・サイエンスの博士号を取得しました。彼のキャリアは、小規模システムを研究している IBM Boca Raton で始まりました。彼の技術的興味は、接続性、モバイル・ソリューション、およびクライアント管理サービスを中心に展開してきました。現在の興味は、お客様の問題を解決するためのサービス科学の研究とその応用の分野にあります。
目次へ戻る
| 
