Priya still keeps the sticky note on her monitor. It reads, simply: “the script did WHAT?” It went up the morning her team discovered that a maintenance job, written eighteen months earlier by a summer intern, had restarted every payment worker in the company during the Friday sales rush \u2014 because its target list had quietly stopped matching anything. Nobody was hurt badly, but the finance team noticed, customers noticed, and Priya’s sleep suffered. What happened to her little ops group over the next quarter is a story worth telling, because it is the story of AutomationOps told at garden-shed scale: how a handful of people turned a shoebox of mysterious scripts into something that behaves like a well-run production system.<\/p>\n
The audit took one afternoon and produced a list nobody enjoyed reading. Eleven scheduled jobs. Four whose authors had left. Two running with an account that could touch essentially the whole platform. One that emailed customers \u2014 no dry runs, no second opinion, just fire and hope. The team’s mood swung between embarrassment and relief; at least the box was finally open. If any of this sounds familiar, you probably have your own shoebox, and like finding spending leaks before they drain your runway<\/a>, the first step is simply counting what is flowing out and where.<\/p>\n Priya’s crew named their scare “the Friday restart” and treated it as a gift. Instead of hunting for the intern’s mistake, they asked a harder question: what stopped anyone \u2014 including Priya herself \u2014 from knowing that job existed, what it touched, and how to stop it mid-run? The honest answer was nothing. So they built the missing thing.<\/p>\n They registered all eleven jobs in one shared document: owner, purpose, what it changes, what it must never touch, and a review date six months out. That document cost nothing and immediately ended the “wait, whose script is this?” meetings. Then they ranked the jobs by how much damage each could do in its worst credible minute. Restarts of one worker: annoying, reversible. Customer emails: irreversible the moment they leave. Database pruning: catastrophic if overreaching.<\/p>\n That ranking became their working rulebook, learned mostly by retelling the disasters of larger companies. The one that stuck hardest was Atlassian’s 2022 outage, where an automation meant to deactivate a single set of accounts went hunting with the wrong identifier type and permanently deleted 883 customer sites in 23 minutes before anyone could intervene. One mistyped field, whole businesses erased, no malice anywhere in the story. Priya read that postmortem aloud in a team meeting, and the room went quiet in the useful way.<\/p>\n From there the rules wrote themselves. Irreversible actions got a second pair of eyes \u2014 a colleague approves before the job fires, every time, no exceptions for speed. Anything that creates, charges, or sends carries a caller-supplied request ID recorded at the moment of execution, so a rerun can never double-charge a card or duplicate an invoice; the ID makes repeats harmless. Destructive jobs delete softly first, into a recoverable bin. The restart-happy maintenance job got rebuilt around small waves \u2014 two machines at a time, halting the whole run if a single wave misbehaved \u2014 instead of one sweeping command across the fleet.<\/p>\n Before guarding a script, the team learned to ask whether it deserved a leash at all. The Atlas decision tree gave them the questions in order. Does the task repeat, and do we genuinely understand it? If not, leave it human. Could we fix the underlying problem at the source instead of papering over it? Remedying the cause is always cheaper than automating around it. Does the task need judgement calls mid-flight? Then automate the preparation and keep a person in the loop, not the reverse. Finally: does it pay back the hours it costs, or enforce a consistency the business cannot get any other way? Only when a job passed all four did it earn registration, limits, and a place on the scoreboard. Two candidate scripts died quietly in that meeting, which everyone agreed counted as time well spent.<\/p>\n The scoreboard surprised everyone. Forty runs a month across the estate, the team estimated, handed back 7.83 net hours of engineer time once residual checking and upkeep were subtracted \u2014 and the hours invested in guards and registration paid for themselves 5.1 months in, with runs succeeding 95% of the time. Those figures came from the worked example in the Atlas entry on AutomationOps<\/a>, which the team borrowed shamelessly rather than inventing their own maths. Borrowing a proven formula, Priya says, was the cheapest good decision of the quarter.<\/p>\n Three things, in their words. First, the shoebox is not shameful; every growing company has one, and pretending otherwise just makes it heavier. Second, governance is mostly polite bookkeeping \u2014 names, dates, limits \u2014 not bureaucracy; their entire rulebook fits on two screens. Third, the skills transfer everywhere. Priya jokes that running automation like a production system taught her more about the business than any dashboard, because you cannot register a job without learning exactly what it does to revenue, inventory, or customers. It is the same instinct behind bringing web, cloud and AI work into one conversation<\/a> instead of letting each grow wild in its own corner.<\/p>\n Priya also learned why so many teams stall halfway. The Atlas describes five maturity stages \u2014 improvised, shared, guarded, governed, self-correcting \u2014 and notes that most organisations park at the second one: scripts hoarded in a repository, no owners, one shared login doing all the work. That parking lot feels productive because the scripts run. But without owners and guardrails the estate just ages in place, and “we automated it once” quietly becomes the most expensive sentence in the building. Her team’s review dates are the antidote: every six months, each job either justifies itself or gets retired with a small round of applause.<\/p>\n The sticky note is still there, by the way. Priya kept it as a friendly ghost \u2014 the ghost of the Friday her team got lucky. Their jobs now stop themselves when target lists come back empty, wave through their batches politely, and page a human the moment their failure budget trips. The intern, for the record, was never blamed. The system that let an unsupervised script restart production was the actual culprit, and it is the thing that no longer exists.<\/p>\n If your own Thursday-night cron jobs answer to nobody, take the parcel route: open the box, write down what is inside, give each item a name and a leash, and rehearse the brakes before you need them. Your future self \u2014 and your finance team \u2014 will sleep better for it. And if the work pulls you deeper into operations, the way a DevOps career actually progresses<\/a> starts exactly here: with the unglamorous, quietly heroic business of making repeats safe.<\/p>\n","protected":false},"excerpt":{"rendered":" A friendly case study: how a five-person ops crew tamed eleven mystery scripts with registration, risk tiers, failure budgets and a borrowed scoreboard.<\/p>\n","protected":false},"author":6,"featured_media":1079,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[166],"tags":[],"class_list":["post-1078","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-business-technology"],"_links":{"self":[{"href":"https:\/\/bhaso.com\/blog\/wp-json\/wp\/v2\/posts\/1078","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bhaso.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bhaso.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bhaso.com\/blog\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/bhaso.com\/blog\/wp-json\/wp\/v2\/comments?post=1078"}],"version-history":[{"count":1,"href":"https:\/\/bhaso.com\/blog\/wp-json\/wp\/v2\/posts\/1078\/revisions"}],"predecessor-version":[{"id":1084,"href":"https:\/\/bhaso.com\/blog\/wp-json\/wp\/v2\/posts\/1078\/revisions\/1084"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bhaso.com\/blog\/wp-json\/wp\/v2\/media\/1079"}],"wp:attachment":[{"href":"https:\/\/bhaso.com\/blog\/wp-json\/wp\/v2\/media?parent=1078"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bhaso.com\/blog\/wp-json\/wp\/v2\/categories?post=1078"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bhaso.com\/blog\/wp-json\/wp\/v2\/tags?post=1078"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}How the Team Adopted AutomationOps Without a Big Bang<\/h2>\n
Should This Job Even Exist? One Meeting, Five Questions<\/h2>\n
The AutomationOps Rules ParcelNest Kept<\/h2>\n
\n
What the Team Would Tell You Over Coffee<\/h2>\n