Bellacosa Mainframe monitorando a ia

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🔭 ALAN TURING E O SDSF DOS AGENTES — O QUE DIABOS A INTELIGÊNCIA ARTIFICIAL ESTÁ FAZENDO AGORA?

Observabilidade, logs, métricas, traces, spans, OpenTelemetry, tokens, custos, latência, estados, workflows, auditoria, SDSF, JES2, SMF, RMF, CICS — e o dia em que Alan Turing descobriu que “AGENT RUNNING...” era quase tão informativo quanto um operador responder “sei lá, está processando”.

---

🎬 PRÓLOGO — O ROBÔ ESTAVA “TRABALHANDO”

Alan Turing entrou novamente no CPD.

O pequeno agente de IA estava diante de um terminal.

Na tela:

AGENT STATUS
============

RUNNING...

Turing esperou.

Um minuto.

Dois minutos.

Cinco minutos.

Continuava:

RUNNING...

O jovem programador COBOL apareceu carregando café.

— Bom dia, professor.

Turing apontou para a tela.

— O que ele está fazendo?

— Trabalhando.

— Em quê?

— Não sei.

— Em qual etapa?

— Também não sei.

— Encontrou algum erro?

— Acho que não.

— Quanto já gastou?

— Não faço ideia.

— Está esperando alguma coisa?

— Talvez.

Turing olhou novamente para:

RUNNING...

e sentenciou:

— Então vocês construíram uma máquina capaz de tomar decisões, utilizar ferramentas e executar ações... mas colocaram nela a mesma lâmpada de “ocupado” de uma impressora de 1987?

Silêncio.

No fundo do CPD alguém apertou Enter tentando não rir.

Turing puxou uma cadeira.

— Abra o SDSF.

E assim começou nossa terceira aventura.

---

🏛️ CAPÍTULO 1 — NO MAINFRAME, “ESTÁ RODANDO” NUNCA FOI RESPOSTA SUFICIENTE

Imagine que você submeta:

//PAYROLL JOB ...
//STEP01  EXEC PGM=PAYCALC
//STEP02  EXEC PGM=REPORT
//STEP03  EXEC PGM=ARCHIVE

Você pergunta ao operador:

Como está o PAYROLL?

E ele responde:

Está fazendo coisas.

Provavelmente essa resposta não sobreviveria muitos minutos no CPD.

Queremos saber:

JOBNAME
JOBID
OWNER
STATUS
QUEUE
STEP
RETURN CODE
OUTPUT

O SDSF existe justamente nesse universo de monitorar e controlar processamento z/OS. A documentação da IBM descreve painéis capazes de acompanhar jobs desde a fila de entrada do JES, passando pelo processamento, até as filas de saída; o painel ST, por exemplo, é central para gerenciamento de jobs e output.

Podemos encontrar algo como:

JOBNAME   JOBID      OWNER      ST      CC
PAYROLL   JOB12345   BELLACOSA  OUTPUT  0000
FATURAM   JOB12346   FINANCE    OUTPUT  0008
BACKUP    JOB12347   OPERADOR   EXEC
REPORT    JOB12348   BELLACOSA  ABEND   S0C7

Isso muda tudo.

Não sabemos apenas:

“O computador está ocupado.”

Sabemos quem, o quê, onde e em qual estado.

É exatamente esse salto que precisamos fazer com agentes.

---

🤖 CAPÍTULO 2 — O AGENTE PRECISA DE UM JOBNAME

Imagine vários agentes corporativos:

AGENT-PAYROLL
AGENT-REPORT
AGENT-SUPPORT
AGENT-COBOL
AGENT-AUDIT

Agora imagine dezenas de execuções simultâneas.

Dizer:

AGENT RUNNING

é quase inútil.

Precisamos de identidade para a execução.

Por exemplo:

