Reimpostazione automatica dei lanci

1) Perché è necessario un ripristino automatico

• riduce CFR e MTTR;
• protegge SLO (auth-success, p99 «stavka→settl», errato-rate)
• impedisce incidenti complessi (PII/RG/AML).

2) Principi

1. Revert is a feature - Il ripristino è previsto per il lancio.
2. Policy-as-Code - soglie, finestre, eccezioni - convalida nella catena di montaggio.
3. Canary-first - Promozioni di gradini, retromarcia di passi specchiati.
4. Le migrazioni Data-safe sono reversibili/sommative; confighi versionuruem.
5. SLO-gates - Rosso SLI/Guardrails per il check-out automatico immediato.
6. Esplainability: timeline, diffide, cause - WORM Magazine.
7. No single button of doom - Vincoli, conferma di rischio-azione, SoD.

3) Trigger auto-ritorno (segnali)

3. 1 SLI tecnico/KRI

auth _ success _ rate drop per GEO/PSP/BIN (ad esempio - 10% in TR ≥10 min).
latency p99/error-rate percorsi chiave (deposito/output/settl).
queue lag / DLQ rate / retry storm.
db replication lag / cache miss surge.

3. 2 Segnali aziendali

deposit _ conversion - X p. su canaretto contro controllo.
settle throughput caduta rispetto alla linea base.
chargeback/decline spikes (soft/hard).

3. 3 Eventi critici

Errore SRM in A/B attivo (distorsione del traffico).
Attivazione di sicurezza/guardrail PII.
Incompatibilità di diagrammi/configli (validatore/linter).

4) Modelli di reversibilità architettonici

Canary → Ramp → Full: promozione al 5%→25%→100%; Il ritorno è inverso (100→25→5→0).
Blue-Green è un maglione atomico del traffico tra Blue e Green, il ritorno è immediato.
Feature Flags: kill-switch per le modifiche comportamentali (TTL, guardrail, SoD).
Config as Data: promozione GitOps/re-promozione della versione precedente; runtime-snapshot.

• bifase (expand→contract),
• reversibile (script down),
• write-shadow (i nuovi campi sono duplicati),
• read-compat (il vecchio codice comprende il nuovo schema).

5) Criteri di rientro (policy-engine)

• `auto_rollback if auth_success_rate. drop(geo="TR") > 10% for 10m AND coverage>=5%`
• `auto_rollback if bet_settle_p99 > SLO1. 25 for 15m`
• `auto_pause_flag if api_error_rate > 1. 5% for 5m`
• `deny_promote if slo_red in {"auth_success","withdraw_tat_p95"}`
• `require_dual_control if change. affects in {"PSP_ROUTING","PII_EXPORT"}`

Tutte le regole vengono versionate, testate e rese.

6) Flusso di recupero automatico (end-to-end)

1. Il rilevatore di regressione funziona (metrica/alert/validatore).
2. Verifica delle eccezioni (picchi natalizi, finestre di prova).

7) Integrazioni

Incidente-bot: '/release rollback <id> ', timeline auto, riferimenti a dashboard e diffusi.
API Metrics: stati SLO e guardrail finiti explars per RCA.
Feature Flags: '/flag off <id> ', aurora automatica di guardrail.
GitOps/Config: `/config rollback <snapshot>`; il rilevatore drivt conferma il risultato.
Pagina Status: update pubblici opzionali (tramite CL/Policy).

8) Osservabilità e telemetria di rientro

Release Dashboard: auth-success, error-rate, p95/p99, settle throughput, PSP по GEO/BIN.
Guardrail Board: regole attive/attive, finestre, isteresi.
Storia dei rivestimenti:% canarini/bandiere/regioni nel tempo.
Controllo: chi/cosa/quando/perché; Diffusioni di manufatti; Versione dei criteri il risultato.

9) Sicurezza, SoD e compilazione

4-eyes/JIT per le azioni che influenzano i pagamenti/PII/RG.
Geo-fences - I rimborsi che interessano i requisiti regolatori vengono applicati localmente.
Registri WORM - Traccia invariabile per i controlli.
Pacchetti pubblici comm: coerenti con CL/Legale; i dettagli degli esperimenti non vengono rivelati.

10) Esempi di manufatti

10. 1 Criterio di recupero automatico (YAML)

