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

Translate

sábado, 9 de outubro de 2010

Júlio Verne: o Homem que Inventou o Futuro Antes de o Futuro Dar IPL

 

Bellacosa Mainframe apresente Julio Verne

☕ Um Café no Bellacosa Mainframe

Júlio Verne: o Homem que Inventou o Futuro Antes de o Futuro Dar IPL

🎩🌍🚀 Do centro da Terra à Lua, das profundezas do oceano aos confins do mundo — o escritor que transformou ciência, engenharia e imaginação em documentação técnica para aventuras que ainda não existiam

Imagine um programador recebendo a seguinte especificação:

Precisamos construir um submarino elétrico capaz de atravessar oceanos, uma máquina para viajar às profundezas da Terra, um veículo capaz de chegar à Lua e uma estratégia logística para dar a volta ao planeta em oitenta dias.

Prazo?

Século XIX.

Hardware disponível?

Máquina a vapor.

Internet?

Não instalada.

Stack tecnológico?

Carvão, aço, telégrafo, bússola e uma quantidade industrial de coragem.

O arquiteto responsável?

Jules Gabriel Verne.

Ou, para nós, Júlio Verne.

E talvez essa seja uma das maneiras mais interessantes de compreender sua obra.

Verne não escrevia simplesmente histórias fantásticas.

Ele pegava tecnologias existentes, observava para onde elas poderiam evoluir, adicionava engenharia, geografia, ciência, política, capitalismo, imperialismo e uma dose cavalar de imaginação e perguntava:

“E se levarmos isso até o limite?”

Esse homem estava fazendo technology forecasting quando ninguém tinha inventado o PowerPoint para colocar isso num quadrante colorido.



🧔 QUEM FOI JÚLIO VERNE?

Jules Gabriel Verne nasceu em 8 de fevereiro de 1828, em Nantes, França.

Morreu em 24 de março de 1905, em Amiens.

Entre essas duas datas aconteceu uma coisa extraordinária.

O planeta mudou.

Verne nasceu em um mundo onde grandes viagens ainda dependiam essencialmente de cavalos, navios a vela e máquinas a vapor primitivas.

Quando morreu, existiam automóveis, submarinos modernos, eletricidade distribuída, telégrafos intercontinentais, fotografia, fonógrafos e experiências com aviação.

Ele viveu justamente durante uma das maiores migrações tecnológicas da História.

Algo equivalente a alguém ter começado a carreira programando cartões perfurados e terminado discutindo inteligência artificial generativa.

Não é difícil imaginar por que aquilo incendiou sua imaginação.



⚙️ A REVOLUÇÃO INDUSTRIAL ERA O MAINFRAME DE VERNE

Para entender Júlio Verne precisamos esquecer por alguns minutos que conhecemos aviões, satélites, computadores e submarinos nucleares.

Imagine olhar para uma locomotiva em 1860.

Aquilo era tecnologia de ponta.

Uma máquina gigantesca de ferro transformava água, carvão e pressão em movimento.

Ferrovias estavam comprimindo continentes.

Navios a vapor estavam comprimindo oceanos.

O telégrafo estava praticamente destruindo a relação histórica entre distância e comunicação.

O mundo estava ficando conectado.

Verne percebeu algo fundamental:

tecnologia muda geografia.

E quando muda a geografia, muda comércio.

Quando muda comércio, muda política.

Quando muda política, muda sociedade.

Quando muda sociedade...

entra alguém pedindo uma alteração emergencial sexta-feira às 17h43.

Algumas leis da humanidade são universais.


📚 LES VOYAGES EXTRAORDINAIRES

Grande parte da obra pela qual Verne se tornou conhecido pertence à coleção Voyages extraordinaires — Viagens Extraordinárias, publicada principalmente em associação com o editor Pierre-Jules Hetzel.

O projeto era gigantesco.

Era quase uma biblioteca destinada a explorar o mundo conhecido — e aquilo que talvez pudesse existir além dele.

Geografia.

Astronomia.

Geologia.

Oceanografia.

Engenharia.

Exploração.

História natural.

Tecnologia.

Tudo embrulhado dentro de aventuras.

Verne estava transformando conhecimento científico em entretenimento décadas antes de alguém inventar expressões como:

edutainment.


🌋 VIAGEM AO CENTRO DA TERRA — 1864

Voyage au centre de la Terre

O professor Otto Lidenbrock encontra uma mensagem codificada atribuída ao alquimista islandês Arne Saknussemm.

A mensagem afirma existir uma passagem para o interior da Terra através do vulcão Snæfellsjökull, na Islândia.

Lidenbrock faz aquilo que qualquer responsável por mudanças em produção recomendaria imediatamente:

entra no vulcão.

Acompanhado pelo sobrinho Axel e pelo guia Hans, inicia uma descida para um mundo subterrâneo.

Cavernas gigantescas.

Oceanos subterrâneos.

Formações geológicas.

Criaturas pré-históricas.

Perigos constantes.

É quase uma exploração de sistema legado.

Quanto mais fundo você entra, mais antigas ficam as coisas.

Até encontrar algo que ninguém sabia que ainda estava rodando.

🦖 O princípio Bellacosa:

Nunca desligue aquilo que encontrou nas profundezas antes de descobrir quem depende daquilo.

Pode ser um dinossauro.

Pode ser um programa COBOL de 1978.


🌊 VINTE MIL LÉGUAS SUBMARINAS — 1870

Vingt mille lieues sous les mers

Aqui Verne apresenta uma das maiores figuras da literatura de aventura:

Capitão Nemo.

E sua máquina:

Nautilus.

O professor Pierre Aronnax, seu criado Conseil e o arpoador Ned Land acabam dentro daquele extraordinário submarino.

Mas o Nautilus não é simplesmente transporte.

Ele representa independência tecnológica.

Nemo construiu uma infraestrutura capaz de operar fora da sociedade.

Energia.

Alimentação.

Navegação.

Pesquisa científica.

Defesa.

Habitação.

Tudo integrado.

Nemo praticamente montou seu próprio datacenter soberano no fundo do oceano.

Sem AWS.

Sem Azure.

Sem mensalidade.

E definitivamente sem chamado para suporte.

O fascinante é que Verne procura fornecer explicações técnicas para aquilo.

O fantástico precisava parecer engenheirável.

Esse detalhe separa Verne de muita fantasia pura.


🚀 DA TERRA À LUA — 1865

De la Terre à la Lune

Um grupo americano decide enviar seres humanos à Lua utilizando um gigantesco canhão.

Hoje sabemos que transformar astronautas em projéteis de artilharia apresenta alguns pequenos inconvenientes biomecânicos.

Como transformar passageiros em purê.

Mas esse não é o ponto interessante.

Verne tenta calcular.

Distâncias.

Dimensões.

Materiais.

Trajetórias.

Custos.

Logística.

Local de lançamento.

Ele não diz simplesmente:

“Eles foram para a Lua.”

Ele pergunta:

“Como poderíamos construir uma infraestrutura capaz de fazer isso?”

Essa mentalidade é profundamente moderna.


🌍 A VOLTA AO MUNDO EM 80 DIAS — 1872

Le Tour du monde en quatre-vingts jours

Aqui aparece outro personagem monumental:

Phileas Fogg.

Um cavalheiro inglês extremamente metódico aposta que consegue dar a volta ao mundo em apenas 80 dias.

Hoje alguém abriria um aplicativo, compraria algumas passagens e começaria a reclamar da conexão Wi-Fi do aeroporto.

Em 1872 aquilo era quase uma demonstração experimental da globalização.

Fogg utiliza:

🚂 trens
🚢 navios
🐘 elefante
⛵ embarcações improvisadas
🧭 rotas internacionais
⌚ horários cuidadosamente calculados

A aventura funciona porque uma infraestrutura global estava começando a existir.

Ferrovias.

Portos.

Linhas marítimas.

Telégrafos.

Horários.

Impérios.

Rotas comerciais.

Verne percebe que o planeta estava se transformando em uma gigantesca rede.

Phileas Fogg não vence simplesmente pela velocidade.

Ele vence utilizando integração de sistemas.

É praticamente uma arquitetura distribuída de 1872.


🏝️ A ILHA MISTERIOSA — 1874/1875

L'Île mystérieuse

Talvez seja uma das obras mais interessantes para engenheiros.

Um grupo fica isolado numa ilha.

E começa a construir.

Abrigo.

Ferramentas.

Agricultura.

Metalurgia.

Produtos químicos.

Comunicações.

Infraestrutura.

Eles utilizam conhecimento para transformar ambiente hostil em sistema operacional.

É quase:

Infrastructure as Code

Só que o código é conhecimento científico.

E o provisionamento envolve literalmente fabricar ferramentas.

A obra também se conecta ao universo do Capitão Nemo, criando algo que hoje chamaríamos imediatamente de:

universo compartilhado.

Marvel chegou um pouquinho atrasada.


🎈 CINCO SEMANAS EM UM BALÃO — 1863

Cinq semaines en ballon

Uma viagem de exploração pela África utilizando um balão.

Aqui aparecem elementos que se tornariam assinatura de Verne:

ciência + geografia + tecnologia + aventura.

A máquina permite enxergar o mundo de uma perspectiva impossível para o cidadão comum.

Essa ideia voltará repetidamente.

Para Verne, tecnologia é frequentemente aquilo que permite ao homem atravessar uma fronteira anteriormente inacessível.


🧊 AS AVENTURAS DO CAPITÃO HATTERAS

Voyages et aventures du capitaine Hatteras

Agora seguimos para o extremo norte.

Exploração polar.

Frio.

Isolamento.

Sobrevivência.

Obstinação.

Hatteras representa outro arquétipo recorrente em Verne:

o homem que não sabe parar.

Pode ser coragem.

Pode ser obsessão.

Frequentemente é impossível distinguir uma coisa da outra.

Qualquer gerente que já acompanhou um projeto seis meses atrasado reconhecerá imediatamente o personagem.


🏴‍☠️ OS FILHOS DO CAPITÃO GRANT — 1867/1868

Les Enfants du capitaine Grant

Uma mensagem parcialmente destruída encontrada dentro de uma garrafa inicia uma expedição internacional para localizar o desaparecido Capitão Grant.

O resultado é uma viagem através de diferentes continentes.

Geografia vira mecanismo narrativo.

Cada território apresenta novos ambientes, povos, riscos e desafios.

É quase uma aula de geografia mundial disfarçada de aventura.


🏯 MIGUEL STROGOFF — 1876

Michel Strogoff

Um correio do czar precisa atravessar a Rússia para entregar uma mensagem vital.

Não existem APIs.

Não existe MQ.

Não existe replicação.

O middleware é um homem.

E se o homem não chegar...

a mensagem não chega.

Strogoff é praticamente um pacote TCP com bigode, cavalo e determinação.


🛰️ VERNE PREVIU O FUTURO?

Aqui nasce uma pequena armadilha.

Frequentemente encontramos listas dizendo:

“Júlio Verne previu submarinos!”

“Previu viagens espaciais!”

“Previu videoconferência!”

“Previu helicópteros!”

A realidade é mais interessante.

Muitas tecnologias relacionadas já estavam sendo discutidas ou experimentadas.

