☕ 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

Mostrar mensagens com a etiqueta Technical Debt. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Technical Debt. Mostrar todas as mensagens

segunda-feira, 7 de setembro de 2026

O Manual da Guilda do Programador Mainframe — Do Rank F ao Rank S

 
Bellacosa Mainframe e o manual para um dev programador cobol iniciante nas artes secretas do mainframe

☕ Um Café no Bellacosa Mainframe

O Manual da Guilda do Programador Mainframe — Do Rank F ao Rank S

Ou: como COBOL, JCL, Db2, CICS, RACF, dumps, documentação, café, S0C7, SQLCODE -911, ICH408I, Technical Debt, Deadline e o Demon Lord Boleto transformaram uma carreira de TI no RPG mais longo que você jamais instalou

Existe um momento inesquecível na vida de todo programador mainframe.

Você recebe seu primeiro USERID.

Alguém lhe entrega uma senha temporária.

Você acessa uma tela preta.

No alto aparece algo que parece ter sido construído numa civilização anterior à invenção do mouse.

Você olha aquilo.

Aquilo olha para você.

Parabéns.

Você acaba de entrar na:


GUILDA DOS PROGRAMADORES MAINFRAME

Seu Rank atual:

F

Sua classe:

Novato

Experiência:

0 XP

Equipamento:

  • um notebook corporativo;

  • um USERID recém-criado;

  • uma senha que expirará no pior momento possível;

  • três PDFs;

  • acesso limitado;

  • nenhum conhecimento sobre produção;

  • uma caneca de café.

Sua primeira quest aparece:

ALTERE UMA MENSAGEM NUM PROGRAMA COBOL.

Dificuldade estimada:

⭐

Dificuldade percebida pelo novato:

⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐

Você ainda não sabe, mas acabou de iniciar um dos RPGs profissionais mais longos existentes.

Não existe tela de Game Over.

Existe:

ABEND



1. Antes de começar: escolha sua classe

Nos RPGs tradicionais escolhemos Warrior, Mage, Cleric ou Rogue.

No Mainframe RPG também existem classes.

COBOL Developer — Warrior

Ataca problemas diretamente.

Sua arma principal é:

IF
   ...
ELSE
   ...
END-IF

Possui resistência extraordinária a sistemas com quarenta anos.

Fraqueza natural:

dados inválidos.


Db2 Specialist — Mage

Manipula entidades invisíveis chamadas tabelas, índices, packages e access paths.

Seu feitiço favorito:

SELECT

Seu feitiço proibido:

DELETE FROM TABELA;

sem WHERE.

Quando isso acontece, nem resurrection spell resolve facilmente.


CICS Specialist — Rogue

Extremamente rápido.

Trabalha em milissegundos.

Conhece transações, regions e resources.

Seu inimigo natural é alguém dizendo:

“CICS está lento.”

Sem fornecer nenhuma outra informação.


RACF Administrator — Paladin

Guardião das portas.

Decide quem entra.

Quem lê.

Quem altera.

Quem executa.

Seu poder supremo é dizer:

ACCESS DENIED.

Não importa se você é diretor, gerente, arquiteto ou primo do CEO.


System Programmer — Archmage

Classe misteriosa.

Habita regiões profundas do reino chamadas PARMLIB, PROCLIB e SYS1.

Fala palavras como:

IPL.

APF.

LPA.

SVC.

SMF.

WLM.

SMP/E.

Quando entra numa War Room, todos ficam um pouco mais tranquilos.

Ou mais preocupados.

Depende da expressão dele.



2. Rank F — O Novato

Você começa no Rank F.

Não sabe quase nada.

E isso é perfeitamente normal.

Seu primeiro grande aprendizado é descobrir que não saber não é um defeito inicial: é o estado padrão da profissão.

Quests do Rank F

  • acessar TSO/ISPF;

  • navegar entre datasets;

  • entender PDS e membros;

  • editar um programa COBOL;

  • compilar;

  • executar um JOB;

  • consultar SDSF;

  • descobrir por que o JOB não terminou;

  • aprender a diferença entre erro de compilação e ABEND;

  • entender que produção não é lugar para experiências criativas.

Equipamento inicial

Espada COBOL +1

Escudo JCL +1

Mapa ISPF +2

Poção Café +5 concentração

Pergaminho “Manual da Empresa” +10 confusão

Skill especial

ASK SENIOR

Cooldown:

depende do humor do senior.

É provavelmente a skill mais importante dessa fase.



3. O primeiro monstro: JCL ERROR

Você submete seu primeiro JOB.

Espera.

Nada.

Olha novamente.

Descobre uma mensagem.

O coração acelera.

Você pensa:

“Quebrei o mainframe.”

Não.

Provavelmente esqueceu uma vírgula.

Mas essa primeira batalha ensina uma regra fundamental:

Leia a mensagem de erro.

Parece óbvio.

Não é.

Programadores frequentemente passam vinte minutos imaginando teorias sofisticadas enquanto o sistema está dizendo exatamente o problema.

O aventureiro experiente aprende:

Primeiro leia o que o monstro escreveu.

Depois desembainhe a espada.



4. Rank E — Junior

Depois de algumas quests você sobe para Rank E.

Agora consegue fazer pequenas alterações sem supervisão constante.

Isso produz um fenômeno perigoso:

confiança.

Você começa a achar que entende o sistema.

O sistema percebe.

E envia seu primeiro boss.

S0C7


5. Boss #1 — S0C7, o Devorador de Dados

Você executa o programa.

Ele morre.

Na tela:

S0C7

O novato pergunta:

— O que significa?

O veterano responde:

— Data Exception.

Tradução RPG:

Você tentou tratar alguma coisa como número e aquilo discordou.

Talvez um campo numérico contenha dados inválidos.

Talvez exista problema de definição.

Talvez um movimento tenha colocado conteúdo inesperado numa área.

A batalha começa.

Armas contra S0C7

  • dump;

  • offset;

  • listing;

  • compile options;

  • análise dos dados;

  • conhecimento das PICs;

  • atenção.

XP recebido

+350 DEBUGGING

Achievement desbloqueado

“Meu primeiro ABEND.”

Todo programador mainframe deveria receber um badge por isso.


6. Rank D — Pleno em formação

Agora você começa a compreender que programa nenhum vive sozinho.

Seu COBOL conversa com:

Db2.

VSAM.

CICS.

MQ.

Arquivos.

Outros programas.

Jobs.

APIs.

Usuários.

E processos de negócio criados antes de você entrar na empresa.

Você acaba de desbloquear:

DEPENDENCY HELL

A dungeon aumentou.


7. A Party

Nenhum aventureiro sensato entra sozinho numa dungeon perigosa.

No mainframe também não deveria.

Sua party pode possuir:

COBOL Developer

Ataca o código.

DBA

Controla os dragões relacionais.

System Programmer

Manipula as forças fundamentais do z/OS.

Security Specialist

Possui as chaves do castelo.

Production Control

Conhece horários e dependências.

Business Analyst

Traduz a misteriosa linguagem dos usuários.

Support

Sabe onde os cadáveres estão enterrados.

