Gerenciar 600 dispositivos com equipe pequena: lições de padronização para ISPs
Quatro engenheiros. Seiscentos e vinte dispositivos de rede. Três províncias. Um NOC que opera 24/7 com plantões rotativos.
Este não é um caso hipotético. É o perfil operacional de vários ISPs regionais da América Latina com os quais trabalhamos na Ayuda.LA. E a pergunta que mais se repete quando descrevemos esse cenário é a mesma: como é possível com tão pouca gente?
A resposta não é que esses engenheiros trabalhem 80 horas semanais nem que sejam extraordinariamente capazes. A resposta é que a rede deles está padronizada de um modo que a maioria das redes de tamanho comparável não está.
O problema de escala que ninguém nomeia
Quando um ISP tem 50 dispositivos, a heterogeneidade é gerenciável. Um engenheiro sabe de memória qual versão de firmware cada roteador tem, por que aquele switch de distribuição na zona norte tem configuração diferente dos demais, e qual é o procedimento manual para provisionar um novo cliente em cada tipo de equipamento.
Quando essa rede cresce para 300 ou 600 dispositivos, essa heterogeneidade vira um problema operacional grave:
Cada equipamento vira um caso especial. Não há dois equipamentos configurados exatamente igual. Cada mudança exige revisar a configuração individual antes de executar qualquer coisa. O conhecimento está na cabeça das pessoas, não nos sistemas.
A resolução de incidentes escala mal. Um engenheiro que atende um incidente num equipamento conhecido pode resolvê-lo em 15 minutos. O mesmo incidente num equipamento com configuração não padrão pode levar 2 horas, porque o diagnóstico exige entender primeiro como aquele equipamento específico está configurado.
A automação é quase impossível. Escrever um script que funcione em 600 equipamentos com 40 variantes de configuração diferentes é um projeto em si, mais complexo do que gerenciar os equipamentos à mão.
A padronização não é um projeto de melhoria opcional. É a pré-condição para operar em escala com equipes pequenas.
Os cinco níveis de padronização
Nível 1: Padronização de fornecedores e modelos
O primeiro limite que um ISP em crescimento deve traçar é quantos fornecedores e modelos de hardware vai suportar simultaneamente. Cada fornecedor adicional multiplica a carga operativa:
- Um conjunto separado de expertise técnico para certificações e suporte
- Ferramentas de gestão diferentes (ou adaptações para que ferramentas genéricas funcionem com esse fornecedor)
- Estoque de peças para cada modelo
- Procedimentos de atualização de firmware separados
- Curva de aprendizado para cada novo integrante da equipe
A recomendação prática: definir uma arquitetura de “fornecedores escolhidos” (às vezes chamada “approved hardware list”) com não mais que dois fornecedores por função de rede (core, distribuição, acesso, CPE). Qualquer equipamento fora dessa lista é tratado como exceção e tem data de fim de vida planejada.
Isso não significa não ter equipamentos de múltiplos fornecedores — em redes legadas, isso é inevitável. Significa ter política ativa de redução de variedade, não de acumulação.
Nível 2: Padronização de versões de software
Dentro de cada fornecedor e modelo, a quantidade de versões de firmware/OS em produção simultânea deve ser mínima. O objetivo é ter todos os equipamentos do mesmo modelo na mesma versão (ou com diferença de um patch menor).
Por que importa: os bugs de firmware que geram comportamentos inesperados são frequentes em equipamentos de rede. Quando há 8 versões de firmware diferentes em produção, diagnosticar se um problema é de configuração ou de firmware exige verificar se o bug está presente naquela versão específica. Com uma ou duas versões ativas, esse diagnóstico é imediato.
Como implementar: criar um processo periódico de “padronização de versões” (semestral ou anual) em que se define a versão alvo para cada plataforma e se planeja o rollout de atualizações. O processo precisa incluir testes em lab antes da produção e um plano de rollback por equipamento.
Nível 3: Padronização de configurações (golden config)
Cada tipo de equipamento tem uma configuração base (golden config) que contém todas as políticas da organização: protocolos de roteamento habilitados, políticas de autenticação, configuração de logging, parâmetros de QoS, linhas de gerenciamento.
A configuração específica de cada equipamento (nome, IPs, interfaces conectadas) é gerada a partir dessa plantilla base mais os parâmetros variáveis daquele equipamento.
O benefício operativo imediato: quando se detecta um desvio da configuração padrão (por mudança manual não documentada, por incidente ou por drift acumulado), a equipe tem uma referência clara contra a qual comparar. A ferramenta de validação de compliance não precisa “entender” a rede — só precisa comparar.
Ferramentas: Ansible com templates Jinja2 é o padrão para gerar configurações a partir de plantillas. Nornir com o módulo de compliance pode detectar desvios automaticamente. Para armazenar configurações versionadas, Git é suficiente.
Nível 4: Padronização de naming e numeração
A forma como se nomeiam equipamentos, interfaces, prefixos e identificadores de circuitos impacta diretamente a velocidade de diagnóstico durante incidentes.
Um esquema de naming bem desenhado permite que um engenheiro que nunca viu aquele equipamento infira pelo nome: em que cidade está, que função cumpre (core/distribuição/acesso), a quais POPs está conectado e em qual cluster de alta disponibilidade participa.
Exemplo de esquema:
[ciudad]-[función]-[vendor]-[número]
bzb-core-hw-01 → Bariloche, core, Huawei, router 1
bzb-dist-ck-01 → Bariloche, distribución, Calix, switch 1
bzb-acc-tp-47 → Bariloche, acceso, TP-Link, OLT 47
O esquema deve ser documentado, exaustivo e aplicado retroativamente a todos os equipamentos novos desde o momento em que for definido. Equipamentos legados com naming inconsistente são migrados em ciclos.
Nível 5: Padronização de procedimentos operacionais
O último nível é o mais ignorado: os procedimentos para tarefas operacionais frequentes devem estar escritos, versionados e disponíveis para toda a equipe.
Isso inclui:
- Provisionamento de novos clientes (passo a passo, por tipo de serviço)
- Atualização de firmware (por fornecedor e modelo)
- Resposta a incidentes frequentes (queda de sessão BGP, interface down, perda de upstream)
- Procedimento de troca de equipamento por falha de hardware
Quando os procedimentos estão documentados, um engenheiro júnior pode executar operações complexas com supervisão mínima. O conhecimento crítico deixa de estar concentrado em uma ou duas pessoas.
A ferramenta que torna tudo isso possível: NetBox como fonte da verdade
Nenhum dos cinco níveis de padronização funciona sem uma fonte da verdade centralizada. O NetBox é hoje o padrão de fato em ISPs modernos para esse papel.
O NetBox armazena:
- Inventário de equipamentos (fornecedor, modelo, versão de firmware, localização)
- Numeração IP (prefixos, IPs atribuídas, IPs de gerenciamento)
- Topologia de rede (conexões entre equipamentos, circuitos, provedores)
- Dados de provisionamento (configurações, serviços ativos por equipamento)
Com NetBox bem populado, os scripts de automação consomem o inventário pela API em vez de arquivos estáticos. Quando um equipamento é substituído ou um IP muda, a atualização no NetBox se propaga automaticamente a todos os sistemas que consomem essa informação.
O requisito crítico: o NetBox deve ser a fonte da verdade, não um catálogo que alguém atualiza quando lembra. Isso exige processo disciplinado: nenhum equipamento se conecta à rede sem estar primeiro no NetBox, e nenhuma mudança de IP é aplicada sem atualizar antes no NetBox.
O resultado: operação em escala com equipe pequena
Um ISP que opera com esses cinco níveis de padronização implementados tem capacidades operacionais qualitativamente diferentes:
Diagnóstico de incidentes mais rápido. Um engenheiro pode entender o contexto de qualquer equipamento em segundos, sem necessidade de acesso prévio àquele equipamento específico.
Onboarding de novos engenheiros em dias, não meses. Um novo integrante pode começar a atender incidentes após uma semana de capacitação nos procedimentos documentados, sem precisar de anos de experiência acumulada naquela rede específica.
Automação efetiva. Com configurações padronizadas e inventário no NetBox, escrever um agente que opere sobre 600 equipamentos é trabalho de semanas, não meses.
Previsibilidade operativa. As mudanças de manutenção têm resultados previsíveis porque os equipamentos estão em estados conhecidos. Os incidentes têm durações previsíveis porque os procedimentos de resolução são conhecidos.
A escala não se resolve com mais pessoas — resolve-se com menos variedade.
Por onde começar
Se sua rede tem mais variedade do que sua equipe consegue gerir confortavelmente, o caminho de padronização começa com duas ações:
-
Auditoria do inventário real. Antes de padronizar, você precisa saber exatamente o que tem: quantos fornecedores, quantos modelos, quantas versões de firmware, quantos esquemas de naming distintos. Essa auditoria costuma revelar que a situação é mais complexa do que se pensava.
-
Definição do estado alvo. Quais fornecedores, modelos, versões e esquema de naming você quer ter em 18 meses. Sem estado alvo claro, a padronização vira uma série de decisões ad hoc que não convergem.
Na Ayuda.LA fazemos essas auditorias e definimos planos de padronização para ISPs na América Latina. O resultado não é um documento — é uma folha de rota executável com impacto mensurável na carga operativa da equipe.
A padronização não é uma restrição à flexibilidade operacional. É a condição que torna a escala possível.