As 20 Leis Secretas da Matrix da Engenharia de Software (Bizarres Rules)

 

Bellacosa Mainframe e as 20 leis secretas da Engenharia do Software

☕ Um Café no Bellacosa Mainframe

As 20 Leis Secretas da Matrix da Engenharia de Software - Bizarres Rules

O Guia do Programador COBOL Padawan para Sobreviver ao Universo dos Sistemas Legados Sem Ser Absorvido pelo Agente Smith

"Existem duas maneiras de aprender Engenharia de Software. A primeira é passando vinte anos corrigindo bugs em produção. A segunda é ouvindo aqueles que já passaram por isso. Este artigo tenta economizar duas décadas da sua vida."

---

Bem-vindo à Matrix, Padawan

Imagine a seguinte cena.

Você acabou de conseguir seu primeiro emprego como Programador COBOL.

Recebe acesso ao ambiente.

TSO.

ISPF.

CICS.

Db2.

JCL.

Tudo parece misterioso.

Então seu líder aponta para um programa com 180 mil linhas de código.

Ele sorri.

— Pequena manutenção.

Você abre o código.

O ventilador do computador começa a girar mais rápido.

Sua expressão muda.

Você pergunta:

— Quem escreveu isso?

A resposta vem imediatamente.

— Ninguém sabe.

Naquele instante o telefone toca.

É Morpheus.

— Neo... digo... Padawan...

Bem-vindo à Matrix da Engenharia de Software.

---

Existe um lado oculto da programação

Quando começamos a estudar programação, aprendemos:

• IF

• PERFORM

• LOOP

• SQL

• APIs

• Arquivos

• Variáveis

Mas ninguém ensina algo muito mais importante.

Os padrões invisíveis.

Os comportamentos humanos.

Os erros que se repetem geração após geração.

As armadilhas psicológicas.

As decisões arquiteturais.

Essas "leis" não pertencem ao COBOL.

Nem ao Java.

Nem ao Python.

Elas pertencem à natureza humana.

E é justamente por isso que continuam válidas há décadas.

---

A Matrix é feita de padrões

No filme Matrix, Neo acredita que tudo acontece por acaso.

Depois descobre que existem regras invisíveis governando aquele universo.

Na Engenharia de Software acontece exatamente a mesma coisa.

Você acha que aquele sistema virou um caos "do nada".

Não virou.

Ele seguiu um padrão.

Sempre segue.

---

O Oráculo chama isso de experiência

Imagine o Oráculo olhando para um jovem desenvolvedor.

Ela não pergunta:

— Você sabe COBOL?

Ela pergunta:

— Quantas vezes você já viu um sistema quebrar exatamente da mesma forma?

Porque experiência não é decorar comandos.

É reconhecer padrões.

---

Conheça as 20 Leis Secretas da Matrix da Engenharia de Software

Cada uma delas parece engraçada.

Algumas possuem nomes estranhos.

Outras parecem piadas.

Mas todas escondem décadas de aprendizado acumulado.

Vamos atravessar esse espelho.

---

1 — Bus Factor

"E se o único que entende o sistema for atropelado por um ônibus?"

Essa lei nos lembra que conhecimento concentrado é um enorme risco.

Se apenas uma pessoa entende o sistema...

...o sistema pertence a ela.

Não à empresa.

O verdadeiro Jedi documenta.

Compartilha.

Ensina.

https://eljefemidnightlunch.blogspot.com/2020/05/o-fator-onibus-o-dia-em-que-um.html

---

2 — Technical Debt

Toda gambiarra possui juros.

Às vezes ela resolve o problema hoje.

Mas cobra muito mais amanhã.

Como diria o Oráculo:

"A dívida técnica nunca esquece seu endereço."

https://eljefemidnightlunch.blogspot.com/2021/10/technical-debt-rules-quando-um.html 

---

3 — Yak Shaving

Você abriu um chamado simples.

Cinco horas depois.

Está configurando Docker.

Atualizando certificado.

Mudando firewall.

Lendo RFC.

Esqueceu completamente o problema inicial.

Parabéns.

Você encontrou um Yak.

https://eljefemidnightlunch.blogspot.com/2021/09/yak-shaving-rules-quando-um-programador.html

---

4 — Bike Shedding

Reunião de duas horas.

Noventa minutos discutindo a cor do botão.

Cinco minutos falando da arquitetura.

O Agente Smith adora reuniões assim.

https://eljefemidnightlunch.blogspot.com/2021/08/bike-shedding-rules-quando-um.html

---

5 — Golden Hammer

Quando tudo parece prego...

...qualquer ferramenta vira martelo.

O Padawan aprende Java.

Quer resolver tudo com Java.

Aprende IA.

Agora tudo precisa de IA.

Aprende Kubernetes.

Até o bloco de notas vira microsserviço.

Calma.

Nem toda batalha precisa da Nebuchadnezzar.

https://eljefemidnightlunch.blogspot.com/2021/07/golden-hammer-rules-quando-um.html

---

6 — Cargo Cult Programming

CTRL+C.

CTRL+V.

Funcionou.

Mas...

Você sabe por quê?

Se não sabe.

Talvez esteja apenas repetindo um ritual.

Não programação.

https://eljefemidnightlunch.blogspot.com/2021/05/spaghetti-code-rules-quando-um.html

---

7 — Spaghetti Code

IF dentro de IF.

GO TO.

PERFORM.

Mais GO TO.

Mais IF.

O código parece um prato de macarrão.

Delicioso no almoço.

Horrível na manutenção.

https://eljefemidnightlunch.blogspot.com/2021/05/spaghetti-code-rules-quando-um.html

---

8 — Lasagna Code

Agora temos o problema contrário.

Camadas.

Mais camadas.

Mais camadas.

Mais uma camada.

No final.

Um IF precisa atravessar sete microsserviços para mudar um campo.

https://eljefemidnightlunch.blogspot.com/2021/03/lasagna-code-rules-quando-um.html

---

9 — Big Ball of Mud

É aquele sistema onde ninguém sabe explicar a arquitetura.

Funciona?

Funciona.

Como?

Boa pergunta.

https://eljefemidnightlunch.blogspot.com/2021/01/big-ball-of-mud-rules-quando-um.html

---

10 — God Object

Existe um programa chamado:

CLIENTE01.

Ele faz:

• cadastro;

• cobrança;

• PIX;

• cartão;

• empréstimo;

• café;

• provavelmente também controla o clima.

Esse programa acredita ser o Escolhido.

Não é.

https://eljefemidnightlunch.blogspot.com/2020/11/god-object-rules-quando-um-programador.html

---

11 — Lava Flow

Código escrito em 1994.

Ninguém sabe para que serve.

Mas ninguém remove.

Vai que explode.

Então permanece.

Como lava endurecida.

https://eljefemidnightlunch.blogspot.com/2020/12/lava-flow-rules-quando-um-programador.html

---

12 — Boiling Frog

O sistema não piora de um dia para outro.

Vai ficando lentamente mais lento.

Mais complicado.

Mais difícil.

Quando percebemos.

Já estamos mergulhados na água fervendo.

https://eljefemidnightlunch.blogspot.com/2021/11/boiling-frog-rules-quando-um.html

---

13 — Death March

Prazo impossível.

Equipe pequena.

Escopo gigante.

Cliente ansioso.

Café infinito.

Dormir virou luxo.

Esse projeto nunca deveria ter começado assim.

https://eljefemidnightlunch.blogspot.com/2021/02/death-march-project-rules-quando-um.html

---

14 — Brooks's Law

O projeto está atrasado.

A solução?

Contratar vinte pessoas.

Resultado?

Agora existem vinte pessoas tentando entender o sistema.

E o atraso aumenta.

https://eljefemidnightlunch.blogspot.com/2020/09/brookss-law-rules-quando-um-programador.html

---

15 — Conway's Law

As equipes desenham software exatamente como se comunicam.

Se departamentos não conversam.

Os sistemas também não conversarão.

https://eljefemidnightlunch.blogspot.com/2020/08/conways-law-rules-quando-um-programador.html

---

16 — Murphy's Law

Tudo que pode falhar...

Vai falhar.

Especialmente sexta-feira.

Às 18h.

Cinco minutos antes da implantação.

Por isso existem testes.

https://eljefemidnightlunch.blogspot.com/2020/01/murphys-law-quando-um-programador-cobol.html

---

17 — KISS

Se ficou complicado demais...

Provavelmente existe uma solução mais simples.

Os melhores sistemas normalmente parecem óbvios.

Depois de prontos.

https://eljefemidnightlunch.blogspot.com/2020/02/kiss-rules-quando-um-programador-cobol.html

---

18 — YAGNI

"Vai que um dia precisamos..."

Essa frase já criou milhões de linhas de código inútil.

Implemente quando realmente precisar.

https://eljefemidnightlunch.blogspot.com/2020/07/yagni-rules-quando-um-programador-cobol.html

---

19 — DRY

Copiou.

Colou.

Copiou novamente.

Agora o bug existe em dezoito lugares diferentes.

Parabéns.

Você criou um exército de Agentes Smith.

https://eljefemidnightlunch.blogspot.com/2020/06/dry-rules-quando-um-programador-cobol.html

---

20 — SOLID

Os cinco pilares.

O alicerce.

A estrutura.

A arquitetura.

Sem eles.

O software continua funcionando.

Por algum tempo.

Depois...

A Matrix desaba.

https://eljefemidnightlunch.blogspot.com/2020/04/solid-roules-quando-um-programador.html

---

21 — Boy Scout Rule

Sim.

Ela veio depois.

Porque nenhum sistema melhora sozinho.

Toda vez que tocar em um programa.

Deixe-o um pouco melhor.

Nem que seja apenas renomeando uma variável.

https://eljefemidnightlunch.blogspot.com/2020/03/boy-scout-rule-quando-um-programador.html

---

O verdadeiro inimigo nunca foi a tecnologia

Perceba algo curioso.

Nenhuma dessas leis fala de:

COBOL.

Java.

Python.

Rust.

Go.

Todas falam sobre pessoas.

Porque software é uma atividade humana.

---

O Agente Smith mora dentro da nossa cabeça

Smith aparece quando pensamos:

• "Depois eu arrumo."

• "Só desta vez."

• "Ninguém vai perceber."

• "Pode copiar."

• "Não precisa documentar."

• "Vai funcionar."

É exatamente assim que grandes sistemas envelhecem.

---

Neo nunca venceu sozinho

Observe Matrix novamente.

Neo nunca salvou o mundo sozinho.

Precisou de:

• Morpheus;

• Trinity;

• Oráculo;

• Link;

• Tank;

• Niobe;

• Sati;

• Chaveiro.

Grandes sistemas também são construídos por equipes.

---

E onde entra o COBOL?

Em todos os lugares.

Os sistemas COBOL que movimentam bancos, seguradoras, bolsas de valores e governos não sobreviveram cinquenta anos porque alguém escreveu um código perfeito.

Eles sobreviveram porque milhares de engenheiros aplicaram — muitas vezes sem conhecer os nomes — esses princípios ao longo das décadas:

• simplificaram;

• documentaram;

• removeram duplicações;

• dividiram responsabilidades;

• testaram;

• compartilharam conhecimento;

• fizeram pequenas melhorias contínuas.

É por isso que um programa COBOL de 1988 ainda pode estar processando milhões de transações diariamente.

---

O Convite do Oráculo