A grande skill profissional aparece quando você percebe:

não precisa saber tudo; precisa saber quem sabe.

Isso vale mais XP do que decorar centenas de comandos.


8. Boss #2 — SQLCODE -911, o Senhor dos Locks

Você escreve SQL.

Testa.

Funciona.

Produção chega.

Então:

SQLCODE = -911

O monstro apareceu.

Rollback.

Deadlock.

Timeout.

Seu programa estava disputando recursos com outra coisa.

Você descobre que bancos de dados não são bibliotecas silenciosas.

São cidades.

Centenas ou milhares de transações querem acessar recursos simultaneamente.

Algumas leem.

Outras alteram.

Algumas seguram locks.

Outras esperam.

Até que Db2 olha para a situação e decide:

“Alguém precisa morrer.”

Parabéns.

Foi sua transação.

Skills necessárias

  • compreender COMMIT;

  • entender ROLLBACK;

  • conhecer locking;

  • investigar concorrência;

  • analisar tempo de transação;

  • compreender access paths;

  • conversar com DBA.

XP

+750 CONCURRENCY

Loot

Anel do COMMIT Frequente

Use com sabedoria.

Commit demais também pode trazer problemas.


9. Rank C — O profissional que começa a enxergar o sistema

Aqui ocorre uma transformação importante.

Você deixa de perguntar apenas:

“Onde está o erro?”

E começa a perguntar:

“Por que esse erro aconteceu?”

Essa mudança parece pequena.

Não é.

É a passagem de executor para analista.

O Rank F corrige o registro.

O Rank C pergunta quem gerou o registro errado.

O Rank F reinicia o JOB.

O Rank C pergunta por que ele falhou.

O Rank F libera espaço.

O Rank C pergunta por que o crescimento não foi previsto.

Você começa a combater causas, não apenas sintomas.


10. Boss #3 — ICH408I, o Guardião das Portas

Você executa alguma coisa.

Recebe:

ICH408I

Você tenta novamente.

ICH408I

Mais uma vez.

ICH408I

O RACF não muda de opinião porque você clicou três vezes.

Esse boss ensina uma das regras fundamentais de segurança:

autenticação não significa autorização.

Você conseguiu entrar no reino.

Isso não significa que pode abrir todas as portas.

Talvez seu USERID não tenha acesso.

Talvez o grupo esteja incorreto.

Talvez o perfil proteja o recurso.

Talvez você precise de READ.

UPDATE.

CONTROL.

ALTER.

E talvez você não devesse receber nenhum deles.

Arma recomendada

Não é:

“Me dê ALTER em tudo.”

A arma correta chama-se:

Least Privilege.

XP

+900 SECURITY

Achievement

“RACF disse não.”


11. Equipamentos raros

Com o tempo você começa a colecionar equipamentos.

Não são espadas.

São ferramentas.

Debugger

Item raro.

Permite observar o monstro antes que ele mate seu programa.

Git

Inventário dimensional.

Guarda versões anteriores das suas armas.

Pipeline CI/CD

Esteira mágica que transporta artefatos entre reinos.

Monitoramento

Olho de Sauron corporativo.

Idealmente usado para observar sistemas, não hobbits.

Logs

Pergaminhos proféticos.

Quase sempre possuem pistas.

Documentação

Item lendário.

Extremamente poderoso.

Raramente atualizado.


12. Rank B — Senior

Aqui surge uma coisa curiosa.

Você sabe muito mais.

Mas começa a dizer:

“Depende.”

O junior acha isso frustrante.

Ele pergunta:

— Qual é a melhor solução?

Senior:

— Depende.

— Qual banco devemos usar?

— Depende.

— Devemos fazer COMMIT aqui?

— Depende.

— Podemos colocar isso em produção?

O senior olha fixamente.

— Depende muito.

Isso não é indecisão.

É percepção de contexto.

Quanto mais você aprende, mais percebe quantas variáveis existem.


13. Boss #4 — Deadline, o Senhor do Tempo

Nenhum treinamento prepara adequadamente para esse monstro.

Deadline possui habilidade especial:

TIME COMPRESSION

Projeto de seis meses.

Prazo:

três meses.

Depois:

dois.

Então alguém pergunta:

“Conseguimos entregar sexta?”

Você olha o calendário.

Hoje é quinta.

Ataques do Deadline

  • reunião de status;

  • daily adicional;

  • planilha vermelha;

  • “quick win”;

  • “só falta um detalhe”;

  • mudança de requisito;

  • reunião para discutir por que existem tantas reuniões.

Defesa

  • estimativa realista;

  • priorização;

  • gerenciamento de risco;

  • documentação;

  • comunicação;

  • coragem profissional para dizer:

“Não.”

Essa última é uma skill Rank A.


14. Boss #5 — Technical Debt, o Monstro que Alimentamos

Esse é diferente.

Ele não aparece repentinamente.

Nós o criamos.

Começa pequeno.

“Depois corrigimos.”

“É temporário.”

“Só para entrar em produção.”

“Na próxima release melhoramos.”

Cada frase adiciona HP ao monstro.

Cinco anos depois existe uma rotina de 8.000 linhas que ninguém quer tocar.

O comentário diz:

* TEMPORARIO - NAO REMOVER
* 2007

Estamos em 2026.

O temporário completou dezenove anos.

Pode votar.

😂

Technical Debt Level 80

Ataques:

  • manutenção cara;

  • regressões;

  • medo de mudança;

  • conhecimento concentrado;

  • documentação inexistente;

  • dependências misteriosas.

Fraqueza

Refactoring controlado.

Testes.

Documentação.

Automação.

Tempo.

Naturalmente, o Deadline Boss geralmente impede que você use essas armas.

Os dois trabalham juntos.


15. Rank A — Especialista

O especialista não é necessariamente quem conhece mais comandos.

É quem possui profundidade suficiente para compreender consequências.

Ele começa a enxergar sistemas como ecossistemas.

Uma alteração COBOL pode afetar Db2.

Db2 pode alterar tempo de resposta.

Tempo de resposta pode afetar CICS.

CICS pode afetar usuários.

Usuários podem afetar faturamento.

Faturamento pode afetar diretoria.

Diretoria pode afetar você.

Tudo está conectado.

Skill desbloqueada

SYSTEM THINKING +100


16. A Skill lendária: reconhecer padrões

Um jovem olha um incidente e vê:

ERROR

O especialista olha e pensa:

“Já vi algo parecido.”

Não exatamente aquilo.

Mas algo parecido.

Essa biblioteca mental foi construída durante milhares de horas.

Incidentes.

Projetos.

Erros.

Migrações.

Falhas.

Sucessos.

Madrugadas.

É uma espécie de machine learning biológico.

Dataset:

sua carreira.

Treinamento:

vinte anos.

Inference:

“Olha aquele job primeiro.”


17. O sorriso ninja

Então aparece uma ferramenta nova.

Nova release.

Interface redesenhada.

Cloud.

API.

IDE.

Pipeline.

Você nunca utilizou exatamente aquela versão.

Cliente pergunta:

— Você sabe fazer?

Você:

😎

— Sei.

Internamente:

🦋🦋🦋🦋

O que você realmente quis dizer foi:

“Conheço suficientemente bem esse tipo de problema para descobrir como essa versão resolveu mudar tudo.”

Isso não é necessariamente blefe.

É confiança na capacidade de aprender.

A skill chama-se:

RELEARN

Rank:

S


18. Rank S — Mestre da Guilda

Pouquíssimos chegam aqui no sentido verdadeiro.

Não é determinado por idade.

Nem apenas por certificações.

Rank S aparece quando conhecimento técnico, experiência, contexto, comunicação e capacidade de formar outras pessoas começam a trabalhar juntos.

O Mestre da Guilda não precisa resolver tudo pessoalmente.

Ele sabe organizar a batalha.

Pergunta:

— O que mudou?

— Quando começou?

— Qual impacto?

— Conseguimos reproduzir?

— Temos rollback?

— Quem conhece esse componente?

— Quais evidências temos?

Observe.

Nenhuma magia.

Somente método.


19. A árvore de Skills

Depois de muitos anos, uma árvore possível poderia parecer assim:

PROGRAMADOR MAINFRAME
│
├── COBOL
│   ├── Estruturas
│   ├── Arquivos
│   ├── Debugging
│   └── Performance
│
├── JCL
│   ├── JOB
│   ├── EXEC
│   ├── DD
│   └── Utilities
│
├── DATA
│   ├── VSAM
│   ├── Db2
│   └── IMS
│
├── ONLINE
│   └── CICS
│
├── INTEGRATION
│   ├── MQ
│   ├── APIs
│   └── z/OS Connect
│
├── SECURITY
│   └── RACF
│
├── DEVOPS
│   ├── Git
│   ├── CI/CD
│   └── Automation
│
└── VETERAN SKILLS
    ├── Debugging
    ├── Comunicação
    ├── Contexto
    ├── Mentoria
    ├── Pattern Recognition
    └── Relearn

A última árvore costuma ser a mais difícil.

Não existe curso de quatro horas para obter vinte anos de contexto.


20. Como ganhar XP de verdade

Nem todo XP vem de certificação.

Alguns dos maiores ganhos acontecem quando algo dá errado.

Quest: corrigir primeiro ABEND

+500 XP

Quest: resolver incidente em produção

+1.000 XP

Quest: admitir que sua alteração causou o incidente

+2.000 XP

Quest: documentar para ninguém repetir

+3.000 XP

Quest: ensinar um junior

+5.000 XP

Quest: impedir um incidente antes que aconteça

+10.000 XP

Curiosamente, essa última geralmente não recebe reconhecimento.

Porque nada aconteceu.

Esse é o paradoxo do bom profissional de infraestrutura.


21. Side quests

Durante sua carreira aparecem missões secundárias.

“Aprenda Python.”

“Conheça Cloud.”

“Faça certificação.”

“Estude APIs.”

“Aprenda Git.”

“Agora containers.”

“Agora IA.”

Você abre seu mapa.

Existem 847 quests pendentes.

E apenas 24 horas por dia.

Então desbloqueia uma habilidade fundamental:

SELECT QUEST

Não tente aprender tudo.

Escolha aquilo que aproxima você de algum objetivo.

Senão você passará a vida coletando XP sem terminar a campanha principal.


22. O item mais raro: Tempo

Dinheiro compra livros.

Cursos.

Computadores.

Certificações.

Mas existe um recurso que não pode ser farmado:

tempo.

Um curso gratuito de quarenta horas custa quarenta horas.

Talvez valha.

Talvez não.

O aventureiro Rank S aprende a perguntar:

“Este conhecimento vale o tempo necessário para adquiri-lo?”

Porque cada curso compete com trabalho, descanso, família, leitura, caminhada...

e anime.

Nunca esqueçamos o anime.


23. O chefão secreto: Síndrome do Impostor

Mesmo depois de milhares de XP aparece uma criatura invisível.

Ela sussurra:

“Você não sabe o suficiente.”

Tecnicamente ela está correta.

Ninguém sabe.

O problema está na conclusão seguinte:

“Portanto você não deveria estar aqui.”

Errado.

O especialista não é aquele que sabe tudo.

É aquele que desenvolveu métodos para lidar com aquilo que não sabe.

Essa distinção salva carreiras.


24. O Boss final

Depois de COBOL.

Depois de Db2.

Depois de CICS.

Depois de RACF.

Depois do S0C7.

Depois do -911.

Depois do ICH408I.

Depois do Deadline.

Depois do Technical Debt.

Você acredita estar preparado.

Então o céu escurece.

A música muda.

Surge uma criatura gigantesca.

HP:

∞

Resistência:

100%

Respawn:

MENSAL

Nome:

BOLETO

O Demon Lord definitivo.


25. Boleto — Level 99

Você pode trocar de emprego.

Boleto acompanha.

Pode virar freelancer.

Ele encontra você.

Pode tornar-se consultor.

Ele escala junto.

Pode tirar férias.

Ele sabe onde você mora.

Sua habilidade suprema chama-se:

VENCIMENTO

Todo mês ele retorna.

Isso explica boa parte da economia da Guilda.

O aventureiro veterano pensa:

“Talvez eu pare de aceitar projetos.”

Boleto:

“Interessante.”

😂

E imediatamente aparece no LinkedIn:

COBOL/Db2 Senior Consultant — Immediate Start — 6 months.

O velho aventureiro olha para a espada pendurada na parede.

Suspira.

— Uma última quest.

Boleto sorri.

Ele já ouviu isso antes.


26. New Game+

Existe, porém, uma fase curiosa da carreira.

Depois de acumular conhecimento suficiente, você começa a ensinar.

E ensinar é uma espécie de:

NEW GAME+

Você retorna às primeiras dungeons.

Só que agora acompanha novos aventureiros.

O junior pergunta:

— O que é S0C7?

Você sorri.

Lembra do seu primeiro.

Explica.

Ele resolve.

Ganha XP.

E alguma coisa interessante acontece.

Você também ganha.

Porque ensinar força a organizar aquilo que anos de experiência deixaram intuitivo.

Talvez essa seja uma das formas mais bonitas de veterania.

Transformar cicatrizes em mapas para quem vem depois.


27. Easter Egg — o verdadeiro Rank S

Existe um segredo escondido neste manual.

Rank S não significa:

Super Senior.

Significa:

Sobrevivente.

Sobreviveu às mudanças.

Às releases.

Aos projetos.

Aos incidentes.

Às tecnologias “que acabariam com o mainframe”.

Às reorganizações.

Às ferramentas revolucionárias.

Às interfaces redesenhadas.

Às certificações.

Ao Ceifeiro Silencioso.

Ao Deadline.

Ao Technical Debt.

E, até agora...

ao Boleto.

Mas sobretudo sobreviveu sem perder completamente uma coisa:

curiosidade.

Porque quando a curiosidade morre, estudar vira apenas obrigação.

E uma carreira tecnológica sem vontade de descobrir coisas novas transforma cada atualização numa punição.


28. A regra de ouro da Guilda

