AI-Ops : Redefining Application Operations
AI-Ops: What image do you have in mind when running a complex software system? A large team of at least 10 to 20 people, usually near or offshore, sitting 24/7 in front of monitors with system health curves and operating ticket systems and solution databases? So far, this has certainly not been unusual. But the use of artificial intelligence in operations can fundamentally change this picture. Let’s take a look at what AI-Ops makes possible.
What are the main challenges in application operation?
A business-critical system usually has to be maintained around the clock, 365 days a year. If disruptions occur, they must be eliminated as quickly as possible. In addition, system environments are becoming increasingly complex due to the increasing use of microservice architectures.
Because each service is operated on its infrastructure, and the services are only loosely coupled. This makes the technical traceability of requests across multiple services more difficult. This means that the associated documentation and solution databases are also becoming more extensive and troubleshooting measures more complex.
The central challenges are identifying faults in good time, finding their cause quickly, and having the appropriate troubleshooting measures immediately available.
How Can AI-Ops Help Simplify Application Operations?
Artificial intelligence cannot only rectify faults that occur faster or with less manual effort but also avoid them entirely through early detection and automated interventions (predictive analytics). But how exactly does that work?
Troubleshoot Faster:
-
Creating The Error Context:
By automatically gathering context information from all available sources, the causes of errors can be identified more quickly. A support agent no longer has to check different tools separately and compare timestamps with each other. The Artificial Intelligence automatically searches log files, traces, and events for abnormalities simultaneously or at least compiles this information centrally.
-
Recognize Patterns:
Certain error patterns can be classified, and automated countermeasures can be stored, which are initiated when the pattern occurs. For example, individual components could be automatically restarted if errors move into unusual areas.
-
Reduce Event Noise:
The AI can help classify what type of event it is and whether it required action in the past. It is not uncommon for error messages not to indicate an immediate system disruption, especially in architectures designed for resilience. An AI can learn to filter out such events in advance and only consider relevant events.
-
Summarize Distributed Errors:
Errors in distributed systems usually lead to many log messages and event storms. If the AI already aggregates and filters this, it can help significantly to focus on the essential information.
-
Suggest Fault Clearance Measures:
Through learning processes, an AI-Ops can be trained to automatically suggest fault clearance measures that have proven themselves in the past or refer to relevant entries in the solution database.
Avoid Disruptions Completely Or Detect Them Earlier:
-
Recognize And Counteract Anomalies:
An artificial intelligence can recognize anomalies in time series and initiate appropriate countermeasures early. Are several measured values moving in an unusual corridor at the same time? Is the deviation from the usual measuring ranges constantly increasing? The AI-Ops could notify the support team or automatically restart affected components.
-
Predictive Infrastructure Scaling:
An artificial intelligence can examine past system usage to predict periods of high utilization. This means that the infrastructure can be scaled early and proactively.
What Are The Requirements For Using AI-Ops?
As tempting as these things may sound, the use of AI in operations can only work sensibly if the operating system itself meets several requirements. Unfortunately, these are requirements that experience shows are only too happy to be prioritized later since their direct value contribution to the system is not immediately obvious. Well-founded requirements engineering pays off here to take these conditions into account in the future.
Above all, a system must be “observable,” i.e., capable of being monitored. The same applies everywhere else in AI: no data, no AI. The better the data, the better the output. Requirements for observability belong to the group of non-functional requirements – special attention must be paid to them in the requirements process.
As early as the application development stage, it is important to ensure that all relevant measuring points, e.g., B. the number of logged-in users, are available. If time series such as CPU utilization is to be monitored, they must be complete. Insufficient, incorrect, or even missing data mean that artificial intelligence cannot be trained in a meaningful way.
If the AI is to carry out actions independently based on recognized patterns, the system must also be designed so that it can be controlled from the outside. A consistent API-based architecture can help by exposing application functions to the outside world. As early as the design phase, it should be considered which functions will be necessary for operation in the future.
Conclusion
It is no longer a dream of the future to use AI methods in the operation of complex software systems. The necessary methods have long been established, and products are also available to operate even the most extensive systems faster, more specifically, and with less personnel.
But to take advantage of this, some preliminary work must be done on the system itself. In particular, it must be well equipped in terms of observability.
And as in all AI-based use cases, the same applies here: the better the data basis; the more value AI solutions can offer. Creating this basis should be prioritized given the growing complexity of software systems.
