Git, GitHub e DevOps para Profissionais IBM Z Por que COBOL Developers, Sysprogs e Sysadmins precisam dominar Git em 2026

 

Bellacosa Mainframe e o Git Github e DevOps para Mainframers

☕🚀 Um Café no Bellacosa Mainframe

Git, GitHub e DevOps para Profissionais IBM Z

Por que COBOL Developers, Sysprogs e Sysadmins precisam dominar Git em 2026

"Deleted your code by mistake? Without Git, it's gone forever."

Confesso que, ao observar aqueles infográficos coloridos sobre Git e DevOps, senti algo curioso.

Em poucos segundos eles conseguiram condensar uma transformação tecnológica que levou quase quarenta anos para acontecer.

Para muitos jovens desenvolvedores, Git sempre existiu.

Para nós, veteranos do Mainframe, sabemos que não foi assim.

Nós vivemos outra realidade.

Vivemos a era dos datasets PDS.

Vivemos a era dos backups manuais.

Vivemos a era do Panvalet.

Do Librarian.

Do Endevor.

Do Changeman.

Do SCLM.

Do ISPW.

Do membro COBOL001.

Do COBOL001.BKP.

Do COBOL001.OLD.

Do COBOL001.TESTE.

Do COBOL001.NOVO.

Do COBOL001.NOVO2.

Do COBOL001.NOVO3.

E, inevitavelmente, do lendário:

COBOL001.FINAL

COBOL001.FINAL2

COBOL001.FINAL_DEFINITIVO

COBOL001.FINAL_DEFINITIVO_OK

COBOL001.AGORA_VAI

Parece piada.

Mas muitos de nós trabalhamos exatamente dessa maneira.

E foi justamente para resolver esse caos que surgiu uma das ferramentas mais importantes da história da Engenharia de Software.

Git.

E não estou exagerando.

Git talvez seja tão revolucionário para o desenvolvimento moderno quanto o JES2 foi para processamento batch, quanto o CICS foi para processamento online ou quanto o DB2 foi para persistência transacional.

Git mudou a maneira como produzimos software.

Bellacosa Mainframe e a evolucao da gestao dos fontes

A primeira geração do controle de versões

Antes do Git existiam várias abordagens.

RCS.

SCCS.

CVS.

Visual SourceSafe.

Subversion.

ClearCase.

Perforce.

Cada um tentou resolver o mesmo problema.

Como permitir que múltiplas pessoas trabalhem no mesmo código sem destruir o trabalho umas das outras?

No Mainframe, resolvemos isso de forma diferente.

Panvalet.

Librarian.

Endevor.

ISPW.

Changeman.

Essas ferramentas foram brilhantes.

E continuam sendo.

Especialmente em ambientes regulados.

Bancos.

Seguradoras.

Governo.

Utilities.

Mas havia uma diferença.

Grande parte delas era centralizada.

Tudo dependia de um servidor.

Git mudou isso.

Git é distribuído.

E isso altera completamente a arquitetura do desenvolvimento.

O que realmente é Git?

A maioria dos cursos ensina:

Git é um sistema de versionamento.

Tecnicamente está correto.

Mas é uma definição pobre.

Git é muito mais.

Git é um banco de dados.

Git é uma máquina do tempo.

Git é um mecanismo de auditoria.

Git é uma ferramenta de colaboração.

Git é um sistema de rastreabilidade.

Git é um gatilho para automação.

Git é praticamente o sistema nervoso central do DevOps moderno.

Cada commit registra:

Quem alterou.

Quando alterou.

Por que alterou.

Qual requisito atendeu.

Qual incidente corrigiu.

Qual sprint participou.

Qual história de usuário foi implementada.

Qual vulnerabilidade foi mitigada.

Git não apenas salva arquivos.

Git preserva conhecimento organizacional.

O segredo escondido do Git

Poucos profissionais conhecem sua arquitetura interna.

Git não armazena arquivos.

Git armazena objetos.

Blob.

Tree.

Commit.

Tag.

Blob representa dados.

Tree representa diretórios.

Commit representa estados.

Tag representa marcos.

Cada commit possui um hash.

Durante muitos anos SHA-1.

Hoje caminhando para SHA-256.

Um commit não é uma diferença.

Ele é uma fotografia completa.

Um snapshot.

É por isso que Git consegue voltar meses no passado.

Como um SMF para código-fonte.

Aliás...

Talvez essa seja a analogia perfeita para um sysprog.

Git é quase um SMF de desenvolvimento.

Cada alteração gera um registro permanente.

O Sysprog e o Git

Talvez alguns sysprogs pensem:

"Mas Git é coisa de desenvolvedor."

Não.

Não mais.

Hoje praticamente toda infraestrutura está migrando para Infrastructure as Code.

Parmlibs.

Policies.

WLM.

NetView.

SA z/OS.

Ansible.

Terraform.

Scripts REXX.

Procedures.

JCL.

USS scripts.

Tudo pode estar em Git.

Imagine uma alteração em uma política WLM.

Antigamente:

Editar.

Salvar.

Copiar.

Torcer.

Hoje:

Criar branch.

Modificar.

Commit.

PR.

Review.

Merge.

Deploy automatizado.

Rollback imediato.

A governança melhora absurdamente.

O Sysadmin moderno também virou desenvolvedor

Existe uma transformação interessante acontecendo.

Sysadmins estão programando.

Desenvolvedores estão automatizando infraestrutura.

DBAs escrevem pipelines.

Sysprogs utilizam APIs REST.

Todos começam a convergir.

A linha entre operações e desenvolvimento desaparece.

Foi exatamente isso que criou DevOps.

DevOps não é ferramenta

Essa talvez seja a maior confusão do mercado.

DevOps não é Jenkins.

Não é GitHub.

Não é Kubernetes.

Não é Docker.

Não é Ansible.

DevOps é cultura.

É reduzir silos.

Eliminar burocracias.

Aproximar pessoas.

Automatizar processos.

Aumentar feedback.

Reduzir tempo de entrega.

No Mainframe isso é extremamente relevante.

Porque o Mainframe sempre teve uma cultura muito compartimentalizada.

Equipe COBOL.

Equipe DB2.

Equipe CICS.

Equipe Storage.

Equipe RACF.

Equipe Sysprog.

Equipe Operações.

Equipe Middleware.

Equipe Rede.

Equipe Segurança.

DevOps propõe outra visão.

Todos trabalham pelo mesmo objetivo.

Entregar valor ao negócio.

GitHub não é Git

Muitos iniciantes confundem.

Git é tecnologia.

GitHub é plataforma.

GitLab é plataforma.

Bitbucket é plataforma.

Azure DevOps é plataforma.

Git continua sendo Git.

Independentemente da hospedagem.

GitHub adicionou uma camada extremamente poderosa.

Issues.

Actions.

Codespaces.

Security.

Dependabot.

Packages.

Container Registry.

Wiki.

Pull Requests.

Tudo integrado.

Pull Request: a maior revolução social do desenvolvimento

Eu particularmente considero Pull Request uma das melhores invenções da engenharia moderna.

Porque ela resolve algo difícil.

Compartilhar conhecimento.

Imagine um desenvolvedor COBOL júnior.

Ele escreve:

MOVE WS-CPF TO WS-TEMP

Um desenvolvedor sênior comenta:

"Poderíamos validar antes."

Outro comenta:

"Talvez usar EVALUATE seja melhor."

Outro:

"Precisamos mascarar LGPD."

Resultado?

O código melhora.

O profissional melhora.

A equipe melhora.

A empresa melhora.

PR é mentoria embutida.

O medo do merge conflict

Todo desenvolvedor já sentiu frio na barriga.

git pull

CONFLICT

Automatic merge failed.

Para iniciantes parece um desastre.

Para equipes maduras é rotina.

Conflitos indicam colaboração.

Duas pessoas trabalharam na mesma área.

Git apenas pede ajuda.

Ele não consegue decidir sozinho.

Você decide.

Git apenas documenta.

Git Flow versus GitHub Flow

Durante anos utilizamos Git Flow.

Main.

Develop.

Feature.

Release.

Hotfix.

Funciona muito bem.

Especialmente em bancos.

Porém empresas modernas começaram simplificar.

GitHub Flow.

Main.

Feature.

PR.

Merge.

Deploy.

Google foi além.

Trunk Based Development.

Branches curtíssimas.

Commits pequenos.

Integração contínua.

Menos divergência.

Menos conflitos.

Mais velocidade.

Git para COBOL Developers

Aqui entramos em um ponto fascinante.

Durante muito tempo dizia-se:

COBOL não combina com Git.

Hoje isso é completamente falso.

IBM DBB.

IBM Dependency Based Build.

zAppBuild.

Z Open Editor.

Rocket Git.

Git Integration for Endevor.

ISPW Git Integration.

IDz.

Wazi Developer.

VS Code.

Tudo isso mudou o cenário.

Hoje um desenvolvedor COBOL pode trabalhar assim.

Abrir VS Code.

Editar programa COBOL.

Executar testes.

Commit.

Push.

Criar PR.

Executar pipeline.

Compilar.

Linkedit.

DB2 Bind.

Newcopy CICS.

Deploy.

Exatamente como Java.

Exatamente como Python.

Exatamente como Node.

Jenkins: o operador automático

Se Git é o cérebro.

Jenkins é o operador.

Ele observa commits.

Dispara builds.

Executa testes.

Compila COBOL.

Gera relatórios.

Aciona SonarQube.

Publica artefatos.

Executa deploy.

Notifica equipes.

No fundo, Jenkins faz o papel que muitos operadores humanos executavam.

Só que 24 horas por dia.

Sem esquecer etapas.

Sem distrações.

GitOps: talvez a próxima revolução

GitOps é simples.

Tudo é Git.

Deseja mudar um cluster Kubernetes?

Commit.

Deseja alterar firewall?

Commit.

Deseja atualizar pipeline?

Commit.

Deseja modificar política?

Commit.

Git torna-se a fonte única da verdade.

Single Source of Truth.

Isso é extremamente poderoso.

Porque elimina configurações manuais.

Elimina servidores "snowflake".

Elimina ambientes misteriosos.

Tudo fica reproduzível.

E a segurança?

Segurança também mudou.

DevSecOps nasceu justamente aqui.

SAST.

DAST.

Dependency Scan.

Secrets Detection.

SBOM.

Tudo integrado ao pipeline.

O desenvolvedor faz commit.

Ferramentas verificam.

Bibliotecas vulneráveis.

Credenciais expostas.

