Las acciones de un postmortem quedan estancadas porque escribir el documento cierra el tema en la cabeza de todos. El arreglo cae en un backlog sin dueño ni fecha, compitiendo contra las features. De ahí salen los incidentes repetidos. Se corrige con un dueño por acción, una fecha y una revisión antes del próximo incidente.
El libro de SRE de Google define el postmortem como un registro escrito del incidente que termina con las acciones de seguimiento para que no vuelva a ocurrir. O sea, el documento existe para generar trabajo. Y ese trabajo es justo la parte que se cae. Si nadie en tu equipo es dueño del backlog de confiabilidad entre un incidente y otro, ese es el hueco que el trabajo de SRE y observabilidad busca cerrar.
¿Por qué no se cumplen las acciones de un postmortem?
Porque nada las obliga a competir con el roadmap en igualdad de condiciones. El incidente tenía urgencia. Había usuarios afectados, alguien recibió la alerta y todos veían el reloj. Las acciones no heredan nada de eso. Caen en un backlog al lado de los tickets de features. Cada feature tiene un product manager que la defiende. La acción del postmortem no tiene a nadie.
El libro de SRE de Google lo dice sin vueltas. Sin un proceso formal para aprender de los incidentes, estos pueden repetirse indefinidamente. La palabra importante es proceso. Un documento de postmortem por sí solo no ejecuta nada. Queda en una wiki mientras el mismo factor contribuyente espera el próximo viernes complicado.
Hay cuatro patrones que alcanzan para frenar una acción, y ninguno necesita mala intención.
El primero es la vaguedad. Una acción como mejorar el monitoreo no tiene un criterio de cierre, así que nunca termina. El segundo es la culpa disfrazada. AWS marca como antipatrón identificar solo el error humano sin sumar capacitación ni automatización que lo prevenga. Tener más cuidado es un deseo. Nadie puede cerrarlo.
El tercero es el dueño colectivo. Cuando una acción le pertenece al equipo de plataforma, en la práctica le pertenece a quien tenga una tarde libre. El cuarto es la revisión que nunca ocurre. Si nadie mira las acciones abiertas hasta la próxima alerta, la próxima alerta se convierte en la revisión.
¿Qué hace que una acción de postmortem valga la pena?
Una buena acción cambia el sistema para que el mismo factor contribuyente no pueda causar el mismo impacto otra vez. Además está escrita para que una sola persona pueda terminarla y otra pueda verificarla.
El ejemplo público más claro está en el workbook de SRE de Google. Un desmantelamiento de rutina de un rack se cruzó con un bug en la automatización de mantenimiento. Una parte del proceso había fallado, así que el equipo lo volvió a correr. En ese reintento la lista de máquinas venía vacía. La API trató la lista vacía como si no hubiera ningún filtro. En pocos minutos se borraron los discos de todas las máquinas satélite del mundo. Gracias a una buena planificación de capacidad, muy pocos usuarios lo notaron durante los dos días que llevó reinstalar.
El seguimiento fue trabajo de hormiga. El equipo pasó varias semanas auditando la automatización y sumando validaciones para que el flujo de desmantelamiento fuera idempotente. Tres años después hubo un incidente parecido, con varios satélites drenados. Google atribuye a las acciones de aquel primer postmortem haber reducido mucho el impacto de la segunda vez.
Eso es lo que te da una acción terminada. El beneficio puede llegar años después, cuando nadie se acuerda del ticket. Un arreglo que vive en la automatización no depende de que alguien recuerde el incidente.
AWS suma un chequeo que vale la pena correr en cada postmortem. Pregúntate por qué los tests existentes no detectaron el problema. En caso de que falte, agrega un test para ese caso. Así un incidente se convierte en una protección permanente.
Así reescribiría yo acciones débiles como estas antes de publicar el postmortem.
| Acción débil | Versión más fuerte | Por qué se sostiene |
|---|---|---|
| Tener más cuidado al reintentar la automatización | Hacer el flujo idempotente y rechazar una lista de destinos vacía | La protección vive en el código y sobrevive a la rotación del equipo |
| Mejorar el monitoreo | Alertar sobre el síntoma que vio el usuario, para que la guardia lo encuentre antes que un cliente | Google trata como motivo de postmortem una falla de monitoreo que obligó a descubrir el incidente a mano |
| Agregar más tests | Agregar un test que reproduzca la entrada exacta de este incidente | AWS pide revisar por qué los tests existentes no lo detectaron |
| Compartir lo aprendido | Sumar el patrón a la checklist previa al deploy que usan otros equipos | AWS recomienda llevar los patrones a guías de desarrollo y checklists |
| Seguir investigando la causa raíz | Nombrar la duda pendiente, un dueño y una fecha para reportar | La pregunta abierta tiene fecha de cierre en lugar de quedar para siempre |
¿Quién debe ser el dueño de las acciones de un postmortem?
Una persona con nombre por cada acción, y otra persona dueña del seguimiento de todas. Son dos trabajos distintos.
La guía Well-Architected de AWS pide asignar un dueño claro para el proceso de análisis posterior al incidente. También pide designar un equipo o una persona que supervise las investigaciones y los seguimientos. Asignar cada ticket es la mitad fácil. Si solo cumples esa mitad, las acciones quedan olvidadas sin que nadie lo note. Cada dueño cree que su acción está bien y nadie ve la pila completa.
El dueño del seguimiento se encarga de que nadie maquille la lista. Cada acción la ejecuta su propio dueño. Yo le daría dos cosas. La primera es un espacio fijo en la reunión semanal de planificación. La segunda es la autoridad para escalar cualquier acción preventiva que se pase de fecha dos veces.
Si tu organización todavía está definiendo dónde termina SRE y dónde empieza plataforma, la división está explicada en ingeniería de plataforma vs DevOps vs SRE. El dueño del seguimiento puede existir antes de que termine ese debate. Yo no lo esperaría.
Aquí también importa que el postmortem no busque culpables. Según el libro de SRE de Google, un postmortem sin culpa parte de que todos actuaron con buena intención y con la información que tenían. Si las acciones se leen como castigo, la gente las negocia hasta dejarlas en nada. Redáctalas sobre el sistema, nunca apuntando a una persona.
¿Cómo priorizar las acciones de un postmortem frente a las features?
Ordénalas por lo que costaría la próxima vez que pase, y decide en la revisión del postmortem con el dueño del roadmap presente. Si quien define la prioridad de las features nunca ve las acciones, las acciones pierden sin que nadie las defienda.
No todas las acciones merecen construirse. El libro de SRE de Google reconoce que el postmortem tiene un costo real de tiempo y esfuerzo. Por eso el equipo elige con cuidado cuándo escribir uno. La misma disciplina sirve para las acciones. Cada una debería salir de la revisión con uno de dos resultados. O recibe un dueño, una fecha y un lugar en el plan, o se cierra como riesgo aceptado con la razón por escrito. Las dos salidas son válidas. Dejarla abierta dos trimestres no lo es.
Yo ordenaría los candidatos con una sola pregunta por acción. Si este factor contribuyente vuelve a dispararse el mes que viene, ¿cuánto cuesta en impacto para el usuario y en horas de guardia? Primero van las acciones que evitan pérdida de datos o caídas visibles para el usuario. Después, las que solo acortan la detección. Google pone la pérdida de datos de cualquier tipo y la caída visible para el usuario entre sus motivos habituales de postmortem. Es una buena pista de dónde poner el peso.
Después protege una porción pequeña y fija de cada ciclo de planificación para las acciones que sobreviven. Acuerda el tamaño en frío, antes del próximo incidente. Una porción negociada en la semana de la caída se cambia por otra cosa a la semana siguiente.
¿Cómo saber si tus postmortems evitan incidentes repetidos?
Revisa si los incidentes nuevos comparten un factor contribuyente con un postmortem viejo que todavía tiene acciones abiertas. Si es así, ya tienes la respuesta para la dirección.
AWS nombra esta falla de forma directa. Sin un mecanismo para conservar lo aprendido, los equipos terminan con incidentes repetidos que tienen la misma causa raíz o una muy parecida.
Unos pocos números simples dicen más que rediseñar un dashboard. Cuenta los incidentes del último trimestre que coinciden con el factor contribuyente de un postmortem anterior. Anota la antigüedad de la acción preventiva abierta más vieja. Compara las acciones cerradas como hechas con las cerradas como riesgo aceptado. Si gana el riesgo aceptado, dilo en voz alta en la revisión.
En caso de que ya midas las métricas DORA, sigue con ellas. Sirven para detectar que algo anda mal. Para saber qué postmortem quedó olvidado, hace falta revisar las acciones abiertas.
También conviene ampliar la red. AWS aclara que un incidente no requiere una caída. Un incidente que estuvo cerca de pasar también cuenta. Esos casos son repeticiones baratas. Documéntalos en pocas líneas y compáralos contra las acciones abiertas de la misma forma.
Por último, comparte los resultados más allá del equipo que recibió la alerta. Según AWS, compartir los hallazgos permite que otros sistemas mitiguen el riesgo si tienen los mismos factores contribuyentes. Un arreglo que vive en el backlog de un equipo protege a un solo equipo.
Empieza por el último incidente repetido
Toma el último incidente por el que preguntó la dirección. Abre los postmortems del último año y busca el mismo factor contribuyente. Dedícale 30 minutos. Si encuentras un postmortem anterior con una acción preventiva abierta, ahí tienes la respuesta honesta a por qué volvió a pasar. Lleva esa acción a la próxima reunión de planificación con el nombre de un dueño y una fecha al lado. Después pídele al dueño del roadmap que la ubique en el plan antes de que termine la reunión.
Fuentes
- sre.google, consultada el 29 de octubre de 2026 (sha256 ef876f0a0f09).
- sre.google, consultada el 29 de octubre de 2026 (sha256 25b55c64c879).
- docs.aws.amazon.com, consultada el 29 de octubre de 2026 (sha256 942fdbe73578).