AIOps

WHAT IT IS AIOps is the application of machine learning and statistical techniques to operational telemetry: correlating thousands of related events into one incident, suppressing known noise, detecting anomalies that static thresholds miss, and surfacing probable causes to the responder. It sits alongside /observability-engineering and /incidentops as a way to make an overwhelming signal volume tractable. **Not this:** AIOps is not MLOps: it is the use of models to run operations, not the operation of models you build and ship. WHY IT EXISTS Alert volume grows with system complexity while human attention stays fixed. Past a certain scale, the binding constraint on incident response is not tooling or telemetry but the responder's ability to find the signal — and a queue that pages a person forty times a night trains them to ignore it. AIOps exists to reduce what reaches a human, on the explicit understanding that a suppressed alert is a decision with consequences. WHEN TO USE IT Adopt it when a single underlying failure routinely produces dozens of alerts, when on-call fatigue is measurable, or when correlation is already being done by a person in their head. Do not adopt it to compensate for missing telemetry or undefined ownership: a model trained on incoherent signals produces confident nonsense, and the fix is upstream. WHO OWNS IT The SRE or operations function owns the outcomes — noise reduction, correlation accuracy, and the consequences of a suppression. Whoever supplies the models owns their behaviour and retraining. Critically, the incident commander retains the decision: correlation and probable-cause output is advisory input to a human, and a system that auto-remediates without a human decision has moved into a different risk category that needs its own approval. WHAT GOOD LOOKS LIKE Correlation demonstrably reduces the number of distinct pages per underlying failure, and that reduction is measured rather than assumed. Suppressed alerts are recorded and reviewable, so a missed incident can be traced to the suppression that hid it. Anomaly detection has a measured false-positive rate and someone tunes it. Responders can see why the system grouped what it grouped; an opaque recommendation is one more thing to distrust at three in the morning. Any automated action is bounded, logged and reversible. HOW TO IMPLEMENT Fix the inputs first: consistent service and ownership metadata on every signal is what makes correlation possible at all. Start with deterministic correlation rules — most of the early win is grouping by service and time window, no model required — and measure the reduction. Introduce statistical anomaly detection on a few high-value metrics, measure its false-positive rate honestly, and tune before expanding. Keep a human in the loop on every consequential action until the record justifies otherwise. Treat the models as production systems, which means the practices in /mlops apply to them. HOW TO ASSESS YOURSELF Count pages per incident before and after correlation; if you cannot, you are not measuring the thing you bought. Ask whether anyone reviews suppressed alerts. Ask a responder whether they trust the probable-cause output and why. Take the scored assessment at /assess and sequence the findings with /roadmaps; the response procedures in /runbooks cover what to do when the correlation itself misleads.