El manejo de incidentes no termina con la recuperación ── el modelo de postmortem (prevención de recurrencia) para equipos de desarrollo pequeños

«El mismo error que arreglaron el mes pasado volvió a aparecer, pero ahora en otra pantalla» ──¿alguna vez se ha quedado sin palabras al escuchar esto sobre un sistema que mantiene?

El manejo del incidente en sí mismo —es decir, detectarlo, identificar el punto de la causa, corregirlo, publicar la solución y disculparse— muchos equipos lo hacen correctamente. El problema viene después. En el instante en que se recupera el servicio, todo el mundo vuelve a sus tareas habituales, y el registro del incidente queda disperso en la bandeja de entrada de alguien y en registros de chat, donde se va desvaneciendo. Seis meses después, un incidente con la misma estructura reaparece en otro punto, y hay que rehacer la misma investigación desde cero. Un manejo de incidentes que termina en «arreglarlo y disculparse» es una operación que paga la misma matrícula una y otra vez.

En este blog hemos explicado, como aspecto técnico de la investigación de incidentes, «cómo llegar hasta la causa» en artículos como «Introducción a la recolección de volcados de memoria en Windows» y «La práctica de capturar excepciones, registrar logs y gestionar errores». Este artículo aborda el siguiente paso: cómo llevar a cabo, una vez conocida la causa, la revisión (postmortem) para que el mismo incidente no vuelva a ocurrir. No hablamos de servicios web a gran escala, sino que nos centramos en un modelo que un equipo pequeño de 2 a 5 personas que mantiene aplicaciones de negocio y software para Windows puede sostener realmente en la práctica.

1. La conclusión, por adelantado

• La recuperación, la investigación de la causa y la prevención de recurrencia son tareas distintas. La recuperación consiste en «restablecer el trabajo del día», la investigación de la causa en «poder explicar por qué ocurrió» y la prevención de recurrencia en «cambiar el sistema». Si se mezclan, todo queda a medias.
• No buscar culpables (blameless) no es una cuestión ética, sino de utilidad práctica. En un entorno donde se culpa a las personas, la información deja de salir a la luz y resulta imposible llegar a la causa. El principio del postmortem blameless, consolidado en la SRE, consiste en suponer que «cada persona involucrada actuó correctamente dentro del alcance de la información que tenía» y buscar los agujeros del sistema.¹
• Las medidas de prevención de recurrencia se traducen en un mecanismo (código, pruebas, monitorización, procedimientos), no en «tener cuidado». Las medidas que dependen de la atención de una persona desaparecen cuando cambia el responsable. En el capítulo 6 se presenta una tabla para evaluar la fuerza de las medidas.
• La causa se separa en «causa directa» y «factores contribuyentes». Lo que suele poder corregirse es, la mayoría de las veces, el lado de los factores contribuyentes; el truco del «análisis de los cinco porqués» está en no detenerse en el comportamiento de una persona, sino seguir excavando hasta llegar al sistema.
• No se hace un postmortem completo de todos los incidentes. Se triaja según impacto × probabilidad de recurrencia (capítulo 7), y en los casos menores se deja solo un párrafo de registro. Mantener el volumen en un nivel sostenible es la condición más importante para que el sistema no muera.
• El postmortem se dimensiona para poder escribirse en una hora. En el capítulo 4 se presenta una plantilla mínima. Tiene más valor dejar un registro tosco cada vez que escribir cero documentos impecables al mes.
• En el desarrollo subcontratado, se separa el propósito del informe de incidente dirigido al cliente, aunque el contenido se reutiliza a partir del postmortem (capítulo 8). No mezclar el documento de determinación de responsabilidades con el de prevención de recurrencia protege la calidad de ambos.

2. Por qué se repiten los mismos incidentes

En los incidentes que se repiten hay un patrón operativo, no técnico.

En el instante en que se recupera, se da el asunto por «terminado». El manejo de incidentes es una interrupción urgente, así que en cuanto se recupera el servicio, todos vuelven al trabajo habitual que se había acumulado. El tiempo para la revisión no está en el calendario de nadie, y el «lo haremos cuando nos calmemos» nunca llega.