No final da jornada, o Oráculo entrega a Neo um pequeno caderno.

Na capa está escrito:

"As Leis Secretas da Engenharia de Software."

Neo pergunta:

— Depois que eu decorar todas elas, finalmente serei um grande programador?

Ela sorri.

— Não.

— Então para que servem?

Ela responde:

"Porque agora, quando encontrar um problema, você saberá dar um nome ao monstro. E quando um monstro tem nome, ele deixa de parecer invencível."

---

Continue Explorando a Matrix

Se este artigo despertou sua curiosidade, esta é apenas a porta de entrada.

Cada uma dessas vinte (e uma) regras esconde uma história fascinante, repleta de exemplos reais, armadilhas clássicas, curiosidades históricas e lições que moldaram a engenharia de software moderna.

Nos próximos artigos da série ☕ Um Café no Bellacosa Mainframe, vamos mergulhar em cada uma delas com profundidade, sempre sob a ótica de um Programador COBOL Padawan explorando os corredores da Matrix.

Você descobrirá por que projetos fracassam, como sistemas sobrevivem por décadas, o que diferencia arquiteturas elegantes de verdadeiros labirintos de código e, principalmente, como transformar conhecimento técnico em sabedoria prática.

A cada regra desvendada, você enxergará um pouco mais do código verde da Matrix.

---

Conclusão — A Matrix Sempre Esteve na Engenharia de Software

No primeiro filme, Morpheus diz a Neo que a Matrix está em toda parte.

Na Engenharia de Software acontece exatamente o mesmo.

Essas leis aparecem:

• em pequenos scripts;

• em APIs modernas;

• em aplicações mobile;

• em microsserviços;

• em sistemas bancários;

• em programas COBOL escritos há quarenta anos;

• e até nas respostas geradas por Inteligências Artificiais.

Elas não são modismos.

São observações acumuladas por milhares de engenheiros que erraram, aprenderam, compartilharam e deixaram um mapa para quem veio depois.

Talvez você ainda não tenha encontrado todas essas situações.

Mas, acredite, se continuar programando, elas encontrarão você.

A boa notícia é que, agora, você já conhece seus nomes.

E isso faz toda a diferença.

No universo Bellacosa Mainframe, existe uma última frase escrita na parede da sala do Arquiteto:

"Todo Padawan começa aprendendo comandos. Todo Mestre termina reconhecendo padrões. Porque linguagens mudam, tecnologias envelhecem e frameworks desaparecem, mas as leis da Engenharia de Software continuam governando a Matrix muito depois que o último deploy termina."

Então pegue seu café.

Abra seu editor COBOL.

E venha explorar essas estranhas, divertidas e surpreendentemente verdadeiras regras da Engenharia de Software.

A Matrix está esperando por você.

Da USS Enterprise aos Containers: O Guia Definitivo do Programador COBOL Padawan para Entender Docker, DevOps e Cloud Computing

 

Bellacosa Mainframe e o docker sem misterios

☕ Um Café no Bellacosa Mainframe

🐳 Docker sem Mistérios

Da USS Enterprise aos Containers: O Guia Definitivo do Programador COBOL Padawan para Entender Docker, DevOps e Cloud Computing

"A lógica é o começo da sabedoria, não o fim."

— Sr. Spock

---

Introdução — Bem-vindo à Sala de Teletransporte

Imagine que você acaba de embarcar na USS Enterprise.

Você é um jovem oficial recém-saído da Academia da Frota Estelar.

Seu trabalho é manter os computadores da nave funcionando.

No entanto...

A Enterprise não possui apenas um computador.

Ela possui centenas.

Existem computadores para:

• Controle de navegação

• Motores de Dobra

• Sensores

• Transporte

• Comunicações

• Holodeck

• Engenharia

• Laboratórios científicos

Todos precisam funcionar simultaneamente.

Mas imagine se, para executar um simples software de navegação, fosse necessário construir uma Enterprise inteira.

Foi exatamente assim que a computação funcionou durante décadas.

Cada aplicação precisava praticamente de um servidor inteiro.

Era desperdício.

Foi então que surgiu uma ideia revolucionária.

"E se pudéssemos empacotar apenas a aplicação e tudo aquilo que ela realmente precisa?"

Nasciam os containers.

E alguns anos depois...

O mundo conheceria uma pequena baleia azul chamada Docker.

Hoje, Docker é um dos pilares de DevOps, Cloud Computing, CI/CD, Kubernetes e da computação moderna.

Neste Café no Bellacosa Mainframe vamos entender absolutamente tudo, especialmente para quem vem do universo COBOL, JCL, CICS, Db2 e IBM Z.

Prepare seu café.

O computador da Enterprise já iniciou o boot.

---

Capítulo 1 — Antes do Docker

Durante muitos anos instalar software era um verdadeiro ritual.

Imagine um servidor Linux.

Você precisava instalar:

• Java

• Python

• NodeJS

• Apache

• Bibliotecas

• Drivers

• Dependências

Depois disso...

Rezava para tudo funcionar.

Se alguém atualizasse uma biblioteca...

Seu programa quebrava.

Era comum ouvir:

"Na minha máquina funciona."

Essa frase virou praticamente uma piada mundial.

O problema não era o código.

Era o ambiente.

---

Capítulo 2 — O Grande Problema

Imagine três aplicações.

Sistema A

Java 8

Sistema B

Java 17

Sistema C

Java 21

Todos no mesmo servidor.

Cada uma exige versões diferentes.

Resultado?

Conflitos.

Muito parecidos com programas COBOL compilados com runtimes incompatíveis.

No IBM Z isso sempre foi tratado com enorme cuidado.

No mundo distribuído...

Era um caos.

---

Capítulo 3 — A Solução Chamada Container

Container significa isolamento.

Cada aplicação leva consigo:

• bibliotecas

• dependências

• configuração

• runtime

Tudo empacotado.

Sem interferir nas demais.

É como colocar cada programa em sua própria cabine da Enterprise.

Todos dividem a nave.

Mas ninguém invade o espaço do outro.

---

Capítulo 4 — Máquina Virtual x Container

Durante anos usamos máquinas virtuais.

Servidor

↓

Hypervisor

↓

Windows

↓

Aplicação

Docker mudou completamente.

Servidor

↓

Linux

↓

Docker Engine

↓

Containers

Não existe outro sistema operacional inteiro.

Existe apenas:

• processo

• isolamento

• filesystem

Resultado?

Inicialização em segundos.

Pouca memória.

Baixíssimo consumo.

---

Curiosidade

O kernel Linux enxerga um container apenas como um processo.

Nada mais.

Esse é um dos maiores segredos do Docker.

---

Capítulo 5 — O Docker Engine

O Docker Engine é o capitão da nave.

Ele administra:

• containers

• imagens

• volumes

• redes

• armazenamento

• execução

Sem ele...

Nada acontece.

---

Capítulo 6 — Dockerfile

O Dockerfile é uma receita culinária.

Exemplo:

FROM ubuntu

RUN apt update

RUN apt install python3

COPY app.py .

CMD ["python3","app.py"]

Ele diz exatamente como montar a aplicação.

No mundo Mainframe ele lembra bastante:

• PROC JCL

• CLIST

• REXX

• Script SMP/E

• Job de instalação

---

Capítulo 7 — O Processo Completo

Tudo segue uma sequência lógica.

Dockerfile

↓

docker build

↓

Imagem

↓

docker run

↓

Container

Jamais confunda.

Dockerfile não executa.

Imagem não executa.

Quem executa é o container.

---

Capítulo 8 — O Mistério das Imagens

Imagem é um template.

Ela é imutável.

Pense em:

• ISO

• Backup

• Snapshot

• Golden Image

Você cria uma única imagem.

Depois gera cem containers.

Todos iguais.

Essa repetibilidade é um dos grandes segredos do DevOps.

---

Capítulo 9 — docker build

docker build -t web .

Significa:

Construa uma imagem usando o Dockerfile localizado no diretório atual.

"-t"

significa Tag.

Exemplo:

bellacosa/site:v1

---

Capítulo 10 — docker images

Lista todas as imagens.

docker images

Saída típica:

REPOSITORY

TAG

IMAGE ID

SIZE

Pense nisso como um catálogo de módulos carregáveis.

---

Capítulo 11 — docker pull

O Docker Hub funciona como uma biblioteca mundial.

docker pull nginx

Baixa uma imagem pronta.

Sem instalar manualmente.

Sem configurar dependências.

Sem sofrimento.

---

Curiosidade

O Docker Hub possui milhões de imagens.

Mas...

Nem todas são oficiais.

Sempre prefira imagens verificadas.

---

Capítulo 12 — docker run

Provavelmente o comando mais famoso.

docker run nginx

Ele cria:

Imagem

↓

Container

Nunca altera a imagem.

---

Principais parâmetros

-d

Modo background.

docker run -d nginx

Muito parecido com iniciar um Started Task no z/OS.

---

-p

Mapeamento de portas.

-p 8080:80

Host

↓

8080

Container

↓

80

---

--name

docker run --name web nginx

Muito melhor que decorar IDs enormes.

---

-e

Variáveis de ambiente.

-e DB_USER=admin

---

-v

Volumes.

-v dados:/var/lib/mysql

Sem volumes...

Os dados desaparecem ao remover o container.

---

Capítulo 13 — docker ps

docker ps

Lista apenas containers ativos.

Muito parecido com observar tarefas em execução no ambiente operacional.

---

docker ps -a

Mostra também:

• encerrados

• falhados

• pausados

É excelente para troubleshooting.

---

Capítulo 14 — docker logs

Todo administrador aprende isso rapidamente.

Quando algo falha...

Primeiro comando:

docker logs

É equivalente ao programador COBOL abrir imediatamente:

• JESMSGLG

• JESJCL

• SYSOUT

• CEEDUMP

• SDSF

Os logs contam a história do que aconteceu.

---

Capítulo 15 — docker exec

docker exec -it web bash

Agora você entra literalmente dentro do container.

Como abrir um terminal remoto exclusivo daquele ambiente.

Muito útil para:

• investigar arquivos

• executar comandos

• validar configurações

---

Capítulo 16 — docker stop

Encerra um container.

Primeiro envia um SIGTERM.

Dá tempo para o programa finalizar corretamente.

Caso ignore...

Recebe SIGKILL.

Muito semelhante a uma finalização controlada antes de um cancelamento forçado.

---

Capítulo 17 — docker rm

Remove containers.

Mas apenas se estiverem parados.

Fluxo típico:

docker stop web

docker rm web

---

Capítulo 18 — docker rmi

Remove imagens.

docker rmi nginx

Só funciona se ninguém estiver usando aquela imagem.

---

Capítulo 19 — docker system prune

O famoso botão vermelho.

docker system prune -a

Remove:

• cache

• containers

• imagens

• redes não utilizadas

• artefatos temporários

Libera dezenas de gigabytes.

Mas...

Muito cuidado.

---

Capítulo 20 — Comandos que Todo Profissional Usa

docker inspect

Mostra praticamente tudo.

IPs.

Volumes.

Redes.

JSON completo.

---

docker stats

Monitoramento em tempo real.

CPU

RAM

Rede

Disco

É semelhante a consultar métricas de desempenho em ferramentas de monitoramento corporativas.

---

docker top

Lista processos internos.

---

docker cp

Copia arquivos.

Host

↓

Container

Container

↓

Host

---

docker restart

