4. Guardias sin quemar a nadie

Descripción

Al terminar esta lección vas a poder organizar una rotación de guardia sostenible con un equipo pequeño, vas a saber tomar de antemano —no a las tres de la mañana— la decisión de qué merece despertar a alguien y qué espera al día siguiente, y vas a entender la fatiga de alertas no como una molestia sino como una falla operativa medible que rompe el sistema entero. También vas a construir el único workflow de este módulo: un pequeño anunciador semanal de quién está de guardia, hecho con nodos que existen.

Esto importa porque la guardia es la pieza del kit que más equipos montan mal, y la montan mal siempre de la misma forma: creen que es un problema de calendario. Ponen a seis personas en una rueda, cada una una semana, y se sienten cubiertos. Dos meses después la rotación se deshizo sola, todo el mundo volvió a llamarte a ti, y quedó la sensación de que "ya se intentó y no funciona". La guardia no es un calendario: es un acuerdo sobre qué interrumpe la vida de una persona, quién puede resolverlo, y qué recibe esa persona a cambio. El calendario es la parte fácil y la última.

Conexión con el módulo: esta es la segunda pieza del kit —la guardia— y viene después del runbook por una razón dura que ya se adelantó en la lección 2: una guardia sin runbooks es un calendario de gente angustiada. No se puede pedir a alguien que responda si no le diste con qué. Por eso las lecciones 2 y 3 van primero. Esta lección también retoma un tema del Módulo 2 —la fatiga de alertas de su lección 7— pero desde el otro lado. Allá lo viste desde la máquina: cómo se agrega, se deduplica y se suprime un aviso para que el canal no se sature. Aquí lo ves desde la persona: qué le pasa a un ser humano a quien despiertas cuatro veces por nada, y por qué su reacción —dejar de leer las alertas— es racional y destruye el sistema. Los dos lados son el mismo problema; el Módulo 2 arregló la fuente, esta lección cuida al destinatario.

El turno de guardia del edificio

Piensa en un edificio de departamentos con un portero de noche.

El portero no está ahí para hacer el trabajo de todos los días —eso pasa de día, con el administrador, el de limpieza, el de mantenimiento—. Está ahí para una cosa: que si a las tres de la mañana se rompe una tubería, o alguien se queda afuera, o suena una alarma, haya una persona despierta que sepa qué hacer o a quién llamar. La mayoría de las noches no pasa nada y el portero lee un libro. Esa es exactamente la señal de que el sistema funciona.

Ahora fíjate en qué haría que ese puesto se volviera insoportable, porque es lo mismo que quema una guardia técnica:

Si lo despiertan por todo. Si cada vez que un gato tira un bote de basura suena una alarma que lo obliga a levantarse, revisar y volver a sentarse, en una semana ese portero deja de reaccionar a las alarmas. Y el día del incendio real, la alarma suena y él piensa "otra vez el gato" y no se levanta. La alarma que suena por todo es una alarma que no protege de nada.

Si no le dijeron qué hacer. Si el portero no tiene una lista de "si pasa X, haz Y; si pasa Z, llama a este número", cada evento nocturno es una crisis personal donde tiene que improvisar solo, cansado, sin poder consultar a nadie. Eso no es un trabajo, es una tortura, y nadie lo aguanta mucho tiempo.

Si no lo compensan. Si estar despierto y disponible toda la noche se trata como si fuera lo mismo que un turno de día, el portero se quema y renuncia, y encontrar al siguiente es cada vez más difícil, porque la fama del puesto se corre.

Si no hay relevo. Si es siempre la misma persona, todas las noches, sin que nadie más pueda cubrirla, entonces esa persona no puede enfermarse, ni tener una emergencia familiar, ni tomar vacaciones. El puesto se vuelve una jaula.

Una guardia técnica bien hecha resuelve esas cuatro cosas: no despierta por todo (la política de qué es una emergencia), dice qué hacer (los runbooks), compensa (el acuerdo con la empresa), y tiene relevo (la rotación). Fíjate en que solo la última es el calendario. Las otras tres son lo que la mayoría de los equipos olvida, y son las que deciden si la guardia sobrevive.

Ejemplo trabajado: la semana de Daniela, dos veces

Volvamos a Daniela, que entró hace dos meses. Le toca su primera semana de guardia. Vamos a mirarla dos veces, cambiando solo la política de alertas.

