Konfigurationsdrift macht leise Änderungen zum Betriebsrisiko

Kurz gesagt Konfigurationsdrift bedeutet, dass ein IT-System im laufenden Betrieb schleichend vom gewünschten Sollzustand abweicht. Ein Server, eine Anwendung, eine Cloud-Ressource oder ein Netzwerkdienst sieht dann auf dem Papier noch richtig aus, verhält sich aber nicht mehr exakt wie geplant. Für den Servicebetrieb ist das gefährlich, weil die Abweichung oft erst auffällt, wenn eine Störung, ein Update oder eine Sicherheitsprüfung plötzlich anders läuft als erwartet.

Der IT-Betrieb lebt von Verlässlichkeit. Ein Service soll heute so funktionieren, wie er gestern dokumentiert, freigegeben und überwacht wurde. Genau diese Verlässlichkeit bricht leise weg, wenn kleine Änderungen nicht sauber zurück in die Betriebssteuerung fließen. Ein Parameter wird direkt auf einem Server geändert. Eine Ausnahme bleibt nach einem Störfall stehen. Ein Cloud-Dienst wird testweise erweitert. Ein Skript korrigiert etwas automatisch, ohne dass der neue Zustand in der Dokumentation, im Monitoring oder im Servicekatalog ankommt.

Das Problem ist nicht nur technischer Natur. Konfigurationsdrift trifft Change Management, Incident Management, Security, Compliance und Kostenkontrolle gleichzeitig. Wer nur auf die einzelne Komponente schaut, sieht vielleicht keinen Fehler. Wer aus Servicesicht denkt, erkennt dagegen eine Kernfrage: Kann der Betrieb noch erklären, warum ein System gerade so eingestellt ist?

Der gefährliche Teil ist die Unsichtbarkeit

Konfigurationsdrift entsteht selten durch eine große, sichtbare Entscheidung. Häufig beginnt sie mit sinnvollen Einzelmaßnahmen. Ein Administrator löst nachts eine Störung. Ein Team beschleunigt eine Lieferung. Ein Lieferant passt eine Einstellung an, damit ein Prozess weiterläuft. Jede einzelne Änderung kann nachvollziehbar sein. Riskant wird es, wenn sie nicht in den gemeinsamen Sollzustand zurückgeführt wird.

Red Hat ordnet Konfigurationsmanagement als Methode ein, Systeme in einem gewünschten Zustand zu halten und Änderungen kontrollierbar zu machen. Atlassian betont bei Configuration Management, dass IT-Teams verstehen müssen, welche Komponenten existieren, wie sie zusammenhängen und welchen Zustand sie haben sollten. Für ITSM-Generalisten heißt das: Eine Konfiguration ist nicht nur eine technische Datei. Sie ist ein Betriebsversprechen darüber, wie ein Service gebaut, geschützt und wiederhergestellt wird.

Störungen werden schwerer erklärbar

Im Incident Management zählt Tempo. Teams müssen schnell verstehen, was betroffen ist, welche Abhängigkeiten bestehen und welche Rückwege möglich sind. Wenn die reale Konfiguration von der dokumentierten Lage abweicht, verlieren diese Antworten an Qualität. Ein Neustart greift nicht wie erwartet. Ein Failover läuft anders. Ein Alarm fehlt, weil eine Schwelle geändert wurde. Ein Berechtigungspfad bleibt offen, obwohl der Prozess ihn längst geschlossen sieht.

Besonders unangenehm ist, dass Drift oft erst im falschen Moment sichtbar wird. Solange der Service läuft, wirkt die Abweichung harmlos. Beim Update, Audit, Notfalltest oder Lieferantenwechsel wird sie plötzlich zum echten Betriebsrisiko. Dann muss ein Team nicht nur die aktuelle Störung lösen, sondern nebenbei rekonstruieren, welche Einstellung wann und warum aus dem Sollzustand gefallen ist.

Automatisierung hilft nur mit klarer Verantwortung

Werkzeuge für Infrastructure as Code, Konfigurationsmanagement oder Cloud-Governance können Abweichungen sichtbar machen. Sie vergleichen Soll und Ist, melden unerwartete Änderungen oder setzen Zustände automatisch zurück. Das ist wertvoll, ersetzt aber keine Betriebsentscheidung. Nicht jede Abweichung ist ein Fehler. Manche Ausnahme ist fachlich gewollt, zeitlich begrenzt oder durch einen Störfall begründet.

Genau deshalb braucht Drift-Management eine klare Verantwortlichkeit. Wer darf entscheiden, ob eine Abweichung zurückgedreht wird? Wer bewertet das Risiko für den Service? Wer aktualisiert Dokumentation, Monitoring und Wiederanlaufplan? Ohne diese Rollen entsteht eine neue Lücke: Das Werkzeug erkennt die Abweichung, aber niemand führt sie sauber in den Betrieb zurück.

Der Sollzustand muss für den Service lesbar sein

Ein technischer Sollzustand allein reicht nicht. ITSM braucht eine Übersetzung in Servicewirkung. Welche Einstellung schützt Verfügbarkeit? Welche betrifft Datenschutz oder Zugriff? Welche ist nur Komfort? Welche Änderung kann Nutzer direkt treffen? Erst diese Einordnung macht aus einem Konfigurationsvergleich eine betriebliche Entscheidung.

Für den Service Desk ist das ebenfalls wichtig. Wenn nach einer Änderung Meldungen auftauchen, muss er wissen, ob ein bekanntes Risiko besteht oder ob ein neues Problem begonnen hat. Für Security zählt, ob eine Ausnahme offen bleibt. Für Finanzen zählt, ob zusätzliche Ressourcen unbemerkt weiterlaufen. Für das Management zählt, ob die Organisation ihren kritischen Betrieb noch beherrscht.

Eine einfache Betriebsroutine gegen Drift

• Für kritische Services einen verständlichen Sollzustand festlegen, nicht nur technische Dateien sammeln.
• Direkte Änderungen im Störfall erlauben, aber mit Rückführungsfrist dokumentieren.
• Abweichungen nach Risiko einteilen: sicherheitskritisch, verfügbarkeitskritisch, kostenrelevant oder rein technisch.
• Monitoring und Dokumentation nach bestätigten Änderungen aktualisieren.
• Regelmäßig prüfen, ob Wiederherstellung, Update und Notfallplan noch zur realen Umgebung passen.
• Ausnahmen mit Besitzer und Ablaufdatum versehen.

Fazit

Konfigurationsdrift ist kein Randthema für Spezialisten. Sie entscheidet darüber, ob ein Service im Alltag noch so betrieben wird, wie er geplant, freigegeben und abgesichert wurde. Der beste Schutz besteht nicht in einem einzigen Tool, sondern in einer gemeinsamen Routine: Sollzustand sichtbar machen, Abweichungen bewerten, Ausnahmen begrenzen und die reale Umgebung wieder in die Betriebssteuerung zurückholen.

Quellen und Einordnung Geprüft wurden Red Hat zu Konfigurationsmanagement, Atlassian zu Configuration Management und Puppet zur Bedeutung von Konsistenz im Konfigurationsmanagement. Stand der Quellenprüfung: 19.06.2026.