El informe termina con «a partir de ahora tendremos más cuidado». Se cierra el apartado de prevención de recurrencia del informe dirigido al cliente o al superior con frases como «reforzaremos las comprobaciones» o «haremos una doble verificación». Como este texto no cambia ningún mecanismo, unos meses después, cuando la atención se relaja, se cae en el mismo agujero.

Se atribuye a la responsabilidad individual y no se corrige la estructura. Si se zanja el asunto con «fue porque esa persona se saltó la prueba», la estructura que permite saltarse la prueba (el procedimiento de publicación no tiene una compuerta de pruebas, la presión de los plazos hace que se tolere la omisión) permanece intacta. La próxima vez, otra persona hará la misma omisión.

No queda registro, y años después se cae en el mismo agujero. El mantenimiento en un equipo pequeño funciona por un tiempo sin registros precisamente porque «la misma persona se ocupa siempre». Pero la memoria de esa persona se desvanece en unos años y desaparece con la baja o el cambio de responsable. «Me parece que ya vi este error antes, pero no recuerdo cómo lo resolvimos» convierte en un día entero una investigación que, con un registro, habría tardado diez minutos.

Ninguno de estos casos es un problema de capacidad, sino la consecuencia de que la revisión no está definida como parte del trabajo. Precisamente por eso vale la pena decidir de antemano un modelo (una plantilla y unos criterios de aplicación).

3. Qué es un postmortem ── traducir el modelo de la SRE al mantenimiento en equipos pequeños

El postmortem es un modelo de revisión que documenta, como registro de un incidente, el impacto, la causa raíz, la cronología de la respuesta y las acciones de prevención de recurrencia; se consolidó ampliamente a través de la práctica de la SRE (Site Reliability Engineering) de Google. Su núcleo es el principio blameless (no culpar): «un postmortem escrito sin culpar a nadie asume que todas las personas involucradas actuaron de buena fe y de forma correcta según la información que tenían en ese momento» —en lugar de castigar a las personas, se corrige el mecanismo que impidió actuar correctamente.¹

Esta idea no es exclusiva de Google: en la guía de arquitectura de Microsoft (Azure Well-Architected Framework) también se define el postmortem como «una revisión estructurada y sin culpas en la que participan todos los equipos involucrados», y se recomienda devolver los resultados del análisis de causa raíz (RCA) al sistema en forma de mejoras del proceso de respuesta, refuerzo de la detección (observabilidad) y mejora del diseño.²

Se suele pensar que «esto no nos concierne porque no somos un servicio web a gran escala», pero el autor cree justo lo contrario. El postmortem es especialmente eficaz en un equipo pequeño que mantiene aplicaciones de escritorio sin destinar personal en las instalaciones del cliente. Hay tres razones.

1. La misma persona sigue atendiendo los incidentes, así que sin registro todo depende por completo de esa persona. En una organización grande, alguien más lo recordará, pero en un equipo de dos o tres personas, «la persona que recuerda» es la única base de datos. El postmortem se convierte en esa memoria externa.
2. El intervalo entre incidentes es largo. A diferencia de un servicio web, en una aplicación de negocio los incidentes graves ocurren solo unas pocas veces al año. El siguiente llega cuando ya se ha desvanecido el recuerdo del anterior, así que el valor del registro es relativamente mayor.
3. Como no se puede acudir al lugar, la evidencia y el registro son el salvavidas. En el mantenimiento remoto, todo depende de la capacidad de reconstruir después «qué estaba pasando en ese momento», algo directamente conectado con el registro cronológico del postmortem.

Como referencia de cuándo escribir un postmortem, el libro de SRE menciona como ejemplos de criterios de aplicación casos como una interrupción visible para el usuario, la pérdida de datos o la intervención de guardia (on-call).¹ Los criterios para equipos pequeños se organizan de nuevo en el capítulo 7.

4. La plantilla mínima de postmortem

