Plantilla de Línea de Tiempo de Incidentes

Overview

La mayoría de los postmortems de incidentes no logran identificar los problemas reales porque carecen de una cronología precisa. Los equipos recuerdan los grandes eventos pero olvidan los 15 minutos de retraso en el escalamiento, los 30 minutos gastados revisando los logs incorrectos, o la brecha entre la primera alerta y el reconocimiento humano. Esta plantilla estructura la reconstrucción de incidentes con granularidad de cinco minutos, exponiendo los retrasos que realmente impulsan el MTTR.

Una cronología cumple dos funciones a la vez: es la base de evidencia para la revisión de postmortem y la entrada para tu análisis de tendencia de MTTR. Sin ella, “deberíamos responder más rápido” queda en una sensación en lugar de una brecha medida.

Cuándo Usar

Usa esta plantilla cuando:

• Realizas un postmortem después de cualquier incidente P1 o P2
• Un incidente tomó considerablemente más tiempo del esperado en resolverse
• Necesitas identificar si brechas de alertas, herramientas o procesos contribuyeron a los retrasos
• Construyes un caso para mejoras de infraestructura o monitoreo

Para coordinar actualizaciones a stakeholders durante el incidente, usa la plantilla de comunicación de incidentes; esta es para la reconstrucción posterior.

Requisitos Previos

Antes de reconstruir la cronología:

• Reunir logs de todos los sistemas afectados (aplicación, infraestructura, red)
• Recolectar marcas de tiempo de alertas de tu sistema de monitoreo
• Revisar el historial del canal de incidentes de Slack/Teams
• Entrevistar a cada respondedor que participó en el incidente
• Extraer logs de despliegues y cambios de configuración de las 24 horas previas

Solución

# Línea de Tiempo de Incidente: `<Título del Incidente>`

## Metadatos

| Campo | Valor |
|-------|-------|
| ID del Incidente | ______ |
| Severidad | P1 / P2 / P3 / P4 |
| Fecha | ______ |
| Servicio(s) Afectado(s) | ______ |
| Comandante del Incidente | ______ |
| Autor de la Cronología | ______ |

---

## Resumen

| Métrica | Valor |
|---------|-------|
| Tiempo hasta Detectar (TTD) | ______ |
| Tiempo hasta Reconocer (TTA) | ______ |
| Tiempo hasta Mitigar (TTM) | ______ |
| Tiempo hasta Resolver (TTR) | ______ |
| Duración Total del Impacto al Cliente | ______ |

---

## Cronología Detallada

| Hora (UTC) | Evento | Fuente | Actor | Notas |
|------------|--------|--------|-------|-------|
| T-2:00:00 | Último estado conocido como saludable | Dashboard de monitoreo | Sistema | Métricas baseline normales |
| T-1:30:00 | Cambio de configuración desplegado | Logs de CI/CD | deploy-bot | [enlace al cambio] |
| T-0:45:00 | Latencia comienza a aumentar | Métricas de APM | Sistema | p95 sube de 200ms a 500ms |
| T-0:15:00 | Primer pico de tasa de error | Rastreo de errores | Sistema | 0.1% → 2% de tasa de error |
| T+0:00:00 | **Alerta dispara: Tasa de error alta** | PagerDuty | Sistema | Umbral: >1% por 5 min |
| T+0:05:00 | Ingeniero de guardia notificado | PagerDuty | Sistema | |
| T+0:12:00 | Ingeniero de guardia reconoce | PagerDuty | [Nombre Ingeniero] | Retraso: 7 min (investigando otra alerta) |
| T+0:15:00 | Incidente declarado en Slack | Slack | [Nombre Ingeniero] | Canal: #incident-xxx |
| T+0:18:00 | Comienza investigación inicial de logs | Shell | [Nombre Ingeniero] | Revisó logs de aplicación primero |
| T+0:25:00 | Identificada correlación con despliegue | Historial de Git | [Nombre Ingeniero] | Encontró cambio de config en T-1:30:00 |
| T+0:30:00 | Intento de rollback | CI/CD | [Nombre Ingeniero] | Rollback falló: migración nueva bloqueando |
| T+0:35:00 | Escalado a equipo de plataforma | Slack | [Nombre Ingeniero] | Ingeniero de plataforma se une en T+0:40 |
| T+0:45:00 | Equipo de plataforma identifica agotamiento del pool de conexiones de BD | Métricas de BD | [Ingeniero Plataforma] | Pool de conexiones máximo en 100 |
| T+0:50:00 | Aplicado aumento de emergencia del pool de conexiones | Cambio de config | [Ingeniero Plataforma] | Temporalmente elevado a 200 |
| T+0:55:00 | Tasa de error comienza a bajar | Monitoreo | Sistema | Baja a 0.5% |
| T+1:00:00 | Servicio declarado mitigado | Canal de incidente | [Nombre Ingeniero] | Impacto al cliente reducido |
| T+1:30:00 | Causa raíz confirmada: cambio de config filtraba conexiones | Revisión de código | [Ingeniero Plataforma] | Conexión no cerrada en nuevo camino |
| T+2:00:00 | Solución permanente desplegada | CI/CD | [Nombre Ingeniero] | Agregada limpieza de conexión apropiada |
| T+2:15:00 | Monitoreo confirma estabilidad | Dashboards | Sistema | Métricas en baseline por 15 min |
| T+2:15:00 | **Incidente resuelto** | Canal de incidente | [Nombre Ingeniero] | |

