Un plan de reversión debe sobrevivir a la primera escritura

Un plan de reversión solo resulta creíble si el sistema anterior puede aceptar las escrituras del nuevo sin perderlas, duplicarlas ni alterar su orden. Devolver el balanceador de carga es la parte fácil. La parte difícil comienza con el primer pedido, pago, expediente, asiento o cambio de estado confirmado después del cambio.

Por eso la reversión es un problema de datos y autoridad, no una función del despliegue. Antes del cambio, el equipo debe saber qué sistema controla las escrituras en cada instante, cómo regresarán al modelo anterior las escrituras posteriores, qué efectos externos no se pueden deshacer y quién puede ordenar la vuelta. Si esas respuestas solo están en la cabeza de alguien o dependen de código que nunca se ha ejecutado, no existe un plan de reversión. Solo queda la esperanza de que el sistema nuevo falle antes de que ocurra algo importante.

El cambio transfiere la autoridad de escritura

Un cambio seguro concede la autoridad de escritura a un único sistema en cada momento. Ambos sistemas pueden servir lecturas, comparar resultados, consumir eventos copiados o ejecutar cálculos en segundo plano. No deben aceptar por separado cambios autoritativos sobre el mismo registro de negocio. Dos escritores crean conflictos que un cambio de ruta no puede resolver.

La autoridad de escritura abarca más que la conexión principal a la base de datos. Un entorno heredado suele aceptar cambios mediante archivos por lotes, colas de mensajes, pantallas de operador, tareas programadas, transferencias de socios, procedimientos almacenados y actualizaciones directas de soporte. He visto equipos bloquear la aplicación web mientras una tarea nocturna contabilizaba ajustes en silencio con otra cuenta. La migración parecía estable hasta que los dos libros contables dejaron de cuadrar a la mañana siguiente.

Construya el inventario de escrituras alrededor de operaciones de negocio, no de tablas. Para cada operación, registre el punto de entrada, la identidad, el límite de la transacción, el identificador generado, la fuente horaria, los efectos posteriores y el sistema que la controla antes y después del cambio. «Actualizar cliente» es demasiado amplio. «Cambiar la dirección postal, emitir el aviso normativo y poner en cola el trabajo de impresión» tiene suficiente detalle para revelar lo que debe conservar la reversión.

El control de enrutamiento también necesita un único responsable. El DNS por sí solo es un mal control de emergencia porque los resolutores y clientes guardan la información más allá del momento en que los operadores creen haber realizado el cambio. Es preferible controlar una puerta de enlace, un proxy, un consumidor de cola, un intermediario de conexiones u otro punto donde el equipo pueda observar la ruta activa. Registre el valor actual del control y la orden que lo modifica. Una captura de una consola no ofrece al responsable del incidente una acción repetible.

Defina los estados de autoridad con términos sencillos: OLD_WRITES, DRAINING, NEW_WRITES y ROLLING_BACK bastan para muchos sistemas. Cada estado debe permitir un conjunto conocido de escritores. La transición debe rechazar un escritor inesperado, no limitarse a registrarlo, porque un aviso descubierto después de la reversión no puede borrar una transacción.

Las condiciones previas necesitan un sí o un no

El cambio solo debe empezar cuando cada condición previa de reversión tenga una prueba identificada, un resultado actual y un responsable capaz de detener la operación. Un documento que diga «replicación correcta» deja espacio para discutir durante un incidente. Una prueba que indique que la posición reproducida es igual o posterior a la posición capturada, con la consulta exacta y su salida adjuntas, proporciona un hecho.

Use un contrato breve de preparación. Es una barrera, no una aspiración:

• La versión anterior puede leer todos los cambios de esquema introducidos para el cambio.
• El sistema anterior está desplegado, accesible, actualizado y puede autenticarse ante sus dependencias.
• La vía de captura o replicación ha procesado una carga similar a producción sin superar el límite de retraso acordado.
• Todos los escritores del inventario respetan el control de autoridad, incluidos los procesos por lotes y de operador.
• El equipo ha restaurado una copia reciente en un entorno aislado y ha comprobado que arranca.

