An Osaka Team’s Road to AI-Assisted Operations

Rajesh Kumar

Rajesh Kumar is a leading expert in DevOps, SRE, DevSecOps, and MLOps, providing comprehensive services through his platform, www.rajeshkumar.xyz. With a proven track record in consulting, training, freelancing, and enterprise support, he empowers organizations to adopt modern operational practices and achieve scalable, secure, and efficient IT infrastructures. Rajesh is renowned for his ability to deliver tailored solutions and hands-on expertise across these critical domains.

Let me tell you about a fictional team that will feel very familiar. Kiso Commerce — invented for this story, though you may recognise your own office in it — runs a mid-sized online marketplace out of Osaka: six engineers, one manager named Sato, and a seasonal sale calendar that turns every November into a month of short sleep. Their road to AI-assisted operations did not begin with a strategy deck. It began the morning after a big sale night, when Sato found his best engineer, Yamada, asleep at his desk beside a notebook containing ninety-one handwritten alert acknowledgements. Nothing had actually broken. Ninety-one times, a human had checked anyway.

The notebook that started everything

Sato did something quietly radical with that notebook: he treated it as data. Over tea, the team sorted the ninety-one entries into piles. Seventy-four were rhythms — traffic surges, queue backlogs, cache churn — that happened at every sale and always resolved the same way. Eleven were known quirks with known one-command fixes. Six were genuinely worth a human’s night. The team stared at the piles for a while. “So we stayed awake,” said Mori, the newest member, “for six things.” That sentence became the project charter nobody wrote down.

If you have read our look at how DevOps is evolving in Japan and beyond, you know the direction of travel: operational judgement is moving up the stack while repetition moves to machines. Kiso’s notebook was that trend, rendered in biro.

Deciding who learns what, before deciding what to buy

Here is where this story diverges from the usual one. Sato’s instinct was procurement; Yamada talked him out of it. “If we buy a watcher we can’t question,” he argued, “we’ve just hired an employee nobody can manage.” So the first budget line was study time, not software, and the team mapped it person by person — because a six-person team cannot send everyone to learn everything.

They sketched it on the whiteboard like a climbing roster. Everyone would reach base camp: enough fluency to read what a learning system claims and push back on it. They found the base layer conveniently sized — a thirty-day AIOps foundation course at ten-odd hours a week fit around sprint work, and the published ladder above it (foundation, then engineer, then professional, then architect) told them what they were choosing not to climb yet. Yamada and Mori took the deeper engineering block afterwards — six-plus weeks of building detection models, wiring observation stacks and designing automatic fixes in practice labs, at a heavier weekly commitment. Sato himself did only the base layer, deliberately: his job was to manage the arrangement, not to tune it. The unexpected detail? Pairing the veteran with the rookie on the deep track worked beautifully. Yamada brought scar tissue, Mori brought fearlessness, and their lab assignments turned into lunchtime arguments the whole team eavesdropped on.

AI-assisted operations on probation: the listen-only winter

By January, Kiso had a detection system observing their marketplace in listen-only mode. The team’s rule, borrowed from their lab exercises: for one full month, the machine gets no authority, only a scorecard. Each morning’s stand-up spent five minutes grading yesterday’s flags — caught, missed, or imagined. Early results were humbling in both directions. The system spotted a slow memory leak eight days before their old thresholds would have fired. It also flagged the Tuesday batch-import as suspicious every single Tuesday, until Mori retrained its sense of normal with the import calendar included.

That grading ritual did something subtler than tune a model. It taught a team of sceptics to disagree with software out loud, in specific terms, with evidence — which, as we argued in our guide to handling the human side of DevOps change, is the actual hard part of any operational transformation. Nobody at Kiso “resisted the tool”. They interrogated it daily until it earned a seat.

One leash, one fix, one sale season

In February the team granted the system its first real authority: when the checkout queue backs up in the specific shape they had seen seventy-four times, scale the workers and post the reasoning to chat. Three constraints applied — a daily action limit, full logging, and a kill command every engineer could run from their phone. The spring sale was the exam. The automation acted nineteen times; eighteen were textbook, and the nineteenth was wrong in an interesting way that produced the best postmortem of the year. Total human pages that night: four. Yamada watched a film. Mori, to her lasting pride, was paged once and resolved it alone — because the flag arrived with context attached instead of a bare threshold scream.

Customers noticed none of this, which was the point. Checkout latency through the sale stayed flat, and the connection between calm operations and happy buyers — something we explored in our piece on how delivery practice flows through to customer satisfaction — showed up in the quarter’s reviews rather than in anyone’s heroics.

What Kiso would tell your team over tea

  • Start from your own notebook. Count what vigilance actually costs you before imagining what automation might save.
  • Fund learning before licences. A tool your team cannot cross-examine is a liability wearing a dashboard.
  • Climb in layers. Whole-team fluency at the base; depth for two; strategy for whoever manages the arrangement. The ladder exists so you can stop at the right rung.
  • Let the machine audition. A month of listen-only mode with daily grading builds trust that no vendor demo can.
  • Leash the first automation and celebrate the first time the leash is used — that is the system working, not failing.

One postscript Sato insists on. The study investment kept paying after the project formally ended: Mori now mentors the next hire through the base-layer material, the team’s postmortems reference baseline behaviour as naturally as they once referenced log lines, and two neighbouring teams in the building have borrowed both the notebook exercise and the grading ritual. Capability, it turns out, is the only deliverable that spreads by itself.

Kiso Commerce is invented, but every beat of its story is assembled from how real teams get AI-assisted operations adoption right: chores counted, skills built person by person, trust earned on a scorecard. The ending is the believable part too. Nobody was replaced. Yamada’s notebook retired. And November stopped being the month the team feared — which, if you ask Sato, was the only metric that ever mattered.

Leave a Reply