Tu automatización se detuvo. ¿Cuándo lo vas a saber?
Quien descubre que la automatización se detuvo suele ser el cliente que llamó a reclamar. La rutina no avisa cuando falla, simplemente deja de correr, y el silencio se parece al funcionamiento normal. Hacer que la operación avise es una decisión de arquitectura, no la compra de una herramienta de monitoreo.
¿Por qué la falla silenciosa es el estado normal de una automatización?
Porque el error que aparece en pantalla tiene a una persona mirándolo, y el error que ocurre a las tres de la mañana no. Esa es toda la diferencia.
Cuando un usuario hace clic y la pantalla se traba, hay alguien incómodo y un ticket abierto en minutos. Cuando la rutina nocturna que empuja pedidos del portal al ERP falla, no hay nadie en la escena. El síntoma es un número un poco menor al día siguiente, y un número menor siempre encuentra una explicación plausible.
El problema es más viejo y más estructural que tu operación. Yuan y colegas estudiaron 198 fallas reales reportadas por usuarios en cinco sistemas de datos de uso amplio, entre ellos Cassandra, HDFS y Redis, y publicaron el resultado en OSDI 2014. En el 92% de las fallas catastróficas, la causa fue el tratamiento incorrecto de un error no fatal que el propio software ya había detectado y señalado.
Vale releer la frase, porque desarma la intuición habitual. El error se vio. Simplemente no llegó a nadie.
El siguiente hallazgo es peor. En el 35% de las fallas catastróficas, el código que debía tratar el error caía en tres patrones triviales, entre ellos estar vacío o contener solo una línea de log. Un log que nadie lee es silencio con fecha. Los autores calculan además que una prueba simple del propio tratamiento de error habría atrapado el 58% de esas fallas catastróficas.
El estudio es de 2014 y trata de software de infraestructura, no de tu integración de pedidos. La lógica es la misma cada vez que alguien decide qué hace el programa cuando el otro lado no responde, y ese alguien no es quien va a sentir la consecuencia.
¿Qué cosas de tu operación tienen fecha de vencimiento?
Más de las que están anotadas en algún lugar con dueño. Certificados digitales, claves de API, tokens de acceso, contraseñas de servicio, contratos de proveedor y la tarjeta que paga la suscripción de la herramienta.
El certificado que sostiene el enlace entre dos sistemas es el que se acortó más rápido. El CA/Browser Forum, donde emisores de certificados y fabricantes de navegadores definen estas reglas, aprobó el 11 de abril de 2025 la reducción progresiva del plazo, con 25 votos a favor, ninguno en contra y 5 abstenciones entre los emisores, y 4 a cero entre los navegadores. Según la tabla de fechas del propio documento normativo, el máximo bajó de 398 a 200 días el 15 de marzo de 2026, pasa a 100 días el 15 de marzo de 2027 y a 47 días el 15 de marzo de 2029.
La misma tabla acorta un segundo reloj que casi nadie mira. El período de reutilización de los datos de validación de dominio baja a 200 días en 2026, a 100 en 2027 y a 10 en 2029, así que la verificación detrás del certificado también hay que rehacerla más seguido.
Una tarea al año se volvió dos, después casi cuatro, y en 2029 serán cerca de ocho. En el mismo período el recordatorio se apagó. Let's Encrypt terminó su servicio de aviso de vencimiento por correo el 4 de junio de 2025, citando, entre otros motivos, que muchos suscriptores ya automatizaron la renovación.
El argumento es correcto para quien automatizó. Para quien dependía de ese correo, la alarma salió del aire nueve meses antes de que la tarea duplicara su frecuencia.
¿Cuánto tiempo sigue el reporte contando una ganancia que ya se detuvo?
Hasta que alguien revise la ejecución, y esa revisión no está en el calendario de nadie. El caso de negocio se aprobó con una cuenta de horas por corrida por corridas al mes, y esa cuenta sigue produciendo un número en la planilla mucho después de que la rutina murió.
La distorsión es doble. La ganancia sigue reportada en su valor completo y el retrabajo manual que volvió aparece diluido en la nómina, sin nombre propio. Esto es razonamiento sobre la mecánica del indicador, no una medición de campo, y es una de las razones por las que el retorno de una automatización se mide en el flujo y no en la estimación de aprobación.
Vale un ejemplo, y es una hipótesis: los datos de abajo son ilustrativos y no describen a ningún cliente. Una distribuidora de porte medio conecta su portal de pedidos al ERP, de modo que el pedido cargado en el portal crea el pedido correspondiente en el ERP cada quince minutos. El proveedor del portal cambia el formato de un campo de fecha. La rutina empieza a fallar solo en los pedidos con entrega programada y sigue funcionando en todo lo demás.
Nadie se da cuenta. La caída de volumen cabe dentro de la variación normal del mes, y el equipo resuelve el problema en su propio nivel: vuelve a cargar esos pedidos a mano, porque es más rápido que abrir un ticket. La automatización está muerta en una porción del flujo, el reporte muestra la ganancia entera y el equipo absorbió la diferencia sin contárselo a nadie.
Mira la forma de esa falla. La parada total se convierte en reclamo en horas. La falla parcial cabe dentro de la variación normal y sobrevive meses.
¿Qué hace que la operación avise cuando algo se detiene?
Cuatro decisiones, todas anteriores a la elección de cualquier herramienta.
La primera es la señal de vida. La rutina tiene que registrar que corrió, y no solo gritar cuando falla, porque la rutina que murió no grita. Si el registro de ejecución no llega dentro de la ventana esperada, eso es la alarma. La ausencia de noticias pasa a ser noticia.
La segunda es el conteo en ambos extremos. Cuántos pedidos salieron del portal y cuántos entraron al ERP en el mismo período. Esa comparación no depende de que el error haya sido tratado correctamente allí adentro, y es la que atrapa la falla parcial del ejemplo anterior.
La tercera es el inventario de vencimientos con dueño. Una lista de cada enlace, con qué vence, cuándo vence y quién responde por él. Mientras esa fecha viva en el correo de quien configuró la integración, se va de la empresa junto con esa persona. Es el mismo hábito que sostiene documentar y versionar automatizaciones, aplicado al plazo de validez.
La cuarta es el destino del error. Todo error necesita una dirección humana y una acción esperada, si no vuelve a ser una línea de log. Definirlo es decidir a quién se llama, en cuánto tiempo y qué puede hacer esa persona por su cuenta. La falta de esa definición es una de las fallas que comprometen las integraciones internas.
Ninguna de las cuatro es la compra de software de monitoreo. Monitorear el servidor responde si la máquina está de pie. La pregunta del negocio es otra: si el pedido llegó del otro lado. Ninguna herramienta responde eso sin que alguien haya definido antes qué debería haber llegado. UniTrust, IMO de seguros de EE. UU., gestiona pólizas, agentes y comisiones desde 2022 y Reatop registra residuos hospitalarios en campo, con uso offline y sincronización posterior. En operaciones así el diseño empieza por la misma pregunta: cómo prueba el sistema que el registro llegó.
Preguntas frecuentes
¿La implementación no va a consumir demasiado tiempo de mi equipo?
Tres de las cuatro decisiones son diseño, no construcción. Definir quién recibe el error, qué tiene que cuadrar entre los dos extremos y quién responde por cada vencimiento es trabajo de reunión. Lo que se vuelve código son dos ítems, el registro de ejecución y el conteo comparado, y ninguno exige tocar la lógica de la integración que ya está en pie.
¿Cómo mido el resultado de una alarma, si solo sirve para avisar que algo se detuvo?
Con dos números que tu operación ya puede contar. El tiempo entre la parada y el descubrimiento, y cuántos casos descubrió el sistema en lugar del cliente. Si el segundo número no mejora después del cambio, el diseño está mal, y esa también es una respuesta útil.
¿Esto no es solo un tablero más que nadie va a abrir?
Lo sería, si la salida fuera un tablero. Un tablero depende de que alguien se acuerde de abrirlo, y la falla silenciosa ocurre justamente cuando nadie se acordó. Lo que cambia la operación es el camino inverso: la discrepancia sale a buscar a una persona con nombre, con plazo y con atribuciones para actuar.
El siguiente paso
Si hoy no puedes decir cuántos enlaces tiene tu operación y cuál de ellos avisa cuando se detiene, el Diagnóstico de Arquitectura Operacional es una conversación de 30 minutos para mapearlo: agenda la conversación.
Cases relacionados
¿Reconociste tu operación en este artículo?
Agenda el Diagnóstico de Arquitectura Operacional: 30 minutos para mapear dónde está el cuello de botella de tu operación. Sin propuesta en la primera conversación.
Agendar diagnóstico