1. Presentación del módulo: cuando suena el teléfono

Descripción

Al terminar esta lección vas a poder explicar por qué un sistema que solo tú sabes atender no está en producción, sino en tu cabeza; vas a conocer las cuatro piezas del kit de operaciones que este módulo construye —el runbook, la guardia, la conducción del incidente y la memoria que sobrevive—; y vas a tener el mapa completo de las ocho lecciones que cierran la guía. También vas a conocer a las personas de Terra Market con nombre propio, porque a partir de aquí el objeto de estudio deja de ser un nodo y pasa a ser un equipo.

Esto importa por una razón que se entiende mejor con una pregunta que con un argumento: si mañana no estás, ¿quién atiende order-sync? No "quién tiene acceso" —eso es fácil— sino quién sabe qué hacer cuando el ERP devuelve 503 a las tres de la mañana, quién decide si eso despierta a alguien o espera, quién le avisa al almacén, y quién se asegura de que la semana siguiente el sistema haya aprendido algo. Si la respuesta honesta a esas cuatro preguntas eres tú, y solo tú, entonces los siete módulos anteriores construyeron una máquina espléndida con un único punto de falla, y ese punto de falla toma vacaciones, se enferma y a veces cambia de trabajo.

Conexión con el módulo: esta lección no configura nada. Es el planteamiento del problema y el mapa. Aquí ves el escenario que cierra la guía —las tres de la mañana, order-sync caído, y quien recibe la alerta no eres tú—, entiendes por qué todo lo que construiste hasta ahora es necesario pero no suficiente, y recibes el esquema de las cuatro piezas que las lecciones 2 a 7 van a construir una por una. La lección 2 arranca por la primera y la más básica: qué es un runbook y por qué tu cabeza no puede serlo. Y una frontera desde ya, porque este módulo cambió de tema respecto de lo que su nombre podría sugerirte: aquí no se habla de Git, ni de entornos dev→staging→prod, ni de permisos de proyecto, ni de respaldar la instancia, ni de mudarse de Cloud a self-hosted. Todo eso existe, es importante, y vive en otras dos guías que te voy a señalar con nombre y apellido más abajo. Lo que se opera aquí es lo humano: quién responde, con qué guion, y cómo el conocimiento sobrevive a que esa persona se vaya.

El turno de noche del hospital

Piensa en un hospital cualquiera a las tres de la mañana.

Durante el día, ese hospital tiene decenas de personas. Cada paciente fue atendido por alguien que lo conoce: sabe por qué llegó, qué se le dio, qué le sentó mal, qué se decidió esperar. Toda esa información existe, y existe con mucho detalle, pero existe dentro de una cabeza.

A las once de la noche esa cabeza se va a su casa. Y a las tres de la mañana, cuando el paciente de la cama 14 se pone mal, quien va a atenderlo es una persona que no lo conoce, que lleva cuatro horas despierta, que tiene otros treinta pacientes a su cargo y que nunca habló con quien lo atendió en la mañana.

¿Qué hace que ese sistema funcione? Porque funciona, todos los días, en todos los hospitales del mundo.

No funciona porque la persona de guardia sea brillante. Funciona por tres cosas muy poco glamorosas: el expediente está escrito y dice qué hacer si pasa X; hay un turno organizado con nombre, teléfono y a quién llamar si la cosa se complica; y hay un traspaso —una conversación de quince minutos al cambio de turno donde se dice "ojo con el de la 14, la presión le viene bajando desde las seis".

Fíjate en algo: nada de eso es medicina. Son tres piezas de organización que permiten que el conocimiento salte de una cabeza a otra sin perderse en el camino. Un hospital donde cada médico se llevara su expediente en la memoria sería un hospital que solo funciona de nueve a seis, y ni siquiera eso, porque también hay que ir al baño.

Terra Market está exactamente en esa situación. Tiene un sistema que funciona, tiene manejo de errores, tiene observabilidad, tiene credenciales endurecidas. Lo que no tiene es expediente, turno ni traspaso. Todo eso vive en tu cabeza, y tu cabeza es —hasta hoy— el único punto del sistema sin respaldo.

Este módulo escribe el expediente, arma el turno y ensaya el traspaso.

Ejemplo trabajado: la misma madrugada, con y sin kit de operaciones

Vamos a mirar una noche concreta dos veces. Misma falla, mismo sistema, misma persona respondiendo. Lo único que cambia es qué había escrito de antemano.

