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.

Kōtetsujō no Kabaneri : Quando um Datacenter IBM Z Virou uma Fortaleza Sobre Trilhos e o ABEND da Humanidade Começou

 

Bellacosa Maiframe e a fortaleza sobre trilhos dos kabaneri

☕ Um Café no Bellacosa Mainframe

Kōtetsujō no Kabaneri (甲鉄城のカバネリ): Quando um Datacenter IBM Z Virou uma Fortaleza Sobre Trilhos e o ABEND da Humanidade Começou

O anime steampunk que ensina mais sobre Resiliência, Continuidade de Negócios e Engenharia de Sistemas do que muitos cursos corporativos

---

Introdução

Imagine que, em vez de servidores Linux espalhados pela nuvem, toda a humanidade dependesse de alguns poucos datacenters isolados, ligados apenas por uma infraestrutura ferroviária altamente protegida. Agora imagine que um malware biológico extremamente agressivo invadisse esses ambientes, transformando qualquer usuário infectado em um processo impossível de encerrar.

Esse é o universo de Kōtetsujō no Kabaneri, conhecido internacionalmente como Kabaneri of the Iron Fortress. Embora muitos o tenham chamado de "Attack on Titan com zumbis", essa comparação é simplista. A obra possui identidade própria, combinando horror, steampunk, drama, ação e uma interessante reflexão sobre tecnologia, isolamento, medo coletivo e sobrevivência.

Para quem trabalha com IBM Z, COBOL, Sysplex e Resiliência Operacional, assistir a esse anime é como observar um gigantesco exercício de Disaster Recovery em escala nacional.

---

Ficha Técnica

Título original: 甲鉄城のカバネリ (Kōtetsujō no Kabaneri)

Título internacional: Kabaneri of the Iron Fortress

Autor (conceito original): Ichirō Ōkouchi

Diretor: Tetsurō Araki

Estúdio: Wit Studio

Character Design: Haruhiko Mikimoto

Música: Hiroyuki Sawano

Lançamento: 8 de abril de 2016

Exibição: abril a junho de 2016

Episódios: 12

Continuação: Filme The Battle of Unato (2019)

---

Classificação

• Ação

• Horror

• Pós-apocalíptico

• Steampunk

• Fantasia Sombria

• Drama

• Suspense

• Sobrevivência

Classificação indicativa: aproximadamente 17+ devido à violência intensa, sangue e cenas de horror.

---

Sinopse

Durante uma Revolução Industrial alternativa no Japão, um vírus transforma seres humanos em criaturas chamadas Kabane. Diferentemente dos zumbis tradicionais, eles possuem um coração protegido por uma camada de aço, tornando-os extremamente difíceis de eliminar.

As cidades sobreviventes tornam-se fortalezas muradas, conectadas apenas por trens blindados. Quando uma dessas fortalezas cai, o jovem engenheiro Ikoma consegue sobreviver parcialmente à infecção, tornando-se um Kabaneri: um híbrido entre humano e Kabane.

A bordo da locomotiva Kotetsujō (Fortaleza de Ferro), Ikoma inicia uma jornada para salvar a humanidade enquanto luta contra os monstros externos e os preconceitos internos.

---

Resumo da História

A narrativa acompanha uma sociedade em colapso permanente. Não existe governo central forte, nem comunicação ampla entre as cidades. Cada estação ferroviária tornou-se praticamente um pequeno país.

O trem blindado Kotetsujō representa a última esperança de conexão entre esses enclaves. Durante a viagem, os personagens enfrentam ataques constantes dos Kabane, disputas políticas, traições, escassez de recursos e conflitos morais.

A história evolui de um simples combate contra monstros para uma reflexão sobre poder, manipulação e os limites da humanidade.

---

Os Personagens

Ikoma

O protagonista foge completamente do arquétipo clássico do herói musculoso.

É um engenheiro.

Um inventor.

Um solucionador de problemas.

Sua primeira reação diante da crise não é fugir, mas construir uma arma melhor.

No universo Bellacosa Mainframe, Ikoma seria aquele desenvolvedor COBOL que passa a madrugada inteira analisando um dump S0C7 até encontrar a verdadeira causa do problema.

---

Mumei

Talvez a personagem mais popular da série.

Ela é uma Kabaneri extremamente poderosa, treinada desde a infância para combater Kabane.

Por trás da aparência inocente existe uma guerreira marcada por manipulação psicológica, perda da infância e uma busca constante por identidade.

---

Ayame Yomogawa

Filha do governante da estação Aragane.

Representa liderança baseada em responsabilidade e empatia, contrastando com líderes que governam pelo medo.

---

Kurusu

Samurai encarregado da proteção de Ayame.

Inicialmente rígido e desconfiado, aprende que disciplina sem adaptação pode levar ao fracasso.

---

