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

Translate

quinta-feira, 5 de janeiro de 2023

Goblin Slayer — Parte I Quando um Programador COBOL Descobre que o Verdadeiro Herói Nunca Salvou o Mundo... Apenas Impediu que Ele Desmoronasse Todos os Dias

 

Bellacosa Mainframe apresenta Goblin Slayer parte I

☕ Um Café no Bellacosa Mainframe

Goblin Slayer sem Mistérios — Parte I

Quando um Programador COBOL Descobre que o Verdadeiro Herói Nunca Salvou o Mundo... Apenas Impediu que Ele Desmoronasse Todos os Dias

"Os grandes bardos cantam sobre quem derrotou o Rei Demônio. Poucos escrevem uma única linha sobre o homem que impediu milhares de aldeias de desaparecerem antes mesmo que o Rei Demônio soubesse da existência delas."




Introdução — A Fantasia que Recusou Ser Fantástica

Existe um momento curioso na vida de praticamente todo fã de fantasia.

Você começa assistindo histórias onde os heróis recebem espadas mágicas.

Depois aparecem armaduras lendárias.

Magias proibidas.

Dragões ancestrais.

Profecias.

Reencarnações.

Escolhidos pelos deuses.

Reis demônios.

E então, depois de centenas de obras, você percebe que todas contam praticamente a mesma história.

Foi exatamente nesse cenário que surgiu uma pequena obra escrita por um autor praticamente desconhecido.

Sem protagonistas overpower.

Sem harém.

Sem protagonista reencarnado.

Sem sistema de níveis absurdos.

Sem "eu derrotei um deus no episódio 12".

Apenas um homem.

Uma espada.

Uma armadura velha.

Um escudo.

Um capacete que nunca revela seu rosto.

E uma única missão.

Matar goblins.

A maioria das pessoas olhou para isso e pensou:

"É só isso?"

A resposta era:

Não. Era exatamente o contrário.

Goblin Slayer nunca foi uma história sobre goblins.

Era uma história sobre pessoas.

Sobre trauma.

Sobre responsabilidade.

Sobre trabalho invisível.

Sobre o preço de continuar vivendo.

E talvez seja justamente por isso que tantos profissionais experientes — médicos, bombeiros, militares, policiais, engenheiros, administradores de sistemas e até programadores COBOL — enxergam muito mais nessa obra do que simples batalhas medievais.

Porque eles sabem uma verdade incômoda.

O mundo não continua funcionando graças aos heróis.

Continua funcionando graças às pessoas que fazem, silenciosamente, o trabalho que ninguém quer fazer.


Bellacosa Mainframe apresenta GOBLIN SLAYER

Um Café no Bellacosa Mainframe

Imagine a cena.

Você acabou de terminar um batch gigantesco às três da manhã.

O processamento fechou.

Nenhum ABEND.

Nenhum S0C7.

Nenhum banco ficou indisponível.

O jornal do dia seguinte não falará de você.

O presidente do banco jamais saberá seu nome.

Os clientes jamais imaginarão que centenas de milhões de transações dependeram do seu trabalho.

Porque tudo funcionou.

Agora imagine outro profissional.

Ele entra numa caverna.

Mata vinte goblins.

Salva uma aldeia inteira.

Ninguém escreve uma música sobre isso.

Ninguém ergue uma estátua.

A Guilda apenas responde:

— "Obrigado. Próxima missão."

Essa é exatamente a vida de Goblin Slayer.

E talvez por isso tantos profissionais adultos tenham se identificado imediatamente com ele.


Bellacosa Mainframe apresenta o matador de goblins GOBLIN SLAYER

Antes de Goblin Slayer

Para compreender o impacto dessa obra precisamos voltar algumas décadas.

Muito antes de isekais.

Muito antes de MMORPGs.

Muito antes de Sword Art Online.

Muito antes de Overlord.

Muito antes de Mushoku Tensei.

Na década de 1970 acontecia algo revolucionário.

Nos Estados Unidos, Gary Gygax e Dave Arneson criavam um jogo chamado:

Dungeons & Dragons (1974).

Pela primeira vez, fantasia deixava de ser apenas literatura.

Ela passava a ser vivida.

Os jogadores criavam:

  • guerreiros

  • magos

  • sacerdotes

  • ladrões

  • elfos

  • anões

Entravam em masmorras.

Recebiam missões.

Exploravam cavernas.

Rolavam dados.

Morriam.

Criavam novos personagens.

Esse conceito atravessaria o oceano.


A chegada ao Japão

Nos anos 1980, o Japão apaixonou-se por RPG de mesa.

Surgiram adaptações locais.

Entre elas:

  • Sword World RPG (1989)

  • Lodoss

  • RuneQuest traduzido

  • Advanced Dungeons & Dragons

Foi nesse ambiente que cresceu uma geração inteira de escritores.

Eles aprenderam algo interessante.

Nas campanhas de RPG, os personagens raramente eram chamados pelo nome.

Eram chamados por suas classes.

"O Guerreiro."

"A Sacerdotisa."

"O Anão."

"O Mago."

Anos depois...

Goblin Slayer faria exatamente isso.

Observe.

Quase ninguém possui nome verdadeiro.

Temos:

  • Goblin Slayer

  • Priestess

  • High Elf Archer

  • Dwarf Shaman

  • Lizard Priest

  • Guild Girl

  • Cow Girl

  • Sword Maiden

Isso não é coincidência.

É uma homenagem direta às mesas de RPG.


Quem é Kumo Kagyu?

Curiosamente...

Sabemos muito pouco sobre ele.

Kumo Kagyu prefere permanecer longe dos holofotes.

Não existe uma biografia gigantesca.

Não há entrevistas semanais.

Não há exposição constante.

Isso acabou aumentando ainda mais o mistério em torno do autor.

Sabe-se, entretanto, que ele sempre foi apaixonado por RPGs de mesa.

E isso aparece em praticamente todas as páginas da obra.

Os deuses lançando dados.

As classes.

As missões.

As guildas.

As recompensas.

As aventuras.

As dungeons.

Tudo parece uma campanha conduzida por um excelente Mestre de Jogo.


A origem da obra

A cronologia da franquia é fascinante.

Tudo começou de maneira extremamente modesta.

2013–2015

Kumo Kagyu publica Goblin Slayer como Web Novel.

Na época, dezenas de autores japoneses utilizavam plataformas online para testar histórias antes de buscar uma editora.

Foi exatamente assim que nasceram também obras como:

  • Overlord

  • Mushoku Tensei

  • Re:Zero

  • The Rising of the Shield Hero

O mercado editorial japonês começava a perceber algo importante.

A internet havia se tornado o novo laboratório para descobrir talentos.


15 de fevereiro de 2016

Surge oficialmente a primeira Light Novel de Goblin Slayer.

Ilustrada por Noboru Kannatsuki, a obra chega às livrarias japonesas.

Ninguém imaginava que aquele pequeno livro se transformaria em uma das franquias mais debatidas da década.


Maio de 2016

O sucesso inicial leva rapidamente ao mangá.

Em 25 de maio de 2016, começa a serialização da adaptação ilustrada por Kōsuke Kurose.

Era o passo natural.

Mas havia um detalhe curioso.

Muitos leitores que não tinham lido a novel ficaram chocados.

O mangá era muito mais pesado do que imaginavam.

A violência não era gratuita.

Ela tinha função narrativa.


O crescimento silencioso

Enquanto outros títulos explodiam em vendas graças ao humor ou ao fan service, Goblin Slayer crescia de maneira diferente.

Cada novo leitor indicava para outro.

As discussões apareciam em fóruns.

Os vídeos no YouTube aumentavam.

As análises multiplicavam-se.

Era um sucesso construído quase artesanalmente.

Sem campanhas milionárias.

Sem marketing agressivo.

Apenas pelo boca a boca.


2017 — O Passado do Caçador

Em 15 de setembro de 2017, surge Goblin Slayer: Year One.

Para muitos fãs, trata-se da melhor obra paralela de toda a franquia.

Ali descobrimos algo que o anime apenas sugere.

Goblin Slayer não nasceu um especialista.

Ele errou.

Fracassou.

Foi derrotado.

Aprendeu.

Improvisou.

Sobreviveu.

Cada cicatriz possui uma história.

Cada equipamento possui um motivo.

Cada decisão foi construída lentamente.

É quase como assistir ao treinamento de Bruce Wayne antes de se tornar Batman.


A explosão de 2018

O ano de 2018 muda completamente a história da franquia.

Primeiro surge Year One em formato de Light Novel.

Depois aparece Brand New Day, mostrando aventuras paralelas e momentos cotidianos da Guilda.

E então chega outubro.


7 de outubro de 2018

Estreia o anime produzido pelo estúdio White Fox.

Doze episódios.

Uma abertura memorável.

Uma trilha sonora excelente.

Uma direção extremamente competente.

Mas ninguém imaginava o que aconteceria nas primeiras horas após sua exibição.


O episódio que abalou a internet

O primeiro episódio tornou-se imediatamente um dos mais comentados da história recente dos animes.

Redes sociais explodiram.

Fóruns entraram em guerra.

Críticos dividiram-se completamente.

Uns afirmavam:

"Isso passou dos limites."

Outros respondiam:

"Finalmente alguém mostrou que monstros realmente são monstros."

Independentemente da opinião, uma coisa tornou-se inegável.

Todo mundo passou a falar sobre Goblin Slayer.

O anime havia conseguido algo raríssimo.

Ser impossível de ignorar.


A desconstrução do goblin

Durante décadas, os goblins ocuparam um papel quase cômico na fantasia.

Em muitos jogos eles eram o equivalente ao "inimigo de tutorial".

Criaturas pequenas.

Desorganizadas.

Fracas.

Quase descartáveis.

