 |
| Bellacosa Mainframe e a observabilidade no mundo mainframe |
☕ Um Café no Bellacosa Mainframe
🕵️ MARVIN BOGGS E A CONSPIRAÇÃO DAS LUZES VERDES
SMF, RMF, WLM, CICS, Db2, IMS, MQ, métricas, logs, traces, OpenTelemetry, Prometheus, Grafana, AIOps — e o dia em que Marvin descobriu que todos os dashboards estavam verdes justamente quando os clientes começaram a reclamar.
🎬 PRÓLOGO — NÃO CONFIE NA LUZ VERDE
O telefone tocou às 03:17.
O jovem programador COBOL acordou assustado.
— Produção?
Do outro lado da linha veio uma resposta curta:
— Os clientes estão reclamando que as autorizações estão demorando.
Cinco minutos depois ele estava conectado ao ambiente.
CPU?
Normal.
CICS?
UP.
Db2?
UP.
MQ?
UP.
z/OS?
UP.
O dashboard corporativo parecia uma árvore de Natal ao contrário.
Tudo verde.
O programador respirou aliviado.
— Não é mainframe.
Uma voz surgiu atrás dele.
— É exatamente isso que eles querem que você pense.
O programador quase caiu da cadeira.
Sentado no canto escuro da War Room estava Marvin Boggs.
Marvin segurava uma pasta enorme marcada:
INCIDENTE 0317 — NÃO CONFIAR EM NINGUÉM
— Marvin?! Como você entrou aqui?
— Essa não é a pergunta correta.
— E qual seria?
Marvin apontou para o dashboard.
— Por que aquilo está verde se os clientes estão reclamando?
Silêncio.
Naquela madrugada o jovem programador aprenderia uma das lições mais importantes de sua carreira:
Monitoramento mostra sinais. Observabilidade ajuda a reconstruir histórias.
E Marvin Boggs adorava histórias.
Principalmente quando alguma coisa nelas não fazia sentido.
🕵️ CAPÍTULO 1 — MONITORAMENTO NÃO É OBSERVABILIDADE
Durante muitos anos utilizamos a palavra monitoramento para praticamente tudo relacionado à saúde operacional de sistemas.
CPU.
Memória.
Disco.
I/O.
Filas.
Jobs.
Transações.
Disponibilidade.
Tudo isso continua extremamente importante.
Mas existe uma diferença conceitual.
Monitoramento normalmente parte de perguntas conhecidas.
Por exemplo:
CPU ultrapassou 90%?
O CICS está disponível?
A queue depth ultrapassou determinado limite?
O batch terminou?
Houve ABEND?
Você sabe antecipadamente aquilo que pretende observar.
É como instalar sensores nas portas de uma casa.
Se uma porta abrir, recebemos um alerta.
Observabilidade precisa ir além.
Ela deve permitir investigar perguntas que talvez nem soubéssemos que precisaríamos fazer quando o sistema foi construído.
Marvin apontou novamente para o dashboard.
CPU 42% GREEN
CICS UP GREEN
DB2 UP GREEN
MQ UP GREEN
STORAGE OK GREEN
NETWORK OK GREEN
— O que isso diz?
— Que está tudo funcionando.
Marvin balançou a cabeça.
— Não. Isso diz que cinco coisas específicas estão dentro dos critérios usados para pintar cinco quadrados de verde.
Essa diferença é fundamental.
Um componente estar UP não significa que esteja entregando o serviço esperado com qualidade.
Um Db2 disponível pode estar sofrendo com locks.
Um MQ disponível pode possuir filas crescendo.
Um CICS disponível pode estar processando transações lentamente.
Um sistema operacional perfeitamente saudável pode hospedar uma aplicação com problemas.
E uma CPU em 30% não significa que o usuário esteja feliz.
A pergunta moderna deixa de ser apenas:
“O computador está funcionando?”
e passa a incluir:
“O serviço está funcionando como deveria?”
🏛️ CAPÍTULO 2 — O MAINFRAME JÁ FAZIA TELEMETRIA ANTES DE ELA FICAR NA MODA
O jovem programador perguntou:
— Então precisamos instalar observabilidade no mainframe?
Marvin arregalou os olhos.
— Instalar?
Ele abriu outra pasta.
Nela estava escrito:
SMF.
Aqui existe uma curiosidade deliciosa da história da computação.
O mercado moderno fala muito sobre:
telemetry;
metrics;
logging;
tracing;
observability;
workload analytics;
performance analytics.
Mas mainframes registram enormes quantidades de informações operacionais há décadas.
No universo z/OS existe uma verdadeira infraestrutura de evidências.
Entre os protagonistas encontramos:
SMF — System Management Facilities
RMF — Resource Measurement Facility
WLM — Workload Manager
E ainda informações provenientes de:
CICS;
IMS;
Db2;
MQ;
JES2;
RACF;
TCP/IP;
storage;
aplicações;
subsistemas.
O mainframe não é uma caixa preta.
Muito pelo contrário.
Às vezes o problema é justamente que existem dados demais.
Marvin sorriu.
— Eles registraram tudo.
— Quem?
— O mainframe.
— Marvin...
— Tudo.
📜 CAPÍTULO 3 — SMF, O ARQUIVO SECRETO DO z/OS
Imagine uma cidade gigantesca.
Milhões de acontecimentos ocorrem diariamente.
Pessoas entram.
Pessoas saem.
Mercadorias são transportadas.
Serviços são executados.
Recursos são consumidos.
Agora imagine que existisse um enorme sistema de registros documentando diferentes categorias desses acontecimentos.
Essa analogia ajuda a compreender o SMF.
O System Management Facilities permite que o z/OS e diversos produtos produzam registros estruturados sobre atividades do ambiente.
Existem diferentes tipos e subtipos de registros.
Alguns exemplos conhecidos ajudam a compreender o conceito:
SMF 30 → informações relacionadas à execução de jobs/steps
SMF 70 → atividade de processadores
SMF 72 → workload e service classes
SMF 80 → eventos relacionados à segurança
SMF 110 → informações relacionadas ao CICS
Produtos como Db2 também produzem dados registrados através do ecossistema SMF.
Não é necessário que um programador COBOL iniciante memorize dezenas de record types.
O importante inicialmente é compreender:
SMF é uma das grandes fontes históricas de evidência operacional do z/OS.
Imagine que alguém pergunte:
— O que aconteceu entre 03:17 e 03:29?
Você poderá procurar evidências relacionadas ao período.
Ou:
— O consumo aumentou depois daquela mudança?
Podemos comparar janelas.
Ou:
— Qual workload estava pressionando o ambiente?
Novamente existem dados que podem ajudar.
Marvin abriu outra pasta.
— Dados não mentem.
O programador interrompeu:
— Dados podem ser interpretados incorretamente.
Marvin ficou alguns segundos em silêncio.
— Você está aprendendo.
🔭 CAPÍTULO 4 — RMF: OLHANDO O ORGANISMO
Se SMF nos oferece uma enorme coleção de registros, o RMF ocupa papel fundamental na análise de desempenho e recursos.
CPU.
Memória.
I/O.
Workloads.
LPARs.
Dispositivos.
Paging.
Utilização.
Tempos.
Delays.
É tentador olhar um gráfico e dizer:
CPU = 91%
e imediatamente concluir:
PROBLEMA!
Mas Marvin não permitiu.
— Qual é o SLA?
— 500 milissegundos.
— E o response time?
— 190 milissegundos.
— Então qual é o problema?
Essa é uma lição importante.
CPU alta não significa automaticamente serviço ruim.
Imagine:
CPU 92%
P95 190 ms
SLO 500 ms
Erros 0,01%
O ambiente pode estar utilizando eficientemente os recursos disponíveis.
Agora considere:
CPU 27%
P95 8,4 s
Timeouts aumentando
Temos CPU sobrando e usuários sofrendo.
Talvez exista:
espera de I/O;
lock;
fila;
dependência externa;
contenção;
problema de rede;
espera no Db2;
MQ;
algum recurso serializado.
Portanto:
Utilização não é experiência do usuário.
Essa frase merece ficar na parede da War Room.
⚖️ CAPÍTULO 5 — WLM E A ARTE DE SABER QUEM IMPORTA AGORA
Imagine um banco processando simultaneamente:
PIX
autorizações
consultas
relatórios
batch
processos contábeis
serviços internos
Se houver pressão de recursos, devemos simplesmente tratar tudo igualmente?
O z/OS possui um componente fundamental chamado Workload Manager — WLM.
Entre os conceitos relacionados encontramos:
Workload
↓
Service Class
↓
Service Class Period
↓
Goal
↓
Importance
O WLM ajuda o sistema a administrar workloads de acordo com objetivos definidos.
Aqui encontramos uma ideia poderosa:
Performance não é somente consumir recursos. É entregar objetivos de serviço para trabalhos com diferentes importâncias.
Para observabilidade, isso é ouro.
Não queremos simplesmente descobrir:
CPU chegou a 90%.
Queremos compreender:
Qual workload estava utilizando recursos?
As metas estavam sendo atendidas?
Alguma workload importante estava sofrendo delay?
Que tipo de atraso estava ocorrendo?
É uma investigação muito mais inteligente.
💳 CAPÍTULO 6 — O CLIENTE NÃO COMPRA CPU
Marvin colocou dois dashboards na mesa.
O primeiro dizia:
CPU 67%
CICS TPS 18.300
Db2 threads 7.180
MQ depth 320
O segundo:
AUTORIZAÇÕES
Transações/min 47.500
Aprovação 91,4%
Recusa 7,8%
Erro técnico 0,8%
P95 310 ms
P99 790 ms
— Qual deles interessa ao diretor?
O jovem apontou para o segundo.
Exatamente.
O cliente não compra:
MIPS, MSU, CPU, I/O ou threads.
O cliente compra um serviço.
Uma autorização.
Uma transferência.
Uma consulta.
Uma compra.
Uma reserva.
Por isso observabilidade madura conecta:
INFRAESTRUTURA
↓
MIDDLEWARE
↓
APLICAÇÃO
↓
TRANSAÇÃO
↓
SERVIÇO
↓
NEGÓCIO
Essa é uma evolução gigantesca.
⏱️ CAPÍTULO 7 — MARVIN DESCONFIA DA MÉDIA
Imagine cem transações.
Noventa e cinco respondem em aproximadamente 100 ms.
Quatro levam dois segundos.
Uma leva trinta segundos.
A média mistura tudo.
Marvin imediatamente pergunta:
— Quem foi o sujeito dos trinta segundos?
Bem-vindo aos percentis.
Podemos analisar:
P50
P90
P95
P99
O P50 ajuda a representar uma experiência mais típica.
P95 mostra que 95% das observações estão até aquele valor.
P99 começa a revelar a cauda da distribuição.
Imagine:
AVG = 210 ms
P95 = 390 ms
P99 = 7.800 ms
Olhar somente a média poderia produzir uma conclusão perigosamente otimista.
Em sistemas que executam milhões de transações, 1% pode representar muita gente.
Dica Bellacosa
Nunca entre numa War Room carregando apenas uma média.
Leve também distribuição, percentis, volume e contexto temporal.
Marvin levaria ainda três pastas, dois rádios e provavelmente um explosivo.
Não precisamos copiar essa última parte.
🔗 CAPÍTULO 8 — A TRANSAÇÃO SAIU DO MAINFRAME
Antigamente poderíamos imaginar:
Terminal
↓
CICS
↓
COBOL
↓
Db2
Hoje podemos encontrar:
Mobile
↓
Internet
↓
API Gateway
↓
Kubernetes
↓
Microservice
↓
Kafka/MQ
↓
z/OS Connect
↓
CICS
↓
COBOL
↓
Db2
Agora surge um problema organizacional.
Cloud olha cloud.
Rede olha rede.
Middleware olha middleware.
Mainframe olha mainframe.
Cada equipe possui seu dashboard.
E acontece o pesadelo clássico:
Cloud GREEN
Network GREEN
API GREEN
Mainframe GREEN
Database GREEN
Cliente RED
Todos conseguem provar que seu pedaço está funcionando.
Ninguém consegue explicar por que o serviço está ruim.
Isso é exatamente o problema que observabilidade distribuída tenta enfrentar.
🧬 CAPÍTULO 9 — TRACE ID: O PASSAPORTE DA TRANSAÇÃO
Em arquiteturas distribuídas encontramos conceitos como:
Trace ID;
Span ID;
parent span;
child span.
Imagine uma transação recebendo um identificador:
TRACE = 8AF723
Podemos reconstruir sua viagem:
TRACE 8AF723
│
├── Mobile
├── API Gateway
├── Java
├── z/OS Connect
├── CICS
│ └── COBOL AUTH001
│ ├── Db2
│ └── MQ
└── Response
Agora medimos:
API Gateway 45 ms
Java 105 ms
Network 18 ms
z/OS Connect 32 ms
CICS 75 ms
COBOL 24 ms
Db2 118 ms
MQ 6.120 ms
Bingo.
Não precisamos de uma reunião de duas horas discutindo:
“Acho que é mainframe.”
Temos evidências indicando onde concentrar a investigação.
Observabilidade reduz a importância do achismo.
🔭 CAPÍTULO 10 — OPENTELEMETRY ENCONTRA O VELHO MAINFRAME
O mundo cloud-native desenvolveu padrões modernos para telemetria.
Um dos nomes importantes nesse cenário é OpenTelemetry.
A proposta geral envolve trabalhar com sinais como:
Metrics
Logs
Traces
Isso é especialmente interessante em ambientes híbridos.
Não significa jogar SMF no lixo.
Seria absurdo.
O cenário interessante é correlacionar mundos:
CLOUD / DISTRIBUÍDO
│
OpenTelemetry
│
▼
CORRELAÇÃO
▲
│
SMF / RMF / CICS
│
MAINFRAME
O objetivo é conseguir acompanhar a história completa.
O mainframe não precisa abandonar décadas de instrumentação para participar da observabilidade moderna.
Precisamos construir pontes.
📈 CAPÍTULO 11 — PROMETHEUS E GRAFANA
Prometheus tornou muito popular o trabalho com métricas organizadas como séries temporais.
Por exemplo:
transaction_response_seconds
Podemos associar dimensões:
application="cards"
transaction="AUTH"
channel="mobile"
Grafana pode apresentar essas informações em dashboards extremamente poderosos.
Mas cuidado.
Marvin entrou na sala e encontrou quinze monitores exibindo gráficos espetaculares.
— O que aconteceu às 03:17?
Silêncio.
— Mas temos 127 dashboards!
— Eu perguntei o que aconteceu.
Essa cena fictícia representa um problema real.
Quantidade de dashboards não mede maturidade de observabilidade.
Se ninguém consegue responder perguntas sobre comportamento do serviço, possuímos decoração operacional.
Não observabilidade.
🚨 CAPÍTULO 12 — O ALARME QUE GRITAVA LOBO
Outro problema clássico é o excesso de alertas.
WARNING CPU
WARNING MQ
WARNING DB2
WARNING CICS
WARNING STORAGE
WARNING MEMORY
WARNING NETWORK
WARNING RESPONSE
Depois de centenas deles surge a alert fatigue.
Operadores começam a ignorar mensagens porque quase todas são ruído.
Observabilidade madura procura contexto e correlação.
Em vez de:
ALERTA 1
ALERTA 2
ALERTA 3
ALERTA 4
ALERTA 5
queremos construir:
INCIDENTE 0317
│
├── MQ queue depth ↑
│
├── espera ↑
│
├── response time ↑
│
└── timeout ↑
Uma coleção de sintomas começa a virar uma história.
🕵️ CAPÍTULO 13 — O INCIDENTE DAS 03:17
Vamos fazer a investigação completa.
Chamado:
Autorizações de cartão estão lentas.
PASSO 1 — NÃO REINICIE NADA
Primeiro preserve evidências.
Restart pode resolver sintomas.
Mas também pode destruir condições importantes para investigação.
PASSO 2 — DETERMINE O IMPACTO
Pergunte:
Quando começou?
Qual serviço?
Qual transação?
Quantos usuários?
Qual canal?
Qual região?
Continua acontecendo?
Descobrimos:
AUTH
03:17–03:29
12.481 transações afetadas
PASSO 3 — DEFINA O NORMAL
Sem baseline, “alto” e “baixo” significam pouco.
Normal:
P95 = 320 ms
Incidente:
P95 = 6,8 s
Temos evidência objetiva de degradação.
PASSO 4 — SIGA A TRANSAÇÃO
API normal
Network normal
CICS normal
COBOL normal
Db2 normal
MQ suspeito
PASSO 5 — CONSTRUA A TIMELINE
03:16:58 mudança implantada
03:17:04 queue depth aumenta
03:17:11 response time aumenta
03:18:02 timeouts começam
Agora temos uma correlação extremamente interessante.
Mas Marvin interrompe:
— Não diga que encontramos a causa.
Correto.
Correlação não é automaticamente causalidade.
Precisamos testar a hipótese.
🧪 CAPÍTULO 14 — HIPÓTESE NÃO É VEREDITO
Uma investigação madura segue aproximadamente:
SINTOMA
↓
EVIDÊNCIA
↓
TIMELINE
↓
CORRELAÇÃO
↓
HIPÓTESE
↓
TESTE
↓
CAUSA
↓
CORREÇÃO
↓
VALIDAÇÃO
Uma investigação ruim segue:
SINTOMA
↓
PALPITE
↓
RESTART
E existe uma versão ainda pior:
RESTART
↓
FUNCIONOU
↓
CHAMADO ENCERRADO
Três semanas depois:
INCIDENTE 0317 — PARTE II.
Marvin já estaria esperando.
⏱️ CAPÍTULO 15 — MTTD E MTTR
Observabilidade tem impacto operacional direto.
Considere:
03:17 problema começa
03:25 cliente reclama
03:32 NOC identifica
03:45 equipe mainframe acionada
04:10 middleware acionado
04:32 causa encontrada
04:48 serviço restaurado
Agora compare com:
03:17 problema começa
03:18 anomalia detectada
03:19 dependência correlacionada
03:22 equipe correta acionada
03:31 serviço restaurado
Não tornamos necessariamente a CPU mais rápida.
Tornamos a organização mais rápida para entender aquilo que está acontecendo.
Esse é um dos grandes retornos da observabilidade.
🤖 CAPÍTULO 16 — AIOPS: QUANDO MARVIN GANHA UM ASSISTENTE
Mainframes podem produzir quantidades gigantescas de telemetria.
Nenhum ser humano consegue observar manualmente tudo o tempo inteiro.
É aí que análise estatística, machine learning e IA podem ajudar.
Imagine que normalmente:
AUTH P95 = 240–370 ms
Hoje:
AUTH P95 = 710 ms
O threshold tradicional é:
ALERT IF > 1000 ms
Portanto:
GREEN.
Mas 710 ms pode representar uma anomalia significativa em relação ao comportamento histórico daquele horário.
Um sistema de anomaly detection poderia sinalizar:
O comportamento está significativamente diferente do baseline.
Isso muda nossa filosofia.
De:
threshold absoluto
para:
comportamento esperado + contexto + tendência.
IA também pode ajudar na correlação entre eventos, logs, mudanças, métricas e incidentes anteriores.
Mas ela não deve transformar hipótese em verdade magicamente.
Marvin provavelmente desconfiaria da IA também.
Nesse caso, talvez ele estivesse certo.
🔮 CAPÍTULO 17 — OBSERVABILIDADE PREDITIVA
Podemos imaginar uma escada:
NÍVEL 1
Está funcionando?
↓
NÍVEL 2
O que está acontecendo?
↓
NÍVEL 3
Onde está acontecendo?
↓
NÍVEL 4
Por que aconteceu?
↓
NÍVEL 5
Qual impacto?
↓
NÍVEL 6
Vai acontecer novamente?
↓
NÍVEL 7
Podemos agir antes?
Aqui observabilidade encontra:
capacity planning;
forecasting;
performance engineering;
anomaly detection;
automação;
AIOps.
Essa é uma evolução natural.
🏗️ CAPÍTULO 18 — CAPACITY PLANNING
Observe seis meses:
TRANSAÇÕES CPU
JAN 100 M 42%
FEV 108 M 45%
MAR 116 M 49%
ABR 127 M 54%
MAI 139 M 59%
JUN 153 M 66%
Separadamente, são números.
Correlacionados ao longo do tempo, começam a contar uma história.
Podemos perguntar:
Existe relação entre crescimento transacional e consumo?
A curva é linear?
Qual workload está crescendo?
Existe sazonalidade?
Qual será o impacto da Black Friday?
Em que ponto determinado SLO começará a ficar ameaçado?
Isso é infinitamente melhor do que esperar CPU chegar a 99% numa sexta-feira às 18 horas.
🧠 CAPÍTULO 19 — O MÉTODO MARVIN BOGGS PARA O PROGRAMADOR COBOL
Quando alguém disser:
“Produção está lenta.”
Não abra imediatamente o fonte COBOL.
Primeiro pergunte:
1. O QUE mudou?
Tempo de resposta?
Erro?
Volume?
Fila?
2. QUANDO mudou?
03:17?
Depois do deploy?
Depois da abertura do mercado?
3. ONDE mudou?
Mobile?
API?
CICS?
Db2?
MQ?
4. QUEM foi afetado?
Todos?
Uma região?
Um produto?
Um canal?
5. QUAL É A EVIDÊNCIA?
SMF?
RMF?
Log?
Trace?
Métrica?
Event?
6. QUAL É A HIPÓTESE?
Só então investigamos causalidade.
🗺️ CAPÍTULO 20 — O MAPA DA OBSERVABILIDADE MAINFRAME
O programador COBOL precisa aprender a enxergar verticalmente:
NEGÓCIO
│
SLA / SLO
│
▼
SERVIÇO
│
▼
TRANSAÇÃO
│
┌────────────┼────────────┐
▼ ▼ ▼
CICS IMS APIs
│ │
▼ ▼
COBOL COBOL
│
┌─────┼─────┐
▼ ▼ ▼
Db2 VSAM MQ
│ │ │
└─────┼─────┘
▼
z/OS
│
┌─────┼─────┐
▼ ▼ ▼
SMF RMF WLM
│
▼
PR/SM
│
▼
IBM Z
Depois deve fazer o caminho contrário:
IBM Z
↓
z/OS
↓
middleware
↓
COBOL
↓
transação
↓
serviço
↓
CLIENTE
Porque o objetivo final não é provar que o hardware está saudável.
É compreender se o serviço está saudável.
🧰 CAPÍTULO 21 — KIT DE SOBREVIVÊNCIA DO PADAWAN
Para começar no assunto, eu estudaria nesta sequência:
Primeiro: aprenda a diferença entre disponibilidade, performance e experiência.
Segundo: entenda CPU, memória, I/O, filas, throughput, latência e erro.
Terceiro: aprenda percentis e baseline.
Quarto: conheça SMF.
Quinto: estude RMF.
Sexto: compreenda WLM e workload management.
Sétimo: observe CICS, IMS, Db2 e MQ como componentes de uma cadeia.
Oitavo: aprenda logs, metrics e traces.
Nono: estude distributed tracing.
Décimo: conheça OpenTelemetry, Prometheus e Grafana.
Finalmente conecte tudo ao negócio.
Não tente decorar 300 métricas.
Aprenda a formular perguntas.
Essa talvez seja a skill mais importante.
🥚 EASTER EGG — 03:17
O jovem programador finalmente percebeu algo.
— Marvin...
— Sim?
— Todos os incidentes começaram às 03:17.
Marvin lentamente fechou a pasta.
Na etiqueta estava escrito:
USER-ID: MARVIN
DATE: 1972-03-17
REASON: DO NOT DELETE
— Isso significa alguma coisa?
Marvin olhou para os lados.
— Tudo significa alguma coisa.
— Mas especificamente isso?
— Provavelmente não.
☕
No Bellacosa Mainframe, 03:17 permanece reservado para aquele momento mágico em que produção decide ensinar alguma coisa que não estava no PowerPoint.
☕ EPÍLOGO — A CONSPIRAÇÃO DAS LUZES VERDES
O incidente terminou.
Na tela:
LPAR 🟢
z/OS 🟢
CICS 🟢
Db2 🟢
MQ 🟢
COBOL 🟢
Marvin acrescentou mais uma linha:
CLIENTE 🔴
O jovem ficou olhando.
Finalmente compreendeu.
Um sistema pode estar tecnicamente disponível e ainda entregar uma experiência ruim.
Um componente pode estar saudável isoladamente e participar de um serviço degradado.
Uma média pode parecer excelente e esconder milhares de transações lentas.
Uma CPU alta pode ser saudável.
Uma CPU baixa pode acompanhar um desastre.
Um alerta pode indicar um sintoma, não a causa.
Uma mudança ocorrida às 03:16:58 pode estar correlacionada com um problema iniciado às 03:17:04 sem, por isso, provar automaticamente causalidade.
E cem dashboards não substituem uma boa investigação.
Observabilidade em mainframe é justamente a capacidade de transformar:
SMF
RMF
WLM
logs
metrics
traces
CICS
IMS
Db2
MQ
APIs
OpenTelemetry
Prometheus
Grafana
em algo muito mais importante:
EVIDÊNCIA
↓
CONTEXTO
↓
CORRELAÇÃO
↓
HIPÓTESE
↓
INVESTIGAÇÃO
↓
CAUSA
↓
IMPACTO
↓
AÇÃO
Marvin levantou-se.
— Então agora você entende observabilidade?
O jovem programador respondeu:
— Acho que sim.
Marvin parou imediatamente.
— Acha?
O rapaz corrigiu:
— Tenho evidências suficientes para sustentar essa hipótese.
Marvin sorriu.
O treinamento estava concluído.
☕ PALAVRAS FINAIS DO BELLACOSA MAINFRAME
Talvez a maior evolução para quem começa em COBOL seja perceber que seu programa não vive sozinho.
Aquele:
PERFORM PROCESSA-AUTORIZACAO
faz parte de algo gigantesco:
CLIENTE
↓
APP
↓
API
↓
MENSAGERIA
↓
z/OS CONNECT
↓
CICS
↓
COBOL
↓
Db2 / VSAM / MQ
↓
z/OS
↓
WLM
↓
LPAR
↓
IBM Z
Cada camada deixa pistas.
Cada espera conta uma história.
Cada fila crescendo significa alguma coisa.
Cada mudança precisa de contexto.
Cada transação possui uma jornada.
O profissional de observabilidade aprende a reconstruí-la.
Por isso, quando alguém entrar correndo na War Room dizendo:
“O MAINFRAME ESTÁ LENTO!”
não discuta.
Não culpe a cloud.
Não culpe a rede.
Não culpe Db2.
Não abra imediatamente o fonte COBOL.
Não reinicie tudo.
Pegue seu café.
Abra as evidências.
Construa a timeline.
E faça a pergunta que Marvin Boggs faria:
“O que exatamente aconteceu às 03:17?”
Porque em produção...
luz verde também precisa de álibi. ☕🕵️
Sem comentários:
Enviar um comentário