Stima dei tempi necessari per la migrazione di un database
Come stimare la durata di una migrazione di database: backfill, durata del blocco, implementazione e rollback. Il comando “Aggiungi una colonna” richiede una sola riga di codice SQL; la stima si riferisce all’incirca al secondo.
“Aggiungi una colonna” è una migrazione di una sola riga. La stima non riguarda la colonna.
Le migrazioni dello schema seguono due tempistiche. Una è quella dell’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 se la durata supera la finestra di distribuzione. Il team si concentra sul codice SQL perché è quello 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 l’implementazione si avvicini minimamente all’ambiente di produzione.
Ciò che viene detto nella stanza
Backend: “È solo un ALTER, la migrazione richiede un secondo.”
SRE: «Nella tabella degli ordini? Con i blocchi attivi? Alle 15:00?»
DBA: “Come procediamo al riempimento delle righe esistenti?”
SRE: “Qual è la procedura di rollback nel caso in cui l’implementazione fallisca a metà?”
Domanda principale: “Il percorso di lettura tollera che la colonna rimanga nulla per un’ora?”
Domande che vale la pena 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 ripieno: 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 reperibilità 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 è un ticket, il piano di backfill e di rollout è un altro.
Si valuti l’implementazione e il rollback, non l’ALTER. È nella seconda fase che risiede il rischio.
Si veda la stima di 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.