Étude de cas d'ingénierie · Instagram Automation Platform
Coordonner l'automatisation de navigateur, la surveillance temps réel et l'exécution multi-comptes
Une plateforme d'automatisation pilotée par le web gère plusieurs sessions de navigateur Instagram persistantes, des workflows parallèles, des délais de repos, la détection du statut des comptes et des journaux en temps réel.
- Rôle
- Architecture Python, automatisation de navigateur, conception de la concurrence, implémentation du tableau de bord, persistance, outils de débogage et documentation client.
Responsabilités du système
- Automatisation
- Intégration IA
Technologies
- Python
- Flask
- Socket.IO
- Playwright
- AsyncIO
- SQLite
- OpenAI Vision
Preuves vérifiées
7 résultats vérifiés documentés ci-dessous.
Aperçu
Les opérateurs devaient faire fonctionner plusieurs comptes de façon indépendante depuis une interface web, avec des sessions authentifiées préservées, des délais de repos respectés et l'état de santé des comptes visible en temps réel.
- Faire fonctionner plusieurs comptes de façon indépendante.
- Préserver les sessions de navigateur authentifiées.
- Contrôler l'automatisation depuis une interface web.
- Diffuser les journaux en temps réel.
- Respecter les délais de repos et les limites quotidiennes.
- Détecter les comptes suspendus ou désactivés.
- Prendre en charge plusieurs formats d'import client.
Le problème
L'automatisation de navigateur multi-comptes devient instable lorsque les sessions de navigateur, les threads du serveur web et les tâches asynchrones se disputent le contrôle. Le système avait aussi besoin de sélecteurs résilients, d'un état persistant et d'une visibilité pour l'opérateur.
Contraintes qui ont façonné le système
- Flask et Socket.IO fonctionnent selon un modèle de concurrence différent de Playwright asynchrone.
- Les interfaces de navigateur changent.
- Les sessions de compte nécessitent une isolation.
- Les opérateurs ont besoin de contrôles d'arrêt.
- L'état de l'automatisation doit survivre aux redémarrages.
- Les données de compte client arrivent dans des formats hétérogènes.
Architecture du système
Flask et Socket.IO fournissent le plan de contrôle, tandis que des threads de travail isolés possèdent chacun leur propre boucle d'événements asyncio pour les workflows de navigateur. SQLite stocke l'état opérationnel, des répertoires de navigateur persistants préservent les sessions, et une journalisation par callback relie les workers au tableau de bord.
client
Tableau de bord opérateur
Décisions d'ingénierie clés
Isoler les boucles d'événements par worker
AcceptéFlask et Socket.IO fonctionnent selon un modèle de concurrence différent de Playwright asynchrone.
Chaque worker d'automatisation possède sa propre boucle asyncio au sein d'un thread dédié.
Pourquoi
- Éviter les erreurs Playwright inter-boucles.
- Garder le plan de contrôle web réactif.
- Isoler les échecs par compte.
Registre externe de sélecteurs
AcceptéLes interfaces de navigateur changent, et disperser les sélecteurs dans les scripts rend la maintenance fragile.
Stocker des sélecteurs ordonnés en JSON plutôt que de les disperser dans les scripts.
Pourquoi
- Maintenance centralisée.
- Les sélecteurs stables sont priorisés en premier.
- Débogage et comportement de repli facilités.
Alternatives envisagées
- Sélecteurs dispersés directement dans les scripts d'automatisation
Sessions persistantes
AcceptéLes sessions de compte nécessitent une isolation, et l'état de l'automatisation doit survivre aux redémarrages.
Attribuer à chaque compte son propre répertoire de données Chromium.
Pourquoi
- Réduire les connexions répétées.
- Isoler les cookies et l'état.
- Faciliter la récupération manuelle.
Points clés de l'implémentation
- Utilitaires d'interaction proches du comportement humain.
- Délais de repos et historique de contact.
- Import de comptes multi-formats.
- Compréhension optionnelle des stories via des modèles de vision.
- Six modules opérationnels.
- Scripts de déploiement Windows et VPS.
- Documentation d'architecture et client détaillée.
Qualité et exploitation
Tests
- Couverture Pytest pour la logique centrale.
- Outils de débogage dédiés.
Exploitation
- Événement d'arrêt partagé en toute sécurité avec les workers.
- Journaux de callback en temps réel.
- Détection des états suspendus et désactivés.
Résultats et preuves
- Fait d'implémentation
Boucle d'événements asyncio isolée par thread de travail
- Fait d'implémentation
Sessions Chromium persistantes par compte
- Fait d'implémentation
Stratégie de sélecteurs externalisée
- Métrique vérifiée
Modules opérationnels6
- Capacité observable
Journaux opérationnels en temps réel
- Fait d'implémentation
Scripts de déploiement Windows et VPS
- Fait d'implémentation
Documentation client livrée
Leçons tirées du système
- Les frontières de concurrence doivent être explicites.
- L'automatisation de navigateur nécessite de l'observabilité et des outils de récupération.
- La stratégie de sélecteurs est une préoccupation de maintenabilité, pas un détail d'implémentation mineur.