Un tiempo de espera no es un botón de parada

Todo comando remoto necesita un plazo. Esa parte no es discutible: un proceso que puede esperar para siempre acabará esperando para siempre, y una sola petición atascada retendrá un trabajador, una conexión y una fila de la cola hasta que alguien reinicie algo.

Lo que resulta mucho menos evidente es qué hace realmente ese plazo. Termina la espera del lado propio. No termina, en el caso general, el trabajo del otro lado. Todo lo difícil de las operaciones largas vive en esa distancia.

Ejecutamos un agente en los hipervisores de los clientes y le enviamos comandos. La copia de seguridad de una máquina virtual es el comando que nos obligó a tomarnos en serio esa distancia, porque una copia puede tardar honestamente una hora, y una hora es justo donde están nuestros propios límites.

El límite no es una preferencia

Nuestro agente recorta todo plazo de comando a una hora. La plataforma puede pedir más; no lo va a obtener. El recorte es un único min() sobre el valor que llega en la petición, con el cero interpretado como «sin definir» y un valor de reserva de dos minutos cuando el campo falta.

Ese recorte tiene una consecuencia que se pasa por alto al fijar tiempos de espera en un fichero de configuración. Si la plataforma cree en un plazo en el que el agente no cree, hay dos sistemas que discrepan sobre cuándo un comando está muerto, y la discrepancia aparece con el peor síntoma posible: el agente se rinde, informa y sigue adelante, mientras la plataforma mantiene la fila abierta esperando una respuesta que nunca llegará con la forma que espera.

Así que la regla a la que llegamos es aburrida y merece escribirse igualmente. Todo tiempo de espera del lado de la plataforma se elige con el techo del agente presente en la sala. Nuestros plazos de copia y de restauración son de una hora precisamente porque ese es el techo, y de varias docenas de plazos de comando son los dos únicos que lo tocan.

Los plazos no son una cuestión de estilo

Esto es lo que son en realidad nuestros plazos de comando, y por qué cada uno es el que es.

Dos de esas filas son historias más que números.

La de la máquina en la nube caía antes al valor por defecto de dos minutos. Dos minutos bastan para una imagen que resulta estar al día, y no bastan para nada más, así que la plataforma informaba de un fallo mientras la instalación dentro de la máquina seguía y terminaba unos minutos después. El pedido quedaba marcado como fallido. La máquina estaba funcionando. Ese es el peor tipo de error: no un fallo, una contradicción, y quien tiene que resolverla es el cliente.

La de la migración es el plazo más largo que no es el techo del agente, y el razonamiento que hay detrás es un recuento y no una sensación. El migrador hace una llamada de API por usuario y una por servidor contra el panel de destino. Con mil servidores eso son mil llamadas de ida y mil respuestas de vuelta, con una lectura completa de ambos lados antes y un recuento después.

Los costes de equivocarse no son simétricos

Este es el principio que hay debajo de las dos historias. Un plazo demasiado corto y un plazo demasiado largo fallan de maneras completamente distintas, y tratarlos como dos lados del mismo mando da el número equivocado siempre.

Demasiado largo: una operación que ha muerto de verdad mantiene una fila abierta un rato más. Alguien espera. Nada se corrompe, nada se duplica, y la limpieza posterior no tiene historia.

Demasiado corto: se registra un fallo para un trabajo que salió bien. Ahora los registros y la realidad discrepan, y todo camino de recuperación que exista (reintentar, recrear, devolver el dinero, alertar) apunta a un problema que no existe y creará un segundo.

No son igual de malos, así que no deberían recibir márgenes del mismo tamaño. Para cualquier cosa que cree, mueva o borre recursos reales, tomamos el lado generoso a propósito y escribimos por qué.

Dos relojes que arrancan en momentos distintos

Hay una sutileza en cualquier sistema de comandos en cola que es fácil pasar por alto y fácil de medir. Nuestra plataforma calcula el plazo como un momento absoluto, en el instante en que se escribe la fila del comando. El agente calcula el suyo como una duración, que empieza cuando comienza a ejecutar.

Son relojes distintos. Si el agente está desconectado, u ocupado, o el comando pasa treinta segundos en la cola, la plataforma ya ha gastado treinta segundos de su presupuesto y el agente no. La plataforma se rinde primero.

Ese es el orden correcto, y merece la pena decir en voz alta por qué. El plazo de la plataforma responde a la pregunta que hace realmente el cliente: ¿cuánto ha pasado desde que hice clic? El del agente responde a otra distinta: ¿cuánto puede durar este trabajo? El tiempo de reloj desde el clic es el número del que trata una conversación de soporte. Igualar los dos números quedaría más limpio y respondería a la pregunta equivocada.