Reinicia.

---

docker start

Liga novamente um container parado.

---

docker pause

Congela processos.

---

docker unpause

Retoma execução.

---

docker network ls

Lista redes.

---

docker volume ls

Lista volumes persistentes.

---

docker history

Mostra todas as camadas da imagem.

Excelente para otimização.

---

Capítulo 21 — Como Docker Funciona Internamente

Pouca gente sabe...

Mas um container não é uma máquina virtual.

Ele utiliza recursos do próprio kernel Linux, como:

• Namespaces

• Control Groups (cgroups)

• OverlayFS

• Union File Systems

Essas tecnologias isolam processos, redes, usuários e sistemas de arquivos sem a necessidade de um sistema operacional completo por container.

É por isso que containers iniciam em poucos segundos e consomem muito menos memória que VMs tradicionais.

---

Capítulo 22 — Docker e DevOps

Docker revolucionou o DevOps porque eliminou um dos maiores problemas da engenharia de software: ambientes inconsistentes.

Hoje é possível:

• Desenvolver localmente.

• Testar em homologação.

• Implantar em produção.

Tudo usando exatamente a mesma imagem.

Isso torna pipelines de CI/CD previsíveis e reproduzíveis.

---

Capítulo 23 — Docker no Mundo Mainframe

Você pode pensar:

"Mas eu trabalho com COBOL no IBM Z. O que Docker tem a ver comigo?"

A resposta é: muito.

Mesmo que aplicações COBOL rodem diretamente no z/OS, Docker é amplamente utilizado para hospedar ferramentas que fazem parte do ecossistema de desenvolvimento moderno:

• Jenkins para automação de builds e deploys.

• SonarQube para análise estática de código.

• GitLab e Gitea para repositórios Git.

• Nexus e Artifactory para gerenciamento de artefatos.

• Bancos PostgreSQL, MariaDB e MongoDB para aplicações satélite.

• Ambientes de testes para APIs REST que consomem serviços do z/OS Connect EE.

• Ferramentas como Zowe CLI, Ansible e utilitários DevOps.

Assim, Docker não substitui o mainframe: ele o complementa, oferecendo um ecossistema ágil ao redor do IBM Z.

---

Boas Práticas

• Use imagens oficiais sempre que possível.

• Evite executar containers como usuário root.

• Versione seus Dockerfiles junto com o código-fonte.

• Utilize tags específicas (nginx:1.28) em vez de latest para garantir previsibilidade.

• Mantenha imagens pequenas, removendo dependências temporárias.

• Faça limpeza periódica de recursos não utilizados com cautela.

---

Curiosidades

• O mascote do Docker chama-se Moby Dock, uma baleia carregando contêineres.

• Docker foi lançado em 2013 pela empresa dotCloud.

• O formato de imagens e containers inspirou o padrão aberto OCI (Open Container Initiative).

• Embora muita gente diga que "Kubernetes usa Docker", atualmente o Kubernetes conversa com runtimes compatíveis com OCI, como containerd e CRI-O, mantendo compatibilidade com imagens Docker.

• Muitas distribuições Linux modernas já trazem ferramentas de containers integradas, mostrando como esse modelo se tornou um padrão da indústria.

---

Easter Egg Bellacosa Mainframe

No universo de Star Trek, o computador da USS Enterprise isola centenas de subsistemas críticos — navegação, comunicações, sensores, suporte de vida e controle dos motores de dobra — para que uma falha em um deles não comprometa toda a nave.

Os containers seguem exatamente essa filosofia: cada aplicação roda em um ambiente isolado, compartilhando apenas os recursos essenciais do sistema operacional. Se um serviço apresentar problemas, os demais continuam operando normalmente.

Essa ideia também ecoa no IBM Z. Assim como LPARs, z/VM e mecanismos de isolamento permitem executar múltiplas cargas de trabalho com segurança e eficiência, os containers oferecem isolamento leve e portabilidade para aplicações modernas.

Missão do Padawan COBOL: quando você entender que Docker não é apenas um conjunto de comandos, mas uma forma diferente de pensar a infraestrutura, terá dado um importante salto rumo ao universo de DevOps. Afinal, tecnologias mudam, ferramentas evoluem, mas os princípios de isolamento, automação, repetibilidade e confiabilidade permanecem — exatamente como ensinaria o Sr. Spock na ponte da Enterprise. 🚀

 

🥄 O Som dos Panelaços

Por Vagner Bellacosa Mainframe

Havia silêncio demais em 2020.
As ruas vazias, os carros parados, o medo suspenso no ar como poeira de um mundo que de repente esqueceu de respirar.
E então, veio o som — o som metálico, áspero, ritmado: o barulho das panelas.

Era o som do homem comum.
Não o das elites, nem dos discursos;
era o som de quem perdeu o chão, o trabalho, o costume de abraçar.
De quem se trancou em casa e, pela primeira vez, percebeu o tamanho da própria solidão.
Os panelaços foram o desabafo coletivo de um país confinado, um grito dentro das janelas.

Cada bairro ecoava como uma tribo.
Em alguns, era protesto;
em outros, catarse.
Alguns batiam contra o governo;
outros batiam contra o destino.
Mas no fundo, todos batiam contra a mesma coisa:
a sensação de impotência.

Porque o homem moderno, acostumado a controlar tudo — o tempo, o corpo, o dinheiro —
descobriu que não controlava nada.
E então, restou-lhe o som.
A batida repetida de uma colher contra o metal.
Uma música primitiva, de raiva e medo, que atravessava a noite e subia pelos prédios como uma oração pagã.

As panelas eram o novo tambor tribal.
O novo Twitter das sacadas.
O eco do desespero travestido de cidadania.
Enquanto o vírus espalhava invisibilidade, o som trazia presença.
Era o “estamos vivos” de quem já não tinha o que dizer.

Houve quem chamasse de “ato político”, quem zombasse, quem ignorasse.
Mas, sob qualquer análise, aquele ruído era puro instinto social —
o barulho de um povo que ainda queria existir, ainda que à distância.
Porque o silêncio mata mais devagar que a doença, mas mata.

E, como tudo, passou.
As panelas se calaram.
Vieram as eleições, as crises, as novas pautas, os novos medos.
O som se perdeu, mas deixou rastro.
Talvez nunca mais voltemos a ouvir o país inteiro batendo panelas,
mas aquele eco — aquele som metálico de frustração e esperança —
ainda vive em cada brasileiro que, por alguns minutos,
sentiu-se parte de algo maior do que o próprio isolamento.

Os panelaços foram o retrato fiel de quem somos:
emocionais, desorganizados, passionais, ruidosos,
mas vivos — e ainda tentando se entender.

 

Bellacosa Mainframe e o curtir ao controle das redes sociais

☕ Do “Curtir” ao Controle: A Metamorfose Sombria do Facebook

Como a rede que prometeu conectar o mundo acabou dividindo a humanidade

---

🧩 Introdução — A utopia azul

Era uma ideia simples, quase inocente:
“E se pudéssemos reunir todas as pessoas do mundo em uma só rede?”

Assim nasceu o Facebook, em 2004, no dormitório de Harvard.
Um projeto universitário de um jovem introspectivo chamado Mark Zuckerberg, que queria aproximar pessoas, compartilhar memórias e criar uma nova forma de comunicação.

A ideia pegou fogo.
Em 10 anos, o mundo estava conectado — da aldeia mais remota da Ásia ao escritório mais moderno de Nova York.
Mas, como toda utopia humana, o sonho de conectar corações tropeçou na ganância de manipular mentes.

---

💰 1. O DNA do problema: o produto era você

Desde o início, o Facebook nasceu com um defeito ético embutido:
o usuário não era o cliente — era o produto.

A empresa precisava de uma fonte de receita.
A publicidade digital parecia inofensiva, até que se descobriu que, para vender anúncios, era preciso conhecer você — o que gosta, o que teme, o que odeia, com quem fala, o que lê, o que ignora.

Assim nasceu o capitalismo de vigilância, conceito brilhantemente descrito por Shoshana Zuboff em The Age of Surveillance Capitalism.
Segundo ela, as empresas de tecnologia começaram a coletar, prever e manipular o comportamento humano como se fosse matéria-prima industrial.

O resultado?
Cada curtida virou dado.
Cada reação, lucro.
Cada emoção, um ativo financeiro.

---

🧠 2. O algoritmo aprendeu o que somos — e o que tememos

O Facebook descobriu que a emoção é mais rentável que a informação.
Postagens neutras geram tédio.
Já o medo, a raiva e a indignação mantêm o dedo rolando — e o dinheiro circulando.

Então o algoritmo foi “treinado” para amplificar o que mais nos afeta.
O resultado foi um mundo emocionalmente inflamável:

• As pessoas começaram a ver apenas o que confirma suas crenças;

• As bolhas ideológicas se solidificaram;

• E o diálogo foi substituído pelo embate.

Como observou o pesquisador Tristan Harris (ex-designer ético do Google):

“As redes sociais não estão competindo por seu dinheiro, mas por sua atenção — e a atenção humana é mais facilmente conquistada pelo medo.”

---

🏛️ 3. Da publicidade à manipulação política

Foi questão de tempo até que alguém percebesse:
se dá pra vender um tênis, dá pra vender um candidato.

Durante o Brexit (2016) e as eleições dos EUA (2016), o mundo viu o nascimento de uma nova arma: a engenharia social algorítmica.
A empresa Cambridge Analytica coletou ilegalmente dados de mais de 87 milhões de usuários para criar propagandas políticas personalizadas, explorando medos e emoções individuais.

As campanhas não convenciam — condicionavam.
O eleitor não pensava, reagia.
E, em uma ironia cruel, a rede que nasceu para unir democracias acabou corroendo a confiança nelas.

---

🧨 4. O pacto silencioso com o caos

O Facebook sabia.
Relatórios internos mostravam que o algoritmo estava radicalizando usuários, promovendo fake news e discursos de ódio.
Mas intervir significava reduzir engajamento — e, portanto, lucro.

Então a empresa escolheu o silêncio.
Como diria um analista da própria Meta em 2018:

“O que é tóxico para a sociedade é lucrativo para nós.”

Foi assim que o “Curtir” virou uma arma de manipulação emocional em massa.
A rede social transformou-se no maior experimento psicológico não autorizado da história.

---

🌍 5. O mundo fragmentado e a solidão conectada

Nunca estivemos tão conectados — e nunca fomos tão solitários.
Vivemos em um mundo digitalmente interligado, mas emocionalmente desintegrado.
As fronteiras físicas caíram, mas as ideológicas se ergueram.

Cada pessoa vive agora dentro de sua realidade personalizada, moldada por algoritmos invisíveis que decidem o que vemos, sentimos e acreditamos.
A verdade virou questão de opinião.
E a opinião virou produto.

O filósofo Byung-Chul Han define isso como a “sociedade da transparência”:

“Vivemos expostos, medidos, quantificados — e voluntariamente escravizados pelo prazer de sermos vistos.”

---

☕ Epílogo — O despertar digital

O Facebook não foi apenas uma empresa. Foi um espelho.
E, como todo espelho, refletiu o que somos: curiosos, carentes, ansiosos, contraditórios.

A guinada para o “lado negro da força” não foi apenas tecnológica — foi humana.
A tecnologia apenas deu escala àquilo que sempre existiu em nós:
a vaidade, o medo, o desejo de pertencer e a tentação de controlar.