La situación. Es martes 14 de julio. A las 02:51, la API del erp empieza a devolver 503. No está caída del todo, pero rechaza la mayoría de las peticiones. El sistema hace lo que aprendió en el Módulo 2: los reintentos se agotan, los pedidos se apartan en dead_letter, y a las 02:58 el error-handler clasifica el patrón como incidente y manda una alerta a #ops-alerts.

La alerta está bien escrita. Dice esto:

🔴 INCIDENTE · order-sync · el ERP no responde

23 ejecuciones fallidas en los últimos 7 minutos.
Todas en el nodo "Create order in ERP" con 503.
Los pedidos se están guardando en dead_letter: no se está perdiendo nada.

Primer fallo: 02:51 · Último: 02:58
→ https://n8n.terramarket.internal/workflow/order-sync/executions/91442

Hasta aquí, todo lo que construiste funcionó. El teléfono suena.

Pero no suena en tu buró. Suena en el de Daniela, que entró al equipo hace dos meses, que es buena desarrolladora, que nunca ha tocado n8n en serio y que hoy le toca la guardia porque el equipo decidió repartirla.

Versión A — sin kit de operaciones.

Daniela despierta a las 02:59. Lee la alerta. Entiende perfectamente las palabras y no entiende ninguna de las decisiones que implican.

• "¿"El ERP no responde" es grave?" No lo sabe. No sabe si el almacén está trabajando ahora.
• "Dice que no se está perdiendo nada. ¿Le creo?" No sabe qué es dead_letter ni cómo verificarlo.
• "¿Tengo que arreglar algo o esto se arregla solo?" No sabe si el ERP es de Terra Market o de un proveedor.
• "¿A quién le aviso?" Son las tres de la mañana. Cualquier persona a la que le escriba, la va a despertar.

Hace lo que haría cualquiera: abre la computadora, entra a n8n, mira ejecuciones en rojo que no sabe interpretar, busca en Slack "ERP 503" y encuentra una conversación de hace cuatro meses sin conclusión. A las 03:40 decide, razonablemente, que no puede hacer nada útil y se vuelve a dormir con una sensación desagradable.

A las 07:10 llega Gerardo, jefe de almacén, y encuentra 40 pedidos menos de los que esperaba. Escribe a #ops-daily. A las 08:15 tú abres Slack, ves la alerta de la madrugada, entiendes en noventa segundos lo que pasó, verificas que el ERP ya está bien, reprocesas los pedidos apartados y a las 08:35 todo está normal.

El daño no fue el ERP. El daño fue: cuatro horas de retraso en el almacén, una persona que perdió una noche de sueño para nada, y —lo peor— Daniela ahora sabe que estar de guardia es angustiante e inútil. La próxima vez que le toque, va a mirar el teléfono, va a pensar "esto es como la otra vez" y va a volver a dormirse. La guardia acaba de morir en su primera semana.

Versión B — con el kit de operaciones de este módulo.

Daniela despierta a las 02:59. Lee la alerta. La alerta trae una línea más al final:

Runbook: RUNBOOK-01 · El ERP no responde

Abre el runbook. La primera sección no le explica qué es el ERP: le dice qué hacer.

VERIFICACIÓN RÁPIDA (2 minutos)
¿Se está perdiendo algo? Corre esto:

  SELECT count(*) FROM dead_letter
  WHERE created_at > now() - interval '1 hour' AND status = 'pending';

· Si el número crece y la alerta dice "se están guardando en dead_letter",
  nada se pierde. Respira: esto NO es una emergencia.
· Si el número NO crece y siguen llegando fallos, sí lo es. Ve a ESCALAR.

Corre la consulta. Salen 23, y treinta segundos después salen 25. Nada se está perdiendo. La sección siguiente le dice lo que necesita saber para decidir si se levanta:

SI EL ERP NO RESPONDE
· El ERP es de un proveedor externo. No hay nada que arreglar de nuestro lado.
· El almacén empaca de 07:00 a 16:00. Antes de las 06:00 hay margen.
· ANTES DE LAS 06:00 → registra en el hilo del incidente y vuelve a dormir.
  Deja la revisión para las 06:30.
· DESPUÉS DE LAS 06:00 → avisa a Gerardo (almacén) por Slack y sigue el
  procedimiento de reproceso.

Son las 03:00. Daniela escribe tres líneas en el hilo de #ops-alerts —hora, qué verificó, qué decidió— y se vuelve a dormir. Total: once minutos despierta.

