Technical Debt, Chaos Engineering e Resiliência no Mundo COBOL

 

Bellacosa Mainframe e divida tecnica, engenharia do caos e resiliencia no mundo mainframe

☕ Um Café no Bellacosa Mainframe

Technical Debt, Chaos Engineering e Resiliência no Mundo COBOL

Uma viagem dos cartões perfurados à engenharia de confiabilidade moderna

Existe uma curiosidade interessante sobre o universo Mainframe.

Boa parte dos desenvolvedores mais jovens acredita que sistemas COBOL foram escritos uma única vez, colocados em produção em algum momento dos anos 80 e simplesmente ficaram funcionando até hoje, imutáveis, como fósseis tecnológicos preservados em um museu digital.

A realidade é completamente diferente.

Poucas plataformas de tecnologia evoluíram tanto quanto o ecossistema IBM Z.

O hardware mudou.

O sistema operacional mudou.

Os compiladores mudaram.

As técnicas de desenvolvimento mudaram.

A forma de entregar software mudou.

As exigências regulatórias mudaram.

E os desenvolvedores também precisaram mudar.

Hoje falamos sobre APIs REST, Git, DevOps, Inteligência Artificial, Observabilidade, Chaos Engineering e Cloud Native. Entretanto, curiosamente, os sistemas que movimentam bilhões de dólares por dia continuam sendo executados por programas COBOL escritos há décadas.

Seria isso uma contradição?

Na verdade, não.

Talvez seja justamente uma demonstração de sucesso.

O primeiro legado não foi um erro

Em 1959 nasceu o COBOL.

Naquela época não existiam metodologias ágeis.

Não existia internet.

Não existiam smartphones.

Muitos programas eram escritos em cartões perfurados.

Armazenamento era caro.

Memória era limitada.

CPU era um recurso precioso.

As equipes construíam software pensando em algo muito importante:

Confiabilidade.

A aplicação precisava funcionar.

Sempre.

Mesmo que demorasse algumas horas para processar milhares de contas bancárias durante a madrugada.

Foi nesse ambiente que nasceu uma cultura extremamente disciplinada.

Documentação.

Padrões.

Controle de mudanças.

Testes.

Auditorias.

Processos.

Talvez os desenvolvedores daquela época não soubessem, mas estavam criando alguns dos primeiros conceitos de Engenharia de Confiabilidade.

Technical Debt: a dívida que todos nós fazemos

Em 1992, Ward Cunningham criou uma analogia brilhante.

Ele comparou decisões de desenvolvimento com empréstimos bancários.

Imagine que você precise entregar um sistema até sexta-feira.

Você poderia construir uma solução perfeita.

Ou poderia desenvolver algo funcional, mais simples, entregando rapidamente.

Você ganha velocidade.

Mas assume uma dívida.

E como toda dívida, ela possui juros.

Esses juros aparecem de várias formas.

Mais bugs.

Mais incidentes.

Mais retrabalho.

Maior consumo de CPU.

Maior dificuldade de manutenção.

Menor velocidade de inovação.

No Mainframe isso acontece frequentemente.

Talvez exista um programa COBOL com 25 mil linhas.

Talvez exista um COPYBOOK criado em 1987.

Talvez apenas um profissional conheça determinada aplicação.

Tudo isso representa dívida técnica.

O problema não é possuir dívida.

O problema é não saber que ela existe.

Nem toda dívida é ruim

Muitos desenvolvedores iniciantes acreditam que Technical Debt sempre significa erro.

Não é verdade.

Às vezes ela é estratégica.

Um banco pode precisar adequar sistemas rapidamente para atender uma nova regulamentação do BACEN.

Uma seguradora pode precisar disponibilizar um novo produto imediatamente.

Uma fintech pode lançar um MVP para validar mercado.

Nesses casos, assumir dívida técnica pode ser perfeitamente aceitável.

Desde que exista um plano para pagá-la posteriormente.

E aqui encontramos uma das primeiras lições importantes para um desenvolvedor COBOL júnior:

Escreva código pensando que alguém precisará entendê-lo daqui a dez anos.

Esse alguém pode ser você mesmo.

O mito da reescrita completa

Existe uma frase bastante comum em empresas:

"Precisamos jogar tudo fora."

Geralmente essa frase surge quando o ambiente está muito complexo.

Mas a IBM apresenta uma visão diferente.

Você não precisa substituir quarenta anos de sistemas.

Você pode modernizar gradualmente.

Esse conceito ficou conhecido como Strangler Pattern.

Imagine um sistema COBOL que processa contas correntes.

Ele continua funcionando.

Mas uma nova camada é criada.

z/OS Connect.

APIs REST.

Microserviços.

Containers.

Aplicações Java.

Python.

Inteligência Artificial.

O COBOL permanece processando transações críticas.

As aplicações modernas apenas consomem seus serviços.

A dívida começa a diminuir sem que seja necessário desligar o coração operacional da empresa.

Testes automatizados são seus melhores amigos

Durante muitos anos, testar em Mainframe significava reservar uma janela de homologação.

Executar jobs.

Analisar relatórios.

Esperar dias.

Hoje isso mudou.

Ferramentas como zUnit permitem criar testes automatizados.

Jenkins integra pipelines.

GitHub Actions executa validações.

DBB facilita builds.

Zowe aproxima o mundo Mainframe das práticas DevOps modernas.

Se você está começando em COBOL, desenvolva o hábito de pensar:

"O que acontece se o CPF estiver inválido?"

"E se a data vier vazia?"

"E se houver overflow?"

Programadores experientes não escrevem apenas funcionalidades.

Eles escrevem confiança.

Code Review: aprendendo com outros desenvolvedores

Uma das melhores maneiras de evoluir tecnicamente é revisar código.

Olhar programas COBOL antigos.

Analisar SQL.

Entender JCLs.

Perguntar.

Questionar.

Aprender.

Muitos problemas são identificados antes mesmo de chegar à produção.

Um cursor esquecido.

Um COMMIT ausente.

Um SORT desnecessário.

Uma consulta DB2 sem índice adequado.

Dois pares de olhos normalmente enxergam mais do que um.

Refatoração não significa reescrever

Refatorar é melhorar.

Não é destruir.

Não é começar do zero.

Pequenas melhorias acumuladas ao longo do tempo fazem enorme diferença.

Renomear variáveis.

Extrair rotinas.

Separar módulos.

Eliminar GOTO.

Criar serviços reutilizáveis.

Transformar programas gigantes em componentes menores.

Refatoração contínua é uma das formas mais eficientes de pagar Technical Debt.

Observabilidade: enxergando o que realmente acontece

Existe uma frase bastante conhecida:

Se você não consegue medir, não consegue melhorar.

No mundo IBM Z temos ferramentas extraordinárias.

SMF.

RMF.

OMEGAMON.

Instana.

Grafana.

Elas permitem compreender:

CPU.

I/O.

Latência.

Filas.

Conexões.

Transações.

Antes de corrigir qualquer problema, precisamos enxergá-lo.

Observabilidade é a base da engenharia moderna.

Chaos Engineering: quebrando para aprender

Talvez o conceito mais surpreendente para desenvolvedores COBOL seja Chaos Engineering.

A ideia surgiu popularmente na Netflix.

Mas a IBM mostra que ela pode ser aplicada em praticamente qualquer ambiente.

O princípio é simples.

Não espere uma falha em produção.

Provoque pequenas falhas.

Aprenda.

Corrija.

Teste novamente.

Por exemplo:

O que acontece se o IMS Connect ficar indisponível?

Se a fila MQ atingir 95% de ocupação?

Se um membro do Sysplex parar?

Se o DB2 responder lentamente?

Chaos Engineering não significa desligar servidores aleatoriamente.

É ciência.

Você cria uma hipótese.

Executa um experimento controlado.

Observa.

Aprende.

Melhora.

Repete.

Resiliência é um investimento

A IBM utiliza uma analogia muito interessante.

Imagine um ciclista.

Ele pode sair apenas com a bicicleta.

Ou levar uma bomba de ar.

Kit de reparo.

Câmara reserva.

Pneu reserva.

Carro de apoio.

Mecânico.

Quanto maior a disponibilidade desejada, maior será o custo.

Em tecnologia ocorre exatamente o mesmo.

Alta disponibilidade.

Disaster Recovery.

Cyber Recovery.

Backups.

Replicação.

GDPS.

Sysplex.

Active-Active.

Tudo possui custo.

O objetivo não é atingir disponibilidade infinita.

O objetivo é encontrar equilíbrio entre risco, orçamento e necessidade do negócio.

O desenvolvedor COBOL de 2026

O profissional COBOL moderno não é apenas alguém que conhece MOVE, PERFORM e READ.

Ele entende Git.

Conhece APIs.

Aprende DevOps.

Sabe interpretar métricas.

Participa de revisões.

Automatiza testes.

Compreende observabilidade.

Conhece conceitos de segurança.

Entende resiliência.

Estuda Inteligência Artificial.