A lição que fica é simples e amarga:

“A ferramenta não é má. Mas, quando a ética dorme, o algoritmo acorda.”

O desafio do século XXI não é desconectar-se,
é reaprender a usar a conexão com consciência, limite e empatia.

---

📚 Curiosidades Bellacosa

• Cambridge Analytica foi fundada em 2013 e dissolvida em 2018, após o escândalo global de manipulação política.

• Mark Zuckerberg depôs no Senado dos EUA em 2018, mas a empresa nunca perdeu relevância — apenas mudou de nome: Meta.

• Em 2021, ex-funcionária Frances Haugen divulgou documentos internos mostrando que o Facebook sabia dos danos psicológicos do Instagram em adolescentes.

• Estima-se que o Facebook detenha dados de mais de 3 bilhões de pessoas, mais do que qualquer governo da história humana.

---

🧭 Conclusão Bellacosa

O Facebook começou como uma rede de amigos.
Hoje é um espelho global das fragilidades humanas — um experimento sobre poder, emoção e controle.

A “força” sempre esteve lá, mas foi o lado humano que escolheu como usá-la.

O futuro não depende do algoritmo, mas da consciência coletiva.
E talvez, um dia, consigamos fazer da tecnologia novamente um meio de aproximar almas — não de vendê-las.

 

Bellacosa Mainframe e o teste de api

☕ Um Café no Bellacosa Mainframe

🤖 NATHAN BATEMAN E A API QUE ACHAVA QUE ERA HUMANA

HTTP, REST, JSON, Postman, OpenAPI, testes positivos e negativos, OAuth, RACF, Db2, CICS, COBOL, contratos, performance, segurança, CI/CD, observabilidade — e o dia em que um programador COBOL descobriu que receber 200 OK não provava absolutamente nada.

Sob a tutela de Nathan Bateman, de Ex Machina — porque, se existe alguém capaz de olhar para uma interface aparentemente perfeita e perguntar “mas o que realmente está acontecendo atrás dela?”, é Nathan.

---

🎬 PRÓLOGO — BEM-VINDO À CASA, PROGRAMADOR

A porta se fecha atrás de você.

Não existe maçaneta.

À sua frente há vidro, concreto, câmeras, servidores e uma quantidade desconfortável de tecnologia escondida nas paredes.

Nathan coloca uma cerveja sobre a mesa.

— Você programa COBOL?

— Sim.

— CICS?

— Sim.

— Db2?

— Também.

Ele sorri.

— Excelente. Então hoje você vai testar uma API.

Você olha para ele como se tivesse acabado de pedir para compilar Java usando um IBM 029.

API?

REST?

JSON?

Bearer Token?

OpenAPI?

Postman?

Você passou anos pensando em:

COBOL
JCL
CICS
Db2
VSAM
RACF
MQ

E agora aparece uma tela mostrando:

POST /api/v1/payments

Nathan aponta para o monitor.

{
  "account": "123456",
  "amount": 500.00
}

Depois surge:

HTTP/1.1 200 OK

Nathan pergunta:

— Funcionou?

Você responde imediatamente:

— Sim.

Ele sorri novamente.

Era uma armadilha.

Porque acabamos de cometer um dos erros mais perigosos em testes de APIs:

confundir uma resposta tecnicamente bem-sucedida com uma transação de negócio corretamente executada.

Bem-vindo ao laboratório.

Hoje não vamos apenas aprender API Testing.

Vamos descobrir o que existe atrás do vidro.

---

🧠 CAPÍTULO 1 — A API É AVA?

Em Ex Machina, Caleb inicialmente vê Ava através de uma interface.

Existe uma parede entre eles.

Ele conversa com ela.

Ela responde.

Pergunta:

Caleb
  ↓
interface
  ↓
Ava

Para Caleb, aquilo parece simples.

Mas por trás da interface existe uma quantidade enorme de tecnologia que ele não vê.

Uma API funciona de maneira parecida.

Imagine um aplicativo bancário.

O usuário toca:

CONSULTAR SALDO

O aplicativo envia:

GET /accounts/12345/balance

Recebe:

{
  "account": "12345",
  "balance": 7342.91
}

Para o celular, acabou.

Mas nós somos profissionais de mainframe.

Queremos abrir a parede.

Talvez exista:

APP MOBILE
    ↓
INTERNET
    ↓
API GATEWAY
    ↓
z/OS CONNECT
    ↓
CICS
    ↓
COBOL
    ↓
DB2

Ou:

API
 ↓
IMS
 ↓
COBOL
 ↓
IMS DB

Ou ainda:

API
 ↓
CICS
 ↓
COBOL
 ↓
MQ
 ↓
OUTRO SISTEMA

Essa é a primeira lição.

API não substitui necessariamente o mainframe. API pode simplesmente fornecer uma nova porta para chegar até ele.

---

🔌 CAPÍTULO 2 — API NÃO É MÁGICA

API significa Application Programming Interface.

Em termos simples, ela estabelece uma forma definida para dois softwares conversarem.

Temos:

CLIENTE
   |
 REQUEST
   ↓
  API
   |
 PROCESSAMENTO
   ↓
 RESPONSE
   |
   ↓
CLIENTE

Para quem vem do COBOL, isso não deveria parecer tão alienígena.

Pense numa COMMAREA.

Um programa recebe uma estrutura:

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

Processa e devolve:

01 WS-RESPONSE.
   05 WS-RETURN-CODE PIC 9(04).
   05 WS-NAME        PIC X(40).
   05 WS-BALANCE     PIC S9(9)V99 COMP-3.

Uma API também recebe dados e devolve dados.

A representação mudou.

Podemos receber:

{
  "customerId": 123456
}

e responder:

{
  "name": "BELLACOSA",
  "balance": 317.00
}

O jovem programador olha para JSON e pensa:

— Moderníssimo!

O veterano COBOL olha e pensa:

— É um layout de dados usando chaves, colchetes e bastante marketing.

Nathan provavelmente aprovaria a segunda resposta.

---

🌐 CAPÍTULO 3 — HTTP: O PROTOCOLO QUE CARREGA A CONVERSA

Muitas APIs REST utilizam HTTP.

Uma requisição pode conter:

URL
METHOD
HEADERS
QUERY PARAMETERS
BODY

Exemplo:

POST /customers HTTP/1.1
Host: api.banco.com
Content-Type: application/json
Authorization: Bearer eyJ...

Body:

{
  "name": "Caleb",
  "age": 26
}

Observe as peças.

Endpoint é o endereço lógico do recurso:

/customers

Headers carregam informações adicionais:

Content-Type
Authorization
Accept
Correlation-ID

Body contém os dados enviados.

Isso nos leva aos verbos HTTP.

---

🛠️ CAPÍTULO 4 — GET, POST, PUT, PATCH E DELETE

Os cinco verbos mais importantes para nosso iniciante são:

GET     consultar
POST    criar/processar
PUT     substituir
PATCH   alterar parcialmente
DELETE  remover

Podemos construir uma analogia COBOL/Db2 apenas para aprendizado:

GET       ≈ SELECT
POST      ≈ INSERT/operação
PUT       ≈ UPDATE completo
PATCH     ≈ UPDATE parcial
DELETE    ≈ DELETE

Mas escreva em letras enormes no caderno:

ANALOGIA NÃO É EQUIVALÊNCIA.

Considere:

POST /payments

Ele talvez execute:

POST
 ↓
z/OS Connect
 ↓
CICS
 ↓
COBOL
 ├── SELECT DB2
 ├── UPDATE DB2
 ├── INSERT DB2
 ├── MQ PUT
 └── COMMIT

Portanto POST não significa necessariamente INSERT.

Ele significa que estamos solicitando determinada operação segundo o contrato daquela API.

---

🚦 CAPÍTULO 5 — STATUS CODE É O RETURN CODE DA INTERNET?

Mais uma analogia útil, mas imperfeita.

O mainframer conhece:

RC=0000
RC=0004
RC=0008
RC=0012
S0C7
S0C4

HTTP possui famílias de códigos:

1xx → informação
2xx → sucesso
3xx → redirecionamento
4xx → problema relacionado à requisição
5xx → falha do servidor

Alguns essenciais:

200 OK
201 Created
204 No Content

400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
409 Conflict
429 Too Many Requests

500 Internal Server Error
503 Service Unavailable

Mas aqui Nathan interrompe a aula.

— Você recebeu 200. Então funcionou?

Não necessariamente.

Veja:

HTTP/1.1 200 OK

{
  "transaction": "FAILED",
  "reason": "INSUFFICIENT_FUNDS"
}

HTTP funcionou.

A API respondeu.

Mas a operação de negócio falhou.

Temos, portanto, pelo menos três perguntas diferentes:

TRANSPORTE
HTTP funcionou?
       ↓
CONTRATO
Resposta possui a estrutura correta?
       ↓
NEGÓCIO
A operação produziu o resultado correto?

Esse pequeno detalhe separa teste superficial de teste sério.

---

📜 CAPÍTULO 6 — OPENAPI: O COPYBOOK DO MUNDO REST?

Calma.

Não literalmente.

Mas para ensinar COBOL é uma analogia fantástica.

Um copybook pode definir:

01 CUSTOMER.
   05 CUSTOMER-ID     PIC 9(10).
   05 CUSTOMER-NAME   PIC X(40).
   05 CUSTOMER-STATUS PIC X(01).

Uma especificação OpenAPI pode descrever uma representação semelhante:

Customer:
  type: object
  required:
    - customerId
    - customerName
  properties:
    customerId:
      type: integer
    customerName:
      type: string
    status:
      type: string

Antes de testar uma API, leia sua documentação.

Procure:

endpoints
métodos
parâmetros
headers
schemas
autenticação
exemplos
responses
erros

Não comece clicando freneticamente em Send no Postman.

Primeiro descubra qual deveria ser o comportamento.

Teste sem requisito vira adivinhação automatizada.

---

🧪 CAPÍTULO 7 — POSTMAN: O TERMINAL 3270 DO EXPLORADOR DE APIs

Imagine esta evolução:

3270
 ↓
CICS
 ↓
COBOL

Agora:

Postman
 ↓
HTTP
 ↓
API
 ↓
z/OS Connect
 ↓
CICS
 ↓
COBOL

O Postman permite montar requisições, headers, parâmetros, autenticação e body, além de examinar respostas e organizar chamadas em collections.

Comece simples.

Faça:

GET /customers/123

Clique em Send.

Não comemore ainda.

Inspecione:

status code
headers
body
schema
response time
business rules

Uma resposta não deve ser considerada correta simplesmente porque apareceu alguma coisa na tela.

---

😊 CAPÍTULO 8 — HAPPY PATH: PRIMEIRO PROVE QUE AVA CONSEGUE CONVERSAR

O teste positivo verifica comportamento esperado com entradas válidas.

Exemplo:

POST /customers

{
  "name": "Nathan Bateman",
  "type": "PREMIUM"
}

Esperamos talvez:

201 Created

e:

{
  "customerId": 12345,
  "name": "Nathan Bateman",
  "type": "PREMIUM"
}

Validamos:

dados válidos
fluxo correto
permissão adequada
resultado esperado
persistência correta

Ótimo.

Mas isso prova apenas que o sistema funciona quando todos se comportam.

Produção não possui essa delicadeza.

---

😈 CAPÍTULO 9 — O TESTE COMEÇA QUANDO AS COISAS DÃO ERRADO

