MTTR: medir y cerrar el incidente

Descripción

Las seis lecciones anteriores de este módulo construyeron, en orden, todo lo necesario para responder bien a un incidente: la red de seguridad (L2), la decisión de revertir o arreglar hacia adelante (L3), el runbook que ejecuta esa decisión (L4), el principio de mitigar antes de diagnosticar (L5), y la severidad que decide a quién avisar (L6). Esta lección cierra el ciclo con la pregunta que queda después de que un incidente termina: ¿qué tan rápido fue, realmente, la respuesta? La respuesta se mide con el MTTR —mean time to recovery, tiempo medio de recuperación— y se comunica hacia el resto de la organización como el cierre formal del incidente.

Conexión con el módulo. Esta es la última pieza de tema del módulo, y la segunda pieza ejecutable central junto con rollbackDecision() de la lección 3. El proyecto de la lección 8 va a usar mttr() sobre la línea de tiempo completa del incidente de recommendations, combinándola con las otras dos piezas ejecutables del módulo.

Una analogía: el cronómetro que no se detiene cuando apagas el fuego

Vuelve a la analogía del incendio de la lección 5. Un equipo de bomberos no considera que su trabajo terminó en el momento en que las llamas se apagan — hay un proceso posterior de verificación, de asegurarse de que no queden focos de calor, antes de declarar la situación completamente resuelta y retirarse. El cronómetro de la respuesta completa no se detiene cuando el fuego visible desaparece; se detiene cuando la situación está genuinamente resuelta y confirmada.

El MTTR mide exactamente ese cronómetro completo, no solo el momento en que "apagaste el fuego" (mitigaste). Hay dos momentos distintos que importa distinguir: el momento en que el daño dejó de ocurrir (mitigado — el kill switch se activó) y el momento en que el problema quedó resuelto de verdad (resuelto — la causa raíz se arregló y se verificó). El MTTR, medido de punta a punta, captura los dos tramos, y separarlos —cuánto tardó cada uno— dice cosas distintas sobre qué tan bien respondió el equipo.

Ejemplo trabajado: mttr() sobre la línea de tiempo real del incidente

// mttr: dada la linea de tiempo de un incidente (detected -> mitigated -> resolved),
// calcula cuanto tardo cada tramo. NO usa Math.random(): la linea de tiempo es un caso
// pedagogico fijo, tomado del incidente de recommendations en rollout 10%.
function mttr(events) {
  const minutesBetween = (from, to) => Math.round((new Date(to) - new Date(from)) / 60000);
  return {
    timeToMitigate: minutesBetween(events.detected, events.mitigated),
    timeToResolve: minutesBetween(events.mitigated, events.resolved),
    totalMTTR: minutesBetween(events.detected, events.resolved),
  };
}

const recommendationsIncidentTimeline = {
  detected: '2026-03-04T14:12:00',
  mitigated: '2026-03-04T14:15:00',
  resolved: '2026-03-04T16:42:00',
};

console.log('=== MTTR del incidente de recommendations (rollout 10%) ===\n');
const result = mttr(recommendationsIncidentTimeline);
console.log('detected   ' + recommendationsIncidentTimeline.detected);
console.log('mitigated  ' + recommendationsIncidentTimeline.mitigated + '  (timeToMitigate=' + result.timeToMitigate + 'min)');
console.log('resolved   ' + recommendationsIncidentTimeline.resolved + '  (timeToResolve=' + result.timeToResolve + 'min)');
console.log('\ntotalMTTR=' + result.totalMTTR + 'min (' + (result.totalMTTR / 60).toFixed(1) + 'h)');

Qué esperar. Al correr el archivo con Node, la salida es exactamente esta:

=== MTTR del incidente de recommendations (rollout 10%) ===

detected   2026-03-04T14:12:00
mitigated  2026-03-04T14:15:00  (timeToMitigate=3min)
resolved   2026-03-04T16:42:00  (timeToResolve=147min)

totalMTTR=150min (2.5h)

Los tres momentos cuentan una historia clara. detected es el instante en que el dashboard de guardrails del módulo 4 confirma que p95Latency cruzó el techo. mitigated, apenas 3 minutos después, es cuando el equipo terminó el runbook de la lección 4 hasta el paso de apagar el kill switch — un timeToMitigate bajísimo, coherente con todo lo que las lecciones 2 y 5 de este módulo ya mostraron sobre la velocidad del kill switch y el valor de mitigar primero. resolved, dos horas y media después de detected, es cuando el equipo terminó de diagnosticar la query lenta que causó la latencia, la corrigió, y verificó que el fix era seguro — el timeToResolve de 147 minutos es, en comparación, mucho más largo, porque diagnosticar y corregir una causa raíz real toma más tiempo que apagar un booleano.

El totalMTTR de 150 minutos junta los dos tramos. Y aquí vale la pena notar algo importante sobre cómo leer ese número: la gran mayoría de esos 150 minutos —147 de 150— ocurrieron después de que la exposición ya estaba controlada. Los usuarios de Mercado dejaron de estar expuestos a la latencia rota en el minuto 3, no en el minuto 150. Reportar solo el totalMTTR, sin desglosar los dos tramos, esconde exactamente esa diferencia.

