O dia que derrubei a rede de um escritório inteiro
Uma mudança que parecia pequena. Um efeito cascata que eu não antecipei. E o que isso me ensinou sobre fazer mudanças em produção — antes de 'produção' ser uma palavra que eu usava.
Era uma mudança simples. Estava reorganizando as VLANs de um escritório — nada crítico, só limpeza de configuração que tinha acumulado.
Mudei um parâmetro no switch. Rede caiu. Não a VLAN que estava configurando — todas as VLANs. O escritório inteiro ficou sem acesso.
Trinta pessoas paradas. Eu com o terminal aberto tentando entender o que tinha feito.
O que aconteceu: o parâmetro que mudei afetava o trunk port — a porta do switch que carrega tráfego de todas as VLANs para o roteador. Eu tinha lido sobre trunk ports. Sabia o conceito. Mas não tinha mapeado que aquele parâmetro específico, naquele switch específico, afetava o trunk.
Efeito cascata que não antecipei porque não entendia completamente o que estava tocando.
Ficou restabelecido em 20 minutos. Mas foram 20 minutos longos.
O que fiz diferente depois disso:
Antes de mudar, entender o escopo completo. Não só "o que esse parâmetro faz" — mas "o que depende desse parâmetro." Dependency mapping antes de qualquer mudança. Isso levava mais tempo. Mas o tempo que gastava antes era menor que o tempo de recovery quando errava.
Mudança em horário de menor impacto. O escritório estava cheio porque era meio da tarde. Se tivesse esperado até depois do expediente, 30 pessoas não teriam parado de trabalhar. Janela de manutenção não é burocracia — é consideração pelo custo do downtime.
Ter plano de rollback antes de executar. Naquele dia, sabia como reverter — mas precisei pensar na hora, sob pressão, com pessoas esperando. Passei a escrever o rollback antes de executar a mudança. Não o conceito de rollback — o comando exato, testado, pronto para rodar.
Comunicar antes e depois. Não avisei o escritório que ia fazer manutenção. A mudança planejada que dá errado ainda é recuperável. A mudança não comunicada que dá errado é percebida como colapso inesperado.
Anos depois, quando comecei a trabalhar com plataforma de software, o mesmo padrão apareceu com outro nome.
Change management. Feature flags. Canary deploy. Blue-green. Progressive rollout.
São todas instâncias do mesmo princípio: mudança em sistema que pessoas dependem precisa ser feita de forma que o impacto seja controlado e o rollback seja possível.
A intuição de que "mudar em prod é diferente de mudar em dev" comecei a desenvolver num switch Cisco em 2014. A terminologia ficou para depois. O instinto ficou para sempre.
Essa semana: qual é a última mudança que você fez em produção sem ter o rollback escrito antes de executar?