Skip to content
Da Vibe Coding à Engenharia Agêntica

Capítulo 17 — Produção também é desenvolvimento

Produção responde perguntas que staging não consegue responder

Section titled “Produção responde perguntas que staging não consegue responder”

Até aqui, construímos uma cadeia:

Intent
  ↓
Spec
  ↓
Implementation
  ↓
Evidence
  ↓
Review
  ↓
Delivery

Mas delivery não encerra o trabalho.

Quando o software começa a receber tráfego real, aparecem novas perguntas:

  • está saudável?
  • ficou mais lento?
  • erros aumentaram?
  • usuários estão abandonando o fluxo?
  • custo mudou?
  • o comportamento observado corresponde ao esperado?

Produção não é apenas destino.

É uma fonte de evidência.

Evidência de runtime

Section titled “Evidência de runtime”

No método deste livro, evidência de runtime é qualquer evidência produzida pelo comportamento real do sistema após deploy.

Pode incluir:

  • health;
  • logs;
  • metrics;
  • traces;
  • error rate;
  • latency;
  • throughput;
  • saturation;
  • business outcomes;
  • resource consumption;
  • agent/ferramenta activity quando aplicável.

O gate deste capítulo é:

uma release permanece incompleta até que seu comportamento pós-deploy seja observado e registrado.

Isso é método deste livro.

Observability

Section titled “Observability”

García descreve observability como prática transversal que torna contexto e comportamento visíveis por telemetry, monitoring, logs, traces e metrics. 1

A palavra importante é visíveis.

Sem visibilidade, operação vira adivinhação.

Monitoring e observability

Section titled “Monitoring e observability”

Monitoring responde perguntas conhecidas:

  • CPU está alta?
  • endpoint está fora?
  • error rate passou do threshold?

Observability ajuda a investigar perguntas que não foram totalmente antecipadas.

No método deste livro, ambos são necessários.

Logs

Section titled “Logs”

Logs registram eventos discretos.

Úteis para:

  • erros;
  • state transitions;
  • decisões;
  • integração externa;
  • audit events.

Um log operacional precisa ser pesquisável e contextual.

Campos úteis:

  • timestamp;
  • service;
  • version;
  • request/trace id;
  • actor;
  • event;
  • outcome;
  • error class.

Log sem contexto é ruído

Section titled “Log sem contexto é ruído”

Mensagem:

failed

é quase inútil.

Melhor:

event=payment_charge_failed
order_id=...
gateway=...
error_class=timeout
release=...
trace_id=...

O objetivo não é logar tudo.

É preservar contexto suficiente para investigação.

Metrics

Section titled “Metrics”

Metrics agregam comportamento ao longo do tempo.

Exemplos:

  • request count;
  • error rate;
  • latency percentiles;
  • queue depth;
  • retries;
  • memory;
  • tokens;
  • cost.

Metrics ajudam a detectar mudança de tendência.

Traces

Section titled “Traces”

Trace acompanha uma operação através de múltiplos componentes.

É especialmente útil quando um fluxo cruza frontend, API, service, database, queue, external provider e agent/ferramenta calls.

Agent / cognitive tracing

Section titled “Agent / cognitive tracing”

Em sistemas agênticos, podemos precisar observar também:

  • ferramenta calls;
  • retrieval;
  • contexto assembly;
  • model invocation;
  • retries;
  • branch decisions;
  • handoffs.

Isso não significa armazenar pensamento interno. Significa registrar eventos operacionais suficientes para explicar o comportamento do sistema.

AI teammate precisa de olhos

Section titled “AI teammate precisa de olhos”

Hassan argumenta que workbenches agênticos precisam de acesso seguro a sinais como logs, traces e metrics para investigar falhas e iterar sem depender de loops humanos de copy-paste. 2

Um agente que pode editar código, mas não observar resultado em runtime, continua parcialmente cego.

Human copy-paste loop

Section titled “Human copy-paste loop”

Anti-pattern:

sistema falha
↓
humano copia log
↓
envia ao agente
↓
agente pede outra métrica
↓
humano copia novamente

Esse fluxo não escala.

Read-only observability

Section titled “Read-only observability”

método deste livro:

Acesso a observability deveria ser separado de acesso de mutação.

Um agente pode precisar ler logs, consultar metrics e buscar traces sem poder alterar produção, apagar dados ou editar dashboards críticos.

Health checks

Section titled “Health checks”

Health não é uma única pergunta.

Liveness

Section titled “Liveness”

O processo está vivo?

Readiness

Section titled “Readiness”

Está pronto para receber tráfego?

Dependency health

Section titled “Dependency health”

As dependências essenciais estão utilizáveis?

Functional health

Section titled “Functional health”

Um fluxo crítico ainda funciona?

Health != correctness completa

Section titled “Health != correctness completa”

Um endpoint /health retornando 200 não prova que checkout funciona.

Health check deve ser interpretado dentro de seu escopo.

Post-deploy verification

Section titled “Post-deploy verification”

Após deploy, execute checks que confirmem o novo estado.

