☕ Um Café no Bellacosa Mainframe

⚔️ RICK GLADIATOR E AS TRÊS DUNGEONS DA ARQUITETURA

Monolith, Microservices, Serverless, COBOL, CICS, Db2, VSAM, MQ, APIs, eventos, consistência distribuída, observabilidade — e o dia em que um programador iniciante descobriu que quebrar um programa em 47 pedaços não o transformava automaticamente em arquiteto.

Sob a tutela de Rick Gladiator, de Shinmai Ossan Boukensha.

---

🎬 PRÓLOGO — VOCÊ TEM 30 ANOS E AINDA USA UM MONÓLITO?

Rick Gladiator conhece muito bem aquela sensação.

Você chega à Guilda dos Aventureiros e encontra uma turma de jovens prodígios.

Um lança magia.

Outro derrota monstros gigantescos.

Outro provavelmente nasceu com KUBERNETES-SKILL LEVEL 99.

Então alguém olha para o velho programador COBOL e pergunta:

— Você ainda trabalha com monólito?

Silêncio.

O programador olha para o terminal.

Rick coloca a espada sobre a mesa.

E responde:

— Antes de chamar alguma coisa de velha, descubra por que ela ainda está funcionando.

Bem-vindo à dungeon.

Hoje não vamos simplesmente comparar três caixas coloridas de um diagrama:

MONOLITH
MICROSERVICES
SERVERLESS

Vamos descobrir o que realmente muda, onde cada arquitetura funciona, quais problemas aparecem quando distribuímos uma aplicação e, principalmente, como tudo isso conversa com COBOL, CICS, Db2, VSAM, MQ e o Mainframe.

Porque existe uma primeira armadilha escondida no mapa:

Monolith, Microservices e Serverless não são exatamente três alternativas equivalentes.

Rick já percebeu o monstro.

Vamos entrar.

---

🏰 CAPÍTULO 1 — A PRIMEIRA DUNGEON: O MONÓLITO

Imagine que precisamos desenvolver um comércio eletrônico.

Temos:

Produtos
Carrinho
Pedidos
Pagamentos
Clientes

Uma arquitetura monolítica poderia ser representada assim:

             CLIENTE
                |
                v
       +----------------+
       |   APLICAÇÃO    |
       |----------------|
       | Produtos       |
       | Carrinho       |
       | Pedidos        |
       | Pagamentos     |
       | Clientes       |
       +----------------+
                |
                v
            DATABASE

Existe uma aplicação contendo diferentes responsabilidades.

A definição simplificada costuma ser:

One application = one deployable unit.

Mas Rick imediatamente ergue a mão.

— Cuidado.

No mundo Mainframe isso precisa de uma explicação adicional.

Um sistema COBOL pode possuir:

PGMAUTH
PGMCUST
PGMLIMIT
PGMPAY
PGMBILL
PGMSTAT

Pode utilizar:

COPYBOOKS
SUBPROGRAMAS
CICS
Db2
VSAM
JCL
PROCEDURES

e possuir centenas ou milhares de módulos.

Mesmo assim, arquiteturalmente, esses componentes podem formar uma grande aplicação fortemente relacionada.

Portanto:

Monólito não significa obrigatoriamente um programa gigantesco com três milhões de linhas.

Essa confusão aparece bastante.

---

🧱 CAPÍTULO 2 — MONÓLITO NÃO SIGNIFICA CÓDIGO RUIM

Rick encontra o primeiro aventureiro da guilda.

Ele possui uma camiseta:

MICROSERVICES OR DIE

Rick pergunta:

— Por quê?

— Porque monólito é ruim.

— Por quê?

— Porque é monólito.

Rick começa a procurar sua espada.

Um monólito pode ser perfeitamente modular.

Imagine:

+--------------------------------+
| SISTEMA DE CARTÕES             |
|                                |
| AUTHORIZATION MODULE           |
| CUSTOMER MODULE                |
| LIMIT MODULE                   |
| BILLING MODULE                 |
| PAYMENT MODULE                 |
| FRAUD MODULE                   |
+--------------------------------+

Cada responsabilidade pode estar adequadamente separada internamente.

Em COBOL:

CALL 'LIMITCHK' USING CUSTOMER-DATA
                      TRANSACTION-DATA
                      RETURN-DATA.

Uma chamada local entre componentes pode ser extremamente rápida.

Não precisamos necessariamente atravessar:

HTTP
TCP/IP
TLS
API Gateway
JSON
Authentication
Load Balancer
Service Discovery

para calcular o limite de um cartão.

A simplicidade também é uma característica arquitetural.

---

⚡ CAPÍTULO 3 — RICK DESCOBRE QUE A REDE TEM LATÊNCIA

Imagine isto:

CALL 'CALCLIM' USING WS-CUSTOMER
                     WS-LIMIT.

Agora alguém decide:

— CALCLIM precisa virar microservice!

A arquitetura passa a ser algo semelhante a:

COBOL
  |
  v
HTTP CLIENT
  |
  v
TCP/IP
  |
  v
TLS
  |
  v
API GATEWAY
  |
  v
AUTHENTICATION
  |
  v
LIMIT SERVICE
  |
  v
DATABASE

Arquiteturalmente ganhamos várias possibilidades.

O serviço pode ser implantado independentemente.

Pode escalar independentemente.

Outra aplicação pode reutilizá-lo.

Mas Rick pergunta:

— E quanto custou atravessar essa ponte?

Porque agora temos:

latência
timeout
retry
serialização
desserialização
falha de rede
DNS
autenticação
observabilidade

A operação que antes acontecia dentro do mesmo processo agora atravessa uma rede.

Não significa que microservices sejam ruins.

Significa apenas:

Toda arquitetura compra vantagens pagando com alguma forma de complexidade.

---

🔵 CAPÍTULO 4 — A SEGUNDA DUNGEON: MICROSERVICES

Agora vamos quebrar nosso comércio eletrônico.

                    CLIENT
                       |
                       v
                 API GATEWAY
                       |
          +------------+------------+
          |            |            |
          v            v            v
       PRODUCT        CART        ORDER
       SERVICE       SERVICE      SERVICE
          |            |            |
          v            v            v
       MongoDB        Redis      PostgreSQL

A ideia é que cada serviço represente uma capacidade de negócio relativamente independente.

Podemos ter:

Customer Service
Order Service
Payment Service
Inventory Service
Fraud Service

Idealmente cada um possui autonomia suficiente para evoluir sem exigir um gigantesco deploy coordenado.

Essa palavra é fundamental:

INDEPENDÊNCIA

Queremos independência de:

desenvolvimento
deploy
escalabilidade
tecnologia
ciclo de vida
equipe
dados

Por exemplo, durante a Black Friday:

Product Service = 20 instâncias
Cart Service    = 80 instâncias
Order Service   = 50 instâncias
Fraud Service   = 30 instâncias

Podemos aumentar apenas aquilo que está sofrendo pressão.

Essa é uma diferença importante em relação a muitos monólitos.

---

🐉 CAPÍTULO 5 — VOCÊ DERROTOU O MONÓLITO E DESBLOQUEOU 17 NOVOS MONSTROS

Rick abre a próxima porta.

Há uma placa:

Distributed Systems Dungeon

Ele imediatamente percebe que alguma coisa vai dar errado.

Imagine uma compra.

Em uma aplicação centralizada poderíamos ter conceitualmente:

BEGIN TRANSACTION

UPDATE INVENTORY
INSERT ORDER
INSERT PAYMENT

COMMIT

Algo falhou?

ROLLBACK

É claro que sistemas reais são mais complexos, mas o banco de dados fornece mecanismos transacionais poderosos.

Agora distribuímos tudo:

Order Service
      |
      +----> Inventory Service
      |
      +----> Payment Service
      |
      +----> Shipping Service

Resultado:

Inventory = OK
Payment   = OK
Shipping  = ERROR

E agora?

Não existe necessariamente um botão mágico:

ROLLBACK UNIVERSO

Temos vários sistemas, bancos e estados independentes.

Bem-vindo a conceitos como:

Eventual Consistency
Saga
Compensating Transactions
Idempotency
Retry
Timeout
Dead-Letter Queue
Circuit Breaker

Rick olha para o programador iniciante.

— Ainda acha que dividir tudo em serviços automaticamente simplifica a aplicação?

---

🔁 CAPÍTULO 6 — IDEMPOTÊNCIA: ATAQUE O MONSTRO DUAS VEZES SEM MATAR DOIS CLIENTES

Suponha que um serviço receba:

PAY CUSTOMER 100

Ele processa.

Mas a resposta não retorna por causa de um timeout.

O chamador pensa:

"Não funcionou."

E envia novamente.

Se o sistema não estiver preparado:

Pagamento 1 = R$100
Pagamento 2 = R$100

Temos problema.

Uma operação idempotente procura permitir que repetições controladas não produzam efeitos duplicados indevidos.

Podemos trabalhar com algo como:

TRANSACTION-ID = ABC123

Antes de processar novamente:

ABC123 já foi processada?

Se sim, devolvemos o resultado anterior ou tratamos de acordo com a regra definida.

Em sistemas distribuídos, isso deixa de ser detalhe.

É sobrevivência.

---

👹 CAPÍTULO 7 — O TERRÍVEL DISTRIBUTED MONOLITH

A guilda comemora.

— Conseguimos! Criamos 27 microservices!

Rick pergunta:

— Eles podem ser implantados independentemente?

Silêncio.

Para instalar PAYMENT, precisamos instalar ORDER.

Para instalar ORDER, precisamos instalar CUSTOMER.

Para instalar CUSTOMER, precisamos atualizar PRODUCT.

Então temos:

27 serviços
27 pipelines
27 APIs
27 logs
27 configurações

mas...

1 deploy coordenado

Criamos um:

DISTRIBUTED MONOLITH

Ou seja:

Pegamos algumas desvantagens do monólito e adicionamos várias dificuldades dos sistemas distribuídos.

Esse é um dos maiores perigos de adotar microservices apenas porque eles estão na moda.

---

🟣 CAPÍTULO 8 — A TERCEIRA DUNGEON: SERVERLESS

Chegamos ao terceiro bloco do desenho.

Mas existe um segredo.

Serverless não está exatamente no mesmo eixo de Monolith e Microservices.

Monolith e Microservices respondem principalmente:

Como organizamos e dividimos a aplicação?

Serverless responde mais diretamente:

Como determinado código será executado e operacionalizado?

Essa diferença muda tudo.

Podemos ter:

Microservices + Serverless

Podemos ter:

Monolith + Serverless Functions

Podemos ter:

Mainframe + Microservices + Serverless

Portanto não pense:

MONOLITH
   ↓
MICROSERVICES
   ↓
SERVERLESS

como uma linha evolutiva.

Não existe um Pokémon arquitetural chamado:

Monolithmon
   ↓
Microservicemon
   ↓
Serverlessmon

---

☁️ CAPÍTULO 9 — MAS SERVERLESS TEM SERVIDOR!

Sim.

Rick também ficou decepcionado.

Serverless não significa que os servidores desapareceram em alguma magia ancestral.

Eles continuam existindo.

A diferença é que o desenvolvedor normalmente não administra diretamente toda a infraestrutura necessária para executar aquela função.

Um modelo simplificado:

EVENT
  |
  v
FUNCTION
  |
  v
RESULT

Por exemplo:

HTTP REQUEST
     |
     v
API GATEWAY
     |
     v
