Uma lista de verificação de 11 pontos para definir e cumprir SLAs de dados (com um modelo de SLA)

Arriscaremos dizer que nenhuma equipe é pequena demais para criar e se comprometer com um contrato de nível de serviço de dados ou SLA de dados. O que é um SLA de dados? É uma promessa pública de entregar um nível quantificável de serviço. Assim como seus provedores de infraestrutura como serviço (IaaS) se comprometem com 99,99% de tempo de atividade, é você se comprometendo a fornecer dados de uma certa qualidade, dentro de certos parâmetros.

É importante que o compromisso seja público. (Dentro da empresa, pelo menos.) A publicidade cria melhor responsabilidade, ajuda a alinhar todas as equipes em torno do que é mais importante e permite que você construa uma estrutura que apoie a qualidade.

Neste guia, exploramos como estabelecer seu próprio SLA de dados.

Os SLAs de dados formalizados por escrito tornam seus compromissos informais concretos e mutuamente aceitáveis. Todo relacionamento de dados envolve compromissos informais, quer você os declare ou não, e muito frequentemente, duas partes podem concordar com algo sem perceber que estão falando sobre coisas diferentes.

Então, qual é exatamente o SLA de dados? É um documento escrito simples, geralmente de 250 a 500 palavras, postado em um espaço compartilhado, como a wiki da empresa ou o Google Doc. Deve incluir seis elementos:

• Objetivo: por que esse SLA de dados existe? Quais problemas você espera que ele resolva e como você espera que seja usado?

• Promessa: o que você está prometendo a outras equipes?

• Medição: como você medirá o SLA de dados, quem o medirá e qual é o período de tempo do SLA?

• Ramificações: o que acontece quando você não cumpre seu SLA de dados? Quem é o responsável e que tipo de remediações estão disponíveis, se houver?

• Requisitos: o que você espera em troca? Como suas promessas são condicionais?

• Assinaturas: quem está se comprometendo com o SLA de dados?

Ao redigir seu SLA de dados, transmita-o com o menor número possível de palavras, sem alterar o significado. Isso requer muitas edições, mas recomendamos escrever tudo completo e voltar para editar mais tarde. A razão é que, se você olhar para a página por muito tempo, você pode desenvolver o que os escritores chamam de "ansioso pela página em branco" e continuar adiando. Faça um rascunho de baixa qualidade agora — não espere.

Aqui está um exemplo de contrato de nível de serviço de dados:

O objetivo deste documento é estabelecer uma promessa pública da nossa equipe aos outros para manter a qualidade de dados dentro de parâmetros precisos. Nossa esperança é que ele crie compreensão, ajude-nos a trabalhar juntos e mantenha nossas equipes mutuamente responsáveis.

Nossa promessa: entregaremos dados de vendas com um índice de qualidade de dados de pelo menos 95% até as 5h ET todos os dias para que a equipe possa responder a perguntas como "Quais foram as vendas ontem?" Reconheceremos todas as solicitações dentro de um dia útil e as classificaremos por tickets simples e complexos. Resolveremos solicitações simples dentro de três dias úteis e solicitações complexas dentro de duas semanas.

Mediremos qualidade de dados comparando KPIs de entrega de dados, como Tempo de Início da Execução e Tempo de Conclusão da Execução, Contagem de Registros e proporção de Nulos em relação à Contagem de Registros, além de pontuações de distribuição e desvio, com os padrões predefinidos de atualização, integridade e fidelidade dos dados.

Se descumprirmos um SLA de dados, dentro de três dias úteis, nossa equipe publicará um pedido público de desculpas assumindo a responsabilidade, explicando por que aconteceu e as medidas precisas que estamos implementando para fazer as correções necessárias.

Para cumprir essa promessa, precisamos da sua ajuda. Nossa equipe precisa de orientação oportuna, informações e feedback sobre como os dados estão sendo usados, bem como um aviso prévio de pelo menos quatro semanas sobre quaisquer alterações solicitadas complexas.

Encaminhe todas as perguntas, comentários e preocupações para data-eng@team.com.

Com determinação,

– Sua equipe de engenharia de dados

Com o seu SLA estabelecido (ou talvez enquanto o está editando), comece a pensar em todas as coisas que você precisa colocar em prática antes de conseguir se comprometer com ele.

Por exemplo:

Tente remover o máximo possível de ambiguidade dessa frase. Defina-a em termos concretos e inequívocos. Como vemos, há quatro características que você pode usar para definir dados de alta qualidade. Uma vez definido, garanta o contrato de outras equipes sobre essa definição.

Pergunte a si mesmo:

• Qual é o resultado de bons dados para a empresa?
• Quais características únicas definem bons dados?
• Quais características definem dados ruins?

Para o rastreamento, você precisará de uma ferramenta de observabilidade para saber se partes do seu pipeline estão inoperantes. Sem uma, é muito difícil medir se você não está cumprindo um SLA, muito menos diagnosticar a causa raiz. Também ajuda a compreender os erros, para que você possa corrigir as coisas muito mais rápido.

