Warum das Zurücksetzen von Infrastruktur nicht mit dem Zurücksetzen einer Anwendung vergleichbar ist

Sie pushen ein fehlerhaftes Anwendungsupdate. Benutzer sehen Fehlermeldungen. Ihr Team schaltet den Load Balancer zurück auf die vorherige Version, oder die Pipeline stellt das alte Artefakt wieder bereit. Innerhalb weniger Minuten läuft die App wieder mit dem alten Code. Die Daten sind intakt. Die Datenbank hat sich nicht verändert. Die Server sind dieselben Maschinen wie zuvor. Das Problem ist behoben.

Das ist ein Anwendungs-Rollback. Es funktioniert, weil Anwendungen meist zustandslos sind. Sie tauschen den Code aus, und das alte Verhalten kehrt zurück. Keine bleibenden Nebeneffekte.

Stellen Sie sich nun vor, Sie haben eine Firewall-Regel geändert, eine Datenbankfestplatte vergrößert oder eine Subnetz-Konfiguration aktualisiert. Etwas geht kaputt. Sie möchten zurück. Können Sie einfach die alte Konfiguration erneut anwenden und erwarten, dass alles funktioniert?

Wahrscheinlich nicht.

Infrastruktur-Rollback ist eine andere Art von Problem. Die beteiligten Ressourcen enthalten Daten, verwalten Netzwerkpfade und bieten grundlegende Dienste, von denen andere Systeme abhängen. Wenn Sie die Infrastruktur ändern, tauschen Sie nicht nur Code aus. Sie verändern den Zustand von etwas, das möglicherweise jahrelange Daten, Verbindungen zu Dutzenden von Diensten oder eine Rolle als Fundament für alles darüber Liegende hat.

Zustand ist das erste Problem

Anwendungen sind als wegwerfbar konzipiert. Sie können einen Container töten, einen neuen mit altem Code starten, und die Anwendung beginnt frisch. Keine Erinnerung an die vorherige Version. Keine übriggebliebenen Daten aus dem fehlgeschlagenen Deployment.

Infrastruktur ist das Gegenteil. Eine Datenbank behält ihre Daten, auch wenn Sie ihre Konfiguration ändern. Ein Datenträger behält seine Dateien, auch wenn Sie ihn vergrößern. Diese Ressourcen sind zustandsbehaftet. Sie halten einen Zustand, der über den Lebenszyklus jeder Konfigurationsänderung hinaus bestehen bleibt.

Wenn Sie eine Anwendung zurücksetzen, stellen Sie nur den Code wieder her. Wenn Sie Infrastruktur zurücksetzen, müssen Sie die Konfiguration wiederherstellen, ohne die Daten zu zerstören, die sich in der Ressource angesammelt haben. Das ist nicht immer möglich.

Hier ist ein konkretes Beispiel. Sie upgraden einen Datenbank-Instanztyp von klein auf groß, weil der Traffic gestiegen ist. Der neue Instanztyp hat ein Problem. Sie möchten zurück zum kleinen Instanztyp. Aber während der Zeit, in der der große Instanztyp lief, wurden mehr Daten in die Datenbank geschrieben. Der alte kleine Instanztyp kann diese Daten nicht mehr aufnehmen. Ein Rollback ist nicht sicher. Sie können die Instanz nicht verkleinern, ohne Daten zu verlieren, und Sie können die Daten nicht behalten, wenn Sie zurückwechseln.

Der Unterschied wird deutlich, wenn man die beiden Pfade nebeneinander vergleicht.

flowchart TD A[Fehlerhafte Änderung deployed] --> B{Handelt es sich um eine App?} B -->|Ja| C[Code über LB oder Pipeline tauschen] C --> D[Alter Code läuft, keine Nebeneffekte] D --> E[Rollback erfolgreich] B -->|Nein, es ist Infra| F[Stateful Ressourcen identifizieren] F --> G{Kann der Zustand erhalten bleiben?} G -->|Nein| H[Rollback kann Daten zerstören] G -->|Ja| I[Abhängigkeiten prüfen] I --> J[Geordnete Rollback-Sequenz] J --> K[Teilweiser oder defekter Zustand] K --> L[Wiederherstellung nötig, nicht nur Rollback]

Dies ist kein Tool-Problem. Dies ist eine grundlegende Einschränkung zustandsbehafteter Ressourcen. Der Akt des Ausführens der neuen Konfiguration verändert die Ressource auf eine Weise, die die alte Konfiguration nicht aufnehmen kann.

Abhängigkeiten vervielfachen das Risiko

Infrastrukturressourcen existieren selten allein. Eine Änderung kann zehn miteinander verbundene Ressourcen betreffen: ein VPC, ein Subnetz, eine Sicherheitsgruppe, einen Load Balancer, mehrere Instanzen und eine Datenbank. Jede Ressource hängt auf spezifische Weise von den anderen ab.

Wenn Sie eine Ressource zurücksetzen, sind die davon abhängigen Ressourcen betroffen. Das Wiederherstellen einer alten Sicherheitsgruppe kann die Kommunikation zwischen dem Load Balancer und den Instanzen unterbrechen. Das Wiederherstellen eines Subnetzes kann die Datenbankverbindung kappen. Rollback ist keine einzelne Operation. Es ist eine Sequenz, die sorgfältig geordnet werden muss, und die Reihenfolge hängt davon ab, wie die Ressourcen ursprünglich erstellt wurden und wie sie sich seitdem verändert haben.

