Wat is een CMDB (Configuration Management Database)?

Een CMDB (configuration management database) is een database die informatie opslaat over de IT-assets van een organisatie - servers, applicaties, netwerkapparatuur, desktop computers - en, cruciaal, de relaties daartussen. Elke entry is een configuration item (CI) met eigen attributen, en elke CI is gekoppeld aan wat erop draait, waar het van afhangt of waarmee het verbonden is. Die relatiedata onderscheidt een CMDB van een gewoon assetregister: het beantwoordt niet alleen “wat bezitten we”, maar “wat valt uit als dit uitvalt”.

Waar CMDB voor staat en waar het vandaan komt

CMDB staat voor configuration management database. De term komt uit frameworks voor IT service management (ITSM) zoals ITIL, waar de CMDB het centrale register is dat het configuratiebeheerproces draagt. In de praktijk werkt het als een datawarehouse voor uw IT-omgeving: elke beheerde component wordt vastgelegd als configuration item, en de database bevat zowel de attributen van het item als de koppelingen naar alles eromheen. Die tweede helft - de relaties - maakt het een CMDB en geen spreadsheet vol apparatuur. Het is hetzelfde onderscheid dat een CMDB scheidt van het bredere IT asset management (ITAM), waar we hieronder op terugkomen.

Wat telt als configuration item

Een configuration item (CI) is elk onderdeel dat het waard is om op zichzelf te volgen. Typische voorbeelden:

• Hardware-CIs - servers, switches, firewalls, storage-arrays, eindgebruikersapparaten
• Software-CIs - applicaties, databases, besturingssystemen, middleware
• Virtuele en cloud-CIs - virtuele machines, containers, cloud-instances en -diensten
• Service-CIs - de bedrijfsdiensten waar die onderdelen samen uitkomen, zoals “e-mail” of “facturatie”

Elke CI heeft attributen (naam, versie, omgeving, eigenaar, locatie) en relaties (“draait op”, “hangt af van”, “maakt deel uit van”). Het bepalen van het detailniveau is de eerste ontwerpbeslissing: volg elke kabel en de CMDB verdrinkt in onderhoud; volg alleen servers en hij kan geen nuttige vragen beantwoorden. Een goede vuistregel is afbakenen op use case, niet op asset - komt een CI-klasse nooit voor in een incident, een wijziging of een audit, laat hem dan weg.

Hoe een CMDB-record eruitziet: een voorbeeld

Een CMDB-record is gestructureerder dan een regel in een spreadsheet. Een enkel CI-record draagt doorgaans een naam of ID, een CI-type (server, applicatie, database, netwerkapparaat, cloud-resource), een status, de omgeving waarin het draait (productie, staging, ontwikkeling), een eigenaar en technische velden zoals IP-adres of versie - en daar bovenop de relaties.

Een uitgewerkt voorbeeld maakt het concreet. Een CI met de naam app-prod-01 is van het type applicatie, staat in productie, is eigendom van het betaalteam en draagt drie relaties: hij draait op een virtuele machine, hangt af van een betaaldatabase en maakt deel uit van de checkout-dienst. Zoek dat ene record op en u ziet, in één overzicht, alles waar de checkout-dienst op steunt. Vermenigvuldig dat met honderden CI’s en u krijgt een service map - de boom van afhankelijkheden achter elke bedrijfsdienst, wat de meeste CMDB-tools voor u tekenen.

Relaties zijn het punt

Neem een keten: de facturatieapplicatie draait op een virtuele machine, die op een host in de serverruimte draait, die via één switch verbonden is. Wanneer die switch vervangen moet worden, vertelt de CMDB u - voordat u iets aanraakt - dat facturatie daarmee uitvalt. Dat is impactanalyse, en het is de kern van CMDB-gebruik. Dezelfde data werkt omgekeerd bij het opsporen van problemen: wanneer facturatie traag is, toont de CMDB elk onderdeel eronder dat het waard is om te controleren, de basis van root-cause-analyse. Daarom zijn CMDB’s een vaste waarde in change management en incidentbeheer bij grotere IT-organisaties.

Waarom CMDB's verouderen - en hoe teams ze actueel houden

Een CMDB is nooit beter dan hoe actueel hij is, en de klassieke fout is bekend: hij wordt eenmalig gevuld tijdens een project en raakt daarna verouderd terwijl de omgeving eromheen verandert. Praktijkmensen zeggen het graag rechtuit - een CMDB faalt niet bij de lancering, hij faalt een paar maanden later, wanneer niemand kan zeggen wie een bepaald record beheert. Twee dingen houden hem eerlijk. Het eerste is automatische discovery: tooling die het netwerk en de cloudaccounts scant en CI’s bijwerkt wanneer de infrastructuur verandert, zodat de database niet met de hand wordt gevoed. Het tweede is duidelijk eigenaarschap: elke CI heeft een aangewezen eigenaar nodig die voor de juistheid zorgt, en de meest kritieke CI’s worden volgens een schema opnieuw gecontroleerd. Zonder een changeproces dat hem voedt, raakt een CMDB snel verouderd - precies daarom past hij bij teams met volwassen ITSM-praktijken en zelden bij teams zonder.

CMDB vs assetregister vs ITAM

De grens zit in het doel. Een assetregister dient eigendom en geld: wie heeft welk apparaat, wat kostte het, wanneer eindigt de garantie, wat gebeurt er bij afvoer. Een CMDB dient de operatie: technische configuratie en afhankelijkheden, ter ondersteuning van wijzigingen en incidenten. ITAM is de bredere discipline; een CMDB is één tool, vooral gebruikt door ITSM-gedreven teams. Kort gezegd: ITAM vertelt u wat u bezit en wat het kost, terwijl een CMDB u vertelt hoe het bedraad is en wat uitvalt als u het aanraakt. De twee overlappen op de hardware zelf - dezelfde server staat in beide - maar ze registreren andere feiten. Licentierechten en verlengingen horen bijvoorbeeld in software license management-records, niet in een afhankelijkheidsdiagram.

Wanneer een klein team er echt een nodig heeft

Een CMDB loont wanneer u infrastructuur beheert waar andere systemen van afhangen en wijzigingen maakt die een impactbeoordeling vereisen - eigen servers, een productieomgeving, alles met uitvalkosten. Het loont niet als eerste centrale register voor een team waarvan de omgeving uit laptops, smartphones en SaaS-licenties bestaat; die vragen gaan over eigendom en verlengingen, en het grootste risico van de CMDB - één keer gevuld en nooit bijgewerkt - treft teams zonder changeproces het hardst. Voor dat meerderheidsgeval wint een actueel assetregister van een verouderde CMDB, en een tool als AMPthilly houdt er één bij met eigenaren, uitleningen, documenten en auditgeschiedenis per asset, zonder afhankelijkheidsdiagrammen.

Gerelateerde termen

• Software Asset Management - het beheer van de softwarekant van de IT-omgeving
• Software License Management - waar rechten en verlengingen worden bijgehouden
• License Compliance - binnen de licentievoorwaarden blijven die u heeft
• IT Asset Disposition - hardware veilig buiten gebruik stellen aan einde levensduur
• True-Up - de licentiereconciliatie die een leveranciersaudit uitlokt