Escribir un runbook de cutover de migración con un reloj en cada paso

La diferencia entre una migración que supone cinco minutos de downtime visible y una que se come un fin de semana rara vez es el hardware. Es si la conmutación final (cutover) se escribió como una secuencia de pasos cronometrados, comprobables y reversibles antes de la noche, y si se ensayó hasta conocer los tiempos. Así escribimos nosotros ese documento.

El problema: la noche es el peor momento para pensar

Cada decisión tomada durante la ventana (qué sincronización va primero, cuánto esperar a una réplica, cuándo rendirse y hacer rollback) la toman personas cansadas y bajo presión, normalmente con el propietario del sitio al teléfono. El objetivo de un runbook es que nadie tenga que decidir durante la ventana nada que pudiera haberse decidido la semana anterior.

Una lista de tareas no es un runbook. Un runbook tiene cinco columnas.

Las cinco columnas

Paso	Tiempo máximo	Responsable	Verificación	Vuelta atrás
Congelar las escrituras en el origen	2 min	app	el login de administrador se rechaza, la cola de pedidos vacía	levantar la congelación
Sincronización final de ficheros	3 min	ops	rsync no detalla más cambios	no hace falta, el origen intacto
Puesta al día final de la base de datos y promoción	3 min	db	GTID igual en ambos lados, destino en read write	degradar el destino, descongelar el origen
Cambiar DNS y balanceador de carga	2 min	net	el nuevo origin responde a través del nombre público	revertir el registro
Smoke tests	5 min	app	lista de páginas, login, checkout, búsqueda	revertir el DNS

Tiempo máximo es lo que tardó el paso en el ensayo, más un margen. Responsable es una persona, no un equipo. Verificación es un hecho observable, no «parece que va bien». Vuelta atrás es la acción exacta que deshace el paso, y si un paso no tiene vuelta atrás, es el punto de no retorno y debe marcarse como tal.

Antes de la ventana: mueva casi todo con antelación

El cutover solo debería mover lo que ha cambiado desde la última sincronización. Todo lo demás ocurre días antes, mientras el origen sigue sirviendo:

• Construya el destino desde cero con especificaciones medidas, en lugar de restaurar imágenes de los servidores antiguos.
• Siembre la base de datos desde un backup físico y manténgala al día por replicación. La noche del cutover, ponerse al día es cuestión de segundos de diferencia.
• Presincronice los ficheros repetidamente, para que la última pasada sea pequeña. Haga un dry run el día anterior para ver qué moverá la pasada final:

rsync -aHAX --numeric-ids --delete --itemize-changes --dry-run \
      source:/var/www/ /var/www/ | wc -l

• Copie los índices de búsqueda con el reindexado remoto del propio motor en lugar de volver a rastrear el contenido a través de la aplicación.
• Baje los TTL del DNS a unos pocos minutos al menos dos TTL antiguos antes de la ventana, para que los resolvers hayan olvidado el valor largo cuando usted cambie. Compruebe lo que el mundo ve de verdad:

dig +noall +answer www.example.com @<public-resolver-1>
dig +noall +answer www.example.com @<public-resolver-2>

Ensaye sobre una copia, con cronómetro

Ejecute el cutover completo contra una copia del destino al menos una vez, con los mismos comandos, en orden, cronometrando cada paso. El ensayo produce la columna del tiempo máximo. También produce las sorpresas: la sincronización de ficheros que recorre despacio millones de ficheros sin cambios por un flag que falta, el usuario de replicación al que le falta un privilegio, el health check que apunta a la ruta equivocada.

Añada cada lección a la plantilla del runbook, no solo a la copia de esta migración. Así es como la décima migración resulta más fácil que la primera.

Escriba los criterios de go o no go por adelantado

Acuerde, antes de la ventana y con el propietario del sitio, qué debe cumplirse para empezar, y qué provocará un rollback:

• Go: lag de replicación en el destino por debajo de una cifra acordada, última sincronización en dry run dentro del tiempo máximo, monitorización del destino en verde, las personas de la columna de responsables presentes.
• Disparador de rollback: cualquier paso que supere el doble de su tiempo máximo, o los smoke tests sin pasar a una hora fija después del cambio.

Escribir el disparador elimina el instinto más peligroso de cualquier noche de cutover: «dale diez minutos más». Si el reloj dice rollback, se hace rollback, y se vuelve a intentar otra noche con un runbook mejor.

Haga que la vuelta atrás sea barata

Un rollback que exige restaurar desde backup no es un rollback que nadie elegirá usar. Diseñe cada paso para que deshacerlo sea rápido:

• El origen se queda intacto y en funcionamiento hasta que el destino se haya demostrado. Sus datos nunca se borran durante la ventana.
• En el destino, lo que se sustituye se renombra, nunca se elimina. Volver atrás es un renombrado y un cambio de DNS.
• La promoción de la base de datos ocurre solo cuando ambos lados informan del mismo GTID, de modo que una degradación le devuelve a una posición conocida.
• Los cambios de configuración se aplican como ficheros que puede intercambiar, no como ediciones que tiene que recordar.

mv /var/www/site /var/www/site.pre-cutover-$(date +%F)
mv /var/www/site.new /var/www/site

Ejecute la ventana, después audite

Durante la ventana, una persona lee el runbook en voz alta y anota el tiempo real frente a cada tiempo máximo. Nadie improvisa. Cuando pasa el último smoke test, mantenga el origen en funcionamiento y observe los dos lados: el tráfico debería drenar del origin antiguo a medida que expiran las cachés. Cualquier cosa que siga llegando al origen cuando ha pasado el TTL antiguo es una dependencia que nadie listó, como un cron job, un cliente de API o una dirección escrita a fuego, y hay que encontrarla antes de apagar el origen.

Después, compare la nueva plataforma con la línea base antigua: exposición externa, tiempos de respuesta, tasa de aciertos de caché, tasas de error. Solo entonces retire el origen, y conserve sus datos hasta que el propietario dé su visto bueno.

Su lista de comprobación

• Cada paso tiene un tiempo máximo, un responsable, una comprobación y una vuelta atrás.
• Los datos se siembran y los ficheros se presincronizan días antes. La ventana solo mueve la diferencia.
• Los TTL bajados pronto y verificados desde fuera.
• Un ensayo cronometrado sobre una copia, con las lecciones incorporadas a la plantilla.
• Criterios de go y de rollback acordados por escrito antes de la noche.
• El origen conservado intacto hasta que la auditoría termine y el propietario dé su visto bueno.

Si tiene una mudanza en el horizonte, con gusto le ayudamos a escribir el runbook.

Hable con un ingeniero

Related (rows[1])

Relacionado: Migraciones de datacenter gestionadas, ensayadas · Replicación de bases de datos y réplicas en otra sede · Live migration y salida de hipervisores