Bellacosa Mainframe experimentos reisiliencia em IBM Z

💥 APERTA O ENTER E DERRUBA O DATA CENTER: SOBREVIVA AO LAB DE RESILIÊNCIA IBM Z

🧪 Laboratório prático — do ABEND ao FAILOVER sem perder um byte

---

🎯 OBJETIVO DO LAB

Você vai simular:

• 💣 Falha de aplicação (ABEND)
• ⚙️ Restart automático (ARM)
• 🧩 Continuidade (Sysplex mental model)
• 🌍 Disaster Recovery (simulado estilo GDPS)
• 📊 Validação de RPO/RTO

👉 Resultado esperado:
Sistema continua — usuário nem percebe

---

🧠 CENÁRIO (VIDA REAL)

Você é dev COBOL em um banco:

• Batch crítico processa pagamentos
• Roda em z/OS
• Usa Db2
• Integra com CICS

💥 E claro… algo vai dar errado.

---

🧪 LAB 1 — “PROVOQUE O CAOS” (ABEND CONTROLADO)

🎯 Objetivo:

Gerar uma falha real

---

📄 Passo 1 — Programa COBOL com erro

IDENTIFICATION DIVISION.
PROGRAM-ID. LABFAIL.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-NUM PIC 9(3) VALUE ZEROS.
01 WS-VAL PIC 9(3).

PROCEDURE DIVISION.
    MOVE 100 TO WS-VAL
    DIVIDE WS-VAL BY WS-NUM GIVING WS-VAL
    DISPLAY 'PROCESSO FINALIZADO'
    STOP RUN.

👉 Resultado esperado:

S0C7 ou S0CB (divisão por zero)

---

💡 Comentário Bellacosa

“Se você nunca causou um ABEND de propósito… você ainda não domina o sistema.”

---

⚙️ LAB 2 — “DEIXA O SISTEMA SE VIRAR” (ARM)

🎯 Objetivo:

Simular restart automático

---

🧠 Conceito

ARM = Automatic Restart Manager

👉 Ele reinicia automaticamente o que caiu

---

📄 Passo 2 — Simulação lógica

JOB FAIL → ABEND
ARM detecta → restart automático
JOB reinicia → continua fluxo

---

🧪 Teste

1. Execute o programa com erro
2. Corrija o erro (WS-NUM ≠ 0)
3. Reexecute

👉 Agora imagine:

• ARM faria isso sozinho
• Sem operador

---

💡 Insight

“ARM é o operador que nunca dorme.”

---

🧩 LAB 3 — “NÃO PARE O SISTEMA” (MENTALIDADE SYSPLEX)

🎯 Objetivo:

Entender continuidade

---

🧠 Simulação conceitual

Imagine:

• LPAR A → falha
• LPAR B → assume

---

📄 Fluxo

Transação → LPAR A
Falha → redireciona → LPAR B
Usuário continua

---

💡 Easter Egg 🔥

“Sysplex não é cluster…
é cluster que não te deixa na mão.”

---

🌍 LAB 4 — “PERDEMOS O DATA CENTER” (DR SIMULADO)

🎯 Objetivo:

Simular desastre total

---

🧠 Cenário

• Site A caiu 💥
• Site B assume

---

📄 Exercício

1. Imagine seu sistema rodando
2. “Desligue” mentalmente o ambiente
3. Suba outro ambiente

👉 Perguntas:

• Quanto tempo levou? (RTO)
• Perdeu dados? (RPO)

---

💡 Resposta ideal

• RTO → segundos/minutos
• RPO → zero

---

🔥 Insight

“Se você precisa pensar muito no DR… ele já falhou.”

---

🧨 LAB 5 — “DESCUBRA SEU SPOF”

🎯 Objetivo:

Encontrar ponto único de falha

---

📄 Checklist

• Um único job crítico?
• Um único DB?
• Um único operador? 😅

---

💡 Easter Egg

SPOF mais comum:
👉 Interface Teclado-Cadeira

---

🤖 LAB 6 — “AUTOMA OU MORRE”

🎯 Objetivo:

Entender automação

---

📄 Cenário

Sem automação:

• detectar
• analisar
• agir

👉 minutos ou horas

---

Com automação:

• detectar
• agir

👉 segundos

---

💡 Insight brutal

“Sem automação, seu RTO é humano.”

---

🧪 LAB 7 — DR TEST (O GRANDE FINAL)

🎯 Objetivo:

Validar tudo

---

📄 Simulação

