Guida ai database di gestione della configurazione (CMDB)

Caratteristiche di un CMDB

Cerchiamo di capire qual è la funzione di un CMDB, qual è il suo ruolo nella gestione della configurazione e in che modo si relaziona e si differenzia dalla gestione delle risorse. Ma come si presenta la funzionalità CMDB a un livello più pratico?

Le principali caratteristiche funzionali di un CMDB sono le seguenti:

Dashboard trasparenti con metriche e analisi dei CI che semplificano il monitoraggio dello stato dei CI, le loro relazioni, l'impatto delle modifiche, i modelli che determinano imprevisti o problemi e il costo, in termini di denaro e risorse, associato alla creazione e alla manutenzione di ciascun servizio all'interno di un'organizzazione.

Funzioni di conformità che offrono agli auditor record dettagliati e visibilità non solo sullo stato corrente dei CI, ma anche sulle loro modifiche storiche, i controlli e i contrappesi, gli imprevisti e così via.

Creazione di CI e popolamento tempestivo dei relativi dati, supportati da tre diversi metodi: input manuale, integrazioni (basate su API, SCCM) e strumenti di rilevamento che eseguono scansioni automatiche di tutti gli indirizzi IP nella rete di un'organizzazione per raccogliere informazioni software e hardware, definendo in modo efficace un inventario di tutti i dispositivi fisici e virtuali dell'azienda.

Assistenza per i set di dati federati, inclusa la normalizzazione e la riconciliazione dei CI e dei relativi dati.

