 |
| Bellacosa Mainframe expande as ideias em IBM Z Resiliency |
☕ Um Café no Bellacosa Mainframe
O Holocron da IBM Z Resiliency
Como um Padawan COBOL Pode Evoluir do "Meu Programa Funciona" para "Meu Sistema Nunca Para"
"O melhor programa COBOL não é apenas aquele que produz o resultado correto. É aquele que continua produzindo o resultado correto mesmo quando discos falham, servidores reiniciam, links caem, operadores cometem erros e o datacenter enfrenta uma crise."
Introdução
Quando um desenvolvedor COBOL começa sua jornada no IBM Z, normalmente sua preocupação é bastante simples:
aprender PROCEDURE DIVISION;
entender WORKING-STORAGE;
fazer READ e WRITE em arquivos VSAM;
acessar Db2;
executar um programa via JCL;
tratar um SQLCODE.
Tudo isso é importante.
Mas existe uma realidade muito maior que normalmente só é descoberta anos depois.
Seu programa não vive sozinho.
Ele faz parte de um enorme ecossistema composto por:
IBM Z Hardware
z/OS
JES2
WLM
CICS
IMS
Db2
MQ
RACF
GDPS
Parallel Sysplex
Storage
Redes
Operação
Monitoramento
Backup
Disaster Recovery
Todo esse conjunto possui um único objetivo:
Nunca deixar o negócio parar.
É justamente isso que a IBM chama de Resiliency.
O maior equívoco do desenvolvedor iniciante
O Padawan COBOL costuma pensar:
"Meu programa compilou."
Depois:
"Funcionou no teste."
Depois:
"Funcionou em produção."
Fim da história.
Na realidade...
A história apenas começou.
Porque a pergunta correta nunca é:
"O programa funciona?"
A pergunta correta é:
"Ele continua funcionando quando alguma coisa dá errado?"
Essa mudança de mentalidade separa um programador júnior de um engenheiro de software para ambientes críticos.
O mundo perfeito não existe
Imagine um banco.
Às 10 horas da manhã.
Existem:
8 milhões de clientes conectados.
milhares de caixas eletrônicos.
PIX.
cartões.
internet banking.
aplicativos móveis.
APIs REST.
Open Finance.
Nesse momento:
uma CPU apresenta defeito.
O que acontece?
Se você respondeu:
"O banco para."
Você ainda está pensando como quem programa um computador doméstico.
No IBM Z, o esperado é que ninguém perceba.
Esse é o verdadeiro significado da palavra Resiliency.
Resiliência não significa nunca falhar
Essa é outra confusão muito comum.
Nenhum computador é perfeito.
Discos quebram.
Memórias apresentam defeitos.
Cabos rompem.
Fontes queimam.
Operadores erram comandos.
Aplicações possuem bugs.
Até meteoros poderiam destruir um datacenter.
Resiliência significa:
Aceitar que falhas acontecerão e projetar o sistema para continuar operando apesar delas.
O conceito mais importante
A IBM define resiliência como:
Capacidade de fornecer os serviços necessários diante da adversidade sem impacto significativo.
Perceba um detalhe.
Ela não fala em hardware.
Ela não fala em COBOL.
Ela fala em:
Serviço.
O cliente quer sacar dinheiro.
Ele não quer saber quantas CPUs existem.
O iceberg invisível
Quando você executa:
EXEC SQL
SELECT SALDO
END-EXEC
Você enxerga apenas uma linha.
Por trás dela existem dezenas de componentes trabalhando juntos.
Seu programa depende de:
compilador COBOL;
runtime;
Db2;
buffer pools;
storage;
cache;
canais FICON;
discos;
processadores;
WLM;
z/OS;
JES;
rede;
segurança RACF.
A resiliência protege toda essa cadeia.
O verdadeiro custo de um downtime
Muitos iniciantes imaginam:
"Se o sistema parar por cinco minutos não faz diferença."
Na prática, cinco minutos podem significar:
milhões de transações não realizadas;
PIX rejeitados;
compras canceladas;
multas;
perda de reputação;
ações caindo na bolsa.
O Redbook mostra que o custo de uma interrupção vai muito além da infraestrutura. Há perdas diretas de receita, custos fixos durante a parada e impactos intangíveis, como perda de confiança dos clientes e danos à marca.
O famoso RAS
Quase todo Sysprog conhece esta sigla.
Reliability
Confiabilidade.
Quanto menor a chance de quebrar.
Availability
Disponibilidade.
Mesmo quebrando,
continua funcionando.
Serviceability
Facilidade para manutenção.
Trocar peças.
Atualizar firmware.
Fazer manutenção.
Sem parar o ambiente.
O COBOL participa da Resiliência?
Sim.
Muito mais do que parece.
Um programa COBOL mal escrito pode derrubar um ambiente inteiro.
Por exemplo:
LOOP infinito.
COMMIT inexistente.
Deadlock.
Consumo exagerado de CPU.
SQL sem índice.
Arquivos bloqueados.
Storage leak.
Falta de tratamento de exceção.
Resiliência também é responsabilidade do desenvolvedor.
O que um Padawan precisa aprender
Primeira fase.
Programar.
Segunda fase.
Programar corretamente.
Terceira fase.
Programar para recuperação.
Quarta fase.
Programar pensando na infraestrutura.
Quinta fase.
Programar pensando no negócio.
Essa evolução leva anos.
A importância do COMMIT
Imagine:
Você atualiza:
100.000 registros.
No registro 99.999 ocorre uma queda elétrica.
Sem COMMIT.
Tudo volta.
Com COMMIT periódico.
A perda é mínima.
O programa consegue reiniciar.
Esse pequeno detalhe pode economizar horas de processamento.
Checkpoints
Batchs gigantes normalmente possuem checkpoints.
Imagine um processamento de:
40 milhões de clientes.
No cliente 39 milhões ocorre uma falha.
Sem checkpoint.
Tudo recomeça.
Com checkpoint.
Continua do ponto salvo.
É resiliência aplicada ao desenvolvimento.
Idempotência
Uma palavra moderna.
Mas extremamente útil.
Se o mesmo programa executar novamente,
ele não deve:
duplicar pagamentos;
duplicar TED;
duplicar PIX;
duplicar lançamentos.
Grandes sistemas financeiros dependem disso.
Tratamento de exceções
Nunca escreva:
IF SQLCODE NOT = 0
DISPLAY 'ERRO'
END-IF
Isso não resolve nada.
Um bom programa:
registra logs;
identifica contexto;
faz rollback quando necessário;
encerra de forma segura;
permite recuperação.
O papel do WLM
O Workload Manager decide quem recebe prioridade.
Imagine:
Folha de pagamento.
PIX.
Batch estatístico.
Quem deve receber CPU primeiro?
O WLM responde.
Seu programa faz parte dessa fila.
Parallel Sysplex
Talvez seja a tecnologia mais famosa do IBM Z.
Vários sistemas trabalham como se fossem um único computador.
Se um deles cair,
os demais continuam.
O usuário nem percebe.
Parece magia.
Na realidade,
é engenharia.
GDPS
Geographically Dispersed Parallel Sysplex.
Imagine:
São Paulo inteiro sem energia.
Outro datacenter assume.
Essa é a ideia.
Algumas empresas conseguem continuar operando mesmo após perder completamente um site.
Zero Data Loss
Um conceito impressionante.
Perder:
zero.
Nem um registro.
Nem um pagamento.
Nem um PIX.
Nem um centavo.
Nem um byte.
É um objetivo que depende de arquiteturas de replicação síncrona e soluções como GDPS e tecnologias de espelhamento de armazenamento.
Curiosidade
Muitos bancos realizam manutenção durante o horário comercial.
Você nem percebe.
Enquanto um sistema recebe manutenção,
outro assume.
Depois ocorre o inverso.
Esse processo chama-se:
Rolling Maintenance.
Easter Egg nº 1
O maior inimigo da disponibilidade nem sempre é o hardware.
É o operador.
Estudos da indústria mostram que erros humanos continuam entre as causas mais frequentes de indisponibilidade.
Por isso existem:
automação;
procedimentos;
scripts;
validações;
System Automation;
Runbooks.
Easter Egg nº 2
Os engenheiros IBM costumam perseguir um objetivo curioso.
Eliminar o que chamam de:
Single Point of Failure
Qualquer componente único que possa derrubar todo o ambiente.
Vale para:
CPU;
disco;
switch;
cabo;
storage;
operador;
documentação.
Até pessoas podem ser um "Single Point of Failure" quando apenas um especialista conhece um procedimento crítico.
Easter Egg nº 3
Um COBOL pode ser resiliente mesmo sendo escrito há 40 anos.
Se:
estiver bem estruturado;
tratar exceções;
possuir restart;
possuir checkpoints;
respeitar transações;
ele continua extremamente moderno.
O que estudar depois deste curso
Depois de entender Resiliency, o caminho natural é aprofundar-se na própria stack IBM Z.
Infraestrutura
IBM Z Hardware
CPC
LPAR
PR/SM
HMC
Sistema Operacional
z/OS
JES2
SDSF
WLM
SMF
RMF
Armazenamento
DFSMS
DFSMShsm
Copy Services
Metro Mirror
Global Mirror
Redes
VTAM
TCP/IP
DVIPA
Sysplex Distributor
Middleware
CICS
IMS
Db2
MQ
Alta Disponibilidade
Parallel Sysplex
Coupling Facility
Data Sharing
GDPS
Operação
IBM System Automation
OMEGAMON
IBM Z Operations Analytics
As habilidades modernas do desenvolvedor COBOL
O mercado mudou.
Hoje um desenvolvedor COBOL pode agregar muito mais valor quando conhece:
APIs REST com z/OS Connect;
JSON e XML;
Git;
GitHub;
DevOps;
CI/CD;
testes automatizados;
observabilidade;
OpenTelemetry;
containers para ferramentas de apoio;
Ansible;
Zowe;
VS Code;
automação operacional;
inteligência artificial aplicada ao desenvolvimento.
Os perigos de ignorar a resiliência
Quem pensa apenas em "fazer funcionar" costuma criar sistemas frágeis.
Os principais riscos são:
perda de dados;
duplicidade de transações;
indisponibilidade prolongada;
degradação de desempenho;
dificuldade de recuperação;
manutenção cara;
dependência de especialistas;
aumento do risco operacional.
Em ambientes financeiros, esses problemas podem gerar prejuízos milionários.
Como evoluir de Padawan para Mestre
Uma evolução sólida pode seguir esta trilha:
Nível 1 — Fundamentos
COBOL
JCL
VSAM
Db2
CICS
Nível 2 — Sistema
z/OS
SDSF
JES2
TSO/ISPF
WLM
Nível 3 — Arquitetura
Parallel Sysplex
Coupling Facility
Data Sharing
ARM
SFM
Nível 4 — Continuidade de Negócios
RAS
HA
DR
RTO
RPO
GDPS
Nível 5 — Modernização
APIs
z/OS Connect
DevOps
Observabilidade
IA
Automação
A maior lição do IBM Z Resiliency
Depois de estudar esse tema, muitos desenvolvedores descobrem que escrever código representa apenas uma pequena parte do trabalho. Um programa COBOL faz sentido somente quando está inserido em uma arquitetura capaz de sobreviver a falhas, manter dados íntegros e continuar entregando serviços ao negócio.
É por isso que os profissionais mais valorizados no ecossistema IBM Z não são apenas excelentes programadores. Eles entendem infraestrutura, operação, banco de dados, middleware, redes, automação e continuidade de negócios. Eles sabem que um COMMIT bem posicionado, um tratamento adequado de exceções ou um checkpoint inteligente podem ter tanto impacto quanto uma nova funcionalidade.
No fim da jornada, o verdadeiro Mestre do IBM Z não é aquele que escreve o código mais sofisticado. É aquele que projeta soluções que continuam funcionando quando o inesperado acontece. Essa é a essência da IBM Z Resiliency: construir sistemas preparados para enfrentar falhas sem interromper aquilo que realmente importa — o negócio de milhões de pessoas.
Sem comentários:
Enviar um comentário