Wenn Infrastruktur-Drift deinen Terraform-Plan unbrauchbar macht

Du startest eine Pipeline, um eine neue Anwendungsversion zu deployen. Terraform plan läuft, und die Ausgabe zeigt, dass es deine Produktionsdatenbank-Instanz verkleinern will. Niemand im Team hatte vor, an der Datenbank herumzuschrauben. Der Pull-Request-Reviewer starrt verwirrt auf den Plan. Ist das ein Nebeneffekt der neuen Version? Ein Sicherheitsrequirement, das übersehen wurde? Jemand gibt die Freigabe nur, um das Release nicht zu blockieren – und plötzlich läuft deine Datenbank während der Spitzenlast auf schwächerer Hardware.

Dieses Szenario ist nicht hypothetisch. Es passiert, wenn die Infrastruktur von dem abweicht, was dein Code definiert. Und sobald Drift eingesetzt hat, wird dein vertrauenswürdigstes Werkzeug für sichere Infrastrukturänderungen unzuverlässig.

Was Drift eigentlich bedeutet

Infrastruktur-Drift ist die Lücke zwischen dem, was dein Code als Soll-Zustand der Infrastruktur definiert, und dem, was tatsächlich in deiner Cloud-Umgebung existiert. Du hast Terraform-, Pulumi- oder CloudFormation-Code geschrieben, der deine Ressourcen definiert. Jemand loggt sich in die Cloud-Konsole ein und ändert einen Instanztyp, fügt eine Security-Group-Regel hinzu oder passt einen Datenbankparameter an. Diese Änderung berührt nie dein Code-Repository. Sie durchläuft nie eine Pipeline. Sie passiert einfach.

Die Infrastruktur funktioniert trotzdem. Anwendungen laufen weiter. Aber dein Code beschreibt nicht mehr die Realität. Er beschreibt, wie die Realität früher einmal war.

Der Plan, der dich belügt

Infrastructure-as-Code-Werkzeuge wie Terraform arbeiten, indem sie zwei Dinge vergleichen: deine Code-Definitionen und deine State-Datei (die nachverfolgt, was in der Cloud existiert). Wenn beide übereinstimmen, ist der Plan, den du erhältst, korrekt. Er zeigt genau, was sich basierend auf deinem letzten Code-Commit ändern wird.

Das folgende Flussdiagramm zeigt, wie Drift eine Diskrepanz zwischen Code, State und tatsächlicher Infrastruktur erzeugt, was zu einem ungenauen Plan führt:

Drift bricht diesen Vergleich. Die State-Datei wird veraltet, weil sich die tatsächliche Infrastruktur außerhalb der Pipeline geändert hat. Wenn Terraform plan ausführt, liest es den veralteten State und vergleicht ihn mit deinem Code. Das Ergebnis sieht so aus, als wolle Terraform Änderungen vornehmen, aber diese Änderungen sind in Wirklichkeit Korrekturen, um die Infrastruktur wieder in den von deinem Code definierten Zustand zu bringen. Nicht die Änderungen, die du beabsichtigt hast.

Das ist Plan-Drift: ein Plan, der bereits bestehende Unterschiede zwischen Code und Realität widerspiegelt, nicht die Änderungen, die du tatsächlich deployen möchtest.

Drei Arten, wie Drift deine Pipeline beschädigt

Unerwartete Zerstörung

Das ist das gefährlichste Ergebnis. Stell dir eine Netzwerk-Security-Group vor, die dein Sicherheitsteam manuell erstellt hat, um eine sensible Workload zu isolieren. Diese Ressource existiert nicht in deinem IaC-Code. Wenn deine Pipeline terraform apply mit Code ausführt, der diese Ressource nie definiert hat, sieht Terraform sie als etwas, das nicht existieren sollte. Es zerstört sie. Deine Sicherheitskonfiguration verschwindet lautlos, und niemand bemerkt es, bis etwas kaputtgeht.

Verschwendete Review-Zeit

Pull-Request-Reviewer sehen einen Plan, der Änderungen an Ressourcen zeigt, die nichts mit dem zu deployenden Feature zu tun haben. Sie können nicht erkennen, ob es sich um versehentliche Nebeneffekte, erforderliche Updates oder etwas Verdächtiges handelt. Zeit wird damit verbracht, Änderungen zu untersuchen, die nicht Teil der eigentlichen Arbeit sind. Review-Zyklen werden länger. Teams stellen Fragen wie "Hat schon wieder jemand an der Produktion herumgeschraubt?", anstatt sich auf die eigentliche Code-Änderung zu konzentrieren.

Gebrochenes Vertrauen in die Automatisierung

