☕ Um Café no Bellacosa Mainframe

🔵 OS SMURFS E A ALDEIA DEVOPS ESCONDIDA DENTRO DO MAINFRAME

COBOL, Git, Jenkins, Terraform, Ansible, Docker, Kubernetes, OpenShift, CI/CD, RACF, CICS, Db2, MQ, SMF, RMF, observabilidade — e o dia em que o Papai Smurf descobriu que pintar o pipeline de azul não fazia o ABEND desaparecer.

---

🎬 PRÓLOGO — HÁ MUITO, MUITO TEMPO, EM UMA LPAR DISTANTE...

Existe uma pequena aldeia escondida no meio de uma floresta.

Nela vivem criaturas azuis que trabalham incansavelmente. Cada uma possui uma especialidade.

Há o Smurf Programador, que escreve COBOL.

O Smurf Operador, que observa o SDSF.

O Smurf DBA, que cuida do Db2.

O Smurf Segurança, que protege o RACF.

O Smurf CICS, que conhece cada transação.

O Smurf MQ, que jura que a mensagem foi entregue.

E existe, naturalmente, o Smurf Ranzinza:

"Eu odeio deploy de sexta-feira!"

No centro da aldeia está Papai Smurf, administrador de sistemas há tantos anos que ninguém sabe exatamente quando seu USERID foi criado.

Certo dia, um jovem Smurf chegou carregando uma caixa escrita:

DEVOPS.

Dentro havia palavras estranhas:

Git
Terraform
Ansible
Docker
Kubernetes
Jenkins
CI/CD
GitOps
Argo CD
Prometheus
Grafana
Observability

O jovem programador COBOL olhou assustado.

— Papai Smurf, precisamos jogar fora nosso mainframe?

Papai Smurf ajeitou o gorro vermelho.

— Não, meu pequeno Padawan azul. Precisamos entender quais problemas essas ferramentas estão tentando resolver.

Essa talvez seja a primeira grande lição desta história.

DevOps não é uma coleção de ferramentas.

DevOps é uma maneira de pensar sobre como software é construído, testado, entregue, observado, operado e melhorado.

Pegue seu café.

Vamos entrar na floresta.

---

🔵 CAPÍTULO 1 — O MAPA DA ALDEIA

Os projetos que analisamos começam com Linux, passam por AWS, Terraform, Ansible, Docker, registries, CI/CD, Jenkins, Kubernetes, EKS, TLS, GitOps, estratégias de deployment, secrets management e finalmente observabilidade.

À primeira vista parece outro planeta para alguém começando com COBOL.

Mas retire os nomes das ferramentas.

O que sobra?

CODE
  ↓
BUILD
  ↓
TEST
  ↓
PACKAGE
  ↓
DEPLOY
  ↓
VERIFY
  ↓
OBSERVE
  ↓
OPERATE

Agora compare com uma aplicação mainframe:

COBOL
  ↓
COMPILE
  ↓
LINK-EDIT
  ↓
TEST
  ↓
PACKAGE
  ↓
PROMOTION
  ↓
DEPLOY
  ↓
MONITOR

A distância diminuiu bastante.

O DevOps moderno não elimina COBOL.

Ele tenta automatizar e controlar o caminho percorrido pelo COBOL.

Essa distinção é fundamental.

---

🏠 CAPÍTULO 2 — SMURF CONSTRUTOR DESCOBRE O LINUX

O primeiro projeto apresenta um servidor Linux de produção.

Temos usuários, grupos, SSH, permissões, Nginx, systemd, firewall, logs e health checks.

O programador COBOL poderia pensar:

— Nada disso existe no meu mundo.

Existe — embora nem sempre da mesma forma.

Podemos fazer uma aproximação conceitual:

LINUX                    z/OS / USS
-----------------------------------------------
users/groups             RACF users/groups
permissions              RACF + POSIX permissions
SSH                      OpenSSH no USS
files                    zFS / USS files
services                  Started Tasks / services
logs                      SYSLOG/OPERLOG/app logs
health checking           monitoring/automation

