Scegliere la tecnologia di Service Mapping

Gli aspetti critici da valutare con attenzione

Per le aziende che vorrebbero conoscere le relazioni interne di asset e servizi, una guida dettata dalla nostra esperienza che evidenzia gli aspetti critici di una tecnologia di Service Mapping che potrebbero penalizzare la riuscita del progetto di mappatura. 

Eliminare ogni congettura: questo è il compito del processo di Configuration Management che si basa sulla popolazione dei dati all’interno del CMDB a riguardo delle relazioni tra i Configuration Items (CIs) che supportano un servizio. La tecnologia di Service Mapping è un elemento fondamentale per garantire che questo popolamento avvenga in modo completo e automatizzato.

È la risposta alla domanda “cosa è cambiato o cosa cambierà?” quando si verifica un’interruzione del servizio o si deve pianificare una change. Una mappatura delle relazioni tra asset e servizi, infatti, permette di identificare facilmente le parti interessate a più livelli e comprendere le cause degli incidenti per ripristinare rapidamente la disponibilità del servizio o analizzare i rischi potenziali di eventuali modifiche all’infrastruttura IT.

La disponibilità di dati offerta grazie alla tecnologia di Service Mapping permette ai team di sicurezza e a IT Operations di migliorare la gestione del servizio: da un lato riducendo i tempi di risposta, e dall’altro assicurando la messa in produzione di nuovi servizi e configurazioni senza che questo abbia alcun impatto sull’operatività.

Se è vero che il battito di ali di una farfalla può causare un uragano dall’altra parte del mondo, allo stesso modo piccole variazioni nelle condizioni iniziali – a volte anche “periferiche” o non direttamente correlabili – possono produrre grandi variazioni nel comportamento a lungo termine dell’intero sistema IT.

La scoperta di questi fili invisibili, oltre ad arricchire di informazioni utili il CMDB e gli strumenti di lavoro per la gestione dei ticket o dei change, può essere anche il punto di partenza per rivedere la propria mappatura dei servizi: a partire dai problemi riscontrati o riscontrabili, si può strutturare il Service Catalog aziendale in modo più coerente con le esigenze aziendali, decidendo quali nuovi servizi mettere in produzione, quale ritirare o eventualmente modificare.

Service Mapping: gli 8 elementi critici

Vediamoli insieme:

• discovery non pensata per un ambiente IT ibrido

Partiamo da un principio: è possibile avere la discovery senza la mappatura dei servizi, ma non è possibile avere la mappatura dei servizi senza la discovery. Un tipico software di discovery (es. Lansweeper, OCS Inventory, GLPI) fornisce un inventario degli asset e alcune relazioni ad alto livello. Un vero software di mappatura dei servizi si spinge oltre, scoprendo relazioni approfondite tra gli asset, compresi hardware, applicazioni e siti web. Queste relazioni sono poi rappresentate in mappe dinamiche che dovrebbero adattarsi automaticamente in base alle modifiche dell’ambiente.

Al giorno d’oggi ci muoviamo in ambienti IT ibridi, quindi la tecnologia di Service Mapping utilizzata dovrebbe fondarsi su dati di discovery completi per data center, edge e cloud, senza perdere tempo e soldi a integrare inventari da più sistemi. Dove le sonde e il CMDB non arrivano per estensione e qualità del dato, deve essere possibile fare integrazioni via API senza dover mantenere costosi database SQL: soprattutto se si vuole conoscere le dipendenze cloud, dato che molti servizi ormai si fondano sia su risorse fisiche sia su risorse virtuali. Ne abbiamo parlato in modo approfondito in un altro articolo. 

• implementazioni poco flessibili e che richiedono lunghi tempi di implementazione

Cloud e on-prem: ogni realtà ha ambienti diversi, per cui la stessa tecnologia di Service Mapping dovrebbe essere in grado di adattarsi facilmente ai server disponibili. E dovrebbe essere veloce da implementare: se c’è un collettore di dati di discovery che si può attivare in modalità agentless è già un valore aggiunto, senza dover tribolare nello scaricare e distribuire agenti che nel lungo tempo dovrebbero essere soggetti a manutenzione e aggiornamenti.

Poi bisogna valutare anche il numero di server di discovery richiesti per supportare la tecnologia: una soluzione web-based semplifica il processo di distribuzione perché non richiede server aggiuntivi (ne è sufficiente uno!). Alcune tecnologie richiedono l’installazione di componenti aggiuntivi (ad esempio server di gestione) per supportare la scoperta delle risorse IT, un processo che può richiedere tempi lunghi di implementazione.

• utilizzo di strumenti con processi manuali

Per quanto le tecnologie di Service Mapping forniscano strumenti automatizzati per la mappatura dei servizi e delle relazioni IT, possono richiedere comunque un certo grado di input e validazione manuale per assicurare l’accuratezza e la completezza delle mappe di relazione. Come può essere la definizione dei criteri di relazione.

Affidare al giorno d’oggi la tracciatura e la registrazione delle topologie di servizi a processi manuali le porta ad essere soggette ad errori, incongruenze e tempi più lunghi per un output di qualità perché devono essere soggette continuamente a revisione: per questo l’utilizzo di tecnologie di Service Mapping con tecniche di apprendimento automatico può garantire la precisione necessaria alla generazione di mappe.

