☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

domingo, 13 de setembro de 2026

🕵️ Professor Moriarty em Brasília — O Caso Master e a Arquitetura Invisível do Poder

 

☕ Um Café no Bellacosa Mainframe

🕵️ Professor Moriarty em Brasília — O Caso Master e a Arquitetura Invisível do Poder

Talvez a história do Banco Master não seja apenas a história de um banco que cresceu demais, arriscou demais e finalmente caiu. Talvez seja também uma aula sobre como dinheiro, amizade, religião, política, informação, reputação e acesso podem formar uma rede de poder muito maior que qualquer uma de suas partes.

Há uma cena recorrente nas histórias de Sherlock Holmes que sempre me fascinou.

Holmes encontra um crime.

Investiga.

Encontra outro.

Depois outro.

A princípio, parecem casos independentes.

Um empresário aqui.

Um político ali.

Um criminoso acolá.

Uma chantagem.

Uma informação confidencial.

Um favor.

Uma pessoa aparentemente insignificante.

Até que Holmes deixa de olhar para os indivíduos e começa a observar as conexões.

E então aparece o Professor Moriarty.

Não necessariamente como o homem que executa pessoalmente cada ação, mas como alguém situado no centro de uma extraordinária arquitetura de relacionamentos.

Foi impossível acompanhar o Caso Master sem lembrar disso.

Antes que alguém interprete esta comparação literalmente, faço uma advertência fundamental:

Daniel Vorcaro não é o Professor Moriarty.

Moriarty é ficção.

O Caso Master envolve pessoas reais, investigações reais, direitos reais e responsabilidades que precisam ser individualmente demonstradas.

Neste artigo, Moriarty será apenas nossa ferramenta literária para compreender algo muito mais interessante:

a arquitetura invisível do poder.

E, como numa auditoria séria, utilizaremos cinco gavetas diferentes:

COMPROVADO → ALEGAÇÃO OFICIAL → INDÍCIO → HIPÓTESE → ESPECULAÇÃO

Nunca misture essas gavetas.

É exatamente quando elas são misturadas que investigação vira teoria conspiratória.


🏦 1. Era uma vez um banqueiro

Uma das coisas que mais impressionam na história de Daniel Vorcaro é a velocidade.

Não estamos falando de uma tradicional dinastia bancária brasileira atravessando quatro ou cinco gerações.

Vorcaro entrou no antigo Banco Máxima, assumiu seu controle e posteriormente transformou a instituição no Banco Master.

Em poucos anos, o banqueiro passou a circular em ambientes extraordinariamente poderosos.

Empresários.

Políticos.

Advogados.

Celebridades.

Influenciadores.

Religiosos.

Autoridades.

Pessoas ligadas ao Judiciário.

Enquanto isso, o banco crescia agressivamente.

E aqui surge nossa primeira pergunta.

Como alguém constrói tamanho capital financeiro e social em tão pouco tempo?

Talvez seja um erro imaginar somente uma escada:

DINHEIRO
   ↓
MAIS DINHEIRO
   ↓
MAIS DINHEIRO

O processo parece muito mais interessante:

DINHEIRO
   ↓
RELACIONAMENTOS
   ↓
ACESSO
   ↓
REPUTAÇÃO
   ↓
INFORMAÇÃO
   ↓
OPORTUNIDADES
   ↓
MAIS DINHEIRO

Isso é um feedback loop.

E feedback loops podem produzir crescimento exponencial.


🕸️ 2. Moriarty não é interessante por ser rico

O Professor Moriarty é interessante porque conhece pessoas.

Mais precisamente:

conhece pessoas que conhecem pessoas.

Isso muda tudo.

Em teoria dos grafos, cada indivíduo pode ser representado como um .

Cada relacionamento vira uma aresta.

        PASTOR
          │
          │
EMPRESÁRIO ─── BANQUEIRO ─── POLÍTICO
          │        │
          │        │
       ADVOGADO ───┼── INFLUENCIADOR
                   │
                AUTORIDADE

Uma pessoa com muito dinheiro possui poder.

Uma pessoa com muitos relacionamentos possui outro tipo de poder.

Uma pessoa com dinheiro e relacionamentos possui algo ainda mais poderoso:

capacidade de transformar um recurso no outro.

Dinheiro compra acesso.

Acesso gera relacionamento.

Relacionamento gera confiança.

Confiança abre portas.

Portas abertas produzem oportunidades.

Oportunidades produzem dinheiro.

E o ciclo recomeça.


⛪ 3. A igreja entra no grafo

Foi aqui que nossa conversa ficou particularmente interessante.

A ligação da família Vorcaro com a Igreja Batista da Lagoinha não surgiu aparentemente como uma operação improvisada quando o Master ficou grande.

As relações familiares são antigas.

Henrique Vorcaro, pai de Daniel, teve relacionamento com projetos ligados à igreja.

Daniel esteve ligado à Rede Super.

Fabiano Zettel, cunhado de Vorcaro, tornou-se figura importante na Lagoinha Belvedere.

Isso muda nossa interpretação.

Seria simplista imaginar:

“O banqueiro ficou rico e resolveu usar uma igreja para conhecer gente.”

O fenômeno social pode ter ocorrido de maneira muito mais orgânica:

FAMÍLIA
   ↓
IGREJA
   ↓
AMIZADES
   ↓
EMPRESÁRIOS
   ↓
OUTRAS AMIZADES
   ↓
POLÍTICOS
   ↓
NOVOS NEGÓCIOS

Uma comunidade religiosa também é uma rede de confiança.

E confiança é uma moeda poderosíssima.

Quando alguém em quem confiamos apresenta outra pessoa, parte daquela confiança é transferida.

É quase um certificado digital humano:

TRUSTED BY X
     ↓
PROVAVELMENTE CONFIÁVEL

Não significa corrupção.

Não significa crime.

Significa capital social.


🤝 4. O poder dos “contatinhos”

Nós costumamos tratar “contatinho” como brincadeira.

Mas talvez seja uma das unidades fundamentais do poder.

Imagine que preciso falar com uma autoridade.

Não conheço a autoridade.

Mas conheço alguém que conhece.

EU
 ↓
AMIGO
 ↓
EMPRESÁRIO
 ↓
ADVOGADO
 ↓
AUTORIDADE

Em teoria de redes isso é fascinante.

Poucas conexões podem separar indivíduos aparentemente muito distantes.

Quanto mais central um nó se torna, maior sua capacidade de conectar diferentes grupos.

O dinheiro acelera brutalmente esse processo.

Jantares.

Eventos.

Patrocínios.

Viagens.

Aeronaves.

Camarotes.

Casamentos.

Festas.

Projetos culturais.

Investimentos.

Doações.

Instituições.

Nada disso isoladamente constitui crime.

Mas cada evento pode criar novas arestas no grafo.


✈️ 5. O jatinho também é uma aresta

Quando surgiram notícias sobre viagens realizadas durante a campanha eleitoral de 2022 em aeronave ligada a empresa da qual Vorcaro participava, apareceu uma excelente demonstração dessa lógica.

Entre os participantes estava Nikolas Ferreira.

Nikolas declarou que foi convidado para a caravana política, que a logística foi organizada por terceiros e que desconhecia quem era proprietário da aeronave.

Perfeitamente possível.

Mas, para um investigador, a fotografia possui outra função.

Ela cria um nó verificável:

FOTO
 ↓
DATA
 ↓
PESSOAS
 ↓
AERONAVE
 ↓
PREFIXO
 ↓
OPERADOR
 ↓
PROPRIETÁRIO
 ↓
AGENDA
 ↓
OUTRAS FOTOS
 ↓
OUTRAS PESSOAS

A fotografia não prova corrupção.

Aliás:

FOTO JUNTOS ≠ AMIZADE

AMIZADE ≠ RELAÇÃO FINANCEIRA

RELAÇÃO FINANCEIRA ≠ CORRUPÇÃO

CORRUPÇÃO = EVIDÊNCIA + CONTEXTO + NEXO

Mas a fotografia pode dizer ao investigador:

“Comece a procurar aqui.”

Bem-vindo ao OSINT.


📸 6. As redes sociais são o SMF da vida moderna

Durante décadas nós, profissionais de mainframe, aprendemos algo básico:

o sistema deixa rastros.

SMF.

Logs.

JES.

RACF.

Auditoria.

Datas.

USER-IDs.

Transações.

Hoje existe outro gigantesco sistema de logging.

Instagram.

Facebook.

LinkedIn.

X.

YouTube.

As pessoas voluntariamente documentam:

onde estavam,

com quem estavam,

quando estavam,

qual avião utilizaram,

qual restaurante frequentaram,

qual evento patrocinaram,

quem estava na mesa,

quem recebeu homenagem,

quem foi ao casamento.

É quase um:

SMF Social.

E políticos deveriam aprender uma lição interessante.

Não adianta imaginar que uma fotografia publicada em 2022 desapareceu porque ninguém se lembrará dela em 2026.

Alguém salvará.

Alguém encontrará.

Um mecanismo de busca indexará.

Uma IA correlacionará.

A pergunta correta não é:

“Como apagar meu passado?”

É:

“Consigo explicar minhas relações quando meu passado reaparecer?”


🇧🇷 7. E então chegamos à família Bolsonaro

Aqui o grafo ganhou novas arestas.

A conexão mais documentada aparece com Flávio Bolsonaro.

Conversas divulgadas pela imprensa indicaram negociação de financiamento para Dark Horse, produção cinematográfica sobre Jair Bolsonaro.

Segundo material revelado nas investigações e reportagens, Vorcaro teria destinado dezenas de milhões de reais ao projeto.

Isso muda a natureza da conexão.

Não estamos falando apenas de:

"tiraram uma fotografia juntos"

Estamos falando de:

FLÁVIO
   ↓
conversa
   ↓
VORCARO
   ↓
financiamento
   ↓
DARK HORSE
   ↓
filme sobre
   ↓
JAIR BOLSONARO

Ainda assim, a disciplina investigativa continua valendo.

Relacionamento financeiro não prova automaticamente corrupção.

Financiamento de projeto privado não é automaticamente ilícito.

É necessário investigar:

origem do dinheiro,

destino,

contratos,

contrapartidas,

beneficiários,

eventuais recursos públicos,

declarações,

mensagens,

decisões posteriores.

Follow the money.


🏛️ 8. Direita, esquerda e o erro da explicação confortável

Em determinado momento surgiu uma pergunta inevitável:

se a direita tivesse continuado no poder, o Master teria estourado?

Não sabemos.

Esse é um contrafactual impossível de provar diretamente.

Mas podemos investigar a hipótese.

Vorcaro possuía conexões importantes em ambientes da direita e centro-direita.

Ao mesmo tempo, o caso acabou alcançando personagens e instituições muito além de uma única corrente política.

Talvez isso revele algo mais sofisticado.

Um operador racional não precisa apostar exclusivamente em:

PARTIDO A

Pode construir:

             PODER
               │
       ┌───────┼───────┐
       ↓       ↓       ↓
    DIREITA  CENTRO  INSTITUIÇÕES
       │       │       │
       └───────┼───────┘
               ↓
             ACESSO

Em finanças chamamos isso de hedge.

Diversificação de risco.

Talvez também exista hedge político.

Isso não prova que tenha ocorrido dessa maneira.

Mas é uma excelente hipótese para investigar.


💰 9. O Master era uma pirâmide financeira?

Essa pergunta também apareceu.

Minha resposta continua sendo:

juridicamente, não podemos simplesmente chamar o Master de pirâmide financeira.

Era uma instituição bancária autorizada e supervisionada.

Possuía negócios e ativos reais.

Mas determinados aspectos econômicos podem lembrar a dinâmica de estruturas que dependem continuamente de dinheiro novo.

O Master tornou-se conhecido pela oferta de CDBs com remunerações bastante agressivas.

Simplificando:

NOVOS CDBs
    ↓
DINHEIRO NOVO
    ↓
COMPRA / FINANCIA ATIVOS
    ↓
NECESSIDADE DE LIQUIDEZ
    ↓
NOVOS CDBs
    ↓
DINHEIRO NOVO

Enquanto a captação funciona, a máquina respira.

Quando a confiança desaparece:

MENOS CONFIANÇA
      ↓
MENOS CAPTAÇÃO
      ↓
MENOS LIQUIDEZ
      ↓
