A estrutura organizacional de DataOps ideal

As comunicações externas de uma organização tendem a refletir suas internas. Foi o que Melvin Conway nos ensinou, e isso se aplica à engenharia de dados. Se você não tiver uma equipe de operações de dados ou "DataOps" claramente definida, as saídas de dados da sua empresa serão tão confusas quanto suas entradas.

As operações de dados são o processo de montagem da infraestrutura para gerar e processar dados, além de mantê-los. É também o nome da equipe que faz (ou deveria fazer) esse trabalho — operações de dados ou DataOps. O que o DataOps faz? Bem, se a sua empresa mantém pipelines de dados, lançar uma equipe sob esse nome para gerenciar esses pipelines pode trazer um elemento de organização e controle que de outra forma falta.

O DataOps não é apenas para empresas que vendem seus dados. A história recente provou que você precisa de uma equipe de operações de dados, independentemente da proveniência ou do uso desses dados. Cliente interno ou cliente externo, tanto faz. Você precisa de uma equipe para construir (ou sejamos realistas, herdar e depois reconstruir) os pipelines. Devem ser as mesmas pessoas (ou, para muitas organizações, pessoas) que implementam as ferramentas de observabilidade e acompanhamento e monitoram a qualidade de dados em seus quatro atributos.

E, é claro, as pessoas que criaram o pipeline devem ser as mesmas pessoas que recebem o temido alerta do PagerDuty quando um dashboard está inativo, não porque seja punitivo, mas porque é educacional. Quando têm a pele no jogo, as pessoas constroem de forma diferente. É um bom incentivo e permite uma melhor solução de problemas e uma resolução mais rápida.

Por último, mas não menos importante, essa equipe de operações de dados precisa de uma missão — uma que transcende simplesmente "mover os dados" do ponto A para o ponto B. E é por isso que a parte "operações" do título é tão importante.

As operações de dados estão construindo processos resilientes  para migrar dados para a finalidade pretendida. Todos os dados devem migrar por um motivo. Muitas vezes, esse motivo é a receita. Se sua equipe de operações de dados não consegue traçar uma linha clara desde esse objetivo final, como equipes de vendas que têm melhores previsões e ganham mais dinheiro, até suas atividades de gerenciamento de pipeline, você tem um problema.

Sem operações, surgirão problemas à medida que você escala:

• Duplicação de dados
• Colaboração problemática
• Aguardando dados
• Band-aids que deixarão cicatrizes
• Problemas de descoberta
• Ferramentas desconectadas
• Registro de inconsistências
• Falta de processo
• Falta de propriedade e SLAs

Se houver uma desconexão, você está simplesmente praticando o antigo gerenciamento de dados. O gerenciamento de dados é o aspecto de manutenção rotineira das operações de dados. O que, embora crucial, não é estratégico. Quando você está no modo de manutenção, está procurando o motivo de uma falha de coluna ou pipeline e corrigindo-a, mas não tem tempo para planejar e melhorar.

Seu trabalho se torna verdadeiras "operações" quando você transforma registros de problemas em correções repetíveis. Por exemplo, você encontra um erro de transformação vindo de um parceiro e envia um e-mail para ele para que o problema seja corrigido antes de atingir seu pipeline. Ou você implementa um banner de “alertas” no dashboard dos seus executivos que os informa quando algo está errado, para que eles saibam aguardar a atualização. As operações de dados, assim como as operações de desenvolvedor, visam implementar sistemas repetíveis, testáveis, explicáveis e intuitivos que, em última análise, reduzem o esforço de todos.

Isso é operações de dados versus gerenciamento de dados. Assim, a pergunta passa a ser: como essa equipe de operações de dados deve ser estruturada?

Então, vamos voltar por onde começamos, falando sobre como as saídas do sistema refletem sua estrutura organizacional. Se sua equipe de operações de dados for uma equipe de “operações” apenas no nome, e principalmente apenas manter, você provavelmente receberá um backlog de solicitações sempre crescente. Raramente você terá tempo de tomar um ar para fazer alterações de manutenção de longo prazo, como trocar um sistema ou ajustar um processo. Você está preso no mundo de respostas do Jira ou do ServiceNow.

Se, por outro lado, você fundou (ou relançou) sua equipe de operações de dados com princípios e estrutura fortes, você produz dados que refletem sua estrutura interna de alta qualidade. Boas estruturas de equipe de operações de dados produzem bons dados.

Reúna um engenheiro de dados, um cientista de dados e um analista em um pod ou grupo e faça-os lidar com coisas juntos com as quais poderiam ter lidado separadamente. Invariavelmente, essas três perspectivas levam a decisões melhores, menos desperdício de recursos e mais previsão. Por exemplo, em vez de o cientista de dados escrever um caderno que não faz sentido e passá-lo ao engenheiro apenas para criar um ciclo de vaivém, ele e o analista podem falar sobre o que precisam e o engenheiro pode explicar como isso deve ser feito.
Muitas equipes de operações de dados já trabalham dessa maneira. "As equipes devem buscar ser equipadas como 'full-stack', para que o talento necessário em engenharia de dados esteja disponível para ter uma visão de longo prazo de todo o ciclo de vida dos dados", dizem Krishna Puttaswamy e Suresh Srinivas, da Uber. E no site de viagens Agoda, a equipe de engenharia usa pods pelo mesmo motivo.

