Vad är ett konfigurationsobjekt (CI)?

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 hela följdverkan syns när något slutar fungera.

Det här går vi igenom

• Konfigurationsobjekt: den korta definitionen
• Vad CI står för (och vad det inte står för)
• CI-typer med underklasser
• Vad en CI-post innehåller
• Relationstyper mellan CI
• CI:ets livscykel
• Så avgör du vad som blir ett CI
• Var CI-datan kommer ifrån
• Så håller du CI-posterna pålitliga
• CI, inventariepost och lagerrad
• Behöver du verkligen en CMDB?
• Vanliga frågor

Konfigurationsobjekt: den korta definitionen

CI = configuration item, konfigurationsobjekt. ITIL definierar det som varje komponent som behöver hanteras för att en IT-tjänst ska kunna levereras. ISO/IEC 20000 formulerar samma idé som varje element som måste styras för att leverera en tjänst. Det praktiska testet: om en förändring av den kan påverka tjänsteleverans, tillgänglighet, säkerhet eller regelefterlevnad, då är den ett konfigurationsobjekt.

Testet är avsiktligt trubbigt, för alternativen som folk gärna griper efter - “är den dyr?”, “aktiverade vi den i balansräkningen?”, “är den fysisk?” - ger alla fel lista. En domänförnyelse för 40 kronor är ett CI. En reservskärm för 9 000 kronor i ett skåp är det inte.

Vad CI står för (och vad det inte står för)

Inom IT service management betyder CI konfigurationsobjekt - den betydelse som används genomgående på den här sidan.

Inom systemutveckling betyder CI continuous integration - det automatiska bygg- och teststeget i en CI/CD-pipeline. Det har ingenting med CMDB:er att göra. Därför är den nakna förkortningen tvetydig i varje samtal som spänner över både utveckling och drift, och därför säger plattformsteam ofta “konfigurationsobjekt” högt för att undvika missförstånd.

Inom system- och försvarsteknik betyder konfigurationsobjekt något äldre och strängare: en sammansättning av hårdvara och/eller programvara som pekats ut för separat konfigurationsstyrning och formellt kontrolleras mot en baslinje. Där möter du hårdvarukonfigurationsobjekt (HWCI), programvarukonfigurationsobjekt (CSCI), gränssnitts-CI och COTS-CI, spårade genom funktionella, allokerade och produktbaslinjer där en ändringsledningsgrupp godkänner varje revision. Samma uttryck, en annan disciplin - och en vanlig källa till förvirring när teknik- och IT-avdelningar delar ordförråd men inte definition.

CI-typer med underklasser

De flesta CMDB:er organiserar CI i en klasshierarki så att gemensamma attribut och regler ärvs i stället för att skrivas in på nytt. De vanliga toppklasserna:

• Hårdvaru- och infrastruktur-CI - fysiska och virtuella servrar, lagringssystem, lastbalanserare, hypervisorer, skrivare, och de datorer och andra slutpunkter som en tjänst faktiskt beror på.
• Programvaru- och applikations-CI - operativsystem, verksamhetsapplikationer, middleware, databaser, containeravbilder och SaaS-instanser, var och en med sin version.
• Nätverks-CI - routrar, switchar, brandväggar, VLAN och subnät, DNS-poster, VPN-tunnlar, accesspunkter och resten av din nätverksutrustning.
• Moln- och plattforms-CI - hanterade databasinstanser, Kubernetes-kluster, lagringsutrymmen, IAM-roller, meddelandeköer, och de konton eller prenumerationer de bor i.
• Tjänste-CI - själva den kundvända tjänsten (“lön”, “e-post”), plus API:er och gränssnitt mellan tjänster.
• Dokumentations-CI - driftmanualer, nätverksscheman, SLA:er och OLA:er, installationsanvisningar, och de standardavbilder som installationer skärs ur.
• Fastighets-CI - serverrum, UPS-aggregat, PDU:er, kyla och ventilation, och fysisk passerkontroll där ett avbrott i dem drar med sig IT i fallet.
• Leverantörs- och avtals-CI - leverantören, supportavtalet eller den licensrättighet som en tjänst juridiskt eller praktiskt vilar på.