Se eu tivesse que entregar somente uma regra ao programador começando hoje, seria:

Aprenda fundamentos profundamente e ferramentas suficientemente.

Ferramentas mudam.

Interfaces mudam.

Versões desaparecem.

Menus migram.

Produtos são renomeados.

Mas compreender transações, dados, concorrência, segurança, arquitetura, debugging e sistemas continuará permitindo que você reconheça os mesmos monstros usando roupas diferentes.

O goblin de 1998 pode aparecer em 2027 com Kubernetes, API REST e inteligência artificial.

Continua sendo goblin.

Só ganhou marketing.


Epílogo — A próxima quest

03:17.

Telefone toca.

Produção está parada.

Um jovem Rank F olha assustado para o terminal.

Ao lado dele existe um veterano Rank S.

— O que faço?

O veterano coloca a caneca de café sobre a mesa.

— Primeiro, não faça nada.

— Como assim?

— Leia.

Eles olham os logs.

O jovem encontra uma mensagem:

ICH408I

— RACF?

O veterano sorri.

— Talvez.

— Você não sabe?

— Ainda não.

O jovem estranha.

Aquele homem possui décadas de experiência.

Como pode responder “não sei”?

O veterano continua:

— Vamos descobrir.

Nesse instante o jovem aprende uma coisa muito maior do que RACF.

Descobre o verdadeiro significado de experiência.

Não é possuir todas as respostas.

É não precisar fingir que possui.

É saber investigar.

Saber testar.

Saber pedir ajuda.

Saber voltar atrás.

Saber diferenciar evidência de palpite.

Saber quando agir.

E, talvez ainda mais importante...

saber quando não agir.

Alguns minutos depois encontram a causa.

04:02.

Produção retorna.

O jovem sorri.

QUEST COMPLETE

+1.000 XP

SKILL UNLOCKED: INCIDENT ANALYSIS

Ele pergunta:

— Um dia chego ao Rank S?

O veterano pega novamente o café.

— Se continuar estudando.

— Só isso?

— Não.

— Trabalhando?

— Também.

— Então como?

O veterano olha para a enorme sala de máquinas.

COBOL continuará executando.

Db2 continuará protegendo dados.

CICS continuará processando transações.

RACF continuará dizendo não.

S0C7 continuará encontrando campos impossíveis.

SQLCODE -911 continuará lembrando que ninguém trabalha sozinho.

Deadline continuará correndo.

Technical Debt continuará crescendo escondido.

Novas ferramentas chegarão.

Interfaces serão redesenhadas.

E o Boleto...

Bem.

O Boleto jamais será descontinuado.

Ele coloca a mão no ombro do novato.

— Continue entrando nas dungeons.

— Mesmo com medo?

O veterano abre o famoso sorriso ninja.

😎

— Principalmente quando houver algumas borboletas.

O jovem olha novamente para o terminal.

No canto inferior aparece:

READY

A próxima quest já está esperando.

☕ Um Café no Bellacosa Mainframe

Mesmos sistemas. Novas histórias. Sempre um bom café.

Ficha final do personagem

Classe: Programador Mainframe
Rank inicial: F
Rank máximo: S
Arma: Conhecimento
Escudo: Experiência
Poção: Café
Mapa: Documentação
Party: Equipe
Skill lendária: Reaprender
Fraqueza: “É só uma alteraçãozinha”
Boss recorrente: Deadline
Boss ancestral: Technical Debt
Demon Lord: Boleto
Achievement final: Ainda curioso depois de décadas
Próxima missão: READY >

Para saber mais

https://eljefemidnightlunch.blogspot.com/2026/09/a-guilda-dos-aventureiros-mainframe-por.html



quinta-feira, 25 de junho de 2026

Technical Debt, Chaos Engineering e Resiliência no Mundo COBOL

 

Bellacosa Mainframe e divida tecnica, engenharia do caos e resiliencia no mundo mainframe

☕ Um Café no Bellacosa Mainframe

Technical Debt, Chaos Engineering e Resiliência no Mundo COBOL

Uma viagem dos cartões perfurados à engenharia de confiabilidade moderna

Existe uma curiosidade interessante sobre o universo Mainframe.

Boa parte dos desenvolvedores mais jovens acredita que sistemas COBOL foram escritos uma única vez, colocados em produção em algum momento dos anos 80 e simplesmente ficaram funcionando até hoje, imutáveis, como fósseis tecnológicos preservados em um museu digital.

A realidade é completamente diferente.

Poucas plataformas de tecnologia evoluíram tanto quanto o ecossistema IBM Z.

O hardware mudou.

O sistema operacional mudou.

Os compiladores mudaram.

As técnicas de desenvolvimento mudaram.

A forma de entregar software mudou.

As exigências regulatórias mudaram.

E os desenvolvedores também precisaram mudar.

Hoje falamos sobre APIs REST, Git, DevOps, Inteligência Artificial, Observabilidade, Chaos Engineering e Cloud Native. Entretanto, curiosamente, os sistemas que movimentam bilhões de dólares por dia continuam sendo executados por programas COBOL escritos há décadas.

Seria isso uma contradição?

Na verdade, não.

Talvez seja justamente uma demonstração de sucesso.

O primeiro legado não foi um erro

Em 1959 nasceu o COBOL.

Naquela época não existiam metodologias ágeis.

Não existia internet.

Não existiam smartphones.

Muitos programas eram escritos em cartões perfurados.

Armazenamento era caro.

Memória era limitada.

CPU era um recurso precioso.

As equipes construíam software pensando em algo muito importante:

Confiabilidade.

A aplicação precisava funcionar.

Sempre.

Mesmo que demorasse algumas horas para processar milhares de contas bancárias durante a madrugada.

Foi nesse ambiente que nasceu uma cultura extremamente disciplinada.

Documentação.

Padrões.

Controle de mudanças.

Testes.

Auditorias.

Processos.

Talvez os desenvolvedores daquela época não soubessem, mas estavam criando alguns dos primeiros conceitos de Engenharia de Confiabilidade.

Technical Debt: a dívida que todos nós fazemos

Em 1992, Ward Cunningham criou uma analogia brilhante.

Ele comparou decisões de desenvolvimento com empréstimos bancários.

Imagine que você precise entregar um sistema até sexta-feira.

Você poderia construir uma solução perfeita.

Ou poderia desenvolver algo funcional, mais simples, entregando rapidamente.

Você ganha velocidade.

Mas assume uma dívida.

E como toda dívida, ela possui juros.

Esses juros aparecem de várias formas.

Mais bugs.

Mais incidentes.

Mais retrabalho.

Maior consumo de CPU.

Maior dificuldade de manutenção.

Menor velocidade de inovação.

No Mainframe isso acontece frequentemente.

Talvez exista um programa COBOL com 25 mil linhas.

Talvez exista um COPYBOOK criado em 1987.

Talvez apenas um profissional conheça determinada aplicação.

Tudo isso representa dívida técnica.

O problema não é possuir dívida.

O problema é não saber que ela existe.

Nem toda dívida é ruim

Muitos desenvolvedores iniciantes acreditam que Technical Debt sempre significa erro.