AGENT        RUN-ID       OWNER       STATUS
REPORT       A000471      VAGNER      RUNNING
COBOLSCAN    A000472      DEVTEAM     WAITING
SUPPORT      A000473      SERVICE     APPROVAL
PAYROLL      A000474      FINANCE     FAILED

Perceba a analogia:

JOBNAME  → AGENT/WORKFLOW
JOBID    → RUN-ID
OWNER    → USUÁRIO/SERVIÇO
STATUS   → ESTADO DO WORKFLOW

Não são equivalências técnicas perfeitas.

São equivalências conceituais.

E são extremamente úteis para pensar UX.

Porque quando alguém disser:

O agente fez besteira!

a primeira pergunta deveria ser:

Qual execução?

---

🚦 CAPÍTULO 3 — “RUNNING” NÃO É UM ESTADO SUFICIENTE

Um agente pode estar em situações completamente diferentes enquanto a interface simplesmente mostra:

RUNNING

Ele pode estar:

PLANNING
READING
WAITING_TOOL
EXECUTING_TOOL
RETRYING
WAITING_APPROVAL
PAUSED
ROLLING_BACK
COMPLETED
FAILED
CANCELLED

Isso importa muito.

Compare:

AGENT: REPORT
STATUS: RUNNING

com:

AGENT: REPORT
RUN-ID: A000471

OBJECTIVE:
Consolidar relatórios de setembro

CURRENT STATE:
WAITING_APPROVAL

CURRENT STEP:
5/7 - Enviar relatório financeiro

WAITING FOR:
Aprovação humana

WAIT TIME:
00:03:42

Agora sabemos o que está acontecendo.

Talvez o agente nem esteja consumindo processamento significativo.

Está simplesmente esperando alguém.

Uma boa interface precisa diferenciar:

TRABALHANDO

de:

ESPERANDO

e de:

TRAVADO

Parece óbvio.

Até você encontrar sistemas que tratam os três como:

PROCESSING...

---

🪵 CAPÍTULO 4 — LOG: O DIÁRIO DE BORDO

Primeiro instrumento da nossa caixa de observabilidade:

LOG.

Log é basicamente o registro de eventos ocorridos.

O OpenTelemetry define logs como registros de eventos e suporta informações estruturadas como timestamp, severidade, corpo, atributos e também identificadores de trace e span, permitindo correlação com outros sinais.

Um log simples:

10:01:03 Agent started
10:01:04 Reading report
10:01:12 Report loaded
10:01:13 Calling model
10:01:18 Analysis completed

Já ajuda.

Mas podemos fazer melhor.

timestamp=10:01:03
agent=REPORT
run_id=A000471
event=workflow.started
owner=VAGNER

Depois:

timestamp=10:01:12
agent=REPORT
run_id=A000471
event=file.read
file=REPORT-09
status=success
duration_ms=284

Agora temos structured logging.

Em vez de texto para seres humanos lerem manualmente, possuímos campos que sistemas podem consultar.

Podemos perguntar:

event = tool.error

ou:

run_id = A000471

ou:

duration_ms > 5000

Isso é tremendamente mais poderoso.

---

📜 CAPÍTULO 5 — O SYSOUT DO ROBÔ

Aqui o programador COBOL começa a sorrir.

Porque o conceito não é estranho.

Quando um job termina, frequentemente vamos investigar sua saída.

SDSF permite navegar pelos outputs de jobs e pelas informações de processamento; historicamente, muito output destinado ao JES sequer precisava ser fisicamente impresso — podia ser inspecionado no SDSF.

Nosso agente também deveria deixar evidências.

Algo como:

RUN A000471

AGENT........ REPORT
START........ 10:01:03
END.......... 10:02:44
DURATION..... 00:01:41

MODEL CALLS.. 4
TOOL CALLS... 7
FILES READ... 12
FILES WRITE.. 1
WARNINGS..... 2
ERRORS....... 0

RESULT........ COMPLETED_WITH_WARNINGS

Não precisamos literalmente transformar agentes em JES.

