Stima dei tempi necessari per la migrazione dei dati

La migrazione in sé è la parte più semplice. È nella fase di riconciliazione, che Lei ha tralasciato, che si nascondono le difficoltà.

Una migrazione dei dati (il trasferimento dei dati da un sistema a un altro, oppure da una struttura a un’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 è 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 database contenente già i dati. Una migrazione dei dati trasferisce i dati da un sistema all’altro, e la domanda non è «l’istruzione ALTER verrà completata 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 stanza

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

Data eng: “Abbiamo verificato quanto siano sporchi i dati di origine?”

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

Titolo: “Chi risolve i conflitti tra le 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 si occupa di risolvere le discrepanze nelle righe che non vengono migrate correttamente, e con quale tolleranza?
• 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 5 e qualcuno dice: «Un momento, e i registri di audit?», non si trattava di un problema di stima; si trattava piuttosto di due storie che fingevano di essere una sola. Dividetele: la trasformazione è un ticket, 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 sezione dedicata alla stima della migrazione di un database per la variante con modifica dello schema su un unico sistema, nonché gli altri esempi pratici di stima. Una volta delineata la strategia di transizione, si avvii una sessione gratuita di “planning poker”.