 |
| Bellacosa Mainframe e tecnica do why-why analysis |
☕ Um Café no Bellacosa Mainframe
Why-Why Analysis sem Mistérios
O Guia do Programador COBOL Padawan para Encontrar a Causa Raiz antes que o ABEND Ataque Novamente
Há uma cena que se repete diariamente nos corredores digitais de muitas empresas.
Um job termina com ABEND S0C7.
O operador abre o chamado.
O programador examina o SYSOUT.
Encontra um campo numérico contendo caracteres inválidos.
Corrige o registro, reinicia o processamento e anuncia:
“Problema resolvido.”
A ponte de comando comemora. O batch volta a navegar. O SLA é preservado. O café continua quente.
Três dias depois, o mesmo erro acontece novamente.
Outro registro inválido. Outro S0C7. Outro restart. Outro chamado. Outra madrugada perdida.
Nesse momento, o programador COBOL Padawan começa a perceber uma verdade desconfortável:
O erro foi corrigido, mas o problema não foi resolvido.
É justamente nesse ponto que entra a Why-Why Analysis, também conhecida como 5 Whys, Five Whys, Análise dos Cinco Porquês ou simplesmente Análise Por Quê–Por Quê.
Trata-se de uma técnica aparentemente simples: diante de um problema, perguntamos repetidamente “por quê?” até encontrar a causa fundamental que permitiu que aquele evento acontecesse.
Mas não se engane.
A técnica não consiste em repetir “por quê?” como uma criança curiosa até alguém perder a paciência. Ela é uma disciplina de investigação, pensamento lógico, observação, análise de evidências e melhoria contínua.
No universo Bellacosa Mainframe, podemos compará-la ao trabalho de um oficial científico da Frota Estelar: não basta saber que o sistema perdeu potência. É necessário descobrir qual componente falhou, por que falhou, que condição permitiu a falha e o que deve ser modificado para que a nave não fique à deriva novamente.
Prepare o café, ajuste o terminal 3270 e venha para a sala de diagnóstico. Nossa missão é viajar além do sintoma e alcançar a verdadeira causa raiz.
1. O que é a Why-Why Analysis?
A Why-Why Analysis é uma técnica de análise de causa raiz, ou Root Cause Analysis — RCA, utilizada para investigar problemas, falhas, defeitos, atrasos, interrupções e resultados indesejados.
Seu funcionamento básico pode ser representado assim:
Problema observado
↓
Por que aconteceu?
↓
Causa imediata
↓
Por que essa causa existia?
↓
Causa intermediária
↓
Por que o processo permitiu isso?
↓
Causa sistêmica
↓
Contramedida
O método parte do princípio de que aquilo que enxergamos inicialmente costuma ser apenas a manifestação visível de algo mais profundo.
Um ABEND é uma manifestação.
Uma transação lenta é uma manifestação.
Um arquivo não catalogado é uma manifestação.
Uma reclamação de cliente é uma manifestação.
Um job atrasado é uma manifestação.
Uma falha de deploy é uma manifestação.
A pergunta correta não é apenas:
“O que aconteceu?”
Também precisamos perguntar:
“Por que o sistema permitiu que isso acontecesse?”
Essa segunda pergunta nos leva do território dos sintomas para o território dos processos.
2. A origem da técnica na Toyota
A técnica dos Cinco Porquês está associada a Sakichi Toyoda, inventor, industrial japonês e fundador do grupo que daria origem à Toyota.
Posteriormente, a abordagem foi incorporada e popularizada no Toyota Production System, especialmente por nomes como Taiichi Ohno, um dos principais arquitetos do sistema de produção da empresa.
A lógica era poderosa: quando uma máquina parava, o objetivo não era apenas colocá-la novamente em funcionamento. Era necessário compreender por que ela havia parado e impedir que a mesma falha voltasse a ocorrer.
Taiichi Ohno defendia que, ao repetir a pergunta “por quê?” algumas vezes, a natureza do problema e sua solução poderiam se tornar mais claras.
A técnica passou a caminhar ao lado de conceitos como:
Com o tempo, sua aplicação atravessou os portões das fábricas.
Hoje, a Why-Why Analysis pode ser aplicada em:
desenvolvimento de software;
operação de data centers;
mainframes;
DevOps;
segurança da informação;
atendimento ao cliente;
logística;
engenharia;
saúde;
projetos;
gestão da qualidade;
processos administrativos;
análise de incidentes.
O chão de fábrica tornou-se também o chão digital.
A máquina industrial pode ser um servidor.
A linha de produção pode ser um pipeline CI/CD.
O defeito em uma peça pode ser um bug em um programa COBOL.
A parada de produção pode ser uma indisponibilidade em CICS.
Os princípios permanecem os mesmos.
3. Por que são cinco porquês?
O nome “Cinco Porquês” pode causar uma interpretação equivocada: a ideia de que obrigatoriamente devemos fazer exatamente cinco perguntas.
Isso não é verdade.
Em alguns casos, três perguntas serão suficientes.
Em outros, poderemos precisar de seis, sete ou dez.
O número cinco funciona como uma referência prática. Em muitos problemas, aproximadamente cinco níveis de investigação conseguem atravessar as causas superficiais e alcançar um ponto em que uma ação sistêmica pode ser implementada.
Portanto, a regra correta é:
Pergunte “por quê?” quantas vezes forem necessárias para chegar a uma causa que possa ser controlada, corrigida e comprovada.
Não pare no quinto porquê apenas porque o formulário terminou.
Também não continue indefinidamente até chegar a respostas filosóficas como:
“Porque os seres humanos criaram computadores.”
A investigação precisa terminar em uma causa relevante para o processo analisado.
4. Sintoma, problema, causa e causa raiz
Um dos principais desafios da análise é separar quatro conceitos diferentes.
Sintoma
É a manifestação percebida.
Exemplos:
Problema
É a descrição objetiva do evento indesejado.
Exemplo:
O job FATUR001 terminou com S0C7 às 02h17, durante o processamento do arquivo CLIENTES.DIARIO, no registro 47.321.
Quanto mais precisa for a definição, melhor será a investigação.
Causa imediata
É aquilo que diretamente provocou o evento.
Exemplo:
Um campo definido como numérico continha o valor “12A45”.
Causa raiz
É a condição fundamental que permitiu que a causa imediata existisse.
Exemplo:
A aplicação não possui validação de dados na entrada, e o processo de integração permite que arquivos fora do layout cheguem ao programa de faturamento.
A diferença é gigantesca.
A causa imediata explica o erro.
A causa raiz explica a recorrência.
5. Contramedida não é o mesmo que correção
Em Lean, costuma-se usar a palavra contramedida.
A correção trata o problema presente.
A contramedida reduz ou elimina a possibilidade de repetição.
Considere este cenário:
Problema: programa terminou com S0C7.
Correção: alterar manualmente o registro inválido.
Contramedida: validar o arquivo antes do processamento e rejeitar registros incompatíveis com o layout.
A correção permite continuar.
A contramedida transforma o processo.
Outro exemplo:
Problema: job não encontrou a LOADLIB.
Correção: incluir a biblioteca manualmente na STEPLIB.
Contramedida: corrigir a PROC catalogada e estabelecer controle de versão para o JCL.
Reiniciar um serviço não é necessariamente uma contramedida.
Aumentar memória não é necessariamente uma contramedida.
Pedir para alguém “tomar mais cuidado” quase nunca é uma contramedida.
Uma boa contramedida atua sobre o processo, o sistema, o padrão, o treinamento, a automação ou os controles.
6. O passo a passo da Why-Why Analysis
Vamos montar uma sequência digna de um procedimento operacional da Frota Estelar.
Passo 1 — Defina o problema com precisão
Evite descrições vagas:
O sistema está ruim.
O batch está lento.
O CICS travou.
O usuário fez algo errado.
Prefira descrições mensuráveis:
O job PGTO010 aumentou seu tempo de execução de 35 minutos para 2 horas e 48 minutos após a mudança de 14 de julho.
Uma boa descrição deve responder:
o que aconteceu;
quando aconteceu;
onde aconteceu;
qual componente foi afetado;
qual era o comportamento esperado;
qual foi o comportamento observado;
qual foi o impacto.
Passo 2 — Vá ao Gemba digital
No Lean, Gemba significa o lugar real onde o trabalho acontece.
Em uma fábrica, é a linha de produção.
No mainframe, o Gemba pode ser:
SDSF;
JESMSGLG;
JESJCL;
JESYSMSG;
SYSLOG;
dump;
IPCS;
RMF;
SMF;
CICS trace;
Db2 accounting trace;
EXPLAIN;
log do pipeline;
histórico do scheduler;
mensagens de console;
spool do job.
Não investigue apenas por telefone.
Não aceite somente:
“Disseram que o sistema caiu.”
Vá até a evidência.
O mainframe possui uma memória operacional extraordinária. Muitos eventos deixam rastros em logs, mensagens, registros SMF, dumps e relatórios.
O programador que aprende a ler esses rastros deixa de ser apenas um codificador e começa a se tornar um investigador de sistemas.
Passo 3 — Pergunte o primeiro porquê
A resposta deve estar baseada em evidência.
Problema:
O job terminou com S0C7.
Por quê?
Porque uma instrução aritmética tentou processar um campo com conteúdo inválido.
Essa resposta deve ser sustentada por informações como:
Passo 4 — Transforme a resposta na próxima pergunta
Agora pergunte:
Por que o campo continha conteúdo inválido?
Resposta:
Porque o arquivo de entrada trouxe caracteres alfabéticos em uma posição definida como numérica.
Próxima pergunta:
Por que o arquivo trouxe caracteres alfabéticos nessa posição?
Resposta:
Porque o sistema fornecedor alterou o layout sem atualizar o copybook utilizado pelo programa consumidor.
Próxima pergunta:
Por que a alteração de layout não atualizou o copybook?
Resposta:
Porque os dois sistemas não possuem um processo integrado de gestão e versionamento de contratos de dados.
Agora estamos muito além do S0C7.
Chegamos a uma falha de governança.
Passo 5 — Verifique a cadeia lógica
Cada resposta precisa explicar diretamente a pergunta anterior.
A cadeia deve fazer sentido de baixo para cima.
Podemos usar a chamada lógica do “portanto”:
Não existe gestão de versão do layout.
Portanto, o copybook do consumidor ficou desatualizado.
Portanto, o programa interpretou os dados incorretamente.
Portanto, um campo alfanumérico chegou a uma operação numérica.
Portanto, ocorreu S0C7.
Quando a cadeia é coerente nos dois sentidos, a análise ganha força.
Caso existam saltos lógicos, suposições ou generalizações, precisamos investigar mais.
Passo 6 — Identifique o ponto de prevenção
Uma boa causa raiz normalmente aponta para um ponto onde a recorrência pode ser evitada.
Pergunte:
O que podemos modificar para impedir que essa cadeia se repita?
Possíveis ações:
versionar copybooks;
validar arquivos;
criar testes de contrato;
automatizar comparação de layouts;
exigir aprovação formal para mudanças;
incluir verificação no pipeline;
gerar documentação compartilhada;
notificar sistemas consumidores.
A melhor solução pode combinar várias ações.
Passo 7 — Defina responsável, prazo e evidência de sucesso
Uma análise sem plano de ação vira decoração de reunião.
Toda contramedida precisa de:
responsável;
prazo;
prioridade;
critério de conclusão;
forma de validação;
acompanhamento.
Exemplo:
Ação: implementar validação automática do layout antes do processamento.
Responsável: equipe de integração.
Prazo: 30 dias.
Critério de sucesso: 100% dos arquivos incompatíveis rejeitados antes da execução do programa COBOL.
Monitoramento: relatório diário e alerta automático.
Passo 8 — Monitore a recorrência
Depois da mudança, acompanhe:
o problema voltou?
surgiu outro efeito?
o tempo de processamento melhorou?
a taxa de falhas caiu?
a equipe está seguindo o novo padrão?
a automação está funcionando?
a documentação foi atualizada?
A melhoria só é confirmada quando os resultados demonstram que a causa foi controlada.
7. Exemplo completo: ABEND S0C7 em COBOL
Vamos entrar em uma investigação completa.
Problema
O programa COBOL FATU120 terminou com ABEND S0C7 durante o processamento noturno.
Primeiro porquê
Por que ocorreu S0C7?
Porque o programa tentou somar um campo com conteúdo não numérico.
Segundo porquê
Por que o campo continha valor não numérico?
Porque o campo VALOR-PARCELA recebeu espaços e letras.
Terceiro porquê
Por que o programa recebeu espaços e letras em um campo esperado como numérico?
Porque o arquivo de entrada foi gerado com um layout diferente do copybook utilizado.
Quarto porquê
Por que o layout do arquivo estava diferente?
Porque o sistema de origem alterou o tamanho e o formato do campo sem comunicar formalmente os consumidores.
Quinto porquê
Por que não houve comunicação formal?
Porque não existe processo corporativo de controle de versão, aprovação e distribuição dos contratos de arquivos.
Causa raiz
Ausência de governança sobre layouts compartilhados.
Correção imediata
Corrigir o registro e reprocessar o job.
Contramedidas
criar repositório central de copybooks;
versionar layouts;
implementar testes de contrato;
validar comprimento e formato do arquivo;
estabelecer processo de aprovação;
incluir consumidores na revisão de mudanças;
adicionar tratamento de dados inválidos no COBOL.
Observe como a investigação saiu de uma instrução aritmética e terminou em governança de integração.
Essa é a força do método.
8. Exemplo: batch lento no Db2
Problema
O job de faturamento passou de 40 minutos para quatro horas.
Por quê 1
Porque uma consulta SQL passou a consumir muito mais tempo.
Por quê 2
Porque o Db2 escolheu um access path com table space scan.
Por quê 3
Porque as estatísticas das tabelas estavam desatualizadas.
Por quê 4
Porque a rotina de RUNSTATS não executou após uma grande carga de dados.
Por quê 5
Porque o processo de carga não possui dependência automática para atualização de estatísticas.
Causa raiz
O fluxo operacional não associa grandes cargas de dados à manutenção das estatísticas necessárias ao otimizador.
Contramedidas
executar RUNSTATS após cargas significativas;
revisar o REBIND;
monitorar mudanças de access path;
criar alertas de cardinalidade;
integrar manutenção ao scheduler;
avaliar índices e distribuição dos dados.
A solução superficial seria “criar um índice”.
Mas talvez o índice já exista.
Talvez o verdadeiro problema seja o processo que deixou o otimizador trabalhando com uma visão antiga dos dados.
9. Exemplo: transação CICS lenta
Problema
A transação PAG1 passou a responder em 18 segundos.
Por quê 1
Porque uma chamada a um serviço externo demorava 15 segundos.
Por quê 2
Porque a fila MQ acumulou milhares de mensagens.
Por quê 3
Porque uma instância consumidora estava parada.
Por quê 4
Porque o processo Java terminou por falta de memória.
Por quê 5
Porque uma atualização introduziu um vazamento de memória não detectado nos testes.
Por quê 6
Porque os testes não incluíam execução prolongada com carga semelhante à produção.
Causa raiz
Ausência de testes de resistência e observação de consumo de memória no pipeline.
Contramedidas
teste de carga prolongado;
análise de heap;
alertas de crescimento de memória;
rollback automático;
limite de backlog da fila;
monitoramento ponta a ponta.
A transação CICS era a vítima visível.
A causa real estava muito longe dela.
10. O erro de culpar pessoas
Uma das regras mais importantes da Why-Why Analysis é:
Analise o processo, não ataque a pessoa.
Uma resposta como:
“O operador errou.”
raramente representa uma boa causa raiz.
Precisamos continuar:
Por que o operador errou?
Talvez:
o procedimento estivesse desatualizado;
a tela fosse confusa;
não existisse validação;
o treinamento fosse insuficiente;
duas opções tivessem nomes semelhantes;
o sistema permitisse uma ação perigosa sem confirmação;
a equipe estivesse sobrecarregada;
a documentação não estivesse disponível.
Chamar tudo de “erro humano” é frequentemente uma maneira elegante de encerrar a investigação cedo demais.
Pessoas cometem erros.
Sistemas maduros são projetados para:
A pergunta não deve ser apenas:
“Quem fez?”
Mas:
“Que condição tornou esse erro possível?”
Essa mudança de mentalidade fortalece a cultura de aprendizado e evita a caça aos culpados.
11. Quando a análise se transforma em árvore
Nem todo problema possui uma única linha causal.
Algumas falhas resultam da combinação de vários fatores.
Exemplo:
Job atrasou
├── volume de dados aumentou
├── CPU ficou limitada
├── SQL perdeu índice
└── execução iniciou fora da janela
Nesse caso, a análise pode se ramificar.
Para cada ramo, perguntamos novos porquês.
A Why-Why pode então trabalhar em conjunto com:
O método é excelente, mas não deve ser usado como martelo universal.
Quando o problema envolve múltiplas causas independentes, uma linha única de cinco perguntas pode simplificar demais a realidade.
12. Integração com Ishikawa
O Diagrama de Ishikawa, conhecido como espinha de peixe, ajuda a levantar categorias de possíveis causas.
Categorias comuns incluem:
método;
máquina;
mão de obra;
material;
medição;
meio ambiente.
Em tecnologia, podemos adaptar:
aplicação;
infraestrutura;
dados;
processo;
pessoas;
segurança;
dependências;
monitoramento.
O Ishikawa ajuda a encontrar áreas de investigação.
Os Cinco Porquês ajudam a aprofundar cada área.
Exemplo:
Categoria: Dados
Problema: S0C7
Por quê? Campo inválido.
Por quê? Layout incompatível.
Por quê? Copybook desatualizado.
Por quê? Mudança não comunicada.
Por quê? Ausência de governança.
As duas ferramentas se complementam muito bem.
13. Relação com PDCA
A análise dos porquês se encaixa perfeitamente no ciclo PDCA.
Plan
Definir o problema, coletar evidências e encontrar a causa raiz.
Do
Implementar a contramedida.
Check
Verificar se o resultado melhorou e se o problema deixou de ocorrer.
Act
Padronizar a solução ou revisar a hipótese caso o problema continue.
A etapa “Check” é frequentemente esquecida.
Uma equipe implementa a mudança e considera o assunto encerrado.
Mas sem medir o resultado, não sabemos se a causa estava correta.
14. Relação com DMAIC e Six Sigma
Dentro do Six Sigma, o método pode ser utilizado principalmente na fase Analyze do DMAIC.
Define
Qual é o problema?
Measure
Qual é sua frequência, impacto e comportamento?
Analyze
Quais causas explicam o problema?
Improve
Quais mudanças eliminam ou reduzem as causas?
Control
Como garantir que a melhoria seja sustentada?
A Why-Why Analysis ajuda a estruturar hipóteses, mas em problemas complexos deve ser apoiada por dados estatísticos e testes.
Perguntar por quê não substitui medir.
15. Dicas práticas para uma boa análise
Não aceite respostas vagas
Evite:
falta de atenção;
problema no sistema;
erro de comunicação;
falha operacional;
problema de performance.
Pergunte:
qual sistema?
qual falha?
que comunicação?
em qual etapa?
qual métrica?
qual evidência?
Não transforme opinião em fato
“Acho que foi a rede” não é conclusão.
É hipótese.
Precisamos de:
tempos de resposta;
logs;
traces;
pacotes perdidos;
métricas;
comparação histórica.
Não pule etapas
É tentador sair de:
“O job falhou”
diretamente para:
“Precisamos trocar a ferramenta.”
Essa conclusão pode não ter nenhuma ligação comprovada com o evento.
A cadeia precisa ser construída passo a passo.
Não confunda correlação com causalidade
Dois eventos acontecerem juntos não significa que um causou o outro.
Exemplo:
O job ficou lento depois da instalação de uma nova versão.
A versão pode ser a causa.
Mas também pode ter ocorrido:
Investigue.
Faça a análise em equipe
Inclua pessoas que conhecem diferentes partes do fluxo:
programador;
operador;
DBA;
analista de produção;
sysprog;
segurança;
infraestrutura;
negócio;
suporte.
Sistemas corporativos são cadeias complexas. Raramente uma única pessoa enxerga tudo.
Registre as evidências
Uma boa análise deve indicar:
Isso evita que a conclusão seja apenas uma opinião coletiva.
16. Um modelo simples para usar
PROBLEMA:
Descreva o evento com data, hora, sistema, impacto e comportamento esperado.
POR QUÊ 1:
Pergunta:
Resposta:
Evidência:
POR QUÊ 2:
Pergunta:
Resposta:
Evidência:
POR QUÊ 3:
Pergunta:
Resposta:
Evidência:
POR QUÊ 4:
Pergunta:
Resposta:
Evidência:
POR QUÊ 5:
Pergunta:
Resposta:
Evidência:
CAUSA RAIZ:
Condição sistêmica comprovada que permitiu o problema.
CORREÇÃO IMEDIATA:
Ação para restaurar o serviço.
CONTRAMEDIDA:
Ação para evitar recorrência.
RESPONSÁVEL:
Nome ou equipe.
PRAZO:
Data prevista.
VALIDAÇÃO:
Métrica que demonstrará a eficácia.
Esse modelo pode ser usado em uma planilha, wiki, ferramenta ITSM, documento de incidente ou post-mortem.
17. Curiosidades da sala de máquinas
A primeira curiosidade é que os Cinco Porquês não precisam produzir uma única resposta correta e absoluta. Em investigações reais, diferentes equipes podem construir cadeias diferentes. O importante é validar cada elo com evidências.
A segunda é que uma causa raiz pode estar fora do componente que apresentou o erro. Um programa COBOL pode falhar por uma alteração feita em uma aplicação distribuída, em um arquivo, em uma regra de negócio ou em um processo manual.
A terceira é que problemas recorrentes são frequentemente sinais de que a organização está tratando sintomas. Quando o mesmo incidente aparece repetidamente com pequenas variações, vale procurar uma causa sistêmica comum.
A quarta é que uma boa análise costuma revelar oportunidades maiores do que o incidente original. Ao investigar um arquivo inválido, podemos descobrir falhas de governança, testes, comunicação e automação.
A quinta é que a pergunta “por quê?” deve ser feita com curiosidade, não com acusação. O tom muda tudo.
Compare:
“Por que você fez isso?”
com:
“Que condições do processo levaram a esse resultado?”
A segunda pergunta abre portas.
A primeira ergue escudos.
18. Easter egg: o incidente da USS Enterprise-Z
Imagine uma nave híbrida: metade USS Enterprise, metade IBM Z.
No centro da sala de máquinas existe um z17 processando transações interplanetárias em COBOL.
De repente, o alerta vermelho é acionado.
IEF450I STARJOB STEP010 - ABEND=S0C7
O Capitão Kirk pergunta:
— Sr. Spock, por que o sistema de navegação financeira caiu?
Spock responde:
— Porque uma rotina aritmética processou um campo não numérico.
Kirk respira aliviado:
— Então corrija o campo.
Spock ergue uma sobrancelha:
— Isso restauraria o processamento, Capitão, mas não explicaria a origem do dado inválido.
O primeiro porquê revela o campo.
O segundo revela o arquivo.
O terceiro revela o copybook.
O quarto revela uma mudança não comunicada.
O quinto revela que a Federação não possui governança para contratos de dados entre planetas.
Scotty entra correndo:
— Capitão, posso fazer o job rodar em vinte minutos!
Spock responde:
— E ele falhará novamente na próxima remessa de carga de Vulcano.
A solução definitiva inclui:
Kirk então compreende:
Reiniciar a nave é manutenção.
Eliminar a causa da falha é engenharia.
No canto da tela, escondido entre os registros do spool, aparece o easter egg:
01 LOGICA-VULCANA PIC X(20)
VALUE 'VIDA-LONGA-E-SEM-S0C7'.
19. Quando não usar apenas os Cinco Porquês
A técnica pode ser insuficiente quando:
existem diversas causas simultâneas;
o problema é altamente probabilístico;
há forte interação entre componentes;
a falha envolve segurança crítica;
os dados são contraditórios;
o evento nunca havia ocorrido;
a cadeia causal é extensa;
há fatores humanos, tecnológicos e organizacionais combinados.
Nessas situações, combine o método com ferramentas mais robustas.
Em incidentes graves, use também:
O objetivo não é preencher cinco caixas.
O objetivo é aprender a verdade operacional do sistema.
20. Conclusão: não pare no primeiro “por quê”
O programador iniciante olha para o ABEND.
O programador experiente olha para os dados.
O analista sênior olha para o fluxo.
O arquiteto olha para o sistema.
O verdadeiro resolvedor de problemas olha para as condições que permitiram a falha.
A Why-Why Analysis ensina exatamente essa evolução.
Ela nos convida a sair do modo reativo:
Falhou → corrigir → reiniciar → esquecer.
E migrar para um modo de melhoria contínua:
Falhou
↓
observar
↓
investigar
↓
comprovar
↓
corrigir
↓
prevenir
↓
monitorar
↓
aprender
No ambiente mainframe, onde milhões de transações dependem de processos maduros, confiáveis e repetíveis, essa mentalidade é especialmente valiosa.
Não basta fazer o job voltar.
É preciso compreender por que ele parou.
Não basta corrigir o registro.
É preciso descobrir por que o registro chegou inválido.
Não basta culpar o operador.
É preciso entender por que o processo permitiu o engano.
Não basta apagar o incêndio.
É preciso descobrir quem deixou combustível perto do reator de dobra.
A pergunta “por quê?” parece pequena, mas abre portas gigantescas.
Cada porquê remove uma camada de aparência.
Cada resposta bem comprovada aproxima a equipe da verdade.
Cada causa raiz eliminada torna o sistema mais robusto.
Portanto, na próxima vez que um programa COBOL terminar com ABEND, não se limite à primeira mensagem do spool.
Abra o dump.
Consulte o SYSOUT.
Converse com as equipes.
Verifique os fatos.
Siga a cadeia lógica.
Pergunte novamente.
E novamente.
Até que o sintoma deixe de ser o centro da investigação e o processo revele aquilo que realmente precisa ser transformado.
Como diria o oficial científico da Bellacosa Enterprise:
“Uma correção que não elimina a recorrência é apenas um adiamento logicamente organizado do próximo incidente.”
Vida longa ao COBOL, ao IBM Z e aos programadores que nunca se contentam com o primeiro porquê.
