構成管理運用ガイド

  • [アーティクル]
トピック

構成管理の概要 構成管理の概要
構成管理 構成管理
推奨トレーニング コース 推奨トレーニング コース

構成管理の概要

構成管理は、変更管理の制御下において、IT 環境を構成するあらゆるコンポーネント (ハードウェア、ソフトウェア、ドキュメント、プロセス、手順など) の識別、制御、追跡管理を受け持つ非常に重要なプロセスです。構成管理の目的は、構成アイテム (CI) と呼ばれる承認済みのコンポーネントのみを IT 環境で使用し、構成アイテムに対する変更を、コンポーネントのライフサイクル全体を通して、すべて記録し、追跡管理することにあります。代表的な CI として、ハードウェア、ソフトウェア、ネットワーク装置、構成、プロセス、手順、テレフォニー装置、ドキュメント、サービス レベル契約、問題の記録などを挙げることができます。構成管理の制御下に置く CI のデータは、IT 環境内の CI 追跡管理用リレーショナル データベースである構成管理データベース (CMDB) に格納します。

構成管理は、しばしば資産管理と混同されますが、後者は減価償却や原価計算などによる会計業務プロセスです。資産管理システムは通常、一定の額面を超えた価値を有する資産の情報を管理します。管理する資産情報には、業務ユニット、購入日、仕入れ業者、資産の所在地などがあります。管理される資産情報はほかの資産と関連において管理されず、主に高額な備品の所在の追跡管理に使用します。多くの組織では、まず資産管理から始め、それを発展させるかたちで構成管理に移行していきます。

構成管理と資産管理の相違は、前者においては、CI と CI の関係が、IT 環境における Cl 間の相互依存関係を前提として記録されている点に求められます。この関係情報は、組織にとって非常に有益な情報です。たとえば、サーバーのメモリをアップグレードする場合、CMDB をチェックすれば、サーバーをオフラインにしたとき影響を受けるユーザーとアプリケーションを特定できます。このとき、ユーザーにアップグレードの事前通知を行えば、ユーザーは予定に合わせた行動を取ることができます。これは、CI データと共に、データ相互の関係をデータベース化しておくことが、いかに IT アクティビティの合理化につながるかのよい見本です。

構成管理は多くの組織にとって業務に不可欠なプロセスとなっていますが、プロセスの実装コストに見合う効果が本当にあるのか判断に迷っている組織も少なくありません。そこで、この文書では構成管理の導入メリットを検討していきます。構成管理の適切な運用によって、構築や保守にかかるコストを補って余りある効果が期待できるからです。

ほかのプロセスとの関係

cfgmgt01

図 1: リリース管理、変更管理、構成管理、および他のプロセスの相互関係
拡大表示する

構成管理の運用の成否は、組織内の各種アクティビティの相互調整によって決まります。上図は、リリース管理、変更管理、構成管理、他の関連プロセスの相互関係を表しています。構成管理は、変更管理とリリース管理と並行的に実施されます。構成管理で最も重要なタスクは、IT 環境に実在するコンポーネントの情報を、正確に CMDB に反映させることです。そのため、コンポーネントに何らかの変更が加えられれば、逐一それを記録します。コンポーネントの変更に関する情報は、変更管理とリリース管理の両プロセスとの連携によって取りまとめられます。構成管理では、この変更情報を CMDB に記録します。

次の図は、CMDB に入力情報を提供し、CMDB から取り出して利用する組織内の各種プロセスを示しています。

cfgmgt02

図 2: CMDB との間でデータをやり取りする組織内プロセス

CMDB に向かう矢印は入力情報を表し、各種プロセスに向かう矢印は CMDB からの出力情報を表しています。出力情報の入手については後述します。

可用性管理
可用性管理は、信頼性の高い、生きたコンピューティング環境を常時ユーザーに提供するためのプロセスです。このプロセスは、構成管理と連携して、メンテナンスやその他の予定されたアクティビティの影響を受けるシステム コンポーネントを決定します。両者の連携によって、システム コンポーネントのダウンタイムを最小に抑えることができます。コンポーネントがダウンする際は、影響を受けるユーザーに通知が行われます。

キャパシティ管理
キャパシティ管理は、現行のシステム リソースの使用量が増加し、キャパシティの限界点に近づくのに合わせてリソースの追加投入を計画し、業務ニーズに最適な IT リソースを確保するためのプロセスです。このプロセスには CMDB からキャパシティ管理用の参照情報が提供されます。CMDB の情報によって、IT 環境を構成するコンポーネントの全容を把握することができます。この CMDB 情報のおかげで、キャパシティ プランやパフォーマンス管理といったキャパシティ プラン プロセスの主要アクティビティが容易になります。

変更管理
変更管理は、ソフトウェアのアップグレード、システム全体のオーバーホール、体制や人事に関する変更、業務上の変更など、組織内で発生するあらゆる変更を制御するプロセスです。このプロセスは構成管理と密接に連携を取りながら、すべての変更を確実に CMDB に記録します。また、変更プロセスの全体を通じて、CMDB に反映すべきシステム アップグレード情報を、構成管理に提供します。構成管理からは IT 環境のベースライン評価の情報を受け取ります。変更管理では、この評価結果を基に、変更が IT 環境に及ぼす影響を見極めます。

なお、CMDB に記録された CI はすべて変更管理の制御下にあります。言い換えれば、IT 環境で発生した CI の変更と、それに伴う CMDB の更新を承認する権限は、すべて変更管理にあります。これは非常に重要なポイントです。

緊急事態対策
緊急事態対策は、大規模な障害に対処するためのプロセスです。たとえば、停電によってデータ センター全体がダウンした場合や、水害、火事、テロ行為などによるダメージに対処します。CMDB 内のデータは、障害後の環境を復旧させるための見取図として利用できます。

経理管理
経理管理は、IT 環境の運用コストの分析と管理を担当するプロセスです。ここでは、ハードウェア、ネットワーク、トレーニング、管理者の工数、CPU 時間 (外部委託の場合)、ソフトウェアのアップグレードなどにかかわるコストを管理します。構成管理から経理管理には、ハードウェア コンポーネントの廃棄や再配置など、IT 環境の変更情報が通知されます。この場合、経理管理では、購入したソフトウェアやハードウェアの受領とインストールについて、構成管理データに照らした検証が行われる必要があります。

サービス デスクとインシデント管理
インシデント管理のメイン タスクは、インシデントを個別に管理し、なるべく早期に解決を図って、業務プロセスへの損失を極小化することにあります。インシデントとは、IT サービスの正常な運用を妨げる事象の総称です。インシデント管理では、CMDB を参照してインシデントの原因となった CI を特定します。この情報は構成管理にフィードバックされ、CMDB の更新によってインシデントとその影響範囲の CI が明示されます。未解決の問題は、問題管理に引き継ぎ、さらに詳細な評価と解決が試みられます。

問題管理
問題管理は、問題の根本的な原因を特定するためのプロセスです。問題とは、類似の現象を示す比較的軽微な 2 件以上のインシデント、または重大な 1 件のインシデントのことです。問題管理と変更管理の密接な連携によって、問題に対する解決が提示された場合、その解決案は通常、変更要求フォームに文書化されます。その後、構成管理によって問題に関するログが CMDB に記録され、その問題に関連する変更要求を追跡管理することで、後日の検索が容易になります。問題の解決策は CMDB に記録されます。新たなインシデントが発生した場合、サービス デスクではこれを再利用することができます。問題管理において CMDB は問題の根本原因を特定するツールとして利用されます。

リリース管理
リリース管理は、IT 環境におけるリリースの計画、テスト、導入のために、組織内のアクティビティを調整および管理するためのプロセスです。このプロセスを構成管理と組み合わせることで、最終ソフトウェア ライブラリ (DSL) へのアプリケーションの出入りを管理できます。DSL とは、IT 環境で使用されるアプリケーションのマスター コピーを格納しておくレポジトリのことです。リリース管理では、特定のリリースの影響を受ける CI やその影響の程度を判定する際にも、構成管理の情報が利用されます。

セキュリティ管理
セキュリティ管理は、ソフトウェアや技術インフラストラクチャなどの面から、セキュリティ規約を開発、実装、および管理し、それによって安全で安定した IT 環境を実現するためのプロセスです。CMDB に関係するセキュリティ規約とドキュメント ライブラリは、セキュリティ管理の連携と承認によって、初めて正式なものとなります。

ページのトップへ ページのトップへ

構成管理

構成管理では、構成アイテム (CI) の識別、記録、追跡管理、およびレポート作成を行います。収集や追跡の対象となる情報は、CI の種類によって異なります。頻繁に管理対象となる情報には、CI の説明、モデル/シリアル番号、バージョン番号、構成部品、他の CI との関係、所在地、所有者、ステータスなどがあります。CI 情報は、構成管理データベース (CMDB) と呼ばれる単一の論理データ レポジトリに格納します。このレポジトリは、たいていの場合、全社レベルで使用するサポート ツールを備えた 1 台以上のリレーショナル データベースです。小規模な組織の場合、スプレッドシートで十分実用に耐えるかもしれません。反対に、グローバルな組織では、CMDB を複数稼働させないと十分な管理は実現できません。

CMDB は、組織内で利用可能な IT 環境のコンポーネントに関する情報を集約した単一の情報源であり、この情報の一元化によってシステムの信頼性、可用性、制御性が拡大します。構成管理での CI の追跡管理にデータベースを使用すれば、承認済みのコンポーネントのみが IT 環境内で利用されていることを保証できます。また、インシデントや問題が発生した場合、情報源が一元化されているので、サービス デスク、インシデント管理、問題管理など、構成管理以外の組織グループでも、インシデントや問題の影響をすばやく正確に評価することができます。これは問題の早期解決、ダウンタイムの短縮に結びつき、最終的に IT 環境の可用性と信頼性が向上します。たとえば、ユーザーの質問にすばやく回答するには、使用されているハードウェアやソフトウェアの構成情報が必要となります。CMDB が整備されていれば、サービス デスクのスタッフは必要な情報をたちどころに取り出せます。

構成管理と最も密接なつながりを持つのが、変更管理です。構成管理からは、変更のリスクや影響に関する評価が提供されます。変更管理では、この情報を利用して変更の処理速度を早めることができます。これを逆の視点で言うと、CMDB に記録され、追跡管理されるのは、変更管理の制御下にある Cl だけです。変更管理の承認がない限り、CMDB の内容は変更できません。これによって構成情報の管理性が向上します。

変更要求の IT 環境での実施が承認されると、まず該当する構成アイテムが CMDB に入力されます。この時点から、CI への変更と CI のステータスは CMDB 内で追跡管理されます。つまり、CMDB には環境内で実施された変更の履歴と、現在の姿が保管されます。変更管理のセクションにも説明しましたが、いったん CMDB に記録された IT 環境内の CI の情報は、変更要求プロセスを経て、最終的に変更管理によって承認されない限り、変更することはできません。 環境の現在の "姿" を常に正確で完全な状態で知ることができるように、変更管理と構成管理の両プロセスには密接な連携を持たせます。

構成管理は、計画、識別、制御、ステータス アカウンティング、検証/監査という 5 種類のアクティビティで構成されています。計画アクティビティとは、構成管理の確立に関連した活動のことです。識別アクティビティは、CI の識別と記録に関する活動です。制御アクティビティは、IT 環境内で適切に CI が使用されていることを保証する活動です。ステータス アカウンティングは、CI レポートの作成に関する活動です。検証/監査アクティビティは、IT 環境内に存在する物理的な CI の情報と CMDB の内容の整合性を維持する活動です。

