SLA, SLO e SLI a confronto: qual è la differenza?

Cos'è uno SLA?

Uno SLA (accordo sui livelli di servizio) è un accordo tra fornitore e cliente su metriche misurabili come tempo di attività, reattività e responsabilità.

Questi accordi sono in genere redatti dai nuovi team aziendali e legali di una società, e rappresentano gli impegni assunti con i clienti e le conseguenze qualora tali impegni non vengano mantenuti. In genere, le conseguenze includono sanzioni pecuniarie, crediti di servizio o estensioni della licenza.

Le sfide degli SLA

Gli SLA sono notoriamente difficili da misurare, rendicontare e rispettare. Questi accordi, generalmente scritti da persone che non fanno parte del settore tecnologico, spesso prevedono impegni che sono difficili da misurare da parte dei team, non sempre sono in linea con le priorità aziendali attuali e in continua evoluzione, e non tengono conto delle sfumature.

Ad esempio, uno SLA può promettere che i team risolveranno i problemi segnalati riguardo al Prodotto X entro 24 ore. Tuttavia, lo stesso SLA non specifica cosa succede se il cliente impiega 24 ore per inviare una risposta o le screenshot che consentono al team di effettuare una diagnosi del problema. Significa che la finestra di 24 ore del team si esaurisce a causa della lentezza del cliente oppure che l'orologio si avvia e si ferma in base ai tempi di risposta del cliente? Gli SLA devono rispondere a queste domande, ma ciò spesso non accade, un fatto che li ha resi invisi agli occhi dei responsabili IT.

Per molti esperti, la risposta a questa sfida risiede, innanzitutto, nella creazione degli SLA che tengano conto della tecnologia. Quanto più l'IT e DevOps collaborano con i team legale e di sviluppo aziendale per creare SLA che affrontino scenari del mondo reale, tanto più gli SLA inizieranno a riflettere realtà chiave, ad esempio i ritardi dei clienti nella risoluzione dei propri problemi.

A chi servono gli SLA?

Uno SLA è un contratto tra un fornitore e un cliente a pagamento. È improbabile che le aziende che forniscono un servizio gratuito agli utenti vogliano o abbiano la necessità di uno SLA per quegli utenti.

Che cos'è uno SLO?

Uno SLO (obiettivo di livelli di servizio) è un accordo all'interno di uno SLA relativo a una metrica specifica come il tempo di attività o il tempo di risposta. Quindi, se lo SLA è l'accordo formale tra te e il tuo cliente, gli SLO sono le promesse individuali che fai a quel cliente. Gli SLO rappresentano ciò che definisce le aspettative dei clienti e indica ai team IT e DevOps gli obiettivi che devono raggiungere e con cui misurarsi.

Le sfide degli SLO

Gli SLO sono meno odiati degli SLA, ma possono creare altrettanti problemi se sono vaghi, eccessivamente complicati o impossibili da misurare. I fattori essenziali per avere SLO che non spingano i tecnici sull'orlo della disperazione sono la semplicità e la chiarezza. Solo le metriche più importanti dovrebbero qualificarsi per lo status di SLO, gli obiettivi dovrebbero essere enunciati in un linguaggio semplice e, come per gli SLA, dovrebbero sempre tenere conto di problemi come i ritardi da parte del cliente.

A chi servono gli SLO?

Mentre gli SLA sono pertinenti solo nel caso di clienti a pagamento, gli SLO possono essere utili sia per gli account a pagamento che per quelli non a pagamento, nonché per i clienti interni ed esterni.

I sistemi interni, come i CRM, i repository di dati dei clienti e la intranet, possono essere altrettanto importanti dei sistemi rivolti verso l'esterno. Disporre di SLO per questi sistemi interni è un elemento importante non solo per raggiungere gli obiettivi aziendali, ma anche per consentire ai team interni di raggiungere i propri obiettivi rivolti ai clienti.

Cos'è uno SLI?

Uno SLI (indicatore del livello di servizio) misura la conformità a uno SLO (obiettivo di livello di servizio). Quindi, per esempio, se lo SLA specifica che i tuoi sistemi saranno disponibili il 99,95% delle volte, lo SLO è probabilmente un'operatività del 99,95% e lo SLI è la misurazione effettiva del tempo di attività. Potrebbe essere, ad esempio, del 99,96% o del 99,99%. Per restare conforme allo SLA, lo SLI dovrà mantenere o superare le promesse fatte in quel documento.

Le sfide degli SLI

Come per gli SLO, la sfida degli SLI è fare in modo che restino semplici, scegliere le metriche giuste da monitorare e non complicare eccessivamente il lavoro dell'IT includendo nel monitoraggio troppe metriche che in realtà non sono importanti per i clienti.

