«Il servizio deve essere sempre disponibile» è una frase che si sente spesso e che non aiuta nessuno. Non dice cosa significa «disponibile», non indica come misurarlo e, soprattutto, chiede qualcosa di impossibile. Gli SLI, gli SLO e l'error budget sono un modo per trasformare quella frase in numeri concreti, discussi tra chi sviluppa, chi gestisce l'infrastruttura e chi decide le priorità.
Tre sigle, tre livelli
- SLI (Service Level Indicator): la misura. Per esempio, la percentuale di richieste che ricevono una risposta corretta in meno di 300 millisecondi.
- SLO (Service Level Objective): l'obiettivo interno su quella misura. Per esempio, il 99,5 per cento delle richieste in un periodo di 30 giorni.
- SLA (Service Level Agreement): l'impegno contrattuale verso un cliente, con conseguenze economiche se non viene rispettato.
Lo SLA è di solito meno ambizioso dello SLO. Se ti impegni con i clienti al 99 per cento, conviene che il tuo obiettivo interno sia più alto, così da accorgerti dei problemi prima di violare il contratto.
Scegliere buoni indicatori
Un buon SLI riflette l'esperienza dell'utente, non lo stato interno delle macchine. Un server con la CPU al 90 per cento non è un problema se gli utenti ricevono risposte rapide; un server con la CPU al 10 per cento lo è se restituisce errori.
Gli indicatori più comuni sono:
| Tipo di servizio | SLI tipico |
|---|---|
| API o sito web | Percentuale di richieste riuscite; percentuale di richieste sotto una certa latenza |
| Elaborazione in background | Percentuale di lavori completati entro un certo tempo |
| Archiviazione dati | Percentuale di letture che restituiscono il dato corretto |
| Pipeline di dati | Freschezza: quanto sono recenti i dati disponibili |
Conviene esprimere l'SLI come rapporto tra eventi buoni ed eventi totali. Così diventa naturale ragionare in percentuali e confrontare periodi diversi. Dove misurarlo conta: i dati del bilanciatore di carico sono più vicini all'esperienza dell'utente di quelli del singolo server.
Perché il cento per cento è l'obiettivo sbagliato
Puntare al cento per cento di disponibilità sembra la scelta più responsabile, ma ha tre difetti.
- È irraggiungibile: reti, fornitori, aggiornamenti e guasti hardware garantiscono che prima o poi qualcosa si fermi.
- È costosissimo: ogni «nove» in più richiede ridondanza, automazione e personale in proporzione crescente.
- Blocca il cambiamento: se nessun errore è tollerato, ogni rilascio diventa un rischio inaccettabile e lo sviluppo rallenta.
Inoltre l'utente non percepisce la differenza oltre un certo livello, perché la sua stessa connessione, il suo dispositivo e la sua rete domestica sono meno affidabili del servizio.
Per orientarsi, ecco quanto tempo di indisponibilità corrisponde ad alcuni obiettivi su un periodo di 30 giorni:
| SLO | Indisponibilità consentita in 30 giorni |
|---|---|
| 99% | Circa 7 ore e 12 minuti |
| 99,5% | Circa 3 ore e 36 minuti |
| 99,9% | Circa 43 minuti |
| 99,99% | Circa 4 minuti e 19 secondi |
L'error budget
Se l'obiettivo è il 99,9 per cento, lo 0,1 per cento restante è l'error budget: la quantità di errori che ci si può permettere nel periodo. Non è un fallimento tollerato a malincuore, ma una risorsa da spendere.
L'error budget si consuma con incidenti, rilasci problematici, manutenzioni. Il suo valore sta nelle decisioni che rende oggettive:
- se il budget è ampio, si possono rilasciare novità più spesso e sperimentare;
- se il budget si sta esaurendo, si rallentano i rilasci e si investe in stabilità;
- se il budget è esaurito, si sospendono le modifiche non urgenti finché l'affidabilità non torna in linea.
In questo modo la tensione tra chi vuole aggiungere funzionalità e chi vuole stabilità si risolve con un criterio condiviso, invece che con discussioni a ogni rilascio.
Avvisi basati sugli SLO
Gli SLO migliorano anche gli avvisi. Invece di svegliare qualcuno ogni volta che un server supera una soglia, si genera un avviso quando il budget si consuma troppo in fretta. Un tasso di errori che, se continuasse, esaurirebbe il budget mensile in poche ore richiede un intervento immediato; un consumo lento può aspettare la mattina.
Questa logica, detta del burn rate, riduce gli avvisi inutili e fa coincidere l'urgenza con l'impatto reale sugli utenti.
Come iniziare
- Scegli un servizio importante e uno o due SLI che rappresentino ciò che interessa agli utenti.
- Misura per qualche settimana prima di fissare un obiettivo: l'SLO deve partire dalla realtà.
- Stabilisci un SLO raggiungibile, leggermente sopra il livello attuale se è insoddisfacente.
- Concorda con il team cosa succede quando il budget si esaurisce, e mettilo per iscritto.
- Rivedi gli obiettivi periodicamente: troppo facili non guidano nulla, troppo difficili vengono ignorati.
In sintesi
- Lo SLI è la misura, lo SLO l'obiettivo interno, lo SLA l'impegno contrattuale.
- Un buon indicatore riflette l'esperienza dell'utente, non lo stato interno delle macchine.
- Il cento per cento è irraggiungibile, costoso e frena lo sviluppo.
- L'error budget trasforma l'affidabilità in una risorsa e rende oggettive le decisioni sui rilasci.
- Gli avvisi basati sul consumo del budget riducono il rumore e rispecchiano l'impatto reale.
