 |
| Bellacosa Mainframe e o nao entre em panico como os britanicos e suas series viam o futuro |
☕ Um Café no Bellacosa Mainframe
NÃO ENTRE EM PÂNICO: Doctor Who, Doomwatch, COBOL e o Guia do Programador Mainframe para Sobreviver ao Futuro
Ou: como a ficção científica britânica dos anos 1970 descobriu AI Governance, resiliência, pandemias, vigilância e incidentes cinquenta anos antes de inventarmos os nomes bonitos
Por Vagner Bellacosa
Existe uma regra fundamental para sobreviver no universo.
Douglas Adams resumiria isso em letras grandes e amigáveis:
NÃO ENTRE EM PÂNICO.
No mundo mainframe, entretanto, convém acrescentar algumas observações:
NÃO ENTRE EM PÂNICO.
Não cancele o job sem saber o que ele está fazendo.
Não dê PURGE apenas porque alguém importante está gritando ao telefone.
Não altere produção diretamente porque “é só uma coisinha”.
E, pelo amor de todos os compiladores COBOL existentes na galáxia, descubra primeiro por que o sistema funciona antes de decidir modernizá-lo.
Pegue sua toalha.
Pegue seu café.
Abra o SDSF.
Nossa nave está prestes a sair da órbita.
Destino:
Reino Unido, década de 1970.
Porque, escondidas entre cenários de papelão, monstros de borracha, computadores cheios de luzes piscantes e naves construídas em miniatura, algumas séries britânicas estavam fazendo perguntas que continuam assustadoramente atuais.
A matéria que serviu de ponto de partida para esta viagem considera os anos 1970 uma espécie de “era de ouro” da ficção científica televisiva britânica. A principal razão não era simplesmente a quantidade de alienígenas apresentados na televisão, mas a profundidade dos temas: problemas políticos, sociais, ambientais e tecnológicos começaram a ocupar o centro das histórias.
Eis a primeira coisa que um jovem programador COBOL precisa entender:
ficção científica de verdade raramente fala sobre o futuro.
Ela fala sobre o presente usando o futuro como máscara.
1. O planeta Reino Unido estava com problemas
Antes de encontrarmos Daleks, Cybermen, vírus mortais e governos totalitários, precisamos verificar o log do sistema operacional chamado Reino Unido.
Nos anos 1970, a situação estava longe de ser tranquila.
O país enfrentava problemas econômicos, greves, restrições de investimento e crise energética. Entre 1973 e 1974, a situação chegou ao ponto de haver restrições na operação das emissoras BBC e ITV durante a noite.
Agora imagine um roteirista sentado diante da televisão.
Ele vê:
greves;
desemprego;
problemas energéticos;
desconfiança política;
ameaças da Guerra Fria;
poluição;
crescimento tecnológico;
medo nuclear.
E pergunta:
“E se isso piorar?”
Pronto.
Temos ficção científica.
Uma das grandes virtudes dos britânicos foi transformar problemas concretos em experimentos narrativos.
As diferenças entre classes sociais, o totalitarismo e as preocupações ambientais tornaram-se temas recorrentes dessas produções.
O roteiro deixou de ser apenas:
ALIENÍGENA CHEGA
↓
HERÓI DESCOBRE
↓
HERÓI LUTA
↓
ALIENÍGENA EXPLODE
↓
FIM
e começou a ser algo parecido com:
SOCIEDADE CRIA TECNOLOGIA
↓
TECNOLOGIA CRIA BENEFÍCIOS
↓
ALGUÉM IGNORA OS RISCOS
↓
INCENTIVOS POLÍTICOS INTERFEREM
↓
SISTEMA SAI DO CONTROLE
↓
PESSOAS DESCOBREM QUE DEPENDIAM DELE
↓
PROBLEMA
Se você trabalha com tecnologia há alguns anos, isso provavelmente lhe parece menos ficção científica do que deveria.
2. Antes de Doctor Who havia Quatermass
Voltemos um pouco no tempo.
Em 1953 a BBC exibiu The Quatermass Experiment.
A história mostrava astronautas contaminados por uma forma de vida alienígena após uma missão espacial. O material que analisamos identifica a produção como uma das experiências da BBC que misturavam drama, terror, fantasia e ciência antes do nascimento de Doctor Who.
Observe a arquitetura da história.
O perigo não aparece simplesmente porque “alienígenas são maus”.
O problema surge porque:
HOMEM
↓
EXPLORA
↓
DESCONHECIDO
↓
TRAZ ALGO DE VOLTA
↓
NÃO ENTENDE O QUE TROUXE
Isso é uma estrutura importantíssima da ficção científica moderna.
E também da segurança da informação.
Se substituirmos “organismo extraterrestre” por:
biblioteca desconhecida
pacote npm
imagem Docker
modelo de IA
arquivo recebido
dependência open source
a história continua funcionando.
O monstro muda.
O problema permanece.
3. 1955: surge concorrência no datacenter televisivo
Durante muitos anos, a BBC dominou praticamente sozinha a televisão britânica.
Então surgiu a ITV.
De repente, existia competição.
A ITV trouxe programação mais popular e produções estrangeiras. A BBC precisou reagir aumentando sua capacidade de oferecer entretenimento sem abandonar sua tradição educacional e cultural.
Aqui encontramos uma lição de arquitetura empresarial.
Um sistema raramente evolui sozinho.
Ele evolui porque o ambiente muda.
Concorrência muda produto.
Regulação muda produto.
Usuários mudam produto.
Tecnologia muda produto.
Custo muda produto.
Até COBOL muda.
O COBOL que você encontra hoje em um IBM Z moderno não é simplesmente uma peça arqueológica que alguém esqueceu ligada desde 1968.
É resultado de décadas de evolução.
Da mesma forma, a BBC precisava preservar aquilo que funcionava e adaptar aquilo que já não respondia ao ambiente.
Guarde essa ideia.
Ela voltará quando falarmos de modernização mainframe.
4. 1963: chega Doctor Who
Então entra Sydney Newman.
A missão era quase impossível:
manter o conteúdo inteligente da BBC e, ao mesmo tempo, torná-lo popular.
A resposta foi uma série chamada:
Doctor Who.
A concepção original tinha forte propósito educacional. História, ciência, tecnologia, espaço e viagens temporais seriam apresentados aos jovens através de aventuras.
Parece simples hoje.
Mas pense na elegância da arquitetura.
Você quer ensinar história?
Leve os personagens para o passado.
Quer falar sobre tecnologia?
Viaje para o futuro.
Quer discutir ética?
Crie uma civilização alienígena.
Quer discutir racismo?
Crie duas espécies que se odeiam.
Quer falar sobre autoritarismo?
Invente um governo galáctico.
Quer discutir guerra?
Crie Daleks.
Doctor Who transformou ficção científica em uma espécie de laboratório moral portátil.
A TARDIS podia levar o espectador para qualquer problema.
5. O sistema quase foi cancelado
A primeira aventura de Doctor Who não provocou o sucesso esperado.
Então apareceram os Daleks.
A audiência aumentou dramaticamente, chegando a aproximadamente nove milhões de espectadores segundo o material analisado.
Ironicamente:
os Daleks salvaram Doctor Who.
Isso também contém uma pequena aula de engenharia de produtos.
Você pode criar uma solução tecnicamente brilhante.
Mas se ninguém quiser utilizá-la, temos um problema.
O criador pensa:
“Mas minha arquitetura está perfeita!”
O usuário responde:
“Tá. Mas onde está o botão que resolve meu problema?”
A BBC descobriu algo parecido.
A ideia educacional era boa.
Mas os Daleks forneceram:
ameaça;
identidade;
conflito;
memória;
símbolo.
Em linguagem de produto:
engajamento.
6. 1970: Doomwatch entra na sala
Agora chegamos a uma das partes mais interessantes desta viagem.
Em 1970 estreia Doomwatch.
A série foi criada por Kit Pedler e Gerry Davis. Pedler era cientista e atuava como consultor das situações apresentadas. Segundo o artigo analisado, a produção teve três temporadas e 38 episódios.
Mas observe a premissa.
Existe um departamento chamado:
Department for the Observation and Measurement of Scientific Work.
Missão:
acompanhar pesquisas científicas e verificar se elas poderiam representar ameaça às pessoas ou ao meio ambiente.
Caro viajante galáctico...
Estamos em 1970.
Agora troque:
Scientific Work
por:
Artificial Intelligence.
Temos imediatamente:
DEPARTMENT FOR THE OBSERVATION
AND MEASUREMENT OF
ARTIFICIAL INTELLIGENCE
Parabéns.
Você acabou de reinventar:
AI Governance.
7. A pergunta de Doomwatch
A pergunta fundamental de Doomwatch é maravilhosa:
se podemos fazer alguma coisa, devemos fazê-la?
Na tecnologia normalmente somos treinados para responder:
“Funciona?”
Mas sistemas críticos exigem outras perguntas:
“Devemos fazer?”
“Quem será afetado?”
“Qual é o risco?”
“Como detectaremos erro?”
“Quem pode interromper?”
“Existe rollback?”
“Quem autorizou?”
“Existe evidência?”
“Existe auditoria?”
“Qual é o blast radius?”
Esse é exatamente o ponto em que engenharia deixa de ser simplesmente programação.
8. O programador COBOL encontra Doomwatch
Imagine que alguém lhe entregue uma mudança:
IF CLIENTE-VIP
MOVE ZERO TO TAXA
END-IF.
Funciona?
Provavelmente.
Compila?
Talvez.
Resolve a solicitação?
Aparentemente.
Mas o programador experiente pergunta:
Quem definiu CLIENTE-VIP?
Essa taxa pode legalmente ser zerada?
Quem autorizou?
Existe trilha de auditoria?
Isso afeta cálculo tributário?
Existem outros programas utilizando esse campo?
É aqui que surge uma regra fantástica:
código correto pode produzir um sistema errado.
Doomwatch já estava discutindo, metaforicamente, exatamente esse problema.
9. 1975: Survivors e o planeta sem produção
Então Terry Nation criou algo muito mais sombrio.
Survivors.
Uma praga provocada por vírus cultivado em laboratório destrói aproximadamente 99% da população mundial. Os sobreviventes precisam reconstruir comunidades praticamente sem infraestrutura moderna.
A produção existiu entre 1975 e 1977 e acumulou 38 episódios.
Hoje, depois de uma pandemia global real, assistir a essa premissa produz outra sensação.
Mas existe uma camada ainda mais interessante.
Survivors não é apenas sobre vírus.
É sobre:
dependência sistêmica.
10. Civilization.exe parou de responder
Imagine que amanhã desapareçam:
energia;
telecomunicações;
sistema bancário;
logística;
produção industrial;
governo;
hospitais;
internet;
combustíveis;
cadeias de suprimento.
Em poucas horas descobriremos algo curioso.
Nossa civilização é uma gigantesca aplicação distribuída.
Ela possui milhares de serviços.
Alguns críticos.
Alguns aparentemente insignificantes.
E todos possuem dependências.
Por exemplo:
SUPERMERCADO
↓
LOGÍSTICA
↓
COMBUSTÍVEL
↓
PAGAMENTO
↓
BANCO
↓
DATACENTER
↓
ENERGIA
↓
TELECOM
Agora faça o caminho inverso.
Telecom depende de energia.
Energia depende de sistemas informatizados.
Sistemas informatizados dependem de redes.
Redes dependem de telecom.
Bem-vindo ao maravilhoso universo das:
dependências circulares.
11. O batch das 04:37
Um jovem desenvolvedor pode olhar para determinado processamento mainframe e pensar:
“É apenas um job.”
Não.
Pode ser:
liquidação;
folha de pagamento;
posição contábil;
cartões;
compensação;
arrecadação;
seguros;
reservas;
crédito;
tributação.
O job pode terminar às 04:37.
Ninguém vê.
Ninguém aplaude.
Nenhuma animação aparece.
Não existem luzes azuis cinematográficas.
Mas talvez milhões de pessoas acordem de manhã esperando que o resultado daquele processamento exista.
Essa é uma das grandes lições de Survivors.
Infraestrutura só parece invisível enquanto funciona.
12. Resiliência antes de chamarmos de resiliência
Hoje utilizamos termos sofisticados:
Business Continuity.
Disaster Recovery.
Cyber Resilience.
High Availability.
Fault Tolerance.
Redundancy.
RTO.
RPO.
Survivors coloca tudo isso em uma única pergunta:
“O que acontece quando quase tudo deixa de funcionar?”
O exercício parece extremo.
Mas arquitetos fazem versões menores dessa pergunta todos os dias.
Se o Db2 cair?
Se o CICS parar?
Se perdermos um LPAR?
Se perdermos o datacenter?
Se a rede cair?
Se o fornecedor desaparecer?
Se o backup estiver corrompido?
Se o operador errar?
Se o ransomware atingir infraestrutura crítica?
Ficção científica e engenharia compartilham uma ferramenta intelectual maravilhosa:
cenários hipotéticos.
13. 1978: Blake's 7
Chegamos então a Blake's 7.
Também criada por Terry Nation.
A série apresenta um futuro onde uma organização chamada Terran Federation governa diversos mundos através de mecanismos políticos, religiosos, tecnológicos e até genéticos.
Agora mudamos de ameaça.
Em Survivors:
o sistema desapareceu.
Em Blake's 7:
o sistema ficou poderoso demais.
Excelente contraponto.
Um extremo:
SEM CONTROLE
Outro:
CONTROLE TOTAL
A humanidade vive entre os dois.
14. A tecnologia também pode controlar
Na Federação, tecnologia não é apenas ferramenta.
Ela é instrumento de poder.
Essa discussão cresceu enormemente no século XXI.
Quem possui os dados?
Quem controla algoritmos?
Quem define recomendações?
Quem observa usuários?
Quem decide quais informações aparecem?
Quem pode desligar uma conta?
Quem controla sistemas de identidade?
Quem controla a infraestrutura?
Não precisamos imaginar uma Federação Galáctica.
Podemos estudar simplesmente a concentração de infraestrutura digital.
15. Blake não é Luke Skywalker
Outro aspecto interessante é que Blake's 7 não transforma automaticamente a resistência em grupo moralmente perfeito.
Os próprios personagens questionam Blake.
Nem todos compartilham sua ideologia.
A série chega a apresentar acusações de fanatismo contra ele.
Isso é muito importante.
Porque sistemas complexos raramente apresentam:
MOCINHO = CERTO
VILÃO = ERRADO
Normalmente encontramos:
pressões;
interesses;
incentivos;
erros;
interpretações;
riscos;
informação incompleta.
Quem trabalha em incidentes conhece isso.
Depois que tudo termina, é fácil dizer:
“Era óbvio.”
Antes do incidente?
Nem sempre.
16. Zen, o computador
A nave Liberator possui um computador chamado Zen.
Por décadas a ficção científica imaginou computadores que:
conversam;
aconselham;
controlam;
decidem;
questionam;
enganam;
ajudam.
Durante muito tempo isso parecia apenas recurso narrativo.
Agora chegamos à era dos modelos generativos e agentes.
A fronteira começou a mudar.
Antes:
HOMEM
↓
COMANDO
↓
COMPUTADOR
↓
RESULTADO
Hoje podemos ter:
HOMEM
↓
OBJETIVO
↓
AGENTE
↓
PLANO
↓
FERRAMENTA
↓
AÇÃO
↓
AVALIAÇÃO
↓
NOVA AÇÃO
A diferença é gigantesca.
Quanto maior a autonomia, maior a importância de controle, observabilidade e validação.
Doomwatch volta à sala.
17. UFO: a burocracia encontra os alienígenas
Outra produção importante foi UFO, de Gerry e Sylvia Anderson, também mencionada entre as séries relevantes daquele período.
Existe algo particularmente divertido em UFO.
A defesa da Terra não depende simplesmente de um herói com uma arma.
Existe uma organização.
Existem procedimentos.
Bases.
Monitoramento.
Satélites.
Computadores.
Comando.
Comunicação.
Ou seja:
até para combater alienígenas os britânicos imaginaram uma estrutura operacional.
Quase conseguimos ouvir alguém dizendo:
“Antes de interceptar a nave alienígena, abra o ticket.”
Isso talvez seja a coisa mais britânica possível.
18. Espaço: 1999 e o problema chamado consequência
Espaço: 1999 apresenta uma ideia completamente absurda do ponto de vista da física:
uma explosão gigantesca lança a Lua para fora da órbita terrestre.
Tudo bem.
Não entre em pânico.
Ficção não precisa necessariamente funcionar como artigo científico.
O interessante é a causa.
Resíduos nucleares.
Outra vez encontramos:
tecnologia + irresponsabilidade + consequência.
Os anos 1970 estavam profundamente preocupados com energia, poluição e tecnologia nuclear.
A Lua simplesmente serviu como cenário.
19. O detalhe mais importante das Eagles
As naves Eagle tornaram-se talvez um dos designs mais memoráveis da série.
Mas existe uma curiosidade de engenharia escondida nelas.
Elas parecem máquinas.
Não parecem “magia espacial”.
É possível observar:
módulos;
estrutura;
propulsores;
cockpit;
componentes.
Isso produz plausibilidade visual.
A mesma regra vale para software.
Quando mostramos arquitetura como caixas mágicas:
APP → CLOUD → IA → RESULTADO
não explicamos nada.
Um bom arquiteto precisa desmontar a Eagle.
APLICAÇÃO
↓
API
↓
AUTENTICAÇÃO
↓
SERVIÇO
↓
BANCO
↓
MENSAGERIA
↓
MAINFRAME
Agora podemos discutir risco.
20. O impacto no Brasil
A influência dessas produções no Brasil aconteceu de maneira diferente da experiência britânica.
Nem todas as séries tiveram aqui a mesma visibilidade.
Isso significa que memória cultural não depende apenas da qualidade de uma obra.
Depende também de:
distribuição;
emissora;
horário;
dublagem;
reprises;
licenciamento;
alcance.
No Reino Unido, Doctor Who tornou-se parte profunda da cultura popular.
No Brasil, para muitas gerações, outras produções britânicas como UFO, produções de Gerry Anderson e Espaço: 1999 foram referências muito mais imediatamente reconhecíveis.
Essa diferença ensina algo curioso.
Tecnologia também possui distribuição cultural.
Uma invenção pode existir.
Mas se não chega às pessoas, seu impacto é limitado.
Software é igual.
21. O código que ninguém conhece não existe
Imagine criar uma biblioteca fantástica.
Documentação inexistente.
Ninguém sabe utilizá-la.
Ela praticamente não existe.
Agora imagine um programa COBOL de 1989.
Executa todos os dias.
Possui milhares de regras.
Resolve dezenas de exceções.
Pouquíssimas pessoas entendem completamente aquilo.
O código existe.
O conhecimento talvez esteja desaparecendo.
É o problema inverso.
Em um caso:
produto sem distribuição.
No outro:
sistema sem conhecimento distribuído.
Ambos são risco.
22. O que a ficção britânica fez de diferente
Existe uma generalização interessante.
Muita ficção científica americana tradicional perguntou:
“O que encontraremos no futuro?”
A tradição britânica frequentemente perguntou:
“O que o futuro fará conosco?”
Não é uma regra absoluta.
Mas ajuda a compreender essas produções.
Doctor Who pergunta:
como usamos conhecimento?
Doomwatch pergunta:
quem controla ciência?
Survivors pergunta:
o que acontece quando infraestrutura desaparece?
Blake's 7 pergunta:
o que acontece quando controle tecnológico se torna excessivo?
Space: 1999 pergunta:
quais consequências deixamos para o futuro?
Essas perguntas continuam abertas.
23. De 1970 para 2026
Podemos montar uma pequena tradução temporal.
DOOMWATCH
1970: risco científico
2026: AI Governance
SURVIVORS
1975: pandemia e colapso
2026: resiliência sistêmica
BLAKE'S 7
1978: Estado tecnológico
2026: vigilância algorítmica
UFO
1970: infraestrutura de defesa
2026: sistemas distribuídos
SPACE: 1999
1975: lixo nuclear
2026: sustentabilidade tecnológica
DOCTOR WHO
1963+
ciência + ética + história
2026:
inovação responsável
Isso não significa que os roteiristas “previram” exatamente nosso mundo.
Significa algo mais interessante.
Eles identificaram padrões.
24. E padrões sobrevivem
Tecnologias mudam.
Padrões humanos nem tanto.
Temos:
pressa;
ambição;
medo;
competição;
custo;
ego;
autoridade;
conformismo;
pressão por prazo;
excesso de confiança.
Agora misture isso com tecnologia.
Resultado:
incidentes.
É exatamente aqui que nossas discussões sobre Plan Continuation Bias entram na TARDIS.
Um plano começa fazendo sentido.
O ambiente muda.
Surgem sinais de problema.
Mas pessoas continuam seguindo o plano porque já investiram nele.
“Já estamos quase terminando.”
“Não vamos voltar agora.”
“Diretoria já anunciou.”
“O cutover é hoje.”
“Todo mundo está mobilizado.”
Enquanto isso:
alerta.
alerta.
alerta.
alerta.
E ninguém reage.
Bem-vindo à Alarm Fatigue.
25. O episódio perdido de Doomwatch
Imagine.
Doomwatch — episódio 39.
Título:
The Legacy System.
Um grande banco decide substituir um sistema COBOL criado décadas antes.
Uma consultoria garante:
“Dezoito meses.”
Um jovem executivo pergunta:
“Quantas linhas?”
Alguém responde:
“Oito milhões.”
Executivo:
“Então é fácil. Colocamos cinquenta programadores.”
No fundo da sala existe um senhor com cinquenta anos de mainframe.
Ele levanta a mão.
Silêncio.
Pergunta:
“Vocês sabem o que ele faz?”
Executivo:
“Claro. Processa contas.”
O veterano:
“Não. Isso é o que vocês acham que ele faz.”
Música dramática.
Corta para propaganda.
26. A arqueologia do legado
Aqui está outra lição fundamental para quem começa em COBOL.
Sistema legado não significa necessariamente:
sistema ruim.
Significa principalmente:
sistema herdado.
Ele acumulou decisões.
Regras.
Correções.
Mudanças legais.
Tratamentos especiais.
Exceções.
Integrações.
Um programa pode conter algo assim:
IF DATA-MOVIMENTO < WS-DATA-1997
PERFORM CALCULO-ANTIGO
ELSE
PERFORM CALCULO-NOVO
END-IF.
O jovem pergunta:
“Por que 1997?”
Resposta:
“Ninguém sabe.”
Cuidado.
Isso não significa automaticamente que podemos apagar.
Talvez exista legislação.
Conversão histórica.
Contrato antigo.
Migração.
Compatibilidade.
A primeira ferramenta do mantenedor não é DELETE.
É:
curiosidade.
27. Guia galáctico para mexer em COBOL antigo
Antes de modificar código crítico:
Passo 1 — Descubra quem chama
JCL?
CICS?
IMS?
Outro programa?
Scheduler?
MQ?
API?
Passo 2 — Descubra o que entra
Arquivo?
VSAM?
Db2?
COMMAREA?
Fila?
Passo 3 — Descubra o que sai
Outro arquivo?
Tabela?
Relatório?
Transação?
Passo 4 — Procure dependências
COPYBOOKS.
CALLs.
PROCs.
SORTs.
Utilitários.
Passo 5 — Entenda a regra de negócio
Não pergunte apenas:
“O que esse IF faz?”
Pergunte:
“Por que o negócio precisa desse IF?”
Passo 6 — Teste o cenário feliz
Depois teste justamente o contrário.
Passo 7 — Crie rollback
Porque:
MOVE PROD TO TEST
é ficção científica.
MOVE TEST TO PROD
sem controle é terror.
28. O verdadeiro vilão quase nunca é o computador
Essa talvez seja a grande síntese.
Nas boas histórias de ficção científica, a máquina raramente é o problema inteiro.
Normalmente existe:
TECNOLOGIA
+
DECISÃO HUMANA
+
CONTEXTO
+
INCENTIVO
+
FALHA DE CONTROLE
= desastre.
Isso vale para:
IA;
mainframe;
aviação;
energia;
medicina;
bancos;
redes sociais;
automação.
29. Curiosidade: Daleks e Cybermen são diferentes
Para um iniciante em Doctor Who, existe uma diferença filosófica divertida.
Daleks representam uma espécie de pureza ideológica extrema.
Cybermen representam transformação tecnológica que elimina progressivamente características humanas.
Ou seja:
um teme o “outro”.
O outro elimina o “humano”.
Em tecnologia moderna isso permite uma metáfora interessante.
Um sistema pode falhar porque rejeita diversidade.
Ou pode falhar porque automatiza tudo sem preservar julgamento humano.
Qualquer semelhança com debates contemporâneos sobre IA é bastante conveniente.
30. Easter egg COBOL galáctico
Se Arthur Dent fosse programador COBOL, provavelmente seu código começaria assim:
IDENTIFICATION DIVISION.
PROGRAM-ID. DONT-PANIC.
PROCEDURE DIVISION.
0000-MAIN.
PERFORM UNTIL UNIVERSE-END
DISPLAY "DON'T PANIC"
PERFORM CHECK-BATCH
PERFORM DRINK-COFFEE
END-PERFORM.
STOP RUN.
O problema está em:
UNIVERSE-END
porque ninguém documentou o formato da variável.
Há rumores de que seja PIC 9(8).
Outros afirmam que é PIC X(42).
Naturalmente, 42.
31. Segunda curiosidade: a resposta não serve sem a pergunta
Em O Guia do Mochileiro das Galáxias, 42 é apresentado como resposta à Grande Questão da Vida, do Universo e de Tudo.
Mas existe um detalhe genial:
ninguém sabe exatamente qual era a pergunta.
Isso é uma metáfora perfeita para tecnologia.
Quantas vezes alguém aparece com uma solução?
“Cloud!”
“Blockchain!”
“Microserviços!”
“IA!”
“Kubernetes!”
“Agentes!”
Você pergunta:
“Qual problema estamos resolvendo?”
Silêncio.
Temos a resposta.
Esquecemos a pergunta.
Arquitetura boa começa pelo problema.
32. O mainframe é a TARDIS da computação empresarial
Exteriormente, alguém olha e diz:
“Isso ainda existe?”
Por dentro encontramos:
processamento massivo;
virtualização;
criptografia;
bancos de dados;
mensageria;
Linux;
APIs;
Java;
Python;
COBOL;
containers;
automação;
IA;
DevOps.
Talvez não seja literalmente maior por dentro.
Mas é suficientemente grande para assustar qualquer desenvolvedor que achava que “mainframe = COBOL + tela verde”.
33. O que realmente aprendemos
Depois de atravessar Quatermass, Doctor Who, Doomwatch, Survivors, Blake's 7, UFO e Espaço: 1999, podemos finalmente voltar para nosso café.
Essas séries ensinaram algo essencial.
Tecnologia não existe isolada.
Ela existe dentro de:
sociedade;
economia;
política;
organizações;
pessoas;
valores.
Portanto, nenhuma discussão tecnológica séria deveria terminar em:
“Funcionou.”
Precisamos perguntar também:
Funcionou para quem?
Com qual risco?
Sob qual controle?
Quem observa?
Quem audita?
Quem interrompe?
Quem responde?
Quem entende?
34. A pergunta que o jovem programador deve aprender
Quando receber sua primeira alteração em um sistema COBOL crítico, talvez você queira mostrar serviço.
Excelente.
Mas existe uma pergunta extremamente poderosa:
“O que pode dar errado?”
Depois:
“Como saberemos que deu errado?”
Depois:
“O que faremos se der errado?”
Essas três perguntas transformam um programador em engenheiro.
35. Não entre em pânico
Um ABEND acontece.
Não entre em pânico.
Veja o código.
Uma transação CICS falha.
Não entre em pânico.
Veja o contexto.
Um job fica preso.
Não entre em pânico.
Veja dependências.
Um usuário liga gritando.
Principalmente:
não entre em pânico.
O pânico reduz investigação.
E incidentes exigem investigação.
36. Observe antes de agir
Talvez Doomwatch pudesse ter como lema:
observar antes de intervir.
Isso é fantástico para produção.
Primeiro:
colete evidência.
Depois:
forme hipótese.
Depois:
valide.
Depois:
aja.
Em pseudo-COBOL:
PERFORM OBSERVE
PERFORM UNDERSTAND
PERFORM VALIDATE
PERFORM AUTHORIZE
PERFORM CHANGE
PERFORM VERIFY
Jamais:
PERFORM CHANGE
PERFORM PRAY
Embora esse segundo modelo tenha sido utilizado com surpreendente frequência na história da informática.
37. A grande lição da ficção científica britânica
Não foram as naves.
Não foram os monstros.
Não foram os figurinos.
Não foram os computadores piscantes.
A grande contribuição foi perceber que o problema fundamental do futuro seria:
como viver com as consequências das tecnologias que criamos.
Essa discussão aparece repetidamente nas obras analisadas: a matéria destaca explicitamente que essas produções dos anos 1970 utilizaram ficção científica para discutir questões sociais, políticas, ambientais e de poder.
Isso continua conosco.
IA.
Biotecnologia.
Computação quântica.
Cybersecurity.
Automação.
Redes sociais.
Mainframes.
Cloud.
Agentes autônomos.
A tecnologia continua avançando.
A pergunta continua praticamente a mesma.
38. Epílogo: o último operador do universo
Imagine o fim do universo.
As estrelas apagaram.
Os planetas desapareceram.
Os Daleks foram embora.
A Federação caiu.
A Lua finalmente encontrou uma órbita decente.
Arthur Dent terminou seu chá.
Restou apenas um datacenter IBM Z perdido no vazio cósmico.
Uma luz verde pisca.
No console aparece:
IEF404I JOB DAILY42 ENDED
Um velho operador olha para o relógio.
04:37.
Sorri.
O batch terminou.
O universo pode acabar tranquilo.
Porque em algum lugar nos últimos registros da civilização existe uma linha dizendo:
MAXCC=0000
E talvez essa seja a maior definição possível de sucesso operacional.
Não evitar todo problema.
Não possuir tecnologia perfeita.
Não prever exatamente o futuro.
Mas construir sistemas suficientemente compreendidos, observáveis, resilientes e responsáveis para continuar funcionando quando o inesperado finalmente aparecer.
Os britânicos descobriram isso enquanto colocavam monstros de borracha diante das câmeras.
Nós descobrimos novamente em cada war room.
Então, jovem programador COBOL, quando alguém aparecer diante de sua mesa dizendo:
“É só uma alteraçãozinha...”
segure sua toalha.
Beba seu café.
Abra o código.
Pergunte quem autorizou.
Descubra as dependências.
Prepare o rollback.
E lembre-se das palavras mais importantes já impressas em qualquer guia realmente útil para sobreviver à tecnologia:
NÃO ENTRE EM PÂNICO.
Principalmente em produção.