組織内で構成管理を成功に導く条件を以下に挙げます。

  • 役員の指示の下、構成管理アクティビティに対する組織全体のコミットメントとサポート

  • ポリシーや手順の作成など、構成プロセス実装に先立つ適切な計画

  • 構成管理スタッフやユーザーに対する適切なトレーニングの実施

  • CMDB 内の CI 情報の維持管理を担当する人員の確保

構成管理の利点

次に示すように、構成管理には数多くの利点があります。

  • IT 環境内の CI を識別、追跡管理、制御することで IT 資産の包括的な管理を効率よく実施できます。

  • CI の情報を詳細に正確に提供できるうえ、経時変化を踏まえた追跡管理が可能です。

  • CMDB リレーショナル データベース内に IT 環境内のコンポーネント情報を記録することで、CI 間の相互依存関係を文書化できます。

  • ソフトウェアのリリース サイクルを短縮し、アップグレードの頻度を増やすことで、IT 資産の監視や制御を容易にします。

  • 管理の行き届いたデータがほかのプロセスに提供されるため、それらのプロセスでは十分な情報に基づいた、速やかな決定がなされます。

  • IT 環境内で変更を計画する際、変更やリリースの管理プロセスで変更の影響 (ハードウェア要件やソフトウェアの競合) を判断しやすくなり、これらの管理作業が容易になります。

  • インシデント管理、問題管理、サービス デスクの各プロセスで、CMDB を調査ツールとして活用することにより、問題やインシデントの解決 (システムのダウンタイム削減など) が容易になります。

  • CI ステータスの追跡管理によって可用性管理アクティビティが容易になります。

  • IT 環境の現時点での詳細な構成情報を保持することで、変更の実装障害や天災が発生した場合、フェール オーバーや復旧の管理による環境の復元が容易になります。

  • CI の耐用年数、ソフトウェア ライセンスの更新日、保守契約などの監視によって、経理管理での IT 経理計画が容易になります。

  • 企業内でのソフトウェア製品の不正使用を防止します。

  • IT 環境内の CI が正確に CMDB に反映されていることを検証することで、組織内での備品の盗難を監視できます。

  • IT 環境全体のデータを論理的に関連付け、単一のレポジトリに格納したうえで提供します。

  • 各種コンポーネントを集中管理してソフトウェアやハードウェア構成の標準化を促すため、システムの保守とアップグレードが容易になります。

  • ダウンタイムの極少化、システムの標準化、 IT 環境の制御の強化によって、TCO を抑制できます。

役割と責任
ここでは、構成マネージャと構成管理スタッフの役割とその責任について概説します。構成マネージャはプロセス全体を管理し、構成管理スタッフは CMDB や関連タスクの日常的な運用を担当します。

これらは役割であって、具体的な業務の説明ではないので注意が必要です。小さな組織では、同じ人が複数のロールを兼務することもありますが、大きな組織では、役割ごとにチームを編成します。ただし、構成マネージャの役割は常に 1 人の従業員に割り当てることを推奨します。

構成管理に関する役割とその責任の要約を下表に示します。

表 1 構成管理に関する役割とその責任

役割

責任

チーム モデル クラスタ

構成マネージャ

構成マネージャは、CMDB 管理のプロセスと手順を定義します。
主な業務は次のとおりです。

  • 構成管理執行上守るべきポリシーと手順の策定
  • CMDB に記録する CI の範囲とレベルの決定
  • 監査の実施とベースラインの設定
  • 普及キャンペーンによる構成管理ポリシーの全社への徹底
  • 構成管理スタッフの選出とトレーニング
  • CI の名前付け規則など、CMDB ポリシーの策定
  • 可能な場合、CMDB 更新システムの自動化
  • 管理職への報告書の作成と配布
  • 変更所有者向けの、リリースの影響評価に関するベースライン報告書の提供
  • ターゲット環境をミラーリングするテスト環境の開発支援
  • リリース完了時、ターゲット環境への全変更を反映するための CMDB の更新

この役割は、MOF チーム モデルに定義されたリリース ロール クラスタの一部です。

構成管理スタッフ

スタッフ メンバは、IT 環境の特定の領域における管理業務を担当します。
主な業務は次のとおりです。

  • 最新の CI 情報とステータス情報による CMDB の更新
  • ドキュメント レポジトリ内のドキュメントに対するアクセスと配布の制御
  • CMDB の構造の変更
  • 管理職への報告書の準備
  • CMDB の監査と再構築
  • ベースラインの文書化
  • インシデントや問題の解決支援 (CMDB 利用によるサービス デスク、インシデント管理、問題管理の各プロセスの支援)
  • 構成アイテム用ストレージ (ドキュメント レポジトリ) の作成

この役割は、MOF チーム モデルに定義されたリリース ロール クラスタの一部です。

構成マネージャ
構成マネージャの職責は、CMDB 管理のプロセスと手順の定義にあります。構成マネージャは CAB (Change Advisory Board) のメンバであり、変更マネージャと協力して、要求された変更の影響を、その承認前に明らかにし、変更実施後は IT 環境に加えられた変更をすべて CMDB に記録します。構成マネージャの主な業務は上表に示したとおりです。

CAB の詳細については、変更管理に関する説明を参照してください。

構成管理スタッフ
構成管理スタッフの役割と責任は、構成マネージャによって定義されます。各スタッフに役割を割り当てる際、構成マネージャはスタッフに CI 情報の CMDB への記録を徹底させ、発生しうる情報の欠落を最小限に抑える必要があります。

構成管理スタッフの必要人数は、組織の規模、IT 環境での変更/リリースの頻度、CMDB の自動化の程度、および CMDB への CI の記録に求められるきめ細かさによって異なります。いずれにしても、構成プロセスがほかの関連プロセスの運用に支障を来さないよう、十分なスタッフを確保する必要があります。

事業所が地理的に離れて存在する場合は、各事業所にスタッフを置きます。小さな組織では、構成管理スタッフの役割はほかの役割と兼務してもかまいません。しかし、大きな組織でのスタッフの役割は、フルタイムの専任メンバを複数のグループに分割し、グループごとに特定の領域を分担することを意味します。この体制で構成管理を進めるとき、二重更新などのエラーを防止するため、CI の管理は必ず 1 人のスタッフに担当させます。

スタッフ メンバの担当業務は表 1 に記載したとおりです。

構成管理の主要ツールは、構成管理データベース (CMDB) です。構成内の IT コンポーネントに関する記録は、CI として CMDB 内で管理します。

構成管理アクティビティ
前述のように、構成管理には計画、識別、制御、ステータス アカウンティング、検証/監査という 5 つの基本アクティビティがあります。構成管理は、これらのアクティビティをフレームワークとして構築/管理します。

  • 構成管理の計画 構成管理のスコープ、目的、ポリシー、手順、組織内でのコンテキスト、技術的なコンテキストを策定します。

  • 構成の識別 インフラストラクチャ内で管理対象とする CI を選定し、その所有者、相関関係、仕様などによって各 CI を階層化します。 ここでは、各 CI に識別子とバージョンも割り当てます。

  • 構成の制御 承認済みの識別子を持つ CI だけを、その作成から廃棄に至るライフ サイクルで管理し、データベースに記録します。CI の追加、変更、置換、削除に際しては、正式な変更制御ドキュメント (承認済みの変更要求など) または最新の仕様書による承認が必要です。

  • 構成ステータス アカウンティング 各 CI の最新のデータおよび過去の変更履歴を、CI のライフ サイクル全体にわたってレポート化します。これによって、CI 情報を開発中、テスト中、使用中、廃棄済みの 4 つのステータスで追跡管理します。

  • 構成の検証 / 監査 CI の物理的な有無と CMDB 内におけるデータの整合性、IT 環境における承認済み CI のみの使用に関して一連のレビューと監査を行います。

構成管理計画アクティビティ
構成管理計画アクティビティとは、構成管理のスコープと目的、ポリシー、手順、組織内でのコンテキスト、技術的なコンテキストを策定する作業です。構成管理計画の典型的なカテゴリ例を下表に示します。その後、各カテゴリについて詳しく説明します。

表 2 構成管理計画の内容

カテゴリ

説明

スコープと目的

構成管理のスコープ (管轄)、短期目標と長期目標、業務上の最終目的を定義し、プロセス構築/実施の指標とします。

ポリシーと手順

構成管理の各アクティビティを実施するうえで守るべきポリシーと手順を定義します。

定常的なアクティビティの計画

管理職への報告書の準備や監査の実施など、定常的なアクティビティのスケジュールを決定します。

ストレージ レポジトリとセキュリティ

ストレージ レポジトリ (CMDB、DSL、ドキュメント レポジトリなど) とそのセキュリティ要件に関する情報を提供します。

トレーニング

構成管理スタッフ、他の IT 担当者、およびユーザーを対象に行われるトレーニングの概要を作成します。

管理職への報告書

管理職に提出する報告書の種類と内容、作成頻度を定義します。

構成管理の最善策
ITIL による構成管理の定義に初めて接した場合、運用スタッフは、通常、肯定的な反応を示します。コンセプトに刺激を受け、プロセスの早急な導入に前向きとなります。しかし、実際に環境の分析に着手し、厳密な制御下で CI に代表される膨大な事象の追跡管理が必要なことがわかってくると、最初の熱意は急速に萎えていきます。そうなると、プロセスが複雑すぎると言って、プロジェクト自体が延期されかねません。すべての CI を個別に記録し、一から追跡しなければならないと見なすなら、それも必然的な結果と言えるでしょう。このような無謀な管理方法は失敗に帰着します。しかし、経験豊富な IT スタッフであれば、落とし穴の存在を知っているので、障害を未然に回避することができます。

これまで、データ センター環境は重厚長大で、複数の所在地にまたがる結果、総体として錯綜した体制に陥りがちでした。なんと言っても、使用する CI の数が多すぎ、記録、追跡、制御はすべて至難の技です。ただ、限定された小さな環境から始める創立間もない企業の場合は事情が異なるかもしれません。

そこで重要なのは適切な構成管理計画です。計画が適切であれば、初めてのプロセスの実装作業はスタッフのトラウマとならず、価値ある経験になります。いったんプロセスが導入されれば、改良を重ね、徐々に堅牢で有益なプロセスに拡張していくための基盤となります。

以下に、構成管理の計画に際して重要なコンセプトと最善の方法をいくつか示します。

ターゲット環境を明確に定義する
IT 環境の 2 つの柱は、開発環境と稼動環境です。運用チームは当初、両方の環境に共通の構成管理と CMDB を導入したいと考えるでしょう。一見正しい目標に見えますが、構成管理の方法を学び始めたばかりの IT 組織にとっては危険な考え方です。2 つの環境は非常に性格が異なるからです。どちらも独自のニーズを抱えています。たとえば、ソフトウェアの開発が最も端的な例です。開発環境という名前が示すとおり、開発作業はすべて開発環境で完結し、稼動環境とは無関係です。

開発中のソフトウェアには用途の異なる多くのモジュールやパッチがあり、すべて記録、追跡管理、制御の対象となります。大部分の IT 組織では、多数の開発者がさまざまなプログラムの開発に携わります。開発ツールは市販のものが多数販売されています。実績豊富な組織であれば、使い慣れたツールが存在するはずです。このような既存の開発プロセス上に、ITIL ベースの構成管理を導入すれば、ただでさえ複雑なアクティビティが余計に入り組んでしまいます。

以上を考慮すると、運用チームは計画初期の段階で、構成管理の導入範囲を稼動環境に限定し、ソフトウェア開発環境では独自の管理プロセスを採用する必要があります。

