Plenty has been written about why operations teams should prepare for AI-assisted operations. Far less about what, specifically, to do on Monday. This list closes that gap. Nine moves, in rough order, each one concrete enough to put on a sprint board. No philosophy, minimal theory \u2014 just the actions that separate teams who end up supervising intelligent automation from teams who end up as cautionary tales in someone’s conference talk.<\/p>\n
Before anything else, measure the problem. Have every team member tally time spent on recurring operational chores \u2014 scheduled health checks, post-deploy alert sifting, ritual service restarts, capacity eyeballing, status reporting. Use a shared sheet, keep categories crude, and resist the urge to fix anything yet. The output is a single number: hours per week of repeatable work. That number funds everything that follows, both politically and literally. Teams routinely discover the equivalent of a full-time engineer dissolved into chores nobody chose.<\/p>\n
Go through the audit line by line and ask: does this task follow a detectable pattern (candidate for machine help), or does it require context a machine lacks (keep it human)? Restarting a service with a known failure signature: pattern. Deciding whether a traffic spike is a marketing win or an attack: judgement \u2014 at least initially. Expect roughly half your list to land in the pattern column. That half is your automation backlog, pre-prioritised by the hours attached to each line.<\/p>\n
Pick a recent fortnight and compute: of all the alerts the team received, what fraction led to action? Most teams score depressingly low, and that score is your before photo. Intelligent monitoring earns its keep partly by raising this number, but you can only prove it if you measured the baseline while things were still noisy. Thirty minutes of log archaeology now saves you an unwinnable ROI argument later.<\/p>\n
One trained person is a bus-factor problem wearing a certificate. Pick two: ideally one senior engineer who knows your estate’s folklore and one hungry mid-level who will do the homework. Formal, sequenced study beats tutorial roulette here, because the skill set \u2014 teaching software what normal looks like, judging statistical deviations, bounding automatic repairs \u2014 hangs together as a discipline. A dedicated provider such as AIOps School<\/a> structures it as a climbable credential ladder that starts at Foundation level and tops out at Architect; the practical sweet spot for your two nominees is the engineering tier, a six-to-seven-week commitment that covers building detection models, wiring up monitoring stacks and scripting contained self-repair, practised in sandboxed labs rather than on your production estate. The knowledge-gap problem is real and well documented \u2014 we mapped its contours in our practical guide to the knowledge gaps students must fill<\/a> \u2014 and structured curricula exist precisely because scattered self-study keeps failing to close it.<\/p>\n The most common failure mode is not bad training; it is phantom training \u2014 approved in principle, erased in practice by the on-call rota. Treat study blocks like production incidents: visible on the calendar, protected, rescheduled only with the same ceremony you’d apply to skipping a postmortem. A dozen hours a week for the deeper track is the honest requirement. If your team genuinely cannot find them, you have just discovered your drudgery audit’s first use case: that is exactly the time the automation will eventually return.<\/p>\n Parallelise. Stand up monitoring across five to ten services with every action feature disabled. The system needs weeks to learn your rhythms anyway \u2014 release days, batch windows, the Monday-morning login surge \u2014 and your trainees will graduate into a system that already has baselines worth tuning. Zero risk, meaningful head start, and the early curiosities it surfaces (there is always a forgotten cron job nobody can explain) make excellent show-and-tell for sceptics.<\/p>\n Once baselines exist, convene thirty minutes a week where the team grades every machine-raised flag: genuine, benign or noise. This single meeting does triple duty \u2014 it tunes sensitivity with human judgement, it spreads literacy beyond your two specialists, and it builds trust at a measurable rate instead of demanding it by decree. Credentials certify knowledge, but this ritual is where knowledge becomes shared team judgement; the distinction matters for careers too, as we argued in our assessment of what certifications are really worth in tech careers<\/a>.<\/p>\n When a flag type has proven reliable and its fix is boring \u2014 restart this, clear that, re-run the other \u2014 promote it to unattended execution. Rules: one promotion at a time, written limits on scope and frequency, automatic escalation when limits are hit, and a named human who reviews its log weekly. The first unattended fix firing quietly at 2 a.m. is the milestone that converts your remaining sceptics; the discipline of bounding it well is diagnostic reasoning applied to automation, close kin to the skills in our guide to building critical-thinking muscle for operations problem-solving<\/a>.<\/p>\n Close the loop. Every quarter, repeat move one and publish three numbers side by side: repetitive hours per week, alert precision, and count of incidents caused by automation (target: zero, tracked honestly). The trend line is your programme’s report card, your budget defence, and \u2014 not least \u2014 the recruiting pitch that your team supervises machines rather than competing with them. Engineers read trend lines like these when deciding where to work next.<\/p>\n Scan back through the list and notice what it never says: pick a vendor. That omission is the point. Tooling decisions fall out naturally around move six, made by people who by then know what they are choosing and why. Everything load-bearing on this list is about people and measurement \u2014 audit, classify, train, protect the time, grade together, bound carefully, measure again. Teams that execute these nine moves report the same quiet outcome: within two or three quarters, the 3 a.m. page has become a log entry, the chore hours have halved, and the team’s scarcest resource \u2014 attention \u2014 is finally pointed at problems worthy of it. Monday awaits.<\/p>\n","protected":false},"excerpt":{"rendered":" Nine sprint-board-ready moves for AI-assisted operations readiness: drudgery audits, paired training, listen-only deployment and graduated automation.<\/p>\n","protected":false},"author":5,"featured_media":1859,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[486],"tags":[],"class_list":["post-1858","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1858","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/comments?post=1858"}],"version-history":[{"count":0,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1858\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/media\/1859"}],"wp:attachment":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/media?parent=1858"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/categories?post=1858"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/tags?post=1858"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}5. Put the training hours on the actual schedule<\/h2>\n
6. Deploy in listen-only mode while they study<\/h2>\n
7. Institute a weekly flag-grading ritual<\/h2>\n
8. Graduate automatic fixes one at a time, with a named auditor<\/h2>\n
9. Re-run the drudgery audit each quarter and publish the delta<\/h2>\n
What all nine moves have in common<\/h2>\n