Falhas conhecidas.

Antes de chegar em produção.

No Mainframe isso pode incluir:

RACF reviews.

JCL analysis.

CICS security checks.

DB2 privilege validation.

SMF auditing.

O papel do Sysprog em 2026

Antigamente o Sysprog era apenas administrador.

Hoje é arquiteto.

Automatizador.

Consultor.

Especialista em APIs.

Especialista em observabilidade.

Especialista em pipelines.

Especialista em integração.

Especialista em segurança.

Sysprog moderno entende:

Git.

GitHub.

GitLab.

Ansible.

Python.

REXX.

Jenkins.

OpenShift.

Containers.

z/OSMF.

Zowe.

REST APIs.

Porque o Mainframe deixou de ser uma ilha.

Ele tornou-se parte do ecossistema corporativo.

O novo profissional IBM Z

Acredito que o profissional IBM Z de maior valor em 2026 possui uma característica interessante.

Ele pensa como um desenvolvedor.

Age como um administrador.

Automatiza como um engenheiro DevOps.

Protege como um especialista em segurança.

E governa como um arquiteto.

Ele consegue conversar com:

Desenvolvedor Java.

Equipe Cloud.

Kubernetes.

Segurança.

Storage.

Networking.

Data Science.

IA.

Sem abandonar aquilo que torna o Mainframe único.

Confiabilidade.

Escalabilidade.

Disponibilidade.

Integridade transacional.

Processamento massivo.

Pensando durante o café

Talvez a grande mensagem escondida por trás daqueles simpáticos desenhos coloridos seja esta:

Git não substitui o conhecimento Mainframe.

Git potencializa o conhecimento Mainframe.

Ele não aposenta COBOL.

Ele amplia o alcance do COBOL.

Ele não elimina o Sysprog.

Ele transforma o Sysprog em um engenheiro de plataforma.

Ele não mata operações.

Ele automatiza operações repetitivas.

A próxima geração de profissionais IBM Z provavelmente não conhecerá Panvalet.

Talvez nunca utilize Librarian.

Possivelmente jamais veja um Changeman clássico.

Mas certamente abrirá um Pull Request.

Criará uma branch.

Executará uma pipeline.

Fará deploy automatizado.

E continuará processando bilhões de transações por dia em um IBM Z.

Porque, no final das contas, o objetivo nunca foi Git.

Nunca foi GitHub.

Nunca foi Jenkins.

Nunca foi Kubernetes.

O objetivo sempre foi o mesmo desde os tempos do System/360.

Entregar software confiável.

Mais rápido.

Mais seguro.

Mais auditável.

Mais sustentável.

E, se possível, com uma boa xícara de café ao lado do teclado 3270.

 

Bellacosa Mainframe e a tecnica de cloud repatriation

☕🏠☁️ CLOUD REPATRIATION — QUANDO AS EMPRESAS DESCOBREM QUE NEM TUDO DEVERIA TER IDO PARA A NUVEM

Se você é uma Analista COBOL Júnior, provavelmente cresceu ouvindo uma frase que parecia uma verdade absoluta:

"O futuro está na nuvem."

Durante mais de uma década, empresas do mundo inteiro migraram aplicações, bancos de dados, sistemas corporativos e ambientes inteiros para AWS, Azure e Google Cloud.

As apresentações dos fornecedores mostravam um cenário quase perfeito.

Tudo seria:

• mais rápido;

• mais moderno;

• mais simples;

• mais seguro;

• mais barato.

Executivos ficaram encantados.

Arquitetos embarcaram na jornada.

Consultorias venderam projetos bilionários.

E milhares de empresas iniciaram aquilo que ficou conhecido como:

Cloud Migration.

Mas alguns anos depois algo inesperado começou a acontecer.

Empresas gigantes passaram a fazer o caminho inverso.

Sim.

O movimento contrário.

Retirar sistemas da nuvem.

Trazer aplicações de volta para datacenters próprios.

Mover cargas para ambientes especializados.

Consolidar plataformas.

Esse fenômeno ganhou um nome que talvez você escute cada vez mais nos próximos anos:

Cloud Repatriation.

Ou simplesmente:

Repatriação da Nuvem.

E para quem trabalha com Mainframe, COBOL e sistemas corporativos, entender esse conceito é fundamental.

Porque ele está mudando a forma como as empresas enxergam tecnologia.

---

O sonho da nuvem

Vamos voltar alguns anos.

Imagine uma empresa tradicional.

Ela possui:

• servidores físicos;

• storage;

• rede;

• datacenter;

• equipe de infraestrutura.

Tudo precisa ser comprado.

Tudo precisa ser instalado.

Tudo precisa ser mantido.

Quando a nuvem chegou, a promessa parecia revolucionária.

Ao invés de comprar:

• você alugaria.

Ao invés de esperar semanas:

• criaria recursos em minutos.

Ao invés de investir milhões:

• pagaria apenas pelo uso.

Parecia perfeito.

E para muitas situações realmente era.

---

O nascimento do "Cloud First"

Entre 2015 e 2022 surgiu uma expressão muito popular.

Cloud First.

Ou seja:

"A nuvem primeiro."

Toda nova solução deveria nascer em cloud.

Muitas organizações foram além.

Não apenas criaram sistemas novos.

Também migraram sistemas antigos.

Tudo virou candidato à nuvem.

ERP.

CRM.

Banco de dados.

Analytics.

Arquivos.

Aplicações críticas.

Em muitos casos sem uma análise profunda de custo-benefício.

---

A pergunta que ninguém fazia

Durante a fase de entusiasmo existia uma pergunta que poucos executivos faziam:

"Quanto isso custará daqui a cinco anos?"

A maioria analisava apenas:

• velocidade;

• facilidade;

• inovação.

Mas ignorava:

• crescimento;

• consumo;

• escalabilidade financeira.

A conta parecia pequena no início.

Mas crescia silenciosamente.

---

A armadilha do sucesso

Imagine uma fintech.

Primeiro ano:

100 mil clientes.

Segundo ano:

1 milhão.

Terceiro ano:

10 milhões.

Quarto ano:

50 milhões.

Tudo parece ótimo.

Mas existe um detalhe.

Cada cliente gera:

• armazenamento;

• processamento;

• logs;

• backups;

• monitoramento;

• tráfego de rede.

Quanto mais sucesso a empresa tem, maior fica a fatura.

O paradoxo é interessante.

O crescimento do negócio aumenta também o custo operacional da nuvem.

---

Quando chega a conta

É nesse momento que começa a repatriação.

Os diretores financeiros começam a fazer perguntas.

Por exemplo:

• Estamos usando tudo que pagamos?

• Precisamos realmente dessa configuração?

• Existe alternativa mais barata?

• O custo por transação está aumentando?

• O retorno continua justificando o investimento?

E muitas vezes a resposta é surpreendente.

Nem toda carga de trabalho se beneficia economicamente da nuvem.

---

A analogia da casa

Uma das formas mais simples de entender Cloud Repatriation é imaginar um imóvel.

No começo você mora de aluguel.

Faz sentido.

Você ainda está começando.

Precisa de flexibilidade.

Não quer investir muito.

Mas imagine que passaram vinte anos.

Você continua pagando aluguel.

Todo mês.

Sem parar.

Em algum momento surge a pergunta:

"Não seria melhor comprar?"

A repatriação nasce exatamente dessa reflexão.

---

O caso do Dropbox

Um dos exemplos mais famosos ocorreu com o Dropbox.

Durante anos a empresa utilizou cloud pública.

Mas conforme cresceu percebeu algo importante.

O volume de armazenamento era gigantesco.

A escala era enorme.

A previsibilidade era alta.

O resultado?

Passou a investir fortemente em infraestrutura própria.

A economia foi medida em centenas de milhões de dólares ao longo dos anos.

Isso chamou a atenção do mercado.

---

O caso da 37signals

Outro exemplo muito discutido foi a empresa por trás do Basecamp.

Após anos utilizando cloud pública, seus executivos anunciaram um movimento de retorno para infraestrutura própria.

O argumento principal?

Economia.

Segundo eles, a redução de custos seria enorme.

A notícia gerou debates em toda a indústria.

---

O que isso ensina para uma Analista COBOL?

Ensina algo extremamente importante.

Tecnologia não é religião.

Não existe:

• Mainframe bom.

• Cloud ruim.

Nem o contrário.

Existe apenas:

o ambiente correto para a carga correta.

Essa é uma das maiores lições da arquitetura moderna.

---

Nem toda carga é igual

Imagine duas aplicações.

Primeira aplicação:

• Website promocional.

• Acessos variáveis.

• Crescimento imprevisível.

Cloud faz sentido.

Agora imagine:

• processamento de contas bancárias;

• liquidação financeira;

• batch noturno;

• milhões de transações previsíveis.

Talvez a análise econômica seja diferente.

Talvez uma plataforma especializada seja mais eficiente.

Talvez um mainframe seja mais competitivo.

Tudo depende do contexto.

---

O papel do Mainframe nessa história

É aqui que muitos jovens profissionais ficam surpresos.

Durante anos ouviram que o Mainframe estava desaparecendo.

Mas a realidade mostrou algo curioso.

Enquanto algumas empresas tentavam migrar tudo para cloud, outras perceberam que certas cargas continuavam extremamente eficientes no IBM Z.

Por quê?

Porque o Mainframe foi construído justamente para:

• alta escala;

• alta disponibilidade;

• processamento transacional;

• confiabilidade extrema.

Essas características continuam valiosas.

Muito valiosas.

---

O custo invisível da nuvem

Uma Analista COBOL costuma enxergar claramente os custos de CPU e disco em ambientes tradicionais.

Na cloud surgem custos menos óbvios.

Por exemplo:

• transferência de dados;

• snapshots;

• logs;

• replicação;

• monitoramento;

• APIs;

• tráfego entre regiões.

Cada item parece pequeno.

Somados podem se tornar gigantescos.

É por isso que tantas empresas passaram a adotar práticas de FinOps.

---

O nascimento do FinOps

FinOps significa:

Financial Operations.

Ou seja:

Operações financeiras aplicadas à tecnologia.

Hoje muitas empresas possuem equipes inteiras dedicadas a responder perguntas como:

• Quem está consumindo recursos?

• Quanto custa cada aplicação?

• Qual é o custo por cliente?

• Qual é o custo por transação?

Isso praticamente não existia no início da corrida para a nuvem.

---

A verdade que ninguém gosta de ouvir

Existe uma verdade que incomoda muitos vendedores de tecnologia.

