As métricas DORA (DevOps Research and Assessment) são um conjunto de quatro indicadores-chave que ajudam a medir a eficácia das práticas DevOps em uma organização. Elas foram identificadas pelo time de pesquisa do Google Cloud e são amplamente utilizadas para avaliar a performance de entrega de software. Compreender e monitorar essas métricas permite que equipes identifiquem gargalos, melhorem a velocidade e a estabilidade das entregas e, consequentemente, aumentem a satisfação do cliente.

Nesta aula, vamos explorar cada uma das quatro métricas: Deployment Frequency, Lead Time, Change Failure Rate e MTTR. Para cada uma, veremos definição, como calcular, boas práticas e exemplos práticos de coleta usando scripts bash.

Deployment Frequency

Deployment Frequency (frequência de deploy) mede quantas vezes uma equipe realiza deployments em produção em um determinado período (geralmente por dia, semana ou mês). Essa métrica reflete a capacidade da equipe de entregar novas funcionalidades, correções e atualizações de forma contínua. Quanto maior a frequência, mais ágil é o time.

Para calcular, basta contar o número de deployments bem-sucedidos em um intervalo. Por exemplo, se uma equipe faz 10 deploys por semana, a frequência é 10/semana. O DORA classifica as equipes em quatro níveis: Elite (múltiplos deploys por dia), Alto (semanal a mensal), Médio (mensal a semestral) e Baixo (semestral a anual).

Exemplo de script bash para contar deploys a partir de logs:

#!/bin/bash
# Conta deploys bem-sucedidos na última semana
kubectl get events --field-selector reason=SuccessfulCreate --since=168h | wc -l

Lead Time

Lead Time mede o tempo decorrido desde o commit do código até o deploy em produção. É uma métrica de velocidade que indica o quão rápido uma mudança chega ao usuário final. Lead time curto significa que a equipe consegue validar e entregar alterações rapidamente.

O cálculo pode ser feito rastreando o timestamp do commit e o timestamp do deploy. Exemplo: se um commit foi feito em 01/01/2024 10:00 e o deploy ocorreu em 02/01/2024 14:00, o lead time é de 28 horas. Níveis DORA: Elite (menos de 1 hora), Alto (1 dia a 1 semana), Médio (1 semana a 1 mês), Baixo (mais de 1 mês).

Script para extrair lead time médio via git e logs:

#!/bin/bash
# Calcula lead time médio para os últimos 10 commits
git log --oneline -10 | while read commit; do
  commit_hash=$(echo $commit | awk '{print $1}')
  commit_time=$(git show -s --format=%ct $commit_hash)
  # Supondo que o deploy time esteja em um arquivo deploy.log
  deploy_time=$(grep $commit_hash deploy.log | awk '{print $2}')
  if [ -n "$deploy_time" ]; then
    lead_time=$((deploy_time - commit_time))
    echo "Lead time para $commit_hash: $lead_time segundos"
  fi
done

Change Failure Rate

Change Failure Rate (taxa de falha de mudanças) mede a porcentagem de deployments que resultam em falha em produção, como incidentes, degradação de serviço ou rollbacks. Uma taxa baixa indica que as mudanças são seguras e bem testadas.

Para calcular, divida o número de deployments que causaram falhas pelo total de deployments em um período. Por exemplo, se em 100 deploys, 5 causaram incidentes, a taxa é 5%. Níveis DORA: Elite (0-15%), Alto (16-30%), Médio (31-45%), Baixo (>45%).

Script para calcular a taxa a partir de logs de incidentes:

#!/bin/bash
# Calcula change failure rate no último mês
total_deploys=$(kubectl get events --field-selector reason=SuccessfulCreate --since=720h | wc -l)
failed_deploys=$(grep -c "incident" /var/log/incidents.log)
if [ $total_deploys -gt 0 ]; then
  rate=$(echo "scale=2; $failed_deploys * 100 / $total_deploys" | bc)
  echo "Change Failure Rate: $rate%"
else
  echo "Nenhum deploy no período"
fi

MTTR

MTTR (Mean Time to Recover) mede o tempo médio necessário para restaurar o serviço após uma falha. Inclui detecção, diagnóstico e correção. Quanto menor o MTTR, mais resiliente é o sistema.

Para calcular, some o tempo de recuperação de todos os incidentes e divida pelo número de incidentes. Exemplo: se três incidentes levaram 10, 20 e 30 minutos, o MTTR é (10+20+30)/3 = 20 minutos. Níveis DORA: Elite (menos de 1 hora), Alto (1 a 24 horas), Médio (1 a 7 dias), Baixo (>7 dias).

Script para calcular MTTR a partir de logs de incidentes:

#!/bin/bash
# Calcula MTTR para incidentes no último mês
# Assume que o log tem formato: timestamp_inicio timestamp_fim
total=0
count=0
while read inicio fim; do
  duracao=$((fim - inicio))
  total=$((total + duracao))
  count=$((count + 1))
done < /var/log/incident_times.log
if [ $count -gt 0 ]; then
  mttr=$((total / count))
  echo "MTTR: $mttr segundos"
else
  echo "Nenhum incidente"
fi

Boas Práticas e Observações Finais

É importante coletar essas métricas de forma consistente e automatizada. Ferramentas como GitLab, GitHub Actions, Jenkins, Prometheus e Grafana podem ajudar a gerar dashboards. Além disso, as métricas devem ser interpretadas em conjunto: uma alta frequência de deploys com alta taxa de falha pode indicar problemas de qualidade. Busque sempre o equilíbrio entre velocidade e estabilidade.

Lembre-se de que as métricas DORA são um meio, não um fim. O objetivo é melhorar a entrega de valor ao cliente, não apenas atingir números. Use os dados para guiar discussões e experimentos, não para punir times.

Referências

Exercícios

  1. Explique o que é Deployment Frequency e por que ela é importante para equipes DevOps.

    ✓ Resposta: Deployment Frequency é a frequência com que uma equipe realiza deployments em produção. Ela é importante porque indica a agilidade da equipe em entregar valor ao cliente. Alta frequência geralmente está associada a processos mais enxutos e automatizados, permitindo feedback rápido e iterações curtas.

  2. Dado um commit feito em 15/03/2025 08:00 e um deploy em 16/03/2025 10:00, calcule o lead time em horas.

    ✓ Resposta: Lead time = 26 horas (de 08:00 do dia 15 até 08:00 do dia 16 são 24 horas, mais 2 horas até 10:00, totalizando 26 horas).

  3. Em um mês, uma equipe realizou 50 deploys, dos quais 8 causaram incidentes. Qual é a Change Failure Rate?

    ✓ Resposta: Change Failure Rate = (8/50)*100 = 16%.

  4. Liste três ações que podem ajudar a reduzir o MTTR.

    ✓ Resposta: 1) Implementar monitoramento e alertas automatizados para detecção rápida de falhas. 2) Ter runbooks e playbooks bem documentados para procedimentos de recuperação. 3) Utilizar infraestrutura imutável e rollbacks automatizados para restaurar rapidamente o serviço.

  5. Escreva um script bash que colete a Deployment Frequency diária de um serviço Kubernetes, contando o número de deployments bem-sucedidos no dia atual.

    ✓ Resposta:
    #!/bin/bash
# Conta deploys bem-sucedidos no dia atual
kubectl get events --field-selector reason=SuccessfulCreate --since=24h | wc -l