A detecção de drift em infraestrutura é um desafio comum, mas resolvido superficialmente. Ferramentas como o terraform plan identificam o que mudou, mas o verdadeiro gargalo operacional é o que acontece na sequência: quem realizou a alteração, por que foi feita e se é seguro reverter essa mudança automaticamente. Geralmente, isso desencadeia uma investigação manual, lenta e propensa a erros.
O que acontece após o terraform plan encontrar drift?
Em times de alta performance, o ciclo de resposta ao drift costuma ser ineficiente:
- O terraform plan agendado detecta alterações em 3 resources.
- Um alerta é disparado no Slack ou Teams.
- Um ticket é aberto.
- Um engenheiro precisa abrir múltiplas abas documentando o estado do Terraform, Azure Portal, Activity Log e Application Insights para entender o contexto.
- Descobre-se que a alteração foi um ajuste de emergência em um App Service durante um incidente de latency às 2 da manhã.
- O engenheiro executa o terraform apply para reverter.
- A aplicação cai, pois ele reverteu o scaling enquanto o bug que causou o incidente original ainda estava em produção.
O problema não é a detecção, mas a falta de contexto na resolução. É aqui que os HTTP Triggers no Azure SRE Agent transformam o panorama, convertendo o output estruturado do drift (webhooks, resumos de plano) no ponto de partida para uma investigação autônoma.
O fluxo: Da detecção à resolução via Webhook
A arquitetura é focada em reduzir o tempo de triagem. O Terraform Cloud envia um webhook assim que identifica drift. Uma Azure Logic App atua como uma ponte de autenticação (usando Managed Identity) e aciona o HTTP Trigger do Agent, iniciando o processo de investigação correlacionando logs, analisando código e recomendando ações baseadas em severidade.
Implementando o Ciclo de Vida do Drift
- Infraestrutura: Utilizamos um Azure App Service configurado via Terraform. A Logic App garante a segurança na comunicação.
- Drift Analysis Skill: É o cérebro que ensina o agent como investigar, priorizando o contexto. A regra de ouro instalada aqui é: "NUNCA reverta drift crítico que esteja ativamente mitigando um incidente."
- HTTP Trigger: O agent processa o payload seguindo um prompt estruturado que avalia desde o Activity Log até o código-fonte.
Estudo de Caso: Por que o contexto salva o SLA
Após o drift ser detectado devido a um scale-up de SKU para S1 (feito manualmente para mitigar um bug de performance), o agent atuou da seguinte forma:
- Classificação: Identificou que o SKU é Critical, enquanto tags são Benign.
- Correlação de Incidente: O agent consultou o Application Insights e descobriu que o endpoint /api/data tinha uma falha de sincronização (latência de ~25s a 58s), invalidando a necessidade de reverter o SKU S1 sem antes corrigir o código.
O Diferencial: Um Agent que auto-aprimora
Além de atuar, o agent revisa seu desempenho. Ao encontrar lacunas em sua própria skill de drift analysis, ele sugeriu e aplicou melhorias, integrando novas verificações (como a ausência de code-infrastructure mismatch) e criando proativamente um pull request (PR) contendo a correção definitiva para o código-fonte.
Conclusões para o Seu Time
- Detecção é apenas o começo: O valor real é o why. Se você sabe por que algo mudou, você evita incidentes P1 causados pela própria automação.
- Contexto é soberano: Remediation sem sensibilidade ao App Insights ou logs de incidente é um risco operacional.
- Aprendizado contínuo: O uso de agentes que evoluem sua "base de conhecimento" (skill files) é o futuro de operações resilientes e eficientes.
O padrão de integração via HTTP Triggers é agnóstico e pode ser aplicado sobre Jenkins, GitHub Actions, Datadog ou qualquer ferramenta de CI/CD que suporte webhooks.
