Cosa è un SLO: Misurare l'Affidabilità del Servizio

Cosa è un SLO? Un Service Level Objective (SLO) è un target affidabilità interno che il vostro team si fissa autonomamente. Non è un contratto con i clienti, non è una metrica grezza dal vostro stack di osservabilità. Un SLO risponde a una domanda precisa: quanto deve essere affidabile questo servizio, e come lo misureremo?

Un SLO completo ha questo aspetto: il 99,9% delle richieste HTTP a /api/checkout restituisce uno status di successo e si completa entro 300 ms, misurato su una finestra di 30 giorni rolling. Tre componenti: la misura, il target, la finestra. Contano tutti e tre.

SLI, SLO, SLA: Tre Sigle Che Significano Cose Diverse

Questi tre termini appaiono costantemente insieme. I team li usano come sinonimi. Descrivono cose diverse.

Un SLI (Service Level Indicator) è la misura grezza che il vostro sistema di monitoring produce. Tasso d'errore come percentuale delle richieste totali. P99 latency in millisecondi. Percentuale di scritture su database riuscite. L'SLI è il numero che esce da Datadog, Grafana o dallo stack che usate. Vi dice cosa è successo.

Un SLO (Service Level Objective) è il target che definite sopra l'SLI. Risponde a: di tutti i possibili valori che l'SLI può assumere, quale range conta come accettabile? Se il vostro SLI è tasso d'errore e il vostro SLO è "tasso d'errore sotto lo 0,1% per il 99% delle finestre di cinque minuti", avete un test pass/fail, non solo un numero su un dashboard.

Un SLA (Service Level Agreement) è la versione esterna della stessa logica, con conseguenze contrattuali. Il vostro SLA potrebbe dire "99,5% di uptime o emettiamo un credito servizio del 20%". Il vostro SLO dovrebbe stare sopra quel soglia, così il team sa di una degradazione prima che una violazione SLA diventi una conversazione con il cliente.

Lo spazio tra SLO e SLA non è padding per la negligenza. È un margine progettato che trasforma "stiamo andando verso una violazione" in "abbiamo tempo di aggiustare ora".

Un'ultima distinzione importante: gli SLI vengono misurati continuamente, ma gli SLO si valutano su una finestra. Lo stesso tasso d'errore misurato su sette giorni versus 30 giorni produce risultati pass/fail molto diversi. Un'ora cattiva conta molto in una finestra di sette giorni. In una finestra di 30 giorni, è grosso modo l'uno percento del periodo. Scegliere la finestra giusta è importante quanto scegliere il target giusto.

Perché "Quanto Deve Essere Affidabile?" Non È Una Domanda Completa

Prima di scegliere un numero, dovete capire cosa sperimenta l'utente quando il servizio degrada. "Abbiamo bisogno di cinque nines" è una dichiarazione d'ambizione, non una misura. Un'API checkout al 99,999% di disponibilità significa pressappoco 26 secondi di errori al mese. Per un servizio che elabora dieci transazioni al secondo, potrebbe essere accettabile. Per un servizio che gestisce il settlement finanziario real-time, potrebbe non esserlo.

L'SLO giusto dipende da due fattori: l'impatto sull'utente di una degradazione, e il costo operativo di mantenere un target più stretto.

Se il vostro servizio ha registrato disponibilità 99,3% negli ultimi 90 giorni, iniziare il primo SLO a 99,9% è aspirazionale, non calibrato. L'approccio pratico: prendete i dati SLI degli ultimi 90 giorni, fissate l'SLO leggermente più stretto della performance attuale, poi revisionate trimestralmente. Un SLO 99,5% con una vera policy di error budget batte un SLO 99,9% che viene ignorato ogni volta che si rompe.

Target SLO comuni per tipo di servizio:

• API rivolte all'utente (checkout, auth): disponibilità 99,9%, latency P99 sotto 500 ms

• Servizi interni (pipeline dati, batch job): tasso successo 99,5%, misurato sul completamento job

• Tool admin: disponibilità 99% è spesso sufficiente

• Worker di background: SLO su tempo completamento job piuttosto che su status HTTP

Quando scegliete quale SLI misurare, usate i quattro segnali dal libro SRE di Google come punto di partenza: availability (la richiesta ha avuto successo?), latency (quanto ha impiegato?), throughput (quante richieste gestisce il sistema?), error rate (quale frazione ha fallito?). Non ogni servizio ha bisogno di tutti e quattro. La maggior parte dei team ottiene segnale reale da availability più un percentile di latency. Aggiungere più SLI prima di avere un baseline affidabile per i primi due è un modo comune di creare rumore senza guadagnare insight.

L'Error Budget: Dal Target Alla Decisione Operativa

