1. 38 augustus 2013 IT-Infra 39IT-Infra augustus 2013
SERVICEMANAGEMENT
CMDBHet verifiëren van een CMDB lijkt een hoop werk, maar in de
praktijk valt het reuze mee en ook voor de kosten hoeft u het
niet te laten.A
ls u zich ooit Configuratie Ma-
nager heeft mogen noemen dan
zal er vast wel eens iemand zijn
geweest, die u gevraagd heeft of
het allemaal nog wel een beetje klopt. Na-
tuurlijk kunt er zich op dat moment vanaf
makenmet eenbijdehanteopmerking,maar
op een gegeven moment komt u daar niet
meer mee weg. Dan is het tijd voor het con-
troleren van uw Configuratie Management
Database,kortweg CMDB,een proces,dat we
ook wel‘Verificatie’ noemen.
De meest voor de hand liggende manier
is de hele handel langs te lopen en wat u ziet
te vergelijken met wat er op papier staat.
Maar als u bij een wat groter bedrijf werkt
met dito IT-infrastructuur, dan zult u er snel
achter komen dat dat niet alleen een hele
grote, maar vooral ook een hele dure onder-
neming is.
Er zijn echter slimmere en goedkopere
manieren, die u daardoor ook veel frequen-
ter kunt toepassen.Gewoon een kwestie van
verdeel en heers, zoals u zult zien.
Ken uw CMDB
Allereerst zult u moeten weten wat u alle-
maalinhuisheeft,want niet elkgegevenkan
op dezelfde manier geverifieerd worden. Er
zijn namelijk maar liefst vier manieren om
uw gegevens aan de tand te voelen:
1. Scannen. Dit is de goedkoopste manier. U
installeert een stukje software, dat u haar-
fijn kan vertellen wat er allemaal huist in
dat bepaalde stukje infrastructuur. Daarbij
kunt u rustig achter uw bureau blijven zit-
ten, terwijl de gegevens automatisch via het
netwerk binnenkomen.
2.Inspectie.Dit is de duurste manier.U dient
daadwerkelijk elk stukje hardware fysiek te
inspecteren, dus dat vergt behoorlijk wat
mankracht. Afhankelijk van hoe grondig u
dat wilt doen bent u per apparaat tussen de
dertig seconden en vijf minuten bezig.
3. Validatie. Dit is de minst betrouwbare
manier. Eigenlijk past u deze methode al-
leen maar toe als u echt niet anders kunt,bij-
voorbeeld als u na wilt gaan of een bepaalde
systeembeheerder echt een bepaald appa-
raat onder zijn hoede heeft. Noch de aanblik
van het apparaat, noch de aanblik van de
goede man zelf kan u daarover uitsluitsel ge-
ven.U kunt hooguit vragen aan een bevoegd
persoon, bijvoorbeeld de systeembeheerder
zelf, of deze vermelding (nog) klopt.
4. Confrontatie, oftewel ‘cross-checking’. Zo
kunt u het lijstje systeembeheerders verge-
lijken met een lijstje medewerkers uit de sa-
larisadministratie.Alsuwsysteembeheerder
daar niet op staat heeft u óf te maken met
een server die al een tijdje niet meer beheerd
wordt, óf met een wel erg enthousiaste en
vooralgoedkopesysteembeheerder.Welkvan
die tweestellingenwaaris,dient uechterna-
der te onderzoeken.
Hetmagduidelijkzijn,datu–onafhanke-
lijk van welke methode u gekozen hebt – niet
degeheleCMDBineenkeerkunt controleren,
maar slechts een subset daarvan. Stel, dat u
inderdaad een stukje programmatuur hebt
dat alle Windows-servers kan scannen, dan
weet u in ieder geval zeker, dat alle netwer-
kapparatuur en de Linux-servers daarin niet
meegenomen worden. Net als de Windows-
servers die u op voorraad heeft staan of die
in reparatie zijn. Kiest u er bijvoorbeeld voor
om alle werkstations op het hoofdkantoor
in Rotterdam te inspecteren, dan vallen de
werkstations op de vestiging in Amsterdam
gegarandeerd buiten de boot. Net als alle
printers, overigens, ongeacht waar die zich
bevinden.
Om een goede vergelijking te kunnen
maken moet u dus de subset uit uw CMDB
afstemmen op de subset, die uw verificatie
levert.
Hoe kan ik het meten?
De meeste managers zullen van u verwach-
tendat umet KeyPerformanceIndicators,of-
Hans Bezemer
tewel KPI’s,op de proppen komt,zodat zij ook
kunnen zien hoe de vlag erbij hangt. Maar
hoe maakt u nou van zo’n enorme berg ge-
gevens een paar mooie getallen? In principe
is dat helemaal niet zo moeilijk als het lijkt,
want als u twee datasets vergelijkt zijn er
maar vier mogelijke situaties (figuur 1):
1. De gegevens komen voor in de ene dataset,
maar niet in de andere;
2. De gegevens komen niet voor in de ene da-
taset, maar wel in de andere;
3.De gegevens komen in beide datasets voor;
4. De gegevens komen in beide datasets niet
voor.
Die laatste mogelijkheid kunnen we onmid-
dellijk ook weer vergeten, want de interesse
in een server die we niet aangetroffen heb-
ben en die ook al niet in onze CMDB stond is
meestal bijzonder gering.
Statische dekkingsgraad
Het is natuurlijk interessant om te weten
hoe de grootte van de door ons gekozen
subset zich verhoudt tot de gehele CMDB.
Met andere woorden: welk gedeelte van de
CMDB hebben we nu eigenlijk geverifieerd?
Dat doen we door het aantal gecontroleerde
‘Configuratie-items’ (zeg maar het aantal
records in de CMDB1) af te zetten tegen het
totaal aantal ‘Configuratie-items’ en dat uit
te drukken in een percentage. Dat noemen
we de ‘statische dekkingsgraad’. De bedoe-
ling is natuurlijk dat we alle ‘Configuratie-
items’op enig moment controleren, dus alle
niet geïnventariseerd,
in CMDB
CMDB Inventarisatie
geïnventariseerd,
in CMDB
geïnventariseerd,
niet in CMDB
Figuur 1 Vergelijken van verificatie- en CMDB-subsets
De gegevensset vormde niet
een momentopname,
maar meer een‘bewogen foto’
Klopt het allemaal nog een beetje?
Verifiëren van een Configuratie Management Database

