Respuesta a Incidentes: Proceso Paso a Paso

Descripción General

A las 3 de la madrugada salta una alerta y tres ingenieros saltan sobre el mismo problema, cada uno aplicando un arreglo distinto mientras la página de estado sigue en silencio y los tickets de soporte se acumulan. Eso es la respuesta a incidentes sin proceso: gente ocupada, decisiones confusas y clientes que se enteran de la caída antes de que se lo digas tú.

La respuesta a incidentes es el proceso estructurado de reaccionar ante interrupciones de servicio no planificadas. Un proceso definido reduce el tiempo medio de resolución (MTTR), limita el impacto en el cliente y baja el estrés de quienes responden. Esta guía cubre el ciclo completo — declarar el incidente, asignar roles, comunicar, mitigar y cerrar — con plantillas que puedes copiar directamente al playbook de tu equipo. El objetivo no es un documento perfecto; es un equipo que ejecuta los mismos pasos disciplinados cada vez que algo sale mal.

Cuándo Usar

• Las caídas de producción ocurren sin un dueño claro de la respuesta.
• Varios ingenieros saltan a los incidentes sin coordinación.
• La comunicación a stakeholders durante las caídas es inconsistente o inexistente.
• Tu MTTR va en aumento o supera tu SLO.
• Quieres practicar y mejorar las capacidades de respuesta de forma proactiva.

Esta guía cubre el proceso de respuesta en sí. Si lo que necesitas es el lado de las guardias — rotaciones, horarios de paginación y políticas de escalado — consulta el Playbook de Guardias y Respuesta a Incidentes.

Conceptos Clave

Concepto	Descripción
Incidente	Una interrupción o degradación no planificada del servicio
Comandante de Incidente (IC)	Único responsable de decisiones que coordina la respuesta
Severidad	Clasificación de impacto (Sev1 = crítico, Sev4 = menor)
MTTR	Tiempo Medio de Resolución — tiempo promedio para restaurar el servicio
Líder de Comunicación	Persona responsable de las actualizaciones a stakeholders
Postmortem	Revisión sin culpa tras la resolución del incidente

La estructura viene del Incident Command System que usan bomberos y servicios de emergencia, adaptada al software en las prácticas documentadas por el libro de SRE de Google y las herramientas comerciales de incidentes. La idea central traslada bien: bajo presión, un equipo necesita un único responsable de decisiones y un protocolo compartido, no un debate.

Respuesta a Incidentes vs. Gestión de Problemas

Aquí se confunden dos disciplinas. La respuesta a incidentes trata de restaurar el servicio ahora: declarar, coordinar, mitigar, verificar. La gestión de problemas es la disciplina lenta que viene después — el postmortem, el análisis de causa raíz, el arreglo sistémico que evita la recurrencia. Mezclarlas en mitad del incidente es como los equipos acaban debatiendo arquitectura en la sala de crisis mientras los usuarios siguen sin servicio.

Mantén el límite explícito. Durante el incidente, el trabajo del IC es restaurar el servicio; cualquier cosa que huela a arreglo permanente — un refactor, un cambio de esquema, una mejora “de paso que estamos” — va a la lista de acciones del postmortem, no a la sala de crisis.

Clasificación de Severidad de Incidentes

Severidad	Criterios	Respuesta	Comunicación
Sev1	Caída completa, ingresos detenidos, pérdida de datos	Todo el equipo, sala de crisis	Notificación a dirección, página de estado, comunicación a clientes
Sev2	Degradación mayor, funcionalidad principal rota	Equipo de guardia + refuerzo	Página de estado, canales internos
Sev3	Impacto parcial, hay solución temporal	Guardia principal	Ticket interno, sin comunicación externa
Sev4	Problema menor, impacto mínimo al usuario	Mejor esfuerzo	Seguimiento en ticket, sin urgencia

Elige la severidad por el impacto al usuario, no por cómo se vea el bug técnicamente. Una mala configuración de una línea que tira el checkout es un Sev1; una fuga de memoria en un proceso batch interno probablemente es un Sev3 aunque el arreglo sea complejo. Cuando los criterios resulten ambiguos, sube un nivel — bajar un Sev2 a Sev3 no cuesta nada, y nadie se arrepiente de haber respondido de más ante un incidente menor.

Define estos niveles por escrito antes de necesitarlos. La Plantilla de Plan de Respuesta a Incidentes incluye una matriz de severidad lista para adaptar a tus servicios.

Respuesta a Incidentes Paso a Paso

