Diagrama de flujo de respuesta a incidentes: de la primera alerta al postmortem

A las tres de la mañana nadie lee una política de incidentes de diez páginas. La persona de guardia necesita saber cuatro cosas rápido: si es real, si es un incidente, quién más tiene que enterarse y qué hacer primero. Un diagrama de flujo de una página responde a esas preguntas en el orden en que surgen, y es la parte de la política que la gente sigue de verdad.

Este artículo construye un diagrama de flujo de respuesta a incidentes para un equipo de ingeniería que opera un servicio en producción: el triaje, los criterios para declarar un incidente, la severidad y los roles, la mitigación y el postmortem que cierra el ciclo. Termina con consejos de dibujo para que el diagrama siga siendo útil bajo presión.

Qué tiene que decidir el diagrama de flujo

Un proceso de incidentes es una serie de decisiones con algunas actividades largas entre ellas. Las decisiones van en el diagrama, escritas como preguntas con respuestas etiquetadas:

• ¿La alerta es real y accionable? Si no, el problema es la alerta.
• ¿Es un incidente? Si no, es trabajo normal con un ticket.
• ¿Qué tan grave es? La severidad decide a quién se avisa y a quién se informa.
• ¿Se ha restablecido el servicio? Si no, prueba la siguiente mitigación o escala.

Todo lo demás, como revertir un despliegue o conmutar una base de datos, va en runbooks enlazados desde el diagrama.

Cuándo declarar un incidente

Declarar es el paso ante el que los equipos dudan, y esa duda sale cara. El capítulo Managing Incidents del libro de SRE de Google defiende declarar pronto: es mejor declarar, encontrar una solución sencilla y cerrar el incidente que iniciar el proceso horas después de que empiece un problema creciente. El equipo de ese capítulo declara un incidente cuando se cumple cualquiera de estas condiciones:

1. Hace falta un segundo equipo para resolver el problema.
2. La caída es visible para los clientes.
3. El problema sigue sin resolverse tras una hora de análisis concentrado.

Pon tus propios criterios en el diagrama, junto a la decisión. Unos criterios claros eliminan el coste social de declarar.

Roles

El mismo capítulo describe una estructura basada en el Incident Command System. Incluso un equipo pequeño se beneficia de nombrar los roles, porque el fallo más común es que una sola persona los asuma todos:

El comandante del incidente también mantiene un documento vivo del incidente y hace un traspaso explícito al final de su turno: el comandante saliente anuncia el traspaso y espera confirmación.

Las habilidades de gestión de incidentes se oxidan cuando no se usan. El mismo capítulo sugiere aplicar el marco a cambios operativos que abarcan varios equipos o zonas horarias, y ensayar incidentes pasados como juego de rol, para que el proceso resulte familiar antes del siguiente incidente real. Recorrer el diagrama de flujo con una persona nueva en la guardia usando un incidente antiguo es una forma barata de empezar.

Niveles de severidad

Las definiciones de severidad varían según la empresa, así que toma estas como ejemplo y escribe las tuyas en el diagrama:

El diagrama de flujo, paso a paso

1. Reconocer y triar. Cuando salte la alerta, reconócela para que el aviso deje de escalar y luego evalúa el alcance y el impacto.
2. ¿Real y accionable? Una alerta falsa o no accionable se ajusta o se elimina, y luego se cierra.
3. ¿Es un incidente? Aplica los criterios. Si no lo es, trátalo como trabajo normal con un ticket.
4. Declarar. Nombra al comandante del incidente, abre un canal y el documento del incidente.
5. Severidad. En SEV-1 y SEV-2, una persona responsable de comunicación publica en la página de estado y envía actualizaciones periódicas.
6. Mitigar primero. Revierte, conmuta, desactiva el feature flag o descarta carga. La primera prioridad según el libro de SRE es detener la hemorragia, restablecer el servicio y conservar las pruebas; la causa raíz viene después.
7. ¿Restablecido? Si no, prueba la siguiente mitigación o escala, y repite el bucle.
8. Resolver. Confírmalo con métricas, sigue vigilando y devuelve el sistema a la operación normal.
9. Postmortem y acciones. Escribe un postmortem sin culpas, revísalo y cierra el incidente cuando las acciones estén registradas.

Cómo leerlo:

