5. La línea de tiempo de un incidente

Descripción

Al terminar esta lección vas a poder conducir un incidente en vez de sufrirlo. Vas a conocer las cinco fases en las que se ordena la respuesta —detectar, comunicar, contener, resolver, verificar—, vas a entender por qué contener va antes que entender la causa (primero se detiene la sangre, después se averigua por qué salía), vas a saber por qué la persona que arregla y la que habla con el negocio no deben ser la misma, y vas a aprender a escribir el registro del incidente mientras ocurre, no después.

Esto importa porque un incidente sin conducción es un incidente que se alarga, que se comunica mal, y que se resuelve de una forma que a veces empeora las cosas. Cuando algo grande se rompe, la reacción natural de una persona técnica es lanzarse a entender la causa —"¿por qué está pasando esto?"— y ponerse a investigar. Es exactamente el instinto equivocado, y lo es por una razón concreta: mientras investigas la causa, la sangre sigue saliendo. El pedido se sigue perdiendo, el correo duplicado se sigue enviando, la cola sigue creciendo. Un incidente bien conducido invierte ese instinto: primero para el daño, y solo entonces se da el lujo de entenderlo.

Conexión con el módulo: esta es la tercera pieza del kit —la conducción— y viene después del runbook y la guardia por una razón. Un runbook cubre un síntoma conocido: lo abres, sigues los pasos, resuelves. Pero hay situaciones que ningún runbook cubre, porque son nuevas, porque son grandes, o porque varias cosas fallan a la vez. Eso es un incidente en sentido pleno, y no se resuelve leyendo una ficha: se conduce. La lección 4 te dio quién responde; esta te da qué hace esa persona cuando lo que tiene enfrente supera al runbook. Y prepara la lección 6: el registro que escribes durante el incidente es, literalmente, la materia prima de la retrospectiva sin culpables que viene después. Una nota de frontera: aquí no rediseñamos la correctitud del sistema para que el incidente no vuelva a pasar —eso es diseño y vive en n8n-workflow-contracts-and-idempotency-guide—; aquí operamos el incidente que ya está ocurriendo.

La sala de urgencias

Piensa en cómo se atiende a alguien que llega grave a una sala de urgencias. Hay un orden, y el orden es sagrado, porque romperlo cuesta vidas.

Llega una persona con una herida que sangra mucho. ¿Qué es lo primero que hace el equipo médico? No es preguntarle cómo se hizo la herida. No es pedir análisis para saber la causa. No es discutir el mejor tratamiento a largo plazo. Lo primero es detener la hemorragia: presión, torniquete, lo que sea, ahora. Porque una persona que se está desangrando no tiene tiempo para que averigües por qué.

Solo cuando la sangre está contenida —cuando el paciente está estable— el equipo pasa a lo siguiente: entender qué pasó, hacer los análisis, decidir el tratamiento de fondo. El orden es innegociable: estabilizar primero, entender después. Un médico que se pusiera a investigar la causa mientras el paciente se desangra sería un mal médico, por muy brillante que fuera su diagnóstico, porque el paciente se le muere durante el análisis.

Y fíjate en algo más de esa sala. No hay una sola persona haciendo todo. Mientras alguien detiene la hemorragia, otra persona habla con la familia que espera afuera: le explica qué está pasando, la mantiene informada, absorbe su angustia. Esas dos tareas —salvar al paciente y hablar con la familia— no las hace la misma persona, y no por falta de manos: es que son incompatibles. Quien tiene las manos dentro de la herida no puede parar cada dos minutos a explicarle a la familia, y si lo hiciera, el paciente lo pagaría. Son dos trabajos distintos que ocurren en paralelo.

Un incidente técnico es una sala de urgencias. El pedido que se pierde es la sangre. Contener es el torniquete. Y el negocio —Gerardo esperando sus pedidos, Andrea preguntando qué pasa— es la familia en la sala de espera. Todo lo que sigue en esta lección es cómo trasladar el orden de la sala de urgencias a tu operación.

