 |
| Bellacosa Mainframe e a auditoria em computadores |
☕ Um Café no Bellacosa Mainframe
🧙♂️ LLOYD DE SALOUM E A DUNGEON DA MICROINFORMÁTICA — QUANDO O PC VIROU BUSINESS COMPUTER
COBOL, mainframe, PCs, Winchester, Lotus 1-2-3, antivírus, backup, auditoria, Shadow IT, ITAM, CMDB, Cloud e IA — e o dia em que Lloyd descobriu que o aplicativo secreto do Financeiro era mais perigoso que um demônio ancestral.
🎬 PRÓLOGO — LLOYD ENCONTROU UM PC DEBAIXO DA MESA
— Lloyd-sama, temos um problema.
Lloyd de Saloum levantou os olhos.
Aquilo normalmente significava uma excelente oportunidade para aprender alguma magia nova.
— Um demônio?
— Não.
— Uma maldição?
— Também não.
— Um artefato mágico proibido?
— Pior. Encontramos um computador no Financeiro que ninguém da Informática sabia que existia.
Os olhos de Lloyd brilharam.
— Interessante!
O pobre auditor percebeu imediatamente que havia cometido um erro.
Poucos minutos depois, Lloyd estava ajoelhado diante da máquina.
Na tela:
C:\>
No disco rígido havia planilhas, documentos, programas em dBASE, arquivos de clientes, backups de backups, executáveis de procedência desconhecida e um diretório chamado:
C:\NOVO\FINAL\BACKUP\VELHO
— Fascinante!
— Lloyd-sama, isso não deveria estar aqui.
— Por quê?
Essa pergunta aparentemente inocente nos leva a uma das transformações mais importantes da história da informática corporativa.
Durante décadas, empresas construíram regras rigorosas para controlar computadores centrais, aplicações COBOL, arquivos, bancos de dados, usuários, backups e mudanças.
Então chegaram os microcomputadores.
E milhares de usuários descobriram que podiam fazer muita coisa sem pedir autorização ao velho CPD.
Nascia uma revolução.
E, junto com ela, uma enorme dungeon chamada:
AUDITORIA DE MICROINFORMÁTICA.
🏰 CAPÍTULO 1 — QUANDO O COMPUTADOR MORAVA NO CASTELO
Para entender a auditoria de microinformática, nosso jovem programador COBOL precisa voltar algumas décadas.
Em uma empresa tradicional, o processamento de dados era altamente centralizado.
Podíamos ter algo parecido com:
┌─────────────────┐
│ MAINFRAME │
│ │
│ COBOL │
│ CICS │
│ IMS │
│ DB2 │
│ VSAM │
└────────┬────────┘
│
┌───────────┴───────────┐
│ │
TERMINAL TERMINAL
│ │
Usuário Usuário
O terminal normalmente não era um computador independente como conhecemos hoje.
Ele era uma janela para o sistema central.
O processamento estava no mainframe.
Os programas estavam sob controle da área de tecnologia.
Os dados estavam em datasets, bancos ou arquivos administrados.
Havia procedimentos para produção.
Havia operadores.
Havia controle de acesso.
Havia backup.
Havia processos de mudança.
Mesmo que tudo isso não fosse perfeito, existia uma importante característica:
centralização.
Se Lloyd perguntasse:
— Onde está a folha de pagamento?
Provavelmente alguém poderia responder:
— Na aplicação XPTO, executada no mainframe, usando estes programas COBOL, estes arquivos e este banco de dados.
Isso é governança.
Então alguém colocou um computador sobre uma mesa.
🖥️ CAPÍTULO 2 — O PC ESCAPOU DO CPD
O Personal Computer mudou completamente a relação entre usuário e tecnologia.
Agora um departamento podia ter poder computacional próprio.
Financeiro podia criar planilhas.
Engenharia podia comprar aplicativos.
Recursos Humanos podia montar uma pequena base de dados.
Vendas podia desenvolver um sistema departamental.
O computador deixou de ser somente uma janela para o grande computador central.
Ele próprio processava informações.
Imagine:
MAINFRAME
│
Sistemas Corporativos
│
─────────────┼─────────────
│
LAN
│
┌────────────┼────────────┐
│ │ │
Financeiro Vendas Engenharia
│ │ │
PC PC PC
│ │ │
Lotus dBASE Aplicativo
Parece maravilhoso.
E realmente foi uma revolução de produtividade.
Mas existe uma pergunta:
quem controla tudo isso?
O programador COBOL acostumado ao mainframe talvez estranhasse.
No ambiente centralizado, para colocar uma aplicação importante em produção, normalmente existiam processos.
No PC departamental alguém poderia simplesmente criar:
C:\CONTAS\FATURA.DBF
E, seis meses depois, aquele arquivo estar participando do fechamento financeiro da empresa.
Sem que ninguém tivesse percebido quando uma experiência virou aplicação crítica.
Essa transformação é fundamental para entender todo o nosso tema.
O PC estava deixando de ser apenas Personal Computer.
Estava virando:
Business Computer.
BC.
Computador de negócios.
🧙 CAPÍTULO 3 — LLOYD DESCOBRE QUE A MAGIA FUNCIONA SEM AUTORIZAÇÃO
Lloyd provavelmente adoraria microcomputadores.
Porque eles representavam liberdade.
Você podia experimentar.
Instalar.
Programar.
Criar.
Testar.
Automatizar.
O problema empresarial aparece quando confundimos:
liberdade para experimentar
com:
liberdade para criar processos corporativos sem governança.
Imagine João, funcionário do Financeiro.
Todo mês ele recebe um arquivo e leva oito horas para produzir determinado relatório.
João aprende dBASE.
Cria uma pequena aplicação.
Agora leva vinte minutos.
Fantástico!
Depois outras pessoas começam a usar.
Dois anos depois:
Programa do João
↓
Relatório financeiro
↓
Fechamento mensal
↓
Diretoria
↓
Decisão empresarial
Parabéns.
João acabou de criar um sistema crítico.
Só existe um pequeno problema.
Ninguém sabe disso.
👻 CAPÍTULO 4 — O ANCESTRAL DO SHADOW IT
Hoje usamos a expressão Shadow IT para tecnologia utilizada fora da governança ou visibilidade formal da organização.
Mas Shadow IT não nasceu com Cloud.
Muito antes de alguém criar uma máquina virtual escondida na AWS, havia aplicações escondidas em PCs.
Podia ser:
Lotus 1-2-3
Excel
Access
dBASE
FoxPro
Clipper
Macros
scripts
executáveis locais
O usuário não estava necessariamente tentando sabotar a empresa.
Na maioria dos casos queria resolver um problema.
Essa distinção é importante.
Shadow IT frequentemente nasce de uma combinação de:
necessidade urgente
+
tecnologia acessível
+
processo corporativo lento
=
solução paralela
O auditor inteligente não deveria simplesmente perguntar:
— Quem foi o irresponsável que fez isso?
Deveria perguntar:
— Por que a organização precisou disso?
Porque uma aplicação clandestina também pode ser sintoma de outro problema.
Talvez o departamento de TI demore oito meses para atender uma necessidade que o negócio precisa resolver em oito dias.
💰 CAPÍTULO 5 — AUDITORIA NÃO É CAÇA ÀS BRUXAS
Existe uma visão pobre de auditoria:
encontrar alguém fazendo algo errado.
Uma boa auditoria é muito mais interessante.
Ela procura compreender:
PROCESSO
↓
RISCO
↓
CONTROLE
↓
EVIDÊNCIA
↓
EXCEÇÃO
↓
IMPACTO
↓
AÇÃO
Suponha que encontramos dez computadores com determinado software instalado.
O auditor não deveria imediatamente gritar:
— IRREGULARIDADE!
Primeiro precisamos entender.
As dez licenças existem?
São necessárias?
São utilizadas?
Existem vinte licenças compradas e apenas dez usadas?
Outro departamento pretende comprar cinco?
Perceba a mudança.
A auditoria pode descobrir economia.
Departamento A:
20 licenças compradas
10 utilizadas
10 ociosas
Departamento B:
10 utilizadas
precisa de mais 5
Sem inventário, B compra cinco novas licenças.
Com governança, talvez seja possível reaproveitar licenças disponíveis, dependendo das condições contratuais do produto.
Auditoria também é otimização de recursos.
📦 CAPÍTULO 6 — O SOFTWARE QUE NINGUÉM USAVA
Outra preocupação clássica era encontrar software instalado e não utilizado.
Isso parece pequeno até multiplicarmos pelo tamanho da empresa.
Imagine 3.000 computadores.
Agora imagine software pago instalado em centenas deles sem necessidade.
Dinheiro parado.
O mesmo vale para hardware.
Uma área pode possuir computadores subutilizados enquanto outra solicita equipamentos novos.
Daí a necessidade de conhecer:
localização;
departamento;
usuário responsável;
fabricante;
modelo;
configuração;
número de série;
software instalado;
situação operacional;
manutenção;
movimentações.
Hoje chamamos grande parte desse universo de IT Asset Management — ITAM.
Para software existe Software Asset Management — SAM.
O velho inventário da microinformática evoluiu.
Mas a pergunta continua:
O que possuímos, onde está, quem usa, quanto custa e ainda precisamos disso?
🗃️ CAPÍTULO 7 — O CADASTRO DIZ 327, MAS LLOYD CONTOU 319
Aqui entramos no coração da auditoria.
Imagine o cadastro:
MICROCOMPUTADORES: 327
Lloyd percorre a empresa e encontra:
MICROCOMPUTADORES: 319
Faltam oito.
Isso não significa automaticamente fraude.
Podem estar:
em manutenção;
transferidos;
emprestados;
armazenados;
descartados;
substituídos;
roubados;
simplesmente cadastrados incorretamente.
Mas existe uma diferença.
E diferenças precisam ser explicadas.
É por isso que o texto original insiste tanto em:
bater cadastro de hardware e software com o existente.
Hoje chamaríamos isso de reconciliação.
O que nossa base acredita existir precisa ser comparado ao que realmente existe.
Esse princípio aparece em CMDBs modernas.
🧠 CAPÍTULO 8 — A EMPRESA TEM CÓDIGO, MAS PERDEU A MEMÓRIA
Agora chegamos a uma das questões mais profundas:
Como preservar a memória da empresa diante do turnover?
Voltemos ao João.
João criou uma aplicação.
Durante quinze anos recebeu solicitações:
— João, cliente XPTO precisa de tratamento diferente.
João altera.
Depois:
— João, quando o produto for 37, calcule assim.
João altera.
Depois:
— João, operações realizadas depois das 17h precisam entrar no próximo ciclo.
João altera.
Quinze anos depois existe isto:
IF CLIENTE = 'XPTO'
...
END-IF
A empresa possui o código.
Mas por que XPTO é diferente?
João sabe.
O programa não.
Então João se aposenta.
💀
Essa situação não é exclusividade da microinformática.
Programador COBOL conhece perfeitamente esse fenômeno.
Podemos possuir o fonte de um programa de 1989 e ainda assim não possuir todo o conhecimento necessário para compreender por que ele foi construído daquela maneira.
Existe diferença entre:
CÓDIGO
e:
CONHECIMENTO
Código registra o que acontece.
Documentação, histórico, requisitos, tickets e conhecimento humano ajudam a explicar por que acontece.
📝 CAPÍTULO 9 — DOCUMENTAÇÃO NÃO É DECORAÇÃO
Por isso “documentação inexistente” aparece como risco.
Imagine encontrar:
CALCULA.EXE
Perguntas:
Quem desenvolveu?
Qual linguagem?
Onde está o fonte?
Qual versão está em produção?
Quais arquivos utiliza?
Quem pode alterar?
Existe procedimento de instalação?
Como recuperar?
Qual é a regra de negócio?
Quem é responsável?
Sem respostas, temos uma espécie de artefato mágico.
Funciona.
Ninguém sabe exatamente como.
Lloyd adoraria.
O auditor teria pesadelos.
💾 CAPÍTULO 10 — WINCHESTER NÃO É ARQUIVO MORTO
Para os Padawans que nasceram na era do SSD: “Winchester” tornou-se uma forma popular de chamar o disco rígido.
E havia um problema.
O usuário descobria espaço em disco e começava a guardar tudo.
Logo apareciam estruturas dignas de arqueologia:
C:\
├── TESTE
├── TESTE2
├── TESTEVELHO
├── BACKUP
├── BACKUP2
├── NOVO
├── NOVO2
├── FINAL
└── FINAL_AGORA_VAI
Parece antigo?
Abra uma pasta corporativa moderna.
Talvez encontre:
Contrato_Final.docx
Contrato_Final2.docx
Contrato_Final_Novo.docx
Contrato_Final_Revisado.docx
Contrato_Final_Revisado_FINAL.docx
Contrato_Final_Revisado_FINAL_v3.docx
Mudamos de storage.
O ser humano permaneceu compatível com versões anteriores.
Essa é a verdadeira retrocompatibilidade.
🧹 CAPÍTULO 11 — FRAGMENTAÇÃO, DEFRAG E ARQUEOLOGIA DOS DISCOS
O texto original também menciona arquivos fragmentados.
Nos discos magnéticos, um arquivo podia acabar armazenado em partes espalhadas pelo disco.
Simplificando:
Arquivo A:
[10][11][12] ........ [58] .... [97]
Um disco mecânico possui partes móveis.
O cabeçote precisa acessar diferentes posições.
Quanto mais espalhados os dados, potencialmente maior o trabalho necessário para determinadas operações.
Daí a popularização de ferramentas de desfragmentação.
Quem viveu DOS e Windows antigos provavelmente lembra de utilitários como DEFRAG, além de ferramentas de diagnóstico e manutenção de disco.
Mas atenção:
não devemos transportar automaticamente essa prática para SSDs modernos.
SSDs funcionam de maneira diferente, não possuem cabeçote mecânico e utilizam mecanismos como wear leveling e TRIM.
Aqui existe uma lição fantástica para auditoria:
o princípio pode sobreviver mesmo quando o controle técnico fica obsoleto.
O princípio era:
manter armazenamento saudável, organizado e adequadamente administrado.
A implementação mudou.
🦠 CAPÍTULO 12 — O DEMÔNIO VIAJAVA DE DISQUETE
Outra preocupação era antivírus.
Durante a era da microinformática, disquetes eram excelentes meios de transporte para dados.
E para vírus.
Um disquete passava por:
PC A
↓
PC B
↓
PC C
↓
casa
↓
PC D
↓
empresa
O malware ganhava transporte gratuito.
Com o tempo vieram vírus de arquivos, boot sector, macrovírus e inúmeras outras famílias.
Hoje a pergunta:
“Existe antivírus?”
é insuficiente.
Em um ambiente moderno poderíamos investigar:
EDR/XDR
patch management
hardening
MFA
least privilege
application control
telemetria
SIEM
resposta a incidentes
gestão de vulnerabilidades
A pergunta fundamental permanece:
Conseguimos prevenir, detectar, investigar e responder a comportamento malicioso no endpoint?
🔐 CAPÍTULO 13 — O PC DESCOBRIU QUE PRECISAVA DE RACF
Aqui temos um choque cultural delicioso para quem conhece mainframe.
O mainframe corporativo já possuía uma longa tradição de controles de acesso.
No mundo IBM Z podemos pensar em mecanismos como RACF e outros componentes de segurança.
Mas muitos PCs antigos foram concebidos originalmente para um contexto bastante diferente.
O usuário ligava a máquina e encontrava:
C:\>
Não existia necessariamente aquele mesmo modelo corporativo robusto de identidade, autorização e auditoria.
Quando o PC começou a processar informações importantes, surgiu uma pergunta inevitável:
Como transportar os conceitos de segurança existentes nos ambientes corporativos para a microinformática?
Não significava instalar RACF em DOS.
Significava transportar princípios.
MAINFRAME ENDPOINT
Identidade → Conta do usuário
Autorização → Permissões
Dataset → Arquivo/pasta
Auditoria → Logs
Backup → Backup endpoint
Change control → Gestão de software
Inventário → Asset Management
A tecnologia muda.
O objetivo do controle permanece.
🌐 CAPÍTULO 14 — MICRO E MAINFRAME SE ENCONTRAM
Outro item importantíssimo era a ligação micro/mainframe.
Primeiro o PC podia funcionar quase como terminal.
Depois começaram transferências de arquivos.
Depois vieram redes, client/server, aplicações gráficas e integrações cada vez mais sofisticadas.
Hoje podemos ter:
Notebook
↓
Browser
↓
Aplicação Web
↓
API Gateway
↓
API
↓
z/OS Connect
↓
CICS
↓
COBOL
↓
Db2
O usuário talvez nem saiba que existe COBOL.
Ele aperta:
CONFIRMAR PAGAMENTO
e, alguns milissegundos depois, uma transação pode estar chegando a uma aplicação no mainframe.
A velha pergunta:
“Como o micro se conecta ao mainframe?”
evoluiu para:
“Como endpoints, canais digitais, aplicações distribuídas, APIs, cloud e parceiros acessam os serviços corporativos?”
É a mesma árvore genealógica.
💽 CAPÍTULO 15 — BACKUP NÃO É COPIAR PARA BACKUP2
Lloyd encontra uma pasta:
C:\BACKUP
— Excelente! Há backup!
Não necessariamente.
Talvez ela esteja no mesmo disco.
Se o disco morrer:
ORIGINAL → morreu
BACKUP → morreu junto
Um verdadeiro backup exige planejamento.
O documento original já perguntava:
periodicidade;
responsável;
local de guarda;
como recuperar.
A última questão vale ouro:
como recuperar?
Backup que nunca foi testado é uma promessa.
Em ambientes modernos adicionamos conceitos como:
RPO — Recovery Point Objective
Quanto dado podemos tolerar perder?
RTO — Recovery Time Objective
Quanto tempo podemos tolerar ficar sem o serviço?
Além disso:
retenção;
cópias off-site;
criptografia;
imutabilidade;
testes de restauração;
proteção contra ransomware;
estratégia 3-2-1 quando apropriada.
A evolução conceitual é interessante:
BACKUP
↓
RECOVERY
↓
DISASTER RECOVERY
↓
BUSINESS CONTINUITY
↓
CYBER RESILIENCE
Não queremos simplesmente possuir cópias.
Queremos conseguir continuar ou recuperar o negócio.
⚡ CAPÍTULO 16 — CONFIG.SYS E AUTOEXEC.BAT: NÃO MEXA NO GRIMÓRIO
Quem viveu DOS provavelmente sorriu ao encontrar:
CONFIG.SYS
AUTOEXEC.BAT
Esses arquivos participavam da configuração do ambiente.
Alterações podiam carregar drivers, modificar memória, definir variáveis, caminhos e executar comandos durante a inicialização.
Era perfeitamente possível alguém “otimizar” a máquina e quebrar alguma coisa.
Isso nos leva a outro conceito moderno:
Configuration Management.
Configuração também é ativo.
Hoje não estamos preocupados com AUTOEXEC.BAT da mesma maneira.
Estamos preocupados com:
políticas
registry
GPO
MDM
containers
YAML
Terraform
Ansible
Kubernetes manifests
cloud configuration
Novamente:
o arquivo mudou.
O problema continuou.
📚 CAPÍTULO 17 — O CATÁLOGO DE SOFTWARE
O documento propõe manter um catálogo de software.
Excelente ideia.
Imagine três departamentos.
Todos precisam resolver o mesmo problema.
Cada um contrata um fornecedor diferente.
Resultado:
Área A → Sistema X
Área B → Sistema Y
Área C → Sistema Z
Agora temos três contratos, três tecnologias, três equipes, três processos de suporte e três integrações.
Talvez exista justificativa.
Mas talvez ninguém soubesse que uma solução já existia.
Um catálogo corporativo ajuda a responder:
Já temos alguma coisa que faz isso?
Esse conceito evoluiu para catálogos de aplicações, portfolios de aplicações e ferramentas de Application Portfolio Management.
🧪 CAPÍTULO 18 — COMO LLOYD FARIA UMA AUDITORIA
Vamos transformar tudo em um pequeno laboratório.
Etapa 1 — Conheça a história
Pergunte:
Quando começou a microinformática?
Por quê?
Quem decidiu?
Havia estratégia?
Compra ou aluguel?
Existia padronização?
Etapa 2 — Conheça as políticas
Descubra quais normas deveriam ser cumpridas.
Sem critério não existe avaliação consistente.
Etapa 3 — Obtenha o inventário
Precisamos saber o que a organização acredita possuir.
Etapa 4 — Vá a campo
Agora verificamos o que realmente existe.
Etapa 5 — Compare
REGISTRO
versus
REALIDADE
Etapa 6 — Teste controles
Não pergunte somente:
— Existe backup?
Peça evidência.
Não pergunte somente:
— Existe antivírus?
Verifique.
Não pergunte somente:
— Existe documentação?
Leia.
Etapa 7 — Investigue diferenças
Toda divergência precisa de contexto.
Etapa 8 — Avalie risco
Uma diferença cadastral em um PC isolado não possui necessariamente o mesmo impacto que uma aplicação não documentada processando milhões em operações financeiras.
Etapa 9 — Recomende ações
A recomendação deve atacar causa e risco, não apenas o sintoma.
🕵️ CAPÍTULO 19 — O AUDITOR QUE PROCURA CAUSA, NÃO CULPADO
Imagine encontrar um PC sem proteção adequada.
Auditoria superficial:
“Usuário em desacordo com a norma.”
Auditoria investigativa:
Por que isso aconteceu?
Descobrimos que o agente deveria ser instalado automaticamente.
Por que não foi?
A máquina estava fora do inventário.
Por quê?
Foi transferida entre departamentos sem atualização cadastral.
Agora temos uma cadeia:
Transferência inadequada
↓
Inventário incorreto
↓
Gestão não identifica endpoint
↓
Controle não é aplicado
↓
Endpoint fica desprotegido
O computador sem proteção era apenas o último sintoma.
A verdadeira descoberta está no processo quebrado.
Isso é muito mais valioso.
☁️ CAPÍTULO 20 — O PC VIROU CLOUD
Agora chegamos à ironia histórica.
Décadas atrás:
“O departamento comprou um PC sem informar o CPD.”
Depois:
“Instalaram um software sem informar TI.”
Depois:
“Colocaram um servidor Linux embaixo da mesa.”
Depois:
“Criaram uma VM.”
Depois:
“Contrataram SaaS no cartão corporativo.”
Depois:
“Criaram recursos na Cloud.”
Agora:
“Colaram dados corporativos numa IA generativa.”
Percebeu?
O objeto mudou.
O padrão permanece:
TECNOLOGIA FICA MAIS ACESSÍVEL
↓
USUÁRIO GANHA AUTONOMIA
↓
INOVAÇÃO ACELERA
↓
GOVERNANÇA PERDE VISIBILIDADE
↓
RISCO APARECE
↓
NOVOS CONTROLES SÃO CRIADOS
É praticamente um ciclo histórico da tecnologia empresarial.
🤖 CAPÍTULO 21 — SHADOW AI: O NOVO LOTUS 1-2-3 CLANDESTINO
E chegamos a 2026.
Um funcionário descobre uma ferramenta de IA.
Começa usando para corrigir textos.
Depois resume documentos.
Depois analisa contratos.
Depois envia código.
Depois envia dados de clientes.
Depois constrói um agente.
Em algum momento a experiência pessoal pode virar processo empresarial.
A auditoria moderna deveria perguntar:
Qual ferramenta?
Quem autorizou?
Qual contrato?
Qual modelo?
Quais dados entram?
Onde são processados?
Existe retenção?
Existe logging?
Existe DLP?
Quem revisa as respostas?
Há integração com sistemas?
Quais permissões o agente possui?
Existe supervisão humana?
Como desligamos isso?
Compare com a auditoria antiga:
Qual software?
Quem comprou?
Onde está instalado?
Quem utiliza?
Quais arquivos acessa?
Existe documentação?
Existe backup?
Quem é responsável?
Lloyd provavelmente sorriria.
— É o mesmo feitiço!
Exatamente.
🧠 CAPÍTULO 22 — DO PERSONAL COMPUTER AO PERSONAL AGENT
Existe ainda uma evolução curiosa.
O PC democratizou processamento.
A Web democratizou publicação.
Cloud democratizou infraestrutura.
SaaS democratizou software corporativo.
Low-code democratizou desenvolvimento.
IA generativa democratizou parte da produção intelectual e automação.
Agentes começam a democratizar execução autônoma de tarefas.
Portanto a pergunta histórica da auditoria fica ainda mais importante:
Quanto de liberdade podemos oferecer sem perder governança, segurança e responsabilidade?
Não existe resposta simples.
Bloquear tudo destrói produtividade.
Liberar tudo cria riscos.
A solução normalmente está entre os extremos:
AUTONOMIA
+
GUARDRAILS
+
OBSERVABILIDADE
+
RESPONSABILIDADE
🧙♂️ CAPÍTULO 23 — O QUE UM PROGRAMADOR COBOL TEM A VER COM ISSO?
Tudo.
Você talvez pense:
“Bellacosa, eu só quero programar COBOL.”
Então guarde esta lição.
Um programa não existe isoladamente.
Seu COBOL participa de um ecossistema:
Usuário
↓
Canal
↓
Aplicação
↓
API / MQ / CICS
↓
COBOL
↓
Db2 / IMS / VSAM
↓
Batch
↓
Outros sistemas
Cada seta possui:
identidade;
autorização;
configuração;
logs;
documentação;
dependências;
recuperação;
responsáveis.
Um excelente programador não conhece somente sintaxe.
Ele começa a entender o sistema ao redor do programa.
🏺 CAPÍTULO 24 — SEU PROGRAMA COBOL É UM ARTEFATO HISTÓRICO
Imagine abrir um programa:
IF WS-CUSTOMER-CODE = 317
PERFORM SPECIAL-PROCESSING
END-IF.
Não remova imediatamente.
Pergunte:
Por quê?
Talvez exista uma regra contratual de 1997.
Talvez o cliente nem exista mais.
Talvez seja código morto.
Talvez seja absolutamente crítico.
O auditor e o mantenedor de legado compartilham uma virtude:
desconfiança metodológica.
Não significa suspeitar das pessoas.
Significa não confundir aparência com evidência.
O código compila?
Ótimo.
Mas está correto?
Tem teste?
Tem documentação?
Quem depende dele?
Qual impacto de uma alteração?
Essa mentalidade transforma um digitador de COBOL em engenheiro de sistemas.
🕒 CAPÍTULO 25 — O EASTER EGG DAS 03:17
Lloyd encontra uma documentação antiga:
“Não executar antes das 03:17.”
— Por quê?
Silêncio.
Ninguém sabe.
O programador original se aposentou.
O analista que conhecia o processo saiu.
O documento não explica.
Lloyd, naturalmente, executa às 03:16.
A dungeon inteira começa a tremer.
😂
Esse é o easter egg, mas também contém uma lição séria.
Uma organização pode preservar:
O QUE FAZER
e perder:
POR QUE FAZER
Esse segundo conhecimento é frequentemente muito mais difícil de reconstruir.
Por isso bons comentários, documentação, versionamento, tickets, decisões arquiteturais e transferência de conhecimento são tão importantes.
🗺️ CAPÍTULO 26 — A EVOLUÇÃO COMPLETA DA DUNGEON
Podemos finalmente montar nosso mapa:
MAINFRAME CENTRALIZADO
↓
MICROCOMPUTADOR
↓
REDES LOCAIS
↓
CLIENT/SERVER
↓
INTERNET
↓
WEB
↓
VIRTUALIZAÇÃO
↓
CLOUD
↓
SAAS
↓
LOW-CODE
↓
GENERATIVE AI
↓
AI AGENTS
A cada camada, a tecnologia fica mais acessível.
E surge novamente a pergunta:
Quem governa?
☕ EPÍLOGO — LLOYD FINALMENTE ENTENDEU O VERDADEIRO FEITIÇO
Depois de examinar computadores, discos, aplicativos, números de série, backups, documentação e cadastros, Lloyd chegou a uma conclusão.
A auditoria de microinformática nunca foi realmente sobre contar computadores.
Também não era sobre procurar arquivos pessoais no Winchester.
Nem sobre descobrir quem havia instalado três processadores de texto diferentes.
Era sobre uma coisa muito maior:
descobrir se a empresa continuava conhecendo e controlando a tecnologia da qual havia passado a depender.
Nos tempos do mainframe, boa parte desse universo estava centralizada.
O PC distribuiu poder computacional.
A rede conectou esse poder.
A Internet expandiu as fronteiras.
Cloud distribuiu infraestrutura.
SaaS distribuiu aplicações.
Low-code distribuiu desenvolvimento.
IA distribuiu capacidade cognitiva.
Agentes começam a distribuir capacidade de ação.
E toda vez que distribuímos poder tecnológico, precisamos redistribuir também:
RESPONSABILIDADE
CONTROLE
CONHECIMENTO
SEGURANÇA
OBSERVABILIDADE
Caso contrário teremos sistemas funcionando perfeitamente...
...que ninguém sabe que existem.
Lloyd fechou o velho computador.
— Então encontramos o demônio?
O auditor balançou a cabeça.
— Não exatamente.
— Encontramos uma aplicação crítica sem documentação?
— Sim.
— Sem responsável?
— Sim.
— Sem backup testado?
— Sim.
— Fora do inventário?
— Sim.
— E ninguém sabe quem criou?
— Exatamente.
Lloyd sorriu.
— Excelente! Quero ver o código!
O auditor começou a suar.
Na tela apareceu:
C:\SISTEMA> DIR
CLIENTES.DBF
FATURA.DBF
CALCULA.EXE
README.TXT
Lloyd abriu o README.
Havia apenas uma frase:
“NÃO APAGAR. É IMPORTANTE.”
Nenhuma assinatura.
Nenhuma documentação.
Nenhum responsável.
Nenhuma explicação.
Lloyd ficou maravilhado.
O auditor pediu café.
E em algum lugar do castelo, provavelmente às 03:17, um velho batch COBOL terminou com:
CC 0000
sem jamais imaginar que, décadas depois, continuávamos tentando resolver exatamente o mesmo problema.
Porque computadores mudam.
Linguagens mudam.
Storage muda.
Redes mudam.
Cloud muda.
IA muda.
Mas existe uma constante assustadoramente retrocompatível:
Toda tecnologia que começa como experiência pode acabar virando infraestrutura crítica antes que alguém perceba.
E talvez essa seja a verdadeira magia que Lloyd de Saloum precisava aprender.
Não a magia de criar sistemas.
Mas a magia muito mais difícil de saber quais sistemas existem, por que existem, quem responde por eles e o que acontecerá quando alguma coisa der errado.
☕ Bem-vindo ao Bellacosa Mainframe.
Onde até um PC esquecido debaixo de uma mesa pode esconder uma dungeon inteira de governança corporativa.
