4 Key Metrics: Quatro Métricas-Chave em eficiência digital

Em 2018, o antropólogo norte-americano Jamais Cascio criou a sigla BANI para definir a dinâmica atual do mundo, um acrônimo dos termos em inglês para frágil, ansioso, não linear e incompreensível. Nesse ecossistema, empresas precisam atender às expectativas e às necessidades de clientes com alta velocidade, assim como acompanhar mudanças de maneira não linear, o que é proporcionado por developer velocity adequada (capacitação de equipes de desenvolvimento que as torne mais ágeis, inovadoras e produtivas em todas as áreas de operações) e eficiência digital. 

Muitas não conseguem, mas um framework capaz de orientar organizações na superação de desafios vem ganhando popularidade no universo DevOps: as Quatro Métricas-Chave orientadas pela Google (4 Key Metrics).

Tais métricas foram citadas pela primeira vez no livro Accelerate, de Nicole Forsgren, Jez Humble e Gene Kim. A obra foi base de estudo para o DevOps Research and Assessment (Dora), uma pesquisa patrocinada pelo Google.

Por sua vez, a iniciativa da gigante das buscas divulga anualmente um relatório chamado State of DevOps, que mostra as melhores práticas de DevOps aplicadas nas empresas pelo mundo e divide as organizações entre entre Low, Medium, High e Elite performers. Mais de 30 mil pessoas participam do levantamento todos os anos.

Segundo o State of DevOps, Elite performers fazem deployment de código 208 vezes mais rápido do que Low performers, além de realizarem entregas 106 vezes mais rápido. O tempo para recuperação de falhas dessas empresas é 2.604 vezes mais ágil, e a taxa de implantações com falhas é 7 vezes menor.

Considerando que as Quatro Métricas-Chave exercem papel fundamental nessa classificação, é interessante trabalhar com esse framework porque ele é didático, consegue conversar com todos os níveis das operações e promove diversas disciplinas a serem trabalhadas na evolução da eficiência digital de uma companhia, destacando as ações voltadas ao aprimoramento de developer velocity mais necessárias a cada caso.

Saiba mais a respeito das 4 Key Metrics a seguir.

Developer velocity e eficiência digital: como chegar lá?

Silos dentro das empresas, propósitos descentralizados, excesso de perfeccionismo e falta de aprendizado contínuo afetam negativamente a developer velocity e são alguns dos obstáculos enfrentados por empresas na busca pela eficiência digital.

Visando contemplar a maior gama possível de aspectos capazes de gerar prejuízos aos negócios, as Quatro Métricas-Chave consideram duas perspectivas fundamentais descritas a seguir.

• Velocidade — deployment frequency (frequência de implantação de códigos novos em produção) e lead time for changes (tempo para o commit sair da máquina do desenvolvedor até chegar à produção);
• Estabilidade — change failure rate (das implantações totais, aquelas que originaram incidentes em produção que impactaram o usuário) e mean time to recover (tempo desde a identificação de um incidente até a correção desse problema em produção).

É preciso ter em mente que as 4 Key Metrics não "abrem mão" de estabilidade em prol de uma simples velocidade de entrega. Agora, vamos conhecê-las.

1. Deployment Frequency

Deployment Frequency é a métrica que vai definir qual é a frequência de deploys em produção, ou seja, a frequência de inserção de novos códigos no ambiente produtivo. É ela que puxa todas as outras key metrics.

Teoricamente, quanto mais deploys são feitos, menor o lead time, menores as taxas de implantações e maior a recuperação de falhas. No Accelerate e na pesquisa do Dora, Deployment Frequency pode ser dividida nas etapas a seguir.

• Low performers — entre 1 deploy mensal e 1 a cada 6 meses.
• Medium performers — deploys entre 1 semana e 1 mês.
• High performers — deploys entre 1 por dia e 1 por semana.
• Elite performers — deploy sob demanda ou vários ao dia.

Fazer deploys sob demanda significa ter maturidade suficiente no processo. Isso porque, em cenários produtivos reais, não é interessante nem possível, muitas vezes, fazer múltiplos deploys ao dia devido a limitações. De todo modo, a definição de mecanismos para agir dessa maneira se desejado ou se necessário faz parte de uma decisão de negócio (eliminando, assim, restrições técnicas).

