 |
| Bellacosa Mainframe e as 5 core quality tools |
☕ Um Café no Bellacosa Mainframe
Os 5 Core Quality Tools na Stack IBM Mainframe
O Que Todo Programador COBOL Padawan Precisa Saber Sobre Como Construir Sistemas Bancários que Não Podem Falhar
"A qualidade não nasce durante o teste. Ela nasce muito antes da primeira linha de código ser compilada."
Quando um desenvolvedor COBOL inicia sua jornada no mundo do IBM Mainframe, normalmente acredita que qualidade significa apenas "o programa compilou sem erro" ou "o teste passou".
Essa visão funciona para pequenos projetos.
Mas desaparece completamente quando você entra em uma instituição financeira, seguradora, empresa aérea ou governo.
Ali, uma única linha de COBOL pode movimentar bilhões de reais diariamente.
Uma alteração aparentemente simples em um programa de cálculo de juros pode impactar milhões de clientes.
Uma mudança em um COPYBOOK pode afetar centenas de programas.
Um campo alterado em um registro VSAM pode quebrar integrações com CICS, DB2, MQ, IMS e dezenas de aplicações.
É por isso que grandes empresas não dependem apenas da habilidade do programador.
Elas dependem de processos.
Esses processos são conhecidos mundialmente como Core Quality Tools.
Embora tenham surgido na indústria automotiva através da AIAG (Automotive Industry Action Group) e hoje façam parte da IATF 16949, seus princípios são universais.
Na prática, eles representam exatamente aquilo que faz um ambiente IBM Z operar durante décadas com níveis de disponibilidade próximos de 99,9999%.
E talvez você nunca tenha percebido...
Grande parte da cultura de desenvolvimento Mainframe já segue esses princípios há décadas.
Vamos descobrir como.
O verdadeiro significado de qualidade
Existe uma diferença enorme entre:
"Meu programa funciona."
e
"Meu sistema continuará funcionando pelos próximos vinte anos."
Essa diferença chama-se engenharia de qualidade.
O Mainframe sempre foi pioneiro nisso.
Enquanto muitas plataformas modernas seguem o famoso:
"Deploy rápido e corrige depois."
O Mainframe tradicionalmente segue outra filosofia:
"Planeje tanto que quase não seja necessário corrigir."
Parece exagero?
Pense em um banco.
Imagine que durante o fechamento financeiro do mês:
um JOB falha
uma transação CICS trava
um cálculo de imposto gera valores incorretos
um débito é executado duas vezes
Agora multiplique isso por:
dez milhões de clientes.
A qualidade deixa de ser uma característica técnica.
Ela passa a ser um requisito de sobrevivência.
A fábrica de software também é uma fábrica
Quando olhamos para uma montadora, vemos:
matéria-prima
máquinas
operadores
inspeções
manutenção
produção
Agora olhe para um ambiente Mainframe.
Temos praticamente a mesma estrutura.
| Na indústria | No Mainframe |
|---|---|
| Matéria-prima | Requisitos |
| Projeto | Arquitetura |
| Linha de produção | Pipeline DevOps |
| Máquinas | LPARs IBM Z |
| Ferramentas | COBOL, JCL, DB2, CICS |
| Inspeção | Testes |
| Controle estatístico | Monitoramento SMF/RMF |
| Produto final | Aplicação em produção |
Mudam os nomes.
A engenharia continua exatamente igual.
APQP
Planejamento Avançado da Qualidade
O primeiro erro de um desenvolvedor júnior é acreditar que programação começa no editor COBOL.
Não começa.
Começa muito antes.
Imagine que o banco deseja criar uma nova modalidade de PIX internacional.
Antes de alguém escrever:
MOVE VALOR TO WS-TOTAL.
centenas de decisões já foram tomadas.
Será utilizado DB2?
VSAM?
MQ?
CICS?
Batch?
Online?
REST?
z/OS Connect?
Quais campos serão adicionados?
Quem fará rollback?
Como será a auditoria?
Qual será o SLA?
Como será a recuperação após desastre?
Tudo isso faz parte do equivalente Mainframe do APQP.
O APQP na prática
Em grandes empresas essa etapa envolve:
levantamento de requisitos
arquitetura corporativa
análise de impacto
padrões COBOL
convenções JCL
segurança RACF
definição de índices DB2
planejamento de backup
definição de monitoramento
cronograma
Observe algo interessante.
Nenhuma linha de código foi escrita.
Mesmo assim já existe enorme trabalho.
É exatamente isso que reduz defeitos.
Um exemplo real
Imagine alterar um programa responsável pelo cálculo do FGTS.
Sem planejamento:
"É só incluir um campo."
Na prática:
Esse campo pode existir em:
COPYBOOK
DB2
VSAM
MQ
CICS
telas BMS
APIs REST
batch noturno
relatórios
ETL
Data Warehouse
Uma alteração pode atingir centenas de programas.
O APQP identifica isso antes.
FMEA
Failure Mode and Effects Analysis
Se existe uma ferramenta que todo desenvolvedor deveria aprender, é esta.
O FMEA faz uma pergunta simples:
"O que pode dar errado?"
Mas a resposta nunca é simples.
Exemplo COBOL
Programa:
PAGTO001
Função:
Efetuar pagamento.
O programador pensa:
"O código está certo."
O FMEA pergunta:
E se o arquivo VSAM estiver cheio?
E se ocorrer DEADLOCK no DB2?
E se o MQ estiver indisponível?
E se o cliente enviar CPF inválido?
E se faltar espaço no SORTWK?
E se ocorrer S0C7?
E se houver rollback?
E se duas transações atualizarem o mesmo registro?
Percebe?
O FMEA obriga a pensar como um arquiteto.
Exemplo prático
Modo de falha
Registro duplicado.
Efeito
Cliente recebe pagamento em dobro.
Consequência
Prejuízo financeiro.
Severidade
10
Ocorrência
4
Detecção
3
Risco elevado.
Ação recomendada
Implementar chave única.
Controle transacional.
Logs.
Rollback.
Auditoria.
O FMEA e os ABENDs
Os ABENDs representam excelente fonte para alimentar um FMEA.
Por exemplo:
S0C7
Pode indicar:
dados inválidos.
S806
Programa inexistente.
SB37
Dataset sem espaço.
S322
Timeout.
Cada um desses eventos deveria gerar perguntas:
Como evitar?
Como detectar antes?
Como recuperar automaticamente?
MSA
Measurement System Analysis
Imagine um gerente perguntar:
"Nosso sistema está rápido?"
Resposta:
"Mais ou menos."
Isso não serve.
No Mainframe tudo precisa ser medido.
Mas...
Quem garante que a medição está correta?
Esse é exatamente o papel do MSA.
No mundo IBM Z
O equivalente do MSA inclui:
SMF
RMF
OMEGAMON
IBM Z IntelliMagic
IBM Instana
Grafana
Prometheus
Z APM Connect
Todos precisam fornecer dados confiáveis.
Imagine.
Uma ferramenta informa:
CPU 95%.
Outra:
CPU 52%.
Qual está correta?
Sem confiabilidade na medição não existe gerenciamento.
Gage R&R aplicado ao Mainframe
Na indústria mede-se paquímetro.
No Mainframe mede-se observabilidade.
Por exemplo:
Tempo CICS.
Tempo DB2.
Tempo MQ.
Tempo Batch.
Latência API.
Precisamos validar:
consistência
repetibilidade
precisão
SPC
Statistical Process Control
Esta talvez seja a ferramenta mais próxima do universo dos operadores Mainframe.
Imagine acompanhar diariamente:
Quantidade de JOBs.
Tempo médio Batch.
CPU.
IOPS.
Locks DB2.
Tempo CICS.
Uso DASD.
Uso de memória.
Esses indicadores possuem comportamento normal.
Quando começam a fugir do padrão...
Algo está acontecendo.
Exemplo
Um JOB sempre executa em:
7 minutos.
Durante semanas.
Depois:
8
9
10
11
13
15 minutos.
Ainda termina.
Mas existe tendência.
SPC detecta.
O operador investiga.
Descobre:
Novo índice DB2.
Plano alterado.
RUNSTATS desatualizado.
Sem SPC isso só seria descoberto quando o batch atrasasse horas.
PPAP
Production Part Approval Process
Agora imagine o momento mais temido.
Deploy em produção.
O desenvolvedor diz:
"Funciona na homologação."
O gerente pergunta:
"Você tem evidências?"
Entra o equivalente Mainframe do PPAP.
Antes do Go Live
São revisados:
Código COBOL.
Resultados dos testes.
Testes unitários.
Testes integrados.
Performance.
Planos DB2.
EXPLAIN.
SCAN de segurança.
Revisão RACF.
Validação CICS.
JCL.
Rollback.
Documentação.
Plano de retorno.
Checklist CAB.
Aprovação do negócio.
Somente depois ocorre o deploy.
O PPAP moderno
Hoje muitas empresas automatizam esse processo.
Ferramentas:
Git
Jenkins
UrbanCode Deploy
Endevor
Changeman
ISPW
SonarQube
Zowe CLI
Ansible
Cada etapa produz evidências.
O pipeline torna-se um PPAP digital.
A relação entre os cinco
Observe como cada ferramenta depende da anterior.
Sem planejamento...
não existe análise de risco.
Sem análise de risco...
não sabemos o que medir.
Sem medição...
não sabemos controlar.
Sem controle...
não existe aprovação.
É uma cadeia.
Os Core Tools dentro do ciclo de vida do software
Imagine um projeto para modernizar um sistema COBOL de empréstimos.
Durante o planejamento (APQP), arquitetos definem requisitos, integração com APIs via z/OS Connect, impactos em DB2, VSAM e CICS, requisitos de segurança RACF e critérios de desempenho.
Na sequência, realiza-se o FMEA, identificando riscos como indisponibilidade de serviços externos, deadlocks em tabelas DB2, falhas de comunicação com IBM MQ, concorrência entre transações CICS, erros de conversão de dados e possíveis ABENDs. Para cada risco são propostas ações preventivas.
Com o projeto definido, entram em cena as práticas equivalentes ao MSA. Ferramentas como SMF, RMF, OMEGAMON, Instana e Grafana são configuradas para garantir que CPU, I/O, tempos de resposta e utilização de recursos sejam medidos de forma consistente e confiável.
Durante testes e homologação, aplica-se o conceito de SPC. A equipe monitora métricas como tempo médio de execução de jobs, consumo de CPU, quantidade de locks DB2, latência de transações CICS e volume de mensagens em filas MQ. O objetivo é identificar tendências antes que se transformem em incidentes.
Por fim, o PPAP se materializa no processo de aprovação para produção. Revisões de código, testes automatizados, análise estática, validação de planos DB2, documentação, plano de rollback, aprovação da CAB (Change Advisory Board) e conformidade com normas corporativas garantem que o software esteja apto para operar em produção com segurança.
A Qualidade como Cultura
O maior ensinamento dos Core Tools não é preencher formulários.
É desenvolver uma forma de pensar.
Um bom programador pergunta:
"Como faço isso funcionar?"
Um excelente engenheiro pergunta:
Como isso pode falhar?
Como detectarei a falha?
Como evitarei que ela ocorra novamente?
Como monitorarei esse comportamento ao longo do tempo?
Como demonstrarei, com evidências, que o sistema é confiável?
Essa mudança de mentalidade transforma desenvolvedores em arquitetos de soluções resilientes.
O que Todo COBOL Padawan Deve Levar para a Carreira
Se existe uma lição que atravessa décadas de evolução tecnológica, do COBOL ao DevOps, do batch ao cloud híbrido, é que qualidade nunca é um evento; é um processo contínuo.
Os 5 Core Quality Tools mostram que sistemas robustos não são fruto de sorte ou de programadores "geniais". Eles são resultado de planejamento disciplinado, análise de riscos, medições confiáveis, monitoramento estatístico e processos rigorosos de aprovação.
No universo IBM Mainframe, essa filosofia sempre esteve presente. É por isso que aplicações escritas há 30 ou 40 anos continuam processando milhões de transações diariamente com níveis extraordinários de disponibilidade e confiabilidade.
Ao estudar APQP, FMEA, MSA, SPC e PPAP, o COBOL Padawan percebe que essas ferramentas não pertencem apenas à indústria automotiva. Elas representam uma forma universal de construir sistemas críticos: pensar antes de programar, prevenir antes de corrigir, medir antes de decidir, controlar antes que o problema aconteça e liberar para produção apenas quando houver evidências objetivas de que o software está pronto.
No fim das contas, o maior legado da Stack IBM Mainframe talvez não seja apenas sua tecnologia, mas sua cultura de engenharia. Uma cultura em que cada linha de código, cada JCL, cada tabela DB2, cada transação CICS e cada job batch fazem parte de um ecossistema projetado para entregar confiança. E confiança, em sistemas que movimentam bilhões de reais todos os dias, é a mais valiosa das qualidades. Afinal, como costumo dizer aos novos Padawans do Mainframe:
"No IBM Z, qualidade não é um departamento. É uma característica da arquitetura, do processo e da mentalidade de quem escreve cada linha de código." ☕
