🥢 O HOMEM HERBÍVORO — A REVOLUÇÃO SILENCIOSA DO DESEJO JAPONÊS

 

🥢 O HOMEM HERBÍVORO — A REVOLUÇÃO SILENCIOSA DO DESEJO JAPONÊS
por Bellacosa Mainframe – Edição El Jefe Midnight, Filosofia em modo Debug

---

Era uma vez o Japão, aquele mesmo das ruas brilhantes de Shibuya e das máquinas de vender de tudo (até cueca usada).
Um país que reconstruiu sua alma após duas bombas, inventou o Walkman, o emoji e o karaokê… mas que, nas últimas décadas, vem sendo palco de um fenômeno intrigante: o “homem herbívoro” (sōshoku danshi).

Não, não tem a ver com dieta.
Tem a ver com desejo — ou melhor, com a ausência dele.
Uma geração de homens que não quer caçar, não quer dominar, não quer competir.
Homens que, em vez de conquistar corações, preferem cultivar plantas, gatos e introspecções.

Prepare seu chá verde, respire fundo e venha comigo entender o bug cultural mais fascinante da psique japonesa moderna.

---

🌿 A ORIGEM DO TERMO — UM JAPÃO CANSADO DE LUTAR

O termo sōshoku danshi (“homem herbívoro”) foi cunhado em 2006 pela jornalista Maki Fukasawa numa revista japonesa chamada AERA.
Ela observava jovens urbanos que não se encaixavam mais no modelo tradicional masculino:
não eram agressivos, não eram ambiciosos e, acima de tudo, não tinham pressa em namorar ou fazer sexo.

Enquanto o Japão dos anos 80 exaltava o “homem carnívoro” — competitivo, workaholic, galanteador e obcecado por status — o novo milênio viu surgir seu oposto:
rapazes educados, tranquilos, avessos à pressão social e emocionalmente autossuficientes.

“Eles não caçam. Eles contemplam.”

---

🧘‍♂️ O PERFIL DO HOMEM HERBÍVORO — O PADRÃO QUE DESLIGA A CORRIDA

O sōshoku danshi não é um preguiçoso nem um antissocial.
Ele apenas optou por não jogar o jogo.

• Trabalha, mas não vive para o trabalho.

• Gosta de cuidar da própria aparência, mas sem obsessão.

• Prefere relações simples, honestas e sem competição.

• Tem hobbies introspectivos (leitura, culinária, jardinagem, animes, jogos).

• Evita o flerte agressivo.

• E, muitas vezes, não vê no sexo a principal forma de conexão.

Em resumo, é o homem que cansou do script do “provedor” e começou a buscar paz mental em vez de performance.

Curiosidade: o termo “herbívoro” vem do contraste com o nikushoku danshi (“homem carnívoro”), símbolo da geração anterior — viril, assertivo e dominador.
O Japão literalmente passou de samurai para minimalista zen.

---

💔 A REAÇÃO DA SOCIEDADE — QUANDO O SISTEMA NÃO ENTENDE O NOVO CÓDIGO

A mídia japonesa, claro, pirou.
De repente, o “homem herbívoro” virou sinônimo de crise masculina:
os jornais culpavam essa geração pela queda da natalidade, pela falta de casamentos e até pelo colapso da indústria de encontros.

As mulheres, por sua vez, ficaram divididas.
Algumas viam neles um tipo gentil, emocionalmente seguro.
Outras reclamavam: “Eles são bonzinhos demais. Cadê o fogo?”.

O resultado?
Uma sociedade em looping emocional, onde ninguém sabe mais qual papel deve executar.

“O Japão criou o protótipo da harmonia… e esqueceu de compilar o desejo.”

---

🧩 AS CAUSAS PROFUNDAS — BUGS SOCIAIS DO SISTEMA JAPONÊS

A teoria do homem herbívoro tem raízes bem mais profundas do que a simples “falta de libido”.
Entre os principais fatores:

1. Pressão social extrema: a cultura corporativa e escolar drena o tempo e a energia emocional.

2. Feminização simbólica da sensibilidade: homens passaram a se expressar melhor, mas a sociedade ainda os julga por isso.

3. Medo da rejeição: o fracasso social ou romântico no Japão é visto como vergonha pública.

4. Economia estagnada: muitos jovens não têm condições financeiras de manter relacionamentos “tradicionais”.

5. Desilusão com o amor de consumo: a geração digital viu o amor virar produto — e decidiu não comprar.

Curiosidade: o Japão tem mais de 1,5 milhão de hikikomoris (pessoas reclusas socialmente), e parte deles se encaixa no arquétipo do homem herbívoro.

---

🍃 DICAS E COMPORTAMENTOS — O QUE ESSE MOVIMENTO ENSINA AO OCIDENTE

O homem herbívoro pode parecer apático, mas carrega valores que o mundo moderno precisa reaprender:

• Não ter pressa — desacelerar o desejo não é negar a vida, é saboreá-la.

• Autocuidado sem culpa — cuidar da pele, da casa e da alma é sinal de equilíbrio, não de fraqueza.

• Afeto sem posse — ele entende que amor não é conquista, é convivência.

• Minimalismo emocional — menos drama, mais clareza.

“Em vez de caçar corações, ele cultiva conexões.”

Easter-egg cultural: muitos personagens de animes modernos — como Tanjiro (Demon Slayer), Shinji (Evangelion), e até Giyu (Kimetsu no Yaiba) — exibem traços do homem herbívoro: introspectivos, gentis, e com uma relação ambígua com o próprio desejo.

---

🕰️ HISTÓRIA E REFLEXÃO — DO SAMURAI AO SILÊNCIO URBANO

Há algo quase poético nessa mutação.
O Japão, que durante séculos exaltou o guerreiro que morria por honra, agora vê nascer o homem que vive por paz.

Enquanto o samurai empunhava a katana, o herbívoro segura o celular — mas ambos lutam pela mesma coisa: controle sobre o próprio destino.
Só que agora a batalha é interna.

O que parece apatia é, na verdade, resistência silenciosa.
Uma geração que olhou o mundo hipercompetitivo e disse:

“Não quero jogar esse game. Quero criar o meu.”

---

☕ EPÍLOGO BELLACOSA — O NOVO MAINFRAME DO DESEJO

A teoria do homem herbívoro não é mito, nem lenda urbana.
É o log emocional de uma sociedade que cansou de rodar scripts antigos.

Talvez o que chamamos de “falta de desejo” seja apenas uma nova forma de amar — menos performática, mais introspectiva, mais honesta.
O homem herbívoro é o símbolo de uma atualização silenciosa do firmware humano.

E se o Ocidente rir, tudo bem.
O Japão sempre foi o early adopter da alma — e o resto do mundo, cedo ou tarde, faz o download.

“Talvez o futuro pertença a quem aprendeu a existir sem caçar.” 🌿

 

Estou sendo sarcastico

estou sendo sarcastico #CheBellacosaSDV pic.twitter.com/Ly0bwqDYbP

— Vagner Bellacosa (@BellacosaVagner) April 11, 2021

 

Bellacosa Mainframe e a mistteriosa loja de bonecas de another

☕ OPERADOR, O QUE DIABOS ERAM AQUELAS BONECAS?

A estranha loja de bonecas de Another

Durante vários momentos do anime aparecem:

• bonecas

• manequins

• olhos artificiais

• membros artificiais

• vitrines estranhas

Tudo envolto em uma atmosfera quase sobrenatural.

A direção faz questão de mostrar:

BONECA
↓
MEI
↓
BONECA
↓
OLHO
↓
BONECA

Praticamente um bombardeio visual.

---

O QUE O ESPECTADOR VETERANO PENSA?

Quem assiste muito anime imediatamente ativa:

CHEKHOV.EXE

E começa a formular hipóteses.

---

Talvez:

• as bonecas estejam vivas

• exista um espírito preso nelas

• sejam recipientes para almas

• sejam ligadas à maldição

• exista um portal dimensional

• Mei seja uma boneca

• a cidade inteira seja um experimento sobrenatural

😂

---

O PROBLEMA?

Nada disso acontece.

---

A LOJA NÃO É UM PORTAL

Muita gente lembra daquele lugar como algo quase lovecraftiano.

Mas tecnicamente não é.

Não é:

• templo

• portal

• santuário

• dimensão paralela

---

É basicamente um ateliê/galeria de bonecas artísticas administrado pela família de Mei.

---

POR QUE ELE PARECE TÃO IMPORTANTE?

Porque a direção do anime o filma como se fosse importante.

Esse é o truque.

---

Imagine em Evangelion.

---

Se uma câmera fica dez segundos mostrando uma porta.

Você pensa:

"Atrás daquela porta existe um segredo."

---

Em Another a câmera faz isso com as bonecas.

---

O SIMBOLISMO REAL

Aqui a coisa fica mais interessante.

As bonecas representam vários temas centrais da obra.

---

1. A Fronteira Entre Vivo e Morto

Uma boneca parece humana.

Mas não é.

---

Parece viva.

Mas não está viva.

---

Esse conceito conversa diretamente com:

• memória

• identidade

• existência

---

Temas centrais de Another.

---

2. Pessoas Que Continuam Presentes

Pense na própria maldição.

---

Alguém deveria não estar ali.

Mas está.

---

Uma boneca cria exatamente essa sensação.

---

Algo humano.

Mas não humano.

---

Algo presente.

Mas ausente.

---

3. O Olho de Mei

Essa é provavelmente a ligação mais importante.

