Prevenindo e corrigindo o drift de infraestrutura no Terraform para Azure

By Mirko Peters · 2026-10-28

Saiba como o drift de infraestrutura acontece no Terraform e no Azure, como hotfixes emergenciais feitos no portal quebram os arquivos de estado e como detectar e corrigir discrepâncias com segurança.

Automatically translated with AI from the original post. Read the English original

O drift de infraestrutura é um dos problemas silenciosos mais comuns e perigosos em ambientes de nuvem modernos. Quando engenheiros fazem ajustes manuais diretamente no portal do Azure durante incidentes, essas ações silenciosamente quebram a sincronização com os repositórios de código. Este guia completo explica como o drift acontece, os riscos que ele representa para os seus arquivos de estado e como detectar e corrigir discrepâncias de forma sistemática, sem causar interrupções em produção.

Principais conclusões

• O drift de infraestrutura ocorre quando alterações manuais feitas no console da nuvem divergem do código Terraform declarado.
• Hotfixes emergenciais feitos diretamente em produção contornam o controle de versão e criam falhas silenciosas futuras durante as execuções normais de plan.
• Os arquivos de estado do Terraform funcionam como a ponte de memória, comparando a sua configuração escrita, o estado anterior e os recursos reais na nuvem.
• Detectar o drift cedo exige execuções automatizadas e regulares de plan e uma política rigorosa contra alterações manuais no portal não documentadas.
• Resolver o drift exige decidir se você atualiza o ambiente em produção para voltar ao código ou se atualiza a configuração para refletir a realidade.

O que é o drift de infraestrutura e por que ele acontece?

Até as equipes de engenharia de nuvem mais disciplinadas acabam sendo afetadas pelo drift de infraestrutura. O drift é definido como qualquer alteração não autorizada, não documentada ou emergencial feita nos recursos da nuvem que gerencia um estado fora dos seus pipelines automatizados. Imagine um cenário em que um engenheiro é acionado durante um incidente de madrugada. Sob pressão, ele acessa o console do Azure, aumenta o limite de escalonamento automático de cinco instâncias para dez, resolve o problema e volta a dormir.

O problema é que o arquivo de configuração versionado no seu repositório ainda diz cinco. O ambiente em nuvem ativo diz dez. Como ninguém documentou a mudança nem atualizou o código, forma-se uma grande desconexão entre a arquitetura pretendida e a realidade. Essa lacuna fica oculta por semanas, até que alguém execute um plan de rotina do Terraform para uma atualização totalmente não relacionada. De repente, a saída do terminal exibe um aviso de que o Terraform pretende reduzir essas instâncias de volta para cinco.

O fator humano e a pressão operacional

O drift raramente é malicioso; quase sempre nasce da urgência operacional. Quando ambientes de produção falham, o instinto leva os engenheiros a conter o problema imediatamente, usando as ferramentas mais rápidas disponíveis. O provisionamento por clique no portal do Azure é rápido, visível e imediato. No entanto, toda vez que um engenheiro usa o portal para corrigir um problema sem registrá-lo no código, ele cria uma dívida técnica que terá de ser paga depois, com juros.

Como o estado do Terraform identifica discrepâncias

Para entender como o Terraform detecta o drift, é preciso observar de perto o seu mecanismo de memória: o arquivo de estado. O arquivo de estado do Terraform funciona como a fonte definitiva da verdade, mapeando os seus recursos na nuvem para os arquivos de configuração. Quando você executa um comando, o Terraform não envia cegamente os arquivos para a nuvem. Em vez disso, ele realiza uma comparação em três vias.

Primeiro, ele lê o que você escreveu nos seus arquivos de configuração. Segundo, inspeciona o que foi registrado no arquivo de estado durante o último apply bem-sucedido. Terceiro, consulta a API do provedor de nuvem por meio de plugins e verifica o que realmente existe na sua assinatura neste momento. Quando esses três elementos não coincidem, o Terraform reconhece que a realidade mudou silenciosamente.

O perigo dos avisos ignorados