Ejemplo trabajado: el incidente del ERP, conducido y no conducido

Volvamos al incidente del ERP del jueves —el que Daniela atendió— pero subamos su gravedad para que sea un incidente de verdad: esta vez el ERP no solo devuelve 503, sino que empieza a aceptar pedidos y perderlos. Los crea a medias: responde 200, pero el pedido no queda registrado del lado del almacén. Es un fallo feo porque el sistema cree que todo va bien. Vamos a verlo conducido de dos formas.

Versión A — sin conducción (el instinto natural).

Son las 02:51. La alerta llega. La persona de guardia —digamos que esta vez eres tú— se lanza a lo que se siente natural: entender por qué. Abres el ERP, revisas logs, comparas peticiones exitosas con fallidas, formulas una hipótesis, la descartas, formulas otra. Estás absorto, concentrado, haciendo buen trabajo de diagnóstico. Pasan cuarenta minutos.

Mientras tanto, tres cosas malas ocurren en paralelo y no las estás mirando:

• order-sync siguió corriendo todo ese tiempo. Cada pedido que llegó en esos cuarenta minutos recibió su 200 del ERP y se perdió, porque el fallo hace que se pierdan. Cuarenta minutos de pedidos evaporados que creías, mientras diagnosticabas, que estaban entrando bien.
• A las 03:20, Andrea —que madruga— vio la alerta en el canal y escribió "¿qué está pasando?". No le respondiste: estabas concentrado. A las 03:35 volvió a escribir, ya nerviosa. El silencio la asustó más que el problema.
• Cuando por fin entendiste la causa a las 03:31, tuviste que empezar la contención que debiste hacer primero, y para entonces ya se habían perdido pedidos que no se van a recuperar, porque nunca quedaron en dead_letter —el fallo los perdía antes—.

Hiciste un diagnóstico excelente. Y el incidente fue un desastre, porque el diagnóstico era la tercera cosa que había que hacer, no la primera.

Versión B — conducida (el orden de la sala de urgencias).

Son las 02:51. La alerta llega. Antes de preguntarte por qué, ejecutas el orden:

• 02:52 — Detectar y evaluar. Lees la alerta. Corres la verificación rápida del runbook. Descubres lo peor: dead_letter no crece, y sin embargo llegan pedidos. Es decir, se están perdiendo. La regla de oro se rompió: esto no está contenido.

• 02:54 — Comunicar que arrancas. Escribes UNA línea en el hilo: "02:54 — order-sync está perdiendo pedidos (el ERP los acepta pero no los guarda). Estoy conteniendo. Actualizo en 15 min. —tú". No explicas la causa (no la sabes). Solo dices: hay un incidente, lo estoy atendiendo, cuándo vuelvo a hablar.

• 02:56 — Contener, sin entender todavía. ¿Cómo detienes la sangre sin saber la causa? Despublicas order-sync. Sí, eso significa que dejan de entrar pedidos. Pero storefront reintenta los webhooks durante seis horas (lo sabías, estaba en el inventario), así que los pedidos no se pierden: se acumulan en storefront esperando. Cambiaste "pedidos perdidos para siempre" por "pedidos en pausa, recuperables". Eso es contener: no arreglaste nada, detuviste el daño.

• 03:10 — Ahora sí, resolver. Con la sangre contenida y sin reloj encima, investigas la causa con calma. Descubres que el ERP tuvo un despliegue fallido de su proveedor. No hay nada que arreglar de tu lado: hay que esperar a que el proveedor lo revierta. Escribes a su contacto de emergencia (estaba en el inventario).

• 03:15 — Comunicar el estado. "03:15 — Contenido. order-sync está en pausa, los pedidos se acumulan en storefront y no se pierde ninguno. Causa: despliegue fallido del ERP (su proveedor). Esperando que lo reviertan. Nada que hacer del lado de almacén hasta las 07:00." Andrea lee eso y se tranquiliza: sabe qué pasa, sabe que está contenido, sabe cuándo importa.