Goblin Slayer destrói completamente essa ideia.

Aqui, goblins não são apenas monstros.

São uma ameaça biológica, militar e psicológica.

Eles observam.

Aprendem.

Adaptam-se.

Criam armadilhas.

Atacam onde há menos defesa.

Exploram o medo.

Usam táticas de guerrilha.

Jamais enfrentam um exército quando podem eliminar uma aldeia isolada.

A pergunta muda completamente.

Não é mais:

"Quantos goblins existem?"

Mas sim:

"Quantos sobreviveram para aprender com a última batalha?"


O mundo além do Rei Demônio

Outro aspecto brilhante da obra é aquilo que ela escolhe não mostrar.

Existe um Rei Demônio.

Existem heróis lendários.

Existem batalhas épicas acontecendo em algum lugar.

Mas Goblin Slayer quase nunca participa delas.

Por quê?

Porque Kumo Kagyu inverteu a câmera.

Enquanto quase toda fantasia acompanha o general, Goblin Slayer acompanha o soldado.

Enquanto todos observam a guerra, ele observa a patrulha.

Enquanto os bardos cantam a vitória dos grandes heróis, ele entra em uma caverna escura para impedir que uma pequena tragédia aconteça.

Essa mudança de foco transforma completamente a experiência do leitor.


O primeiro grande ensinamento

Talvez a maior lição da primeira fase de Goblin Slayer seja incrivelmente simples.

Nunca despreze um problema apenas porque ele parece pequeno.

Goblin Slayer sabe que uma única tribo ignorada hoje pode transformar-se em centenas de goblins amanhã.

Esse princípio vale para quase tudo.

Na segurança da informação, uma senha esquecida.

Na medicina, um sintoma aparentemente banal.

Na engenharia, uma pequena fissura.

No mundo do mainframe, um warning ignorado durante semanas.

Os grandes desastres raramente começam grandes.

Eles começam pequenos.

Muito pequenos.

Pequenos o suficiente para que alguém diga:

"Depois eu vejo isso."

Goblin Slayer jamais diria essa frase.

E talvez seja exatamente essa mentalidade que o aproxima tanto de um bom administrador de sistemas ou de um programador COBOL experiente: ambos entendem que a estabilidade do mundo depende de resolver problemas aparentemente insignificantes antes que eles se transformem em catástrofes.


Continuação...

Na Parte II, entraremos no coração da obra: analisaremos Goblin Slayer como personagem, seu trauma, a psicologia por trás de sua obsessão, a construção dos companheiros de aventura, a filosofia do dever, a moral da história e por que esse "caçador de goblins" acabou se tornando um dos protagonistas mais humanos e memoráveis da fantasia japonesa contemporânea.

Um Café no Bellacosa Mainframe

ARQUIVOS DA GUILDA • CLASSIFICAÇÃO: DARK FANTASY

Goblin Slayer sem Mistérios

O Guia Definitivo da Série Completa

Uma jornada por cronologia, psicologia, biologia, estratégia, engenharia militar, referências culturais, simbolismos e os segredos escondidos de Goblin Slayer.

“Quando um Programador COBOL Descobre que Grandes Obras Também Precisam de um Mapa para Não se Perder na Dungeon.”
Explorar a série
RELATÓRIO DE MISSÃO

Uma série construída como uma campanha de RPG

Goblin Slayer sem Mistérios é uma coleção especial do Bellacosa Mainframe dedicada à análise profunda da obra criada por Kumo Kagyu. Cada capítulo investiga uma camada diferente da franquia, relacionando fantasia sombria, RPG de mesa, estratégia, trauma, sobrevivência, engenharia militar e arquitetura de sistemas.

A coleção foi organizada em ordem cronológica para facilitar a leitura. Você pode começar pela Parte I, seguir capítulo após capítulo ou utilizar os filtros para selecionar assuntos como psicologia, goblins, táticas, história da franquia e cultura otaku.

Todos os títulos abaixo são links HTML reais e permanecem acessíveis mesmo quando o JavaScript estiver desativado. Isso facilita a navegação dos leitores e a descoberta das páginas por mecanismos de busca.

Progresso da campanha 0 de 14 missões visitadas
14 capítulos encontrados
I
Introdução

Goblin Slayer sem Mistérios — Parte I

O ponto de entrada da campanha. Uma análise sobre o herói invisível que não salva o mundo em uma única batalha, mas impede silenciosamente que ele desmorone todos os dias.

Heroísmo Disciplina Mainframe
II
Disciplina

Goblin Slayer sem Mistérios — Parte II

O verdadeiro poder não está na espada, mas na constância de levantar, preparar os equipamentos e executar diariamente o trabalho que quase ninguém deseja assumir.

Rotina Dever Persistência
III
Missão crítica

Goblin Slayer sem Mistérios — Parte III

Nem todo herói enfrenta o Rei Demônio. Alguns garantem que na segunda-feira existirão sistema, salários, luz e uma aldeia inteira ainda de pé.

Disponibilidade Proteção Responsabilidade
IV
Arquitetura

Parte IV — O Arquiteto Invisível de Goblin Slayer

Uma reflexão sobre profissionais que projetam soluções, previnem desastres e permanecem atrás do terminal enquanto o restante do mundo apenas percebe que tudo continua funcionando.

Arquitetura COBOL Prevenção
V
Cronologia

Parte V — A Evolução Cronológica Completa da Franquia

Da publicação original às light novels, mangás, adaptações, spin-offs, filme e temporadas do anime: a evolução de uma história que cresceu release após release.

Web Novel Light Novel Anime
VI
Biologia

Parte VI — A Biologia dos Goblins

Anatomia, comportamento, adaptação, hierarquia e ecologia dos goblins analisados como uma espécie invasora capaz de explorar brechas e evoluir rapidamente.

Ecologia Adaptação Worldbuilding
VII
Referências

Parte VII — As Referências Escondidas de Goblin Slayer

Conan, Berserk, Tolkien, Dungeons & Dragons, Sword World RPG, literatura fantástica, mitologia e cultura pop escondidos entre as linhas da obra de Kumo Kagyu.

RPG Literatura Cultura pop
VIII
Psicologia

Parte VIII — A Psicologia Profunda de Goblin Slayer

Trauma, hipervigilância, isolamento, necessidade de controle, resiliência e reconstrução emocional por meio das relações que lentamente devolvem humanidade ao protagonista.

Trauma Memória Resiliência
IX
Engenharia militar

Parte IX — A Engenharia Militar de Goblin Slayer

Reconhecimento, suprimentos, redundância, controle do terreno, fortificação, retirada e arquitetura operacional transformam batalhas perigosas em vitórias planejadas.

Logística Terreno Contingência
X
Estratégia

Parte X — A Estratégia de Goblin Slayer

Uma análise sobre informação, iniciativa, especialização, probabilidades, redundância e a capacidade de pensar diversos movimentos à frente do adversário.

Planejamento Inteligência Antecipação
XI
100 segredos

Parte XI — Os 100 Segredos de Goblin Slayer

Cem detalhes sobre personagens, mundo, goblins, equipamentos, narrativa, simbolismos, RPG, produção, psicologia e estratégia que podem passar despercebidos até pelos fãs.

Easter eggs Simbolismos Curiosidades
XII
Guia completo

Parte XII — Goblin Slayer sem Mistérios

O mapa da campanha: introdução, sequência recomendada, resumo dos capítulos e orientação para explorar todas as camadas da coleção sem se perder na dungeon.

Índice Mapa Ordem de leitura
FINAL
Síntese definitiva

Por Que Goblin Slayer É uma das Melhores Obras de Dark Fantasy

A conclusão da jornada, reunindo cronologia, psicologia, estratégia, engenharia militar, simbolismos, referências culturais, construção de mundo e impacto na cultura otaku.

Dark Fantasy Síntese Conclusão
BÔNUS
Dossiê militar

A Composição do Exército Goblin em The Fate of an Adventurer

Rei Goblin, estado-maior, Champions, Shamans, arqueiros, infantaria, Riders, logística e cadeia de comando analisados como componentes de uma força militar organizada.

Exército Goblin Hierarquia Ordem de batalha
ROTA RECOMENDADA

Como percorrer esta dungeon

Comece pelas três primeiras partes para compreender a proposta da série. Depois visite o Arquiteto Invisível, conheça a evolução da franquia e aprofunde-se em biologia, referências, psicologia, engenharia militar e estratégia.

  1. 01 Fundamentos do herói invisível
  2. 02 História e evolução da franquia
  3. 03 Biologia e organização dos goblins
  4. 04 Psicologia e simbolismos
  5. 05 Engenharia militar e estratégia
  6. 06 Segredos, guia completo e síntese final
Bellacosa Mainframe Dark Fantasy • Anime • RPG • COBOL • Estratégia

“A vitória não é improviso. É arquitetura.”

quarta-feira, 4 de janeiro de 2023

Capítulo I — Vocabulário e Fundamentos da Cibersegurança

 


☕ Um Café no Bellacosa Mainframe

Capítulo I — Vocabulário e Fundamentos da Cibersegurança

Ou: o Agente 86 recebeu a missão de proteger o datacenter, entrou pela porta blindada usando o telefone-sapato — e descobriu que Igor havia publicado a senha do RACF em Base64 porque “agora ninguém consegue ler”



Prólogo — A porta secreta que não era tão secreta

— 86, temos uma emergência — disse o Chefe, fechando cuidadosamente as persianas do escritório.

— A KAOS invadiu o datacenter?

— Pior. Igor fez um curso de quinze páginas sobre cibersegurança e declarou o ambiente completamente protegido.

— Isso parece ótimo, Chefe.

— Ele instalou um firewall, colocou a senha em Base64 e desativou os logs para que os atacantes não soubessem o que estávamos fazendo.