La condición más importante para poder mantener esto es el volumen. Presentamos una plantilla en Markdown diseñada con el límite de que la primera versión se pueda escribir por completo en una hora. Se recomienda colocarla como un archivo con fecha en un lugar como docs/postmortem/ del repositorio, y gestionarla con control de versiones en el mismo sitio que el código.

# Postmortem: datos duplicados al cruzar la fecha en el listado de pedidos (15/07/2026)

- Estado: completado / acciones en curso / solo registrado
- Autor: Komura
- Gravedad: media (el negocio pudo continuar, pero hubo que hacer una conciliación manual)

## Resumen (máximo 3 líneas)
Al abrir el listado de pedidos durante el proceso de cierre mensual,
los comprobantes del día anterior aparecían duplicados. Era un
problema solo de visualización; los datos en la base de datos eran correctos.

## Impacto (quién, qué y cuánto)
- Personas afectadas: 3 miembros del equipo administrativo de ventas
- Contenido del impacto: duplicación en la pantalla de listado. 1 caso en que casi se envió el pedido por duplicado
- Duración: del 15/07 hacia las 9:10 hasta las 11:40 (unas 2 horas y media)

## Cronología
- 09:10 un usuario llama por teléfono diciendo «aparece el mismo comprobante en dos filas» (detección)
- 09:30 se comparte la pantalla de forma remota y se confirman las condiciones de reproducción
- 10:15 medida provisional: se pide no abrir el listado mientras se ejecuta el cierre
- 11:40 se distribuye la versión corregida y se confirma la recuperación

## Causa directa
La consulta del listado hacía un UNION ALL entre las filas que el
proceso de cierre había copiado a una tabla temporal y la tabla
principal (sin control de exclusión).

## Factores contribuyentes
- La ejecución simultánea del cierre y la consulta de pantalla no estaba en los escenarios de prueba
- La existencia de la tabla temporal no estaba documentada en el diseño, por lo que no se tuvo en cuenta al modificar la pantalla
- No había ningún mecanismo para detectar la duplicación; el descubrimiento dependía de que el usuario avisara

## Qué salió bien
- El usuario había anotado la hora en el registro de sus operaciones, lo que agilizó identificar las condiciones de reproducción
- El mecanismo de distribución estaba automatizado, así que se pudo desplegar la versión corregida el mismo día

## Acciones de prevención de recurrencia (responsable y plazo)
- [ ] Añadir una aserción de detección de duplicados a la consulta del listado (Komura, 22/07)
- [ ] Añadir una prueba de ejecución simultánea entre el cierre y la consulta (Komura, 29/07)
- [ ] Estudiar eliminar el esquema de tabla temporal y adoptar aislamiento por instantáneas (Komura, definir el enfoque a fines de agosto)

Para poder duplicarla tal cual, dejamos también la plantilla vacía sin rellenar. Es práctico guardarla en el repositorio como docs/postmortem/_template.md y copiarla con un nombre que incluya la fecha cuando ocurra un incidente.

# Postmortem: el fenómeno en una línea (AAAA-MM-DD)

- Estado: solo registrado / acciones en curso / completado
- Autor:
- Gravedad: alta / media / baja (motivo de la valoración en una frase)

## Resumen (máximo 3 líneas)

## Impacto (quién, qué y cuánto)
- Personas afectadas:
- Contenido del impacto:
- Duración: DD/MM HH:MM a HH:MM (unas   horas)

## Cronología
- HH:MM  (detección: quién y cómo se dio cuenta)
- HH:MM
- HH:MM  (medida provisional)
- HH:MM  (confirmación de recuperación)

## Causa directa

## Factores contribuyentes
- (condición que permitió que se introdujera)
- (condición que hizo que pasara desapercibido)
- (condición que amplió el daño)

## Qué salió bien
-

## Acciones de prevención de recurrencia (responsable y plazo)
- [ ]  (responsable, DD/MM)
- [ ]  (responsable, DD/MM)

A continuación, algunos puntos a tener en cuenta al escribirla.