E aqui aparece uma curiosidade maravilhosa.

O z/OS possui dentro dele um ambiente UNIX certificado segundo padrões POSIX: UNIX System Services — USS.

Portanto podemos ter no mesmo sistema:

MVS
│
├── JCL
├── datasets
├── JES2
├── TSO
├── ISPF
├── RACF
└── SDSF

USS
│
├── shell
├── directories
├── files
├── SSH
├── chmod
├── chown
└── aplicações UNIX

Para o programador COBOL moderno, conhecer USS é extremamente útil porque várias ferramentas modernas de desenvolvimento e integração passam por esse universo.

Papai Smurf escreveria na lousa:

Dataset não é simplesmente file, e USS não substitui MVS. São mundos que convivem.

---

🏰 CAPÍTULO 3 — O ATAQUE DE GARGAMEL E A ALTA DISPONIBILIDADE

Gargamel finalmente encontrou a aldeia.

Ele derrubou um servidor.

A aplicação continuou funcionando.

Gargamel ficou indignado.

Esse é o princípio por trás do segundo projeto: High Availability.

Na cloud encontramos conceitos como:

DNS
 ↓
Load Balancer
 ↓
Availability Zone A
     +
Availability Zone B
 ↓
Auto Scaling

O princípio é simples:

A falha de um componente individual não deveria necessariamente provocar a indisponibilidade de todo o serviço.

O IBM Z conhece essa conversa muito bem.

No universo mainframe encontramos tecnologias e arquiteturas envolvendo:

• Parallel Sysplex;

• Coupling Facility;

• XCF;

• WLM;

• CICSplex;

• Db2 Data Sharing;

• MQ;

• mecanismos de redundância;

• soluções de recuperação e continuidade como GDPS.

Não significa que uma Availability Zone seja "igual" a uma LPAR ou que Auto Scaling seja "igual" a WLM.

Esse tipo de equivalência seria tecnicamente perigoso.

Estamos comparando problemas arquitetônicos, não dizendo que as implementações são idênticas.

A pergunta correta é:

Se este componente morrer agora, o que acontece com o negócio?

Essa pergunta vale para AWS, Kubernetes, CICS, Db2 e praticamente qualquer arquitetura crítica.

---

🧱 CAPÍTULO 4 — SMURF CONSTRUTOR ENCONTRA O TERRAFORM

Terraform introduz Infrastructure as Code — IaC.

Em vez de alguém entrar em uma interface e configurar manualmente cinquenta coisas, descrevemos infraestrutura de maneira controlada.

A ideia geral é:

DEFINIÇÃO
    ↓
   GIT
    ↓
 REVIEW
    ↓
AUTOMAÇÃO
    ↓
INFRAESTRUTURA

Isso traz algo precioso:

reprodutibilidade.

Se o Smurf A configurou DEV de um jeito e o Smurf B configurou TEST de outro, eventualmente teremos:

DEV ≠ TEST ≠ PROD

E começará a clássica frase:

"Mas funcionou em desenvolvimento!"

Infrastructure as Code tenta diminuir essa diferença.

No universo IBM Z, o princípio pode aparecer por meio de automação, APIs, workflows, configuração versionada e ferramentas modernas que interagem com z/OS.

E cuidado com uma comparação sedutora:

JCL não é Terraform.

JCL descreve execução de jobs e recursos necessários ao processamento. Terraform trabalha com gerenciamento declarativo de infraestrutura.

Existe parentesco filosófico em alguns aspectos — automação, definição textual, repetibilidade — mas são tecnologias com objetivos diferentes.

---

🪄 CAPÍTULO 5 — PAPAI SMURF APRENDE ANSIBLE

Agora encontramos Configuration Management.

Ansible trabalha com conceitos como:

inventory
playbooks
roles
templates
variables
handlers
vault

