Wenn der Infrastrukturzustand nicht der Realität entspricht

Du hast deine Infrastruktur als Code aufgesetzt. Terraform, Pulumi oder ein anderes Tool deiner Wahl. Alles ist getrackt, versioniert und reproduzierbar. Deine State-Datei sagt, der Produktionsserver hat 4 CPUs und 16 GB RAM. Das Leben ist gut.

Dann eines Tages loggt sich jemand in die Cloud-Konsole ein und ändert die Größe des Servers manuell. Vielleicht gab es ein Performance-Problem und das Support-Team musste schnell handeln. Vielleicht hat jemand ein Skript ausgeführt, das nicht in deiner Codebasis war. Was auch immer der Grund ist: Deine State-Datei sagt immer noch 4 CPUs und 16 GB, aber der tatsächliche Server läuft jetzt mit 8 CPUs und 32 GB.

Diese Lücke zwischen dem, was dein State sagt, und dem, was tatsächlich existiert, nennt man Drift. Und es ist ein größeres Problem, als die meisten Teams glauben.

Warum Drift entsteht

Drift ist nicht selten. Es passiert häufiger, als man denkt, und meist aus nachvollziehbaren Gründen:

  • Jemand nimmt während eines Incidents eine schnelle Änderung in der Cloud-Konsole vor
  • Ein anderes Team führt eigene Automatisierungen aus, die deine Ressourcen betreffen
  • Ein Monitoring-Tool skaliert etwas automatisch, ohne den State zu aktualisieren
  • Ein Entwickler ändert eine Ressource direkt, um etwas zu testen, und vergisst, es rückgängig zu machen

Die Absicht ist fast nie böswillig. Aber das Ergebnis ist dasselbe: Dein State wird unzuverlässig. Und wenn der State unzuverlässig ist, wird jeder nachfolgende Deployment zu einem Glücksspiel. Du könntest versuchen, eine Ressource zu aktualisieren, die nicht mehr deiner Konfiguration entspricht. Oder du stellst fest, dass Ressourcen, von denen du dachtest, sie existieren, geändert oder gelöscht wurden. Beim nächsten Durchlauf deiner Pipeline bekommst du Überraschungen statt vorhersehbarer Ergebnisse.

Die wahren Kosten von Drift

Drift zerstört nicht nur deine Automatisierung. Es zerstört das Vertrauen in deinen gesamten Auslieferungsprozess. Wenn dein Team nicht darauf vertrauen kann, dass Infrastructure as Code die Realität abbildet, fangen sie wieder an, manuelle Änderungen vorzunehmen. Und manuelle Änderungen führen zu mehr Drift. Das ist eine Abwärtsspirale.

Für Produktionsumgebungen ist Drift besonders gefährlich. Eine Ressource, die außerhalb deines Prozesses geändert wurde, könnte sich unter Last anders verhalten. Sicherheitsgruppen, die manuell geändert wurden, könnten Lücken hinterlassen. Datenbankinstanzen, die ohne State-Update skaliert wurden, könnten unerwartete Kosten oder Performance-Probleme verursachen. Und wenn etwas schiefgeht, hast du keine zuverlässige Aufzeichnung darüber, was sich tatsächlich geändert hat.

Drift erkennen: Der einfache Weg

Der einfachste Ansatz zur Drift-Erkennung ist der manuelle Vergleich. Mit Terraform zeigt dir terraform plan den Unterschied zwischen deinem Code, deinem State und der tatsächlichen Infrastruktur. Jede Ressource, die außerhalb deines Codes geändert wurde, erscheint als unerwartete Modifikation.

Hier ist der Befehl und worauf du achten musst:

# Führe terraform plan ohne Code-Änderungen aus, um Drift zu erkennen
terraform plan

# Beispielausgabe, die Drift zeigt (keine Code-Änderungen vorgenommen)
# Terraform will perform the following actions:
#
#   # aws_instance.web_server will be updated in-place
#   ~ resource "aws_instance" "web_server" {
#       ~ instance_type = "t3.large" -> "t3.medium"
#         id            = "i-0abcd1234efgh5678"
#         tags          = {}
#         # (12 unchanged attributes hidden)
#     }
#
# Plan: 0 to add, 1 to change, 0 to destroy.

# Jede Änderung, die angezeigt wird, obwohl du deinen Code nicht geändert hast = Drift

Das funktioniert für gelegentliche Überprüfungen. Aber die manuelle Erkennung hat ein grundlegendes Problem: Du findest Drift nur, wenn du danach suchst. Wenn du einmal pro Woche prüfst, kann Drift tagelang existieren, bevor du es bemerkst. Und in dieser Zeit kann es echte Probleme verursachen.

Drift-Erkennung automatisieren

Für Umgebungen, die konsistente Kontrolle benötigen, sollte die Drift-Erkennung automatisch laufen. Viele Teams richten geplante Pipelines ein, die regelmäßig terraform plan oder entsprechende Befehle ausführen. Wenn Drift erkannt wird, sendet die Pipeline eine Benachrichtigung an das Team.