• 04:40 — Verificar y cerrar. El proveedor revirtió a las 04:20. Republicas order-sync. storefront empieza a reenviar los webhooks acumulados. Verificas con la consulta que los pedidos entran y quedan registrados de verdad esta vez. A las 04:40 todo está normal, con cero pedidos perdidos.

Qué esperar. Mira la diferencia, que no está en el conocimiento técnico —en las dos versiones diagnosticaste igual de bien— sino en el orden:

	Versión A (sin conducir)	Versión B (conducida)
Primera acción	Entender la causa	Contener el daño
Pedidos perdidos para siempre	40 min de pedidos	0
Andrea (el negocio)	Asustada por el silencio	Informada y tranquila
Tiempo hasta contener	~40 min	~5 min
Calidad del diagnóstico	Excelente	Excelente (pero hecho sin prisa)

La segunda fila es la que duele: cuarenta minutos de pedidos perdidos, que en la versión B fueron cero, y la única diferencia fue qué hiciste primero. Contener antes de entender no es una preferencia de estilo: es lo que decide cuántos pedidos existen mañana.

Las cinco fases, en orden

Ahora el orden completo, fase por fase. Piénsalo como el protocolo que se ejecuta, no como una lista que se consulta.

Fase 1 — Detectar. Saber que hay un incidente y de qué tamaño. Casi siempre empieza con la alerta, pero la detección no termina ahí: incluye la verificación rápida del runbook que responde la pregunta que gobierna todo —¿se está perdiendo algo? ¿el daño crece o está contenido?—. Esta fase es corta pero decide todo lo demás, porque distingue entre "un runbook alcanza" (síntoma conocido, contenido) y "esto es un incidente" (nuevo, grande, o no contenido). No confundas detectar con entender: en esta fase sabes qué pasa (se pierden pedidos), no por qué.

Fase 2 — Comunicar (que arrancas). Antes de meter las manos, una línea: hay un incidente, lo estoy atendiendo, cuándo vuelvo a informar. Esta comunicación inicial cuesta quince segundos y evita el peor patrón de los incidentes: el silencio que asusta al negocio más que el propio problema. No es la comunicación completa —esa viene después, con el estado— es solo el "estoy en esto". Fíjate en que va antes de contener: quince segundos de avisar no retrasan la contención de forma significativa, y en cambio evitan que Andrea escriba tres veces mientras tú tienes las manos ocupadas.

Fase 3 — Contener. Detener el daño, sin necesidad de entender la causa todavía. Esta es la fase que la intuición pone en el lugar equivocado, y es el corazón de la lección. Contener es cambiar un daño que crece por uno que está detenido, aunque la solución sea tosca: despublicar un workflow, pausar un trigger, desviar el tráfico a una cola. No es elegante y no es la solución final. Es el torniquete. La pregunta de esta fase no es "¿cómo lo arreglo?" sino "¿cómo hago que deje de empeorar mientras lo arreglo?".

Fase 4 — Resolver. Ahora sí, entender la causa y arreglarla de fondo, con la sangre ya contenida y sin reloj encima. Esta es la fase donde tu instinto técnico —el diagnóstico— por fin tiene su lugar, y lo hace mejor porque lo hace sin la presión de estar perdiendo algo cada segundo. A veces resolver es esperar (el proveedor revierte su despliegue); a veces es un arreglo tuyo (renovar el token). Lo importante es que resolver ocurre después de contener, no en su lugar.

Fase 5 — Verificar. Confirmar, con evidencia, que el sistema volvió a la normalidad de verdad. No "parece que ya está": la consulta que muestra que los pedidos entran y quedan registrados, el reproceso de lo acumulado, el conteo que baja a cero. Esta fase existe porque el mayor error del final de un incidente es declararlo resuelto cuando solo estaba pausado, y descubrir a la mañana siguiente que la mitad seguía rota. Verificar es la diferencia entre "creo que ya" y "confirmé que sí".