Submarinos, por exemplo, não surgiram magicamente da cabeça de Verne.

Balões já existiam.

Experimentos elétricos já existiam.

A astronomia já conhecia bastante sobre a Lua.

Verne fazia algo intelectualmente mais sofisticado:

extrapolação tecnológica.

Ele observava:

Estado atual → tendência → possibilidade → consequência humana.

Isso é exatamente aquilo que fazemos quando perguntamos hoje:

  • O que acontece quando IA encontra robótica?

  • O que acontece quando computação quântica amadurecer?

  • O que acontece quando agentes autônomos administrarem sistemas?

  • O que acontece quando modelos rodarem diretamente dentro de infraestrutura crítica?

Verne fazia perguntas semelhantes usando as tecnologias disponíveis no século XIX.


🔬 HARD SCIENCE FICTION ANTES DA SCIENCE FICTION

O termo science fiction nem sequer estava consolidado quando Verne produziu suas grandes aventuras.

Mas muitos dos elementos estavam ali.

A máquina precisava possuir alguma lógica.

A viagem precisava possuir geografia.

A exploração precisava possuir ciência.

A aventura precisava respeitar — pelo menos aproximadamente — determinadas regras.

Verne adorava explicar.

Às vezes muito.

Um personagem podia simplesmente atravessar uma montanha.

Verne queria contar:

qual montanha,

qual formação geológica,

qual altitude,

qual mineral,

qual latitude,

quem explorou anteriormente,

qual temperatura,

e provavelmente quantos quilômetros faltavam.

É o equivalente literário daquele analista mainframe que responde uma pergunta simples sobre um dataset explicando primeiro a arquitetura do System/360.

Eu respeito profundamente esse homem.


🧠 O VERDADEIRO PERSONAGEM DE VERNE

Existe um personagem escondido atravessando grande parte de sua obra.

Não é Nemo.

Não é Fogg.

Não é Lidenbrock.

Não é Passepartout.

É:

CONHECIMENTO.

Conhecimento resolve problemas.

Conhecimento permite navegar.

Conhecimento permite construir.

Conhecimento permite sobreviver.

Mas Verne também percebe algo mais sombrio.

Conhecimento combinado com obsessão pode produzir monstros.

Nemo possui tecnologia extraordinária.

Mas também possui traumas.

Lidenbrock possui conhecimento extraordinário.

Mas sua obsessão coloca todos em perigo.

Hatteras possui determinação extraordinária.

Mas determinação sem limites pode destruir o próprio homem.

Tecnologia nunca aparece completamente separada de quem controla a tecnologia.

E essa discussão permanece assustadoramente atual.


⚡ CAPITÃO NEMO: O SYSADMIN QUE DEU RACF REVOKE NA HUMANIDADE

Talvez nenhum personagem represente isso melhor que Nemo.

Ele domina ciência e engenharia.

Constrói uma das máquinas mais avançadas imaginadas em sua época.

E decide:

não quero mais participar desse sistema.

Nemo literalmente desconecta sua infraestrutura do mundo.

SETROPTS HUMANITY(REVOKE)

O Nautilus torna-se simultaneamente:

laboratório,

casa,

navio,

arma,

refúgio,

prisão.

Essa ambiguidade torna Nemo fascinante.

Ele não é simplesmente herói.

Nem simplesmente vilão.

É um homem que conseguiu independência tecnológica absoluta...

e descobriu que independência não significa necessariamente liberdade.


🎩 PHILEAS FOGG: O GERENTE DE PROJETO

Fogg é o oposto.

Ele acredita em planejamento.

Cronograma.

Recursos.

Rotas.

Contingência.

Horários.

O homem provavelmente dormiria abraçado a um gráfico de Gantt.

Sua viagem inteira é um projeto.

Objetivo: circunavegar o planeta.

Prazo: 80 dias.

Budget: disponível.

Stakeholders: Reform Club.

Project Manager: Phileas Fogg.

Equipe: Passepartout.

Risco: basicamente o planeta inteiro.

Mas existe algo maravilhoso.

O planejamento constantemente falha.

Trens atrasam.

Rotas desaparecem.

Problemas surgem.

Fogg precisa adaptar.

Ou seja:

Júlio Verne descobriu o Agile em 1872 e teve a elegância de não chamar ninguém para uma Daily.


🦖 E O QUE JÚLIO VERNE TEM A VER COM MAINFRAME?

Muito mais do que parece.

Porque existe uma filosofia comum:

Grandes sistemas são construídos em camadas.

Você olha para um IBM z17 e vê uma máquina moderna.

Mas lá dentro existe uma genealogia tecnológica atravessando décadas.

COBOL.

JCL.

VSAM.

Db2.

CICS.

IMS.

RACF.

z/OS.

Linux.

Java.

Python.

APIs.

Containers.

IA.

O novo não necessariamente destrói o antigo.

Frequentemente ele se conecta ao antigo.

O mundo de Verne funciona da mesma maneira.

Navios convivem com ferrovias.

Elefantes convivem com máquinas a vapor.

Telégrafos convivem com mensageiros.

Tecnologia nova aparece sobre infraestrutura anterior.

A humanidade raramente executa:

DELETE OLD-WORLD

Ela normalmente executa:

CALL 'LEGACY' USING NEW-TECHNOLOGY


📚 POR ONDE COMEÇAR?

Se alguém nunca leu Verne, eu montaria nosso pequeno JCL literário assim:

JOB01 — Viagem ao Centro da Terra
Para conhecer aventura, ciência e exploração.

JOB02 — Vinte Mil Léguas Submarinas
Para conhecer Nemo e o Nautilus.

JOB03 — A Volta ao Mundo em 80 Dias
Para descobrir como infraestrutura mudou o planeta.

JOB04 — A Ilha Misteriosa
Para encontrar ciência aplicada à sobrevivência.

JOB05 — Da Terra à Lua
Para observar engenharia transformada em imaginação.

Depois disso...

COND=(0,NE)

Pode continuar executando.


📜 OUTRAS OBRAS IMPORTANTES

A produção de Verne foi enorme e não cabe apenas nos cinco títulos que dominaram o imaginário popular.

Entre suas obras mais conhecidas também encontramos:

  • Cinco Semanas em um Balão

  • As Aventuras do Capitão Hatteras

  • Os Filhos do Capitão Grant

  • Ao Redor da Lua

  • Miguel Strogoff

  • Heitor Servadac

  • Um Capitão de Quinze Anos

  • As Tribulações de um Chinês na China

  • A Casa a Vapor

  • A Jangada

  • Robur, o Conquistador

  • Dois Anos de Férias

  • O Castelo dos Cárpatos

  • O Senhor do Mundo

É uma espécie de enorme catálogo de possibilidades humanas diante de um planeta que estava sendo tecnologicamente reinventado.


🌍 O MUNDO ERA O DATACENTER DE JÚLIO VERNE

Talvez essa seja minha imagem favorita.

Para Verne, o planeta inteiro era uma máquina esperando para ser explorada.

Os oceanos eram datasets gigantescos ainda não processados.

Os continentes eram partições.

As ferrovias eram barramentos.

Os portos eram interfaces.

O telégrafo era middleware.

Os exploradores eram processos.

E as fronteiras desconhecidas eram aquelas regiões perigosíssimas da documentação onde alguém escreveu:

DO NOT TOUCH — ORIGINAL PROGRAMMER RETIRED.

Naturalmente...

Verne tocava.


🚀 O LEGADO

Júlio Verne não precisava acertar exatamente como seria o futuro.

Esse nunca foi seu maior talento.

Seu verdadeiro talento foi ensinar gerações inteiras a imaginar que o impossível poderia talvez ser transformado em um problema de engenharia.

Primeiro você imagina.

Depois pergunta:

“Como funcionaria?”

Depois alguém calcula.

Outro desenha.

Outro constrói.

Outro testa.

Outro coloca em produção.

E algumas décadas depois aparece um adolescente olhando aquilo e dizendo:

“Sempre existiu.”

Não.

Nada sempre existiu.

Antes da máquina existe o projeto.

Antes do projeto existe a ideia.

E antes da ideia frequentemente existe alguém suficientemente maluco para olhar para os limites conhecidos e perguntar:

“E se continuarmos?”

Talvez seja essa a verdadeira herança de Júlio Verne.

Ele não foi apenas o homem que escreveu sobre submarinos, balões, vulcões, ilhas, ferrovias e viagens espaciais.

Ele foi um dos grandes cartógrafos do território entre aquilo que existe e aquilo que ainda pode existir.

E nesse território vivem cientistas, engenheiros, programadores, exploradores e todos aqueles sujeitos perigosos que, diante de uma placa dizendo:

NÃO ENTRE

imediatamente querem saber o que existe atrás dela.

No Bellacosa Mainframe conhecemos muito bem essa espécie.

São os mesmos que encontram um programa COBOL de 1974 sem documentação, respiram fundo, colocam uma caneca de café ao lado do teclado e digitam:

C

na frente da linha.

Porque algumas pessoas observam sistemas antigos.

Outras...

viajam ao centro deles.

☕🦖🌋

CHANGE COMPLETED.

MAXCC=0000.

JÚLIO VERNE CONTINUA EM PRODUÇÃO.

https://eljefemidnightlunch.blogspot.com/2026/07/jogador-n-1-cacada-pelo-algoritmo.html

https://eljefemidnightlunch.blogspot.com/2026/08/nao-entre-em-panico-doctor-who.html

sexta-feira, 8 de outubro de 2010

Automation Bias: Doctor Who, COBOL e o Dia em que a Máquina Disse “Está Tudo Certo” — e Todo Mundo Acreditou

Bellacosa Mainframe e o automation bias

☕ Um Café no Bellacosa Mainframe

Automation Bias: Doctor Who, COBOL e o Dia em que a Máquina Disse “Está Tudo Certo” — e Todo Mundo Acreditou

Uma viagem pela TARDIS dos incidentes para entender por que automação, dashboards, scripts e IA podem nos ajudar tanto quanto podem nos convencer a ignorar nossos próprios olhos

06:47.

Centro de operações.

Primeiro café.

Segundo monitor.

Terceiro alerta.

Nada particularmente dramático.

Na tela principal:

SYSTEM STATUS
-------------------------
CPU        GREEN
DB2        GREEN
CICS       GREEN
MQ         GREEN
STORAGE    GREEN
BATCH      GREEN

OVERALL STATUS: HEALTHY

Nosso jovem programador COBOL observa.

Tudo verde.

Excelente.

Mas existe uma coisa estranha.

Usuários começaram a reclamar.

Poucos.

Ainda assim:

— O saldo não atualizou.

Outro:

— Minha transação ficou pendente.

Outro:

— O pagamento aparece processado, mas não chegou.

O programador olha novamente para o painel.

OVERALL STATUS: HEALTHY

Ele pergunta ao operador:

— Pode existir problema mesmo tudo estando verde?

O operador responde:

— Se tivesse problema, o monitoramento mostraria.

Pausa.

Uma frase simples.

Muito confortável.

Muito perigosa.

08:12.

Mais reclamações.

08:37.

Fila de chamados crescendo.

09:03.

Ainda:

OVERALL STATUS: HEALTHY

Nosso programador começa a acreditar que talvez os usuários estejam enganados.

