Cuando se automatiza una parte de una empresa, se añaden comprobaciones automáticas para dormir tranquilo. El problema es que esas comprobaciones son código, y el código tiene fallos — con una diferencia incómoda: cuando falla una comprobación, lo que se rompe es precisamente la capacidad de enterarse de que algo se ha roto.
Una comprobación que no puede fallar no es una comprobación: es una ceremonia.
El primer caso: preguntar por una puerta que no existe
Uno de nuestros servicios internos se despliega con un guion que, al terminar, comprueba que el servicio responde. Esa comprobación consultaba una dirección de estado concreta y esperaba una respuesta correcta.
El detalle: esa dirección no existía en ese servicio. Existía en otro proyecto nuestro, y se copió de allí al escribir el guion. Así que la respuesta era siempre «no encontrado» — estuviera el servicio perfectamente o completamente caído.
Y el guion la daba por buena. Sólo trataba como error la ausencia total de respuesta. Es decir: durante semanas, esa comprobación aprobó todos los despliegues sin haber comprobado absolutamente nada.
Se descubrió el día que el servicio estuvo un cuarto de hora devolviendo un error a quien lo usaba. No lo detectó el guion, que había dicho que todo estaba bien: lo detectó una persona abriendo la página.
La ruta era correcta. En otro proyecto. Esa es exactamente la clase de fallo que ninguna revisión rápida encuentra.
El segundo caso, cuatro días después: aprobar al que ya estaba
En otro despliegue, la construcción de la nueva versión falló. El sistema que la publica hizo entonces lo que hace siempre en ese caso: dejar en pie la versión anterior, que funcionaba.
La comprobación de salud consultó el servicio y recibió una respuesta correcta, porque el servicio estaba correcto. Lo que no estaba era la versión nueva. La comprobación no mentía; simplemente no medía lo que se creía que medía.
Dos despliegues seguidos se dieron por buenos así, sin haber publicado nada. Y se descubrió del mismo modo que el anterior: mirando la pantalla y viendo que el cambio no estaba.
El servidor estaba sano, la aplicación respondía y la versión desplegada era la de antes. Las tres cosas a la vez.
Lo que tienen en común
En los dos casos la comprobación era técnicamente correcta: consultaba algo y recibía una respuesta esperada. El fallo estaba en la distancia entre lo que se preguntaba y lo que se quería saber.
Se preguntaba «¿responde el servidor?» queriendo saber «¿está publicado lo nuevo?». Se preguntaba «¿contesta esta dirección?» queriendo saber «¿funciona el servicio?». Son preguntas distintas, y en la mayoría de los días dan la misma respuesta — por eso el fallo aguanta tanto tiempo sin verse.
Y las dos veces lo detectó una persona mirando, no el sistema. Ésa es la señal de alarma de verdad: si cada vez que aparece un problema lo encuentra alguien de casualidad, las comprobaciones no están comprobando.
La regla que sacamos: hay que ver fallar la alarma
Una comprobación sólo vale si alguien la ha visto ponerse en rojo. Si nunca se ha visto fallar, no se sabe si funciona: se sabe que no ha molestado.
Aplicado en la práctica, significa tres cosas. Primero, comprobar la comprobación: apagar a propósito lo que vigila y confirmar que salta. Segundo, que la señal sea el resultado y no el estado — buscar en la página algo que sólo exista en la versión nueva, en lugar de preguntar si el servidor vive. Y tercero, desconfiar de las respuestas que siempre son iguales: si una comprobación lleva meses en verde y nada ha cambiado nunca, merece una revisión.
En nuestro caso las dos comprobaciones se reescribieron para preguntar lo que importaba, y quedaron documentadas con el fallo que las motivó, para que nadie las «simplifique» y las devuelva a como estaban.
Si nunca has visto sonar una alarma, no sabes si suena.
Por qué esto le importa a quien automatiza
Cuando una empresa conecta un agente a su teléfono o a su WhatsApp, no está comprando sólo el agente: está comprando también el sistema que avisa cuando el agente deja de funcionar. Y ese segundo sistema casi nunca se mira al decidir.
Conviene preguntarlo antes de firmar, y con estas palabras: ¿qué comprobáis exactamente, cada cuánto, y qué pasa cuando falla? Si la respuesta es «monitorizamos el servicio 24/7», la siguiente pregunta es cuándo fue la última vez que esa monitorización avisó de algo real.
Nosotros contamos estos dos casos porque son nuestros y porque son recientes. No los contamos para decir que ya no nos pasará: los contamos porque la única defensa que conocemos contra este tipo de fallo es asumir que las comprobaciones también fallan, y revisarlas con la misma desconfianza con la que se revisa lo que vigilan.