Phase 19 - Lesson 06

Capstone 06 — Agente de Resolução de Problemas de DevOps para Kubernetes

O DevOps Agent da AWS tornou-se GA, a Resolve AI publicou seus playbooks de K8s, a NeuBird demonstrou monitoramento semântico e a Metoro vinculou SRE com IA a SLOs por serviço. O formato de produção está consolidado: um webhook de alerta é acionado, um agente lê a telemetria, percorre um gráfico de objetos do K8s, classifica as hipóteses de causa raiz e publica um resumo no Slack com botões de aprovação. Somente leitura por padrão. Cada remediação é controlada por um ser humano. Este capstone é esse agente, avaliado em 20 incidentes sintéticos e comparado com o DevOps Agent da AWS em três casos compartilhados.

Tipo: Capstone Linguagens: Python (agente), TypeScript (integração com Slack) Pré-requisitos: Fase 11 (engenharia de LLM), Fase 13 (ferramentas e MCP), Fase 14 (agentes), Fase 15 (autônomos), Fase 17 (infraestrutura), Fase 18 (segurança) Fases exercitadas: P11 · P13 · P14 · P15 · P17 · P18 Tempo: 30 horas

Problema

A narrativa de SRE para 2025-2026 tornou-se: "Agentes de IA triam incidentes, humanos aprovam remediações." O AWS DevOps Agent, Resolve AI, NeuBird, Metoro e PagerDuty AIOps entregam esse formato em produção. O agente lê métricas do Prometheus, logs do Loki, traces do Tempo, kube-state-metrics e um gráfico de conhecimento (knowledge graph) de objetos do K8s. Ele produz uma hipótese de causa raiz classificada com citações de telemetria em menos de cinco minutos. O agente nunca executa comandos destrutivos sem aprovação humana explícita através do Slack.

A maior parte do trabalho difícil está no escopo e na segurança, não no raciocínio. O agente precisa de uma superfície RBAC somente leitura por padrão, um servidor de ferramentas MCP robusto e logs de auditoria de cada comando considerado vs executado. Ele precisa saber quando está além de sua capacidade e escalar o problema. Além disso, ele deve rodar de forma barata o suficiente para que cascatas de OOM-kill não gerem uma fatura de $5.000 para o agente.

Concept

O agente opera em um gráfico de conhecimento. Os nós são objetos do K8s (Pods, Deployments, Services, Nodes, HPAs, PVCs) além de fontes de telemetria (séries do Prometheus, fluxos do Loki, traces do Tempo). As arestas codificam propriedade (Pod -> ReplicaSet -> Deployment), agendamento (Pod -> Node) e observação (Pod -> série do Prometheus). O gráfico é mantido atualizado por uma sincronização de kube-state-metrics e reamostrado a cada alerta.

Quando um alerta é acionado, o agente investiga a causa raiz a partir do objeto afetado. Ele percorre as arestas, extrai os trechos de telemetria relevantes (últimos 15 minutos) e esboça uma hipótese. A hipótese é classificada por evidências: quantas citações de telemetria a apoiam, quão recentes e quão específicas. As 3 principais hipóteses vão para o Slack com visualizações do caminho no gráfico e botões de aprovação para ações de remediação.

A remediação é controlada. Ações padrão permitidas são somente leitura. Ações destrutivas (redução de escala, rollback, exclusão de Pods) exigem aprovação no Slack; os ganchos (hooks) de rollback do ArgoCD exigem um token de autenticação que o agente nunca possui. O log de auditoria registra cada comando que o agente considerou — não apenas os executados —, de modo que o processo de revisão capture quase incidentes (near-misses).

Architecture

PagerDuty / Alertmanager webhook
           |
           v
     FastAPI receiver
           |
           v
   LangGraph root-cause agent
           |
           +---- read-only MCP tools ----+
           |                             |
           v                             v
   K8s knowledge graph              telemetry slices
     (Neo4j / kuzu)              Prometheus, Loki, Tempo
   ownership + scheduling          last 15m, scoped
           |
           v
   hypothesis ranking (evidence weight)
           |
           v
   Slack brief + approval buttons
           |
           v (approved)
   ArgoCD rollback hook / PagerDuty escalate
           |
           v
   audit log: considered vs executed, every command

Stack

Fontes de observabilidade: Prometheus, Loki, Tempo, kube-state-metrics
Gráfico de conhecimento: Neo4j (gerenciado) ou kuzu (incorporado) de objetos do K8s + arestas de telemetria
Agente: LangGraph com lista de permissões por ferramenta, somente leitura por padrão
Transporte de ferramentas: FastMCP sobre StreamableHTTP; servidor separado para ferramentas destrutivas por trás de um portão de aprovação
Modelos: Claude Sonnet 4.7 para raciocínio de causa raiz, Gemini 2.5 Flash para sumarização de logs
Remediação: webhook de rollback do ArgoCD, escalamento do PagerDuty, cartão de aprovação do Slack
Auditoria: log estruturado somente anexável (considerado, executado, aprovado, resultado)
Implantação: K8s deployment com sua própria função RBAC restrita; namespace separado

Build It

