Objetivo da Aula
Ao concluir esta aula, você será capaz de:
Mapear os 4 níveis de maturidade de IA em DevOps (assistente → copilot → agente → auto-remediação)
Identificar casos de uso reais onde LLMs superam abordagens tradicionais em operações
Projetar um pipeline RAG sobre runbooks e documentação técnica
Aplicar guardrails essenciais para agentes que atuam em infraestrutura de produção
Avaliar limitações reais de LLMs em contextos de infraestrutura
Por que isso importa
AIOps não é hype — é uma resposta a um problema real de escala. Um SRE humano processa centenas de alertas por dia. Cada alerta pode exigir correlacionar logs de 10 serviços, consultar runbooks, verificar métricas históricas. É fisicamente impossível fazer isso em segundos sem automação.
LLMs adicionam uma camada crucial que ferramentas determinísticas não têm: compreensão de contexto. Um script de remediação sabe que “reiniciar o pod resolve OOMKilled”. Um LLM entende que “esse OOMKilled específico é causado por um query sem índice que foi deployado há 2 horas” — e pode recomendar o fix correto em vez do fix genérico.
Conceitos Fundamentais
Decisão de Arquitetura: Padrão de Contenção AIOps
O risco central de IA em infraestrutura: LLMs geram configuração plausível mas incorreta. Um Terraform HCL ou PromQL gerado por IA pode ter a estrutura certa e a semântica errada — passando em lint mas falhando em produção, ou pior, aplicando corretamente algo destrutivo. O padrão de contenção é: (1) gerar o artefato com o LLM; (2) validar deterministicamente com ferramentas reais (terraform validate, yamllint, conftest OPA, custo estimado); (3) gate humano para revisar validação + artefato; (4) aplicar só após aprovação. O LLM só gera; toda a validação é determinística e automatizada antes de qualquer humano revisar. Isso cria uma "malha de verificação em torno de um gerador não-confiável" — o mesmo princípio de ter CI validando antes de qualquer merge.
Os 4 Níveis de Maturidade
Nível 1 — Assistente O humano mantém controle total. IA gera sugestões.
SRE: "Gere um manifest K8s para um deployment Node.js com 3 réplicas"
IA: [gera o YAML]
SRE: [revisa e aplica manualmente]Nível 2 — Copilot IA analisa e recomenda. Humano decide e executa.
Alerta: "API latency p99 > 5s"
IA: "Logs mostram pool de conexões esgotado. Recomendo aumentar max_connections para 200."
SRE: [executa o comando recomendado]Nível 3 — Agente Autônomo IA executa ações após gate de aprovação.
Alerta: "Memória > 90%"
IA: "Identifiquei vazamento no serviço auth. Proposta: reiniciar pod + criar issue."
SRE: [aprova com 1 clique]
IA: [executa kubectl rollout restart + cria issue]Nível 4 — Auto-Remediação IA detecta, decide e executa para classes pré-aprovadas de incidentes.
Alerta: "Serviço X com erro 503"
IA: [sem intervenção humana] escalou HPA de 3 para 6 réplicas → resolveu em 45sA maioria das empresas opera nos Níveis 1-2. Nível 3 requer auditoria robusta. Nível 4 é reservado para ações muito específicas e reversíveis.
RAG sobre Runbooks
A combinação mais poderosa em AIOps: RAG sobre documentação técnica específica da empresa.
# Pipeline RAG para troubleshooting
query = "Como resolver OOMKilled no namespace prod?"
# 1. Busca semântica nos runbooks indexados
runbooks_relevantes = buscar_runbooks(query, top_k=3)
# → retorna: runbook-oom.md, incidente-oom-2024-03.md
# 2. Injetar no contexto do LLM
context = '\n\n'.join([r.conteudo for r in runbooks_relevantes])
# 3. LLM responde com contexto específico
resposta = client.messages.create(
system=f"Você é um SRE. Use estes runbooks:\n\n{context}",
messages=[{'role': 'user', 'content': query}]
)Sem RAG, o LLM responde com boas práticas genéricas. Com RAG sobre os runbooks da empresa, responde com o procedimento exato que funciona para aquela infraestrutura.
Guardrails Essenciais
Todo sistema de IA em infra precisa de:
1. Dry-run antes de apply
def executar_kubectl(comando: str, dry_run: bool = True) -> str:
if dry_run:
return subprocess.run(['kubectl', '--dry-run=client', ...])
return subprocess.run(['kubectl', ...])2. Gate de aprovação para ações destrutivas
ACOES_DESTRUTIVAS = {'scale_to_zero', 'delete_deployment', 'drain_node', 'force_restart'}
def executar_acao(acao: str, args: dict) -> str:
if acao in ACOES_DESTRUTIVAS:
if not aguardar_aprovacao_humana(acao, args):
return "Ação bloqueada: aguardando aprovação"
return executar(acao, args)3. Audit log imutável
import json
from datetime import datetime
def registrar_acao(acao: str, args: dict, resultado: str, aprovado_por: str = 'auto'):
with open('audit_infra.jsonl', 'a') as f:
f.write(json.dumps({
'timestamp': datetime.utcnow().isoformat(),
'acao': acao,
'args': args,
'resultado': resultado[:500],
'aprovado_por': aprovado_por,
}) + '\n')4. Rollback automático
def executar_com_rollback(acao: str, args: dict, verificacao: callable) -> str:
estado_anterior = capturar_estado()
executar(acao, args)
if not verificacao():
restaurar_estado(estado_anterior)
return "Ação revertida: verificação falhou"
return "Ação bem-sucedida"Aprofundamento Técnico
Onde LLMs Superam Scripts Determinísticos
Análise de causa raiz em sistemas distribuídos Um script verifica condição A → executa ação A. Um LLM correlaciona: “O checkout falhou por timeout, que foi causado por pool de DB esgotado, que foi causado por uma migração que rodou às 14:31 sem índice, o que gerou full table scans.”
Compreensão de logs não estruturados Stack traces, mensagens de erro customizadas, logs de aplicações legadas — tudo em linguagem natural técnica. LLMs processam todos; scripts precisam de parsers para cada formato.
Adaptação a contexto variável O mesmo erro pode ter causas diferentes dependendo de deployment recente, load, hora do dia, dependências. LLMs raciocinam sobre contexto; scripts executam condição fixa.
Onde Scripts/Ferramentas Vencem LLMs
Execução determinística de ações: kubectl apply, terraform apply — use CLI real
Verificação de thresholds: latency > 500ms — use alertas configurados
Ações em alta frequência: HPA, auto-scaling — use regras determinísticas
Parsing estruturado de dados: métricas em Prometheus — use PromQL, não LLM
A IA é o raciocínio — as ferramentas são a execução.
Exemplos Anotados
Exemplo 1: Análise de Incidente com LLM
import anthropic
client = anthropic.Anthropic()
def analisar_incidente(logs: dict, metricas: dict) -> str:
contexto = f"""
LOGS DOS SERVIÇOS:
{json.dumps(logs, indent=2)}
MÉTRICAS ATUAIS:
{json.dumps(metricas, indent=2)}
"""
response = client.messages.create(
model='claude-haiku-4-5-20251001',
max_tokens=800,
system="""Você é um SRE sênior. Analise o incidente e produza:
1. Causa raiz identificada
2. Serviço(s) diretamente afetado(s)
3. Ações imediatas recomendadas (em ordem de prioridade)
4. Ações de longo prazo para prevenir recorrência""",
messages=[{'role': 'user', 'content': contexto}],
)
return response.content[0].text
# Uso
resultado = analisar_incidente(LOGS_SIMULADOS, METRICAS)
print(resultado)Padrões e Armadilhas
Padrões
Padrão 1: Dry-run como padrão, apply como exceção confirmada Nunca execute sem dry-run em produção. O dry-run é gratuito; um delete acidental não é.
Padrão 2: Escopo de permissões mínimo para o agente O agente precisa de kubectl get e kubectl describe para diagnóstico. Precisa de kubectl scale para mitigação. Mas não precisa de kubectl delete deployment para a maioria dos casos.
Padrão 3: Timeout em todas as ações do agente
import signal
def executar_com_timeout(acao, timeout_s=30):
signal.alarm(timeout_s)
resultado = acao()
signal.alarm(0)
return resultadoArmadilhas
⚠️ Armadilha 1: LLM “confiante” em diagnóstico incorreto LLMs raramente dizem “não sei”. Podem diagnosticar incorretamente com alta confiança. Sempre verifique empiricamente.
⚠️ Armadilha 2: Agente sem memória de ações anteriores Um agente que restartou o pod 5 vezes sem sucesso deveria escalar para humano. Adicione memória de ações anteriores para evitar loops.
⚠️ Armadilha 3: Audit log sem informações de contexto suficientes
# RUIM: o que foi deletado?
{'acao': 'kubectl delete', 'timestamp': '...'}
# BOM: contexto completo para auditoria
{'acao': 'kubectl delete pod auth-abc123', 'namespace': 'prod', 'motivo': 'OOMKilled 15x', 'aprovado_por': 'sistema', 'timestamp': '...'}Se não for realizar o laboratório, pule para o próximo capítulo.
Ponte para o Lab
Esta unidade é conceitual. O lab é exploratório:
Desenhe a arquitetura: Para seu contexto de trabalho (ou um projeto hipotético), identifique em qual nível de maturidade você operaria. Quais ações seriam Nível 3 (com gate) vs Nível 4 (automático)?
Liste runbooks candidatos: Quais documentações técnicas da empresa seriam mais valiosas indexadas para RAG? (runbooks de incidentes comuns, guias de troubleshooting, wikis de operações)
Defina guardrails: Para o seu contexto, quais ações são “destrutivas irreversíveis” e requerem aprovação humana sempre?
Agora você está pronto para o lab.