Y algo que envuelve a las cinco fases y no es una fase aparte: el registro, que se escribe mientras todo esto ocurre. Lo desarrollamos más abajo, pero tenlo presente desde ya: cada línea de la versión B llevaba una hora y un actor. Eso no era decoración; era el registro construyéndose en tiempo real.

DETECTAR ──► COMUNICAR ──► CONTENER ──► RESOLVER ──► VERIFICAR
   │           (arranco)    (torniquete)  (con calma)   (con evidencia)
   │                                                          │
   └──────────── el REGISTRO se escribe durante TODO ─────────┘
        (cada línea: hora + qué se hizo o se supo)

Los dos roles que no deben ser la misma persona

Esta es la segunda idea grande de la lección, y viene directo de la sala de urgencias: quien arregla el incidente y quien habla con el negocio no deben ser la misma persona.

Los dos roles tienen nombres que vale la pena usar:

Quien conduce (o quien resuelve). Tiene las manos dentro del problema. Su atención está en contener y resolver, y esa atención es un recurso escaso y frágil: cada interrupción para explicar algo le cuesta minutos de recuperar el hilo. Necesita concentración protegida.

Quien comunica. Habla con el negocio —Andrea, Gerardo, Lucía—, absorbe sus preguntas, traduce el estado técnico a lenguaje de negocio, y le da a quien conduce el escudo que necesita para trabajar. No toca el sistema; su herramienta es el hilo del incidente y la conversación.

Por qué no pueden ser la misma persona, aunque haya manos de sobra para intentarlo:

Porque las dos tareas compiten por la misma atención. Explicar bien un incidente a alguien nervioso requiere concentración; contener y resolver también. Una persona haciendo las dos hace las dos mal: contiene distraída y comunica a medias. La versión A del ejemplo fue exactamente eso: absorto en el diagnóstico, no comunicó, y Andrea se asustó.

Porque el negocio no debe interrumpir a quien arregla. Si Andrea le escribe directo a quien tiene las manos en el sistema, cada mensaje suyo es una interrupción en el peor momento. Con un rol de comunicación, Andrea tiene a alguien con quien hablar que no es quien está resolviendo, y así sus preguntas legítimas no le cuestan tiempo a la solución. El rol de comunicación es, en parte, un parachoques.

Porque la comunicación es un trabajo real, no un descuido. Tratar de comunicar como algo que se hace "en los ratos libres" del arreglo garantiza que se haga tarde y mal, porque durante un incidente no hay ratos libres. Darle a una persona el trabajo explícito de comunicar es lo que asegura que ocurra.

Un matiz honesto para equipos pequeños: en un equipo de seis, a las tres de la mañana, puede que solo haya una persona despierta. ¿Qué haces entonces? Dos cosas. Primera: si el incidente es grande, escalas para conseguir la segunda persona —despertar a alguien para que comunique es un uso legítimo del escalamiento—. Segunda: si de verdad estás solo, la comunicación se vuelve asíncrona y espaciada —una línea en el hilo cada quince minutos— en vez de una conversación en vivo, y eso es aceptable como mal menor. Lo que no es aceptable es que la comunicación desaparezca porque estabas ocupado. Aunque estés solo, el "actualizo en 15 min" del ejemplo protege al negocio sin robarte casi tiempo.

El registro que se escribe mientras ocurre

El registro del incidente es la pieza que casi todos posponen —"lo escribo después, cuando esto se calme"— y esa es exactamente la forma de que salga mal. Un registro escrito después es un registro reconstruido de memoria, y la memoria de un incidente es pésima: comprimes el tiempo, olvidas el orden, y racionalizas las decisiones ("obviamente contuve primero") aunque no haya sido así. El registro tiene que escribirse mientras ocurre, por tres razones.

