SLI vs SLO vs SLA: differenze e come impostarli

Lo SLI e cio che misuri, lo SLO il tuo obiettivo, lo SLA l'impegno contrattuale. I tre concetti del Google SRE piu spesso confusi, spiegati.

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 tempo di risposta sotto 500 ms
% di email consegnate correttamente (delivered, non bounced)
Rapporto tra transazioni di pagamento riuscite e tutti i tentativi

Un buon SLI ha tre proprietà chiave:

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 una finestra di 5 minuti" è un SLI

SLO - Service Level Objective

Obiettivo interno che definisce quale valore deve raggiungere lo SLI. Espresso in percentuale su una finestra temporale scelta.

Esempi:

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

Lo SLO è di solito più rigoroso dello SLA, così da avere un margine. Se lo SLA dice 99,9 %, lo SLO interno dovrebbe essere ad es. 99,95 % - così ti resta riserva per incidenti inattesi prima di violare il contratto.

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

Lo SLA ha conseguenze legali. Lo SLO, invece, è solo un 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, e 0,1 % di 30 giorni sono 43 minuti al mese. Questo è il tuo error budget.

Implicazioni pratiche:

Se hai già consumato 35 min di downtime nel mese, restano 8 min alla violazione dello SLO. Il team dovrebbe essere conservativo nei prossimi deploy.
Se hai consumato solo 5 min di downtime, hai 38 min di budget per il rischio - puoi permetterti cambi più aggressivi, A/B test ed esperimenti.
L'error budget risolve così il conflitto tra velocità d'innovazione (dev team) e stabilità (ops team). Entrambe le parti 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 un 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: uno SLO del 99,9 % significa 43 min di downtime al mese. Lo SLA dà un margine ancora maggiore prima di qualsiasi 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

Uno SLO troppo ambizioso. 99,99 % richiede active-active redundancy in più regioni. Irrealistico per una piccola azienda.
Solo uno uptime SLO. Il web può essere "up" e comunque inutilizzabile. Aggiungi un latency SLO e un error rate SLO.
Uno SLA senza misurazione automatica. Un report SLA calcolato manualmente non è affidabile. Investi in uptime tracking automatizzato.
Uno SLO senza conseguenze. Se a nessuno interessa la violazione di uno SLO, nessuno lo prende sul serio. Collegalo 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 i 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 una registrazione storica di uptime con rollup 30/90/365 giorni. Una base solida per il reporting SLO.

Avvia monitoraggio →