Scrivete prima il rollback: un template per gli aggiornamenti di routine

Le piattaforme restano indietro per un motivo semplice: ogni aggiornamento sembra rischioso, quindi viene rimandato, e ogni rinvio rende il prossimo aggiornamento più grande e ancora più rischioso. La via d'uscita è rendere noiosi gli aggiornamenti. Significa un template da seguire ogni volta, e la riga più importante al suo interno è quella che la maggior parte dei team scrive per ultima: come tornare indietro.

Sapere che una release esiste prima di averne bisogno

Pubblichiamo ogni nuova build, con il suo changelog, nella nostra chat operativa il giorno stesso in cui esce.

Un affinamento vale la pena copiarlo. Molti progetti pubblicano correzioni per i rami più vecchi accanto a quello corrente. Un watcher che annuncia ciecamente «nuova release» può tentare qualcuno a installare un back-port più vecchio di ciò che è già in esecuzione. Noi li etichettiamo automaticamente come «da non distribuire», così nessuno fa un passo indietro per sbaglio.

Preparate la modifica

Leggete il changelog come un contratto

Nelle note di rilascio, le migrazioni contano di più: qualsiasi cosa che viene eseguita una volta sola e non si annulla facilmente, come una modifica di schema, decide cosa deve includere il vostro rollback.

Controlli preliminari su ogni server

Poi controllate ogni server che toccherete, non la flotta in generale, ed elencate i suoi plugin, estensioni e integrazioni rispetto alla nuova release.

Un plugin di cui nessuno si ricordava è la ragione più comune per cui un aggiornamento altrimenti pulito fallisce. Elencarli per server richiede minuti ed elimina la sorpresa.

Fate un backup che avete guardato davvero

«Il job di backup è girato» non è la stessa cosa di «abbiamo un backup». Prima della modifica, fate un dump consistente e testatelo:

mysqldump --single-transaction --routines --triggers --events <db> \
  | gzip > <db>-pre-upgrade-$(date +%F-%H%M).sql.gz
gzip -t <db>-pre-upgrade-*.sql.gz && ls -lh <db>-pre-upgrade-*.sql.gz

Scrivete il rollback prima della modifica

È il passo che trasforma un aggiornamento rischioso in uno di routine. Prima di iniziare, scrivete, in ordine, i passi esatti che riporterebbero il sistema dov'è adesso. Sui sistemi basati su RPM la parte dei pacchetti è di solito breve:

dnf history list | head
dnf history undo <transaction-id>

E per impedire che un pacchetto noto per funzionare si muova mentre testate, il plugin versionlock lo blocca:

dnf versionlock add <package>

Ma i pacchetti raramente sono tutta la storia. Se la release esegue una migrazione di schema, tornare indietro con i soli pacchetti vi lascia con codice vecchio su uno schema nuovo. Il vostro rollback deve allora includere il ripristino del dump che avete appena fatto, e dovete sapere quanto dura quel ripristino. Scrivete tutto, e dove potete, provatelo prima su una copia. Un rollback che esiste solo nella vostra testa nel momento in cui le cose vanno storte non è un rollback.

Cambiate una macchina alla volta

Sulle piattaforme ridondate, un nodo alla volta. Le release maggiori vanno prima sulle nostre istanze e girano lì prima che qualsiasi istanza di un cliente le riceva.

Misurate e verificate

Misurate il downtime invece di stimarlo

«Circa un minuto» è un'ipotesi. Un probe in esecuzione per tutta la modifica vi dà il numero vero. Avviatelo prima di iniziare e fermatelo quando avete finito:

while true; do
  printf '%s %s\n' "$(date +%T.%3N)" \
    "$(curl -s -o /dev/null -m 2 -w '%{http_code}' https://<service>/health)"
  sleep 0.5
done | tee upgrade-probe-$(date +%F).log

Dopo, la prima e l'ultima riga non 200 nel log delimitano l'interruzione a mezzo secondo. Quello è il numero che riferite alle persone che dipendono dal servizio, ed è il numero con cui confronterete la volta successiva. Nell'arco di un trimestre, queste misurazioni sono la migliore prova che avete che gli aggiornamenti stanno diventando più sicuri invece che più rischiosi.

Verificate dall'esterno, poi portate dietro il sistema operativo

Quando l'aggiornamento è finito, fate scattare un allarme di prova per sapere che il monitoraggio vede ancora il servizio. Poi usate la stessa finestra per portare al corrente anche i pacchetti del sistema operativo. Applicazione e fondamenta restano al passo, e il prossimo aggiornamento non comincia con una pila di aggiornamenti non correlati.

Il template

• Release notata e annunciata, back-port etichettati.
• Changelog letto cercando correzioni di sicurezza, cambiamenti incompatibili e migrazioni.
• Ogni server sottoposto ai controlli preliminari, plugin compresi.
• Backup fresco fatto e ispezionato.
• Rollback scritto, passo per passo, prima della modifica.
• Un nodo alla volta, le major prima sui vostri sistemi.
• Downtime misurato da un probe, riferito in secondi.
• Verificato dall'esterno, sistema operativo aggiornato nella stessa finestra.

Se le vostre piattaforme sono rimaste indietro e il prossimo aggiornamento sembra un progetto, possiamo aiutarvi a tornare alla routine. Parla con un ingegnere

Related (rows[1])

Correlati: Aggiornamento delle piattaforme e disciplina degli upgrade · Risposta urgente alle vulnerabilità in giornata · Monitoraggio della flotta e instradamento degli allarmi