Infrastructure

L'infrastructure du Bot de Trading ByNinja est conçue pour un fonctionnement autonome de longue durée dans des environnements réels instables. Les systèmes de trading crypto doivent rester opérationnels 24h/24 et 7j/7, se remettre automatiquement des pannes inattendues et minimiser les temps d'arrêt sans nécessiter d'intervention manuelle.

Pour y parvenir, l’infrastructure inclut :

• •Boucles d’exécution Watchdog
• •Récupération automatique après crash
• •Orchestration du redémarrage des processus
• •Gestion gracieuse de l'arrêt
• •Environnement d'exécution persistant
• •Exécution de module isolée

L'architecture entière est construite autour de la tolérance aux pannes et de la continuité opérationnelle.

La couche d'exécution principale du système est contrôlée via un script de lancement watchdog dédié :

./run.sh trading
./run.sh telegram

Le script watchdog agit comme un superviseur de processus léger responsable de :

• •Validation de l'environnement
• •Activation de l'environnement virtuel
• •Démarrage du module
• •Détection de crash
• •Gestion du redémarrage automatique

Cette approche évite le besoin de gestionnaires de processus externes pendant le développement ou les déploiements légers tout en offrant une résilience de style production.

Avant de démarrer un module, le script valide :

• •Arguments d'entrée
• •Existence de l'environnement virtuel
• •Configuration runtime

Exemple :

if [[ "$MODULE" != "trading" && "$MODULE" != "telegram" ]]; then
    echo "Invalid argument"
    exit 1
fi

Le script s’assure également que l’environnement virtuel Python existe :

if [ ! -f "$VENV_PATH" ]; then
    echo "Virtual environment not found"
    exit 1
fi

Cela empêche un démarrage accidentel avec des dépendances cassées ou des paramètres d'exécution incorrects.

L'infrastructure active un environnement virtuel Python dédié avant l'exécution :

source "./env/bin/activate"

Cela garantit :

• •Isolation des dépendances
• •Versions de paquets stables
• •Comportement d'exécution reproductible
• •Séparation propre du déploiement

Le lanceur définit également explicitement PYTHONPATH :

PYTHONPATH="$(pwd)/src" python3 -c "$CMD"

Cela garantit des imports fiables, quel que soit le contexte du shell actuel ou l'emplacement du déploiement.

L'une des fonctionnalités d'infrastructure les plus importantes est la boucle de redémarrage automatique.

Le lanceur surveille en continu le processus du bot :

while true; do
    PYTHONPATH="$(pwd)/src" python3 -c "$CMD"
done

Si le processus se termine de manière inattendue, le watchdog détecte immédiatement la panne et relance le module automatiquement.

Logique de détection de crash :

EXIT_CODE=$?

if [ $EXIT_CODE -ne 0 ]; then
    echo "[CRASH] Restarting..."
    sleep $RESTART_DELAY
fi

Cela crée un modèle d’exécution auto-cicatrisant capable de se remettre de :

• •Exceptions inattendues
• •Pannes réseau
• •Pannes API
• •Interblocages
• •Instabilité temporaire du système
• •Terminaison de processus externe

L'infrastructure ajoute intentionnellement un temps de repos avant redémarrage :

RESTART_DELAY=3

Cela empêche :

• •Boucles de redémarrage rapide infinies
• •Pics de CPU lors de crashes répétés
• •Sollicitation excessive de l'API
• •Inondation des journaux

Le court délai donne aux systèmes externes le temps de se rétablir avant de réessayer l’exécution.

Le système sépare l'infrastructure en deux services redémarrables indépendamment :

Cette isolation offre plusieurs avantages :

• •Un sous-système peut tomber en panne indépendamment
• •La surveillance Telegram peut rester en ligne pendant les crashes du trading
• •Le trading peut continuer même si Telegram échoue
• •Débogage et maintenance plus faciles

Les modules communiquent via la couche TCP interne plutôt que par couplage direct.

L'infrastructure prend en charge un comportement d'arrêt contrôlé en utilisant la gestion des signaux.

Exemple :

signal.signal(signal.SIGINT, signal_handler)

À l'arrêt :

• •Le trading s’arrête en toute sécurité
• •La persistance est vidée sur le disque
• •Les connexions TCP se ferment proprement
• •Les threads se terminent gracieusement

Exemple de flux d'arrêt :

🛑 Shutdown signal received...
💾 Forcing save to disk...
✅ PersistentMap stopped

Ceci est essentiel dans les systèmes de trading car des arrêts inappropriés pourraient autrement conduire à :

• •Perte de l'état de la position
• •Corruption de la persistance
• •Données de récupération incohérentes
• •Ordres non clôturés

L'infrastructure suit un principe simple mais puissant :

Crash → Detect → Restart → Recover State → Continue Trading

Le bot est conçu en partant du principe que les crashes sont inévitables dans les systèmes distribués fonctionnant longtemps.

Au lieu d'essayer de prévenir chaque défaillance possible, l'architecture se concentre sur :

• •Détection rapide
• •Redémarrage fiable
• •Récupération d’état persistant
• •Continuité opérationnelle

Cela augmente considérablement la fiabilité à long terme.

L'infrastructure travaille en étroite collaboration avec le sous-système de persistance.

Avant l’arrêt ou le redémarrage :

• •L'état d'exécution est sauvegardé
• •Les positions sont persistées
• •La configuration reste intacte
• •Les métadonnées de récupération sont stockées

Après le redémarrage :

• •L'état se recharge automatiquement
• •Le trading reprend en toute sécurité
• •Les positions existantes sont restaurées
• •La connectivité Telegram revient automatiquement

Cela crée un pipeline de récupération résilient même après des crashes inattendus ou des redémarrages de serveur.

Le sous-système Telegram agit également comme une couche de surveillance opérationnelle légère.

Les événements d’infrastructure sont transférés directement à Telegram :

[CRASH] Module trading exited with code 1
Restarting in 3 seconds...

Cela donne aux opérateurs une visibilité instantanée sur :

• •Crashes
• •Redémarrages
• •Arrêts
• •Événements de récupération
• •Problèmes de connectivité TCP

Le résultat est une infrastructure observable à distance sans nécessiter de tableaux de bord de surveillance complexes.

L'infrastructure ByNinja combine plusieurs concepts opérationnels de qualité production :

• •Boucles d'exécution Watchdog
• •Récupération automatique après crash
• •Gestion gracieuse de l'arrêt
• •État d'exécution persistant
• •Isolation des services
• •Comportement de redémarrage auto-cicatrisant
• •Surveillance à distance via Telegram
• •Récupération indépendante des sous-systèmes

Ensemble, ces composants créent une infrastructure capable de supporter des opérations de trading autonomes continues avec une supervision manuelle minimale.