🧠 Agile e Scrum : Do batch noturno ao sprint quinzenal

 

Bellacosa Mainframe em um projeto Agile Scrum 

🧠 Agile e Scrum

Do batch noturno ao sprint quinzenal — uma conversa franca de mainframeiro

“Agile não nasceu para matar o mainframe.
Nasceu para sobreviver ao mundo fora dele.”
— Bellacosa (provavelmente reclamando de um status meeting)

---

📜 Origem: quando o Waterfall começou a dar abend

Antes de Agile virar buzzword em slide corporativo, o mundo vivia sob o Waterfall:
analisa tudo → projeta tudo → codifica tudo → testa tudo → entrega tudo.

Funcionava…
👉 até o requisito mudar no meio do caminho.

No mainframe, isso era tolerável porque:

• sistemas eram estáveis

• mudanças eram raras

• o batch rodava à noite e ninguém mexia

Fora do CPD, o mundo começou a mudar rápido demais.

📅 2001 – O nascimento oficial do Agile

Em fevereiro de 2001, 17 desenvolvedores se reuniram em Utah (EUA) e escreveram o Manifesto Ágil.

📌 Easter egg histórico:
Nenhum deles falava em ferramenta, framework ou certificado.
Falavam de pessoas, colaboração e adaptação.

---

🔁 Scrum: o JES2 do Agile

Scrum não é metodologia.
Scrum é framework.

Assim como:

• JCL não é aplicação

• JES não é programa

• ISPF não escreve código

Scrum organiza o fluxo, mas não faz o trabalho por você.

📅 Scrum “oficial”

• Conceito inicial: 1986 (Takeuchi & Nonaka)

• Consolidação moderna: anos 1990

• Popularização absurda: 2010+ (quando começaram a estragar)

---

👥 Papéis do Scrum (tradução para mainframeiro)

• Product Owner
  👉 Dono do requisito, como o usuário que assina o change

• Scrum Master
  👉 Um misto de operador experiente + analista que tira impedimento do caminho

• Time
  👉 Quem realmente faz o sistema funcionar (igual sempre foi)

📌 Fofoquinha:
Em muitas empresas, o Scrum Master vira “chefe disfarçado”.
Isso quebra o Scrum mais rápido que DELETE sem backup.

---

🧩 User Story: o novo requisito funcional

User Story é simples:

Como <usuário>, quero <objetivo>, para <valor>.

Se você já escreveu:

• especificação funcional

• descrição de programa

• comentário de COBOL bem feito

👉 você já sabe escrever user story.

💡 Dica Bellacosa

User story grande demais é como JOB com 200 steps:
ninguém entende, ninguém testa, ninguém confia.

---

📊 Story Points: estimar sem mentir

Story Point não é hora, não é dia, não é prazo.

É:

• complexidade

• risco

• esforço relativo

📌 Easter egg Agile:
Times ruins transformam story point em hora escondida.
Times bons usam para prever, não para cobrar.

---

🗂️ Backlog e Kanban: o SDSF do projeto

O Product Backlog é a fila do sistema.
O Kanban Board é o painel:

• To Do

• In Progress

• Done

👉 Igual SDSF:

• você vê o que está rodando

• o que está esperando

• o que terminou

💡 Dica prática

Se tudo fica em “In Progress”, o problema não é Agile.
É falta de limite de WIP (Work in Progress).

---

📉 Burndown Chart: o SMF do Sprint

Burndown chart mostra:

• quanto trabalho falta

• se o sprint fecha

• se alguém mentiu na estimativa

📌 Curiosidade:
Scrum não manda “bater meta”.
Ele apenas mostra a realidade.
Quem não gosta do gráfico geralmente não gosta da verdade.

---

🧪 Execução diária: o batch agora é contínuo

Daily Stand-up

• Não é reunião de status

• Não é para gerente

• Não passa de 15 minutos

👉 É para sincronizar o time, como um checkpoint lógico.

Sprint Review

• Mostra o que foi entregue

• Não é teatro

Retrospective

• Onde o time melhora

• Onde a política costuma atrapalhar

---

🛠️ Ferramentas modernas (com cheiro de CPD)

