Wenn die Infrastruktur abweicht: Wie Sie entscheiden, ob Sie sie reparieren oder akzeptieren

Sie öffnen an einem Montagmorgen Ihr Infrastruktur-Dashboard. Auf den ersten Blick sieht alles gut aus. Dann fällt es Ihnen auf: Die Datenbankinstanzgröße weicht von dem ab, was Ihr Terraform-Code definiert. Jemand hat sie übers Wochenende über die Cloud-Konsole geändert. Die Pipeline wurde nicht ausgeführt. Der Code sagt das eine, die tatsächliche Infrastruktur etwas anderes.

Das ist Drift. Es passiert häufiger, als die meisten Teams zugeben. Jemand nimmt während eines Incidents eine manuelle Änderung vor. Ein Cloud-Anbieter aktualisiert automatisch eine Ressourceneigenschaft. Ein Teammitglied ändert direkt eine Sicherheitsgruppenregel, weil es schnell gehen musste. Was auch immer die Ursache ist – Sie haben jetzt eine Lücke zwischen dem, was Ihr Code deklariert, und dem, was tatsächlich in Ihrer Infrastruktur existiert.

Die Frage ist nicht, ob Drift auftritt. Er wird auftreten. Die eigentliche Frage ist, was Sie tun, nachdem Sie ihn erkannt haben.

Die drei Wege zur Rekonziliation

Rekonziliation ist der Prozess, Ihre Infrastruktur wieder mit Ihren Code-Definitionen in Einklang zu bringen. Es gibt jedoch keinen einzigen richtigen Weg. Der beste Ansatz hängt von der Situation, dem damit verbundenen Risiko und dem Kontext der Änderung ab.

Nutzen Sie diesen Entscheidungsbaum, um schnell den passenden Weg für Ihre Situation zu finden:

flowchart TD A[Drift erkannt] --> B{Weißt du, warum es passiert ist?} B -- Nein --> C[Erst untersuchen] B -- Ja --> D{War es beabsichtigt?} D -- Nein --> E[Pipeline erneut ausführen] D -- Ja --> F{Änderung vorteilhaft?} F -- Ja --> G[Drift übernehmen] F -- Nein --> H{Ressource im Live-Betrieb?} H -- Ja --> I[Manuelle Behebung] H -- Nein --> E C --> D

Weg Eins: Pipeline erneut ausführen

Die einfachste Option ist, Ihre Pipeline erneut auszuführen, ohne den Code zu ändern. Sie nehmen Ihren vorhandenen Infrastructure as Code (IaC), lassen ihn genau so, wie er ist, und führen den Apply-Schritt aus. Tools wie Terraform, Pulumi oder AWS CloudFormation vergleichen die Statusdatei mit den tatsächlichen Ressourcen und nehmen die notwendigen Anpassungen vor, um alles auf den vom Code definierten Zustand zurückzusetzen.

Dies funktioniert gut, wenn Drift versehentlich auftritt. Jemand hat eine Instanz über die Konsole vergrößert, ohne zu merken, dass er die Pipeline umgangen hat. Ein Entwickler hat vorübergehend einen Sicherheitsgruppen-Port zum Debuggen geöffnet und vergessen, ihn wieder zu schließen. Ein geplanter Job eines anderen Teams hat ein Tag auf Ihren Ressourcen geändert. In diesen Fällen ist das erneute Ausführen der Pipeline sauber und sicher. Der Code repräsentiert den gewünschten Zustand, und die Infrastruktur muss lediglich aufholen.

Das Risiko ist hier gering, da die Änderungen nicht beabsichtigt waren. Sie korrigieren einen Fehler, Sie überschreiben keine bewusste Entscheidung.

Weg Zwei: Drift übernehmen

Manchmal war die manuelle Änderung tatsächlich die richtige Entscheidung. Während eines Produktionsincidents hat Ihr Betriebsteam die Datenbank hochskaliert, um einen Traffic-Spike zu bewältigen. Die Anwendung blieb dank dieser Änderung verfügbar. Nach dem Incident stellen Sie fest, dass die neue Kapazität besser zu Ihrer aktuellen Arbeitslast passt. Der alte Wert in Ihrem Code ist nun veraltet.

In diesem Fall wäre es ein Fehler, zum alten Code zurückzukehren. Sie würden eine Lösung rückgängig machen, die Ihr System am Laufen gehalten hat. Stattdessen aktualisieren Sie Ihren IaC, um den neuen Zustand abzubilden. Dies wird als „Drift übernehmen“ bezeichnet. Sie ändern den Code so, dass er dem tatsächlich laufenden System entspricht, und führen dann die Pipeline aus, um die Konsistenz zu bestätigen.

Das Übernehmen von Drift hält Ihre Pipeline als einzige Quelle der Wahrheit, während Änderungen, die sich als nützlich erwiesen haben, erhalten bleiben. Es erfordert jedoch eine sorgfältige Bewertung. Sie müssen verstehen, warum die Änderung vorgenommen wurde, ob sie getestet wurde und ob sie Nebenwirkungen verursacht. Das Übernehmen von Drift ohne Überprüfung kann Ihren IaC in eine unübersichtliche Sammlung undokumentierter Entscheidungen verwandeln.

Weg Drei: Manuelle Behebung

