Automatisation

Auto-réparation d'un service qui plante

Quand un service tombe, l'agent tente de le redémarrer avant même que tu le remarques

Hermèsn8n + IAAvancéAutonome

Le besoin

Les services web tombent pour des raisons prévisibles (mémoire saturée, processus zombie, lock de base) qui ont souvent des remèdes standard.

  • Réveiller un humain pour un redémarrage simple à 3h du matin n'a aucun sens.
  • Un agent peut exécuter le playbook de remédiation et n'alerter que sur les cas vraiment complexes.

L'approche

  • Définis un health check pour chaque service (HTTP 200, ping, requête DB test)
  • Un cron toutes les 2 minutes vérifie l'état de chaque service
  • En cas d'échec, l'agent exécute le playbook de remédiation : redémarrage, nettoyage, rollback
  • Il reteste après chaque action et passe à l'étape suivante si le service ne revient pas
  • Si le playbook complet échoue, alerte humaine immédiate avec diagnostic complet

Étape par étape

  1. 1

    Cataloguer les services et leurs remèdes

    Pour chaque service critique, écris un playbook : quel health check, quelle séquence d'actions en cas d'échec, quand abandonner et alerter. Ce travail préparatoire est la clé.

  2. 2

    Implémenter le health check et la boucle de surveillance

    Configure un cron fréquent qui appelle chaque health check et déclenche l'agent de remédiation en cas d'échec. Utilise un compteur d'échecs consécutifs pour éviter les faux positifs.

  3. 3

    Tester les scenarios de panne en conditions réelles

    Simule chaque type de panne (kill manuel du processus, saturation mémoire artificielle) pour vérifier que le playbook fonctionne correctement avant de t'y fier en production.

Le prompt à donner

Le service API sur le port 3001 ne répond plus au health check depuis 3 minutes. Essaie de le redémarrer, vérifie les logs pour la cause, et si ça ne revient pas en 2 minutes, prépare un résumé de l'incident.

Le résultat

L'agent redémarre le service, confirme qu'il répond au health check, lit les dernières lignes de log pour identifier la cause (OOM killer) et envoie un résumé de l'incident avec la durée de l'interruption.

Le verdict NXUS

Indispensable pour les projets en production sans équipe ops dédiée. La robustesse dépend de la qualité des playbooks écrits au départ.

Cas d'usage similaires

Apprends à piloter tes propres agents IA

Nos formations t'apprennent à transformer ces cas d'usage en automatisations concrètes pour ton métier.

Voir les formations