desafio de métricas de implantação pré-DevOps

TL; DR, como você prova que os devops, especificamente a automação de implantação, melhoram as taxas de falha de alteração?

Todos nós estamos tentando capturar métricas sobre 'falhas de implantação' usando os meios atuais (principalmente manuais). Infelizmente, uma "falha" raramente acontece, certo? Porque quando algo dá errado, a equipe se reúne (geralmente com heroísmo) para corrigir o problema (geralmente permissões, configurações perdidas, você sabe o que fazer). Então ... quando perguntamos como foi a implantação, a resposta é "funcionou".

Mas, intuitivamente, todos sabemos que isso não é bom. O relatório do estado dos devops de 2017 diz que há uma taxa de falha de alteração de 31 a 45% . Embora isso pareça intuitivo, eles são rastreados como incidentes? Nah. Porque eles são corrigidos rapidamente, geralmente durante a validação. É muito mais raro reverter uma implantação.

Portanto, é preciso disciplina para relatar taxas de falha com precisão. Não estamos motivados a relatar assim, porque queremos que as coisas funcionem e fazemos o que é preciso para que isso aconteça.

Então, como você prova que os devops, especificamente a automação de implantação, melhoram as taxas de falha de alteração?

(O PS tentou marcar isso com "# devops-capacity-model")

Uma técnica que usamos no passado em situações semelhantes é obter "compromisso de gerenciamento" que impõe essas regras a todos os membros da equipe:

1. O acesso para realizar atualizações nas áreas de implantação de destino (ou seja, produção) é limitado a sistemas automatizados selecionados, que possuem trilhas de auditoria apropriadas (= registro em log) de qualquer tipo de atualização nas áreas que gerenciam.

2. As atualizações manuais nas áreas de implantação de destino, por qualquer motivo, não são mais permitidas pelos membros típicos da equipe (IDs de usuário) que costumavam ser capazes (autorizados) de executar essas atualizações. Em vez disso, serão criados NOVOS IDs de usuário (adicionais) que terão todas as permissões necessárias para (ainda) executar essas atualizações manuais, sempre que necessário. Porém, para realmente poder usar esses novos IDs de usuário (= realizar um logon com eles), o membro da equipe que deseja realizar um logon com esse novo ID de usuário precisará executar "algumas" etapas extras para obter acesso à senha para esse novo ID de usuário. Idealmente, essa etapa extra também é automatizada (use sua própria imaginação como deve ser), mas se algo mais falhar: basta entrar em contato (= e-mail, ligar, etc.) com o guardião da senha necessária, incluindo "qual problema eles têm ser consertado "

3. Colocar esse guardião no portão não é uma tarefa fácil. E a maior resistência virá dos ... membros da equipe (por todo o tipo de razões). Portanto, uma variação desses novos IDs de usuário (como na etapa anterior) é que cada membro da equipe obtém um ID de usuário extra (com a senha que eles próprios decidem), mas com uma sequência extra anexada a ele: eles só podem executar uma faça logon com esse ID de usuário (extra) se eles realmente tiverem um bom motivo para fazê-lo. E cada vez que eles realizam esse logon, são solicitados a apresentar algum tipo de relatório sobre "qual problema foi corrigido" (semelhante à sua pergunta).

Com esses procedimentos, tudo o que resta a fazer é revisar periodicamente cada um desses relatórios / razões pelas quais foi necessário o uso de um ID de usuário especial e fazer a pergunta " Existe algo que possa ser feito para automatizar ainda mais isso, para reduzir ainda mais a necessidade desse login especial? ".

Atualização :

Cite seu comentário extra abaixo desta resposta:

Eu acho que adicionar barreiras artificiais para corrigir um problema de implantação é contraproducente.

É verdade que acrescenta uma barreira extra, mas não estou convencido de que seja "artificial". Pelo que sei, essa é a única maneira de tomar conhecimento de coisas que os membros da equipe nunca lhe dirão, por razões como:

• seguro desemprego.
• coisas ruins / práticas que eles preferem manter escondidos.
• poder que eles não querem perder.

O relatório do estado dos devops de 2017 diz que há uma taxa de falha de mudança de 31 a 45%. Embora isso pareça intuitivamente correto, eles são rastreados como incidentes? Nah. Porque eles são corrigidos rapidamente, geralmente durante a validação.

Um problema corrigido rapidamente ainda é um problema. Se você não está relatando isso como tal, isso é um problema.

Portanto, é preciso disciplina para relatar taxas de falha com precisão. Não estamos motivados a relatar assim, porque queremos que as coisas funcionem e fazemos o que é preciso para que isso aconteça.

Se seu objetivo é realmente fazer as coisas funcionarem, você precisa ser honesto sobre falhas, para poder evitá-las no futuro. Parece que a equipe aqui está mentindo (talvez para si próprios, certamente para a gerência) sobre falhas, porque seu objetivo é fazer com que as coisas pareçam estar funcionando.

Essas são coisas diferentes. Por exemplo, considere a velha piada de que o controle de qualidade produz bugs - "meu código estava bom até que o controle de qualidade o capturasse e depois eles fizeram todos esses bugs!". Os bugs estavam lá o tempo todo, mas o desenvolvedor os ignorava. O objetivo de uma equipe de operações deve ser a confiabilidade real , e eles precisam ser incentivados como tal por seus gerentes. Isso significa que, se eles implementarem mais monitoramentos que levem à descoberta de novos problemas, deverão ser recompensados, e não penalizados pela queda subsequente nas métricas de confiabilidade.

TL; DR, como você prova que os devops, especificamente a automação de implantação, melhoram as taxas de falha de alteração?

Se você está tentando motivar mudanças em sua organização, não deve tentar provar nada, mas forneça evidências do que outras organizações dizem sobre suas próprias transições. Se você estiver tentando medir os processos que você já possui e justificar sua existência contínua, deverá acompanhar as métricas de confiabilidade padrão, como tempo médio para reparo (MTTR).

Mas os princípios dos devops não se limitam a aumentar a confiabilidade. Mesmo a engenharia de confiabilidade do site não se limita a aumentar a confiabilidade. Em vez disso, você deseja obter um nível adequado de confiabilidade - algo que beneficia os negócios, mas não prejudica o desenvolvimento. E isso traz o verdadeiro motivador nos devops, que é capacitar a mudança . Você deseja permitir que a empresa responda mais rapidamente aos estímulos do mercado, o que ocorre diminuindo o atrito do desenvolvedor, aumentando a taxa de implantações, automatizando processos manuais etc., mantendo-se dentro de um limite aceitável de confiabilidade. Isso significa que você precisa medir a confiabilidade, mas também a velocidade, porque seu objetivo é aumentar o último, mantendo o primeiro relativamente estático.