E principalmente, continua cultivando algo que sempre esteve presente no universo Mainframe:

Disciplina técnica.

Os sistemas que movimentam bilhões de transações diariamente não permanecem relevantes por acaso.

Eles permanecem relevantes porque existem profissionais dispostos a compreender o passado, melhorar continuamente o presente e testar constantemente o futuro.

E talvez seja exatamente essa a maior lição do Mainframe.

Tecnologia muda.

Ferramentas mudam.

Buzzwords mudam.

Mas excelência em engenharia continua sendo atemporal.

E isso, felizmente, nunca sai de moda.

Até o próximo café.

☕ Bellacosa Mainframe

Bellacosa Mainframe Network

Siga nossas newsletters e comunidades no LinkedIn

☕ Um Café no Bellacosa Mainframe Subscribe on LinkedIn

🚀 COBOL Jr. Subscribe on LinkedIn

💻 Bellacosa Mainframe Follow Company

🟩 COBOL Life Follow Showcase

 

Bellacosa Mainframe a arte da guerra contra o caos conheça o RCA

☕🔥💣 O SYSprog PADAWAN E A ARTE DA GUERRA CONTRA O CAOS

Root Cause Analysis no IBM Mainframe: Por Que Reiniciar o CICS Não Resolve Seus Problemas

Existe uma frase muito comum nos corredores dos data centers:

"Reinicia que volta."

Durante décadas ela funcionou.

O CICS travou?

Reinicia.

O batch falhou?

Roda de novo.

O MQ congestionou?

Dá STOP e START.

O JES2 ficou estranho?

Cancela alguns jobs.

O storage explodiu?

Aumenta a região.

O problema é que essa mentalidade criou gerações de profissionais especialistas em apagar incêndios, mas não necessariamente especialistas em eliminar incêndios.

E existe uma diferença gigantesca entre as duas coisas.

O verdadeiro profissional de Mainframe moderno não é aquele que resolve o incidente mais rápido.

É aquele que garante que o incidente nunca mais aconteça.

É aí que entra uma das disciplinas mais importantes da engenharia moderna:

Root Cause Analysis (RCA)

Ou, em português:

Análise de Causa Raiz

Uma habilidade que separa o operador comum do engenheiro de confiabilidade.

---

O INCIDENTE NÃO É O PROBLEMA

Este é talvez o conceito mais importante de todo o artigo.

Quando um sistema cai, aquilo que você vê não é o problema.

É apenas a consequência visível.

Imagine uma transação CICS que começa a responder lentamente.

O usuário reclama.

O suporte abre um chamado.

O operador percebe aumento de CPU.

O time de infraestrutura aumenta recursos.

Tudo parece resolvido.

Mas alguns dias depois o problema volta.

Por quê?

Porque ninguém investigou a causa raiz.

A lentidão era apenas um sintoma.

O problema verdadeiro talvez fosse:

• SQL ineficiente

• Índice DB2 corrompido

• Loop em programa COBOL

• Fila MQ congestionada

• Deadlock de recursos

• Automação mal configurada

Resolver o sintoma gera alívio.

Resolver a causa gera evolução.

---

O MAIOR PECADO DA TI MODERNA

A Harvard Business Review publicou um estudo mostrando que a maioria dos executivos acredita que suas organizações são ruins em diagnosticar problemas.

Isso não surpreende.

A cultura corporativa moderna recompensa velocidade.

Poucas vezes recompensa investigação.

A pressão é sempre:

"Volta o sistema agora."

Raramente alguém pergunta:

"Por que ele caiu?"

E menos ainda:

"Como impedimos que isso aconteça novamente?"

---

O DETETIVE DIGITAL

Um bom profissional de RCA pensa como um investigador.

Quando ocorre uma falha ele não procura imediatamente uma solução.

Primeiro procura evidências.

Ele coleta:

• SYSLOG

• JESMSGLG

• SMF

• RMF

• Dumps

• Traces

• Mensagens CICS

• Logs DB2

• Eventos MQ

• Métricas OMEGAMON

Cada informação conta parte da história.

Nenhum log isolado revela a verdade completa.

O segredo está na correlação.

---

O CASO DO BATCH QUE ATRASAVA TODA SEXTA-FEIRA

Vamos analisar um exemplo realista.

Toda sexta-feira o processamento noturno atrasava duas horas.

A primeira reação foi aumentar os initiators JES2.

Funcionou por algumas semanas.

Depois o atraso voltou.

Nova tentativa:

Mais CPU.

Mais memória.

Mais canais.

Nada resolveu.

Quando uma análise de causa raiz foi finalmente realizada, descobriu-se que um programa COBOL executava uma consulta DB2 sem índice adequado.

Toda sexta-feira havia crescimento no volume de dados.

A consulta que normalmente levava segundos passava a consumir minutos.

Um único SQL provocava efeito cascata em dezenas de jobs dependentes.

A verdadeira solução não foi comprar hardware.

Foi corrigir um SQL.

---

O MÉTODO DOS CINCO PORQUÊS

Uma técnica clássica de RCA é conhecida como:

Five Whys

Cinco Porquês.

Exemplo:

Problema:

Batch falhou.

Por quê?

Dataset estava bloqueado.

Por quê?

Outro job mantinha ENQ.

Por quê?

Entrou em loop.

Por quê?

SQL aguardava retries.

Por quê?

Índice DB2 estava inconsistente.

Agora temos a causa raiz.

Observe que a resposta verdadeira apareceu apenas após várias camadas de investigação.

---

O INIMIGO INVISÍVEL CHAMADO CULTURA

Muitas vezes a causa raiz não está no software.

Nem no hardware.

Nem na rede.

Está nas pessoas.

Considere o seguinte cenário.

Um deploy derruba produção.

A primeira conclusão costuma ser:

"O desenvolvedor errou."

Mas uma análise profunda pode revelar:

• Prazo impossível

• Falta de testes

• Ausência de homologação

• Pressão da gestão

• Processo de aprovação falho

O erro humano foi apenas o último elo da corrente.

A verdadeira falha estava no sistema organizacional.

---

O MODELO DE CONGRUÊNCIA

Uma abordagem extremamente interessante utilizada em liderança organizacional é o Modelo de Congruência.

Ele analisa cinco dimensões:

Trabalho

O que precisa ser feito?

Dependências

Quem depende de quem?

Capacidades

As pessoas possuem conhecimento suficiente?

Estrutura

A organização facilita ou dificulta o trabalho?

Cultura

Os comportamentos desejados são incentivados?

No Mainframe isso é extremamente aplicável.

Não adianta investir milhões em Z17 se:

• a equipe não recebe treinamento

• a documentação está desatualizada

• os processos são confusos

• ninguém entende as integrações

---

O MAINFRAME MODERNO É UM ECOSSISTEMA

Nos anos 80 era relativamente fácil identificar falhas.

Hoje um único fluxo pode envolver:

• COBOL

• CICS

• DB2

• MQ

• APIs REST

• Kafka

• Cloud

• Linux on Z

• Zowe

• DevOps

A causa raiz pode estar em qualquer lugar.

Ou em vários lugares simultaneamente.

Por isso a investigação precisa ser sistêmica.

---

A ARMADILHA DO "SEMPRE FOI ASSIM"

Uma das causas mais perigosas de incidentes recorrentes é a complacência.

Frases famosas:

"Isso acontece às vezes."

"Sempre fizemos assim."

"Nunca deu problema."

São frases que deveriam acender alertas imediatos.

Porque normalmente escondem riscos acumulados durante anos.

---

COMO REALIZAR UM RCA NO MAINFRAME

Passo 1 — Definir o Problema

Não investigue algo genérico.

Errado:

"O sistema está ruim."

Correto:

"O CICS CICSPRD apresentou aumento de resposta de 0,3 para 8 segundos entre 14h e 15h."

Problemas bem definidos geram investigações eficientes.

---

Passo 2 — Coletar Evidências

Reúna:

• logs

• métricas

• dumps

• relatórios

• eventos

Sem dados você possui apenas opiniões.

---

Passo 3 — Construir a Linha do Tempo

Pergunte:

O que aconteceu primeiro?

O que aconteceu depois?

Qual evento precedeu a falha?

Muitas causas aparecem quando organizamos os fatos cronologicamente.

---

Passo 4 — Correlacionar Eventos

Um erro aparentemente isolado pode estar conectado a dezenas de outros eventos.

O desafio é encontrar essas relações.

---

Passo 5 — Aplicar os Cinco Porquês

Continue perguntando:

Por quê?

Até chegar à origem.

---

Passo 6 — Validar a Hipótese

A hipótese precisa ser comprovada.

Não basta parecer correta.

Ela deve explicar:

• o incidente

• os sintomas

• a recorrência

---

Passo 7 — Criar Plano de Ação

A correção deve:

• eliminar a causa

• reduzir riscos

• ser mensurável

---

FERRAMENTAS ESSENCIAIS PARA RCA NO Z/OS

RMF

Identifica gargalos de performance.

SMF

Registra praticamente tudo que acontece.

IPCS

