Un inventario risponde a "che cosa ho?". Una CMDB risponde a "che cosa cade insieme quando questo si guasta?". Il ponte tra i due in GLPI non è la scheda Connessioni, come molti presumono - è l'analisi di impatto, ed è esattamente lì che la maggior parte dei progetti di CMDB si arena. Questa guida mostra i quattro meccanismi di relazione che GLPI offre, quale usare in ogni caso e le query che eseguiamo in manutenzione per individuare la CMDB cieca.
Inventario vs CMDB: la differenza che cambia la risposta agli incidenti
L'inventario è un registro: marca, modello, numero di serie, garanzia, responsabile. È controllo patrimoniale ed è da qui che tutti iniziano - con l'inventario automatico di GLPI Agent popola centinaia di asset in pochi giorni. La CMDB è ciò che viene dopo: lo strato di relazione che risponde alla domanda che conta durante un incidente - se questo switch cade, quali server, servizi e utenti si fermano con lui?
| Aspetto | Inventario | CMDB |
|---|---|---|
| Domanda a cui risponde | Che cosa ho? | Che cosa dipende da che cosa? |
| Unità | Asset (elemento) | Relazione tra CI |
| Come si popola | Automatico (GLPI Agent) | Manuale, una decisione di modellazione |
| Valore durante un incidente | Trovare l'apparato | Prevedere il raggio di impatto |
L'errore strategico comune è trattare la CMDB come "inventario più dettagliato" e provare a compilare una relazione per tutto. Non scala e nessuno la mantiene. Una buona CMDB è snella: solo i CI critici e le dipendenze che userebbe davvero in un'analisi di impatto.
I quattro meccanismi di relazione in GLPI
GLPI non ha un unico "campo di relazione" - ha quattro meccanismi distinti, ciascuno nella propria tabella, e scegliere quello sbagliato è la radice della maggior parte delle CMDB che non funzionano. In manutenzione, l'errore numero 1 è montare tutto nella scheda Connessioni credendo che quella sia la CMDB, per poi scoprire che l'analisi di impatto è vuota.
| Meccanismo | Tabella | Modella | Orientato? | Popolato da |
|---|---|---|---|---|
| Connessioni dirette | glpi_computers_items | Periferica collegata a un computer (monitor, stampante, telefono) | No | Inventario o manuale |
| Porte di rete | glpi_networkports_networkports | Cablaggio tra due porte (switch ↔ host) | No | SNMP/LLDP o manuale |
| Applicazioni (Appliances) | glpi_appliances_items | Un servizio/applicazione come CI + l'infrastruttura che lo sostiene | No (raggruppamento) | Manuale |
| Analisi di impatto | glpi_impactrelations | Grafo di dipendenza per calcolare il raggio di impatto | Sì (origine → impattato) | Manuale (scheda Impatto) |
Connessioni e porte di rete modellano il collegamento fisico. Applicazioni raggruppa l'infrastruttura di un servizio. E l'analisi di impatto - l'unica orientata - è il grafo di dipendenza che risponde davvero a "che cosa cade insieme". I quattro convivono; la confusione nasce dall'aspettarsi che uno faccia il lavoro dell'altro.
Modelli il servizio come un CI: Applicazioni (Appliances)
Il passo che manca nella maggior parte degli inventari è dare al servizio un'esistenza propria. "Posta", "ERP", "Portale clienti" non sono hardware - sono servizi che girano sull'hardware. In GLPI l'oggetto giusto è l'Applicazione (Appliances, menu Parco), disponibile da GLPI 9.5. Un'Applicazione è un CI logico a cui collega gli elementi che lo sostengono:
- Crei l'Applicazione (es. "Servizio di Posta").
- Nella scheda degli elementi associati, colleghi i CI di supporto: il server, lo switch core, lo storage, il link internet. Questo viene scritto in glpi_appliances_items.
- Registri il responsabile tecnico, il contratto di supporto e il fornitore sull'Applicazione stessa.
Da lì il servizio esiste come entità interrogabile: apre "Servizio di Posta" e vede l'elenco dell'infrastruttura che lo sostiene, senza dipendere dalla memoria di nessuno.
La CMDB vera: l'analisi di impatto
Raggruppare l'infrastruttura in un'Applicazione dice chi sostiene cosa, ma non calcola il raggio di impatto di un guasto. Questo è il compito della scheda Analisi di impatto (presente da GLPI 9.4), che disegna un grafo orientato di dipendenze memorizzato in glpi_impactrelations. Ogni arco ha un'origine e una destinazione: itemtype_source, items_id_source impatta itemtype_impacted, items_id_impacted.
La direzione è il dettaglio che separa chi capisce da chi ha solo trascinato dei riquadri. Un arco dallo switch al server significa "lo switch impatta il server". Quando lo switch cade, segue le frecce in avanti e vede tutto ciò che si ferma con lui. L'errore comune è disegnare la freccia invertita - collegare il server come se impattasse lo switch - e allora l'analisi di impatto dello switch guasto risulta vuota, proprio quando ne ha più bisogno. Modelli sempre nel senso del flusso di dipendenza: dall'infrastruttura di base fino al servizio in cima.
Un'accortezza sul campo: il grafo viene renderizzato nel browser e diventa lento con centinaia di nodi. Non provi a disegnare l'intero parco. Usi la criticità di business (il menu a tendina Criticità, in Configura > Menu a tendina) per marcare i CI critici e metta solo quelli nel grafo. Una CMDB densa è una CMDB abbandonata.
SQL di diagnostica: trovare la CMDB cieca
All'avvio di un contratto di manutenzione, prima ancora di discutere di processi, eseguiamo un audit di copertura: quali CI critici sono nell'inventario ma fuori da qualsiasi relazione di impatto. Sono i punti in cui l'analisi di impatto mentirà, dicendo "niente è coinvolto" quando in realtà nessuno lo ha modellato. La query elenca i computer senza alcun arco - né come origine né come destinazione:
-- Computer SENZA alcuna relazione di impatto:
-- esistono nell'inventario, ma sono invisibili all'analisi di impatto.
SELECT c.id, c.name
FROM glpi_computers c
LEFT JOIN glpi_impactrelations r
ON (r.itemtype_source = 'Computer' AND r.items_id_source = c.id)
OR (r.itemtype_impacted = 'Computer' AND r.items_id_impacted = c.id)
WHERE c.is_deleted = 0
AND r.id IS NULL
ORDER BY c.name;E l'altro lato: dato un servizio modellato come Applicazione, quali CI raggruppa. Utile per verificare se "Servizio di Posta" punta davvero al server e allo switch giusti prima di fidarsene in una notte di incidente:
-- Elementi che sostengono una specifica Applicazione (servizio):
SELECT ai.itemtype, ai.items_id
FROM glpi_appliances_items ai
INNER JOIN glpi_appliances a ON a.id = ai.appliances_id
WHERE a.name = 'Servizio di Posta';Eseguiamo queste due query direttamente sul database (tramite un client SQL in sola lettura), mai con un LIKE nell'interfaccia, perché vogliamo il numero esatto di orfani per dimensionare lo sforzo di modellazione.
La scoperta automatica non costruisce la CMDB al posto Suo
Vale la pena smontare un'aspettativa che compare in ogni progetto: l'inventario di rete via SNMP scopre le connessioni fisiche - se GLPI Agent scansiona gli switch via SNMP e LLDP/CDP è attivo, le porte di rete tra switch e host si popolano da sole in glpi_networkports_networkports. È ottimo e non deve farlo a mano. Ma la dipendenza logica di servizio - "la posta dipende da questo server" - nessun protocollo la scopre. L'agente non sa che quel processo Exchange è il Suo servizio di posta critico. Quello strato è sempre una decisione umana, ed è proprio ciò che trasforma l'inventario in CMDB.
Tenga vivo il grafo o Le mentirà
Una CMDB obsoleta è peggio di una CMDB inesistente: dà falsa sicurezza. Sostituisce uno switch, dimentica di aggiornare la relazione e, al guasto successivo, l'analisi di impatto punta a un apparato che non esiste più. Leghi la manutenzione del grafo al processo di gestione dei cambiamenti - ogni cambiamento su un CI critico deve rivedere le sue relazioni di impatto prima della chiusura. Senza questa disciplina, il grafo invecchia in poche settimane. È lo stesso principio della base di conoscenza: una relazione che nessuno mantiene diventa rumore.
Ha bisogno di una CMDB in GLPI che sostenga un'analisi di impatto reale, con il grafo modellato sui CI giusti e mantenuto al passo con i cambiamenti? Scopra il servizio di manutenzione GLPI di NexTool.
Revisionato dal team NexTool Solutions.
