Stima dei tempi necessari per la migrazione dei dati

La migrazione in sé è la parte più semplice. È nella fase di riconciliazione, che avete tralasciato, che si nascondono le insidie.

Una migrazione dei dati (il trasferimento dei dati da un sistema all’altro, oppure da una struttura all’altra all’interno dello stesso sistema) si presenta come una trasformazione. Lettura dalla fonte, trasformazione, scrittura nella destinazione, deviazione del traffico. Il team vota in merito alla trasformazione. La trasformazione rappresenta solitamente la parte di lavoro più piccola della storia. Le difficoltà risiedono in ciò che la trasformazione non rileva: record che sembrano corretti ma fanno riferimento a dati che non sono stati trasferiti, record che sembrano errati ma che in realtà sono corretti in un modo non previsto dalle specifiche, casi limite che sono sopravvissuti solo perché il vecchio sistema li tollerava mentre quello nuovo non lo fa.

Si tratta di un problema diverso dalla migrazione di un database. Una migrazione dello schema modifica la struttura di un singolo archivio contenente già i dati. Una migrazione dei dati trasferisce i dati da un sistema all’altro, e la domanda non è «l’ALTER terminerà in tempo?», bensì «come gestiamo le righe che non corrispondono a nessuna delle due parti?». La maggior parte del lavoro consiste nella riconciliazione, nella strategia di transizione e nel rollback. Il codice di trasformazione è la parte che si scrive più rapidamente e che si completa per ultima.

Ciò che viene detto nella sala

Backend: «È uno script. Lettura, mappatura, scrittura. Due giorni al massimo.»

Data eng: “Abbiamo verificato quanto sia sporca la fonte?”

SRE: “Qual è la modalità di transizione: ‘big bang’ o ‘dual-write’?”

Titolo: “Chi risolve i problemi relativi alle righe che non vengono migrate correttamente?”

Primo Ministro: «Quando verrà dismesso il vecchio sistema?»

La domanda del Primo Ministro è quella che dovrebbe guidare la stima. Se il vecchio sistema verrà dismesso tra un mese, è necessaria una strategia che garantisca il 100% di accuratezza; se invece rimarrà in uso parallelamente a quello nuovo per due trimestri, ci si può permettere di rimandare la gestione della coda lunga a un momento successivo. La stima non riguarda la trasformazione, bensì la strategia.

Domande da porsi prima di votare

• Qual è la qualità dei dati di origine: puliti, sporchi o sconosciuta?
• Strategia di migrazione: “big bang”, dual-write, shadow read, graduale?
• Per quanto tempo i due sistemi coesisteranno? È prevista una data di scadenza?
• Chi provvede alla riconciliazione delle righe che non vengono migrate correttamente, e con quale soglia?
• Qual è la procedura di ripristino nel caso in cui il nuovo sistema riceva dati errati dopo il passaggio?
• Esistono consumatori a valle (report, integrazioni) che devono essere migrati in modo sincronizzato?

Se il team assegna un voto di 5 e qualcuno obietta: «Un momento, e i registri di audit?», non si è trattato di un problema di stima, bensì di due storie che fingevano di essere una sola. Suddividetela: la trasformazione costituisce un ticket, mentre la riconciliazione e il piano di transizione ne costituiscono un altro.

Votate sulla strategia, non sulla trasformazione. La trasformazione dura due giorni. La strategia riguarda l’intero trimestre.

Si veda la stima di una migrazione di database per la variante relativa alla modifica dello schema su un singolo sistema, nonché gli altri esempi pratici di stima. Avviare una sessione gratuita di Planning Poker una volta delineata la strategia di transizione.