CREATE-ORDER FUNCTION
     |
     v
DATABASE

Mas o evento também pode ser:

Queue Message
File Upload
Timer
Database Change
Object Created
Event Stream

Por isso Serverless combina muito bem com arquiteturas orientadas a eventos.

---

🥶 CAPÍTULO 10 — O DRAGÃO DO COLD START

Uma função pode não estar continuamente ativa.

Chega uma solicitação.

A plataforma talvez precise preparar seu ambiente:

REQUEST
   |
   v
START RUNTIME
   |
   v
LOAD DEPENDENCIES
   |
   v
INITIALIZE
   |
   v
EXECUTE FUNCTION

Essa inicialização pode introduzir latência.

É o famoso:

Cold Start

Isso varia conforme plataforma, linguagem, configuração e modelo operacional.

Para algumas aplicações é irrelevante.

Para outras, alguns milissegundos adicionais podem ser importantes.

A lição é novamente:

Não escolha tecnologia olhando apenas o desenho bonito.

Meça.

---

🏦 CAPÍTULO 11 — RICK GLADIATOR ENTRA NO CICS

Agora começa a parte que faz o velho programador COBOL sorrir.

Considere:

CLIENT
   |
   v
CICS
   |
   v
TRANSACTION
   |
   v
COBOL PROGRAM
   |
   +----> Db2
   |
   +----> VSAM

O programador COBOL normalmente não precisa escrever do zero toda a infraestrutura necessária para:

gerenciar processos
controlar recursos
coordenar transações
gerenciar milhares de solicitações
proteger recursos

O CICS oferece um ambiente transacional gerenciado.

Isso não significa que CICS seja Serverless no sentido moderno.

Mas existe uma analogia pedagógica deliciosa.

Décadas antes da palavra "serverless" virar assunto de conferência, o Mainframe já trabalhava profundamente com ideias como:

execução gerenciada
workload
transações
eventos
resource management
security
recovery

Rick olha para a arquitetura moderna.

Depois olha para o CICS.

— Eu já vi alguns desses golpes antes...

---

🌉 CAPÍTULO 12 — O COBOL NÃO PRECISA VIRAR MICROSERVICE

Imagine um banco com:

Mobile Banking
Internet Banking
Open Finance
Parceiros
ATM

Podemos construir:

Mobile
   |
   v
API Gateway
   |
   v
Microservices
   |
   v
z/OS Connect
   |
   v
CICS
   |
   v
COBOL
   |
   +--> Db2
   |
   +--> VSAM

O programa COBOL pode continuar sendo responsável pela lógica transacional crítica.

A modernização ocorre ao redor e através dele.

Essa é uma mudança enorme de perspectiva.

Modernizar não significa obrigatoriamente:

DELETE COBOL.

Pode significar:

ENABLE COBOL.

---

🔌 CAPÍTULO 13 — z/OS CONNECT ABRE A PORTA DA DUNGEON

Imagine que nosso programa trabalha com:

01 CUSTOMER-REQUEST.
   05 CUSTOMER-ID PIC X(10).

01 CUSTOMER-RESPONSE.
   05 CUSTOMER-NAME  PIC X(40).
   05 CUSTOMER-LIMIT PIC 9(09)V99.

O mundo moderno deseja conversar usando algo semelhante a:

{
  "customerId": "0001234567"
}

e receber:

{
  "name": "RICK GLADIATOR",
  "limit": 15000.00
}

Uma integração pode assumir:

REST / JSON
     |
     v
z/OS Connect
     |
     v
CICS
     |
     v
COBOL

Perceba a beleza.

O programa COBOL não precisa acordar numa terça-feira dizendo:

"Agora sou JavaScript."

Ele continua executando a responsabilidade para a qual foi construído.

Criamos uma nova fronteira de integração.

---

📨 CAPÍTULO 14 — MQ: RICK DESCOBRE QUE NEM TODA MISSÃO PRECISA ESPERAR RESPOSTA

Outra possibilidade:

ORDER SERVICE
      |
      v
     MQ
      |
      v
COBOL CONSUMER
      |
      v
     Db2

O produtor publica uma mensagem.

Algo como:

ORDER.CREATED

O consumidor processa quando apropriado.

Podemos ter:

ORDER.CREATED
      |
      +----> BILLING
      |
      +----> INVENTORY
      |
      +----> FRAUD
      |
      +----> ANALYTICS

Isso introduz uma distinção essencial.

Comunicação síncrona:

FAÇA ISTO
E EU ESPERO A RESPOSTA

Comunicação assíncrona:

ESTE TRABALHO PRECISA SER PROCESSADO

Essa diferença é fundamental para arquiteturas corporativas.

---

🌊 CAPÍTULO 15 — EVENT STREAMING: O MONSTRO MORREU E TODO MUNDO FICOU SABENDO

Em arquiteturas orientadas a eventos, podemos publicar:

PAYMENT.APPROVED

Diversos interessados podem reagir:

PAYMENT.APPROVED
        |
        +------> ORDER
        |
        +------> SHIPPING
        |
        +------> ANALYTICS
        |
        +------> FRAUD
        |
        +------> NOTIFICATION

Isso reduz determinados acoplamentos diretos.

O produtor não precisa necessariamente conhecer todos os consumidores.

O conceito muda de:

"Fulano, faça isso."

para:

"Isto aconteceu."

É uma mudança arquitetural poderosa.

---

🔭 CAPÍTULO 16 — OBSERVABILIDADE: QUEM MATOU O MONSTRO?

No monólito:

Client
  |
Application
  |
Database

Investigar uma falha pode ser relativamente simples.

Agora:

Client
 |
Gateway
 |
Service A
 |
Service B
 |
Queue
 |
Service C
 |
Mainframe
 |
CICS
 |
COBOL
 |
Db2

O usuário reclama:

"Demorou oito segundos."

Onde?

Precisamos correlacionar:

logs
metrics
traces
timestamps
transaction IDs
correlation IDs

Talvez a API tenha consumido:

50 ms

O microservice:

80 ms

MQ:

20 ms

CICS:

40 ms

mas uma consulta esperou:

7.500 ms

por um lock no Db2.

Sem observabilidade distribuída, o diagnóstico vira investigação arqueológica.

---

📊 CAPÍTULO 17 — O MAPA DE RICK

Guarde esta tabela mental:

Aspecto	Monolith	Microservices	Serverless
Organização	aplicação	serviços	funções/event handlers
Deploy	mais coordenado	independente	função
Comunicação	frequentemente local	rede/eventos	eventos/APIs
Escala	aplicação	serviço	execução/função
Estado	mais centralizado	distribuído	normalmente externo
Debug	mais simples	distribuído	distribuído
Operação	menor complexidade inicial	alta	infraestrutura abstraída
Consistência	mais simples	complexa	frequentemente distribuída
Rede	menor dependência interna	fundamental	fundamental
Observabilidade	concentrada	distribuída	distribuída

Mas Rick acrescentaria:

Não transforme essa tabela em religião.

---

💰 CAPÍTULO 18 — SERVERLESS NÃO SIGNIFICA BARATO

Imagine uma função utilizada:

100 vezes por dia

Excelente candidata potencial.

Agora imagine:

10.000 requisições/segundo
24 horas/dia
365 dias/ano

A análise econômica muda completamente.

Serverless frequentemente oferece cobrança baseada em utilização, mas isso não significa automaticamente:

SERVERLESS = MAIS BARATO

Você precisa avaliar:

volume
duração
memória
I/O
rede
armazenamento
requisições
picos
previsibilidade
SLA

A arquitetura correta é também uma decisão econômica.

---

🧭 CAPÍTULO 19 — PASSO A PASSO PARA ESCOLHER

Rick não escolheria uma arma apenas porque alguém colocou "Cloud Native" na embalagem.

Faça perguntas.

Passo 1 — descubra o domínio

O que a aplicação realmente faz?

Pagamento?
Consulta?
Relatório?
Fraude?
Cadastro?
Processamento de imagem?

Passo 2 — descubra o volume

Temos:

100 operações/dia

ou:

10.000 operações/segundo?

Passo 3 — determine a latência

Pode levar:

10 segundos?
1 segundo?
100 ms?
20 ms?

Passo 4 — descubra o estado

Precisamos manter informações entre execuções?

Onde?

Passo 5 — determine consistência

É aceitável que dois sistemas fiquem temporariamente diferentes?

Passo 6 — analise as transações

Precisamos alterar vários recursos atomicamente?

Passo 7 — analise escalabilidade

Qual componente realmente precisa crescer?

Passo 8 — pense em falhas

Pergunte:

E se a rede cair?

E se houver timeout?

E se a mensagem chegar duas vezes?

E se o consumidor ficar indisponível?

E se o banco responder e a confirmação desaparecer?

Essa talvez seja uma das melhores formas de pensar como arquiteto.

---

🏗️ CAPÍTULO 20 — A ARQUITETURA REAL NÃO CABE NAS TRÊS COLUNAS

Uma arquitetura corporativa moderna pode ser:

                    MOBILE
                       |
                       v
                  API GATEWAY
                       |
            +----------+----------+
            |                     |
            v                     v
      MICROSERVICES          SERVERLESS
            |                     |
            +----------+----------+
                       |
                       v
                 EVENT STREAM
                       |
                       v
                      MQ
                       |
                       v
              +----------------+
              |   IBM Z        |
              |----------------|
              | CICS           |
              | IMS            |
              | COBOL          |
              | Db2            |
              | VSAM           |
              +----------------+

Agora desaparece aquela velha guerra:

MAINFRAME
   VS
CLOUD

Essa pergunta é pobre.

A pergunta melhor é:

Qual workload deve executar onde?

Essa é uma pergunta de arquiteto.

---

🥚 EASTER EGG — 03:17 DA MADRUGADA

Às 03:17, o telefone toca.

Produção.

O dashboard está verde.

O cliente diz que pagamentos estão sendo duplicados.

O jovem aventureiro verifica Kubernetes.

Tudo verde.

Verifica API Gateway.

Verde.

Microservices.

Verdes.

Serverless.

Verde.

MQ.

Verde.

CICS.

Verde.

Então Rick pergunta:

— Qual é o CORRELATION-ID da transação?

Silêncio.

Descobrem que um timeout fez o cliente repetir uma requisição e o Payment Service não tratava adequadamente a repetição.

A transação foi processada duas vezes.

Rick fecha o notebook.

Não existe arquitetura suficientemente moderna para compensar uma regra transacional mal compreendida.

03:17.

Incidente encerrado.

Quem acompanha o Bellacosa Mainframe sabe que esse horário nunca aparece por acaso. ☕😈

---

🎓 CAPÍTULO 21 — O QUE O PROGRAMADOR COBOL INICIANTE PRECISA APRENDER

Não abandone COBOL para correr atrás de todas as palavras da moda.

Expanda o mapa.

Comece com:

COBOL
JCL
VSAM
Db2
CICS

Depois acrescente:

TCP/IP
HTTP
REST
JSON
APIs

Depois:

MQ
Mensageria
Eventos
Kafka/Event Streaming

Depois:

Git
CI/CD
Containers
Microservices
Cloud
Serverless

E finalmente conecte tudo:

COBOL
   |
   +------ CICS
   |
   +------ Db2
   |
   +------ VSAM
   |
   +------ MQ
   |
   +------ APIs
   |
   +------ Events
   |
   +------ Microservices
   |
   +------ Cloud

