Änderungs- und Konfigurationsmanagement: die Unterschiede

Was ist Änderungsmanagement?

IT-Betriebsteams müssen kontinuierlich dafür sorgen, dass Systeme am Laufen bleiben. Dabei ist es wichtig, dass sie jede Änderung – absichtlich oder unabsichtlich – kennen. Genau hier spielt das Änderungsmanagement seine Vorzüge aus.

Change-Management bezeichnet eine Reihe standardisierter Methoden und Verfahren, um Änderungen an der IT-Infrastruktur zu überwachen, nachzuvollziehen und eventuelle negative Auswirkungen zu minimieren. Idealerweise können von vornherein nur autorisierte Personen Änderungen an einem Objekt vornehmen. Jeder Eingriff in die Infrastruktur birgt ein Risiko für Systemfehler oder Serviceprobleme– daher stellt das Change-Management sicher, dass alle Änderungen gut geplant und ausgeführt werden. Zwei typische Anwendungsfälle für Change-Management sind beispielsweise:

• System-Patches. Anwender und Administratoren müssen über einen Patch zumindest informiert sein, um negative Konsequenzen abfangen zu können. Nicht jede überarbeitete Softwareversion kann ausführlich getestet werden. Ein Beispiel dafür wäre ein Hotfix, der eine akute Sicherheitslücke
• Ungeplante Änderungen. Administratoren müssen öfter spontan Anpassungen am System vornehmen, zum Beispiel, indem sie einen ausgefallenen Server neu starten. Diese Aktionen durchlaufen nicht den üblichen Änderungsmanagement-Prozess, und Details werden möglicherweise nachgetragen.

Was ist Konfigurationsmanagement?

Konfigurationsmanagement ist ein bisschen schwieriger zu definieren. Ursprünglich in ITIL 2 eingeführt, wurde das Konfigurationsmanagement in ITIL 3 in Service Asset and Configuration Management umbenannt. Unabhängig von der Namensänderung ist die Idee dieselbe geblieben.

ITIL definiert drei allgemeine Komponenten des Konfigurationsmanagements:

• Konfigurationsmodell. Das Modell spezifiziert die Typen von Konfigurationselementen und bildet ab, welche Attribute die Managementplattform verfolgt und wie diese Elemente miteinander in Beziehung stehen.
• Konfigurationselemente. Eine einzelne Einheit innerhalb des Konfigurationsmodells mit zugehörigen Attributen und Beziehungen.
• Konfigurationsmanagementsystem. Der Satz von Werkzeugen, mit denen IT-Mitarbeiter Konfigurationselemente sowie deren Beziehungen speichern, verwalten und analysieren. Dies wird oft auch als Konfigurationsmanagement-Datenbank (CMDB) bezeichnet.

Zusammen erreichen diese drei Konzepte das Ziel des Konfigurationsmanagements: das Identifizieren, Aufzeichnen und Überprüfen aller Elemente eines IT-Systems – nicht nur der physischen Geräte – und der Beziehungen zwischen ihnen.

Unterschiede zwischen Änderungs- und Konfigurationsmanagement

Obwohl die beiden Bereiche ineinandergreifen, gibt es deutliche Unterschiede zwischen Änderungs- und Konfigurationsmanagement.

Änderungsmanagement ist der Prozess zum Verfolgen und Identifizieren von Änderungen, die innerhalb einer Umgebung auftreten. Dabei geht es im Allgemeinen darum, dass Administratoren sicherstellen, dass nur autorisierte Mitarbeiter Änderungen an einem Objekt vornehmen können; das reduziert Risiken und negative Auswirkungen.

Das Konfigurationsmanagement hingegen befasst sich damit, wie die Konfigurationselemente und ihre Beziehungen untereinander identifiziert, aufgezeichnet und verifiziert werden können.

Das Konfigurationsmanagement unterstützt das Änderungsmanagement durch das Auflisten der Assets und Systeme, die an einer Änderung beteiligt sind, aber es verfolgt nicht die Änderungen selbst. Es betrifft auch nicht die mit dieser Änderung verbundenen Risiken und Auswirkungen.

Überschneidungen von Änderungs- und Konfigurationsmanagement

Um wirklich zu verstehen, wie sich eine Änderung auf ein bestimmtes System auswirkt, benötigen Sie ein Konfigurationsmanagement. Wenn alle Konfigurationselemente und ihre Abhängigkeiten abgebildet sind, ist es einfacher aufzuschlüsseln, welche Auswirkung eine Änderung auf sie haben kann.

