Einschätzung des Aufwands für eine Datenbankmigration

„Spalte hinzufügen“ ist eine einzeilige Migration. Die Schätzung bezieht sich nicht auf die Spalte.

Bei Schemamigrationen gibt es zwei Zeitfaktoren. Der eine ist die SQL: 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 welche Notfallmaßnahmen gibt es, falls die Ausführung länger dauert als das Bereitstellungsfenster? Das Team stimmt über die SQL-Anweisung ab, 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 – allesamt Schritte, die jemand einstudiert haben muss, bevor die Bereitstellung auch nur annähernd in die Produktion übergeht.

Was in dem Raum gesagt wird

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

SRE: „Auf der Auftragstabelle? Mit gesperrten Positionen? 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 Batch-Verfahren, 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 Notfallhandbuch für diese Migration durchgespielt?

Wenn die eine Hälfte des Raums für „die 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 weiteres.

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

Lesen Sie den Abschnitt zur Abschätzung einer Datenmigration für die systemübergreifende Variante sowie die weiteren Beispiele für durchgespielte Abschätzungen. Starten Sie eine kostenlose Planning-Poker-Sitzung, sobald der Rollout grob skizziert ist.