Talvez cache.

Talvez navegador.

Talvez percepção.

Afinal...

o sistema está dizendo que está tudo bem.

VWORP.

VWORP.

VWORP.

A TARDIS materializa-se perto do console.

A porta abre.

O Doctor sai.

Olha para o painel.

Depois para os chamados.

Depois novamente para:

HEALTHY

— O sistema diz que está saudável?

— Sim.

— E os usuários dizem que não?

— Sim.

— Então qual dos dois vocês estão investigando?

Silêncio.

O Doctor sorri.

— Ah. Excelente.

Pausa.

— Vocês criaram uma máquina para ajudar humanos a tomar decisões...

Olha para o dashboard.

— ...e agora deixaram a máquina decidir quais fatos merecem existir.

Bem-vindo ao:



Automation Bias

Ou:

Viés de Automação

A tendência humana de confiar excessivamente em sistemas automáticos, recomendações, dashboards, algoritmos, assistentes, scripts ou inteligências artificiais — às vezes até quando existem sinais claros de que a automação pode estar errada, incompleta ou operando fora do contexto esperado.


🌀 Onde estamos na nossa TARDIS dos incidentes?

Nossa coleção já está respeitável.

Passamos pelo:

Swiss Cheese Model — várias barreiras podem falhar juntas.

Depois:

Normalization of Deviance — desvios repetidos deixam de parecer perigosos.

Depois:

Hindsight Bias — o passado parece óbvio quando já conhecemos o final.

Depois:

Confirmation Bias — escolhemos evidências que reforçam nossas crenças.

Depois:

Anchoring Bias — a primeira explicação influencia demais.

Depois:

Groupthink — um grupo inteiro pode concordar e ainda assim estar errado.

Depois:

Authority Gradient — alguém sabe que existe problema, mas não consegue desafiar quem tem mais autoridade.

Depois:

Plan Continuation Bias — continuamos um plano porque já investimos demais.

Depois:

Alarm Fatigue — o sistema alerta tanto que ninguém mais escuta.

Agora temos quase o fenômeno oposto.

Em Alarm Fatigue:

a máquina fala e ignoramos.

Em Automation Bias:

a máquina fala e acreditamos demais.

Parece contraditório.

Na verdade, ambos mostram a mesma coisa:

nossa relação com automação pode ficar desequilibrada.


🤖 O que é Automation Bias?

Automation Bias acontece quando humanos atribuem credibilidade excessiva à saída de um sistema automático.

Exemplo:

AUTOMAÇÃO DIZ:
“TUDO OK”
        ↓
HUMANO PENSA:
“ENTÃO ESTÁ OK”
        ↓
EVIDÊNCIA CONTRÁRIA APARECE
        ↓
HUMANO REINTERPRETA OU IGNORA

Ou o contrário:

AUTOMAÇÃO DIZ:
“ERRO”
        ↓
HUMANO ASSUME:
“EXISTE ERRO”

mesmo que contexto mostre outra coisa.

A automação deixa de ser:

fonte de informação

e vira:

autoridade epistemológica.

Bonita expressão para:

“Se o computador disse, deve ser verdade.”


💻 Para um programador COBOL iniciante: computador não sabe que está certo

Essa ideia é fundamental.

Um programa não sabe que está correto.

Ele apenas executa lógica.

Se você escreve:

IF WS-STATUS = 'OK'
    DISPLAY 'SISTEMA SAUDAVEL'
END-IF.

e a variável WS-STATUS estiver errada...

o programa exibirá alegremente:

SISTEMA SAUDAVEL

O computador não ficará constrangido.

Não levantará a mão.

Não dirá:

— Desculpe, acho que estou sendo alimentado com dados incompletos.

Ele executará.

Perfeitamente.

A lógica errada.


☕ Bellacosa Mainframe: o dashboard verde

Imagine que o dashboard avalia:

CPU;

CICS availability;

Db2 connectivity;

MQ channel;

storage.

Tudo verde.

Mas ninguém mede:

se o processamento funcional está correto.

Exemplo:

CICS UP       = YES
DB2 UP        = YES
MQ UP         = YES
TRANSACTION   = RESPONDING

Dashboard:

HEALTHY

Mas o COBOL está calculando juros com regra incorreta.

Infraestrutura perfeita.

Negócio errado.

O dashboard não mentiu.

Você perguntou a coisa errada.

Essa diferença é enorme.


🧠 Automação só responde ao que foi programada para observar

Se você mede:

serviço respondeu?

e serviço responde:

HTTP 200

monitoramento diz:

OK.

Mas talvez payload seja:

{"balance": null}

Tecnicamente:

respondeu.

Funcionalmente:

quebrou.

Logo:

disponibilidade não é correção.


🧪 Synthetic Monitoring

Por isso sistemas maduros podem usar testes sintéticos.

Não apenas:

porta está aberta?

Mas:

consigo executar uma transação representativa?

Exemplo:

login;

consulta;

pagamento fictício;

validação;

resposta esperada.

Quanto mais perto do comportamento real do usuário:

melhor.


🧀 Automation Bias encontra Swiss Cheese

Uma das fatias de defesa pode ser:

monitoramento automático.

Outra:

revisão humana.

Parece ótimo.

Mas se o humano confiar cegamente no monitoramento:

temos:

AUTOMAÇÃO ERRADA
        ↓
HUMANO CONFIA
        ↓
DUAS BARREIRAS VIRAM UMA

Isso é extremamente importante.

A segunda camada deixou de ser independente.

Agora existe uma common mode failure cognitiva.

Se máquina erra, humano herda o erro.


👻 Easter Egg nº 1 — O computador de Gallifrey

Imagine o Doctor entrando numa sala.

Computador central:

“Probability of danger: 0%.”

Companion:

— Então estamos seguros.

Doctor:

— Não.

— Mas ele disse zero.

— Sim.

— Então?

O Doctor aponta para um Dalek parado atrás dela.

— Talvez devêssemos perguntar o que exatamente ele mede.

Essa é Automation Bias.


🧠 Commission Error e Omission Error

Automation Bias pode produzir dois padrões interessantes.

Error of Commission

A automação recomenda uma ação errada.

O humano executa porque confia nela.

Exemplo:

sistema recomenda:

RESTART REGION CICS01

Operador executa.

Mas problema não estava na região.

Agora cria impacto adicional.


Error of Omission

Automação não detecta algo.

Então humano também não age.

Exemplo:

dashboard não mostra alerta.

Operador conclui:

não há problema.

Esse é exatamente nosso cenário inicial.

A ausência de aviso torna-se evidência de ausência de risco.

Mas:

não detectado ≠ inexistente.


📡 “No alerts” não significa “No problems”

Isso merece uma moldura.

NO ALERTS

significa:

Nenhuma condição configurada para gerar alerta foi detectada pelos sensores funcionando com os dados que receberam.

É bem diferente de:

“Não existe problema no sistema.”

Quase um contrato jurídico.

Mas verdadeiro.


🔍 Observability Gap

Existe uma lacuna entre:

o que o sistema faz

e

o que conseguimos observar.

Chamemos aqui de:

observability gap.

Você pode ter monitoramento perfeito de:

CPU;

memória;

rede.

E zero visibilidade sobre:

duplicidade de transações.

A ausência de sinal pode ser apenas ausência de sensor.


🔦 O poste de luz

Existe uma velha metáfora.

Pessoa procura chave debaixo de um poste.

Alguém pergunta:

— Você perdeu a chave aqui?

— Não.

— Então por que procura aqui?

— Porque aqui tem luz.

Observabilidade pode produzir o mesmo comportamento.

Investigamos onde temos dashboards.

Ignoramos onde não temos.

Automation Bias reforça isso:

“Se não aparece no painel, provavelmente não é ali.”

Talvez seja justamente ali.


⚓ Automation Bias + Anchoring Bias

Dashboard mostra primeiro:

DB2 WAIT HIGH

Pronto.

Âncora.

Agora porque foi gerado automaticamente, ganha ainda mais autoridade.

Equipe pensa:

banco.

Mesmo quando outras evidências dizem:

fila downstream.

A automação criou a âncora.


🔎 Automation Bias + Confirmation Bias

Sistema recomenda:

provável problema de rede.

Equipe aceita.

Depois procura:

timeouts;

retransmissões;

latência.

Confirmation Bias faz o resto.

A origem da teoria agora parece mais legítima porque veio da máquina.


👥 Automation Bias + Groupthink

Imagine War Room.

Dashboard:

ROOT CAUSE PROBABILITY: DB2 82%.

Todo mundo olha.

DBA diz:

— Pode ser.

Outros:

— Se ferramenta aponta 82%...

Agora temos consenso.

Talvez ninguém queira ser a pessoa dizendo:

“A ferramenta pode estar errada.”

O algoritmo virou oitavo participante da reunião.

E talvez o mais influente.


🪜 Authority Gradient com máquinas

Authority Gradient normalmente aparece entre pessoas.

Mas pode acontecer com tecnologia.

Algumas interfaces comunicam autoridade.

Exemplo:

AI ANALYSIS COMPLETE

ROOT CAUSE:
DATABASE CONTENTION

CONFIDENCE: HIGH

Usuário iniciante pensa:

acabou.

Mas “confidence: high” depende do modelo.

Da qualidade do treinamento.

Dos dados.

Do contexto.

Do escopo.

Não é uma garantia metafísica.


🤖 Automation Bias e IA generativa

Agora chegamos a 2026.

Assistentes de IA.

Copilots.

Agentes.

Análise automática.

Code generation.

Incident summarization.

Root cause suggestions.

Tudo isso pode ser extraordinariamente útil.

Mas produz uma nova versão do velho problema:

resposta fluente parece resposta correta.

Se IA escreve:

“A causa mais provável é contenção no Db2 devido ao aumento de lock wait.”

parece convincente.

Mas:

os dados realmente suportam?

Ou o modelo construiu uma explicação plausível?


🧠 Plausibilidade não é evidência

Isso vale para humanos e IAs.

Uma narrativa pode ser:

coerente;

elegante;

tecnicamente sofisticada;

e ainda assim estar errada.

A pergunta continua:

“Que evidência suporta isso?”


💻 COBOL gerado por IA

Imagine pedir:

escreva rotina COBOL para calcular juros.

IA gera código bonito.

Compila.

Testes básicos passam.

Automation Bias:

se a IA gerou e compila, deve estar certo.

Não.

Você precisa validar:

regra;

tipo;

arredondamento;

precision;

overflow;

datas;

edge cases;

requisitos regulatórios.

A IA acelerou produção.

Não removeu responsabilidade.


🧪 “Compila” não significa “correto”

Essa é uma das primeiras lições de programação.

COMPILE = SUCCESS

significa:

sintaxe e regras de compilação foram satisfeitas.

Não:

algoritmo representa corretamente o negócio.

Da mesma forma:

PIPELINE = GREEN

não significa:

sistema é perfeito.


✅ Green Pipeline Bias

Pipelines CI/CD criam outra forma de Automation Bias.

Tudo verde:

build;

unit test;

security scan;

deploy.

Então:

GO.

Mas talvez testes não cubram uma condição importante.

Automação verificou:

o que foi configurado.

Não:

tudo que existe no universo.