A las 06:30 su alarma suena. El ERP volvió a responder a las 03:47. Sigue el procedimiento de reproceso del runbook, que son cuatro pasos con la consulta escrita, y a las 06:52 los 31 pedidos apartados están en el ERP. Avisa a Gerardo que a las 07:00 va a tener sus pedidos completos y agrega una línea al hilo.

Gerardo llega y no se entera de que hubo un incidente. Tú te enteras a las 08:15, leyendo el hilo, y lo único que haces es agendar la retrospectiva del viernes.

Qué esperar. Compara las dos noches línea por línea:

	Sin kit	Con kit
Tiempo despierta de Daniela	~41 min, sin resultado	~11 min, con decisión tomada
¿Supo si se estaba perdiendo algo?	No	Sí, en 2 minutos
Hora en que se recuperaron los pedidos	08:35	06:52
Impacto en el almacén	4 horas de retraso	Ninguno
¿Te tuvieron que despertar a ti?	No, pero tampoco sirvió de nada	No, y no hizo falta
Efecto sobre la persona de guardia	Aprendió que la guardia es inútil	Aprendió que la guardia es manejable

La última fila es la que de verdad importa y es la más fácil de pasar por alto. Un incidente no solo tiene costo técnico: tiene costo de confianza. Cada vez que alguien es despertado y no puede hacer nada, la guardia se degrada un poco. Después de cuatro noches así, nadie contesta el teléfono, y ahí ya no tienes un problema de operación: tienes un problema que no se arregla con más alertas.

Y fíjate en lo que no cambió entre las dos versiones: ni un solo nodo, ni una sola credencial, ni una línea de código. El sistema técnico era idéntico. Lo que cambió fue una página de texto escrita antes, con la cabeza fresca, por alguien que sí sabía las respuestas.

Eso es el kit de operaciones. Y es la parte más barata de construir de toda la guía.

Las personas de Terra Market

Hasta ahora Terra Market fue sistemas y workflows. A partir de este módulo es gente, porque las decisiones que vamos a tomar dependen de quién hace qué. Este es el reparto, y lo vas a ver en las ocho lecciones.

El equipo de tecnología son seis personas, y el número importa: seis es suficiente para repartir una guardia y demasiado poco para tener a alguien dedicado a operar. Es el tamaño más común y el más incómodo.

Persona	Rol	Qué sabe de n8n
Tú	Automatización	Todo. Eres el único que lo sabe todo, y ese es el problema
Marco	Líder de tecnología	Lo básico. Decide prioridades y habla con dirección
Sofía	Infraestructura y bases de datos	Sabe Postgres a fondo; de n8n, lo justo
Daniela	Desarrollo backend, entró hace dos meses	Casi nada. Aprende rápido
Iván	Desarrollo de storefront	Conoce los webhooks que él mismo dispara
Renata	Datos y reportes	Consulta las tablas de ops, no toca workflows

Y hay tres personas fuera de tecnología que aparecen cada vez que algo se rompe, porque son quienes sufren la consecuencia:

• Gerardo, jefe de almacén. Su equipo empaca de 07:00 a 16:00. Si order-sync falla de madrugada, él es quien lo nota.
• Lucía, coordinadora de atención a clientes. Si shipment-notify manda correos duplicados o equivocados, su equipo recibe los reclamos.
• Andrea, dirección de operaciones. Es quien pregunta "¿qué pasó?" y quien necesita una respuesta en lenguaje de negocio, no en lenguaje de nodos.

Un recordatorio que ya conoces del Módulo 2 pero que aquí pesa más: Terra Market es una empresa inventada. Los nombres, los roles y el tamaño del equipo son hipótesis razonables para practicar. Si operas un sistema real, tu reparto va a ser otro —quizá seas un equipo de dos, quizá de veinte— y lo que se transfiere no son los nombres sino las preguntas: quién responde, quién decide, quién comunica, y quién se entera de la consecuencia.

Lo que ya tienes y lo que todavía falta

Vale la pena que veas el inventario completo de lo que los siete módulos anteriores te dejaron, porque este módulo solo tiene sentido encima de todo eso.

