In un precedente approfondimento di InternetPost avevamo chiarito la differenza tra i concetti di scalabilità ed alta disponibilità, precisando quale dei due fosse correttamente perseguibile utilizzando servizi cloud computing. Nel post di oggi ci focalizzeremo sul solo concetto di disponibilità (availability) partendo dalla classica definizione fino all’approccio consigliato per calcolare le soglie ideali per il vostro caso di utilizzo. Buona lettura.
Che cos’è esattamente la disponibilità di un servizio? Secondo Google, fonte del post odierno (il link è disponibile come sempre a fondo pagina), la disponibilità è una delle chiavi del successo di una compagnia perchè definisce se un sistema X, in un determinato momento Y, sia in grado o meno di portare a termine il compito per il quale è stato progettato.
Le storico dati sulla disponibilità è un utile strumento per le aziende perchè può mostrare preziose informazioni – come ad esempio la percentuale di affidabilità che un sistema potrebbe avere nell’immediato futuro. Si giunge così alla parte più delicata del discorso, ovvero alla misurazione del livello di disponibilità, atto imprenscindibile in base al quale trarre le successive valutazioni.
Sebbene per il calcolo della disponibilità possano essere presi in considerazioni vari fattori (numero di richieste soddisfatte, intervallo di tempo totale in cui il servizio non è stato utilizzabile etc), la struttura della formula da adoperare resta sempre la stessa, osservano gli esperti Google: “valori positivi / somma totale dei valori” quindi “uptime / (uptime+downtime)” o ancora “numero di richieste soddisfatte / (richieste soddisfatte+richieste non soddisfatte )” e così via. Indipendentemente dai fattori considerati, otterremo una percentuale alla quale ci si riferisce solitamente con le espressioni “three nines” (99,9%) e “five nines” (99,999%), valori che dovrebbero essere familiari agli hosting provider ed ai clienti che leggono attentamente i Service Level Agreement o SLA – compagnie come Google ed Amazon hanno i mezzi per puntare a percentuali elevatissime di disponibilità.
Con il termine “error budget” ci si riferisce solitamente all’obiettivo di alta disponibilità da perseguire: focalizzando l’attenzione sugli elementi di insuccesso dell’equazione precedente (downtime, richieste non soddisfatte) ed applicandovi una determinata metrica (es: su base temporale ovvero una soglia da rispettare in un determinato periodo di tempo) è possibile fissare un traguardo. Se un hosting provider punta ad esempio al 99,9% su base mensile (30 giorni = 43200 minuti) dovrà impegnarsi a non superare i 43,2 minuti di downtime nell’arco di 30 giorni.
Mean Time Between Failures e Mean Time To Repair
Per valutare in maniera più accurata possibile l’error budget, prosegue Google, è opportuno inserire nell’equazione menzionata il Mean Time Between Failures (MTBF) ed il Mean Time To Repair (MTTR):
- il primo è ricavabile dalla formula “total uptime / # of failures” e indica l’intervallo di tempo tra un situazione critica (failure) e l’altra;
- il secondo è ricavabile dalla formula “total downtime / # of failures” e indica l’intervallo di tempo necessario per riprendere il normale svolgimento delle operazioni in seguito ad un evento critico.
Grazie all’MTBF ed all’MTTR è possibile stabilire in modo più efficace e con cognizione di causa determinati obiettivi di disponibilità. Applicando ad esempio la formula (total period / MTBF) * MTTR è possibile ottenere un determinato valore di downtime importante per valutare al meglio le priorità operative.
Al valore numerico ottenuto vanno tuttavia associati anche altri fattori, in modo da non ridurre l’intera operazione ad un mero calcolo matematico. Sebbene fino ad ora si sia parlato quasi esclusivamente di formule, la disponibilità deve necessariamente tenere conto dell’esperienza di utilizzo offerta ai clienti/visitatori, meglio nota come user experience. E’ proprio in relazione a quest’ultima che è possibile definire le massime soglie consentite di downtime, frequenza e durata degli eventi critici (failure).
Disponibilità: calcolo ed individuazione di un obiettivo in base all’user experience
Nell’esempio presentato da Google, un dipendente viene incaricato di determinare l’obiettivo di availability da perseguire: il dipendente calcola la soglia ideale rapportando la percentuale di status code HTTP “OK 200” con il numero totale di richieste ricevute dal sito. Dopo aver consegnato il rapporto emergono tuttavia i primi problemi: nel forum dedicato al supporto clienti si leggono diverse lamentele da parte dei visitatori che affermano di non aver ricevuto alcun risultato interpellando il servizio messo a disposizione dall’azienda. Il dipendente, sottolinea Google, ha commesso il classico errore di “basare la propria definizione di disponibilità su misurazioni che non corrispondono alle aspettative degli utenti o agli obiettivi dell’azienda.”
Se la percentuale di richieste con codice “OK 200” non è il metro di paragone ideale per definire l’obiettivo, su cosa dovrebbe allora basarsi la valutazione del dipendente? L’azienda avvia un’accurata indagine affidandosi ai feedback degli utenti che porta a determinare quali siano le loro reali aspettative: il sistema è considerato disponibile da un utente quando dopo aver inoltrato una richiesta sul portale dell’azienda viene restituito, nel 100% dei casi ed entro 5 secondi, un risultato. Il dipendente impiega un’altra settimana per valutare se il servizio offerto rispetti o meno tali requisiti scoprendo che solo l’80% delle query è idoneo.
I vertici aziendali ed il dipendente capiscono di non essere in grado di soddisfare il 100% delle richieste. In base agli obiettivi finanziari annuali, una percentuale dell’80% consentirebbe in ogni caso di rispettare i vincoli di bilancio con un sufficiente margine (guadagno ottenuto da ciascuna query inoltrata * percentuale di query soddisfatte). Una percentuale di richieste non soddisfatte pari al 20% è tuttavia un valore abbastanza alto che non andrebbe trascurato – che offre un’esperienza di utilizzo discontinua all’utenza. Il dubbio dell’azienda è allora il seguente: dobbiamo fare in modo che questa percentuale diminuisca? E se si, come dobbiamo rivalutare i nostri obiettivi di disponibilità?
Benefici e costi d’opportunità
Ipotizziamo che l’azienda fittizia della quale si è parlato fino ad ora decida di innalzare dello 0,5% la percentuale di availability: tale scelta potrebbe essere stata dettata da un semplice confronto tra il budget da impiegare per il compimento di tale operazione (costo dell’operazione e tempo totale necessario, ad esempio 6 mesi) e l’ammontare di entrate perse nell’arco dell’intero periodo di distribuzione del servizio (percentuale di utenti che dopo non aver ricevuto alcuna risposta abbandonano il portale). Se il secondo valore risulta superiore al primo, concluderanno i vertici aziendali, perchè non procedere al miglioramento dell’availability?
Niente di più sbagliato dice Google: l’equazione non tiene conto di un altro fattore, ovvero i costi di opportunità. Di cosa si tratta esattamente? In sintesi di una task che potrebbe essere svolta al posto di quella destinata all’innalzamento della percentuale di availability, ad esempio la messa in produzione di un algoritmo in grado di innalzare il traffico in entrata e di conseguenza le entrate annuali.
Tirando le somme, stabilire realistici obiettivi di availability è un compito delicato che nasconde numerose insidie. Google stabilisce ad esempio il proprio target di availability partendo da una determinato obiettivo numerico (es: 99,9%) al quale però seguono processi di ottimizzazione volti ad agevolare immancabili operazioni di intervento rapido (“fast fix”).
Sono i site reliability engineer a fare allora la differenza in quanto in grado di mitigare e risolvere nell’arco di pochi minuti inaspettati problemi che possono impattare sensibilmente sull’user experience. Oltre a garantire agli ingegneri un’elevata rapidità di deploying, tale approccio consolida/rafforza allo stesso tempo la reputazione di Google.