Plataformas · Software · Proveedores · Mercados
Devin Hartcastle
El sitio de recuperación solo resulta útil si puede hacerse cargo de la cartera sin perder el seguimiento de las órdenes ya enviadas al mercado. Este requisito influye más en el coste que disponer de un segundo conjunto de servidores. Un plan viable debe recuperar posiciones, límites de riesgo, estado de las órdenes, datos de mercado y sesiones con los centros de negociación en una secuencia controlada, y luego demostrar que el sistema recuperado puede operar con seguridad.
Fije objetivos de recuperación en torno al estado de trading
El objetivo de tiempo de recuperación (RTO) mide cuánto tiempo puede permanecer interrumpido el servicio. El objetivo de punto de recuperación (RPO) mide cuántos datos de estado puede permitirse perder la empresa. En una cartera de trading, no basta con un objetivo genérico de recuperación de bases de datos: una orden aceptada por el sistema primario pero no confirmada por un centro de negociación genera una incertidumbre que la infraestructura, por sí sola, no puede resolver.
Los rangos habituales de planificación varían según la arquitectura y el acceso a los centros de negociación. Un sistema de reserva templado puede tener como objetivo un RTO de 5 to 30 minutes y un RPO de 1 to 10 seconds. Un sistema de reserva en caliente puede tener como objetivo de 30 seconds a 5 minutes, con un RPO de menos de 1 second a alrededor de 2 seconds. Los diseños activo-activo pueden tener como objetivo de 1 a 30 seconds, pero el enrutamiento, la recuperación de sesiones y la conciliación de órdenes pueden tardar más que la detección del servicio. Trate estos valores como rangos de diseño, no como garantías.
Presupueste toda la ruta de recuperación
Las cifras siguientes son rangos habituales de planificación en dólares estadounidenses para una implementación de un broker o una prop firm pequeña o mediana. No son resultados auditados.
Los costes mensuales incluyen una asignación indicativa para ingeniería y operaciones, pero excluyen las licencias de datos de mercado, las comisiones de los mercados y las reescrituras importantes de aplicaciones. Estos conceptos dependen de los contratos y del código, y pueden modificar sustancialmente el total.
| Arquitectura, rangos habituales de mercado | Coste recurrente mensual, rango habitual | Coste de implementación, rango habitual | Objetivo habitual de RTO | Objetivo habitual de RPO |
|---|---|---|---|---|
| Sistema de reserva templado, capacidad que se activa o amplía durante la recuperación | $15,000 to $60,000 | $50,000 to $250,000 | 5 to 30 minutes | 1 to 10 seconds |
| Sistema de reserva en caliente, servicios principales en ejecución y datos replicados | $30,000 to $115,000 | $150,000 to $750,000 | 30 seconds to 5 minutes | Under 1 second to 2 seconds |
| Activo-activo, tráfico y estado gestionados entre sitios | $60,000 to $200,000+ | $400,000 to $1.5 million+ | 1 to 30 seconds | Near-zero to 1 second |
Los rangos incluyen computación y almacenamiento, bases de datos replicadas o registros de eventos, enlaces de red, supervisión, trabajo de implementación y una parte de la mano de obra operativa. Los costes aumentan con el número de instrumentos, la tasa máxima de órdenes, la retención, la distancia geográfica y la cantidad de centros de negociación que requieren conectividad independiente. El modelo activo-activo no consiste simplemente en duplicar el coste de los servidores: también requiere una gestión de conflictos, pruebas y cobertura operativa más complejas.
Los derechos de uso de datos de mercado y la conectividad con los centros de negociación son omisiones habituales en los presupuestos. Confirme si los feeds del sitio de respaldo, las sesiones, las conexiones cruzadas y el acceso para recuperación ante desastres están incluidos en los contratos vigentes. Un sitio técnicamente preparado podría no poder recibir datos con licencia ni conectarse a un centro de negociación.
Haga que el failover sea seguro para las órdenes en curso
Replique un registro de eventos de negocio que solo permita agregar datos, no una instantánea copiada periódicamente. El sistema de recuperación necesita una secuencia coherente para las solicitudes de órdenes, las confirmaciones, las ejecuciones, las cancelaciones, las decisiones de riesgo y los cambios de posiciones. Utilice claves de idempotencia y números de secuencia para que la reproducción no convierta una instrucción del cliente en dos órdenes.
Durante un fallo del sitio, no dé por sentado que un timeout significa que se rechazó una orden. Es posible que el centro de negociación la haya aceptado, pero que se haya perdido la confirmación.
Aísle el sistema primario para impedir que envíe más tráfico, restaure el último estado persistente y, a continuación, concilie las órdenes abiertas y las ejecuciones utilizando los registros autorizados del centro de negociación o un drop copy antes de habilitar nuevas órdenes. La secuencia exacta depende del protocolo del centro de negociación y del diseño del gateway.
- Mantenga los límites de riesgo, el estado de las cuentas y el estado de las posiciones en la ruta de recuperación, con controles para detectar datos obsoletos o incompletos.
- Defina qué sitio controla cada sesión con los centros de negociación. Utilice tokens de fencing o un control equivalente para evitar que ambos sitios actúen como primarios.
- Separe la recuperación de datos de mercado de la recuperación de la entrada de órdenes. Los precios obsoletos deben bloquear los controles de riesgo afectados, en lugar de pasar silenciosamente como actuales.
- Registre cada decisión de failover y cada transición de estado con marcas de tiempo que el equipo de operaciones pueda comparar entre sistemas.
La replicación síncrona puede reducir la pérdida de datos, pero añade latencia y hace que la disponibilidad dependa del enlace. La latencia típica de ida y vuelta entre regiones puede oscilar aproximadamente entre 20 y 80 milliseconds; un enlace metropolitano puede rondar entre 1 y 5 milliseconds.
Muchos sistemas de trading replican de forma asíncrona los eventos críticos y utilizan controles de conciliación, en lugar de añadir un viaje de ida y vuelta por una red de área extensa a cada orden. La opción adecuada depende de la tolerancia a la pérdida de cada tipo de estado.
Pruebe el servicio, no solo los servidores
Un cambio de infraestructura satisfactorio no demuestra que se haya recuperado una cartera de trading. Simule fallos en el gateway de órdenes, la base de datos, la ruta de red, el gestor de datos de mercado y el sitio primario. Incluya una desconexión del centro de negociación durante una orden en curso, porque las pruebas de apagado limpio no detectan la ambigüedad que genera el riesgo de ejecuciones duplicadas.
Un simulacro útil parte de una cartera inicial conocida, aplica fallos de forma controlada, establece quién tiene autoridad para declarar aislado el sistema primario e incluye una etapa de conciliación antes de reanudar el trading. Mida el RTO desde el primer fallo detectado hasta la primera orden verificada y habilitada para operar con controles de riesgo, no hasta el momento en que se inicia un proceso. Mida el RPO frente al registro de eventos y compare las posiciones reconstruidas con las ejecuciones de los centros de negociación.
- Realice una prueba mensual de recuperación a nivel de componentes, incluidos los backups, las credenciales, los certificados y el acceso a la configuración.
- Realice un simulacro de sitio completo al menos una vez al año y después de cambios sustanciales en los gateways, el enrutamiento, las bases de datos o la conectividad con los centros de negociación.
- Registre el tiempo transcurrido, los eventos perdidos o duplicados, las intervenciones manuales y cualquier diferencia entre el estado interno de las órdenes y el de los centros de negociación.
Asigne un responsable a cada modo de fallo y registre las pruebas necesarias para declarar la recuperación. Un runbook que depende de la memoria de un solo ingeniero es un coste operativo oculto. Puede aceptarse un paso manual controlado, pero su duración y la autoridad para tomar la decisión deben incluirse en el RTO.
Elija el diseño menos costoso que cubra el riesgo de la cartera
Un sistema de reserva templado suele ser adecuado para empresas que pueden pausar el trading durante varios minutos y conciliar con cuidado antes de reanudarlo. Un sistema de reserva en caliente es más apropiado cuando una interrupción prolongada tiene un coste directo para el cliente o de riesgo, pero sigue requiriendo una transferencia deliberada de las sesiones. El modelo activo-activo solo se justifica cuando la empresa necesita un servicio continuo y la aplicación puede gestionar de forma fiable la titularidad del estado, las solicitudes duplicadas y las situaciones de split-brain.
Elabore el presupuesto a partir de sus componentes, en lugar de aplicar un único porcentaje de resiliencia. Calcule el coste de una segunda ubicación, la replicación de datos, la red y el acceso a los centros de negociación, los entornos de prueba, la cobertura operativa y los simulacros anuales.
Después, calcule el coste de los derechos de uso de datos de mercado y de cualquier asistencia del proveedor que se necesite durante un incidente. El panorama general de plataformas y proveedores cambia las opciones disponibles; la cobertura de infraestructura de Trading Technology es un recurso para seguir esas dependencias.
Mantenga acotado el primer objetivo de recuperación: restablecer una vista verificada de la cartera, conciliar el estado en los centros de negociación y habilitar la entrada de órdenes solo cuando los controles de riesgo estén actualizados. Amplíe la automatización después de que los simulacros demuestren que la secuencia funciona.
Realice o revise el próximo simulacro y mida los segundos desde la inyección del fallo hasta la primera orden verificada y habilitada para operar con controles de riesgo. El umbral que debe comprobarse es 60 seconds.
Preguntas frecuentes
¿Cuál es un RTO realista para una plataforma de trading?
Los objetivos habituales de planificación van de 5 to 30 minutes para un sistema de reserva templado, de 30 seconds a 5 minutes para uno en caliente y de 1 a 30 seconds para algunos diseños activo-activo. La recuperación de las sesiones con los centros de negociación y la conciliación de órdenes pueden retrasar el momento en que se reanuda el trading seguro.
¿Cuánto cuesta la recuperación ante desastres de una plataforma de trading?
Los rangos habituales de planificación mensual son de $15,000 to $60,000 para un sistema de reserva templado, de $30,000 to $115,000 para uno en caliente y de $60,000 to $200,000 o más para un modelo activo-activo. Las licencias de datos de mercado, las comisiones de los mercados y los cambios importantes en las aplicaciones pueden aumentar sustancialmente estas cifras.
¿Cómo debe gestionar un broker las órdenes en curso durante un failover?
Aísle el sistema primario que ha fallado para que no pueda seguir enviando órdenes y, después, concilie el estado recuperado con los registros autorizados de los centros de negociación o con un drop copy. Considere incierta una orden que haya agotado el tiempo de espera, en lugar de darla por rechazada, y no habilite nuevas órdenes hasta controlar el riesgo de duplicados.
¿Con qué frecuencia debe probar una empresa de trading la recuperación ante desastres?
Realice pruebas de recuperación de componentes periódicamente; las comprobaciones mensuales son una frecuencia operativa habitual. Lleve a cabo un simulacro de sitio completo al menos una vez al año y repita las pruebas después de cambios importantes en los gateways, el enrutamiento, las bases de datos o la conectividad con los centros de negociación.