Módulo	Lo que te dejó
1	El criterio de producción: la matriz de criticidad × reversibilidad, la auditoría de los 18 workflows y un inventario con dueños
2	Las cinco capas de defensa: reintento, rama de error, fallo deliberado, error workflow global, notificación
3	Depuración: leer una ejecución, repetirla, datos fijados, patrones de fallo
4	Observabilidad: logging estructurado, rastro de auditoría, métricas, health checks, SLA
5	Credenciales: mínimo privilegio, rotación y tope de gasto del token de IA
6	Rendimiento: medir, procesar por lotes, memoria, reducir llamadas, concurrencia
7	Costo de la IA en producción: tope de gasto, medición por ejecución, riesgo de MCP

Léelo de corrido y date cuenta de algo: todo eso es máquina. Cada línea de esa tabla es algo que el sistema hace solo, o algo que tú configuraste y que queda puesto. Ninguna de esas siete líneas contiene la palabra "persona".

Y sin embargo, en la madrugada de Daniela, las siete estaban funcionando. El manejo de errores apartó los pedidos. La observabilidad detectó el patrón. La notificación llegó con el enlace correcto y con el contexto correcto. El sistema hizo todo bien y aun así el resultado fue malo, porque la última milla de la operación no es técnica.

Esa última milla tiene cuatro piezas.

Las cuatro piezas del kit de operaciones

Piénsalo como lo que necesita una casa para que alguien más pueda cuidarla mientras tú viajas. No basta con dejar la llave.

┌──────────────────────────────────────────────────────────────┐
│  PIEZA 4 · La memoria                        (lecciones 6-7) │
│  Lo que el equipo aprendió sigue aquí en seis meses          │
│  ┌────────────────────────────────────────────────────────┐  │
│  │  PIEZA 3 · La conducción              (lección 5)       │  │
│  │  Cuando pasa algo grande, hay un orden y hay roles      │  │
│  │  ┌──────────────────────────────────────────────────┐   │  │
│  │  │  PIEZA 2 · La guardia            (lección 4)      │   │  │
│  │  │  Alguien responde, y se sabe quién y hasta dónde  │   │  │
│  │  │  ┌────────────────────────────────────────────┐   │   │  │
│  │  │  │  PIEZA 1 · El runbook     (lecciones 2-3)   │   │   │  │
│  │  │  │  Quien responde sabe qué hacer              │   │   │  │
│  │  │  └────────────────────────────────────────────┘   │   │  │
│  │  └──────────────────────────────────────────────────┘   │  │
│  └────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────┘

El orden no es decorativo: cada pieza es inútil sin la anterior. Una guardia sin runbooks es un calendario de gente angustiada. Un protocolo de incidentes sin guardia es un documento que nadie activa porque nadie estaba mirando. Y una retrospectiva sin conducción del incidente es una reunión donde nadie se acuerda del orden de los hechos.

Pieza 1 — El runbook (lecciones 2 y 3). Una página que dice qué hacer ante un síntoma concreto. No explica cómo funciona el sistema: dice cuál es el siguiente paso. Es la pieza más barata y la que más devuelve, porque convierte "solo tú puedes atender esto" en "cualquiera del equipo puede atender esto". La lección 2 define qué es y en qué se diferencia de la documentación; la lección 3 es la lección técnica del módulo y es donde escribes tres runbooks completos de Terra Market.

Pieza 2 — La guardia (lección 4). Un acuerdo explícito sobre quién responde, cuándo, hasta dónde y a cambio de qué. La parte más importante no es el calendario: es la decisión previa de qué merece despertar a alguien y qué espera a mañana. Esa decisión se toma con la cabeza fresca, en una reunión de treinta minutos, no a las 02:59 con la lámpara prendida. Aquí también retomamos la fatiga de alertas del Módulo 2, pero desde el otro lado: no cómo se agrega un mensaje, sino qué le pasa a una persona a la que despiertas cuatro veces por nada.

Pieza 3 — La conducción del incidente (lección 5). Cuando lo que pasa es grande, hay un orden que no es obvio y que casi todos los equipos descubren por las malas: detectar, comunicar, contener, resolver, verificar. La parte contraintuitiva es que contener va antes que entender. Primero se detiene la sangre y después se averigua por qué salía. Y hay un reparto de roles que evita el error más caro de todos: que la persona que está arreglando sea también la que responde preguntas.

Pieza 4 — La memoria (lecciones 6 y 7). Dos mitades. La retrospectiva sin culpables (lección 6) hace que el incidente produzca un cambio en vez de un susto; y no es un gesto de amabilidad, es un método, por una razón muy práctica que vamos a desmenuzar. El traspaso y la documentación viva (lección 7) hacen que lo aprendido siga sirviendo cuando la persona que lo aprendió ya no esté. Con una advertencia que es el corazón de esa lección: la documentación que nadie mantiene es peor que ninguna, porque miente, y alguien va a actuar según ella a las tres de la mañana.

