CMDB CI ライフサイクル管理 (従来)

  • リリースバージョン: Washingtondc
  • 更新日 2024年02月01日
  • 読む8読むのに数分

    • 作成時から不要になった時点まで、CMDB CI は通常、さまざまな操作を実行しながらいくつかの運用ステータスに移行します。CI ライフサイクル管理は、CI の状態とアクションを定義するメカニズムを提供し、CI の状態に基づいて適切なアクションを適用して、CI ライフサイクルの管理をビジネス ニーズに合わせることができます。

    CMDB データマネージャーは、削除やアーカイブなどの CI ライフサイクル操作を一括で管理するための、より包括的な統合ソリューションになりました。CMDB データマネージャーの詳細については、「の操作 CMDB データマネージャー」を参照してください。

    CI ライフサイクル管理に関連する用語：
    運用ステータス
    CI が「稼働中」や「修理中」などになることができる一連の状態。CI は、任意の時点で単一の運用ステータスにのみ関連付けることができます。運用ステータスの選択肢は、[cmdb_ci] テーブルの operational_status フィールドに基づきます。ベース システムで定義されている運用ステータスは、「廃止」や「修理中」など複数あります。このリストを変更して、ビジネスに関連する運用ステータスを反映させることができます。
    注:
    デフォルトでは、Service Mapping は、運用ステータス [operational_status] の値が 1 (稼働中) でないか、ステータス [install_status] の値が 100 (記録不明) である場合、すべてのホスト CI を無視するように設定されています。この動作の関連情報については、HI ナレッジベースの「サービスマッピングと連携させるためにカスタマイズされた ServiceNow デプロイメントを準備する」[KB0647574] を参照してください。
    CI ライフサイクル管理では、複数のオペレーターおよび自動化により、CI の異なる運用ステータスを同時に設定できます。CI を複数の運用ステータスに関連付けることができないため、各運用ステータスに優先度を設定することが重要です。そのような状況では、これらの優先度を使用して、どの運用ステータスが累積運用ステータスであるかを決定します。
    CI アクション
    CI のライフタイム中に CI に適用できる一連のアクション。ビジネスに関連する CI アクションを定義できます。
    互換 CI アクション
    CI ライフサイクル管理では、CI が複数の有効な CI アクションを同時に持つことができますが、互換性があると明確に定義されている必要があります。デフォルトでは、相互に互換性のある CI の 2 つのアクションはありません。この動作を変更するには、互換性があり、同時に CI に適用できるアクションのペアを指定します。たとえば、「パッチ適用」と「プロビジョニング」の CI アクションに互換性があることを指定すると、両方を同時に CI に適用することができます。
    許可されていない CI アクション
    デフォルトでは、任意の CI アクションを任意の CI に適用できます。この動作を制限するには、CI が特定の運用ステータスにあるときにアクションが許可されないというルールを定義します。たとえば、「非稼働」状態の Linux サーバーに「プロビジョニング」アクションを適用することができない、「許可されていない CI アクション」を定義することができます。
    許可されていない運用上の移行
    デフォルトでは、運用ステータスから別のステータスへの移行は許可されます。この動作を制限するには、指定された CI に対して、特定の運用ステータスから別の運用ステータスへの移行が許可されないというルールを定義します。たとえば、Linux サーバーについて「修理中」から「非稼働」に移行できないように定義できます。
    リクエスタ
    要求者は、運用ステータスを設定し、CI アクションを適用しようとするワークフローまたは非ワークフローのオペレーターになることができます。各要求者には、GUID であり、有効なワークフロー コンテキストまたは非ワークフローの登録済みオペレーター ID になることができる関連要求者 ID があります。
    リース時間
    指定された CI に対して指定された CI アクションを有効にすることができる、各要求者 (特に非ワークフロー オペレーター) が提供できる期間。

    CMDB CI ライフサイクル管理には、CI 運用ステータスと CI アクションを管理するための一連の API が用意されています。また、UI では、特定の運用ステータスの移行を制限し、運用ステータスに基づいてアクションを制限する一連のルールを定義することができます。また、CI ライフサイクル全体で CI の運用ステータスと CI アクションを監査するメカニズムも提供します。

    自動化、ワークフロー、または変更管理などのプロバイダーは、CI の運用ステータスを管理し、CI のアクションを適用するためのメカニズムとして CI ライフサイクル管理を使用できます。デフォルトでは、CI ライフサイクル管理の動作は、一部の操作に対して制限がなく、他の操作に対しては完全な制限があります。CI ライフサイクル管理 UI では、一部の操作を制限し、その他の操作を可能にする、許可されていない CI アクション、互換 CI アクション、および許可されていない運用上の移行を指定することによって、このデフォルトの動作を変更できます。

    CI ライフサイクル管理では、次のことが可能です。
    • CI ライフサイクル全体を通じて、CI 運用ステータスと CI アクションを管理する。
    • CI 運用ステータスの移行を管理する。
    • 特定の運用ステータスの移行を制限する。
    • 特定の運用ステータスにある特定の CI タイプに対して特定のアクションを関連付ける。
    • CI 運用ステータスに基づいて IT Service Management アプリケーションを制限する。
    • CI ライフサイクル全体で CI 運用ステータスと CI アクションを監査する。

    ライフサイクル管理 API

    CI ライフサイクル管理には、CI ライフサイクル全体で CI 運用ステータスと CI アクションを管理するための一連の API が用意されています。UI のルールで指定されたすべての制限および許可は、状態管理 API が実行されるときに強制され、API が制限付き操作を実行しようとすると、操作はブロックされ、エラーが記録されます。

    要求者の登録

    ライフサイクル管理 API を使用して CI アクションを適用する場合、要求者を登録し、ライフサイクル管理テーブル内で一意の要求者 ID を取得する必要があります。登録して要求者 ID を取得するには、非ワークフローユーザーは registerOperator API を呼び出す必要があります。ワークフロー ユーザーは、有効なワークフロー コンテキストを要求者 ID として使用でき、registerOperator を明示的に呼び出す必要がありません。

    CI ライフサイクル運用が完了したら、要求者は unregisterOperator API を呼び出して登録を解除する必要があります。特定の要求者 ID に関連付けられているすべての状態管理レコードは、非アクティブとしてマークされるか、[CI Lifecycle Management — Restore Internal State Management Tables] スケジュール設定済みジョブによって削除されます。

    インシデント管理と問題管理との統合

    ベースインスタンスには、CI のタスクを作成するために使用される、事前定義された CI アクション CreateTask が含まれます。新しいインスタンスには、事前定義された許可されていない CI アクションがあり、[CreateTask] アクションが [廃止] 運用ステータスの CI で許可されないことが指定されています。この制限は、インシデント管理および問題管理と統合され、廃止された CI のインシデントまたは問題タスクの作成を防ぎます。[CreateTask] CI アクションは、インシデント/問題テーブルの [Configuration Item] フィールドへの参照修飾子として使用されます。新たなインシデントや問題では、[Operational Status] が [廃止] の CI はフォームの [Configuration Item] リストから除外されます。参照修飾子の詳細については、「参照修飾子」を参照してください。

    統合： 資産管理

    ベースシステムでは、CI の [Operational Status] フィールドと [Status]/[Hardware Status] (ハードウェアの場合) フィールドは、2 つのフィールド値のいずれかが [廃止] である場合、同期されたままになります。CI の [Operational Status] が [廃止] に設定されると、[Status]/[Hardware Status] フィールドは自動的に [廃止] に設定されます。反対に、CI の [Status]/[Hardware Status] フィールドが [廃止] に設定されると、[Operational Status] も自動的に [廃止] に設定されます。
    • [Operational Status] フィールドが [廃止] から別のステータスに変わると、CI の [Status]/[Hardware Status] フィールドは [インストール済み] に設定されます。

    • また、CI の [Status]/[Hardware Status] フィールドが [廃止] から別のステータスに変わると、[Operational Status] フィールドは自動的に [非稼働] に設定されます。

      [廃止] から別のステータスへのステータス変更はほとんど行われません。デフォルトでは、ステータスは [非稼働] に変更されます。ただし、これは意図したレコードステータスではない可能性があります。したがって、このような場合は、管理者がステータスを確認して適切に管理することが重要です。

    CI の [Status]/[Hardware Status] が変更すると、CI の対応する [Asset State] フィールドに同期され、反対も同様になります。CI の [Operational Status] および CI の対応する [Asset State] が同期され続けます。

    [Asset State] および [Substate] フィールドから CI の [Status]/[Hardware Status] (ハードウェアの場合) フィールドへのマッピングの詳細については、「資産状態と CI ハードウェアステータスをマッピングする」を参照してください。廃止資産の詳細については、「資産の廃止」を参照してください。