Finuslugi coloca agentes de AI para trabalhar à noite: eles encontraram problemas em 1600 cadastros sem alertas

Os problemas mais incômodos em produção não parecem incidentes. Os principais gráficos estão no verde, os alertas ficam em silêncio e o serviço está disponível, mas a proporção de operações malsucedidas ou o tempo de resposta aumenta em uma etapa da jornada do usuário. Para o sistema como um todo, está tudo bem; para aquela pessoa, o produto está quebrado.

Toda semana, a equipe de cadastro da Finuslugi percorria manualmente o mesmo caminho: Grafana, depois os logs no OpenSearch, depois a busca pela operação de negócio problemática e pelo código relacionado. Isso consumia de quatro a oito horas por semana, antes mesmo de o engenheiro começar a pensar no que corrigir. Foi essa parte que decidiram automatizar: a coleta de fatos e a preparação de uma hipótese, mantendo as decisões com a equipe.

Como funciona o fluxo noturno

Uma tarefa é criada conforme o agendamento (no Multica, esse recurso se chama Autopilot), e o OpenCode assume sua execução. Em seguida, entra em ação o agente líder: via MCP, ele lê no Confluence o catálogo de operações de negócio e as regras de controle de cada uma. No cenário básico do Prometheus, são 21 operações. O agente líder distribui essas operações entre sete agentes subordinados, três para cada um, que verificam suas respectivas áreas em paralelo.

O diagnóstico é dividido deliberadamente em duas etapas. Na primeira, o agente coletor trabalha dentro de um único ambiente de observabilidade e responde a uma pergunta específica: existe algum desvio e qual é sua gravidade? Ele compara os fatos com o SLA e a linha de base e atribui o status OK, WARNING ou BREACH. O resultado é uma ficha curta: operação, valor observado, SLA, linha de base e dados que sustentam a avaliação. Apenas os casos WARNING e BREACH chegam ao agente analista. Ele abre o repositório relacionado e formula uma hipótese sobre a causa.

Se o desvio for confirmado, o Multica monta um rascunho de tarefa no Jira. Ele inclui a operação de negócio, os valores das métricas, a violação do SLA, o contexto técnico, a causa e uma proposta de correção. A palavra-chave aqui é “rascunho”: quem coloca a tarefa no backlog é o engenheiro, depois de verificar as conclusões.

Por que não basta passar todos os logs para o modelo

A tentação é compreensível: “olhe todos os serviços, métricas, logs e código e encontre algo suspeito”. Na prática, esse pedido esbarra no tempo de execução, no tamanho do contexto e na qualidade da resposta. Quanto mais heterogêneos os dados, mais difícil fica entender o que sustenta a hipótese.

Por isso, o SLA e a observabilidade primeiro delimitam a busca, e cada subtarefa passa a ser tanto uma unidade de paralelismo quanto um limite de contexto. Isso traz algumas vantagens práticas: os cálculos determinísticos não se misturam ao raciocínio do LLM, uma parte que falhou pode ser executada novamente de forma independente, e a qualidade é verificada por função e por artefato específico.

Três fontes, três camadas de problemas

O sistema foi ampliado aos poucos, e cada fonte respondia a uma pergunta diferente.

• O Prometheus mostra onde algo mudou: taxa de falhas, latência e cumprimento dos SLAs por operação. A primeira versão, baseada em métricas e código, encontrou problemas em aproximadamente 1000 cadastros.
• O OpenSearch explica o que aconteceu exatamente: códigos HTTP, mensagens de erro e stack traces. Isso acrescentou cerca de 600 cadastros. Se a causa estiver em um serviço de outra equipe, o agente pode acessar o repositório dessa equipe, desde que tenha permissão; a relação é identificada pelas chamadas Feign.
• O Sentry trouxe uma nova classe de sinais: erros de frontend e velocidade de carregamento das páginas. Uma página sem erros, mas que leva um minuto para carregar, não funciona para o usuário, e a taxa de falhas do backend não revela esse problema.

Depois de cada rodada de correções, os resultados chegavam a um platô, até a conexão da próxima fonte. Os autores apresentam a conclusão com franqueza: o avanço vinha da ampliação da visibilidade, não da “inteligência” do modelo.

Limitações e o que fazer na prática

Não dá para calcular a taxa de falhas com uma única fórmula. Os códigos 500 e 401/403/422 têm semânticas diferentes, erros esperados, como uma sessão expirada, têm seu próprio nível aceitável, e algumas operações têm exceções específicas. A utilidade do agente depende diretamente da precisão com que a equipe descreveu as operações, os SLAs, a linha de base e o significado dos sinais. A AI não substitui o modelo de observabilidade: ela se apoia nele.

O próprio fluxo de diagnóstico se torna um sistema de produção e, por isso, também precisa de monitoramento: estabilidade das execuções, proporção de falsos positivos e utilidade dos relatórios. Analise também o caminho que levou o agente à conclusão. Um falso positivo indica que é preciso refinar o SLA ou a fórmula. Faltaram dados: aprimore a observabilidade ou a skill de coleta de contexto. Escolheu o repositório errado: melhore a skill de investigação de dependências. O relatório tem muito ruído: torne o contrato mais rigoroso.

Se quiser reproduzir a abordagem, não comece pelo agente. Primeiro, formalize o que conta como problema e com o que os sinais devem ser comparados; caso contrário, o LLM apenas reproduzirá sua indefinição. Defina o relatório final como um contrato: operação, gravidade, fatos, impacto, código, hipótese, nível de confiança e próxima ação.

A equipe planeja encurtar o caminho entre a hipótese e a correção: correções padronizadas e MR no lugar do rascunho no Jira. Mas, quanto mais perto o agente chega de alterar a produção, mais importantes se tornam a revisão humana, o controle de acesso e a reprodutibilidade. Por enquanto, o ganho vem de funções específicas, limites claros e uma pessoa no ponto de decisão, e não de um “engenheiro de AI” autônomo.