Gestione IT

Come minimizzare il tempo medio di soluzione degli inconvenienti

06 Ottobre 2014

Aumentare l'efficienza IT è un argomento sempre in cima all'elenco delle preoccupazioni delle aziende e degli MSP ogni volta che si parla di budget o strategie.
Parliamo adesso di come minimizzare il tempo medio di risoluzione dei problemi nel momento in cui essi avvengono e alla ricezione dei relativi ticket.




Il segreto è ridurre la variabilità dell'intervallo di tempo trascorso per risolvere i vari problemi


Più facile a dirsi che a farsi? Il processo di Mean Time to Repair/Resolve (MTTR) può essere suddiviso in quattro attività principali:

  1. consapevolezza: identificare l'esistenza di un inconveniente o di un problema;
  2. causa originale: comprendere la causa del problema, la cosiddetta root cause;
  3. rimedio: risolvere il problema;
  4. test: verificare che il problema sia stato effettivamente risolto.

Di queste quattro componenti, la consapevolezza, il rimedio e il test tendono a essere le attività minori e anche quelle meno variabili.  Il tempo richiesto per accorgersi di un problema dipende principalmente da quanto è sofisticato il sistema di monitoraggio.

Funzionalità complete, che tengano sotto controllo tutti gli aspetti dell'infrastruttura IT e ne raggruppino gli elementi in servizi, sono quelle che tendono a essere le più produttive.
La tecnica proattiva del Service Level Monitoring (SLM) permette di osservare i sistemi trasversalmente ai silos tradizionali (per esempio rete, server, applicazioni) e analizzare le tendenze prestazionali dei componenti sottostanti. Sviluppando analisi di tendenza in questo modo, la gestione SLM proattiva può identificare le problematiche future prima che possano verificarsi.

Per esempio, quando il traffico applicativo è in espansione e la bandwidth si avvicina alla saturazione, o quando lo storage di un server è prossimo al suo limite. Al verificarsi di problemi imprevisti, essere in grado di valutarne rapidamente la gravità, eliminare gli allarmi a valle e determinare l'impatto di business sono fattori altrettanto importanti per aiutare a contenere la variabilità e attivare le risorse corrette per il massimo impatto possibile.<
Identificare la causa originale è solitamente la ragione principale della variabilità MTTR ed è quella associata ai costi più elevati.
Ancora una volta la soluzione risiede nei tool che si adoperano e nei processi esistenti.
Spesso i tool di gestione sono selezionati da ciascuna funzione IT a seconda delle rispettive attività specifiche: il gruppo degli amministratori di rete ricercherà capacità approfondite per il monitoraggio della rete, il gruppo dei DBA vorrà strumenti capaci di ottimizzare le prestazioni dei database e così via.
Questi tool in genere non si integrano granché reciprocamente e non danno visibilità a livello dei servizi.
Inoltre ottenere una correlazione avvalendosi di strumenti separati richiede spesso moltissimo lavoro e la collaborazione tra esponenti dei vari gruppi IT cercando di evitare il consueto "scarica barile" delle responsabilità.
 La visione dei livelli di servizio è importante non solo perché fornisce visibilità sull'impatto in termini di business, ma anche perché rappresenta un livello di aggregazione dal quale è possibile avviare un'analisi della causa originale.
Molte organizzazioni IT iniziano avvalendosi di strumenti open source, rendendosi conto ben presto che nonostante siano gratuiti essi comportano un costo al crescere delle dimensioni e della complessità delle infrastrutture.
I tool rivolti a singoli aspetti infrastrutturali possono venire integrati ma, senza una logica sottostante, non sarà facile correlare i vari eventi e identificare con certezza una causa originale.
Negli ambienti più complessi, una cattiva diagnostica può essere controproducente tanto quanto l'assenza di diagnostica. Investigare gli allarmi inutili che scattano a valle del problema originale per escludere che abbiano cause differenti rappresenta un significativo spreco di risorse.
Consideriamo una causa frequentemente citata di variabilità MTTR come le cattive performance applicative

