Quais são alguns métodos para medir o ROI do DevOps?

O DevOps é complexo e envolve muitos aspectos não determinísticos, como cultura e processo.
Quais são algumas maneiras de medir as iniciativas de DevOps para obter sucesso?
Como você prova para uma empresa que o investimento realizado está retornando (ou economizando) dólares reais?

Ótima pergunta! A maioria de nós sabe que investir em práticas de DevOps é uma busca que vale a pena por inúmeras razões; no entanto, geralmente não justificamos o DevOps apenas sobre o impacto nos resultados.

Nota : isso é uma pergunta opinativa, e minha resposta é igualmente opinativa.

Tensibai sabiamente sugeriu que encontrássemos as métricas corretas e usou o tempo de colocação no mercado como exemplo. Essa é uma ótima abordagem geral.

Como uma abordagem alternativa, minha experiência com contadores de feijão é que eles não precisam - ou necessariamente querem - conhecer o cenário geral, apenas querem evidências de responsabilidade fiscal. Eles querem ver uma tendência na direção certa.

Aqui estão apenas algumas vitórias fiscais:

• calcular os custos do servidor economizados, aproveitando o dimensionamento automático na nuvem
• para sites de geração de renda, extrapole o custo por minuto do tempo de inatividade e mostre melhorias no MTTI e MTTR
• novamente, para sites geradores de renda, estime o custo por minuto economizado, aproveitando a arquitetura altamente disponível com base em incidentes anteriores
• se você melhorou o pipeline de criação e implantação, mostre que reduziu regressões e erros na produção causados ​​por falhas já rastreadas
• se você fez melhorias nos ambientes de teste para desenvolvedores, ou mesmo nas ferramentas e na configuração dos laptops para desenvolvedores, consulte os históricos de confirmação para ver se novos engenheiros estão fazendo suas primeiras contribuições mais cedo depois de ingressar
• faça uma comparação completa de custos entre nuvem e on-prem, como o Gitlab fez recentemente , para justificar seus gastos em infraestrutura (também conhecido como economia!)

Mostrar que você está preocupado com dinheiro e tem algumas vitórias claras é muitas vezes suficiente. Eu certamente perdi alguns exemplos óbvios; fique à vontade para adicionar comentários abaixo.

A principal métrica para um pipeline do DevOps é o tempo de ciclo (também chamado de lead time ). É o tempo que leva para uma mudança (ou uma solicitação de mudança, acompanhando todo o caminho até o início da ideia). A melhor ilustração desse conceito que conheço é do livro "The Goal", que fala sobre isso em um contexto de fabricação.

A frequência de implantação também é útil. Queremos que as implantações sejam frequentes em um pipeline de DevOps. Não há medição mágica "1 dia é bom, 2 dias é ruim"; isso precisará de um contexto histórico no seu projeto para ser significativo.

Tamanho da implantação : medido no entanto, seus desenvolvedores medem o trabalho - histórias de usuários, histórias, quatloos, qualquer que seja. Novamente, você deseja ver as tendências ao longo do tempo, não o valor absoluto.

Entre frequência e tamanho, há uma história para contar. Nossos lançamentos estão se tornando menos frequentes e maiores? porque? Eles estão se tornando menores e mais frequentes? Novamente porque?

Explicando se a tendência de frequência / tamanho é boa, também precisaremos de Porcentagem de implantações com falha . Descobrir o 'porquê' nessas três métricas lhe dirá muito sobre a saúde do projeto.

Meu favorito pessoal, embora seja uma métrica de vaidade, é Hora de uma implantação trivial . Se você achou a menor coisa possível vale a pena reimplementar todo o site ... talvez um erro de digitação no nome do CEO ... com que rapidez você poderia passar da ligação telefônica em pânico para um site implantado? Digo 'vaidade' porque realmente não é tão preditivo além do que as outras métricas acima discutem, mas me faz sentir bem quando gosto do valor.

Se entrarmos no monitoramento, há várias coisas diferentes que podemos rastrear ... de coisas abrangentes como ' Uptime ' a coisas realmente de baixo nível, como o tempo gasto na regeneração de HTML personalizado em um ciclo de solicitação-resposta ... mas esses não são específicos para instituir uma cultura DevOps.

Eles não estão diretamente vinculados ao dinheiro ... isso exigirá mais conhecimento sobre sua organização do que posso oferecer em um fórum como este; mas eles são a chave para COMEÇAR a responder a essa pergunta. Depois de saber que é possível liberar regularmente o trabalho para produção como um não evento, você pode começar a ver quanto esforço estava desperdiçando antes. Como ensina o livro "O objetivo" (sobre pipelines de fabricação - é relevante), a otimização local pode parecer que você está economizando dinheiro, mas, em última análise, apenas cria valor que está associado ao estoque (recursos não implementados).

Além deste conselho, você deve dar uma olhada no Relatório State Of DevOps dos últimos anos. Isso está cheio de medições sobre projetos do mundo real que você pode emular.

Capitão óbvio: reduzindo o tempo de lançamento no mercado e os defeitos nos lançamentos.

Para estender essa linha, a armadilha usual é ser uma mudança de organização sem nenhuma referência.

Envolver uma mudança de cultura ou organização implica alguma despesa em treinar e apresentar as pessoas a esse novo método, isso tem um custo em treinamento, mas também implica uma perda de produtividade, pois as pessoas em uma sessão de trem não produzem nada. Esta é a parte de investimento da mudança cultural.

Para medir um ROI, primeiro você precisa encontrar algumas métricas relevantes que devem ser aprimoradas (entenda caro, caro ou fonte de perda de lucro). Esse pode ser um tempo menor para o mercado, menos correções após cada lançamento, um melhor envolvimento do cliente em seu produto. As métricas relevantes dependerão altamente do (s) seu (s) produto (s).

Medir um ROI (com que rapidez você cobriu as despesas de treinamento) implica que você pode apresentar de fato uma evolução nessas métricas; portanto, antes de iniciar qualquer mudança, você deve ter definido essas métricas e as medido de maneira objetiva.
Depois de ter uma evolução real para mostrar, você pode dizer se melhorou algo de uma maneira que cobriu as despesas de treinamento e se tornou mais lucrativo do que era antes.

A armadilha usual é envolver a mudança antes de definir qualquer métrica e, assim, avaliar o ROI com base em um sentimento e não em dados factuais.

A produtividade pode ser uma métrica, mas sua medição geralmente é muito difícil de ser feita de maneira objetiva e não deve ser uma métrica de primeira classe para esse tipo de estudo.

Tarde para o jogo aqui, mas pensei que eu iria gritar.

Você não pode gerenciar o que não mede; portanto, para iniciantes, eis as principais métricas que os devops devem acompanhar as equipes para resposta a incidentes:

• % De tempo de atividade : % total de tempo disponível = [tempo total - tempo de inatividade] / [tempo total]
• MTTR : tempo médio para resolução = [tempo de inatividade] / [# incidentes]
• MTTA : tempo médio para reconhecer = [tempo total para reconhecer] / [# de incidentes]
• MTBF : tempo médio entre falhas = [tempo total - tempo de inatividade] / [# de incidentes]

Essas métricas fornecem uma verificação de integridade de alto nível de suas operações e ajudam a identificar onde você precisa se aprofundar mais.

Dê uma olhada na animação do quadro branco aqui para uma visão mais aprofundada do tópico.

Depois de conhecer suas métricas, você poderá compará-las ao custo do tempo de inatividade . Você pode começar a desenvolver o ROI da sua equipe a partir daí e definir algumas métricas quantitativas para melhoria contínua.