Data Products confiáveis: dados disponíveis nem sempre significam dados certos 

Imagine que você pede uma entrega por aplicativo. O app avisa que o motoboy saiu, que ele chegou ao seu endereço e que o pedido foi entregue com sucesso. Só que, quando você abre a sacola, faltam dois itens. Tecnicamente, a entrega "funcionou": o app não travou, o motoboy chegou, o status ficou verde. Mas, na prática, o serviço falhou com você.

Algo parecido acontece o tempo todo com dados dentro das empresas. 

Um conjunto de sistemas move informações de um lugar para outro todos os dias — isso é o que chamamos de pipeline de dados. Em muitos casos, tudo parece ter corrido bem: os processos terminaram no horário, nenhum sistema caiu, a tabela final pode ser consultada normalmente. Horas depois, alguém percebe que uma parte das vendas não entrou no relatório. Em outro caso, um número continua lá, no mesmo lugar de sempre, mas passou a significar outra coisa depois de uma mudança em algum sistema de origem — como se o preço de um produto, do nada, passasse a ser mostrado em centavos em vez de reais. 

Em nenhum dos dois casos existe um "erro" óbvio, do tipo tela azul ou sistema fora do ar. E, ainda assim, a informação entregue não é o que as pessoas esperavam receber. Isso importa porque, hoje, dados não alimentam só relatórios: eles também sustentam aplicativos, modelos de inteligência artificial, decisões do dia a dia e processos automáticos. Um problema em um único ponto pode se espalhar rapidamente por tudo que depende dele — mesmo que, olhando só para a infraestrutura, esteja tudo "verde". 

Por isso, garantir que os dados sejam confiáveis não pode ser algo que se verifica só no final, como uma vistoria de última hora. Precisa ser algo pensado desde o início: deixar claro o que se promete entregar, criar mecanismos automáticos que vigiem isso, observar o comportamento dos dados no dia a dia, medir se os compromissos estão sendo cumpridos e mudar as coisas sem pegar ninguém de surpresa. 

Este artigo explica, de forma direta, quais práticas ajudam a construir essa confiabilidade.

 

Primeiro: o que exatamente está sendo prometido?

Antes de discutir qualquer ferramenta, é preciso responder a uma pergunta simples: o que significa "dado bom" para quem vai usá-lo?

 

Um relatório financeiro que é atualizado uma vez por dia pode ser perfeitamente adequado para uma análise mensal — mas completamente inútil para um sistema que precisa identificar uma transação suspeita em poucos minutos. Ou seja, "qualidade" não é uma régua fixa e universal. Ela depende de quem vai usar o dado e para quê. 

É por isso que uma métrica como "98% dos registros estão completos" pode ser ótima para uma análise exploratória e, ao mesmo tempo, inaceitável para o setor que calcula faturas de clientes. 

Vale a pena separar três ideias que costumam se misturar: 

Qualidade dos dados: os dados estão corretos, de acordo com as regras combinadas? 

Disponibilidade: é possível acessar e usar o dado quando e como foi combinado? 

Confiabilidade: essas duas coisas continuam acontecendo de forma consistente, dia após dia — ou é uma loteria?

Definir a "promessa" de um produto de dados vai além de dizer qual é a estrutura das informações e com que frequência elas são atualizadas. Também envolve deixar claro o que cada campo realmente significa, como os números são calculados, quais atrasos são esperados e aceitáveis, e quem é responsável por cada parte. Sem isso, um time pode estar de olho em centenas de indicadores e, mesmo assim, não conseguir responder a uma pergunta básica: "esse dado está bom o suficiente para o que estamos usando ele?"

 

Data contracts: um "acordo por escrito" entre quem produz e quem usa os dados

Você já deve ter visto um contrato de aluguel, de prestação de serviço, ou até os termos de uso de um aplicativo. Esses documentos existem para que as duas partes saibam exatamente o que esperar uma da outra, sem depender de "combinados verbais" que cada lado entende de um jeito. 

Um data contract (contrato de dados) faz algo parecido, mas entre o time que produz um dado e os times que o utilizam. Ele descreve, por escrito e de forma que os próprios sistemas conseguem verificar automaticamente, coisas como: quais informações vão existir, quais são obrigatórias, o que cada uma significa, com que frequência serão atualizadas e quem é o responsável por manter tudo funcionando. 