MAIS DESCONFIANÇA
      ↓
MENOS CAPTAÇÃO
      ↓
ABEND

Em novembro de 2025, o Banco Central decretou a liquidação extrajudicial do Banco Master e de outras empresas do conglomerado.

O interessante não é simplesmente dizer:

“era pirâmide.”

É perguntar:

quanto do modelo dependia da continuidade da captação para sustentar ativos de risco, baixa liquidez ou cuja qualidade posteriormente passou a ser questionada?

Essa é uma pergunta muito melhor.


🏦 10. O paradoxo da supervisão

Aqui chegamos a uma das partes mais perturbadoras.

O Master não funcionava escondido em uma sala clandestina.

Era banco.

Autorizado.

Supervisionado.

Seus produtos apareciam em plataformas financeiras.

Determinados investimentos possuíam cobertura do FGC dentro das regras e limites aplicáveis.

Para o cidadão comum:

BANCO
 ↓
BANCO CENTRAL
 ↓
FGC
 ↓
CORRETORA CONHECIDA
 ↓
CDB
 ↓
"deve ser seguro"

Isso cria algo poderoso:

legitimidade institucional.

O investidor não precisa conhecer Daniel Vorcaro.

Ele confia na arquitetura.

E justamente por isso o caso precisa produzir uma pergunta desconfortável:

por que os mecanismos de controle não impediram que os problemas alcançassem tamanho tão grande antes da intervenção?

Isso não significa que o Banco Central nada tenha feito.

Ao contrário: a supervisão identificou problemas, investigou operações, adotou medidas prudenciais e finalmente liquidou instituições do conglomerado.

A questão é temporal.

Quando os primeiros sinais apareceram?

Quando tornaram-se materialmente relevantes?

Quando seria possível intervir?

Quando deveria ter ocorrido intervenção?

Esse timeline será fundamental para compreender o caso.


💣 11. E o BRB?

Aqui aparece outra peça gigantesca.

A Polícia Federal afirma que o BRB adquiriu aproximadamente R$ 17 bilhões em créditos do Master, dos quais cerca de R$ 12,2 bilhões seriam associados a créditos consignados inexistentes.

Isso ainda envolve investigações, defesas e determinação de responsabilidades individuais.

Mas economicamente existe uma questão simples.

Quando alguém compra seu ativo:

MASTER
   │
   │ vende ativo
   ▼
  BRB
   │
   │ paga
   ▼
MASTER RECEBE LIQUIDEZ

Liquidez significa tempo.

E tempo pode signific sobrevivência.

Portanto uma das perguntas fundamentais será:

quanto determinadas operações permitiram que a máquina continuasse funcionando antes do colapso?


🏦 12. E os outros bancos?

Essa pergunta me incomodou bastante.

Onde estavam os bancos tradicionais?

Por que aparentemente tão pouco barulho?

Seria um silêncio de “parças”?

Não temos evidência para afirmar isso.

Aliás, posteriormente apareceram conflitos importantes entre Vorcaro e figuras do sistema bancário tradicional.

Mas existe uma explicação institucional talvez ainda mais inquietante:

cada participante possuía incentivo para cuidar somente da própria parte.

PLATAFORMA
"estou ganhando comissão"

INVESTIDOR
"tenho FGC"

BANCO CONCORRENTE
"é problema do BC"

REGULADOR
"estou supervisionando"

POLÍTICO
"é banco autorizado"

MASTER
"continuo captando"

Ninguém precisa conspirar.

Basta ninguém puxar o disjuntor.


🛡️ 13. FGC e o problema do risco moral

Aqui entramos em economia clássica.

O FGC é importantíssimo.

Ele ajuda a proteger depositantes e a confiança no sistema financeiro.

Mas toda garantia pode produzir moral hazard, ou risco moral.

Imagine:

BANCO A

captação conservadora
juros menores
crescimento moderado


BANCO B

captação agressiva
juros maiores
crescimento explosivo

O investidor olha:

“Ambos possuem FGC dentro dos limites.”

Então o Banco B consegue oferecer retorno maior sem que o investidor perceba integralmente a diferença de risco.

Se tudo funcionar:

LUCRO → PRIVADO

Se tudo explodir:

PARTE DA PERDA → SISTEMA DE GARANTIA

Esse desenho exige controles extraordinários.


🧓 14. E foi então que lembrei do FGTS dos anos 1970 e 1980

Durante nossa conversa uma memória antiga apareceu.

Naquela época, as contas vinculadas do FGTS estavam distribuídas entre diversos bancos.

Existe um relato que ouvi sobre empréstimos cruzados.

Segundo esse relato — e faço questão de marcar isto como relato ainda não documentalmente comprovado — determinados bancos não poderiam utilizar diretamente determinados recursos vinculados para financiar sua própria expansão.

Então surgiria uma engenharia:

BANCO A
não pode financiar A
     │
     └────────► financia B

BANCO B
não pode financiar B
     │
     └────────► financia A

Resultado econômico:

A ajuda A

B ajuda B

por intermédio um do outro.

O relato específico que guardo é de Bradesco e Itaú utilizando operações dessa natureza para ajudar a financiar expansão de suas redes de agências.

Ainda preciso encontrar documentação histórica que confirme exatamente esse mecanismo.

Mas o paralelo conceitual é delicioso.

Uma operação pode obedecer formalmente à regra e, quando combinada com outra operação igualmente permitida, produzir exatamente o resultado que a regra pretendia evitar.

O auditor não deveria perguntar somente:

IF OPERACAO-A = LEGAL
    DISPLAY 'OK'.

Ele deveria executar:

COMPUTE RESULTADO =
       OPERACAO-A
     + OPERACAO-B
     + OPERACAO-C.

IF RESULTADO = REGRA-CONTORNADA
    DISPLAY 'OPA...'.

É aí que começa auditoria de verdade.


📱 15. Projeto DV e a guerra da narrativa

Outra camada do Caso Master levou nossa história para um território diferente.

A Polícia Federal passou a investigar uma suposta operação de influência envolvendo jornalistas, influenciadores e perfis de redes sociais.

A investigação descreveu o chamado Projeto DV.

Segundo a investigação, pessoas teriam sido recrutadas para produzir ou difundir narrativas favoráveis ao Master e críticas ao Banco Central.

Há relatos de propostas financeiras elevadas e acordos de confidencialidade.

Aqui novamente:

investigação não é condenação.

Mas o conceito é fascinante.

Antigamente, poder significava controlar dinheiro.

Depois significou controlar informação.

Hoje existe outra camada:

controlar a interpretação da informação.

FATO
 ↓
NARRATIVA
 ↓
INFLUENCIADORES
 ↓
ALGORITMO
 ↓
MILHÕES DE PESSOAS
 ↓
PERCEPÇÃO

E percepção influencia comportamento.

Investidor mantém dinheiro.

Político reage.

Autoridade sente pressão.

Jornalista recebe ataques.

Mercado muda expectativas.


🗄️ 16. Quando dados públicos viram inteligência privada

Foi talvez o ponto que mais me assustou.

Investigações passaram a mencionar acessos indevidos ou suspeitos a sistemas governamentais e informações restritas.

PF.

MPF.

Polícias.

Banco Central.

Em alguns casos discute-se uso indevido de credenciais; em outros, comprometimento de conta por phishing.

Isso exige enorme cuidado.

Um acesso realizado com USER-ID legítimo não significa necessariamente:

“o servidor vendeu a informação.”

Pode significar:

USUÁRIO CORROMPIDO

ou:

USUÁRIO COMPROMETIDO

São incidentes completamente diferentes.

Mas o resultado potencial é assustador.

Dados que o cidadão entrega ao Estado para uma finalidade pública podem transformar-se em inteligência privada.

Imagine alguém capaz de agregar:

DADOS PESSOAIS
      +
DADOS FINANCEIROS
      +
PROCESSOS
      +
ENDEREÇOS
      +
RELACIONAMENTOS
      +
ROTINAS
      +
INFORMAÇÕES PROFISSIONAIS

Não estou dizendo que alguém no Caso Master possuía tudo isso.

Estou dizendo que esse é o risco arquitetural revelado pelo caso.


🎯 17. Moriarty sabia onde apertar

Na série Sherlock, Moriarty não precisa necessariamente matar alguém pessoalmente.

Seu poder deriva de outra coisa:

saber qual botão apertar.

Família.

Amigos.

Reputação.

Medo.

Dinheiro.

Segredos.

É por isso que acesso indevido a dados é tão assustador.

Informação não serve apenas para descobrir crimes.

Também pode servir, em tese, para:

chantagem,

intimidação,

monitoramento,

constrangimento,

pressão.

Novamente:

possibilidade não significa evidência.

Mas sistemas de segurança precisam ser projetados considerando justamente possibilidades adversariais.

Isso é Red Team.


🔐 18. RACF não basta

Nós, mainframers, gostamos de pensar:

“Usuário autenticado. Acesso autorizado. Tudo certo.”

Não.

O Caso Master ensina algo importante.

Identidade não é finalidade.

Uma pessoa pode possuir acesso legítimo a um sistema e ainda assim realizar uma consulta ilegítima.

Portanto precisamos de:

MFA resistente a phishing,

Zero Trust,

segregação de funções,

logs imutáveis,

SIEM,

UEBA,

detecção comportamental,

justificativa para consultas sensíveis,

alertas de volume,

alertas de horário,

alertas de consultas fora do perfil funcional.

Exemplo:

SERVIDOR X
normalmente consulta:
20 registros/dia

HOJE:
847 registros

incluindo:
jornalista
banqueiro
político
empresário

Isso deveria acender uma árvore de Natal no SOC.


⚰️ 19. Sicário

Então chegamos a uma das partes mais delicadas desta história.

Luiz Phillipi Machado de Moraes Mourão, chamado de Sicário em materiais da investigação, foi preso em março de 2026.

Horas depois tentou suicídio enquanto estava sob custódia da Polícia Federal.

Morreu posteriormente no hospital.

A Polícia Federal investigou sua morte e concluiu que ocorreu suicídio, sem participação externa, analisando câmeras, perícias, testemunhos e outros elementos.

Esse é o fato institucional disponível.

Portanto:

não há base para afirmar que Mourão foi assassinado.

Mas durante nossa conversa surgiu uma pergunta hipotética interessante.

Uma câmera pode demonstrar que ninguém entrou fisicamente numa cela.

Mas poderia excluir uma ameaça realizada antes da prisão?

Por exemplo:

“Se algum dia você for preso...”

Teoricamente, não.

Isso não significa que tenha acontecido.

Significa somente que:

AUSÊNCIA DE EVIDÊNCIA
      ≠
EVIDÊNCIA DE AUSÊNCIA

Mas precisamos acrescentar imediatamente:

POSSIBILIDADE
      ≠
PROBABILIDADE

Para elevar essa hipótese seria necessário encontrar:

mensagens anteriores,

ameaças,

instruções,

pressões familiares,

pagamentos,

ordens de silêncio,

testemunhas,

documentos.

Sem isso, permanece especulação.

E deve continuar na gaveta marcada:

ESPECULAÇÃO.


💾 20. O operador morreu. O log não.

Aqui está uma das maiores diferenças entre Moriarty e o século XXI.

Moriarty podia eliminar uma pessoa.

Mas hoje existe:

telefone,

backup,

cloud,

PIX,

CFTV,

GPS,

metadata,

logs,

e-mail,

mensagens,

extratos,

ERBs,

registros de voo,

fotografias,

bancos de dados.

Portanto:

Mourão morreu. O log não.

Essa talvez seja uma das frases fundamentais do Caso Master.

Pessoas desaparecem.

Dados permanecem.


🧊 21. O iceberg

Durante nossa conversa apareceu inevitavelmente a imagem do iceberg.

Sabemos que existe uma parte submersa.

Mas existe uma armadilha intelectual.

Não sabemos qual é o formato dela.

          VISÍVEL
        __________
       /          \
~~~~~~/~~~~~~~~~~~~\~~~~~~
     /              \
    /       ?        \
   /     ?     ?      \
  /   ?           ?    \
 /______________________\

É legítimo dizer:

“Ainda há coisas que não conhecemos.”

Não é legítimo dizer:

“Como ainda há coisas desconhecidas, minha teoria sobre elas está correta.”

Essa diferença separa investigação de conspiração.


🔎 22. A metodologia Bellacosa

