Patch Management em Larga Escala: Linux vs AIX IBM em Produção

Gerir patches em um parque heterogêneo — dezenas de servidores Linux ao lado de partições AIX em hardware IBM Power — expõe rapidamente onde a teoria de “patch tudo, sempre” quebra na prática.

O problema do rollback

Em Linux, um pacote com dependência quebrada geralmente é resolvido revertendo para a versão anterior do repositório ou usando snapshots de filesystem (LVM, Btrfs). Em AIX, a estratégia é fundamentalmente diferente: o mecanismo nativo é o alt_disk_copy, que clona o rootvg inteiro para um disco alternativo antes de aplicar o Technology Level ou Service Pack. Se algo falhar, o boot é redirecionado para o disco antigo através do HMC (Hardware Management Console) — não existe “downgrade de pacote”, existe troca de disco de boot.

Janelas de manutenção

Em produção crítica, isso significa que uma janela de patch AIX precisa reservar tempo para: clonar o disco, aplicar o pacote, reiniciar, validar serviços, e só depois decidir se o disco antigo pode ser liberado. É comum reservar esse disco por 30 a 90 dias como rede de segurança antes de reaproveitá-lo.

O que aprendi

• Documentar lado a lado os dois runbooks (Linux e AIX) evita que alguém aplique o procedimento errado sob pressão.
• Testar o rollback de verdade em ambiente de homologação — não basta confirmar que o alt_disk foi criado, é preciso realmente inicializar por ele.
• Priorização por CVSS puro não funciona igual nos dois mundos: a superfície de exposição de uma partição AIX isolada é normalmente muito menor que a de um servidor Linux com serviços expostos.

No fim, patch management em ambiente misto não é sobre ferramentas — é sobre ter dois modelos mentais diferentes de “o que significa reverter” e saber qual usar em cada sistema.