Rollback e ripristino della stabilità

(Sezione Tecnologia e infrastruttura)

Breve riepilogo

Il ripristino è un ritorno gestito all'ultima versione stabile con un rischio minimo di perdita di dati e violazioni SLO. Un processo affidabile include: segnali SLO, gate chiari e criteri di riparazione, meccanismo di cambio (GitOps/Ingress/mesh), schema di dati compatibile, configi/segreti/cache isolati, runabook e un ciclo di miglioramenti post-incidenti.

1) Quando ritoccare (criteri di avvio)

SLO/Business Gate: p95/99 sopra la soglia, errore-rate ↑, calo della conversione dei pagamenti/rate, aumento dei timeout PSP.
Tecnologie: crash sottostante, perdita di memoria, crescita delle code, degrado dei token/sec (LLM), 5xx su Edge.
Rischio dati: migrazioni non corrette, repliche incoerenti, transazioni/pagamenti orfani.
Sicurezza/PII - Sospetto di fuga - ritorno immediato/isolamento.

Regola: se 2 + metriche chiave oltre le soglie> N minuti, viene attivato il ripristino.

2) Tipi di rolback

1. Applicazione: reimpostare i contenitori/pacchetti sul tag precedente.
2. Ficci: disattivazione istantanea attraverso la feature flag/kill-switch.
3. Instradamento: ritorno del peso su una versione stabile (canary→stable) o Blue→Green.
4. Database: rimborso logico (rimborso), restituzione graduale dello schema; PITR è una misura estrema.
5. Infrastruttura: reimpostazione di manifesti/Terraform Plan; Restituisce le configurazioni di rete/WAF.
6. Dati/cache/code: reimpostazione/disabilità/reimpostazione dei messaggi; Cache di versioni.

3) Principi architettonici per un ritorno sicuro

La compatibilità degli schemi è una strategia di expand→migrate→contract (è possibile ripristinare tra expand e contract).
Dipendenze isolate: segreti separati/configi/cache/code per le revisioni.
Operazioni Idempotent: la ripetizione delle migrazioni è sicura.
Immutabilità dei manufatti: immagini, liste, script SQL - versionati e firmati.
GitOps vero - La versione corrente e il routing sono registrati nel repository manifesto.

4) Meccanica di rientro (Kubernetes/GitOps)

Argo Rollouts (ritorno del peso)

yaml apiVersion: argoproj. io/v1alpha1 kind: Rollout metadata: { name: api }
spec:
strategy:
canary:
steps:
- setWeight: 5
- pause: { duration: 10m }
in case of analysis failure → automatic rollback to stable

GitOps-Reimpostazione (idea)

git revert <commit_with_bad_version>
git push # Argo CD/Flux revert cluster to previous revision

NGINX: un maglione veloce su stabile

nginx map $cookie_canary $to_canary { default 0; 1 1; }
upstream stable { server api-stable:80; }
upstream canary { server api-canary:80; }
server {
location / {
if ($to_canary) { proxy_pass http://canary; }
proxy_pass http ://stable; # removed canary cookie - instant rollback
}
}

5) Rollback e protezione dei dati

• Espand - Aggiungi nuovi campi/indici, il codice supporta il vecchio e il nuovo schema.
• Migrate: il codice inizia a scrivere in un nuovo schema, il vecchio non si rompe.
• Contract - Rimuoviamo il vecchio solo dopo la stabilizzazione.
• PITR/snapshot: usa solo se non è possibile un rimborso logico.
• Rimborsi: script/jobs separati per correggere inserzioni/bilanci/pagamenti.
• Finestra read-only - Se criticato, blocchiamo temporaneamente la voce per congelare lo stato.

sql
-- expand
ALTER TABLE wallet ADD COLUMN bonus_balance NUMERIC DEFAULT 0 NULL;
CREATE INDEX CONCURRENTLY idx_wallet_bonus ON wallet(bonus_balance);

-- migrate in code, two-sided write
-- contract (after stabilization)
ALTER TABLE wallet DROP COLUMN legacy_bonus_balance;

6) Code e cache al ripristino

Cache versione: chiavi con prefisso versione ('v2:') per la convivenza sicura.
Disabilità: durante il ripristino, pulizia di massa «v2:», ritorno a «v1:».
Code: partitini/topic per versione; reimpostazione dei messaggi dal punto di controllo.
Deduplicazione/idampotenza: chiavi di idempotenza per la ripetizione senza doppie.

7) SLO-gate e auto-rimborso

