DORA Metrics: saiba como medir

As DORA Metrics (Deployment Frequency, Lead Time for Changes, Change Failure Rate e Mean Time to Recovery) são fundamentais para avaliar a eficiência de equipes de desenvolvimento de software. Desenvolvidas pela equipe de pesquisa do DevOps Research and Assessment (DORA), essas métricas oferecem insights valiosos sobre o desempenho e a qualidade das entregas de software. Neste contexto, vamos te ajudar a entender como medir cada uma dessas métricas, o que é considerado baixa, média e alta performance, e exemplos práticos de cálculo.

Deployment Frequency

Deployment Frequency mede a frequência com que a equipe entrega código em produção. Essa métrica é crucial para entender a agilidade e a capacidade de uma equipe em lançar novas funcionalidades e corrigir bugs rapidamente.

Como calcular o Deployment Frequency?

Para calcular o Deployment Frequency, você precisa saber o número total de deploys realizados durante um período específico e depois dividir esse número pela quantidade de dias no período considerado. Para isso:

1. Defina o período (ex.: uma semana).
2. Conte o número de deploys durante esse período.
3. Divida o número de deploys pelo número de dias no período.

Se, por exemplo, sua equipe fez 20 deploys em 10 dias, a frequência seria 2 deploys por dia.

Padrões de mercado segundo o State of DevOps

• Baixa Performance: Menos de uma vez por mês. Isso indica que a equipe tem um processo de desenvolvimento lento, possivelmente devido a processos manuais, falta de automação ou outros gargalos significativos.
• Média Performance: Entre uma vez por mês e uma vez por semana. A equipe tem um ritmo razoável, mas ainda há espaço para melhorias na automação e na eficiência do pipeline.
• Alta Performance: Pelo menos uma vez por semana. Isso reflete uma equipe altamente eficiente, com processos automatizados e um pipeline de CI/CD robusto.

Vamos considerar uma mudança que começou com um commit inicial em 1º de janeiro. O Pull Request foi aberto em 2 de janeiro, aprovado e mergeado em 5 de janeiro, e a mudança foi implantada em produção no mesmo dia. Assim, o cálculo seria:

• Primeiro commit: 1º de janeiro
• Deploy em produção: 5 de janeiro
• Lead Time for Changes: 5 – 1 = 4 dias

Benchmark de Mercado

• Baixa Performance: Mais de um mês. Isso sugere que há muitos gargalos no processo de desenvolvimento, desde a codificação até a implantação.
• Média Performance: Entre uma semana e um mês. A equipe está razoavelmente eficiente, mas pode beneficiar-se de melhorias nos processos de revisão de código e testes.
• Alta Performance: Menos de uma semana. Reflete uma equipe ágil com processos eficientes e bem integrados, permitindo entregas rápidas.

Change Failure Rate

O Change Failure Rate mede a proporção de mudanças em produção que resultam em falhas, como bugs, rollback ou incidentes que requerem intervenção.

Como calcular o Change Failure Rate?

Calcular o Change Failure Rate envolve identificar e contar o número de deploys falhos e dividi-los pelo número total de deploys. Isso fornece uma visão clara da qualidade das mudanças implementadas e da eficiência dos processos de testes e revisão de código.

Passo a Passo para Medir o Change Failure Rate:

1. Defina o Período de Medição: Escolha o período para o qual você deseja medir a taxa de falhas. Pode ser diário, semanal, mensal, ou qualquer outro intervalo que faça sentido para a sua equipe.
2. Colete Dados de Deploys: Utilize ferramentas de CI/CD para registrar todos os deploys realizados no período definido. Essas ferramentas ajudam a manter um histórico detalhado de todas as implantações.
3. Identifique Deploys Falhos: Analise os logs e registros para identificar quais deploys resultaram em falhas. Uma falha pode ser definida como qualquer implantação que necessitou de rollback, correções urgentes ou gerou incidentes.
4. Calcule a Taxa de Falhas: Divida o número de deploys falhos pelo número total de deploys e multiplique por 100 para obter a porcentagem.

