[ad_1]
As métricas DORA são quatro medidas principais que ajudam os líderes de equipe a entender a eficácia de suas práticas de trabalho de DevOps. O grupo DevOps Research and Evaluation (DORA) desenvolveu as métricas após seis anos de pesquisa sobre a adoção bem-sucedida de DevOps.
A medição de dados é a melhor maneira de medir o efeito que o DevOps está tendo em sua organização. Focar nos aspectos identificados pela DORA pode revelar oportunidades para otimizar seus processos e melhorar a eficiência. Neste artigo, explicaremos como cada uma das quatro métricas contribui para o sucesso do DevOps.
Frequência de Implementação
A frequência de implantação mede a frequência com que você envia um novo código para seu ambiente de produção. Como o objetivo principal do DevOps é fornecer código que funcione com mais eficiência, a frequência de implantação é um ótimo ponto de partida para avaliar o sucesso.
Você pode coletar esses dados simplesmente observando quantas vezes o novo código foi implantado em um determinado período de tempo. Você pode então procurar oportunidades para aumentar sua taxa de lançamento, sem sacrificar as grades que mantêm os padrões de qualidade. Usar a entrega contínua para implantar código automaticamente à medida que você o mescla é uma maneira de acelerar seu fluxo de trabalho.
A frequência de implantação ideal depende do tipo de sistema que você está construindo. Embora agora seja comum que aplicativos da Web sejam entregues várias vezes ao dia, essa cadência não é adequada para desenvolvedores de jogos que produzem compilações de vários gigabytes.
Em algumas situações, pode ser útil reconhecer essa diferença pensando na frequência de implantação de maneira um pouco diferente. Você pode chegar perto dela como quantas vezes poderia tendo implementado o código, se você quisesse lançar uma nova versão em um determinado momento. Essa pode ser uma maneira mais eficaz de medir o desempenho quando a entrega contínua verdadeira não for viável para o seu projeto.
Alterar o prazo de entrega
O tempo limite para uma mudança é o intervalo entre a confirmação de uma revisão de código e a entrada dessa confirmação no ambiente de produção. Essa métrica revela atrasos que ocorrem durante a revisão e iteração do código, depois que os desenvolvedores concluíram o sprint original.
Medir este valor é fácil. Você precisa encontrar a hora em que o desenvolvedor assinou uma alteração e, em seguida, a hora em que o código foi liberado para os usuários. O tempo de espera é o número de horas e minutos entre os dois valores.
Como exemplo, considere uma alteração simples para enviar um e-mail de alerta de segurança depois que os usuários fizerem login. O desenvolvedor conclui a tarefa às 11h e confirma seu trabalho no repositório de origem. Às 12h, um revisor lê o código e o passa para o controle de qualidade. Às 14h, o testador da equipe de controle de qualidade percebeu que havia um erro de digitação na cópia do e-mail. O desenvolvedor confirma uma correção às 15h e o controle de qualidade mescla a alteração final na produção às 16h. O tempo de espera para essa alteração foi de 5 horas.
O lead time é usado para descobrir ineficiências à medida que o trabalho se move entre os itens. Embora os padrões variem amplamente de acordo com o setor e a organização, um lead time médio alto pode ser indicativo de atrito interno e fluxo de trabalho mal considerado. Os prazos de entrega estendidos também podem ser causados por desenvolvedores com baixo desempenho produzindo trabalho de baixa qualidade como sua primeira iteração em uma tarefa.
Algumas organizações usam medidas diferentes para o tempo de entrega. Muitos selecionam o tempo entre um desenvolvedor iniciando um recurso e o código final entrando em produção. Outros podem olhar ainda mais para trás e usar o momento em que uma mudança foi solicitada, por um cliente, cliente ou gerente de produto, como ponto de partida.
Esses métodos podem produzir informações mais úteis dentro do negócio, fora das equipes de engenharia. No entanto, a interpretação do DORA usando timestamps de confirmação tem uma grande vantagem: a ferramenta de controle de origem captura os dados automaticamente, para que os desenvolvedores não precisem registrar manualmente os horários de início de cada nova tarefa.
Alterar taxa de erro
A taxa de falha de alteração é a porcentagem de implantações de produção que resultam em um incidente. Um incidente é qualquer erro ou comportamento inesperado que causa uma interrupção ou interrupção nos clientes. Desenvolvedores e operadores precisarão gastar tempo resolvendo o problema.
Você pode calcular sua taxa de falha de alteração dividindo o número de implantações feitas pelo número que resultou em uma falha. O valor final geralmente é obtido pela marcação de relatórios de bugs em seu software de gerenciamento de projetos com a implementação que os introduziu.
Às vezes, atribuir incidentes com precisão à mudança que os causou pode ser complicado, especialmente se você tiver uma alta frequência de implantação, mas em muitos casos é possível que desenvolvedores e equipes de triagem determinem o gatilho mais provável. Outro desafio pode ser concordar sobre o que constitui uma falha: pequenos bugs devem aumentar sua taxa de falha ou você está interessado apenas em grandes interrupções? Ambos os tipos de problemas afetam a forma como os clientes percebem seu serviço, portanto, pode ser útil manter vários valores diferentes para essa métrica, cada um analisando uma classe diferente de problema.
Você deve sempre tentar reduzir a taxa de erro de mudança o mais baixo possível. O uso de testes automatizados, análise estática e integração contínua pode ajudar a evitar que códigos quebrados cheguem à produção. Proteja seus processos com novas ferramentas e métodos de trabalho para reduzir gradualmente a taxa de falhas ao longo do tempo.
Hora de restaurar o serviço
Infelizmente, as falhas não podem ser completamente erradicadas. Eventualmente, você se deparará com um problema que causará dor aos seus clientes. A quarta métrica da DORA, Time to Restore Service, analisa a eficácia com que você pode responder a esses eventos.
Semelhante ao tempo de entrega de alterações, a duração medida pode variar entre as organizações. Algumas equipes usarão a hora em que o bug foi implantado, outras partirão do primeiro relatório do cliente e algumas poderão usar a hora em que a equipe de resposta a incidentes foi chamada. Seja qual for o ponto de gatilho que você adotar, você deve usá-lo de forma consistente e continuar medindo até que o incidente seja marcado como resolvido.
Um tempo médio de recuperação alto é um sinal de que seus processos de resposta a incidentes precisam de ajustes. As respostas eficazes dependem da disponibilidade das pessoas certas para identificar a falha, desenvolver um patch e se comunicar com os clientes afetados. Você pode reduzir o tempo de restauração desenvolvendo procedimentos de resposta acordados, mantendo informações críticas acessíveis centralmente em toda a sua organização e introduzindo monitoramento automatizado para alertá-lo sobre problemas assim que eles ocorrerem.
A otimização dessa métrica geralmente é negligenciada porque muitas equipes supõem que uma grande interrupção nunca ocorrerá. Você também pode ter relativamente poucos pontos de dados para trabalhar se seu serviço for geralmente estável. A execução de testes de resposta a incidentes usando técnicas como testes de caos pode fornecer dados mais significativos que representam seu tempo de recuperação atual.
Resumo
As quatro métricas da DORA fornecem aos líderes de equipe de DevOps dados que revelam oportunidades de melhoria. Medições e análises regulares da frequência de implantação, tempo de entrega de alterações, taxa de falha de alterações e tempo de restauração de serviço ajudam você a entender seu desempenho e tomar decisões informadas sobre como melhorá-lo.
As métricas DORA podem ser calculadas manualmente usando informações do seu sistema de gerenciamento de projetos. Existem também ferramentas como as Quatro Chaves do Google Cloud que irão gerá-las automaticamente a partir das informações de confirmação. Algumas ferramentas do ecossistema, como o GitLab, também estão começando a incluir suporte integrado.
As melhores implementações de DevOps facilitarão mudanças rápidas e implementações regulares que raramente introduzem novos bugs. Qualquer regressão que ocorrer será tratada imediatamente, minimizando o tempo de inatividade para que os clientes tenham a melhor impressão do seu serviço. Acompanhar as tendências do DORA ao longo do tempo permite que você verifique se está atingindo esses ideais, oferecendo a melhor chance de sucesso no DevOps.
[ad_2]