Mas precisamos abandonar a filosofia:

“Ele respondeu, então provavelmente deu tudo certo.”

---

📊 CAPÍTULO 6 — MÉTRICA NÃO É LOG

Turing escreve:

LOG
≠
METRIC

Log responde muito bem a:

O que aconteceu?

Métrica responde melhor a:

Quanto está acontecendo?

Por exemplo:

agent_runs_total = 15420

agent_failures_total = 327

average_duration = 18.4 s

tool_calls_total = 92481

approval_wait_time = 47.2 s

input_tokens = ...
output_tokens = ...

OpenTelemetry é hoje um framework vendor-neutral para instrumentar, gerar, coletar e exportar telemetria, incluindo traces, metrics e logs.

Para aplicações GenAI, suas convenções incluem atributos relacionados ao uso de tokens e identificação de workflows/agentes; essas convenções específicas continuam evoluindo, portanto não devemos tratá-las como uma pedra gravada para toda a eternidade.

---

💰 CAPÍTULO 7 — AGORA A TELEMETRIA TEM CONTA PARA PAGAR

No mainframe sempre aprendemos que recurso computacional custa.

CPU.

I/O.

Storage.

Elapsed time.

Consumo não é abstração filosófica.

Com IA, aparece outro recurso:

TOKENS

Uma execução pode fazer:

CALL 1 → modelo
CALL 2 → modelo
CALL 3 → ferramenta
CALL 4 → modelo
CALL 5 → ferramenta
CALL 6 → modelo

Talvez obtenha a resposta correta.

Mas quanto custou?

Um dashboard poderia mostrar:

RUN-ID............ A000471
MODEL CALLS....... 8
INPUT TOKENS...... 34,812
OUTPUT TOKENS..... 8,401
TOOL CALLS........ 14
DURATION.......... 01:47
ESTIMATED COST.... ...

As convenções de GenAI do OpenTelemetry contemplam métricas e atributos de uso de tokens; a observabilidade pode então ajudar a detectar prompts excessivamente grandes, regressões de latência e padrões de consumo.

E aqui aparece um velho fantasma mainframe:

EFICIÊNCIA.

Um agente que consegue resolver uma tarefa em:

3 chamadas

pode ser operacionalmente preferível a outro que precisa:

37 chamadas

mesmo que ambos terminem corretamente.

---

⏱️ CAPÍTULO 8 — LATÊNCIA: O AGENTE DEMOROU, MAS ONDE?

Imagine:

TOTAL = 18 segundos

Isso não nos diz muita coisa.

Talvez:

LLM............. 2 s
DATABASE........ 1 s
API............. 1 s
FILE............ 1 s

Então onde foram parar os outros 13 segundos?

Precisamos decompor.

É aí que entramos no mundo do distributed tracing.

---

🧵 CAPÍTULO 9 — TRACE: SIGA O FIO DE ARIADNE

Imagine uma execução completa:

Usuário
  ↓
Agente
  ↓
LLM
  ↓
Busca
  ↓
Db2
  ↓
LLM
  ↓
API
  ↓
Resultado

Um trace acompanha a operação através dessas etapas.

Dentro dele encontramos spans.

Podemos imaginar:

TRACE A000471
│
├─ SPAN 1 invoke_agent ........ 18.2s
│
├─ SPAN 2 plan ................  1.1s
│
├─ SPAN 3 model_call ..........  2.4s
│
├─ SPAN 4 search_documents ....  4.8s
│
│   ├─ SPAN 5 api_call ........  3.9s
│   └─ SPAN 6 parse ...........  0.7s
│
├─ SPAN 7 analyze .............  5.2s
│
└─ SPAN 8 write_report ........  1.4s

Agora descobrimos:

Ahá!

A busca documental está custando quase cinco segundos.

Um span representa uma execução individual de uma operação significativa dentro de um trace; as convenções do OpenTelemetry padronizam atributos para facilitar correlação entre tecnologias diferentes.

