Einschätzung des Aufwands für eine Datenbankmigration

„Spalte hinzufügen“ ist eine einzeilige Migration. Bei der Schätzung geht es nicht um die Spalte.

Bei Schemamigrationen gibt es zwei Zeitfaktoren. Der eine ist der SQL-Vorgang: meist schnell, meist routinemäßig. Die andere ist die operative Zeitskala: Wie lange wird die Tabelle gesperrt, wie verhält sich der Vorgang bei gleichzeitigen Schreibvorgängen, wie lässt sich der Vorgang rückgängig machen, falls etwas schiefgeht, und wie sieht der Notfallplan aus, falls die Ausführung länger dauert als das Bereitstellungsfenster? Das Team entscheidet über die SQL-Anweisung, da diese im Ticket aufgeführt ist. Die eigentliche Arbeit findet auf der zweiten Zeitskala statt.

Auf einem kleinen Tisch sind die beiden Uhren identisch, und die Geschichte ist wirklich unbedeutend. Auf jedem Tisch, der von Bedeutung ist, ist dies jedoch nicht der Fall. Die Schätzung muss die Nachfüllung, die Einführungsstrategie und den Rollback berücksichtigen, die jemand einstudiert haben muss, bevor die Bereitstellung auch nur in die Nähe der Produktion gelangt.

Was in dem Raum gesagt wird

Backend: „Es handelt sich lediglich um einen ALTER-Befehl, die Migration ist in einer Sekunde abgeschlossen.“

SRE: „In der Auftragstabelle? Mit gesperrten Aufträgen? Um 15 Uhr?“

DBA: „Wie füllen wir bestehende Zeilen nach?“

SRE: „Wie sieht der Rollback aus, wenn die Bereitstellung auf halbem Weg fehlschlägt?“

Leitfrage: „Kann der Lesepfad es verkraften, wenn die Spalte eine Stunde lang den Wert „Null“ aufweist?“

Fragen, die man sich vor der Stimmabgabe stellen sollte

• Wie groß ist die Tabelle: Tausende, Millionen oder Hunderte von Millionen Zeilen?
• Online-Migrationswerkzeug oder ALTER vor Ort?
• Strategie zur Datenwiederherstellung: synchron, im Stapelverfahren, Dual-Write?
• Welche Funktion hat der Lesepfad während des Rollout-Fensters?
• Rollback: Nur vorwärtsgerichtet – oder können wir das Schema rückgängig machen?
• Hat jemand das Bereitschafts-Handbuch für diese Migration durchgespielt?

Wenn die eine Hälfte der Anwesenden für „das SQL“ stimmt und die andere Hälfte für „die Einführung“, haben Sie kein Problem mit der Anzahl; Sie haben zwei Stories, die so tun, als wären sie eine. Teilen Sie es auf: Die Schemaänderung ist ein Ticket, der Plan für die Nachvervollständigung und die Einführung ist ein anderes.

Schätzen Sie die Dauer der Einführung und der Rücknahme, nicht die des ALTER-Befehls. Das Risiko liegt bei der zweiten Zeitangabe.

Informationen zur systemübergreifenden Variante finden Sie unter Schätzung einer Datenmigration sowie unter den weiteren Beispielen für Schätzungen. Starten Sie eine kostenlose Planning-Poker-Sitzung, sobald der Rollout skizziert ist.