Como identificar gargalos na rede antes que o cliente perceba

Às 21h de toda quinta-feira, um bairro inteiro reclama que "a internet tá boa, mas trava no jogo online e trava no vídeo". Ninguém abre chamado de queda, porque a luz da ONU está acesa e o teste de velocidade às três da tarde deu resultado normal. O problema não é queda — é gargalo, e gargalo é traiçoeiro justamente porque não aparece como "sem conexão". Ele aparece como reclamação vaga, difícil de reproduzir fora do horário de pico, e é exatamente por isso que muito provedor só descobre onde está o estrangulamento da própria rede depois de meses ouvindo o mesmo tipo de queixa.

O que é gargalo, tecnicamente

Gargalo é qualquer ponto da rede onde a demanda momentânea de tráfego ultrapassa a capacidade disponível, criando fila, atraso (latência adicional) e, em casos mais graves, descarte de pacote. Diferente de uma queda, o serviço continua funcionando — só que pior, de forma inconsistente, geralmente concentrada em horários específicos. Isso torna o diagnóstico mais difícil que o de uma queda simples: não existe um "está fora do ar" binário para apontar, só uma degradação que varia ao longo do dia. Vale lembrar que degradação recorrente também pode aparecer nos indicadores de qualidade que a Anatel acompanha junto às prestadoras de SCM, então gargalo crônico não é só um problema de percepção do cliente — é algo que também pode virar questionamento regulatório se acontecer com frequência alta demais.

Onde gargalos costumam se esconder

Nem todo ponto da rede tem o mesmo risco de virar gargalo. Os mais comuns num provedor de médio porte são:

• Link de upstream com a operadora de trânsito: se a banda contratada não acompanha o crescimento da base, o link inteiro satura em horário de pico.
• CPU do concentrador PPPoE ou do BRAS: processamento no limite atrasa autenticação e reautenticação, mesmo com banda de sobra disponível.
• Porta de uplink de uma OLT específica: OLTs que cresceram muito em número de ONUs ativas podem ter a porta de uplink saturada mesmo com portas PON individuais tranquilas.
• Switch de agregação num POP regional: concentra tráfego de várias OLTs ou rádios antes de sair para o backbone, e é um ponto fácil de esquecer no monitoramento.
• Taxa de oversubscription mal calculada num splitter ou rádio PtMP: quando a proporção de clientes por capacidade compartilhada é otimista demais para o uso real da região.

Sinais que aparecem antes da reclamação virar volume

Antes de o telefone tocar em massa, geralmente já existem sinais no próprio dado da rede: latência que sobe de forma consistente num mesmo horário todos os dias, utilização de interface passando de 80-85% de forma repetida (não só em picos isolados), ou contagem de descarte de pacote (ifOutDiscards) crescendo mês a mês num ponto específico. Esses sinais raramente aparecem isolados — é o acúmulo deles no mesmo trecho da rede, ao longo de semanas, que indica gargalo estrutural em vez de anomalia pontual.

Como medir oversubscription de forma realista

1. Levante a capacidade nominal do trecho (banda do link, capacidade da porta, taxa do rádio).

2. Meça o uso real em horário de pico, não a média do dia — a média esconde o problema.

3. Calcule a proporção entre demanda de pico e capacidade disponível, não entre número de clientes e capacidade — dois clientes de streaming pesado consomem mais que vinte de uso leve.

4. Compare com a tendência das últimas semanas, não com um único dia — um pico isolado por evento (jogo, lançamento de app) não é o mesmo que uma saturação recorrente.

5. Priorize o trecho com tendência de piora, mesmo que hoje ainda não esteja crítico — resolver antes de virar reclamação é sempre mais barato que resolver depois.

SNMP, NetFlow e teste ativo: quando usar cada um

O monitoramento via SNMP mostra o estado das interfaces — utilização, erros, descartes — em intervalos regulares, e é a base de qualquer diagnóstico de capacidade. Já um coletor de NetFlow ou sFlow mostra o que está passando por dentro do link — quais IPs, quais protocolos, se o consumo é tráfego legítimo de cliente ou algo anômalo como um ataque de negação de serviço direcionado à rede. Teste ativo (ping continuado, medição de jitter) complementa mostrando o efeito prático na experiência do cliente, mesmo quando a interface ainda não está tecnicamente saturada. Provedores maduros combinam os três: SNMP para tendência, NetFlow para causa, teste ativo para validar impacto real.

O mito de que "aumentar banda sempre resolve"

Contratar mais banda de upstream é a resposta mais fácil e, em muitos casos, a errada. Se o gargalo real está na CPU de um concentrador PPPoE sobrecarregado ou na porta de uplink de uma OLT específica, aumentar o link de trânsito não muda nada — o estrangulamento continua no mesmo ponto interno da rede. Antes de comprar mais banda, vale confirmar onde exatamente a fila está se formando; às vezes o problema custa uma configuração ajustada ou um equipamento redistribuído, não um contrato mais caro com a operadora.

E se o gargalo só aparecer em horário de pico?

Essa é a situação mais comum e também a mais mal diagnosticada. Um trecho que roda tranquilo às 14h e trava às 20h não tem problema de capacidade instalada — tem problema de capacidade insuficiente para o pico específico daquele horário. Medir só durante o expediente comercial, quando a equipe técnica geralmente está de plantão, é o erro clássico que faz o gargalo passar despercebido nos relatórios internos enquanto o cliente sofre com ele todo santo dia às 20h. Vale coletar dado de utilização em janelas de 5 a 15 minutos ao longo das 24 horas, por pelo menos duas semanas, antes de concluir que um trecho está ou não dentro do limite aceitável — amostragem curta demais esconde exatamente o horário que mais importa.

Rede que avisa antes do estrangulamento virar chamado

Encontrar gargalo depende de dado histórico organizado, não de abrir gráfico manualmente todo dia esperando notar um padrão. O monitoramento SNMP do ZISP acompanha utilização de interface e sinais de sobrecarga continuamente, e quando um trecho específico começa a se aproximar do limite de forma recorrente, o sistema já aponta a anomalia — em vez de o provedor descobrir o gargalo pela reclamação repetida do mesmo bairro todo horário de pico. Veja como funciona em sistema.zisp.com.br.