Faça isso mesmo se você for apenas uma pessoa. Cada função é um “chapéu” que alguém deve usar. Para ter uma equipe de operações de dados altamente eficiente, é útil saber qual chapéu está onde e quem é o proprietário dos dados. Também é necessário reduzir o alcance do controle de cada indivíduo a um nível gerenciável. Talvez delinear assim ajude você a defender a contratação.

O que é gerenciamento de equipes de operações de dados? Uma camada de coordenação além do seu pod estrutura as estruturas que desempenham o papel de líder servidor. Eles gerenciam, orientam e desbloqueiam projetos. Idealmente, elas são as pessoas mais experientes da equipe.

Criamos nossa própria estrutura ideal, na foto, embora seja um trabalho em andamento. O que é importante observar é que há uma única pessoa liderando com uma visão para os dados (o VP). Abaixo deles estão vários líderes que orientam várias disciplinas de dados em direção a essa visão (os Diretores) e, abaixo deles, equipes interdisciplinares que garantem que a organização de dados e as funcionalidades trabalhem juntas. (Crédito ao nosso Arquiteto de Soluções de Dados, Michael Harper, pelas ideias.)

Escolher uma métrica orientadora ajuda todos os envolvidos a entender o que devem otimizar. Sem esse acordo, surgem disputas. Talvez seus “clientes” de dados internos reclamam que os dados são lentos. Mas a razão para a lentidão é que você sabe que o desejo não declarado deles é otimizar para qualidade primeiro.

Estrelas do norte comuns de DataOps: qualidade de dados, automação (processos repetíveis) e descentralização de processos (também conhecida como autossuficiência do usuário final).

Depois de definir um norte, você também pode decidir sobre sub-métricas ou subprincípios que apontam para esse norte, que é quase sempre um indicador de atraso.

Organize a equipe de modo que diferentes grupos dentro dela interajam com frequência e peçam coisas a outros grupos. Essas interações podem ser inestimáveis. "Quando os cientistas de dados e engenheiros aprendem uns sobre os outros a trabalhar, essas equipes se movem mais rapidamente e produzem mais", diz Amir Arad, Gerente Sênior de Engenharia da Agoda.

Amir diz que acha que um dos valores ocultos de um pouco de redundância multifuncional é que as pessoas fazem perguntas que ninguém naquela equipe havia pensado em fazer.

"A lacuna de conhecimento de engenharia é realmente muito boa. Isso pode fazer com que eles nos peçam para simplificar”, diz Amir. “Elas podem dizer: 'Mas por que não podemos fazer isso?' E, às vezes, voltamos e percebemos que não precisamos desse código ou do servidor. Às vezes, não especialistas trazem coisas novas para a mesa.”

Assim como no DevOps, as melhores equipes de operações de dados são invisíveis e trabalham constantemente para se tornarem redundantes. Em vez de desempenhar o papel de herói que gosta de salvar a todos, mas que acaba fragilizando o sistema, faça de líder servidor. Procure, como disse Lao Tzu, levar as pessoas à solução de uma forma que as faça pensar: “Fizemos isso sozinhos”.

Trate sua equipe de operações de dados como uma equipe de produto. Estude seu cliente. Mantenha um backlog de correções. Procure tornar a ferramenta útil o suficiente para que os dados sejam realmente usados.

Não existe "cedo demais" para o monitoramento de dados e a observabilidade. A analogia que é frequentemente usada para justificar o adiamento do monitoramento é: "Estamos construindo o avião durante o voo". Pense nesse visual. Isso não diz tudo o que você precisa saber sobre sua sobrevivência a longo prazo? Uma analogia muito melhor é a arquitetura antiga. Quanto mais você espera para montar uma base, mais caro é colocar e mais problemas cria a falta de uma base.

Leia: O que é observabilidade de dados?

As decisões que você toma agora com sua infraestrutura de dados, como disse o General Maximus, “ecoam na eternidade”. Os hackers de crescimento de hoje são o pesadelo gigantesco do caos do sistema interno que transforma os dados de amanhã. Você precisa garantir o apoio da diretoria para tomar decisões inconvenientes, mas corretas, como dizer a todos que precisam pausar as solicitações porque você precisa de um trimestre para resolver as coisas.

CASE significa "copiar e roubar tudo", uma maneira irônica de dizer, não construa tudo a partir do zero. Há muitos microsserviços úteis e ofertas de código aberto hoje. Apoie-se nos ombros de gigantes e concentre-se em construir os 40% do seu pipeline que realmente precisam ser personalizados, e fazendo isso bem.

Dê uma olhada nos tickets em sua lista de pendências. Com que frequência você reage em vez de antecipar problemas? Quantos dos problemas com os quais você lidou tinham uma causa raiz claramente identificável? Quantos você conseguiu fazer as correções permanentemente? Quanto mais você prevenir, mais se assemelhará a uma verdadeira equipe de operações de dados. E, quanto mais útil você achar uma ferramenta de observabilidade de dados, mais fácil será. A visibilidade total pode ajudá-lo a fazer a transição de simplesmente manter para melhorar ativamente.

Equipes que melhoram ativamente sua estrutura melhoram ativamente seus dados. A harmonia interna leva à harmonia externa, em uma conexão que deixaria Melvin Conway orgulhoso.

Saiba mais sobre a plataforma de observabilidade contínua de dados do IBM Databand e como ela ajuda a detectar incidentes de dados mais cedo, resolvê-los mais rapidamente e entregar dados mais confiáveis para a empresa. Se você está pronto para fazer uma análise mais detalhada, agende uma demonstração hoje mesmo.