Isso é especialmente importante quando times diferentes cuidam de partes diferentes da cadeia — um time cuida da origem dos dados, outro faz as transformações, outro constrói o produto final. Sem um acordo explícito, cada equipe cria suas próprias suposições. Um time pode achar que um determinado campo é opcional; outro pode estar usando esse mesmo campo como se fosse essencial para o funcionamento do sistema. O problema fica escondido até que, um dia, algo dá errado de verdade. 

O ponto-chave é que esse contrato só tem valor de fato quando ele é verificado automaticamente, e não apenas escrito em um documento que ninguém consulta. Assim, se alguém tentar remover uma informação obrigatória ou mudar seu formato, o sistema consegue avisar antes que isso afete quem usa o dado — parecido com um corretor ortográfico que avisa sobre um erro antes de você enviar o e-mail. 

Ao mesmo tempo, um contrato rígido demais pode travar qualquer evolução do produto, tornando cada pequena mudança um processo lento e burocrático. Um contrato frouxo demais, por outro lado, não protege ninguém de verdade. O nível de rigor deve depender de quão crítico é aquele dado, quantas pessoas dependem dele e qual seria o estrago de um erro. 

Um exemplo prático: imagine um produto de dados que mostra valores em dinheiro. Mudar a forma como esse número é registrado (por exemplo, de número inteiro para número com casas decimais) pode ser uma mudança tranquila para uns sistemas e quebrar outros. Já mudar a unidade — de reais para centavos — pode manter exatamente a mesma aparência técnica, mas fazer com que todo mundo passe a interpretar o valor errado, achando que R$ 10,00 é, na verdade, R$ 0,10. Por isso, não basta garantir que a "forma" dos dados não mudou: é preciso garantir que o significado também continua o mesmo. 

 

Testes: várias redes de proteção, não uma única barreira no fim da linha

É comum pensar em "teste" como aquela checagem final antes de liberar algo,,como revisar um texto só depois de pronto. Mas, com dados, isso é arriscado: se o único ponto de controle é o final do processo, um problema pode passar despercebido por várias etapas antes de ser notado. 

Por isso, faz mais sentido espalhar verificações ao longo de todo o caminho — quando o dado entra no sistema, quando é transformado, quando é publicado e quando é consumido. Cada etapa tem seus próprios riscos, e por isso pede tipos diferentes de teste: 

• Testes de estrutura: conferem se os dados continuam no formato combinado (tipos, campos obrigatórios etc.). 
• Testes de conteúdo: verificam se não há informações faltando indevidamente, valores duplicados ou números fora do esperado. 
• Comparações entre origem e destino: conferem, por exemplo, se a quantidade de vendas que saiu do sistema de origem é a mesma que chegou ao relatório final. 
• Testes de integração: verificam se as diferentes partes do sistema conseguem, juntas, entregar o produto dentro do prazo e da forma combinados. 
• Testes de regressão: verificam se uma mudança recente não quebrou algo que funcionava antes. 

Vale destacar: esses testes não substituem uns aos outros. Uma coluna pode passar em todas as verificações de "não está vazia" e, ainda assim, estar com o conteúdo semanticamente errado. Uma tabela pode ter o número certo de registros no total, mas estar sem os dados de uma região inteira. Um processo pode ter rodado com sucesso, só que depois do horário em que a informação era necessária para uma decisão. 

Outra decisão importante é: o que fazer quando um teste falha? Bloquear a publicação daquele dado faz sentido quando o risco de entregar uma informação errada é alto. Em outros casos, pode ser melhor apenas isolar a parte com problema, publicar com um aviso de que algo está fora do padrão, ou simplesmente gerar um alerta para alguém investigar. 

Bloquear tudo, sempre, deixa o sistema menos disponível. Alertar sobre qualquer oscilação pequena cria tanto barulho que as pessoas passam a ignorar os alertas — o clássico efeito "menino que gritou lobo". A resposta certa depende da gravidade do problema, de quão confiável é aquele teste específico e do impacto real sobre quem usa o dado. 

 

Observabilidade: entender o produto, não só o "motor" por trás dele

Testes detectam problemas que a equipe já previu e programou para verificar. Mas, no dia a dia, coisas acontecem que ninguém tinha imaginado — e é aí que entra a observabilidade. 

Pense na diferença entre um painel de carro e um mecânico experiente. O painel mostra luzes de aviso para problemas já conhecidos, como pouco combustível. Já o mecânico consegue ouvir um barulho estranho, investigar e descobrir a causa de algo que nenhuma luz do painel avisou. Monitoramento é o painel: acompanha indicadores já definidos. Observabilidade é ter informação suficiente para investigar por que algo saiu do esperado, mesmo quando não havia um alarme programado para aquilo. 