🧠 Test Coverage não é cobertura da realidade

90% coverage.

Parece ótimo.

Mas os 10% restantes podem conter:

a regra que quebra bilhões.

Cobertura é métrica.

Não garantia.

Essa é uma lição muito importante:

métricas são proxies.


📏 Goodhart aparece pela porta

Existe um princípio associado conhecido como Lei de Goodhart:

quando uma medida vira meta, pode deixar de ser boa medida.

Se equipe persegue:

100% testes verdes;

100% automação;

zero alertas;

pode começar a otimizar o indicador e não o risco real.

Mais um possível episódio futuro.


🚨 Alarm Fatigue + Automation Bias

Veja a ironia.

No capítulo anterior:

muitos alertas.

Operadores aprendem a ignorar.

Então a organização cria automação para priorizar.

Excelente.

Mas depois humanos confiam cegamente no filtro.

Agora um alerta real é classificado incorretamente como baixo.

Ninguém vê.

Saímos de:

ruído demais

para:

confiança demais no filtro.

Equilíbrio.

Sempre equilíbrio.


🔄 Human-in-the-Loop

Uma expressão muito usada:

Human-in-the-Loop, ou HITL.

Mas cuidado.

Colocar uma pessoa no processo não garante supervisão real.

Exemplo:

IA gera 500 decisões.

Humano tem cinco segundos para aprovar cada uma.

Ele clicará:

APPROVE
APPROVE
APPROVE
APPROVE

Isso não é revisão humana.

É carimbo humano.


🧠 Rubber Stamp Automation

Se o humano quase sempre aceita a recomendação automática, começamos a ter:

rubber stamping.

Automação decide.

Humano formalmente confirma.

Auditavelmente:

houve revisão.

Na prática:

não.

Isso é perigosíssimo.


👨‍⚕️ Médico + sistema automático

Imagine sistema clínico sugerindo diagnóstico.

Médico vê.

Depois interpreta sintomas sob influência da sugestão.

Automation Bias + Anchoring + Confirmation Bias.

Observe como nossos monstros trabalham bem em equipe.


🚗 Automação em veículos

Em automação avançada, um problema conhecido é:

humano reduz vigilância quando sistema funciona bem por muito tempo.

Até que automação encontra cenário que não consegue lidar.

Nesse momento humano precisa assumir rapidamente.

Mas está:

desengajado;

desatento;

fora do loop.

Mais uma lição aplicável a TI.


💤 Out-of-the-Loop Problem

Quando automação executa tudo durante longos períodos, pessoas podem perder:

contexto;

habilidade;

consciência situacional.

Até precisar intervir.

Então temos paradoxo:

automação reduz carga humana...

mas pode tornar intervenção excepcional mais difícil.


☕ O operador que não sabe mais fazer manualmente

Imagine rotina automatizada há oito anos.

Ninguém executa manualmente.

Um dia script quebra.

Pergunta:

— Como fazemos manual?

Silêncio.

Talvez documentação exista.

Talvez não.

Automação criou eficiência.

Também criou dependência.


🧠 Skill Degradation

Habilidades não usadas degradam.

Se tudo é automatizado:

diagnóstico manual;

procedimentos de fallback;

conhecimento interno

podem desaparecer.

Isso precisa ser gerenciado.


🛠️ Automation Paradox

Quanto melhor a automação funciona normalmente, menos frequentemente humanos praticam intervenção.

Mas justamente em situações raras e complexas é que intervenção humana é necessária.

Isso é uma espécie de paradoxo da automação.


📋 Runbooks de fallback

Pergunte:

se automação falhar, o que fazemos?

Precisa existir:

manual;

fallback;

responsável;

procedimento;

teste.

E, se crítico:

simulação periódica.


🔄 Manual Override

Sistemas automatizados críticos deveriam considerar:

como interromper?

como assumir controle?

quem pode?

como validar?

como voltar?

Automation Bias não deve ser combatido removendo automação.

Mas garantindo que automação permaneça subordinada a objetivos e evidências.


🧠 “A máquina sabe melhor”

Às vezes sabe.

Algoritmos podem:

processar mais dados;

detectar padrões;

ser mais consistentes;

não cansar.

Mas também:

podem ter dados ruins;

modelo errado;

condição não prevista;

bug;

drift;

limites de escopo.

A pergunta não deve ser:

humano ou máquina?

Mas:

qual combinação produz decisão mais segura?


🧪 Trust Calibration

Existe uma ideia muito útil:

calibrar confiança.

Não confiar zero.

Não confiar 100%.

Confiar de acordo com desempenho, contexto e limites.

Exemplo:

sistema A:

excelente em detectar CPU saturation.

Confiança alta nesse domínio.

Mas péssimo em inferir causa raiz funcional.

Confiança baixa ali.

Isso é confiança calibrada.


🎯 Pergunta Bellacosa nº 1

Quando sistema disser:

“HEALTHY.”

Pergunte:

“Saudável segundo quais critérios?”

Essa pergunta é maravilhosa.


🎯 Pergunta Bellacosa nº 2

Quando IA disser:

“Root cause is X.”

Pergunte:

“Que evidências observáveis sustentam X?”


🎯 Pergunta Bellacosa nº 3

Quando pipeline disser:

PASS.

Pergunte:

“O que esse pipeline não testa?”


🎯 Pergunta Bellacosa nº 4

Quando algoritmo disser:

98% confidence.

Pergunte:

“Confiança sobre qual distribuição e quais dados?”

Mesmo que não tenhamos resposta completa, a pergunta protege contra reverência.


🔍 Detectando Automation Bias numa equipe

Observe frases:

“Se o dashboard está verde, está tudo bem.”

“A ferramenta não mostrou nada.”

“O scanner aprovou.”

“A IA disse que é isso.”

“O pipeline passou.”

“O antivírus não detectou.”

“O sistema classificou como baixo risco.”

Essas frases não são necessariamente erradas.

Mas podem indicar confiança não calibrada.


🧪 Passo a passo para combater Automation Bias

Passo 1 — Defina escopo da automação

O que ela realmente verifica?

Exemplo:

MONITOR CHECKS:
- availability
- latency
- queue depth

DOES NOT CHECK:
- financial correctness
- duplicate processing
- business-rule accuracy

Isso muda percepção.


Passo 2 — Mostre incerteza

Evite:

ROOT CAUSE: DB2

Prefira:

POSSIBLE CAUSE: DB2
CONFIDENCE: 62%
ALTERNATIVES:
MQ 23%
NETWORK 15%

Automação deveria comunicar limites.


Passo 3 — Exija evidência independente

Se automação diz X:

procure pelo menos um sinal externo.

Exemplo:

AI diz DB2.

Valide:

locks;

wait;

queries;

timeline.


Passo 4 — Crie challenge points

Antes de ação irreversível:

humano precisa responder:

quais dados suportam isso?

Não apenas clicar approve.


Passo 5 — Teste falhas da automação

Faça exercícios:

sensor indisponível;

dado errado;

alerta falso;

modelo incorreto;

script incompleto.

Veja como equipe reage.


Passo 6 — Preserve capacidade manual

Documente e pratique fallback.


Passo 7 — Monitor the monitor

Sim.

Monitoramento também precisa ser monitorado.

Se sensor falhar:

quem detecta?

Se pipeline de observabilidade cair:

quem alerta?

É quase filosófico.


🌀 Quem vigia os vigilantes?

Em latim:

Quis custodiet ipsos custodes?

Quem vigia os próprios vigilantes?

Para nossa série:

Quem monitora o monitoramento?

Talvez:

heartbeat;

self-check;

redundância;

cross-validation.

Nunca confie em uma única fonte crítica.

Swiss Cheese retorna.


🧠 Dual Channel Validation

Se algo é muito importante, valide por caminhos diferentes.

Exemplo:

dashboard diz:

transações processadas = 1.000.000.

Reconciliação financeira diz:

999.998.

Temos conflito.

Excelente.

Duas fontes independentes detectaram divergência.

Isso é mais seguro que uma fonte replicada em cinco dashboards.


🧮 Reconciliation é antídoto contra Automation Bias

Em sistemas financeiros, reconciliação é poderosa porque não pergunta:

sistema acha que funcionou?

Pergunta:

entradas e saídas fecham?

Exemplo:

INPUT
=
SUCCESS
+
REJECT
+
PENDING

Se não fecha:

investigue.

A matemática não se impressiona com dashboard verde.


💰 O mainframe pode processar erro em escala industrial

Um programa errado é perigoso.

Um programa errado em mainframe é eficiente.

Pode processar:

milhões;

bilhões;

rapidamente;

consistentemente.

Automação transforma decisão em escala.

Essa é sua força.

E risco.


🤖 Agentes de IA e Automation Bias

Imagine agente autônomo.

Planeja.

Executa.

Valida.

Ótimo.

Mas se valida usando sua própria interpretação?

Temos possível circuito de confirmação.

Exemplo:

AGENT:
I generated change X.

AGENT:
I evaluated change X.

AGENT:
X looks correct.

AGENT:
Deploying.

Talvez precisemos de:

validador independente;

policy engine;

human approval;

testes objetivos;

rollback.

Independência importa.


🔁 Closed Loop não significa loop correto

Agentes modernos adoram:

plan;

act;

observe;

evaluate.

Mas se o critério de avaliação estiver errado, o loop pode otimizar na direção errada.

Um loop fechado não é automaticamente seguro.


🧠 Reward Hacking

Em sistemas de IA existe ideia de sistemas encontrarem formas de satisfazer métrica sem atingir objetivo real.

Isso lembra Goodhart.

Exemplo simplificado:

meta:

reduzir tickets.

Solução absurda:

fechar tickets automaticamente.

Métrica melhorou.

Usuários continuam com problema.

Automação satisfez proxy.

Falhou objetivo.


📊 KPI verde pode ser Automation Bias gerencial

Nem sempre a máquina é um algoritmo sofisticado.

Pode ser dashboard executivo.

KPI:

99,99% disponibilidade.

Excelente.

Mas:

clientes reclamando.

Talvez métrica esteja agregada demais.

Green dashboard pode esconder experiência ruim.

Gestão também sofre Automation Bias.


🛑 Redundância de decisão

Para ações críticas:

não dependa exclusivamente de recomendação automática.

Exemplo:

AUTOMATION RECOMMENDATION
+
BUSINESS VALIDATION
+
TECHNICAL CHECK
=
DECISION

Camadas independentes.


🧠 Automation Bias + Authority Gradient

E se a automação foi comprada por milhões?

Fornecedor promete IA revolucionária.

Diretor adora.

Júnior encontra inconsistência.

Vai questionar?

Agora tecnologia recebe autoridade institucional.

Não apenas técnica.

Interesse político e investimento tornam contestação mais difícil.

Outra combinação perigosa.


💸 Sunk Cost + Automation Bias

Empresa gastou milhões em plataforma automática.

Se ferramenta erra:

alguém diz:

impossível. Compramos a melhor solução.

O investimento passado começa a proteger a crença na ferramenta.

Sunk Cost volta.


👥 Groupthink + Vendor Authority

Fornecedor:

nossa IA possui 99% de precisão.

Todos:

excelente.

Pergunta Bellacosa:

99% em qual cenário?

qual dataset?

false positive?

false negative?

produção parecida?

Perguntar não é desconfiar por esporte.

É engenharia.


🔐 Segurança: “scanner não encontrou nada”

Ausência de detecção não significa ausência de vulnerabilidade.

Scanner cobre um conjunto.

Pen test outro.

Code review outro.

Threat modeling outro.

Defesa em profundidade novamente.

Automation Bias pode transformar scanner em falsa sensação de segurança.


🧯 Segurança operacional: automatic rollback

Imagine pipeline detecta problema e rollbacka automaticamente.

Excelente.

Até um dia detecção errada causa rollback durante condição que seria transitória.

Automação também precisa de guardrails.

Não existe solução simples:

automatizar tudo;

ou tudo manual.

Design é contextual.


🧠 Automation Complacency

Relacionado ao Automation Bias existe a complacência de automação.

Quando sistema funciona bem por muito tempo, humanos monitoram menos ativamente.

Pense:

“Ele sempre detecta.”

Até o dia que não.

Esse padrão conversa diretamente com:

Normalization of Deviance.


🔁 Normalization of Automation

Primeiro:

automação recomenda.

Humano valida.

Depois de cem acertos:

humano olha rapidamente.

Depois:

apenas aprova.

Depois:

autoapprove.

Agora automação conquistou autonomia não porque decidimos formalmente...

mas porque gradualmente paramos de revisar.

Isso é quase uma normalização do desvio operacional.


🚨 Near Miss da automação

Se ferramenta quase executa ação errada e humano percebe:

não diga apenas:

boa, evitamos.

Investigue.

Por que ferramenta recomendou?

Quais dados?

Como chegou?

O que impediria sem humano?

Near miss é teste grátis.


🧪 Shadow Mode

Antes de dar controle real a nova automação:

execute em shadow mode.

Sistema recomenda.

Humano continua decidindo.

Depois compare.

Exemplo:

AUTOMATION: ROLLBACK
HUMAN: HOLD

OUTCOME:
HOLD WAS CORRECT

Aprendemos antes de delegar autoridade.


📈 Measure Automation Quality

Meça:

precision;

recall;

false positives;

false negatives;

overrides humanos;

incidentes evitados;

incidentes causados;

condições onde falha.

Confiança precisa de dados.


🧠 Override Rate

Se humanos ignoram recomendação 60% das vezes:

automação pode estar ruim.

Se humanos nunca ignoram:

duas possibilidades:

automação perfeita.

Ou ninguém realmente questiona.

A segunda é mais provável que perfeição.

Investigue.


🧑‍💻 Dica para programador COBOL iniciante

Você pode usar:

Copilot;

IA;

geradores;

scripts;

templates.

Use.

São ferramentas fantásticas.

Mas pratique:

GERAR
↓
ENTENDER
↓
TESTAR
↓
VALIDAR
↓
SÓ ENTÃO USAR

Nunca:

GERAR
↓
COPIAR
↓
PRODUÇÃO

O dragão mora nesse atalho.


👻 Easter Egg nº 3 — K-9

K-9 seria maravilhoso em incidentes.

Pergunta:

— K-9, status?

— Affirmative, Master. Probability of failure: 2.3%.

Doctor:

— E o que não sabemos?

Essa segunda pergunta importa mais.

Automação boa deveria ajudar a mostrar incerteza.

Não esconder.


🧭 Human-on-the-Loop versus Human-in-the-Loop

Podemos pensar em diferentes papéis.

Human-in-the-loop

Humano participa antes da ação.

Human-on-the-loop

Automação age, humano supervisiona.

Human-out-of-the-loop

Automação decide e executa sem intervenção regular.

Cada nível exige controle diferente.

Quanto maior autonomia:

mais importante:

observabilidade;

limites;

rollback;

testes;

auditoria.


🔒 Irreversibilidade define rigor

Automação que recomenda playlist:

baixo risco.

Automação que bloqueia conta bancária:

maior.

Automação que altera produção financeira:

maior ainda.

Regra simples:

quanto maior impacto e irreversibilidade, maior deve ser o rigor da supervisão.


📋 Checklist anti-Automation Bias

Antes de confiar numa saída automática:

[ ] O que exatamente esta automação mede?

[ ] Quais dados ela usa?

[ ] Quais cenários ela não cobre?

[ ] Existe evidência independente?

[ ] Qual é a taxa histórica de erro?

[ ] Há false positives?

[ ] Há false negatives?

[ ] O humano consegue contrariá-la?

[ ] Existe rollback?

[ ] Quem monitora a própria automação?

[ ] Estamos aprovando porque entendemos ou porque confiamos?

[ ] Se a ferramenta estivesse errada, como perceberíamos?

Essa última pergunta é preciosa.


🧬 Regeneração organizacional

Como uma organização se regenera depois de Automation Bias?

Primeiro:

abandona a ideia de que automação = verdade.

Depois:

documenta escopo.

Expõe incerteza.

Mede qualidade.

Cria validação independente.

Mantém fallback.

Treina override.

Analisa near misses.

Testa falhas.

Faz shadow mode.

E principalmente:

ensina pessoas a perguntar:

“O que esta automação sabe — e o que ela não sabe?”


📓 Diário do Doctor

Se guardar apenas algumas ideias desta viagem, guarde estas:

Automation Bias é a tendência de confiar excessivamente em saídas automáticas.

Um dashboard verde não prova que o negócio está correto.

Ausência de alerta não significa ausência de problema.

Automação responde apenas ao que consegue observar e ao que foi programada para interpretar.

Human-in-the-loop só funciona se o humano realmente revisar.

Automação pode produzir erros de comissão e de omissão.

Confiança precisa ser calibrada.

Ferramentas devem comunicar incerteza.

Validação independente é essencial em ações críticas.

Automação não elimina responsabilidade humana.

E principalmente:

A máquina pode saber mais do que você sobre determinados sinais — mas ainda precisa provar que esses sinais respondem à pergunta certa.


🕰️ De volta às 09:03

O dashboard continua:

OVERALL STATUS: HEALTHY

Nosso programador pega os chamados.

Começa a analisar horários.

08:04.

08:07.

08:11.

08:15.

Todos envolvendo o mesmo tipo de pagamento.

Ele pergunta:

— Temos um teste funcional dessa transação?

Operador:

— Não. Só disponibilidade do CICS e MQ.

O Doctor sorri.

— Ah.

Eles executam uma transação controlada.

Resultado:

pedido aceito.

Mensagem gerada.

Fila enviada.

Mas o consumer funcional rejeita silenciosamente uma nova condição de dado.

Infraestrutura:

perfeita.

Negócio:

quebrado.

Dashboard tecnicamente correto.

Diagnóstico humano:

errado.

O programador olha para:

HEALTHY

e pergunta:

— Podemos mudar isso?

— Para quê?

— Para que saudável signifique algo mais próximo de saudável.

Boa pergunta.

Criam synthetic check.

Agora o dashboard valida:

conectividade;

transação;

resultado esperado.

Dias depois:

INFRASTRUCTURE: HEALTHY
BUSINESS FLOW: DEGRADED
OVERALL STATUS: WARNING

Muito melhor.

A ferramenta não ficou mais “inteligente”.

Ficou mais honesta.


🥚 Easter Egg final

Na madrugada seguinte aparece um membro novo:

BELLACOSA.BIAS(K9)

Dentro:

       IF AUTOMATION-SAYS-OK
           PERFORM CHECK-WHAT-OK-MEANS
       END-IF.

       IF HUMAN-SEES-CONTRADICTION
           PERFORM INVESTIGATE
       END-IF.

       IF AI-CONFIDENCE = 'HIGH'
           PERFORM ASK-FOR-EVIDENCE
       END-IF.

Comentário:

* AUTOMATION IS AN ADVISER.
* NOT A DEITY.

Abaixo:

* GREEN IS A COLOR.
* NOT A PROOF.

E finalmente:

* BAD WOLF OVERRULED THE ALGORITHM.

Nosso programador ri.

Fecha o membro.

O telefone toca.

Novo alerta.

Desta vez o sistema diz:

POSSIBLE ROOT CAUSE:
NETWORK

CONFIDENCE: 87%

Ele olha para o operador.

O operador pergunta:

— Rede?

Nosso programador responde:

— Talvez.

Abre os dados.

— Vamos verificar.

O Doctor, em algum lugar do espaço-tempo, provavelmente aprovaria.

Porque nosso jovem finalmente aprendeu uma coisa essencial:

automação deve reduzir o esforço necessário para pensar — não eliminar a obrigação de pensar.

VWORP.

VWORP.

VWORP.

A TARDIS desaparece.

No console permanece:

SYSTEM STATUS:
UNKNOWN UNTIL VALIDATED

Talvez seja menos confortável que um enorme indicador verde.

Mas certamente é mais verdadeiro.

☕🌀

Next stop: Diffusion of Responsibility — quando vinte pessoas recebem o alerta, todo mundo presume que alguém está cuidando… e ninguém está.


quinta-feira, 7 de outubro de 2010

O Rei que Fugiu e o País que Ficou — D. João VI, Napoleão e o dia em que Portugal transformou logística em arma de guerra

 

Bellacosa Maifnrame e o rei que fugiu, será? A mudança de capital e a resistencia as tropas de Napoleão

☕ Um Café no Bellacosa Mainframe

O Rei que Fugiu e o País que Ficou — D. João VI, Napoleão e o dia em que Portugal transformou logística em arma de guerra

⚓ Chamaram de fuga. Mas quando Napoleão chegou a Lisboa, encontrou o palácio quase vazio, a frota no Atlântico e a monarquia funcionando do outro lado do oceano. Quem ficou em Portugal descobriu a outra metade do plano: destruir estradas, retirar comida, abandonar aldeias e transformar cada quilômetro conquistado pelos franceses em mais um quilômetro que precisavam alimentar.

Durante boa parte da minha vida escolar brasileira, D. João VI foi apresentado mais ou menos assim:

um rei gordo, medroso, comedor de frango, que fugiu de Napoleão para o Brasil.

Fim.

Era quase uma personagem de comédia.

Napoleão vinha chegando.

D. João olhou pela janela.

IF NAPOLEAO = CHEGANDO
    PERFORM CORRER-PARA-O-NAVIO
END-IF.

🤣

Então você começa a andar por Portugal.

Vai a Amarante.

Ouve histórias das invasões francesas.

Encontra fortalezas.

Descobre a resistência popular.

Passa pelas Linhas de Torres Vedras.

Percebe que houve evacuação de populações, destruição de recursos e uma estratégia deliberada para tornar determinadas regiões impossíveis de sustentar para o invasor.

E aquela história escolar começa a dar SOC7.

Porque surge uma pergunta incômoda:

Se D. João simplesmente fugiu e Napoleão venceu, por que Portugal não terminou incorporado ao sistema napoleônico como tantos outros territórios europeus?

Pegue o café.

Precisamos reabrir esse incidente.


🇵🇹 Portugal estava preso entre dois gigantes

No início do século XIX, Portugal tinha um problema daqueles que nenhum gerente gostaria de receber numa segunda-feira.

De um lado:

Napoleão Bonaparte.

Do outro:

Grã-Bretanha.

