Indicadores do DevOps
Por que, o quê e como medir o sucesso no DevOps
TOM HALL
Representante e Profissional de DevOps
O velho ditado de que você não pode melhorar o que não mede é tão verdadeiro para o DevOps quanto qualquer outra prática. Para cumprir a promessa do DevOps — lançar produtos de maior qualidade e mais rápido — as equipes precisam coletar, analisar e medir várias métricas. Essas métricas de DevOps disponibilizam os dados essenciais que as equipes de DevOps precisam para ter visibilidade e controle sobre seu pipeline de desenvolvimento.
O que são métricas de DevOps?
As métricas de DevOps são pontos de dados que fazem uma revelação direta do desempenho de um pipeline de desenvolvimento de software DevOps e ajudam a identificar e remover com rapidez quaisquer gargalos no processo. Essas métricas podem ser usadas para rastrear recursos técnicos e processos de equipe.
Em sua essência, o DevOps se concentra em encurtar a distância entre as equipes de desenvolvimento e operações, permitindo uma maior colaboração entre desenvolvedores e administradores de sistemas. As métricas permitem que as equipes de DevOps meçam e avaliem fluxos de trabalho colaborativos e acompanhem o progresso de atingir metas de alto nível, incluindo maior qualidade, ciclos de lançamento mais rápidos e melhor desempenho de aplicativos.
Quatro métricas fundamentais de DevOps
Embora existam várias métricas usadas para medir o desempenho do DevOps, as quatro métricas fundamentais a seguir devem ser medidas por toda equipe de DevOps.
1. Tempo de espera para mudanças
Uma das principais métricas de DevOps a ser rastreada é o tempo de espera para alterações. Não deve ser confundido com o tempo de ciclo (discutido abaixo), o tempo de espera para alterações é o período entre o momento em que uma alteração de código é confirmada para a ramificação de tronco e quando ela está em um estado implantável. Por exemplo, quando o código passa em todos os testes de pré-lançamento necessários.
2. Taxa de falha em alterações
A taxa de falha de alteração é a porcentagem de alterações de código que exigem correções ou outras remediações após a produção. Essa taxa não mede falhas detectadas por testes e corrigidas antes da implementação do código.
3. Frequência de implementação
Compreender a frequência com que o novo código é implementado na produção é fundamental para entender o sucesso do DevOps. Muitos profissionais usam o termo “entrega” no sentido de alterações de código que são lançadas em um ambiente de staging de pré-produção e reservam “implementação” para se referir às alterações de código que são lançadas na produção.
4. Tempo médio de recuperação
O tempo médio de recuperação (MTTR) mede quanto tempo leva para se recuperar de uma interrupção parcial do serviço ou falha total. Essa é uma métrica importante a ser rastreada, não obstante se a interrupção for resultado de uma implementação recente ou de uma falha isolada do sistema.
Ver solução
Ferramentas para uma equipe de elite de DevOps
Material relacionado
A importância da estrutura da equipe no DevOps
Como medir, usar e melhorar as métricas de DevOps
Como outros elementos do ciclo de vida do DevOps, uma cultura de melhoria contínua se aplica às métricas de DevOps. A capacidade de receber feedbacks rápidos em cada fase do desenvolvimento, em conjunto com a habilidade e a autoridade para implementar feedbacks, são características das equipes de alto desempenho. No livro sobre DevOps “Accelerate”, os autores observam que as quatro métricas principais listadas acima são suportadas por 24 recursos adotados por equipes de software de alto desempenho. Cobrimos a maioria desses recursos abaixo (IC/CD, automação de testes, trabalho em pequenos lotes, monitoramento e aprendizado contínuo), mas vale a pena ler “Accelerate” para um mergulho mais profundo na pesquisa que apoia essas práticas.
Tempo de espera para mudanças
As equipes de alto desempenho, em geral, medem os tempos de espera em horas. Em contrapartida, equipes de médio e baixo desempenho, medem os prazos de entrega em dias, semanas ou até meses.
Automação de testes, desenvolvimento baseado em troncos e trabalho em pequenos lotes são elementos-chave para melhorar o tempo de espera. Essas práticas permitem que os desenvolvedores recebam feedback rápido sobre a qualidade do código que eles confirmam para que possam identificar e corrigir quaisquer defeitos. Tempos de espera longos são quase garantidos se os desenvolvedores trabalharem em grandes mudanças que existem em ramificações separadas e dependem de testes manuais para o controle da qualidade.
Alterar taxa de falhas
Equipes de alto desempenho têm taxas de falha de mudança na faixa de 0 a 15%.
As mesmas práticas que permitem prazos de entrega mais curtos — automação de testes, desenvolvimento baseado em troncos e trabalho em pequenos lotes — se correlacionam com uma redução nas taxas de falha de alteração. Todas essas práticas tornam os defeitos muito mais fáceis de identificar e corrigir.
Rastrear e relatar as taxas de falha de alteração não é importante apenas para identificar e corrigir bugs, mas também para garantir que as novas versões de código atendam aos requisitos de segurança.
Frequência de implementação
Equipes de alto desempenho podem implementar mudanças sob demanda e muitas vezes o fazem várias vezes ao dia. As equipes de baixo desempenho, em geral, se limitam à implementação semanal ou mensal.
A capacidade de implementar sob demanda requer um pipeline de implementação automatizado que incorpore os mecanismos automatizados de teste e feedback referenciados nas seções anteriores e minimize a necessidade de intervenção humana.
Tempo médio de recuperação
Equipes de alto desempenho se recuperam de falhas do sistema com rapidez — quase sempre em menos de uma hora — enquanto equipes de baixo desempenho podem levar até uma semana para se recuperar de uma falha.
A capacidade de se recuperar com rapidez de uma falha depende da capacidade de identificar com rapidez quando ocorre uma falha, além de implementar uma correção ou reverter quaisquer alterações que levaram à falha. Em geral, essa recuperação é feita monitorando com continuidade a integridade do sistema e alertando a equipe de operações em caso de falha. A equipe de operações deve ter os processos, as ferramentas e as permissões necessárias para resolver incidentes.
O foco no MTTR é um distanciamento da prática histórica de focar no tempo médio entre falhas (MTBF). Essa ação reflete o aumento da complexidade dos aplicativos modernos e, portanto, uma maior expectativa de falhas. Além de reforçar a prática do aprendizado e aprimoramento contínuos. Em vez de esperar até que a implementação seja “perfeita” para evitar qualquer falha (e, assim, redefinir o antigo marcador MTBF), as equipes fazem implementações com continuidade. Em vez de culpar o arruinamento do recorde de MTBF “perfeito”, o MTTR incentiva retrospectivas irrepreensíveis para ajudar as equipes a melhorar seus processos e ferramentas upstream.
Outras métricas relacionadas
Outra métrica relevante é o tempo de ciclo, que é o tempo que uma equipe gasta trabalhando em um item até que ele esteja pronto para envio. No mundo do desenvolvimento, o tempo de ciclo é o momento em que os desenvolvedores fazem a confirmação até o momento em que ele é implementado na produção. Essa métrica importante do DevOps ajuda os líderes de projeto e os gerentes de engenharia a entender melhor o que funciona bem no pipeline de desenvolvimento. Como resultado, eles podem alinhar melhor o trabalho com as expectativas das partes interessadas e dos clientes, garantindo que a equipe faça o lançamento mais rápido.
Os relatórios de tempo de ciclo permitem que os líderes do projeto estabeleçam uma linha de base para o pipeline de desenvolvimento que pode ser usada para avaliar processos futuros. Quando as equipes otimizam o tempo de ciclo, os desenvolvedores, em geral, têm menos trabalhos em andamento e menos fluxos de trabalho ineficientes.
No gerenciamento de produtos Lean, há um foco no mapeamento dos fluxos de valor , que é uma visualização do fluxo desde o conceito do produto ou função até a entrega. As métricas de DevOps disponibilizam muitos dos pontos de dados essenciais para o mapeamento e o gerenciamento efetivos do fluxo de valor, mas devem ser aprimoradas com outras métricas de negócios e produtos para uma verdadeira avaliação de ponta a ponta. Por exemplo, gráficos de burndown do sprint oferecem insights sobre a eficácia dos processos de estimativa e planejamento, enquanto um Net Promoter Score indica se o produto final atende às necessidades dos clientes.
Conclusão…
A melhoria contínua é um princípio fundamental das equipes que praticam DevOps. A capacidade de medir e rastrear o desempenho em todo o tempo de espera para mudanças, taxa de falha de alteração, frequência de implementação e MTTR, permite que as equipes acelerem a velocidade e aumentem a qualidade.
O Open DevOps da Atlassian oferece tudo o que as equipes precisam para desenvolver e operar software. As equipes podem criar a cadeia de ferramentas de DevOps que quiserem, graças às integrações com os principais fornecedores e apps do marketplace. Experimente agora mesmo.
Compartilhar este artigo
Próximo tópico
Leitura recomendada
Marque esses recursos para aprender sobre os tipos de equipes de DevOps ou para obter atualizações contínuas sobre DevOps na Atlassian.
Comunidade de DevOps
Caminho de aprendizagem de DevOps