Por qué separar timeToMitigate de timeToResolve cambia la conversación

Imagina dos incidentes distintos, ambos con el mismo totalMTTR de 150 minutos. En el primero —el de recommendations— la mitigación tomó 3 minutos y la resolución completa 147. En un segundo incidente hipotético, la mitigación podría haber tomado 120 minutos (el equipo tardó en decidir o en encontrar el mecanismo correcto para detener el daño) y la resolución completa solo 30 minutos más. El totalMTTR es idéntico en los dos casos — pero son historias completamente distintas sobre qué salió bien y qué salió mal.

En el primer caso, el equipo respondió excelente en el tramo que más le importa a los usuarios afectados (mitigar rápido) y tomó su tiempo, razonablemente, en el tramo de diagnóstico completo. En el segundo caso hipotético, el equipo tardó demasiado en lo que más urgía —proteger a los usuarios— y eso amerita revisar el runbook, la severidad asignada, o el propio proceso de decisión. Un totalMTTR sin desglosar no distingue entre estas dos historias — y por eso Atlassian, PagerDuty, y el resto de la industria de incident response insisten en reportar timeToMitigate (o su equivalente, a veces llamado MTTA/tiempo de reconocimiento combinado con tiempo de mitigación) por separado del tiempo de resolución completa.

Errores comunes

Reportar solo el totalMTTR, sin desglosar cuánto fue mitigar y cuánto fue resolver por completo. Qué pasa: el reporte de un incidente dice "MTTR: 150 minutos", sin ninguna mención de que la exposición real de los usuarios terminó en el minuto 3. Por qué pasa: un solo número es más simple de comunicar que dos, y la distinción entre "mitigado" y "resuelto" puede sentirse como un detalle técnico innecesario para una audiencia no técnica. Cómo detectarlo: si alguien que lee el reporte concluye, incorrectamente, que los usuarios de Mercado estuvieron expuestos a la latencia rota durante dos horas y media, el reporte no comunicó bien la diferencia. Cómo corregirlo: como en la salida de mttr() de esta lección, siempre reporta timeToMitigate y timeToResolve por separado, además del total — son preguntas distintas, con implicaciones distintas.

No definir con precisión qué cuenta como "detected" — usar el momento en que alguien lo notó, en vez del momento en que el sistema lo detectó. Qué pasa: al calcular el MTTR de un incidente, alguien usa como detected el momento en que un ingeniero, revisando manualmente el dashboard, notó el problema por primera vez — no el momento en que el guardrail cruzó el techo, que pudo haber sido antes. Por qué pasa: el momento en que "una persona se dio cuenta" es más fácil de recordar y documentar que el momento exacto en que un sistema automatizado cruzó un umbral, especialmente si esa alerta automatizada tardó en llegar o en ser revisada. Cómo detectarlo: si detected en el reporte de un incidente coincide siempre, sospechosamente, con el horario en que alguien del equipo empezó su turno, probablemente no es el momento real de detección del sistema. Cómo corregirlo: usa, como fuente de detected, el timestamp del sistema de monitoreo del módulo 4 —cuándo el guardrail cruzó el techo—, no el momento en que un humano lo notó; la diferencia entre ambos es, en sí misma, información valiosa sobre qué tan bien está funcionando el sistema de alertas.

Comparar el MTTR de dos incidentes muy distintos entre sí, como si fueran comparables sin más contexto. Qué pasa: alguien concluye que "el equipo mejoró su respuesta a incidentes" porque el MTTR promedio bajó de un trimestre a otro, sin revisar si los incidentes de cada trimestre eran del mismo tipo de severidad, o si simplemente hubo menos incidentes SEV1 (que naturalmente toman más tiempo de resolver por completo) y más SEV3. Por qué pasa: un promedio agregado es fácil de graficar en el tiempo, y esconde con facilidad diferencias de composición entre los periodos que se comparan. Cómo detectarlo: si el MTTR promedio cambia pero nadie puede decir si cambió la mezcla de severidades entre los periodos comparados, la conclusión sobre "mejoramos" o "empeoramos" no está bien fundamentada. Cómo corregirlo: cuando compares MTTR entre periodos, sepáralo por severidad (el MTTR de los SEV1 contra el de los SEV2, por separado) — igual que la lección 6 separó los incidentes por severidad antes de decidir a quién avisar, la comparación de MTTR necesita esa misma separación para ser honesta.

Ejercicios

Ejercicio 1 — Calcula un MTTR distinto. Un segundo incidente de Mercado tiene esta línea de tiempo: detected: '2026-04-01T09:00:00', mitigated: '2026-04-01T09:40:00', resolved: '2026-04-01T10:10:00'. Calcula a mano (o corriendo mttr()) el timeToMitigate, el timeToResolve, y el totalMTTR. ¿Qué te dice la proporción entre los dos tramos, comparada con el incidente de recommendations de esta lección?

Ver solución

