 |
| Bellacosa Mainframe e a auditoria de software |
☕ Um Café no Bellacosa Mainframe
Auditoria de Software em Mainframe
Muito Além do Código: Como Descobrir a Saúde de um Sistema que Movimenta Bancos, Seguradoras e Governos
"O bom desenvolvedor faz o programa funcionar. O excelente desenvolvedor faz o programa continuar funcionando durante décadas. A auditoria existe justamente para descobrir a diferença."
Introdução
Quando alguém ouve a palavra auditoria, normalmente imagina alguém procurando erros, apontando culpados ou produzindo relatórios intermináveis.
No universo do IBM Mainframe, a realidade é completamente diferente.
A auditoria de software é uma disciplina de engenharia.
Ela mede qualidade.
Mede risco.
Mede maturidade.
Mede sustentabilidade.
Principalmente, mede algo extremamente valioso:
a capacidade de um sistema continuar funcionando daqui a vinte anos.
Poucas plataformas do mundo possuem aplicações executando continuamente há 30, 40 ou até 60 anos.
Isso muda completamente a forma de avaliar software.
Enquanto no mundo web normalmente pergunta-se:
"Está funcionando?"
No IBM Z pergunta-se:
"Continuará funcionando depois das próximas mil mudanças?"
Essa pequena diferença muda toda a filosofia de auditoria.
A origem da auditoria de software
Curiosamente, a auditoria de software nasceu praticamente junto com os primeiros computadores comerciais.
Na década de 1960, grandes bancos perceberam um problema.
Era impossível validar manualmente milhões de transações.
Foi necessário criar processos para responder perguntas como:
Quem alterou este programa?
Quando?
Por quê?
Quem autorizou?
Existe documentação?
Existe teste?
Existe rollback?
Foi aí que nasceram conceitos que hoje chamamos de:
Governança
Compliance
Rastreabilidade
Gestão de Configuração
Segregação de Funções
Muito antes de DevOps existir.
Auditoria não procura bugs
Esse talvez seja o maior mito.
Uma auditoria séria quase nunca começa olhando código.
Ela começa olhando processos.
Porque processos ruins inevitavelmente geram software ruim.
O grande tripé
Toda auditoria madura observa três pilares.
Pessoas
Quem desenvolve?
Quem revisa?
Quem aprova?
Existe segregação?
Existe treinamento?
Existe documentação?
Processo
Como mudanças acontecem?
Existe fluxo formal?
Existe versionamento?
Existe rollback?
Existe aprovação?
Produto
Como está o software?
É complexo?
É duplicado?
É documentado?
É testado?
É sustentável?
O que normalmente é auditado
Uma auditoria completa pode analisar dezenas de aspectos.
Entre eles:
Código-fonte
COBOL
PL/I
Assembler
JCL
REXX
Easytrieve
Banco de Dados
DB2
IMS DB
VSAM
Processamento Batch
Dependências
Restart
Checkpoint
Performance
Online
CICS
IMS DC
MQ
APIs
Segurança
RACF
Permissões
Criptografia
Auditoria
Operação
JES2
WLM
RMF
SMF
Indicadores clássicos
Uma auditoria profissional mede indicadores.
Não opiniões.
1. Complexidade Ciclomática
Criada por Thomas McCabe em 1976.
Ela mede quantos caminhos independentes existem no programa.
Quanto maior o número...
Maior o risco.
Exemplo
IF
ELSE
END-IF
Possui baixa complexidade.
Agora imagine dezenas de:
IF
EVALUATE
PERFORM
GO TO
ALTER
A complexidade explode.
Valores típicos
Até 10 → Excelente
10–20 → Bom
20–40 → Atenção
Acima de 50 → Alto risco
2. Tamanho do Programa
Nem sempre maior significa pior.
Mas programas enormes costumam esconder problemas.
Exemplo
COBOL com
40.000 linhas
é muito diferente de
40 módulos com 1.000 linhas.
3. Acoplamento
Quanto um programa depende dos outros.
Alto acoplamento significa:
qualquer mudança provoca efeito dominó.
4. Coesão
Quanto um módulo faz apenas uma responsabilidade.
Alta coesão
é excelente.
Baixa coesão
indica "programa faz tudo".
5. Duplicação
Quanto código repetido existe.
Ferramentas modernas conseguem localizar blocos duplicados automaticamente.
6. Cobertura de Testes
Quantos caminhos realmente foram testados.
No Mainframe isso inclui:
Batch
Online
Abends
Rollback
Recovery
Restart
7. Taxa de Mudanças
Quantas alterações um programa recebe por ano.
Programas alterados constantemente merecem atenção especial.
8. Taxa de Defeitos
Quantos defeitos aparecem após produção.
Pode ser medida por:
1000 linhas
100 mudanças
Sprint
Release
Aplicação
9. Tempo Médio para Correção
MTTR
Quanto tempo demora para corrigir um incidente.
10. Disponibilidade
Quanto tempo o sistema permanece disponível.
No IBM Z frequentemente encontramos:
99,99%
99,999%
ou superior.
Rácios importantes
Uma auditoria raramente olha números isolados.
Ela cruza informações.
Defeitos por KLOC
Quantidade de defeitos
/
1000 linhas
Alterações por Programa
Mudanças
/
Quantidade de módulos
Incidentes por Release
Muito usado em bancos.
Percentual de Reprocessamentos
Quanto batch precisou ser executado novamente.
Percentual de Abends
Número de abends
/
Número total de Jobs
Percentual de Rollback
Importante para CICS.
Percentual de Mudanças Emergenciais
Mudanças urgentes
/
Mudanças totais
Quanto maior esse índice...
Menor costuma ser a maturidade.
Indicadores específicos de COBOL
Existem métricas interessantes.
Número médio de:
IF
EVALUATE
PERFORM THRU
GO TO
COPYBOOKS
DECLARATIVES
SQL EMBEDDED
CALL
Dynamic CALL
Static CALL
Indicadores de JCL
Quantidade média de:
STEP
COND
IF/THEN
RESTART
GDG
Temporary Dataset
SORT
IDCAMS
IEFBR14
Quanto maior a padronização...
Melhor.
Indicadores de DB2
Número de:
Tablespaces
Indexes
Packages
RUNSTATS vencidos
REORG pendentes
Locks
Deadlocks
Escalation
Access Path alterado
Indicadores CICS
Número médio de
Transações
Abends
Pseudo-Conversational
Syncpoint
Threadsafe
Storage Violations
Temporary Storage
Transient Data
Indicadores Operacionais
SMF
CPU
MSU
zIIP
Tempo Batch
Janela Batch
Fila JES
Espera em Dataset
Tempo em DB2
Tempo em MQ
Tempo em VSAM
O que um auditor experiente enxerga rapidamente
Ele procura padrões.
Por exemplo.
Programa de 60 mil linhas.
Pouquíssimos comentários.
Mais de 200 GO TO.
Sem testes.
Última documentação em 1998.
Esse programa funciona?
Provavelmente.
É saudável?
Talvez não.
As melhores práticas do mercado
1. Revisão por pares
Nenhum código importante deve entrar em produção sem revisão.
2. Versionamento
Hoje Git já faz parte do universo IBM Z.
3. Integração Contínua
Build automático.
Testes automáticos.
Deploy controlado.
4. Padronização
Naming.
Layout.
Comentários.
Copybooks.
Macros.
5. Código pequeno
Programas menores.
Mais simples.
Mais reutilizáveis.
6. Automatização
Quanto menos atividade manual...
Menor chance de erro.
7. Documentação viva
Nunca documente apenas uma vez.
Documentação envelhece.
8. Métricas contínuas
Não espere auditoria anual.
Métricas devem ser diárias.
Ferramentas frequentemente utilizadas
No ecossistema IBM Z encontramos soluções como:
IBM Application Discovery and Delivery Intelligence (ADDI)
IBM Developer for z/OS (IDz)
IBM Debug for z/OS
IBM File Manager
IBM Fault Analyzer
IBM Application Performance Analyzer
IBM z/OS Debugger
IBM Z IntelliMagic Vision
SonarQube (com plugins específicos para COBOL)
Micro Focus Enterprise Analyzer
BMC AMI DevX
Broadcom Endevor
IBM Engineering Workflow Management
Cada uma observa um aspecto diferente do ciclo de vida.
O que diferencia uma auditoria madura
Ela não gera apenas números.
Ela responde perguntas.
Como:
Onde está o maior risco?
Qual aplicação envelheceu?
Qual equipe produz menos defeitos?
Qual módulo merece refatoração?
Qual banco precisa reorganização?
Onde investir primeiro?
Um erro muito comum
Medir produtividade por linhas de código.
Isso é péssimo.
Um excelente desenvolvedor frequentemente reduz milhares de linhas.
Menos código.
Menos defeitos.
Menos manutenção.
Mais qualidade.
Outro erro clássico
Medir apenas velocidade.
Velocidade sem qualidade gera retrabalho.
Retrabalho custa caro.
Muito caro.
Curiosidade
Muitos bancos utilizam indicadores internos que jamais são divulgados.
Alguns acompanham centenas de métricas diariamente.
Não apenas software.
Também:
CPU
Storage
I/O
MSU
Licenciamento
Tempo de resposta
Custo por transação
Consumo energético
Capacidade futura
Easter Egg
Você sabia que um dos primeiros conceitos de métricas estruturadas para software surgiu antes mesmo da popularização da Engenharia de Software como disciplina?
Na década de 1970, organizações financeiras perceberam que um programa COBOL "que nunca dava problema" geralmente compartilhava características curiosas:
poucos desvios incondicionais (
GO TO);lógica de negócio bem dividida em parágrafos;
convenções de nomenclatura consistentes;
alterações pequenas e frequentes, em vez de grandes reescritas.
Décadas depois, muitos desses princípios foram formalizados em métricas de qualidade e continuam válidos até hoje.
Pontos de atenção
⚠ Nem toda dívida técnica aparece no código. Muitas vezes ela está na documentação ausente, nos processos informais ou na dependência de um único especialista.
⚠ Indicadores isolados enganam. Um programa grande pode ser excelente, enquanto um programa pequeno pode concentrar enorme risco. Sempre correlacione métricas.
⚠ Mudanças emergenciais recorrentes são um sinal de alerta. Se a exceção virou rotina, há problemas no planejamento, nos testes ou na governança.
⚠ Softwares críticos exigem histórico. Uma boa auditoria valoriza rastreabilidade: requisito, alteração, teste, aprovação e implantação devem formar uma cadeia verificável.
⚠ Ferramentas ajudam, mas não substituem experiência. Um relatório automatizado aponta sintomas; um auditor experiente identifica causas.
Como evoluir na carreira de Auditor de Software Mainframe
Se você deseja atuar nessa área, desenvolva competências em camadas:
Nível 1 — Fundamentos
COBOL
JCL
TSO/ISPF
SDSF
VSAM
DB2
CICS
Nível 2 — Operação
JES2
WLM
RMF
SMF
RACF
Catálogos
Performance
Nível 3 — Engenharia
Métricas de software
Refatoração
Arquitetura
Design de sistemas
Gestão de configuração
CI/CD para IBM Z
Nível 4 — Governança
ITIL
COBIT
ISO/IEC 25010 (qualidade de software)
ISO/IEC 12207 (ciclo de vida)
NIST Cybersecurity Framework
Auditoria baseada em risco
Nível 5 — Visão Estratégica
O diferencial dos grandes auditores não é conhecer todas as instruções do COBOL ou todos os parâmetros do JCL.
É conseguir responder perguntas como:
Onde estão os maiores riscos para o negócio?
Qual aplicação merece modernização primeiro?
Quanto custa manter esse sistema?
O risco de uma alteração é aceitável?
A arquitetura atual suporta o crescimento esperado?
Quando você conecta métricas técnicas aos objetivos do negócio, deixa de ser apenas um especialista em tecnologia e passa a atuar como um consultor estratégico.
Conclusão
A auditoria de software em Mainframe não é uma caça aos erros nem uma atividade burocrática. Ela é um processo contínuo de medição, análise e melhoria que transforma dados em decisões. Organizações que monitoram indicadores de qualidade, complexidade, desempenho, segurança e manutenção conseguem reduzir riscos, aumentar a estabilidade e prolongar a vida útil de aplicações que sustentam operações críticas há décadas.
No estilo Bellacosa Mainframe, vale lembrar uma última lição:
"Software não envelhece porque foi escrito em COBOL. Ele envelhece quando ninguém mais consegue entendê-lo, medi-lo ou evoluí-lo. A melhor auditoria não é a que encontra problemas; é a que cria um ambiente onde eles deixam de nascer."
Porque, no fim das contas, um sistema crítico não é aquele que nunca muda. É aquele que consegue mudar continuamente sem perder a confiança de milhões de usuários. Essa é a verdadeira medida de excelência em engenharia de software no IBM Z.
Sem comentários:
Enviar um comentário