Un error budget è l'inverso matematico del vostro SLO. Se il vostro SLO di availability è 99,9%, allora lo 0,1% delle richieste nella finestra di misurazione possono fallire. Per un servizio che riceve un milione di richieste al mese, sono 1.000 richieste fallite prima che l'SLO si rompa.

L'error budget rende gli SLO operativamente utili. Senza, un SLO è una soglia che viene violata e poi discussa. Con una policy di error budget, diventa un framework di decisione.

Quando l'error budget è sano, diciamo 80% rimasto con due settimane rimaste nella finestra, il team può spedire veloce. Nuove feature, esperimenti, deployment più rischiosi sono tutti ammissibili. L'error budget è il segnale che la velocità non è attualmente il vincolo.

Quando l'error budget sta bruciando, il team cambia. I cambiamenti non critici vanno in sospeso. La policy di deployment si stringe. Le fix affidabilità hanno priorità. L'error budget ha preso la decisione, non una chiamata manageriale su se le cose "si sentono abbastanza stabili".

Uno scenario concreto: un servizio checkout ha avuto una degradazione di 12 minuti lunedì pomeriggio, consumando il 15% del budget mensile d'errore. Un secondo incident giovedì ha consumato altri 12%. A 27% consumato nella prima settimana del mese, la policy di error budget si attiva: nessun nuovo deployment di feature finché un postmortem non è completato e la root cause non è patchata. Quella decisione non è una negoziazione prodotto/engineering. È una lettura dai dati.

Google ha pubblicato la sua policy di error budget nel Workbook SRE: un singolo incident che consuma più del 20% dell'error budget trimestrale richiede un postmortem. Questa è una policy concreta da adattare.

Gli alert di burn rate vanno oltre. Invece di aspettare finché l'error budget quasi non è consumato, un alert di burn rate scatta quando il tasso di consumo suggerisce che esaurirete il budget prima che la finestra finisca. Se il vostro servizio sta consumando error budget a 14 volte il tasso normale, esaurirete un budget di 30 giorni in pressappoco 50 ore. Un alert a quel tasso dà al team due giorni per rispondere piuttosto che una notifica postmortem dopo la violazione. Tool come Datadog e Grafana supportano alert multi-finestra e multi-burn-rate out of the box. Configurarlo richiede un pomeriggio. Non averlo significa scoprire violazioni SLO dopo che i clienti hanno già notato.

Impostare Il Vostro Primo SLO Senza Sbagliare Il Numero

L'errore più comune è iniziare col target prima di stabilire la misura.

Step 1: Definire l'SLI. "Availability" non è un SLI. "Richieste HTTP che restituiscono uno status non-errore (2xx/3xx), diviso per tutte le richieste HTTP" è un SLI. La misura deve essere producibile dalla telemetria che avete già. Promettere di instrumentare qualcosa "presto" significa che l'SLO non ha fonte dati.

Step 2: Prendere dati storici. Guardate gli ultimi 60-90 giorni. Com'è veramente l'SLI? Quali sono stati i due o tre giorni peggiori? Questo vi dice quale target è raggiungibile oggi e quanto margine avete prima della prima violazione.

Step 3: Impostare la finestra di misurazione. Le finestre rolling di 30 giorni sono le più comuni e vi danno dati responsivi e sempre attuali. Le finestre di mese calendario creano effetti cliff ai confini del mese. Le finestre rolling di sette giorni sono più sensibili ma possono triggerare troppo spesso per team ancora costruendo muscolo affidabilità.

Step 4: Scrivere la policy di error budget prima di averne bisogno. A quale tasso di burn dell'error budget il team ferma i cambiamenti non critici? A quale tasso di burn l'on-call escalate? Documentate questo prima dell'incident, non durante.

Step 5: Iniziare con un servizio. Definire SLO per 15 servizi contemporaneamente produce 15 dashboard che nessuno legge. Iniziate col servizio più visibile all'utente, fate un trimestre, aggiustate, poi espandete.

Opzioni della finestra di misurazione e loro trade-off:

• 7 giorni rolling: feedback veloce, più sensibile a incident brevi, può creare alert fatigue

• 30 giorni rolling: più comune, bilancia segnale e rumore

• 90 giorni rolling: utile per operazioni infrequenti ma critiche come batch job

Un esempio elaborato: per un'API e-commerce, potete impostare il primo SLO come "il 95% delle richieste a /checkout hanno successo e restituiscono entro 500 ms, misurato su una finestra rolling di 28 giorni". Questo vi dà un SLI concreto (tasso successo combinato con latency), un target specifico (95%), e una finestra definita (28 giorni). Da lì, calcolate l'error budget: il 5% delle richieste totali può fallire o essere lento. Se ricevete 200.000 richieste al giorno, il vostro error budget mensile è pressappoco 280.000 richieste fallite prima che l'SLO si rompa.

