✨ 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
 |
| So por diversao.
Humor e diversao... as vezes acontecem coisas em nossa cidade que ate duvidamos que seja verdade, esta pagina tem por objetivo retratar de forma humoristica algum acontecimento marcante... diariamente lendo jornais, blogs de opiniao e paginas de nossa cidade. Encontrado o furo, lapidamos e fazemos a piada... alguns gostam, outros odeiam... mas eh dificil ficar indiferente.
Pagina no Facebook para aqueles que curtem o Face
#ItatibaNoSeuMelhor
|
 |
| Bellacosa Mainframe e o plano de ataque de ferris bueller |
Chicago.
Década de 1980.
Computadores pessoais ainda tinham aquele ar de objeto mágico comprado por alguém que provavelmente também mantinha uma enciclopédia de 30 volumes na sala.
Não havia cloud.
Não havia SIEM.
Não havia EDR.
Não havia SOC 24x7.
Não havia dashboard piscando vermelho porque alguém da contabilidade tentou entrar no sistema às 03h17.
Não havia Zero Trust.
Também não havia LinkedIn dizendo exatamente onde você trabalha, qual tecnologia utiliza, qual certificação acabou de tirar, quem é seu gerente e qual projeto está colocando em produção na próxima terça-feira.
Mesmo assim, Ferris Bueller já havia entendido uma coisa que muita empresa ainda tenta aprender em 2026:
São feitos de pessoas.
Regras.
Rotinas.
Expectativas.
Horários.
Autoridade.
Confiança.
Telefonemas.
Burocracia.
E pequenas certezas que ninguém costuma questionar.
Ferris não precisava de um exploit de kernel.
Não precisava de malware.
Não precisava descobrir um buffer overflow.
Ele precisava apenas olhar para o mundo ao redor e perguntar:
“O que essas pessoas esperam que aconteça?”
E então fazer alguma coisa ligeiramente diferente.
Senhoras e senhores, bem-vindos ao primeiro episódio de:
Existe uma tendência quase infantil quando alguém começa a estudar segurança ofensiva.
A pessoa quer ferramentas.
Kali Linux.
Burp Suite.
Metasploit.
Nmap.
Hydra.
John the Ripper.
Wireshark.
E vinte abas abertas contendo comandos copiados de um tutorial.
Nada contra.
Ferramentas são importantes.
Mas Red Team começa antes.
Muito antes.
Começa com observação.
Ferris conhece o ambiente.
Ele conhece os pais.
Conhece a escola.
Conhece o diretor Rooney.
Conhece Cameron.
Conhece Sloane.
Conhece os horários.
Conhece os comportamentos esperados.
Sabe como um adolescente doente deveria parecer.
Sabe como adultos falam ao telefone.
Sabe quais histórias parecem plausíveis.
Sabe quem acredita em autoridade.
Sabe onde existe margem para improvisação.
Isso tem nome.
Quando falamos em reconhecimento em segurança, muita gente imediatamente pensa:
nmap -sV -O target
Excelente.
Você descobriu portas.
Ferris descobriria pessoas.
A diferença não é pequena.
Imagine uma organização.
Você pode saber que ela possui:
443/tcp open
22/tcp open
8443/tcp open
Muito útil.
Mas imagine saber também:
que o administrador principal está de férias;
que a equipe está no meio de uma migração;
que existe uma manutenção emergencial naquela noite;
que o fornecedor externo costuma telefonar para o Service Desk;
que o diretor financeiro está viajando;
que funcionários recebem instruções urgentes pelo WhatsApp;
que um projeto específico utiliza credenciais técnicas compartilhadas.
Agora a superfície de ataque começa a parecer diferente.
Portas são tecnologia.
Contexto é poder.
Uma vulnerabilidade tradicional costuma ser descrita assim:
Existe um comportamento inesperado no software que pode ser explorado.
Red Team amplia isso.
Também existe comportamento inesperado em organizações.
Um funcionário acredita que alguém falando com confiança deve saber o que está fazendo.
Um gerente acredita que um e-mail vindo de determinado endereço é confiável.
Um operador acredita que aquilo que aparece na tela corresponde à realidade.
Um administrador acredita que determinada conta nunca será usada indevidamente.
Um desenvolvedor acredita que uma API só será chamada pelo aplicativo oficial.
Essas crenças não aparecem no código.
Mas fazem parte do sistema.
Ferris é especialista nisso.
Ferris não controla tudo.
Ele prevê.
E previsão é extremamente poderosa.
Se você sabe que uma pessoa provavelmente reagirá de determinada maneira, você pode preparar o próximo movimento.
Pense como um atacante.
Se eu enviar esta solicitação, quem receberá?
Se chegar fora do horário comercial, haverá menos supervisão?
Se eu aparentar urgência, alguém pulará uma etapa?
Se eu mencionar o nome do gerente correto, minha história ficará mais convincente?
Se eu souber o jargão interno, parecerá que pertenço ao ambiente?
Perceba.
Até agora não atacamos nenhum computador.
Mas já estamos construindo um ataque.
Talvez essa seja uma definição melhor que muitas definições acadêmicas.
Red Team é a capacidade de olhar para um sistema e perguntar:
O desenvolvedor cria uma função.
O usuário utiliza a função.
O atacante pergunta:
“O que acontece se eu usar essa função para outra coisa?”
O RH cria um processo para redefinição de senha.
O funcionário legítimo usa o processo.
O atacante pergunta:
“Quais informações preciso saber para parecer o funcionário?”
A empresa cria uma API.
O aplicativo usa a API.
O atacante pergunta:
“A API sabe que sou o aplicativo?”
Essa mudança de perspectiva é gigantesca.
Toda arquitetura nasce com premissas.
Algumas são técnicas.
Outras sociais.
Imagine este desenho:
USER
↓
APPLICATION
↓
API
↓
DATABASE
Simples.
Seguro.
Bonito.
Arquitetura aprovada.
Ferris olha.
E pergunta:
Quem cria o usuário?
Quem redefine sua senha?
Quem administra a aplicação?
Quem configura a API?
Quem possui acesso ao banco?
Quem aprova mudanças?
Quem lê logs?
Quem pode desabilitar alertas?
Quem possui acesso de emergência?
Quem testa restore?
Quem trabalha no fornecedor?
Subitamente nosso belo desenho fica assim:
USER
↓
HELP DESK
↓
IDENTITY SYSTEM
↓
APPLICATION
↓
API
↓
SERVICE ACCOUNT
↓
DATABASE
↓
BACKUP
↓
ADMIN
↓
VENDOR
↓
CLOUD
Agora estamos chegando perto da realidade.
Nenhum controle precisa estar completamente quebrado.
Basta que pequenas falhas se alinhem.
Imagine:
O funcionário publica demais no LinkedIn.
A empresa utiliza perguntas previsíveis para recuperação de conta.
O Help Desk trabalha sob pressão.
Existe uma conta antiga com privilégio excessivo.
O SOC não monitora determinado horário.
Separadamente?
Talvez nada aconteça.
Juntos?
OSINT
↓
Pretexto
↓
Reset de senha
↓
Conta legítima
↓
Privilégio excessivo
↓
Sistema crítico
Nenhuma cena cinematográfica.
Nenhuma tela verde.
Nenhum crânio piscando.
Apenas pequenas permissões fazendo amizade umas com as outras.
Nós adoramos pensar em APIs.
Mas pessoas também possuem interfaces.
E muito menos documentação.
Uma pessoa recebe uma solicitação.
Analisa contexto.
Interpreta autoridade.
Avalia urgência.
Decide.
Essa decisão pode virar autorização.
Por isso engenharia social funciona.
Não porque humanos sejam estúpidos.
Mas porque sistemas humanos foram desenhados para colaborar.
Se toda solicitação fosse tratada como ataque, organizações parariam.
Ferris explora exatamente isso.
Ele não encontra uma pessoa burra.
Encontra uma pessoa cumprindo o papel esperado.
Olhe para a escola de Ferris como uma arquitetura corporativa.
Temos:
Alunos
Professores
Secretaria
Direção
Pais
Registros
Telefone
Computadores
Procedimentos
Autoridade
Isto é um sistema.
Ferris não precisa quebrar todas as partes.
Ele precisa compreender como elas interagem.
É exatamente isso que Red Team faz.
Não se trata apenas de:
“Consigo comprometer este servidor?”
A pergunta mais interessante é:
“Consigo atingir um objetivo usando qualquer combinação disponível?”
Essa mudança de linguagem é fundamental.
Uma operação Red Team deveria começar com um objetivo.
Por exemplo:
Obter acesso a determinado ambiente.
Não:
Usar phishing.
Phishing é técnica.
Talvez funcione.
Talvez não.
O objetivo permanece.
Então podemos tentar:
credenciais vazadas;
engenharia social;
exposição externa;
misconfiguração;
cadeia de fornecedores;
processos de recuperação;
acesso físico;
tokens;
integrações;
privilégios excessivos.
O atacante real não recebe KPI dizendo:
“Utilizar obrigatoriamente Metasploit em 37% da operação.”
Ele quer chegar ao objetivo.
Ferris também.
Empresas costumam proteger aquilo que consideram importante.
Servidor principal?
Protegido.
Banco de dados?
Protegido.
Firewall?
Protegido.
Ferris pergunta:
Uma impressora.
Um fornecedor.
Uma aplicação antiga.
Uma conta esquecida.
Uma VPN temporária.
Um endpoint de teste.
Uma integração criada durante pandemia.
Um funcionário terceirizado.
Um sistema legado.
Uma API mobile.
Um pipeline CI/CD.
Um chatbot.
Agora começamos a entender por que superfície de ataque cresce tão rápido.
Agora entramos no Bellacosa Mainframe propriamente dito.
Quando alguém pensa em atacar mainframe, frequentemente imagina:
HACKER
↓
3270
↓
TSO
↓
RACF
↓
z/OS
Talvez.
Mas Ferris provavelmente escolheria outra rota.
Ele perguntaria:
Quem conversa com o mainframe?
Talvez:
Mobile App
↓
API Gateway
↓
z/OS Connect
↓
CICS
↓
COBOL
↓
Db2
Ou:
Cloud
↓
MQ
↓
Mainframe
Ou:
Git
↓
Pipeline
↓
Build
↓
Deploy
↓
z/OS
O ambiente principal pode possuir controles extraordinários.
Mas o atacante pode preferir comprometer a confiança ao redor dele.
É mais Ferris.
Menos Hulk.
Essa frase merece moldura.
Imagine que Ferris deseja acessar um dataset.
Ele pode tentar quebrar RACF.
Difícil.
Ou encontrar uma conta legítima que já possui acesso.
Muito mais interessante.
Por isso identidade é tão importante.
O atacante não quer necessariamente destruir o controle de segurança.
Muitas vezes quer ser confundido com alguém autorizado.
Quando isso acontece, o sistema funciona perfeitamente.
E esse é o problema.
O Ferris de 1986 trabalhava artesanalmente.
Observação manual.
Telefone.
Computador.
Improviso.
Conhecimento social.
O Ferris moderno teria ferramentas capazes de acelerar partes desse processo.
Análise de grandes volumes de informação.
Correlação de dados públicos.
Geração de mensagens.
Automação.
Agentes.
Reconhecimento de padrões.
Isso não elimina a necessidade de criatividade adversarial.
Amplifica.
A pessoa ainda precisa fazer a pergunta certa.
IA pode encontrar cem informações.
Ferris precisa perceber quais três formam uma história convincente.
Não é ferramenta.
É imaginação disciplinada.
Veja a combinação aparentemente banal:
Informação pública
+
comportamento previsível
+
processo legítimo
+
credencial válida
+
privilégio acumulado
Pode não existir CVE para isso.
Pode não existir patch.
Pode não existir assinatura no antivírus.
Mas existe risco.
E esse tipo de coisa é exatamente onde Red Team brilha.
Uma frase adorável.
Também perigosíssima.
Não ter evidência de invasão não significa necessariamente que seu sistema é seguro.
Pode significar:
ninguém tentou;
ninguém percebeu;
ninguém registrou;
ninguém correlacionou;
o atacante desistiu;
o atacante passou despercebido.
Ferris poderia passar o dia inteiro fora da escola.
Se ninguém verificasse corretamente, o sistema permaneceria convencido de que tudo estava normal.
Rooney sabe que Ferris está fazendo alguma coisa.
Mas concentra-se em Ferris como pessoa.
Isso pode virar uma forma de tunnel vision.
Em segurança, acontece algo semelhante.
A equipe possui uma hipótese.
Procura evidências dessa hipótese.
Ignora caminhos alternativos.
Um Red Team serve justamente para bagunçar essas certezas.
Talvez o ataque não venha de onde imaginávamos.
Talvez o controle mais caro não seja relevante.
Talvez o problema esteja naquele processo humilde que ninguém revisa desde 2009.
Aqui está o coração deste artigo.
Ferris não é perigoso porque possui uma ferramenta excepcional.
Ele é perigoso porque combina coisas comuns.
Telefone.
Computador.
Conhecimento.
Pessoas.
Rotina.
Autoridade.
Timing.
Individualmente, nenhuma é suficiente.
Juntas, produzem o efeito.
Em segurança chamamos isso de attack chain.
Ou, dependendo do contexto, attack path.
O atacante percorre pequenos passos.
Reconhecimento.
Acesso inicial.
Execução.
Persistência.
Escalada.
Movimento.
Objetivo.
O cinema gosta do clique mágico.
A realidade gosta de encadeamento.
Se eu estivesse numa War Room avaliando segurança de qualquer ambiente, eu faria uma pergunta simples:
Depois listaria.
Usuários não compartilham senha.
Administradores revisam privilégios.
Logs permanecem íntegros.
Backups funcionam.
Fornecedores não são comprometidos.
APIs validam identidade corretamente.
Credenciais técnicas não vazam.
Funcionários reconhecem tentativas de fraude.
IA não executa instruções maliciosas.
Ótimo.
Agora o Red Team começa a trabalhar.
Uma por uma.
Blue Team constrói controles.
Red Team testa controles.
Mas o melhor trabalho acontece quando testamos também certezas.
Você acredita que ninguém consegue alterar determinado dado?
Teste.
Acredita que o SOC detectará um comportamento?
Teste.
Acredita que MFA bloqueará um atacante?
Teste.
Acredita que um funcionário nunca liberaria determinada informação?
Teste de forma autorizada e segura.
Acredita que o mainframe está isolado?
Mapeie integrações.
Acredita que um agente de IA não pode executar determinada ação?
Valide.
Segurança baseada em esperança é apenas esperança usando crachá corporativo.
Ferris não estudou MITRE ATT&CK.
Não possui OSCP.
Não abriu Kali Linux.
Não rodou Cobalt Strike.
Mas demonstra algo anterior a todas essas ferramentas:
pensamento adversarial.
Ele observa regras.
Entende expectativas.
Identifica fragilidades.
Combina recursos.
Prevê reações.
Adapta o plano.
E busca resultado.
Quase quarenta anos depois, essa mentalidade continua no centro de qualquer bom Red Team.
Porque o melhor atacante talvez não seja quem conhece mais comandos.
Pode ser quem olha para um ambiente complexo e percebe:
“Vocês estão protegendo a coisa errada.”
Talvez seja por isso que Ferris continue tão divertido.
Ele percebe que instituições possuem regras.
Mas também percebe que regras dependem de modelos mentais.
A escola acredita conhecer seus alunos.
Os pais acreditam conhecer o filho.
O diretor acredita conhecer o comportamento de Ferris.
O sistema acredita conhecer o número de faltas.
Ferris testa cada uma dessas certezas.
Isso é Red Team.
Não destruir o sistema.
Não atacar por atacar.
Mas descobrir:
onde termina a realidade e começa a confiança na representação da realidade.
Em mainframe.
Em cloud.
Em redes.
Em IA.
Em pessoas.
Em 1986.
Em 2026.
A tecnologia muda.
A pergunta permanece.
Se sua arquitetura não possui resposta, talvez Ferris já esteja alguns passos à frente.
Enquanto Rooney procura por ele no corredor.
Enquanto Cameron atende o telefone.
Enquanto Sloane espera.
Enquanto o computador da escola continua tranquilamente executando suas rotinas.
E enquanto seu SOC exibe, orgulhosamente:
SECURITY STATUS: GREEN
ACTIVE INCIDENTS: 0
Ferris olha para a câmera.
Sorri.
E desaparece pela porta.
☕ SAVE FERRIS.
No próximo café:
Porque se o sistema diz que Ferris esteve na escola...
quem somos nós para discutir com o computador?
☕ Um Café no Bellacosa Mainframe — Especial 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á?
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.
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.
Pretexting, autoridade inventada e confiança contextual: Identity, Authentication e Authorization não são a mesma coisa.
Como dados públicos sobre pessoas, tecnologias, hábitos, empresas e relacionamentos podem revelar uma superfície de ataque antes do primeiro scan.
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.
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.
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.
Confirmation Bias, tunnel vision, Sunk Cost, Authority Gradient e o risco de uma resposta defensiva criar mais impacto que o próprio atacante.
IA generativa, agentes, OSINT automatizado, deepfake, voice cloning e automação transformam o ataque artesanal em uma capacidade paralela e escalável.
RACF, SAF, ACEE, APF, USS, TSO, CICS, Db2, MQ, z/OS Connect, Zowe e service accounts vistos pela ótica dos caminhos de ataque até o mainframe.
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.
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.
☕ Acessar o especial completo SAVE FERRISA 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 engenharia de performance no mainframe |
O painel do submarino começa a piscar.
Uma luz amarela acende na sala de controle.
Depois outra.
No sonar, um objeto gigantesco se aproxima lentamente pelo lado de boreste.
O Capitão pergunta:
— É uma criatura marinha?
O operador responde:
— Negativo, senhor. Parece uma fila de I/O crescendo no volume de produção.
O Almirante observa os instrumentos, ajusta os óculos e diz:
— Então chamem o engenheiro de performance. E tragam café.
Bem-vindo à Engenharia de Performance em Mainframe, uma disciplina em que números aparentemente inocentes podem esconder problemas capazes de afetar milhões de transações, atrasar processamento batch, aumentar custos de software e transformar uma madrugada tranquila em uma expedição ao fundo do oceano.
Para um programador COBOL iniciante, performance pode parecer assunto exclusivo de sysprog, especialista de capacidade ou administrador de sistemas. Mas isso é um erro.
Seu programa consome CPU.
Seu programa faz I/O.
Seu programa acessa Db2, VSAM, IMS, MQ e CICS.
Seu programa pode gerar contenção, espera, filas, locks, page-ins, excesso de logging, leitura desnecessária e milhões de instruções que ninguém percebeu durante os testes.
Portanto, entender Engenharia de Performance não é abandonar o COBOL.
É aprender a enxergar o mundo que existe abaixo de cada READ, cada WRITE, cada EXEC CICS, cada SELECT e cada CALL.
Engenharia de Performance é o conjunto de práticas usadas para medir, analisar, prever, otimizar e controlar o comportamento de sistemas computacionais.
No mainframe, ela procura responder perguntas como:
O sistema está entregando o tempo de resposta esperado?
Existe capacidade suficiente para o crescimento?
Qual workload está consumindo mais recursos?
O problema está na aplicação, no sistema operacional, no banco, no storage ou na rede?
A utilização atual é normal?
Existe uma tendência de saturação?
Quanto custa essa ineficiência?
O ambiente sobreviverá ao próximo fechamento mensal?
O novo release aumentou CPU?
O zIIP está sendo bem utilizado?
O WLM está protegendo as aplicações críticas?
Engenharia de Performance não é simplesmente olhar um gráfico de CPU.
É entender a relação entre:
carga + recursos + prioridade + arquitetura + tempo + custo + impacto no negócio.
No Seaview, não basta saber a profundidade.
É necessário saber a pressão do casco, a velocidade, o combustível, a direção da corrente, a temperatura da água e a distância até o próximo porto.
No IBM Z acontece exatamente o mesmo.
Muita gente usa “performance” como sinônimo de rapidez.
Mas performance é mais ampla.
Um sistema pode ser rápido e mesmo assim ser ineficiente.
Imagine um programa COBOL que termina em dois minutos, mas consome uma quantidade absurda de CPU. Talvez ele pareça rápido porque o mainframe possui muita capacidade disponível. Porém, quando centenas de programas semelhantes executarem ao mesmo tempo, o problema aparecerá.
Da mesma forma, um sistema pode ter baixa CPU e apresentar péssimo tempo de resposta porque está esperando por:
I/O;
locks;
ENQ;
storage;
rede;
fila MQ;
Db2;
VSAM;
tape;
outro address space;
tarefa serializada;
serviço externo.
A primeira grande lição é esta:
CPU alta não significa necessariamente problema, e CPU baixa não significa necessariamente saúde.
O profissional de performance atua em várias frentes.
Ele acompanha o ambiente continuamente.
Observa:
consumo de GCP;
consumo de zIIP;
utilização de LPAR;
peso de partição;
dispatch time;
paging;
I/O;
response time;
filas;
WLM;
service classes;
storage;
CICS;
Db2;
IMS;
MQ;
batch;
redes;
Coupling Facility.
O objetivo é perceber desvios antes que o usuário perceba.
Quando ocorre lentidão, timeout, abend em massa, filas ou degradação, o especialista procura a causa.
Ele pergunta:
Quando começou?
O que mudou?
Quais sistemas foram afetados?
Foi geral ou localizado?
O problema é recorrente?
Existe correlação com deploy, batch, fechamento ou pico de usuários?
Houve alteração de configuração?
Algum recurso ficou saturado?
Aqui o foco deixa de ser apenas “o que está acontecendo?” e passa a ser:
“O que acontecerá daqui a três, seis ou doze meses?”
O especialista analisa crescimento, sazonalidade, novas aplicações, migrações, aquisições e projeções de negócio.
No mainframe, performance e custo caminham juntos.
Um programa que utiliza CPU demais pode aumentar o custo de software.
Uma consulta Db2 mal desenhada pode consumir milhões de instruções desnecessárias.
Um workload que poderia usar zIIP pode acabar executando em GCP.
Um fechamento mal planejado pode elevar o pico mensal de consumo.
O engenheiro de performance não procura apenas velocidade.
Procura eficiência econômica.
Antes e depois de uma mudança, ele compara resultados.
Exemplos:
nova versão do compilador COBOL;
mudança de índices Db2;
novo release de CICS;
atualização de z/OS;
aumento de memória;
mudança de WLM;
alteração de topology;
migração de storage;
nova política de batch;
modernização para API.
A rotina varia conforme a empresa, mas geralmente começa pela observação da saúde do ambiente.
Imagine o engenheiro chegando à sala de controle do Seaview.
Ele não começa desmontando o motor.
Primeiro, olha os instrumentos.
Normalmente verifica:
incidentes da madrugada;
jobs que atrasaram;
batch critical path;
picos de CPU;
uso de zIIP;
filas de I/O;
tempo de resposta CICS;
threads Db2;
locks e deadlocks;
filas MQ;
paging;
alertas de storage;
goals perdidos pelo WLM.
Também compara com o comportamento esperado.
Se o fechamento mensal sempre eleva a CPU, isso pode ser normal.
Se uma terça-feira comum apresenta o mesmo pico de um fechamento, algo precisa ser investigado.
O especialista participa de reuniões com:
aplicações;
infraestrutura;
banco de dados;
storage;
redes;
capacity planning;
gestão;
arquitetura;
fornecedores.
Ele traduz linguagem técnica para impacto de negócio.
Não basta dizer:
“houve aumento de 22% no dispatch time”.
É necessário explicar:
“o aumento ocorreu no período de maior volume, afetou o tempo de resposta do serviço de pagamentos e pode comprometer o SLA caso o crescimento continue”.
Pode gerar relatórios, registrar conclusões, revisar mudanças e atualizar previsões.
Uma análise que não é documentada tende a ser esquecida.
E um problema esquecido costuma voltar.
O mainframe é provavelmente uma das plataformas mais instrumentadas da história da computação.
Ele gera telemetria detalhada há décadas.
O System Management Facility é o grande diário de bordo do z/OS.
Registra uma enorme variedade de eventos e medições.
Há registros para:
jobs;
steps;
CPU;
datasets;
Db2;
CICS;
MQ;
WLM;
storage;
segurança;
rede;
hardware;
utilização de processadores.
Para o engenheiro de performance, SMF é ouro.
Sem dados históricos, muitas conclusões viram opinião.
O Resource Measurement Facility ajuda a medir recursos do sistema.
Ele oferece informações sobre:
CPU;
memória;
paging;
I/O;
channels;
Coupling Facility;
workload;
delays;
utilização de dispositivos.
O RMF é como o conjunto de sensores da sala de máquinas.
Permite observar comportamento mais próximo do tempo real.
É muito útil durante incidentes.
Você pode investigar quem está esperando, qual workload está atrasado e onde existe contenção.
CICS, Db2, IMS, MQ, storage e redes também possuem seus próprios monitores e registros.
É por isso que performance exige visão integrada.
Um problema no CICS pode ter origem no Db2.
Um problema no Db2 pode ter origem no storage.
Um problema no storage pode refletir em timeouts na aplicação.
Tudo está conectado.
Cada empresa utiliza um conjunto diferente, mas algumas categorias aparecem com frequência.
São a base da análise de performance no z/OS.
Muito usado para monitoramento de:
z/OS;
CICS;
Db2;
IMS;
MQ;
storage;
redes.
Ajuda a visualizar métricas, alertas e problemas em tempo próximo do real.
Transforma grandes volumes de dados operacionais em análises visuais, correlações, Health Insights, tendências e detecção de mudanças.
Sua força está em reunir dados de diversas áreas e aplicar conhecimento especializado.
Ajuda na análise histórica, relatórios e planejamento.
Possui soluções para monitoramento, automação, performance e gestão operacional.
Inclui ferramentas de monitoramento, performance, automação e capacity management.
Embora não seja uma plataforma completa de performance, o SDSF é fundamental para analisar jobs, address spaces, utilização e situações operacionais.
Essenciais para investigar:
SQL;
threads;
locks;
buffer pools;
getpages;
I/O;
accounting;
statistics.
Ajuda a entender transações CICS, tempo de resposta, CPU, waits e comportamento das tarefas.
CPU é importante, mas deve ser analisada com contexto.
Os General Purpose Processors executam a maior parte do trabalho tradicional.
O especialista observa:
utilização média;
picos;
distribuição entre LPARs;
CPU por workload;
CPU por job;
CPU por transação;
CPU por programa;
crescimento histórico.
O zIIP executa workloads elegíveis, como partes de Db2, Java, XML, criptografia e outros componentes.
É importante analisar:
quanto trabalho é elegível;
quanto está realmente executando no zIIP;
quanto está transbordando para GCP;
se existe capacidade suficiente de zIIP;
se aplicações poderiam aproveitar mais esse recurso.
Um ambiente com zIIP saturado pode enviar trabalho elegível para processadores gerais, aumentando custos.
É o tempo em que uma unidade de trabalho realmente executa em processador.
Se o workload está pronto, mas não recebe CPU, pode haver atraso de dispatch.
Uma LPAR pode estar muito ocupada enquanto o CPC ainda possui capacidade.
Ou o CPC inteiro pode estar perto do limite.
São situações diferentes.
No z/OS, memória insuficiente pode gerar paging.
Paging significa que páginas de memória precisam ser movidas entre armazenamento central e auxiliar.
Algum paging pode ser normal.
Paging excessivo é como obrigar a tripulação do Seaview a buscar cada ferramenta em um depósito localizado três compartimentos abaixo.
O especialista observa:
page-ins;
page-outs;
frames;
storage central;
auxiliary storage;
working sets;
utilização por address space;
pressão de memória;
storage shortages.
Em CICS, também é necessário observar áreas como DSAs.
Em Db2, buffer pools são fundamentais.
I/O é uma das áreas mais importantes.
Um programa pode estar usando pouca CPU porque passa quase todo o tempo esperando dados.
Métricas comuns incluem:
I/O rate;
response time;
connect time;
disconnect time;
pending time;
IOSQ time;
cache hit;
quantidade de operações;
concentração por volume;
concentração por device;
throughput.
Representa espera na fila do subsistema de I/O.
Se muitos pedidos aguardam para usar o mesmo recurso, IOSQ pode crescer.
Pode indicar espera antes que a operação seja atendida.
É o tempo de transferência efetiva.
Pode envolver períodos em que o dispositivo não está conectado ao canal durante a operação.
A relação entre esses tempos ajuda a descobrir onde está o atraso.
No CICS, o especialista verifica:
response time;
dispatch time;
suspend time;
CPU por transação;
quantidade de tasks;
MXT;
storage;
waits;
file control;
Db2 calls;
MQ calls;
temporary storage;
transient data;
program loads;
abends;
transaction rate.
Um tempo de resposta alto pode ser dividido em partes.
Talvez a transação tenha executado apenas 20 milissegundos de CPU, mas esperado dois segundos por Db2.
Logo, otimizar o COBOL pode não resolver.
É necessário identificar onde a transação ficou suspensa.
Db2 merece uma expedição própria.
Os principais pontos incluem:
SQL com maior CPU;
SQL com maior elapsed time;
getpages;
synchronous reads;
dynamic prefetch;
buffer pool hit ratio;
locks;
suspensions;
deadlocks;
timeouts;
sort;
package;
thread;
commit frequency;
logging;
uso de índice;
acesso tablespace scan.
Uma instrução SQL aparentemente simples pode provocar milhões de getpages.
Um índice ausente pode transformar uma busca seletiva em varredura completa.
Um commit mal posicionado pode causar logging excessivo.
Nunca otimize SQL olhando apenas o texto.
Olhe também:
access path;
cardinalidade;
estatísticas;
frequência;
volume;
custo acumulado.
Um SQL que custa pouco, mas executa 10 milhões de vezes, pode ser mais importante que um SQL caro executado uma vez.
Em VSAM, observe:
EXCP;
CI splits;
CA splits;
free space;
bufferização;
número de acessos;
acesso sequencial ou aleatório;
tamanho do cluster;
distribuição de chaves;
reorganização;
sharing;
RLS.
Um KSDS com muitos splits pode sofrer degradação progressiva.
Um programa que faz leituras aleatórias em massa pode gerar enorme I/O.
Uma chave mal distribuída pode concentrar atividade.
Quando chega a mensagem clássica:
“O sistema está lento.”
Não comece alterando parâmetros.
Comece investigando.
“Lento” significa o quê?
tela demorando?
batch atrasando?
timeout?
CPU alta?
fila crescendo?
relatório demorando?
apenas um usuário?
todos os usuários?
Sem delimitar o problema, você investiga o oceano inteiro.
Determine:
horário;
duração;
frequência;
recorrência;
relação com mudança;
relação com pico de negócio.
Foi afetado:
um programa?
uma transação?
um CICS?
uma LPAR?
um Sysplex?
toda a empresa?
Use períodos equivalentes.
Compare terça com terça.
Fechamento com fechamento.
Horário comercial com horário comercial.
Comparações ruins geram conclusões ruins.
Verifique:
deploy;
parâmetros;
WLM;
índices;
volume;
hardware;
storage;
rede;
políticas;
releases;
crescimento de dados.
Tempo total pode ser dividido em:
CPU;
I/O;
lock;
queue;
dispatch;
network;
subsystem;
application wait.
Descubra onde o tempo foi gasto.
Não olhe métricas isoladamente.
Exemplo:
response time aumentou;
CPU não aumentou;
IOSQ aumentou;
storage response piorou;
batch iniciou no mesmo horário.
Agora existe uma hipótese forte.
Não pare na primeira coincidência.
Confirme com evidências.
Faça uma mudança por vez, quando possível.
Caso contrário, você não saberá qual ação resolveu o problema.
Sem medição posterior, não existe prova de melhoria.
No IBM Z, consumo técnico pode virar custo financeiro.
Considere um programa batch que consome 5% a mais de CPU depois de uma alteração.
Parece pouco.
Mas, se ele executa diariamente, em múltiplas LPARs e durante o pico, pode influenciar:
licenciamento;
capacidade contratada;
necessidade de upgrade;
consumo mensal;
janela batch;
risco operacional.
Imagine que uma otimização evite a ativação antecipada de capacidade adicional.
Ela pode representar economia de centenas de milhares ou até milhões de reais ao longo do tempo.
Não porque o COBOL ficou “mais elegante”, mas porque o sistema passou a usar menos recursos para entregar o mesmo resultado.
Há também custos indiretos:
cliente esperando;
transação abandonada;
SLA violado;
batch que invade horário comercial;
equipe mobilizada em incidente;
multas;
indisponibilidade;
desgaste da marca.
Performance é uma disciplina técnica com impacto financeiro direto.
Para um programador COBOL iniciante, o caminho pode ser gradual.
Aprenda a responder:
quanto CPU ele usa?
quanto I/O ele gera?
quais arquivos acessa?
quais tabelas consulta?
quantas vezes executa?
qual volume processa?
qual é o tempo total?
qual parte mais demora?
Comece com:
SDSF;
JES;
SYSOUT;
mensagens;
accounting;
planos de execução;
estatísticas do job;
EXCP;
CPU time;
elapsed time.
Aprenda:
address spaces;
dispatch;
WLM;
LPAR;
CPC;
paging;
I/O;
service classes.
Escolha uma área:
CICS;
Db2;
IMS;
MQ;
storage.
Aprofunde-se.
Você não precisa se tornar matemático.
Mas deve compreender:
média;
mediana;
percentil;
desvio padrão;
tendência;
sazonalidade;
correlação;
outlier;
baseline.
Pergunte:
qual aplicação é crítica?
qual horário é sensível?
qual transação gera receita?
qual batch não pode atrasar?
qual SLA deve ser protegido?
O melhor engenheiro de performance não é quem conhece mais gráficos.
É quem sabe quais gráficos importam.
É o erro mais frequente.
Uma média diária de 40% pode esconder dez minutos a 100%.
Comparar domingo com segunda é perigoso.
Nem toda anomalia é prioridade.
Tuning sem baseline é superstição técnica.
Às vezes o problema está no storage, WLM, rede ou infraestrutura.
Às vezes um loop COBOL ou SQL ruim é o verdadeiro monstro.
Em toda missão do Seaview havia três certezas:
alguma luz vermelha piscaria;
o sonar detectaria algo inexplicável;
alguém sugeriria mergulhar ainda mais fundo.
Na Engenharia de Performance também existem três certezas:
algum gráfico ficará vermelho;
o problema será mais complexo do que parecia;
alguém sugerirá aumentar CPU antes de analisar a causa.
Resista à terceira tentação.
Mais hardware pode mascarar ineficiência.
É como reforçar o casco sem descobrir por que o submarino está colidindo com as rochas.
O mainframe mede performance com profundidade há muitas décadas, muito antes da popularização do termo “observabilidade”.
SMF e RMF já registravam dados operacionais quando muitos sistemas distribuídos ainda dependiam de logs simples.
O WLM não é apenas um agendador. Ele gerencia prioridades com base em objetivos de serviço.
zIIP não é apenas “CPU mais barata”. É uma parte estratégica da arquitetura econômica do IBM Z.
Uma aplicação COBOL eficiente pode continuar valiosa por décadas, justamente porque seu comportamento é previsível, estável e mensurável.
A maioria dos grandes problemas de performance não nasce de uma única causa. Nasce da combinação de pequenas degradações.
A Engenharia de Performance é a arte de ouvir sinais que outros ignoram.
Enquanto muitos enxergam apenas uma tela lenta, o especialista enxerga:
CPU;
I/O;
filas;
locks;
memória;
workload;
prioridade;
arquitetura;
tendência;
custo;
impacto no negócio.
Ele não pergunta apenas:
“Está lento?”
Ele pergunta:
“Desde quando, para quem, em qual camada, sob qual carga, com qual impacto e com quais evidências?”
Para o programador COBOL iniciante, esse conhecimento muda tudo.
Você deixa de escrever programas que apenas funcionam e começa a escrever programas que funcionam bem dentro de um ecossistema complexo.
Você aprende que cada acesso a arquivo tem custo.
Cada SQL tem comportamento.
Cada loop consome capacidade.
Cada chamada remota adiciona espera.
Cada commit influencia logging.
Cada mudança precisa ser medida.
No final da missão, o Seaview retorna à superfície.
A tripulação comemora.
O monstro não era um polvo gigante.
Era um programa que fazia leitura completa de uma tabela de 200 milhões de linhas porque alguém esqueceu de criar o índice correto.
O engenheiro de performance fecha o relatório, toma o último gole de café e deixa uma anotação no diário de bordo:
“Problema resolvido. Causa confirmada. CPU reduzida. Tempo de resposta restaurado. Nenhum submarino perdido.”
E assim termina mais uma viagem ao fundo do mainframe.
 |
