Grab a chair near any ops team’s coffee machine and you will hear beliefs about automation stated with total confidence — beliefs that fall apart the moment you check them against a postmortem or a manual. The Atlas’s editorial label for running automation properly is AutomationOps, and a surprising amount of it consists of unlearning. Here are six myths I hear most often, each paired with what the evidence actually says. Retiring them costs nothing and prevents the kind of afternoon nobody enjoys describing to a customer.
Myth 1: Automation Eliminates Human Error
The comfortable version goes: humans are sloppy, machines are precise, so hand the task over and errors disappear. What actually happens was written down in 1983 by Lisanne Bainbridge, in a paper titled “Ironies of Automation” that is still uncomfortably current. Moving a task to a machine does not destroy human error; it relocates it to design time, where a mistaken assumption gets baked in once and then executed flawlessly a thousand times. Worse, the humans left supervising drift out of practice precisely because nothing usually goes wrong, so when judgement is suddenly needed, it arrives rusty. The practical takeaway is not to distrust automation but to respect what it changes: errors become rarer, quieter, and far more expensive per incident. Google’s SRE camp put it crisply years ago — automation multiplies force without replacing judgement — so multiply an unexamined assumption and you get the same assumption, now with torque. Teams that internalise this rehearse failure deliberately, keep hands-on skills current, and read design docs with the same suspicion they once saved for production changes.
Myth 2: If the Target List Is Empty, Run Everything
Nobody states this one out loud, but plenty of scripts believe it. A selection filter returns nothing — after a rename, a migration, a stray typo — and the job shrugs and acts on the world instead. Google lived the consequences with Diskerase, a removal tool that treated an empty protection list as permission and started destroying data it existed to safeguard. The corrected rule sounds almost too simple: an empty list is a stop sign, never a green light. “Empty never means all” now reads like obvious advice; it reads that way because someone paid for it. Add the three-line guard to your own jobs today and thank nobody, quietly, forever. It is the rarest kind of fix: one that costs an afternoon and prevents a headline.
Myth 3: A Clean Dry Run Means the Job Is Safe
Rehearsal mode is valuable and routinely over-trusted. The fine print matters: in Ansible, check mode tends to skip command and shell tasks unless they are explicitly flagged as safe to simulate, so a spotless dry run may simply mean the riskiest steps never actually rehearsed. Static analysis helps where simulation cannot: ShellCheck picks apart shell scripts, ansible-lint scolds playbooks, and both catch sins before any runtime sees them. Treat a green rehearsal as evidence only about the steps that truly executed. If your most dangerous job reports no changes in check mode, be suspicious — that is often the tool telling you it could not look. A rehearsal you do not interrogate is theatre with good lighting.
Myth 4: One AutomationOps Super-Login Keeps Everything Simple
The god credential — a single all-powerful account every job shares — feels tidy and is a standing invitation to disaster. It hides which job did what, makes revocation impossible without breaking everything, and hands any compromised script the keys to the building. The opposite convention costs little: each automation gets the narrowest identity that works, and newcomers to the estate — the AI agents now joining operations teams, such as AWS’s DevOps Agent, generally available in March 2026, and Microsoft’s Azure SRE Agent — are started read-only and granted reach only as they earn it, routed through the same guards as everything else. If a piece of software can request credentials politely, so can your cron jobs.
Myth 5: Automate It Once and It Stays Done
Automation is not a monument; it is produce. Targets drift, credentials expire, upstream APIs change their minds, and the job that healed systems last year quietly starts harming them this year. The Atlas’s maturity ladder makes the failure mode visible: teams typically stall at the “shared” stage — scripts gathered in a repository, ownership foggy, credentials shared — which feels organised and behaves like deferred trouble. The antidotes are unglamorous: every job carries a named owner and a review date, and reviews end in one of two honest outcomes, renewed or retired. A job that cannot justify its existence has told you something useful. It helps to remember how varied the habitats are — runbook platforms such as Rundeck and StackStorm sit beside event-driven runners and cloud-native services like AWS SSM Automation and Azure Automation — so a review cadence per habitat keeps the whole zoo honest rather than just the loudest enclosure.
Myth 6: Approval Is Either a Speed Bump or a Rubber Stamp
Two extremes, both wrong. Approve nothing and every irreversible act is one bad config away from history. Approve everything and your reviewers sign dozens of routine requests a day until they stop reading — approver fatigue, which is just rubber-stamping with extra steps. The way out is grading: read-only work needs no approver, reversible single-target changes need none either, multi-target changes get guardrails instead of signatures, and only the destructive class — the deletes, the purges, the data-destroying misfires of the kind that erased 883 Atlassian customer sites in 23 minutes back in 2022 — earns a second human’s explicit yes. Same principle as how AIOps differs from traditional operations: the goal is better decisions, not more process for its own sake.
Retiring the AutomationOps Myths in Your Own Shop
None of the six corrections requires a platform purchase. Add the empty-list guard this week; flag your check-mode gaps the same afternoon; give the three scariest jobs their own identities and their first failure budgets. Then book the unglamorous event that proves the safety net exists: a stop-button drill, out loud, with the whole team watching, repeated twice a year for anything dangerous — and a standing rule that whoever carries the pager can throw any stop switch first and explain afterwards.
If the six myths need a fridge-door version, here it is:
- Machines inherit our mistakes; they just stop apologising for them.
- An empty target list is a stop sign, not a green light.
- A rehearsal only covers the steps that actually ran.
- Shared super-accounts make every incident anonymous.
- Owners and review dates are how automation stays fresh.
- Approvals belong to the destructive tier — and only there.
Meanwhile, let the machines help you see: cutting alert fatigue with AIOps pairs naturally with automation governance, because both are about hearing the signals that matter. And when an incident does slip through, resolving it faster with modern AIOps platforms goes smoother if your automations already announce what they touched.
For the full discipline these fixes belong to — the five core controls, the tier model, the metrics, the drills — the Atlas keeps a compact spec on one page: AutomationOps at The Ops Atlas. Read it once, then go argue with your crontab. It will lose, and everyone’s week will go better for that. Myths are only expensive when they are load-bearing; retire these six and the structure that remains is one you can actually stand on.