Qual é o relacionamento adequado entre as métricas rollback / rollforward e MTTR?

Estou tentando entender a melhor maneira de capturar dados para começar a medir as métricas de tempo médio para reparo (MTTR) e preciso entender como a "reversão" afeta o MTTR de maneira positiva ou negativa.

Cenário 1

Supondo que haja um monitoramento sólido, é implantado um código que causa um incidente que é detectado rapidamente (MTTI baixo). No ponto de identificação, existem dois principais caminhos possíveis (sim, estou simplificando demais para fins de discussão):

1. Reverta a implantação, retornando estabilidade rapidamente, mas sem os recursos pretendidos na produção.

2. Prossiga com alterações adicionais que resolvem o incidente e mantêm os recursos pretendidos ativos.

Nesse cenário, o MTTR é bastante baixo, já que a estabilidade do site pode retornar rapidamente. Dito isto, o resultado pretendido da mudança não está ativo e, portanto, o código / recurso / alteração ainda está parado no processo. Se uma meta é baixa MTTR, parece incentivar a reversão como um mecanismo de recuperação.

Cenário 2

Nesse cenário, o MTTR é estritamente medido pelo tempo que leva para que o código / recurso / alteração esperado funcione corretamente na produção. Mesmo se eu reverter, até que minha alteração de código "fixa" entre em prod, o temporizador MTTR ainda estará em execução. Nesse caso, o MTTR parece vinculado à estabilidade dos resultados dos negócios, em vez de apenas "ei, tudo está estável".

Agora, a resposta pode ser tão simples quanto o MTTR não ser usado como métrica no vácuo, mas em conjunto com a Taxa de Falha na Mudança - um MTTR super baixo causado por retrocessos frequentes pode apontar para uma Taxa de Falha na Mudança altíssima. Dito isto, há algo que não me parece correto na ideia de separar a medida do MTTR do resultado do negócio.

Talvez eu esteja pensando demais nisso, mas estou curioso para saber como os outros estão medindo o MTTR e qual é o ponto final para a "recuperação". Você o está usando simplesmente como estabilidade ou outros fatores determinam o que "recuperado" significa?

Sim, o MTTR está / deve sempre estar vinculado ao resultado do negócio: se as coisas não estiverem estáveis, o próprio negócio estará em risco.

O fato de o código / recurso / alteração esperado ainda estar parado no processo no cenário 1 é irrelevante: o recurso não é estável e, portanto, não gera novos negócios, a reversão é o melhor que você pode fazer naquele momento da empresa prospectivo.

O rollforward é uma aposta: mantém os negócios em risco à espera de uma correção em potencial que, de fato, tenha mudanças estatisticamente menores de sucesso (devido à instabilidade, ela sempre será apressada em comparação com a mudança que causou a instabilidade em primeiro lugar, mesmo sem ter tanta pressão sobre ele). O rollforward é mais uma versão do código que não foi verificada antes.

Se você deseja manter o MTTR baixo, você reverte imediatamente, sem debate. Isso remove o risco comercial e permite verificar se a correção está realmente funcionando antes de tentar implantá-la. Eu sugiro fortemente que seja uma política como sim, quase sempre haverá alguém pedindo uma correção em vez da reversão e convocando uma reunião para negociar / decidir sobre ela - enquanto os negócios continuam em risco.

Nota lateral: se você estiver preocupado com uma taxa de falha de alteração alta, sugiro verificar a taxa de reversão real em vez de derivá-la de um MTRR baixo. Talvez você queira adicionar uma verificação de portão antes da implantação para as falhas mais frequentes. Se você já possui essa verificação automatizada - por que não incluí-la na verificação do IC? Se você não tem um - talvez seja hora de começar a pensar sobre isso? :)

O tempo médio de recuperação tem um assunto implícito - o tempo médio de recuperação de quê ? Definir isso é a chave para usar a métrica efetivamente.

Você está recuperando a disponibilidade geral do seu site de produção? Você está recuperando a funcionalidade de um recurso específico que possui um bug? Depois de saber o que realmente está tentando medir, é muito mais fácil medir!

O objetivo geral da sua pergunta parece estar na verdade cercando os objetivos concorrentes dos recursos de remessa e mantendo a confiabilidade, que é uma batalha antiga. Tradicionalmente, é tarefa dos desenvolvedores implementar coisas novas, e tarefas dos administradores de sistemas para impedir que as coisas quebrem, e isso leva a conflitos departamentais, pois as mudanças tendem a causar rupturas. Uma das filosofias frequentemente associadas ao DevOps é a idéia de que desenvolvedores e engenheiros de operações devem trabalhar juntos para aliviar essa tensão.

Você também pode estar interessado na abordagem do Google para esse problema, que é ter "orçamentos de erro" para as equipes de desenvolvimento gastarem; depois de penalizar demais a estabilidade, eles devem passar o resto do trimestre apenas trabalhando na estabilidade. Junto com isso, os engenheiros de confiabilidade do site têm objetivos disponíveis e, se eles dispararem em excesso , são incentivados a permitir mais alterações; a idéia aqui é que seu objetivo não deve ser simplesmente manter a confiabilidade o mais alta possível, pois eles seriam motivados a combater as mudanças em todas as situações.