Configuration Management Database

Un configuration item (CI) è qualsiasi componente da gestire per erogare un servizio: un server, una workstation, uno switch di rete, un'applicazione, uno schema di database, una licenza, un contratto o la documentazione che descrive come tutto si combina. Ogni CI ha attributi come proprietario, ubicazione, versione, numero di serie e stato del ciclo di vita. Nella maggior parte dei progetti conserva anche la cronologia dei suoi stati nel tempo.

Ciò che definisce una CMDB è che le relazioni hanno lo stesso peso degli elementi stessi. Un record CI dice cos'è un componente. Una relazione dice che l'applicazione delle paghe gira su un cluster specifico, che quel cluster dipende da uno storage array e che una filiale si collega tramite un router preciso. Lette insieme, queste relazioni formano un grafo delle dipendenze. Risponde a domande che un elenco piatto non può gestire: se questo dispositivo si guasta, quali servizi si fermano e chi ne viene colpito?

Nell'ITSM la CMDB è il punto di riferimento su cui scrivono e da cui leggono gli altri processi. La gestione degli incidenti collega ogni incidente ai CI coinvolti. Questo accelera il triage e rende visibili i guasti ricorrenti sullo stesso componente. La gestione dei problemi analizza questi raggruppamenti per trovare le cause radice. La gestione dei cambiamenti è il principale processo di scrittura: un cambiamento approvato registra quali CI coinvolgerà, e la CMDB deve riflettere il nuovo stato a cambiamento completato.

È il grafo delle dipendenze a trasformare i record in decisioni. Prima dell'approvazione di un cambiamento, il suo raggio d'impatto si può stimare seguendo le relazioni verso l'esterno a partire dai CI coinvolti. Dopo un incidente, lo stesso percorso indica cosa verificare per eventuali effetti collaterali. Una CMDB consultata solo durante gli audit offre soltanto una frazione di questo valore.

I due sono collegati ma rispondono a domande diverse. L'inventario degli asset, parte centrale della gestione degli asset IT (ITAM), indica cosa possiede l'organizzazione, dove si trova ogni asset e chi ne è responsabile. I suoi utilizzatori naturali sono finanza, acquisti e facility management. La CMDB indica come sono collegati i componenti e cosa comporta un cambiamento su uno di essi. I suoi utilizzatori sono i team di incidenti, problemi e cambiamenti.

Nella pratica il confine è graduale. Molte organizzazioni partono da un semplice inventario e aggiungono relazioni man mano che maturano i processi di gestione dei servizi. Vale un test semplice: un repository in cui nulla è collegato a nient'altro è un inventario con campi in più, comunque lo si chiami.

La maggior parte delle CMDB combina la discovery automatizzata con la gestione manuale dei record. La discovery si basa su raccolta tramite agenti, scansione della rete e integrazioni con piattaforme cloud e directory. Trova ciò che esiste davvero e rileva le differenze tra lo stato registrato e quello reale. Contratti, definizioni di servizio e altri elementi che non si possono scansionare vengono inseriti e mantenuti a mano.

Quando più strumenti detengono ciascuno una parte della verità, la CMDB li federa o li riconcilia. Per ogni tipo di attributo si designa una fonte autorevole. I conflitti si risolvono con una regola, non con una discussione. L'accuratezza è il risultato di un processo continuo, non di un caricamento una tantum. Senza un proprietario designato, si deteriora in fretta.

In Anexet Inventory la scheda di ogni workstation elenca i dispositivi e le applicazioni installate, con tipo di dispositivo, produttore, versione e data di installazione. Record come questi sono la materia prima con cui una CMDB costruisce i suoi configuration item.

1 / 2

• 
• 

Il modello di fallimento è noto. Il perimetro iniziale copre tutto in una volta, e il progetto affonda nel lavoro sulla qualità dei dati prima di consegnare qualcosa. I record vengono aggiornati solo quando qualcuno se ne ricorda. Col tempo il database smette di corrispondere alla realtà e il personale smette di fidarsene. A quel punto è tecnicamente vivo e praticamente morto. Le pratiche seguenti separano le implementazioni che sopravvivono da quelle che non ce la fanno.

Una CMDB è un dato di riferimento, non un collettore: raramente osserva da sola l'ambiente, ma aggrega ciò che riportano gli strumenti di discovery, monitoraggio e gestione. In cambio li arricchisce. Gli avvisi di monitoraggio acquisiscono contesto su cosa sia un host e quale servizio serva. Le indagini di sicurezza partono da una mappa nota di ciò che dovrebbe esistere. La pianificazione del ripristino sa quali componenti riportare online e in quale ordine.

I suoi limiti derivano dallo stesso disegno. Una CMDB non rileva intrusioni, non controlla i dispositivi e non sostituisce la visibilità sugli endpoint. Dice all'organizzazione come dovrebbe apparire il suo ambiente, così che gli altri controlli possano interpretare ciò che osservano. Controlli come la Data Loss Prevention agiscono dove i dati si spostano davvero, come mostra la tabella.

Inizia dai servizi la cui interruzione costerebbe di più e modella i componenti da cui dipendono. Tenere il modello vicino alla realtà è il cuore della disciplina di gestione della configurazione, quindi espandi il perimetro solo dopo aver superato un audit di accuratezza.