Exemplo:

  • version correta ativa;
  • instances healthy;
  • migration aplicada;
  • smoke test;
  • error rate normal;
  • latency dentro da faixa;
  • business event funcionando.

Runtime Evidence Record

Section titled “Runtime Evidence Record”

Artefato operacional do capítulo.

# Runtime Evidence


release_id:
artifact_digest:
deploy_time:
observation_window:


## Health
## Logs
## Metrics
## Traces
## Business Signals
## Cost
## Anomalies
## Decision

O objetivo é preservar evidência suficiente para responder: como sabemos que a release está saudável?

Expected vs observed

Section titled “Expected vs observed”

Evidência de runtime precisa de expectation.

expected p95_latency < 400 ms
observed p95_latency = 520 ms

Sem expectativa, métrica vira número sem decisão.

Baseline

Section titled “Baseline”

Antes de comparar depois, precisamos saber o antes.

Baseline pode incluir error rate, latency, CPU/memory, cost/request e conversion rate.

Release marker

Section titled “Release marker”

Dashboards e traces devem conseguir marcar quando uma release ocorreu.

Isso facilita correlação entre mudança e efeito.

Version-aware telemetry

Section titled “Version-aware telemetry”

Logs e metrics deveriam permitir identificar versão quando isso for operacionalmente importante.

Caso contrário, em rollout gradual, versões diferentes se misturam.

SLI

Section titled “SLI”

Service Level Indicator é uma medição do comportamento relevante do serviço.

Exemplos comuns:

  • availability;
  • latency;
  • correctness;
  • freshness.

Neste livro, usamos SLI como conceito operacional, não como framework obrigatório.

SLO

Section titled “SLO”

Service Level Objective define um objetivo para um indicador.

Exemplo:

99.9% das requests bem-sucedidas em 30 dias

O valor precisa representar expectativa de serviço relevante.

Error budget

Section titled “Error budget”

Error budget transforma confiabilidade em trade-off operacional.

Se o serviço está consumindo margem rapidamente, ritmo de mudança pode precisar ser reduzido.

Aqui tratamos o conceito de maneira introdutória; a fonte Google SRE continua prevista para aprofundamento futuro.

Business observability

Section titled “Business observability”

Sistema pode estar tecnicamente saudável e funcionalmente errado.

Exemplo:

  • HTTP 200;
  • latency normal;
  • CPU normal;
  • zero pedidos concluídos.

Por isso, observability pode incluir sinais de negócio.

Technical + business evidência

Section titled “Technical + business evidência”

Para checkout:

  • technical: error rate, latency;
  • business: payment success rate.

Para busca:

  • technical: response time;
  • business: zero-result rate, click-through.

Cost é propriedade operacional

Section titled “Cost é propriedade operacional”

Em sistemas com APIs, cloud e modelos, custo muda com comportamento.

Podemos observar:

  • cost/request;
  • tokens/request;
  • ferramenta calls/task;
  • compute time;
  • storage growth;
  • retry amplification.

Custo em sistemas agênticos

Section titled “Custo em sistemas agênticos”

Hassan destaca que, em escala, health e custo precisam ser observáveis para detectar falhas correlacionadas e controlar recursos e paralelismo. 3

Isso evita o anti-pattern: throughput aumenta, custo explode silenciosamente.

Cost budget

Section titled “Cost budget”

método deste livro:

Uma mission ou serviço pode ter budget operacional.

max_cost_per_task = $0.20
max_tool_calls = 30
max_runtime = 5 min

O objetivo é tornar custo parte da engenharia, não surpresa financeira posterior.

Retry amplification

Section titled “Retry amplification”

Falha transitória pode causar retry, mais carga, nova falha e mais retry.

Metrics precisam mostrar esse padrão.

Correlated failure

Section titled “Correlated failure”

Se vários agentes ou serviços falham de forma semelhante, o problema pode ser compartilhado: dependency, configuration, credential, platform, model provider ou rate limit.

Fleet-level observability ajuda a enxergar isso. 3

Friction signal

Section titled “Friction signal”

Em plataforma agêntica, também vale medir:

  • intervenção humana frequente;
  • ferramenta failure;
  • timeout;
  • missing evidência;
  • repeated escalation.

Esses sinais indicam onde a plataforma precisa evoluir.

Runtime feedback fecha o ciclo

Section titled “Runtime feedback fecha o ciclo”
Intent
  ↓
Delivery
  ↓
Runtime
  ↓
Evidence
  ↓
Learning

Produção fornece informação para próxima mudança.

Failure creates new evidência

Section titled “Failure creates new evidência”

Quando algo falha em runtime, essa observação pode virar test, gate, alert, runbook step, Spec constraint ou architecture change.

Isso será aprofundado no Capítulo 19.

Anti-pattern: dashboard sem decisão

Section titled “Anti-pattern: dashboard sem decisão”

Dashboard com 50 gráficos pode ter baixo valor.

Cada painel relevante deveria apoiar perguntas concretas: estamos saudáveis? release piorou algo? precisamos rollback?

