Wenn Infrastrukturänderungen schiefgehen: Wiederherstellungsoptionen von Neu anwenden bis Failover

Sie haben gerade terraform apply auf Ihrer Produktionsinfrastruktur ausgeführt. Die Ausgabe sieht sauber aus. Keine Fehler. Dann feuert Ihr Monitoring-Alarm: Benutzer können keine Verbindung zur Datenbank herstellen. Die von Ihnen vorgenommene Sicherheitsgruppenänderung hat versehentlich die Anwendungsschicht blockiert.

Was nun?

Dieser Moment trennt Teams mit einem Wiederherstellungsplan von Teams, die hektisch nach der letzten bekannten guten Konfiguration suchen. Infrastrukturänderungen können auf eine Weise fehlschlagen, die Application-Rollbacks nicht abdecken. Ein schlechter Konfigurations-Push mag Ihren Code nicht brechen, aber er kann Konnektivität, Speicher oder Zugriffskontrollen beeinträchtigen. Die Wiederherstellung braucht ihr eigenes Playbook.

Lassen Sie uns vier Wiederherstellungsoptionen durchgehen, von der einfachsten bis zur komplexesten. Jede passt zu unterschiedlichen Situationen, und jede bringt Kompromisse mit sich, die Sie verstehen müssen, bevor Sie sie brauchen.

Alten Zustand erneut anwenden

Der direkteste Ansatz: Bringen Sie Ihre Infrastruktur zurück zur Konfiguration, die sie vor der Änderung hatte.

Wenn Sie Terraform verwenden, bedeutet dies, terraform apply mit der vorherigen Zustandsdatei oder Konfiguration auszuführen. Das gleiche Prinzip gilt für Pulumi, CloudFormation oder jedes Infrastructure-as-Code-Tool. Sie weisen das System an, die bekannte gute Version Ihrer Infrastrukturdefinition wiederherzustellen.

Dies funktioniert gut, wenn die Änderung idempotent ist und die beteiligten Ressourcen keine kritischen Daten enthalten. Denken Sie an Sicherheitsgruppenregeln, Umgebungsvariablen auf Compute-Instanzen oder Load-Balancer-Einstellungen. Diese Ressourcen können ohne Nebenwirkungen hin- und hergeschaltet werden.

Hier ist eine konkrete Befehlssequenz, um den alten Zustand erneut anzuwenden:

# 1. Prüfen, ob die vorherige Zustandsdatei existiert
ls -la terraform.tfstate.backup

# 2. Vorherigen Zustand wiederherstellen (überschreibt aktuellen Zustand)
cp terraform.tfstate.backup terraform.tfstate

# 3. Vorschau der Änderungen, die Terraform zum Zurücksetzen vornehmen wird
terraform plan -state=terraform.tfstate

# 4. Alten Zustand anwenden, um die Infrastruktur wiederherzustellen
terraform apply -state=terraform.tfstate -auto-approve

Hinweis: Überprüfen Sie immer, ob die Backup-Zustandsdatei gültig ist, bevor Sie sie anwenden. Führen Sie terraform state list -state=terraform.tfstate.backup aus, um zu bestätigen, dass sie die erwarteten Ressourcen enthält.

Der Haken: Sie benötigen den alten Zustand, der noch existiert. Wenn Ihr Team alte Zustandsdateien entfernt oder der Infrastrukturanbieter einige Ressourcen bereinigt hat, haben Sie möglicherweise nichts, was Sie erneut anwenden können. Außerdem hat dieser Ansatz Schwierigkeiten mit zustandsbehafteten Ressourcen. Sie können nicht einfach eine alte Datenbankkonfiguration erneut anwenden und erwarten, dass die Daten in ihren vorherigen Zustand zurückkehren.

Erneutes Anwenden ist schnell, erfordert minimale manuelle Eingriffe und funktioniert für die meisten zustandslosen Infrastrukturänderungen. Aber es ist keine universelle Lösung.

Snapshot-Wiederherstellung

Wenn Ihre Änderung Ressourcen betrifft, die Daten enthalten, reicht erneutes Anwenden nicht aus. Sie müssen die Daten selbst wiederherstellen.

