Plantilla de postmortem

Un postmortem es una revisión escrita de un incidente, completada después de restablecer el servicio. El libro de SRE de Google lo define como un registro del incidente, su impacto, las acciones tomadas para mitigarlo, sus causas raíz y las acciones de seguimiento que evitan que vuelva a ocurrir. Una plantilla de postmortem mantiene ese registro consistente de un incidente al siguiente.

Los postmortems son sin culpas. Parten de que todos actuaron de buena fe con la información que tenían, y preguntan qué permitió el sistema en lugar de quién cometió un error. Los equipos que esperan culpas dejan de reportar problemas, y la revisión pierde los detalles de los que depende.

El mismo documento recibe otros nombres: revisión post-incidente (post-incident review) en Microsoft y GitLab, y corrección de error (correction of error, COE) en Amazon.

Acuerda los criterios antes del próximo incidente, para que nadie tenga que debatirlos después. El libro de SRE de Google enumera detonantes habituales:

• Caída o degradación visible para los usuarios por encima de un umbral definido
• Pérdida de datos de cualquier tipo
• Intervención de la guardia, como un rollback o redirigir tráfico
• Tiempo de resolución por encima de un umbral definido
• Una falla del monitoreo, cuando el incidente se descubrió manualmente

Cualquier parte interesada también puede pedir uno. AWS añade que un incidente no requiere una interrupción: un casi-incidente, o un sistema que se comporta de forma inesperada aunque siga funcionando, también vale la pena revisarlo. GitLab exige una revisión para cada incidente S1 y S2 y permite que cualquiera la solicite para severidades menores.

Escríbelo mientras los detalles están frescos. El ejemplo publicado por Google salió menos de una semana después de cerrar el incidente, y Azure publica sus revisiones finales por lo general en un plazo de 14 días.

Detalles del postmortem

Dale al postmortem un único responsable, no un comité. Google señala cuatro responsables como síntoma de un postmortem débil: los colaboradores ayudan, una persona lo lleva hasta el final. Nombra también a un revisor. En GitLab, un "Bar Raiser" par aprueba cada revisión antes de que pueda cerrarse. Enlaza el informe de incidente y el RCA en lugar de repetirlos.

Resumen

Escríbelo al final. La recomendación de AWS es escribir el resumen como si fuera a llegar por correo a la principal parte interesada de tu empresa: quién se vio afectado, durante cuánto tiempo, cómo se mitigó y qué evitará que se repita. Debe entenderse por sí solo.

Impacto

Usa cifras: solicitudes fallidas, clientes afectados, minutos de impacto, presupuesto de errores consumido. Google divide el impacto en impacto para los usuarios, en los ingresos y en el equipo, porque las horas que dedicaron quienes respondieron son parte del costo. Si una cifra es una estimación, indica cómo se estimó.

Momentos clave de la cronología

Registra solo los momentos que importan: detonante, detección, escalamiento, mitigación y resolución. Empieza en el detonante, como un despliegue o un pico de tráfico, no en la alerta, y usa UTC. La cronología minuto a minuto queda en el informe de incidente.

Causa raíz y detonante

Mantén separadas las dos cosas. El detonante inició el incidente; la causa raíz es la condición que permitió que se convirtiera en un incidente. En el postmortem de ejemplo de Google, el detonante fue un aumento repentino de tráfico y la causa raíz una fuga de recursos latente. El tipo de causa raíz te indica qué clase de corrección buscar: GitLab espera que un incidente causado por un cambio de código produzca acciones que eviten que defectos similares se escapen, no solo un parche. Para el análisis completo, usa la plantilla de análisis de causa raíz.

Detección, diagnóstico y mitigación

Esta sección pregunta cómo podría haber sido más rápida la respuesta. Para cada fase, el proceso de corrección de error de AWS pregunta cómo podrías reducir el tiempo a la mitad. GitLab trata una detección o recuperación lenta como un factor contribuyente que necesita su propia acción correctiva.

Lecciones aprendidas

Tres listas, de la plantilla de Google: qué salió bien, qué salió mal y dónde tuviste suerte. La última recoge los casi-incidentes, lo que limitó el daño por casualidad y no estará ahí la próxima vez.

Acciones a realizar

