Warum sich Datenmigration von Anwendungsbereitstellung unterscheidet

Ihre CI/CD-Pipeline läuft rund. Anwendungsbereitstellungen sind Routine. Rolling Updates, Blue-Green-Deployments, sogar Canary-Releases – Ihr Team meistert sie ohne Probleme. Dann sagt jemand: „Wir müssen das Datenbankschema ändern und Daten von der alten in die neue Tabelle verschieben.“ Plötzlich wird es still im Raum. Fragen kommen auf. Jemand prüft, ob die Backups aktuell sind. Ein anderer fragt, ob wir das während der Wartungsfenster machen können. Die eben noch spürbare Zuversicht ist verflogen.

Das liegt nicht daran, dass Ihrem Team die Fähigkeiten fehlen. Sondern daran, dass Datenmigration grundlegend anders ist als Anwendungsbereitstellung. Beides gleich zu behandeln, ist ein Rezept für Produktionsvorfälle, die keine noch so grüne Pipeline verhindern kann.

Das Problem des Zustands

Anwendungen sind von Natur aus zustandslos. Wenn Sie eine neue Version bereitstellen, ersetzen Sie Code, der im Arbeitsspeicher oder auf der Festplatte läuft. Wenn die neue Version kaputt ist, rollen Sie auf die vorherige zurück. Der alte Code existiert noch in Ihrem Repository. Sie führen ihn einfach erneut aus. Benutzer erleben vielleicht ein paar Minuten Ausfallzeit, aber ihre Daten bleiben unberührt.

Datenbanken sind das Gegenteil. Sie halten Zustände – Benutzerkonten, Transaktionshistorien, Konfigurationseinstellungen, Bestellaufzeichnungen. Sobald Sie eine Migration ausführen, die eine Spalte löscht, sind die Daten dieser Spalte weg. Sobald Sie ein Datumsformat über Millionen von Zeilen ändern, kehren diese Daten nicht von selbst zurück. Es gibt keinen „Rückgängig“-Button für Datenänderungen. Sie können aus einem Backup wiederherstellen, aber das bedeutet, alle Daten zu verlieren, die seit dem letzten Backup erstellt oder geändert wurden.

Diese Irreversibilität macht Datenmigration so angespannt. Ein Fehler bei der Anwendungsbereitstellung ist behebbar. Ein Fehler bei der Datenmigration ist dauerhaft – es sei denn, Sie haben vorher einen genauen Wiederherstellungsplan.

Das folgende Diagramm stellt die beiden Abläufe gegenüber:

flowchart TD subgraph AppDeploy["Anwendungsbereitstellung"] A1[Code] --> A2[Build] A2 --> A3[Test] A3 --> A4[Deploy] A4 --> A5{Erfolg?} A5 -- Ja --> A6[Fertig] A5 -- Nein --> A7[Rollback auf alte Version] A7 --> A6 end subgraph DataMigrate["Datenmigration"] B1[Schemaänderung] --> B2[Datenverschiebung] B2 --> B3{Erfolg?} B3 -- Ja --> B4[Verifizieren & Abgleichen] B3 -- Nein --> B5[Wiederherstellung aus Backup] B5 --> B6[Datenverlust möglich] end AppDeploy -.->|Umkehrbar| DataMigrate

Direkte Auswirkungen auf Benutzer

Wenn eine Anwendung abstürzt, sehen Benutzer eine Fehlerseite. Sie aktualisieren die Seite, versuchen es später erneut oder kontaktieren den Support. Das ist ärgerlich, aber ihre Daten sind sicher.

Wenn eine Datenmigration schiefgeht, ist der Schaden unsichtbar, bis ihn jemand bemerkt. Eine Migration, die Kontostände falsch berechnet, Lieferadressen überschreibt oder die Bestellhistorie löscht, zeigt sich nicht als 500-Fehler. Sie zeigt sich, wenn ein Benutzer sein Konto prüft und falsche Informationen findet. Zu diesem Zeitpunkt ist die Migration bereits gelaufen und die Daten haben sich bereits geändert. Der Benutzer hat echten Schaden erlitten, nicht nur Unannehmlichkeiten.

Diese direkte Auswirkung auf Benutzerdaten erfordert ein anderes Maß an Vorsicht. Sie können eine Datenmigration nicht wie eine Code-Bereitstellung behandeln, die Sie in der Staging-Umgebung testen und dann in die Produktion überführen. Die Risiken sind höher, und die Fehlermodi sind schwerer zu erkennen.

Dauer und Einschränkungen