Vale lembrar também que implantações frequentes tornam a recuperação das falhas muito mais fácil, assim como a detecção de problemas. No mais, não se deve confundir Deployment Frequency com "Volume com Frequência". 

É preferível fazer deploys continuamente na linha do tempo de produção, dividindo-os e tornando-os concisos e constantes. Não adianta 10 deploys em 1 dia, mas 29 dias sem e 10 deploys no fim do mês.

Entre as causas de baixa frequência podem estar:

• Alto número de modificações e mudanças frequentes durante o ciclo de desenvolvimento;
• Falta de mecanismos de testes automatizados dentro da pipeline de continuous delivery/continuous integration (CD/CI);
• Desbalanceamento da estrutura organizacional;
• Ineficiência no processo de deployment, que pode ser ocasionada por diversos blocks, caminhos críticos para chegar à produção e muita burocracia.

Se o objetivo for otimizar Deployment Frequency e, consequentemente, developer velocity, aqui vão algumas dicas:

• Implementar uma esteira de CD/CI de maneira mais integrada, com testes automatizados;
• Trabalhar com pacotes menores de código em produção, havendo, assim, um tracking aprimorado de falhas em produção;
• Reduzir o número de débitos técnicos da aplicação;
• Planejar as entregas em releases, sem acúmulo de muito código.

2. Lead time for changes

Segunda métrica no pilar velocidade das 4 Key Metrics, Lead Time For Changes prega que se deve calcular a diferença entre o commit da máquina do desenvolvedor a partir do momento em que este é efetuado até aquele em que ele chega à produção. Isso revela qual é o tempo de desenvolvimento dentro do processo de DevOps para possibilitar a ativação de novas features em produção.

Assim como as outras métricas-chave, é dividido entre Low, Medium, High e Elite performers, estando intimamente ligado ao Deployment Frequency, uma vez que a frequência de deploys é ajudada por um Lead Time For Changes cada vez menor. 

Sua importância reside no fato de que uma taxa baixa consegue habilitar um feedback muito maior e com um ciclo muito menor de desenvolvimento, fornecendo uma noção exata de onde e quando corrigir o curso das alterações.

Aliás, dentro das key metrics, o Lead Time For Changes é mais indicado do que o Cycle Time e o Lead Time por proteger projetos de ciclos anteriores ao desenvolvimento, muitas vezes complexos e diferentes de acordo com o contexto. Tanto Cycle Time quanto Lead Time dependem muito da área de negócio e das áreas burocráticas do cliente.

Por outro lado, o Lead Time For Changes não tem essa dependência, uma vez que o processo de mensuração geralmente é padrão, com alguns desvios mínimos. Ainda assim, é importante frisar que o Lead Time For Changes é uma aproximação, uma média das datas (entre a do commit e a em que aquele deploy foi feito) efetuada ao longo do tempo a ser considerado.

Algumas das possíveis formas de se calcular essa métrica incluem alguns mecanismos que, cruzados, podem promover insights interessantes e impulsionar estratégias voltadas à eficiência digital:

• Kanban;
• Issue trackers (como Gira e ServiceNow);
• Pipelines de CI/CD;
• Git hooks;
• Próprio repositório de código com Patterns, usando tags e branches.

Falando das causas para um Lead Time For Changes alto, algumas delas podem ser:

• Número alto de mudanças não planejadas ao longo do processo de desenvolvimento;
• Falta de clareza de requisitos;
• Ausência de um critério de Ready definido;
• Testes muito custosos e feitos de maneira manual;
• Gargalos e rotas complexos e desnecessários;
• Burocracia com várias etapas de aprovação.

Felizmente, há maneiras de reduzi-lo, que são elas:

• Trabalhar sempre tendo em vista mudanças pequenas e autossuficientes;
• Incorporar testes automatizados dentro da pipeline de CI/CD;
• Avaliar novas opções de gerenciamento de códigos e de modelos novos de SCM (trunk based e baseados em feature toggle, por exemplo, habilitando, inclusive, uma frequência de deploys mais alta).

3. Change failure rate

