## Sistema lento: como descobrir o que está travando a operação

technical-article · 2026-10-16 · Bleu · 6 min · pt-BR

> Como investigamos a lentidão de uma aplicação, encontramos a causa e acompanhamos o que aconteceu depois da correção.


Baseado na apresentação de Juliano Quatrin Nunes no Bleu Bytes.

Você abre uma tela para trabalhar e espera, atualiza a página, tenta de novo e pergunta se mais alguém está com o mesmo problema. A equipe responsável pelo sistema começa a investigar, mas ainda não consegue explicar por que isso está acontecendo.

Para um founder ou gestor, a dificuldade é decidir o próximo passo enquanto o trabalho continua parado (e, se não trabalha com uma empresa como a Bleu, a dificuldade é também esperar resposta do cara de TI que nunca responde, rs).

Pode ser necessário aumentar a capacidade do servidor, corrigir uma funcionalidade ou rever uma atualização recente, mas cada hipótese leva a um tipo diferente de trabalho e investimento. Precisamos saber o que sustenta essa decisão.

# Uma falha no carregamento das páginas

Passamos por isso em um projeto para uma consultoria do setor de mineração. Estávamos substituindo um sistema antigo que usava uma tecnologia sem suporte adequado, e o novo sistema trouxe funcionalidades para o que antes era trabalho manual (como buscar informações em órgãos reguladores e lançar prazos internos).

Em um determinado dia, algumas páginas não estavam carregando e o time interno começou a relatar dificuldades para usar a aplicação. Já conhecíamos as páginas mais importantes para a rotina, especialmente as de processos e alertas, e usamos os painéis para investigar o que estava acontecendo naquele momento.

Os dados ajudaram a localizar a falha e resolvemos o problema rapidamente. Depois da correção, continuamos acompanhando a aplicação para conferir se as páginas voltavam a carregar e se ainda havia usuários afetados.

# Como saber por que um sistema está lento

Uma reclamação de lentidão descreve o que a pessoa está vendo na tela, mas ainda deixa várias causas em aberto. Para investigar, precisamos acompanhar quanto tempo as operações levam, quantas vezes são executadas e o que aconteceu no período em que houve o problema.

Essa capacidade é chamada de observabilidade. Ela permite entender o comportamento de um sistema pelos dados que ele produz, conforme a definição do [OpenTelemetry](https://opentelemetry.io/pt/docs/concepts/observability-primer/).

No projeto, organizamos essas informações em painéis e passamos a comparar os momentos de lentidão com o funcionamento habitual da aplicação. Conseguimos verificar se uma operação estava demorando mais, se estava sendo executada com uma frequência diferente ou se alguma etapa concentrava boa parte do tempo de resposta.

Isso nos deu uma forma de conferir as hipóteses antes de escolher o que mudar.

# O que encontramos durante o incidente

Ao consultar o painel, encontramos um aumento no tempo de resposta, mas foi o volume de chamadas que direcionou a investigação, que precisava ser rápida e efetiva: os prazos de mais de 40 mil processos dependiam daquele fluxo.

Em períodos normais, as operações mais acessadas recebiam cerca de 40 a 50 chamadas a cada cinco minutos. Durante o incidente, uma única operação chegou a aproximadamente 3 mil chamadas no mesmo intervalo.

Ao analisar os registros e o código, encontramos uma falha na tela: em determinadas condições, ela fazia um pedido ao servidor e repetia esse pedido enquanto esperava terminar de carregar. O ciclo gerava novas chamadas e dificultava o próprio carregamento, mantendo o comportamento que provocava a sobrecarga.

Corrigimos o código e continuamos acompanhando o painel. Depois da publicação, porém, apareceram novos picos porque algumas pessoas ainda estavam com a versão anterior aberta no navegador e continuavam gerando chamadas repetidas.

Foi necessário orientar esses usuários a recarregar a aplicação e adicionar um limite para conter o excesso de solicitações. Essa proteção conteve a sobrecarga provocada pelas versões antigas, enquanto os dados nos permitiram acompanhar o efeito da correção e das chamadas que ainda chegavam.

# O que um founder pode pedir à equipe responsável pelo sistema

Não é necessário conhecer a arquitetura da aplicação para acompanhar uma investigação, mas sim entender como a equipe chegou à causa apontada e o que vai continuar acompanhando depois da correção. Essas perguntas ajudam a tornar a conversa mais concreta:

| Pergunta | O que a resposta ajuda a entender |
|---|---|
| Quais tarefas estão sendo afetadas? | Onde a lentidão está atrapalhando o trabalho |
| O que mudou em relação ao funcionamento habitual? | Quais hipóteses têm apoio nos dados e merecem ser investigadas primeiro |
| Que evidência sustenta a causa apontada? | Como a equipe relacionou o problema observado à mudança proposta |
| Como vamos verificar se a correção funcionou? | Que dados serão acompanhados e quais tarefas serão conferidas com os usuários |
| Quem ainda pode estar enfrentando o problema? | Se há sessões antigas ou outras situações que precisam de atenção |

Começar com hipóteses faz parte da investigação. Neste projeto, tínhamos dúvidas sobre a infraestrutura, a comunicação entre partes da aplicação e o código, mas só conseguimos avançar quando passamos a conferir essas possibilidades com os dados do sistema.

O mesmo vale para a correção. Se tivéssemos encerrado o acompanhamento logo depois da publicação, as sessões com a versão anterior continuariam provocando o problema sem que tivéssemos entendido por quê.

# Um sistema com poucos usuários pode ser essencial para a operação

O sistema da consultoria era usado por poucas pessoas para acompanhar milhares de processos, e a lentidão atrapalhava quem dependia dele para controlar todos os prazos.

Isso precisa entrar na avaliação de desempenho. Uma ferramenta usada durante boa parte do expediente pode atrasar a rotina inteira, mesmo que tenha um público pequeno, e as tarefas mais importantes para essas pessoas devem orientar o que vamos medir e investigar.

Depois do incidente, usamos os mesmos dados para examinar consultas ao banco e fazer outros ajustes. Conseguimos ver quais etapas demoravam mais e avaliar onde uma mudança no código poderia melhorar o tempo de resposta.

A modernização precisava ser avaliada também por esse uso cotidiano. As novas funcionalidades faziam parte da entrega, assim como entender por que uma página demorava e acompanhar se as mudanças melhoraram o trabalho de quem dependia dela.

# Perguntas frequentes

## Um sistema lento precisa de um servidor maior?

Depende da causa. Mais capacidade pode ser necessária quando os recursos disponíveis não atendem à demanda, mas é preciso conferir o que está provocando essa demanda. No caso apresentado, encontramos uma falha que repetia chamadas ao servidor e precisávamos corrigir esse comportamento.

## O que é observabilidade?

É conseguir entender o que acontece dentro de um sistema: onde ele fica lento, por que uma falha ocorreu e como isso afeta quem usa. Com esses dados, a equipe consegue identificar a causa dos problemas e acompanhar se os ajustes resolveram.

## Como saber se uma correção resolveu o problema?

Acompanhe os dados depois da mudança, usando os mesmos critérios de medição, e confira as tarefas com os usuários. Neste caso, essa verificação mostrou que algumas pessoas ainda estavam com a versão anterior aberta e continuavam gerando chamadas repetidas.

## Uma aplicação com poucos usuários precisa desse acompanhamento?

Vale considerar quanto trabalho depende dela. Uma aplicação usada por poucas pessoas pode ser necessária para acompanhar milhares de processos ou cumprir prazos, e as informações coletadas devem ajudar a investigar os problemas que afetam essas tarefas.


Themes: observabilidade · desempenho · modernização