El último punto detecta una sustitución frecuente: una copia correcta no equivale a una restauración correcta. Una tarea de copia en verde demuestra que se copiaron bytes a algún lugar. No demuestra que la clave de cifrado esté disponible, que el archivo esté completo, que el motor pueda leerlo ni que la aplicación arranque con él. Guarde la orden de restauración, la duración, la suma de comprobación y el resultado de la prueba de la aplicación junto al registro del cambio.

Capture un punto de control de datos justo antes de transferir la autoridad. En PostgreSQL, un equipo que use replicación física por streaming puede comparar la posición WAL actual del primario con la posición reproducida por el secundario. El manual de PostgreSQL define un LSN como una posición del registro de escritura y dice que pg_last_wal_replay_lsn() devuelve la última posición reproducida durante la recuperación. Una captura mínima de prueba tiene este aspecto:

/* On the primary */
SELECT pg_current_wal_lsn();
 pg_current_wal_lsn

 7A3/91F2C6D0
(1 row)

/* On the standby */
SELECT pg_last_wal_replay_lsn();
 pg_last_wal_replay_lsn

 7A3/91F2C6D0
(1 row)

Considere el valor un ejemplo del formato de salida, no un umbral mágico. La igualdad en un instante no demuestra que todas las escrituras de negocio sean reversibles, y una diferencia en bytes no se traduce directamente en tiempo. La comprobación demuestra un hecho limitado: el secundario ha reproducido hasta la posición capturada del registro. La prueba también necesita recuentos de aplicación, invariantes y muestras de registros que tengan sentido en el negocio.

Mantenga caliente el sistema anterior hasta poder devolver los datos

El sistema anterior debe seguir caliente hasta que el equipo demuestre que puede incorporar todos los cambios posteriores al cambio o renuncie formalmente a la reversión y pase a reparar hacia delante. Un número fijo de días parece concluyente, pero ignora el volumen de transacciones, los trabajos retrasados, los ciclos de liquidación y los cambios de esquema. Establezca el periodo según condiciones de salida observables y añada un límite de calendario para controlar personal y costes.

«Caliente» significa que puede ejecutarse bajo la presión de un incidente. La aplicación anterior tiene capacidad de cálculo, configuración actual, secretos válidos, acceso a la red, contratos vigentes con sus dependencias, espacio de almacenamiento, supervisión y operadores que aún saben usarla. Una máquina virtual apagada con un certificado vencido es un archivo. No es un destino de reversión.

Manténgala caliente durante al menos un ciclo completo de negocio capaz de mostrar comportamiento tardío. El ciclo puede incluir una contabilización nocturna, un cierre de facturación, un archivo de un socio, una programación de fin de semana o un cierre de periodo. No copie una regla genérica de siete o treinta días. Un sistema de siniestros que recibe documentos tardíos y un servicio de punto de venta que liquida cada noche necesitan ventanas de prueba distintas.

Las condiciones de salida deben cubrir comportamiento y capacidad de recuperación. Exija al sistema nuevo que termine las tareas demoradas, concilie confirmaciones externas, respete los límites de error y latencia con tráfico real y produzca un flujo de cambios que el sistema anterior pueda consumir. Exija también un ensayo de reversión correcto con datos capturados después de un cambio simulado. Si el equipo elimina la vía inversa, aplica un cambio destructivo de esquema o deja caducar el contrato de una dependencia antigua, registre el momento exacto en que termina la posibilidad de volver.

Mantener caliente el sistema anterior tiene coste y riesgo. Los servicios sin parches, los planificadores duplicados y las credenciales activas aumentan la superficie de fallo. Redúzcala a propósito: bloquee el tráfico de usuarios, desactive todos los planificadores salvo el necesario para la reversión probada, limite el acceso de operadores y supervise cada intento de conexión. Caliente no significa dejarlo funcionando sin control.

Las escrituras posteriores deciden la estrategia

Cada escritura posterior al cambio necesita uno de cuatro tratamientos: reproducirla en el sistema anterior, conservarla para una reproducción posterior, compensar su efecto o aceptar que hace imposible la reversión. Llamar «sincronización de datos» a las cuatro opciones oculta las decisiones importantes. El tratamiento correcto depende de la semántica de negocio, especialmente del orden y los efectos externos.