Para um produto de dados, isso significa observar em várias camadas ao mesmo tempo: 

• A execução dos processos: falhas, tempo de execução, uso de recursos. 
• Os próprios dados: se estão atualizados, completos, dentro do padrão esperado, sem duplicidade. 
• As dependências entre sistemas (chamadas de lineage, ou "linhagem dos dados"): de onde cada informação veio e para onde ela vai — como um mapa que mostra todo o caminho percorrido por aquele dado. 
• A experiência de quem consome: se as consultas estão rápidas, se os sistemas que usam o dado estão funcionando bem. 

Essa visão em conjunto evita um problema clássico: painéis de infraestrutura totalmente verdes, enquanto quem usa os dados recebe informação incompleta ou errada. Se um processo "termina com sucesso" depois de processar só metade dos arquivos esperados, olhar apenas para o status do processo não conta a história toda — é preciso também observar o volume de dados entregue. 

Ferramentas de detecção automática de anomalias também podem ajudar, identificando quedas bruscas de volume ou mudanças estranhas nos valores. Mas é preciso cuidado: uma variação sazonal legítima (como uma queda de vendas em um feriado) pode parecer um erro, enquanto um problema que piora aos poucos pode passar despercebido por ficar sempre "dentro da margem". 

Por isso, o objetivo da observabilidade não é apenas disparar alarmes, e sim ajudar a responder rápido a perguntas como: o que mudou, quando começou, quais fontes de dados estavam envolvidas e quem precisa ser avisado. 

 

Colocando números na confiabilidade: SLIs e SLOs

Se a promessa de um produto de dados não pode ser medida, fica difícil saber se as coisas estão realmente indo bem — e mais difícil ainda priorizar melhorias. Aqui, um conceito emprestado da área de infraestrutura de tecnologia (chamado de Site Reliability Engineering) ajuda bastante: os indicadores e objetivos de nível de serviço, conhecidos pelas siglas SLI e SLO. 

De forma simples: 

• Um SLI é uma métrica concreta — por exemplo, "porcentagem de atualizações que aconteceram dentro do prazo combinado". 
• Um SLO é a meta para essa métrica — por exemplo, "os dados devem estar disponíveis até as 7h em pelo menos 99% dos dias úteis do mês". 

É como o prazo de entrega de uma loja online: dizer apenas que "o site está no ar" não garante que seu pedido vai chegar no prazo prometido. O SLO é justamente esse compromisso de prazo, e o SLI é o número que mostra se ele está realmente sendo cumprido. 

Um detalhe importante: metas de confiabilidade não devem ser definidas só pensando no que a equipe técnica acha viável entregar. Elas precisam refletir o que quem usa os dados realmente precisa, equilibrado com o custo de manter esse nível de qualidade. Metas mais rígidas normalmente exigem mais investimento: redundância, plantão de equipe, testes extras. 

Existe ainda o conceito de margem de erro tolerável (chamado de error budget): em vez de exigir perfeição total, a equipe aceita uma pequena margem de falha compatível com a meta combinada. Se essa margem está sendo usada demais, é sinal de que melhorar a confiabilidade deve virar prioridade — mesmo que isso signifique atrasar novas funcionalidades. Se a margem está sobrando, há espaço para investir em coisas novas. 

E quando algo dá errado de verdade? Alertas precisam chegar até a pessoa certa, com critério claro sobre a gravidade do problema. Depois de incidentes importantes, vale fazer uma análise sem buscar "culpados", focada em entender o que faltou nos controles e como evitar que aconteça de novo.

 

Documentação e mapa de dependências: saber o que vai ser afetado antes de mudar algo

Descrever com clareza o que cada informação significa, como é calculada, quem é responsável por ela e com que frequência é atualizada parece um detalhe burocrático — mas reduz muito mal-entendido e retrabalho. 

Essa documentação fica ainda mais poderosa quando conectada a um mapa de dependências (o tal do lineage): antes de mudar um campo, a equipe consegue saber quais outros sistemas e relatórios dependem dele. Durante um problema, consegue rastrear rapidamente de onde veio o erro. Depois de corrigido, consegue saber quais relatórios ou modelos precisam ser recalculados. 