— Ah. Nesse caso, estamos mortos.

Para quem começa em COBOL, cibersegurança às vezes parece um continente descoberto recentemente: cheio de siglas, especialistas vestidos de preto e diagramas onde uma caveira atravessa uma nuvem até alcançar um servidor. Mas o programador mainframe já vive dentro desse assunto há décadas, mesmo quando ninguém usava os nomes atuais.

Quando você protege um dataset com RACF, verifica um return code, impede que um programa atualize uma conta sem autorização, registra uma operação no SMF, faz COMMIT ou ROLLBACK, separa desenvolvimento de produção e limita o acesso de uma transação CICS, você está praticando segurança.

O problema começa quando confundimos ferramentas com segurança. Firewall não é segurança completa. Criptografia não é segurança completa. MFA não é segurança completa. Antivírus, WAF, SIEM, RACF e auditoria são componentes de um sistema maior.

Segurança é a capacidade de conhecer o que precisa ser protegido, reduzir a possibilidade de dano, detectar quando algo saiu do esperado, responder com disciplina e restaurar o serviço sem transformar o incidente num festival de improvisos.

Pegue seu café. O Agente 86 já está descendo para a sala de controle — infelizmente pelo elevador errado.



1. Cibersegurança não é apenas impedir hackers

Uma definição introdutória diz que cibersegurança é a prática de proteger sistemas, redes, programas e dados contra ataques, danos ou acessos não autorizados. Está correta, mas descreve apenas a fachada do prédio.

Na vida real, cibersegurança envolve pessoas, processos, tecnologia e decisões de negócio. Inclui:

  • descobrir quais ativos existem;

  • compreender quais deles são críticos;

  • identificar ameaças e vulnerabilidades;

  • administrar identidades e privilégios;

  • desenvolver software seguro;

  • monitorar o ambiente;

  • responder a incidentes;

  • recuperar dados e serviços;

  • atender leis e contratos;

  • preservar evidências;

  • aprender com cada falha.

O NIST Cybersecurity Framework 2.0 organiza essa jornada em seis funções: Governar, Identificar, Proteger, Detectar, Responder e Recuperar.

Repare no verbo “Governar”. Antes de comprar uma ferramenta, alguém precisa definir responsabilidades, apetite de risco, prioridades, recursos e critérios de decisão. Se um scanner encontra vinte mil vulnerabilidades e ninguém sabe quais sistemas processam folha de pagamento, cartão ou PIX, temos dados, mas não temos governo.

No IBM Z, isso pode ser traduzido assim:

  • Governar: definir proprietários, políticas, segregação de funções e risco aceitável.

  • Identificar: inventariar LPARs, aplicações, started tasks, usuários, datasets, filas MQ, APIs, certificados e dependências.

  • Proteger: usar RACF, criptografia, hardening, MFA, menor privilégio e programação segura.

  • Detectar: coletar SMF, logs de CICS, Db2, z/OSMF, USS, rede e ferramentas de segurança.

  • Responder: bloquear credenciais, conter o incidente, preservar evidências e comunicar responsáveis.

  • Recuperar: restaurar dados confiáveis, validar integridade e retomar os serviços na ordem correta.

As funções não formam uma fila de batch na qual uma só começa quando a anterior termina. Governar, identificar, proteger e detectar são atividades contínuas; resposta e recuperação precisam estar prontas antes do incidente.

Curiosidade de corredor: o melhor plano de resposta não é aquele que está num PDF de 180 páginas. É aquele que a equipe consegue encontrar e executar enquanto o telefone toca, o diretor pergunta quando o sistema volta e o Agente 86 está preso dentro da cabine telefônica.




2. A tríade CIA — o triângulo que sustenta o castelo

O primeiro mapa mental da segurança é a tríade CIA:

  • Confidentiality — Confidencialidade;

  • Integrity — Integridade;

  • Availability — Disponibilidade.

Não confunda CIA com a agência americana. O Agente 86 já confundiu e passou quarenta minutos tentando apresentar credenciais ao triângulo.

2.1 Confidencialidade

Confidencialidade significa que a informação só pode ser acessada por pessoas, sistemas ou processos autorizados.

Exemplos:

  • um cliente vê apenas suas próprias contas;

  • um operador acessa os comandos necessários, mas não toda a administração do sistema;

  • uma aplicação CICS lê somente os recursos indispensáveis;

  • uma cópia de produção usada em testes tem dados mascarados;

  • backups, dumps e logs recebem proteção equivalente à informação original.

Criptografia ajuda a preservar confidencialidade, mas não resolve tudo. Um banco de dados perfeitamente criptografado pode ser exposto por uma aplicação autenticada que execute SELECT * FROM CLIENTES e entregue o resultado ao usuário errado.

Confidencialidade depende também de autorização, classificação, minimização, mascaramento, segregação, descarte seguro e proteção das chaves.

2.2 Integridade

Integridade significa preservar correção, completude, consistência e origem confiável.

É comum imaginar um invasor alterando saldos, mas a integridade também pode ser perdida por:

  • erro de programação;

  • campo truncado;

  • processamento duplicado;

  • mensagem MQ consumida duas vezes;

  • restauração de backup antigo;

  • atualização parcial;

  • regra de negócio incorreta;

  • falha de sincronização.

Considere este trecho didático:

COMPUTE WS-NOVO-SALDO =
        WS-SALDO-ATUAL - WS-VALOR-TRANSFERENCIA

Se WS-VALOR-TRANSFERENCIA aceitar valor negativo, subtrair -100 adicionará 100 ao saldo. O programa compilou. O RACF autorizou. O banco estava disponível. Mesmo assim, a integridade foi destruída porque a regra de domínio não foi validada.

Integridade não significa apenas “o arquivo não mudou”. Significa que as mudanças foram corretas, completas, autorizadas e rastreáveis.

2.3 Disponibilidade

Disponibilidade é a capacidade de acessar informação e serviços quando a missão exige.

Não basta a tela responder ao PING. Se uma autorização de cartão leva três minutos, o serviço está tecnicamente vivo e operacionalmente morto.

Disponibilidade envolve:

  • redundância;

  • capacidade;

  • proteção contra DDoS;

  • manutenção;

  • monitoração;

  • backup;

  • recuperação de desastre;

  • tolerância a falhas;

  • operação degradada segura.

Duas siglas são fundamentais:

  • RTO: tempo máximo aceitável para restaurar o serviço;

  • RPO: quantidade máxima aceitável de dados perdidos, normalmente expressa em tempo.

Se o RTO é duas horas, não adianta descobrir durante o desastre que restaurar o ambiente exige nove. Se o RPO é zero, a arquitetura precisa tratar replicação e consistência de forma muito diferente daquela que admite perder uma hora.

2.4 O que existe além da CIA?

A tríade é a fundação, não o edifício inteiro. Também precisamos considerar:

  • autenticidade;

  • responsabilização;

  • rastreabilidade;

  • privacidade;

  • não repúdio;

  • resiliência;

  • segurança física;

  • segurança humana.

Uma assinatura digital pode ajudar a demonstrar origem e integridade, mas o não repúdio depende também de identidade verificada, custódia da chave, timestamp, auditoria e processo jurídico. Igor assinar um arquivo com uma chave privada encontrada num diretório público não cria prova celestial de autoria.



3. Ativo, ameaça, vulnerabilidade, exposição e risco

Essas palavras são frequentemente misturadas até virarem uma sopa de siglas. Vamos separá-las.

Ativo

É algo que possui valor: dinheiro, informação, sistema, reputação, credencial, certificado, serviço, conhecimento ou capacidade operacional.

Um job crítico, uma chave criptográfica e a confiança do cliente são ativos, embora não tenham a mesma forma.

Ameaça

É uma circunstância capaz de causar dano.

Pode ser:

  • criminoso;

  • funcionário mal-intencionado;

  • usuário enganado;

  • incêndio;

  • falha elétrica;

  • erro humano;

  • fornecedor comprometido;

  • ransomware;

  • bug destrutivo.

Ameaça não é sinônimo de hacker. Uma enchente não possui endereço IP e ainda assim pode derrubar o datacenter.

Vulnerabilidade

É uma fraqueza que pode ser explorada ou acionada:

  • SQL construído por concatenação;

  • senha reutilizada;

  • software desatualizado;

  • conta órfã;

  • porta administrativa exposta;

  • excesso de privilégios;

  • ausência de segregação de funções;

  • procedimento de recuperação nunca testado.

Exposição

É a condição que coloca o ativo ao alcance da ameaça. Um servidor vulnerável desligado e isolado possui vulnerabilidade, mas exposição pequena. O mesmo servidor publicado na Internet possui outro nível de risco.

Controle

É uma medida que reduz probabilidade ou impacto:

  • MFA;

  • firewall;

  • validação;

  • revisão de código;

  • limite transacional;

  • segmentação;

  • monitoração;

  • backup imutável.

Risco

Uma fórmula didática é:

Risco ≈ Probabilidade × Impacto

Mas risco não é uma multiplicação divina capaz de produzir a verdade com duas casas decimais. Precisamos avaliar valor do ativo, exposição, capacidade do adversário, controles existentes, detectabilidade, impacto operacional, jurídico e reputacional.

Uma vulnerabilidade CVSS 9.8 numa biblioteca não é automaticamente o maior risco da empresa. Pergunte:

  1. O componente vulnerável é realmente utilizado?

  2. Está exposto?

  3. Existe exploração conhecida?

  4. A exploração exige autenticação?

  5. Com qual privilégio o processo roda?

  6. Que dados podem ser alcançados?

  7. Existem controles compensatórios?

  8. Qual seria o impacto para o negócio?

Dica do Agente 86: nunca permita que um número substitua a investigação. O placar mostra onde olhar; não conta sozinho toda a história.



