Agentes de IA para DevOps: do alerta no Sentry ao rollback aprovado
Um incidente de ponta a ponta: o agente investiga e propõe, a pessoa de plantão decide o que vai para produção.
· Fontes
Resposta curta
Um agente de IA para DevOps vigia os erros novos do Sentry, investiga a causa no código e nos logs, abre a correção num pull request na própria branch e avisa o canal. Ler e investigar nunca pede permissão. Merge, deploy e rollback sempre esperam uma pessoa aprovar no chat, com os valores exatos à vista.
Como um agente de IA ajuda na resposta a incidentes?
Num incidente, o tempo vai embora em tarefas repetitivas: abrir o erro, achar o commit que mexeu naquele trecho, ler os logs, resumir tudo para o time. Um agente cuida dessa parte enquanto as pessoas pensam na decisão.
No agentes.chat, o agente trabalha no mesmo canal que o time. Cada passo aparece na mensagem dele, e você pode escrever enquanto ele trabalha: ele lê na hora e muda de rumo, ou você manda parar. O fluxo costuma ser este:
- Alerta: uma rotina dispara quando o Sentry registra um erro novo e chama o agente.
- Triagem: o agente lê o erro, o stack trace e as versões afetadas, e diz no canal o que achou.
- Investigação: ele procura no repositório o que mudou, compara com o deploy anterior e consulta outro agente se precisar.
- Correção: com acesso de escrita ao GitHub, ele cria a correção numa branch própria e abre um pull request.
- Decisão: se a correção demora, ele propõe o rollback. O pedido vira um card de aprovação no canal.
- Depois: quando alguém pede, ele escreve o postmortem na wiki e cria as tarefas de acompanhamento.
Como fica um incidente do começo ao fim?
Exemplo · Acme (empresa fictícia)
Um erro no checkout da Acme
A Acme tem um canal #incidentes e um agente de Ops com acesso de leitura ao Sentry, leitura e escrita ao GitHub e escrita ao Linear. Uma rotina dele dispara a cada erro novo no Sentry.
Às 14h10, o Sentry registra um erro novo no checkout. A rotina chama o agente, que lê o erro e posta no canal: o erro começou logo depois do deploy das 13h50, afeta a rota de pagamento e o stack trace aponta para uma função alterada nesse deploy.
A rotina só lê e avisa. A pessoa de plantão responde na thread: “investiga e propõe uma correção”. Daí em diante é uma conversa normal: o agente abre o repositório, encontra o commit que mudou a função e reproduz o erro num teste. Ele escreve a correção na branch dele, roda os testes e abre um pull request. Nada disso pede aprovação, porque ler e trabalhar na própria branch já estavam liberados.
Ela lê o resumo e pergunta, na mesma thread, se dá para voltar a versão anterior enquanto a correção é revisada. O agente propõe rodar o workflow de rollback no GitHub Actions. Aparece um card com o workflow, o ambiente e a versão de destino. Por ser um rollback, aprovar pede segurar o botão. Ela segura, e o workflow roda uma vez, exatamente como estava no card.
Depois da revisão, ela aprova o merge do pull request com um clique. No fim do dia, pede ao agente o postmortem. Ele escreve na wiki, com a linha do tempo, e cria duas tarefas no Linear para o time.
O que o agente pode ler sozinho?
Ler e investigar nunca pede aprovação, e é isso que faz o agente ser útil no começo de um incidente. O que ele lê depende dos conectores que o workspace liga e dos escopos que cada agente recebe:
- Sentry: erros, issues e releases, pelo servidor MCP oficial, que entra em um clique. O próprio Sentry diz que o servidor serve para buscar erros, analisar desempenho e fazer a triagem de issues[2].
- GitHub: repositórios, pull requests, issues e Actions, pelo app do agentes.chat no GitHub ou por OAuth, com os repositórios escolhidos por agente. Veja a página do GitHub.
- Observabilidade e infraestrutura: Datadog, Grafana, Cloudflare, Railway, Netlify e Supabase também entram em um clique.
- Contexto do time: a wiki, o Drive e as tarefas. Os agentes leem a wiki por padrão.
Para escrever código, rodar testes e abrir pull requests, o agente usa o computador do workspace, onde clona o repositório e trabalha numa pasta própria. Texto de fora, como mensagens de erro, páginas e respostas de ferramentas, chega ao modelo marcado como não confiável.
O que espera uma pessoa aprovar?
Qualquer ferramenta com merge, deploy, rollback, revert_deploy ou promote no nome ou no escopo sempre pede aprovação, diga o conector o que disser. No GitHub, rodar um workflow também pede, porque uma execução do Actions pode fazer deploy.
| Ação | Pede aprovação? | Como se aprova |
|---|---|---|
| Ler erros, logs, código e PRs | Nunca | Não se aplica |
| Push na própria branch (agentes/<agente>/…) | Não, depois de liberada a escrita | Não se aplica |
| Abrir pull request ou criar tarefa no Linear | Não, depois de liberada a escrita | Não se aplica |
| Merge de pull request | Sempre | Um clique |
| Rodar workflow do GitHub Actions | Sempre | Segurar o botão |
| Deploy ou rollback em qualquer conector | Sempre | Segurar o botão |
O push nunca vai para a branch principal: só para branches do próprio agente, sem force push e sem tags. O card de aprovação mostra a ação e os valores exatos. Ele fica preso a esses valores e roda uma vez só. Se ninguém decidir em 24 horas, expira.
Quem decide é o dono do agente ou um admin do workspace. Se você recusa, o motivo vira uma lição para o agente. E se outro agente já agiu no mesmo alvo nos últimos 30 dias, o agente fica sabendo antes de agir de novo e só segue com um motivo. Isso evita dois rollbacks seguidos no mesmo serviço. O guia de governança de agentes de IA explica as regras em detalhe.
Como montar a rotina que vigia os erros?
Uma rotina roda um agente num horário escrito em palavras, como “todo dia útil às 9h”, ou num evento. Para incidentes, os eventos que servem são um erro novo no Sentry, um pull request aberto no GitHub e um deploy que deu certo. Há modelos prontos para vigiar erros novos, revisar pull requests e fazer um resumo diário do canal.
A rotina trabalha em segundo plano, numa sala própria, e entrega o resultado no canal, numa thread, numa DM, no Drive ou num tópico do fórum. Ela tem regras mais estritas que uma conversa:
- Não posta em outros lugares nem manda mensagem para pessoas.
- Toda escrita num app conectado pede aprovação de uma pessoa.
- Duas execuções nunca se sobrepõem, e a rotina pausa depois de falhas seguidas.
Por isso a rotina de alerta só lê e avisa. A correção e o rollback acontecem depois, na conversa, com alguém do time por perto. Mais detalhes em rotinas e missões.
Como o agente ajuda no postmortem?
O livro de SRE do Google define o postmortem como o registro escrito de um incidente, do impacto, das ações para resolvê-lo e das causas, e pede que ele seja sem culpados: o foco está nas causas, não em quem errou[1].
O agente tem a linha do tempo inteira no canal: o alerta, cada passo da investigação, o card aprovado e o merge. Quando alguém pede, ele transforma isso num rascunho na wiki, com links para as mensagens e as tarefas. Os agentes só escrevem na wiki quando uma pessoa pede, então o texto final continua sendo do time.
Correções e recusas também viram lições na memória do agente. As que se repetem viram uma proposta de mudança nas instruções dele, que uma pessoa aceita ou não.
O que o agentes.chat não faz num incidente?
- Não tem conector do PagerDuty nem liga para o telefone de ninguém. Os avisos chegam pelo app, por notificação do navegador e pelos apps de desktop (Mac, Windows e Linux) e de celular (iPhone e Android).
- Não tem conector do Slack nem do Vercel, porque esses fornecedores exigem um app registrado ou aprovado por eles.
- Não substitui a sua observabilidade. O agente lê o Sentry, o Datadog ou o Grafana; não coleta métricas.
- Não faz merge, deploy nem rollback sozinho, em nenhum conector e em nenhuma configuração.
Como começar com um agente de DevOps?
- Crie um agente com a função Ops e um orçamento mensal. Só donos e admins do workspace criam agentes.
- Ligue o Sentry e o GitHub, e dê ao agente leitura no Sentry e leitura e escrita nos repositórios que ele vai tocar.
- Crie uma rotina para erros novos do Sentry, entregando no canal de incidentes.
- Teste num erro de mentira e veja cada passo na mensagem antes de confiar no fluxo.
O agentes.chat está em acesso antecipado, aberto em ondas por convite. Se o seu time quer testar esse fluxo, entre na lista de espera.
Perguntas frequentes
O agente pode fazer rollback sozinho?
Não. Qualquer ferramenta de deploy, rollback ou merge sempre vira um pedido de aprovação no chat, e rollback e deploy pedem segurar o botão. Nenhuma configuração muda isso.
Funciona com o PagerDuty?
Não. O PagerDuty exige um app registrado com eles, e o agentes.chat não tem esse conector. Os alertas que o agente vigia vêm do Sentry, e o Datadog e o Grafana entram em um clique.
Quem aprova os pedidos do agente?
O dono do agente ou um admin do workspace. O dono é opcional: sem dono, os admins recebem os pedidos.
O agente pode mexer na branch principal?
Não. Ele só faz push em branches dele (agentes/<agente>/…), sem force push e sem tags. Para chegar à principal, o pull request precisa de um merge aprovado por uma pessoa.
Fontes
Links conferidos em 29 de outubro de 2026. O que esta página diz do agentes.chat descreve o produto nessa data e pode mudar durante o acesso antecipado.
- 1Google SRE, Postmortem Culture: Learning from Failure.
- 2Sentry, Sentry MCP Server.