Esta es la parte que cambia algo. Cada acción tiene un responsable, una prioridad, una fecha límite y un enlace al ticket que la sigue. Haz que el estado final sea verificable ("alertar cuando el uso del pool de conexiones supere el 80%", no "mejorar el monitoreo") y cubre la prevención y la detección, no solo la reparación. La lista de verificación de postmortems de Google pide al menos una acción de alta prioridad, o el acuerdo explícito de las partes interesadas de que se acepta el riesgo de recurrencia.

Lista de verificación de la revisión

La lista se basa en la lista de verificación de postmortems de Google y en los criterios de cierre de GitLab. Un postmortem está terminado cuando el impacto está evaluado, cada acción tiene responsable y seguimiento, el lenguaje que culpa a personas ha desaparecido, el revisor lo ha aprobado y se ha compartido.

Información de respaldo

Enlaza paneles, logs y el chat del incidente en lugar de pegarlos. Enumera también los incidentes relacionados, incluidos los similares que no son repeticiones exactas. Un patrón entre varios incidentes suele ser un hallazgo más importante que cualquier postmortem individual.

El siguiente ejemplo continúa el incidente INC-2026-017 usado en las plantillas de informe de incidente y de análisis de causa raíz.

Título: El agotamiento del pool de conexiones de la base de datos causó errores elevados en la API Incidente: INC-2026-017, SEV-2, 3 de septiembre de 2026 Responsable: Líder de Ingeniería de plataforma Revisor: Staff engineer, Equipo de base de datos Estado: Final, acciones abiertas Postmortem público: No requerido

Resumen

Entre las 14:03 y las 14:31 UTC, alrededor del 18% de las solicitudes a la API pública fallaron. Consultas analíticas de larga duración mantuvieron abiertas conexiones a la base de datos hasta agotar el pool compartido. Quienes respondieron terminaron las consultas y aumentaron la capacidad de conexiones. Estamos aplicando un tiempo de espera a las consultas de la carga de trabajo analítica, moviéndola a su propio pool de conexiones y agregando una alerta de saturación.

Impacto

El 18% de las solicitudes a la API fallaron durante 28 minutos. Los paneles y la página de estado no se vieron afectados, y no se perdieron datos. Cuatro ingenieros dedicaron alrededor de una hora cada uno a la respuesta.

Momentos clave de la cronología

Causa raíz y detonante

Causa raíz: No se aplicaba ningún tiempo de espera a las consultas en el pool de conexiones compartido entre el tráfico analítico y el de cara al cliente. Detonante: Un job analítico programado. Tipo: Capacidad

Detección, diagnóstico y mitigación

La alerta de tasa de error se disparó cuatro minutos después de que empezara el impacto. Una alerta de saturación del pool de conexiones se habría disparado antes de que fallara cualquier solicitud. Relacionar los errores con el pool llevó ocho minutos porque el runbook de la base de datos no tenía un paso para el agotamiento de conexiones.

Lecciones aprendidas

• Salió bien: la alerta de tasa de error se disparó en cuatro minutos, y el incidente se declaró cinco minutos después.
• Salió mal: el tráfico analítico y el de la API compartían un único pool, y nada alertaba sobre su saturación.
• Tuvimos suerte: el job se ejecutó antes del pico de tráfico de Estados Unidos.

Acciones a realizar

Un incidente suele producir los tres, en este orden.

El postmortem se construye sobre los otros dos en lugar de reconstruir el incidente. Toma los hechos del informe de incidente y la causa del análisis de causa raíz, y los convierte en lecciones y acciones con responsable. Los incidentes de baja severidad pueden necesitar solo el informe.

Algunos incidentes necesitan una versión para los clientes. GitLab publica un análisis de causa raíz público para cada incidente S1, y Google recomienda compartir los postmortems lo más ampliamente posible, "quizás incluso con tus clientes". Un postmortem público es un documento aparte escrito a partir del interno, no el interno con los nombres eliminados.

Las revisiones post-incidente de Azure responden siempre las mismas seis preguntas:

1. ¿Qué pasó?
2. ¿Qué salió mal y por qué?
3. ¿Cómo respondimos?
4. ¿Cómo estamos haciendo que incidentes como este sean menos probables o tengan menos impacto?
5. ¿Cómo pueden los clientes hacer que incidentes como este tengan menos impacto?
6. ¿Cómo podemos hacer más útiles nuestras comunicaciones de incidentes?

