Remedy Trade

Opérateur de trading systématique

remedy.trade

Remedy Trade conçoit, teste et exploite des processus de trading systématique dans lesquels la recherche, l’exécution, la supervision et le risque doivent rester liés. L’infrastructure derrière ces processus soulève des questions logicielles ordinaires — services, bases de données, certificats, journaux et déploiements —, mais le coût d’un changement mal compris est plus élevé lorsque les systèmes réagissent à des marchés en temps réel.

L’environnement de départ

L’équipe disposait déjà de systèmes d’exécution et de recherche performants. Le problème se situait dans la couche d’exploitation qui les entourait. Le déploiement des services, l’accès aux hôtes, TLS, la connectivité aux bases de données, la supervision et la réponse aux incidents reposaient sur des outils et des conventions différents. Un ingénieur pouvait répondre à chaque question prise isolément, mais répondre à la question complète — ce qui a changé, ce que cela a affecté, si des clients ou des stratégies étaient exposés et comment rétablir le service — exigeait des recoupements manuels.

Remedy avait aussi une contrainte d’architecture stricte : l’application de gestion ne devait pas devenir une dépendance d’exécution pour les stratégies déjà en cours. Si un service du plan de contrôle était indisponible, les charges de travail exposées au marché et les routes établies devaient continuer à servir.

Une adoption autour de la chaîne d’exécution

Opfield a été introduit autour de l’environnement de trading existant, et non à travers lui. Les premières ressources gérées concernaient l’infrastructure : ingress, hôtes Docker de support, signaux de supervision et une sélection de routes de services. Le code de recherche, la logique d’exécution et la connectivité au marché sont restés inchangés.

Le déploiement a suivi quatre principes :

1. Garder la gestion en sortie. Les hôtes gérés initiaient eux-mêmes leurs connexions de contrôle. Le déploiement n’a pas exigé d’ouvrir largement des ports de gestion entrants sur le réseau de trading.
2. Séparer la disponibilité du contrôle de celle des charges de travail. Les Routes et les services en cours continuaient de fonctionner lorsque Opfield lui-même était temporairement indisponible. Le plan de contrôle coordonnait les changements, mais ne faisait pas transiter le trafic applicatif ordinaire par son processus web.
3. Relier l’état avant d’automatiser le changement. L’équipe a d’abord utilisé Opfield pour établir l’inventaire, les identités, l’état de santé et les relations. L’automatisation est venue une fois que l’état affiché correspondait à la réalité.
4. Appliquer une exploitation limitée par les permissions. Les actions courantes sont passées à des processus tenant compte des permissions. Les changements lourds de conséquences exigeaient toujours une revue explicite par un opérateur et une vérification.

Ce qui a changé au quotidien

Les opérateurs de Remedy suivent l’infrastructure qui entoure un service de trading dans un seul produit. Ils passent d’une route publique à son certificat, à la charge de travail en amont, à l’état de santé du nœud, aux journaux récents et à l’historique des opérations sans avoir à traduire les noms d’un tableau de bord à l’autre.

Pendant les incidents, cela a réduit la tentation de faire des changements de grande ampleur avant d’en comprendre l’impact. L’équipe pouvait distinguer un problème du plan de contrôle d’un problème d’exécution, laisser en place les charges de travail saines et n’utiliser la maintenance ou le retour arrière que sur le chemin concerné. L’observabilité est devenue une partie du processus d’exploitation plutôt qu’un tableau de bord consulté après le déploiement.

Le même modèle a aussi amélioré le contrôle d’accès. Les personnes travaillant sur les applications n’avaient pas besoin d’une administration illimitée des hôtes pour les déploiements ou les diagnostics courants, tandis que les responsables de l’infrastructure conservaient l’accès de bas niveau nécessaire à la reprise.

Résultat

Le code de recherche, la logique d’exécution et la connectivité au marché de Remedy sont restés tels quels. Le déploiement, l’accès, l’état de santé des services, TLS, les journaux et la reprise passent désormais par un seul produit, et le chemin d’exécution ne dépend pas de la disponibilité d’Opfield.

« Dans une infrastructure de trading, le déploiement et l’observabilité ne peuvent pas être des sujets séparés. Opfield garde la couche d’exploitation cohérente sans gêner l’exécution. »

Poursuivez avec Préparation à la production et Runbook d’incident pour le modèle d’exploitation utilisé dans cet environnement.