Nem toda inovação reduz custos.

Algumas aumentam custos.

Mas aumentam receita.

E isso pode ser perfeitamente aceitável.

Cloud frequentemente se encaixa nesse cenário.

A empresa paga mais.

Mas cresce mais rápido.

Lança produtos mais rapidamente.

Conquista clientes mais cedo.

Portanto o custo adicional pode valer a pena.

---

Então por que repatriar?

Porque chega um momento em que determinadas cargas se tornam:

• previsíveis;

• estáveis;

• maduras.

Nesse ponto a elasticidade da cloud perde parte do valor.

E a eficiência operacional começa a ganhar importância.

A pergunta muda.

Deixa de ser:

"Como crescer?"

E passa a ser:

"Como operar com eficiência?"

---

O futuro é híbrido

Talvez essa seja a maior conclusão.

O futuro não parece ser:

• tudo na cloud;

• tudo no mainframe;

• tudo on-premises.

O futuro parece híbrido.

Cada carga de trabalho executada no ambiente mais adequado.

É exatamente isso que vemos nos grandes bancos.

Itaú.

Bradesco.

Banco do Brasil.

Santander.

Caixa.

Todos operam ambientes mistos.

Cloud.

Linux.

Containers.

APIs.

Mainframe.

Tudo convivendo.

Tudo integrado.

---

O que você deve aprender como profissional

Se você está começando em COBOL, não caia na armadilha de pensar que sua carreira está presa ao passado.

Pelo contrário.

O mercado está procurando profissionais que entendam integração.

Profissionais que consigam conversar sobre:

• COBOL;

• APIs;

• Cloud;

• Mensageria;

• Kubernetes;

• IBM Z;

• Arquitetura distribuída.

Porque a verdadeira transformação digital não consiste em destruir o legado.

Consiste em conectá-lo ao futuro.

---

Conclusão: O Retorno da Maturidade Tecnológica

Cloud Repatriation não significa fracasso da nuvem.

Também não significa vitória do Mainframe.

Significa algo muito mais interessante.

Significa maturidade.

O mercado finalmente começou a entender que tecnologia não deve ser escolhida por moda.

Nem por marketing.

Nem por tendências.

Ela deve ser escolhida por critérios objetivos:

• custo;

• desempenho;

• segurança;

• disponibilidade;

• escalabilidade.

A nuvem continuará crescendo.

Os datacenters continuarão existindo.

Os mainframes continuarão processando bilhões de transações.

E as arquiteturas híbridas se tornarão cada vez mais comuns.

Para uma Analista COBOL Júnior, essa é uma excelente notícia.

Porque mostra que o conhecimento de sistemas corporativos continua extremamente relevante.

O profissional do futuro não será aquele que conhece apenas uma tecnologia.

Será aquele que entende quando usar cada uma delas.

E talvez essa seja a maior lição da Cloud Repatriation.

Às vezes a inovação não está em mover tudo para a nuvem.

Às vezes a inovação está em descobrir o que nunca deveria ter saído de casa.

Bellacosa Mainframe e historia da IBM em resumo

IBM 115 Anos: A Empresa que Ajudou a Construir o Mundo Digital

Uma viagem pela história, curiosidades, desafios e segredos da gigante que ainda move bilhões de transações por dia

16 de junho.

Para muitos, apenas mais um dia no calendário.

Para quem trabalha com Mainframe, COBOL, z/OS, CICS, DB2 e tecnologia corporativa, é uma data especial: o aniversário da IBM, uma das empresas mais influentes da história da humanidade.

Em 16 de junho de 1911 nasceu uma organização que sobreviveria a duas guerras mundiais, à Grande Depressão, à Guerra Fria, ao surgimento do computador pessoal, à internet, ao smartphone, à computação em nuvem e agora à Inteligência Artificial.

Poucas empresas conseguem permanecer relevantes durante cinco anos.

Algumas sobrevivem vinte.

Raríssimas chegam aos cinquenta.

A IBM chegou aos 115 anos.

E continua ajudando a processar boa parte do dinheiro que circula no planeta.

Para um Desenvolvedor COBOL Jr., compreender a história da IBM é entender a própria história da computação.

---

Bellacosa Mainframe e os 115 anos da IBM

Antes da IBM Existia um Problema

Imagine o mundo em 1890.

Não havia computadores.

Não havia bancos de dados.

Não havia internet.

Não havia sequer calculadoras eletrônicas.

Governos precisavam contar milhões de pessoas manualmente.

Empresas precisavam processar montanhas de documentos em papel.

Folhas de pagamento eram calculadas à mão.

Erros eram frequentes.

Processos demoravam meses.

Foi nesse cenário que apareceu Herman Hollerith.

---

O Homem que Criou o Conceito de Processamento de Dados

Herman Hollerith era um engenheiro americano que observou um problema gigantesco:

O censo dos Estados Unidos de 1880 demorou quase oito anos para ser concluído.

Se nada mudasse, o próximo censo demoraria mais do que o intervalo entre censos.

Era matematicamente impossível continuar daquele jeito.

Sua solução foi revolucionária.

Ele criou cartões perfurados capazes de armazenar informações.

Cada furo representava um dado.

Máquinas eletromecânicas liam esses cartões e realizavam contagens automaticamente.

Pela primeira vez na história, uma máquina processava dados em larga escala.

Nascia o conceito que décadas depois evoluiria para os computadores modernos.

---

O Verdadeiro Nascimento da IBM

Em 1911 várias empresas se fundiram para formar a:

Computing-Tabulating-Recording Company (CTR)

O nome era enorme.

Pouco elegante.

Pouco memorável.

Em 1924, Thomas J. Watson decidiu mudar tudo.

A empresa passou a se chamar:

International Business Machines

Ou simplesmente:

IBM

Uma mudança que parece simples, mas que carregava uma visão ousada.

Watson acreditava que as máquinas de processamento de dados teriam alcance mundial.

Na década de 1920 isso parecia exagero.

Hoje sabemos que ele estava certo.

---

O Primeiro Easter Egg da IBM

A famosa frase:

"THINK"

foi criada por Thomas Watson Sr.

Ela surgiu em uma reunião onde um executivo perguntou:

"Como resolveremos este problema?"

Watson respondeu:

"Think."

A palavra virou slogan oficial.

Décadas depois inspirou o nome do notebook ThinkPad.

Até hoje a cultura IBM incentiva seus profissionais a pensarem antes de agir.

Uma filosofia simples.

Mas extremamente poderosa.

---

A IBM e a Segunda Guerra Mundial

Durante os anos 1940 a IBM cresceu enormemente.

Suas máquinas de tabulação eram usadas para processar informações em velocidade inédita para a época.

A guerra acelerou a necessidade de automação.

Governos precisavam controlar:

• Estoques

• Logística

• Produção industrial

• Recursos militares

A IBM tornou-se referência mundial em processamento de informações.

Mas a verdadeira revolução ainda estava por vir.

---

O Computador Entra em Cena

Na década de 1950 o mundo testemunhou o nascimento dos computadores eletrônicos.

Grandes máquinas ocupavam salas inteiras.

Consumiam energia absurda.

Possuíam menos capacidade computacional que um relógio inteligente moderno.

Mesmo assim representavam um salto gigantesco.

A IBM rapidamente percebeu que o futuro estava nos computadores.

Surgiram máquinas históricas como:

IBM 650

IBM 701

IBM 704

IBM 7070

Cada uma delas ajudou a criar os alicerces da computação corporativa.

---

A Maior Aposta da História da Computação

Em 1964 a IBM tomou uma decisão considerada loucura por muitos analistas.

Ela investiu aproximadamente 5 bilhões de dólares no desenvolvimento de uma nova arquitetura.

A aposta recebeu um nome simples:

System/360

Hoje parece apenas mais um produto.

Na época foi uma revolução.

---

Bellacosa Mainframe e a evolução historica do logotipo IBM

Por Que o System/360 Mudou o Mundo?

Antes do System/360 cada computador era praticamente incompatível com os demais.

Trocar de equipamento significava reescrever programas.

Refazer processos.

Treinar equipes novamente.

A IBM propôs algo radical.

Uma família inteira de computadores compatíveis entre si.

O programa escrito para um modelo poderia funcionar em outro.

Esse conceito influenciou praticamente toda a indústria.

Windows.

Linux.

Unix.

Cloud.

Todos herdaram, direta ou indiretamente, ideias introduzidas pelo System/360.

---

O Nascimento do Mainframe Moderno

Quando um profissional fala em Mainframe hoje, está falando do descendente direto do System/360.

A linha evoluiu:

System/360

System/370

390

zSeries

System z

IBM Z

z16

z17

Existe uma linha evolutiva contínua de mais de sessenta anos.

Pouquíssimas tecnologias possuem essa continuidade.

---

Onde Entra o COBOL?

Em 1959 surgiu o COBOL.

Seu objetivo era simples:

Permitir que pessoas de negócios compreendessem programas.

Por isso comandos como:

ADD

SUBTRACT

MOVE

READ

WRITE

são tão próximos da linguagem humana.

A IBM adotou COBOL massivamente.

Bancos.

Seguradoras.

Governos.

Empresas aéreas.

Todos começaram a construir sistemas corporativos usando COBOL.

Muitos desses sistemas continuam funcionando até hoje.

---

O Grande Mito Sobre COBOL

Você provavelmente já ouviu:

"COBOL está morto."

Curiosamente essa frase existe desde os anos 1980.

Mas o COBOL continua processando:

• Folhas de pagamento

• Cartões de crédito

• PIX

• TED

• DOC

• Seguros

• Aposentadorias

• Impostos

Na prática, ele sobrevive porque resolve muito bem problemas de negócios.

Tecnologia não vence porque é nova.

Vence porque funciona.

---

A Curiosidade Que Surpreende Todo Iniciante

Muitos aplicativos modernos dependem de COBOL sem que seus usuários saibam.

Quando alguém usa:

• Aplicativo bancário

• Caixa eletrônico

• Portal de investimentos

• Sistema de previdência

Existe uma chance enorme de uma transação COBOL estar participando do processo.

O aplicativo bonito do smartphone frequentemente é apenas a ponta do iceberg.

A parte invisível muitas vezes roda em Mainframe.

---

O Mainframe Nunca Foi Embora

Existe uma narrativa popular de que Mainframes desapareceram.

Isso nunca aconteceu.

O que aconteceu foi algo diferente.

Eles ficaram invisíveis.

Ninguém vê o Mainframe.

Mas todos usam.

