Métricas DevOps: você está medindo o que importa?

Como você mede o sucesso da sua estratégia DevOps? Fale sobre as “métricas” para o trabalho DevOps ou infraestruturas nativas da nuvem, e a conversa tende a girar em torno de medidas operacionais e de produtividade familiares. Tempo de atividade. Transações por segundo. Erros corrigidos. Commits. Categorias familiares de dados que são diretas para acompanhar e pareceriam correlacionar ao menos passivamente com alguma combinação de eficiência, saúde do ambiente e velocidade de desenvolvimento.

É comum que as equipes de TI instrumentem e façam o log de tais dados – especialmente agora que o aprendizado de máquina e outras ferramentas modernas tornam muito mais fácil obter informações sobre grandes conjuntos de dados, seja para análise pró-ativa, preditiva ou análise de causa raiz após uma falha.

Essa não é uma métrica DevOps!

No entanto, isso não torna tudo uma métrica! Uma métrica é devidamente pensada como um indicador de desempenho chave para dados – uma medida que é substancialmente importante para você.

As métricas que você realmente deseja para o trabalho DevOps diferem do conjunto maior de dados que você pode coletar de 4 maneiras importantes:

1. Não deve haver muitas métricas DevOps. Selecione não mais que 10, e menos provavelmente é melhor. Escolher um conjunto de métricas de todas as coisas possíveis que você pode medir é um processo de seleção deliberado. Ao mesmo tempo, amplie sua rede de abrangência. Considere métricas que possam descobrir problemas organizacionais de saúde do negócio ou de processos mais amplos além de dados operacionais e de desenvolvimento mais óbvios que você pode coletar de seus sistemas de computador.

2. As métricas DevOps devem refletir o que é importante para você. Como você define o sucesso? Conforme observado pelo MIT Center for Information Systems Research (CISR), os projetos de transformação digital envolvem mudanças de etapas em duas dimensões: experiência do cliente e eficiência operacional. As métricas relevantes serão diferentes dependendo da dimensão em que uma organização optou pelo foco inicial. Se for a experiência do cliente, uma métrica como o Net Promoter Score pode ser apropriada. Se for a eficiência, medidas mais centradas em custos serão a melhor opção.

3. As métricas DevOps devem estar vinculadas aos resultados comerciais de alguma forma. Você provavelmente não se preocupa com o número de linhas de código criadas por seus desenvolvedores, se um servidor teve uma falha de hardware durante a noite ou a abrangência de sua cobertura de teste. Na verdade, você nem sequer se preocupa diretamente com a capacidade de resposta do seu site ou a rapidez de suas atualizações. Mas você se importa com o grau em que tais métricas possam estar correlacionadas com os clientes que abandonam os carrinhos de compras ou fizeram a compra no site concorrente.

4. Procure um caminho rastreável para causas raiz. É fácil encontrar métricas comerciais relevantes. Mas, na perspectiva do DevOps e das métricas de infraestrutura nativas da nuvem, é necessário que haja um caminho rastreável para as causas raiz que podem afetar as operações e as equipes de desenvolvimento. A escolha de métricas apropriadas é, portanto, um ponto de equilíbrio entre ser alto nível suficiente para ter um impacto mais ou menos direto sobre os resultados do negócio, enquanto suficientemente dentro da competência da TI em ações diretas para melhorar os resultados.

Melhores métricas DevOps

Conheça 3 exemplos de métricas DevOps que podem ser relevantes para uma organização:

O volume do ticket de cliente é um proxy razoável para a satisfação geral do cliente, o que, por sua vez, afeta fortemente as medidas de nível superior (e altamente avaliadas), como o Net Promoter Score, a vontade dos clientes de recomendar produtos ou serviços de uma empresa para outras. Ao mesmo tempo, os tickets tendem a ser arquivados por deficiências específicas relacionadas a aplicativos e infraestrutura.

Uma medida como a porcentagem de implementações com falha não está tão diretamente ligada a qualquer coisa que um cliente veja. Mas é indicativo de problemas de processo que podem levar a falhas visíveis ou apenas ao desperdício de esforço e tempo. Talvez a cobertura de teste esteja faltando, ou há apenas algum problema sistemático com o pipeline de build e deploy.

E sobre a satisfação no trabalho por parte da sua equipe de desenvolvimento? Falamos muito sobre a cultura quando estamos discutindo DevOps. Talvez seja boa ideia ter uma métrica ou duas que aponte para a eficácia da colaboração ou a eficiência de seus treinamentos e caminhos de carreira.

Cuidado com anti-padrões DevOps

Um cuidado importante: quando você está escolhendo métricas, esteja atento a “anti-padrões”, ou seja, métricas que encorajam comportamentos improdutivos ou negativos ou que simplesmente não são relevantes.
Como observa Daniel Ariely, um dos mentores da economia comportamental:

“Os seres humanos ajustam o comportamento com base nas métricas que lhes são imputadas. Em outras palavras, qualquer coisa que você mede levará uma pessoa a otimizar sua pontuação com base nessa métrica. O que você mede é o que você receberá”.

Medidas de produtividade individuais podem desencorajar a colaboração dentro e entre as equipes. E medidas de resultados simples, como o número de erros corrigidos, podem não se correlacionar bem com avaliações mais significativas da qualidade ou valor do código entregue aos clientes.

Talvez ainda mais comuns sejam as métricas DevOps coletadas, porque são fáceis de colecionar, mas na verdade não significam nada. Falhas que não são visíveis para os clientes podem ser indicativas de um problema de processo – ou podem simplesmente demonstrar que o serviço está funcionando conforme o projetado/planejado.

Colete dados de todas as formas. Armazene-os e analise-os. Cada vez mais esse é o padrão. Mas as métricas que você escolhe para traçar seu caminho e medir o sucesso DevOps devem envolver uma decisão deliberada.

Fonte: The Enterprises Project

  • Marco

    Aqui na empresa temos um indicador que mede o tempo que foi alocado em atividade faturável, isto é, o tempo que as equipes alocam em atividade de cliente. Espera-se que esse tempo alocado a cliente seja em torno de 90% e que 10% sejam alocados em tarefas de custo interno como treinamento, reuniões da empresa, indisponibilidade de máquina e a própria ociosidade quando não existir demanda.

    Para tanto, há um mecanismo de registro da atividade diária do colaborador. Para simplificar, precisamos apenas registrar o tempo que foi efetivamente trabalhado em atividade do cliente. Não registramos o tempo dedicado ao custo interno. No final, fazemos a conta entre o tempo registrado em atividade e o tempo que o empregado permaneceu na empresa. Como dito, espera-se que esta relação esteja dentro dos 90%.

    A grande dúvida: Seria desejável que fosse registrado de forma detalhada também o tempo relacionado ao custo interno, detalhando quando se tratar de um treinamento, de uma máquina com defeito que impediu o trabalho, de uma reunião geral com a diretoria, etc?

    1) O argumento a favor do sim é que precisamos medir o que pretendemos atacar. E neste caso seria minimizar (atacar) o tempo de custo interno. Classificando este tempo temos como identificar possibilidades de otimização e/ou eliminar problemas que impactam o tempo produtivo.

    2) O argumento contra é o de que só devemos nos concentrar em medir o que realmente importa que seria o tempo produtivo. Em The Lean Enterprise,
    Jez Jumble fala sobre a importância de medir a produtividade e o
    resultado – medir as coisas que são importantes para o resultado da
    organização – e não as perdas.

    E aí? Qual a melhor estratégia?

21