La replicación inversa funciona cuando el modelo de destino puede expresar el nuevo cambio y la herramienta de replicación conserva los límites de transacción necesarios. Se vuelve peligrosa cuando el sistema moderno divide una fila antigua en varios registros, sustituye un estado mutable por eventos, cambia la generación de identificadores o aplica una validación más estricta. Un copiador de filas puede entregar datos sintácticamente válidos que la aplicación anterior interpreta de forma incorrecta.

Un diario de cambios que solo admite adiciones suele ser más fácil de entender. Asigne a cada orden aceptada un identificador de operación inmutable, una clave de negocio, una secuencia de origen, una versión de esquema, un actor, la hora de aceptación, los datos y el resultado. El importador de reversión registra el identificador que aplicó, para que los reintentos no repitan la acción de negocio. La idempotencia pertenece al límite de negocio: «establecer la dirección X» se puede reintentar, mientras «sumar 10 al saldo» exige una identidad única y el rechazo de duplicados.

La escritura doble desde el código de la aplicación es popular porque parece inmediata. La desaconsejo en la mayoría de los cambios. La solicitud puede confirmarse en la base nueva y agotar el tiempo antes de hacerlo en la antigua, lo que deja al cliente sin saber qué pasó y separa ambos sistemas. Invertir el orden solo cambia qué sistema gana el fallo. Un buzón transaccional o un flujo de cambios de la base vincula la captura a la confirmación autoritativa y permite que un consumidor separado reintente la entrega.

Algunas escrituras no deben regresar automáticamente. Si el sistema nuevo permite un estado que el esquema anterior no puede representar, ponga la operación en cuarentena y muestre el recuento antes del cambio. Lo mismo se aplica cuando las reglas de validación difieren. No fuerce el valor, elimine un campo ni esconda un significado nuevo en un antiguo campo de texto libre solo para que un contador de conciliación llegue a cero.

El runbook debe mover datos y tráfico

Un runbook de reversión ejecutable congela las escrituras nuevas, establece un límite final, vierte los cambios capturados en el modelo anterior, verifica el estado de negocio y solo entonces devuelve el tráfico. Devolver primero el tráfico invita a los usuarios a crear más cambios mientras el importador todavía recupera el retraso. El límite se mueve durante el incidente.

Una secuencia práctica contiene interrupciones y pruebas explícitas:

1. Declare ROLLING_BACK, rechace nuevas solicitudes de modificación, detenga los consumidores y registre la hora y el último identificador de operación aceptado. Las lecturas solo pueden continuar si no provocan escrituras ocultas.
2. Espere a que terminen las transacciones en curso o interrúmpalas según una regla documentada. Capture la posición del registro de origen, los desplazamientos de las colas y el recuento de entradas del diario sin procesar.
3. Aplique el flujo inverso hasta el límite registrado. Deténgase si una operación no tiene correspondencia, incumple un invariante anterior o produce una referencia externa diferente.
4. Ejecute consultas de conciliación y lecturas de negocio de muestra en el sistema anterior. Envíe una transacción sintética por cada punto de entrada crítico, pero dirija las notificaciones externas a un receptor controlado.
5. Restaure la autoridad de escritura anterior, libere el tráfico de forma gradual, reanude solo los planificadores antiguos y observe los contadores de duplicados, rechazos y retrasos.

Escriba las salidas esperadas junto a cada orden. 0 rows puede significar éxito en una consulta de huérfanos y desastre en un recuento de pedidos. Indique cuál es el significado aplicable. Coloque los procedimientos de credenciales y aprobación cerca de las órdenes sin incluir secretos en el runbook. Si quien lo ejecuta tiene que buscar una ruta en el almacén de contraseñas, identifique la entrada y compruebe el acceso durante el ensayo.

Mida por separado cada etapa. No basta con el tiempo total de recuperación. El equipo debe saber cuánto permanecen congeladas las escrituras, a qué velocidad vacía el consumidor inverso el volumen máximo y qué validación domina la pausa. Si una cola de 500 000 operaciones tarda más en reproducirse de lo que el negocio puede tolerar, el plan falla aunque supere un ensayo pequeño. Pruebe con el máximo esperado y un margen.

La compatibilidad conserva el camino de vuelta

