Grabar post-mortems de incidentes: convertir las caídas en conocimiento de equipo

Todos los equipos escriben un documento post-mortem después de una caída. Muchos menos lo leen. Una cronología bien redactada, llena de enlaces a paneles y fragmentos de logs, le pide al lector que reconstruya el incidente en su cabeza, y la mayoría lo hojea, asiente y sigue adelante.

Una grabación de pantalla breve cambia eso. En lugar de describir cómo se veía la gráfica de errores a las 02:14, la muestras. En lugar de explicar qué consulta reveló la causa raíz, la ejecutas. En esta guía verás cómo grabar post-mortems que la gente realmente mira y cómo mantenerlos útiles meses después.

Por qué grabar un post-mortem

• La evidencia gana a la descripción: gráficas, trazas y logs son visuales por naturaleza; una captura pierde el movimiento antes/después que hace evidente un pico
• Se produce más rápido: narrar lo que ya tienes abierto lleva menos tiempo que redactar prosa cuidada
• Mejor para quien se incorpora: seis minutos de repaso enseñan los modos de fallo de tu sistema mucho más rápido que una página de wiki
• Conserva el razonamiento: los documentos registran qué pasó; las grabaciones capturan por qué quien respondió pensó lo que pensó en cada paso
• Compatible con el trabajo asíncrono: los equipos distribuidos asimilan la revisión sin agendar otra reunión entre husos horarios

Qué grabar y qué no

Un post-mortem grabado no es la repetición de todo el incidente. Quédate con las partes donde ver supera a leer:

Graba esto:

• El momento de la detección: la alerta, el panel, el primer reporte de una persona usuaria
• La gráfica clave que muestra el impacto durante la ventana del incidente
• Los pasos de investigación que acotaron el problema (incluidos los callejones sin salida)
• El código, la configuración o la consulta exacta que provocó el fallo
• La aplicación del arreglo y la recuperación de las métricas

Sáltate esto:

• Los largos tramos esperando despliegues o carga de datos
• Las conversaciones internas ajenas al diagnóstico
• Cualquier cosa que puedas resumir en una frase de narración

Prepararte antes de pulsar Grabar

Las herramientas de incidentes muestran mucho que no quieres en un vídeo compartido. Dedica cinco minutos:

1. Abre todas las pestañas antes: paneles en el rango horario correcto, la consulta de logs relevante, el pull request, la alerta
2. Fija los rangos temporales: ancla los paneles a la ventana del incidente para que todos vean lo mismo que tú
3. Cierra lo sensible: fichas de clientes, tickets internos con datos personales, mensajes privados, gestores de credenciales
4. Silencia las notificaciones: nada desinfla un post-mortem serio como un recordatorio de la comida en plena narración
5. Escribe un guion de tres líneas: impacto, causa raíz, prevención. Todo lo demás cuelga de esos tres puntos

Usa captura de ventana en lugar de pantalla completa cuando tu panel viva en una sola ventana del navegador: es la forma más sencilla de garantizar que nada más se cuele en el encuadre.

Una estructura que funciona

Mantén las grabaciones entre cinco y diez minutos. Una estructura fiable:

1. Primero el impacto (30 segundos): a quién afectó, durante cuánto tiempo y con qué gravedad. Empieza por aquí, es a lo que viene la mayoría
2. Recorrido por la cronología (2–3 minutos): detección, escalado, mitigación y resolución, mostrados sobre el panel real
3. Causa raíz (2–3 minutos): enseña la ruta de código, el cambio de configuración o la consulta reales. Haz zoom en las líneas concretas
4. Qué lo hizo difícil (1 minuto): alertas que faltaban, logs confusos, responsabilidades poco claras; justo lo que un documento suele aplanar
5. Acciones (1 minuto): enuncia cada una con su responsable y enlázalas en la descripción

Usar el editor para que se entienda

El material bruto de un incidente es denso. El editor de Recorded lo convierte en algo seguible:

• Efectos de zoom: los paneles y las líneas de log son pequeños. Amplía el pico, el mensaje de error, el diff culpable; nadie debería forzar la vista
• Regiones de velocidad: acelera los pipelines de despliegue y la ejecución de consultas, y vuelve a velocidad normal en el momento en que aparece la causa
• Superposiciones de texto: marca las marcas de tiempo (02:14 UTC — primera alerta) para que el vídeo se corresponda con el documento
• Recorte: elimina el arranque fallido en el que descubriste que el panel tenía el rango equivocado
• Efectos de cursor: resalta los clics cuando muestres la ruta exacta de reproducción

Usa la webcam solo en la introducción y el cierre. Una cara ayuda a marcar el tono en el impacto y las acciones; durante el análisis de logs solo tapa la terminal.

Mantener el tono sin culpables ante la cámara

El vídeo transmite el tono de una forma que el texto no. La misma frase suena a análisis o a acusación según cómo se diga.

• Di «el despliegue introdujo» en lugar de nombrar a quien lo publicó
• Narra las decisiones con el contexto disponible entonces: «en este punto todavía no teníamos la métrica de profundidad de cola»
• Muestra los callejones sin salida sin disculparte: demuestran que el sistema era difícil de diagnosticar, y eso ya es una acción pendiente
• Vuelve a grabar la introducción si la primera toma suena frustrada. Son dos minutos y marcan el tono para todo el mundo

Combinar vídeo y documento

La grabación complementa al documento post-mortem, no lo sustituye. Los documentos se buscan, se enlazan y se hojean; el vídeo no.

Una buena combinación:

• El documento sigue siendo la fuente de verdad para cronología, acciones y responsables
• La grabación se incrusta arriba, con una línea que resume qué cubre
• Las marcas de capítulo en la descripción permiten saltar directo a la causa raíz
• Las acciones viven en tu gestor de tareas, no solo en el vídeo

Construir una biblioteca de incidentes

Una grabación suelta es útil. Una colección lo es mucho más.

• Nombra de forma coherente: 2026-09-28-checkout-latency-postmortem se ordena y se busca sin problemas
• Etiqueta por sistema: agrupa por servicio implicado para entregar de una vez todo lo relativo a un componente a quien entra de guardia
• Revisa cada trimestre: ver las grabaciones del trimestre de una sentada hace evidentes los fallos recurrentes
• Úsalas en la incorporación: tres o cuatro incidentes seleccionados son la vía más rápida para enseñar cómo se rompe de verdad tu sistema

Errores comunes

• Grabar durante el incidente: primero la mitigación. La revisión se graba después, cuando puedas narrar con calma
• Compartir el material en bruto: una pantalla compartida de 40 minutos sin editar no es un post-mortem; nadie la ve
• Filtrar datos de clientes: mira siempre tu grabación una vez antes de compartirla, buscando datos personales en logs y paneles
• Saltarte el resumen de impacto: quien solo vea el primer minuto debe llevarse igualmente lo esencial
• Dejar que sustituya al documento: dentro de seis meses, cuando empiece un incidente parecido, un vídeo no se puede buscar

Conclusión

Los post-mortems fallan cuando se escriben para archivarse en lugar de para entenderse. Una grabación de pantalla enfocada —impacto por delante, evidencia real en pantalla, narración sin culpables y acciones claras— convierte cada caída en algo que todo el equipo puede aprender en diez minutos.

Graba tu próximo post-mortem en lugar de solo escribirlo y comprueba cuánta más gente se implica.