Quando você passa um cartão.

Quando faz PIX.

Quando compra uma passagem aérea.

Quando consulta um seguro.

Quando paga impostos.

Existe uma grande probabilidade de um Mainframe estar envolvido.

---

O Desafio dos Anos 2000

Um dos maiores momentos da história da IBM foi o famoso Bug do Milênio.

Muitos sistemas armazenavam anos usando apenas dois dígitos.

Exemplo:

99

00

Quando chegasse o ano 2000, milhões de programas poderiam interpretar:

00

como 1900.

O mundo inteiro entrou em pânico.

Governos contrataram milhares de programadores COBOL.

Muitos profissionais construíram carreiras inteiras trabalhando nesse projeto.

O curioso?

Grande parte do sucesso ocorreu justamente porque Mainframes eram sistemas extremamente bem documentados.

---

O Segundo Easter Egg

Existe uma brincadeira antiga no mundo Mainframe:

"Mainframe é a única tecnologia que os jornais só mencionam quando para."

Quando tudo funciona, ninguém fala.

Quando um banco fica indisponível por dez minutos, vira manchete nacional.

Isso mostra o quanto esses sistemas se tornaram essenciais.

---

A Era da Internet

Quando a internet surgiu, muitos especialistas declararam o fim do Mainframe.

Aconteceu exatamente o contrário.

A internet aumentou a demanda por processamento.

Mais acessos.

Mais transações.

Mais clientes.

Mais integrações.

O Mainframe tornou-se ainda mais importante.

---

O Nascimento do DB2

Outro capítulo fundamental da IBM foi o DB2.

Criado a partir das pesquisas de Edgar F. Codd sobre bancos relacionais.

O DB2 ajudou a transformar a forma como empresas armazenam dados.

Hoje conceitos como:

SELECT

JOIN

INDEX

TABLE

são comuns.

Mas houve uma época em que tudo isso era revolucionário.

---

A Revolução do CICS

Outro herói pouco conhecido é o CICS.

Customer Information Control System.

Ele permitiu que sistemas deixassem de ser exclusivamente batch.

Agora usuários podiam interagir online.

Em tempo real.

Caixas eletrônicos.

Terminais bancários.

Consultas instantâneas.

Tudo isso foi potencializado pelo CICS.

---

O Que Um COBOL Jr Deve Aprender Com a História da IBM?

Primeira lição:

Tecnologia é uma maratona.

Não uma corrida de cem metros.

A IBM não sobreviveu 115 anos perseguindo modismos.

Ela sobreviveu resolvendo problemas reais.

---

Segunda lição:

Confiabilidade vale ouro.

Uma aplicação pode ser bonita.

Pode usar a linguagem da moda.

Pode ter milhões de downloads.

Mas se não for confiável, não sobrevive.

---

Terceira lição:

Fundamentos importam.

COBOL.

JCL.

VSAM.

DB2.

CICS.

Datasets.

Esses conceitos parecem antigos.

Mas continuam sustentando operações críticas.

---

O Futuro Chegou

Hoje a IBM investe pesadamente em:

• Inteligência Artificial

• WatsonX

• Quantum Computing

• Cloud Híbrida

• OpenShift

• Red Hat

• Automação

Mas existe algo interessante.

Ela não abandonou o Mainframe.

Pelo contrário.

Ela o integrou ao futuro.

O IBM Z moderno executa:

• Containers

• APIs REST

• Java

• Python

• Node.js

• COBOL

• IA

Tudo no mesmo ecossistema.

---

O Maior Easter Egg de Todos

Existe uma ironia divertida na história da tecnologia.

Muitos desenvolvedores passam anos tentando criar sistemas escaláveis.

Altamente disponíveis.

Seguros.

Auditáveis.

Transacionais.

E acabam redescobrindo conceitos que o Mainframe já utilizava há décadas.

Controle transacional.

Alta disponibilidade.

Particionamento.

Segurança centralizada.

Recuperação automática.

Observabilidade.

Governança.

Tudo isso já fazia parte do universo IBM muito antes da maioria das plataformas modernas existir.

---

Conclusão

Quando comemoramos os 115 anos da IBM, não estamos celebrando apenas uma empresa.

Estamos celebrando uma parte importante da história da computação.

Dos cartões perfurados de Hollerith ao IBM z17.

Do COBOL ao WatsonX.

Do System/360 à Inteligência Artificial.

A IBM ajudou a construir a infraestrutura invisível que move a economia global.

E para você, Desenvolvedor COBOL Jr., existe uma mensagem importante nessa história:

Aprenda as tecnologias modernas.

Explore IA.

Conheça Cloud.

Estude APIs.

Mas nunca subestime os fundamentos.

Porque enquanto o mundo muda de linguagem a cada poucos anos, os sistemas críticos continuam exigindo aquilo que sempre importou:

Confiabilidade.

Performance.

Segurança.

Disponibilidade.

E é exatamente nesse ponto que o Mainframe e a IBM construíram um legado que atravessa gerações.

Parabéns, IBM.

115 anos conectando passado, presente e futuro.

 

Bellacosa Mainframe quando o sonho da nuvem virada pesadelo

☕💸☁️ CLOUD BILL SHOCK — QUANDO A FATURA DA NUVEM CHEGA E O MAINFRAME COMEÇA A PARECER BARATO

Existe um momento muito curioso na vida de quase toda empresa que embarca na jornada da computação em nuvem.

No início tudo parece maravilhoso.

O desenvolvedor cria um servidor em poucos minutos.

O ambiente de testes nasce instantaneamente.

Os sistemas escalam sozinhos.

As equipes ganham agilidade.

Os executivos sorriem.

Os arquitetos comemoram.

Os fornecedores fazem apresentações cheias de gráficos coloridos.

E então chega a primeira fatura realmente grande.

Nesse momento nasce um fenômeno que ficou conhecido mundialmente como:

Cloud Bill Shock.

Ou, em português:

O Choque da Fatura da Nuvem.

Para muitos profissionais jovens, especialmente quem está começando carreira em COBOL e Mainframe, esse termo parece estranho.

Afinal, durante anos ouvimos que a nuvem era mais moderna, mais simples e mais barata.

Mas a realidade dos grandes ambientes corporativos mostrou uma verdade muito interessante.

Cloud pode ser fantástica.

Cloud pode ser revolucionária.

Cloud pode acelerar negócios.

Mas cloud nem sempre é barata.

E algumas empresas descobriram isso da forma mais dolorosa possível.

Ao abrir a fatura no final do mês.

---

O que uma Analista COBOL Júnior precisa entender

Vamos começar do início.

Imagine que você trabalha em um banco tradicional.

Existe um ambiente mainframe que processa:

• contas correntes;

• cartões;

• PIX;

• empréstimos;

• aplicações financeiras.

Tudo funciona há décadas.

O sistema está pago.

A infraestrutura está instalada.

Os profissionais conhecem a plataforma.

Os processos são estáveis.

Então surge a pergunta:

"Por que não colocar tudo na nuvem?"

Parece uma pergunta simples.

Mas a resposta é extremamente complexa.

Porque existe uma enorme diferença entre:

custo inicial
e
custo operacional contínuo.

---

O encanto da nuvem

Imagine uma startup recém-criada.

Ela possui:

• 5 desenvolvedores;

• 1 produto;

• 100 clientes.

Comprar um datacenter próprio seria loucura.

A nuvem resolve o problema.

Você cria:

• servidores;

• bancos de dados;

• armazenamento;

• monitoramento.

Tudo com poucos cliques.

O modelo parece perfeito.

E realmente é.

Nesse estágio.

---

O problema da escala

Agora imagine que essa startup cresceu.

Não possui mais:

• 100 clientes.

Possui:

• 1 milhão.

Depois:

• 10 milhões.

Depois:

• 50 milhões.

Depois:

• 100 milhões.

Agora o cenário muda completamente.

Cada operação gera consumo.

Cada acesso gera consumo.

Cada consulta gera consumo.

Cada byte armazenado gera consumo.

Cada transferência de dados gera consumo.

Cada serviço adicional gera consumo.

A conta começa a crescer.

E cresce rapidamente.

---

O aluguel invisível

Uma forma simples de explicar cloud para um iniciante é esta:

Mainframe tradicional muitas vezes funciona como casa própria.

Cloud funciona como aluguel.

Imagine um apartamento alugado.

No começo parece excelente.

Pouco investimento inicial.

Entrada reduzida.

Flexibilidade.

Mas depois de vinte anos pagando aluguel...

Você percebe que gastou uma fortuna.

Cloud possui comportamento parecido.

Você paga continuamente por:

• CPU;

• memória;

• armazenamento;

• rede;

• backup;

• tráfego;

• monitoramento;

• segurança.

A conta nunca para.

---

O dia em que o financeiro descobre a AWS

Existe uma história que se repete em inúmeras empresas.

A área técnica está feliz.

A inovação está acelerada.

Os desenvolvedores estão satisfeitos.

Então o departamento financeiro recebe a fatura.

Primeiro mês:

US$ 5 mil.

Segundo mês:

US$ 20 mil.

Terceiro mês:

US$ 80 mil.

Sexto mês:

US$ 500 mil.

Um ano depois:

milhões de dólares.

Nesse momento alguém pergunta:

"Por que estamos gastando tudo isso?"

E nasce uma investigação corporativa.

---

O caso do armazenamento

Uma analista COBOL talvez pense:

"Mas armazenamento é barato."

Sim.

Individualmente.

Mas vamos fazer uma conta simples.

Imagine um banco com:

• 100 milhões de clientes;

• documentos digitalizados;

• extratos;

• imagens;

• logs;

• backups;

• auditoria.

Estamos falando de petabytes.

Talvez dezenas de petabytes.

Quando o volume cresce, cada centavo por gigabyte se transforma em milhões.

---

O inimigo chamado Data Transfer

Existe uma cobrança que assusta muitos arquitetos.

Transferência de dados.

Os provedores de nuvem adoram falar sobre armazenamento.

Sobre CPU.

Sobre inteligência artificial.

Mas existe um detalhe.

Mover dados também custa dinheiro.

Muito dinheiro.

Imagine:

• aplicativos móveis;

• APIs;

• integrações;

• analytics;

• parceiros externos.

Bilhões de chamadas.

Bilhões de respostas.

Terabytes trafegando diariamente.

Cada pacote possui custo.

---

O pesadelo do ambiente esquecido

Todo analista experiente já viu isso.

Um desenvolvedor cria:

• servidor de teste;

• banco temporário;