La reversión depende de la compatibilidad hacia atrás de bases de datos, mensajes, API, archivos y autenticación. El binario anterior debe ejecutarse contra el estado del cambio. Si una migración elimina una columna, reutiliza un valor de enumeración, cambia el significado de un mensaje o renueva una credencial fuera de lo que admite el cliente antiguo, la ruta de vuelta puede desaparecer sin que nadie lo note.

La descripción de Parallel Change de Danilo Sato divide un cambio incompatible en las fases de ampliación, migración y contracción. El modelo es útil porque la reversión pertenece a la fase ampliada, mientras todavía funcionan consumidores antiguos y nuevos. Los equipos se meten en problemas cuando tratan la contracción como limpieza y eliminan el campo o punto de acceso antiguo en cuanto el tráfico nuevo parece sano. La contracción es el final deliberado de la reversión y merece su propio registro de cambio.

Los cambios aditivos de esquema son necesarios, pero no bastan. Una columna que admita nulos puede romper código antiguo si cambia un disparador, una consulta usa inserciones posicionales o un procedimiento almacenado devuelve una forma de resultado nueva. Pruebe la versión antigua real contra un clon del esquema de cambio. Ejercite lecturas y escrituras, incluidos valores infrecuentes, lotes vacíos, tamaños máximos de campo y rutas de error.

Los mensajes también necesitan una regla de compatibilidad. Los consumidores deben ignorar campos que no entienden, pero tienen que rechazar un significado cambiado que se oculte bajo un nombre anterior. Mantenga disponibles los tipos de evento antiguos durante el periodo caliente o proporcione un conversor descendente probado. Versione el conversor y guarde los datos originales para que un operador pueda reproducir una correspondencia discutida.

Los fallos de autenticación son especialmente incómodos porque se pueden evitar. Conserve las identidades de servicio anteriores, las cadenas de certificados, la compatibilidad de cifrado y las rutas de red mientras la reversión siga siendo una opción. Pruébelas desde el entorno de ejecución anterior, no desde el equipo de un administrador.

Los efectos externos necesitan compensación

Una reversión no puede recuperar un correo ya entregado, un archivo bancario aceptado, una etiqueta impresa ni una orden de un socio que ya se ha ejecutado. Son efectos externos, y el plan necesita una política para cada uno antes del cambio. La paridad en la base de datos no los resuelve.

Asigne una clave de idempotencia a cada acción saliente y conserve con ella la confirmación del proveedor. Durante la reversión, el sistema anterior debe conocer las acciones que ya ocurrieron para no volver a enviarlas. Si el receptor admite solicitudes idempotentes, reutilice la misma clave. Si no, coloque la acción detrás de un registro interno que rechace un segundo envío.

La compensación es una nueva acción de negocio, no un borrado. Un pago contabilizado puede requerir un asiento inverso. Una instrucción de almacén enviada puede necesitar una cancelación que a su vez puede fallar. Una notificación al cliente puede exigir una corrección escrita por una persona. Registre quién autoriza cada compensación, el plazo y qué sucede cuando la parte externa no puede revertir el efecto.

El trabajo programado crea un riesgo de duplicación más discreto. Cuando ambos entornos siguen calientes, dos planificadores pueden recoger las mismas filas pendientes y emitir la misma acción. El control de autoridad debe cubrir los trabajos con la misma firmeza que las solicitudes HTTP. Durante el funcionamiento normal, el planificador inactivo no debe poder adquirir el arrendamiento ni la credencial de producción. Durante la reversión, los operadores transfieren el arrendamiento solo después de detener el trabajador nuevo y conocer su último elemento terminado.

Concilie los efectos por identificador de negocio y confirmación, no por profundidad de la cola local. Una cola vacía puede significar que todo tuvo éxito, que todo falló en un almacén de mensajes descartados sin vigilar o que un filtro no seleccionó nada. El informe útil une acciones previstas, intentos, respuestas del proveedor y compensaciones en una fila por cada evento de negocio.

Un ensayo debe forzar el fallo incómodo

Un ensayo solo demuestra la reversión cuando utiliza escrituras posteriores al cambio, rompe algo a propósito y devuelve el servicio mediante los mismos controles que usará el equipo de producción. Una reunión donde se lee el runbook en voz alta prueba el texto. Un cambio en preproducción sin datos representativos prueba el enrutamiento. Ninguno demuestra la recuperación.