この決定は、ソフトウェア開発を完全に無視するという意味ではありません。開発を無視した稼動環境は存在しないからです。導入先を稼動環境に限定したら、構成管理の責任者 (構成マネージャ) は、開発側と協議して、CMDB で CI として 管理するソフトウェアとその管理方法を決定します。たとえば、個々のソフトウェア モジュールは CMDB で追跡管理するのではなく、相互に関連するモジュールを "リリース" として括り、リリース番号やタイトルで一括管理します。これにより、ソフトウェアという重要な追跡管理対象要素の構成管理を簡略化できます。また、開発側が構成マネージャの関与を邪魔に思うことによる社内的な政治紛争を回避できます。

構成管理の目的は、社内に亀裂を作ることなく開発と営業の協力関係を強化することです。したがって、構成管理の計画アクティビティを大きく発展させるための最善策とは、構成管理の対象となるターゲット環境を的確に定義し、その情報を関連部署にくまなく伝達することです。

サービス ベースで CMDB を実装する
稼動環境が大規模な場合、はじめからすべての情報をカバーする CI を管理するのではなく、まずは与えられたリソース内で実現可能な範囲を CMDB 化するのが理想です。

こうすれば、IT 部門が既にサービス管理の実装を決定している場合、つまりサービス レベル管理 (SLM) プロセスの導入が計画/実現されている場合の構成管理の実装が容易になります。SLM プロセスの要はサービス レベル契約 (SLA) です。SLA には、契約対象のサービスごとに、そのサービスを構成するサービス コンポーネントを規定する必要があります。これによって、組織の IT 部門と顧客の双方が、個々のサービスで提供される内容をよく理解できます。また、SLA はサービスにかかるコストや価格を算定するうえでも不可欠です。

運用チームでは、SLA 情報を基に、各サービスに対して CI リスト (サービス コンポーネント) を作成します。そして、CI リストを前提に、サービス ベースで構成管理を実装する意思決定が可能となります。

たとえば、SLA に規定されたサービスに "SAP 会計" サービスがあり、関連する CI の管理責任が運用チームにある場合、このサービスを構成するコンポーネントはすべて出揃っています。これらのコンポーネントには、専用のファイル サーバーやデータベース サーバー、各種ネットワーク コンポーネント、SAP アプリケーション モジュール、クライアント PC などが含まれます。SAP 会計は基幹業務サービスであり、SAP 環境は明確に定義されていることが多いことを考えると、初めて構成管理の導入を試みるときにはこれを手始めにするとよいかもしれません。運用チームばかりではなく、顧客の側でも、即座に構成管理の価値を実感できるからです。

実感できる価値とは次のように言い換えられます。顧客側のメリットは、関連プロセスの質的改善です。顧客が自在に SAP CI データを利用できれば、サービス デスク、インシデント管理、問題管理、変更管理などのプロセスの利用価値が大幅に増すからです。運用チームにも、スタッフが運用経験を積むことができるというメリットがあります。有限で明確な定義を持つ CI セットで構成管理の練習を重ねることは、担当者にとって価値ある経験です。さらに、顧客にとって重要な基幹業務サービスに注力することは、顧客満足度の向上にもつながります。

このように、まず単一の基幹業務サービスを対象とした構成管理を成功させれば、この重要性の高い IT プロセスを自信をもってほかのサービスにも拡大し、CMDB を拡充していくことができます。

メモ サービス ベースの導入アプローチは、IT 部門で SLM を実装していない場合でも利用できますが、サービス コンポーネントの規定作業にはそれだけ労力がかかります。

ドメイン ベースで CMDB を実装する
もう 1 つの実際的な構成管理アプローチは、稼動環境をドメインとサブドメインに分割し、ドメイン単位で CMDB を構築していく方法です。

ドメインは、IT 部門やその環境に応じた基準をベースに自由に定義できます。たとえば、ネットワーク全体、1 つのネットワークのセグメント、コンピュータ システムのクラスなどを基準として、CI をグループ化することができます。

また、所在地を基準にドメインを定義し、所在地単位で CMDB を構築する方法もあります。大学であれば、構内の建物ごとにドメインを定義したり、大企業であれば、事業所や営業所ごとにドメインを構成したりできます。

ここで非常に重要なポイントは、運用チームが環境内において、自分の組織にふさわしい基準を選び、明確にドメインを定義することです。また、コストや労力に合った見返りが得られるように配慮しなければなりません。入念な分析を基に実効性の高いドメインを選択すれば、スムーズに構成管理の実装に進むことができます。

CI の詳細さを適切に設定する
CMDB で管理する CI の仕様を決めるときは、慎重な検討が必要です。たとえば、Windows 2000 ファイル サーバーを親の CI として定義した場合、子 CI には追跡管理が必要なコンポーネントだけを定義する必要があります。この場合、ハードウェア カードやソフトウェア モジュールをすべて管理するのか、また中枢部品を逐一個別に管理するのか、といった決定が重要です。

計画当初は、すべての CI を追跡管理しなければならないと考えるかもしれません。それも一理ありますが、CMDB における管理労力を考えてみれば、実現可能な詳細さには限界があります。小さな組織の稼動環境なら、すべてのコンポーネントを CI 化しても問題にはなりません。しかし、何百台ものサーバーを抱える大規模な環境では、管理に膨大な手間がかかり、想像するだけでも悪夢と言えます。

構成管理の価値は、ひとえに CMDB で管理するデータの質と精度で決まります。管理する CI を詳細に設定しすぎて運用チームの手に余るようでは、データの整合性が犠牲になる可能性が大きくなります。CMDB の信頼性が薄れれば、関係するプロセス (サービス デスク、変更管理、インシデント管理など) に与える影響も深刻です。

ツールでプロセスを自動化する
複数の機能にまたがるプロセス (変更管理など) のなかには、プロセスの実装に使用するツールやテクノロジを考慮せずに設計できるものもあります。その場合、設計終了時点で解析を行えば、プロセスのなかでツールによって自動化できる部分を即座に決定できます。この意味で、プロセスがツールを支配します。つまり、プロセス固有のニーズに基づいて設計を行い、その後、ツールを選択します。

単機能のプロセスの場合は、アプローチが変わります。反対にツールがプロセスを支配することになります。構成管理とはそのようなプロセスです。この場合、プロセスに利用可能なツールが複雑な設計に対応しきれないのであれば、時間をかけて非常に細かなプロセスを設計してもあまり意味はありません。

構成管理の計画段階では、市販の ITIL 対応構成管理ツールについて知っておく必要があります。ツールの中には、必要機能が完備されてすぐに使える状態のものもあれば、相当量の開発が必要なものもあります。どちらにも存在理由があり、それぞれ異なる要件に対応しています。追加の開発を行うかどうかを決めるのは運用チームです。アプローチを決定したら、ITIL 構成管理に詳しいスタッフが、各製品の特徴を比較します。

ツールの機能や特徴を知ることで、環境に適した構成管理と、そこで使用するツールの両方を視野に入れた設計作業に入ることができます。また、ツールの能力を超えた機能を盛り込むような無駄な労力を省けるので、プロセスの設計が大幅に単純化します。

まとめ
構成管理は真の価値を生む、非常に重要度の高いシステム運用プロセスです。このため運用チームには、プロセスの設計/実装を慎重に行うことが求められます。これ以降の記述内容は、常に上述のコンセプトや最善の方法を念頭に置きながら読み進んでください。

スコープと目的の定義
構成管理計画の策定における最初のステップは、構成管理のスコープと直接的な目的を定義し、最終的に目指すビジネス目標を決定することです。目標としては、短期的目標と長期的目標の両方を掲げるべきです。スコープと目的を明確に理解すれば、構成管理スタッフはそれをガイドラインとして、各自の担当業務を遂行していくことができるからです。

構成管理は、あらゆる IT インフラストラクチャ システム/機器に適用できます。その役割は、IT 環境を構成するすべてのコンポーネントを識別/制御/追跡管理することです。これらを遂行するには、構成管理とほかの各種プロセスを連携させる必要があります。この点の詳細については、「ほかのプロセスとの関係」を参照してください。

組織で構成管理の効果を十分に活用するための要件は以下の通りです。

  • IT 環境内のすべての CI を特定し、それぞれに識別子を付ける。

  • システムのライフ サイクルを通じて CI への変更をすべて制御し、追跡管理する。

  • IT 環境での変更はすべて文書化し、変更管理とリリース管理の両プロセスと矛盾を来さないようにする。

  • ベースラインとなる構成を規定し、維持する。

  • サービス デスク、変更管理、インシデント管理、リリース管理などのプロセスから要請があった場合、正確な CI とその関連ドキュメント情報を提供する。

  • インシデントや問題が発生した場合は該当する CI を特定し、サービス デスク、インシデント管理、問題管理の各プロセスを支援する。

  • 組織の現有資産を把握することで、資産の管理を行う。

  • 使用許可のあるソフトウェアのコピーのみが IT 環境内で利用されるように、ソフトウェア ライセンスを管理する。

  • 監査を行い、IT 環境の実際の状況と CMDB の登録内容の一致を確認する。

  • 変更要求に基づく変更処理プロセスと承認済み CI のみを使用する重要性について、組織内の各グループをトレーニングする。

  • 管理職に報告書を提出する。

ポリシーと手順
構成管理の成否は、プロセスのアクティビティを規定するポリシーと手順の質に依存します。必要な手順としては、CMDB 更新などの構成管理アクティビティ、CMDB の監査や再構築、管理職への報告書の作成などを挙げることができます。構成管理を構成するアクティビティは明確に定義し、文書化する必要があります。文書化したポリシーや手順は、必要な管理職や構成管理スタッフに配布してください。

さらに、構成管理、変更管理、リリース管理の間の関係とインタラクションを定義したポリシーと手順も定義します。プロセス間の通信が正しく行われないと、構成管理の目的が果たされません。また、これらのプロセスが関わる変更は、すべて承認したうえで、正しく速やかに CMDB に記録する必要があります。プロセス相互の関係性を適切に規定し、構成管理のアクティビティを成功させるには、適切な計画が必要です。ポリシーには、プロセス相互の連携に関するガイドラインを規定してください。

定常的なアクティビティの計画
定常的なアクティビティには、管理職への報告書の作成と監査の実施があります。ここでは、これらのアクティビティの実施時期、スタッフへのタスクの割り当てについて概説します。スケジュールの作成とスタッフへのタスクの割り当ては構成マネージャが担当します。

ストレージ レポジトリとセキュリティ
構成管理のデータ管理は、物理的および電子的レポジトリ (CMDB、ドキュメント レポジトリ、リリース管理の主管轄である最終ソフトウェア ライブラリなど) を使用して行います。レポジトリに関しては次の情報を管理する必要があります。

  • レポジトリ メディアの説明

  • 場所

  • 内容

  • アクセス権と更新権

  • 最低限必要なエントリ

  • 廃棄の条件

レポジトリは安全な場所に設置してください。火災や従業員の不正行為に備えて社外に設置する場合もあります。セキュリティ対策は、セキュリティ管理担当と協議のうえで決めます。特に、CMDB やほかのストレージ レポジトリへのアクセス権やデータ更新権の設定が重要です。

トレーニング
構成管理のデータ管理は、物理的および電子的レポジトリ (CMDB、ドキュメント レポジトリ、リリース管理の主管轄である最終ソフトウェア ライブラリなど) を使用して行います。レポジトリに関しては次の情報を管理する必要があります。トレーニングは、構成管理計画で重要な位置を占めますので、トレーニング担当者や変更管理担当者と協議のうえで計画してください。特に、変更管理に変更要求を提出する手順については、組織の全員にトレーニングを実施します。最新で正確な情報による CMDB の更新の重要性も強調します。また、承認済みのソフトウェアのみの使用を義務付け、未承認のソフトウェアの使用については、詳細な規定を設けて規律化します。