Vissa modeller registrerar även personer och roller som CI, så att “vem är ansvarig för det här” hamnar i beroendekartan i stället för i någons huvud. Det avgörande testet är hela vägen påverkan på tjänsten, inte priset. Ett billigt SSL-certifikat är ett solklart CI eftersom tjänsten faller när 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 inventarier väl värda att hålla koll på, men sällan värda att modellera som CI.

Vad en CI-post innehåller

En användbar CI-post är kort och komplett snarare än lång och halvifylld. De fält som nästan varje CMDB förväntar sig:

• Unik CI-identifierare - ett stabilt inventarienummer som överlever namnbyten och nya IP-adresser.
• Namn - en läsbar etikett enligt en dokumenterad namnstandard.
• Typ eller klass - var den sitter i klasshierarkin.
• Status - aktiv, under underhåll, inaktiv, avvecklad.
• Miljö - produktion, staging, test, utveckling.
• Ägare - en namngiven person eller ett team som är ansvarigt.
• Version, modell eller build - för allt som patchas eller uppgraderas.
• Plats - datahall, adress, molnregion eller konto.
• Serienummer eller instans-ID - tillverkarens eller plattformens referens.
• Leverantör och supportavtal - vem du ringer, och hur länge.
• Kopplad tjänst - den verksamhetstjänst komponenten i slutänden stödjer.
• Relationer - länkarna till andra CI, som vi tar härnäst.
• Ändringshistorik - en händelselogg över vad som ändrades, när och av vem.

Motstå lusten att lägga till fler. Varje attribut är ett fält som någon måste underhålla, och det snabbaste sättet att göra en CMDB opålitlig är att fylla den med kolumner ingen läser.

Relationstyper mellan CI

Relationerna är det attribut som gör det verkliga jobbet. Ta bort dem och CMDB:n faller ihop till en vanlig IT-inventering med några extra fält. De flesta modeller grupperar dem i fyra familjer:

• Beroende - “kör på”, “beror på”, “använder”. Applikationen beror på databasen.
• Inneslutning - “driftas av”, “del av”, “medlem i”. Den virtuella maskinen driftas av hypervisorn; disken är en del av lagringssystemet.
• Ägande - “ägs av”, “supportas av”, “förvaltas av”. Kopplar ett CI till ett team eller en person.
• Påverkan - den härledda vyn: vad som faller nedströms när det här faller.

En genomräknad kedja gör poängen tydlig. Accesswitch → hypervisorvärd → virtuell maskin → databasinstans → betaltjänst. När switchen dör låter den enda länken servicedesken namnge betaltjänsten på sekunder i stället för att vänta på att kunder hör av sig. Läs samma kedja åt andra hållet och den blir en konsekvensbedömning inför en ändring: att patcha hypervisorn betyder att du måste planera runt betalningarna. Läs den en tredje gång och den blir risk- och regelefterlevnadsomfattning - allt i den kedjan omfattas av de kontroller som skyddar betaldata.

Det är tre olika jobb som betjänas av en och samma uppsättning länkar, vilket är precis därför relationsdata är värd underhållet där den verkligen underhålls, och värdelös där den inte gör det. Samma princip driver modellering av tillgångshierarki på registersidan, till en mycket lägre kostnad.

CI:ets livscykel

En CI-post har ett eget liv som löper ungefär parallellt med IT-tillgångens livscykel:

1. Planera och utforma - komponenten specificeras; CI-klass och namnkonvention väljs.
2. Köp in eller bygg - inköpt, provisionerad eller kompilerad.
3. Identifiera och registrera - ett unikt CI-ID tilldelas och posten skapas. Det här är steget team hoppar över, och allt nedströms ärver luckan.
4. Testa - verifierad mot avsedd konfiguration eller baslinje.
5. Driftsätta - flyttad till produktion, med relationerna registrerade i takt med att de skapas.
6. Tidigt driftstöd - noga bevakad; posten korrigeras medan detaljerna fortfarande är färska.
7. I drift - i tjänst, med varje ändring speglad i posten.
8. Avveckla och avyttra - status satt till avvecklad, relationerna plockade isär, och det fysiska eller avtalsmässiga slutet hanterat genom avveckling av utrustning och IT asset disposition.

Varje steg motsvarar ett statusvärde som posten faktiskt bär: aktiv, under underhåll, inaktiv, avvecklad. Ett statusfält som ingen uppdaterar är den första delen av en CMDB som ruttnar, och avvecklade men fortfarande länkade CI är den vanligaste orsaken till att en beroendekarta tyst slutar stämma med verkligheten.

Så avgör du vad som blir ett CI

Fyra frågor, i ordning:

1. Behöver en förändring av den granskas eller revideras? Om en ändring passerar en ändringsledningsgrupp eller landar i en efterlevnadsrapport - modellera den.
2. Påverkar ett haveri en tjänst som användarna märker? Om ja är dess beroenden värda att kartlägga.
3. Är det någon som faktiskt äger den? Ett CI utan namngiven ägare är en post utan skötare.
4. Kommer posten att hållas aktuell? Om det ärliga svaret är nej - skapa den inte.

Sätt sedan detaljnivån: använd den grövsta klassificering som fortfarande svarar på dina frågor. Varje extra detaljnivå multiplicerar underhållet utan att nödvändigtvis göra besluten bättre. “Databasserver” som ett enda CI räcker ofta; att dela upp den i chassi, RAID-styrkort och enskilda diskar gör det sällan, om du inte byter de delarna oberoende av varandra.

För moln och kortlivade resurser: modellera den stabila mallen i stället för varje flyktig instans - autoskalningsgruppen, inte de fyrtio containrar den startade i eftermiddags; funktionsdefinitionen, inte varje anropsmiljö. Disciplin i taggningen i molnkontot gör mer nytta här än hur mycket modellering på instansnivå som helst. Och regeln som styr allt: modellera inte det du inte kommer att underhålla.

Var CI-datan kommer ifrån

CI-poster skapas och hålls aktuella på tre sätt, oftast i kombination.

Manuell registrering sker vid inköp eller driftsättning. Det är den mest exakta vägen för allt som saknar API - fastighets-CI, dokumentation, leverantörsavtal - och den sköraste, eftersom den helt hänger på att någon kommer ihåg.

Massimport hämtar in det som redan finns i kalkylblad, inköpsunderlag eller ett annat system. Så börjar de flesta register, och det är en helt rimlig start förutsatt att datan städas innan den landar snarare än efteråt.

Automatisk upptäckt frågar miljön direkt. Agentlös upptäckt läser från moln-, virtualiserings- och nätverks-API:er; agentbaserad upptäckt installerar programvara på värdarna för djupare detaljer som installerade paket och körande processer. Kontinuerlig synk slår ett veckojobb, eftersom en CMDB som ligger en vecka efter är precis lika vilseledande som en som ligger ett år efter, i just den incident där det spelar roll. Asset discovery går igenom marknadsbilden mer i detalj.

Den viktiga brasklappen: automatiken löser insamlingen, inte strukturen. Upptäckt säger att en maskin finns; den kan inte säga vilken affärstjänst den stödjer, vem som äger den, eller om dubbletten den just skapade i själva verket är en separat värd. Klassificering, ägarskap och granskningsregler förblir mänskligt arbete, vilket är varför även helt genomsökta CMDB:er förfaller - och varför oupptäckta hörn som skugg-IT förblir osynliga oavsett.

Så håller du CI-posterna pålitliga