Es gibt Situationen, in denen die Ausführung einer automatisierten Pipeline zu riskant ist. Die abweichende Ressource ist im Live-Betrieb. Eine Sicherheitsgruppenänderung schützt einen kritischen Endpunkt. Eine Load-Balancer-Konfiguration verteilt Anfragen auf Instanzen. Wenn Ihre Pipeline Änderungen automatisch anwendet, könnte dies zu einer kurzen Unterbrechung oder sogar einem vollständigen Ausfall führen.

In diesen Fällen ist die manuelle Behebung die sicherere Wahl. Jemand mit Zugriff auf die Cloud-Konsole oder den Server prüft die Änderungen einzeln, macht sie sorgfältig rückgängig und überwacht die Auswirkungen in Echtzeit. Dies ist langsamer und arbeitsintensiver, gibt Ihnen aber die Kontrolle über die Reihenfolge und den Zeitpunkt jeder Änderung.

Manuelle Behebung ist kein Versagen der Automatisierung. Es ist die Anerkennung, dass einige Ressourcen während der Wiederherstellung menschliches Urteilsvermögen erfordern. Der Schlüssel ist, zu dokumentieren, was getan wurde und warum, damit Sie beim nächsten Auftreten desselben Drifts entscheiden können, ob Sie die Behebung automatisieren.

Wer sollte entscheiden?

Rekonziliation ist keine rein technische Entscheidung. Sie erfordert Kontext. Wurde der Drift durch einen Fehler, einen Incident oder ein Experiment verursacht, das nie dokumentiert wurde? Die Antwort bestimmt, welcher Weg der richtige ist.

Die Entscheidung sollte die Personen einbeziehen, die die Änderung und ihre Auswirkungen verstehen. Das könnte das Betriebsteam sein, das den Incident bearbeitet hat, der Entwickler, der die manuelle Korrektur vorgenommen hat, oder der Plattformingenieur, der das Systemverhalten überwacht. Eine einzelne Person, die die Entscheidung isoliert trifft, kann die Situation leicht falsch einschätzen.

Eine einfache Faustregel: Wenn Sie nicht wissen, warum der Drift aufgetreten ist, führen Sie keine automatische Rekonziliation durch. Untersuchen Sie zuerst. Führen Sie die Pipeline nur dann erneut aus, wenn Sie sicher sind, dass die Änderung unbeabsichtigt war. Übernehmen Sie den Drift nur, wenn Sie sicher sind, dass die Änderung vorteilhaft war. Beheben Sie manuell, wenn Sie sich bei beidem nicht sicher sind.

Eine praktische Checkliste für Rekonziliationsentscheidungen

Bevor Sie auf einen Drift-Erkennungsalarm reagieren, gehen Sie diese Fragen durch:

  • Weiß ich, wer diese Änderung vorgenommen hat und warum?
  • Wurde diese Änderung während eines Incidents oder unter Zeitdruck vorgenommen?
  • Befindet sich die abweichende Ressource derzeit im Produktionsbetrieb?
  • Würde das Rückgängigmachen dieser Änderung ein bekanntes Problem verursachen?
  • Gibt es eine Aufzeichnung dieser Änderung in einem Ticket, Chat oder Runbook?

Wenn die Antwort auf die erste Frage Nein lautet, beginnen Sie mit der Untersuchung, nicht mit der Aktion. Wenn die Ressource im Live-Betrieb ist, bevorzugen Sie die manuelle Behebung gegenüber der automatischen Anwendung. Wenn die Änderung während eines Incidents vorgenommen wurde, ziehen Sie in Betracht, den Drift nach einer ordnungsgemäßen Überprüfung zu übernehmen.

Rekonziliation ist nicht das Ende

Nach der Rekonziliation ist die Arbeit noch nicht getan. Sie müssen bestätigen, dass die Rekonziliation keine neuen Probleme verursacht hat. Ein automatischer Apply, der einen kritischen Sicherheitsfix rückgängig macht, kann Ihr System angreifbar machen. Eine manuelle Änderung, die ohne Tests übernommen wurde, kann Instabilität verursachen.

Das Ziel ist nicht, Drift zu eliminieren. Das Ziel ist, ihn so zu handhaben, dass Ihr System zuverlässig und Ihr Code aussagekräftig bleibt. Jedes Drift-Ereignis ist auch eine Gelegenheit, Ihre Prozesse zu verbessern. Wenn derselbe Drift immer wieder auftritt, braucht Ihre Pipeline vielleicht eine Schutzmaßnahme. Wenn manuelle Änderungen zu häufig vorkommen, braucht Ihr Incident-Response-Prozess vielleicht einen klareren Weg für Code-Updates nach einem Incident.

Die konkrete Erkenntnis

Drift ist kein Zeichen dafür, dass Ihre Infrastruktur kaputt ist. Es ist ein Zeichen dafür, dass etwas außerhalb Ihrer Pipeline passiert ist. Die richtige Reaktion hängt vom Kontext ab, nicht von Dogmen. Führen Sie die Pipeline erneut aus, wenn die Änderung versehentlich war. Übernehmen Sie den Drift, wenn die Änderung nützlich war. Beheben Sie manuell, wenn das Risiko hoch ist. Und verstehen Sie immer, warum der Drift aufgetreten ist, bevor Sie entscheiden, was als Nächstes zu tun ist.