CMDB-CI-Lebenszyklusmanagement (veraltet)

Freigeben Version: Yokohama

Aktualisiert 30. Januar 2025

5 Minuten Lesedauer

Vom Zeitpunkt der Erstellung bis zu dem Zeitpunkt, zu dem es nicht mehr benötigt wird, durchläuft ein CMDB-CI normalerweise mehrere betriebsstatus, während er verschiedene Vorgänge durchläuft. Das CI-Lebenszyklusmanagement bietet den Mechanismus zum Definieren von status und Aktionen für ein CI und ermöglicht Ihnen, geeignete Aktionen basierend auf dem Status eines CI anzuwenden, um die Verwaltung des CI-Lebenszyklus an die Geschäftsanforderungen anzupassen.

Der CMDB-Datenmanager ist jetzt eine umfassendere und integrierte Lösung für die Massenverwaltung von CI-Lebenszyklusvorgängen wie Löschung und Archivierung. Informationen zum CMDB-Datenmanager finden Sie unter .

Begriffe, die dem CI-Lebenszyklusmanagement zugeordnet sind:

betriebsstatus: Eine Reihe von status, in denen sich ein CI befinden kann, z. B. „betriebsbereit“ oder „Reparatur in Bearbeitung“. Ein CI kann jeweils nur einem einzelnen Betriebsstatus zugeordnet werden. Die Auswahlmöglichkeiten für betriebsstatus basieren auf operational_statusFeld in der Tabelle [cmdb_ci]. Im Basissystem sind mehrere betriebsstatus definiert, z. B. „stillgelegt“ und „Reparatur in Bearbeitung“. Sie können diese Liste ändern, um betriebsstatus widerzuspiegeln, die für Ihr Unternehmen relevant sind.
Hinweis:
Standardmäßig Service-MappingIst so konfiguriert, dass alle Host-CIs ignoriert werden, für die der Wert des Betriebsstatus gilt [operational_status]Ist nicht 1 (Betriebsbereit) oder der Wert des Status [install_status]Ist 100 (Abwesend). Weitere Informationen zu diesem Verhalten finden Sie unter Anwenderdefinierte ServiceNow-Bereitstellungen werden für die Arbeit mit der Servicezuordnung vorbereitet [KB0647574] in der HI-Knowledge Base.
Mit dem CI-Lebenszyklusmanagement können mehrere Operatoren und Automatisierungen gleichzeitig verschiedene betriebsstatus eines CI festlegen. Da ein CI nicht mehreren betriebsstatus zugeordnet werden kann, ist es wichtig, jeden Betriebsstatus mit einer Priorität zu konfigurieren. Diese Prioritäten werden dann in einer solchen Situation verwendet, um zu bestimmen, welcher der betriebsstatus der kumulative Betriebsstatus ist.
CI-Aktionen: Eine Reihe von Aktionen, die während seiner Lebensdauer auf ein CI angewendet werden können. Sie können CI-Aktionen definieren, die für Ihr Unternehmen relevant sind.
Kompatible CI-Aktionen: Das CI-Lebenszyklusmanagement ermöglicht es einem CI, mehrere aktive CI-Aktionen gleichzeitig zu haben, muss jedoch speziell als kompatibel definiert werden. Standardmäßig gibt es keine zwei Aktionen für ein CI, die miteinander kompatibel sind. Sie können dieses Verhalten ändern, indem Sie Aktionspaare angeben, die kompatibel sind und daher gleichzeitig auf ein CI angewendet werden dürfen. Sie können beispielsweise angeben, dass die CI-Aktionen „Patching“ und „Bereitstellung“ kompatibel sind, sodass beide gleichzeitig auf ein CI angewendet werden können.
Unzulässige CI-Aktionen: Standardmäßig kann jede CI-Aktion auf jedes CI angewendet werden. Sie können dieses Verhalten einschränken, indem Sie eine Regel definieren, dass eine Aktion für ein CI nicht zulässig ist, wenn es sich in einem bestimmten Betriebsstatus befindet. Sie können beispielsweise eine nicht zulässige CI-Aktion definieren, in der die Aktion „Bereitstellung“ nicht auf einen Linux-Server angewendet werden darf, der sich im Status „nicht betriebsbereit“ befindet.
Unzulässige betriebliche Übergänge: Standardmäßig sind Übergänge von einem beliebigen Betriebsstatus in einen anderen zulässig. Sie können dieses Verhalten einschränken, indem Sie eine Regel definieren, die für ein angegebenes CI ein Übergang von einem bestimmten Betriebsstatus zu einem anderen Betriebsstatus nicht zulässig ist. Sie können beispielsweise definieren, dass für einen Linux-Server der Übergang von „Reparatur in Bearbeitung“ zu „nicht funktionsfähig“ nicht zulässig ist.
Anforderer: Eine anfordernde Person kann ein Workflow oder ein nicht-Workflow-Operator sein, der versucht, betriebsstatus festzulegen und CI-Aktionen anzuwenden. Jeder anfordernden Person ist eine anfordernde ID zugeordnet, die eine GUID ist und ein aktiver Workflow-Kontext oder eine nicht-Workflow-registrierte Operator-ID sein kann.
Lease-Zeit: Ein Zeitraum, den jede anfordernde Person (insbesondere nicht-Workflow-Operatoren) angeben kann, in dem eine angegebene CI-Aktion für ein angegebenes CI aktiv sein darf.

