Wie können Infrastruktur-Teams Configuration Drift zwischen der aktuellen Umgebung und einer genehmigten Baseline erkennen?

Infrastruktur-Teams erkennen Configuration Drift, indem sie für jedes verwaltete Asset oder jeden Service eine genehmigte Baseline pflegen, den aktuellen Zustand kontinuierlich erfassen, beides vergleichen und unerklärte Abweichungen in nachvollziehbare Änderungsdatensätze überführen. Das Lifecycle-Modell der Quelle verlangt ausdrücklich einen kontinuierlichen Abgleich zwischen aktueller Konfiguration und genehmigter Baseline, auch bei Komponentenaustausch, Kapazitätsanpassung, Firmware-Upgrades, Änderungen der Management-Schnittstelle und physischen Standortwechseln.

Ein Drift-System sollte mehr melden als „unterschiedlich". Es sollte zeigen, was sich genau geändert hat, wann es erkannt wurde, woher der Beleg stammt, ob eine genehmigte Änderung die Abweichung erklärt und ob der neue Zustand zur nächsten Baseline werden sollte.

Was ist eine genehmigte Baseline?

Eine genehmigte Baseline ist der Konfigurationszustand, den das Unternehmen für eine bestimmte Lifecycle-Phase als korrekt akzeptiert hat. Das Quellmaterial zum Hardware-Lifecycle beschreibt mindestens zwei wichtige Baselines. Die Abnahme-Baseline ist der verifizierte Zustand nach Lieferung und technischer Abnahme der Ausrüstung. Die Produktions-Baseline ist der endgültige genehmigte Zustand, mit dem das Gerät nach allen autorisierten Bereitstellungsänderungen in Produktion geht.

Diese Unterscheidung ist wichtig, weil ein Server mit einer Firmware-Version geliefert werden und vor dem Produktivstart ein genehmigtes Upgrade erhalten kann. Die Produktions-Baseline bildet den Endzustand ab, der tatsächlich für den Betrieb akzeptiert wurde. Configuration Drift wird normalerweise gegen die jeweils relevante genehmigte Betriebs-Baseline bewertet.

Was zählt als Configuration Drift?

Drift ist jede beobachtete Differenz zwischen aktuellem und genehmigtem Zustand, die noch nicht abgeglichen wurde. Die Quelle nennt ausdrücklich Änderungen wie Komponentenaustausch, Kapazitätsanpassung, Firmware-Upgrade, Änderung der Management-Schnittstelle, physischen Standortwechsel, Software-Versionsänderung, Migration virtueller Ressourcen und Verantwortlichkeitswechsel.

Nicht jede Abweichung ist schlecht, manche Änderungen sind genehmigt und erwartet. Der Drift-Prozess soll klären, ob eine Abweichung autorisiert und dokumentiert ist, autorisiert, aber nicht synchronisiert, nicht autorisiert, unbekannt, vorübergehend oder ob ein Erkennungs- oder Datenqualitätsfehler dahintersteckt. Mit dieser Klassifizierung kann man mehr anfangen, als wenn jede Abweichung pauschal als nicht konform gilt.

Warum ist Configuration Drift wichtig?

Veraltete Konfigurationsdaten schwächen viele andere Betriebsfunktionen, und die Quelle liefert dafür mehrere Beispiele. Die Fehleranalyse beginnt womöglich mit der falschen Hardware-Konfiguration, Wartungsansprüche beziehen sich auf die falsche Komponente, und die Kapazitätsplanung arbeitet mit der falschen Rack-Position oder dem falschen Leistungsprofil. Sicherheitsprüfungen übersehen eine nicht mehr unterstützte Firmware-Version, CMDB-Beziehungen werden unzuverlässig, und Automatisierung trifft das falsche Objekt.

Die Quelle betont immer wieder, dass Monitoring, Scheduling, Metering und Fehleranalyse von präzisen Konfigurationsbeziehungen abhängen. Configuration Drift ist deshalb ein Betriebsrisiko und reicht weit über die CMDB-Pflege hinaus.