Não é verdade.

Às vezes ela é estratégica.

Um banco pode precisar adequar sistemas rapidamente para atender uma nova regulamentação do BACEN.

Uma seguradora pode precisar disponibilizar um novo produto imediatamente.

Uma fintech pode lançar um MVP para validar mercado.

Nesses casos, assumir dívida técnica pode ser perfeitamente aceitável.

Desde que exista um plano para pagá-la posteriormente.

E aqui encontramos uma das primeiras lições importantes para um desenvolvedor COBOL júnior:

Escreva código pensando que alguém precisará entendê-lo daqui a dez anos.

Esse alguém pode ser você mesmo.

O mito da reescrita completa

Existe uma frase bastante comum em empresas:

"Precisamos jogar tudo fora."

Geralmente essa frase surge quando o ambiente está muito complexo.

Mas a IBM apresenta uma visão diferente.

Você não precisa substituir quarenta anos de sistemas.

Você pode modernizar gradualmente.

Esse conceito ficou conhecido como Strangler Pattern.

Imagine um sistema COBOL que processa contas correntes.

Ele continua funcionando.

Mas uma nova camada é criada.

z/OS Connect.

APIs REST.

Microserviços.

Containers.

Aplicações Java.

Python.

Inteligência Artificial.

O COBOL permanece processando transações críticas.

As aplicações modernas apenas consomem seus serviços.

A dívida começa a diminuir sem que seja necessário desligar o coração operacional da empresa.

Testes automatizados são seus melhores amigos

Durante muitos anos, testar em Mainframe significava reservar uma janela de homologação.

Executar jobs.

Analisar relatórios.

Esperar dias.

Hoje isso mudou.

Ferramentas como zUnit permitem criar testes automatizados.

Jenkins integra pipelines.

GitHub Actions executa validações.

DBB facilita builds.

Zowe aproxima o mundo Mainframe das práticas DevOps modernas.

Se você está começando em COBOL, desenvolva o hábito de pensar:

"O que acontece se o CPF estiver inválido?"

"E se a data vier vazia?"

"E se houver overflow?"

Programadores experientes não escrevem apenas funcionalidades.

Eles escrevem confiança.

Code Review: aprendendo com outros desenvolvedores

Uma das melhores maneiras de evoluir tecnicamente é revisar código.

Olhar programas COBOL antigos.

Analisar SQL.

Entender JCLs.

Perguntar.

Questionar.

Aprender.

Muitos problemas são identificados antes mesmo de chegar à produção.

Um cursor esquecido.

Um COMMIT ausente.

Um SORT desnecessário.

Uma consulta DB2 sem índice adequado.

Dois pares de olhos normalmente enxergam mais do que um.

Refatoração não significa reescrever

Refatorar é melhorar.

Não é destruir.

Não é começar do zero.

Pequenas melhorias acumuladas ao longo do tempo fazem enorme diferença.

Renomear variáveis.

Extrair rotinas.

Separar módulos.

Eliminar GOTO.

Criar serviços reutilizáveis.

Transformar programas gigantes em componentes menores.

Refatoração contínua é uma das formas mais eficientes de pagar Technical Debt.

Observabilidade: enxergando o que realmente acontece

Existe uma frase bastante conhecida:

Se você não consegue medir, não consegue melhorar.

No mundo IBM Z temos ferramentas extraordinárias.

SMF.

RMF.

OMEGAMON.

Instana.

Grafana.

Elas permitem compreender:

CPU.

I/O.

Latência.

Filas.

Conexões.

Transações.

Antes de corrigir qualquer problema, precisamos enxergá-lo.

Observabilidade é a base da engenharia moderna.

Chaos Engineering: quebrando para aprender

Talvez o conceito mais surpreendente para desenvolvedores COBOL seja Chaos Engineering.

A ideia surgiu popularmente na Netflix.

Mas a IBM mostra que ela pode ser aplicada em praticamente qualquer ambiente.

O princípio é simples.

Não espere uma falha em produção.

Provoque pequenas falhas.

Aprenda.

Corrija.

Teste novamente.

Por exemplo:

O que acontece se o IMS Connect ficar indisponível?

Se a fila MQ atingir 95% de ocupação?

Se um membro do Sysplex parar?

Se o DB2 responder lentamente?

Chaos Engineering não significa desligar servidores aleatoriamente.

É ciência.

Você cria uma hipótese.

Executa um experimento controlado.

Observa.

Aprende.

Melhora.

Repete.

Resiliência é um investimento

A IBM utiliza uma analogia muito interessante.

Imagine um ciclista.

Ele pode sair apenas com a bicicleta.

Ou levar uma bomba de ar.

Kit de reparo.

Câmara reserva.

Pneu reserva.

Carro de apoio.

Mecânico.

Quanto maior a disponibilidade desejada, maior será o custo.

Em tecnologia ocorre exatamente o mesmo.

Alta disponibilidade.

Disaster Recovery.

Cyber Recovery.

Backups.

Replicação.

GDPS.

Sysplex.

Active-Active.

Tudo possui custo.

O objetivo não é atingir disponibilidade infinita.

O objetivo é encontrar equilíbrio entre risco, orçamento e necessidade do negócio.

O desenvolvedor COBOL de 2026

O profissional COBOL moderno não é apenas alguém que conhece MOVE, PERFORM e READ.

Ele entende Git.

Conhece APIs.

Aprende DevOps.

Sabe interpretar métricas.

Participa de revisões.

Automatiza testes.

Compreende observabilidade.

Conhece conceitos de segurança.

Entende resiliência.

Estuda Inteligência Artificial.

E principalmente, continua cultivando algo que sempre esteve presente no universo Mainframe:

Disciplina técnica.

Os sistemas que movimentam bilhões de transações diariamente não permanecem relevantes por acaso.

Eles permanecem relevantes porque existem profissionais dispostos a compreender o passado, melhorar continuamente o presente e testar constantemente o futuro.

E talvez seja exatamente essa a maior lição do Mainframe.

Tecnologia muda.

Ferramentas mudam.

Buzzwords mudam.

Mas excelência em engenharia continua sendo atemporal.

E isso, felizmente, nunca sai de moda.

Até o próximo café.

☕ Bellacosa Mainframe


Bellacosa Mainframe Network

Siga nossas newsletters e comunidades no LinkedIn

quarta-feira, 3 de junho de 2026

☕💣📋 HOW TO PAY BACK TECHNICAL DEBT — O DIA EM QUE O PROGRAMADOR COBOL DESCOBRIU QUE ESTAVA PAGANDO JUROS POR UMA DECISÃO TOMADA EM 1998

 

Bellacosa Mainframe como pagar dividas tecnicas em mainframe



☕💣📋 HOW TO PAY BACK TECHNICAL DEBT — O DIA EM QUE O PROGRAMADOR COBOL DESCOBRIU QUE ESTAVA PAGANDO JUROS POR UMA DECISÃO TOMADA EM 1998

Existe uma frase muito conhecida no mercado de tecnologia:

"Toda empresa tem dívida técnica. Algumas apenas ainda não receberam a cobrança."

