# O que são métricas DORA e como usá-las em sua equipe

URL: https://upstreamapi.com/pt/journal/o-que-sao-metricas-dora
Type: blog
Locale: pt
Published: 2026-10-03
Updated: 2026-10-03

---

> As cinco métricas DORA (mudança, frequência, recuperação, falha, retrabalho) substituem anedotas por números. Bem usadas, apontam gargalos; mal usadas, viram placar que a equipe maqueia.

## O que são métricas DORA?

São cinco medidas da entrega de software: tempo de mudança, frequência de implantação, tempo de recuperação, taxa de falha de mudança e taxa de retrabalho de implantação. As três primeiras descrevem throughput, as duas últimas descrevem instabilidade. Juntas, elas dizem a que velocidade as mudanças chegam à produção e com que frequência essas mudanças causam danos. Bem usadas, apontam o gargalo. Mal usadas, viram um boletim de desempenho que a equipe aprende a maquiar.

## De onde vêm os números e por que o vocabulário pegou

Um tech lead senta numa reunião trimestral. O CTO faz uma pergunta: estamos shipper mais rápido que no ano passado, e estamos quebrando menos? Sem um vocabulário compartilhado, a resposta é uma pilha de anedotas. As métricas DORA existem para substituir os relatos por quatro ou cinco números que você consegue extrair dos sistemas que já executa.

