Cos'è uno SLO? Guida con template Excel e Google Sheets

Cos'è uno SLO? Un service level objective è un obiettivo di affidabilità che stabilisci per un servizio, scritto come un numero su un periodo di tempo. "Il 99,9% delle richieste ha successo in 30 giorni" è un SLO. Dice al tuo team quanto guasto è accettabile prima di smettere di rilasciare e cominciare a riparare. La matematica dietro è una divisione semplice, ecco perché un foglio di calcolo la gestisce benissimo. Biscuit ha già trovato le formule. Ora tocca a te portare i numeri.

I tre acronimi che continui a vedere, spiegati bene

SLI, SLO, SLA. La gente li confonde nelle riunioni, quindi ecco la versione breve.

• SLI (service level indicator): la cosa che misturi. La percentuale di richieste che ritornano senza errore, la percentuale di pagine che si caricano sotto i 300 ms, la percentuale di job che finiscono in tempo.

• SLO (service level objective): l'obiettivo per quella misura. "L'SLI deve essere almeno al 99,9% in 30 giorni."

• SLA (service level agreement): un contratto con conseguenze, solitamente i soldi indietro, legato a un obiettivo.

Il test più pulito viene dal libro SRE di Google: chiediti cosa succede se non raggiungi l'obiettivo. Se non succede niente dal punto di vista contrattuale, stai guardando un SLO, non un SLA. Il tuo SLO dovrebbe essere più stringente di qualsiasi SLA che hai firmato, così ricevi un avviso prima che un cliente riceva un rimborso.

In termini di foglio di calcolo: l'SLI è una colonna di misurazioni, l'SLO è una cella con l'obiettivo, e l'SLA è un PDF che qualcuno ufficio legale conserva gelosamente.

Perché il 99,9% e il 99,99% sono promesse molto diverse

Ogni nove in più riduce il tempo di inattività consentito di un fattore dieci. In un mese di 30 giorni (43.200 minuti), ecco cosa lascia ogni obiettivo:

• 99%: 1% di budget, 432 minuti (7,2 ore) di inattività consentita per 30 giorni

• 99,5%: 0,5% di budget, 216 minuti (3,6 ore)

• 99,9%: 0,1% di budget, 43,2 minuti

• 99,95%: 0,05% di budget, 21,6 minuti

• 99,99%: 0,01% di budget, 4,32 minuti

Quest'ultima è la trappola. Quattro minuti al mese significa che un umano non riesce nemmeno a finire di leggere l'avviso prima che il budget sia esaurito. La maggior parte degli strumenti interni, dashboard e piccoli prodotti SaaS non ne ha bisogno, e inseguirlo costa soldi veri in ridondanza e ore on-call.

Salta il 99,99% a meno che un cliente non ti stia pagando specificamente per averlo. Anche il consiglio di Google è diretto: inizia con un obiettivo che puoi poi stringere, perché uno troppo rigido che devi poi rilassare insegna a tutti a ignorare il numero.

L'error budget: il numero su cui il tuo team discute davvero

L'error budget è tutto quello che l'SLO lascia di avanzo. Obiettivo 99,9%, quindi il budget è 0,1%. In 30 giorni, sono 43,2 minuti di tempo "cattivo" che puoi spendere.

Pensalo come un indicatore di carburante. I rilasci rischiosi bruciano carburante. Una migrazione pessima del database brucia carburante. Un'interruzione alle 3 di mattina brucia un sacco di carburante. Quando il serbatoio è pieno, rilascia più veloce. Quando è vuoto, smetti di aggiungere funzionalità e inizia a riparare l'affidabilità.

La stessa politica di Google è concreta al riguardo: se un servizio brucia il suo budget in una finestra di quattro settimane, tutti i cambiamenti si fermano eccetto i fix P0 e le patch di sicurezza finché il servizio non è di nuovo dentro il suo SLO. L'error budget è uno strumento di negoziazione, non una punizione. Permette a un product manager e a un ingegnere di discutere dalla stessa cella invece che da sensazioni istintive.

Vale la pena farci caso se hai più di un team che tocca lo stesso servizio. È eccessivo se sei un founder da solo con una landing page e un form di contatto.

Scegliere un SLI che i tuoi utenti riconoscerebbero

Gli SLI migliori descrivono un momento che una persona noterebbe. Tre coprono la maggior parte dei servizi:

• Disponibilità: la percentuale di richieste che hanno successo. Facile da misurare, facile da spiegare.

