"AIOps" has been a vendor word for years, which has made it easy to dismiss. Underneath the marketing there are a few genuinely useful applications, and a few that will page you at three in the morning for no reason. The difference is whether the system is advising a human or acting on its own.
Where it works
Anomaly detection instead of static thresholds
Static thresholds are either too loose to catch anything or too tight to live with. Traffic is seasonal; "CPU above 80%" means something different on Monday morning than at 3am on Sunday. Models that learn normal behaviour per service and per time of week catch the deviations that matter and stay quiet otherwise. This is the single highest-value application in operations.
Alert correlation
One failing dependency can produce forty alerts across a dozen services. Grouping those into a single incident with a probable root cause is pattern matching on timing and topology — a good fit for automation and an immediate relief for whoever is on call.
Incident summarising
Assembling a timeline from logs, deploys, alerts and chat into a draft incident summary takes a human an hour at exactly the moment they are least able to concentrate. A generated first draft, corrected by the responder, gets written when it is still accurate.
Cost optimisation
Analysing usage against provisioning finds over-sized instances, forgotten environments, unattached storage and reservations that no longer fit. This is tedious, repetitive comparison work across thousands of resources — and it usually pays for a quarter of the operations budget on its own.
Capacity forecasting
Predicting when current headroom runs out, based on observed growth rather than on a guess made during the original design, turns scaling into a planned activity instead of an incident.
Where it should stay out
- Automatic remediation of anything stateful. Restarting a stateless pod automatically is fine. Automatically failing over a database, scaling down a cluster or rolling back a release is how a small problem becomes an outage.
- Security decisions without review. Blocking traffic or revoking credentials automatically will eventually block your largest customer at their busiest hour.
- Anything where the model cannot see the business context. A spike in failed payments during a marketing campaign is not the same event as the same spike on an ordinary Tuesday.
Prerequisites nobody mentions
AIOps tools assume a level of operational hygiene that many estates do not have. Before any of this helps, you need:
- Consistent telemetry. Structured logs, traces and metrics with consistent service naming. A model cannot correlate what is not labelled.
- A service inventory. Something that knows which service depends on which, even if it is a maintained diagram rather than a discovery tool.
- Runbooks. A probable root cause is only useful if the responder knows what to do with it.
- Deployment markers. Most incidents follow a change. Correlating alerts with deploys is the fastest root-cause signal there is, and it is nearly free.
If you are missing these, fix them first. They improve operations on their own and they are what any intelligent layer on top will depend on.
A reasonable adoption order
Deployment markers and structured telemetry, then alert correlation, then anomaly detection on your most critical services, then cost analysis, then forecasting. Automatic remediation last, scoped narrowly, and only for actions you would be comfortable with a junior engineer taking unsupervised.
Our DevOps & CloudOps practice runs this way across AWS, Azure, Google Cloud and Tencent Cloud — anomaly detection and predictive alerting in the operate phase, with humans making the decisions that carry risk.
