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 was vastgelegd; en randgevallen die alleen standhielden 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, een omschakelingsstrategie en het terugdraaien van wijzigingen. De transformatiecode is het onderdeel dat u het snelst schrijft en als laatste afrondt.

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’?”

Leidende vraag: “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 bewaren. 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: zuiver, onzuiver of onbekend?
• Overstapstrategie: big bang, dual-write, shadow read, geleidelijk?
• Hoe lang zullen beide systemen naast elkaar bestaan? Is er een einddatum?
• Wie zorgt ervoor dat de rijen die niet correct worden gemigreerd, in overeenstemming worden gebracht, 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 eens even, hoe zit het dan met de auditlog-gegevens?”, dan had u geen probleem met de schatting; u had twee stories die deden alsof ze er één waren. Splits het op: de transformatie is één ticket, het afstemmings- en overgangsprogramma is een ander ticket.

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

Zie het inschatten van een databasemigratie voor de variant waarbij het schema binnen één systeem wordt gewijzigd, en de andere praktijkvoorbeelden van schattingen. Start een gratis planning poker-sessie zodra de overgangsstrategie in grote lijnen is uitgewerkt.