---

🔬 CAPÍTULO 10 — TRACE É O “QUAL STEP ESTÁ DEMORANDO?” DO MUNDO DISTRIBUÍDO

Um programador batch entende isso rapidamente.

Imagine:

STEP01  00:00:01
STEP02  00:00:02
STEP03  00:14:37
STEP04  00:00:01

Onde investigar?

Não precisa chamar Sherlock Holmes.

STEP03

Tracing faz algo conceitualmente semelhante em sistemas distribuídos.

Mas existe uma complicação.

Um agente pode decidir dinamicamente qual ferramenta chamar.

Portanto duas execuções do mesmo objetivo podem seguir caminhos diferentes.

RUN A
Agent
 ├─ LLM
 ├─ Search
 ├─ Db2
 └─ Report

enquanto:

RUN B
Agent
 ├─ LLM
 ├─ Search
 ├─ API
 ├─ Search novamente
 ├─ LLM
 └─ Report

Agora tracing deixa de ser luxo.

Torna-se instrumento para entender o caminho realmente escolhido.

---

🧠 CAPÍTULO 11 — O AGENTE POSSUI UM “STEP” QUE NÃO EXISTIA NO JCL

No JCL tradicional, normalmente declaramos etapas.

//STEP01 EXEC PGM=A
//STEP02 EXEC PGM=B
//STEP03 EXEC PGM=C

O agente pode raciocinar:

Talvez A.

Não.

Preciso consultar B.

Resultado incompleto.

Vou tentar C.

Agora preciso voltar para A.

Isso é poderoso.

Mas torna a execução menos previsível.

Portanto precisamos registrar:

OBJETIVO
↓
DECISÃO
↓
FERRAMENTA ESCOLHIDA
↓
RESULTADO
↓
PRÓXIMA DECISÃO

Não precisamos — nem devemos — exigir exposição irrestrita de raciocínio interno privado do modelo.

Precisamos registrar decisões e eventos operacionalmente relevantes.

Por exemplo:

STEP 4
ACTION: customer_lookup
REASON: Dados insuficientes para validar pedido
RESULT: 1 customer found
NEXT: order_lookup

Isso é auditável e útil sem transformar telemetria em uma descarga indiscriminada de conteúdo interno.

---

🔗 CAPÍTULO 12 — TRACE ID: O CPF DA EXECUÇÃO

Imagine receber:

ERROR 500

Fantástico.

Onde?

Quando?

Para quem?

Em qual execução?

Precisamos de correlação.

Um identificador como:

trace_id = 7A91...

pode acompanhar uma operação através de vários componentes.

E então um log pode carregar:

TraceId
SpanId

O modelo de logs do OpenTelemetry prevê justamente essa correlação, permitindo conectar registros a traces e spans.

Assim podemos sair de:

ERROR: timeout

para:

RUN A000471
TRACE 7A91
SPAN DB2_QUERY
ERROR timeout

Agora temos pista.

---

🚨 CAPÍTULO 13 — MÉDIA É O MIMIC DA OBSERVABILIDADE

Você olha o dashboard:

Average latency = 2 seconds

Maravilhoso.

Só que alguns usuários esperam 40 segundos.

A média esconde caudas.

Por isso sistemas modernos frequentemente observam percentis:

p50
p95
p99

Exemplo:

p50 = 1.4 s
p95 = 5.8 s
p99 = 21.7 s

Agora percebemos que uma pequena parcela das execuções sofre muito.

Isso vale especialmente para agentes porque workflows podem variar enormemente.

Uma execução consulta duas ferramentas.

Outra consulta vinte.

A média olha para ambas e diz:

Está tudo razoável.

O p99 começa a gritar no corredor.

---

❤️ CAPÍTULO 14 — MÉTRICAS DO AGENTE NÃO DEVEM SER APENAS TÉCNICAS

Imagine este dashboard:

CPU........ OK
MEMORY..... OK
LATENCY.... OK
ERRORS..... 0

Excelente.

Mas o agente resolveu o problema?

Precisamos também de métricas funcionais.

Por exemplo:

TASK SUCCESS RATE

HUMAN ESCALATION RATE

ROLLBACK RATE

APPROVAL REJECTION RATE

RETRY RATE

TOOL FAILURE RATE

AVERAGE STEPS PER TASK

COST PER SUCCESSFUL TASK

E aqui aparece uma métrica especialmente interessante:

TASK COMPLETED

não deveria significar apenas:

O workflow chegou ao último nó.

Deveria significar:

O critério de sucesso foi realmente atingido.

É a diferença entre:

MAXCC=0000

e:

O relatório contém os números corretos.

Velho problema.

Roupa nova.

---

🧾 CAPÍTULO 15 — OBSERVABILIDADE NÃO É AUDITORIA

Turing escreve no quadro:

OBSERVABILIDADE
≠
AUDITORIA

Observabilidade pergunta:

O que está acontecendo com o sistema?

Auditoria pergunta:

Quem fez o quê, quando, com qual autoridade e qual foi o resultado?

Exemplo operacional:

tool_call duration=840ms

Isso é ótimo para observabilidade.

Mas uma trilha de auditoria pode precisar:

AGENT........ AGENT-CREDIT
RUN-ID....... A001991
REQUESTER.... USER471
ACTION....... CREDIT_LIMIT_CHANGE
CUSTOMER..... 98127
OLD_VALUE.... 10000
NEW_VALUE.... 15000
APPROVER..... MANAGER08
TIMESTAMP.... 14:32:11
RESULT....... SUCCESS

Agora podemos reconstruir o evento.

Auditoria é particularmente importante quando o agente age em vez de apenas responder.

---

🔐 CAPÍTULO 16 — CUIDADO: OBSERVABILIDADE TAMBÉM PODE VAZAR SEGREDOS

Aqui aparece uma armadilha enorme.

Você decide:

Quero registrar tudo!

Prompt.

Resposta.

Documentos.

Argumentos das ferramentas.

Resultados.

Fantástico para debugging.

Talvez terrível para segurança.

Logs podem acabar contendo:

dados pessoais
segredos comerciais
credenciais
tokens
informação financeira
código proprietário
documentos confidenciais

A própria documentação de observabilidade GenAI chama atenção para o fato de que conteúdo de mensagens e tool calls pode ser capturado quando habilitado, enquanto implementações podem permitir desativar a exportação desse conteúdo.

Portanto:

Observabilidade não significa registrar tudo indiscriminadamente.

Precisamos pensar em:

REDACTION
MASKING
SAMPLING
RETENTION
ACCESS CONTROL
ENCRYPTION

O log também é dado.

E dado precisa de governança.

---

🧹 CAPÍTULO 17 — NÃO TRANSFORME O LOG NUM DEPÓSITO DE LIXO

Outro clássico.

DEBUG 1
DEBUG 2
ENTROU AQUI
PASSOU AQUI
TESTE
XYZ
AAAA

😂

Todo programador já encontrou algum parente dessa criatura.

Logs úteis precisam responder perguntas.

Uma boa estrutura pode incluir:

timestamp
severity
service
agent
run_id
trace_id
span_id
event
tool
duration
status
error_type

E usar níveis coerentes:

DEBUG
INFO
WARN
ERROR

Não transforme tudo em:

ERROR

senão o erro perde significado.

É o equivalente moderno de um painel inteiro piscando vermelho.

Depois de quinze minutos ninguém mais olha.

---

🌉 CAPÍTULO 18 — OPENTELEMETRY: UMA LÍNGUA COMUM

Em sistemas distribuídos temos:

Java
Python
Node
API Gateway
Kubernetes
Db2
MQ
CICS
Cloud
Mainframe
LLM
Agent

