Speaker 1: A configuration management database, or CMDB, is the master inventory of systems and services.
Speaker 2: It lists configuration items and how they depend on each other so support teams have the full picture.
Speaker 1: Start by identifying key CIs such as servers, applications and network devices.
Speaker 2: Pull in attributes from source systems and link them together to show relationships.
Speaker 1: For example, the "web01" server might depend on the "db01" database service.
Speaker 1: Building the CMDB focuses attention on a concrete part of the work. Identify key configuration items, Populate attributes from trusted sources, and Map relationships between CIs.
Speaker 2: In practice, ask who owns the work, what evidence proves it happened, and what handoff comes next. Use the supporting details as a checklist: Populate attributes from trusted sources; Map relationships between CIs.
Speaker 1: Change requests should list the configuration items they will modify.
Speaker 2: After approval, update those CI records and compare discovery results to catch any unplanned drift.
Speaker 1: Keeping the CMDB accurate is a continual task.
Speaker 2: Automate discovery and update records after every approved change, then audit regularly to find gaps.
Speaker 1: Compare the observed state from discovery tools against the approved configuration to detect drift.
Speaker 1: Sometimes discovery shows a system in a state the CMDB never approved.
Speaker 2: This can come from emergency fixes, admins bypassing change control, or forgetting to remove retired equipment.
Speaker 1: When observed and authorised states diverge, troubleshooting and audits slow down because teams can't trust the data.
Speaker 1: A well-maintained CMDB accelerates incident troubleshooting and change planning.
Speaker 2: It reduces surprises from hidden dependencies and becomes your single source of truth.