Run a clinic front desk for a while and you start noticing which tasks repeat. The reminder texts. The nightly backup. The report that gets exported every Monday whether anyone asks or not. Somebody eventually writes a small program to handle one of them, then another, and within two years the clinic runs on a dozen little machines nobody has ever introduced to each other. Computing teams call that situation normal. The remedy they are converging on goes by the name AutomationOps, and a plain-terms AutomationOps guide lives at The Ops Atlas if you want the full treatment. In this piece I will walk through the idea the way I would explain it to a friend over coffee: what it covers, what it deliberately leaves out, and why the boring details — like who owns the backup script — turn out to matter more than the clever parts.
So What Is AutomationOps, Exactly?
Strip the label down and it means this: treat your automated actions like a service your colleagues quietly depend on. A restart job, a cleanup sweep, a failover routine, a certificate rotation, a nightly refresh across a fleet of machines — each one gets picked deliberately, built to fail safely, limited in how much damage it can do, and cared for by a named human right up to its deliberate retirement. That last part surprises people. Automation is not a one-time project that ends when the script works; it is more like a colleague who needs onboarding, reviews and eventually a retirement party.
One honest caveat before we go further. The word itself is young and a little contested. A few automation vendors have used it for their own things — one open-source company had a methodology by that name that has since been archived, and a big RPA vendor sells a product line under a similar banner. The meaning used here, the one the Atlas entry argues for, is about governing run-time actions as a production concern. When you read the phrase, think “management discipline for robots that press buttons”, not “a product you can buy”.
What It Deliberately Leaves Out
Good definitions are mostly about boundaries, so here is the fence line. Writing infrastructure files and keeping servers declared in code is its own field. Workflow engines that chain tasks into long pipelines are another. Commands typed into chat windows, network device changes, and the measurement of tedious toil each have their own labels too. The AutomationOps territory is narrower and more specific: the actions that fire at run time, out in the world, while your systems are live. Colleagues in those neighbouring fields are actually its best customers — every one of them eventually says “this change should happen automatically”, and the moment it does, it lands on this desk with its safety questions attached.
The Safety Questions, Asked in Order
Before any repeated action earns a place in production, five questions come up, and mature teams answer all five in writing:
- Can it rehearse? The job should be able to announce its plan without executing it. Small catch worth knowing: a rehearsal mode may skip the raw commands inside a playbook, so a dry run that never touches the risky line proves less than it seems.
- Does it know its targets? A job handed an empty list of machines must halt, not shrug and assume “all of them”. A cloud provider’s cleanup once received just such an empty list and kept deleting anyway; the industry has treated blank-means-stop as law ever since.
- How big a bite does it take? Hundreds of hosts should never change in one gulp. Wise setups walk a single canary machine first, then small waves, checking health between each.
- When does it give up? A sensible run stops after a few failures and fetches a human, rather than ploughing through a hundred broken targets because the loop said so.
- How do we stop it? Every job needs an off switch, plus one big red lever above all jobs, exercised regularly enough that using it under pressure is muscle memory.
The Quietest AutomationOps Idea: Make It Predictable
Here is my favourite concept in the whole field, because it explains a lot of midnight incidents. A repeated action should aim at a state, not perform a gesture. “Ensure the service is running” is a state — run it ten times and the tenth run shrugs, sees everything already fine, and does nothing. “Start the service” is a gesture — run it ten times and you may get ten errors, or worse, ten instances. Jobs built as states are calm and re-runnable. The jobs that cannot be made re-runnable — payments, account creation, outbound messages — get a trick borrowed from banking: the caller attaches a unique reference number to each request, the system records it the instant it arrives, and a duplicate with the same number is politely refused. One huge engineering organisation leaned on this so heavily that its repair jobs could legally run every fifteen minutes around the clock, because a repeat was guaranteed to be harmless.
A Cautionary Story Worth Retelling
Why does any of this matter? In early 2017 an engineer at a very large cloud provider was debugging a slow storage system and typed a command with one small input wrong — the wrong kind of identifier, in the wrong corner of the command. The routine did what it was told and removed far more stored data than intended, and a huge slice of the internet wobbled for hours because a single company’s storage region went dark. No attacker, no exotic bug: a routine with more reach than its operator realised, and no gate between the typo and the consequences. Every guardrail in the previous section exists because of evenings like that one. The typo was human. The blast radius was a choice.
How Grown-Up Is Your Setup?
The Atlas draws its maturity ladder with five rungs, and it is refreshingly blunt about where most teams stand. Rung one is improvisation: scripts everywhere, folklore everywhere, no inventory. Rung two is sharing — the scripts move into a code repository, which is progress, but nobody owns them, and one shared login runs the lot. Rung three adds the safety questions from earlier. Rung four makes the whole estate declared and policy-checked, so the rules live in files rather than in someone’s memory. Rung five, rare and lovely, is a system that notices its own drift and corrects it. Most organisations plant themselves firmly on rung two and wave. Climbing is less about new tools than about naming owners and writing down the rules — dull work that pays like a menace.
A One-Page Experiment for Next Week
You do not need a platform budget to begin. Open a document and list every scheduled or triggered action you can find on your systems: the backups, the sweeps, the syncs, the things a former colleague scripted in a hurry. Next to each one, write three facts — who owns it now, what it is allowed to touch, and the exact command that stops it. Expect the exercise to be humbling; most teams find orphaned jobs, mystery credentials and at least one task whose failure nobody would notice for weeks. That single page is the seed of a proper registry, and the gaps in it are your real risk register, more honest than any brainstorm could be. Fill the owner column first. Names fix things; committees rarely do.
Bringing It Back to the Waiting Room
If this all sounds abstract, think about how good clinics already operate. Nobody treats back pain by guessing; there are structured treatment options to weigh before anyone talks about an operation, and a sensible patient asks what each one involves. Automated actions deserve the same graduated care — try the reversible thing first, keep the aggressive option gated behind a second opinion, which is exactly how specialist spine care gets involved at the right moment rather than at the convenient one. And just as patients benefit from understanding the whole field of modern medicine before choosing a path, automation owners benefit from seeing how their discipline fits into the wider family of operations practices described in this guide to the XOps family. Pick jobs that repeat and are understood, build them to be switched off, review them on a calendar, and rehearse the human skills too — because the moment everything is automated is the moment nobody remembers how to do it by hand, and that is precisely when you will need to.