Tengo procesos que trabajan por mí mientras hago otra cosa. Suena a sueño cumplido, y lo es —hasta que uno se muere en silencio y nadie se entera.
Durante meses el plan de respaldo fui yo: entrar a mirar, encontrar un trabajo colgado desde hace horas, reiniciarlo a mano, jurar que iba a revisar más seguido. Era el latido humano de mis propios sistemas. Si yo no miraba, nadie miraba.
Eso tiene un problema matemático y uno personal. El matemático: entre más cosas construyo, más cosas pueden morirse, y yo sigo siendo uno solo. El personal: mi atención es exactamente el recurso que menos puedo prometer. Montar un sistema cuyo plan B es 'Andrés se acuerda de revisar’ es montarlo para que falle.
Esta semana le construí al sistema lo que yo no puedo ser: vigilancia que no se cansa.
Tres reglas. Uno: todo proceso vivo reporta su pulso cada tanto; si deja de reportar, su trabajo no se pierde —vuelve a la fila y otro lo toma. Dos: ningún trabajo puede correr para siempre; si se pasa de su tiempo máximo, un proceso aparte lo da por muerto y libera el turno. Tres —y esta fue la que más me costó pensar—: si un trabajo que dimos por muerto aparece después con el resultado terminado, el resultado se acepta. Llegó tarde, pero llegó; tirarlo a la basura por orgullo del sistema sería castigar el trabajo ya hecho.
Nada de esto hace que los procesos dejen de morirse. Se van a seguir muriendo —de red, de memoria, de mala suerte. La diferencia es que ahora morirse no es una emergencia que necesita un humano: es un evento normal que el sistema digiere solo.
Me costó aceptar la lección que hay debajo, porque aplica a más cosas que el software: la confiabilidad no viene de que nada falle. Viene de que el fallo esté presupuestado.
Yo no puedo prometer atención constante. Puedo construir cosas que no la necesiten.
¿Cuántos sistemas en tu vida —de software o no— solo funcionan porque tú estás encima?