Reliez chaque alerte à un impact métier, définissez qui intervient et préparez les vérifications utiles pour réduire les notifications sans suite.
Une notification arrive parce que le processeur d’un serveur dépasse un seuil. Faut-il interrompre la personne qui exploite l’application ? La réponse dépend du service rendu, de la durée du phénomène et des conséquences observées. Un traitement prévu peut utiliser beaucoup de ressources sans empêcher les utilisateurs de travailler.
Avant d’ajouter une règle, écrivez l’action attendue à sa réception. Si personne ne peut la formuler, gardez la mesure disponible pour l’analyse et poursuivez le travail de qualification. Une petite équipe gagne à savoir pourquoi elle est appelée et ce qu’elle doit vérifier en premier.
Décrire le service qui doit rester disponible
Choisissez un parcours : consulter un stock, enregistrer une commande, transmettre un devis. Discutez avec son responsable des périodes où une panne bloque effectivement le travail. Un export nocturne a une échéance ; un formulaire client peut être sollicité à toute heure.
Dans son chapitre consacré à la supervision des systèmes distribués, Google distingue les symptômes visibles et les causes internes. Les signaux proposés comprennent la latence, le trafic, les erreurs et la saturation. Cette distinction aide à séparer le déclenchement d’une intervention des informations utilisées ensuite pour comprendre le problème.
Pour votre formulaire, mesurez par exemple les soumissions abouties et les échecs techniques. Une validation refusée parce qu’un champ manque doit être interprétée selon votre parcours métier. Confondre ces refus avec une indisponibilité empêche de savoir si le service fonctionne normalement.
Fixer un seuil avec son contexte
Un taux d’erreur sans volume est difficile à interpréter. Dans un exemple fictif, une seule erreur parmi deux demandes produit un taux de 50 %. Cela ne décrit pas la même situation que cinq cents échecs sur mille demandes. Conservez les deux informations dans le message ou son tableau de bord.
Définissez aussi la fenêtre d’observation. Une règle déclenchée à la première mesure répond vite, mais peut appeler pour un incident très bref. Une fenêtre plus longue retarde la réaction. Choisissez ce compromis avec la personne responsable du service, à partir de la conséquence d’une attente supplémentaire.
Pour un traitement planifié, l’absence de résultat à l’échéance peut être plus utile que la consommation du serveur qui l’exécute. Écrivez ce que signifie « terminé » : fichier créé, données contrôlées et disponibles pour l’équipe suivante. Adaptez les seuils au calendrier réel du traitement.
Donner un destinataire et un chemin de relève
Une alerte envoyée à une boîte commune sans règle de prise en charge reste facile à manquer. Désignez le rôle responsable, les horaires couverts et la procédure lorsque personne ne répond. Ne promettez pas une intervention permanente si votre contrat ou votre organisation ne la prévoit pas.
Prévoyez deux niveaux de traitement lorsque cela correspond à vos moyens : une intervention immédiate pour un service bloqué, et un ticket pour une anomalie qui peut attendre. Les recommandations de Prometheus sur les alertes privilégient des notifications qui appellent une action et insistent sur la supervision du dispositif de surveillance lui-même.
Testez la réception jusqu’au destinataire. Une règle qui passe correctement à l’état d’alerte peut encore échouer au niveau de son routage. Vérifiez les coordonnées, les droits d’accès au tableau de bord et les conditions de relève lorsque le titulaire est absent.
Écrire un message utilisable depuis un téléphone
Le destinataire doit identifier rapidement le service et son environnement. Une proposition de format pour une alerte de transmission de commandes peut contenir :
- le parcours concerné et l’heure de début observée ;
- le nombre d’échecs et le volume total sur la période ;
- un lien vers la recherche ou le tableau de bord pertinent ;
- la première vérification autorisée et le contact d’escalade.
Évitez les liens qui ouvrent seulement la page d’accueil d’un outil. Préparez une vue filtrée, puis vérifiez qu’un autre membre de l’équipe peut l’ouvrir. Le guide de journalisation applicative décrit les identifiants utiles pour retrouver l’opération concernée.
Le message ne doit pas contenir de secret ni recopier une demande client. Il suffit généralement d’une référence technique dont l’accès détaillé reste soumis aux droits de l’application.
Prévoir les premières vérifications
Dans la fiche d’intervention, commencez par confirmer le périmètre : toutes les demandes ou seulement certaines, depuis quelle version, sur quelle dépendance. Mentionnez les opérations qui exigent un accord supplémentaire. Relancer un traitement peut créer des effets métier ; le redémarrage ne doit pas devenir une réponse automatique à chaque notification.
Si l’anomalie suit un déploiement, la personne d’astreinte doit trouver la décision de reprise déjà préparée. Notre article sur le retour arrière avec une base de données détaille les différences entre restauration, correction et retour à une version précédente.
Ajoutez un critère de fin d’incident. Le retour d’une mesure sous son seuil ne suffit pas toujours : vérifiez aussi les opérations accumulées pendant la panne et celles qui nécessitent une reprise manuelle.
Revoir les notifications avec leurs suites
Après une période d’utilisation, reprenez les alertes reçues avec les tickets correspondants. Classez celles qui ont conduit à une action, celles qui étaient redondantes et celles qui n’avaient pas de destinataire disponible. Consignez la modification décidée pour chaque règle problématique.
Une maintenance planifiée peut justifier une suspension temporaire. Donnez-lui une heure de fin et conservez une trace de son auteur. Après la maintenance, vérifiez la reprise effective de la surveillance ainsi qu’une demande métier complète. Cela évite de découvrir au prochain incident qu’une règle était encore désactivée.