Para um programador COBOL Mainframe júnior, a expressão "dívida técnica" parece algo moderno, criado por arquitetos ágeis, consultores de transformação digital ou gurus do DevOps.

Mas a verdade é muito mais divertida.

Muito antes de alguém inventar Scrum, Kanban, DevOps, GitHub ou Microservices, os programadores COBOL já acumulavam dívida técnica sem saber.

Toda vez que alguém dizia:

"Depois a gente arruma."

Nascia uma nova parcela.

E em muitos ambientes z/OS, ainda estamos pagando prestações de decisões tomadas há 20 ou 30 anos.

Pegue seu café porque hoje vamos entender como identificar, medir, controlar e pagar dívida técnica sem derrubar a produção.


O QUE É DÍVIDA TÉCNICA?

A definição mais simples é:

Dívida técnica é o custo futuro criado por uma decisão técnica tomada para resolver um problema rapidamente hoje.

Imagine um programa COBOL.

Você precisa entregar uma alteração urgente.

O correto seria:

  • Revisar arquitetura

  • Atualizar documentação

  • Criar testes

  • Refatorar módulos

Mas o prazo é amanhã.

Então alguém faz:

IF CLIENTE = '999999'
    GO TO TRATAMENTO-ESPECIAL.

Entrega.

Produção funciona.

Cliente feliz.

Projeto encerrado.

Mas daqui a dois anos ninguém lembra por que aquele IF existe.

A dívida nasceu.


O MAIOR MITO DO MAINFRAME

Muita gente acredita que:

"Código antigo é dívida técnica."

Errado.

Código antigo pode ser excelente.

Existem programas COBOL escritos nos anos 80 que ainda hoje são exemplos de engenharia.

Por outro lado, existem programas escritos há seis meses que já nasceram endividados.

A idade do código não importa.

O que importa é:

  • Complexidade

  • Manutenibilidade

  • Clareza

  • Testabilidade

  • Documentação


COMO IDENTIFICAR DÍVIDA TÉCNICA

O primeiro passo é aprender a enxergá-la.

Alguns sintomas clássicos:

Programa que ninguém quer alterar

Quando uma demanda chega e todos falam:

"Tomara que não seja naquele programa..."

Existe dívida.


Alteração simples demora dias

Mudança:

Trocar 20 para 25.

Tempo gasto:

3 dias

Existe dívida.


Muitos abends

Se o mesmo módulo gera incidentes frequentemente:

  • S0C7

  • S0C4

  • SQLCODE negativos

  • Arquivos inconsistentes

Existe dívida.


Dependência de especialistas

Quando apenas uma pessoa entende o sistema.

Isso é uma dívida técnica humana.

Extremamente perigosa.


A METÁFORA DO CARTÃO DE CRÉDITO

A IBM utiliza uma analogia excelente.

Imagine um cartão.

Você compra algo hoje.

O benefício é imediato.

O pagamento fica para depois.

Dívida técnica funciona igual.

Benefício imediato:

Entreguei no prazo

Pagamento futuro:

Mais manutenção
Mais defeitos
Mais testes
Mais retrabalho

O problema não é usar o cartão.

O problema é esquecer da fatura.


COMO MAPEAR A DÍVIDA TÉCNICA

A primeira atividade prática é criar um inventário.

Monte uma planilha contendo:

SistemaProblemaImpactoPrioridade
CadastroGO TO excessivoMédioMédia
CobrançaSem documentaçãoAltoAlta
FaturamentoAlta complexidadeAltoAlta

Você não consegue corrigir aquilo que não consegue enxergar.


MÉTRICA 1 – COMPLEXIDADE CICLOMÁTICA

Uma das métricas mais famosas.

Ela mede quantos caminhos lógicos existem em um programa.

Exemplo:

IF A
   ...
ELSE
   ...
END-IF

Pouca complexidade.

Agora imagine:

IF A
 IF B
  IF C
   IF D

A complexidade explode.

Quanto maior a complexidade:

  • Mais difícil testar

  • Mais difícil manter

  • Maior risco de erro

Regra prática:

ValorSituação
1 a 10Boa
11 a 20Atenção
Acima de 20Risco

MÉTRICA 2 – TEMPO DE MANUTENÇÃO

Métrica simples.

Quanto tempo leva para implementar uma mudança?

Exemplo:

Alteração simples:

4 horas

Virou:

3 dias

A dívida está cobrando juros.


MÉTRICA 3 – QUANTIDADE DE INCIDENTES

Monitore:

  • Chamados

  • Tickets

  • Problemas recorrentes

Se determinado programa gera:

20% dos incidentes

Ele deve entrar imediatamente no backlog técnico.


MÉTRICA 4 – COBERTURA DE TESTES

Quanto do sistema possui testes?

Exemplo:

10%

Muito arriscado.

80%

Muito saudável.

No mundo COBOL isso pode envolver:

  • Unit Test

  • Testes automatizados

  • Batch Validation


MÉTRICA 5 – TEMPO MÉDIO DE RECUPERAÇÃO

MTTR

Mean Time To Recovery.

Quanto tempo leva para resolver um problema?

Exemplo:

10 minutos

Excelente.

8 horas

Existe forte dívida técnica.


A REGRA DOS 20%

Uma prática muito utilizada é reservar:

80% desenvolvimento
20% redução de dívida técnica

Isso impede que a dívida cresça infinitamente.


TÉCNICA 1 – REFATORAÇÃO CONTÍNUA

Refatorar significa melhorar sem alterar comportamento.

Exemplo:

Antes:

GO TO ERRO.
GO TO ERRO.
GO TO ERRO.

Depois:

PERFORM TRATA-ERRO.

Mesmo resultado.

Código mais limpo.


TÉCNICA 2 – MODULARIZAÇÃO

Programas gigantes são fábricas de dívida.

Já encontrei programas com:

80.000 linhas

Divida responsabilidades.

Crie módulos menores.

Mais simples de entender.

Mais simples de testar.


TÉCNICA 3 – DOCUMENTAÇÃO VIVA

Documentação morta é inútil.

Documentação viva é atualizada junto com o sistema.

Documente:

  • Fluxos

  • Arquivos

  • Tabelas

  • Regras de negócio


TÉCNICA 4 – ELIMINAÇÃO DE CÓDIGO MORTO

Existe um cemitério escondido em todo sistema.

Trechos como:

IF FLAG = 'X'

Que nunca mais executam.

Remover código morto reduz:

  • Complexidade

  • Risco

  • Tempo de manutenção


TÉCNICA 5 – BACKLOG TÉCNICO

Crie um backlog específico.

Exemplo:

Remover GO TO
Documentar módulo
Automatizar teste
Eliminar código morto

A dívida precisa aparecer oficialmente.

Caso contrário ela nunca será priorizada.


FERRAMENTAS ÚTEIS NO MUNDO MAINFRAME

IBM Application Discovery

Mapeia dependências.

Mostra:

  • Programas

  • Arquivos

  • CICS

  • DB2

Excelente para arqueologia de sistemas.


IBM ADDI

Application Discovery and Delivery Intelligence.

