CMDB CI-Lebenszyklusmanagement (veraltet)

Freigeben Version: Zurich

Aktualisiert 31. Juli 2025

6 Minuten Lesedauer

Vom Zeitpunkt der Erstellung eines CMDB-CI bis zum Zeitpunkt, zu dem es nicht mehr benötigt wird, würde ein CMDB-CI normalerweise verschiedene Betriebsstatus durchlaufen, während verschiedene Vorgänge ausgeführt werden. Das CI-Lifecycle-Management stellt den Mechanismus zum Definieren von Status und Aktionen für ein CI bereit und ermöglicht Ihnen, basierend auf dem CI-Status geeignete Aktionen anzuwenden, um die Verwaltung des CI-Lifecycle an die geschäftlichen Anforderungen 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 Arbeiten mit CMDB-Datenmanager.

Mit CI-Lifecycle-Management verknüpfte Begriffe:

Betriebsstatus: Eine Reihe von Zuständen, in die ein CI gesetzt werden kann, z. B. „Operativ“ oder „Reparatur wird ausgeführt“. Ein CI kann jeweils nur einem Betriebsstatus zugeordnet werden. Die Auswahlmöglichkeiten für betriebsstatus basieren auf operational_statusFeld in der Tabelle [cmdb_ci]. Es gibt mehrere Betriebsstatus, die im Basissystem definiert sind, wie z. B. „Stillgelegt“ und „Wird gerade repariert“. Sie können diese Liste ändern, um Betriebsstatus anzuzeigen, die für Ihr Unternehmen relevant sind.
Hinweis:
Standardmäßig Service-Mapping Ist so konfiguriert, dass alle Host-CIs ignoriert werden, für die der Wert des Betriebsstatus gilt [operational_status]Ist nicht 1 (Operativ) oder der Wert des Status [install_status]Ist 100 (Abwesend). Weitere Informationen zu diesem Verhalten finden Sie unter Vorbereiten von angepassten ServiceNow-Bereitstellungen für die Zusammenarbeit mit Service Mapping [KB0647574] in der HI-Wissensdatenbank.
Mit dem CI-Lifecycle-Management können mehrere Bediener und Automatisierungen gleichzeitig verschiedene Betriebsstatus einer CI einstellen. Da einem CI nicht mehrere Betriebsstatus zugeordnet werden können, 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 kumulierte Betriebsstatus ist.
CI-Aktionen: Eine Reihe von Aktionen, die während der Laufzeit auf ein CI angewendet werden können. Sie können für Ihr Business relevante CI-Aktionen definieren.
Kompatible CI-Aktionen: CI Lifecycle Management ermöglicht es einem CI, mehrere aktive CI-Aktionen gleichzeitig auszuführen, sie müssen jedoch ausdrücklich 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 bestimmtes CI den Übergang von einem bestimmten Betriebsstatus in einen anderen Betriebsstatus nicht zulässt. 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 ID einer anfordernden Person zugeordnet, bei der es sich um eine GUID handelt. Dies kann ein aktiver Workflow-Kontext oder eine nicht als Workflow registrierte Benutzer-ID sein.
Mietzeitraum: Ein Zeitraum, den jede anfordernde Person (insbesondere Nicht-Workflow-Operatoren) angeben kann, während dem eine angegebene CI-Aktion für ein bestimmtes CI aktiv sein darf.

CMDB CI Lifecycle Management bietet eine Reihe von APIs zum Verwalten von CI-Betriebsstatus und CI-Aktionen. Und die Benutzeroberfläche, in der Sie Regeln definieren, um bestimmte Betriebsstatusübergänge einzuschränken und Aktionen basierend auf Betriebsstatus zu beschränken. Es bietet auch einen Mechanismus zum Auditieren des CI-Betriebsstatus und der CI-Aktionen während des gesamten CI-Lebenszyklus.

Anbieter wie Automatisierung, Workflows oder Change Management können CI Lifecycle Management als Mechanismus zum Verwalten von CI-Betriebsstatus und zum Anwenden von CI-Aktionen verwenden. Standardmäßig hat das Verhalten von CI Lifecycle Management keine Einschränkungen für bestimmte Vorgänge und vollständige Einschränkungen für andere Vorgänge. Mit der Benutzeroberfläche von CI Lifecycle Management 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 Lifecycle Management können Sie:

CI-Betriebsstatus und CI-Aktionen während des gesamten CI-Lebenszyklus verwalten.
CI-Betriebsstatusübergänge verwalten.
Bestimmte Betriebsstatusübergänge beschränken.
Bestimmte Aktionen für bestimmte CI-Typen zuordnen, die sich in einem bestimmten Betriebsstatus befinden.
IT Service Management-Anwendungen basierend auf dem CI-Betriebsstatus beschränken.
CI-Betriebsstatus und CI-Aktionen während des gesamten CI-Lebenszyklus überwachen.

Lifecycle Management-APIs

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

Anfordernde Personen registrieren

Wenn Sie die Lifecycle Management-APIs zur Anwendung von CI-Aktionen verwenden, müssen anfordernde Personen registriert werden und eine ID für eine anfordernde Person anfordern, die innerhalb der Lifecycle Management-Tabellen eindeutig ist. Um sich zu registrieren und eine Anforderer-ID zu erhalten, sollten nicht-Workflow-Anwender den anrufen registerOperatorAPI. Workflow-Benutzer können den aktiven Workflow-Kontext als ID der anfordernden Person verwenden und müssen nicht explizit registerOperator aufrufen.

Nach Abschluss der CI-Lebenszyklusvorgänge sollte die anfordernde Person die API unregisterOperator aufrufen, um die Registrierung aufzuheben. Alle Statusverwaltungsdatensätze, die dieser bestimmten ID einer anfordernden Person zugeordnet sind, werden dann als inaktiv markiert oder vom Scheduled Job CI Lifecycle Management — Restore Internal State Management Tables entfernt.

Integration mit Incident-Management und 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 mit Incident-Management und Problem-Management integriert, um die Erstellung von Incident- oder Problemaufgaben für deaktivierte 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 CIs Operational StatusFeld und Status/ Hardware Status(Bei Hardware) Felder werden synchronisiert, wenn eines der Werte der beiden Felder ist Stillgelegt . Wenn Operational StatusVon einem 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 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, der Operational StatusFeld wird automatisch auf festgelegt Nicht Funktionsfähig .

Der Status von „stillgelegt“ in einen anderen Status wird selten geändert, 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 entsprechend überprüfen und verwalten.

Immer CIs Status/ Hardware StatusÄndert sich, wird es mit den entsprechenden CIs synchronisiert Asset StateFeld und umgekehrt – Beibehalten 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 .