Einige Tools haben das eingebaut. Terraform Cloud und Atlantis bieten beide automatisierte Drift-Erkennung. Pulumi hat ähnliche Fähigkeiten. Aber auch ohne diese Tools kannst du einen einfachen Cron-Job oder eine geplante CI-Pipeline einrichten, die deine Infrastrukturvalidierung ausführt und alarmiert, wenn Dinge nicht übereinstimmen.

Automatisierte Erkennung ist besonders wichtig für Produktionsumgebungen. Drift in der Produktion wartet nicht auf deinen wöchentlichen Check. Es betrifft die Benutzer sofort.

Was tun, wenn du Drift findest

Erkennung ist nur die Hälfte des Problems. Sobald du weißt, dass Drift existiert, musst du entscheiden, was du dagegen tun willst. Du hast zwei Hauptoptionen:

Das folgende Flussdiagramm fasst die beiden Hauptwege zur Behandlung von Drift zusammen:

flowchart TD A[Drift erkannt] --> B{War die Änderung beabsichtigt?} B -->|Nein| C[An Code angleichen] B -->|Ja| D{Soll es der neue Standard werden?} D -->|Nein| C D -->|Ja| E[State an Realität anpassen] C --> F[Apply ausführen, um gewünschten Zustand wiederherzustellen] E --> G[Ressource importieren & Code aktualisieren] F --> H[Keinen verbleibenden Drift prüfen] G --> H H --> I[Änderung dokumentieren]

Option 1: Wieder an deinen Code angleichen. Führe deine Konfiguration erneut aus, um die Infrastruktur wieder in den gewünschten Zustand zu versetzen. Das ist die sicherste Wahl für Produktionsumgebungen. Es verstärkt, dass dein Code die Quelle der Wahrheit ist und manuelle Änderungen nicht bestehen bleiben.

Option 2: Deinen State an die Realität anpassen. Importiere die aktuelle Infrastruktur in deinen State und aktualisiere dann deinen Code entsprechend. Das ist sinnvoll, wenn die manuelle Änderung beabsichtigt war und zum neuen Standard werden soll. Aber Vorsicht: Drift in deinen State zu übernehmen bedeutet, dass du akzeptierst, dass Infrastruktur außerhalb deines definierten Prozesses geändert werden kann.

Die meisten erfahrenen Teams wählen Option eins für die Produktion. Sie gleichen die Infrastruktur wieder an den gewünschten Zustand an. Diese Praxis nennt man Reconciliation, und sie ist der Kern von Tools wie Kubernetes-Operatoren und GitOps-Workflows. Das System überprüft kontinuierlich, ob die Realität dem gewünschten Zustand entspricht, und korrigiert automatisch jeden gefundenen Drift.

Eine Drift-Erkennungs-Praxis aufbauen

Wenn du Drift-Erkennung zum ersten Mal einrichtest, fange einfach an. Führe einen geplanten Plan gegen deine kritischsten Umgebungen aus. Sende die Ergebnisse an einen Chat-Kanal, wo das Team sie sehen kann. Mache Drift sichtbar, bevor du versuchst, die Reaktion zu automatisieren.

Sobald sich das Team an Drift-Benachrichtigungen gewöhnt hat, beginne damit, die Reaktion für Nicht-Produktionsumgebungen zu automatisieren. Lass die Pipeline Staging- und Entwicklungsumgebungen automatisch angleichen. Für die Produktion behalte den Menschen im Loop, bis du dir deiner Automatisierung sicher bist.

Und behalte immer Folgendes im Hinterkopf: Drift-Erkennung geht nicht nur darum, Fehler zu finden. Es geht darum, das Vertrauen in deine Infrastructure as Code zu erhalten. Wenn dein Team weiß, dass der State korrekt ist, können sie Änderungen mit Zuversicht vornehmen. Wenn nicht, verlangsamt sich alles.

Praktische Checkliste

  • Führe terraform plan oder ein Äquivalent regelmäßig für Produktionsumgebungen aus
  • Sende Drift-Benachrichtigungen an einen Team-Kanal
  • Definiere eine klare Richtlinie: An Code angleichen oder State aktualisieren
  • Automatisiere die Angleichung zuerst für Nicht-Produktionsumgebungen
  • Dokumentiere, wie mit absichtlichen manuellen Änderungen umzugehen ist
  • Überprüfe Drift-Muster monatlich, um Prozesslücken zu identifizieren

Das Fazit

Drift ist kein Versagen deiner Tools. Es ist ein Signal, dass dein Prozess eine Lücke hat. Jemand musste eine Änderung vornehmen, und der definierte Prozess hat für ihn nicht funktioniert. Vielleicht war er zu langsam. Vielleicht hatte er keinen Zugriff. Vielleicht wusste er nicht, dass der Prozess existiert.

Wenn du Drift findest, repariere nicht nur die Infrastruktur. Repariere den Prozess, der den Drift ermöglicht hat. Mache es den Leuten leichter, Änderungen auf dem richtigen Weg vorzunehmen als daran vorbei. So baust du ein System auf, das ohne ständige Wachsamkeit konsistent bleibt.