Eu criaria cinco colunas.

COMPROVADO

Documento.

Extrato.

Contrato.

Decisão oficial.

Registro.

ALEGAÇÃO OFICIAL

PF afirma.

MP afirma.

BC afirma.

CVM afirma.

Ainda sujeito a defesa, contraditório e julgamento quando aplicável.

INDÍCIO

Elemento que aponta uma direção, mas não encerra a questão.

HIPÓTESE

Explicação compatível com os indícios e que pode ser testada.

ESPECULAÇÃO

Possibilidade sem evidência suficiente.

Nunca mova algo da coluna 5 para a coluna 1 porque parece fazer sentido.


🧠 23. O erro humano mais perigoso: JOIN sem chave

Nosso cérebro adora fazer isso.

SELECT *
FROM RUMORES R
JOIN MEMORIAS M
JOIN FOTOS F
JOIN POLITICOS P
JOIN EMPRESARIOS E;

Resultado:

“Caramba! Está tudo conectado!”

😂

Calma.

Precisamos da chave.

ON EVIDENCIA_DOCUMENTAL

Sem ela temos produto cartesiano.

Milhões de combinações aparentemente interessantes e pouquíssima verdade.


🏛️ 24. Quem investiga o investigador?

O Caso Master também expõe outro problema institucional.

O que acontece quando uma investigação alcança pessoas situadas perto do topo das instituições responsáveis por investigar?

Judiciário.

Ministério Público.

Polícia.

Reguladores.

Políticos.

Não estou afirmando culpa de ninguém.

Estou apontando um problema arquitetural.

Todo sistema crítico precisa de:

OPERADOR
   ↓
SUPERVISOR
   ↓
AUDITOR
   ↓
AUDITOR DO AUDITOR

No mainframe isso parece óbvio.

Ninguém deveria possuir:

SPECIAL
OPERATIONS
AUDITOR

e simultaneamente poder apagar todos os próprios logs.

No Estado deveria ser igualmente óbvio.


🧾 25. Talvez precisemos de uma SOX brasileira

Depois da Enron, os Estados Unidos produziram a Sarbanes-Oxley.

Talvez o Brasil precise aproveitar o Caso Master para criar uma arquitetura muito mais forte de transparência entre dinheiro e Estado.

Eu gostaria de ver:

registro público de lobby,

agenda pesquisável de autoridades,

rastreabilidade de reuniões entre regulados e reguladores,

regras claras sobre presentes e viagens,

cooling-off entre regulador e regulado,

regras transparentes para contratos envolvendo familiares de autoridades,

proteção efetiva a whistleblowers,

beneficiário final identificável,

monitoramento contínuo de conflitos de interesse,

logs invioláveis de consultas a bases governamentais.

Em resumo:

DINHEIRO DEIXA RASTRO

ACESSO DEIXA RASTRO

INFORMAÇÃO DEIXA RASTRO

INFLUÊNCIA DEIXA RASTRO

DECISÃO DEIXA JUSTIFICATIVA

🧱 26. No meu mainframe isso não passaria

Há décadas defendemos colocar no topo de um programa:

USER-ID
DATA
ALTERAÇÃO
MOTIVO

Estamos falando de um programa COBOL.

Por que decisões envolvendo bilhões de reais e interesses públicos deveriam possuir menos rastreabilidade?

Se alguém alterar uma regra:

quem?

quando?

por quê?

a pedido de quem?

quem se beneficiou?

Essa deveria ser a filosofia de auditoria do Estado.


🕵️ 27. Talvez Vorcaro nem precise ser Moriarty

E aqui chegamos à conclusão mais interessante.

Talvez procurar um grande vilão central seja justamente nosso erro.

Talvez não exista uma sala secreta onde vinte pessoas decidem tudo.

Talvez o sistema funcione porque cada nó possui seu próprio incentivo.

BANQUEIRO
quer crescer

PLATAFORMA
quer comissão

INVESTIDOR
quer juros

POLÍTICO
quer apoio

EMPRESÁRIO
quer negócio

INFLUENCIADOR
quer dinheiro/audiência

INSTITUIÇÃO
quer recursos

BANCO CONCORRENTE
cuida do próprio negócio

REGULADOR
segue seu processo

Cada pessoa executa seu pequeno JOB.

E então o JES scheduler da realidade cria algo que ninguém isoladamente precisou planejar.

Essa hipótese é assustadora.

Porque prender Moriarty resolveria o problema de Moriarty.

Mas como prender uma arquitetura de incentivos?


🕸️ 28. E se Vorcaro fosse apenas um usuário da rede?

Outra pergunta surgiu durante nossa conversa.

Se Daniel Vorcaro desaparecer amanhã da equação, as conexões desaparecem?

Políticos deixam de conhecer empresários?

Advogados deixam de conhecer ministros?

Pastores deixam de conhecer políticos?

Influenciadores deixam de conhecer assessores?

Banqueiros deixam de conhecer reguladores?

Claro que não.

Então talvez algumas redes precedam Vorcaro e sobrevivam a ele.

Isso permitiria uma hipótese fascinante:

NÃO:

VORCARO
  ↓
CRIOU TODA A REDE


TALVEZ:

REDE EXISTENTE
      ↕
   VORCARO
      ↕
AMPLIOU / UTILIZOU /
CONECTOU PARTES DELA

Ainda é hipótese.

Mas é uma pergunta muito mais inteligente do que procurar uma única organização secreta controlando Brasília.


🧬 29. Poder é um grafo

Talvez essa seja a principal conclusão deste artigo.

Durante muito tempo imaginamos poder como uma pirâmide:

        PRESIDENTE
           ↓
       MINISTROS
           ↓
      AUTORIDADES
           ↓
        RESTO

O mundo moderno funciona cada vez menos assim.

Poder parece um grafo:

        A──────B
       / \    / \
      C───D──E───F
       \ /    \ /
        G──────H

Alguns nós possuem dinheiro.

Outros possuem informação.

Outros possuem autoridade.

Outros possuem audiência.

Outros possuem reputação.

Outros possuem acesso.

O indivíduo realmente poderoso pode ser simplesmente aquele capaz de atravessar vários desses mundos.


🎻 30. Professor Moriarty em Brasília

Sherlock Holmes queria descobrir quem estava atrás dos crimes.

Nós precisamos fazer uma pergunta ligeiramente diferente:

Que arquitetura permitiu que tantas relações diferentes se aproximassem do mesmo ecossistema financeiro?

Não basta investigar Daniel Vorcaro.

Precisamos compreender:

como o banco captava,

quem distribuía,

quem lucrava,

quem financiava,

quem comprava ativos,

quem apresentava pessoas,

quem produzia narrativas,

quem consultava dados,

quem sabia dos riscos,

quando soube,

o que fez depois de saber.

Isso é muito maior que:

“Quem é amigo de quem?”

É:

“Como o sistema funcionava?”


☕ Epílogo — Sherlock abriria o SMF

Se Sherlock Holmes trabalhasse no Caso Master, provavelmente não começaria interrogando Daniel Vorcaro.

Sentaria diante de um terminal.

Pegaria um café.

Abriria os logs.

Construiria uma timeline.

Depois construiria um grafo.

PESSOA
  ↓
EMPRESA
  ↓
CONTA
  ↓
PIX
  ↓
FUNDO
  ↓
AERONAVE
  ↓
EVENTO
  ↓
FOTOGRAFIA
  ↓
MENSAGEM
  ↓
REUNIÃO
  ↓
DECISÃO

Então perguntaria:

“Quem apareceu repetidamente no critical path?”

Porque essa é a diferença entre procurar culpados e compreender sistemas.

O Caso Master ainda está sendo investigado. Pessoas mencionadas possuem direito de defesa. Diversas acusações permanecem sem julgamento definitivo. Novas evidências podem confirmar algumas hipóteses e destruir outras.

Portanto seria irresponsável encerrar esta história dizendo:

“Descobrimos Moriarty.”

Não descobrimos.

Talvez nem exista um.

O que descobrimos é algo muito mais interessante — e potencialmente muito mais perigoso.

Uma arquitetura.

Uma arquitetura na qual dinheiro compra proximidade, proximidade gera confiança, confiança abre portas, portas produzem informação, informação gera influência e influência pode produzir ainda mais dinheiro.

O verdadeiro adversário de Sherlock Holmes talvez não fosse simplesmente Moriarty.

Era a rede.

E o grande desafio brasileiro depois do Caso Master não será apenas descobrir quem cometeu quais crimes.

Será garantir que, quando o próximo operador começar a montar uma rede semelhante, nossos sistemas consigam perceber o padrão antes do ABEND.

Porque existe uma velha verdade que qualquer operador de mainframe conhece:

Você pode encerrar o JOB.

Pode cancelar o USER-ID.

Pode desmontar a aplicação.

Mas, se a arquitetura que permitiu o problema continuar intacta, outro JOB ocupará o initiator.

E tudo começará novamente.

Moriarty pode morrer.

A rede não.

sábado, 12 de setembro de 2026

👄 COBOL Horror Picture Show — Frank-N-Furter e a Estranha Arte de Modernizar sem Matar a Criatura

 

Bellacosa Mainframe e a modernização do cobol

☕ Um Café no Bellacosa Mainframe

👄 COBOL Horror Picture Show — Frank-N-Furter e a Estranha Arte de Modernizar sem Matar a Criatura

“Don’t dream it. Be it.” — e, se estiver em produção há quarenta anos, talvez seja melhor descobrir primeiro todas as dependências antes de tentar transformá-lo.

Há alguma coisa deliciosamente apropriada em colocar Frank-N-Furter, de The Rocky Horror Picture Show, diante de uma arquitetura de modernização COBOL.

Pense na cena.

No centro do laboratório existe uma aplicação COBOL.

Ela é antiga.

Muito antiga.

Há décadas recebe transações, abre arquivos, atualiza bancos de dados, processa lotes durante a madrugada e alimenta sistemas que provavelmente nem existiam quando sua primeira versão foi compilada.

Em volta dela aparecem engenheiros carregando Git, Jenkins, Terraform, Ansible, AWS EC2, RDS, Secrets Manager e CloudWatch.

Luzes piscam.

Pipelines começam a executar.

Playbooks descem do Git.

EC2s surgem.

O banco ganha vida.

E alguém grita:

“IT'S ALIVE!”

Calma.

Frank-N-Furter ficaria encantado.

Eu ficaria procurando o JCL.

Porque existe uma diferença monumental entre fazer um programa COBOL executar em outro lugar e modernizar o sistema empresarial do qual aquele programa faz parte.

E é justamente essa diferença que vamos explorar.

Bem-vindo ao laboratório.



🎭 1. Antes de tudo: conheça o Dr. Frank-N-Furter

The Rocky Horror Picture Show nasceu como adaptação cinematográfica do musical The Rocky Horror Show, criado por Richard O'Brien, e chegou aos cinemas em 1975.

No centro daquela insanidade musical está o Dr. Frank-N-Furter, interpretado por Tim Curry.

Cientista.

Showman.

Manipulador.

Extravagante.

E, sobretudo, criador.

Frank não quer simplesmente estudar aquilo que existe.

Ele quer construir sua própria criatura.

Rocky nasce dentro do laboratório como materialização dessa ambição.

E é exatamente por isso que Frank é nosso tutor perfeito para esta conversa.

Modernização de sistemas também pode sofrer da síndrome de Frank-N-Furter:

ficamos tão fascinados com nossa capacidade de construir alguma coisa nova que esquecemos de perguntar se entendemos completamente aquilo que estamos substituindo.



⚡ 2. Há uma criatura COBOL sobre a mesa

Nossa arquitetura começa com algo aparentemente simples:

COBOL
   +
AWS EC2
   +
AWS RDS
   +
Ansible
   +
Terraform
   +
CI/CD

A proposta é elegante.

Temos ambientes:

DEV
 ↓
SIT
 ↓
UAT
 ↓
PRE-PROD
 ↓
PROD

Terraform provisiona infraestrutura.

Ansible configura máquinas e instala o ambiente necessário.

O pipeline controla o processo.

RDS fornece banco de dados gerenciado.

Git preserva código e configuração.

CloudWatch observa o ambiente.

Excelente.

Mas Frank-N-Furter aproxima-se da mesa, levanta o lençol e pergunta:

“Isso é realmente tudo que existe dentro da criatura?”

Não.

