 |
| Bellacosa Mainframe capacity planning |
☕ Um Café no Bellacosa Mainframe
🐗 ASTERIX, OBELIX E O CAPACITY PLANNING DA ALDEIA QUE RESISTIA AOS INCIDENTES
COBOL, SMF, RMF, WLM, CICS, Db2, MQ, CPU, I/O, filas, latência, observabilidade, performance, forecasting — e o dia em que Obelix descobriu que capacidade infinita só existe para quem caiu no caldeirão quando era pequeno.
🎬 PRÓLOGO — TODA A GÁLIA ESTÁ OCUPADA...
Estamos no ano 50 antes de Cristo.
Toda a Gália foi ocupada pelos romanos.
Toda?
Não!
Uma pequena aldeia povoada por irredutíveis gauleses ainda resiste ao invasor.
Séculos depois, algo muito parecido acontece dentro de um enorme datacenter.
Toda a empresa foi tomada por containers, microsserviços, Kubernetes, APIs, dashboards coloridos e aplicações distribuídas.
Toda?
Não!
No centro do datacenter existe uma pequena — bem, pequena é modo de dizer — plataforma que continua processando milhões de transações.
O mainframe.
Na entrada dessa aldeia digital encontramos um jovem programador COBOL.
Ele olha assustado para uma tela do SDSF.
CPU UTILIZATION = 92%
Ele arregala os olhos.
— Asterix! Temos um incidente! A CPU está em 92%!
Asterix observa tranquilamente.
Obelix chega carregando dois javalis e pergunta:
— Podemos bater nos romanos?
— Ainda não, Obelix.
Panoramix aparece segurando uma concha de sua poção mágica.
Ele olha para o jovem programador e pergunta:
— 92% de quê? Durante quanto tempo? Para qual workload? Em qual LPAR? Qual era o volume de transações? Qual era o objetivo definido no WLM? Houve fila? O SLA foi violado?
Silêncio.
O jovem programador olha novamente para a tela.
Naquele momento começa nossa aventura.
Porque um número sem contexto não é diagnóstico.
🏛️ CAPÍTULO 1 — A ALDEIA CHAMADA z/OS
Imagine o z/OS como nossa aldeia gaulesa.
Dentro dela existem muitos moradores:
ALDEIA z/OS
┌─────────────────────────────┐
│ │
│ COBOL CICS │
│ │
│ Db2 IMS │
│ │
│ MQ VSAM │
│ │
│ JES2 USS │
│ │
│ RACF WLM │
│ │
└─────────────────────────────┘
Todos compartilham recursos.
CPU.
Memória.
I/O.
DASD.
Canais.
Filas.
Locks.
Cada workload possui características diferentes.
Uma transação de cartão precisa responder rapidamente.
Um relatório pode esperar um pouco.
Um batch de fechamento talvez possa consumir enormes quantidades de recursos durante a madrugada.
O primeiro erro do jovem Padawan COBOL é imaginar que o mainframe executa apenas seu programa.
Não.
Seu programa vive dentro de um ecossistema.
E performance é consequência da interação entre essas partes.
🔭 CAPÍTULO 2 — ASTERIX DESCOBRE A OBSERVABILIDADE
Certo dia, chega uma mensagem:
“O sistema está lento.”
Essa talvez seja uma das frases mais perigosas da informática.
Asterix pergunta:
— Qual sistema?
— O sistema.
— Qual transação?
— Todas.
— Desde quando?
— Hoje.
Isso não é diagnóstico.
Isso é o início de uma investigação.
Monitoramento normalmente responde perguntas conhecidas:
CPU está alta?
CICS está UP?
Db2 está disponível?
MQ está funcionando?
Há espaço em DASD?
Observabilidade vai além.
Ela permite investigar:
Por que o comportamento mudou?
Imagine:
Response Time
↑
2s| ███
| ██ ██
1s|____________________█ █____
|
+--------------------------------→ tempo
14:32
O monitoramento diz:
ALERTA:
Response Time > 2 segundos
Ótimo.
Agora Asterix pergunta:
POR QUÊ?
E abre-se um exército de suspeitos:
LENTIDÃO
│
┌──────────────┼──────────────┐
│ │ │
CPU Db2 I/O
│ │ │
WLM LOCK DASD
│ │ │
CICS MQ REDE
│ │ │
STORAGE FILA CÓDIGO
Observabilidade existe para transformar esses suspeitos em evidências.
🧙 CAPÍTULO 3 — PANORAMIX E OS INGREDIENTES DA POÇÃO
Panoramix explica que uma boa observabilidade possui ingredientes.
Os três famosos são:
METRICS
LOGS
TRACES
Mas na aldeia do z/OS podemos acrescentar uma enorme quantidade de registros e eventos operacionais.
Temos:
SMF
RMF
SYSLOG
OPERLOG
JES
SDSF
CICS logs
Db2 traces
MQ events
RACF records
Panoramix coloca tudo no caldeirão.
Obelix tenta beber.
— Você não, Obelix!
O objetivo não é simplesmente acumular dados.
Esse é um ponto fundamental.
Uma empresa pode armazenar terabytes de logs e ainda possuir péssima observabilidade.
Observabilidade não significa:
“Tenho muitos dados.”
Significa:
“Consigo utilizar esses dados para compreender o comportamento do sistema.”
📜 CAPÍTULO 4 — SMF, O ESCRIBA DA ALDEIA
Toda boa aldeia precisa de alguém registrando o que aconteceu.
No z/OS existe um mecanismo extremamente importante:
System Management Facilities — SMF.
Imagine um escriba sentado no centro da aldeia.
Passa um job.
Ele anota.
Um workload consome recursos.
Ele registra.
Um subsistema executa determinada atividade.
Outro registro pode ser produzido.
Simplificando bastante:
z/OS
│
┌──────┼───────┐
│ │ │
JOBS CPU I/O
│ │ │
CICS Db2 MQ
│ │ │
└──────┼───────┘
▼
SMF
│
▼
RECORDS
│
▼
ANÁLISE
Existem numerosos tipos e subtipos de registros.
O iniciante frequentemente pergunta:
— Preciso decorar todos?
Não.
Asterix responde:
— Primeiro aprenda qual pergunta você está tentando responder.
Essa é uma excelente regra de performance.
Não comece pela ferramenta.
Comece pela pergunta.
📊 CAPÍTULO 5 — RMF E O ESCUDO DE ASTERIX
Se SMF registra uma enorme quantidade de acontecimentos, o Resource Measurement Facility — RMF ajuda a observar recursos e comportamento do sistema.
Pense no RMF como o painel de instrumentos da aldeia.
RMF
│
┌─────────────┼─────────────┐
│ │ │
CPU STORAGE I/O
│ │ │
WLM PAGING DEVICES
│ │
└─────────────┬─────────────┘
▼
PERFORMANCE
Agora encontramos outra armadilha.
CPU em 90% não significa automaticamente problema.
CPU em 30% também não significa automaticamente ambiente saudável.
A pergunta correta é:
O workload está conseguindo cumprir seus objetivos?
Podemos ter 90% de CPU com excelentes tempos de resposta.
E podemos ter 30% de CPU enquanto determinada aplicação sofre esperando locks, I/O ou algum recurso externo.
Performance exige contexto.
🚦 CAPÍTULO 6 — WLM, O ABRACURCIX DOS WORKLOADS
Abracurcix, o chefe da aldeia, possui um problema.
Todo mundo quer alguma coisa.
O ferreiro quer trabalhar.
O peixeiro quer vender peixe.
Obelix quer javalis.
Asterix precisa expulsar os romanos.
E o bardo Assurancetourix quer cantar.
Este último talvez possa esperar.
No z/OS temos problema semelhante.
Diferentes workloads disputam recursos.
Entra o Workload Manager — WLM.
Simplificando:
RECURSOS
│
WLM
│
┌────────────┼────────────┐
│ │ │
ONLINE BATCH RELATÓRIO
│ │ │
importante importante pode esperar
WLM trabalha com conceitos como:
service classes;
goals;
importance;
periods;
workloads.
Não pense nele simplesmente como uma tabela fixa de prioridades.
A ideia é muito mais interessante:
gerenciar recursos procurando atender objetivos de serviço definidos para os workloads.
Isso aproxima tecnologia de negócio.
⏱️ CAPÍTULO 7 — OBELIX DESCOBRE QUE RESPONSE TIME NÃO É CPU TIME
Chega uma transação demorando:
1.800 ms
Obelix declara:
— O COBOL gastou 1,8 segundo!
Panoramix quase deixa cair o caldeirão.
Não necessariamente.
Response time pode conter diversos componentes.
Didaticamente:
RESPONSE TIME
│
├── CPU
├── I/O Wait
├── Db2 Wait
├── Lock Wait
├── Queue
├── Dispatch Delay
├── Network
└── outros tempos
Imagine:
Response Time ........ 1800 ms
CPU .................. 110 ms
Db2 .................. 420 ms
I/O .................. 260 ms
Lock .................. 650 ms
Queue/Dispatch ........ 260 ms
Network ............... 100 ms
Nosso COBOL efetivamente consumiu apenas uma parcela daquele tempo.
Se o programador passar uma semana tentando economizar 10 ms de CPU enquanto existem 650 ms relacionados a lock, ele está atacando o romano errado.
🕵️ CAPÍTULO 8 — ASTERIX INVESTIGA O INCIDENTE
Asterix cria um método:
SINTOMA
↓
ESCOPO
↓
MÉTRICAS
↓
CORRELAÇÃO
↓
HIPÓTESE
↓
EVIDÊNCIA
↓
CAUSA
↓
CORREÇÃO
↓
VALIDAÇÃO
Recebemos:
“CICS está lento.”
Primeira pergunta:
Desde quando?
Depois:
Todas as transações?
Depois:
Uma região?
Um programa?
Uma API específica?
Uma LPAR?
Um horário?
Agora correlacionamos.
14:00 normal
14:15 deploy
14:20 Db2 calls ↑
14:22 I/O ↑
14:25 Response Time ↑
14:30 reclamações
De repente temos uma história.
Isso é muito mais útil do que observar cinco dashboards isoladamente.
🧮 CAPÍTULO 9 — O JAVALI PRECISA DE DENOMINADOR
Obelix comeu ontem:
10 javalis
Hoje:
13 javalis
Asterix anuncia:
— Seu consumo aumentou 30%!
Matematicamente correto.
Mas imagine que ontem Obelix enfrentou 100 romanos e hoje enfrentou 200.
Precisamos de contexto.
No mainframe:
CPU ontem = 1000 segundos
CPU hoje = 1300 segundos
Parece pior.
Mas:
Ontem:
1.000.000 transações
Hoje:
1.500.000 transações
Então precisamos analisar também algo como:
CPU / transação
Apesar de a CPU total ter aumentado, o custo por transação pode ter diminuído.
Essa ideia é poderosíssima.
Podemos acompanhar:
CPU / transaction
CPU / customer
CPU / order
CPU / batch record
I/O / transaction
SQL / transaction
messages / transaction
Estamos aproximando a linguagem técnica da linguagem do negócio.
💾 CAPÍTULO 10 — OBELIX E OS QUATRO MILHÕES DE EXCPS
Nosso jovem COBOL escreve:
PERFORM UNTIL WS-EOF = 'S'
READ ARQUIVO
...
END-PERFORM.
Funciona.
Então ele pergunta:
— Está bom?
Asterix responde:
— Quantos registros?
10.000?
10.000.000?
1.000.000.000?
E como eles são acessados?
Sequencialmente?
Aleatoriamente?
VSAM?
Db2?
Qual é o comportamento de buffers?
Qual é o padrão de I/O?
Compare:
PROGRAMA A
CPU ........ 40 segundos
EXCP ....... 80.000
com:
PROGRAMA B
CPU ........ 45 segundos
EXCP ....... 4.000.000
Olhando somente CPU, parecem próximos.
Olhando I/O, descobrimos dois animais completamente diferentes.
🗄️ CAPÍTULO 11 — O ROMANO ESCONDIDO DENTRO DO Db2
Considere:
EXEC SQL
SELECT NOME,
SALDO
INTO :WS-NOME,
:WS-SALDO
FROM CLIENTE
WHERE CPF = :WS-CPF
END-EXEC.
O COBOL parece inocente.
Mas por trás podem existir:
INDEX
ACCESS PATH
BUFFER POOL
GETPAGE
I/O
LOCK
SORT
STATISTICS
CONCURRENCY
Por isso:
PROGRAMA LENTO
não significa automaticamente:
COBOL LENTO
Talvez o access path tenha mudado.
Talvez a tabela tenha crescido.
Talvez existam estatísticas inadequadas.
Talvez tenhamos lock contention.
O programador COBOL moderno precisa aprender a enxergar além do código COBOL.
📬 CAPÍTULO 12 — O CORREIO DE OBELIX CHAMADO MQ
Imagine IBM MQ.
Produtor:
5.000 mensagens/s
Consumidor:
4.500 mensagens/s
Tudo está UP.
Queue Manager funcionando.
Channels funcionando.
Aplicações funcionando.
Mas temos:
+500 mensagens/s
acumulando.
Depois de uma hora:
500 × 3600
=
1.800.000 mensagens
Nada necessariamente “caiu”.
Mesmo assim temos um incidente em formação.
Por isso não basta perguntar:
MQ está UP?
Precisamos observar também:
Queue Depth
Arrival Rate
Consumption Rate
Oldest Message Age
Retries
DLQ
Latency
Channel Status
Essa é uma das diferenças entre disponibilidade e observabilidade.
🌙 CAPÍTULO 13 — A BATALHA DA JANELA BATCH
Quando a aldeia dorme, começam os jobs.
22:00 ─────────────────────── 06:00
BATCH WINDOW
Hoje:
JOB A 22:00 → 23:00
JOB B 23:00 → 01:30
JOB C 01:30 → 03:00
JOB D 03:00 → 04:30
Tudo perfeito.
Mas o negócio cresce 10% ao mês.
Pouco a pouco:
Mês 1 █████████████
Mês 2 ███████████████
Mês 3 █████████████████
Mês 4 ████████████████████
Até que:
BATCH ────────────────────────→
│
▼
06:00 ONLINE
A janela estourou.
E é aqui que aparece nosso terceiro personagem:
Capacity Planning.
🔮 CAPÍTULO 14 — PANORAMIX NÃO TEM POÇÃO DE CAPACIDADE INFINITA
Capacity Planning não significa esperar CPU chegar a determinado percentual e comprar uma máquina maior.
A pergunta correta é:
Com a capacidade atual, crescimento previsto, perfil dos workloads e objetivos de serviço, durante quanto tempo conseguiremos atender a demanda de maneira sustentável?
Precisamos combinar:
CAPACIDADE ATUAL
+
UTILIZAÇÃO
+
CRESCIMENTO
+
SAZONALIDADE
+
NOVAS APLICAÇÕES
+
ROADMAP
+
EFICIÊNCIA
+
OBJETIVOS DE SERVIÇO
=
CAPACITY PLANNING
Isso muda completamente a conversa.
📈 CAPÍTULO 15 — QUAL É O NORMAL DA ALDEIA?
Antes de detectar uma anomalia, precisamos conhecer o normal.
Chamamos isso de baseline.
Imagine:
00h ███
02h █████████████
04h ██████████
06h ████
10h ████████
12h ███████████
18h █████
22h █████████
CPU alta às 02:00 pode ser completamente normal.
Talvez seja fechamento diário.
Então:
alto não significa anormal.
E:
baixo não significa saudável.
Baseline nos permite perguntar:
Esse comportamento é esperado para esse workload, nesse horário, nesse dia e com esse volume?
🎄 CAPÍTULO 16 — OS ROMANOS ATACAM NA BLACK FRIDAY
Médias podem ser perigosas.
Imagine:
CPU média diária = 55%
Parece confortável.
Mas escondemos:
00h ───────────────────────────── 24h
30% 35% 40% 98% 99% 35% 30%
↑─────↑
PEAK
Se essas duas horas representam o horário crítico de Black Friday, a média de 55% é praticamente inútil para entender o risco.
Capacity Planning precisa conhecer:
peak hour
peak interval
peak day
sazonalidade
eventos especiais
O mesmo ocorre com latência.
Uma média:
300 ms
pode esconder:
P50 = 180 ms
P95 = 900 ms
P99 = 4,8 s
Para uma pequena parcela dos clientes, o sistema pode estar terrível enquanto a média continua bonita.
💰 CAPÍTULO 17 — ASTERIX DESCOBRE QUE MILISSEGUNDO VALE DINHEIRO
Antes:
CPU / transaction = 8 ms
Depois da otimização:
CPU / transaction = 6 ms
Economizamos:
2 ms
Obelix ri.
— Dois milissegundos?
Agora multiplicamos por:
100.000.000 transações/mês
Temos:
0,002 × 100.000.000
=
200.000 CPU seconds
Aproximadamente:
55,6 CPU hours
Agora Obelix para de rir.
Em sistemas de enorme escala:
pequenas economias multiplicadas milhões de vezes deixam de ser pequenas.
Performance também possui dimensão econômica.
🚨 CAPÍTULO 18 — UTILIZAÇÃO NÃO É SATURAÇÃO
Imagine a taberna gaulesa.
Existem 20 mesas.
18 estão ocupadas.
Utilização = 90%
Mas ninguém espera.
Agora temos:
20 mesas ocupadas
+ 40 gauleses esperando
O recurso está saturado.
Essa distinção é essencial.
Utilização pergunta:
Quanto do recurso está sendo utilizado?
Saturação pergunta:
Existe trabalho esperando porque o recurso não consegue atendê-lo imediatamente?
Por isso investigamos:
queues
waits
contention
paging
locks
dispatch delay
I/O contention
Um gráfico de utilização sozinho nunca conta toda a história.
🚗 CAPÍTULO 19 — PANORAMIX APRESENTA LITTLE'S LAW
Panoramix escreve numa pedra:
L = λW
Obelix pergunta:
— Isso é receita de poção?
Quase.
Onde:
L = quantidade média de itens no sistema
λ = taxa média de chegada
W = tempo médio no sistema
Se recebemos:
500 transações/s
e cada uma permanece em média:
0,2 s
temos aproximadamente:
L = 500 × 0,2
L = 100
Cerca de 100 transações estão presentes simultaneamente nesse modelo simplificado.
Essa pequena equação conecta três conceitos fundamentais:
VOLUME
│
▼
CONCORRÊNCIA
│
▼
LATÊNCIA
Bem-vindo à teoria das filas.
🧪 CAPÍTULO 20 — O INCIDENTE DOS 100.000 SELECTS
Agora vamos juntar tudo.
Às 09:00:
Response Time = 250 ms
Às 10:30:
Response Time = 1800 ms
Asterix investiga.
CPU?
Normal.
Storage?
Normal.
I/O?
Um pouco maior.
Db2?
Espera aumentou.
Qual SQL?
Encontramos uma consulta disparando milhares de vezes.
E então descobrimos:
DEPLOY = 10:15
Alguém alterou:
PERFORM 100000 TIMES
EXEC SQL
SELECT ...
END-EXEC
END-PERFORM.
Agora conseguimos construir uma narrativa causal:
DEPLOY
↓
ALTERAÇÃO COBOL
↓
MAIS SQL
↓
MAIS Db2 CALLS
↓
MAIS I/O
↓
MAIS CONTENÇÃO
↓
MAIOR RESPONSE TIME
↓
SLA VIOLADO
Isso é observabilidade.
Não:
CPU = 63%
Mas:
uma cadeia de evidências explicando o comportamento do serviço.
🧬 CAPÍTULO 21 — PERFORMANCE ENTRA NO CI/CD
E por que esperar produção?
Nosso pipeline poderia evoluir:
Git
│
▼
Build
│
▼
Unit Test
│
▼
Integration Test
│
▼
Performance Test
│
▼
Baseline Comparison
│
▼
Quality Gate
│
▼
Deploy
│
▼
Observability
Imagine:
VERSÃO ATUAL
CPU/transação = 4,1 ms
Nova versão:
CPU/transação = 5,8 ms
Funcionalmente:
PASS
Mas performance:
+41%
Precisamos pelo menos investigar antes de produção.
Essa é uma mudança cultural enorme.
Performance deixa de ser assunto apenas do pessoal que aparece depois do incidente.
Passa a fazer parte do ciclo de engenharia.
🤖 CAPÍTULO 22 — O DRUIDA DIGITAL: AIOps
Agora imagine décadas de dados operacionais.
SMF.
RMF.
CICS.
Db2.
MQ.
Logs.
Eventos.
Temos material excelente para:
Anomaly Detection
Forecasting
Correlation
Pattern Recognition
Capacity Forecast
Incident Clustering
Change Analysis
Uma IA não precisa simplesmente avisar:
CPU > 90%
Isso um threshold consegue fazer.
Algo mais interessante seria:
“Esse comportamento está significativamente diferente do baseline histórico desse workload para quintas-feiras entre 14:00 e 15:00.”
Melhor ainda:
CPU ........ comportamento normal
Db2 ........ comportamento normal
CICS ....... comportamento normal
MQ Depth ... +317% sobre baseline
Agora temos uma pista relevante.
🧭 CAPÍTULO 23 — OS QUATRO SINAIS DA ALDEIA
Para o jovem programador COBOL, podemos começar com quatro perguntas.
Latency
Quanto demora?
CICS response time
Db2 elapsed
MQ latency
batch elapsed
API response
Traffic
Quanto trabalho está chegando?
TPS
transactions
messages/sec
records
SQL calls
requests
Errors
Quanto está falhando?
ABEND
SQLCODE
CICS errors
MQ failures
JCL failures
timeouts
Saturation
Estamos chegando ao limite?
CPU
storage
I/O
queues
locks
paging
WLM delays
Sempre que receber:
“Está lento.”
Pense nesses quatro grupos.
🪜 CAPÍTULO 24 — O CAMINHO DO PADAWAN COBOL
Eu estudaria performance em camadas.
Nível 1 — aplicação
COBOL
JCL
CICS
Db2
VSAM
MQ
Entenda primeiro aquilo que está executando.
Nível 2 — métricas
CPU
Elapsed
EXCP
Response Time
Transactions
Throughput
Aprenda a medir.
Nível 3 — plataforma
SMF
RMF
SDSF
WLM
Aprenda de onde vêm as evidências.
Nível 4 — investigação
baseline
correlation
bottleneck
contention
queue
wait
Aprenda a encontrar relações.
Nível 5 — capacidade
trend
forecast
growth
peak
saturation
headroom
Aprenda a olhar para amanhã.
Nível 6 — enterprise
APM
OpenTelemetry
dashboards
AIOps
hybrid cloud
business observability
Agora você consegue acompanhar uma jornada atravessando plataformas.
🗺️ CAPÍTULO 25 — PASSO A PASSO PARA INVESTIGAR “ESTÁ LENTO”
Guarde este pequeno roteiro.
Quando alguém disser:
“O sistema está lento.”
Não saia alterando COBOL.
Pergunte:
Passo 1 — Quando começou?
Determine intervalo.
Passo 2 — Qual é o escopo?
Uma transação?
Uma aplicação?
Uma região CICS?
Todos os usuários?
Passo 3 — O volume mudou?
Compare TPS, registros, mensagens ou usuários.
Passo 4 — O que mudou?
deploy
configuração
Db2
JCL
WLM
rede
infraestrutura
volume
Passo 5 — Separe CPU de elapsed time.
Não trate os dois como sinônimos.
Passo 6 — Procure waits.
I/O
Db2
lock
MQ
queue
dispatch
Passo 7 — Compare com baseline.
Pergunte:
Isso já aconteceu nesse horário?
Passo 8 — Correlacione eventos.
Procure o primeiro indicador que mudou.
Passo 9 — Forme uma hipótese.
Não uma opinião.
Uma hipótese testável.
Passo 10 — Valide.
Depois da correção, compare novamente as métricas.
Sem validação, você não sabe se realmente resolveu.
🐗 CAPÍTULO 26 — CURIOSIDADES DA ALDEIA
Curiosidade 1
Mainframes historicamente geram uma quantidade extraordinária de telemetria operacional.
A dificuldade muitas vezes não é conseguir informação.
É transformá-la em conhecimento.
Curiosidade 2
Um programa pode utilizar menos CPU e ainda ficar mais lento.
Basta aumentar tempo de espera.
Curiosidade 3
Um sistema pode estar 100% disponível e operacionalmente doente.
A fila MQ crescendo continuamente é um excelente exemplo.
Curiosidade 4
Otimização local pode piorar o sistema global.
Aumentar paralelismo pode diminuir o elapsed de um batch enquanto prejudica outros workloads.
Curiosidade 5
A média pode esconder justamente os clientes que estão sofrendo.
Por isso percentis e distribuição são tão interessantes.
🥚 EASTER EGG — O INCIDENTE DAS 03:17
Certa madrugada, exatamente:
03:17
o alarme dispara.
Obelix corre para a sala:
— ROMANOS!
Não.
CPU normal.
CICS normal.
Db2 normal.
MQ normal.
Mesmo assim o batch está atrasado.
Asterix investiga.
Descobre que um pequeno job aparentemente insignificante atrasou.
Ele era predecessor de outro.
Que era predecessor de outro.
Que era predecessor de 47 outros jobs.
O pequeno job consumia quase nada.
Mas estava no critical path.
Moral do Easter Egg:
O componente que mais consome recursos nem sempre é o componente mais importante para a performance do serviço.
Às vezes um job de poucos segundos possui impacto maior no negócio do que outro que consome horas de CPU.
E sim...
03:17.
Quem acompanha o Bellacosa Mainframe já deveria desconfiar desse horário.
🏁 EPÍLOGO — POR TUTATIS, NÃO É SÓ CPU!
Depois de meses de treinamento, nosso jovem programador recebe novamente:
CPU = 92%
Obelix pergunta:
— Não vai abrir incidente?
O programador responde:
— Ainda não.
Asterix sorri.
O jovem continua:
— Quero saber qual workload está utilizando essa CPU, qual era o volume naquele intervalo, como está o response time, se existe saturação, como estão os goals do WLM, se houve mudança no comportamento de CICS, Db2, MQ ou I/O e como isso se compara ao baseline.
Panoramix sorri.
O treinamento funcionou.
Porque agora ele compreendeu:
OBSERVABILIDADE
│
▼
O QUE ESTÁ ACONTECENDO?
│
▼
PERFORMANCE
│
▼
POR QUE ESTÁ ACONTECENDO?
│
▼
CAPACITY PLANNING
│
▼
O QUE PODERÁ ACONTECER?
│
▼
ENGENHARIA
│
▼
O QUE FAREMOS ANTES?
Essa última pergunta talvez seja a mais importante de todas.
Um ambiente imaturo descobre falta de capacidade quando produção começa a sofrer.
Um ambiente maduro observa tendências.
Um engenheiro de performance procura gargalos.
Um Capacity Planner projeta crescimento.
E uma organização verdadeiramente observável consegue relacionar:
INFRAESTRUTURA
+
APLICAÇÃO
+
WORKLOAD
+
EXPERIÊNCIA
+
NEGÓCIO
Não queremos descobrir durante a Black Friday que o sistema precisava de mais capacidade.
Não queremos descobrir durante o fechamento que nossa janela batch deixou de caber na madrugada.
Não queremos descobrir depois de milhões de mensagens acumuladas que nossos consumidores MQ eram mais lentos que os produtores.
Queremos descobrir tudo isso meses antes.
Talvez numa terça-feira tranquila.
CPU em 63%.
CICS respondendo perfeitamente.
Db2 saudável.
MQ vazio.
Nenhum ABEND.
Nenhum romano à vista.
Asterix sentado sob uma árvore.
Obelix assando um javali.
E Panoramix olhando silenciosamente para um gráfico aparentemente inocente que mostra:
Capacity
100% | X
| /
80% | __/
| __/
60% | __/
| __/
40% |__________/
|
+----------------------------→ tempo
HOJE +8 meses
Ele aponta para o futuro e diz:
— É ali que teremos um problema.
Obelix olha para o gráfico.
Depois olha para o caldeirão.
— Então precisamos fazer mais poção?
Panoramix responde:
— Não, Obelix.
— Precisamos fazer Capacity Planning.
E enquanto toda a empresa continua discutindo se mainframe é antigo ou moderno, nossa pequena aldeia continua processando bilhões de transações.
Porque capacidade não é magia.
Performance não é chute.
Observabilidade não é um dashboard cheio de gráficos.
E um verdadeiro engenheiro de mainframe não espera os romanos chegarem aos portões para começar a contar quantos são.
Por Tutatis! Meça primeiro. Correlacione depois. Planeje antes. ☕🐗🖥️
Sem comentários:
Enviar um comentário