---

## Análisis de Retrasos

| Brecha | Duración | Causa Raíz | Item de Acción |
|--------|----------|------------|----------------|
| Alerta a Reconocimiento | 7 min | Ingeniero investigando alerta de menor prioridad | MEJORA-1: Separar enrutamiento de alertas P1 vs P2 |
| Reconocimiento a Declaración de Incidente | 3 min | Ingeniero intentó solucionar solo primero | MEJORA-2: Requerir declaración de incidente dentro de 5 min de alerta P1 |
| Fallo de Rollback | 5 min | Conflicto de migración no documentado en runbook | MEJORA-3: Actualizar runbook de rollback con manejo de migraciones |
| Retraso de Escalamiento | 10 min | Equipo de plataforma no auto-incluido para problemas de BD | MEJORA-4: Agregar alertas de BD al enrutamiento del equipo de plataforma |
| Brecha de Detección | 15 min | Aumento de latencia no disparó alerta | MEJORA-5: Agregar alerta de latencia en p95 >400ms |

---

## Lo Que Funcionó Bien

1. [Observación positiva sobre la respuesta]
2. [Observación positiva sobre la comunicación]
3. [Observación positiva sobre las herramientas]

## Lo Que Funcionó Mal

1. [Observación negativa sobre detección/alertas]
2. [Observación negativa sobre el proceso de respuesta]
3. [Observación negativa sobre documentación/runbooks]

## Items de Acción

| ID | Acción | Responsable | Fecha Límite | Prioridad |
|----|--------|-------------|--------------|-----------|
| MEJORA-1 | ______ | ______ | ______ | Alta |
| MEJORA-2 | ______ | ______ | ______ | Alta |
| MEJORA-3 | ______ | ______ | ______ | Media |
| MEJORA-4 | ______ | ______ | ______ | Media |
| MEJORA-5 | ______ | ______ | ______ | Alta |

Cómo Funciona

La cronología expone brechas: los períodos donde no pasó nada útil. La mayoría de las mejoras de MTTR provienen de eliminar estas brechas, no de hacer más rápido el trabajo activo. La plantilla obliga a documentar la fuente de cada marca de tiempo (línea de log, mensaje de Slack, sistema de monitoreo) para que la cronología sea verificable, no basada en memoria. El análisis de retrasos convierte la cronología en mejoras útiles en lugar de solo un registro histórico.

La notación T± ancla todo al momento en que disparó la primera alerta. Los eventos antes de T+0 forman la brecha de detección; los posteriores mapean a las fases de respuesta:

Cada flecha es un segmento medible. Suma las flechas y obtienes el MTTR; acorta la flecha más larga y el MTTR baja. Por eso existe la tabla de análisis de retrasos: convierte “el incidente duró dos horas” en “la brecha de detección fue de 15 minutos y el escalamiento se comió 10”.

Dirigir la Sesión de Reconstrucción

No construyas la cronología solo en un documento. Ejecuta una sesión de 45 minutos dentro de las 48 horas posteriores a la resolución, mientras los detalles están frescos. La memoria se degrada rápido aquí: los respondedores reconstruyen la secuencia de eventos durante uno o dos días, pero hacia el día cinco empiezan a llenar huecos con lo que “debió” pasar — y una cronología reconstruida por plausibilidad produce items de acción plausibles en lugar de reales.

El formato de sesión que funciona:

1. El escriba redacta el esqueleto solo desde fuentes de máquina: alertas, despliegues, eventos de monitoreo. Sin entrevistas todavía.
2. Los respondedores llenan las brechas en vivo. Comparte el borrador en la reunión. La gente recuerda “ah, ahí noté X” cuando ve un ancla con marca de tiempo.
3. Cuestiona cada brecha mayor a 10 minutos. “¿Qué estábamos haciendo aquí?” suele revelar una alerta faltante, un escalamiento lento o alguien atascado en una hipótesis equivocada.
4. Asigna cada retraso a una causa de sistema, no a una persona. “7 minutos para reconocer” se convierte en “la alerta llegó mientras el ingeniero atendía otro incidente”, lo que mapea a un arreglo de enrutamiento, no a una conversación de rendimiento.