• ambiente experimental.

O projeto termina.

O ambiente fica ligado.

Dias passam.

Meses passam.

Anos passam.

Ninguém percebe.

Mas a cobrança continua.

Existem empresas pagando milhares de dólares por recursos esquecidos.

---

O efeito multiplicador dos microsserviços

Os microsserviços trouxeram inúmeras vantagens.

Mas também criaram novos desafios.

No mundo tradicional talvez existisse:

• uma aplicação;

• um banco de dados.

No mundo moderno podemos ter:

• centenas;

• milhares;

• dezenas de milhares de serviços.

Cada um consumindo:

• CPU;

• memória;

• armazenamento;

• rede.

Separadamente parecem baratos.

Juntos tornam-se gigantescos.

---

Quando o Mainframe entra na conversa

É aqui que uma analista COBOL começa a entender o debate.

Um mainframe não é vendido como servidor barato.

Nunca foi.

Mas existe algo impressionante nele.

Consolidação.

Um único IBM Z moderno pode processar volumes absurdos de transações.

Em muitos casos substituindo centenas ou milhares de servidores distribuídos.

O resultado é que algumas cargas financeiras apresentam:

• menor consumo energético;

• menor ocupação física;

• menor administração;

• menor complexidade operacional.

Por isso o cálculo econômico não é tão simples quanto parece.

---

O choque das empresas famosas

Nos últimos anos surgiu um movimento chamado:

Cloud Repatriation

Traduzindo:

"Trazer sistemas de volta."

Empresas que migraram tudo para cloud começaram a revisar decisões.

Não porque a nuvem fosse ruim.

Mas porque certas cargas de trabalho ficaram caras demais.

Algumas descobriram economias milionárias ao mover parte dos ambientes para:

• infraestrutura própria;

• colocation;

• plataformas especializadas.

O mercado percebeu que não existe solução mágica.

---

O erro mais comum dos iniciantes

Muitos profissionais novos acreditam que arquitetura é apenas tecnologia.

Mas arquitetura também é economia.

Um arquiteto precisa entender:

• desempenho;

• segurança;

• disponibilidade;

• custos.

A melhor solução técnica do mundo pode fracassar se custar dez vezes mais que o necessário.

---

O que os bancos aprenderam

Os grandes bancos possuem uma experiência valiosa.

Eles processam bilhões de transações há décadas.

Por isso normalmente adotam arquitetura híbrida.

Não colocam tudo na cloud.

Também não deixam tudo no mainframe.

Cada ambiente recebe a carga mais adequada.

Por exemplo:

Aplicativo móvel?

Cloud.

Machine Learning?

Cloud.

Analytics?

Cloud.

Core bancário?

Talvez mainframe.

Liquidação financeira?

Talvez mainframe.

Processamento crítico?

Talvez mainframe.

---

O paradoxo que ninguém conta

Aqui está a parte mais interessante.

O objetivo da cloud nunca foi ser sempre mais barata.

O objetivo principal era:

agilidade.

Você consegue lançar produtos rapidamente.

Experimentar ideias.

Criar novos serviços.

Escalar em minutos.

Essa velocidade possui valor.

Muitas vezes o ganho de negócio compensa o aumento de custo.

Por isso empresas continuam investindo bilhões em nuvem.

---

O que uma Analista COBOL deve aprender com isso

Talvez a maior lição seja esta.

Não existe guerra entre Mainframe e Cloud.

Essa guerra só existe em apresentações simplificadas.

No mundo real os dois convivem.

E convivem muito bem.

O profissional moderno precisa compreender:

• COBOL;

• APIs;

• Cloud;

• Mensageria;

• Integração;

• Arquitetura distribuída.

Porque o mercado não procura especialistas que conhecem apenas um lado.

Procura profissionais que entendem como tudo se conecta.

---

Conclusão: Quando a Fatura Vira Professor

Cloud Bill Shock é uma das lições mais importantes da tecnologia moderna.

Ele nos lembra que inovação possui custo.

Escalabilidade possui custo.

Conveniência possui custo.

Flexibilidade possui custo.

A nuvem transformou a indústria.

Permitiu o nascimento de empresas como Nubank, Mercado Pago e centenas de fintechs.

Mas também ensinou uma lição valiosa.

Quando os números chegam à casa dos milhões de clientes e bilhões de transações, a discussão deixa de ser tecnológica.

Passa a ser econômica.

E é justamente nesse momento que muitos executivos voltam a olhar para tecnologias que julgavam ultrapassadas.

Mainframe.

COBOL.

CICS.

DB2.

IBM Z.

Não porque sejam antigos.

Mas porque continuam resolvendo problemas extremamente difíceis com eficiência impressionante.

Por isso, da próxima vez que alguém disser que o futuro pertence apenas à nuvem, lembre-se de uma verdade que o mercado financeiro aprendeu ao longo das décadas:

A tecnologia mais moderna nem sempre é a mais barata.
A mais antiga nem sempre é a mais cara.
E a melhor arquitetura quase sempre é aquela que equilibra inovação, desempenho e custo.

É exatamente nesse ponto que nasce o verdadeiro arquiteto de sistemas.

E é exatamente aí que uma analista COBOL deixa de enxergar apenas código e começa a enxergar negócios.

 

Bellacosa Mainframe e uma visão do sistema bancario brasileiro

☕🚀 Os Maiores Bancos Digitais do Brasil Nasceram na Nuvem, Mas o Dinheiro Ainda Passa pelo Mainframe

Existe uma frase que se tornou quase um mantra no mercado financeiro moderno:

"O futuro está na nuvem."

E é verdade.

Nubank, Inter, Mercado Pago, PicPay, PagBank e dezenas de fintechs brasileiras nasceram em arquiteturas modernas, utilizando APIs, microsserviços, containers, Kubernetes, inteligência artificial e infraestrutura cloud.

Mas existe uma realidade pouco comentada fora dos bastidores da tecnologia bancária.

Uma realidade que surpreende estudantes, jornalistas, executivos recém-chegados ao setor financeiro e até muitos profissionais de TI.

O dinheiro que movimenta bilhões de reais diariamente no Brasil continua passando por sistemas centrais executados em plataformas que nasceram décadas antes da internet comercial.

Sim.

Enquanto o cliente faz um PIX em um smartphone equipado com processadores capazes de executar bilhões de operações por segundo, uma parte significativa da infraestrutura que garante que aquele dinheiro chegue ao destino continua rodando em ambientes IBM Z, CICS, DB2, MQ e COBOL.

E isso não acontece por nostalgia.

Acontece porque funciona.

Muito bem.

---

O mito do "banco 100% digital"

Quando um banco digital aparece na televisão, geralmente a propaganda mostra:

• aplicativo moderno;

• cartão colorido;

• conta aberta em minutos;

• chatbot inteligente;

• investimentos com poucos cliques.

Tudo parece novo.

Tudo parece revolucionário.

Tudo parece distante do mundo dos grandes datacenters.

Mas existe uma diferença importante entre:

interface digital
e
infraestrutura financeira.

O cliente enxerga o aplicativo.

O sistema financeiro enxerga liquidação.

E são coisas completamente diferentes.

Um banco pode ter uma experiência totalmente digital e, ainda assim, depender de sistemas centrais extremamente robustos para realizar:

• liquidação financeira;

• compensação;

• controle contábil;

• reconciliação;

• registro de operações;

• cálculo de tarifas;

• processamento de empréstimos;

• integração com o Banco Central.

É nesse momento que entram os sistemas de missão crítica.

---

O que acontece quando você faz um PIX?

Vamos imaginar uma situação extremamente comum.

Você abre o aplicativo.

Transfere R$ 100 para um amigo.

A operação parece instantânea.

Na tela tudo ocorre em segundos.

Mas por trás dos bastidores existe uma verdadeira cadeia industrial de processamento.

O aplicativo envia a solicitação.

Uma API recebe o pedido.

Serviços de autenticação validam identidade.

Motores antifraude executam verificações.

Regras de compliance são avaliadas.

Sistemas de limites são consultados.

Dados cadastrais são verificados.

Mensagerias distribuem eventos.

Sistemas contábeis registram a operação.

Mecanismos de liquidação realizam o acerto financeiro.

Tudo isso antes que a mensagem "PIX realizado com sucesso" apareça na tela.

O usuário vê um clique.

O datacenter vê centenas de transações.

---

Onde entra o mainframe?

É aqui que muita gente se surpreende.

O mainframe raramente aparece na camada visual.

Ele normalmente opera na camada mais importante.

A camada onde não pode haver erro.

Imagine o seguinte cenário.

Se uma rede social ficar indisponível por 10 minutos, usuários reclamam.

Se um streaming cair durante uma série, pessoas ficam irritadas.

Mas se um banco perder o controle de saldos durante 10 minutos?

O problema pode atingir milhões de clientes.

Por isso os sistemas responsáveis pelos registros financeiros mais críticos precisam apresentar:

• disponibilidade extrema;

• consistência absoluta;

• segurança rigorosa;

• rastreabilidade completa;

• recuperação imediata.

São justamente essas características que fizeram os mainframes permanecerem relevantes.

---

O paradoxo da fintech

As fintechs surgiram prometendo romper com os bancos tradicionais.

Em muitos aspectos conseguiram.

Mudaram a experiência do cliente.

Reduziram burocracias.

Popularizaram contas digitais.

Criaram novos modelos de negócio.

Mas descobriram rapidamente uma verdade do mercado financeiro.

Movimentar dinheiro é muito mais difícil do que movimentar dados.

Enviar uma foto errada em uma rede social gera um transtorno.

Transferir R$ 10 milhões para a conta errada gera uma crise.

Por isso a arquitetura financeira moderna acabou evoluindo para um modelo híbrido.

Na superfície:

• cloud;

• APIs;

• microsserviços;

• inteligência artificial.

No núcleo:

• processamento transacional;

• bancos de dados críticos;

• mensageria corporativa;

• sistemas centrais de liquidação.

É uma combinação extremamente poderosa.

---

A nuvem descobriu que precisa do mainframe

Durante alguns anos surgiu uma narrativa bastante agressiva.

Muitos especialistas afirmavam que o mainframe desapareceria rapidamente.

A computação em nuvem seria suficiente para tudo.

A realidade mostrou algo diferente.

O que ocorreu foi integração.

Hoje observamos ambientes híbridos onde:

• Kubernetes conversa com CICS;

• APIs REST acessam programas COBOL;

• aplicações cloud consomem serviços do z/OS;