Nesse momento você deixa de enxergar apenas um programa.

Começa a enxergar arquitetura.

---

⚔️ EPÍLOGO — O OSSAN NÃO PRECISAVA SER O MAIS JOVEM DA GUILDA

Rick Gladiator não é interessante porque começou cedo.

É justamente o contrário.

Ele lembra que experiência, disciplina e treinamento podem alterar completamente aquilo que aparentemente parecia uma desvantagem.

Existe uma bela analogia com Mainframe.

O programador olha para:

COBOL
CICS
VSAM
Db2
JCL

e alguém diz:

— Isso é velho.

Então ele olha para:

transactions
workload management
resource management
messaging
security
high availability
event processing

e percebe:

— Espere um pouco...

Muitos dos problemas que a computação moderna está tentando resolver não são novos.

As ferramentas mudaram.

As abstrações mudaram.

Os nomes ficaram mais bonitos.

Os slides ganharam cores.

Mas continuamos tentando responder perguntas antigas:

Como executar trabalho?

Como dividir responsabilidades?

Como mover dados?

Como sobreviver a falhas?

Como escalar?

Como garantir uma transação?

Como descobrir onde alguma coisa deu errado?

E é por isso que a pergunta definitiva não deveria ser:

Monolith
     VS
Microservices
     VS
Serverless

A pergunta deveria ser:

QUAL ARQUITETURA RESOLVE MELHOR ESTE PROBLEMA?

Às vezes será um monólito modular.

Às vezes serão microservices.

Às vezes serverless.

Às vezes CICS e COBOL.

E, em sistemas empresariais de verdade, frequentemente será:

              +----------------+
              | MICROSERVICES  |
              +-------+--------+
                      |
SERVERLESS -------- EVENTS
                      |
                     MQ
                      |
              +-------+--------+
              |      CICS      |
              +-------+--------+
                      |
                    COBOL
                      |
               +------+------+
               |             |
              Db2           VSAM

O programador iniciante entrou na dungeon procurando descobrir qual arquitetura era "a moderna".

Saiu dela entendendo algo muito mais importante:

Arquitetura não é escolher a tecnologia mais nova. É compreender suficientemente bem o problema para saber onde cada tecnologia pertence.

Rick pega a espada.

O velho COBOL compila.

O CICS continua processando transações.

O microservice publica um evento.

A função serverless acorda.

MQ entrega uma mensagem.

Db2 confirma o COMMIT.

E, em algum canto escuro da dungeon, alguém propõe transformar os 847 programas COBOL em 847 microservices porque viu isso numa apresentação.

Rick olha para o programador.

O programador olha para Rick.

IF ARCHITECTURE-BY-HYPE
    MOVE 'RUN!' TO RECOMMENDATION
END-IF.

☕⚔️ Bem-vindo ao Bellacosa Mainframe. Aqui até o aventureiro Rank F aprende que o monstro mais perigoso da arquitetura continua sendo uma solução procurando um problema.

 

☕ Um Café no Bellacosa Mainframe

🧙‍♂️ GANDALF E O VSAM QUE ATRAVESSOU AS ERAS

COBOL, KSDS, ESDS, RRDS, CI, CA, buffers, LSR, RLS, DFSMS, Extended Format, encryption, zHyperLink, DS8000, IBM z17 — e o dia em que um jovem programador descobriu que o arquivo de 50 anos atrás ainda não estava pronto para se aposentar.

Sob a tutela de Gandalf

---

🎬 PRÓLOGO — VOCÊ NÃO PASSARÁ... SEM ENTENDER O VSAM!

Imagine um jovem programador COBOL chegando pela primeira vez diante de um IBM z17.

Ele olha para aquela máquina moderna, lê sobre processadores poderosos, criptografia, inteligência artificial, aceleração de I/O, APIs, containers, Linux, cloud e uma quantidade quase assustadora de tecnologias.

Então abre um programa COBOL.

E encontra isto:

SELECT CLIENTES
       ASSIGN TO CLIENTES
       ORGANIZATION IS INDEXED
       ACCESS MODE IS RANDOM
       RECORD KEY IS COD-CLIENTE.

Mais abaixo:

MOVE 123456 TO COD-CLIENTE.

READ CLIENTES
    INVALID KEY
        DISPLAY 'CLIENTE NAO ENCONTRADO'
END-READ.

Ele olha novamente para o z17.

Olha para o programa.

Olha para o z17.

— Gandalf... não está faltando alguma coisa?

O velho mago apoia o cajado no chão.

— Não.

— Mas isso parece o mesmo COBOL que alguém poderia ter escrito décadas atrás!

Gandalf sorri.

— Exatamente.

E aqui começa nossa aventura.

Porque talvez a coisa mais impressionante sobre VSAM no IBM z17 seja justamente aquilo que não mudou.

O programa continua dizendo:

READ CLIENTES

Só que o universo existente entre esse READ e os dados tornou-se extraordinariamente sofisticado.

Prepare o café.

Pegue o cajado.

Hoje vamos atravessar a Terra-média do DFSMS.

---

🧙 CAPÍTULO 1 — A PERGUNTA ERRADA: "QUAL É O NOVO VSAM DO z17?"

Quando uma nova geração IBM Z aparece, é natural perguntar:

O que mudou no VSAM?

Talvez imaginemos algo chamado:

VSAM 17

ou:

VSAM Next Generation

Talvez esperemos encontrar um comando COBOL novo:

READ CLIENTES
    WITH-Z17-TURBO-MODE
END-READ.

Não existe.

E isso não é uma deficiência.

É uma das maiores virtudes da arquitetura.

O IBM z17 não representa uma reinvenção da interface lógica do VSAM.

Continuamos reconhecendo conceitos históricos:

KSDS
ESDS
RRDS
LDS

Control Interval
Control Area

INDEX
AIX
PATH

READ
WRITE
REWRITE
DELETE
START
READ NEXT

Portanto, se você aprendeu VSAM em uma geração anterior do IBM Z, seu conhecimento não virou cinzas quando o z17 apareceu.

Gandalf poderia resumir assim:

"Nem toda tecnologia antiga precisa morrer para que o mundo evolua."

O segredo está nas camadas inferiores.

---

🗺️ CAPÍTULO 2 — O MAPA DA TERRA-MÉDIA DO VSAM

Quando ensinamos VSAM para iniciantes, geralmente desenhamos:

COBOL
  |
  v
VSAM
  |
  v
DISCO

Isso é útil.

Mas é como representar toda a Terra-média desenhando apenas:

CONDADO
   |
MORDOR

Há muita coisa no caminho.

Em um ambiente moderno, podemos imaginar algo mais próximo disto:

                 APLICAÇÃO
                     |
                   COBOL
                     |
            +--------+--------+
            |                 |
          BATCH              CICS
            |                 |
            +--------+--------+
                     |
                    VSAM
                     |
          +----------+----------+
          |          |          |
         NSR        LSR        RLS
                                |
                             SMSVSAM
                     |
                   DFSMS
                     |
             BUFFER MANAGEMENT
                     |
               MEDIA MANAGER
                     |
                I/O SERVICES
                     |
                  CACHE
                     |
               zHyperLink
                     |
                  DS8000
                     |
                   FLASH

Agora nossa pergunta muda.

Não é apenas:

"VSAM ficou diferente?"

Passa a ser:

"O que aconteceu com todas as camadas que atendem aquele velho READ COBOL?"

Essa é uma pergunta muito mais interessante.

---

🔑 CAPÍTULO 3 — KSDS: O ANEL CONTINUA SENDO O ANEL

Vamos começar pelo conhecido.

Um KSDS — Key Sequenced Data Set — permite localizar registros através de uma chave.

Imagine:

CUSTOMER.KSDS

contendo:

000001  BILBO BAGGINS
000002  FRODO BAGGINS
000003  SAMWISE GAMGEE
000004  PEREGRIN TOOK
000005  MERIADOC BRANDYBUCK

Seu programa pode fazer:

MOVE 000003 TO CUSTOMER-ID.

READ CUSTOMER-FILE
    KEY IS CUSTOMER-ID
END-READ.

O COBOL não precisa conhecer o endereço físico daquele registro.

É justamente para isso que existe VSAM.

Conceitualmente:

KEY
 |
 v
INDEX
 |
 v
SEQUENCE SET
 |
 v
DATA
 |
 v
RECORD

E aqui aparece uma primeira lição importante.

O programador trabalha com:

KEY -> RECORD

O VSAM resolve o restante.

---

📦 CAPÍTULO 4 — CONTROL INTERVAL: A CAIXA QUE CARREGA SEUS REGISTROS

Um registro VSAM não está simplesmente flutuando sozinho no storage.

Precisamos conhecer o Control Interval, nosso famoso CI.

Simplificando:

CONTROL INTERVAL
+-----------------------------------+
| RECORD | RECORD | RECORD | FREE   |
+-----------------------------------+

Vários CIs formam uma estrutura maior chamada Control Area, CA.

CONTROL AREA
|
+-- CI 01
+-- CI 02
+-- CI 03
+-- CI 04
+-- CI 05

Portanto:

REGISTRO
   ↓
CONTROL INTERVAL
   ↓
CONTROL AREA
   ↓
VSAM DATA SET

Essa organização continua fundamental.

E ela será importante quando chegarmos ao zHyperLink.

Guarde o CI no bolso.

Voltaremos a ele.

---

💥 CAPÍTULO 5 — O BALROG CHAMADO CI SPLIT

Imagine:

+-----------------------------+
| A | B | C | D | FREE        |
+-----------------------------+

Há espaço disponível.

Novos registros entram.

Depois temos:

+-----------------------------+
| A | B | C | D | E | F      |
+-----------------------------+

Chega outro registro que precisa ser colocado naquela sequência lógica.

Não existe espaço adequado.

O VSAM pode precisar realizar um:

CI SPLIT.

Em situações maiores podemos chegar a:

CA SPLIT.

E Gandalf aparece diante do Balrog:

"YOU SHALL NOT PASS!"

Infelizmente, o novo registro responde:

"Tenho WRITE autorizado pelo RACF."

E passa.

Brincadeiras à parte, splits podem ter impacto operacional e de performance.

Por isso existem parâmetros como:

FREESPACE

e decisões sobre:

CI SIZE
CA SIZE

Um z17 não elimina magicamente um dataset mal planejado.

Hardware mais rápido não substitui arquitetura.

---

🧠 CAPÍTULO 6 — O I/O MAIS RÁPIDO É AQUELE QUE NÃO EXISTE

Aqui está uma das dicas mais importantes deste artigo.

Imagine:

READ CUSTOMER
      |
      v
    VSAM
      |
      v
   STORAGE

Talvez você pense:

Precisamos acelerar o storage!

Calma, jovem Hobbit.

Primeiro pergunte:

Por que estamos indo ao storage?

Se a informação necessária já estiver disponível em buffer/cache, podemos evitar determinado acesso físico.

Conceitualmente:

READ
 |
 v
BUFFER?
 |
 +--- HIT ---> RECORD
 |
 +--- MISS --> I/O

Compare:

READ
 ↓
I/O
 ↓
STORAGE
 ↓
RETURN

com:

READ
 ↓
BUFFER HIT
 ↓
RETURN

É por isso que buffering continua tão importante.

Não adianta possuir um storage absurdamente rápido se a aplicação estiver produzindo I/O desnecessário.

---