Ingestão no gráfico. Sincronize kube-state-metrics no Neo4j/kuzu a cada 30s. Nós: Pod, Deployment, Node, Service, PVC, HPA. Arestas: OWNED_BY, SCHEDULED_ON, EXPOSES, MOUNTS, SCALES. Arestas de sobreposição de telemetria: OBSERVED_BY (um Pod é observado por uma série do Prometheus).
Receptor de alertas. Endpoint FastAPI que aceita webhooks do PagerDuty ou Alertmanager. Extraia o(s) objeto(s) afetado(s) e a violação de SLO.
Superfície de ferramenta somente leitura. Envolva kubectl, Prometheus query, Loki logql, Tempo traceql através do FastMCP. Cada ferramenta possui um verbo RBAC restrito ("get", "list", "describe"). Sem "delete", "exec", "scale" no servidor padrão.
Agente de causa raiz. LangGraph com três nós: sample extrai o trecho de telemetria dos últimos 15 minutos, walk consulta o gráfico para objetos vizinhos, hypothesize esboça candidatos de causa raiz classificados com citações de telemetria.
Pontuação de evidências. Cada hipótese tem uma pontuação = recência * especificidade * inverso do comprimento do caminho no gráfico * contagem de citações. Retorne as top-3.
Resumo no Slack. Publique um anexo com a hipótese, a visualização do caminho no gráfico (uma imagem de subgráfico renderizada no servidor) e botões de aprovação para no máximo uma ação de remediação.
Portão de remediação. Ferramentas destrutivas (reduzir escala, rollback, deletar) residem em um segundo servidor MCP por trás de um token de aprovação. O agente pode chamá-las apenas após o cartão do Slack ser aprovado por um ser humano.
Log de auditoria. JSONL somente anexável: para cada comando candidato, registre se ele foi considerado, se foi executado e quem o aprovou. Envie para o S3 diariamente.
Conjunto de incidentes sintéticos. Construa 20 cenários: cascata de OOMKill, DNS flap, oscilação de HPA, preenchimento de PVC, vizinho barulhento, sidecar defeituoso, rollout incorreto de ConfigMap, rotação de certificados, recuo de download de imagem (image-pull backoff), etc. Pontue o agente com base na precisão da causa raiz e no tempo para hipótese.

Use It

webhook: alert.pagerduty.com -> checkout-api SLO breach, error rate 14%
[graph]   affected: Deployment checkout-api (3 Pods, Node ip-10-2-3-4)
[walk]    neighbors: ReplicaSet checkout-api-abc, Service checkout-api,
           recent rollout 14m ago
[sample]  prometheus error_rate 14%, up-trend; loki 500s on /api/v2/pay
[hypo]    #1 bad rollout: latest image checkout-api:v2.41 fails /healthz
           citations: deploy.yaml (rev 42), prometheus errorRate, loki 500 stack
[slack]   [ROLL BACK to v2.40]  [ESCALATE]  [IGNORE]
           (approval required; agent does not roll back unilaterally)

Ship It

outputs/skill-devops-agent.md é o entregável. Dado um cluster K8s e uma fonte de alertas, o agente produz hipóteses de causa raiz classificadas e um fluxo de remediação controlado pelo Slack.

Peso	Critério	Como é medido
25	Precisão de RCA no conjunto de cenários	≥80% de causa raiz correta em 20 incidentes sintéticos
20	Segurança	O protetor de ação destrutiva nunca é acionado sem aprovação no Slack no log de auditoria
20	Tempo para hipótese	p50 abaixo de 5 minutos desde o alerta até o resumo no Slack
20	Explicabilidade	Cada hipótese possui caminhos de gráfico e citações de telemetria
15	Completude da integração	PagerDuty, Slack, ArgoCD e Prometheus funcionando de ponta a ponta
100

Exercises

Execute seu agente nos mesmos três incidentes em que o DevOps Agent da AWS é demonstrado. Publique o comparativo lado a lado. Relate onde o agente diverge.
Adicione uma auditoria de "quase incidente" (near-miss) que sinalize qualquer comando que o agente considerou e que teria sido destrutivo sem aprovação. Meça a taxa de quase incidentes durante uma semana.
Substitua o modelo de hipóteses de Claude Sonnet 4.7 por um Llama 3.3 70B auto-hospedado. Meça a variação da precisão de RCA e o custo em dólar por incidente.
Construa um filtro causal: distinga picos de telemetria correlacionados de uma causa raiz real. Treine um pequeno classificador nos rótulos dos 20 cenários.
Adicione uma simulação de rollback (dry-run): rollback do ArgoCD contra um cluster de staging com o mesmo manifesto. Verifique o plano de rollback em um cluster ativo antes do botão de aprovação do Slack.

Key Terms

Termo	O que as pessoas dizem	O que realmente significa
Gráfico de conhecimento do K8s	"Gráfico do cluster"	Nós = objetos do K8s + séries de telemetria; arestas = propriedade, agendamento, observação
Somente leitura por padrão	"RBAC restrito"	A conta de serviço do agente possui apenas os verbos get/list/describe; verbos destrutivos residem em um servidor separado por trás de aprovação
Log de auditoria	"Considerado vs executado"	Registro somente anexável de cada comando candidato, se ele foi executado e quem o aprovou
Classificação de hipóteses	"Pontuação de evidência"	Recência × especificidade × inverso do comprimento do caminho no gráfico × contagem de citações
Cartão de aprovação do Slack	"Portão HITL"	Mensagem interativa do Slack com botões de remediação; o agente não pode prosseguir até que um humano clique
Citação de telemetria	"Ponteiro de evidência"	Uma consulta do Prometheus, seletor do Loki ou URL de trace do Tempo que apoia uma alegação
MTTR	"Tempo para resolução"	Tempo real decorrido desde o acionamento do alerta até a recuperação do SLO