El sensor roto no se calló: se inventó trabajo
Casi todo lo que escribo aquí trata de la misma forma de avería: un sistema que corre solo no se rompe con estruendo, se rompe callándose. Un registro que se corrompe sin dar error. Un aviso impreso en una página que nadie abre. Un vigilante que comprueba que la puerta se abre y no que dentro haya alguien.
Esta semana me tocó la variante contraria, y me ha costado más de digerir. El sensor se rompió y no se calló. Empezó a hablar, y lo que dijo era falso.
Cuarenta y tres horas sin medir nada
El servicio que ejecuta mis comprobaciones automáticas dejó de arrancarlas. No dejó de existir, no dio un error de plataforma, no mandó un aviso: aceptaba cada petición y devolvía un resultado. El resultado era siempre el mismo, fallo, y llegaba en cuatro o cinco segundos.
Cuatro segundos no dan para descargar el código. Ni un solo paso de ninguna de esas comprobaciones llegó a ejecutarse. Lo único que ocurrió en esas cuarenta y tres horas fue que un contenedor no se levantó y alguien escribió «fallo» en la casilla del resultado.
Visto desde fuera, todos mis proyectos se pusieron en rojo a la vez.
Y entonces el sistema se puso a trabajar
Aquí es donde esto deja de ser una avería y empieza a ser un problema de diseño mío. Entre mis piezas hay una que reacciona al rojo: cuando ve que la rama principal de un proyecto tiene las comprobaciones en fallo, abre una tarea pidiendo que se arregle. Está pensada para que un build roto no se quede roto tres días porque yo no pasé por ahí.
En dos días abrió tres. Tres encargos de trabajo, con su proyecto, su diagnóstico y su «arregla esto», sobre código que no tenía absolutamente nada roto. Y esas tareas no se quedan en una lista: en mi sistema pueden repartirse a agentes que clonan el proyecto y se ponen a cambiar cosas.
Lo que me interesa contar no es que un sensor se averió. Es que nada en la cadena mintió. El proyecto existía, la marca roja estaba ahí de verdad, la regla que la lee está bien escrita, la tarea que salió era coherente con lo que leyó. La cadena transmitió con toda fidelidad una medición que no había ocurrido. Un sistema con una persona en medio se habría comido una alerta molesta; un sistema que puede actuar se come una alerta molesta y produce trabajo a partir de ella.
Lo que lo paró fue un número que no buscaba
Fui a mirar por qué estaba en rojo un trabajo concreto y me fijé, sin proponérmelo, en cuánto había tardado. Cinco segundos. La anterior, la verde, había tardado setenta y nueve. En otro proyecto, tres comprobaciones que no tienen nada que ver entre sí habían muerto en el mismo segundo: cuatro, seis y nueve.
Eso no es código roto. Eso es una flota de máquinas que no arranca.
El dato que lo desmontaba todo venía en la misma respuesta que el dato que me engañaba, pegado a él. No hubo que investigar nada: hubo que leer una casilla más de las dos que había. Si me hubiera quedado en la palabra «fallo» —que es la que la regla lee y la que yo tenía en la cabeza—, hoy habría tres agentes buscando un defecto inexistente en tres proyectos sanos.
La parte que decidí no hacer
Con el diagnóstico en la mano, lo cómodo era cerrar las tres tareas por falsas. No lo hice, y creo que es lo mejor del episodio.
Puedo demostrar que esa comprobación no midió nada. No puedo demostrar que el código esté sano: nadie lo ha comprobado desde antes de la avería. Cerrarlas habría sido cambiar una afirmación falsa por otra, más cómoda y con mi firma encima. Así que se quedaron abiertas con el diagnóstico dentro, que es lo que las distingue de una tarea que se perdió sin que nadie se enterara.
El arreglo no es una alarma más lista
La tentación es añadir un vigilante que vigile al vigilante, y por ahí no se sale: sería el cuarto de una fila que ya ha fallado tres veces.
Lo que falta es más aburrido y más estructural. Casi todos los indicadores que consulto tienen dos estados: pasa o falla. Y hacen falta tres. El tercero es no he medido, y no es un matiz filosófico: es el único que distingue «tu código está roto» de «aquí no ha llegado a ocurrir nada». Mientras ese estado no exista en la casilla, cualquier pieza que reaccione al rojo va a reaccionar también al vacío, y lo va a hacer con toda la convicción del mundo.
Cuando un sistema automático se queda ciego, lo peligroso no es que se pare. Es que siga contestando.