Mappatura dei servizi IT (in genere un'illustrazione grafica delle relazioni e delle dipendenze).

Controlli di accesso che consentono di assegnare diversi livelli di accesso a persone o team diversi in base alle esigenze e di monitorare le modifiche alla loro origine in caso di domande o imprevisti.

I vantaggi di un CMDB

I problemi principali affrontati da un CMDB sono i dati isolati e le informazioni obsolete. Prima di implementare un CMDB, la maggior parte delle organizzazioni dispone di dati distribuiti su vari sistemi con vari responsabili, il che rende difficile avere una visione d'insieme di tutti i CI e delle loro interdipendenze e, in misura maggiore, comprendere quali informazioni sono aggiornate e quali, invece, non lo sono.

Questo impedisce ai team di comprendere un contesto importante quando prendono decisioni, il che può influire sulla valutazione e la segnalazione dei rischi, compromettere il processo decisionale, rallentare la risoluzione dei ticket e, in ultima analisi, avere un costo per l'azienda, sia in termini finanziari che di reputazione.

Supponiamo, ad esempio, che i dati dell'elemento del CI A siano ospitati in un reparto e quelli dell'elemento CI B in un altro. Per funzionare correttamente, CI B dipende da CI A. Tuttavia, quando il reparto di CI A decide di portarlo offline per la manutenzione, non ha visibilità sull'impatto che questo comporta su CI B.

Nella migliore delle ipotesi, ciò può creare confusione tra i team; nel peggiore dei casi, può trasformarsi in un imprevisto grave. Tutto ciò che serve per evitare questo scenario è un CMDB efficace.

Forrester identifica tre casi d'uso in cui un CMDB è oggi di vitale importanza:

Pianificazione

I responsabili tecnologici hanno bisogno dei dati CMDB per pianificare, sia a un livello generale con l'architettura aziendale e la gestione del portafoglio sia a un livello più dettagliato con la gestione degli asset e della capacità.

Contabilità

Il reparto finanziario dell'IT richiede la registrazione delle applicazioni o dei codici di servizio per allocare gli estratti conti e gestire correttamente le finanze aziendali.

Operazioni

Un CMDB migliora una serie di procedure ITSM fondamentali, tra cui la gestione delle modifiche, la gestione degli imprevisti e la gestione dei problemi.

Nella gestione delle modifiche, un CMDB può migliorare la valutazione del rischio anticipando quali utenti, sistemi e altri CI potrebbero essere interessati. Nei settori regolamentati, può anche favorire la conformità, aiutare i team a gestire i controlli e fornire un audit trail chiaro.

Nella gestione degli imprevisti, un CMDB può contribuire a identificare le modifiche che hanno determinato un imprevisto e a ottenere una risoluzione più rapida. I record degli imprevisti possono essere associati ai CI pertinenti, aiutando i team a tenere traccia degli imprevisti nel corso tempo insieme agli asset su cui hanno un impatto.

Nella gestione dei problemi, un CMDB può essere utile per l'analisi delle cause primarie, consentendo ai team di individuare più rapidamente l'origine di un problema. Può inoltre supportare la gestione proattiva dei problemi aiutando i team a identificare gli asset che necessitano di aggiornamento per ridurre i costi di assistenza e il tempo di inattività non pianificato.

In sintesi, un CMDB deve ridurre la complessità, prevenire gli errori, aumentare la sicurezza e consentire un'esecuzione fluida delle pratiche ITSM come la gestione delle modifiche e degli imprevisti.

Le sfide dei CMDB

Le statistiche del settore ci dicono che solo il 25% delle organizzazioni ottiene un valore significativo dai propri investimenti in CMDB. Una percentuale di insuccesso così elevata non ha di certo giovato alla reputazione della tecnologia.

La buona notizia è che i motivi alla base di questo insuccesso sono evitabili e in genere rientrano in sei categorie prevedibili:

Cultura

Come per qualsiasi aspetto in un'organizzazione, la cultura e l'impegno del team sono uno dei fattori più importanti per il successo delle nuove tecnologie e dei nuovi processi. In un recente studio condotto dalla Harvard Business Review, il 93% dei dirigenti ha affermato che la principale sfida nella trasformazione digitale basata sui dati è costituita dalle persone e dai processi. Questo vale per i progetti CMDB.

Pertinenza

I CMDB sono spesso definiti la "singola fonte di riferimento", il che a volte può indurre le organizzazioni a cercare di inserire tutti i propri dati in un'unica posizione senza riflettere sulle specificità dei casi d'uso pertinenti per le loro esigenze.

Come per qualsiasi repository di dati, un CMDB deve contenere dati utili e mirati in grado di supportare processi interni come la gestione delle modifiche. Assicurati che il CMDB abbia un obiettivo di valore definito in modo chiaro, un responsabile e una modalità di aggiornamento dei dati che rifletta tutte le modifiche.

Centralizzazione

Quando affermiamo che un CMDB è una posizione centralizzata dove visualizzare i dati degli asset, non significa che tutti i dati degli asset debbano risiedere esclusivamente nel CMDB. Si tratta di una convinzione errata che può determinare un notevole aumento di lavoro per i team che ritengono di dover spostare tutti i loro dati in questa "singola fonte di riferimento". In questo contesto la vera best practice è quella di federare i dati provenienti da altri strumenti in modo da utilizzare lo strumento più appropriato per supportare ogni caso d'uso.

Ad esempio, spesso ha più senso conservare i dati finanziari in uno strumento di gestione finanziaria IT (ITFM) e le informazioni sulle licenze software uno strumento di gestione delle risorse software (SAM). I dati possono essere importati e sottoposti a mirroring nel CMDB, anche se questo non è il suo spazio di archiviazione principale.

Precisione

Molte organizzazioni hanno difficoltà a sviluppare e mantenere un CMDB preciso. I problemi più comuni riguardano gli strumenti di individuazione eseguiti troppo raramente, l'assenza di regole di automazione o la dipendenza da input manuali. La risposta a queste sfide è in genere l'individuazione basata sugli eventi che ottimizza la tradizionale individuazione bottom-up.

Per coloro che non hanno familiarità con questi termini, l'individuazione bottom-up indica il momento in cui gli asset vengono mappati, iniziando con l'infrastruttura per poi proseguire con i CI rivolti ai clienti. L'individuazione basata sugli eventi, invece, si verifica quando accade qualcosa, ad esempio un evento all'interno di un sistema o un problema, che determina la comunicazione tra i sistemi. In base all'evento che si verifica, quindi, il sistema mappa i CI correlati e le relative connessioni.

Non tutti i CI sono individuabili. Ad esempio, il team potrebbe voler mappare i monitor nel CMDB, ma poiché i monitor non sono individuabili da un sistema automatico, devono essere inseriti manualmente tramite un foglio di calcolo (o un metodo simile).

L'aspetto fondamentale dal punto di vista della precisione è sfruttare la potenza dell'individuazione bottom-up e basata sugli eventi per ottenere un quadro più chiaro degli asset e delle loro connessioni.

Processo

In alcune organizzazioni si ritiene che i CMDB servano a modellare l'infrastruttura e il software legacy, piuttosto che il nuovo stack di infrastruttura cloud e software-defined e i moderni flussi di lavoro in hosting su di essa.

La verità è che non dovremmo lasciare che il dibattito sulla semantica ci impedisca di esplorare l'autentico valore associato al monitoraggio dei CI, legacy e moderni, in uno strumento che ci offre una vista generale dei nostri ecosistemi tecnici.

strumenti

La scelta dello strumento giusto è fondamentale se si desidera evitare le tristi statistiche sugli errori riportate sopra. Alcuni strumenti CMDB sono poco più che repository di asset: strutture di dati fissate su infrastrutture fisiche legacy e strumenti di individuazione che reagiscono lentamente a qualsiasi modifica. Per un CMDB efficace, è necessario che tenga conto dei nuovi tipi di asset e possa supportare modifiche rapide.

Scelta dei contenuti da gestire nel CMDB

Non esiste una risposta valida per tutti i CI da gestire all'interno del CMDB. I casi d'uso e gli obiettivi di ogni organizzazione devono determinare il livello di ampiezza e profondità più adatto alla configurazione del CMDB. In generale, ha senso partire da un livello ampio di comprensione dei servizi per poi andare più in profondità solo se necessario per soddisfare gli obiettivi dell'organizzazione.

Fatta questa premessa, i CI possono essere ampiamente raggruppati come entità tecniche o non tecniche.

Le entità tecniche includono servizi aziendali, servizi tecnici, applicazioni, software, database, container, macchine virtuali, sistemi operativi, hardware, reti, porte e così via.

Le entità non tecniche possono anche essere modellate nel CMDB se è necessario rappresentarle come dipendenti o interessate da altri asset nella mappatura dei servizi IT. Le entità non tecniche possono includere utenti, clienti, organizzazioni, sedi, contratti di servizio, documenti e così via.

Infine, i servizi cloud dovrebbero essere presi in considerazione nella progettazione di un modello CMDB. Sia le offerte SaaS (ad es. Google Apps, Dropbox, Salesforce, ecc.) che le offerte IaaS (ad es. DigitalOcean, Linode, Rackspace, Amazon Web Services, ecc.) possono essere rappresentate come CI in base alle esigenze.