Ask a room of pilots what they think about autopilot and you will hear the same split: some trust it blindly, others hand-fly everything out of distrust. Server rooms are no different. People either let scripts do whatever they want or refuse to automate at all, and both camps carry beliefs that do not survive contact with evidence. AutomationOps — the craft of treating operational automation as a production system with owners, limits and paperwork, as catalogued in The Ops Atlas entry on AutomationOps — exists precisely because those beliefs keep causing outages. Below are six myths we keep meeting, each answered the short, practical way. No vendor pitch, no theory mountain: just what the belief gets wrong and what to do instead.
Six AutomationOps Myths Worth Retiring
Each myth below sounds reasonable. That is exactly why it spreads. Treat them the way you would treat a worn tyre — replaceable once you spot the signs, dangerous once you ignore them. And note the pattern running through all six: each one takes a real truth (scripts save time, rehearsals help, simplicity matters) and keeps stretching until the truth runs out.
Myth 1: It ran fine last month, so it is safe
Past success proves nothing about the next run. Environments drift: disks fill, DNS records change, colleagues rename things. A cron job that cleaned logs for a year will happily delete the wrong directory the day someone moves a mount point. The record books are blunt about this — in 2012, Knight Capital lost around $460 million in under an hour after code reached production without proper review and an old flag reactivated dead logic. The lesson is not “never automate”. It is that a history of quiet success is not a control. Registration, a named owner and a review date are what turn a lucky script into a managed one. If nobody knows a job exists — the classic script sitting in somebody’s home directory — it is not safe, it is invisible.
Myth 2: Automation removes human error
It moves it. Lisanne Bainbridge made the point in 1983 in “Ironies of Automation”: push the human out of routine operation and what remains for them is the hardest slice — design-time mistakes and the awkward recovery when the machine meets something new. A typo that once restarted one server can now restart a fleet in ninety seconds. The AWS S3 disruption of 2017 began with a mistyped input during routine maintenance; the tooling executed the wrong command faithfully and took a chunk of the internet with it. Humans did not disappear from that story. They were just further upstream, where the checks were thinner. Good teams respond by putting review, dry runs and staged rollouts at design time, where the errors actually originate.
Myth 3: Automating a messy process improves it
Copy a tangled workflow into code and you get a tangled workflow that runs at machine speed and never gets tired. If the manual version depends on tribal knowledge — “restart it twice, wait for the green light, except on Tuesdays” — the script will encode the superstition too. The repair is unglamorous: simplify the human procedure first, then write the automation against the simplified version. Ask whether the step is understood, whether it needs judgement, and whether the result needs to be removable if it misbehaves. If the answer to the last one is no, fix the thing at its source rather than wrapping a bandage around it at 2 a.m.
Myth 4: A dry run proves the change is harmless
A rehearsal only counts if it exercises the same muscles as the performance. Ansible’s check mode, for instance, skips command and shell tasks unless you explicitly flag them — so a playbook full of shell probes can pass a dry run while telling you almost nothing about what those probes would do. Treat dry runs as one input, not a verdict. Pair them with a target validation that refuses empty lists (an empty inventory should mean “run nothing”, never “run everything” — the mistake behind Google’s Diskerase wipe of its own backups), batching that touches a canary first, and a failure budget that stops the whole run once breakdowns cross the limit you set.
Myth 5: One powerful account keeps things simple
A single all-powerful credential is simple the way a hangar with the doors left open overnight is simple. Every job that borrows it inherits every permission it holds, so one compromised or buggy script becomes a fleet-wide event. Give each automation its own identity with the narrowest rights that let it work. Modern tiers make the same argument in policy terms: read-only work sits at the bottom; reversible actions on many targets need dry runs, batches and health checks; anything irreversible or data-destroying needs a second person’s approval, soft deletion and a staged rollout. That last tier maps neatly onto NIST’s dual-authorisation controls, which is a formal way of saying: destructive work never rides on one person’s click.
Myth 6: Once it is automated, you are done
Automation rots. Teams change, APIs deprecate, the person who wrote the job leaves, and the thing keeps running unwatched until it becomes governance debt — an orphan with admin rights and no next of kin. Plan the retirement on day one. Register the job with a tier, limits, an owner and a review date; let policy-as-code tests in CI fail the build when a job drifts outside its registered limits; and re-run the numbers occasionally. If a task that once saved hours now saves minutes and costs an afternoon of maintenance each quarter, say so honestly and switch it off. For the measurement side of that conversation — net hours returned, success rate, how often humans have to step in — the write-up on analytics pipeline reliability and automation covers the arithmetic in depth.
What Retiring These Myths Looks Like in Practice
None of the fixes above are exotic. In rough order of effort:
- Name every job. Inventory what runs, where it lives and who owns it. Unregistered scripts are the raw material of incidents.
- Tier each one. Read-only, reversible-single, reversible-many, irreversible. The tier decides which guards attach.
- Rehearse honestly. Dry runs that actually exercise the commands, canaries that go first, batches that stay small.
- Budget failures. Stop after N failures instead of pushing a broken change across the whole estate.
- Fit a kill switch. Per job and global, and drilled — the Atlas suggests twice a year for the riskier tiers. Whoever carries the pager should be able to pull it without asking permission first.
There is a useful overlap between this discipline and the tooling-side reading on our site. If you want the monitoring half of the story, the piece on practical AIOps knowledge sits naturally next to this one, and our SRE learning guide maps where toil measurement and automation candidates meet. Both treat automation as a system to be governed rather than a bag of tricks.
AutomationOps Myths in One Line Each
Last flight was smooth? Irrelevant. Errors eliminated? Relocated. Messy process automated? Messier, faster. Dry run passed? Check what it skipped. Shared super-account? Shared blast radius. Automated once, done forever? It is already decaying. Print that list, pin it near the deploy dashboard, and the next time somebody proposes “a quick script”, the conversation starts from evidence instead of folklore — which is the whole point of treating automation as a production system rather than a hobby.
