Escriba primero el rollback: una plantilla para actualizaciones rutinarias

Las plataformas se quedan atrás por una razón sencilla: cada actualización parece arriesgada, así que se pospone, y cada aplazamiento hace la siguiente actualización más grande y aún más arriesgada. La salida es hacer que las actualizaciones sean aburridas. Eso significa una plantilla que se sigue cada vez, y la línea más importante de esa plantilla es la que la mayoría de los equipos escribe la última: cómo volver atrás.

Sepa que existe una versión antes de necesitarla

Publicamos cada nuevo build, con su changelog, en nuestro chat de operaciones el día en que sale.

Un refinamiento merece copiarse. Muchos proyectos publican correcciones para ramas antiguas junto con la actual. Un vigilante que anuncia a ciegas «nueva versión» puede tentar a alguien a instalar un back-port más antiguo que lo que ya está en marcha. Nosotros los etiquetamos automáticamente como «no desplegar», para que nadie dé un paso atrás por accidente.

Prepare el cambio

Lea el changelog como si fuera un contrato

En las notas de la versión, lo que más importa son las migraciones: cualquier cosa que se ejecute una vez y no pueda deshacerse con facilidad, como un cambio de esquema, decide lo que su rollback debe incluir.

Revise cada servidor antes de tocarlo

Después compruebe cada servidor que va a tocar, no la flota en general, y contraste sus plugins, extensiones e integraciones con la nueva versión.

Un plugin del que nadie se acordaba es la razón más común por la que falla una actualización que por lo demás sería limpia. Listarlos por servidor lleva minutos y elimina la sorpresa.

Haga un backup que haya mirado de verdad

«El trabajo de backup se ejecutó» no es lo mismo que «tenemos un backup». Antes del cambio, haga un volcado consistente y pruébelo:

mysqldump --single-transaction --routines --triggers --events <db> \
  | gzip > <db>-pre-upgrade-$(date +%F-%H%M).sql.gz
gzip -t <db>-pre-upgrade-*.sql.gz && ls -lh <db>-pre-upgrade-*.sql.gz

Escriba el rollback antes del cambio

Este es el paso que convierte una actualización arriesgada en una rutinaria. Antes de empezar, escriba, en orden, los pasos exactos que devolverían el sistema a donde está ahora. En sistemas basados en RPM la parte de los paquetes suele ser corta:

dnf history list | head
dnf history undo <transaction-id>

Y para evitar que un paquete en buen estado se mueva mientras prueba, el plugin versionlock lo fija:

dnf versionlock add <package>

Pero los paquetes rara vez son toda la historia. Si la versión ejecuta una migración de esquema, revertir solo los paquetes le deja con código antiguo sobre un esquema nuevo. Su rollback tiene entonces que incluir la restauración del volcado que acaba de hacer, y necesita saber cuánto tarda esa restauración. Escríbalo todo y, siempre que pueda, ensáyelo primero sobre una copia. Un rollback que solo existe en su cabeza en el momento en que las cosas se tuercen no es un rollback.

Cambie una máquina cada vez

En plataformas redundantes, un nodo cada vez. Las versiones mayores van primero a nuestras propias instancias y corren ahí antes de que las reciba cualquier instancia de cliente.

Mida y verifique

Mida el downtime en lugar de estimarlo

«Alrededor de un minuto» es una suposición. Un probe que corre durante todo el cambio le da el número real. Arránquelo antes de empezar y párelo cuando haya terminado:

while true; do
  printf '%s %s\n' "$(date +%T.%3N)" \
    "$(curl -s -o /dev/null -m 2 -w '%{http_code}' https://<service>/health)"
  sleep 0.5
done | tee upgrade-probe-$(date +%F).log

Después, la primera y la última línea distintas de 200 en el log acotan la interrupción con medio segundo de precisión. Ese es el número que comunica a las personas que dependen del servicio, y es el número con el que compara la próxima vez. A lo largo de un trimestre, estas mediciones son la mejor prueba que tiene de que las actualizaciones se están volviendo más seguras y no más arriesgadas.

Verifique desde fuera, después ponga al día el sistema operativo

Cuando la actualización haya terminado, dispare una alarma de prueba para saber que la monitorización sigue viendo el servicio. Después aproveche la misma ventana para poner al día también los paquetes del sistema operativo. Aplicación y base se mantienen al mismo paso, y la siguiente actualización no empieza con una montaña de updates sin relación.

La plantilla

• Versión detectada y anunciada, back-ports etiquetados.
• Changelog leído en busca de correcciones de seguridad, cambios incompatibles y migraciones.
• Cada servidor revisado previamente, incluido cada plugin.
• Backup reciente hecho e inspeccionado.
• Rollback escrito, paso a paso, antes del cambio.
• Un nodo cada vez, las versiones mayores primero en sus propios sistemas.
• Downtime medido con un probe, comunicado en segundos.
• Verificado desde fuera, sistema operativo actualizado en la misma ventana.

Si sus plataformas se han quedado atrás y la siguiente actualización parece un proyecto, podemos ayudarle a volver a la rutina. Hable con un ingeniero

Related (rows[1])

Relacionado: Plataformas al día y disciplina de actualización · Respuesta urgente a vulnerabilidades, el mismo día · Monitorización de la flota y enrutado de alarmas