Perguntar a um líder de engenharia como está a performance do time costuma produzir respostas positivas, mas nem sempre acompanhadas de dados que permitam entender o que está acontecendo de fato. Quando a conversa avança para questões como frequência de deploy, tempo entre um commit e a entrada em produção ou taxa de falha das mudanças, muitas organizações percebem que ainda não têm uma visão consistente desses indicadores.

As métricas DORA foram desenvolvidas justamente para estruturar essa leitura. O programa DevOps Research and Assessment, hoje parte do Google Cloud, consolidou ao longo de anos de pesquisa um conjunto de indicadores para avaliar a capacidade de entrega de software. As quatro métricas tradicionalmente conhecidas como as Four Keys permitem observar dois aspectos que precisam evoluir juntos: velocidade de entrega e estabilidade da operação.

Esse acompanhamento ajuda a substituir percepções isoladas por uma visão baseada no comportamento real do processo de entrega. Para uma área de engenharia, isso significa entender onde o fluxo está funcionando bem, onde existem gargalos e quais mudanças podem gerar impacto efetivo.

As quatro métricas DORA

O valor das métricas está principalmente na combinação. Uma frequência maior de deploy, isoladamente, não significa uma operação mais madura. O ganho aparece quando a organização consegue aumentar a velocidade sem provocar crescimento proporcional nas falhas e, quando elas acontecem, consegue reduzir o tempo de recuperação.

Vale também registrar uma atualização importante: o modelo DORA evoluiu ao longo do tempo e hoje trabalha com cinco métricas. Este artigo mantém as quatro métricas tradicionalmente utilizadas nas Four Keys porque elas formam a base da discussão apresentada aqui, mas a nomenclatura e os indicadores devem ser considerados conforme a versão mais recente da pesquisa.

O que esses indicadores mostram para a liderança?

Para a liderança, as métricas ganham importância quando deixam de ser vistas apenas como indicadores técnicos e passam a ajudar na compreensão da capacidade de entrega da organização. 

Uma frequência baixa de deploy pode indicar que existe uma dependência excessiva de processos manuais ou de validações fora do pipeline. Um lead time elevado pode revelar gargalos em revisão, testes, aprovação ou infraestrutura. Uma taxa de falha alta aponta para riscos no processo de mudança, enquanto um tempo de recuperação elevado pode indicar limitações de observabilidade, automação ou conhecimento operacional.

• Deploy Frequency: Mostra com que frequência a organização consegue transformar trabalho de engenharia em mudanças disponíveis para o negócio.

• Lead Time for Changes: Ajuda a identificar quanto tempo uma mudança permanece parada entre desenvolvimento, validação e produção.

• Change Failure Rate: Permite dimensionar a estabilidade das mudanças e o esforço que retorna para a operação na forma de incidentes e correções.

• MTTR / tempo de recuperação: Ajuda a avaliar a exposição operacional durante incidentes e a capacidade do time de restaurar o serviço.

 

O objetivo não é transformar esses números em uma competição entre equipes. O contexto de cada operação importa, e comparar diretamente times que trabalham com arquiteturas, produtos e restrições diferentes pode levar a conclusões equivocadas. A evolução ao longo do tempo dentro do próprio ambiente costuma ser uma referência mais útil.

Como interpretar os níveis de performance? 

As pesquisas DORA historicamente organizaram os resultados em níveis de performance para facilitar a leitura da maturidade dos times. As faixas variam conforme a edição do relatório e não devem ser tratadas como metas universais. O mais importante é identificar a posição atual, entender os fatores que explicam esse resultado e acompanhar a evolução.

Métrica	Elite	Alto	Médio	Baixo
Deploy Frequency	Múltiplos por dia	De 1 vez por dia a 1 vez por semana	De 1 vez por semana a 1 vez por mês	De 1 vez por mês a 1 vez por semestre
Lead Time for Changes	Menos de 1 hora	De 1 dia a 1 semana	De 1 semana a 1 mês	De 1 a 6 meses
Change Failure Rate	0–5%	5–10%	10–15%	Faixas superiores, conforme a edição do relatório
MTTR / tempo de recuperação	Menos de 1 hora	Menos de 1 dia	De 1 dia a 1 semana	Mais de 6 meses

 

Os erros mais comuns na adoção de DORA

