Introduzione Il tempo medio di soluzione (MTTR) è una delle metriche usate più comunemente per misurare l'affidabilità dei sistemi. Paradossalmente è anche una delle più fraintese. Molti sviluppatori e team operativi non sanno bene come definire l'MTTR, come usarlo e come migliorarlo in modo continuativo e sostenibile.
Poiché le moderne organizzazioni fanno sempre più affidamento al software per gestire le proprie attività, queste lacune riguardanti l'MTTR non rappresentano solo un inconveniente. Infatti, possono essere una minaccia per la redditività dell'azienda, compromettendo la sempre più importante esperienza digitale dei clienti, per non parlare degli ulteriori costi, rischi e complessità imposti sul processo di sviluppo del software.
La chiave per evitare questi problemi è adottare un approccio progressivo alla definizione e all'implementazione dell'MTTR, che abbini strumentazione e monitoraggio esaurienti, una procedura di gestione degli incidenti che sia robusta e affidabile, e un team in grado di comprendere come e perché usare l'MTTR per ottimizzare la disponibilità e le prestazioni delle applicazioni. A tal fine, New Relic ha raccolto 10 prassi ottimali per ridurre l'MTTR nel modo giusto, il tutto in un contesto di creazione di una sana strategia di risposta agli incidenti. Spiegheremo anche come la piattaforma New Relic supporta gli obiettivi di riduzione dell'MTTR del team DevOps in svariati modi di estrema importanza.
I molti significati dell'MTTR
Le complessità riguardanti l'MTTR iniziano dalla definizione del termine. Il suo significato originario, risalente all'era industriale, riportava alla manutenzione delle macchine: il tempo medio necessario per riparare un macchinario, un dispositivo o un'officina.
Nel mondo odierno definito dal software, MTTR generalmente sta per «tempo medio di ripristino» o «tempo medio di soluzione». La distinzione potrebbe apparire irrilevante, tuttavia, queste definizioni si focalizzano su risultati differenti e rispecchiano due approcci molto diversi per gestire i problemi prestazionali del software:
- Tempo medio di ripristino (a volte detto tempo medio di recovery) è l'equivalente digitale del tempo medio di riparazione, ossia il tempo necessario affinché un'applicazione riprenda la normale operatività dopo un problema di prestazioni o un'interruzione del servizio.
- Tempo medio di soluzione, d'altro canto, si focalizza su un quadro più completo, ossia riguarda il tempo necessario per risolvere un problema e implementare azioni successive di «clean up» o interventi proattivi finalizzati a impedire il ripresentarsi dello stesso inconveniente. Un team deve occuparsi di entrambi questi compiti prima di dichiarare risolto un problema.
Questa seconda definizione di MTTR, più completa, richiede l'abilità di trovare e risolvere le cause alla base dei problemi di prestazioni. Evita di proposito le soluzioni rapide che possono porre rimedio al problema nell'immediato, ma che non ne impediscono il verificarsi nel futuro.
L'MTTR è un dato statistico, non una pozione magica
Bisogna tenere a mente che l'MTTR è un valore statistico medio. Comprendendo come usarlo con efficacia se ne comprendono anche le limitazioni:
L'MTTR è più utile come metrica «chiavi in mano» quando gli incidenti (e le soluzioni) tendono a essere simili. Se accadono spesso incidenti atipici, i cui tempi di soluzione variano ampiamente da un caso all'altro, l'MTTR da solo può presentare una visione distorta delle vere capacità di risposta del team.
Analogamente, è facile dimenticare che l'MTTR non prende in considerazione il fattore temporale (il che può sorprendere). Il calcolo dell'MTTR non permette di rilevare, ad esempio, la differenza cruciale tra gli incidenti che influiscono sui sistemi e sulle applicazioni durante i picchi di utilizzo e gli incidenti che accadono nei momenti di calma.
Nessuno di questi fattori riduce il valore dell'MTTR, ma è importante tenere a mente gli svantaggi in cui si incorre affidandosi eccessivamente a una singola metrica.
Due prassi ottimali per l'utilizzo dell'MTTR sono particolarmente efficaci per ridurre al minimo questi rischi:
- È consigliabile usare l'MTTR in concomitanza con altre metriche per misurare in modo più completo, accurato e dettagliato le prestazioni dell'applicazione e dell'infrastruttura. A tal fine, una metrica di tipo «error budget»; può specificare, ad esempio, che un minuto durante i periodi di picco equivale a un'ora negli altri periodi. Usate assieme all'MTTR, le metriche di tipo «error-budget»; aiutano a comprendere il vero costo e impatto dell'inattività e quindi a valutare meglio il valore dei guadagni o delle perdite nelle tendenze dell’MTTR.
- È importante convalidare gli sforzi di riduzione dell'MTTR focalizzandosi sulla soluzione degli incidenti e sull'ottimizzazione della disponibilità. Come già accennato, rimediare a un disservizio riguardante un'applicazione significa trovarne le cause, individuando il servizio o il componente dell'infrastruttura alla base del guasto, per poi formulare una soluzione a lungo termine. Questo spesso si discosta considerevolmente dall'adozione di espedienti rapidi finalizzati a risolvere il problema nell'immediato, senza identificarne la vera origine o tutti i fattori che hanno contribuito all'incidente.
Il focus sulla disponibilità aiuta a trovare soluzioni durature e a lungo termine ai problemi prestazionali di un'applicazione. Inoltre, evidenzia la necessità di prevenire i disservizi ricorrenti e valutarne l'impatto sull'esperienza digitale dei clienti, anche se questo approccio sortisce soluzioni più costose che richiedono più tempo per l'implementazione rispetto ai rimedi a breve termine.
La chiave di una strategia di MTTR vincente è la gestione degli incidenti
Una volta comprese le regole fondamentali per un utilizzo saggio dell'MTTR, il passo successivo è scoprire come i moderni team DevOps possono migliorare i propri tempi di soluzione e consolidare i miglioramenti conseguiti.
Generalmente, i team DevOps necessitano di tre competenze di base:
- Rilevamento proattivo delle anomalie, rapida risposta e soluzione degli incidenti, nonché workflow efficaci che accelerano il procedimento risolutivo.
- Una fonte unificata di dati multidimensionali riguardanti la salute e le prestazioni delle applicazioni e dell'infrastruttura, che fornisca contesto per l'intero sistema software.
- L'impegno a spostare le priorità verso l'affidabilità del servizio a lungo termine, aumentando le probabilità che le soluzioni implementate risolvano i problemi definitivamente.
La tecnologia riveste un ruolo essenziale nel conseguimento di queste competenze, ma non è sufficiente. È necessaria una strategia che includa anche processi risolutivi consolidati e l'impiego dei talenti e delle capacità individuali dei membri del team.
La procedura di gestione degli incidenti rappresenta la convergenza di tutti questi fattori. Racchiude tutte le fasi della catena di eventi che inizia dalla scoperta del problema nelle prestazioni dell'applicazione o dell'infrastruttura e termina con l'apprendimento di tutto ciò che è necessario per evitare che l'incidente si ripeta nel futuro. Copre tutti gli aspetti di una solida strategia di riduzione dell'MTTR e garantisce che il team possa continuare a migliorare, anche in vista di un'espansione dell'azienda e delle sue applicazioni.
Le chiavi per creare una procedura di gestione degli incidenti di livello superiore
Una buona gestione degli incidenti inizia con questa domanda: che cos'è un incidente? La risposta è essenziale, in quanto la procedura di gestione scatta nel momento in cui viene rilevato un incidente. New Relic definisce incidente qualsiasi problema prestazionale di applicazioni o infrastrutture che soddisfa tre criteri:
- Rappresenta un rischio elevato per l'azienda. L'incidente ha un impatto diretto o indiretto sui clienti.
- È urgente. Deve essere risolto immediatamente. Durante un incidente, i team sono sotto pressione per trovare la soluzione il più rapidamente possibile e devono operare in modo diverso rispetto alle consuete attività giornaliere.
- Richiede collaborazione. Generalmente, gli incidenti di una certa portata richiedono la collaborazione di svariate persone, spesso impegnate in reparti diversi dell'azienda. Il coordinamento durante un evento pressante ad alto rischio richiede un particolare tipo di gestione e può implicare costi che devono essere considerati nel budget dei team.
Queste 10 prassi ottimali, basate sul modo in cui New Relic gestisce gli incidenti, sono state ideate per aiutare i team a ridurre il tempo medio di soluzione.