• Latenza: la percentuale di richieste più veloci di una soglia. "Il 95% delle ricerche ritorna in meno di 300 ms" è meglio di una media, perché le medie nascondono la coda lenta che infastidisce la gente.

• Freschezza: per pipeline di dati e report, la percentuale di esecuzioni che finiscono prima della scadenza. Questo si adatta bene ai tabulisti: "il foglio di vendita del mattino è aggiornato entro le 8 del mattino nel 99% dei giorni feriali."

Scrivi l'SLI come una frazione: eventi buoni diviso eventi validi. Quel singolo abito rende ogni SLO calcolabile in una sola cella, e ti costringe a decidere cosa conta come "buono" prima dell'incidente, non durante.

Per la finestra, 30 giorni rolling è la scelta usuale. Un mese di calendario è più semplice da riportare ma resetta il budget il primo del mese, il che attira i team a fare rilasci rischiosi alla fine del mese. In un foglio, una finestra rolling significa solo filtrare la scheda Incidents agli ultimi 30 giorni con SUMIFS(Incidents!C:C,Incidents!A:A,">="&TODAY()-30).

Costruisci un tracker SLO in Google Sheets o Excel in 10 minuti

Non hai bisogno di una piattaforma di monitoraggio per iniziare. Hai bisogno di due schede: Incidents e SLO.

Sulla scheda Incidents, registra ogni interruzione con un'ora di inizio nella colonna A, un'ora di fine nella colonna B, e la durata nella colonna C:

=(B2-A2)*24*60

• B2 e A2: l'ora di fine e di inizio dell'incidente.

• *24*60: trasforma la differenza basata su giorni in minuti.

Funziona sia in Excel che in Sheets, tutte le versioni.

Ora la scheda SLO. Metti queste etichette nella colonna A e le formule nella colonna B:

B1: 0.999                         (il tuo obiettivo SLO)
B2: 30                            (finestra in giorni)
B3: =B2*24*60                     (total minutes in the window)
B4: =B3*(1-B1)                    (error budget in minutes)
B5: =SUM(Incidents!C2:C)          (downtime so far)
B6: =1-B5/B3                      (actual availability)
B7: =B4-B5                        (budget left, in minutes)
B8: =B5/B4                        (share of budget burned)

Con un obiettivo 99,9%, B3 ritorna 43200 e B4 ritorna 43,2. Registra un'interruzione di 12 minuti e B8 mostra il 27,8%. Ecco cosa dà in una vera cella.

Una nota su C2:C in B5: la gamma aperta è la sintassi di Sheets. In Excel, usa una gamma fissa come Incidents!C2:C500 o un riferimento a tabella.

Aggiungi una cella di stato in modo che nessuno debba leggere il numero:

=IF(B8>=1,"Freeze releases",IF(B8>=0.5,"Careful","Ship it"))

• B8>=1: budget completamente speso o eccessivo.

• B8>=0.5: metà consumata, quindi rivedi i cambiamenti rischiosi.

• Qualsiasi altra cosa: luce verde.

Scegli le tue soglie. Cinquanta per cento è un'ipotesi iniziale, non una legge della fisica.

Bloccato sulla sintassi per la tua versione di questo foglio? Descrivila in italiano semplice e lascia che lo strumento la scriva.

Contare le richieste invece dei minuti

Il tracciamento basato sul tempo è facile da spiegare ma grezzo. Se il tuo servizio è "inattivo" per 5 minuti alle 4 del mattino quando nessuno è online, fa meno male di 5 minuti a mezzogiorno. La maggior parte dei team seri definisce l'SLI per richieste invece.

Incolla un'esportazione del tuo log di richieste in una scheda, con il codice di stato HTTP nella colonna B. Poi:

=1-COUNTIF(B2:B,">=500")/COUNTA(B2:B)

• COUNTIF(B2:B,">=500"): conta le richieste che hanno ritornato un errore del server.

• COUNTA(B2:B): conta tutte le richieste. Uno meno la quota di errore ti dà la quota di successo.

Il risultato è il tuo SLI di disponibilità come frazione. Confrontalo con la cella di obiettivo e hai il SLO intero in una riga. Excel 2016 e 365 accettano entrambi COUNTIF; basta scambiare B2:B con una gamma limitata.

Due avvertimenti onesti. I fogli di calcolo si bloccano su milioni di righe, quindi esporta i totali giornalieri invece dei log raw. E una risposta 4xx è solitamente l'errore dell'utente, non la tua interruzione, quindi decidi quella regola una volta e scrivila.

