Métricas em DevOps: medir e otimizar performance com Dora, Space e DevEx

DORA Métricas e Cálculo Prático - Boa vindas e Introducao

Apresentando o curso e o instrutor

Olá, pessoal. Bem-vindos ao curso de Engenharia de Alto Desempenho, Estratégia e Métricas com Dora, Space e DevEx. Sou Eric Fernandes e tenho 18 anos de experiência nas áreas de qualidade, SRE e observabilidade. Atualmente, atuo como Principal Quality Architect na IBM.

Introduzindo as métricas Dora e o framework Space

Vamos analisar as métricas principais que hoje guiam as empresas em direção aos resultados. As Dora Metrics estão fortemente vinculadas ao Media Performance, aos schemes e ao Space. Vamos discutir bastante sobre esse framework, que mede o ambiente, a sustentabilidade do ambiente, o bem-estar humano, entre outros aspectos.

Explorando o foco no DevEx

Além disso, abordaremos o DevEx, focando na experiência da pessoa desenvolvedora, e também veremos isso na prática. Vamos juntos nessa jornada.

DORA Métricas e Cálculo Prático - Accelerate e introducao as 4 key metrics

Introduzindo as métricas DORA

Vamos começar a falar sobre as métricas DORA. Antes de abordar esse tema, precisamos entender como tudo começou. O livro que deu origem à difusão dessas métricas no mercado foi amplamente referenciado e utilizado desde sua publicação. Trata-se de uma pesquisa muito sólida, que foi condensada nesse livro, e que durou, se não me engano, oito anos. Essa pesquisa foi realizada por pessoas que também são figuras destacadas no setor: Nicole Forsgren, Jess Humble e Jane King. A partir daí, eles condensaram essa investigação.

O termo DORA significa DevOps Research and Assessment (Pesquisa e Avaliação de DevOps), que é, de fato, a pesquisa de DevOps realizada ao longo desses anos. Esse livro nos apresentou quatro métricas principais que são muito utilizadas e difundidas, e que veremos aqui na prática. Essas métricas ajudam a medir o desempenho das equipes.

Explicando as métricas DORA

As métricas são as seguintes:

1. Deployment Frequency (Frequência de Desdobramentos): Refere-se à frequência de desdobramentos em produção, ou seja, quantos desdobramentos são feitos em produção em um determinado período de tempo.

2. Lead Time to Change: Imagine um quadro no Jira, Linear ou Azure Boards, ou qualquer outro que você use. Quando colocamos uma tarefa em desenvolvimento, quanto tempo essa tarefa leva para chegar à produção? Podemos medir dessa forma. Ou quanto tempo passa desde que se abre o pull request até que ele tenha a revisão de código, vai e vem, e finalmente chega à produção. Isso depende muito de como queremos medir. No exemplo dado, as empresas definem dessa forma, e é um acordo comum para medir corretamente. Isso se aplica a todas as métricas que mencionaremos aqui. Veremos na prática, mas para todas essas métricas, esse acordo comum é importante. Se medirmos uma equipe de maneira diferente de outra, não estaremos medindo todas com a mesma regra e teremos resultados nos quais não poderemos confiar. É importante começar por aí.

3. Change Failure Rate: Basicamente, é o percentual de falhas que estamos introduzindo em produção.

Algo importante a ser dito desde já é que essas quatro métricas não são avaliadas individualmente, mas sempre em conjunto.

Relacionando métricas e desempenho

Por exemplo, o percentual de falhas que introduzimos em produção está relacionado com a nossa Deployment Frequency (Frequência de Implantação). Se realizarmos 10 implantações em produção em um sprint de duas semanas, e estivermos medindo esse sprint, podemos identificar que 5 dessas 10 implantações provocaram um incidente em produção, ou seja, geraram um erro. Assim, estamos dizendo que 50% são falhas, resultando em um Change Failure Rate (Taxa de Falhas de Mudança) de 50%. Vamos calcular dessa forma apenas para exemplificar.

Por último, temos o Mean Time to Restore (Tempo Médio para Restaurar), que é uma métrica importante. Ela mede quanto tempo levamos para nos recuperarmos de uma falha total ou parcial em produção. Isso quase sempre se torna uma meta global da empresa, pois não queremos ficar fora de serviço ou perder vendas. Imagine uma empresa que possui um e-commerce. Se ficar fora do ar no Natal ou na Black Friday, ninguém poderá comprar, resultando em perda de vendas e impacto direto nos lucros. Por isso, é uma métrica que indica que quanto menor, melhor. Precisamos medir isso para saber quanto tempo levamos para nos recuperar, pois falhas vão ocorrer. No entanto, é necessário medir o desempenho da equipe em relação à sua capacidade de recuperação.

Explorando a pesquisa contínua DORA

Vamos sair um pouco da apresentação para mostrar algo interessante sobre a DoraMetrix. Trata-se de uma pesquisa que continua sendo realizada até hoje. Anualmente, são publicadas as edições do State of DevOps, onde divulgam os estudos em andamento. Isso é muito respeitado no mercado e amplamente utilizado para entender o que está acontecendo com as evoluções, principalmente com a IA. O último estudo publicado é o "Impact of Generative AI" (Impacto da IA Generativa) no desenvolvimento de software. É possível baixá-lo e entender o que é apresentado na pesquisa, mas isso já vem sendo feito há bastante tempo, sempre em torno do tema DevOps, o que é bastante interessante.

