 |
| Bellacosa Mainframe e o cics capacity planning |
☕ Um Café no Bellacosa Mainframe
CICS Capacity Planning — A Sociedade da Capacidade e a Jornada para o Crescimento Futuro
Quando um Programador COBOL Padawan Descobre que o Verdadeiro Perigo Não é o Volume de Hoje, mas a Carga que Marcha no Horizonte
Em uma região distante do Reino do Mainframe, cercada por salas refrigeradas, consoles luminosos e arquivos SMF que registravam silenciosamente cada movimento do sistema, existia um ambiente CICS responsável por milhões de transações.
Durante o dia, clientes consultavam saldos, faziam pagamentos, transferiam dinheiro, atualizavam cadastros, contratavam produtos e utilizavam serviços que pareciam simples na tela de um aplicativo.
Por trás daquela aparente simplicidade, entretanto, havia uma fortaleza tecnológica.
Regiões CICS trabalhavam em conjunto. Programas COBOL executavam regras de negócio. O Db2 armazenava os dados. O VSAM mantinha arquivos essenciais. O MQ transportava mensagens. O WLM distribuía prioridades. O z/OS coordenava todos os recursos como um sábio administrador do reino.
Tudo funcionava tão bem que um jovem programador COBOL começou a acreditar que sempre seria assim.
Ele olhou para os monitores e perguntou ao velho sysprog:
— Mestre, o ambiente está estável. Os tempos de resposta estão bons. A CPU não está saturada. Por que continuamos analisando crescimento, produzindo relatórios e estudando dados antigos?
O sysprog tomou um gole de café e respondeu:
— Porque os sistemas raramente são derrotados pela carga que já conhecem. Eles são derrotados pela carga para a qual ninguém se preparou.
Essa é a essência do Capacity Planning, ou planejamento de capacidade.
Não se trata apenas de observar quanto CPU o CICS utiliza hoje.
Trata-se de compreender quanto trabalho poderá chegar amanhã, quais recursos serão necessários e como preparar a infraestrutura antes que o crescimento se transforme em crise.
Bem-vindo à jornada do CICS Capacity Planning.
1. A sombra que cresce além das montanhas
Em um ambiente de produção, tudo pode parecer tranquilo até que alguma mudança de negócio altere completamente o comportamento do sistema.
Uma campanha de marketing pode atrair milhões de novos acessos.
Um novo aplicativo móvel pode aumentar o número de consultas.
Uma promoção pode gerar picos inesperados.
Uma fusão entre empresas pode adicionar milhares de usuários.
Uma nova regulamentação pode obrigar todos os clientes a atualizar cadastros.
A chegada de pagamentos, benefícios, impostos, Black Friday, Natal, 13º salário ou vencimentos bancários pode concentrar enormes volumes em poucas horas.
O crescimento do negócio quase sempre chega primeiro como uma boa notícia.
— Teremos mais clientes!
— Lançaremos um novo produto!
— Nossa plataforma estará disponível em todo o país!
— A previsão é aumentar as vendas em 40%!
Para a diretoria, isso representa receita.
Para o CICS, isso representa transações.
E transações consomem recursos.
Mais transações podem significar:
mais CPU;
mais acessos ao Db2;
mais I/O;
mais mensagens MQ;
mais arquivos VSAM acessados;
mais tarefas simultâneas;
mais uso de memória;
mais conexões;
mais locks;
mais logs;
mais tráfego de rede;
mais pressão sobre regiões CICS.
O Capacity Planning transforma o crescimento comercial em necessidades técnicas mensuráveis.
Em linguagem simples:
A empresa diz quanto pretende crescer. A equipe técnica calcula se o ambiente sobreviverá ao crescimento.
2. O que é Capacity Planning?
Capacity Planning é o processo de analisar o comportamento atual e histórico de um ambiente, estimar seu crescimento futuro e determinar quais recursos serão necessários para manter desempenho, disponibilidade e estabilidade.
No caso do CICS, o planejamento procura responder perguntas como:
O número atual de regiões suportará o volume futuro?
A CPU disponível será suficiente?
O tempo de resposta permanecerá dentro do SLA?
O Db2 suportará o aumento de chamadas SQL?
Os arquivos VSAM continuarão atendendo o volume?
O WLM distribuirá corretamente as prioridades?
A rede suportará mais requisições?
O sistema continuará disponível durante os horários de pico?
Será necessário criar novas AORs?
Existe risco de atingir o MXT?
Alguma região poderá entrar em Short on Storage?
O throughput aumentará sem degradar a experiência do usuário?
Observe que Capacity Planning não é apenas prever consumo.
É prever consumo mantendo os objetivos de serviço.
Um sistema pode continuar funcionando e, ainda assim, estar tecnicamente fracassando.
Imagine que uma transação levava 300 milissegundos e, após o crescimento, passa a levar 8 segundos.
Ela ainda funciona.
Mas o cliente percebe lentidão.
O aplicativo parece travado.
O operador tenta novamente.
As requisições se acumulam.
O sistema passa a receber transações duplicadas.
O suporte começa a receber reclamações.
O problema deixa de ser apenas técnico e passa a afetar o negócio.
Por isso, capacidade não significa somente “aguentar o volume”.
Significa:
Agir dentro do tempo esperado, com estabilidade, eficiência e margem de segurança.
3. Reagir ou se preparar: duas formas de administrar o reino
Existem dois estilos básicos de gestão de capacidade.
O modelo reativo
No modelo reativo, a empresa espera o problema aparecer.
O sistema começa a ficar lento.
A CPU sobe.
O número de tarefas aumenta.
As filas crescem.
O Db2 registra contenções.
As transações começam a exceder o tempo esperado.
Então todos correm.
A equipe de aplicação culpa o banco de dados.
O Db2 culpa o CICS.
O CICS culpa a rede.
A rede culpa o fornecedor.
A infraestrutura pede mais CPU.
A gestão pergunta por que ninguém previu o problema.
Esse cenário é parecido com uma cidade que só começa a construir muralhas depois que o exército inimigo já apareceu no horizonte.
O modelo proativo
No modelo proativo, a organização acompanha tendências.
Ela conhece os picos sazonais.
Mantém histórico de consumo.
Conversa com as áreas de negócio.
Estima novos volumes.
Realiza testes de carga.
Identifica gargalos.
Ajusta aplicações.
Revisa o WLM.
Planeja novas regiões.
Reserva capacidade adicional.
Quando o crescimento chega, o sistema está preparado.
Para o cliente, nada de extraordinário aconteceu.
Ele simplesmente continuou usando o serviço.
Esse é um dos paradoxos da infraestrutura:
Quando o Capacity Planning funciona perfeitamente, ninguém percebe.
O sucesso é invisível.
4. A Sociedade da Capacidade
Nenhum profissional realiza Capacity Planning sozinho.
É necessário reunir uma verdadeira sociedade, formada por diferentes especialidades.
Podemos imaginar os participantes desta jornada como membros de uma grande expedição.
A área de negócios
Representa o futuro esperado.
Ela informa:
novos produtos;
campanhas;
expansão;
previsão de clientes;
aquisições;
mudanças regulatórias;
datas críticas.
Sem essas informações, a infraestrutura só consegue analisar o passado.
A equipe CICS
Conhece:
A equipe COBOL
Conhece a lógica da aplicação.
Ela pode identificar:
A equipe Db2
Analisa:
instruções SQL;
planos de acesso;
índices;
locks;
buffer pools;
quantidade de getpages;
tabelas;
estatísticas;
concorrência.
A equipe de performance
Correlaciona:
A equipe de infraestrutura
Planeja:
processadores;
memória;
discos;
rede;
licenciamento;
capacidade adicional;
contratos;
upgrades.
Capacity Planning é, portanto, uma disciplina técnica e organizacional.
O trabalho começa em reuniões de negócio e termina em decisões de arquitetura.
5. O mapa da jornada: o fluxo do Capacity Planning
O processo pode ser representado assim:
Crescimento do negócio
↓
Análise do volume de transações
↓
Coleta de dados SMF e performance
↓
Identificação de tendências
↓
Previsão de capacidade
↓
Planejamento de recursos
↓
Testes e validação
↓
Ajustes e implementação
↓
Monitoramento contínuo
Cada etapa é importante.
Pular uma delas pode produzir conclusões erradas.
6. Passo 1 — Conheça o negócio antes de olhar a CPU
O primeiro passo não é abrir o SDSF.
Também não é consultar um gráfico.
O primeiro passo é descobrir o que mudará no negócio.
Perguntas úteis:
Haverá lançamento de um novo produto?
Existe previsão de aumento de clientes?
Alguma campanha será realizada?
O serviço ganhará um novo canal?
Uma API será disponibilizada para parceiros?
Haverá migração de sistemas?
Alguma aplicação distribuída passará a utilizar o CICS?
O volume batch também aumentará?
Existem períodos sazonais conhecidos?
Imagine um banco que lança uma funcionalidade de pagamento instantâneo integrada a centenas de lojas.
Antes, cada cliente realizava duas ou três operações por dia.
Depois da integração, cada compra pode gerar várias chamadas:
validação do cliente;
consulta de saldo;
autorização;
gravação da transação;
atualização de limite;
geração de evento;
envio de mensagem;
auditoria.
Uma única ação visível ao usuário pode gerar diversas transações internas.
Por isso, crescimento de usuários e crescimento de transações não são necessariamente iguais.
Um aumento de 20% nos clientes pode provocar 60% a mais de trabalho.
7. Passo 2 — Analise o volume de transações
Depois de compreender a previsão de negócio, é necessário estudar o volume atual.
Os principais indicadores incluem:
Um erro comum é utilizar apenas médias.
Suponha que um ambiente processe 86 milhões de transações por dia.
Dividindo esse valor por 86.400 segundos, teríamos aproximadamente mil transações por segundo.
Parece simples.
Mas o sistema não recebe carga uniforme.
Durante a madrugada, pode processar 100 transações por segundo.
Às 11h30, pode atingir 8 mil.
No horário de pagamento, pode chegar a 15 mil.
A média esconde o pico.
E sistemas normalmente quebram durante o pico, não durante a média.
Dica Bellacosa
Nunca pergunte apenas:
Qual é o volume diário?
Pergunte também:
Qual foi o maior volume em um intervalo de 1, 5, 15 e 60 minutos?
Isso revela a verdadeira pressão sobre o ambiente.
8. Passo 3 — Consulte os pergaminhos do SMF
O SMF, System Management Facility, é um dos grandes cronistas do z/OS.
Ele registra eventos e métricas produzidos por vários componentes.
Pode ser comparado a uma enorme biblioteca que documenta a história operacional do sistema.
Entre os registros mais conhecidos estão:
SMF 30, relacionado a jobs e address spaces;
SMF 70, relacionado ao uso de processadores;
SMF 72, relacionado ao WLM;
SMF 74, relacionado a dispositivos e armazenamento;
SMF 101, relacionado ao Db2;
SMF 110, relacionado ao CICS;
SMF 119, relacionado ao TCP/IP.
Para um iniciante, a quantidade de dados pode parecer assustadora.
Mas não é necessário começar entendendo todos os campos.
O importante é compreender o princípio:
O SMF permite transformar percepções em evidências.
Em vez de afirmar:
— Acho que a região está sobrecarregada.
É possível demonstrar:
aumento de transações;
maior CPU por transação;
aumento de espera;
crescimento do response time;
saturação de tarefas;
elevação de I/O;
concentração de workload;
degradação em horários específicos.
Essa diferença é fundamental.
Capacity Planning não pode ser baseado em “achismos”.
9. Passo 4 — Observe os recursos certos
O infográfico destaca CPU, memória, armazenamento e regiões CICS.
Esses são pilares importantes, mas o ambiente deve ser observado como um conjunto.
CPU
Devemos analisar:
Uma transação pode continuar rápida e, mesmo assim, passar a utilizar mais CPU.
Esse aumento talvez ainda não afete o usuário, mas reduz a margem disponível para o futuro.
Memória e storage do CICS
No CICS, memória não significa apenas RAM física.
Também precisamos considerar as áreas de storage da região, alocações dinâmicas e limites internos.
Indicadores e conceitos importantes incluem:
EDSA;
GCDSA;
GUDSA;
storage below the line;
storage above the line;
GETMAIN;
FREEMAIN;
storage violations;
fragmentation;
Short on Storage.
Uma região pode ter CPU disponível e, ainda assim, sofrer por falta de storage interno.
I/O e armazenamento
Devemos observar:
Rede
Aplicações modernas podem acessar o CICS por:
TCP/IP;
HTTP;
HTTPS;
MQ;
APIs;
z/OS Connect;
CICS web services;
sockets;
gateways.
Se a rede estiver saturada, adicionar CPU ao CICS não resolverá o problema.
Regiões CICS
É necessário estudar:
Uma única região enorme pode tornar-se um ponto de concentração e risco.
Em muitos ambientes, o crescimento exige distribuição horizontal por várias regiões.
10. O papel das AORs na expansão
Uma Application-Owning Region, ou AOR, é a região em que os programas aplicativos normalmente executam.
Quando o volume cresce, uma estratégia possível é adicionar novas AORs.
Imagine inicialmente:
TOR
|
+-- AOR1
+-- AOR2
Com o aumento da demanda:
TOR
|
+-- AOR1
+-- AOR2
+-- AOR3
+-- AOR4
Isso pode aumentar a capacidade e melhorar a disponibilidade.
Entretanto, adicionar regiões não resolve tudo automaticamente.
É preciso verificar:
se as transações podem ser roteadas;
se existem affinities;
se o programa depende de storage local;
se utiliza TSQ local;
se há recursos compartilhados;
se as conexões Db2 suportam o aumento;
se o WLM está configurado corretamente;
se o CPSM realiza o roteamento adequado.
Criar uma nova região sem revisar dependências pode apenas mover o problema.
11. O WLM como o regente dos exércitos
O Workload Manager, WLM, ajuda o z/OS a distribuir recursos conforme objetivos de serviço.
Em vez de tratar todos os trabalhos da mesma forma, o WLM reconhece que alguns workloads são mais importantes.
Uma transação de autorização de cartão pode ter prioridade diferente de um relatório interno.
Um serviço online pode exigir resposta em menos de um segundo.
Um processamento batch talvez possa esperar.
O WLM trabalha com conceitos como:
service classes;
importance;
goals;
response time;
velocity;
periods;
classification rules.
Em uma situação de contenção, ele ajuda o sistema a tomar decisões.
Mas o WLM não cria capacidade do nada.
Esse é um ponto importante.
Ele distribui melhor os recursos existentes.
Se não houver CPU suficiente, todos ainda poderão sofrer.
Podemos comparar o WLM a um comandante que organiza seus soldados.
Um bom comandante melhora a defesa.
Mas, se o exército for pequeno demais para enfrentar a batalha, organização sozinha não será suficiente.
12. Db2: o dragão escondido na montanha
Muitos problemas atribuídos ao CICS estão, na verdade, relacionados ao acesso a dados.
Uma transação CICS pode executar rapidamente até chegar a uma instrução SQL.
Se o plano de acesso estiver ruim, ela pode:
Às vezes, uma simples revisão de índice ou atualização de estatísticas reduz drasticamente o consumo.
Por isso, antes de comprar capacidade, convém investigar:
RUNSTATS atualizados;
access paths;
EXPLAIN;
índices;
getpages;
lock waits;
deadlocks;
buffer pools;
packages;
binds;
cardinalidade;
seletividade.
Curiosidade
Uma instrução SQL aparentemente pequena pode consumir mais recursos do que milhares de linhas COBOL.
O tamanho visual do comando não representa seu custo.
SELECT *
FROM MOVIMENTO
WHERE CODIGO_CLIENTE = :WS-CLIENTE
Sem índice adequado, essa consulta pode atravessar uma enorme quantidade de dados.
Em Capacity Planning, o código também faz parte da infraestrutura.
13. Response time, throughput e wait time
Três conceitos precisam ser diferenciados.
Response time
É o tempo total percebido para concluir a transação.
Pode incluir:
Throughput
É a quantidade de trabalho concluído em determinado período.
Exemplo:
5.000 transações por segundo
Um sistema pode ter bom response time com baixo throughput ou alto throughput com resposta ruim.
Os dois indicadores precisam ser analisados juntos.
Wait time
É o tempo em que a tarefa não está executando porque aguarda algum recurso.
Ela pode esperar por:
CPU;
I/O;
lock;
Db2;
MQ;
arquivo;
socket;
terminal;
storage;
enqueue;
serviço externo.
Um ambiente com CPU em 40% pode estar extremamente lento se as tarefas passarem grande parte do tempo esperando por outros recursos.
Por isso:
CPU baixa não significa necessariamente sistema saudável.
14. O exemplo do banco e a temporada festiva
Vamos aprofundar o exemplo.
Um banco prevê aumento de 40% nas transações durante o fim do ano.
Atualmente, o pico é de 10 mil transações por segundo.
A previsão simples seria:
10.000 × 1,40 = 14.000 TPS
Porém, a equipe decide adicionar margem de segurança.
Ela considera:
crescimento acima da previsão;
repetição de transações por usuários;
falhas em canais externos;
degradação em parceiros;
carga batch simultânea;
campanhas adicionais;
comportamento imprevisível.
A meta passa a ser suportar 17 mil TPS.
A equipe então realiza os seguintes passos.
1. Analisa o histórico
São consultados dados dos últimos anos.
Identificam-se:
dias críticos;
horários;
transações mais usadas;
consumo de CPU;
resposta;
filas;
falhas;
limites atingidos.
2. Localiza os maiores consumidores
Algumas transações podem representar grande parte da CPU.
A regra 80/20 aparece com frequência:
Otimizar essas transações pode produzir enorme ganho.
3. Revisa o Db2
A equipe encontra acessos com muitas getpages.
Atualiza estatísticas.
Cria índices.
Executa REBIND onde necessário.
Revê buffer pools.
4. Adiciona AOR
Uma nova AOR é configurada.
Programas, definições e conexões são validados.
O roteamento é testado.
5. Ajusta o WLM
As service classes são revisadas.
Workloads críticos recebem objetivos compatíveis com a prioridade do negócio.
6. Realiza teste de carga
O ambiente é submetido a volumes crescentes.
10.000 TPS
12.000 TPS
14.000 TPS
16.000 TPS
17.000 TPS
A equipe observa o ponto em que os tempos começam a degradar.
Esse ponto é conhecido como joelho da curva.
Antes dele, o sistema cresce de forma controlada.
Depois dele, pequenas elevações de carga podem provocar grande degradação.
7. Cria plano de contingência
Mesmo com planejamento, a equipe define ações emergenciais:
ativação de capacidade adicional;
criação de região;
bloqueio de funções não críticas;
priorização de serviços;
redução de batch;
acionamento de fornecedores;
rollback de mudanças.
Quando a temporada chega, o sistema suporta o crescimento.
O cliente apenas percebe que o serviço funciona.
15. O perigo da extrapolação simples
Suponha o seguinte histórico:
2023 — 100 milhões de transações
2024 — 110 milhões
2025 — 121 milhões
2026 — 133 milhões
Alguém poderia concluir que o crescimento é de aproximadamente 10% ao ano.
Mas e se, em 2027, a empresa lançar um aplicativo obrigatório para todos os clientes?
O crescimento histórico deixará de ser suficiente para prever o futuro.
Modelos estatísticos são úteis, mas precisam ser combinados com informações do negócio.
O futuro não é apenas uma continuação matemática do passado.
Ele também inclui eventos.
Por isso, um bom forecast mistura:
16. Técnicas de previsão
Em ambientes mais maduros, podem ser utilizadas técnicas como:
Para um iniciante, entretanto, o melhor ponto de partida é simples:
obtenha o histórico;
encontre os picos;
calcule a tendência;
identifique eventos futuros;
crie cenários;
adicione margem;
teste.
Três cenários são bastante úteis:
Cenário conservador
Crescimento menor que o esperado.
Cenário provável
Crescimento alinhado à previsão oficial.
Cenário agressivo
Crescimento acima do esperado.
Por exemplo:
Conservador: +20%
Provável: +40%
Agressivo: +70%
O objetivo não é adivinhar o futuro com perfeição.
É evitar ser surpreendido.
17. Capacity Planning não significa comprar mais hardware
Esse é um dos maiores mitos.
Antes de aumentar capacidade física, várias ações podem melhorar o ambiente:
otimizar programas COBOL;
eliminar chamadas redundantes;
melhorar SQL;
atualizar índices;
tornar programas threadsafe;
reduzir switch para QR TCB;
ajustar buffers;
melhorar LSR pools;
rever logging;
corrigir affinities;
distribuir workload;
ajustar WLM;
reorganizar datasets;
reduzir I/O;
usar zIIP quando aplicável;
ajustar parâmetros CICS.
Comprar hardware sem corrigir ineficiências pode apenas tornar um sistema ruim mais caro.
Regra do Café
Primeiro descubra onde o recurso está sendo desperdiçado. Depois decida se realmente falta capacidade.
18. Margem de segurança: a reserva de Gondor
Nenhum ambiente crítico deve operar permanentemente no limite.
Se a CPU atinge 100% no pico normal, não existe espaço para:
A capacidade de reserva é chamada frequentemente de headroom.
O percentual ideal depende do ambiente, dos SLAs, da arquitetura e das políticas da empresa.
Não existe um número universal.
O importante é compreender que trabalhar sempre próximo da saturação reduz a resiliência.
É como defender uma fortaleza utilizando todos os soldados em uma única muralha.
Quando surge um segundo ataque, não há reserva.
19. Teste de carga: o ensaio antes da batalha
Forecast sem teste é apenas hipótese.
Um teste de carga procura reproduzir o comportamento esperado.
Ele deve considerar:
Não basta executar uma transação simples milhares de vezes.
O ambiente real possui uma combinação de operações.
Exemplo:
40% consultas
25% pagamentos
15% transferências
10% atualizações
5% inclusão de dados
5% outras operações
A distribuição do teste precisa aproximar-se da realidade.
Também é importante testar durante tempo suficiente.
Um teste de cinco minutos pode não revelar:
vazamentos;
crescimento de filas;
esgotamento gradual;
acúmulo de logs;
contenções;
fragmentação;
problemas de storage.
20. Sinais de que a capacidade está chegando ao limite
Alguns sintomas merecem atenção:
crescimento contínuo do response time;
CPU por transação aumentando;
CPU total próxima do limite;
aumento de dispatch delay;
mais tarefas aguardando;
MXT frequentemente atingido;
maior número de queued tasks;
aumento de lock waits;
aumento de I/O;
degradação em horários de pico;
desequilíbrio entre regiões;
ocorrências de SOS;
erros de falta de recurso;
aumento de timeouts;
necessidade frequente de intervenção manual.
Um único indicador não conta toda a história.
É necessário correlacionar dados.
Por exemplo:
Mais transações
+ mesma CPU por transação
+ maior CPU total
= crescimento normal
Mas:
Mesmo volume
+ mais CPU
+ pior resposta
= provável ineficiência ou mudança
21. Como um programador COBOL iniciante pode ajudar
Capacity Planning não é responsabilidade exclusiva do sysprog.
O programador COBOL pode contribuir muito.
Conheça o custo do seu programa
Pergunte:
Quantas vezes ele é executado?
Quanto CPU utiliza?
Quantos acessos ao Db2 realiza?
Quantos arquivos lê?
Existem loops desnecessários?
Existem chamadas repetidas?
Há processamento que poderia ser evitado?
Evite SELECT desnecessário
Não consulte o banco várias vezes para obter a mesma informação.
Considere armazenar temporariamente valores já obtidos, quando isso for seguro e coerente com a aplicação.
Leia apenas o necessário
Evite SELECT * quando somente algumas colunas são usadas.
Cuidado com loops
Um comando dentro de um loop pode ser multiplicado milhares de vezes.
PERFORM VARYING WS-I FROM 1 BY 1
UNTIL WS-I > 10000
EXEC SQL
SELECT ...
END-EXEC
END-PERFORM
Esse padrão pode gerar dez mil chamadas SQL.
Talvez seja possível resolver a necessidade com uma única consulta melhor estruturada.
Entenda o contexto CICS
Evite programas que:
seguram recursos por muito tempo;
realizam waits desnecessários;
mantêm locks;
executam processamento pesado online;
fazem loops extensos;
dependem de afinidade sem necessidade;
usam recursos locais que dificultam o roteamento.
Registre e meça
Uma alteração considerada “pequena” pode aumentar o consumo de todas as transações.
Se a transação roda dez milhões de vezes por dia, alguns microssegundos adicionais tornam-se relevantes.
22. Perguntas úteis para entrevistas
Por que Capacity Planning é importante no CICS?
Porque permite prever o crescimento do workload e garantir que CPU, memória, armazenamento, regiões e componentes associados estejam preparados antes que ocorram problemas de desempenho ou disponibilidade.
Quais dados podem ser usados?
Qual a diferença entre monitoring e Capacity Planning?
Monitoring observa o estado atual ou recente.
Capacity Planning utiliza dados históricos e previsões para tomar decisões futuras.
Mais CPU sempre resolve?
Não. O gargalo pode estar no Db2, I/O, rede, locks, storage, arquitetura, código COBOL ou configuração CICS.
Por que analisar picos?
Porque a média pode esconder os momentos de maior pressão, que são justamente aqueles em que o sistema corre maior risco de degradação.
23. Curiosidades da Terra-Média do Mainframe
Curiosidade 1 — O CICS pode estar saudável enquanto uma transação está doente
A região inteira pode apresentar bons indicadores, mas uma transação específica pode estar consumindo recursos demais.
Por isso, análises globais e individuais são necessárias.
Curiosidade 2 — Crescimento de volume não precisa gerar crescimento proporcional de CPU
O ambiente pode ganhar eficiência com:
cache;
melhor SQL;
código otimizado;
melhor distribuição;
uso de zIIP;
redução de I/O.
Curiosidade 3 — Uma mudança pequena pode criar um grande impacto
Adicionar uma chamada a banco em uma transação executada milhões de vezes pode alterar significativamente a capacidade.
Curiosidade 4 — O sistema pode degradar antes de chegar a 100%
Filas, contenções e esperas podem crescer muito antes da CPU atingir o máximo.
Curiosidade 5 — O melhor Capacity Planning começa com boas perguntas
Ferramentas produzem gráficos.
Mas somente uma boa pergunta transforma o gráfico em decisão.
24. Easter egg — O Um Anel da performance
Em antigas lendas do Reino do Mainframe, dizia-se que existia um parâmetro secreto capaz de resolver qualquer problema de desempenho.
Um parâmetro para acelerar todas as transações.
Um parâmetro para reduzir todos os tempos.
Um parâmetro para eliminar todos os gargalos.
Muitos jovens aventureiros procuraram por ele em manuais, reuniões, fóruns e consoles.
Alguns acreditaram que era o MXT.
Outros disseram que era o número de AORs.
Alguns juraram que bastava adicionar CPU.
Outros culparam o Db2.
Depois de muitos anos, os sábios descobriram a verdade:
O Um Anel da performance não existe.
Não há um único parâmetro capaz de resolver todos os problemas.
Performance é o resultado do equilíbrio entre:
aplicação;
CICS;
Db2;
WLM;
CPU;
memória;
I/O;
rede;
arquitetura;
volume;
prioridade;
operação.
Aquele que procura uma solução mágica acaba sendo dominado por ela.
Aquele que mede, compreende e planeja governa seus recursos com sabedoria.
25. Passo a passo resumido para começar
Para o programador COBOL iniciante, esta é uma boa trilha prática.
Passo 1
Entenda o fluxo da transação.
Descubra quais programas, arquivos, tabelas e serviços são utilizados.
Passo 2
Identifique o volume.
Saiba quantas vezes a transação executa e quais são seus horários de pico.
Passo 3
Aprenda métricas básicas.
Comece por:
transaction count;
response time;
CPU time;
wait time;
abends;
throughput.
Passo 4
Conheça os principais registros SMF.
Não tente dominar todos imediatamente.
Comece entendendo o papel dos registros 70, 72, 101 e 110.
Passo 5
Compare períodos.
Analise hoje contra ontem, este mês contra o anterior e o pico atual contra o pico histórico.
Passo 6
Investigue mudanças.
Quando o consumo subir, verifique:
houve mais volume?
mudou o programa?
mudou o SQL?
mudou a infraestrutura?
surgiu novo canal?
houve redistribuição?
Passo 7
Crie cenários futuros.
Projete crescimento conservador, provável e agressivo.
Passo 8
Teste.
Simule a carga e observe quando os indicadores começam a degradar.
Passo 9
Prepare ações.
Defina antecipadamente o que fazer caso o cenário ultrapasse a previsão.
Passo 10
Continue monitorando.
Capacity Planning não é um relatório anual esquecido em uma pasta.
É um ciclo contínuo.
26. A conclusão da jornada
Ao final da conversa, o jovem programador COBOL olhou novamente para o console.
As mesmas regiões CICS estavam ativas.
As mesmas transações continuavam sendo executadas.
O ambiente parecia idêntico ao de algumas horas antes.
Mas ele já não o enxergava da mesma forma.
Agora compreendia que cada linha de consumo contava uma história.
Cada pico podia ser um aviso.
Cada relatório SMF era uma página do passado.
Cada previsão de negócio era uma mensagem vinda do futuro.
O sysprog terminou o café e disse:
— Administrar capacidade não é tentar impedir que o negócio cresça. É garantir que a tecnologia cresça junto.
O programador perguntou:
— Então Capacity Planning é preparar o sistema para uma batalha?
O velho profissional sorriu.
— Não exatamente. A batalha acontece quando o planejamento falha. Quando fazemos nosso trabalho corretamente, o crescimento chega e encontra os portões abertos, as regiões disponíveis, o WLM preparado, o Db2 ajustado e a CPU com espaço suficiente.
Essa é a grande lição.
Capacity Planning não é comprar hardware por medo.
Não é aumentar parâmetros aleatoriamente.
Não é observar somente CPU.
Não é esperar o usuário reclamar.
É transformar dados históricos em decisões futuras.
É ligar o planejamento do negócio à engenharia do IBM Z.
É estudar o passado, compreender o presente e preparar o ambiente para aquilo que ainda não aconteceu.
No universo CICS, a verdadeira alta performance não consiste apenas em executar rapidamente hoje.
Consiste em continuar executando rapidamente quando o volume dobrar.
A verdadeira disponibilidade não significa apenas permanecer ativo durante uma tarde tranquila.
Significa suportar campanhas, pagamentos, picos, falhas, crescimento e mudanças sem abandonar o usuário.
E o verdadeiro profissional de mainframe não é aquele que corre mais depressa quando o sistema entra em crise.
É aquele que percebe a marcha distante, interpreta os sinais do SMF e prepara a fortaleza antes que a tempestade chegue.
Porque, na Terra-Média do IBM Z, nem todo exército aparece como uma sombra no horizonte.
Às vezes ele chega silenciosamente, disfarçado de milhões de novas transações.
E quando isso acontecer, que suas AORs estejam prontas, que seus planos de acesso estejam ajustados, que o WLM conheça suas prioridades e que ainda exista café suficiente para acompanhar os gráficos.
Um sistema confiável não é aquele que nunca enfrenta crescimento.
É aquele que foi preparado para sobreviver a ele.