| Bellacosa Mainframe apresenta sword art online ordinal scale |
"O mundo mudou. Não é mais preciso entrar no sistema. Agora o próprio sistema entra no mundo."
Depois do enorme sucesso das duas primeiras temporadas, Sword Art Online: Ordinal Scale chegou aos cinemas japoneses em 18 de fevereiro de 2017.
Ao contrário de Extra Edition, que funcionava como um especial de transição, Ordinal Scale é um filme totalmente inédito, canônico, supervisionado diretamente por Reki Kawahara, ocupando um lugar importante na cronologia oficial entre Sword Art Online II e Alicization.
O filme marca uma mudança significativa no universo da franquia: a realidade virtual deixa de ser o foco principal e dá lugar à Realidade Aumentada (AR).
Para um profissional de mainframe, é como abandonar um terminal 3270 dedicado e começar a trabalhar com uma interface gráfica inteligente que projeta informações diretamente sobre o ambiente físico, sem desligar o sistema legado.
Título original: 劇場版 ソードアート・オンライン -オーディナル・スケール-
Título internacional: Sword Art Online: Ordinal Scale
Autor: Reki Kawahara
Ilustrações: abec
Estúdio: A-1 Pictures
Diretor: Tomohiko Itō
Roteiro: Reki Kawahara
Música: Yuki Kajiura
Lançamento: 18 de fevereiro de 2017
Duração: 119 minutos
Formato: Filme
Cronologia: entre Sword Art Online II e Alicization
A A-1 Pictures entregou uma produção cinematográfica de altíssimo nível.
Os destaques incluem:
animação extremamente detalhada
efeitos de iluminação
cenários urbanos realistas
integração perfeita entre AR e mundo físico
batalhas cinematográficas
É considerado um dos filmes visualmente mais impressionantes da franquia.
Uma nova tecnologia domina o mercado.
O dispositivo Augma.
Diferente do NerveGear e do AmuSphere.
Ele não mergulha totalmente o usuário em realidade virtual.
Em vez disso.
Projeta informações sobre o mundo real.
Surge então o jogo Ordinal Scale.
Milhões de pessoas passam a jogar caminhando pelas ruas.
Mas acontecimentos estranhos começam a ocorrer.
Sobreviventes de SAO perdem memórias importantes.
Kirito percebe que existe algo muito errado por trás do novo sistema.
O professor Shigemura Tetsuhiro cria o sistema Ordinal Scale utilizando tecnologia de realidade aumentada.
Sua filha, Yuna, falecida durante o incidente de Aincrad, torna-se o centro emocional da narrativa.
Enquanto jogadores enfrentam monstros espalhados pelas cidades, memórias dos sobreviventes de SAO são coletadas silenciosamente para um projeto secreto.
Kirito precisa descobrir quem está manipulando esses dados antes que todos percam suas lembranças.
A maior inovação do filme é o Augma.
Não existe mais isolamento sensorial.
O jogador continua vendo o mundo real.
Elementos virtuais são projetados sobre ele.
Na visão Bellacosa Mainframe:
NerveGear = Terminal exclusivo.
AmuSphere = Terminal seguro.
Augma = Interface gráfica integrada ao ambiente operacional.
É uma mudança de paradigma.
Agora enfrenta um desafio diferente.
Sua habilidade em VR não garante vantagem em AR.
Ele precisa reaprender.
Tem papel central na história devido às memórias ligadas a Aincrad.
Ídolo virtual criada a partir do projeto Ordinal Scale.
Sua existência levanta questões profundas sobre memória, identidade e legado.
Um cientista brilhante.
Consumido pela dor da perda da filha.
Representa os riscos de colocar a tecnologia acima da ética.
Ex-integrante dos Knights of the Blood.
Busca corrigir erros do passado.
É um antagonista complexo, motivado por culpa e arrependimento.
Pela primeira vez a franquia troca o foco da realidade virtual pela realidade aumentada.
O mundo real torna-se o cenário das batalhas.
Os jogadores:
caminham pelas cidades
enfrentam chefes gigantes
utilizam informações projetadas no ambiente físico
Essa mudança aproxima o filme de tecnologias que anos depois se tornariam populares em dispositivos vestíveis.
Realidade Aumentada
Memória
Luto
Ética Científica
Inteligência Artificial
Música
Tecnologia
Superação
Identidade
Responsabilidade
O jogo torna-se um fenômeno mundial.
Sobreviventes de Aincrad começam a esquecer acontecimentos importantes.
Chefes gigantes aparecem em locais famosos.
O mundo inteiro vira uma arena.
Kirito enfrenta Eiji e o plano do Professor Shigemura para impedir que a tecnologia destrua as lembranças de milhares de pessoas.
Apagar lembranças significa modificar uma pessoa.
Mas também pode aprisioná-lo.
O filme mostra como a incapacidade de aceitar uma perda pode levar até mesmo grandes cientistas a cruzarem limites éticos.
Não basta viver das memórias.
É preciso criar novas.
Imagine um banco que decide modernizar seu ambiente IBM Z.
Em vez de substituir o sistema legado.
Cria uma camada gráfica inteligente.
Tudo parece mais moderno.
Mais bonito.
Mais intuitivo.
Mas essa camada começa a copiar silenciosamente informações críticas do banco de dados.
Quando os administradores percebem.
Os dados mais importantes já foram comprometidos.
É exatamente essa a metáfora de Ordinal Scale.
A inovação nunca deve ignorar governança, segurança e ética.
Foi o primeiro longa-metragem totalmente inédito da franquia.
Reki Kawahara escreveu a história especialmente para o cinema.
O filme arrecadou centenas de milhões de ienes e tornou-se um dos maiores sucessos comerciais de Sword Art Online.
A personagem Yuna tornou-se extremamente popular entre os fãs, especialmente por suas músicas interpretadas por Sayaka Kanda.
Ordinal Scale aproximou Sword Art Online das discussões sobre realidade aumentada, dispositivos vestíveis e integração entre ambientes físicos e digitais.
Lançado meses após o fenômeno de jogos baseados em localização, o filme reforçou o interesse por AR como próxima etapa da computação pessoal.
Também serviu de ponte narrativa para os eventos de Alicization, introduzindo conceitos tecnológicos que evoluiriam no Soul Translator.
O filme recebeu poucas controvérsias em comparação com outras partes da franquia.
As discussões concentraram-se mais em temas como manipulação de memória, uso de dados pessoais e ética científica do que em violência ou conteúdo sensível.
Em alguns países houve pequenas adaptações de classificação indicativa devido às cenas de combate.
Ordinal Scale recebeu adaptação em mangá baseada no roteiro do filme.
Além da adaptação principal, diversos materiais promocionais e artbooks expandiram o universo do longa.
Embora seja uma história original, o filme ganhou adaptações em formato de light novel e materiais complementares supervisionados por Reki Kawahara.
Esses conteúdos aprofundam o passado de Eiji, Yuna e do Professor Shigemura.
O universo de Ordinal Scale foi incorporado a diversos jogos da franquia:
Hollow Realization
Integral Factor
Alicization Lycoris
Last Recollection
Unleash Blading
Yuna e Eiji tornaram-se personagens jogáveis em vários desses títulos.
Gênero:
Ação
Ficção Científica
Aventura
Romance
Drama
Realidade Aumentada
Fantasia Tecnológica
Classificação indicativa: 12 anos.
Enquanto os títulos anteriores perguntavam:
"Como viver dentro de um mundo virtual?"
Ordinal Scale inverte completamente a lógica:
"O que acontece quando o mundo virtual invade o mundo real?"
Essa mudança faz do filme um elo importante entre a realidade aumentada de hoje e as interfaces neurais exploradas posteriormente em Alicization.
Para o Bellacosa Mainframe, Sword Art Online: Ordinal Scale representa o desafio clássico da modernização de sistemas críticos. O legado continua funcionando, mas novas camadas tecnológicas prometem experiências mais rápidas, intuitivas e integradas. O perigo surge quando a inovação avança sem a mesma preocupação com governança, privacidade e integridade dos dados.
Assim como um arquiteto de IBM Z precisa garantir que uma nova interface não comprometa décadas de informações críticas, Kirito descobre que a tecnologia mais avançada não é necessariamente a mais segura. No fim, o filme lembra que memória é o banco de dados mais precioso que existe, e que preservar a humanidade deve ser sempre mais importante do que impressionar com a próxima geração de tecnologia.
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.
Inicializando FullDive...