Anti-pattern: logs sem retention strategy

Section titled “Anti-pattern: logs sem retention strategy”

Guardar tudo para sempre custa caro e pode aumentar risco de dados sensíveis.

Retention precisa considerar valor investigativo, compliance, custo e privacidade.

Anti-pattern: alerta em tudo

Section titled “Anti-pattern: alerta em tudo”

Alert fatigue reduz atenção.

Alerta deveria indicar condição que exige ação.

Anti-pattern: só infraestrutura

Section titled “Anti-pattern: só infraestrutura”

CPU e memória não bastam para explicar experiência do usuário.

Inclua sinais de comportamento relevante.

Anti-pattern: telemetry sem provenance

Section titled “Anti-pattern: telemetry sem provenance”

Se não sabemos qual release gerou o sinal, diagnóstico fica mais difícil.

Evidência de runtime deve conectar a artifact/release identity.

Anti-pattern: agente sem observability

Section titled “Anti-pattern: agente sem observability”

Se o agente precisa pedir manualmente todo log ao humano, autonomia é artificial. 2

Privacy boundary

Section titled “Privacy boundary”

Observability pode conter PII, secrets, prompts, user content e identifiers.

Portanto, telemetry também precisa de redaction, access control, retention e classification.

Observability não deve virar surveillance irrestrita

Section titled “Observability não deve virar surveillance irrestrita”

Mais dados não é sempre melhor.

A coleta deve ser proporcional à necessidade operacional.

Runtime acceptance

Section titled “Runtime acceptance”

método deste livro:

production-promoted
  ↓
observed
  ↓
runtime-accepted

Critérios possíveis:

  • smoke PASS;
  • health normal;
  • ausência de regressão relevante em error/latency;
  • KPI crítico estável;
  • cost dentro do budget.

Runtime acceptance responde “o estado promovido está saudável o suficiente para continuar?”

Quando a resposta é não, observability precisa acionar containment ou recovery. Um threshold pode, por exemplo, pausar rollout ou disparar rollback segundo policy explícita. O detalhe do mecanismo pertence ao próximo capítulo.

Da observação à recuperação

Section titled “Da observação à recuperação”

Operations detecta divergência entre esperado e observado. Recovery começa quando essa divergência exige ação para limitar dano ou restaurar estado aceitável.

Essa fronteira é importante:

  • Observability produz sinais;
  • runtime acceptance interpreta esses sinais;
  • recovery executa containment, rollback, restore, failover ou compensation.

O próximo capítulo começa exatamente nesse ponto: Falha, rollback e recuperação.

Fronteira de confiança

Section titled “Fronteira de confiança”

Observability cruza uma boundary entre produção e quem investiga. Logs, traces e metrics podem conter dados sensíveis e precisam de acesso scoped. Read-only observability deve ser separada, quando possível, de permissões de mutação em produção.

Evidência exigida

Section titled “Evidência exigida”

Toda release relevante deve produzir evidência de runtime ligada à release/artifact identity. Health, error rate, latency, traces, business signals e custo precisam ser comparados com expectativas ou baseline antes de declarar runtime acceptance.

Rollback e recuperação

Section titled “Rollback e recuperação”

Runtime telemetry precisa alimentar rollback triggers e incident response. Um sinal que detecta degradação mas não está conectado a uma ação ou escalação produz informação, não necessariamente proteção.

Proveniência das fontes

Section titled “Proveniência das fontes”

Rastreabilidade deste capítulo:

  • CLM-059 — García, observability via telemetry, monitoring, logs, traces e metrics;
  • CLM-060 — Hassan, acesso seguro a observability signals para investigação autônoma;
  • CLM-061 — Hassan, fleet health e cost observability para falhas correlacionadas e resource control.

Runtime Evidence Record, runtime acceptance, cost budget e version-aware telemetry como disciplina integrada são método deste livro.

Os comparáveis de Nissl e Jayaratchagan permanecem fonte limitada e não foram usados como autoridade factual.

Fontes de acesso limitado não foram usadas como autoridade factual neste capítulo.

Recursos complementares

Section titled “Recursos complementares”

Recursos relacionados:

  • Runtime Evidence Record template;
  • post-deploy verification checklist;
  • health-check matrix;
  • runtime acceptance template;
  • cost budget template;
  • rollback-trigger worksheet;
  • futura visualização PCC de release → runtime signals → decision.

Footnotes

Section titled “Footnotes”

  1. Boni García, Context Engineering (MEAP, 2026), 1.1.2 The context engineering stack — Observability, p. 10. Rastreabilidade interna: CLM-059. ↩

  2. Ahmed E. Hassan, Agentic Software Engineering (2026), Practice 4: Build the AI teammate execution plane for fast, self-sufficient work, pp. 253–254. Rastreabilidade interna: CLM-060. ↩ ↩2

  3. Ahmed E. Hassan, Agentic Software Engineering (2026), Practice 8: Add an enterprise command center for fleet observability and resource control, p. 255. Rastreabilidade interna: CLM-061. ↩ ↩2