• El «resumen» debe tener como máximo 3 líneas. Quien busque este documento más adelante será usted mismo en el futuro. Que se entienda el contenido en tres líneas al encontrarlo con una búsqueda es más importante que la elegancia de la estructura de secciones.
• En la cronología se escriben solo hechos, con su hora. Las interpretaciones («debería haber sido…», «se debería haber hecho…») se separan en la sección de causas. Si se mezclan interpretaciones en la cronología, al releerla más tarde resulta imposible reconstruir qué ocurrió realmente.
• Escriba siempre «qué salió bien». Esto evita que la revisión se convierta en una sesión de autocrítica, y sirve de entrada para elevar a mecanismo formal aquello que funcionó por casualidad (por ejemplo, que resultara haber un registro disponible).
• Asigne siempre un responsable y un plazo a cada acción. Una acción sin responsable ni plazo no se ejecuta. La eficacia real de un postmortem depende de que se revise y de que se haga seguimiento de las acciones.¹

5. La práctica del análisis de causas ── separar la causa directa de los factores contribuyentes

Hay una razón para que la plantilla divida el apartado de causas en dos.

La causa directa (direct cause) es el fenómeno técnico que provocó directamente el incidente: «una excepción por falta de comprobación de NULL», «un UNION ALL sin control de exclusión». Es lo que corrige el parche.

Los factores contribuyentes (contributing factors) son las condiciones que permitieron que la causa directa se introdujera, pasara desapercibida o que el daño se ampliara: «no había una prueba para ese caso», «no estaba escrito en el diseño», «la detección dependía del usuario». Aquí es donde se libra la batalla principal de la prevención de recurrencia, y normalmente hay varios.

La razón para separarlos es sencilla: aunque se corrija solo la causa directa, si quedan los factores contribuyentes, entrará otra causa directa distinta por el mismo camino. El «el mismo error en otra pantalla» del inicio del artículo es exactamente esto.

5.1 El análisis de los cinco porqués no se detiene en «el comportamiento de una persona»

Como herramienta para excavar en la causa, el «análisis de los cinco porqués (5 Whys)» es eficaz, pero si se excava en la dirección equivocada se convierte en una herramienta para buscar culpables. El fallo típico es detenerse en «¿por qué? → porque el responsable olvidó comprobarlo». En lugar de detenerse ahí, hay que excavar un nivel más.

• ¿Por qué pudo olvidarse la comprobación? → Porque la comprobación no figuraba ni en el procedimiento ni en la lista de verificación, y dependía de la memoria
• ¿Por qué dependía de la memoria? → Porque el procedimiento de publicación no estaba documentado y se improvisaba cada vez

Cuando el comportamiento de una persona aparece como respuesta, no es el punto final, sino la entrada a la siguiente pregunta sobre el sistema. Si se parte de la premisa de que las personas siempre se equivocan, la pregunta que hay que excavar deja de ser «por qué se equivocó» y pasa a ser «por qué el error llegó tal cual a producción».

5.2 Sin evidencia, el análisis no puede empezar

La calidad del análisis de causas tiene como techo la calidad de la evidencia que quedó registrada en el momento del incidente. Un postmortem que no puede reconstruir la cronología se convierte en un ejercicio de especulación. Para el mantenimiento de aplicaciones de Windows, el mínimo despliegue son estos tres elementos:

• Volcados de memoria (crash dumps): si se configura WER LocalDumps de antemano, queda un volcado al finalizar de forma anómala sin necesidad de que el usuario haga nada. La configuración se explica en «Introducción a la recolección de volcados de memoria en Windows», y cómo leerlos en «Leer volcados de memoria con WinDbg + SOS».
• Registros de la aplicación (logs): hora, un ID que permita correlacionar eventos y escritura síncrona de los eventos críticos. Para un diseño que garantice dejar registros incluso al fallar, consulte «Diseño para conservar logs y volcados al fallar una aplicación de Windows».
• Registro de eventos de Windows (Event Log): aunque el registro propio de la aplicación esté dañado, el registro de eventos estándar del sistema operativo conserva el registro de fallo de la aplicación (Application Error). El modo de aprovecharlo se resume en «Introducción al registro de eventos de Windows y ETW».

Si al escribir el postmortem la cronología no se puede completar, eso en sí mismo es un factor contribuyente —«faltan mecanismos de detección y registro»— y es un candidato a acción de prevención de recurrencia.

