SLI, SLO e SLA: misura, obiettivo, contratto

La pratica SRE (Site Reliability Engineering) di Google distingue tre concetti che l’esame ama sovrapporre. Lo SLI (Service Level Indicator) è una misura quantitativa del comportamento del servizio: availability, latency, error rate, freshness. Si esprime tipicamente come rapporto fra eventi “buoni” ed eventi totali su una finestra temporale. Lo SLO (Service Level Objective) è l’obiettivo interno posto su uno SLI, per esempio “il 99,9% delle richieste in 28 giorni ha latenza sotto i 300 ms”. Lo SLA (Service Level Agreement) è il contratto con il cliente, con penali economiche in caso di violazione.

Regola pratica: lo SLA deve essere sempre meno stringente dello SLO interno, così il team ha margine per reagire prima che scatti la penale contrattuale. Un buon SLI misura ciò che l’utente percepisce (una richiesta lenta è di fatto un fallimento), non una metrica di sistema come la CPU. In Google Cloud, SLI e SLO si definiscono e monitorano in Cloud Monitoring, che calcola direttamente il consumo dell’error budget.

Error budget e error budget policy

L’error budget è il complemento dello SLO: error budget = 1 - SLO. Con uno SLO del 99,9% hai lo 0,1% di inaffidabilità “spendibile” nella finestra. Questo budget è ciò che abilita i rilasci: finché c’è budget residuo, il team può innovare e accettare rischio; quando il budget è esaurito, la error budget policy — concordata in anticipo fra sviluppo e SRE — impone di frenare i rilasci di feature e concentrarsi su reliability e bugfix fino a rientrare.

I burn-rate alert sono il modo corretto di allertare: misurano la velocità di consumo del budget, non ogni singolo spike di errori. Un burn rate alto su finestra breve indica un incidente acuto; un burn rate moderato ma persistente segnala un’erosione lenta. Allertare su ogni deviazione genera invece rumore e alert fatigue. Dopo un incidente, il postmortem è blameless: si analizzano cause sistemiche, non colpe individuali.

Toil: riconoscerlo e ridurlo

Il toil è il lavoro operativo manuale, ripetitivo, automatizzabile, privo di valore duraturo e che scala linearmente con la dimensione del servizio. Non è “qualunque lavoro noioso”: un’attività di progettazione una tantum non è toil. Esempi tipici: restart manuali, applicare a mano la stessa patch, evadere richieste ripetitive. SRE punta a tenere il toil sotto una soglia di tempo (spesso citata intorno al 50%) per lasciare spazio all’ingegneria che riduce il toil futuro.

La riduzione passa dall’automazione: Cloud Build per la CI, Cloud Deploy per la CD, Config Sync / Config Controller per applicare in modo GitOps lo stato desiderato dell’infrastruttura (IaC dichiarativa), e la strumentazione con Cloud Monitoring, Cloud Trace (latenza distribuita) e Cloud Profiler (uso di CPU e memoria) per diagnosticare senza intervento manuale.

Capacity planning e affidabilità vs velocità

Il capacity planning garantisce che il servizio abbia risorse per reggere la domanda prevista rispettando lo SLO. Combina previsione della crescita (organica e legata a lanci/eventi), provisioning con margine e verifica tramite load testing. L’obiettivo è l’equilibrio: troppa affidabilità (SLO al 100%) blocca l’innovazione ed è antieconomica, troppo poca rompe la fiducia dell’utente. L’error budget rende questo trade-off misurabile e non politico: quanto rischiare deriva da un numero condiviso, non dalle opinioni.

Trappole tipiche d’esame

  • Confondere SLI/SLO/SLA → ricorda i ruoli: SLI = misura, SLO = obiettivo interno, SLA = contratto con penale; lo SLA è sempre più lasco dello SLO.
  • Alert su ogni errore → usa burn-rate alert: allerti sul consumo dell’error budget, distinguendo incidenti acuti (finestra breve) da erosione lenta, evitando alert fatigue.
  • “Puntiamo al 100% di availability” → punta allo SLO giusto: il 100% è antieconomico e azzera l’error budget; serve margine per rilasciare.
  • Budget esaurito ma si vuole rilasciare la feature → applica la error budget policy: i rilasci si congelano a favore della reliability finché il budget non rientra.
  • Chiamare “toil” ogni lavoro noioso → verifica i criteri: il toil è manuale, ripetitivo, automatizzabile e scala col servizio; il lavoro di progettazione una tantum non lo è.
  • Diagnosticare a mano → automatizza e strumenta: Cloud Build/Cloud Deploy per CI/CD, Config Sync per lo stato desiderato, Cloud Trace per la latenza e Cloud Profiler per CPU/memoria.