Uma ressalva importante: esse mapa nunca é 100% completo. Planilhas exportadas manualmente, consultas feitas por fora dos sistemas oficiais e integrações "por baixo dos panos" criam usuários invisíveis, que ninguém sabia que dependiam daquele dado. Por isso, ferramentas automáticas de mapeamento precisam ser combinadas com um bom registro de quem é responsável por cada coisa, e com conversas reais entre as equipes. 

 

Mudar sem quebrar: versionamento e aposentadoria de versões antigas

Produtos de dados precisam evoluir. Novas fontes de informação surgem, regras de negócio mudam, tecnologias são trocadas. A confiabilidade não está em travar essas mudanças, e sim em fazê-las de um jeito previsível — sem pegar ninguém de surpresa. 

Uma mudança é compatível quando quem já usa aquele dado continua funcionando normalmente sem precisar fazer nada. É incompatível quando exige alguma adaptação do lado de quem consome. E aqui vale reforçar algo já mencionado: até uma mudança que parece pequena e "só estrutural" — como adicionar uma nova coluna — pode afetar sistemas que dependem da posição exata dos campos. E uma mudança na fórmula de cálculo, sem alterar nada na estrutura visível, pode ter um impacto ainda maior, do tipo mais difícil de perceber. 

Quando uma mudança incompatível é inevitável, faz sentido manter a versão antiga funcionando por um tempo, em paralelo com a nova — dando um prazo de transição, parecido com quando um aplicativo avisa "esta versão vai parar de funcionar em tal data, atualize até lá". Essa comunicação deve deixar claro: o que está mudando, como se adaptar, quem será afetado e até quando a versão antiga continua disponível. 

Isso não significa que toda mudança precisa gerar uma "versão nova" formal. Em ajustes pequenos e compatíveis, um simples registro do que mudou (um changelog) e alguns testes já bastam. Já em mudanças mais profundas ou que alteram o significado dos dados, criar uma versão nova e explícita costuma ser o caminho mais seguro. 

 

Juntando tudo: como isso funciona na prática do dia a dia

Todas essas práticas formam, na verdade, um ciclo contínuo: definir o que está sendo prometido, verificar antes de publicar, observar o comportamento em produção, responder rápido quando algo foge do esperado, aprender com os problemas que acontecem e evoluir sem surpreender ninguém. 

Isso também exige clareza sobre responsabilidades. Quem é dono do produto de dados precisa garantir que as promessas estejam claras e que a confiabilidade seja tratada como prioridade — não como algo que se resolve "se sobrar tempo". A equipe técnica implementa os controles. Times de plataforma oferecem as ferramentas reutilizáveis (de monitoramento, testes, documentação). A área de governança define regras proporcionais ao risco. E quem consome os dados também tem um papel: avisar sobre suas necessidades e sobre o impacto real de cada problema. 

E aqui vale um ponto de bom senso: nem todo produto de dados precisa do mesmo nível de rigor. Um produto crítico, usado por muita gente ou que alimenta processos automáticos, exige contratos, metas e procedimentos mais rígidos. Já um produto ainda em fase exploratória pode começar com controles mais leves — e ganhar mais rigor conforme for sendo mais usado e se tornando mais importante para a empresa. O objetivo é evitar dois exageros opostos: burocracia demais em coisas pouco críticas, ou tratar um sistema essencial como se fosse ainda um experimento. 

 

Para fechar: confiabilidade não é um selo, é um hábito

Um produto de dados confiável é aquele cujas promessas são claras, verificáveis e observadas de perto, e cujas mudanças acontecem sem pegar ninguém desprevenido. 

Contratos deixam claro o que está sendo combinado. Testes evitam que erros já conhecidos se repitam. Observabilidade ajuda a investigar o que ninguém previu. Metas mensuráveis (SLIs e SLOs) transformam expectativas em números acompanháveis. Documentação e mapas de dependência ajudam a entender o impacto de cada mudança. E um processo claro de versionamento evita que a evolução do produto vire um susto para quem depende dele. 

Ferramentas ajudam — e muito — mas não substituem decisões de produto, clareza sobre responsabilidades e bom senso na hora de escolher o nível de rigor certo para cada situação. Confiabilidade não é algo que se conquista uma vez e fica garantido para sempre; é um cuidado contínuo, que acompanha a evolução das fontes de dados, da arquitetura e da forma como as pessoas usam a informação no dia a dia. 

O primeiro passo não é escolher uma ferramenta nova. É simples: identificar quais produtos de dados sustentam decisões importantes na empresa, deixar claro o que cada um promete entregar — e verificar se essas promessas realmente podem ser testadas, observadas e evoluídas com segurança.