Versión A — sin política: "avísame de todo fallo".

Terra Market tiene su #ops-alerts conectado a "cualquier ejecución fallida". Esta es la semana de Daniela:

Noche	Hora	Alerta	¿Requería acción?
Lunes	01:14	carrier dio timeout, reintento lo resolvió	No
Lunes	03:40	inventory-update falló una corrida, la siguiente corrigió	No
Martes	02:09	Un sku con precio vacío se apartó en dead_letter	No
Miércoles	04:22	shipment-notify no mandó un correo, email inválido	No
Jueves	02:51	El ERP cayó de verdad, 23 pedidos apartados	Sí
Viernes	01:30	carrier timeout otra vez	No

Seis noches, seis interrupciones, una que de verdad importaba. Pero mira lo que le pasó a Daniela por el camino. El lunes se levantó dos veces, miró, no había nada que hacer, se volvió a dormir molesta. El martes ya abrió el teléfono medio dormida, vio "otra del inventario", y sin leerla bien la descartó. El miércoles ni se levantó: miró desde la cama y siguió durmiendo. El jueves —la noche del ERP, la que sí importaba— su teléfono sonó a las 02:51 y ella, entrenada por cuatro noches de falsas alarmas, pensó "otra vez algo del inventario o del carrier", silenció el teléfono y siguió durmiendo. Se enteró del incidente real a las 07:10, cuando Gerardo escribió al canal del día.

Daniela no fue negligente. Daniela fue entrenada por el sistema para ignorar las alertas, y respondió racionalmente a ese entrenamiento. El problema no fue de ella: fue de un canal que gritó lobo cinco veces antes del lobo de verdad.

Versión B — con política: solo lo que requiere acción llega al canal que despierta.

Con las cuatro primeras filas reclasificadas —los reintentos exitosos no llegan a ningún lado, los items apartados van al resumen de dead-letter-watch en el canal del día, los rechazos de negocio van a error_log— la semana de Daniela se ve así:

Noche	Hora	Alerta a #ops-alerts	¿Requería acción?
Jueves	02:51	El ERP cayó, 23 pedidos apartados	Sí

Una sola interrupción en toda la semana. Y cuando el teléfono de Daniela sonó el jueves a las 02:51, había sonado cero veces antes esa semana. Ese silencio previo es lo que le dio significado a la alarma. Daniela se levantó, abrió el runbook, verificó que nada se perdía, y resolvió, exactamente como viste en la lección 1.

Qué esperar. La diferencia entre las dos versiones no es el número de fallos —fueron los mismos seis eventos en el sistema— sino cuántos cruzaron la frontera hasta una persona dormida. Y la consecuencia es contraintuitiva: el canal que avisa menos es el que protege más.

	Versión A (avisa de todo)	Versión B (avisa lo accionable)
Interrupciones nocturnas en la semana	6	1
Alertas que requerían acción	1	1
¿Se atendió el incidente real a tiempo?	No (5 h tarde)	Sí
Estado de Daniela al final de la semana	Quemada y desconfiada	Cansada una noche, nada más

La fila que más importa vuelve a ser la última. En la versión A, Daniela termina la semana habiendo aprendido que la guardia es un castigo inútil, y esa lección se contagia: se lo cuenta al equipo, y la próxima persona entra a su turno ya predispuesta a ignorar el teléfono. En la versión B, la guardia es molesta una noche y llevadera el resto, que es lo máximo a lo que una guardia puede aspirar y es suficiente para que el sistema se sostenga en el tiempo.

La decisión se toma antes, no a las 3 a.m.

Aquí está el principio central de la lección, y es tan importante que merece decirse solo: la decisión de qué merece despertar a alguien se toma con la cabeza fresca, de antemano, en una reunión de treinta minutos —no a las tres de la mañana con la lámpara prendida.

La razón es simple y es de sentido común: a las tres de la mañana, medio dormido, nadie toma buenas decisiones sobre gravedad. La persona que recibe la alerta no está en condiciones de razonar "bueno, esto es un fallo del carrier que suele resolverse solo, así que puedo esperar, pero déjame verificar que dead_letter no crezca…". Esa cadena de razonamiento se hace mal a esa hora. Lo que sí puede hacer una persona medio dormida es mirar una regla escrita y seguirla. Así que el trabajo de la guardia consiste en mover toda la decisión de gravedad del momento del incidente a un momento anterior y tranquilo.