CMDB-CI-Lebenszyklusmanagement bietet eine Reihe von APIs zum Verwalten von CI-betriebsstatus und CI-Aktionen. Und die UI, in der Sie eine Reihe von Regeln definieren, um bestimmte Betriebsstatusübergänge einzuschränken und Aktionen basierend auf betriebsstatus einzuschränken. Es bietet auch einen Mechanismus zum Audit des CI-Betriebsstatus und der CI-Aktionen während des gesamten CI-Lebenszyklus.

Anbieter wie Automatisierung, Workflows oder Change-Management können CI-Lebenszyklusmanagement als Mechanismus verwenden, um CI-betriebsstatus zu verwalten und CI-Aktionen anzuwenden. Standardmäßig hat das Verhalten von CI-Lebenszyklusmanagement keine Einschränkungen für einige Vorgänge und vollständige Einschränkungen für andere Vorgänge. Mit der UI „CI-Lebenszyklusmanagement“ können Sie dieses Standardverhalten ändern, indem Sie nicht zulässige CI-Aktionen, kompatible CI-Aktionen und nicht zulässige Betriebsübergänge angeben, die einige Vorgänge einschränken und für andere aktivieren.

Mit CI-Lebenszyklusmanagement können Sie:

Verwalten Sie CI-betriebsstatus und CI-Aktionen während des gesamten CI-Lebenszyklus.
Verwalten Sie CI-Betriebsstatusübergänge.
Schränken Sie bestimmte Betriebsstatusübergänge ein.
Ordnen Sie bestimmte Aktionen für bestimmte CI-Typen zu, die sich in einem bestimmten Betriebsstatus befinden.
Beschränken Sie IT-Servicemanagement-Anwendungen basierend auf dem CI-Betriebsstatus.
Audit-CI-betriebsstatus und CI-Aktionen während des gesamten CI-Lebenszyklus.

Lebenszyklusmanagement-APIs

CI-Lebenszyklusmanagement bietet eine Reihe von APIs zur Verwaltung des CI-Betriebsstatus und CI-Aktionen während des gesamten CI-Lebenszyklus. Alle durch Regeln in der Anwenderoberfläche angegebenen Einschränkungen und Berechtigungen werden erzwungen, wenn Statusverwaltungs-APIs ausgeführt werden. Wenn eine API versucht, einen eingeschränkten Vorgang auszuführen, wird der Vorgang blockiert und ein Fehler protokolliert.

Anfordernde Personen werden registriert