• eventos trafegam através do IBM MQ;

• microsserviços utilizam informações armazenadas em DB2.

Não houve substituição.

Houve convergência.

A nuvem não matou o mainframe.

A nuvem passou a conversar com ele.

---

O caso brasileiro

O Brasil possui um dos sistemas financeiros mais sofisticados do planeta.

Muitas vezes não percebemos isso.

PIX.

TED.

DOC.

Open Finance.

Cartões.

Boletos.

Débito automático.

Tudo isso precisa funcionar para centenas de milhões de contas.

Os números impressionam.

Bilhões de transações são processadas todos os meses.

Milhões de operações acontecem simultaneamente.

O sistema precisa funcionar:

• de madrugada;

• em feriados;

• durante promoções;

• na Black Friday;

• durante a Copa do Mundo;

• durante grandes eventos nacionais.

A infraestrutura necessária para suportar esse volume é gigantesca.

E boa parte dela continua baseada em tecnologias que nasceram décadas atrás, mas evoluíram continuamente.

---

O COBOL que ninguém vê

Poucas tecnologias sofreram tanto preconceito quanto o COBOL.

Para muitos profissionais jovens, COBOL parece uma relíquia.

Algo pertencente a museus de informática.

Mas existe um detalhe curioso.

Grande parte das pessoas que criticam COBOL utilizou sistemas processados por COBOL antes mesmo do café da manhã.

Salário.

PIX.

Cartão.

Financiamento.

Previdência.

Seguros.

Consórcios.

Tudo isso frequentemente passa por programas COBOL.

O motivo é simples.

Esses sistemas foram construídos ao longo de décadas.

Receberam investimentos bilionários.

Foram testados em condições extremas.

Acumularam conhecimento de negócio impossível de reproduzir rapidamente.

Muitas vezes o código representa mais valor do que a própria infraestrutura.

---

O banco invisível

Imagine um iceberg.

O cliente vê apenas a ponta.

Aplicativo.

Cartão.

Notificação.

Interface.

Mas abaixo da superfície existe uma massa gigantesca de tecnologia invisível.

Essa parte inclui:

• motores contábeis;

• sistemas regulatórios;

• integração com Banco Central;

• mecanismos de liquidação;

• auditoria;

• compliance;

• segurança.

É nesse universo invisível que o mainframe continua brilhando.

E justamente por ser invisível, raramente recebe o reconhecimento merecido.

---

Quando tudo funciona ninguém percebe

Existe uma ironia interessante no mundo da infraestrutura.

Quanto melhor um sistema funciona, menos as pessoas falam sobre ele.

Ninguém elogia um elevador por funcionar.

Ninguém agradece à rede elétrica por fornecer energia.

Ninguém faz uma postagem comemorando que o saldo bancário apareceu corretamente.

Mas quando ocorre uma falha?

Todo mundo percebe.

Por isso os sistemas centrais são projetados para uma missão simples:

não chamar atenção.

O sucesso é a invisibilidade.

---

O futuro não é cloud versus mainframe

Uma das maiores lições da última década foi perceber que a discussão estava errada.

A pergunta nunca deveria ter sido:

"Cloud ou Mainframe?"

A pergunta correta é:

"Como integrar os dois da melhor forma possível?"

Os líderes do mercado entenderam isso.

Hoje as arquiteturas mais modernas utilizam o melhor dos dois mundos.

Cloud para:

• inovação rápida;

• elasticidade;

• analytics;

• inteligência artificial.

Mainframe para:

• processamento massivo;

• transações críticas;

• consistência financeira;

• segurança corporativa.

O resultado é uma arquitetura híbrida extremamente eficiente.

---

A verdadeira transformação digital

Muitas empresas acreditam que transformação digital significa abandonar tudo que veio antes.

Mas a história mostra outra coisa.

Transformação digital bem-sucedida raramente consiste em destruir.

Consiste em evoluir.

Os sistemas que sustentam o mercado financeiro brasileiro representam décadas de conhecimento acumulado.

Substituí-los completamente seria como demolir uma usina hidrelétrica para construir um gerador portátil.

Não faz sentido.

O caminho inteligente é modernizar.

Expor APIs.

Integrar plataformas.

Automatizar processos.

Conectar o legado ao futuro.

---

O que os estudantes precisam entender

Quem está começando carreira em tecnologia frequentemente busca apenas as ferramentas mais recentes.

Isso é natural.

Mas existe uma lição valiosa.

As tecnologias que movimentam bilhões nem sempre são as mais populares nas redes sociais.

Muitas vezes são as mais confiáveis.

As mais estáveis.

As mais resilientes.

O profissional que entende:

• cloud;

• APIs;

• Kubernetes;

• segurança;

• mainframe;

• integração corporativa;

torna-se extremamente valioso para o mercado.

Porque consegue enxergar a arquitetura completa.

Não apenas a camada visível.

---

Conclusão: o coração continua batendo

Os maiores bancos digitais do Brasil nasceram na nuvem.

Foram criados por uma geração que cresceu falando de APIs, microsserviços e aplicações móveis.

Mudaram completamente a forma como os brasileiros se relacionam com o dinheiro.

Mas, ao crescerem, descobriram algo que os bancos tradicionais já sabiam há décadas.

No mercado financeiro, velocidade é importante.

Experiência do usuário é importante.

Inovação é importante.

Mas nada é mais importante do que confiança.

E confiança se constrói com sistemas capazes de operar dia após dia, ano após ano, movimentando bilhões de reais sem perder o controle de um único centavo.

Por isso, enquanto milhões de brasileiros fazem PIX, pagam boletos, investem, financiam imóveis e utilizam aplicativos modernos, existe uma infraestrutura silenciosa trabalhando nos bastidores.

Uma infraestrutura que raramente aparece nas propagandas.

Que quase nunca vira manchete.

Mas que continua sustentando o sistema financeiro nacional.

A nuvem trouxe inovação.

As fintechs trouxeram agilidade.

Os aplicativos trouxeram conveniência.

Mas, no coração de boa parte dessa engrenagem, o velho gigante continua trabalhando.

Discreto.

Confiável.

Resiliente.

Processando bilhões.

Como faz há décadas.

E, ao que tudo indica, continuará fazendo por muitos anos.

Bellacosa Mainframe e uma visão da integração mainframe + nuvem

☕🚀 Azure + IBM MQ + CICS + COBOL: Quando a Nuvem Descobre Que Ainda Precisa do Mainframe

A arquitetura híbrida que responde em milissegundos e movimenta bilhões sem que ninguém perceba

Existe uma frase que escuto há mais de trinta e cinco anos:

"O Mainframe está morrendo."

A primeira vez que ouvi isso foi quando ainda existiam fitas magnéticas por todos os lados, terminais 3270 ocupavam salas inteiras e a internet comercial engatinhava.

Depois ouvi novamente quando surgiram os ERPs.

Depois quando surgiram os Data Centers distribuídos.

Depois quando vieram os smartphones.

Depois quando chegaram os containers.

Depois quando Kubernetes virou moda.

Depois quando a nuvem se tornou o assunto do momento.

E agora escuto novamente com a Inteligência Artificial.

Curiosamente, enquanto todos anunciavam o funeral do Mainframe, ele continuava processando cartões de crédito, transações bancárias, reservas aéreas, operações de seguradoras, sistemas governamentais e bilhões de dólares diariamente.

Talvez o erro nunca tenha sido tecnológico.

Talvez o erro tenha sido imaginar que inovação significa substituir tudo o que existe.

Na prática, a verdadeira inovação costuma acontecer quando conseguimos conectar mundos aparentemente incompatíveis.

E poucas arquiteturas representam isso melhor do que a integração entre Microsoft Azure e IBM Mainframe utilizando IBM MQ, CICS e COBOL.

Estamos falando de uma arquitetura capaz de unir o melhor dos dois universos:

• Agilidade da nuvem

• Robustez do Mainframe

• Escalabilidade dos microsserviços

• Consistência transacional do CICS

• Segurança do IBM MQ

• Décadas de regras de negócio escritas em COBOL

Tudo funcionando como uma única plataforma.

---

O Grande Equívoco Sobre Modernização

Quando alguém fala em modernização, muitas pessoas imaginam algo parecido com isto:

Sistema Antigo
      ↓
Apagar Tudo
      ↓
Reescrever Tudo
      ↓
Sistema Novo

Na teoria parece simples.

Na prática costuma ser um desastre.

Imagine um banco que possui:

• 40 milhões de clientes

• 30 anos de regras de negócio

• milhares de programas COBOL

• dezenas de sistemas satélites

• integrações desconhecidas

Reescrever tudo pode levar anos.

Custar centenas de milhões.

E ainda introduzir novos erros.

Por isso os grandes bancos do mundo adotaram outro caminho.

Em vez de substituir o Mainframe, passaram a conectá-lo ao ecossistema digital.

É exatamente isso que esta arquitetura faz.

---

O Cliente Nem Imagina o Que Está Acontecendo

Imagine um cliente consultando saldo pelo aplicativo.

Ele toca um botão.

Em menos de um segundo recebe a resposta.

Para ele parece algo simples.

Mas nos bastidores ocorre uma verdadeira orquestra tecnológica.

O aplicativo chama uma API hospedada no Azure.

A API gera uma mensagem JSON.

Essa mensagem atravessa a rede.

Chega ao IBM MQ.

O MQ desperta uma transação CICS.

O CICS chama um programa COBOL.

O COBOL consulta DB2.

A resposta retorna pelo mesmo caminho.

Tudo isso em poucos milissegundos.

O usuário jamais perceberá.

E essa é justamente a beleza da arquitetura.

---

IBM MQ: O Carteiro Mais Confiável do Mundo Corporativo

Muitos profissionais mais jovens cresceram utilizando APIs REST.

Naturalmente surge a pergunta:

Por que usar MQ?

Porque sistemas críticos exigem garantias que HTTP sozinho não consegue fornecer.

Quando uma mensagem entra em uma fila MQ, ela não desaparece.

Ela permanece armazenada até ser processada.

Mesmo que:

• um servidor caia

• a rede falhe

• uma aplicação seja reiniciada

a mensagem continua lá.

Imagine uma transferência financeira de cem mil reais.

Você gostaria que ela dependesse exclusivamente de uma conexão HTTP momentânea?

Provavelmente não.

É por isso que bancos continuam apaixonados pelo MQ.

Ele foi criado para ambientes onde perder uma única mensagem pode significar prejuízo milionário.

---

Request-Reply: O Casamento Entre Dois Mundos