Análise de dumps.

OMEGAMON

Observabilidade avançada.

SDSF

Investigação operacional.

NetView

Correlação de eventos.

System Automation

Automação e recuperação.

JES2

Análise de filas, execução e spool.

---

O FUTURO: AIOPS E RCA AUTOMATIZADO

Estamos entrando em uma era fascinante.

Ferramentas modernas conseguem:

• detectar anomalias

• prever falhas

• correlacionar eventos

• sugerir causas prováveis

AIOps não substitui o analista.

Mas amplifica sua capacidade.

O profissional moderno utilizará IA para acelerar investigações complexas.

---

ONDE A MAIORIA DAS EMPRESAS ERRA

As falhas mais comuns são:

Falta de documentação

Sem histórico não existe aprendizado.

Ausência de postmortem

O incidente é resolvido e esquecido.

Busca por culpados

Pessoas escondem erros quando temem punição.

Falta de métricas

Sem observabilidade não existe RCA.

Correções paliativas

Workarounds substituem soluções definitivas.

---

COMO EVOLUIR SUA ORGANIZAÇÃO

Empresas maduras desenvolvem cultura de aprendizado.

Após cada incidente perguntam:

• O que aconteceu?

• Por que aconteceu?

• Como detectamos?

• Como evitaremos recorrência?

• O que aprendemos?

Essa simples mudança transforma organizações.

---

O SYSprog PADAWAN E O MESTRE

O Padawan reinicia.

O Mestre investiga.

O Padawan fecha chamados.

O Mestre elimina problemas.

O Padawan trata sintomas.

O Mestre trata causas.

O Padawan celebra quando o sistema volta.

O Mestre celebra quando o sistema não cai novamente.

Essa é a verdadeira evolução profissional.

---

CONCLUSÃO

Root Cause Analysis não é apenas uma metodologia.

É uma filosofia.

É a diferença entre sobreviver e evoluir.

No mundo do IBM Z17, DevOps, observabilidade, automação e inteligência artificial, a capacidade de descobrir a causa raiz tornou-se uma das habilidades mais valiosas da engenharia moderna.

Porque reiniciar um sistema pode resolver um incidente.

Mas apenas entender a causa raiz pode impedir que ele volte.

E é exatamente isso que separa um operador de console de um arquiteto da estabilidade.

No final das contas, o verdadeiro inimigo nunca foi o abend.

Nunca foi o dump.

Nunca foi o job cancelado.

O verdadeiro inimigo sempre foi aquilo que ninguém investigou.

 

Bellacosa Mainframe e root cause analysis em Mainframe

---

☕🔥💣 “O SYSprog PADAWAN E A ARTE DA GUERRA CONTRA O CAOS” — ROOT CAUSE ANALYSIS NO MAINFRAME Z17, DEVOPS, CICS, JES2 E A CAÇADA À CAUSA RAIZ

Quando o operador para de apagar incêndios e começa a eliminar demônios do datacenter

Existe um momento na vida de todo Sysprog Padawan em que ele percebe uma verdade brutal do universo corporativo:

“Reiniciar o JOB não resolveu o problema…”

Apenas escondeu o cadáver.

E é exatamente nesse momento que nasce a verdadeira disciplina do guerreiro IBM Z:
a arte da Root Cause Analysis — ou simplesmente RCA.

No universo do mainframe moderno, onde bilhões de transações passam por CICS, DB2, MQ, IMS e JES2, problemas não aparecem do nada.

Todo ABEND possui uma origem.

Todo LOOP tem um motivo.

Todo dataset corrompido conta uma história.

E todo operador experiente sabe:

“O sintoma mente. A causa raiz não.”

Hoje vamos mergulhar profundamente no universo da RCA no estilo Bellacosa Mainframe, explorando:

• história,

• filosofia,

• métodos,

• guerra operacional,

• automação,

• observabilidade,

• DevOps,

• IA operacional,

• e sobrevivência psicológica em ambientes z/OS críticos.

Prepare o café.
Abra o SDSF.
E mantenha o dump por perto.

Porque o LOBO da causa raiz está observando.

---

☕ O QUE É ROOT CAUSE ANALYSIS?

Root Cause Analysis é a ciência de descobrir a verdadeira origem de um problema.

Não o sintoma.
Não o efeito.
Não o caos superficial.

Mas sim:
o gatilho original que iniciou a cascata da destruição.

Na definição da IBM:

“RCA é o processo de identificar a raiz de um problema para evitar sua recorrência.”

O detalhe importante aqui é:

EVITAR RECORRÊNCIA.

Porque qualquer novato consegue:

• cancelar TASK,

• reiniciar STC,

• reciclar CICS,

• dar IPL no desespero.

Mas poucos conseguem impedir o problema de voltar.

---

☕ A DIFERENÇA ENTRE OPERADOR E ENGENHEIRO

Operador reativo:

“Voltou a funcionar? Ótimo.”

Engenheiro RCA:

“Por que parou?”

Essa diferença separa:

• operadores comuns,

• Sysprogs lendários.

---

☕ A ORIGEM HISTÓRICA DA RCA

A RCA não nasceu na TI.

Ela surgiu em ambientes extremos.

Segunda Guerra Mundial

Engenheiros militares precisavam descobrir:

• por que aviões caíam,

• por que motores explodiam,

• por que radares falhavam.

Não havia espaço para tentativa e erro.

A falha matava pessoas.

A filosofia então evoluiu para:

• engenharia industrial,

• indústria nuclear,

• aviação,

• automóveis,

• telecom,

• e finalmente TI corporativa.

---

☕ TOYOTA E O MÉTODO DOS 5 WHYs

Nos anos 1950, Taiichi Ohno criou o famoso:

“5 Porquês”

A lógica era simples:

Continue perguntando “por quê?” até encontrar a verdade.

---

☕ EXEMPLO MAINFRAME REALÍSTICO

Problema:

JOB noturno ABEND S0C7.

---

Por quê?

Campo numérico inválido.

---

Por quê?

Arquivo veio com caracteres errados.

---

Por quê?

Conversão ASCII/EBCDIC falhou.

---

Por quê?

Novo middleware FTP alterou encoding.

---

Por quê?

Mudança entrou sem homologação.

---

CAUSA RAIZ:

Processo DevOps inadequado.

Perceba:
o COBOL não era o vilão.

O problema estava na governança.

---

☕ O MAIOR ERRO DOS PADAWANS

Todo Sysprog iniciante acredita em sintomas.

Mas sintomas enganam.

Exemplo clássico:

Sintoma:

CPU alta.

O Padawan pensa:

“Precisamos de mais processador.”

O mestre RCA responde:

“Não.
Precisamos descobrir QUEM está consumindo CPU.”

Pode ser:

• loop COBOL,

• SQL ruim,

• runaway task,

• lock contention,

• buffer inadequado,

• storage leak,

• automação defeituosa.

A CPU alta é apenas o grito do sistema.

---

☕ OS 3 TIPOS DE CAUSAS

A IBM divide RCA em três dimensões.

---

1. CAUSAS FÍSICAS

Hardware.
Infraestrutura.
Equipamentos.

Exemplos:

• DASD defeituoso

• canal FICON instável

• controladora falhando

• memória ECC corrompida

• falha elétrica

---

☕ EXEMPLO Z/OS

O JES2 começa a apresentar I/O ERROR.

Batch falha aleatoriamente.

Após investigação:

Causa raiz:

microfissura em controladora storage.

---

2. CAUSAS HUMANAS

O terror invisível do datacenter.

Exemplos:

• operador cancelando STC errada,

• PROC alterada incorretamente,

• DELETE DATASET acidental,

• parâmetro inválido,

• JCL truncado.

---

☕ O CLÁSSICO ERRO DO PADAWAN

//STEP01 EXEC PGM=IEFBR14
//DD1 DD DSN=PROD.CLIENTES,
// DISP=(OLD,DELETE,DELETE)

Parabéns.

Você acabou de invocar o demônio ancestral do DELETE em produção.

---

3. CAUSAS ORGANIZACIONAIS

As mais perigosas.

Porque sobrevivem por anos.

Exemplos:

• ausência de documentação,

• treinamento ruim,

• processo inexistente,

• automação incompleta,

• cultura tóxica,

• deploy sem governança.

---

☕ A VERDADE SOMBRIA

Grandes falhas raramente acontecem por um único motivo.

Elas acontecem porque:

múltiplas pequenas falhas se alinham.

Igual peças de dominó.

---

☕ O CICLO DA DESTRUIÇÃO OPERACIONAL

1. Pequena falha ignorada

2. Monitoramento ruim

3. Automação incompleta

4. Time cansado

5. Mudança mal testada

6. Alertas ignorados

7. Deploy na sexta-feira

8. Caos absoluto

---

☕ O PROCESSO COMPLETO DE RCA

Agora entramos na disciplina guerreira.

---

ETAPA 1 — IDENTIFICAR O PROBLEMA

Definição ruim:

“O sistema caiu.”

Definição profissional:

“O CICS PAY01 apresentou degradação progressiva após aumento de lock contention DB2 causado por crescimento anômalo de filas MQ.”

Agora sim existe material técnico.

---

☕ ETAPA 2 — MONTAR O TIME RCA

Você precisa reunir:

• operadores,

• Sysprogs,

• DBAs,

• DevOps,

• segurança,

• storage,

• redes,

• automação.

Porque falhas modernas são híbridas.

---

☕ ETAPA 3 — COLETA DE DADOS

Aqui começa a arqueologia digital.

Ferramentas clássicas:

• SDSF

• RMF

• SMF

• IPCS

• NetView

• OMEGAMON

• SYSLOG

• dumps

• traces

• logs MQ

• logs DB2

---

☕ O PODER DOS LOGS

Logs são fósseis digitais.

Eles contam a história da tragédia.

O problema é:

Padawans não leem logs.

Eles olham apenas:

• RC=12

• ABEND=S806

• IEC141I

E entram em pânico.

---

☕ ETAPA 4 — BRAINSTORM DAS CAUSAS

Aqui existe uma regra sagrada:

NÃO ASSUMA NADA.

O maior inimigo da RCA é:

“Já sei o que aconteceu.”

Porque normalmente você NÃO sabe.

---

☕ ETAPA 5 — DETERMINAR A CAUSA RAIZ

Agora elimina-se hipótese por hipótese.

Até restar:

• evidência,

• causalidade,

• sequência lógica.

---

☕ ETAPA 6 — IMPLEMENTAR A SOLUÇÃO

Agora nasce a verdadeira engenharia.

Não basta corrigir.

É preciso:

• automatizar,

• prevenir,

• monitorar,

• alertar,

• documentar.

---

☕ MÉTODOS RCA MAIS IMPORTANTES

---

☕ 5 WHYs

Simples.
Poderoso.
Mortal.

Excelente para:

• incidentes operacionais,

• falhas batch,

• troubleshooting rápido.

---

☕ FMEA

Failure Mode and Effects Analysis.

Muito usado em:

• bancos,

• aviação,

• missão crítica.

Objetivo:

Prever COMO o sistema pode falhar antes do desastre.

---

☕ ISHIKAWA (FISHBONE)

O famoso diagrama espinha de peixe.

Divide problemas em categorias:

• pessoas,

• máquinas,

• processos,

• ambiente,

• software,

• gestão.

Excelente para war rooms.

---

☕ PARETO

80% dos problemas vêm de 20% das causas.

Exemplo real:

• 70% dos ABENDs vêm de input inválido.

• 15% vêm de espaço.

• 10% vêm de lock.

• 5% diversos.

Ataque os 20%.
Ganhe estabilidade absurda.

---

☕ RCA EM DEVOPS

No DevOps moderno:

TODO INCIDENTE GERA POSTMORTEM.

Mas aqui existe uma mudança filosófica gigantesca.

---

☕ BLAMELESS POSTMORTEM

Google popularizou:

“Postmortem sem caça às bruxas.”

Objetivo:

Não destruir pessoas.
Mas aprender.

Porque sistemas falham.
Humanos erram.
Processos quebram.

A maturidade está em aprender rápido.

---

☕ RCA NO MAINFRAME MODERNO

O IBM Z atual é extremamente avançado.

Hoje temos:

• observabilidade,

• IA operacional,

• automação,

• analytics,

• machine learning.

Ferramentas modernas:

• IBM Instana

• OMEGAMON

• System Automation

• NetView

• z/OSMF

• SMF Analytics

---

☕ EXEMPLO REAL — O APOCALIPSE DO PIX

Imagine:

Sexta-feira.
18:05.
PIX nacional congestionado.

Sintomas:

• CICS lento

• MQ crescendo

• DB2 travando

• CPU disparando

Padawans entram em desespero.

---

☕ INVESTIGAÇÃO

A RCA descobre:

Deploy DevOps alterou frequência de COMMIT.

Resultado:

• lock contention,

• timeout,

• crescimento de filas,

• efeito cascata.

---

☕ CAUSA RAIZ

Mudança sem teste de carga.

---

☕ SOLUÇÃO

• rollback,

• observabilidade,

• testes automáticos,

• limites MQ,

• monitoramento preditivo.

Agora o sistema ficou MAIS FORTE que antes.

Esse é o verdadeiro objetivo da RCA.

---

☕ A ERA DA IA OPERACIONAL

Hoje AIOps tenta prever:

• anomalias,

• falhas,

• gargalos,

• tendências,

• causas prováveis.

O futuro do Sysprog não é apenas reagir.

Será:

prever o desastre antes dele nascer.

---

☕ O VERDADEIRO NÍVEL MESTRE

O Sysprog lendário não luta contra incêndios.

Ele elimina as condições que permitem incêndios.

---

☕ LIÇÕES FINAIS PARA O SYSprog PADAWAN

Nunca confie no primeiro sintoma.

Nunca assuma a primeira hipótese.

Nunca ignore pequenos alertas.

Nunca faça deploy sexta-feira.

Nunca delete dataset sem olhar duas vezes.

Nunca subestime logs.

Nunca trate apenas o efeito.

---

☕ CONCLUSÃO

Root Cause Analysis não é apenas metodologia.

É mentalidade.

É disciplina.

É engenharia real.

No mundo IBM Z moderno, onde bilhões dependem da estabilidade do sistema, RCA separa:

• operadores comuns,

• arquitetos da confiabilidade.

Quando você aprende RCA:

você deixa de ser alguém que “reinicia sistemas”.

E se torna alguém que entende o funcionamento profundo do caos.

E no momento em que você compreende o caos…

você começa a dominar o datacenter.

☕🔥💣

 

☕💾🔥 CICS DATA SETS — O “SUBSOLO INVISÍVEL” QUE MANTÉM BANCOS VIVOS NO MAINFRAME IBM Z

O programador COBOL vê EXEC CICS.

O sysprog vê sobrevivência transacional.

Quando um programador iniciante começa no CICS, normalmente ele enxerga apenas:

EXEC CICS READ
EXEC CICS WRITE
EXEC CICS RETURN

Mas existe um universo gigantesco escondido por trás disso.

Um universo formado por:

• recovery,

• tracing,

• logging,

• observabilidade,

• filas,

• rollback,

• dumps,

• persistência operacional,

• orchestration.

E é exatamente isso que os datasets do CICS representam.

Neste artigo vamos mergulhar profundamente no “lado invisível” do CICS.

Porque:

entender datasets do CICS é começar a pensar como um verdadeiro sysprog.

---

☕ O CICS NÃO É Apenas Um Transaction Monitor

Essa é uma das maiores descobertas que um profissional faz quando amadurece no mundo mainframe.

O CICS:

• não é apenas EXEC CICS,

• não é apenas COBOL online,

• não é apenas tela verde.

Ele é:

• transaction manager,

• recovery engine,

• queue manager,

• observability platform,

• tracing framework,

• runtime orchestrator.

E os datasets são literalmente:

os órgãos internos dessa criatura.

---

🔥 DFHCSD — O DNA Operacional do CICS

O primeiro dataset que um sysprog precisa entender profundamente é:

DFHCSD

O famoso:

CICS System Definition File.

---

☕ O Que o CSD Realmente Faz?

Ele funciona como:

• catálogo mestre,

• banco de definições,

• repositório operacional.

Tudo o que o CICS precisa conhecer:

• PROGRAM,

• TRANSACTION,

• FILE,

• TERMINAL,

• TCPIPSERVICE,

• URIMAP,

• TDQUEUE,

• JVMSERVER,

• PIPELINE,

fica definido no CSD.

---

🔥 O CICS NÃO “DESCUBRE” Recursos Automaticamente

Esse é um ponto fundamental.

No mundo cloud moderno muita gente está acostumada com:

• service discovery,

• auto registration,

• dynamic orchestration.

Mas o CICS nasceu em um mundo onde:

previsibilidade e controle eram mais importantes do que automação descontrolada.

Tudo precisa ser explicitamente definido.

---

☕ O Grande Segredo Arquitetural

O runtime do CICS:

NÃO trabalha diretamente no CSD.

Durante startup ocorre:

DFHCSD
   ↓
INSTALL
   ↓
Control Blocks em memória
   ↓
Runtime CICS

Isso é extremamente sofisticado.

---

🔥 O Que São Control Blocks?

São estruturas internas contendo:

• atributos,

• endereços,

• localização dos programas,

• flags,

• status operacional.

Quando um programa executa:

EXEC CICS LINK PROGRAM('PGM001')

O CICS consulta:

control blocks em memória.

Não o CSD.

---

☕ Isso Explica a Velocidade do CICS

Tudo fica:

• pré-carregado,

• indexado,

• organizado,

• otimizado em memória.

Décadas antes do conceito moderno de:

• metadata caching,

• in-memory orchestration,

• runtime repositories.

---

🔥 O CSD Revolucionou o CICS

Antes dele existiam:

• PPT,

• PCT,

• FCT,

• TCT.