1. Derrube o “ambiente”
2. Ative backup
3. Valide sistema

---

📊 Checklist

• Sistema subiu?
• Dados íntegros?
• Tempo aceitável?

---

💡 Regra de ouro

“DR não testado = DR inexistente”

---

🧠 CONSOLIDAÇÃO FINAL

---

🔗 RELAÇÃO DOS CONCEITOS

• RAS → evita impacto
• Models → define arquitetura
• Planning → garante execução

---

💥 Fluxo completo

Falha pequena → ARM resolve
Falha média → Sysplex resolve
Desastre total → DR/GDPS resolve

---

🏁 MISSÃO FINAL DO LAB

👉 Você não está testando sistema
👉 Você está testando sobrevivência do negócio

---

🔥 FRASE FINAL

“No mainframe, o erro não é falhar…
é deixar o usuário perceber.”

 

IBM Z Resiliência: A Engenharia Invisível que Mantém o Mundo Funcionando (E Quase Ninguém Percebe)

 

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.

Resiliência IBM Z – Conceitos Fundamentais: Por que os Mainframes Quase Nunca Param? Parte I

 

Bellacosa Mainframe ibm z resiliencia parte i

☕ Um Café no Bellacosa Mainframe

O Holocron da Resiliência IBM Z

Parte I – Conceitos Fundamentais: Por que os Mainframes Quase Nunca Param?

Quando um jovem Padawan COBOL entra pela primeira vez em uma empresa que utiliza IBM Z, normalmente ele acredita que seu trabalho consiste em escrever programas COBOL, executar alguns Jobs, consultar arquivos VSAM e, eventualmente, criar uma transação CICS.

Não demora muito para ouvir frases como:

"Precisamos garantir o SLA."

"O RTO deste sistema é de cinco minutos."

"Não podemos ter nenhum Single Point of Failure."

"Essa aplicação precisa ser resiliente."

Nesse momento, o Padawan percebe que entrou em um universo completamente diferente daquele ensinado na maioria dos cursos de programação.

No IBM Z, escrever software é apenas uma parte da engenharia. A outra metade consiste em garantir que esse software continue funcionando quando tudo ao redor começa a falhar.

Bem-vindo ao mundo da Resiliência.

Os conceitos apresentados nesta primeira parte são a base para compreender por que os maiores bancos, seguradoras, bolsas de valores, companhias aéreas e governos do mundo continuam confiando no IBM Z para executar suas aplicações mais críticas. Os termos discutidos a seguir fazem parte do glossário de Resiliency do IBM Z e representam os pilares conceituais dessa arquitetura.

---

O que significa Resiliency?

Imagine um hospital.

Ninguém espera que um hospital nunca enfrente problemas.

Equipamentos quebram.

Transformadores queimam.

Geradores precisam de manutenção.

Redes elétricas falham.

Mesmo assim...

A cirurgia não pode parar.

No mundo dos computadores acontece exatamente a mesma coisa.

Resiliência significa continuar prestando serviço mesmo quando partes da infraestrutura apresentam defeitos.

Esse é um conceito muito diferente de simplesmente "não quebrar".

Todo equipamento quebra.

Todo software possui defeitos.

Todo disco possui vida útil.

Toda memória pode apresentar falhas.

A diferença é que o IBM Z foi projetado assumindo que essas falhas acontecerão.

A arquitetura inteira trabalha para impedir que o usuário perceba qualquer interrupção.

Essa filosofia explica por que milhares de transações bancárias continuam acontecendo enquanto técnicos substituem processadores, discos ou placas de comunicação.

Para um programador COBOL, compreender Resiliency muda completamente a forma de pensar. O objetivo deixa de ser apenas fazer o programa "funcionar"; passa a ser escrever aplicações que convivam com uma infraestrutura preparada para falhas.

---

RAS – Reliability, Availability and Serviceability

Existe um conceito extremamente famoso dentro da IBM:

RAS.

São apenas três palavras.

Mas representam décadas de engenharia.

Reliability

Confiabilidade.

O equipamento precisa falhar pouco.

Isso envolve:

• qualidade dos componentes;

• redundância;

• testes de fábrica;

• validações contínuas.

Quanto maior a confiabilidade, menor a probabilidade de interrupções inesperadas.

---

Availability

Disponibilidade.

Mesmo quando alguma coisa quebra...

O serviço continua.

É exatamente aqui que entram conceitos como:

• Parallel Sysplex;

• GDPS;

• Load Balancing;

• WLM.

