Desvio

O desvio é uma diferença entre o que o código diz e o que realmente existe na nuvem. Em geral significa que alguém mudou algo fora de um merge request: no console do Google Cloud, com uma concessão de tempo limitado, ou com um comando rodado à mão. O Airframe não tenta impedir toda mudança assim; ele garante que nenhuma passe despercebida, verificando cada raiz todo dia e abrindo uma issue quando os dois não batem.

Por que o desvio importa

A plataforma inteira se apoia em uma promessa: o que está no código na main é o que roda. As revisões, o pacote de políticas e o registro de auditoria olham o código. Uma mudança feita à mão pula os três e, pior, o próximo apply daquela raiz pode desfazê-la em silêncio, ou falhar por causa dela, num momento que ninguém espera.

O desvio nem sempre é um erro. Um mantenedor que corrige uma queda com uma concessão cria desvio de propósito. O que importa é que ele seja visto e depois resolvido, de um jeito ou de outro.

Como ele é encontrado

Cada repositório com raízes do Terraform tem um pipeline agendado diário. Nele, o job de desvio do componente tf-apply planeja cada raiz contra a infraestrutura real sem aplicar nada. Um plano vazio significa que a raiz corresponde. Um plano que não está vazio significa que algo se desviou.

As duas raízes da plataforma que implantam imagens, a do controle de aprovação e a do catálogo de arquitetura, são planejadas contra as imagens que aplicaram por último, que elas registram na saída images do seu estado. Por isso uma imagem construída para um commit e nunca implantada não é desvio: o plano pergunta se a nuvem difere da última aplicação.

As três raízes do landing-zone que ainda são aplicadas a partir de um notebook são planejadas do mesmo jeito, por uma identidade que só pode ler, então uma mudança feita com uma concessão aparece em menos de um dia.

O que acontece

Depois dos jobs de desvio, o componente drift-report transforma seus resultados em issues do GitLab, como a identidade de auditoria da plataforma:

uma issue aberta por raiz com desvio, com o rótulo audit::drift e o nome da raiz no título;
a issue lista os recursos que diferem e o que o plano faria com cada um, nunca seus valores, então nenhum segredo pode vazar para uma issue;
enquanto o desvio dura, cada execução diária reescreve a issue;
a primeira execução que encontra a raiz correspondendo de novo a fecha.

Por exemplo, o Drift: gate do control-plane foi um desvio falso. Cada merge no control-plane construía uma nova imagem do controle de aprovação, enquanto o controle só era implantado quando o seu próprio código mudava, e o plano diário comparava com a construção mais recente, então a partir de 2026-09-29 a maioria das manhãs o relatou. A correção de 2026-10-02 fez o plano comparar com as imagens que a raiz aplicou por último, e a execução de 2026-10-03 encontrou a raiz correspondendo e fechou a issue.

O que fazer

Leia a issue, descubra quem mudou o quê e por quê, e escolha uma de duas correções:

Codificar. Se a mudança estava certa, escreva-a no código em um merge request. Depois de aplicada, o próximo plano diário sai vazio e a issue se fecha.
Reverter. Se a mudança estava errada, deixe o código vencer: o próximo apply daquela raiz, a partir de um pipeline na sua branch main, devolve a infraestrutura ao que o código diz, e a próxima execução diária fecha a issue.

De qualquer jeito, o código continua sendo a única fonte da verdade, e toda mudança nele passa por um merge request e suas verificações.

Por que o console não é o jeito de mudar as coisas

O console serve para olhar. Para mudar, ele pula tudo o que torna uma mudança segura no Airframe: ninguém mais a revisa, nenhuma regra a verifica, nenhum plano mostra o que ela toca, e nada registra por que ela foi feita. De todo modo, as contas de uso diário das pessoas não podem mudar a infraestrutura de produção; as concessões de tempo limitado existem para emergências, e a detecção de desvio é o que garante que uma correção de emergência volte para o código.

Onde fica

No repositório control-plane: