SRE e incidentes

A resposta a incidentes parece, à primeira vista, o caso de uso perfeito para um agente de IA. Boa parte do trabalho de um SRE durante um incidente é leitura e correlação: cruzar um alerta com um deploy recente, vasculhar logs, formar uma hipótese, descartá-la, formar outra. Isso é raciocínio sobre linguagem e sinais, justamente o que LLMs fazem bem. O problema é que a outra parte do trabalho, agir sobre produção no pior momento possível, é das mais arriscadas que existem em engenharia. O estado da arte comercial de 2026 é inteiramente moldado por essa divisão.

Os produtos e o padrão que eles compartilham

Três ofertas saíram do estágio de promessa e viraram produto com disponibilidade geral, e a forma como cada uma desenha a fronteira da autonomia é mais instrutiva que a lista de recursos.

O PagerDuty SRE Agent (GA em outubro de 2025, para clientes AIOps e Advance) é o exemplo mais maduro do padrão dominante. Ele roda diagnósticos, fornece análise, sugere ações de remediação e executa essas ações automaticamente apenas após aprovação humana, confirmando em seguida que o serviço foi restaurado. Além disso, aprende com cada incidente para gerar playbooks que reusa depois, mantendo uma espécie de memória organizacional dos incidentes passados. A frase-chave é “automaticamente após aprovação”: o agente prepara e executa, mas o gatilho da ação com efeito real continua sendo humano.

O incident.io AI SRE empurra o diagnóstico um passo adiante, na direção do código. Ele faz triagem e investigação de alertas, correlaciona mudanças de código, alertas e incidentes históricos para chegar à causa-raiz, e recomenda se o on-call deve agir agora ou pode adiar. Chega a apontar o pull request provável por trás do incidente, e aqui a palavra “provável” é do próprio fornecedor, não um amaciamento: o apontamento é probabilístico, best-effort, não determinístico. Quando a causa é de código, um botão “Code it up” redige uma correção e abre um pull request direto do Slack, sempre como rascunho sujeito a revisão, nunca auto-merge.

A Resolve AI concentra sua proposta na correlação e na investigação estruturada. O agente correlaciona alertas entre serviços e dependências, filtra ruído e ranqueia issues por severidade e impacto de negócio, distinguindo barulho de sistema de incidente real. Para a causa-raiz, formula múltiplas hipóteses testadas em paralelo por agentes especializados, puxando código, infraestrutura, logs, métricas e traces, e entrega a causa identificada com um confidence score, a cadeia de dependências e uma timeline dos eventos.

O que os três têm em comum importa mais que o que os separa. Em todos, a investigação, a correlação e a análise de causa-raiz são autônomas, mas a ação com efeito real (executar a remediação, mesclar o fix) permanece atrás de uma aprovação humana. O estado da arte comercial é o agente que recomenda e prepara, não o agente que decide e age em produção. Ninguém posiciona a remediação destrutiva totalmente autônoma como capacidade de produção, e essa fronteira, até onde a pesquisa alcança, não foi cruzada comercialmente.

A fronteira é a confiabilidade, e os próprios vendedores a admitem

O Eixo B do SRE é mais difícil de documentar com honestidade do que parece, e vale ser explícito sobre o porquê. Existe uma literatura acadêmica sobre RCA agêntico com LLMs, com benchmarks e estudos de modos de falha, mas os números específicos que circulam (acurácias baixas de hipótese de causa-raiz, taxas de erro de classificação) não sobreviveram à verificação independente nesta pesquisa, e por isso não são citados aqui como fato. Afirmá-los seria emprestar precisão a algo que não a tem.

O sinal confiável do gap, então, vem de onde menos se esperaria: das ressalvas que os próprios fornecedores e seus clientes admitem. O hedge é constante e onipresente, “pull request provável”, “confidence score”, e os ganhos de acurácia que aparecem são benchmarks internos não auditados, do tipo “2x mais preciso” sem metodologia divulgada. Um estudo de caso documentado do incident.io é ainda mais franco: reconhece que não há uma linha reta até a causa correta de um incidente, que os falsos positivos (achados tecnicamente reais mas irrelevantes para o incidente) são o problema maior, que a acurácia não é divulgada, e registra um caso concreto em que o agente falhou em encontrar o pull request que tinha causado a falha. Análises comparativas independentes apontam na mesma direção, com agentes lendo métricas erradas ou só em nível de host quando o incidente estava no nível do pod.

A conclusão defensável é uma só, e é menos animadora que o marketing: a capacidade existe e é demonstrável como feature, mas a confiabilidade medida em produção permanece indeterminada, e quem está mais perto de quantificá-la, os próprios fornecedores, escolhe hedgeá-la em vez de publicá-la. Para quem avalia adotar, isso transforma a pergunta certa de “o agente faz RCA?” (faz) para “qual a taxa em que ele erra a causa, e quanto custa seguir uma hipótese errada durante um incidente?”, para a qual não há resposta pública.

Convém registrar também o que esta rodada de pesquisa não cobriu. Outros nomes povoam o ecossistema de AI SRE (Rootly, FireHydrant, Cleric, entre outros), mas não geraram afirmações verificadas aqui, então o panorama acima é sólido sobre PagerDuty, incident.io e Resolve AI, e apenas indicativo sobre o resto do mercado.

Fontes

Palavras-chave

Conceitos: SRE, resposta a incidentes, triagem de alertas, correlação, análise de causa-raiz, RCA, remediação, playbooks, human-in-the-loop, confidence score, falsos positivos Produtos: PagerDuty SRE Agent, incident.io AI SRE, Resolve AI Ferramentas: Slack, AIOps