Last month a reader wrote in about her team’s Tuesday. A cleanup script, written by an intern who left two summers ago, ran at noon and deleted a folder nobody knew mattered. The outage lasted forty minutes; the argument inside the team lasted a week, and the apology to customers lasted longer. Her question — “who was supposed to be governing this?” — is the best one-sentence case for AutomationOps I have received. The discipline, laid out in the Ops Atlas entry, treats every unattended action on production as part of one production system: chosen deliberately, safe on repeats, limited when it fails, owned until it retires. Her letter deserved more than a reply, so here are the questions readers keep sending, answered as honestly as I can.

AutomationOps Questions Readers Keep Sending Us

Is this just DevOps wearing a new jacket?

No, and the boundary is cleaner than most buzzwords manage. DevOps is a culture of shared ownership across build and run. AutomationOps is a specific governance practice inside that culture, concerned with run-time actions — restarts, cleanups, failovers, credential rotations, configuration sweeps across a fleet. It deliberately excludes neighbouring territories: infrastructure templating, workflow engines, chat-triggered commands, network change windows, toil accounting. Those are separate disciplines with separate playbooks; confusion between them is exactly how the intern’s cleanup script survived two summers without a single audit.

We keep our twelve scripts in a shared repository. Is that enough?

Shared storage is where most teams stall, and the maturity ladder explains why. The Atlas draws five rungs, from untracked improvisation up through pooled scripts and guarded practice to governed estates that correct themselves, and observes that teams almost always wedge at rung two. A repository holds code; it does not hold ownership, risk grades, rehearsals or stops. Twelve governed scripts beat two hundred shared ones, because governance is what turns code into a system. The jump from level two to level three is the most valuable climb in the field, and it needs no new tooling — only a register, owners and drills.

Who is allowed to press the stop button?

Anyone on call, without asking. This is the answer that surprises managers and relieves engineers. Every automation carries its own stop, a global stop sits above them, and the person awakened by the pager holds the standing authority to pull either first and explain afterwards. For the two riskiest grades of automation the stop gets drilled twice a year, with the time it takes recorded — because a brake that has never been practised is a rumour, and the worst night of the year is a poor time to check.

How do we decide what deserves automating at all?

Walk the four gates before writing a line. Does the task repeat, and is the procedure genuinely understood — or would you simply be putting chaos on a schedule? Can the result be removed when it is wrong; if not, mend the source instead. Does the step need human judgement mid-flight? Then design for a human-backed interface rather than a hands-off job. Only then ask whether it pays back in hours, or earns its place through consistency. An action that fails the gates should stay manual, whatever the roadmap says.

How do we prove the value to management?

With arithmetic, not adjectives. Count the runs each month, multiply by the minutes people used to burn, subtract what the machine still spends and the upkeep it demands, and divide by sixty. The Atlas’s sample estate lands at forty runs a month returning nearly eight hours, break-even a little past the fifth month, and ninety-five runs succeeding in every hundred. Add the honesty metrics — how often a human gets paged anyway, how often the automation causes the very incident it exists to prevent — and you have a case no slide of adjectives can match.

Do the new AI agents change any of this?

Less than the headlines suggest. In March 2026 Amazon’s agent for DevOps duties left beta for good, and Azure’s own SRE agent arrived from Microsoft wearing identical fine print. Both come pre-fitted with the leash this discipline designed: Narrowest usable identity, read-only until proven, every proposed action past the identical guard checks that any veteran’s script must clear. The lesson for teams is not that governance is over but that it now applies to colleagues who never sleep. An agent is simply the newest entry in the register — tiered, owned, reviewed, stoppable.

A Small Story About the Cost of Skipping the Story

A three-person team I know — call them the harbor pilots, because they guided ships into a port you have shipped goods through — grew fast and automated faster. Restart hooks, disk sweeps, a failover script of real elegance. They shared one administrative credential across everything because three people trust each other. Then one sweep ran against the wrong environment, and the elegant failover, doing precisely what it was told, made the wrongness permanent on the standby too. Recovery took a weekend. The postmortem’s first line read: “We had no registry, so we had no brakes.” Bainbridge saw the shape of this in 1983 — push human error upstream into design, and it waits there patiently — and the trading world proved it in 2012 when a brokerage’s unreviewed deployment flag cost it some 460 million dollars in under an hour.

Where Should a Small Team Begin with AutomationOps?

Before the how, the what — a pocket summary of the answers above:

• Scope: run-time actions only; templates, workflow engines and chat triggers are neighbours.
• A shared repository is rung two of five; the register, owners and drills are the climb.
• The stop belongs to whoever is on call, first and explanations afterwards.
• Four gates decide automation-worthiness; failing any one keeps the task human.
• Value is arithmetic: runs, minutes returned, upkeep, break-even month, success rate.
• Agents inherit the leash: narrow identity, read-only beginnings, guard checks all the way down.

Small teams start smaller than they fear. Month one: write down every unattended action that exists, however embarrassing, and pick the twenty riskiest for the register. Month two: put those behind a single runner, give each its own identity, and hold the first stop drill — the silence in the room is part of the training. Month three: bring the remaining entries across as the evidence accumulates, until nine of every ten actions carry a name and a review date. Grade everything on the way in: read-only at the bottom, reversible-many in the middle with rehearsals and health checks attached, and the irreversible, data-destroying class at the top with a second approver, soft delete and a staged rollout — the two-person concurrence that NIST files under its dual-authorization entries covering access and change.

For continued reading from this site, the outlook piece on how DevOps keeps evolving across Japan and beyond places practices like these in their industry context, the guide to DevOps and risk management extends the tiering logic into wider delivery risk, and the beginner’s DevOps glossary covers the vocabulary this FAQ assumed. And when your own Tuesday comes — the script nobody owned misfiring at noon — you will know exactly which brake to reach for and who may pull it — because you installed both, months before, in daylight.