6. La calidad de las medidas de prevención de recurrencia ── tabla de evaluación de la fuerza

Una vez anotadas las acciones de prevención de recurrencia, se evalúa su fuerza. El eje del juicio es «cuánto depende de la atención de una persona».

La regla realista aquí es «no prohibir las medidas débiles», sino «no dejar que la medida termine siendo débil». Difundir información tiene sentido como respuesta provisional que se puede hacer el mismo día, pero en el apartado de medida definitiva solo debería escribirse una de nivel medio o superior, y a ser posible, fuerte.

Cuando solo surgen medidas débiles, hay que volver a preguntarse lo siguiente.

• «Si una persona recién incorporada se encontrara en la misma situación, ¿ocurriría este incidente de todos modos?» —si la respuesta es no, no se ha convertido en un mecanismo.
• «¿Se puede hacer que el compilador, una prueba o el CI detecten este error?» —por ejemplo, si «se estaba silenciando la excepción al finalizar», la medida fuerte no es difundir información, sino implementar en el manejador de excepciones común del código una política como la que se organiza en «Tabla de decisión: salir o continuar ante una excepción inesperada».
• «¿Se puede evitar que ocurra el error? ¿Se puede notar antes?» —si prevenirlo resulta muy costoso, inclinarse hacia la detección (monitorización, alertas, procesos batch de conciliación) también es una medida fuerte legítima. La idea de devolver las lecciones del incidente al refuerzo de la detección y a la mejora del diseño se recomienda con el mismo esquema en la guía de Microsoft.²

Como las medidas fuertes requieren más esfuerzo, en la práctica conviene incluir en las acciones tanto «la medida de nivel medio que se hará esta semana» como «la medida fuerte que se hará el mes que viene», y gestionarlas por plazo.

7. A qué incidentes aplicarlo ── el triaje de la ejecución

Si se obliga a hacer un postmortem completo de todos los incidentes, en tres meses nadie lo escribirá. El nivel de ejecución se decide según impacto × probabilidad de recurrencia.

Hay tres puntos clave para la operación.

• La «recurrencia de un incidente similar» sube un nivel, sin importar el impacto. El hecho mismo de que se repita es la prueba de que la medida anterior no se convirtió en un mecanismo.
• Aunque sea menor, deje siempre un registro. Basta con un párrafo. Con los cuatro puntos «fecha, fenómeno, causa y solución», usted mismo, años después, se salvará gracias a la búsqueda. Cuando se acumulan registros de incidentes pequeños, también se hace visible un sesgo estructural, como «esta pantalla en concreto tiene muchos incidentes».
• Ante la duda, decántese por escribirlo, pero reduzca el volumen. Si va a dudar entre hacerlo completo o no, es más rápido empezar a escribir la versión simplificada.

7.1 Cómo determinar si algo es «estructural»

El eje horizontal de la tabla, «fácil de repetir / estructural», no se puede usar sin fijar antes un criterio. En la práctica conviene establecer una referencia sencilla: si se cumple aunque sea uno de los siguientes puntos, se trata como estructural.

• Es la segunda vez en la misma pantalla o el mismo módulo. Aunque haya pasado tiempo, si ocurre dos veces en el mismo lugar, no es casualidad.
• El «patrón» de la causa coincide con un incidente anterior: una comprobación de NULL faltante, un descuido en el control de exclusión, el manejo de un límite de fecha. Aunque el lugar sea distinto, si el patrón es el mismo, es prueba de que ese patrón todavía no se ha cerrado.
• No se puede escribir una prueba que reproduzca el incidente, o aunque se escriba, no se ejecuta. Hay un agujero estructural en la red de detección, así que la próxima vez también pasará desapercibido.
• Es del tipo «no ocurre si se opera en el orden establecido». Lo que depende de un procedimiento operativo se repite en cuanto cambia la persona.
• El mismo código se ejecuta también en otros clientes u otros entornos. El alcance del impacto no termina en este único caso, así que se sube un nivel el tratamiento.

