Correzione automatica degli errori

1) Scopo e principi

Obiettivo: ridurre l'MTTR e prevenire l'escalation degli incidenti mantenendo SLO, ricavi e conformità.

• SLO-first: le attività automatiche sono autorizzate solo in caso di errori di bilancio confermati.
• Sicurezza in primo luogo: blast-radius minimo, limiti evidenti e timbox.
• Esplainable by design: ogni azione è spiegabile e audibile.
• Preparazione Rollback: ogni passo è accompagnato da criteri di ritorno.
• Human-in-the-loop dove il rischio è elevato: modifiche P1-Critical - tramite controllo dual o conferma IC/coll (a meno che non sia impostato da altro criterio).

2) Termini

Auto-remediation - Risposta programmatica all'evento (alert/anomalia) senza coinvolgimento umano.
Garrails: criterio di restrizione (soglia, durata, numero di tentativi, area di esposizione).
Runbook-Action - Operazione atomatica con pre/post-test e recupero.
Decection Engine è un servizio che associa l'evento alle regole e avvia le azioni.

3) Architettura della soluzione

1. I segnali sono SLO/burn-rate, KRI, sintetico, RUM, deep-health.
2. Correlazione del contesto: release, ficchflags, operazioni pianificate, provider dipendenti.
3. Decision Engine: regole/regole (policy-as-code), valutazione dell'impatto e del rischio, scelta dello script.
4. Esecuzione: orchestratore di azioni runbook (idampotenza, retrai con jitter).
5. Controllo: pre-validatori, post-verificatori, timbox, ritorno.
6. Controllo e osservabilità: attività trade, metriche di successo, registro (WORM/immutable).
7. Comunicazione: una pagina di stato (tramite Comms Lead), una barra, una macro per lo zapport.

4) Criteri e tolleranze (policy-as-code)

• `allow if burn_rate(payments. auth) > fast && impact>threshold && psp_alt. healthy && within_limits("psp_reroute")`

• `allow if p99(bet_settlement)>3x && queue_lag>limit && feature("replay_center"). enabled`

• `allow if consumer_lag>target && cost_budget. ok && region_capacity. available`

• `allow if export_spike && no_ticket && data_class=PII -> action=block + notify(Compliance)`

Ogni criterio contiene condizione, azione, limite (scope/tempo/frequenza), criteri di successo, ripristino.

5) Catalogo di azioni sicure (runbook-action atomiche)

Pagamenti: passare al traffico alternativo PSP/banca; Cambiare le priorità di routing health x fee x conversion; Abilitare 3DS semplificato aumentare i limiti dei retrai con jitter.
Scommesse/giochi: ridimensiona i worker settle; Abilitare cache-warmup; disattivare temporaneamente le fitte non ritiche (animazioni, fidi secondari) abilitare waiting-room/queue-page.
Infrastruttura: rimuovere gli esemplari degradati (outlier-detector), evacuare il traffico verso la zona adiacente AZ/regione; Aumentare il pool/quote riavviare i worker con controlli lint.
Dati/code: ridistribuire le partenze; Aumentare i consumatori a cap; Passare il traffico read a una replica sana attivare il sempreverde adattivo delle piste.
Sicurezza/compilazione: blocca temporaneamente l'esportazione di PII senza ticket; Rafforzare i limiti velocity delle conclusioni abilitare il dual control sulle operazioni sensibili.
Livello comm: bozza di stato automatica + slot di update per Comms Lead; notifica ai partner in caso di degrado PSP.

6) Pre e post-validazione

• Verificare che il problema è reale e fresco (N-da-M finestre; nessun silence/lavoro programmato).
• Assicurarsi che l'azione sia consentita da un criterio e che il budget delle risorse sia disponibile.
• Stima del costo (FinOps) e dei vincoli di compilazione.

• Conferma riduzione burn-rate/metriche; Scrivere il risultato; pianificare la restituzione (auto-rollback) secondo i termini.

7) Rollback и “escape hatch”

Ritorno automatico durante la stabilizzazione delle metriche e attraverso azioni max-TTL.
Pulsante di ripristino per l'IC/on-call nella barra.
Break-glass solo per l'accesso di emergenza obbligatorio il post-controllo.

8) Integrazione con alerting e incidenti

Ogni azione auto viene collegata alla scheda dell'incidente: chi/cosa/quando/perché, il risultato, i collegamenti alla grafica.
Il cercapersone è abbassato per i duplicati, ma non per i blocchi auto falliti (escalation).
La pagina di stato viene aggiornata tramite Comms Lead per modello.

9) Design della sicurezza e della compilazione

