Eine persistente Abweichung zwischen den tatsächlichen Laufzeit‑Einstellungen oder dem Zustand eines Systems und dessen beabsichtigtem, aufgezeichnetem oder verwaltetem Konfigurations‑Baseline, verursacht durch ad‑hoc‑Änderungen, Umgebungsunterschiede, Software‑Updates oder unvollständige Automatisierung; führt zu inkonsistentem Verhalten, Interoperabilitätsfehlern, Sicherheitslücken oder fehlgeschlagenen Deployments, wenn Komponenten den Baseline‑Zustand voraussetzen.

Prinzip

Wenn der autoritative Konfigurationszustand nicht kontinuierlich durchgesetzt und mit dem laufenden Zustand abgeglichen wird, sammeln sich inkrementelle oder manuelle Änderungen an und erzeugen eine beobachtbare Divergenz, proportional zur Häufigkeit und zum Umfang nicht verwalteter Änderungen.

Demonstration

Illustriertes Szenario → Erkennung → Handlung → Folge: Ein Team betreibt Server, die durch ein Infrastructure‑as‑Code‑Repository definiert sind. Ein Ingenieur wendet ein Notfall‑Patch manuell auf eine Teilmenge von Hosts an. Später gehen automatisierte Deployments vom Repository‑Zustand aus und bringen eine Konfiguration, die mit den gepatchten Hosts in Konflikt steht. Erkennung: Monitoring meldet inkonsistente Service‑Antworten zwischen Hosts. Handlung: Betreiber führen einen Abgleich durch oder rollen die manuelle Änderung zurück. Folge: Entweder ein Deployment‑Rollback und Betriebsunterbrechung oder die Feststellung, dass die manuelle Änderung eine Sicherheitskonfiguration eingeführt hat, die im Baseline fehlt und behoben werden muss.

Fehlanwendung

Jede Konfigurationsabweichung als Beleg für böswillige Kompromittierung zu werten. Warum plausibel: sowohl Kompromittierung als auch Drift erzeugen Zustandsunterschiede. Semantischer Fehler: Drift beschreibt einen Zustandsvergleich (tatsächlich ≠ beabsichtigt) verursacht durch Änderungsprozesse; Kompromittierung ist eine kausale Zuschreibung, die Belege erfordert.

Konsequenz

Betriebliche Unvorhersehbarkeit (fehlgeschlagene Deployments, inkonsistente Feature‑Verfügbarkeit), Sicherheitsrisiken (fehlende Patches oder falsch konfigurierte Kontrollen) und Compliance‑Verstöße; Behebung erfordert typischerweise Erkennung, Abgleich und Änderungen in der Governance statt einzelner Reparaturen.

Umkehrung

Ist die Infrastruktur als unveränderliche Artefakte ausgeführt oder wird durch kontinuierlich durchgesetzte Desired‑State‑Systeme verwaltet (deklarative Orchestrierung mit automatischer Reconciliation), so wird persistente Drift eliminiert oder auf transiente Fenster begrenzt; andererseits ist eine beabsichtigte, versionierte Fortentwicklung der Baseline keine Drift, wenn sie dokumentiert und abgeglichen wird.

Abgrenzung

Klar innerhalb: Produktionshosts, deren Live‑Konfiguration dauerhaft von der versionierten Konfigurationsquelle abweicht. Randfall: temporäre Abweichung während eines kontrollierten Rolling‑Updates, bei dem Knoten zeitweise unterschiedlich sind. Klar außerhalb: Unterschiede zwischen zwei absichtlich verschiedenen Umgebungen (z. B. Entwicklung vs Produktion), die nicht denselben Baseline‑Anspruch teilen.

Semantische Spannung

Stabilität ↔ Anpassung — das Bedürfnis, unautorisierte Änderungen zu verhindern (Stabilität), steht im Wettbewerb mit dem Bedürfnis nach schneller Fehlerbehebung und Evolution (Anpassung); stärkere Durchsetzung reduziert Drift, kann aber die Notfallreaktion verlangsamen.

Synthese

Konfigurationsdrift zwingt dazu, Konfiguration als beobachtbaren Zustand zu begreifen: Effektives Management braucht ein autoritatives Baseline‑Modell und automatisierte Erkennung/Reconciliation, damit Divergenz ein kontrolliertes, dokumentiertes Ereignis bleibt statt eines kumulativen Fehlermodus.