Agora Nathan fica interessado.

Envie:

{
  "amount": -500
}

Depois:

{
  "amount": "CINCO REAIS"
}

Depois:

{}

Depois:

{
  "amount": null
}

Teste:

• campos ausentes;

• tipos inválidos;

• limites;

• JSON malformado;

• dados duplicados;

• métodos não suportados;

• valores negativos;

• valores enormes;

• strings vazias;

• recursos inexistentes;

• credenciais inválidas.

O sistema bom não é aquele que apenas sabe funcionar.

É aquele que sabe falhar corretamente.

---

💣 CAPÍTULO 10 — PIC 9(7)V99 ENCONTRA JSON

Aqui aparece um problema particularmente interessante para mainframers.

COBOL:

05 WS-AMOUNT PIC 9(7)V99.

API:

{
  "amount": 999999999999999999.99
}

Quem impede isso?

Gateway?

Schema?

z/OS Connect?

Programa intermediário?

COBOL?

Db2?

E se ninguém impedir?

Esse é um maravilhoso teste de boundary.

Teste:

0
0.01
9999999.99
10000000.00
-0.01
NULL
"ABC"

A fronteira é justamente onde muitos defeitos ficam escondidos.

---

🔐 CAPÍTULO 11 — "QUEM É VOCÊ?" NÃO É "O QUE VOCÊ PODE FAZER?"

Autenticação:

Quem é você?

Autorização:

O que você pode acessar?

Essa distinção é vital.

No IBM Z podemos encontrar uma cadeia como:

OAuth/OIDC
    ↓
API Gateway
    ↓
token
    ↓
z/OS
    ↓
SAF
    ↓
RACF

Mas autenticar alguém não significa permitir qualquer operação.

Teste:

sem token
token inválido
token expirado
token correto
scope incorreto
usuário sem privilégio
usuário privilegiado
recurso de outro usuário

Um 401 e um 403 não significam exatamente a mesma coisa.

E existe uma pergunta ainda mais interessante:

Um usuário autorizado para consultar seus dados consegue trocar /123 por /124 e consultar dados de outra pessoa?

Isso testa autorização no nível do objeto, não apenas login.

---

🧬 CAPÍTULO 12 — TEST DATA: NÃO USE PRODUÇÃO COMO PARQUINHO

Dados de teste precisam ser:

controlados
repetíveis
realistas
seguros
isolados
limpáveis

No mainframe isso pode ser particularmente delicado.

Existem ambientes com dados acumulados durante décadas.

Você encontrará:

EBCDIC
COMP
COMP-3
campos redefinidos
datas históricas
códigos descontinuados
valores especiais
copybooks antigos
registros migrados

E existe ainda segurança e privacidade.

Mascarar dados sensíveis é fundamental quando dados semelhantes aos de produção precisam alimentar testes.

E nunca coloque senha, token ou segredo dentro do script:

PASSWORD=SUPERSECRET123

Nathan certamente encontraria.

O auditor também.

---

🗄️ CAPÍTULO 13 — DATABASE VALIDATION: OLHE ATRÁS DO VIDRO

Agora chegamos ao coração do problema.

Você envia:

POST /transfers

{
  "from": "100001",
  "to": "200002",
  "amount": 500.00
}

Recebe:

200 OK

Fim?

Não.

Precisamos descobrir o efeito.

Antes:

A = 2000
B = 1000

Depois:

A = 1500
B = 1500

Precisamos validar:

débito correto
crédito correto
nenhum registro duplicado
histórico criado
mensagem MQ correta
audit trail
commit

Agora provoque uma falha depois do débito e antes do crédito.

O resultado correto provavelmente deverá envolver:

ROLLBACK

e não:

A = 1500
B = 1000

Essa é a diferença entre testar uma tela JSON e testar uma transação.

---

🔄 CAPÍTULO 14 — COMMIT, ROLLBACK E A UNIT OF WORK

Mainframe conhece esse problema há décadas.

Uma API pode iniciar uma cadeia:

REQUEST
 ↓
CICS
 ↓
COBOL
 ↓
DB2
 ↓
MQ

Agora surgem perguntas realmente interessantes:

O que pertence à mesma unidade de trabalho?

Quando ocorre COMMIT?

O que acontece se MQ falhar?

E se Db2 estiver indisponível?

E se a API sofrer timeout?

E se o cliente repetir a chamada?

Chegamos à palavra que deveria estar colada no monitor de qualquer desenvolvedor de pagamentos:

IDEMPOTÊNCIA

Imagine:

03:16:55 pagamento enviado

03:17:00 processamento iniciado

03:17:10 timeout

O aplicativo não sabe se funcionou.

Então repete.

Se o backend executar novamente:

R$500
R$500

acabamos de cobrar duas vezes.

Uma estratégia pode envolver uma chave de idempotência:

Idempotency-Key: PAY-ABC-123

O backend reconhece a repetição.

E sim: 03:17 apareceu por acaso.

Quem acompanha o Bellacosa Mainframe sabe que acidentes temporais desse tipo costumam ser cuidadosamente planejados. ☕

---

📐 CAPÍTULO 15 — CONTRACT TESTING: AVA MUDOU A LINGUAGEM

Hoje:

{
  "customerId": 123,
  "status": "ACTIVE"
}

Amanhã alguém decide "modernizar":

{
  "customerNumber": 123,
  "customerStatus": "ACTIVE"
}

O serviço continua funcionando.

Mas dez consumidores quebram.

É o equivalente moderno do sujeito que altera um copybook compartilhado sem estudar impacto e depois pergunta por que metade da madrugada está em conference call.

Contract testing procura detectar mudanças incompatíveis antes que cheguem aos consumidores.

Aqui o mainframer possui uma vantagem cultural enorme.

Ele já conhece o medo saudável de:

"Quem mais usa isso?"

---

🏎️ CAPÍTULO 16 — PERFORMANCE: 120 MILISSEGUNDOS NÃO CONTAM TODA A HISTÓRIA

Uma API responde em:

120 ms

Excelente.

Com um usuário.

Agora tente 100.

1.000.

10.000.

50.000.

Precisamos observar:

latency — tempo de resposta;

throughput — quantidade processada;

error rate — percentual de falhas;

concurrency — usuários/operações simultâneos.

Existem ainda quatro cenários clássicos:

LOAD
carga normal esperada

SPIKE
explosão repentina

STRESS
além do limite normal

SOAK
carga sustentada durante longo período

No IBM Z, não pare no tempo HTTP.

Investigue:

API Gateway
     ↓
z/OS Connect
     ↓
CICS
     ↓
COBOL
     ↓
Db2
     ↓
CPU / I/O / LOCKS

Pode ser que HTTP esteja apenas mostrando o sintoma.

---

🕵️ CAPÍTULO 17 — SEGURANÇA: NATHAN NÃO CONFIA NA INTERFACE

API Security Testing precisa procurar problemas como:

autenticação
autorização
input validation
rate limiting
exposição de dados
configurações inseguras

No mainframe adicionamos outra camada:

SAF
RACF
TLS
AT-TLS
certificados
SMF
proteção CICS
privilégios Db2
permissões USS
segregação de funções
auditoria

Um erro particularmente perigoso é retornar informação demais.

Exemplo:

{
  "name": "USER",
  "balance": 500,
  "internalRacfUser": "ABC123",
  "databaseHost": "PRODDB2",
  "debugMessage": "SQLCODE -..."
}

Talvez três desses campos jamais devessem sair dali.

Erro também é dado.

Log também é dado.

Stack trace também é dado.

Portanto teste o que o sistema revela quando falha.

---

🤖 CAPÍTULO 18 — AUTOMATIZE, MAS NÃO AUTOMATIZE BURRICE

Depois dos testes manuais estáveis, automatizamos.

Ferramentas possíveis incluem:

Postman/Newman
REST Assured
Playwright API
SuperTest

Um framework saudável separa:

config/
api-clients/
test-data/
tests/
reports/

Isso evita aquele script de 4.000 linhas onde URL, senha, payload, teste, relatório e provavelmente o CPF do desenvolvedor estão todos misturados.

Automação boa precisa ser:

repetível
independente
legível
determinística
diagnosticável
manutenível

Automatizar um teste ruim produz um teste ruim que roda mais rápido.

---

🏭 CAPÍTULO 19 — CI/CD: O COBOL ENTRA NA ESTEIRA

Agora o teste deixa de depender de alguém clicar em Send.

Podemos ter:

COMMIT
   ↓
BUILD
   ↓
UNIT TEST
   ↓
API TEST
   ↓
CONTRACT TEST
   ↓
SECURITY CHECK
   ↓
DEPLOY DEV
   ↓
INTEGRATION TEST
   ↓
QUALITY GATE
   ↓
PROMOTION

Isso também é DevOps no mainframe.

COBOL não precisa deixar de ser COBOL.

CICS não precisa fingir que é Kubernetes.

Db2 não precisa colocar boné para trás.

O objetivo é introduzir práticas modernas de engenharia em torno das plataformas adequadas.

---

🔭 CAPÍTULO 20 — OBSERVABILIDADE: AVA RESPONDEU, MAS O QUE ELA ESTAVA FAZENDO?

Chegamos ao estágio mais interessante.

Testes dizem:

"Sob estas condições, obtive este resultado."

Observabilidade pergunta:

"O que o sistema está realmente fazendo?"

Precisamos de evidências.

logs
metrics
traces
request IDs
test reports
artifacts

No IBM Z temos uma riqueza enorme de telemetria:

SMF
RMF
CICS statistics
Db2 accounting
Db2 statistics
MQ statistics
WLM
logs
network telemetry

Imagine colocar:

X-Request-ID: CALEB-0317

e acompanhar:

CALEB-0317
    ↓
API Gateway
    ↓
z/OS Connect
    ↓
CICS
    ↓
COBOL
    ↓
Db2

De repente não temos apenas:

"A API demorou 4 segundos."

Temos:

"A requisição chegou ao z/OS, entrou na transação CICS, esperou determinado recurso e a maior parte do tempo foi consumida naquela etapa."

Isso muda completamente a investigação.

---

🧪 CAPÍTULO 21 — O LABORATÓRIO FINAL DE NATHAN

Sua missão é testar:

POST /accounts/transfer

Payload:

{
  "from": "100001",
  "to": "200002",
  "amount": 500.00
}

Arquitetura:

CLIENT
  ↓
HTTPS
  ↓
API GATEWAY
  ↓
z/OS CONNECT
  ↓
CICS
  ↓
COBOL
  ↓
DB2
  ↓
MQ

Comece pelo happy path.

Depois execute:

conta origem inexistente
conta destino inexistente
saldo insuficiente
amount = 0
amount negativo
amount máximo
amount acima do máximo
amount como texto
campo ausente
JSON quebrado
token ausente
token expirado
scope incorreto
usuário sem autorização
requisição duplicada
timeout
Db2 indisponível
MQ indisponível
100 requests simultâneos
1.000 requests
spike
soak

Depois de cada cenário, pergunte:

HTTP correto?
JSON correto?
Schema correto?
Regra de negócio correta?
Db2 correto?
MQ correto?
Commit correto?
Rollback correto?
RACF correto?
Logs corretos?
SMF mostra o esperado?
Performance aceitável?
Dados sensíveis protegidos?

Agora você não está mais testando simplesmente uma API.

Está testando um serviço de negócio distribuído de ponta a ponta.