El ciclo completo, desde la primera alerta hasta el postmortem:

1. Detectar y Declarar

Una alerta es una señal; un incidente es una decisión. Las alertas se convierten en incidentes cuando la evaluación inicial confirma impacto real al usuario y la respuesta estándar del runbook no basta:

## Checklist de Declaración de Incidente

- [ ] Alerta recibida y reconocida
- [ ] Evaluación inicial confirma impacto al usuario
- [ ] Severidad evaluada (Sev1-4)
- [ ] Comandante de Incidente asignado
- [ ] Canal de incidente creado (p. ej., #incident-2024-001)
- [ ] Página de estado actualizada (Sev1/Sev2)
- [ ] Stakeholders notificados (Sev1)

Principios de Declaración

• Ante la duda, declara. Bajar de severidad es más fácil que ponerte al día después.
• Los incidentes Sev1 reciben un Comandante de Incidente de inmediato.
• Crea un canal dedicado para cada incidente Sev1/Sev2.
• Registra hora de inicio, disparador y evaluación inicial.

La calidad de la detección importa tanto como la velocidad de la declaración. Si las alertas saltan tarde o por motivos equivocados, la declaración se vuelve ruidosa y los ingenieros aprenden a ignorar los avisos. La Guía de Gestión de Alertas cubre cómo afinar esa señal.

2. Asignar Roles

Los roles claros previenen el caos:

Rol	Responsabilidades	Requerido Para
Comandante de Incidente	Toma todas las decisiones, asigna tareas, controla el alcance	Sev1, Sev2
Líder Técnico	Investiga la causa raíz, propone soluciones	Sev1, Sev2
Líder de Comunicación	Redacta actualizaciones de estado, gestiona la comunicación a stakeholders	Sev1
Registrador	Documenta la cronología, las acciones y las decisiones	Sev1
Respondedor	Ejecuta las tareas asignadas por el IC	Todos

Lo Que Funciona con los Roles

• El IC no investiga directamente; coordina.
• Solo el IC habla en nombre del equipo de incidentes ante los stakeholders.
• Rota al IC si la persona actual lleva más de 2 horas en el cargo.
• El registrador anota la hora de cada acción y decisión importante.
• En equipos pequeños una persona puede acumular dos roles — normalmente Líder Técnico más Respondedor — pero nunca combines IC con investigación.

3. Comunicar Bien

La comunicación es tan importante como la respuesta técnica — quizá más, porque los stakeholders que no escuchan nada asumen lo peor:

Audiencia	Canal	Frecuencia	Contenido
Equipo de respuesta	Canal de incidente	Continuo	Estado, hipótesis, acciones
Stakeholders internos	#incidents o Slack	Cada 15-30 min (Sev1)	Impacto, ETA, lo que sabemos
Dirección	Email/Slack DM	Cada 30-60 min (Sev1)	Impacto de negocio, plan de recuperación
Clientes	Página de estado	Cada 15-30 min (Sev1/2)	Qué está afectado, ETA, soluciones temporales

## Plantilla de Actualización de Estado

**Incidente:** #incident-2024-001
**Severidad:** Sev1
**Inicio:** 14:30 UTC
**Estado:** [Investigando / Identificado / Monitoreando / Resuelto]

**Impacto:** [Qué está roto y a quién afecta]
**Lo que sabemos:** [Comprensión actual de la causa raíz]
**Lo que estamos haciendo:** [Pasos activos de remediación]
**ETA:** [Tiempo estimado de resolución o siguiente actualización]
**Solución temporal:** [Cualquier alternativa disponible para los usuarios]

Siguiente actualización: 15:00 UTC

Principios de Comunicación

• Promete menos y entrega más en las ETAs.
• No especules sobre la causa raíz hasta estar seguro.
• Actualiza aunque nada haya cambiado (“seguimos investigando”).
• Cierra el ciclo: notifica al resolver y después comparte la cronología del postmortem.

En incidentes Sev1 dentro de entornos regulados — fintech, salud, cualquier cosa que maneje datos personales — la comunicación a clientes puede acarrear obligaciones legales más allá de la página de estado. Las reglas de notificación de brechas (la ventana de 72 horas del GDPR es la más conocida) implican que el Líder de Comunicación debería involucrar a legal o compliance pronto, en lugar de redactar el lenguaje externo en solitario.

La Plantilla de Comunicación de Incidentes te da variantes listas de esta plantilla para clientes, dirección y equipos de soporte.

4. Investigar y Mitigar

Mientras el IC mantiene la sala coordinada, el Líder Técnico dirige la investigación:

## Pasos de Investigación

1. **Confirmar alcance:** ¿Qué está roto? ¿Para quién? ¿Desde cuándo?
2. **Identificar cambios:** ¿Qué se desplegó recientemente? ¿Cambios de configuración?
3. **Verificar dependencias:** ¿Los servicios downstream están sanos?
4. **Revisar logs y métricas:** Encuentra el primer error, el pico, la divergencia
5. **Formular hipótesis:** ¿Cuál es la causa más probable?
6. **Probar la hipótesis:** ¿Puedes reproducir o validar la teoría?
7. **Implementar el arreglo:** Rollback, cambio de config, escalar, parche
8. **Verificar la recuperación:** Confirma que las métricas vuelven a la normalidad y los reportes de usuarios se resuelven

La división es deliberada. El IC sigue el panorama global — alcance, stakeholders, la próxima actualización — mientras el Líder Técnico profundiza en las hipótesis. Si el IC empieza a depurar, nadie vigila el reloj ni el canal; si el Líder Técnico empieza a informar a dirección, la investigación se frena. Mantén los carriles separados.

Estrategias de Mitigación

Estrategia	Cuándo Usarla	Riesgo
Rollback	Un despliegue reciente causó el problema	Bajo, si está probado
Desactivar feature flag	Una funcionalidad concreta está rota	Muy bajo
Escalar	Agotamiento de capacidad	Bajo, pero puede ocultar la causa raíz
Circuit breaker	Una dependencia está fallando	Bajo, degrada funcionalidad
Desvío de tráfico	Problema regional o de despliegue	Medio, requiere preparación
Intervención manual	Corrupción de datos, estado complejo	Alto, requiere experiencia

Mitiga primero, diagnostica después. Si un rollback restaura el servicio en cinco minutos, tómalo — la investigación forense puede correr sobre la versión rota en staging mientras los usuarios están tranquilos.

5. Resolver y Cerrar

Un incidente no termina cuando sale el arreglo. Termina cuando puedes demostrarlo:

## Checklist de Resolución

- [ ] Servicio completamente restaurado y verificado
- [ ] El monitoreo muestra verde durante 15+ minutos
- [ ] Página de estado actualizada a "Resuelto"
- [ ] Comunicación final enviada a los stakeholders
- [ ] El registrador tiene la cronología completa documentada
- [ ] Postmortem agendado dentro de 48 horas
- [ ] Incidente cerrado formalmente en el sistema de seguimiento

Principios de Resolución

• No cierres sin confirmación del monitoreo — reabrir un incidente resuelto destruye la credibilidad más rápido que la propia caída.
• Mantén el canal de incidente abierto 24 horas para preguntas de seguimiento.
• Agenda el postmortem antes de que la memoria se desvanezca; los detalles decaen en días.
• Registra MTTR y frecuencia de incidentes como métricas operativas.

6. Relevar en Incidentes Largos

Los incidentes que superan las dos horas necesitan un plan de rotación, no héroes. Un IC cansado toma malas decisiones, y una investigación que sobrevive a un relevo descuidado pierde horas reexplicando el contexto.

Haz el relevo así:

• El IC saliente escribe un resumen de estado: severidad actual, qué se sabe, qué se descartó, acciones en curso y cuándo toca la próxima actualización a stakeholders.
• El IC entrante lo lee en voz alta y pregunta hasta poder recontar la historia. Solo entonces se transfiere el mando — anúncialo en el canal del incidente, no por privado.
• El registrador y el Líder de Comunicación rotan en el mismo momento para que la cronología y las comunicaciones externas se mantengan coherentes.
• Para cobertura follow-the-sun, releva en los límites de región con una ventana corta de solape (15-30 minutos) en lugar de un corte abrupto.

Escribe el resumen del relevo en el canal del incidente, no en un privado ni en un documento que nadie encuentra. Seis meses después, cuando la revisión del postmortem pregunte por qué se tomó una decisión, el registro del canal es la única fuente de verdad que tienes.

Las rotaciones, los horarios de paginación y las políticas de escalado están en el Playbook de Guardias y Respuesta a Incidentes.

Herramientas de Respuesta a Incidentes

El proceso funciona con un documento compartido y un canal de chat, pero la tooling dedicada elimina fricción donde más duele: paginación, coordinación y comunicación al cliente.

Categoría	Qué hace	Herramientas comunes
Paginación / guardias	Escala alertas a la persona correcta, gestiona rotaciones	PagerDuty, Opsgenie, Splunk On-Call
Gestión de incidentes	Canales, roles, cronologías y tareas en un solo lugar	incident.io, FireHydrant, Rootly
Página de estado	Comunicación pública a clientes	Atlassian Statuspage, Better Stack, Instatus
Feature flags	Mitigación instantánea sin despliegues	LaunchDarkly, Flagsmith, Unleash
Chat / sala de crisis	Coordinación en tiempo real	Slack, Microsoft Teams, Zoom

Dos reglas prácticas para elegir herramientas:

• Automatiza primero lo aburrido: creación del canal, asignación de roles, captura de la cronología y borradores de página de estado. Cada paso manual es un paso que alguien olvida a las 3 de la madrugada.
• No dejes que la herramienta se convierta en el proceso. Un equipo que no puede gestionar un Sev1 con un canal de chat y un documento compartido no se salva con más tooling.

Medir la Respuesta a Incidentes

Lo que no mides, no lo mejoras. Registra cuatro métricas operativas por incidente:

Métrica	Definición	Dirección objetivo
MTTA	Tiempo medio en reconocer la alerta	A la baja (minutos)
MTTD	Tiempo medio de detección — reporte de usuario vs monitoreo	A la baja; el monitoreo debería ganar
MTTR	Tiempo medio de resolución — declaración a recuperación verificada	A la baja
Cumplimiento de acciones	Porcentaje de acciones del postmortem entregadas a tiempo	Al alza hacia el 100%

Un ejemplo concreto. El último trimestre tu equipo tuvo seis incidentes con impacto al usuario, con tiempos de resolución de 18, 45, 27, 92, 33 y 61 minutos:

MTTR = (18 + 45 + 27 + 92 + 33 + 61) / 6 = 276 / 6 = 46 minutos

Ahora desglosa. El outlier de 92 minutos fue un Sev2 sin IC declarado durante los primeros 40 minutos — ese único dato dice más que el promedio. Revisa el MTTR por severidad, por servicio y por si una acción de postmortem habría prevenido el incidente. Los equipos que persiguen el cumplimiento de las acciones con rigor suelen ver caer los incidentes repetidos en dos trimestres.

Pon los números donde alguien los lea. Una revisión de operaciones mensual que recorra los incidentes recientes — MTTR, si la severidad declarada coincidió con el impacto real, qué acciones se atrasaron — hace más por el proceso que cualquier dashboard que nadie abre.

Ejemplo Práctico: Cronología de un Sev-1

La teoría se absorbe mejor como historia. Así se ve un Sev1 bien gestionado, minuto a minuto, en una plataforma SaaS cuya API se cae:

Incidente: API caída, 100% de las peticiones fallando
Severidad: Sev-1 (crítico)
Inicio: 03:15 UTC
Guardia: Ana (primaria), Luis (secundario)

Cronología de la respuesta:
  03:15 - Salta la alerta: APIErrorRate 100% en api-gateway
  03:16 - Ana recibe el aviso (PagerDuty)
  03:17 - Ana abre Slack #incident-sev1, declara Sev-1
  03:18 - Ana toma el rol de IC, asigna a Luis como Líder Técnico
  03:19 - Abre sala de crisis (Zoom), invita al team lead, DBA, infra
  03:21 - Luis verifica: 503 en todos los endpoints
  03:23 - Luis revisa despliegues recientes:
         kubectl rollout history deploy/api-gateway
         -> Despliegue v3.2 hace 12 min
  03:26 - Carlos (DBA) revisa la BD: pool de conexiones 200/200
         con peticiones en cola -> saturación
  03:28 - Ana decide: rollback a v3.1 mientras Luis
         sigue investigando en paralelo
  03:30 - Rollback ejecutado: kubectl rollout undo
  03:33 - API restaurada, errores al 0%
  03:38 - Ana confirma estabilidad 5 min, cierra la sala
  03:42 - Última actualización de estado; postmortem agendado (48h)
  03:45 - El bot registrador exporta la cronología del canal

Roles durante el incidente:
  | Rol | Persona | Responsabilidad |
  |-----|---------|----------------|
  | Comandante de Incidente | Ana | Coordinar, decidir |
  | Líder Técnico | Luis | Investigar, proponer arreglos |
  | Comunicaciones | Luis (hasta 03:40, luego team lead) | Actualizar stakeholders |
  | Experto BD | Carlos (DBA) | Investigar base de datos |
  | Experto Infra | Pedro | Verificar infraestructura |
  | Registrador | Bot | Cronología en Slack |

Comunicaciones:
  03:19 - #status: "Investigando Sev1 API caída"
  03:26 - #status: "Identificado: despliegue v3.2 correlacionado con el fallo"
  03:28 - #status: "Ejecutando rollback a v3.1"
  03:33 - #status: "API restaurada, monitoreando"
  03:42 - #status: "Incidente resuelto. Postmortem en 48h"

Postmortem (48h):
  - Resumen: API caída 18 min por despliegue defectuoso
  - Impacto: 50K usuarios afectados, ~$15K de ingresos perdidos
  - Causa raíz: una migración en v3.2 introdujo una query que
    escaneaba una tabla grande sin LIMIT. Bajo carga de
    producción retenía conexiones el tiempo suficiente para
    saturar el pool de 200 conexiones y encolar el resto.
  - 5 Whys:
    1. ¿Por qué se cayó? Pool de conexiones saturado
    2. ¿Por qué saturado? Una query lenta retenía las conexiones
    3. ¿Por qué no se detectó? Los tests no cubrían carga de producción
    4. ¿Por qué no había test de carga? El CI no incluía etapa de performance
    5. ¿Por qué? Los tests de carga nunca se priorizaron para este servicio
  - Acciones:
    1. Exigir LIMIT o paginación en las queries (responsable: equipo, 1 semana)
    2. Añadir etapa de test de carga con k6 en CI (responsable: plataforma, 2 semanas)
    3. Bajar el máximo de conexiones del pool por instancia a 100 (responsable: SRE, 3 días)
    4. Añadir alerta de saturación del pool al 80% (responsable: SRE, 3 días)
    5. Checklist de revisión de migraciones para queries riesgosas (responsable: team lead, 1 semana)

Lecciones:
  - El IC coordina; el Líder Técnico investiga
  - Comunica antes de tener respuestas, no después
  - El rollback es la primera opción, no la última
  - Postmortem sin culpa: arregla el sistema, no a la persona
  - Cada acción necesita un responsable y una fecha

Fíjate en los roles: Ana nunca toca kubectl ni la base de datos. Asigna, decide y comunica mientras Luis investiga. Esa separación es lo que evita que un Sev1 de 27 minutos se convierta en uno de dos horas.

Esqueleto de Runbook

Cada servicio crítico merece un runbook que el de guardia pueda ejecutar medio dormido. Este esqueleto cubre lo esencial — adapta las comprobaciones a tu stack:

## Runbook de Servicio: api-gateway

### Síntomas que activan este runbook
- Alerta: tasa de errores > 5% durante 5 min, o latencia p99 > 2s
- Reportes de usuarios de peticiones fallidas

### Primeros 5 minutos
1. Confirma el alcance: ¿qué endpoints, qué regiones, desde cuándo?
2. Revisa el último despliegue: `kubectl rollout history deploy/api-gateway`
3. Revisa dependencias: pool de la BD, servicio de auth, upstreams
4. Revisa dashboards: tasa de errores, latencia, saturación

### Escalera de mitigación (probar en orden)
1. Rollback del último despliegue si correlaciona: `kubectl rollout undo`
2. Desactiva el feature flag sospechoso
3. Escala réplicas si hay falta de capacidad: `kubectl scale --replicas=N`
4. Failover a la región secundaria (requiere aprobación del IC)

### Escalado
- Sev1/Sev2: declara incidente, avisa al secundario + team lead
- Sin progreso en 30 min: escala al dueño del servicio
- ¿Sospecha de corrupción de datos? Congela escrituras, escala al DBA de guardia

### Tras la resolución
- Pega la cronología en el ticket del incidente
- Agenda postmortem (Sev1/Sev2) dentro de 48h
- Actualiza este runbook con todo lo que tuviste que descubrir a mano

Dos reglas hacen que los runbooks funcionen de verdad: se prueban en game days y se actualizan tras cada incidente que exponga un hueco. Un runbook desactualizado es peor que no tenerlo — manda a los respondedores por caminos equivocados con total confianza.

Guarda el runbook donde ocurre el incidente: enlazado desde la propia alerta, fijado en el canal del servicio o junto a los dashboards que el de guardia ya está mirando. Si llegar a él lleva más de treinta segundos a las 3 de la madrugada, es como si no existiera. Lo mismo vale para la página de estado y la lista de escalado — todo lo que necesite el respondedor debería estar a un clic, marcado dentro de la propia plantilla del incidente.

Lo que funciona

• Practica antes de necesitarlo: corre game days y ejercicios de chaos engineering para que el primer Sev1 real no sea el primer ensayo.
• Mitiga antes de diagnosticar. Restaurar el servicio te compra todo el tiempo que necesitas para encontrar la causa raíz con calma.
• Un solo Comandante de Incidente. La autoridad de decisión debe ser única y explícita.
• Comunica en horario fijo, no cuando haya noticias. Un “seguimos investigando” cada 30 minutos mantiene a los stakeholders fuera de tu canal.
• Las notas del registrador son la base del postmortem — escríbelas para la persona que no estuvo allí.
• Si el mismo incidente ocurre dos veces, falló el proceso, no la gente. Trata las repeticiones como deuda de acciones pendientes.

Errores Comunes

• Sin IC claro. Varios ingenieros dando órdenes crea confusión y retraso.
• El IC depurando. En el momento en que el coordinador empieza a investigar, el incidente pierde a su coordinador.
• Saltarse la comunicación. Los stakeholders escriben su propia historia (normalmente equivocada) cuando guardas silencio.
• Perseguir la causa raíz antes de mitigar. A los usuarios no les importa por qué falló; les importa que funcione.
• Marcar resuelto demasiado pronto. Cerrar sin confirmación del monitoreo lleva a incidentes reabiertos.
• Postmortems que nunca ocurren. Un incidente sin postmortem es una lección que pagaste y tiraste a la basura.
• Canales de incidente que crecen a 40 personas. Cura la membresía; los observadores pueden leer la página de estado.

Variantes

• Respuesta a incidentes automatizada: runbooks de auto-remediación disparados por alertas — reiniciar un worker colgado, escalar ante saturación, disparar un circuit breaker. Mantén humanos en el bucle para todo lo irreversible.
• Respuesta follow-the-sun: equipos regionales se relevan en los incidentes entre zonas horarias. Solo funciona con relevos disciplinados y tooling compartido.
• Incidentes de dependencia externa: la caída está en tu proveedor de pagos o región cloud. Tu playbook es escalado más degradación elegante — plantillas de contacto con vendors y modos de respaldo pre-aprobados.
• Respuesta a incidentes de seguridad: brechas y exposición de datos siguen un playbook distinto — contención antes que comunicación, participación de legal y compliance, preservación de evidencia. Consulta la Plantilla de Respuesta a Incidentes de Seguridad.

Solución de Problemas

Problemas que aparecen en el propio proceso de respuesta:

• Los stakeholders puentean al IC y escriben a los ingenieros por privado. Redirige cada “¿hay novedades?” al canal del incidente y respóndelo allí una vez. Hacer cumplir el canal único de comunicación es trabajo del IC.
• El canal del incidente está demasiado lleno para trabajar. Mueve a los observadores a un canal de actualizaciones de solo lectura; deja el canal de trabajo para los roles asignados más los expertos que invite el IC.
• Las actualizaciones de estado se atrasan. Asigna un Líder de Comunicación o pon un recordatorio repetido cada 30 minutos en el canal. El silencio también es un mensaje — el equivocado.
• El incidente dura más que los respondedores. Rota a las 2 horas con un relevo por escrito. Un IC fatigado tomando decisiones multiplica el incidente.
• El MTTR no mejora trimestre a trimestre. Comprueba si las acciones del postmortem realmente se entregan. La recurrencia, no el MTTR, es el primer síntoma de un ciclo de aprendizaje roto.
• Los postmortems se agendan y se descartan en silencio. Seguimiento como si fueran incidentes: responsable, fecha y una revisión que cierre el ciclo.

Ver También

• Recursos complementarios — checklists de declaración y resolución, la plantilla de actualización de estado, el esqueleto de runbook y la cronología completa del Sev-1 como archivos reutilizables.
• NIST SP 800-61 Rev. 2 — Computer Security Incident Handling Guide — el framework canónico de las fases de gestión de incidentes.
• Managing Incidents — Google SRE Book — cómo funciona en la práctica el mando de incidentes de Google.
• PagerDuty Incident Response Documentation — el playbook open source detrás del propio proceso de PagerDuty.

Conclusión

Un buen proceso de incidentes no es un documento — es un hábito. Empieza pequeño: elige una matriz de severidad, escribe una plantilla de actualización de estado y corre el próximo incidente real con un IC declarado y un registrador. Cuando caiga el postmortem, vuelca lo aprendido de vuelta en el runbook. Los equipos que iteran este ciclo dejan de tener el mismo incidente dos veces — y ese es todo el punto.