Most people who want to get better at AIOps do the obvious thing: they put in hours. They read dashboards, click through consoles and sit in on incident calls. Months later they are busier but not noticeably sharper. This FAQ explains why, and lays out what deliberate practice for AIOps looks like when you replace volume with aim.

What is deliberate practice, and why does it beat plain repetition?

Repetition by itself locks in whatever you already do, good or bad. If you triage incidents sloppily a hundred times, you become fluent at sloppy triage. Deliberate practice is different in three ways. You pick one narrow weakness, you attempt it in a short block, and somebody or something tells you honestly how it went. Then you change one small thing and go again.

The evidence on skill-building in music, sport and medicine broadly points the same way: the quality of attention during practice matters more than the raw count of hours. You do not need a lab to apply that. You need a clear target and a source of honest feedback.

What counts as a “narrow weakness” in AIOps work?

Think of things you can name in a single sentence and attempt in under twenty minutes. A few examples that come up often:

• Reading a timeline of events and stating, in two sentences, what changed first.
• Deciding whether a spike deserves a page or a ticket, and writing down why.
• Writing a query that isolates one service’s errors without pulling in its neighbours.
• Putting a model’s recommendation into plain words for a teammate unfamiliar with the tool.

“Get better at observability” is not a drill. “Find the first anomalous deploy in this saved timeline within ten minutes” is. If you cannot tell when the drill is over, shrink it.

How long should a single drill last?

Short enough that your attention does not drift. Fifteen to twenty-five minutes is a reasonable range for most people, followed by a real pause. Attention is the scarce ingredient here, and a drill you half-attend to is just repetition wearing a costume.

A useful rhythm is three parts. First, attempt the task cold. Second, compare your answer with a reference or a reviewer’s notes. Third, retry the same task with one adjustment. The retry is where most of the learning shows up, because you can see the difference your change made.

Where does honest feedback come from if I work alone?

This is the hard part, and it is why so many practice routines stall. A few workable sources exist:

1. Replays with known answers. Past incidents that your team has already written up give you a ground truth. Attempt the diagnosis blind, then read the write-up.
2. A colleague’s review. Request just two remarks, a strength to keep and a habit to drop. Tight requests tend to draw candid answers.
3. Your own recording. Talk through your reasoning aloud while you work, then listen back. Hesitations and hand-waving become obvious.
4. An outside coach. Someone who watches how you work and names the habit you cannot see yourself.

For that last option, the problem is simply knowing where to look. DevOps professionals who want a coach, and teams hoping to arrange a workshop, can browse the DevOpsTrainer directory of DevOps trainers, instructors and coaches, which also has skill routes covering AIOps alongside SRE, DevSecOps, MLOps and DataOps. It is a place to begin the search, not a replacement for the drills you run yourself.

Can you give a worked example of one drill?

Here is a concrete session for the timeline-reading weakness.

Choose an old incident your team has documented, and export the raw event log without the conclusions. Set a timer for twenty minutes. Your task is to write two sentences naming the first change that mattered and the evidence for it. When the timer stops, put your two sentences next to the official write-up.

Now score yourself honestly on three questions. Did you land on the same starting point? If not, what did you look at first that pulled you away? Did your evidence name a specific event, or only a general area? Pick the single largest gap and make it the adjustment for the next attempt, perhaps “check deploy events before metrics” or “ignore anything after the first alert fired.”

Repeat with a different incident the next day, applying only that one adjustment. Jot down, in a line, which adjustment you applied. A week of these sessions, each one aimed at a specific miss, teaches more than a month of passively watching the same consoles.

Is it better to drill many skills at once?

It is tempting, because a broad plan feels thorough. In practice the breadth is what dilutes it.

No. Rotating through four weaknesses in one sitting blurs the feedback, because you cannot tell which adjustment produced which change. Stay on one target for several sessions, until the miss stops appearing, then move to the next. Treat it like a queue with a limit of one item in progress.

If you need to choose, pick the weakness that costs you the most in real work. Slow diagnosis during an outage matters more than awkward dashboard styling, however much the latter irritates you.

How do I know the practice is working?

Look for evidence that is specific and observable rather than a vague sense of improvement. Your drill times shrink. The gap between your answer and the reference narrows. A colleague stops repeating the same note. Those are small signals, but they are real, and they beat the comfortable feeling of having “put the time in.”

If nothing changes after several sessions, the drill is probably aimed wrongly. Narrow it further, or change the feedback source. Sometimes the fault lies in the reference answer itself, which is worth discovering too.

Does tooling make deliberate practice easier or harder?

It can do either. A well-run sandbox with Kubernetes workloads you can break and restore at will offers endless safe material for drills. On the other hand, a tool that hands you an answer before you attempt the problem removes the struggle that makes the practice useful. Attempt first, then consult the automated suggestion, and treat any disagreement as the interesting part.

That habit also protects you from over-trusting recommendations. If you have always checked your own reasoning against the tool’s, you will notice sooner when the tool is wrong.

What usually goes wrong with these routines?

Three failure patterns show up repeatedly. People choose drills that are too large to finish, so they never see a result. They skip the comparison step and treat the attempt itself as the reward. Or they abandon a drill the moment it feels easy, when a quick extra rep at a slightly harder setting would have been the productive move. Naming these in advance makes them easier to catch while they are happening.

What should I do this week?

Keep it modest. Choose one weakness you can phrase in a sentence. Find one source of honest feedback, whether a past write-up or a willing colleague. Book three short blocks in your calendar and write down the single adjustment you will try in each one.

If you want more material to build on, two earlier pieces on this site pair well with the exercise. The walkthrough on approaching live IT problems for the first time gives you a diagnostic frame to practise inside, and the stepwise DevOps learning path for newcomers helps you decide which weakness deserves the next block of attention.

Skill in this field is built the same unglamorous way it is built anywhere else: one aimed attempt, one honest look at the result, one small change. The hours will come anyway. Make sure they have a target.