Estou tentando direcionar bons comportamentos em um programa de transformação do DevOps. Para apoiar isso, estou procurando identificar métricas acionáveis em torno das disciplinas de operações:
- Gerenciamento de Problemas e Incidentes
- Gerenciamento de capacidade
- Gerenciamento de alterações e liberações
Para ser absolutamente claro, essas são funções que pertenciam à organização de operações e agora pertencem à organização Agile / DevOps. Existem KPIs existentes que geram comportamentos ruins são:
- Tempo para análise da causa raiz concluída:
- Gera RCAs incompletos apenas para colocá-los no sistema no prazo.
- Duração da execução do teste:
- Desativa testes de execução longa, independentemente de seu valor comercial.
- Utilização média de serviços em nuvem:
- Incentiva o comprometimento excessivo dos recursos de computação, resultando em tempos de resposta lentos
Quais indicadores-chave de desempenho podem ser usados para incentivar o bom comportamento em um programa DevOps?
Respostas:
Eu não acho que haja KPIs do DevOps "universais". Por exemplo, a velocidade é ótima, a menos que não seja um fator essencial para os seus negócios. A Amazon se preocupa muito com a velocidade, porque eles têm uma operação de varejo maciça. Isso é menos importante para um aplicativo pequeno com 100 usuários.
Isso levanta a questão: como você seleciona os melhores KPIs relevantes para o seu negócio? Esse é um processo de pesquisa e descoberta que envolve toda a empresa.
Você se importa com o quê?
O que mantém as partes interessadas da sua empresa acordadas à noite? O que determina se você ganha dinheiro neste trimestre ou não? A lista acima pode incluir algumas dessas coisas ou não. Faça sua lista e descubra como alinhar os incentivos em todos os departamentos para alcançá-los.
Os incentivos direcionam o comportamento; portanto, decida colaborativamente sobre as metas da SMART. Escolha dois ou três itens da sua lista de ideias e inicie um ciclo de medida / correção para cada um. Não escolha muitos de uma vez - é mais provável que você consiga se concentrar muito em duas ou três coisas.
fonte
O DevOps não possui nenhum KPI . Seria como perguntar quais são os KPIs do amor. Mas algumas das coisas que você mencionou ( Problema e Gerenciamento de Incidentes , Capacidade de Gestão , Mudança e Release Management ) têm boa KPI, alguns dos quais são baseados na teoria por trás DevOps.
Em geral, para qualquer processo de negócios, você pode criar um Mapa da Cadeia de Valor descrevendo como o valor flui do Cliente , pela empresa, de volta ao Cliente . Todo o ciclo sempre tem que começar e terminar com o Cliente, mas às vezes, para uma organização de serviço, o Cliente pode ser interno. A taxa de transferência de valor através dessa cadeia pode ser uma boa maneira de projetar seu KPI de maneira inviolável. Medir qualquer KPI em qualquer link individual da cadeia de valor só faz sentido desde que esse link específico seja o gargalo do processo e você tente explorar ou elevar o gargalo.
Um problema comum com o KPI é quando ele começa na metade da cadeia. Por exemplo, um processo de alteração e liberação geralmente começa com os desenvolvedores e termina com a implantação. Este processo excluiu:
O problema é que medir um tempo de ciclo sozinho pode levar a dois grandes problemas:
O gargalo está em qualquer uma das partes excluídas mencionadas acima e seus clientes não estão percebendo o valor e você não está percebendo a receita proporcional à velocidade do seu tempo de ciclo. Portanto, enquanto sua engenharia é excelente, sua empresa sofre.
A desconexão dos clientes fará com que seu ciclo de liberação fique vazio - sem produzir nenhum valor, apesar da alteração ser feita - ou até contrarie as necessidades de seus clientes e o trabalho que está sendo feito pode ter um valor comercial negativo.
Outro problema com o KPI é que, ao iniciar e terminar com um cliente, ele pode não realmente medir o valor para o cliente. Um bom exemplo seria um processo de resposta a problemas e incidentes e o MTTR (tempo médio de reparo) como KPI. O problema afeta alguém? Qual é o valor para os clientes? Você pode ter um excelente MTTR de 3 horas em mais de 100 incidentes. Porém, se a maioria deles era interna, com impacto mínimo ou mínimo para os clientes e resolvida em minutos, enquanto o único grande incidente com grande impacto no cliente levou três dias para ser gerenciado, o valor do negócio é menor do que se você tivesse um dia de MTTR, porque você ignore a maioria dos incidentes internos, mas você respondeu ao enorme incidente de impacto no cliente em 1 hora.
NOTA: Para um cliente interno, no caso do processo de negócios da equipe de suporte, o valor derivado não é o valor do trabalho para o cliente interno, mas o valor obtido pela empresa ao desbloquear o cliente interno em seu próprio processo de negócios. Desbloquear uma equipe que é um gargalo em seu próprio processo obtém um valor mais alto do que desbloquear uma equipe ou indivíduo que não seja gargalo. Todos os KPIs dessa equipe de suporte precisam incluir o valor comercial em seus cálculos.
fonte
E, finalmente,
fonte
5.DevOpsCulture, which actually can’t be measured=> faça um questionário anônimo para todos os envolvidos, mesmo que ligeiramente, e pergunte como eles se sentem sobre tudo isso. Isso certamente lhe dirá se você tem um processo que é vivido por seu povo, ou se muitas pessoas estão na verdade a meio caminho da porta ...