La pregunta que nadie contesta hasta que son las 23:40 de un viernes
La automatización lleva ocho meses funcionando y nadie ha vuelto a hablar de ella. Eso es exactamente lo que se compró. El problema es que ese silencio se confunde con una respuesta a una pregunta que nunca se hizo: si esto se cae, ¿quién lo coge? Y la pregunta se contesta sola, mal, la primera noche que el flujo de pedidos deja de crear albaranes: alguien escribe al grupo de WhatsApp del equipo, otro alguien responde a las siete de la mañana, y por el camino se han quedado sin procesar catorce pedidos que nadie sabe todavía que existen.
La guardia y el soporte de automatizaciones es la parte del día dos que casi nadie compra porque no se ve en la demo. No es un servicio de 24×7 con centralita. Son cuatro decisiones tomadas en frío —qué es grave, a quién se llama, qué hace esa persona cuando llega y qué se hace mientras tanto— escritas en un sitio donde las encuentre alguien que no seas tú. Sin ellas, tu plan de contingencia es tu memoria, y tu memoria se va de vacaciones en agosto.
Severidades de verdad: qué justifica llamar a alguien y qué espera a mañana
La primera decisión no es a quién llamas: es cuándo se llama a alguien. Sin esa línea escrita pasan las dos cosas malas a la vez. Todo parece urgente —y el equipo aprende a ignorar los avisos porque saltan por cualquier cosa— o nada lo parece, y el fallo que costaba dinero se descubre el lunes.
La industria de operaciones lleva décadas resolviendo esto con niveles de severidad, y la práctica establecida es sensata: PagerDuty recomienda mapear cada nivel directamente a la política de escalado y aviso, y advierte de que seis o siete niveles que nadie sabe distinguir producen parálisis de clasificación: entre tres y cinco es el punto dulce. En una empresa que no tiene equipo de guardia, tres sobran.
| Nivel | Qué significa en tu casa | Qué se hace |
|---|---|---|
| Grave | Se está perdiendo dinero o compromiso con cliente ahora mismo: no salen pedidos, no se cobran facturas, no se responde a nadie. | Se avisa a la persona de guardia en el momento, sea la hora que sea. Se activa el plan manual. |
| Molesto | El proceso funciona a medias o solo para una parte: una integración caída con salida alternativa, un lote que no se ha procesado pero se puede reprocesar. | Se registra y se coge a primera hora del siguiente día laborable. No se llama a nadie de noche. |
| Feo pero puede esperar | Algo está mal y no tiene consecuencia inmediata: un informe que no se generó, un campo que llega vacío en un sitio que nadie mira hasta el cierre de mes. | Entra en la cola de mantenimiento de la semana. |
El criterio que hace que esta tabla funcione no es técnico, es de negocio: la severidad la define el daño que hace cada hora que pasa, no lo roto que esté el sistema. Un flujo completamente muerto que solo mueve un informe interno es «feo pero puede esperar». Un flujo que funciona al 90% pero está mandando presupuestos con el precio equivocado es grave. Escribe la tabla con esa lógica y con tus procesos por nombre —«pedidos web», «facturación», «avisos a clientes»— no con categorías abstractas. Una severidad que hay que interpretar a las 23:40 no sirve para nada.
La guardia que cabe en una empresa pequeña (no copies el modelo de una big tech)
Aquí es donde la mayoría de artículos se vuelven inútiles: describen rotaciones semanales, escalados de tres niveles y localizadores. Tú tienes dos personas que saben tocar los flujos y una de ellas eres tú. La guardia realista a esa escala tiene cuatro piezas y ninguna cuesta dinero.
- Un nombre por semana, escrito. No «el equipo», no «quien lo vea». Una persona concreta por semana, en un calendario compartido, con las semanas ya repartidas hasta fin de trimestre. El valor no está en la rotación: está en que a las 23:40 nadie tenga que decidir a quién molesta.
- Un canal que sí interrumpe. El correo no despierta a nadie y un canal de Slack silenciado tampoco. El aviso de severidad grave tiene que llegar por algo que suene: una llamada, un SMS, una notificación configurada como excepción del modo «no molestar». Lo demás puede ir por el canal de siempre.
- Un suplente, y solo uno. Si el de guardia no contesta en un plazo que tú decides —quince minutos es razonable—, se avisa al suplente. Sin cadena de cuatro niveles: en una empresa de veinte personas, el tercer nivel es siempre la misma persona.
- Una regla de compensación explícita. Si alguien atiende una incidencia un sábado, eso se paga o se descansa. La guardia que se sostiene sobre la buena voluntad dura exactamente hasta la segunda vez que alguien pierde una cena.
Y una decisión honesta antes de montar nada: ¿de verdad necesitas guardia nocturna? Si tus procesos críticos solo tienen consecuencia en horario comercial —facturación, pedidos B2B, avisos internos—, la respuesta correcta es no tener guardia de noche y decirlo en voz alta, en vez de tener una guardia informal que nadie ha aceptado. Lo que sí necesitas siempre es que el fallo esté registrado y visible a primera hora. En n8n eso se monta con un flujo de error único conectado a todos los demás: la documentación oficial describe cómo un solo Error Workflow con nodo Error Trigger se reutiliza en todos los flujos de producción, sin construir el aviso uno por uno. Make y Zapier tienen equivalentes propios.
El runbook de una página: lo único que hace que responda otra persona
La guardia sin runbook es un teléfono que suena para avisar a alguien de que no puede hacer nada. Un runbook es la ficha de una página —una, no doce— que convierte «el flujo de pedidos está caído» en una secuencia que puede ejecutar quien no lo construyó. PagerDuty lo dice sin adornos: los incidentes de severidad alta deben apuntar a un runbook para que quien responde no improvise.
Uno por flujo crítico. No por flujo: por flujo crítico, que en una empresa normal son entre tres y cinco. Cada ficha contesta seis preguntas y nada más:
- Qué hace este flujo y qué pasa si está parado. Dos líneas de negocio, no de técnica. «Crea el albarán en el ERP cuando entra un pedido web. Si está parado, los pedidos entran pero no se preparan.»
- Cómo se comprueba en treinta segundos si está vivo. El enlace exacto al historial de ejecuciones, y qué se mira ahí.
- Las tres causas que ya han pasado antes, y su arreglo. Credencial caducada, cuota del proveedor agotada, campo que llega vacío. Con el clic concreto, no con la teoría.
- Cómo se para del todo. El botón, el interruptor, el sitio. Parar es una acción legítima y muchas veces la correcta: un flujo caído hace menos daño que un flujo que decide mal.
- Qué se hace mientras tanto (el plan manual, siguiente sección).
- A quién se escala si nada de esto funciona, con nombre y teléfono.
El runbook es un primo cercano de la documentación del flujo, pero no es lo mismo y conviene no mezclarlos: documentar tus automatizaciones sirve para que alguien pueda mantenerlas y cambiarlas con calma; el runbook sirve para los quince minutos siguientes a la caída. Uno se lee sentado, el otro de pie. Si intentas que el mismo documento haga las dos cosas, acabas con doce páginas que nadie abre a las 23:40.
El plan manual: seguir facturando a mano no es un fracaso, es el plan
Esta es la pieza que más gente se salta, y la que más dinero salva. Mientras la automatización está caída, el negocio sigue. Los pedidos siguen entrando, los clientes siguen escribiendo y las facturas siguen venciendo. La pregunta no es «¿cuándo lo arreglamos?», es «¿cómo seguimos operando hasta que esté arreglado?».
Hay un reflejo cultural que estorba aquí: volver al proceso manual se vive como una derrota, como admitir que la automatización no valía. Es al revés. Un sistema serio tiene modo degradado; el que no lo tiene no es más automático, es más frágil. Escribe, para cada flujo crítico, la versión a mano del proceso: quién la ejecuta, dónde apunta lo que va haciendo y cuál es el volumen máximo que aguanta antes de que haya que empezar a decir que no.
Esa última parte es la que casi nadie escribe y la que decide el resto: el plan manual tiene un techo. Doce pedidos al día se pueden meter a mano; cuatrocientos no. Saber tu número de antemano cambia la conversación durante la caída, porque convierte «aguantamos» en «aguantamos hasta las dos de la tarde, a partir de ahí paramos de aceptar pedidos web». Y el registro paralelo de lo que se hizo a mano no es burocracia: es lo que hace posible la reconciliación posterior sin duplicar nada, que es un trabajo con su propia mecánica y está desarrollado en recuperar los datos perdidos en una automatización caída.
El postmortem de tres líneas: por qué sin él la misma caída vuelve en marzo
La incidencia termina, todo el mundo respira y nadie escribe nada. Tres meses después vuelve a pasar lo mismo y la persona que lo arregló la primera vez ya no se acuerda de cómo. Ese es el coste real de saltarse el postmortem, y no se paga en el momento: se paga en la repetición.
No hace falta el documento de diez páginas de una empresa de miles de personas. El libro de SRE de Google —donde nació buena parte de esta práctica— insiste en dos cosas que sí escalan hacia abajo: que sea sin culpables, centrado en por qué el sistema permitió el fallo y no en quién lo cometió, y que se pueda empezar con un procedimiento muy básico e ir afinándolo. A tu escala eso son tres líneas, escritas el mismo día, en el sitio donde vive el runbook:
- Qué pasó y desde cuándo. Con hora de inicio real, no de detección. La diferencia entre las dos es, casi siempre, el hallazgo más útil de todo el ejercicio.
- Qué lo arregló. La acción concreta. Esto va directo al apartado de causas conocidas del runbook, y es lo que hace que la segunda vez dure diez minutos en vez de tres horas.
- Qué cambiamos para que no vuelva. Una sola cosa, con dueño y fecha. Si no hay ninguna, escríbelo también: «aceptamos que puede repetirse» es una decisión válida y consciente; «ya veremos» no lo es.
Cuando esas tres líneas se acumulan durante un año, dejas de tener anécdotas y empiezas a tener un mapa: qué flujo se cae más, qué proveedor te ha costado más horas, qué arreglo has aplicado seis veces sin resolver la causa. Ese mapa es lo que convierte el mantenimiento reactivo en mantenimiento de verdad, el que se adelanta.
Qué montar esta semana
Todo lo anterior cabe en una tarde si lo haces en este orden y no intentas hacerlo perfecto: la tabla de tres severidades con tus procesos por nombre; el calendario con un nombre por semana y un canal que suene; el runbook de una página de tus dos flujos más críticos; la versión manual de esos dos procesos con su techo escrito; y el hábito de las tres líneas después de cada caída. Nada de esto requiere herramienta nueva. Requiere que alguien lo decida en frío y lo deje escrito donde se encuentre.
La frontera honesta: esto está pensado para quien tiene unos cuantos flujos y quiere dormir tranquilo sin montar un departamento. Cuando lo que hay debajo son decenas de procesos, varios equipos y agentes que deciden solos, la respuesta a incidencias deja de ser una ficha y pasa a ser una función con turnos, acuerdos de nivel de servicio y su propia mecánica de escalado: eso es gestión de incidencias de agentes de IA. Y si lo que quieres es que las severidades, la guardia, los runbooks y el plan manual queden montados sobre tus flujos actuales y operados por alguien que no eres tú, eso es automatización de operaciones: el día dos, hecho, en vez de una intención escrita en una servilleta.