Y encima de las cuatro va la lección 8: el proyecto final, donde armas el kit completo de Terra Market y lo validas con un simulacro. Porque un kit de operaciones que nadie probó es exactamente igual de confiable que un error workflow que nunca se disparó, y ese argumento ya lo conoces del Módulo 2.

Lo que este módulo no cubre, y dónde está

Esto merece una sección propia y un poco de honestidad sobre el nombre de la carpeta.

Este módulo se llamaba originalmente "Ciclo de vida, entornos y Cloud vs self-hosted", y su plan era enseñar Git para workflows, la promoción de dev a producción, los permisos por proyecto, los respaldos y la migración entre Cloud y self-hosted. Todo eso se escribió —muy a fondo— en otras dos guías del ecosistema, y repetirlo aquí te habría dado una versión peor de lo que ya existe completo en otro lado. Así que el módulo se reorientó al hueco real: la operación humana, que es la única parte de "operar en producción" que ninguna otra guía cubre.

Si viniste buscando alguna de estas cosas, esto es lo que tienes que abrir:

Lo que buscas	Dónde está de verdad
Versionar workflows, revisar cambios, historial	n8n-git-and-environments-guide
Entornos dev → staging → producción y cómo promover entre ellos	n8n-git-and-environments-guide
Permisos, proyectos compartidos y quién puede editar qué	n8n-git-and-environments-guide
Respaldar y restaurar la instancia y su base de datos	n8n-self-hosting-and-operations-guide
Actualizar la versión de n8n sin romper nada	n8n-self-hosting-and-operations-guide
Mudarse de n8n Cloud a self-hosted (o al revés)	n8n-self-hosting-and-operations-guide
Idempotencia, contratos entre workflows, compensación	n8n-workflow-contracts-and-idempotency-guide

Ninguna de esas siete filas aparece en las ocho lecciones de este módulo. Si en algún momento sientes que falta, no falta: está escrito, con más detalle del que cabría aquí, en la guía que le corresponde.

Y hay una segunda cosa que este módulo no hace, y que conviene decir temprano para que no la busques en el producto: n8n no tiene funcionalidades de gestión de incidentes ni de guardias. No hay una pantalla de "quién está de guardia", ni un botón de "declarar incidente", ni una plantilla de retrospectiva. No la busques. Lo que sí vamos a hacer, en la lección 4, es construir con nodos que existen un workflow pequeño que anuncia el turno de guardia cada semana, que es lo único de este módulo que se parece a automatizar algo. El resto son documentos, acuerdos y ensayos. Es un módulo de práctica profesional, no de configuración.

El mapa de este módulo

Lección	Qué resuelve
2	Qué es un runbook, en qué se diferencia de la documentación, y por qué el conocimiento tácito es el riesgo que nadie mide
3	Cómo se escribe uno que sirva a las tres de la mañana: anatomía por síntoma, con tres runbooks completos de Terra Market
4	La rotación de guardia con seis personas, el criterio de qué despierta a alguien, y la fatiga de alertas como falla de la guardia
5	El orden de un incidente —detectar, comunicar, contener, resolver, verificar— y los dos roles que no deben ser la misma persona
6	La retrospectiva sin culpables: por qué es método y no amabilidad, y cómo se escribe una que produzca cambios reales
7	Traspaso y documentación viva: qué se documenta, qué no, y la prueba de fuego de que otra persona pueda sin preguntarte
8	Proyecto final: el kit completo de Terra Market, validado con un simulacro, y el cierre de la guía

Fíjate en el orden y en su lógica. Primero el guion (2 y 3), porque sin él nada de lo demás sirve. Después quién lo ejecuta (4). Después qué pasa cuando el guion no alcanza (5), que es la definición práctica de un incidente. Después cómo se aprende (6) y cómo lo aprendido sobrevive (7). Y al final la integración (8).

Hay una simetría con el Módulo 2 que quiero que notes, porque explica la forma de toda la guía. Allá construiste cinco capas de defensa automáticas: cinco cosas que el sistema hace solo. Aquí construyes cuatro piezas de defensa humanas: cuatro cosas que hace un equipo. Un sistema de producción serio necesita las dos mitades. Con solo la primera, tienes lo de la versión A: todo funcionó y el resultado fue malo. Con solo la segunda, tienes gente heroica apagando incendios que no debieron empezar.

