¿Cuál es la relación adecuada entre la reversión / avance y las métricas MTTR?

Estoy tratando de entender la mejor manera de capturar datos para comenzar a medir las métricas de Tiempo medio de reparación (MTTR), y necesito entender cómo el "retroceso" impacta MTTR positiva o negativamente.

escenario 1

Suponiendo que existe una supervisión sólida, se implementa un código que causa un incidente que se detecta con bastante rapidez (MTTI bajo). En el punto de identificación, hay dos caminos principales posibles hacia adelante (sí, estoy simplificando demasiado para fines de discusión):

1. Revierta la implementación, devolviendo la estabilidad rápidamente, pero sin las características previstas en producción.

2. Avance con los cambios adicionales que resuelven el incidente y mantienen vivas las funciones previstas.

En este escenario, el MTTR es bastante bajo, dado que la estabilidad del sitio puede volver bastante rápido. Dicho esto, el resultado previsto del cambio no está en vivo y, por lo tanto, el código / característica / cambio todavía está atascado en el proceso. Si un objetivo es bajo MTTR, parece incentivar la reversión como un mecanismo de recuperación.

Escenario 2

En este escenario, el MTTR se mide estrictamente por el tiempo que tarda el código / característica / cambio esperado en funcionar correctamente en la producción. Incluso si retrocedo, hasta que mi cambio de código "fijo" entre en producción, el temporizador MTTR todavía se está ejecutando. En este caso, el MTTR parece estar vinculado a la estabilidad de los resultados comerciales en lugar de simplemente "oye, las cosas son estables".

Ahora, la respuesta puede ser tan simple como que MTTR no se utiliza como una métrica en el vacío, sino en combinación con la tasa de falla de cambio: una MTTR súper baja causada por retrocesos frecuentes podría apuntar a una tasa de falla de cambio altísima. Dicho esto, hay algo que no me parece correcto en la idea de divorciar la medición MTTR del resultado comercial.

Puedo pensar demasiado en esto, pero tengo curiosidad por saber cómo otros están midiendo MTTR y cuál es el punto final en el tiempo para la "recuperación". ¿Lo está utilizando simplemente como estabilidad o hay otros factores que determinan lo que significa "recuperado"?

Sí, el MTTR está / debe estar siempre vinculado al resultado comercial: si las cosas no son estables, el negocio mismo está en riesgo.

El hecho de que el código / característica / cambio esperado todavía esté atascado en el proceso en el escenario 1 es irrelevante: la característica no es estable, por lo que no trae nuevos negocios, retroceder es lo mejor que puede hacer en ese momento desde el negocio futuro.

El avance es una apuesta: mantiene a la empresa en riesgo esperando una solución potencial que de hecho tenga cambios de éxito estadísticamente más bajos (debido a la inestabilidad, siempre será apresurada en comparación con el cambio que causó la inestabilidad en primer lugar sin siquiera tener tanta presión sobre él). El avance es una versión más del código que no se ha verificado antes.

Si desea mantener el MTTR bajo, retroceda de inmediato, sin debate. Esto elimina el riesgo comercial y le da la oportunidad de verificar que la solución realmente esté funcionando antes de intentar implementarla. Sugeriría encarecidamente que se convierta en una política como sí, casi siempre habrá alguien que solicite una solución en lugar de la reversión y convoque a una reunión para negociar / decidir sobre ello, todo mientras el negocio sigue en riesgo.

Nota al margen: si le preocupa una alta tasa de falla de cambio, le sugiero que verifique la tasa de reversión real en lugar de derivarla de un MTRR bajo. Tal vez le gustaría agregar una verificación de puerta antes del despliegue para las fallas más frecuentes. Si ya tiene dicho control automatizado, ¿por qué no incluirlo en la verificación de CI? Si no tienes uno, ¿tal vez es hora de empezar a pensar en ello? :)

El tiempo medio para recuperarse tiene un tema implícito: el tiempo medio para recuperarse, ¿qué ? Definir esto es clave para usar la métrica de manera efectiva.

¿Está recuperando la disponibilidad general de su sitio web de producción? ¿Está recuperando la funcionalidad de una característica particular que tiene un error? Una vez que sabes lo que realmente estás tratando de medir, ¡es mucho más fácil medirlo!

El objetivo general de su pregunta parece estar realmente en torno a los objetivos competitivos de las funciones de envío y el mantenimiento de la fiabilidad, que es una batalla milenaria. Tradicionalmente, los trabajos de los desarrolladores son para implementar cosas nuevas, y los trabajos de los administradores de sistemas para evitar que las cosas se rompan, y esto lleva a conflictos departamentales, ya que el cambio tiende a causar la ruptura. Una de las filosofías a menudo asociadas con DevOps es la idea de que los desarrolladores y los ingenieros de operaciones deberían trabajar en estrecha colaboración para aliviar esta tensión.

También puede estar interesado en el enfoque de Google para ese problema, que consiste en tener "presupuestos de error" para que los equipos de desarrollo los gasten; Una vez que han penalizado demasiado la estabilidad, deben pasar el resto del trimestre solo trabajando en la estabilidad. Junto con esto, los ingenieros de confiabilidad del sitio tienen objetivos disponibles, y si se disparan en exceso , se los alienta a dejar pasar más cambios; La idea aquí es que su objetivo no debe ser simplemente mantener la confiabilidad lo más alta posible, ya que entonces estarán motivados para luchar contra el cambio en cada situación.