Metriche: p95/99, errore-rate, saturations (CPU/IO/GPU), queue depth, token/s, conversione dei pagamenti.

if p95_latency_ms > 250 for 5m OR error_rate > 1. 5% for 3m OR payment_conv < baseline-0. 3%
then rollback release && open incident && freeze deploys

8) Runabuki (playbooks)

A) Altezza p99 e 5xx dopo il lancio

1. Stop promote (congelare canary/blue-green).
2. Switch traffic per una revisione stabile.
3. Controlla la cache/coda/ritardo PSP.
4. Disattivare la diagnostica: fogli, profili, versioni client/diagrammi.
5. Comunicazione: ChatOps, stato-canale, incidente-tessera.
6. Avvia un'azione di regolazione: patch/hot fix/annulla fici.

B) Errore nella migrazione del database

1. Freeze writes (read-only, breve).
2. Il ripristino dell'applicazione è una versione stabile (compatibile con il vecchio schema).
3. Esegui rimborsi/script rollback.
4. Scongelare la registrazione; Osservare la deriva/errori.

C) Degrado dei pagamenti (PSP)

1. Passa al percorso precedente di instradamento PSP.
2. Ripristina la release del processing.
3. Verifica di tutti i pagamenti in sospeso, ripetizione con chiavi idipotenti.

D) LLM/raccomandazioni degradate

1. Disattiva il nuovo modello/parametri (feature flag).
2. Restituire il vecchio endpoint/peso; cancellare la cache KV della nuova revisione.
3. Controlla tokens/s, primo token latency, tossicità.

9) Comunicazioni e congelamento dei comunicati

Freeze window: dopo la rimozione, pausa di rilascio fino a RCA/fix.
Un unico canale: status update, cronologia delle azioni, chi ha fatto cosa.
Steikholder: prodotto/CS/pagamenti/avvocati (PII).

10) Post-incidente: analisi e prevenzione

RCA (senza accuse) è la causa principale, il contributo dei fattori per cui i gate non hanno funzionato (se non hanno funzionato).
Azioni: test di migrazione, limiti, phicheflag-gate, osservabilità.
Soglia SLO: regolazione se troppo «morbido «/» rigido ».
Documentazione: aggiorna runabuki, aggiungi alert, allenamenti (game-day).

11) Strumenti e modelli

GitOps: Argo CD/Flux - «revert »/« rollback» commit con versione.
Progressive delivery: Argo Rollouts/Flagger - stop/ritorno per metriche.
Edge/Ingress: instradamento di peso, cookie routing, maglioncino veloce.
Feature flags: fractional rollout, kill-switch.
Migrazioni DB: frame con up/down, dry-run, throttling.
Osservabilità: dashboard finiti «release compare» (stabile vs canary).

12) Assegno foglio pronto per i rimborsi

1. Manufatti versionati e firmati (immagini/liste/SQL).
2. Configi a due binari/segreti/cache/code (prefissi versioni).
3. Schema di controllo expand→migrate→contract.
4. Release canarie e blue-green con SLO-gate e auto-ritorno.
5. Runabook su script chiave (pagamenti/database/cache/LLM).
6. Pulsanti ChatOps: '/rollback ', '/freeze', '/promote'.
7. Controllo e logica: chi, quando, cosa ha ritrattato; Artefatti diagnostici.
8. Allenamento game-day - Simulazione di errori e ripristini.
9. Un piano di comunicazione con gli affari e lo zappone.
10. Metriche di confronto (stabile vs new) sullo stesso schermo.

13) Anti-pattern

Migrazioni distruttive fino alla risoluzione del codice (nessuna compatibilità inversa).
Cache/code condivise senza versioni di .
La mancanza di GitOps/cronologia delle modifiche consente di modificare manualmente la prua.
Rilascio di canarini senza gate/telemetria.
Ritorno senza freeze e RCA per ripetere l'incidente.
Monitoraggio solo delle tecnologie senza metriche aziendali (pagamenti/scommesse).
I segreti comuni a tutte le revisioni sono difficili da isolare.

Riepilogo

Un roll affidabile non è uno stop-rubinetto, ma un processo integrato nelle release: versionalità e compatibilità, dipendenze isolate, gate SLO, realtà GitOps, ritocchi automatici e runabook chiari. Questo approccio consente alle piattaforme iGaming di ripristinare rapidamente la stabilità riducendo al minimo la perdita di dati e ricavi e trasformando ogni incidente in una fonte di miglioramento.