Quase nunca.



🧟 3. COBOL não é o monstro

Esta talvez seja a primeira grande inversão que precisamos fazer.

Quando alguém anuncia:

“Temos uma aplicação COBOL de quarenta anos.”

muita gente imediatamente imagina que encontrou o problema.

Não encontrou.

Encontrou uma linguagem.

O problema real pode estar em tudo aquilo que cresceu ao redor dela:

                COBOL
                  │
       ┌──────────┼──────────┐
       │          │          │
      CICS       IMS        Db2
       │          │          │
      VSAM       MQ        Stored
       │                   Procedures
       │
      JCL
       │
   Scheduler
       │
 GDG / datasets

Depois aparecem:

SORT
IDCAMS
REXX
PROCs
copybooks
utilities
FTP/SFTP
APIs
arquivos externos
interfaces
sistemas parceiros

Então alguém encontra um programa:

CALL 'XPTO123'

Ótimo.

Onde está XPTO123?

Ninguém sabe.

Até que aquele senhor sentado no fundo da sala fala:

“Ah... isso chama uma rotina que o Pereira escreveu em 1997.”

Onde está Pereira?

Aposentado.

Documentação?

Não existe.

Código?

Está numa load library.

Bem-vindo ao castelo.


🔬 4. “I can make you a man” — recompilar não significa modernizar

Imagine que conseguimos pegar determinado programa COBOL e compilá-lo para execução em Linux numa instância EC2.

Fantástico.

COBOL/zOS
    │
    ▼
COBOL/Linux
    │
    ▼
AWS EC2

A aplicação executa.

Então:

“IT'S ALIVE!”

Sim.

Mas cuidado.

Fizemos replatforming.

Talvez isso seja exatamente aquilo que o projeto necessita. Não há absolutamente nada de errado com replatforming.

O erro está em chamar qualquer mudança de plataforma de transformação completa.

A lógica pode continuar praticamente igual.

O código pode continuar COBOL.

O que mudou foi o ambiente no qual ele vive.

É como Rocky.

Frank criou um homem.

Mas criar um corpo funcionando não resolveu automaticamente todos os problemas do castelo.


🏗️ 5. Terraform constrói o laboratório

Vamos separar responsabilidades.

Terraform pode assumir a infraestrutura:

Terraform
    │
    ├── VPC
    ├── Subnets
    ├── Security Groups
    ├── EC2
    ├── IAM
    ├── RDS
    └── outros recursos

Pense nele como quem prepara o laboratório.

Mesa instalada.

Eletricidade ligada.

Tanque montado.

Cabos conectados.

Máquinas posicionadas.

Mas Terraform não deveria necessariamente decidir cada detalhe de configuração da criatura.

Para isso entra outro personagem.


🧰 6. Ansible entra usando salto alto

Ansible entra no laboratório dizendo:

“Deixem a configuração comigo.”

E começa.

EC2
 ↓
pacotes do sistema operacional
 ↓
COBOL compiler/runtime
 ↓
environment variables
 ↓
aplicação
 ↓
configuração
 ↓
database connectivity
 ↓
services
 ↓
health checks

É aqui que a arquitetura original fica realmente interessante.

Não precisamos ter um processo artesanal para DEV, outro para SIT, outro para UAT e um ritual secreto conhecido apenas por dois operadores para PRE-PROD.

Temos automação reutilizável.

Algo conceitualmente assim:

             ANSIBLE ROLE
                  │
       ┌──────────┼──────────┐
       │          │          │
      DEV        SIT        UAT
                              │
                              ▼
                          PRE-PROD

A receita permanece.

Os ingredientes variáveis são separados.


🧓 7. O programador COBOL olha para group_vars e começa a rir

Aqui temos uma das minhas partes favoritas.

A turma DevOps explica:

“Nós separamos a lógica da automação dos parâmetros específicos do ambiente.”

O programador COBOL responde:

“Parâmetros?”

Sim.

DEV pode ter:

DB = APP_DEV
PORT = 1521
ENDPOINT = dev-database

SIT:

DB = APP_SIT
PORT = 1521
ENDPOINT = sit-database

UAT:

DB = APP_UAT
PORT = 1521
ENDPOINT = uat-database

O playbook continua fundamentalmente o mesmo.

Para alguém vindo do mainframe, isso não deveria parecer ficção científica.

Nós passamos décadas trabalhando com conceitos semelhantes através de:

JCL
PROCs
symbolic parameters
PARMLIB
SYSIN
DD statements

Mudam as ferramentas.

A ideia de externalizar configuração é muito mais antiga que os slides modernos que a apresentam.

Frank-N-Furter provavelmente acrescentaria glitter.


👄 8. “Don’t dream it. Be it.” — Infrastructure as Code

Aqui encontramos uma mudança genuinamente poderosa.

Durante décadas tivemos infraestrutura e configuração documentadas mais ou menos assim:

“Instalar pacote X, editar arquivo Y, trocar parâmetro Z, reiniciar serviço e telefonar para Carlos se não funcionar.”

Carlos sai da empresa.

Fim da documentação.

Infrastructure as Code transforma parte desse conhecimento operacional em algo executável.

CONHECIMENTO
     ↓
    CODE
     ↓
Version Control
     ↓
Automation
     ↓
Environment

Isso é importante.

Código pode ser:

revisado, versionado, comparado, testado, auditado e reproduzido.

O conhecimento deixa de existir exclusivamente na memória do operador.


🧪 9. DEV → SIT → UAT → PRE-PROD

Agora Frank conduz nossa criatura pelos diferentes aposentos do castelo.

DEV

Aqui desenvolvemos e realizamos os primeiros testes.

SOURCE
  ↓
BUILD
  ↓
TEST
  ↓
DEPLOY

SIT

System Integration Testing.

Aqui descobrimos uma verdade universal da informática:

Tudo funciona perfeitamente até precisar conversar com outra coisa.

Banco.

APIs.

Filas.

Serviços.

Arquivos.

Autenticação.

Sistemas externos.

UAT

User Acceptance Testing.

Agora a pergunta deixa de ser apenas:

“Funciona?”

e torna-se:

“Isso faz aquilo que o negócio realmente precisa?”

Diferença enorme.

PRE-PROD

Aqui chegamos ao ensaio geral.

E PRE-PROD deveria ser assustadoramente parecido com produção.


🏰 10. PRE-PROD precisa ser o castelo quase completo

Um PRE-PROD simplificado demais produz falsa segurança.

Precisamos considerar:

OS version
runtime version
COBOL compiler/runtime
database version
patches
CPU architecture
memory
network
TLS
IAM
filesystem
locale
encoding
timezone
batch
integrations
security policies

Quanto mais diferente de PROD, mais perguntas surgem.

Imagine:

UAT
COBOL Runtime 8.0

PROD
COBOL Runtime 7.4

Funcionou no UAT.

Que maravilhoso.

Mas você não testou produção.

Testou outra coisa.


📦 11. Está faltando um personagem importante: o artefato

Aqui eu faria uma alteração importante na arquitetura.

Não gosto da ideia de recompilar arbitrariamente a aplicação em cada ambiente.

Prefiro:

          SOURCE
             │
             ▼
           BUILD
             │
             ▼
            TEST
             │
             ▼
      ARTIFACT REPOSITORY
             │
     ┌───────┼─────────┐
     ▼       ▼         ▼
    DEV     SIT       UAT
                       │
                       ▼
                   PRE-PROD
                       │
                       ▼
                     PROD

Isso nos leva a um princípio extremamente poderoso:

Build once, deploy many.

Produzimos uma criatura.

Depois submetemos aquela mesma criatura aos testes.

Não fazemos Rocky 1 para DEV, Rocky 2 para SIT, Rocky 3 para UAT e Rocky 4 para produção esperando que todos sejam geneticamente idênticos.


🕵️ 12. A pergunta do auditor

Imagine uma mudança chegando a produção.

O auditor pergunta:

“Esse binário é exatamente aquele homologado?”

Se cada ambiente recompila:

SOURCE
 ↓
DEV BUILD

SOURCE
 ↓
SIT BUILD

SOURCE
 ↓
UAT BUILD

SOURCE
 ↓
PROD BUILD

temos quatro processos de construção.

Mesmo que tudo pareça igual, aumentamos nossa superfície de dúvida.

Com artefato imutável:

SOURCE
 ↓
BUILD
 ↓
ARTIFACT 7.3.17
 ↓
DEV
 ↓
SIT
 ↓
UAT
 ↓
PRE-PROD
 ↓
PROD

agora existe uma cadeia muito mais clara.


🔐 13. Sweet Transvestite não significa senha escrita no YAML

Chegamos aos secrets.

Nunca faça:

database_password: "senha_supersecreta123"

e depois:

git commit

Parabéns.

Você acaba de transformar seu Git em museu arqueológico de credenciais.

A arquitetura corretamente menciona mecanismos como Ansible Vault e AWS Secrets Manager.

O princípio é:

CODE ≠ SECRET

Idealmente:

CI/CD
   │
   ▼
IAM / temporary authorization
   │
   ▼
Secrets Manager
   │
   ▼
Runtime

O segredo aparece apenas onde e quando precisa aparecer.


🧛 14. Privilégio mínimo: nem Frank deveria ter acesso a tudo

Outro princípio:

Developer ≠ Production Admin
Application ≠ Database Admin
Pipeline ≠ Unlimited AWS Administrator

Cada componente recebe apenas aquilo de que necessita.

Isso é least privilege.

Se determinado processo precisa consultar um segredo, não existe razão automática para permitir que consulte todos.

Se uma aplicação precisa acessar determinado banco, não significa que deva possuir poder administrativo sobre ele.

É o equivalente moderno de algo que o pessoal RACF conhece muito bem:

Quem é você e por que exatamente precisa acessar isso?


🗄️ 15. RDS parece simples até começarmos a falar de Db2

A imagem permite Oracle/PostgreSQL como exemplos.

Tudo bem.

Mas um cenário vindo de mainframe pode envolver:

COBOL
  +
Db2 for z/OS

E alguém inevitavelmente pensa:

Db2 → Db2

Então deve ser simples.

Ah, meu jovem Brad...

Não necessariamente.

Db2 for z/OS
      ≠
Db2 LUW
      ≠
RDS for Db2

Existe parentesco tecnológico.

Não existe identidade operacional perfeita.

Precisamos investigar SQL utilizado, stored procedures, utilities, comportamento transacional, autorização, integração e características específicas da plataforma.

O banco pode carregar tanta arqueologia quanto o COBOL.


🗃️ 16. E o VSAM?

Agora Frank encontra um arquivo VSAM no porão.

Silêncio.

Se a aplicação original utiliza:

KSDS
ESDS
RRDS

precisamos responder:

Para onde esses dados vão?

RDS?

Arquivos?

Outro datastore?

Mantemos comportamento equivalente?

E principalmente:

a aplicação depende semanticamente da organização original?

Não basta exportar registros e dizer:

“Migrei.”

Dados possuem comportamento.

Chaves.

Ordenação.

Concorrência.

Locking.

Integridade.

Performance.

Tudo isso importa.


📜 17. E o JCL?

Aqui está uma das grandes vítimas dos diagramas bonitos de modernização.

Pegamos o COBOL.

Migramos.

E esquecemos que às 02:00 existe isto:

JOB A
 ↓
JOB B
 ↓
JOB C ─── JOB D
   │
   ▼
 JOB E
   │
   ▼
 JOB F

Existem dependências.

Calendários.

Arquivos.

Condições.

Return codes.

Restart.

Checkpoints.

SLA.

Janelas de processamento.

O JCL talvez desapareça.

A necessidade que ele implementava não desaparece.

Alguma outra coisa precisará orquestrar aquilo.


⏰ 18. O batch não quer saber que agora você é cloud

Imagine um processamento que precisa terminar até 06:00.

No mainframe:

23:00 START
...
05:31 END

Migramos para AWS.

Agora:

23:00 START
...
06:47 END

Tecnicamente funciona.

Funcionalmente funciona.

Os resultados estão corretos.

E mesmo assim:

A MIGRAÇÃO FALHOU.

Porque o negócio precisava dos dados às 06:00.

Essa é uma lição gigantesca.

Compatibilidade funcional não é suficiente.

Precisamos de compatibilidade operacional.


📊 19. CloudWatch não deveria ficar decorando o canto do desenho

