✨ 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
SEO não é sobre truques, mas sobre clareza, qualidade e consistência. Ao seguir este checklist, você cria uma base sólida para crescer organicamente, ganhar visibilidade e construir autoridade nos motores de busca de forma sustentável.
🔹 1. Visibilidade nos motores de busca
📍 Blogger → Configurações → Preferências de pesquisa
Visibilidade nos motores de busca: ☑️ SIM (permitir indexação)
❌ Se estiver “Não”, o Google não indexa nada do blog.
🔹 2. Meta tags do blog (muito importante)
📍 Configurações → Preferências de pesquisa → Meta tags
Descrição: ATIVADA
Descrição clara, objetiva e com palavras-chave do blog
⚠️ Não usar textos vazios ou genéricos.
🔹 3. Meta tags dos posts
📍 Editor de post → Opções do post
Para cada post:
Robôs personalizados: padrão (index, follow)
NÃO marcar “Não indexar”
❌ Um post com noindex nunca aparecerá no Google.
🔹 4. Robots.txt personalizado
📍 Configurações → Preferências de pesquisa → Robots.txt personalizado
Configuração recomendada:
User-agent: *Disallow: /searchAllow: /
Robots.txt ATIVADO
Não bloquear / ou /posts
Não usar Disallow: / (isso bloqueia tudo)
🔹 5. Cabeçalho HTTP (X-Robots-Tag)
⚠️ Erro comum em templates modificados
Nenhuma página importante retorna:
X-Robots-Tag: noindex
Como verificar:
Abrir post no navegador
Pressionar F12
Aba Network → Document
Ver cabeçalhos HTTP
🔹 6. Template do Blog
📍 Tema → Editar HTML
NÃO existir:
<metaname="robots"content="noindex">
em páginas de post
✔️ noindex só deve existir em:
páginas de busca
arquivos
labels (opcional)
🔹 7. URLs corretas (SEO-friendly)
URLs curtas
Sem datas exageradas
Palavras-chave no link
Evitar caracteres estranhos
Exemplo bom:
/2025/retrospectiva-canal-el-jefe.html
🔹 8. Sitemap enviado ao Google
📍 Google Search Console → Sitemaps
Enviar:
/sitemap.xml
Sitemap enviado
Sem erros
🔹 9. Google Search Console – Indexação
📍 Indexação → Páginas
Verificar:
Páginas indexadas
Páginas excluídas
Motivos de exclusão analisados
Erros comuns:
noindex
duplicadas
redirecionadas
descobertas mas não indexadas
🔹 10. Inspeção de URL (página por página)
📍 Search Console → Inspeção de URL
Colar URL do post
Ver status: INDEXADA
Se não → Solicitar indexação
🔹 11. Conteúdo mínimo para indexação
O Google evita indexar páginas fracas.
Para cada post:
+300 palavras
Texto original
Pelo menos 1 imagem
Título claro
Conteúdo útil
🔹 12. Links internos
Posts linkam para outros posts
Página inicial linka posts importantes
Menu com links reais
✔️ Links internos ajudam o Google a descobrir páginas.
“COBOL 4 não é ruptura.
É a IBM dizendo: ‘vamos modernizar… sem quebrar nada’.”
— Bellacosa, depois de recompilar 3 milhões de linhas
🧬 Contexto histórico: onde o COBOL 4.00 se encaixa
O Enterprise COBOL for z/OS 4.0 faz parte da família COBOL 4.x, que surgiu no início da década de 2010, num momento crítico:
Mainframes mais poderosos (z10, z196)
Arquitetura 64 bits amadurecendo
Pressão por performance, modernização e integração
COBOL 3 ainda dominante… mas envelhecendo
👉 O COBOL 4 não veio para “mudar a linguagem”.
Veio para mudar o compilador.
📅 Data de lançamento (contexto realista)
Enterprise COBOL for z/OS 4.0: final de 2007 e primordios da primeira década de 2010.
Consolidação real aconteceu nas versões 4.1 / 4.2
Foi o degrau obrigatório antes do COBOL 5.x
💡 Tradução Bellacosa:
Se você saiu do COBOL 3 direto para o 5, o 4 foi o “meio do caminho” que você pulou… e pagou depois.
🖥️ Equipamentos mainframe indicados
COBOL 4 foi feito para explorar hardware moderno da IBM:
Mainframes ideais:
IBM z10
IBM z196
IBM zEC12
Totalmente compatível com zEnterprise
Por quê?
Porque o COBOL 4:
Gera código mais otimizado
Explora melhor o pipeline do processador
Se beneficia de novas instruções de CPU
🥚 Easter-egg:
Recompilar COBOL antigo em COBOL 4 sem mudar uma linha já dava ganho de performance.
🔄 O que muda em relação ao COBOL 3.x?
🧠 1️⃣ Compilador totalmente redesenhado
Novo backend
Melhor otimização de código
Melhor uso de registradores
👉 O código fonte parece igual.
👉 O código objeto não é.
⚙️ 2️⃣ Melhor suporte a arquitetura moderna
Preparação para 64 bits
Melhor alinhamento de dados
Base para o futuro COBOL 5 (LE-only)
📊 3️⃣ Performance real
Redução de CPU em batch
Melhor performance em loops
Melhor otimização de PERFORM
🥚 Easter-egg:
Muitos shops recompilaram só para economizar MIPS.
🧨 4️⃣ Mais rigor (menos permissividade)
Alguns “pecados antigos” começaram a ser cobrados:
Dados mal definidos
Uso implícito perigoso
Código que “sempre funcionou” 😅
👉 COBOL 4 começa a expor bugs escondidos há 20 anos.
🧪 Exemplo simples (nada muda… mas muda tudo)
IDENTIFICATION DIVISION.
PROGRAM-ID. EXEMPLO4.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-TOTAL PIC 9(9) VALUE 0.
PROCEDURE DIVISION.
PERFORM 10 TIMES
ADD 1 TO WS-TOTAL
END-PERFORM
DISPLAY WS-TOTAL
STOP RUN.
➡ Em COBOL 3: funciona
➡ Em COBOL 4: funciona mais rápido
💡 O ganho está no objeto gerado, não no código.
🛠️ Dicas técnicas Bellacosa Approved™
✔ Recompile, mesmo sem modernizar
COBOL 4 já entrega valor só na recompilação
✔ Use parâmetros certos:
OPTIMIZE
ARCH
SSRANGE (para pegar erro escondido)
✔ Teste batch crítico
Principalmente cálculos
Principalmente datas
Principalmente arredondamentos
✔ Compare CPU antes/depois
Você vai se surpreender
⚠️ Armadilhas clássicas
🚨 Código que dependia de comportamento indefinido
🚨 Campos mal alinhados
🚨 MOVE CORRESPONDING em estruturas duvidosas
🚨 Arredondamento implícito não documentado
🥚 Easter-egg cruel:
COBOL 4 não cria bug.
Ele revela.
🧠 Curiosidades de bastidor
COBOL 4 foi o primeiro passo sério rumo ao LE-only
Muitas empresas ficaram “presas” no 4 por anos
Ele é visto como a versão mais estável da transição
Serviu de base para o radical COBOL 5
🧘 Primeiros passos para o Padawan
Se você está começando agora:
1️⃣ Entenda COBOL clássico primeiro
2️⃣ Saiba compilar e linkar
3️⃣ Entenda parâmetros de compilação
4️⃣ Recompile código antigo e observe
5️⃣ Leia o listing — ele ensina mais que o código
“Quem lê o listing, domina o mainframe.”
🧠 Visão Bellacosa Final™
O COBOL 4.00 não é famoso.
Não é revolucionário.
Não é hype.
Mas ele é:
Estável
Inteligente
O verdadeiro ponto de virada técnico do COBOL moderno
Se o COBOL fosse uma saga:
COBOL 3 = trilogia clássica
COBOL 4 = o episódio de transição
COBOL 5 = o reboot corajoso
E lembre-se, Padawan:
“Modernizar não é reescrever.
É entender o que funciona… e deixar melhor.”
Bellacosa Mainframe e os caçadores de fantasma em Ghost Hunt
☕💣👻 OPERADOR, EXISTEM JOBS EXECUTANDO NO ALÉM!
GHOST HUNT — O ANIME QUE TRANSFORMOU CAÇA-FANTASMAS EM UMA OPERAÇÃO DE DEBUG SOBRENATURAL DE ALTO RISCO
📋 Ficha Técnica
Item
Informação
Título Original
ゴーストハント (Ghost Hunt)
Título Internacional
Ghost Hunt
Autora Original
Fuyumi Ono
Ilustrações da Novel
Shiho Inada
Estúdio
J.C.Staff
Diretor
Rei Mano
Exibição Original
3 de outubro de 2006 a 27 de março de 2007
Episódios
25
Origem
Light Novel
Gênero
Terror, Mistério, Sobrenatural, Investigação, Suspense, Drama
Classificação Indicativa
14 anos
Status
Concluído
☕ Introdução
Existem animes de terror que tentam assustar usando sangue.
Existem animes que usam monstros.
Existem animes que usam violência psicológica.
E existe Ghost Hunt, que consegue causar desconforto apenas com um corredor vazio, uma porta fechada ou um ruído vindo do andar de cima.
O que torna Ghost Hunt especial é que ele mistura:
Investigação científica
Paranormalidade
Espiritualidade japonesa
Psicologia
Folclore oriental
Tudo isso embalado como se fosse uma série de casos investigativos.
É praticamente um cruzamento entre:
Arquivo X
Supernatural
Scooby-Doo (versão adulta)
CSI Paranormal
📖 Sinopse
Mai Taniyama é uma estudante comum que gosta de contar histórias de fantasmas.
Ao se envolver acidentalmente em uma investigação paranormal conduzida pela empresa:
Shibuya Psychic Research (SPR)
ela acaba tornando-se assistente do brilhante e arrogante investigador:
Kazuya Shibuya (Naru)
A partir daí, Mai passa a participar de casos envolvendo:
Escolas assombradas
Mansões amaldiçoadas
Espíritos vingativos
Possessões
Poltergeists
Fenômenos inexplicáveis
Cada caso leva a equipe para situações cada vez mais perigosas.
📚 A História por Trás da Obra
Ghost Hunt nasceu como uma série de novels escritas por Fuyumi Ono durante os anos 1980.
Curiosamente, a autora pesquisou profundamente:
Parapsicologia
Fenômenos sobrenaturais
Religiões orientais
Casos paranormais reais
Isso explica por que a obra possui uma abordagem muito mais técnica do que a maioria dos animes do gênero.
Enquanto outros animes simplesmente dizem:
"É um fantasma."
Ghost Hunt pergunta:
"Temos certeza?"
👻 O Que Torna Ghost Hunt Diferente?
Aqui está o grande diferencial.
Na maioria dos animes de terror:
Fantasma → susto → exorcismo.
Fim.
Em Ghost Hunt:
Fantasma → investigação → coleta de evidências → hipóteses → confronto de teorias → conclusão.
Parece quase uma análise de incidente em produção.
☕ Analogia Bellacosa Mainframe
Imagine um ambiente z/OS.
Surge um problema misterioso.
Ninguém sabe a causa.
Os logs não mostram nada.
Os operadores estão desesperados.
Os usuários reclamam.
O gerente quer respostas.
É exatamente isso que acontece em Ghost Hunt.
Só que em vez de:
JES2
CICS
DB2
os problemas envolvem:
Espíritos
Maldições
Assombrações
Possessões
Naru é basicamente um Analista de Suporte Nível 3 especializado em incidentes sobrenaturais.
🧑💻 Principais Personagens
👻 Mai Taniyama
A protagonista.
Representa o espectador.
Curiosa.
Impulsiva.
Corajosa.
É através dela que aprendemos as regras daquele universo.
🕶️ Kazuya "Naru" Shibuya
O cérebro da operação.
Frio.
Lógico.
Extremamente inteligente.
Age como um dump analyzer humano.
Nada escapa à sua investigação.
✝️ John Brown
Padre católico.
Especialista em exorcismos.
Uma das figuras mais equilibradas da série.
🔥 Houshou Takigawa
Monge budista.
Responsável pelos rituais orientais.
Também fornece momentos de humor.
⛩️ Ayako Matsuzaki
Sacerdotisa xintoísta.
Muitas vezes entra em conflito com Naru.
Representa a fé tradicional japonesa.
🔮 Masako Hara
Médium profissional.
Possui uma conexão espiritual muito mais forte do que aparenta.
🏚️ As Grandes Aventuras
Diferentemente de muitos animes, Ghost Hunt funciona por arcos independentes.
Cada caso é praticamente um incidente diferente.
Escola Assombrada
O clássico ponto de partida.
Corredores escuros.
Barulhos.
Sombras.
Uma excelente introdução ao universo.
Mansão dos Espíritos
A equipe enfrenta fenômenos muito mais agressivos.
Aqui percebemos que algumas entidades são perigosas de verdade.
Casa dos Bonecos
Um dos arcos mais perturbadores.
Utiliza o medo psicológico de forma magistral.
Labirinto Sangrento
Considerado por muitos fãs o melhor caso da série.
O nível de tensão sobe drasticamente.
Possessões e Exorcismos
Os casos finais exploram temas mais pesados:
Morte
Culpa
Trauma
Obsessão
🧠 As Mensagens Ocultas
Ghost Hunt possui muito mais profundidade do que aparenta.
O Medo do Desconhecido
A obra sugere que aquilo que não entendemos sempre parece sobrenatural.
É uma discussão constante entre:
Ciência
versus
Crença
A Verdade Pode Ser Assustadora
Muitas vezes o verdadeiro horror não é o fantasma.
É a história por trás dele.
Trauma Não Desaparece
Diversos espíritos representam emoções não resolvidas.
Mágoa.
Dor.
Arrependimento.
Culpa.
Nem Tudo Tem Explicação
Mesmo Naru, com toda sua lógica, encontra fenômenos impossíveis de explicar completamente.
🎭 Simbolismos Escondidos
Cada membro da equipe representa uma forma diferente de interpretar a realidade.
Personagem
Simbolismo
Naru
Ciência
Ayako
Tradição
John
Fé
Masako
Sensibilidade
Mai
Curiosidade
Takigawa
Espiritualidade
A série mostra que nenhuma visão é suficiente sozinha.
🎨 Qualidade da Animação
O estúdio J.C.Staff fez um excelente trabalho.
Em vez de investir em ação exagerada, apostou em:
Atmosfera
Iluminação
Som ambiente
Silêncio
O resultado envelheceu surpreendentemente bem.
🚫 Houve Censura?
Não houve censura significativa.
Entretanto, o anime suavizou alguns elementos das novels.
As obras originais possuem:
Mais violência psicológica
Casos mais detalhados
Explicações mais profundas
Desenvolvimento maior de Naru
Alguns fãs consideram as novels superiores justamente por isso.
🌎 Impacto Cultural
Ghost Hunt ajudou a popularizar um subgênero que mais tarde inspiraria obras como:
Another
Dark Gathering
Ghost Hound
Shinrei Tantei Yakumo
Dusk Maiden of Amnesia
Até hoje é frequentemente citado em listas de:
"Melhores animes de terror psicológico"
e
"Melhores histórias de fantasmas dos animes."
⭐ Avaliação Bellacosa Mainframe
Critério
Nota
Terror
9/10
Mistério
10/10
Atmosfera
10/10
Personagens
9/10
Suspense
10/10
Reassistibilidade
9/10
Impacto Emocional
8/10
Sobrenatural
10/10
☕ Conclusão
Ghost Hunt é um daqueles animes raros que não dependem de gore, violência extrema ou monstros gigantes para funcionar.
Seu verdadeiro poder está em criar a sensação de que existe algo errado no ambiente.
Algo observando.
Algo esperando.
Algo que não deveria estar ali.
Na linguagem do operador de mainframe:
Ghost Hunt é o equivalente a encontrar um JOB consumindo CPU há 40 anos, sem owner, sem documentação, sem JCL catalogada e sem ninguém vivo para explicar por que ele continua executando.
E quanto mais você investiga...
mais percebe que talvez fosse melhor nunca ter aberto o ticket. ☕👻💣🖥️
Porque naquele exato instante o pequeno e-mail é arrancado do conforto do cliente de correio eletrônico e lançado em uma das maiores burocracias automatizadas criadas pela humanidade.
Ele encontrará servidores SMTP, consultará DNS, procurará registros MX, atravessará conexões de rede e será interrogado por SPF, DKIM, DMARC, mecanismos de reputação, antispam, antivírus e políticas corporativas.
Tudo isso antes de conseguir tocar na sagrada pasta:
INBOX.
Nosso pequeno e-mail ainda não sabe.
Mas alguém bate à porta.
— Toc, toc.
— Quem está aí?
Três homens aparecem.
Vestidos de vermelho.
O primeiro carrega uma enorme documentação de DNS.
O segundo segura uma chave criptográfica.
O terceiro traz uma política DMARC impressa em pergaminho.
E gritam:
NOBODY EXPECTS THE SPANISH INQUISITION!
Bem-vindo à autópsia de um e-mail.
🎬 Ato I — O botão SEND é apenas o começo
Uma das primeiras coisas que precisamos destruir é a ideia de que apertar SEND significa que o destinatário recebeu alguma coisa.
Não significa.
Significa apenas que você entregou a mensagem para a próxima etapa de uma cadeia.
Dependendo da arquitetura utilizada, existem diferentes componentes envolvidos, mas podemos imaginar inicialmente:
Usuário
│
▼
Cliente de e-mail
│
▼
Servidor de envio
│
▼
Internet
│
▼
Servidor destinatário
│
▼
Mailbox
De maneira simplificada, DMARC pode ser satisfeito quando existe SPF válido e alinhado ou DKIM válido e alinhado conforme suas regras.
O Grande Inquisidor olha para nosso pequeno e-mail.
— SPF?
— PASS!
— DKIM?
— PASS!
— Alignment?
Silêncio dramático.
Uma orquestra imaginária começa a tocar.
— PASS!
Todos comemoram.
O e-mail corre em direção à Inbox.
O Cardeal DMARC segura-o pela gola.
— Onde pensa que vai?
⚖️ Ato IX — none, quarantine ou reject
DMARC também permite que o domínio publique uma política.
Entre as políticas clássicas encontramos:
p=none
p=quarantine
p=reject
p=none permite essencialmente uma postura de monitoramento em relação ao tratamento DMARC.
p=quarantine solicita tratamento mais cauteloso para mensagens que falham à política.
p=reject solicita que mensagens que falhem sejam rejeitadas.
O domínio está dizendo ao mundo algo próximo de:
“Se alguém tentar se passar por mim e não atender às minhas regras de autenticação, eis como desejo que você trate a situação.”
Isso é extremamente importante contra determinadas formas de falsificação de identidade de domínio.
Mas existe uma pegadinha maravilhosa.
Nosso e-mail passou SPF.
Passou DKIM.
Passou DMARC.
Então está garantido na Inbox?
NÃO!
E essa é uma das lições mais importantes desta autópsia.
🕵️ Ato X — “Sabemos quem você é. Agora precisamos decidir se gostamos de você.”
Autenticação não é reputação.
Repita comigo:
autenticação não é reputação.
Um operador de spam pode possuir seu próprio domínio.
Pode configurar SPF corretamente.
Pode implementar DKIM.
Pode publicar DMARC.
E continuar enviando porcaria industrial em escala planetária.
Portanto, depois da Spanish Inquisition da autenticação, aparece outro departamento.
ANTISPAM.
Esse pessoal não usa roupas vermelhas.
Usa dashboards.
O que é muito mais assustador.
🔬 Ato XI — A máquina de suspeitar
Sistemas modernos de proteção de e-mail podem considerar uma quantidade enorme de sinais.
Por exemplo:
IP remetente
domínio
reputação
volume de mensagens
velocidade de envio
histórico
SPF
DKIM
DMARC
URLs
anexos
conteúdo
headers
padrões de phishing
malware
feedback de usuários
Não devemos imaginar necessariamente uma fórmula universal:
Received: from mail-a
by mail-b;
Received: from mail-b
by mail-c;
Essas informações ajudam a reconstruir partes do caminho percorrido pela mensagem.
É quase uma investigação forense.
A mensagem diz:
“Eu fui diretamente daqui até lá.”
O header responde:
“Curioso. Tenho testemunhas.”
🖥️ Ato XVI — O programador COBOL entra na investigação
Agora chegamos à parte Bellacosa Mainframe.
Alguém abre um incidente:
E-MAIL NÃO ESTÁ FUNCIONANDO.
Isso é quase tão útil quanto abrir um chamado dizendo:
COBOL DEU PROBLEMA.
Nossa primeira missão não é resolver.
É reduzir o universo do problema.
Pergunte:
Todos os usuários?
Um usuário?
Um domínio?
Um destinatário?
Mensagens externas?
Mensagens internas?
Somente mensagens com anexo?
Somente um tipo de anexo?
Começou quando?
Existe mensagem de erro?
Existe bounce?
Qual o timestamp?
Qual o Message-ID?
Veja como o incidente muda.
Antes:
EMAIL NÃO FUNCIONA
Depois:
Mensagens enviadas por determinado
domínio externo começaram a ser
rejeitadas às 03:17.
Agora temos alguma coisa investigável.
🥚 Easter egg — O incidente das 03:17
São 03:17.
Telefone toca.
— Bellacosa?
— Sim.
— O e-mail caiu.
Primeira pergunta:
— Todo o e-mail?
Silêncio.
— Não sei.
— Então ainda não sabemos se o e-mail caiu.
Essa frase deveria estar pregada na parede de toda War Room.
Porque existe uma tendência humana terrível de transformar:
“Qual foi o último ponto que sabemos que funcionou?”
Imagine:
Cliente
│
│ GOOD
▼
SMTP origem
│
│ GOOD
▼
DNS
│
│ GOOD
▼
MX
│
│ GOOD
▼
Servidor destino
│
│ GOOD
▼
SPF
│
│ GOOD
▼
DKIM
│
│ GOOD
▼
DMARC
│
│ ???
▼
Antispam
Pronto.
Acabamos de transformar um universo gigantesco em uma região investigável.
SMTP é fundamentalmente associado ao envio e transferência de mensagens.
Mas depois que a mensagem está armazenada, historicamente outros protocolos são utilizados para acesso às caixas postais.
Entre eles:
POP3
e:
IMAP.
Uma visão didática:
ALICE
│
SMTP
▼
SERVIDOR A
│
SMTP
▼
SERVIDOR B
│
├──── IMAP ────► BOB
│
└──── POP3 ────► CLIENTE
As arquiteturas modernas podem envolver APIs, sincronização proprietária, serviços em nuvem e inúmeras abstrações adicionais.
Mas essa separação é excelente para construir o modelo mental inicial:
SMTP transporta.
IMAP/POP tradicionalmente ajudam clientes a acessar mensagens armazenadas.
🧠 Ato XIX — O e-mail moderno é uma cadeia de confiança
Agora podemos finalmente enxergar o quadro completo.
Quando apertamos SEND, não estamos simplesmente transportando texto.
Estamos iniciando uma negociação de confiança.
O sistema precisa responder sucessivamente:
PARA ONDE?
│
▼
DNS / MX
QUEM ESTÁ CONECTANDO?
│
▼
SMTP / IP
ESTÁ AUTORIZADO?
│
▼
SPF
EXISTE ASSINATURA VÁLIDA?
│
▼
DKIM
AS IDENTIDADES ESTÃO ALINHADAS?
│
▼
DMARC
QUAL A REPUTAÇÃO?
│
▼
REPUTATION SYSTEMS
O CONTEÚDO É SUSPEITO?
│
▼
ANTISPAM
EXISTE AMEAÇA?
│
▼
ANTIMALWARE
QUAL O DESTINO?
│
▼
INBOX / SPAM / QUARANTINE / REJECT
E aqui está a grande diferença conceitual.
SPF, DKIM e DMARC não dizem simplesmente:
“Este e-mail é bonzinho.”
Eles trabalham com propriedades de autenticação, autorização e alinhamento de identidade.
Depois disso ainda existe outra pergunta:
“Mesmo sabendo melhor quem está falando, devo confiar no que ele trouxe?”
É exatamente por isso que autenticação e antispam coexistem.
🏛️ Ato XX — A Internet aprendeu a desconfiar
Nos primórdios das redes acadêmicas, muitos protocolos nasceram em ambientes muito diferentes da Internet comercial moderna.
A rede cresceu.
Vieram empresas.
Vieram milhões de usuários.
Vieram bilhões de mensagens.
E naturalmente vieram:
spam, phishing, malware, falsificação, campanhas automatizadas e fraude.
A arquitetura precisou ganhar camadas adicionais de defesa.
É um fenômeno recorrente na computação.
Primeiro criamos:
“Faça A conversar com B.”
Depois descobrimos que precisamos perguntar:
“Quem é A?”
Depois:
“A pode fazer isso?”
Depois:
“Posso provar que é A?”
Depois:
“Mesmo sendo A, seu comportamento é aceitável?”
É praticamente a história inteira da segurança da informação condensada em uma mensagem eletrônica.
🏰 Ato XXI — A Catedral do E-mail
Gosto de pensar nesses sistemas como catedrais.
Ninguém acordou numa terça-feira e desenhou toda a infraestrutura mundial de e-mail exatamente como ela existe hoje.
Camadas foram acrescentadas.
Problemas apareceram.
Soluções surgiram.
Protocolos foram ampliados.
Mecanismos de segurança foram incorporados.
E o resultado é uma construção que atravessa décadas mantendo enorme compatibilidade com conceitos antigos.
Isso deveria soar extremamente familiar para quem trabalha com mainframe.
O novo não necessariamente destrói o velho.
Muitas vezes:
o novo envolve o velho.
SMTP continua lá.
DNS continua lá.
Sobre eles construímos novas camadas.
Essa é uma das grandes lições da engenharia de sistemas maduros.
🇪🇸 Epílogo — O julgamento final
Nosso pequeno e-mail finalmente chega diante dos três inquisidores.
Depois de SMTP, DNS, MX, SPF, DKIM, DMARC, reputação, antispam, antimalware e políticas, finalmente cumpriu sua missão.
João chega ao escritório oito horas depois.
Abre a caixa postal.
Olha rapidamente para a mensagem.
E clica:
DELETE.
Silêncio absoluto.
SMTP olha para SPF.
SPF olha para DKIM.
DKIM olha para DMARC.
DMARC olha para o antispam.
Todos atravessaram meio planeta, executaram consultas DNS, verificaram identidades, calcularam criptografia, analisaram reputação e protegeram a infraestrutura para aquilo.
O Cardeal SPF pergunta:
— Podemos interrogá-lo novamente?
O Grande Inquisidor responde:
— Não.
— Por quê?
— Porque ninguém espera...
As portas se abrem.
...A SPANISH INQUISITION DO E-MAIL!
E em algum datacenter distante, às 03:17, outro alerta acaba de surgir.
SMTP DELIVERY FAILURE
O telefone toca.
— Bellacosa?
— Sim.
— O e-mail caiu.
— Todos?
Silêncio.
Pegue o café.
A investigação está apenas começando.
☕ Bellacosa Mainframe — moral da história
Nunca trate um sistema complexo como uma caixa preta chamada “não funciona”.
Divida-o em checkpoints.
Descubra quem falou com quem.
Identifique as evidências.
Encontre o último estado conhecido como GOOD.
Localize a transição:
GOOD
│
▼
GOOD
│
▼
GOOD
│
▼
???
│
▼
BAD
E comece exatamente ali.
Seja investigando SMTP, COBOL, CICS, Db2, MQ, RACF ou um job misteriosamente desaparecido no JES, o princípio continua extraordinariamente útil:
não interrogue o sistema inteiro quando você pode interrogar cada etapa.
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