In der Praxis bedeutet das, dass Sie nicht einfach terraform apply auf der alten Zustandsdatei ausführen und gehen können. Der alte Zustand kann mit dem aktuellen Zustand anderer Ressourcen, die nicht zurückgesetzt wurden, kollidieren. Das Ergebnis ist oft eine teilweise Wiederherstellung, die Ihre Infrastruktur in einem defekten Zustand hinterlässt.

Idempotentes Anwenden bedeutet nicht sicheres Rollback

Infrastruktur-Pipelines sind als idempotent konzipiert. Sie können dieselbe Konfiguration mehrmals ausführen und dasselbe Ergebnis erzielen. Das funktioniert gut für das Anwenden von Änderungen. Aber idempotentes Anwenden bedeutet nicht sicheres Rollback.

Betrachten Sie die Festplattengröße. Sie deklarieren eine Festplatte von 100 GB, wenden sie an, und die Festplatte wird erstellt. Sie führen dieselbe Konfiguration erneut aus, und nichts ändert sich. Das ist idempotent. Jetzt ändern Sie die Konfiguration auf 200 GB und wenden sie an. Die Festplatte wächst. Dann ändern Sie die Konfiguration zurück auf 100 GB und wenden sie erneut an. Was passiert?

Die meisten Infrastruktur-Tools werden entweder die Operation ablehnen oder die Festplatte zerstören und eine neue erstellen. Sie können eine Festplatte nicht verkleinern, ohne Datenverlust zu riskieren. Die Konfiguration ist theoretisch idempotent, aber die tatsächliche Ressource hat sich auf eine Weise verändert, die nicht rückgängig gemacht werden kann.

Dies wird als Zustandsdrift bezeichnet. Die Konfiguration in Ihrem Code sagt etwas, aber die tatsächliche Ressource in der Cloud oder auf dem Server ist anders. Wenn Sie versuchen, ein Rollback durchzuführen, machen Sie nicht nur Code rückgängig. Sie versuchen, eine Konfiguration in Einklang zu bringen, die nicht mehr der Realität entspricht. Und die Realität gewinnt oft.

Was das für Ihr Team bedeutet

Infrastruktur-Rollback erfordert eine andere Art der Vorbereitung als Anwendungs-Rollback. Sie können sich nicht auf dieselbe Pipeline oder dasselbe mentale Modell verlassen. Sie müssen wissen, welche Ressourcen sicher zurückgesetzt werden können, welche nicht und welche Reihenfolge einzuhalten ist.

Einige Änderungen sind umkehrbar. Das Ändern der Health-Check-Konfiguration eines Load Balancers ist normalerweise sicher zurückzusetzen. Das Ändern einer Datenbank-Parametergruppe könnte sicher sein, wenn die neuen Parameter keine gespeicherten Daten verändert haben. Aber das Ändern der Instanzgröße, der Festplattengröße, der Netzwerktopologie oder der Speicher-Engine ist oft ohne Datenverlust oder Ausfallzeiten nicht umkehrbar.

Der sicherste Ansatz ist, für die Wiederherstellung zu planen, nicht nur für das Rollback. Wiederherstellung bedeutet zu akzeptieren, dass die alte Konfiguration möglicherweise nicht mehr gültig ist und einen Weg nach vorne statt nach hinten zu bauen. Dies könnte das Erstellen einer neuen Ressource mit der alten Konfiguration und das Migrieren von Daten oder das Akzeptieren eines degradierten Zustands umfassen, während eine Lösung entwickelt wird.

Praktische Checkliste für Infrastrukturänderungen

Bevor Sie eine Infrastrukturänderung anwenden, stellen Sie diese Fragen:

  • Enthält diese Ressource einen Zustand? Wenn ja, kann der Zustand erhalten bleiben, wenn wir die Konfiguration rückgängig machen?
  • Welche anderen Ressourcen hängen von dieser ab? Wird ein Rollback ihre Konnektivität unterbrechen?
  • Ist die Änderung umkehrbar? Kann das Tool eine Festplatte verkleinern, eine Instanz herabstufen oder einen Netzwerkpfad wiederherstellen, ohne Daten zu zerstören?
  • Was ist der tatsächliche Wiederherstellungsplan, wenn die Änderung fehlschlägt? Ist es ein Rollback, eine Migration oder ein Neuaufbau?
  • Haben wir den Wiederherstellungspfad in einer Nicht-Produktionsumgebung getestet?

Fazit

Anwendungs-Rollback ist ein Code-Tausch. Infrastruktur-Rollback ist ein Problem der Zustandsabstimmung. Wenn Sie beide gleich behandeln, führt das zu kaputten Systemen, Datenverlust und langen Wiederherstellungszeiten. Planen Sie für die Wiederherstellung, nicht nur für das Rollback. Wissen Sie, welche Änderungen umkehrbar sind, und testen Sie Ihren Wiederherstellungspfad, bevor Sie ihn brauchen.