Permite visualizar relacionamentos invisíveis.

Muito útil para sistemas legados.


SonarQube

Mesmo para COBOL.

Detecta:

  • Complexidade

  • Duplicação

  • Código suspeito


IBM Developer for z/OS

Auxilia:

  • Navegação

  • Análise

  • Refatoração


Jira

Controle de backlog técnico.

Muitas empresas utilizam para registrar dívida técnica.


EASTER EGG MAINFRAME

Quer descobrir rapidamente onde existe dívida?

Procure:

GO TO
ALTER
NEXT SENTENCE

Ou:

STEP099
STEP100
STEP101

Sem documentação.

Você provavelmente encontrou um sítio arqueológico corporativo.


O ERRO MAIS COMUM DOS JUNIORES

Pensar:

"Vou reescrever tudo."

Não.

Esse é o caminho para o desastre.

A melhor estratégia quase sempre é:

Pequenas melhorias contínuas.

Todo dia.

Toda sprint.

Todo projeto.

Toda manutenção.


COMO EVOLUIR COMO PROFISSIONAL

Programadores experientes não são aqueles que escrevem mais código.

São aqueles que reduzem complexidade.

Quando você consegue olhar para um sistema e dizer:

"Esse trecho vai gerar problema daqui a dois anos."

Você começou a pensar como arquiteto.


O SEGREDO DOS MELHORES ANALISTAS DE SISTEMAS

Eles não combatem apenas bugs.

Eles combatem as causas dos bugs.

Essa é a diferença entre apagar incêndios e construir sistemas duradouros.


CONCLUSÃO

Dívida técnica não é um defeito.

Ela é uma ferramenta.

Em alguns momentos vale a pena assumir a dívida para entregar rapidamente.

O problema surge quando ninguém controla o saldo.

O programador COBOL júnior que aprender a:

  • Identificar dívida

  • Medir dívida

  • Priorizar dívida

  • Reduzir dívida

  • Monitorar dívida

Terá uma visão muito mais próxima de um arquiteto de sistemas do que de um simples codificador.

Porque no fim das contas, o maior segredo do Mainframe não é fazer programas funcionarem.

É garantir que eles continuem funcionando daqui a 30 anos sem que alguém precise vender a alma para entender por quê.



domingo, 6 de maio de 2018

Blog Analytics : Parte III – Como Limpar Milhares de Posts sem Perder SEO Engenharia de Manutenção para Blogs Gigantes

 

Bellacosa Mainframe e o blog analytics parte iii

☕ Um Café no Bellacosa Mainframe

Blog Analytics :  Parte III – Como Limpar Milhares de Posts sem Perder SEO

Engenharia de Manutenção para Blogs Gigantes

O Dia em que Descobri que Corrigir um Erro Pode Ser Muito Mais Perigoso do que Deixá-lo Existir

☕ Um Café no Bellacosa Mainframe

Depois de descobrir o HTML invisível escondido dentro do Feed Atom e identificar as assinaturas deixadas por diferentes ferramentas, surgiu uma pergunta inevitável.

Como limpar milhares de artigos sem destruir anos de indexação no Google?

Essa pergunta muda completamente o tipo de investigação.

Não estamos mais procurando evidências.

Agora estamos entrando na fase mais delicada de toda operação.

A manutenção.

Quem trabalha com IBM Mainframe conhece perfeitamente essa situação.

Modificar um programa COBOL de vinte linhas é simples.

Modificar um sistema que processa bilhões de reais por dia exige uma estratégia completamente diferente.

Blogs com milhares de artigos funcionam exatamente assim.

Quanto maior o acervo, menor deve ser a pressa.


O Primeiro Erro dos Blogueiros

Ao descobrir HTML estranho, muita gente faz exatamente isto:

Seleciona tudo.

Apaga.

Cola novamente.

Publica.

Visualmente parece perfeito.

Na prática pode ser um desastre.

Porque cada republicação modifica elementos importantes do documento.

Entre eles:

  • HTML interno;

  • data de atualização;

  • estrutura do DOM;

  • imagens;

  • âncoras;

  • formatação.

E dependendo do caso...

Até snippets do Google podem mudar.


A Regra Número Um

Nunca trate milhares de artigos como milhares de páginas.

Trate-os como um banco de dados.

Foi exatamente essa mudança de mentalidade que tornou os sistemas IBM tão confiáveis.

Ninguém atualiza milhões de registros manualmente.

Primeiro faz-se um inventário.

Depois uma classificação.

Somente então começa a manutenção.


Fase 1 — Inventário

Antes de alterar qualquer coisa, descubra exatamente o tamanho do problema.

Perguntas fundamentais:

  • Quantos artigos existem?

  • Quantos possuem HTML suspeito?

  • Quantos têm apenas pequenos resíduos?

  • Quantos possuem HTML inválido?

  • Quantos realmente precisam de intervenção?

Quando fizemos a primeira auditoria percebemos algo interessante.

A maioria dos artigos estava perfeitamente saudável.

Ou seja...

Não existia motivo para sair modificando tudo.


O Princípio 80/20

Em acervos grandes normalmente acontece o mesmo fenômeno observado em bancos de dados corporativos.

Poucos registros concentram a maior parte dos problemas.

Em vez de editar quatro mil artigos, talvez apenas algumas dezenas realmente precisem de limpeza.

É um enorme ganho de produtividade.


O Maior Inimigo: A Pressa

Imagine um administrador de banco DB2 recebendo esta ordem:

"Atualize todas as tabelas agora."

Ele jamais faria isso.

Primeiro seriam criados:

  • backup;

  • ambiente de testes;

  • validação;

  • rollback.

Blogs merecem exatamente o mesmo cuidado.


Backup Nunca é Exagero

Antes de qualquer limpeza:

  1. Exporte o Blogger.

  2. Guarde o arquivo XML original.

  3. Faça uma segunda cópia.

  4. Nunca trabalhe sobre o único backup.

É surpreendente a quantidade de pessoas que descobrem um problema justamente depois de salvar por cima do arquivo original.


Classificando os Problemas

Nem todo HTML estranho precisa ser removido.

Ao longo das auditorias comecei a dividir os resíduos em quatro categorias.

Categoria A — Sem Risco

Exemplos:

  • pequenos spans;

  • atributos válidos;

  • estilos mínimos.

Não costumam justificar intervenção.


Categoria B — Recomendável Limpar

Exemplos:

  • excesso de spans;

  • estilos redundantes;

  • classes inúteis.

Melhoram a qualidade do código.


Categoria C — Corrigir

Exemplos:

  • <p><table>

  • headings quebrados

  • HTML inválido

  • marcações mal fechadas

Esses merecem prioridade.


Categoria D — Crítico

Scripts estranhos.

Objetos desconhecidos.

Código corrompido.

Esses exigem investigação imediata.


SEO Não Gosta de Mudanças Bruscas

Existe um mito bastante comum.

"Quanto mais eu editar um artigo, melhor ele ficará."

Nem sempre.

Motores de busca valorizam estabilidade.

