← Últimos artigos
💻 computer science

From Ad-Hoc Scripts to Orchestrated Pipelines: Architecting a Resilient ELT Framework for Developer Productivity Metrics

Este artigo relata a migração de scripts de ingestão ad-hoc para uma arquitetura de pipeline ELT orquestrada com DAGs e Medallion, visando resolver falhas silenciosas e garantir a confiabilidade dos dados necessários para dashboards de produtividade de desenvolvedores.

Autores originais: Yuvraj Agrawal, Pallav Jain

Publicado 2026-02-26
📖 5 min de leitura🧠 Leitura aprofundada

Autores originais: Yuvraj Agrawal, Pallav Jain

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você é o gerente de uma grande fábrica de software. Você quer saber se os trabalhadores estão produzindo bem, se as máquinas não estão quebrando e se os produtos estão saindo no prazo. Para isso, você instalou um painel de controle (um "Dashboard") com luzes e números.

No início, esse painel funcionava de um jeito meio "gambiarra": você tinha um funcionário (um script) que acordava de madrugada, olhava para as máquinas, anotava os números em um caderno e, se não encontrasse nada, escrevia "0". O problema é que, se o funcionário adormecesse ou se a máquina estivesse desligada, ele ainda escrevia "0". Você achava que a fábrica estava parada, mas na verdade era apenas o funcionário que falhou. Isso é o que os autores chamam de "Zero Fantasma": um erro silencioso que parece um dado real, mas é mentira.

Este paper conta a história de como a Adobe mudou esse sistema de "gambiarra" para uma fábrica de dados organizada e à prova de falhas. Aqui está a explicação simples:

1. O Problema: A "Gambiarra" do Cron Job

Antes, eles usavam scripts simples (como um despertador que toca de manhã) para pegar dados do GitHub, Jira e Jenkins.

  • O Erro: Se o sistema de uma máquina (API) falhasse silenciosamente, o script pensava: "Ah, não tem nada hoje" e colocava "0" no painel.
  • A Consequência: O painel mostrava que a equipe estava super produtiva (ou super parada), mas era mentira. Ninguém confiava mais no painel.

2. A Solução: A Fábrica de 3 Andares (Arquitetura Medallion)

Eles construíram um sistema novo, como uma linha de montagem de três andares, para garantir que o que chega no painel final seja sempre verdade.

  • Andar 1 (Bronze - O Armazém Bruto): É como uma câmera de segurança que grava tudo, sem julgar. Eles salvam exatamente o que o sistema original mandou (o JSON bruto), sem tentar consertar nada. Se a câmera falhar, o sistema sabe que a gravação parou. Isso é o "histórico imutável".
  • Andar 2 (Prata - A Limpeza): Aqui, os dados são lavados e organizados. Eles convertem horários de diferentes fusos, unificam nomes de usuários (quem é "joao" no GitHub e "joao.silva" no e-mail?) e jogam fora lixo (como testes de robôs).
  • Andar 3 (Ouro - O Painel Final): Só aqui os números são calculados e mostrados no painel. É uma versão limpa, rápida e pronta para leitura.

A Grande Vantagem: Se a definição de "sucesso" mudar (ex: "agora não contamos mais bugs pequenos"), eles não precisam ir buscar os dados de novo na fonte (o que é lento e caro). Eles apenas reprocessam o que já está guardado no Andar 1 e 2. É como reescrever a receita de um bolo sem precisar comprar os ingredientes de novo.

3. O Maestro (Orquestração com DAGs)

Antes, os scripts rodavam por horário (às 1:00, às 1:30). Se o primeiro atrasasse, o segundo rodava com dados velhos.
Agora, eles usam um Maestro (Apache Airflow) que funciona como um maestro de orquestra ou um chefe de cozinha.

  • Regra de Ouro: O prato B só é servido se o prato A estiver pronto e aprovado.
  • Portões Rígidos (Hard Gates): Se a fonte de dados falhar, o maestro para tudo imediatamente. Nada de dados "metade pronto" ou "0" falso chega ao painel. É melhor o painel ficar em branco do que mostrar mentira.

4. O Sistema de Alerta (Empurrar em vez de Puxar)

Antes, o sistema "perguntava" a cada hora: "Tem algum problema?". Isso era lento e gastava energia.
Agora, eles usam um sistema de notificação automática (Push).

  • Analogia: Imagine que, em vez de você ir até a caixa registradora verificar se o dinheiro bateu a cada hora, o caixa tem um botão de pânico. Assim que o dinheiro não bater, ele aperta o botão e um alarme toca instantaneamente no seu celular.
  • Isso permite que a equipe saiba de um erro em segundos, não em horas.

5. O Que Aprendemos (Lições de Casa)

  • Não confie no "Zero": Se o sistema diz que não houve atividade, verifique se o sensor não quebrou.
  • Histórico é Rei: Guardar os dados brutos (Andar 1) permite corrigir erros do passado sem precisar pedir os dados de novo para os fornecedores.
  • Automação é Segurança: Se um token de senha expirar, o sistema deve pegar um novo automaticamente, sem depender de um humano lembrar de atualizar.

Resumo Final

O papel diz que, para confiar em métricas de produtividade de desenvolvedores, você não pode usar scripts soltos e amadores. Você precisa de uma engenharia de dados robusta, onde os dados são guardados, limpos e verificados em etapas, com um maestro garantindo que nada de errado chegue ao final.

A lição principal: Um painel de controle que os usuários não confiam é inútil. Se eles acham que os números são mentirosos, eles param de olhar. A confiança é construída com processos sólidos, não apenas com gráficos bonitos.

Afogado em artigos na sua área?

Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.

Experimentar Digest →