As métricas DORA (DevOps Research and Assessment) são um conjunto de quatro indicadores-chave de performance (KPIs) que ajudam equipes de DevOps a medir e melhorar a entrega de software. Elas foram identificadas por Nicole Forsgren e sua equipe em pesquisas que analisaram milhares de organizações, mostrando que equipes de alto desempenho se destacam nessas métricas. Nesta aula, vamos explorar cada uma delas em detalhes: deployment frequency (frequência de deploy), lead time (tempo de espera), change failure rate (taxa de falha de mudanças) e MTTR (Mean Time to Recovery).

Dominar essas métricas permite que você identifique gargalos, otimize processos e alinhe a equipe em direção a entregas mais rápidas e confiáveis. Vamos começar!

Deployment Frequency

Deployment frequency mede com que frequência sua equipe realiza deploys para produção ou para um ambiente de staging significativo. É um indicador direto da capacidade de entrega contínua. Quanto maior a frequência, mais rápido o time consegue entregar valor aos usuários.

Para medi-la, basta contar o número de deploys bem-sucedidos em um período (ex.: por dia, semana ou mês). Equipes de alto desempenho realizam deploys múltiplas vezes ao dia, enquanto equipes de baixo desempenho podem fazer deploys mensais ou trimestrais. Ferramentas como Git, CI/CD (GitHub Actions, Jenkins) e sistemas de monitoramento (Datadog, Grafana) ajudam a registrar e extrair esses dados.

Exemplo de coleta via script bash:

#!/bin/bash
# Contar deploys de um mês (via API do GitHub)
# Supondo que tags representam deploys
count=$(git tag --list 'v*' --sort=-creatordate | wc -l)
echo "Deploys no último mês: $count"

Lead Time

Lead time é o tempo que leva desde o momento em que um commit é feito até o momento em que ele está rodando em produção (ou em um ambiente de homologação). É uma medida da velocidade do pipeline de entrega. Lead time curto significa que mudanças chegam rapidamente aos usuários.

Para calcular, você pode usar a diferença entre o timestamp do commit e o timestamp do deploy bem-sucedido. Ferramentas como Git, Jenkins e sistemas de rastreamento de releases podem fornecer esses dados. Equipes de alto desempenho têm lead time de horas ou minutos; as de baixo desempenho, semanas ou meses.

Exemplo de cálculo manual via bash:

#!/bin/bash
# Assumindo que o deploy é feito via tag
commit_time=$(git log -1 --format=%ct "v1.0.0")
deploy_time=$(date +%s)  # simulado
lead_time=$((deploy_time - commit_time))
echo "Lead time (segundos): $lead_time"

Change Failure Rate

Change failure rate mede a porcentagem de deploys que resultam em falha (ex.: incidentes, rollbacks, degradação de serviço). É um indicador de qualidade e estabilidade. Uma taxa baixa indica que as mudanças são seguras e bem testadas.

Para calcular, divida o número de deploys que causaram falhas pelo número total de deploys em um período. Equipes de alto desempenho têm taxas abaixo de 15%; as de baixo desempenho podem ter taxas acima de 30%.

Exemplo de cálculo:

#!/bin/bash
# Simulação: total_deploys=100, failed_deploys=5
failed=5
total=100
rate=$(echo "scale=2; $failed * 100 / $total" | bc)
echo "Change failure rate: $rate%"

MTTR

MTTR (Mean Time to Recovery) mede o tempo médio que a equipe leva para se recuperar de uma falha em produção. É uma métrica de resiliência e capacidade de resposta. Quanto menor o MTTR, mais rápido a equipe restaura o serviço.

Para calcular, some o tempo de duração de cada incidente (desde a detecção até a resolução) e divida pelo número de incidentes. Ferramentas de incident management (PagerDuty, Opsgenie) e monitoramento ajudam a registrar esses dados. Equipes de alto desempenho têm MTTR de horas; as de baixo desempenho, dias ou semanas.

Exemplo de cálculo com dados hipotéticos:

#!/bin/bash
# Tempos de recuperação (em horas) para 3 incidentes: 2, 3, 5
tempos=(2 3 5)
soma=0
for t in "${tempos[@]}"; do
  soma=$((soma + t))
done
mttr=$(echo "scale=2; $soma / ${#tempos[@]}" | bc)
echo "MTTR (horas): $mttr"

Referências

Exercícios

  1. Explique com suas palavras o que significa deployment frequency e por que ela é importante para equipes de DevOps.

    ✓ Resposta: Deployment frequency é a frequência com que uma equipe realiza deploys para produção. Ela é importante porque indica a capacidade de entregar valor rapidamente aos usuários, permitindo feedback mais rápido e menor risco de grandes releases. Equipes com alta frequência de deploy tendem a ter processos mais automatizados e maduros.

  2. Calcule o lead time para um commit feito em 01/01/2023 10:00:00 UTC e um deploy em 02/01/2023 14:30:00 UTC. Expresse o resultado em horas.

    ✓ Resposta: Diferença entre 01/01/2023 10:00 UTC e 02/01/2023 14:30 UTC = 28 horas e 30 minutos = 28,5 horas.

  3. Uma equipe realizou 50 deploys no mês, dos quais 8 resultaram em incidentes. Qual é a change failure rate?

    ✓ Resposta: Change failure rate = (8 / 50) * 100 = 16%.

  4. Se três incidentes tiveram durações de 2h, 4h e 6h, qual é o MTTR?

    ✓ Resposta: MTTR = (2 + 4 + 6) / 3 = 12 / 3 = 4 horas.

  5. Cite duas ações práticas que uma equipe pode tomar para melhorar o lead time.

    ✓ Resposta: Duas ações: (1) Automatizar testes e builds para reduzir o tempo de validação; (2) Implementar deploys incrementais e feature flags para permitir entregas parciais sem depender de grandes releases.

Boas Práticas

Ao implementar as métricas DORA, lembre-se de que elas são complementares. Focar apenas em deployment frequency pode levar a mudanças arriscadas; já um lead time curto sem controle de qualidade pode aumentar a change failure rate. O ideal é buscar um equilíbrio: deploys frequentes, lead time curto, baixa taxa de falhas e MTTR reduzido. Use dashboards para visualizar essas métricas e promova discussões em retrospectivas para identificar áreas de melhoria.