Mas há uma palavra especialmente importante:

IDEMPOTÊNCIA.

Imagine que Papai Smurf ordene:

"Certifique-se de que a porta da aldeia esteja fechada."

Se estiver aberta:

FECHAR.

Se já estiver fechada:

NÃO FAZER NADA.

Ele não manda instalar outra porta em cima da primeira.

Isso é uma boa maneira de começar a entender idempotência.

Para administração de ambientes complexos, isso é ouro.

Em mainframe, pense em dezenas de configurações, datasets, membros, serviços e sistemas que precisam permanecer consistentes.

Automação não deveria significar simplesmente:

"Executar comandos rapidamente."

Automação madura significa:

levar o ambiente ao estado desejado de forma previsível, auditável e segura.

---

📦 CAPÍTULO 6 — SMURF EMPACOTADOR DESCOBRE DOCKER

Docker popularizou outra ideia poderosa:

empacotar aplicação e dependências em uma unidade reproduzível.

Mas aqui nosso programador COBOL precisa evitar um erro.

Um programa COBOL tradicional executando sob CICS no z/OS não vira automaticamente um container Docker.

O IBM Z pode hospedar mundos diferentes:

IBM Z
│
├── z/OS
│   ├── COBOL
│   ├── CICS
│   ├── IMS
│   ├── Db2
│   ├── MQ
│   └── USS
│
└── Linux on IBM Z
    ├── containers
    ├── Kubernetes
    └── OpenShift

E esses mundos podem conversar.

Por exemplo:

Aplicação containerizada
        ↓
      API
        ↓
  z/OS Connect
        ↓
      CICS
        ↓
      COBOL
        ↓
      Db2

Essa arquitetura é extremamente importante para compreender modernização.

Modernizar não significa obrigatoriamente reescrever milhões de linhas COBOL.

Às vezes significa construir novas interfaces ao redor de ativos confiáveis.

---

📚 CAPÍTULO 7 — A BIBLIOTECA DE POÇÕES IMUTÁVEIS

O projeto seguinte apresenta um private container registry.

A cadeia é aproximadamente:

SOURCE
 ↓
BUILD
 ↓
SCAN
 ↓
VERSION
 ↓
PUBLISH
 ↓
DEPLOY

O conceito que interessa ao mainframe é controle de artefatos.

Imagine dois Smurfs.

Smurf A compila uma versão às 14:00.

Smurf B recompila "a mesma versão" às 17:00 com uma copybook diferente.

São realmente o mesmo executável?

Talvez não.

Daí a importância de saber:

• qual source foi utilizado;

• quais dependências;

• qual compilador;

• quais opções;

• quais testes;

• qual artefato;

• qual versão;

• quem aprovou;

• quando foi promovido.

Esse é DevOps aplicado ao legado de maneira séria.

---

🔨 CAPÍTULO 8 — A ESTEIRA MÁGICA DO CI

Chegamos a Continuous Integration.

Imagine:

git push
   ↓
dependency analysis
   ↓
compile
   ↓
link
   ↓
unit tests
   ↓
static analysis
   ↓
security checks
   ↓
artifact

No mundo COBOL moderno podemos ter Git, ferramentas de build baseado em dependências, testes automatizados e pipelines.

O programador deixa de pensar:

"Compilei meu programa."

E começa a pensar:

"Minha mudança passou por uma cadeia reproduzível de validações."

É uma mudança gigantesca.

O herói não é mais o Smurf que sabe de memória quais 17 jobs precisam ser executados.

O objetivo é que esse conhecimento esteja codificado na esteira.

---

🚂 CAPÍTULO 9 — JENKINS, O MAQUINISTA

Jenkins aparece como orquestrador.

Ele pode receber um evento do Git e iniciar uma cadeia:

COMMIT
   ↓
JENKINS
   ↓
BUILD
   ↓
TEST
   ↓
SCAN
   ↓
PACKAGE
   ↓
DEPLOY

