MTTR sigue siendo útil. Indica a los equipos si la producción vuelve a un estado saludable con la suficiente rapidez.
Pero ya no es el único reloj que importa.
Cuando el flujo de trabajo de remediación puede conectar la observabilidad, el historial de implementación, la propiedad del código y los parches generados por IA, se vuelve práctica una nueva métrica: el tiempo de revisión de las relaciones públicas.
Qué significa la métrica
El tiempo de revisión de las relaciones públicas mide el camino desde una señal de producción hasta una solicitud de extracción que el propietario del código puede evaluar seriamente.
No es una diferencia generada aleatoriamente. No es un vago resumen del incidente. Un PR revisable.
Eso significa que la solicitud de extracción incluye:
- la señal de producción que desencadenó la investigación
- el servicio, archivo, función o ruta de código sospechosos
- la implementación reciente o el conjunto de cambios que pueden estar relacionados
- un parche enfocado
- las pruebas que se ejecutaron o deberían ejecutarse
- los supuestos y el nivel de confianza
- el revisor o propietario adecuado
La métrica finaliza cuando el RP está listo para tomar una decisión de ingeniería significativa.
Por qué esto es diferente del MTTR
MTTR está orientado a resultados. El tiempo de revisión de las relaciones públicas está orientado al flujo de trabajo.
MTTR pregunta: "¿Cuándo nos recuperamos?"
Time-to-reviewed-PR pregunta: "¿Qué tan rápido llegamos a un punto de decisión de alta calidad?"
Esa distinción es importante porque muchos incidentes se retrasan incluso antes de que exista el cambio de código. Los ingenieros todavía están recopilando pruebas, encontrando propietarios, comparando implementaciones o decidiendo si el problema pertenece a otro sistema.
Si el equipo puede acortar esa fase, la recuperación suele mejorar de forma natural. Incluso cuando la respuesta final es revertir o intensificar la situación, la decisión se toma con mejores pruebas y menos confusión.
La barra de calidad
La métrica solo funciona si "PR revisado" significa algo estricto.
Una mala versión de esta métrica recompensaría a las herramientas que abren rápidamente solicitudes de extracción ruidosas. Eso genera fatiga en la revisión y hace que los ingenieros desconfíen de la automatización.
Una buena versión recompensa el trabajo preparado, con alcance y respaldado por evidencia.
El RP debe ser lo suficientemente pequeño como para revisarlo, lo suficientemente claro como para rechazarlo y lo suficientemente conectado con la evidencia de producción para que el revisor no tenga que reconstruir el incidente desde cero.
Métricas complementarias útiles
El tiempo hasta la revisión de las relaciones públicas no debería ser un factor aislado. Combínalo con señales de calidad:
- Tasa de aceptación de relaciones públicas
- tasa de edición del revisor
- tasa de diagnóstico falso
- tasa de reversión después de correcciones asistidas por IA
- tasa de incidentes duplicados después de la fusión
- tiempo desde el PR abierto hasta la decisión del revisor
En conjunto, estas métricas muestran si la automatización está ahorrando tiempo o simplemente pasando el trabajo a revisión.
Donde esto ayuda a los líderes
Los líderes de ingeniería necesitan saber si las herramientas para incidentes reducen la resistencia operativa. Un gráfico que indique que la recuperación es más rápida es útil, pero no explica dónde pasó el tiempo.
El tiempo de revisión de las relaciones públicas hace que el traspaso sea visible. Muestra si el equipo puede pasar de la alerta a la evidencia, de la evidencia al código y del código a la propiedad sin unir manualmente.
También expone vínculos débiles. Si los RP se abren rápidamente pero no se revisan, el problema es la propiedad o la dotación de personal. Si las pruebas tardan demasiado, el problema es la integración. Si se rechazan muchos RP, el problema es la calidad del diagnóstico.
El punto no es más métricas.
El objetivo no es inventar otro panel que los ingenieros puedan ignorar.
El objetivo es hacer observable la calidad de la remediación.
Los errores de producción no se resuelven cuando se activa una alerta y no se resuelven cuando un modelo escribe código. Avanzan hacia la resolución cuando el ser humano adecuado puede tomar una decisión segura con la evidencia adecuada frente a ellos.
Eso es lo que mide el tiempo hasta la revisión de las relaciones públicas.
