Uno dei principali problemi che i team detti di “IT Enterprise”, ovvero quelli di infrastrutture con più di 1000 dispositivi, si trovano ad affrontare è il rumore di fondo determinato dall’alto numero di allarmi durante il monitoraggio. Ciò avviene quando si deve tenere sotto controllo l’infrastruttura, la rete, lo storage, i servizi cloud e altri elementi: tutto questo genera continue allerte e notifiche per guasti reali o incombenti. Un numero eccessivo di allarmi rende però difficile l’identificazione dei problemi seri, oltre a portare potenzialmente a ignorare alcune allerte e a perdersi quelle importanti. Per evitare che la situazione vada fuori controllo ci sono alcuni consigli che i responsabili degli ambienti IT Enterprise possono seguire per ridurre il rumore di fondo causato da un numero eccessivo di allarmi.
Prima di passare ai consigli, però, è importante capire quali sono le cause del rumore di fondo e perché è pericoloso ignorarlo.
Monitoraggio degli allarmi: le cause del rumore di fondo
Gli ambienti IT Enterprise sono complessi ed eterogenei, con migliaia di dispositivi e applicazioni di molti fornitori diversi. Generalmente ci si ritrova con una molteplicità di tool di monitoraggio, ognuno dei quali monitora diversi aspetti dell’infrastruttura e invia notifiche e allarmi per ogni dettaglio del loro ambito di monitoraggio. Essendoci così tanti allarmi da tanti tool diversi, risulta quasi impossibile assegnare ogni allarme al membro del team IT responsabile di quell’ambito. Tutti gli allarmi finiscono quindi in una cartella IT centrale facendo perdere la visione d’insieme.
Un altro problema è l’assegnazione della corretta importanza a un allarme. Ad esempio: ricevere un allarme da un server che sta esaurendo la memoria è utile quando si gestiscono 5 server ma se ci sono 5000 server, l’allarme non è di nessuna utilità. Occorre essere in grado di stabilire le priorità e concentrarsi sugli allarmi più importanti riguardanti problemi che possono avere gravi conseguenze.
Un’altra caratteristica comune delle grandi infrastrutture è la presenza di reti distribuite, ovvero quando si utilizzano più data center in sedi diverse. Se le reti sono gestite da una postazione centrale, tutti gli allarmi vengono probabilmente inviati al team centrale e si crea il rischio che gli allarmi vadano fuori controllo.
Se gli allarmi sono troppi rischiano di diventare poco significativi o che gli indicatori importanti vengano perduti. Per questo è importante ridurne la quantità grazie a una combinazione di attenta pianificazione strategica e del giusto tool di monitoraggio. In generale, i 4 consigli che ogni responsabile IT dovrebbe seguire sono:
Utilizzare un unico strumento di monitoraggio degli allarmi
Consolidare il monitoraggio in un unico strumento anziché avere molteplici tool con diversi metodi di allerta, fa sì che in presenza di allarmi ci sarà solo una fonte da indagare per scoprire il problema. Inoltre, poiché i vari tool gestiscono allerte e notifiche in modo diverso, disporre di un unico strumento significa poter applicare sempre la stessa filosofia.
Fissare correttamente le soglie
Gli allarmi sono basati su valori soglia: quando un dispositivo supera una certa temperatura prestabilita o quando lo storage disponibile scende sotto un dato numero di gigabyte, scatta l’allarme. Una buona gestione del monitoraggio dipende quindi dall’avere stabilito soglie corrette. Se sono troppo basse si sarà inondati di allarmi, se troppo alte non si verrà avvisati dei problemi se non quando sarà troppo tardi. Sembra facile, ma quando si deve monitorare migliaia di dispositivi e applicazioni è necessario adottare una soluzione di monitoraggio che offra automazione e altri meccanismi come l’ereditarietà delle soglie per gruppi di dispositivi.
Definire i team di reazione e filtrare gli allarmi
Per definire i team di reazione lo strumento di monitoraggio deve essere dotato di funzionalità complete di gestione di ruoli e privilegi: questo permette di creare agevolmente ruoli e responsabilità per specifici team (o anche individui) e di filtrare gli allarmi di conseguenza. In questo modo si può stabilire di inviare le notifiche relative a quelle aree solamente ai team che devono esserne a conoscenza ed evitare inutili allarmi.
Definire gli allarmi di alto livello di cui devono essere informati manager e stakeholder
Non tutte le persone all’interno dell’organizzazione hanno necessità di sapere cosa succede dietro le quinte dell’infrastruttura. I team IT devono ovviamente saperlo, ma in generale i decisori, il management e gli stakeholder è sufficiente che vengano informati solo se si presentano problemi a livelli molto elevati.
Una valida strategia da adottare per “scremare” le informazioni consiste nell’organizzare l’infrastruttura IT in servizi in funzione dei processi di business: il servizio email, il sistema di licensing, i processi di costruzione del software sono tutti servizi IT forniti da diversi “pezzi” connessi di hardware, software e connettività.
Per i servizi email, ad esempio, è necessario mappare le componenti mail server, storage server e connettività Internet dell’infrastruttura. Se si verifica un guasto di poca importanza su uno di questi componenti (ad esempio un mail server ridondante presenta problemi di performance), il servizio email in sé non è a rischio, perché sono disponibili mail server di failover. In questo caso viene avvisato solo il team IT responsabile del servizio, non c’è bisogno di allertare il management. Se invece si verifica un problema critico (ad esempio un crash dello switch core attraverso cui passano tutte le mail) il servizio email è a rischio e l’allarme deve essere inviato al management o ad alcuni stakeholder.
