You have written a script. It works. You schedule it, feel briefly like a genius, and move on with your life. Six months later that script is still running — unwatched, unloved, and now holding more access than you ever intended — and nobody, including you, remembers exactly what it touches. Multiply that small story across every team in every company and you have the mess this article is about. AutomationOps is the tidy label The Ops Atlas prints next to this mess: the habit of treating routine automation as a production system that someone chooses, someone guards, and someone owns until the day it retires. No vendor sells it as a box; it is closer to a set of habits than a product, which is good news, because habits are free to start today.
What Problem Does AutomationOps Actually Solve?
Plainly: repeats are where companies get hurt. The first time a human does a task, caution is high. The hundredth time a script does it, caution is zero, because scripts have no caution at all. They will happily restart a hundred servers when you meant ten, email a thousand customers when you meant one, or delete a database because a config value arrived empty. Real outages follow exactly this shape — an AWS outage in 2017 began with a mistyped input, and a 2022 automation at Atlassian wiped 883 customer sites in under half an hour because it was fed the wrong kind of identifier. Nobody was careless on purpose. The systems simply lacked brakes.
So the discipline asks four questions of every automated job. What does it change? How much damage can it do in its worst minute? Who stops it when it misbehaves? And who owns it until it is decommissioned? If those questions have answers written down somewhere, you are doing AutomationOps. If they live only in someone’s head, you have scripts, not a system.
Sign Before You Drive: The Beginner’s Mental Model
Borrow an idea from renting a car. Before you drive off, you check the mirrors, confirm the fuel, and glance at the brakes — every trip, not just your first. Automated jobs deserve the same tiny ritual. The Atlas organises the checks by how much harm a job could do, sorting them into tiers: read-only work at the bottom needs almost nothing; single-target, reversible changes need a little; multi-target changes need rehearsals, waves, and health checks; and anything that destroys data sits at the top, where a second person must approve and deletions land somewhere recoverable first. Security standards agree — NIST’s dual-authorisation controls exist precisely because catastrophic actions should never rest on one person’s confidence.
The Five Checks, Translated Into Plain Language
- Rehearse it. Run the job in a mode that shows planned changes without making them. Caveat worth knowing early: in Ansible, check mode may skip command and shell steps unless flagged, so a clean rehearsal only counts if the steps really executed.
- Refuse on empty. If the target list resolves to nothing, the job must stop. Google learned this the hard way when a removal tool called Diskerase mistook an empty protection list for permission to erase; “empty never means all” has been the rule ever since.
- Go in waves. Act on a small group first — one machine, then ten, then the rest — and stop automatically if a wave fails. Ansible’s serial keyword and max_fail_percentage exist for exactly this.
- Set a failure allowance. Decide beforehand how many failures halt the run. Three breakdowns out of fifty is information, not bad luck to push past.
- Install the brakes. Every job gets a kill switch, plus a global one, and the on-call team practises using them twice a year for anything risky.
One more plain-language habit makes all five easier: describe jobs by the end state you want, not the action you would type. “Ensure the service is running” can be repeated all afternoon without harm; “start the service” breaks the second it runs twice. Engineers call this idempotency, and it is the reason Google’s repair automations could loop every fifteen minutes without anyone holding their breath. When a task truly cannot repeat safely — payments, emails, account creation — hand it a unique request ID recorded the instant it executes, so duplicates are impossible by construction rather than by vigilance.
A Mini Glossary for Your First Week
- Dry run: a rehearsal pass that reports intended changes without applying them.
- Blast radius: everything a job could conceivably touch if it went wrong. Capping it is the whole game.
- Failure budget: the number of tolerated failures before a run halts itself.
- Kill switch: a pre-built, tested way to stop one job — or all of them — immediately.
- Risk tier: the harm category a job sits in, which decides which guardrails are mandatory.
- Request ID: a unique label supplied by whoever triggers a non-repeatable action, stored atomically so reruns cannot duplicate it.
- Registration: the one-page record of a job: owner, purpose, tier, limits, review date.
- Retirement: the planned end of a job. Automation rots; every script eventually deserves a funeral.
Keep this list nearby and you will understand most conversations on the topic. The vocabulary matters less than the reflex it trains: before any job runs, someone decided its limits, and after it runs, someone can see what it did. Guardrails that trip in the wild are worth charting too — teams count these “guard trips” the way pilots count warnings, because a rising number means reality is drifting away from what the job assumes. And when a human has to take over mid-run, that moment gets logged as well; a climbing takeover rate is the earliest honest signal that a job has outgrown its design.
Your First Week With AutomationOps: A Tiny Plan
Day one, list every scheduled job you can find — yours, your team’s, and the mysterious ones in shared folders. Day two, write one line per job: what it changes and who owns it; anything unclaimed gets a claimant or a retirement date. Day three, mark each job read-only, reversible, or dangerous, and let that marking decide what protection it gets. Day four, add the empty-list refusal to every job that takes targets; it is usually three lines of code. Day five, find or build the stop button and tell the team where it lives. That is a genuine first week, no purchases required, and it mirrors the advice in a good roadmap for new clients: survey, record, prioritise, protect, then review.
Two cautions from people further along the road. Do not automate a broken human workflow verbatim — you will just produce the same mess at higher speed; clean the process first, then encode it. And do not demand approval for everything, because approvers who sign fifty things a day stop reading them, and your safety theatre will cost more than it saves. Approval belongs to the dangerous tier only. If you want the wider context for where this fits in a modern engineering career, pair it with a calmer route into DevOps, and with thinking about connecting websites, cloud platforms and AI tools as one estate rather than separate hobbies. Automation is simply the newest resident of that estate — and AutomationOps is how you give it a responsible tenancy agreement instead of leaving the keys under the mat. When you are ready for the full map of controls, tiers and metrics beyond this primer, the AutomationOps entry at The Ops Atlas is the single best next read.
