Un sistema que se cae es un problema pequeño: alguien lo nota en minutos y se arregla. Un sistema que sigue funcionando, contesta con normalidad y no hace su trabajo puede estar así durante días. Esto es lo que nos pasó con nuestro propio asistente, contado con fechas, porque es el fallo que más miedo debería dar a cualquiera que automatice una parte de su empresa.
«Hoy no tienes nada» y «no he podido mirar» son la misma frase para quien la lee. Sólo una de las dos es verdad.
Lo que ocurrió
Nuestro asistente interno envía cada mañana un parte a cada persona del equipo comercial: los avisos del día, las tareas vencidas, las oportunidades que llevan tiempo paradas. Es una rutina pequeña y bastante querida, de esas que sólo se notan cuando faltan.
Entre el 17 y el 24 de agosto no envió ni un solo mensaje. Siete días. Y durante esos siete días el sistema estuvo funcionando con normalidad: la aplicación respondía, la tarea programada se ejecutaba a su hora, y ninguna comprobación se puso en rojo.
El motivo era una restricción de acceso a los datos. Nuestra base separa la información de cada empresa, y las consultas que no declaran de qué empresa hablan no reciben un error: reciben una lista vacía. Es un comportamiento correcto y deliberado — pero significa que un fallo de configuración y un día sin trabajo pendiente se ven exactamente igual.
Así que el asistente miraba, no encontraba nada, y hacía lo razonable: no molestar a nadie. Todas las mañanas.
No falló. Hizo bien su trabajo sobre una realidad que no era la real.
La mitad ruidosa se arregló; la muda siguió una semana más
Lo interesante es que el sistema sí protestó, pero sólo por la mitad del problema.
El asistente hace dos cosas con cada persona: leer lo que tiene pendiente y apuntar que ya le ha avisado. La primera es una consulta de lectura; la segunda, de escritura. Con la configuración mal puesta, la escritura fallaba con un error claro que quedaba registrado, y la lectura devolvía cero en silencio.
El error de escritura se apuntó decenas de veces en el registro. Nadie lo leyó, porque un registro al que nadie mira no es un aviso. Y la lectura vacía ni siquiera dejó rastro: no hay nada que registrar cuando la respuesta es «no hay nada».
Cuando se corrigió el primer sitio donde faltaba la declaración de empresa, pareció resuelto. No lo estaba: lo que se hace con cada persona pasaba por otras consultas distintas, y ésas siguieron devolviendo cero una semana más.
El fallo ruidoso se arregla en una tarde. El mudo sobrevive a su propia corrección.
Por qué las comprobaciones no lo vieron
Teníamos casi dos mil pruebas automáticas en verde. Ninguna cazó esto, y no por descuido: las pruebas se ejecutan con permisos de administración, y a un administrador esa separación de datos no se le aplica. Es decir, el entorno donde comprobamos que todo funciona es precisamente el único donde ese fallo no puede ocurrir.
La tarea programada tampoco avisó. Terminaba correctamente — recorría una lista vacía, no tenía nada que hacer y salía con éxito. Desde fuera, un día sin trabajo y un día sin poder ver el trabajo son indistinguibles.
Y la comprobación de salud del servidor decía que todo estaba bien, porque todo estaba bien: la máquina, la base de datos y la aplicación funcionaban perfectamente. Lo único que no ocurría era el trabajo.
La pregunta que lo habría cazado en dos segundos
Todas nuestras comprobaciones preguntaban por el proceso: ¿está el servicio en pie?, ¿ha terminado la tarea?, ¿hay errores? Ninguna preguntaba por el resultado.
La pregunta que faltaba era mucho más simple: ¿cuándo fue la última vez que este asistente escribió a alguien?
Esa respuesta estaba en nuestra propia base de datos desde el primer día del silencio. Cualquiera que la hubiera consultado el martes por la mañana habría visto que el último mensaje era del lunes anterior. Nadie la consultó, porque a nadie se le ocurre preguntar por algo que se da por hecho.
Vigilar que un proceso se ejecuta no es vigilar que hace su trabajo. Son dos preguntas distintas y sólo la segunda importa.
Qué cambiamos
Lo primero, la causa: la declaración de empresa dejó de estar en cada tarea suelta y pasó al sitio único por el que pasan todas. Poner esa línea en cada comando funciona hasta que alguien escribe el comando número veintidós y se olvida.
Lo segundo, y más importante: el punto por donde pasan todas esas consultas ahora deja constancia cuando alguien pregunta sin decir de qué empresa habla. Avisa y no revienta — esto corre con clientes detrás, y cambiar un fallo mudo por una caída es cambiar un problema por otro.
Y lo tercero, la vigilancia que faltaba: comprobar el resultado. No «¿se ejecutó la tarea?», sino «¿cuánta gente debía recibir su parte hoy y cuánta lo recibió?». Esa diferencia es la única que habría sonado el martes 18 por la mañana.
Por qué contamos esto
Porque es exactamente el riesgo de automatizar una parte de una empresa, y no el que se suele contar. El miedo habitual es que el sistema se equivoque de forma escandalosa: que le diga una barbaridad a un cliente. Eso pasa, se ve enseguida y se corrige.
El riesgo real es el contrario: que deje de hacer algo y nadie lo note, porque su silencio es idéntico a un día tranquilo. Un recordatorio que no sale, un aviso que no llega, un seguimiento que no se hace. Todo eso, visto desde fuera, se parece muchísimo a que no había nada que hacer.
Por eso, cuando alguien nos pregunta qué garantías damos, la respuesta no es que nuestros agentes no fallen. Es que cuando fallen, alguien se entere. Que el sistema tenga quien lo mire desde fuera, y que lo que se mire sea el resultado y no el estado del servidor.
Si está valorando automatizar cualquier parte de su operación, con nosotros o con quien sea, hay una pregunta que conviene hacer antes de firmar: si esto deja de funcionar un martes, ¿quién se entera, y cuándo?
Un sistema que sólo funciona cuando su parte lista funciona no tiene red.