• GitHub
  Versionamento, issues, colaboração
  👉 o novo Librarian/Endevor

• ZenHub
  Agile sobre o GitHub
  👉 backlog, sprint, burndown

• Boards nativos do GitHub
  Simples, mas funcionais

📌 Fofoquinha de bastidor:
Empresa que compra ferramenta antes de mudar cultura
só troca Waterfall por Agile fake.

---

🎓 Curso IBM – Quando a teoria encontra a prática

O curso Introduction to Agile Development and Scrum (IBM):

📅 Lançamento: década de 2020
🎯 Público: iniciantes
🧠 Abordagem: prática, direta, sem romantismo

Inclui:

• Agile

• Scrum

• Kanban

• GitHub

• ZenHub

• Projeto final completo

Faz parte do IBM DevOps and Software Engineering Professional Certificate.

---

🧠 Dicas Bellacosa (aprendidas na dor)

✔ Agile não acelera time ruim
✔ Scrum não salva projeto sem dono
✔ Ferramenta não substitui disciplina
✔ Daily não resolve problema estrutural
✔ Retrospective ignorada vira reunião inútil

---

🥚 Easter Eggs para quem veio do mainframe

• Agile é iterativo como release de sistema legado

• Sprint é mini-release controlado

• Burndown é SMF emocional do time

• Kanban é SDSF com post-it

• Waterfall é batch eterno sem restart

---

🎯 Conclusão: Agile não é moda, é sobrevivência

O mainframe sobreviveu porque:

• era estável

• era disciplinado

• evoluía sem quebrar

Agile sobrevive pelo mesmo motivo.

👉 Quem entende mainframe entende Agile mais rápido do que imagina.

No fim, muda a ferramenta.
Muda o ritmo.
Mas a verdade continua a mesma:

Sistema bom é aquele que entrega valor
sem acordar ninguém de madrugada.

— Bellacosa Mainframe ☕💾

📘 Treinamento Completo de Auditoria z/OS

Bellacosa Mainframe treinamento em Auditoria em IBM Z/OS

📘 Treinamento Completo de Auditoria z/OS

Estilo Bellacosa Mainframe — do técnico ao auditável

"Auditoria em z/OS não é um evento. É um estado permanente de controle."

---

🎯 Objetivo do treinamento

Capacitar profissionais de mainframe a:

• Preparar ambientes z/OS para auditoria

• Responder auditores com evidência técnica

• Evitar não conformidades

• Implementar governança contínua

Público-alvo:

• System Programmers

• Analistas de Segurança

• Auditores técnicos

• Arquitetos mainframe

---

🧱 Estrutura do treinamento

🧩 Módulo 1 – Fundamentos de Auditoria em z/OS

• O que o auditor realmente procura

• Tipos de auditoria (interna, externa, regulatória)

• Conceitos: evidência, rastreabilidade, segregação

• Por que z/OS já nasce auditável

📌 Entregável: checklist conceitual

---

🔐 Módulo 2 – Controle de Acesso (RACF)

• IDs privilegiados (SPECIAL, OPERATIONS)

• UACC e perfis genéricos

• Logging e SMF

• Revisão periódica de acessos

📌 Laboratório:

• Identificar riscos reais em perfis RACF

---

📦 Módulo 3 – SMP/E como pilar de integridade

• CSI, DLIB e TARGET

• RECEIVE, APPLY, ACCEPT

• APPLY CHECK

• ++HOLD, ++ERROR, ++VER

📌 Laboratório:

• Análise de PTF com HOLD de segurança

---

🧩 Módulo 4 – USERMOD e risco operacional

• Quando USERMOD é aceitável

• Documentação obrigatória

• Riscos em auditoria

• Plano de remoção

📌 Estudo de caso real

---

🔁 Módulo 5 – Gestão de Mudanças

• Integração SMP/E + Change Management

• Evidências exigidas

• Falhas clássicas em auditoria

📌 Oficina:

• Montar dossiê de mudança

---

🧪 Módulo 6 – Evidência técnica e rastreabilidade

• Outputs SMP/E

• Logs RACF

• SMF como prova

• Versionamento de JCL

📌 Laboratório:

• Criar pacote de evidências

---

