Een schatting maken van een gegevensmigratie

De migratie zelf is het makkelijke deel. De afstemmingsstap die u over het hoofd hebt gezien, is waar de valkuilen schuilgaan.

Een gegevensmigratie (het verplaatsen van gegevens van het ene systeem naar het andere, of van de ene structuur naar de andere binnen hetzelfde systeem) lijkt op een transformatie. Uit de bron lezen, transformeren, naar de bestemming schrijven, het verkeer omleiden. Het team stemt over de transformatie. De transformatie is doorgaans het kleinste onderdeel van het verhaal. De valkuilen zitten in de zaken die de transformatie over het hoofd ziet: records die er op het eerste gezicht goed uitzien, maar verwijzen naar gegevens die niet zijn overgezet; records die er kapot uitzien, maar in feite correct zijn op een manier die niet in de specificatie is vastgelegd; en randgevallen die alleen overeind zijn gebleven omdat het oude systeem ze tolereerde, terwijl het nieuwe systeem dat niet doet.

Dit is een ander probleem dan een databasemigratie. Bij een schemamigratie wordt de structuur van één database gewijzigd, terwijl de gegevens daarin al aanwezig zijn. Bij een gegevensmigratie worden gegevens tussen systemen verplaatst, en de vraag is niet „is de ALTER-opdracht op tijd voltooid?“, maar „wat doen we met de rijen die aan geen van beide kanten overeenkomen?“ Het grootste deel van het werk bestaat uit afstemming, de omschakelingsstrategie en het terugdraaien van wijzigingen. De transformatiecode is het onderdeel dat u het snelst schrijft en als laatste voltooit.

Wat er in de kamer wordt gezegd

Backend: “Het is een script. Lezen, toewijzen, schrijven. Maximaal twee dagen.”

Data eng: “Hebben wij al gekeken hoe vervuild de bron is?”

SRE: “Wat is de overgang: een ‘big bang’ of ‘dual-write’?”

Kop: “Wie lost de problemen op bij rijen die niet correct worden gemigreerd?”

Premier: “Wanneer wordt het oude systeem afgeschaft?”

De vraag van de premier is bepalend voor de schatting. Als het oude systeem over een maand verdwijnt, heeft u een strategie nodig die 100% nauwkeurig is; als het nog twee kwartalen naast het nieuwe systeem blijft bestaan, kunt u het zich veroorloven om de ‘long tail’ voor later te laten. De schatting heeft geen betrekking op de transformatie, maar op de strategie.

Vragen die het waard zijn om te stellen voordat u gaat stemmen

• Wat is de kwaliteit van de brongegevens: schoon, vervuild of onbekend?
• Overstapstrategie: big bang, dual-write, shadow read, geleidelijk?
• Hoe lang zullen beide systemen naast elkaar blijven bestaan? Is er een einddatum?
• Wie zorgt ervoor dat de rijen die niet correct worden gemigreerd, worden afgestemd, en op welk niveau?
• Wat is de terugdraaiingsprocedure indien het nieuwe systeem na de overgang onjuiste gegevens ontvangt?
• Zijn er downstream-gebruikers (rapporten, integraties) die gelijktijdig moeten worden gemigreerd?

Als het team een 5 stemt en iemand zegt: „Wacht even, hoe zit het dan met de auditlogboekgegevens?“, dan had u geen probleem met de schatting; u had twee stories die deden alsof ze één waren. Splits het op: de transformatie is één ticket, het afstemmings- en overgangsplan is een ander ticket.

Stem over de strategie, niet over de transformatie. De transformatie duurt twee dagen. De strategie geldt voor het kwartaal.

Zie „Een databasemigratie inschatten” voor de variant met een schemawijziging binnen één systeem, en de andere uitgewerkte schattingsvoorbeelden. Start een gratis planning poker-sessie zodra de overgangsstrategie in grote lijnen is uitgewerkt.