Use un clon parecido a producción o un entorno aislado de reproducción con registros depurados y tráfico grabado. Inicie las versiones anterior y nueva, active el control real de autoridad y cargue suficiente historial para que migraciones e índices se comporten de forma creíble. CodeHero usa un banco de paridad contra tráfico de producción grabado cuando reescribe sistemas heredados. Ese mismo conjunto de tráfico puede descubrir diferencias de comportamiento antes de un ensayo de reversión.

A continuación, provoque un fallo después de que el sistema nuevo haya aceptado una mezcla de operaciones. Incluya una actualización que llegue dos veces, dos órdenes sobre la misma cuenta en orden, un límite de lote, un valor rechazado, una operación con un efecto externo capturado en un receptor y una tarea que se ejecutaba durante la congelación. Detenga el consumidor inverso a mitad de camino y reinícielo. Los identificadores de operación deben evitar duplicados y el límite debe permanecer estable.

Un fallo conocido merece atención especial. El importador inverso informa que no hay retraso, el tráfico regresa al sistema anterior y los recuentos básicos coinciden. Horas después, un socio rechaza el archivo del día porque el sistema moderno generó identificadores con un formato que la exportación antigua trunca. La reversión movió bien las filas, pero perdió comportamiento en el límite de un archivo. Un ensayo adecuado ejecuta la exportación, la analiza con el contrato del receptor y compara los identificadores de extremo a extremo.

Recoja pruebas que pueda evaluar alguien distinto del autor de la migración: identificadores de operación aceptados, posiciones de origen y aplicadas, resultados de consultas de invariantes, recuentos de duplicados, correspondencias en cuarentena, entradas del registro de efectos externos, duración de las etapas y estado final de autoridad. Conserve también el ensayo fallido. Un plan que solo funciona después de que un ingeniero modifica datos a mano necesita incorporar esa reparación como un paso controlado o eliminarla mediante código.

La observación debe mostrar corrección de negocio

Las señales de reversión deben informar sobre la corrección de negocio, no limitarse a decir si los procesos están vivos. Un servicio nuevo puede responder deprisa mientras asigna números de factura duplicados, omite una regla contable o deja una exportación atascada para siempre. Los gráficos de infraestructura ayudan a encontrar un fallo, pero rara vez dicen al responsable si resulta seguro seguir escribiendo.

Defina invariantes a partir del comportamiento heredado antes del cambio. Un invariante puede indicar que cada pago aceptado tiene un asiento, cada envío hace referencia a un pedido aceptado, cada expediente cerrado tiene un motivo o cada archivo saliente tiene el total de control correspondiente. Exprese cada uno como consulta o informe que ambos sistemas puedan producir. Cuando los esquemas difieran, compare una proyección de negocio canónica en lugar de forzar la igualdad de tablas.

La proyección debe normalizar las diferencias que no cambien el comportamiento y conservar las que sí. Convertir las marcas de tiempo a una zona antes de comparar es razonable. Ignorar los céntimos porque un sistema almacena decimales y el otro unidades menores enteras no lo es. Acuerde esas reglas con las personas responsables del registro de negocio y versiónelas junto al código de migración. De lo contrario, un ingeniero puede convertir una comparación roja en verde ampliando un filtro durante el incidente.

Los recuentos necesitan denominadores y límites. «Doce diferencias» dice poco sin el número examinado, los tipos de operación y el intervalo de aceptación. Un recuento de cero también puede mentir si la comparación se detuvo en la partición de ayer. Cada resultado debe indicar los límites de origen y destino, el número seleccionado, el número comparado, las diferencias, la operación sin pareja más antigua y la hora de finalización.

Use señales de actualidad que sigan la vía real de reproducción. La profundidad de la cola oculta una partición atascada si las demás siguen vaciándose. La actividad del consumidor oculta un mensaje defectuoso que se reintenta sin fin. Muestre la operación sin aplicar más antigua y su edad, la última secuencia de origen vista, la última secuencia de destino confirmada, el recuento de cuarentena, los reintentos por operación y el ritmo de vaciado. Un retraso estable con tráfico constante puede ser aceptable en operación normal, pero fatal para una reversión que debe llegar a cero durante la congelación.