🧙‍♂️ CAPÍTULO 7 — NSR, LSR E RLS: TRÊS MAGOS CHEGAM À REUNIÃO

Você encontrará três siglas importantes no universo VSAM:

NSR
LSR
RLS

NSR — Non-Shared Resources

É o modelo convencional em que recursos utilizados no acesso ficam associados ao processamento daquele dataset/contexto.

LSR — Local Shared Resources

Permite compartilhamento de pools de buffers entre datasets VSAM dentro do contexto apropriado. É particularmente conhecido no universo CICS.

RLS — Record Level Sharing

Aqui nossa aventura cresce bastante.

Agora podemos pensar em múltiplos acessos compartilhados:

          CICS A
             |
             |
CICS B ---- VSAM ---- CICS C
             |
             |
          CICS D

E começam a aparecer problemas que não existem quando imaginamos apenas:

PROGRAMA -> ARQUIVO

Agora precisamos pensar em:

locking
serialization
sharing
consistency
recovery

Bem-vindo ao VSAM de produção.

---

🌍 CAPÍTULO 8 — A SOCIEDADE DO ANEL ENCONTRA O PARALLEL SYSPLEX

Imagine três sistemas:

LPAR A
  |
CICS A
  |
  +-----------+
              |
LPAR B        |
  |           |
CICS B -------+---- VSAM
              |
LPAR C        |
  |           |
CICS C -------+

Não queremos necessariamente limitar determinado dado a uma única região CICS ou sistema.

Em arquiteturas de alta disponibilidade e compartilhamento, RLS torna-se extremamente importante.

Agora aquele inocente:

READ CUSTOMER-FILE

faz parte de um universo distribuído dentro da arquitetura do próprio mainframe.

Isso é algo que surpreende muitos iniciantes.

VSAM não precisa significar:

"Um arquivo usado por um programa."

Pode participar de uma infraestrutura extremamente sofisticada.

---

🏦 CAPÍTULO 9 — DFSMStvs: QUANDO VSAM APRENDE TRANSAÇÕES MAIS SOFISTICADAS

Agora chegamos a uma tecnologia que muitos programadores COBOL passam anos sem conhecer:

DFSMStvs — Transactional VSAM Services.

Imagine:

             CUSTOMER.KSDS
                  |
          +-------+-------+
          |               |
        CICS             BATCH
          |               |
        UPDATE          UPDATE
          |               |
          +-------+-------+
                  |
               DFSMStvs

O problema já não é simplesmente ler um registro.

Queremos coordenação transacional, recuperação e compartilhamento apropriado entre workloads.

Isso não transforma VSAM em Db2.

Repita comigo:

VSAM não virou Db2.

Mas também mostra como é inadequado chamar VSAM simplesmente de:

"arquivo velho do COBOL".

Existe muita infraestrutura ao redor dele.

---

⚡ CAPÍTULO 10 — GANDALF DESCOBRE O zHYPERLINK

Agora chegamos a uma das partes mais interessantes da história.

zHyperLink.

Tradicionalmente, pensamos em I/O aproximadamente assim:

CPU
 |
 v
I/O REQUEST
 |
 v
I/O INFRASTRUCTURE
 |
 v
STORAGE
 |
 v
COMPLETION
 |
 v
APPLICATION

A arquitetura assíncrona de I/O é uma das grandes forças históricas do mainframe.

A CPU não deveria simplesmente ficar sentada olhando para um dispositivo lento.

Só que storage mudou dramaticamente.

Memória, cache e flash mudaram as relações de tempo.

Em determinadas situações, tornou-se interessante oferecer um caminho de synchronous I/O de baixíssima latência.

Entra zHyperLink.

Simplificando brutalmente:

             VSAM READ
                 |
                 v
         operação elegível?
                 |
                SIM
                 |
                 v
            zHyperLink
                 |
                 v
          STORAGE CACHE
                 |
                 v
             RESPONSE

E isso pode reduzir significativamente a latência para operações elegíveis.

---

🧩 CAPÍTULO 11 — O CI QUE GUARDAMOS NO BOLSO VOLTOU

Lembra do Control Interval?

Agora ele volta à história.

Porque existe relação entre quantidade de dados da operação e elegibilidade para determinados caminhos de I/O.

No ambiente moderno, parâmetros relacionados ao zHyperLink permitem controlar limites de leitura e explorar capacidades mais recentes de aceleração.

Portanto algo que aprendemos no primeiro curso de VSAM:

CI SIZE

continua conversando com uma infraestrutura que surgiu décadas depois.

Veja a beleza disso:

         DESIGN VSAM
              |
           CI SIZE
              |
              v
       TAMANHO DA LEITURA
              |
              v
        MEDIA MANAGER
              |
              v
       I/O ELIGIBILITY
              |
              v
         zHyperLink

Um conceito antigo continua relevante em uma máquina moderníssima.

Isso é mainframe.

---

⚠️ CAPÍTULO 12 — NÃO USE MAGIA SEM SABER O FEITIÇO

Neste momento alguém certamente perguntará:

Então devemos mudar todos os CIs para 16K?

NÃO!

Gandalf bate o cajado no chão.

Esse é exatamente o tipo de tuning que produz desastre:

ALGUÉM DISSE QUE 16K É MAIS RÁPIDO

Logo:

ALTERE TUDO!

Não.

O comportamento depende de:

record size
access pattern
random access
sequential access
insert rate
free space
buffering
RLS
cache
workload

Uma aplicação fazendo:

READ RANDOM
READ RANDOM
READ RANDOM

não possui necessariamente o mesmo perfil de:

START
READ NEXT
READ NEXT
READ NEXT
READ NEXT

E nenhuma das duas é necessariamente equivalente a uma carga massiva de inserções.

Meça antes de mudar.

Essa é uma das regras de ouro do mainframe.

---

📊 CAPÍTULO 13 — SMF E RMF: AS PALANTÍRI DA PERFORMANCE

Gandalf não faz tuning dizendo:

"Tenho a impressão de que está mais lento."

Ele consulta as Palantíri.

No z/OS temos instrumentos muito melhores:

SMF
RMF

Se você migrou determinada carga para uma plataforma mais nova e deseja saber o que aconteceu, investigue.

Observe coisas como:

CPU
elapsed time
I/O rate
I/O response time
EXCP
cache behavior
buffer behavior
locking
RLS activity
synchronous I/O
CI/CA splits

O método correto é:

BASELINE
   |
   v
MUDANÇA
   |
   v
NOVA MEDIÇÃO
   |
   v
COMPARAÇÃO
   |
   v
CONCLUSÃO

Não:

MIGRAMOS PARA z17
       |
       v
DEVE ESTAR MAIS RÁPIDO

"Deve" é uma palavra perigosa em Capacity Planning.

---

🏎️ CAPÍTULO 14 — MÁQUINA MAIS RÁPIDA NÃO SIGNIFICA TRANSAÇÃO MAIS RÁPIDA

Considere:

CUSTOMER.KSDS

200.000.000 registros

e:

CICS
8.000 READs/s

Migramos para uma infraestrutura mais nova.

Depois descobrimos:

CPU ↓

Excelente!

Mas:

RESPONSE TIME =

praticamente igual.

Como?

Porque talvez a transação esteja esperando:

I/O

ou:

LOCK

ou:

MQ

ou:

Db2

ou:

NETWORK

ou:

API

ou outra dependência.

Performance é uma corrente.

Acelerar um elo que não é o gargalo não acelera necessariamente a corrente inteira.

---

🗜️ CAPÍTULO 15 — EXTENDED FORMAT: VSAM GANHOU UMA MOCHILA NOVA

Outro conceito que o iniciante precisa conhecer é Extended Format.

Pense:

VSAM
 |
 +-- Conventional
 |
 +-- Extended Format

Com Extended Format entram possibilidades importantes associadas ao gerenciamento moderno de datasets, incluindo recursos como:

Data Striping
Compression
Extended Addressability
Encryption
System Managed Buffering

Isso significa que dois programas podem enxergar:

CUSTOMER.KSDS

enquanto por baixo existem características bastante diferentes.

O programa continua:

READ CUSTOMER-FILE

A infraestrutura pode estar fazendo muito mais.

---

📏 CAPÍTULO 16 — 4 GB JÁ FOI O TAMANHO DE SMAUG

Hoje alguém olha para:

4 GB

e pensa:

Só isso?

Historicamente, 4 GB já representou um limite enorme.

À medida que datasets cresceram, mecanismos como Extended Addressability tornaram possível ultrapassar limitações tradicionais.

Essa é outra lição interessante da história do mainframe.

A arquitetura não foi criada prevendo tudo que existiria cinquenta anos depois.

Ela foi evoluída.

Pense na sequência:

VSAM
1970s
 |
1980s
 |
1990s
 |
2000s
 |
2010s
 |
2020s
 |
IBM z17

Pouquíssimas tecnologias de infraestrutura possuem uma linhagem operacional comparável.

---

🔐 CAPÍTULO 17 — O REGISTRO PODE ESTAR CRIPTOGRAFADO E O COBOL NEM SABE

Agora imagine:

READ CUSTOMER-FILE
END-READ.

O programa não contém:

DECRYPT CUSTOMER

nem:

CALL AES

nem precisa carregar manualmente uma biblioteca criptográfica para cada READ.

A proteção dos dados pode acontecer em camadas inferiores da infraestrutura.

Conceitualmente:

COBOL
  |
 VSAM
  |
DFSMS
  |
ENCRYPTION
  |
STORAGE

Essa separação de responsabilidades é poderosa.

O programador trabalha com:

registro

A plataforma trabalha com:

proteção do dado

Isso permite modernizar requisitos de segurança sem obrigatoriamente reescrever milhões de linhas de aplicação.

---

🧙‍♀️ CAPÍTULO 18 — SYSTEM MANAGED BUFFERING

Outro conceito importante é o System Managed Buffering — SMB.

O nome praticamente explica a proposta.

Em vez de depender exclusivamente de escolhas estáticas e históricas sobre buffers, permitimos que mecanismos do sistema participem da estratégia.

Voltemos à nossa regra:

O I/O mais rápido é aquele que não precisa acontecer.

Temos:

APPLICATION
     |
    VSAM
     |
   BUFFER
     |
   CACHE
     |
     I/O
     |
  STORAGE

Quanto mais cedo conseguirmos satisfazer a necessidade, melhor.

Mas novamente:

não existe configuração universal perfeita.

Batch sequencial não é CICS random.

Leitura não é inserção.

Arquivo pequeno não é arquivo gigantesco.

Performance engineering exige contexto.

---

☁️ CAPÍTULO 19 — E O VSAM COMEÇA A OLHAR PARA A CLOUD

Uma das direções interessantes do ecossistema moderno é permitir que dados tradicionalmente residentes no ambiente z/OS participem mais facilmente de outros fluxos.

A evolução do DFSMS e mecanismos de Cloud Data Access aproxima datasets do mundo de object storage e processos modernos de movimentação de dados.

O desenho conceitual começa a parecer:

VSAM
 |
DFSMS
 |
Cloud Data Access
 |
Object Storage

Isso muda nossa maneira de pensar modernização.

Durante anos, muita gente tratou modernização como:

REMOVER O MAINFRAME

Hoje existe uma abordagem muito mais interessante:

MANTER O QUE FUNCIONA
       +
INTEGRAR COM O NOVO

Gandalf aprovaria.

Não precisamos destruir Minas Tirith para instalar Wi-Fi.

