Errore Budget e controllo SLO

1) Perché SLO e bilancio degli errori

SLO è un target di qualità percepito dall'utente. SLI - metrica misurabile; Errore Budget - Autorizzazione alle deviazioni per finestra (solitamente 30/90 giorni).
Il bilancio degli errori trasforma l'affidabilità da «astrazione» in una risorsa gestita: quando il budget brucia rapidamente, congeliamo le feci e i chinim; Quando il budget è sano, si possono accelerare i comunicati.

2) Scelta SLI cosa considerare «buono»

Criterio «riuscito dal punto di vista dell'utente».

2. 1 Classici SLI

Availability: percentuale di richieste di successo (escluse quelle annullate dal cliente).
'success = http _ status' {2xx, 3xx, 404} e senza timeout '(404 può essere considerato un successo per l'API read se si tratta di una semantica prevista).
Latency: percentuale di query più veloce della soglia (ad esempio p95-300 ms).
`good_latency = duration_ms ≤ 300`.
Freshness/Staleness: «dati non superiori a X minuti» (cache, directory, coefficienti).
Quality: correttezza del risultato (passaggio di validatori aziendali/backend invarianti).

2. 2 Bordi e segmenti

La SLI deve essere considerata in base a tagli importanti: «route», «tenant/brand», «region/jurisdiction», «payment _ provider». Così non si smuove un guasto ad una maniglia critica su tutto il sistema.

3) Formule e budget

3. 1 Ricorest-based (preferibilmente API)

SLO_availability = good_requests / total_requests
Error_budget = 1 - SLO_target
Burn = 1 - SLO_actual

3. 2 Time-based (per servizi/streaming in sottofondo)

SLO_uptime = good_minutes / total_minutes

3. 3 Esempio di obiettivi

API comuni: 99. 9% di disponibilità in 30 giorni, budget = 0. 1%.
Maniglie critiche: 99. 95%; directory/ricerca: 99. 5%.
Latenza: p95-300 ms su/v1/payments, p99-800 mc.

4) Strumenti SLI

4. 1 Principi

Loghi/trailer RED (Rate/Errors/Duration) con buckets evidenti.
Assicurati di fare «tenant», «region», «route _ class» (senza PII).
Considerate le due metriche: «successo» e «tutto», e per latency «veloce» e «tutto».

4. 2 Esempio Prometheus (rate per 5m)

promql
Availability (successes/total)
sli:success:rate5m = sum by(region, route)(
rate(http_requests_total{code=~"2..    3.."}[5m])
)
sli:total:rate5m = sum by(region, route)(
rate(http_requests_total[5m])
)
sli:availability:ratio5m = sli:success:rate5m / sli:total:rate5m

Latency (fraction faster than 300 ms)
sli:fast:rate5m = sum by(region, route)(
rate(http_request_duration_seconds_bucket{le="0. 3"}[5m])
)
sli:latency_ok:ratio5m = sli:fast:rate5m / sli:total:rate5m

5) Alert per burn rate (multi-window, multi-burn)

5. 1 Idea

Vediamo a che velocità brucia il budget rispetto all'obiettivo. Se la velocità è alta su una finestra corta e lunga, è un segnale.

5. 2 Profili soglia (per SLO 99. 9%)

Cercing burn rate 14. 4 x (10% del budget in un'ora e 5% in 6 ore).
Ticket: burn rate 6 x (2% in 6 ore e 1% in 24 ore).

5. 3 Esempio di regole (Prometheus, pseudo)

promql
Let's calculate the error_ratio on two windows short = 1 - (sum (rate (http_requests_total{code=~"2..    3.."}[5m])) /
sum(rate(http_requests_total[5m])))
long = 1 - (sum(rate(http_requests_total{code=~"2..    3.."}[1h])) /
sum(rate(http_requests_total[1h])))

For SLO = 99. 9%, error_budget=0. 001. BurnRate = error_ratio / 0. 001 burn_short = short / 0. 001 burn_long = long / 0. 001

Paging: Both windows exceed 14. 4× alert: SLOErrorBudgetBurnRateHigh expr: burn_short > 14. 4 and burn_long > 14. 4 for: 5m labels: { severity="page" }
annotations:
summary: "SLO burn rate high (short & long windows)"
runbook: "slo/runbooks/payments. md"

Simile a 6h/24h per il ticket.

6) Gestione del bilancio: processi

6. 1 Gate di lancio

