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

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

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

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

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

    • テクノロジー 管理サービス (旧テクニカルサービス)[cmdb_ci_service_technical] テーブル。サービスの分類はテクニカルサービスです。
    • テクノロジー 管理オファリング (旧称テクニカルサービスオファリング)[service_offering] テーブル。サービスの分類はテクニカルサービスです。
    • カタログを要求します。 テクノロジー コンシューマーは、要求カタログを通じて テクノロジー 管理オファリング を要求できます。カタログについては「サービスカタログ」で詳しく説明されています。
    • ダイナミック CI グループ [cmdb_ci_query_based_service] テーブル。サービスの分類はテクニカルサービスです。イベント管理テクノロジー 管理サービスcmdb_ci_query_based_serviceテーブルを使用します。
    • サービスインスタンス (以前のアプリケーションサービス) [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 Agile 開発コンポーネント (このアイテムを使用するにはオプション)。
    • サービスインスタンス別のビジネスアプリケーション Consumes::Consumed
    • サービスインスタンス (展開されたシステムまたはアプリケーションスタックの論理表現)Depends on::Used by /Sends Data To:: サービスインスタンス。
    • アプリケーション Depends on::Used by サービスインスタンス。
    • アプリケーション Runs on::Runs インフラストラクチャ CI。
    • テクノロジー 管理サービス は参照属性を使用してインフラストラクチャ テクノロジー 管理オファリングとの関係を指定します。サービスオーナーに公開され、通常は 1 つ以上のビジネスサービスをサポートします。テクノロジー 管理サービスには、1 つ以上のテクノロジー 管理オファリングで構成される運用ビューがあります。
    • テクノロジー 管理オファリング Contains::Contained by サービスインスタンス。テクニカルサービスを、ローカリゼーション/地域、環境、価格設定、可用性、機能、サポートグループ (INCIDENT)、テクニカル承認グループ (CHANGE)、パッケージングオプションなどのオプションに階層化します。
    • テクノロジー 管理オファリング 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 データの管理を支援するために、API データモデルが CMDB 内で利用できるようになります。API インサイトの一環として、API の詳細の表示、AP の比較、データギャップの特定と解決、サービス関係の管理など、AP の管理を一元化できます (これらに限定されません)。API 関数:仮想の視点から。API アプリケーション:オンプレミスの観点から。

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

    Al アプリケーション: LinuxWindowsDocker コンテナー、 Kubernetes (K8) クラスターなどのさまざまなプラットフォームで実行できる Al ソフトウェアアプリケーション。これらのプラットフォームは、機械学習モデル、データ分析、インテリジェント サービスや Al 対応アプリケーションなど、多様な 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 グループを選択し、ビジネスルールを使用して [影響を受ける CI] フィールドに自動入力できます。

    サービスインスタンス (旧称アプリケーションサービス)

    サービスインスタンスは、[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]

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

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

    サービスインスタンスは、サービスマッピング機能のエントリーポイントです。サービスインスタンスは、ビジネスサービスまたはテクノロジー 管理サービスをサポートし、一般的なレポート用に CMDB サービスインスタンス [cmdb_ci_service_auto] テーブル (旧称アプリケーションサービステーブル) にマッピングされます。

    サービスインスタンスは、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
    [サービスインスタンスを作成 (Create a Service Instance)] フォーム (旧称 [アプリケーションサービスを作成] フォーム) を使用した手動入力 cmdb_ci_service_discovered

    アプリケーション

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

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

    インフラストラクチャ CI

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

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

    CSDM のビデオ ServiceNow コミュニティ

    すべてのプレイリスト CSDM ビデオ