How to Follow the Configuration Management Procedure?
How to Track Configuration Management Procedure? Closed-Loop Architecture with Asset Discovery, Monitoring, and AIOps. The procedure is documented, but is it really applied in the network, server, and cloud? In this article, we discuss which layer tracks each procedure step, how these layers are connected, and with which KPIs you can measure the health of the process.
The configuration management procedure is tracked not by a single tool, but by a cycle of four layers: Asset Discovery manages the "what is out there?" question and the CMDB, NCM manages the baseline, drift, and rollback, Monitoring manages the live impact of the change, and AIOps manages correlation, risk, and automatic actions. They all connect to the change record in ITSM via API; the process is measured with KPIs such as inventory accuracy, drift rate, unauthorized change rate, and MTTR.
Why Isn't a Procedure Enough on Its Own?
In most organizations, there is a configuration management procedure: a change request is opened, CAB approves, and it is implemented in a planned window. The problem is that the procedure stays on paper. Three typical disconnects are observed:
-
Inventory Gets
OutdatedRecords manually entered into the CMDB deviate from reality within weeks. Duplicate, ghost, and unregistered assets mislead impact analysis and root cause analysis. -
Undocumented
Change InvisibleA change made from the CLI during an emergency response might never turn into an RFC. The running configuration silently drifts from the baseline (configuration drift). -
Change / Incident
Link MissingWhen an outage occurs, the question "what changed in the last 2 hours?" is searched manually across multiple tools. Most of the average resolution time is spent on diagnosis.
Making the procedure trackable means attaching an automated evidence source to each step. Each of these sources lives in a different class of tools.
Seven Steps of the Procedure and Their Owners
The classic process (ITIL, ISO/IEC 20000, ISO 27001 A.8.9) consists of the following steps. The table shows which layer automatically tracks each step.
| Procedure Step | Asset Discovery | NCM | Monitoring | AIOps |
|---|---|---|---|---|
| CI Identification | Finds, classifies the device, writes to CMDB | Links the configuration file to the CI | – | – |
| Baseline | Hardware/software version baseline | Saves the approved configuration | Extracts performance baseline | Learns normal behavior |
| Change Control | Shows dependencies and impact area | Applies the change, backs up the previous state | Verifies the impact live | Scores the risk, correlates it with the incident |
| Status Accounting | Updates the CMDB | Keeps the version history | Logs the events | Establishes the change-incident relationship |
| Audit | Catches unregistered devices | Finds drift and non-compliance | Alerts on deviation | Highlights anomalies |
| Backup | – | Periodic and event-based backup | Monitors backup job success | – |
| Recovery | – | Applies rollback | Verifies recovery | Triggers automated remediation |
The Role of Each Layer
1. Asset Discovery: CI Identification and Inventory Accuracy
-
Multi-Source
DiscoveryPhysical, virtual, and cloud assets are discovered in a single stream using SNMP, WMI, SSH, ARP/LLDP/CDP, cloud provider APIs, and Kubernetes API. -
Enrichment
Model, serial number, firmware/OS version, installed software, interface, and port information are collected.
-
Topology and
DependencyWhich CI is connected to which service and which neighbor is extracted. Change impact analysis is based on this map. -
Reconciliation
Duplicate records are merged, CIs not seen for a long time are marked as "retirement candidates", devices seen on the network but not in the CMDB are reported as shadow IT signals.
Agentless Asset Discovery
2. NCM: Baseline, Drift, Compliance, and Rollback
A New Era in Network Management: SolarWinds Network Configuration Manager (NCM)
3. Monitoring: Live Impact of the Change
Before/After Comparison
Latency, packet loss, CPU/memory, interface error rate, and service availability are monitored during the change window.
Catching the Change Event
Syslog (e.g., "configured from console" log), SNMP traps, and API events are the first indicators of a non-RFC change.
Timeline Overlay
Change markers are placed on graphs. A metric deviation and a change are seen on the same axis.
Service Map
By monitoring the relationship between the business service and its underlying CIs, it becomes visible which service a deviation in a device reflects on.
Monitoring Systems and CI Data: Co-Management and Strategic Relationship
4. AIOps: Correlation, Risk, and Automation
Note: The value of the AIOps layer is limited by the quality of the data it feeds on. If the inventory is dirty, correlation is built between the wrong CIs; if change records are missing, the question "which change caused this incident?" remains unanswered. Therefore, the investment order is generally discovery, NCM, monitoring, and AIOps.
ODYA Automated NOC Solutions
End-to-End Example: A Switch Change
A VLAN and trunk setting is changed on a distribution layer switch. The cycle works as follows:
-
Step 1
RFC is opened. Asset discovery's dependency map lists the services connected to the switch and the access switches below it as the impact area. AIOps adds a medium-level risk score based on similar past changes.
-
Step 2
CAB approves, window is defined. Monitoring switches to planned maintenance mode for the related CIs during the window; out-of-window changes are considered abnormal.
-
Step 3
NCM applies it. Backs up the current configuration before application, processes the template with the RFC number, and adds the diff to the record.
-
Step 4
Monitoring verifies. Error rates on trunk ports, LLDP status on neighboring devices, and service availability are compared live.
-
Step 5
If a deviation is seen, AIOps steps in. Latency spikes, outages, alarm floods in an application service, and the recent change are merged into a single incident; this RFC is shown as the candidate cause.
-
Step 6
Rollback is triggered. Depending on the maturity level, it is either suggested to the team or, within approval rules, NCM automatically reverts to the previous version. Monitoring verifies recovery.
-
Step 7
Records are closed. CMDB relationships, ITSM record, configuration version, and incident history are updated. The new baseline is approved once the success criteria are met.
In a CLI change made on the same switch without an RFC, the chain starts differently: a syslog event triggers NCM's real-time comparison, a deviation from the baseline automatically opens a record in ITSM as an "unauthorized change", and a notification goes to the security/operations team.
Common Mistakes
Frequently Asked Questions
Q: What is the Difference Between Configuration Management and Change Management?
Configuration management records what state assets should be in (baseline) and what state they actually are in. Change management manages the request, risk analysis, approval, and implementation flow to change this state. They work together: change management updates the baseline in a controlled manner, configuration management holds the evidence of this.
Q: What is Configuration Drift and How is it Detected?
Configuration drift is the deviation of a device's running configuration from the approved baseline due to an unapproved or undocumented change. NCM tools detect drift by pulling the running configuration periodically and on an event-basis (syslog, trap, API) and comparing it with the baseline.
Q: What is the Role of AIOps in Configuration Management?
AIOps correlates configuration change events with monitoring alarms, suggests which change is linked to an incident, highlights abnormal deviations, and generates a risk score for a new change based on historical data. As maturity increases, it can automatically trigger steps like drift remediation and rollback.
Q: What is the Most Reliable Way to Keep the CMDB Updated?
It is to use automated discovery and reconciliation instead of manual entry. The asset discovery solution periodically scans the network, servers, cloud accounts, and container environments; detects duplicate, obsolete, and unregistered CIs and maps them to the CMDB.
Q: Which KPIs Should Be Monitored in This Process?
Inventory accuracy, discovery coverage rate, baseline coverage rate, drift rate and remediation time, unauthorized change rate, change success rate, change-induced incident rate, MTTD, MTTR, alarm noise reduction rate, and auto-resolved incident rate are the core KPIs.
Do You Want to Map This Cycle in Your Own Environment?
The ODYA Teknoloji team conducts working sessions that address configuration and compliance management with SolarWinds NCM, automated inventory and CMDB reconciliation with SPIDYA Asset Discovery, and correlation and ITSM integration with ODYA Automated NOC together. We can review your existing tool inventory and procedure together to identify which step is currently evidenced by which layer.
Contact Us →