CSDM モデルのサービスデリバリドメイン

  • リリースバージョン: Zurich
  • 更新日 2025年07月31日
  • 所要時間:17分
  • サービスデリバリドメインは、インフラストラクチャ、テクノロジー、統合パターン (インフラストラクチャ、システム、データ、プロセス、依存関係モデル)、サービスデリバリーネットワーク、および運用モデルを含む、エンドツーエンドのサービスデリバリーシステム全体を表します。これらのアイテムを組み合わせることで、CSDM 準拠のサービスが内部および外部のユーザーや組織に提供されます。

    サービスデリバリドメインのテーブル

    サービスデリバリドメインのテーブルのユーザーは、(ビルドおよび統合ドメインで開発された) 組織のビジネスアプリケーションをサポートする運用環境とインフラストラクチャを提供および管理します。一般的なユーザーは、サービスインスタンスオーナー (アプリケーションとプラットフォームの場合) とサービスデリバリーオーナーまたはサービスプロバイダー (インフラストラクチャとデリバリーの場合) です。

    サービスデリバリドメインのテーブルは 会社が販売しているか、プロバイダービューで消費しているテクノロジーを表します。 サービスマッピングディスカバリー テーブルに入力します。ドメイン内のテーブルでは、CI とその関係を管理することもできます。このドメインには以下のテーブルが含まれます。

    • 技術管理サービス (以前のテクニカルサービス)[cmdb_ci_service_technical] テーブル。サービス分類はテクニカルサービスです。
    • テクノロジー管理オファリング (旧称テクニカルサービスオファリング)[service_offering] テーブル。サービス分類はテクニカルサービスです。
    • カタログを要求します。テクノロジーコンシューマーは、要求カタログを通じて テクノロジー管理オファリング を要求できます。カタログについては、 サービスカタログで詳しく説明しています。
    • ダイナミック CI グループ [cmdb_ci_query_based_service] テーブル。サービス分類はテクニカルサービスです。イベント管理技術管理サービスcmdb_ci_query_based_serviceテーブルを使用します。
    • サービスインスタンス ( CSDM v5 より前はアプリケーションサービスと呼ばれていました) [cmdb_ci_service_auto] テーブル。[サービス分類] は [アプリケーションサービス] です。
      • 手動で作成および サービスマッピングの場合:マップ済みアプリケーションサービス [cmdb_ci_service_discovered] テーブル ( ベースシステムに含まれています)。
      • クエリベースの場合:[cmdb_ci_query_based_service]。
      • タグベースの場合:[cmdb_ci_service_by_tags]。

    このドメインの CI は、デジタル製品の展開済みインスタンスと、それに関連する検出可能なコンポーネント (インストール済みアプリケーション、サーバー、ネットワークコンポーネントなど) に加えて、展開されたインスタンスを提供およびサポートするサービスのドキュメントです。ドメインは、使用中の 技術管理サービス ポートフォリオも表します。ライフサイクルの詳細については、「 有形/物理 CI のライフサイクル値の定義」を参照してください。

    サービスは操作可能です。つまり、 ITSM インシデント管理問題管理、または 変更管理用に選択できます。

    CSDMフレームワークのサービスデリバリドメイン。

    サービスデリバリテーブル間の関係

    • サービスインスタンス Contains::Contained by SDLC コンポーネント (このアイテムを使用するためのオプション)。
    • サービスインスタンス別のビジネスアプリケーション Consumes::Consumed
    • サービスインスタンス (展開されたシステムまたはアプリケーションスタックの論理表現)Depends on::Used by /Sends Data To:: サービスインスタンス。
    • サービスインスタンス Depends on::Used by アプリケーション。
    • アプリケーション Runs on::Runs インフラストラクチャ CI。
    • 技術管理サービス は参照属性を使用してインフラストラクチャ テクノロジー管理オファリングとの関係を指定します。サービスオーナーに公開され、通常は 1 つ以上のビジネスサービスをサポートします。技術管理サービスには、1 つ以上のテクノロジー管理オファリングで構成される運用ビューが含まれる場合があります。
    • テクノロジー管理オファリング Contains::Contained by サービスインスタンス。ローカライズ/地域、環境、価格設定、可用性、機能、サポートグループ (インシデント)、テクニカル承認グループ (変更)、パッケージオプションなどのオプションへのテクニカルサービスの階層化。
    • テクノロジー管理オファリング Contains::Contained by ダイナミック CI グループ。
    • ダイナミック CI グループ (CMDB グループのクエリーの結果に基づく CI の動的なグループ化) は、関連リストを使用してインフラストラクチャ CI との関係を指定します。
    • ビジネスサービスオファリング Depends on::Used by サービスインスタンス。
    注:
    ビジネスサービスと 技術管理サービス は、spm_taxonomy_nodeを介してspm_service_portfolioに接続します。「Service Portfolio Management taxonomy」を参照してください。

    サービスライフサイクルのサービスデリバリフェーズで使用されるテーブル

    サービスライフサイクルにおけるサービスデリバリーテーブル。

    サービスライフサイクルのサービスデリバリフェーズで使用されるテーブル

    サービスライフサイクルにおけるサービスデリバリーテーブル。

    サービスライフサイクルのサービスデリバリフェーズで使用される AI コンポーネントテーブル

    サービスデリバリフェーズの AI コンポーネントテーブル。

    API:API データモデルは CMDB 内で利用可能になり、API データの管理に役立ちます。API Insights の一部として、API の詳細の表示、APl の比較、データ欠落の特定と解決、サービス関係の管理など、APl の管理を一元化できます。API関数:仮想の視点から。API アプリケーション:オンプレミスの観点から。

    Al Function:機械学習、データ処理、およびAI駆動型タスクのためのスケーラブルなオンデマンドサービスを提供するパブリッククラウドプラットフォームに展開されたAl SaaSアプリケーション。アプリケーションは、オンプレミスのインフラストラクチャ管理を必要とせずに柔軟なソリューションを提供します。

    AL アプリケーション:Linux、Windows、Docker コンテナ、Kubernetes (K8) クラスターなどのさまざまなプラットフォームで実行できる AI ソフトウェアアプリケーション。プラットフォームは、機械学習モデル、データ分析、インテリジェントサービス、またはAI対応アプリケーションなど、さまざまなAlワークロードをサポートします。

    技術管理サービス

    技術管理サービス はサービスオーナーに関連付けられており、通常は 1 つ以上のビジネスサービスまたはサービスインスタンスの下に階層化されています。技術管理サービスには、1 つ以上の技術管理オファリングが含まれる場合があります。

    技術管理サービス のユーザーは、ビジネスに提供するテクノロジーを表示および管理できます。イベント管理により、サービスパフォーマンスを監視できます。イベント管理を使用して、関連するインフラストラクチャ CI とサービスインスタンスの健全性の問題を特定することもできます。

    技術管理サービス は、サービス消費ドメインのサービスポートフォリオの一部として管理できます (つまり、サービスポートフォリオ階層は 技術管理サービスから参照できます)。これにより、サービスポートフォリオ管理ワークスペースおよび関連するワークスペース内の技術管理サービスサービスとビジネスサービスの両方の、より完全な階層化と管理が可能になります。技術管理サービスに費やすことでビジネスサービスのパフォーマンスと信頼性がどのように向上するかを把握すると、より適切な意思決定を行うことができます。

    注:
    ビジネスサービスと 技術管理サービス は、spm_taxonomy_nodeを介してspm_service_portfolioに接続します。「Service Portfolio Management taxonomy」を参照してください。

    テクノロジー管理オファリング

    テクノロジーコンシューマーは、要求カタログを介して テクノロジー管理オファリング (TMO) を要求できます。カタログについては、 サービスカタログを参照してください。コンシューマーは通常、次の機能とオプションを選択できます。
    • パフォーマンスのレベル
    • 場所または地域
    • 環境
    • 価格設定
    • 利用できる場所
    • 機能
    • サポートグループ (インシデント用)
    • テクニカル承認グループ (変更用)
    • パッケージオプション (コミットメント)
    ヒント:
    動的 CI グループを使用して、管理を大幅に改善します。詳細については、「テクノロジー管理オファリングのユーザーグループの同期」を参照してください。
    テクノロジー管理オファリング 通常、次のコンポーネントがあります。
    1 つ以上のサービスコミットメント
    サービスコミットメントは、コンシューマーとプロバイダーの間で合意されたサービスデリバリーの義務を定義します。サービスコミットメントは、可用性、重要度、スコープ、価格、その他の要素に関してサービスのレベルを一意に定義します。たとえば、組織では、サービスインスタンスに対して次の 2 つのレベルのサポートを提供できます。
    • 本番レベルオファリングのサポート:本番インスタンスの高レベルの可用性と重要度を提供します。24 時間、週 7 日の 5 分間の応答時間の保証が含まれています。
    • 非本番レベルオファリングのサポート:非本番インスタンスの制限された可用性と重要度。月曜日から金曜日の午前 8 時から午後 5 時までの 60 分間の応答時間の保証が含まれています。
    オファリングにアクセスできるユーザーを記録するサービスオファリングサブスクリプション

    テクノロジー管理オファリングは、サービステーブルのサービスカテゴリ化属性を参照して、テクノロジー管理オファリングまたはオファリングがビジネスサービスに関連するか、技術管理サービスに関連するかを示します。[service_offering] テーブルにマッピングされているテクノロジー管理オファリングは「技術管理サービス」として分類され、サービスから派生します。テクノロジー管理オファリングは、親が特定の技術的ニーズにどのように対応するかに基づいています。すべての 技術管理サービス に少なくとも 1 つの テクノロジー管理オファリングが必要です。

    重要:
    ダイナミック CI グループを介して関連付けられた各 CI は、1 つの 技術管理サービス または テクノロジー管理オファリングにのみ関連付けることができます。1 つのサービスに SLA、OLA、サポートグループ、およびコミットメントが異なる複数のオファリングが含まれる場合には、競合が発生する可能性があります。

    ダイナミック CI グループ

    ダイナミック CI グループは、CMDB グループクエリから生じる CI で構成されます。たとえば、「デトロイトのすべての Web サーバー」または「ムンバイのすべての Oracle データベース」の場所に基づいてダイナミック CI グループを作成することができます。
    注:
    ダイナミック CI グループには CI のみが含まれ、他の CI グループを含めることはできません。
    ダイナミック CI グループは [cmdb_ci_query_based_service] テーブルにマッピングされ、必要に応じてサービスインスタンスまたは 技術管理サービスのいずれかに分類されます。次の状況で、ダイナミック CI グループを使用できます。
    クエリベースのサービスインスタンス

    サービスマッピング はまだ有効になっていませんが、MyAppServiceProd に 12 のサーバーと 3 つのデータベースインスタンスがあります。サービスインスタンスとして、スプレッドシートを動的 CI グループに置き換えることができます。

    ダイナミック CI グループメソッドを使用してアプリケーションサービスを設定する」を参照してください。

    インフラストラクチャ CI の管理対象グループ
    デトロイトのWebサーバーは、DetroitRockCity テクノロジー管理オファリングによって管理されています。テクノロジー管理オファリング からインフラストラクチャ CI への関係を手動で作成する代わりに、ダイナミック CI グループを使用します。テクノロジー管理オファリング CI (DetroitRockCity) から動的 CI グループ (デトロイトの Web サーバー) への 1 つの関係性により、必要な可視化が得られます。
    CI のパッチを管理する方法
    変更管理 で、更新する必要があるダイナミック CI グループを選択し、ビジネスルールを使用して [影響を受ける CI] フィールドに自動入力できます。

    サービスインスタンス (CSDM v5 より前はアプリケーションサービスと呼ばれていました)

    サービスインスタンスは、以前はアプリケーションサービスと呼ばれていた [cmdb_ci_service_auto] のラベル変更です。

    アプリケーションサービスはまだ存在します。アプリケーションサービスの管理方法によっては、常に拡張テーブルとして存在していました。

    手動での作成またはサービスマッピングの場合は、マッピングされたアプリケーションサービスに移動します。

    タグベースの場合は、タグベースのアプリケーションサービステーブルに格納されます。テーブルがまだ存在し、アプリケーションサービスであり、アプリケーションサービスウィザードに移動してアプリケーションサービスを作成します。

    新しいタイプのサービスインスタンスは、[cmdb_ci_service_auto]の拡張です。
    • データサービスインスタンス [cmdb_ci_data_service_instance]
    • ネットワークサービスインスタンス [cmdb_ci_network_service_instance]
    • オペレーショナルプロセスサービスインスタンス [cmdb_ci_operational_process_service_instance]
    • 接続サービスインスタンス [cmdb_ci_connection_service_instance]
    • 施設サービスインスタンス [cmdb_ci_facility_service_instance]

    サービスインスタンス ( CSDM v5 より前はアプリケーションサービスと呼ばれていました) [cmdb_ci_service_auto] テーブルは、サービスインスタンスをサポートします。 サービスインスタンスは、サービスを提供するように構成されている、相互接続された一連のアプリケーションとホストです。サービスインスタンスは、展開されたシステムまたはアプリケーションスタックの論理表現です。サービスインスタンスを使用すると、サービスのマップと変更履歴を表示できます。たとえば、 イベント管理 アプリケーションは、サービスパフォーマンスを監視し、サービスインスタンスの健全性の問題を特定できます。

    サービスインスタンスは、組織のメールシステムのような内部向け、または組織の Web サイトのような顧客向けにすることができます。たとえば、Web ベースのアプリケーションで財務レポートを作成するにはコンピューター、Web サーバー、アプリケーションサーバー、データベース、ミドルウェア、ネットワークインフラストラクチャが必要です。アプリケーションとホストは、財務レポートサービスを提供するように構成されています。サービスインスタンスは、開発、テスト、または本番環境におけるそのようなビジネスアプリケーションまたはシステムのインスタンスを表します。

    サービスインスタンスは、 サービスマッピング 機能のエントリポイントです。サービスインスタンスはビジネスまたは技術管理サービスをサポートし、一般的なレポートのために [cmdb_ci_service_auto] テーブルCMDBサービスインスタンス ( CSDM v5 より前はアプリケーションサービスと呼ばれていました) [] テーブルにマッピングされます。

    サービスインスタンスは、 IT Service Management (ITSM)、 IT Operations Management (ITOM) (ITOM)、 戦略的ポートフォリオ管理 (SPM) (SPM)、および カスタマーサービス管理 (CSM)の主要な関係エンティティです。

    サービスインスタンスには、ビジネスアプリケーション、ビジネスサービス、 技術管理サービス、アプリケーション、およびインフラストラクチャ CI 間の関係が含まれます。関連するビジネスまたは テクノロジー管理オファリングを使用して、サービスインスタンスを公開できます。詳細については、「アプリケーションサービスダッシュボードを使用して健全性を監視する」を参照してください。

    サービスインスタンスデータモデル内のサービスインスタンスのタイプ:
    • データサービスインスタンス
    • ネットワークサービスインスタンス
    • オペレーショナルプロセスサービスインスタンス
    • 接続サービスインスタンス
    • 施設サービスインスタンス
    サービスインスタンスがマップされるテーブルは、作成に使用された方法によって異なります。
    表 : 1. テーブルにマッピングされた方法
    サービスインスタンスの作成に使用された方法 テーブルへのマッピング
    トップダウンディスカバリー (サービスマッピング) cmdb_ci_service_discovered
    ダイナミック CI グループ (クエリーベース) cmdb_ci_query_based_service
    タグ cmdb_ci_service_tags
    [サービスインスタンスを作成] フォーム (以前は [アプリケーションサービスを作成] フォーム) を使用した手動入力 cmdb_ci_service_discovered

    アプリケーション

    アプリケーションとは、動作を定義したり特定の機能を実行したりするプログラムまたはモジュールのことです。アプリケーションは通常、検出可能なインスタンスであり、1 つ以上のサービス用の特定の機能セットを提供します。

    • アプリケーションテーブルと拡張テーブルには、ホスト上で使用されている一意に検出されたコードのインスタンスが含まれています。
    • アプリケーションはインフラストラクチャ CI と見なされます。
    • インスタンスは、単一ホスト上のアプリケーションに制限されます。この制限により、ディスカバリー中にアプリケーションが一意に識別されます。
    • アプリケーションとサービスインスタンスの間には、1 対 1 ではなく 1 対多の関係があります。データベースインスタンスなどの単一のインストール済みアプリケーションは、アプリケーションの構成と用途に応じて、複数のサービスインスタンスをサポートする場合があります。
    注:
    アプリケーションテーブル [cmdb_ci_appl] は、アプリケーションのインベントリまたはポートフォリオではありません。管理対象アプリケーションの詳細を誤ってアプリケーションテーブルに格納しないでください。これらの詳細 (インベントリまたはアプリケーションポートフォリオオブジェクト) は、(CSDM モデルの設計および計画ドメイン に記載されているように) ビジネスアプリケーションテーブルに属します。

    インフラストラクチャ CI

    インフラストラクチャ CI は、管理対象の物理および論理コンポーネントです。CI は、サーバー、データベース、ルーターなどの単一のモジュールの場合もあれば、完全システム (Web サーバー、データベース、インフラストラクチャなど) の場合もあります。

    基盤となるインフラストラクチャコンポーネントまたは CI は複雑になる可能性があります。物理 CI 上にデータ構造が階層化されると、複雑さが増します。そのため、事業関係マネージャーまたはエンタープライズアーキテクトと協力して、ご利用のビジネス機能とビジネスアプリケーションを定義する必要があります。

    ServiceNow コミュニティ の CSDM に関するビデオ

    すべての CSDM ビデオの再生リスト