Recuperación ante desastres para un libro de trading en vivo: checklist semanal

Decida qué debe conmutar y qué debe detenerse

Un operador activa una réplica en espera en cuanto el primario pierde conectividad. Otro aísla el primario, comprueba la posición de replicación y el estado de las órdenes, y luego activa la réplica. El primero podría restablecer más rápido la entrada de órdenes.

El segundo reduce la posibilidad de que dos sistemas activos envíen órdenes contra el mismo libro. Ninguna de las dos decisiones es segura por sí sola: la secuencia adecuada depende de cómo gestiona la plataforma la autoridad, el estado y las sesiones con los mercados.

Para un libro de trading en vivo, la recuperación no consiste simplemente en poner en marcha servidores en otra zona. Significa establecer un único sistema con autoridad para escribir, restaurar el estado necesario para tomar decisiones seguras y demostrar que las órdenes, las ejecuciones, las posiciones y los límites de riesgo coinciden. Una página de inicio de sesión rápida no demuestra que el servicio de trading esté listo.

Esta semana, empiece por definir objetivos de recuperación para cada función, en lugar de fijar un único objetivo general para la plataforma. Separe la aceptación de órdenes, los datos de mercado, los precios, los controles de riesgo, el acceso de clientes, los informes y las conexiones con el back office. Decida qué funciones pueden estar temporalmente disponibles solo en modo de lectura o no estar disponibles, y cuáles deben bloquearse hasta que se concilie el estado. Un objetivo habitual podría permitir que los informes para clientes tengan varios minutos de retraso, mientras se exige que la entrada de órdenes permanezca desactivada hasta que el libro sea coherente.

Deje por escrito quién puede declarar un desastre, quién controla el token de conmutación por error y quién puede detener el trading. Un runbook que depende de que una persona reconozca una alerta no es un runbook. Para conocer mejor las operaciones de plataforma, la cobertura de infraestructura de Trading Technology analiza los sistemas de los que dependen los brokers y las prop firms.

Mapee el estado y fije objetivos medibles

Enumere todos los componentes que pueden cambiar el estado del libro: gestión de órdenes, riesgo, gateways de ejecución, servicio de posiciones, libro de caja, almacén de sesiones de clientes y registro de eventos. Para cada uno, identifique la fuente de verdad, el método de replicación, la alerta de retraso y el responsable de la recuperación. Incluya las sesiones con los mercados y las conexiones con la cámara de compensación o el prime broker. Una réplica de base de datos no reproduce una sesión FIX en vivo, una cancelación sin confirmar ni la visión que tiene un mercado de una orden.

Las cifras siguientes son rangos habituales del mercado para conversaciones de planificación, no garantías ni resultados auditados. Los objetivos de una empresa dependen de su arquitectura, los mercados, la gama de productos y las obligaciones regulatorias. Mídalos en un ensayo con una carga representativa.

Para cada objetivo, indique cuándo empieza y termina el cómputo. «RTO de cinco minutos» es ambiguo si un equipo empieza a contar al recibir la alerta y otro al declararse el incidente. Registre por separado las horas de detección, aislamiento, activación, validación y primera orden permitida.

Realice un ensayo controlado esta semana

Elija un periodo de bajo riesgo y un libro representativo, que incluya el gateway o grupo de instrumentos de mayor actividad que el entorno de pruebas pueda admitir de forma segura. No realice una conmutación por error en producción cortando la alimentación o bloqueando una ruta de red sin un cambio aprobado, un plan de reversión y coordinación con los mercados. Si no se autoriza probar en producción, inyecte fallos en staging y compare la configuración y el flujo de eventos con los de producción.