🛡️ Módulo 7 – Segurança e Compliance

• PTFs de segurança

• Backlog e risco

• Auditorias regulatórias (SOX, PCI, LGPD)

📌 Discussão guiada

---

🔄 Módulo 8 – Continuidade e Recuperação

• Backup do CSI

• RESTORE na prática

• Testes documentados

📌 Laboratório:

• Simulação de rollback

---

📋 Módulo 9 – Auditoria passo a passo

• Como o auditor conduz a sessão

• Como responder perguntas difíceis

• O que nunca dizer

📌 Simulação completa de auditoria

---

🧠 Estudos de Caso Bellacosa

• USERMOD esquecido

• CSI sem backup

• ALTER irrestrito

• PTF de segurança atrasado

---

📜 Avaliação e Certificação

• Checklist executável preenchido

• Estudo de caso resolvido

• Avaliação prática

🎓 Certificado: Auditoria Técnica z/OS – Nível Profissional

---

🧰 Material complementar

• Checklist executável

• Modelos de evidência

• JCLs de laboratório

• Guia rápido para auditores

---

🏁 Encerramento

"No mainframe, auditoria não é medo. É maturidade operacional."

📘💾🛡️

📘 Treinamento Completo De Auditoria Z/os 

☕ UME, UMEBOSHI & CIA

 

Bellacosa Mainframe comendo obento com ume

☕ UME, UMEBOSHI & CIA
As ameixas japonesas que dão debuff no rosto… e buff na alma
(ao estilo Bellacosa Mainframe – El Jefe Midnight Lunch)

Tem coisa no Japão que parece simples, mas carrega séculos de cultura compactados. As famosas ameixas japonesas, ou melhor dizendo, o UME (梅), são exatamente isso: pequenas, azedinhas, quase agressivas… e absolutamente fundamentais.

E já aviso: quem morde uma umeboshi desprevenido toma um DEBUFF de careta nível S. 😖

---

ume

🌸 Origem: não é bem uma ameixa…

Tecnicamente, o ume está mais próximo do damasco do que da ameixa ocidental. Ele chegou ao Japão vindo da China por volta do século VII, junto com o budismo, a escrita e aquele pacote completo de “civilização importada”.

Desde cedo, o ume virou:

• remédio,

• conservante,

• símbolo de resistência.

Mainframe feelings: dataset pequeno, crítico e vital para o sistema.

---

umeboshi

🧂 Umeboshi: a conserva lendária

A umeboshi é o ume conservado em sal, muitas vezes seco ao sol e, às vezes, curado com shiso vermelho, que dá aquela cor rosada clássica.

Características:

• ácido forte (pH baixo = antibacteriano natural)

• salgado agressivo

• sabor que acorda até operador de madrugada

Era presença obrigatória no bentō dos samurais e camponeses.
Não estragava fácil, ajudava na digestão e dava energia.

Ou seja: BUFF portátil de sobrevivência.

---

Pasta de ume

🏯 História & uso tradicional

• Samurais levavam umeboshi para batalhas.

• Monges usavam como remédio digestivo.

• Agricultores confiavam na conserva para dias longos de trabalho.

Durante guerras e crises, a umeboshi era o fallback plan da alimentação japonesa.

No arroz branco?
Ela vai no centro, como checkpoint de sanidade.

---

🍶 Outras conservas & derivados

Além da clássica umeboshi:

• Umeshu 🍶 → licor doce feito com ume, açúcar e álcool

• Umeboshi suave → versão moderna, menos salgada

• Pasta de ume → usada em onigiri e molhos

• Ume seco → snack tradicional

Fofoquice:
Os japoneses mais velhos torcem o nariz para umeboshi “doce demais”.
“Isso aí é versão cloud, perdeu o mainframe raiz.”

---

📺 Animes & cultura pop

A umeboshi aparece direto, principalmente em:

• Naruto → bentō simples, comida de casa

• Shirobako → rotina, trabalho duro

• Barakamon → interior, tradição

• Totoro → comida simples, aconchego

Easter egg clássico:
Personagem morde umeboshi → silêncio → careta → respeito.

---

🧠 Simbolismo japonês

O ume representa:

• resistência no inverno,

• simplicidade,