Biba Amatori

O antagonista principal.

Carismático, inteligente e estrategista, acredita que apenas o caos pode destruir uma sociedade considerada fraca.

Sua visão lembra administradores que preferem derrubar todo o ambiente para reconstruí-lo do zero, ignorando o custo humano dessa decisão.

---

O que torna Kabaneri diferente?

Embora muitos o comparem com Attack on Titan, existem diferenças importantes:

O cenário

Em vez de muralhas medievais, o mundo mistura:

• locomotivas a vapor;

• tecnologia industrial;

• armamentos improvisados;

• arquitetura inspirada no Japão do período Meiji.

O resultado é um dos cenários steampunk mais belos dos animes modernos.

Os zumbis

Os Kabane não são mortos-vivos lentos.

São rápidos, agressivos e possuem um coração protegido por ferro. Para derrotá-los é necessário precisão, estratégia e armas especializadas.

O protagonista

Ikoma vence pela inteligência e pela engenharia, não apenas pela força física.

A infraestrutura

O trem Kotetsujō não é apenas transporte: é uma cidade móvel, um centro logístico e uma linha de sobrevivência.

---

A análise Bellacosa Mainframe

Os Kabane são um malware impossível de erradicar

Pense nos Kabane como um ransomware de última geração.

Uma máquina comprometida infecta outra.

A propagação é exponencial.

Não existe antivírus.

Somente isolamento e contenção.

---

As fortalezas são Data Centers

Cada estação funciona como um grande ambiente IBM Z.

Possui:

• energia;

• armazenamento;

• produção;

• segurança;

• usuários;

• operações.

Quando uma estação cai, perde-se um centro inteiro de processamento.

---

O trem é um Parallel Sysplex

O Kotetsujō conecta ambientes isolados.

Transporta pessoas, recursos, conhecimento e esperança.

Se o trem parar, toda a infraestrutura nacional entra em colapso.

É praticamente um Parallel Sysplex sobre trilhos, garantindo continuidade operacional mesmo diante de falhas catastróficas.

---

Ikoma é um engenheiro DevOps

Enquanto outros apenas combatem sintomas, Ikoma busca entender a causa raiz.

Ele observa, testa, falha, ajusta e melhora continuamente.

É a mentalidade de um engenheiro que automatiza processos, otimiza pipelines e cria soluções resilientes em vez de depender apenas de esforço manual.

---

Biba representa o risco interno

Nem toda ameaça vem de fora.

No universo da segurança da informação, um atacante interno com privilégios elevados pode causar danos muito maiores do que qualquer invasor externo.

Biba simboliza exatamente essa ameaça: alguém que conhece o sistema profundamente e usa esse conhecimento para explorá-lo.

---

Mensagens ocultas

O medo destrói mais que o vírus

Grande parte das mortes ocorre porque pessoas entram em pânico ou passam a desconfiar umas das outras.

A obra mostra como sociedades podem ruir quando o medo substitui a cooperação.

---

Engenharia salva vidas

Sem manutenção, sem inovação e sem pessoas capazes de criar novas soluções, nenhuma fortaleza sobrevive.

O anime valoriza engenheiros, mecânicos e inventores tanto quanto guerreiros.

---

A tecnologia é neutra

O mesmo conhecimento capaz de salvar também pode ser usado para destruir.

Tudo depende da ética de quem o utiliza.

---

Humanidade é uma escolha

Os Kabaneri vivem entre dois mundos.

São vistos como monstros, mas continuam tentando agir com compaixão.

A pergunta central é: o que realmente define um ser humano? A aparência, a biologia ou as escolhas?

---

Aventuras marcantes

• A queda da estação Aragane.

• A fuga desesperada no Kotetsujō.

• A adaptação de Ikoma à condição de Kabaneri.

• Os combates contra Kabane gigantes.

• A chegada à estação Kongōkaku.

• O confronto ideológico com Biba.

• A batalha final pela sobrevivência.

Cada arco amplia o universo e revela que o verdadeiro desafio não é apenas vencer os Kabane, mas impedir que o medo transforme os sobreviventes em algo igualmente perigoso.

---

Impacto cultural

Embora não tenha alcançado o fenômeno global de Attack on Titan, Kabaneri of the Iron Fortress conquistou reconhecimento por sua qualidade técnica. A animação da Wit Studio, a direção dinâmica de Tetsurō Araki e a trilha sonora de Hiroyuki Sawano são frequentemente apontadas como seus maiores destaques.

A série também ajudou a consolidar o estúdio como referência em animações de ação de alto nível, além de reforçar a popularidade do subgênero steampunk em um período dominado por isekais.

---

Houve censura?

Não houve censura significativa à obra em si, mas alguns canais de televisão japoneses exibiram versões com ajustes de iluminação e redução da intensidade visual em determinadas cenas muito violentas, prática comum em transmissões de TV. As versões lançadas em Blu-ray restauraram integralmente essas cenas.

