Se o agente também publica código, observabilidade deixa de ser “painel da aplicação” e passa a incluir quem mudou o quê, com qual correlação. Log, trace e dono de serviço continuam o básico. Sem commit atribuível, sem release e sem on-call, o incidente do agente vira mistério com cara de inovação.

O agente não precisa de um APM especial no primeiro dia. Precisa entrar no mesmo contrato de telemetria do serviço: request id, deploy id, pessoa (ou bot) que aprovou o merge. Publicar sem isso é deploy anônimo. Times já sofrem deploy anônimo humano; o agente só aumenta a frequência.

O que muda quando o publisher não é só humano

Três buracos aparecem rápido:

  1. Atribuição — o commit é do bot, o merge é da pessoa. Os dois precisam estar no log de auditoria.
  2. Volume — mais PR, mais deploy, mais ruído se o alerta não tiver dono.
  3. Comportamento novo — o agente muda timeout, flag ou query. O trace tem que mostrar a versão que rodou, não a intenção do prompt.

Monitoramento e observabilidade de aplicações continua o mapa. Este texto adiciona o publisher não humano. Plataforma interna ajuda: platform engineering sem ticket eterno oferece pipeline e guarda-corpo para o agente não publicar fora do trilho.

Drift de infra no mesmo período — Terraform sem dono — piora o diagnóstico: o código da app mudou e o cluster também. Dono de serviço é a pessoa que junta as duas pontas no incidente.

Log, trace, métrica — o mínimo que o agente não pode pular

  • log de aplicação com correlação;
  • trace nas fronteiras (API, fila, downstream);
  • métrica de erro e latência do serviço que o agente tocou;
  • evento de deploy no mesmo relógio.

Não inventamos aqui o “gold standard” do seu provedor. Inventar dashboard sem dono é o anti-padrão. O mínimo é conseguir responder em cinco minutos: qual release, qual serviço, quem aprovou, o que o usuário sentiu.

Agente que gera migração de banco sem o mesmo rigor de migrate/rollback que o time humano usa é incidente anunciado. Observabilidade não substitui o limite de autonomia; ela mostra o estrago quando o limite falhou.

Ritual de incidente com publisher misto

Runbook: se o último deploy tem label de agente, o on-call abre o PR, não só o Grafana. Rollback é o mesmo botão. Blameless continua: o alvo é o processo (por que o agente pôde publicar X), não a pessoa que confiou no diff grosso.

Fevereiro é bom mês para um exercício: um deploy gerado, um alerta, um dono. Se o time não consegue o exercício, o agente não deveria publicar em produção — só em branch, com review.

Como a Tech Coders trata observabilidade na fábrica

Na fábrica de software, publicar — humano ou agente — passa por pipeline, dono de serviço e sprint de 15 dias. Não prometemos um painel único universal. Combinamos log, trace e on-call no aceite. Sustentação 24×7 precisa dessa linha do tempo; resgate de projeto costuma começar exatamente pela ausência dela.

Perguntas frequentes

Agente precisa de sampling de trace diferente?

Só se o volume quebrar o orçamento de telemetria. Comece igual ao serviço. Ajuste com evidência de custo e de lacuna, não com ferramenta nova no primeiro incidente.

Commit do bot impede auditoria?

Não, se o merge humano e o hash do release estiverem no evento de deploy. Bot sem merge rastreável impede.

Observabilidade substitui review de PR?

Não. Mostra o que passou. Review tenta impedir o que não deveria passar. Os dois.

Quem é o dono de serviço se o agente “é do time de IA”?

O dono do serviço de negócio que quebrou. Time de IA sem on-call no produto é buraco. Nomeie na página de serviço.