SLI vs SLO vs SLA: differenze e come impostarli

In breve: SLI è cosa misuri, SLO è che obiettivo vuoi raggiungere, SLA è l'impegno contrattuale. Questi termini dal libro Google SRE sono tra le frasi più usate nell'esercizio di servizi web - e spesso confuse.

In breve: SLI è cosa misuri, SLO è che obiettivo vuoi raggiungere, SLA è l'impegno contrattuale. Questi termini dal libro Google SRE sono tra le frasi più usate nell'esercizio di servizi web - e spesso confuse.

SLI - Service Level Indicator

Metrica concreta con cui quantifichi l'affidabilità del servizio. Esempi:

% di richieste che si sono concluse in HTTP 2xx o 3xx negli ultimi 30 giorni
% di richieste con response time sotto 500 ms
% di email consegnate correttamente (delivered, non bounced)
Rapporto di transazioni di pagamento riuscite su tutti i tentativi

Proprietà chiave di un buon SLI:

Misurabile - esiste un metodo concreto di raccolta dati
Rilevante per l'utente - riflette l'esperienza reale del cliente, non una metrica tecnica interna
Specifico - "uptime" è troppo vago; "% di richieste riuscite a /api/v1/orders in finestra di 5 minuti" è un SLI

SLO - Service Level Objective

Obiettivo interno, che valore deve raggiungere lo SLI. Espresso in percentuale su finestra temporale.

Esempi:

"99,9 % delle richieste a /api/orders devono concludersi in HTTP 2xx in 30 giorni"
"95 % delle richieste deve avere response time sotto 200 ms in 7 giorni"
"99,5 % delle transazioni di pagamento passano con successo in mese calendario"

SLO è più alto di SLA per avere buffer. Se SLA dice 99,9 %, lo SLO interno dovrebbe essere ad es. 99,95 % - per avere riserva per incidenti inattesi.

SLA - Service Level Agreement

Impegno contrattuale verso i clienti. Definisce cosa succede quando non rispetti lo SLO - tipicamente:

Service credits - restituisci parte del canone mensile (10-50% in base alla grandezza della violazione)
Termination rights - il cliente può risolvere il contratto senza sanzione
Obbligo di reporting - devi pubblicare postmortem e report uptime

SLA ha conseguenze legali. SLO è obiettivo interno.

Error budget

Concetto chiave dell'SRE: il downtime che puoi permetterti senza violare lo SLO.

Esempio: SLO = 99,9 % uptime in 30 giorni. Sono 0,1 % di downtime ammesso. 0,1 % di 30 giorni = 43 minuti al mese. Questo è il tuo error budget.

Implicazioni pratiche:

Se hai già 35 min di downtime nel mese, restano 8 min alla "violazione dello SLO". Il team dovrebbe essere conservativo nei prossimi deploy.
Se hai 5 min di downtime, hai 38 min di budget per rischi - puoi fare cambi più aggressivi, A/B test, esperimenti.
Error budget risolve il conflitto tra velocità d'innovazione (dev team) e stabilità (ops team). Entrambi seguono lo stesso numero.

Esempio pratico: API e-commerce

SLI: % di richieste HTTP a POST /api/checkout che si sono concluse in 2xx, misurate in bucket di 1 minuto negli ultimi 30 giorni.

SLO: ≥ 99,9 % di richieste riuscite in finestra rolling 30-day.

SLA (per clienti Enterprise):

≥ 99,5 % uptime in mese calendario
A 99,0-99,5 % = 10% credit del canone mensile
A 95,0-99,0 % = 25% credit
A < 95,0 % = 50% credit + diritto di risolvere il contratto

Error budget: 99,9 % SLO significa 43 min downtime / mese di budget. SLA dà ancora un buffer maggiore prima della penalizzazione economica.

Sintesi: tabella

Termine	Cos'è	Per chi
SLI	Metrica concreta di affidabilità	Team engineering
SLO	Obiettivo interno per SLI	Engineering + product
SLA	Impegno contrattuale	Cliente + legal
Error budget	Downtime che puoi permetterti prima della violazione dello SLO	Engineering risk management

Errori pratici

SLO troppo ambizioso. 99,99 % richiede active-active redundancy in più regioni. Irrealistico per piccola azienda.
Solo uptime SLO. Il web può essere "up" e comunque inutilizzabile. Aggiungi latency SLO e error rate SLO.
SLA senza misurazione automatica. Un report SLA calcolato manualmente non è affidabile. Investi in uptime tracking automatizzato.
SLO senza conseguenze. Se a nessuno interessa la violazione dello SLO, nessuno se ne preoccupa. Collega a deploy freeze, on-call escalation, ecc.

Conclusione

Il framework SLI/SLO/SLA non è burocrazia cartacea - è il linguaggio con cui il team engineering comunica con business stakeholders sull'affidabilità. Senza questi termini la discussione sulla stabilità diventa soggettiva ("il nostro web è instabile"). Con essi è numerica ("negli ultimi 30 giorni abbiamo raggiunto 99,87 % SLI, che è sotto il nostro 99,9 % SLO - ecco il piano d'azione").

Misura SLI in tempo reale

ePulz.io fornisce registrazione storica di uptime con rollup 30/90/365 giorni. Base per il reporting SLO.

Avvia monitoraggio →