Conserva los detalles que reconstruyen la confianza: horas, alcance, la causa en lenguaje claro y los cambios que estás haciendo. Deja fuera nombres internos, teorías provisionales y cualquier cosa que identifique a un cliente o usuario concreto. Publícalo donde los clientes miraron durante el incidente, como tu página de estado, y enlázalo desde la actualización final del incidente.

• Describe el sistema, no a la persona. La guía de GitLab da ejemplos de la diferencia:

  Escribe	En lugar de
  "El proceso de despliegue no detectó este problema"	"La persona X cometió un error"
  "No teníamos monitoreo para esta condición"	"No siguieron el proceso"
  "El runbook no tenía un paso para este escenario"	"El ingeniero de guardia debería haberlo sabido"

• Publícalo en una o dos semanas. El ejemplo de Google de un postmortem débil se publicó cuatro meses después del incidente. La interrupción de ese caso de estudio volvió a ocurrir, y un informe tardío pierde los detalles que habrían ayudado.

• Mantén un lenguaje factual. Las descripciones dramáticas distraen de los hallazgos y ponen a la gente a la defensiva. Respalda cada afirmación con datos.

• Involucra a todas las personas que participaron. Un postmortem escrito por un solo equipo tiende a pasar por alto los factores contribuyentes que vieron otros equipos.

• Compártelo ampliamente. El valor de un postmortem crece con el número de personas que aprenden de él. Por defecto, da acceso a toda la organización de ingeniería.

• Haz seguimiento de las acciones hasta cerrarlas. Cada acción va a tu sistema de tickets, y alguien revisa el avance. Un postmortem con acciones abiertas no está terminado.

• Vigila las repeticiones. Si los incidentes se parecen a otros anteriores, pregúntate si las acciones tardan demasiado en cerrarse o si se registraron las acciones correctas.

¿Cuál es la diferencia entre un postmortem y una revisión post-incidente?

Nada sustancial. Ambos son una revisión escrita de un incidente después de restablecer el servicio, que cubre el impacto, la causa, las lecciones y las acciones de seguimiento. Microsoft y GitLab lo llaman revisión post-incidente, Amazon lo llama corrección de error y muchos equipos dicen postmortem.

¿Qué es un postmortem sin culpas?

Un postmortem sin culpas busca las condiciones del sistema y del proceso que permitieron un incidente, en lugar de a la persona que hizo un cambio. Parte de que todos actuaron de buena fe con la información que tenían. Así, las personas reportan los problemas abiertamente, lo que le da a la revisión los detalles que necesita.

¿Quién debería escribir el postmortem?

Un único responsable, normalmente del equipo dueño del servicio afectado, con aportes de todas las personas que participaron en la respuesta. GitLab hace responsable de sus revisiones de incidentes al equipo dueño del servicio, y un revisor distinto aprueba el resultado.

¿Cuánto tiempo después de un incidente deberías escribir el postmortem?

En una o dos semanas desde la resolución, mientras los detalles están frescos. El ejemplo publicado por Google salió menos de una semana después de cerrar el incidente, y Azure publica las revisiones post-incidente finales por lo general en un plazo de 14 días.

¿Todo incidente necesita un postmortem?

No. Define los criterios de antemano, como una caída visible para los usuarios por encima de un umbral, cualquier pérdida de datos, la intervención de la guardia o una falla del monitoreo. Cualquier parte interesada también puede pedir uno. Los incidentes menores pueden necesitar solo un informe de incidente.

Decide antes del próximo incidente qué severidades requieren un postmortem, quién es el responsable, quién lo revisa, dónde se guarda y cómo se hace seguimiento de sus acciones. Cuando eso está resuelto de antemano, escribir el postmortem es rutina y no un debate.

Hechos de forma consistente, los postmortems se convierten en un registro consultable de cómo fallan tus sistemas y qué cambiaste en respuesta. Ese registro es lo que hace más corto el siguiente incidente.

La estructura de esta plantilla sigue cómo estas organizaciones escriben y revisan sus postmortems. Difieren sobre todo en cuándo se requiere una revisión, con qué rapidez se publica y quién la aprueba.