8. Proyecto final: el kit de operaciones

Descripción

Al terminar esta lección vas a tener armado y probado el kit de operaciones completo de Terra Market: los runbooks de los tres síntomas más frecuentes, la rotación de guardia con su criterio de escalamiento, la plantilla de retrospectiva, y el inventario actualizado con dueños. Y lo vas a haber validado con la única prueba que cuenta: un simulacro donde otra persona ejecuta un runbook sin tu ayuda. Es el proyecto de este módulo y el cierre de toda la guía.

Esto importa porque un kit de operaciones sin probar es exactamente igual de confiable que un error workflow que nunca se disparó, y ese argumento ya lo conoces de sobra. Todo lo que construiste en las siete lecciones anteriores —los runbooks, la política de guardia, la conducción, las retrospectivas, el traspaso— existe para un solo fin: que la operación sobreviva sin ti. Y ese fin no se declara, se demuestra, con otra persona resolviendo un incidente que tú provocaste, mientras te muerdes la lengua. Esta lección es esa demostración, ensamblada pieza por pieza en entregables concretos y verificables.

Conexión con el módulo: esta lección integra las cuatro piezas del kit que las lecciones 2 a 7 construyeron por separado. No introduce ideas nuevas: reúne, ensambla y prueba lo que ya sabes. Y como es la última lección de la última guía —o de esta guía, al menos— cierra dos cosas: el módulo, con el kit entregado y validado; y la guía entera, con un recorrido por los ocho módulos y un mapa de hacia dónde seguir. La frontera del módulo sigue en pie hasta el final: aquí no hay Git, ni entornos, ni respaldos, ni migración —eso vive en las guías hermanas que vas a ver al cierre—; aquí está la operación humana, ensamblada.

Qué vas a entregar

El kit tiene cuatro entregables, uno por cada pieza. Piénsalo como la carpeta que le dejas a quien tome la operación cuando tú no estés:

KIT DE OPERACIONES · Terra Market
│
├── 1. RUNBOOKS (pieza: el guion)
│      RUNBOOK-01 · el ERP no responde
│      RUNBOOK-02 · llegaron pedidos duplicados
│      RUNBOOK-03 · la cola de dead_letter creció
│
├── 2. GUARDIA (pieza: quién responde)
│      Rotación semanal + política de niveles + criterio de escalamiento
│      + el anunciador semanal (workflow)
│
├── 3. RETROSPECTIVA (pieza: cómo se aprende)
│      La plantilla de las cinco secciones, lista para usar
│
└── 4. INVENTARIO VIVO (pieza: la memoria)
       Los 18 workflows con criticidad, dueño, runbook y notas vivas

Y por encima de los cuatro, la validación: el simulacro, que no es un documento sino una prueba que se ejecuta y se pasa. Un kit con los cuatro entregables escritos pero sin simulacro no está terminado, igual que un manejo de errores configurado pero no probado no está terminado.

Vamos por partes. Para cada entregable vas a ver qué debe contener y cómo verificar que quedó bien. Los runbooks ya los escribiste en la lección 3, así que aquí el trabajo es reunirlos y verificar que cumplen; las otras tres piezas se ensamblan aquí.

Fase 1 — Los tres runbooks

El primer entregable son los tres runbooks completos de la lección 3: el ERP no responde (RUNBOOK-01), llegaron pedidos duplicados (RUNBOOK-02), y la cola de dead_letter creció (RUNBOOK-03). No los repetimos aquí —ya los tienes escritos— pero sí los sometemos a una lista de verificación, porque un runbook que existe no es lo mismo que uno que sirve.

La lista de verificación de un runbook. Pasa cada uno de los tres por estas casillas:

□ El título es un SÍNTOMA observable, no una causa.
  (✔ "el ERP no responde" · ✘ "problema de autenticación")
□ Empieza con una VERIFICACIÓN RÁPIDA que responde "¿se pierde algo?"
  o la pregunta que orienta la urgencia de ese síntoma.
□ El diagnóstico está en UNA frase, con la tranquilización de si es
  esperado.
□ Cada paso de acción es una ACCIÓN, no una decisión, y tiene su
  RESULTADO ESPERADO.