4. Malware — o zoológico dentro do telefone-sapato

Malware é software criado ou utilizado para executar ações maliciosas. As categorias ajudam a estudar, mas uma única amostra pode possuir várias capacidades.

Vírus

Anexa-se a arquivo ou programa e normalmente depende da execução para se espalhar. É o passageiro clandestino.

Worm

Propaga-se automaticamente por redes ou serviços. Se o vírus pede carona, o worm possui pernas e conhece os horários dos trens.

Trojan

Parece legítimo, mas carrega função maliciosa. “Trojan” descreve principalmente o disfarce ou forma de entrada, não todas as ações posteriores.

Ransomware

Bloqueia, criptografa ou destrói acesso e exige pagamento. Operações modernas podem combinar roubo de dados, ameaça de publicação, destruição de backup e pressão sobre clientes.

Restaurar o backup pode recuperar a disponibilidade, mas não devolve a confidencialidade dos dados já roubados.

Spyware e keylogger

Monitoram comportamento e coletam dados. Um keylogger pode capturar senhas, códigos, conversas e dados financeiros.

Rootkit

Oculta presença e ajuda a preservar acesso privilegiado. Atua na persistência e evasão.

Botnet

Botnet não é exatamente uma espécie isolada de malware; é uma rede de dispositivos comprometidos sob comando. Pode ser usada para DDoS, spam, fraude, mineração ou distribuição de novas cargas.

Insider threat

Também não é malware. Pode ser o funcionário malicioso, negligente, coagido, enganado, o ex-funcionário ainda habilitado ou uma conta legítima tomada por criminosos.

No mainframe, o invasor mais perigoso pode não precisar quebrar o RACF. Ele pode utilizar uma identidade autorizada para executar uma finalidade não autorizada.


5. Engenharia social — a vulnerabilidade usa crachá

Phishing não explora apenas ignorância. Explora características humanas normais:

  • autoridade;

  • urgência;

  • medo;

  • curiosidade;

  • escassez;

  • desejo de ajudar;

  • fadiga;

  • hábito.

As principais formas incluem phishing genérico, spear phishing direcionado, whaling contra executivos, smishing por SMS, vishing por voz, pretexting com história falsa, baiting por isca e quid pro quo por troca de favores.

Exemplo:

“Aqui é o suporte antifraude. Recebemos uma tentativa suspeita. Informe o código que acabou de chegar para bloquearmos a operação.”

O código é verdadeiro. O contexto é falso.

Treinamento é necessário, mas não pode ser a única barreira. O sistema deve supor que alguém eventualmente clicará. Use:

  • MFA resistente a phishing;

  • aprovação dupla;

  • limites transacionais;

  • filtragem de mensagens;

  • privilégio mínimo;

  • detecção comportamental;

  • confirmação fora de banda;

  • canal simples para denúncia.

Quando a organização culpa exclusivamente o usuário, ela transforma “defesa em profundidade” em “culpa em profundidade”.


6. O ataque não segue um fluxograma obediente

O modelo introdutório apresenta reconhecimento, varredura, exploração, manutenção de acesso e impacto. É útil, mas ataques reais voltam etapas, mudam de rota e frequentemente usam credenciais legítimas.

Uma campanha pode incluir:

  1. pesquisa sobre funcionários e fornecedores;

  2. criação de domínio parecido;

  3. phishing direcionado;

  4. roubo de sessão;

  5. acesso inicial;

  6. descoberta do ambiente;

  7. roubo de credenciais;

  8. escalada de privilégio;

  9. persistência;

  10. movimento lateral;

  11. coleta;

  12. exfiltração;

  13. impacto.

O ransomware que aparece no final pode ser apenas a sirene. O roubo silencioso aconteceu semanas antes.

Easter egg para os antigos: no Agente 86, as portas automáticas fechavam atrás do herói criando a ilusão de segurança perfeita. Na cibersegurança, isso se chama perímetro. O problema é descobrir quem já estava dentro antes de a última porta fechar.


7. Segurança de rede — a DMZ não é uma zona mágica

O desenho clássico é:

Internet → firewall → DMZ → firewall interno → aplicação → banco

É uma boa introdução à defesa em profundidade, mas uma arquitetura moderna pode conter CDN, proteção DDoS, WAF, API gateway, balanceador, serviços, filas, identidade, armazenamento, SIEM e serviços em nuvem.

Firewall

Controla fluxos conforme regras, mas não entende necessariamente fraude ou regra de negócio. Uma porta 443 permitida pode transportar um ataque perfeitamente protegido por TLS.

O cadeado garante que a conversa foi criptografada; não garante que um dos participantes seja honesto.

IDS e IPS

  • IDS detecta e alerta.

  • IPS pode intervir e bloquear.

Na prática, ferramentas podem combinar funções. Mais importante: alerta sem investigação é apenas uma mensagem de socorro guardada para auditoria.

Proxy, reverse proxy, WAF e gateway

“Proxy” é uma família:

  • forward proxy representa clientes;

  • reverse proxy representa servidores;

  • WAF analisa tráfego de aplicação web;

  • API gateway autentica, limita e roteia chamadas.

Nenhum deles corrige automaticamente código inseguro.

VPN

VPN protege o canal, não purifica o endpoint. Um notebook comprometido pode transformar a VPN numa ponte criptografada para o invasor.

Segmentação

Segmentação reduz movimento lateral e raio de explosão. VLAN sem política aplicada e monitorada é apenas organização de rede.

Pergunte a cada fluxo:

  • quem chama?

  • usando qual identidade?

  • por qual protocolo?

  • para qual finalidade?

  • com qual privilégio?

  • como será auditado?

  • o que acontece quando falha?


8. Identificação, autenticação, autorização e auditoria

Essas quatro etapas precisam ser separadas.

Identificação

“Sou o usuário MAXWELL86.”

Autenticação

“Consigo provar que sou MAXWELL86.”

Autorização

“MAXWELL86 pode executar esta ação neste recurso?”

Accountability

“Conseguimos reconstruir quem fez o quê, quando, de onde e com qual resultado?”

No RACF:

  • o USERID declara a identidade;

  • senha, certificado, PassTicket ou MFA ajudam a autenticar;

  • perfis, grupos e níveis de acesso determinam autorização;

  • SMF e outros registros fornecem evidências.

MFA

Os fatores clássicos são:

  • algo que você sabe;

  • algo que você possui;

  • algo que você é.

Senha mais PIN não é MFA verdadeiro: ambos são conhecimento. Senha mais pergunta secreta também não.

Códigos digitáveis acrescentam proteção, mas podem ser capturados por phishing. Para acessos sensíveis, mecanismos criptográficos resistentes a phishing são preferíveis.

Senhas

A velha receita “oito caracteres, maiúscula, número, símbolo e troca a cada 30 dias” produziu monstruosidades previsíveis como Agosto@2026!.

As diretrizes modernas favorecem:

  • comprimento;

  • blocklist de senhas comuns ou vazadas;

  • gerenciador de senhas;

  • ausência de trocas periódicas sem suspeita de comprometimento;

  • MFA;

  • proteção contra tentativas automatizadas.

Senhas não devem ser armazenadas em texto puro nem em SHA-256 simples. Aplicações usam funções próprias para derivação de senha, como Argon2id, com salt e parâmetros adequados.

Menor privilégio

Cada identidade recebe somente o necessário, durante o período necessário.

“Funciona com SPECIAL” não é solução; é confissão.


9. Criptografia, hashing e encoding — três ferramentas diferentes

Igor colocou a senha em Base64 e declarou:

— Pronto. Está criptografada.

O Chefe olhou para o Agente 86.

— Você quer contar ou eu conto?

Encoding

Encoding muda a representação para armazenamento ou transmissão. Base64, ASCII e UTF-8 não oferecem sigilo.

senha123 → c2VuaGExMjM=

Qualquer pessoa pode reverter essa representação.

Hashing

Hash transforma uma entrada em saída de tamanho definido e não utiliza chave. Serve para verificações de integridade, identificação de conteúdo e construções criptográficas.

Não existe operação de “descriptografar o hash”, mas entradas fracas podem ser descobertas por tentativa e comparação. Por isso, senha não deve ser guardada com hash rápido simples.

MD5 e SHA-1 não são escolhas adequadas para novas proteções criptográficas. SHA-256 e SHA-3 pertencem a famílias modernas, mas o algoritmo correto depende do uso.

Criptografia simétrica

Usa segredo compartilhado e é eficiente para grandes volumes. AES é a referência moderna, normalmente dentro de um modo autenticado adequado.

Criptografia assimétrica

Usa par de chaves pública e privada. É aplicada em assinatura, autenticação e estabelecimento de chaves.

Sistemas reais geralmente são híbridos:

  1. mecanismo assimétrico estabelece um segredo de sessão;

  2. mecanismo simétrico protege o volume de dados.

DES, 3DES e Blowfish aparecem em materiais antigos ao lado de AES, como se fossem opções equivalentes. Não são. DES está quebrado, 3DES é legado e Blowfish possui limitações para novos projetos.

Gestão de chaves

A criptografia é tão forte quanto a administração das chaves:

  • geração;

  • armazenamento;

  • distribuição;

  • rotação;

  • segregação;

  • revogação;

  • destruição;

  • recuperação controlada.

Uma chave AES gravada no fonte COBOL é apenas uma senha com autoestima elevada.

Assinatura digital

Ajuda a verificar origem e integridade, mas não fornece confidencialidade automaticamente. E não deve ser reduzida à frase “criptografar com a chave privada”; esquemas de assinatura possuem construções específicas.

Curiosidade: a migração pós-quântica já começou. Padrões como ML-KEM, ML-DSA e SLH-DSA existem para enfrentar futuros adversários com capacidade quântica. O trabalho atual não é apertar um botão, mas inventariar algoritmos, certificados, protocolos e dependências para construir agilidade criptográfica.