Privilegi minori per un orchestratore; singoli ruoli per attività/dominio.
SoD e dual control per high-risk: routing PSP, bonus limite, esportazione PII.
Controllo WORM/immutabile di tutte le soluzioni automatiche, inclusi i segnali di input e le versioni delle regole.
L'igiene PII è priva di ID personali nelle etichette e nei fogli di azione.

10) Osservabilità dei circuiti auto

Metriche: azioni success-rate, tempi di reazione,% di rimborsi, risparmio MTTR, impatto SLO.
Trace: trace passanti per «segnale, soluzione, azione, effetto».
Loghi: strutturati, con policy _ id, versioni e pre/post-test.
Dashboard: Exec (impatto sul fatturato/SLO), Ops (matrice di azione x domini), FinOps (costo delle misure auto).

11) Esempi di script (iGaming)

11. 1 degrado PSP (TR/EU)

Segnale: auth-success PSP-1 è ↓ al 25% in 10 minuti, copertura> 30% transazioni.
Azioni: ridistribuire il 40% del traffico a PSP-2/3; Abilitare 3DS semplificato sollevare i retrai delle richieste di banca X con jitter.
Limite: non più del 60% del traffico totale per PSP alternativo; TTL 45 min.
Rollback: al momento della normalizzazione di success-rate, il target viene ≥ entro 15 minuti.

11. 2 Aumento p99 per le puntate settle

Segnale: p99 «bet→settle»> 3 x norma + consumer-lag> soglia.
Azioni scale-out dei worker fino al cap; riscaldamento della cache dei coefficienti spegnere temporaneamente la cronologia delle ripetizioni.

Rollback: dopo headroom> X e p99 nella norma di 20 minuti

11. 3 Replica database in ritardo

Segnale: replication-lag> N secondi, altezza lock-wait.
Azioni: spostare il traffico read in una replica sana; Abilitare operazioni write throttling di bassa priorità.
Rollback: dopo la normalizzazione e gli errori di blocco.

11. 4 Spike export PII

Segnale: rate di esportazione> linea base x K, nessun ticket.
Azioni: unità di esportazione, notifica Compliance, attivazione dual control.
Rollback: dopo la conferma delle richieste e la chiusura dell'anomalia.

12) KPI и KRI

MTTR↓ per gli incidenti in cui l'auto-fix ha funzionato.
TTD→Action: tempo dal dettaglio all'esecuzione dell'azione.
Success-rate azioni e Rollback-rate (basso - bene se non a causa di falsi funzionamenti).
False-action rate (azioni senza effetto o con effetti negativi).
SLO impatto saved (minuti/fatturato, multe evitate).
Pager fatigue↓ (meno cercapersone manuali con gli stessi/migliori SLO).

13) Road map di implementazione (8-12 settimane)

Ned. 1-2 - Seleziona 3-5 script RE (PSP-feelover, autoscale per lag, feature-degrade) descrivere criteri/limiti/rimborsi.
Ned. 3-4: implementare l'orchestrazione, i segreti e i ruoli, l'integrazione con la piattaforma d'incidente; aggiungere osservazione e verifica.
Ned. 5-6: pilota in modalità shadow (simulate-only) → A/B-valutazione degli effetti; quindi includerlo in un proto con poca copertura.
Ned. 7-8 - Estendere la directory degli script (database/cache/code/fronte), associare alla pagina di stato e a Comms.
Ned. 9-10 - Aggiungere le regole dei limiti FinOps (costo/SLI), implementare il dual control per l'high-risk.
Ned. 11-12: tabletop/chaos-esercitazioni, revisione KPI/KRI, pubblicazione di haydline e formazione on-call.

14) Manufatti e modelli

Auto-Remediation Policy: condizione, azione, limiti, TTL, ripristino, proprietario, classe di rischio.
Runbook-Action Spec: preimpostazione, passo, convalida, errore, monitoraggio, logica di ripristino.
Cambio-Control: chi può modificare i criteri, la RV, i test, il diff e la versione.
Evidence Pack: loghi/trailer/metriche di esposizione a SLO, report post mortem/controllo.

15) Antipattern

«Curiamo il sintomo» senza controllare la causa e il flapping SLO.
Azioni senza ritorno e TTL bloccano il degrado.
Script universali senza guardrails, guasti a cascata.
Nessun controllo o versioning dei criteri.
Ignora il costo (scale automatico senza limite) e la compilazione (esportatori PII).
Autonomia completa senza Human-in-the-loop nei rischi P1.

Totale

La correzione automatica degli errori è un tracciato controllato: i segnali SLO di una politica con guardrails consentono di eseguire attività runbook sicure con disattivazione, osservazione e verifica degli incidenti. Questo approccio riduce misurabilmente MTTR, mantiene il fatturato nei picchi e rimuove la routine dalla colla, mantenendo la conformità ai requisiti di sicurezza e ai regolatori.