En delvis korrekt CMDB är farligare än ingen CMDB alls, eftersom folk litar på den mitt i en incident. Underhållsdisciplinen som förhindrar det:

• Standardisera namngivning och nyckelfält. En namnkonvention, dokumenterad, tillämpad vid skapandet. Att rätta namn i efterhand är eländigt arbete.
• Utse en namngiven ägare per CI eller per klass innan en incident blottar luckan, inte under en.
• Stäm av dubbletter och föräldralösa poster enligt schema. Upptäckt skapar dubbletter; avvecklingar lämnar föräldralösa poster. Avstämning av inventarier är rutinen som fångar båda, och det är så spökposter - poster för saker som inte längre finns - rensas bort.
• Begränsa attributen till fält som någon faktiskt läser. Oanvända fält förblir inte tomma; de fylls med rimligt låtande nonsens.
• Registrera ändringar när de sker, inte i en årlig storstädning. Den årliga storstädningen är där CMDB-projekt går för att dö.

Ägarskapet spelar roll på processnivå också: en konfigurationsansvarig äger standarderna och granskningarna, tjänsteägarna är ansvariga för de CI som ligger bakom deras tjänster, och driften speglar verkliga förändringar in i posterna. Utan de tre rollerna är datakvalitet ingens jobb.

CI, inventariepost och lagerrad

De tre beskriver samma fysiska värld från olika håll.

Mängderna överlappar utan att vara desamma. En produktionsserver är både inventarie och CI. En reservskärm är en inventarie 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.

Tydligast blir det med en enda virtuell maskin. I ITAM är den ett kostnadsställe, en licenskonsument och en rad i avskrivningsplanen, med en plats i utbytescykeln för hårdvara bakom sig. I CMDB:n är samma maskin en nod med fyra länkar till andra noder. Ingen av vyerna är hela bilden, och ingen av dem ersätter den andra.

Behöver du verkligen en CMDB?

CMDB:er 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.

Tecken på att du behöver en: tjänster som hakar i varandra där en komponent stödjer flera andra; formell ändringshantering med en granskningsgrupp; reglerade krav på upptid eller revision; och ett driftteam så stort att ingen längre bär hela kartan i huvudet.

Tecken på att ett välskött inventarieregister räcker: några dussin slutpunkter; en handfull SaaS-tjänster; en eller två personer som sköter IT; och beroenden så enkla att de går att rita på en whiteboard på tio minuter.

Mellanvägen, som passar de flesta organisationer: börja med ett korrekt register - ägare, status, plats, serienummer, historik - och lägg till relationsmodellering bara för den lilla grupp komponenter vars haveri är verkligt dyrt. Det ger dig det mesta av värdet i incidenthanteringen utan att du skriver på för underhåll i företagsskala. Börja med ett enkelt inventarieregister går igenom hur du gör det, och sidan om CMDB beskriver vad den fullständiga varianten innebär om du landar i att du behöver den.

Vanliga frågor

Vad betyder CI inom IT?

Det beror på vilket rum du står i. Inom IT service management betyder CI konfigurationsobjekt (configuration item) - en komponent som registreras i en CMDB eftersom en tjänst beror på den. Inom systemutveckling betyder CI continuous integration, det automatiska bygg- och teststeget i en CI/CD-pipeline. De två har inget med varandra att göra, så i samtal där både utveckling och drift sitter med är det värt att säga vilket du menar.

Vad är ett konfigurationsobjekt enligt ITIL?

ITIL definierar ett konfigurationsobjekt som varje komponent som behöver hanteras för att leverera en IT-tjänst. I ITIL 4 ligger detta under praktiken tjänstekonfigurationshantering, vars uppgift är att hålla korrekt information om CI:n och relationerna mellan dem. Posterna bor i en eller flera CMDB:er, och det praktiska testet är oförändrat: om en förändring av komponenten kan påverka en tjänst är den ett CI.