1. Delimite el alcance. Indique los servicios, mercados, cuentas y operadores incluidos en la prueba. Capture las posiciones actuales, las órdenes abiertas, los límites, el retraso de replicación y el estado de las sesiones del gateway.
2. Fije un límite de eventos conocido. Registre el último número de secuencia persistente en el primario y en la réplica en espera. Confirme qué registro, base de datos o flujo define ese número. Anote los flujos asíncronos que puedan llegar más tarde.
3. Active el fallo acordado. Simule la pérdida del servicio o sitio primario mediante el método aprobado. Observe las alertas y las marcas de tiempo. No permita que la réplica en espera acepte escrituras hasta que el mecanismo de aislamiento demuestre que el antiguo primario ya no puede escribir.
4. Active la réplica y restaure las dependencias. Compruebe la configuración, los secretos, los certificados, los cambios de DNS o de rutas, la sincronización de relojes y la conectividad con los mercados. Confirme que la réplica en espera tiene los límites de riesgo y la configuración de productos correctos, y no solo un estado de proceso saludable.
5. Concilie el libro. Compare las órdenes abiertas y ejecuciones internas con las copias drop de los mercados u otros registros autorizados equivalentes. Resuelva las órdenes nuevas, pendientes, rechazadas y ejecutadas parcialmente. Compruebe las cancelaciones en curso; nunca deduzca que una orden no llegó al mercado por el hecho de que falte una confirmación.
6. Valide el riesgo antes de habilitar la entrada de órdenes. Vuelva a calcular las posiciones y la exposición a partir de la fuente de verdad acordada. Compruebe el crédito, el margen, la concentración y los límites de frecuencia. Confirme que los interruptores de emergencia funcionan desde el sitio de recuperación.
7. Permita tráfico controlado. Empiece con una cuenta de prueba designada o un flujo limitado, y amplíelo solo después de que la monitorización confirme las confirmaciones, ejecuciones, rechazos y actualizaciones de posiciones esperados. Designe a un operador autorizado para detener la prueba.
8. Restaure y registre. Pruebe la conmutación de vuelta por separado, en lugar de tratarla como el proceso inverso a la activación. Registre los tiempos, los eventos perdidos o duplicados, las intervenciones manuales y las diferencias sin resolver, y asigne responsables y fechas a cada corrección.

Antes de la prueba, acuerde las condiciones para detenerla. Algunos ejemplos son un primario sin aislar, una brecha de secuencia que supere el objetivo de punto de recuperación aprobado, diferencias de posiciones sin explicación, límites de riesgo obsoletos o una sesión con un mercado que aún podría estar activa en ambos sitios. Registre quién tiene autoridad para abortar y comunique claramente a todo el equipo cómo hacerlo.

Demuestre que es seguro operar tras la recuperación

Después del ensayo, revise las pruebas en lugar de confiar en un panel en verde. Compruebe la continuidad de la secuencia de eventos, la gestión de duplicados, la conciliación de órdenes y ejecuciones, los cálculos de riesgo, el estado visible para los clientes y la cobertura de monitorización. Compare los tiempos reales con los objetivos de cada función. Si la aceptación de órdenes se restableció en cuatro minutos, pero el recálculo del riesgo tardó doce, el libro no se recuperó en cuatro minutos.

Registre los hallazgos en una lista breve de acciones:

• Elimine cualquier vía que permita dos sistemas de escritura, incluidas las credenciales obsoletas o una concesión de liderazgo que no haya expirado.
• Genere alertas por retrasos de replicación, flujos drop-copy interrumpidos y desviaciones de reloj antes de que se produzca un incidente.
• Haga que el runbook indique los comandos, permisos, responsables de las decisiones y pasos de reversión. Valide el acceso desde el entorno de recuperación.
• Vuelva a probar tras cambios importantes en el gestor de órdenes, el motor de riesgo, la conectividad con los mercados, la región de la nube o la topología de replicación.

Conserve el registro de recuperación junto con los procedimientos de incidentes y las pruebas para auditoría. Incluya el alcance de la prueba, las versiones, las marcas de tiempo, las discrepancias, las decisiones de los operadores y los responsables de las medidas correctivas. Un ejercicio trimestral integral puede probar dependencias más amplias, pero las comprobaciones breves y específicas de cada semana pueden detectar antes certificados caducados, rutas modificadas y desviaciones de configuración.

Esta checklist presupone que la empresa o su proveedor tecnológico puede controlar la activación y consultar el estado autorizado del trading. No se aplica sin cambios durante una interrupción de una bolsa o una cámara de compensación, cuando cambiar la infraestructura del propio broker no puede restaurar el mercado externo, ni cuando un contrato de plataforma externalizada no da a la empresa control sobre los mecanismos de conmutación por error. En esos casos, siga el proceso de incidentes del mercado o solicite al proveedor pruebas de recuperación verificadas y acuerde las responsabilidades antes de confiar en sus objetivos de recuperación.

#conmutación por error del libro de trading #recuperación ante desastres de brokers #resiliencia de la plataforma de trading #conmutación activo-pasivo #reproducción de órdenes #conciliación de operaciones #objetivo de tiempo de recuperación #controles de riesgo