Quando uma página muda completamente:

  • snippets podem mudar;

  • trechos destacados desaparecem;

  • links internos precisam ser reprocessados;

  • caches são reconstruídos.

Isso não significa que você nunca deva atualizar conteúdos.

Significa apenas que a atualização deve ser planejada e focada naquilo que realmente agrega valor ou corrige problemas concretos.


A Estratégia Mainframe

Nos bancos nunca se atualizam milhões de registros em produção de uma única vez.

Existe uma sequência clássica:

Inventário

↓

Classificação

↓

Priorização

↓

Teste

↓

Produção

↓

Validação

Descobri que exatamente a mesma estratégia funciona para blogs.


A Auditoria em Lotes

Depois de analisar milhares de artigos percebi que trabalhar em lotes é muito mais eficiente.

Por exemplo:

Semana 1

100 artigos

Semana 2

100 artigos

Semana 3

100 artigos

Ao final de alguns meses praticamente todo o acervo terá sido revisado.

Sem estresse.

Sem risco.

Sem destruir o histórico do blog.


Nunca Atualize Só Porque Pode

Essa talvez seja a lição mais importante.

Encontrar um pequeno span inútil não significa que o artigo inteiro precise ser republicado.

Quanto menos alterações desnecessárias forem feitas, menor a chance de efeitos colaterais.


O Checklist Bellacosa

Antes de qualquer alteração comecei a seguir um pequeno checklist.

✔ Existe backup?

✔ O HTML realmente está errado?

✔ O problema afeta SEO?

✔ O problema afeta acessibilidade?

✔ O leitor percebe?

✔ Vale a pena alterar?

Se alguma resposta for "não", muitas vezes a melhor decisão é simplesmente deixar o artigo como está.

Essa abordagem evita o que engenheiros chamam de overengineering: gastar tempo corrigindo detalhes sem impacto real, introduzindo novos riscos no processo.


O Papel do Feed Atom

O Feed Atom deixa de ser apenas uma fonte de dados.

Ele passa a funcionar como um relatório de auditoria.

É possível descobrir:

  • onde estão os resíduos;

  • quando apareceram;

  • quais ferramentas os produziram;

  • quais artigos precisam de revisão.

É praticamente um inventário completo da saúde técnica do blog.


Automatizando a Limpeza

Depois das primeiras auditorias ficou evidente que boa parte do processo pode ser automatizada.

Uma ferramenta especializada poderia:

✔ localizar HTML inválido;

✔ identificar resíduos do Word;

✔ detectar atributos data-*;

✔ procurar spans desnecessários;

✔ listar tabelas incorretas;

✔ calcular um índice de qualidade.

Em vez de abrir milhares de artigos manualmente, bastaria executar uma única análise.

Seria o equivalente a um utilitário de manutenção de banco de dados aplicado ao universo Blogger.


O Conceito de Dívida Técnica Editorial

Na engenharia de software existe um conceito chamado Technical Debt.

Cada pequena decisão tomada hoje pode aumentar o custo de manutenção amanhã.

Blogs também acumulam dívida técnica.

Ela aparece em forma de:

  • HTML redundante;

  • imagens gigantes;

  • links quebrados;

  • código copiado;

  • estilos antigos;

  • marcações desnecessárias.

Quanto antes ela for controlada, mais saudável permanece o acervo.


O Bellacosa Blog Doctor

Depois dessa experiência comecei a imaginar uma ferramenta que funcionasse como um verdadeiro médico para blogs.

Ela receberia apenas um arquivo Atom.

E produziria um laudo completo.

Por exemplo:

BLOG HEALTH REPORT

Artigos.....................4018

HTML Excelente..............3946

Necessitam Revisão..........54

HTML Inválido...............8

Resíduos IA................11

HTML Word...................7

Google Docs................5

Links Quebrados.............13

Problemas SEO...............16

Score Geral................98,9%

Em poucos segundos seria possível saber exatamente onde concentrar os esforços.

Sem desperdício.

Sem adivinhações.


Conclusão

A maior descoberta desta etapa não foi aprender a remover HTML invisível.

Foi perceber que limpar tudo nem sempre é a melhor solução.

Assim como em um sistema legado de missão crítica, a manutenção de um grande blog deve ser guiada por evidências, prioridade e planejamento.

Cada alteração precisa ter um motivo claro, um benefício mensurável e, acima de tudo, um caminho seguro para voltar atrás caso algo inesperado aconteça.

A verdadeira maturidade não está em corrigir cada detalhe encontrado, mas em saber diferenciar aquilo que representa uma curiosidade técnica daquilo que realmente compromete a qualidade, o SEO e a evolução do acervo.

No próximo capítulo do CSI Blogspot, construiremos uma metodologia completa de auditoria automatizada. Vamos aprender a transformar o Feed Atom em um laboratório forense capaz de analisar milhares de publicações, gerar indicadores de qualidade e produzir um diagnóstico técnico digno de um grande ambiente de produção IBM Mainframe.

Porque, no fim das contas, administrar um blog com milhares de artigos não é muito diferente de administrar um sistema crítico: o segredo não está em mudar tudo, mas em saber exatamente o que mudar, quando mudar e por quê.

🔎 CSI BLOGSPOT · ARQUIVO DE EVIDÊNCIAS

Blog Analytics: A Investigação Completa

Seis capítulos sobre auditoria de HTML, resíduos invisíveis, limpeza segura, checklist técnico e construção do Bellacosa Blog Doctor.

6 relatórios2018HTML · SEO · Blogger
CASE FILE 01

Blog Analytics — Parte I

Como descobrir evidências invisíveis no HTML de um blog antigo.

HTMLAuditoriaBlogspot
CASE FILE 02

Blog Analytics — Parte II

Os resíduos invisíveis deixados por editores, Word, IA e cópias antigas.

ResíduosWord HTMLIA
CASE FILE 03

Blog Analytics — Parte III

Como limpar milhares de posts sem destruir o acervo editorial.

LimpezaBackupQualidade
CASE FILE 04

Blog Analytics — Parte IV

Checklist de auditoria para blogs antigos e acervos com anos de história.

ChecklistSEO TécnicoAuditoria
CASE FILE 05

Blog Analytics — Parte V

Construindo o Bellacosa Blog Doctor e seu scanner automático.

Blog DoctorScannerJavaScript
CASE FILE 06

Blog Analytics — Parte VI

Criando o motor de regras, scores, prioridades e códigos de retorno.

Motor de RegrasScoreMainframe

Índice textual da série Blog Analytics

Esta série investiga a saúde técnica de blogs antigos no Blogger, cobrindo auditoria de HTML, resíduos de editores, SEO técnico, acessibilidade, limpeza segura, diagnóstico automatizado e motores de regras.

  1. Blog Analytics Parte I — Como descobrir evidências invisíveis
  2. Blog Analytics Parte II — Os resíduos invisíveis do HTML
  3. Blog Analytics Parte III — Como limpar com segurança
  4. Blog Analytics Parte IV — Checklist de auditoria
  5. Blog Analytics Parte V — Construindo o Bellacosa Blog Doctor
  6. Blog Analytics Parte VI — Criando o motor de regras
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...