Remedy Trade

Operador de trading sistemático

remedy.trade

Remedy Trade diseña, prueba y opera procesos de trading sistemático en los que la investigación, la ejecución, la monitorización y el riesgo deben permanecer conectados. La infraestructura detrás de esos procesos incluye preocupaciones habituales de software (servicios, bases de datos, certificados, logs y despliegues), pero el coste de un cambio poco claro es mayor cuando los sistemas reaccionan a mercados en vivo.

El entorno de partida

El equipo ya tenía sistemas de ejecución e investigación muy capaces. El problema era la capa operativa a su alrededor. El despliegue de servicios, el acceso a los hosts, TLS, la conectividad con las bases de datos, la monitorización y la respuesta a incidentes estaban repartidos entre herramientas y convenciones distintas. Un ingeniero podía responder a cada pregunta por separado, pero responder a la pregunta completa (qué cambió, a qué afectó, si los clientes o las estrategias quedaron expuestos y cómo recuperarse) requería correlacionar datos a mano.

Remedy tenía además una restricción de arquitectura estricta: la aplicación de gestión no podía convertirse en una dependencia en tiempo de ejecución para las estrategias que ya estaban funcionando. Si un servicio del plano de control no estaba disponible, las cargas de trabajo de cara al mercado y las Routes establecidas tenían que seguir sirviendo.

Adopción en torno a la pila de ejecución

Opfield se introdujo alrededor del entorno de trading existente, no a través de él. Los primeros recursos gestionados fueron los de infraestructura: el tráfico entrante, los hosts Docker de apoyo, las señales de monitorización y algunas Routes de servicios seleccionadas. El código de investigación, la lógica de ejecución y la conectividad con los mercados no cambiaron.

El despliegue siguió cuatro límites:

1. Mantener la gestión saliente. Los hosts gestionados iniciaban sus conexiones de control. El despliegue no exigió abrir puertos de gestión entrantes en toda la red de trading.
2. Separar la disponibilidad del control de la disponibilidad de las cargas de trabajo. Las Routes y los servicios en ejecución seguían funcionando cuando el propio Opfield no estaba disponible temporalmente. El plano de control coordinaba los cambios, pero no hacía de proxy del tráfico normal de las aplicaciones a través de su proceso web.
3. Conectar el estado antes de automatizar los cambios. El equipo usó primero Opfield para establecer el inventario, las identidades, el estado y las relaciones. La automatización llegó cuando el estado visible coincidía con la realidad.
4. Aplicar operaciones con alcance limitado. Las acciones rutinarias pasaron a flujos de trabajo que respetan los permisos. Los cambios de alto impacto seguían requiriendo una revisión y una verificación explícitas por parte de un operador.

Qué cambió en la operación diaria

Los operadores de Remedy siguen la infraestructura que rodea a un servicio de trading en un solo producto. Pasan de una Route pública a su certificado, a la carga de trabajo upstream, al estado del nodo, a los logs recientes y al historial de operaciones sin traducir nombres entre paneles que no tienen relación entre sí.

Durante los incidentes, esto redujo la tentación de hacer cambios amplios antes de entender el impacto. El equipo podía distinguir un problema del plano de control de un problema de ejecución, mantener en su sitio las cargas de trabajo sanas y usar el mantenimiento o la reversión solo en el camino afectado. La observabilidad pasó a formar parte del flujo de trabajo operativo en lugar de ser un panel que se revisa después del despliegue.

El mismo modelo mejoró también el control de acceso. Las personas que trabajaban en las aplicaciones no necesitaban administración sin restricciones de los hosts para el despliegue o el diagnóstico rutinarios, mientras que los responsables de la infraestructura conservaban el acceso de bajo nivel necesario para la recuperación.

Resultado

El código de investigación, la lógica de ejecución y la conectividad con los mercados de Remedy se quedaron como estaban. El despliegue, el acceso, el estado de los servicios, TLS, los logs y la recuperación funcionan ahora en un solo producto, y el camino de ejecución no depende de que Opfield esté activo.

«En la infraestructura de trading, el despliegue y la observabilidad no pueden ser asuntos separados. Opfield mantiene coherente la capa operativa sin interponerse en la ejecución.»

Continúa con Preparación para producción y Runbook de incidentes para ver el modelo operativo usado en este entorno.