A coleta das métricas é apenas o início. O modo como elas são utilizadas determina se o acompanhamento vai gerar aprendizado ou apenas mais um painel de indicadores.

Um dos erros mais comuns é usar as métricas para punir ou avaliar individualmente os times. Quando isso acontece, a equipe pode passar a otimizar o número em vez do processo, criando comportamentos artificiais, como agrupar mudanças para reduzir a frequência de deploy ou alterar a forma de registrar falhas. DORA funciona melhor como instrumento de diagnóstico do sistema de entrega, ajudando a identificar onde existem gargalos e quais mudanças podem melhorar o fluxo.

Também é importante evitar a busca por velocidade sem considerar a estabilidade. Aumentar a frequência de deploy não representa necessariamente uma evolução se, ao mesmo tempo, cresce o número de falhas e o esforço necessário para recuperar o ambiente. As métricas precisam ser analisadas em conjunto, considerando o equilíbrio entre velocidade de entrega e estabilidade operacional.

Outro problema é medir sem agir. Ter dados sobre lead time ou change failure rate não produz melhoria por si só. Quando um indicador permanece em um nível desfavorável, é necessário investigar as causas, formular hipóteses e testar mudanças que possam atuar sobre o gargalo identificado. A métrica deve fazer parte de um ciclo de melhoria, e não apenas de um relatório periódico.

A comparação entre times também exige cuidado. Equipes que trabalham com produtos, arquiteturas e restrições diferentes não necessariamente podem ser avaliadas pelas mesmas referências. Nesse contexto, acompanhar a evolução da própria operação ao longo do tempo costuma ser mais útil do que estabelecer um ranking entre equipes. Os resultados precisam ser interpretados considerando o contexto em que cada time trabalha.

Por fim, um ponto que muitas vezes fica fora da discussão é o banco de dados. Uma aplicação pode atravessar rapidamente as etapas do pipeline e ainda assim depender de processos manuais para alterações de schema, validações ou rollback. Quando isso acontece, parte do fluxo de entrega continua sujeita a filas e intervenções externas. Práticas como Database CI/CD, versionamento das mudanças, revisão e estratégias de rollback ajudam a levar a mesma disciplina de automação e rastreabilidade para essa etapa do processo.

Como começar e ver resultados em 90 dias?

A adoção de DORA não precisa começar com uma transformação completa da operação. O primeiro passo é criar uma linha de base confiável e, a partir dela, identificar quais pontos do fluxo merecem atenção. Um roteiro inicial de 90 dias pode ser organizado em quatro etapas.

Período	Principais ações	Resultado esperado
Dias 1–30: Instrumentação	Definir o que será considerado deploy e falha e automatizar a coleta a partir dos eventos de CI/CD, observabilidade e registro de incidentes.	Linha de base das métricas e critérios consistentes de medição.
Dias 31–60: Diagnóstico	Identificar o nível atual, localizar gargalos em revisão, testes, deploy, recuperação e dependências externas.	Mapa priorizado de gargalos e hipóteses de melhoria.
Dias 61–90: Experimentação	Escolher o gargalo de maior impacto, testar uma mudança em escopo controlado e medir o efeito.	Evidência sobre quais mudanças produzem melhoria.
A partir do dia 91: Evolução	Incorporar a análise das métricas ao ritmo de engenharia e acompanhar tendências ao longo do tempo.	Ciclo contínuo de melhoria orientado por dados.

Entre as iniciativas que podem surgir desse diagnóstico estão a adoção de trunk-based development para reduzir o tempo de integração, o uso de feature flags para separar deploy de release, melhorias de automação no pipeline e exercícios controlados para validar a capacidade real de recuperação. A escolha depende do gargalo identificado, e não de uma lista fixa de práticas.

Como a MarkWay atua nesse contexto

A MarkWay apoia organizações na evolução de suas práticas DevOps a partir de uma análise do fluxo de entrega e dos principais gargalos da operação. O trabalho pode envolver CI/CD, automação, infraestrutura como código, observabilidade, Platform Engineering e integração entre desenvolvimento, infraestrutura e dados, sempre de acordo com as necessidades do ambiente.

Se você quer entender como está a capacidade de entrega da sua operação e quais pontos devem ser priorizados, a MarkWay pode ajudar a estabelecer essa linha de base e transformar os dados em um plano de evolução.

Fale com a MarkWay e avalie o nível de maturidade do seu ambiente DevOps.