Piénsalo como el protocolo de un socorrista. El socorrista no decide en el momento del ahogamiento si vale la pena entrar al agua, ponderando el oleaje contra su cansancio. Eso ya está decidido: hay un protocolo escrito, practicado en seco mil veces, que dice exactamente qué condiciones justifican entrar y cuáles obligan a llamar refuerzos. En la emergencia, el socorrista ejecuta, no delibera. La deliberación pasó antes, en tierra firme, con la cabeza clara.

Tu política de guardia es ese protocolo. Y se construye respondiendo, para cada tipo de fallo, una sola pregunta —la misma que viste en el Módulo 2 pero ahora aplicada a la persona—:

¿Qué haría, ahora mismo, la persona de guardia si recibe esto? Si la respuesta honesta es "nada, esto se resuelve solo o puede esperar a mañana", entonces no debe llegar al canal que despierta. Punto.

De esa pregunta salen tres niveles, que son la traducción a "guardia" de las tres severidades del Módulo 2:

Nivel	¿Despierta?	Ejemplo en Terra Market	Qué recibe la persona
Despierta ahora	Sí, a cualquier hora	El ERP caído perdiendo pedidos; el trigger de order-sync muerto	Llamada + Slack con mención
Espera a mañana	No	dead_letter creciendo pero con todo a salvo; shipment-notify con correos duplicados	Resumen en el canal del día
Solo queda registrado	No	Reintentos exitosos, rechazos de negocio	Nada; vive en error_log

Y la regla de oro que decide dónde va cada fallo, la que hace toda la diferencia y que ya conoces de la lección 1: solo se puede posponer un aviso si estás seguro de que nada se está perdiendo mientras tanto. Un fallo donde los pedidos quedan a salvo en dead_letter puede esperar a la mañana. Un fallo donde los pedidos se están evaporando no puede esperar, sean las tres o las cinco. La frontera no es la hora ni la gravedad aparente: es si el daño está contenido. Esa es la misma condición innegociable de las ventanas horarias del Módulo 2, y aquí es lo que separa una política sensata de una que descubre un desastre por la mañana.

La fatiga de alertas como falla operativa medible

En el Módulo 2 conociste la fatiga de alertas desde la máquina. Aquí la vas a ver como lo que es desde el punto de vista de la operación: una falla del sistema que se puede medir, igual que mides la tasa de error de un workflow.

La definición operativa es esta: la fatiga de alertas empieza cuando la proporción de alertas que no requieren acción es tan alta que la persona deja de leerlas todas —incluidas las que sí importan. No es pereza ni mala actitud. Es una adaptación racional: si el 80% de lo que llega a un canal es ruido, el cerebro aprende, correctamente, que la apuesta más probable ante un mensaje nuevo es que sea ruido, y deja de invertir energía en leerlo. La consecuencia es que el 20% que sí importaba se pierde junto con el resto.

Y aquí está lo que la hace peligrosa y no solo molesta: el sistema se ve más sano cuanto más roto está. Un canal con cuarenta alertas diarias parece un canal muy vigilado —"mira cuánta visibilidad tenemos"—. En realidad es un canal que nadie lee, es decir, un sistema sin vigilancia con la apariencia de tenerla. La abundancia de alertas se disfraza de cobertura y es lo contrario.

Como es medible, se puede vigilar con un par de números que cualquier equipo puede llevar:

La tasa de accionabilidad. De las alertas que llegaron al canal que despierta esta semana, ¿qué fracción llevó a que alguien hiciera algo? Si de diez alertas, ocho no requirieron ninguna acción, tu tasa de accionabilidad es del 20% y la fatiga ya empezó. Una guardia sana vive cerca del 100%: casi todo lo que despierta a alguien, merecía despertarlo.

El volumen objetivo por nivel. Ya lo viste en el Módulo 2 y aquí es la herramienta de la guardia: el nivel "despierta ahora" debería producir cero o una alerta la mayoría de las noches. Si empieza a producir cinco por noche, el problema no es que haya más fallos: es que algo mal clasificado se coló, o que las capas de defensa del Módulo 2 dejaron de hacer su trabajo. En cualquier caso, es una señal de arreglar la clasificación, nunca de subir el umbral para que dejen de llegar.