Observabilidade precisa atravessar toda a solução.

Não basta:

EC2 = UP
RDS = UP

Enquanto:

Pedidos processados = ZERO

Infraestrutura saudável não significa aplicação saudável.

Precisamos enxergar:

CPU
memory
disk
network
database latency
connections
locks
errors
transaction rate
response time
batch duration
business transactions

E aqui o veterano do mainframe reconhece novamente uma velha ideia.

O importante não é saber apenas:

“A máquina está ligada?”

O importante é:

“O workload está entregando aquilo que deveria?”


💥 20. PRE-PROD também precisa morrer

Frank provavelmente aprovaria esta parte.

Testamos:

DATABASE ONLINE

Excelente.

Agora desligue o banco.

Testamos:

NETWORK OK

Excelente.

Agora introduza timeout.

Testamos:

DISK SPACE OK

Encha o disco.

Testamos:

PASSWORD VALID

Revogue a credencial.

Queremos descobrir:

database unavailable
network failure
bad credentials
timeout
disk full
process killed
duplicate transaction
corrupted input
rollback failure
partial deployment

Porque produção descobrirá essas condições por você.

E produção não agenda laboratório.


🔥 21. O health check mais importante talvez seja o ABEND

Um health check dizendo:

HTTP 200

é agradável.

Mas para uma aplicação empresarial eu quero saber:

Aplicação iniciou?
Banco conecta?
Fila responde?
Transação funciona?
Arquivo abre?
Batch executa?
Rollback funciona?
Restart funciona?
Dados permanecem consistentes?

Um sistema não é saudável porque existe um processo no ps.

Ele é saudável quando consegue realizar sua função.


🔄 22. Rollback precisa entrar no espetáculo

Deployment sem rollback testado é fé.

O pipeline deveria conhecer algo como:

VERSION 8.4
    │
    ▼
DEPLOY
    │
    ├── SUCCESS → continue
    │
    └── FAILURE
            │
            ▼
        VERSION 8.3
            │
            ▼
        VALIDATION

Mas existe uma complicação.

Rollback de executável é relativamente fácil.

Rollback de banco pode não ser.

Se versão 8.4 alterou schema e começou a gravar dados novos, voltar simplesmente o executável para 8.3 talvez não resolva.

Portanto deployment strategy precisa conversar com database migration strategy.


🧬 23. A criatura tem memória

Esse é outro erro frequente.

Tratamos aplicação como código.

Mas aplicações empresariais são:

CODE
 +
DATA
 +
STATE
 +
INTEGRATIONS
 +
HISTORY

Migrar código é apenas uma parte.

Migrar décadas de dados mantendo integridade pode ser o verdadeiro projeto.

Frank consegue construir outro corpo.

Transferir quarenta anos de memória para ele é outra história.


🕸️ 24. Discovery deveria aparecer antes de Terraform

Se eu redesenhasse completamente a figura, colocaria no início:

             DISCOVERY
                 │
      ┌──────────┼───────────┐
      │          │           │
    COBOL       JCL         DATA
      │          │           │
     CICS    Scheduler     VSAM
      │                      │
     IMS                    Db2
      │
      MQ
      │
 External Systems

Depois:

Dependency Mapping
       ↓
Workload Classification
       ↓
Modernization Strategy
       ↓
Architecture
       ↓
Terraform / Ansible / CI/CD

Essa ordem é fundamental.

Não escolha a ferramenta antes de compreender o problema.


🧭 25. Nem tudo precisa sair do mainframe

Aqui está outra heresia contra certas apresentações de modernização.

Podemos terminar com:

                   ENTERPRISE
                       │
           ┌───────────┴───────────┐
           │                       │
         IBM Z                    AWS
           │                       │
      COBOL/CICS                 Services
           │                       │
          Db2       ← API/MQ →     RDS
           │                       │
        Batch                    Analytics

Isso também é modernização.

Talvez seja uma modernização melhor.

Mainframe não precisa desaparecer para AWS existir.

AWS não precisa substituir IBM Z para gerar valor.

O objetivo deveria ser colocar cada workload onde faz sentido técnico, econômico e operacional.


🏎️ 26. Performance: “funciona” é uma palavra perigosíssima

Suponha que uma transação CICS respondesse em:

40 ms

A nova aplicação responde em:

480 ms

Funciona?

Sim.

É equivalente?

Talvez não.

Agora multiplique pela quantidade de transações.

Adicione network latency.

Database round trips.

APIs.

TLS.

Logs.

Tracing.

De repente aquela diferença aparentemente pequena torna-se enorme.

Modernização precisa de baseline antes da migração.

Sem baseline você termina dizendo:

“Parece mais lento.”

Isso não é engenharia.


💰 27. E existe FinOps

Outro easter egg escondido sob a mesa do laboratório.

No mainframe alguém pode reclamar:

“MIPS são caros!”

Migramos para cloud.

Então descobrimos:

EC2
RDS
storage
IOPS
snapshots
data transfer
NAT
logs
monitoring
backup
licenses
support

e percebemos que cloud não significa:

barato.

Significa principalmente:

modelo econômico diferente.

Se não medirmos consumo, uma arquitetura elasticamente maravilhosa pode gerar uma conta elasticamente maravilhosa também.


👄 28. “Don’t dream it. Be it.”

Chegamos finalmente à grande lição de Frank-N-Furter.

Não devemos ter medo de transformar sistemas.

COBOL pode viver em novas plataformas.

Pode participar de pipelines modernos.

Pode trabalhar com Git.

Pode ser automatizado com Ansible.

Pode ter infraestrutura criada com Terraform.

Pode conversar com cloud.

Pode expor APIs.

Pode entrar num processo CI/CD.

Não existe qualquer contradição nisso.

O problema começa quando confundimos modernização com maquiagem tecnológica.

Trocar:

z/OS

por:

Linux

não moderniza automaticamente arquitetura.

Trocar:

Db2

por:

PostgreSQL

não moderniza automaticamente dados.

Trocar:

JCL

por:

YAML

não moderniza automaticamente processos.

E trocar:

datacenter

por:

AWS

não moderniza automaticamente engenharia.


🧠 29. A verdadeira modernização

Para mim, modernização aparece quando conquistamos:

REPRODUCIBILITY
      +
AUTOMATION
      +
OBSERVABILITY
      +
TRACEABILITY
      +
SECURITY
      +
TESTABILITY
      +
RESILIENCE
      +
MAINTAINABILITY

Se conseguimos isso mantendo COBOL?

Excelente.

Se parte precisa ser reescrita?

Pode fazer sentido.

Se outra parte permanece no IBM Z?

Perfeitamente possível.

Se determinado workload vai para AWS?

Ótimo.

Tecnologia é consequência da decisão arquitetural.

Não deveria ser sua causa.


🥚 Easter egg — 03:17 no castelo

Naturalmente precisamos deixar uma pequena surpresa.

São 03:17 da madrugada.

O telefone toca.

Produção parou.

O dashboard está verde.

EC2:

RUNNING

RDS:

AVAILABLE

CPU:

12%

Memory:

41%

CloudWatch:

NO INFRASTRUCTURE ALARM

Mas o batch não termina.

Um engenheiro olha para outro.

Ninguém entende.

Então aparece um veterano COBOL carregando uma caneca de café.

Ele olha cinco minutos para os logs e pergunta:

“Onde está o arquivo que o JOB anterior deveria ter criado?”

Silêncio.

O arquivo não existe.

O JOB anterior terminou com RC=04.

O novo scheduler considerou RC=04 sucesso.

O sistema antigo possuía uma regra que tratava aquele retorno especificamente.

Ela nunca apareceu no diagrama de migração.

Frank-N-Furter olha para sua criatura.

A criatura olha para Frank.

E o veterano toma outro gole de café.

O COBOL havia sido migrado perfeitamente.

O conhecimento operacional, não.


☕ 30. A lição final do Bellacosa Mainframe

Há algo profundamente fascinante nesses sistemas antigos.

Quando encontramos um programa COBOL escrito em 1989, atualizado em 1997, alterado em 2008, integrado com uma API em 2019 e ainda executando em 2026, não estamos olhando simplesmente para código legado.

Estamos olhando para história empresarial executável.

Cada IF.

Cada copybook.

Cada DD.

Cada tabela.

Cada fila.

Cada estranho RC=04.

Pode existir porque alguma coisa aconteceu.

Alguém tomou uma decisão.

Algum problema ocorreu.

Alguma regra comercial nasceu.

Algum cliente reclamou.

Algum auditor exigiu.

Alguma madrugada de produção ensinou uma lição.

Por isso, quando alguém entrar no laboratório segurando Terraform numa mão e Ansible na outra, não devemos impedi-lo.

Muito pelo contrário.

Acendam as máquinas.

Preparem AWS.

Construam pipelines.

Versionem tudo.

Automatizem.

Observem.

Testem.

Modernizem.

Só não cometam o erro de Frank-N-Furter:

não fiquem tão apaixonados pela nova criatura a ponto de esquecer de compreender o mundo no qual ela terá de sobreviver.

Porque, no final, a pergunta mais importante de uma modernização COBOL não é:

“Conseguimos fazê-lo rodar na AWS?”

É:

“Conseguimos preservar quarenta anos de comportamento, regras, dependências e conhecimento — eliminando aquilo que ficou obsoleto e melhorando aquilo que realmente precisava mudar?”

Se a resposta for sim, então podem aumentar o volume.

As luzes do laboratório podem acender.

Terraform pode subir a infraestrutura.

Ansible pode executar o playbook.

Jenkins pode promover o artefato.

CloudWatch pode começar a observar.

E Frank-N-Furter finalmente poderá anunciar:

⚡ “IT'S ALIVE!”

Enquanto o velho programador COBOL, sentado discretamente no fundo do laboratório, acrescentará:

“Muito bonito. Agora vamos ver se fecha o batch antes das seis.” ☕👄⚡



 

sexta-feira, 11 de setembro de 2026

🧠 Microservices sob a Batuta de Chris Knight — Real Genius, Arquitetura e a Arte de Não Construir um Laser para Aquecer Pipoca

 

Bellacosa Mainframe apresenta microservices

☕ Um Café no Bellacosa Mainframe

🧠 Microservices sob a Batuta de Chris Knight — Real Genius, Arquitetura e a Arte de Não Construir um Laser para Aquecer Pipoca

Quando todo mundo está fascinado pela tecnologia, talvez o verdadeiro gênio seja justamente aquele que pergunta: “Legal... mas por que estamos construindo isso?”

Existe uma cena mental perfeita para explicar boa parte da arquitetura de software moderna.

Imagine uma sala cheia de engenheiros brilhantes. Há diagramas nas paredes, notebooks abertos, APIs sendo desenhadas, Kubernetes em algum canto, Kafka atravessando o desenho, containers surgindo aos montes e alguém acaba de pronunciar palavras capazes de provocar arrepios em qualquer apresentação corporativa:

“Precisamos migrar para microservices.”

Todos concordam.

Alguém acrescenta:

— E microfrontends.

Outro melhora:

— Event-driven!

Do fundo da sala:

— Service mesh!

Então aparece Chris Knight, de Real Genius, observa o quadro por alguns segundos e provavelmente pergunta:

“Tá... qual problema vocês estão tentando resolver?”

Silêncio.

E é justamente aí que começa nossa conversa.

Porque transformar um desenvolvedor em arquiteto não significa ensiná-lo a colocar mais tecnologias dentro de um desenho.

Significa ensiná-lo a questionar o desenho.

Para um programador COBOL começando a olhar para arquitetura moderna, existe uma excelente notícia: você provavelmente já conhece vários dos princípios fundamentais. Talvez apenas os conheça por outros nomes.

Pegue seu café.

Hoje vamos entrar no laboratório de Chris Knight.

E alguém, por favor, esconda a pipoca.



🎬 1. Primeiro precisamos falar sobre Real Genius

Real Genius, lançado em 1985, acompanha estudantes extremamente talentosos envolvidos em um projeto científico universitário. Chris Knight, interpretado por Val Kilmer, é um daqueles personagens que parecem estar permanentemente brincando enquanto enxergam coisas que outras pessoas não percebem.

E isso combina maravilhosamente com arquitetura.

O estereótipo do arquiteto costuma ser alguém extremamente sério diante de um enorme diagrama.

Chris Knight representa quase o contrário.

