CMDB 設計Issue この記事では、要件の定義からデータモデルの開発まで、CMDB の設計方法に関するガイダンスとアドバイスを提供します。ここでは、構成管理のリーダーシップチームが、そのスコープを管理する目標、メリット、予想される用途、およびポリシーを既に明確にしていることを前提としています。 対象者は、構成管理プロセスオーナー、構成マネージャー、構成アナリスト、および主要な CI オーナーです。 スコーピングの決定は、多くの場合、組織のビジネスドライバー、契約上の義務、サービスコミットメント、準拠法、規制、および標準に対処するポリシーによって決定されます。必要なスコーピングの決定は次のとおりです。 •構成管理はどのような環境を制御するか？•CMDB 内のどの CI を関係レベルで管理する必要があり、どの CI が在庫または資産レベルの管理のみを必要とするか？•どの IT サービスが含まれるか？•考慮すべき地理的な考慮事項はありますか？•準拠する必要がある規制またはコンプライアンス要件はあるか？•トレーサビリティと監査可能性に必要な特定のレベルのコントロールがあるか？•どのようなセキュリティ上の問題に対処する必要があるか？•内部と外部のサービスプロバイダーへのインターフェイスが必要か？ これらの質問に対する回答の多くは、構成管理システムの設計と開発を管理するポリシーとして記述できます (まだ存在しない場合)。CauseCMDB 要件 IT インフラストラクチャに関するすべての情報の「記録システム」として、CMDB は、すべてのサービスマネジメントプロセスの効果的な実行をサポートする基盤ツールです。このため、CMDB を設計する前にすべてのステークホルダーから要件を収集することが、成功への重要な最初のステップです。少なくとも、次の要件を決定する必要があります。 ガバナンス CMDB は、IT 組織に影響を与えるさまざまな規制およびガバナンス要件を満たすのに役立つ非常に強力なツールです。たとえば、サーベンスオクスリー法は、財務報告に影響するプロセスのコントロールの証拠を要求する連邦政府の義務です。特定の CMDB 要件を規定する業界固有の規制が多数あります(患者情報に関する HIPAA コントロール、欧州連合のデータ保護に関する GDPR コントロールなど)。CMDB チームは、内部監査チーム、法律顧問、IT ガバナンスと規制コントロールを担当する IT 担当者など、適切なガバナンスステークホルダーからこれらの特定の要件を収集する必要があります。 在庫と資産 IT 資産管理の改善が CMDB イニシアチブの目標の 1 つである場合は、IT 資産管理関連の要件を定義する必要があります。在庫、資産、および構成管理機能はすべて、各 CI の属性データの共通サブセットを使用します。ただし、各機能には、CI 管理の目的ごとに異なる追加要件があります。たとえば、在庫関連の CI データは通常、CI の一意の物理プロパティと場所 (シリアル番号、モデル番号、場所、所有者など) を表します。在庫管理アプリケーションは、所有権、場所、状態、ライフサイクル、および在庫レベルを追跡します。資産関連 CI データは、コスト、現在価値、メンテナンスコスト、契約条件、減価償却、交換情報などの財務およびガバナンス情報に焦点を当てています。一方、構成管理では、CI が互いにどのように関連しているかに関する情報が必要です。関係情報により、インシデントのトラブルシューティングと変更の影響分析が可能になります。その結果、インシデントをより迅速に解決し、変更要求をより確実にレビューおよび承認することができます。 ServiceNow では、在庫、資産、および構成管理のすべてのアプリケーションが単一の CMDB を利用します。ただし、実装を成功させるには、これらの機能の要件を事前に定義し、それらに対応するように CMDB を設計する必要があります。これらの機能に必要な情報の一部は、おそらく既に他のデータベースに存在します。この場合、CMDB のデータを複製するか、CMDB の代わりに元のソースから参照するかを決定する必要があります。レプリケーションにより、レポートとアドホック検索が容易になりますが、データをタイムリーに同期するためのコントロールが必要です。 インシデント、問題、および変更管理 CMDB を使用すると、イベント、インシデント、問題、および変更の要求をサービスの影響度に関連付けることができるように、サービス依存関係マップを作成できます。これらの機能をサポートし、組織の同意を得るために必要な特定の CI 情報を決定するには、適切なステークホルダーを関与させる必要があります。このステークホルダーグループには、プロセスオーナー、プロセスマネージャー、および各プロセスのその他の該当分野のエキスパートを含める必要があります。少なくとも、次の必要なサポート機能を考慮してください。 •インシデント管理 – 解決責任アサインのためのサポートチーム情報へのアクセス – インシデントのトラブルシューティングと解決を迅速化するための CI エンドツーエンドサービスマッピング – 適切な優先度とエスカレーションアサインのための、解決ターゲットまたは SLA、およびビジネスへの影響度情報へのアクセス •変更管理 – 影響を受ける CI を影響度評価の目的で変更要求に関連付ける機能 (メンテナンス/機能停止期間、SLA など) – 変更のアップストリームまたはダウンストリームの潜在的な影響を理解するための CI エンドツーエンドサービスマッピング CMDB 要件に影響を与えるプロセスを優先順位付けするときは、プロセスの現在の成熟度レベルと、成熟度を高めるための目標または計画に関する一般的な理解も考慮する必要があります。 サービス管理 CMDB イニシアチブの目標がサービスの改善を実現することである場合、CMDB 要件にはサービスの詳細と関係を含める必要があります。CMDB は、サービスオファリングのブレークダウンを保持し、基礎となるインフラストラクチャとのリンクを示すための優れたリポジトリです。サービスカタログに記載されているさまざまなサービスの所有者と協力して、サービスレベルの向上に必要な監視およびレポート情報を特定します。ステークホルダーには、サービスプランナー、ポートフォリオマネージャー、プログラムまたはサービスオーナー、ビジネスリレーションシップマネージャー、およびサービスレベルマネージャーが含まれます。 CMDB を使用してサービスカタログをサポートするための一般的なアプローチは、カタログ内のサービスに対応する CMDB にサービス CI を作成することです。サービス CI をさらに細分化して、基礎となるインフラストラクチャ CI にリンクして、サービス階層を作成することができます。最初のステップは、提供されるサービスオファリングのタイプを特定することです。これらのタイプには通常、すぐに使用できるビジネスサービスと、ビジネスサービスを形成するために他のサービス要素と組み合わせる必要がある IT サービスが含まれます。各タイプのオファリングから少なくとも 1 つのサービスを選択し、基礎となるインフラストラクチャレベルに分類します。この情報は、CMDB サービス構造とレベル設計を決定するために使用され、必要な CI 関係のタイプを決定するのに役立ちます。 サービスレベルアグリーメントも考慮する必要があります。CMDB の設計作業の多くは、テクノロジーとインフラストラクチャを管理するための適切な属性情報を特定しますが、次のような重要な Service Management 属性を見落とすことがよくあります。 サービスレベルターゲットと優先度 サービス運用情報 (サービス可用性の時間、必要な承認など) サービス関連の通知および通信情報 サービスオーナー ResolutionCMDB 設計 CMDB 設計の最も重要かつ困難な領域の 1 つは、適切な CI クラス、レベル、属性、および関係を選択することです。これには、コントロール、情報の可用性、およびデータの維持に必要なコストと労力の適切なバランスが必要です。このバランスは、組織の IT ビジネスプロセスとサービスマネジメントの要件が満たされたときに達成されます。情報が多すぎると、維持するための不必要なコストと労力がかかり、CMDB の受け入れと使用が損なわれる可能性があります。情報が少なすぎると、制御レベルが不十分になり、サービスパフォーマンスを最適化できなくなります。適切な CI クラス、レベル、属性、および関係の決定は、反復的なプロセスです。CMDB データモデルを完成させる前に、CMDB 開発のこれらの 4 つの側面をしっかりと理解しておく必要があります。 CI クラスの定義 CMDB は、各クラスが類似の CI を含む事前定義された標準化されたカテゴリであるクラス構造によって編成されます。各クラスは、親子関係を通じてサブクラスにさらに分割できます。子は親の特殊化です。たとえば、ハードウェアの最上位クラスは、コンピューター、ネットワーク機器、プリンターなどのサブクラスに分割できます。この階層が下になるほど、コンポーネントの専門性が高くなります。 CMDB クラス構造を定義するときは、次のガイドラインを使用して CMDB のトップレベルのクラスが多いほど、CI の検索が難しくなる可能性があります。CMDB の最高レベルでクラスの数を制限すると、検索条件が簡素化されます。 クラスを使用して、最適化されたフィルタリングを通じて検索とクエリを絞り込みます。IT コンポーネントは、物理コンポーネント、論理コンポーネント、または概念コンポーネントです。 – 物理コンポーネントには特定の場所があり、スペースを占有し、表示できます (サーバー、デスクトップ、ネットワークデバイスなど)。 – 論理コンポーネントは物理スペースを占有しません。運用に物理コンポーネントを必要とする特定の機能 (データベースインスタンス、ソフトウェアリリース、企業イントラネットなど) を実行します。 – 概念コンポーネントは、一意の概念 (ビジネスサービス、システム、環境など) を作成するために結合された物理コンポーネントと論理コンポーネントを表します。 一部のステークホルダーは、物理 CI のみに関心があるため、たとえば、物理資産のみを表すクラスを使用することをお勧めします。 一意のデータが存在する場合にのみサブクラスを作成します。たとえば、図 1 では、「Personal Computer」というクラスをさらにデスクトップ、ラップトップ、ワークステーション、タブレットなどに細分化できます。ただし、すべてのタイプのデータ要件が類似している場合は、これらのタイプのパーソナルコンピューターごとに新しいクラスを作成する必要はありません。より適切なソリューションは、「Personal Computer」クラスに「Type」属性を追加して、特定の各タイプ (デスクトップ、ラップトップなど) を識別することです。自動検出ツールを使用して、CMDB に物理 (および一部の論理) CI を入力します。適切に定義された CMDB クラスを使用すると、自動検出リンクを簡素化できます。概念的な (およびいくつかの論理的な) コンポーネントを手動で入力する必要があります。幸いなことに、これらのコンポーネントは、物理コンポーネントよりもはるかに頻繁に変更される傾向があります。最上位のクラスを標準化して、すべてのコンポーネントが一貫した分類に準拠するようにします。一貫性がないと、CMDB の使用が非常に困難になります。CI を関連付ける機能が低下し、問い合わせと分析結果の効果が低下します。 CI レベルの定義 レベルは、CMDB に含めるように選択した CI クラスの深度を参照します。CI は、単一のコンポーネントまたは完全なシステムにすることができます。たとえば、CI はワークステーションの場合もあれば、ワークステーションの各コンポーネント (プロセッサー、モニター、キーボード、マウスなど) の場合もあります。CI クラスレベルの深度を決定するときは、次のような質問に答える必要があります。ワークステーションを CI にするか、または各ワークステーションコンポーネントに CI を含めるかMicrosoft Office スイートは 1 つの CI である必要があるか、それともスイートのコンポーネント (Word、Excel、PowerPoint など) ごとに 1 つの CI がある必要があるか?)考慮すべき基準は次のとおりです。 コスト：コンポーネントのコストは個別に追跡する必要がありますか？たとえば、高価なグラフィックカードは、ワークステーションに存在する場合でも CI になる可能性があります。 価値：コンポーネントを追加する価値は、コンポーネントを作成および管理するためのオーバーヘッドよりも小さいか？その場合は追加しないでください代わりに、追加の詳細を親 CI の 1 つ以上の属性として表します。 変更に関する考慮事項：コンポーネントの変更、特に場所の変更は頻繁に行われますか？ トレーサビリティ：監査上の理由から、コンポーネントを追跡する必要がありますか？ ガバナンスおよびコンプライアンス要件：この CI はサーベンスオクスリーコンプライアンスの影響を受けますか？契約および使用コンプライアンスの対象ですか？ 提供品質：インシデントと変更を記録し、効果的な問題管理アクティビティをサポートするには、どのレベルの CI で十分か？ サービスコミットメントの管理：コンポーネントは、変更の影響を分析するときに考慮する必要があるサービスオファリングの重要な部分ですか？ ベストプラクティスでは、CMDB に記録された CI レベルで変更を行うことをお勧めします。たとえば、各モジュールの詳細レベルまでソフトウェア CI を記録することにした場合、変更はそのレベルで行われ、記録されます。ただし、CMDB ソフトウェア CI の平準化がプログラムのレベルにのみ拡張されている場合、モジュール (プログラムのコンポーネント) レベルで変更するには、プログラム全体を再コンパイルし、そのレベルで変更を記録する必要があります。 CI レベルを定期的にレビューして、情報が有用で正確な適切なレベルであることを確認します。ただし、CMDB イニシアチブの開始時に、必要な最低レベルの CI クラスを特定し、すぐに使用する予定がない場合でも CMDB で作成するようにしてください。これにより、後で CMDB を再設計する必要性が最小限に抑えられます。 CI 属性の定義 属性は、CI を説明するデータ要素です。これらは、使用中のもの、アイテムのステータス、場所など、サービスを管理およびサポートするために必要な CI の特性を特定し、詳述するのに役立ちます。ハードウェア CI 属性のサンプルには、メーカー、モデル、シリアル番号、場所、バージョン、ライセンス番号などが含まれます。 以前に収集した CMDB 要件を確認して、必要な特定の CI 属性を特定します。IT サービスを管理およびサポートするために必要な場合にのみ、属性が CI に追加されるように対策を講じます。また、必要な情報が他のレコード (インシデントなど) に既に存在するかどうか、および CI レコードで複製する必要があるかどうかを検討します。まず、最上位の CI クラスの属性を定義します。多くの CI 属性は、親 CI から継承することも、子 CI に渡すこともできます。 適切な CI レベルと属性の設計を可能にする重要なコンポーネントは、ServiceNow CMDB クラス継承モデルを理解することです。CMDB クラスは、同じ特性を共有する CI のグループであり、CMDB クラス構造は、テーブルと列、またはクラスと属性の形式で構成要素を提供します。CMDB は、すべての共通 CI 属性が定義されているベースクラスまたは親クラスで始まります。基底クラスは「構成アイテム」と呼ばれ、cmdb_ci というデータベーステーブルに存在します。構成アイテムクラスには、ハードウェアかソフトウェアか、物理か論理かを問わず、任意の構成アイテムに関連付けることができる多数の属性が含まれてい 。構成アイテムクラスで定義された属性の例は、「説明」です。CMDB 内のすべての CI クラスレベルに対して一意の説明フィールドまたは属性を作成する必要があるのではなく、cmdb_ci は [説明] 属性と、構成アイテム継承を拡張するすべてのサブクラスを定義し、その属性を使用できます。 拡張テーブルまたは子クラスは、その特定のクラスに固有の属性を追加します。たとえば、Unix Server クラスは Server クラスを拡張し、Computer クラスを拡張し、[] Hardware クラスを拡張します。Hardware クラスは構成アイテムを拡張し、その 4 つの「親」クラスで利用可能なすべての属性は、追加された一意の属性に加えて、Unix Server クラスで使用できます。 この例をさらに進めると、多くの組織が複数のメーカーの Unix サーバーを使用しています。CMDB は、HP-UX、Solaris、および AIX サーバーの Unix サーバークラスを拡張する一意のクラスを含めることでこれに対処します。これらの各クラスは、その 5 つの「親」から属性を継承します。組織内の特定のタイプの CI に適した CMDB クラスがまだ存在しない場合は、テーブルと列を使用して新しいクラスを簡単に作成でき 。カスタムテーブルを CMDB に追加するときのベストプラクティスは、最も論理的な親クラスを拡張して、クラスの継承を活用することです。たとえば、CMDB には、サーバークラスを拡張するロードバランサークラスが含まれています。ロードバランサークラスには、F5 BIG-IP ロードバランサーの子クラスがあります。組織が Barracudo Networks のロードバランサーを利用している場合は、ロードバランサークラスから拡張する新しいクラスを作成するのが最適です。 継承の概念を属性に適用すると、いくつかの便利な機会が生まれます。次の 3 つの観点から考えてください。 タイプ 説明 例 ルートレベルの CMDB 内のすべての CI に適用される必須属性 •名前•説明•ステータス クラスレベル 特定の CI クラスに固有の属性 サーバー•メーカー •モデル•シリアル番号 CI レベル 特定の CI インスタンスサーバー NT00490 に固有の属性 サーバー NT00490•NERC 規制コード•前回の監査日•セキュリティクリアランスレベル 継承の概念を使用して CI を分類すると、CMDB データモデルを一貫して定義し、CI 属性の管理を簡素化するのに役立ちます。 CI 関係の定義 CMDB と資産リポジトリの違いは、CI 間の関係を定義することです。関係がなければ、資産を組み合わせてビジネスに価値を提供するエンドツーエンドの IT サービスを提供する方法を理解することはできません。CMDB を強力な意思決定支援ツールにするのは、この関係データです。CI 間の依存関係を理解することで、たとえば、ディスクドライブのバンクの損失によって誰が、何が影響を受けるかを正確に把握できます。ルーターが故障していることがわかったら、その機能停止の影響を評価することができます。サーバーのプロセッサーをアップグレードする場合は、アップグレードの機能停止中に誰または何が影響を受けるかを知ることができます。 多くの場合、CI 間の関係は自動的に検出できます。ServiceNow の Discovery 製品を使用すると、検出プロセスを通じて多くの関係がシステムに自動的にロードされます。同様に、別のシステムから CMDB データをプルする場合は、インポートの一環として何らかの形式の関係を受け取ることがあります。データソースに関係なく、これらの自動化された関係を、定義した他の関係と拡張することができます。 ServiceNow の CI 関係エディターを使用すると、これを簡単に行うことができ、12 を超える関係タイプから選択できます (使用、実行、接続先、依存など)。関係タイプを選択するときは注意が必要です。多すぎると管理できなくなり、ユーザーが混乱する可能性があります。推奨されるベストプラクティスは、関係に応じて汎用から開始することです。このアプローチでは、関係が特定の CI から上流と下流の両方に移動できる基本的な依存関係マップを定義できます。この関係タイプにより、ビジネスサービスマップ (BSM) が、指定された (ルート) CI のアップストリームとダウンストリームの依存関係をグラフィカルに表現できるようになります。この機能は、インシデントのトラブルシューティング、問題の根本原因分析、および変更の影響分析をサポートします。これらの機能は、インシデント、問題、および変更の管理プロセスを正常に運用するために重要です。 すべてをまとめる CI クラス、レベル、属性、および関係を定義した後、次のステップは、これらの詳細を最終モデルに統合することです。多くの組織は、CMDB 構造を視覚的に表現した図または「図」で CMDB モデルを表すことを好みます。このアクティビティに使用できる CMDB モデル図の構造のサンプルは無数にあります。インターネットですばやく検索したり、ServiceNow コミュニティに問い合わせたりすると、組織に適したものが必ず見つかります。CMDB モデルは、少なくとも 3 つの情報列 (CI クラス構造 (レベル)、CI 属性、および関係) を含むリスト形式で表すことができます。 Related Linksサマリー 主要なステークホルダーを関与させ、明確に表現された要件を利用することで、組織の包括的で拡張可能な CMDB 設計を確実に行うことができます。このモデルは、CMDB の構築と入力計画の信頼できるソースになります。さらに、効果的なコントロールメカニズムと組み合わせることで、現在および将来のサービスとインフラストラクチャを管理するために必要な重要な情報が CMDB に含まれるようになります。