---

O olho artificial de Mei vem daquele ambiente.

---

O tema dos olhos aparece o tempo inteiro.

---

Olhos representam:

PERCEPÇÃO

---

E a história inteira gira em torno de:

O QUE PODE SER VISTO

e

O QUE NÃO PODE SER VISTO

---

A VERDADE SOBRE A LOJA

Vou ser sincero.

---

A loja funciona mais como:

Cenário simbólico

do que

Elemento de enredo

---

E é justamente isso que frustra alguns espectadores.

---

Porque a linguagem visual promete:

SEGREDO IMPORTANTE

---

Mas entrega:

ATMOSFERA

---

O FALSO CHEKHOV'S GUN

Lembra do texto que discutimos sobre Chekhov?

---

As bonecas são quase um:

Falso Chekhov

---

O anime faz você acreditar:

"Isso será essencial."

---

Mas não será.

---

Bellacosa Mainframe

Imagine um operador encontrando:

//MISTERIO DD DSN=PORTAL.DIMENSIONAL

---

Durante 12 episódios você espera:

OPEN DATASET

---

Mas nunca acontece.

😂

---

No último episódio descobre:

DSN UTILIZADO APENAS PARA DECORAÇÃO

---

O QUE EU ACHO?

Pessoalmente?

Concordo parcialmente com você.

---

As bonecas criam uma expectativa gigantesca.

Maior do que a recompensa entregue.

---

Não considero um erro.

Mas considero um dos maiores casos de:

"promessa visual superior ao retorno narrativo"

de todo o anime.

---

A TEORIA BELLACOSA MAINFRAME

Se eu pudesse reescrever Another mantendo a essência da obra, faria as bonecas terem um papel um pouco maior.

Não necessariamente explicando a maldição.

Mas conectando:

• memória

• identidade

• morte

• percepção

de forma mais explícita.

---

Porque hoje elas funcionam quase como um módulo órfão.

BONECAS.EXE

STATUS:
CARREGADO

IMPORTÂNCIA VISUAL:
ALTA

IMPORTÂNCIA NARRATIVA:
MODERADA

EXPECTATIVA GERADA:
MUITO ALTA

RETORNO ENTREGUE:
MENOR QUE O ESPERADO

☕💣👁️

E talvez isso explique exatamente sua sensação.

Você não estava esperando apenas a revelação da pessoa extra.

Você estava esperando que:

• as bonecas,

• a loja,

• os olhos artificiais,

• o ambiente gótico,

fossem a ponta de um iceberg muito maior.

Mas no final descobriu que eles eram principalmente metáforas visuais, não a chave do mistério.

E para um veterano de anime, acostumado com obras onde cada detalhe estranho esconde uma conspiração gigantesca (Lain, Higurashi, Evangelion, Steins;Gate), isso realmente pode deixar aquela sensação de:

"Operador... faltou abrir alguns datasets." ☕📂👁️💣

 

O Restaurante Fechava às Dez; Assuan Só Começava Depois

 

Bellacosa Mainframe um drink num bar clandestino em Assuan

☕ Um Café no Bellacosa Mainframe

O Restaurante Fechava às Dez; Assuan Só Começava Depois

Ou: como um brasileiro fumando narguilé virou operador internacional de aquisição etílica, descobriu que uma parede falsa era mais honesta que certas leis e terminou a noite bebendo com novos amigos num porão ao estilo Lei Seca

Há leis que tentam regular comportamentos. Há leis que protegem pessoas. Há leis que organizam uma sociedade complicada, como uma boa PROC que impede o batch de executar um DELETE no arquivo errado.

E há leis que parecem ter sido escritas por alguém que nunca encontrou seres humanos de verdade.

Em uma viagem ao Egito, eu estava em Assuan, sentado na calçada do hotel, fumando narguilé e observando a noite passar. Nada de aventura planejada. Nada de “hoje vou conhecer o submundo egípcio”. Apenas um brasileiro, um narguilé e aquela tranquilidade de fim de noite que faz qualquer lugar distante parecer temporariamente familiar.

Então chegou um rapaz.

— Brasileiro, tudo bem?

A pergunta já era curiosa. Ele sentou, puxou conversa, falou do Egito, perguntou do Brasil. Era simpático demais para ser inteiramente inocente, pensei. Meu processador de risco começou a trabalhar:

Em alguns minutos ele tentará vender um passeio pelo Nilo, um tapete persa, um perfume milagroso, ouro verdadeiro com desconto de amigo ou um camelo que, por razões misteriosas, precisa ser vendido ainda hoje.

Mas o rapaz foi direto ao ponto. Tirou algumas notas egípcias bem gastas, quase pretas de tanto circular de mão em mão, e pediu um favor.

Neste momento, meu cérebro abriu uma tela em letras vermelhas:

ALERTA: possível início de um city tour pela cadeia egípcia.
AÇÃO RECOMENDADA: sorrir, levantar devagar e retornar ao hotel.

O pedido, porém, era simples. E absurdamente humano.

No Egito havia — e talvez ainda haja, em certas situações — comércio voltado para estrangeiros e comércio voltado para egípcios. Uma loja de bebidas para ocidentais podia exigir passaporte estrangeiro para vender álcool. O rapaz e seus amigos não podiam comprar ali como cidadãos locais. Eu podia.

Aquela pilha de notas não era dinheiro de alguma operação obscura do Nilo. Era uma vaquinha. Dez amigos nas redondezas tinham juntado dinheiro e precisavam de um turista disposto a executar o job.

Eu seria o contrabandista internacional de álcool de Assuan.

Naturalmente, topei.

Entrei na vaquinha, acrescentei dinheiro para comprar também algumas bebidas para mim, pegamos o caminho da loja 24 horas destinada aos estrangeiros e fiz a compra do goró em plena conformidade burocrática. Passaporte brasileiro apresentado. Caixa registrada. Nenhuma mala falsa. Nenhum barco cruzando o Nilo às três da manhã. Nenhum contato com a máfia.

Tudo legal, tudo em ordem.

Exceto pelo pequeno detalhe de que uma garrafa era acessível para mim porque eu tinha nascido em outro país e inacessível para aqueles homens porque eles tinham nascido naquele.

Voltamos para o mesmo tapete onde eu fumava narguilé. A noite seguiu com bebida, conversa e risada. Em menos de uma hora, aquele desconhecido que eu imaginava estar prestes a me vender um tour fraudulento havia me dado uma aula de sociologia aplicada. A lei dizia uma coisa; a vida das pessoas organizava outra.

Como presente intercultural de irmão de copo para irmão de copo, ele fez uma recomendação enfática:

— Amanhã, vá jantar em tal restaurante. Comida egípcia de verdade. Muito boa.

No dia seguinte, fui.

O restaurante era normalíssimo. Comida típica, mesas, cozinha, garçons, famílias, o cheiro maravilhoso de temperos e aquela aparência sem glamour que normalmente indica que a comida será melhor que qualquer lugar com cardápio plastificado em cinco idiomas. Comi comida egípcia para egípcios, daquelas que não aparecem no roteiro do hotel.

Quando o restaurante fechou, as portas foram cerradas e as luzes apagaram, bateu aquele friozinho na espinha.

O primeiro filme que me veio à cabeça foi Um Drink no Inferno.

Por alguns segundos, meu cérebro decidiu que a refeição egípcia terminaria com vampiros, motociclistas, uma banda tocando rock no porão e algum sujeito revelando presas atrás do balcão. Pensei, com toda a elegância possível:

— Fudeu.

Aí ri do próprio pensamento bobo e esperei o desenrolar.

O dono saiu, olhou a multidão que permanecia ali — gente demais para um restaurante supostamente fechado —, atravessou o salão, abriu uma cortina e empurrou uma parede falsa. Atrás dela, um corredor escuro e uma longa escadaria desciam para o porão.

Não havia vampiros.

No fim do corredor, uma longa escadaria descia para o porão.

E lá embaixo existia uma discoteca clandestina, música ocidental e álcool à vontade.

O restaurante não era o Titty Twister de Assuan. Era apenas um estabelecimento normalíssimo que, depois das dez, executava uma mudança de ambiente mais radical que qualquer IPL de sexta-feira: desligava a fachada, revelava uma segunda operação e deixava a cidade continuar no subsolo.

O restaurante não fechava às dez. Ele apenas encerrava a operação visível.

Depois, iniciava o segundo turno.

//ASSUAN01 JOB
//DAYSHIFT EXEC PGM=RESTAURANTE
//NIGHTJOB  EXEC PGM=SPEAKEASY
//SYSIN     DD *
   FECHAR PORTAS
   APAGAR LUZES
   ABRIR CORTINA
   MOVER PAREDE
   DESCER ESCADARIA
   SERVIR ÁLCOOL