• saúde,

• tradição.

Enquanto a sakura é efêmera, o ume é persistente.

Mainframe analogy:

• Sakura = batch bonito

• Ume = sistema que roda há 40 anos sem cair

---

💬 Comentário final do El Jefe

A umeboshi não tenta agradar.
Ela entrega o que promete.

É azeda, forte, honesta.
Como a vida.
Como o trabalho.
Como aquele sistema legado que ninguém ama… mas todo mundo precisa.

E quem aprende a gostar de umeboshi,
aprende a respeitar o essencial.

☕
Pequena, conservada, poderosa.
Dataset crítico da cultura japonesa.

🔥 KARUBI (カルビ) - O batch job mais confiável do yakiniku

 

Bellacosa Mainframe assando karubi em uma grelha domestica

🔥 KARUBI (カルビ)

O batch job mais confiável do yakiniku

Se existe um corte bovino que aparece mais em anime do que protagonista de isekai, esse corte é o Karubi.

Você já viu a cena:

• Grelha pequena no centro da mesa

• Carne fatiada

• Fogo baixo

• Alguém virando rápido com hashis

• Outro dizendo: “Não deixa passar!”

👉 Isso é Karubi.

---

🥩 O que é Karubi, afinal?

Karubi (カルビ) vem do coreano “Kalbi”, que significa:

costela

No Japão, virou:

• Costela bovina

• Com muita gordura entremeada

• Cortada bem fina

• Feita para grelhar rápido

📌 Easter egg nº 1:

Karubi não é corte “nobre” no sentido europeu.

Ele é corte social.

---

🔥 Por que Karubi aparece tanto em anime?

Porque ele carrega significado narrativo:

✔ Amizade

✔ Reunião

✔ Descanso

✔ Vida cotidiana

✔ Pós-batalha

✔ Pós-trabalho

Karubi é o equivalente culinário de:

“Missão cumprida. Vamos comer.”

---

🍖 Como o Karubi é preparado

• Corte fino

• Marinada simples (shoyu, alho, açúcar, óleo de gergelim)

• Fogo rápido

• Grelha pequena

• Comer na hora

💡 Regra sagrada:

Karubi não espera.

Karubi se come na grelha.

---

🥚 Easter eggs gastronômicos

🥚 Quanto mais fino o corte no anime, mais realista

🥚 Personagem virando Karubi = ele sabe o que faz

🥚 Karubi queimado = pecado capital

🥚 Anime nunca mostra a conta — Karubi é democrático

---

☕ Tradução para Mainframers

• Karubi = batch noturno confiável

• Sempre roda

• Nunca falha

• Todo mundo depende dele

Não é glamouroso como Wagyu A5,

mas sem ele… o sistema social cai.

---

🎌 Animes onde Karubi aparece (ou é fortemente sugerido)

🍱 Gastronomia / Slice of Life

• Yuru Camp – churrascos tranquilos, vida simples

• Oishinbo – cultura alimentar japonesa

• Shokugeki no Soma – yakiniku, marinadas e técnicas

• Sweetness & Lightning – comida como afeto

🎮 Vida cotidiana / Trabalho

• Working!!

• Wotakoi

• Barakamon

• My Senpai is Annoying

🧙 Pós-batalha / Fantasia

• Dungeon Meshi

• Konosuba (quando sobra dinheiro)

• Campfire Cooking in Another World

📌 Em muitos casos:

Não dizem “Karubi”

Mas a grelha + carne fina + brilho = assinatura visual.

---

🧠 Comentário Bellacosa Mainframe

Wagyu impressiona.

Ribeye respeita.

Mas Karubi conecta.

Ele é:

• O corte da conversa

• Do riso

• Do descanso

• Do “sentar junto”

Assim como no mainframe:

O sistema mais importante

não é o mais caro

é o que mantém tudo funcionando.

---

JOB FINALIZADO

RC=0

SYSOUT: “Fome crítica detectada.” 🔥🥩

SMP/E for z/OS : O guardião silencioso do mainframe

 

Bellacosa Mainframe apresenta o SMP/E 

SMP/E for z/OS

O guardião silencioso do mainframe (e por que você deve respeitá-lo)