Você pode tratar seu SLA de dados como uma métrica orientadora, um ponto focal para guiar todos. Mas dentro dele, é claro, há muita complexidade oculta, e você precisará acompanhar uma cesta de KPIs para ajudá-lo a saber o que está acontecendo antes e depois.

Veja aqui algumas recomendações específicas:

1. Configure testes automáticos para monitorar a qualidade de dados em suas quatro dimensões
   • Pré-produção de dados de teste
   • Teste em cada estágio: integridade, anomalias
2. Meça o seu nível de sucesso em descobrir, responder e lidar com os problemas
   • Tempo até a descoberta
   • Tempo até a de resolução
   • Incidentes por ativo
3. Documente as causas próximas e a causa raiz de cada problema
   • O parceiro de dados não cumpriu uma entrega
   • Tempo limite
   • Trabalho preso em uma fila
   • Transformação inesperada
   • Problema de permissão
   • Erro de tempo de execução
   • Alterações na programação

Seja cauteloso sobre aquilo com o que você se compromete. Você não pode estar em todos os lugares e se preparar para tudo, e um SLA de 99,999% de tempo de atividade significa que você pode ter apenas 5 minutos de downtime por ano. Para entregar isso, você provavelmente precisaria de mais funcionários, mais visibilidade, mais redundâncias e pessoas trabalhando 24 horas por dia.

Você provavelmente precisará de uma ferramenta de abertura de chamados, como o Jira ou ServiceNow. Isso permite que os usuários de dados criem tickets, sua equipe os rastreie e você entenda a natureza desses tickets para criar correções de longo prazo e identificar áreas problemáticas.

Talvez você não queira especificá-los em seu documento de SLA de dados públicos, mas definir os proprietários das fontes de dados e dos pipelines. Eles são os principais responsáveis se algo der errado. Especifique também o que acontece se eles saírem de férias ou deixarem a empresa.

Configure alertas para publicar no seu aplicativo de mensagens da equipe, como o Slack, ou em um sistema de gerenciamento de incidentes como o PagerDuty. Quanto mais detalhes do incidente você puder incluir nesse alerta, mais rápido poderá diagnosticar. Esses alertas informarão antecipadamente quem mais você precisará incluir ou onde iniciar sua análise. (o IBM® Databand pode enviar esses alertas e acrescenta contexto e insights úteis).

Digamos que um consumidor de dados diga que uma tabela está corrompida em seu dashboard. Como você confirma e responde? Escreva de forma que, quando ocorrer um incidente, você não se depare com o problema do espectador, em que todos assumem que outra pessoa vai lidar com isso e, então, ninguém age.

Dependendo do tamanho da sua equipe e da sua distribuição no mundo, talvez você queira levar isso muito a sério e nomear o que os responsáveis pela resposta a emergências chamam de líderes de incidentes. Essa pessoa se torna o CEO do incidente e direciona todas as outras. (Isso garante uma resposta coordenada e ajuda a evitar que várias pessoas enfrentem o mesmo problema.)

Se você puder, crie painéis de alerta nos dashboards das pessoas para comunicar o status do sistema. Se algo der errado, você pode escrever: "Estamos passando por uma interrupção. Aqui está o nosso tempo estimado de resolução." Isso difundirá os alertas repetidos de todos os seus consumidores de dados, liberando você para realmente responder.

Se você não puder criar painéis de alerta, pelo menos designe uma pessoa-chave em cada equipe que você possa contar, que então informará a todas as outras.

Monitore como seus consumidores de dados estão usando os dados (e se eles estão usando os dados.) Realize pesquisas ocasionais, formais ou informais, para avaliar sua confiança nesses dados e peça sugestões. Para os consumidores interessados, comunique o que está no seu roteiro.

Defina períodos de manutenção periódica em que a sua equipe avalia o motivo da falha e faz um brainstorming para correções. Pergunte por que esses problemas foram possíveis, realize um post-mortem sem falhas, documente as descobertas, atribua essas correções e monitore como funcionaram.

Com tudo isso definido, você está pronto para editar e revisar seu SLA de dados. Publique-o publicamente no wiki da sua empresa ou em algum lugar compartilhado, garanta o compromisso de todos e cumpra-o.

Os SLAs de dados ajudam a manter a integridade da sua empresa e da sua equipe. Embora sejam formulados como uma promessa pública a outros, na verdade são um contrato bidirecional. Você concorda em fornecer dados dentro de parâmetros específicos, mas, em troca, precisa da participação e compreensão das pessoas.

Muita coisa pode dar errado na engenharia de dados, e grande parte tem a ver com falta de comunicação. Documentar seu SLA ajuda muito a esclarecer tudo, para que você possa alcançar seu objetivo final: incutir maior confiança nos dados dentro de sua organização.

Comece a detectar problemas de integridade de dados com antecedência sempre e pare de perder dinheiro com perdas de SLA de dados. Saiba como capacitar seus engenheiros com alertas avançados e detecção de anomalias para eliminar problemas de qualidade pela raiz. Se você está pronto para fazer uma análise mais detalhada, agende uma demonstração hoje mesmo.