Bevor Sie eine Änderung an einer Datenbank, einem Dateisystem oder einer anderen zustandsbehafteten Ressource vornehmen, erstellen Sie einen Snapshot. Cloud-Anbieter bieten dies für Volumes, Datenbanken und Storage-Buckets an. Der Snapshot erfasst den Zustand der Ressource zu einem bestimmten Zeitpunkt.

Wenn die Änderung fehlschlägt, stellen Sie aus diesem Snapshot wieder her. Die Datenbank kehrt in ihren Zustand vor der Änderung zurück. Das Dateisystem erhält seinen vorherigen Inhalt zurück.

Dieser Ansatz ist schwerfälliger als erneutes Anwenden. Das Wiederherstellen eines Snapshots dauert Zeit. Während dieser Zeit ist die Ressource möglicherweise nicht verfügbar. Benutzer sehen Fehler oder einen degradierten Dienst. Aber für zustandsbehaftete Ressourcen ist die Snapshot-Wiederherstellung oft die einzig zuverlässige Option.

Sie funktioniert am besten, wenn der Schaden auf eine Ressource oder Komponente begrenzt ist. Wenn Sie ein Datenbankschema geändert haben und es die Anwendung beschädigt hat, behebt die Wiederherstellung des Datenbank-Snapshots die Datenebene. Die Anwendung muss möglicherweise neu gestartet werden, aber die Daten sind wieder normal.

Der Hauptnachteil: Sie verlieren alle Daten, die zwischen dem Snapshot und der fehlgeschlagenen Änderung geschrieben wurden. Wenn Ihre Anwendung kontinuierlich schreibt, ist diese Lücke relevant. Planen Sie Ihr Snapshot-Timing entsprechend.

DNS-Rollback

Manchmal geht es bei der schnellsten Wiederherstellung gar nicht darum, die Infrastruktur wiederherzustellen. Es geht darum, den Datenverkehr von der defekten Version wegzuleiten.

DNS-Rollback arbeitet auf der Ebene des Datenverkehrs-Routings. Anstatt die Infrastrukturänderung rückgängig zu machen, leiten Sie den Datenverkehr zurück zur alten Infrastruktur, die noch läuft.

Stellen Sie sich vor, Sie haben eine neue Version Ihres Anwendungsservers bereitgestellt. Der Server selbst ist in Ordnung, aber die Konfigurationsänderung hat etwas beschädigt. Ihr alter Server läuft noch mit der alten Konfiguration. Sie aktualisieren den DNS-Eintrag oder die Load-Balancer-Konfiguration, um den Datenverkehr zurück zum alten Server zu leiten.

Das ist schnell. Wirklich schnell. DNS-Änderungen verbreiten sich in kontrollierten Umgebungen schnell, und Load-Balancer-Updates sind nahezu sofort. Sie müssen nichts neu aufbauen oder wiederherstellen.

Aber es gibt eine kritische Anforderung: Die alte Infrastruktur muss noch existieren. Wenn Ihr Bereitstellungsprozess die alten Ressourcen zerstört, wenn neue erstellt werden, ist DNS-Rollback keine Option. Diese Strategie funktioniert natürlich mit Blue-Green-Deployments oder Canary-Releases, bei denen alte und neue Versionen parallel laufen.

DNS-Rollback behebt auch nicht das zugrunde liegende Problem. Die defekte Infrastruktur existiert noch. Sie müssen später untersuchen und reparieren. Aber um Benutzer schnell wieder online zu bringen, ist es kaum zu übertreffen.

Failover auf eine Standby-Umgebung

Dies ist die komplexeste Wiederherstellungsoption und auch die zuverlässigste für kritische Systeme.

Sie unterhalten eine zweite Umgebung, die Ihre Produktionsumgebung spiegelt. Dies könnte in einer anderen Availability Zone, einer anderen Region oder sogar bei einem anderen Cloud-Anbieter sein. Die Standby-Umgebung läuft mit der gleichen Infrastruktur, der gleichen Anwendungsversion und hat synchronisierte Daten.

Wenn eine Änderung in der Produktion fehlschlägt und die Auswirkungen weitreichend sind, führen Sie ein Failover durch. Der gesamte Datenverkehr wird auf die Standby-Umgebung umgeleitet. Benutzer arbeiten weiter, und Sie gewinnen Zeit, um die Produktionsumgebung zu reparieren.