Ese último punto es la trampa más común y vale la pena nombrarla: cuando un canal se satura, la reacción instintiva es "voy a hacer que me avise de menos cosas" subiendo un umbral a ciegas. Eso no calibra nada: apaga alarmas sin saber cuáles. La forma correcta es al revés —mirar qué está llegando que no debería, y moverlo al nivel que le corresponde—, que es un trabajo de clasificación, no de silenciar.

Lo que hace sostenible una rotación

El calendario es la parte fácil, pero tiene decisiones que conviene tomar bien porque afectan si la gente aguanta.

El tamaño del turno. Con seis personas, lo natural es una rotación semanal: cada quien una semana cada seis. Una semana es un buen tramo —suficiente para que la persona tenga contexto continuo de lo que pasa, no tanto como para agotarla—. Turnos más cortos (un día) fragmentan demasiado el contexto; más largos (un mes) queman. Y una regla práctica: si el equipo es tan pequeño que la rotación toca a cada quien demasiado seguido, ese es un dato sobre el equipo, no sobre la guardia. Una guardia que recae sobre dos personas no es sostenible, y la respuesta no es apretar más a esas dos, es reducir lo que la guardia tiene que atender —con mejores capas de defensa del Módulo 2— o crecer el equipo.

Quién puede estar de guardia. No todos desde el día uno. Daniela, recién llegada, no debería tener la guardia en su primera semana de trabajo: primero necesita los runbooks, un par de incidentes acompañada, y saber a quién escalar. La guardia se gana entrando por la puerta del acompañamiento, no se asigna por calendario. Esto conecta directo con el error que la lección 2 ya nombró: repartir la guardia sin repartir primero la capacidad. El orden correcto es capacidad primero (runbooks + acompañamiento), turno después.

El escalamiento como red de la red. La persona de guardia nunca está sola de verdad: siempre hay a quién escalar. En Terra Market, el primer nivel es quien tiene el turno; si un incidente lo supera o no puede resolverlo, escala a la persona experta (tú) o al líder (Marco). Esto no es una debilidad de la persona de guardia: es lo que hace posible que alguien poco experto tome el turno sin miedo, porque sabe que no va a quedarse atrapado con un problema que no entiende. Una guardia sin escalamiento claro es una guardia que solo pueden tomar los expertos, y eso derrota su propósito.

La compensación y los límites. Estar disponible fuera de horario tiene un costo real en la vida de una persona, y tratarlo como si no lo tuviera es la forma más segura de que nadie quiera hacerlo. La forma de compensarlo —tiempo libre, pago, lo que la empresa decida— no es un tema técnico y varía por lugar; lo que sí es innegociable es que se reconozca explícitamente. Y un límite que protege a todos: quien tuvo una noche de guardia movida no empieza el día siguiente como si hubiera dormido. Un equipo que quema a su gente de guardia se queda sin gente dispuesta, y ahí ya no hay política que salve la rotación.

El anunciador de guardia: el único workflow del módulo

Este es el único momento del módulo en que construimos algo en n8n, y conviene ser honesto sobre qué es y qué no. n8n no tiene una función de "gestión de guardias". No hay una pantalla de quién está de turno ni un botón de escalamiento. Lo que sí podemos hacer, con nodos que existen, es un workflow pequeño que resuelve un problema real y molesto: que todo el equipo sepa, sin preguntar, quién está de guardia esta semana.

El problema que resuelve es concreto. Sin esto, cuando algo se rompe, la primera pregunta del equipo es "¿quién está de guardia?", y esa pregunta se responde a destiempo, en medio del incidente, que es el peor momento. Un anuncio automático cada lunes elimina esa fricción.

La forma es sencilla:

Schedule Trigger ──► Code: "¿A quién le toca?" ──► Slack: publicar en #ops-daily
   (lunes 09:00)        (calcula el turno)          (anuncio de la semana)

El disparador es un Schedule Trigger configurado para correr los lunes a las 09:00. Ese nodo existe y es exactamente para esto: ejecutar algo en un horario recurrente.

El cálculo es un nodo Code, y aquí es importante respetar la restricción de n8n 2.x que ya conoces: dentro del nodo Code no hay peticiones HTTP, ni acceso a archivos, ni require de nada externo. Lo que sí hay es lógica pura con las librerías permitidas. Este cálculo no necesita nada más: es aritmética de fechas.

