Ihre Cloud-Infrastruktur driftet von Ihrem Code weg – So erkennen Sie es

Sie haben Ihre Infrastruktur als Code geschrieben. Sie haben terraform plan ausgeführt, die Ausgabe geprüft und die Änderungen angewendet. Die Ressourcen erscheinen in der Cloud-Konsole. Das Team feiert einen weiteren erfolgreichen Deployment. Die Arbeit ist erledigt.

Oder etwa nicht?

Eine Woche später meldet sich jemand mit Admin-Zugriff auf einem Server an und passt eine Konfiguration an, um ein dringendes Problem zu beheben. Das Sicherheitsteam fügt über das Cloud-Dashboard eine Firewall-Regel hinzu, ohne jemanden zu informieren. Ihr Cloud-Anbieter stellt einen API-Endpunkt ein, und die Konfiguration, die letzten Monat einwandfrei funktioniert hat, tut jetzt still und leise nichts Nützliches mehr.

Keine dieser Änderungen hat Ihr Repository berührt. Keine davon durchlief ein Code-Review. Keine ist irgendwo dokumentiert, wo Ihr Team sie später finden könnte. Ihre Infrastruktur unterscheidet sich nun von dem, was Ihr Code beschreibt. Sie haben ein Problem.

Diese Situation hat einen Namen: Drift. Es bedeutet, dass der tatsächliche Zustand Ihrer Infrastruktur nicht mehr mit dem gewünschten Zustand in Ihrem Code übereinstimmt. Drift ist gefährlich, weil er das Versprechen von Infrastructure as Code leise bricht. Wenn Sie eine Umgebung von Grund auf neu erstellen müssen, wird das Ergebnis anders aussehen. Wenn ein Incident passiert, können Sie nicht darauf vertrauen, dass die Ausführung desselben Codes einen sicheren Zustand wiederherstellt. Sie haben die Fähigkeit verloren, Ihre Infrastruktur zuverlässig zu reproduzieren.

Wie Drift in der Praxis entsteht

Drift wird nicht von böswilligen Akteuren oder inkompetenten Teams verursacht. Er entsteht durch normale, gut gemeinte Aktionen, die die Pipeline umgehen.

Ein Entwickler muss schnell etwas testen und ändert manuell eine Security-Group-Regel. Ein Datenbankadministrator passt einen Parameter an, um einen plötzlichen Lastspitzen zu bewältigen. Ein Plattformingenieur patcht einen Server direkt, weil der automatisierte Patch-Prozess zu lange dauert. Jede dieser Aktionen ergibt im Moment Sinn. Jede erzeugt eine Lücke zwischen dem, was Ihr Code sagt, und dem, was tatsächlich läuft.

Das Problem verstärkt sich mit der Zeit. Aus einer manuellen Änderung werden zwei, dann zehn. Nach ein paar Monaten hat die in Produktion laufende Infrastruktur kaum noch Ähnlichkeit mit dem Code in Ihrem Repository. Wenn das nächste Mal jemand terraform apply in der Erwartung eines sauberen Zustands ausführt, erhält er eine lange Liste unerwarteter Änderungen. Niemand weiß, welche Änderungen beabsichtigt und welche Unfälle sind. Das Vertrauen in den Infrastrukturcode schwindet.

Drift erkennen, bevor er Probleme verursacht

Die Lösung ist nicht, manuelle Änderungen zu verbieten. Manchmal muss man schnell handeln, und die Pipeline ist zu langsam. Die Lösung ist, Drift automatisch und regelmäßig zu erkennen, sodass Sie davon wissen, bevor er einen Incident verursacht.

Drift-Erkennung ist ein Prozess, der den tatsächlichen Zustand Ihrer Infrastruktur mit dem gewünschten Zustand in Ihrem Code vergleicht. Er läuft nach einem Zeitplan oder wird durch bestimmte Ereignisse ausgelöst. Wenn er Unterschiede findet, zeichnet er die Details auf: welche Ressource geändert wurde, welcher Teil der Konfiguration anders ist und welcher Wert korrekt sein sollte.

Die meisten Infrastructure-as-Code-Tools unterstützen die Drift-Erkennung nativ. Terraform hat terraform plan, das Unterschiede zwischen Zustand und Konfiguration anzeigt. Pulumi hat Vorschau-Befehle. AWS CloudFormation hat eine integrierte Drift-Erkennung im Service. Der Schlüssel ist, diese Prüfungen automatisch auszuführen, nicht nur, wenn jemand daran denkt.

Hier ist ein einfacher Befehl, den Sie in Ihrer CI-Pipeline ausführen können, um Drift automatisch zu erkennen:

#!/bin/bash
# Run terraform plan and exit with a non-zero code if drift is detected
terraform init -input=false
terraform plan -detailed-exitcode -input=false -out=tfplan
PLAN_EXIT_CODE=$?

if [ $PLAN_EXIT_CODE -eq 2 ]; then
  echo "Drift detected! Infrastructure does not match code."
  # Send alert to Slack or your incident management tool
  curl -X POST -H 'Content-type: application/json' \
    --data '{"text":"Drift detected in production environment. Run terraform apply to reconcile."}' \
    YOUR_SLACK_WEBHOOK_URL
  exit 1
elif [ $PLAN_EXIT_CODE -eq 1 ]; then
  echo "Error running terraform plan."
  exit 1
else
  echo "No drift detected. Infrastructure matches code."
fi