Preparando para a prática

Na nossa próxima aula, entraremos um pouco na prática, veremos como medir de forma prática, como calcular e até mesmo como classificar. O livro também oferece um ponto de vista interessante: podemos medir, mas até que ponto é bom ou ruim? Existem níveis de classificação como Elite, Médio, Alto, mas isso fica para a próxima aula. Nos vemos lá!

DORA Métricas e Cálculo Prático - DORA na pratica

Introduzindo o cálculo de métricas a partir de dados de repositórios

Olá a todos, vamos agora ver de forma prática como calcular métricas a partir de dados extraídos de um repositório. Por exemplo, aqui temos uma planilha com dados que simulamos ter extraído de um repositório, seja GitHub, GitLab, Azure, etc. Estamos falando de um time e vamos medir o desempenho deste time. Cada linha representa um deploy e temos alguns dados necessários para medir as quatro métricas: o timestamp do deploy, do PR, se houve incidente ou não, a taxa de falha de mudanças para saber quantos incidentes ocorreram, e quantos deploys foram feitos. Já temos aqui quatro deploys. Temos também a hora em que o PR foi aberto e o dia até chegar ao deploy desse PR. Além disso, temos a hora e o dia em que o incidente foi aberto e a hora em que foi resolvido, e se foi um hotfix ou não. Esses são os dados que nos importam.

Explicando o cálculo das métricas de desempenho

Já preparei algumas fórmulas para calcular e agora explicarei como foi feito. Temos a frequência de deploy, que é a contagem de quantos deploys foram realizados. Temos uma frequência de deploy de quatro deploys. Isso sempre é um recorte de tempo, que pode ser definido de acordo com o contexto, seja trimestral, por sprint, mensal, etc. Suponhamos que seja mensal, então, no mês, houve apenas quatro deploys. O lead time é de 23 horas, calculado em média usando as colunas de deploy e PR. A porcentagem de falhas é fácil de calcular: são duas falhas, o que significa uma taxa de falhas de 50% em relação ao número de deploys. De todos os deploys, metade apresentou falhas. O MTTR é medido em minutos, considerando os incidentes ocorridos e o tempo de resolução. Por exemplo, um incidente começou às 9h e foi resolvido às 11h10, e outro começou às 13h20 e foi resolvido às 18h. Isso nos dá uma média em minutos.

Discutindo o contexto e o benchmark de desempenho

Agora, sabemos como medir isso, mas no mundo real, podemos ter envios de todos os times. Como saber se esse desempenho é bom, ruim ou mediano? Preparei algo para explicar isso. Vale ressaltar que o State of DevOps e o próprio DORA sempre reforçam que o benchmark precisa de contexto. O modelo de níveis é revisado ao longo dos anos e não pode ser usado como um contrato fixo na empresa. Por exemplo, se temos uma frequência de deploys diária, isso não significa necessariamente que somos elite. Dependerá do contexto da empresa e do que é considerado elite, alto, médio ou baixo.

Classificando a frequência de deploy e o desempenho dos times

A frequência de deploy é geralmente classificada assim: se um time faz deploys sob demanda, diariamente, ele é considerado elite. Se faz um deploy por semana, é considerado alto. Caso contrário, é médio ou baixo. No entanto, um time elite não deve cumprir apenas um critério, mas todos os quatro para se encaixar nessa categoria. Isso inclui fazer deploys diariamente, ter um lead time menor que um dia, uma taxa de falhas por mudança dentro de um certo intervalo e um MTTR menor que uma hora.

Destacando a importância da recuperação rápida e do contexto

É importante destacar que não é necessário ter 0% de falhas. Isso não existe. O que se defende como elite é até 15% de falhas. Em alguns contextos, pode ser diferente, mas empresas de referência, como Google e Netflix, podem ter uma taxa de falhas por mudança mais baixa. O importante é se recuperar rapidamente, ter uma baixa taxa de problemas e uma frequência de deploys em um curto espaço de tempo. Isso nos permite avaliar se um time tem desempenho elite, alto, médio ou baixo. Não penalizamos um time com desempenho baixo, mas isso nos ajuda a entender o contexto e por que está assim. Isso conecta com o tema da próxima aula, onde veremos que não estamos falando apenas de números, mas também do fator humano e do contexto.

Introduzindo o próximo tema: framework SPACE

Na próxima aula, falaremos um pouco sobre o framework SPACE. Nos vemos lá!

Sobre o curso Métricas em DevOps: medir e otimizar performance com Dora, Space e DevEx

O curso Métricas em DevOps: medir e otimizar performance com Dora, Space e DevEx possui 89 minutos de vídeos, em um total de 52 atividades. Gostou? Conheça nossos outros cursos de Platform Engineering em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Aula 1
• Aula 2
• Aula 3
• Aula 4
• Aula 5