Quelle est la bonne relation entre les métriques rollback / rollforward et MTTR?

J'essaie de comprendre la meilleure façon de capturer des données pour commencer à mesurer les métriques du temps moyen de réparation (MTTR), et je dois comprendre comment l'impact du «rollback» sur le MTTR est positif ou négatif.

Scénario 1

En supposant qu'une surveillance solide est en place, un code est déployé qui provoque un incident qui est détecté assez rapidement (faible MTTI). Au point d'identification, il existe deux voies principales possibles (oui, je simplifie à l'excès à des fins de discussion):

1. Annulez le déploiement, en retournant rapidement la stabilité, mais sans les fonctionnalités prévues en production.

2. Roll-forward avec des modifications supplémentaires qui résolvent l'incident et maintiennent les fonctionnalités prévues en direct.

Dans ce scénario, le MTTR est sacrément bas, étant donné que la stabilité du site peut revenir assez rapidement. Cela dit, le résultat attendu de la modification n'est pas en direct, et donc le code / fonctionnalité / modification est toujours bloqué en cours. Si un objectif est un MTTR faible, il semble inciter au retour en arrière comme mécanisme de récupération.

Scénario 2

Dans ce scénario, MTTR est strictement mesuré par le temps qu'il faut au code / fonctionnalité / changement attendu pour fonctionner correctement en production. Même si je rétrograde, jusqu'à ce que mon changement de code "fixe" entre en prod, le minuteur MTTR fonctionne toujours. Dans ce cas, MTTR semble lié à la stabilité des résultats commerciaux au lieu de simplement "hé, les choses sont stables".

Maintenant, la réponse peut être aussi simple que le MTTR n'est pas utilisé comme une mesure dans le vide, mais plutôt en conjonction avec le taux d'échec de changement - un MTTR très bas provoqué par des retours en arrière fréquents pourrait indiquer un taux d'échec de changement extrêmement élevé. Cela dit, il y a quelque chose qui ne me semble pas juste dans l'idée de séparer la mesure MTTR des résultats commerciaux.

Je réfléchis peut-être beaucoup à cela, mais je suis curieux de savoir comment d'autres mesurent le MTTR et quel est le point final dans le temps pour la «récupération». L'utilisez-vous simplement comme stabilité, ou d'autres facteurs entrent-ils en jeu pour déterminer ce que signifie "récupéré"?

Oui, le MTTR est / devrait toujours être lié au résultat commercial: si les choses ne sont pas stables, l'entreprise même est en danger.

Le fait que le code / la fonctionnalité / le changement attendu est toujours bloqué dans le processus dans le scénario 1 est sans importance: la fonctionnalité n'est pas stable, donc elle n'apporte pas de nouvelles affaires, le retour en arrière est le meilleur que vous puissiez faire à ce moment-là de l'entreprise éventuel.

Le rollforward est un pari: maintient l'entreprise à risque en attendant une solution potentielle qui a en fait des changements de succès statistiquement inférieurs (en raison de l'instabilité, elle sera toujours précipitée par rapport au changement qui a causé l'instabilité en premier lieu sans même avoir une telle pression). Le rollforward est une autre version du code qui n'a pas été vérifiée auparavant.

Si vous voulez garder le MTTR bas, vous annulez immédiatement, sans débat. Cela supprime le risque commercial et vous permet de vérifier que le correctif fonctionne réellement avant de tenter de le déployer. Je suggérerais fortement d'en faire une politique car oui, presque toujours, il y aura quelqu'un qui demandera un correctif au lieu du retour en arrière et convoquera une réunion pour négocier / décider - tout cela pendant que les affaires restent à risque.

Remarque: si vous êtes préoccupé par un taux d'échec de changement élevé, je suggère de vérifier le taux de restauration réel au lieu de le dériver d'un MTRR faible. Vous souhaitez peut-être ajouter une vérification de porte avant le déploiement pour les pannes les plus fréquentes. Si ce contrôle est déjà automatisé - pourquoi ne pas l'inclure dans la vérification CI? Si vous n'en avez pas - peut-être qu'il est temps de commencer à y penser? :)

Le temps moyen pour récupérer a un sujet implicite - le temps moyen pour récupérer quoi ? Il est essentiel de définir cela pour utiliser efficacement la métrique.

Récupérez-vous la disponibilité générale de votre site de production? Récupérez-vous les fonctionnalités d'une fonctionnalité particulière contenant un bogue? Une fois que vous savez ce que vous essayez de mesurer, il est beaucoup plus facile de le mesurer!

L'idée générale de votre question semble en fait entourer les objectifs concurrents des fonctionnalités d'expédition et du maintien de la fiabilité, ce qui est une bataille séculaire. Traditionnellement, c'est le travail des développeurs d'implémenter de nouvelles choses, et le travail des administrateurs système pour empêcher les choses de se casser, et cela conduit à des conflits départementaux, car le changement a tendance à provoquer des ruptures. L'une des philosophies souvent associées à DevOps est l'idée que les développeurs et les ingénieurs d'exploitation devraient travailler en étroite collaboration afin d'atténuer cette tension.

Vous pouvez également être intéressé par l'approche de Google à ce problème, qui est d'avoir des «budgets d'erreur» pour les équipes de développement à dépenser; une fois qu'ils ont trop pénalisé la stabilité, ils doivent passer le reste du trimestre à travailler uniquement sur la stabilité. Parallèlement à cela, les ingénieurs de fiabilité du site ont des objectifs disponibles, et s'ils dépassent , ils sont encouragés à laisser passer plus de changements; l'idée ici est que leur objectif ne doit pas simplement être de maintenir la fiabilité aussi élevée que possible, car ils seraient alors motivés à lutter contre le changement dans chaque situation.