• Sí va a la derecha, No va hacia abajo. Todas las decisiones siguen la misma convención, así que el camino principal avanza hacia la derecha y las salidas tempranas bajan.
• A la izquierda, la primera respuesta. La alerta se reconoce y se tría. Las alertas que no son reales ni accionables, y los eventos que no son incidentes, terminan en Done.
• Tercera columna, el incidente. Se declara, se comprueba su severidad y se mitiga. SEV-1 y SEV-2 añaden un responsable de comunicación a la derecha.
• El bucle. "Service restored?" te devuelve a la mitigación hasta que la respuesta sea sí.
• Columna derecha, el cierre. Resuelve, escribe el postmortem sin culpas y cierra cuando las acciones estén registradas.
• Las notas contienen los criterios de declaración y los niveles de severidad, para que nadie tenga que abrir otro documento.

El postmortem cierra el ciclo

El capítulo Postmortem Culture del libro de SRE enumera desencadenantes habituales, como una caída o degradación visible para los usuarios por encima de un umbral y la pérdida de datos de cualquier tipo. Un postmortem es sin culpas cuando busca las causas contribuyentes en los sistemas y los procesos sin culpar a las personas; de lo contrario, la gente deja de comunicar los problemas. Dibuja el postmortem en el diagrama como un documento con responsable y fecha límite, y no marques el incidente como cerrado hasta que sus acciones estén registradas.

Los incidentes de seguridad necesitan más que este diagrama: conservación de pruebas, pasos legales y regulatorios y, a menudo, un equipo aparte. NIST SP 800-61 Rev. 3, publicado en abril de 2025, es la referencia habitual. Conecta una rama de seguridad con ese proceso en lugar de improvisar una.

Consejos para dibujar diagramas de flujo que se usan bajo presión

• Un inicio, finales claros. Cada camino debe terminar en algún sitio, aunque sea "Done".
• Decisiones como preguntas de sí o no, con las dos salidas etiquetadas, y Sí y No saliendo siempre por los mismos lados.
• Haz explícitos los bucles. "Prueba la siguiente mitigación" es un bucle, no una nota al pie.
• Quince formas o menos. Los detalles van en runbooks enlazados desde los pasos.
• Muestra dónde cambia la responsabilidad. Para una versión con carriles por rol, parte de la plantilla de diagrama de flujo interfuncional.
• Tenlo donde mira la guardia. Enlaza o inserta el diagrama en vivo en el runbook en lugar de pegar una captura de pantalla.

Si tu proceso implica a muchos equipos y traspasos formales, un diagrama BPMN puede modelarlo con más precisión; para la guardia, un diagrama de flujo es más fácil de seguir.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Del pack Diagrama de flujo, añade un Inicio / Fin para el comienzo y para cada final, un Proceso para cada paso y una Decisión para cada pregunta.
3. Añade un Documento para el postmortem.
4. Conecta las formas. La forma Decisión marca Y en su esquina derecha y N en su esquina inferior, así que dibuja Sí hacia la derecha y No hacia abajo, etiqueta ambas salidas y lleva la salida "no restablecido" de vuelta a la mitigación.
5. Añade nodos Nota del pack Básico con tus criterios de declaración y tus niveles de severidad.

El ejemplo usa 15 nodos de diagrama, dentro del plan Free. La página del creador de diagramas de flujo muestra las demás formas y el diseño con carriles.

Preguntas frecuentes

¿Quién debe ser responsable del diagrama de flujo de respuesta a incidentes? El equipo que gestiona la rotación de guardias. Revísalo después de cada incidente en el que alguien no supo qué hacer a continuación.

¿Toda alerta debe ser un incidente? No. La mayoría de las alertas deben tratarse como trabajo normal. Declara cuando se cumplan tus criterios, y declara pronto si tienes dudas.

¿Necesito un comandante del incidente para incidentes pequeños? Alguien tiene que mantener la visión de conjunto. En un incidente pequeño, la persona de guardia ejerce de comandante, y decirlo en voz alta evita que dos personas arreglen lo mismo de formas distintas.

¿Cuándo debe escribirse el postmortem? Pronto, mientras los detalles están frescos. Fija una fecha límite que tu equipo pueda cumplir, ponla en el diagrama y haz seguimiento de las acciones.

¿Debe el diagrama de flujo incluir los incidentes de seguridad? Añade una rama que los derive a tu proceso de incidentes de seguridad. Ese proceso tiene pasos distintos, como la conservación de pruebas y la revisión legal.

Empieza gratis — un puesto, sin tarjeta de crédito.