2. 40 augustus 2013 IT-Infra 41IT-Infra augustus 2013
SERVICEMANAGEMENT
verificatiesdienenuiteindelijkdeheleCMDB
af tedekken.Dediversesubsetsuit dediverse
verificaties kunnen elkaar uiteraard overlap-
pen (figuur 2).
Dynamische dekkingsgraad
De subset die u uit uw CMDB heeft gehaald
zouhelemaalovereenmoetenkomenmet de
gegevens die u verzameld heeft. Maar u zult
er al snel achter komen dat dat niet het geval
is. Stel dat u een scan heeft uitgevoerd, dan
kan het zijn dat bepaalde apparaten zich te-
gen de verwachting in niet aangemeld heb-
ben. Het kan zijn dat ze toevallig net stuk
waren of in de tussentijd op voorraad waren
gezet.Erkanookeen technischprobleemzijn
opgetreden, waardoor het apparaat niet ge-
scand kon worden.Wat de oorzaak ook is, er
is werk aan de winkel. Hetzij dat u de CMDB
aan moet passen, hetzij dat er een monteur
aan te pas moet komen.
Als u erachter komt dat veel apparaten
zich niet aangemeld hebben, omdat er pre-
cies op dat moment een grote wijziging in de
infrastructuur plaatsvond, dan heeft u een
belangrijke les geleerd: voer een scan alleen
uit als er geen grote wijzigingen plaatsvin-
den.UwChangeManagermoet daaruitsluit-
sel over kunnen geven.
Voorts kunt u geconfronteerd worden
met werkstations die op het moment van
scannen uit stonden. Als dat het geval is, is
het verstandig om na te gaan of deze voor-
afgaand aan de scan op afstand aangezet
kunnen worden2.Nog een tip:laptops kunt u
beter niet middels een scan controleren,
want die zijn zelden allemaal tegelijkertijd
online.
Ook hier valt weer een KPI te berekenen,
namelijk het aantal apparaten uit de CMDB
dat u verwachtte aan te treffen,ten opzichte
van het aantal apparaten dat u daadwerke-
lijk aangetroffen heeft. Dit wordt ook wel de
‘dynamische dekkingsgraad’ genoemd.
Volledigheid
Nu kunt u de zaak van de andere kant
beschouwen,namelijk het aantal apparaten
dat u bij de scan of inspectie gevonden heeft
en zich niet in de subset van de CMDB bevon-
den. Daarbij heeft u twee mogelijkheden. Of
ze bevonden zich wel in de CMDB, maar vie-
len niet binnen de criteria voor de subset of
ze bevonden zich helemaal niet in de CMDB.
In het eerste geval dient u reeds bestaande
gegevens in de CMDB zodanig aan te passen,
dat ze wel in de subset vallen. In het tweede
geval dient u een aantal nieuwe ‘Configura-
tie-items’ aan te maken.
Uw grootste vijand is de factor tijd.Heeft
er recentelijk een wijziging plaatsgevonden,
dan kan het voorkomen dat deze nog in de
pijplijn zit en nog niet niet verwerkt is in de
CMDB. Er zit namelijk altijd een vertraging
tussen het afronden van een wijziging en
de administratieve afhandeling.Voorts kun-
nen scans gegevens bevatten over een lan-
gere periode. Het kan dus goed zijn dat een
werkstation dat een week geleden gescand
is, inmiddels weer op de plank staat.
Het is om die reden dat u een scan of
inspectie binnen de kortst mogelijke tijd af
moet ronden.Zo niet,dan kunt u met schijn-
baar onverklaarbare zaken geconfronteerd
worden. Dat noem ik het ‘AMEV- effect’. De
naam is ontleend aan een inspectie die ik
ooit op het hoofdkantoor van de gelijknami-
ge verzekeringsmaatschappij liet uitvoeren.
Op het eerste gezicht leek het alsof men niet
zorgvuldig genoeg was geweest. Sommige
werkstations waren namelijk twee keer ge-
ïnspecteerd en anderen helemaal niet.
Maar omdat het hier om een nogal groot
gebouw ging, had de inspectie een fors aan-
tal dagen gevergd. In de tussentijd ging het
werk echter gewoon door. Werkstations op
verdiepingen die men nog niet geïnventa-
riseerd had, werden verplaatst naar verdie-
pingen die men al bekeken had en vice versa.
Dat was de verklaring voor de afwijkingen.
De gegevensset vormde dus niet een mo-
mentopname,maarmeereen‘bewogenfoto’.
Als u alle afwijkingen hebt verklaard en
verholpen, kunt u de ‘Volledigheid’ gaan be-
rekenen.DezeKPIverkrijgenwedoorhetaan-
tal gevonden apparaten die reeds in CMDB
bekend waren, te delen op het totaal aantal
gevonden apparaten.
Juistheid
Wat overblijft - en dat is hopelijk het over-
grote deel - zijn de gevonden én in de CMDB
vermeldeapparaten.Indienubijhetscannen
ofinspecterenmeergegevensvergaardheeft
danunodigheeftvoordeidentificatie,kuntu
nog een andere KPI aan uw lijstje toevoegen.
U hoeft dan alleen de betreffende gescande
ofgeïnspecteerdeeigenschappen tevergelij-
ken met de waarden in uw CMDB.
Let wel,soms zult u daar wat extra moei-
te voor moeten doen, want als u dacht dat
fabrikanten consistenter zijn bij het invullen
van bijvoorbeeld merk- en modelgegevens
dan uw bloedeigen medewerkers, dan heeft
u het mis.Maar als u niet de gewoonte heeft
om alles aan te schaffen wat toevallig in de
aanbieding is bij de grootgrutter, dan is het
bijhouden van een conversietabel niet al te
veel werk. Andere gegevens, zoals processor-
snelhedenofgeheugengrootte,zijnvaakwat
makkelijker te vergelijken.
Uiteindelijk houdt u een hoeveelheid
‘Configuratie-items’ over, waarvan de gege-
vens allemaal kloppen versus een hoeveel-
heid ‘Configuratie-items’, die één of meer
fouten bevatten. De verhouding tussen die
twee, uitgedrukt in een percentage, vormt
onze laatste KPI:‘Juistheid’.
Hoe goed ben ik?
U heeft vanzelfsprekend braaf alle boven-
staande KPI’s uitgerekend en nu wilt u
natuurlijk weten hoe goed u het heeft ge-
daan.Als de‘Dynamische dekkingsgraad’,de
‘Volledigheid’ of de ‘Juistheid’ beneden de
85 procent liggen, moet u echt terug naar
de tekentafel. Liggen ze allemaal boven de
95 procent dan mag u uzelf een schouder-
klopje geven.
Dat wil zeggen: tot de volgende verifica-
tie,want dankunnendekaartenerweerheel
anders voor liggen. Configuratie Manage-
ment is namelijk een kwetsbaar proces, veel
kwetsbaarder dan bijvoorbeeld Change- of
Incident Management. In slechts één week
kunnenwel tienprocent vandewaardenver-
anderen – laat staan als het proces een tijdje
lang heeft stilgelegen.
Diekwetsbaarheidisookdereden,dat de
norm op 95 proecent ligt. Honderd procent
is in de praktijk nagenoeg niet haalbaar. Het
scannen gaat niet perfect, er worden kleine
fouten gemaakt bij inspecties, tijdsverschil-
len bij de gegevensverzameling – ze hebben
allemaal hun invloed op het eindresultaat.
Uiteraard kunt u ook allerlei percentages
uitrekenen ná verklaring van de verschillen,
maar dat vind ik persoonlijk een beetje vals-
spelen. De arme drommel op de werkvloer,
die in goed vertrouwen uw CMDB gebruikt,
heeft namelijk weinig aan uw verklaring
achteraf.
Epiloog
Het verifiëren van een CMDB lijkt een hoop
werk,maar in de praktijk valt het reuze mee.
Als u uw infrastructuur een beetje kent dan
zult u al snel tot de conclusie komen, dat er
vaak veel te automatiseren valt - van gege-
vensvergaring tot KPI-berekening.De kosten
hoeven daarom geen beletsel te zijn om een
groot deel van uw technische infrastructuur
maandelijks of zelfs wekelijks te verifiëren.
Voortszult umerken,dat heelveelbeslui-
ten binnen uw beheersorganisatie worden
gemaakt op basis van de informatie in uw
CMDB. En hoe beter die informatie is, hoe
beter die besluiten zullen zijn. Geloof me, de
kosten die u initieel en periodiek moet ma-
ken heeft u snel terugverdiend.
Hans Bezemer (thebeez@xs4all.nl) is configuratie­
manager bij Ordina.
(1) ITIL spreekt over‘Configuratie-records’, wat veel
correcter is aangezien‘Configuratie-items’feitelijk
de objecten zelf zijn. In de praktijk worden beide
begrippen veelal door elkaar gebruikt, derhalve
zal hier consequent gesproken worden over
‘Configuratie-items’.
(2) Bijvoorbeeld middels‘Wake-on-LAN’-technologie.
Als de‘Dynamische dekkingsgraad’,
‘Volledigheid’of‘Juistheid’
beneden de 85 procent liggen,
moet u terug naar de tekentafel
op voorraad
Inspectie
Linux-
servers
Tivoli
Scanning SCCM
Scanning
Windows-
servers
werk-
stations
laptops
bruikleen-
administratie
Confrontatie
verantwoordelijk systeembeheerder
Validatie
routers
CiscoWorks
Scanning
Figuur 2 Overlappende verificatie-subsets