Durante a execução de um plan, o Terraform gera uma saída detalhada mostrando adições, atualizações e exclusões. Quando há drift, você verá com frequência avisos indicando que um recurso precisa ser modificado ou até completamente substituído. Iniciantes costumam entrar em pânico ao ver avisos sobre substituições forçadas de recursos. Esse aviso não é um erro, e sim o Terraform dizendo que o recurso ativo sofreu uma mudança tão grande que ficou irreconhecível e que, para trazê-lo de volta ao que está no seu código, ele precisa ser destruído e recriado.

Melhores práticas para detectar e prevenir drift

Prevenir drift exige uma combinação de barreiras culturais e controles técnicos automatizados. Se você deixar a detecção de drift inteiramente por conta de verificações manuais, inevitavelmente enfrentará indisponibilidades dolorosas em produção. Estas são as estratégias fundamentais que as equipes usam para manter seus ambientes de nuvem alinhados:

• Imponha acesso somente leitura: remova as permissões de escrita em produção dos usuários humanos. Faça com que todas as mudanças de infraestrutura passem pelos seus pipelines de CI/CD e pelas revisões de pull request.
• Agende execuções automatizadas do plan: configure pipelines de integração contínua para executar regularmente o comando 'terraform plan' sem aplicá-lo. Revise a saída em busca de modificações inesperadas.
• Divida arquivos de estado monolíticos: separe ambientes grandes em componentes menores e modulares. Arquivos de estado menores facilitam isolar, revisar e corrigir o drift.
• Implemente o bloqueio de estado remoto: garanta que sua equipe use backends remotos seguros com bloqueio de estado, para que execuções simultâneas não corrompam os registros de estado.

Como corrigir o drift quando ele ocorre

Quando você descobre que sua infraestrutura ativa se desviou da configuração, chega a uma bifurcação estratégica. Há dois caminhos principais para a correção:

A primeira opção é deixar o Terraform sobrescrever o ambiente ativo. Ao executar o 'terraform apply' padrão, você força o Azure a reverter para o estado descrito no seu código. Este é o caminho certo quando o drift foi causado por uma alteração manual não autorizada ou por uma configuração temporária de depuração que não deveria mais existir.

A segunda opção é atualizar a configuração do Terraform para refletir a realidade. Escolha este caminho quando o hotfix manual feito durante um incidente se mostrar necessário, estável e benéfico para produção. Ao atualizar o código para refletir a nova realidade, você fecha a lacuna e garante que as execuções automatizadas futuras preservem a configuração necessária.

Conclusão

O drift de infraestrutura é um desafio inevitável em ambientes de nuvem dinâmicos, mas não precisa significar um desastre para a sua equipe. Ao entender como o arquivo de estado do Terraform registra as mudanças, implementar controles de acesso rigorosos e tratar a detecção de drift como um hábito operacional regular, você pode manter controle total sobre a sua arquitetura de nuvem. Para explorar em mais detalhes os mecanismos fundamentais de infraestrutura como código, provedores e gerenciamento de estado, ouça o episódio completo e conheça as percepções dos especialistas para aprimorar sua estratégia de automação em nuvem.

Perguntas frequentes

O que causa drift de infraestrutura no Terraform?

O drift é causado por alterações feitas diretamente nos recursos da nuvem fora do fluxo do Terraform, usando portais, comandos de CLI ou scripts que contornam o pipeline do Terraform.

Como o Terraform detecta drift de configuração durante uma execução de plan?

O Terraform compara o arquivo de estado armazenado com os recursos reais da nuvem, consultados por meio das APIs dos provedores, e com os seus arquivos de configuração locais.

O que acontece se alguém alterar manualmente um recurso do Azure gerenciado pelo Terraform?

Na próxima execução de um plan do Terraform, ele sinalizará a divergência e tentará reverter o recurso para que corresponda ao código declarado, a menos que a configuração seja atualizada.

Devo atualizar o código do Terraform ou reverter a alteração feita no portal do Azure?

Se a alteração manual foi um hotfix emergencial que agora é necessário para a estabilidade, atualize sua configuração do Terraform. Se foi uma modificação não autorizada ou acidental, deixe o Terraform reverter a alteração.