---

🧠 CAPÍTULO 22 — O TESTE DE TURING DO MAINFRAME

Nathan volta à sala.

Na tela aparecem duas respostas:

{
  "status": "SUCCESS"
}

e:

{
  "status": "SUCCESS"
}

São idênticas.

Nathan pergunta:

— Qual delas está correta?

Você não responde.

Abre o Db2.

Verifica a transação CICS.

Consulta evidências.

Confere MQ.

Verifica autorização.

Procura duplicidades.

Analisa logs.

Correlaciona Request ID.

Observa métricas.

Confere o contrato.

Finalmente responde:

— A primeira.

Nathan pergunta:

— Como sabe?

E aí está toda a diferença:

— Porque eu não confiei na interface. Eu validei o sistema.

---

☕ EPÍLOGO — A API NÃO PRECISAVA SER HUMANA

Existe uma deliciosa ironia nessa história.

Muitos conceitos vendidos como absolutamente modernos são problemas que o mundo mainframe enfrenta há décadas.

Hoje dizemos:

schema

O mainframer lembra de layouts e copybooks.

Hoje:

transaction consistency

Ele pensa em unit of work, commit e rollback.

Hoje:

authorization

Ele pensa em SAF/RACF e também nas regras de autorização da aplicação.

Hoje:

observability

Ele pergunta:

— Quais registros SMF temos?

Hoje:

high availability

Ele sorri.

Hoje:

backward compatibility

Agora ele começa a rir.

Isso não significa que REST, OpenAPI, OAuth, CI/CD ou observabilidade moderna sejam apenas nomes novos para tecnologias antigas. Não são.

Significa algo mais interessante.

Os problemas fundamentais da computação permanecem surpreendentemente constantes:

Quem pediu?

Pode pedir?

Os dados são válidos?

O processamento aconteceu?

A informação foi persistida?

A transação terminou inteira?

Se falhou, voltou ao estado consistente?

Se repetiu, duplicou?

Quanto demorou?

Quantas conseguimos processar?

Quem consegue observar isso?

Quem consegue alterar isso?

Conseguimos provar depois o que aconteceu?

E aqui está talvez a maior lição para o programador COBOL iniciante.

Não tenha medo quando alguém colocar na sua frente:

REST
JSON
OAuth
OpenAPI
Postman
CI/CD
Observability

Você não está abandonando tudo o que aprendeu.

Está aumentando seu campo de visão.

Ontem você enxergava:

3270
 ↓
CICS
 ↓
COBOL
 ↓
DB2

Hoje precisa enxergar:

                    INTERNET
                       │
                       ▼
                  API GATEWAY
                       │
                       ▼
                 z/OS CONNECT
                       │
              ┌────────┴────────┐
              ▼                 ▼
            CICS               IMS
              │                 │
              └───────┬─────────┘
                      ▼
                    COBOL
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
         DB2         VSAM         MQ
          │           │           │
          └───────────┼───────────┘
                      ▼
                COMMIT/ROLLBACK
                      │
                      ▼
               RESPONSE JSON

E ao redor de tudo isso:

        SECURITY
            │
            ▼
   ┌───────────────────┐
   │                   │
RACF/SAF            OAuth
   │                   │
   └─────────┬─────────┘
             │
             ▼
          AUDIT
             │
             ▼
       OBSERVABILITY
             │
     ┌───────┼────────┐
     ▼       ▼        ▼
    SMF     LOGS    METRICS

Essa é a arquitetura que o teste precisa enxergar.

A API é apenas o vidro.

Atrás dela existe uma máquina inteira.

---

🥚 EASTER EGG — 03:17

Às 03:17, todas as luzes do laboratório apagam.

O programador COBOL continua sentado.

Nathan pergunta:

— Você não está preocupado?

— Não.

— Por quê?

Ele aponta para o monitor.

HTTP 200

Nathan sorri.

O programador responde:

— Também não confio nisso.

Abre outra janela.

CICS: OK
DB2 : COMMIT
MQ  : MESSAGE PUT
RACF: AUTHORIZED
SMF : RECORDED

Então pega o café.

— Agora sim.

Porque no Bellacosa Mainframe existe uma regra que Nathan Bateman aprenderia rapidamente:

Não importa o quão bonita seja a interface, o quão perfeito seja o JSON ou quantos 200 OK apareçam na tela. Em sistemas de missão crítica, confiança não vem da aparência da resposta. Vem da evidência de que toda a cadeia fez exatamente aquilo que deveria fazer.

E talvez esse seja o verdadeiro Teste de Turing de uma API mainframe:

não descobrir se ela consegue parecer inteligente,

mas provar que, quando ninguém está olhando, ela continua sendo correta, segura, consistente, observável e confiável.

☕ Um Café no Bellacosa Mainframe

Onde até Ava teria que apresentar evidência de COMMIT antes de receber acesso à produção.

🎌🌈 Por que tantos fãs de anime são LGBT+?

 🎌🌈 Por que tantos fãs de anime são LGBT+?

Uma reflexão Bellacosa sobre identidade, espelhos e liberdade na cultura otaku.

---

🎭 O Espelho das Emoções

Existe uma coisa mágica no anime: ele fala com o coração antes de falar com a lógica.
E é justamente por isso que tantos fãs LGBT+ se sentem acolhidos — porque o anime reflete sentimentos de diferença, transformação e autoaceitação que muitas pessoas vivem por dentro.

Séries como Revolutionary Girl Utena, Wandering Son ou Given não têm medo de tocar em temas de gênero, amor e identidade.
São histórias que dizem, sem precisar gritar:

“Tudo bem ser diferente. Tudo bem ser você.”

---

🌐 O Fandom como Refúgio

Durante anos, comunidades de anime foram refúgios digitais para quem se sentia deslocado.
No Tumblr, fóruns ou Discord, jovens encontraram espaço para desenhar, escrever e sonhar — sem julgamento.
Muitos descobriram ali que eram gays, bi, trans ou não-binários, assistindo a personagens que quebravam regras invisíveis da sociedade.

💬 “Percebi que era trans vendo Ranma mudar de corpo.”
💬 “Me senti visto pela primeira vez em Yuri on Ice.”

Essas frases não são coincidência — são a tradução emocional de um fenômeno cultural.

---

🎨 Estética e Liberdade

A cultura visual japonesa adora desafiar fronteiras:
bishounen (rapazes belos e andróginos), magical girls, personagens gender bender e visuais que misturam força e delicadeza.
Essa fluidez estética abre espaço para quem não cabe nas caixinhas do “menino ou menina”, “hétero ou gay”.

💡 Exemplos icônicos:

• Howl (O Castelo Animado) — beleza livre e fluida.

• Astolfo (Fate/Apocrypha) — charme andrógino que conquistou o fandom.

• Sailor Uranus e Neptune — casal que inspirou gerações antes mesmo de o tema ser aceito na TV ocidental.

---

📊 O Que Dizem as Tendências

Pesquisas em convenções e redes sociais mostram que a comunidade LGBT+ é majoritária em muitos fandoms de anime.
Mas isso não quer dizer que anime “torne” ninguém LGBT+.
O que acontece é que o anime acolhe, representa e inspira — e por isso tanta gente encontra ali um espelho do que sente.

---

🧩 Filosofia Bellacosa

O anime é um laboratório da alma.
Ele permite experimentar identidades, amores e mundos onde ser diferente não é um problema, mas uma força.

No fim das contas, a correlação entre anime e LGBT+ não é biológica — é emocional e simbólica.
O anime não muda quem você é; ele te ajuda a enxergar quem você sempre foi.

---

☕ Bellacosa Conclui:
Anime é arte da empatia, e empatia é a linguagem universal da liberdade.
Por isso, onde há um coração otaku, quase sempre há também um arco-íris de possibilidades.

Bellacosa Mainframe apresenta o jenkins

☕ Um Café no Bellacosa Mainframe

🧪 RICK SANCHEZ E O JENKINSFILE DA DIMENSÃO C-137

Jenkins Pipelines, Git, agentes, artefatos, containers, quality gates, rollback, observabilidade — e o dia em que Rick descobriu que o verdadeiro monstro da produção não era um alienígena, mas um deploy manual de sexta-feira.

Nota de estilo: este artigo usa Rick Sanchez como lente humorística e paródica. A explicação técnica, porém, é bem terrestre — e perigosamente aplicável à produção.

---

🎬 PRÓLOGO — MORTY, QUEM FEZ DEPLOY DIRETO EM PRODUÇÃO?

Imagine a cena.

03:17 da madrugada.

O celular toca.

Produção caiu.

CICS está respondendo.

Db2 está de pé.

MQ aparentemente está normal.

CPU está em 34%.

Nenhum LPAR está pegando fogo.

Mesmo assim, clientes não conseguem concluir transações.

Rick olha para Morty.

— Morty... o que você mudou?

— Nada, Rick!

— Morty, todo programador que diz "nada" às 03:17 acabou de alterar alguma coisa.

Cinco minutos depois descobrimos:

Mudança emergencial
      ↓
Compilação manual
      ↓
Load module copiado manualmente
      ↓
Produção
      ↓
"Funcionou aqui"

Rick pega a portal gun.

Não para fugir.

Para mandar o responsável para uma dimensão na qual toda implantação precisa ser feita manualmente pelo resto da eternidade.

E aqui começa nossa história.

Porque Jenkins Pipeline não é simplesmente uma ferramenta para "automatizar compilação".

Estamos falando de algo conceitualmente muito maior:

SOURCE
   ↓
BUILD
   ↓
TEST
   ↓
QUALITY
   ↓
SECURITY
   ↓
PACKAGE
   ↓
APPROVAL
   ↓
DEPLOY
   ↓
VERIFY
   ↓
OBSERVE

O Jenkins ajuda a transformar o processo de entrega do software em software.

A própria documentação do Jenkins define Pipeline como uma maneira de modelar o processo de entrega como código; um Jenkinsfile pode ficar junto ao código-fonte, permitindo revisão, histórico de auditoria e uma fonte comum da definição da pipeline. (Jenkins)

E para quem passou décadas no mainframe existe algo deliciosamente familiar nisso tudo.

---

🧪 CAPÍTULO 1 — RICK DESCOBRE QUE O JENKINS NÃO FAZ QUASE NADA

Esse é um dos primeiros conceitos que eu ensinaria para alguém começando em DevOps:

Jenkins não é a fábrica. Jenkins é o maestro da fábrica.

O Jenkins não precisa ser o compilador.

Não precisa ser o scanner de vulnerabilidades.

Não precisa ser o repositório Git.

Não precisa ser o repositório de artefatos.

Não precisa ser Kubernetes.

Ele coordena ferramentas que executam essas funções.

Pense:

                    ┌─────────────┐
                    │   JENKINS   │
                    │ ORCHESTRATOR│
                    └──────┬──────┘
                           │
        ┌──────────────────┼──────────────────┐
        ↓                  ↓                  ↓
       Git              Compiler          Tests
        │                  │                  │
        └──────────┬───────┴─────────┬────────┘
                   ↓                 ↓
             Security Scan      Artifact Repo
                   │                 │
                   └────────┬────────┘
                            ↓
                         Deploy
                            ↓
                       Production

Rick provavelmente resumiria:

"Morty, Jenkins não constrói a nave. Ele manda cada idiota da garagem fazer sua parte na ordem certa."