Wie sollte der aktuelle Zustand erfasst werden?

Überall dort, wo die Infrastruktur zuverlässige Daten liefert, sollte automatische Erkennung zum Einsatz kommen. Die Erfassungsebene der Quelle unterstützt BMC, IPMI, Redfish, SNMP, SSH, API, Agent und Kubernetes-Schnittstellen.

Die Quellen liefern jeweils unterschiedliche Teile des Zustands. Aus der Hardware-Erkennung kommen Seriennummer, CPU, Arbeitsspeicher, Festplatte, NIC, Firmware, Beschleuniger und BMC-Informationen. Die Erkennung auf höheren Ebenen liefert Betriebssystem, Container, Software-Version, virtuelle Ressourcen und Anwendungsbeziehungen. So wird die reale Umgebung beobachtet, statt sich allein auf manuelle Aktualisierungen zu verlassen.

Wie sollte die Baseline gespeichert werden?

Die Baseline sollte als versionierter genehmigter Zustand gespeichert werden und nicht als Tabelle, deren aktuelle Werte ständig überschrieben werden. Laut Lifecycle-Modell der Quelle bewahrt das System sowohl den aktuellen Zustand als auch die vollständige Änderungshistorie. Die Baseline lässt sich zurückverfolgen auf Asset, Zeitpunkt, Genehmigungs- oder Abnahme-Ereignis, Quelle und Lifecycle-Phase.

Damit kann die Plattform beantworten, was aktuell ist, was genehmigt wurde, was sich seit der Genehmigung geändert hat und wie das Gerät vor der letzten Änderung aussah. Eine Baseline zu einem festen Zeitpunkt ist wesentlich nützlicher als eine fortlaufend überschriebene Zeile.

Wie sollte der Drift-Vergleich funktionieren?

Aktuell beobachtete Werte werden Feld für Feld mit der genehmigten Baseline verglichen. Beispiele sind die aktuelle gegenüber der genehmigten Firmware, die Arbeitsspeicherkapazität, die Festplatten-Seriennummer und die Rack- und U-Position jeweils gegenüber der Baseline, die BMC-NTP-Einstellung gegenüber der Richtlinie und die Netzwerkkonfiguration gegenüber der beabsichtigten Konfiguration.

Die Check- und Diff-Modi von Ansible zeigen dasselbe Kontrollmuster in der Automatisierung: Sie bewerten, was sich ändern würde, und zeigen Vorher-Nachher-Unterschiede an, ohne das Ziel zwangsläufig zu verändern. Die Quellplattform wendet dieses Prinzip auf der Ebene des Infrastruktur-Managements an, mit kontinuierlicher Erkennung und Änderungshistorie.

Was sollte ein Drift-Datensatz enthalten?

Der Lifecycle-Leitfaden der Quelle wird hier konkret. Die Änderungshistorie sollte festhalten:

• Alter Wert
• Neuer Wert
• Erkennungszeitpunkt
• Belegquelle
• Betroffenes Asset
• Zugehöriger Arbeitsauftrag oder Änderungsdatensatz
• Endgültiges Genehmigungsergebnis

Das ist ein solides Minimum, mit dem jedes Drift-Ereignis auditierbar wird. Ein Operator sieht dann, dass sich die Firmware unterscheidet, und auch, ob der Unterschied aus einem genehmigten Wartungsfenster stammt oder unerwartet aufgetreten ist.

Wie sollten genehmigte Änderungen abgeglichen werden?

Entspricht die Abweichung einer genehmigten Änderung und war die Validierung danach erfolgreich, kann der neue Zustand gemäß Änderungsprozess zur aktualisierten genehmigten Baseline werden. Das Quellmaterial zu Kapazität und Lifecycle beschreibt dieses Rückkopplungsmuster, bei dem der validierte Produktionszustand zur neuen Baseline wird. Eine Baseline soll die Infrastruktur also nicht für immer einfrieren, sondern sich über kontrollierte Lifecycle-Änderungen weiterentwickeln.