Por el contrario, solo se puede afirmar con seguridad que algo es «puntual» cuando la causa está confinada a un factor externo (un fallo de hardware específico, una interrupción temporal de un servicio del que se depende) y, además, no se ha encontrado ningún agujero en el diseño o el procedimiento propios. Ante la duda, decántese por lo estructural: escribir de más casi nunca causa problemas.

7.2 Cómo llevar a cabo la reunión de revisión (30 minutos)

El truco de la reunión de revisión que se hace para incidentes de impacto alto es fijar el tiempo y seguir el modelo al pie de la letra.

• Los participantes son de 3 a 5 personas: quien respondió al incidente, otros miembros que podrían tocar el mismo código y quien atiende al cliente. No se incluye a quien tenga el papel de juzgar responsabilidades. En el momento en que se incluye, las intervenciones se vuelven defensivas y dejan de salir los factores contribuyentes. Si hace falta, basta con compartirle después el resultado.
• Distribuya la primera versión de antemano. No empiece a escribirla en la propia reunión. Aun así, no se puede dar por hecho que todos la habrán leído, así que se incluye un tiempo de lectura al principio.
• Reparto de los 30 minutos: (1) 0-5 min: cada uno lee en silencio (2) 5-10 min: verificación de los hechos de la cronología, para corregir discrepancias de percepción y completar horas que falten (3) 10-20 min: añadir factores contribuyentes; esta es la parte central (4) 20-28 min: evaluar la fuerza de las acciones (tabla del capítulo 6) y fijar responsable y plazo (5) 28-30 min: decidir la fecha en que se revisará el progreso.
• Solo hay dos puntos de vista que verificar: «¿en qué otro punto se podría haber notado?» y «¿hay el mismo agujero en algún otro lugar?». Al plantear estas dos preguntas a todos, salen a la luz factores contribuyentes que la persona que respondió por sí sola no habría identificado.
• La persona que modera no debe ser quien respondió al incidente. Cuando surja una intervención con el nombre de una persona como sujeto, quien modera la sustituye por el sujeto del mecanismo: «el señor A olvidó comprobarlo» → «la comprobación no estaba incluida en el procedimiento». Con solo hacer esta sustitución de forma sistemática, el ambiente de la reunión cambia.
• No deje acciones sin definir. Lo que no se pueda decidir en la propia reunión se convierte en una acción del tipo «decidir el enfoque antes del día X del mes X», con un plazo, y se cierra así.

7.3 Dónde colocar el libro de gestión de incidentes

El «libro de gestión de incidentes» que ha aparecido varias veces hasta ahora no implica comprar una herramienta especializada. Solo hay tres requisitos que cumplir: que se pueda buscar en texto completo años después, que cada incidente se sume como una línea, y que todo el equipo pueda escribir en él. Si se cumplen estos tres puntos, el formato no importa.

Basta con que las columnas sean «fecha / sistema-pantalla / fenómeno / impacto / causa directa / solución / enlace al postmortem / si es una recurrencia». Lo importante no es la herramienta, sino estos dos puntos: que siempre se sume una línea aunque el incidente sea menor, y que años después se pueda buscar por «el mismo fenómeno». Un estado en el que solo se dependa de hilos de chat y correos no cumple ninguno de los dos.

8. El tratamiento en el desarrollo subcontratado ── la relación con el informe de incidente dirigido al cliente

En un contrato de subcontratación o de mantenimiento, después de un incidente el cliente suele pedir un «informe de incidente». Tener organizada de antemano la relación entre el postmortem y el informe evita hacer el trabajo dos veces.

Alrededor del 80 % del contenido se puede reutilizar. El resumen, el impacto, la cronología, la causa directa y las medidas de prevención de recurrencia son exactamente los elementos que componen el informe dirigido al cliente. Si se sigue el orden de escribir primero el postmortem interno y editar a partir de él la versión para el cliente, desaparece la necesidad de redactar un texto solo para el informe.

Sin embargo, hay que ser consciente de que son dos documentos con propósitos distintos y mantenerlos separados.

8.1 Cómo se reescribe en la práctica

