 |
| Bellacosa Mainframe latency, throughput, availability e capacity |
☕ Um Café no Bellacosa Mainframe
🔧 WINRY ROCKBELL E A OFICINA DOS TRÊS PONTEIROS DO MAINFRAME
Latency, Throughput, Availability, Capacity, COBOL, CICS, Db2, MQ, WLM, SMF, RMF, Parallel Sysplex, filas, percentis, locks, COMMIT — e o dia em que Winry descobriu que trocar a CPU não consertava uma transação esperando 4 segundos por um lock.
Sob a tutela de Winry Rockbell, de Fullmetal Alchemist: porque antes de trocar uma peça cara, um bom mecânico descobre exatamente onde a máquina está rangendo.
🎬 PRÓLOGO — WINRY, TEM ALGUMA COISA ERRADA COM O MAINFRAME!
O jovem programador COBOL entrou correndo na oficina carregando um relatório de produção.
— Winry! Temos um problema!
Winry Rockbell nem levantou a cabeça.
Continuou ajustando uma pequena engrenagem sobre a bancada.
— Quebrou?
— Pior. Está lento.
Agora ela parou.
— O que está lento?
Silêncio.
— O... sistema.
Winry colocou a chave sobre a bancada.
— Qual sistema?
— O mainframe.
Ela respirou fundo.
— Qual aplicação? Qual transação? Qual horário? Qual volume? Qual tempo de resposta? Qual percentil? Está consumindo CPU ou esperando? Existe fila? O Db2 está esperando lock? O CICS está saturado? O MQ está acumulando mensagens? Houve aumento de workload?
O programador ficou olhando.
— Eu só ia dizer que o COBOL estava lento.
Winry pegou a chave inglesa novamente.
— Então você ainda não sabe se o COBOL está lento.
E assim começou nossa aula.
Porque existem três números que aparecem repetidamente quando estudamos sistemas computacionais:
Latency. Throughput. Availability.
Mas, quando atravessamos a porta do datacenter e chegamos ao IBM Z, descobrimos rapidamente que existem outros personagens escondidos na oficina.
Principalmente:
Capacity, Reliability e Recoverability.
Vamos desmontar essa máquina peça por peça.
🔧 CAPÍTULO 1 — NÃO TROQUE A PEÇA ANTES DE DESCOBRIR O DEFEITO
Uma das grandes lições de uma boa mecânica é extremamente aplicável à computação:
sintoma não é causa.
O usuário diz:
"Está lento."
Isso é um sintoma.
Você ainda não sabe se o problema está em:
Rede
↓
API Gateway
↓
z/OS Connect
↓
CICS
↓
COBOL
↓
Db2
↓
StorageOu talvez exista MQ no caminho:
Aplicação
│
▼
API
│
▼
z/OS Connect
│
▼
CICS
│
▼
COBOL
│
├────────► Db2
│
└────────► MQ ─────► Outro sistemaSe o cliente esperou quatro segundos pela resposta, isso não significa que o programa COBOL executou durante quatro segundos.
Essa diferença é fundamental.
Temos que separar:
Response Time de Service Time, CPU Time e tempos de espera.
Imagine:
Tempo total percebido: 2.400 ms
CPU COBOL: 15 ms
Db2 processamento: 70 ms
Rede: 40 ms
CICS queue: 300 ms
Db2 lock wait: 1.800 ms
Outros: 175 ms
--------
TOTAL: 2.400 msO programa COBOL consumiu apenas 15 milissegundos de CPU.
Mesmo assim, alguém provavelmente abrirá o chamado:
"COBOL lento em produção."
Bem-vindo ao primeiro parafuso solto da nossa oficina.
⏱️ CAPÍTULO 2 — LATENCY: QUANTO TEMPO O CLIENTE FICOU ESPERANDO?
Latency responde, em sua forma mais simples:
Quanto tempo uma operação leva?
Em uma aplicação moderna integrada ao mainframe, poderíamos ter:
Usuário
│
│ REQUEST
▼
Internet
▼
API Gateway
▼
z/OS Connect
▼
CICS
▼
COBOL
▼
Db2
│
│ RESPONSE
▼
UsuárioO relógio começa quando a solicitação é enviada e termina quando a resposta relevante chega.
Suponha:
Request ─────────────────────────►
Server
Response ◄────────────────────────
120 msTemos uma latência de aproximadamente 120 ms para aquela observação.
Parece simples.
O problema começa quando alguém pergunta:
"Qual é a latência da aplicação?"
E alguém responde:
"120 ms."
Winry imediatamente perguntaria:
— 120 ms de quê? Quando? Para quem? Em qual percentil? Com qual carga?
Porque uma média isolada pode esconder um desastre.
📊 CAPÍTULO 3 — A MÉDIA É AQUELA PEÇA BONITA QUE ESCONDE A FERRUGEM
Imagine milhares ou milhões de transações.
O relatório mostra:
Average Response Time = 150 msExcelente?
Talvez.
Agora observamos a distribuição:
p50 = 110 ms
p90 = 170 ms
p95 = 250 ms
p99 = 2.100 ms
p99.9 = 6.500 msA história mudou.
p50 significa que 50% das observações ficaram naquele valor ou abaixo dele.
p95 indica que aproximadamente 95% ficaram naquele valor ou abaixo.
p99 mostra a fronteira abaixo da qual ficaram aproximadamente 99%.
Isso nos permite enxergar a chamada:
tail latency — latência de cauda.
E a cauda pode morder.
Se você processa 10 milhões de operações e 1% sofre comportamento ruim, não estamos falando de "só 1%".
Estamos falando potencialmente de:
10.000.000 × 1%
= 100.000 operaçõesA média pode continuar linda enquanto milhares de clientes estão irritados.
🔍 CAPÍTULO 4 — O MISTÉRIO DO p99
Imagine:
p50 = 90 ms
p95 = 140 ms
p99 = 4.000 msWinry não começaria trocando o processador.
Ela procuraria onde existe espera.
No mainframe poderíamos investigar hipóteses como:
Db2 lock wait
CICS dispatch delay
fila de transações
I/O
MQ backlog
TCP/IP
serviço externo
contenção
storage
limites de concorrência
WLMIsso nos ensina uma regra preciosa:
Latência não é sinônimo de CPU.
Um programa pode consumir pouquíssima CPU e apresentar péssimo response time.
Por quê?
Porque computadores também passam muito tempo esperando.
🚦 CAPÍTULO 5 — THROUGHPUT: QUANTOS CARROS PASSAM PELA OFICINA?
Se Latency pergunta:
Quanto tempo levou?
Throughput pergunta:
Quanto trabalho conseguimos processar por unidade de tempo?
Em aplicações web você encontrará muito:
RPS — Requests Per Second.
Em ambientes transacionais:
TPS — Transactions Per Second.
No universo mainframe podemos encontrar diferentes medidas, dependendo do workload:
transações/segundo
mensagens/segundo
registros/segundo
jobs/hora
MB/segundo
GB/horaImagine um sistema processando:
5.000 TPSEm um minuto:
5.000 × 60
= 300.000 transaçõesEm uma hora, se essa taxa fosse sustentada:
18.000.000Agora começamos a compreender por que throughput é tão importante em sistemas de grande volume.
🏎️ CAPÍTULO 6 — UMA FERRARI PRESA NUM PEDÁGIO CONTINUA PARADA
Aqui está um erro clássico:
"Minha transação executa em 10 ms, portanto meu sistema é rápido."
Não necessariamente.
Imagine que cada transação realmente possa executar rapidamente, mas o sistema consiga atender apenas dez simultaneamente.
Chegam 10.000 solicitações.
Temos:
REQUESTS
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
┌────────────────────┐
│ QUEUE │
│ QUEUE │
│ QUEUE │
│ QUEUE │
│ QUEUE │
└────────────────────┘
│
▼
SERVIÇOO código pode continuar rápido quando finalmente recebe recursos.
O usuário continuará esperando.
Winry apontaria para a fila:
— O motor não está quebrado. Você construiu uma estrada com um pedágio pequeno demais.
É aqui que Latency e Throughput começam a conversar.
🧮 CAPÍTULO 7 — LITTLE'S LAW ENTRA NA OFICINA
Existe uma relação extremamente elegante em teoria das filas conhecida como Little's Law:
L = λ × WSimplificando:
L = quantidade média de itens dentro do sistema
λ = taxa média de chegada/throughput em estado estável
W = tempo médio que cada item permanece no sistema
Imagine:
Throughput = 2.000 TPS
Tempo médio = 0,25 sEntão:
L = 2.000 × 0,25
L = 500Sob as premissas da lei, temos em média cerca de 500 transações dentro daquele sistema ou trecho analisado.
Agora a latência aumenta para um segundo:
L = 2.000 × 1
L = 2.000Temos muito mais trabalho simultaneamente em voo.
E aqui pode começar uma reação em cadeia:
mais workload
↓
mais concorrência
↓
mais filas
↓
mais espera
↓
mais latency
↓
mais transações pendentes
↓
mais contençãoEsse ciclo pode transformar uma pequena degradação em um incidente enorme.
🏛️ CAPÍTULO 8 — WLM: O CHEFE DA OFICINA
No z/OS existe um personagem importantíssimo nessa história:
WLM — Workload Manager.
Um iniciante pode imaginar gerenciamento de recursos simplesmente como:
"Programa A recebe CPU; programa B recebe CPU."
A realidade é muito mais sofisticada.
O WLM trabalha com conceitos como:
WORKLOAD
│
▼
SERVICE CLASS
│
▼
GOALS
│
▼
IMPORTANCEA organização descreve objetivos de serviço e importância para diferentes workloads, e o z/OS usa essas informações em sua gestão dinâmica de recursos.
Isso introduz uma mudança mental importante.
Em vez de perguntar somente:
"Quanto de CPU está sendo utilizado?"
pergunte também:
"Os objetivos de serviço estão sendo cumpridos?"
🔥 CAPÍTULO 9 — 90% DE CPU NÃO É NECESSARIAMENTE UM INCÊNDIO
O programador entra correndo:
— WINRY! CPU 90%!
Ela olha para o painel.
— E?
— Noventa por cento!
— Os objetivos estão sendo cumpridos?
— Sim.
— O throughput?
— Normal.
— Response time?
— Normal.
— Filas?
— Controladas.
— Então por que você quer desligar a máquina?
Essa é uma bela lição de performance.
Utilização alta não significa automaticamente problema.
Você comprou capacidade computacional para utilizá-la.
O inverso também é verdadeiro.
Você pode ter:
CPU = 35%e uma aplicação horrorosa.
Por exemplo:
CPU 35%
Db2 lock ██████████████████As CPUs não precisam estar saturadas para que usuários fiquem esperando.
🗄️ CAPÍTULO 10 — Db2 E O PARAFUSO QUE NINGUÉM CONSEGUIA SOLTAR
Vamos construir um incidente.
Às 10h:
Throughput = 3.200 TPS
p95 = 180 ms
p99 = 350 ms
Errors = 0,02%Às 11h30:
Throughput = 5.800 TPS
p95 = 900 ms
p99 = 4.800 ms
Errors = 2,1%Primeira suspeita:
CPU.
Mas CPU não explica o comportamento.
CICS parece razoável.
Então a investigação chega ao Db2.
Descobrimos:
LOCK WAIT ↑↑↑↑Uma transação está mantendo determinados locks durante muito mais tempo.
A corrente passa a ser:
Unit of Work longa
↓
locks permanecem
↓
outras transações esperam
↓
fila aumenta
↓
latency cresce
↓
timeouts
↓
retries
↓
mais workloadWinry sorri.
Encontramos a peça problemática.
💾 CAPÍTULO 11 — COMMIT NÃO É UM BOTÃO DE SALVAR
O iniciante COBOL precisa entender isso cedo.
Considere conceitualmente:
PERFORM 10000 TIMES
EXEC SQL
UPDATE ...
END-EXEC
END-PERFORM
EXEC SQL
COMMIT
END-EXECDependendo da aplicação, desenho das transações, isolamento e acesso aos dados, uma Unit of Work excessivamente longa pode contribuir para contenção e dificultar recuperação.
Mas cuidado.
A solução não é simplesmente:
"Coloque COMMIT depois de cada UPDATE."
Isso também pode ser errado.
A fronteira do COMMIT deve respeitar a unidade lógica do negócio.
Uma transferência bancária, por exemplo, não deveria terminar assim:
Debita conta A
COMMIT
💥 ABEND
Credita conta BParabéns.
Inventamos dinheiro desaparecendo.
O correto é projetar cuidadosamente a Unit of Work, considerando atomicidade, integridade, locking, logging, restart e recuperação.
Performance nunca deve destruir consistência.
📦 CAPÍTULO 12 — BATCH TAMBÉM TEM THROUGHPUT
Até agora falamos bastante sobre aplicações online.
Mas mainframe respira batch.
Imagine uma janela:
23:00 ───────────────────────── 05:00
BATCHDurante esse período precisamos executar:
Clearing
Settlement
Billing
Accounting
Reconciliation
ReportsSuponha que existam 500 milhões de registros para processar.
Perguntar:
"Quanto tempo levou um registro?"
pode ser muito menos importante do que:
"O processamento completo terminou antes das 05:00?"
Aqui throughput pode aparecer como:
records/sec
GB/hour
jobs/hour
elapsed timeEsse é um excelente exemplo de por que métricas precisam de contexto.
🟢 CAPÍTULO 13 — AVAILABILITY: A MÁQUINA ESTÁ LIGADA, MAS O CLIENTE NÃO CONSEGUE PAGAR
Chegamos ao terceiro ponteiro.
Availability pergunta:
Durante quanto tempo o serviço esteve disponível?
E aqui encontramos uma armadilha.
Imagine:
z/OS UP
CICS UP
Db2 UP
MQ UP
TCP/IP UPO operador diz:
"Tudo funcionando."
Mas existe uma dependência externa:
API Gateway = DOWNO cliente não consegue concluir a operação.
Quem está certo?
Tecnicamente, vários componentes estão funcionando.
Mas o serviço de negócio está indisponível para o cliente.
Portanto precisamos diferenciar:
component availability
de:
service availability.
Essa distinção é fundamental.
9️⃣ CAPÍTULO 14 — OS FAMOSOS NOVES
Disponibilidade costuma aparecer como porcentagem.
Considerando aproximadamente um ano de 365 dias:
| Disponibilidade | Indisponibilidade anual aproximada |
|---|---|
| 99% | 3 dias, 15h e 36min |
| 99,9% | 8h e 46min |
| 99,99% | 52min e 34s |
| 99,999% | 5min e 15s |
Parece existir pouca diferença entre:
99,9%e:
99,999%Só existem alguns noves extras.
Mas esses noves podem exigir mudanças profundas em arquitetura, operação e investimento.
Você começa a pensar em:
redundância
automação
failover
eliminação de SPOFs
replicação
observabilidade
capacity headroom
procedimentos operacionais
testes de recuperação
disaster recovery
resiliênciaCada nove adicional pode ser uma peça extremamente cara da oficina.
🏰 CAPÍTULO 15 — PARALLEL SYSPLEX E A OFICINA QUE NÃO PODIA FECHAR
No ecossistema IBM Z, uma tecnologia fundamental para alta disponibilidade e escalabilidade é o Parallel Sysplex.
Conceitualmente:
WORKLOAD
│
┌────────┴────────┐
│ │
▼ ▼
z/OS A z/OS B
│ │
└────────┬────────┘
│
COUPLING FACILITY
│
SHARED DATATemos múltiplas imagens z/OS capazes de cooperar dentro da arquitetura, com mecanismos sofisticados de coordenação e compartilhamento.
Mas Winry faria uma advertência:
Duas peças não significam automaticamente redundância real.
Se ambas dependem do mesmo ponto único de falha, o problema continua existindo.
Alta disponibilidade exige procurar os famosos:
SPOFs — Single Points of Failure.
💣 CAPÍTULO 16 — QUANDO LATENCY DESTRÓI AVAILABILITY
Agora conectaremos dois ponteiros.
Imagine:
CICS = UP
Db2 = UP
MQ = UPA transação responde em:
45 segundosMas o aplicativo móvel possui timeout de:
10 segundosPara o usuário:
O SERVIÇO CAIU.
Para a monitoração superficial:
TUDO VERDE.
Temos então uma descoberta importante:
Um sistema tecnicamente disponível pode estar funcionalmente indisponível.
Performance degradada pode atravessar uma fronteira e virar problema de disponibilidade.
🌪️ CAPÍTULO 17 — A TEMPESTADE DE RETRIES
Existe ainda algo pior.
O cliente faz uma requisição.
Ela demora.
O aplicativo recebe timeout.
Então tenta novamente.
REQUEST
↓
TIMEOUT
↓
RETRY
↓
mais carga
↓
mais fila
↓
mais latency
↓
mais TIMEOUT
↓
mais RETRYAcabamos de construir uma retry storm.
O mecanismo criado para aumentar resiliência começou a amplificar o incidente.
Essa é uma curiosidade maravilhosa da engenharia de sistemas:
Um mecanismo de proteção mal configurado pode se transformar em mecanismo de ataque contra o próprio sistema.
Por isso estratégias de retry costumam exigir coisas como limites, backoff, jitter, idempotência e entendimento da operação que está sendo repetida.
📐 CAPÍTULO 18 — CAPACITY: O QUARTO PONTEIRO ESCONDIDO
Latency, Throughput e Availability são excelentes conceitos.
Mas Winry encontra outro mostrador atrás do painel:
CAPACITY.
Capacity pergunta:
Quanto workload conseguimos sustentar mantendo os objetivos desejados?
Imagine testes mostrando:
4.000 TPS → p95 = 120 ms
6.000 TPS → p95 = 170 ms
8.000 TPS → p95 = 300 ms
9.000 TPS → p95 = 800 ms
9.500 TPS → p95 = 4.000 msVeja o comportamento:
Latency
│
│ /
│ /
│ __/
│ __/
│________________/
└──────────────────────────── TPS
↑
SATURAÇÃOExiste uma região em que adicionar workload provoca crescimento muito maior da latência.
Encontrar esse comportamento antes da Black Friday é muito mais agradável do que descobri-lo durante a Black Friday.
Isso é parte do espírito de Capacity Planning.
🔭 CAPÍTULO 19 — SMF E RMF: WINRY ENCONTRA O MANUAL DE MANUTENÇÃO
Como investigamos tudo isso?
O z/OS produz uma quantidade extraordinária de telemetria.
Dois nomes precisam entrar cedo no vocabulário do iniciante:
SMF — System Management Facilities
e
RMF — Resource Measurement Facility.
Simplificando muito:
MAINFRAME
│
┌─────────┴─────────┐
▼ ▼
SMF RMF
│ │
▼ ▼
atividade/ recursos/
registros performanceAlém deles, investigamos informações específicas dos subsistemas:
CICS
Db2
MQ
TCP/IP
WLM
JES
StorageE, em ambientes híbridos:
API Gateway
OpenShift
Kubernetes
Java
cloud
network
serviços externosPorque a transação não respeita o organograma da empresa.
Ela simplesmente percorre o caminho necessário.
🕵️ CAPÍTULO 20 — PASSO A PASSO: COMO INVESTIGAR "O MAINFRAME ESTÁ LENTO"
Winry agora entrega uma prancheta ao jovem programador.
Quando alguém disser:
"Está lento."
não comece alterando código.
Faça perguntas.
1. Identifique o serviço afetado. Descubra qual transação, aplicação, API, job ou fluxo apresenta problema.
2. Determine quando começou. Horário é crucial para correlacionar workload, mudanças e eventos.
3. Meça a latência. Não fique apenas na média. Procure distribuição e percentis relevantes.
4. Observe o throughput. O volume aumentou? Diminuiu? Continua igual?
5. Observe erros e timeouts. Latência pode estar virando falha percebida.
6. Verifique filas e esperas. CICS, Db2, MQ, I/O e dependências podem introduzir queueing.
7. Observe CPU no contexto. CPU é evidência, não veredito.
8. Investigue contenção. Locks, serializações e recursos compartilhados merecem atenção.
9. Compare com o baseline. Saber que p95 está em 400 ms não ajuda tanto quanto saber que normalmente está em 90 ms.
10. Correlacione o caminho completo.
Pense:
Cliente
↓
Rede
↓
API
↓
z/OS Connect
↓
CICS
↓
COBOL
↓
Db2 / MQ
↓
DependênciasNunca pare simplesmente porque encontrou o primeiro gráfico vermelho.
🧰 CAPÍTULO 21 — A CAIXA DE FERRAMENTAS DO PROGRAMADOR COBOL
O iniciante costuma começar preocupado com:
IF
PERFORM
MOVE
EVALUATE
READ
WRITENaturalmente.
Mas seu crescimento profissional começa quando percebe que o programa não vive sozinho.
Ele existe dentro de um ecossistema.
Aprenda gradualmente:
COBOL
↓
JCL
↓
CICS
↓
Db2
↓
VSAM
↓
MQ
↓
z/OS
↓
WLM
↓
SMF/RMFVocê não precisa dominar tudo amanhã.
Mas precisa entender que tudo pode participar da mesma transação.
🤖 CAPÍTULO 22 — RELIABILITY NÃO É AVAILABILITY
Outro conceito merece entrar na oficina.
Availability e Reliability estão relacionados, mas não são sinônimos.
Uma maneira didática de pensar:
Availability: o serviço está acessível quando necessário?
Reliability: ele consegue operar corretamente, de forma consistente, ao longo do período considerado?
Imagine um serviço que cai frequentemente, mas reinicia em segundos.
Sua disponibilidade agregada pode até parecer boa dependendo da medição.
Mesmo assim, sua confiabilidade operacional pode ser péssima.
Winry resumiria:
Não basta o braço mecânico estar preso ao corpo. Ele precisa funcionar corretamente quando Edward precisar dele.
♻️ CAPÍTULO 23 — RECOVERABILITY: E DEPOIS DO ABEND?
Existe ainda outro ponteiro:
Recoverability.
Pergunta:
Depois da falha, conseguimos voltar corretamente?
No mainframe isso nos leva a temas fundamentais:
logging
checkpoint
restart
rollback
backup
recovery
RTO
RPO
disaster recovery
cyber resilienceImagine um batch processando 500 milhões de registros.
Ele sofre ABEND no registro:
487.321.998Se o único plano de recuperação for:
"Roda tudo novamente."
temos espaço para melhorar o projeto.
Checkpoint/restart, quando apropriado, pode mudar completamente a recuperação operacional.
🥚 EASTER EGG — 03:17 E TODOS OS DASHBOARDS ESTAVAM VERDES
Às 03:17, o telefone toca.
Produção.
— O cliente não consegue fazer pagamentos.
O jovem programador abre o dashboard.
Tudo verde.
CPU 🟢
CICS 🟢
Db2 🟢
MQ 🟢
z/OS 🟢Ele sorri.
— Impossível. Está tudo funcionando.
Winry entra na sala.
Olha para os gráficos.
Depois olha para ele.
— O cliente consegue pagar?
— Não.
— Então alguma coisa importante não está funcionando.
Silêncio.
Esse talvez seja o easter egg mais importante deste artigo:
Não confunda ausência de alerta com ausência de problema.
Um dashboard mostra aquilo que você decidiu medir.
O cliente experimenta o serviço inteiro.
🔩 CAPÍTULO 24 — A REGRA DE OURO DE WINRY ROCKBELL
Depois de horas na oficina, Winry coloca quatro mostradores sobre a mesa:
┌──────────────────────┐
│ LATENCY │
│ Quanto demora? │
├──────────────────────┤
│ THROUGHPUT │
│ Quanto processamos? │
├──────────────────────┤
│ AVAILABILITY │
│ Quanto fica no ar? │
├──────────────────────┤
│ CAPACITY │
│ Quanto sustentamos? │
└──────────────────────┘Ao lado, acrescenta mais dois:
RELIABILITY
Funciona corretamente?
RECOVERABILITY
Como voltamos quando falha?Agora temos uma visão muito mais madura.
Nenhum desses indicadores sozinho descreve a saúde do serviço.
Você pode ter:
baixa latency e baixo throughput;
alto throughput e baixa availability;
alta availability com latency tão ruim que o usuário recebe timeout;
capacidade suficiente hoje e nenhuma margem para amanhã;
ótima performance e péssima recuperação após uma falha.
Engenharia acontece justamente nas relações entre essas dimensões.
🎓 EPÍLOGO — O PROGRAMADOR COBOL SAI DA OFICINA DIFERENTE
No começo deste artigo nosso jovem programador olhava para:
IF SALDO >= VALOR
SUBTRACT VALOR FROM SALDO
END-IFe perguntava:
"O programa funciona?"
Essa continua sendo uma pergunta importante.
Mas agora ele possui outras:
Quanto tempo a transação leva?
Qual é seu p95 e p99?
Quanto desse tempo é processamento e quanto é espera?
Quantas transações por segundo conseguimos sustentar?
Onde aparecem filas?
Existe contenção?
Qual é a Unit of Work?
Quanto tempo mantemos locks?
O COMMIT está na fronteira correta do negócio?
O WLM está cumprindo os objetivos definidos?
O serviço continua disponível quando um componente falha?
Existe um SPOF?
O que acontece quando aparecem timeouts?
Os clientes fazem retry?
Quanto workload conseguimos absorver antes da saturação?
Como sabemos que algo está errado?
Como recuperamos depois de um ABEND?
Essas perguntas transformam alguém que simplesmente escreve COBOL em alguém que começa a compreender sistemas.
E essa é uma mudança gigantesca.
O mainframe nunca foi apenas COBOL.
COBOL pode estar no coração da aplicação, mas ao redor dele existe uma verdadeira máquina:
CLIENTE
│
▼
LATENCY
│
▼
THROUGHPUT
│
▼
CAPACITY
│
┌───────────────┼───────────────┐
▼ ▼ ▼
CICS Db2 MQ
│ │ │
└───────────────┼───────────────┘
▼
WLM
│
┌──────┴──────┐
▼ ▼
SMF RMF
│ │
└──────┬──────┘
▼
IBM Z / z/OS
│
▼
AVAILABILITY
│
▼
RECOVERABILITYE talvez essa seja a grande lição que Winry Rockbell deixaria para um padawan do COBOL:
Não saia trocando peças porque alguém disse que a máquina está lenta. Primeiro descubra o caminho do trabalho, meça onde o tempo está sendo gasto, encontre onde a fila nasceu e só então abra a caixa de ferramentas.
Porque Latency conta quanto uma transação esperou.
Throughput conta quantas conseguiram atravessar.
Availability conta durante quanto tempo o serviço permaneceu utilizável.
Capacity revela até onde conseguimos aumentar a carga antes de a oficina começar a ranger.
Reliability pergunta se a máquina continua fazendo corretamente aquilo para que foi construída.
E Recoverability responde à pergunta inevitável em qualquer sistema sério:
Quando alguma coisa finalmente quebrar, como voltaremos?
Às vezes o culpado será CPU.
Às vezes será CICS.
Às vezes será Db2.
Às vezes será MQ.
Às vezes será uma dependência fora do mainframe.
E, de vez em quando, depois de horas investigando SMF, RMF, WLM, traces, logs, locks e filas, você encontrará um COMMIT colocado no lugar errado anos atrás.
Winry provavelmente limparia as mãos sujas de graxa, apontaria para o código e diria:
— Eu avisei. Antes de trocar o motor, descubra qual parafuso está solto.
E o programador COBOL nunca mais olharia para um simples gráfico de Latency × Throughput × Availability da mesma maneira.
Porque agora ele não vê três números.
Ele vê o comportamento de uma máquina inteira. ☕🔧🖥️
Sem comentários:
Enviar um comentário