Skip to content
JavaAgentic

Type at least two characters. Try “RAG”, “pgvector” or “tool calling”.

AI for DevOps & SRE

Apply AI to DevOps and SRE in Java: incident investigation agents, LLM log analysis, alert correlation and runbook automation — with the read-only-first, human-approved discipline ops demands.

Advanced4 min readUpdated
On this page

DevOps and SRE are promising ground for AI — logs and metrics are text-heavy, incidents follow patterns, and investigation is tedious. They are also exactly where an agent's mistakes are most costly. This tutorial covers useful AI applications in ops, all governed by the read-only-first, human-approved discipline that production demands. The DevAgentic project is the full worked example.

Key Takeaways

  • Investigation agents gather evidence across logs, metrics and deploys far faster than a human.
  • Ops agents are read-only during investigation and propose fixes for approval — never act autonomously on production.
  • AI complements existing ops tooling — use each where it is strong.
  • Ops is where agent guardrails matter most: budgets, approval, scoped access, a kill switch.

The incident investigation agent

When an alert fires, an agent can gather evidence far faster than a human paging through dashboards — provided it can only look, not touch:

Read-only investigation
private static final String SYSTEM = """
        You are an SRE investigating a production incident.
        Method: check recent deployments first (most incidents follow a change),
        then pod health, then logs, then metrics. Form a hypothesis only when
        the evidence supports it.
 
        You have READ-ONLY access. You cannot change anything, and must not imply
        that you have. Report a hypothesis and a recommended action for a human.
 
        Never claim to have checked something you did not check. If the evidence
        is inconclusive, say so.
        """;
 
// All tools are read-only by construction — the agent investigates, a human acts.
var agent = agentBuilder.defaultSystem(SYSTEM)
        .defaultTools(logTools, metricTools, deploymentTools, k8sReadTools)
        .build();

Log analysis

LLMs add correlation and explanation on top of existing log tooling:

// Existing tools find the errors; the LLM correlates them and explains the
// story — "these 200 connection errors started 3 minutes after the deploy of
// service X, which changed the connection pool size" — in plain language.
LogAnalysis analysis = logAnalyst.correlate(errorCluster, deploymentContext);

The value is not replacing your log platform — it is synthesising across sources into a hypothesis a human can act on faster. Statistical alerting stays; the LLM adds the narrative. See AI for data engineering for the complement-not-replace principle.

Alert correlation

Alert storms — dozens of alerts from one root cause — are noise that AI can compress:

// Group related alerts by likely common cause, so on-call sees "one incident:
// database saturation, causing these 15 downstream alerts" instead of 15 pages.
CorrelatedIncident incident = correlator.group(activeAlerts);

This turns a wall of pages into a single actionable incident with its probable root cause surfaced — directly reducing alert fatigue.

Runbook automation

AI can help execute and generate runbooks, within the propose-approve boundary:

Runbook execution behind approval
public Proposal proposeRunbook(Incident incident) {
    // The agent matches the incident to a runbook and drafts the steps.
    Runbook runbook = runbookMatcher.match(incident);
    RemediationPlan plan = agent.planExecution(runbook, incident);
 
    // It PROPOSES the plan. A human approves before any step runs.
    return approvalGate.propose(plan, agent.reasoning());
}

It can also generate runbooks from incident post-mortems — turning "here is what we did to fix it" into a reusable, documented procedure, which is genuinely useful and low-risk.

Guardrails, with extra force

Everything from productionizing agentic systems applies, and ops raises the stakes on each:

Ops agents: read-only investigation, human-approved remediation, scoped access, and a kill switch.
  • Read-only investigation, approved remediation — the core boundary.
  • Scoped access — only the systems the task needs, never blanket production access.
  • Hard budgets — a runaway agent during an incident is a second incident.
  • Trajectory logging — for the post-mortem and for debugging the agent.
  • A kill switch — disable the agent instantly if it misbehaves.

Starting safely

Begin where risk is lowest and value is clear: the read-only investigation agent and alert correlation. Both help immediately and cannot damage anything. Add runbook generation (documentation, low-risk), then, much later and cautiously, runbook execution for a small set of reversible actions behind the approval gate. Autonomous production changes are the last thing you add, if ever. See human-in-the-loop systems.

Next

Frequently Asked Questions

How can AI help with incident response?
An investigation agent can gather evidence across logs, metrics and deployment history far faster than a human paging through dashboards, then propose a hypothesis and recommended action. Crucially it should be read-only during investigation and propose fixes for human approval, not act on production autonomously — the cost of an automated wrong action during an incident is too high.
Can AI analyse logs better than existing tools?
It complements them. Statistical and rule-based tools are cheaper and more reliable for known patterns and numeric thresholds. LLMs add the ability to correlate across sources, explain what a cascade of errors means in plain language, and spot contextual anomalies rules miss. Use each where it is strong rather than replacing proven tooling.
Should an AI agent be allowed to fix production issues automatically?
Only for a narrow set of reversible, low-risk actions, and even then with caution. The safe default is propose-and-approve: the agent investigates and drafts a remediation, and a human approves before it executes. Autonomous production changes by an agent are how a confused agent turns an incident into an outage — the blast radius is too large.
What guardrails does an AI ops agent need?
Read-only tools for investigation, human approval for any change, scoped access to only the systems it needs, a hard step and cost budget, full trajectory logging, and a kill switch. Ops systems are exactly where an agent's mistakes are most costly, so the guardrails from productionizing agents apply with extra force.

Related tutorials