Quando um alerta de severidade Sev1 dispara em um cluster AKS, o desafio raramente está na detecção; o verdadeiro gargalo é o que vem a seguir: isolar a causa raiz, entender o impacto e aplicar a correção sem aumentar o blast radius — tudo isso sob pressão, muitas vezes de madrugada. É aqui que o Azure SRE Agent entra como uma peça fundamental para times que buscam eficiência operacional.
O Azure SRE Agent não é apenas um assistente conversacional; ele é uma solução de resposta a incidentes que integra a observabilidade nativa do Azure, diagnósticos do AKS e fluxos de trabalho de engenharia em um loop fechado. O resultado é a capacidade de investigar, remediar, verificar e documentar incidentes sem exigir a intervenção manual do time para consultar dashboards ou executar comandos kubectl ad-hoc.
Conceitos fundamentais
O Azure SRE Agent é um sistema de resposta governado, não um simples chatbot de infraestrutura. Cinco pilares sustentam esse fluxo:
- Incident platform: A origem dos alertas, neste caso, o Azure Monitor.
- Built-in Azure capabilities: Integração direta com Log Analytics, Azure Resource Graph, Azure CLI/ARM e diagnósticos do AKS, sem conectores externos.
- Connectors: Extensão para ecossistemas como GitHub, Microsoft Teams, Kusto e servidores MCP.
- Permission levels: Níveis de Reader (apenas investigação) versus Privileged (alterações operacionais).
- Run modes: Review (requer aprovação) e Autonomous (execução direta).
Nota: O critério de sucesso mais crítico na produção é a configuração de permissão e o modo de execução, não o prompt. Instruções personalizadas refinam o comportamento, mas não substituem políticas de RBAC, qualidade de telemetria ou disponibilidade de ferramentas.
A jornada recomendada para adoção é progressiva:
Start: Reader + Review → Then: Privileged + Review → Finally: Privileged + Autonomous (reservado apenas para caminhos críticos e validados).
Ambiente de demonstração
Para reproduzir esses cenários, os scripts e manifestos podem ser encontrados no repositório de demonstração. O ambiente utiliza:
- AKS com node auto-provisioning (NAP);
- Azure CNI Overlay com Cilium;
- Managed Prometheus;
- Microserviços do AKS Store.
O fluxo segue esta lógica:
Azure Monitor (Alert) → Action Group (Webhook) → Azure SRE Agent (Investigate / Fix) → AKS Cluster (Recover)
Dois incidentes, duas abordagens
O agente opera tanto em automação disparada por alertas quanto em modo de auxílio via chat. No primeiro cenário (CPU starvation), ele identificou que o erro não era OOMKill, mas uma falha de configuração de startup probe, corrigindo múltiplos pods automaticamente em 8 minutos. No segundo, tratou um OOMKill de um order-service em apenas 4 minutos, ajustando limites de memória que estavam subdimensionados.
A importância da continuidade (Teams + GitHub)
Remediar em tempo real é apenas metade da batalha. Se o manifesto original no repositório continuar errado, o incidente voltará. Por isso, a integração com GitHub para abrir Issues e Pull Requests de correção é vital. Enquanto o Teams mantém o time informado sobre o status, o Git garante que a causa raiz seja corrigida de forma definitiva no código-fonte.
Considerações estratégicas
- Governança: Trate o Azure SRE Agent como um sistema de resposta, não como um robô autônomo sem rédeas. O controle está nos permissionamentos (RBAC) e nos modos de execução.
- Detecção ancorada: Utilize as plataformas de incidentes existentes. O agent deve atuar como uma extensão do seu fluxo, utilizando conectores para coordenação real-time e documentação de engenharia.
- Evolução: Comece pequeno, em uma única Resource Group e em modo Review. A confiança na automação cresce conforme você valida a telemetria e os tipos de falhas mapeados.
À medida que o cenário brasileiro de TI busca maior eficiência FinOps e resiliência, a adoção de agentes de SRE não é mais uma opção, mas uma necessidade para escalar ambientes complexos de Kubernetes.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