□ Dice CUÁNDO ESCALAR y A QUIÉN, con nombre, y hay una ruta directa
  a escalar desde la verificación cuando el caso es grave.
□ Tiene una sección de "LO QUE NUNCA HAY QUE HACER" con los atajos
  que destruyen datos.
□ Tiene FECHA de última revisión y DUEÑO en el encabezado.
□ Alguien que NO seas tú lo leyó y entendió sin preguntarte.

La última casilla es la más importante y la que casi nadie marca: un runbook no está terminado hasta que otra persona lo leyó y lo entendió sin ti. Las siete casillas anteriores las puedes marcar tú solo, engañándote; la octava requiere a otra persona, y es la que de verdad prueba que el runbook está escrito para quien lo va a usar y no para quien lo escribió.

Cómo verificar que quedó bien. Toma el RUNBOOK-01 y dáselo a la persona menos experta del equipo —Daniela— sin ningún contexto. Pídele que te diga, leyéndolo, qué haría paso por paso si recibiera la alerta. Cada vez que te pregunte algo que el runbook debería responder, tienes un hueco: lo arreglas. Cuando Daniela pueda narrar la resolución completa solo con el runbook en la mano, ese runbook pasó.

Fase 2 — La guardia con su criterio de escalamiento

El segundo entregable ensambla lo de la lección 4 en un documento operable. Tiene tres partes:

Parte A — La rotación. Quién está en la rueda, en qué orden, y con qué tramo. Para Terra Market:

ROTACIÓN DE GUARDIA · Terra Market
Turno: semanal (lunes a lunes). Rueda de 5:
  Tú → Marco → Sofía → Iván → Renata → (vuelve a Tú)

FUERA DE LA RUEDA (por ahora):
  · Daniela: en acompañamiento. Entra cuando complete su simulacro
    de los 3 runbooks sin ayuda.

El turno de cada semana se anuncia automáticamente los lunes 09:00
en #ops-daily (workflow "on-call-announcer").

Parte B — La política de niveles. La decisión, tomada de antemano, de qué despierta a alguien. Es la tabla de la lección 4, con la regla de oro visible:

POLÍTICA DE ALERTAS · qué despierta y qué no