Porque la memoria miente sobre los tiempos. Después de un incidente, todos recuerdan que fue más rápido de lo que fue, y en el orden que tiene sentido, no en el que pasó. Solo un registro con horas reales, escrito en el momento, conserva la verdad de cuánto tardó cada fase. Y esa verdad es lo que la retrospectiva de la lección 6 necesita: sin ella, la retrospectiva discute sobre recuerdos, no sobre hechos.

Porque es la comunicación y el registro a la vez. Fíjate en que en la versión B, las líneas que escribiste en el hilo para comunicar son el registro. No son dos trabajos: comunicar en un hilo con hora deja, como subproducto, la línea de tiempo del incidente. Esa es la forma más barata de registrar: hacer que tu comunicación quede escrita y fechada.

Porque quita carga mental en el peor momento. Escribir "02:56 — despubliqué order-sync" te libera de recordarlo. Durante un incidente tu cabeza está saturada; el registro es memoria externa que te permite concentrarte en el problema sin miedo a olvidar qué ya hiciste. Es lo mismo que un cirujano cantando en voz alta cada paso: no es ceremonia, es no perder la cuenta.

¿Qué se anota? No todo —un registro que intenta capturar cada clic se vuelve inescribible en pleno incidente—. Se anotan los hitos: cuándo se detectó, cuándo se comunicó, cada acción de contención, cuándo se entendió la causa, cuándo se resolvió, cuándo se verificó. Cada línea con dos cosas: la hora y qué se hizo o se supo. Nada más. La regla práctica: si alguien que llega tarde al incidente leyera solo el registro, ¿entendería qué pasó y en qué orden? Si sí, el registro está completo.

Un ejemplo del formato mínimo, que es el mismo del ejemplo trabajado:

INCIDENTE · order-sync pierde pedidos · 2026-07-16
Conduce: tú · Comunica: (solo, asíncrono)

02:51  Alerta: order-sync fallando en Create order in ERP
02:52  Verificación: dead_letter NO crece y llegan pedidos → se PIERDEN
02:54  Comunico arranque en el hilo. No sé la causa aún.
02:56  CONTENGO: despublico order-sync. storefront reintenta 6h → a salvo
03:10  Diagnóstico: despliegue fallido del ERP (proveedor). Nada de mi lado
03:15  Comunico estado: contenido, causa, no se pierde nada
04:20  El proveedor revirtió su despliegue
04:30  Republico order-sync. storefront reenvía lo acumulado
04:40  VERIFICO: pedidos entran y quedan registrados. Cero perdidos. Cierro

Diez líneas. Cualquiera que las lea entiende el incidente completo, y son la materia prima exacta de la retrospectiva. Ese registro no costó tiempo extra: nueve de sus diez líneas eran comunicación que de todos modos tenías que hacer.

Errores comunes

Lanzarse a entender la causa antes de contener (conceptual). Qué pasa: llega el incidente y el instinto técnico toma el control —"¿por qué está pasando?"— y se va directo a investigar. Mientras se diagnostica, el daño sigue: pedidos que se pierden, correos que se envían, cola que crece. Cuando por fin se entiende la causa, ya se acumuló un daño que la contención habría evitado. Por qué pasa: entender es lo que una persona técnica sabe y disfruta hacer, y contener con una solución tosca (despublicar algo) se siente como rendirse o como "hacer algo feo". Cómo detectarlo: en tu último incidente, ¿cuánto tardaste en detener el daño versus en empezar a diagnosticar? Si diagnosticaste primero, invertiste el orden. Cómo corregirlo: entrena el reflejo de preguntar "¿cómo hago que deje de empeorar?" antes de "¿por qué pasa?". Contener con algo tosco y reversible casi siempre es posible sin saber la causa, y comprar tiempo no es rendirse: es lo que hace que el diagnóstico posterior sea tranquilo en vez de desesperado.