Control tables extremamente rígidas.

Alterações exigiam:

• assemble,

• link-edit,

• restart.

O CSD trouxe:

• definição dinâmica,

• administração online,

• menos downtime,

• maior agilidade.

---

☕ DFHLOG — O Coração da Integridade Transacional

Agora chegamos no componente mais crítico de todos:

o system log.

Sem ele:

• bancos quebrariam,

• saldos ficariam inconsistentes,

• transações seriam perdidas.

---

🔥 O Que o DFHLOG Faz?

Ele registra:

• before images,

• syncpoints,

• rollback records,

• updates,

• UOWs.

Tudo necessário para:

recovery transacional.

---

☕ Before Image — Conceito Fundamental

Antes de alterar um dado:

o CICS grava o estado anterior.

Exemplo:

Saldo = 1000
↓
Tentativa de update para 800

Antes disso:

o valor antigo é registrado no log.

---

🔥 Dynamic Transaction Backout (DTB)

Agora imagine:

Debita conta A
↓
ABEND
↓
Crash

O CICS:

• consulta o DFHLOG,

• identifica updates incompletos,

• executa rollback,

• restaura integridade.

Isso é:

DTB — Dynamic Transaction Backout.

---

☕ Warm Start e Emergency Restart

Quando o CICS reinicia:

ele escaneia o log inteiro.

Para descobrir:

• quais tasks estavam ativas,

• quais UOWs precisam rollback,

• quais recursos devem ser restaurados.

---

🔥 Primary e Secondary Streams

O system log lógico é composto por:

• Primary stream

• Secondary stream

Ambos são vistos como:

um único logical log stream.

Isso mostra uma arquitetura extremamente madura.

---

☕ DFHSHUNT — O Mundo das Shunted UOWs

Quando uma Unit of Work:

• não consegue completar recovery,

• possui recurso indisponível,

• encontra erro persistente,

ela pode ficar:

shunted.

O CICS NÃO perde a integridade.

Ele preserva a UOW para recuperação posterior.

Isso é engenharia mission-critical real.

---

🔥 Dumps — A Forense do CICS

O CICS possui dois níveis principais de dump.

---

☕ System Dump

Captura:

• região inteira,

• memória,

• address spaces,

• control blocks,

• storage global.

Vai normalmente para:

SYS1.DUMPnn

É usado em:

• falhas severas,

• storage corruption,

• kernel problems.

---

🔥 Transaction Dump

Mais focado.

Captura:

• task específica,

• COMMAREA,

• EIB,

• storage da transação.

Usa:

DFHDMPA
DFHDMPB

Muito usado em:

• ASRA,

• S0C7,

• AICA,

• debugging aplicativo.

---

☕ Trace — O Gravador de Voo do CICS

O tracing do CICS é uma obra-prima da engenharia enterprise.

---

🔥 CETR — O Painel de Controle do Trace

A transação:

CETR

permite:

• ativar trace,

• parar trace,

• selecionar domains,

• ajustar níveis,

• controlar GTF,

• configurar auxiliary trace.

---

☕ GTF — Generalized Trace Facility

O GTF integra:

• CICS,

• z/OS,

• VTAM,

• DB2,

• TCP/IP.

Permitindo tracing sistêmico.

Muito antes do conceito moderno de:

• distributed tracing,

• observability pipelines,

• telemetry frameworks.

---

🔥 Auxiliary Trace — Evitando o Wrapping

Trace em memória é circular.

Quando enche:

sobrescreve dados antigos.

Para evitar isso:

DFHAUXT
DFHBUXT

permitem:

• persistência,

• grandes volumes,

• rotação automática.

Isso é praticamente:

rolling logs décadas antes do Linux popularizar isso.

---

☕ SMF — O Big Data Operacional do Mainframe

O CICS também produz telemetria enterprise.

---

🔥 O Que o CICS Grava no SMF?

• CPU usage,

• elapsed time,

• transaction counts,

• waits,

• VSAM activity,

• DB2 usage,

• storage consumption.

Especialmente via:

SMF Type 110

---

☕ Muito Antes da “Observabilidade Moderna”

Enquanto muita gente fala hoje sobre:

• Prometheus,

• Grafana,

• OpenTelemetry,

• observability,

O z/OS já fazia isso:

há décadas.

---

🔥 TSQ — Temporary Storage Queue

O CICS frequentemente precisa guardar dados temporários.

Para isso existem:

TSQs.

---

☕ Características da TSQ

• criação dinâmica,

• leitura por item,

• releitura,

• update.

Exemplo:

EXEC CICS WRITEQ TS
     QUEUE('TEMP001')
END-EXEC

---

🔥 Main TS vs Auxiliary TS

Main TS

• memória,

• rápido,

• temporário.

Auxiliary TS

• VSAM,

• persistente,

• maior capacidade.

Muito usado via:

DFHTEMP

---

☕ TDQ — Transient Data Queue

Agora chegamos em um clássico absoluto do CICS.

---

🔥 TDQ vs TSQ

Essa diferença derruba muitos iniciantes.

---

☕ TSQ

Mais flexível.

---

🔥 TDQ

Mais orientada a fluxo:

• leitura sequencial,

• destrutiva,

• pré-definida.

Ideal para:

• impressão,

• integração batch,

• pipelines assíncronos.

---

☕ Intrapartition vs Extrapartition

Intrapartition

Usada:

dentro da região CICS.

Controlada pelo próprio CICS.

---

Extrapartition

Usada:

dentro e fora do CICS.

Muito comum em:

• integração batch,

• JES,

• exportação,

• geração de arquivos.

---

🔥 O CICS Já Fazia Mensageria Muito Antes do Kafka

Observe algo impressionante.

Décadas antes de:

• Kafka,

• RabbitMQ,

• Event Streaming,

• Message Brokers modernos,

O CICS já implementava:

• filas,

• desacoplamento,

• processamento assíncrono,

• integração enterprise.

---

☕ Global Catalog — A Memória Persistente do Runtime

O global catalog:

• salva recursos instalados,

• guarda localização do system log,

• ajuda no warm start,

• auxilia recovery.

---

🔥 Installed ≠ Defined

Esse conceito é importantíssimo.

Defined

Existe no CSD.

Installed

Está ativo no runtime.

---

☕ O CICS Separa Configuração de Runtime

Isso é extremamente moderno.

Mesmo conceito atual de:

• configuration repositories,

• runtime metadata,

• orchestration state.

---

🔥 O Que Um Sysprog Junior Deve Entender?

Se você está começando em sysprog CICS:

pare de enxergar apenas EXEC CICS.

Comece a enxergar:

• recovery,

• rollback,

• observabilidade,

• logs,

• tracing,

• queues,

• startup orchestration,

• runtime control blocks.

Porque:

é isso que mantém bancos funcionando sem parar.

---

☕ O Grande Insight Final

O mais impressionante do CICS é perceber que:

muito antes da computação distribuída moderna existir,

o mainframe já havia resolvido problemas extremamente complexos.

Como:

• observabilidade,

• tracing,

• rollback automático,

• crash recovery,

• filas assíncronas,

• persistência runtime,

• transaction management.

---

🔥 Pensamento Final ao Estilo Bellacosa Mainframe

O programador iniciante vê:

EXEC CICS READ

O sysprog experiente vê:

• DFHLOG,

• SMF,

• CETR,

• GTF,

• recovery manager,

• syncpoints,

• UOWs,

• auxiliary trace,

• control blocks,

• startup orchestration.

E entende que:

o CICS não é apenas um monitor transacional.

Ele é uma das arquiteturas mais sofisticadas já construídas na história da computação enterprise.

☕💾🔥

 

Bellacosa Mainframe e laboratorio pratico de performance

☕💣🔥 LABORATÓRIO PRÁTICO — TESTES DE PERFORMANCE PARA O PADAWAN COBOL MAINFRAME

Este laboratório foi criado para transformar conceitos em prática.

A ideia é que o aluno pense como um Analista de Performance, um Desenvolvedor COBOL e um Sysprog ao mesmo tempo.

Cada exercício possui:

• Cenário

• Desafio

• Solução Comentada

• Conceitos Envolvidos

---

EXERCÍCIO 1

Identificando o Tipo de Teste

Cenário

O banco deseja validar se o Internet Banking suporta 5.000 usuários simultâneos.

Pergunta

Qual tipo de teste deve ser realizado?

A) Estresse

B) Resistência

C) Carga

D) Pico

---

Solução

Resposta:

C) Carga

O objetivo é validar a capacidade prevista do ambiente.

Não estamos ultrapassando limites.

Não estamos testando durante horas.

Não estamos simulando explosões repentinas.

Estamos simulando o uso normal esperado.

---

EXERCÍCIO 2

Descobrindo o Gargalo

Cenário

Uma consulta de saldo apresenta:

Componente	Tempo
Front-End	50 ms
API	80 ms
CICS	1200 ms
DB2	950 ms

Pergunta

Onde está o principal gargalo?

---

Solução

CICS e DB2.