---

🧬 CAPÍTULO 20 — VSAM, JSON E O MUNDO MODERNO

Outra fronteira interessante é a transformação de registros tradicionais em representações modernas.

Imagine um copybook:

01 CUSTOMER.
   05 CUSTOMER-ID    PIC 9(08).
   05 CUSTOMER-NAME  PIC X(40).
   05 CUSTOMER-CITY  PIC X(30).

O mundo COBOL enxerga isso perfeitamente.

Uma aplicação moderna talvez prefira:

{
  "customerId": 317,
  "customerName": "Gandalf",
  "customerCity": "Valfenda"
}

Esses dois universos não precisam necessariamente ser inimigos.

Podemos construir pontes:

COPYBOOK
   |
   v
RECORD
   |
   v
TRANSFORMATION
   |
   v
JSON

Esse é um dos princípios centrais da modernização contemporânea do mainframe:

Modernizar o acesso não significa obrigatoriamente substituir o dado.

---

🏛️ CAPÍTULO 21 — VSAM NÃO É UM BANCO RELACIONAL

Precisamos colocar uma placa gigantesca aqui.

VSAM != Db2

VSAM possui características extremamente poderosas:

indexed access
sequential access
direct access
buffering
sharing
locking infrastructure
recovery integration

Mas não oferece o modelo relacional do Db2.

No Db2 posso pensar:

SELECT NAME
FROM CUSTOMER
WHERE CITY = 'HOBBITON'
ORDER BY NAME;

Em um KSDS tradicional, a chave e a organização dos dados têm uma importância estrutural enorme.

VSAM é brilhante quando o problema é algo parecido com:

KEY
 |
 v
RECORD

Db2 resolve outra classe de problemas.

Escolher tecnologia significa entender o problema.

Não escolher a tecnologia mais nova.

---

🧓 CAPÍTULO 22 — "MAS VSAM NÃO É VELHO?"

Sim.

E essa pergunta sozinha não significa absolutamente nada.

Um martelo é velho.

A roda é velha.

SQL é velho.

TCP/IP é velho.

COBOL é velho.

Unix é velho.

A pergunta arquitetural correta é:

Resolve o problema adequadamente?

Imagine:

CICS
 |
COBOL
 |
VSAM KSDS

processando milhares de transações com:

alta disponibilidade
baixo response time
previsibilidade
recuperação
décadas de estabilidade

Qual é o business case para substituí-lo?

"É antigo" não é business case.

Agora, se existem problemas como:

alto custo operacional
dificuldade de integração
limitações funcionais
escassez de conhecimento
problemas de escalabilidade
requisitos novos

a conversa muda.

Arquitetura começa pelo problema.

---

🔬 CAPÍTULO 23 — PASSO A PASSO: INVESTIGANDO VSAM EM UM AMBIENTE MODERNO

Se você é um Padawan COBOL — ou Hobbit COBOL, já que Gandalf assumiu a aula — siga esta sequência.

Passo 1 — descubra a organização

Pergunte:

KSDS?
ESDS?
RRDS?
LDS?

Passo 2 — descubra como é acessado

Sequential?
Random?
Dynamic?

Passo 3 — descubra quem usa

Batch?
CICS?
Ambos?

Passo 4 — examine a definição

Procure entender:

KEYS
RECORDSIZE
CONTROLINTERVALSIZE
FREESPACE
SHAREOPTIONS
DATACLASS
STORCLAS
MGMTCLAS

Não saia alterando.

Primeiro entenda.

Passo 5 — descubra o buffering

Pergunte:

NSR?
LSR?
RLS?
SMB?

Passo 6 — descubra o comportamento

Observe:

READ
WRITE
REWRITE
DELETE
READ NEXT

Passo 7 — procure sinais de problema

Investigue:

I/O excessivo
splits
lock contention
response time
elapsed time
CPU
buffer misses

Passo 8 — use telemetria

Entre no mundo:

SMF
RMF
CICS statistics
VSAM statistics

Passo 9 — crie baseline

Nunca diga:

"Ficou melhor."

Diga:

ANTES
CPU       = X
I/O       = Y
ELAPSED   = Z
RESPONSE  = W

DEPOIS
CPU       = ...
I/O       = ...
ELAPSED   = ...
RESPONSE  = ...

Agora temos engenharia.

Passo 10 — mude UMA coisa

Não altere simultaneamente:

CI
FREESPACE
buffers
storage
programa
CICS

e depois pergunte qual alteração funcionou.

Você jamais saberá.

---

🎒 CAPÍTULO 24 — CURIOSIDADES PARA LEVAR NA MOCHILA

Curiosidade 1: VSAM surgiu na década de 1970 e continua operacionalmente relevante em plataformas IBM Z modernas.

Curiosidade 2: conceitos aparentemente antigos, como CI e CA, continuam importantes mesmo quando a infraestrutura utiliza flash, grandes caches e mecanismos modernos de I/O.

Curiosidade 3: um programa COBOL pode continuar usando praticamente a mesma lógica de acesso enquanto hardware, storage, segurança e sistema operacional mudaram várias gerações.

Curiosidade 4: VSAM pode participar de arquiteturas compartilhadas muito mais sofisticadas do que a caricatura "programa abre arquivo".

Curiosidade 5: acelerar CPU não necessariamente reduz response time quando o gargalo está em I/O, locks ou outra dependência.

Curiosidade 6: evitar um I/O geralmente é mais interessante do que simplesmente tornar aquele I/O mais rápido.

---

🥚 CAPÍTULO 25 — O EASTER EGG DAS 03:17

São 03:17 da madrugada.

O telefone toca.

Produção.

O operador informa:

"O CICS está lento."

O jovem programador pergunta:

— Deve ser CPU?

Gandalf responde:

— Não sabemos.

— Storage?

— Não sabemos.

— VSAM?

— Não sabemos.

— Então o que fazemos?

Gandalf olha para o monitor e responde:

"Um mago não adivinha um gargalo. Ele chega exatamente quando as métricas dizem onde procurar."

Abrimos SMF.

Analisamos RMF.

O processador estava tranquilo.

Storage também.

Depois de muita investigação...

...descobrimos uma aplicação segurando locks muito mais tempo do que deveria.

O jovem olha para Gandalf.

— Então comprar um z17 maior não resolveria?

Gandalf acende o cachimbo.

— Agora você está começando a entender performance.

---

🧭 CAPÍTULO 26 — O QUE REALMENTE MUDOU?

Finalmente podemos responder à pergunta original.

Para o programador COBOL?

Pouco.

Ele continua conhecendo:

OPEN
READ
WRITE
REWRITE
DELETE
START
READ NEXT
CLOSE

Para a organização lógica?

Continuamos reconhecendo:

KSDS
ESDS
RRDS
LDS
CI
CA
AIX
PATH

Para a infraestrutura?

A história é completamente diferente.

Temos um universo envolvendo:

DFSMS
Extended Format
SMB
RLS
DFSMStvs
compression
encryption
cache
Media Manager
zHyperLink
modern storage
Parallel Sysplex
Cloud Data Access

É aqui que está a evolução.

---

🧙‍♂️ EPÍLOGO — O VSAM NÃO PRECISOU SE TORNAR OUTRA COISA

Ao final da aventura, nosso jovem programador retorna ao mesmo código:

MOVE CUSTOMER-ID TO WS-CUSTOMER-ID.

READ CUSTOMER-FILE
    INVALID KEY
       DISPLAY 'NOT FOUND'
END-READ.

Agora ele não enxerga apenas quatro linhas de COBOL.

Enxerga:

                   COBOL
                     |
                   READ
                     |
                    VSAM
                     |
             +-------+-------+
             |       |       |
            NSR     LSR     RLS
                             |
                          SMSVSAM
                     |
                   DFSMS
                     |
             EXTENDED FORMAT
                     |
                 BUFFERING
                     |
                MEDIA MANAGER
                     |
                 I/O SERVICES
                     |
                  zHyperLink
                     |
                    CACHE
                     |
                   DS8000
                     |
                 IBM Z17

E finalmente entende por que VSAM ainda é fascinante.

A genialidade não está em permanecer congelado em 1974.

Está em permitir que a interface conhecida pela aplicação sobreviva enquanto praticamente todo o universo existente debaixo dela evolui.

O programa pede:

READ

VSAM responde:

"Deixe comigo."

E entre essas duas frases podem existir cinquenta anos de engenharia.

Gandalf pega o cajado e começa a caminhar em direção ao próximo sistema.

O jovem programador pergunta:

— Mestre, então nunca devemos substituir VSAM?

Gandalf para.

Olha para trás.

— Eu não disse isso.

— Então quando devemos substituir?

O velho mago sorri.

"Quando você conseguir demonstrar qual problema está tentando resolver."

Silêncio no datacenter.

Nenhum Balrog.

Nenhum ABEND.

Apenas o som distante de um job terminando:

IEF142I JOB STEP WAS EXECUTED
COND CODE 0000

E em algum lugar de uma LPAR, um programa escrito décadas atrás executa novamente:

READ CUSTOMER-FILE

sobre uma infraestrutura que seu autor jamais poderia ter imaginado.

☕ Moral da história

No mainframe, compatibilidade não significa ausência de inovação.

Às vezes é justamente o contrário.

A maior demonstração de engenharia é permitir que tudo mude sem obrigar aquilo que funciona a mudar junto.

E antes de sair alterando CISIZE, FREESPACE, buffers ou qualquer outra coisa porque alguém prometeu performance...

lembre-se da primeira regra de Gandalf para o jovem analista de performance:

"Você não passará... para produção sem medir primeiro."

 

☕ Um Café no Bellacosa Mainframe

🎩 O CHAPELEIRO MALUCO E O PAÍS DAS PORTAS DOS FUNDOS

RACF, Zero Trust, jatinhos, VIPs, compliance, conflitos de interesse, despesas de representação, audit trail, Red Team — e o dia em que Alice descobriu que o sistema estava perfeitamente protegido contra todo mundo, exceto contra quem tinha poder suficiente para pedir uma exceção.

---

🎬 PRÓLOGO — ALICE CAIU NO BURACO ERRADO

Alice já conhecia o País das Maravilhas.

Coelhos atrasados.

Gatos que desapareciam.

Rainhas temperamentais.

Cartas de baralho que falavam.

Nada daquilo a surpreendia mais.

Até que encontrou uma porta onde estava escrito:

SECURITY — AUTHORIZED PERSONNEL ONLY

Alice tentou entrar.

A porta não abriu.

Uma tela verde respondeu:

ICH408I USER ALICE
NOT AUTHORIZED TO RESOURCE

— Excelente! — disse Alice. — Finalmente encontrei um lugar organizado.

Então apareceu um homem importante.

Tentou entrar.

A porta também não abriu.

ICH408I USER VIP001
NOT AUTHORIZED TO RESOURCE

Alice sorriu.

— Pelo menos as regras são iguais.

O homem aproximou-se do funcionário responsável pela porta e perguntou:

— Você sabe com quem está falando?

O funcionário empalideceu.

Pegou o telefone.

Cinco minutos depois, a porta abriu.

Alice ficou olhando.

Nesse momento surgiu o Chapeleiro Maluco carregando uma xícara de café.

— Bem-vinda à segurança corporativa, Alice.

— Mas o sistema negou!

— Exatamente.

— Então como ele entrou?

O Chapeleiro tomou um gole.

— O computador disse não. O organograma disse sim.