Dove SLO Monitoring Si Connette Al Lavoro Sulla Codebase

Un error budget che brucia più veloce del previsto è un problema di codebase più spesso che di infrastruttura. Latency spike risalgono a N+1 query che passarono inosservate in code review. Availability drop risalgono a un null pointer exception in un codepath che si attiva solo sotto una combinazione di carico specifica. L'SLO rileva i sintomi. La codebase contiene la causa.

Qui è dove il tempo tra "l'alert scatta" e "la root cause è identificata" diventa il vincolo pratico. Quando il servizio checkout sta consumando il 30% del suo error budget in tre giorni e l'engineer on-call deve grep attraverso un monorepo di 150.000 linee per trovare la logica di retry che si comporta diversamente sotto carico, l'SLO sta facendo il suo lavoro. Il tooling per l'analisi della root cause no.

I team che hanno instrumentato ricerca di codice assistita da IA insieme al loro stack di osservabilità riportano significativamente tempo-a-diagnosi più breve durante gli incident. Una query in linguaggio naturale per dove il servizio di pagamento gestisce retry su risposte 503 fa affiorare la funzione rilevante in secondi piuttosto che nei 20 minuti che richiede leggere attraverso cinque file e una pagina di Confluence. La finestra di 43 minuti dell'error budget viene spesa ad aggiustare il problema, non a leggere il codice.

Quattro Modi In Cui I Team Sbagliano Gli SLO

Troppi SLO. Un team che traccia 12 SLO simultaneamente tratterà gli alert come rumore di fondo entro due mesi. Tre a cinque SLO focalizzati sui comportamenti più visibili all'utente è un soffitto workable per un team di 10 engineer. Se ne servono di più, organizzateli in tier: SLO critici che triggerano le policy di error budget, e SLO informativi che generano solo dati.

Misurare infrastruttura, non esperienza utente. Utilizzo CPU, uso memoria, e I/O su disco sono utili segnali di debug. Sono scarsi SLI se non potete provare che correlano direttamente con degradazione visibile all'utente. Misurate cosa l'utente sperimenta: tasso successo richiesta, tempo risposta a P95 o P99, tempo a first meaningful paint.

SLO impostati senza analisi di costo operativo. Raggiungere disponibilità 99,99% tipicamente richiede active redundancy, multi-region failover, e immediate on-call response a qualsiasi ora. Se il team non può sostenibilmente operare così, l'SLO sarà regolarmente violato e poi ignorato. Un SLO violato e ignorato è peggio di nessun SLO: addestra il team a dismissare alert affidabilità.

Usare dati di error budget per assegnare colpa. Se la prima risposta a un error budget consumato è identificare chi ha pushato il cambiamento che l'ha causato, i report smetteranno di essere onesti. Gli error budget sono una risorsa di team. Quando il budget cala basso, la domanda è "cosa aggiustiamo?" non "chi è responsabile?"

Test della salute organizzativa: condividereste lo status attuale del vostro error budget in un all-hands engineering senza che triggeresse una discussione politica? Se no, la cultura intorno agli SLO ha bisogno di più attenzione che i target stessi. Le metriche affidabilità funzionano come strumenti decisionali solo quando il team si fida che segnalare un problema non crei rischio personale.

Gli SLO Hanno Bisogno Di Revisioni Trimestrali, Non Annuali

Impostare un SLO non è una calibrazione una tantum. I servizi cambiano, i pattern di traffico si spostano, e il costo di mantenere un dato livello di affidabilità cambia con loro.

Ogni 90 giorni, passate attraverso quattro domande:

1. L'SLO ha tenuto? Se sì, era confortevole, suggerendo che il target potrebbe essere più stretto?

2. L'error budget è stato interamente consumato? Quali incident l'hanno guidato?

3. L'SLO ha fatto affiorare segnale utile, o il team ha aggirato la policy di error budget?

4. La finestra di misurazione è ancora appropriata per come il servizio viene usato?

Se il team ha aggirato la policy di error budget più di due volte in un trimestre, l'SLO è probabilmente miscalibrato. O il target è troppo stretto, o la finestra è troppo breve, o la misura non riflette quello che gli utenti veramente esperiscono.

Gli SLO sono strumenti di calibrazione. Sono pensati per essere aggiustati mentre l'affidabilità migliora, il traffico cresce, e il business cambia la sua tolleranza per downtime. Un team che rivede e aggiusta i suoi SLO trimestralmente sta gestendo una pratica affidabilità. Un team che li ha impostati una volta e non li ha toccati da allora ha un dashboard con numeri che non significano nulla a nessuno.