A routine change, five tools
Patching a production database cluster is routine, but it still involves a change record in ServiceNow, a list of dependent services from the CMDB, a CAB approval, a maintenance window, the job itself in Ansible or a vSphere snapshot followed by the patch, then someone watching Datadog afterward to make sure nothing broke. One engineer moves between five tools, and the change record is updated from memory the next morning.
Multiply that by every certificate renewal, firewall change and new application going into monitoring. IT operations spends much of its week coordinating work it already knows how to do.
The change as a workflow
- Request. An engineer fills in a change form: what, where, why and the proposed window. Kinetic creates the change record in ServiceNow.
- Impact. The workflow reads dependent services from the CMDB and lists them on the change, with their owners.
- Approval by risk. Standard changes on your pre-approved list go straight to scheduling. Normal changes go to the CAB with an AI-drafted summary. Emergency changes outside the window need the on-call manager.
- Implementation. At the start of the window, Kinetic takes the snapshot in vSphere or the cloud console, triggers the job in your automation tool and records the output.
- Verification. It checks the agreed monitors in Datadog or Splunk for a set period. If they stay healthy, the change closes. If not, the engineer is paged with the rollback step ready to approve.
- Record. The ServiceNow change is updated at each step, so the record is accurate when the change closes, not the next morning.
Other routine work
The same pattern covers new applications going live (monitoring set up, access groups created, CMDB entries added), certificate renewals ahead of expiry, and decommissioning. Each is a form, a workflow and calls to the tools that already do the technical work.
Kinetic doesn’t replace your automation scripts or your monitoring. It runs the process around them so they’re used the same way every time.
Infrastructure provisioning uses the same connections to vSphere and the cloud providers. When things go wrong rather than to plan, see incident response orchestration.