Ele domina a tecnologia, mas não é hipnotizado por ela.

Essa distinção é fundamental.

Existe uma diferença enorme entre:

saber construir algo

e

saber se aquilo deveria ser construído.

Na arquitetura corporativa encontramos frequentemente pessoas extremamente competentes resolvendo brilhantemente problemas que talvez nem precisassem existir.

Microservices são um excelente exemplo.



🧱 2. “Monólito” não é palavrão

Durante alguns anos, dizer que uma aplicação era monolítica parecia quase uma confissão.

“Nosso sistema ainda é um monólito...”

Pronunciado quase como:

“Temos ratos no datacenter.”

Mas precisamos separar duas coisas:

MONÓLITO

e:

MONÓLITO RUIM

Não são sinônimos.

Imagine:

SISTEMA DE PEDIDOS
│
├── CLIENTES
├── PRODUTOS
├── PEDIDOS
├── ESTOQUE
├── PAGAMENTOS
└── FATURAMENTO

Tudo pode existir dentro da mesma aplicação.

Isso não significa necessariamente que temos uma arquitetura ruim.

Podemos possuir módulos claramente definidos, responsabilidades separadas e interfaces controladas.

Temos então aquilo que costuma ser chamado de:

Modular Monolith.

Agora compare com:

SISTEMA
│
├── tudo acessa tudo
├── qualquer módulo altera qualquer tabela
├── regras aparecem duplicadas
├── dependências circulares
└── ninguém sabe quem é dono de quê

Isso é ruim.

Mas dividir esse segundo sistema em 50 containers não elimina magicamente seus problemas.

Talvez apenas consigamos transformar:

um monólito ruim

em:

50 pequenos pedaços ruins conversando pela rede.

Chris Knight certamente acharia isso divertido.

O pessoal de produção, provavelmente menos.



🧠 3. COBOL já ensinava modularidade antes de ela ganhar slides coloridos

Vamos colocar nosso programador COBOL iniciante diante disso.

Imagine:

       CALL 'CALCJURO'
           USING WS-SALDO
                 WS-TAXA
                 WS-JUROS.

O programa principal não precisa conhecer cada detalhe do cálculo.

Ele conhece uma interface.

Existe entrada.

Existe processamento.

Existe saída.

Isso é uma forma de separação de responsabilidade.

Podemos ter:

PROGRAMA PRINCIPAL
       │
       ├── VALIDCPF
       ├── CALCJURO
       ├── CONSULTA
       └── GRAVAPGTO

Isso não são microservices.

É importante não cair nessa simplificação.

Um subprograma COBOL normalmente não possui várias características associadas a um microservice moderno, como deployment independente, isolamento operacional, endpoint de rede próprio, escalabilidade independente e ownership autônomo.

Mas existe uma ancestralidade conceitual.

Estamos falando de:

modularidade.

coesão.

baixo acoplamento.

contratos.

Esses princípios não nasceram com Docker.


🔬 4. Chris Knight perguntaria onde está a fronteira

Agora imagine que alguém encontre:

PGM001
PGM002
PGM003
...
PGM500

e proponha:

“Vamos transformar cada programa COBOL em um microservice.”

Chris Knight provavelmente levantaria a sobrancelha.

Porque programa não é necessariamente domínio de negócio.

Um sistema bancário poderia possuir algo conceitualmente parecido com:

CONTA
├── abrir
├── consultar
├── bloquear
├── movimentar
└── encerrar

Essas operações possuem relação.

Talvez façam parte de uma capacidade coerente.

Por outro lado, transformar mecanicamente:

PGM001 → SERVICE001
PGM002 → SERVICE002
PGM003 → SERVICE003

não constitui arquitetura.

É conversão de inventário.

Uma boa fronteira deveria tentar responder:

Quem é responsável por esta capacidade?

Quais dados pertencem a ela?

Quem pode modificá-los?

Que contrato oferecemos ao restante do sistema?

Esse raciocínio nos aproxima de conceitos como bounded contexts e Domain-Driven Design.


🚪 5. Então aparece o API Gateway

Nos diagramas modernos frequentemente encontramos:

                 FRONTEND
                    │
                    ▼
              API GATEWAY
                    │
        ┌───────────┼───────────┐
        ▼           ▼           ▼
     PRODUCT      BASKET      ADVERT
     SERVICE      SERVICE     SERVICE

O gateway funciona como uma porta de entrada.

Ele pode participar de tarefas como roteamento, autenticação, autorização, controle de tráfego, transformação e observabilidade.

Isso evita que o consumidor precise conhecer detalhes demais da infraestrutura interna.

Para quem trabalha com mainframe, existe aqui uma conexão importantíssima.

Suponha:

MOBILE
   │
   ▼
REST API
   │
   ▼
API LAYER
   │
   ▼
CICS
   │
   ▼
COBOL
   │
   ▼
Db2

O aplicativo móvel não precisa saber que existe COBOL.

Aliás, ele não deveria precisar saber.

Para ele existe:

GET /accounts/123

Atrás disso pode existir uma transação CICS construída anos atrás.

Isso nos leva a uma das ideias mais importantes deste artigo:

Modernizar a interface de um sistema não exige necessariamente reescrever seu coração.


⚡ 6. “Mas microservices escalam!”

Sim.

E aqui Chris Knight provavelmente responderia:

“Qual parte precisa escalar?”

Imagine uma loja:

CATÁLOGO
50.000 req/s

PAGAMENTO
2.000 req/s

RELATÓRIOS
200 req/s

Se tudo estiver dentro de uma aplicação indivisível, talvez seja necessário escalar todo o conjunto.

Com serviços independentes, podemos ter:

CATÁLOGO
████████████████████

PAGAMENTO
████

RELATÓRIO
█

Agora temos uma vantagem concreta.

Não estamos usando microservices porque são modernos.

Estamos usando porque determinadas capacidades possuem características operacionais diferentes.

Esse é pensamento arquitetural.


🌐 7. Só existe um pequeno problema chamado rede

No COBOL podemos ter:

CALL 'VALIDA' USING WS-DADOS.

Agora transforme conceitualmente essa interação em:

SERVICE-A
    │
    │ HTTP
    ▼
SERVICE-B

Parece semelhante no PowerPoint.

Na operação, não é.

O Service B pode estar indisponível.

A rede pode estar congestionada.

O DNS pode falhar.

A resposta pode demorar.

A conexão pode cair.

A solicitação pode ser processada e a resposta se perder.

Aí Service A pensa:

“Não recebi resposta. Vou tentar novamente.”

Só que Service B executou a operação.

Parabéns.

Talvez você tenha cobrado o cliente duas vezes.


🔁 8. Bem-vindo ao maravilhoso mundo dos retries

Precisamos começar a pensar em:

timeout
retry
backoff
circuit breaker
idempotency
correlation ID
distributed tracing

Suponha:

POST /payment

A chamada chega.

O pagamento é processado.

A resposta desaparece.

O consumidor repete:

POST /payment

O sistema precisa conseguir perceber:

“Eu já processei esta operação.”

Daí surge a importância de idempotência.

Por exemplo:

IDEMPOTENCY-KEY: TX-928374

Se a mesma operação chegar novamente, podemos reconhecer que ela já aconteceu.

Observe como algo que parecia simplesmente:

A → B

acabou se tornando uma discussão arquitetural inteira.

Essa é uma das contas escondidas dos sistemas distribuídos.


💾 9. E então chegamos aos dados

Aqui começa a diversão de verdade.

Em um monólito podemos encontrar:

APPLICATION
     │
     ▼
    DB2

Uma transação pode executar várias operações e depois:

COMMIT

ou:

ROLLBACK

É uma ideia maravilhosa.

Tudo funcionou?

COMMIT.

Alguma coisa falhou?

ROLLBACK.

Agora distribua:

ORDER SERVICE
      │
      ▼
ORDER DB

PAYMENT SERVICE
      │
      ▼
PAYMENT DB

STOCK SERVICE
      │
      ▼
STOCK DB

Uma compra precisa:

criar pedido
reservar estoque
autorizar pagamento
emitir nota
solicitar entrega

Quem controla a transação?

Agora a resposta pode envolver eventos, mensagens, compensações, Saga Pattern e consistência eventual.


🍿 10. O microservice que virou laser de pipoca

Aqui está nossa metáfora Real Genius.

Imagine que o requisito fosse:

aquecer pipoca.

A primeira equipe sugere:

panela

Outra diz:

micro-ondas

Então o arquiteto extremamente entusiasmado apresenta:

satélite
     ↓
laser de alta potência
     ↓
espelho orbital
     ↓
sistema de coordenadas
     ↓
pipoca

Funciona?

Provavelmente conseguimos inventar uma maneira.

É impressionante?

Sem dúvida.

Era necessário?

Aí está a pergunta.

Em software fazemos exatamente isso.

Requisito:

600 usuários
CRUD
4 desenvolvedores
1 release mensal

Arquitetura proposta:

37 microservices
Kubernetes
Kafka
service mesh
Redis
API Gateway
15 databases
distributed tracing
GitOps
multi-cloud

E alguém precisa perguntar:

“Nós estamos construindo uma aplicação ou tentando ganhar a feira de ciências?”


🕸️ 11. O monólito distribuído

Existe uma criatura particularmente cruel.

Ela possui microservices no diagrama:

A → B → C → D → E

Mas A não consegue funcionar sem B.

B depende de C.

C depende de D.

Todos compartilham dados.

Precisam ser publicados juntos.

Uma alteração em E exige mudanças em A.

Temos então algo parecido com:

Distributed Monolith.

Conseguimos preservar o acoplamento do monólito e adicionar:

latência
rede
timeouts
deployment
containers
observabilidade
versionamento
falhas distribuídas

É quase uma obra de arte.

Chris Knight estaria impressionado.


📡 12. Observabilidade deixa de ser luxo

Imagine uma operação:

APP
 ↓
GATEWAY
 ↓
ORDER
 ↓
PAYMENT
 ↓
BROKER
 ↓
FRAUD
 ↓
BANK

Às 03:17, toca o telefone.

Easter egg encontrado. ☕

O cliente foi cobrado, mas o pedido não existe.

Agora precisamos reconstruir a viagem daquela transação.

Precisamos de algo parecido com:

TRACE-ID = ABC938271

Esse identificador acompanha a operação:

Gateway  ABC938271
Order    ABC938271
Payment  ABC938271
Fraud    ABC938271
Bank     ABC938271

Finalmente podemos reconstruir a história.

Esse é o valor do distributed tracing.

Em sistemas distribuídos, logs isolados deixam de contar a história completa.

Precisamos correlacioná-los.


🎯 13. Microservices não são principalmente uma decisão tecnológica

Aqui encontramos uma das maiores curiosidades da arquitetura.

Microservices também são uma decisão organizacional.

Imagine uma empresa com 300 desenvolvedores divididos em equipes:

CATALOG TEAM
PAYMENT TEAM
ORDER TEAM
SHIPPING TEAM
CUSTOMER TEAM

Se cada equipe puder controlar uma capacidade com ciclo próprio:

code
 ↓
test
 ↓
deploy
 ↓
operate

a independência arquitetural pode trazer enorme valor.

Agora imagine quatro desenvolvedores mantendo tudo.

Criar 40 serviços talvez não proporcione autonomia.

Talvez proporcione 40 coisas para quatro pessoas cuidarem.

Arquitetura precisa considerar a organização que vai operá-la.


🧩 14. Microfrontends repetem a experiência

Depois dos microservices alguém percebeu:

“E o frontend?”

Surge então:

Microfrontends.

Podemos ter:

BASE APPLICATION
│
├── PRODUCT
├── BASKET
└── ADVERT

Equipes diferentes podem desenvolver partes da experiência.

Em organizações enormes isso pode oferecer independência.

Mas imediatamente surgem novas perguntas.

Quem controla o design?

Quem controla as bibliotecas?

Como evitamos duplicação?

Como mantemos performance?

Como garantimos experiência consistente?

Outra vez:

Todo benefício arquitetural compra alguma complexidade.

A pergunta é se vale o preço.


🤖 15. “Micro/vibe everything” é mais perigoso do que parece

A imagem original contém uma pequena provocação maravilhosa:

Micro/vibe everything.

Em plena era da IA generativa, isso merece atenção.

Hoje podemos pedir:

“Crie 15 microservices para uma plataforma de vendas.”

