SLO, SLA, error budget per i prodotti dati

Il Modulo 8 parla di reliability. La prima metà del corso ha costruito sistemi. Il Modulo 7 ha coperto le pratiche che li spediscono. Questo modulo riguarda le discipline che li tengono in piedi una volta che utenti veri ci dipendono sopra, e deve partire dalla domanda che ogni team dati prima o poi si sente fare: quanto è affidabile il dato, di preciso?

La risposta onesta che la maggior parte dei team dà è una qualche forma di “abbastanza affidabile, di solito”. Quella risposta non sopravvive a una sola settimana storta. La dashboard era in ritardo martedì. I numeri del report di venerdì non quadravano con il sistema sorgente. Il cliente ha firmato un contratto presupponendo un refresh notturno e adesso si è irritato perché “notturno” qualche volta vuol dire le 11 del mattino. Nessuno ha messo nero su bianco cosa significava reliability, quindi ognuno ha un modello mentale diverso, e ogni incidente diventa una rinegoziazione.

La pratica Site Reliability Engineering di Google ha risolto questo problema per i servizi software circa quindici anni fa. Il framework è ormai ampiamente adottato: gli SLI misurano, gli SLO mettono il target, gli SLA si impegnano, e gli error budget collegano la reliability al resto del lavoro. Il framework è stato scritto per sistemi request-response (latency, availability, error rate di un servizio HTTP), ma la stessa forma si applica in modo pulito ai prodotti dati se gli indicatori sono scelti con cura. Questa lezione traduce il framework SRE nel vocabolario del data engineering e attraversa le policy che lo rendono operativo.

I quattro termini

Il vocabolario è piccolo ma ogni termine ha un ruolo preciso. Confonderli è l’errore più comune nelle prime fasi di adozione.

SLI, il Service Level Indicator, è una proprietà misurabile del sistema. È un numero che puoi calcolare a partire dai dati che il tuo monitoring già raccoglie. “Frazione dei refresh della dashboard che si completano entro le 9 del mattino, calcolata giornalmente” è uno SLI. “Frazione delle righe nella tabella customer che sono non-null su email, calcolata ogni ora” è uno SLI. Il test che lo definisce è: uno script può restituire un numero? Se sì, è un candidato SLI. Se la proprietà è “data quality”, non è ancora uno SLI; è una categoria che ha bisogno di essere affilata in qualcosa di misurabile.

SLO, il Service Level Objective, è il target che imposti per lo SLI. Lo SLI è la misurazione; lo SLO è l’obiettivo. “Il 99% dei refresh della dashboard si completa entro le 9 del mattino, misurato mensilmente” è uno SLO costruito sullo SLI precedente. L’obiettivo è interno. È l’asticella che il team si pone, ed è l’asticella che guida le priorità di engineering. Il numero si sceglie deliberatamente, non in modo aspirazionale; più avanti su questo punto.

SLA, il Service Level Agreement, è un impegno contrattuale verso una parte esterna con conseguenze se non rispettato. Gli SLA in genere coinvolgono soldi: service credit, rimborsi, penali contrattuali. La proprietà cruciale è che lo SLA è quasi sempre più debole dello SLO interno corrispondente. Il team si impegna internamente al 99,9% in modo da poter firmare con sicurezza uno SLA esterno al 99%. Lo scarto è il margine di sicurezza. Un team il cui SLA coincide con il suo SLO è a una settimana storta dal pagare penali. Un team il cui SLA è più lasco del suo SLO ha spazio per assorbire la varianza normale senza violare contratti.

Error budget è l’inverso dello SLO. Se lo SLO è 99%, l’error budget è l’1%. Su un mese, quell’1% sono grosso modo 7 ore di downtime ammesso, oppure diverse migliaia di refresh falliti ammessi, a seconda di come è contato lo SLI. Il budget è una risorsa finita, come il saldo di una carta di credito per la inaffidabilità. Ogni incidente, ogni refresh in ritardo, ogni riga mancante ne consuma una parte. Quando finisce, il comportamento cambia (descritto sotto).

Le relazioni si perdono di vista facilmente. Lo SLI è l’indicatore sulla dashboard. Lo SLO è dove si trovano le bande verde-ambra-rosso. Lo SLA è ciò che sta nel contratto. L’error budget è il margine prima che lo SLO venga violato.

Applicare il framework ai dati

I prodotti dati hanno quattro dimensioni di reliability che vale la pena strumentare, e ognuna mappa in modo pulito su una forma di SLI.