Las muestras siguen importando porque los invariantes no pueden codificar todas las reglas extrañas del sistema heredado. Seleccione registros con criterios deterministas para que el ensayo y la producción inspeccionen casos comparables: transacciones más grandes, campos con longitud máxima, expedientes reabiertos, pagos revertidos, monedas no predeterminadas y operaciones que cruzan una fecha. Incluya el resultado de negocio y el artefacto de salida, no solo la fila almacenada. Una factura que cuadra en la base pero se presenta sin identificador fiscal es una diferencia de comportamiento.

Las alertas deben corresponder directamente a decisiones declaradas. Una infracción de invariantes puede congelar las escrituras de inmediato. Una edad creciente de reproducción puede iniciar un temporizador. Un pico transitorio de latencia puede requerir observación sin reversión. Escriba esa correspondencia antes del cambio y adjúntela a la alerta. Durante un incidente, una alerta llamada «migración no saludable» solo inicia una discusión sobre qué significa no saludable.

Conserve la telemetría después de terminar el periodo caliente. Explica por qué el equipo retiró la vía de vuelta y ofrece una referencia fiable para reparar hacia delante. El registro final debe demostrar que concluyó el trabajo demorado, los límites de comparación superaron el ciclo de negocio acordado, las cuarentenas se resolvieron y no quedaron efectos externos sin explicar. Esa prueba vale más que un acta que diga que la migración parecía correcta.

Haga que la tarea de comparación sea independiente de la ruta que evalúa. Si la conexión de base de datos, la caché o el código de serialización de la aplicación nueva también alimentan el verificador, un defecto puede corromper tanto el resultado como su supuesto control. Ejecute las conciliaciones críticas mediante un lector desplegado por separado con permisos restringidos, y guarde el texto de la consulta y la suma del resultado en el registro del cambio. La independencia no exige una segunda plataforma, pero sí una vía de fallo que no pueda coincidir consigo misma en silencio.

Pruebe también como fallo la ausencia de telemetría. Detenga el consumidor del diario, retenga una partición de origen y haga que el receptor de efectos externos rechace una confirmación. El panel debe mostrar un límite cada vez más antiguo y una comparación incompleta, mientras el control de autoridad impide declarar el éxito. Si un panel vacío parece igual que cero diferencias, corríjalo antes del cambio.

La decisión de revertir necesita un reloj

La decisión debe seguir desencadenantes declarados, un responsable y un presupuesto de tiempo fijados antes del cambio. Sin ellos, los ingenieros gastan la ventana reversible en diagnosticar mientras se acumulan escrituras y se propagan efectos externos. Cuando la dirección pide volver, la reproducción puede tardar más que una reparación hacia delante.

Elija desencadenantes que describan daño al usuario o a la contabilidad: rechazo de operaciones críticas, incumplimiento de invariantes, diferencias de conciliación sin explicar, una cola sin límite, confirmaciones externas ausentes o incapacidad para cerrar un lote obligatorio. La CPU y la latencia pueden apoyar la decisión, pero los síntomas de infraestructura rara vez dicen por sí solos si los datos siguen seguros. Indique el periodo de observación y la fuente de cada señal.

Conceda a una persona autoridad para ordenar la reversión y nombre un suplente. Los responsables de base de datos, aplicación, operaciones, negocio e incidentes pueden aconsejar, pero el consenso es demasiado lento mientras llegan escrituras. Indique también quién puede declarar que la reversión ya no está disponible porque se cruzó un límite destructivo. Esa declaración debe pasar el plan a reparación hacia delante y compensación, no dejar al equipo debatiendo una opción caducada.

El reloj necesita dos límites. El plazo de decisión establece cuánto puede investigar el equipo antes de congelar escrituras o comprometerse con la reparación hacia delante. El presupuesto de ejecución establece cuánto puede tolerar el negocio la pausa y la reproducción. Derive ambos de la llegada de transacciones, el ritmo de vaciado, los plazos externos y el personal, y ponga a prueba esos supuestos en el ensayo.

Un equipo preparado puede entregar el runbook a un operador que no lo escribió, inyectar un fallo después de escrituras reales y recuperar el sistema anterior dentro del presupuesto. Si el ejercicio necesita una consulta no documentada, un ingeniero específico o una edición manual de datos, retrase el cambio. Producción no hará que esas dependencias sean más amables.