El Tiempo Medio de Recuperación (MTTR) mide el tiempo promedio que toma restablecer la operación normal después de un incidente en producción. Es la métrica de resiliencia operativa del conjunto DORA.
Qué mide
Leanmote no tiene un registro de incidentes que leer, así que infiere la recuperación a partir de los pull requests. Un PR mergeado cuyo título contiene hotfix, revert o HOT-FIX se trata como una recuperación, y el reloj arranca en el PR anterior mergeado en ese mismo repositorio que no sea a su vez una recuperación. El MTTR es el promedio de esos intervalos.
Cómo lo calcula Leanmote
mttr = avg(recovery_pr.merged_at - previous_pr_in_repo.merged_at)
La recuperación se reconoce sólo por el título, y la lista es corta:
hotfix,revert,HOT-FIX. Un PR titulado «fix: null pointer» cuenta como falla para la Tasa de Fallos de Cambios pero no como recuperación aquí: las dos métricas usan listas de palabras distintas, así que sus conteos no coinciden.La coincidencia es sobre cualquier parte del título, así que un PR sobre «revertir el cambio de copy» también cuenta.
Se reporta como promedio, en horas. No hay mediana, ni selector de percentiles, ni etiquetas de severidad.
El intervalo se mide por repositorio, y las recuperaciones consecutivas se saltean: tres hotfixes seguidos miden todos contra el mismo pull request original, así que el segundo y el tercero dan cada vez más largo.
Una recuperación sin ningún merge anterior que no sea recuperación en su repositorio se descarta por completo, en vez de contarse como cero.
Cómo interpretarlo
Que baje significa que la recuperación se está haciendo más rápida: operativamente sano.
Como es un promedio sin tratamiento de valores extremos, un solo intervalo patológico mueve todo el número. Abre el detalle y mira las filas más largas antes de reaccionar a un salto.
El límite real es la lista de palabras. Una recuperación mergeada con un título que no contenga una de esas tres es invisible aquí, y un pull request de rutina que mencione revertir algo cuenta como incidente.
Qué hacer al respecto
Mejora la observabilidad: las alertas que detectan incidentes más temprano acortan el reloj.
Clarifica la responsabilidad y las rutas de escalamiento para que se convoque de inmediato a las personas correctas.
Invierte en runbooks para los modos de falla más comunes.
Revisa después del incidente: ¿el tiempo de recuperación se fue en diagnosticar o en arreglar? Eso revela si el cuello de botella es la observabilidad o la velocidad de cambio.
Métricas relacionadas
Tasa de Fallos de Cambios
Frecuencia de Despliegue
Panorama de métricas DORA