yaml apiVersion: policy.platform/v1 kind: AutoRollbackRule metadata:
id: "payments-auth-success-tr"
spec:
scope: { tenants: ["brandA","brandB"], regions: ["EU"], geo: ["TR"] }
signal:
metric: "auth_success_rate"
condition: "drop > 10% for 10m"
compareTo: "canary_control"
action:
strategy: "step_down"  # 100%->25%->5%->0%
cooldown: "15m"
exceptions:
calendar: ["2025-11-29:black_friday"]
manualOverride: false audit:
owner: "Payments SO"
riskClass: "high"

10. 2 Manifesto di ripristino della configurazione

yaml apiVersion: cfg.platform/v1 kind: ConfigRollback metadata:
id: "psp-routing-revert-2025-11-01"
spec:
from: "payments-routing-2025-11-01"
to:  "payments-routing-2025-10-29"
criteria:
- metric: "auth_success_rate"
where: "geo=TR"
condition: "drop>10% for 10m"
notify:
incidentBot: true stakeholders: ["Payments","SRE","Support"]

10. 3 Kill-switch flag

yaml apiVersion: flag.platform/v1 kind: KillSwitch metadata:
id: "deposit.flow.v3"
spec:
guardrails: ["api_error_rate<1.5%","latency_p99<2s","slo_green:auth_success"]
autoPauseOnBreach: true ttl: "30d"

11) Gestione delle migrazioni dei dati

• Espand - Aggiungere nuove colonne/indici senza interrompere la lettura.
• Migrate: doppia scrittura/replica, compressione della consistenza.
• Contract - Rimuove il vecchio solo dopo aver rilasciato con successo + finestra di sorveglianza.
• Script down obbligatori; Stima dei tempi e dei blocchi.
• Shadow-letture: confronto dei risultati del vecchio/nuovo percorso (senza effetti collaterali).
• Criteri di annullamento contract: qualsiasi guardrail «rosso».

12) Processi e RACI

Release Manager è il proprietario della catena di montaggio e delle regole.
Servizio Owner: approva regole di dominio, accetta rischi.
La SRE realizza rilevatori, meccaniche di ritocco, dashboard.
Sicurezza/Compliance: SoD, controllo PII/RG, controllo.
On-call IC/CL - Comunicazioni, stato-pagina.
CAV: panoramica post-fattura dei rimborsi automatici, regolazione delle regole.

13) Funzioni KPI/KRI

Auto-Rollback Rate - Percentuale di rilascio automatico (bassa ma non zero).
Time-to-Rollback: detekt→otkat (mediana/p95).
SLO-Breach Avoided - Casi in cui il rientro automatico ha impedito la violazione degli obiettivi.
False Positive - Percentuale di rimborsi «falsi» (obiettivo ↓).
CFR prima/dopo l'implementazione dell'autotrasporto.
Cost of Rollbacks: tempo supplementare, canarini, risorse informatiche.
Audit Completeness:% degli eventi con timeline e diffusioni complete.

14) Road map di implementazione (6-10 settimane)

Ned. 1-2: catalogo delle metriche critiche e delle soglie di base Selezionare le strategie (canary/blue-green/flags) Inventario della reversibilità delle migrazioni.
Ned. 3-4: implementazione di rilevatori e policy-engine; integrazione con l'incidente-bot; GitOps-rollback per configure; I dashboard dei Guardrails.
Ned. 5-6 - Pilota sul dominio Payments (auth-success, PSP-Routing), allenamento tabletop; registro WORM e report.
Ned. 7-8: espansione su Games/KYC; Pausa automatica dei flag Esercitazioni DR con blue-green.
Ned. 9-10: calibrazione delle soglie, riduzione false positive, valutazione dei costi FinOps, formalizzazione di RACI e apprendimento.

15) Antipattern

«Ripieghiamo in qualche modo», la mancanza di un piano e di una reversibilità delle migrazioni.
Attivazione/disattivazione immediata globale senza gradini.
Ripristina le metriche crude senza contesto (nessuna stratificazione GEO/PSP/BIN).
Ignorare SRM e peeking negli esperimenti.
La release-alert senza isteresi, il flapping dei rimborsi.
Modifica manuale dei configli in vendita senza Git/Auditel.
Rimuove il vecchio schema prima di passare la finestra di sorveglianza.

Totale

Reimpostazione automatica delle release è una griglia di protezione della piattaforma: regole come codice, segnali e soglie corrette, soluzioni architettoniche reversibili (canary/blue-green/flags/reversibili migrations), comunicazioni integrate e un controllo completo. Questo tracciato riduce drasticamente il rischio di rilascio, protegge SLO e ricavi e migliora la fiducia di regolatori e partner.