Tempo medio di risoluzione (MTTR): come ridurlo nel modo giusto

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:

1. È 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.
2. È 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:

1. Rilevamento proattivo delle anomalie, rapida risposta e soluzione degli incidenti, nonché workflow efficaci che accelerano il procedimento risolutivo.
2. 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.
3. 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:

1. Rappresenta un rischio elevato per l'azienda. L'incidente ha un impatto diretto o indiretto sui clienti.
2. È 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.
3. 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.

Come minimo, i team devono disporre di una chiara politica di escalation che illustri che cosa fare in caso di guasto: chi chiamare, come documentare l'accaduto e come iniziare la procedura di soluzione del problema.

Molte organizzazioni scelgono una delle tre strategie di gestione più comuni:

1. Ad hoc. Le aziende più recenti e di piccole dimensioni generalmente usano questo approccio: quando si verifica un incidente, il team individua la persona in possesso delle giuste competenze e le assegna le risorse per risolvere il problema. Non c'è una struttura specifica, e questa è appunto l'essenza di questo metodo.
2. Rigida. Questo è l'approccio tradizionale alla information technology systems management (ITSM), spesso adottato da grandi società, organizzate in modo convenzionale. In genere, in questo tipo di struttura il reparto IT è a capo della gestione dell'incidente. La gestione del cambiamento è di importanza fondamentale e i team devono seguire procedure e protocolli molto rigorosi. In questo caso, la struttura non è un onere ma un vantaggio.
3. Fluida. Questo è l'approccio scelto da molte aziende moderne, specialmente quelle che hanno attuato una trasformazione digitale. Le risposte si basano sulla specificità di ogni singolo incidente e prevedono alti livelli di collaborazione interfunzionale e formazione per risolvere i problemi in modo più efficiente. Questo approccio si ispira ai principi Lean di costante sperimentazione e apprendimento, quindi le procedure di gestione si evolvono continuamente nel tempo.

L'approccio fluido è quello generalmente preferito dalle moderne aziende di software, a meno che non vi sia una ragione specifica per l'uso del modello rigido o di quello ad hoc. Una procedura fluida di gestione degli incidenti permette alle imprese di radunare le risorse giuste e i membri del team con le competenze più adatte ad affrontare situazioni in cui è spesso difficile determinare inizialmente ciò che sta accadendo e quali capacità sono necessarie per risolvere il problema.

Inoltre, man mano che i team analizzano l'incidente, l'approccio fluido rende più semplice la formulazione di soluzioni creative per problemi nuovi e complessi.

