 |
| Bellacosa Mainframe e root cause analysis |
☕💣🚨 PADAWAN, O PROBLEMA NÃO ESTÁ ONDE O ABEND ACONTECEU!
Executando Root Cause Analysis (RCA) em Ambiente Mainframe
Como Encontrar a Verdadeira Causa do Incidente e Não Apenas o Sintoma
Uma das maiores armadilhas no mundo Mainframe é acreditar que o erro está exatamente onde ele apareceu.
O operador vê um S0C7.
O desenvolvedor vê um SQLCODE -911.
O analista vê um JOB FAILED.
O gerente vê um SLA perdido.
Mas o verdadeiro culpado pode estar escondido horas, dias ou até semanas antes do incidente.
É exatamente para isso que existe a Root Cause Analysis (RCA).
O Que é Root Cause Analysis?
Root Cause Analysis é um processo estruturado utilizado para descobrir:
O que aconteceu
Por que aconteceu
Como aconteceu
Como impedir que aconteça novamente
O objetivo NÃO é:
❌ Encontrar culpados
O objetivo é:
✅ Encontrar causas
Existe uma enorme diferença entre:
Sintoma
e
Causa Raiz
Exemplo:
Sintoma:
JOB ABC123 ABEND S0C7
Causa raiz:
Arquivo recebido com campo numérico inválido
Sem RCA você corrige o programa.
Com RCA você corrige o processo.
O Modelo Bellacosa de RCA
Costumo ensinar que a investigação deve seguir 5 perguntas:
1. O que falhou?
2. Onde falhou?
3. Quando começou?
4. O que mudou?
5. Qual evento iniciou a cadeia?
A quinta pergunta normalmente encontra a causa raiz.
Caso Real Simulado
Imagine o seguinte cenário:
Às 03:15 da manhã:
JOB FINPAY01
ABEND S0C7
Sistema financeiro parado.
Pagamento não processado.
Telefone do plantão toca.
Você entra na guerra.
Passo 1 – Não Entre em Pânico
Primeiro erro dos iniciantes:
ABEND → Corrigir programa
Errado.
Primeiro precisamos coletar evidências.
Passo 2 – Capturar Informações Básicas
Anote:
Job Name
Step Name
Programa
Hora
Sistema
Código de retorno
Exemplo:
JOB:
FINPAY01
STEP:
CALCPAY
PROGRAMA:
PAYROLL
ABEND:
S0C7
HORA:
03:15
Agora temos o ponto inicial.
Passo 3 – Analisar JESMSGLG
Abrir:
SDSF
ST
?
Verificar:
JESMSGLG
Perguntas:
Houve mensagens antes do abend?
Dataset estava disponível?
Houve timeout?
Houve atraso?
Exemplo:
RECORD READ SUCCESSFULLY
Logo antes do erro:
INVALID DATA DETECTED
Primeira pista encontrada.
Passo 4 – Analisar SYSOUT
Agora olhamos:
SYSOUT
SYSPRINT
SYSUDUMP
CEEDUMP
Dependendo da aplicação.
Encontramos:
FIELD SALARY
VALUE = ABC123
O campo deveria ser numérico.
Passo 5 – Confirmar no Dump
No dump:
OFFSET X'03A2'
Instrução:
PACK
O programa tentou converter:
ABC123
para número.
Resultado:
S0C7
Até aqui temos:
O QUE aconteceu
Mas ainda não temos:
POR QUE aconteceu
Erro Comum da Equipe
Muitas equipes param aqui.
Produzem um relatório:
Causa:
Campo inválido.
Isso NÃO é RCA.
Isso é apenas descrição do sintoma.
Passo 6 – Rastrear a Origem do Dado
Pergunta:
Quem criou esse registro?
Abrimos o fluxo.
FINPAY01
↓
FINLOAD
↓
FTPIN
↓
Arquivo Externo
Agora começamos a enxergar a cadeia de eventos.
Passo 7 – Reconstruir a Linha do Tempo
Uma RCA boa sempre monta uma timeline.
01:00 Arquivo recebido
01:05 FTP concluído
01:10 Processo de carga
03:15 Abende S0C7
Agora investigamos:
O que mudou entre ontem e hoje?
Passo 8 – Procurar Mudanças
A pergunta mais poderosa da RCA:
O que mudou?
90% dos incidentes começam aqui.
Verificamos:
Mudança de software
Novo fornecedor
Nova versão
Alteração de layout
Mudança de parâmetro
Descobrimos:
Fornecedor alterou layout do arquivo
Ontem:
SALARY PIC 9(8)
Hoje:
SALARY PIC X(8)
E começou a enviar:
ABC123
Finalmente Encontramos a Causa Raiz
Sintoma:
S0C7
Causa imediata:
Campo não numérico
Causa raiz:
Mudança de layout
não comunicada
pelo fornecedor
Agora sim temos RCA.
Técnica dos 5 Porquês
Muito utilizada em bancos e seguradoras.
Pergunte repetidamente:
Por que houve S0C7?
Porque havia valor inválido.
Por que havia valor inválido?
Porque o campo veio alfanumérico.
Por que veio alfanumérico?
Porque o layout mudou.
Por que o layout mudou?
Porque fornecedor implantou nova versão.
Por que ninguém percebeu?
Porque não existia validação de layout.
Causa raiz:
Ausência de validação contratual
do arquivo recebido
Observe:
Não era COBOL.
Não era Mainframe.
Não era operador.
Era falha de processo.
Técnica do Diagrama de Ishikawa
Também chamado:
Fishbone Diagram
Categorias comuns:
Pessoas
Processos
Tecnologia
Dados
Infraestrutura
Mudanças
Exemplo:
S0C7
│
├── Dados
│ └ Campo inválido
│
├── Processo
│ └ Sem validação
│
├── Mudança
│ └ Layout alterado
│
└── Governança
└ Sem comunicação
Esse modelo é excelente para incidentes complexos.
RCA em Problemas de Performance
Outro exemplo.
Sintoma:
Batch passou de
20 minutos para 4 horas
Investigação:
CPU normal
Memória normal
I/O elevado
Descoberta:
Índice DB2 ficou REORG pendente
Sintoma:
Batch lento
Causa raiz:
Janela de manutenção não executada
Novamente:
A causa raiz não era o batch.
RCA em Problemas de CICS
Sintoma:
AICA
Timeout.
Investigação:
CICS esperando DB2
DB2 esperando:
Lock
Lock causado por:
Batch noturno
Batch preso por:
Dataset indisponível
Causa raiz:
Dataset não montado
O AICA era apenas o último dominó da cadeia.
Estrutura de um Relatório RCA Profissional
INCIDENTE:
Batch FINPAY01 falhou.
IMPACTO:
Pagamento não processado.
SINTOMA:
ABEND S0C7.
CAUSA IMEDIATA:
Campo SALARY inválido.
CAUSA RAIZ:
Fornecedor alterou layout sem aviso.
AÇÃO CORRETIVA:
Correção do layout.
AÇÃO PREVENTIVA:
Validação automática de arquivo.
RESPONSÁVEL:
Equipe de Integração.
PRAZO:
15 dias.
O Segredo dos Grandes Especialistas Mainframe
Os profissionais mais experientes não são aqueles que sabem mais comandos.
São aqueles que conseguem responder:
Por que isso aconteceu?
Porque o verdadeiro trabalho de um especialista não é apagar incêndios.
É descobrir quem acendeu o fósforo.
Quando você domina RCA, deixa de ser apenas alguém que resolve abends e passa a ser alguém que elimina problemas da raiz, reduz incidentes recorrentes e se torna uma das pessoas mais valiosas dentro da operação Mainframe.
E é exatamente nesse momento que você deixa de ser um simples operador de mensagens e passa a pensar como um verdadeiro detetive de sistemas IBM Z. ☕🚀🔎