Wenn die Lebenszyklusmanagement-APIs zum Anwenden von CI-Aktionen verwendet werden, müssen Anforderer registriert sein und eine Anforderer-ID erhalten, die innerhalb der Lebenszyklusverwaltungstabellen eindeutig ist. Um sich zu registrieren und eine Anforderer-ID zu erhalten, sollten nicht-Workflow-Anwender anrufen registerOperatorAPI. Workflow-Anwender können den aktiven Workflow-Kontext als Anforderer-ID verwenden und müssen nicht explizit aufrufen RegisterOperator .

Nach Abschluss der CI-Lebenszyklusvorgänge sollte die anfordernde Person aufrufen Heben Sie die Registrierung des Operators auf API zum Aufheben der Registrierung. Alle Statusverwaltungsdatensätze, die dieser spezifischen Anforderer-ID zugeordnet sind, werden dann als inaktiv markiert oder von entfernt CI Lifecycle Management — Restore Internal State Management TablesGeplante Aufgabe.

Integration mit Incident-ManagementUnd Problem-Management

Eine Basisinstanz enthält die vordefinierte CI-Aktion CreateTaskWird zum Erstellen einer Aufgabe für ein CI verwendet. Neue Instanzen haben eine vordefinierte nicht zulässige CI-Aktion, die angibt, dass die Aktion „CreateTask“ für kein CI mit zulässig ist Stillgelegt Betriebsstatus. Diese Einschränkung ist in integriert Incident-ManagementUnd mit Problem-ManagementUm die Erstellung von Incident- oder Problemaufgaben für stillgelegte CIs zu verhindern. Die CI-Aktion „CreateTask“ wird als Referenzqualifizierer für verwendet Configuration ItemFeld der Incident-/Problem-Tabellen. In einem neuen Incident oder Problem, CIs in denen Operational StatusIst „stillgelegt“ – werden aus herausgefiltert Configuration ItemListe im Formular. Weitere Informationen zu Referenzqualifizierern finden Sie unter Referenzqualifizierer .

Integration mit Asset-Management

In einem Basissystem ein CI Operational StatusFeld und Status/ Hardware Status(Bei Hardware) Felder werden synchronisiert, wenn eines der Werte der beiden Felder ist Stillgelegt . Wann Operational StatusEines CI ist auf festgelegt Stillgelegt , Dann Status/ Hardware StatusFeld wird automatisch auf festgelegt Stillgelegt . In die entgegengesetzte Richtung, wenn Status/ Hardware StatusFeld eines CI ist auf festgelegt Stillgelegt , Operational StatusIst automatisch auf festgelegt Stillgelegt Auch.

Wenn ein Operational StatusFeld ändert sich von Stillgelegt Zu einem anderen Status, den CIs Status/ Hardware StatusFeld ist auf festgelegt Installiert .
Wenn ein CI ist Status/ Hardware StatusFeld ändert sich von Stillgelegt Zu einem anderen Status, zu Operational StatusFeld wird automatisch auf festgelegt Nicht Funktionsfähig .

Die Statusänderung von „stillgelegt“ in einen anderen Status ist selten, und standardmäßig wird der Status in „nicht funktionsfähig“ geändert. Dies ist jedoch möglicherweise nicht der beabsichtigte Status für den Datensatz. Daher ist es wichtig, dass Administratoren den Status in diesem Fall ordnungsgemäß überprüfen und verwalten.

Immer CIs Status/ Hardware StatusÄndert sich, wird mit den entsprechenden CIs synchronisiert Asset StateFeld und umgekehrt: Beibehaltung der CIs Operational StatusUnd die entsprechenden CIs Asset StateSynchronisiert.

Für weitere Informationen zur Zuordnung Asset StateUnd SubstateFelder für CIs Status/ Hardware StatusFeld (falls Hardware), siehe Ordnen Sie den Asset-Status und den CI-Hardwarestatus zu . Weitere Informationen zum Stilllegen von Assets finden Sie unter Assets stilllegen .