Errores comunes

Creer que la documentación técnica sustituye al runbook (conceptual). Qué pasa: el equipo tiene una página muy completa que explica la arquitectura de order-sync —qué nodos tiene, qué sistemas toca, cómo se autentica— y se asume que con eso alguien más puede operarlo. Llega el incidente y esa página no ayuda, porque responde "cómo funciona" cuando la pregunta era "qué hago ahora". Por qué pasa: escribir documentación técnica es satisfactorio y se parece a un entregable; escribir un guion de emergencia se siente redundante mientras nada falla. Cómo detectarlo: toma tu mejor página de documentación, ponte en el lugar de alguien recién llegado a las tres de la mañana y busca en ella la frase "haz esto". Si no la encuentras, no es un runbook. Cómo corregirlo: no reemplaces la documentación, agrégale un guion aparte. Las dos cosas conviven y sirven a momentos distintos, y la lección 2 desarrolla exactamente esa distinción.

Repartir la guardia sin repartir primero la capacidad (práctico). Qué pasa: el equipo decide, con muy buena intención, que la guardia se turna entre las seis personas. La primera noche que le toca a alguien que no sabe operar n8n, esa persona pasa una hora sin poder hacer nada y termina llamándote de todos modos. En dos meses la rotación se deshace sola y vuelve a ser tuya, ahora con la sensación añadida de que "ya se intentó y no funcionó". Por qué pasa: la guardia parece un problema de calendario, y calendarizar es fácil. La parte difícil es que la persona que entra al turno pueda hacer algo. Cómo detectarlo: pregúntale a la persona menos experta del equipo qué haría con la alerta de la madrugada de Daniela. Si su respuesta empieza con "pues te llamaría a ti", la rotación todavía no existe. Cómo corregirlo: el orden correcto es runbooks primero, guardia después. Es la razón por la que la lección 4 viene después de la 3 y no al revés.

Tratar este módulo como "lo blando" y saltárselo (conceptual). Qué pasa: después de siete módulos de nodos, tablas y consultas, un módulo de documentos y acuerdos se siente como el relleno del final. Se lee en diagonal, no se hace el proyecto, y el resultado es un sistema técnicamente impecable que sigue dependiendo de una sola persona. Por qué pasa: lo humano no tiene captura de pantalla. No hay una casilla que activar ni un nodo que conectar, así que no se siente como progreso. Cómo detectarlo: es la pregunta del principio y no tiene truco. Si mañana no estás dos semanas, ¿el sistema sigue operando? Si la respuesta es "más o menos", el módulo no está hecho. Cómo corregirlo: mide este módulo por su prueba, no por su lectura. La lección 8 lo aterriza en un simulacro donde otra persona resuelve un incidente sin preguntarte nada, y ese simulacro pasa o no pasa. No hay término medio.

Ejercicios

Ejercicio 1 — El inventario de tu cabeza. Sin abrir ninguna herramienta, escribe una lista de cosas que sabes sobre tus automatizaciones y que no están escritas en ningún lado. Apunta a diez. Después marca cada una con una letra: (C) si su ausencia costaría tiempo, (D) si costaría dinero o datos, (N) si nadie más podría averiguarla sin ti.

Ver solución

No hay respuesta correcta porque la lista es tuya, pero sí hay un patrón que casi siempre aparece. Esta es la lista de Terra Market, como referencia de qué tipo de cosas cuentan:

Lo que solo está en tu cabeza	Marca
El token del erp se rota cada 90 días; el último cambio fue el 2026-05-14	D, N
andes-express devuelve 200 con un cuerpo de error cuando la guía ya existe	D, N
Los pedidos de STORE-114 traen el total en centavos y hay una conversión especial	D, N
El nodo Normalize prices de inventory-update falla con precios vacíos, y eso es esperado	C
Si order-sync se despublica, storefront reintenta el webhook durante 6 horas	D, N
El contacto real del proveedor del ERP no es soporte, es el ingeniero de integraciones	C, N
El pico de las 21:00 satura el ERP; subir la concurrencia empeora las cosas	D, N
dead-letter-watch corre cada hora, así que un problema puede tardar 59 minutos en verse	C
La credencial de Slack del error-handler la creó una cuenta personal	D, N
Reprocesar dead_letter sin marcar status duplica pedidos	D, N