Cada componente poderia produzir telemetria de maneira completamente diferente.

Correlação viraria pesadelo.

OpenTelemetry tenta fornecer uma linguagem e arquitetura vendor-neutral para sinais de observabilidade, especialmente traces, metrics e logs.

Podemos imaginar:

APLICAÇÕES
     ↓
INSTRUMENTAÇÃO
     ↓
OpenTelemetry
     ↓
COLLECTOR
     ↓
BACKEND DE OBSERVABILIDADE

O Collector pode receber, processar e exportar telemetria.

O objetivo não é:

“Comprar um dashboard bonito.”

É:

Padronizar a forma de produzir e transportar evidência operacional.

---

🏷️ CAPÍTULO 19 — CONVENÇÕES SEMÂNTICAS: CHAME A MESMA COISA PELO MESMO NOME

Imagine:

Sistema A:

duration

Sistema B:

elapsed

Sistema C:

execution_time

Sistema D:

how_long_this_thing_took

😂

Agora tente construir um dashboard corporativo.

Convenções semânticas procuram padronizar nomes e significados para operações e dados observáveis. O OpenTelemetry mantém convenções para traces, métricas, logs, profiles e resources.

No universo GenAI isso é especialmente importante.

Queremos poder falar de conceitos como:

agent
model
operation
tool
token usage
workflow

de maneira consistente.

As convenções GenAI ainda estão evoluindo, o que é natural numa área que também está mudando rapidamente.

---

🧬 CAPÍTULO 20 — SDSF + SMF + RMF + OTEL: NÃO SÃO A MESMA COISA

Aqui precisamos evitar uma simplificação perigosa.

Não podemos dizer:

SDSF = OpenTelemetry

Não é.

Nem:

SMF = logs
RMF = metrics

como equivalências técnicas exatas.

São tecnologias com histórias, escopos e arquiteturas diferentes.

Mas podemos construir uma ponte didática.

SDSF

Ajuda o operador a ver e controlar execução.

SMF

Produz enorme quantidade de registros operacionais e de accounting sobre atividades do sistema.

RMF

Historicamente fornece medição e análise de performance e recursos.

OpenTelemetry

Padroniza instrumentação e transporte de sinais modernos de observabilidade.

Então, pedagogicamente:

MAINFRAME
                     MUNDO DISTRIBUÍDO

SDSF        ←→       Operational UI
SMF         ←→       Telemetry records
RMF         ←→       Performance metrics
Job/Step    ←→       Trace/Span
JobID       ←→       Run/Trace correlation
SYSOUT      ←→       Logs / execution evidence

A seta significa:

“pense na função conceitual”

e não:

“são a mesma tecnologia”.

Essa diferença é importantíssima.

---

🖥️ CAPÍTULO 21 — COMO SERIA O “SDSF DOS AGENTES”?

Agora podemos desenhar.

Imagine:

AGENT OPERATIONS FACILITY
────────────────────────────────────────────────────

AGENT       RUN-ID    OWNER     STATE       TIME
REPORT      A00471    VAGNER    EXECUTING   00:01:47
COBOLSCAN   A00472    DEV       COMPLETE    00:00:38
PAYROLL     A00473    FINANCE   APPROVAL    00:03:12
SUPPORT     A00474    CRM       FAILED      00:00:09
BACKUP      A00475    OPS       RETRYING    00:00:41

Coloque:

S

ao lado de REPORT.

Abre:

OBJECTIVE
Consolidar relatórios mensais

CURRENT STEP
4/7 Analyze financial data

MODEL CALLS
5

TOOL CALLS
8

TOKENS
18,471 / 4,901

ELAPSED
00:01:47

WARNINGS
2

STATUS
EXECUTING

Agora:

L

para logs.

T

para trace.

M

para metrics.

P

para pause.

C

para cancel.

A

para approvals.

Meu Deus.

Acabamos de reinventar uma workstation operacional para agentes.

O barbudo do mainframe começa a sorrir.