Jenkins não precisa compreender sozinho toda a semântica do COBOL.

Ele coordena ferramentas que realizam as diferentes tarefas.

Pense nele como o Papai Smurf da fábrica:

"Smurf Compilador, faça sua parte."

"Smurf Testador, agora você."

"Smurf Segurança, verifique isso."

"Smurf Deployment, somente prossiga se todos aprovarem."

E temos Pipeline as Code.

A própria receita da fábrica passa a ser versionada.

---

🚢 CAPÍTULO 10 — KUBERNETES NÃO VEIO MATAR O MAINFRAME

Agora aparece Kubernetes.

É tentador cair na discussão:

KUBERNETES
    VS
MAINFRAME

Essa comparação frequentemente começa errada.

Uma arquitetura empresarial pode utilizar ambos:

Mobile
   ↓
Internet
   ↓
API Gateway
   ↓
Kubernetes/OpenShift
   ↓
Microservices
   ↓
z/OS Connect / MQ
   ↓
CICS
   ↓
COBOL
   ↓
Db2

O mainframe pode continuar sendo o system of record, enquanto containers implementam novas experiências, serviços e integrações.

O COBOLista não precisa necessariamente transformar-se no maior especialista Kubernetes da empresa.

Mas precisa saber conversar com quem trabalha desse lado da arquitetura.

---

🔐 CAPÍTULO 11 — SMURF SEGURANÇA ENCONTRA TLS E SECRETS

Quando começamos a conectar sistemas, aparecem perguntas sérias:

Quem é você?
O que você pode fazer?
Quem autorizou?
A comunicação está criptografada?
Onde está a credencial?
Quem pode lê-la?
Quando ela expira?
Como é rotacionada?

Isso nos leva a TLS, certificados, IAM, secrets e RACF.

Uma das piores ideias possíveis seria:

MOVE 'USER01'   TO WS-USER.
MOVE 'SENHA123' TO WS-PASSWORD.

E ainda assim arqueologia de sistemas encontra coisas parecidas.

Credenciais não deveriam ficar hardcoded em source code.

O mundo moderno trabalha cada vez mais com identidades de workload, roles, secrets managers, certificados e rotação automática.

No mainframe, RACF participa de uma filosofia muito mais ampla:

IDENTIDADE
    ↓
AUTENTICAÇÃO
    ↓
AUTORIZAÇÃO
    ↓
RECURSO
    ↓
AUDITORIA

E Papai Smurf deixa uma frase no quadro:

Autenticar alguém não significa autorizar tudo.

---

🐙 CAPÍTULO 12 — GITOPS E A RECEITA OFICIAL DA POÇÃO

Argo CD introduz GitOps.

O Git passa a representar o estado desejado.

Simplificando:

GIT
 │
 │ desired state
 ▼
ARGO CD
 │
 ▼
KUBERNETES

Agora imagine que Smurf Curioso entre diretamente em produção e altere alguma coisa.

Temos:

GIT        PRODUÇÃO
 A             B

       ≠

Isso é drift.

A diferença entre o estado declarado e o estado real.

Esse conceito é interessantíssimo para ambientes mainframe.

Quantas vezes sistemas antigos carregam configurações cujo motivo ninguém mais conhece?

"Não mexe nesse parâmetro."

— Por quê?

"Porque em 2004 tentaram e deu problema."

— Onde está documentado?

"O Geraldo sabia."

— Onde está o Geraldo?

"Aposentou em 2017."

Esse é o tipo de conhecimento tribal que automação, versionamento e documentação procuram combater.

---

🔵🟢 CAPÍTULO 13 — BLUE/GREEN NA ALDEIA AZUL

Temos três estratégias famosas:

ROLLING
BLUE/GREEN
CANARY

Rolling

Substituímos gradualmente componentes antigos pelos novos.

Blue/Green

Mantemos dois ambientes ou conjuntos equivalentes:

BLUE = atual

GREEN = novo

