What is AIOps

If you work anywhere near infrastructure you have probably had AIOps pitched at you. Usually by a vendor, and usually with a slide showing a dashboard full of sparklines. What the slide rarely does is explain what the term means.

This is my attempt at the explanation I wanted when I first heard it.

Table of contents

The problem it is trying to solve

Modern systems produce a lot of telemetry. A moderately large platform might emit metrics from a few hundred hosts, structured logs from a few dozen services, traces that cross six of those services on a single request, synthetic checks, cloud provider events, and whatever the network layer underneath is reporting. Every one of those streams has thresholds, every threshold has an alert, and every alert has somewhere to go.

Anyone who has carried a pager knows how this plays out. Something breaks at three in the morning and you get 40 alerts. 38 of them are symptoms. One is the cause. One is unrelated and has been flapping for a month because nobody has had time to look at it.

People are bad at this, and not for lack of skill. Correlating 40 time series at three in the morning, under pressure, is not something brains do well. We form hypotheses easily and we search exhaustively very badly.

AIOps is the idea of pointing software at that gap, and almost everything else you will read about it is implementation detail.

Where the name comes from

Gartner coined the term around 2016. It started life as Algorithmic IT Operations and later became AI for IT Operations, which is a shame, because the first version was more accurate. Most of what ships under the label is statistics: clustering, seasonal decomposition, similarity scoring. That is not a criticism. Those techniques solve real problems.

The picture got muddier once large language models arrived, because some tooling now really does include a model that reads a stack trace and writes you a summary. Both kinds of product use the same word. They fail in very different ways, so it helps to keep them separate in your head.

The core loop

At the centre of most AIOps products is a loop that runs from signal to fix. It has four steps, and vendors differ mainly in which of them they are good at. This is the part everyone demonstrates, so it is worth understanding first, but it is not the whole picture and I come back to that below.

1. Noise reduction and correlation

Take the 40 alerts, notice that 38 of them fired inside ninety seconds across services that share a dependency, and collapse them into a single incident.

This is the least exciting of the four and the one I would fight hardest to keep. Cutting alert volume in half without losing signal improves the working life of everyone on call, and you can measure it.

The methods are ordinary. Temporal clustering, grouping by topology, text similarity across alert payloads. Nothing here is clever. All of it beats doing the same work by hand at three in the morning.

2. Anomaly detection

Rather than alerting when CPU goes above eighty percent, the system learns the usual shape of a metric and alerts when reality departs from it.

This earns its place on anything seasonal. Your traffic is not flat. It has a daily shape, a weekly shape, and if you bill monthly it has a monthly one too. A fixed threshold will either shout every Monday morning or stay quiet through a real problem on a Sunday night. A seasonal model handles both.

The disappointment is that unusual and bad are not the same thing. A successful campaign is unusual. So is a deploy. Budget for a tuning period and assume it runs longer than the demo suggested.

3. Root cause assistance

Given an incident, the tool suggests where to look, normally by putting a dependency graph next to a change log. This started four minutes after a config change upstream, and these three metrics moved first.

I call it assistance rather than analysis on purpose. In my experience these tools reliably get you from forty candidates down to three. Picking the right one of the three is still your job, and it is the part that needs someone who understands the system.

4. Automated remediation

Spot a known condition, run a known fix. Restart the stuck worker, drain the bad node, add queue consumers, move traffic to the standby path.

Everyone gets excited about this one, and it is the one I would go slowest on. Automation that can fix things can also break things, faster and more consistently than any person. Start with actions that only read, or that reverse trivially. Make every one of them log loudly. Build the off switch before you build the automation.

How much wider the label goes

If you only look at that loop you will get a narrow idea of what AIOps means, and you may well miss the part your team needs most. A few of the bigger omissions.

Forecasting is the obvious one. Anomaly detection tells you something looks odd now. Forecasting tells you a volume fills in nine days, or that you need capacity in place before the next billing peak, or that a disk is showing the failure signature that usually precedes a real one. On a large enough fleet that last case pays for itself.

A great deal of commercial AIOps has almost nothing to do with metrics. It works on tickets: classifying what comes in, routing it to the right team, spotting duplicates, and surfacing the past incidents that look like this one. If you run a support function rather than a platform, that is probably the part that matters most to you, and it is the part the observability vendors talk about least.

Topology discovery deserves a correction to what I wrote above. I described the dependency map as something you sit down and write, because that is how I have usually had to do it. Plenty of tools now assemble it themselves from traces, flow logs and configuration. Worth checking before you spend a month drawing one by hand.

Log analytics is its own discipline. Reducing millions of lines to a few hundred recurring templates, then alerting when a genuinely new one shows up, is a different problem from metric anomaly detection and usually needs different tooling.

Alert enrichment gets very little attention and earns more than it gets. Attaching the recent changes, the owning team and the relevant runbook to an alert before a human reads it costs little and saves real minutes at the worst possible time.

Then there is everything after the incident. Reconstructing the timeline, drafting the writeup, pulling out the actions and tracking them. This is where the language model additions have landed most convincingly so far, mostly because a poor first draft is cheap and a poor automated remediation is not.

Telemetry cost control turns up under the label too, though it is really a data management problem wearing a fashionable hat.

I would not treat that as a closed list. The term has been stretched to cover more or less anything that puts a model next to operations data, which is a large part of why it is hard to pin down. When somebody says they are buying AIOps, the useful question is which of these they actually mean.

The prerequisite nobody mentions

Most of the above depends on your telemetry being in reasonable shape. Correlation needs to know what depends on what. Anomaly detection needs enough clean history to learn from. Root cause assistance needs your change events to actually arrive. Remediation needs trustworthy signals, or it will automate the wrong thing with great enthusiasm.

If your service names are inconsistent, your tags were invented ad hoc, your dependency map lives in one person’s head and a third of your alerts are already muted, none of this will fix that. It will model the mess faithfully and hand it back with nicer graphs.

Which brings me to a conclusion I resisted for a while. A lot of the value credited to AIOps projects comes from the data cleanup they force. Consistent naming, a dependency map somebody has written down, deleting alerts nobody acts on, tagging things properly. You could do all of that this quarter with no vendor and no model, and collect a decent share of the benefit.

That is not an argument against buying anything. It is an argument about order.

Where I would start

For a team drowning in alerts I would go roughly in this sequence.

1. Count your alerts. How many fired last month, and how many led to somebody doing something? That ratio is your baseline and it is usually worse than people expect.
2. Delete the ones nobody acts on. Free, immediate, and it improves everything downstream.
3. Make naming and tagging consistent. Dull work with no visible output, and everything later depends on it.
4. Write down the dependency graph, or find out whether something you already run can discover it for you.
5. Add correlation and grouping. Now it has something to work with.
6. Add anomaly detection, on the handful of metrics that matter rather than on everything.
7. Automate remediation last, one narrow runbook at a time.

The first four need no AI at all. A team that does those and stops will still be ahead of most.

If your pain is ticket volume rather than alert volume, that order is wrong for you. Start with classification and duplicate detection on the queue instead, and treat the metrics side as a later problem.

What I think overall

AIOps is a sound idea with an unhelpful name and boundaries that keep moving. The premise, that machines should do the correlation and sorting work people are bad at, holds up well. The tooling is real and improving, and the language model additions are genuinely useful for the summarising and explaining parts of the job.

It is a multiplier though, not a replacement. It multiplies whatever operational discipline you already have, so if that number is small the multiplication does not help much.

Get the basics right, then hand the tedious part over.

I want to write up what happens when you point a language model at an incident channel, which turned out to be more mixed and more interesting than I expected.