---

🧰 CAPÍTULO 22 — PASSO A PASSO: INSTRUMENTANDO MENTALMENTE UM AGENTE

Mesmo que você seja um COBOL iniciante e não vá implementar OpenTelemetry amanhã, aprenda o raciocínio.

PASSO 1 — IDENTIFIQUE A EXECUÇÃO

Nunca dependa apenas de:

agent_name

Tenha algo equivalente a:

run_id
trace_id

PASSO 2 — DEFINA OS ESTADOS

Por exemplo:

QUEUED
PLANNING
RUNNING
WAITING_TOOL
WAITING_HUMAN
PAUSED
COMPLETED
FAILED
CANCELLED

PASSO 3 — REGISTRE EVENTOS IMPORTANTES

Não cada suspiro eletrônico.

Mas:

workflow.started
tool.called
tool.failed
approval.requested
approval.received
checkpoint.created
rollback.started
workflow.completed

PASSO 4 — MEÇA

latência
tokens
tool calls
retries
erros
tempo aguardando humano
custo

PASSO 5 — TRACE AS DEPENDÊNCIAS

Quando a execução atravessar:

agent → API → Db2 → MQ → CICS

preserve correlação.

PASSO 6 — PROTEJA A TELEMETRIA

Não registre segredos simplesmente porque são úteis para debugging.

PASSO 7 — DEFINA SUCESSO

Não use apenas:

DONE

Use critérios de negócio.

PASSO 8 — CONSTRUA ALERTAS ÚTEIS

Não alerte para tudo.

Alerte quando algo realmente exigir atenção.

---

🚨 CAPÍTULO 23 — O ALERTA QUE TOCA ÀS 3 DA MANHÃ

Todo sistema de observabilidade eventualmente encontra seu verdadeiro teste:

03:17.

Telefone toca.

ALERT:
AGENT FAILURE RATE > 25%

Você abre o painel.

Descobre:

Tool: CUSTOMER-API
p99 latency: 31s
Timeout rate: 38%
Retries: 4.2 per run

Agora existe hipótese.

Sem observabilidade:

A IA ficou burra.

Com observabilidade:

A API de clientes está degradada; o agente está repetindo chamadas e acumulando timeout.

Essa diferença é gigantesca.

Modelos inteligentes introduzem novas fontes de incerteza.

Não devemos atribuir todo problema ao modelo.

Pode ser:

modelo
prompt
tool
API
rede
Db2
MQ
permissão
rate limit
dados
timeout
bug

Observabilidade separa fantasmas de evidências.

---

🧙 CAPÍTULO 24 — TURING DESENHA AS QUATRO PERGUNTAS

Turing pega o giz.

Escreve:

1. O QUE ESTÁ ACONTECENDO?

Estado + logs.

2. QUANTO ESTÁ ACONTECENDO?

Métricas.

3. POR ONDE PASSOU?

Trace.

4. QUEM AUTORIZOU?

Auditoria.

O jovem COBOL acrescenta uma quinta:

5. QUANTO CUSTOU?

Turing olha.

— Muito bem.

O administrador do CPD acrescenta:

6. POSSO PARAR?

E o administrador RACF:

7. ELE PODIA FAZER ISSO?

Agora temos praticamente toda a série:

PF3
↓
POSSO PARAR?

MAXCC
↓
FUNCIONOU?

RACF
↓
PODIA FAZER?

SDSF
↓
O QUE ESTÁ FAZENDO?

---

🥚 EASTER EGG — S A00471

São 02:58.

O jovem operador vê:

AGENT       RUN-ID    STATE
REPORT      A00471    RUNNING

Digite:

S A00471

A tela abre.

CURRENT ACTION:
Searching documentation

ELAPSED:
02:47:31

FILES FOUND:
4,281,771

CURRENT DIRECTORY:
/

Silêncio.

Turing olha para o programador.

O programador olha para Turing.