In questo caso non c'è nulla di specificamente "guasto", quindi è difficile diagnosticare il problema usando tool specifici.
Un cruscotto unificato che mostri sia le metriche dei processi applicativi sia le metriche di rete o dei pacchetti fornisce invece una visione utilissima dal punto di vista diagnostico.
Per fare un semplice esempio, un'applicazione di monitoraggio dei tempi di risposta applicativi potrebbe inviare un allarme indicando che il tempo di risposta di una certa applicazione è troppo elevato.
I dati del monitoraggio potrebbero segnalare la lentezza di risposta alle query da parte di un database a causa dell'inadeguatezza dei buffer e del numero insolitamente alto delle transazioni.
Integrando queste informazioni con i dati dei pacchetti o dei flussi di rete si potrebbe isolare immediatamente l'indirizzo IP del client responsabile del grande volume di query.
Questo livello di integrazione velocizza l'analisi della causa originale ed evita facilmente lo "scarica barile" delle responsabilità permettendo di identificare rapidamente l'azione ottimale per neutralizzare l'inconveniente.Una volta che il problema è stato identificato, è possibile risolvere gli ultimi due termini dell'equazione MTTR

Il tempo richiesto dalla soluzione e dal test tende a essere molto meno variabile e può essere abbreviato definendo chiaramente processi e responsabilità.
Anche l'automazione può giocare un ruolo chiave. Per esempio, moltissimi problemi nascono da configurazioni errate.
Il rollback delle configurazioni all'ultimo stato funzionante precedente può essere effettuato automaticamente così da eliminare velocemente i problemi mentre è in corso l'analisi approfondita della causa originale.

L'automazione può giocare un ruolo essenziale anche nei test per garantire che le prestazioni siano in linea con i relativi requisiti e che i livelli di servizio siano tornati normali.
Per massimizzare l'efficienza e l'efficacia IT e contribuire a minimizzare il valore MTTR, i sistemi di gestione IT non possono più funzionare in isolamento verticale od orizzontale.
L'interdipendenza tra servizi, applicazioni, server, servizi cloud e infrastruttura di rete impone l'adozione di capacità di gestione a livello di servizi da parte delle aziende che possiedono infrastrutture di servizi IT più complesse.
Il volume di dati generato da questi vari componenti è enorme e il ritmo di generazione talmente veloce che i tradizionali strumenti dedicati non possono né integrarsi né tenere il passo con alcun genere di correlazione in tempo reale.
(Tratto dal blog di Kaseya)

Autore
Claudio Panerai
Gli ultimi prodotti che vi ho portato, nel 2020: Vade Secure Il primo sistema antispam/antihishing/antimalware basato sull'intelligenza artificiale e appositamente progettato per Office 365. Naturalmente a misura di MSP. ID Agent Piaffaforma che consente agli MSP di monitorare le credenziali (proprie e dei clienti) che sono in vendita nel dark web.
Nato a Ivrea nel 1969, è sposato e padre di due figlie. Laureato in Scienze dell’Informazione nel 1993, ha dapprima svolto numerose consulenze e corsi di formazione per varie società per poi diventare responsabile IT per la filiale italiana del più grande editore mondiale di informatica, IDG Communications. Dal 2004 lavora in Achab dapprima come Responsabile del Supporto Tecnico per poi assumere dal 2008 la carica di Direttore Tecnico. Giornalista iscritto all’albo dei pubblicisti, dal 1992 pubblica regolarmente articoli su riviste di informatica e siti web di primo piano. E' stimato da colleghi e clienti per la schiettezza e onestà intellettuale. Passioni: viaggi, lettura, cinema, Formula 1, sviluppo personale, investimenti immobiliari, forex trading. Claudio è anche su LinkedIn e Facebook.
Commenti (0)

Lascia un commento

Il tuo indirizzo e-mail non verrà pubblicato, lo utilizzeremo solamente per inviarti la notifica della pubblicazione del tuo commento. Ti informiamo che tutti i commenti sono soggetti a moderazione da parte del nostro staff.