Se il saldo del budget <25% e il trend negativo è «codice-congelamento» per i fili, la priorità è SRE/sostenibilità.
Le release canarie devono avere un taglio SLO separato ('deployment. environment="canary"`).

6. 2 Priorità beclog

Distribuire la capacità del comando in proporzione alla velocità di combustione e all'impatto sul fatturato.
Giustifica il debito tecnico con le metriche: «Il fix X ridurrà il burn rate di Y%».

6. 3 Post-incidente

Ogni incidente è un RCA e un'fix che non può essere rimosso ".

7) SLO come codice

7. 1 Esempio di manifesto SLO (YAML)

yaml service: payments-api owner: team-payments slis:
- name: availability type: request_based success_query: sum(rate(http_requests_total{svc="pay",code=~"2..    3.."}[5m]))
total_query:  sum(rate(http_requests_total{svc="pay"}[5m]))
objective: 99. 95 window: 30d segments: ["region", "tenant", "route"]
- name: latency_p95_300ms type: latency_threshold good_query: sum(rate(http_request_duration_seconds_bucket{svc="pay",le="0. 3"}[5m]))
total_query: sum(rate(http_request_duration_seconds_count{svc="pay"}[5m]))
objective: 99. 0 window: 30d alerts:
- name: burn_high_page windows: ["5m", "1h"]
threshold_burn: 14. 4 severity: page

7. 2 Generazione di regole

Utilizzare i generatori (slo-generator, pyrra, sloth) per creare automaticamente regole, dashboard e report.

8) Degrado e protezione SLO

Load shedder: dare risposte rapide senza dipendenze «costose» al picco.
Cache & stale: `stale-while-revalidate` для read.
Rate/Concertency limits - protegge i backend; i percorsi importanti sono la priorità.
Circuito/Timeout - Timeout veloci e rami «fallback».
Feature flags - Disattiva i filetti pesanti con un solo pulsante.

9) Osservabilità per SLO

Dashboard: SLO actual vs target, bilancio residuo, burn rate, contributi percorsi/provider.
Correlazione: dal "buco" dello SLO "all' ar, un particolare trace di logi/profili.
Report: trend settimanale, consumo di budget, cause top degrado.

10) Antipattern

Uno SLO globale per tutto il mondo maschera i problemi. Segmentate.
«99. 99% su tutto" senza contare costi e realtà. Selezionare gli obiettivi dall'esperienza utente.
Alert per CPU/heap invece di burn rate/SLO.
Ignorare i reading 4xx/lunghi che rovinano UX.
Finestra opaca (rollvs calendario) - Confronta mele con arance.

11) Specificità iGaming/finanza

I percorsi di denaro (depositi/conclusioni) sono singoli SLO al di sopra del livello generale (ad esempio, 99. 95% di disponibilità p95 ≤ 250 ms).
Provider PSP/KYC: SLO per ogni provider + alert per il loro contributo al burn; commutazione automatica delle rotte (smart routing).
Giurisdizioni/tenenti: SLO e budget per «region/giurisdiction/brand», in modo che il problema locale non «riempia» la metrica globale.
Gioco responsabile: SLO durante l'applicazione dei limiti/auto-esclusione (formula compliance).
Controllo/regolazione: conserva i rapporti SLO e gli incidenti; trasparenza per le revisioni interne.

12) Assegno-foglio prod-pronto

• Definiti SLIs (availability/latency/quality/freshness) e segmenti (route/tenant/region).
• Gli obiettivi (SLO) sono realistici, coerenti con il business; Ci sono le finestre rolling 30/90 giorni.
• Alert per burn rate con multi-finestre (paging/ticket).
• SLO come codice (generatore di regole/dashboard); I resoconti del bilancio.
• Gate di lancio allineati al resto del budget; i tagli canarini.
• I meccanismi di degrado (shedder, cache stale, circuito, limiti) sono stati implementati e testati.
• La correlazione tra metriche di trailer (exemplars), runbooks chiari.
• Percorsi finanziari/giurisdizionali - SLO/alert separati; PSP/KYC disattivati.
• Regolare retromarcia per incidenti e investimenti in affidabilità basati sul burn.

13) TL; DR

Definire la SLI in base al valore utente, impostare un SLO realistico, e controllare attraverso l'Errante Budget e il burn rate con le finestre multi. Attivare codice SLO-come, gate di lancio e degrado previsto. Segmentare per percorsi/tenenti/regioni; per le vie del denaro, mantenere obiettivi più rigidi e alert separati.