Agora, pense em um cenário onde sua equipe realizou 20 deploys em um mês e 3 deles resultaram em falhas. O cálculo seria:

• Total de deploys: 20
• Deploys falhos: 3
• Change Failure Rate = (3 / 20) * 100 = 15%

Benchmark de Mercado

• Baixa Performance: Mais de 15%. Isso indica problemas significativos na qualidade do código e nos processos de teste, resultando em frequentes problemas em produção.
• Média Performance: Entre 5% e 15%. A equipe tem uma taxa aceitável de falhas, mas ainda precisa melhorar a qualidade do código e a eficácia dos testes.
• Alta Performance: Menos de 5%. Reflete uma equipe com excelentes práticas de QA, testes automatizados robustos e um processo de revisão de código eficaz.

Mean Time to Recovery (MTTR)

O MTTR mede o tempo médio que a equipe leva para restaurar o serviço após uma falha em produção. Essa métrica é crucial para avaliar a capacidade de resposta e resiliência da equipe.

Como calcular o MTTR?

Calcular o Mean Time to Recovery envolve rastrear o tempo que leva para resolver incidentes de produção, desde a detecção até a resolução. Essa métrica ajuda a avaliar a eficácia dos processos de recuperação e a prontidão da equipe em lidar com falhas.

Passo a Passo para Medir o Mean Time to Recovery:

1. Defina o Período de Medição: Escolha o período durante o qual você deseja medir o MTTR. Isso pode ser diário, semanal, mensal ou qualquer outro intervalo que faça sentido para a sua equipe.
2. Colete Dados de Incidentes: Utilize ferramentas de monitoramento e gestão de incidentes como PagerDuty, Datadog, Splunk, ou New Relic para registrar cada incidente de produção. Esses registros devem incluir o timestamp de detecção e o timestamp de resolução de cada incidente.
3. Registre Tempos de Recuperação: Para cada incidente, registre o tempo total de recuperação. Isso é calculado subtraindo o timestamp de detecção do timestamp de resolução.
4. Calcule a Média dos Tempos de Recuperação: Some todos os tempos de recuperação registrados no período e divida pelo número total de incidentes para obter o MTTR.

Imagine um cenário onde sua equipe teve três incidentes no último mês com os seguintes tempos de recuperação:

• Incidente 1: 30 minutos
• Incidente 2: 45 minutos
• Incidente 3: 60 minutos

O cálculo seria:

• Total de incidentes: 3
• Somatório dos tempos de recuperação: 30 + 45 + 60 = 135 minutos
• MTTR = 135 / 3 = 45 minutos

Benchmark de Mercado

• Baixa Performance: Mais de um dia. Isso sugere que a equipe tem dificuldades significativas em resolver incidentes rapidamente, possivelmente devido a processos de recuperação ineficientes ou falta de ferramentas adequadas.
• Média Performance: Entre uma hora e um dia. A equipe é razoavelmente eficaz, mas pode beneficiar-se de melhorias nos processos de recuperação e monitoramento.
• Alta Performance: Menos de uma hora. Reflete uma equipe altamente ágil e bem preparada para lidar com incidentes, com processos de recuperação eficientes e ferramentas de monitoramento eficazes.

Porque é importante saber medir de forma correta as DORA Metrics

Medir as DORA Metrics de forma correta é super importante para entender como as equipes de desenvolvimento estão se saindo e identificar onde estão os gargalos no pipeline. Essas métricas dão uma visão clara de como o software está sendo entregue, ajudando a liderança a tomar decisões mais acertadas sobre onde focar os esforços de melhoria e onde investir recursos. Sem essas medições, fica difícil identificar problemas e fazer mudanças eficazes.

Além disso, as DORA Metrics permitem que a equipe compare seu desempenho com os padrões da indústria, ajudando a ajustar estratégias para se manter competitiva. Monitorar e otimizar essas métricas ao longo do tempo cria um ciclo contínuo de melhorias, o que é essencial para manter a equipe ágil e a qualidade do desenvolvimento em alta.