O administrador de segurança derruba o café.

Alguém pergunta:

— Quem deu acesso ao filesystem inteiro?

Do fundo da sala vem uma voz:

— Foi para facilitar o protótipo.

O administrador RACF levanta lentamente da cadeira.

ICH408I

Fim do easter egg.

---

☕ EPÍLOGO — NÃO QUERO UMA IA TRANSPARENTE; QUERO UMA IA OPERÁVEL

Existe uma diferença importante.

Quando falamos em observabilidade, não estamos necessariamente exigindo enxergar todos os mecanismos internos de um modelo.

Queremos algo muito mais prático.

Queremos saber:

qual tarefa
qual execução
qual estado
qual etapa
qual ferramenta
quanto tempo
quanto recurso
qual erro
qual resultado
qual aprovação

Em outras palavras:

OPERABILIDADE.

Um agente corporativo precisa ser operável.

Precisa ser possível colocar alguém diante dele e perguntar:

O que está acontecendo?

E obter resposta melhor que:

RUNNING...

Isso parece uma discussão sobre inteligência artificial.

Mas também é uma discussão profundamente antiga sobre sistemas.

O mainframe aprendeu há décadas que executar trabalho empresarial significa deixar evidência.

Jobs possuem identidade.

Execuções possuem estados.

Etapas possuem resultados.

Output pode ser examinado.

Falhas precisam ser investigadas.

Recursos precisam ser medidos.

A IBM descreve SDSF justamente como um meio seguro de monitorar e gerenciar sistemas z/OS, jobs, output, recursos e mensagens operacionais.

O mundo distribuído acrescentou novos desafios.

Microsserviços.

APIs.

Cloud.

Containers.

Mensageria.

Agora adicionamos:

LLMs.

Tools.

RAG.

Copilotos.

Agentes.

Mas a pergunta do operador continua assustadoramente parecida.

O que diabos está acontecendo agora?

OpenTelemetry nos oferece uma linguagem moderna para parte dessa investigação, reunindo logs, métricas e traces e permitindo correlação entre componentes.

E os agentes tornam essa disciplina ainda mais importante.

Porque não estamos observando apenas software executando um caminho predeterminado.

Podemos estar observando software escolhendo dinamicamente qual caminho executar.

Quanto maior a autonomia...

maior a necessidade de evidência.

Quanto mais ferramentas disponíveis...

mais importante a correlação.

Quanto mais passos dinâmicos...

mais necessário o tracing.

Quanto maior o custo variável...

mais importantes as métricas.

Quanto maior o poder de ação...

mais importante a auditoria.

Alan Turing volta ao terminal.

A tela agora mostra:

AGENT: REPORT
RUN-ID: A00471

STATUS........ WAITING_APPROVAL
STEP.......... 6/7
ELAPSED....... 00:01:48
MODEL CALLS... 5
TOOL CALLS.... 8
WARNINGS...... 2
ERRORS........ 0

ACTION........ SEND REPORT
RISK.......... EXTERNAL ACTION
APPROVAL...... REQUIRED

[P] PAUSE
[C] CANCEL
[L] LOG
[T] TRACE
[M] METRICS
[A] APPROVE

Turing toma um gole de café.

— Melhor.

O programador pergunta:

— Agora sabemos tudo?

Turing sorri.

— Claro que não.

— Então o que sabemos?

Ele aponta para a tela.

— Sabemos onde procurar.

Para um operador, um SRE, um programador COBOL ou qualquer pessoa que já tenha passado algumas horas tentando descobrir por que um sistema parou às três da manhã...

isso já é uma diferença gigantesca.

Porque o futuro talvez esteja cheio de agentes inteligentes.

Mas quando alguma coisa der errado, alguém ainda precisará abrir uma tela e perguntar:

ST

Qual é o status?

Algumas perguntas sobrevivem a todas as revoluções tecnológicas.

READY

E, naturalmente...

há outro agente na fila.