Triagem de erros automatizada, pronta antes do standup

O Zero é um agente de IA para DevOps que automatiza a triagem diária de erros. Toda manhã, ele coleta os erros não resolvidos do Sentry e do Axiom, os deduplica entre as duas fontes e abre issues atribuídas no GitHub com stack traces completos antes do standup, economizando de 20 a 30 minutos de revisão manual dos engenheiros.

O Zero conecta:SentryAxiomGitHub

O que o Zero entrega: um relatório diário de triagem de erros

Explore um exemplo de relatório de triagem de erros gerado por IA, com incidentes priorizados, deduplicação entre fontes, issues atribuídas no GitHub, severidade, volume e tempo economizado. Os dados são ilustrativos; o formato do relatório é uma saída real que o Zero pode gerar a partir do Sentry e do Axiom.

Zero · Relatório de automaçãoDados de exemplo

Resumo do agente

O Zero inspecionou 17 erros brutos do Sentry e do Axiom, os deduplicou em 13 causas-raiz, criou 6 issues atribuídas no GitHub e encaminhou 2 sinais apenas para acompanhamento ao #dev.

Erros brutos inspecionados
1712 Sentry · 5 Axiom
Causas-raiz únicas
13após a deduplicação
Issues criadas no GitHub
6todas atribuídas
Abrir o relatório diário completo de triagem de erros

O que é triagem de erros?

Triagem de erros, também chamada de bug triage ou incident triage, é o processo de agrupar, priorizar e atribuir os erros de produção para que os engenheiros saibam o que corrigir primeiro. O Zero atua como um agente de IA de SRE entre Sentry, Axiom e GitHub: ele deduplica erros, aplica limites, anexa stack traces e atribui os responsáveis pelo código. O resultado é uma automação consistente de triagem diária de erros com menos fadiga de alertas.

Por que a triagem manual de erros gera fadiga de alertas

Toda manhã, um engenheiro precisa abrir o Sentry, percorrer os alertas não resolvidos, cruzar com o Axiom, identificar o que é novo ou duplicado, decidir o que é sério, abrir issues no GitHub e encontrar o responsável certo. Essa primeira passada repetitiva custa de 20 a 30 minutos de tempo de engenharia focado e gera fadiga de alertas antes mesmo do trabalho de verdade começar. O Zero roda às 8h45 e conclui a mesma triagem antes que alguém abra o laptop.

Como o Zero automatiza a triagem diária de erros

Passo 1: conecte suas ferramentas

Sentry
Sentry
Obrigatório
A integração do Zero com o Sentry consulta erros de produção não resolvidos, stack traces, contagens de eventos e tags de ambiente.
Conectar
GitHub
GitHub
Obrigatório
A integração do Sentry com o GitHub abre issues estruturadas com os detalhes completos dos erros e as atribui aos responsáveis pelo código.
Conectar
Axiom
Axiom
Opcional
O Zero consulta o Axiom em busca de logs de erro para cruzar e deduplicar com os achados do Sentry. Opcional, mas recomendado.
Conectar

Passo 2: peça ao Zero

@Zero todo dia útil às 8h45, colete os erros não resolvidos do Sentry e do Axiom das últimas 24 horas. Deduplique entre as fontes. Para qualquer coisa com 5+ ocorrências, abra uma issue no GitHub em vm0-ai/vm0 com o stack trace completo e atribua ao responsável pelo código correspondente.
Um exemplo de execução do mesmo workflow, passo a passo: coletar e classificar as issues do Sentry, sinalizar regressões de deploy, renderizar gráficos, publicar o relatório e postá-lo no Slack.
O Zero coleta os erros não resolvidos do Sentry e do Axiom
O Zero consulta tanto o Sentry quanto o Axiom em busca de erros não resolvidos dentro da janela de tempo que você definir e então aplica seu limite de ocorrências, para que o ruído de baixo sinal seja filtrado e apenas os erros que acontecem em escala passem.
Erros duplicados são mesclados entre Sentry e Axiom
O mesmo erro muitas vezes aparece tanto no Sentry quanto no Axiom com formatações diferentes. O Zero os deduplica em um único registro que combina dados de ambas as fontes, para que você faça a triagem de cada problema real apenas uma vez.
Issues são abertas no GitHub e atribuídas aos responsáveis pelo código
Para cada erro único que se qualifica, o Zero abre uma issue estruturada no GitHub com o stack trace completo, a contagem de ocorrências e os horários da primeira e da última ocorrência, e então a atribui ao engenheiro responsável por aquela área do código — a passagem do Sentry ao GitHub, automatizada de ponta a ponta.

