Was passiert nach dem Rollback: Überprüfung der tatsächlichen Wiederherstellung

Sie haben gerade den Rollback-Button gedrückt. Das Deployment, das Fehler, langsame Antworten oder Datenbankkorruption verursacht hat, ist weg. Ihre Anwendung läuft wieder auf der vorherigen Version. Ihr Team atmet erleichtert auf.

Aber funktioniert das System tatsächlich?

Ein Rollback oder Roll-forward ist nicht das Ende eines Incidents. Es ist die Mitte. Die eigentliche Frage ist, ob die Wiederherstellung selbst neue Probleme eingeführt, Restdaten hinterlassen oder Integrationen mit anderen Diensten unterbrochen hat. Ohne ordnungsgemäße Verifizierung nach der Wiederherstellung erklären Sie den Incident möglicherweise für gelöst, während das System immer noch auf eine Weise defekt ist, die erst Stunden später sichtbar wird.

Die versteckten Risiken der Wiederherstellung

Wenn Sie eine Anwendung zurücksetzen, machen Sie die Zeit nicht einfach rückgängig. Die alte Version kehrt zurück, aber die Umgebung hat sich möglicherweise verändert. Datenbankschemata könnten nicht mehr passen. Konfigurationsdateien könnten von der neueren Version stammen. Daten, die von der problematischen Version geschrieben wurden, bleiben in der Datenbank. Dienste, die von dem neuen API-Format abhingen, erhalten jetzt alte Antworten und brechen.

Ein Roll-forward mit einem Hotfix hat seine eigenen Risiken. Sie haben einen Fehler behoben, aber der Hotfix könnte etwas anderes verändert haben. Ein Konfigurationswert, der im Notfall funktioniert hat, könnte für den Normalbetrieb nicht korrekt sein. Der Hotfix wurde möglicherweise schnell ohne die üblichen Tests geschrieben und könnte eigene Fehler enthalten.

Deshalb ist die Verifizierung nach der Wiederherstellung nicht optional. Sie ist das Sicherheitsnetz, das die Probleme auffängt, die die Wiederherstellung selbst verursacht.

Beginnen Sie mit Smoke-Tests

Der schnellste Weg, um zu prüfen, ob das System lebt, ist ein Smoke-Test. Dies ist eine kurze Reihe von Prüfungen, die die Kernfunktionen Ihrer Anwendung bestätigen. Nicht jede Funktion, nicht jeder Randfall, nur die kritischen Pfade, auf die Benutzer angewiesen sind.

Ein guter Smoke-Test für eine Webanwendung könnte Folgendes umfassen:

• Können sich Benutzer anmelden?
• Können sie ihr Haupt-Dashboard sehen?
• Können sie ein Formular absenden oder eine Transaktion abschließen?
• Gibt es Fehler in den Anwendungslogs?

Diese Prüfungen sollten automatisiert sein. Wenn Ihr Smoke-Test erfordert, dass jemand manuell durch Bildschirme klickt, wird er übersprungen, wenn das Team nach einem Incident müde und unter Druck ist. Automatisieren Sie ihn, sodass der Smoke-Test innerhalb von Minuten nach Abschluss der Wiederherstellung läuft und ein klares Bestehen oder Nichtbestehen anzeigt.

Ein einfacher automatisierter Smoke-Test mit curl könnte zum Beispiel so aussehen:

#!/bin/bash
# Einfacher Smoke-Test nach dem Rollback

BASE_URL="https://my-app.example.com"

# Health-Endpunkt prüfen
if ! curl -f -s -o /dev/null "$BASE_URL/health"; then
  echo "FAIL: Health-Endpunkt nicht erreichbar"
  exit 1
fi

# Prüfen, ob die Login-Seite lädt
if ! curl -f -s -o /dev/null "$BASE_URL/login"; then
  echo "FAIL: Login-Seite lädt nicht"
  exit 1
fi

# Prüfen, ob die API für einen kritischen Endpunkt 200 zurückgibt
if ! curl -f -s -o /dev/null "$BASE_URL/api/v1/status"; then
  echo "FAIL: API-Status-Endpunkt fehlgeschlagen"
  exit 1
fi

echo "PASS: Alle Smoke-Tests bestanden"

Metriken vorher und nachher vergleichen

Smoke-Tests sagen Ihnen, dass die Anwendung läuft. Metriken sagen Ihnen, ob sie gut läuft.

Vergleichen Sie wichtige Metriken von vor dem Incident, während des Incidents und nach der Wiederherstellung. Die relevanten Metriken hängen von Ihrer Anwendung ab, aber übliche sind:

• Anfragen pro Sekunde
• Fehlerrate (Prozentsatz der fehlgeschlagenen Anfragen)
• Durchschnittliche Antwortzeit
• Speicher- und CPU-Auslastung
• Datenbank-Abfragelatenz

Wenn die Fehlerrate nach der Wiederherstellung immer noch höher ist als vor dem Incident, stimmt etwas nicht. Vielleicht wurde ein Dienst nicht richtig neu gestartet. Vielleicht wurde eine Konfiguration nicht zurückgesetzt. Vielleicht hat der Wiederherstellungsprozess selbst einen neuen Engpass eingeführt.