Eram exatamente 03:17.

---

🐇 CAPÍTULO 1 — O QUE APRENDEMOS COM O COELHO BRANCO?

Nossa conversa começou com um caso contemporâneo envolvendo um banco, seu controlador, autoridades, familiares, contratos, viagens e relações sociais.

Mas rapidamente percebemos que o assunto era muito maior.

As investigações envolvendo o Banco Master revelaram publicamente uma extensa rede de relacionamentos envolvendo diferentes setores do poder brasileiro. Isso não significa que toda pessoa mencionada tenha cometido irregularidade; contatos, contratos, viagens ou relações profissionais precisam ser examinados individualmente e com devido processo.

O verdadeiro aprendizado não está em perguntar:

“Quem conhece quem?”

Está em perguntar:

“Nosso sistema institucional consegue identificar quando um relacionamento legítimo começa a produzir conflito de interesses?”

Essa pergunta serve para Brasília.

Serve para bancos.

Serve para empresas.

E serve perfeitamente para o mainframe.

---

🔐 CAPÍTULO 2 — RACF NÃO PROTEGE CONTRA ORGANOGRAMA

Imagine que você está começando como programador COBOL.

Seu programa processa pagamentos.

O dataset é:

PROD.PAYROLL.MASTER

Seu USERID possui apenas:

READ

Você tenta alterar.

RACF responde:

ICH408I
NOT AUTHORIZED

Excelente.

Agora imagine que o presidente da empresa tente fazer a mesma coisa.

Tecnicamente, deveria acontecer exatamente a mesma coisa.

O RACF não deveria pensar:

“Nossa! É o presidente!”

Para o sistema, existem:

identidade → autenticação → autorização.

Cargo não substitui nenhuma delas.

Esse conceito precisa sair do mainframe e entrar na governança das organizações.

---

🪪 CAPÍTULO 3 — IDENTIDADE NÃO É AUTORIZAÇÃO

Essa talvez tenha sido a principal descoberta de toda nossa conversa.

Existem três conceitos diferentes:

Identificação

Quem você afirma ser?

USERID = ALICE

Autenticação

Você consegue provar que realmente é Alice?

Senha.

MFA.

Certificado.

Biometria.

Passkey.

Autorização

Alice pode executar aquela operação?

PERMIT ALICE
       CLASS(DATASET)
       ACCESS(READ)

É perfeitamente possível possuir:

IDENTITY       = VALID
AUTHENTICATION = SUCCESS
AUTHORIZATION  = DENIED

E isso não representa erro.

Representa segurança funcionando.

O problema aparece quando acrescentamos uma quarta variável:

STATUS = VIP

E alguém decide que VIP significa:

ACCESS = ALTER

Não deveria.

---

🎩 CAPÍTULO 4 — “VOCÊ SABE COM QUEM ESTÁ FALANDO?”

O Chapeleiro colocou quatro xícaras sobre a mesa.

Na primeira escreveu:

Política.

Na segunda:

Procedimento.

Na terceira:

Tecnologia.

Na quarta:

Cultura.

— Qual delas controla a empresa? — perguntou Alice.

— Política?

— Errado.

— Tecnologia?

— Também.

O Chapeleiro apontou para a quarta.

Cultura.

Uma organização pode possuir a política:

Ninguém entra sem autorização.

Mas possuir simultaneamente a cultura:

Não crie problema para diretor.

Qual das duas vence?

Normalmente a segunda.

Isso cria aquilo que poderíamos chamar de:

Shadow Security Policy

A política invisível.

Ela nunca foi aprovada.

Não existe PDF.

Não existe versão.

Não existe owner.

Mas todo funcionário aprende.

---

🧨 CAPÍTULO 5 — O FUNCIONÁRIO QUE DISSE NÃO

Nossa conversa trouxe um exemplo perfeito.

Um diretor solicitou determinado acesso.

O responsável sabia exatamente quem ele era.

Mas não havia autorização adequada.

A resposta foi:

não.

Só que não terminou aí.

Foi solicitado um e-mail formal.

Enquanto isso, houve confirmação independente com a pessoa competente para autorizar.

Isso é excelente segurança.

O fluxo ficou:

REQUEST
   |
   v
IDENTITY CONFIRMED
   |
   v
AUTHORIZATION MISSING
   |
   v
ACCESS DENIED
   |
   v
EXCEPTION REQUEST
   |
   v
INDEPENDENT VALIDATION
   |
   v
DOCUMENTED APPROVAL
   |
   v
CONTROLLED ACCESS

Observe algo importante:

o funcionário não decidiu conceder privilégio.

Quem possuía autoridade assumiu formalmente a responsabilidade.

Isso é accountability.

---

😡 CAPÍTULO 6 — QUANDO O DIRETOR FICA OFENDIDO

Só que existe um problema.

O diretor pode interpretar:

controle = desconfiança

ou:

procedimento = humilhação

ou:

registro = burocracia.

Se depois retaliar quem aplicou corretamente o procedimento, algo extremamente perigoso acontece.

Os demais funcionários aprendem.

Não através de treinamento oficial.

Aprendem observando.

A próxima pessoa importante aparece.

O funcionário lembra:

“Da última vez alguém seguiu a política e se ferrou.”

Então libera.

Nesse momento a empresa possui uma vulnerabilidade que:

Nessus não encontra.

Qualys não encontra.

SIEM não encontra.

Penetration test tradicional talvez não encontre.

Porque a vulnerabilidade está na cultura de poder.

---

✈️ CAPÍTULO 7 — ALICE ENCONTRA UM JATINHO

Depois apareceu o avião executivo.

Aqui descobrimos outra coisa importante.

Privacidade não é necessariamente anonimato.

Aviação executiva possui controles e regulamentação próprios, diferentes em vários aspectos do fluxo comercial comum.

Mas para governança existe uma pergunta essencial:

Conseguimos reconstruir posteriormente quem utilizou determinado recurso, quem autorizou e quem pagou?

Isso vale para avião.

Vale para carro corporativo.

Vale para hotel.

Vale para cartão empresarial.

Vale para dataset.

Vale para transação CICS.

Vale para API.

O nome técnico disso é:

Audit Trail

---

📜 CAPÍTULO 8 — SMF PARA O MUNDO REAL

No z/OS temos algo maravilhoso:

SMF — System Management Facilities.

O sistema registra acontecimentos.

Jobs.

Logons.

Uso de recursos.

Segurança.

Performance.

Accounting.

Agora imagine aplicar mentalidade semelhante à governança.

Queremos responder:

WHO?
WHAT?
WHEN?
WHERE?
WHY?
WHO AUTHORIZED?
WHO PAID?
WHO BENEFITED?

Isso é praticamente um SMF institucional.

E existe uma lição extraordinária:

quanto maior o privilégio, maior deveria ser a auditabilidade.

Muitas organizações fazem exatamente o contrário.

Funcionário comum:

30 controles.

Diretor:

“Pode deixar passar.”

Deveria ser:

mais poder → mais accountability.

---

🍽️ CAPÍTULO 9 — O JANTAR QUE TALVEZ NÃO FOSSE JANTAR

Chegamos então às despesas de representação.

Hospitalidade empresarial existe.

Jantares existem.

Eventos existem.

Viagens existem.

Relacionamento comercial existe.

Nada disso é automaticamente irregular.

Mas descobrimos outra diferença fundamental:

DOCUMENT EXISTS

não significa:

DOCUMENT REPRESENTS REALITY

Um compliance superficial verifica:

✔ nota fiscal
✔ centro de custo
✔ aprovação
✔ fornecedor
✔ valor

E encerra.

Um Red Team pergunta:

A natureza econômica da operação corresponde ao documento?

Essa pergunta muda tudo.

---

🧾 CAPÍTULO 10 — COMPLIANCE NÃO É COLECIONAR PDFs

Imagine:

REALIDADE       = A
DOCUMENTO       = B
ERP             = B
CONTABILIDADE   = B
RELATÓRIO       = B
AUDITORIA       = B

Todos os sistemas concordam.

Todos podem estar errados.

Por quê?

Porque todos receberam a mesma informação inicial.

Programadores conhecem isso há décadas:

Garbage In, Garbage Out.

Compliance também sofre de GIGO.

---

⚖️ CAPÍTULO 11 — A TOGA NÃO É SUPERUSER

Chegamos então à magistratura.

Aqui precisamos abandonar personagens específicos e pensar institucionalmente.

O Código de Ética da Magistratura Nacional estabelece princípios como independência, imparcialidade, transparência e integridade. Determina também que o magistrado mantenha distância equivalente das partes e evite comportamento que possa refletir favoritismo.

Isso é praticamente Zero Trust jurídico.

Não significa:

“Desconfie de todo juiz.”

Significa:

Construa mecanismos que não dependam exclusivamente da confiança pessoal.

Aliás, o próprio STF anunciou em fevereiro de 2026 a elaboração de seu Código de Ética específico, mencionando explicitamente prevenção de conflitos de interesse, transparência, responsabilidade e confiança pública.

O CNJ também avançou em 2026 numa proposta específica para identificação, declaração e tratamento de conflitos de interesses, incluindo sistemas eletrônicos de prevenção e estruturas de aconselhamento ético.

Ou seja:

o problema estrutural está sendo reconhecido institucionalmente.

---

❤️ CAPÍTULO 12 — CONFIANÇA NÃO PODE SER A ÚNICA DEFESA

Alice perguntou:

— Então devemos desconfiar de todo mundo?

O Chapeleiro respondeu:

— Claro que não!

— Mas você acabou de falar de Zero Trust.

— Alice, Zero Trust não significa que todos são desonestos.

Significa que honestidade não substitui controle.

Essa distinção é maravilhosa.

Não colocamos senha porque acreditamos que todos são criminosos.

Não utilizamos RACF porque acreditamos que todos os programadores querem roubar dados.

Não fazemos backup porque esperamos que o storage exploda amanhã.

Controles existem porque sistemas resilientes não dependem de pessoas perfeitas.

---

🕵️ CAPÍTULO 13 — ENTRE O INTERESSE PÚBLICO E O NOTÍCIAS POPULARES

Nossa conversa passou também por intimidade.

Sexo.

Profissionais do sexo.

Festas.

Luxo.

E aí existe uma armadilha.

Esses elementos são excelentes para manchetes.

Mas podem distrair da verdadeira questão.

A pergunta relevante não deveria ser:

“Com quem determinada autoridade dormiu?”

A pergunta institucional é:

“Um terceiro interessado financiou um benefício privado?”

Se não financiou, a intimidade pode continuar sendo simplesmente intimidade.

Se financiou, aparecem perguntas sobre:

conflito de interesses → vantagem → independência → eventual contrapartida.

O sexo vira quase detalhe contábil.

O dinheiro torna-se interessante.

---

🔎 CAPÍTULO 14 — FOLLOW THE MONEY NÃO É SUFICIENTE

Todo mundo conhece:

Follow the money.

O Chapeleiro discorda.

— Incompleto!

Ele escreveu:

FOLLOW THE MONEY
FOLLOW THE ACCESS
FOLLOW THE RELATIONSHIP
FOLLOW THE DECISION
FOLLOW THE EXCEPTION

Esse é um modelo muito melhor.

Imagine:

EMPRESA
   |
   +-- pagamento
   |
INTERMEDIÁRIO
   |
   +-- benefício
   |
PESSOA COM PODER
   |
   +-- decisão
   |