Callar mientras se arregla (práctico). Qué pasa: quien resuelve se concentra tanto en el problema que deja de comunicar. El negocio, sin información, se angustia, escribe una y otra vez, y a veces empieza a tomar decisiones propias mal informadas ("les voy a decir a los clientes que hubo un hackeo"). El silencio hace más daño que el incidente. Por qué pasa: durante un incidente la comunicación se siente como una distracción del trabajo real, y se pospone hasta "cuando tenga algo que decir". Cómo detectarlo: si en tu último incidente el negocio se enteró del estado por preguntar en vez de por un aviso tuyo, comunicaste tarde. Cómo corregirlo: comunica que arrancas antes de meter las manos, aunque no tengas la causa, y da un ritmo ("actualizo en 15 min") aunque el update sea "sigo en ello, contenido, sin novedad". Y si puedes, separa el rol: que otra persona comunique para que tú no tengas que elegir entre arreglar y hablar.

Declarar resuelto sin verificar (práctico). Qué pasa: se aplica el arreglo, el síntoma visible desaparece, y se cierra el incidente con un "ya está". A la mañana siguiente resulta que solo se había pausado una parte, o que lo acumulado nunca se reprocesó, y el incidente resucita, ahora con menos energía del equipo para atenderlo. Por qué pasa: al final de un incidente todos están cansados y con ganas de que termine, y "parece que ya funciona" es una conclusión muy tentadora. Cómo detectarlo: si tu criterio de cierre fue "ya no veo el error" en vez de "corrí la consulta y confirmé que los datos están completos", cerraste sin verificar. Cómo corregirlo: define para cada incidente una verificación con evidencia concreta —un conteo en cero, una consulta que muestra los datos, un reproceso confirmado— y no lo cierres hasta tenerla. La fase de verificar existe precisamente para resistir la tentación de creer que ya, cuando solo casi.

Ejercicios

Ejercicio 1 — Ordena las acciones. Durante un incidente en Terra Market, alguien hizo estas seis cosas, pero en desorden. Reordénalas según las cinco fases y señala cuál fue el error de orden que se cometió:

(1) Escribió en el hilo: "resuelto, el ERP ya responde". (2) Investigó los logs del ERP para entender por qué fallaba. (3) Corrió la consulta de dead_letter y vio que los pedidos se perdían. (4) Despublicó order-sync para frenar la pérdida. (5) Corrió la consulta final y confirmó que los pedidos entran y quedan registrados. (6) Avisó en el hilo que había un incidente y lo estaba atendiendo.

Ver solución

El orden correcto por fases:

• Detectar: (3) corrió la consulta y vio que se perdían pedidos.
• Comunicar (arranque): (6) avisó que había un incidente y lo atendía.
• Contener: (4) despublicó order-sync para frenar la pérdida.
• Resolver: (2) investigó los logs para entender la causa.
• Verificar: (5) corrió la consulta final y confirmó datos completos.

Y sobra una acción fuera de lugar: (1) "resuelto, el ERP ya responde" es un cierre declarado antes de verificar. "El ERP ya responde" no es lo mismo que "los pedidos entran y quedan registrados"; es justo el error de declarar resuelto por el síntoma visible en vez de por evidencia. El cierre correcto es (5), no (1). Si el incidente se cerró con (1), lo más probable es que a la mañana siguiente los pedidos acumulados en storefront nunca se hubieran reprocesado y el problema resucitara.

Por qué funciona: el ejercicio muestra que las acciones de un incidente casi nunca ocurren en el orden correcto por sí solas —el instinto quiere (2) antes que (4), y (1) en vez de (5)—. Tener las cinco fases como plantilla es lo que impone el orden que el instinto no impone. Fíjate en que (2), el diagnóstico, que se siente como "el trabajo de verdad", es la cuarta cosa que se hace, no la primera.

