Automação em ambientes de alto risco: quando a margem de erro é quase zero
Em 2009, a Netflix publicou o primeiro paper sobre Chaos Engineering: a ideia de injetar falhas deliberadas em sistemas de produção para encontrar fraquezas antes que as falhas reais as encontrem. A prática tornou-se influente na indústria de software e gerou uma onda de entusiasmo em equipes de operações de infraestrutura.
Alguns anos depois, um engenheiro de NOC em um ISP da América Latina com 80.000 assinantes leu sobre Chaos Engineering e se entusiasmou. Quis aplicar a filosofia às operações de rede. Propôs fazer exercícios de “queda controlada” para testar os mecanismos de redundância.
A proposta foi recusada. Não por resistência à mudança, mas porque o contexto era radicalmente diferente: na Netflix, uma falha afeta a reprodução de vídeos. Em um ISP, uma falha pode interromper o serviço de hospitais, sistemas de alarme e negócios que dependem de conectividade para faturar.
Esse é o ponto central: as filosofias de automação e resiliência que funcionam em ambientes de baixo risco não podem ser transferidas diretamente para redes ISP em produção. Precisam ser adaptadas, e essa adaptação exige mudanças em como se pensa a automação, não só em quais ferramentas se usam.
A assimetria do risco em redes ISP
Em software, a reversibilidade é alta. Um deploy de código que sai mal em geral pode ser revertido em minutos. O blast radius de um erro em um microsserviço costuma ser limitado a uma porcentagem de usuários, e com feature flags ou circuit breakers a contenção é rápida.
Em redes ISP, a assimetria é diferente:
Uma alteração de configuração mal aplicada pode interromper o serviço a milhares de usuários em segundos, e o rollback pode levar minutos que parecem horas.
Um erro em uma política de roteamento pode propagar rotas incorretas a peers de trânsito antes que a equipe detecte, gerando incidentes que envolvem terceiros fora do controle da organização.
A infraestrutura de rede é, em muitos casos, infraestrutura crítica de verdade: hospitais, serviços de emergência, empresas de logística e sistemas de pagamento dependem da conectividade que um ISP fornece.
Essa assimetria não significa que não se deva automatizar. Significa que a filosofia com que se desenham os sistemas de automação precisa refletir essa assimetria desde o princípio.
As filosofias que precisam de adaptação
“Move fast and break things”
Essa filosofia, popular em startups de software, é o oposto exato do que se precisa em redes ISP de produção. Mas a versão mais sofisticada da mesma ideia —“iterar rápido, falhar rápido, aprender rápido”— é aplicável, com um ajuste importante:
O “falhar rápido” em redes não pode ser em produção.
Em software, o ciclo de feedback pode ser a produção diretamente. Em redes ISP, o ciclo de feedback tem de ser:
- Lab que replica produção → falhar aqui, aprender aqui
- Janela de manutenção em horário de baixo impacto → validar em produção com risco controlado
- Rollout gradual com monitoramento ativo → expandir só se os primeiros segmentos forem bem-sucedidos
O ritmo de iteração na automação de redes pode ser rápido — mas as iterações em produção têm de ser de baixo impacto por desenho, não por sorte.
“Primeiro automatize, depois valide”
Em ambientes de baixo risco, a lógica de automatizar primeiro e validar depois tem certa racionalidade: lançar algo imperfeito e corrigir com base no feedback real.
Em redes ISP, essa lógica inverte a ordem correta. A automação de redes tem de ser validada antes de chegar à produção, não na produção.
Isso implica um nível de rigor em testes que não é habitual em projetos iniciais de automação de redes:
- Teste funcional em lab: o agente faz o que deve em condições normais
- Teste de condições limite: o que acontece quando o equipamento não responde, quando a sessão SSH cai no meio da mudança, quando a validação pós-mudança detecta um estado inesperado
- Teste de interoperabilidade: o agente funciona corretamente com todas as versões de firmware e todos os modelos de equipamentos que estão em produção
- Teste de rollback: o mecanismo de rollback efetivamente reverte a mudança nas condições em que é necessário
A tentação de pular etapas de teste porque “o lab não reflete exatamente a produção” é real. A resposta correta é melhorar o lab para refletir melhor a produção, não pular o teste.
“Confie no sistema, não nas pessoas”
Essa filosofia —própria da cultura SRE e DevOps— implica substituir processos que dependem da intervenção humana correta por sistemas que garantem resultados corretos independentemente do operador.
Em redes ISP, isso é correto em princípio, mas exige uma precaução: os sistemas de automação em redes ISP precisam de override humano claro e sempre disponível.
Um agente de automação de redes bem desenhado deve:
- Ter um mecanismo de pausa ou cancelamento que qualquer engenheiro possa acionar imediatamente
- Exigir aprovação humana explícita para mudanças de alto impacto (mudanças de política de roteamento, modificações de configuração de equipamentos de core)
- Gerar alertas que um operador humano veja antes de o agente concluir mudanças críticas
A automação reduz a dependência de intervenção humana para tarefas rotineiras. Não elimina o critério humano para decisões de alto impacto.
Os princípios que funcionam em alto risco
Princípio 1: Mudanças pequenas, frequentes e verificáveis
O maior fator de risco em uma mudança de rede não é a complexidade da operação em si — é o tamanho do delta entre o estado anterior e o posterior. Uma mudança que altera 80 parâmetros em 200 equipamentos simultaneamente é exponencialmente mais difícil de diagnosticar se algo der errado do que uma que altera 3 parâmetros em 10 equipamentos.
A automação de redes permite fazer mudanças pequenas e frequentes de forma eficiente. Aproveitar essa capacidade para reduzir o tamanho de cada mudança individual é uma estratégia de redução de risco, não de aumento de trabalho.
Princípio 2: Validação em múltiplos pontos da mudança
Uma mudança de rede bem desenhada tem validação em três momentos:
Pré-mudança: o estado da rede antes da mudança é o esperado. As condições para executar a mudança estão presentes. Não há incidentes ativos que afetem os equipamentos envolvidos.
Durante a mudança: o agente monitora indicadores de impacto enquanto aplica a configuração. Se os indicadores se deteriorarem acima de um limiar, o agente interrompe o rollout e aguarda confirmação.
Pós-mudança: o estado da rede após a mudança é o esperado. Os serviços afetados continuam funcionando corretamente. Não há novos incidentes gerados pela mudança.
Essa validação em três pontos converte a mudança de um ato de “aplicar e rezar” em um processo verificável com critérios objetivos de sucesso.
Princípio 3: Blast radius limitado por desenho
Todo sistema de automação de redes deve ter limites explícitos em quantos equipamentos pode afetar numa única execução, independentemente do que lhe peçam.
Esses limites não são configurações de usuário — são restrições do sistema:
# Límites hardcodeados en el agente de automatización
max_devices_per_run: 50
max_concurrent_changes: 5
max_percentage_of_fleet: 10
require_approval_above: 20
Se um operador quiser aplicar uma mudança a todos os 600 equipamentos, o sistema deve exigir que esse processo se execute em múltiplos ciclos com validação entre cada um, não numa única execução massiva.
Princípio 4: Observabilidade antes da automação
Não se pode automatizar de forma confiável o que não se pode observar. Antes de automatizar qualquer processo numa rede ISP de alto risco, a equipe deve ter visibilidade clara sobre:
- O estado das sessões de roteamento (BGP, IS-IS, OSPF) em tempo real
- Os indicadores de tráfego por enlace (utilização, drops, erros)
- Os logs de mudanças de configuração de todos os equipamentos
- Os eventos de protocolo relevantes (BGP state changes, interface flaps, convergência IGP)
Se uma mudança automatizada afeta negativamente algum desses indicadores, a equipe precisa saber em segundos, não em minutos. A latência de detecção em redes ISP é o fator crítico: incidentes que levam 10 minutos para ser detectados já têm impacto significativo nos usuários.
O perfil de equipe que pode operar automação de alto risco
A automação não reduz a necessidade de engenheiros com critério técnico profundo. A eleva.
Um sistema de automação de redes de alto risco precisa ser desenhado, mantido e operado por engenheiros que entendem profundamente os protocolos de rede que o sistema manipula. A automação não oculta a complexidade da rede — expõe de outra forma.
O perfil certo para esse trabalho combina:
- Conhecimento de redes: entender o que cada mudança de configuração faz de fato e quais são as implicações no plano de controle e de dados
- Critério de engenharia de software: desenhar sistemas que tratam erros corretamente, têm testes e são mantíveis
- Cultura de segurança operacional: intolerância a atalhos que reduzem a confiabilidade por conveniência
Esse perfil não é comum. É a razão pela qual a automação de redes em ISPs de alto risco se beneficia do trabalho com especialistas externos com experiência nesse domínio específico.
Como a Ayuda.LA pode ajudar
Na Ayuda.LA desenhamos e implementamos automação de redes para ISPs na América Latina com critérios de alto risco incorporados desde o desenho. Não acreditamos em automação a qualquer custo — acreditamos em automação que reduz o risco operacional em vez de aumentá-lo.
Se você está avaliando um projeto de automação de rede e quer garantir que seja adequado ao seu ambiente de produção, podemos fazer uma revisão de desenho antes de você avançar.
A automação que falha na produção não é melhor do que não ter automação. É pior: cria a ilusão de controle sem a realidade dele.