Disponibilidade não significa ausência de falhas.

Significa continuidade do negócio.

---

Serviceability

Facilidade de manutenção.

Imagine trocar um disco sem desligar o computador.

Ou substituir memória durante a operação.

Ou atualizar firmware sem interromper milhares de usuários.

Isso é Serviceability.

Quanto mais simples a manutenção...

Menor o tempo de indisponibilidade.

---

High Availability (HA)

Muitos iniciantes acreditam que Alta Disponibilidade significa "100% online".

Não é verdade.

Alta Disponibilidade significa reduzir o impacto das interrupções até um nível aceitável para o negócio.

Imagine dois caixas eletrônicos.

Se um apresentar defeito...

O cliente utiliza o outro.

Agora imagine dois servidores CICS.

Se um falhar...

O outro assume automaticamente.

Essa é a essência da HA.

A infraestrutura foi desenhada para absorver falhas sem interromper o serviço.

---

Disaster Recovery (DR)

Enquanto a Alta Disponibilidade lida com falhas locais, o Disaster Recovery pensa em eventos extremos.

Perguntas típicas são:

• E se o prédio pegar fogo?

• E se faltar energia por várias horas?

• E se houver uma enchente?

• E se todo o datacenter ficar inacessível?

Nesse cenário entra o Plano de Recuperação de Desastres.

O objetivo não é impedir o desastre.

É garantir que o negócio sobreviva a ele.

No IBM Z, tecnologias como GDPS, replicação de dados e sites espelhados fazem parte dessa estratégia.

---

SLA – Service Level Agreement

Todo sistema existe para atender um negócio.

E o negócio estabelece compromissos.

Exemplo:

"O Internet Banking deve permanecer disponível 99,99% do tempo."

Isso é um SLA.

Curiosamente, poucas pessoas percebem o impacto desses números.

Veja:

• 99% parece excelente.

• 99,9% é muito melhor.

• 99,99% é extraordinário.

• 99,999% representa apenas alguns minutos de indisponibilidade por ano.

Cada "9" adicional exige muito mais investimento em hardware, software, processos e pessoas.

---

RPO – Recovery Point Objective

Imagine que um banco sofra uma pane às 15h.

Qual o último dado aceitável?

15h00?

14h59?

14h30?

Ontem?

Essa resposta define o RPO.

Quanto menor o RPO...

Menor a perda de informações.

Em sistemas financeiros modernos, o objetivo costuma ser próximo de zero.

Nenhuma transação pode desaparecer.

---

RTO – Recovery Time Objective

Agora faça outra pergunta.

Quanto tempo o sistema pode permanecer parado?

Cinco minutos?

Uma hora?

Quatro horas?

Isso é o RTO.

Observe a diferença.

O RPO mede perda de dados.

O RTO mede tempo de recuperação.

São conceitos diferentes.

E ambos determinam toda a arquitetura de um ambiente corporativo.

---

Single Point of Failure (SPoF)

Este talvez seja o termo mais importante para qualquer arquiteto.

Imagine um único switch de rede.

Se ele quebrar...

Toda a empresa para.

Esse switch é um SPoF.

Agora pense em um único banco de dados.

Ou uma única fonte de alimentação.

Ou um único servidor DNS.

Todos são candidatos a pontos únicos de falha.

A missão dos arquitetos IBM Z é eliminar todos eles.

Por isso existem componentes redundantes, caminhos alternativos e múltiplos mecanismos de recuperação.

---

Component Failure Impact Analysis (CFIA)

O nome parece complicado.

Mas a ideia é simples.

Pergunte para cada componente:

"O que acontece se você morrer agora?"

Depois repita para:

• discos;

• processadores;

• memória;

• switches;

• links;

• storages;

• sistemas operacionais.

Se alguma resposta for:

"Tudo para."

Você encontrou um problema.

O CFIA é justamente o exercício sistemático de identificar esses riscos antes que eles ocorram.

---

ITIL – Muito Além da Tecnologia

Muitos desenvolvedores imaginam que disponibilidade depende apenas do hardware.

Na prática, processos mal definidos também derrubam sistemas.

É aqui que entra a ITIL.

Ela organiza boas práticas para:

• mudanças;

• incidentes;

• problemas;

• configuração;

• continuidade;

• disponibilidade.

Quando uma grande instituição financeira realiza uma atualização em produção, normalmente existe todo um processo inspirado nessas práticas para reduzir riscos.

---

A Mentalidade IBM Z

