O que são métricas DORA?

Desenvolvidas pela equipe de DevOps Research and Assessment (DORA) do Google, as métrica DORA fornecem benchmarks padrão do setor para entrega de softwares e maturidade DevOps.

Em sua essência, as métricas DORA concentram-se em duas dimensões:

1. Throughput: a velocidade com que as equipes de DevOps conseguem lançar um software.
   
   
2. Estabilidade: como as equipes de DevOps podem entregar softwares de forma confiável e segura.

As métricas orientadas ao throughput revelam a rapidez com que as alterações de código migram pelo ciclo de vida do desenvolvimento de software (da idealização à produção), enquanto as métricas orientadas à estabilidade mostram com que frequência as implementações falham e a rapidez com que as equipes se recuperam. Juntas, elas oferecem aos líderes empresariais e às equipes de DevOps insights reproduzíveis e baseados em evidências sobre o desempenho do DevOps. As empresas não precisam confiar em medidas subjetivas de desempenho ou indicadores de vaidade, como “linhas de código escritas” ou “horas trabalhadas”.

Acompanhar métricas DORA permite que as equipes de DevOps vejam como elas se comparam aos níveis de desempenho reconhecidos pelos setores (baixo, médio, alto e elite), e se estão alinhadas com os objetivos corporativos. Isso ajuda as empresas a identificar objetivamente os gargalos nos fluxos de trabalho de integração contínua/entrega contínua (CI/CD), testes de software e gerenciamento de incidentes.

As métricas DORA também facilitam a comunicação do desempenho dos departamentos de engenharia para os stakeholders e ajudam a justificar investimentos em ferramentas avançadas de automação, observabilidade e engenharia de confiabilidade local (SRE) que auxiliam na otimização das práticas de DevOps.

Em DevOps, DORA refere-se à equipe de DevOps Research and Assessment que popularizou métricas de desempenho organizacional para equipes de desenvolvimento de software.

A DORA, agora parte do Google Cloud, começou como um projeto de pesquisa independente que estudava como os processos de entrega de software afetavam os resultados dos negócios. A equipe da DORA estava interessada em responder a uma pergunta importante: o que diferencia as equipes de software de alto desempenho das de baixo desempenho?

Eles coletaram dados de pesquisas e de telemetria de milhares de equipes e constataram que um pequeno conjunto de métricas relacionadas à entrega e às operações era um forte indicador do desempenho geral. Ou seja, essas métricas são a frequência de implementação, o tempo de espera para alterações, a taxa de falha de alteração e o tempo de recuperação de implementação com falhas. Os resultados também provaram que a velocidade de lançamento e a estabilidade do software podem caminhar lado a lado, para que as equipes não precisem priorizar uma em detrimento da outra.

Por fim, os quatro indicadores se tornaram as métricas padrão DORA, que forneceram benchmarks padrão do setor para desempenho de entrega de software. Em 2024, a equipe de pesquisa da DORA adicionou uma quinta métrica (taxa de retrabalho de implementação) ao framework.

As cinco métricas DORA podem ser agrupadas em duas categorias principais: “throughput” e “estabilidade”.

As métricas de throughput incluem a frequência de implementação, o tempo de espera para alterações e o tempo de recuperação de falhas de implementação, que, em conjunto, descrevem com quantas alterações uma aplicação pode lidar e com que rapidez as alterações chegam à produção.

As métricas de estabilidade incluem a taxa de falha de alterações e a taxa de retrabalho de implementação, que medem a proporção de implementações que causam falhas e a proporção de implementações não planejadas ou impulsionadas por incidentes de produção.

A frequência de implementação mede a frequência com que uma equipe implementa código em produção com sucesso durante um determinado período (por dia, por semana, por mês).

A frequência de implementação é um dos sinais mais visíveis da agilidade e da confiança de uma equipe de software em seu processo de entrega. Quando uma equipe implementa código em produção várias vezes por dia, isso geralmente significa que os processos automatizados de compilação, teste e implementação estão funcionando sem problemas e que mecanismos sólidos de observabilidade estão em vigor. Essas condições permitem que as equipes de desenvolvimento lancem softwares sem medo de quebrar o sistema.

Por outro lado, as equipes que implementam apenas uma vez por mês (ou até com menos frequência) geralmente dependem de branches de código de longa duração, testes manuais, protocolos de aprovação complexos e grandes janelas de lançamento. Todos esses fatores retardam o ciclo de feedback do usuário e aumentam o custo da correção de defeitos.

Vale ressaltar que uma alta frequência de implementação não é sinal de integridade se vier acompanhada de frequentes interrupções ou reversões. Equipes de alto desempenho combinam alta frequência de implementação com práticas robustas de garantia de qualidade (testes automatizados em vários níveis, implementações escalonadas, funcionalidades e práticas de monitoramento em tempo real) que ajudam as equipes a lançar atualizações com frequência, minimizando o risco para os usuários.