Wenn Pläne ständig unerwartete Änderungen zeigen, hören Teams auf, der Pipeline zu vertrauen. Sie führen manuelle Checks vor dem Deployment durch. Sie beginnen, Änderungen direkt in der Konsole vorzunehmen, weil die Pipeline unzuverlässig wirkt. Die Ironie ist brutal: Je mehr Änderungen außerhalb der Pipeline stattfinden, desto schlimmer wird der Drift. Die Pipeline wird weniger vertrauenswürdig, also umgehen die Leute sie häufiger, was sie noch weniger vertrauenswürdig macht.

Warum Drift in echten Teams passiert

Drift wird nicht durch schlechte Ingenieure verursacht. Er passiert, weil echte Arbeit Situationen schafft, in denen die Pipeline nicht der schnellste Weg ist:

• Ein Vorfall erfordert eine sofortige Änderung. Der diensthabende Ingenieur behebt es in der Konsole, weil das Schreiben von Code, Committen und Warten auf eine Pipeline zu lange dauert.
• Ein Datenbank-Administrator optimiert Parameter direkt in der Cloud-Konsole, weil er nicht täglich mit IaC-Werkzeugen arbeitet.
• Ein Sicherheitsteam fügt während eines Audits temporäre Firewall-Regeln hinzu und vergisst, sie zu dokumentieren.
• Ein Entwickler muss schnell etwas testen und erstellt manuell eine Ressource, mit dem Plan, sie "später in den Code aufzunehmen."

Jede dieser Aktionen ist für sich genommen sinnvoll. Zusammen erzeugen sie eine Lücke zwischen Code und Realität, die so groß wird, dass der Pipeline nicht mehr vertraut werden kann.

Drift erkennen, bevor er schadet

Die Lösung ist nicht, den Konsolenzugang zu verbieten. Dieser Ansatz scheitert, weil Notfälle und legitime betriebliche Anforderungen starre Regeln immer umgehen werden. Die Lösung ist, Drift automatisch zu erkennen und sichtbar zu machen, bevor jemand einen Plan ausführt.

Die meisten IaC-Werkzeuge bieten Drift-Erkennungsfunktionen. Terraform Cloud und Enterprise haben eine Drift-Erkennung, die Pläne zeitgesteuert ausführt und alarmiert, wenn die tatsächliche Infrastruktur vom State abweicht. OpenTofu, der Open-Source-Fork von Terraform, enthält ähnliche Funktionen. Du kannst auch deine eigene Erkennung mit zeitgesteuerten Pipeline-Läufen bauen, die den State mit den tatsächlichen Cloud-Ressourcen vergleichen.

Der Schlüssel ist, Drift sichtbar zu machen. Wenn ein Teammitglied etwas in der Konsole ändert, sollte der nächste geplante Drift-Check dies melden. Das Team kann dann entscheiden: den Code aktualisieren, um die Änderung abzubilden, oder die Änderung rückgängig machen, um wieder dem Code zu entsprechen. Beide Optionen sind gültig, solange sie beabsichtigt und nachverfolgt werden.

Eine praktische Checkliste zur Drift-Erkennung

Wenn du Infrastruktur mit IaC verwaltest, solltest du diese Checks in deine Routine aufnehmen:

• Plane einen wöchentlichen Drift-Erkennungslauf für Produktionsumgebungen
• Alarmiere das Team, wenn Drift gefunden wird, nicht erst, wenn es zu Fehlern führt
• Überprüfe Drift-Berichte in deinem regelmäßigen Team-Sync
• Dokumentiere einen klaren Prozess zur Behebung von Drift: entweder Code aktualisieren oder die Änderung rückgängig machen
• Behandle manuelle Konsolenänderungen als temporäre Workarounds, nicht als dauerhafte Lösungen

Die wahren Kosten, Drift zu ignorieren

Drift zerstört deine Infrastruktur nicht sofort. Er untergräbt langsam die Zuverlässigkeit deiner Pipeline. Jeder unentdeckte Drift macht den nächsten Plan weniger vertrauenswürdig. Jeder Plan, der das Team überrascht, macht es weniger bereit, zu automatisieren. Irgendwann wird deine Infrastruktur zu einer Blackbox, in der niemand weiß, was tatsächlich läuft, und das Code-Repository wird zu einem Wunschdokument statt zur Quelle der Wahrheit.

Das Ziel ist nicht, Drift vollständig zu eliminieren. Etwas Drift ist in komplexen Systemen unvermeidlich. Das Ziel ist, ihn schnell zu erkennen, sichtbar zu machen und deinem Team einen klaren Weg zur Behebung zu geben. Wenn dein Plan nur die Änderungen zeigt, die du beabsichtigt hast, kannst du deiner Pipeline wieder vertrauen.