Stima dei tempi necessari per la migrazione di un database

“Aggiungi una colonna” è una migrazione di una sola riga. La stima non riguarda la colonna.

Le migrazioni degli schemi seguono due tempistiche. Una è quella relativa alle operazioni SQL: solitamente veloce, solitamente meccanica. L’altro è il ciclo operativo: per quanto tempo blocca la tabella, come si comporta in caso di scritture simultanee, come si annulla l’operazione se qualcosa va storto e quale è il piano di emergenza qualora il processo duri più a lungo della finestra di distribuzione. Il team si concentra sul codice SQL perché è ciò che è indicato nel ticket. Il lavoro vero e proprio si svolge secondo il secondo ciclo.

Su un tavolino, i due orologi sono identici e la questione è davvero di poco conto. Su qualsiasi tavolo che conti davvero, invece, non lo sono. La stima deve tenere conto del backfill, della strategia di implementazione e del rollback che qualcuno dovrà aver provato prima che la distribuzione si avvicini minimamente all’ambiente di produzione.

Ciò che viene detto nella sala

Backend: «È solo un ALTER, la migrazione richiede un secondo.»

SRE: «Nella tabella degli ordini? Con i blocchi attivi? Alle 15:00?»

DBA: “Come si procede al riempimento delle righe esistenti?”

SRE: «Qual è la procedura di rollback qualora l’implementazione fallisca a metà?»

Domanda principale: “Il percorso di lettura tollera che la colonna rimanga nulla per un’ora?”

Domande da porsi prima di votare

• Quanto è grande la tabella: migliaia, milioni, centinaia di milioni di righe?
• Strumento di migrazione online o comando ALTER in loco?
• Strategia di recupero dei dati: sincrona, elaborazione in batch, doppia scrittura?
• Qual è la funzione del percorso di lettura durante la finestra di implementazione?
• Rollback: solo in avanti, oppure è possibile ripristinare lo schema?
• Qualcuno ha seguito il protocollo di pronto intervento previsto per questa migrazione?

Se metà dei presenti vota per “l’SQL” e l’altra metà per “il rollout”, il problema non è di natura numerica; si tratta piuttosto di due storie che fingono di essere una sola. Separatele: la modifica dello schema costituisce un ticket, mentre il piano di backfill e rollout ne costituisce un altro.

Si valuti l’implementazione e il rollback, non l’ALTER. È nella seconda fase che risiede il rischio.

Si veda Come stimare una migrazione dei dati per la variante intersistemica e gli altri esempi pratici di stima. Avviare una sessione gratuita di planning poker una volta delineato il piano di implementazione.