New Relic designa una persona a capo di tutte le fasi della procedura di gestione degli incidenti, che agisce da punto centralizzato di leadership durante il disservizio e aiuta i team a prendere le necessarie decisioni. Questa persona ha la responsabilità di coordinare sia i protocolli tecnici che le comunicazioni (queste ultime comportano interazioni con i clienti per raccogliere informazioni e divulgare aggiornamenti riguardanti l'incidente e la relativa risposta). Il coordinatore si assicura che le persone pertinenti siano al corrente del problema.

In alcune aziende questo ruolo viene assegnato in pianta stabile al dipendente, mentre in altre esiste una rotazione all'interno del personale. In New Relic, ogni membro dello staff tecnico può essere il coordinatore della gestione degli incidenti in quanto il primo a rispondere a un avviso di disservizio nei confronti dei clienti generalmente assume il ruolo di leader.

Ogni incidente può anche richiedere un responsabile tecnico e un responsabile delle comunicazioni, ed entrambi riferiscono al coordinatore. Generalmente, è il responsabile tecnico, non il coordinatore, a definire la risposta tecnica specifica per un dato incidente. In alcuni casi, possono essere necessari più responsabili tecnici, in base al numero di sistemi coinvolti. Queste persone devono conoscere a fondo i sistemi compromessi dall'incidente e devono avere la facoltà di prendere decisioni informate e valutare le possibili soluzioni, per una risoluzione rapida e per ottimizzare l'MTTR del team.

Il responsabile delle comunicazioni in genere è un membro del servizio clienti. È in grado di comprendere il probabile impatto sui clienti e condivide queste informazioni con il coordinatore. Allo stesso tempo, decide il miglior modo per informare i clienti degli sforzi messi in campo per risolvere il problema.

Per massimizzare i benefici del modello fluido, è importante investire in iniziative di addestramento dei tecnici, in modo che possano assumere ruoli e funzioni differenti nell'ambito della gestione degli incidenti. C'è sempre bisogno di specialisti di sistemi e tecnologie particolari, ma fare troppo affidamento su pochi individui può avere conseguenze negative, come «burnout» e ricambio del personale. Tutti i membri del team devono sviluppare competenze sufficienti per affrontare la maggior parte dei problemi, lasciando che gli specialisti si concentrino sugli incidenti più difficoltosi e urgenti. Dei protocolli esaurienti (v. prassi ottimale n. 7) possono essere un'ottima risorsa per raccogliere e divulgare conoscenze tecniche specialistiche all'interno del team.

L'addestramento multidisciplinare e il trasferimento di conoscenze aiutano anche a evitare uno dei peggiori rischi insiti nella gestione degli incidenti, ossia le situazioni in cui una persona è l'unica fonte di conoscenza per un sistema o una tecnologia particolare. Se questa persona è in ferie o lascia l'azienda all'improvviso, sistemi critici possono trasformarsi in scatole nere che nessuno nel team ha le competenze per aprire.

È quindi consigliabile che l'azienda valuti il proprio personale tecnico, misuri il suo livello di dipendenza da specifici individui e metta in atto delle ridondanze che eliminino questi intoppi, proprio come si fa per le risorse di sistema.

È ovvio che non si può riparare una cosa se non si sa che è rotta. Pertanto, il giusto livello di visibilità sulle applicazioni e sull'infrastruttura è essenziale per qualsiasi procedura di gestione degli incidenti.

Prendiamo l'esempio di un processo di rilevamento guasti senza dati di monitoraggio: un server che gestisce un database o un'applicazione essenziale si arresta e l'unico «dato»; disponibile per diagnosticare il problema è lo spegnimento della spia di alimentazione sulla parte anteriore del server. Il team di gestione è costretto a diagnosticare e risolvere il problema basandosi essenzialmente su supposizioni, portando a riparazioni lente e costose e quasi certamente a un MTTR inaccettabile.

Confrontiamo ora questo scenario con uno in cui utili dati di monitoraggio in tempo reale pervengono dall'applicazione, dal server e dall'infrastruttura collegata, offrendo al team un quadro accurato del carico del server, dell'utilizzo di memoria e spazio di archiviazione, dei tempi di risposta e di altre metriche. Il team può formulare una teoria riguardante la causa del problema e la soluzione basandosi su dati effettivi, piuttosto che su congetture.

Inoltre, i team possono usare i dati di monitoraggio per valutare gli effetti di una soluzione durante la sua implementazione e passare rapidamente dalla diagnosi alla soluzione dell'incidente. È una combinazione potente, che fa del monitoraggio forse l'elemento più importante per una procedura di soluzione degli incidenti efficiente ed efficace e per ridurre l'MTTR.

Negli ultimi anni è emersa una nuova serie di tecnologie che permette ai team di sfruttare le capacità dell'intelligenza artificiale (AI) e dell'apprendimento automatico (ML) per evitare gli incidenti e risolverli più rapidamente. Gartner ha coniato il termine “AIOps” (Artificial Intelligence for IT Operations, ossia intelligenza artificiale per le operazioni di tecnologia informatica) per descrivere questa categoria. L'AIOps si avvale di AI e ML per analizzare i dati generati dai sistemi software al fine di prevedere possibili problemi, determinarne le cause e applicare l'automazione per risolverli.

L'AIOps è un elemento complementare alle pratiche di monitoraggio in quanto fornisce informazioni sull'incidente di pari passo con i dati di telemetria. Usando tali informazioni per analizzare i dati e intraprendere le azioni necessarie, l'azienda sarà meglio preparata a rilevare e risolvere i disservizi. I team DevOps e SRE altamente performanti usano le capacità dell'AIOps per rispondere agli incidenti rapidamente e aumentare il tempo medio tra un guasto e il successivo.

L'AIOps può aiutare principalmente in quattro modi:

1. Rilevamento proattivo delle anomalie, prima di compromettere la produzione, l'esperienza clienti e gli obiettivi del livello di servizio (SLO).
2. Riduzione delle interferenze per aiutare i team a gestire gli avvisi con la giusta priorità e a focalizzarsi sui problemi più pressanti, individuando le correlazioni tra gli incidenti e potenziando le analisi con metadati e altro contesto.
3. Sistema di allertamento ed escalation intelligente per assegnare automaticamente gli incidenti agli individui e ai team meglio attrezzati per risolverli.
4. Correzione automatizzata degli incidenti, che include workflow per risolvere gli incidenti nel momento in cui si verificano e per ridurre l'MTTR.

Con tutti gli strumenti di monitoraggio disponibili al giorno d'oggi, è possibile che si abbiano troppe informazioni riguardanti i sistemi aziendali, il che rende difficile lo sviluppo di un piano per l'utilizzo dei dati. È in questi casi che diventa essenziale un sistema di allertamento programmatico.

Un primo passo pratico consiste nell'impostare gli avvisi in forma di soglie per gli indicatori del livello di servizio (SLI). Si tratta semplici metriche o soglie che possono essere osservate con strumenti di monitoraggio automatici e che indicano la possibilità o l'imminenza di un grave problema. Si può definire che se la resa scende al di sotto di una certa soglia, significa che qualcosa sta andando storto nel sistema. Oppure che se si verifica un picco di latenza per un certo intervallo di tempo, è necessario intervenire. Si tratta essenzialmente di metodi per quantificare la salute del sistema.

Ad esempio, anche se i membri del team non conoscono i dettagli di un database per i clienti, più a valle nel sistema, possono comunque monitorarne le soglie e scoprire che sta per verificarsi un problema. Quando un sistema raggiunge una soglia SLI, può notificare i tecnici in merito a un potenziale incidente prima che l'azienda sia inondata di chiamate e tweet dei clienti. Bisogna solo assicurarsi di tarare le soglie di avviso in modo consono per evitare i falsi allarmi: non piace a nessuno essere svegliati nel mezzo della notte se non è assolutamente necessario.

Inoltre è consigliabile scegliere uno strumento di allertamento che offra regole di silenziamento, al fine di avere maggiore controllo sugli avvisi e sopprimere le notifiche durante noti periodi di inattività, come la manutenzione dei sistemi, le installazioni, le operazioni di testing.

Man mano che si sviluppano le procedure di gestione degli incidenti e le prassi di monitoraggio e allertamento, è essenziale documentare tutto nel dettaglio. Queste note possono poi essere usate per creare dei «protocolli», ossia documentazione che indichi agli addetti di turno che cosa fare esattamente quando si verifica un problema specifico.

I protocolli permetteranno di raccogliere le conoscenze del team in merito a specifici incidenti e le relative risposte. Oltre a contribuire alla riduzione dell'MTTR, saranno utili per la formazione di nuovo personale, in particolar modo quando importanti membri del team lasciano l'organizzazione.

Bisogna tenere presente che nessun protocollo può coprire tutti i possibili scenari, né fornire una "ricetta" per risolvere tutti i problemi. Le variabili e le eccezioni sono troppe per poter tener conto di tutte le possibilità. Si tratta di usare i protocolli come punto di inizio, risparmiando tempo ed energie nella gestione di problemi noti e consentendo al team di concentrarsi sugli aspetti più complessi e singolari di un problema.

Si può chiamarla analisi retrospettiva, retrodiagnosi o analisi del giorno dopo: la riduzione dell'MTTR richiede un'efficace procedura di revisione degli incidenti. In altre parole, si indaga sull'accaduto, si scopre come si è verificato e si identificano gli eventi scatenanti e le cause probabili, quindi si ipotizzano le strategie per evitare che il problema si ripresenti.

Oltre a condurre un esame retrospettivo senza puntare il dito su nessuna persona coinvolta, è consigliabile anche stabilire una procedura di prevenzione futura. Tale modello comporta l'arresto del servizio coinvolto nell'incidente fino alla correzione o alla mitigazione delle cause. Inoltre, rafforza l'impegno verso la soluzione dei problemi anziché accettare rimedi a breve termine, aiutando i team a prendersi la responsabilità di seguire fino in fondo la procedura di gestione degli incidenti. È un modo per ricordare a tutti che la qualità è un obbligo, non un'opzione.

Chaos engineering è la pratica secondo cui si tenta di iniettare una turbolenza nei sistemi aziendali, in modo casuale ma assolutamente controllato, per testarne la resilienza. Si può usare il chaos engineering per rispondere a domande cruciali come:

• Il fallimento del sistema è avvenuto nel modo previsto?
• È stato possibile risolverlo prontamente?
• Che cosa hanno evidenziato i dati di monitoraggio?
• Dopo quanto tempo il servizio è stato ripristinato?

Il chaos engineering può portare beneficio all'organizzazione in molti modi. Innanzitutto, i team possono individuare le opportunità per rendere i sistemi più disponibili e più resilienti. Gli esperimenti di chaos engineering possono anche essere una sorta di prova generale per la gestione degli incidenti, permettendo di testare procedure, escalation, politiche, monitoraggio, allertamento e altri elementi. Rimuovendo l'attrito dalle situazioni di effettiva gestione degli incidenti, queste prove possono avere un impatto diretto sulle prestazioni dell'MTTR.

Nel momento dell'emergenza, si può avere la tentazione di prendere scorciatoie per ridurre l'MTTR con rapidità e semplicità, ma spesso in modo illusorio. L'MTTR è una media che include i tempi di risposta a tutti gli incidenti. Il rimedio raffazzonato di oggi può essere l'origine di un grosso problema futuro, assolutamente prevenibile. Bisogna quindi affrontare di petto le cause del disservizio di oggi per evitare che provochino danni maggiori in un secondo momento.

Le 10 prassi ottimali qui illustrate possono aiutare ad adottare un approccio all'MTTR basato sui principi di gestione degli incidenti e sulla disponibilità. La piattaforma di osservabilità New Relic può essere una componente chiave del successo di un tale approccio.

La piattaforma New Relic offre monitoraggio, AIOps, allertamento, diagnosi degli incidenti e altre funzionalità che contribuiscono direttamente a una gestione degli incidenti più rapida, più intelligente e più efficiente, portando a significativi miglioramenti dell'MTTR e di altre metriche delle prestazioni.

Le nostre esaurienti funzioni AIOps, che chiamiamo New Relic AI, forniscono al team le informazioni e le automazioni necessarie per trovare, analizzare e risolvere i problemi più rapidamente. New Relic AI potenzia le procedure di rilevamento, evidenziando automaticamente le anomalie dei vari strumenti dello stack tecnologico e suggerendo azioni per monitorare condizioni simili nel futuro. Inoltre, New Relic AI può fornire informazioni sulle anomalie via Slack, permettendo di valutare in modo rapido e collaborativo i potenziali problemi.

Ma non ci limitiamo a rilevare gli incidenti. New Relic AI sopprime in modo intelligente gli avvisi trascurabili, mettendo a frutto le conoscenze degli standard del settore in abbinamento ai dati aziendali e al feedback del team. New Relic AI individua le correlazioni tra gli incidenti e potenzia le analisi con utili metadati e altro contesto, per arrivare più rapidamente a una diagnosi. Inoltre, offre preziose informazioni sui problemi esistenti, includendone una classificazione in base ai «quattro segnali d'oro» (latenza, traffico, errori e saturazione) e in base a problemi correlati in altri punti dell'ambiente operativo. Infine, New Relic AI può anche suggerire quali membri del team hanno le competenze più idonee per gestire un particolare incidente, riducendo così il numero di avvisi inviati inutilmente ad altre persone.

I team operativi possono avvalersi di New Relic Synthetics per colmare una lacuna critica per molti team DevOps, ovvero il monitoraggio e l'analisi del comportamento del sistema end-to-end. Synthetics offre alle organizzazioni una gamma di opzioni per misurare le prestazioni, dall'invio di un semplice comando di ping al monitoraggio dettagliato che esegue script per simulare complessi scenari. Synthetics supporta inoltre l'uso di CPM (containerized private minion) per monitorare siti interni ed espandere la copertura geografica, elevando i livelli di sicurezza, compatibilità al cloud e flessibilità.

In molti casi, la soluzione rapida ed efficace degli incidenti richiede l'abilità di vedere la prospettiva degli utenti, ad esempio per valutare l'impatto delle interazioni degli utenti o le conseguenze dell'incidente sull'esperienza utente. New Relic Browser permette di conseguire questo obiettivo offrendo ampia visibilità e informazioni dettagliate sul modo in cui gli utenti interagiscono con un'applicazione o un sito web. Browser va oltre l'analisi dei tempi di caricamento delle pagine, analizzandone l'intero ciclo di vita, dalle prestazioni delle singole sessioni alle richieste AJAX, dagli errori JavaScript al monitoraggio delle architetture di applicazioni a pagina singola.

Browser, inoltre, aiuta i tecnici a comprendere il ruolo del fattore geografico nell'ambito dell'incidente, ad esempio filtrando le metriche prestazionali e i punteggi Apdex per regione o stato, mantenendo whitelist di segmenti di URL e bloccando o monitorando domini specifici.

Infine, New Relic aiuta le organizzazioni a gestire la crescente complessità dei moderni ambienti di microservizi distribuiti. La complessità è il prezzo da pagare per beneficiare dei vantaggi dei microservizi, ma è anche la principale barriera alla creazione di un processo di gestione degli incidenti che sia rapido ed efficiente.

La funzione New Relic Kubernetes Cluster Explorer è il perfetto esempio di come New Relic contribuisca a fornire ai team chiarezza e visibilità di sistemi altamente complessi, anche su ampia scala. Kubernetes Cluster Explorer offre una rappresentazione multidimensionale di un cluster Kubernetes che consente di zoomare in namespace, distribuzioni, nodi, pod, contenitori e applicazioni. Cluster Explorer permette di reperire facilmente i dati e i metadati di questi elementi e di comprenderne le correlazioni, grazie a strumenti di visualizzazione altamente intuitivi.

Inoltre, passando con facilità tra le viste di alto livello e quelle di massimo dettaglio, Kubernetes Cluster Explorer presenta a ogni persona coinvolta nella procedura un singolo punto di riferimento condiviso per la ricerca dei problemi e l'analisi della salute del cluster. Questo può accelerare la soluzione mettendo tutti al corrente della situazione ed eliminando malintesi e inutili atteggiamenti accusatori.

Anche le funzioni di distributed tracing in New Relic APM aiutano a ridurre le complessità – in questo caso, si tratta dei problemi che sorgono nel tracciamento delle cause di un'eventuale latenza e di altri rallentamenti prestazionali nelle architetture con applicazioni distribuite.

Il distributed tracing permette al team di tracciare il percorso di una richiesta in un sistema complesso, rivela la latenza dei componenti lungo tale percorso e mostra quale componente sta creando il rallentamento. Il distributed tracing si avvale anche dell'intelligenza incorporata nella piattaforma New Relic, grazie a strumenti come il rilevamento di span anomali, i grafici di tracciatura e le query personalizzate dei dati di distributed tracing per contribuire a isolare, diagnosticare e risolvere i problemi rapidamente e con sicurezza.

La scelta del giusto approccio verso l'MTTR può essere un compito complesso e difficile. Questa è la realtà delle moderne architetture applicative. Ma con tutte queste funzionalità (e molte altre), la piattaforma New Relic è uno strumento essenziale per aiutare a implementare una procedura di gestione degli incidenti più rapida, uniforme e affidabile

Per finire, bisogna tenere a mente che l'MTTR è importante, ma non è l'unica metrica per misurare la risposta agli incidenti. È ovvio che l'obiettivo è ridurre al minimo il tempo di soluzione, ma non è saggio dedicare una quantità smisurata di ore alla sua ottimizzazione mentre ci si focalizza troppo sui risultati a breve termine.

Piuttosto, può essere vantaggioso implementare strumenti come New Relic che offrono un flusso continuo di dati in tempo reale, coordinati con politiche di allertamento attentamente calibrate, per poi usare tali strumenti a sostegno di una robusta procedura di gestione degli incidenti. Questa è la formula migliore per risolvere incidenti in modo sistematico ed efficiente. È anche il modo ideale per migliorare continuamente gli sforzi volti a ridurre l'MTTR, ossia massimizzare in modo sostenibile a lungo termine la disponibilità delle applicazioni.