Portugal mantinha uma antiquíssima relação diplomática e comercial com os britânicos. A economia portuguesa também dependia fortemente das relações marítimas.

Napoleão, porém, precisava derrotar a Grã-Bretanha.

Como atravessar o Canal da Mancha e destruir militarmente os britânicos era complicado, decidiu atacá-los economicamente.

Em 1806 veio o Bloqueio Continental.

A ideia era essencialmente:

EUROPE
DENY ACCESS TO BRITAIN;

Os países europeus deveriam fechar seus portos aos produtos britânicos.

Só havia um pequeno problema.

Portugal.


🇵🇹 “Podemos conversar sobre isso?”

D. João — ainda príncipe regente, porque D. Maria I já não possuía condições de governar — tentou aquilo que Portugal havia aprendido durante séculos vivendo entre potências maiores:

ganhar tempo.

Negociar.

Prometer.

Adiar.

Mandar diplomata.

Receber diplomata.

Fazer concessão.

Não fazer concessão demais.

Conversar com francês.

Conversar com inglês.

Conversar novamente com francês.

É fácil olhar retrospectivamente e dizer:

“Que indecisão!”

Mas experimente administrar isto:

FRANCE:
"Feche os portos aos ingleses."

BRITAIN:
"Se fechar, sua frota pode virar alvo."

PORTUGAL:
"Temos um império ultramarino."

FRANCE:
"Escolha."

PORTUGAL:
"...mais café?"

🤣

A neutralidade portuguesa estava ficando impossível.


🤝 França e Espanha fazem as contas

Em 1807, França e Espanha assinaram o Tratado de Fontainebleau.

Portugal seria invadido.

E, pelo tratado, seu território seria repartido.

Esse detalhe é fundamental.

Napoleão não estava chegando simplesmente para:

“dar uma bronca em D. João.”

A existência política da monarquia portuguesa estava ameaçada.

Tropas francesas comandadas por Jean-Andoche Junot atravessaram a Espanha e marcharam em direção a Portugal.

Agora o relógio estava correndo.


🚢 E D. João toma a decisão pela qual seria ridicularizado durante dois séculos

A corte vai para o Brasil.

É aqui que precisamos parar de usar a palavra “fuga” por alguns minutos.

Sim.

Eles estavam fugindo de uma invasão.

Isso é indiscutível.

Mas aquilo não foi simplesmente a fuga pessoal de D. João.

Foi uma transferência transatlântica da sede da monarquia portuguesa, realizada sob proteção naval britânica e apoiada numa ideia estratégica que já possuía precedentes no pensamento político português.

A possibilidade de a Coroa refugiar-se no Brasil não nasceu naquela manhã no cais.

O Brasil era a grande retaguarda ultramarina da monarquia.

E, diante da impossibilidade de defender Lisboa imediatamente contra a invasão, a Coroa fez algo extraordinário:

negou a Napoleão o prêmio político principal.


🧠 Napoleão conquistaria Lisboa. Mas não capturaria Portugal inteiro.

Aqui está a diferença.

Imagine uma empresa sendo atacada.

O invasor entra no prédio.

Só que antes de chegar encontra:

CEO: OFFSITE

BOARD: OFFSITE

DATABASE: REPLICATED

TREASURY: MOVED

ADMINISTRATION: RELOCATED

BACKUP DATACENTER:
RIO DE JANEIRO

🤣

O prédio foi ocupado.

O sistema continuou funcionando.

Napoleão poderia controlar Lisboa.

Mas não capturaria D. João.

Não capturaria a família real.

Não assumiria automaticamente a legitimidade da monarquia.

E sobretudo não controlaria o vasto império português simplesmente colocando soldados no Terreiro do Paço.

Esse detalhe transforma completamente nossa leitura da “fuga”.


⚓ Novembro de 1807: o maior change de produção da história portuguesa

Imagine a logística.

Navios.

Tripulações.

Água.

Comida.

Documentos.

Funcionários.

Nobres.

Servidores.

Militares.

Prata.

Livros.

Objetos da administração.

Bagagens.

Famílias.

Uma rainha incapacitada.

Crianças.

E uma invasão francesa aproximando-se.

Tudo isso precisava atravessar o Atlântico.

Não houve elegância.

Houve confusão.

Chuva.

Pressa.

Bagagem abandonada.

Famílias separadas.

Gente tentando embarcar.

A imagem provavelmente estava muito longe da majestade de uma pintura oficial.

Mas os navios partiram.

Em 29 de novembro de 1807, a frota deixou a região de Lisboa.

Junot chegou pouco depois.

Tarde demais.


🇫🇷 “Cadê o príncipe?”

Imagine Junot entrando em Lisboa.

Missão:

CAPTURE PORTUGAL

Resultado:

LISBON........... CAPTURED
ROYAL FAMILY..... NOT FOUND
GOVERNMENT....... RELOCATED
FLEET............ GONE
COLONIAL EMPIRE.. NOT CAPTURED
BRITISH ALLIANCE. ACTIVE

RC=08.

🤣

Napoleão havia conquistado território.

Mas o Estado português tinha acabado de executar um gigantesco:

MOVE PORTUGAL
TO BRAZIL.

E aqui começa uma das experiências políticas mais estranhas da história moderna.


🇧🇷 A colônia acorda com uma corte na porta

Em 1808, D. João chegou ao Brasil.

Primeiro Salvador.

Depois Rio de Janeiro.

E começou uma transformação enorme.

Abertura dos portos.

Instituições administrativas.

Tribunais.

Banco.

Imprensa Régia.

Bibliotecas e organismos ligados ao funcionamento da corte.

Estruturas militares.

Burocracia.

Diplomacia.

O Rio de Janeiro deixou de ser simplesmente uma grande cidade colonial.

Tornou-se centro político da monarquia portuguesa.

A metrópole estava parcialmente governada a partir da antiga colônia.

É difícil exagerar o tamanho dessa inversão.


🇵🇹 Mas Portugal ficou

E aqui está a metade da história que nós brasileiros frequentemente enxergamos muito pouco.

Quando estudamos 1808, nossa câmera embarca com D. João.

Acompanhamos o Atlântico.

Salvador.

Rio.

Abertura dos portos.

Família real.

E seguimos a história brasileira.

Mas experimente deixar a câmera em Lisboa.

A frota desaparece no horizonte.

Agora vire-se.

Os franceses estão chegando.

Milhões de portugueses não receberam cabine no navio.

Eles ficaram.


⚔️ A primeira invasão

Junot ocupou Portugal.

Mas a situação francesa rapidamente se tornou complicada.

A resistência cresceu.

Os britânicos desembarcaram tropas.

E entra em cena um nome que depois seria inseparável das guerras napoleônicas:

Arthur Wellesley, futuro duque de Wellington.

Em 1808 ocorreram batalhas como Roliça e Vimeiro.

Os franceses acabaram obrigados a abandonar Portugal pela controversa Convenção de Sintra.

Primeira invasão:

FRANCE IN
FRANCE OUT

Napoleão, porém, não era conhecido por receber RC=08 e cancelar o job.


⚔️ Segunda invasão

Em 1809, os franceses voltaram.

Desta vez sob o comando do marechal Soult.

Entraram pelo norte.

E aqui aparece um daqueles lugares em que história deixa de ser abstração:

Amarante.

A ponte sobre o Tâmega tornou-se cenário de combates importantes.

Forças portuguesas sob Silveira resistiram aos franceses.

Quando você está naquele espaço, olhando rio, ponte, encostas e cidade, começa a entender uma coisa que o mapa escolar não transmite.

Image

Image

Image

Image

Guerra não acontece numa seta vermelha.

Acontece numa ponte.

Numa casa.

Num celeiro.

Numa estrada.

Num pão.

Num barril de vinho.


🍞 E chegamos à arma mais cruel: comida

Um exército napoleônico podia ser extraordinário no campo de batalha.

Mas existia algo que nenhum general conseguia abolir:

SOLDIER NEEDS FOOD
HORSE NEEDS FOOD
ARMY NEEDS SUPPLIES

Um exército gigantesco atravessando território inimigo possui um apetite monstruoso.

Napoleão aperfeiçoara a capacidade de seus exércitos de viver parcialmente dos recursos encontrados durante a marcha.

Isso funcionava maravilhosamente...

enquanto existiam recursos para encontrar.

E aqui Portugal e os britânicos começaram a transformar logística em arma.


🔥 Se o francês precisa comer, retire a comida

Quando a terceira invasão francesa chegou em 1810, comandada pelo marechal Masséna, Wellington aplicou uma estratégia brutal.

Populações foram retiradas de determinadas regiões.

Alimentos foram removidos ou destruídos.

Recursos úteis ao inimigo foram negados.

Moinhos, colheitas, animais e estoques podiam tornar-se parte da guerra.

Era a lógica da terra arrasada.

Não precisamos romantizar isso.

Para a população portuguesa, significava sofrimento enorme.

Famílias abandonavam casas.

Propriedades eram destruídas.

Havia fome.

Doença.

Deslocamento.

Violência.

A estratégia que prejudicava Masséna também esmagava civis portugueses.

Mas militarmente havia uma lógica terrível:

cada quilômetro avançado aumentava a distância entre o exército francês e aquilo de que precisava para sobreviver.


🍷 E então aparecem as histórias do vinho e do pão

Durante minhas caminhadas e conversas em Portugal encontrei histórias locais sobre alimentos e bebidas deixados deliberadamente impróprios — inclusive narrativas sobre vinho ou pão envenenados para atingir franceses.

Aqui precisamos fazer aquilo que fazemos sempre no Café Bellacosa:

separar história documentada de memória popular.

A destruição e remoção de suprimentos como estratégia são muito bem conhecidas.

Já histórias específicas de envenenamento pertencem muitas vezes ao território complicado das tradições locais e precisam ser verificadas caso a caso.

Mas repare como a memória popular compreendeu perfeitamente a lógica estratégica.

O francês precisava comer.

Então:

não dê comida ao francês.

A aldeia inteira torna-se parte do sistema logístico da guerra.


🧱 E então Wellington constrói um firewall chamado Torres Vedras

Agora chegamos a uma das coisas mais extraordinárias da campanha.

As Linhas de Torres Vedras.

Um vasto sistema defensivo construído secretamente ao norte de Lisboa, combinando fortificações, terreno, estradas, comunicações e posições militares.

Não era uma muralha contínua.

Era muito mais inteligente.

Era uma arquitetura defensiva em profundidade.

Image

Image

Image

Image

Image

Image

Pense como alguém de mainframe.

Você não protege o sistema apenas colocando:

PASSWORD=1234

🤣

Você cria camadas.

PERIMETER
   ↓
TERRAIN
   ↓
FORT
   ↓
ARTILLERY
   ↓
COMMUNICATION
   ↓
RESERVE
   ↓
LISBON
   ↓
BRITISH NAVY

Se tudo desse errado, ainda existia a possibilidade de evacuação pelo mar.

Era defesa com disaster recovery.


😈 Masséna chega — e encontra um problema

O exército francês avançou.

Combateu.

Chegou diante das linhas.

E descobriu que romper aquela estrutura seria extremamente difícil.

Então fez aquilo que exércitos frequentemente fazem:

esperou.