Ejercicio 2 — Diseña la contención. Para cada uno de estos tres incidentes de Terra Market, propón una contención que detenga el daño sin necesidad de conocer ni arreglar la causa. Recuerda: la contención puede ser tosca y reversible; su único trabajo es que el daño deje de crecer.

(a) shipment-notify está mandando correos duplicados en masa por un reenvío del carrier. (b) order-sync crea pedidos duplicados en el ERP porque una guarda de idempotencia está fallando bajo carga. (c) inventory-update está empujando precios en cero a storefront por un dato malo del ERP, y la tienda ya muestra productos gratis.

Ver solución

(a) Contención: despublicar (o pausar) shipment-notify. Detiene el envío de correos de inmediato. Aceptas que mientras esté pausado no salen avisos de envío, pero un aviso retrasado es reparable y un correo duplicado enviado no lo es. Los eventos del carrier se pueden reprocesar después. No necesitaste saber por qué el carrier reenvía: solo cerraste la llave.

(b) Contención: despublicar order-sync. Como storefront reintenta los webhooks seis horas, los pedidos se acumulan a salvo en lugar de duplicarse. Cambiaste "duplicados que alguien tendrá que cancelar uno por uno" por "pedidos en pausa, recuperables". No arreglaste la guarda de idempotencia —eso es diseño, va a la otra guía y a la retrospectiva—; solo detuviste la producción de duplicados.

(c) Contención: pausar inventory-update Y —esto es clave— evaluar si hay que revertir lo ya empujado. Pausar detiene nuevos precios malos, pero aquí el daño ya salió a la tienda: hay productos en cero visibles a clientes que podrían comprarlos. La contención completa incluye o bajar la tienda de esos productos, o forzar un empuje del último inventario bueno conocido. Este caso enseña que a veces contener no es solo "cerrar la llave" sino también "limpiar el charco que ya se hizo", cuando el daño es visible y sigue teniendo efecto.

Por qué funciona: en los tres casos la contención es la misma operación mental —¿cuál es la palanca más rápida y reversible para que el daño deje de crecer?— y en los tres es despublicar o pausar algo, aceptando un costo menor (avisos retrasados, pedidos en pausa) a cambio de detener un daño mayor e irreversible. Fíjate en que ninguna contención requirió entender la causa, y en que el caso (c) añade el matiz de que a veces hay charco que limpiar además de llave que cerrar.

Ejercicio 3 — Reparte los roles. Es un incidente grande en Terra Market a las 15:00 (horario laboral, hay gente despierta). Están disponibles: tú (experta en n8n), Daniela (junior, ya con acompañamiento), Marco (líder), y Andrea (dirección de operaciones) está preguntando qué pasa. Reparte los roles de "quien conduce" y "quien comunica", justifica, y di qué pasaría si los mezclaras.

Ver solución

Un reparto razonable:

• Quien conduce: tú. Eres quien más rápido contiene y resuelve en n8n. Tus manos deben estar en el sistema, con la concentración protegida.
• Quien comunica: Marco. Es el líder, habla el lenguaje de negocio, y es la persona natural para tratar con Andrea. Su trabajo durante el incidente es absorber las preguntas de Andrea, traducir tu estado técnico a lenguaje de negocio, y ser el parachoques que te deja trabajar. No toca el sistema.
• Daniela: observa y apoya a quien conduce. Este es un momento de oro para su acompañamiento —ver un incidente real conducido bien vale más que diez runbooks leídos—. Puede correr consultas de verificación que tú le dictes, sin tomar decisiones, y así aprende el orden sin la presión de la responsabilidad.
• Andrea: es "la familia". No tiene un rol operativo; es a quien se comunica. Su ansiedad es legítima y el trabajo de Marco es gestionarla, no ignorarla.

