Informations sur la communauté et sentiment du marché #devops

Une fois que le système d'automatisation est en marche, comment surveiller s'il est toujours actif ?

C'est la leçon la plus profonde que j'ai tirée après avoir mis en place plusieurs pipelines d'automatisation : **le système ne doit pas tomber en panne au milieu de la nuit et vous laisser le découvrir le lendemain**.

J'avais déjà déployé une tâche cron, pensant qu'une fois configurée, je pouvais la laisser tourner sans souci. Après une semaine, en vérifiant l'état, je me suis rendu compte qu'elle avait silencieusement cessé de fonctionner depuis 3 jours — la connexion à la base de données était rompue, sans aucune notification. Depuis, j'ai établi une philosophie de surveillance complète, que je partage avec vous aujourd'hui.

**Premier niveau : Surveillance de la fréquence d'exécution**

La méthode de base est de vérifier le last_run_at de cron. Ma règle est : **si le dernier temps d'exécution dépasse le double du cycle attendu, déclencher immédiatement une alerte**. Par exemple, une tâche qui devrait s'exécuter toutes les 5 minutes, si last_run_at dépasse 10 minutes, j'envoie directement une alerte sur Telegram. Ce critère est extrêmement efficace — environ 90% des "systèmes plantés" peuvent être détectés en moins d'une heure, au lieu d'attendre passivement que le service constate le problème.

**Deuxième niveau : Mécanisme de coupure d'API**

L'instabilité des API est la norme. Ma méthode est : **si 3 requêtes API échouent consécutivement, couper automatiquement pendant 24 heures**. Pourquoi 3 fois ? Parce que 1-2 échecs peuvent être dus à une instabilité réseau, mais 3 échecs consécutifs signifient qu'il y a vraiment un problème. Pendant la période de coupure, le système n'essaie plus d'appeler, évitant ainsi de gaspiller des quotas API et de l'espace log dans un état erroné. C'est beaucoup plus efficace que de réessayer aveuglément.

**Troisième niveau : Persistance des fichiers d'état**

Chaque fois que le système s'exécute, j'écris l'état actuel — le nombre de succès, le nombre d'échecs, le timestamp, les messages d'erreur — dans un fichier d'état. Je conserve ce fichier avec une historique de 30 jours. Quel est l'avantage ? Cela permet de revenir en arrière — "Pourquoi le taux de publication a-t-il soudainement chuté à 60% mercredi dernier ?" — il suffit de consulter les logs pour avoir la réponse. Le fichier d'état ne prend pas de place, mais me fournit une chaîne d'audit complète.

**Quatrième niveau : Examen manuel hebdomadaire**

Chaque semaine, je consacre 15 minutes à faire générer automatiquement un rapport récapitulatif par le système : taux de succès des publications, distribution des taux d'erreur, statistiques de mots, anomalies potentielles. Pas besoin que ce soit trop fréquent, mais **il ne faut pas totalement se fier aux alertes automatiques**. Parfois, une tendance d'augmentation du taux d'erreur de 2% à 4% ne sera pas signalée par la surveillance automatique, mais une inspection manuelle permettra de voir immédiatement "il faut commencer à prêter attention ici".

**Compréhension clé**

Mettre en place l'automatisation est rapide, mais **si la surveillance est bien faite, on peut vraiment se reposer sans garder un œil dessus**. Mon expérience est la suivante : les alertes automatiques s'occupent des urgences (système complètement planté), tandis que l'examen manuel s'occupe des problèmes de tendance (détérioration progressive). La combinaison des deux permet à ce système de durer. Sinon, même la meilleure automatisation n'est qu'une bombe à retardement dans une boîte noire.

$BTC #DevOps #automatisation

devops

La santé d’un nœud au-delà de la disponibilité

ICPay — Fiabilité du protocole : mises à niveau de canister sans interruption et sécurité de l’état

devops

La santé d’un nœud au-delà de la disponibilité

ICPay — Fiabilité du protocole : mises à niveau de canister sans interruption et sécurité de l’état

Sujets d’actualité