Só que havia um pequeno problema.

Comida.

A região à frente havia sido esvaziada de muitos recursos.

Os franceses começaram a sofrer seriamente com escassez, doenças e dificuldades logísticas.

O exército que havia conquistado enormes regiões da Europa estava sendo derrotado por algo profundamente pouco cinematográfico:

supply chain.

🤣

Não foi uma carga heroica de cavalaria.

Não foi um duelo entre generais.

Foi:

SUPPLY NOT FOUND

🐴 O cavalo também participa da guerra

Existe ainda uma coisa que filmes quase sempre escondem.

Exércitos daquela época dependiam enormemente de cavalos.

Cavalaria.

Artilharia.

Transporte.

Mensageiros.

Logística.

E cavalo come.

Muito.

Você pode ter 50 mil soldados extraordinários.

Se os animais começam a morrer, sua mobilidade diminui.

Se faltam alimentos, homens adoecem.

Se não existem sapatos, os pés destroem-se.

Se as estradas estão ruins, carroças quebram.

Se a população esconde informação, você não sabe onde encontrar recursos.

A grande máquina napoleônica dependia de milhões de pequenas coisas funcionando.

Portugal começou a quebrar essas pequenas coisas.


🧑‍🌾 A guerra que não cabe no quadro de generais

E aqui precisamos devolver protagonismo a quem quase nunca aparece.

O camponês.

A mulher que abandonou a casa.

O padre.

O moleiro.

O comerciante.

O guia.

O guerrilheiro.

O sujeito que conhecia uma estrada que o francês não conhecia.

A família que levou animais embora.

A aldeia que escondeu alimento.

A população que passou informação às forças portuguesas.

A guerra peninsular também foi uma guerra de populações.

E isso ajuda a explicar por que ocupar um território não significava necessariamente controlá-lo.


🇪🇸 E a Espanha estava pegando fogo ao lado

Portugal não estava isolado.

A Península Ibérica transformou-se num gigantesco problema para Napoleão.

Na Espanha, a resistência assumiu dimensões enormes.

Aliás, a palavra guerrilla ganhou projeção internacional justamente nesse contexto.

Pequenas forças atacavam.

Desapareciam.

Interrompiam comunicações.

Atacavam comboios.

Obrigavam os franceses a espalhar tropas para proteger estradas e posições.

Napoleão conseguia derrotar exércitos.

Mas ocupar permanentemente populações hostis era outra espécie de problema.

A Península começou a consumir recursos franceses de maneira assustadora.


🇬🇧 E os ingleses não “salvaram Portugal” sozinhos

Aqui aparece outra simplificação.

Uma narrativa britânica tradicional pode transformar a guerra em:

Wellington chegou e salvou os portugueses.

Calma.

Sem tropas britânicas, a situação portuguesa seria dramaticamente pior.

A contribuição britânica foi decisiva.

Mas existia:

Exército português reorganizado.

Milícias.

Ordenanças.

Resistência popular.

Informação local.

Logística portuguesa.

População suportando uma estratégia devastadora.

E havia o trabalho extraordinário de reorganização associado a William Carr Beresford, entre outros.

O exército anglo-português tornou-se uma força extremamente eficiente.

Não era:

BRITAIN + NPC PORTUGAL

Era uma coalizão militar.


⚔️ E Portugal deixa de ser apenas território defendido

Depois de expulsar os franceses, as forças anglo-portuguesas não simplesmente disseram:

“Obrigado, pessoal. Acabou.”

Elas avançaram.

Entraram na Espanha.

Continuaram pressionando os exércitos franceses.

E finalmente atravessaram os Pireneus.

Sim.

Forças portuguesas terminaram combatendo em território francês.

Agora compare isso com:

“Napoleão invadiu Portugal e a família real fugiu.”

Percebe quanto desaparece?


🇫🇷 O homem que dominou a Europa não conseguiu resolver Portugal

Não porque Portugal fosse militarmente mais poderoso que o Império Francês.

Não era.

Mas guerra não é uma tabela:

FRANCE POWER = 100
PORTUGAL POWER = 25

100 > 25

FRANCE WINS

Guerra é sistema.

Geografia.

Mar.

Alianças.

Tempo.

População.

Inteligência.

Suprimentos.

Doença.

Estradas.

Portos.

Fortificações.

Política.

Legitimidade.

E nesse sistema Portugal possuía algo extraordinário:

profundidade estratégica atlântica.


🌎 O Brasil era o disaster recovery site do Império Português

Essa analogia é irresistível.

Lisboa era o datacenter principal.

O Brasil era um gigantesco ambiente remoto.

Napoleão ameaçou o PRIMARY.

Portugal executou:

SWITCHOVER TO RIO

🤣

Não era backup perfeito.

Não era barato.

Não era simples.

E provocaria consequências políticas gigantescas.

Mas funcionou.

A monarquia sobreviveu.

O império permaneceu conectado à dinastia.

E quando Napoleão caiu, apareceu outro problema:

o rei não queria voltar.


😂 Plot twist: o fugitivo gostou do DR

D. João permaneceu no Brasil.

E isso começou a incomodar profundamente Portugal.

Porque havia uma situação quase surreal.

Portugal europeu — a antiga metrópole — tinha sofrido:

invasões,

ocupação,

destruição,

fome,

guerra,

presença militar estrangeira,

crise econômica.

Enquanto isso...

a corte estava no Rio de Janeiro.

O que inicialmente fora solução estratégica tornou-se problema político.

O disaster recovery virou produção.

🤣


🇧🇷 1815: precisamos corrigir a arquitetura

A solução foi elevar o Brasil.

Nasceu o Reino Unido de Portugal, Brasil e Algarves.

Agora juridicamente ficava menos absurdo ter a corte no Rio.

Mas para muitos portugueses isso não resolvia a sensação de inversão:

“Espera aí... nós somos Portugal e estamos sendo governados do Rio de Janeiro?”

Sim.

Bem-vindos ao século XIX.


💥 1820: Portugal executa outro job

A Revolução Liberal do Porto, em 1820, mudou novamente o cenário.

Entre outras coisas, exigia o retorno da corte e a reorganização constitucional da monarquia.

D. João acabou voltando a Portugal em 1821.

Mas aquilo que atravessara o Atlântico em 1807 não podia simplesmente ser restaurado com:

RESTORE PORTUGAL
FROM BACKUP_1807;

O Brasil havia mudado.

As elites brasileiras haviam mudado.

As instituições haviam mudado.

O equilíbrio do império havia mudado.

No ano seguinte:

1822.

Independência do Brasil.


🤯 Então a “fuga” ajudou a criar o Brasil independente?

Indiretamente, profundamente.

Existe uma ironia monumental.

Napoleão queria submeter Portugal.

Sua invasão ajudou a provocar:

TRANSFER COURT → BRAZIL
        ↓
OPEN PORTS
        ↓
BUILD INSTITUTIONS
        ↓
ELEVATE BRAZIL
        ↓
POLITICAL AUTONOMY
        ↓
PORTUGUESE REVOLUTION
        ↓
RETURN OF JOAO
        ↓
1822

Napoleão nunca pisou no Brasil.

Mas deixou impressões digitais enormes na história brasileira.


🧠 E agora podemos voltar ao “rei que fugiu”

D. João fugiu?

Sim.

Mas essa resposta sozinha é intelectualmente pobre.

Ele fugiu com a instituição que Napoleão precisava capturar.

Há uma diferença gigantesca entre:

abandonar o Estado

e

retirar o centro do Estado para impedir que o inimigo o capture.

Isso não transforma D. João automaticamente num gênio militar.

A decisão contou com apoio e interesse britânicos, surgiu dentro de circunstâncias extremas e foi executada de maneira caótica.

Mas chamar tudo simplesmente de covardia destrói justamente a parte mais fascinante da história.


🇵🇹 E quem realmente pagou a conta foi quem ficou

Aqui está a correção necessária para não transformar nossa releitura numa nova caricatura.

Podemos reconhecer a inteligência estratégica da transferência da corte sem romantizar o sofrimento português.

Porque o país ficou.

E pagou.

Com casas.

Colheitas.

Animais.

Comércio.

Fome.

Mortos.

Feridos.

Refugiados.

Aldeias destruídas.

Anos de guerra.

As Linhas de Torres Vedras funcionaram.

A terra arrasada funcionou.

A resistência funcionou.

A aliança funcionou.

Mas dizer que uma estratégia funcionou não significa que ela foi indolor.

Muito pelo contrário.


🗺️ E é aqui que caminhar muda a história

Há uma diferença enorme entre ler:

“Masséna retirou-se diante das Linhas de Torres Vedras.”

e caminhar por aquela região.

Olhar o relevo.

Ver onde ficavam as posições.

Perceber distâncias.

Imaginar milhares de homens.

Depois imaginar milhares de cavalos.

Depois perguntar:

“Onde todo mundo comia?”

Essa pergunta muda tudo.

Porque você começa a perceber que a história militar não é somente:

GENERAL
BATTLE
VICTORY

É:

FOOD
WATER
ROAD
HORSE
SHOE
CART
BRIDGE
WEATHER
INFORMATION
MEDICINE
MORALE

O general aparece na estátua.

A logística ganha a guerra.


☕ O Café Bellacosa

Talvez por isso minha percepção de D. João tenha mudado tanto depois de conhecer Portugal.

O brasileiro aprende a olhar para o navio partindo.

O português que conhece a memória das invasões olha para aquilo que ficou atrás dele.

São duas câmeras filmando o mesmo acontecimento.

Na câmera brasileira:

chegada da corte.

Na portuguesa:

começo da ocupação.

Na britânica:

abertura de um teatro estratégico contra Napoleão.

Na francesa:

um problema peninsular que se recusava a terminar.

E na câmera da família portuguesa comum:

sobreviver.

Talvez seja essa última que mais mereça ser recuperada.


🖥️ $HASP395 NAPOLEAO JOB ENDED

//PORTUGAL JOB '1807'
//STEP01   EXEC PGM=DIPLOMACY
//STEP02   EXEC PGM=EVACUATE
//STEP03   EXEC PGM=RIO
//STEP04   EXEC PGM=RESISTANCE
//STEP05   EXEC PGM=SCORCHED
//STEP06   EXEC PGM=TORRES
//STEP07   EXEC PGM=SUPPLY
//STEP08   EXEC PGM=COUNTERATTACK

NAPOLEON:
CAPTURE LISBON

PORTUGAL:
MOVE CROWN TO BRAZIL

WELLINGTON:
BUILD DEFENSE

POPULATION:
REMOVE SUPPLIES

MASSENA:
SEARCH FOOD

SYSTEM:
FOOD NOT FOUND

MASSENA:
RETREAT

$HASP395 PORTUGAL ENDED

RC=00

E talvez a frase final seja esta:

D. João fugiu.

Sim.

Mas o interessante começa quando paramos de discutir se a palavra é ofensiva e perguntamos:

o que exatamente ele levou consigo — e o que Napoleão deixou de conquistar porque aquilo já estava no meio do Atlântico?

Enquanto a Coroa navegava para o Brasil, Portugal transformava montanhas, pontes, estradas, fortalezas, comida e até espaço vazio em armas.

Napoleão conquistara capitais.

