Cos'è il canary deployment? Guida pratica per gli SRE

Il canary deployment è una tecnica di rilascio in cui una nuova versione viene messa in produzione su una piccola porzione del traffico, confrontata con la versione già in esecuzione, e allargata solo se i numeri reggono. Quindi, cos'è il canary deployment in pratica? È un deploy con un punto di decisione integrato: la modifica raggiunge per prima l'1-5 per cento degli utenti, e un controllo sulle metriche decide se proseguire o tornare indietro.

Il resto di questa guida spiega come funziona, dove fallisce e cosa conviene automatizzare.

La pagina delle 3 di notte che un canary avrebbe trasformato in un messaggio Slack

Un deploy parte alle 16:40 di un giovedì. Il tasso di errore del servizio checkout sale dallo 0.2 al 4 per cento. Nessuno se ne accorge finché un ticket di supporto arriva due ore dopo, quando ormai ogni utente ha eseguito la nuova build. Il rollback richiede 25 minuti perché la migrazione è applicata a metà.

Lo stesso cambiamento, eseguito come canary sul 5 per cento del traffico, produce un danno circoscritto. Circa 1 utente su 20 vede il bug, il confronto con il controllo fallisce in pochi minuti e la pipeline si ferma. Il post-mortem racconterebbe cosa il canary ha intercettato, non cosa ha mancato.

Il nome viene dalle miniere di carbone, dove il canarino smetteva di cantare prima che l'aria diventasse letale. La coorte ridotta svolge lo stesso ruolo. Non impedisce la release difettosa: limita chi la respira.

Cosa fa davvero un canary deployment, passo dopo passo

Il Google SRE Workbook definisce il canarying come un rilascio parziale e a tempo limitato di una modifica, più una valutazione che decide se il rollout prosegue. Il sottoinsieme che esegue la modifica è il canary. Il resto della flotta è il controllo. Questa impostazione conta: rende il canary un test A/B sull'affidabilità reale, non un deploy lento.

Una sequenza tipica è questa:

• Installare la nuova versione accanto a quella stabile, senza traffico per il momento.

