Databas för konfigurationshantering

En konfigurationshanteringsdatabas ) ( CMDB ) är en ITIL- term för en databas som används av en organisation för att lagra information om hård- och mjukvarutillgångar (vanligen kallade konfigurationsobjekt . Det är användbart att dela upp konfigurationsobjekt i logiska lager. Denna databas fungerar som ett datalager för organisationen och lagrar även information om relationerna mellan dess tillgångar. CMDB tillhandahåller ett sätt att förstå organisationens kritiska tillgångar och deras relationer, såsom informationssystem , uppströmskällor eller beroenden av tillgångar, och nedströmsmålen för tillgångar.

Syfte och fördelar

CMDB är en grundläggande komponent i ITIL- ramverkets konfigurationshanteringsprocess . CMDB:er används för att hålla reda på tillståndet för tillgångar såsom produkter, system, mjukvara, faciliteter, människor som de existerar vid specifika tidpunkter och förhållandet mellan alla tillgångar. En CMDB hjälper en organisation att förstå förhållandet mellan komponenterna i ett system och att spåra deras konfigurationer. Upprätthållandet av denna information gör det möjligt för vissa åtgärder, såsom rekonstruktion av tillgångar, att inträffa när som helst. CMDB:er kan också användas för saker som konsekvensanalys , rotorsaksanalys eller förändringshantering .

CMDB-implementeringar involverar ofta federation – inkludering av data i CMDB från andra källor – såsom tillgångshantering, på ett sådant sätt att datakällan behåller kontrollen över data. Federation särskiljs vanligtvis från ETL-lösningar (extrahera, transformera, ladda) där data kopieras till CMDB.

CMDB:er kan användas för många saker, inklusive men inte begränsat till: business intelligence, mjukvara och hårdvara, inventering, konsekvensanalys för förändringshantering och incidenthantering .

ITIL- sammanhang är användningen av CMDB:er som en del av infrastrukturdrift och support. CMDB representerar den auktoriserade konfigurationen av de betydande komponenterna i IT-miljön.

Innehåll

Huvudartikel: Konfigurationsobjekt

CMDB innehåller och registrerar data som också kallas konfigurationsobjekt (CI). Den ger också detaljer om de viktiga egenskaperna hos CI och relationerna mellan dem.

CI-attribut och data

Attribut som fångas upp av en CMDB varierar beroende på CI-kategori och kan vara upp till hundratals. Några exempel inkluderar:

• CI Unique Identifier eller Identification Code
• CI-namn eller etikett (ofta, både långa namn och korta namn )
• CI-förkortningar eller akronymer
• CI Beskrivning
• CI-ägande (organisationer och människor)
• CI betydelse

Eftersom attribut definieras av metadata innehåller CMDB också metadata, och därmed överlappar konceptet med ett metadatalager , som också används för att mer effektivt driva IT-organisationer. Konfigurationshantering tar upp hur data ska hållas uppdaterad. Detta har historiskt sett varit en svaghet hos metadataförråd.

Relationer mellan CI

Som ett minimum är relationer ofta sammansatta av en käll-CI som är relaterad till en mål-CI. I fallet med mer avancerade relationer, såsom semantiska relationer , är det önskvärt att ha en deskriptor mellan Source CI och Target CI som hjälper till att ge sammanhang. Till exempel är "databas" relaterad som en "komponent" av "applikation Y". Beskrivningen är också känd som ett predikat.

Typer av konfigurationsobjekt

En konfigurationsobjekttyp (eller CI-typ) är datatypen för elementet eller konfigurationsobjektet som ett företag vill lagra i CMDB. Som ett minimum lagras och spåras all mjukvara, hårdvara, nätverk och lagrings-CI-typer i en CMDB. När företag mognar börjar de spåra affärs-CI-typer i sin CMDB, såsom människor, marknader, produkter och tredjepartsenheter som leverantörer och partners. Detta gör att relationerna mellan CI:er blir mer meningsfulla och CMDB att bli en starkare källa för kunskapshantering.

CI-typer är:

• Hårdvara
• programvara
• Kommunikation/nätverk
• Plats
• Dokumentation
• Människor (personal och entreprenörer)

En viktig framgångsfaktor för att implementera en CMDB är förmågan att automatiskt upptäcka information om CI:erna (auto-discovery) och spåra förändringar när de inträffar.

Schematiska representationer

CMDB-schematiska strukturer, även kända som databasscheman , antar flera former. Två av de vanligaste formerna är en relationsdatamodell och en semantisk datamodell .

Relationsdatamodeller är baserade på första ordningens predikatlogik och all data representeras i termer av tupler som är grupperade i relationer. I relationsmodellen länkas relaterade poster ihop med en "nyckel", där nyckeln är unik för en posts datatypsdefinition. Sådana relationsmodeller tillhandahåller deklarativa metoder för att specificera data och frågor. Användare anger med andra ord direkt vilken information databasen innehåller och vilken information de vill ha från den, och låter databassystemet ta hand om att beskriva datastrukturer för lagring av data och hämtningsprocedurer för att svara på frågor.

Semantiska datamodeller förlitar sig vanligtvis på resursbeskrivningsramverket som kartlägger relationen mellan ett antal saker genom användning av relationsbeskrivningar, vilket ger sammanhang till hur saker är relaterade till varandra.

Utmaningar

Det finns tre specifika kärnutmaningar för att skapa och underhålla en konfigurationshanteringsdatabas:

• Relevans : Det är nödvändigt att samla in data under varje posts eller CI:s livscykel. Detta innebär att man installerar processer och verktyg för att samla in de senaste ändringarna av data när de inträffar.
• Underhåll : Företag står inför ständiga förändringar. Data om CI och relationerna mellan dem förändras ständigt. Detta underhåll är ett betydande åtagande som ofta inte är planerat eller förväntat. Organisationer tycker ofta att detta är den största utmaningen.
• Användbarhet : De flesta CMDB:er är bara databaser. Detta innebär att de inte har några egenskaper, funktioner eller fördelar med mer komplexa applikationer. De saknar verktyg för att visa data via komplexa visualiseringar eller verktyg för avancerad upptäckt. Detta innebär att de flesta företag behöver investera i ett applikationslager som lägger till sådana konstruktioner till sin CMDB, vilket lägger till ett lager av komplexitet och kostnad som de flesta företag inte planerar för eller förväntar sig. Genom att implementera funktioner som säkerställer att databasen är uppdaterad eller att den kan interagera med system för att köra kommandon, tillämpa uppdateringar eller distribuera nya applikationer utökas funktionaliteten och användbarheten av CMDB.

På grund av ovanstående skäl väljer företag vanligtvis att köpa sina CMDB:er, snarare än att designa, bygga, leverera och stödja dem själva.

Se även

• DMTF (CMDBf)
• ITIL

externa länkar

• Collins: Infrastrukturhantering för ingenjörer
• Guide till design av CMDB-lösningar