Existe um detalhe fascinante nessa arquitetura.

O mundo web é síncrono.

O mundo MQ é assíncrono.

São filosofias diferentes.

Quando um navegador faz uma requisição HTTP, ele espera uma resposta.

Quando uma aplicação grava uma mensagem em uma fila MQ, ela normalmente segue seu caminho.

Mas o usuário quer uma resposta imediata.

Surge então o padrão Request-Reply.

Funciona assim:

A aplicação envia uma mensagem para a fila REQUEST.

O Mainframe processa.

Depois envia uma resposta para uma fila REPLY.

A aplicação recupera a resposta e devolve ao usuário.

Parece simples.

Mas essa simplicidade esconde décadas de evolução arquitetural.

---

O Poder dos Identificadores

Aqui encontramos um dos elementos mais importantes de toda a solução.

O MsgId.

Cada mensagem recebe um identificador único.

Por exemplo:

A1B2C3D4E5

Quando a resposta é gerada, esse valor reaparece como CorrelId.

Dessa forma:

Request
MsgId = A1B2C3D4E5

Reply
CorrelId = A1B2C3D4E5

A aplicação consegue saber exatamente qual resposta pertence a qual requisição.

Sem isso seria impossível processar milhares de mensagens simultaneamente.

É como o número de protocolo de uma ligação para suporte.

Sem ele tudo viraria uma enorme confusão.

---

MQ Trigger: O Despertador do Mainframe

Uma das partes mais elegantes dessa arquitetura é o Trigger.

Imagine um operador sentado observando uma fila.

Sempre que chegasse uma mensagem ele iniciaria um programa.

Seria absurdo.

O MQ faz isso automaticamente.

Quando uma mensagem chega:

QUEUE DEPTH = 1

o Trigger entra em ação.

Instantaneamente ele inicia uma transação CICS.

Sem polling.

Sem scripts.

Sem agendadores.

Sem desperdício de CPU.

É uma solução extremamente elegante criada décadas antes do conceito moderno de eventos ganhar popularidade.

Na verdade, muitos sistemas chamados hoje de Event-Driven Architecture fazem algo conceitualmente muito parecido com o que MQ e CICS realizam há anos.

---

O Router Program: O Maestro da Orquestra

Após a ativação do Trigger entra em cena o Router Program.

Se eu tivesse que apontar o cérebro da arquitetura, seria ele.

Sua função é simples:

Receber.

Analisar.

Decidir.

Encaminhar.

Ele lê o payload.

Consulta tabelas de roteamento.

Avalia parâmetros.

E escolhe qual backend deverá executar o processamento.

Por exemplo:

CONSULTA_CLIENTE → CUST0001
PIX → PIX0001
CARTAO → CARD0001

Isso oferece enorme flexibilidade.

Novos serviços podem ser adicionados sem alterar toda a arquitetura.

Basta cadastrar uma nova regra.

É o equivalente corporativo de um controlador de tráfego aéreo.

---

Quando COBOL Encontra JSON

Muitos profissionais ainda acreditam que COBOL vive preso a arquivos sequenciais e layouts de 80 colunas.

A realidade atual é muito diferente.

O CICS moderno possui recursos nativos para trabalhar com JSON.

Isso significa que uma estrutura como:

{
  "cliente":"VAGNER",
  "saldo":1500
}

pode ser transformada diretamente em estruturas COBOL.

Sem parsers complexos.

Sem centenas de linhas de manipulação de texto.

Sem gambiarras.

Durante décadas, integrar COBOL com formatos modernos exigia muito esforço.

Hoje o próprio CICS faz grande parte desse trabalho.

Essa é uma das transformações menos conhecidas fora do universo Mainframe.

---

O Segredo da Performance

Quando alguém vê Azure, JSON e microsserviços, normalmente imagina dezenas de chamadas distribuídas.

Mas o processamento principal acontece dentro do CICS.

E isso muda tudo.

Após chegar ao Mainframe, a execução ocorre dentro de um ambiente extremamente otimizado.

Não existe:

• startup de container

• inicialização de JVM

• criação de novos processos

• overhead desnecessário

O programa já está carregado.

O ambiente já está pronto.

A transação apenas executa.

É por isso que muitas operações conseguem responder em poucos milissegundos.

Uma característica frequentemente subestimada por quem nunca trabalhou em ambientes de missão crítica.

---

DB2: O Guardião da Consistência

Toda essa velocidade seria inútil sem consistência.

É aqui que entra o DB2.

Quando o COBOL consulta ou atualiza dados, o DB2 garante:

• integridade

• atomicidade

• isolamento

• durabilidade

Os famosos princípios ACID.

Em outras palavras:

ou tudo acontece corretamente

ou nada acontece.

Em sistemas financeiros isso não é luxo.

É obrigação.

Ninguém quer descobrir que o débito ocorreu mas o crédito não.

---

O Valor das Transações

Um aspecto frequentemente ignorado é o gerenciamento transacional.

Quando MQ, CICS e DB2 trabalham juntos, formam um ecossistema extremamente robusto.

Imagine:

• mensagem recebida

• atualização realizada

• resposta enviada

Tudo dentro de uma única unidade lógica de trabalho.

Se qualquer etapa falhar:

rollback.

Como se nada tivesse acontecido.

Esse é um dos motivos pelos quais Mainframes continuam dominando ambientes financeiros.

Confiabilidade não é um recurso opcional.

É parte fundamental do negócio.

---

Dead Letter Queue: A Sala de Quarentena

Nem toda mensagem nasce perfeita.

Erros acontecem.

Layouts incorretos.

Dados inválidos.

Problemas de roteamento.

Mensagens corrompidas.

Se elas bloqueassem a fila principal, toda a operação sofreria.

A solução é a Dead Letter Queue.

A famosa DLQ.

Ela funciona como uma área de isolamento.

Mensagens problemáticas são removidas do fluxo principal e armazenadas separadamente.

O processamento continua.

Os usuários continuam trabalhando.

A equipe técnica pode investigar posteriormente.

É um conceito simples.

Mas extremamente poderoso.

---

O Que os Jovens Arquitetos Podem Aprender Com Isso

Existe uma tendência atual de acreditar que tudo começou com APIs, Kubernetes e microsserviços.

Arquiteturas como esta mostram que muitos conceitos modernos possuem raízes muito mais antigas.

Observe:

Eventos.

Mensageria.

Roteamento dinâmico.

Processamento assíncrono.

Alta disponibilidade.

Escalabilidade.

Observabilidade.

Resiliência.

Tudo isso já existia em ambientes Mainframe décadas atrás.

A diferença é que hoje utilizamos novos nomes para ideias antigas.

---

O Futuro Não É Cloud ou Mainframe

A pergunta correta não é:

Cloud ou Mainframe?

A pergunta correta é:

Como combinar Cloud e Mainframe?

A resposta está justamente nesta arquitetura.

O Azure fornece velocidade para inovação.

O Mainframe fornece estabilidade para execução.

O MQ conecta os dois mundos.

O CICS orquestra as transações.

O COBOL preserva o conhecimento acumulado.

O DB2 protege os dados.

Juntos, eles formam uma plataforma capaz de atender milhões de usuários simultaneamente.

---

Considerações Finais

Ao observar esta arquitetura, não vejo apenas filas MQ, programas COBOL ou serviços Azure.

Vejo algo muito mais interessante.

Vejo a prova de que tecnologia não é uma disputa entre velho e novo.

É uma construção contínua.

Os sistemas que realmente movem o mundo raramente são os mais barulhentos.

São os mais confiáveis.

Enquanto muitos discutem tendências, frameworks e modismos passageiros, arquiteturas híbridas como esta continuam processando pagamentos, movimentando recursos financeiros, autorizando cartões, executando operações críticas e sustentando economias inteiras.

Talvez essa seja a maior lição de todas.

O futuro não pertence exclusivamente à nuvem.

O futuro pertence às arquiteturas capazes de unir inovação e legado sem sacrificar desempenho, segurança ou confiabilidade.

E poucas combinações fazem isso tão bem quanto Azure, IBM MQ, CICS, COBOL e DB2 trabalhando em perfeita harmonia.

Porque, no final das contas, modernizar não significa destruir o passado.

Significa construir pontes entre o que já funciona e aquilo que ainda está por vir.

E essa arquitetura é uma dessas pontes.

O Dia em que um Banco Declarou a Própria Liquidação: Lições de Engenharia, Governança e Confiabilidade a partir do Incidente do Nubank

Bellacosa Mainframe e o incidente informatico do Nubank

O Dia em que um Banco Declarou a Própria Liquidação: Lições de Engenharia, Governança e Confiabilidade a partir do Incidente do Nubank

Introdução

Em junho de 2026, um episódio incomum chamou a atenção do mercado financeiro brasileiro, dos profissionais de tecnologia e dos especialistas em gestão de riscos. Clientes do Nubank receberam comunicações oficiais informando que a instituição teria entrado em processo de liquidação. A mensagem, enviada por canais legítimos da empresa, parecia autêntica, utilizava terminologia regulatória correta e mencionava procedimentos relacionados ao Fundo Garantidor de Créditos (FGC).

O problema era simples e ao mesmo tempo alarmante: a informação era falsa.

Em poucas horas, a notícia se espalhou pelas redes sociais, grupos de investidores, fóruns especializados e veículos de imprensa. O Banco Central precisou esclarecer que não existia qualquer procedimento de liquidação em andamento. O Nubank confirmou que se tratava de um erro operacional decorrente de uma falha em processos internos.

À primeira vista, o incidente parece apenas um erro de comunicação. Entretanto, uma análise mais profunda revela um caso clássico de falha sistêmica envolvendo automação, governança, gestão de mudanças, segregação de ambientes e controles de produção.

Mais importante ainda: o episódio oferece uma oportunidade rara para discutir um tema frequentemente negligenciado em empresas digitais modernas — a diferença entre construir sistemas rápidos e construir sistemas confiáveis.

---

O que aconteceu

Segundo informações divulgadas publicamente, um fluxo responsável por notificações relacionadas a processos de liquidação institucional teria sido acionado indevidamente.

A comunicação foi distribuída para clientes reais utilizando canais oficiais.

Do ponto de vista do usuário final, todos os elementos indicavam legitimidade:

• origem oficial;

• identidade visual correta;

• linguagem regulatória compatível;

• referência ao FGC;

• comunicação direta da instituição.

Em segurança da informação existe um princípio fundamental:

O usuário não possui mecanismos para diferenciar uma mensagem legítima de uma mensagem enviada legitimamente por engano.