Passo 3: leve mais longe

Ajuste o limite
Mude o filtro de ocorrências para reduzir o ruído ou capturar mais issues.
@Zero atualize o agendamento da triagem diária para abrir issues apenas para erros com 10+ ocorrências. Para qualquer coisa abaixo disso, apenas publique um resumo em #dev.
Adicione ao seu briefing matinal
Incorpore a triagem de erros ao briefing de saúde do produto que seu time já lê.
@Zero inclua o resultado da triagem de erros de hoje no briefing de saúde do produto das 9h que você publica em #standup.
Verificação de segurança pós-deploy
Rode a triagem logo após um deploy em produção para que as regressões apareçam em minutos, e não na manhã seguinte.
@Zero sempre que um PR for mergeado na main em vm0-ai/vm0, espere 15 minutos e então execute uma verificação de novos erros no Sentry.

Integrações com Sentry, GitHub e Axiom para triagem de erros

Este fluxo é uma integração entre Sentry e GitHub com um agente no meio: o Zero lê do Sentry, confere a mesma janela de tempo no Axiom e escreve no GitHub. Cada conector é autorizado separadamente e fica limitado ao que o fluxo realmente usa, então o acesso de leitura aos seus dados de erro nunca significa acesso de escrita aos seus repositórios.

Sentry

Integração com o Sentry: os erros que o Zero lê

Obrigatório

O Zero lê o seu rastreamento de erros no Sentry pela API de issues e consulta os erros não resolvidos nos ambientes que você indicar, ordenados por frequência. De cada um ele lê o título e o culprit, a contagem de eventos e de usuários afetados, o nível e os horários de primeira e última ocorrência, e depois busca o evento mais recente para obter o stack trace completo com as tags de release e ambiente. Isso cobre o que a decisão de triagem precisa: o que quebrou, com que frequência, onde e desde quando. Neste fluxo a integração com o Sentry é somente leitura: o Zero nunca resolve, mescla ou reatribui suas issues do Sentry, e o registro que ele escreve vai para o GitHub.

GitHub

Integração com o GitHub: as issues que o Zero abre

Obrigatório

Todo erro que passa do seu limite vira uma issue no repositório que você indicar ao Zero. A issue traz o título do erro, o stack trace, a contagem de ocorrências e de usuários afetados, os horários de primeira e última ocorrência e um link de volta para a issue do Sentry, para os dados originais ficarem a um clique. O Zero aplica as labels que você definir e atribui o code owner dos arquivos citados no stack trace. O acesso de escrita se limita aos repositórios que você autorizar, e abrir issues é tudo o que ele faz: sem commits, sem pull requests, sem mexer nas configurações do repositório.

Axiom

Integração com o Axiom: os logs do Axiom que o Zero cruza

Opcional

O Axiom é opcional e se justifica pela deduplicação. Se a sua gestão de logs já roda no Axiom, o Zero a lê na mesma passagem: ele roda uma consulta APL nos datasets que você escolher, limitada à mesma janela de tempo da leitura do Sentry, e compara esses logs do Axiom com as assinaturas de erro que já tem. Isso pega o caso em que uma mesma falha aparece duas vezes em formatos diferentes e acrescenta o contexto no nível da requisição em torno da falha, que o evento do Sentry sozinho não carrega. Sem o Axiom o fluxo roda do início ao fim mesmo assim, e a deduplicação passa a se apoiar só nos dados do Sentry.

Zero vs. triagem manual vs. regras de alerta do Sentry

A triagem diária de erros é a primeira camada da resposta automatizada a incidentes. Os times automatizam do Sentry ao GitHub com o Zero, concluindo a primeira passada repetitiva antes que um problema exija um gerenciamento de incidentes com IA mais amplo.

Triagem manual

Um engenheiro revisa o Sentry e o Axiom, identifica duplicados, decide a severidade, abre issues e encontra um responsável. É flexível, mas repete os mesmos 20 a 30 minutos de trabalho toda manhã.

Regras de alerta do Sentry

