Der falsche Gleichklang
„Wir können jederzeit zurück“ kann zwei sehr unterschiedliche Dinge meinen: Der alte Traffic-Pfad existiert noch. Oder das alte System kann mit dem inzwischen entstandenen Zustand korrekt weiterarbeiten. Die erste Aussage beweist die zweite nicht.
Wenn eine neue Anwendung Daten in einem inkompatiblen Schema schreibt, ist ein Routing-Wechsel noch keine Wiederherstellung. Ebenso wenig reicht eine alte Deployment-Datei, wenn ihre Secrets, Abhängigkeiten oder Berechtigungen inzwischen verändert wurden.
Drei Grenzen, die ich getrennt betrachten würde
Traffic: Welche Clients erreichen bereits das neue Ziel? DNS-TTLs, bestehende Verbindungen und Load-Balancer-Draining können den Übergang verzögern. Der erfolgreiche Konfigurationswechsel ist nicht identisch mit dem Ende aller Requests auf dem alten Pfad.
Daten: Wer darf in welcher Phase schreiben? Ein parallel erreichbares System sollte nicht versehentlich ein zweiter unabhängiger Writer werden. Datenreplikation, Schreibzuständigkeit und Konsistenz müssen zum konkreten Dienst passen.
Kompatibilität: Welche Kombinationen aus alter und neuer Anwendung, Schema und Konfiguration sind zulässig? Eine vorwärts- und rückwärtskompatible Übergangsphase kann Optionen offenhalten. Ob sie möglich ist, muss konkret geprüft werden.
Gedankenmodell · keine Live-Infrastruktur
Den Übergang mitlesen.
Bestehender Betrieb
Produktiver Traffic bleibt auf dem bisherigen Pfad. Abhängigkeiten, Schreibzuständigkeit und Kriterien für den Wechsel werden erfasst.
Rückweg: Ausgangszustand bleibt maßgeblich.
Parallel prüfen
Das neue Ziel wird mit repräsentativen Requests und vorgesehener Identität geprüft. Parallele Erreichbarkeit bedeutet nicht automatisch parallele Schreibberechtigung.
Rückweg: Tests beenden; produktiven Pfad beibehalten.
Traffic wechseln
Traffic wird nach dem geplanten Verfahren umgestellt. Verbindungen und Datenzustand separat beobachten. Ob eine Rückkehr noch zulässig ist, hängt von den tatsächlich erfolgten Änderungen ab.
Rückweg: nur bei erfüllten Daten- und Kompatibilitätsbedingungen.
Eine Rückkehrbedingung braucht einen Befund
Vor dem Wechsel würde ich wenige entscheidende Signale benennen: einen repräsentativen Geschäftsrequest, Fehlerquote und Latenz für diesen Pfad sowie einen Nachweis für Datenintegrität. Dazu gehören Beobachtungsfenster, Verantwortliche und die Grenze, ab der ein einfacher Rückweg nicht mehr zulässig ist.
Die Prüfungen sollten dieselben Identitäten und Netzpfade nutzen wie der spätere Betrieb. Ein erfolgreicher Test mit Admin-Rechten oder von einem anderen Subnetz kann genau die Einschränkung auslassen, die nach dem Cutover relevant wird.
Was ich vor einer Freigabe sehen möchte
Ein aktueller Pfad, ein neuer Pfad und ein beschriebener Übergang. Ein Rückweg, dessen Voraussetzungen noch erfüllt sind. Und eine Person, die anhand vereinbarter Befunde entscheiden kann. Der Plan muss nicht kompliziert sein. Er muss die riskanten Annahmen sichtbar machen.
Nachstellen: Traffic zurück, Daten unverändert
Reproduzierbares Lernbeispiel mit synthetischen Daten. Kein Bericht über ein Arbeitgeber- oder Kundenprojekt.
Das Symptom: Nach dem Zurückschalten läuft wieder die alte Anwendung, aber sie scheitert an Datensätzen, die vor dem Cutover noch gültig waren. Dieses lokale Beispiel isoliert genau diese Grenze.
Lokal ausführen
Python 3 genügt. Das Skript nutzt eine SQLite-Datenbank im Arbeitsspeicher, schreibt keine Dateien und benötigt weder Netzwerk noch Cloud-Zugang. Nach dem Download im Terminal ausführen:
Python-Beispiel herunterladen · rollback-compatibility.py
python rollback-compatibility.pyAusgabe des Beispiels
Before cutover: old reader accepts 'paid'
New writer: status changed to 'refunded'
After traffic reversal: unsupported status: refunded
Simple rollback gate: BLOCKED (data contract is incompatible)Die alte Anwendung akzeptiert nur „new“ und „paid“. Die neue schreibt „refunded“. Selbst ohne Änderung an der SQL-Spalte ist der Datenvertrag damit inkompatibel. Der Rückwechsel auf alten Code macht diese neue Bedeutung nicht rückgängig. Das Skript prüft beide Zustände mit Assertions.
Welche Entscheidung folgt daraus?
Vor einer Freigabe braucht es einen Kompatibilitätstest mit Daten, die der neue Writer tatsächlich erzeugen kann. Eine mögliche Übergangsstrategie: Zuerst alle Leser auf den neuen Wert vorbereiten, erst danach den Writer aktivieren. Ob alte Werte verlustfrei wiederhergestellt werden können, ist eine eigene fachliche Entscheidung. Ein erzwungenes Umschreiben von „refunded“ zu „paid“ wäre hier keine korrekte Reparatur.
Das Modell prüft einen Datenvertrag. Es testet keine AWS-Umschaltung, Replikationsverzögerung, gleichzeitigen Schreibzugriffe oder vollständige Wiederherstellung. Diese Grenzen gehören in einen dienstspezifischen Cutover-Test.