{"id":11658,"date":"2026-10-29T07:30:00","date_gmt":"2026-10-29T07:30:00","guid":{"rendered":"https:\/\/www.cotocus.com\/blog\/?p=11658"},"modified":"2026-10-29T07:30:00","modified_gmt":"2026-10-29T07:30:00","slug":"automationops-six-myths-retired","status":"publish","type":"post","link":"https:\/\/www.cotocus.com\/blog\/automationops-six-myths-retired\/","title":{"rendered":"Six AutomationOps Myths Worth Retiring Today"},"content":{"rendered":"

Grab a chair near any ops team’s coffee machine and you will hear beliefs about automation stated with total confidence \u2014 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.<\/p>\n

Myth 1: Automation Eliminates Human Error<\/h2>\n

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 \u2014 automation multiplies force without replacing judgement \u2014 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.<\/p>\n

Myth 2: If the Target List Is Empty, Run Everything<\/h2>\n

Nobody states this one out loud, but plenty of scripts believe it. A selection filter returns nothing \u2014 after a rename, a migration, a stray typo \u2014 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.<\/p>\n

Myth 3: A Clean Dry Run Means the Job Is Safe<\/h2>\n

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 \u2014 that is often the tool telling you it could not look. A rehearsal you do not interrogate is theatre with good lighting.<\/p>\n

Myth 4: One AutomationOps Super-Login Keeps Everything Simple<\/h2>\n

The god credential \u2014 a single all-powerful account every job shares \u2014 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 \u2014 the AI agents now joining operations teams, such as AWS’s DevOps Agent, generally available in March 2026, and Microsoft’s Azure SRE Agent \u2014 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.<\/p>\n

Myth 5: Automate It Once and It Stays Done<\/h2>\n

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 \u2014 scripts gathered in a repository, ownership foggy, credentials shared \u2014 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 \u2014 runbook platforms such as Rundeck and StackStorm sit beside event-driven runners and cloud-native services like AWS SSM Automation and Azure Automation \u2014 so a review cadence per habitat keeps the whole zoo honest rather than just the loudest enclosure.<\/p>\n

Myth 6: Approval Is Either a Speed Bump or a Rubber Stamp<\/h2>\n

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 \u2014 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 \u2014 the deletes, the purges, the data-destroying misfires of the kind that erased 883 Atlassian customer sites in 23 minutes back in 2022 \u2014 earns a second human’s explicit yes. Same principle as how AIOps differs from traditional operations<\/a>: the goal is better decisions, not more process for its own sake.<\/p>\n

Retiring the AutomationOps Myths in Your Own Shop<\/h2>\n

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 \u2014 and a standing rule that whoever carries the pager can throw any stop switch first and explain afterwards.<\/p>\n

If the six myths need a fridge-door version, here it is:<\/p>\n