Leçons tirées de l'exploitation de plusieurs passerelles OpenClaw en production

Défaillances en production et leurs causes

Un développeur faisant fonctionner 3+ passerelles OpenClaw 24h/24 et 7j/7 pour un usage personnel, une organisation à but non lucratif et une organisation communautaire a connu des défaillances répétées en production en traitant les modifications d'OpenClaw comme du travail brouillon plutôt que comme des déploiements en production.

Scénarios de défaillance spécifiques

La mise à niveau qui ne voulait pas mourir : L'exécution de pnpm add -g openclaw@latest a fait planter la passerelle avec MODULE_NOT_FOUND car la nouvelle version s'est installée sur un chemin différent alors que le fichier de service avait l'ancien chemin codé en dur. Un script de secours qui redémarrait toutes les 5 minutes ne pouvait pas distinguer les plantages transitoires (où le redémarrage fonctionne) des défaillances structurelles (nécessitant d'abord des corrections du fichier de service).

Perte silencieuse de capacités : Après avoir configuré de nouvelles intégrations et redémarré la passerelle, des capacités comme la synthèse vocale pour l'accessibilité du tableau, l'envoi d'e-mails et la publication sur X.com semblaient configurées mais étaient en réalité cassées en raison de clés API dans de mauvaises sections de configuration ou d'identifiants expirés. Ces défaillances sont restées non détectées pendant des jours.

Analyse de la cause racine

La configuration de la passerelle OpenClaw est répartie sur au moins cinq emplacements :

• Fichier JSON principal
• Variables d'environnement dans les fichiers de service
• Indicateurs Docker
• Blocs de fournisseurs
• Compétences avec leurs propres identifiants

La rotation d'une clé à un emplacement laisse les autres obsolètes. La mise à niveau d'OpenClaw casse les chemins codés en dur. La mise à jour d'une compétition fait que les identifiants cessent silencieusement de se charger. Ce sont des régressions que le CI/CD détecterait dans le développement logiciel, mais il n'y avait pas de CI pour l'infrastructure de la passerelle.

Solution mise en œuvre

Audit de capacités : Avant et après tout changement :

• Analyser la configuration pour énumérer les capacités revendiquées
• Vérifier que chacune fonctionne réellement avec des tests d'API en direct (délai d'attente de 5 secondes)
• Différencier les instantanés avant/après

Portail de validation de configuration : Pas de modifications directes de la configuration en direct :

• Vérification de la validité JSON
• Sauvegardes horodatées
• Bloque les modèles dangereux connus

Environnement reproductible :

• Fichiers de service indépendants de la version (pas de chemins codés en dur)
• Un fichier d'identifiants canonique, dont tout le reste découle
• Détection de boucle de plantage (3 échecs = mode diagnostic, pas mode redémarrage)

Détecteur de régression :

• Comparaison quotidienne avec une base de référence connue comme bonne
• Classer les changements en amélioration vs. dégradation
• Alerte en cas de perte de capacité

Le développeur partage ce travail tôt et demande aux autres opérateurs d'infrastructure IA : "Comment gérez-vous la gestion des passerelles ?" et "Quelle est votre stratégie de test pour votre openclaw ?"