IA para DevOps e SRE

10.1 IA na infraestrutura: o que muda

• Raio de impacto: uma resposta errada num chat é um incômodo; um comando errado em produção é um incidente. Classifique cada ação por risco (Módulo 6) e trate ações de escrita como deploys.
• Leitura é menos arriscada que escrita, mas não é isenta de risco: a maior parte do valor está em investigar (ler logs, métricas, eventos, histórico), e por isso comece só com leitura. Mas ler também tem riscos: logs e variáveis de ambiente podem conter segredos, que entram no contexto do modelo e podem sair numa resposta; e um log, um ticket ou uma página pode trazer instruções maliciosas (injeção indireta, Módulo 12). Leitura com credenciais restritas, segredos mascarados na origem e o conteúdo lido tratado como dado, não como ordem.
• Validação determinística depois da IA: terraform validate e plan, dry-run do Kubernetes, políticas, testes. O modelo propõe; as ferramentas da sua plataforma verificam.
• Credenciais mínimas: a conta de serviço do agente só lê, salvo exceções aprovadas e auditadas.
• Alucinação de flags e APIs: modelos inventam opções de linha de comando e campos de manifest com confiança. Validação de schema e dry-run pegam isso.

10.2 Copilot de IaC com validação e policy-as-code

python python/01_politicas_iac.py

✓ create  aws_s3_bucket.relatorios
      [alerta] tags obrigatórias ausentes: centro_de_custo
✗ create  aws_s3_bucket_public_access_block.relatorios
      [bloqueia] bucket com acesso público liberado
✗ create  aws_instance.job_noturno
      [bloqueia] tipo de instância p4d.24xlarge fora da lista aprovada (custo)
✗ create  aws_security_group.job
      [bloqueia] porta 22 aberta para a internet inteira
✗ delete  aws_db_instance.legado
      [bloqueia] remove um recurso de DADOS (pedidos-legado): exige aprovação explícita e backup verificado

4 violações bloqueantes.

10.3 Agentes para Kubernetes e GitOps

• Gerar e revisar manifests: LLMs escrevem YAML razoável; valide com kubectl apply --dry-run=server, schemas e políticas (requests e limits obrigatórios, sem latest, sem privilégios).
• Autoscaling: a IA pode sugerir parâmetros de HPA/VPA a partir do histórico de uso, mas a mudança passa pelo mesmo fluxo de PR.
• Rollouts progressivos (canário, blue-green): a IA ajuda a ler as métricas da análise de canário e a explicar por que um rollout foi abortado.
• GitOps (Argo CD, Flux): o estado desejado vive no Git. Um agente bem projetado propõe commits, não altera o cluster por fora, o que mantém auditoria e rollback pelo próprio Git.

10.4 Troubleshooting com ReAct

O agente do projeto segue o método de um SRE experiente, escrito no prompt de sistema:

1. Estado dos pods e eventos; depois logs e métricas.
2. Procurar a mudança mais recente: a maioria dos incidentes começa com um deploy, uma configuração ou um pico de tráfego.
3. Registrar o diagnóstico estruturado com evidências antes de agir (o código recusa ação sem diagnóstico).
4. Preferir a correção mais segura e reversível.

npm run investigar -- crashloop-config

10.5 AIOps: métricas, logs e anomalias

• Linguagem natural → consulta: "erro 5xx do checkout na última hora por versão" → PromQL ou LogQL. Útil para quem não domina a linguagem; mostre sempre a consulta gerada e rode em modo só leitura.
• Resumo de logs: agrupar milhares de linhas em padrões e mandar ao LLM só os padrões e exemplos, não o log inteiro (custo e contexto).
• Detecção de anomalias: estatística simples (z-score, sazonalidade) e modelos de série temporal resolvem a maioria dos casos; o LLM entra para explicar e correlacionar, não para detectar.

python python/02_anomalias_e_timeline.py

Detector INGÊNUO (janela inclui os próprios pontos anômalos):
  2 minutos anômalos: 10:34, 10:35
