Ricardo Brandão – Senior Software Engineer e Team Lead
Um dos maiores problemas e, francamente, a parte mais irritante da engenharia de software é coletar os dados necessários para investigar um defeito. Seja vasculhando rastreamentos do DataDog, lendo logs ou procurando em um banco de conhecimento (geralmente incompleto) por possíveis casos semelhantes no passado (o que normalmente envolve perguntar para o engenheiro que está há mais tempo na empresa). Um cálculo rápido de guardanapo sugere que pelo menos 50% do tempo necessário para corrigir um defeito é gasto coletando dados e depurando-o. E se pudéssemos automatizar isso?
Relatórios de SRE do Google sugerem que, em sistemas distribuídos complexos, até 70% do tempo de resolução de incidentes é gasto no diagnóstico e triagem, não na alteração de código em si. A taxa horária média para um engenheiro de software nos EUA é de cerca de US$ 45. Isso significa que um incidente/defeito que levou cerca de 4 horas para ser solucionado custou à empresa US$ 108 apenas em coleta de dados e custos de depuração. Depois, multiplique isso pelo número de incidentes e defeitos que uma empresa recebe mensalmente (uma SaaS de porte médio pode enfrentar cerca de 20–100 defeitos relatados por clientes por mês) e o custo chega a US$ 2.000 só para a coleta de dados. Acho que você já percebeu onde isso vai parar.
Então, vamos lá: estamos falando de uma empresa SaaS já estabelecida, com cerca de 45 engenheiros de software (um tamanho razoável, certo?). A equipe com a qual trabalhamos tinha 6 engenheiros full-stack – 2 seniors, 2 de nível médio e 2 juniores. Um stack padrão em Node.js rodando tudo na AWS, usando DataDog para monitoramento, Jira para o caos habitual de projetos e GitHub para gestão de código. Você sabe, aquele stack típico com o qual a maioria de nós está familiarizada.
Como qualquer empresa que já existe há algum tempo, eles acumularam… digamos “dívida técnica” (todos nós já passamos por isso). O sistema havia crescido organicamente até se tornar uma fera complexa, abrangendo mais de 10 repositórios e serviços. Nada incomum, mas definitivamente torna a depuração um pesadelo.
Mas aqui é que fica feio: só nos primeiros 4 meses de 2025, eles receberam mais de 300 defeitos relatados por clientes. Isso dá aproximadamente 75 defeitos por mês – bem acima da faixa típica de 20–100 que geralmente vemos. A equipe de engenharia estava basicamente se afogando, passando mais tempo jogando caça-fantasmas com bugs do que construindo novos recursos legais.
Quando nós, da Fornax, ouvimos sobre a situação deles, pensamos: “esse é exatamente o tipo de problema que podemos resolver com alguma automação inteligente”. Então decidimos encarar isso em estilo hackathon durante um sprint de 3 dias (trabalhando fora do nosso horário normal, porque por que não tornar tudo mais interessante?).
Como qualquer equipe de engenharia sob pressão, eles tentaram as manobras clássicas primeiro. Passo um: colocar mais gente no problema. Eles aumentaram a equipe de 4 para 6 engenheiros em dois meses, retirando desenvolvedores de trabalho de feature para lidar com o backlog de defeitos. Mas surpresa, surpresa – isso só criou mais troca de contexto e não resolveu realmente o problema central (que era o processo de investigação demorado).
Próximo passo: mudanças de processo. Eles implementaram todo um sistema de triagem em que engenheiros seniors investigavam previamente os defeitos antes de designá-los, além de terem criado modelos de defeito detalhados para capturar mais informações logo no início. Ajudou um pouco, mas agora os seniors estavam gastando 60% do tempo na triagem em vez de, você sabe, fazer coisas de engenheiro senior, como arquitetura e mentoria.
Eles também reforçaram a prevenção (o caminho responsável). A cobertura de testes foi de 65% para 85% em três meses, adicionaram requisitos mais rígidos de revisão de código, linting automatizado, varreduras de segurança – todo o pacote. Bons investimentos de longo prazo, mas os defeitos continuavam surgindo do código existente e daqueles adoráveis casos de borda que os testes simplesmente não conseguem capturar.
O ponto de ruptura? Eles perceberam que estavam fechando defeitos praticamente na mesma velocidade em que novos eram relatados. Apesar de todos os esforços, o tempo de investigação ainda era o gargalo. Cada defeito ainda exigia vasculhar rastreamentos do DataDog, correlacionar logs entre serviços e recorrer ao conhecimento tribal de quem já tinha visto algo semelhante antes (geralmente a pessoa que está na empresa há mais tempo e provavelmente já está sobrecarregada). A equipe estava entrando em burnout, e o desenvolvimento de features essencialmente havia parado.
Depois que um dos nossos engenheiros de software na Fornax defendeu o uso de ferramentas MCP personalizadas dentro do Cursor (IDE preferida do cliente), decidimos tentar automatizar a pesquisa dos defeitos que chegavam, particularmente aqueles que exigiam uma correção de dados no banco, especialmente após o defeito ser corrigido. Poderíamos executar uma instrução SQL genérica, mas com tantos cenários diferentes em que os dados poderiam estar (lógica de ledger não é simples, pessoal), a ideia era assustadora. Mas se conseguíssemos identificar um padrão que nos permitisse categorizar o problema e realizar a investigação, o engenheiro de software estaria livre para verificar rapidamente se tudo estava ok, fazer a correção e fechar o defeito!
Foi aqui que propusemos um “proof of concept”. Queríamos gerar embeddings de TODOS os defeitos e suas resoluções e criar um banco de conhecimento vetorizado onde pudéssemos realizar buscas semânticas com base nos sintomas que o usuário estava enfrentando.
Agora, indo ao que interessa, aqui estava o plano:
1 – Implementar um fluxo de trabalho em que, para cada defeito no Jira, coletaríamos todas as informações do DataDog sobre ele, comentários do Jira, PRs do GitHub e diffs de mudança, conversas relevantes no Teams e correções de dados DevOps que foram executadas. Todas essas informações seriam inseridas em um banco vetorial onde o embedding era um resumo gerado por LLM do problema, dos sintomas e da solução.
As integrações necessárias para isso foram feitas seguindo o padrão MCP para que pudéssemos reutilizá-las no Cursor também, o que foi um duplo benefício do trabalho!
Como estávamos fazendo esse trabalho fora do horário normal, como um POC, decidimos usar o OpenSearch hospedado na AWS (quase toda nossa infraestrutura estava na AWS). Optamos pela opção serverless porque não precisávamos de alta computação. A parte de catalogação era basicamente algo que se faz uma vez e pronto. Só em 2025 conseguimos catalogar cerca de 350 defeitos relatados por clientes e suas resoluções.
2 – Implementar um segundo fluxo de trabalho em que, ao criar um novo defeito no Jira, geraríamos o embedding dos sintomas e qualquer outra informação que tivéssemos sobre ele e realizaríamos uma busca pelos k-mais-próximos defeitos em nosso catálogo, mantendo apenas as correspondências mais altas. Isso nos deu uma base muito boa para alimentar outro LLM para comparar os sintomas e criar um resumo das possíveis causas e resoluções, incluindo mudanças de código, correções de dados e rastreamentos do DataDog para respaldar tudo.
Um truque particularmente inteligente que usamos para encontrar todos os rastreamentos relacionados no DataDog foi solicitar ao suporte que sempre gerasse um arquivo HAR (HTTP Archive) contendo todas as requisições, respostas, cabeçalhos, cookies e tempos da sessão do usuário, e só de analisar essas informações conseguimos encontrar facilmente todos os rastreamentos relacionados.
Por fim, com o resumo em mãos, adicionamos-o ao ticket do Jira como um comentário pronto para o próximo engenheiro de software verificar, fazer as alterações de código/correção de dados e fechar o defeito.
O segundo fluxo de trabalho que decidimos usar era uma Lambda acionada por um endpoint REST registrado no AWS API Gateway. O webhook do Jira o chamava com o ID do ticket e a Lambda fazia o resto. Cerca de 5 segundos depois, todas as informações eram buscadas e anexadas ao ticket do Jira.
3 – Precisávamos de uma forma de manter nosso banco de conhecimento de defeitos atualizado com os últimos defeitos encontrados e resolvidos. Para isso, chamávamos outro webhook do Jira ao mover um defeito para concluído. Esse webhook chamava outro endpoint do API Gateway que, por sua vez, acionava outra Lambda, mas desta vez adicionava uma entrada em um SQS que eventualmente começaria a processar aquele ticket do Jira da mesma maneira que o primeiro fluxo, exceto por aquele único defeito.
Optamos por um SQS em vez de simplesmente acionar uma Lambda, principalmente porque queríamos uma dead-letter queue caso algo desse errado ao catalogar o defeito. Não queríamos perder informações preciosas de defeito só porque alguma integração não funcionou direito.
Todo esse trabalho resultou em uma solução MUITO eficiente em termos de custo (bom, é nuvem, então foi o mais eficiente possível) sem computação desnecessária. Executa somente quando necessário.
Aquele custo de investigação de US$ 108 em mão de obra? Agora nos custa US$ 0,02, incluindo todos os embeddings, custos de LLM e computação. E o mais importante? Nossos engenheiros de software puderam gastar seu tempo corrigindo o problema em vez de apenas vasculhar logs e rastreamentos. Isso levou não só a resoluções mais rápidas de defeitos, mas também a maior satisfação da equipe e mais investimentos em novos recursos.
É certo que essa resposta mais rápida também se reflete nos nossos clientes. Correções de defeitos mais rápidas significam clientes satisfeitos!
Obviamente, isso não é completamente perfeito ainda. Temos otimizações que queremos realizar em termos de uma estratégia de chunking melhor para os embeddings, de modo a obter resultados ainda mais precisos. Também queremos estender esse banco de conhecimento para um chatbot para nossa equipe de suporte, para que ELES possam buscar uma solução antes mesmo de chegar até nós.
Para equipes que consideram fazer o mesmo, minha recomendação seria planejar com antecedência quais informações você adicionará ao banco de conhecimento. No nosso caso, como usamos OpenSearch, toda vez que queríamos adicionar novos metadados ao índice, precisávamos recriá-lo por causa das restrições de validação de esquema. Não foi grande coisa, já que era bem barato reconstruí-lo, mas em conjuntos de dados maiores definitivamente queremos evitar isso.
Acho que este caso realmente mostra para onde a indústria de engenharia de software está caminhando. Estamos vendo o surgimento do que gosto de chamar de “DevOps aumentado por IA” – onde o aprendizado de máquina não substitui os engenheiros, mas elimina o trabalho tedioso de investigação que nos impede de fazer o que realmente amamos: resolver problemas complexos e construir coisas legais.
Os números também confirmam isso. Segundo o State of DevOps Report de 2024, equipes que gastam mais de 30% do tempo em trabalho manual e repetitivo têm 2,5 vezes mais probabilidade de sofrer burnout (e, francamente, quem quer isso?). Nossa abordagem baseada em RAG lida diretamente com isso, automatizando a parte mais demorada da resolução de defeitos – todo aquele trabalho de investigação.
Olhando para frente, prevejo que fluxos de trabalho de desenvolvimento com conhecimento aumentado se tornarão prática padrão até 2027. Empresas que adotarem essas ferramentas de investigação alimentadas por IA mais cedo terão vantagens competitivas significativas: tempos de resolução mais rápidos, engenheiros mais felizes e a capacidade de reinvestir o tempo economizado em inovação em vez de apagar incêndios constantemente.
A conclusão? O futuro não é sobre a IA substituir desenvolvedores – é sobre a IA amplificar o que podemos fazer cuidando das tarefas repetitivas e pesadas de pesquisa que atualmente consomem 50–70% do nosso tempo de resposta a incidentes.
Quais desafios de investigação de defeitos estão consumindo o tempo da sua equipe? Você já experimentou RAG ou soluções de IA semelhantes no seu fluxo de trabalho de engenharia? Adoraríamos ouvir suas experiências nos comentários abaixo. Se você está se afogando em defeitos de clientes como nós estávamos, entre em contato conosco na Fornax – estamos ajudando equipes a implementar soluções semelhantes de automação. Compartilhe este post se você acha que sua rede pode se beneficiar de reduzir seus custos de investigação de US$ 108 para US$ 0,02!
PT 
EN