dbt em produção: 12 testes que evitam incidentes (com critérios de severidade)
Por que testes em produção falham na vida real
Em produção, incidentes raramente acontecem porque “o SQL quebrou”. O que quebra dashboards de verdade é qualidade mínima não atendida:
- chaves que viram nulas
- duplicidade que infla métricas
- relacionamento que deixa de bater
- valores fora do domínio do negócio
- datas fora do intervalo esperado
- fatos sem dimensões e dimensões sem fatos
O dbt já nasce com testes genéricos que cobrem boa parte do básico (not_null, unique, accepted_values, relationships).
A diferença entre um projeto que “tem testes” e um projeto que “evita incidentes” está em 3 decisões:
- Definir qualidade mínima por camada (staging, core, mart)
- Definir severidade (o que quebra pipeline e o que apenas alerta)
- Controlar ruído para não criar alert fatigue
Padrão de qualidade mínima por camada
Camada 1: staging (entrada limpa e consistente)
Objetivo: garantir que o dado está utilizável e que você não está propagando sujeira.
Aqui, foque em integridade de campos, domínios e chaves técnicas.
Camada 2: core (modelagem confiável)
Objetivo: garantir que o dado está coerente com o modelo, com chaves estáveis e relacionamentos corretos.
Aqui, relationships e unique são fundamentais para evitar duplicidades e quebras de joins.
Camada 3: mart (métrica pronta para consumo)
Objetivo: garantir que dashboards não quebrem e que as métricas não “mintam” por falhas simples.
Aqui, entram testes de regra de negócio e testes de distribuição/anomalia com bom senso.
Severidade em produção: quando falhar pipeline vs apenas alertar
No dbt, a severidade de testes normalmente é tratada como error (falha) ou warn (alerta). E você pode configurar como lidar com warnings, inclusive promovendo warnings a erro dependendo do processo.
Uma forma prática de mapear P0, P1, P2
P0 (quebra pipeline)
Falhas que deixam o dado inutilizável ou geram risco alto de decisão errada em massa.
Exemplos: chave primária nula, duplicidade em chave de fato, relationship quebrado para dimensão crítica.
P1 (alerta forte, não quebra por padrão)
Falhas que degradam qualidade, mas não invalidam todo o dataset.
Exemplos: accepted_values estourando em 1 a 2 por cento das linhas, atraso de freshness, outliers moderados.
P2 (monitoramento silencioso ou digest diário)
Sinais fracos, ruído controlado, coisas que você quer ver em tendência.
Exemplos: pequenas variações, campos auxiliares fora do padrão, regras experimentais.
Regra de ouro para evitar alert fatigue: só gere alerta imediato para P0 e P1 que afetam colunas críticas. O resto vira relatório periódico.
As 12 verificações que mais evitam incidentes em dashboards
Abaixo, um conjunto enxuto e realmente útil. Os quatro primeiros são “genéricos dbt”. Os demais são padrões de regra de negócio e confiabilidade operacional.
1) not_null em chaves críticas (P0)
Use em ids, datas chave e colunas necessárias para join e agregação.
Onde: staging (campos de origem), core (chaves do modelo), mart (campos que sustentam métrica).
2) unique na chave do grão correto (P0)
Evita duplicidade silenciosa que infla KPIs.
Aplicar unique na coluna errada é pior do que não aplicar. Valide primeiro qual é o grão.
3) relationships para integridade referencial (P0 ou P1)
Garante que fatos apontem para dimensões existentes.
Em marts, relationship quebrado em dimensão crítica costuma ser P0.
4) accepted_values em colunas categóricas (P1)
Perfeito para status, tipo, canal, país, moeda.
Em dados de origem instáveis, comece como P2 e promova a P1 quando estabilizar.
5) intervalos válidos para datas e números (P0 ou P1)
Exemplos:
- datas no futuro em eventos históricos
- valores negativos em receita
- quantidade absurda em pedidos
Esse teste não vem “pronto” como genérico padrão, mas é simples de fazer como teste singular SQL.
6) monotonicidade ou consistência de datas de atualização (P1)
Exemplo: updated_at não pode ser menor que created_at.
Esse tipo de regra evita regressões em pipelines incrementais.
7) grão do fato consistente (P0)
Exemplo: tabela de pedidos deve ter 1 linha por pedido_id.
Mesmo que você não use unique direto, valide grão com contagens e agrupamentos.
8) completeness mínima por período (P1)
Exemplo: “todo dia deve ter pelo menos X registros” ou “não pode zerar do nada”.
Isso evita dashboards vazios por falha de carga.
9) regra de negócio de soma e coerência (P1)
Exemplos:
- total = subtotal + frete − desconto
- imposto não pode ser maior que total
- margem deve estar entre limites plausíveis
10) consistência entre tabelas (P1)
Exemplo: número de pedidos no mart deve bater com fatos filtrados no core dentro de uma tolerância.
11) testes em colunas críticas priorizadas (estratégia, não um teste)
Você não precisa testar tudo. Você precisa testar o que quebra decisão.
Escolha um conjunto pequeno de colunas críticas por domínio e eleve severidade nelas.
12) store_failures para investigação rápida (operacional)
Quando um teste falha, você quer ver linhas problemáticas sem reconstruir tudo manualmente. O dbt permite armazenar falhas de teste quando executado com store_failures.
Como evitar alert fatigue sem reduzir qualidade
Alert fatigue aparece quando você cria muitos alertas de baixa utilidade e o time para de reagir. O antídoto é governança simples:
- Comece por 5 a 10 tabelas críticas
Dashboards principais e métricas que mexem com decisão. - Escolha colunas críticas por tabela
Chaves, datas, status, valores financeiros, colunas usadas em filtros de dashboard. - Poucos alertas, bem roteados
P0 quebra pipeline e abre incidente
P1 alerta em canal visível, mas sem travar entrega
P2 entra em digest diário ou semanal - Rotina de ajuste de falsos positivos
Todo teste novo pode gerar ruído no começo. Trate como rollout gradual.
Rollout gradual: como colocar testes em produção sem dor
Fase 1: base mínima
Implemente not_null, unique e relationships nas tabelas críticas.
Seja agressivo em P0 apenas onde a quebra é real.
Fase 2: domínio e regras de negócio
Adicione accepted_values e regras específicas.
Aqui, comece com severidade mais baixa para medir falsos positivos.
Fase 3: operacionalização
Ative store_failures para testes críticos e garanta rastreabilidade de incidentes.
Reavalie mensalmente: quais testes salvaram você de incidentes e quais só fazem barulho.
Checklist final para produção
- Qualidade mínima definida por camada (staging, core, mart)
- P0, P1, P2 definidos com base em impacto de negócio
- Colunas críticas priorizadas
- Warnings tratados com política clara no pipeline
- Falhas investigáveis com store_failures em testes críticos
Conclusão
dbt em produção não é sobre ter muitos testes. É sobre ter os testes certos, com severidade certa, nas colunas certas, para evitar incidentes que quebram dashboards e confiança.
Se você aplicar esse padrão de 12 verificações com rollout gradual e controle de ruído, você sai do modo “apagar incêndio” e entra no modo “qualidade mínima garantida”.
