Scrivere un runbook di cutover per la migrazione con un orologio su ogni passo

La differenza tra una migrazione che costa cinque minuti di downtime visibile e una che si mangia un fine settimana raramente sta nell'hardware. Sta nel fatto che il cutover sia stato scritto, prima della notte, come una sequenza di passi cronometrati, verificabili e reversibili, e provato finché i tempi non erano noti. Ecco come scriviamo quel documento.

Il problema: la notte è il momento peggiore per pensare

Ogni decisione presa durante la finestra (quale sincronizzazione va per prima, quanto aspettare una replica, quando arrendersi e tornare indietro) è presa da persone stanche e sotto pressione, di solito con il proprietario del sito al telefono. Lo scopo di un runbook è che nessuno debba decidere, durante la finestra, qualcosa che poteva essere deciso la settimana prima.

Una lista di compiti non è un runbook. Un runbook ha cinque colonne.

Le cinque colonne

Passo	Budget	Responsabile	Verifica	Via del ritorno
Congelare le scritture sull'origine	2 min	app	login admin rifiutato, coda ordini vuota	togliere il congelamento
Sincronizzazione finale dei file	3 min	ops	rsync non elenca ulteriori modifiche	non serve, origine intatta
Riallineamento finale del database e promozione	3 min	db	GTID uguale sui due lati, destinazione in lettura e scrittura	retrocedere la destinazione, scongelare l'origine
Cambio di DNS e load balancer	2 min	net	la nuova origine risponde attraverso il nome pubblico	ripristinare il record
Smoke test	5 min	app	checklist di pagine, login, checkout, ricerca	ripristinare il DNS

Il budget è il tempo che il passo ha richiesto in prova generale, più un margine. Il responsabile è una persona, non un team. La verifica è un fatto osservabile, non «sembra a posto». La via del ritorno è l'azione esatta che annulla il passo, e se un passo non ha via del ritorno è il punto di non ritorno e va marcato come tale.

Prima della finestra: spostate quasi tutto in anticipo

Il cutover dovrebbe spostare solo ciò che è cambiato dall'ultima sincronizzazione. Tutto il resto avviene giorni prima, mentre l'origine continua a servire:

• Costruite la destinazione da zero secondo specifiche misurate, invece di ripristinare immagini dei vecchi server.
• Inizializzate il database da un backup fisico e tenetelo aggiornato per replica. La notte, il riallineamento è questione di secondi di delta.
• Pre-sincronizzate i file ripetutamente, così l'ultimo passaggio è piccolo. Fate una prova a vuoto il giorno prima per vedere cosa sposterà il passaggio finale:

rsync -aHAX --numeric-ids --delete --itemize-changes --dry-run \
  source:/var/www/ /var/www/ | wc -l

• Copiate gli indici di ricerca con il reindex remoto del motore stesso invece di far ripercorrere i contenuti all'applicazione.
• Abbassate i TTL del DNS a pochi minuti almeno due vecchi TTL prima della finestra, così i resolver hanno dimenticato il valore lungo quando fate il cambio. Controllate cosa vede davvero il mondo:

dig +noall +answer www.example.com @<public-resolver-1>
dig +noall +answer www.example.com @<public-resolver-2>

Provate su una copia, con il cronometro

Eseguite l'intero cutover su una copia della destinazione almeno una volta, con gli stessi comandi, in ordine, cronometrando ogni passo. La prova generale produce la colonna del budget. Produce anche le sorprese: la sincronizzazione dei file che percorre lentamente milioni di file invariati per un flag mancante, l'utente di replica a cui manca un privilegio, l'health check che punta al percorso sbagliato.

Aggiungete ogni lezione al template del runbook, non solo alla copia di questa migrazione. È così che la decima migrazione diventa più facile della prima.

Scrivete in anticipo i criteri di go o no go

Concordate, prima della finestra e con il proprietario del sito, cosa deve essere vero per iniziare, e cosa causerà un rollback:

• Go: ritardo di replica sulla destinazione sotto una soglia concordata, ultima sincronizzazione di prova dentro il budget, monitoraggio sulla destinazione verde, le persone nominate nella colonna del responsabile presenti.
• Innesco del rollback: qualsiasi passo che superi il doppio del suo budget, oppure gli smoke test che non passano entro un'ora fissata dopo il cambio.

Scrivere l'innesco elimina l'istinto più pericoloso di ogni notte di cutover: «diamogli altri dieci minuti». Se l'orologio dice rollback, si fa il rollback, e si riprova un'altra notte con un runbook migliore.

Rendete economica la via del ritorno

Un rollback che richiede un ripristino da backup non è un rollback che qualcuno sceglierà di usare. Progettate ogni passo in modo che annullarlo sia veloce:

• L'origine resta intatta e in funzione finché la destinazione non ha dato prova di sé. I suoi dati non vengono mai cancellati durante la finestra.
• Sulla destinazione, tutto ciò che viene sostituito viene rinominato, mai rimosso. Tornare indietro è una rinomina e un cambio di DNS.
• La promozione del database avviene solo dopo che entrambi i lati riportano lo stesso GTID, così una retrocessione vi riporta a una posizione nota.
• Le modifiche di configurazione si applicano come file che potete scambiare, non come modifiche da ricordare.

mv /var/www/site /var/www/site.pre-cutover-$(date +%F)
mv /var/www/site.new /var/www/site

Eseguite la finestra, poi fate l'audit

Durante la finestra, una persona legge il runbook ad alta voce e registra il tempo effettivo accanto a ogni budget. Nessuno improvvisa. Quando l'ultimo smoke test passa, tenete l'origine in funzione e osservate entrambi i lati: il traffico dovrebbe defluire dalla vecchia origine man mano che le cache scadono. Qualsiasi cosa arrivi ancora all'origine dopo che il vecchio TTL è trascorso è una dipendenza che nessuno ha elencato, come un cron job, un client API o un indirizzo scritto nel codice, e va trovata prima che l'origine venga spenta.

Dopo, confrontate la nuova piattaforma con la vecchia baseline: esposizione esterna, tempi di risposta, hit rate della cache, tassi di errore. Solo allora dismettete l'origine, e conservatene i dati finché il proprietario non firma.

La vostra checklist

• Ogni passo ha un budget, un responsabile, una verifica e una via del ritorno.
• Dati inizializzati e file pre-sincronizzati giorni prima; la finestra sposta solo il delta.
• TTL abbassati in anticipo e verificati dall'esterno.
• Una prova generale cronometrata su una copia, con le lezioni riportate nel template.
• Criteri di go e di rollback concordati per iscritto prima della notte.
• Origine mantenuta intatta finché l'audit non è concluso e il proprietario ha firmato.

Se avete uno spostamento all'orizzonte, saremo lieti di aiutarvi a scrivere il runbook.

Parla con un ingegnere

Related (rows[1])

Correlati: Migrazioni di datacenter gestite, provate in anticipo · Replica di database e repliche offsite · Live migration e uscita dall'hypervisor