Spend a week around teams whose automation never pages anyone and a pattern emerges: it is not better tools, it is nine small habits applied without exception. None costs money. None needs a committee. All of them come from the same source — the Ops Atlas’s write-up of AutomationOps, found at its AutomationOps page, which frames operational automation as something you operate, not merely something you write: chosen, tamed, bounded and owned. Steal the habits. They compound. Each one removes a specific, well-documented way for a routine job to ruin someone’s evening, and together they remove nearly all of them.
Nine AutomationOps Habits Worth Stealing
Read them in order; each one assumes the ones before it. The first three change what you write, the middle three change what you run, the last three change how you live with it.
Habit 1: Declare the end state; skip the imperative
“Start the queue worker” runs once, then misbehaves. “Ensure the queue worker is running” can run every minute for a year and change nothing, because when the state already holds, it does nothing at all. This is idempotency, and it is the difference between a job you re-run with confidence and one you re-run while holding your breath. Molecule, the testing tool for Ansible roles, even ships an idempotence step among its default tests — the tooling world considers this property important enough to verify without being asked, which tells you something. Watch your own scripts for verbs: start, stop, create and send are action words that age badly; ensure, verify and reconcile are state words that survive re-runs.
Habit 2: Treat an empty list as a stop sign
Every job that acts on a list of targets can be handed a broken list: renamed filter, moved file, clock drift. The habit is absolute — no targets, no action, loud complaint. Google’s Diskerase story is the permanent warning: a blank where a list should be was read as “remove everything”, and stored backups went with it. Writing the guard is minutes. Explaining its absence to a customer is months.
Habit 3: Send small waves, learn from the first
Whatever the job does, it should do a little of it first. A canary target, then a batch, health checks between, hosts running in series where the tooling allows. Ansible’s serial execution and failure-percentage limits exist because fleets taught the community this lesson repeatedly. Big bangs are exciting in exactly the wrong register. And the pause between waves is where judgement lives: a person who looks at the first wave’s results is still steering, even though the job is doing the driving.
Habit 4: Give each job its own identity
A shared super-account turns every script into every other script’s risk. One identity per job, trimmed to what the work needs, keeps a mistake local. The side effect is pleasant: permission reviews stop being archaeology and become reading a table. When a new job arrives, the question “what could this job touch if it went strange?” now has an answer you can read off the grant list instead of guessing.
Habit 5: Stamp the actions that must never repeat
Payments, emails, account creations — actions whose second execution is a bug. Give the action a tag the caller provides, and store that tag together with the action in one write; a retry then lands as a recognised duplicate and gets refused. This habit is old banking practice wearing modern clothes, and it has saved every team that adopted it at least one very embarrassing double-send. The subtle part is atomicity: the ID and the action must be written together, in one step, or the cruel edge case — recorded ID, lost action — creates the opposite failure and silently swallows work.
Habit 6: Halt on a number, not a mood
Agree in advance how many failures a run tolerates before it stops itself. The number ends the argument that otherwise happens mid-incident (“keep pushing” versus “roll it back”). Deciding while calm what to do while stressed is the oldest trick in operations, and it works here perfectly. Pick the number from consequence, not optimism: a report job might tolerate several failures before anyone cares, while anything touching customer data earns a budget of zero.
Habit 7: Fit a brake, then pull it on purpose
Every job gets a stop control; the estate gets a global one. The on-call engineer pulls either without asking permission — at night, permission is the enemy. Then drill it: twice a year for the riskier tiers is the Atlas’s recommendation. A brake that has only ever worked in theory is theory. Time the drill and publish the number; the gap between the first drill and the second is usually the most convincing slide your team will ever show an auditor.
Habit 8: Write the retirement date when you write the job
Automation rots quietly: APIs shift, staff move on, the job keeps running past the point anyone remembers why. Register every job — purpose, tier, limits, owner, review date — and revisit the entry on schedule. An orphan still holding more permissions than anyone can justify is the exact shape governance debt takes just before it turns into an incident report. The review date also gives you a socially acceptable way to delete things: a job that no longer justifies itself at review gets retired without anyone having to defend the decision emotionally, because the calendar made the decision first.
Habit 9: Count what the automation gives back — honestly
The Atlas’s arithmetic is short: monthly runs times minutes saved, minus the minutes a human still spends, minus maintenance hours, converted to net hours. Their worked example lands at 7.83 net hours from forty monthly runs, with the build paid back in about 5.1 months at 95 percent success. Alongside the headline number track two corrections: how often people had to rescue a run, and how often the automation itself caused trouble — a measure adapted from DORA’s change-failure rate. The pair keeps the headline honest. A job that returns hours but keeps causing trouble is not a bargain; it is a loan at a bad rate, and the numbers exist precisely to reveal that before the interest comes due.
Stealing the AutomationOps Habits Without Breaking Anything
Start with habit 2 on your riskiest job — it is an afternoon and it removes the scariest failure mode you own. Habits 4 and 5 pair well in the same week, since both are small code changes with immediate payoff. Save the register (habit 8) for after you have three or four governed jobs; a registry of one is lonely. The skills behind habits 1 and 3 come straight from mainstream tooling, and the site’s roadmap for AIOps training and certification shows where monitoring knowledge plugs into the same stack. If the whole programme feels bigger than the team, the piece on DevOps consulting for automation and delivery describes what outside help usually covers, and the starter guide to building a DevOps career suits the person who wants to be the one holding the checklist.
For the fridge door, the nine in one breath:
- Declare states, not actions.
- Empty list? Stop.
- Small waves first.
- One identity per job.
- Stamp what must not repeat.
- Halt on the agreed number.
- Brake it, then drill the brake.
- Register it, retire it on time.
- Measure honestly — hours back, rescues, self-inflicted trouble.
Nine habits, one quiet phone. That trade never gets old, and unlike most cultural advice in this industry, every item on the list can be finished before lunch.
