SLA, SLO e KPI affidabilità

1) Termini e differenze

SLI (Service Level Indicator) - Indicatore di qualità misurato (ad esempio, percentuale di query di successo, p95 latitanza).
SLO (Service Level Objective) - Destinazione SLI per la finestra del tempo (ad esempio «successo» 99. 9% in 28 giorni").
Errore di bilancio - Percentuale di inattività SLO valida: '1 - SLO'.
SLA (Service Level Agreement) - Obblighi contrattuali con multe/crediti (esterni).
KPI di affidabilità - metriche operative del processo (MTTD/MTTA/MTTR/MTBF,% mitigate automatiche, rivestimento alert, ecc.).

2) Come scegliere SLI (basato su Golden Signals)

1. Latency è p95/p99 per endpoint chiave.
2. Traffic - RPS/RPM/flusso di messaggi.
3. Errors è una quota di errori di 5xx/business (ad esempio, i pagamenti «decline per colpa di PSP» da escludere).
4. Saturation - saturazione delle risorse (CPU/RAM/IO/lag).

• Correlazione con l'esperienza utente (user-perceived).
• Tecnicamente disponibile e stabile nella misura.
• Controllo (possibili azioni di miglioramento).
• Basso costo della raccolta.

3) Formule e esempi

3. 1 Disponibilità (availability)

Availability = Успешные запросы / Все запросы
Error Budget (за период) = 1 − SLO

Esempio: SLO 99. Il 9% in 30 giorni ha calcolato il bilancio degli errori = 0. 1%, pari a 43 min 12 secondi di indisponibilità.

3. 2 Latitanza

Latency SLI = доля запросов с duration ≤ T
SLO пример: 99% запросов ≤ 300 мс (rolling 28d)

3. 3 Pagamenti (livello aziendale)

Payment Success SLI = (успешные проводки — внешние отказы PSP) / все попытки

4) Budget errato e burn-rate

L'errore di bilancio è il vostro serbatoio per l'innovazione (rilasci, esperimenti).

• Canale rapido (Dettaglio di} 1 h),
• canale lento (trend 6-12 ore/24 ore).

• Se il burn-rate> 14. 4 in un'ora e mezza - 1-1 (mangi il budget giornaliero per 100 minuti).
• Se burn-rate> 6 in 6 ore - SEC-2 (degrado rapido).

5) Alerting SLO (multi-window, multi-burn)

Indicatore di errore: 5xx o interruzioni di latenza.

promql
Доля ошибок за 5 минут sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Быстрый burn (1m окно)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14.4

Медленный burn (30m окно)
(
sum(rate(http_requests_total{status=~"5.."}[30m])) /
sum(rate(http_requests_total[30m]))
) / (1 - SLO) > 2

promql p95 latency histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6) Esempi di SLI/SLO per dominio

6. 1 gateway API/Edge

SLI-Errors: percentuale di risposte 5xx <0. 1% (28d).
SLI-Latency: p95 da 250 ms (giorno).
SLO: Availability ≥ 99. 95% (trimestre).

6. 2 Pagamenti

SLI-Success: un sovraccarico di successo (esclusi i guasti client) di 99. 8% (28d).
SLI-Latency: autorizzazione di 2 secondi per 99% (giorno).
SLO: Time-to-Wallet p95 ≤ 3 мин (24h).

6. 3 Database (PostgreSQL)

SLI-Lag: lega di replica p95 ≤ 1 secondi (giorno).
SLI-Errors: percentuale di errori di richiesta 0. 05% (28d).
Disponibilità del cluster ≥ 99. 95%.

6. 4 Code/Streaming (Kafka)

SLI-Lag: gruppo di consumatori p95 ≤ N messaggi (ore).
SLI-Durability: conferma della registrazione del ≥ 99. 99% (28d).
La disponibilità dei broker è di 99. 9%.

7) Processo di affidabilità KPI

MTTD (Mean Time To Detect)

MTTA (… To Acknowledge)

MTTR (… To Restore)

MTBF (… Between Failures)

% degli incidenti con mitigazione automatica

Copertura SLO/alert delle vie di traffico top (obiettivo 95%)

Percentuale di release in fase canaresca

Consumo di budget non valido per comando/file

8) Come mettere SLO realistico

1. Misurare l'affidabilità di base corrente (3-4 settimane).
2. Definire percorsi personalizzati sensibili (login, deposito, gioco).
3. Tenere conto del costo di ogni deviazione (tempo, denaro, reputazione).
4. Scegliere un obiettivo ambizioso ma realizzabile (un miglioramento del 10-30% verso la base).
5. Rivedete trimestralmente.