Anwendungsbereitstellungen dauern in der Regel Sekunden oder Minuten. Rolling Updates können Instanzen nacheinander ersetzen, ohne spürbare Ausfallzeiten. Benutzer merken vielleicht nicht einmal, dass eine Bereitstellung stattgefunden hat.

Datenmigrationen können Stunden dauern. Eine Migration, die jede Zeile in einer Tabelle mit Millionen von Datensätzen aktualisiert, sperrt Tabellen, verbraucht Datenbankressourcen und verlangsamt Abfragen. Während dieser Zeit muss Ihre Anwendung möglicherweise in einem abgespeckten Modus laufen. Einige Funktionen sind deaktiviert. Einige Endpunkte geben Fehler zurück. Möglicherweise müssen Sie die Anwendung sogar vollständig offline nehmen.

Diese langlaufende Natur führt zu Koordinationsproblemen. Wer überwacht die Migration? Was passiert, wenn sie auf halbem Weg fehlschlägt? Wie kommunizieren Sie den Status an den Rest des Teams? Das sind Fragen, die Sie bei einer Code-Bereitstellung normalerweise nicht stellen.

Was eine Datenmigration sicher macht

Da Datenmigrationen ein höheres Risiko tragen, benötigen sie eine andere Reihe von Sicherheitsvorkehrungen. Dies sind keine optionalen Extras. Sie sind die Mindestanforderungen, um Datenänderungen mit der Ernsthaftigkeit zu behandeln, die sie verdienen.

Idempotenz. Ihr Migrationsskript sollte sicher mehrmals ausgeführt werden können. Wenn es auf halbem Weg fehlschlägt, sollten Sie das Problem beheben und es erneut ausführen können, ohne doppelte Daten oder inkonsistente Zustände zu verursachen. Das bedeutet, IF NOT EXISTS-Prüfungen, UPSERT-Operationen oder bedingte Logik zu verwenden, die erkennt, ob eine Änderung bereits angewendet wurde.

Trockenlauf-Fähigkeit. Bevor Sie Produktionsdaten berühren, müssen Sie die Migration in einer sicheren Umgebung ausführen, die die Produktion so genau wie möglich abbildet. Das ist nicht dasselbe wie Testen in der Staging-Umgebung. Ein Trockenlauf sollte Ihnen genau zeigen, was sich ändern wird, wie lange es dauern wird und ob irgendwelche Constraints verletzt werden.

Backfill-Strategie. Einige Datenmigrationen beinhalten das Auffüllen fehlender Daten aus historischen Aufzeichnungen. Dies ist kein einmaliger Vorgang. Backfill sollte inkrementell, überwacht und umkehrbar sein. Sie sollten in der Lage sein, ihn zu pausieren, die Ergebnisse zu überprüfen und fortzufahren, wenn alles korrekt aussieht.

Abgleich. Nach Abschluss der Migration müssen Sie nachweisen, dass die Daten korrekt sind. Das bedeutet, Abfragen auszuführen, die den alten mit dem neuen Zustand vergleichen, Zeilenanzahlen zu prüfen, Summen zu verifizieren und nach Anomalien zu suchen. Abgleich ist kein „nice-to-have“. Es ist der einzige Weg, um zu bestätigen, dass die Migration das getan hat, was sie tun sollte.

Eine praktische Checkliste vor jeder Datenmigration

Bevor Sie eine Datenmigration in der Produktion ausführen, gehen Sie diese Liste durch:

  • Ist das Migrationsskript idempotent? Kann es zweimal ausgeführt werden, ohne Probleme zu verursachen?
  • Haben Sie einen Trockenlauf gegen eine Kopie der Produktionsdaten durchgeführt?
  • Wissen Sie, wie lange die Migration dauern wird? Haben Sie für dieses Zeitfenster geplant?
  • Gibt es einen Rollback-Plan, der nicht auf „einfach aus Backup wiederherstellen“ basiert?
  • Haben Sie Abgleich-Abfragen geschrieben, um das Ergebnis zu verifizieren?
  • Weiß das Team, wer die Migration überwacht und wen man anruft, wenn etwas schiefgeht?

Das Fazit

Datenmigration ist keine Anwendungsbereitstellung mit einem anderen Skript. Es ist eine andere Kategorie von Arbeit, die ihren eigenen Prozess, ihre eigenen Sicherheitsvorkehrungen und ihre eigene Definition von „erledigt“ erfordert. Wenn Ihr Team das nächste Mal eine Schemaänderung oder eine Datenverschiebung plant, halten Sie inne und fragen Sie: Haben wir Idempotenz, Trockenlauf, Backfill und Abgleich abgedeckt? Wenn die Antwort Nein lautet, sind Sie nicht bereit, diese Migration durchzuführen.