In questo articolo vediamo perché mantenere un CMDB affidabile è più difficile di quanto sembri, quali variabili bisogna governare per riuscirci, e dove finisce il lavoro della tecnologia e comincia quello di modeling.
Quanti server avete?
Sembra una domanda banale. In teoria basterebbe aprire il CMDB, dove dovrebbero confluire discovery tool, cloud provider e ticketing, e leggere il numero. Ma provate a prendere un server qualsiasi, uno che è in produzione da anni, e a cercarlo in ciascuna di quelle fonti. Nel discovery tool si chiama SRV-PROD-01. Nella console del cloud provider è i-0a1b2c3d4e5f. Nel CMDB legacy compare come “Server Produzione Milano”. Nel sistema di ticketing è “App-Fatturazione-Host”, perché a chi apre un ticket interessa il servizio che non funziona, non l’host che c’è dietro.
Quattro fonti, quattro nomi, un solo oggetto fisico. E senza qualcuno che li riconosca come la stessa cosa, ogni fonte continuerà a trattarli come quattro elementi distinti perché, dal suo punto di vista, lo sono davvero. Il rischio va in entrambe le direzioni: potete contare lo stesso server più volte, oppure scambiare due server diversi per uno solo e perderne uno per strada senza accorgervene. C’è anche un terzo caso, più sottile: il totale è pure corretto, ma le informazioni restano sparpagliate tra le occorrenze – la versione software da una parte, lo stato degli aggiornamenti da un’altra ancora, lo storico degli incidenti dall’altra – e finite per considerare “patchato” un asset la cui evidenza è in realtà attaccata all’occorrenza sbagliata.
Sono proprio i momenti che contano di più a farvelo notare: un audit di conformità, una valutazione d’impatto prima di autorizzare una modifica, la pianificazione di quali server dismettere.
Di fronte a questa situazione, la reazione più naturale è pensare “abbiamo un problema di data quality“. È una diagnosi sbagliata, e porta a curare la cosa sbagliata.
Il discovery tool usa l’hostname perché è quello che il sistema operativo dichiara di sé. Il cloud provider usa il resource ID perché è l’unico identificatore garantito univoco nel suo perimetro. Il CMDB legacy usa nomi descrittivi perché è stato popolato da persone, e le persone hanno bisogno di leggere qualcosa di comprensibile. Il ticketing usa il nome del servizio applicativo per lo stesso motivo. Ognuna di queste fonti fa bene il proprio lavoro.
Il problema nasce nel momento in cui proviamo a metterle in relazione tra loro, scoprendo che in tutta l’architettura non esiste nessun livello il cui compito sia proprio quello.
E il quadro si complica ulteriormente non appena entrano in gioco le fonti terze: un database di vulnerabilità che nomina i prodotti secondo la propria nomenclatura CPE, un portale vendor che pubblica le date di fine supporto con un proprio codice release. Su queste fonti non avete alcun controllo – non potete certo chiedere a un database di vulnerabilità di adattarsi al vostro naming – ma è proprio incrociandole con le fonti interne che si scopre se un asset è vulnerabile o vicino a fine vita, un’informazione che nessuna fonte interna può darvi da sola.
Riconciliare tutto questo significa chiedersi non solo come ciascuna fonte chiama le cose, ma anche quando le osserva e con quale livello di dettaglio. Sono domande diverse, e generano cinque variabili che vanno gestite una per una – non con una regola unica per tutte.
La prima è il naming: è l’esempio del server di prima, e vale anche per le fonti terze. Se le occorrenze dello stesso asset restano separate, i ticket si accumulano su una, la CVE su un’altra, l’owner su nessuna delle due. Se invece il matching è troppo aggressivo il rischio è opposto: un solo CI che in realtà rappresenta due macchine diverse, con attributi mischiati che non si sa più a chi appartengano.
Poi c’è la granularità. Anche quando l’identità è risolta, resta da capire di cosa si sta parlando davvero. SRV-PROD-01 è un host, ma sopra girano quattro macchine virtuali, e su una di queste una decina di applicazioni. Chi guarda l’hardware vede un oggetto, chi guarda le VM ne vede quattro, chi guarda le applicazioni ne vede dieci: tre letture tutte corrette, prese a profondità diverse, senza che nessuna fonte tenga il filo tra un livello e l’altro. Il risultato è che si interviene su un livello senza sapere cosa succede sugli altri – una modifica sull’host sembra a impatto nullo, e invece cade un servizio che nessuno aveva collegato.
C’è poi la tassonomia: ogni fonte classifica secondo la propria logica. Quello che un sistema chiama server fisico, un altro lo chiama compute instance, un terzo workload; un vendor identifica una release con un codice interno che non corrisponde alla versione rilevata dal vostro discovery tool. Non sono categorie sbagliate, sono state pensate per rispondere a domande diverse ma la conseguenza è che “quanti server Linux abbiamo” produce tre numeri diversi a seconda di chi lo chiede e da dove, e nessuno dei tre regge davanti a un auditor perché nessuno è riproducibile.
La quarta variabile, la più sottovalutata perché invisibile, è la frequenza di aggiornamento. Alcune fonti sono continue, altre sono fotografie settimanali o mensili e vale anche per le fonti terze: un database di vulnerabilità pubblica nuove CVE più volte al giorno, un portale vendor aggiorna le date di fine supporto una volta a trimestre. Due dati possono essere entrambi corretti e comunque incompatibili, semplicemente perché descrivono due istanti diversi. Qui a farne le spese è la fiducia nello strumento: il CI dice che l’host è attivo, l’host in realtà è stato dismesso undici giorni fa, e il ticket ci finisce sopra lo stesso. Dopo un paio di episodi così, il service desk smette di consultare il CMDB ed è il danno peggiore, perché è quello che non si misura.
Infine, la variabile più recente: la volatilità degli asset effimeri, che cresce con container e workload a vita breve. Un container che vive quaranta minuti, dentro una sincronizzazione giornaliera, non è un asset censito male: è un asset che nasce e muore tra un giro di sincronizzazione e l’altro. O non compare mai nel CMDB, oppure vi compare già morto, risultando “attivo” quando in realtà non esiste più da ore. A quel punto non è più solo il dato a dover essere ripensato, ma il presupposto stesso dell’inventario – che gli oggetti censiti durino più a lungo dell’intervallo con cui li osservate.
Messe insieme, queste cinque variabili spiegano perché non esiste una soluzione facile e perché non basta risolverle una volta per le fonti interne: vanno tenute sotto controllo anche quando entrano in gioco fonti che non gestite voi.
A questo punto la tentazione è affidarsi all’automazione: costruire una tabella di mapping, definire le regole di corrispondenza, automatizzare il join. Due settimane di lavoro, forse tre. Ed è esattamente qui che la questione si fa interessante, perché il matching affidabile tra fonti eterogenee non si fa sui nomi – che sono la cosa meno stabile che esista – ma su identificatori tecnici: serial number, UUID di sistema, MAC address, FQDN, resource ID del cloud provider.
Il problema è che nessuno di questi identificatori copre tutto il parco. Il serial number non esiste su un’istanza cloud, il MAC address cambia quando la VM viene ricreata, l’FQDN cambia con una migrazione di dominio, il resource ID è specifico di un solo provider, e l’UUID di sistema può rigenerarsi con certe operazioni di clonazione. Non esiste una chiave universale, quindi il matching serio è necessariamente a cascata, e dove non c’è nessuna chiave forte si finisce nel matching probabilistico, con soglie di somiglianza da tarare: troppo permissive e si fondono due asset distinti, troppo severe e restano i duplicati. Non esiste una taratura giusta in assoluto: esiste una taratura giusta per quel parco, in quel momento, con quelle fonti.
E anche una volta trovata, quella taratura non dura, per un motivo preciso: dipende dalle fonti così come sono oggi, e le fonti continuano a cambiare – un connettore in più, un formato di campo aggiornato, una migrazione, un’acquisizione. Una tabella costruita a mano viene ritarata solo quando qualcuno se ne accorge, cioè in ritardo. E anche quando funziona, risolve solo l’identità degli oggetti – il naming – non dice nulla su come si classificano, quando le fonti li osservano, o come si relazionano tra loro.
Un approccio completo: tecnologia e modeling
In WEGG siamo consulenti ITAM e ITSM e lavoriamo su progetti di data quality del CMDB, e sappiamo bene che non esiste una soluzione univoca per governare queste cinque variabili. Ed è proprio questo il motivo per cui molti progetti di CMDB falliscono: nella complessità di gestirle e aggiornarle nel tempo, evitando che lo scollamento – il drift – con l’infrastruttura diventi troppo ampio.
Nel tempo abbiamo trovato una strada che per noi funziona, fatta di due lavori distinti. Da un lato, una tecnologia che gestisca in continuo l’identità degli oggetti del CMDB – naming e classificazione – restando sempre allineata alle fonti. Dall’altro, un lavoro che nessuna tecnologia può fare da sola: costruire la relazione reciproca tra gli oggetti e decidere il livello di dettaglio con cui censirli.
La tecnologia a cui ci riferiamo è IT Visibility di Flexera: un motore di riconoscimento e normalizzazione automatico, ancorato a Technopedia, il catalogo di riferimento di Flexera su hardware e software, che raccoglie e classifica in modo standardizzato milioni di prodotti IT esistenti sul mercato.
A differenza di una tabella di mapping statica, si aggancia alle vostre fonti interne ma resta ancorato a Technopedia, quindi porta con sé anche informazioni aggiuntive come vulnerabilità note e dati forniti direttamente dai vendor. E quando Technopedia si aggiorna – cosa che fa più volte al giorno – quell’aggiornamento non resta chiuso nel catalogo: si propaga direttamente sul dato nel vostro CMDB, senza bisogno di un intervento manuale che lo riporti allineato. Il risultato è un identificativo univoco per ogni asset, una classificazione di prodotto coerente – categoria, famiglia, versione ecc. – e un dato allineato alle fonti quasi in tempo reale.
Resta però l’altro lavoro, quello che la tecnologia da sola non può fare: decidere la granularità con cui volete leggere l’infrastruttura. E questa scelta non si fa nel vuoto: dipende da un catalogo servizi definito a monte, e da come quel catalogo dovrà essere letto dentro il CMDB. Solo sapendo quali business service dovete rappresentare potete decidere fino a che livello di dettaglio scendere per ciascuno.
È il lavoro di modeling del CMDB che aiutiamo a fare: aggiungere al dato una classificazione di business, capire quali asset sono davvero critici: perché la criticità non è una proprietà dell’asset in sé, ma dipende dal servizio che sostiene. Lo stesso server può essere trascurabile o fondamentale a seconda di cosa c’è a valle, e solo la mappa delle relazioni con i business service lo dice con certezza. Prendete gli asset effimeri: se sostengono un servizio, li volete comunque tracciare? Il canale tecnico per portarli dentro tramite API c’è già, ma la scelta di trattarli o meno come CI a tutti gli effetti resta del personale IT ed è una scelta che ha senso solo se si sa già a quale servizio quell’asset appartiene.
La tecnologia fa un lavoro enorme sul dato grezzo: lo rende leggibile, e su quella base permette anche di costruire query mirate a seconda dell’obiettivo. IT Visibility, per esempio, ha una struttura Power BI Embedded che organizza i dati secondo esigenze diverse (vulnerabilità, obsolescenza), con template pronti o costruiti su misura, utili in prossimità di un audit, di una remediation sulle macchine non patchate o di uno svecchiamento tecnologico. Ma è un lavoro che si ferma al singolo asset. Leggere quegli stessi dati in relazione al business – sapere cosa è critico, cosa serve tracciare, a quale livello di dettaglio – è il valore aggiunto che porta il modeling.
Nel webinar del 15 ottobre vedremo nel dettaglio i vantaggi di questa tecnologia e come gestire il drift e l’aggiornamento continuo delle fonti dati nel CMDB con un approccio a 360 gradi.
*Articolo a firma di Yari Formaggio, ITAM/ITSM Consultant in WEGG
Approfondimenti
I NOSTRI UFFICI
I NOSTRI UFFICI
PADOVA
Via Arnaldo Fusinato 42, 35137
MILANO
Viale Enrico Forlanini 23, 20134
ROMA
Viale Giorgio Ribotta 11, 00144
Copyright © 2025 WEGG S.r.l. • P.I 03447430285 • C.F. 02371140233 • REA 311023
Azienda Certificata ISO 9001:2015 – ITA / ISO 9001:2015 – EN