// ============================================================
// Nodo: Code — "¿A quién le toca?"
// Modo: Run Once for All Items
//
// QUÉ HACE: calcula qué persona del equipo está de guardia esta
//           semana, rotando en orden por semana del calendario.
// POR QUÉ:  el equipo debe saber quién responde SIN preguntarlo en
//           medio de un incidente. Esto lo publica cada lunes.
// NOTA n8n 2.x: nada de HTTP ni archivos aquí. Solo lógica y 'moment',
//           que es una de las librerías permitidas en el nodo Code.
// ============================================================

const moment = require('moment');

// El orden de la rotación. Daniela NO está todavía: entra cuando
// termine su acompañamiento (ver la política de "quién puede estar
// de guardia"). Meter a alguien antes de tiempo rompe la guardia.
const rotation = ['Tú', 'Marco', 'Sofía', 'Iván', 'Renata'];

// Semana ISO del año: un número de 1 a 53 que avanza cada lunes.
// Sirve como índice estable de la rotación.
const week = moment().isoWeek();

// El resto de la división reparte las semanas en ciclo sobre la lista:
// semana 1 -> índice 1, semana 5 -> índice 0, y así sin fin.
const onCall = rotation[week % rotation.length];

// El respaldo es siempre el siguiente en la rueda: a quien la persona
// de guardia escala si necesita una segunda mano.
const backup = rotation[(week + 1) % rotation.length];

const message =
  `📟 *Guardia de esta semana (semana ${week})*\n` +
  `Responde: *${onCall}*\n` +
  `Respaldo: ${backup}\n\n` +
  `Runbooks: RUNBOOK-01..04 · Escalamiento: si te supera, al respaldo, ` +
  `y si sigue, a Marco.`;

// Devolvemos el texto listo para que el nodo de Slack lo publique.
// El nodo Code arma el mensaje; el ENVÍO lo hace el nodo de Slack,
// nunca este nodo (restricción de n8n 2.x).
return { json: { on_call: onCall, backup, week, message } };

El envío lo hace un nodo de Slack que publica {{ $json.message }} en #ops-daily. Recuerda, una vez más, la restricción: la llamada al servicio la hace el nodo de la integración, no el nodo Code.

Qué esperar. Cada lunes a las 09:00, el equipo ve en el canal quién responde esa semana y quién es el respaldo. Es un workflow de veinte minutos que elimina una pregunta que, de otro modo, siempre se hace en el peor momento. No gestiona la guardia —la guardia la gestiona el acuerdo humano que montaste en las secciones anteriores—; solo la anuncia, que es justamente lo que n8n puede hacer bien.

Una limitación honesta que conviene anotar: este anunciador no sabe de intercambios de última hora ("esta semana me toca a mí pero me voy de viaje, cambio con Sofía"). Esos cambios son humanos y se acuerdan hablando; si ocurren seguido, la lista del código se edita a mano. No intentes construir un sistema de intercambios dentro de n8n: sería mucho trabajo para resolver algo que una conversación resuelve mejor. La herramienta hace la parte mecánica; las personas hacen la parte humana.

Errores comunes

Montar la guardia como un calendario y nada más (conceptual). Qué pasa: el equipo reparte semanas entre seis personas y da la guardia por resuelta. Falta la política de qué despierta a alguien, faltan los runbooks, falta el escalamiento y falta la compensación. La primera semana movida, la persona de turno sufre, no puede resolver nada, y la rotación empieza a deshacerse. Por qué pasa: el calendario es la parte visible y fácil de la guardia, así que se confunde la parte con el todo. Cómo detectarlo: pregunta a la persona que tiene la guardia esta semana qué haría con un fallo del ERP a las tres de la mañana. Si no puede responder con precisión, la guardia es solo un calendario. Cómo corregirlo: antes de repartir turnos, ten los runbooks (lección 3), la política de niveles (esta lección) y el escalamiento con nombres. El calendario va al final, no al principio.

