 |
| Bellacosa Mainframe e a ibm z resiliencia |
☕ Um Café no Bellacosa Mainframe
IBM Z Resiliência: A Engenharia Invisível que Mantém o Mundo Funcionando (E Quase Ninguém Percebe)
"Quando tudo funciona, ninguém lembra do Sysprog. Quando tudo para... todo mundo lembra."
Introdução – O paradoxo da excelência
Existe uma curiosidade muito interessante sobre a profissão de System Programmer (Sysprog) e System Administrator (Sysadmin) no universo IBM Z.
Se você fizer um trabalho perfeito durante dez anos, provavelmente ninguém vai notar.
Mas basta cinco minutos de indisponibilidade para que diretores, gestores, usuários, imprensa e até clientes passem a perguntar:
"O que aconteceu com o sistema?"
Esse é o maior paradoxo da infraestrutura crítica.
Quanto melhor você trabalha...
menos visível você fica.
E justamente por isso existe um tema que deveria ser obrigatório para qualquer profissional que trabalha com IBM Z:
Resiliência.
Não Backup.
Não Disaster Recovery.
Não Alta Disponibilidade isoladamente.
Mas sim Resiliência.
São conceitos diferentes.
E entender essa diferença muda completamente a forma como um Sysprog enxerga um ambiente de missão crítica.
O que realmente significa Resiliência?
A maioria das pessoas responde rapidamente:
"É conseguir recuperar o sistema."
Na verdade...
Essa resposta está incompleta.
Resiliência significa:
continuar entregando o serviço mesmo quando alguma coisa está dando errado.
Perceba a diferença.
Recuperação acontece depois.
Resiliência começa antes.
Essa filosofia está presente na arquitetura IBM Z desde seus primeiros projetos.
O Mainframe nasceu paranoico
Essa talvez seja a primeira curiosidade da apresentação.
Os computadores distribuídos normalmente são construídos pensando em desempenho.
O IBM Z foi construído pensando em falhas.
Pode parecer estranho.
Mas faz todo sentido.
Durante décadas, bancos, governos, bolsas de valores e empresas de telecomunicações não podiam simplesmente dizer:
"Desculpe, voltamos amanhã."
Logo, toda a engenharia foi criada assumindo uma premissa:
Alguma coisa vai falhar.
A pergunta nunca foi:
"Será que vai falhar?"
A pergunta correta sempre foi:
"Quando falhar... como vamos impedir que alguém perceba?"
Essa pequena mudança de mentalidade explica praticamente toda a arquitetura IBM Z.
A grande diferença entre Cloud e Mainframe
Existe uma frase que gosto muito.
"Na Cloud você escala."
No IBM Z...
Você continua funcionando.
São objetivos diferentes.
Cloud normalmente resolve aumento de carga.
Mainframe resolve continuidade operacional.
Não significa que um substitui o outro.
Eles resolvem problemas diferentes.
RAS: o DNA invisível do IBM Z
Todo Sysprog deveria decorar três letras.
RAS.
Reliability.
Availability.
Serviceability.
Essas três palavras são provavelmente as mais importantes de toda a arquitetura IBM Z.
Reliability
Confiabilidade.
O hardware foi projetado para falhar menos.
Mas mais importante...
Foi projetado para detectar quando está começando a falhar.
Memórias ECC.
Processadores redundantes.
Correção automática de erros.
Diagnóstico permanente.
Enquanto outros equipamentos apenas quebram...
O IBM Z normalmente avisa antes.
Curiosidade
Você provavelmente já trabalhou em um ambiente onde uma memória apresentou erro.
A diferença é que no Mainframe isso muitas vezes acontece...
...sem ninguém perceber.
O hardware corrigiu sozinho.
Esse é um daqueles "superpoderes" invisíveis.
Availability
Disponibilidade.
Talvez o conceito mais famoso.
Mas muita gente interpreta errado.
Disponibilidade não significa:
"O servidor está ligado."
Significa:
O negócio continua funcionando.
Um servidor ligado sem processar transações...
continua indisponível.
Serviceability
Essa é a parte mais fascinante.
Capacidade de manutenção.
Imagine trocar um componente crítico...
sem desligar o equipamento.
Isso parece impossível para quem vem do mundo x86.
No IBM Z isso faz parte do dia a dia.
Easter Egg nº 1
Você sabia que existem técnicos que substituem componentes internos do IBM Z enquanto ele continua processando milhões de transações?
Parece ficção científica.
Mas acontece.
Resiliência começa muito antes do desastre
Um erro comum é associar resiliência apenas ao Disaster Recovery.
Na verdade...
Disaster Recovery representa apenas uma pequena parte da estratégia.
Antes dele existem dezenas de mecanismos trabalhando continuamente.
ARM.
Parallel Sysplex.
GDPS.
Storage replicado.
WLM.
SMF.
Monitoramento.
Automação.
Tudo isso forma um enorme quebra-cabeça.
ARM — O operador que nunca dorme
Automatic Restart Manager.
Se um serviço cai...
ele pode reiniciar automaticamente.
Sem operador.
Sem ligação telefônica.
Sem abrir chamado.
Sem drama.
Imagine um Batch crítico.
Ele sofre um ABEND.
Sem ARM.
Operador.
Diagnóstico.
Restart.
Tempo.
Com ARM.
Detecção.
Restart.
Continuidade.
Essa diferença pode representar minutos.
Ou milhões de reais.
GDPS
Aqui entramos em outro nível.
Geographically Dispersed Parallel Sysplex.
Não estamos falando apenas de aplicações.
Estamos falando de Data Centers inteiros.
Imagine:
Uma enchente.
Um incêndio.
Falha elétrica.
Ataque físico.
Mesmo assim...
o ambiente continua funcionando.
Isso é GDPS.
Easter Egg nº 2
A maior parte das pessoas acredita que o maior inimigo do ambiente é o hardware.
Na prática...
um dos maiores SPOFs continua sendo...
o ser humano.
O operador continua sendo um SPOF
Single Point of Failure.
Existe uma brincadeira famosa entre Sysprogs.
"O maior ponto único de falha fica sentado na cadeira."
Parece piada.
Mas é verdade.
Boa parte dos incidentes graves começa com:
DELETE errado.
IPL errado.
PARMLIB errada.
JCL errada.
ALTER errado.
Por isso automação é tão importante.
DR Test
Existe outra máxima.
DR não testado...
...não existe.
Todo mundo gosta de mostrar diagramas bonitos.
Mas quando chega o momento do teste...
descobrem que:
Scripts estão desatualizados.
Documentação não funciona.
Equipe mudou.
Dependências não foram consideradas.
E justamente por isso os DR Tests existem.
Curiosidade
Algumas instituições financeiras realizam simulações completas de desastre.
Literalmente desligam parte do ambiente.
Tudo controlado.
Tudo documentado.
Tudo medido.
O objetivo não é provar que funciona.
É descobrir onde ainda pode falhar.
RPO e RTO
Esses dois indicadores aparecem em praticamente todas as entrevistas para Sysprog.
RPO.
Quanto dado posso perder?
RTO.
Quanto tempo posso ficar parado?
São perguntas simples.
Mas extremamente difíceis de responder.
Porque dependem do negócio.
Um banco e um supermercado possuem o mesmo RPO?
Não.
Um PIX pode exigir praticamente zero perda.
Já outro sistema administrativo pode aceitar alguns minutos.
Tudo depende da criticidade.
Parallel Sysplex
Talvez a maior obra de engenharia já construída no universo dos sistemas operacionais comerciais.
Diversos sistemas.
Compartilhando recursos.
Compartilhando dados.
Compartilhando carga.
Tudo funcionando como se fosse um único computador.
Quem vem do mundo Linux costuma dizer:
"Parece um cluster."
Não.
É muito mais sofisticado.
Easter Egg nº 3
Existe uma brincadeira antiga entre Sysprogs.
"Parallel Sysplex é aquele cluster que não resolve discutir quem é o líder."
Quem conhece algoritmos distribuídos entende a piada.
O futuro da profissão
Existe uma pergunta recorrente.
"O Sysprog vai acabar?"
Minha resposta é sempre a mesma.
Não.
Mas o Sysprog que conhece apenas ISPF...
talvez tenha dificuldades.
Hoje o profissional precisa conhecer:
REST APIs.
Python.
Ansible.
Zowe.
Git.
DevOps.
Observabilidade.
OpenTelemetry.
Containers.
OpenShift.
Cloud.
Não para abandonar o Mainframe.
Mas para integrá-lo.
O novo Sysprog
O novo profissional mistura tradição com modernização.
Continua dominando:
JCL.
SDSF.
RACF.
SMF.
RMF.
Mas também conversa naturalmente sobre:
GitHub.
CI/CD.
VS Code.
Terraform.
Automation.
IaC.
Esse profissional será extremamente valorizado.
Plano de estudos sugerido
Mês 1
Conceitos de RAS
RPO
RTO
SLA
Mês 2
Sysplex
Coupling Facility
WLM
Mês 3
GDPS
Storage
Replicação
Mês 4
ARM
Automação
NetView
System Automation
Mês 5
Zowe
Python
APIs
Ansible
Mês 6
Exercícios
DR Test
Laboratórios
Simulações
Onde aprender mais?
Para quem realmente quer se aprofundar, eu recomendaria estudar nesta ordem:
IBM Documentation
A documentação oficial continua sendo a principal referência técnica para IBM Z, z/OS, GDPS, Parallel Sysplex, WLM e demais componentes.
IBM Redbooks
Os Redbooks são praticamente livros técnicos escritos por especialistas da IBM e clientes. Um dos mais relevantes para este tema é Getting Started with IBM Z Resiliency, além de publicações sobre Parallel Sysplex, GDPS e z/OS.
IBM TechXchange
Apresentações de arquitetos IBM, sessões técnicas, estudos de caso e demonstrações práticas.
IBM Z Xplore
Ambiente gratuito para laboratórios, permitindo explorar tecnologias IBM Z de forma prática.
IBM SkillsBuild e IBM Learning
Cursos introdutórios e avançados sobre resiliência, z/OS, System Automation, GDPS, RACF, CICS, Db2 e diversas outras áreas.
SHARE Conference
Talvez o maior evento técnico do mundo voltado ao ecossistema IBM Z. É um excelente lugar para acompanhar tendências, novidades e relatos de grandes clientes.
Comunidade
Grupos técnicos, blogs especializados, fóruns e iniciativas como o Bellacosa Mainframe ajudam a transformar conhecimento técnico em conteúdo acessível, conectando teoria, prática e experiência de campo.
A maior lição
Depois de mais de sessenta anos de evolução tecnológica, existe uma conclusão interessante.
O maior diferencial do IBM Z nunca foi simplesmente seu hardware.
Nunca foi apenas o z/OS.
Nunca foi apenas o COBOL.
O verdadeiro diferencial sempre foi a filosofia de engenharia.
Projetar sistemas assumindo que falhas vão acontecer.
Não para reagir ao desastre.
Mas para impedir que ele se transforme em indisponibilidade.
Essa é a essência da resiliência.
E talvez seja exatamente por isso que, enquanto tantas tecnologias surgem e desaparecem, o IBM Z continua processando a maior parte das transações financeiras do planeta.
☕ Reflexão Final
"Um bom Sysprog mantém o sistema funcionando. Um excelente Sysprog faz com que ninguém perceba que dezenas de falhas aconteceram durante o dia. A verdadeira excelência em resiliência não é eliminar as falhas, mas construir uma arquitetura onde elas deixam de ser um problema para o negócio."
Essa é a filosofia que torna o IBM Z muito mais do que um computador: ele é uma plataforma construída para manter empresas, governos e economias funcionando, mesmo quando o inesperado acontece.
Sem comentários:
Enviar um comentário