Essa frase resume a gravidade do incidente.

Quando uma comunicação falsa vem de um atacante externo, o cliente pode desconfiar.

Quando a mesma comunicação vem do próprio banco, a confiança desaparece como mecanismo de defesa.

---

O erro informático por trás do incidente

Embora os detalhes técnicos completos não tenham sido divulgados, a descrição pública permite inferir algumas hipóteses plausíveis.

O problema parece ter ocorrido em uma combinação de:

• automação de mensagens;

• parametrização inadequada;

• ausência de validações obrigatórias;

• insuficiência de mecanismos de aprovação.

Em engenharia de software, isso é conhecido como um erro de "guard rails", ou seja, ausência de barreiras que impeçam uma ação perigosa.

Imagine um sistema com a seguinte lógica:

Evento:
Liquidação Institucional

Instituição:
[NOME_DO_BANCO]

Ação:
Enviar comunicação aos clientes

Se o campo da instituição estiver vazio, o sistema deveria interromper imediatamente o processo.

No entanto, em muitos sistemas corporativos existem valores padrão.

Exemplo:

if banco == null:
    banco = "Nubank"

Ou ainda:

if banco == "":
    utilizar_instituicao_padrao()

Pequenos atalhos criados durante desenvolvimento, testes ou homologação podem se transformar em bombas-relógio quando chegam à produção.

---

Quando ambientes de teste contaminam a produção

Uma das hipóteses mais discutidas é a existência de um fluxo originalmente criado para testes.

Esse cenário é extremamente comum.

Empresas desenvolvem sistemas utilizando ambientes distintos:

Desenvolvimento

Local onde programadores criam funcionalidades.

Homologação

Ambiente utilizado para validações.

Produção

Sistema real utilizado por clientes.

Na teoria, esses ambientes são completamente isolados.

Na prática, muitas organizações acabam criando atalhos.

Exemplos comuns:

• cópia de bases produtivas;

• reutilização de configurações;

• compartilhamento de APIs;

• uso de dados reais em homologação.

Quando isso acontece, uma fronteira crítica desaparece.

O resultado é que ações originalmente pensadas para teste passam a ter impacto real.

---

A armadilha da automação

O setor financeiro moderno depende de automação em larga escala.

Bancos digitais enviam diariamente:

• notificações;

• alertas;

• extratos;

• avisos regulatórios;

• comunicações de segurança.

Uma única plataforma pode disparar milhões de mensagens por hora.

O benefício é evidente:

• redução de custos;

• velocidade operacional;

• escalabilidade.

O problema é que a automação amplifica erros.

Um funcionário que envia uma mensagem errada manualmente afeta algumas pessoas.

Um sistema automatizado pode afetar milhões.

Existe uma máxima conhecida em operações de TI:

A automação não elimina erros humanos. Ela multiplica seus efeitos.

O incidente ilustra perfeitamente esse princípio.

---

O papel dos controles de mudança

Toda alteração em sistemas críticos deveria seguir um processo formal.

Esse processo normalmente inclui:

Revisão técnica

Validação por outros desenvolvedores.

Aprovação operacional

Análise dos impactos.

Aprovação de negócio

Validação da área responsável.

Testes

Verificação funcional.

Plano de rollback

Capacidade de reversão rápida.

Quando qualquer uma dessas etapas falha, o risco aumenta exponencialmente.

A questão não é impedir erros.

Erros são inevitáveis.

A questão é impedir que erros individuais alcancem clientes.

---

O conceito de “blast radius”

Engenheiros de confiabilidade utilizam o conceito de blast radius.

Traduzindo livremente:

"raio de explosão".

A pergunta é simples:

Se algo der errado, quantas pessoas serão afetadas?

Sistemas modernos devem ser projetados para minimizar esse impacto.

Exemplo:

Em vez de enviar uma comunicação para toda a base de clientes, o sistema deveria:

1. enviar para um grupo piloto;

2. validar resultados;

3. liberar gradualmente;

4. expandir para toda a população.

Essa técnica é utilizada por empresas como:

• Google;

• Amazon;

• Microsoft;

• Netflix.

Caso o disparo incorreto tivesse sido submetido a um rollout progressivo, o incidente provavelmente teria sido detectado nos primeiros minutos.

---

O problema dos dados reais em testes

Outro aprendizado importante envolve o uso de dados produtivos.

Muitas empresas utilizam bases reais para reproduzir cenários complexos.

Isso facilita testes.

Também aumenta riscos.

Dados reais possuem características imprevisíveis:

• relacionamentos existentes;

• integrações ativas;

• gatilhos automáticos;

• usuários legítimos.

Uma rotina criada para laboratório pode encontrar condições inesperadas quando executada em produção.

É por isso que organizações maduras investem em:

• anonimização;

• mascaramento de dados;

• ambientes sintéticos.

O objetivo é reproduzir a realidade sem colocar clientes reais em risco.

---

O fator psicológico do incidente

Existe um aspecto pouco discutido.

O dano não foi apenas tecnológico.

Foi psicológico.

O sistema financeiro funciona baseado em confiança.

Quando um banco afirma que está sendo liquidado, o cliente não realiza uma análise técnica.

Ele reage emocionalmente.

As perguntas surgem imediatamente:

• Meu dinheiro está seguro?

• Preciso sacar recursos?

• Minha conta continuará funcionando?

• Meu cartão será cancelado?

• Vou perder investimentos?

Em poucos minutos pode surgir um fenômeno conhecido como corrida informacional.

Não necessariamente uma corrida bancária tradicional.

Mas uma corrida por esclarecimentos.

Milhares de pessoas acessam simultaneamente:

• aplicativo;

• central de atendimento;

• redes sociais;

• imprensa.

O volume gerado pode se tornar um problema operacional por si só.

---

O impacto no mercado

Embora o incidente tenha sido rapidamente esclarecido, ele produziu repercussões relevantes.

Mercados financeiros são altamente sensíveis à informação.

Especialmente quando envolve:

• liquidez;

• solvência;

• regulação.

Investidores institucionais monitoram continuamente sinais de risco.

Uma notícia sobre liquidação, ainda que falsa, pode provocar:

• volatilidade;

• aumento de dúvidas;

• especulação;

• pressão reputacional.

Mesmo após o esclarecimento, permanece uma questão:

Como um mecanismo tão crítico conseguiu ser acionado incorretamente?

Essa pergunta interessa mais ao mercado do que o próprio erro.

Porque ela trata da maturidade operacional da organização.

---

O custo invisível da reputação

Empresas costumam medir:

• receita;

• lucro;

• crescimento;

• número de clientes.

Poucas conseguem medir confiança.

Entretanto, confiança é um dos ativos mais valiosos do setor financeiro.

Uma instituição pode gastar bilhões em marketing.

Mas basta um único incidente de credibilidade para comprometer anos de construção de marca.

A reputação é semelhante a um sistema distribuído:

Leva muito tempo para convergir.

Pode ser afetada em segundos.

---

O que empresas podem aprender

O incidente produz diversas lições para organizações digitais.

1. Sistemas críticos precisam de múltiplas aprovações

Nenhuma comunicação regulatória deveria depender de uma única ação.

Princípio dos quatro olhos:

duas pessoas precisam validar.

2. Produção deve ser protegida contra operadores

O objetivo não é desconfiar das pessoas.

É reconhecer que erros acontecem.

Sistemas precisam impedir ações perigosas.

3. Rollouts graduais reduzem impacto

Nenhum disparo massivo deveria ocorrer instantaneamente.

4. Testes precisam ser isolados

Ambientes de homologação devem permanecer separados da produção.

5. Alertas precisam monitorar comportamentos anormais

Se uma mensagem de liquidação for enviada, alarmes automáticos deveriam disparar imediatamente.

---

O paradoxo dos bancos digitais

O caso revela um paradoxo interessante.

Os bancos digitais são extraordinariamente eficientes.

Conseguem:

• abrir contas em minutos;

• aprovar cartões rapidamente;

• processar milhões de transações.

Mas velocidade e confiabilidade nem sempre evoluem no mesmo ritmo.

À medida que organizações crescem, seus sistemas tornam-se mais complexos.

Mais integrações.

Mais automações.

Mais dependências.

Mais pontos de falha.

O desafio deixa de ser construir funcionalidades.

Passa a ser controlar complexidade.

---

A maturidade dos sistemas modernos

Os maiores incidentes tecnológicos raramente acontecem por falhas sofisticadas.

Na maioria das vezes eles surgem de:

• configurações incorretas;

• permissões inadequadas;

• processos incompletos;

• validações ausentes.

A história da tecnologia está repleta de exemplos semelhantes.

Falhas milionárias já foram causadas por:

• campos vazios;

• scripts de manutenção;

• comandos executados no ambiente errado;

• parâmetros incorretos.

O problema não é a tecnologia.

O problema é a interação entre tecnologia, pessoas e processos.

---

Conclusão

O episódio envolvendo a falsa comunicação de liquidação do Nubank não deve ser interpretado apenas como um erro operacional isolado.

Ele representa um estudo de caso sobre os desafios da engenharia moderna em sistemas de missão crítica.

O incidente demonstrou como um único evento pode atravessar múltiplas camadas organizacionais:

• tecnologia;

• governança;

• comunicação;

• segurança;

• reputação;

• mercado financeiro.

Mais importante, revelou uma verdade frequentemente esquecida em ambientes digitais:

A confiabilidade não nasce da ausência de erros.

Ela nasce da capacidade de impedir que erros inevitáveis se transformem em crises.

Em um mundo onde bancos são plataformas de software, cada linha de código, cada configuração e cada processo operacional participa diretamente da construção da confiança do cliente.

E confiança, diferentemente do software, não pode ser restaurada simplesmente com um novo deploy.

Ela precisa ser reconquistada.

Para ir mais longe

Bellacosa Mainframe e o incidente do nubank

nubank-diz-que-mensagem-sobre-liquidacao-extrajudicial-enviada-a-clientes-foi-erro-tecnico-pontual

https://www.cnnbrasil.com.br/economia/macroeconomia/cofundadora-do-nubank-diz-que-mensagem-sobre-liquidacao-foi-erro-bizarro/

https://www.tecmundo.com.br/mercado/413858-erro-de-desenvolvedor-disparou-mensagens-de-liquidacao-extrajudicial-do-nubank.htm

https://comunidade.nubank.com.br/discussoes/post/email-de-liquidacao-judicial-Ii0ygNNm8mD5Qxr