Dieses Skript verwendet -detailed-exitcode, um zwischen einem sauberen Zustand (Exit-Code 0), einem Fehler (Exit-Code 1) und Drift (Exit-Code 2) zu unterscheiden.

Drift-Erkennung in Ihre Pipeline einbauen

Eine praktische Drift-Erkennungs-Pipeline sieht so aus:

Hier ist eine visuelle Übersicht der Drift-Erkennungs-Pipeline:

flowchart TD A[Code Commit] --> B[Plan] B --> C[Apply] C --> D{Drift Check} D -- Periodic or Event-Triggered --> E{Drift Found?} E -- No --> D E -- Yes --> F[Alert Team] F --> G{Decision} G -- Revert --> H[Reconcile] G -- Accept --> I[Update Code] H --> D I --> D

  1. Planen Sie regelmäßige Prüfungen ein. Führen Sie die Drift-Erkennung alle paar Stunden oder täglich durch, je nachdem, wie kritisch Ihre Infrastruktur ist. Für Produktionsumgebungen sind häufigere Prüfungen besser. Für Staging-Umgebungen können tägliche Prüfungen ausreichen.

  2. Reagieren Sie auf verdächtige Ereignisse. Einige Cloud-Anbieter geben Ereignisse aus, wenn Ressourcen außerhalb Ihrer Pipeline geändert werden. Verwenden Sie Webhooks oder Ereignisprotokolle, um eine Drift-Prüfung auszulösen, wenn diese Ereignisse auftreten.

  3. Melden Sie die Ergebnisse. Wenn Drift erkannt wird, senden Sie eine Benachrichtigung an das Team. Verwenden Sie Slack, E-Mail oder erstellen Sie ein Issue in Ihrem Tracker. Die Benachrichtigung sollte enthalten, welche Ressourcen abgedriftet sind und welche Werte erwartet werden.

  4. Lassen Sie das Team entscheiden, was zu tun ist. Nicht jeder Drift ist schlecht. Eine manuelle Änderung könnte legitim sein und in den Code übernommen werden. Eine andere Änderung könnte versehentlich sein und rückgängig gemacht werden müssen. Das Team muss den Drift sehen und eine Entscheidung treffen.

Automatische Korrektur: Vorsicht ist geboten

Manche Teams gehen einen Schritt weiter und automatisieren die Korrektur. Wenn die Pipeline Drift erkennt, führt sie sofort apply aus, um die Infrastruktur wieder in den gewünschten Zustand zu versetzen. Dieser Ansatz funktioniert gut für Umgebungen, die konsistent bleiben müssen, wie Staging oder streng kontrollierte Produktionssysteme.

Aber die automatische Korrektur birgt Risiken. Denken Sie an Auto-Scaling: Ihre Infrastructure as Code definiert eine minimale und maximale Anzahl von Instanzen. Eine Auto-Scaling-Gruppe fügt Instanzen basierend auf der Last hinzu. Ein Drift-Erkennungslauf sieht die zusätzlichen Instanzen als Drift an und beendet sie. Ihre Benutzer erleben eine Unterbrechung, weil das System genau das tat, was es tun sollte.

Die Faustregel lautet: Automatisieren Sie die Korrektur nur für Ressourcen, die sich niemals außerhalb der Pipeline ändern sollten. Für alles andere benachrichtigen Sie das Team und lassen es entscheiden.

Eine praktische Checkliste für die Drift-Erkennung

Hier ist eine kurze Checkliste, die Ihnen den Einstieg in die Drift-Erkennung erleichtert:

  • Wählen Sie einen Zeitplan für Drift-Prüfungen (alle 6 Stunden für Produktion, täglich für Staging)
  • Konfigurieren Sie Benachrichtigungen für den richtigen Kanal (Slack, E-Mail oder Incident-Management-Tool)
  • Entscheiden Sie, welche Umgebungen automatische Korrektur erhalten und welche manuelle Überprüfung benötigen
  • Testen Sie den Drift-Erkennungsprozess, indem Sie eine kleine manuelle Änderung vornehmen und die Warnung überprüfen
  • Überprüfen Sie Drift-Berichte wöchentlich im Team, um Muster oder wiederkehrende Probleme zu identifizieren

Was Ihnen die Drift-Erkennung bringt

Die Drift-Erkennung verhindert keine manuellen Änderungen. Sie macht die Incident-Response nicht überflüssig. Was sie tut, ist, Ihnen Sichtbarkeit in die Lücke zwischen Ihrem Code und der Realität zu geben. Wenn Sie von Drift wissen, können Sie entscheiden, ob Sie ihn akzeptieren, rückgängig machen oder Ihren Code aktualisieren, um ihn abzubilden.

Ohne Drift-Erkennung ist Ihre Infrastructure as Code eine Fiktion. Sie mögen glauben, Ihr System sei reproduzierbar, aber Sie haben keine Möglichkeit, es zu überprüfen. Mit Drift-Erkennung bleibt Ihr Code die einzige Quelle der Wahrheit, weil Sie diese Wahrheit aktiv aufrechterhalten.

Wenn das nächste Mal jemand sagt „wir verwenden Infrastructure as Code“, fragen Sie ihn: „Woher wissen Sie, dass Ihre Infrastruktur noch mit Ihrem Code übereinstimmt?“ Wenn er keine Antwort hat, hat er Drift. Und Drift ist eine Zeitbombe, die beim nächsten Incident hochgeht.