Bajar el ruido subiendo el umbral a ciegas (práctico). Qué pasa: el canal que despierta se satura, y para que "deje de molestar" alguien sube un umbral —"que solo avise si fallan más de diez"—. El ruido baja, sí, pero también se apagan alarmas que importaban, sin saber cuáles. Un día un fallo real no cruza el nuevo umbral y nadie se entera. Por qué pasa: subir un umbral es una acción rápida que produce alivio inmediato, y el costo —las alarmas que ahora no suenan— es invisible hasta que estalla. Cómo detectarlo: si tu último cambio a las alertas fue "que avise de menos" sin haber mirado qué estaba llegando, apagaste a ciegas. Cómo corregirlo: no bajes el volumen, arregla la clasificación. Mira qué está llegando al canal que no debería y muévelo al nivel que le toca. El objetivo es que todo lo que despierte a alguien merezca despertarlo, no que despierte a menos gente por cosas al azar.

Poner a alguien de guardia antes de que pueda responder (práctico). Qué pasa: para "repartir la carga cuanto antes", se mete a la persona más nueva en la rotación en sus primeras semanas. Le toca un incidente, no tiene los runbooks interiorizados ni sabe a quién escalar, pasa una hora angustiada y termina llamándote de todos modos. Encima, ahora asocia la guardia con esa angustia. Por qué pasa: hay presión por descargar al experto rápido, y meter a alguien a la rueda parece progreso. Cómo detectarlo: si alguien en la rotación no podría resolver el incidente más común sin llamarte, no está listo para el turno. Cómo corregirlo: la guardia se gana con acompañamiento —runbooks leídos, un par de incidentes vividos al lado de alguien con experiencia, escalamiento claro—. Meter a la rueda a quien aún no puede responder no reparte la carga: la disfraza y la devuelve peor.

Ejercicios

Ejercicio 1 — Clasifica la semana. Aquí hay seis eventos de una semana de guardia en Terra Market. Para cada uno, di a qué nivel pertenece —despierta ahora / espera a mañana / solo registro— y por qué. Recuerda la regla de oro: solo se pospone si nada se pierde.

(a) A las 02:00, el trigger de order-sync deja de recibir webhooks por completo; no entran pedidos. (b) A las 03:30, dead_letter tiene 60 items apartados de inventory-update por precios vacíos; la tienda muestra precios viejos. (c) A la 01:00, un reintento del carrier resuelve un timeout al segundo intento. (d) A las 04:00, el ERP está lento por el pico nocturno; algunas ejecuciones dan timeout pero se apartan en dead_letter. (e) A las 02:45, shipment-notify empieza a mandar correos duplicados en masa por un reenvío del carrier. (f) A las 05:00, un pedido se rechaza deliberadamente por venir con total: 0.

Ver solución

(a) Despierta ahora. El trigger muerto significa que no entran pedidos y no se están guardando en ningún lado —no hay dead_letter que valga cuando el workflow ni siquiera arranca—. Falla la regla de oro por completo: sí se está perdiendo. Es el caso más grave de todos, porque además es silencioso: no hay ejecuciones en rojo, hay ausencia de ejecuciones. Despierta a cualquier hora.

(b) Espera a mañana. 60 items apartados suena a mucho, pero la pregunta correcta no es cuántos, es si se pierden: no se pierden, están en dead_letter, y la tienda con precios viejos es mejor que con precios malos. La regla de oro se cumple. Va al resumen del canal del día. Ahora bien, si a la mañana siguiente siguen creciendo, eso es un problema de dato malo del RUNBOOK-03, pero de día.

(c) Solo registro —de hecho ni eso: un reintento exitoso terminó en verde y no llega ni al error workflow—. Es la capa 1 del Módulo 2 haciendo su trabajo. Si esto despertara a alguien, sería el primer paso hacia la fatiga.

(d) Espera a mañana. Lentitud nocturna con los pedidos a salvo en dead_letter. La regla de oro se cumple. Y es un caso de manual para NO despertar: es esperado, se recupera solo o con un reproceso de mañana, y despertar por la lentitud del pico solo enseñaría a ignorar el canal.

(e) Caso de frontera, y por eso es interesante. No se pierde dinero ni datos —así que por la regla de oro estricta podría esperar—, pero el daño crece con cada minuto: son correos irreversibles saliendo a clientes reales, y a diferencia de dead_letter, esto no está "contenido", se está derramando. Aquí la decisión razonable es despertar, porque contener (pausar el workflow, RUNBOOK-04) detiene un daño que de otro modo se acumula toda la noche. La regla de oro tiene una segunda parte implícita: no solo "¿se pierde algo?" sino "¿el daño está contenido o crece?".