As regras notificam o time quando um limite é ultrapassado. São úteis para a detecção, mas o time ainda precisa correlacionar logs, deduplicar erros, criar issues no GitHub e atribuir responsáveis.

A automação de workflow do Zero para o Sentry

O Zero roda a automação do Sentry de ponta a ponta: consulta, deduplicação entre fontes, aplicação de limites, criação de issues, anexação de stack traces e atribuição aos responsáveis pelo código. As execuções sob demanda e pós-deploy usam o mesmo workflow.

Dicas para melhores resultados

Defina um limite de ocorrências para manter a quantidade de issues gerenciável. 5+ é um bom ponto de partida; ajuste conforme seu volume.
Restrinja a consulta do Zero à produção usando os ambientes ou as tags de projeto do Sentry, para que erros do staging nunca cheguem à fila de triagem.
Encadeie a triagem diária com verificações pós-deploy para transformar uma rotina em uma resposta a incidentes leve e automatizada, e combine com o briefing de saúde do produto das 9h para que o time veja erros e status em um só lugar.

Perguntas frequentes

Como fazer a triagem de erros do Sentry e transformá-los em issues do GitHub?

Para criar issues no GitHub a partir do Sentry automaticamente, conecte o Sentry e o GitHub ao Zero e então dê a ele um agendamento ou um prompt sob demanda. O Zero consulta os erros não resolvidos, aplica filtros de ocorrências e de ambiente, cria uma issue por erro que se qualifica, anexa o stack trace e os horários, e atribui um responsável pelo código.

Como deduplicar erros entre o Sentry e o Axiom?

Sim. O Zero compara assinaturas de erro, stack traces, mensagens e tempo entre o Sentry e o Axiom, e então mescla os eventos correspondentes em um único registro de triagem. Cada fonte de origem permanece vinculada para investigação.

Como reduzir a fadiga de alertas do monitoramento de erros?

Limite a triagem à produção, defina um limite de ocorrências, deduplique o mesmo erro entre as ferramentas e encaminhe os erros de baixo volume para um resumo em vez de criar uma issue. Isso mantém a fila focada nos erros que exigem ação.

O Zero pode rodar a triagem de erros após cada deploy?

Sim. Crie uma automação que inicie o workflow de triagem de erros após um deploy ou merge na main, opcionalmente aguarde uma breve janela de observação e então verifique o Sentry em busca de novos erros de produção e abra as issues que se qualificam.

Quais ferramentas a automação de triagem de erros precisa?

Sentry e GitHub são obrigatórios: o Sentry fornece os dados dos erros e o GitHub recebe as issues atribuídas. O Axiom é opcional, mas adiciona contexto de logs e melhora a deduplicação entre fontes.

Quais permissões a integração entre Sentry e GitHub precisa?

O Sentry precisa de acesso de leitura a issues e eventos dos projetos que você tria. O GitHub precisa de permissão de escrita de issues nos repositórios que vão recebê-las. O Axiom, se você usar, precisa de acesso de consulta aos datasets indicados. Cada conector é autorizado separadamente no Zero, e revogar um não afeta os outros.

O Zero pode abrir issues em mais de um repositório do GitHub?

Pode. Informe qual serviço ou projeto corresponde a qual repositório e o Zero encaminha cada issue de acordo: erros de frontend vão para o repositório web e erros de API para o do backend. Esse mapeamento fica no prompt, então você pode mudá-lo sem reconfigurar o conector do GitHub.

O Zero muda alguma coisa no Sentry?

Não. Aqui a integração com o Sentry é somente leitura: o Zero consulta issues e eventos e não escreve nada de volta. Os status das suas issues, as atribuições e o histórico de resoluções ficam exatamente como seu time deixou. A única coisa que o Zero cria é a issue no GitHub.

Rode sua primeira triagem do Sentry

Conecte o Sentry, o GitHub e, opcionalmente, o Axiom. Use o mesmo prompt de triagem diária para ver o workflow em ação sem precisar reconstruí-lo manualmente.

@Zero todo dia útil às 8h45, colete os erros não resolvidos do Sentry e do Axiom das últimas 24 horas. Deduplique entre as fontes. Para qualquer coisa com 5+ ocorrências, abra uma issue no GitHub em vm0-ai/vm0 com o stack trace completo e atribua ao responsável pelo código correspondente.