NETWORK CONFIGURATION MANAGEMENT
Situation: A Network Operator Makes a Change
- A network operator makes a change to the configuration of a network device but may not have thought to reflect that change in the configuration management database (CMDB).
- A monitoring Syslog service like Solarwinds, ELK Stack or Splunk would capture and log the change but not perform any CMDB query to ensure consistency.
- Over a period of time a "Configuration Drift" will develop whereby the actual configuration of various network devices and the CMDB configuration data will differ.
- Ultimately, there are potentially serious security and compliance risks introduced by an accumulating "Configuration Drift" in the absence of a more automated approach to ensuring the actual and intended configurations are accurately reflected in the CMDB.
Manual Change Management
The Conventional Workflow Approach
A user recognizes that a service has gone down and creates a ServiceNow ticket. Service Ops assigns the ticket to NetOps with a Priority 1.
NetOps team members now manually start diagnostics, discovering that an interface is down. Remediation action is performed to bring up the interface.
NetOps team now either updates the ticket if successful or continues running diagnostics to discover why the interface went down, staying as a priority level 1 task. The ServiceNow record is then updated and closed.
Orchestral.ai's Composer Solution
Automated Change Management
Composer Event-Driven Change Management
- Composer monitors the Syslog service, such as SolarWinds, ELK Stack, Splunk or similar for the specific "event" of a configuration change.
- Once a config change has been detected, Composer will initiate a "Config Drift" workflow that begins with a query check of the Configuration Management Database (CMDB).
- Composer retrieves from the CMDB the stored configuration of the target (i.e changed) device and brings this data into the "Config Drift" workflow.
- Leveraging the hundreds of available device integrations, Composer will then extract the running config of the target/changed device.
- Next, Composer performs a diff to compare the stored device configuration against the changed device configuration with the result captured for audit purposes.
- Composer will then prompt the operations team via Chatops, email or similar alerting tool to make them aware of the change and provide them an opportunity to decide which config to retain.
- Should the operations team choose to retain the CMDB config, then Composer will create an IT Service Management (ITSM) ticket with high priority to replace the running config with the stored CMDB config.
- If the operations team chooses to retain the changed config, then Composer will update the CMDB with the changed config to ensure that the actual running config is correctly captured in the CMDB.
- Finally, the audit trail of this operation is saved by Composer by opening an ITSM ticket and attaching the related data.