(f) Solo registro. Es un rechazo deliberado, el sistema funcionando, no fallando (la capa 3 del Módulo 2). A error_log. Vale revisarlo de día por si los total: 0 se disparan —sería un bug de storefront— pero de noche no es nada.

Por qué funciona: de seis eventos, solo dos justifican despertar a alguien, y por razones distintas —(a) porque se pierde, (e) porque el daño crece sin contenerse—. Los otros cuatro esperan o ni siquiera llegan. Ese reparto es el objetivo de la política: que el canal que despierta sea tan raro que, cuando suene, nadie dude en atenderlo. Fíjate en que la clasificación no depende de la hora ni del número de casos, sino de dos preguntas: ¿se pierde algo? y ¿el daño está contenido?

Ejercicio 2 — Diagnostica la fatiga. El equipo de Terra Market lleva un registro de su canal que despierta durante cuatro semanas. Los números: semana 1, 12 alertas, 2 requirieron acción; semana 2, 15 alertas, 1 requirió acción; semana 3, 18 alertas, 2 requirieron acción; semana 4, 20 alertas, 1 requirió acción. Calcula la tasa de accionabilidad de cada semana, di qué está pasando, y propón la acción correcta y la incorrecta.

Ver solución

Las tasas de accionabilidad (acciones / alertas):

• Semana 1: 2/12 ≈ 17%
• Semana 2: 1/15 ≈ 7%
• Semana 3: 2/18 ≈ 11%
• Semana 4: 1/20 = 5%

Qué está pasando: dos cosas malas a la vez. Primero, la tasa de accionabilidad es bajísima —entre el 5% y el 17%—, lo que significa que más del 80% de lo que despierta a alguien no requería despertarlo. Segundo, y peor, el volumen total está subiendo semana a semana (12 → 15 → 18 → 20) mientras las acciones reales se mantienen en una o dos. Es la firma exacta de la fatiga de alertas instalándose: cada vez más ruido, la misma señal real, y una tasa de accionabilidad en caída. Para la semana 4, con un 5%, es casi seguro que el equipo ya dejó de leer el canal con atención.

La acción incorrecta: subir un umbral para que "lleguen menos". Bajaría el número de 20 a, digamos, 8, y se sentiría como una mejora. Pero apagaría alarmas a ciegas, y como las que importan son solo una o dos entre veinte, hay un riesgo real de apagar justo esa. El síntoma —volumen alto— se atacaría sin tocar la causa.

La acción correcta: mirar las 20 alertas de la semana 4 y clasificar cada una por qué llegó al canal que despierta sin requerir acción. Casi con certeza vas a encontrar que son reintentos que se resolvieron, items apartados que debían ir al resumen del día, o rechazos de negocio que debían ir a error_log. Cada una se mueve a su nivel correcto. El objetivo no es "menos alertas": es que las que queden tengan una tasa de accionabilidad cercana al 100%. Si al terminar el canal recibe 2 alertas y las 2 requerían acción, la guardia está sana, aunque el número absoluto sea chico.

Por qué funciona: la tasa de accionabilidad convierte una sensación difusa —"me llegan muchas alertas"— en un número que se puede vigilar y sobre el que se puede actuar. Y distingue las dos reacciones posibles: bajar el volumen (que trata el síntoma y esconde el problema) versus subir la accionabilidad (que trata la causa). Una guardia se mide por la segunda, nunca por la primera.

Ejercicio 3 — Rediseña una rotación rota. Terra Market montó su guardia así: los seis del equipo, incluida Daniela que entró hace dos meses, rotan una semana cada uno; el canal avisa de todo fallo; no hay runbooks escritos; y no hay acuerdo de compensación ni de escalamiento. A los dos meses, la rotación se deshizo y todo vuelve a caer en ti. Identifica los cuatro errores y propón el orden correcto para reconstruirla.

Ver solución

Los cuatro errores, que son justamente las cuatro cosas del portero de noche:

1. Avisa de todo fallo → fatiga de alertas garantizada. La persona de turno se quema en su primera semana movida y aprende a ignorar el canal. Falta la política de niveles.

2. No hay runbooks → cada incidente es una crisis personal donde la persona improvisa sola y cansada. Sin el guion, la guardia es una tortura y termina llamándote de todos modos. Falta la pieza 1 del kit.

3. Daniela en la rotación desde el mes dos → alguien sin la capacidad para responder tiene el turno, sufre, y asocia la guardia con la angustia. Falta el acompañamiento previo.