Die Abfolge sieht so aus: Nach der genehmigten Änderung folgen Ausführung und Validierung. Die Konfigurationserkennung bestätigt die Abweichung, die Baseline wird aktualisiert, und die Historie bleibt erhalten. So bleibt die Baseline aktuell, ohne dass der vorherige Zustand verloren geht.

Wie sollte nicht autorisierter Drift behandelt werden?

Nicht autorisierter Drift ist eine operative Ausnahme. Die Reaktion kann ein Alert sein, ein Incident, eine Änderungsprüfung, eine Wiederherstellung der Konfiguration, eine Sicherheitsprüfung oder eine Benachrichtigung des Owners.

Welche Maßnahme passt, hängt vom Feld und vom Risiko ab. Ein unerwarteter Rack-Wechsel ist etwas anderes als eine nicht autorisierte Änderung der Zugriffskontrolle, und eine unerwartete Firmware-Version etwas anderes als ein fehlendes Arbeitsspeichermodul. Ein universelles Schweregrad-Modell für Drift schreibt die Quelle nicht vor. Das Unternehmen sollte Drift nach geschäftlichen und operativen Folgen einstufen.

Wie lässt sich Firmware-Drift erkennen?

Man vergleicht die erkannte Firmware-Version mit der genehmigten Firmware-Baseline für das Gerätemodell oder die Asset-Gruppe. Der Quell-Anwendungsfall für Hardware-Management unterstützt ausdrücklich Firmware-Baseline-Management und Batch-Upgrades über heterogene Server-Marken hinweg.

Er beschreibt auch ein reales Betriebsproblem: Eine defekte Firmware-Version muss unter Umständen auf allen betroffenen Geräten gefunden und schnell ersetzt werden. Dafür braucht es drei Angaben, nämlich die aktuelle Firmware, die genehmigte oder verbotene Firmware und die Asset-Identität.

Für Firmware-Betrieb im Flottenmaßstab erklärt wie Unternehmen Firmware-Versionen und Firmware-Compliance über Tausende Server hinweg verwalten können, wie die Baseline zu einer Compliance-Ansicht wird.

Wie lässt sich physischer Standort-Drift erkennen?

Man vergleicht den erkannten oder verifizierten Standort mit dem genehmigten Asset-Standort. Das Lifecycle-Modell der Quelle erfasst Rechenzentrum, Rack, U-Position und physische Umzüge.

Eine Standortänderung wirkt sich auf Kapazität, Strom, Kühlung, Netzwerkpfad, Eigentümerschaft und Incident Response aus. Wird ein Server verschoben, ohne dass die CMDB nachzieht, stimmen danach womöglich weder die Rack-Kapazität noch die Geschäftstopologie. Standort-Drift gehört deshalb als Konfigurationsänderung behandelt und nicht nur als Vermerk im Asset-Management.

Wie kann Komponentenaustausch Drift erzeugen?

Eine Hardware-Reparatur verändert die physische Konfiguration des Assets, weil eine Festplatte, ein Arbeitsspeichermodul, ein Netzteil, eine NIC oder ein Beschleuniger ausgetauscht wird. Das Asset-Management-Modell der Quelle erkennt Änderungen auf Komponentenebene automatisch und setzt voraus, dass Reparaturdatensätze die CMDB aktualisieren.

Taucht ein Ersatzteil ohne zugehörigen Arbeitsauftrag auf, markiert die Plattform die Abweichung zum Abgleich. Bestätigt der Arbeitsauftrag den Austausch, wird die neue Komponente nach der Validierung Teil der aktuellen Baseline, und der Reparaturkreislauf ist geschlossen.

Wie sollte Drift mit Incidents verknüpft werden?

