Installazione zero-downtime

(Sezione Architettura e Protocolli)

1) Cos'è Zero-Downtime e perché è necessario

• Zero facile per clienti e integrazioni.
• Rilascio prevedibile, ritorno rapido e rischio gestito.
• Conserva SLO/SLI (latitanza, errori, disponibilità) nei limiti degli accordi.

La chiave di ZDT non è una tecnica «magica», ma una combinazione di pattern di consegna, compatibilità dei dati e corretta routing del traffico.

2) Principi di base Zero-Downtime

1. Compatibilità versione: la nuova versione deve gestire il traffico e i dati contemporaneamente.
2. Idampotenza delle operazioni: la riprogettazione non deve interrompere lo stato.
3. Completamento grazioso (graceful shutdown) e drenaggio delle connessioni.
4. Controllo sanitario passo passo: readover/liveness campioni, health-endpoint.
5. Il ritorno come primo cittadino è più semplice e veloce di hotfix.
6. Osservabilità by design: etichette di rilascio, dashboard unificati, alert SLO.
7. Automazione: gli script di rilascio e ripristino sono codice, non istruzioni manuali.

3) Cartelli di consegna senza downtime

3. 1 Rolling Update

Rimuoviamo gradualmente alcune istanze della vecchia versione, le aggiorniamo a una nuova versione e le riportiamo al pool.

Vantaggi: risparmio sull'infrastruttura, solo in k8s/ASG.
Contro: per un po "il cluster funziona con due versioni contemporaneamente (variante skew).

3. 2 Blue-Green

Due protesi completi: attivo (Blue) e candidato (Green). Il cambio di traffico è una flip atomica.

Il lato positivo è il ritorno istantaneo, l'isolamento puro.
Contro i costi delle infrastrutture, più complicato con la stateful.

3. 3 Canary/Rollout progressivo

Forniamo una piccola quota di traffico (1-5-10-25-50-100%) alla nuova versione gate per metriche.

I vantaggi sono un minimo di blast radius, una soluzione data-driven.
Contro - bisogno di osservazione matura e routing intelligente.

3. 4 Shadow traffic / Dark launch

Mirroring delle query reali in una nuova versione (senza risposta all'utente) o avvio nascosto per assemblare le metriche.

I vantaggi sono l'identificazione precoce dei problemi.
Contro - doppio carico di dipendenza, dobbiamo controllare gli effetti collaterali.

4) Gestione del traffico e delle connessioni

4. 1 Readiness/Liveness

Liveness dice all'orchestratore «riavvicinami».
«Non guidare il traffico, non sono ancora pronto».
Non è possibile rilasciare senza una corretta logica e timeout.

4. 2 Drenaggio delle connessioni (Connection Draining)

• smettete di accettare nuove connessioni,
• in attesa del completamento degli attivi
• Interrompiamo il tempo.

4. 3 sessioni Sticky e routing livello L7

Sticky è utile per gli script stateful, ma rende più difficile il bilanciamento del carico di lavoro.
Le regole L7 (percorso, intestazione, cookie, API) sono comode per il canary/ring.

4. 4 Connessioni a lunga durata

WebSocket/gRPC streaming - Accendere il segnale «GOAWAY» prima dell'aggiornamento.
Pianificare Windows per superare gli striam e i becof-retrai client.

5) Compatibilità dei dati e migrazione del database

5. 1 Expand-Migrate-Contract

1. Espand - Aggiungi nuove colonne/indici/tabelle senza stravolgere la versione precedente.
2. Migrate - Trasferiamo i dati di sottofondo e idipotente (batch, checkpoint).
3. Contract - Rimuoviamo il vecchio solo dopo la stabilizzazione.

5. 2 Pratiche

Evitare l'esclusivo DDL-lock nella finestra di rilascio.
Versionare i contratti API/eventi (schema registry, CDC).
Per le migrazioni pesanti, strumenti online, repliche, spostamenti graduali.
Record dual-write (dual-write) solo con deduplicazione e utenti idipotenti.
Outbox/Inbox per l'integrazione affidabile attraverso le code.

6) Cache, sessioni e operazioni di sfondo

Sessioni e cache esterne (Redis/Memcached) in modo che le versioni siano scambiabili.
Riscaldamento della cache/jit/indice di ritmo prima di essere incluso nel pool.
Separare le code di sfondo per versione o utilizzare la leadership per evitare corse.