Como en abstracto resulta difícil de entender, usamos tal cual el ejemplo de la plantilla del capítulo 4 y ponemos en paralelo cómo cambia la redacción interna al pasarla al cliente.

Los principios de la reescritura son tres.

• Traduzca los términos técnicos al lenguaje del negocio, pero sin diluir los hechos. «UNION ALL» y «aserción» se sustituyen por palabras que el responsable del cliente pueda explicar a su superior. Por otro lado, información que delimita el alcance del impacto, como «solo en la visualización, los datos están correctos», debe conservarse siempre. Si esto queda ambiguo, aumentan las consultas en lugar de disminuir.
• Escriba como hecho también las carencias de procedimiento internas. Si se elimina «no estaba escrito en el diseño», desaparece el motivo de la medida de prevención de recurrencia y no se transmite «por qué eso lo soluciona». Se cuida la formulación, pero no se hace como si no hubiera existido.
• Elimine el nombre del responsable, pero conserve la fecha. El nombre del responsable interno no es necesario para el cliente. En cambio, la fecha prevista de ejecución se mantiene como una promesa, y se informa cuando se complete.

La razón principal para separarlos es que si se mezcla la discusión de determinación de responsabilidades y compensación con la de prevención de recurrencia, ambas se distorsionan. En un documento donde está en juego la responsabilidad, los involucrados inevitablemente escriben a la defensiva. De un documento defensivo desaparecen los factores contribuyentes, y la prevención de recurrencia degenera en «tendremos cuidado». Por el contrario, si se entrega tal cual al cliente un postmortem interno franco, puede ocurrir que algún pasaje sin contexto adquiera vida propia. Es más seguro separar «el documento interno, escrito con franqueza» del «documento externo, que transmite con precisión», y establecer un flujo de una sola dirección en que el primero da lugar al segundo.

Además, si en el informe dirigido al cliente se escribe una medida de prevención de recurrencia prevista, eso es una promesa hecha al cliente. Se gestiona el plazo con el mismo mecanismo que el apartado de acciones del postmortem, y se informa cuando se complete. Este ida y vuelta convierte el incidente, más bien, en una oportunidad para construir confianza.

9. Resumen

• El manejo de incidentes no termina con la recuperación. Se incorpora la revisión (postmortem) al trabajo, tratando la recuperación, la investigación de la causa y la prevención de recurrencia como tareas distintas.
• El postmortem se rige por el principio blameless (no culpar). Si se culpa a las personas, la información deja de salir y no se puede llegar a la causa. No se detiene el análisis en el comportamiento de una persona; se excava hasta los agujeros del sistema (los factores contribuyentes).¹
• Con el documento basta la plantilla mínima que se puede escribir en una hora (resumen, impacto, cronología, causa directa, factores contribuyentes, qué salió bien, y acciones con responsable y plazo). Como condición previa para poder completar la cronología, se instala de antemano la conservación de evidencia mediante volcados de memoria, registros y el registro de eventos.
• Las medidas de prevención de recurrencia se elevan de «tener cuidado» (débil) a un procedimiento (medio) y, a ser posible, a prevenirlo mecánicamente con pruebas, aserciones, monitorización y cambios de diseño (fuerte). El esquema de devolver las lecciones a la detección y al diseño es común tanto en la guía de la SRE como en la de Microsoft.¹²
• No se aplica el proceso completo a todos los incidentes. Se triaja según impacto × probabilidad de recurrencia, y hasta en los casos menores se deja siempre al menos un párrafo de registro.
• En el desarrollo subcontratado, se escribe primero el postmortem interno, y el informe de incidente para el cliente se edita a partir de él. Separar el documento de responsabilidad y compensación del documento de prevención de recurrencia protege la calidad de ambos.

Artículos relacionados

• Introducción a la recolección de volcados de memoria en Windows - WER/ProcDump/WinDbg
• Leer volcados de memoria con WinDbg + SOS ── introducción práctica al análisis después de la recolección
• Diseño para conservar logs y volcados al fallar una aplicación de Windows
• Introducción al registro de eventos de Windows y ETW ── llevar los logs de una aplicación de negocio al mecanismo estándar del sistema operativo
• La práctica de capturar excepciones, registrar logs y gestionar errores
• Tabla de decisión: salir o continuar ante una excepción inesperada