10. Segurança web — o navegador também executa o inimigo

Uma aplicação web pode ser atacada em qualquer camada: navegador, web server, aplicação, API, identidade, dependência, banco, pipeline ou configuração.

SQL Injection

O erro clássico é misturar código e dados:

String sql = "SELECT * FROM USERS WHERE USERNAME = '" + user + "'";

Uma entrada maliciosa altera a estrutura do comando. A defesa principal é consulta parametrizada.

Em COBOL com Db2, SQL estático com host variables separa naturalmente valores do comando:

EXEC SQL
   SELECT NOME
     INTO :WS-NOME
     FROM CLIENTES
    WHERE CPF = :WS-CPF
END-EXEC

Ainda precisamos validar tamanho, formato, domínio, autorização e tratamento de erro. E SQL dinâmico concatenado pode recriar a vulnerabilidade.

XSS

Cross-Site Scripting ocorre quando dados do atacante são interpretados como código no navegador.

A proteção principal é encoding contextual da saída. O tratamento muda conforme o destino: HTML, atributo, JavaScript, CSS ou URL. Content Security Policy é uma segunda camada, não cura universal.

CSRF

Cross-Site Request Forgery força o navegador de um usuário autenticado a enviar uma ação não desejada.

Defesas incluem:

  • token anti-CSRF;

  • cookies SameSite;

  • verificação de origem;

  • reautenticação em operações críticas;

  • não usar GET para alterar estado.

Controle de acesso quebrado

Se o cliente altera /conta/12345 para /conta/12346 e vê a conta alheia, a autenticação funcionou. A autorização falhou.

Esconder o botão na tela não protege o endpoint. O servidor precisa autorizar cada operação e cada objeto.


11. OWASP — mapa de conscientização, não certificado de invencibilidade

Materiais baseados em 2021 já estão historicamente úteis, mas a lista vigente do OWASP Top 10 é a de 2025:

  1. Controle de acesso quebrado;

  2. Configuração insegura;

  3. Falhas na cadeia de suprimentos de software;

  4. Falhas criptográficas;

  5. Injeção;

  6. Design inseguro;

  7. Falhas de autenticação;

  8. Falhas de integridade de software ou dados;

  9. Falhas de logging e alertas;

  10. Tratamento incorreto de condições excepcionais.

As mudanças contam uma história. Configuração subiu de importância. Supply chain ganhou destaque. Logging passou a enfatizar alertas. Tratamento incorreto de condições excepcionais entrou na lista.

Isso é música para ouvidos COBOL. Mainframeiro sabe que exceção ignorada, return code não verificado e transação parcialmente atualizada podem produzir desastres sem uma única linha de malware.

OWASP Top 10 serve para conscientização. Não é uma lista completa de requisitos. Para verificação estruturada, o OWASP ASVS é mais apropriado.


12. Programação segura — não cole segurança depois do compilador

Programação segura inclui:

  • validação de entrada;

  • consultas parametrizadas;

  • encoding de saída;

  • autenticação forte;

  • autorização em cada operação;

  • menor privilégio;

  • tratamento seguro de erro;

  • logging útil;

  • proteção de segredos;

  • atualização de dependências;

  • revisão de código;

  • testes de segurança.

Validação de domínio

Não pergunte apenas se o dado é numérico. Pergunte se faz sentido.

Uma idade de -900 pode caber num PIC S9(4), mas não cabe na realidade. Uma transferência pode possuir sintaxe perfeita e violar limite, estado da conta ou segregação de funções.

Falhar de forma segura

Quando o serviço de autorização não responde, a aplicação libera ou nega? Quando ocorre timeout após débito, a repetição duplica a transferência? Quando o log falha, a operação privilegiada continua?

Falhar de forma segura exige:

  • estado consistente;

  • rollback;

  • idempotência;

  • mensagens externas discretas;

  • evidência interna suficiente;

  • negação por padrão quando apropriada.

Logs

Registre quem, o quê, quando, onde, resultado e identificador de correlação. Não registre senha, chave, token completo ou dado pessoal sem necessidade.

Log sem alerta é arqueologia. Alerta sem responsável é decoração natalina do SOC.

Cadeia de suprimentos

Atualizar biblioteca é só o início. Precisamos saber:

  • quais componentes existem;

  • de onde vieram;

  • quem alterou o pipeline;

  • quais artefatos foram assinados;

  • onde estão os segredos;

  • como revogar uma versão comprometida;

  • como reconstruir o software de forma confiável.

Segurança entra no desenho, no código, no build, no teste, na implantação e na operação.


13. Passo a passo — uma transferência bancária atravessa o castelo

Vamos acompanhar uma transferência.

Passo 1 — O cliente se conecta

TLS protege o canal. Mas o cadeado não garante que a aplicação esteja livre de fraude ou falha lógica.

Passo 2 — O cliente se identifica e autentica

O sistema verifica senha, passkey, dispositivo ou MFA, aplica rate limiting e detecta credential stuffing.

Passo 3 — O sistema autoriza

Verifica se o cliente possui a conta, se pode usar aquele canal, se o valor está dentro do limite e se a sessão possui nível suficiente.

Passo 4 — A regra de negócio valida

Confere valor positivo, moeda, saldo, favorecido, bloqueios, limite, horário, duplicidade e estado da conta.

Passo 5 — A transação é executada

Débito e crédito precisam formar uma unidade atômica. Em caso de falha, ROLLBACK; no sucesso, COMMIT.

Passo 6 — A operação é registrada

Logs e trilhas registram identidade, conta, canal, horário, resultado e correlação, sem expor segredos desnecessários.

Passo 7 — A fraude é analisada

O sistema considera novo dispositivo, valor atípico, velocidade, localização e histórico.

Passo 8 — O ambiente monitora

SIEM, regras, analistas e automações observam sinais técnicos e de negócio.

Passo 9 — Se algo der errado

A organização contém, investiga, preserva evidências, comunica, recupera e aprende.

Perceba: firewall, criptografia e MFA são três parafusos. A transferência segura depende da máquina inteira.


14. Checklist do programador COBOL que começou ontem — e quer chegar vivo à produção

Antes de entregar um programa, pergunte:

  1. Todos os campos externos têm tamanho, tipo e domínio validados?

  2. Valores negativos, zeros, limites e overflow foram tratados?

  3. Cada operação verifica autorização, não apenas autenticação?

  4. O programa usa apenas os privilégios necessários?

  5. SQL dinâmico e comandos externos separam código de dados?

  6. Return codes e condições excepcionais são tratados?

  7. Atualizações relacionadas usam unidade transacional adequada?

  8. Reprocessamento é idempotente ou pode duplicar operações?

  9. Logs possuem correlação e não vazam segredos?

  10. Mensagens ao usuário evitam detalhes internos?

  11. Senhas, tokens e chaves estão fora do fonte e do JCL?

  12. Há testes de sucesso, negação, limite, falha e recuperação?

  13. Alguém revisou o código com olhar de abuso, não só de funcionalidade?

  14. Existe plano para detectar e corrigir o comportamento em produção?

Se alguma resposta for “não sei”, você encontrou trabalho útil antes que a KAOS encontre trabalho divertido.


Epílogo — Desculpe por isso, Chefe

O Agente 86 voltou à sala de controle carregando um relatório.

— Chefe, tenho boas e más notícias.

— Comece pelas boas.

— O firewall está funcionando, o RACF está ativo e a senha não está mais em Base64.

— E as más?

— Igor substituiu a senha por AGOSTO@2026!, concedeu ALTER para todos e desligou o SIEM porque as luzes vermelhas estavam deixando o laboratório nervoso.

— 86...

— Eu sei, Chefe. Errei por isso aqui.

Esta é a grande lição do Capítulo I: segurança não é um produto instalado, um cadeado no navegador ou uma certificação pendurada na parede. É uma disciplina contínua de conhecimento, prevenção, observação, reação e aprendizado.

A tríade CIA ensina o que preservar. A análise de risco ensina onde concentrar esforço. A defesa em profundidade assume que algum controle falhará. A programação segura reduz fraquezas antes da produção. O monitoramento reconhece o que escapou. A resposta limita o dano. A recuperação devolve a missão ao ar.

O iniciante não precisa decorar todas as siglas de uma vez. Precisa aprender a fazer as perguntas certas:

  • O que estou protegendo?

  • De quem ou de quê?

  • Como isso pode falhar?

  • Quem realmente precisa de acesso?

  • Como saberei que algo aconteceu?

  • O que farei quando acontecer?

  • Como provarei o que ocorreu?

  • Como voltarei a operar com segurança?

Quando essas perguntas entram no código, no JCL, no RACF, no CICS, no Db2, na arquitetura e na reunião de mudança, o programador deixa de enxergar segurança como uma equipe que diz “não” no final do projeto. Ele passa a enxergá-la como parte da qualidade do sistema.

E qualidade, no Bellacosa Mainframe, significa algo muito simples: o programa faz o que deve, somente para quem pode, preserva o que importa, conta o que aconteceu e sabe voltar para casa depois que o telefone-sapato explode.


Referências para continuar a missão

☕ Um Café no Bellacosa Mainframe

Cibersegurança: dos fundamentos à recuperação

Uma jornada em dois capítulos para entender a linguagem da segurança, reconhecer riscos e organizar a operação antes, durante e depois de um incidente.

Vocabulário e Fundamentos da Cibersegurança

Tríade CIA, ativos, ameaças, vulnerabilidades, risco, malware, autenticação, criptografia, redes, aplicações web e codificação segura.

Ler o Capítulo I no artigo original →

Operação, Detecção, Resposta e Recuperação

Inventário, vulnerabilidades, eventos, alertas, incidentes, crise, monitoramento, contenção, evidências, continuidade e recuperação.