Freshness SLO catturano quanto stantio può essere il dato. “La tabella customer ha al massimo 1 ora di staleness, il 99% del tempo, misurato su una rolling window di 30 giorni.” Lo SLI si calcola dal massimo lag tra il commit time del sistema sorgente e il tempo in cui il dato è visibile nel warehouse, campionato come il sistema permette. La freshness è ciò che la maggior parte degli stakeholder di business intende quando dice “il dato è rotto”; il report mostra dati di ieri quando si aspettavano quelli di oggi, e il modello che decide cosa significa “di oggi” è lo SLO di freshness.

Completeness SLO catturano le righe mancanti. “Meno dello 0,1% delle righe attese mancano per giorno, misurato per pipeline.” Lo SLI confronta il numero di righe attese (dai metadati del sistema sorgente, da una cardinalità nota, oppure dal giorno precedente più una tolleranza) con il numero di righe effettive. I fallimenti di completeness spesso si nascondono perché la dashboard si renderizza comunque; il grafico mostra solo un numero più piccolo di quello che dovrebbe, e nessuno se ne accorge finché una persona del sales non chiede perché la sua region sembra sbagliata.

Accuracy SLO catturano l’errore, non l’assenza. “Il totale revenue giornaliero nel warehouse coincide con il sistema ERP source-of-truth entro lo 0,01%, misurato di notte.” Lo SLI è un controllo di riconciliazione: prendi la stessa metrica da due sistemi, confronta. L’accuracy è la dimensione più difficile da strumentare perché ti serve una ground truth indipendente, ma è anche la dimensione che distrugge la fiducia più velocemente quando fallisce. Gli stakeholder perdonano una dashboard in ritardo. Non perdonano una dashboard sbagliata.

Availability SLO catturano se il dato è interrogabile quando atteso. “La dashboard di BI è interrogabile il 99,9% delle ore durante l’orario di ufficio, misurato per region.” Lo SLI è una sonda sintetica: ogni minuto, una query automatica gira, e il sistema registra se è riuscita entro una soglia di latency. L’availability è la più vicina agli SLO tradizionali dei servizi, perché la dashboard è essenzialmente un sistema request-response una volta che il dato è stato caricato.

La maggior parte dei prodotti dati vuole SLO su due o tre di queste dimensioni, non su tutte e quattro. Scegli le dimensioni che mappano sul vero dolore degli stakeholder.

Perché gli SLO funzionano meglio di “dovremmo solo essere affidabili”

Il modello pre-SLO di reliability è implicito e antagonistico. L’engineering vuole spedire feature. Le operations o gli stakeholder vogliono meno incidenti. Ogni incidente diventa una lite su se il team stia andando troppo veloce, e non c’è uno standard condiviso per “troppo veloce”. Il framework SLO sostituisce quella lite con tre proprietà.

Rende il trade-off esplicito. Il 100% di reliability non è raggiungibile, e anche se lo fosse, il costo sarebbe assurdo: ogni nove di reliability addizionale tipicamente costa un ordine di grandezza in più di sforzo di engineering. Lo SLO nomina il target deliberatamente. Il 99% è economico. Il 99,9% è significativamente più caro. Il 99,99% richiede vero investimento di engineering. Il 99,999% è raramente giustificato fuori dai sistemi di pagamento e dalla life-safety. Scegliere 99% contro 99,9% è scegliere quanta parte del budget di engineering va alla reliability rispetto alle feature, e lo SLO rende quella scelta visibile invece di fingere che non esista.

Dà al team il permesso di essere imperfetto. Un incidente che consuma parte dell’error budget non è un fallimento morale. È il sistema che spende il budget che gli era già stato allocato. Su un trimestre, qualche incidente è atteso. Il team che ha zero incidenti probabilmente sta investendo poco nella velocità di feature; il team che esaurisce il suo budget ogni mese sta investendo poco in reliability. Il budget rende la conversazione quantitativa.

Prioritizza il lavoro automaticamente. Quando il budget è in salute, spedisci feature e prendi rischi. Quando il budget è finito, gli stessi rischi non sono più accettabili, e lo sforzo di engineering si sposta sul lavoro di reliability finché il budget non si ripristina. Lo spostamento è policy, non negoziato. C’è una regola scritta, il team la segue, la conversazione su cosa lavorare diventa breve.

La error-budget policy