Em alguns países, a classificação indicativa elevada limitou horários de exibição ou exigiu avisos de conteúdo devido à violência gráfica e ao horror.

---

Vale a pena assistir?

Sem dúvida.

Mesmo com críticas ao ritmo da segunda metade e ao desenvolvimento do antagonista, Kabaneri of the Iron Fortress permanece como uma das produções visualmente mais impressionantes da década de 2010. Sua combinação de ação frenética, estética steampunk, trilha sonora marcante e reflexões sobre sobrevivência, liderança e inovação faz dele uma experiência única.

---

Veredito Bellacosa Mainframe

Se The Walking Dead mostra como grupos sobrevivem ao colapso da sociedade e Attack on Titan explora o medo do desconhecido, Kabaneri of the Iron Fortress ensina que a continuidade de uma civilização depende de infraestrutura, engenharia, logística e pessoas capazes de inovar sob pressão.

Para um profissional de IBM Z, a maior lição do anime é clara:

Um datacenter resiliente não é aquele que nunca sofre ataques. É aquele que continua operando mesmo quando o impossível acontece.

E é exatamente isso que o Kotetsujō representa: uma fortaleza móvel onde tecnologia, disciplina, colaboração e coragem mantêm a humanidade "online", mesmo quando todo o restante do mundo entrou em ABEND.

 

Bellacosa Mainframe introduz o disaster recovery

O que é Disaster Recovery (DR) em Mainframe?

Imagine a seguinte situação:

É uma segunda-feira de manhã.

Milhões de pessoas estão:

• usando PIX;

• comprando com cartão;

• acessando Internet Banking;

• consultando seguros;

• realizando operações financeiras.

De repente, ocorre uma falha grave no datacenter principal.

Pode ser:

• incêndio;

• enchente;

• apagão;

• falha elétrica;

• erro humano;

• ataque cibernético.

Se não existir um plano de recuperação, toda a operação pode parar.

É exatamente para isso que existe o:

Disaster Recovery (DR)

---

Definição simples

Disaster Recovery é o conjunto de processos, tecnologias e procedimentos criados para recuperar sistemas críticos após um desastre.

Seu objetivo é garantir que a empresa continue operando mesmo diante de eventos graves.

Em português podemos chamar de:

Plano de Recuperação de Desastres.

---

Uma analogia simples

Imagine um hospital.

Se faltar energia:

• os geradores entram em ação;

• equipamentos continuam funcionando;

• pacientes permanecem seguros.

O DR funciona da mesma forma.

Ele garante que os sistemas possam continuar operando mesmo quando algo muito sério acontece.

---

Por que o DR é importante?

Empresas modernas dependem totalmente de sistemas computacionais.

Imagine:

• um banco fora do ar por horas;

• uma companhia aérea sem reservas;

• uma seguradora sem acesso aos clientes;

• uma bolsa de valores indisponível.

O prejuízo pode atingir milhões ou até bilhões de reais.

Por isso o DR é considerado essencial.

---

O que pode causar um desastre?

Existem diversos cenários.

Falhas de hardware

Problemas em:

• servidores;

• storage;

• redes;

• equipamentos elétricos.

---

Falhas humanas

Exemplos:

• exclusão acidental de dados;

• configurações incorretas;

• procedimentos executados de forma errada.

---

Falhas elétricas

Exemplos:

• apagões;

• surtos de energia;

• problemas em subestações.

---

Desastres naturais

Como:

• enchentes;

• terremotos;

• incêndios;

• tempestades severas.

---

Ataques cibernéticos

Exemplos:

• ransomware;

• invasões;

• sabotagem;

• vazamento de dados.

---

O que o DR protege?

O DR protege:

• aplicações;

• bancos de dados;

• datasets;

• sistemas operacionais;

• transações;

• informações corporativas.

---

Como funciona um ambiente de DR?

Normalmente existem dois locais:

Site Primário

É o datacenter principal.

Onde as operações acontecem diariamente.

---

Site Secundário

Também chamado:

• DR Site;

• Recovery Site;

• Site de Contingência.

É o ambiente preparado para assumir as operações caso o principal falhe.

---

Arquitetura simplificada

SITE PRINCIPAL
      │
      │ Replicação
      ▼
SITE DE DR

Os dados são copiados continuamente entre os dois ambientes.

---

O que é replicação?

Replicação é o processo de copiar dados de um ambiente para outro.

Assim, o site de recuperação permanece atualizado.

---

Replicação síncrona

Os dados são gravados simultaneamente nos dois locais.

Vantagem:

• praticamente nenhuma perda de dados.

Desvantagem:

• maior custo;

• necessidade de baixa latência.

---