Existe uma frase bastante conhecida entre profissionais experientes de Mainframe:

"No IBM Z, falhas são esperadas. O que não é aceitável é que elas interrompam o negócio."

Essa mentalidade muda completamente a forma de desenvolver software.

O programador COBOL deixa de enxergar apenas linhas de código e passa a compreender que sua aplicação faz parte de um ecossistema muito maior, onde hardware, sistema operacional, middleware, armazenamento e processos trabalham em conjunto para garantir continuidade.

Cada programa Batch, cada transação CICS e cada acesso ao Db2 participa de uma cadeia cuidadosamente projetada para manter milhões de pessoas utilizando serviços bancários, comprando passagens aéreas, movimentando bolsas de valores ou recebendo benefícios sociais sem sequer imaginar a complexidade escondida por trás de uma simples tela.

Esse é o verdadeiro espírito do IBM Z.

Não construir computadores que nunca falham.

Mas construir sistemas que continuam funcionando mesmo quando inevitavelmente algo dá errado.

No próximo capítulo, deixaremos os conceitos e entraremos na infraestrutura física do IBM Z, explorando componentes como CPC, Processing Units, HMC, Support Element, License Internal Code e outros elementos que fazem do mainframe uma das plataformas mais resilientes já criadas.

IBM Z Resiliency : 20 Laboratórios Práticos para um Padawan COBOL

 

Bellacosa Mainframe e o laboratorio pratico em IBM Z Resiliency

☕ O Holocron da IBM Z Resiliency

Este material foi desenvolvido para ajudar o programador COBOL Padawan a compreender que, no universo IBM Z Mainframe, escrever código é apenas parte da construção de sistemas críticos. O objetivo é apresentar os conceitos de IBM Z Resiliency de forma progressiva, combinando teoria, exemplos práticos e 20 laboratórios que mostram como desenvolver aplicações mais confiáveis, disponíveis e preparadas para falhas. 

A metodologia adota uma abordagem "do básico ao avançado", na qual cada laboratório amplia os conhecimentos sobre RAS (Reliability, Availability and Serviceability), High Availability, Disaster Recovery, Parallel Sysplex, GDPS, Db2, CICS e boas práticas de desenvolvimento para ambientes corporativos.

No dia a dia, o desenvolvedor aprenderá a implementar tratamentos de erro, checkpoints, commits, rollback, logs, estratégias de retry, idempotência e recuperação automática, compreendendo como seu código influencia diretamente a continuidade dos negócios. Mais do que programar, o profissional passa a entender a infraestrutura que sustenta aplicações bancárias, governamentais e de grandes empresas. 

As boas práticas incluem escrever código limpo, tratar exceções adequadamente, monitorar desempenho, documentar processos, eliminar pontos únicos de falha, colaborar com Sysprogs e DBAs e adotar ferramentas modernas como Git, Zowe, DevOps, APIs REST e Inteligência Artificial. Dessa forma, o Padawan evolui para um desenvolvedor capaz de criar soluções resilientes, escaláveis e preparadas para os desafios do IBM Z moderno.

20 Laboratórios Práticos para um Padawan COBOL

Do "Meu Programa Funciona" até "Meu Sistema Nunca Para"

Objetivo: ensinar um desenvolvedor COBOL a pensar como um engenheiro de sistemas críticos, entendendo que escrever código é apenas uma parte da construção de aplicações resilientes no IBM Z.

---

LAB 1 — Descobrindo os Pontos Únicos de Falha (SPoF)

Objetivo

Entender por que um único componente pode derrubar um sistema inteiro.

Cenário

Você possui:

• 1 servidor

• 1 disco

• 1 banco Db2

• 1 aplicação COBOL

Desenhe toda a arquitetura.

Agora marque todos os componentes que, caso parem, derrubam o sistema.

Solução

Perceba que praticamente tudo é um SPOF.

Aprendizado

Antes de eliminar falhas, é preciso encontrá-las.

💡 Dica: faça isso também com aplicações.

---

LAB 2 — Medindo o Custo do Downtime

Objetivo

Entender por que disponibilidade vale dinheiro.

Exercício

Imagine:

• Banco realiza 15.000 transações/segundo

• Receita média R$ 0,12 por transação

Calcule perdas para:

• 1 minuto

• 10 minutos

• 1 hora

Solução

O prejuízo cresce rapidamente e ainda não inclui imagem, multas ou clientes perdidos.

💡 Truque: disponibilidade é uma decisão financeira, não apenas técnica.