E minutos depois receber:

/auth
/customer
/product
/order
/payment
/shipping
/inventory
/notification
/recommendation
...

Temos Dockerfiles.

APIs.

Testes.

YAML.

Filas.

Bancos.

Tudo parece extraordinariamente profissional.

Só existe uma questão:

Por que 15?

Talvez fossem necessários três.

Talvez oito.

Talvez nenhum.

IA reduziu dramaticamente o custo de produzir código.

Mas isso não reduz automaticamente o custo de:

possuir o código.

Alguém terá que entender, testar, proteger, atualizar, observar e recuperar aquilo.

Esta talvez seja uma das maiores mudanças para o arquiteto moderno:

Quanto mais barato fica criar complexidade, mais valiosa fica a capacidade de recusá-la.


🏛️ 16. O velho mainframe entra no laboratório

Aqui nosso programador COBOL pode sorrir.

Mainframes corporativos carregam décadas de lições sobre:

contratos
compatibilidade
transações
workload
segurança
mensageria
recuperação
disponibilidade
observabilidade

Sistemas antigos sobreviveram não porque nunca mudaram.

Sobreviveram justamente porque conseguiram mudar preservando contratos importantes.

Podemos encontrar algo como:

React
   ↓
REST
   ↓
API
   ↓
CICS
   ↓
COBOL
   ↓
Db2

E isso não deveria provocar vergonha arquitetural.

Talvez seja uma arquitetura excelente.

O frontend pode ser substituído.

A API pode evoluir.

A camada de integração pode mudar.

Enquanto isso, uma rotina COBOL comprovada durante bilhões de transações continua fazendo exatamente aquilo para que foi construída.

Chris Knight provavelmente perguntaria:

“Se funciona, escala, é seguro e atende ao negócio... exatamente por que vocês querem reescrever?”

Excelente pergunta.


🧠 17. O que realmente transforma Engineer em Architect

Não é Kubernetes.

Não é Kafka.

Não é AWS, Azure ou qualquer outra plataforma.

Não é conhecer cinquenta design patterns.

A transformação acontece quando mudamos de:

COMO CONSTRUO?

para:

POR QUE CONSTRUIR?

QUAL PROBLEMA?

QUAL ESCALA?

QUAL SLA?

QUAL CUSTO?

COMO FALHA?

COMO RECUPERA?

COMO OBSERVAMOS?

QUEM MANTÉM?

COMO EVOLUI?

QUAL É A ALTERNATIVA MAIS SIMPLES?

Um arquiteto não deveria ser simplesmente o profissional capaz de desenhar mais caixas.

Às vezes sua maior contribuição é pegar o desenho:

□ → □ → □ → □ → □
       ↓
       □
       ↓
   □ → □ → □

e perguntar:

“Podemos fazer isso com três?”


⚖️ 18. A regra Bellacosa-Chris Knight

Podemos transformar toda esta conversa em uma pequena regra:

Não escolha uma arquitetura porque consegue construí-la. Escolha porque consegue justificar sua existência.

Microservices podem ser extraordinários.

Um modular monolith também.

Event-driven architecture pode resolver problemas difíceis.

Uma chamada síncrona simples também.

Kafka pode ser fantástico.

Uma fila MQ pode continuar sendo exatamente aquilo que o problema exige.

REST pode ser perfeito.

Uma transação CICS pode estar executando sua função impecavelmente há décadas.

O arquiteto não deveria possuir religião tecnológica.

Deveria possuir critérios.


🔬 19. Passo a passo: antes de escolher microservices

Quando alguém disser:

“Precisamos de microservices.”

Faça o exercício Chris Knight.

Primeiro pergunte:

Qual problema atual queremos resolver?

Depois:

Precisamos de deployment independente?

Depois:

Partes diferentes precisam escalar independentemente?

Depois:

Existem boundaries de negócio claros?

Depois:

As equipes realmente possuem autonomia?

Depois:

Temos CI/CD maduro?

Depois:

Temos observabilidade?

Depois:

Sabemos operar sistemas distribuídos?

Depois:

Como trataremos consistência de dados?

Finalmente:

Um modular monolith resolveria?

Se ninguém consegue responder à primeira pergunta, não precisamos discutir a décima.


🎓 20. A lição para o programador COBOL iniciante

Se você está começando COBOL e olha para diagramas modernos pensando:

“Meu Deus, preciso aprender tudo isso antes de entender arquitetura.”

Não.

Comece pelos fundamentos.

Entenda profundamente:

dados
interfaces
responsabilidades
transações
dependências
falhas
contratos
estado
recuperação

Aprenda por que existe:

CALL

Entenda por que existe:

COMMIT

Entenda por que existe:

ROLLBACK

Entenda arquivos, Db2, VSAM, CICS e mensageria.

Depois olhe novamente para microservices.

Você começará a reconhecer velhos problemas usando roupas novas.

Naturalmente, sistemas distribuídos trouxeram desafios e soluções próprias. Não devemos fingir que um CALL COBOL e uma chamada HTTP são equivalentes.

Mas ambos obrigam o arquiteto a pensar:

Quem chama quem?

Qual é o contrato?

O que acontece quando falha?

Essas perguntas atravessam gerações tecnológicas.


🍿 Epílogo — alguém trouxe pipoca?

No final, talvez essa seja a melhor contribuição de Chris Knight para nossa imaginária aula de arquitetura.

Tecnologia pode — e deve — ser divertida.

Precisamos experimentar.

Precisamos construir protótipos.

Precisamos estudar microservices, containers, APIs, eventos, IA e tudo aquilo que surgir depois.

Mas devemos conservar uma pequena irreverência diante das modas.

Quando uma apresentação disser:

“Todo mundo está migrando para microservices.”

Pergunte:

Por quê?

Quando disserem:

“Precisamos quebrar o monólito.”

Pergunte:

Onde exatamente ele está nos prejudicando?

Quando disserem:

“Precisamos de 70 serviços.”

Pergunte:

Por que 70?

E quando alguém apresentar uma arquitetura gigantesca para resolver um problema relativamente pequeno, imagine Chris Knight entrando na reunião, olhando aquele maravilhoso laser tecnológico apontado para uma simples panela de milho e perguntando:

“Vocês sabem que existe um jeito mais fácil de fazer pipoca, não sabem?”

Essa é a diferença entre conhecer tecnologia e compreender arquitetura.

O desenvolvedor aprende a construir o laser.

O engenheiro aprende a fazê-lo funcionar.

O arquiteto calcula potência, disponibilidade, segurança e custo.

Mas o Real Genius olha para o requisito e pergunta:

“A gente precisava mesmo do laser?”

Bellacosa Mainframe — porque às 03:17 da madrugada, simplicidade também é uma feature.

quinta-feira, 10 de setembro de 2026

🎧 zBNA — A Conversação do Batch: Harry Caul e o Mistério do Critical Path

 

Bellacosa Mainframe apresenta o zBNA analise de processos batch

☕ Um Café no Bellacosa Mainframe

🎧 zBNA — A Conversação do Batch: Harry Caul e o Mistério do Critical Path

Sob a batuta de Harry Caul, de The Conversation: no mainframe, assim como numa gravação de vigilância, o problema raramente está simplesmente no sinal mais alto. Está naquilo que acontece entre os sinais — nas pausas, dependências, esperas e detalhes que ninguém percebeu.



Imagine uma sala silenciosa.

Na parede existem gráficos de CPU, relatórios de utilização, tempos de execução, estatísticas de I/O e algumas planilhas de capacity planning.

O batch deveria ter terminado às 03:00.

São 03:17.

Alguém olha para o gráfico e diz:

— Precisamos de um mainframe maior.

No fundo da sala, Harry Caul não responde.

Ele coloca os fones de ouvido.

Volta a fita.

Escuta novamente.

Porque Harry aprendeu uma coisa durante toda uma vida ouvindo conversas que outras pessoas não deveriam ouvir:

uma informação isolada pode dizer algo completamente diferente quando colocada no contexto correto.

E é exatamente esse o problema que encontramos quando tentamos fazer sizing de um ambiente IBM Z olhando somente para capacidade de processador.

Bem-vindo à investigação.



🎧 1. Harry Caul não começaria olhando o processador

Para quem nunca assistiu a The Conversation, Harry Caul é um especialista em vigilância e gravação de áudio.

Seu trabalho não consiste simplesmente em gravar sons.

Ele precisa separar ruído de informação.

Uma conversa aparentemente banal pode esconder algo importante.

Uma frase pode assumir outro significado quando escutada novamente.

No nosso datacenter acontece algo parecido.

Temos:

CPU utilization
MSU
MIPS
Elapsed Time
CPU Time
I/O
Wait
ENQ
Db2
VSAM
JES2
WLM
Scheduler

Tudo está falando ao mesmo tempo.

O erro seria escolher o gráfico mais chamativo e concluir:

CPU alta
   ↓
Falta capacidade
   ↓
Comprar processador

Pode ser verdade.

Mas ainda não sabemos.

Harry Caul provavelmente perguntaria:

“O que aconteceu antes disso?”


 

Essa pergunta nos leva ao IBM Z Batch Network Analyzer — zBNA.



🕸️ 2. O batch é uma conversa entre JOBs

Para um programador COBOL iniciante, uma sequência batch pode parecer algo relativamente simples.

Temos JOBs:

JOB001
JOB002
JOB003
JOB004
JOB005

Parece uma lista.

Mas operacionalmente eles podem estar relacionados:

             +--> JOB B --+
             |            |
JOB A -------+            +--> JOB D --> JOB E --> FIM
             |            |
             +--> JOB C --+

Agora a história mudou.

JOB B e JOB C dependem de A.

JOB D depende de alguma condição relacionada aos anteriores.

JOB E depende de D.

Portanto, não estamos mais observando apenas programas.

Estamos observando uma rede de dependências.

É quase uma conversação:

JOB A: terminei.

JOB B: agora posso começar.
JOB C: eu também.

JOB C: terminei.

JOB D: ainda não.

JOB B: terminei.

JOB D: agora sim.

JOB D: processando...
JOB D: processando...
JOB D: processando...

JOB E: esperando...

Harry Caul imediatamente prestaria atenção naquele silêncio.

Por que JOB E está esperando?


⏱️ 3. O silêncio também faz parte da gravação

Esse é um conceito fundamental para quem começa a estudar performance.

Um programa pode estar demorando sem estar usando CPU.

Considere:

Elapsed Time = 42 minutos
CPU Time     = 11 minutos

Onde estão os outros 31 minutos?

Essa é uma pergunta maravilhosa.

Porque começamos a procurar:

I/O WAIT
LOCK
ENQ
DATASET CONTENTION
DB2 LOCKING
QUEUE
SCHEDULING
RESOURCE WAIT
NETWORK
APPLICATION SERIALIZATION

Imagine nossa investigação encontrando:

Elapsed Time     42 min
├── CPU           11 min
├── I/O            17 min
├── Lock/ENQ        8 min
└── Outros waits    6 min

Agora tente resolver isso simplesmente colocando mais processador.

Talvez os 11 minutos de CPU melhorem.

Mas e os outros?

Essa é a primeira grande lição:

Elapsed Time não é simplesmente CPU Time usando outro relógio.


🐉 4. Encontramos JOB D

Voltemos à cadeia:

JOB A = 12 min

       +-- JOB B = 18 min --+
       |                    |
       +-- JOB C =  7 min --+
                            |
                         JOB D = 42 min
                            |
                         JOB E = 9 min

B e C podem executar simultaneamente.

Portanto não podemos simplesmente fazer:

12 + 18 + 7 + 42 + 9

Precisamos considerar a dependência.

Nesse exemplo simplificado:

12 + MAX(18,7) + 42 + 9

Temos:

12 + 18 + 42 + 9 = 81 minutos

E observe JOB D:

42 / 81 ≈ 52%

Ele ocupa mais da metade do caminho.

Harry Caul colocaria os fones novamente.

Por que exatamente são 42 minutos?

Essa pergunta vale potencialmente muito dinheiro.


🛣️ 5. Critical Path — quem realmente possui o relógio?

Chegamos ao conceito central:

Critical Path.

Imagine uma rede maior:

                 JOB B --------+
                /               \
JOB A ----------                 +---- JOB F ----+
                \               /                |
                 JOB C --> JOB D                 +--> JOB H
                                                /
                 JOB E -------------------------+

