Quando trocar a borda do provedor deixa de ser opcional

A borda quase nunca avisa que chegou no limite. Ela vai entregando, degradando devagar no horário de pico, e o time se acostuma a conviver com uma lentidão que ninguém consegue explicar direito.

Quando o problema fica óbvio, a troca deixou de ser projeto e virou emergência. E migração feita com pressa custa noite de operação e cancelamento.

O que é a borda e por que ela vira gargalo?

A borda é o ponto onde a rede do provedor conversa com o mundo, onde entra o trânsito contratado e onde ficam roteamento, NAT e as políticas de saída. Ela concentra tudo. Por isso qualquer limite dela aparece como lentidão geral, e não como problema de um bairro ou de um equipamento específico.

O gargalo raramente é largura de banda pura. Costuma ser quantidade de sessões simultâneas, capacidade de processar tabela de rotas, ou recurso que o equipamento simplesmente não implementa em hardware e passa a fazer em software.

Quais sinais indicam que a borda chegou no limite?

Cinco sinais, e nenhum deles precisa de ferramenta cara para ser observado:

1. O pico diário passa de 70% da capacidade da porta de saída de forma consistente.
2. A lentidão tem hora marcada e some de madrugada.
3. Recursos novos exigidos pela operação, como CGNAT com registro de portas ou IPv6, não rodam bem no equipamento atual.
4. Toda mudança de configuração vira evento de risco, porque não existe equipamento par para dividir a carga.
5. O crescimento previsto para os próximos 12 meses passa da capacidade atual em algum ponto.

O quinto é o único que permite decidir sem pressa. Os outros quatro já são o limite acontecendo.

CPU baixa e rede travando: o que isso costuma significar?

Significa que o gargalo não está no processamento geral, e sim em um recurso específico. Roteador de borda distribui trabalho entre núcleos e funções, então é comum ver a CPU total em 17% enquanto uma fila, uma interface ou o encaminhamento em software está saturado.

Esse é o caso que mais gera decisão errada. O painel mostra folga, o dono conclui que o equipamento aguenta, e o investimento vai para link novo que não resolve nada. Vale olhar consumo por núcleo, taxa de descarte por interface e o que está sendo processado fora do hardware.

Trocar o equipamento resolve sozinho?

Não. Equipamento define teto, projeto define desempenho. Já vi provedor migrar para plataforma de operadora, gastar o orçamento do ano e continuar com lentidão no pico, porque a configuração foi transposta como estava, com o mesmo desenho de roteamento e o mesmo dimensionamento de link.

Quando a lentidão continua depois da migração, o problema estava em uma destas três frentes desde o começo: desenho de roteamento, dimensionamento do trânsito contratado, ou política de tráfego mal ajustada. Nenhuma delas se corrige trocando a caixa.

Como decidir entre reforçar o que existe e migrar?

A pergunta certa não é qual equipamento é melhor. É quanto tempo de crescimento o cenário atual ainda comporta e o que ele impede de fazer hoje.

A ordem importa. Provedor que compra equipamento novo antes de resolver redundância troca um risco por outro.

O que preparar antes da janela de migração?

Três coisas, e a ausência de qualquer uma delas é motivo suficiente para adiar: topologia atual documentada, plano de rollback testado e comunicação combinada com o atendimento.

Migração sem rollback testado é a que gera as histórias de duas noites seguidas. O rollback precisa ter sido executado em ambiente de teste, não apenas escrito no documento. E o atendimento precisa saber o horário da janela antes do assinante ligar, porque a percepção de queda é sempre pior quando ninguém na empresa sabe responder o que está acontecendo.