Chegamos à terceira métrica-chave: a change failure rate. Diz respeito à porcentagem de deploys que causaram falhas em uma produção após a aplicação de mudanças (queda de serviço, por exemplo). Problemas que ocorram em fases de testes não entram nessa conta, assim como falhas que não tenham a ver com novos deploys.

Seu resultado é obtido da seguinte forma: divisão de deploys falhos pelo total de deploys em um determinado período. Nesse caso, o ideal é que a taxa esteja o mais próximo de zero possível. Elite performers, por exemplo, apresentam um Change Failure Rate de 0% a 15%, segundo o State of DevOps 2021; os demais, de 16% a 30%.

Além de oferecer informações valiosas a respeito de developer velocity, essa métrica-chave revela a capacidade de aprendizado de profissionais com erros passados. Aliás, como nas situações anteriores, existem algumas circunstâncias que podem prejudicar a taxa, afetando a progressão da eficiência digital, a exemplo de:

• Deploys manuais, suscetíveis a erros humanos;
• Mudanças em infraestruturas não replicáveis;
• Execução manual de testes;
• Má qualidade de códigos, dificultando a manutenção e a introdução de novos códigos, levando a uma maior complexidade e a falhas inesperadas.

Porém, algumas medidas podem otimizar os resultados:

• Trabalhar em mudanças menores e autossuficientes;
• Assegurar que configurações de ações críticas e de infraestruturas cruciais para o serviço estejam visíveis e sejam replicáveis;
• Incorporar automação em todo estágio do pipeline CI/CD;
• Automatizar revisões de códigos com ferramentas específicas que podem ajudar a aprimorar códigos e economizar tempo, como o Codacy.

4. Time to recover

Encerrando a lista das quatro métricas-chave está Time To Recover, outra no pilar estabilidade. Está relacionada ao tempo que se leva para se recuperar de um problema que impacta o usuário em produção, considerando desde a detecção da falha até a correção e normalização do serviço para o usuário final.

Dividida entre os níveis Low, Medium, High e Elite performers, é também chamada de Mean Time To Recover (MTTR) e trata-se, inclusive, de um desdobramento geral dos outros vários MTT que existem no processo, englobando-os em uma única métrica (a saber, Mean Time to Detect, Mean Time to Repair, Mean Time to Discover).

Visto que falhas são comuns, apresentar um baixo Time To Recover é um diferencial para uma empresa, pois ele diz muito acerca do processo e da tolerância a falhas; um tempo baixo de recuperação de um serviço representa alta maturidade em resposta a crises, portanto developer velocity adequada e, claro, preocupação com a eficiência digital.

Para calculá-lo, basta definir um período a ser avaliado e fazer a média de tempos entre o surgimento de problemas e a realização de deploys de correção no timebox determinado.

Um alto Time To Recover pode ter diversas causas, entre elas:

• Testes muitos custosos ou feitos manualmente;
• Desbalanceamento de pessoas na estrutura organizacional do time ou da empresa;
• Processos de gerenciamento de incidentes ineficientes, com muitas etapas ou sem responsáveis definidos;
• Não uso de ferramentas para issue tracking (ou uso incorreto);
• Ausência de ferramentas de monitoria; 
• Alertas que não são propriamente configurados.

Por fim, seguem algumas dicas para reduzi-lo:

• Atentar-se à estrutura organizacional, colocando pessoas com papéis corretos nos lugares e nos momentos certos;
• Implementar testes automatizados e integrados à pipeline de CI/CD;
• Providenciar documentos claros sobre o processo de gerenciamento de incidentes (com as etapas bem definidas e seus respectivos responsáveis);
• Encontrar potenciais etapas dentro do processo de gerenciamento de incidentes que possam ser automatizadas, evitando cada vez mais a interferência manual;
• Preparar a aplicação para cenários de crise, com alertas específicos de erros.

4 Key Metrics e a busca pelo alto desempenho

Juntas, Deployment Frequency, Lead Time For Changes, Change Failure Rate e Time To Recover, as Quatro Métricas-Chave, oferecem um panorama completo da saúde de equipes de desenvolvimento e empresas, além de informações e meios para elas atingirem o posto de Elite performers graças à developer velocity e à eficiência digital que constroem durante o processo.

---