Verlassen Sie sich nicht auf eine einzelne Metrik. Eine niedrige Fehlerrate in Kombination mit hoher Latenz kann immer noch bedeuten, dass das System nicht gesund ist. Betrachten Sie das Gesamtbild.

Datenbankverifizierung erfordert besondere Sorgfalt

Die Datenbankwiederherstellung ist der kniffligste Teil. Wenn Sie die Datenbank auf ein Backup zurückgesetzt haben, das vor dem Deployment erstellt wurde, sind alle Daten, die zwischen diesem Backup und dem Rollback geschrieben wurden, verloren. Diese Daten können Benutzertransaktionen, Bestellungen oder Konfigurationsänderungen umfassen.

Sie müssen prüfen:

• Ist der Datenverlust aus geschäftlicher Sicht akzeptabel?
• Können Sie kritische Daten aus Logs oder anderen Systemen wiederherstellen?
• Gibt es verwaiste Datensätze, die von der neueren Version hinterlassen wurden und mit denen die alte Version nicht umgehen kann?

Manchmal ist die Antwort, dass ein gewisser Datenverlust akzeptabel ist. In anderen Fällen müssen Sie bestimmte Datensätze manuell wiederherstellen. In beiden Fällen müssen Sie wissen, was verloren gegangen ist, und entscheiden, ob Maßnahmen erforderlich sind.

Integrationen mit anderen Systemen prüfen

Ihre Anwendung lebt nicht in Isolation. Nach der Wiederherstellung ist die alte Version möglicherweise nicht mit APIs kompatibel, die andere Teams geändert haben, während Ihr Deployment lief. Oder der Hotfix hat möglicherweise das Format der Daten geändert, die an Monitoring-, Logging- oder Analysesysteme gesendet werden.

Testen Sie die Verbindungen:

• Kann Ihre Anwendung weiterhin externe APIs aufrufen?
• Geben diese APIs Antworten zurück, die Ihre Version parsen kann?
• Empfangen nachgelagerte Dienste die Daten, die sie erwarten?

Integrationsprobleme nach der Wiederherstellung sind häufig, weil Teams sich oft auf ihre eigene Anwendung konzentrieren und die Dienste vergessen, die von ihr abhängen oder von denen sie abhängt.

Aus Benutzersicht verifizieren

Dashboards und Logs zeigen, was das System tut. Sie zeigen nicht immer, was der Benutzer erlebt. Ein Benutzer sieht möglicherweise eine leere Seite, die kein Fehlerlog erzeugt. Eine Transaktion könnte stillschweigend fehlschlagen, weil das Frontend die Fehlermeldung nicht anzeigt.

Lassen Sie nach Möglichkeit interne Benutzer die Hauptfunktionen nach der Wiederherstellung testen. Oder verwenden Sie Tools für echtes Benutzermonitoring, um Metriken wie Transaktionserfolgsrate und Sitzungsdauer zu prüfen. Diese Metriken zeigen oft Probleme, die das Infrastruktur-Monitoring übersieht.

Dokumentieren Sie, was Sie gefunden haben

Nach Abschluss der Verifizierung schreiben Sie auf, was passiert ist. Diese Dokumentation dient zwei Zwecken:

1. Sie liefert den Nachweis, dass die Wiederherstellung erfolgreich war und das System wieder normal läuft.
2. Sie hilft Ihrem Team, den Deployment- und Wiederherstellungsprozess für das nächste Mal zu verbessern.

Halten Sie fest, was schiefgelaufen ist, was die Wiederherstellung umfasste, was Sie während der Verifizierung geprüft haben und welche Probleme Sie entdeckt haben. Diese Aufzeichnung wird anderen Teammitgliedern helfen, die in Zukunft mit ähnlichen Problemen konfrontiert sind.

Eine praktische Verifizierungs-Checkliste

Hier ist eine kurze Checkliste, die Sie nach jeder Wiederherstellung verwenden können:

Das folgende Flussdiagramm zeigt die Verifizierungssequenz mit Entscheidungspunkten bei jedem Schritt:

• Smoke-Test für alle kritischen Funktionen bestanden
• Fehlerrate auf das Niveau vor dem Incident zurückgekehrt
• Antwortzeit normal
• Ressourcennutzung (CPU, Speicher, Festplatte) stabil
• Datenbankintegrität geprüft, Datenverlust dokumentiert
• Alle externen Integrationen funktionieren
• Benutzerseitige Metriken zeigen normales Verhalten
• Ergebnisse für zukünftige Referenz dokumentiert

Das wahre Ende eines Incidents

Die Verifizierung nach der Wiederherstellung ist keine Formalität. Sie ist die letzte Verteidigungslinie, bevor Sie den Incident für gelöst erklären. Ohne sie riskieren Sie, das System als gesund zu bezeichnen, obwohl es immer noch auf eine Weise defekt ist, die später einen größeren Incident verursachen wird.

In dem Moment, in dem Sie bestätigen, dass das System tatsächlich funktioniert, endet der Incident wirklich. Alles davor ist nur Wiederherstellung.