Testamos GREEN e mudamos o tráfego.

Se houver problema, voltamos.

Canary

Uma pequena porcentagem recebe a nova versão:

90% → V1
10% → V2

Observamos.

Se estiver saudável:

70/30
50/50
0/100

O conceito fundamental não é copiar literalmente isso para cada workload mainframe.

É aprender:

deployment não precisa significar apostar toda a produção em uma única mudança instantânea.

Ambientes CICS, arquiteturas paralelas, roteamento e mecanismos operacionais podem permitir estratégias controladas de atualização.

---

👀 CAPÍTULO 14 — "DEPLOY SUCCESSFUL" NÃO SIGNIFICA "TUDO CERTO"

Esta talvez seja uma das maiores lições de toda a coleção.

O pipeline diz:

DEPLOY SUCCESSFUL

Smurf Feliz comemora.

Papai Smurf pergunta:

"E a aplicação?"

Silêncio.

Uma implantação tecnicamente concluída não garante que o negócio esteja saudável.

Imagine:

COBOL compilou     ✓
link-edit          ✓
deploy             ✓
CICS               ✓

Mas:

tempo resposta     8 segundos
fila MQ            crescendo
Db2 locks          aumentando
erros negócio      crescendo
clientes           reclamando

O deployment funcionou.

O sistema não.

Por isso precisamos de verificação pós-deploy.

---

🔭 CAPÍTULO 15 — SMURF ÓCULOS INVENTA A OBSERVABILIDADE

Chegamos a uma das partes mais importantes:

METRICS
   +
LOGS
   +
TRACES

Monitoramento responde muito bem:

"Esta métrica ultrapassou o limite?"

Observabilidade tenta ajudar a responder perguntas que talvez nem tivéssemos previsto antes do incidente.

O mainframe possui uma riqueza extraordinária de telemetria:

SMF
RMF
WLM
CICS statistics
CICS monitoring
Db2 accounting/statistics
IMS
MQ
SYSLOG
OPERLOG
logs de aplicação
network telemetry

O problema moderno é correlacionar tudo.

Imagine:

Cliente
  ↓
Mobile
  ↓
API
  ↓
OpenShift
  ↓
MQ
  ↓
CICS
  ↓
COBOL
  ↓
Db2

Cliente reclama:

"Está lento."

CPU:

43%

Tudo verde.

Smurf Ranzinza olha para o dashboard:

"Eu odeio dashboards verdes."

E ele está certo em desconfiar.

Precisamos investigar:

latência da API
       ↓
tempo na fila
       ↓
tempo CICS
       ↓
tempo COBOL
       ↓
tempo Db2
       ↓
lock/wait
       ↓
resposta

Agora estamos fazendo observabilidade de verdade.

---

💥 CAPÍTULO 16 — GARGAMEL FAILURE LAB

Uma das melhores ideias do material analisado é colocar falhas intencionais nos exercícios.

Isso deveria ser obrigatório em treinamento mainframe.

Não ensine apenas:

"Aqui está um comando."

Ensine:

"O sistema quebrou. Descubra por quê."

Laboratório:

CENÁRIO 01

JOB
RC=0000

MAS...

resultado financeiro incorreto.

O iniciante aprende imediatamente:

RC=0000 não significa resultado de negócio correto.

Segundo cenário:

MQ QUEUE DEPTH
10
20
80
300
900
4000

Por quê?

Consumidor parado?

Problema de conexão?

Transação CICS degradada?

Db2 esperando lock?

Terceiro:

CICS RESPONSE TIME

0.2s
0.2s
0.3s
0.4s
4.8s
8.1s

CPU continua normal.

Agora o aluno precisa investigar.

Esse é treinamento para produção.

---

🧪 CAPÍTULO 17 — O MÉTODO PAPAI SMURF DE INVESTIGAÇÃO

Nunca comece mudando coisas aleatoriamente.

Use:

SINTOMA
   ↓
ESCOPO
   ↓