Se existe uma ferramenta que todo System Programmer precisa conhecer profundamente, essa ferramenta é o SMP/E (System Modification Program / Extended).
Ele não aparece no painel bonito, não tem interface gráfica chamativa, mas é ele quem controla a saúde do z/OS.

👉 Sem SMP/E, o mainframe vira um Frankenstein de PTFs soltos.

---

📜 Origem e História

O SMP nasceu lá atrás, nos primórdios do OS/360, quando a IBM percebeu que:

“Instalar correções sem controle é pedir para quebrar o sistema.”

Com o tempo, o SMP evoluiu e virou SMP/E, agregando:

• Controle de dependências

• Histórico de mudanças

• Rastreabilidade total

• Capacidade de rollback (sim, isso já existia antes de DevOps virar moda)

📆 SMP/E acompanha o z/OS até hoje, sendo atualizado a cada release do sistema.

---

🧠 O que é o SMP/E, em poucas palavras

SMP/E é o gerenciador oficial de manutenção do z/OS.

Ele controla:

• Instalação

• Aplicação

• Aceitação

• Histórico

• Dependências

• Erros conhecidos

Tudo baseado em regras formais, nada de “copiar membro na mão”.

---

🧩 Conceitos-chave que todo mainframeiro precisa dominar

🔹 SYSMOD

É o pacote de mudança. Pode ser:

• PTF – correção

• APAR – problema reportado

• USERMOD – customização do cliente

• FUNCTION – novo produto ou base

---

🔹 MCS – Modification Control Statements

As MCS são as instruções que dizem ao SMP/E:

“O que é isso, onde entra, do que depende e como tratar.”

📌 Todas começam com:

++

Exemplos clássicos:

• ++VER

• ++MOD

• ++HOLD

• ++ERROR

---

🚨 ++ERROR — o alarme vermelho do SMP/E

O ++ERROR é usado para marcar um PTF como defeituoso.

👉 Em bom português Bellacosa:

“Instala por sua conta e risco.”

Exemplo:

++ERROR

📌 O SMP/E não bloqueia automaticamente, mas alerta o sysprog de que aquele PTF tem problema conhecido.

💡 Dica de ouro:
Nunca ignore um ++ERROR sem ler a documentação da APAR correspondente.

---

🔐 Outros statements famosos (e perigosos)

• ++HOLD → segura o APPLY/ACCEPT automático

• ++WAIT → depende de outro SYSMOD

• ++IF / ++IN → controle condicional

• ++VER → garante compatibilidade de versão

👉 SMP/E é rigoroso porque produção não aceita improviso.

---

🔄 O Fluxo SMP/E (o caminho da sabedoria)

1️⃣ RECEIVE
👉 Introduz o SYSMOD no SMP/E (CSI)

2️⃣ APPLY
👉 Aplica no Target Libraries (executável)

3️⃣ ACCEPT
👉 Atualiza o DLIB (baseline oficial)

📌 Regra de ouro:

Nada vai para produção sem passar por APPLY e ACCEPT.

---

📦 DLIB vs TARGET (o erro clássico dos iniciantes)

• DLIB

  • Biblioteca de referência

  • Fonte “oficial”

  • Não executável

• TARGET

  • Onde o sistema realmente roda

  • Código executável

❌ Erro comum:

“Apliquei no DLIB achando que estava em produção.”

---

🧪 Exemplos práticos (vida real)

• Instalar um PTF de segurança

• Aplicar correção crítica de JES2

• Avaliar impacto de um ++HOLD

• Recuar uma manutenção problemática

👉 SMP/E não é só instalar, é governar mudanças.

---

🎓 Como aprender SMP/E de verdade

📚 Teoria

• IBM Knowledge Center

• Redbooks de SMP/E

• APARs reais (leitura obrigatória!)

🧪 Prática

• SMP/E for z/OS Workshop

• Ambientes de laboratório

• CSI de teste

• APPLY CHECK antes de tudo

💡 Dica Bellacosa:

“Quem só lê manual não vira sysprog. Quem só pratica sem teoria vira bombeiro.”

---

🛠️ SMP/E for z/OS Workshop

O Workshop de SMP/E para z/OS é onde a mágica acontece:

• Criação de CSI

• RECEIVE/APPLY/ACCEPT reais

• Análise de HOLDS e ERRORS

• Resolução de conflitos

• Simulação de falhas

👉 É aqui que o SMP/E deixa de ser teoria e vira ferramenta de sobrevivência.

---

🧠 Curiosidades

• SMP/E já fazia dependency management antes do Maven existir

• Já tinha rollback antes do Git

• Continua sendo 100% obrigatório em ambientes regulados

• Ignorar SMP/E é pedir outage

---

🧾 Comentário final (estilo Bellacosa)

SMP/E não é opcional.
SMP/E não é simples.
SMP/E não perdoa.

Mas quem domina o SMP/E:

• Ganha respeito

• Evita madrugada em produção

• Vira referência técnica

💾🔥

O Beijo do Enigma em uma visão paulistana

 

O Beijo do Enigma  

Houve um tempo em que o mundo cabia dentro de um teatro.
Chamava-se Enigma, e era mais que um lugar — era um refúgio.
Entre cortinas vermelhas e risadas de juventude, encontrei Patrícia.
A musa que não pedi, mas que o destino insistiu em colocar no meu caminho.

Ela chegou como se o universo tivesse dado “play” em uma nova trilha sonora.
Aos treze, não sabia o que era o amor — só o senti.
Ela se tornou o meu norte, meu referencial, meu verso inacabado.
O beijo dela... ah, aquele beijo… ainda vive em mim,
como se o tempo tivesse parado só para assistir.

Depois vieram os anos — implacáveis, mudos, necessários.
Nos tornamos memórias ambulantes um do outro:
primeiro namorados, depois amigos, depois ecos.
E no fim, apenas conhecidos.
Mas a alma reconhece o que o tempo finge esquecer.

Reconstruí o rosto dela com IA — como quem tenta conversar com o passado.
E quando vi, senti a velha vertigem:
a nostalgia que abraça…
e o “e se” que fere com doçura.

Alguns lugares guardam marcas que ninguém mais vê.
A Avenida Tiradentes, o Shopping Paraíso,
os encontros com Amélia, os caminhos pelo Parque do Ibirapuera —
São Paulo inteira respira Patrícia em cada sombra, em cada riso antigo.

Cresci nesta cidade, me tornei quem sou aqui,
e certos amores, mesmo distantes,
se tornam parte da paisagem da alma.

☕ IBM MQ – State-of-the-art Resilience

 

Bellacosa Mainframe apresenta o IBM MQ

☕ IBM MQ – State-of-the-art Resilience

Alta disponibilidade não é luxo. É sobrevivência. (e o mainframe sempre soube disso)

Vamos começar pelo óbvio — aquele óbvio que só dói quando falha.
Se o e-commerce cai, você fica irritado.
Se o banco cai, o país inteiro sente.
Se logística, pagamentos ou supply chain param… bem-vindo ao caos operacional, manchetes negativas e reuniões “quentes” com o board.

👉 Resiliência hoje não é diferencial técnico. É requisito de negócio.

E é exatamente aqui que o IBM MQ entra em modo mainframe mindset:

falhar pode até acontecer — parar, não.

---

🧠 Um pouco de história (porque nada nasce ontem)

Mensageria sempre foi o “sistema nervoso” das arquiteturas corporativas.
No mainframe, isso já era verdade quando REST ainda era só uma palavra em inglês comum.

O IBM MQ (ex-WebSphere MQ, para os old school 😏) nasceu com um princípio simples e poderoso:

mensagem persistente não se perde. ponto.

Enquanto o mundo distribuído moderno corre atrás de eventual consistency, o MQ sempre jogou no modo consistência forte + durabilidade.

E agora, com Native High Availability (NHA) e Cross Region Replication (CRR), ele elevou esse jogo para o nível cloud + geo + compliance.

---

🧱 Native High Availability (NHA)

Alta disponibilidade… sem gambiarra externa

Vamos direto ao ponto:
NHA é alta disponibilidade nativa, de verdade.

Nada de:

• storage replicado caríssimo 💸

• drivers de kernel obscuros

• cluster manager de terceiros

• dependência de “caixinhas mágicas”