---

LAB 3 — O Primeiro COMMIT

Objetivo

Entender recuperação transacional.

Exercício

Atualize 1 milhão de registros.

Versão A

Sem COMMIT.

Versão B

COMMIT a cada 5.000 registros.

Solução

Simule uma interrupção.

Qual versão reinicia mais rápido?

---

LAB 4 — Criando Checkpoints

Objetivo:

Implementar restart.

Crie:

• arquivo CHECKPOINT

• posição do último registro

Simule queda.

Continue do ponto salvo.

💡 Essa técnica é usada há décadas em grandes batchs.

---

LAB 5 — Simulando Deadlock

Utilize duas sessões Db2.

Sessão A

Atualiza CLIENTE.

Sessão B

Atualiza CONTA.

Depois inverta.

Observe:

• SQLCODE

• timeout

• deadlock

Solução

Aprenda ordem consistente de atualização.

---

LAB 6 — Tratando SQLCODE Corretamente

Crie um programa que trate:

• +100

• -803

• -911

• -913

Não apenas DISPLAY.

Faça:

• rollback

• log

• retorno correto

---

LAB 7 — Criando Logs Inteligentes

Todo programa deve registrar:

• data

• hora

• usuário

• JOBNAME

• programa

• chave

• SQLCODE

• mensagem

Depois analise o log.

Descubra o erro sem recompilar.

---

LAB 8 — O Primeiro Retry

Imagine:

Db2 indisponível por poucos segundos.

Implemente:

Tentativa 1

Espera 2 segundos

Tentativa 2

Espera 5 segundos

Tentativa 3

Depois aborte.

Essa estratégia evita falhas temporárias.

---

LAB 9 — Descobrindo Gargalos

Utilize:

• EXPLAIN

• RUNSTATS

• índices

Compare:

SELECT eficiente

vs

TABLESPACE SCAN

Descubra quanto CPU pode ser economizada.

---

LAB 10 — Idempotência

Crie um pagamento.

Execute duas vezes.

O dinheiro pode ser debitado novamente?

Se sim,

o programa não é resiliente.

---

LAB 11 — Introdução ao WLM

Converse com um Sysprog.

Pergunte:

• Service Class

• Importance

• Velocity

Descubra onde seu batch roda.

Poucos desenvolvedores conhecem isso.

---

LAB 12 — Conhecendo o Parallel Sysplex

Pesquise:

• Coupling Facility

• Data Sharing

• Sysplex Distributor

Desenhe:

LPAR A

LPAR B

LPAR C

CF

Explique como seu programa continua disponível.

---

LAB 13 — Explorando o CICS

Descubra:

O que acontece quando uma região CICS cai?

Quem reinicia?

Como outra região assume?

Pesquise:

• TOR

• AOR

• DOR

• FOR

---

LAB 14 — Simulando Recovery

Imagine:

Servidor caiu.

Liste passo a passo.

• quem liga?

• quem recupera?

• quem valida?

• quem autoriza?

Perceba quantas equipes participam.

---

LAB 15 — Conhecendo o GDPS

Estude:

Metro Mirror

Global Mirror

HyperSwap

Depois responda:

Como um banco continua funcionando após perder um datacenter inteiro?

---

LAB 16 — Health Check

Aprenda:

IBM Health Checker

Descubra:

• parâmetros incorretos

• riscos

• alertas

Muitos problemas são encontrados antes da falha.

---

LAB 17 — Observabilidade

Monte um mini dashboard.

Colete:

• CPU

• I/O

• Tempo SQL

• Tempo CICS

• Batch

Analise tendências.

Não espere a reclamação do usuário.

---

LAB 18 — Engenharia do Erro

Pegue um programa antigo.

Liste:

• IF sem ELSE

• SQLCODE ignorado

• FILE STATUS ignorado

• GO TO excessivo

• PERFORM infinito

Corrija.

Compare antes/depois.

---

LAB 19 — Arquitetura Resiliente

Desenhe uma arquitetura moderna contendo:

IBM Z

↓

Parallel Sysplex

↓

Db2 Data Sharing

↓

MQ

↓

CICS

↓

z/OS Connect

↓

API REST

↓

Aplicativo Mobile

Agora marque:

Onde existe redundância?

Onde ainda há SPOF?

---

LAB 20 — O Projeto Final do Mestre Padawan

Construa um mini sistema bancário.

Funcionalidades

✔ Cadastro

✔ Consulta

✔ Depósito

✔ Saque

