Ett konfigurationsobjekt (CI) är en komponent - hårdvara, programvara eller dokumentation - som registreras i en CMDB eftersom den stödjer en IT-tjänst.
Ett konfigurationsobjekt (CI) är en komponent som måste hanteras för att leverera en IT-tjänst - en server, en applikation, en nätverksswitch, till och med ett dokument - registrerad i en configuration management database (CMDB). Termen kommer från ITIL, det mest använda ramverket för IT service management. Det som skiljer ett CI från en vanlig tillgångspost är relationsdatan: en CMDB listar inte bara komponenter, den kartlägger hur de beror på varandra, så att man ser hela följdverkan när något slutar fungera.
Exempel på konfigurationsobjekt
- Hårdvaru-CI - servrar, nätverksswitchar, routrar, brandväggar, lagringssystem, och slutanvändarenheter som en tjänst beror på.
- Programvaru-CI - operativsystem, applikationer, databaser, middleware, och deras versioner.
- Dokumentations-CI - driftmanualer, SLA:er, nätverksscheman, och policyer som tjänsten inte kan drivas utan.
- Tjänste- och infrastruktur-CI - själva e-posttjänsten, molninstanser, SSL-certifikat, DNS-zoner.
Det avgörande testet är påverkan på tjänsten, inte priset. Ett billigt SSL-certifikat är ett solklart CI eftersom tjänsten faller om det går ut; en dyr post utan roll i någon tjänst - reserv-hårddiskar i ett skåp, eller konferensrumsutrustning som ingen upptid hänger på - är en tillgång värd att hålla koll på, men sällan värd att modellera som CI.
Vad en CI-post innehåller
Ett CI bär en unik identifierare, typ, ägare, status och version där en sådan finns. Det attribut som gör det verkliga jobbet är relationerna: “kör på”, “beror på”, “ansluter till”, “dokumenteras av”. De länkarna låter en servicedesk följa ett avbrott från en trasig switch till de tre applikationerna bakom, eller i förväg bedöma vad en planerad ändring berör. Ta bort relationerna och CMDB:n faller ihop till en vanlig inventeringslista med några extra fält.
CI eller tillgång
De två begreppen beskriver samma fysiska värld från olika håll. Tillgångsposten tar ägar- och ekonomiperspektivet: inköpspris, leverantör, garanti, aktuell innehavare, var i IT-tillgångens livscykel den befinner sig, och när utbytescykeln för hårdvara säger att den ska bytas. CI:t tar tjänsteperspektivet: vad komponenten stödjer och vad som händer om den slutar fungera.
Mängderna överlappar utan att vara desamma. En produktionsserver är både tillgång och CI. En reservskärm är en tillgång men inget CI. Ett gratis open source-bibliotek eller en driftmanual är ett CI men syns inte i balansräkningen - precis som en licensrättighet är en tillgång i licenstermer oavsett om någon modellerar den i CMDB:n.
När en CMDB är överdrivet
En CMDB har ett välförtjänt rykte om sig att förfalla. Relationsdata är dyr att hålla aktuell - varje arkitekturändring, migrering och avveckling måste speglas, och en CMDB som stämmer till 80 % är farlig just därför att folk litar på den mitt i en incident. Den ärliga tumregeln: modellera CI där beroendekartan verkligen kommer att underhållas och användas, vanligtvis servrar, nätverksutrustning och kärnapplikationerna bakom kritiska tjänster. För allt annat - och för de flesta små och medelstora organisationer helt och hållet - ger ett välskött inventarieregister med ägare, statusar och historik det mesta av värdet till en bråkdel av arbetet; ordlistan går igenom registersidans begrepp på djupet.
Relaterade termer
- IT-tillgångens livscykel - stegen från inköp till avyttring som tillgångsperspektivet följer
- Utbytescykel för hårdvara - den planerade utbytestakten för hårdvaru-CI och tillgångar
- Licensrättighet - rätten till de licenser som ligger bakom programvaru-CI
- Permanent eller prenumerationslicens - två sätt att betala för programvaru-CI
- Licensiering per användare - platsbaserad licensiering kopplad till användare snarare än komponenter