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.
