Perdemos integração entre sistemas que alimenta meu BI
Resposta rápida
Pipeline quebrada que alimenta BI exige resposta em três frentes paralelas. Primeiro, comunique imediatamente aos consumidores dos dashboards: avisar que os dados não estão atualizados é mais importante do que ainda não saber a causa — usuários consumindo dado desatualizado sem saber tomam decisões erradas confiantes. Coloque aviso visível nos dashboards. Segundo, diagnostique em camadas: API do sistema fonte (responde? mudou contrato?), ETL ou ferramenta de pipeline (rodou? falhou silenciosamente?), schema (campo renomeado, tipo alterado, tabela removida?), credenciais (token expirado, senha mudada, permissão revogada?). Cada camada tem sinal próprio. Terceiro, restaure com cautela: corrigir o sintoma sem entender a causa garante reincidência em dias. Após estabilizar, RCA cobre por que a falha não foi detectada antes e como melhorar observabilidade da pipeline.
Na empresa pequena, "pipeline" muitas vezes é integração via ferramenta de no-code (Zapier, Make) ou exportação programada de planilha. Diagnóstico costuma ser rápido — poucos passos, fácil de ver onde quebrou. Causa frequente: token expirou, credencial mudou, sistema fonte atualizou versão e o conector parou de funcionar. Comunicação aos consumidores cabe em mensagem direta no canal do time. Restauração pode ser via reconfiguração do conector ou via execução manual da exportação enquanto o problema é resolvido. A lição estrutural é configurar alerta básico — ferramenta no-code costuma oferecer alerta de falha gratuitamente; ativá-lo evita descobrir o problema só quando alguém usa o dashboard.
Na empresa média, há pipeline mais estruturada (ETL próprio, ferramenta de integração paga, jobs agendados). Diagnóstico precisa ser metódico: logs do job que falhou, status da API fonte, mudança recente no schema, fila acumulada de mensagens. Comunicação aos consumidores via canal corporativo, com aviso nos dashboards. Restauração pode envolver fix de código, atualização de conector, ajuste de schema, renovação de credencial. Para BI com múltiplos dashboards, identificar quais foram afetados (e por quanto tempo) é parte da resposta. RCA cobre causa e observabilidade — pipeline falhar silenciosamente é falha de monitoramento, não só falha técnica.
Na empresa grande, há plataforma de dados com pipelines orquestradas (Airflow, dbt, ferramentas comerciais), data lake, data warehouse, observabilidade de pipeline. Quebra de integração crítica é tratada como incidente de dados — time de engenharia de dados, donos de dataset, comunicação a consumidores via canal de dados. Investigação aproveita observabilidade existente (lineage, qualidade, freshness). Restauração via reprocessamento de batches afetados, com janela controlada e validação pós. Comunicação a consumidores executivos via canal apropriado. RCA formal cobre causa, observabilidade que falhou em detectar, ações para melhoria da plataforma. Para pipelines críticas, SLO de freshness com penalidade contratual quando aplicável (fornecedor de SaaS, vendor de ferramenta).
- Dashboard mostra dados desatualizados em dias ou semanas
- Job de ETL falhou ou está rodando sem completar
- API do sistema fonte mudou ou parou de responder
- Erro de schema (campo faltando, tipo incompatível) aparece nos logs
- Usuários começaram a questionar números que "não fecham"
- Alerta de falha de pipeline foi disparado (ou deveria ter sido)
Comunicar primeiro, diagnosticar depois
O reflexo de "deixar o aviso para quando souber a causa" é o erro mais caro. Usuário consumindo dashboard desatualizado sem saber toma decisão errada com confiança falsa. Coloque aviso visível nos dashboards afetados ("dados não atualizados desde X — em investigação") nos primeiros minutos da detecção. Diagnóstico vem em paralelo. A janela entre detecção e aviso é a janela em que erro acontece.
Diagnóstico em camadas
Integração quebrada tem alguns lugares previsíveis para falhar. Investigue em ordem do mais provável.
Credenciais e autenticação
Token expirou, senha foi rotacionada, permissão da conta de serviço foi revogada (talvez em revisão de acessos). Sinal: erro 401/403 nos logs. Costuma ser a causa mais comum e a correção mais rápida.
API ou contrato do sistema fonte
Sistema fonte atualizou versão da API, mudou contrato (campo removido, tipo alterado, paginação modificada), depreciou versão antiga. Sinal: erro 4xx ou 5xx específico, ou mudança silenciosa que só aparece em validação. Para SaaS, depreciação costuma ser anunciada com janela — vale verificar comunicação prévia perdida.
ETL ou ferramenta de pipeline
Job não rodou (agendamento mudou, recurso fora do ar), rodou e falhou (lógica errada, exceção não tratada), rodou e processou parcialmente (timeout, limite de memória). Sinal: status do job, logs de execução, monitoramento de fila.
Schema do banco ou estrutura do dado
Campo renomeado, tabela removida, tipo alterado, índice quebrado. Sinal: erro de SQL, transformação que não encontra coluna. Para mudança feita por outra área sem comunicação ao time de dados, esse é o cenário clássico.
Volume e performance
Crescimento de volume estourou janela de processamento, falta de capacidade, timeout. Sinal: job que antes rodava em X agora não termina em Y, fila acumulando, recursos saturados.
- Coloque aviso nos dashboards afetados. "Dados não atualizados desde X — em investigação". Evita que consumidores usem dado velho como se fosse atual.
- Comunique consumidores ativos. Times que consomem o BI regularmente precisam saber em minutos para parar de usar e aguardar.
- Diagnostique em camadas. Credenciais, API fonte, ETL, schema, volume. Logs e monitoramento dizem onde quebrou.
- Identifique o escopo. Quais dashboards estão afetados, desde quando, quais consumidores usam, quais decisões podem ter sido tomadas com dado antigo.
- Restaure com cautela. Corrigir a causa, não só o sintoma. Reprocessar a janela afetada para preencher os dados perdidos.
- Valide pós-restauração. Confirme que os dashboards voltaram a refletir a realidade. Compare com outras fontes se possível.
- Comunique normalização. Aos consumidores e à diretoria, com nota sobre o período em que o dado estava desatualizado.
Reprocessar a janela afetada
Quando a integração volta, falta corrigir o passado. Dados que deveriam ter chegado entre a quebra e a correção não chegaram — dashboards estão sem essa janela. Reprocessar o período (rodar ETL para os dias afetados, popular o dado retroativamente) costuma ser parte da restauração. Validar que os dados reprocessados batem com a fonte é essencial — meio-restauração é confusão para o consumidor.
Observabilidade: detectar antes
Pipeline falhando silenciosamente é o pior cenário. Detectar só quando o usuário reclama significa que a janela de dado errado foi grande. As frentes de observabilidade que mudam isso.
Alerta de falha de job
Trivial e barato. Toda ferramenta de pipeline oferece. Configurar e direcionar para canal monitorado deveria ser padrão.
Alerta de freshness
"O dado X não foi atualizado há mais de Y horas" — alerta independente da execução do job. Pega o caso em que o job rodou e não falhou tecnicamente, mas não trouxe dado.
Validação de qualidade no destino
Após o dado aterrissar, validações automáticas: contagem dentro do esperado, soma cruzada com outra fonte, comparação com período anterior. Pega erro de dado mesmo quando a integração foi tecnicamente bem.
Lineage e impacto
Saber quais dashboards dependem de qual fonte permite avaliar impacto rápido quando algo quebra, e comunicar consumidores específicos.
Esperar diagnosticar antes de avisar. Usuário usando dado desatualizado sem saber toma decisão errada confiante. Aviso primeiro, diagnóstico em paralelo.
Corrigir só o sintoma. Restaurar a execução sem entender a causa garante reincidência. Causa raiz e correção dela, sempre.
Não reprocessar o período afetado. Pipeline voltando para frente sem corrigir o passado deixa dashboards com buraco. Reprocessamento da janela é parte da restauração.
Pular observabilidade depois. Pipeline falhar silenciosamente é problema de monitoramento. Sem alerta de falha e alerta de freshness, próximo erro é descoberto pelo usuário de novo.
Não acordar schema com produtores do dado. Mudança em sistema fonte feita sem pensar em consumo downstream é causa frequente. Acordo informal de schema reduz drasticamente.
- Aviso foi colocado nos dashboards afetados
- Consumidores ativos foram comunicados
- Causa raiz foi identificada (não só o sintoma)
- Janela afetada foi reprocessada e validada
- Comparação com fonte confirma que dashboards refletem realidade
- Comunicação de normalização foi enviada
- Alertas de falha e freshness foram revisados ou criados
- RCA cobre observabilidade que falhou em detectar