Por Que um Único Link de Internet é um Risco Operacional
Durante muitos anos, a internet corporativa foi tratada como um item de infraestrutura secundário — algo que "já vem com o escritório", contratado pelo menor preço e revisado apenas quando alguém reclama de lentidão. Essa lógica ficou obsoleta. Hoje, o ERP roda em nuvem, o telefone é VoIP, o e-mail está no Microsoft 365, o backup replica para um data center externo, o time de vendas depende do CRM e o financeiro emite nota fiscal por webservice da prefeitura. Quando o link cai, não é "a internet" que para: é a empresa inteira.
O cálculo do prejuízo costuma surpreender os gestores. Uma empresa com 40 colaboradores e custo médio de R$ 45 por hora trabalhada perde cerca de R$ 1.800 por hora de indisponibilidade apenas em produtividade parada — sem contar vendas não fechadas, pedidos não faturados, chamados de clientes não atendidos e o desgaste de imagem. Uma única queda de quatro horas custa mais do que um ano inteiro do segundo link que teria evitado o problema.
E quedas acontecem com frequência maior do que o marketing das operadoras sugere. Rompimento de fibra por obra na via pública, falha em equipamento de borda da operadora, manutenção programada que extrapola a janela, problema de energia no armário de rua, roteamento instável, ataque em infraestrutura do provedor. Nenhum contrato de SLA impede o rompimento — ele apenas define em quanto tempo a operadora promete restabelecer e quanto desconta na fatura. Um SLA de "restabelecimento em 8 horas úteis" significa, na prática, que sua empresa pode ficar um dia inteiro offline dentro do contrato.
Contratar SLA não é o mesmo que ter disponibilidade. SLA é uma promessa de reparo com multa contratual; redundância é a garantia de que a operação continua enquanto o reparo acontece.
Como Funciona o Failover: da Detecção à Comutação
Failover é o mecanismo que transfere automaticamente o tráfego de um link primário para um link secundário quando o primeiro apresenta falha. Parece simples, mas a qualidade de uma solução de redundância está justamente nos detalhes de como a falha é detectada e em quanto tempo a comutação ocorre.
O erro mais comum em implementações amadoras é monitorar apenas o estado físico da interface. Se o roteador considera o link "ativo" só porque a porta ethernet está conectada, ele nunca detectará o cenário mais frequente na prática: o modem da operadora continua ligado e negociando, mas não há tráfego real chegando à internet. O link está "no ar" para o equipamento e completamente inútil para o usuário. É o clássico "está tudo verde no painel e ninguém consegue acessar nada".
Uma detecção correta funciona em camadas sobrepostas:
- Camada física — a interface está conectada e negociando velocidade?
- Camada de rede — o gateway da operadora responde?
- Camada de alcance real — destinos externos e independentes respondem? O padrão de mercado é fazer probing contínuo contra múltiplos alvos públicos (resolvedores DNS distintos, por exemplo), exigindo falha simultânea em vários deles antes de declarar o link inoperante.
- Camada de qualidade — mesmo respondendo, o link está com perda de pacotes acima de um limiar ou latência degradada? Um link com 30% de perda derruba VoIP e trava sessões de terminal, mesmo "funcionando".
O tempo de comutação também precisa ser dimensionado com critério. Um failover agressivo demais provoca flapping: o link oscila, o roteador troca a rota, derruba as sessões estabelecidas, volta, derruba de novo. Um failover conservador demais deixa a empresa dez minutos fora do ar antes de reagir. Na prática, uma configuração equilibrada usa verificação a cada 1–2 segundos, com confirmação após 3 a 5 falhas consecutivas e um período de estabilização (hold time) antes de retornar ao link primário quando ele volta.
Escolhendo os Dois Links: Diversidade é o que Importa
Contratar dois links não garante redundância. Se ambos forem da mesma operadora, passarem pelo mesmo poste, entrarem pelo mesmo duto e terminarem no mesmo armário de rua, uma única retroescavadeira derruba os dois ao mesmo tempo. Você terá pago o dobro por um ponto único de falha com aparência de redundância.
A regra de ouro é maximizar a diversidade em três dimensões:
- Operadora distinta — evita que uma falha de backbone, roteamento ou manutenção do provedor afete os dois links.
- Meio físico distinto — fibra óptica no primário e rádio, cabo metálico ou 4G/5G no secundário. Meios diferentes falham por causas diferentes.
- Rota de entrada distinta — sempre que possível, cabos entrando por lados opostos do prédio. Em condomínios empresariais isso nem sempre é viável, mas vale a pergunta ao provedor.
Sobre o dimensionamento do link secundário: ele não precisa ser idêntico ao primário, mas precisa sustentar a operação essencial. Faça o exercício de listar o que não pode parar — telefonia VoIP, ERP, e-mail, emissão fiscal — e calcule a banda mínima. Um backup de 100 Mbps para um primário de 500 Mbps costuma ser suficiente se o consumo do primário for majoritariamente tráfego não-crítico (streaming, downloads, atualizações). Já um link 4G de contingência com franquia de 20 GB pode esgotar em poucas horas de operação plena — leia a política de franquia antes de contar com ele.
Um ponto frequentemente esquecido: o IP muda no failover. Se sua empresa publica serviços para acesso externo (VPN, servidor de terminal, câmeras, webserver), a comutação quebra o acesso remoto, a menos que você planeje isso. As soluções são DNS dinâmico com TTL baixo, registro DNS com múltiplos apontamentos, VPN configurada com endpoints redundantes ou, em cenários maiores, IPs próprios anunciados por BGP com as duas operadoras.
Balanceamento de Carga: Quando Faz Sentido e Quando Atrapalha
Balanceamento é diferente de failover. No failover, o link secundário fica ocioso esperando a falha. No balanceamento, os dois links trabalham simultaneamente, distribuindo as conexões — o que aproveita o investimento e aumenta a banda agregada disponível.
A distinção crítica é que balanceamento distribui conexões, não a velocidade de um download individual. Dois links de 200 Mbps balanceados não entregam 400 Mbps para um único arquivo; entregam 200 Mbps para cada conexão, com o conjunto de usuários dividido entre os caminhos. Explicar isso ao cliente antes da implantação evita frustração no dia seguinte.
Os métodos mais usados em ambientes corporativos:
- Per-connection (PCC / hash de origem-destino) — cada sessão fica presa a um link do início ao fim. É o método mais seguro, porque evita quebrar sessões HTTPS, bancárias e sistemas que validam consistência de IP de origem.
- Por peso — distribui proporcionalmente à capacidade de cada link. Útil quando os links têm velocidades muito diferentes (ex.: 500 Mbps e 100 Mbps).
- Policy-based routing — decide o caminho por tipo de tráfego. Uma prática eficaz é fixar VoIP e ERP no link mais estável e direcionar navegação geral, atualizações e streaming para o outro.
Quando o balanceamento atrapalha: sistemas bancários, portais governamentais, alguns webservices fiscais e sessões de aplicações legadas podem derrubar a conexão ao detectar mudança de IP de origem no meio da sessão. Nesses casos, a solução é criar regras explícitas fixando esse tráfego em um único link — não abandonar o balanceamento inteiro.
Erros Comuns e Como Testar a Redundância de Verdade
A falha mais cara em projetos de redundância não é técnica, é de processo: montar a solução, nunca testar e descobrir que ela não funciona exatamente no dia da queda. Redundância não testada é redundância presumida.
Erros recorrentes que encontramos em auditorias de rede:
- Ponto único de falha no próprio equipamento — dois links entrando em um roteador só. Se o roteador queima ou trava, os dois links viram enfeite. Ambientes críticos exigem redundância também no gateway (VRRP/HSRP com dois equipamentos).
- Nobreak dimensionado só para os servidores — o rack tem autonomia, mas o modem da operadora está numa tomada comum na recepção. Queda de energia derruba o link mesmo com o roteador ligado.
- Link de backup nunca usado — fica meses ocioso e, quando é acionado, descobre-se que o contrato foi cancelado por falta de tráfego, o IP mudou ou o equipamento da operadora está desligado.
- DNS interno apontando para o gateway antigo — o failover ocorre na camada de roteamento, mas a resolução de nomes continua tentando o caminho morto.
- Ausência de monitoramento e alerta — o failover funciona tão bem que ninguém percebe que o link primário caiu. Semanas depois, o secundário também cai e aí sim a empresa para — sem nenhum link disponível.
O teste correto é simples e deve ser rotina trimestral: desconecte fisicamente o cabo do link primário, em horário de operação real, e cronometre. Verifique quanto tempo levou a comutação, se a chamada VoIP em andamento caiu, se o ERP reconectou sozinho, se o acesso remoto externo continuou funcionando e se o alerta chegou a quem deveria. Depois reconecte e observe o retorno — o failback costuma esconder tantos problemas quanto o failover.
Se você não sabe em quantos segundos sua rede comuta para o link secundário, você não tem redundância. Tem esperança.
Como a Duk Estrutura Alta Disponibilidade de Conectividade
Projetar redundância de internet vai muito além de contratar um segundo link. Envolve mapear a criticidade de cada aplicação, dimensionar a banda mínima de contingência, escolher operadoras com rotas físicas realmente distintas, configurar detecção de falha em múltiplas camadas, definir políticas de roteamento por tipo de tráfego, garantir energia protegida para todos os elementos do caminho e — o mais importante — monitorar e testar continuamente.
Com mais de 18 anos de mercado e 550+ empresas atendidas, a Duk Informática & Cloud implanta e gerencia arquiteturas de conectividade redundante em ambientes que não podem parar: indústrias, clínicas, escritórios de contabilidade, comércio e operações com filiais interligadas. Somos Microsoft Gold Partner e operamos data center próprio em Alphaville, o que nos permite integrar conectividade, backup e continuidade em um único projeto — com monitoramento 24/7 e SLA contratual, incluindo alerta proativo quando um dos links cai, mesmo que o failover tenha funcionado e ninguém na empresa tenha notado.
Se sua empresa hoje depende de um único link, ou se tem dois links mas nunca testou a comutação, o próximo passo é um diagnóstico de disponibilidade: levantamento dos pontos únicos de falha, cálculo do custo real de indisponibilidade e desenho da arquitetura adequada ao seu porte e orçamento. Fale com a Duk e descubra onde sua operação está exposta antes que a retroescavadeira descubra por você.
Quer proteger e otimizar a TI da sua empresa?
Agende um diagnostico gratuito com nossos especialistas certificados.
Falar com Especialista