Do ponto de vista da liderança, o acompanhamento da frequência de implementação ao longo do tempo pode revelar gargalos no pipeline de entrega de software. Por exemplo, uma queda na frequência de implementação após a introdução de um novo conselho de aprovação pode indicar que o processo é muito complexo. Por outro lado, um aumento constante na frequência de implementação, aliado à melhoria das métricas de confiabilidade, é um forte indicador de que os investimentos em pipelines de CI/CD e práticas de DevOps estão valendo a pena.

O tempo de implementação de alterações (também chamado de tempo de espera para alterações) mede o tempo necessário para que uma alteração de código seja implementada e executada com sucesso em produção, após a alteração ter sido confirmada na branch principal do código em um sistema de controle de versão.

Esta visão completa abrange tudo, incluindo o tempo de compilação, a execução de testes, as avaliações de código, as aprovações, os estágios do pipeline e a implementação propriamente dita. Revela a rapidez com que um sistema pode converter uma decisão em uma mudança tangível para os usuários finais.

Quando o tempo de espera é curto (menos de uma hora), as organizações podem responder a incidentes quase em tempo real. Por exemplo, se uma equipe de segurança sinalizar uma vulnerabilidade, a equipe de engenharia pode implementar uma correção, validá-la por meio de verificações automatizadas e colocá-la em funcionamento em um período muito curto de tempo. Esse ciclo de feedback rápido vincula o trabalho de desenvolvimento diretamente aos resultados comerciais, porque as equipes podem medir o impacto das mudanças com rapidez e fazer os ajustes necessários.

Reduzir o tempo de implementação de mudanças quase sempre exige que as equipes de DevOps automatizem e simplifiquem o pipeline de entrega. Esse processo normalmente inclui investir em ferramentas de integração contínua (CI) para que cada commit seja construído e testado rapidamente, além de simplificar os processos de aprovação para que sejam integrados aos fluxos de trabalho de desenvolvimento.

O tempo de recuperação de implementação com falha, também chamado de tempo médio de recuperação (MTTR) ou tempo médio para restaurar o serviço, avalia quanto tempo leva para restaurar o serviço após uma falha relacionada à implementação.

A remediação de serviço pode exigir que os desenvolvedores revertam uma alteração incorreta, implementem um hotfix (uma pequena alteração urgente de código lançada fora do ciclo normal de lançamento) ou mitiguem o impacto do problema para que os usuários possam utilizar o sistema normalmente de novo.

Quando o tempo de recuperação é curto (em questão de minutos), isso geralmente significa que vários componentes do DevOps estão funcionando bem juntos.

A observabilidade é robusta. Os dados de telemetria em tempo real (métricas, logs e traces) são totalmente agregados e centralizados em dashboards. Os incidentes são detectados com rapidez (muitas vezes de forma automática) e sem esperar pela reclamação dos usuários.

O sistema de alertas é ajustado para que os engenheiros sejam notificados prontamente, mas sem serem sobrecarregados por ruídos.

As equipes de DevOps se baseiam em runbooks (guias táticos passo a passo para realizar tarefas técnicas), playbooks (guias estratégicos de nível superior que descrevem como as equipes devem responder a uma situação) e procedimentos de reversão documentados. Esses frameworks eliminam as dúvidas sobre o que fazer em meio a uma interrupção.

Tempos longos de recuperação (horas ou até dias) geralmente indicam práticas operacionais fracas. A detecção pode ser ruim e, portanto, as falhas de produção permanecem até que os clientes as relatem. O diagnóstico é um processo lento porque a coleta de dados é dispersa, as mensagens de erro não são claras ou as equipes não têm um entendimento compartilhado de como o sistema se comporta nos modos de falha. Nesses ambientes, cada incidente torna-se um evento de alto estresse e alto risco, em vez de um exercício direto de resolução de problemas com um protocolo de resolução claro.

Quando combinados com as outras métricas DORA, os tempos de recuperação de implementações com falha ajudam a garantir que, mesmo que as implementações falhem ocasionalmente, a falha seja contida e os tempos de resposta sejam curtos.

A taxa de falha de alterações (CFR) é uma métrica de "qualidade de entrega" que informa às equipes de DevOps com que frequência as implementações falham em ambientes de produção reais. Qualquer implementação problemática em produção que force a equipe a intervir imediatamente, em vez de esperar até o próximo lançamento planejado para lidar com o problema, é considerada uma implementação "com falha".

Acompanhar a CFR ao longo do tempo ajuda as equipes a entender o nível de confiabilidade com que estão entregando alterações e serve como contrapeso para métricas de throughput (frequência de implementação, tempo de espera para mudanças) que priorizam a velocidade.

A CFR é tipicamente expressa como uma porcentagem e é calculada dividindo o número de implementações com falha pelo número total de implementações no mesmo período e, em seguida, multiplicando por 100.