✔ Transferência

Implemente:

• tratamento de erros

• rollback

• commit

• logs

• checkpoint

• restart

• retry

• validações

• auditoria

• mensagens MQ (simuladas ou documentadas)

• documentação operacional

• diagrama de arquitetura

• plano de recuperação em caso de falha

Depois responda:

• Quanto tempo o sistema leva para voltar após uma falha?

• Existe risco de perda de dados?

• Há pontos únicos de falha?

• Como o operador identifica problemas?

• Como um Sysprog ajudaria a resolver um incidente?

---

Missões Extras (XP para Padawans)

Bronze

• Aprender SDSF

• Ler SYSOUT

• Entender ABENDs comuns (S0C7, S0C4, S806)

• Navegar no ISPF

Prata

• Aprender SMF

• Conhecer RMF

• Ler EXPLAIN do Db2

• Entender WLM

Ouro

• Estudar Parallel Sysplex

• Coupling Facility

• Db2 Data Sharing

• ARM

• SFM

• IBM Health Checker

Platina

• GDPS

• Metro Mirror

• Global Mirror

• HyperSwap

• Continuous Availability

• Zero Data Loss

Mestre Jedi do Mainframe

• z/OS Connect

• APIs REST

• Git e GitHub

• Zowe CLI

• VS Code

• DevOps

• OpenTelemetry

• Observabilidade

• Ansible

• Inteligência Artificial aplicada ao COBOL

• Engenharia de Resiliência

---

Conselho Final do Mestre

Um programador COBOL iniciante acredita que seu trabalho termina quando o compilador retorna RC=0. Um profissional experiente sabe que esse é apenas o começo. A verdadeira excelência está em construir aplicações que possam ser interrompidas, reiniciadas, recuperadas, monitoradas, auditadas e evoluídas sem comprometer o negócio.

Quando você domina resiliência, deixa de ser apenas um programador de COBOL. Você se torna um engenheiro de sistemas críticos, capaz de desenvolver soluções que sustentam bancos, seguradoras, bolsas de valores e governos. Essa é a diferença entre dizer "Meu programa funciona" e afirmar com confiança "Meu sistema nunca para."

IBM Z Resiliency Como um Padawan COBOL Pode Evoluir do "Meu Programa Funciona" para "Meu Sistema Nunca Para"

 

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.

🛡️ IBM Z Resiliency : Por que o mainframe foi feito para não cair — e o mundo digital ainda corre atrás

 

🛡️ IBM Z Resiliency

Por que o mainframe foi feito para não cair — e o mundo digital ainda corre atrás

“Downtime não é um incidente técnico. É um evento de negócio.”

No mundo atual, onde uma falha de segundos vira trending topic e uma indisponibilidade de minutos custa milhões, resiliência deixou de ser luxo e virou sobrevivência.
E é exatamente aqui que o IBM Z entra em cena — não como moda, mas como engenharia.

Este artigo nasce do conteúdo do curso IBM Z Resiliency, mas vai além: traduz conceitos, conecta história, provoca reflexão e mostra por que o mainframe continua sendo o porto seguro do digital.

---

☕ O que é Resiliência — e por que não é só “alta disponibilidade”

Muita gente confunde resiliência com uptime.
Mas uptime é métrica. Resiliência é comportamento.

Um sistema resiliente:

• Falha (porque tudo falha)

• Se adapta

• Se recupera rápido

• E, muitas vezes, falha sem que o usuário perceba

📌 No IBM Z, o objetivo não é evitar a falha a qualquer custo — é garantir que ela não vire um problema de negócio.

---

💥 Quando o sistema cai, o negócio cai junto

Downtime não afeta só TI. Ele afeta:

• 💳 Transações não realizadas

• 🏦 Operações financeiras interrompidas

• ⚖️ Penalidades regulatórias

• 😡 Clientes que não voltam

E no mundo digital:

• 99,9% não é “excelente”

• 99,99% é o mínimo aceitável

• 99,999% (five nines) é onde o IBM Z opera por padrão

👉 Five nines significa menos de 5 minutos de indisponibilidade por ano.
Não é marketing. É engenharia.

---

📊 Como se mede disponibilidade (e por que isso importa)

A conta é simples:

Disponibilidade = (Tempo total – Downtime) / Tempo total

Mas a interpretação não é.

Porque uma hora fora do ar:

• Às 3h da manhã ≠

• Às 11h de uma segunda-feira bancária

📢 Resiliência não é quanto tempo você ficou fora — é o impacto que isso causou.

