Close

Neem een duik in Jira Service Management en andere krachtige tools bij Atlassian presenteert: Razendsnel ITSM.

Meld je gratis aan

Klaar voor ITSM met hoge snelheid?

Aan de slag met configuratiebeheerdatabases (CMDB's)

Volgens ITIL 4 wordt een configuratiebeheerdatabase (CMDB) gebruikt om configuratierecords gedurende hun hele levenscyclus op te slaan en de relaties daartussen te onderhouden.

Met andere woorden: je CMDB slaat informatie op over de configuratie van items binnen een organisatie, waaronder hardware, software, systemen, faciliteiten en soms personeel. Het is aan de IT-organisatie om te bepalen welke items moeten worden gevolgd en hoe dit moet worden gedaan. Deze configuratiegegevens kunnen bestaan uit relaties en onderlinge afhankelijkheden tussen items, de geschiedenis van wijzigingen aan elk item en klasse en attributen - zoals type, eigenaar en belang - voor elk item.

Binnen een CMDB staan deze bijgehouden items bekend als "configuratie-items" (CI's). ITIL 4 omschrijft CI's als "elke component die moet worden beheerd om een IT-service te leveren".

Een CMDB is bedoeld om een organisatie te voorzien van de informatie die nodig is om betere zakelijke beslissingen te nemen en efficiënte ITSM-processen uit te voeren. Door alle configuratie-informatie te centraliseren, kunnen leidinggevenden kritieke CI's en hun relaties beter begrijpen. CMDB's zijn belangrijk bij impactanalyse, analyse van onderliggende oorzaken, naleving van wettelijke voorschriften, incidentmanagement en verandermanagement.

IT-assetbeheer (ITAM) en configuratiebeheer

Spreken over assets en CI's, IT assetbeheer (ITAM) en configuratiebeheer kan al snel tot verwarring leiden. De termen lijken op het eerste gezicht inwisselbaar, maar in de praktijk kunnen ze enkele van dezelfde componenten van een bedrijf behandelen terwijl ze toch om verschillende aspecten van die componenten draaien.

Wat is het verschil tussen die praktijken? Laten we een auto als voorbeeld gebruiken. Een auto kan zowel een middel (iets van financiële waarde voor een bedrijf) als een CI (een dynamische component die belangrijk is voor de diensten van een organisatie) zijn.

De verschillende praktijken brengen opvattingen over die auto met zich mee:

ITAM-overwegingen

Overwegingen voor configuratiebeheer

  • Wanneer heb je de auto gekocht?
  • Bij welke dealer?
  • Wat kostte hij?
  • Wat is het merk, het model en de afwerking?
  • Wat is de afschrijving?
  • Wat valt er onder de garantie?
  • Welke oliesoort wordt er gebruikt?
  • Hoe vaak wordt de olie gecontroleerd?
  • Na hoeveel kilometer is de volgende olieverversing?
  • Wat is de configuratie van de motor?
    • Is deze aangepast?

Nu is niet elk eigendom ook een CI. Voor sommige bedrijven kan het zinvol zijn om middelen te volgen die niet over de configuratie en afhankelijkheden beschikken die ze waardevol maken om als CI's te volgen. Een energiebedrijf kan bijvoorbeeld individuele elektriciteitsmasten volgen als middelen. Ze hebben financiële waarde voor de organisatie en kennis over beschadigingen, vervanging en dergelijke kunnen de moeite van het volgen waard zijn binnen assetbeheer.

Als CI is de elektriciteitsmast echter misschien niet logisch. Er is geen web van onderlinge afhankelijkheden dat je kunt volgen. Het stuk hout heeft geen configuratie. En het invoeren van elektriciteitsmasten als CI's in je CMDB voegt mogelijk niet genoeg waarde toe aan het systeem om de tijd en moeite te rechtvaardigen.

Kenmerken van een CMDB

We begrijpen dus wat een CMDB doet, de rol ervan in configuratiebeheer en hoe deze zich verhoudt tot en verschilt van assetbeheer. Maar hoe ziet CMDB-functionaliteit er op een praktischer niveau uit?

De belangrijkste functionele kenmerken van een CMDB zijn:

Naadloze dashboards met CI-statistieken en analyses die het gemakkelijk maken om de status van CI's, hun relaties, de impact van veranderingen, patronen die tot incidenten of problemen leiden, en de kosten -in geld en middelen- van het bouwen en onderhouden van elke service binnen een organisatie te volgen.

Nalevingsfuncties die gedetailleerde gegevens en inzichten bieden voor auditors, niet alleen over de huidige staat van CI's, maar ook over hun historische wijzigingen, controles en balansen, incidenten, enz.

Maken van CI's en tijdige invulling van hun gegevens, ondersteund binnen drie verschillende methoden (handmatige invoer, integraties (API-gestuurd, SCCM) en detectietools) die geautomatiseerde scans uitvoeren van alle IP-adressen in het netwerk van een organisatie om software- en hardware-informatie te verzamelen en effectief een inventaris te maken van elk fysiek en virtueel apparaat in het bedrijf.

Ondersteuning voor federatieve gegevenssets, waaronder normalisatie en afstemming van CI's en hun gegevens.

Inzicht in IT-service (meestal een grafische illustratie van relaties en afhankelijkheden).

Toegangscontroles waarmee je zo nodig verschillende toegangsniveaus kunt toekennen aan verschillende mensen of teams en wijzigingen in geval van vragen of incidenten kunt traceren tot aan de bron.

De voordelen van een CMDB

De kernproblemen waarop een CMDB inspeelt, zijn verzuilde gegevens en verouderde informatie. Voordat een CMDB wordt geïmplementeerd, zijn de gegevens vaak verspreid over verschillende systemen met verschillende eigenaren. Daardoor is het moeilijk om in vogelvlucht alle CI's en hun onderlinge afhankelijkheden te zien. Het is bovendien nog moeilijker om te begrijpen welke informatie wel en niet actueel is.

Dit voorkomt dat teams belangrijke context begrijpen wanneer ze beslissingen nemen, terwijl die context van invloed kan zijn op risicobeoordeling en -rapportage –om het maar niet te hebben over belemmering van de besluitvorming, vertraging van de probleemoplossing en de financiële schade en reputatieschade voor het bedrijf.

Laten we bijvoorbeeld zeggen dat de gegevens van CI A op de ene afdeling zijn ondergebracht en dat die van CI B zich in een andere afdeling bevinden. CI B is afhankelijk van CI A om goed te kunnen functioneren. Maar wanneer de afdeling van CI A besluit het systeem offline te halen voor onderhoud, is er geen inzicht in de impact die daarvan op CI B.

Dit kan in het beste geval verwarring veroorzaken tussen teams. In het slechtste geval kan het tot een groot incident leiden. Alles wat nodig is om dit scenario te vermijden, is een goede CMDB.

Forrester beschrijft drie toepassingsscenario's waarin een CMDB tegenwoordig van vitaal belang is:

Planning

Technologiemanagers hebben CMDB-gegevens nodig om te plannen, zowel op hoog niveau met bedrijfsarchitectuur en portefeuillebeheer als op een gedetailleerder niveau met asset- en capaciteitsbeheer.

Boekhouding

IT-financiering vereist gegevens van toepassingen of servicecodes om factuurafschriften toe te wijzen en de bedrijfsfinanciën goed te beheren.

Operationele activiteiten

Een CMDB verbetert een aantal belangrijke ITSM-methoden, waaronder verandermanagement, incidentmanagement en probleembeheer.

Bij verandermanagement kan een CMDB de risicobeoordeling verbeteren door te anticiperen op de gebruikers, systemen en andere CI's die kunnen worden beïnvloed. In gereguleerde industrieën kan de methode ook helpen bij de naleving, teams helpen bij het beheren van controles en een duidelijk auditspoor bieden.

Bij incidentmanagement kan een CMDB helpen bij het identificeren van de wijzigingen die tot een incident hebben geleid en bijdragen aan een snellere oplossing. Incidentrecords kunnen worden gekoppeld aan hun relevante CI's, waardoor teams incidenten in de loop van de tijd kunnen volgen naast de middelen die ze beïnvloeden.

Bij probleembeheer kan een CMDB helpen bij de analyse van de oorzaak, zodat teams sneller tot de kern van een probleem komen. Ook kan proactief probleembeheer worden ondersteund doordat teams worden geholpen bij het in kaart brengen van middelen die moeten worden geüpgraded om servicekosten en ongeplande downtime te verminderen.

Uiteindelijk moet een CMDB de complexiteit verminderen, fouten voorkomen, de beveiliging verhogen en ITSM-methoden, zoals veranderings- en incidentmanagement, soepel laten verlopen.

De uitdagingen van CMDB's

Statistieken uit de sector vertellen ons dat slechts 25% van de organisaties zinvolle waarde haalt uit hun CMDB-investeringen. Het hoge uitvalpercentage heeft de technologie een nogal problematische reputatie opgeleverd

Het goede nieuws is dat de redenen voor mislukking kunnen worden voorkomen. Meestal vallen ze in zes voorspelbare categorieën:

Cultuur

Zoals met alles in een organisatie, behoren cultuur en teambetrokkenheid tot de belangrijkste factoren bij de vraag of nieuwe technologie en processen succesvol zijn. In een recent onderzoek van de Harvard Business Review zei 93% van de leidinggevenden dat mensen en processen de grootste uitdaging vormen voor datagestuurde digitale transformatie. Dat geldt ook voor CMDB-projecten.

Relevantie

CMDB's worden vaak de "centrale bron van waarheid" genoemd. Dat kan er soms toe leiden dat organisaties proberen al hun gegevens samen te voegen zónder na te denken over de toepassingsscenario's die relevant zijn voor hun behoeften.

Zoals bij elke data repository moet een CMDB gerichte, nuttige gegevens bevatten die interne processen, zoals verandermanagement, ondersteunen. Zorg ervoor dat je CMDB is voorzien van een duidelijk gedefinieerde waardedoelstelling, eigenaar en een manier om gegevens bij te werken om alle wijzigingen weer te geven.

Centralisatie

Wanneer we zeggen dat een CMDB een gecentraliseerde plek is om gegevens over middelen te bekijken, betekent dat niet dat alle gegevens uitsluitend in de CMDB aanwezig zijn. Deze algemene misvatting kan teams veel werk opleveren, omdat ze proberen al hun gegevens naar deze "centrale bron van waarheid" te verplaatsen. De échte beproefde methode is dat je gegevens van andere tools federeert, zodat de meest geschikte tool wordt gebruikt om elk toepassingsscenario te ondersteunen.

Het is bijvoorbeeld vaak logischer om financiële gegevens te bewaren in een IT-tool voor financieel beheer (ITFM) en informatie over softwarelicenties in een programma voor het beheer van softwaremiddelen (SAM). De gegevens kunnen worden geïmporteerd en gespiegeld in je CMDB –zelfs als dat niet de primaire omgeving is.

Nauwkeurigheid

Veel organisaties vinden het moeilijk om een nauwkeurige CMDB te ontwikkelen en te onderhouden. De meest voorkomende problemen ontstaan doordat detectietools te weinig worden uitgevoerd, automatiseringsregels ontbreken of handmatige invoer dé basis vormt. Meestal vormt gebeurtenisgestuurde detectie het antwoord: daarmee wordt traditionele, bottom-up discovery vergroot.

Voor degenen die deze termen niet kennen: bij bottom-up discovery worden middelen in kaart gebracht door te beginnen met infrastructuur en daarna te vertakken naar klantgerichte CI's. Bij gebeurtenisgestuurde discovery gebeurt er iets -een gebeurtenis binnen een systeem of een probleem- waardoor systemen met elkaar communiceren. Vervolgens brengt het systeem op basis van die gebeurtenis de gerelateerde CI's en hun verbindingen in kaart.

Nu is niet elke CI detecteerbaar. Het kan bijvoorbeeld zijn dat je team monitors wil vastleggen in je CMDB. Omdat de monitors niet door een geautomatiseerd systeem kunnen worden gedetecteerd, moeten ze handmatig worden ingevoerd via een spreadsheet (of vergelijkbare methode).

De sleutel tot nauwkeurigheid is dat je de kracht van zowel bottom-up discovery als gebeurtenisgestuurde discovery benut om een duidelijk beeld te krijgen van je middelen en hun verbindingen.

Proces

In sommige organisaties heerst de opvatting dat CMDB's zijn bedoeld voor het modelleren van verouderde infrastructuur en software, in plaats van voor de nieuwe stack of cloud en door software gedefinieerde infrastructuur en de moderne workflows die daarop worden gehost.

Het debat over semantiek moet ons er echter niet van weerhouden om de echte waarde van het volgen van ons CIS -oud en modern- te onderzoeken in een tool die ons een vogelperspectief geeft van onze technische ecosystemen.

tools

Als je de bovenstaande statistieken over ongelukkige mislukkingen wilt vermijden, is het heel belangrijk om de juiste tool te kiezen. Sommige CMDB-tools zijn weinig meer dan opslagplaatsen voor middelen: datastructuren die zijn vastgelegd op oudere fysieke infrastructuur en detectietools die langzaam reageren op eventuele wijzigingen. Om een CMDB succesvol in te zetten, heb je er een nodig die rekening houdt met nieuwe soorten middelen en die snel kan veranderen.

Kiezen wat je wilt beheren in je CMDB

Er is geen eenduidig antwoord op de vraag welke CI's je binnen je CMDB moet beheren. De toepassingsscenario's en doelen van elke organisatie bepalen de breedte en diepte die dat zinvol zijn voor de CMDB-configuratie. Over het algemeen is het zinvol om op hoog niveau te beginnen en de services goed te configureren. Ga daarna alleen breder of dieper waar dat nodig is om je organisatiedoelen te bereiken.

Dat gezegd hebbende, kunnen CI's grofweg worden gegroepeerd als technische of niet-technische entiteiten.

Technische entiteiten omvatten zakelijke services, technische services, toepassingen, software, databases, containers, virtuele machines, besturingssystemen, hardware, netwerken, poorten, enz.

Niet-technische entiteiten kunnen ook worden gemodelleerd in je CMDB als je deze moet weergeven als afhankelijke entiteiten of als entiteiten die worden beïnvloed door andere middelen in je IT-serviceomgeving. Niet-technische entiteiten zijn bijvoorbeeld gebruikers, klanten, organisaties, locaties, serviceovereenkomsten, documenten, etc.

Ten slotte moet bij het ontwerp van een CMDB-model rekening worden gehouden met cloudservices. Zowel SaaS-aanbiedingen (bijv. Google-apps, Dropbox, Salesforce, enz.) als IaaS-aanbiedingen (bijv. DigitalOcean, Linode, Rackspace, Amazon Web Services, etc.) kunnen indien nodig als CI's worden weergegeven.

In tegenstelling tot oudere CMDB's biedt Insight for Jira Service Management een flexibele en open datastructuur, zodat je al jouw middelen kunt beheren.