Uma baixa taxa de falha de alteração indica que a equipe está enviando alterações que geralmente se comportam conforme o esperado na produção. Quando a CFR é baixo e estável, as equipes podem aumentar com segurança a frequência de implementação e reduzir o tempo de espera de mudanças sem prejudicar a experiência do usuário.

No entanto, uma alta taxa de falha nas alterações sugere que mudanças em excesso estão desestabilizando o sistema. As causas podem incluir testes incompletos ou imprecisos, ambientes de testes e estágios que diferem daqueles em produção, implementações grandes demais ou monitoramento e alertas lentos. Uma CFR alta indica que a organização deve priorizar mudanças menores e mais incrementais e práticas de implementação mais seguras (como versões canário, em que um novo aplicativo ou funcionalidade é lançado para um pequeno grupo de usuários antes do lançamento mais amplo), reduzindo assim o número de mudanças que se transformam em incidentes de produção.

A taxa de implementação de retrabalho é uma métrica de estabilidade que mede qual fração da implementação de uma equipe é retrabalho. "Retrabalho" refere-se a qualquer implementação que seja desencadeada por um bug ou incidente que afeta o usuário em produção e que não faça parte do lançamento original e planejado.

A taxa de retrabalho de implementação complementa as quatro métricas DORA originais, tornando o trabalho reativo visível. Ela revela quanto do esforço de desenvolvimento de uma equipe é gasto corrigindo erros do passado, em vez de avançar com o produto.

Uma taxa baixa de retrabalho geralmente indica que as equipes de DevOps estão identificando a maioria dos problemas antes de chegarem aos usuários finais e passando a maior parte do tempo fazendo trabalhos de criação de valor (otimizações planejadas e refatorações). Uma alta taxa de retrabalho significa que as equipes estão gastando muito tempo em tarefas corretivas.

As taxas de retrabalho são especialmente valiosas quando combinadas com outras métricas importantes. Por exemplo, se uma equipe tem alta frequência de implementação e baixa taxa de retrabalho, isso indica que a equipe está lançando novas versões de software de forma rápida, sem sacrificar a qualidade. Mas se a equipe apresentar uma alta frequência de implementação juntamente com uma alta taxa de retrabalho, isso sugere que ela está enviando muito código, mas também perdendo muito tempo corrigindo-o.

É importante ressaltar que uma taxa de retrabalho diferente de zero é normal (e muitas vezes saudável). Mesmo as melhores equipes de desenvolvimento podem cometer erros, e aplicações de software bem construídas ainda exigirão melhorias e atualizações de funcionalidades ao longo do tempo. A meta não é atingir 0% de retrabalho, mas manter o retrabalho em uma porcentagem pequena e previsível de todas as implementações.

Para cada métrica DORA, as equipes são classificadas em um dos quatro níveis de desempenho (elite, alto, médio ou baixo) e cada nível é baseado em limites estabelecidos para a métrica. Os limites são:

Como a taxa de retrabalho de implementação é uma métrica mais recente, ela ainda não estabeleceu limites ou níveis de desempenho. No entanto, muitas empresas e equipes de DevOps monitoram suas próprias linhas de base de retrabalho e visam reduzir ao longo do tempo. O uso dos dados de taxa de retrabalho em conjunto com a taxa de falha de alteração e outras métricas de confiabilidade ajuda as equipes a melhorar as taxas de retrabalho de implementação sem correções excessivas com base em um único número.

As métricas DORA apoiam uma abordagem DevOps mais abrangente para o desenvolvimento de software, que prioriza a colaboração contínua entre equipes multidisciplinares em todo o desenvolvimento de aplicativos e funções operacionais. Os ambientes DevOps são tão bem-sucedidos quanto as equipes que os compõem.

As métricas DORA permitem que as empresas quantifiquem o desempenho da equipe de acordo com critérios estreitamente alinhados com fluxos de valor mais amplos e resultados de negócios. Por exemplo, os setores de alto desempenho e os de elite têm maior probabilidade de atingir as metas de lucratividade, prazo de lançamento no mercado e satisfação do cliente.

As culturas de DevOps também são caracterizadas por um compromisso com a comunicação fluida e a responsabilidade compartilhada entre os stakeholders na entrega de software, que trabalham juntos para construir softwares de alta qualidade e acelerar a inovação de produtos. Portanto, muitas organizações usam as métricas DORA para criar um ciclo de feedback de melhoria contínua. As métricas medem o desempenho de cada equipe. As equipes podem discutir oportunidades de melhoria com base nas medições, experimentar novas abordagens e medir novamente o desempenho para verificar quais mudanças realmente melhoram as práticas de entrega.

É importante ressaltar que as métricas DORA são diagnósticas, não punitivas. Elas ajudam a revelar padrões sistêmicos nos processos de desenvolvimento, em vez de se concentrarem no trabalho de desenvolvedores individuais.