Ler o Capítulo II no artigo original →

Mapa da missão: o primeiro capítulo explica o que precisa ser protegido e por quê; o segundo mostra como observar, decidir, responder e restaurar a operação quando a prevenção não for suficiente.

Capítulo I — Vocabulário e Fundamentos da Cibersegurança

Abrir fora do quadro ↗

Capítulo II — Operação, Detecção, Resposta e Recuperação

Abrir fora do quadro ↗

terça-feira, 3 de janeiro de 2023

🕵️‍♂️ Tintin na Terra dos Containers — O Mistério de Docker & Kubernetes

 

Bellacosa Mainframe e os containers dockers e kubernetes

☕ Um Café no Bellacosa Mainframe

🕵️‍♂️ Tintin na Terra dos Containers — O Mistério de Docker & Kubernetes

Uma investigação entre imagens, containers, Pods, Deployments e clusters — porque até Tintin descobriria que colocar uma aplicação em produção é muito mais complicado do que embarcar no Sirius.

Caso nº 03:17 — Arquivo confidencial do Bellacosa Mainframe
Destino: Produção
Suspeitos: Docker, Kubernetes e algumas dezenas de arquivos YAML
Situação: aparentemente simples. Portanto, extremamente suspeita.

Tintin estava acostumado a situações complicadas.

Já havia enfrentado falsificadores, contrabandistas, sociedades secretas, ditadores, traficantes, cientistas excêntricos e até viajado à Lua.

Mas naquela manhã encontrou algo muito mais perigoso.

Um desenvolvedor havia pronunciado a frase:

— Na minha máquina funciona.

Milou levantou as orelhas.

Capitão Haddock largou o café.

Professor Girassol continuou mexendo em alguma coisa que provavelmente explodiria antes do almoço.

Tintin abriu seu pequeno caderno.

Novo caso.

Precisávamos descobrir como levar uma aplicação desde o notebook de um programador até produção sem depender da configuração particular daquela máquina.

E nossa investigação começaria com uma criatura chamada container.



📰 1. O estranho caso da aplicação que funcionava ontem

Imagine que nosso jovem programador COBOL decidiu aprender Python e criou uma pequena API usando FastAPI.

No computador dele tudo funciona.

Python instalado.

Bibliotecas instaladas.

Variáveis configuradas.

Banco de dados acessível.

Portas abertas.

Versões corretas.

Ele entrega o programa para Haddock.

Haddock tenta executá-lo.

Nada funciona.

MIL MILHÕES DE MILHARES DE BIBLIOTECAS INCOMPATÍVEIS!

Eis um problema muito antigo da computação.

O programa não existe sozinho.

Ele depende de um ambiente.

No universo mainframe conhecemos isso muito bem. Um programa COBOL pode depender de determinada versão de runtime, Db2, CICS, arquivos, configurações, parâmetros, bibliotecas e permissões.

No mundo distribuído ocorre exatamente o mesmo fenômeno.

Docker ataca justamente esse problema.

Em vez de entregar apenas:

minha-aplicacao.py

tentamos empacotar:

APLICAÇÃO
   +
RUNTIME
   +
BIBLIOTECAS
   +
DEPENDÊNCIAS
   +
CONFIGURAÇÃO NECESSÁRIA

dentro de uma unidade reproduzível.

Tintin anotaria:

Pista nº 1: não transporte apenas o programa. Transporte uma descrição reproduzível de seu ambiente.



📦 2. Surge a primeira testemunha: Docker

Docker popularizou uma maneira extremamente prática de construir, distribuir e executar aplicações em containers.

Mas precisamos separar duas palavras que frequentemente aparecem misturadas:

IMAGE e CONTAINER.

Uma imagem é o artefato preparado.

Um container é uma instância executando aquela imagem.

Podemos imaginar:

Dockerfile
    │
    ▼
docker build
    │
    ▼
┌─────────────────┐
│      IMAGE      │
│ app:v1          │
└─────────────────┘
       │
       │ docker run
       ▼
┌─────────────────┐
│    CONTAINER    │
│ aplicação viva  │
└─────────────────┘

Para quem vem do mainframe, existe uma analogia didática interessante.

Imagem lembra um artefato executável versionado. Container lembra uma execução desse artefato.

Não interprete isso literalmente como LOAD MODULE = IMAGE, porque arquiteturalmente são coisas diferentes.

Mas como ponte mental funciona muito bem.

O detalhe importante é:

uma única imagem pode originar muitos containers.

Temos:

IMAGE: bellacard-api:v7

        │
        ├── Container A
        ├── Container B
        ├── Container C
        └── Container D

Agora Tintin já tinha uma pista importante.

O artefato poderia ser reproduzido.


🧾 3. O bilhete encontrado no bolso do suspeito: Dockerfile

Toda boa investigação tem um documento comprometedor.

No nosso caso:

FROM python:3.13-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install -r requirements.txt

COPY . .

EXPOSE 8000

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

Esse arquivo é o Dockerfile.

Ele descreve como construir nossa imagem.

Tintin examina cada linha com a lupa.

FROM determina a imagem-base.

WORKDIR estabelece o diretório de trabalho.

COPY coloca arquivos dentro da imagem.

RUN executa comandos durante sua construção.

ENV pode definir variáveis de ambiente.

CMD estabelece o comando normalmente executado quando o container começa.

E então aparece:

EXPOSE 8000

Haddock imediatamente conclui:

— Então a porta 8000 está publicada!

Não.

EXPOSE não publica automaticamente uma porta no host.

É informação sobre a porta esperada pela aplicação. A publicação efetiva pode ser feita, por exemplo:

docker run -p 8080:8000 bellacard-api

Temos então:

HOST                  CONTAINER

localhost:8080  ───►  :8000

Essa diferença pequena é exatamente o tipo de detalhe que transforma uma explicação introdutória em conhecimento operacional.



🌐 4. O mistério das portas

Tintin agora encontra três containers.

frontend
backend
database

Cada um possui seu próprio contexto de rede.

E aqui surge outra mudança mental importante.

Não devemos construir sistemas distribuídos supondo que cada container terá eternamente determinado endereço IP.

Containers aparecem.

Containers desaparecem.

Podem ser recriados.

É muito melhor trabalhar com nomes e mecanismos de descoberta de serviços.

Em um ambiente Docker Compose poderíamos ter:

frontend
    │
    ▼
backend:8000
    │
    ▼
postgres:5432

Isso começa a revelar algo importante.

Containerização não significa simplesmente:

“pegamos uma VM e diminuímos.”

O modelo operacional é diferente.

Containers tendem a ser descartáveis.

A aplicação precisa ser projetada levando isso em consideração.



💾 5. Milou encontra o banco de dados

Milou começa a latir para um container.

Tintin abre o container.

Encontra PostgreSQL.

Haddock reinicia a máquina.

O banco desaparece.

BOMBARDEIOS E BACKUPS INEXISTENTES!

Tintin identifica imediatamente o problema.

Persistência.

O filesystem interno de um container não deve ser tratado ingenuamente como o lugar permanente dos dados importantes.

Precisamos separar:

COMPUTE                  DATA

container              volume/storage
 descartável            persistente

Docker oferece mecanismos como volumes e bind mounts.

Essa separação torna-se ainda mais importante quando chegarmos ao Kubernetes.

Uma aplicação pode morrer.

O Pod pode desaparecer.

O container pode ser substituído.

Mas determinados dados precisam continuar existindo.

Para quem vem de mainframe isso não deveria parecer revolucionário.

Há décadas aprendemos a separar processamento de dados persistentes.

A novidade está nas abstrações utilizadas.



🗝️ 6. O envelope secreto

Girassol encontra isto:

DB_PASSWORD=Tintin123
API_KEY=abc123

E sugere colocar tudo no GitHub.

Tintin quase derruba o café.

Variáveis de ambiente são excelentes para retirar determinadas configurações do código.

Podemos ter:

APP_ENV=production
DB_HOST=database
DB_PORT=5432

Arquivos .env também são muito convenientes durante desenvolvimento.

Mas existe uma armadilha:

tirar uma senha do código não significa que ela automaticamente ficou segura.

Um .env contendo credenciais continua sendo um arquivo contendo credenciais.

Precisa ser protegido.

Não deve simplesmente parar no repositório.

E esse problema reaparecerá no Kubernetes com os Secrets.


🧩 7. O caso ficou grande demais: Docker Compose

Tintin agora possui cinco containers:

frontend
API
agent
database
redis

Executá-los manualmente começa a parecer uma operação militar.

Então entra Docker Compose.

Podemos declarar um conjunto de serviços em um arquivo compose.yaml.

Algo conceitualmente semelhante a:

services:

  api:
    build: .
    ports:
      - "8000:8000"

  database:
    image: postgres

  redis:
    image: redis

Agora descrevemos uma pequena aplicação multi-container declarativamente.

Essa é uma das grandes virtudes do Compose.

Em vez de Haddock precisar decorar quinze comandos, declaramos como o ambiente deve ser.

Um detalhe merece atualização nos materiais mais antigos: no Compose moderno, aquele tradicional:

version: "3.8"

não é mais necessário. A documentação do Docker classifica a propriedade superior version como obsoleta e meramente informativa; o Compose moderno trabalha com a Compose Specification. (Docker Documentation)

É um belo exemplo de por que bons cursos técnicos precisam ser revisados continuamente.


🚢 8. Finalmente embarcamos a imagem

Construímos nossa aplicação:

docker build -t bellacard:v1 .

Temos uma imagem local.

Mas queremos executá-la em outro lugar.

Entram os container registries.

O fluxo conceitual torna-se:

SOURCE CODE
     │
     ▼
DOCKERFILE
     │
     ▼
BUILD
     │
     ▼
