Retroceso: cuando el parche rompe algo

Un plan de retroceso responde, antes de tocar nada, tres preguntas: a qué punto se vuelve (una instantánea de la máquina, una copia de seguridad, el paquete anterior), con qué criterio se decide volver y quién lo decide. Escrito de antemano, esas respuestas se aplican con la cabeza fría. Escrito durante la ventana, a medianoche y con el equipo cansado, se vuelve una discusión.

El punto de retorno se toma al principio de la ventana, antes de aplicar el parche, no después de que algo haya salido mal. Abre plan_retroceso: cada sistema tiene su fila.

El criterio de retroceso debe ser objetivo y llevar un tiempo: «si la verificación funcional falla y no se corrige en 30 minutos, se vuelve atrás». La condición se puede comprobar y el tiempo evita dos fallos opuestos: retroceder al primer síntoma sin dar oportunidad a una corrección simple, o seguir empeñado en arreglarlo hasta que se acaba la ventana y no queda margen para volver.

El plan también dice quién decide, para que no haya cinco personas opinando. Quien decide no es necesariamente quien sabe más del sistema; es quien responde de la ventana.

El punto de retorno es lo que permite volver: una referencia concreta a una instantánea o copia, creada antes del cambio. Sin identificador no se sabe a qué se vuelve, y un retroceso sin punto de retorno es una reconstrucción, que dura horas y no minutos.

En la bitácora de la ventana de servidores aparece la instantánea del sistema de correo, tomada antes de aplicar el parche. Consulta el plan de ese sistema.

Medir un retroceso importa porque es lo que los dueños de los sistemas recuerdan: no el parche que salió bien, sino la noche en que algo falló y cuánto tardó en arreglarse. La bitácora registra cada evento con su hora y permite calcular el tiempo entre dos de ellos sin depender de la memoria de nadie.

Abre la tabla bitacora y localiza la hora en que falló la verificación funcional y la hora en que el retroceso quedó completado.

Retroceder deja el sistema como estaba, con el fallo de seguridad incluido. El hallazgo, por tanto, no se cierra: sigue abierto, con su fecha límite original, porque el reloj nunca se detuvo. Lo que cambia es el trabajo pendiente: hay que averiguar por qué falló el parche, conseguir una versión que funcione y reprogramarla en una ventana posterior.

Si la fecha límite está cerca y no se llegará, se avisa pronto al dueño y se plantea una mitigación temporal o una excepción, en vez de esperar a que el plazo se venza. La tabla hallazgos tiene el caso de esta ventana.