Translated from the Korean original. Some screenshots show the original Korean interface.
From operations that check alerts to operations that make decisions
In IT operations, a shortage of alerts is rarely the problem. We monitor countless metrics, from CPU usage to memory, response time, network, database, and application status, and get an alert in real time whenever one leaves its configured range.
But when alerts pile up every day, the bigger challenge becomes deciding which ones could actually lead to an incident. When false positives keep firing on normal fluctuations, the operations team spends a lot of time checking each alert one by one. On the other hand, there are also false negatives: a real anomaly occurs, but no alert fires because it never crosses the configured threshold. In the end, what matters is not the number of alerts but how accurately you can find patterns that differ from normal in a sea of data, and how quickly you can pinpoint where the anomaly started.
Anomaly detection in AIOps is also evolving to reduce this operational burden. Instead of only checking whether a fixed threshold was crossed, it detects anomalies while reflecting changes in the data, and analyzes relationships between metrics to narrow down where a problem started.
XAIOps is also advancing its analysis framework in this direction: rather than detecting more anomalies, it filters out the ones that actually need attention and helps the operations team make decisions faster.
1. Why do we miss real anomalies when there are so many alerts?
Traditional monitoring has typically set a threshold on a metric and fired an alert when it is exceeded. For example, a Warning alert fires when CPU usage goes above 80%, and a Critical alert when it goes above 90%.
But the state of a real IT environment is hard to define with a single number.
What if a server that usually runs at around 20% CPU suddenly climbs to 70%?
- It has not crossed the 80% threshold, but compared with its usual pattern, it is a change worth checking.
- Conversely, on a server where a batch job runs at set times and pushes CPU usage up to 90%, that number does not necessarily mean an incident.
So the same 90% can be an anomaly on one system and perfectly normal on another.
Anomaly detection in the previous XAIOps calculated the mean and standard deviation by day of week and minute from about 3 months of accumulated data, and flagged values outside that range as anomalies. This has the advantage of defining a normal range from historical data, but real system behavior does not always match past patterns.
In real production environments in particular, traffic can grow gradually, new services can be added, and work patterns themselves can change. As these changes accumulate, a gap can open between the normal range set from past data and the current state of the system. Set the threshold too sensitively and false positives increase as normal changes get flagged as anomalies; loosen it to cut alerts and you are more likely to miss important warning signs. As the number of managed targets and metrics grows, having the operations team check each metric's normal range and repeatedly adjust thresholds also hits its limits.
💡 What we need is not to keep tuning fixed thresholds, but detection criteria that move along with the changing data.
2. Real-time anomaly detection that adjusts its own baseline
To address these limits, XAIOps is advancing its anomaly detection based on the dSPOT (Streaming Peak Over Threshold with Drift) algorithm. The key is that it continuously reflects trend changes in streaming data, known as drift, in the detection process.
Instead of calculating a normal range in advance from a fixed period of data, it updates the detection criteria as new data comes in and judges whether a value is unusual at the current point in time. For example, suppose a metric has been rising gradually over a long period. With a fixed normal range based on past data, you would judge anomalies against the old baseline. If you reflect the real-time trend instead, you can account for the changed environment while still singling out movements that fall outside the expected range for the system's current state.
The goal of XAIOps is a detection framework that cuts unnecessary false positives that keep reacting to normal changes, and more precisely picks out warning signs that were hard to distinguish under the old criteria.
3. Beyond correlation, to where the anomaly started
Finding an anomaly accurately does not end incident analysis. When a real incident occurs, it rarely shows up in just one metric. A problem that starts in one area can spread to other systems, so anomalies can appear in a chain across multiple metrics.
RCA (Root Cause Analysis) in the previous XAIOps showed the metric where the anomaly was detected together with highly correlated metrics. That helps you see which metrics moved together, but on its own it is hard to tell which metric changed first and how the change spread to the others.
The advanced RCA in XAIOps uses Granger causality. Instead of stopping at "A and B changed together," it analyzes how metrics change over time to identify which metric's change preceded another's. So instead of comparing countless metrics one by one every time an incident occurs, you can focus the analysis on the starting point and propagation path, which also shortens the process of narrowing down root cause candidates.
Along with finding where the cause started, it is important to see the relationships between analysis targets at a glance. XAIOps is also applying Auto-Layout to the topology view so that all nodes are arranged automatically and added or removed nodes are reflected on screen automatically. Group and node filters let you focus on the area you need during incident analysis.
If causal analysis narrows down "where the anomaly started," the topology helps operators see system connections and analysis targets more intuitively.
4. Why reducing false positives and false negatives connects to MTTR
False positives and false negatives look like opposite problems, but in operations they end up costing the same thing. With many false positives, the operations team spends time checking alerts that are not real problems; with false negatives, the moment you even notice the problem comes later.
Even after you notice an incident, it takes time. You have to check which metric the problem started in, compare other anomalies from the same time window, and follow the relationships between systems to narrow down root cause candidates. In real incident response, a significant amount of time goes not only into the recovery work itself but also into deciding which alert to look at first and finding where the problem started.
So to reduce MTTR (mean time to recovery), you need to cut not only the time to act but also the time spent on detection and analysis. The direction XAIOps is advancing in connects to this process.
- Anomaly detection that reflects real-time trends filters out the anomalies that need checking.
- Causality-based RCA narrows down where the anomaly started and which way it spread.
- The topology shows related systems and the analysis scope intuitively.
This lets the operations team spend less time triaging alerts and cross-checking metrics by hand, and move faster to judging the real cause and taking action.
In the end, the value of AIOps goes beyond AI finding incidents. It depends on how much human time it can cut across the whole operations flow from detection → analysis → decision.
5. LLM: operations that solve problems by talking to the data
With LLMs added to the mix, the way operations teams access data is also changing. XAIOps plans to expand into an operations assistant that uses LLM and RAG to provide Q&A, summaries, report writing, and action guides.
For example, you will be able to solve problems by asking questions like "Summarize yesterday's alerts for me" or "Where did the anomaly on target A start?" The role of the LLM here is not just adding a chatbot to a monitoring solution.
If anomaly detection finds what is different from normal and RCA narrows down where the problem started, the LLM is closer to an interface that lets the operations team query and understand that analyzed information in natural language.
Instead of moving between screens to dig up the data they need, the operations team can look up related information by asking questions, and summarize analysis results or organize them into reports. Later, this could also extend to checking the action guide needed for the analyzed situation.
It's time for faster decisions, not more alerts
The purpose of anomaly detection is not to find every change, but to separate the changes the operations team actually needs to check and help them quickly narrow down the cause when an incident occurs.
To that end, XAIOps is advancing its analysis framework with dSPOT-based anomaly detection that reflects real-time data trends and RCA using Granger causality. On top of that, topology improvements make analysis targets and system relationships easier to see, and an LLM-based operations assistant is planned to extend coverage of the operations flow to queries, summaries, report writing, and action guides.
But the changes in XAIOps are not limited to making the AI model more accurate.
The product's operational foundation is also being improved for stability and manageability, including Config standardization, backend performance improvements, Dockerizing all services, and redundancy for core modules. On the deployment side, we are also semi-automating ETL integration work to reduce the effort needed to adopt and integrate the product.
So the direction XAIOps is advancing in is hard to sum up as just "AI that finds anomalies better."
It is closer to cutting the time once spent tuning detection thresholds by hand, triaging a flood of alerts, and cross-checking metrics to find the cause. And to connecting detection, root cause analysis, the operator's decisions and actions, and the operational foundation behind them into one flow.
AIOps that shortens operational decision time, from anomaly detection to root cause analysis
Related articles
