Oncall Bot e monitoramento de frontend

O problema

Desistências silenciosas na passagem para terceiros, como as verificações NFC, eram descobertas dias depois pelo atendimento ao cliente. Nossos alertas eram baseados em limites fixos e barulhentos, e as pessoas tinham aprendido a ignorá-los.

A abordagem

• Linhas de base relativas, não limites fixos. O serviço de alertas executa SQL no ClickHouse e compara cada métrica com a mesma hora da semana anterior. Uma queda de 20 % na conversão significa uma coisa às 3 da manhã em Tóquio e outra ao meio-dia em Berlim, e as variações do tráfego global deixam de gerar alarmes falsos.
• Um alerta que chega com contexto. Quando um alerta dispara, ele publica um cartão de incidente na plataforma de chat interna. Em seguida, um processo em segundo plano reúne stack traces recentes de erros do frontend no ClickHouse, a versão de configuração ativa no serviço de configuração e os logs de deploy do Kubernetes, e os envia como um prompt estruturado para uma API de LLM corporativa.
• Um resumo no próprio fio. O bot responde com uma causa provável, por exemplo: conversão da etapa 3 caiu 32 % no Japão, um erro de ponteiro nulo no wrapper da ponte NFC, uma mudança de configuração publicada 15 minutos antes e o gateway de um fornecedor estourando o tempo no backend.

O resultado

O tempo de detecção caiu de horas ou dias para menos de 5 minutos, o tempo de mitigação caiu 65 % e os alertas falsos, 80 %. Também foram acompanhados a relação sinal-ruído dos alertas (a parcela ligada a incidentes reais) e o tempo médio entre falhas dos módulos de frontend.

Por que assim

Um alerta comum só diz que algo quebrou. Coletar os dados automaticamente e resumi-los fecha a distância entre uma métrica e uma pessoa que a entende, e era ali que ia a maior parte do tempo de resposta.