IMAGE
     │
     ▼
REGISTRY
     │
     ▼
PULL
     │
     ▼
EXECUTION

É aqui que começa uma ideia extremamente poderosa:

o artefato produzido pelo pipeline deve ser exatamente aquilo que promovemos entre ambientes.

Não queremos recompilar misteriosamente produção de maneira diferente de homologação.

Queremos artefatos versionados, rastreáveis e reproduzíveis.

O velho programador mainframe sentado no fundo da sala provavelmente começa a sorrir.

Ele já ouviu essa música antes.


🌊 9. De repente aparecem 500 containers

E aqui nossa aventura muda completamente.

Docker resolveu muito bem vários problemas relacionados a construção e execução de containers.

Mas suponha que nossa aplicação tenha:

300 containers
40 servidores
12 serviços
6 versões
3 ambientes
milhares de requisições

Quem decide onde cada workload executará?

Quem percebe que um deles morreu?

Quem cria outro?

Quem mantém determinada quantidade de réplicas?

Quem distribui tráfego?

Quem atualiza gradualmente uma versão?

Quem associa armazenamento?

Quem controla configuração?

Quem escala a aplicação?

Tintin escreve uma única palavra no caderno:

KUBERNETES


☸️ 10. Entramos no território Kubernetes

Kubernetes não é simplesmente um “Docker maior”.

Essa distinção é fundamental.

Ele é uma plataforma de orquestração de workloads containerizados.

Seu grande truque filosófico está no conceito de estado desejado.

Nós declaramos algo como:

QUERO 3 RÉPLICAS DESTA APLICAÇÃO.

O sistema observa:

DESEJADO = 3
ATUAL = 3

Tudo certo.

Um Pod desaparece:

DESEJADO = 3
ATUAL = 2

Existe divergência.

Os controladores trabalham para retornar ao estado desejado:

DESEJADO = 3
ATUAL = 3

Isso é extraordinariamente importante.

O operador deixa de pensar apenas:

“execute este comando.”

e passa também a pensar:

“este é o estado que quero manter.”

Quem conhece automação operacional, WLM e políticas em ambientes corporativos provavelmente já começou a enxergar pontes conceituais.


🏰 11. Tintin entra no cluster

Um cluster Kubernetes possui componentes de controle e nós onde workloads são executados.

De forma simplificada:

              KUBERNETES CLUSTER

        ┌─────────────────────────┐
        │      CONTROL PLANE      │
        │                         │
        │ API Server              │
        │ Scheduler               │
        │ Controller Manager      │
        │ etcd                    │
        └────────────┬────────────┘
                     │
          ───────────┼───────────
                     │
       ┌─────────────┴─────────────┐

   WORKER NODE                 WORKER NODE
   ┌──────────────┐           ┌──────────────┐
   │ kubelet      │           │ kubelet      │
   │ runtime      │           │ runtime      │
   │              │           │              │
   │ Pod Pod Pod  │           │ Pod Pod Pod  │
   └──────────────┘           └──────────────┘

O API Server é uma peça central da interface de controle.

O scheduler ajuda a decidir onde Pods serão colocados.

Os controllers observam o estado e trabalham para reconciliá-lo.

O etcd mantém dados importantes do estado do cluster.

E nos workers temos, entre outros componentes, o kubelet e um runtime de containers.


🐳 12. Haddock encontra uma pista desatualizada

Em algum velho mapa Tintin encontra:

Kubernetes → Docker

— Caso encerrado! — grita Haddock.

Não tão depressa.

Aqui existe uma atualização histórica importantíssima.

Kubernetes removeu seu dockershim integrado a partir da versão 1.24. Kubernetes moderno trabalha através da Container Runtime Interface — CRI, com runtimes compatíveis, como containerd e CRI-O; Docker Engine ainda pode ser integrado por um adaptador como cri-dockerd. (Kubernetes)

Isso não significa que imagens construídas com Docker deixaram de funcionar no Kubernetes. A própria documentação explica que usar Docker para construir imagens não cria uma dependência de Docker como runtime do cluster. (Kubernetes)

Portanto nosso mapa mental moderno é melhor representado assim:

              KUBERNETES

                 kubelet
                    │
                    ▼
                   CRI
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
     containerd             CRI-O

E Docker continua extremamente útil no workflow de desenvolvimento e construção de imagens.

Pista nº 12: Docker não morreu no Kubernetes. Mudou a relação arquitetural entre eles.


📦 13. O menor quarto do hotel: Pod

Chegamos agora a uma das palavras mais importantes de Kubernetes:

Pod.

Pod é a menor unidade implantável de computação que Kubernetes gerencia.

Normalmente encontramos um container principal dentro dele, embora um Pod possa conter mais de um container quando esses processos precisam compartilhar estreitamente recursos e ciclo de vida.

Podemos imaginar:

POD
┌────────────────────────────┐
│                            │
│   Application Container    │
│                            │
│   shared networking        │
│   shared volumes/context   │
│                            │
└────────────────────────────┘

Mas existe algo fundamental:

não se apaixone pelo Pod.

Pods são substituíveis.

Podem desaparecer e serem recriados.

E por isso normalmente não administramos aplicações complexas criando Pods soltos manualmente.

Entra outra testemunha.


🧬 14. Deployment → ReplicaSet → Pods

Para uma aplicação típica, podemos declarar um Deployment.

Por exemplo:

replicas: 3

Conceitualmente:

Deployment
     │
     ▼
ReplicaSet
     │
 ┌───┼───┐
 ▼   ▼   ▼
Pod Pod Pod

Se um desaparece:

Pod ✖

o sistema trabalha para restaurar o estado desejado.

Isso também permite realizar rolling updates.

Em vez de:

VERSÃO 1
   ↓
DESLIGA TUDO
   ↓
VERSÃO 2

podemos substituir progressivamente instâncias antigas por novas.

E, quando necessário, trabalhar com mecanismos de rollback.

Haddock começa a gostar da história.

Produção sem uma gigantesca janela de “desliga tudo e reza” realmente parece civilização.


📞 15. Mas como encontramos esses Pods?

Temos outro problema.

Pods são efêmeros.

Se ficarmos distribuindo seus endereços diretamente, criamos dependências frágeis.

Entra o objeto Service.

Imagine:

CLIENTE
   │
   ▼
SERVICE
   │
 ┌─┼───────────┐
 ▼ ▼           ▼
POD A        POD B        POD C

O Service fornece uma abstração estável para alcançar determinado conjunto de Pods.

Essa é uma mudança mental importantíssima:

não procure indivíduos; procure o serviço.

Para um programador mainframe acostumado com um endpoint lógico de uma aplicação transacional, a ideia começa a soar curiosamente familiar.


🗺️ 16. ConfigMap e o documento que não deveria conter a senha

Nossa aplicação precisa saber:

LOG_LEVEL=INFO
LANGUAGE=pt_BR
FEATURE_X=true

Esses valores podem estar em um ConfigMap.

Mas temos também:

PASSWORD
TOKEN
API_KEY
CERTIFICATE

Aí entramos no território dos Secrets.

Contudo, há uma pegadinha digna dos irmãos Dupond e Dupont:

— Está em Base64, portanto está criptografado!

— Exatamente! E eu diria ainda mais: está criptografado porque está em Base64!

Errado duas vezes.

A documentação oficial é explícita: Base64 não é criptografia. Kubernetes Secrets podem ser armazenados sem criptografia por padrão; ambientes sérios precisam considerar controles como RBAC, restrição de acesso, criptografia em repouso e soluções apropriadas de gerenciamento de segredos. (Kubernetes)

Portanto:

ConfigMap
    ↓
configuração não confidencial

Secret
    ↓
informação confidencial
    ↓
+ controle de acesso
+ proteção apropriada
+ encryption at rest quando aplicável
+ gestão segura do ciclo de vida

Esse é um ponto que merece enorme atenção em qualquer treinamento.


🗄️ 17. O banco não pode desaparecer novamente

Voltamos ao problema de persistência.

No Kubernetes encontramos conceitos como:

PersistentVolume — PV

e

PersistentVolumeClaim — PVC

Didaticamente:

POD
 │
 ▼
PVC
 │
 ▼
PV
 │
 ▼
STORAGE

O PVC representa a solicitação de armazenamento feita pelo workload.

O PV representa o recurso persistente disponibilizado ao cluster, dependendo do modelo e provisionamento utilizado.

Em ambientes modernos existe ainda toda uma camada envolvendo StorageClass, provisionamento dinâmico e CSI.

Mas para nossa primeira investigação basta guardar:

Pod é descartável; dado importante não pode depender da sobrevivência daquele Pod.


🩺 18. Professor Girassol inventa três estetoscópios

Agora precisamos saber se a aplicação está saudável.

Kubernetes trabalha com probes que respondem perguntas diferentes.

Startup probe:

Você conseguiu iniciar?

Liveness probe:

Você continua vivo?

Readiness probe:

Você está pronto para receber tráfego?

Essas perguntas parecem semelhantes.

Não são.

Imagine uma aplicação Java que demora bastante para iniciar.

Ela pode estar viva, mas ainda não pronta para atender.

Ou uma aplicação pode continuar com processo existente, mas ter entrado em um estado do qual não consegue se recuperar adequadamente.

Misturar esses conceitos pode produzir exatamente o tipo de incidente que começa às...

03:17.

Pronto.

Easter egg encontrado. ☕😎


🚪 19. Tintin chega ao portão: Ingress

Agora temos serviços funcionando dentro do cluster.

Mas usuários precisam chegar até eles.

Tradicionalmente, Kubernetes utiliza Ingress para definir roteamento HTTP/HTTPS externo, associado a uma implementação/controlador.

Conceitualmente:

INTERNET
   │
   ▼