構成管理スタッフにも適切なトレーニングを行う必要があります。構成管理の流れ、CMDB と関連ドキュメント ライブラリの更新手順について、各スタッフに十分な理解を求めてください。正しいトレーニングを受けていないスタッフがいると変更処理の妨げとなります。これは、IT 環境での変更が頻繁な組織では、特に問題となります。また、スタッフがベースライン報告書などの必要書類を準備できないと、変更管理やリリース管理で、構成管理の導入に備え、その影響を正しく評価することができなくなります。また、トレーニングが不十分なスタッフは、サービス デスク、インシデント管理、問題管理の各プロセスにも悪影響を及ぼします。たとえば、CMDB が最新のデータに更新されていない場合、インシデントや問題の調査または修正に支障を来します。

トレーニングを計画する際、構成マネージャはトレーニング担当者と協議を重ね、トレーニングの実施形態、コース編成、予定、必要リソースなどを決定します。以下、これらについて概説します。まずトレーニングの実施形態ですが、社内研修、インストラクタによる講義、演習、操作手順ガイダンスなどを組み合わせます。次に、クラスの大きさ、グループ別の編成 (ユーザー クラス、構成管理スタッフ クラス) などのコース編成を決めます。さらにトレーニングの実施予定を関係部署に配布します。そして最後に、インストラクタ、コンピュータ機器、教室、教材などの必要リソースを定義し、調達します。

管理職への報告書
ここでは、構成管理に必要な報告書の種類とその内容について概説します。報告書は、経営陣、管理職が構成管理の評価に使用する資料です。報告書は、構成管理以外のグループが IT の変更やインシデントまたは問題の解決に役立てる場合もあります。次の報告書が揃っていると便利です。

  • ベースライン報告書

  • 監査報告書

  • CI ステータス報告書

  • ソフトウェア ライセンス ステータス報告書

  • CMDB/ドキュメント ライブラリ問題報告書

  • CMDB 変更率に関する報告書

ベースライン報告書と監査報告書は、リリース管理と変更管理の各グループで IT 環境への変更計画を立てる際に役立つ資料です。前述のように、これらのドキュメントによって、全部署における運用業務の開始ポイントと、変更を実施した場合の影響を評価するポイントが明確になります。変更率に関する報告書は、経営陣が組織内での変更量に関する現況と見通しを立てる際に有用です。変更過多の場合、変更管理で問題が生じやすくなります。これらの報告書は組織の実状、特にインシデントや問題の傾向を評価するためにも有用です。

構成の識別
構成識別アクティビティでは、次の図に示すように、IT コンポーネントの選定、識別、ラベル付けなどを行います。

cfgmgt03

図 3: 構成識別タスク

構成アイテムの識別
構成アイテム (CI) とは、そのライフ サイクル全体を通じて識別、追跡管理、制御される IT コンポーネントのことです。追跡管理の対象となる CI には、次のコンポーネントがあります。

  • ハードウェア

  • ソフトウェア

  • テレフォニー装置

  • ネットワーク コンポーネント

  • 環境

  • 文書、マニュアル類

  • 変更要求

  • ベースライン報告書と監査報告書

  • サービス レベル契約 (SLA)

  • データベース

  • ベンダ情報

  • インシデントおよび問題の記録

  • ドキュメントライブラリおよびソフトウェア ライブラリ

  • 手順とポリシー

社員情報も CI として追跡管理する場合があります。たとえば、組織内の任意のワークステーションの使用許可を得ている社員がいれば、その人の情報を CI として管理します。この場合、あるユーザーが ID とパスワードを入力してシステムにログオンを試みると、CI 属性から、その人に許可されているオペレーティング システム、アプリケーション、アクセス権がシステムに通知され、ログオン制御が行われます。ここからは代表的な CI と、ほかの CI の関係について説明します。

ハードウェア CI
ハードウェア CI は、管理属性によってハードウェア コンポーネントを識別する情報です。たとえば、サーバーをハードウェア CI として管理するとします。その場合、サーバー ID、購入日、バージョン、BIOS、モデル、ファームウェア、シリアル番号などを CI 管理属性となります。また、サーバーに内蔵ハード ディスクがある場合、このハード ディスクを別のハードウェア CI として管理する際には、サーバー CI の子 CI として管理します。ハード ドライブ CI の属性としては、ハードウエア コンポーネント ID、親ハードウェア ID、コンポーネントの種類、インストール日、バージョン、シリアル番号などが考えられます。

cfgmgt04

図 4: ハードウェア CI の例

cfgmgt05

図 5: ソフトウェア CI の例

ソフトウェア CI
ソフトウェア CI では、インベントリ (ファイルとバージョンの一覧)、ビルド スクリプト、インストール スクリプト、設定情報 (.ini ファイル、レジストリ値、各種設定ファイル) などを管理します。ソフトウェア CI の例としては、Microsoft の IIS (インターネット インフォメーション サービス) のビルドに追加した修正プログラムがあります。CI 管理属性としては、このほかに、ソフトウェア CI の ID、ソフトウェアの種類、アプリケーション名、インストール日、バージョン、サービス パック、修正プログラムなどがあります。

ネットワーク CI
ネットワーク CI は、ネットワーク デバイス (ルーターなど) からケーブルの配線にまでのすべてのネットワーク情報を管理します。ネットワーク CI の例としては、ルーターの情報があります。この場合、管理属性には、ハードウェア仕様、インターフェイス カードなどの筐体に含まれる部品のインベントリなどが考えられます。また、ビルド スクリプトや設定スクリプトも属性として管理されます。

ユーザー CI
ユーザー CI は、ユーザーの識別に必要な情報や、そのユーザーに与えられている権限などで構成されます。ユーザー CI の例としては、IIS サーバー クラスタ管理者があります。管理属性としては、ユーザー名、役割、連絡先情報、不在時の代理要員名などが考えられます。

CI のスコープと詳細さの設定
構成管理において IT 環境の構成コンポーネントの選定と識別を行うには、構成管理プロセスで管理する CI のスコープと詳細さを決定する必要があります。IT 環境にインストール、置換、配置替え、またはアーカイブ可能な CI は、すべて個別の CI として追跡管理します。スコープに関して、構成管理が IT 環境のどのコンポーネントを記録し、追跡管理する責任があるのかを、組織的に決定する必要があります。たとえば、外部に管理を委託するコンポーネントは CMDB で管理しないので CI 化しません。データ ウェアハウスの管理をサードパーティのプロバイダに委託する場合、このウェアハウスのコンポーネントは管理しなくてかまいませんが、このプロバイダの連絡先情報は CI として管理すべきです。

cfgmgt06

図 6: CI の詳細さの決定

スコープ以外に、コンポーネントの置換や更新に関して CI の詳細さを規定します。これはポリシーに基づいて決めるのが最も効果的です。CI は管理するレベル数を制限しないと、CMDB で管理不能に陥ります。たとえば、上図の "System 1" がコンピュータだとすれば、そのサブレベルとしてハードディスク、Ethernet カードなどのコンポーネントを管理します。各ボックスが 1 つのコンポーネントに対応し、個別の CI として管理できます。管理対象を詳細にすれば、それだけ構成管理の規模が増大し、コストがかかります。たとえば、日常的にデスクトップ システム全体の入れ替えがある組織の場合、デスクトップのみを CI として管理すれば十分です。しかし、システムのコンポーネント レベルで定期的なアップグレードを実施している組織なら、そのコンポーネントのレベルまで CI として管理すべきです。CI の詳細さは半期または年度ごとに見直し、CMDB の内容を IT 環境と業務全般のニーズに符合させます。

メモ CMDB に記録する CI のレベルは、変更が実施されるレベルと一致させることが大原則です。

CI の標準的名前付け規則の定義
個々の CI は、一意の名前、モデル番号、シリアル番号、バージョン番号などによって一意に識別される必要があります。バージョン番号を含めるのは、同一の CI に複数のバージョンが IT 環境内に存在する可能性があり、バージョン番号がないと完全には一意にならないからです。構成識別アクティビティの一環として、標準的な名前付け規則を定義し、IT 環境内で追跡管理する CI のすべてに適用します。CI カテゴリを明示するために、接頭語を ID の一部として使用すると便利です。CI カテゴリの例を次の表に示します。

表 3 CI カテゴリの例

ハードウェア

ソフトウェア

文書類

lp ラップトップ

os オペレーティング システム

ag 管理者ガイド

ce 通信機器

as アプリケーション ソフトウェア

rm リファレンス マニュアル

pc パーソナル コンピュータ

ac アプリケーション コード

um ユーザー マニュアル

ws Web サーバー

vs ベンダー ソフトウェア

sl ソフトウェア ライセンス

sq SQL Server

av アンチウイルス ソフトウェア

pr 問題

pr プリンタ

ic インシデント

sc スキャナ

pd 手順

hb ハブ

pt ポート

rt ルーター

たとえば、複数のデータ センターにまたがる e コマース サイトの場合、ハードウェア CI には、次のような名前付けを行います。

DDAATTNN

各部には次の値が入ります。DD = データ センター ID

AA = アプリケーション ID

TT = サーバー タイプ ID (Web サーバーの場合 ws)

NN = 一意の識別子 (01、02、03、…)

CI 属性の決定
属性とは、CMDB に記録する個々の CI が持つ特性です。CI の種類が違えば、管理する属性も異なります。構成識別アクティビティの一環として、構成マネージャは組織にとって重要な、管理すべき属性を決定する必要があります。ソフトウェア CI やハードウェア CI は、次のような類似した属性によって管理されます。

  • 一意の ID と CI 名

  • バージョン

  • 説明

  • 製造元と、シリアル番号またはモデル番号

  • 購入日

  • インストール日

  • 購入価格

  • 設置場所

  • ステータス

  • 構成 (CPU、サーバーなど)

  • 担当グループ (または所有者)

  • 関連リリース - インストール日、変更要求番号

  • 関連するインシデントおよび問題報告書

  • 他の CI との関係

さらに多くの属性を持たせた方が、CMDB の有用性が増すように思われるかもしれません。しかし、管理する情報が増えれば増えるほど、CMDB の維持コストも増えます。したがって、構成マネージャは、あくまでも業務要求と関係グループへの便宜性を念頭に置いて、管理する属性を決定してください。たとえば、CI の所有者を管理していれば、インシデント管理および問題管理の担当者が、その所有者に問い合わせを行うことができます。変更管理と可用性管理のマネージャなら、同じ情報を参照し、これから行う変更やメンテナンス作業に関して所有者に通知することができます。また、管理対象コンポーネントのリリース、ステータス、インシデントおよび問題報告書を記録しておけば、CI のライフ サイクル全体を通じた履歴を管理することができます。

バリアントの定義
バリアントとは、バージョンが異なるだけなど、お互いによく似通った CI のことです。同じ CI に複数のバージョンがある場合は、バージョンごとに異なる CI として管理することも、バージョン番号属性のみが異なる同一の CI (バリアント) として管理することもできます。バリアントは、頻繁にアップグレードされるコンポーネントを同一の CI で管理したいときなどに便利です。異なる CI を作成する方がバリアントを使用するより簡単ですが、バリアントは、特定のコンポーネントにおいてバージョンの更新が必要な場合、または特定のバージョンがシステム障害を引き起こす場合などに効果を発揮します。たとえば、バリアントを持つ CI をアップグレードすると、それに伴いすべてのバリアントが即座にアップグレードされます。また、ある CI に問題が発生した場合、そのバリアントをすべて修正することで、問題が繰り返し発生するのを防ぐことができます。バリアントを使用すると、記録および追跡管理対象の CI 数が減り、CMDB の維持コストが低減する効果があります。

