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

☕ Um Café no Bellacosa Mainframe Subscribe on LinkedIn

🚀 COBOL Jr. Subscribe on LinkedIn

💻 Bellacosa Mainframe Follow Company

🟩 COBOL Life Follow Showcase

 

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:

Sistema	Problema	Impacto	Prioridade
Cadastro	GO TO excessivo	Médio	Média
Cobrança	Sem documentação	Alto	Alta
Faturamento	Alta complexidade	Alto	Alta

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:

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

---

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ê.

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

Abrir artigo original

CASE FILE 02

Blog Analytics — Parte II

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

ResíduosWord HTMLIA

Abrir artigo original

CASE FILE 03

Blog Analytics — Parte III

Como limpar milhares de posts sem destruir o acervo editorial.

LimpezaBackupQualidade

Abrir artigo original

CASE FILE 04

Blog Analytics — Parte IV

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

ChecklistSEO TécnicoAuditoria

Abrir artigo original

CASE FILE 05

Blog Analytics — Parte V

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

Blog DoctorScannerJavaScript

Abrir artigo original

CASE FILE 06

Blog Analytics — Parte VI

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

Motor de RegrasScoreMainframe

Abrir artigo original

Í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