Hardware é software: o que trocar placa de rede em produção ensina sobre sistemas
Substituir hardware em servidor em produção parece diferente de fazer deploy de código. Os princípios são os mesmos — e aprendi isso da forma mais tensa possível.
O servidor de email estava com erros intermitentes de rede. Diagnóstico apontava para placa de rede com defeito.
A solução era simples: trocar a placa. O problema era que o servidor estava em produção, com email corporativo de centenas de usuários dependendo dele, e trocar a placa exigia desligar o equipamento.
Janela de manutenção: sexta à noite, depois das 22h.
Antes da manutenção, passei a tarde inteira preparando.
Documentei o estado atual — todas as configurações de rede, as rotas, as interfaces. Testei o processo de inicialização no ambiente de desenvolvimento para ter certeza do que ia acontecer quando o servidor voltasse. Avisei os usuários com antecedência. Tinha contato do supervisor disponível caso algo saísse errado.
Parecia exagero para uma troca de placa. Não era.
A placa nova tinha driver diferente do esperado. A interface de rede voltou com nome diferente — eth1 em vez de eth0. As configurações que estavam amarradas ao nome da interface pararam de funcionar. O que deveria ser 20 minutos de downtime se estendeu para 45 enquanto reconfigurávamos.
O que aquela noite ensinou que carreguei para software:
Mudança em produção sem plano de rollback não é mudança — é aposta. Para hardware, rollback significa ter a placa antiga disponível. Para software, significa saber exatamente como reverter o deploy. A pergunta "como desfaço isso se der errado?" precisa ter resposta antes de começar.
Estado atual documentado antes de mudar. Não confiar na memória. Não assumir que "vai ser rápido então não precisa". Tempo que leva documentar o estado é sempre menor que o tempo de recriar quando você não lembra como estava.
Avisar quem vai ser afetado. Mesmo que a janela seja madrugada e poucos usuários estejam ativos — alguém pode estar. Surpresa em produção não é surpresa: é falha de comunicação.
Testar a mudança antes de aplicar em prod. Em hardware isso era difícil — não tinha equipamento idêntico para simular. Em software não tem desculpa: staging existe por essa razão.
Tem uma frase que ouvi de um colega mais velho naquela época: "servidor em produção não tem segunda chance de fazer a primeira impressão."
Era sobre reputação de quem operava. Se você derruba o servidor três vezes tentando fazer manutenção, as pessoas param de confiar que você pode fazer manutenção. A confiança de que o sistema vai estar disponível quando precisam — isso é construído chamada a chamada, manutenção a manutenção.
Anos depois, trabalhando com progressive delivery e canary deployments, a motivação era a mesma: não expor todos os usuários à mudança de uma vez. Janela de manutenção de hardware às 22h virou canary em 5% do tráfego. O princípio não mudou.
Essa semana: qual é a última mudança que você fez em produção sem ter planejado o rollback antes?