As Quatro Métricas de Accelerate
Tags: devops, sre, platformengineering
Published: 2023-03-28 02:11:25

For non-Portuguese speakers, there is an English version of this article [here](https://medium.com/@dmyoko/the-four-key-metrics-from-accelerate-a53f75c105b6).

Na última vez que conversamos, eu estava tentando explicar [como podemos usar uma cultura DevOps para desenvolver equipes de alto desempenho](https://dev.to/dmyoko/criando-equipes-de-alto-desempenho-com-a-cultura-devops-3d4o). Falei por um tempo sobre "_As Três Maneiras_" do livro de Gene Kim **The Phoenix Project**, e mencionei **Accelerate**, outro livro de Gene Kim (junto com Jez Humble e a Dra. Nicole Forsgren), como uma ideia para uma abordagem mais "_tática_" para estimular a _cultura DevOps_ dentro da organização. Hoje, quero explorar mais essa abordagem, explorando um pouco mais **Accelerate** e ver como ele pode estabelecer uma diretriz geral para avaliar o quão maduros os times estão em relação a DevOps e como podem melhorá-lo.

No mundo do _desenvolvimento e operações de software_, alto desempenho é fundamental. Mas como você mede o desempenho e quais métricas são mais importantes?

## Medindo a Maturidade do DevOps

Vamos deixar as coisas claras: **Não sou a favor da adoção de qualquer modelo de maturidade DevOps** para medir isso dentro de uma organização. _Accelerate_ esclarece que devemos focar em **capacidades** em vez de maturidade, e vou seguir o livro sobre este assunto. Todo o primeiro capítulo descreve o esforço dos autores para criar **medidas** e **métricas** que poderiam indicar equipes de bom desempenho e o quão confiáveis elas são quando usadas para entender como a organização se classifica nessas medições.

Ao nos concentrarmos em **capacidades**, nos referimos à _habilidade de uma equipe de executar determinadas práticas técnicas_ associadas ao alto desempenho. Essas práticas técnicas incluem coisas como _controle de versão_, _testes automatizados_, _integração contínua_ e _automação de deployment_, entre outras. Medir as capacidades envolve avaliar o nível de proficiência de uma equipe em cada uma dessas práticas técnicas.

De acordo com _Accelerate_, existem quatro métricas principais nas quais as equipes de alto desempenho se concentram:

-  Lead Time
-   Frequência de Deployment
-   Tempo médio para restaurar o Sistema (MTTR)
-   Percentual de falha de mudança

Essas métricas fornecem uma visão abrangente do **desempenho operacional e de entrega de software** e mostraram ser fortes preditores do desempenho organizacional.

De acordo com Kim, "As organizações mais bem-sucedidas são aquelas capazes de alcançar altos níveis de **throughput** e **estabilidade**". Throughput (vazão) refere-se à capacidade de entregar novos recursos e atualizações rapidamente, enquanto estabilidade refere-se à capacidade de fazê-lo de forma confiável e com altos níveis de qualidade.

Vamos dar uma olhada mais de perto em cada uma das quatro métricas principais:

## Lead Time

"Os melhores desempenhos têm Lead Time inferior a um dia, enquanto os piores desempenhos têm Lead Time superior a um mês." - Accelerate

**Lead Time** mede o tempo que leva para que uma mudança de código seja implementada e implantada em produção. Equipes de alto desempenho têm um Lead Time significativamente mais curto do que equipes de baixo desempenho, permitindo que elas entreguem valor aos clientes mais rapidamente e respondam mais rapidamente às condições de mercado em constante mudança.

Para alcançar um curto Lead Time, equipes de alto desempenho utilizam práticas como **integração e entrega contínuas**, **teste automatizado** e **pequenos lotes de entrega**. Automatizando tarefas repetitivas e dividindo o trabalho em peças menores, as equipes podem reduzir o tempo necessário para implementar mudanças de código em produção.

## Frequência de Deployment

"Os melhores desempenhos implantam o código várias vezes por dia, enquanto os piores desempenhos implantam o código uma vez por mês ou menos." - Accelerate

**Frequência de Deployment** mede com que frequência as mudanças são implantadas em produção. Equipes de alto desempenho implantam mudanças com muito mais frequência do que equipes de baixo desempenho, permitindo que elas respondam às necessidades dos clientes mais rapidamente e iterem seu produto mais rapidamente.

No entanto, é importante observar que a frequência de deployment não deve ser perseguida às custas da estabilidade e confiabilidade. Equipes de alto desempenho são capazes de alcançar deployments frequentes e altos níveis de estabilidade por meio de práticas como **teste automatizado**, **integração contínua** e **entrega contínua**.

## Tempo Médio de Restauração de Serviço (MTTR)

"Os melhores desempenhos têm tempos para restaurar o serviço inferiores a uma hora, enquanto os piores desempenhos têm tempos para restaurar o serviço superiores a um dia." - Accelerate

**Tempo Médio de Restauração do Serviço** mede o tempo que leva para restaurar o serviço após um incidente ou interrupção de produção. Equipes de alto desempenho são capazes de diagnosticar e corrigir rapidamente problemas em produção, minimizando o impacto nos clientes e reduzindo o tempo de queda do sistema.

Para alcançar tempos de restauração curtos, equipes de alto desempenho utilizam práticas como **monitoramento**, **alertas** e **processos de resposta a incidentes**. Monitorando proativamente seus sistemas, as equipes podem identificar rapidamente problemas quando ocorrem e respondem a eles antes que afetem os clientes. Quando um incidente ocorre, equipes com processos de resposta a incidentes fortes podem mobilizar rapidamente e trabalhar juntas para diagnosticar e corrigir o problema.

## Percentual de Mudanças com Falha

"Os melhores desempenhos têm taxas de falha de mudança de menos de 15%, enquanto os piores desempenhos têm taxas de falha de mudança de mais de 46%." - Accelerate

**Percentual de Mudanças com Falha** mede a porcentagem de mudanças que resultam em uma falha ou defeito que deve ser corrigido. As equipes de alto desempenho têm taxas de falha de mudança significativamente menores do que as equipes de baixo desempenho, indicando que elas conseguem entregar mudanças para produção com níveis mais altos de qualidade.

Para alcançar baixas taxas de falha de mudança, equipes de alto desempenho utilizam práticas como **teste automatizado**, **integração contínua** e **entrega contínua**. Ao identificar problemas mais cedo no processo de desenvolvimento e garantir que as mudanças sejam testadas com rigor antes de serem implantadas, as equipes podem reduzir a probabilidade de defeitos e falhas na produção.

Também é importante observar que a taxa de falha da mudança não deve ser vista como uma métrica punitiva. Em vez disso, ela deve ser usada para identificar áreas de melhoria e impulsionar a melhoria contínua no processo de desenvolvimento.

## Quinta Métrica do DORA: A Métrica de Desempenho Operacional

Isso mesmo ... há uma quinta métrica para as 4 Métricas Principais, assim como os Três Mosqueteiros (que eram na verdade quatro).

Além dessas quatro métricas principais, o DORA (DevOps Research and Assessment) tem uma métrica adicional para **Desempenho Operacional**, baseada em Confiabilidade. É uma medida de _práticas operacionais_ modernas, indicando o quão bem os serviços atendem às expectativas do usuário, como _disponibilidade_, _latência_, _desempenho_ e _escalabilidade_. De acordo com o [2022 State of DevOps Report do DORA](https://cloud.google.com/devops/state-of-devops/), equipes com diferentes graus de _desempenho de entrega_ têm melhores resultados (por exemplo: menos _burnout_) quando também priorizam o desempenho operacional.

_Fitness Functions_ podem ser úteis para executar diagnósticos de desempenho e escalabilidade dentro do fluxo de trabalho de desenvolvimento, enquanto o _monitoramento_ garantiria que o ambiente de produção garanta a consistência em relação a esse diagnóstico.

## O que significa ser uma equipe de alta performance?

Tenho falado muito sobre usar a cultura DevOps para criar equipes de alta performance em uma organização e trouxe métricas para a discussão. Obviamente, medir com que frequência uma equipe consegue implementar ou quanto tempo leva para uma nova mudança chegar à produção dá à equipe um feedback sólido sobre sua própria maturidade. No livro Accelerate, os autores descrevem como usaram análise de cluster para categorizar o desempenho das equipes com base nos dados fornecidos pelos entrevistados. Eles aplicaram essa técnica por quatro anos de pesquisa (os resultados foram publicados pela Puppet como o relatório "State of DevOps Report" de 2014 a 2017) e descobriram que a cada ano havia categorias significativamente consistentes de desempenho na entrega de software na indústria.

Veja como os resultados de 2016 comparados às descobertas de dados em 2017 ilustram como as quatro métricas-chave ajudaram a análise de cluster a categorizar o desempenho (fonte: Accelerate):

| 2016 | Alto Desempenho | Desempenho Médio | Baixo Desempenho | 
| - | - | - | - |
| Frequência de Deployment | Sob demanda (múltiplas implementações por dia) | Entre uma vez por semana e uma vez por mês | Entre uma vez por mês e uma vez a cada seis meses | 
| Lead Time | Menos de uma hora | Entre uma semana e um mês | Entre um mês e seis meses | 
| MTTR | Menos de uma hora | Menos de um dia | Menos de um dia* | 
| Taxa de Falha na Mudança | 0-15% | 31-45% | 16-30% |

| 2017 | Alto Desempenho | Desempenho Médio | Baixo Desempenho | 
| - | - | - | - |
| Frequência de Deployment | Sob demanda (múltiplas implementações por dia) | Entre uma vez por semana e uma vez por mês | Entre uma vez por semana e uma vez por mês* | 
| Lead Time | Menos de uma hora | Entre uma semana e um mês | Entre uma semana e um mês* | 
| MTTR | Menos de uma hora | Menos de um dia | Entre um dia e uma semana | 
| Taxa de Falha na Mudança | 0-15% | 0-15% | 31-45% |
_* Baixo desempenho foi menor em média (em um nível estatisticamente significativo), mas teve a mesma mediana que o desempenho médio._

Observe como o limite que distingue as categorias de desempenho para a _Taxa de Falha de Mudança_ muda nos dados de 2016 para os dados de 2017: os times de Desempenho Médio melhoraram seu resultado de 21-45% em 2016 para 0-15% em 2017, sendo comparáveis aos times de Alto Desempenho, enquanto o oposto aconteceu com os Times de Baixo Desempenho, que tiveram 16-30% em 2016, mas em 2017 a análise os agrupou para serem entre 31-45%.

Recomendo ler o livro para obter mais informações sobre como a pesquisa foi projetada e como os autores usaram os dados. É uma excelente fonte de informação e continua explicando todo o processo de pesquisa.

## Como as equipes de Engenharia de Plataforma e SRE podem ajudar a melhorar essas métricas?

Agora que estamos familiarizados com as Quatro Métricas Principais, vamos falar sobre como a Engenharia de Plataforma e SRE podem contribuir para ajudar as equipes a terem um desempenho melhor nessas métricas.

Primeiro, quando se trata de estabilidade, as métricas de "Desempenho Operacional", e todas as boas práticas mencionadas pelo Relatório DORA que contribuem para essa medição, acabam se resumindo ao que chamamos de Confiabilidade (Reliability). É senso comum que o software falha de vez em quando, algo errado vai acontecer, alguma parte do software vai se comportar mal, ou alguma máquina arbitrária vai falhar, a conectividade com a internet será perdida, uma série de coisas pode acontecer (e elas acontecerão, em Murphy devemos confiar). Confiabilidade é uma forma de medir o quão sólido é o seu sistema de monitoramento e o quão capaz você é de reconhecer que algo está errado para agir rápido, ou até mesmo para evitar a necessidade de reagir a tais cenários, preparando tarefas automatizadas que antecipam tais falhas e fazem com que todo o sistema reaja automaticamente a falhas (quase como se fosse capaz de se auto-restaurar). Esse é o objetivo da Engenharia de Confiabilidade do Site (SRE).

Em primeiro lugar, é crucial que a organização seja capaz de determinar que tipo de Operação de Desempenho é considerado "suficientemente bom" para manter, e o que é "suficientemente ruim" para agir. Isso tem que ser definido com base em como o usuário experimenta o produto: qual é a linha de base de latência que impacta na conversão, a partir de qual ponto a disponibilidade não vale a pena ser melhorada, pois provavelmente não será experimentada pelo usuário, o quanto estamos cientes da capacidade de carga para todo o sistema, para que possamos ser capazes de responder quando essa carga é excedida, e fazermos isso de maneira que o sistema seja capaz de lidar com a nova carga.

Para fazer isso, o SRE ajuda a organização a definir os Indicadores de Nível de Serviço (SLIs) que serão medidos, a fim de definir o que seria considerado "bom desempenho", e quando devemos tratá-lo como "ruim", esses limites são chamados de Objetivos de Nível de Serviço (SLOs), e eles ajudam as equipes a entender quando algo está errado. Em um artigo futuro, espero poder falar mais sobre SLIs e SLOs, bem como explorar Error Budgets e explicar mais sobre Observabilidade.

Quando se trata de Platform-Engineering, muito pode ser alcançado pelas equipes de entrega de software quando há um conjunto de ferramentas disponíveis para tornar todo o SDLC mais suave e confiável. Isso varia desde coisas simples como fornecer um Sistema de Controle de Versão e ferramentas de automação de compilação, permitir Integração Contínua e Entrega Contínua, até trazer ferramentas para o fluxo de trabalho para melhorar a segurança (shift-left on security) e automatizar toda a operação para o sistema e suas partes (gerenciamento de configuração, estratégias de rollout, circuit-breaking, etc.), idealmente abstraindo todo o "encanamento" da infraestrutura (containers, orquestração, proxies reversos, malhas de serviços, etc) para tornar todo o processo de publicação de serviços em produção mais fácil ao longo do tempo.

Não há dúvida de que teremos muito o que discutir no futuro para abordar como uma equipe de Platform-Engineering pode contribuir para criar fluxos de trabalho de entrega de software de alta performance.

No entanto, as equipes de entrega de software ainda são responsáveis por controlar a qualidade de seu software, automatizando testes e executando ferramentas de verificação de qualidade de código (padrões e métricas de análises).

## Conclusão

Os quatro principais indicadores apresentados pelo livro _Accelerate_ - Lead Time, frequência de deployment, tempo médio para restauração (MTTR) e taxa de falha de mudança - são ferramentas poderosas para avaliar a performance de equipes de software e operações e para identificar áreas de melhoria. Esses indicadores fornecem uma visão geral da entrega de software e desempenho operacional e têm sido mostrados como preditores fortes de desempenho organizacional.

Ao se concentrar nas capacidades das equipes em vez de sua maturidade em DevOps, as empresas podem obter insights valiosos sobre sua capacidade de entregar software de alta qualidade com rapidez e segurança. Com as práticas adequadas, como controle de versão, testes automatizados, integração contínua e automação de implantação, entre outras, as equipes podem melhorar esses quatro indicadores-chave e alcançar desempenho de alta qualidade.

Em resumo, a adoção de uma cultura DevOps é fundamental para as empresas que buscam alcançar um alto desempenho em seus projetos de software e operações. Com a ajuda de práticas de automação e ferramentas adequadas, as equipes podem melhorar significativamente sua capacidade de entrega de software com rapidez e segurança, mantendo altos níveis de qualidade e estabilidade. E a avaliação constante dos quatro principais indicadores de desempenho pode ajudar a garantir que as equipes estejam no caminho certo para atingir esses objetivos.

P.S.: Quero agradecer meus amigos @danielpilon e Frederico Vitorino pela revisão. Eu amo vocês.