Replicação assíncrona

Os dados são enviados em intervalos.

Vantagem:

• menor custo;

• maior distância entre sites.

Desvantagem:

• pequena possibilidade de perda de dados recentes.

---

Objetivos principais do DR

Existem duas métricas famosas.

---

RTO

Recovery Time Objective

Representa:

Quanto tempo o sistema pode ficar parado.

Exemplo:

RTO = 2 horas

A recuperação deve ocorrer em até duas horas.

---

RPO

Recovery Point Objective

Representa:

Quanto dado a empresa aceita perder.

Exemplo:

RPO = 15 minutos

A empresa aceita perder no máximo os últimos quinze minutos de informações.

---

Estratégias de recuperação

---

1. Backup e Restore

A mais simples.

Processo:

1. realizar backup;

2. armazenar cópia;

3. restaurar quando necessário.

Vantagem:

• menor custo.

Desvantagem:

• recuperação mais lenta.

---

2. Site Frio (Cold Site)

Existe infraestrutura básica.

Os sistemas precisam ser instalados após o desastre.

Vantagem:

• barato.

Desvantagem:

• recuperação lenta.

---

3. Site Morno (Warm Site)

Parte dos sistemas já está preparada.

Vantagem:

• recuperação moderada.

Desvantagem:

• exige sincronização constante.

---

4. Site Quente (Hot Site)

Ambiente totalmente pronto.

Praticamente uma cópia do ambiente principal.

Vantagem:

• recuperação rápida.

Desvantagem:

• alto custo.

---

Como funciona no mundo Mainframe?

Os ambientes IBM Z utilizam tecnologias avançadas de recuperação.

---

GDPS

Geographically Dispersed Parallel Sysplex

Permite:

• automação de failover;

• gerenciamento de desastres;

• recuperação rápida.

É uma das soluções mais sofisticadas do mundo mainframe.

---

Parallel Sysplex

Permite múltiplos sistemas z/OS trabalhando juntos.

Caso um sistema falhe:

outro pode assumir.

---

DFSMS

Gerencia:

• storage;

• backup;

• recuperação;

• movimentação de dados.

---

FlashCopy

Tecnologia que cria cópias rápidas de volumes de armazenamento.

Muito utilizada em estratégias de DR.

---

Processo de recuperação

Quando ocorre um desastre:

1. Detecção

A equipe identifica o problema.

---

2. Avaliação

Analisa-se:

• impacto;

• risco;

• extensão da falha.

---

3. Ativação do DR

O plano de recuperação é acionado.

---

4. Recuperação

Os sistemas são iniciados no site secundário.

---

5. Validação

As equipes verificam:

• aplicações;

• bancos;

• transações;

• usuários.

---

6. Retorno

Após a normalização, os sistemas retornam ao ambiente principal.

---

O papel dos testes

Um DR que nunca foi testado não pode ser considerado confiável.

Por isso as empresas realizam:

• simulações;

• exercícios;

• failovers programados;

• testes de restauração.

---

Curiosidades incríveis

1. Alguns sites de DR ficam em outras cidades

Ou até em outros estados.

Isso reduz riscos de eventos regionais.

---

2. Grandes bancos possuem múltiplos ambientes

Muitas instituições operam com:

• produção;

• contingência;

• homologação;

• desenvolvimento.

---

3. O failover pode ser automático

Em alguns ambientes a troca ocorre com mínima intervenção humana.

---

4. O DR é exigido por auditorias

Órgãos reguladores frequentemente exigem comprovação dos planos de recuperação.

---

Erros comuns de iniciantes

"Backup é a mesma coisa que DR"

Não.

Backup é apenas uma parte do Disaster Recovery.

---

"Nunca vamos precisar usar"

Muitas empresas descobrem a importância do DR somente após uma crise.

---

"Ter um segundo servidor resolve"

Não.

Um plano completo envolve:

• pessoas;

• processos;

• tecnologia;

• documentação;

• testes.

---

Profissionais envolvidos

Diversas equipes participam do DR:

• operadores;

• sysprogs;

• DBAs;

• storage administrators;

• especialistas RACF;

• equipes de rede;

• infraestrutura;

• segurança.

---

Por que aprender DR?

Porque ele é um dos pilares da computação corporativa.

Entender DR ajuda a compreender:

• continuidade de negócios;

• alta disponibilidade;

• segurança operacional;

• arquitetura corporativa;

• gestão de riscos.

---

Conclusão

Disaster Recovery é muito mais do que um simples backup.

Ele representa a capacidade de uma organização continuar funcionando mesmo diante de eventos graves e inesperados.

No universo mainframe, onde milhões de transações dependem de disponibilidade contínua, o DR é uma das camadas mais importantes para garantir que bancos, governos e grandes empresas continuem operando com segurança, confiabilidade e resiliência.