Detector ROBUSTO (anomalias ficam fora da referência):
  10 minutos anômalos: 10:34, 10:35, 10:36, ... 10:43

LINHA DO TEMPO
  10:33  deploy    checkout revisão 42 (migração de ConfigMap) iniciada
  10:34  anomalia  latencia_p95_ms começou a subir: 983 ms (z = 56)
  10:34  anomalia  taxa_erro_pct começou a subir: 11.17% (z = 63)
  10:35  alerta    taxa de erro 5xx > 5% em checkout
  10:40  deploy    rollback de checkout para a revisão 41
  10:44  alerta    alerta resolvido

10.6 ChatOps com RBAC, aprovação e auditoria

• Comandos explícitos (/investigar, /rollback), não "faça o que achar melhor".
• Aprovação por quem tem o papel certo (RBAC): no projeto, só ana.sre e bruno.oncall aprovam ações em produção; qualquer outro nome é recusado.
• Mostrar o impacto antes de aprovar: o diff da mudança, a revisão de destino, quantos pods serão reiniciados.
• Auditoria completa: cada passo do agente e cada aprovação (quem, quando, o quê) vão para auditoria-chatops.jsonl.
• Disjuntores (circuit breakers): limite de ações automáticas por hora; se o agente propõe três rollbacks seguidos, algo está errado, então pare e chame uma pessoa.

10.7 RAG de runbooks e post-mortem automático

• Runbooks como fonte do agente: indexe runbooks, READMEs e post-mortems antigos com o RAG do Módulo 4 e exponha como ferramenta (ou servidor MCP, Módulo 5). O agente passa a seguir o procedimento da sua empresa.
• Linha do tempo automática: junte deploys, alertas, anomalias e mensagens do canal (lab 10.5).
• Rascunho de post-mortem sem culpados: o LLM escreve o rascunho a partir da linha do tempo e da trajetória do agente; as pessoas revisam, especialmente as causas contribuintes e as ações.
• Lições viram prevenção: cada post-mortem gera itens concretos (teste no CI, alerta mais cedo, política nova) e, de preferência, um caso novo no eval do agente.

10.8 Auto-remediação segura e FinOps

Auto-remediação

• Automatize primeiro ações reversíveis e bem compreendidas (reiniciar um pod, escalar réplicas dentro de limites), com dry-run e validação depois.
• Ações de alto impacto (rollback em produção, failover de banco) continuam com uma pessoa no circuito.
• Limites e disjuntores: o remediador nunca pode ser a causa do próximo incidente.

FinOps com IA

• Estimativa de custo no PR (ferramentas como Infracost) e explicação em linguagem natural do que encarece.
• Rightsizing a partir do histórico de uso; detecção de recursos ociosos ("zumbis").
• Previsão de gasto e alerta de desvio. O mesmo raciocínio vale para o custo dos próprios LLMs (Módulo 9).

Projeto do módulo: bot de ChatOps para incidentes

cd projeto && npm install && npm test       # 7 testes, offline
npm run investigar -- oom                     # precisa de ANTHROPIC_API_KEY

Entregáveis

1. Rode os três cenários com a API. O agente chegou à causa certa? Quantos passos e quanto custou?
2. Crie dois cenários novos (por exemplo, certificado TLS expirado; dependência externa lenta) com testes.
3. Transforme os cenários num eval de trajetória (Módulo 6): a ação correta foi proposta? Alguma ação foi executada sem diagnóstico?
4. Adicione uma ferramenta de busca em runbooks usando o RAG do Módulo 4.
5. Gere o rascunho de post-mortem a partir da trajetória e do diagnóstico.

Critérios de avaliação

Recursos para aprofundar

• Open Policy Agent e Conftest · políticas como código
• Checkov · varredura de IaC
• Postmortem culture (Google SRE) · post-mortems sem culpados
• Argo CD · GitOps
• Infracost · custo de infraestrutura no PR