timeToMitigate = 40 minutos (de 09:00 a 09:40). timeToResolve = 30 minutos (de 09:40 a 10:10). totalMTTR = 70 minutos. Comparado con el incidente de recommendations —donde timeToMitigate fue apenas 3 minutos de un total de 150—, este segundo incidente muestra una proporción muy distinta: más de la mitad del tiempo total (40 de 70 minutos) ocurrió antes de mitigar. Eso es una señal de alerta que merece revisión: ¿por qué tardó tanto en mitigarse este incidente? ¿No había un kill switch disponible, o el equipo no lo usó de inmediato? Esa pregunta —no el número total— es la que realmente importa para mejorar la respuesta la próxima vez.

Ejercicio 2 — Encuentra el problema en una línea de tiempo mal registrada. Alguien reporta esta línea de tiempo para un incidente: detected: '2026-05-10T18:00:00', mitigated: '2026-05-10T17:50:00', resolved: '2026-05-10T19:00:00'. Corre (mentalmente o en Node) mttr() con estos datos. ¿Qué resultado da timeToMitigate, y qué te dice ese resultado sobre la calidad de los datos registrados?

Ver solución

timeToMitigate daría -10 minutos — un número negativo, porque mitigated (17:50) ocurre antes que detected (18:00) según los timestamps dados, algo lógicamente imposible: no se puede mitigar un incidente antes de haberlo detectado. Un resultado negativo como este es una señal clara de que los timestamps están mal registrados —quizás una zona horaria distinta entre dos sistemas, o un error humano al anotar la hora—, no que el equipo mitigó "antes de tiempo". Este ejercicio ilustra por qué vale la pena, en un sistema real, validar que mitigated >= detected y resolved >= mitigated antes de confiar en cualquier resultado de mttr() — el modelo pedagógico de esta lección no incluye esa validación, pero un sistema de producción sí debería.

Ejercicio 3 — Escribe el mensaje de cierre del incidente. Usando los datos de mttr() sobre el incidente de recommendations de esta lección, y la severidad SEV2 de la lección 6, escribe el mensaje de cierre (80-120 palabras) que el equipo enviaría al resto de la organización, confirmando que el incidente está resuelto.

Ver solución

Un mensaje posible: "Cierre de incidente SEV2 — recommendations, 4 de marzo. A las 14:12 detectamos que el guardrail de latencia (p95) volvió a romperse durante el rollout al 10%, superando el techo de 800ms. Mitigamos en 3 minutos apagando el kill switch de la feature — ningún usuario quedó expuesto después de las 14:15. La causa fue una query sin índice en el join de recomendaciones bajo tráfico real; el fix quedó verificado y el incidente resuelto por completo a las 16:42 (MTTR total: 150 minutos, con 147 de esos minutos dedicados a diagnóstico y verificación, sin usuarios afectados durante ese tramo). El rollout permanece frenado en 10% hasta decidir los próximos pasos." El mensaje separa claramente cuándo se detuvo el daño real (14:15) de cuándo se cerró el incidente por completo (16:42), y no esconde el MTTR total detrás de una sola cifra sin contexto.

Resumen y siguiente paso

En esta lección construiste mttr(), el modelo que mide, a partir de una línea de tiempo de tres momentos —detected, mitigated, resolved—, cuánto tardó cada tramo de la respuesta. Sobre el incidente real de recommendations, el resultado mostró algo importante: apenas 3 de los 150 minutos totales fueron de exposición real de los usuarios (timeToMitigate); el resto (147 minutos) fue el tiempo de diagnóstico y verificación completa, ya con el daño contenido.

Antes de avanzar deberías poder: explicar por qué reportar timeToMitigate y timeToResolve por separado dice más que reportar solo el totalMTTR; identificar cuándo una línea de tiempo tiene datos mal registrados (por ejemplo, un timeToMitigate negativo); y escribir un mensaje de cierre de incidente que comunique con precisión ambos tramos.

Con esta lección se cierra el arco completo de tema del módulo: la red de seguridad (L2), la decisión entre revertir y arreglar hacia adelante (L3), el runbook (L4), mitigar antes de diagnosticar (L5), la severidad (L6), y ahora la medición y el cierre (L7). La lección 8, el proyecto de este módulo, te pide juntar las tres piezas ejecutables —rollbackDecision(), el runbook, y mttr()— y responder de punta a punta al incidente completo de recommendations.

Recursos

• Atlassian, "Common Incident Management Metrics" — atlassian.com/incident-management/kpis/common-metrics. Define el MTTR y sus variantes (MTTA, MTTD, MTBF), y explica por qué el "R" de MTTR puede significar cosas distintas —repair, recovery, respond, resolve— y por qué esa ambigüedad importa al reportarlo. En inglés.
• Google SRE Book, Capítulo 14, "Managing Incidents" — sre.google/sre-book/managing-incidents. Describe la práctica de mantener una línea de tiempo documentada en vivo durante el incidente, la fuente de datos exacta que mttr() necesita para calcular tiempos reales, no estimados después de los hechos. En inglés.
• PagerDuty Incident Response Documentation — response.pagerduty.com. La guía completa de cierre de incidentes, incluyendo la comunicación de resolución hacia el resto de la organización — el mismo tipo de mensaje que pide el ejercicio 3 de esta lección. En inglés.