En CMDB är en databas som lagrar information om IT-tillgångar (konfigurationsobjekt) och relationerna mellan dem.
En CMDB (configuration management database) är en databas som lagrar information om organisationens IT-tillgångar - servrar, applikationer, nätverksutrustning, stationära datorer - och, viktigast av allt, relationerna mellan dem. Varje post är ett konfigurationsobjekt (CI) med egna attribut, och varje CI kopplas till det den kör på, beror på eller ansluter till. Relationsdatan är det som skiljer en CMDB från ett enkelt inventarieregister: den svarar inte bara på “vad äger vi” utan på “vad går sönder om det här går ner”.
Vad CMDB står för och var det kommer ifrån
CMDB står för configuration management database. Begreppet kommer från ramverk för IT service management (ITSM) som ITIL, där CMDB:n är det centrala registret som ligger till grund för konfigurationshanteringen. I praktiken fungerar den som ett datalager för din IT-miljö: varje hanterad komponent registreras som ett konfigurationsobjekt, och databasen håller både objektets attribut och dess kopplingar till allt runt omkring. Den andra halvan - relationerna - är det som gör den till en CMDB och inte ett kalkylark över utrustning. Det är samma skillnad som skiljer en CMDB från bredare IT asset management (ITAM), som vi återkommer till nedan.
Vad räknas som konfigurationsobjekt
Ett konfigurationsobjekt (CI) är en komponent som är värd en egen post. Typiska exempel:
- Hårdvara-CI - servrar, switchar, brandväggar, lagringsarrayer, slutanvändarenheter
- Programvara-CI - applikationer, databaser, operativsystem, middleware
- Virtuella och moln-CI - virtuella maskiner, containrar, molninstanser och tjänster
- Tjänste-CI - affärstjänster komponenterna summerar till, som “e-post” eller “fakturering”
Varje CI har attribut (namn, version, miljö, ägare, plats) och relationer (“kör på”, “beror på”, “är del av”). Detaljnivån är det första designbeslutet: spårar du varje kabel drunknar din CMDB i skötsel, och spårar du bara servrar kan den inte svara på något användbart. En bra tumregel är att avgränsa efter användningsfall, inte efter tillgång - om en typ av CI aldrig dyker upp i en incident, en ändring eller en revision, låt den vara.
Så ser en CMDB-post ut: ett exempel
En CMDB-post är mer strukturerad än en rad i ett kalkylark. En enskild CI-post bär vanligtvis ett namn eller ID, en CI-typ (server, applikation, databas, nätverksenhet, molnresurs), en status, miljön den kör i (produktion, staging, utveckling), en ägare och tekniska fält som IP-adress eller version - och därtill, ovanpå allt det, sina relationer.
Ett konkret exempel gör det tydligt. En CI som heter app-prod-01 är av typen applikation, ligger i produktion, ägs av betalningsteamet och bär tre relationer: den kör på en virtuell maskin, beror på en betalningsdatabas och är del av checkout-tjänsten. Slår du upp den enda posten ser du, i en enda vy, allt som checkout-tjänsten vilar på. Multiplicera det med hundratals CI så får du en tjänstekarta - trädet av beroenden bakom varje affärstjänst, vilket är vad de flesta CMDB-verktyg ritar upp åt dig.
Relationer är poängen
Tänk dig en kedja: en faktureringsapplikation kör på en virtuell maskin, som kör på en värd i serverrummet, som ansluter via en switch. När den switchen ska bytas berättar CMDB:n - innan du rör något - att faktureringen går ner med den. Det är påverkansanalys, det främsta användningsområdet för en CMDB. Samma data fungerar baklänges vid felsökning: när faktureringen är långsam visar CMDB:n vilka komponenter under den som är värda att kontrollera, vilket är grunden för rotorsaksanalys. Därför är CMDB:n ett fast inslag i change management och incidenthantering i större IT-organisationer.
Varför CMDB:er blir inaktuella - och hur team håller dem aktuella
En CMDB är aldrig bättre än hur aktuell den är, och den klassiska fallgropen är välkänd: den fylls en gång under ett projekt och blir sedan inaktuell allt eftersom miljön förändras runt omkring den. Praktiker uttrycker det gärna rakt på sak - en CMDB fallerar inte vid lanseringen, den fallerar några månader senare, när ingen kan säga vem som äger en viss post. Två saker håller den ärlig. Det första är automatisk upptäckt: verktyg som skannar nätverket och molnkontona och uppdaterar CI när infrastrukturen ändras, så att databasen inte matas för hand. Det andra är tydligt ägarskap: varje CI behöver en utpekad ägare som ansvarar för dess riktighet, och de mest kritiska objekten kontrolleras om enligt ett schema. Utan en ändringsprocess som matar den blir en CMDB snabbt inaktuell - vilket är precis därför den passar team med mogna ITSM-rutiner och sällan passar dem utan.
CMDB, inventarieregister eller ITAM
Gränsen handlar om syfte. Ett inventarieregister finns till för ägande och ekonomi: vem som har varje enhet, vad den kostade, när garantin går ut, vad som händer vid avyttring. En CMDB finns till för driften: teknisk konfiguration och beroenden, som stöd vid ändringar och incidenter. ITAM är det bredare området; CMDB är ett verktyg, mest använt av ITSM-drivna team. Enkelt uttryckt: ITAM berättar vad du äger och vad det kostar, medan en CMDB berättar hur det är hopkopplat och vad som går sönder om du rör det. De överlappar kring själva hårdvaran - samma server syns i båda - men registrerar olika fakta om den. Licensrättigheter och förnyelser hör hemma i licenshanteringen, inte i en beroendegraf.
När ett litet team faktiskt behöver en
En CMDB lönar sig när du driver infrastruktur som andra system beror på och gör ändringar som kräver påverkansbedömning - egna servrar, en produktionsmiljö, något där avbrott kostar pengar. Den lönar sig inte som första register för team vars bestånd är laptops, smartphones och SaaS-platser; de frågorna handlar om ägande och förnyelser, och CMDB:ns klassiska fallgrop - att fyllas en gång och aldrig uppdateras - slår hårdast i team utan en ändringsprocess som matar den. För den majoriteten slår ett aktuellt inventarieregister en inaktuell CMDB, och verktyg som AMPthilly ger dig just ett sådant - med ägare, utlåning, dokument och revisionshistorik per tillgång, utan beroendemappning.
Relaterade termer
- Software asset management - att hantera programvarusidan av IT-beståndet
- Licenshantering - där rättigheter och förnyelser hör hemma
- Licensefterlevnad - att hålla sig inom villkoren för de licenser du äger
- IT-tillgångsavveckling - att ta uttjänt hårdvara ur drift på ett säkert sätt
- True-up - licensavstämningen som en leverantörsrevision utlöser