CSDMフレームワークの技術管理サービスドメインの管理

  • リリースバージョン: Yokohama
  • 更新日 2025年01月30日
  • 所要時間:11分
  • [技術管理サービスの管理] ドメインサービスマッピングディスカバリー などのIT Operations Management (ITOM) (ITOM) 製品で使用されるテーブルが含まれます。これらは、デジタル製品の展開済みインスタンスと、それに関連する検出可能なコンポーネント、および展開済みインスタンスを提供しサポートするサービスのドキュメントです。

    このドメインの CI は、インストールされているアプリケーション、サーバー、ネットワークコンポーネントなどの検出されたアイテムです。[技術管理サービスの管理] ドメインは、使用中の 技術管理サービス ポートフォリオも表します。これらのサービスは操作可能です。つまり、ITSM インシデント管理問題管理、または 変更管理 用に選択できます。

    一般的なユーザーは、サービスインスタンスオーナー (アプリケーションとプラットフォーム) とテクノロジーサービスオーナー (インフラストラクチャとデリバリー) です。テクノロジーコンシューマーは、要求カタログを通じて テクニカルサービスオファリング を要求できます。カタログについては、 サービスカタログで詳しく説明しています。

    技術管理サービスの管理ドメイン。

    [テクノロジー管理サービスの管理] ドメインのテーブルは 会社が販売しているか、プロバイダービューで消費しているテクノロジーを表します。 サービスマッピングディスカバリー がテーブルに入力されます。また、CI とその関係を管理することもできます。これらの製品はプロセスを迅速化し、エラーを最小限に抑えますが、使用する必要はありません。このドメインには以下のテーブルが含まれます。

    • 技術管理サービス [cmdb_ci_service_technical] テーブル (以前のテクニカルサービス)
    • テクニカルサービスオファリング [service_offering] テーブル
    • カタログを要求します。
    • ダイナミック CI グループ [cmdb_ci_query_based_service] テーブル。技術管理サービスイベント管理cmdb_ci_query_based_serviceテーブルを使用します。
    • マップ済みアプリケーションサービス [cmdb_ci_service_discovered] テーブル ( ベースシステムに含まれる)

    技術管理サービス

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

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

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

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

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

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

    テクノロジー管理オファリングは、テクノロジー管理オファリングまたはオファリングがビジネスサービスに関連しているか、テクノロジー管理サービスに関連しているかを示すために、サービステーブルの [サービスカテゴリ化 (Service Categorization )] 属性を参照します。[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] フィールドに自動入力できます。

    サービスインスタンス (以前のアプリケーションサービス)

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

    アプリケーション

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

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

    インフラストラクチャ CI

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

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

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

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