La error-budget policy è il documento che trasforma il budget astratto in comportamento operativo. Il Google SRE Workbook (https://sre.google/workbook/error-budget-policy/, consultato 2026-05-01) fornisce un template; la maggior parte delle organizzazioni lo adatta. La struttura è tre stati con regole diverse.

Budget in salute (resta più del 50% del budget del periodo): operazioni normali. Spedisci feature. Prendi rischi ragionevoli. Deploy il venerdì se il sistema di deployment è abbastanza affidabile. Esegui esperimenti. Il team sta operando nel regime che lo SLO era progettato per consentire.

Budget basso (meno del 50%, più dello 0%): cautela. I cambiamenti rischiosi ricevono review extra. Le migrazioni maggiori vengono rimandate se non sono già in volo. La frequenza di deployment può rallentare. Il team inizia a ripagare il debito di reliability: tuning degli alert, aggiornamenti dei runbook, le piccole fix che erano state rimandate. L’obiettivo è ricostituire il budget prima che l’esaurimento forzi misure più dure.

Budget esaurito (zero o negativo per il periodo): freeze. Nessun deployment salvo quelli che migliorano direttamente la reliability o che sistemano gli incidenti che hanno consumato il budget. Il lavoro su feature si ferma. Il team si concentra sul riportare lo SLI in verde e sul lavoro di engineering che previene la prossima violazione. Il freeze è scomodo, che è il punto: crea pressione perché si investa in reliability prima che il budget finisca, non dopo.

Il freeze è la parte controversa. I team di engineering gli resistono perché il lavoro su feature è più visibile. I product manager gli resistono perché gli impegni di roadmap slittano. Il framework funziona solo se la leadership supporta la policy quando viene invocata. Una policy che viene sospesa la prima volta che davvero scatta è una policy che ha allenato il team a ignorarla.

Impostare SLO realistici

L’errore più comune sugli SLO è scegliere il numero in modo aspirazionale. “Vogliamo il 99,99% perché il cliente l’ha chiesto” non è uno SLO. È un desiderio. Lo SLO vero deve essere qualcosa che il sistema può consegnare con uno sforzo ragionevole di engineering, e il modo per trovare quel numero è partire dalla performance attuale.

Misura lo SLI per un periodo rappresentativo (un mese, un trimestre). Guarda la distribuzione. Lo SLO andrebbe impostato appena sopra la performance attuale, non molto sopra. Se la dashboard attualmente si aggiorna entro le 9 del mattino il 97% delle volte, imposta lo SLO al 98%, non al 99,9%. L’error budget al 98% dà al team lo spazio per la varianza che attualmente sperimenta, mentre il piccolo gradino in su forza un miglioramento incrementale. Dopo un trimestre al 98%, alza al 98,5%. Rachet lento, miglioramento sostenibile.

L’errore opposto è impostare lo SLO troppo lasco. Se la performance attuale è 99,5% e lo SLO è impostato al 95%, il budget è così generoso che gli incidenti non fanno scattare la policy, e il framework non fornisce alcuna pressione operativa. Lo SLO va impostato a un numero che il sistema in effetti rischia di violare, altrimenti è teatro.

Gli impegni esterni (lo SLA) si derivano poi dallo SLO interno, non viceversa. Il team interno si impegna al 99% come SLO. Il contratto esterno si impegna al 95% come SLA. Il gap di 4 punti percentuali è il margine di sicurezza. I clienti vedono un impegno al 95% e il team opera contro un target del 99%, il che significa che lo SLA non viene quasi mai violato anche quando lo SLO sì.

Il loop dell’error budget

flowchart TD
    A[Measure SLI from monitoring] --> B[Compare to SLO target]
    B --> C[Compute remaining error budget]
    C --> D{Budget state?}
    D -->|Healthy| E[Ship features, take risks]
    D -->|Low| F[Caution, pay down reliability debt]
    D -->|Exhausted| G[Freeze, focus on reliability]
    E --> H[Next measurement period]
    F --> H
    G --> H
    H --> A

Il loop è il ritmo giornaliero e settimanale. Il monitoring calcola gli SLI in continuo. Una dashboard mostra la compliance attuale rispetto allo SLO e il budget rimanente. Le riunioni di review settimanali o mensili ispezionano lo stato del budget e aggiustano l’allocazione del lavoro. Gli incidenti aggiornano il budget in tempo reale. Il framework diventa la lente attraverso cui il team vede il proprio lavoro di reliability.

L’arco di maturità è graduale. Il primo trimestre, il team sceglie SLO che si rivelano sbagliati (troppo stretti, troppo larghi, che misurano la cosa sbagliata) e li rivede. Il secondo trimestre, gli SLI sono ragionevoli ma la policy non è ancora stata invocata, quindi non è stata testata. Il terzo o quarto trimestre, il budget si esaurisce per la prima volta, la policy viene invocata, e l’organizzazione scopre se davvero crede nel framework. I team che sopravvivono a quel test hanno una pratica di reliability vera. I team che no, hanno un documento.

La Lezione 61 riprende il filo andando uno strato più a fondo nella categoria di SLI più comune per i prodotti dati: la data quality. Lo SLO dice “meno dello 0,1% delle righe attese mancano”; la pratica di data-quality testing è ciò che produce quel numero in modo affidabile. SLO senza testing di qualità sono indovinelli. Testing di qualità senza SLO è lavoro inutile.