Getting started with infrastructure automation

Most infrastructure automation projects fail for the same reason: they start with the most interesting problem rather than the most repetitive one. The interesting problems are interesting precisely because they are varied, judgement-heavy and rare — which makes them terrible candidates for a first automation. This guide works through choosing a first workflow, scoping it safely, and building the evidence you need to justify the second one.

Start from your ticket data, not your intuition

Before designing anything, export the last ninety days of tickets or work items and group them by what was actually done. Not by the category field — that field reflects how requests were filed, not how they were resolved. Group by resolution.

You are looking for clusters where the same sequence of actions resolved the request. In most infrastructure operations teams, the top five resolution clusters account for a surprisingly large share of total volume: disk space reclamation, service restarts, access provisioning, quota or limit changes, and informational answers that required looking something up.

Rank candidates on three axes: how often the request arrives, how uniform the resolution is, and how much damage a wrong action could do. Your first automation should be high on the first two and low on the third.

Write the procedure down before you automate it

If a procedure cannot be written as an unambiguous sequence, it cannot be automated yet — and the problem is the procedure, not the tooling. Write it out as explicit steps, and for each step record four things:

• The input it needs, and where that input comes from.
• The system it touches, and the specific operation it performs there.
• How you would know the step succeeded, independently of the step reporting success.
• What a person should do if it fails.

That third point is the one teams skip, and it is the one that separates automation you can trust from automation you have to supervise. A step that reports success because the command exited zero has told you very little. A step that re-measures the symptom has told you something real.

Scope before capability

The instinct when building automation is to make it capable. The correct instinct is to make it narrow, then widen deliberately. For a first workflow, decide these boundaries explicitly:

• Which assets it may act on — one environment, one asset class, one customer tier.
• Which operations it may perform — a named list, not a general shell.
• How many assets a single run may touch, and how often it may run.
• Which conditions force it to stop and ask a person.

Decide what 'done' looks like

Before you turn anything on, write down the measurement that will tell you whether it worked. Good measurements for a first automation are concrete and already available in your existing systems:

• Share of requests in the target category resolved without a person opening the ticket.
• Time from request arrival to resolution for that category, compared to the previous quarter.
• Number of escalations from the workflow, and how many of those were correct escalations.
• Number of runs that could not verify their own outcome.

That last measurement matters more than it looks. A workflow with a rising rate of unverified outcomes is drifting away from the reality it was written against, and it will eventually produce a wrong result confidently.

Run it in parallel first

For the first two weeks, let the workflow run alongside your existing process rather than instead of it. Compare its conclusion against what the engineer did. You are checking three things: whether it classified correctly, whether the context it gathered was the context a human would have wanted, and whether its proposed action matches what actually happened.

Disagreements in this period are valuable rather than embarrassing. Each one is either a gap in the procedure you wrote down, or a case the procedure should explicitly exclude.

Then expand along one axis at a time

When you expand, change one dimension per iteration: a wider asset scope, or a new request variant, or removing a review gate — never two at once. If something degrades, you need to know which change caused it.

A reasonable sequence for the first six months is: one workflow in draft-only mode, the same workflow executing within a narrow scope, the same workflow across the full asset class, then two or three further workflows built on the patterns you now understand. Teams that try to launch eight workflows in month one usually end up maintaining none of them.

What to avoid

• Automating a procedure that is currently inconsistent. Standardise it by hand first; otherwise you are encoding whichever variant you happened to document.
• Giving a workflow general-purpose execution access because it is easier than registering specific actions. The registration is the control.
• Treating a successful exit code as a verified outcome.
• Hiding runs from the team that owns the systems. Visibility is what earns permission to widen scope.

Where to go next

Once a first workflow is running and measured, the natural second step is connecting the request system to the infrastructure action so the loop closes without a human relay. That pattern is covered in the guide on connecting support tickets to infrastructure actions.