VLANs, GPO e servidor de email: o que aprendi mantendo infra real
Antes de escrever código profissionalmente, passei anos mantendo servidores, switches, VPNs e Linux rodando email corporativo. O que isso ensina que nenhum tutorial de dev cobre.
Segundo ano na Oi, fui designado para assumir um servidor de email Linux que estava com problema de entrega.
Emails saindo da empresa chegavam com atraso ou não chegavam. SPF mal configurado, relay aberto em algumas situações, fila do Postfix acumulando. O servidor existia havia anos — configurado por alguém que já não estava mais lá, documentação inexistente.
Passei uma semana dentro daquele servidor antes de entender o que estava errado. Nessa semana aprendi mais sobre como email funciona de verdade do que em qualquer coisa que li depois.
O que mantinha no dia a dia:
Switches e VLANs. Segmentação de rede não é conceito abstrato quando você configura na mão. VLAN 10 para administrativo, VLAN 20 para produção, VLAN 30 para visitantes — cada uma isolada, cada uma com suas políticas de roteamento. Aprendi que rede plana é risco: um dispositivo comprometido tem acesso a tudo.
VPNs. Escritórios regionais conectados à matriz via VPN site-to-site. Quando caia, o escritório ficava ilhado. Diagnosticar VPN é entender o caminho completo: túnel, autenticação, roteamento no outro lado. Não dá para debugar VPN sem entender o que está tentando acontecer.
Windows Server e GPO. Group Policy Object é uma das coisas mais poderosas e mais perigosas que existe em ambiente corporativo Windows. Uma GPO errada pode desabilitar acesso remoto em centenas de máquinas ao mesmo tempo. Aprendi na prática o que significa "testar antes de aplicar em produção" — porque produção aqui eram pessoas reais trabalhando.
Active Directory. Autenticação centralizada parece simples até quebrar. Quando o AD tem problema, nada funciona — login, email, VPN, acesso a arquivos. Entender dependency chain foi o que me ensinou a pensar em cascata de falhas.
SAML e SSO. Mais tarde, integração de sistemas externos com autenticação federada via SAML. Primeiro contato com o conceito de que identidade pode ser delegada — que um sistema pode confiar em outro para dizer "esse usuário é quem diz ser". Isso voltou anos depois quando fiz integração com Azure AD em projetos de software.
O que esses anos ensinaram que vejo falta em engenheiros de software:
Rede não é confiável por padrão. Dev que nunca configurou uma rede tende a escrever código que assume latência zero, pacotes que sempre chegam, DNS que sempre resolve. Rede real tem jitter, tem perda, tem timeout. Código que não trata isso quebra em produção de formas que são invisíveis em desenvolvimento.
Segmentação existe por razão. Quando vejo arquitetura onde todos os serviços podem falar com todos os outros serviços sem restrição, reconheço o problema: é rede plana. A mesma razão que VLANs existem em rede física existe em arquitetura de microsserviços — princípio de menor privilégio, blast radius controlado.
Logs não são monitoramento. No servidor de email, log me dizia o que aconteceu. Mas eu precisava saber o que estava acontecendo agora — fila crescendo, taxa de rejeição subindo, latência de entrega aumentando. São coisas diferentes. Aprendi a diferença antes de conhecer os termos formais.
Mudança em produção tem custo de reversão. GPO aplicada errada afeta imediatamente. Rollback é possível, mas tem janela — enquanto reverte, as pessoas estão bloqueadas. Isso me ensinou um instinto que carrego até hoje: antes de mudar qualquer coisa em prod, saber exatamente como desfazer.
Anos depois, numa revisão de arquitetura de plataforma, alguém perguntou por que eu insistia em network policy entre namespaces do Kubernetes quando "todos os serviços são nossos mesmo."
Expliquei com VLANs.
A intuição de que isolamento de rede não é paranoia — é design — veio de um switch Cisco num rack da Oi em 2014. O vocabulário mudou. O princípio ficou.
Essa semana: qual é a camada de infraestrutura do sistema que você opera que você nunca olhou por dentro?