Vad är skillnaden mellan ett konfigurationsobjekt och en tillgång?

En tillgångspost svarar på frågor om ägande och ekonomi - vad den kostade, vem som har den, när garantin går ut. Ett CI svarar på frågor om tjänsten - vad komponenten stödjer och vad som går sönder om den slutar fungera - och därför bär ett CI relationer till andra CI. Samma server kan vara båda delarna. Många inventarier blir aldrig CI (reservskärmar, möbler), och en del CI är inte ekonomiska tillgångar alls (dokumentation, ett gratis programbibliotek).

Vad är skillnaden mellan en CMDB och ett inventarieregister?

En CMDB lagrar konfigurationsobjekt och, framför allt, relationerna mellan dem, så att du kan följa vad som faller när en komponent faller. Ett inventarieregister lagrar ägande, kostnad, plats, status och livscykel för det du äger. En och samma virtuella maskin kan finnas i båda - som en avskrivningsrad i registret och som en länkad nod i CMDB:n. För de flesta små och medelstora IT-team ger ett korrekt register den större delen av värdet till en bråkdel av underhållet.

Vilka är exempel på konfigurationsobjekt?

Hårdvara: servrar, nätverksswitchar, brandväggar, de datorer som en tjänst beror på. Programvara: operativsystem, applikationer, databaser, middleware. Utöver det allt som hanteras för att leverera en tjänst: SSL-certifikat, molninstanser, driftmanualer och SLA-dokument, och själva tjänsterna. Varje CI bär en identifierare, en ägare, en status, en version där det är relevant, och relationer till de CI det beror på.

Måste varje inventarie vara ett CI?

Nej. Ett CI förtjänar sin plats där relationsdatan underhålls aktivt - en CMDB full av inaktuella länkar är sämre än ingen CMDB alls, eftersom folk litar på den under incidenter. Ett vanligt grepp är att modellera bara de komponenter vars haveri påverkar tjänster (servrar, nätverksutrustning, kärnapplikationer) som CI, och hålla allt annat som vanliga poster i inventarieregistret med ägare, status och livscykel.

Verktyg som gör det enklare

Om det är mellanvägen du landar på handlar jobbet om ett korrekt register snarare än en beroendegraf. AMPthilly ger varje post en plats i registret med kategori och underkategori, status (i bruk, i förråd, på reparation, avvecklad), aktuell ägare och plats, serienummer, leverantör, inköpsdatum och garantislut, plus egna fält per tillgångstyp för det som är specifikt i din miljö. Fysisk utrustning, programvarulicenser och förbrukningsmaterial bor i samma register, du kan importera det du redan har via CSV och exportera ut det igen, utskrivbara QR-etiketter öppnar rätt post direkt i mobilens webbläsare utan app att installera, och en permanent händelsehistorik registrerar varje utlåning, återlämning, överföring, statusändring och fältändring. Gratisplanen täcker 3 användare och 25 poster utan kort.

Sammanfattningen

Ett konfigurationsobjekt är varje komponent du måste hantera för att leverera en IT-tjänst, identifierad utifrån påverkan på tjänsten snarare än pris, och gjord användbar av relationerna som registreras vid sidan av. Får du de fyra grunderna rätt - ett unikt ID, en namngiven ägare, en status någon uppdaterar, och länkar som speglar verkligheten - betalar CMDB:n för sig i snabbare triage och säkrare ändringar. Får du dem fel blir den en självsäker, inaktuell karta som folk följer rakt in i fel avbrott. Är din miljö tillräckligt liten för att beroendena fortfarande får plats i en persons huvud: börja med ett välskött inventarieregister och lägg till CI-modellering bara där ett haveri är verkligt dyrt.

Relaterade termer

• CMDB - databasen där konfigurationsobjekt och deras relationer bor
• Inventarieregister - ägar- och ekonomivyn som de flesta team behöver först
• 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 inventarier
• 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