Frameworks de prompt para DevOps: 5 modelos que funcionam

Comecei uma pós-graduação em AIOps este ano com a galera da DevOps PRO e o mestre Fabricio Veronez. Quando chegou o módulo de engenharia de prompt, confesso que torci o nariz. Parecia um módulo bobo, trivial, coisa para quem está começando. Framework para escrever pergunta? Aí voltei para o meu dia a dia de SRE, olhei os prompts que eu mesmo mandava para a IA (metade deles começava com “me ajuda com…”) e entendi por que as respostas vinham genéricas: o problema não era o modelo, era o pedido.

A resposta curta, para quem chegou aqui pelo Google: frameworks de prompt são estruturas fixas para organizar o que você pede a uma IA. A diferença entre eles está em qual parte do pedido carrega o peso. Os cinco mais úteis para quem trabalha com infraestrutura:

• R-T-F (Role, Task, Format): o peso está no formato da saída
• T-A-G (Task, Action, Goal): o peso está na meta mensurável
• B-A-B (Before, After, Bridge): o peso está no estado atual e no desejado
• C-A-R-E (Context, Action, Result, Example): o peso está no padrão da casa
• R-I-S-E (Role, Input, Steps, Expectation): o peso está na sequência de passos

Neste post eu passo pelos cinco, cada um com um exemplo do tipo de problema que já enfrentei e documentei aqui no blog: tuning de Zabbix, pods travados no EKS, limpeza de branch no Git. Nada de exemplo de receita de bolo. Bora lá!

O que um framework de prompt resolve (e o que não resolve)

Um framework de prompt não deixa o modelo mais inteligente. O que ele faz é obrigar VOCÊ a entregar o contexto que o modelo precisa, na ordem certa, sem esquecer pedaço. É a mesma lógica de um runbook: o plantonista sênior resolve sem runbook, mas com runbook qualquer um do time resolve, e sempre do mesmo jeito.

As documentações oficiais de prompt engineering, como o guia da Anthropic e o guia da OpenAI, convergem nos mesmos princípios: dar papel, dar contexto, dar exemplos, definir o formato da saída. Os frameworks abaixo são jeitos de empacotar esses princípios para não depender de memória às 3h da manhã com produção fora do ar.

O que framework nenhum resolve: pedido errado. Se você não sabe o que quer, a IA também não.

R-T-F: quando o formato da saída manda

R-T-F é Role, Task, Format: quem a IA deve ser, o que deve fazer e em que formato entregar. É o framework que eu mais uso, porque a maioria das tarefas de DevOps tem saída de formato conhecido: um script, um manifest, uma tabela.

Exemplo real: eu mantenho um script de limpeza de branches remotas no Git que nasceu de uma dor repetida. Se fosse pedir hoje para uma IA, o prompt seria assim:

# Role
Você é um engenheiro DevOps sênior que escreve shell script defensivo
para rodar em pipeline.
# Task
Escreva um script Bash que liste branches remotas já mergeadas na main
com mais de 30 dias sem commit e as delete do remote.
# Format
Script Bash comentado, com dry-run por padrão e flag --execute para
aplicar de verdade. Saída em duas colunas: branch e data do último commit.

Repare no Format: dry-run por padrão. Esse detalhe não é estética, é o que separa um script que você roda tranquilo de um que apaga branch de colega na sexta-feira. Deu ruim? Com dry-run, não deu.

T-A-G: quando a meta manda

T-A-G é Task, Action, Goal: a tarefa, como executar e, principalmente, qual resultado mensurável define sucesso. Uso quando o problema é de análise e o que muda tudo é a restrição de chegada.

Quem leu meu post sobre Zabbix com poller processes acima de 75% de uso sabe que tuning de monitoramento é um jogo de restrições: você não pode simplesmente jogar hardware no problema. Um prompt T-A-G para aquele cenário:

# Task
Analise um Zabbix Server com o alerta "poller processes more than 75% busy"
disparando várias vezes ao dia.
# Action
Liste as causas mais prováveis em ordem de probabilidade e, para cada uma,
o parâmetro de configuração envolvido (StartPollers, CacheSize, intervalos
de coleta dos itens) e como validar com dados internos do próprio Zabbix.
# Goal
Plano de tuning aplicável em uma janela de manutenção de 30 minutos, sem
upgrade de hardware, que traga o uso dos pollers para baixo de 60%.

Sem o Goal, a resposta vem como consultoria de vendor: “considere aumentar recursos”. Com o Goal, o modelo é obrigado a priorizar o que cabe na sua janela e no seu orçamento. É o componente que transforma resposta em plano.

B-A-B: quando o antes e o depois mandam

B-A-B é Before, After, Bridge: descreva o estado atual, descreva o estado desejado e peça a ponte entre os dois. É o framework natural de migração, upgrade e modernização, que é basicamente a vida de quem opera Kubernetes gerenciado.

Já contei aqui a experiência de fazer upgrade de EKS com rollback no radar, em ambiente PCI e com prazo de compliance apertado. Um prompt B-A-B para planejar um upgrade desse tipo:

# Before
Cluster EKS 1.32 com managed node groups, add-ons vpc-cni, coredns e
kube-proxy gerenciados, Karpenter para nodes de workload e cerca de 40
serviços em produção. Janela de manutenção mensal de 2 horas.
# After
Cluster em 1.33 com todos os add-ons compatíveis, sem downtime perceptível
para os serviços e com critério objetivo de rollback definido antes de começar.
# Bridge
Monte o plano de upgrade em fases: pré-checks de API deprecada, ordem
correta entre control plane, add-ons e node groups, validação por fase e
o ponto exato onde o rollback deixa de ser possível.

O pulo do gato do B-A-B é que descrever bem o Before dói. Você é obrigado a admitir o que o seu ambiente É, não o que deveria ser. Mas é exatamente essa honestidade que faz a ponte vir aterrissada na sua realidade, e não num cluster de tutorial.

C-A-R-E: quando o padrão da casa manda

C-A-R-E é Context, Action, Result, Example. O elemento que o diferencia é o Example: você cola um artefato existente e o modelo replica o padrão. É o framework certo quando a resposta tecnicamente correta ainda pode estar errada para a SUA casa, porque não segue a convenção do time.

Exemplo com monitoramento, na linha do que fiz no post do alarme de CloudWatch para detectar horário incorreto no Linux:

# Context
Monitoramos instâncias Linux na AWS com CloudWatch. Todo alarme do time
segue convenção de nome "equipe-servico-sintoma" e notifica um tópico SNS
que aciona o plantão.
# Action
Crie o alarme de CloudWatch para detectar divergência de horário (drift de
NTP) acima de 5 segundos nas instâncias.
# Result
Definição do alarme em Terraform, mais um parágrafo de runbook explicando
o que o plantonista verifica primeiro.
# Example
Alarme existente, como referência de padrão:
resource "aws_cloudwatch_metric_alarm" "sre_api_latencia" {
  alarm_name  = "sre-api-latencia-p99"
  ...
}

Sem o Example, você recebe um alarme bonito e fora do padrão, e vai gastar mais tempo adaptando do que gastaria escrevendo. Com o Example, o modelo captura o que nenhuma instrução textual captura direito: as decisões implícitas que o time já tomou.

R-I-S-E: quando o procedimento manda

R-I-S-E é Role, Input, Steps, Expectation. É o framework mais verboso dos cinco, e é proposital: ele existe para tarefas procedurais onde a ORDEM dos passos importa. Runbook, resposta a incidente, checklist de go-live.

Meu caso de uso favorito: transformar uma investigação que já vivi em runbook para o time. Quando escrevi sobre pods travados em ContainerCreating com Karpenter, a solução envolvia uma sequência específica de verificações. Um R-I-S-E para gerar esse runbook:

# Role
Você é um SRE sênior especialista em Kubernetes e Karpenter escrevendo
runbook para plantonistas que não conhecem o cluster a fundo.
# Input
- Sintoma: pods presos em ContainerCreating, Karpenter provisiona o node
  mas o pod não sobe
- Ambiente: EKS com Karpenter, ferramentas disponíveis: kubectl e aws cli
- Suspeitos conhecidos: limite de ENIs/IPs por instância, CNI, volumes
# Steps
1. Confirmar o estado dos pods e coletar os eventos (describe)
2. Verificar se o node provisionado registrou no cluster
3. Checar alocação de IPs do VPC CNI no node
4. Validar attach de volumes, se o pod usa PVC
5. Definir mitigação imediata e correção definitiva
# Expectation
Runbook em Markdown com o comando pronto em cada passo, o resultado
esperado ao final de cada verificação e critério objetivo de escalação.

A diferença para o R-T-F é sutil mas real: no R-T-F eu digo o que quero de saída; no R-I-S-E eu digo o CAMINHO que a análise deve percorrer. Para runbook, quem define os passos sou eu, que já me queimei com esse problema. A IA formata e completa; a cicatriz é minha.

Foi numa resposta a incidente complexo que essa estrutura me pagou de volta: a documentação que costumava consumir uma tarde inteira de reconstrução de timeline e escrita saiu em menos de uma hora, com a IA organizando os artefatos que eu entreguei e eu revisando cada afirmação antes de circular. O ganho não foi a IA escrever por mim; foi eu não começar do zero.

Qual framework usar: minha regra prática

Depois de rodar os cinco em exercícios da pós e em tarefa real, minha regra prática cabe em cinco perguntas, na ordem:

Na dúvida entre dois, escolha o que te força a escrever o que você tem preguiça de escrever. Se você está adiando descrever o ambiente atual, é B-A-B. Se está adiando definir o que é sucesso, é T-A-G. O framework certo é o que ataca a sua omissão, não o que rende o prompt mais bonito.

Perguntas que sempre aparecem

Preciso decorar os cinco?

Não. Decore a lógica: papel, contexto, exemplo, formato, meta. Os frameworks são combinações disso com nome bonito. Eu mantenho os esqueletos num arquivo de snippets e preencho na hora; depois de algumas semanas, você monta de cabeça. E eles são agnósticos de modelo: eu uso muito o Claude no dia a dia, mas o mesmo esqueleto funciona no ChatGPT(Gosto de usar com os GPT’s lá) e no Gemini. O que muda a qualidade da resposta é a estrutura do pedido, não o logo da ferramenta.

Framework de prompt evita alucinação?

Diminui, não evita. Quanto mais contexto real você dá (versões, limites, configuração atual), menos espaço o modelo tem para inventar. Mas saída de IA em infraestrutura se trata como pull request de estagiário: pode estar ótima, e você revisa linha por linha do mesmo jeito antes de aplicar em produção.

Isso não é só para quem está começando?

Minha leitura é o contrário, e o motivo é simples: framework de prompt não adiciona conhecimento, ele transporta o SEU. Quem está começando ganha estrutura, claro. Mas o iniciante esbarra em dois limites: tem pouco contexto para injetar (não sabe quais passos o runbook deveria ter, nem qual é o padrão da casa) e tem pouca bagagem para auditar o que sai do outro lado, e resposta de IA erra com muita confiança. O sênior tem os dois lados: a cicatriz que vira Steps, o padrão que vira Example, a meta que vira Goal, e o olho treinado para pegar a resposta errada com cara de certa. IA sem o seu contexto devolve a média da internet. Com o seu contexto, devolve algo que parece feito por alguém do seu time. Os cinco nomes esquisitos deste post são só o mecanismo de transporte.

Por isso, a cobrança que passa a fazer sentido num time de operações não é “você usou IA?”, e sim “que contexto você deu para ela?”. Prompt sem contexto é loteria. Framework é o jeito de garantir que o contexto embarca.