Da prova de conceito à produção: como construir um agente de automação de rede que não falhe
O cenário se repete com frequência em equipes de redes: um engenheiro motivado monta um laboratório, constrói um agente de automação com Python e Ansible, executa mudanças em equipamentos de teste, e o sistema funciona impecavelmente. A equipe aprova o PoC. Decide-se levar o agente à produção.
Três semanas depois, o agente está pausado. Causou um incidente menor ao assumir um estado da rede que já não era verdadeiro. A equipe voltou às mudanças manuais “por segurança”.
Esse padrão não é fracasso da ferramenta nem do engenheiro. É resultado de não ter desenhado o agente para as condições reais de produção desde o princípio. A diferença entre um PoC que funciona num lab e um agente que opera em produção sem falhar não está na lógica do script — está em como o sistema trata incerteza, erros e estados inesperados.
Por que o PoC funciona e a produção não
Um laboratório de automação de redes tem condições que raramente ocorrem em produção:
Estado conhecido e controlado. No lab, o engenheiro sabe exatamente o estado de cada equipamento antes de executar o agente. Em produção, isso nem sempre é verdade. Um equipamento pode estar no meio de uma atualização de firmware, ter uma sessão SSH aberta por outro operador, ou ter configuração modificada manualmente horas antes sem atualizar a fonte da verdade.
Topologia estável. No lab não há incidentes ativos, interfaces caídas por manutenção de terceiros ou segmentos de rede com latência elevada que fazem os timeouts de conexão falharem aleatoriamente.
Sem efeitos colaterais. No lab, se algo der errado, reinicia-se o equipamento virtual e começa de novo. Em produção, um comando executado pela metade pode deixar um equipamento num estado inconsistente difícil de diagnosticar.
Um só operador. No lab, só o agente toca os equipamentos. Em produção, há engenheiros que fazem mudanças manuais, scripts de monitoramento que abrem sessões e sistemas de backup que competem pelo acesso.
O PoC não falha por ser mal desenhado. Falha porque foi desenhado para as condições do lab, não para as condições de produção.
Os quatro problemas que matam agentes em produção
1. Ausência de pré-validação do estado
O erro mais comum: o agente assume que o estado da rede é o que deveria ser segundo a fonte da verdade (NetBox, arquivo YAML, base de dados), sem verificar antes de executar.
O problema: A fonte da verdade tem deriva. Um equipamento que segundo o NetBox tem sessão BGP ativa pode tê-la caída por manutenção não registrada. Se o agente faz mudanças assumindo que essa sessão está ativa, pode causar um corte.
A solução: Toda operação do agente deve começar com fase de pré-validação que leia o estado atual do equipamento e o compare ao estado esperado. Se houver discrepância, o agente deve parar e alertar — nunca continuar às cegas.
def pre_validate(device, expected_state):
current_state = get_device_state(device)
discrepancies = compare_states(current_state, expected_state)
if discrepancies:
raise PreValidationError(
f"Estado inesperado en {device}: {discrepancies}. Operación abortada."
)
return True
2. Falta de idempotência
Um agente idempotente pode executar-se múltiplas vezes e produzir o mesmo resultado. Um agente não idempotente pode causar problemas se executado duas vezes —por retry automático, operador que dispara manualmente ou falha no meio do caminho.
O problema: Se o agente adiciona uma entrada a uma ACL e executa duas vezes, adiciona a mesma entrada duas vezes. Dependendo do fornecedor, isso pode ser inofensivo ou causar comportamento inesperado.
A solução: Antes de aplicar qualquer mudança, verificar se o estado desejado já existe. Se já existe, não aplicar a mudança. Esse padrão —“verificar antes de mudar”— é a base da idempotência em automação de rede.
Ferramentas como Ansible têm idempotência incorporada nos módulos de rede. Se você escreve scripts Python com Netmiko, a idempotência é sua responsabilidade explícita.
3. Ausência de rollback automatizado
Toda mudança em produção deve ter rollback executável em segundos, não em minutos. Em automação, o rollback manual não escala: se o agente aplicou mudanças em 50 equipamentos e algo deu errado, não dá para fazer rollback manual em 50 equipamentos a tempo.
O problema: Agentes de PoC tipicamente não implementam rollback. O engenheiro que construiu assumiu que, se algo falhasse, alguém reverteria manualmente.
A solução: Antes de aplicar qualquer mudança, capturar o estado atual da configuração do equipamento (ou do fragmento que será modificado). Se a validação pós-mudança falhar, o agente deve reverter automaticamente a esse estado capturado.
def apply_with_rollback(device, change):
snapshot = capture_config_snapshot(device)
try:
apply_change(device, change)
if not post_validate(device, change.expected_state):
raise PostValidationError("Validación post-cambio fallida")
except Exception as e:
logger.error(f"Falla en {device}, iniciando rollback: {e}")
restore_snapshot(device, snapshot)
raise
4. Tratamento deficiente de erros parciais
Um agente que aplica mudanças em múltiplos equipamentos sequencialmente ou em paralelo pode falhar no meio do caminho. Se os primeiros 20 equipamentos receberam a mudança e os últimos 30 não, a rede fica num estado inconsistente.
O problema: O agente de PoC termina abruptamente ao encontrar um erro e deixa o trabalho pela metade. Não há notificação clara de quantos equipamentos foram modificados e quantos não.
A solução: Definir explicitamente o comportamento ante falhas parciais antes de escrever o agente:
- Fail fast: ante o primeiro erro, parar tudo e fazer rollback das mudanças já aplicadas. Adequado para mudanças interdependentes.
- Fail slow: continuar com os equipamentos restantes, registrar os erros e reportar o resultado completo no final. Adequado para mudanças independentes entre equipamentos.
- Limiar de falha: continuar enquanto a porcentagem de falhas estiver abaixo de um limiar configurado (por exemplo, abortar se mais de 10% dos equipamentos falhar).
O modelo de agente que de fato funciona em produção
Um agente de automação de rede pronto para produção tem esta estrutura:
1. INVENTARIO → Obtener lista de equipos desde la fuente de verdad
2. PRE-VALIDACIÓN → Verificar estado actual de cada equipo
3. SNAPSHOT → Capturar configuración actual antes de cambiar
4. EJECUCIÓN → Aplicar cambios con manejo de errores y límites de concurrencia
5. POST-VALIDACIÓN → Verificar que el estado post-cambio es el esperado
6. ROLLBACK → Revertir automáticamente si la validación falla
7. REPORTE → Registrar resultado detallado por equipo y notificar
Cada fase é explícita, testável de forma independente e tem comportamento definido ante falhas.
Levar o agente à produção: o plano de implantação
O rollout de um agente de automação à produção deve ser gradual:
Semana 1 — Somente leitura. O agente roda contra equipamentos de produção mas só em modo leitura. Pré-valida, gera snapshots, verifica o estado e reporta — sem aplicar mudanças. Isso valida que o agente consegue conectar a todos os equipamentos e que a pré-validação funciona contra o estado real da rede.
Semanas 2-3 — Um segmento de baixo risco. O agente aplica mudanças num conjunto pequeno de equipamentos (5-10) de menor criticidade, com um engenheiro monitorando a execução em tempo real.
Semana 4 em diante — Expansão gradual. Aumentar o alcance do agente conforme os resultados. Estabelecer métricas de sucesso claras: taxa de falhas, tempo de execução, quantidade de rollbacks acionados.
De ferramenta a infraestrutura
Um agente de automação que passa à produção deixa de ser ferramenta de um engenheiro e torna-se infraestrutura operativa. Isso implica que precisa de:
- Versionamento e revisão de código. Todas as mudanças no agente passam por pull request e revisão, como código de software.
- Testes automatizados. Uma suíte de testes que valida que o agente funciona corretamente antes de cada implantação.
- Monitoramento e alertas. O próprio agente é monitorado: execuções ficam registradas, falhas geram alertas e o desempenho é medido no tempo.
- Documentação operativa. O agente tem runbook que qualquer membro da equipe pode seguir para operá-lo, diagnosticar falhas e executar rollbacks manuais se necessário.
A automação de redes não falha porque a tecnologia seja ruim. Falha quando é tratada como script de uso pessoal em vez de infraestrutura de produção.
Como a Ayuda.LA pode ajudar
Na Ayuda.LA desenhamos e implementamos agentes de automação de rede para ISPs e empresas enterprise na América Latina que funcionam em produção desde o primeiro dia. Não entregamos PoCs — entregamos sistemas operacionais com validação, rollback e monitoramento incorporados.
Se você tem um projeto de automação parado porque o PoC não escala, ou quer construir automação de rede desde o princípio com critérios de produção, vamos conversar.
A diferença entre um PoC e um sistema de produção não é quanto código tem — é quantas formas de falhar foram consideradas.