Podemos possuir diferentes caminhos:

A → B → F → H

A → C → D → F → H

E → H

Um deles determinará quando todo o processo poderá terminar.

Esse é nosso caminho crítico.

E aqui surge uma descoberta extremamente importante:

O JOB que mais consome CPU não precisa ser o JOB mais importante para reduzir a janela batch.

Suponha que JOB X consuma enorme quantidade de CPU.

Todo mundo olha para ele.

JOB X
CPU TIME = █████████████████████

Parece culpado.

Mas JOB X possui bastante folga e está fora do critical path.

Você consegue uma otimização fantástica:

JOB X
-30% elapsed

Resultado sobre o fechamento:

0 minutos

Nada.

O batch termina exatamente no mesmo horário.

Enquanto isso, um JOB pequeno pertencente ao critical path perde cinco minutos esperando determinado recurso.

Eliminar aquela espera poderia antecipar o fechamento em aproximadamente cinco minutos.

Harry Caul diria:

vocês estavam ouvindo a pessoa errada.


💻 6. Programador COBOL: não condene o programa imediatamente

Encontramos JOB D.

A primeira reação pode ser:

— COBOL velho!

Calma.

Talvez o programa esteja perfeitamente correto.

Imagine:

PERFORM PROCESSA-REGISTRO
   UNTIL EOF.

O programa está executando adequadamente.

Mas cada ciclo depende de acesso a um recurso.

Pode existir:

COBOL
  ↓
VSAM
  ↓
Dataset
  ↓
ENQ
  ↓
WAIT

Ou:

COBOL
  ↓
SQL
  ↓
Db2
  ↓
LOCK
  ↓
WAIT

Ou ainda:

JOB
 ↓
Scheduler
 ↓
Dependency
 ↓
WAIT

Nenhuma quantidade de indignação contra o COBOL resolverá automaticamente isso.

E talvez nenhuma quantidade adicional de CPU resolva.

Precisamos encontrar a causa.


⚙️ 7. Capacity não é a mesma coisa que velocidade

Aqui encontramos outra armadilha.

Imagine dois sistemas hipotéticos:

SYSTEM A
10 engines × velocidade X

SYSTEM B
6 engines × velocidade Y

Mesmo que determinada medida agregada de capacidade pareça semelhante, o comportamento do workload pode ser diferente.

Por quê?

Imagine trabalho altamente paralelo:

JOB1 ──┐
JOB2 ──┤
JOB3 ──┼──> resultado
JOB4 ──┤
JOB5 ──┘

Vários engines podem ser aproveitados.

Agora imagine:

JOB1
  ↓
JOB2
  ↓
JOB3
  ↓
JOB4

Colocar dezenas de engines disponíveis ao lado dessa sequência não faz os JOBs executarem simultaneamente por mágica.

Temos então que distinguir:

aggregate capacity

de

per-engine performance

e ambos de:

usable parallelism.


🧵 8. Usable parallelism — dez microfones não criam dez conversas

Harry Caul poderia instalar dez microfones.

Mas se existe apenas uma pessoa falando, continuamos tendo uma conversa.

No mainframe podemos possuir:

10 engines disponíveis

enquanto o workload oferece:

1 unidade relevante de trabalho executável

Visualmente:

CPU0 ████████████
CPU1 ░░░░░░░░░░░░
CPU2 ░░░░░░░░░░░░
CPU3 ░░░░░░░░░░░░
CPU4 ░░░░░░░░░░░░

Adicionar CPU5, CPU6 e CPU7 não necessariamente ajudará.

Talvez precisemos investigar:

  • dependências;

  • scheduler;

  • initiators;

  • particionamento;

  • desenho dos JOBs;

  • datasets;

  • banco;

  • I/O;

  • serialização da aplicação.

Esse é o significado prático de usable parallelism.

Não importa somente quanta capacidade existe.

Importa quanto daquele paralelismo o workload consegue realmente consumir.


🏭 9. JES2, WLM e scheduler entram na sala

Agora nossa investigação fica mais interessante.

Eu dividiria o problema em quatro níveis:

BUSINESS PROCESS
       ↓
BATCH NETWORK
       ↓
z/OS RESOURCE BEHAVIOR
       ↓
PROCESSOR

No terceiro andar dessa investigação encontramos:

JES2
WLM
Initiators
Scheduler
I/O
Db2
VSAM
ENQ
Storage
Memory
Network

Imagine comprarmos um IBM Z muito mais poderoso.

Temos:

PROCESSOR
████████████████████████

JOB
██████

WAIT
████████████████████████████████

O processador está disponível.

O JOB não está trabalhando.

Harry Caul aumenta o volume.

Nada.

Porque o problema não está onde todos estavam olhando.


🎧 10. CPU a 95%: culpada!

Não tão rápido.

Encontramos:

CPU = 95%

Parece assustador.

Mas existe trabalho útil sendo processado?

O SLA está sendo atendido?

Existe fila significativa esperando CPU?

A utilização é sustentada ou apenas um pico?

O comportamento está dentro do esperado?

Então 95% isoladamente não constitui diagnóstico.

Agora encontramos:

CPU = 40%

Maravilha!

Temos sobra.

Talvez.

Ou talvez metade do workload esteja esperando recursos.

Portanto:

CPU HIGH ≠ automaticamente ruim

CPU LOW ≠ automaticamente bom

Um gráfico é uma pista.

Não é uma sentença.


🕵️ 11. War Room Mainframe sob a batuta de Harry Caul

Agora apagamos as luzes.

Colocamos JOB D no centro da tela.

Pergunta número um:

Por que exatamente são 42 minutos?

Não:

Quanto CPU ele usa?

Ainda não.

Primeiro:

42 MINUTOS
    |
    +-- CPU?
    |
    +-- I/O?
    |
    +-- ENQ?
    |
    +-- Db2 lock?
    |
    +-- VSAM?
    |
    +-- Queue?
    |
    +-- Scheduler?
    |
    +-- Dependency?
    |
    +-- Application serialization?

Então começamos a correlacionar evidências.

Esse é o ponto em que capacity planning deixa de ser comparação de catálogo e começa a se aproximar de investigação.


🔄 12. Harry Caul volta a fita

Encontramos o gargalo.

PATH A:

81 minutos

PATH B:

75 minutos

Otimizamos PATH A:

81 → 70

Excelente!

Acabou?

Não.

Agora temos:

PATH A = 70
PATH B = 75

PATH B tornou-se o novo critical path.

O gargalo mudou de endereço.

Esse comportamento ensina uma das coisas mais importantes sobre performance:

MEASURE
   ↓
ANALYZE
   ↓
FIND CRITICAL PATH
   ↓
OPTIMIZE
   ↓
MEASURE AGAIN
   ↓
RECALCULATE
   ↺

Harry Caul volta a gravação porque uma segunda audição pode revelar algo que a primeira interpretação escondeu.

Nós fazemos a mesma coisa.

Depois de modificar o workload, medimos novamente.


💰 13. Performance também conversa com dinheiro

Existe outro microfone naquela sala.

Custo.

Sizing não deveria ser simplesmente:

Qual máquina é mais rápida?

Precisamos equilibrar:

PERFORMANCE
     +
CAPACITY
     +
SLA
     +
SOFTWARE COST
     +
OPERATIONAL RISK
     +
GROWTH

Porque uma solução tecnicamente elegante pode não ser economicamente interessante.

Da mesma maneira, economizar dinheiro sacrificando um SLA crítico pode custar muito mais ao negócio.

Sizing é um problema de engenharia.

Mas também é um problema de negócio.


🎯 14. Antes do zBNA existe uma pergunta zero

Eu acrescentaria uma etapa antes de qualquer análise:

Qual é o SLA?

Imagine que o fechamento termina às 04:30.

Caso A:

SLA = 06:00
Fim = 04:30

Temos determinada situação.

Caso B:

SLA = 03:00
Fim = 04:30

Agora temos um incidente.

Os mesmos JOBs.

A mesma CPU.

O mesmo hardware.

O mesmo elapsed.

Contextos de negócio completamente diferentes.

Performance sem objetivo é apenas uma coleção muito bonita de gráficos.


🧠 15. As seis perguntas de Harry Caul

Se eu estivesse ensinando isso para um programador COBOL iniciante, colocaria seis perguntas ao lado do terminal:

1. Quando o negócio precisa terminar?

SLA.

2. O que precisa acontecer para ele terminar?

Batch Network.

3. Qual sequência determina esse horário?

Critical Path.

4. Por que os componentes críticos estão demorando?

CPU, I/O, locks, ENQ, Db2, VSAM, scheduling, dependências.

5. O workload consegue utilizar capacidade adicional?

Usable Parallelism.

6. Qual alteração entrega maior benefício considerando custo e risco?

Sizing.

Somente então colocamos os candidatos a processador sobre a mesa.


☕ 16. A tradução para quem está começando no COBOL

Você escreveu:

PERFORM PROCESSO-A
PERFORM PROCESSO-B
PERFORM PROCESSO-C
PERFORM PROCESSO-D

Alguém aparece oferecendo um computador duas vezes mais rápido.

Parece razoável imaginar:

2 × PERFORMANCE
       =
1/2 ELAPSED TIME

Mas descobrimos:

PROCESSO-A → CPU

PROCESSO-B → espera arquivo

PROCESSO-C → espera outro JOB

PROCESSO-D → espera lock Db2

Ops.

Nosso computador duas vezes mais rápido não pode acelerar magicamente aquilo que não está usando processador.

Quando ampliamos isso para centenas ou milhares de JOBs, datasets, bancos, schedulers, dependências e recursos compartilhados, começamos a compreender por que precisamos enxergar o workload como sistema.

É aí que o zBNA se torna particularmente interessante.


🥚 Easter Egg — 03:17

O processamento deveria terminar às 03:00.

Harry está sentado no fundo da War Room.

03:00

Nada.

03:05

Nada.

03:11

Os gerentes começam a olhar para o dashboard.

03:16

Alguém diz:

— Precisamos de mais CPU.

Harry coloca os fones.

03:17

Ele volta alguns minutos da gravação operacional.

Na tela:

JOB D
STATUS: WAIT

CPU?

AVAILABLE

Ele continua seguindo a cadeia.

Predecessor.

Dataset.

ENQ.

Wait.

Silêncio.

Harry tira lentamente os fones.

Não faltava processador.

Faltava ouvir a conversa inteira.


🏁 Conclusão — o mainframe também deixa pistas

O ensinamento mais importante do zBNA não é simplesmente aprender a utilizar outra ferramenta.

É aprender a fazer uma pergunta melhor.

Um problema de performance não significa automaticamente:

NEED MORE CAPACITY

A janela batch é resultado de uma combinação muito mais interessante:

BATCH WINDOW
     =
CPU
+
DEPENDENCIES
+
SERIALIZATION
+
PARALLELISM
+
I/O
+
CONTENTION
+
SCHEDULING
+
RESOURCE AVAILABILITY
+
APPLICATION BEHAVIOR

O processador está dentro dessa equação.

Às vezes ele será justamente o gargalo e aumentar capacidade será a decisão correta.

Mas precisamos demonstrar isso.

Harry Caul não condenaria alguém porque uma palavra pareceu suspeita na primeira reprodução.

Ele limparia o ruído.

Voltaria a fita.

Compararia os sinais.

Procuraria o contexto.

No capacity planning deveríamos ter a mesma disciplina.

Antes de perguntar:

“Qual IBM Z devemos comprar?”

pergunte:

“Quem está segurando o batch?”

Depois encontre o critical path.

Descubra quanto do elapsed realmente depende de CPU.

Investigue I/O, locks, datasets, scheduler, JES2, WLM, Db2, VSAM, ENQ e dependências.

Descubra quanto paralelismo é realmente utilizável.

Meça.

Simule.

Altere.

Meça novamente.

E somente depois faça sizing.

Porque existe uma diferença enorme entre possuir uma gravação e compreender a conversa.

Da mesma maneira, existe uma diferença enorme entre possuir métricas e compreender o workload.

🎧 Não faça sizing do mainframe antes de fazer sizing do problema.

O processador pode fornecer a potência.

Mas é o critical path que possui o relógio.

E, às 03:17, quando todos estiverem olhando para a CPU, talvez o verdadeiro gargalo esteja silenciosamente esperando em algum lugar da conversação.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...