RESULTADO

Uma seta isolada pode não significar absolutamente nada.

O grafo completo pode contar uma história.

---

🧠 CAPÍTULO 15 — O QUE AINDA NÃO DESCOBRIMOS?

Aqui precisamos ter disciplina.

Não podemos afirmar que existem fatos escondidos específicos sem evidência.

Mas podemos perguntar:

Que classes de risco ainda podem estar invisíveis?

Essa é exatamente a função de threat modeling.

Possibilidades genéricas:

relações indiretas não declaradas

beneficiários econômicos difíceis de identificar

presentes e hospitalidade

viagens

intermediários

consultorias

empresas relacionadas

familiares

fundos

associações

institutos

eventos privados

exceções não documentadas

aprovações verbais

conflitos de interesse não percebidos

O objetivo não é presumir culpa.

É construir controles capazes de detectar situações relevantes.

---

🔴 CAPÍTULO 16 — ENTRA O RED TEAM

Finalmente chegamos ao Red Team.

Muita gente pensa:

Red Team = hacker tentando invadir servidor.

É muito pouco.

Um Red Team maduro pergunta:

Como este sistema pode falhar?

E “sistema” pode significar organização.

Começamos criando adversários hipotéticos.

Cenário 1 — VIP

Uma pessoa poderosa pede exceção.

O funcionário cede?

Cenário 2 — relacionamento

Fornecedor possui amizade com decisor.

O conflito é declarado?

Cenário 3 — benefício

Terceiro oferece viagem ou hospitalidade.

Existe registro?

Cenário 4 — intermediário

O benefício não vem diretamente do interessado.

O sistema identifica relacionamento indireto?

Cenário 5 — pressão hierárquica

Funcionário bloqueia operação irregular.

Ele é protegido ou punido?

Aqui encontramos uma métrica extraordinária.

---

🛡️ CAPÍTULO 17 — O TESTE DO FUNCIONÁRIO PROTEGIDO

Quer saber se uma organização possui cultura de segurança?

Faça esta pergunta:

O que acontece com o funcionário que corretamente diz NÃO para alguém poderoso?

Se ele recebe apoio:

boa cultura.

Se recebe bronca:

alerta.

Se sofre retaliação:

vulnerabilidade crítica.

Porque segurança depende de pessoas terem permissão organizacional para aplicar segurança.

---

🧪 CAPÍTULO 18 — RED TEAM DE GOVERNANÇA

Agora montamos nosso exercício.

Sem tentar cometer crimes.

Sem violar privacidade.

Sem burlar controles reais.

Usamos simulações autorizadas.

Passo 1 — Mapear ativos

Dados.

Dinheiro.

Decisões.

Acessos.

Contratos.

Viagens.

Presentes.

Passo 2 — Mapear privilégios

Quem pode aprovar?

Quem pode dispensar?

Quem pode autorizar exceções?

Passo 3 — Mapear relacionamentos

Fornecedores.

Clientes.

Familiares.

Representantes.

Consultores.

Passo 4 — Procurar Shadow Policies

Pergunte aos funcionários:

“O que realmente acontece quando um diretor pede exceção?”

A resposta pode ser completamente diferente do manual.

Passo 5 — Simular pressão

Em ambiente autorizado, teste se procedimentos continuam funcionando quando o solicitante possui status elevado.

Passo 6 — Verificar audit trail

Conseguimos reconstruir tudo posteriormente?

Passo 7 — Corrigir.

Não apenas tecnologia.

Processo + cultura + proteção ao funcionário + transparência.

---

🔧 CAPÍTULO 19 — COMO MELHORAMOS O SISTEMA?

O Chapeleiro apresentou sua arquitetura.

1. Zero Trust também para VIP

Nenhum cargo concede privilégio implícito.

2. Exceção sempre registrada

Se precisa quebrar regra:

REQUEST
APPROVER
REASON
TIME
RESOURCE
EXPIRATION
AUDIT

3. Four Eyes Principle

Operações sensíveis exigem segunda aprovação independente.

4. Conflict-of-interest by design

Não espere o conflito aparecer.

Crie sistemas para declará-lo antecipadamente.

5. Beneficial ownership

Saiba quem realmente está atrás de empresas e estruturas relevantes quando a legislação permitir e exigir essa verificação.

6. Hospitalidade transparente

Presentes, viagens e benefícios relevantes precisam de regras claras.

7. Proteção contra retaliação

Funcionário que aplica corretamente o controle não pode ser punido por fazê-lo.

8. Auditoria baseada em substância

Não verifique apenas documentos.

Verifique realidade econômica.

9. Analytics

Procure padrões.

Valores.

Recorrência.

Relacionamentos.

Concentração.

Exceções.

10. Red Team periódico

Ataque processos.

Não pessoas.

---

🤖 CAPÍTULO 20 — IA PODE AJUDAR

Agora entra 2026.

Imagine milhares de:

contratos,

pagamentos,

agendas,

fornecedores,

declarações,

processos,

aprovações.

Humanos não conseguem correlacionar tudo.

IA e graph analytics podem ajudar a encontrar:

PESSOA A
   |
EMPRESA B
   |
FUNDO C
   |
CONSULTORIA D
   |
FAMILIAR E
   |
PROCESSO F

Isso não prova irregularidade.

Produz:

sinal para investigação humana.

Essa distinção é fundamental.

IA não deveria declarar:

CULPADO.

Deveria dizer:

ANOMALIA — INVESTIGAR.

---

🏛️ CAPÍTULO 21 — TRANSPARÊNCIA É OBSERVABILIDADE INSTITUCIONAL

Programadores conhecem observabilidade.

Metrics.

Logs.

Traces.

Agora aplique isso à governança.

Metrics: quantas exceções existem?

Logs: quem autorizou?

Traces: como o benefício percorreu a organização?

De repente:

OBSERVABILITY

vira:

TRANSPARENCY

O próprio CNJ criou o ONIT para fortalecer integridade, ética, governança e transparência e identificar riscos como corrupção, conflitos de interesse e captura institucional.

A analogia é perfeita:

instituição sem transparência é produção sem logs.

Tudo parece funcionar.

Até ocorrer incidente.

---

🎩 CAPÍTULO 22 — O ÚLTIMO CHÁ DO CHAPELEIRO

Alice estava cansada.

— Então nunca teremos um sistema perfeito?

O Chapeleiro riu.

— Claro que não!

— Então para que tudo isso?

Ele colocou uma última xícara sobre a mesa.

Nela estava escrito:

RESILIENCE.

Segurança não significa impedir absolutamente todo problema.

Significa:

dificultar → detectar → registrar → responder → aprender → melhorar.

É exatamente aquilo que fazemos no mainframe.

---

🐒 EPÍLOGO — OS CHIMPANZÉS VOLTARAM

Alice retornou à porta do início.

O homem importante apareceu novamente.

Tentou entrar.

ICH408I
ACCESS DENIED

Olhou para o funcionário.

— Você sabe com quem está falando?

O funcionário respondeu calmamente:

— Sei perfeitamente, senhor.

— Então abra.

— Sua identidade está confirmada. Sua autorização, não.

O homem pegou o telefone.

Nada aconteceu.

Tentou ligar para um diretor.

Nada.

Tentou chamar um amigo.

Nada.

Alice ficou surpresa.

— O que vocês fizeram?

O Chapeleiro apontou para uma placa nova:

EXCEPTION WORKFLOW

REQUEST
   ↓
INDEPENDENT APPROVAL
   ↓
JUSTIFICATION
   ↓
TIME-LIMITED ACCESS
   ↓
LOG
   ↓
REVIEW

Ao lado havia outra:

Nenhum funcionário será punido por aplicar corretamente um controle de segurança.

Alice sorriu.

Os chimpanzés começaram a bater palmas.

O Chapeleiro olhou para o relógio.

03:17.

— Conseguimos fechar todas as portas dos fundos?

Alice perguntou.

Ele colocou o chapéu.

— Não.

— Então fracassamos?

— Pelo contrário.

Pegou a xícara.

— Agora sabemos que devemos continuar procurando.

No terminal 3270 surgiu a última mensagem:

BELLACOSA MAINFRAME

SECURITY IS NOT
A PRODUCT.

SECURITY IS
A SYSTEM OF
PEOPLE,
PROCESSES,
TECHNOLOGY
AND ACCOUNTABILITY.

READY

E em letras menores:

ZERO TRUST:
SAME RULES.
ESPECIALLY FOR
SUPERUSERS.

☕🎩

Porque talvez a maior lição de todas seja esta:

Uma organização não demonstra que possui bons controles quando consegue dizer NÃO para quem não tem poder.

Ela demonstra quando consegue dizer NÃO para quem tem.

E um bom Red Team existe justamente para descobrir se esse NÃO continua funcionando quando chega o próximo Chapeleiro Maluco perguntando por que todo mundo está seguindo regras numa terra onde ele sempre acreditou que as regras eram para os outros.

 

☕ Um Café no Bellacosa Mainframe

🐒 QUANDO UM MILHÃO DE CHIMPANZÉS ABRIRAM O BARRIL DE SAQUÊ PREMIUM

Portas dos fundos humanas, “sabe com quem você está falando?”, jatinhos emprestados, togas, garotas de programa, despesas de representação, compliance, Red Team, Security — e o estranho dia em que descobrimos que o maior privilégio de um sistema talvez não estivesse cadastrado no RACF.

---

🎬 PRÓLOGO — O SISTEMA ESTAVA SEGURO

O jovem programador COBOL tinha certeza.

O RACF estava configurado.

As senhas eram fortes.

MFA estava habilitado.

Os datasets críticos estavam protegidos.

Os acessos privilegiados eram registrados.

O SIEM recebia eventos.

O SOC monitorava alertas.

Auditores possuíam relatórios.

Havia segregação de funções.

Existia política de Zero Trust.

Tudo perfeito.

Até que alguém apareceu na porta e pronunciou uma sequência de palavras contra a qual nenhum firewall havia sido configurado:

— Você sabe com quem está falando?

O jovem programador olhou para o veterano.

— Onde cadastro isso no RACF?

O velho tomou um gole de café.

— Em lugar nenhum.

— Então estamos protegidos?

— Muito pelo contrário, Padawan.

Eram 03:17.

O incidente estava apenas começando.

---

🐒 CAPÍTULO 1 — O MILHÃO DE CHIMPANZÉS

Existe uma velha brincadeira segundo a qual, colocando infinitos chimpanzés diante de máquinas de escrever durante tempo suficiente, algum deles acabaria escrevendo Shakespeare.

No Bellacosa Mainframe decidimos modernizar a experiência.

Colocamos um milhão de chimpanzés diante de terminais 3270.

Mas alguém cometeu um erro operacional gravíssimo.

Em vez de café, abriram um barril de saquê premium.

Depois do terceiro copo, nenhum chimpanzé queria mais escrever Shakespeare.

Queriam fazer auditoria.

E descobriram uma coisa extraordinária:

os sistemas mais protegidos do mundo frequentemente possuem portas que não aparecem nos diagramas de arquitetura.

Não são portas TCP.

Não estão no firewall.

Não possuem CVE.

Não aparecem no Nessus.

Não estão no OWASP Top 10.

São portas humanas.

---

🚪 CAPÍTULO 2 — A BACKDOOR QUE NÃO ESTAVA NO CÓDIGO

Imagine um sistema extremamente seguro.

Um funcionário tenta acessar determinado ambiente.