Ahí dentro se esconde también un tercer reloj. En nuestro agente, la espera de un permiso de concurrencia ocurre fuera del plazo de ejecución. Un comando encolado detrás de otro contra la misma integración no quema su propio presupuesto mientras espera. Si los plazos son ajustados, conviene revisar cuál de los relojes incluye la cola; la respuesta rara vez es la que está en la documentación.

Lo que el plazo cancela en realidad

Cuando expira el plazo del agente, este señala la cancelación y deja de esperar. Lo que alcanza esa cancelación es el código propio: el bucle de sondeo que preguntaba al hipervisor cómo iba la tarea.

No alcanza al hipervisor. La copia sigue en marcha. Terminará, o fallará, enteramente sin nosotros. Nada de la cancelación viajó hasta la cabina de discos.

Esto no es una limitación que haya que eliminar con ingeniería. Es la forma honesta del problema, y lo útil es registrar el resultado con verdad en lugar de fingir. La taxonomía que sobrevivió al contacto con producción tiene tres desenlaces y no dos.

• Fallido. Sabemos que no ocurrió nada. El cliente puede reintentar y no hay nada que limpiar.
• Desconocido. Dejamos de escuchar antes de que hubiera respuesta. Puede que algo exista.
• Necesita conciliación. Tenemos motivos positivos para pensar que existe algo de lo que no podemos dar cuenta.

Una restauración que agota el plazo es el caso más afilado. Puede que ahora haya una máquina funcionando en el hipervisor para la que nuestra base de datos no tiene fila. Marcarla como fallida sería una mentira que esconde una máquina; marcarla como correcta sería una mentira que inventa otra. Queda marcada como pendiente de revisión, y el panel pide al cliente que lo compruebe en lugar de ofrecerle un botón de reintento que construiría una segunda máquina al lado de la primera.

Esa regla está en el código como una lista de los casos ciertos, no de los inciertos. Cuatro códigos de error concretos significan que el trabajo nunca empezó, porque los cuatro vienen de comprobaciones que el agente hace antes de la primera llamada. Todo lo demás, incluido cualquier código de error que añadamos después y olvidemos clasificar, cae por defecto en incierto. La dirección importa: un código olvidado que se anota en silencio como fallo hace desaparecer de los registros una máquina que existe, y un código olvidado que se anota como incierto solo le cuesta a alguien una revisión.

Un resultado incierto necesita una manera de volverse cierto

Un estado que significa «alguien debería revisarlo» solo es honesto si alguien, o algo, revisa de verdad. El nuestro es un trabajador que pide periódicamente a cada máquina con historial de copias que vuelva a listar sus puntos de restauración, de modo que un archivo que desapareció en silencio en el proveedor se convierte en una notificación y no en una lista que se acortó el día en que un cliente resultó mirarla.

Sobre ese bucle hay una restricción deliberada de coste, porque cada listado es un comando que se ejecuta en el host de otra persona. Solo visita máquinas que tienen una política o al menos un punto de restauración conocido, y toma un lote acotado por ronda. Cuando eso deje de bastar, el arreglo correcto es un cursor, no un número mayor.

El bucle también tiene que sobrevivir a que dos servidores propios decidan ejecutarlo en el mismo segundo. Eso se resuelve con una clave de idempotencia duradera formada por la máquina y el número de ventana, no por una marca de tiempo: dos servidores nunca laten en el mismo milisegundo, pero seguro que están dentro de la misma ventana de seis horas, así que una marca de tiempo no eliminaría ningún duplicado.

Lo que recomendaríamos escribir

Si hay que elegir plazos para trabajo remoto, cuatro preguntas llevan casi todo el camino.

1. 01¿Cuál es el techo duro y quién lo impone? Si dos componentes discrepan, en la práctica gana el menor y el mayor es ficción.
2. 02¿Cuándo arranca cada reloj? El tiempo en cola está dentro del presupuesto o no lo está, y ambas respuestas son defendibles. No saberlo no lo es.
3. 03¿Qué cancela la expiración? Si la respuesta es «nuestra propia espera», conviene decirlo en voz alta, porque el resto del diseño se deriva de ahí.
4. 04¿De qué lado cae un desenlace sin clasificar? Que la incertidumbre sea el valor por defecto, y que la certeza sea lo que hay que escribir.

Nada de esto acorta una copia de seguridad larga. Hace que su registro sea verdadero, que es la parte que se lee a las dos de la madrugada.