 |
| Bellacosa Mainframe e a jornada do engenheiro de performance em mainframe |
☕ Um Café no Bellacosa Mainframe
A Jornada do Engenheiro de Performance em Mainframe
Quando um Cadete Embarca no USS Seaview e Descobre que o Verdadeiro Tesouro Não Está no Fundo do Oceano... Está Escondido Entre Milhões de Métricas do IBM Z
"Profundidade: 10.000 metros."
"Motores nucleares operando normalmente."
"Sonar ativo."
"Todos os sensores reportando dados."
O Capitão Lee Crane olha para o jovem cadete recém-chegado ao USS Seaview.
— Você sabe pilotar um submarino?
— Não, senhor.
— Então sabe interpretar o sonar?
— Ainda não.
— Conhece oceanografia?
— Também não.
O capitão sorri.
— Excelente. Você está exatamente onde todo grande engenheiro começou.
Essa pequena cena resume perfeitamente a Engenharia de Performance em Mainframe.
Ninguém nasce sabendo interpretar RMF.
Ninguém entende SMF na primeira semana.
Ninguém olha um relatório de WLM e imediatamente identifica um problema.
Tudo isso é aprendido.
E existe um caminho.
Este artigo é exatamente esse mapa.
Não um curso.
Mas um roteiro de formação para transformar um programador COBOL em um verdadeiro Engenheiro de Performance IBM Z.
A Grande Verdade
Existe uma diferença enorme entre:
Fazer um programa funcionar
e
Entender como o computador inteiro funciona.
O programador escreve aplicações.
O engenheiro de performance compreende o ecossistema inteiro.
Ele precisa enxergar aquilo que ninguém vê.
Enquanto um desenvolvedor observa:
READ CLIENTE
O especialista imagina imediatamente:
Quantos EXCPs isso gera?
O dataset está em cache?
Existe contenção?
O Buffer Pool está adequado?
O Storage está respondendo normalmente?
Esse acesso poderia usar Sequential Detection?
Existe leitura desnecessária?
É outro universo.
A Mentalidade Correta
Antes dos livros...
antes dos cursos...
antes das ferramentas...
é preciso desenvolver uma nova forma de pensar.
O engenheiro de performance não pergunta:
"Como resolver?"
Ele pergunta:
"Por que isso aconteceu?"
Essa simples mudança muda toda a carreira.
O Primeiro Ano
Imagine que você acabou de embarcar no Seaview.
Ninguém coloca um novato para controlar o reator nuclear.
Primeiro ele aprende o navio.
No IBM Z acontece exatamente o mesmo.
Etapa 1
Aprenda o Sistema Operacional
Antes de qualquer ferramenta...
aprenda z/OS.
Muito bem.
Estude:
IPL
Address Space
TCB
SRB
Dispatching
Cross Memory
Storage
Virtual Storage
Paging
Swapping
CSA
SQA
ECSA
Link Pack Area
APF
Catalog
SMS
JES2
JES3
Sem isso...
todo o restante fica confuso.
Por quê?
Porque performance nunca acontece apenas no COBOL.
Ela acontece dentro do z/OS.
Etapa 2
Aprenda Arquitetura IBM Z
Conheça profundamente:
CPC
↓
Drawer
↓
Books
↓
CP
↓
zIIP
↓
ICF
↓
SAP
↓
LPAR
↓
PR/SM
↓
Channel Subsystem
↓
OSA
↓
FICON
↓
Coupling Facility
↓
Memory
↓
Cache
↓
HMC
↓
SE
Imagine o Seaview.
Antes de mergulhar você precisa conhecer:
motores
hélices
sonar
casco
radar
reator
O IBM Z também é um navio.
Etapa 3
CPU
Aqui começa o verdadeiro mundo da performance.
Aprenda:
CPU Time
Elapsed Time
Dispatch Time
Wait Time
SRB Time
TCB Time
PR/SM
Weight
LPAR
Logical CPU
Physical CPU
SMT
Vertical High
Vertical Medium
Vertical Low
Entenda:
GCP
zIIP
IFL
ICF
SAP
Nunca mais olhe apenas:
CPU = 90%
Pergunte:
90% de quê?
Etapa 4
Memória
Aprenda:
Frames
Pages
Paging
Working Set
Central Storage
Expanded Storage (história)
Auxiliary Storage
Frames Reais
Virtual Storage
Buffer Pool
Hiperspace
Data Spaces
Memory Objects
A memória explica inúmeros problemas aparentemente "misteriosos".
Etapa 5
I/O
Talvez o assunto mais importante.
Estude:
Channel
CU
Device
Volume
Cache
FICON
IOSQ
Pending
Connect
Disconnect
Response Time
EXCP
DASD
FlashSystem
RAID
Storage Class
SMS
Cache Miss
Write Pending
Buffering
Sem dominar I/O...
não existe engenheiro de performance.
Easter Egg
Na série Viagem ao Fundo do Mar...
o sonar era mais importante que o periscópio.
No Mainframe...
o I/O costuma ser mais importante que CPU.
Segundo Ano
Agora você começa a estudar subsistemas.
CICS
Aprenda:
Task
Transaction
Program
COMMAREA
Channel
Threadsafe
QR
L8
Open TCB
MXT
SOS
DSALIM
Storage
Temporary Storage
Transient Data
Journal
Mirror
TOR
AOR
FOR
Pipeline
IPIC
MRO
ISC
EXCI
Performance CICS é um universo inteiro.
Db2
Estude:
Access Path
RUNSTATS
REBIND
Package
Plan
RID List
Getpage
Prefetch
Index
Cluster Ratio
Lock
Latch
Buffer Pool
Sort
Stage 1
Stage 2
CPU SQL
RID Overflow
Parallelism
Dynamic SQL
Static SQL
Performance Db2 é quase uma especialização própria.
MQ
Aprenda:
Queue
Channel
Trigger
Persistent
Non Persistent
Commit
Rollback
Backout
Depth
Dead Letter Queue
Transmission Queue
Cluster
MQ também impacta performance.
IMS
Mesmo que nunca utilize...
conheça.
Principalmente:
DL/I
PSB
PCB
Database
Fast Path
Message Queue
TM
DB
WLM
Aqui mora a inteligência do z/OS.
Aprenda:
Service Class
Report Class
Velocity
Response Time
Importance
Goals
Classification
Policy
Performance sem WLM...
é impossível.
Ferramentas
Agora sim.
Chegou a hora.
RMF
Aprenda:
Monitor I
Monitor II
Monitor III
Postprocessor
Reports
SMF
Este será seu melhor amigo.
Conheça:
SMF 30
SMF 70
SMF 72
SMF 74
SMF 80
SMF 100
SMF 101
SMF 110
SMF 115
SMF 116
Cada registro conta uma história.
SDSF
Domine completamente.
Aprenda:
DA
ST
H
LOG
INPUT
OUTPUT
JESMSGLG
JESJCL
SYSOUT
OMEGAMON
Depois:
OMEGAMON
z/OS
CICS
Db2
MQ
Storage
Network
IntelliMagic Vision
Aprenda:
Health Insights
Topology
Trend
Change Detection
Capacity
Forecast
Anomaly
Correlation
Drill Down
Rating
É uma das ferramentas mais impressionantes existentes hoje.
Estatística
Surpresa.
Todo engenheiro de performance precisa entender estatística.
Não avançada.
Mas suficiente.
Estude:
Média
Moda
Mediana
Percentil
Desvio Padrão
Correlação
Distribuição
Outlier
Baseline
Forecast
Sazonalidade
Sem estatística...
não existe Capacity Planning.
Capacity Planning
Depois de dominar performance...
aprenda previsão.
Pergunte:
Quando acabará CPU?
Quando acabará memória?
Quando precisaremos de outro CPC?
Quando o licenciamento aumentará?
Como reduzir MSU?
Como aproveitar melhor zIIP?
Custos
Aqui está um assunto que quase ninguém ensina.
Performance também significa dinheiro.
Um SQL ruim pode custar milhares de horas de CPU por mês.
Um loop desnecessário pode aumentar MSUs.
Uma política WLM inadequada pode provocar desperdício.
Um buffer pool pequeno pode multiplicar leituras físicas.
Um zIIP subutilizado pode elevar custos de software.
O melhor engenheiro de performance pensa como um engenheiro e como um gestor.
O Que Ler
Monte sua biblioteca.
IBM Redbooks
IBM Documentation
RMF User Guide
SMF Manuals
Principles of Operation
DFSMS Redbooks
Db2 Performance Guides
CICS Performance Guide
WLM Redbooks
Enterprise COBOL Programming Guide
Arquitetura de Computadores
Sistemas Operacionais
Estatística
Filas
Teoria das Filas
Capacity Planning
AIOps
Observabilidade
O Que Praticar
Leia SMFs.
Analise RMFs.
Observe gráficos.
Faça comparações.
Monte dashboards.
Descubra gargalos.
Correlacione métricas.
Explique resultados.
Escreva relatórios.
Ensine outras pessoas.
Ensinar acelera o aprendizado.
O Perfil Ideal
O engenheiro de performance gosta de:
✔ investigar
✔ medir
✔ comparar
✔ questionar
✔ procurar padrões
✔ estudar arquitetura
✔ entender negócios
✔ resolver problemas difíceis
Ele é menos "programador".
E mais "cientista".
A Evolução da Carreira
O caminho normalmente segue algo parecido com:
Programador COBOL
↓
Programador Sênior
↓
Especialista CICS/Db2
↓
Analista Técnico
↓
Performance Analyst
↓
Capacity Planner
↓
System Performance Engineer
↓
IBM Z Architect
↓
Enterprise Performance Consultant
↓
Chief Performance Engineer
Não existe pressa.
Existe evolução contínua.
Curiosidades Bellacosa
☕ Um único dia de operação de um grande banco pode produzir milhões de registros SMF.
☕ Muitos problemas atribuídos ao COBOL têm origem em SQL, storage, WLM ou infraestrutura.
☕ O melhor relatório de performance é aquele que explica o impacto no negócio, não apenas os números.
☕ A maioria dos grandes especialistas em performance começou como programador ou operador e desenvolveu a capacidade de conectar métricas, arquitetura e processos de negócio.
☕ Ferramentas modernas como IBM Z IntelliMagic Vision aceleram a análise, mas não substituem o conhecimento de arquitetura. Elas ajudam o especialista a enxergar mais rápido, mas é o especialista quem transforma dados em decisões.
Missão Final – A Última Viagem do Seaview
Depois de anos estudando, você retorna ao centro de controle do USS Seaview.
O sonar detecta uma anomalia.
Os alarmes começam.
Todos olham para você.
Ninguém pergunta:
"Qual é a CPU?"
Perguntam:
"O que está acontecendo?"
Você consulta RMF, SMF, OMEGAMON, IntelliMagic Vision, WLM e os monitores dos subsistemas. Em poucos minutos percebe que o problema não está na CPU, nem no CICS, nem no Db2.
Um volume de storage apresenta aumento no tempo de resposta, gerando filas de I/O, elevando o tempo de espera das transações e causando degradação em cascata.
Você explica a causa, demonstra as evidências, estima o impacto no negócio e propõe a correção.
Nesse instante, você deixa de ser apenas um programador COBOL.
Você se torna um verdadeiro Engenheiro de Performance em Mainframe.
Porque, no universo Bellacosa Mainframe, performance não é decorar relatórios.
É aprender a ouvir o sonar invisível do IBM Z antes que o oceano inteiro perceba que existe um problema.
