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")
Respostas:
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:
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.
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 "
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:
É 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:
fonte
Um problema corrigido rapidamente ainda é um problema. Se você não está relatando isso como tal, isso é um problema.
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.
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.
fonte