Áreas de consultoría relacionadas

KomuraSoft LLC se ocupa desde la investigación y el análisis de causas de defectos difíciles de reproducir, pasando por la construcción de mecanismos de conservación de evidencia (recolección de logs y volcados), hasta la organización del régimen de operación y mantenimiento, incluida la prevención de recurrencia. También son bienvenidas las consultas desde etapas como «el mismo incidente se sigue repitiendo» o «las medidas de prevención de recurrencia del informe de incidentes se han quedado en letra muerta».

• Investigación de fallos y análisis de causas
• Modificación y mantenimiento de software Windows existente
• Consultoría técnica y revisión de diseño
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Qué es un postmortem? ¿En qué se diferencia de un informe de incidente?

El postmortem es un documento y una actividad de revisión estructurada que se realiza después de recuperarse de un incidente, un método consolidado en el campo de la SRE (Site Reliability Engineering, ingeniería de fiabilidad de sitios). Se basa en el principio de no culpar a las personas (blameless) y registra la cronología, la causa directa, los factores contribuyentes y las acciones de prevención de recurrencia. Mientras que el informe de incidente dirigido al cliente es un documento de rendición de cuentas sobre «qué ocurrió y cómo se abordó», el postmortem es un documento interno para decidir «cómo cambiar el sistema para que esto no vuelva a ocurrir». Sin embargo, como la mayor parte del contenido se superpone, resulta eficiente escribir primero el postmortem y luego editar a partir de él el informe dirigido al cliente.

Las medidas de prevención de recurrencia siempre terminan siendo «a partir de ahora tendremos más cuidado». ¿Qué se puede hacer?

«Tener cuidado» o «difundir la información» depende de la memoria y la buena voluntad de las personas, así que el efecto desaparece con el tiempo y los cambios de responsable. Al pensar en una medida, vuelva a preguntarse: «si una persona recién incorporada se encontrara en la misma situación, ¿ocurriría este incidente de todos modos?». Si la respuesta es no, la medida no se ha convertido en un mecanismo. Las medidas fuertes son las que se detectan o previenen mecánicamente sin que nadie tenga que prestar atención: pruebas automatizadas, aserciones, restricciones impuestas por tipos o por el diseño, alertas de monitorización, etc. Si no se puede implementar de inmediato una medida fuerte, coloque una lista de verificación o un procedimiento como etapa intermedia y registre la medida definitiva como una acción con fecha límite.

En un desarrollo subcontratado con pocas personas, no tenemos margen para escribir un postmortem de todos los incidentes.

No hace falta escribir un postmortem completo de todos los incidentes, y si se intenta, el propio sistema deja de sostenerse. Es mejor triajar la ejecución según el impacto y la probabilidad de recurrencia: aplicar el proceso completo a los incidentes que implican paralización del negocio o pérdida de datos y a las recurrencias de incidentes similares, y dejar solo un párrafo de registro en el libro de gestión de incidentes para los casos menores. Lo importante es «dejar siempre un registro, incluso de lo menor»: cuando el mismo fenómeno vuelve a aparecer años después, que el registro anterior se pueda buscar marca una gran diferencia en el tiempo de investigación.

¿No buscar culpables (blameless) no es lo mismo que dejar la responsabilidad en el aire?

No lo es. Blameless es un principio para desplazar el foco de «quién cometió el error» a «por qué el sistema permitía que esa persona lo cometiera». Si un operador se equivocó al manipular algo, el factor contribuyente está en la interfaz o el procedimiento que permitió ese error. En una organización que castiga a las personas, la información se oculta en el siguiente incidente y resulta imposible llegar a la causa. Por otro lado, la rendición de cuentas ante el cliente (qué ocurrió y cómo se compensará) debe realizarse mediante un documento y un proceso distintos, y esto no contradice una revisión blameless. El punto clave en la práctica es separar el documento de determinación de responsabilidades del documento de prevención de recurrencia.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.