/*

Aquela discoteca no porão tinha algo de filme americano dos anos 1930. Era o speakeasy da Lei Seca, só que com comida egípcia, narguilé, uma fachada de restaurante e um brasileiro que havia entrado no sistema por causa de uma vaquinha de amigos.

E ali está o ponto que sempre me incomoda quando falamos de proibição moral. O legislador pode declarar que determinada prática não deve existir. Pode limitar, punir, fiscalizar e condenar. Mas, se uma parcela relevante da sociedade continua querendo aquilo — e se aquilo não é percebido por essa parcela como um mal concreto contra outra pessoa — a demanda não evapora.

Ela desce a escada.

Sai do comércio regulamentado e vai para a porta dos fundos. Sai da luz e vai para o corredor escuro. Sai da regra transparente e vai para a rede de favores, cumplicidades e tolerâncias silenciosas.

O resultado raramente é uma sociedade mais virtuosa. Frequentemente é uma sociedade mais hipócrita.

A Lei Seca americana ensinou isso com clareza brutal: não acabou com o álcool; criou contrabando, corrupção, bebida sem controle, violência e oportunidades para quem aceitasse lucrar com a proibição. Em Assuan, não vi uma caricatura de criminosos perigosos. Vi pessoas comuns tentando beber, conversar, dançar e passar uma boa noite — com toda a criatividade que uma regra desconectada da vida cotidiana é capaz de provocar.

Não estou dizendo que toda proibição é errada. Há leis que precisam ser firmes para impedir exploração, violência e dano real. Mas existe uma diferença importante entre proteger vítimas e criar uma polícia da consciência.

Porque, quando a lei começa a tentar administrar desejo, costume e intimidade em vez de dano concreto, ela frequentemente não elimina o comportamento. Ela apenas transforma cidadãos comuns em infratores ocasionais — e transforma um restaurante muito normalzinho em uma escada para o porão.

Na noite seguinte, eu poderia ter ficado no hotel, pedido algo sem graça no serviço de quarto e contado que Assuan era bonita. Em vez disso, comi comida egípcia de verdade, encontrei uma discoteca clandestina e aprendi que um passaporte brasileiro pode abrir portas muito mais interessantes do que qualquer guia turístico.

Ou, naquele caso, abrir uma cortina, mover uma parede e revelar que a cidade só começava depois das dez.

https://eljefemidnightlunch.blogspot.com/2016/02/hora-feliz-pensa-que-um-viajante-nao.html

https://eljefemidnightlunch.blogspot.com/2015/12/cavalgando-uma-mulinha-no-vale-dos-reis.html

https://eljefemidnightlunch.blogspot.com/2016/02/big-crazy-part-uma-festa-muita-louca.html

https://eljefemidnightlunch.blogspot.com/2016/02/templo-de-horus-em-edfu.html

https://eljefemidnightlunch.blogspot.com/2016/02/complexo-de-templos-em-abu-simbel.html

https://eljefemidnightlunch.blogspot.com/2016/02/cavalgando-camelos-em-pleno-deserto-do.html

https://eljefemidnightlunch.blogspot.com/2025/08/a-nostalgica-abertura-do-programa-enigma.html

Bellacosa Mainframe e a mitica fabrica da Lambretta em Lambrate Milano

☕ Um Café no Bellacosa Mainframe

Eu Fui Procurar uma Lambretta e Encontrei 2.200 Anos de História

🛵 Uma criança brasileira que andou na garupa de uma lambreta. Décadas depois foi procurar onde ela nasceu — e encontrou romanos, Barbarossa, Borromeos, bombas e um deus cujo nome desapareceu.

Existem lugares aos quais viajamos porque alguém colocou uma estrela no guia turístico.

E existem lugares aos quais chegamos porque uma lembrança antiga ficou armazenada em algum endereço obscuro da memória e, décadas depois, resolveu executar novamente.

Lambrate, em Milão, pertence à segunda categoria.

Eu não fui até lá procurando ruínas romanas.

Não fui atrás de São Carlos Borromeo.

Não estava procurando Frederico Barbarossa.

Muito menos fui procurar um pequeno lugar de culto pagão transformado ao longo dos séculos numa Cappelletta cristã.

Eu fui atrás de uma Lambretta.

E a culpa começou no Brasil, quando eu ainda era criança.

---

🛵 Quando Lambretta significava simplesmente “lambreta”

Para o pequeno Vagner, Lambretta não era uma aula sobre design industrial italiano.

Era uma coisa muito mais concreta.

Eu andava na garupa de uma.

No Brasil daquela época, “lambreta” havia praticamente escapado da condição de marca e entrado no vocabulário cotidiano. Era a motinha pequena, econômica, popular.

Eu conhecia a palavra.

Conhecia o objeto.

Conhecia a garupa.

Conhecia a experiência física de andar naquela coisa.

Décadas depois fui morar na Itália.

E em algum momento aconteceu aquilo que costuma acontecer comigo quando descubro que alguma coisa aparentemente banal possui um endereço histórico.

Descobri que aquela máquina da minha infância levava diretamente a:

Innocenti.

Lambrate.

Milão.

Pronto.

Precisava conhecer.

---

🏭 A fábrica que produziu uma palavra da minha infância

Lambrate tornou-se um dos grandes territórios industriais de Milão no século XX.

Ali funcionou a Innocenti, fundada por Ferdinando Innocenti, cujo nome ficaria definitivamente associado à fabricação da Lambretta.

O bairro transformou-se.

Fábricas cresceram.

Operários chegaram.

Casas foram construídas.

Trabalhava-se em Lambrate.

Vivia-se em Lambrate.

E dali saíram milhares e milhares daquelas scooters que atravessariam oceanos e chegariam inclusive ao Brasil.

Muito tempo depois, eu faria o caminho inverso.

Do Brasil para a Itália.

Da lembrança para a fábrica.

Da garupa para Lambrate.

Só havia um problema.

Quando cheguei procurando arqueologia industrial, encontrei arqueologia de verdade.

---

🏺 “Peraí... o que é aquilo?”

Quem conhece minhas viagens sabe que existe um bug recorrente no planejamento.

Tenho um destino.

Encontro alguma coisa estranha no caminho.

Pergunto:

“O que é isso?”

Fim do roteiro original.

Em Lambrate aconteceu novamente.

Em meio àquela história industrial existia uma construção minúscula.

A Cappelletta di Lambrate.

Nada monumental.

Nada remotamente comparável ao Duomo.

Nenhuma fila de turistas.

Nenhum ônibus despejando cinquenta pessoas com câmeras.

Quase invisível dentro da própria cidade.

E isso não é apenas impressão minha.

Uma placa que fotografei dizia:

“Oggi, quasi non la si nota più, sommersa dalle auto e dalle case…”

Em tradução livre:

“Hoje quase não se percebe mais, submersa pelos automóveis e pelas casas.”

Perfeito.

Era exatamente aquilo.

Mas então comecei a descobrir sua história.

E a Lambretta teve de esperar.

---

🏺 Antes da Lambretta, antes da fábrica, antes de Milão ser Milão

As fontes locais que encontramos precisam ser tratadas com alguma cautela.

Há história documentada.

Há arqueologia.

E há tradição transmitida durante gerações.

Não são exatamente a mesma coisa.

Sabemos que Lambrate possui passado romano real. Achados arqueológicos realizados na região incluem um sarcófago de mármore e um bronze do período augustano.

Uma das fontes locais situa a história conhecida do território aproximadamente dois séculos antes da Era Cristã.

E a própria Cappelletta é apresentada em diferentes registros como um lugar cuja origem pode remontar a um antigo espaço de culto pagão, posteriormente convertido ou reinterpretado no contexto romano e cristão.

Uma fonte contemporânea resume:

“Sorta come luogo di culto pagano, divenne altare in epoca romana…”

“Nascida como lugar de culto pagão, tornou-se altar na época romana…”

Outra fonte é mais cautelosa e fala em origem pagã apenas como possibilidade.

Essa distinção importa.

Não estamos afirmando que existe documentação arqueológica perfeita demonstrando uma linha religiosa contínua durante 2.200 anos.

Estamos reconstruindo uma mistura fascinante de arqueologia, história e memória local.

E existe algo que todas essas versões possuem em comum:

o lugar permaneceu importante.

---

🔄 Religious Upgrade

Mainframes recebem upgrades.

Sistemas operacionais recebem upgrades.

CICS recebe upgrades.

Db2 recebe upgrades.

Religiões também possuem uma característica interessante:

às vezes o sistema muda...

mas o endereço permanece.

Um local considerado especial por determinada população pode ser reinterpretado pela população seguinte.

Muda o deus.

Muda o ritual.

Muda a língua.

Muda a explicação.

O endereço continua lá.

Em linguagem Bellacosa:

LAMBRATE.SACRED.SITE

RELEASE 0.x   — possível culto pagão
RELEASE 1.x   — mundo romano
RELEASE 2.x   — tradição cristã
RELEASE 3.x   — Cappelletta
RELEASE 4.x   — devoção moderna

STATUS: ACTIVE

E então começaram a aparecer personagens que normalmente esperamos encontrar em livros, não numa capelinha quase escondida entre carros.

---

⚔️ 1162 — Barbarossa chega ao log

Em 1162, Frederico I, o famoso Barbarossa, ordenou a destruição de Milão depois do conflito entre a cidade e o poder imperial.

Segundo a tradição local preservada sobre a Cappelletta, grupos de milaneses — particularmente habitantes ligados a Porta Orientale — teriam se reunido naquela região enquanto fugiam da cidade destruída.

Imagine a cena.

Hoje atravessamos aquele cruzamento olhando o celular.

Em 1162 alguém poderia ter chegado ali olhando para trás e vendo sua cidade sendo destruída.

Quatro anos depois, uma pergaminho de 1166 registra Lambrate como uma espécie de borgo imperiale.

E nossa pequena Cappelletta continuou atravessando versões da humanidade.

---

⛪ ~1570 — Carlo Borromeo

Passam quatro séculos.

Entra em cena Carlo Borromeo.

Arcebispo de Milão.

Cardeal.

Uma das grandes figuras da Contrarreforma.

Posteriormente santo da Igreja Católica.

Segundo a tradição local, por volta de 1570 Carlo Borromeo celebrou funções religiosas naquele lugar.

A Cappelletta ganhou mais um registro no log.

Mas a família Borromeo ainda voltaria.

---

📖 1610 — Federico Borromeo

Em 1610, segundo o mesmo registro local, Federico Borromeo recolheu-se ali em oração.

E Federico possui uma pequena conexão cultural maravilhosa.

É justamente o cardeal eternizado por Alessandro Manzoni em I Promessi Sposi.

Agora nossa pequena construção conecta:

Roma.

Milão medieval.

Barbarossa.

Contrarreforma.

Borromeos.

Literatura italiana.

E ainda nem chegamos à Lambretta.

---

🇪🇸 🇦🇹 🇫🇷 Lambrate troca de administradores

Vieram espanhóis.

Vieram austríacos.

Veio Napoleão.

Durante o domínio espanhol apareceu inclusive uma primeira atividade industrial militar importante na região: La Polveriera.

Em 1805, sob Napoleão, Lambrate tornou-se município livre.

Em 1808 foi anexada a Milão.

Em 1816, com o retorno austríaco, recuperou sua independência municipal.

E permaneceu assim por mais de um século.

Finalmente, em 1924, Lambrate foi definitivamente incorporada ao município de Milão.

Enquanto governos mudavam:

CAPPELLETTA
STATUS: STILL HERE

---

🏭 Então chegou a Innocenti

No século XX começa outra transformação gigantesca.

A Lambrate rural desaparece progressivamente sob a Lambrate industrial.

A Innocenti torna-se uma das grandes referências do bairro.

E então nasce aquela máquina que, décadas depois, seria responsável pela minha presença naquele lugar:

Lambretta.

A fábrica não produziu apenas scooters.

Produziu cultura.

Produziu empregos.

Produziu identidade urbana.

Produziu memórias.

E, do outro lado do Atlântico, ajudou a transformar uma marca em palavra cotidiana.

Para uma criança brasileira, aquilo era simplesmente:

uma lambreta.

E eu andava na garupa.

---

💣 Então veio a guerra

Milão foi duramente bombardeada durante a Segunda Guerra Mundial.

Especialmente dramáticos foram os ataques de agosto de 1943, quando enormes áreas da cidade sofreram destruição.

A reconstrução posterior também alteraria profundamente a paisagem milanesa.

E aqui chegamos a um dos episódios mais extraordinários da tradição da Cappelletta.

Durante um bombardeio, um artefato atingiu o pequeno santuário.

E não explodiu.

Aqui precisamos abrir duas LPARs.

---

📜 LPAR A — História

Bombas falham.

Espoletas apresentam defeitos.

Artefatos podem atingir o solo em condições inadequadas para detonação.

Até hoje cidades europeias encontram bombas não detonadas da Segunda Guerra Mundial.

Portanto:

BOMB
  ↓
IMPACT
  ↓
FAILURE TO DETONATE

É perfeitamente possível.

Não precisamos de intervenção sobrenatural.

Fim da explicação histórica.

---

🧙 LPAR B — Imaginação Vagneriana

Agora podemos brincar.

Imagine algum antigo ocupante sobrenatural daquele endereço observando a situação.

Ele já tinha sobrevivido a:

romanos;

cristianização;

Barbarossa;

Borromeos;

espanhóis;

austríacos;

Napoleão;

industrialização.

Então aparece um bombardeiro.

Uma bomba vem diretamente na direção do pequeno santuário.

Depois de dois milênios de uptime, o antigo processo finalmente acorda:

ICH408I

BOMB IS NOT AUTHORIZED
TO ACCESS RESOURCE:

LAMBRATE.SACRED.SITE

ACCESS INTENT: EXPLODE
ACCESS ALLOWED: NONE

SAF RC=08
RACF RC=08

A bomba não explode.

Historicamente?

Falha mecânica.

Na Imaginação Vagneriana?

O antigo deus apenas murmurou:

“Aqui não.”

---

🛵 E finalmente apareço eu

Um brasileiro aparece em Lambrate.

Não está procurando o Duomo.

Não está procurando Leonardo da Vinci.

Não está procurando moda.

Está procurando uma fábrica de scooters porque, quando criança, andava na garupa de uma lambreta no Brasil.

Encontra a história da Innocenti.

Encontra Lambrate.

Encontra a Cappelletta.

Lê as placas.

Tira fotografias.

Descobre que aquele pequeno objeto quase invisível possui uma quantidade absolutamente desproporcional de história.

E resolve visitá-lo.

Eu tinha ido procurar uma memória da minha infância.

Acabei encontrando memórias de pessoas que estavam mortas havia quase dois mil anos.

---

📸 A Cappelletta não encolheu

Décadas de fotografias permitem observar outra coisa extraordinária.

Nas imagens antigas, a Cappelletta parece dominar o pequeno cruzamento.

Há menos carros.

Menos mobiliário urbano.

Menos construções competindo visualmente com ela.

Depois olhamos as fotografias contemporâneas.

Prédios.

Carros.

Scooters.

Placas.

Restaurantes.

Postes.

Apartamentos.

Vegetação.

Asfalto.

A Cappelletta parece minúscula.

Mas existe uma ilusão aí.

Ela não ficou menor.

Milão ficou maior ao redor dela.

Essa talvez seja a melhor representação física de toda a história.

Uma cidade inteira cresceu em volta de uma coisa pequena que aparentemente se recusou a sair dali.

---

🌹 2022 — ainda existe alguém colocando flores

As fotografias de 2022 acrescentam algo fundamental.

O lugar não é simplesmente uma relíquia arquitetônica.

Olhando através das grades vemos flores.

Vasos.

Uma cruz.

Um pequeno espaço cuidadosamente mantido.

Ou seja:

continua vivo.

Depois de todas aquelas transformações, ainda existem pessoas atribuindo significado religioso àquele pequeno espaço.

E então aparece meu detalhe favorito numa das fotografias de 2022.

Uma scooter está estacionada praticamente diante da Cappelletta.

Claro que está.

Depois de toda essa história, o universo precisava fechar o loop.

ANTIGO CULTO
     ↓
ROMA
     ↓
CRISTIANISMO
     ↓
BARBAROSSA
     ↓
BORROMEO
     ↓
GUERRA
     ↓
INNOCENTI
     ↓
LAMBRETTA
     ↓
VAGNER
     ↓
CAPPELLETTA
     ↓
SCOOTER

RETURN TO ORIGIN

---

🏙️ O lugar que ficou invisível

A placa que fotografei em 2011 talvez contenha a melhor descrição:

quase não se percebe mais.

E existe algo profundamente bonito nisso.

O Duomo não corre grande risco de ser esquecido.

Pompeia não precisa que eu escreva sobre Pompeia para continuar existindo na memória coletiva.

O Coliseu possui milhões de fotografias.

Mas pequenos lugares são diferentes.

Uma placa desaparece.

Um morador que conhecia determinada história morre.

Uma construção é reformada.

Uma página antiga sai da internet.

Uma tradição deixa de ser repetida.

E um pedacinho de informação desaparece.

Foi justamente isso que aconteceu enquanto eu tentava reconstruir esta história.

---

👻 O deus que desapareceu do backup👻 O deus que desapareceu do backup

Existe uma lembrança que não consegui recuperar.

Quando visitei o local, recordo-me de encontrar uma referência ao nome da antiga divindade pagã associada à história daquele lugar.

Quinze anos depois procurei novamente.

Nada.

Revirei fotografias.

Consultamos textos sobre Lambrate.

Encontramos referências a luogo di culto pagano.

Encontramos fontes dizendo que a origem pagã é apenas uma possibilidade.

Encontramos romanos.

Encontramos Barbarossa.

Encontramos Carlo Borromeo.

Encontramos Federico Borromeo.

Encontramos a Innocenti.

Encontramos Lambrettas.

Encontramos bombardeios.

Encontramos até fotografias da Cappelletta antes e depois da transformação urbana.

Mas o nome daquele deus...

MEMBER NOT FOUND

E não vou inventá-lo.

Essa talvez seja a regra mais importante de toda esta história:

quando a memória termina, a imaginação pode começar — desde que coloquemos uma placa avisando onde fica a fronteira.

---

☕ Por que escrever isso?

Porque grandes monumentos possuem historiadores.

Pequenos lugares dependem de alguém suficientemente curioso para perguntar por que ainda estão ali.

Foi exatamente isso que aconteceu comigo.

Uma palavra da infância levou-me a uma scooter.

A scooter levou-me a uma fábrica.

A fábrica levou-me a um bairro.

O bairro levou-me a uma capelinha.

A capelinha levou-me aos romanos.

Os romanos levaram-me a um culto anterior.

Depois apareceram Barbarossa, Borromeos, guerras, bombas, operários, fábricas e dois milênios de pessoas que viveram naquele mesmo pequeno pedaço do planeta.

Tudo porque um dia pensei:

“Já que estou em Milão, quero conhecer onde faziam a Lambretta.”

Talvez seja por isso que gosto tanto de viajar para lugares históricos.

Uma praia bonita é uma praia bonita.

Mas diga:

“Na frente daquela praia existe um navio afundado.”

Acabou.

Preciso saber o nome do navio.

Quem estava nele.

Quando afundou.

Por quê.

O que carregava.

Onde está.

História transforma coordenadas em lugares.

---

🗃️ Fazendo backup das coisas pequenas

Quando publiquei esta história, aconteceu mais uma transformação.

Uma lembrança de 2011 tornou-se registro.

Fotografias antigas ganharam contexto.

Uma placa ganhou transcrição.

Textos locais separados passaram a conversar entre si.

A Cappelletta ganhou mais uma pequena cópia no gigantesco e caótico backup chamado Internet.

Talvez ninguém precise dela.

Talvez daqui a vinte anos alguém procure justamente essa informação.

E talvez encontre este artigo.

Nesse caso:

BACKUP SUCCESSFUL

Porque patrimônio não é somente aquilo que colocamos num grande museu.

Às vezes patrimônio é uma construção minúscula que milhares de pessoas atravessam diariamente sem perceber.

E alguém precisa fazer backup das coisas pequenas.

---

📋 Incident Report — Cappelletta di Lambrate

RESOURCE:
LAMBRATE.SACRED.SITE

INITIAL INSTALLATION:
UNKNOWN

EARLIEST CONTEXT:
Ancient / Roman Lambrate

POSSIBLE ORIGINAL FUNCTION:
Pagan place of worship

ROMAN MIGRATION:
Reported

CHRISTIAN MIGRATION:
Successful

BARBAROSSA EVENT:
Survived

BORROMEO ACCESS:
Recorded by local tradition

SPANISH ADMINISTRATION:
Survived

AUSTRIAN ADMINISTRATION:
Survived

NAPOLEON:
Survived

MILAN ANNEXATION:
Survived

INDUSTRIALIZATION:
Survived

INNOCENTI:
Survived

WORLD WAR:
Survived

BOMB:
FAILED

DEINDUSTRIALIZATION:
Survived

GENTRIFICATION:
Survived

VAGNER VISIT:
2011

PHOTOGRAPHIC CHECK:
2022 — ACTIVE

CURRENT STATUS:
STILL THERE

UPTIME:
UNKNOWN, POSSIBLY ~2 MILLENNIA+

ORIGINAL PAGAN DEITY:
MEMBER NOT FOUND

MAXCC=0000

---

P.S. — Procura-se um deus desaparecido

E agora faço algo que normalmente seria imperdoável num relatório técnico.

Deixo o incidente aberto.

As fontes locais consultadas relacionam a Cappelletta a um antigo lugar de culto pagão ou tratam essa origem como possibilidade.

Mas existe uma informação que não consegui recuperar:

qual era o nome da divindade associada à tradição pagã da Cappelletta di Lambrate?

Não quero uma reconstrução criativa.

Não quero escolher algum deus romano conveniente.

Não quero transformar hipótese em fato.

Quero a fonte.

Se você é de Lambrate, estudou a história do bairro, possui fotografias antigas, livros, folhetos, placas, arquivos paroquiais ou simplesmente lembra de uma antiga indicação existente no local:

conte-me.

Se possível, envie também a referência, fotografia ou documento.

Este artigo será atualizado e o crédito será registrado.

Até lá, nosso ocupante mais antigo continuará assim:

NAME        : ????????
LOCATION    : LAMBRATE
STATUS      : LEGACY
FIRST SEEN  : UNKNOWN
LAST SEEN   : POSSIBLY ALWAYS

E talvez exista certa justiça poética nisso.

Seu templo mudou.

Seu povo mudou.

Sua religião mudou.

Sua cidade mudou.

Seu nome desapareceu.

Mas o endereço permaneceu.

E se a Imaginação Vagneriana estiver certa sobre aquela bomba, em algum lugar dentro do grande log histórico de Lambrate ainda existe uma mensagem muito antiga:

“Eu ainda estou aqui.”

☕🛵🏺

Bellacosa Mainframe — fazendo backup das coisas pequenas antes que alguém execute DELETE PURGE.

P.P.S. — Aos moradores de Lambrate que chegaram até aqui

Se você é milanês e encontrou esta página procurando informações sobre a Cappelletta, talvez neste momento esteja fazendo uma pergunta perfeitamente razoável:

“Por que diabos um programador COBOL de Itatiba, uma pequena cidade do interior do Brasil, escreveu tudo isso sobre nossa velha capelinha?”

A resposta começa muitos milhares de quilômetros daqui.

Quando criança, no Brasil, eu andava na garupa de uma lambreta.

Décadas depois descobri que aquela pequena máquina da minha infância havia nascido em Lambrate.

Em 2011 fui procurar sua história.

Encontrei a Innocenti.

Depois encontrei a Cappelletta.

E cometi o erro que costuma arruinar meus roteiros de viagem:

perguntei o que era aquilo.

Uma pergunta levou aos romanos.

Os romanos levaram a um antigo culto.

Depois apareceram Barbarossa, Carlo Borromeo, Federico Borromeo, guerras, bombardeios, operários, fábricas e gerações de moradores que continuaram atribuindo significado àquele pequeno pedaço de terra.

Portanto, caro milanês:

a culpa é de vocês.

Eu fui a Lambrate procurando uma scooter.

Vocês deixaram dois mil anos de história estacionados ao lado dela.

Um programador não pode encontrar um LOG desse tamanho e simplesmente ir embora.

E, se ainda estiver achando estranho um brasileiro se importar tanto com um monte de pedras velhas de seu bairro, talvez exista uma explicação ainda mais simples:

às vezes quem mora ao lado de uma coisa olha para ela todos os dias.

Quem atravessou um oceano para encontrá-la olha uma única vez — mas pergunta por quê.

☕🇧🇷🤝🇮🇹🛵

END OF JOB

MAXCC=0000

Essa última ideia, aliás, é o coração do artigo inteiro: a distância pode fazer alguém perceber como extraordinário aquilo que a familiaridade tornou invisível. E é exatamente o que a própria placa de Lambrate dizia: quasi non la si nota più.

O coboleiro de Itatiba simplesmente notou. 😄

Para ir mais longe

https://eljefemidnightlunch.blogspot.com/2017/12/aguas-vivas-encantadoras-bailando-no.html

O Paciente TSB: House, COBOL e a Migração Bancária de £1 Bilhão que Quase Matou um Banco

Bellacosa Mainframe e a migragação que quase matou um banco case study TSB Bank

 ☕ Um Café no Bellacosa Mainframe

O Paciente TSB: House, COBOL e a Migração Bancária de £1 Bilhão que Quase Matou um Banco

O relógio marcava poucos minutos depois da abertura dos serviços digitais quando os primeiros sintomas apareceram.

Um cliente não conseguia acessar a conta.

Outro via um saldo incorreto.

Um terceiro enxergava informações que aparentemente pertenciam a outra pessoa.

Pagamentos falhavam.

Cartões eram recusados.

O aplicativo móvel apresentava erros.

O internet banking oscilava entre lentidão, indisponibilidade e comportamentos estranhos.

Na sala de operações, os painéis começaram a piscar como monitores de uma UTI.

Alertas.

Filas crescendo.

APIs retornando erro.

Processos atrasados.

Centrais telefônicas congestionadas.

Milhões de clientes tentando descobrir se o dinheiro ainda estava no banco.

Em algum lugar do edifício, provavelmente alguém disse a frase mais perigosa da informática:

— Deve ser apenas um problema temporário.

Se o doutor Gregory House trabalhasse com mainframes, ele provavelmente entraria na sala apoiado em sua bengala, olharia para os gráficos de CPU, para os logs de aplicação e para os executivos reunidos ao redor da mesa e perguntaria:

— Quem foi o gênio que decidiu transplantar o coração, trocar o sistema nervoso e atualizar o cérebro do paciente na mesma cirurgia?

Silêncio.

O paciente era o TSB Bank.

O procedimento era uma gigantesca migração de sistemas e dados.

E o diagnóstico inicial estava completamente errado.

---

Capítulo 1 — O paciente chega à emergência

O TSB era um banco britânico com milhões de clientes, milhares de funcionários, agências, cartões, contas, empréstimos, pagamentos e serviços digitais.

Embora funcionasse como uma instituição independente, grande parte de sua tecnologia ainda estava hospedada na infraestrutura do Lloyds Banking Group.

Isso significava que os clientes enxergavam a marca TSB, mas muitos sistemas por trás das telas ainda dependiam da plataforma tecnológica do antigo grupo.

Em 2015, o banco espanhol Sabadell adquiriu o TSB.

A aquisição trouxe uma necessidade estratégica bastante compreensível: transferir os sistemas do TSB para uma nova plataforma controlada pelo próprio Sabadell.

A plataforma escolhida era conhecida como Proteo4UK, uma adaptação do sistema Proteo utilizado pelo grupo espanhol.

No papel, o projeto parecia racional.

O banco deixaria de pagar pela dependência tecnológica da Lloyds.

Passaria a controlar sua própria infraestrutura.

Reduziria custos.

Ganharia autonomia.

Modernizaria canais digitais.

Unificaria processos.

Era como transferir um paciente de um hospital antigo para uma nova clínica, equipada com aparelhos modernos, prontuário eletrônico e quartos recém-pintados.

O problema é que um banco não é apenas um edifício cheio de computadores.

Um banco é um organismo vivo.

Cada conta é uma célula.

Cada programa é um órgão.

Cada fila de mensagens é uma artéria.

Cada arquivo VSAM é uma memória.

Cada tabela Db2 é uma parte do DNA.

Cada transação CICS é um impulso nervoso.

Cada job batch é um processo metabólico que precisa acontecer na hora certa.

Migrar um banco não é transportar caixas.

É realizar um transplante completo enquanto o paciente continua respirando, pagando boletos, recebendo salários, autorizando cartões e transferindo dinheiro.

• Para saber mais

https://eljefemidnightlunch.blogspot.com/2020/04/o-caso-tsb-bank-como-uma-migracao-de.html

---

Capítulo 2 — “Todo mundo mente”, inclusive os dados

Uma das frases mais famosas associadas ao estilo House é:

Todo mundo mente.

Na engenharia de dados, podemos adaptar a frase:

Todo dado mente até ser validado.

Um registro pode parecer correto e ainda estar errado.

Imagine o seguinte conteúdo no sistema antigo:

CLIENTE: 00012345
SALDO: 00000150000

O programador iniciante olha e interpreta:

Saldo = 150.000

Mas o copybook COBOL informa:

05 SALDO-CONTA PIC S9(9)V99 COMP-3.

Agora sabemos que existem duas casas decimais implícitas.

O valor real pode ser:

1.500,00

Além disso, o dado está armazenado em formato decimal compactado.

Se alguém tratar o conteúdo como texto comum, o resultado pode ser inválido.

Esse é um exemplo simples.

Em um banco real, existem milhares de variações:

• campos com sinal;

• valores em COMP;

• números em COMP-3;

• datas julianas;

• indicadores de um caractere;

• campos redefinidos com REDEFINES;

• layouts diferentes para tipos diferentes de conta;

• valores históricos mantidos em moedas antigas;

• campos cujo significado depende de outro campo;

• registros criados antes de certas regras modernas;

• códigos que só fazem sentido para programas antigos.

Veja um exemplo:

01 REGISTRO-CONTA.
   05 TIPO-REGISTRO          PIC X.
   05 DADOS-GERAIS.
      10 NUMERO-CONTA        PIC 9(10).
      10 CODIGO-CLIENTE      PIC 9(08).
   05 DADOS-ESPECIFICOS      PIC X(100).

01 REGISTRO-CORRENTE REDEFINES REGISTRO-CONTA.
   05 FILLER                 PIC X(19).
   05 LIMITE-CHEQUE          PIC S9(7)V99 COMP-3.
   05 TAXA-JUROS             PIC S9(3)V9999 COMP-3.
   05 FILLER                 PIC X(88).

Sem o copybook, o campo DADOS-ESPECIFICOS parece um bloco sem significado.

Com o copybook, descobrimos que parte dele representa limite, juros e informações específicas da conta corrente.

É por isso que acessar os dados de origem sem possuir os modelos, layouts, programas e regras de negócio é como examinar uma radiografia sem saber qual parte do corpo está sendo observada.

Você vê sombras.

Mas não sabe se elas representam um osso, um tumor ou apenas um botão da camisa.

---

Capítulo 3 — O erro de acreditar que migração é apenas copiar

Um dos maiores enganos em projetos tecnológicos é considerar a migração de dados uma operação simples:

Extrair
Transformar
Carregar

O famoso ETL.

A sigla é correta.

A interpretação simplificada é que causa problemas.

Em um sistema bancário, migrar uma conta exige preservar muito mais do que uma linha de tabela.

É necessário manter:

• identificação do cliente;

• titularidade;

• contas conjuntas;

• saldos;

• limites;

• cartões associados;

• empréstimos;

• débitos automáticos;

• pagamentos agendados;

• beneficiários cadastrados;

• autenticação;

• tokens;

• autorizações;

• bloqueios judiciais;

• histórico;

• auditoria;

• prevenção à fraude;

• regras de compliance;

• relacionamento com sistemas externos.

Considere uma tabela simples:

CLIENTE
CONTA
CARTAO
EMPRESTIMO
PAGAMENTO

A princípio, parece suficiente mover cinco conjuntos de dados.

Mas logo surgem as perguntas.

Uma conta pode ter mais de um titular?

Um cliente pode ter várias contas?

Um cartão pode estar temporariamente bloqueado?

Uma dívida pode ser renegociada?

Um pagamento agendado pode depender de saldo futuro?

Uma conta encerrada precisa continuar disponível para auditoria?

Um cliente falecido pode manter processos sucessórios ativos?

Uma conta pode estar sob investigação?

Uma transação pode ter sido autorizada, mas ainda não compensada?

É aqui que o caso deixa de parecer uma simples cópia e passa a se parecer com um episódio de diagnóstico médico.

O sintoma visível é:

O cliente não consegue entrar no aplicativo.

Mas a causa pode estar em:

• autenticação;

• perfil migrado incorretamente;

• chave de acesso ausente;

• conta não associada;

• API indisponível;

• timeout;

• fila congestionada;

• banco de dados lento;

• cache inconsistente;

• regra de segurança incompatível;

• capacidade insuficiente.

Como House diria:

— O aplicativo não é a doença. É apenas onde a doença decidiu aparecer.

---

Capítulo 4 — A tempestade perfeita

O desastre do TSB não foi causado por um único erro.

Essa é uma das lições mais importantes.

Grandes colapsos raramente nascem de uma única falha gigantesca.

Eles surgem da combinação de diversas falhas menores que se fortalecem mutuamente.

No caso TSB, houve uma verdadeira tempestade perfeita:

• migração de milhões de clientes;

• transformação de dados;

• mudança de plataforma;

• alterações de infraestrutura;

• adaptações de software;

• novos canais digitais;

• integração com diversos sistemas;

• pressão por prazo;

• planejamento insuficiente;

• testes inadequados;

• dificuldades operacionais;

• respostas lentas durante a crise.

Cada elemento isolado já seria complexo.

Todos juntos criaram um paciente com falência múltipla de órgãos.

Em engenharia de sistemas, devemos evitar mudar várias camadas críticas simultaneamente.

Por exemplo, executar na mesma janela:

Migração de banco de dados
+
Upgrade do sistema operacional
+
Nova versão da aplicação
+
Mudança de infraestrutura
+
Alteração de autenticação
+
Novo aplicativo móvel

Quando algo falha, onde está a causa?

No banco?

Na rede?

Na aplicação?

Na API?

No sistema operacional?

Na autenticação?

No dado convertido?

Na configuração?

Na capacidade?

Sem isolamento de variáveis, a investigação torna-se caótica.

Em medicina, se um paciente toma seis medicamentos novos e apresenta uma reação, fica difícil descobrir qual substância provocou o problema.

Em TI, é a mesma coisa.

O tratamento pode acabar piorando o paciente.

---

Capítulo 5 — O diagnóstico por amostragem

Um dos pontos mais perigosos em qualquer migração é a confiança exagerada em amostras.

A equipe seleciona alguns milhares de registros.

Compara origem e destino.

Os valores parecem corretos.

O relatório fica verde.

A reunião termina com aplausos.

Mas há um detalhe.

O banco possui milhões de clientes.

Suponha que uma anomalia afete apenas 0,1% dos registros.

Em 5,2 milhões de clientes, isso representa:

5.200 clientes

Cinco mil e duzentas pessoas sem acesso correto ao dinheiro já são suficientes para gerar:

• reclamações;

• denúncias;

• chamadas telefônicas;

• repercussão na imprensa;

• investigação regulatória;

• dano reputacional.

Agora imagine uma falha de 1%.

Temos:

52.000 clientes

Uma amostra aleatória pode não capturar casos raros.

E sistemas bancários são repletos de casos raros.

Entre eles:

• conta muito antiga;

• endereço internacional;

• nome com caracteres especiais;

• cliente com múltiplas nacionalidades;

• conta bloqueada;

• conta conjunta com regras incomuns;

• empréstimo renegociado;

• cartão substituído;

• cliente menor de idade;

• cliente falecido;

• conta órfã;

• saldo negativo com condição especial;

• registro criado por sistema desativado;

• contrato com código legado.

A amostragem é útil para análise exploratória.

Ela não deve ser confundida com reconciliação completa.

Para dados críticos, o ideal é automatizar a comparação do conjunto inteiro sempre que possível.

Não basta executar:

SELECT COUNT(*) FROM CLIENTES;

e concluir que tudo está correto porque os dois bancos possuem 5.200.000 linhas.

Duas bibliotecas podem ter exatamente um milhão de livros.

Isso não significa que possuam os mesmos livros.

É necessário comparar:

• chaves;

• valores;

• relacionamentos;

• totais;

• regras;

• integridade;

• exceções;

• duplicidades;

• dados ausentes;

• transformações.

---

Capítulo 6 — A anatomia de uma validação verdadeira

Uma boa validação ocorre em várias camadas.

Primeira camada: contagem

Quantos registros existiam na origem?

Quantos chegaram ao destino?

SELECT COUNT(*) FROM CONTA_ORIGEM;
SELECT COUNT(*) FROM CONTA_DESTINO;

Essa verificação é necessária, mas insuficiente.

Segunda camada: somatórios

Compare valores agregados.

SELECT SUM(SALDO) FROM CONTA_ORIGEM;
SELECT SUM(SALDO) FROM CONTA_DESTINO;

Se a quantidade de contas for igual, mas o total financeiro for diferente, existe um problema grave.

Terceira camada: comparação por chave

Cada conta deve existir nos dois lados.

Conta 123 existe na origem?
Conta 123 existe no destino?

Quarta camada: comparação de atributos

Para cada chave:

Saldo origem = saldo destino?
Status origem = status destino?
Limite origem = limite destino?
Data origem = data destino?

Quinta camada: integridade referencial

Todo cartão aponta para uma conta válida?

Todo empréstimo aponta para um cliente existente?

Todo pagamento agendado mantém seu beneficiário?

Sexta camada: regras de negócio

Mesmo que os valores sejam tecnicamente iguais, o comportamento pode estar incorreto.

Exemplo:

Status antigo: B
Status novo: 2

A conversão pode ser válida.

Mas o código 2 significa “bloqueado” ou “encerrado”?

É necessário validar o significado, não apenas o formato.

Sétima camada: comportamento

Depois da migração, o cliente consegue:

• entrar;

• consultar saldo;

• pagar;

• transferir;

• bloquear cartão;

• atualizar cadastro;

• receber salário;

• consultar extrato?

Dados corretos em repouso podem produzir comportamento incorreto quando utilizados pelas aplicações.

É como um exame de sangue aparentemente normal em um paciente que continua desmaiando.

O diagnóstico ainda não terminou.

---

Capítulo 7 — O Big Bang e o botão vermelho

O TSB adotou uma abordagem de grande corte, frequentemente chamada de Big Bang.

Em essência:

1. parar ou congelar partes do sistema antigo;

2. extrair dados;

3. converter;

4. carregar no novo ambiente;

5. direcionar os clientes para a nova plataforma;

6. esperar que tudo funcione.

O Big Bang é sedutor.

Executivos gostam dele porque parece definitivo.

Existe uma data.

Existe uma noite de virada.

Existe uma apresentação com foguetes, setas e a palavra “transformação”.

Mas a concentração de risco é enorme.

Se o novo ambiente apresentar problemas, milhões de clientes são afetados simultaneamente.

Uma alternativa é a migração progressiva.

Pode-se dividir por:

• produto;

• região;

• grupo de clientes;

• funcionalidade;

• canal;

• tipo de conta.

Outra abordagem é o chamado Strangler Pattern.

O sistema novo vai gradualmente substituindo funções do antigo.

Imagine:

Semana 1: consulta de saldo
Semana 2: extrato
Semana 3: atualização cadastral
Semana 4: pagamentos
Semana 5: cartões

Ou:

Grupo piloto: 10 mil clientes
Segundo grupo: 100 mil
Terceiro grupo: 500 mil
Expansão gradual

Cada etapa produz aprendizado.

O risco é limitado.

Falhas são descobertas antes de atingir toda a população.

Nem sempre a migração gradual é simples.

Sistemas antigos podem ser altamente acoplados.

Regulamentos e contratos podem impor prazos.

Manter dois ambientes custa dinheiro.

Ainda assim, quando o paciente é um banco com milhões de clientes, prudência custa menos do que uma crise de £1 bilhão.

---

Capítulo 8 — Reconciliação contínua: o eletrocardiograma dos dados

Durante uma migração, a origem não permanece congelada por semanas.

Clientes continuam movimentando contas.

Novas transações surgem.

Endereços são alterados.

Cartões são bloqueados.

Pagamentos são agendados.

Empréstimos recebem parcelas.

Por isso existe o conceito de delta.

Delta é aquilo que mudou desde a última sincronização.

Considere:

Base completa: 5,2 milhões de clientes
Mudanças na última hora: 12 mil registros

Não é necessário comparar tudo o tempo todo.

Podemos comparar apenas as alterações recentes.

Esse processo é chamado de reconciliação contínua de deltas.

O fluxo pode ser:

Sistema de origem
      ↓
Captura de alterações
      ↓
Transformação
      ↓
Sistema de destino
      ↓
Comparação automática
      ↓
Relatório de diferenças

Se a origem recebeu 100 transações e o destino recebeu 98, precisamos descobrir imediatamente quais duas desapareceram.

Não no dia seguinte.

Não depois da abertura das agências.

Não depois que os clientes reclamarem.

Imediatamente.

Essa reconciliação funciona como um monitor cardíaco.

O paciente pode parecer estável, mas o eletrocardiograma mostra pequenas arritmias antes do colapso.

Em ambientes modernos, essa observação pode envolver:

• Change Data Capture;

• logs de transação;

• timestamps;

• números sequenciais;

• filas;

• eventos;

• trilhas de auditoria;

• checksums;

• hashes;

• tabelas de controle.

No mainframe, conceitos semelhantes já existem há décadas.

Logs do Db2.

Journals.

SMF.

Logs do CICS.

Registros de recuperação.

Arquivos de controle.

O nome das ferramentas muda.

O princípio permanece.

---

Capítulo 9 — Ferramentas automáticas não são luxo

Imagine cinco milhões de clientes.

Agora suponha que cada cliente possua 200 atributos relevantes.

Temos aproximadamente:

1 bilhão de valores

Nenhuma equipe humana consegue comparar manualmente esse volume.

Mesmo que cada conferência levasse apenas um segundo, seriam décadas de trabalho.

Automação não é opcional.

É requisito básico.

Uma plataforma de testes de dados deve ser capaz de:

• comparar origem e destino;

• executar regras;

• gerar exceções;

• identificar duplicidades;

• encontrar registros ausentes;

• validar formatos;

• calcular somatórios;

• verificar relacionamentos;

• repetir testes;

• manter evidências;

• produzir relatórios auditáveis.

Um script simples já pode ajudar.

Pseudo-COBOL:

READ ARQUIVO-ORIGEM
READ ARQUIVO-DESTINO

PERFORM UNTIL FIM-DOS-ARQUIVOS

   IF CHAVE-ORIGEM NOT = CHAVE-DESTINO
      DISPLAY 'DIFERENCA DE CHAVE'
   ELSE
      IF SALDO-ORIGEM NOT = SALDO-DESTINO
         DISPLAY 'DIFERENCA DE SALDO'
      END-IF
   END-IF

   READ ARQUIVO-ORIGEM
   READ ARQUIVO-DESTINO

END-PERFORM

Em produção, a solução seria muito mais sofisticada.

Mas o princípio é exatamente esse:

Comparar de forma repetível, automática e rastreável.

---

Capítulo 10 — O sistema de origem é o prontuário do paciente

Outra lição crítica é a necessidade de acesso completo ao sistema de origem.

Não basta receber arquivos exportados.

A equipe precisa entender:

• copybooks;

• modelos de dados;

• programas;

• regras;

• interfaces;

• códigos;

• exceções;

• histórico;

• processos batch;

• transações online.

Em sistemas COBOL antigos, muitas regras de negócio não estão documentadas em manuais.

Elas vivem no código.

Veja:

IF TIPO-CONTA = 'P'
   AND DATA-ABERTURA < 19950101
   AND IND-ESPECIAL = 'S'
      MOVE TAXA-HISTORICA TO TAXA-APLICADA
ELSE
      MOVE TAXA-ATUAL TO TAXA-APLICADA
END-IF.

Essa regra pode ter sido criada trinta anos atrás.

Talvez exista apenas porque um produto antigo concedia uma condição especial.

Se a nova plataforma migrar todos os clientes para a taxa atual, os dados estarão estruturalmente corretos.

Mas o negócio estará errado.

Essa é a diferença entre migrar bytes e migrar significado.

O programador COBOL experiente frequentemente conhece essas exceções.

Ele sabe que determinado campo não pode ser tratado como zero.

Sabe que um código aparentemente obsoleto ainda é usado por um job mensal.

Sabe que um arquivo “temporário” alimenta um relatório regulatório.

Sabe que uma rotina chamada CALCULA-AJUSTE também atualiza auditoria.

Esses profissionais são como médicos veteranos que reconhecem uma doença rara apenas observando um pequeno detalhe.

Quando são excluídos do projeto porque “a plataforma nova não usa COBOL”, o projeto perde parte da memória institucional.

---

Capítulo 11 — Prazos políticos não curam sistemas

Há duas datas em qualquer grande projeto.

A data desejada.

E a data segura.

Elas nem sempre são iguais.

Executivos trabalham com contratos, custos, compromissos públicos e metas estratégicas.

Engenheiros trabalham com evidências, testes, capacidade, estabilidade e risco.

O conflito nasce quando a data desejada se transforma em uma verdade absoluta.

A reunião de decisão deveria perguntar:

Os dados foram reconciliados?
Os testes críticos passaram?
A capacidade suporta o pico?
O rollback foi ensaiado?
As equipes estão preparadas?
Existem defeitos bloqueadores?

Mas muitas vezes pergunta apenas:

Vamos cumprir a data?

House provavelmente responderia:

— Claro. O funeral também pode ser realizado na data prevista.

Um prazo não corrige defeitos.

Uma apresentação não aumenta capacidade.

Um gráfico verde não apaga erros.

Uma declaração de confiança não substitui um teste.

O critério de entrada em produção deve ser baseado em condições objetivas.

Exemplo:

Zero diferenças financeiras não explicadas
100% das funções críticas aprovadas
Tempo de resposta dentro do limite
Rollback executado com sucesso
Equipe de suporte completa
Defeitos críticos resolvidos

Sem isso, a decisão é uma aposta.

E bancos não deveriam apostar com o dinheiro dos clientes.

---

Capítulo 12 — Rollback: o desfibrilador que precisa funcionar

Todo grande projeto fala em rollback.

Poucos realmente o testam.

Rollback significa retornar ao estado anterior quando a migração falha.

Mas há perguntas desconfortáveis:

• Quanto tempo leva?

• Os dados novos podem ser devolvidos?

• As transações realizadas no ambiente novo serão perdidas?

• Os dois sistemas continuam compatíveis?

• Quem autoriza a reversão?

• Até que momento é possível voltar?

• O rollback foi ensaiado?

• Há capacidade operacional para executá-lo?

Imagine:

22h00 — sistema antigo desligado
23h00 — dados extraídos
02h00 — carga concluída
06h00 — novo sistema liberado
08h00 — clientes realizam transações
10h00 — falhas graves confirmadas

Agora não basta religar o sistema antigo.

Entre 06h00 e 10h00 surgiram novas transações.

Como transportá-las de volta?

É por isso que rollback não é um botão mágico.

É um projeto dentro do projeto.

Uma estratégia pode incluir:

• congelamento controlado;

• logs de transação;

• captura de deltas;

• sincronização reversa;

• limites claros para abortar;

• pontos de não retorno;

• ensaios completos.

Um plano não testado é apenas literatura corporativa.

---

Capítulo 13 — Observabilidade: os exames do paciente

Durante uma migração, não devemos observar apenas se o servidor está ligado.

Precisamos medir o comportamento completo.

Infraestrutura:

• CPU;

• memória;

• disco;

• rede;

• filas;

• latência.

Aplicação:

• erros;

• exceções;

• tempo de resposta;

• sessões;

• threads;

• conexões.

Banco de dados:

• locks;

• deadlocks;

• I/O;

• buffer pools;

• consultas lentas;

• contenção.

Negócio:

• logins realizados;

• pagamentos concluídos;

• cartões autorizados;

• transferências processadas;

• saldos consultados;

• falhas por produto.

Esse último grupo é essencial.

O servidor pode apresentar CPU de 40% e ainda assim os clientes não conseguirem pagar contas.

Métricas técnicas dizem como o sistema está respirando.

Métricas de negócio dizem se ele está vivendo.

Em mainframe, podemos utilizar informações provenientes de:

• SMF;

• RMF;

• CICS statistics;

• Db2 accounting;

• logs;

• traces;

• MQ;

• WLM;

• ferramentas de APM.

O segredo é definir limites antes da migração.

Não basta olhar um gráfico e dizer:

— Parece alto.

Devemos saber:

Tempo normal: 300 ms
Limite aceitável: 800 ms
Estado crítico: acima de 2 segundos

Sem baseline, não existe diagnóstico.

---

Capítulo 14 — A equipe também pode entrar em colapso

Grandes viradas frequentemente envolvem equipes trabalhando durante noites, finais de semana e feriados.

A pressão aumenta.

O sono diminui.

A comunicação piora.

Erros simples tornam-se frequentes.

Uma pessoa executa um comando no ambiente errado.

Outra interpreta incorretamente um alerta.

Uma terceira deixa de escalar um problema porque acredita que será resolvido.

Em incidentes graves, o comportamento humano faz parte do sistema.

Por isso uma migração precisa de:

• turnos definidos;

• descanso;

• funções claras;

• canais de comunicação;

• autoridade para abortar;

• registros de decisão;

• responsáveis por cada componente;

• war room estruturada.

Uma boa war room não é uma sala cheia de executivos perguntando a cada cinco minutos se o problema acabou.

É um ambiente disciplinado com:

• líder do incidente;

• especialistas técnicos;

• cronologia;

• hipóteses;

• evidências;

• ações;

• responsáveis;

• próximos passos.

House era brilhante porque testava hipóteses.

Ele não aceitava a primeira explicação.

Na TI, devemos fazer o mesmo.

Sintoma:

Login lento

Hipóteses:

Banco lento
API saturada
Cache vazio
Autenticação com falha
Rede congestionada
Sessões excessivas

Cada hipótese precisa de evidência.

Não de opinião.

---

Capítulo 15 — Um roteiro prático para migrar sem matar o paciente

Para um programador COBOL iniciante, aqui está um roteiro simplificado.

Passo 1 — Inventarie tudo

Liste:

• arquivos;

• tabelas;

• copybooks;

• programas;

• jobs;

• transações;

• interfaces;

• filas;

• relatórios;

• sistemas externos.

Não migre o que você não conhece.

Passo 2 — Descubra as regras escondidas

Leia:

• código COBOL;

• JCL;

• procedures;

• stored procedures;

• documentação;

• logs;

• manuais.

Converse com especialistas antigos.

Eles conhecem as cicatrizes do paciente.

Passo 3 — Crie o mapeamento de dados

Para cada campo:

Origem
Destino
Tipo
Tamanho
Regra de transformação
Valor padrão
Exceções

Exemplo:

ORIGEM: STATUS-CLI PIC X
DESTINO: CUSTOMER_STATUS VARCHAR(20)

A = ACTIVE
B = BLOCKED
E = CLOSED
F = DECEASED

Passo 4 — Teste todos os tipos de registro

Não apenas os casos comuns.

Inclua:

• extremos;

• nulos;

• caracteres especiais;

• registros antigos;

• valores máximos;

• valores negativos;

• exceções.

Passo 5 — Automatize a reconciliação

Compare:

• contagens;

• totais;

• chaves;

• valores;

• relacionamentos;

• exceções.

Passo 6 — Execute ensaios completos

Faça várias migrações simuladas.

Meça:

• duração;

• erros;

• gargalos;

• capacidade;

• tempo de recuperação.

Passo 7 — Teste o rollback

Não apenas no PowerPoint.

Execute de verdade.

Passo 8 — Defina critérios de go/no-go

Exemplo:

Se houver diferença financeira não explicada:
NO-GO

Se o tempo exceder a janela:
NO-GO

Se o rollback não estiver disponível:
NO-GO

Passo 9 — Migre progressivamente quando possível

Reduza o raio de impacto.

Passo 10 — Monitore dados e negócio

Não encerre o projeto quando o sistema ligar.

A estabilização pode durar semanas.

---

Capítulo 16 — Curiosidades da enfermaria mainframe

Primeira curiosidade: sistemas bancários modernos ainda carregam regras criadas décadas atrás.

Não porque ninguém quis modernizá-los, mas porque o dinheiro possui memória.

Um contrato de 1989 pode continuar válido.

Uma hipoteca de vinte anos atrás ainda precisa ser calculada corretamente.

Segunda curiosidade: muitas falhas de migração não são causadas por dados inválidos, mas por dados válidos que o novo sistema não esperava.

O paciente não está mentindo.

O médico apenas nunca viu aquela condição.

Terceira curiosidade: registros encerrados podem ser tão importantes quanto registros ativos.

Auditoria, processos judiciais e reguladores podem exigir histórico por muitos anos.

Quarta curiosidade: a parte mais difícil não é transportar o dado.

É provar que ele chegou corretamente.

Quinta curiosidade: o melhor programador em uma migração pode não ser quem escreve o código mais elegante.

Pode ser aquele analista veterano que pergunta:

— E as contas conjuntas abertas antes da conversão de 1997?

Todos riem.

Depois descobrem 40 mil registros exatamente assim.

---

Easter egg — O diagnóstico diferencial

Na sala de reunião, o painel mostrava milhões de erros.

O gerente perguntou:

— Pode ser vírus?

O especialista em segurança respondeu:

— Não há evidência.

Outro sugeriu:

— Talvez seja a rede.

O DBA culpou a aplicação.

A aplicação culpou o banco.

O banco culpou a infraestrutura.

A infraestrutura culpou o volume.

O programador COBOL permaneceu em silêncio.

House olhou para ele:

— Você sabe alguma coisa.

O programador abriu um copybook escrito em 1994.

Apontou para uma linha:

88 CLIENTE-ESPECIAL VALUE 'X' 'Y' 'Z'.

— A plataforma nova só reconhece X e Y.

Silêncio.

— Quantos clientes possuem Z? — perguntou alguém.

O programador executou uma consulta.

348.721 registros

House sorriu.

— Finalmente alguém examinou o paciente em vez de culpar o estetoscópio.

---

Conclusão — A migração nunca é apenas técnica

O desastre do TSB ensina que grandes migrações não fracassam apenas por causa de código defeituoso.

Elas fracassam quando tecnologia, gestão, planejamento, testes, pessoas e governança deixam de trabalhar como um único organismo.

O custo financeiro ultrapassou a dimensão de um simples incidente.

A reputação do banco foi afetada.

Clientes perderam confiança.

Funcionários enfrentaram enorme pressão.

Reguladores investigaram.

Executivos foram responsabilizados.

Tudo porque a operação foi tratada como um projeto tecnológico quando, na realidade, era uma cirurgia no coração da instituição.

Para um programador COBOL iniciante, a grande lição é esta:

Nunca subestime um campo.

Nunca ignore um copybook antigo.

Nunca confie apenas em amostras.

Nunca aceite uma contagem como prova de integridade.

Nunca acredite que o sistema novo compreende automaticamente o significado do sistema antigo.

Nunca considere rollback apenas uma formalidade.

Nunca deixe a data ser mais importante do que a segurança.

E, sobretudo, lembre-se:

Em ambientes bancários, o programa que você escreve não movimenta apenas números.

Ele movimenta salários.

Aposentadorias.

Economias.

Sonhos.

Casas.

Empresas.

Vidas.

Um erro de uma casa decimal pode parecer pequeno na tela.

Multiplicado por milhões de clientes, ele se transforma em uma catástrofe.

A verdadeira modernização não consiste em abandonar o passado.

Consiste em compreendê-lo profundamente antes de construir o futuro.

Na medicina, o primeiro princípio é não causar dano.

Na engenharia de sistemas críticos, deveria ser o mesmo.

E quando alguém disser:

— É apenas uma migração de dados.

Pegue sua bengala imaginária, olhe para os logs e responda:

— Não. É um transplante de memória. E o paciente ainda está acordado.