Nicht alle Konfigurationselemente sind direkt Teile der IT-Infrastruktur. Die Dokumentation kann ihrerseits ein Konfigurationselement sein: Wenn eine Änderung fehlschlägt, wollen Sie wissen, wer der Prozessverantwortliche ist und in welcher Dokumentation Sie Ihre Änderung hinzufügen.

Auf diese Weise beeinflussen die Informationen innerhalb eines Konfigurationselements, wie IT-Teams eine Änderung implementieren.

Betrachten wir zwei typische Beispiele, bei denen sich Änderungsmanagement und Konfigurationsmanagement überschneiden:

• Ein Team stellt eine Konfigurationsänderung in einer Produktionsumgebung bereit. Dieser Prozess muss den Änderungsmanagementprozess mit Genehmigungen und Tests durchlaufen, und erst dann wird die Konfigurationsaktualisierung des Codes in ein Produktionssystem implementiert und die entsprechenden Benachrichtigungen werden versendet.
• Eine Datenbankmigration von einem Server auf einen anderen umfasst das Änderungsmanagement der Analyse, Benachrichtigungen und Genehmigungen. Dies erfordert auch Aktualisierungen der CMDB und aller Konfigurationen, die sich auf die Nutzer des Dienstes auswirken können.

Beispiele für den Einsatz von Änderungs- und Konfigurationsmanagement im IT-Betrieb

Die folgenden Beispiele verdeutlichen, wie sich Änderungsmanagement und Konfigurationsmanagement ergänzen, aber auch, wie sie sich unterscheiden.

Ein Software-Update schlägt fehl. Ein neues Software-Update für die Migration zu TLS 1.2 wird für die Produktion freigegeben. Kurz darauf beschweren sich Anwender, dass sie E-Mails, die über die Software gesendet werden, nicht empfangen. Offensichtlich ist die neue Version der Software schuld – aber wo genau liegt das Problem?

Die CMDB verrät den IT-Administratoren, dass die betreffende Anwendung auf einen weiteren Dienst angewiesen ist, um E-Mails zu versenden. Laut Konfigurationselement verfügt dieser Dienst über eine Konfigurationsdatei. Ein Blick auf die übergebenen Änderungen in dieser zeigt, dass der Dienst keine Aktualisierung erhalten hat, so dass er nicht mit TLS 1.2 arbeiten kann.

Die Administratoren aktualisieren daraufhin die Konfigurationsdatei, so dass alle E-Mails in der Warteschlange gesendet werden. Die CMDB enthielt alle zugehörigen Abhängigkeiten und ermöglichte es, die Änderungsanforderung zu überprüfen, um festzustellen, ob der Bereitstellungsprozess korrekt befolgt wurde.

Versagen des monatlichen Aktualisierungsprozesses. Ein wichtiges Buchhaltungssystem wird monatlich neu gestartet, um Updates anzuwenden und den reibungslosen Betrieb des Systems sicherzustellen. Die Administratoren verwenden eine CMDB für die Dokumentation des Prozesses, den sie für einen Neustart des Systems befolgen müssen. Ein ordnungsgemäßer Neustart des Systems muss festgelegte Schritte in einer bestimmten Reihenfolge befolgen. Daher ist es wichtig, dass der Prozess genau definiert ist und eingehalten wird.

Nach dem letzten monatlichen Neustart nimmt die IT zusätzliche Änderungen vor, um ein neues Subsystem zu unterstützen. Beim Neustart im nächsten Monat booten mehrere Systeme nicht korrekt, obwohl der neue Prozess korrekt befolgt wurde. Der CMDB-Dokumentation entnimmt das IT-Team nun die Kontaktinformationen der Prozesseigentümer sowie der Person, die den Prozess zuletzt aktualisiert hat. Bei der Untersuchung stellt sich heraus, dass bei der Änderung für das neue Subsystem die vorhandenen Systeme, die zusätzliche Zeit für den Neustart benötigen, nicht berücksichtigt wurden.

Das IT-Betriebsteam fügt deshalb eine zusätzliche Wartezeit ein, damit alle anderen Systeme neu starten können, bevor das Subsystem neu startet. In diesem Beispiel ermöglichte die Pflege der Prozessdokumentation und der Attribute – wie zum Beispiel der Eigentümerschaft – in der CMDB eine schnelle Lösung des Problems.