Gli algoritmi di machine learning possono essere impiegati per identificare pattern e correlazioni tra i diversi componenti IT e servizi aziendali, creare modelli predittivi e utilizzare il feedback continuo dai dati in tempo reale e dalle iterazioni dell’utente per migliorare continuamente i modelli di apprendimento impiegati. Se poi vengono scoperte nuove risorse, l’AI automaticamente può classificarle e muoverle a CMDB.

• gli algoritmi che dovrebbero farlo non sono addestrati su fonti affidabili

Qui ci colleghiamo al punto sopra: se utilizziamo tecnologie di Service Mapping che incorporano algoritmi di Machine Learning, quest’ultimi devono essere “trainati” su fonti affidabili. Quindi la tecnologia per scoprire asset e servizi deve fondarsi su un dizionario applicativo di tutto rispetto. Che assicuri la giusta profondità di dettaglio e una costante frequenza di aggiornamento con tutte le evoluzioni che interessano le configurazioni IT.

A tal riguardo, avere nelle mappe un dettaglio visivo su quali sono gli asset con vulnerabilità note o qual è il loro impatto sul livello di servizio è un valore aggiunto: per questo addestrare gli algoritmi su dizionari applicativi che incorporano e utilizzano i dati provenienti dal National Vulnerability Database (NVD), un repository di informazioni sulle vulnerabilità informatiche gestito dal governo degli Stati Uniti, permette di avere insight azionabili su come prioritizzare gli interventi.

• non si riesce a portare fuori i dati

Un altro aspetto che tutti conoscono ma di cui si parla troppo poco è il lock-in dei dati. Ci sono delle condizioni per cui un’azienda fa fatica a spostare i propri dati dal sistema di Service Mapping a piattaforme che non siano dello stesso vendor: sia per la struttura proprietaria usata per memorizzare e gestire i dati, sia per condizioni contrattuali o costi che regolano le estrazioni, sia per l’elevata integrazione di servizi e prodotti dello stesso vendor che rende difficile migrare verso piattaforme diverse senza perdere funzionalità o interoperabilità.

I vincoli rigidi sulla portabilità dei dati limitano la libertà di scelta, qualora un domani si volesse impegnarsi in progetti che coinvolgono altre tecnologie. Con alcuni vendor bisogna già mettere in preventivo dei costi di formazione e di adattamento, dato che investono nella creazione di una forte base di utenti e integrazioni interne.

• si creano sovrapposizioni

Con Service Mapping e CMDB (ma anche un qualsiasi strumento ITSM) che operano in modo indipendente, i dati possono venire duplicati o sovrascritti nei due sistemi. I componenti IT come server, applicazioni o dispositivi di rete potrebbero essere stati identificati e registrati separatamente, nonostante facciano riferimento allo stesso CI. Se poi non vengono sincronizzati in tempo reale o regolarmente aggiornati, potrebbero verificarsi discrepanze e sovrapposizioni quando i cambiamenti vengono apportati all’infrastruttura IT. Per questo motivo sarebbe bene appoggiarsi a tecnologie in grado di gestire automaticamente sovrapposizioni di record ITSM sulle mappe dei servizi con i prodotti ITSM e/o di aggiornare i dati contenuti a CMDB, per avere un’unica fonte di verità allineata. I processi di manutenzione e pulizia dati, infatti, aumentano il carico di lavoro del personale IT.

• c’è poca chiarezza nell’esposizione delle mappe

Le due dimensioni che riguardano le informazioni da visualizzare nelle mappe, che rientrano nello SCOPE (quali entità si vuole gestire) e nel DETAIL (la profondità di dettaglio riguardo alle entità gestite), devono poter essere gestite con flessibilità: a tal proposito la possibilità di creare filtri per concentrarsi solo sui tipi di risorse che interessano o comunque la possibilità di organizzare il livello di dettaglio e la natura delle relazioni con assegnazioni, codifiche, colori, facilita una più chiara comprensione delle relazioni stesse.

Oltre alle mappe, un supporto valido alla comprensione potrebbe essere rappresentato da dashboard e grafici che permettono un “colpo d’occhio” su metriche e dati chiave relativi all’infrastruttura IT e ai servizi aziendali. Questi potrebbero includere informazioni su prestazioni, disponibilità, sicurezza, conformità e altro ancora.

• costi di licenza elevati

La maggior parte delle soluzioni di Service Mapping richiede una licenza per ogni dispositivo scoperto: per le aziende con un’ampia infrastruttura IT o un gran numero di dispositivi da monitorare il conto finale potrebbe presentarsi piuttosto salato.

Per questo è da preferire quelle realtà che, a parità di funzionalità offerte, permettono di pagare solo per i sistemi operativi dei server scoperti (o le macchine virtuali, dove è possibile installare il software), con vantaggi in termini di trasparenza dei costi: i costi di licenza in questo modo si tradurrebbero solo per le risorse effettivamente utilizzate.

Approfondiremo tutti questi aspetti nel webinar “Service Mapping: la tecnologia invisibile al ballo dei servizi IT” in programma per il 28 febbraio (vai qui per ottenere il video!), dove vedremo con casi d’uso concreti su una tecnologia di Service Mapping che da un lato abbia le funzionalità necessarie a scoprire le relazioni tra asset e servizi e dall’altro sia implementabile senza richiedere investimenti o integrazioni onerose.

Articolo a firma di Francesco Clabot, CTO di WEGG e docente ITSM all’Università di Padova.