Dos observaciones sobre esa lista, que son el punto del ejercicio:

Casi todo lleva N. Ese es el hallazgo incómodo. No es que la información sea difícil de encontrar: es que no existe en ningún lugar del que se pueda extraer. Si desapareces, no se recupera investigando; se recupera equivocándose.

Las que llevan D son las urgentes. La última de la lista es la que más asusta: alguien con buena intención, siguiendo el instinto correcto de "voy a reprocesar los pedidos apartados", puede duplicar cobros. Ese es exactamente el tipo de cosa que un runbook con su sección de "lo que nunca hay que hacer" evita.

Por qué funciona: este ejercicio convierte un riesgo abstracto —"dependemos mucho de ti"— en una lista concreta de entre diez y treinta líneas. Y una lista se puede atacar. La lección 2 te va a dar el criterio para decidir cuáles de esas líneas merecen un runbook, cuáles merecen una nota en el inventario y cuáles no merecen nada.

Ejercicio 2 — Reparte la madrugada. Vuelve a la noche del 14 de julio, versión B. Daniela resolvió sola porque el runbook alcanzó. Ahora cambia un dato: la consulta de verificación devuelve cero, y los fallos siguen llegando. Es decir, los pedidos no se están guardando. Responde: (a) ¿qué cambia en la decisión de Daniela?; (b) ¿a quién debe escribirle y por qué a esa persona y no a otra?; (c) ¿qué información necesita tener a la mano para que ese mensaje sirva?

Ver solución

(a) Cambia todo, y ese es el diseño. La verificación rápida existe para responder una sola pregunta —¿se está perdiendo algo?— porque esa respuesta divide el mundo en dos. Con los pedidos a salvo, el incidente puede esperar cuatro horas. Sin ellos, cada minuto que pasa son pedidos pagados que desaparecen, y eso sí justifica despertar a más gente. Daniela pasa de "registro y me duermo" a "escalo ahora".

(b) A ti, porque eres el dueño declarado de order-sync en el inventario, y si no contestas en quince minutos, a Marco, el líder de tecnología, que es quien puede decidir cosas que Daniela no puede decidir sola —por ejemplo, despublicar el workflow para que storefront acumule los webhooks en vez de perderlos. Lo que no hace es escribirle a Gerardo: son las tres de la mañana, el almacén no abre hasta las 07:00, y despertar a alguien que no puede hacer nada con la información es precisamente lo que erosiona la confianza en el sistema de alertas. A Gerardo se le avisa a las 06:30.

(c) Cuatro datos, y los cuatro deberían estar en el runbook para que no tenga que buscarlos: desde cuándo está pasando (primer fallo: 02:51), cuántos casos van, qué verificó (la consulta y su resultado), y qué NO intentó todavía. Ese último es el que casi siempre falta y el que más tiempo ahorra a quien recibe la llamada: saber que nadie ha tocado nada evita que la primera pregunta de la persona que despierta sea "¿qué le hicieron?".

Por qué funciona: el ejercicio muestra que un runbook no es una lista de pasos lineal, sino un árbol con una pregunta en la raíz. La verificación rápida no está ahí para arreglar nada: está para decidir en qué rama del árbol estás. La lección 3 construye ese árbol para tres síntomas distintos.

Ejercicio 3 — Ubica la pieza. Para cada una de estas cinco situaciones de Terra Market, di cuál de las cuatro piezas del kit la resuelve y por qué las otras no serían la respuesta principal:

(a) Una alerta llega a las 04:00 y nadie la ve hasta las 09:30 porque no había nadie asignado. (b) Dos personas del equipo tocan el mismo workflow durante un incidente y se pisan los cambios. (c) El mismo fallo del carrier ocurre por tercera vez en dos meses y cada vez se resuelve desde cero. (d) La persona que respondió el incidente resolvió bien, pero Andrea se enteró seis horas después por un cliente. (e) Renata entra a operaciones el mes que viene y no hay forma de ponerla al día sin veinte horas tuyas.

Ver solución

(a) Pieza 2, la guardia. No es un problema de guion ni de memoria: es que no había nadie con el turno asignado. Un runbook impecable no sirve si nadie está mirando el canal. Ojo con el matiz: el problema tampoco se arregla mandando la alerta a más gente. Una alerta que llega a seis personas sin dueño asignado es una alerta de la que nadie se hace cargo.