👉 O próprio IBM MQ resolve.

🔑 Como funciona?

• 3 nós (leader / followers)

• Baseado no algoritmo de consenso Raft (sim, o mesmo conceito usado em sistemas distribuídos sérios)

• Quórum síncrono:

  • mensagem só é confirmada quando escrita em pelo menos 2 nós

  • resultado? RPO = zero (nenhuma mensagem perdida)

📌 Easter egg técnico:

Se você viveu o mundo de DB2 Data Sharing, isso vai soar familiar. O conceito é diferente, mas a filosofia é a mesma: consistência acima de tudo.

⚡ Recuperação em segundos

Falhou um nó?

• detecção rápida

• eleição automática

• retomada quase imediata

Tudo isso:

• em VM

• bare metal

• containers (Kubernetes / OpenShift)

Sem reescrever arquitetura. Sem dor.

🔐 Segurança e operação

• Comunicação entre nós com TLS

• Atualizações rolling upgrade

• Sem downtime relevante

👉 Operacionalmente simples.
👉 Arquiteturalmente elegante.
👉 Auditor-friendly (alô, bancos e regulados 👀).

---

🌍 Cross Region Replication (CRR)

Quando o problema não é o servidor… é o mapa

Agora vamos falar de desastre de verdade:
região inteira fora do ar.
datacenter indisponível.
zona geográfica comprometida.

É aqui que entra o CRR.

---

🎯 Objetivo do CRR

Garantir resiliência geográfica com:

• alta performance

• baixo impacto de latência

• custo otimizado

Tudo isso sem replicação de disco tradicional.

---

📉 O problema das soluções antigas

Replicação baseada em storage:

• replica log + arquivos de fila

• duplica tráfego de rede

• snapshot de 15 minutos (ou pior)

• custo alto em cloud 🌩️

📌 Tradução Bellacosa:

você paga mais, replica mais dados… e ainda perde mensagens no meio do caminho.

---

🚀 O diferencial do CRR

O CRR faz algo muito mais inteligente:

• replica somente o que é necessário

• usa compressão eficiente

• protege o primário contra lentidão do remoto (latency protection)

• permite switchover planejado com RPO zero

👉 Mesmo sendo assíncrono, um planned switchover não perde nenhuma mensagem.

Isso é ouro puro para:

• DR corporativo

• auditorias

• testes reais de contingência

• ambientes regulados

---

🔄 Active / Active? Sim, senhor.

O CRR permite:

• alternar primário ↔ secundário

• ou até operar queue managers ativos em ambos os sites

📌 Easter egg arquitetural:

aqui o MQ começa a conversar de igual para igual com arquiteturas distribuídas modernas — só que sem abrir mão da confiabilidade “old school”.

---

🧾 Persistência: o detalhe que muda tudo

Lembrete importante (e muita gente esquece):

📝 IBM MQ sempre grava mensagens persistentes no log transacional.
Se a fila estoura memória ou precisa ir para disco:

• arquivos de fila garantem durabilidade

• recuperação consistente após falha

O CRR entende isso profundamente — por isso não replica disco bruto, mas sim o estado lógico necessário para reconstrução perfeita.

Resultado?

• menos tráfego

• menos custo

• mais controle

---

🧩 NHA + CRR = mentalidade mainframe no mundo cloud

Quando você junta:

• NHA (resiliência local, RPO zero, failover rápido)

• CRR (resiliência geográfica, DR real, switchover sem perda)

Você tem algo raro hoje em dia:

resiliência enterprise sem complexidade externa

Sem Frankenstein arquitetural.
Sem depender de “mais uma ferramenta”.
Sem sustos na madrugada.

---

☕ Comentário final (estilo Bellacosa)

O mercado redescobriu agora o que o mainframe sempre soube:

alta disponibilidade não é só estar no ar — é garantir integridade, consistência e previsibilidade quando tudo dá errado.

O IBM MQ, com NHA e CRR, mostra que:

• dá pra ser moderno

• distribuído

• cloud-ready

• sem abrir mão da confiabilidade raiz

No fim do dia, não é sobre tecnologia.
É sobre confiança.

E confiança…
👉 não se replica com snapshot de 15 minutos.