Burn rate: la formula che ti avvisa prima che sia troppo tardi

Sapere che hai bruciato il 27,8% del tuo budget è bello. Sapere che lo stai bruciando più veloce del calendario è utile. Quel rapporto è il burn rate.

=B8/(B9/B2)

• B8: quota di budget bruciata finora.

• B9: giorni trascorsi nella finestra (inseriscilo manualmente o usa =TODAY()-B10, con la data di inizio della finestra in B10).

• B2: finestra totale in giorni.

Un burn rate di 1 significa che finirai la finestra con esattamente zero budget rimasto. Sopra 1, stai andando verso un congelamento. Sotto 1, hai spazio. Se sei a 10 giorni in una finestra di 30 giorni e hai già bruciato il 60%, il burn rate è 1,8. Quel è il numero da mettere su uno schermo.

È la stessa idea che i grandi strumenti di monitoraggio usano per gli avvisi di burn rate. Un foglio non ti chiamerà alle 3 di mattina, però, quindi trattalo come uno strato di reporting, non un allarme.

Ecco un esempio reale con numeri veri. Il tuo SLO è 99,9% in 30 giorni, quindi il budget è 43,2 minuti. Giorno 1 a 8: un rilascio cattivo porta la pagina di checkout giù per 14 minuti. È il 32,4% del budget consumato in un quarto della finestra, un burn rate di circa 1,2. Niente è in fiamme, ma il foglio ora dice "Careful", e la prossima migrazione rischiosa riceve una seconda occhiata. Giorno 15: un'interruzione del provider aggiunge 30 minuti. Totale 44 minuti, 101,9% bruciato. La cella di stato passa a "Freeze releases", e la conversazione sulle priorità accade con un numero sul tavolo invece che una sensazione.

Questo è il valore intero dell'esercizio. Non i nove, ma la cella condivisa che tutti possono indicare.

Quando il foglio di calcolo non basta più

Un tracker come questo funziona per uno o due servizi e una revisione settimanale. Si rompe quando hai dozzine di servizi, hai bisogno di raccolta dati automatica, o vuoi avvisi che scattano in minuti piuttosto che alla prossima riunione del lunedì.

È ora di guardare uno strumento di observability adeguato. Datadog e Grafana entrambi hanno funzionalità SLO native che tirano l'SLI direttamente dalle tue metriche e disegnano il budget per te.

Scegli Grafana se vuoi open source e stai già usando Prometheus. Scegli Datadog se preferisci pagare per non mantenere niente tu stesso. In entrambi i casi, mantieni il foglio in giro per il deck di revisione mensile, perché chiunque nella stanza può aprirlo e nessuno ha bisogno di un login presso un fornitore.

Se vuoi aiuto a stilare una prima serie di SLI per un servizio, un assistente generico è un partner di brainstorming decente. Verifica ogni numero che ti dà, perché sarà felice di inventare un obiettivo plausibile.

Gli errori che rendono un SLO inutile, e cosa fare lunedì

Alcuni pattern che Biscuit ha visto finire male:

• Copiare la tua performance attuale come obiettivo. Se hai funzionato al 99,97% il trimestre scorso, un SLO di 99,97% blocca un ritmo che potresti non riuscire a sostenere.

• Troppi SLO. Due o tre per servizio. Dopo, nessuno ricorda quale conta.

• Misurare quello che è facile, non quello che gli utenti sentono. L'uso della CPU non è un SLI. I checkout falliti lo sono.

• Nessuna conseguenza. Un SLO senza una politica di error budget è un desiderio. Decidi in anticipo cosa succede al 50%, 100% e 150% bruciato.

• Non rivisitare mai l'obiettivo. Rivedi ogni trimestre. Se non vieni mai vicino a spendere il budget, l'obiettivo è troppo lasco.

Ora la parte del lunedì. Scegli un servizio. Scrivi uno SLI in una sola frase che un non-ingegnere potrebbe seguire. Imposta un obiettivo lasco, 99,5% o 99,9%. Costruisci le due schede di cui sopra, registra gli incidenti dell'ultimo mese, e vedi cosa dice il budget.

Se la risposta è "abbiamo bruciato il 300% di esso", hai appena scoperto perché tutti si sentono stanchi. Se la risposta è "abbiamo bruciato il 4%", stringi l'obiettivo o rilascia più veloce. In ogni caso, ora hai un numero di cui discutere invece di una sensazione.

Brav'attore. Ora vai a registrare quei incidenti.