Métricas DORA a partir dos dados de release, por serviço

A maioria das equipes de engenharia sabe dizer o que entregou. Pouquíssimas sabem dizer com que velocidade entregaram, com que frequência algo quebrou, ou quanto tempo levou para se recuperar quando quebrou. A contagem de deploys está lá. O sinal de qualidade, não.

Esse ponto cego existe porque desempenho de entrega e documentação de arquitetura sempre viveram em mundos separados. Sua ferramenta de CI/CD conhece pipelines. Sua ferramenta de arquitetura conhece sistemas. Nenhuma das duas sabe o suficiente para responder à pergunta que realmente importa: a sua equipe está ficando melhor em entregar software?

As métricas DORA fecham essa lacuna, e o Archyl agora as calcula automaticamente a partir dos seus dados de release. Este post explica como isso funciona. Para entender por que métricas de entrega pertencem ao lado da arquitetura, veja métricas DORA para equipes de arquitetura.

As quatro métricas que importam

Em 2018, a equipe do DORA (DevOps Research and Assessment, hoje parte do Google Cloud) publicou uma pesquisa mostrando que quatro métricas específicas preveem o desempenho de entrega de software melhor do que qualquer outra coisa. Desde então, elas viraram o padrão do setor para medir a eficácia da engenharia:

Deployment Frequency: com que frequência sua equipe faz deploy em produção. Equipes elite fazem deploy sob demanda, várias vezes por dia. Equipes de baixo desempenho fazem deploy entre uma vez por mês e uma vez a cada seis meses.

Lead Time for Changes: quanto tempo leva do commit do código até o deploy em produção. Equipes elite medem isso em horas. Equipes de baixo desempenho, em meses.

Change Failure Rate: que porcentagem dos deploys causa uma falha em produção (exigindo hotfix, rollback ou patch). Equipes elite ficam abaixo de 5%. Equipes de baixo desempenho passam de 46%.

Mean Time to Restore (MTTR): quando acontece uma falha em produção, quanto tempo leva para restaurar o serviço? Equipes elite restauram em menos de uma hora. Equipes de baixo desempenho levam de uma semana a um mês.

A força do DORA não está em uma métrica isolada, mas nas quatro juntas. Uma equipe que faz deploy dez vezes por dia mas derruba a produção metade das vezes não está indo bem. Uma equipe com zero falhas mas um deploy por trimestre está jogando seguro demais. As quatro métricas formam um scorecard equilibrado que recompensa tanto a velocidade quanto a estabilidade.

DORA no Archyl: construído sobre seus dados de release

A questão das métricas DORA é esta: se você acompanha releases, os dados brutos já existem. Cada release tem um timestamp, um status e um ambiente. Isso basta para calcular as quatro métricas automaticamente.

Se você já usa o Release Management do Archyl (via GitHub Actions, webhooks ou a API REST), você já tem os dados. Só faltava fazer a conta.

A Deployment Frequency é calculada a partir do número de deploys bem-sucedidos em produção em uma janela de tempo. Se você fez 45 releases em produção nos últimos 30 dias, sua deployment frequency é de 1,5 por dia.

O Lead Time for Changes é o tempo entre a criação de uma release (ou o timestamp do commit, quando disponível) e o seu deploy bem-sucedido em produção. O Archyl calcula a mediana de todas as releases do período.

O Change Failure Rate considera as releases com status Failed ou Rolled Back como porcentagem do total de deploys. Se você fez 40 deploys e 3 deles sofreram rollback, seu CFR é de 7,5%.

O Mean Time to Restore mede o tempo entre um deploy com falha e o próximo deploy bem-sucedido no mesmo ambiente. Ele captura a rapidez com que sua equipe se recupera de incidentes.

As quatro métricas são calculadas automaticamente. Sem configuração, sem entrada manual. Se as suas releases estão chegando ao Archyl, as métricas DORA já estão lá.

O scorecard DORA

Cada métrica é classificada em um de quatro níveis de desempenho, com base nos benchmarks estabelecidos pela pesquisa do DORA:

  • Elite: desempenho de ponta. Você está na faixa mais alta das equipes de engenharia do mundo.
  • High: desempenho forte. Você está à frente da maioria das equipes, mas ainda tem espaço para melhorar.
  • Medium: desempenho médio. Há áreas claras de melhoria.
  • Low: abaixo da média. Essas métricas mostram onde o seu pipeline de entrega precisa de atenção.

O scorecard dá uma visão imediata: quatro cartões, quatro métricas, quatro níveis. Cada cartão mostra o valor atual, o nível de desempenho com um indicador de cor e uma breve explicação do que aquele nível significa. Você não precisa decorar os benchmarks do DORA: o scorecard interpreta os números para você.

Um nível de desempenho geral é calculado a partir da combinação das quatro métricas. Se três das suas métricas são Elite e uma é High, você está no nível Elite no geral.

Gráficos de tendência: a direção importa mais que a posição

Um retrato único das métricas DORA diz onde você está. Uma tendência diz para onde você está indo. O painel DORA inclui gráficos de tendência que mostram cada métrica ao longo do tempo, para você ver se as coisas estão melhorando, estáveis ou piorando.