CI 間の関係の定義
構成識別アクティビティには、CI の相互関係を記録することも含まれます。CI 間の関係を記録することは、前提とされている相互依存関係の理解に役立ちます。関係は CI の属性の 1 つとして管理できます。CI 間には次のような関係が考えられます。

  • 使用 (ある CI が別の CI を使用していることを表す。たとえば、ソフトウェア アプリケーションがサーバ上で稼動。)

  • 接続 (CI どうしが接続されていることを表す。たとえば、パーソナル コンピュータとプリンタが接続されている状態。)

  • 構成要素 (ある CI が別の CI の構成要素であることを表す。たとえば、モニタはコンピュータ システムの構成要素。)

前述のように、CMDB は関係情報を管理できる点で、スプレッドシートとは異なります。関係情報の管理は、環境内で CI どうしが依存関係にあることを意味します。このことから、CMDB は適切に管理すれば強力なツールとなることがわかります。また、CI 相互の関係を文書化しておけば、特定の CI にインシデントや問題が発生したとき、またはその CI が変更されたとき、ほかにどのような影響を与えるかを把握できます。この点でも、適切に管理された CMDB 関係情報は有用です。組織内の各グループで関係情報を活用すれば、影響評価や問題解決をはじめとして、さまざまな作業が容易になるからです。たとえば問題管理では、関係情報によって、問題の根本原因を突き止め、ほかの CI が受けている影響を把握できます。変更管理でも同様に、IT 環境へのリリースの導入によって影響を受ける CI を判断できます。

CI 関係情報を定義する際は、ソフトウェア ライセンスを供与されているサーバー、デスクトップ、ラップトップなどを把握するために、必ずソフトウェア CI とハードウェア CI を関係付けます。これによって構成管理において、使用中のソフトウェア ライセンス数が契約内容と一致していることが確認できます。また、IT 環境内で使用許可のあるソフトウェアのみが使用されていることも簡単に確認できます。たとえば、10 台の PC で構成されるクラスタに、特定のアプリケーションの使用許可が与えられているとします。 この場合、次の例のように 13 個の CI を定義します。

  • 各 PC 用の CI を 10 個

  • クラスタ用の CI を 1 個

  • ライセンス用の CI を 1 個

  • アプリケーション用の CI を 1 個

PC はクラスタに関係付け、クラスタはライセンスに関係付けます。また、ライセンスはアプリケーションにも関係づけます。その結果、このアプリケーションを実行可能な PC が特定され、使用許可のあることも保証されます。

CI には変更要求やインシデントおよび問題報告書も関係情報として持たせることが重要です。変更要求情報が記録されていれば、変更に関係するコンポーネントを検索し、追跡管理することができます。その結果、変更中または変更後に問題が発生した場合の解決が容易になります。サービス デスクなどのグループでは、インシデントおよび問題報告書から CI を見つけ、即座に問い合わせてきたユーザーに問題の内容や詳細 (たとえば、影響を受けている他の CI は何かなど) を提供できます。この情報は、インシデント管理および問題管理による現状分析、問題の根本原因の究明、早期解決などを容易にします。次に CMDB スキーマの例を示します。

cfgmgt07

図 7: CMDB スキーマの例

これはあくまでもサンプルです。実際の組織が CMDB で追跡管理する情報がすべて含まれているとは限りません。たとえば、サンプルのスキーマにはインシデントと問題の記録、SLA、手順などが含まれていません。このスキーマは、リレーショナル データベースで管理できる基本関係情報と依存関係情報を例示することで、CMDB のパワーの一端を表しているだけです。