TIMELINE
   ↓
TELEMETRIA
   ↓
HIPÓTESE
   ↓
EVIDÊNCIA
   ↓
ROOT CAUSE
   ↓
CORREÇÃO
   ↓
VALIDAÇÃO
   ↓
DOCUMENTAÇÃO

Exemplo:

Sintoma: transações lentas.

Pergunte:

Quando começou?

03:17

Curioso horário. ☕

O que mudou antes?

Deploy às 03:10.

Todas as transações?

Não.

Somente PAYM.

Qual programa?

PAYM001.

Existe Db2?

Sim.

SQL mudou?

Sim.

Pronto.

Já reduzimos dramaticamente o universo da investigação.

Esse é o raciocínio que transforma operador de comandos em engenheiro.

---

🧠 CAPÍTULO 18 — O QUE UM COBOLista PRECISA APRENDER EM 2026

Não abandone COBOL.

Expanda o mapa.

Uma formação moderna pode evoluir assim:

COBOL
 │
 ├── JCL
 ├── VSAM
 ├── Db2
 ├── CICS
 ├── IMS
 └── MQ
      │
      ▼
     Git
      │
      ▼
    CI/CD
      │
      ├── Build
      ├── Tests
      ├── Security
      ├── Package
      └── Deploy
             │
             ▼
       Observability
             │
             ▼
       Incident Response

Depois acrescente:

USS
Linux
APIs
JSON
YAML
Docker
Kubernetes
OpenShift
Cloud
Terraform
Ansible

Não porque todos os programadores COBOL precisarão administrar Kubernetes.

Mas porque aplicações empresariais não vivem isoladas.

---

🗺️ CAPÍTULO 19 — PASSO A PASSO PARA O PADAWAN AZUL

Se eu fosse orientar um iniciante, não começaria jogando Kubernetes na cabeça dele.

Começaria por COBOL + ambiente.

Aprenda programa, compile/link, datasets, JCL, JES, SDSF, VSAM, Db2 e fundamentos CICS.

Depois aprenda Git.

Entenda:

repository
commit
branch
merge
pull request
tag

Então automatize o build.

Depois acrescente testes.

Depois quality gates.

Depois packaging.

Depois deployment.

Depois rollback.

Só então conecte isso a observabilidade.

Finalmente, provoque falhas controladas.

A sequência pedagógica seria:

1. FAÇA FUNCIONAR
        ↓
2. FAÇA REPETÍVEL
        ↓
3. FAÇA AUTOMÁTICO
        ↓
4. FAÇA TESTÁVEL
        ↓
5. FAÇA SEGURO
        ↓
6. FAÇA OBSERVÁVEL
        ↓
7. QUEBRE
        ↓
8. DESCUBRA POR QUÊ
        ↓
9. RECUPERE
        ↓
10. APRENDA

Isso produz alguém muito mais preparado para produção.

---

🎓 CAPÍTULO 20 — OS 20 PROJETOS BELLACOSA MAINFRAME

Se Papai Smurf transformasse aquela trilha em laboratório IBM Z, eu imaginaria projetos como:

#	Projeto
01	USS/Linux fundamentals para COBOLista
02	RACF, usuários e least privilege
03	Git para COBOL
04	Build automatizado COBOL
05	Dependency Based Build
06	Automated Testing
07	Static Analysis e Quality Gates
08	Pipeline CI
09	Jenkins + IBM Z
10	Pipeline CI/CD
11	Package e promoção DEV→TEST→PROD
12	APIs com z/OS Connect
13	Integração assíncrona com MQ
14	Linux on Z + containers
15	OpenShift + aplicações z/OS
16	Secrets e segurança
17	SMF/RMF/WLM observability
18	CICS/Db2/MQ troubleshooting
19	Resiliência, Sysplex e recuperação
20	War Room — incidente completo

O último projeto começaria assim:

03:17:00

ALERTA:

CLIENTES NÃO CONSEGUEM
FINALIZAR PAGAMENTOS.

Você receberia apenas:

CICS aparentemente UP.
Db2 aparentemente UP.
MQ aparentemente UP.
CPU normal.
Deploy ocorreu sete minutos antes.

Boa sorte.

Agora investigue.

Isso seria muito mais educativo do que uma prova perguntando:

"Qual opção abaixo define observabilidade?"

---

🥚 EASTER EGG — POR QUE 03:17?

O programador atento provavelmente percebeu o horário aparecendo novamente.

03:17 é aquele horário imaginário em que toda arquitetura deixa de ser PowerPoint.

Às 14:00 alguém diz:

"Temos alta disponibilidade."

Às 03:17:

"Desligue aquele componente e prove."

Às 14:00:

"Temos observabilidade."

Às 03:17:

"Então explique por que o cliente está esperando oito segundos."

Às 14:00:

"Temos rollback."

Às 03:17:

"Ótimo. Faça."

Esse é o Easter Egg escondido dentro da aldeia.

---

☕ EPÍLOGO — PAPAI SMURF DESLIGA O PROJETOR

Depois de estudar Terraform, Ansible, Docker, registries, CI, CI/CD, Jenkins, Kubernetes, EKS, TLS, GitOps, deployment strategies, secrets e observabilidade, o jovem Smurf perguntou:

— Papai Smurf, então o mainframe estava ultrapassado?

O velho administrador sorriu.

— Não.

— Então todo esse DevOps é apenas coisa que o mainframe já fazia?

Papai Smurf também respondeu:

— Não.

E essa é precisamente a resposta importante.

O mainframe possui décadas de engenharia extraordinária em processamento transacional, segurança, workload management, disponibilidade, telemetria, recuperação e operação crítica.

O ecossistema DevOps moderno trouxe práticas extremamente poderosas em versionamento distribuído, automação, Pipeline as Code, Infrastructure as Code, testes contínuos, GitOps, containers, security scanning e entrega automatizada.

Não precisamos escolher um lado.

Precisamos juntar os conhecimentos.

            COBOL
              +
             GIT
              +
            CI/CD
              +
          AUTOMATION
              +
           SECURITY
              +
       OBSERVABILITY
              +
          RESILIENCE
              ↓

      MODERN IBM Z ENGINEERING

O programador COBOL iniciante que entender isso deixa de enxergar apenas:

IDENTIFICATION DIVISION.
PROGRAM-ID. SMURF001.

Ele começa a enxergar todo o sistema ao redor daquele programa:

Quem solicitou a mudança?
        ↓
Qual commit?
        ↓
Qual build?
        ↓
Quais dependências?
        ↓
Quais testes?
        ↓
Qual artefato?
        ↓
Quem aprovou?
        ↓
Como foi implantado?
        ↓
Como sabemos que funcionou?
        ↓
Como observamos?
        ↓
Como detectamos regressão?
        ↓
Como fazemos rollback?
        ↓
Como descobrimos a causa?

Essa é a verdadeira transformação.

Não é trocar COBOL por YAML.

Não é substituir CICS por Kubernetes.

Não é colocar Docker em tudo.

Não é migrar tudo para cloud porque alguém desenhou uma nuvem bonita no PowerPoint.

É transformar conhecimento tribal em processo, processo em automação, automação em evidência, evidência em observabilidade e observabilidade em capacidade de entender e recuperar sistemas reais.

No fim da aula, Smurf Ranzinza levantou a mão:

— Papai Smurf?

— Sim?

— Ainda odeio deploy de sexta-feira.

Papai Smurf tomou o último gole do café.

— Excelente. Algumas boas práticas sobrevivem a qualquer modernização.

E em algum lugar daquela pequena aldeia azul, escondida dentro de uma LPAR, o relógio marcou:

03:17

O dashboard estava completamente verde.

Então o telefone tocou.

Fim?

Não.

Início do War Room. ☕🔵🖥️