News & Insights
AIOps Explained: How AI Is Changing IT Operations
AIOps, short for artificial intelligence for IT operations, is the use of machine learning and language models to read the logs, metrics and alerts your infrastructure produces, decide which events matter, and act on them, usually through your IT service management processes. For an IT operations team in Malaysia, AIOps changes where people spend their time: less on reading logs and sorting alerts, more on the incidents that need judgement.
The practical questions are which operations problems AIOps solves, how far automated fixes should go before a person approves them, and where your operations data is processed. The answers below apply whichever AIOps platform you use.
What AIOps Means in IT Operations
AIOps means applying artificial intelligence to the day-to-day work of keeping IT systems running: monitoring, event triage, ticketing and routine remediation. An AIOps platform takes in operational data from servers, virtual machines, containers, networks and applications, including logs, performance metrics and alerts, and looks for patterns a person would otherwise have to find by reading through that data.
AIOps differs from conventional monitoring in what happens after an alert fires. A conventional monitoring tool raises an alert when a threshold is crossed, such as disk usage above a set percentage, and leaves a person to decide what it means. An AIOps platform interprets the event in context, decides whether it is a real issue, and can open a ticket or run a fix.
The IT Operations Problems AIOps Addresses
AIOps addresses four problems that grow with the size of an IT estate, because each one depends on people reading and sorting machine data by hand.
- Alert fatigue: Monitoring tools can generate more alerts than a team can review, and when alerts that need no action outnumber real ones, real issues are missed or reach the right person late.
- Manual log review: Finding the cause of a fault means searching logs across several servers and containers, which takes an engineer’s time on work that follows the same pattern each time.
- Inconsistent triage: Two engineers can classify the same event differently, so similar incidents get different priorities depending on who is on shift.
- Slow ticketing: When an engineer has to create the ticket, describe the event and assign it by hand, the incident record starts late and can lack the detail needed to fix it.
How AIOps Works: Ingest, Classify, Remediate
AIOps works in three stages, each of which replaces a step an engineer currently does by hand.
1. Ingest
The platform collects logs and metrics from the systems it monitors, such as virtual machine metrics, application logs and container logs, into one place. Collecting from every monitored system matters because related events, such as a disk filling up and an application failing on the same server, are only visible when the data sits together.
2. Classify
The platform’s model assesses each event and assigns it a category, for example a real issue that needs action, a false alarm, or normal behaviour. Classification is where language models add value over rule-based monitoring, because a model can read an unfamiliar log message and judge what it means rather than matching it against a fixed list.
3. Remediate
For events classified as real issues, the platform identifies a likely root cause and either runs an approved fix, such as clearing temporary files on a server running out of disk space or restarting a failed container, or raises a ticket with the diagnosis attached for an engineer to act on.
Why Human-in-the-Loop Controls Matter in AIOps
Human-in-the-loop controls decide which AIOps actions run automatically and which wait for a person, and they are what make automated remediation safe to use on production systems. A well-run AIOps rollout starts with automated classification and ticketing only, then adds automated fixes one type at a time as the team confirms the platform’s judgement is reliable for that type.
Three controls do most of the work. First, a confidence threshold routes uncertain classifications to a reviewer instead of acting on them. Second, an approved list limits automated fixes to low-risk, reversible actions, while anything that changes configuration or affects customers waits for approval. Third, an audit trail records what the platform saw, what it decided and what it did, so every automated action can be reviewed later.
Some decisions should stay with people regardless of how reliable the platform becomes, particularly where a regulatory clock starts. Under Malaysia’s Cyber Security Act 2024, in force since 26 August 2024, an authorised person at a national critical information infrastructure (NCII) entity must give an initial report to the National Cyber Coordination and Command Centre System within six hours of discovering a cyber security incident. An AIOps platform can surface the event quickly, but deciding whether it is a reportable incident is a human call.
How AIOps Fits Alongside ITSM Processes
AIOps feeds IT service management rather than replacing it. AXELOS, which manages the ITIL framework, describes incident management as minimising the negative impact of incidents by restoring normal service operation as quickly as possible. AIOps supports that aim at the start of the process, by detecting, classifying and logging incidents faster, while the incident, problem and change practices your team already runs stay in place.
Three integration points decide whether AIOps strengthens your service management or bypasses it:
- Ticket creation: The AIOps platform should create and update tickets in your existing ITSM tool, with the diagnosis attached, so every incident has one record.
- Change control: Automated fixes are changes, so each type of fix should be approved once as a standard change before the platform is allowed to run it.
- Problem management: Patterns in AIOps classifications, such as the same disk alert recurring on one server, are inputs for problem management, which looks for the underlying cause rather than fixing the same symptom repeatedly.
AIOps vs DevOps: What Each Covers
AIOps and DevOps address different parts of IT. DevOps is a set of practices that brings software development and operations together to release changes faster and more reliably, covering how code is built, tested and deployed. AIOps applies AI to running systems after they are deployed, covering how events are detected, triaged and resolved. The two connect where an AIOps platform watches the systems a DevOps team releases and feeds incidents back to that team.
Where AIOps Processes Your Operations Data
Where an AIOps platform processes your logs is a data protection decision as much as a technical one. Infrastructure logs can contain usernames, IP addresses, hostnames, file paths and fragments of application data. An AIOps platform that sends those logs to an external AI service moves that data outside your environment.
The alternative is a Local LLM, a large language model deployed on-premises or on your own infrastructure, so log data is classified without leaving your environment. Before choosing a platform, ask where models run, whether any log data is sent to an external service, and who can access the stored logs and decisions.
AIOps Readiness Checklist
| Check | What good looks like |
| Data sources mapped | You know which servers, virtual machines, containers and applications will send logs and metrics |
| Event categories agreed | The team has defined what counts as a real issue, a false alarm and normal behaviour |
| Confidence threshold set | Uncertain classifications go to a named reviewer rather than triggering action |
| Automated fixes approved | Each automated fix is a low-risk, reversible action approved as a standard change |
| ITSM integration in place | The platform creates and updates tickets in your existing ITSM tool |
| Escalation route defined | Reviewers are alerted and can escalate an event in one step |
| Audit trail retained | Every classification and automated action is recorded and reviewable |
| Data location confirmed | You know where models run and whether any log data leaves your environment |
| Reportable incidents owned | A named person decides whether an event triggers a regulatory notification |
Where We Fit
At Strateq, we have delivered enterprise systems and managed services in Malaysia since 1983, and our Enterprise System Solutions and Enterprise Business Solutions practices operate under ISO/IEC 20000-1:2018, the international standard for IT service management, and ISO/IEC 27001:2022.
Our AI-Ops Agent (Alert-A) collects logs and metrics from monitored virtual machines, including Docker and journal logs, and uses a Local LLM to classify every event as a True Issue, False Issue or Normal, so your log data never leaves your environment. For real issues, it runs root cause analysis and executes the fix on the affected virtual machine. Uncertain cases go to reviewers with email alerts and one-click escalation, and tickets are created and tracked through ITSM integration, with status synced every minute. Typical events it handles include server outages, Docker crashes and disk space alerts.
To see how incident, request and change practices fit together around AIOps, read our guide to IT service management in Malaysia.