O tempo de resposta total está concentrado nessas camadas.

O Front-End e API representam parcela muito pequena do processamento.

O próximo passo seria analisar:

• SQL

• Índices

• Plano de acesso

• Locks

---

EXERCÍCIO 3

Avaliando Throughput

Cenário

Durante um teste foram processadas:

120.000 transações

em

60 segundos

Pergunta

Qual o Throughput?

---

Solução

Fórmula:

TPS = Transações ÷ Tempo

120.000 ÷ 60

TPS = 2.000

Resposta:

2.000 TPS

---

EXERCÍCIO 4

Encontrando Problema de Código COBOL

Programa

PERFORM UNTIL WS-FIM = 'S'

   READ ARQ-CLIENTES
      AT END
         MOVE 'S' TO WS-FIM
   END-READ

   PERFORM PROCESSA-CLIENTE

END-PERFORM

Pergunta

Qual risco de performance existe?

---

Solução

Se o arquivo possuir milhões de registros:

• CPU elevada

• I/O elevado

• Tempo excessivo

O código não está errado.

Mas pode não escalar.

Performance depende do volume.

---

EXERCÍCIO 5

Escolhendo a Ferramenta

Cenário

Você precisa gerar:

10.000 usuários simultâneos

realizando chamadas HTTP.

Pergunta

Qual ferramenta apresentada seria mais indicada?

---

Solução

Apache JMeter.

Porque:

• Open Source

• Escalável

• HTTP

• HTTPS

• REST

• SOAP

Foi justamente a ferramenta mostrada na apresentação.

---

EXERCÍCIO 6

Teste de Resistência

Cenário

Uma aplicação funciona perfeitamente por:

30 minutos

Após:

8 horas

o consumo de memória cresce continuamente.

Pergunta

Qual tipo de teste identificou o problema?

---

Solução

Teste de Resistência.

Também chamado:

Soak Test

ou

Endurance Test.

Esse tipo de problema dificilmente aparece em testes rápidos.

---

EXERCÍCIO 7

Simulando Black Friday

Cenário

Usuários simultâneos:

09:00 → 1.000

09:01 → 10.000

09:02 → 15.000

09:03 → 1.000

Pergunta

Qual tipo de teste está sendo realizado?

---

Solução

Teste de Pico.

Objetivo:

Validar explosões repentinas de acesso.

Muito comum em:

• Black Friday

• PIX

• Campanhas

• Venda de ingressos

---

EXERCÍCIO 8

Análise de Mainframe

Cenário

Durante o teste:

CPU = 35%

Tempo de Resposta = 8 segundos

Pergunta

A CPU é o problema?

---

Solução

Não necessariamente.

Esse é um erro clássico.

Mesmo com CPU baixa podem existir:

• Locks DB2

• Espera de I/O

• MQ congestionado

• SQL ruim

• Contenção CICS

CPU baixa não significa ambiente saudável.

---

EXERCÍCIO 9

Virtualização de Serviços

Cenário

O microsserviço precisa chamar:

• Serviço A

• Serviço B

• Mainframe

Mas o Mainframe está indisponível.

Pergunta

Como continuar os testes?

---

Solução

Utilizando Virtualização.

Criamos respostas simuladas.

Exemplo:

{
  "conta":"12345",
  "saldo":"1500.00"
}

Assim os testes continuam sem depender do ambiente real.

---

EXERCÍCIO 10

Diagnóstico Completo

Cenário

O Grafana mostra:

CPU = 40%

Memória = 45%

Tempo Médio = 5 segundos

Dynatrace mostra:

API = 100 ms

CICS = 250 ms

DB2 = 4200 ms

Pergunta

Onde você investigaria primeiro?

---

Solução

DB2.

O banco responde por mais de 80% do tempo total.

Possíveis causas:

• Full Scan

• Índice ausente

• Estatísticas desatualizadas

• Lock

• SQL mal otimizado

---

DESAFIO FINAL DO PADAWAN ☕💣

Imagine a seguinte arquitetura:

Mobile
   ↓
Apache
   ↓
WebSphere
   ↓
API
   ↓
MQ
   ↓
CICS
   ↓
COBOL
   ↓
DB2

Você recebe a reclamação:

"Consultar saldo está demorando 12 segundos."

Descreva:

1. Quais ferramentas utilizaria?

2. Quais métricas analisaria?

3. Quais componentes investigaria primeiro?

4. Como executaria um teste de carga?

5. Como validaria a correção?

---

GABARITO ESPERADO

Ferramentas:

• JMeter

• Dynatrace

• Grafana

• OMEGAMON

• RMF

• SMF

Métricas:

• CPU

• TPS

• Tempo Médio

• P95

• P99

• I/O

• MQ Depth

• Tempo DB2

Investigação:

1. Dynatrace

2. DB2

3. CICS

4. MQ

5. API

Teste:

• 5.000 usuários

• Ramp-up gradual

• Monitoramento simultâneo

Validação:

Comparar:

Antes = 12 segundos

Depois = meta inferior a 2 segundos

---

Missão Extra Bellacosa Mainframe

Pegue um programa COBOL real do seu ambiente e responda:

• Quantos READs ele executa?

• Quantos WRITEs?

• Quantos SELECTs DB2?

• Qual o maior loop?

• Qual o volume esperado?

• Como ele se comportaria com 10 milhões de registros?

Se você conseguir responder essas perguntas, já começou a pensar como um profissional de Performance Mainframe e não apenas como um programador COBOL. ☕💣🚀

Bellacosa Mainframe e a performance em mainframe

☕💣🔥 O DIA EM QUE 10.000 USUÁRIOS DERRUBARAM UM COBOL QUE FUNCIONAVA PERFEITAMENTE — O GUIA DEFINITIVO DE TESTES DE PERFORMANCE PARA O PADAWAN DO MAINFRAME

Existem algumas frases que assustam qualquer profissional experiente de Mainframe.

Uma delas é:

"Pode colocar em produção. Já testamos tudo."

A segunda é:

"Funcionou na minha máquina."

E a terceira, talvez a mais perigosa de todas:

"Performance a gente vê depois."

Se você é um jovem Padawan do COBOL, provavelmente acredita que o trabalho do programador termina quando o programa compila sem erros, passa nos testes funcionais e devolve o resultado correto.

Mas existe um mundo oculto além da lógica.

Um universo onde programas corretos derrubam bancos.

Onde APIs perfeitamente desenvolvidas travam durante a Black Friday.

Onde um SELECT aparentemente inocente consegue transformar uma aplicação inteira em um incêndio corporativo.

Esse universo chama-se Performance.

E hoje vamos conversar sobre um assunto que separa programadores comuns dos profissionais que sobrevivem décadas trabalhando em ambientes críticos.

Vamos falar sobre Testes de Performance.

---

A PRIMEIRA GRANDE LIÇÃO

Imagine que você criou um programa COBOL chamado CONSULTA-SALDO.

O programa recebe:

• Agência

• Conta

Consulta o DB2.

Retorna o saldo.

Você testa.

Funciona.

Seu colega testa.

Funciona.

O analista testa.

Funciona.

O gerente testa.

Funciona.

Todo mundo comemora.

O programa sobe para produção.

Cinco minutos depois:

O Internet Banking trava.

O aplicativo móvel trava.

O atendimento telefônico trava.

O gerente da agência liga desesperado.

E você pensa:

"Mas aqui funcionava..."

Sim.

Funcionava.

Para um usuário.

Produção não possui um usuário.

Produção possui milhares.

Essa é a primeira lição da performance.

Um sistema que funciona para uma pessoa não necessariamente funciona para dez mil.

---

O QUE É UM TESTE DE PERFORMANCE?

Muitos iniciantes acreditam que teste de performance significa medir velocidade.

Não é apenas isso.

Teste de performance é a arte de descobrir como um sistema se comporta quando submetido ao mundo real.

Queremos responder perguntas como:

• Quantos usuários suporta?

• Qual o tempo de resposta?

• Onde está o gargalo?

• Quanto de CPU consome?

• Quanto de memória utiliza?

• Quantas transações por segundo processa?

Na prática estamos tentando descobrir o limite antes que o cliente descubra primeiro.

Porque quando o cliente descobre primeiro, normalmente já existe uma crise instalada.

---

TESTES FUNCIONAIS X TESTES NÃO FUNCIONAIS

O material apresentado faz uma separação extremamente importante.

Testes funcionais verificam:

"O sistema faz o que deveria fazer?"

Exemplo:

Você informa uma conta.

O sistema retorna o saldo correto.

Teste aprovado.

Mas existe outra pergunta.

"O sistema continua fazendo isso quando dez mil usuários acessam simultaneamente?"

Essa pergunta pertence ao mundo dos testes não funcionais.

E é exatamente aqui que entra a performance.

---

O EXEMPLO DO AUTOMÓVEL

Imagine um carro.

Você gira a chave.

O motor liga.

Teste funcional aprovado.

Mas ainda faltam várias perguntas:

• Qual a velocidade máxima?

• Quanto consome?