E isso é importante porque muita arquitetura ruim nasce quando Jenkins vira uma espécie de Deus DevOps.

Jenkins chama Docker.

Docker constrói uma imagem.

Jenkins publica a imagem em um registry.

Uma ferramenta de deployment ou Kubernetes executa essa imagem.

São responsabilidades diferentes.

---

🧠 CAPÍTULO 2 — O JENKINSFILE É O JCL DO DEVOPS?

Calma.

Antes que alguém arremesse um manual do JES2 na minha cabeça:

não tecnicamente.

Mas pedagogicamente a comparação é excelente.

Para um programador COBOL entrando em Jenkins, podemos imaginar:

Mundo mainframe	Jenkins/DevOps
JOB	Pipeline
STEP	Stage/Step
EXEC	execução de ferramenta
RC	exit status
SYSOUT	logs
load module	artifact
PROCLIB	lógica reutilizável/shared library
scheduler	parte da orquestração

Não são equivalências arquitetônicas 1:1.

São pontes mentais.

Veja um JCL:

//BELLACOS JOB ...
//COMPILE EXEC PGM=IGYCRCTL
//LINK    EXEC PGM=IEWL
//TEST    EXEC PGM=TESTPGM

Agora uma pipeline extremamente simplificada:

pipeline {
    agent any

    stages {
        stage('Compile') {
            steps {
                sh './compile.sh'
            }
        }

        stage('Test') {
            steps {
                sh './test.sh'
            }
        }

        stage('Package') {
            steps {
                sh './package.sh'
            }
        }
    }
}

Um mainframer olha isso e pensa:

"Vocês inventaram STEP de novo."

😂

Mas existe uma evolução importantíssima.

O Jenkinsfile pode estar dentro do mesmo repositório Git da aplicação.

Portanto:

programa mudou
pipeline mudou
teste mudou
configuração mudou

Tudo isso pode passar pelo mesmo mecanismo de versionamento e revisão.

O Jenkins recomenda manter o Jenkinsfile no source control, justamente por benefícios como revisão, auditabilidade e uma fonte comum da definição da pipeline. (Jenkins)

---

🛸 CAPÍTULO 3 — CONTROLLER E AGENTS: RICK NÃO FAZ O TRABALHO PESADO

Imagine Rick administrando cem Mortys.

Rick recebe os pedidos.

Decide prioridades.

Escolhe quem executará cada tarefa.

Coordena tudo.

Mas seria absurdo Rick pessoalmente pegar cada programa, compilar, testar, empacotar e instalar.

No Jenkins existe uma ideia semelhante:

             JENKINS CONTROLLER
                    │
       ┌────────────┼────────────┐
       ↓            ↓            ↓
   AGENT-01     AGENT-02     AGENT-03
    Linux        z/OS         Docker

O controller administra a coordenação.

Os agents fornecem ambientes onde o trabalho efetivamente é executado.

Um agent poderia possuir:

Java
Maven
Git
Docker
Python
Node.js

Outro poderia possuir ferramentas específicas.

No universo IBM Z, podemos ter integração com ferramentas e processos executados no próprio z/OS.

E novamente surge uma analogia útil com mainframe.

JES2 recebe trabalho, gerencia filas e participa da seleção/execução conforme recursos e classes.

Não significa que Jenkins seja "um JES moderno".

Não é.

Mas o conceito de separar orquestração do trabalho de execução do trabalho certamente não provoca choque cultural em quem conhece mainframe.

---

🧬 CAPÍTULO 4 — O PIPELINE DE PRODUÇÃO NÃO É BUILD → DEPLOY

Essa simplificação é perigosa:

BUILD → DEPLOY

Uma pipeline de produção madura se parece muito mais com:

COMMIT
   ↓
CHECKOUT
   ↓
DEPENDENCY ANALYSIS
   ↓
BUILD
   ↓
UNIT TEST
   ↓
STATIC ANALYSIS
   ↓
SECURITY SCAN
   ↓
QUALITY GATE
   ↓
PACKAGE
   ↓
PUBLISH ARTIFACT
   ↓
DEPLOY DEV
   ↓
INTEGRATION TEST
   ↓
DEPLOY SIT
   ↓
DEPLOY UAT
   ↓
APPROVAL
   ↓
DEPLOY PROD
   ↓
VERIFY
   ↓
OBSERVE

Cada estágio deveria responder a uma pergunta.

Build: conseguimos construir?

Test: o comportamento conhecido continua correto?

Security: introduzimos riscos conhecidos?

Quality Gate: atingimos os critérios mínimos?

Deploy: conseguimos instalar?

Verify: o software realmente iniciou e responde?

Observe: continua saudável sob tráfego real?

É aí que aparece uma das frases mais importantes deste artigo:

🚨 DEPLOY SUCCESS ≠ SYSTEM HEALTHY

Morty vê isto:

DEPLOY ........ SUCCESS

e comemora.

Rick pergunta:

"E as transações?"

Silêncio.

---

💳 CAPÍTULO 5 — O SISTEMA ESTÁ VERDE, MAS O NEGÓCIO ESTÁ MORTO

Vamos trazer isso para Cards & Payments.

Imagine um programa COBOL:

AUTHORIZATION

Antes do deploy:

Approval Rate: 87%
CICS Response: 120 ms
CPU: 32%
Db2: NORMAL
MQ: NORMAL

Depois:

Approval Rate: 41%
CICS Response: 118 ms
CPU: 31%
Db2: NORMAL
MQ: NORMAL

Dashboard de infraestrutura:

🟢 CPU

🟢 Memória

🟢 CICS

🟢 Db2

🟢 MQ

Dashboard do negócio:

🔥🔥🔥🔥🔥🔥🔥

A aplicação está respondendo perfeitamente...

e recusando clientes perfeitamente.

Isso nos conduz a uma evolução importantíssima de observabilidade:

TECHNICAL HEALTH
        +
BUSINESS HEALTH
        =
PRODUCTION HEALTH

Para uma autorização de cartões poderíamos acompanhar:

approval rate
decline rate
timeout rate
reversal rate
duplicate transactions
average authorization latency
transactions/minute

Isso é infinitamente mais poderoso do que perguntar apenas:

"A JVM está viva?"

Ou:

"O CICS está UP?"

---

🧪 CAPÍTULO 6 — QUALITY GATES: RICK PROÍBE MORTY DE APERTAR O BOTÃO

Imagine:

Compile       OK
Unit Tests    OK
Coverage      42%
Security      CRITICAL
Quality       FAILED

Morty pergunta:

— Posso mandar para produção?

Rick:

— Claro. E depois podemos testar se respirar no espaço sem capacete realmente mata.

Quality Gates transformam regras organizacionais em controles executáveis.

Podemos determinar:

IF compilation failed
    STOP

IF mandatory tests failed
    STOP

IF critical vulnerability exists
    STOP

IF artifact is invalid
    STOP

Isso é fail fast.

Descobriu cedo?

Pare cedo.

Porque existe uma matemática cruel:

erro descoberto no desenvolvimento
        ↓
barato

erro descoberto no teste
        ↓
mais caro

erro descoberto em produção
        ↓
War Room + pizza + café + 03:17

---

🔐 CAPÍTULO 7 — MORTY COLOCOU A SENHA NO JENKINSFILE

Rick abre o repositório:

environment {
    USER = "PRODADMIN"
    PASSWORD = "Morty123"
}

Silêncio.

Rick olha para Morty.

Morty olha para Rick.

Rick abre o portal.

😂

Segredos não devem ser hardcoded no código da pipeline.

Jenkins oferece mecanismos de credentials que permitem trabalhar com diferentes tipos de segredo e vinculá-los durante a execução. A documentação também alerta para os cuidados necessários com interpolação e exposição acidental em logs. (Jenkins)

Mas existe uma pegadinha.

Mascarar uma senha no log não transforma uma arquitetura insegura em arquitetura segura.

Precisamos combinar:

Secure storage
      +
Least privilege
      +
Credential scope
      +
Log hygiene
      +
Rotation
      +
Access control

Outra distinção importante:

ENVIRONMENT VARIABLE ≠ SECRET

Uma variável de ambiente pode conter um segredo.

Mas isso não significa que qualquer environment variable seja um mecanismo seguro para armazenamento de segredo.

---

📦 CAPÍTULO 8 — BUILD ONCE, PROMOTE MANY

Aqui aparece uma ideia maravilhosa.

Imagine:

DEV
 ↓
build A

TEST
 ↓
build B

UAT
 ↓
build C

PROD
 ↓
build D

Rick imediatamente perguntaria:

"Então exatamente o que vocês testaram?"

Essa pergunta destrói a arquitetura.

Porque se eu reconstruí o software entre ambientes, existe a possibilidade de diferenças em:

compiler
dependencies
configuration
timestamps
build environment
scripts
libraries

O modelo muito mais forte é:

SOURCE
   ↓
BUILD
   ↓
ARTIFACT X
   ↓
DEV
   ↓
TEST
   ↓
UAT
   ↓
PROD

O mesmo artefato vai sendo promovido.

A documentação atual da IBM para CI/CD em z/OS descreve explicitamente o artifact repository como peça que desacopla SCM dos ambientes de runtime e possibilita a prática de "Build once, deploy many". (IBM)

Agora conseguimos dizer:

APP       AUTHORIZATION
VERSION   4.7.2
COMMIT    a73fc91
BUILD     1842
ARTIFACT  auth-4.7.2-1842

Isso é rastreabilidade.

---

🧬 CAPÍTULO 9 — MAS COBOL TEM DEPENDÊNCIAS, RICK!

Exatamente.

Imagine:

COPY CARDREC.
COPY AUTHRESP.

O desenvolvedor altera:

CARDREC

Quem precisa ser recompilado?

É justamente aqui que o problema fica interessante no mainframe.

A IBM descreve o Dependency Based Build como solução para aplicações tradicionais z/OS, incluindo COBOL e PL/I, capaz de rastrear dependências e realizar builds integrados a workflows Git e ferramentas como Jenkins. (IBM)

Assim podemos imaginar:

Git commit
     ↓
Jenkins
     ↓
DBB
     ↓
Dependency Analysis
     ↓
Programs impacted
     ↓
Compile
     ↓
Link-edit
     ↓
Test

Em vez de:

"Alterou COPYBOOK? Compila tudo e reza."

A documentação IBM para DevOps em z/OS inclui no conceito de build justamente dependências, compilação, link-edit e testes unitários; ela posiciona DBB como ferramenta principal para essa parte específica do fluxo z/OS. (IBM)

---

🧙 CAPÍTULO 10 — O PIPELINE COBOL DA DIMENSÃO C-137

Agora podemos construir mentalmente algo muito interessante:

             DEVELOPER
                 │
                 ↓
                Git
                 │
              Webhook
                 │
                 ↓
              Jenkins
                 │
                 ↓
        Dependency Analysis
                 │
                 ↓
             IBM DBB
                 │
       ┌─────────┼─────────┐
       ↓         ↓         ↓
     COBOL      PL/I    Copybooks
       │
       ↓
    Compile
       │
       ↓
   Link-edit
       │
       ↓
   Unit Tests
       │
       ↓
 Static Analysis
       │
       ↓
 Security Gate
       │
       ↓
 Artifact Repository
       │
       ↓
       SIT
       │
       ↓
       UAT
       │
       ↓
 Approval Gate
       │
       ↓
  PRODUCTION
       │
       ↓
 Verification
       │
       ↓
 Observability