7) Osservabilità e gate SLO

Golden signals: latitanza p95/p99, error rate, RPS, saturation, fila.
Business SLA: autorizzazioni, conversioni, pagamenti completi, rinuncia ai passi del vortice.
Il rollout è avanzato solo se canary ≤ baseline + soglia di degrado, e non brucia.

8) Completamento sicuro e ripristino

Il ritorno è la stessa piplina, solo al contrario: comandi fissi, non craft manuale.
Per blue-green - flip back; canary - perdita di peso fino allo 0% o precedente passo stabile.
Dati: transazioni compensative, rielaborazione, deduplicazione degli eventi.

9) Assegno-fogli Zero-Downtime

Prima del lancio

• Assemblaggio di un manufatto firmato (immutabile), SBOM e controllo delle dipendenze.
• Readava/liveness sono stati implementati e testati.
• Piano di migrazione in modalità expand, reversibilità confermata.
• Dashboard e alert per la nuova versione sono pronti, etichette di rilascio sono pronte.
• Il ripristino è stato convalidato su staging/pre-prod.

Durante il lancio

• Il drenaggio delle connessioni è acceso, i timeout sono adeguati.
• Il traffico viene tradotto gradualmente (canary/ring) o flip (blue-green).
• Le metriche vengono confrontate con baseline e le soglie di gate vengono rispettate.

Dopo il lancio

• Post-monitoraggio N ore, nessun incidente.
• Migrazioni contract completate e bandiere/percorsi temporanei rimossi.
• Retrospettiva, aggiornamento playbook.

10) Anti-pattern

Recreate-deplay senza drenaggio e readehi le query.
Il DDL non è pronto per blocchi e timeout in prima serata.
Combinazione di diagrammi incompatibili tra le versioni del servizio.
Nessuna idepotenza nei processori e nei worker.
Senza gate o confronto con baseline.
DNS-TTL lungo con blue-green, che fa sì che la flip duri ore.
Sessione/cache locale nella memoria dell'istanza di rolling/canary.

11) Script di implementazione

11. 1 Kubernetes (rolling + canary)

Deployment с `maxUnavailable=0`, `maxSurge=25%`.
Readavain attesa di riscaldamento (inizializzazione cache, migrazione minore).
Strumenti-mesh/Ingress con weighted routing (1-5-10-25-50-100%).
Alert: p95, 5xx, fila, vortice d'affari.

11. 2 Blue-Green nella nuvola

Due pile dietro il bilanciatore. example. com` и `green. example. com`.
Riscaldamento green, smoke/regress, quindi listener/route swap (o failover DNS con TTL basso).
In caso di problemi, flip back istantaneo.

11. 3 Servizio Stateful

Repliche di dati + migrazioni online doppia lettura con validazione.
I jobs di sfondo vengono spostati in base alla «leadership» della versione o alle code divise.
Sessioni/cache fuori sede; sticky è attivato solo temporaneamente.

12) Phicheflagi e applicazioni client

I nuovi fili vengono attivati con le bandiere (i segmenti sono i dipendenti del Beta).
Per i client mobile/disctop, tenere conto dei limiti di compatibilità del protocollo e della sopravvivenza delle versioni precedenti (deprecation policy, server-side fallback).

13) Prestazioni e costi

Rolling è più economico, ma richiede una compatibilità attenta.
Blue-Green è più costoso durante il lancio, ma il rimborso è immediato.
Canary bilancia rischi e costi, ma richiede una forte osservabilità.
Risparmiare attraverso l'espansione ephemerale e pulizia automatica degli stand.

14) Piplining minimo ZDT

1. Build: un unico artefatto, firma, SBOM.
2. Test: unit/integration/contract + security.
3. Staging: smoke, carico di lavoro, migrazioni in modalità expand, controllo di ripristino.
4. Prod: shadow → canary (gate) o blue-green flip.
5. Post-deploy - osservazione, contract-cleanup, retrò.

15) Breve riepilogo

Zero-Downtime è una disciplina: versioni compatibili + routing corretto + migrazioni gestite + osservabilità e ripristino rapido. Scegli un pattern sotto il contesto (rolling, blue-green, canary), automatizzi i gate SLO, tieni i dati idipotenti - e le release smetteranno di essere un evento, diventando un processo di routine affidabile.