---

🧱 RAS: o DNA do IBM Z

Quando falamos de IBM Z, falamos de RAS:

🔧 Reliability (Confiabilidade)

• Componentes redundantes

• Correção automática de erros

• Falhas detectadas antes de virarem incidentes

📌 Há casos reais em que o cliente nunca soube que um componente falhou.

---

⏱ Availability (Disponibilidade)

• Substituição de peças com sistema ligado

• Workloads realocados automaticamente

• Sysplex mascarando falhas de LPAR ou CPC

📢 No mundo distribuído, reiniciar é normal.
No mainframe, é exceção.

---

🛠 Serviceability (Manutenibilidade)

• Diagnóstico preciso

• Call Home automático

• Menos tempo para resolver, menos impacto

👉 O IBM Z foi feito para ser consertado em produção.

---

🌍 Modelos de Resiliência no IBM Z

Nem todo ambiente precisa do mesmo nível de proteção. Por isso existem modelos de resiliência.

1️⃣ Sistema único resiliente

• Um IBM Z

• Forte uso de RAS

• Recuperação rápida

✔️ Simples
❌ Sem proteção contra desastre físico

---

2️⃣ Alta disponibilidade local

• Sysplex

• Múltiplos LPARs

• Failover quase invisível

✔️ Excelente para ambientes críticos
❌ Ainda preso a um único site

---

3️⃣ Resiliência geográfica (GDPS)

• Sites separados

• Replicação de dados

• Failover automatizado

✔️ Proteção real contra desastre
✔️ RTO extremamente baixo
💰 Investimento maior, mas justificado

---

4️⃣ Disponibilidade contínua

• Zero downtime percebido

• Automação total

• Planejamento extremo

📢 Aqui não se fala em “se cair”, mas em “quando cair, ninguém percebe”.

---

🧠 Planejar Resiliência é mais do que comprar hardware

Um erro clássico: achar que resiliência se compra.

Ela se projeta.

Princípios fundamentais:

✔️ Falhas são normais
✔️ RTO e RPO bem definidos
✔️ Automação acima de intervenção manual
✔️ Testes frequentes de DR
✔️ Pessoas treinadas e processos claros

📌 Plano de desastre não testado é ficção técnica.

---

🧩 O diferencial do IBM Z

O IBM Z não é resiliente por acaso.

Ele nasceu em uma época em que:

• Sistemas não podiam cair

• Transações não podiam ser perdidas

• Clientes não aceitavam erro

Enquanto muitos ambientes ainda tentam alcançar resiliência com camadas de software, o mainframe nasceu resiliente.

---

🎯 Conclusão – Resiliência não é moda. É sobrevivência.

No fim do dia, a pergunta não é:

“Meu sistema vai falhar?”

Mas sim:

“O que acontece quando ele falhar?”

No IBM Z, a resposta é simples:

O negócio continua.

☕💻 Isso é resiliência. Isso é mainframe.

 

📘 Visão Geral do Curso – IBM Z Resiliency

Objetivo do curso

Compreender os conceitos de resiliência no IBM Z e o valor da recuperação rápida, mostrando por que o mainframe é a espinha dorsal de negócios digitais que não podem parar.

Público-alvo

• Profissionais novos em resiliência no IBM Z

• Analistas, operadores, sysprogs iniciantes

• Profissionais de TI vindos de ambientes distribuídos que precisam entender por que o mainframe é diferente

👉 É um curso conceitual, não técnico profundo, focado em mentalidade, fundamentos e arquitetura.

---

🧠 Resumo Executivo (em uma frase)

O curso ensina por que o IBM Z foi projetado para não parar, como medir disponibilidade, quais mecanismos de hardware e software garantem isso, quais modelos de resiliência existem e como planejar sistemas realmente resilientes.

---

🔹 TÓPICO 1 – Resiliency: The key to the survival of a digital business

🎯 Objetivo do tópico

• Entender como o downtime afeta clientes e usuários

• Conhecer formas de medir disponibilidade

📌 Explicação prática

O que é Resiliência

Resiliência não é apenas alta disponibilidade.
É a capacidade de um sistema:

• Continuar operando mesmo com falhas

• Recuperar rapidamente

• Minimizar impacto ao negócio e ao cliente

📢 Sistema resiliente não é o que nunca falha — é o que falha sem ser percebido.

---

💥 Impacto do downtime

Downtime afeta diretamente:

• 💰 Receita (transações não realizadas)