El resultado de la sesión alimenta directamente tu revisión de postmortem y las actualizaciones de tu política de escalamiento.

Fuentes de Marcas de Tiempo por Confiabilidad

Fuente	Precisión	Cuidado con
Métricas de monitoreo (Datadog, Prometheus)	Segundos	Las ventanas de retención pueden perder eventos tempranos
Sistemas de alertas (PagerDuty, Opsgenie)	Segundos	Alerta ≠ detección; la métrica pudo incumplir antes
Logs de CI/CD	Segundos	Tiempo de despliegue ≠ tiempo de propagación
Historial de chat (Slack, Teams)	Segundos	”Lo estoy viendo” ≠ inicio real de la acción
Entrevistas a respondedores	Minutos	La memoria comprime los retrasos; úsala como complemento, no como fuente
Tickets de soporte	Minutos	El inicio reportado por el cliente es el verdadero inicio del impacto

Cuando las fuentes discrepan, prefiere las marcas de tiempo de máquina y anota la discrepancia. Que un respondedor recuerde “reconocí de inmediato” mientras PagerDuty muestra 7 minutos no es una mentira; es exactamente la brecha de percepción que la cronología existe para capturar.

Ejemplo Real de Línea de Tiempo de Incidente

=== Línea de Tiempo de Incidente: INC-2026-07-11-001 ===

Severidad: SEV1 (Crítico)
Servicio: auth-service
Inicio: 2026-07-11 10:55 UTC
Fin:    2026-07-11 11:25 UTC
Duración: 30 minutos

TIMELINE:
10:42  [SISTEMA]  CPU de DB comienza a subir (métrica CloudWatch)
10:50  [SISTEMA]  CPU de DB llega a 95% (umbral: 80%)
10:52  [SISTEMA]  Latencia de login p99 excede 2s (umbral: 1s)
10:55  [ALERTA]   PagerDuty dispara: "auth-service latencia crítica"
10:55  [ALERTA]   PagerDuty dispara: "DB CPU crítico"
10:57  [HUMANO]   Ingeniero de guardia reconoce ambas alertas
10:58  [HUMANO]   Abre canal de incidente #inc-2026-07-11
11:00  [HUMANO]   Declara SEV1 — 15% de logins fallando
11:01  [HUMANO]   Revisa despliegues recientes — deploy de config a las 10:40
11:03  [HUMANO]   Identifica cambio de config: intervalo de rotación de JWT secret
11:04  [HUMANO]   Notifica al canal #support sobre problemas de login
11:05  [HUMANO]   Inicia rollback del cambio de config
11:08  [SISTEMA]  Rollback de config desplegado
11:08  [HUMANO]   Monitorea tasa de error: 15% -> 8% -> 3%
11:12  [SISTEMA]  Tasa de error cae debajo de 0.5%
11:12  [HUMANO]   Actualiza página de estado: "Problema identificado, fix desplegado"
11:15  [HUMANO]   Monitorea por 10 minutos (ventana de estabilidad)
11:25  [HUMANO]   Declara incidente resuelto
11:25  [HUMANO]   Actualiza página de estado: "Resuelto"

ANÁLISIS DE RETRASOS:
  Detección -> Alerta:        3 min  (CPU DB subiendo a las 10:42, alerta a las 10:55)
  Alerta -> Reconocimiento:   2 min  (Bien)
  Reconocimiento -> Declarar: 3 min  (Bien)
  Declarar -> Identificar:    4 min  (Bien — revisó deploys recientes)
  Identificar -> Fix:         3 min  (Bien — rollback rápido)
  Fix -> Estable:             7 min  (Aceptable — drenaje de tasa de error)
  Estable -> Resolver:       10 min  (Ventana de estabilidad estándar)

TOTAL: 30 minutos (RTO objetivo: 30 min — CUMPLIDO)

Este incidente salió bien — todos los segmentos bajo objetivo excepto la ventana de estabilidad, que es deliberada. Fíjate en lo que aún vale la pena capturar: la brecha de detección de 13 minutos antes de que disparara cualquier alerta (CPU de DB subiendo a las 10:42, primera alerta a las 10:55) es la mayor oportunidad de mejora, incluso en un incidente “bueno”.

Variantes

El mismo esqueleto se adapta a distintas audiencias y tipos de incidente. Ajusta la granularidad y el vocabulario, no la disciplina de darle fuente a cada marca de tiempo:

Contexto	Enfoque	Notas
Postmortem sin culpa	Brechas de procesos y sistemas	Evita nombrar individuos; enfócate en fallas de sistemas
Resumen ejecutivo	Cronología de impacto al negocio	Comprime a 5-10 eventos clave con impacto al cliente
Incidente de seguridad	Cronología del vector de ataque	Incluye acciones del atacante y respuestas defensivas
Degradación de rendimiento	Correlación de métricas	Enfócate en cambios de métricas y sus efectos en cascada

Mejores Prácticas

1. Construye la cronología durante el incidente, no después: asigna un escriba para capturar marcas de tiempo en tiempo real
2. Incluye eventos “negativos”: anota cuando las alertas esperadas NO dispararon
3. Cruza múltiples fuentes: no confíes en una sola fuente de logs; la memoria es poco confiable
4. Cuantifica cada brecha: “pasamos algún tiempo” no sirve; “12 minutos” impulsa la mejora
5. Revisa cronologías mensualmente: busca patrones entre incidentes en lugar de tratar cada uno como único

Errores Comunes

1. Construir la cronología de memoria: los humanos comprimen el tiempo y omiten retrasos incómodos
2. Incluir solo acciones exitosas: el rollback fallado que desperdició 10 minutos es más valioso que la solución eventual
3. Usar marcas de tiempo imprecisas: “alrededor de las 2:30” no es suficiente; usa marcas de tiempo UTC exactas
4. Olvidar la brecha de detección: el tiempo entre cuando empezó el problema y cuando disparó la alerta frecuentemente es la brecha más grande
5. No conectar la cronología a items de acción: una cronología sin seguimiento es solo una historia

Checklist de Calidad de la Cronología

Antes de publicar la cronología, verifícala contra esta lista:

• Cada marca de tiempo está en UTC con precisión de segundos o minutos; nada de “alrededor” o “aproximadamente”
• Cada evento cita su fuente (log, alerta, chat, entrevista); una cronología sin fuentes no se puede verificar
• La brecha de detección está documentada: el delta entre la primera desviación de métrica y la primera alerta
• Todas las brechas mayores a 10 minutos tienen una anotación, aunque sea “investigando X, sin progreso”
• Las acciones fallidas aparecen junto a las exitosas: rollbacks que no funcionaron, hipótesis sin salida
• Los eventos esperados pero ausentes están anotados (p. ej., “la alerta de BD debió disparar a T-0:45 y no lo hizo”)
• El análisis de retrasos mapea cada brecha a una causa de sistema y a un item de acción concreto
• Al menos un respondedor además del escriba revisó la cronología para validarla
• El análisis de retrasos lista responsables y fechas límite concretos, no intenciones vagas

Una cronología que pasa este checklist alimenta el postmortem; una que falla se convierte en narración. Interesante de leer, pero no impulsará las mejoras sistémicas que realmente reducen el MTTR el próximo trimestre.

Solución de Problemas

• Las fuentes muestran marcas de tiempo contradictorias: normaliza todo a UTC primero. Un mensaje de Slack en PDT y un evento de CloudWatch en UTC parecerán una brecha de 7 horas hasta que conviertas. Si el conflicto persiste, confía en la marca de máquina y anota el desacuerdo.
• Nadie recuerda qué pasó durante una brecha: revisa las reacciones de emoji y las ediciones de mensajes del canal del incidente; tienen marca de tiempo y suelen revelar cuándo cambiaron las hipótesis. Consulta sesiones de git blame o el historial de terminal si el respondedor ejecutó comandos.
• La cronología contradice el relato del ingeniero: ese es el punto del ejercicio. Presenta los datos de máquina sin acusación; la corrección (“creí que respondí rápido, pero fueron 9 minutos”) es el aprendizaje, no una falta.
• Los logs expiraron antes del postmortem: ejecuta la reconstrucción dentro de las 48 horas. Si tu retención de logs es más corta que tu cadencia de postmortems, ese es el primer item de acción.
• La cronología está completa pero el postmortem sigue atascado: la cronología muestra cuándo, no por qué. Combínala con una revisión de postmortem que recorra la cadena causal detrás de cada brecha.

Lectura Adicional

• Google SRE Book — Postmortem Culture: el argumento canónico para la reconstrucción sin culpa y por qué las cronologías la anclan.
• Atlassian — Incident Postmortem Guide: estructura de facilitación para la reunión de revisión que consume la cronología.
• The List of Public Postmortems: decenas de cronologías de incidentes reales de Google, Cloudflare, AWS y otros para calibrar tu granularidad.
• PagerDuty — Post-Incident Review Guide: fuentes de datos y herramientas para captura automática de cronologías.