• Quanto suporta de carga?

• Como se comporta em uma subida?

• Como reage após cinco horas de viagem?

Essas perguntas representam os testes não funcionais.

O mesmo vale para sistemas.

---

O QUE REALMENTE DERRUBA SISTEMAS?

O Padawan normalmente pensa:

"Se estiver lento é porque falta CPU."

Nem sempre.

Na verdade, CPU costuma ser apenas um dos suspeitos.

Os verdadeiros vilões geralmente são:

• SQL mal escrito

• Índices ausentes

• Locks excessivos

• Filas MQ congestionadas

• Chamada excessiva a serviços

• Pool JDBC esgotado

• Recursos compartilhados

Em outras palavras:

O problema normalmente não está onde você imagina.

---

TESTE DE CARGA

Este é o mais conhecido.

O objetivo é reproduzir o uso normal esperado.

Imagine:

O banco estima 5.000 usuários simultâneos.

Criamos então um cenário simulando exatamente esse volume.

A pergunta é simples:

"O sistema suporta?"

Se suporta, ótimo.

Se não suporta, ainda temos tempo para corrigir.

Muito melhor descobrir isso no laboratório do que no Jornal Nacional.

---

TESTE DE ESTRESSE

Aqui a conversa fica interessante.

Em vez de testar o limite esperado, ultrapassamos o limite.

Muito.

Se o ambiente foi projetado para 5.000 usuários:

Testamos 10.000.

15.000.

20.000.

Queremos descobrir:

Como ele falha?

Uma falha controlada é muito melhor que um colapso inesperado.

---

TESTE DE RESISTÊNCIA

Agora imagine uma maratona.

O sistema suporta 5.000 usuários.

Ótimo.

Mas por quanto tempo?

Uma hora?

Duas?

Dez?

Vinte e quatro?

O teste de resistência mantém carga constante durante longos períodos.

Muitas aplicações parecem saudáveis por trinta minutos.

Depois começam a consumir memória.

Depois mais memória.

Depois ainda mais memória.

Até morrerem lentamente.

É o famoso Memory Leak.

---

TESTE DE PICO

Imagine a abertura das vendas de um show.

Ou a Black Friday.

Ou o lançamento de um PIX promocional.

O tráfego explode.

O sistema precisa absorver esse impacto.

O teste de pico verifica exatamente isso.

O comportamento durante explosões repentinas.

---

O MUNDO HÍBRIDO

Antigamente era simples.

Usuário.

Tela.

Mainframe.

Fim.

Hoje não.

Hoje temos:

Aplicativo Mobile

↓

Apache

↓

WebSphere

↓

API Gateway

↓

Microsserviços

↓

MQ

↓

CICS

↓

COBOL

↓

DB2

Percebe o problema?

Se a tela demora cinco segundos, onde está o gargalo?

Pode estar em qualquer ponto da cadeia.

E é por isso que observabilidade se tornou tão importante.

---

APACHE JMETER

Se existe uma ferramenta que virou símbolo dos testes de carga modernos, essa ferramenta é o Apache JMeter.

Pense nele como um exército virtual.

Você configura usuários fictícios.

Esses usuários começam a executar operações.

Consultar saldo.

Fazer transferência.

Emitir extrato.

Pagar boleto.

E o sistema acredita que são usuários reais.

O JMeter consegue gerar milhares de acessos simultâneos.

É exatamente assim que simulamos produção sem colocar clientes reais em risco.

---

EXEMPLO PRÁTICO

Suponha uma API:

GET /saldo

Queremos simular:

5.000 usuários.

Criamos:

Thread Group

Usuários: 5000

Ramp-Up: 300 segundos

Loop: infinito

Agora adicionamos:

HTTP Request

Executamos.

Pronto.

Começamos a produzir carga.

Mas isso é apenas metade da história.

---

POR QUE APENAS GERAR CARGA NÃO BASTA?

Imagine um médico.

Ele mede sua pressão.

Mas ignora:

• Frequência cardíaca

• Oxigenação

• Temperatura

Seria um diagnóstico completo?

Claro que não.

Com performance ocorre a mesma coisa.

Gerar carga é apenas o começo.

Precisamos observar o ambiente inteiro.

---

DYNATRACE

É aqui que entra o Dynatrace.

Pense nele como uma tomografia computadorizada da aplicação.

Ele acompanha cada requisição.

Cada chamada.

Cada serviço.

Cada banco de dados.

Cada microsserviço.

Cada transação.

Em vez de simplesmente dizer:

"Está lento."

Ele mostra:

"Está lento porque o Serviço X chamou o Serviço Y que executou uma consulta SQL custosa."

Agora existe informação para agir.

---

O SONHO DE TODO ANALISTA DE PERFORMANCE

Imagine um clique no aplicativo.

Consultar saldo.

Dynatrace exibe:

Frontend = 80 ms

API = 100 ms

Microsserviço = 120 ms

CICS = 800 ms

DB2 = 700 ms

Pronto.

Achamos o culpado.

Não existe mais adivinhação.

---

GRAFANA

Se Dynatrace é o médico.

Grafana é o painel da UTI.

Ele transforma números em gráficos.

Mostra:

• CPU

• Memória

• Throughput

• Erros

• Tempo médio

• Percentil 95

• Percentil 99

E permite acompanhar tudo em tempo real.

Uma imagem muitas vezes vale mais que mil relatórios.

---

O QUE O MAINFRAME ENSINA SOBRE PERFORMANCE?

Muito antes da palavra observabilidade virar moda, o Mainframe já monitorava tudo.

E quando digo tudo, é tudo mesmo.

O z/OS nasceu para ambientes críticos.

Por isso existem ferramentas extremamente sofisticadas.

---

SMF

System Management Facility.

Registra praticamente tudo.

CPU.

I/O.

Transações.

Consumo.

Execução.

É o grande livro de registros do sistema.

---

RMF

Resource Measurement Facility.

Analisa comportamento dos recursos.

Ajuda a identificar gargalos.

Mostra utilização de processadores.

Filas.

Memória.

Dispositivos.

---

OMEGAMON

Uma das ferramentas mais famosas do universo IBM.

Monitora:

• z/OS

• CICS

• DB2

• MQ

Em tempo real.

Quando algo fica lento, geralmente ele é um dos primeiros lugares onde o especialista procura respostas.

---

O MAIOR ERRO DOS PROGRAMADORES INICIANTES

O Padawan costuma pensar:

"Meu programa executa rápido."

Mas rápido para quem?

Com qual volume?

Em qual horário?

Contra qual banco?

Com quantos registros?

Essas perguntas mudam tudo.

Um SELECT que retorna dez linhas parece maravilhoso.

O mesmo SELECT retornando dez milhões de linhas pode virar um desastre.

---

O CASO DO LOOP INOCENTE

Imagine:

PERFORM UNTIL EOF

READ ARQUIVO

PROCESSA

END-PERFORM

Parece simples.

Mas e se o arquivo possuir:

50 milhões de registros?

Agora o cenário muda.

Performance não depende apenas do código.

Depende dos dados.

---

PERFORMANCE É ARQUITETURA

Muitos acreditam que performance é responsabilidade exclusiva da infraestrutura.

Não é.

Também não é responsabilidade exclusiva do desenvolvedor.

Performance é responsabilidade de todos.

Arquitetura.

Banco.

Infraestrutura.

Rede.

Aplicação.

Integração.

Monitoramento.

Tudo influencia.

---

A MENTALIDADE DO PROFISSIONAL MADURO

O iniciante pergunta:

"Funciona?"

O profissional experiente pergunta:

"Funciona sob carga?"

O iniciante pergunta:

"Retornou o resultado?"

O profissional experiente pergunta:

"Quanto tempo demorou?"

O iniciante pergunta:

"Passou no teste?"

O profissional experiente pergunta:

"Qual foi o consumo?"

Essa mudança de mentalidade transforma carreiras.

---

A LIÇÃO FINAL

Ao longo dos anos vi programas COBOL sobreviverem décadas.

Vi sistemas processarem bilhões de transações.

Vi ambientes suportarem eventos gigantescos sem falhar.

E todos tinham algo em comum.

Performance não era tratada como um detalhe.

Era tratada como requisito.

Porque funcionalidades atraem usuários.

Mas é a performance que permite que eles permaneçam utilizando o sistema.

No fim das contas, um programa COBOL não é avaliado apenas pelo que faz.

Ele é avaliado pela velocidade, estabilidade e capacidade com que faz aquilo.

E essa é a diferença entre escrever código e construir sistemas capazes de sobreviver ao mundo real.

Bem-vindo ao próximo nível da sua jornada no Mainframe, jovem Padawan.

Agora você já sabe que compilar é apenas o começo.

 

Bellacosa Mainframe o mundo da observabilidade mainframe

☕🔥 PROMETHEUS, MIMIR E O “SMF DO MUNDO CLOUD” — O UNIVERSO DA OBSERVABILIDADE EXPLICADO PARA UM SYSPROG JÚNIOR 🔥☕