上図のスキーマ例に含まれているテーブルについて、次に簡単に説明します。

  • tblSystem Components このテーブルは、システム (この場合は Web サーバー） の組織内での機能を説明したものです。システムが使用するハードウェアおよびソフトウェア コンポーネントのリストも含まれています。

  • tblHardware Components このテーブルは各ハードウェア コンポーネントの詳細情報です。

  • tblSoftware Components このテーブルは各ソフトウェア コンポーネントの詳細情報です。

  • tblDocument Components このテーブルは関連するドキュメント コンポーネントの詳細情報です。

  • tblDriver Components このテーブルはハードウェア ドライバの詳細情報です。

  • tblVendor Information このテーブルは関連するベンダについての情報です。

  • tblRequest For Change このテーブルはすべての関連変更要求についての詳細情報です。

  • tblEmployee Information このテーブルは社員のオンサイト情報です。

  • tblEmployee Role Information このテーブルは社員の役割についての情報です。

CI のラベル付け
構成識別アクティビティの一環として、IT 環境のすべての CI は、すべて物理的な手段 (たとえば、バーコード) でマーキングし、構成の識別と検証および監査を容易にします。最終ソフトウェア ライブラリ内にあるソフトウェアのマスタ コピーには、ソース コードの先頭に CI 名とバージョン番号を記入します。CI に関するドキュメントの識別情報も正確に記録します。前述のとおり、各 CI には固有の ID を割り当てます。ソフトウェア、ハードウェア、ルータなどのカテゴリで CI の種類を分ければ、簡単にコンポーネントを識別できます。

ベースラインの文書化
構成識別アクティビティの一環として、構成管理スタッフは IT 環境のベースラインを定義します。ここではベースラインを文書化します。ベースラインとは、特定の時点における静止した状態の IT 環境を表す情報で、これによって基準となる環境の構造と、構造を規定するコンポーネント間の依存関係を定義します。特定の時点における IT 環境の見取図とも考えられます。ベースラインは通常、IT 環境の標準を定めるもので、これを基準としてその後の環境を設計および制御します。

ベースライン報告書は、変更の影響を受ける CI や、変更のサポートに必要なアップグレードの特定 (たとえば影響評価） にも使用します。変更要求の妥当性を判断する際、CAB (変更諮問委員会) では、IT 環境への影響がわからないと、申請を許可できません。そのため、構成管理から CAB にベースライン報告書を提出します。この報告書では、基準となる環境の構造について詳述し、CAB はこれに基づいて変更による環境への影響を評価し、決定を下します。

また、導入された変更が問題を発生させた場合、ベースラインによって復帰すべきポイントがわかります。変更の実装によってベースラインに加えられた変更は、すべて CMDB に記録されます。この作業には、新しい CI の登録、既存 CI のアーカイブ化、配置替え、アップグレードなどが含まれます。

構成の制御
構成制御アクティビティでは、CMDB において、適切な手順とポリシーに従って CI の追加、変更、削除、および閲覧が行われていることを確認します。これは IT 環境における変更の制御とは違います。IT 環境における変更の制御は、変更管理アクティビティの管轄です。この詳細については、『MOF 運用ガイド』の「変更管理運用ガイド」を参照してください。構成制御アクティビティでは次の作業を行います。

  • CMDB への新規 CI の追加

  • CMDB の CI ステータス更新

  • IT 環境から削除された CI のアーカイブ保存と、それに応じた CMDB の更新

  • ソフトウェア ライセンスの管理

  • CMDB、ソフトウェアおよびドキュメント ライブラリのセキュリティ確保

  • CMDB データのバックアップ

CMDB への新規 CI の追加
構成を効率的に制御するには、変更管理と構成管理を緊密に連携させる必要があります。変更管理は、IT 環境全体での変更を制御する役割があるため、構成管理と連携して、変更による影響を評価します。また、両者の連携は、正式に許可された変更のみが実装され、正しく CMDB に記録されていること、その結果 CMDB 内の CI が正しく制御されていることも確認しています。

下図は、CMDB における新規 CI の追加手順を表しています。

cfgmgt08

図 8: CMDB における新 規 CI 情報の追加

変更管理が変更要求を受け付けると、IT 環境に関するベースライン報告書を参照して、環境への影響が評価されます。変更要求が承認されれば、変更管理から構成管理スタッフに対して新規 CI を記述したフォームが提出されます。構成管理スタッフはこの情報を CMDB に登録します。次ページの新規 CI フォームのサンプルに、提出が義務付けられている情報を示します。構成管理スタッフには、インシデント管理および問題管理から CMDB に反映すべきインシデントおよび問題を記述したフォームが提出されます (インシデントも問題も、1 件ずつ固有の CI として追跡管理されます)。フォームに記載する情報には、インシデントおよび問題の説明、影響を受けるユーザー数と CI などがあります。インシデントおよび問題フォームのサンプルも後続のページに示します。

多くの組織で構成管理プロセスの導入が困難を極めるのは、管理しようとする CI の種類が多すぎるためです。導入は段階的に進め、その都度ミスから学びながら、変更管理プロセスの制御下にある全 CI の CMDB 登録を目指してください。段階的アプローチを採用すれば、IT 部門ではプロセス導入に必要以上のプレッシャーを感じなくて済みます。

新規 CI 情報フォーム

cfgmgt22

図 9: 新規 CI 情報フォームのサンプル

インシデントおよび問題フォーム

cfgmgt25

図 10: インシデント / 問題フォームのサンプル

既存 CI のステータス更新

cfgmgt11

図 11: CMDB における CI 情報の更新

CI ステータスの変更は、CMDB に記録してデータベース情報の精度を確保します。組織内では多数のグループが CMDB 情報を利用してアクティビティの効率化を進めています。そのため、誤ったステータス情報は深刻な問題につながる恐れがあります。たとえば、変更管理グループがベースライン報告書を基に CI 変更による IT 環境への影響を評価するとき、間違った CI ステータス情報は、環境の現状を間違って伝え、当然、変更の与える影響も不正確なものとなります。

次の図は、全 CI ステータス情報の流れを示しています。リリース管理からは、最終ソフトウェア ライブラリからの出入りに伴うソフトウェア CI ステータス変更、可用性管理からは、定常的なメンテナンスの CI のステータス変更が変更管理に通知されます。変更管理で承認されたステータス変更情報は、最後に構成管理に渡されます。次に、CI ステータス変更フォームのサンプルを示します。

CI ステータスの例 :

  • 計画済み

  • 開発中

  • 開発済み

  • テスト中

  • テスト済み

  • 実装中

  • 実装済み

  • メンテナンス中

  • アーカイブ済み

なお、インシデントおよび問題 CI への変更は、直接構成管理に渡されます。どちらの場合も、受け付けられた情報は即座に CMDB に記録されます。

CI ステータス変更フォーム

cfgmgt24

図 12: CI ステータス変更フォームのサンプル

CI のアーカイブ保存と CMDB の更新
ソフトウェアのアップグレードとハードウェアの新しい製品への置き換えが行われた場合、旧バージョンのコンポーネントは IT 環境から除外し、対応する CI ステータスを CMDB に反映させます。通常、CI の廃棄は、このような IT システムのアップグレードによって起こります。このとき、廃棄するコンポーネントの CI ステータス変更を詳述した CI ステータス変更フォームが、変更管理から構成管理に提出されます (下図参照)。

cfgmgt13

図 13: CMDB における CI 情報の更新とアーカイブ保存

また、変更要求に関係なく環境から CI が削除された場合も、変更管理からステータス変更フォームが提出されます。たとえば、組織の部門で現在サブネットワークで使用しているカラー プリンタが不要になった場合が、これに相当します。部門では、プリンタの処分と変更管理への通知を担当するシステム管理グループに連絡します。そして通知を受けた変更管理から構成管理にステータス変更フォームが提出されます。

ソフトウェア ライセンスの管理
ソフトウェア ライセンスの監視と管理にも CMDB を使用します。この場合、構成管理プロセスは、組織が契約条項を遵守していること、何らかの問題が発生したときは管理職に通知する役割を果たします。組織または執行役員に対する法律上の責任問題につながりかねないので、ソフトウェアの不正使用は厳重に監視します。ベンダからソフトウェアを購入したとき、ソフトウェア ライセンスはセキュリティで保護されたドキュメント ライブラリなど、安全な場所に保管してください。ソフトウェア ライセンスの記載情報は、ソフトウェア CI の属性として管理することが必要です。具体的には次のような情報を管理します。

  • CI カテゴリ

  • CI 番号

  • 製造元

  • シリアル番号

  • バージョン番号

  • 購入日

  • 有効期限

  • ライセンス更新日

  • 配布可能コピー数

ソフトウェアの新規購入、追加ライセンスの購入、ソフトウェアのアーカイブ化を行ったら CMDB を更新します。ライセンス情報を適切に文書化することで、IT 環境で使用されているソフトウェアがすべてライセンス許可されていることを容易に確認できるようになります。ライセンス情報は、該当グループへの料金請求や、追加ライセンスの購入要請にも利用できます。この情報は不正使用の監視やライセンス情報の保守だけでなく、組織全体での無駄なライセンス購入防止にも役立ちます。大組織では、これだけでも大幅なコスト削減が期待できる場合があります。構成管理グループでは、当事者の部門から要請された場合、ライセンス情報を提供します。

cfgmgt14

ソフトウェア ライセンス管理タスク

ライセンス関連の構成管理の役割をまとめれば、次のようになります。

  • ソフトウェア ライセンスの要求

  • ライセンスの認可と割り当て

  • ライセンスの追跡管理

変更要求が承認されれば、変更管理から、新規ユーザー アカウントの設定、業務機能の拡張、新規ソフトウェア導入を目的としてソフトウェア ライセンスを要求できます。このとき、システム管理グループでも、新規ユーザー アカウントの設定など変更管理の承認が必要な作業を除き、グループに権限がある標準的な変更に関してソフトウェア ライセンスを要求することができます。詳細については、『MOF 運用ガイド』の「変更管理運用ガイド」を参照してください。

前の図に示したように、すべての要求は構成管理グループに提出されます。構成管理では、要求されたソフトウェアの使用ライセンスが組織にあること、そして要求数のライセンスを提供できることを確認します。また、構成管理スタッフは、ソフトウェア要求フォームに必要な情報が記載されるていることを確認します。情報が間違っていたり、不足していたりする場合は、申請者に差し戻します。ソフトウェアが IT 環境で使用されている標準的なアプリケーションでない場合、またはライセンス数が足りない場合、構成管理と要求グループの連名で、購買グループに必要なライセンスの購入を要請します。追加ライセンスが取得され、CMDB に記録された時点で、ソフトウェアのインストールを開始できます。要求されたライセンスが使用可能な場合は、ソフトウェアのインストール許可と共に申請者に要求を返します。通常、インストール許可は、最終ソフトウェア ライブラリの管理を担当するリリース管理グループに与えられます。最終ソフトウェア ライブラリにはすべてのソフトウェアのマスタ コピーが保管されています。インストール完了後、構成管理グループがライセンスのステータスを更新します。

ソフトウェア申請者は、フォームの先頭セクションに必要事項を記入して構成管理に渡します。構成管理でフォームの内容を検討後、ライセンスが使用可能な場合は、申請者にフォームを戻します。それ以外の場合は、ソフトウェア購買グループに要求を転送します。最後に、申請者はフォームの 3 番目のセクションに、アプリケーションのインストール先プラットフォームを記入します。そしてフォームを構成管理に送り返し、CMDB を更新してもらいます。

以下にソフトウェア要求フォームのサンプルを示します。

ソフトウェア要求フォーム

手順 1. このセクションは申請者が記入します。

申請日 : ____/____/____

使用場所 :

申請者名 :
_____________________

電話番号 :
内線 : ________

ソフトウェア製造元 :
_________________________________________________

製品名 :
_________________________________________________

バージョン :

シリアル番号 : ______________________

必要コピー数 : _____________

インストール先ハードウェア プラットフォーム :

名前 :
_____________

CI 番号 : __________

名前 :
_____________

CI 番号 : __________

名前 :
_____________

CI 番号 : __________

名前 :
_____________

CI 番号 : __________

名前 :
_____________

CI 番号 : __________

名前 :
_____________

CI 番号 : __________

手順 2. このセクションは構成管理スタッフが記入します。

担当者 : __________________________

日付 : ____/____/____

要求されているのは標準ソフトウェアである。 :

はい

いいえ (購買グループへ転送)

受給可能ライセンス数 : _____________

ライセンス番号 : __________________

手順 3. このセクションは導入担当者が記入します。

導入日 : ____/____/____

担当者名 :

電話番号 :
内線 : _______

インストール先ハードウェア プラットフォーム :

名前 :
_____________

CI 番号 : __________

名前 :
_____________

CI 番号 : __________

名前 :
_____________

CI 番号 : __________

名前 :
_____________

CI 番号 : __________

名前 :
_____________

CI 番号 : __________

名前 :
_____________

CI 番号 : __________

手順 4. このセクションは構成管理スタッフが記入します。

CMDB 登録担当者 : ____________________

日付 : ____/____/____

図 15 ソフトウェア要求フォームの例

セキュリティ

セキュリティは構成制御において重要な位置を占めます。データベースとライブラリに対するセキュリティ ポリシーは、セキュリティ グループが計画します。ライブラリからデータを取得し、CMDB を変更する権限は、構成管理スタッフだけに与えます。CMDB 内にあるジョブに直接関係する情報の更新権も、構成管理スタッフのみに与えます。データベース アーキテクチャの変更権限は、構成マネージャと、マネージャが任命した変更実施者のみに与えます。CMDB に対するアクセス制御を確立すれば、正式許可数を超えるライセンス使用などの不正アクションを防止できます。

CMDB データのバックアップ
CMDB の定期的なバックアップは非常に重要な作業です。作成したバックアップは火災や盗難の恐れのない、安全な場所に隔離して保管します。バックアップの頻度は、IT 環境に行われる変更の量と頻度によって異なります。毎日大量に CMDB を変更する組織なら、毎週、場合によっては毎日バックアップを作成してください。CDMB は、重大な障害からの復旧手段として緊急事態対策の筆頭に数えられるものです。CDMB のバックアップは、万一のシステム障害に備えて作成しておくことが大切です。

構成ステータス アカウンティング
構成ステータス アカウンティング アクティビティは、ライフ サイクル全体を通じて個々の CI の現在および過去の履歴を報告書にまとめる作業です。報告書には以下の情報を含めます。

  • CI を一意に識別する ID

  • 関連の変更要求とインシデント/問題報告書

  • 監査報告の結果

  • ステータス変更履歴

  • CI の所有者

この情報を使用して、ベースライン報告書と管理職への報告書を作成できます。 ベースライン報告書は、変更管理に IT 環境の現在の状態に関する情報を提供し、これを利用して環境への影響が評価されます。このほかにも、組織内での変更量、特定の CI の変更率などを盛り込んだ報告書を作成できます。これを利用して、将来的な問題を未然に防ぐことができます。 通常、報告書は月次で作成しますが、大がかりな変更が頻繁に行われる環境では、それより頻繁に作成することもあります。

構成の検証および監査
構成の検証および監査のアクティビティは、ハードウェア、ソフトウェア、ドキュメント、手順、SLA などの CI をすべて物理的にチェックする作業です。 監査では、CMDB 内の CI の内容が実際の物理環境のコンポーネントと一致していることを確認します。 また、監視には、最終ソフトウェア ライブラリなど、組織にあるセキュリティ保護されたドキュメント ライブラリの内容の確認や、IT 環境でライセンス許可のあるソフトウェア コンポーネントと手順のみが利用されていることの確認も含まれます。さらに、承認済みの CI すべてに対応する変更要求が記録されているかどうかも確認の対象です。つまり監査とは、CMDB に最新の情報が反映され、信頼性の高い情報源として機能していることを検証する作業です。

監査は定期的 (たとえば半年に 1 度）に実施すると共に、抜き打ちでも実施し、ライセンス許可のあるソフトウェアの使用に関して組織が定めた基準が守られているか、また、CI の盗難が発生していないかどうかを確認します。抜き打ち監査では 、IT 環境の一部を検査するだけでもかまいませんが、定期監査では IT 環境全体を検査します。 実際の監査は、構成管理マネージャの指揮下において構成管理スタッフが実施します。監査の実施タイミングは次のように規定できます。

  • 定期 (CMDB 内容の変更量に応じて四半期に 1 度、または半期に 1 度)

  • 不定期

  • 主要な変更の前

  • 未登録 CI 発見時

  • 壊滅的な障害の発生時

許可されていない CI が見つかった場合は、担当の管理職に通知します。このとき、一般的な対応措置としては再トレーニングで十分ですが、必要と認められる場合は懲罰を課します。たとえば、違法ソフトウェアを発見した場合は、ソフトウェアを削除し、再トレーニングで当事者に、不正ソフトウェアの使用の違法性、その人や組織全体への影響について再教育します。検証および監査のアクティビティの推移を下図に示します。

cfgmgt16

図 16: 検証および監査のアクティビティ

監査の準備を行う際、構成管理マネージャはスタッフに、デスクトップ、サーバー、プリンタなど担当を割り当て、監査の実施方法を決定します。小さな組織では、CMDB テーブルを印刷し、テーブルのデータと実際の IT コンポーネントを照合すれば十分でしょう。しかし、大きな組織ではこの方法は不十分なため、スキャナを使用して各コンポーネントのバーコードを記録し、そのデータをダウンロードして CMDB の内容と照合します。どちらの場合でも、バーコードのないコンポーネントはドキュメントに記録し、監査タスク終了後に調査してください。

CMDB 内のデータの整合性を保証するには、監査結果と実際の CMDB 内容の比較が必要です。人的ミス防止のため、この作業は自動プロセスで処理します。その結果、矛盾が見つかれば報告書に記載します。構成管理スタッフは個々の矛盾を調査し、原因が構成管理グループの内部的なエラーなのか、外部的なエラーなのかを突き止める必要があります。たとえば、内部的なエラーは、構成管理プロセスに提出された変更要求に対する CI が正しくログに記録されていない場合などに発生します。内部的な問題を解決するには、スタッフの実施した作業を調べ、問題の再発防止にプロセスの再構築が必要かどうかを判断します。必要があれば、トレーニングを実施して作業手順の徹底を図ります。外部的な問題は、ユーザーが使用許可のないソフトウェアをダウンロードした場合や、未承認のハードウェアを使用した場合に発生します。そのような場合はシステム管理グループに報告して問題を解決してもらい、結果を構成管理グループに報告させます。構成管理スタッフは監査の最後に監査報告書を作成し、監査の結果、および矛盾が見つかった場合はその矛盾と対応措置を記録に残します。報告書は経営幹部と IT マネージャに提出し、彼らが IT コンポーネントの無許可使用と対応措置について十分な認識を得られるようにします。

Windows 2000 の監査機能
Windows 2000 の WMI (Windows Management Instrumentation) を使用すると、IT 環境の監査が容易になります。WMI は、IT 環境の運用と管理のコストの低減を目的に開発された、スケーラブルな管理インフラストラクチャです。WMI ベースの管理アプリケーションを作成すれば、大量の情報を収集できるようになります。収集した情報を CMDB 内のデータと比較することで、データベース内の CI と物理環境の対応コンポーネントとの整合性をチェックできます。CMDB に関しては次の機能を果たすスクリプトを記述することができます。

  • クライアント コンピュータに現在インストールされているアプリケーションの一覧

  • ネットワーク リソースの一覧

  • コンピュータ システム、周辺デバイス、およびファイル システムに関する情報

WMI スクリプトは次の各言語に対応しています。

  • Microsoft Visual Basic

  • Visual Basic for Applications

  • VBScript

  • Microsoft JScript

  • Perl

WBEM の概要
WBEM (Web-based Enterprise Management) は、エンタープライズ ネットワークでの情報アクセスおよび共有方法を、共通の規格で標準化するための業界イニシアチブです。WBEM の成果として、多様多様なソースから管理データの収集、関連付け、および統合するテクノロジが開発され、ユーザーはエンタープライズ ネットワーク環境の全体像をさまざまな視点で正確に把握できるようになりました。WBEM イニシアチブが解決を目指すのは、エンタープライズ ネットワークでのエンド ツー エンド管理および診断用データの収集に関する問題の解決です。大規模企業の場合、ネットワークは下図に示すように、製造元の異なるハードウェア、さまざまなプロトコルとオペレーティング システム、多数の分散アプリケーションで構成され、その全体の掌握は大きな課題です。

cfgmgt17

図 17: WBEM アーキテクチャの例

一般に、エンタープライズ環境では用途によって異なるプロトコルとインターフェイスを使用しています。たとえば、ネットワーク管理には SNMP (Simple Network Management Protocol) を利用し、デスクトップ システム管理には DMI (Desktop Management Interface) を利用する、といった具合です。そこでエンタープライズ ネットワーク管理の対策として、WBEM では、共通のモデルに準拠し、相互に連携しながら管理情報の収集に当たるツールの開発を提唱しました。共通化されたモデルとデータ ソースを必要に応じて拡張することで、既存のネットワーク コンポーネント、ツール、およびプロトコルとの連携が可能となります。

cfgmgt18

図 18: WBEM 標準ベースの エ ンタープライズ ネットワーク管理向けイニシアチブ

つまり、WBEM はブラウザをベースをせず、また、ユーザー インターフェイス (UI) ツール、データ リポジトリ、ネットワーク管理プロトコル、コンポーネント モデル、レジストリ、ディレクトリ、ファイル システム、そのいずれに取って代わるものでもありません。 WBEM は、あくまでも規格であり、エンタープライズ ネットワークの管理標準の集まりです。WBEM の管理標準は次のことを定めたものです。

  • 管理対象オブジェクトに関する情報へのアクセスに必要な構造と表記規則の定義。

  • 情報の集中管理のサポート。さまざまなクライアントや管理ツールによるデータの提供、検索、解析をサポートします。

  • ネットワークのあらゆる場所から管理対象オブジェクトへのアクセス制御のサポート。アクセス権があれば任意の場所からオブジェクトの解析と操作が可能です。

WBEM の沿革
WBEM は、Microsoft、コンパック、BMC、シスコ、Intel を代表とする企業群によって 1996 年に構想化され、正式に提案されました。WBEM の基本構想はオープンなデータ管理環境の定義にあります。つまり、ネットワークを構成する管理システムとアプリケーションが、被管理デバイス上にある任意の管理エージェントを使用して、また可能な限り多くの既存テクノロジと規格を利用して、相互アクセス、制御、および情報共有を行うオープンな環境の定義にあります。この構想は多くの点で、近年の大きな技術的ブレークスルー である World Wide Web の成果を反映しています。なぜならインターネットは、史上初めて、通信相手のコンポーネントが置かれた環境に対する知識を必要とせずに、ネットワーク上のデバイスがデータの提供者にも利用者にもなれる環境だからです。このような WWW 技術との構想的類似性を受け、将来的に、従来型の管理ツールに Web ベース テクノロジを加えてオープンな管理環境の構築を図るために、イニシアチブは WBEM (Web-based Enterprise Management) と命名されました。

イニシアチブ創設以来の参加企業は、DMTF (Desktop Management Task Force) という組織を結成し、共同で環境に依存しない WBEM 仕様のプロトタイプを開発しました。この仕様には、SNMP や DMI などの標準に基づき、任意の管理対象の記述方法とそのアクセス方法が定義されました。 この仕様の中核コンポーネントはデータ記述メカニズムで、これが後に CIM (Common Information Model) という名称で DMTF 標準になりました。

CIM 仕様は元々 HMMS (HyperMedia Management Schema) プロジェクトとして知られ、データ プロバイダやほかの管理モデルからの情報の収集と転送に使用するモデリング言語、名前付け、およびマッピング技術を規定したものです。実装モデルの記述と情報のフレームワークは、CIM スキーマに定義します。具体的には、プロパティとアソシエーションを備えたクラスの集まりを定義し、管理する環境についての情報を整理します。

DMTF では CIM 仕様と CIM スキーマの両方を管轄下に置き、ネットワーク管理データのアクセスおよび共有に関する業界標準と位置付けています。Windows 環境に実装された CIM コンポーネントの詳細については、後述の「WMI アーキテクチャ」を参照してください。

1996 年から 1998 年にかけて、Microsoft は Windows をベースとした WBEM テクノロジの実装コンポーネントの開発に取り組みました。具体的には、WBEM SDK (ソフトウェア開発キット)、CIM コンポーネント、および CIM 対応データ プロバイダ テクノロジを開発しました。

1998 年 6 月、DMTF は、創設企業からの WBEM イニシアチブの移管を受けたことを公表しました。このため、現在の WBEM イニシアチブ活動の中心は DMTF に移り、この組織は WBEM 互換テクノロジと標準の開発を進め、業界への普及を図る総合組織となっています。ただし、Microsoft Windows Management Instrumentation SDK (旧称 WBEM SDK) など WBEM 準拠の具体的な実装は、各ベンダの責任で行います。DMTF は、WBEM イニシアチブを引き受ける際に、WBEM 参照例として最新の WBEM テクノロジ (Microsoft の CIM 実装など) を使用することに合意しました。さらに、環境の中立性という当初の WBEM の理念を遵守するために、いかなる要件においても、プログラミング言語を特定の言語に限定するなどの実装の依存性をベンダに課さないことにも合意しました。

WBEM の標準コンポーネント
現在、WBEM は次の 2 つで構成されていますが、将来的には、ほかの標準 (XML によるプラットフォームに依存しない CIM オブジェクトの共有など) によって拡充されていく見通しです。

  • CIM 仕様 - WBEM の実装要件を定義します。

  • CIM スキーマ - データ リポジトリの内容を記述します。

本来 WBEM は、CIM (Common Information Model) の実装を提案するためのイニシアチブです。CIM とは、管理対象オブジェクトのオブジェクト指向スキーマのことです。また、管理対象オブジェクトとはシステム リソースのオブジェクト表現、スキーマとは管理データを記述する共通のメカニズムのことです。WBEM はこれらを利用して、データの表現形式を規定する情報の標準と、コンポーネント間の相互作用を規定するプロセスの標準を定義するフレームワークです。

CIM スキーマは、すべての管理ドメインに適用する単一のコア モデルと、特定の種類の管理ドメイン (システム、ネットワーク、データベース、アプリケーション、デバイス) に属する情報を記述するための複数の共通モデルで構成されます。

スキーマは拡張可能です。共通スキーマで表現できない、特定のテクノロジ (オペレーティング システムなど) に固有の情報を表現したい場合に、拡張スキーマを定義します。

Microsoft の WBEM 実装 - WMI
Microsoft の WMI (Windows Management Instrumentation) は WBEM の実装形態の 1 つで、DMTF が採用した CIM に基づいてシステムおよびアプリケーションの統一管理をサポートします。これは Microsoft Windows 管理サービスの主要コンポーネントです。Windows 管理サービスには、WMI のほかに、Active Directory のロケーションとポリシーに関するサービス、Microsoft 管理コンソール (MMC) の表示系を司るサービス、WSH (Windows Scripting Host) による自動化機能が実装されています。

WMI は Microsoft の管理インフラストラクチャの中核コンポーネントとして、Windows NT エンタープライズ ネットワークを構成する管理コンポーネントの保守作業と管理コストを軽減します。WMI には次の特長があります。

  • Windows 98 と Windows&#174 2000 オペレーティング システムの操作、構成、ステータス管理に、多機能で一貫性のあるモデルを提供します。WMI のダウンロード可能コア コンポーネントには、Windows NT 4.0 SP 4 と Windows 95 に対応したものもあります。

  • COM API によって、すべての管理情報への共通のアクセスを提供します。

  • ほかの Windows 2000 管理サービスと相互運用性があり、サードパーティ ベンダによる統合管理アプリケーションの開発を容易にします。

  • 柔軟なアーキテクチャを提供しています。新規にコード モジュール (WMI プロバイダ) を記述することによって、ベンダは独自のデバイス、アプリケーション、拡張機能に対応するように情報モデルを拡張することができます。

  • 管理情報の変化を認識、収集し、ほかの管理情報と比較、関連付けして、ほかのローカルまたはリモートの管理アプリケーションに転送できるイベント アーキテクチャを備えています。

  • 情報モデルの詳細なクエリを可能にする多機能クエリ言語を提供しています。

  • スクリプトを記述できる API を採用し、管理アプリケーションの開発者が Visual Basic または WSH (Windows Scripting Host) を使用できるようになっています。

たとえば、ローカルとリモートでのイベント管理機能と情報モデルのクエリを組み合わせれば、複雑な管理問題のソリューションを作成可能です。こうしたソリューションは Visual Basic または WSH で簡単にスクリプト化すれば、要求頻度の多い付加機能として Windows NT 管理に実装することができます。

以降のセクションでは、Microsoft の WBEM 実装についてもう少し詳しく説明していきます。

WMI アーキテクチャ
WBEM は、管理データの収集および配布に関し、3 層アプローチを採用しています。3 層とは、オブジェクト定義を格納する標準メカニズム (CIM 準拠のオブジェクト リポジトリ)、管理データの取得と配布のための標準プロトコル (COM/DCOM、ほかのプロトコルも使用可能)、および WMI プロバイダとして機能する Win32 ダイナミックリンク ライブラリ (DLL) です。WMI プロバイダは CIM スキーマに管理対象のデータを提供します。

cfgmgt19

図 19: WMI のアーキテクチャ

WMI 機能を提供する実行プロセスは WinMgmt.exe です。この実行プログラムは、CIM オブジェクト リポジトリ、CIM オブジェクト マネージャ、API と連携して WMI 機能を実現します。

CIM オブジェクトマネージャ
CIM オブジェクト マネージャは、Microsoft の WBEM 実装テクノロジの主要コンポーネントです。WBEM の最大の目標はデータの統一表現ですが、オブジェクト マネージャではデータをオブジェクト指向方式でカプセル化し、CIM オブジェクト リポジトリに格納します。CIM オブジェクト マネージャは、リポジトリに格納されている管理対象オブジェクトの収集および操作のポイントを提供し、情報の収集と操作を容易にします。

ただし、CIM オブジェクト マネージャは管理情報に直接アクセスすることはありません。WMI プロバイダはリソース (管理対象オブジェクト) から情報を収集し、WMI API を通じて管理アプリケーションで利用できるようにします。つまり、WMI 内で CIM 機能を提供するのは、CIM オブジェクト マネージャです。

WMI プロバイダ
WMI プロバイダは、CIM オブジェクト マネージャと 管理対象オブジェクトの間の中間プログラムとして機能します。CIM オブジェクト マネージャは、管理アプリケーションから CIM リポジトリにない情報、またはサポートされていないイベントの通知に対する要求を受け取ると、その要求をプロバイダに転送します。その結果、プロバイダから要求された情報またはイベントが供給されます。

Microsoft WMI SDK には次のプロバイダが含まれています。

  • レジストリ プロバイダ

  • Windows NT イベント ログ プロバイダ

  • Win32 プロバイダ

  • SNMP プロバイダ

  • WDM プロバイダ

サードパーティ ベンダは、SDK を使用して、自社製品環境に固有の管理対象オブジェクトと対話するカスタム プロバイダを作成できます。

Microsoft WMI テクノロジは、SNMP、DMI、CMI などの既存の管理標準の代替技術でも、NDS などの他社プラットフォームやプラットフォーム固有のフレームワークを排除する技術でもありません。実際 WMI は、どのようなソースからでもデータ アクセスが可能な統合ポイントとして働き、他社テクノロジを補完します。この統合ポイントによって、管理エンティティで使用されている機器特有の API や標準に依存せずに、管理アプリケーションが利用できるようになります。これによって、システム管理者は、ローカル レベルで、または全社レベルで複数のソースからのデータやイベントを収集し、相互に関連付けることができます。

WMI セキュリティ
WMI は、Windows と Windows NT プラットフォーム専用の限定的なセキュリティをサポートします。WMI セキュリティは、ローカル マシンとリモート アクセスの両方についてユーザーのログオン情報を認証します。認証されたユーザーは、CIM スキーマ全体に対し、そのユーザーにふさわしいアクセス権を与えられます。現在の WMI リリースでは、個々のクラス、インスタンス、および名前空間などのシステム リソースに対するセキュリティはまだ提供されていません。ただし、ユーザーのアクセス権を読み取り操作に限定するなど、スキーマ操作に関するグローバルなアクセス制御は提供しています。WMI には、ユーザー アクセス権を設定するためのシステム管理者用ユーザー マネージャ アプリケーションが組み込まれています。このツールは、Windows NT オペレーティング システムに付属のユーザー マネージャ アプリケーションに似ています。

セキュリティ チェックが行われるのは、ユーザーが WinMgmt にログオンしたときだけです。このため、ユーザーによる WinMgmt 接続中に行われたアクセス権の変更は、ユーザーが次回ログオンするまで有効になりません。ユーザーのアクセス権を無効にした場合も、これと同様です。

セキュリティの実装に関する詳細については、WMI SDK を参照してください。

イベント処理
イベント通知は WMI の主要機能の 1 つで、これを使用すると、コンポーネントがハードウェアおよびソフトウェアに関するイベントやエラーを検出できるようになります。通知されたイベントが WMI アーキテクチャを通じて該当するコンポーネントに渡され、そこで必要な対応措置が実行されます。

WMI 内では、イベントとは外部で発生した特定の (または事前定義された) 事象 (外因性イベント)、または CIM リポジトリの変更事象 (内因性イベント) のどちらかを意味します。イベントが発生すると、イベント プロバイダが CIM オブジェクト マネージャに通知し、CIM オブジェクト マネージャが、この通知をイベント コンシューマと呼ばれる 1 つ以上の登録済みの受信先に配信します。イベント コンシューマが受信する通知の種類は CIM オブジェクト マネージャに登録されています。また、イベント プロバイダには通知対象のイベントの種類が登録されています。イベント コンシューマがイベント プロバイダとは独立して動作できるようにするため、CIM オブジェクト マネージャは両者を仲介し、登録済みコンシューマをそのコンシューマに対応するプロバイダと照合し、該当するイベントがあれば、そのコンシューマに転送します。

イベント コンシューマは受け取る通知を登録するだけで、イベントと通知が送られてくる方法には関与していません。通知の登録にはフィルタを指定します。フィルタは WQL (WMI クエリ言語) で記述されています。ここには、コンシューマがイベント通知を受信するための条件が列挙されています。

WMI クエリ言語
WMI クエリ言語 (WQL : WMI Query Language) は SQL 言語から派生した言語で、SQL にイベント通知などの WBEM 互換機能を追加したものです。コンシューマは、イベント通知を登録するとき、イベントの種類と配信条件をクエリに定義します。WQL を使用すると、エンタープライズ ネットワーク内の特定のコンポーネントに関するイベント通知フィルタを作成できます。WQL は WMI SDK 内に定義されています。

WBEM 互換スクリプト
WMI のスクリプト インターフェイスを使用すると、CIM オブジェクト マネージャと通信できるスクリプトと Visual Basic アプリケーションを作成できます。WMI スクリプトは次の各言語に対応しています。

  • Microsoft® Visual Basic®

  • Visual Basic for Applications

  • Visual Basic Scripting Edition

  • Microsoft® JScript®

  • Perl

スクリプト インターフェイスは、Visual Basic、Visual Basic for Applications、VBScript (Visual Basic Scripting Edition) などのスクリプト言語に対応する点で、CIM オブジェクト マネージャの COM インターフェイスとは異なります。

各種スクリプト言語と、スクリプトによるバッチ プロセス、自動イベント処理などの能力は、長年にわたって活用されてきました。これに対して、Microsoft の WBEM 互換スクリプトには、ほかの言語にない次の利点があります。

  • データ駆動アプローチ、つまり CIM を使用します。CIM は異種の情報を 1 つのモデルで扱います。このため、CIM のスクリプト API は、アプリケーションを各種のデータ ソースの複雑性から切り離します。

  • システム、ネットワーク、およびアプリケーションの情報を広範にカバーします。Microsoft のスクリプト API は、Win32、SNMP、レジストリ、WDM、パフォーマンス モニタ、Windows NT イベント ログ、および ADSI プロバイダをサポートします。Intel、コンパック、ヒューレット パッカード、BMC ソフトウェア などのベンダからは、各社に固有のオブジェクトに対応したスクリプト機能が提供される予定です。Microsoft でも、Microsoft Systems Management Server 用の機能を開発中です。また、Microsoft ではほかのプロバイダも開発中です。

  • プロバイダの機能が簡単に拡張できます。ツール、サンプル、および拡張可能なプロバイダ アーキテクチャは、Microsoft WMI SDK に完全なかたちで定義されています。さらに、プロバイダ開発には業界全体からのサポートがあります。

  • 新しいスクリプトが簡単に記述できます。Microsoft WBEM 互換 API は使い方が簡単です。スキーマは、スクリプトの適用範囲と改良に合わせて、容易に参照および拡張することができます。

Microsoft では、Windows 2000 に適用するシステム管理スクリプトの完全セットを提供する予定です。これらのスクリプトは、コマンド ラインから実行して、ローカルおよびリモートのシステム管理機能を提供します。サポート対象は Windows 95、Windows 98、Windows NT 4.0、および Windows 2000 です。スクリプトには VBScript 版、Perl 版、および JScript 版が用意され、ネットワークに合わせて簡単に拡張またはカスタマイズできます。さらに、WSH オブジェクト モデルを機能拡張すれば、CIM スキーマとの相互作用が可能となります。

次のセクションでは、WDM プロバイダを使用して、Microsoft WBEM 互換 WMI アーキテクチャがどのように機能するかについて説明します。

WDM プロバイダ
Microsoft は、カーネル コンポーネント計測用に WDM プロバイダを開発しました。WDM 計測コンポーネントは、WDM (Win32® Driver Model) アーキテクチャのコンポーネントですが、幅広いユーティリティが組み込まれているので、他種ドライバ (SCSI や NDIS など) と併用できます。WDM プロバイダはカーネル モード コンポーネントと通信して、WDM 対応ドライバへの WMI の実装を可能にするサービスを提供すると共に、WDM プロバイダへのインターフェイスとしても動作します。WMI は WDM プロバイダを使って情報の公開、デバイスの設定を行うと共に、デバイス ドライバからイベントを通知します。

WMI の WDM 部分は次のデータを配布します。

  • 公開されたデータ - データの標準セットは、Windows 2000 付属のポートとクラスのドライバに組み込まれます。

  • カスタム データ - OEM/IHV ドライバ拡張機能の形で提供されます。

  • セキュリティで保護されたデータ - 指定された用途に合わせて、Windows NT セキュリティ記述子のかたちで提供されます。

  • 高コスト データ (オプション) - データ収集アクティビティによっては、ドライバのパフォーマンスに大きな影響を及ぼすことがあります。このようなデータ収集は、管理アプリケーションが特にデータ収集を要求する場合にのみ実行します。既定では、ドライバは高コスト データを収集しません。WMI CIM に準拠しているテクノロジを使用する管理アプリケーションがその高コストデータを必要とする場合、WMI はデータの収集を開始するようドライバに通知します。そして、そのデータを必要とする最後の WMI 対応アプリケーションが終了するときに、データ収集を中止するようドライバに通知します。 どのデータの収集が高コストにつくかを決定するのは WMI ではなく、ドライバの作成者です。このように、収集コストが高いデータを識別するメカニズムは、非常に簡単です。

  • イベント通知 - イベント通知は WMI の主要機能の 1 つで、ドライバはこれを使ってハードウェア/ソフトウェアに関するイベントやエラーを検出できます。ハードウェア イベント通知は、前の説明のように、イベント フィルタと CIM オブジェクト マネージャによって処理されます。

また、WMI は管理アプリケーションにデバイスの構成を許可します。管理アプリケーションは、ドライバで発生したイベント、または自らが収集したデータのせいで、デバイスを構成し直さなければならないことがあります。

下図は、WMI アーキテクチャのプロセス フローにおける WDM プロバイダとカーネル モード計測機能の概要を示したものです。

cfgmgt20

図 20: WDM プロバイダとカーネル モード計測機能

ページのトップへ ページのトップへ

推奨トレーニング コース

このガイドで説明したタスクを実行するために最低限必要な予備知識については、以下に示す Windows 2000 用トレーニング リソースを参照してください。これらのコースの詳細情報は、https://www.microsoft.com/learning/default.mspx (英語) および https://www.microsoft.com/japan/learning/training/default.mspx に記載されています。

コース名
1267 : Planning and Implementing Active Directory (英語コース)

1556 : Administering Microsoft Windows 2000 (英語コース)

1557 : Installing and Configuring Microsoft Windows 2000 (英語コース)

1558 : Advanced Administration for Microsoft Windows 2000 (英語コース)

1561 : Microsoft Windows 2000 ディレクトリ サービス

2151 : Windows 2000 ネットワーク エッセンシャル

2152 : Microsoft Windows 2000 インプリメンテーション

2153 : Microsoft Windows2000 ネットワークインプリメンテーション

2154 : Microsoft Windows 2000 ディレクトリーサービスインプレメンテーション

謝辞

この文書の内容は、Accenture、Avanade、Microsoft Consulting Services、Hewlett-Packard Company、Lucent Technologies/NetworkCare Professional Services、および Compaq Global Services の IT 分野におけるさまざまな実装の経験に基づいています。

この文書に資料を提供していただいた各団体の寛大な支援に対し、心から感謝いたします。

この文書に記載されている情報は、発行時点で議論されている問題点に関する Microsoft Corporation の最新の見解を示しています。Microsoft は変化する市場状況に対処しなければならないため、本書の内容を Microsoft の確約事項として解釈してはならず、Microsoft は発行日以降に提示された情報の精度についてはいかなるものであれ保証致しません。

この文書は、情報の通知のみを目的としており、Microsoft は本書に記載されている情報について明示的にも暗黙的にも一切の保証を致しません。

適用し得るすべての著作権法を順守する責任はユーザーにあります。本書中のいかなる部分も、Microsoft の書面による許可なしには、いかなる目的のためであれ、いかなる形態、手段 (電子的、機械的、コピー機の使用、記録など) によっても複製、検索システムへの格納、または伝送してはなりません。

この文書の内容に関する特許、特許出願、商標、著作権、およびその他の知的財産は、Microsoft が所有します。Microsoft との書面によるライセンス契約に明記されていない限り、本書の提供が、以上の特許、商標、著作権、あるいはその他の知的財産権の利用を認めるものではありません。

この文書で例として挙げられている企業、その他の組織、製品、職業、イベントは、仮想のものです。それらが、いずれかの実際の企業、組織、製品、人物、またはイベントを指していることはなく、そのように解釈されるべきではありません。

© 2001 Microsoft Corporation.All rights reserved.

Microsoft、 BackOffice、 MS-DOS、 Outlook、 PivotTable、 PowerPoint、 Microsoft Press、 Visual Basic、 Windows、 Windows NT、 および Office ロゴは米国およびその他の国における米国 Microsoft Corporation の登録商標または商標です。

この文書に登場する実在の企業名や製品名は、各所有者の商標である場合があります。

ページのトップへ ページのトップへ