Cerca
Close this search box.
Cerca
Close this search box.
Service Mapping

Mappare servizi e asset in un mondo ibrido

Il nuovo perimetro del Service Mapping

Quali sono le condizioni di discovery necessarie a una tecnologia di Service Mapping per poter conoscere nel dettaglio le relazioni tra asset e servizi in un ambiente IT ibrido.

La conoscenza delle relazioni tra i vari componenti del CMDB è un requisito fondamentale per garantire le prestazioni e la disponibilità dei servizi IT.

Infatti, per poter rispondere rapidamente ai cambiamenti – pianificati e imprevisti – che si verificano all’interno dell’infrastruttura IT (incidenti e problemi, ma anche analisi di impatto per la messa in produzione di nuovi servizi), è necessario avere la piena comprensione delle dipendenze di infrastrutture, applicazioni e servizi al fine di tracciare a più livelli l’ereditarietà delle criticità.

Facendo un paragone con la genetica, il concetto è lo stesso dei modelli di ereditarietà degli alberi genealogici: ci sono dei caratteri recessivi che non emergono ma vige ugualmente il principio della trasmissione verticale. Magari un componente IT in linea gerarchica non manifesta problemi evidenti, ma è ugualmente coinvolto nella trasmissione della criticità. E senza una mappatura delle dipendenze non lo si scoprirà mai.

Una tecnologia di Service Mapping fonda il suo lavoro di creazione automatica di mappe di relazioni e dipendenze sui dati di discovery raccolti all’interno del CMDB. Quindi il primo step per assicurarsi la buona riuscita della mappatura è verificare il perimetro di dati raccolti.

Il perimetro utile al Service Mapping

Per scoprire le dipendenze di asset e servizi, è necessario avere la piena conoscenza delle configurazioni fisiche e virtuali di:

  • Data center (server, hypervisors, storage, database, applicazioni)
  • Edge (desktop, stampanti, VOIP, IoT, mobile)
  • Network (switches, routers, firewall, load balancer, wireless)
  • Cloud (server virtuali, storage, database, applicazioni, security groups)


In un mondo ibrido server e applicazioni
possono essere in esecuzione su qualsiasi ambiente e di conseguenza abbiamo bisogno di sonde e sensori che rilevino i datacenter, le loro specifiche hardware, OS e i componenti collegati (hypervisor, switch di rete, firewall e storage) a prescindere dalla loro locazione, se fisica o virtuale.

Inoltre, i dispositivi client possono connettersi a server posizionati agli estremi (o “edge”) di reti decentralizzate quindi per scoprire nel dettaglio i servizi a cui ci si accede, è necessario avere anche piena consapevolezza delle relazioni con questi device periferici (desktop, stampanti, telefoni VoIP o dispositivi mobili).

Una soluzione di Service Mapping, per poter mappare con successo tutte le dipendenze, dovrebbe quindi fondarsi su dati di discovery completi per data center, edge e cloud.

Nella mia esperienza presso aziende enterprise però ho incontrato scenari di questo tipo:

  • Importazioni e aggiornamenti manuali del CMDB che non assicurano la tempestiva completezza delle informazioni (errori, duplicazioni, nuove configurazioni non segnalate ecc.)
  • utilizzo di strumenti di discovery non sufficientemente evoluti o non ottimizzati per i data center (es. Lansweeper, OCS Inventory, GLPI) che offrono un livello di dettaglio di inventario insufficiente per identificare le relazioni tra i sistemi rilevati
  • costose integrazioni tra più sistemi per scoprire anche le risorse cloud: la conoscenza delle relazioni tra oggetti virtuali potrebbe dover richiedere, ad esempio, i costi di mantenimento di un database SQL

In queste situazioni la mappatura delle dipendenze che ne risulta potrebbe non essere in grado di coprire l’intero perimetro IT o di riuscire a farlo con spese onerose.

Uno dei requisiti tecnologici da valutare nella scelta della tecnologia di Service Mapping è verificare che sia progettata per un ambiente IT ibrido e di conseguenza abbia delle sonde di discovery estensibili per qualsiasi tipo di risorsa IT.