Failover beinhaltet DNS-Änderungen, Datenbank-Replikationsmanagement und Datensynchronisation. Das ist nichts, was Sie während eines Incidents herausfinden möchten. Sie müssen den Failover-Prozess regelmäßig testen, idealerweise als Teil Ihres normalen Betriebs.

Die Investition ist erheblich. Die Standby-Umgebung kostet Geld im Betrieb. Datensynchronisation erhöht die Komplexität. Sie benötigen Leute, die den Failover-Prozess verstehen und unter Druck ausführen können.

Aber für Infrastruktur, die verfügbar bleiben muss, ist Failover die zuverlässigste Option. Banken, Gesundheitssysteme und große E-Commerce-Plattformen verwenden diesen Ansatz, weil die Kosten für Ausfallzeiten die Kosten für den Betrieb einer Standby-Umgebung bei weitem übersteigen.

Die richtige Option wählen

Jede Wiederherstellungsoption passt zu verschiedenen Szenarien:

  • Alten Zustand erneut anwenden: Zustandslose Änderungen, schnelle Korrekturen, geringes Datenrisiko
  • Snapshot-Wiederherstellung: Zustandsbehaftete Änderungen, Auswirkungen auf einzelne Ressourcen, Datenintegrität erforderlich
  • DNS-Rollback: Parallele Umgebungen, schnelle Wiederherstellung, alte Infrastruktur existiert noch
  • Failover: Kritische Systeme, großer Schadensbereich, hohe Verfügbarkeitsanforderungen

Ihre Wahl hängt von drei Faktoren ab: der Art der Änderung, die Sie vornehmen, dem potenziellen Schadensbereich und wie schnell Sie wiederherstellen müssen.

Das folgende Flussdiagramm ordnet häufige Fehlerszenarien dem empfohlenen Wiederherstellungspfad zu:

flowchart TD A[Infrastrukturänderung schlägt fehl] --> B{Änderungstyp?} B -->|Zustandslos| C{Alter Zustand verfügbar?} B -->|Zustandsbehaftet| D{Datenverlust akzeptabel?} C -->|Ja| E[Alten Zustand erneut anwenden] C -->|Nein| F{Alte Infrastruktur läuft noch?} D -->|Nein| G[Snapshot-Wiederherstellung] D -->|Ja| H[Alten Zustand erneut anwenden] F -->|Ja| I[DNS-Rollback] F -->|Nein| J{Standby vorhanden?} J -->|Ja| K[Failover auf Standby] J -->|Nein| L[Manueller Wiederaufbau aus Backups] E --> M[Wiederherstellung verifizieren] I --> M G --> M K --> M L --> M

Praktische Checkliste vor Ihrer nächsten Infrastrukturänderung

Bevor Sie das nächste terraform apply ausführen oder eine Konfigurationsänderung pushen, gehen Sie diese Checkliste durch:

  • Weiß ich, welche Wiederherstellungsoption für diese Änderung vorgesehen ist?
  • Ist die alte Zustandsdatei zugänglich und gültig?
  • Habe ich einen Snapshot erstellt, wenn die Änderung zustandsbehaftete Ressourcen betrifft?
  • Läuft die alte Infrastruktur noch, falls ich ein DNS-Rollback benötige?
  • Habe ich den Failover-Prozess im letzten Monat getestet?
  • Weiß das Team, wer die Wiederherstellung durchführt und wie?

Die konkrete Erkenntnis

Die Wiederherstellung nach Infrastrukturausfällen bedeutet nicht, eine perfekte Strategie zu haben. Es geht darum, die Wiederherstellungsoption an die Änderung anzupassen, die Sie vornehmen. Eine Sicherheitsgruppenänderung benötigt kein vollständiges Failover. Eine Datenbankmigration benötigt wahrscheinlich einen Snapshot. Ein Canary-Deployment profitiert von einem DNS-Rollback.

Kennen Sie Ihre Optionen, bevor Sie sie brauchen. Die Zeit, um zu entscheiden, wie Sie wiederherstellen, ist vor der Änderung, nicht nachdem die Alarme losgehen.