DESPIERTA AHORA (Slack #ops-alerts + mención + teléfono)
  · Se está PERDIENDO algo (la verificación rápida dio "no crece").
  · El daño CRECE sin contenerse (correos irreversibles saliendo).
  · Un trigger crítico muerto (no entran pedidos).
  Objetivo: 0 o 1 por noche.

ESPERA A MAÑANA (resumen en #ops-daily)
  · dead_letter creciendo PERO con todo a salvo.
  · Fallos visibles pero contenidos (duplicados que no se enviaron).
  Objetivo: menos de 10 al día.

SOLO REGISTRO (error_log, ningún canal humano)
  · Reintentos exitosos, rechazos de negocio deliberados.

REGLA DE ORO: solo se pospone un aviso si nada se pierde Y el daño
está contenido. Si dudas, despierta.

Parte C — El criterio de escalamiento. A quién se acude cuando el turno no alcanza. Esta es la pieza que hace que alguien poco experto pueda tomar la guardia sin miedo:

ESCALAMIENTO · cuando el turno no alcanza

NIVEL 1 · quien tiene el turno esta semana.
  Resuelve con los runbooks. Si el runbook alcanza, no escala.

NIVEL 2 · el RESPALDO (el siguiente en la rueda).
  Se escala si: el runbook no cubre el síntoma, o la acción del
  runbook no funcionó, o se necesita una segunda persona para
  comunicar mientras alguien resuelve.

NIVEL 3 · automatización (Mike) para lo técnico / Marco para
  decisiones de negocio (ej: despublicar order-sync).
  Se escala si: se está perdiendo algo y no se logra contener, o
  el incidente supera lo que el respaldo puede resolver.

SIEMPRE es válido escalar. Escalar no es fallar: es lo que hace
que la guardia la pueda tomar alguien que no lo sabe todo.

Cómo verificar que quedó bien. Dos comprobaciones. Primera: mide una semana real. Cuenta cuántas alertas llegaron a #ops-alerts y qué fracción requirió acción. Si el volumen supera "0 o 1 por noche" o la accionabilidad cae por debajo del ~80%, la política no está calibrada: revisa qué se está colando y reclasifícalo (no subas el umbral). Segunda: verifica que el anunciador semanal publica en #ops-daily cada lunes. Es el único workflow del kit y es fácil de olvidar.

Fase 3 — La plantilla de retrospectiva

El tercer entregable es la plantilla de la lección 6, lista para copiar cuando ocurra el próximo incidente. No es un documento que se llena una vez: es un formato que se reusa. Este es, para que quede en el kit:

PLANTILLA DE RETROSPECTIVA · copiar por cada incidente

RETROSPECTIVA · [título por síntoma]
Incidente: [fecha] · Retro: [fecha, pocos días después]
Participaron: [quién estuvo al frente + quiénes analizan]

① QUÉ PASÓ (3 líneas, lenguaje llano)

② LÍNEA DE TIEMPO (del registro escrito DURANTE el incidente,
   con horas reales)

③ IMPACTO (en lenguaje de negocio, MEDIDO: cuántos pedidos,
   cuánto tiempo, cuántos clientes)

④ CAUSAS CONTRIBUYENTES (qué lo hizo posible — la cadena de
   "¿por qué?" hasta llegar a causas del SISTEMA, nunca a una
   persona. Si aparece un nombre propio, sigue preguntando.)

⑤ ACCIONES (cada una con DUEÑO con nombre y FECHA verificable.
   Sin dueño no la hace nadie; sin fecha no la hace nunca.)

RECORDATORIO AL ABRIR LA REUNIÓN (leer en voz alta):
"No buscamos culpables, buscamos causas. Cuenta los detalles
incómodos: son los que arreglan el sistema. La pregunta es qué lo
hizo posible, no quién lo hizo."

Fíjate en el recordatorio del final: no es decorativo. Leer en voz alta que no se buscan culpables, al abrir cada retrospectiva, es lo que crea las condiciones para que la información salga. Sin ese encuadre explícito, la reunión deriva sola hacia la cacería, porque buscar culpables es el estado por defecto de cualquier grupo ante un error.

Cómo verificar que quedó bien. La plantilla se prueba usándola. Toma un incidente real reciente de Terra Market —el reproceso de Daniela de la lección 6, por ejemplo— y llénala entera. Si al terminar tienes causas que son todas del sistema (ningún nombre propio en la sección ④) y acciones que todas tienen dueño y fecha, la plantilla funciona. Si te cuesta llenar la línea de tiempo, es señal de que en el próximo incidente hay que escribir mejor el registro durante —la plantilla depende de esa materia prima—.

Fase 4 — El inventario vivo

El cuarto entregable es el inventario de la lección 7: los 18 workflows con criticidad, dueño, runbook y notas vivas, con fecha de última revisión y un responsable de mantenerlo. Ya viste su forma; aquí el trabajo es asegurarte de que esté completo y vivo, no solo empezado.

Un inventario completo cubre los 18, no solo los 3 protagonistas. Los tres críticos llevan sus runbooks; los de apoyo (error-handler, dead-letter-watch) llevan sus notas especiales (como "no se prueba a mano"); y los otros trece llevan al menos criticidad y dueño, aunque sea en una línea cada uno. Un inventario que solo cubre los tres que te sabes de memoria deja fuera justo los quince que nadie recuerda cuando fallan.

Cómo verificar que quedó bien. Tres comprobaciones. Primera: ¿están los 18? Cuenta las filas. Segunda: ¿tiene cada fila un dueño con nombre? Un workflow sin dueño es un workflow que nadie va a atender. Tercera —la prueba de que está vivo—: toma tres afirmaciones concretas del inventario (un nombre de credencial, una fecha de rotación, un contacto) y verifícalas contra el sistema real ahora. Si alguna miente, el inventario ya empezó a pudrirse y hay que arreglarla y agendar la revisión trimestral.

La validación: el simulacro

Aquí está la parte que convierte cuatro documentos en un kit de operaciones de verdad. Los cuatro entregables pueden estar impecables sobre el papel y aun así no funcionar, por la misma razón que un error workflow puede estar bien configurado y no dispararse el día que hace falta. La única forma de saberlo es ejecutar un simulacro: otra persona resuelve un incidente que tú provocas, con el kit, sin tu ayuda.

Este es el simulacro completo del kit de Terra Market, paso por paso:

Paso 1 — Elige el incidente y la persona. El incidente: el ERP que no responde (RUNBOOK-01), por ser el más frecuente y crítico. La persona: Daniela, que está en acompañamiento y cuya entrada a la rueda de guardia depende justamente de pasar este simulacro.

Paso 2 — Provoca el síntoma sin tocar producción. Monta un order-sync-test desechable que apunte a un endpoint de prueba devolviendo 503, de modo que Daniela vea la alerta real, el nodo fallando y el código, sin que ningún pedido real corra peligro. El síntoma tiene que ser indistinguible del real; una descripción en papel no prueba nada.

Paso 3 — Daniela resuelve sola, y tú te callas. Le das el kit —los runbooks, el inventario, la política de escalamiento— y la dejas trabajar. Observas y tomas notas de dónde se atora. No intervienes. Cada vez que dude y no encuentre la respuesta en el kit, anotas un hueco. Le recuerdas antes de empezar: esto prueba el kit, no a ella; atorarse está bien y es información útil.

Paso 4 — Cada tropiezo es un arreglo del kit. ¿No encontró la verificación rápida? Estaba enterrada en el runbook: la subes. ¿No supo a quién escalar de madrugada? El escalamiento no lo decía claro: lo aclaras. ¿No sabía que reprocesar sin verificar duplica? Faltaba en el "nunca": lo agregas. El simulacro produce una lista de arreglos concretos al kit.

Paso 5 — Repite con un incidente que no haya practicado. Cuando Daniela resuelva el del ERP sin ayuda, prueba con otro que no haya visto —los pedidos duplicados, por ejemplo—. El traspaso está terminado cuando resuelve un incidente nuevo solo con el kit, sin preguntarte nada. Ese momento es la definición operativa de que el kit funciona, y es el criterio para meter a Daniela a la rueda de guardia.

Qué esperar. El primer simulacro casi siempre descubre varios huecos —es normal y es el punto—. El segundo, menos. En algún momento, Daniela resuelve un incidente que no había visto usando solo el kit, y ahí sabes dos cosas a la vez: que el kit está completo, y que tienes una persona más que puede tomar la guardia. Las dos son el objetivo del módulo entero, demostradas de una sola vez.

Y una consecuencia que vale la pena nombrar: el día que Daniela pasa el simulacro, respondiste por fin la pregunta que abrió la guía en la lección 1 del Módulo 2 —¿qué pasa si mañana no estás?—. La respuesta dejó de ser "me llaman a mí" y pasó a ser "hay un kit, y hay al menos una persona más que sabe usarlo". Eso es lo que significa que una operación esté en producción y no en tu cabeza.

La lista de entrega del kit

El kit está terminado cuando puedes marcar estas casillas. Es la lista de publicación de todo el módulo:

□ RUNBOOK-01, 02, 03 escritos, cada uno pasa las 8 casillas de la
  lista de verificación (incluida "alguien más lo entendió").
□ Rotación de guardia definida, con Daniela FUERA hasta pasar el
  simulacro.
□ Política de niveles escrita, con la regla de oro visible.
□ Criterio de escalamiento con nombres y los tres niveles.
□ Anunciador semanal publicando en #ops-daily cada lunes.
□ Plantilla de retrospectiva lista, con el recordatorio de "sin
  culpables" al abrir.
□ Inventario vivo con los 18 workflows, cada uno con dueño, fecha
  de revisión y responsable de mantenerlo.
□ SIMULACRO PASADO: otra persona resolvió un incidente nuevo con el
  kit, sin ayuda.

Fíjate en que la última casilla es la que vale por todas las demás. Puedes tener las siete primeras marcadas y, si la octava no lo está, no sabes si el kit funciona —solo sabes que se ve bien—. Y puedes tener un kit modesto que marque la octava, y ese sí es un kit de operaciones real. El simulacro no es el último paso del proyecto: es su único juez.

Errores comunes

Entregar el kit sin el simulacro (conceptual). Qué pasa: se escriben los cuatro entregables con esmero, se guardan en una carpeta, y se da el kit por terminado. Nunca se probó con una persona real resolviendo un incidente, así que los huecos —el runbook con un paso ambiguo, el escalamiento que no cubre la madrugada— siguen ahí, invisibles, esperando el primer incidente real para aparecer en el peor momento. Por qué pasa: escribir los documentos se siente como el trabajo, y el simulacro se siente como un extra opcional "si hay tiempo". Cómo detectarlo: si nadie que no seas tú ha resuelto un incidente con el kit, el kit no está probado. Cómo corregirlo: trata el simulacro como parte de la definición de terminado, no como un lujo. Un kit sin simulacro es un manejo de errores sin provocar fallos: infraestructura que se supone que funciona y que nadie verificó.

Confundir "cuatro documentos" con "operación sostenible" (conceptual). Qué pasa: se produce el kit, se archiva, y se asume que la operación ya sobrevive sin la persona clave. Pero un kit es una foto de un momento; sin mantenerlo, en seis meses los runbooks mienten, el inventario está desactualizado y la rotación se deshizo. El kit existe pero ya no describe la realidad. Por qué pasa: el kit es un artefacto tangible, y es fácil confundir tener el artefacto con tener la capacidad que representa. Cómo detectarlo: mira la fecha de última revisión de tu inventario y tus runbooks. Si es de hace más de un trimestre, el kit se está pudriendo. Cómo corregirlo: ata el mantenimiento a eventos que ya ocurren —cada retrospectiva actualiza los runbooks y el inventario que tocó— y agenda una revisión trimestral completa. El kit no es un entregable que se termina; es un organismo que se mantiene vivo o muere.

Meter a alguien a la guardia antes de que pase el simulacro (práctico). Qué pasa: por prisa de repartir la carga, se pone a la persona nueva en la rueda de guardia apenas se escribe el kit, sin haber probado que puede usarlo. Le toca un incidente, se atora en un hueco que el simulacro habría encontrado, y termina llamándote —o peor, tomando una decisión mal informada—. Por qué pasa: hay presión por descargar al experto, y meter a alguien a la rueda parece progreso inmediato. Cómo detectarlo: si alguien en tu rotación no ha resuelto un incidente simulado con el kit sin ayuda, no está listo para el turno. Cómo corregirlo: el simulacro es la puerta de entrada a la guardia, no el calendario. Daniela entra a la rueda el día que pasa el simulacro, ni antes ni por otra razón. Es el orden de la lección 4 —capacidad primero, turno después— hecho requisito.

Ejercicios

Ejercicio 1 — Audita un kit incompleto. Un equipo dice tener su kit de operaciones listo. Al revisarlo encuentras esto: tres runbooks bien escritos; una rotación de seis personas incluyendo a la más nueva; una política que avisa de todo fallo a un solo canal; ninguna plantilla de retrospectiva; un inventario de los tres workflows críticos; y ningún simulacro hecho. Identifica los cuatro problemas y ordénalos por gravedad.

Ejercicio 2 — Diseña el criterio de escalamiento de un workflow nuevo. Terra Market lanza refund-process (procesa devoluciones, mueve dinero real, ~40 ejecuciones/día). Escribe su entrada de escalamiento en tres niveles, decidiendo qué justifica subir de nivel, dado que aquí hay dinero de por medio.

ESCALAMIENTO · refund-process (mueve dinero)

NIVEL 1 · quien tiene el turno.
  · Fallo transitorio del procesador de pagos que el reintento resuelve
    → no escala, se resolvió solo.
  · Validación fallida (pedido no existe, fuera de plazo) → no escala,
    es rechazo deliberado, a error_log.

NIVEL 2 · el respaldo + finanzas informada.
  Se escala si: el procesador de pagos falla tras agotar reintentos y
  hay una devolución que no salió. Cada caso importa porque es una
  persona esperando su dinero.

NIVEL 3 · automatización + Marco, AHORA, a cualquier hora.
  Se escala si: el estado es AMBIGUO — no se sabe si el pago salió y solo
  se perdió la confirmación, o si no salió. Esa ambigüedad con dinero de
  por medio no espera a la mañana, aunque sean las 3 a.m.

Ejercicio 3 — Ejecuta un simulacro mental. No tienes a Daniela enfrente, pero puedes hacer el simulacro en tu cabeza, que es un buen detector de huecos. Toma el RUNBOOK-01 (el ERP no responde) y ponte en la piel de alguien que nunca lo usó, a las 3 a.m. Recórrelo línea por línea y anota cada punto donde alguien sin tu contexto se atoraría. Propón el arreglo de cada hueco.

Resumen y siguiente paso

En esta lección ensamblaste el kit de operaciones completo de Terra Market: los tres runbooks pasados por su lista de verificación, la guardia con su rotación, su política de niveles y su criterio de escalamiento en tres niveles, la plantilla de retrospectiva con el recordatorio de "sin culpables", y el inventario vivo con los 18 workflows. Y lo validaste con la única prueba que cuenta: el simulacro, donde otra persona resuelve un incidente que tú provocas, sin tu ayuda, y donde cada tropiezo arregla el kit en vez de reprochar a la persona. Viste que la última casilla de la lista de entrega —el simulacro pasado— vale por todas las demás, porque un kit que se ve bien pero no se probó es exactamente igual de confiable que un error workflow que nunca se disparó. Y el día que Daniela pasa el simulacro, respondiste la pregunta que abrió la guía: qué pasa si mañana no estás. La respuesta ya no es "me llaman a mí".

Resumen y cierre de la guía

Llegaste al final. Vale la pena mirar hacia atrás y ver, de golpe, todo lo que ahora sabes hacer, porque son ocho módulos y es fácil perder de vista el conjunto.

Empezaste sin saber qué convierte a un workflow en "de producción" y ahora operas automatizaciones de las que depende un negocio. Este fue el camino, módulo por módulo, y la capacidad que cada uno te dejó:

Módulo 1 — Qué cambia cuando un workflow pasa a producción. Te dio el criterio: la matriz de criticidad × reversibilidad, la auditoría de preparación, y el inventario con dueños. Aprendiste a mirar un workflow y decir qué tan crítico es y qué pasa si falla. Sin esto, todo lo demás sería esfuerzo repartido a ciegas.

Módulo 2 — Manejo de errores robusto. Te dio las cinco capas de defensa: el reintento que cura solo, la rama que aparta, el fallo que provocas, el error workflow global que recoge, y la notificación que avisa. Aprendiste a diseñar para el fallo, porque en producción el fallo no es una posibilidad sino una agenda.

Módulo 3 — Depuración con el motor de replay. Te dio cómo dejar de adivinar: leer una ejecución, reproducir un fallo pasado, fijar datos, re-ejecutar un solo nodo. Aprendiste a entender qué pasó de verdad, en vez de suponerlo.

Módulo 4 — Observabilidad. Te dio los ojos: logging estructurado, rastro de auditoría, métricas, health checks y SLA. Aprendiste a responder "¿qué pasó con el pedido 4471?" nueve días después, que es la diferencia entre operar y esperar.

Módulo 5 — Seguridad de credenciales y secretos. Te dio las llaves bien guardadas: mínimo privilegio, rotación, y el tope de gasto del token de IA. Aprendiste a que un sistema comprometido no arrastre a los demás.

Módulo 6 — Rendimiento del workflow. Te dio cómo hacer rápido lo lento: medir dónde se va el tiempo, procesar por lotes, cuidar la memoria, reducir llamadas, manejar la concurrencia. Aprendiste a atacar el cuello de botella real, no el imaginado.

Módulo 7 — Costo de la IA en producción y MCP. Te dio el control del gasto: el tope, la medición por ejecución, y el riesgo de exponer y consumir servidores MCP. Aprendiste a que la IA en producción no arruine el presupuesto ni abra un agujero de seguridad.

Módulo 8 — Runbooks, guardias y continuidad. Te dio lo que ninguno de los siete anteriores podía dar: que la operación sobreviva sin ti. El runbook que otra persona ejecuta a las 3 a.m., la guardia que reparte la carga sin quemar a nadie, la conducción del incidente que detiene la sangre antes de entenderla, la retrospectiva que aprende sin culpar, y el traspaso que hace que todo lo aprendido sobreviva a las personas.

Junta los ocho y tienes la frase con la que abrió la guía, ahora defendible en una entrevista: "opero automatizaciones de las que depende un negocio, y puedo irme de vacaciones." Los primeros siete módulos te hicieron capaz de operar; el octavo te hizo prescindible en el buen sentido, que es el único estado en el que un sistema está de verdad en producción.

Hacia dónde seguir

Esta guía tiene fronteras deliberadas —cosas que decidió no cubrir para hacer bien lo suyo—, y las guías hermanas del ecosistema cubren justo esas fronteras. Aquí están, agrupadas no por catálogo sino por el problema que te va a llevar a ellas. Cuando te topes con uno de estos problemas, ya sabes a dónde ir:

Si necesitas versionar workflows y moverlos entre entornos sin romper producción —"quiero un dev y un prod separados", "quiero revisar los cambios antes de que entren", "quién puede editar qué"— eso es n8n-git-and-environments-guide. Es la frontera que este módulo señaló una y otra vez: Git, entornos dev→staging→prod, promoción y permisos.

Si tienes que montar, endurecer o escalar la instancia misma —"cómo instalo n8n en un servidor", "cómo respaldo y restauro", "cómo actualizo la versión sin romper nada", "cómo me mudo de Cloud a self-hosted", "queue mode con Redis y workers"— eso es n8n-self-hosting-and-operations-guide. Esta guía asumió una instancia ya funcionando; aquella la construye y la mantiene.

Si el problema es que el sistema hace cosas incorrectas, no que falle —"un reintento me duplicó un cobro", "cómo diseño una clave de idempotencia", "cómo deshago un efecto que ya ocurrió", "cómo defino un contrato entre dos workflows"— eso es n8n-workflow-contracts-and-idempotency-guide. Fue la frontera más citada de todo este módulo: aquella guía diseña la correctitud del sistema, esta la opera.

Si quieres construir agentes de IA, chatbots, o pipelines de documentos —"cómo monto un agente que use herramientas", "cómo hago un chatbot sobre mis documentos", "cómo funciona un pipeline RAG"— eso vive en las guías de IA del ecosistema (n8n-ai-chatbots-agents-guide, n8n-document-ai-guide, n8n-ai-automation-basics-guide). Este módulo solo controló lo que la IA cuesta y arriesga en producción; construirla es allá.

Si todavía estás aprendiendo a construir workflows —nodos, triggers, expresiones, la lógica básica— esa es la guía de fundamentos (n8n-fundamentals-guide), y las de patrones de diseño (n8n-workflow-design-patterns-guide) y de trabajar con APIs sin código (n8n-apis-without-code-guide). Esta guía asumió que ya sabías construir y te enseñó a operar; si sientes que te faltó base, ahí está.

Y un último pensamiento para cerrar. Operar en serio no es un destino al que se llega, es un oficio que se practica —el del segundo constructor del puente, el que camina sobre él buscando grietas—. El kit que armaste no es un trabajo terminado: es un organismo que vas a mantener vivo, incidente a incidente, retrospectiva a retrospectiva. Cada vez que algo se rompa y aprendas algo, ese aprendizaje va a un runbook o a una nota viva, y el sistema queda un poco mejor preparado para la próxima persona que llegue —que a veces vas a ser tú mismo, ocho meses después, a las tres de la mañana, agradeciéndole a tu yo del pasado que se haya tomado la molestia de escribirlo—.

Gracias por llegar hasta aquí. No está mal para quien empezó preguntándose qué hace "de producción" a un workflow.

Recursos

• Handle errors gracefully — n8n Docs — la base técnica sobre la que se apoyan los runbooks del kit; sus fallos son lo que cada runbook convierte en acción.
• Schedule Trigger — n8n Docs — el disparador del anunciador semanal de guardia, el único workflow del kit.
• Postgres node — n8n Docs — el nodo de las consultas de verificación rápida de los runbooks y de la medición de impacto de las retrospectivas.
• Executions — n8n Docs — la lista de ejecuciones desde donde se provoca y se verifica el simulacro, y de donde salen las horas reales de las líneas de tiempo.
• n8n-git-and-environments-guide · n8n-self-hosting-and-operations-guide · n8n-workflow-contracts-and-idempotency-guide — las tres guías hermanas que cubren las fronteras que esta dejó fuera a propósito: versionado y entornos, montaje y escalado de la instancia, y diseño de la correctitud del sistema.