Altri requisiti tecnologici in supporto alla definizione del perimetro

Quando parliamo di definizione del perimetro utile al Service Mapping, ci sono altri aspetti da considerare nella tecnologia oltre al verificare che assicuri una copertura completa delle risorse IT.

Un altro aspetto importante da considerare è la facilità e la velocità nella distribuzione delle sonde di discovery: è inutile avere un dettaglio molto completo di inventario se per ottenerlo ci vogliono giorni interi o si deve tribolare scaricando, configurando e aggiornando agenti per la raccolta dati.

Il rilevamento dovrebbe quindi essere eseguibile anche con sonde agentless (ad esempio, WMI, SSH, SNMP) che operino attraverso “ping” su sottoreti e siano in grado di recuperare velocemente una lista di indirizzi IP con tutti i relativi dettagli di configurazione. Dove non è possibile (ad esempio per le risorse cloud), bisognerebbe poter sfruttare l’integrazione diretta con le API.

Un altro tema da non tralasciare, sempre in ambito discovery utile al Service Mapping, è la sicurezza: dato che l’utilizzo di sonde e API prevede l’inserimento delle credenziali per i tipi di sistemi che si vuole scansionare, si preferiscano tecnologie che offrono sufficienti garanzie di sicurezza. Ad esempio, sarebbe preferibile che l’applicazione di discovery fosse installata su un server on-prem dove i dati possono essere facilmente crittografati.

La Cloud Discovery in Ivanti Neurons per Service Mapping

La tecnologia del nostro partner Ivanti per il Service Mapping è progettata per funzionare in un ambiente IT ibrido.  

Sfrutta, infatti, un collettore di dati di discovery che può essere installato su un server fisico o cloud dell’azienda: oltre alle sonde agentless che scansionano 20.000 IP nell’ordine di ore, non di giorni, offre la possibilità di integrazioni API per i servizi cloud.

L’integrazione API con Azure, AWS e Google Public Cloud, ad esempio, permette di importare molte risorse cloud rilevanti per il CMDB (ad esempio istanze EC2, macchine virtuali, VPC, gateway di applicazioni, ecc.)

Con queste informazioni la tecnologia di Service Mapping di Ivanti, che è fruibile tramite un web portal, crea automaticamente la mappa delle dipendenze anche all’interno di scenari cloud e ibridi. Si può impostare anche la frequenza e la profondità della scansione voluta.

Qui sotto, ad esempio, vediamo una mappatura che è il risultato di un’integrazione via API con AWS.

Oltre a conoscere nel dettaglio i CIs, otteniamo il valore aggiunto della scoperta di nuove risorse: all’interno della sezione “Discovered items”, infatti, troviamo flaggato come “new” quanto non già presente a CMDB.

Se vogliamo operare per l’integrazione con piattaforme già presenti in azienda (CMDB o ITSM), andiamo a migliorare la qualità dei dati di inventario con processi automatizzati di aggiornamento, facendo in modo che il discovery legato al Service Mapping attivi un miglioramento continuo dei dati già raccolti in azienda.

In WEGG siamo consulenti esperti di processi e tecnologie di mappatura di asset e servizi IT. La completezza del perimetro di analisi è uno dei requisiti necessari, ma non l’unico da considerare per attivare con successo un progetto di Service Mapping.

Ne parleremo nel webinar in programma per il 28 febbraio dal titolo “Service Mapping: la tecnologia invisibile al ballo dei servizi IT” (vai qui per iscriverti!) dove approfondiremo tutti i vantaggi di scoprire le dipendenze interne del nostro IT e i requisiti da considerare per una tecnologia in grado di trarre il massimo beneficio con la minore spesa!

Articolo a firma di Yari Formaggio, ITAM/ITSM consultant in WEGG.

02-s pattern02

Vorresti ricevere supporto sull'analisi del perimetro di Service Mapping?

CONTATTACI PER APPROFONDIRE!