O nome vem de DevOps Research and Assessment, o programa de pesquisa que passou anos pesquisando equipes de engenharia e correlacionando suas práticas de entrega com resultados organizacionais. Agora faz parte do Google Cloud, e os achados são publicados anualmente no [programa de pesquisa DORA](https://dora.dev/research/). O livro Accelerate popularizou os quatro originais. O framework foi revisado desde então, e essa revisão importa mais do que a maioria dos posts admite.

Aqui está a parte que se perde: as métricas nunca foram pensadas como placar de ranking. Saíram de um achado estatístico. Equipes que pontuavam bem em velocidade também pontuavam bem em estabilidade. Velocidade e segurança não eram uma troca, andavam juntas. Esse é um afirmação sobre correlação entre muitas equipes, não um alvo para a sua.

## Os cinco métricas, definidos do jeito que um on-call engineer definiria

As definições atuais no [guia oficial de métricas DORA](https://dora.dev/guides/dora-metrics/) se dividem em dois grupos. Leia-os com um serviço específico em mente, porque toda definição desmorona se você a aplica para "a empresa".

**Tempo de mudança.** O tempo de um commit até esse commit rodando em produção. Não do ticket sendo aberto, e não do pull request sendo aprovado. Do commit até prod. Se seu pipeline leva quarenta minutos e seu release train sai nas quintas-feiras, seu tempo de mudança é dominado pela quinta-feira.

**Frequência de implantação.** Com que frequência você coloca em produção. Você pode contar implantações ao longo de um período ou medir a brecha entre elas. Um serviço que implanta onze vezes ao dia e um serviço que implanta uma vez por mês são animais diferentes, e fazer a média deles esconde ambos.

**Tempo de recuperação de implantação com falha.** Quanto tempo leva para recuperar-se quando uma implantação causa um problema que precisa de intervenção. Isso costumava chamar-se mean time to restore, e a renomeação é deliberada. Só conta incidentes causados por sua própria mudança, não uma falha do provedor de nuvem numa terça-feira.

**Taxa de falha de mudança.** A parcela de implantações que precisam de intervenção imediata depois: um rollback, um hotfix, um forward fix aplicado rápido. Dez implantações, duas delas revertidas, taxa de falha de mudança de vinte por cento.

**Taxa de retrabalho de implantação.** A parcela de implantações que são não planejadas, acionadas por um incidente em produção em vez de trabalho roadmap. Essa é a adição mais recente, e captura algo que taxa de falha de mudança não consegue: a equipe que nunca faz rollback mas passa metade da semana shipper patches de emergência.

![Cronômetro em um painel de rack de servidor, um retrato do tempo de mudança](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/02c796-i1.webp)

## Throughput versus instabilidade: por que você nunca lê uma métrica sozinha

Os três primeiros métricas são throughput. Os dois últimos são instabilidade. O agrupamento é o ponto inteiro.

Se você só observa throughput, vai comemorar uma equipe que implanta quarenta vezes ao dia e silenciosamente reverte um quarto delas. Se você só observa instabilidade, vai recompensar uma equipe que coloca em produção uma vez por mês com um registro impecável, porque ninguém muda nada. Todo métrica tem um jeito barato de melhorá-lo que torna o sistema pior.

A frequência de implantação sobe quando você divide uma implantação em cinco implantações vazias. A taxa de falha de mudança desce quando você para de contar hotfixes como falhas. O tempo de mudança encolhe quando você redefine o início do relógio. Isso é a lei de Goodhart fazendo o que sempre faz: quando uma medida vira um alvo, ela para de ser uma boa medida. O guia oficial lista isso primeiro entre seus avisos, e é o que mais morde.

Então a regra operacional é pares. Leia tempo de mudança ao lado de taxa de falha de mudança. Leia frequência de implantação ao lado de taxa de retrabalho. Um movimento numa direção sem uma história correspondente na outra é um sinal para olhar mais de perto, não uma vitória para anunciar.

Benchmarks circulam em todo deck de vendor, e são uma armadilha. O padrão relatado em relatórios DORA recentes é consistente em forma: o cluster mais forte de equipes implanta sob demanda, com tempo de mudança sob um dia, e recupera-se de uma implantação com falha em menos de uma hora. O cluster mais lento fica na faixa de semanas até meses em ambos.

Esses números são úteis para uma coisa: calibrando sua intuição sobre o que é possível. São fracos como alvos. Um serviço de pagamentos com um portão de auditoria obrigatório não vai combinar com um site de marketing, e não deveria tentar. A orientação oficial é explícita de que você deveria comparar apenas aplicações ou serviços similares, e que deveria apontar para melhoria contra sua própria baseline em vez de competição entre equipes.

Comece com sua mediana. Meça por um mês antes de estabelecer um alvo. O primeiro número quase sempre é constrangedor, e está tudo bem. Uma baseline que constrange você é uma baseline que você realmente confia.

## Como instrumentá-los sem construir uma plataforma de dados

A maioria das equipes constrói demais isso. Você não precisa de um warehouse. Você precisa de quatro timestamps e uma flag.

Os timestamps: commit merged na main branch, build finalizado, implantação iniciada em produção, implantação finalizada. A flag: se a implantação foi depois revertida, hotfixada, ou seguida por uma implantação não planejada dentro de uma janela definida.

Aqui está um esboço mínimo em TypeScript. Ele pega uma lista de registros de implantação e retorna os números que importam.

`type Deploy = {
  service: string;
  committedAt: Date;
  deployedAt: Date;
  failed: boolean;       // reverted, hotfixed, or manual intervention
  unplanned: boolean;    // triggered by an incident, not by roadmap work
  recoveredAt?: Date;    // set when failed is true
};

const median = (xs: number[]) => {
  const s = [...xs].sort((a, b) => a - b);
  return s.length ? s[Math.floor(s.length / 2)] : 0;
};

export function doraSummary(deploys: Deploy[], days: number) {
  const leadHours = deploys.map(
    d => (d.deployedAt.getTime() - d.committedAt.getTime()) / 36e5,
  );
  const failures = deploys.filter(d => d.failed);
  const recoveryMins = failures
    .filter(d => d.recoveredAt)
    .map(d => (d.recoveredAt!.getTime() - d.deployedAt.getTime()) / 6e4);

  return {
    leadTimeHoursP50: median(leadHours),
    deploysPerDay: deploys.length / days,
    changeFailRate: failures.length / Math.max(deploys.length, 1),
    recoveryMinutesP50: median(recoveryMins),
    reworkRate: deploys.filter(d => d.unplanned).length / Math.max(deploys.length, 1),
  };
}`Duas decisões naquele snippet carregam o peso. Primeiro, usa a mediana, não a média. Uma semana ruim com uma recuperação de três dias vai estragar uma média e não diz nada sobre uma terça-feira típica. Segundo, calcula tudo por serviço. Agregue para um time ou um departamento só depois de ter olhado os serviços por baixo.

A parte difícil não é o código. A parte difícil é a flag `failed`. Alguém tem que decidir o que conta como uma falha, escrever em algum lugar, e aplicar da mesma forma toda vez. Se seu incident tracker liga incidentes à implantação que os causou, você consegue isso quase de graça. Se não liga, comece lá.

![Painel de disjuntor industrial com uma alavanca vermelha puxada, um retrato de uma mudança com falha](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/f8caad-i2.webp)

A questão de ferramentas vem depois da questão de dados. Você já possui a maioria dos dados brutos. Seu Git host tem tempos de commit. Seu CI tem eventos de build e implantação. Sua ferramenta de incidentes tem as falhas. O trabalho é ligá-los num identificador compartilhado de implantação.

Plataformas de observabilidade são um lugar natural para sobrepor marcadores de implantação em cima de taxas de erro e latência, para que você veja qual implantação precedeu qual spike.

Se você prefere manter a stack aberta e self-hosted, uma camada de dashboard sobre seu próprio banco de dados de eventos de implantação faz o mesmo trabalho a custo menor, com mais encanamento do seu lado.

Existe também uma categoria de ferramentas que lê seus repositórios e histórico de entrega e torna visível o risco, como pontos quentes onde mudança de código e defeitos passados se aglomeram. Não vai substituir os quatro timestamps, mas explica por que um serviço tem taxa de falha de mudança alta quando seus vizinhos não têm.

Uma cautela sobre comprar nada aqui. Um dashboard que mostra os números não é a mesma coisa que uma equipe que age sobre eles. Se ninguém é dono do gráfico de tempo de recuperação, comprar um gráfico mais bonito não muda nada.

## Os alavancas que realmente movem cada número

Métricas são um diagnóstico. O tratamento está em outro lugar, e é diferente para cada um.

Para tempo de mudança, olhe para espera, não para trabalho. Pegue uma dúzia de mudanças recentes e marque onde cada uma ficou ociosa: esperando revisão, esperando slot de build, esperando janela de release. Na maioria das equipes o tempo ocioso supera o tempo de codificação várias vezes. Pull requests menores e uma expectativa de nível de serviço de revisão vencem qualquer tuning de pipeline.

Para frequência de implantação, a alavanca é tamanho de batch. Mudanças menores são mais fáceis de revisar, mais fáceis de raciocinar, e mais fáceis de reverter. Desenvolvimento trunk-based e feature flags existem para deixar você fazer merge de trabalho inacabado com segurança, que é como você desacopla deployment de release.

Para taxa de falha de mudança, a alavanca é quanto do blast radius você consegue ver antes que seja a frota inteira. Um rollout que expõe um por cento do traffic, observa uma taxa de erro contra um SLO, e para numa violação transforma um seria-sido-incidente num não-evento. Essa é a lacuna entre uma implantação com falha e uma mudança com falha que ninguém fora da equipe percebeu.

Para tempo de recuperação, a alavanca é o revert. Se o fix mais rápido é rollback, então tempo de recuperação é como rapidamente você detecta o problema mais como rapidamente você consegue apertar o botão. Automatizar o revert num limiar de violação tira o humano dos primeiros dez minutos. Às 3 da manhã isso importa mais que qualquer runbook.

Para taxa de retrabalho, a alavanca é upstream. Um número alto quer dizer incidentes geram implantações. Olhe quais serviços produzem os patches de emergência, e leia seus post-mortems como um conjunto em vez de um por um.

## O que muda quando IA escreve mais do seu código

A pesquisa DORA recente aponta para algo desconfortável para qualquer um vendendo um assistente de codificação. Assistentes aceleram tarefas de baixo nível, mas os ganhos não chegaram claramente a tempo de mudança ou taxa de falha de mudança. Mais código escrito por hora não é a mesma coisa que mais valor entregue por semana.

Se algo, um volume maior de mudanças geradas empurra pressão para revisão e para seu pipeline de entrega. Batches maiores prejudicam estabilidade, e capacidade de revisão não escala com velocidade de digitação. Observe sua taxa de falha de mudança e taxa de retrabalho nos meses depois que um time adota um assistente. Se tempo de mudança cai mas retrabalho sobe, você não ficou mais rápido, você moveu o custo.

![Notebook com gráficos de tendência desenhados à mão para uma retrospectiva de time](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/30e093-i3.webp)

## Como usá-los numa retro sem quebrar seu time

Aqui está o que funciona na prática. Coloque as linhas de tendência na tela pelo último trimestre e faça uma pergunta: o que mudou aqui, e por quê? Não pergunte quem. O alvo é uma hipótese sobre o sistema, não um veredito sobre uma pessoa.

Três hábitos mantêm os números honestos.

Primeiro, nunca coloque em revisões de desempenho individual. No momento que uma métrica se liga a um nome, pessoas otimizam a métrica, e seus dados param de descrever realidade.

Segundo, empareque todo número com uma história. Um spike em tempo de recuperação é um incidente com um nome e um post-mortem. Leia o post-mortem antes de ler o gráfico.

Terceiro, mude uma coisa por vez. Se você adota feature flags, encolhe pull requests, e automatiza reverts no mesmo mês, você nunca vai aprender qual moveu a agulha.

Pule o slide de modelo de maturidade que classifica sua org em tiers e distribui um troféu. Vale a pena em vez: uma página única por serviço, atualizada mensalmente, listando os cinco números, o valor do mês anterior, e uma frase sobre o que mudou.

Suponha que você tinha noventa dias de dados limpos num serviço, e viu a taxa de falha de mudança subindo enquanto frequência de implantação ficava plana. Onde procuraria primeiro: o tamanho das mudanças, a qualidade da revisão, ou a visibilidade que você tem num rollout enquanto ele ainda é pequeno? Sua resposta diz mais sobre seu sistema de entrega que qualquer benchmark faz.

## FAQ

### Qual é a diferença entre tempo de mudança e frequência de implantação?

Tempo de mudança mede quanto tempo leva para um commit chegara à produção. Frequência de implantação mede com que frequência você faz deploy. Uma equipe pode ter frequência alta mas tempo de mudança longo se as implantações esperarem em filas.

### Por que não comparar minhas métricas com benchmarks de outras empresas?

Cada serviço tem contextos diferentes. Um serviço de pagamentos com portão de auditoria não deve ser comparado com um site de marketing. O importante é melhorar contra sua própria baseline, não contra competidores.

### Como começar a medir métricas DORA se não tenho uma plataforma de observabilidade?

Você precisa de apenas quatro timestamps (commit merged, build finished, deploy started, deploy finished) e uma flag para falhas. Isso você já tem espalhado entre Git, CI, e incident tracker. O trabalho é juntá-los.

### O que significa uma taxa de falha de mudança alta?

Significa que uma parcela grande das implantações precisa de rollback ou hotfix depois. Pode indicar problemas em revisão, testes, ou tamanho das mudanças. Leia junto com tempo de recuperação para entender o impacto.

### Devo usar métricas DORA em avaliações de desempenho individual?

Não. No momento em que uma métrica vira alvo de desempenho, as pessoas otimizam a métrica, não o sistema. Use para diagnóstico de equipe, não para avaliar pessoas.