Leçons apprises en opérant des bots de trading en production
Les plus grandes leçons que j'ai apprises ne viennent pas de l'écriture du code. Elles viennent de l'observation d'un logiciel qui fonctionne en continu dans le monde réel.
Construire un bot de trading est un défi. En opérer un en production pendant des mois en est un tout autre.
Quand j'ai commencé Oblivion, je pensais que la majorité du travail aurait lieu pendant le développement. Une fois la plateforme arrivée en production, j'imaginais que le progrès consisterait surtout à ajouter de nouvelles fonctionnalités et à raffiner celles qui existaient déjà.
La réalité s'est révélée très différente.
Faire tourner un logiciel en continu enseigne des leçons difficiles, voire impossibles, à apprendre en développant localement.
La production est le meilleur professeur
Les environnements de développement sont confortables. Tout est prévisible. Tu décides quand l'application démarre. Tu décides quand elle s'arrête. Tu contrôles les données.
La production retire ce confort.
Les marchés continuent de bouger pendant que tu dors. Les services externes évoluent sans prévenir. Les situations inattendues apparaissent naturellement avec le temps.
Au lieu de demander si le logiciel fonctionne, la production pose constamment une autre question :
Va-t-il continuer à fonctionner demain ?
Cette distinction a changé ma manière de penser le logiciel.
Les événements rares deviennent courants
Une observation intéressante est que les situations inhabituelles cessent d'être inhabituelles quand un logiciel tourne assez longtemps.
Un timeout d'API qui arrive une fois toutes les plusieurs milliers de requêtes peut sembler insignifiant.
Une perte temporaire de connectivité peut paraître inoffensive.
Une réponse inattendue d'un exchange peut ressembler à un cas limite.
Pourtant, une plateforme qui fonctionne en continu finira par rencontrer tout cela.
L'objectif n'est donc pas d'éliminer chaque situation inattendue. L'objectif est de s'assurer que les situations inattendues restent gérables.
La récupération compte plus que la perfection
Au début du projet, j'ai passé beaucoup de temps à essayer d'empêcher les échecs entièrement.
Avec le temps, j'ai compris que la perfection est un objectif irréaliste. Les échecs arrivent. Les dépendances deviennent indisponibles. Les réseaux deviennent instables. Les processus redémarrent parfois.
La vraie question n'est pas de savoir si quelque chose va échouer. C'est de savoir à quelle vitesse et avec quel niveau de sécurité la plateforme récupère ensuite.
Ce changement de perspective a influencé beaucoup de décisions d'ingénierie.
Au lieu de supposer des conditions idéales, j'ai commencé à supposer que quelque chose finirait par mal se passer.
Étonnamment, concevoir autour de cette hypothèse produit souvent des solutions plus simples et plus résilientes.
L'observabilité change tout
Une autre leçon est apparue à mesure que la plateforme mûrissait. Les problèmes sont beaucoup moins intimidants quand on comprend ce qui se passe.
Logs. Métriques. Indicateurs de statut. Health checks. Monitoring.
Ces outils n'empêchent pas les échecs. Ils réduisent l'incertitude.
Plus vite on comprend un problème, plus vite on peut décider si une intervention est réellement nécessaire.
Une bonne observabilité crée de la confiance, pas seulement pour les développeurs, mais aussi, à terme, pour les utilisateurs.
La stabilité crée de la liberté
Une conséquence inattendue d'une plateforme stable, c'est qu'elle change la manière de travailler.
Au lieu de réagir constamment à des problèmes opérationnels, on gagne du temps pour améliorer le produit lui-même.
Moins de temps à corriger des urgences. Plus de temps à concevoir de meilleures solutions. Plus de temps à penser au futur au lieu de répondre sans cesse au présent.
La fiabilité devient donc plus qu'un objectif technique. Elle devient un multiplicateur pour le développement futur.
Avec le recul
La plus grande leçon que la production m'a peut-être apprise, c'est que le logiciel n'est jamais vraiment terminé.
Il évolue. Il s'adapte. Il s'améliore par l'observation.
Chaque semaine de fonctionnement continu révèle quelque chose de nouveau.
Parfois, c'est une faiblesse. Parfois, c'est la confirmation qu'une décision d'architecture était la bonne.
Les deux résultats ont de la valeur.
Avec le recul, je ne vois plus la production comme la dernière étape du développement.
Je la vois comme l'environnement où le développement commence vraiment.
Parce que c'est là que les hypothèses rencontrent la réalité, et que le logiciel devient progressivement assez mature pour mériter la confiance des gens.