Escolha um período (7 dias, 30 dias, 90 dias ou um intervalo personalizado) e o gráfico mostra a sua trajetória. A deployment frequency pode estar subindo de forma constante. O lead time pode ter disparado depois de uma grande refatoração e agora estar se recuperando. O change failure rate pode estar estável em um nível saudável.

São as tendências que transformam as métricas de ferramenta de avaliação de desempenho em ferramenta de melhoria contínua. Você não olha o DORA uma vez por trimestre para arquivar em um relatório. Você acompanha as tendências toda semana, percebe quando o lead time começa a subir e investiga antes que vire um problema.

Restritas à sua arquitetura

Como o Archyl conhece o seu modelo C4, as métricas DORA não se limitam a agregados do projeto inteiro. Você pode restringi-las a um sistema ou container específico.

Quer saber a deployment frequency só do Payment Gateway? Filtre por esse sistema. Tem curiosidade se o Notification Service tem um change failure rate maior do que a Account API? Compare os dois lado a lado.

É aqui que métricas conscientes da arquitetura se tornam úteis de verdade. Um MTTR de duas horas no projeto inteiro pode parecer ótimo, até você perceber que o API Gateway se restaura em 15 minutos e o Billing Service leva 18 horas. Métricas restritas a um elemento revelam os pontos fora da curva que as médias escondem.

Visão geral do DORA na organização

Para líderes de engenharia que gerenciam vários projetos, a visão geral do DORA no nível da organização oferece um panorama de todos os projetos do workspace.

A visão mostra uma barra de resumo com o nível de desempenho agregado e depois uma grade de cartões de projeto, cada um com as quatro métricas DORA e seus níveis individuais. Você vê na hora quais projetos estão no nível Elite e quais estão com dificuldade.

Não se trata de ranquear equipes umas contra as outras. Trata-se de identificar onde investir. Se o lead time de um projeto está subindo enquanto os outros estão estáveis, é um sinal que vale investigar. Se o change failure rate está alto em todo lugar, talvez o problema seja sistêmico: infraestrutura compartilhada, lacunas de teste ou ferramentas de deploy.

A visão da organização usa o mesmo seletor de período da visão do projeto, para que você alinhe os intervalos de tempo ao comparar projetos.

O ciclo de feedback

As métricas DORA funcionam melhor como parte de um ciclo de feedback. Veja como vimos equipes usá-las de forma eficaz:

  1. Configure o acompanhamento de releases: conecte seu pipeline de CI/CD ao Archyl via GitHub Actions, webhooks ou a API REST. As releases começam a chegar automaticamente.

  2. Estabeleça uma linha de base: depois de algumas semanas de dados, confira seu scorecard DORA. É aí que você está hoje. Não julgue, apenas anote.

  3. Acompanhe as tendências: confira toda semana. As métricas estão indo na direção certa? Estável está bom. Piorando é um sinal.

  4. Investigue as anomalias: quando uma métrica muda, restrinja-a aos sistemas individuais. Muitas vezes, uma mudança no projeto inteiro vem de um ou dois serviços.

  5. Itere: faça mudanças no seu processo de entrega e veja como as métricas respondem. Code reviews mais rápidos reduzem o lead time. Uma cobertura de testes melhor reduz o change failure rate. Feature flags reduzem o MTTR.

A principal lição da pesquisa do DORA é que essas métricas são resultados, não metas. Você não melhora a deployment frequency fazendo mais deploys: você a melhora removendo o atrito que torna o deploy lento ou arriscado. As métricas dizem se as melhorias no seu processo estão funcionando de verdade.

Ligando os pontos

As métricas DORA são a peça mais recente da abordagem do Archyl para uma documentação de arquitetura que reflete a realidade, não só a intenção.

Seus diagramas C4 mostram a estrutura. Os contratos de API mostram as interfaces. Os ADRs mostram as decisões. O Release Management mostra o que foi entregue. E agora as métricas DORA mostram quão bem a sua máquina de entrega está funcionando.

Cada camada acrescenta contexto à anterior. Um sistema no seu diagrama não é mais só uma caixa com uma seta: é um serviço com uma API definida, decisões documentadas por trás do seu design, um histórico de deploys e um desempenho de entrega mensurável. Essa é a diferença entre um diagrama e uma plataforma de arquitetura viva.

Como começar

Se você já acompanha releases no Archyl, as métricas DORA já estão disponíveis. Vá até a página Releases do seu projeto e mude para a aba Metrics. Seu scorecard e seus gráficos de tendência já estão preenchidos.

Se você ainda não configurou o acompanhamento de releases, comece por aí. Siga o guia de Release Management para conectar seu pipeline de CI/CD e volte à aba Metrics quando tiver algumas semanas de dados de deploy.

Para insights no nível da organização, abra a página Releases sem selecionar um projeto específico e mude para a aba Metrics. A visão geral vai mostrar todos os projetos do seu workspace com seus scores DORA individuais.

Sua arquitetura sabe o que existe. Suas releases sabem o que foi entregue. Agora suas métricas sabem quão bem você está entregando.

Saiba mais sobre o acompanhamento de deploys no Release Management, ou veja como as Architecture Change Requests trazem fluxos de revisão estruturados para o seu modelo C4.