Se o Grafana é o “painel do operador moderno”…

Então:

• Prometheus é o coletor de métricas
• Mimir é o mega repositório escalável
• Loki é o “SYSLOG gigante”
• Tempo é o rastreador de transações
• OpenTelemetry virou o “SMF universal”

E tudo isso junto forma o que o mercado chama hoje de:

☕ OBSERVABILIDADE

Mas um sysprog veterano olha isso e pensa:

“Isso parece RMF + SMF + OMEGAMON + SYSLOG + CICS MONITORING misturados…”

E honestamente?

Está certíssimo. ☕💾

---

☕ O QUE É OBSERVABILIDADE?

Observabilidade é a capacidade de:

• enxergar o sistema
• entender comportamento
• prever falhas
• diagnosticar problemas rapidamente

Ela normalmente trabalha em 3 pilares:

Pilar	Equivalente Mainframe
Métricas	RMF / SMF
Logs	SYSLOG / JESMSGLG
Traces	CICS trace / Db2 accounting

---

☕ O QUE É PROMETHEUS?

O Prometheus é:

• banco de métricas
• coletor temporal
• motor de queries
• sistema de alertas

Criado em:

• 2012
• pela SoundCloud
• open source
• depois adotado pela CNCF

Site oficial:

• Prometheus

---

☕ O PROBLEMA QUE ELE RESOLVEU

Antes do Prometheus:

• monitoramento era caro
• proprietário
• complicado
• cheio de agentes pesados

O Prometheus trouxe:

• simplicidade
• coleta HTTP
• métricas em texto
• integração cloud-native

Foi um divisor de águas.

---

☕ COMO O PROMETHEUS FUNCIONA?

☕ Modelo “Pull”

O Prometheus vai até o servidor e pergunta:

“Me mostre suas métricas.”

Isso é chamado:

• scrape

---

☕ Exemplo de endpoint

Servidor exportando:

http://server:9100/metrics

Saída:

node_cpu_seconds_total 12345
node_memory_MemFree_bytes 987654321

Parece simples…

E é exatamente essa simplicidade que tornou o Prometheus gigante.

---

☕ EXPORTERS — O “COLETOR SMF” DO MUNDO MODERNO

Prometheus usa exporters.

Eles convertem dados do sistema para métricas.

---

☕ EXPORTERS MAIS FAMOSOS

Exporter	Função
node_exporter	Linux
windows_exporter	Windows
blackbox_exporter	Rede
mysqld_exporter	MySQL
postgres_exporter	PostgreSQL
jmx_exporter	Java
snmp_exporter	Equipamentos

---

☕ ANALOGIA MAINFRAME

Mainframe	Prometheus
SMF Type Records	Metrics
RMF Monitor	node_exporter
OMEGAMON	Grafana + Prometheus
Performance Monitor	Time Series DB

---

☕ PROMQL — O “JCL DAS MÉTRICAS”

O Prometheus possui uma linguagem chamada:

☕ PromQL

Isso é o coração do sistema.

---

☕ Exemplo simples

CPU:

rate(node_cpu_seconds_total[5m])

---

☕ Média de memória

avg(node_memory_MemAvailable_bytes)

---

☕ Detectar servidor offline

up == 0

---

☕ O QUE TORNA O PROMETHEUS ESPECIAL?

☕ 1 — Time Series Database

Ele guarda:

• métricas no tempo
• compressão eficiente
• consultas rápidas

Perfeito para:

• tendências
• capacity planning
• troubleshooting

---

☕ 2 — Labels

Toda métrica pode ter rótulos:

http_requests_total{job="api",status="500"}

Isso lembra:

• classificação SMF
• accounting records
• classes de workload

---

☕ 3 — Alertas

Exemplo:

CPU > 90%

Aciona:

• email
• Slack
• Teams
• PagerDuty

Equivalente moderno de:

“OPERADOR! O SISTEMA ESTÁ PEGANDO FOGO!” ☕💥

---

☕ LIMITAÇÕES DO PROMETHEUS

Aqui começa o lado “sysprog raiz”.

Prometheus é excelente…

Mas:

• retenção longa é complicada
• clustering nativo é limitado
• escala massiva dói
• multi-tenant é complexo

E foi exatamente daí que nasceu:

☕ MIMIR

---

☕ O QUE É MIMIR?

O Grafana Mimir é:

• backend distribuído
• armazenamento massivo de métricas
• compatível com Prometheus

Site:

• Grafana Mimir

---

☕ A IDEIA DO MIMIR

Imagine:

Prometheus sozinho:

• ótimo para ambientes pequenos/médios

Mas empresas gigantes precisam:

• bilhões de métricas
• retenção longa
• HA
• multi datacenter
• multi tenant

Mimir resolve isso.

---

☕ ANALOGIA MAINFRAME

Mundo Moderno	Mundo Mainframe
Prometheus	RMF local
Mimir	SMF central corporativo
Object Storage	Tape library
Long retention	Arquivamento histórico

---

☕ COMO O MIMIR FUNCIONA?

Ele separa componentes:

Componente	Função
Distributor	recebe métricas
Ingester	grava dados
Querier	faz consultas
Compactor	compacta blocos
Store Gateway	acessa storage

Parece familiar?

Sim…

É praticamente arquitetura de subsistema enterprise:

• filas
• cache
• storage
• distribuído
• paralelismo

Muito parecido com mentalidade mainframe.

---

☕ STORAGE

Mimir normalmente usa:

• S3
• MinIO
• GCS
• Azure Blob

Isso permite:

• retenção gigantesca
• baixo custo
• alta escalabilidade

---

☕ LOKI — O “SYSLOG GIGANTE”

☕ O QUE É?

O Loki é:

• sistema de logs
• feito pela Grafana Labs

Site:

• Grafana Loki

---

☕ DIFERENÇA IMPORTANTE

Elasticsearch indexa tudo.

Loki indexa:

• apenas labels

Resultado:

• menos custo
• menos storage
• mais eficiência

---

☕ EXEMPLO

{job="nginx"} |= "ERROR"

---

☕ ANALOGIA MAINFRAME

Loki	Mainframe
Logs distribuídos	SYSLOG
Labels	Classes JES
Queries	SDSF filtros

---

☕ TEMPO — O “CICS TRACE MODERNO”

Tempo trabalha com:

• distributed tracing

Site:

• Grafana Tempo

---

☕ O QUE É TRACE?

Imagine:

• usuário clica no app
• passa API
• banco
• microserviço
• MQ
• cache

Tempo rastreia:

• toda jornada

---

☕ ANALOGIA MAINFRAME

Quase igual:

• CICS trace
• Db2 accounting trace
• MQ activity trace

---

☕ OPEN TELEMETRY — O “SMF UNIVERSAL”

☕ O QUE É?

Framework padronizado de:

• métricas
• logs
• traces

Site:

• OpenTelemetry

---

☕ POR QUE ISSO MUDOU O MERCADO?

Antes:

• cada ferramenta tinha padrão próprio

Agora:

• tudo fala OpenTelemetry

Virou:

“o TCP/IP da observabilidade”

---

☕ DATA SOURCES MAIS IMPORTANTES NO GRAFANA

Data Source	Uso
Prometheus	Métricas
Loki	Logs
Tempo	Traces
Elasticsearch	Logs/search
InfluxDB	IoT/time series
PostgreSQL	Dados SQL
MySQL	Analytics
CloudWatch	AWS
Azure Monitor	Azure
Splunk	Enterprise logs
OpenSearch	Observabilidade

---

☕ O QUE UM SYSPROG JÚNIOR PRECISA APRENDER?

☕ PRIORIDADE 1

Aprender:

• Grafana
• Prometheus
• PromQL

Isso já abre MUITAS portas.

---

☕ PRIORIDADE 2

Depois:

• Loki
• Alertmanager
• OpenTelemetry

---

☕ PRIORIDADE 3

Avançado:

• Mimir
• Tempo
• Thanos
• Kubernetes observability

---

☕ THA NOS — O “PRIMO DO MIMIR”

Outro projeto famoso:

• Thanos

Também resolve:

• escala
• retenção longa
• HA

Muito usado em Kubernetes.

---

☕ CURIOSIDADES INSANAS

☕ Netflix, Uber, bancos e bolsas usam isso

Hoje observabilidade é:

• missão crítica
• core business

---

☕ Um dashboard ruim pode derrubar operação

Porque:

• operador não vê problema
• alerta errado gera caos
• excesso de métricas vira ruído

Exatamente como:

• console floodado no JES2 ☕💥

---

☕ MÉTRICA DEMAIS VIRA O NOVO “SPAGHETTI”

Empresas geram:

• bilhões de métricas por dia

Sem governança:

• storage explode
• custo explode
• queries ficam lentas

---

☕ O FUTURO

A nova onda:

• AIOps
• IA analisando métricas
• detecção automática
• previsão de falhas
• correlação inteligente

Mas o princípio continua o mesmo desde os tempos do MVS:

“Monitorar, entender e agir antes do desastre.” ☕💾🔥