Isso não é "tirar o mainframe do passado".

É justamente o contrário.

É integrar IBM Z ao processo corporativo moderno.

A própria orientação IBM sobre DevOps para Z apresenta uma pipeline CI/CD baseada em componentes como serviço Git e DBB, buscando alinhar ferramentas, práticas e resultados com as demais plataformas da empresa. (IBM)

---

🛑 CAPÍTULO 11 — O BOTÃO VERMELHO CHAMADO APPROVAL

Automação não significa:

ninguém controla nada

Esse é outro mito.

Uma pipeline pode chegar até:

Deploy Production

e parar:

╔══════════════════════════════════════╗
║       PRODUCTION APPROVAL           ║
║                                    ║
║ Tests.................... PASSED    ║
║ Security................. PASSED    ║
║ Quality.................. PASSED    ║
║ Artifact................. SIGNED    ║
║ Change Ticket............ VALID     ║
║                                    ║
║       [ APPROVE ] [ REJECT ]        ║
╚══════════════════════════════════════╝

Isso é especialmente relevante em ambientes regulados.

Governança não precisa significar:

planilha
+
e-mail
+
telefonema
+
reunião
+
"quem tem a senha?"

Governança também pode virar código e evidência.

---

🚀 CAPÍTULO 12 — ROLLING, BLUE-GREEN E CANARY

Agora Rick abre três portais.

Rolling

Temos:

V1 V1 V1 V1

Vamos substituindo gradualmente:

V2 V1 V1 V1
V2 V2 V1 V1
V2 V2 V2 V1
V2 V2 V2 V2

Útil quando a arquitetura suporta substituição gradual.

Blue-Green

Temos dois ambientes:

BLUE  → V1 → ACTIVE

GREEN → V2 → READY

Testamos Green.

Depois:

TRAFFIC
   ↓
 GREEN

Se houver problema e as condições permitirem retorno:

TRAFFIC
   ↓
 BLUE

Canary

Liberamos V2 para pequena parcela:

95% → V1
 5% → V2

Observamos.

Depois:

75% → V1
25% → V2

Depois:

50 / 50

até eventualmente:

100% → V2

No mainframe, não devemos copiar esses modelos cegamente como se CICS fosse Kubernetes.

Mas princípios semelhantes podem ser implementados, dependendo da arquitetura, usando regiões, roteamento, APIs, gateways, feature flags, LPARs ou segmentação de tráfego.

---

💥 CAPÍTULO 13 — ROLLBACK NÃO É CTRL+Z

Aqui mora um monstro.

Aplicamos:

PROGRAM V1
       ↓
PROGRAM V2

Deu problema.

Então:

PROGRAM V1

Resolvido?

Talvez.

Agora imagine que V2 também mudou:

COPYBOOK
DB2 SCHEMA
MQ MESSAGE
CONFIGURATION
API CONTRACT
DATA

O programa antigo pode não entender mais o estado atual.

Por exemplo:

V1:
01 CUSTOMER.
   05 ID      PIC 9(08).
   05 STATUS  PIC X.

V2:

01 CUSTOMER.
   05 ID      PIC 9(08).
   05 STATUS  PIC X.
   05 RISK    PIC 9(03).

Dependendo de onde e como esse contrato é utilizado, voltar somente o executável pode criar outro problema.

Portanto:

Rollback é propriedade da arquitetura, não apenas comando da ferramenta de deployment.

Precisamos pensar em:

Code rollback
Data rollback
Schema rollback
Configuration rollback
Infrastructure rollback
Contract compatibility

Rick não inventaria o plano de fuga depois que a dimensão começasse a explodir.

Nós também não deveríamos.

---

🔥 CAPÍTULO 14 — RETRY NÃO É CURA UNIVERSAL

Pipeline falhou?

Alguém imediatamente propõe:

retry(5)

Rick pergunta:

"Por quê?"

Excelente pergunta.

Retry pode fazer sentido para uma falha transitória:

network timeout
temporary API failure
registry temporarily unavailable

Mas imagine:

COBOL COMPILATION ERROR

Retry.

Erro.

Retry.

Erro.

Retry.

Erro.

Você não criou resiliência.

Criou um computador extremamente persistente em provar cinco vezes que seu código está errado.

😂

Podemos pensar:

TRANSIENT FAILURE
      ↓
    RETRY

DETERMINISTIC FAILURE
      ↓
    INVESTIGATE

---

🕵️ CAPÍTULO 15 — RICK SANCHEZ VIRA ANALISTA DE ABEND

Pipeline:

FAILED

Isso é praticamente inútil sozinho.

Precisamos perguntar:

Onde?
Quando?
Qual stage?
Qual command?
Qual return code?
Qual agent?
Qual commit?
Qual artifact?
Qual dependency?

É exatamente a disciplina que o mainframer já conhece.

Imagine:

JOB FAILED

Tá.

E daí?

Queremos:

JOB
 ↓
STEP
 ↓
ABEND
 ↓
S0C7
 ↓
PROGRAM
 ↓
OFFSET
 ↓
FIELD
 ↓
RECORD
 ↓
ORIGIN

Ou seja:

SYMPTOM ≠ ROOT CAUSE

Um pipeline maduro precisa fornecer evidência suficiente para transformar:

"deu pau"

em:

Security stage failed
      ↓
dependency scan
      ↓
library X
      ↓
critical vulnerability
      ↓
version Y
      ↓
introduced by commit Z

Isso é investigação.

---

📊 CAPÍTULO 16 — OBSERVE A PRÓPRIA PIPELINE

Aqui existe um nível acima.

Não monitoramos apenas a aplicação.

Monitoramos a fábrica que produz a aplicação.

Podemos acompanhar:

Pipeline Success Rate
Build Duration
Queue Waiting Time
Deployment Frequency
Failure Rate
Rollback Rate
Mean Recovery Time
Flaky Tests
Agent Utilization
Approval Waiting Time

Imagine:

Checkout .......... 1 min
Build ............. 8 min
Tests ............ 14 min
Security .......... 5 min
Package ........... 2 min
Approval ..........32 min
Deploy ............ 7 min
Verify ............ 5 min

Tempo total:

74 minutos

Qual é o gargalo?

Compilador?

Não.

Jenkins?

Não.

Mainframe?

Não.

32 minutos esperando alguém aprovar.

Agora DevOps deixa de ser conversa sobre ferramenta e começa a revelar problemas do fluxo organizacional.

Isso é poderoso.

---

🧠 CAPÍTULO 17 — O QUE ESTAMOS REALMENTE VERSIONANDO?

Nos velhos tempos poderíamos pensar:

SOURCE CODE

Hoje estamos caminhando para algo muito maior:

Source Code
+
Build Definition
+
Tests
+
Infrastructure
+
Security Policies
+
Deployment Rules
+
Observability

Ou seja:

Não estamos versionando apenas o programa. Estamos tentando versionar o processo pelo qual esse programa nasce, é validado, autorizado, implantado e observado.

Esse é um dos aspectos mais interessantes de Pipeline as Code.

A documentação Jenkins trata o Jenkinsfile justamente como parte versionável do projeto, enquanto a IBM descreve pipelines z/OS combinando Git, DBB e outros componentes de CI/CD. (Jenkins)

---

🧓 CAPÍTULO 18 — O MAINFRAMER DE 1985 ENTRA NA GARAGEM DO RICK

Agora vem meu Easter Egg favorito.

Coloque um mainframer veterano diante destas expressões:

Pipeline as Code
Infrastructure as Code
Policy as Code
Immutable Artifact
Return Code
Dependency Management
Automated Scheduling
Audit Trail
Separation of Duties
Repeatable Build

Ele talvez fique alguns segundos em silêncio.

Tome um gole de café.

Olhe para Rick.

E diga:

"Então vocês passaram quarenta anos distribuindo tudo para finalmente descobrir que processos declarativos, controlados, auditáveis, repetíveis e cheios de return codes eram uma boa ideia?"

Rick olha para Morty.

Morty olha para Rick.

E ninguém responde.

☕😂

Naturalmente, mainframe tradicional e DevOps moderno são arquiteturas e ecossistemas profundamente diferentes.

Mas existe uma continuidade filosófica fascinante:

REPETIBILIDADE
CONTROLE
AUTOMAÇÃO
RASTREABILIDADE
EVIDÊNCIA

Isso sempre teve enorme valor em sistemas críticos.

---

🧪 EPÍLOGO — A PIPELINE NÃO TERMINA NO DEPLOY

Aqui está o erro que eu mais gostaria que um Junior Engineer evitasse.

Pensar:

DEPLOY SUCCESS

          FIM

Não.

Eu redesenharia mentalmente a última página do notebook assim:

                 SOURCE
                    ↓
                   GIT
                    ↓
                 JENKINS
                    ↓
             BUILD + TEST
                    ↓
                SECURITY
                    ↓
              QUALITY GATE
                    ↓
                ARTIFACT
                    ↓
              ENVIRONMENTS
                    ↓
                APPROVAL
                    ↓
               PRODUCTION
                    ↓
                 VERIFY
                    ↓
              OBSERVABILITY
                    ↓
          ┌───────────────────┐
          │ SYSTEM HEALTHY ?  │
          └─────────┬─────────┘
              YES   │   NO
               ↓    │    ↓
             DONE   │ RECOVERY
                    │    ↓
                    │ INVESTIGATION
                    │    ↓
                    │ ROOT CAUSE
                    │    ↓
                    └──→ FIX

Porque entregar software não significa apenas copiar um binário.

Significa conseguir demonstrar:

qual código foi utilizado, qual versão foi construída, quais testes foram executados, quais controles foram satisfeitos, qual artefato foi promovido, quem autorizou a mudança, onde ele foi implantado e o que aconteceu depois que usuários reais começaram a utilizá-lo.

É aí que Jenkins deixa de ser "aquele negócio que roda script".

Torna-se parte de uma cadeia de engenharia.

E quando trazemos isso para IBM Z, COBOL, CICS, Db2, MQ e sistemas de pagamentos, percebemos algo ainda mais interessante: não precisamos jogar fora décadas de disciplina operacional para adotar DevOps.

Podemos fazer justamente o contrário.

Podemos combinar:

DISCIPLINA DO MAINFRAME
          +
AUTOMAÇÃO DEVOPS
          +
PIPELINE AS CODE
          +
OBSERVABILIDADE
          =
ENTREGA MODERNA DE SISTEMAS CRÍTICOS

A documentação IBM atual recomenda uma abordagem CI/CD para z/OS que integra SCM baseado em Git, DBB e ferramentas corporativas de pipeline; DBB, inclusive, integra-se a Jenkins por CLI e suporta aplicações tradicionais COBOL e PL/I. (IBM)

E essa talvez seja a grande lição que Rick deixaria antes de desaparecer pelo portal:

"Morty, qualquer idiota consegue automatizar um deploy. Engenharia é automatizar as evidências de que aquilo deveria ter sido implantado — e saber exatamente como reagir quando não deveria."

☕🧪

No Bellacosa Mainframe, eu resumiria em uma frase ainda mais simples:

A PIPELINE NÃO TERMINA QUANDO O DEPLOY TERMINA.

Ela termina quando temos evidências suficientes de que a versão correta foi construída, testada, autorizada, implantada e continua funcionando corretamente em produção.

E se alguém discordar...

Rick já está carregando a portal gun. 🛸