• 📉 Reputação da empresa

• ⚖️ Compliance (bancos, seguradoras, governo)

• 😡 Experiência do cliente

No mundo digital:

• Milissegundos importam

• Minutos custam milhões

• Horas podem matar um negócio

---

📊 Como medir disponibilidade

Disponibilidade normalmente é medida como:

Disponibilidade (%) = (Tempo total – Tempo de indisponibilidade) / Tempo total

Exemplo clássico:

• 99,9% (three nines) → ~8,7 horas de downtime por ano

• 99,999% (five nines) → ~5 minutos por ano

👉 O IBM Z foi projetado para five nines ou mais, algo extremamente difícil em ambientes distribuídos.

---

🔹 TÓPICO 2 – IBM Reliability, Availability, Serviceability (RAS)

🎯 Objetivo

Descrever como hardware e software suportam a resiliência do IBM Z.

📌 O que é RAS

RAS é um princípio de engenharia, não um produto.

🔧 Reliability (Confiabilidade)

• Componentes projetados para falhar menos

• Detecção proativa de erros

• Redundância física e lógica

Exemplos no IBM Z:

• CPUs redundantes

• Memória com ECC avançado

• Detecção e correção automática de falhas

---

⏱ Availability (Disponibilidade)

• Capacidade de continuar operando mesmo com falhas

• Substituição de componentes sem desligar o sistema

Exemplos:

• Hot swap de componentes

• Workload sendo redistribuído automaticamente

• Sysplex mascarando falhas de um nó

---

🛠 Serviceability (Manutenibilidade)

• Diagnóstico rápido

• Reparos sem impacto ao negócio

Exemplos:

• Call Home automático para IBM

• Logs detalhados de falha

• Manutenção com sistema online

📢 No IBM Z, muitas falhas são corrigidas antes mesmo do cliente perceber.

---

🧠 Importante

RAS não é só hardware:

• z/OS

• CICS

• DB2

• JES

• Sysplex

• WLM

Tudo foi desenhado com a filosofia de nunca parar.

---

🔹 TÓPICO 3 – IBM Z Resiliency Models

🎯 Objetivo

Descrever as características dos quatro modelos de resiliência

📌 Os quatro modelos (visão conceitual)

1️⃣ Single system resiliency

• Um único IBM Z

• Usa RAS para evitar falhas

• Recuperação rápida, mas sem site alternativo

✔️ Bom para ambientes menores
❌ Vulnerável a desastres físicos

---

2️⃣ Local high availability

• Uso de Sysplex

• Múltiplos LPARs ou CPCs no mesmo site

• Failover quase transparente

✔️ Altíssima disponibilidade
❌ Ainda dependente de um único local físico

---

3️⃣ Geographically Dispersed Parallel Sysplex (GDPS)

• Sites geograficamente separados

• Replicação de dados

• Failover automatizado

✔️ Proteção contra desastre
✔️ Recovery Time Objective (RTO) muito baixo
💰 Custo mais elevado

---

4️⃣ Continuous availability / Business resilience

• Zero downtime percebido

• Planejamento extremo

• Automação total

✔️ Missão crítica absoluta
✔️ Bancos, bolsas, governos
📢 Aqui o negócio não pode parar nunca.

---

🔹 TÓPICO 4 – Planning for Resiliency

🎯 Objetivo

Definir princípios que contribuem para a resiliência.

📌 Planejar resiliência não é comprar hardware

Princípios fundamentais:

🧩 1. Pensar em falhas como algo normal

• Tudo falha

• O plano deve assumir isso

---

📋 2. Definir RTO e RPO

• RTO: quanto tempo posso ficar fora?

• RPO: quanto dado posso perder?

Sem isso, não existe resiliência — só achismo.

---

🔁 3. Automação

• Failover manual não escala

• IBM Z foi feito para automação

---

🧪 4. Testar, testar e testar

• Plano não testado = plano inexistente

• DR sem teste falha quando é mais necessário

---

🧠 5. Pessoas e processos

• Tecnologia sem pessoas treinadas não funciona

• Documentação clara

• Papéis definidos

📢 Resiliência é 50% tecnologia e 50% processo.

---

🧾 Conclusão Geral do Curso

Este curso:

• Não ensina comandos

• Não ensina instalação

• Ensina mentalidade de resiliência no IBM Z

É ideal para:

• Quem vem de cloud/distribuído

• Quem acha que “mainframe é caro”

• Quem nunca viu um sistema rodar anos sem downtime