✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
Bellacosa Mainframe e a ordem correta para assistir another
☕💣👁️ OPERADOR, O PROBLEMA NÃO É O ANIME. É A EXPECTATIVA DO USUÁRIO.
A ORDEM DEFINITIVA PARA QUEM ACHOU ANOTHER SUPERFICIAL — E POR QUE VOCÊ TALVEZ ESTEJA CERTO
Existe um fenômeno curioso que ocorre com muitos fãs após terminarem Another.
Eles chegam ao episódio final.
Fecham o player.
Olham para a tela.
E pensam:
"Era só isso?"
Não porque o anime seja ruim.
Não porque a produção seja fraca.
Não porque a atmosfera não funcione.
Mas porque existe uma diferença gigantesca entre aquilo que Another promete nos primeiros episódios e aquilo que ele realmente entrega.
É uma situação muito semelhante ao que acontece em ambientes corporativos de TI.
Imagine que alguém lhe entrega um sistema legado.
Você abre a documentação.
Encontra diagramas complexos.
Processos misteriosos.
Dependências ocultas.
Interfaces desconhecidas.
Logs criptografados.
Você pensa:
"Nossa. Deve existir uma arquitetura incrível por trás disso."
Após semanas investigando você descobre:
"Na verdade são apenas três jobs e uma quantidade absurda de gambiarras."
A decepção não acontece porque o sistema é ruim.
Acontece porque sua imaginação construiu algo maior.
Com Another ocorre exatamente isso.
O anime cria uma expectativa gigantesca.
O espectador imagina conspirações.
Explicações elaboradas.
Mistérios profundos.
Camadas psicológicas infinitas.
Mas a adaptação escolhe outro caminho.
Ela prioriza:
Atmosfera
Tensão
Choque
Horror visual
Por isso muitos espectadores terminam a série com uma sensação estranha.
Gostaram.
Mas sentem que faltou alguma coisa.
Se você faz parte desse grupo, existe uma boa notícia.
O universo de Another é muito maior do que o anime mostra.
E existe uma ordem quase perfeita para explorá-lo.
☕🥇 PRIMEIRO LUGAR
A LIGHT NOVEL ORIGINAL — O SISTEMA-FONTE
Antes de qualquer coisa precisamos entender um fato fundamental.
O anime não é a obra original.
A obra original é a light novel escrita por Yukito Ayatsuji.
E isso muda tudo.
O Grande Problema do Anime
O anime possui apenas 12 episódios.
Doze.
Para adaptar uma história construída sobre:
investigação
observação
suspeitas
deduções
comportamento humano
Isso cria uma limitação inevitável.
O diretor precisou escolher.
Ele poderia:
Opção A
Explorar personagens.
Ou:
Opção B
Explorar horror visual.
A produção escolheu a segunda opção.
O Que a Novel Faz Melhor?
Praticamente tudo relacionado aos personagens.
O leitor acompanha:
pensamentos
dúvidas
inseguranças
hipóteses
interpretações
Algo impossível de reproduzir completamente na animação.
Kouichi Muda Completamente
No anime ele parece apenas:
"O garoto curioso."
Na novel ele se transforma em um observador.
Quase um detetive.
Você entende seus raciocínios.
Suas conclusões.
Suas hesitações.
Sua evolução.
Mei Misaki Se Torna Outra Pessoa
Essa talvez seja a maior diferença.
Muitos espectadores terminam o anime e pensam:
"Mei é interessante, mas parece distante."
Na novel ela ganha profundidade.
Você percebe:
sarcasmo
humor
sensibilidade
fragilidade emocional
Ela deixa de ser apenas um símbolo visual.
Passa a ser um ser humano.
Veredito Bellacosa
Se o anime é:
INTERFACE GRÁFICA
A novel é:
CÓDIGO-FONTE
Sem ela você está vendo apenas a camada superficial.
☕🥈 SEGUNDO LUGAR
ANOTHER 2001 — O UPGRADE QUE MUITOS DESCONHECEM
Aqui encontramos algo fascinante.
A maioria dos fãs sequer sabe que existe.
Mas Another 2001 é provavelmente o material mais injustamente ignorado de toda a franquia.
O Que Aconteceu?
Quando escreveu a obra original, Yukito Ayatsuji ainda estava consolidando algumas ideias.
Décadas depois ele retornou ao universo.
Mais experiente.
Mais maduro.
Mais refinado.
O Resultado
Um romance muito mais seguro.
Mais confiante.
Mais elaborado.
O Que Melhora?
Praticamente tudo.
Especialmente:
ritmo
construção narrativa
personagens
mistério
Menos Dependência do Choque
Uma crítica comum ao anime original:
"Parece que algumas mortes existem apenas para impressionar."
Em Another 2001 existe mais equilíbrio.
A narrativa ganha protagonismo.
É Necessário?
Não.
Mas para quem sentiu falta de profundidade?
É praticamente obrigatório.
☕🥉 TERCEIRO LUGAR
ANOTHER EPISODE S — O DATASET ESCONDIDO
Imagine que você encontrou um backup esquecido.
Um daqueles datasets antigos.
Ninguém sabia que existia.
Mas ele contém informações importantes.
É exatamente isso que Episode S representa.
O Que É?
Uma história complementar.
Não substitui a obra principal.
Mas adiciona contexto.
Por Que Ler?
Porque amplia a percepção do universo.
Muitos elementos que pareciam pequenos ganham nova importância.
O Valor Real
Não está na trama.
Está na atmosfera.
Você passa mais tempo dentro daquele mundo.
E isso ajuda a criar conexão emocional.
☕🏅 QUARTO LUGAR
O MANGÁ — O MEIO DO CAMINHO
O mangá ocupa uma posição curiosa.
Ele não possui toda a profundidade da novel.
Mas também não é tão acelerado quanto o anime.
A Grande Vantagem
O ritmo.
Você consegue observar melhor:
expressões
reações
silêncios
A Arte
Hiro Kiyohara realizou um trabalho excelente.
Muitos fãs consideram algumas cenas mais impactantes no mangá do que na animação.
O Problema
Ainda existe limitação de espaço.
O aprofundamento psicológico continua menor que na novel.
☕📼 QUINTO LUGAR
OVA THE OTHER – INGA
Muita gente pula.
Grande erro.
Por Que Existe?
Porque Mei Misaki é a alma de Another.
E o OVA ajuda justamente a entender melhor essa personagem.
O Que Acrescenta?
Humanidade.
Algo que parte do público sente falta no anime principal.
Não É Obrigatório
Mas é extremamente recomendável.
O MAIOR MAL-ENTENDIDO SOBRE ANOTHER
Agora chegamos ao ponto central.
O maior erro dos espectadores é acreditar que Another pretende ser o próximo:
Monster
Death Note
Steins;Gate
Não pretende.
Another Nunca Foi Sobre Resolver Um Mistério
Parece absurdo dizer isso.
Mas é verdade.
O mistério existe.
Porém não é o objetivo principal.
O Objetivo Real
Produzir uma sensação.
Ansiedade.
Insegurança.
Desconforto.
Paranoia.
É Um Anime de Clima
Não de investigação.
Essa diferença muda completamente a experiência.
O Efeito Premonição
Uma comparação ajuda.
Imagine assistir:
Seven
Você quer descobrir o assassino.
Monster
Você quer entender Johan.
Death Note
Você quer acompanhar o duelo intelectual.
Premonição
Você quer descobrir:
"Como a próxima tragédia acontecerá?"
Another está muito mais próximo de Premonição.
Por Que Alguns Fãs Amam?
Porque valorizam atmosfera.
Por Que Outros Se Frustram?
Porque valorizam construção narrativa.
O Problema Não Está Em Another
O problema está na expectativa inicial.
O anime vende uma promessa de mistério.
Mas entrega uma experiência de horror atmosférico.
São coisas diferentes.
A Melhor Forma de Consumir a Franquia
Se você achou o anime superficial:
Etapa 1
Leia a novel.
Etapa 2
Leia Another 2001.
Etapa 3
Leia Episode S.
Etapa 4
Leia o mangá.
Etapa 5
Reveja o anime.
O Que Acontece Depois?
Algo curioso.
Você percebe que o anime nunca mudou.
Quem mudou foi você.
Agora entende:
motivações
símbolos
personagens
decisões
A experiência torna-se completamente diferente.
Veredito Final do Operador
Após analisar toda a franquia, chegamos a uma conclusão surpreendente.
O anime de Another não é exatamente uma adaptação.
É quase um resumo visual.
Uma vitrine.
Uma demonstração.
Um trailer extremamente sofisticado para um universo muito maior.
Na linguagem Bellacosa Mainframe:
O anime é o painel do operador.
A light novel é o código-fonte.
Another 2001 é a nova versão do sistema.
Episode S é a documentação esquecida.
O mangá é o manual ilustrado.
Se você terminou o anime pensando:
"Só isso?"
Não significa que falhou em compreender a obra.
Significa apenas que chegou ao final da interface gráfica sem acessar os datasets mais importantes.
E a boa notícia é que os arquivos continuam lá.
Esperando pelo próximo operador curioso disposto a abrir o dataset correto e descobrir que, por trás das mortes, existia um sistema muito maior rodando silenciosamente em background.
Bellacosa Mainframe e o cheio de surpresas Made in Abyss
☕💣🕳️ OPERADOR, O DATACENTER DA HUMANIDADE ACABA DE ENCONTRAR UM STORAGE INFINITO SEM DOCUMENTAÇÃO, SEM BACKUP E SEM PLANO DE RETORNO!
MADE IN ABYSS — O ANIME QUE TRANSFORMOU UMA SIMPLES EXPLORAÇÃO EM UM DESASTRE OPERACIONAL DE NÍVEL APOCALÍPTICO E PROVOU QUE A CURIOSIDADE HUMANA É MAIS PERIGOSA QUE QUALQUER FALHA DE SEGURANÇA
Apesar da aparência infantil, é recomendado para público mais velho devido à violência intensa, sofrimento físico, temas psicológicos pesados e cenas perturbadoras.
📺 EPISÓDIOS E FILMES
Temporada 1 (2017)
13 episódios
Filmes Recap
Journey's Dawn (2019)
Wandering Twilight (2019)
Filme Continuação
Dawn of the Deep Soul (2020)
Temporada 2
Made in Abyss: The Golden City of the Scorching Sun (2022)
12 episódios
Total principal até o momento:
25 episódios + 1 filme canônico essencial
☕ O QUE É O ABYSS?
Imagine um operador encontrando um volume DASD tão profundo que ninguém sabe onde termina.
Agora imagine que toda a civilização mundial resolve construir sua economia em torno dele.
Esse é o Abyss.
Uma gigantesca cratera vertical contendo:
Ecossistemas desconhecidos
Artefatos impossíveis
Tecnologia perdida
Criaturas monstruosas
Fenômenos inexplicáveis
O detalhe mais assustador:
Descer é permitido. Subir é punido.
🕳️ SINOPSE
Riko vive na cidade de Orth, construída ao redor do gigantesco Abyss.
Seu sonho é tornar-se uma White Whistle, a elite dos exploradores.
Durante uma exploração ela encontra Reg, um misterioso garoto robô sem memória.
Quando uma mensagem aparentemente enviada por sua mãe desaparecida surge das profundezas do Abyss, os dois iniciam uma descida sem retorno.
A partir desse momento o anime deixa de ser uma aventura infantil e se transforma numa das experiências mais brutais da animação japonesa.
📖 RESUMO DA HISTÓRIA
A estrutura da narrativa lembra uma operação de disaster recovery invertida.
Normalmente você explora para voltar com informações.
No Abyss, quanto mais informações você obtém, menor a chance de retornar.
Cada camada apresenta:
Novas espécies
Novas leis naturais
Novas ameaças
Novos custos físicos
A história não gira em torno de derrotar um vilão.
Ela gira em torno de sobreviver ao próprio mundo.
E isso é extremamente raro.
👥 PRINCIPAIS PERSONAGENS
Riko
A exploradora.
Curiosa.
Inteligente.
Obstinada.
Representa a busca humana pelo desconhecido.
É a operadora que vê uma mensagem "ACESSO PROIBIDO" e imediatamente tenta acessar.
Reg
O mistério ambulante.
Uma tecnologia impossível.
Uma máquina construída por alguém muito mais avançado.
Funciona como um artefato perdido que ninguém consegue documentar.
Nanachi
Talvez a personagem mais amada da obra.
Representa sobrevivência, trauma e adaptação.
Sua história muda completamente o tom emocional da série.
Bondrewd
Um dos maiores antagonistas já criados.
Não é mal por prazer.
Não busca poder.
Não busca riqueza.
Busca conhecimento.
E está disposto a pagar qualquer preço.
Inclusive o preço que outras pessoas terão de pagar.
☕ O QUE TORNA MADE IN ABYSS DIFERENTE?
Aqui está a genialidade da obra.
A maioria dos animes apresenta:
Mistério → Resposta
Made in Abyss apresenta:
Mistério → Mais mistério
Quanto mais fundo você vai:
Menos entende
Mais teme
Mais perguntas surgem
É exatamente o oposto da estrutura tradicional.
O ABYSS COMO UMA METÁFORA DA HUMANIDADE
O Abyss pode ser interpretado de diversas maneiras.
A Ciência
Bondrewd representa o conhecimento sem ética.
A eterna pergunta:
"Até onde devemos ir para descobrir algo?"
A Curiosidade Humana
Riko simboliza o impulso que levou:
Navegadores aos oceanos
Cientistas ao espaço
Pesquisadores às profundezas do mar
O desejo de explorar mesmo quando o risco é absurdo.
Crescimento
Cada camada simboliza uma etapa da vida.
Quanto mais amadurecemos:
Mais conhecimento adquirimos
Mais inocência perdemos
Existe um preço para crescer.
A Jornada Sem Retorno
A infância é uma camada superior.
A vida adulta é uma descida.
Você aprende.
Você evolui.
Mas nunca retorna exatamente como era.
☕ AS MENSAGENS OCULTAS
Nem todo conhecimento é gratuito
Toda descoberta possui um custo.
A inocência é temporária
Os personagens começam crianças.
O Abyss força amadurecimento brutal.
O mundo não é justo
Não existe proteção narrativa.
Personagens sofrem consequências reais.
O desconhecido é fascinante e aterrorizante
O mesmo impulso que produz avanços também produz tragédias.
🎨 QUALIDADE TÉCNICA
Arte
O contraste visual é brilhante.
Personagens parecem saídos de um conto infantil.
O mundo parece saído de um pesadelo lovecraftiano.
Trilha Sonora
Kevin Penkin criou uma das trilhas mais elogiadas da década.
A música transmite:
Maravilhamento
Solidão
Terror
Esperança
Muitas cenas seriam impossíveis sem a trilha.
Direção
A direção entende perfeitamente o ritmo da exploração.
O espectador sente:
Curiosidade
Encantamento
Ansiedade
Medo
Exatamente na sequência desejada.
HOUVE CENSURA?
Sim, a obra gerou controvérsias em vários países.
Os principais debates envolveram:
Violência extrema envolvendo personagens jovens
Nudez não sexualizada em contexto infantil
Tortura psicológica
Horror corporal (body horror)
Algumas plataformas internacionais realizaram pequenos ajustes de exibição ou classificação etária.
Entretanto, a narrativa principal permaneceu intacta na maior parte das distribuições oficiais.
IMPACTO CULTURAL
Made in Abyss tornou-se referência em:
Worldbuilding
Fantasia sombria
Narrativas de exploração
Horror psicológico
Diversos críticos o consideram um dos melhores mundos fictícios construídos nos animes modernos.
A série influenciou debates sobre:
Ética científica
Narrativas de sofrimento
Construção de ecossistemas fictícios
Limites da curiosidade humana
☕ ANÁLISE BELLACOSA MAINFRAME
Se eu tivesse que explicar Made in Abyss para um operador de z/OS, diria:
O Abyss é um ambiente legado criado por uma civilização desaparecida.
Ninguém possui o source.
Ninguém possui a documentação.
Ninguém conhece todos os subsistemas.
Mas toda a economia mundial depende dele.
Cada camada é um novo nível de armazenamento.
Cada descida é uma migração para um ambiente menos conhecido.
E a Maldição do Abyss funciona como uma rotina de segurança que cobra um preço cada vez maior por qualquer tentativa de rollback.
No fundo, Made in Abyss não fala sobre monstros.
Não fala sobre aventura.
Não fala sobre tecnologia perdida.
Ele fala sobre algo muito mais humano:
A necessidade quase irracional de continuar avançando, mesmo sabendo que talvez não exista caminho de volta.
🎯 VEREDITO FINAL
Made in Abyss é uma obra-prima da fantasia sombria e do worldbuilding moderno.
É um anime que engana pela aparência, destrói expectativas, desafia convenções narrativas e entrega uma experiência emocional que poucos espectadores esquecem.
Uma descida fascinante, assustadora e profundamente humana.
☕☕☕☕☕ Nota Bellacosa Mainframe: 5/5 Cafés
Status do Sistema: 🟢 EXPLORAÇÃO ATIVA
Mensagem do Console:
"OPERADOR, O JOB DE DESCIDA FOI SUBMETIDO COM SUCESSO. O SISTEMA INFORMA QUE NÃO EXISTE PROCEDIMENTO DE RETORNO DISPONÍVEL APÓS A SEXTA CAMADA. DESEJA CONTINUAR? (Y/N)" ☕💣🕳️
⚔️ AS AVENTURAS — O COLAPSO ENTRE REALIDADE E SISTEMA
As batalhas do filme são absurdamente cinematográficas.
Chefes gigantes aparecem:
em arenas urbanas;
ruas reais;
estádios;
espaços públicos.
A cidade inteira vira:
um campo operacional híbrido.
E a sensação é fantástica: como se MMORPG, Pokémon GO, cloud computing e neurociência tivessem colidido em um único sistema.
🌍 IMPACTO CULTURAL
Ordinal Scale foi extremamente importante porque:
revitalizou a franquia;
conectou SAO II com Alicization;
elevou a qualidade visual da série;
consolidou SAO no cinema mundial.
O filme também ajudou a popularizar ainda mais debates sobre:
realidade aumentada;
metaverso;
IA emocional;
integração humano-máquina.
☕ A VERDADE SOBRE ORDINAL SCALE
Muitos acham que o filme é apenas:
“mais uma aventura de SAO”.
Mas na prática… Ordinal Scale talvez seja o momento mais próximo da realidade atual.
Porque ele mostra algo perigosamente plausível:
tecnologia invisível;
dependência social digital;
memórias tratadas como dados;
realidade aumentada integrada ao cotidiano.
Não é mais sobre escapar para outro mundo.
Agora:
o próprio mundo real foi convertido em interface.
BELLACOSA MAINFRAME // VIRTUAL ARCHIVE
SISTEMA ONLINE|CONEXÃO SEGURA|00:00:00
Sword Art Online sem Mistérios
O Guia Definitivo da Franquia
Entre novamente em Aincrad e percorra toda a evolução de
Sword Art Online. Conheça as temporadas, filmes,
especiais, arcos narrativos, personagens, tecnologias de realidade
virtual e conexões com as light novels e os mangás.
🕶️ O atacante perfeito talvez pareça um usuário normal
Essa é uma das conclusões mais importantes.
Se a ação maliciosa parece uma ação autorizada, detecção fica difícil.
Por isso precisamos de contexto.
Quem normalmente faz isso?
Em qual horário?
Com qual frequência?
De qual dispositivo?
Em qual volume?
Depois de qual evento?
Segurança não pode olhar apenas para:
ALLOW
DENY
Precisa olhar para comportamento.
🔵 Rooney versus o computador
Voltemos a Rooney.
Ele possui intuição.
O computador possui registro.
A segurança madura precisa dos dois.
Dados.
Contexto.
Automação.
Experiência humana.
Nenhum deveria dominar cegamente.
Rooney também pode estar errado.
Sua obsessão por Ferris prova isso.
Mas o computador também pode.
A chave é não transformar nenhuma fonte em autoridade absoluta.
☕ “Está no sistema” não significa “é verdade”
Essa frase deveria estar impressa em muitas salas de operação.
Talvez em letras grandes.
Porque sistemas registram aquilo que conseguimos observar.
E aquilo que alguém informou.
E aquilo que integrações enviaram.
E aquilo que processos permitiram.
Eles não possuem acesso mágico à realidade.
Então sempre precisamos perguntar:
Como esse dado nasceu?
Quem pode alterá-lo?
Como validamos?
Como auditamos?
Como detectamos inconsistências?
🔴 Integridade é confiança verificável
No final, integridade significa uma coisa muito simples:
poder confiar que informação não foi alterada de maneira indevida.
Mas “confiar” não pode significar fé.
Precisa existir evidência.
Controles.
Logs.
Reconciliação.
Segregação.
Revisão.
Detecção.
E capacidade de reconstruir eventos.
🎬 Ferris Bueller e o primeiro ataque à verdade digital
Talvez Ferris não tivesse percebido a profundidade filosófica do que estava fazendo.
Provavelmente só queria matar aula.
Mas aquele computador escolar antecipou um problema que cresceria enormemente nas décadas seguintes.
O mundo passou a depender cada vez mais de registros digitais.
Dinheiro virou registro.
Identidade virou registro.
Propriedade virou registro.
Saúde virou registro.
Reputação virou registro.
Autorizações viraram registros.
E quanto mais a sociedade digitaliza, maior fica o valor de alterar silenciosamente aquilo que ela acredita ser verdade.
☕ Epílogo: nove faltas desapareceram
Rooney olha para Ferris.
Ferris olha para o computador.
O computador olha para ninguém.
Ele apenas executa comandos.
Essa talvez seja a parte mais importante.
A máquina não sabe que está mentindo.
Ela não sabe que está dizendo a verdade.
Ela simplesmente armazena estado.
Nós é que atribuímos confiança.
E é exatamente essa confiança que Red Team deve testar.
Porque entre:
REALITY
e:
DATABASE
existe sempre um caminho.
Alguém coleta.
Alguém transmite.
Alguém grava.
Alguém altera.
Alguém consulta.
Alguém interpreta.
Cada etapa pode falhar.
Cada etapa pode ser abusada.
Cada etapa pode virar uma porta.
Então da próxima vez que alguém disser:
“Mas está no sistema.”
Sirva outro café.
Olhe para Ferris.
E faça a pergunta mais importante:
“Quem disse ao sistema que isso era verdade?”
☕ SAVE FERRIS.
No próximo artigo:
Abe Froman, o Rei da Salsicha de Chicago — A Aula de Engenharia Social que Ninguém Percebeu
Porque talvez você não precise hackear um banco de dados.
Talvez precise apenas convencer alguém de que você deveria estar sentado naquela mesa.
☕ Um Café no Bellacosa Mainframe — Especial Red Team
SAVE FERRIS — Ferris Bueller’s Red Team
Uma série de 12 artigos sobre Red Team, segurança ofensiva,
engenharia social, OSINT, integridade de dados, MFA, PAM,
rollback, Blue Team, inteligência artificial, RACF e z/OS,
usando Ferris Bueller para explorar uma pergunta fundamental:
o sistema está realmente seguro ou apenas acredita que está?
Red Team
OSINT
Engenharia Social
Blue Team
MFA
PAM
IA Generativa
RACF
z/OS
Mainframe
1
Ferris Bueller Tinha um Plano de Ataque — Red Team Antes de Existir Red Team
Reconhecimento, criatividade adversarial e a ideia de que
o verdadeiro alvo nem sempre é a tecnologia:
são as suposições de quem construiu o sistema.
Red Team • Recon • Threat Modeling • Criatividade Adversarial
Nove Faltas? CTRL+Z — Quando o Banco de Dados Decide o que é Verdade
Integridade de dados, alteração de registros, privilégio,
auditoria e a perigosa diferença entre aquilo que aconteceu
e aquilo que o banco de dados afirma ter acontecido.
Integridade • Db2 • Auditoria • Insider Threat • Dados
Cameron, Atenda o Telefone — Social Engineering as a Service
Ferris → Cameron → telefone → escola → funcionário → sistema.
Nenhuma peça precisa falhar sozinha quando a cadeia inteira
possui uma combinação explorável de confiança.
Social Engineering • Swiss Cheese Model • Human Risk
O Diretor Rooney Está Procurando Malware no Lugar Errado
Firewall, SIEM, EDR e Zero Trust podem funcionar perfeitamente
enquanto engenharia social, Help Desk e processos humanos
criam outro caminho até o objetivo.
Privilégio, acesso físico, MFA, PAM, least privilege e o risco
de proteger um ativo crítico apenas com medo, confiança
e a esperança de que ninguém ousará tocá-lo.
Colocamos a Ferrari em Ré — Por Que Rollback Não É Backup
Rollback, restore, journaling, logs, Db2, VSAM e recuperação:
voltar o estado de um sistema não significa apagar
as consequências daquilo que aconteceu.
“A Vida Passa Muito Rápido” — O Red Team Depois que Todo Mundo Foi Embora
Red Team não termina em “conseguimos entrar”.
Ataque deve gerar descoberta, evidência, correção,
detecção e aprendizado para deixar a organização mais resiliente.
Red Teaming • Purple Team • Detection • Resilience • Learning
Ferris Bueller’s Red Team: Como Hackear o Sistema
Sem Precisar Roubar a Ferrari do Cameron
reúne os doze episódios e conecta Red Team,
engenharia social, IA, Blue Team e segurança de mainframe.
A série SAVE FERRIS, publicada no
Bellacosa Mainframe, utiliza situações inspiradas
em Ferris Bueller para explicar conceitos de
Red Team, cybersecurity, segurança ofensiva,
engenharia social, OSINT, Blue Team, Purple Team,
Zero Trust, MFA, PAM, inteligência artificial,
RACF, IBM z/OS, CICS, Db2, MQ e segurança de mainframe.
O fio condutor é simples: um atacante não precisa necessariamente
quebrar a tecnologia. Ele pode explorar relações de confiança,
processos, identidades, privilégios, integrações e suposições
existentes entre pessoas e sistemas.
A temporada acompanha o ciclo completo:
reconhecimento → engenharia social → acesso →
privilégio → impacto → detecção → correção → aprendizado.
Para Red Teams e Blue Teams, o objetivo final não é provar
quem é mais inteligente, mas encontrar caminhos invisíveis
antes que um adversário real os descubra.
Bellacosa Mainframe e a jornada do engenheiro de performance em mainframe
☕ Um Café no Bellacosa Mainframe
A Jornada do Engenheiro de Performance em Mainframe
Quando um Cadete Embarca no USS Seaview e Descobre que o Verdadeiro Tesouro Não Está no Fundo do Oceano... Está Escondido Entre Milhões de Métricas do IBM Z
"Profundidade: 10.000 metros."
"Motores nucleares operando normalmente."
"Sonar ativo."
"Todos os sensores reportando dados."
O Capitão Lee Crane olha para o jovem cadete recém-chegado ao USS Seaview.
— Você sabe pilotar um submarino?
— Não, senhor.
— Então sabe interpretar o sonar?
— Ainda não.
— Conhece oceanografia?
— Também não.
O capitão sorri.
— Excelente. Você está exatamente onde todo grande engenheiro começou.
Essa pequena cena resume perfeitamente a Engenharia de Performance em Mainframe.
Ninguém nasce sabendo interpretar RMF.
Ninguém entende SMF na primeira semana.
Ninguém olha um relatório de WLM e imediatamente identifica um problema.
Tudo isso é aprendido.
E existe um caminho.
Este artigo é exatamente esse mapa.
Não um curso.
Mas um roteiro de formação para transformar um programador COBOL em um verdadeiro Engenheiro de Performance IBM Z.
A Grande Verdade
Existe uma diferença enorme entre:
Fazer um programa funcionar
e
Entender como o computador inteiro funciona.
O programador escreve aplicações.
O engenheiro de performance compreende o ecossistema inteiro.
Ele precisa enxergar aquilo que ninguém vê.
Enquanto um desenvolvedor observa:
READ CLIENTE
O especialista imagina imediatamente:
Quantos EXCPs isso gera?
O dataset está em cache?
Existe contenção?
O Buffer Pool está adequado?
O Storage está respondendo normalmente?
Esse acesso poderia usar Sequential Detection?
Existe leitura desnecessária?
É outro universo.
A Mentalidade Correta
Antes dos livros...
antes dos cursos...
antes das ferramentas...
é preciso desenvolver uma nova forma de pensar.
O engenheiro de performance não pergunta:
"Como resolver?"
Ele pergunta:
"Por que isso aconteceu?"
Essa simples mudança muda toda a carreira.
O Primeiro Ano
Imagine que você acabou de embarcar no Seaview.
Ninguém coloca um novato para controlar o reator nuclear.
Primeiro ele aprende o navio.
No IBM Z acontece exatamente o mesmo.
Etapa 1
Aprenda o Sistema Operacional
Antes de qualquer ferramenta...
aprenda z/OS.
Muito bem.
Estude:
IPL
Address Space
TCB
SRB
Dispatching
Cross Memory
Storage
Virtual Storage
Paging
Swapping
CSA
SQA
ECSA
Link Pack Area
APF
Catalog
SMS
JES2
JES3
Sem isso...
todo o restante fica confuso.
Por quê?
Porque performance nunca acontece apenas no COBOL.
Ela acontece dentro do z/OS.
Etapa 2
Aprenda Arquitetura IBM Z
Conheça profundamente:
CPC
↓
Drawer
↓
Books
↓
CP
↓
zIIP
↓
ICF
↓
SAP
↓
LPAR
↓
PR/SM
↓
Channel Subsystem
↓
OSA
↓
FICON
↓
Coupling Facility
↓
Memory
↓
Cache
↓
HMC
↓
SE
Imagine o Seaview.
Antes de mergulhar você precisa conhecer:
motores
hélices
sonar
casco
radar
reator
O IBM Z também é um navio.
Etapa 3
CPU
Aqui começa o verdadeiro mundo da performance.
Aprenda:
CPU Time
Elapsed Time
Dispatch Time
Wait Time
SRB Time
TCB Time
PR/SM
Weight
LPAR
Logical CPU
Physical CPU
SMT
Vertical High
Vertical Medium
Vertical Low
Entenda:
GCP
zIIP
IFL
ICF
SAP
Nunca mais olhe apenas:
CPU = 90%
Pergunte:
90% de quê?
Etapa 4
Memória
Aprenda:
Frames
Pages
Paging
Working Set
Central Storage
Expanded Storage (história)
Auxiliary Storage
Frames Reais
Virtual Storage
Buffer Pool
Hiperspace
Data Spaces
Memory Objects
A memória explica inúmeros problemas aparentemente "misteriosos".
Etapa 5
I/O
Talvez o assunto mais importante.
Estude:
Channel
CU
Device
Volume
Cache
FICON
IOSQ
Pending
Connect
Disconnect
Response Time
EXCP
DASD
FlashSystem
RAID
Storage Class
SMS
Cache Miss
Write Pending
Buffering
Sem dominar I/O...
não existe engenheiro de performance.
Easter Egg
Na série Viagem ao Fundo do Mar...
o sonar era mais importante que o periscópio.
No Mainframe...
o I/O costuma ser mais importante que CPU.
Segundo Ano
Agora você começa a estudar subsistemas.
CICS
Aprenda:
Task
Transaction
Program
COMMAREA
Channel
Threadsafe
QR
L8
Open TCB
MXT
SOS
DSALIM
Storage
Temporary Storage
Transient Data
Journal
Mirror
TOR
AOR
FOR
Pipeline
IPIC
MRO
ISC
EXCI
Performance CICS é um universo inteiro.
Db2
Estude:
Access Path
RUNSTATS
REBIND
Package
Plan
RID List
Getpage
Prefetch
Index
Cluster Ratio
Lock
Latch
Buffer Pool
Sort
Stage 1
Stage 2
CPU SQL
RID Overflow
Parallelism
Dynamic SQL
Static SQL
Performance Db2 é quase uma especialização própria.
MQ
Aprenda:
Queue
Channel
Trigger
Persistent
Non Persistent
Commit
Rollback
Backout
Depth
Dead Letter Queue
Transmission Queue
Cluster
MQ também impacta performance.
IMS
Mesmo que nunca utilize...
conheça.
Principalmente:
DL/I
PSB
PCB
Database
Fast Path
Message Queue
TM
DB
WLM
Aqui mora a inteligência do z/OS.
Aprenda:
Service Class
Report Class
Velocity
Response Time
Importance
Goals
Classification
Policy
Performance sem WLM...
é impossível.
Ferramentas
Agora sim.
Chegou a hora.
RMF
Aprenda:
Monitor I
Monitor II
Monitor III
Postprocessor
Reports
SMF
Este será seu melhor amigo.
Conheça:
SMF 30
SMF 70
SMF 72
SMF 74
SMF 80
SMF 100
SMF 101
SMF 110
SMF 115
SMF 116
Cada registro conta uma história.
SDSF
Domine completamente.
Aprenda:
DA
ST
H
LOG
INPUT
OUTPUT
JESMSGLG
JESJCL
SYSOUT
OMEGAMON
Depois:
OMEGAMON
z/OS
CICS
Db2
MQ
Storage
Network
IntelliMagic Vision
Aprenda:
Health Insights
Topology
Trend
Change Detection
Capacity
Forecast
Anomaly
Correlation
Drill Down
Rating
É uma das ferramentas mais impressionantes existentes hoje.
Estatística
Surpresa.
Todo engenheiro de performance precisa entender estatística.
Não avançada.
Mas suficiente.
Estude:
Média
Moda
Mediana
Percentil
Desvio Padrão
Correlação
Distribuição
Outlier
Baseline
Forecast
Sazonalidade
Sem estatística...
não existe Capacity Planning.
Capacity Planning
Depois de dominar performance...
aprenda previsão.
Pergunte:
Quando acabará CPU?
Quando acabará memória?
Quando precisaremos de outro CPC?
Quando o licenciamento aumentará?
Como reduzir MSU?
Como aproveitar melhor zIIP?
Custos
Aqui está um assunto que quase ninguém ensina.
Performance também significa dinheiro.
Um SQL ruim pode custar milhares de horas de CPU por mês.
Um loop desnecessário pode aumentar MSUs.
Uma política WLM inadequada pode provocar desperdício.
Um buffer pool pequeno pode multiplicar leituras físicas.
Um zIIP subutilizado pode elevar custos de software.
O melhor engenheiro de performance pensa como um engenheiro e como um gestor.
O Que Ler
Monte sua biblioteca.
IBM Redbooks
IBM Documentation
RMF User Guide
SMF Manuals
Principles of Operation
DFSMS Redbooks
Db2 Performance Guides
CICS Performance Guide
WLM Redbooks
Enterprise COBOL Programming Guide
Arquitetura de Computadores
Sistemas Operacionais
Estatística
Filas
Teoria das Filas
Capacity Planning
AIOps
Observabilidade
O Que Praticar
Leia SMFs.
Analise RMFs.
Observe gráficos.
Faça comparações.
Monte dashboards.
Descubra gargalos.
Correlacione métricas.
Explique resultados.
Escreva relatórios.
Ensine outras pessoas.
Ensinar acelera o aprendizado.
O Perfil Ideal
O engenheiro de performance gosta de:
✔ investigar
✔ medir
✔ comparar
✔ questionar
✔ procurar padrões
✔ estudar arquitetura
✔ entender negócios
✔ resolver problemas difíceis
Ele é menos "programador".
E mais "cientista".
A Evolução da Carreira
O caminho normalmente segue algo parecido com:
Programador COBOL
↓
Programador Sênior
↓
Especialista CICS/Db2
↓
Analista Técnico
↓
Performance Analyst
↓
Capacity Planner
↓
System Performance Engineer
↓
IBM Z Architect
↓
Enterprise Performance Consultant
↓
Chief Performance Engineer
Não existe pressa.
Existe evolução contínua.
Curiosidades Bellacosa
☕ Um único dia de operação de um grande banco pode produzir milhões de registros SMF.
☕ Muitos problemas atribuídos ao COBOL têm origem em SQL, storage, WLM ou infraestrutura.
☕ O melhor relatório de performance é aquele que explica o impacto no negócio, não apenas os números.
☕ A maioria dos grandes especialistas em performance começou como programador ou operador e desenvolveu a capacidade de conectar métricas, arquitetura e processos de negócio.
☕ Ferramentas modernas como IBM Z IntelliMagic Vision aceleram a análise, mas não substituem o conhecimento de arquitetura. Elas ajudam o especialista a enxergar mais rápido, mas é o especialista quem transforma dados em decisões.
Missão Final – A Última Viagem do Seaview
Depois de anos estudando, você retorna ao centro de controle do USS Seaview.
O sonar detecta uma anomalia.
Os alarmes começam.
Todos olham para você.
Ninguém pergunta:
"Qual é a CPU?"
Perguntam:
"O que está acontecendo?"
Você consulta RMF, SMF, OMEGAMON, IntelliMagic Vision, WLM e os monitores dos subsistemas. Em poucos minutos percebe que o problema não está na CPU, nem no CICS, nem no Db2.
Um volume de storage apresenta aumento no tempo de resposta, gerando filas de I/O, elevando o tempo de espera das transações e causando degradação em cascata.
Você explica a causa, demonstra as evidências, estima o impacto no negócio e propõe a correção.
Nesse instante, você deixa de ser apenas um programador COBOL.
Você se torna um verdadeiro Engenheiro de Performance em Mainframe.
Porque, no universo Bellacosa Mainframe, performance não é decorar relatórios.
É aprender a ouvir o sonar invisível do IBM Z antes que o oceano inteiro perceba que existe um problema.
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
