SLA: quali metriche utilizzare?

Nel definire i Service Level Agreement (SLA), potenzialmente si può concordare qualsiasi metrica, facendo attenzione a non farsi prendere la mano ed esagerare. Anche la probabilità che un fulmine colpisca il nostro portatile non è pari a zero, ma non per questo lo assicuriamo contro gli eventi naturali.

Citiamo alcuni esempi al solo scopo di evidenziare quanto possano essere diverse le esigenze.

1) Monitoraggio di SLA prestazionali
Facili da incontrare per servizi di connettività e di rete, più difficili da definire sui layer applicativi:
che il checkout di un e-commerce avvenga sempre e con un tempo di caricamento inferiore ad 1 secondo è complicato da definire, monitorare e garantire perché dipende da molteplici fattori, banalmente oltre che dalla parte infrastrutturale è un valore che dipende dalla parte applicativa (e quindi dall’operato del cliente) e dal numero di utenti connessi al sito in ogni istante (quindi valori poco controllabili).

ll monitoraggio di SLA prestazionali applicativi è comunque importante, perché consente di definire con il cliente un obiettivo comune più funzionale al reale servizio rispetto a singole metriche specifiche ma avulse dal servizio; inoltre rappresenta un modo per prevenire possibili anomalie tecniche e applicative, che potrebbero causare disservizi più gravi per l’utente finale. Sotto questo profilo, si parla di monitoraggio in tempo reale degli SLA, la cui gestione implica il ricorso a sistemi di alerting in grado di segnalare il verificarsi di problemi durante l’erogazione del servizio.

2) RTO (recovery time objective)

L’RTO è il tempo necessario per il pieno recupero dell’operatività di un sistema o di un processo, è in pratica la massima durata, prevista o tollerata per un disservizio.

E’ evidente come questo parametro differisca da un normale SLA di uptime, perché un cliente potrebbe accettare 4 ore di down nell’arco di un anno, ma non potersi permettere mai più di 5 minuti di disservizio continuativo in una determinata fascia oraria (ad esempio perché deve gestire del trading online o delle scommesse in real time).

3) RPO (Recovery Point Objective)

L’RPO è uno dei parametri usati in ambito di disaster recovery; rappresenta il massimo tempo che deve intercorrere tra la produzione di un dato e la sua messa in sicurezza ad esempio attraverso backup; conseguentemente, fornisce la misura della massima quantità di dati che il sistema può perdere a causa di guasto improvviso.

Anche in questo caso è chiaro come uno SLA relativo alla ridondanza dei dati su sistemi RAID  garantisca in termini di probabilità che una perdita di dati non avvenga praticamente mai (se non ad esempio una volta ogni 250 anni), ma nel caso in cui lo sfortunato evento si verifichi non mi mette al riparo da perdita di dati rispetto all’ultimo backup disponibile.

Al diminuire dell’RPO desiderato si rendono necessarie politiche di sicurezza sempre più stringenti e dispendiose fino ad arrivare a replicazione pressoché immediata di dati presso diversi data center (che è quanto ad esempio effettuato per dati di tipo bancario).

4) SLA Uptime/availability 

E’ come già evidenziato la metrica più usata in ambito hosting, il valore % usato definisce la % di tempo in cui il servizio (solitamente di basso livello, ovvero infrastruttura hardware e di rete) è disponibile.
E’ interessante evidenziate (vedi tabella sottostante) cosa rappresenti invece in termini di tempo il valore residuo in cui i servizi possono essere offline.
I valori sono evidenziati in termini giornalieri/settimanali/mensili e annuali, in quanto negli accordi di SLA è importante definire il range temporale da prendere in considerazione e che si azzera ad ogni ciclo.

Per fare un esempio esemplificatore, se un fornitore ha un unico disservizio in un anno che comporta 4h di down

In caso di SLA 99,9% giornaliero – uscirà dallo SLA per circa 240 minuti
In caso di SLA 99,9% settimanale – uscirà dallo SLA per circa 230 minuti
In caso di SLA 99,9% mensile – uscirà dallo SLA per circa 200 minuti
In caso di SLA 99,9% annuale – lo SLA sarà comunque rispettato dal fornitore

Gli agreement solitamente sono effettuati con cadenza mensile, ma attenzione ad eventuali SLA annuali a chiaro vantaggio del fornitore.

SLA	DAILY	WEEKLY	MONTHLY	YEARLY
99%;	14m 24.0s	1h 40m 48.0s	7h 18m 17.5s	3d 15h 39m 29.5s
99,5%	7m 12.0s	50m 24.0s	3h 39m 8.7s	1d 19h 49m 44.8s
99,9%	1m 26.4s	10m 4.8s	43m 49.7s	8h 45m 57.0s
99,95%	43.2s	5m 2.4s	21m 54.9s	4h 22m 58.5s
99,99%	8.6s	1m 0.5s	4m 23.0s	52m 35.7s
99,999%	0.9s	6.0s	26.3s	5m 15.6s