Aktueller Drift sollte im Incident-Kontext sichtbar sein. Das RCA-Modell der Quelle nutzt Konfigurationsänderungen als Beleg bei der Fehlersuche. Beginnt ein Incident, zeigt die Plattform aktuelle Alarme, Topologie, Metriken sowie jüngsten Configuration Drift oder genehmigte Änderungen.

Begann der Ausfall kurz nach einer Firmware- oder Konfigurationsänderung, ist dieser Zusammenhang relevant. Er bleibt ein Indiz und kein Beweis, kann die Diagnose aber erheblich verkürzen.

Für die historische Fehlersuche erklärt wie frühere Incidents und die Remediation-Historie künftige Fehlersuche verbessern, wie Änderungshistorie und geprüfte Fälle zusammenwirken.

Wie sollte Drift mit Compliance verknüpft werden?

Compliance lässt sich als spezifische Drift-Regel umsetzen. Beispiele: Die Firmware muss der genehmigten Version entsprechen, BMC-NTP muss genehmigte Server verwenden und SNMP die genehmigte Konfiguration. Die Konfiguration der Netzwerkgeräte muss der genehmigten Vorlage entsprechen, und Werte der Sicherheits-Baseline müssen innerhalb der Richtlinie bleiben.

Der Quell-Anwendungsfall für BMC beschreibt eine einheitliche Initialisierung und Firmware-Baseline-Management über Server-Marken hinweg. Mit demselben Vergleichsmodell wird aus der beabsichtigten Konfiguration eine Compliance-Ansicht.

Wie oft sollten Drift-Prüfungen laufen?

Die Quelle verlangt einen kontinuierlichen oder automatisierten Abgleich, nennt aber kein universelles Intervall. Die richtige Häufigkeit hängt davon ab, wie oft sich die Konfiguration ändert, wie schnell sich Risiko entwickelt, was die Erfassung kostet, welche Schnittstellen verfügbar sind und wie kritisch das Asset ist.

Manche Zustände lassen sich ereignisgesteuert erfassen, andere werden periodisch abgefragt. Auf eine jährliche Inventur allein sollte man sich nicht verlassen, denn ein Gerät kann zwischen zwei Audits mehrfach driften.

Wie sollten widersprüchliche Datenquellen behandelt werden?

Belegquelle und Abgleichsstatus sollten erhalten bleiben. Das Datenverwaltungsmodell der Quelle unterstützt autoritative Quellen, Konfidenz, Konfliktprüfung und Änderungshistorie. So kann die Hardware-Erkennung für Seriennummer und Firmware maßgeblich sein, ITSM für den Business Owner und die Beschaffung für die Anschaffungskosten.

Widersprechen sich zwei Quellen, sollte keine davon unbemerkt überschrieben werden. Der Konflikt wird markiert und nach der Feldautorität aufgelöst, und das macht die Baseline vertrauenswürdiger.

Was sollte ein Drift-Dashboard zeigen?

Eine praxisnahe Ansicht auf Basis der Quelle kann zeigen:

• Geprüfte Assets
• Konforme Assets
• Assets mit Drift
• Nicht genehmigte Änderungen
• Genehmigte Änderungen, die auf die Baseline-Aktualisierung warten
• Firmware-Drift
• Komponenten-Drift
• Standort-Drift
• Drift der Management-Schnittstelle
• Zugehöriges Änderungsticket
• Alter des ungelösten Drifts
• Belegquelle

Ein Plattform-Beispiel, das erkannte Infrastruktur kontinuierlich mit kontrollierten Konfigurationsdatensätzen abgleicht, ist Sensaka.

Würde ich Configuration-Drift-Management einführen, würde ich eine Regel verpflichtend machen: Jede erkannte Abweichung braucht einen Status. Sie ist durch eine genehmigte Änderung erklärt, nach Validierung in die neue Baseline übernommen, bewusst ausgenommen oder ungelöst. Gefährlich wird es, wenn sich etwas unterscheidet und niemand weiß, warum.