 |
| Bellacosa Mainframe e a engenharia de qualidade sem misterios para a Stack Mainframe |
☕ Um Café no Bellacosa Mainframe
Quality Engineering sem Mistérios
O Guia Definitivo do Programador COBOL Padawan para Entender a Engenharia da Qualidade Aplicada ao IBM Z — Inspirado em Star Trek
"Em qualquer missão da Frota Estelar, sobreviver não depende apenas de tecnologia. Depende de processos bem definidos, verificações constantes e disciplina operacional."
— Adaptado da filosofia do Sr. Spock
Introdução — O que um Programador COBOL tem a ver com Engenharia da Qualidade?
Quando um programador COBOL iniciante escuta palavras como FMEA, PPAP, MSA, SPC, CAPA ou APQP, normalmente pensa:
"Isso deve ser coisa do pessoal da fábrica..."
Na verdade...
Não.
Esses conceitos nasceram na manufatura, principalmente na indústria automobilística japonesa e americana, mas seus princípios são praticamente universais.
Na IBM, por exemplo, boa parte da cultura de engenharia que permitiu que o IBM System/360, depois o System/370, o zSeries, o IBM Z e atualmente o IBM z16/z17 alcançassem níveis absurdos de disponibilidade foi construída exatamente sobre esses fundamentos.
Aliás...
Existe uma curiosidade interessante.
A indústria automotiva mede defeitos em peças.
O mundo mainframe mede defeitos em informações.
Ambos perseguem exatamente o mesmo objetivo:
Zero defeito.
No universo de Star Trek isso fica ainda mais evidente.
Imagine a USS Enterprise.
Ela possui:
motores
computadores
sensores
bancos de dados
replicadores
sistemas médicos
controle de voo
Agora imagine se cada módulo fosse desenvolvido sem controle de qualidade.
A Enterprise nunca sairia do estaleiro de Utopia Planitia.
No IBM Z acontece exatamente a mesma coisa.
Engenharia da Qualidade não é encontrar erros
Este é um dos maiores equívocos dos iniciantes.
Muita gente acredita que qualidade significa:
"Encontrar bugs."
Na verdade...
Encontrar bugs é apenas uma pequena parte.
A Engenharia da Qualidade tenta impedir que o bug exista.
Essa filosofia pode ser resumida assim:
Inspecionar
↓
Encontrar defeitos
Prevenir
↓
Eliminar defeitos antes que apareçam
É exatamente a diferença entre apagar incêndios e construir um prédio que não pega fogo.
A Jornada Completa da Qualidade
No mundo automotivo existe praticamente uma sequência lógica.
Planejamento
↓
Projeto
↓
Análise de Riscos
↓
Plano de Controle
↓
Validação
↓
Produção
↓
Monitoramento
↓
Correção
↓
Melhoria Contínua
Curiosamente...
Essa sequência lembra muito o ciclo de desenvolvimento de um sistema COBOL.
Levantamento
↓
Análise
↓
Codificação
↓
Compilação
↓
Teste
↓
Homologação
↓
Produção
↓
Monitoramento
↓
Correções
Nada mudou.
Mudou apenas o produto.
APQP — O Planejamento da Missão
Imagine o Capitão Kirk recebendo uma nova missão.
Spock pergunta:
Capitão... já sabemos os riscos?
McCoy pergunta:
O suporte médico foi planejado?
Scotty pergunta:
Os motores suportam essa missão?
Uhura pergunta:
As comunicações foram testadas?
Todos estão fazendo APQP.
O que significa?
Advanced Product Quality Planning.
É um planejamento extremamente detalhado.
Seu objetivo é garantir que o produto nascerá corretamente.
No mundo mainframe seria equivalente ao momento em que uma nova aplicação bancária começa.
Antes da primeira linha de COBOL já precisamos definir:
requisitos
banco de dados
segurança RACF
interfaces MQ
jobs
SLAs
backups
monitoramento
capacidade
rollback
Perceba...
Nenhuma linha de código foi escrita.
Mesmo assim boa parte do sucesso do projeto já foi decidida.
FMEA — O Dr. Spock prevê o futuro
Esta talvez seja minha ferramenta favorita.
Failure Mode and Effects Analysis.
Traduzindo:
Análise dos Modos de Falha.
Ela faz uma pergunta simples:
O que pode dar errado?
Depois:
Qual será o impacto?
Depois:
Como impedir?
Imagine um programa COBOL.
READ CLIENTE
IF NOT FOUND
O que pode acontecer?
Arquivo vazio.
Dataset inexistente.
Erro de autorização.
Registro inválido.
VSAM corrompido.
Todas essas possibilidades deveriam aparecer no FMEA.
No universo Star Trek...
Spock faria exatamente isso antes da missão começar.
Exemplo Mainframe
Programa realiza TED bancária.
Possíveis falhas:
Saldo insuficiente.
Abend S0C7.
Deadlock DB2.
Timeout CICS.
Fila MQ cheia.
Sistema remoto indisponível.
Agora imagine cada um deles recebendo:
Severidade.
Probabilidade.
Facilidade de detecção.
Esse é exatamente o FMEA.
SPC — O RMF da Indústria
SPC significa Statistical Process Control.
Aqui entra estatística.
Imagine acompanhar diariamente:
CPU
↓
Tempo de resposta
↓
IOPS
↓
Uso de DASD
↓
Quantidade de ABENDs
↓
Tempo de Batch
Tudo isso pode ser colocado em gráficos.
É exatamente isso que o SPC faz.
No mundo industrial mede:
temperatura
pressão
espessura
diâmetro
peso
No IBM Z mede:
CPU
Paging
EXCP
Response Time
Storage
Buffer Pools
Locks
Tudo baseado em estatística.
Easter Egg
RMF é praticamente um gigantesco SPC para sistemas operacionais.
MSA — Posso confiar na minha medição?
Imagine dois operadores.
Um diz:
CPU = 60%
Outro diz:
CPU = 85%
Quem está certo?
Antes de confiar no número...
Precisamos confiar na ferramenta.
MSA faz exatamente isso.
No mundo industrial analisa:
paquímetro
micrômetro
scanner
laser
No mainframe seria equivalente a validar:
RMF
SMF
OMEGAMON
Grafana
Instana
Zabbix
Se a ferramenta mede errado...
Todas as decisões seguintes estarão erradas.
QA x QC
Essa pergunta aparece praticamente em todas as entrevistas.
QA
Quality Assurance.
Garante o processo.
QC
Quality Control.
Verifica o produto.
Imagine uma compilação COBOL.
QA seria:
Padronizar coding standards.
Checklist.
Code Review.
Pipeline.
Testes obrigatórios.
QC seria:
Executar o programa.
Validar saída.
Comparar resultados.
Encontrar erros.
QA evita.
QC detecta.
PPAP — A Homologação Definitiva
Imagine entregar um novo sistema para produção.
O gerente pergunta:
Você testou?
Sim.
Documentou?
Sim.
Backup?
Sim.
Rollback?
Sim.
Plano B?
Sim.
Plano C?
Sim.
Aprovação?
Sim.
Esse "pacote de confiança" é praticamente um PPAP.
Na indústria significa provar que a linha inteira consegue fabricar corretamente.
No mainframe seria provar que:
o sistema inteiro está pronto para produção.
Control Plan
Depois que tudo foi planejado...
Como garantir que ninguém saia do padrão?
Control Plan responde isso.
No desenvolvimento COBOL poderia conter:
Toda alteração passa por Git.
↓
Build automático.
↓
Compilação Enterprise COBOL.
↓
Testes ZUnit.
↓
Code Review.
↓
Deploy via DBB.
↓
Homologação.
↓
Produção.
Tudo documentado.
CAPA
Corrective and Preventive Action.
Imagine ocorreu um ABEND S0C4.
Correção:
ajustar ponteiro.
Prevenção:
criar regra de inspeção para ponteiros.
Outro exemplo.
Deadlock DB2.
Correção:
alterar ordem dos UPDATE.
Prevenção:
documentar padrão corporativo.
Perceba.
A prevenção vale muito mais.
Root Cause Analysis
A pergunta mais importante da engenharia.
Por quê?
Imagine:
Programa caiu.
Por quê?
Arquivo indisponível.
Por quê?
Storage cheio.
Por quê?
Job anterior não apagou temporários.
Por quê?
PROC estava errada.
Agora encontramos a verdadeira causa.
Não era o COBOL.
Era o processo.
Os famosos 5 Porquês
Toyota popularizou essa técnica.
Pergunte cinco vezes:
Por quê?
Até chegar na raiz.
No mundo mainframe isso resolve inúmeros incidentes.
8D — A Investigação da Frota Estelar
Imagine um incidente gravíssimo.
Sistema bancário parado.
Kirk convoca uma força-tarefa.
Cada disciplina representa uma etapa.
D1
Equipe.
D2
Problema.
D3
Conter.
D4
Descobrir causa.
D5
Corrigir.
D6
Validar.
D7
Evitar repetição.
D8
Registrar aprendizado.
É praticamente um Post Mortem moderno.
Poka-Yoke — O Idiot Proof
Talvez o conceito japonês mais genial.
Impedir o erro antes que aconteça.
No COBOL:
Obrigar CPF com 11 dígitos.
Obrigar DATA AAAAMMDD.
Obrigar código de agência válido.
Obrigar commit antes do término.
Tudo isso é Poka-Yoke.
Kaizen — O Espírito Vulcano
Kaizen significa:
Melhoria contínua.
Todos os dias.
Pouco.
Mas sempre.
No IBM Z isso significa:
Melhor SQL.
Menor consumo de CPU.
Menos EXCP.
Menos SORT.
Mais cache.
Mais paralelismo.
Nenhuma mudança isolada faz milagre.
Mil pequenas melhorias mudam uma organização inteira.
Process Flow Diagram
É literalmente desenhar o processo.
No COBOL:
Cliente
↓
Tela CICS
↓
Programa COBOL
↓
DB2
↓
MQ
↓
Sistema Externo
↓
Resposta
↓
Tela
Quanto melhor o diagrama...
Mais fácil identificar gargalos.
Cp e Cpk
São indicadores estatísticos.
Na indústria medem:
Capacidade do processo.
No IBM Z poderiam representar:
Capacidade de throughput.
Capacidade do Batch.
Capacidade do CICS.
Capacidade do DB2.
Embora não sejam usados formalmente dessa forma, a filosofia é semelhante.
GD&T
Geometric Dimensioning and Tolerancing.
Pode parecer distante do COBOL.
Mas existe uma analogia.
Na indústria define tolerâncias.
No software definimos:
Layout Copybook.
Formato JSON.
API Contract.
Record Layout.
Todos precisam seguir exatamente o padrão.
5S no Mainframe
Seiri
Eliminar datasets inúteis.
Seiton
Organizar bibliotecas.
Seiso
Eliminar jobs antigos.
Seiketsu
Padronizar nomenclaturas.
Shitsuke
Disciplina operacional.
O ISPF agradece.
OEE
Overall Equipment Effectiveness.
Na indústria mede:
Disponibilidade
Performance
Qualidade
No IBM Z seria algo como:
Disponibilidade do Sysplex.
Performance do Batch.
Qualidade dos serviços.
LPA
Layered Process Audit.
Imagine auditorias periódicas.
Operador.
Supervisor.
Gerente.
Arquiteto.
Todos verificam o mesmo processo sob perspectivas diferentes.
QMS
Quality Management System.
É o "sistema operacional" da qualidade.
No IBM seria equivalente ao conjunto de:
ITIL
COBIT
ISO 9001
Políticas internas
Procedimentos
Fluxos
Normas
IATF 16949
É a principal norma automotiva.
Ela integra praticamente tudo o que vimos.
Pode ser comparada, conceitualmente, a grandes frameworks de governança utilizados em ambientes corporativos de TI, onde processos, auditorias, gestão de riscos e melhoria contínua precisam funcionar de forma integrada.
Como tudo isso conversa com o IBM Z?
A maior lição deste artigo é perceber que o IBM Z sempre foi uma plataforma orientada à qualidade.
Quando você utiliza:
RACF
WLM
RMF
SMF
JES2
GDGs
DB2
CICS
IMS
ZUnit
Git
DBB
Ansible
Jenkins
você está, na prática, aplicando muitos dos mesmos princípios da Engenharia da Qualidade: prevenção, padronização, rastreabilidade, medição, auditoria e melhoria contínua.
A tecnologia muda, mas os fundamentos permanecem.
Curiosidades para impressionar em uma entrevista
☕ A Toyota foi uma das grandes responsáveis por popularizar FMEA, 5S, Kaizen, Poka-Yoke e os 5 Porquês, influenciando metodologias de qualidade em diversos setores.
☕ O conceito de melhoria contínua inspirou práticas modernas como Lean Manufacturing, Lean Software Development e parte da cultura DevOps.
☕ O ciclo Planejar → Executar → Medir → Corrigir aparece em praticamente todas as áreas da engenharia, da manufatura ao desenvolvimento de software.
☕ Em ambientes IBM Z, métricas provenientes de RMF, SMF e ferramentas de observabilidade cumprem papel semelhante ao SPC, permitindo identificar tendências antes que se transformem em incidentes.
☕ O famoso Post Mortem adotado por empresas como Google, Microsoft e IBM segue princípios muito próximos do RCA (Root Cause Analysis) e do método 8D: entender profundamente a causa raiz, implementar ações corretivas permanentes e compartilhar o aprendizado para evitar recorrências.
O Conselho Final do Sr. Spock
Ao terminar sua conversa com o capitão Kirk, Spock olha para um jovem engenheiro recém-chegado à Enterprise e diz:
"Um excelente engenheiro não é aquele que resolve problemas rapidamente. É aquele que projeta sistemas onde os problemas raramente acontecem."
Essa frase resume toda a Engenharia da Qualidade.
Seja em uma linha de montagem produzindo milhões de componentes automotivos ou em um IBM Z processando bilhões de transações financeiras, o verdadeiro objetivo nunca foi apenas corrigir defeitos. O objetivo é construir processos tão robustos, previsíveis e bem controlados que a qualidade deixe de ser uma inspeção no final do caminho e passe a fazer parte da própria essência do sistema.
E essa é uma lição que todo Programador COBOL Padawan leva consigo ao iniciar sua jornada rumo ao nível de Mestre. Afinal, como diria Spock:
"A lógica constrói sistemas. A qualidade garante que eles permaneçam funcionando quando toda a galáxia depende deles."