INGRESS
   │
   ├── /api ─────► Service API
   │                    │
   │                  Pods
   │
   └── /web ─────► Service WEB
                        │
                      Pods

Ingress continua sendo um conceito importante porque existem enormes ambientes usando-o.

Porém nosso curso de 2026 precisa colocar uma anotação vermelha no caderno de Tintin:

⚠️ EXISTE UM NOVO CAPÍTULO

O ecossistema Kubernetes está avançando para Gateway API como abordagem moderna e mais expressiva para networking. Em agosto de 2026, o projeto anunciou Gateway API v1.6, incluindo TCPRoute e UDPRoute no canal Standard. (Kubernetes)

Há inclusive tooling oficial para ajudar migrações de Ingress para Gateway API. (Kubernetes)

Portanto um curso atualizado deveria ensinar:

Ingress
   │
   ├── importantíssimo para ambientes existentes
   │
   └── API congelada para novos recursos
             │
             ▼
         Gateway API
        caminho moderno

Esse pequeno detalhe separa uma apostila histórica de uma formação preparada para os próximos anos.


📈 20. De repente chegam dez mil usuários

Haddock finalmente publica seu sistema.

Um usuário acessa.

Tudo funciona.

Dez acessam.

Tudo funciona.

Mil acessam.

Haddock começa a suar.

Dez mil acessam.

ESCALABILIDADE DOS SETE MARES!

Kubernetes oferece mecanismos de escalabilidade, entre eles o Horizontal Pod Autoscaler — HPA.

Podemos pensar:

TRÁFEGO ↑
CPU ↑
MÉTRICA ↑

       │
       ▼

HPA observa
       │
       ▼

replicas: 3
       │
       ▼
replicas: 7

Quando a demanda diminui, a quantidade pode ser reduzida segundo a configuração e comportamento do autoscaler.

CPU e memória são excelentes exemplos introdutórios, embora arquiteturas reais possam utilizar outras métricas conforme a infraestrutura de métricas disponível.

Aqui encontramos uma ponte interessante com o universo mainframe.

Um profissional de WLM imediatamente perguntaria:

Qual é a política? Qual a prioridade? Qual o recurso disponível? Qual a métrica? Qual o objetivo de serviço?

Excelente.

Essa é exatamente a mentalidade que queremos preservar.

A tecnologia muda.

As boas perguntas sobrevivem.


🧠 21. Tintin monta o quadro completo

Depois de centenas de pistas espalhadas pela mesa, finalmente conseguimos enxergar nossa arquitetura.

                    INTERNET
                        │
                        ▼
              ┌──────────────────┐
              │ GATEWAY/INGRESS  │
              └────────┬─────────┘
                       │
                       ▼
                  ┌─────────┐
                  │ SERVICE │
                  └────┬────┘
                       │
              ┌────────┼────────┐
              ▼        ▼        ▼
             POD      POD      POD
              ▲        ▲        ▲
              └────────┼────────┘
                       │
                  ReplicaSet
                       ▲
                       │
                  Deployment
                       │
             desired replicas = 3


       CONFIGURAÇÃO                DADOS

        ConfigMap                   PVC
        Secrets                      │
                                     ▼
                                     PV
                                     │
                                     ▼
                                  STORAGE

E por trás disso existe o cluster:

CONTROL PLANE
      │
      ├── API Server
      ├── Scheduler
      ├── Controllers
      └── etcd
             │
             ▼
        WORKER NODES
             │
             ▼
           kubelet
             │
             ▼
             CRI
             │
       container runtime
             │
             ▼
            Pods

Finalmente o mistério começa a fazer sentido.


🏦 22. E onde entra o mainframe nessa aventura?

Aqui está talvez a parte mais interessante para quem está entrando nesse mundo vindo de COBOL, CICS, Db2 e z/OS.

Você não precisa apagar quarenta anos de conhecimento para aprender containers.

Muito pelo contrário.

Quem passou anos pensando em disponibilidade, processamento transacional, controle de acesso, recuperação, armazenamento, capacidade, versionamento e produção já possui uma enorme bagagem conceitual.

O segredo é não procurar equivalências literais.

Não diga:

CICS = Kubernetes
JES2 = Kubernetes
WLM = HPA
RACF = RBAC

Não são.

Mas use essas tecnologias como pontes cognitivas.

Você conhece a pergunta:

Quem pode executar isto?

Ótimo. Vamos conversar sobre RBAC.

Você conhece:

Onde os dados sobrevivem?

Excelente. Vamos falar de persistent storage.

Você pergunta:

O que acontece se esta execução morrer?

Bem-vindo ao desired state e reconciliation.

Você pergunta:

Como distribuir capacidade?

Vamos estudar scheduler, requests, limits e autoscaling.

Você pergunta:

Como colocar uma nova versão sem explodir produção?

Deployment, rolling updates, probes, observabilidade e estratégias de rollout estão esperando por você.

O veterano não chega vazio a Kubernetes.

Chega carregando décadas de perguntas extremamente úteis.


🚂 23. A viagem completa

Agora podemos reconstruir toda nossa investigação em uma única linha narrativa.

Tintin recebe:

SOURCE CODE

Cria:

Dockerfile

Produz:

IMAGE

Publica:

REGISTRY

Kubernetes referencia essa imagem.

Um:

Deployment

define o workload desejado.

Ele administra ReplicaSets que mantêm:

Pods

Esses Pods são alcançados por:

Service

Configuração chega através de mecanismos como:

ConfigMap
Secret

Dados persistentes podem utilizar:

PVC → PV → Storage

Saúde pode ser acompanhada com:

startup
readiness
liveness

Tráfego externo pode chegar através de:

Gateway API / Ingress

E escalabilidade horizontal pode envolver:

HPA

Isso já não parece uma coleção aleatória de palavras.

Parece uma arquitetura.


🔎 24. O que as excelentes ilustrações escondem

Os infográficos que iniciaram nossa investigação são ótimos para aquilo que considero a primeira passagem pelo território.

Você olha.

Reconhece os nomes.

Entende as relações.

Executa alguns comandos.

Constrói uma imagem.

Executa containers.

Cria um Compose.

Publica uma imagem.

Cria Pod.

Deployment.

Service.

PVC.

Ingress.

HPA.

Excelente.

Mas existe uma segunda passagem.

É nela que começamos a perguntar:

“Como isso funciona em produção?”

Então surgem novos personagens:

Namespaces
RBAC
ServiceAccounts
NetworkPolicy
requests/limits
taints
tolerations
affinity
anti-affinity
PodDisruptionBudget
StorageClass
CSI
Helm
Kustomize
observability
metrics
logging
tracing
GitOps
CI/CD
supply-chain security
image scanning
policy enforcement
Gateway API

E existe uma terceira passagem ainda mais interessante para nós:

Kubernetes + IBM Z + LinuxONE + OpenShift + z/OS

Aí a história deixa de ser simplesmente:

“mainframe versus cloud.”

Passa a ser:

“qual workload deve executar onde?”

Esse é um problema arquitetural muito mais adulto.


🚀 25. Bellacosa Containers 101 → 201 → 301

Eu transformaria todo esse material em uma trilha em três atos.

101 — Tintin descobre os containers: Linux essencial, Docker, imagens, containers, Dockerfile, registry, networking, volumes, environment variables, secrets e Compose.

201 — Tintin encontra Kubernetes: cluster, control plane, worker, kubectl, Pod, Deployment, ReplicaSet, Service, ConfigMap, Secret, PV/PVC, probes, requests/limits, Ingress, Gateway API e HPA.

301 — Tintin entra em produção: RBAC, namespaces, NetworkPolicy, CSI, Helm/Kustomize, observabilidade, segurança, CI/CD, GitOps, supply chain, OpenShift, LinuxONE/IBM Z e integração de workloads containerizados com serviços corporativos e z/OS.

O aluno poderia começar com:

docker run hello-world

e terminar compreendendo algo como:

Internet
   │
Gateway
   │
OpenShift/Kubernetes
   │
Containerized API
   │
MQ / REST
   │
z/OS Connect
   │
CICS
   │
COBOL
   │
Db2

Agora estamos falando a língua do Bellacosa Mainframe.


🏁 Epílogo — Tintin fecha o caderno

Depois de horas investigando containers, imagens, registries, Pods, Deployments, Services, Secrets e clusters, Capitão Haddock finalmente perguntou:

— Então Kubernetes substitui o mainframe?

Tintin fechou o caderno.

Milou olhou para Haddock.

Professor Girassol fingiu não ouvir.

E um velho programador COBOL sentado no canto começou a rir.

Porque essa era a pergunta errada.

Mainframes resolvem determinados problemas extraordinariamente bem.

Containers resolvem outros.

Kubernetes resolve um problema importantíssimo de orquestração e gerenciamento de workloads containerizados em escala.

E arquiteturas modernas podem combinar esses mundos.

A verdadeira habilidade do arquiteto não é escolher uma tecnologia para vencer uma guerra imaginária.

É saber onde cada workload pertence, como conectá-lo aos demais e como operar o conjunto com segurança, disponibilidade e previsibilidade.

Tintin guardou a lupa.

Haddock terminou o café.

Milou finalmente encontrou o container desaparecido.

E o veterano COBOL abriu um terminal e digitou:

kubectl get pods

Havia três.

bellacard-7f84c      Running
bellacard-2b17d      Running
bellacard-91a2e      Running

Deployment desejava três.

Produção tinha três.

Por alguns preciosos minutos, o universo estava em equilíbrio.

Até o telefone tocar.

Eram 03:17.

— Tintin... caiu produção.

Ele pegou o sobretudo.

— Milou, estamos diante de um novo caso.

Bellacosa Mainframe — porque a tecnologia muda, mas produção continua encontrando maneiras criativas de acordar alguém de madrugada.




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

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

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

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