ACCESS DENIED.

Perfeito.

Agora chega um diretor.

ACCESS DENIED.

Tecnicamente, continua perfeito.

Então o diretor olha para o funcionário:

— Você sabe quem eu sou?

Nesse instante surge uma nova interface de autenticação.

Não existe API.

Não existe documentação.

Mas todo mundo conhece o protocolo:

IDENTIDADE: DIRETOR
AUTORIZAÇÃO: NÃO
PRESSÃO HIERÁRQUICA: ALTA
RISCO DE RETALIAÇÃO: ALTO

RESULTADO ESPERADO PELO SISTEMA:
DENY

RESULTADO ESPERADO PELO HUMANO:
TALVEZ SEJA MELHOR LIBERAR

Encontramos uma vulnerabilidade.

CVE-HUMAN-0001 — Sabe-Com-Quem-Está-Falando Privilege Escalation.

---

🪪 CAPÍTULO 3 — IDENTIDADE NÃO É AUTORIZAÇÃO

Aqui está uma lição fundamental de segurança:

Identification ≠ Authentication ≠ Authorization.

Eu posso saber exatamente quem você é.

Você pode realmente ser presidente.

Diretor.

CEO.

Ministro.

General.

Administrador.

DBA.

Isso não significa automaticamente que você esteja autorizado a acessar determinado recurso.

No RACF isso é banal.

No mundo humano, surpreendentemente, não.

O verdadeiro Zero Trust deveria conseguir dizer:

“Sei perfeitamente quem é o senhor. Agora preciso verificar se o senhor possui autorização.”

É fácil implementar Zero Trust contra o estagiário.

Quero ver implementar contra o presidente.

---

✈️ CAPÍTULO 4 — O JATINHO EMPRESTADO

Então os chimpanzés encontraram um hangar.

E descobriram outra propriedade curiosa do poder.

O cidadão comum viaja assim:

documento → check-in → fila → segurança → raio-X → portão → embarque.

O VIP pode utilizar ambientes completamente diferentes, sujeitos aos controles específicos daquela modalidade de aviação.

Nada disso significa automaticamente irregularidade.

Mas, para um Red Team, aparece imediatamente uma pergunta:

os controles continuam oferecendo rastreabilidade suficiente quando o usuário é VIP?

A pergunta não é:

“Como alguém poderia burlar isso?”

A pergunta correta é:

“Conseguimos reconstruir posteriormente quem entrou, quem saiu, quem autorizou e quem pagou?”

Essa é a diferença entre procurar uma vulnerabilidade e ensinar sua exploração.

---

Bellacosa Mainframe e uma historia que não esta no gibi

⚖️ CAPÍTULO 5 — A TOGA NÃO É UM TOKEN DE AUTENTICAÇÃO

Os chimpanzés continuaram investigando.

Encontraram pessoas poderosas.

Executivos.

Autoridades.

Magistrados.

Políticos.

Empresários.

E perceberam uma coisa.

Quanto maior o poder de uma pessoa, maior pode ser a tentação social de transformar sua posição em credencial.

Mas uma toga não deveria funcionar como:

PERMIT * ACCESS(ALTER)

Nem um cargo de CEO.

Nem um cartão VIP.

Nem amizade com o presidente.

Porque segurança baseada em prestígio possui uma vulnerabilidade fundamental:

ela funciona melhor justamente contra quem oferece menos risco institucional para quem aplica a regra.

---

🍽️ CAPÍTULO 6 — DESPESAS DE REPRESENTAÇÃO

Agora os chimpanzés chegaram ao departamento financeiro.

Encontraram uma expressão maravilhosa:

DESPESAS DE REPRESENTAÇÃO.

Jantares.

Viagens.

Eventos.

Hospitalidade.

Entretenimento.

Presentes.

Tudo pode possuir finalidade comercial perfeitamente legítima.

O problema começa quando alguém confunde:

DOCUMENTO EXISTE

com

TRANSAÇÃO É LEGÍTIMA.

São coisas completamente diferentes.

Um sistema ruim pergunta:

Tem comprovante?

Um sistema melhor pergunta:

O comprovante representa aquilo que realmente aconteceu?

---

🧾 CAPÍTULO 7 — COMPLIANCE NÃO É COLECIONAR PDF

Imagine:

DESPESA REAL = A
DOCUMENTO = B
CONTABILIDADE = B
ERP = B
RELATÓRIO = B
AUDITORIA SUPERFICIAL = OK

Cinco sistemas concordam.

E cinco sistemas podem estar errados.

Porque todos receberam a mesma representação incorreta da realidade.

Esse é um problema fascinante para quem trabalha com sistemas.

Garbage in, garbage out também funciona em compliance.

Uma transação pode possuir:

✔ documento
✔ aprovação
✔ centro de custo
✔ fornecedor
✔ lançamento
✔ pagamento

e ainda exigir investigação.

O auditor experiente não pergunta apenas:

“Existe nota?”

Pergunta:

“Esta nota conta a história verdadeira?”

---

👠 CAPÍTULO 8 — AS GAROTAS QUE ROUBARAM A MANCHETE

Então apareceram profissionais do sexo.

E todos os chimpanzés abandonaram imediatamente a arquitetura de segurança.

A imprensa também.

Porque:

CONFLITO DE INTERESSES EM COMPLEXA REDE DE RELACIONAMENTOS

é uma manchete chata.

Mas:

TOGA + JATINHO + GAROTA + FESTA

é praticamente o renascimento do Notícias Populares.

Só que existe uma armadilha intelectual aí.

Sexo consensual entre adultos pode não ser a questão relevante.

A pergunta interessante é outra:

quem proporcionou o benefício?

E depois:

por quê?

E depois:

para quem?

E finalmente:

o beneficiário possuía poder sobre algum interesse de quem estava pagando?

O Red Team abandona a fofoca e segue o fluxo.

---

💰 CAPÍTULO 9 — FOLLOW THE MONEY

Dinheiro possui uma qualidade maravilhosa para auditoria:

ele deixa rastros.

Mas o auditor iniciante procura somente:

A → B

O experiente procura:

A
│
├── empresa
├── consultoria
├── escritório
├── fornecedor
├── instituto
├── evento
├── viagem
└── benefício
        │
        ▼
        B

Isso não significa que cada seta represente corrupção.

Muito pelo contrário.

A maior parte das relações econômicas é perfeitamente legítima.

O objetivo é descobrir o significado das relações, não criminalizar relacionamentos.

---

🕵️ CAPÍTULO 10 — RED TEAM NÃO PROCURA APENAS BUG

Essa talvez seja a maior lição.

Red Team não precisa perguntar somente:

“Consigo quebrar o software?”

Pode perguntar:

“Consigo quebrar o processo?”

E depois:

“Consigo fazer alguém autorizado executar algo que eu não conseguiria executar?”

E finalmente:

“Existe alguém tão poderoso que os controles deixam de funcionar normalmente quando ele aparece?”

Essa última pergunta é assustadoramente poderosa.

---

🧠 CAPÍTULO 11 — O CONTROLE INVISÍVEL

Imagine duas políticas.

A política oficial:

Ninguém entra sem autorização.

E a política cultural:

Ninguém entra sem autorização, exceto pessoas importantes porque ninguém quer confusão.

Qual delas controla realmente a organização?

A segunda.

Mesmo sem estar escrita.

Esse é o Shadow Security Policy.

E ele pode ser mais poderoso que o RACF.

---

🐵 CAPÍTULO 12 — O CHIMPANZÉ AUDITOR

Depois de consumir quantidades preocupantes de saquê, um chimpanzé apresentou sua metodologia.

Ele escreveu no quadro:

QUEM?
 ↓
PEDIU O QUÊ?
 ↓
QUEM AUTORIZOU?
 ↓
QUEM PAGOU?
 ↓
QUEM RECEBEU?
 ↓
QUEM SE BENEFICIOU?
 ↓
HAVIA INTERESSE?
 ↓
HOUVE ATO POSTERIOR?
 ↓
EXISTE AUDIT TRAIL?

A sala ficou silenciosa.

O chimpanzé havia acabado de inventar uma investigação melhor que muito checklist corporativo.

---

🔐 CAPÍTULO 13 — ZERO TRUST PARA PODEROSOS

Talvez precisemos atualizar o conceito.

Zero Trust costuma ser explicado assim:

Never trust, always verify.

Mas existe uma versão organizacional:

Never trust status. Always verify authorization.

Porque existem duas formas de privilégio.

O privilégio técnico:

SPECIAL
OPERATIONS
AUDITOR
ALTER
CONTROL

E o privilégio social:

CEO
DIRETOR
VIP
AUTORIDADE
AMIGO DO DONO

O primeiro aparece nos relatórios.

O segundo raramente.

E justamente por isso merece atenção.

---

🧯 CAPÍTULO 14 — O FUNCIONÁRIO QUE DISSE NÃO

Existe ainda outro controle que quase nunca aparece no diagrama:

a pessoa que executa a política.

Se ela disser NÃO corretamente e receber punição por isso, a organização acabou de executar um treinamento informal.

Todos aprenderam:

Na próxima vez, diga SIM.

É assim que controles morrem sem ninguém alterar uma única linha de configuração.

O RACF continua perfeito.

O manual continua perfeito.

A auditoria continua recebendo relatórios verdes.

Mas ninguém mais deseja aplicar a regra contra determinadas pessoas.

---

🏛️ CAPÍTULO 15 — O PRINCÍPIO DA DISTÂNCIA ZERO

Relacionamento não é crime.

Networking não é crime.

Jantar não é crime.

Viajar não é crime.

Ter amigos poderosos não é crime.

Contratar serviços não é crime.

A pergunta de governança é:

essas relações conseguem alterar decisões que deveriam ser independentes?

Esse é o ponto em que compliance deixa de ser moralismo e vira arquitetura institucional.

---

📰 CAPÍTULO 16 — O EFEITO NOTÍCIAS POPULARES

Existe ainda um perigo para quem investiga.

Encontrar algo escandaloso demais.

Sexo.

Luxo.

Celebridades.

Jatinhos.

Festas.

Tudo isso produz atenção.

Mas atenção pode destruir investigação.

Porque o público passa a discutir:

“Quem dormiu com quem?”

quando deveria perguntar:

“Quem pagou o quê para quem e qual interesse existia?”

O espetáculo pode funcionar como fumaça sobre o problema verdadeiro.

---

🐒 EPÍLOGO — SHAKESPEARE NÃO VEIO

Depois de milhares de horas, o milhão de chimpanzés não escreveu Shakespeare.

Produziu algo muito mais útil.

Um relatório de auditoria.

Na última página havia apenas quatro linhas:

IDENTIDADE NÃO É AUTORIZAÇÃO.

DOCUMENTAÇÃO NÃO É VERDADE.

PODER NÃO É CREDENCIAL.

E TODO PRIVILÉGIO PRECISA DE AUDIT TRAIL.

O jovem programador olhou para o veterano.

— Então qual é a porta dos fundos mais perigosa?

O velho terminou o café.

Olhou para o relógio.

03:17.

— Aquela que todo mundo conhece, Padawan.

— Então por que ninguém fecha?

O veterano levantou-se.

— Porque às vezes quem passa por ela é justamente quem poderia mandar fechá-la.

No fundo da sala, um chimpanzé levantou o copo de saquê.

ICH408I.

Access denied.

Desta vez, para todos.

☕