Quem Administra Os Estados

O que é administração de estado em infraestrutura como código

A administração de estados em ferramentas de infraestrutura como código se refere ao gerenciamento dos arquivos de estado que registram a correspondência entre os recursos declarados no seu código e a realidade dentro da nuvem ou data center. Quando você roda um comando como "terraform apply", o sistema consulta um arquivo de estado para saber o que já existe, o que precisa ser criado ou modificado, e o que deve ser destruído. Sem esse controle, a ferramenta não conseguiria fazer plano de execução correto e acabaria criando recursos duplicados ou destruindo o que já está funcionando. Na prática, quem administra os estados é a pessoa ou equipe responsável por manter o backend de estado seguro, versionado e acessível apenas para quem tem autorização. No Terraform, por exemplo, o estado pode ficar num bucket S3, num repositório Git, em um storage Azure ou até localmente. O problema é que esse arquivo contém credenciais, IDs de recursos e configurações sensíveis, então a administração dele exige controle de acesso rigoroso e, idealmente, criptografia em repouso. Eu já tive um problema bem específico com isso. Em um projeto antigo, o arquivo de estado do Terraform estava configurado em backend local, mas outro engenheiro fez apply na máquina dele sem sincronizar com o repositório. Quando tentei rodar o meu plano, o Terraform reclamou de conflito de trava e o estado saiu completamente dessincronizado com a infraestrutura real. A solução foi restaurar uma cópia de backup do dia anterior e refazer o import manual dos recursos que haviam sido criados durante o período de inconsistência. Demorou cerca de 4 horas para resolver, e esse é exatamente o tipo de situação que aparece quando a administração do estado é deixada de lado.

Existem algumas práticas que reduzem muito esse risco. O primeiro ponto é usar backend remoto desde o início, nunca local. O segundo é ativar versionamento no storage onde o estado fica — no S3, por exemplo, isso é uma configuração de uma linha e te permite recuperar qualquer versão anterior com facilidade. O terceiro é colocar travas de concorrência no backend, porque duas execuções simultâneas escrevendo no mesmo arquivo de estado são a causa número um de corrupção. Uma coisa que pouca gente menciona é que ferramentas diferentes não compartilham estado entre si. Se você usa Terraform para provisionar a infraestrutura e depois Ansible para configurar os servidores, o Ansible não sabe do que o Terraform criou, e vice-versa. Alguns times tentam contornar isso exportando outputs do Terraform para arquivos JSON que o Ansible consome como variáveis. Funciona, mas exige um pipeline bem estruturado, senão você acaba com dados defasados rodando em produção. Também é importante lembrar que estado grande é problema. Já vi arquivos de estado com mais de 50 MB em ambientes que provisioningavam centenas de recursos sem cuidado. O tempo de execução do plano e do apply crescia proporcionalmente, e o risco de timeout em backends remotos aumentava bastante. A solução para isso é modularização — dividir a infraestrutura em workspaces ou módulos menores que mantenham arquivos de estado independentes e gerenciáveis. Em geral, um arquivo de estado com menos de 5 MB mantém performance boa mesmo em execução diária.

Se você está começando agora e quer entender melhor como funciona o estado no Terraform, a documentação oficial tem a seção State File Documentation que cobre desde o básico até técnicas avançadas como state migrate e remote backend configuration. Eu costumo recomendar esse link para quem precisa resolver um problema específico, porque a resposta quase sempre está lá. O ponto mais importante que eu deixei de fora em tutoriais genéricos é que administração de estado não termina quando o recurso é criado. Você precisa monitorar quem tem acesso, quando o arquivo foi modificado pela última vez, e manter um registro das mudanças. Um simples log de quem rodou apply e quando, num repositório separado, já ajuda muito a rastrear problemas quando algo sai do controle.