• Instradare una piccola percentuale verso di essa (l'esempio del Workbook usa il 5 per cento).

• Mantenere una finestra fissa (lo stesso esempio usa 30 minuti) confrontando canary e controllo.

• Passare allo step successivo, ad esempio 25, poi 50 e infine 100 per cento, oppure interrompere e rimandare il traffico alla versione precedente.

Il ciclo è semplice. La parte difficile è il confronto, che la maggior parte dei team implementa come «qualcuno guarda una dashboard».

Canary, blue-green e rolling: quale si adatta alla modalità di guasto

Questi tre approcci vengono confusi di continuo, quindi ecco la distinzione che conta quando si sceglie.

• Rolling update: sostituisce le istanze gradualmente. Economico e integrato in ogni orchestratore, ma non prevede un confronto con un controllo né una divisione pulita del traffico. Vecchia e nuova versione condividono il carico fino alla fine.

• Blue-green: due ambienti completi, con lo switch di tutto il traffico in un colpo solo. Il rollback è immediato, ma il raggio d'impatto nel momento dello switch è il 100 per cento degli utenti. Si paga una capacità doppia.

• Canary: una frazione controllata del traffico reale sulla nuova versione, giudicata rispetto alla vecchia. Raggio d'impatto minimo, complessità operativa massima.

Si sceglie blue-green quando il rischio è un deploy rotto che si rileva con uno smoke test e si ripristina in pochi secondi. Si sceglie il canary quando il rischio è una regressione sottile che solo il traffico reale fa emergere: un aumento della latenza p99, una perdita di memoria lenta, un piano di query che cede con i dati di produzione.

Il canary va evitato se il servizio ha un traffico molto basso. Con poche centinaia di richieste all'ora, una fetta del 5 per cento dà qualche campione e nessun segnale. Il Workbook lo dice chiaramente: pochissime query non forniscono un segnale utile per carichi di lavoro eterogenei.

Perché un canary all'1 per cento probabilmente mente

Ecco il guasto che colpisce i team nei primi tre mesi. Il canary prende il 5 per cento del traffico e fallisce il 20 per cento delle sue richieste. Il tasso di errore dell'intero servizio passa da 0.2 a circa 1.2 per cento. La soglia di allarme è al 2 per cento. Non scatta nulla.

Il monitoraggio aggregato nasconde i fallimenti del canary. La stessa aritmetica compare nel Workbook SRE: un canary che fallisce il 20 per cento delle richieste su un 5 per cento di traffico mostra solo un 1 per cento di errore globale. Bisogna scomporre le metriche per popolazione, canary contro controllo, altrimenti il segnale si perde nel denominatore.

Altre tre trappole da conoscere:

• Confronti prima e dopo. Confrontare la finestra del canary con l'ora precedente confonde la modifica con il tempo. Il solo traffico feriale rispetto a quello del weekend può coprire una regressione reale. Meglio confrontare con un controllo concorrente.

• Dipendenze condivise. Se canary e controllo usano la stessa cache o lo stesso database, un canary difettoso può degradare entrambi e il confronto non mostra nulla. Occorre verificare i domini di guasto.

• Metriche rumorose. L'uso della CPU è un pessimo gate. Codici di errore e latenza tracciano ciò che percepiscono gli utenti. Il Workbook consiglia di ordinare le metriche candidate in base a quanto riflettono i problemi visibili agli utenti e di tenerne solo poche, al massimo una dozzina.

Scegliere le metriche di gate prima del rilascio, non durante l'incidente

Si parte dagli SLI. Se il servizio ha già uno SLI di disponibilità e uno di latenza, questi sono i primi due gate. Un insieme di partenza ragionevole per un servizio guidato dalle richieste:

• Tasso di errore (5xx) su canary contro controllo, lungo la finestra di osservazione

• Latenza p99 su canary contro controllo

• Un segnale di saturazione attribuibile alla modifica, come la crescita della memoria per pod

• Una metrica vicina al business, ad esempio il completamento del checkout, se si riesce a isolarla per coorte

Le soglie sono il punto in cui i team perdono settimane. Se sono troppo strette, ogni canary si interrompe per il rumore e gli ingegneri imparano a scavalcare il gate. Se sono troppo larghe, una build difettosa passa. Vanno riviste con una cadenza regolare. Un gate che in sei mesi non ha mai interrotto nulla è perfetto oppure decorativo, e conviene scoprire quale dei due.

Inoltre, l'intervallo di aggregazione delle metriche non deve superare la finestra del canary. Un rollup di 10 minuti su un canary di 5 minuti confonde tutto.

Un canary in configurazione: come appaiono gli step in Argo Rollouts

In Kubernetes, la specifica canary di Argo Rollouts esprime la sequenza come una lista di step. Ecco una versione condensata, nella forma descritta dalla documentazione:

strategy:
  canary:
    steps:
      - setWeight: 5
      - pause: { duration: 30m }
      - analysis:
          templates:
            - templateName: error-rate-vs-baseline
      - setWeight: 25
      - pause: { duration: 30m }
      - setWeight: 50
      - pause: {}

Due dettagli della documentazione meritano attenzione. Senza un router del traffico, il peso è approssimato dal numero di pod, su base indicativa: 10 repliche al 10 per cento significano un pod canary e nove stabili. È matematica sulle repliche, non sulle richieste. E un pause: {} senza durata attende indefinitamente finché qualcuno non esegue kubectl argo rollouts promote, un gate umano che si può volere oppure no.

Se lo step di analisi fallisce, il rollout viene interrotto. È la parte in cui conviene investire.

I feature flag sono l'altra metà di un canary sicuro

I canary infrastrutturali dividono il traffico per istanza o per pod. I canary basati su flag lo dividono per utente, per account o per qualsiasi attributo selezionabile. Le due tecniche rispondono a domande diverse. La prima chiede se la nuova build è sana. La seconda chiede se il nuovo comportamento è accettabile, e permette di disattivarlo senza un redeploy.

Per i rollout guidati da flag conta lo strumento. LaunchDarkly ha le regole di targeting più mature e il registro di audit più completo, e vince sull'ampiezza dell'ecosistema. Il suo prezzo a scala enterprise è la lamentela più diffusa tra i responsabili di piattaforma.

Statsig unisce sperimentazione e flag, ed è adatto ai team che vogliono valutazioni basate su metriche sulla stessa piattaforma. Ha meno senso se serve soltanto un kill switch.

Il compromesso onesto: una piattaforma di flag offre rollout percentuali, ma la maggior parte non legge da sola gli SLO. Qualcuno deve ancora collegare la metrica alla decisione.

Serve una fonte di confronto che possa dividere per versione

Qualunque strumento guidi il rollout, il verdetto arriva dalla telemetria. Ogni metrica deve avere un'etichetta di versione o di coorte, e il backend deve poterla interrogare senza un ritardo di 10 minuti.

Datadog lo fa bene con le scomposizioni basate su tag, e il suo tracciamento dei deploy correla i rilasci con i picchi di errore. Il costo con alta cardinalità va modellato prima di taggare tutto.

Grafana con Prometheus funziona se è già in uso e le metriche sono etichettate per revisione di rollout. Si ottiene pieno controllo, ma la manutenzione resta a carico del team.

Automatizzare l'interruzione: da dove nasce l'idea del pilota AI

L'analisi manuale del canary scala male. Con dieci deploy al giorno nessuno fissa una dashboard per 30 minuti ogni volta, e così il gate diventa silenziosamente «sembra a posto». Il modello che regge è un giudice automatico: si definiscono l'SLO e il confronto, e un controller interrompe e ripristina quando il canary consuma il budget di errore più in fretta del controllo.

È il problema che l'AI Pilot di upstreamapi affronta: legge il segnale SLO durante il rollout e attiva un auto-rollback quando il tasso di errore supera la soglia impostata. Misura tasso di errore e latenza rispetto alla coorte stabile, niente di più misterioso. Se si usano già i template di analisi di Argo Rollouts con una buona query Prometheus, si dispone di gran parte della stessa capacità, e conviene dirlo a chiunque venda soluzioni magiche. Un pilota ospitato trova la sua ragion d'essere negli stack eterogenei, dove ogni team dovrebbe altrimenti mantenere i propri template di analisi.

Un errore ricorrente: i team automatizzano lo step di promozione e non automatizzano mai l'interruzione. Una pipeline che sa solo andare avanti è un nastro trasportatore.

Cosa misurare per capire se il processo canary funziona

Un programma canary ha le proprie metriche. Da monitorare nell'arco di un trimestre:

• Tasso di interruzione dei canary: quota di canary fermati dal gate. Zero significa che il gate è cieco. Sopra il 20-30 per cento di solito indica soglie instabili o test pre-merge scarsi.

• Tempo di rilevamento sul canary: minuti tra la prima richiesta difettosa e l'interruzione. È il vero MTTD per i rilasci.

• Regressioni sfuggite: incidenti riconducibili a una release passata dal canary. Ognuno dovrebbe modificare un gate.

• Tempo medio di ripristino: dalla decisione di interruzione al 100 per cento del traffico sulla versione stabile.

Eseguire un solo canary alla volta per servizio. Il Workbook lo raccomanda con forza, e il motivo è pratico: due modifiche sovrapposte rendono impossibile l'attribuzione, e non si sa quale delle due abbia causato il danno.

Da dove cominciare questa settimana

Scegliere un servizio stateless con traffico sufficiente per produrre un segnale in 15 minuti. Aggiungere un'etichetta di versione alle sue metriche di errore e latenza. Scrivere una sola query di confronto, canary contro controllo. Eseguire un canary del 5 per cento con promozione manuale e annotare cosa si sarebbe intercettato negli ultimi tre incidenti.

Poi conviene porsi la domanda scomoda: se il canary fosse fallito alle 02:00, qualcosa lo avrebbe fermato senza un umano sveglio?