 |
| Bellacosa Mainframe analisando querys sob a otica de um QA |
☕ Um Café no Bellacosa Mainframe
Viagem ao Fundo do Banco — O Dia em que o Seaview Mergulhou no Db2 para Descobrir Quem Cobrou o Mesmo Pedido Duas Vezes
Ou: como SELECT, JOIN, GROUP BY, HAVING, Window Functions, timestamps, logs, APIs, retries, idempotência, observabilidade e um pouco de desconfiança transformam SQL de “consulta ao banco” em instrumento forense — e por que o Almirante Nelson jamais aceitaria “acho que tem dado duplicado” como relatório de missão
Imagine a cena.
O relógio marca 02:17 da madrugada.
No Centro de Processamento de Dados, alguém acabou de descobrir que clientes podem estar sendo cobrados duas vezes. O telefone do suporte toca. O monitor de produção pisca. O café da máquina já passou da classificação “bebida” para “reagente químico”.
E, estacionado metaforicamente no fundo do oceano de dados, encontra-se o Seaview, o submarino de Viagem ao Fundo do Mar.
O Almirante Nelson olha para o painel.
O Capitão Crane olha para Nelson.
Chip Morton olha para os instrumentos.
E Kowalski, que provavelmente teve a infelicidade de ficar com o plantão daquela madrugada, pergunta:
— Almirante, encontramos doze registros estranhos. Posso abrir o incidente?
Nelson responde:
— Encontrou doze registros ou descobriu o que aconteceu?
Silêncio no submarino.
E é exatamente aqui que começa nossa viagem.
Porque muita gente aprende SQL como se fosse apenas isto:
SELECT *
FROM CLIENTES;
Depois aprende:
WHERE
ORDER BY
GROUP BY
JOIN
faz algumas provas, ganha um certificado e conclui:
“Eu sei SQL.”
Mas saber SQL não é apenas conhecer sua gramática.
Da mesma maneira que conhecer COBOL não significa saber investigar um S0C7, conhecer SELECT não significa saber investigar produção.
A diferença aparece quando existe um incidente real.
E neste artigo vamos descer lentamente até o fundo desse oceano.
1. Primeiro mergulho — o chamado chegou da superfície
Nossa história começa com uma reclamação:
“Alguns clientes parecem ter sido cobrados duas vezes.”
Observe a palavra perigosa:
parecem.
Não temos ainda um bug.
Temos uma suspeita.
O primeiro erro de um investigador inexperiente é tentar provar imediatamente que sua primeira ideia está correta.
O investigador experiente faz algo diferente.
Ele transforma suspeitas em perguntas.
Por exemplo:
Existem realmente duas cobranças?
Quantos clientes foram afetados?
Quando aconteceu?
Os valores são iguais?
Os casos possuem algo em comum?
Houve deploy?
Houve timeout?
Houve retry?
A primeira cobrança já tinha sido processada quando o retry aconteceu?
Esse é o verdadeiro começo da investigação.
Não é SQL.
É pensamento investigativo.
SQL virá depois como sonar.
2. O QA Jr liga o sonar
Nosso primeiro tripulante executa:
SELECT *
FROM PEDIDOS
WHERE STATUS = 'ERROR';
Resultado:
12 linhas
E abre o ticket:
“Existem 12 pedidos com erro no banco.”
Isso está errado?
Não necessariamente.
É uma observação válida.
O problema é que ela praticamente não responde à reclamação original.
Pedidos com erro podem existir por dezenas de motivos:
endereço inválido
estoque indisponível
cartão recusado
timeout
cancelamento
erro de integração
falha de cadastro
E nenhum deles necessariamente implica cobrança duplicada.
O QA Jr encontrou peixes no oceano.
Ainda não encontrou o submarino desaparecido.
3. Um SELECT pode responder perfeitamente à pergunta errada
Esta é uma das lições mais importantes de SQL.
Imagine:
SELECT *
FROM PAGAMENTOS
WHERE STATUS = 'APROVADO';
O banco retorna:
427.816 linhas
Excelente.
Agora sabemos que existem pagamentos aprovados.
E daí?
Nada.
O fato de uma consulta retornar dados não significa que ela produziu evidência útil.
Um bom investigador aprende a perguntar:
Qual pergunta exatamente esta query está respondendo?
Se não conseguir responder em português simples, provavelmente ainda não sabe por que está executando aquela consulta.
Por exemplo:
SELECT *
FROM PAGAMENTOS
WHERE PEDIDO_ID = 9;
Agora temos uma pergunta clara:
“Quais pagamentos pertencem ao pedido 9?”
Resultado imaginário:
PAGAMENTO_ID PEDIDO_ID VALOR STATUS HORARIO
88341 9 999.99 APROVADO 14:32:08
88352 9 999.99 APROVADO 14:32:11
Interessante.
Agora temos dois pagamentos aprovados para o mesmo pedido.
O Seaview acabou de detectar algo grande no sonar.
4. O QA Pleno pergunta: isso aconteceu só uma vez?
Esta é a primeira grande mudança de mentalidade.
O iniciante normalmente encontra um caso.
O profissional mais experiente procura um padrão.
Em vez de investigar apenas o pedido 9:
SELECT
PEDIDO_ID,
COUNT(*) AS QTD
FROM PAGAMENTOS
WHERE STATUS = 'APROVADO'
GROUP BY PEDIDO_ID
HAVING COUNT(*) > 1;
Agora estamos dizendo ao banco:
“Agrupe os pagamentos por pedido e mostre apenas aqueles que possuem mais de uma ocorrência aprovada.”
E aparecem:
PEDIDO_ID QTD
9 2
17 2
28 2
31 2
...
Doze pedidos.
Agora a história mudou.
Não parece mais um registro corrompido isolado.
Existe um padrão.
Mas cuidado.
O Almirante Nelson ainda não autorizaria tocar o alarme vermelho.
5. COUNT(*) > 1 não significa automaticamente bug
Este detalhe é importantíssimo.
Imagine um pedido de R$ 1.000.
O sistema pode permitir:
Cartão A: R$ 500
Cartão B: R$ 500
Duas transações aprovadas.
Perfeitamente legítimo.
Ou pode existir:
Autorização
Captura
duas operações associadas ao mesmo pedido.
Ou:
pagamento
estorno
nova cobrança
Portanto:
HAVING COUNT(*) > 1
não significa:
“Achei o bug!”
Significa:
“Encontrei algo que merece investigação.”
Esta diferença parece pequena, mas separa SQL mecânico de SQL investigativo.
6. Descendo mais fundo: precisamos conhecer a regra de negócio
Antes de perguntar ao banco se algo está errado, precisamos saber o que significa certo.
Suponha que a regra seja:
Para cada pedido, deve existir no máximo uma captura financeira aprovada no valor total do pedido.
Agora conseguimos escrever uma consulta melhor:
SELECT
PEDIDO_ID,
COUNT(*) AS QTD_CAPTURAS,
SUM(VALOR) AS TOTAL_CAPTURADO
FROM PAGAMENTOS
WHERE STATUS = 'APROVADO'
AND TIPO = 'CAPTURE'
GROUP BY PEDIDO_ID
HAVING COUNT(*) > 1;
Essa consulta já conhece mais do negócio.
Mas ainda podemos melhorar.
7. O verdadeiro problema talvez não seja duplicidade — seja dinheiro a mais
Imagine:
Pedido = R$ 999,99
Captura 1 = R$ 999,99
Captura 2 = R$ 999,99
Se executarmos:
SUM(VALOR)
obteremos:
R$ 1.999,98
Mas o prejuízo excedente não é R$ 1.999,98.
Uma cobrança era legítima.
O excedente é:
R$ 999,99
Então uma consulta mais inteligente seria:
SELECT
P.ID AS PEDIDO_ID,
P.VALOR_TOTAL,
COUNT(PG.ID) AS QTD_CAPTURAS,
SUM(PG.VALOR) AS TOTAL_CAPTURADO,
SUM(PG.VALOR) - P.VALOR_TOTAL AS VALOR_EXCEDENTE
FROM PEDIDOS P
JOIN PAGAMENTOS PG
ON PG.PEDIDO_ID = P.ID
WHERE PG.STATUS = 'APROVADO'
AND PG.TIPO = 'CAPTURE'
GROUP BY
P.ID,
P.VALOR_TOTAL
HAVING SUM(PG.VALOR) > P.VALOR_TOTAL;
Agora a pergunta mudou novamente.
Não estamos procurando apenas:
“Quem possui dois pagamentos?”
Estamos perguntando:
“Quais pedidos receberam mais dinheiro do que deveriam?”
Isso é muito mais próximo do problema real.
8. Easter egg Bellacosa nº 1 — SQL não é VARIG, mas também exige saber para onde você está indo
Um SELECT sem pergunta bem definida lembra aquele passageiro que chega ao aeroporto e diz:
“Quero viajar.”
Excelente.
Para onde?
Um banco de produção pode conter bilhões de registros.
Você precisa de destino.
tabela
período
cliente
endpoint
status
versão
produto
transação
Caso contrário, seu maravilhoso:
SELECT *
é praticamente um bilhete de volta para o DBA perguntar por que você resolveu fazer turismo pelo tablespace inteiro às 14:30.
9. O relógio do Seaview começa a revelar o assassino
Os doze pedidos duplicados possuem outro detalhe.
Veja:
Pedido 9
14:32:08 primeira cobrança
14:32:11 segunda cobrança
Pedido 17:
14:33:24
14:33:27
Pedido 28:
14:34:01
14:34:04
Estranho.
A diferença é quase sempre três segundos.
Esse tipo de repetição é extremamente valioso.
O investigador agora pergunta:
“Existe alguma configuração do sistema que também seja de três segundos?”
Resposta:
HTTP timeout = 3 segundos
O sonar começou a apitar com vontade.
10. Window Functions — quando SQL ganha uma máquina do tempo
Aqui entram funções que assustam iniciantes:
LAG()
LEAD()
ROW_NUMBER()
RANK()
SUM() OVER()
Mas elas são maravilhosas para investigação.
Imagine:
SELECT
PEDIDO_ID,
PAGAMENTO_ID,
CRIADO_EM,
LAG(CRIADO_EM) OVER (
PARTITION BY PEDIDO_ID
ORDER BY CRIADO_EM
) AS PAGAMENTO_ANTERIOR
FROM PAGAMENTOS
WHERE STATUS = 'APROVADO';
LAG() basicamente pergunta:
“Qual era o registro anterior dentro desse grupo?”
Para cada pedido, conseguimos olhar para trás.
Algo quase digno do Seaview atravessando uma fenda temporal.
Podemos encontrar:
Pedido 9
Pagamento 1001 14:32:08
Pagamento 1002 14:32:11
E então calcular o intervalo.
Se todos os incidentes apresentam aproximadamente:
3 segundos
temos uma assinatura.
11. Mas SQL ainda não provou a causa
Aqui devemos ser cuidadosos.
Encontramos:
duas cobranças
+
intervalo de 3 segundos
+
timeout configurado em 3 segundos
Isso é uma excelente hipótese.
Mas ainda não significa:
“Provado: retry sem idempotência.”
Para provar o mecanismo, precisamos subir do fundo do banco e consultar outros instrumentos.
Logs.
Tracing.
Histórico de deploy.
Configuração.
Código.
É aqui que uma investigação realmente Sênior começa a parecer uma sala de controle.
12. Logs são a caixa-preta do submarino
Imagine o log:
14:32:08.104
POST /checkout/payment
pedido_id=9
request_id=ABC123
14:32:11.107
TIMEOUT esperando resposta
14:32:11.110
RETRY POST /checkout/payment
pedido_id=9
request_id=DEF456
E o gateway financeiro registra:
14:32:08.350
payment_authorized
transaction=TX8811
14:32:11.340
payment_authorized
transaction=TX8819
Agora conseguimos reconstruir a sequência.
Aplicação
|
| cobrança
v
Gateway
|
| aprova
|
v
Dinheiro capturado
Resposta demora
Aplicação
|
| timeout
|
| retry
v
Gateway
|
| aprova novamente
v
Segunda cobrança
O ponto decisivo é este:
timeout não significa necessariamente que a operação falhou.
Significa apenas:
“Não recebi a resposta no intervalo esperado.”
A operação remota pode ter funcionado perfeitamente.
13. Bem-vindo ao maravilhoso mundo dos sistemas distribuídos
Aqui está um conceito que programadores COBOL acostumados a processamento transacional precisam entender cada vez mais.
Imagine:
Sistema A envia mensagem para Sistema B.
Sistema B processa.
Sistema B responde.
A resposta se perde.
O Sistema A sabe que enviou.
Mas não sabe se B processou.
Então tenta novamente.
Esse é um problema clássico:
“at least once delivery”
ou seja:
a operação pode chegar mais de uma vez.
Se aquilo que será executado envolve dinheiro, estoque, emissão de nota ou alguma alteração irreversível, precisamos de proteção.
14. Entra em cena a idempotência
Uma operação idempotente pode ser repetida sem provocar efeitos adicionais depois da primeira aplicação.
Por exemplo:
PUT /cliente/123
Conteúdo:
{
"cidade": "Itatiba"
}
Executar dez vezes continua resultando em:
cidade = Itatiba
Agora compare com:
POST /cobrar
Primeira execução:
cobra R$ 999,99
Segunda execução:
cobra mais R$ 999,99
Não é exatamente o tipo de repetição que queremos.
15. A chave mágica: Idempotency-Key
Uma API pode receber:
Idempotency-Key: PEDIDO-9-PAGAMENTO
Na primeira tentativa:
chave não existe
↓
processa
↓
grava resultado
No retry:
chave já existe
↓
não processa novamente
↓
retorna resultado anterior
Podemos ainda reforçar isso no banco:
CREATE UNIQUE INDEX UX_PAYMENT_IDEMPOTENCY
ON PAGAMENTOS (IDEMPOTENCY_KEY);
Agora temos duas camadas de defesa.
Aplicação.
Banco.
Se uma falhar, a outra pode impedir o desastre.
16. O mainframe olha para isso e pergunta: “vocês descobriram integridade?”
Quem trabalha com Db2, CICS e sistemas transacionais antigos provavelmente está sorrindo.
Muitos “novos problemas da computação distribuída” têm parentes bem velhos.
Integridade.
Commit.
Rollback.
Locks.
Uniqueness.
Recovery.
Auditoria.
Exatamente as coisas que o mundo mainframe vem discutindo há décadas.
A tecnologia muda.
A física da transação continua bastante teimosa.
17. O QA Sênior pergunta quando começou
Agora encontramos doze casos.
Hora de perguntar:
“Eles sempre existiram?”
Agrupamos por horário.
Exemplo PostgreSQL:
SELECT
DATE_TRUNC('hour', CRIADO_EM) AS HORA,
COUNT(*) AS QTD
FROM PAGAMENTOS
GROUP BY DATE_TRUNC('hour', CRIADO_EM)
ORDER BY HORA;
Resultado imaginário:
10h normal
11h normal
12h normal
13h normal
14h 12 duplicidades
15h normal
Consultamos deploy:
14:21 nova versão entrou em produção
Primeira ocorrência:
14:32
O deploy entra imediatamente na lista de suspeitos.
Mas atenção.
Correlação temporal ainda não é causalidade.
18. “Depois do deploy” não significa necessariamente “por causa do deploy”
Talvez às 14:30 tenha acontecido:
degradação da rede
latência no gateway
falha no DNS
mudança de feature flag
fila congestionada
mudança de configuração
Portanto um profissional experiente escreve:
“O problema passou a ocorrer após o deploy.”
Em vez de:
“O deploy causou o problema.”
Até encontrar evidência.
Palavras importam.
Em incidentes, elas podem separar investigação de caça às bruxas.
19. Git entra no submarino
Então alguém compara o código.
E encontra:
for tentativa in range(2):
try:
return cobrar(pedido)
except Timeout:
continue
A intenção era boa.
Resiliência.
Mas existe uma pergunta fundamental:
“Podemos repetir cobrar(pedido) com segurança?”
Se não existir idempotência, o retry pode transformar uma falha de disponibilidade em problema financeiro.
E aqui aparece algo interessante.
O bug não é:
retry
O bug pode ser:
retry + operação não idempotente
Dois componentes perfeitamente razoáveis isoladamente criaram um problema juntos.
20. Causa raiz frequentemente é uma cadeia, não um ponto
Veja uma RCA mais completa:
Deploy muda uma consulta
↓
consulta fica mais lenta
↓
resposta ultrapassa 3 segundos
↓
timeout
↓
retry automático
↓
primeira chamada continua processando
↓
segunda chamada entra
↓
não existe idempotência
↓
duas capturas
Agora aparecem várias disciplinas:
SQL
performance
API
HTTP
resiliência
banco
observabilidade
arquitetura
negócio
É por isso que bugs interessantes raramente cabem dentro de uma única tecnologia.
21. Onde EXPLAIN ANALYZE entra na história?
Imagine que antes do deploy uma consulta levasse:
200 ms
Depois:
4.200 ms
E o timeout da aplicação seja:
3.000 ms
Podemos investigar o plano.
Em alguns bancos:
EXPLAIN ANALYZE
SELECT ...
Talvez encontremos:
antes:
Index Scan
depois:
Sequential Scan
ou um JOIN produzindo milhões de linhas intermediárias.
Então o aparente incidente:
“clientes cobrados duas vezes”
pode ter começado com:
“uma query perdeu um índice adequado.”
Bem-vindo à engenharia de produção.
22. Easter egg nº 2 — o monstro marinho talvez fosse um FULL TABLE SCAN
No seriado, vez ou outra surgia alguma coisa enorme pela janela do submarino.
Se Viagem ao Fundo do Mar fosse produzido dentro de um CPD, provavelmente a tripulação gritaria:
— Almirante! Há algo gigantesco vindo em nossa direção!
Nelson olharia o monitor:
TABLESPACE SCAN
2.4 bilhões de linhas
— Fechem as comportas e chamem o DBA.
23. O Sênior mede o raio de explosão
Encontrar o bug ainda não basta.
Precisamos saber:
“Quantos foram afetados?”
Suponha:
12 pedidos duplicados
Parece muito?
Pouco?
Não sabemos.
Se existiram:
4.000 pedidos no período
então:
12 / 4000 = 0,003
ou:
0,3%
Isso é o chamado blast radius.
Mas percentual sozinho também engana.
0,3% de usuários pode representar:
R$ 500
ou:
R$ 5 milhões
Por isso precisamos combinar quantidade e impacto.
24. SQL deve calcular impacto com semântica, não só matemática
Um erro muito comum é executar:
SUM(VALOR)
e chamar aquilo de prejuízo.
Nem sempre.
Imagine:
cobrança legítima R$ 100
cobrança duplicada R$ 100
SUM:
R$ 200
Impacto excedente:
R$ 100
Agora adicione:
estorno
chargeback
taxas
parcelamento
moeda
captura parcial
e ficará ainda mais delicado.
Dados financeiros exigem entendimento de negócio.
25. Window Functions são excelentes para reconstruir eventos
Vamos usar ROW_NUMBER():
SELECT
PEDIDO_ID,
PAGAMENTO_ID,
CRIADO_EM,
ROW_NUMBER() OVER (
PARTITION BY PEDIDO_ID
ORDER BY CRIADO_EM
) AS ORDEM
FROM PAGAMENTOS
WHERE STATUS = 'APROVADO';
Temos:
Pedido 9 Pagamento A ordem 1
Pedido 9 Pagamento B ordem 2
Então podemos procurar:
ORDEM > 1
Ou seja:
pagamentos posteriores ao primeiro.
Isso é bastante útil para auditoria.
26. LAG() também pode revelar estados impossíveis
Imagine uma tabela histórica de pedidos:
PEDIDO_ID
STATUS
DATA_EVENTO
Fluxo esperado:
CRIADO
↓
PAGO
↓
SEPARADO
↓
ENVIADO
Agora aparece:
CANCELADO
↓
ENVIADO
Opa.
Ou:
CANCELADO
↓
PAGO
Podemos usar funções analíticas para enxergar transições.
O SQL deixa de ser apenas fotografia.
Passa a reconstruir filme.
27. Aqui nasce outro conceito poderoso: invariantes
Uma invariante é algo que deveria permanecer verdadeiro.
Exemplo:
estoque não pode ficar negativo.
Consulta:
SELECT *
FROM ESTOQUE
WHERE QUANTIDADE < 0;
Resultado esperado:
0 linhas
Outra:
pedido cancelado não deve receber captura posterior.
SELECT
P.ID
FROM PEDIDOS P
JOIN PAGAMENTOS PG
ON PG.PEDIDO_ID = P.ID
WHERE P.STATUS = 'CANCELADO'
AND PG.STATUS = 'APROVADO'
AND PG.CRIADO_EM > P.CANCELADO_EM;
Esperado:
0 linhas
Agora SQL tornou-se uma ferramenta de validação de regras.
28. Procure também aquilo que deveria existir e não existe
LEFT JOIN é maravilhoso para isso.
Pagamentos órfãos:
SELECT PG.*
FROM PAGAMENTOS PG
LEFT JOIN PEDIDOS P
ON P.ID = PG.PEDIDO_ID
WHERE P.ID IS NULL;
Tradução:
“Mostre pagamentos cujo pedido correspondente não existe.”
Pedidos sem pagamento:
SELECT P.*
FROM PEDIDOS P
LEFT JOIN PAGAMENTOS PG
ON PG.PEDIDO_ID = P.ID
WHERE PG.ID IS NULL;
Isso muda a pergunta.
Você não procura apenas dados estranhos.
Procura ausências estranhas.
29. Cardinalidade: o recife onde muita query naufraga
Existe um problema traiçoeiro.
Suponha:
Pedido
├── 2 pagamentos
└── 5 itens
Faça:
PEDIDOS
JOIN PAGAMENTOS
JOIN ITENS
Pode resultar em:
2 × 5 = 10 linhas
Então você executa:
SUM(PAGAMENTOS.VALOR)
e multiplica dinheiro sem perceber.
Parabéns.
Você acaba de descobrir uma nova modalidade de inflação.
😄
Por isso é fundamental conhecer cardinalidade:
1:1
1:N
N:N
Antes de agregar.
Muitas vezes devemos agregar previamente:
WITH PAGAMENTOS_AGG AS (
SELECT
PEDIDO_ID,
SUM(VALOR) AS TOTAL
FROM PAGAMENTOS
GROUP BY PEDIDO_ID
)
SELECT ...
Isso evita explosões causadas pelos JOINs.
30. Uma query pode estar sintaticamente perfeita e semanticamente errada
Este é um conceito que vale guardar.
O banco pode dizer:
SQLCODE = 0
E você ainda assim estar completamente errado.
O SQL executou.
A pergunta estava errada.
No Db2, Oracle, PostgreSQL ou qualquer outro banco, sucesso de execução não significa sucesso de raciocínio.
Um resultado pode ser:
matematicamente correto
e:
conceitualmente inútil
ao mesmo tempo.
31. O QA Sênior procura características discriminantes
Suponha que os doze casos tenham algo em comum:
endpoint = /checkout/payment
Ótimo.
Vamos verificar outro atributo.
gateway = XPTO
Todos os doze.
Outro:
versão = 4.12.7
Todos.
Outro:
retry_count = 1
Todos.
Agora reduzimos enormemente o espaço de busca.
Começamos:
4.000 pedidos
Depois:
12 duplicados
Depois:
1 endpoint
Depois:
1 gateway
Depois:
1 versão
Depois:
retry
Depois:
sem idempotency key
Esse é um método poderoso.
Você está fechando o cerco.
32. Mas agora vem a pergunta que separa investigação de confirmação de viés
Se todos os bugs têm retry, talvez retry seja a causa.
Certo?
Calma.
Pergunte:
Quantos retries ocorreram sem duplicidade?
Isso é importantíssimo.
Imagine:
40.000 retries
12 duplicidades
Então retry sozinho claramente não explica tudo.
Talvez a condição seja:
retry
+
versão X
+
endpoint Y
+
gateway Z
+
ausência de idempotência
O investigador bom não procura somente evidência que confirma sua hipótese.
Ele procura evidência capaz de destruí-la.
Isso é ciência aplicada.
33. Uma curiosidade: correlação pode nos enganar lindamente
Imagine que todos os doze clientes afetados usam Chrome.
Ticket:
“Bug ocorre no Chrome.”
Então alguém consulta a população normal:
98% dos clientes usam Chrome.
Bem...
O Chrome acabou de deixar de ser um suspeito particularmente interessante.
Esse tipo de comparação é essencial.
Pergunte não apenas:
“Os casos ruins possuem X?”
Pergunte também:
“Quantos casos bons possuem X?”
34. O passo a passo de uma investigação madura
Em vez de decorar cinquenta comandos, pense assim.
Comece confirmando existência.
Depois quantifique.
Depois encontre período.
Depois segmente.
Depois procure diferenças entre casos afetados e normais.
Depois correlacione com deploy, configuração e eventos externos.
Depois use logs e tracing para reconstruir sequência.
Depois verifique código.
Depois tente reproduzir.
Depois calcule impacto.
Por fim, valide a correção e crie defesa contra recorrência.
Este é o ciclo completo.
35. O ticket muda completamente
Um ticket inicial pode dizer:
“Há pedidos duplicados.”
Um melhor:
“Encontramos 12 pedidos com duas capturas aprovadas entre 14:32 e 14:57.”
Um ticket realmente útil:
Entre 14:32 e 14:57 foram identificados 12 pedidos com duas capturas financeiras aprovadas, correspondendo a 0,3% dos pedidos do período e R$ 12.430 de cobrança excedente. Todos foram processados pelo endpoint /checkout/payment após o deploy X. As segundas chamadas ocorreram aproximadamente três segundos após as primeiras, valor compatível com o timeout configurado. Os logs mostram retry após timeout enquanto a primeira captura já havia sido concluída pelo gateway. As requisições não apresentavam mecanismo de idempotência. O comportamento foi reproduzido em ambiente controlado.
Isto já não é:
“Tem algo estranho.”
É praticamente um relatório de investigação.
36. Mas nem o Sênior deveria escrever “provei sozinho com SQL”
Esse é um detalhe importante.
SQL é excelente para provar:
existência
quantidade
padrão
período
impacto
Mas causa raiz frequentemente exige:
logs
traces
configuração
código
deploy
reprodução
Portanto, em vez de:
“SQL provou que retry causou o problema.”
Melhor:
“SQL demonstrou o padrão e o impacto; logs e tracing demonstraram o mecanismo de retry; código e reprodução confirmaram a ausência de idempotência.”
Muito mais preciso.
37. O melhor investigador mantém humildade epistemológica
Palavra grande.
Ideia simples.
Não diga:
“Tenho certeza porque minha query voltou 12 linhas.”
Diga:
“Os dados atualmente sustentam esta hipótese.”
Isso permite que uma nova evidência mude sua conclusão.
Produção adora humilhar excesso de confiança.
Ela tem talento para isso.
38. SQL investigativo também precisa respeitar produção
Aqui entra outra lição essencial.
Você está investigando um incidente.
Não deve criar outro.
Evite executar sem necessidade:
SELECT *
FROM PAGAMENTOS;
sobre bilhões de linhas.
Prefira filtros:
WHERE CRIADO_EM BETWEEN ...
Escolha colunas.
Conheça índices.
Use ambiente read-only quando disponível.
Tenha cuidado com dados pessoais.
E nunca confunda:
investigar
com:
“já que estou aqui vou dar um UPDATE rapidinho...”
É assim que nasce a segunda temporada do incidente.
39. No mainframe, RACF estaria observando
Em um ambiente z/OS bem administrado, acesso não deveria significar:
“Faça qualquer coisa.”
Existem permissões.
Auditoria.
Perfis.
Separação de funções.
O equivalente moderno continua sendo:
least privilege
read-only
audit trail
mascaramento
roles
timeouts
resource limits
Um QA não precisa necessariamente possuir poderes para alterar produção.
Ele precisa de visibilidade suficiente para investigar com segurança.
40. Timestamps — as correntes marítimas invisíveis
Outro assassino de investigações:
timezone
Imagine:
Banco: America/Sao_Paulo
API: UTC
Observabilidade: UTC
Deploy: horário local
Banco:
14:32
Log:
17:32
Alguém conclui:
“Não corresponde.”
Mas é o mesmo instante.
Por isso qualquer investigação temporal deve entender:
timezone
precisão
sincronização de relógio
formato
Caso contrário você pode passar três horas procurando um fantasma.
41. Consistência também importa
Banco de produção está vivo.
Você roda:
SELECT COUNT(*)
Às 14:00:00.
Depois:
SELECT SUM(VALOR)
Às 14:01:00.
Enquanto isso, milhares de transações aconteceram.
Talvez você esteja comparando dois universos diferentes.
Dependendo do banco e da investigação, conceitos como:
READ COMMITTED
REPEATABLE READ
SNAPSHOT
MVCC
podem importar.
Até um SELECT tem contexto transacional.
42. Do SQL para Db2 for z/OS
Agora chegamos ao nosso CPD.
Um programador COBOL pode encontrar algo muito parecido em Db2.
Por exemplo:
SELECT PEDIDO_ID,
COUNT(*) AS QTD
FROM PAGAMENTO
WHERE STATUS = 'A'
GROUP BY PEDIDO_ID
HAVING COUNT(*) > 1;
Nada conceitualmente diferente.
Você pode executar consultas por ferramentas autorizadas como SPUFI ou outras interfaces corporativas.
Depois correlacionar com:
CICS
Db2
MQ
JES
SMF
logs da aplicação
APIs
Imagine um programa COBOL/CICS emitindo uma solicitação.
Depois MQ entrega.
Depois uma API externa processa.
Depois ocorre timeout.
Depois há nova mensagem.
Você pode ter criado no século XXI um problema cuja solução exige disciplina transacional conhecida desde os dinossauros do CPD.
43. Easter egg nº 3 — o Seaview encontrou um SQLCODE
Alarmes.
Luzes vermelhas.
Kowalski:
— Capitão! SQLCODE negativo!
Crane:
— Qual?
— -811, senhor!
Nelson entra correndo.
— Então a query que esperava uma linha encontrou várias. Finalmente o banco resolveu colaborar com a investigação.
Quem trabalha com Db2 conhece o drama.
Uma aplicação espera unicidade.
O banco entrega duas linhas.
De repente uma regra implícita se materializa em erro.
Às vezes o bug esteve ali durante anos, esperando os dados certos para aparecer.
44. O SQL da investigação pode virar teste
Isto é belíssimo.
Você encontra o incidente com:
SELECT PEDIDO_ID
FROM PAGAMENTOS
WHERE STATUS = 'APROVADO'
GROUP BY PEDIDO_ID
HAVING COUNT(*) > 1;
Depois da correção, essa mesma consulta pode se tornar parte de uma validação.
Esperado:
0 rows
Teste:
envia requisição
simula timeout
executa retry
Nova consulta:
0 rows
Excelente.
O incidente se tornou teste de regressão.
45. Melhor ainda: a query pode virar monitoramento
Agora execute periodicamente uma consulta equivalente.
Se:
resultado = 0
normal.
Se:
resultado > 0
alerta.
O fluxo mudou de:
cliente reclama
↓
investigamos
para:
sistema detecta
↓
investigamos antes de dezenas de clientes reclamarem
Isso é evolução operacional.
46. Sanity check pós-deploy
Antes do deploy você conhece certos números normais:
duplicidades = 0
erros = 0,02%
aprovação = 98,7%
pedidos órfãos = 0
Depois do deploy executa verificações equivalentes.
Se aparece:
erro = 4,8%
não espere o telefone tocar.
Esta é uma aplicação prática excelente de SQL para QA.
SQL deixa de ser apenas “consulta durante defeito”.
Vira instrumento de observabilidade.
47. Migrations também merecem investigação
Imagine:
ALTER TABLE PEDIDOS
ADD COLUMN STATUS_V2 VARCHAR(20);
QA iniciante verifica:
“A coluna existe.”
Bom começo.
QA mais maduro verifica:
SELECT COUNT(*)
FROM PEDIDOS
WHERE STATUS_V2 IS NULL;
Depois:
SELECT
STATUS,
STATUS_V2,
COUNT(*)
FROM PEDIDOS
GROUP BY STATUS, STATUS_V2;
Agora estamos verificando:
estrutura
+
conteúdo
+
coerência
Uma migration pode funcionar tecnicamente e falhar semanticamente.
48. Jr, Pleno e Sênior não são comandos SQL diferentes
Existe uma caricatura comum:
Jr sabe SELECT
Pleno sabe JOIN
Sênior sabe Window Function
Não.
Um Jr pode dominar Window Functions.
Um Sênior pode solucionar um incidente inteiro usando:
COUNT(*)
A diferença é mais interessante.
O Jr pergunta:
“O que existe?”
O Pleno pergunta:
“Que padrão existe?”
O Sênior pergunta:
“Que mecanismo produziria exatamente esse padrão e como posso provar que minha hipótese está errada?”
Isto é maturidade investigativa.
49. E depois do Sênior existe outra pergunta
Imagine alguém no nível Staff, Principal ou arquitetura.
Ele olha para toda a investigação e pergunta:
“Por que nosso sistema permitiu que isso acontecesse?”
Não:
“Quem escreveu esse retry?”
Mas:
Por que uma API financeira não exigia idempotência?
Por que o banco permitia a duplicidade?
Por que não havia alerta?
Por que não existia teste de timeout?
Por que o gateway não possuía reconciliação?
Por que o deploy não tinha sanity check?
Por que demoramos para detectar?
Agora estamos corrigindo o sistema, não apenas o código.
50. Defesa em profundidade — ou quantas comportas possui o Seaview?
Uma arquitetura madura pode colocar várias barreiras:
cliente
↓
idempotency key
↓
API
↓
controle de duplicidade
↓
serviço
↓
regra de negócio
↓
banco
↓
unique constraint
↓
gateway
↓
reconciliação
↓
monitoramento
Se uma proteção falhar, outra ainda pode ajudar.
É a mesma filosofia de compartimentos estanques de um submarino.
Uma seção pode sofrer danos sem afundar a embarcação inteira.
51. O verdadeiro papel do SQL
Depois de toda esta viagem, chegamos ao fundo do oceano.
SQL não é apenas:
SELECT
INSERT
UPDATE
DELETE
Para um investigador, SQL permite perguntar:
Onde a realidade deixou de obedecer ao modelo que construímos?
Uma query de QA pode dizer:
mostre pedidos impossíveis
mostre transições inválidas
mostre valores inconsistentes
mostre relacionamentos quebrados
mostre duplicidades
mostre ausências
mostre anomalias temporais
Isso é extraordinariamente poderoso.
52. Uma regra Bellacosa para levar para casa
Antes de executar uma consulta durante um incidente, pergunte:
“Que hipótese estou tentando testar?”
Depois da consulta:
“Este resultado poderia ter outra explicação?”
Depois de encontrar um padrão:
“Os casos normais também possuem esse padrão?”
Depois de encontrar correlação:
“Consigo demonstrar o mecanismo?”
Depois de encontrar a causa:
“Como impedimos que volte?”
Se você incorporar apenas isso à sua maneira de trabalhar, seu SQL ficará muito melhor sem aprender um único comando novo.
Epílogo — Emergindo do fundo do banco
O Seaview finalmente volta à superfície.
Missão concluída.
No relatório inicial havia:
“Acho que tem cobrança duplicada.”
No relatório final temos:
12 pedidos afetados
0,3% da população do período
R$ 12.430 de cobrança excedente
mesmo endpoint
mesmo intervalo
mesma versão
segunda requisição ~3 segundos depois
timeout configurado em 3 segundos
retry confirmado pelos logs
primeira captura já havia sido concluída
ausência de idempotência
problema reproduzido
correção aplicada
constraint adicionada
teste de regressão criado
monitoramento implementado
Almirante Nelson fecha a pasta.
Crane pergunta:
— Então SQL resolveu o caso?
Nelson olha pela janela do submarino.
— Não. SQL nos mostrou onde procurar e quanto dano havia. Logs mostraram a sequência. Tracing mostrou o caminho. Código explicou o mecanismo. O teste provou que conseguimos reproduzir. E a arquitetura nos ensinou por que aquilo jamais deveria ter sido permitido.
No fundo da sala alguém executa:
SELECT COUNT(*)
FROM PAGAMENTOS_DUPLICADOS;
Resultado:
0
Nelson sorri.
Até que Kowalski aparece correndo:
— Almirante...
— O que foi agora?
— Encontramos um pedido cancelado que foi enviado três horas depois.
Nelson olha para Crane.
Crane olha para o café.
O Seaview começa a mergulhar novamente.
Porque em produção, meu caro programador COBOL, todo fundo do mar possui outro fundo logo abaixo.
E talvez essa seja a verdadeira lição da nossa viagem:
o profissional iniciante usa SQL para encontrar registros; o profissional experiente usa SQL para testar hipóteses; o profissional Sênior combina dados, logs, arquitetura e conhecimento de negócio até transformar suspeita em evidência.
Não é o SELECT complicado que encerra o caso.
É a pergunta certa.
E, como diria qualquer veterano do CPD diante de um incidente às duas da madrugada:
antes de culpar o programa, consulte os dados. Antes de culpar os dados, confira o JOIN. Antes de culpar o JOIN, olhe o timestamp. E antes de executar um UPDATE em produção... chame o DBA.
☕ Um Café no Bellacosa Mainframe
Onde às vezes descemos ao fundo do oceano apenas para descobrir que o monstro marinho era um retry de três segundos sem Idempotency-Key.
