“Todo bien” y “no pude revisar” no son la misma respuesta

Un control tiene tres respuestas posibles: todo está bien, algo anda mal, o no pude revisar. Casi todos los sistemas están hechos para distinguir las dos primeras. La tercera suele quedar archivada como “bien”, y ahí empiezan los problemas.

En una semana de revisión de una herramienta de gestión de ventas que construimos, encontramos tres controles que hacían justo eso. Ninguno había dado nunca un error. Los tres se veían sanos en todos los tableros.

El control nocturno que se había detenido

Cada noche el producto revisa los datos de cada cliente en busca de cosas que necesitan atención. Su registro de ejecuciones simplemente terminaba, semanas atrás. Nadie lo notó.

La razón es la parte útil. Cuando el control no lograba identificar qué cuenta estaba revisando, devolvía una lista vacía. Una lista vacía significa “no se encontraron problemas”. Así que la tarea reportó éxito, el monitoreo registró un éxito, y la página que muestra los resultados enseñaba una lista que se cortaba, sin nada al lado que dijera por qué.

El control de versiones que lo aprobaba todo

Antes de cada publicación, un control confirma que las pruebas automáticas pasaron para la versión exacta que se va a publicar. Le pide los resultados a otro servicio. La credencial que usaba para pedirlos había vencido, así que todas las consultas fallaban.

El control se había escrito para dejar pasar la publicación cuando no obtenía respuesta. El razonamiento era justo: un control que bloquea publicaciones por sus propios problemas de conexión enseña a la gente a saltárselo. El resultado fue un control que no podía decir que no. Aprobó cada publicación sin leer un solo resultado de pruebas.

El registro que nunca se escribió

El producto lleva una bitácora de cada cambio en los datos de un cliente: quién hizo qué, sobre cuál registro y cuándo. Es lo primero que pide ver una revisión de seguridad. Varias acciones no escribían en ella, entre ellas el momento en que se guarda la conexión de un cliente con sus otros sistemas.

Agregar las líneas que faltaban no habría bastado. La bitácora identifica la cuenta viendo quién tiene la sesión abierta, y en una tarea nocturna o en un aviso que llega de otro sistema, nadie la tiene. La escritura habría fallado sin hacer ruido, y el código se habría leído como si el registro estuviera ahí.

Además habría pasado las pruebas. En el ambiente de pruebas no hay inicio de sesión, así que ahí la escritura funciona. La falla solo existe en producción.

Lo que tenían en común

Los tres fallaban hacia “todo en orden”. Para cualquier cosa que solo vigila errores, un control que no encontró nada y uno que nunca miró son idénticos. El monitoreo no puede ver un problema que se reporta a sí mismo como éxito.

No fueron decisiones descuidadas. Devolver una lista vacía cuando no hay nada que listar es código normal. Dejar pasar una publicación cuando un servicio de estado está caído es una decisión razonable. Cada una tenía sentido donde se tomó. Juntas produjeron un sistema que habría seguido en verde frente a casi cualquier cosa.

Qué cambiamos

• Un control que no puede ver ahora lo dice. “No pude revisar” es un resultado propio, distinto de “no encontré nada”, y cuenta como falla de la tarea.
• Una tarea que falla levanta una alerta, no una línea en un archivo que a alguien se le tiene que ocurrir abrir.
• El control de versiones se niega cuando no puede confirmar. Saltárselo exige una razón por escrito, y la razón queda registrada. No hay un ajuste que se active una vez y se olvide.
• La compilación falla si alguien agrega una acción que cambia datos sin registrarla. La próxima no puede pasar inadvertida como estas.
• “Las pruebas pasan” ya no se acepta por sí solo en nada que corra sin un usuario con sesión abierta. Esos caminos se ejecutan de verdad y se lee lo que dejaron.

También descubrimos que nuestra primera búsqueda de acciones sin registro había sido demasiado estrecha. Buscaba un tipo de solicitud, y las tareas programadas y los enlaces del navegador son de otro tipo, así que eran invisibles para ella. Al ampliarla aparecieron más. El control de tus controles merece la misma sospecha que los controles.

Cómo buscar esto en tus propios sistemas

• Pídele a cada control su última ejecución, con fecha. Un control sin un “corrió por última vez” visible no se distingue de uno muerto.
• Alerta ante el silencio. Si una tarea nocturna no ha reportado en la mañana, esa es la alarma. No esperes a que reporte una falla que tal vez no esté viva para reportar.
• Hazlo fallar a propósito. Ponle un problema conocido delante y mira cómo se queja. Un control que nadie ha visto fallar es una esperanza. Hacemos lo mismo con las alertas: las verificamos contra un caso del que conocemos la respuesta correcta.
• Decide qué pasa cuando no puede revisar. En todo lo que protege a clientes o dinero, lo seguro es detenerse y preguntarle a una persona.
• Desconfía de la calma larga. Semanas de cero hallazgos en un control sobre datos reales son una muy buena noticia o ninguna noticia.

Por qué importa más con IA en el producto

Una función de IA agrega más lugares donde una respuesta vacía o verosímil puede ocupar el lugar de una real: un modelo que no devuelve nada, una fuente que no se pudo leer, un paso que se saltó. En nuestro método, la etapa de Confianza existe para esto. Antes de que alguien actúe sobre un número, el sistema tiene que poder decir de dónde salió y si de verdad miró.

También es parte de lo que un prototipo se salta. Una demo solo tiene que funcionar cuando todo responde. Un producto tiene que avisarte cuando algo no respondió.

Mira cómo construimos IA con tus datos