Devops Research & Assessment DORA, você sabe o que é?
A equipe de pesquisa e avaliação de DevOps (DORA) é o grupo de pesquisa do Google mais conhecido por seu trabalho em um programa de seis anos para medir e entender as práticas e recursos de DevOps em todo o setor de TI. A pesquisa da DORA foi apresentada no relatório anual State of DevOps de 2014 a 2019 . O grupo também produziu um whitepaper sobre ROI , fornecendo insights sobre as transformações do DevOps.
O relatório está disponível no site do google e pode ser baixado de graça ou quase de graça. https://cloud.google.com/devops/state-of-devops
Explorar os resultados da pesquisa DevOps Research and Assessment (DORA) e compartilhar o que você precisa saber para alcançar a Entrega Contínua e a filosofia DevOps obtendo velocidade e estabilidade.
Peter Drucker uma vez disse: “Se você não pode medir, não pode melhorá-lo”. Para aplicação do DevOps é a mesma coisa. Para entregar um software melhor com eficiência e eficácia, as equipes precisam de visibilidade, dados e decisões para impulsionar os recursos de DevOps.
Hoje vamos explorar os resultados da pesquisa DevOps Research and Assessment (DORA) e compartilhará o que você precisa saber sobre como alcançar a um ciclo de Entrega Contínua e a filosofia DevOps sobre velocidade e estabilidade.
O que é DORA?
A equipe de pesquisa e avaliação de DevOps (DORA) é o grupo de pesquisa do Google mais conhecido por seu trabalho em um programa de seis anos para medir e entender as práticas e recursos de DevOps em todo o setor de TI. A pesquisa da DORA foi apresentada no relatório anual State of DevOps de 2014 a 2019 . O grupo também produziu um whitepaper sobre ROI , fornecendo insights sobre as transformações do DevOps.
A pesquisa da DORA identificou quatro métricas principais que indicam o desempenho de desenvolvimento e entrega de software dos seis anos de dados do estudo. A líder da equipe DORA, Nicole Forsgren, é coautora de um livro chamado Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. Neste livro Nicole compartilha as descobertas da equipe DORA explicando a ciência e a pesquisa por trás dos recursos nos quais as equipes de entrega e desenvolvimento devem investir para aumentar o desempenho de entrega de software.
Quais são as quatro métricas principais?
- LeadTime
- Change Failure Rate
- Deployment Velocity
- MMTR
As medições de produtividade e desempenho do desenvolvedor, como linhas de código, velocidade e utilização, concentram-se em saídas das equipes de forma individual ou isolada. Equipes com perfil de entrega multifuncionais, acompanhar os resultados da equipe versus os resultados individuais permite que as organizações atinjam suas metas organizacionais com mais foco e velocidade.
Por meio de seu livro Accelerate, Nicole Forsgren, Jez Humble e Gene Kim identificaram as principais características para a construção de organizações de tecnologia de alto desempenho. Essas organizações de alto desempenho se concentraram em resultados de engenharia sobre saídas e equipes sobre indivíduos, rastreando quatro medidas: Lead Time, Deployment Frequency, Mean Time to Restore (MTTR) e Change Failure Rate.
Vamos definir cada um desses termos e discutir métodos práticos para medir essas métricas.
LeadTime
O prazo de entrega é o tempo total entre o início de uma solicitação de recurso até a entrega desse recurso a um cliente. Na manufatura enxuta e no mapeamento do fluxo de valor, é comum capturar o Lead Time de um processo como a implantação de um serviço. Capturar o tempo total que leva da confirmação do código-fonte até o lançamento da produção ajuda a indicar o ritmo da entrega do software.
Muitas empresas se perguntam qual a forma mais assertiva de medir o LeadTime, entendemos que a partir do momento que uma tarefa entra no sprint o lead time já começa a ser contabilizado, porém ainda é muito difícil contabilizar essa métrica, para facilitar alguns times usar o momento que uma pull request é enviada ao repositório até o momento que o merge e o deploy em produção acontece.
Deploy Frequency
A frequência de implantação é a frequência com que uma empresa consegue implantar código para um serviço ou aplicativo. A frequência indica o ritmo de entrega do software. A teoria por trás da Frequência de Implantação também se baseia nos conceitos de manufatura enxuta e como isso se traduz no controle do tamanho do lote de estoque a ser entregue. Organizações de alto desempenho fazem implantações menores e mais frequentes.
Mean Time to Restore (MTTR)
Mean Time to Restore ou MTTR refere-se à resolução de incidentes. Onde houver uma falha, o tempo médio para restauração é o tempo médio necessário para restaurar o serviço quando ocorre um incidente. O MTTR é uma medida de tempo semelhante ao Lead Time, porém além do MTTR também podemos usar o MMTA Mean time to acknowledge, assim você consegue medir o tempo de recuperação a partir do momento que a equipe responsável toma conhecimento sobre o incidente, isso pode evitar que apenas para identificar que o problema aconteceu demorou 1 dia enquanto a resolução demorou apenas 1 hora.
Change Failure Rate
A taxa de falha de alteração é a porcentagem de alterações feitas em um serviço em que a alteração resulta em soluções, incidentes, reversões ou implantações com falha. A porcentagem de falha de alteração é uma medida de qualidade. Com base na pesquisa da equipe DORA, as equipes de alto desempenho estavam em algum lugar entre a faixa de 0 a 15%, um item importante para conseguir medir as falhas é com métricas de error rate.
E como podemos usar as métricas de aceleração?
Quando conseguimos rastrear essas métricas, é importante considerar o tempo, o contexto e os recursos. A análise de dados requer uma medição consistente ao longo do tempo. Diferentes níveis de liderança podem então entender esses resultados com base no contexto. Faltou ferramentas ou automação para auxiliar nas implantações, triagem de incidentes e teste de nossos serviços? Houve mudanças na arquitetura, planejamento ou objetivos durante esse período? Da mesma forma, rastrear essas métricas por serviço e entre várias equipes pode fornecer informações adicionais sobre o que está indo bem e o que não está.
Essas métricas destinam-se a incentivar a melhoria, a discussão e a entrega a qualquer pessoa que tenha interesse no serviço ou aplicativo de software.
Já no ferramental é importante falar com o time de Observabilidade como essas métricas podem ser armazenadas e processadas, em resumo um prometheus bem instrumentado com o grafana pode resolver o problema, se você tiver essas métricas sendo expostas em algum endpoint.
Velocidade Vs. Estabilidade
Quando a velocidade ou frequência de entrega é um custo para sua estabilidade. Ou seja, uma taxa de falha mais alta durante as alterações pode indicar que o controle de qualidade está ruim em um pipeline CI/CD é possível acompanhar esses dados com testes, já escrevi um artigo falando sobre as etapas mais importantes de um pipeline você pode ler no link.
Isso pode ser verdadeiro se a frequência de implantação for diária ou semanal. Se a frequência de implantação não for com uma frequência tão alta, mas a taxa de falha de alteração for alta, isso pode indicar que as implantações não foram bem planejadas e podem conter grandes ou grandes alterações de recursos.
Tempo e recursos são importantes nessas conversas. Mas essas quatro métricas principais influenciam umas às outras e muitas vezes ajudam a desvendar histórias e insights que, de outra forma, seriam mais difíceis de entender. Observar a qualidade, velocidade e estabilidade é um método para analisar seu desempenho de DevOps.
Na CodeView consultoria aplicamos a observabilidade desde o início de qualquer contrato, pois entendemos que qualquer empresa pode se beneficiar de dados sólidos para tomada de decisões o que faz a diferença para seu cliente final.
Faça uma avaliação rápida do DORA DevOps