(b) Pieza 3, la conducción. Es el síntoma clásico de un incidente sin roles: dos personas actuando en paralelo sobre el mismo sistema sin coordinación. La solución no es un documento sino un acuerdo de quién conduce, y de que quien conduce es la única persona que ejecuta cambios mientras dura el incidente.

(c) Pieza 4, la memoria —su mitad de retrospectiva. Que un fallo se repita idéntico tres veces no es mala suerte: es que las dos primeras veces no produjeron ningún cambio. Un runbook ayudaría a resolverlo más rápido, pero seguiría ocurriendo. La retrospectiva es lo que pregunta por qué es posible que ocurra.

(d) Pieza 3, la conducción —su parte de comunicación. Es el error de tener una sola persona haciendo dos trabajos: arreglar y comunicar. Cuando alguien está resolviendo, comunicar se siente como una interrupción, y se pospone hasta que ya no hace falta. Por eso los dos roles se separan de antemano.

(e) Pieza 4, la memoria —su mitad de traspaso. Y fíjate en la cifra del enunciado: veinte horas tuyas es la medida exacta del problema. Un traspaso bien hecho no elimina el acompañamiento, pero lo baja de veinte horas a dos, y la diferencia es la documentación viva más el simulacro.

Por qué funciona: las cinco situaciones parecen problemas distintos y en realidad son el mismo problema visto desde cuatro alturas. Nadie sabe qué hacer (pieza 1), nadie sabe que le toca (pieza 2), nadie sabe en qué orden (pieza 3), nadie recuerda lo que ya se aprendió (pieza 4). Cuando algo se rompa en tu sistema real y no sepas por dónde empezar, esas cuatro preguntas son un buen triaje.

Resumen y siguiente paso

En esta lección viste el problema que cierra la guía, con la imagen del hospital a las tres de la mañana: lo que hace que un turno de noche funcione no es la brillantez de quien está de guardia, sino el expediente, el turno organizado y el traspaso. Comparaste la madrugada del 14 de julio dos veces —mismo fallo del ERP, misma persona respondiendo— y viste que la diferencia entre once minutos con una decisión tomada y cuarenta y un minutos de angustia inútil no fue ni un nodo ni una credencial, sino una página escrita antes. Conociste al equipo de Terra Market con nombre propio: seis personas en tecnología, con Daniela recién llegada, y tres personas fuera de tecnología que son quienes sufren la consecuencia de cada fallo. Recibiste el esquema de las cuatro piezas del kit —el runbook, la guardia, la conducción del incidente y la memoria— con la advertencia de que cada una es inútil sin la anterior. Y quedó declarada, con nombre y apellido, la frontera con las dos guías hermanas: Git y entornos son n8n-git-and-environments-guide; respaldos, actualizaciones y migración son n8n-self-hosting-and-operations-guide.

Antes de avanzar deberías poder: explicar en una frase por qué un sistema que solo tú sabes atender no está en producción; nombrar las cuatro piezas del kit y decir qué resuelve cada una; y responder honestamente la pregunta del inventario de tu cabeza.

Lo que no viste todavía es la pieza uno, que es donde empieza todo lo demás. Porque casi todos los equipos creen que ya la tienen —"sí, sí, tenemos documentación"— y casi ninguno la tiene. La lección 2 desmonta esa confusión: qué es exactamente un runbook, en qué se diferencia de la documentación técnica que quizá ya escribiste, por qué el conocimiento tácito es el único riesgo operativo que nadie mide aunque sea el más caro, y cómo se hace el examen honesto que ordena todo el módulo: si mañana no estás, ¿qué se rompe primero?

Recursos

• Handle errors gracefully — n8n Docs — la base técnica sobre la que se apoya todo este módulo: lo que el sistema resuelve solo antes de que una persona tenga que intervenir.
• Error Trigger — n8n Docs — la fuente de los campos que llenan la alerta que despierta a quien está de guardia, incluido execution.url.
• Configure workflow settings — n8n Docs — los ajustes por workflow, donde vive el campo Error Workflow que conecta cada automatización con la cadena de aviso.
• Postgres node — n8n Docs — el nodo con el que se consultan dead_letter, error_log e inbox, que son las tres tablas que aparecen en las verificaciones rápidas de los runbooks de la lección 3.
• Schedule Trigger — n8n Docs — el disparador del único workflow que se construye en este módulo, el anuncio semanal del turno de guardia de la lección 4.