• Non c'è alcuna giustificazione.
• SLO per metriche non visibili all'utente (ad esempio CPU senza collegamento UX).
• Troppo SLO per spruzzare il trucco.

9) Report SLO e budget

• Esecuzione per ogni SLO: vs obiettivo, trend, confidence.
• Riepilogo del consumo di errori: quanti budget sono bruciati e chi (comunicato/incidente).
• Le prime cinque cause di degrado, il piano CAPA e lo stato delle attività.
• Impatto sul business: conversione, ND, trattenimento, LTV.

10) Relazione con la politica di lancio

Budget degli errori <50% di rilascio libero.
50-80% «Modalità attenta»: solo low-risk/canarini.

11) SLA - modelli di punti

Obbligo di disponibilità, ad esempio 99. 9 %/mese.
Eccezioni (Force Majeure) - Fuori controllo ragionevole, provider terzi.
La finestra di misurazione e la zona di responsabilità sono le origini delle metriche, il metodo di calcolo.
Crediti/multe: tabella dei livelli (ad esempio, non disponibile 60-120 min, credito X%).
Procedure di accelerazione e notifica: tempi, canali.
Dati e privacy: occultamento, conservazione, legale hold.
Piano di prevenzione delle ripetizioni (CAPA) in caso di violazione.

12) Strumenti di misurazione

Metriche passive: Prometheus/Mimir/Thanos, esportatori.
Loghi: Loki/ELK per il conteggio dei successi/errori a livello aziendale.
Sintetico: provini attivi (login/deposito/gioco) per cron.
Traccia: Tempo/Jaeger per «colli di bottiglia» p99.
Pagamento/finanza: fonti di ground truth per SLI di pagamento.

13) Esempi di query (modelli)

promql
1 - (
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
)

yaml slo:
name: "API Availability"
window: "28d"
target: 0.999 sli: "1 - 5xx%"
owner: "Platform SRE"
alerting:
fast_burn: {window: "1h", factor: 14.4}
slow_burn: {window: "6h", factor: 6}

success_rate = (count_over_time({app="payments"}     = "status=success"[5m]))
/ (count_over_time({app="payments"}     ~ "status=(success    fail)"[5m]))

14) FinOps e affidabilità

Cost per 9: il costo dell'aggiunta del nove aumenta esponenzialmente.
La curva dei benefici è ottimale dove l'aumento del fatturato o la riduzione delle perdite è il valore di «9» in più.
Portafoglio SLO: diversi livelli per percorsi diversi (pagamenti critici «più costosi», rapporti più economici).

15) Qualità SLO/alert - assegno-foglio

• SLI è correlato a UX e metriche aziendali.
• Finestra e aggregazione concordati (rolling 28d/trimestre).
• Alert multi-window, senza flapping, con routing di ruolo.
• Documentazione: proprietario, formula, fonti, runbook.
• Dashboard SLO con budget e indicatori burn errati.
• Revisione regolare degli obiettivi (trimestrale).
• Test sintetici su scenari chiave.

16) Piano di implementazione (4 iterazioni)

1. Settimana 1: inventario dei percorsi personalizzati, bozze SLI, dashboard base.
2. Settimana 2 - formalizzazione SLO, calcolo budget, alert (fast/slow burn).
3. Settimana 3: integrazione con il processo di incidenti/rilascio, regole freeze.
4. Settimana 4 +: SLA contrattuali, gelosia trimestrale, finops «cost per 9».

17) Mini FAQ

È necessario avere un SLO per il servizio?
Meglio 2-3 chiave (successo + latitanza) invece di decine secondarie.

E se il budget fosse esaurito?
Congelamento dei rilasci, fuoco sulla stabilizzazione e CAPA, rimozione di fiffe sperimentali.

Come evitare un conflitto tra velocità di rilascio e affidabilità?
Pianificare le release «budget», implementare le pagine canarie e le feature-flags.

Totale

L'affidabilità non è gestita da un insieme di metriche separate, ma da un sistema: SLI-SLO: un errore di budget del burn-alerting, un processo di incidenti del CAPO-SLA. Standardizzare le definizioni, le fonti di dati e i report, collegare gli obiettivi all'esperienza e all'economia degli utenti e rivedere regolarmente il livello di «device» in base al RE reale.