Un personaggio raffigurato su un post-it, dall’aria preoccupata, con una mano appoggiata su un pesante schedario, che lancia uno sguardo all’orologio da parete posto sopra di esso.

Stima dei tempi necessari per la migrazione di un database

Come stimare la migrazione di un database: backfill, durata del blocco, implementazione e rollback. Il comando “Aggiungi una colonna” è costituito da 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 relativa all’SQL: solitamente rapida, 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 si protragga oltre la finestra di distribuzione. Il team si concentra sul codice SQL perché è ciò che è indicato nel ticket. Il lavoro vero e proprio si svolge nel 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 anche solo lontanamente 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 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 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. Dividetele: 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 relativa alla migrazione dei dati per la variante intersistemica, nonché gli altri esempi pratici di stima. Una volta delineato il piano di implementazione, si avvii una sessione gratuita di “planning poker”.