Crea un piano dettagliato per il ripristino di emergenza

Cosa farai se dovesse verificarsi un tempo di inattività? Se non conosci già la risposta a questa domanda, la risposta predefinita sarà questa: "Perdere tempo prezioso per capire cosa fare".

Quanto migliore è il tuo piano di risposta agli imprevisti, tanto più rapidi ed efficaci saranno i tuoi team nella gestione degli imprevisti. Ecco perché il primo passo di ogni nuovo programma di gestione degli imprevisti dovrebbe essere il processo e la pianificazione.

A chi servono gli SLI?

Qualsiasi azienda che misuri le proprie prestazioni rispetto agli SLO ha bisogno di SLI per effettuare tali misurazioni. Non è possibile avere degli SLO senza gli SLI.

Definisci gli SLA in base alle aspettative dei clienti

Ogni parte del contratto con il cliente dovrebbe essere definita in base a ciò che è importante per il cliente. Alla fine del processo, un imprevisto può comportare la gestione di 10 componenti diversi, ma dal punto di vista del cliente, tutto ciò che conta è che il sistema funzioni secondo le aspettative.

Gli SLA e gli SLO dovrebbero riflettere questa realtà. Non complicare troppo le cose con un eccessivo livello di dettaglio e con promesse definite per ciascuno dei 10 componenti. Limita le promesse alle funzionalità generali rivolte agli utenti. In questo modo i clienti saranno più soddisfatti e meno confusi, e renderai più semplice la vita dei professionisti IT che hanno la responsabilità di mantenere le promesse degli SLA.

Usa un linguaggio semplice negli SLA

I clienti non sempre chiedono chiarimenti, quindi se il linguaggio che utilizzi negli SLA è complicato, probabilmente stai preparando il terreno per dolorosi malintesi in futuro. Più il linguaggio utilizzato è semplice, minore è la probabilità che si verifichi un conflitto con i clienti in futuro.

Con gli SLO, meno è meglio

Non tutte le metriche sono fondamentali per il successo dei clienti, il che significa che non occorre che ogni metrica sia uno SLO. Impegnati a rispettare il minor numero possibile di SLO e concentrati su quelli più importanti per i clienti.

Non tutte le metriche monitorabili devono essere SLI

Allo stesso modo, il monitoraggio delle prestazioni su 10 componenti per ciascuno dei 10 SLO può rapidamente diventare complicato. Invece, scegli in modo strategico le metriche che sono effettivamente importanti per gli SLO principali e impiega le tue energie per monitorarle efficacemente.

Includi fattori esterni al controllo del team IT

Cosa succede quando è il cliente a rallentare il tempo di risoluzione? Se questo aspetto non è trattato in modo chiaro nello SLA, il team potrebbe essere costretto a rispettare uno standard impossibile di risoluzione dei problemi del cliente senza che il cliente stesso debba muovere un dito.

Includi un budget di errore

Lasciarsi un margine di errore non solo protegge l'azienda dalle violazioni degli SLA e da pesanti conseguenze, ma lascia anche spazio all'agilità, perché consente al team di apportare modifiche rapidamente e di provare soluzioni innovative che potrebbero rivelarsi inefficaci.

Google consiglia in realtà di utilizzare il budget di errore per il tempo di inattività pianificato, in modo da identificare i problemi imprevisti (ad es. servizi che utilizzano i server in modo inappropriato) e a mantenere aspettative adeguate nei confronti dei tuoi clienti.

Non puntare alla luna

Il fatto che il tuo team sia probabilmente in grado di mantenere un tempo di attività del 99,99% non significa che il tuo SLO debba essere del 99,99%. È sempre meglio promettere meno e fare di più. Questo vale soprattutto per i team Agile che desiderano effettuare lanci tempestivi e frequenti, e hanno bisogno di un budget di errore per mantenere un ritmo così rapido.

Qual è l'impatto sugli SRE?

Per chi segue il modello di Google e utilizza i team di Site Reliability Engineering (SRE) per colmare il divario tra sviluppo e operazioni, gli SLA, gli SLO e gli SLI sono fondamentali per il successo. Gli SLA aiutano i team a stabilire limiti e budget di errore, gli SLO aiutano a definire le priorità del lavoro e gli SLI indicano ai SRE quando bloccare tutti i lanci per risparmiare un budget di errore a rischio e quando possono allentare le redini.

Rimani aggiornato sugli SLA per risolvere le richieste in base alle priorità e utilizza regole di escalation automatizzate per informare i membri del team di competenza e prevenire le violazioni degli SLA con Jira Service Management.