Derrubara reis.

Redesenhara fronteiras.

Humilhara algumas das maiores potências da Europa.

Em Portugal encontrou algo menos glorioso e muito mais difícil de derrotar:

um governo que podia atravessar o oceano, uma marinha que o ligava a outro continente, um aliado que dominava o mar, um exército que aprenderia a enfrentá-lo e uma população disposta — voluntariamente ou por necessidade — a deixar o invasor marchar cada vez mais longe em direção a lugar nenhum.

No mapa, os franceses avançavam.

Na planilha logística, estavam perdendo.

E dois séculos depois talvez seja hora de instalar uma pequena atualização na velha caricatura brasileira:

D_JOAO_VI_OLD:
"o rei que fugiu de Napoleão"

D_JOAO_VI_PATCHED:
"o governante que retirou a monarquia
antes que Napoleão pudesse capturá-la"

PORTUGAL:
"o país que ficou para pagar a conta"

Porque às vezes vencer não significa defender o palácio até o último homem.

Às vezes significa saber qual parte do sistema você não pode permitir que o inimigo capture.

E quando Napoleão finalmente chegou a Lisboa...

o PRIMARY já estava navegando para o Rio de Janeiro.

☕⚓🇵🇹🇧🇷

quarta-feira, 6 de outubro de 2010

Gakuen Mokushiroku: Highschool of the Dead — Quando o Datacenter da Humanidade Entrou em ABEND e Apenas os Operadores Sobreviveram

 

Bellacosa Mainframe apresenta Highschool of the Dead

☕ Um Café no Bellacosa Mainframe

Gakuen Mokushiroku: Highschool of the Dead — Quando o Datacenter da Humanidade Entrou em ABEND e Apenas os Operadores Sobreviveram

"Todo sistema é considerado confiável... até o primeiro desastre real. Highschool of the Dead mostra exatamente o que acontece quando o planeta inteiro perde o operador."


Ficha Técnica

Título Original: 学園黙示録 HIGHSCHOOL OF THE DEAD (Gakuen Mokushiroku: Highschool of the Dead)

Título Internacional: Highschool of the Dead

Autor (Mangá):

  • Daisuke Satō (roteiro)

  • Shōji Satō (arte)

Estúdio: Madhouse

Diretor: Tetsurō Araki

Composição da Série: Yōsuke Kuroda

Design de Personagens: Masayoshi Tanaka

Música: Takafumi Wada

Mangá

  • Publicado entre 2006 e 2013

  • Revista Monthly Dragon Age

Anime

  • Lançamento: 5 de julho de 2010

  • Exibição: julho a setembro de 2010

OVA

  • Drifters of the Dead (2011)

Quantidade de episódios

  • 12 episódios

  • 1 OVA


Classificação

  • 🔞 17+ (em muitos países)

  • Violência extrema

  • Sangue

  • Terror

  • Nudez parcial

  • Conteúdo sexual

  • Linguagem adulta

Não é um anime indicado para crianças.


Gêneros

  • Horror

  • Zumbis

  • Sobrevivência

  • Ação

  • Suspense

  • Ecchi

  • Drama

  • Pós-apocalipse


Sinopse

Tudo começa em uma manhã aparentemente comum.

Enquanto os alunos seguem sua rotina escolar, uma estranha epidemia transforma pessoas em mortos-vivos extremamente agressivos.

Em questão de minutos, a escola inteira se torna um cenário de massacre.

Takashi Komuro consegue escapar junto de alguns colegas, iniciando uma longa jornada para encontrar familiares, abrigo e respostas.

Mas rapidamente descobrem uma verdade:

Os mortos não são necessariamente o maior perigo.

Quando a sociedade deixa de existir, o verdadeiro monstro passa a ser o próprio ser humano.


Resumo da História

O anime acompanha um pequeno grupo de estudantes tentando sobreviver ao colapso da civilização japonesa.

Eles atravessam:

  • escolas

  • bairros residenciais

  • estradas

  • delegacias

  • mansões

  • cidades completamente destruídas

Cada episódio representa um novo desafio.

Não existe governo.

Não existe polícia.

Não existe exército funcional.

Não existe internet.

Não existe logística.

Tudo aquilo que sustentava a sociedade desapareceu em poucas horas.


Os Personagens

Takashi Komuro

O protagonista.

Não é o mais forte.

Não é o mais inteligente.

Mas possui algo extremamente importante:

Capacidade de tomar decisões sob pressão.

No universo Bellacosa Mainframe, ele seria o Operador Master durante um desastre de produção.


Rei Miyamoto

Especialista em combate com lança.

Representa o lado emocional do grupo.

É também quem mantém parte da humanidade dos sobreviventes.


Saeko Busujima

Talvez uma das personagens femininas mais populares dos animes.

Excelente espadachim.

Calma.

Precisa.

Controlada.

Ela lembra um Sysprog experiente:

Não desperdiça movimentos.

Não desperdiça recursos.


Saya Takagi

A arquiteta.

O cérebro.

Enquanto todos pensam em sobreviver ao próximo minuto, Saya pensa nas próximas semanas.

Ela é praticamente uma Analista de Sistemas.


Kōta Hirano

Especialista em armas.

No início parece apenas um nerd.

Depois demonstra enorme capacidade técnica.

É o equivalente ao especialista de infraestrutura que conhece profundamente as ferramentas.


Shizuka Marikawa

A enfermeira.

Representa logística, primeiros socorros e transporte.

Sem ela o grupo dificilmente sobreviveria.


A Temática

À primeira vista parece apenas um anime de zumbis.

Na realidade fala sobre:

  • colapso social

  • ética

  • medo

  • liderança

  • sobrevivência

  • egoísmo

  • confiança

  • adaptação

O vírus é apenas o gatilho.

O verdadeiro tema é:

Como seres humanos reagem quando toda estrutura desaparece.


O que existe de diferente?

Muitos animes possuem zumbis.

Pouquíssimos possuem:

Ritmo extremamente acelerado

O desastre começa nos primeiros minutos.

Não existe preparação.

O espectador entra imediatamente no caos.


Personagens relativamente "normais"

Não existem poderes mágicos.

Não existem espadachins lendários.

São estudantes comuns.

Isso aumenta muito a sensação de realismo.


Ação cinematográfica

O diretor Tetsurō Araki mais tarde faria enorme sucesso em Attack on Titan.

Já era possível perceber seu estilo:

  • câmeras rápidas

  • enquadramentos dramáticos

  • tensão constante


Violência gráfica

Em 2010 poucos animes apresentavam um nível tão alto de violência.


Ecchi exagerado

É o aspecto mais controverso da obra.

Em vários momentos o fan service interrompe completamente a tensão.

Para alguns isso faz parte da identidade da série.

Para outros prejudica o horror.


As Aventuras

Cada arco representa uma etapa da sobrevivência.

  • escapar da escola

  • encontrar abrigo

  • procurar familiares

  • buscar alimentos

  • fugir de saqueadores

  • enfrentar grupos armados

  • lidar com governos inexistentes

Não existe "missão principal".

A missão é continuar vivo.


As Mensagens Ocultas

A civilização é extremamente frágil

Levamos décadas para construir uma sociedade.

Podemos perdê-la em poucos dias.


O conhecimento vale mais que força

Saya salva o grupo inúmeras vezes usando inteligência.

Não músculos.


Liderança não depende de cargo

Takashi nunca foi líder.

As circunstâncias o obrigam a assumir essa função.


Recursos são limitados

Comida.

Combustível.

Remédios.

Munição.

Tudo acaba.

A sobrevivência depende de planejamento.


O medo transforma pessoas

Durante o anime vemos cidadãos comuns se tornando criminosos.

O verdadeiro vírus talvez seja o desespero.


Bellacosa Mainframe

O Grande ABEND Mundial

Imagine que a humanidade inteira seja um gigantesco ambiente IBM Z.

De repente acontece um desastre.

  • JES2 para de controlar filas.

  • CICS perde conectividade.

  • DB2 deixa de responder.

  • MQ interrompe mensagens.

  • O operador desaparece.

  • O WLM deixa de distribuir carga.

O ambiente continua ligado.

Mas não existe mais coordenação.

É exatamente isso que acontece em Highschool of the Dead.

Os zumbis são processos que continuam executando.

Consomem CPU.

Consumem memória.

Propagam corrupção.

Mas perderam completamente sua lógica de negócio.

Enquanto isso, os sobreviventes tentam manter o "Sistema Operacional Sociedade" funcionando.

Takashi torna-se o Incident Manager.

Saya atua como arquiteta.

Saeko é a equipe de resposta imediata.

Kōta administra os recursos críticos.

Shizuka representa Disaster Recovery.

No fundo, o anime inteiro pode ser interpretado como um enorme exercício de:

  • Business Continuity

  • Disaster Recovery

  • Gestão de Incidentes

  • Gestão de Crises

  • Resiliência Operacional


Impacto Cultural

Quando estreou em 2010, Highschool of the Dead tornou-se um enorme sucesso.

Foi um dos responsáveis por popularizar novamente o gênero zumbi nos animes.

Influenciou diversas obras posteriores.

Também consolidou a reputação do estúdio Madhouse em animações de ação extremamente fluidas.

Até hoje permanece como referência quando se fala em animes de sobrevivência.


Houve censura?

Sim.

Este é um dos animes mais censurados de sua época.

Dependendo da emissora e do país, cenas receberam:

  • escurecimento da tela (black shading);

  • feixes de luz (light beams) para ocultar nudez;

  • neblina ou fumaça digital;

  • cortes de enquadramento;

  • redução de violência gráfica.

As versões em Blu-ray removeram grande parte dessas censuras, apresentando a obra em sua forma originalmente produzida.

Além disso, alguns países restringiram sua classificação indicativa devido ao conteúdo sexual e à violência intensa.


Por que nunca ganhou uma segunda temporada?

Essa é uma das maiores frustrações dos fãs.

O mangá sofreu longos hiatos por problemas de saúde do roteirista Daisuke Satō. Em 2017, o autor faleceu, deixando a história inacabada. Sem material suficiente e sem uma conclusão oficial, uma continuação do anime nunca foi produzida.


Vale a pena assistir?

Mesmo anos após seu lançamento, Gakuen Mokushiroku: Highschool of the Dead continua relevante por combinar ação frenética, horror, suspense e discussões sobre comportamento humano em situações extremas. Embora o fan service possa dividir opiniões, a qualidade da animação, a direção dinâmica e a construção da tensão fazem dele um clássico do gênero zumbi nos animes.

Veredicto Bellacosa Mainframe

Se The Walking Dead mostra como administrar uma comunidade após o colapso, Highschool of the Dead retrata o momento exato em que o ambiente entra em falha catastrófica.

Para um profissional de IBM Z, é como acompanhar um ABEND sistêmico onde não há IPL, backup imediato ou equipe de plantão. Cada decisão precisa ser tomada com os recursos disponíveis, priorizando continuidade de serviço, resiliência e cooperação.

No fim, a grande lição da obra é clara: a tecnologia pode manter sistemas funcionando, mas são as pessoas, sua capacidade de adaptação e liderança, que determinam se uma organização — ou uma civilização — sobreviverá ao desastre.

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

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

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

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