Wenn Ihre Infrastruktur vom Code abweicht

Sie haben Ihre gesamte Infrastruktur in Terraform definiert. Jede Sicherheitsgruppe, jede Instanzgröße, jeder Datenbankparameter ist in Code geschrieben und wird über eine Pipeline bereitgestellt. Sie sind zuversichtlich, dass das, was in Ihrem Repository steht, mit dem übereinstimmt, was in der Produktion läuft. Doch dann führen Sie eines Tages einen Plan aus und sehen Änderungen, die Sie nie erwartet haben. Ressourcen, die Sie nicht berührt haben, sollen geändert werden. Etwas unterscheidet sich zwischen Ihrem Code und der Realität.

Dieser Unterschied hat einen Namen: Drift.

Was Drift eigentlich bedeutet

Drift ist die Lücke zwischen dem, was Ihr Infrastrukturcode als Soll-Zustand definiert, und dem, was tatsächlich in Ihrem Cloud-Provider oder Server existiert. Ihre Terraform- oder Pulumi-Dateien definieren den gewünschten Zustand. Die Ressourcen, die in AWS, Google Cloud oder Azure laufen, repräsentieren den Ist-Zustand. Wenn diese beiden nicht übereinstimmen, haben Sie Drift.

Das klingt einfach, aber die Auswirkungen sind tiefgreifend. Infrastructure as Code basiert auf einer kritischen Annahme: dass Ihr Code die alleinige Quelle der Wahrheit für die Konfiguration aller Komponenten ist. Diese Annahme gilt nur, wenn jede einzelne Änderung an der Infrastruktur durch Ihre Pipeline erfolgt. Sobald sich etwas außerhalb dieser Pipeline ändert, bricht die Annahme.

Drei Wege, wie Drift entsteht

Drift entsteht nicht, weil jemand einen Fehler gemacht hat. Er entsteht, weil Infrastruktur von echten Menschen unter echtem Druck verwaltet wird.

Das folgende Diagramm zeigt, wie jeder Pfad die beabsichtigte IaC-Pipeline umgeht und zu Drift führt.

flowchart TD A[Intended Path: IaC Pipeline] --> B[Desired State in Code] C[Manual Console Change] --> D[Direct modification] D --> E[Drift] F[Incident Response] --> G[Emergency change] G --> E H[External Tools / Autoscalers] --> I[Automated change outside pipeline] I --> E B -.->|No drift| J[Actual State Matches Code] E --> K[Actual State != Code]

Manuelle Änderungen

Jemand meldet sich in der Cloud-Konsole an und nimmt eine direkte Änderung vor. Vielleicht fügt er eine Sicherheitsgruppenregel hinzu, damit sein Team von einer neuen Büro-IP auf einen Server zugreifen kann. Vielleicht vergrößert er eine Instanz, weil eine Demo ansteht und mehr Kapazität benötigt wird. Die Änderung dauert dreißig Sekunden in der Konsole. Den Terraform-Code zu aktualisieren, einen Pull-Request zu erstellen, auf die Überprüfung zu warten, die Pipeline auszuführen – das dauert viel länger. Also wird es übersprungen.

Das ist keine Faulheit. Es ist eine rationale Reaktion auf ein System, das kleine Änderungen teuer macht. Aber jede direkte Konsolenänderung erzeugt eine Lücke zwischen Ihrem Code und der Realität.

Incident Response

Wenn die Produktion ausfällt, erstellt niemand zuerst einen Pull-Request. Das Team springt in die Konsole oder CLI und nimmt alle notwendigen Änderungen vor, um den Dienst wiederherzustellen. Sie erhöhen die Instanzkapazität. Sie ändern die Datenbank-Verbindungslimits. Sie deaktivieren ein Feature-Flag über das Cloud-Dashboard.

Diese Notfalländerungen sind operativ korrekt. Die Priorität ist die Wiederherstellung des Dienstes, nicht die Aufrechterhaltung der Infrastruktur-Reinheit. Aber nach dem Vorfall wird der IaC-Code selten aktualisiert, um das Geschehene abzubilden. Das Team wendet sich dem nächsten Brandherd zu, und der Drift bleibt bestehen.

Externe Tools und Prozesse

Nicht jeder Drift wird durch menschliches Handeln verursacht. Autoscaler fügen Instanzen hinzu und entfernen sie basierend auf der Last. Sicherheitstools wenden Richtlinien über separate Mechanismen an. Secret-Management-Systeme rotieren Anmeldeinformationen automatisch. Konfigurationsmanagement-Tools aktualisieren Parameter außerhalb Ihrer IaC-Pipeline.

Dies sind legitime, automatisierte Prozesse. Sie halten Ihre Infrastruktur am Laufen und sicher. Aber sie erzeugen auch eine Lücke zwischen dem, was Ihr Terraform-Code definiert, und dem, was tatsächlich läuft.

Warum Drift wichtig ist

Eine kleine Menge Drift mag keine unmittelbaren Probleme verursachen. Ihre Anwendung läuft weiter. Ihre Benutzer bemerken nichts. Aber Drift akkumuliert, und diese Akkumulation schafft echte Risiken.