Qué pasaría si mezclaras los roles —si tú condujeras y comunicaras con Andrea a la vez—: cada mensaje de Andrea te sacaría del problema, contendrías distraída, y probablemente comunicarías tarde y mal, que es exactamente la versión A del ejemplo trabajado. Andrea, sin un interlocutor dedicado, escribiría cada vez más nerviosa, y su ansiedad no gestionada podría llevarla a tomar decisiones de negocio mal informadas. Separar los roles no es burocracia: es lo que permite que tú resuelvas bien y que Andrea esté informada, dos cosas que una sola persona no puede dar a la vez.

Un matiz: en un incidente a las 03:00, este reparto ideal de cuatro personas no existe —quizá solo estés tú—. Ahí es donde el escalamiento de la lección 4 entra: si el incidente es grande, despertar a Marco para que comunique es un uso correcto del escalamiento, no una molestia. Y si de verdad estás sola, comunicas asíncrono y espaciado, que es el mal menor aceptable.

Por qué funciona: el ejercicio muestra que los roles de un incidente no dependen de la jerarquía sino de la tarea —quien mejor contiene conduce, quien mejor habla con el negocio comunica— y que la separación protege dos recursos escasos a la vez: tu concentración y la tranquilidad del negocio. Mezclarlos sacrifica los dos.

Resumen y siguiente paso

En esta lección aprendiste a conducir un incidente en vez de sufrirlo. Con la imagen de la sala de urgencias viste el orden sagrado —estabilizar primero, entender después— y sus dos consecuencias: contener va antes que diagnosticar, y quien salva al paciente no es quien habla con la familia. Comparaste el incidente del ERP conducido y no conducido, y viste que la diferencia entre cuarenta minutos de pedidos perdidos y cero no estuvo en el conocimiento técnico —el diagnóstico fue igual de bueno en los dos— sino en qué se hizo primero. Recorriste las cinco fases en orden —detectar, comunicar, contener, resolver, verificar— con contener en el lugar que la intuición le niega. Entendiste por qué los dos roles no deben ser la misma persona, porque compiten por la misma atención y porque el negocio no debe interrumpir a quien arregla. Y aprendiste a escribir el registro mientras ocurre, con hora y hecho por línea, que sale casi gratis porque es la misma comunicación que ya tenías que hacer, y que es la materia prima de lo que viene.

Antes de avanzar deberías poder: nombrar las cinco fases en orden y justificar por qué contener va antes que resolver; explicar por qué quien conduce y quien comunica no deben ser la misma persona; y escribir un registro de incidente con horas y hechos que otra persona pueda entender.

Tienes el incidente conducido y cerrado, y tienes su registro. Falta lo que convierte un incidente en aprendizaje en vez de en un susto que se olvida: la retrospectiva. La lección 6 es la mitad de la cuarta pieza del kit —la memoria— y trae el argumento más contraintuitivo del módulo. "Sin culpables" no es un gesto de amabilidad: es un método, y tiene una lógica dura detrás. Si buscar culpables tiene costo para quien participó, la gente esconde información —los tiempos reales, las decisiones dudosas, el "yo pensé que…"—, y sin esa información el sistema no puede aprender de verdad. Vas a ver la estructura del documento de retrospectiva, y sobre todo la pregunta que la ordena: ¿qué hizo que esto fuera posible?, no ¿quién lo hizo?.

Recursos

• Executions — n8n Docs — la lista de ejecuciones desde donde se detecta el alcance de un incidente y se reprocesa lo acumulado en la fase de verificar.
• Configure workflow settings — n8n Docs — la referencia de cómo se activa y desactiva un workflow, que es la palanca de contención más usada (despublicar para frenar la sangría).
• Postgres node — n8n Docs — el nodo con el que se corren las consultas que detectan si se pierde algo y las que verifican, con evidencia, que el sistema volvió a la normalidad.
• n8n-workflow-contracts-and-idempotency-guide — la guía hermana donde vive el rediseño de la correctitud (guardas de idempotencia, compensación) que un incidente identifica como causa pero que se arregla después, no en caliente.