ITSM voor razendsnelle teams
Wat is CMDB?
CMDB staat voor configuratiebeheerdatabase (Configuration Management Database), een bestand dat de verbanden verduidelijkt tussen de hardware, software en netwerken die door een IT-organisatie worden gebruikt.
Je CMDB slaat informatie op over de configuratie van items zoals hardware, software, systemen, faciliteiten en zelfs personeel. Deze configuratiegegevens kunnen bestaan uit onderlinge afhankelijkheden tussen items, de geschiedenis van wijzigingen aan elk item en klasse en attributen - zoals type, eigenaar en belang - voor elk item. Het is de taak van de IT-organisatie om te bepalen welke items moeten worden gevolgd en hoe dit moet worden gedaan.
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". Enkele eenvoudige voorbeelden van een CI zijn een router, een server, een toepassing en een virtuele machine.
Een CMDB is bedoeld om je 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
Configuratiemanagement is een andere discipline dan IT-assetbeheer. IT-assetbeheer (ook bekend als ITAM) is het proces waarbij er geïnventariseerd wordt en er IT-assets worden geïdentificeerd, geüpgraded en verwijderd. IT-assets omvatten software, hardware, netwerken, gegevens en meer. Als je een groot aantal assets hebt, heb je ook een groot aantal onderlinge afhankelijkheden die in een CMDB bijgehouden moeten worden. Bijna alle CI's (configuratie-items) in een CMDB worden ook bijgehouden in je ITAM-tool, maar niet alle assets die in een ITAM-tool worden bijgehouden, staan ook in een CMDB. Als dat verwarrend klinkt, dan is hier een voorbeeld:
Laten we ons twee assets voorstellen. De ene is een computer en de andere is een muis. Beide moeten worden bijgehouden in je ITAM-tool, maar er staat er maar één in je CMBD. Een computer moet worden gevolgd in een CMDB omdat er sprake is van onderlinge afhankelijkheden die beheerd moeten worden om de computer te laten werken. Met een muis is er gelukkig geen web van onderlinge afhankelijkheden om bij te houden.
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.
Voordelen van 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.
CMDB-software
Softwareoplossingen voor CMDB zijn er in vele soorten en maten. Welke software je ook kiest, gebruik de volgende functies om er zeker van te zijn dat je succes kunt behalen.
- Scannen - CMDB-tools voeren scans uit waarbij netwerkassets worden opgehaald. Met geweldige tools kun je je eigen scanpatronen aanmaken om meer niche-assets te vinden en scans kunt uitvoeren volgens een vast schema om alles actueel te houden. Als je CMDB gebruikt in Jira Service Management, kun je zelfs e-mailmeldingen triggeren op basis van gedetecteerde wijzigingen.
- Visualisatie - Als je in de IT zit, ben je waarschijnlijk goed in het begrijpen van databases. Hopelijk ben je ook een mens en mensen doen het nog beter als informatie wordt gevisualiseerd. Met CMDB-software kun je beter visualiseren wat er in je CMDB is opgeslagen, zodat je gemakkelijk kunt interpreteren wat je beheert.
- Relaties in kaart brengen - Een essentieel onderdeel van CMDB-software is het aantonen van de relatie tussen CI's. Dit staat bekend als een servicekaart.
- Statistieken en analyses - Leer van je huidige configuraties en optimaliseer ze voor de toekomst met actuele statistieken en analyses.
Het handboek voor IT-asset- en -serviceconfiguratiebeheer van Atlassian
Je stapsgewijze handleiding voor asset- en configuratiebeheer in Jira Service Management.
Download het handboekJira-native asset- en configuratiebeheer
Assets in Jira Service Management biedt zicht op afhankelijkheden zodat je assets en configuratie-items (CI's) kan beheren, snel incidenten kan oplossen en het risico op wijzigingen beperkt.
Meer informatie