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