Das unmittelbarste Problem ist das Vertrauen. Wenn Sie einen Terraform-Plan ausführen, erwarten Sie, nur die von Ihnen beabsichtigten Änderungen zu sehen. Wenn jedoch Drift existiert, zeigt der Plan unerwartete Modifikationen. Ressourcen, die Sie nicht berührt haben, werden auf ihren code-definierten Zustand zurückgesetzt. Diese Sicherheitsregel, die jemand manuell hinzugefügt hat? Sie wird beim nächsten Apply entfernt. Diese Instanzvergrößerung aus dem Vorfall? Sie wird rückgängig gemacht.

Dies ist gefährlich, weil Sie möglicherweise nicht wissen, was Sie gleich zerstören. Ein Plan, der Änderungen an Ressourcen zeigt, die Sie nicht ändern wollten, sollte Sie davon abhalten, ihn anzuwenden. Aber in der Praxis genehmigen Teams unter Druck den Plan trotzdem, in der Annahme, die Änderungen seien harmlos. Manchmal sind sie es. Manchmal nicht.

Das tiefere Problem ist, dass Drift Ihre Infrastruktur unberechenbar macht. Sie können keine Änderungen mehr zuversichtlich vornehmen, weil Sie nicht wissen, was der aktuelle Zustand tatsächlich ist. Jede Bereitstellung wird zum Glücksspiel. Wird die Pipeline korrekt funktionieren? Wird sie eine kritische Änderung rückgängig machen, die während eines Vorfalls vorgenommen wurde? Wird sie etwas zerstören, das monatelang einwandfrei gelaufen ist?

Drift ist kein Zeichen von Versagen

Es ist wichtig zu verstehen, dass Drift kein Beweis für ein nachlässiges Team ist. Es ist eine natürliche Konsequenz der Verwaltung von Infrastruktur mit mehreren Personen, konkurrierenden Prioritäten und unterschiedlichem Zeitdruck. Jedes Team, das Produktionsinfrastruktur betreibt, erlebt Drift. Der Unterschied zwischen Teams, die gut damit umgehen, und Teams, die kämpfen, ist nicht, ob Drift existiert. Es ist, ob sie wissen, dass er existiert, und eine Möglichkeit haben, ihn zu erkennen.

Ein Team, das Drift ignoriert, verliert irgendwann das Vertrauen in seine gesamte Bereitstellungspipeline. Es hört auf, Plänen zu vertrauen. Es beginnt, mehr manuelle Änderungen vorzunehmen, weil es der Automatisierung nicht vertraut. Die Infrastruktur wird zu einer Blackbox, die niemand anfassen will.

Ein Team, das Drift anerkennt, baut die Erkennung in seinen Workflow ein. Es führt regelmäßige Drift-Checks durch. Es hat Prozesse, um Code mit der Realität abzugleichen. Es behandelt Drift als normalen Teil des Infrastrukturmanagements, nicht als ein zu verbergendes Versagen.

Eine praktische Checkliste zur Drift-Erkennung

Wenn Sie Infrastruktur mit IaC verwalten, finden Sie hier eine kurze Checkliste, um mit Drift umzugehen:

  • Führen Sie mindestens einmal pro Woche einen Plan gegen Ihre Produktionsumgebung aus, auch wenn Sie nichts bereitstellen. Überprüfen Sie die Ausgabe auf unerwartete Änderungen.
  • Richten Sie eine automatisierte Drift-Erkennung ein. Die meisten IaC-Tools haben Funktionen oder Integrationen, die Sie alarmieren können, wenn der Ist-Zustand vom Soll-Zustand abweicht.
  • Planen Sie nach jedem Vorfall Zeit ein, um Ihren IaC-Code zu aktualisieren, damit er mit allen Notfalländerungen übereinstimmt.
  • Dokumentieren Sie, welche externen Tools und Prozesse Ihre Infrastruktur außerhalb Ihrer Pipeline modifizieren. Wissen Sie, was sich automatisch ändert und warum.
  • Wenn Sie Drift in einem Plan sehen, untersuchen Sie ihn, bevor Sie ihn anwenden. Verstehen Sie, was die Abweichung verursacht hat und ob es sicher ist, sie rückgängig zu machen.

Was als Nächstes kommt

Drift verursacht nicht nur operative Kopfschmerzen. Er macht die Ausgabe Ihrer IaC-Planungstools unzuverlässig. Wenn Sie einen Plan gegen driftende Infrastruktur ausführen, können die Ergebnisse irreführend sein. Sie könnten Änderungen sehen, die harmlos aussehen, aber tatsächlich kritische Konfigurationen rückgängig machen. Oder Sie könnten Änderungen übersehen, die hätten vorgenommen werden sollen, weil der Plan nicht das zeigt, was Sie erwarten.

Die eigentliche Gefahr besteht darin, dass Drift das Fundament des Vertrauens untergräbt, das Infrastructure as Code wertvoll macht. Ohne Vertrauen in Ihre Pipeline verlieren Sie die Zuversicht, Änderungen schnell und sicher vorzunehmen. Und diese Zuversicht ist der eigentliche Sinn der Automatisierung Ihrer Infrastruktur.