DFK Algotrade

Ingénierie et exploitation fintech

dfk-algotrade.com

DFK Algotrade développe des logiciels financiers et exploite des systèmes liés à la gestion de portefeuille, au trading, aux données et au risque. Dans cet environnement, la vitesse de déploiement compte, mais la prévisibilité des changements compte davantage. Une mise à jour du plan de contrôle peut affecter l’accès, le routage, la livraison des applications, les bases de données et la capacité de l’équipe à diagnostiquer tout le reste.

L’incident qui a changé l’exigence

L’équipe avait auparavant exploité un environnement dans lequel une mise à jour automatique de Coolify avait provoqué une panne en production. La leçon : la disponibilité d’une version, son approbation, le moment du déploiement, la compatibilité des données et les preuves de reprise sont des décisions distinctes.

La panne a révélé une faiblesse plus large du modèle d’exploitation. L’équipe pouvait rétablir le service, mais le processus de mise à jour ne partait pas d’une réponse commune à plusieurs questions : quelle version exacte est approuvée ? Quel état doit être sauvegardé ? Qu’est-ce qui déclencherait un retour arrière ? Quels chemins exposés aux clients prouvent que la mise à jour a réussi ? Quelles parties peuvent être modifiées indépendamment ?

DFK voulait maîtriser chaque changement de son infrastructure, et pas seulement disposer d’un bouton de mise à jour.

Une adoption autour de la discipline de mise à jour

DFK est passé à Opfield en même temps qu’à une procédure de mise à jour convenue entre l’ingénierie et l’exploitation.

1. Séparer la découverte de l’approbation. Le canal de mise à jour choisi pouvait signaler une version disponible sans modifier l’installation en cours. Un opérateur choisissait la cible et la fenêtre de maintenance.
2. Consigner les éléments de reprise. Avant tout changement, l’équipe notait les versions en cours et les empreintes (digests) des images, vérifiait les sauvegardes de PostgreSQL et de l’état persistant, et préservait le matériel de chiffrement et d’identité.
3. Mettre à jour par domaine de panne. Opfield, les membres Relay et les nœuds gérés n’étaient pas traités comme un seul événement simultané. Les composants pouvaient être vidés, mis à jour, vérifiés et remis en service avant de poursuivre.
4. Vérifier le système réel. Un conteneur en cours d’exécution n’était pas considéré comme un succès. La connexion, le déchiffrement, la reconnexion des nœuds, les routes, les liaisons de bases de données, les journaux, l’automatisation et le trafic externe formaient les critères d’achèvement.

Les versions et artefacts de démons signés ne laissent aucun doute sur ce qui est installé, et les tâches et enregistrements d’audit gardent chaque décision visible une fois la fenêtre de maintenance terminée.

Ce qui a changé au-delà des mises à jour

La même discipline a amélioré la livraison applicative ordinaire. DFK pouvait conserver un déploiement réputé sain, utiliser des chemins de déploiement contrôlés par des vérifications de santé lorsque c’était pertinent, et distinguer le retour arrière applicatif de la restauration de données. Les opérateurs sont devenus moins enclins à supprimer ou recréer l’infrastructure simplement parce qu’un déploiement avait échoué.

Les relations au sein de l’infrastructure sont aussi devenues plus faciles à inspecter. Les services financiers, les connexions privées aux bases de données, les routes, les certificats et l’état de santé des hôtes n’étaient plus des fragments séparés dans les discussions de mise à jour. L’équipe pouvait déterminer quelle couche avait changé et éviter de transformer une panne locale en incident à l’échelle de la plateforme.

Résultat

Les mises à jour sont devenues des décisions d’exploitation planifiées, avec une responsabilité, des éléments de reprise et une vérification explicites. DFK a gardé la maîtrise du calendrier des mises à jour tout en gagnant un chemin plus clair pour adopter les nouvelles fonctionnalités d’Opfield, sans laisser le rythme de publication de l’éditeur dicter les changements en production.

« Après qu’une mise à jour de Coolify a mis un environnement de production hors service, nous avons cessé de voir les mises à jour automatiques comme un confort. Opfield nous donne un processus de mise à jour que nous pouvons revoir, planifier et vérifier avant d’aller plus loin. »

Poursuivez avec Mises à jour et sauvegardes et Cycle de vie et sécurité pour les procédures qui sous-tendent ce cas.