Un trabajo de copia que termina en verde es una afirmación. La afirmación es que, alguna mañana futura, esos archivos se convertirán en un sitio que funciona. No creo la afirmación hasta haber hecho esa mañana a propósito, en una máquina de prueba, mientras nadie espera. Una copia sin probar es una historia que te cuentas. Una restauración que has ejecutado es una copia.
Restaurar sobre nada, con calendario
El entorno de ensayo no es producción ni el staging que usan quienes editan. Empieza vacío. La copia es la única forma de entrar. Lo levanto, entro y recorro un camino que importaría durante un incidente: una página de pedido, un envío de formulario que sigue en la base, un archivo de medios que debe estar en el archivo y no solo en el disco viejo. Luego tiro la copia de ensayo.
Si eso falla, prefiero enterarme un martes que durante la caída para la que estaba la copia. Los fallos habituales son aburridos. El volcado de la base es más nuevo que los uploads. Una tabla del plugin apunta a un archivo que quedó excluido. El archivo supone una versión de PHP que la máquina de ensayo no tiene. Nada de esto aparece en la marca verde del plugin de copias.
Las actualizaciones necesitan vuelta atrás
Aplicar una actualización es fácil. Aplicarla con una forma de volver atrás es el servicio. Una instantánea antes, una prueba de humo corta después, y una vuelta atrás escrita si la prueba falla. Decir que la copia se puede restaurar no es una vuelta atrás si la restauración no tiene una duración que hayas medido. Quiero esa duración de la prueba en la máquina de ensayo, no del folleto del plugin.
Lo que realmente abro en la copia en limpio
Entra como un usuario real, no como el administrador de la instalación, si la copia incluye usuarios. Abre un pedido que tenga un estado, un total y al menos una nota. Abre una página que contenga una imagen y confirma que la imagen es el archivo del archivo, no un enlace caliente de vuelta a producción. No envíes nada. Estoy comprobando que el pasado volvió, no creando un presente nuevo en un host desechable.
Escribo la duración junto a la fecha. “Última restauración, 18 minutos, falló en el archivo de uploads, corregí la exclusión, la volví a lanzar.” Esa nota sirve más que una insignia de monitorización. Cuando alguien pregunta si el plan incluye copias, puedo responder con una fecha. Un plan que no puede responder con una fecha es un cron con una factura.
Un tiempo de respuesta en un plan de mantenimiento no significa nada el primer día si todavía no he restaurado nada. El reloj que estoy dispuesto a escribir empieza después de la línea base, el acceso y una restauración que ha salido bien. Antes de eso sigo aprendiendo cómo está montado el sitio. Prometer una respuesta el mismo día en esa niebla es como los planes de mantenimiento se vuelven disculpas.
Pregunta cuándo se hizo la última restauración de prueba. La pausa antes de la respuesta es la respuesta.
El mantenimiento no es una pestaña abierta para funciones nuevas
Un plan que promete monitorización, actualizaciones, restauraciones y además lo que se te ocurra después está tasado para una fantasía, o se renegociará la primera vez que la fantasía llegue. Páginas nuevas, un rediseño, una migración: eso es su propio alcance. El plan que voy a defender es más estrecho. El sitio sigue haciendo lo que ya hace. La copia está demostrada. Una persona responde dentro de las horas que quedaron escritas. Eso es menos emocionante que una iguala sin bordes. También es un plan que puedes comprobar.
