✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
...e outro atualizar a Conta B alguns segundos depois...
Durante esses segundos:
Conta A = 100
Conta B = 0
O dinheiro "sumiu".
Ou pior...
Uma nova consulta pode permitir outra transferência.
Resultado:
Saldo negativo.
Quando Eventual Consistency funciona
Excelente para:
Feed do Instagram
Likes
Comentários
Catálogo de produtos
Estatísticas
Alguns segundos de atraso não importam.
Quando NÃO funciona
Nunca utilize em:
PIX
Bancos
Bolsa de Valores
Controle de Estoque
Reserva de assentos
Sistemas médicos
Nestes casos:
Strong Consistency
é obrigatória.
Mainframe
DB2 usa:
Commit
Rollback
Locking
Isolation Levels
Há décadas.
Muito antes da moda dos bancos NoSQL.
2. Não Definir Limites do Sistema
Este talvez seja o maior erro.
Imagine uma empresa.
Quem faz RH?
Quem faz Financeiro?
Quem faz Compras?
Agora imagine todos fazendo tudo.
É exatamente isso que acontece em sistemas mal divididos.
Sintoma
Um módulo chamado:
CustomerService
faz:
login
pagamento
envio de email
cadastro
estoque
geração de nota
relatórios
Virou um monólito.
Consequência
Qualquer alteração:
↓
quebra tudo.
Boa arquitetura
Cada domínio possui responsabilidade única.
Order Service
Inventory
Billing
Notification
Shipping
Cada um evolui sozinho.
Conceito
Domain Driven Design
Bounded Context
Single Responsibility
Todos nascem desse princípio.
3. Ignorar Latência
Usuários não medem CPU.
Eles medem tempo.
Exemplo
Pesquisa Google
300 ms
Parece instantânea.
Agora imagine:
4 segundos.
Você já fechou a página.
Latência acumulada
Cliente
↓
API Gateway
↓
Auth
↓
Inventory
↓
Recommendation
↓
Payment
↓
Shipping
↓
DB
Cada chamada adiciona:
20 ms
40 ms
80 ms
100 ms
...
No final:
1 segundo
Sem perceber.
Lei importante
Uma arquitetura com 20 microsserviços pode ser MAIS LENTA que um monólito.
Mainframe
Por isso CICS sempre priorizou:
poucas chamadas
processamento local
transações curtas
4. Subestimar a Carga
Outro erro clássico.
O sistema funciona perfeitamente...
...com 50 usuários.
Mas na Black Friday:
200 mil usuários
Tudo trava.
Perguntas importantes
Quantos usuários?
Quantas requisições?
Picos?
Sazonalidade?
Crescimento anual?
Capacidade
Sempre calcule:
Requests/second
Transactions/minute
IOPS
CPU
RAM
Storage
Network
Exemplo
Sistema:
1000 req/s
Promoção:
15000 req/s
Resultado:
Timeout.
Fila.
Erro 500.
5. Fazer Tudo Sincronamente
Imagine um e-commerce.
Cliente compra.
Sistema:
↓
processa pagamento
↓
envia email
↓
gera nota
↓
atualiza estoque
↓
gera cashback
↓
envia SMS
↓
atualiza BI
Tudo esperando.
O usuário fica olhando.
Melhor abordagem
Pagamento
↓
Resposta imediata
↓
Eventos
↓
Email
↓
Nota
↓
BI
↓
Analytics
↓
Machine Learning
Tudo assíncrono.
Tecnologias
Kafka
RabbitMQ
IBM MQ
SQS
Azure Service Bus
Pulsar
Benefícios
Escalabilidade
Baixa latência
Maior throughput
Resiliência
6. Não Planejar Evolução
Todo sistema muda.
Sempre.
Hoje:
Pix
Amanhã:
Pix Parcelado
Depois:
Pix Internacional
Depois:
IA financeira
Se sua arquitetura não suporta mudança...
Ela morre.
Arquitetura deve ser extensível
Open/Closed Principle
Plug-ins
Feature Flags
Configuration Driven
Interfaces
Strategy Pattern
7. Criar Pontos Únicos de Falha (Single Point of Failure)
Imagine:
1 servidor
↓
Banco
↓
Toda empresa
Servidor cai.
Empresa para.
Alta disponibilidade
Sempre pense em:
Load Balancer
Cluster
Replica
Failover
Geo-redundância
Backup
Mainframe
Sysplex
Parallel Sysplex
GDPS
foram criados exatamente para isso.
8. APIs Mal Projetadas
API é um contrato.
Contrato ruim gera caos.
Exemplo ruim
GET /data
Retorna:
qualquer coisa...
Exemplo melhor
GET /customers/{id}
Resposta consistente.
Documentada.
Versionada.
API deve possuir
Versionamento
Idempotência
Paginação
Rate Limit
Autenticação
Observabilidade
Documentação
9. Ignorar Backup e Recuperação
A pergunta não é:
"Meu sistema vai falhar?"
A pergunta correta é:
"Quando ele vai falhar?"
Recovery é parte da arquitetura
Backup
Snapshot
Point-in-Time Recovery
Replication
Disaster Recovery
Multi Region
Chaos Engineering
Conceitos fundamentais
RPO (Recovery Point Objective)
Quanto de dados você pode perder?
0 minutos
5 minutos
1 hora
RTO (Recovery Time Objective)
Quanto tempo o sistema pode ficar indisponível?
30 segundos
5 minutos
2 horas
Essas metas orientam a escolha da estratégia de backup e recuperação.
Um Décimo Erro que Poucos Mencionam: Falta de Observabilidade
Mesmo uma boa arquitetura pode fracassar se você não consegue enxergar o que acontece em produção.
Os três pilares da observabilidade são:
Logs: registram eventos e erros.
Métricas: mostram CPU, memória, latência, throughput e disponibilidade.
Traces distribuídos: acompanham uma requisição passando por vários serviços.
Ferramentas como Prometheus, Grafana, OpenTelemetry, Jaeger e Elastic Stack ajudam a identificar gargalos antes que eles se transformem em incidentes graves.
Um Décimo Primeiro Erro: Esquecer a Segurança Desde o Início
Segurança não deve ser um complemento adicionado ao final do projeto.
Uma arquitetura moderna precisa considerar desde o início:
Princípio do menor privilégio (Least Privilege)
Autenticação e autorização robustas
Criptografia em trânsito (TLS) e em repouso
Gestão de segredos
Auditoria e rastreabilidade
Proteção contra ataques como SQL Injection, XSS e CSRF
Rate limiting e proteção contra abuso
No ecossistema IBM Z, RACF, TLS, criptografia por hardware e auditoria integrada são exemplos de recursos que incorporam esses princípios há décadas.
O Que Todo Programador COBOL Padawan Deve Aprender
Uma lição importante é que System Design não é exclusivo de microsserviços ou da nuvem. Os princípios fundamentais são universais:
Modelar corretamente o domínio do negócio.
Entender os requisitos funcionais e não funcionais.
Projetar para disponibilidade, escalabilidade e recuperação.
Definir responsabilidades claras entre componentes.
Reduzir acoplamento e aumentar coesão.
Tratar desempenho, segurança e observabilidade como requisitos de primeira classe.
Os grandes sistemas corporativos escritos em COBOL, CICS, IMS e DB2 continuam processando bilhões de transações diariamente porque foram construídos com esses princípios. A tecnologia evolui, mas os fundamentos da boa arquitetura permanecem os mesmos. Um arquiteto experiente não é aquele que conhece mais ferramentas, e sim aquele que consegue prever os problemas antes que eles aconteçam e projetar sistemas preparados para enfrentá-los.
Bellacosa Mainframe apresenta ibm mainframe capitulo iii
☕ Um Café no Bellacosa Mainframe
Capítulo III — A Nave Que Se Recusa a Explodir
Alta Disponibilidade: Como o IBM Z Aprendeu a Desafiar o Caos
PRIMEIRA REGRA DAS GRANDES VIAGENS ESPACIAIS
Nunca pergunte:
"Qual é o computador mais rápido da galáxia?"
Pergunte:
"Qual ainda estará funcionando quando todos os outros estiverem reiniciando?"
Essa pequena diferença separa brinquedos tecnológicos de infraestrutura crítica.
Hoje vamos entrar na sala de máquinas do IBM Z.
Não espere lasers.
Nem motores de dobra.
Nem explosões cinematográficas.
Porque, curiosamente, a característica mais espetacular desta nave é justamente...
não explodir.
O Universo Ama o Caos
Existe uma lei universal.
Tudo falha.
Mais cedo ou mais tarde.
HDs falham.
Memórias falham.
Processadores falham.
Fontes queimam.
Cabos rompem.
Operadores digitam comandos errados.
Programadores esquecem um IF.
Analistas fazem deploy sexta-feira às 18h.
O universo simplesmente adora testar sistemas.
A verdadeira pergunta nunca foi:
"Vai acontecer?"
A pergunta correta é:
"Quando acontecer... o que sua arquitetura fará?"
É aqui que o IBM Z começa a parecer uma nave construída por engenheiros extremamente desconfiados.
O Clube dos Cinco Noves
Imagine um comandante perguntando:
— Quanto tempo nossa nave pode ficar parada?
Alguém responde:
Cinco minutos.
Por dia?
Não.
Por semana?
Também não.
Por mês?
Ainda não.
Por ano.
Essa é a obsessão conhecida como:
99,999% de disponibilidade.
Spruth destaca que uma configuração de grande porte do System z busca disponibilidade da ordem de 99,999%, o equivalente a poucos minutos de indisponibilidade ao longo de um ano, resultado da combinação de centenas ou milhares de mecanismos de engenharia trabalhando juntos.
O Grande Equívoco
Muita gente acredita existir um botão secreto chamado:
"Alta Disponibilidade"
Não existe.
Disponibilidade não é um recurso.
É uma consequência.
Ela nasce da soma de milhares de pequenas decisões.
É como construir uma nave.
Você não pergunta:
"O que faz a nave voar?"
Você pergunta:
motores funcionam?
combustível está protegido?
sensores possuem redundância?
portas possuem trava?
comunicação possui backup?
Cada pequeno detalhe aumenta as chances de voltar para casa.
Engenharia da Desconfiança
Existe uma filosofia invisível no IBM Z.
Ela diz:
Nunca confie que uma peça continuará funcionando.
Isso parece pessimista.
Na verdade...
é maturidade.
Enquanto muitas arquiteturas assumem que tudo continuará funcionando...
o Mainframe parte da hipótese oposta.
Alguma coisa vai quebrar.
Então...
vamos nos preparar antes.
Redundância Não É Desperdício
Imagine uma nave interestelar.
Ela possui:
dois motores.
Duas fontes.
Dois computadores.
Dois radares.
Dois sistemas elétricos.
Alguém pergunta:
— Não seria mais barato construir apenas um?
Seria.
Até o primeiro defeito.
O IBM Z foi projetado exatamente com essa mentalidade.
Se algo falhar...
outra parte assume.
Antes mesmo que alguém perceba.
A Recovery Unit: O Médico da Nave
Chegamos a um dos componentes mais fascinantes do relatório.
Pouca gente fora do universo mainframe conhece sua existência.
Ela se chama:
Recovery Unit.
Imagine um médico que acompanha cada tripulante da nave.
A cada segundo ele anota:
posição
sinais vitais
estado físico
última ação realizada
Se acontecer um acidente...
ele sabe exatamente como restaurar aquele momento.
É isso que a Recovery Unit faz.
Ela mantém uma cópia protegida do estado interno do processador.
Registradores.
Estado das instruções.
Contexto completo.
Caso ocorra um erro interno...
o processador simplesmente volta alguns instantes e tenta novamente.
Como se nada tivesse acontecido.
Segundo Spruth, a Recovery Unit armazena uma cópia protegida por ECC do estado do processador, permitindo repetição precisa de instruções, recuperação transparente e até substituição dinâmica de núcleos defeituosos.
Imagine Voltar Cinco Segundos no Tempo
Você derruba café sobre o teclado.
Seria maravilhoso voltar cinco segundos no tempo.
O IBM Z faz algo semelhante.
Não com café.
Com instruções.
Ele consegue repetir operações que sofreram interferência por falhas transitórias.
Isso evita interrupções completamente desnecessárias.
Trinta Mil Vigilantes
O relatório apresenta um dado impressionante.
Cada chip possui mais de:
20.000 verificadores internos.
Pense nisso.
Não são vinte mil processadores.
São vinte mil fiscais.
Eles observam continuamente:
sinais elétricos
fluxo de dados
registradores
memória
barramentos
Caso percebam qualquer anomalia...
acionam mecanismos automáticos de recuperação.
Spruth estima ainda que cerca de 30% a 40% dos transistores do chip sejam dedicados exclusivamente a verificação e recuperação de erros.
O Universo Está Cheio de Raios Cósmicos
Pode parecer ficção científica.
Mas não é.
Partículas vindas do espaço atingem constantemente componentes eletrônicos.
Às vezes alteram um único bit.
Um.
Parece insignificante.
Até esse bit representar:
saldo bancário.
senha.
ponteiro.
endereço de memória.
Por isso existe:
ECC.
ECC: O Bibliotecário Galáctico
Imagine uma gigantesca biblioteca.
Um visitante altera discretamente uma letra em um livro.
O bibliotecário percebe imediatamente.
Não apenas identifica o erro.
Ele o corrige.
Isso é exatamente o que faz o ECC.
Error Correcting Code.
Ele detecta alterações.
Corrige automaticamente.
Sem interromper o trabalho.
Memory Scrubbing: O Robô Faxineiro
Outro capítulo fascinante.
Imagine uma estação espacial durante a madrugada.
Enquanto todos dormem...
pequenos robôs percorrem corredores.
Apertam parafusos.
Trocam lâmpadas.
Lubrificam portas.
Corrigem pequenos defeitos antes que alguém acorde.
O Memory Scrubbing faz exatamente isso.
Enquanto parte da memória está ociosa...
o hardware a verifica.
Lê.
Confere.
Corrige.
Grava novamente.
Tudo automaticamente.
Segundo o relatório, essa técnica impede o acúmulo de erros "silenciosos" ao longo do tempo.
Smart Memory
Cada palavra armazenada possui mecanismos adicionais de proteção.
Se um chip apresentar defeito permanente...
outro assume seu lugar.
Sem drama.
Sem manchetes.
Sem reunião de crise.
A maioria dos usuários jamais perceberá.
O Support Element: O Centro de Comando
Agora imagine que nossa nave possui um computador dedicado apenas a observar.
Ele não executa aplicações.
Ele supervisiona.
Inicializa o sistema.
Carrega microcódigo.
Monitora temperatura.
Energia.
Ventilação.
Fontes.
Processadores.
Memória.
Tudo.
Esse é o Support Element.
Ele conversa continuamente com a Hardware Management Console (HMC) e pode encaminhar diagnósticos automaticamente para o suporte técnico da IBM, permitindo intervenções rápidas quando necessário.
O Médico Chega Antes da Dor
Existe uma história muito famosa entre administradores IBM.
Às vezes...
o técnico da IBM chegava ao cliente antes que o administrador percebesse o defeito.
Parece exagero.
Mas o Support Element já coletava diagnósticos continuamente.
Em muitos casos a análise começava antes da falha se tornar crítica.
Hoje chamaríamos isso de:
Observabilidade.
Telemetria.
Manutenção preditiva.
O Sistema Aprende
Outro conceito extraordinário apresentado por Spruth é o Predictive Failure Analysis (PFA).
Imagine uma inteligência responsável por observar padrões.
Ela percebe:
"Esse comportamento não costuma acontecer."
Nada quebrou.
Ainda.
Mas algo está diferente.
O PFA procura justamente identificar esses comportamentos anormais antes que eles provoquem uma indisponibilidade, ajudando o sistema a agir preventivamente.
ARM: O Paramédico Digital
Suponha que um subsistema pare de funcionar.
Em muitos ambientes alguém precisa:
abrir chamado.
entrar no servidor.
reiniciar manualmente.
No z/OS existe o:
Automatic Restart Manager.
Ele tenta restaurar automaticamente componentes que falharam.
Quanto menos intervenção humana...
menor o tempo de indisponibilidade.
O Desastre Também Foi Planejado
Imagine que um meteoro destrói metade da colônia.
Fim da missão?
Não necessariamente.
O relatório apresenta o GDPS (Geographically Dispersed Parallel Sysplex), solução voltada para recuperação de desastres e continuidade dos negócios em ambientes distribuídos geograficamente. Ela coordena sistemas e dados para permitir retomada rápida mesmo diante de eventos graves.
É como manter uma segunda base espacial pronta para assumir a operação caso a primeira fique indisponível.
O Segredo Não Está em Não Falhar
Talvez esta seja a maior lição deste capítulo.
Grandes engenheiros nunca acreditaram que poderiam eliminar todas as falhas.
Isso seria arrogância.
Eles fizeram algo muito mais inteligente.
Construíram sistemas capazes de sobreviver a elas.
Essa é uma filosofia profundamente diferente.
O Que Mudou Desde 2010?
Desde que Spruth escreveu este relatório, a IBM ampliou ainda mais essa abordagem:
mecanismos mais sofisticados de análise preditiva;
firmware continuamente atualizado;
processadores Telum e Spyre com recursos adicionais de confiabilidade;
integração com IA para observabilidade;
automação avançada de recuperação;
monitoramento contínuo em ambientes híbridos.
O princípio, porém, continua exatamente o mesmo:
detectar cedo, isolar rapidamente, recuperar automaticamente e manter o serviço disponível.
Curiosidades do Diário de Bordo
🚀 O IBM Z não busca apenas corrigir erros; ele procura impedir que muitos deles cheguem a afetar aplicações.
🛠️ Uma parcela significativa da complexidade do hardware existe apenas para verificar se o próprio hardware continua funcionando corretamente.
🌌 Técnicas como ECC, Memory Scrubbing e análise preditiva mostram que confiabilidade não depende de um único componente extraordinário, mas da cooperação de milhares de mecanismos discretos.
📡 Em engenharia de sistemas críticos, a verdadeira inovação muitas vezes é invisível para o usuário final — justamente porque evita que problemas se transformem em interrupções.
Diário de Bordo do Padawan COBOL
Antes de sair da sala de máquinas, registre estas coordenadas:
✅ Todo hardware falha; a diferença está em como a arquitetura reage à falha.
✅ Alta disponibilidade não nasce de um único recurso, mas da soma de centenas de mecanismos trabalhando em conjunto.
✅ O IBM Z foi projetado para continuar operando mesmo quando partes dele apresentam defeitos.
✅ A melhor recuperação é aquela que acontece antes mesmo que o usuário perceba que existiu um problema.
No próximo capítulo atravessaremos um dos setores mais protegidos da nave: o sistema de segurança do IBM Z. Descobriremos por que essa arquitetura trata memória, criptografia, autorização e isolamento como se cada byte fosse um artefato precioso de uma civilização galáctica.
☕ Um Café no Bellacosa Mainframe
O Guia Galáctico do IBM Z
Dezoito capítulos e uma conclusão reunidos em um painel interativo. Escolha uma missão, abra no visor e continue explorando diretamente no artigo original.
Não entre em pânico: se o Blogger impedir a exibição dentro do iframe, use “Abrir artigo”. Os links diretos continuam visíveis para leitores e motores de busca.