4. Sin compensación ni escalamiento → estar disponible de noche se trata como gratis, y quien se atora no tiene a quién recurrir. Faltan el reconocimiento y la red de escalamiento.

El orden correcto para reconstruirla, que es el orden de las piezas del kit:

1. Primero los runbooks (lección 3), al menos para los tres o cuatro síntomas más frecuentes. Sin esto, nada de lo demás sirve.
2. Después la política de niveles: reclasificar las alertas para que el canal que despierta reciba cero o una por noche. Esto arregla la fatiga y hace la guardia soportable.
3. Después el escalamiento con nombres y el acuerdo de compensación, para que quien tome el turno sepa que no está solo y que su tiempo se reconoce.
4. Solo entonces el calendario, y con Daniela fuera de la rueda hasta que complete su acompañamiento —runbooks leídos y un par de incidentes vividos al lado de alguien con experiencia—.

Fíjate en que el calendario, que fue lo único que el equipo hizo la primera vez, es el último paso de la reconstrucción. Esa inversión de orden es la lección entera: la guardia no empieza por el calendario, termina en él.

Por qué funciona: el ejercicio muestra que una guardia rota casi nunca se arregla ajustando el calendario —que es lo que la intuición pide— sino construyendo las tres cosas que faltaban debajo. Y el orden importa: los runbooks habilitan la política, la política habilita que la guardia sea soportable, y solo una guardia soportable puede repartirse en un calendario que sobreviva.

Resumen y siguiente paso

En esta lección montaste la segunda pieza del kit. Con la imagen del portero de noche viste las cuatro cosas que hacen sostenible una guardia —que no despierte por todo, que diga qué hacer, que compense, que tenga relevo— y notaste que solo la última es el calendario, que es donde la mayoría de los equipos empieza y se equivoca. Comparaste la semana de guardia de Daniela dos veces y viste que el canal que avisa menos es el que protege más: con "avísame de todo", seis interrupciones entrenaron a Daniela a ignorar justo la que importaba; con una política que solo deja pasar lo accionable, una sola interrupción recuperó el significado de la alarma. Aprendiste el principio central —la decisión de qué despierta a alguien se toma antes, no a las tres de la mañana, como el protocolo de un socorrista— con sus tres niveles y la regla de oro de que solo se pospone lo que está contenido. Entendiste la fatiga de alertas como una falla medible, con la tasa de accionabilidad y el volumen objetivo como sus dos números, y la trampa de subir umbrales a ciegas. Y construiste el único workflow del módulo: el anunciador semanal de guardia, con Schedule Trigger y un nodo Code de aritmética de fechas que respeta la restricción de n8n 2.x.

Antes de avanzar deberías poder: clasificar un fallo en despierta-ahora / espera-a-mañana / solo-registro usando la regla de oro; calcular una tasa de accionabilidad y decir qué hacer si es baja; y explicar por qué el calendario es el último paso de montar una guardia, no el primero.

Hasta aquí has preparado todo lo que se decide antes del incidente: el guion (runbooks) y quién responde con qué criterio (guardia). Pero llega el momento en que algo grande de verdad se rompe, y ahí ni el mejor runbook alcanza, porque no es un síntoma conocido con su ficha: es un incidente que se despliega en tiempo real y hay que conducirlo. La lección 5 es la tercera pieza del kit: la línea de tiempo de un incidente. Qué se hace y en qué orden —detectar, comunicar, contener, resolver, verificar—, por qué contener va antes que entender la causa (primero se detiene la sangre), quién habla con el negocio mientras alguien arregla y por qué esas dos personas no deben ser la misma, y el registro que se escribe mientras ocurre y no después.

Recursos

• Schedule Trigger — n8n Docs — el disparador del anunciador de guardia, configurado para correr los lunes a las 09:00.
• Code node — n8n Docs — el nodo donde se calcula el turno; recuerda que en n8n 2.x no admite HTTP ni acceso a archivos, solo lógica y las librerías permitidas como moment.
• Slack node — n8n Docs — el nodo que publica el anuncio en #ops-daily; la llamada al servicio la hace este nodo, nunca el nodo Code.
• Handle errors gracefully — n8n Docs — las capas de defensa cuyo buen funcionamiento es lo que mantiene bajo el volumen del canal que despierta; una guardia sana descansa sobre ellas.