Cualquier automatización se puede hacer funcionar una vez, en condiciones ideales, con datos de entrada limpios y todos los servicios conectados respondiendo con normalidad. La diferencia entre eso y algo en lo que un negocio puede confiar realmente está por completo en cómo se comporta cuando aparece una condición para la que no estaba preparada, que es cuestión de cuándo, no de si. La mayoría de fallos de automatización que de verdad le cuestan dinero a un negocio se deben a esta diferencia, no a que la lógica principal esté mal.
Manejo de errores: qué pasa cuando algo no sale según lo previsto
Un campo que falta, un formato de datos inesperado, un servicio conectado que está temporalmente caído, todo esto acabará pasando tarde o temprano en cualquier automatización que se ejecute con suficiente frecuencia. Sin un manejo explícito, el fallo típico es que la automatización se cuelgue en silencio o, peor, que siga funcionando con datos incorrectos y produzca un resultado erróneo que a simple vista parece correcto. Manejo explícito de errores significa decidir de antemano qué debería pasar en cada uno de estos casos: saltar el registro y marcarlo, reintentar tras una espera, o detenerse y avisar a alguien, en vez de dejar el comportamiento al azar.
Registro (logging): poder reconstruir qué pasó de verdad
Cuando algo sale mal tres semanas después de lanzar una automatización, la pregunta nunca es solo "¿está rota?", es "¿qué pasó exactamente, y cuándo empezó?". Un registro que anota qué se ejecutó, cuándo, con qué datos de entrada, y cuál fue el resultado, convierte esa investigación de un ejercicio de adivinanza en una simple consulta. Las automatizaciones sin registro suelen acabar reconstruyéndose desde cero cuando algo se rompe, porque no hay forma de rastrear qué salió mal de verdad.
Alertas: enterarse al instante, no una semana después
Los fallos de automatización más caros no son los que se rompen de forma ruidosa, son los que fallan en silencio y solo se notan cuando alguien por fin revisa un informe y lo encuentra vacío, a veces semanas después de que empezara el fallo. Una alerta que salta en el momento en que algo se rompe, aunque sea un simple email o notificación de Slack, suele ser la incorporación de mayor impacto en cualquier automatización, barata de añadir y desproporcionadamente valiosa cuando finalmente algo falla.
Una checklist mínima de fiabilidad
- Cada llamada externa (API, base de datos, webhook) tiene un manejo explícito para el fallo o el timeout, no solo para el camino de éxito
- Existe un registro en algún sitio que anota qué se ejecutó y cuándo, aunque sea una simple hoja de cálculo para automatizaciones más pequeñas
- Hay al menos una alerta configurada para el fallo total, aunque una monitorización más matizada llegue después
- Alguien concreto es responsable de responder a esa alerta, porque una alerta que nadie vigila es funcionalmente lo mismo que no tener ninguna
Por qué merece la pena el tiempo extra de configuración
Saltarse el manejo de errores y la monitorización hace que una automatización se construya más rápido al principio y salga considerablemente más cara a lo largo de su vida real, una vez que se cuenta el coste de un fallo que corre sin detectarse durante semanas. Esta es exactamente la razón por la que una automatización fiable tarda notablemente más en construirse bien que una versión de demo rápida, y por qué ese tiempo extra casi nunca se desperdicia.
La pregunta que merece la pena hacerse antes de construir nada
Antes de configurar un solo disparador o acción, merece la pena preguntarse cuál sería el coste real de un fallo silencioso para este proceso en concreto. Una automatización de newsletter que falla en silencio durante una semana es una molestia. Una automatización de conciliación de pagos o notificación a clientes que falla en silencio durante una semana puede ser un problema genuinamente serio. Esa respuesta debería determinar cuánto tiempo se invierte en manejo de errores y monitorización, en vez de aplicar el mismo enfoque ligero a cada automatización sin importar lo que realmente esté en juego.