1. Commencez à partir d’un moniteur de disponibilité existant et ouvrez ses paramètres d’alerte
Si vous avez déjà une vérification en cours, vous êtes à mi-chemin. Il ne s’agit pas maintenant de mettre en place un suivi de disponibilité complet d’un site web à partir de zéro ; il s’agit de transformer cette vérification en quelque chose qui alerte la bonne personne au bon moment.
Ouvrez le moniteur que vous voulez surveiller de près, puis cherchez les paramètres d’alerte, les règles de notification ou les options d’incident. L’intitulé exact varie, mais l’objectif reste le même : relier un moniteur actif à une action lorsque des interruptions apparaissent. Si vous cherchez à configurer le tout rapidement, pensez à configurer alertes de disponibilité Astrina au sein du moniteur déjà en place.
C’est ici que la façon de configurer les alertes de disponibilité Astrina étape par étape commence à devenir concrète. Vous ne refondez pas le moniteur. Vous décidez simplement de ce qui doit se passer après que le moniteur a échoué deux fois, cinq fois, ou au moment que votre équipe juge approprié pour être avertie.
Commencez avec un seul service. Si votre page d’accueil, votre page de connexion et votre page de paiement tombent toutes en même temps, un seul moniteur suffit pour démarrer. Cela garde la première alerte simple, et les alertes simples sont lues.
Vérifiez le nom actuel du moniteur, l’URL cible et la fréquence d’exécution avant de toucher aux alertes. Un libellé comme « Connexion prod » est préférable à « Vérification 1 », car votre boîte de réception d’alertes sera moins confuse à 2 h 14 du matin.
2. Choisissez les conditions d’indisponibilité qui doivent déclencher une alerte
Le cœur de la configuration, c’est le déclencheur. Vous avez besoin de seuils d’alerte pour les indisponibilités qui correspondent au service, et non d’une règle générique copiée ailleurs ; définissez bien vos seuils d’alerte indisponibilité site web avant de passer en production.
Un déclencheur courant est constitué d’échecs consécutifs. Deux vérifications en échec peuvent suffire pour un petit outil interne, tandis qu’une page de paiement destinée aux clients peut nécessiter trois échecs ou plus avant d’alerter. Le nombre compte, car un simple raté passager ne devrait pas réveiller l’ingénieur de garde, sauf si le service est déjà fragile.
Les pics de temps de réponse peuvent aussi compter. Un site peut encore renvoyer 200 OK et être, en pratique, inutilisable si la page met trop de temps à se charger, surtout pendant le paiement. Lent n’est pas la même chose qu’en panne, mais les utilisateurs vivent souvent les deux comme un échec.
Les motifs de codes de statut valent aussi la peine d’être surveillés. Une réponse de type 500 mérite généralement une attention plus rapide qu’un 404, tandis qu’un 401 sur un tableau de bord privé peut simplement signifier que la page est protégée. L’astuce consiste à faire correspondre le code attendu au comportement prévu du service.
Choisissez le déclencheur le plus précis qui correspond au service. Si un moniteur concerne une page d’accueil sans connexion, un 403 doit généralement être examiné. S’il s’agit d’un environnement de préproduction, le même code peut être du bruit. Une seule règle ne convient pas à tous les points de terminaison.
Ne rendez pas le seuil trop permissif. Un moniteur qui alerte dès la première vérification manquée peut devenir inutilisable en une semaine. Ne le rendez pas trop strict non plus. Si une vraie panne peut durer 10 minutes avant que quelqu’un soit prévenu, le seuil est trop lent pour un trafic destiné aux clients.
3. Définissez les canaux de notification et orientez les alertes vers les bonnes personnes
Choisissez où l’alerte doit arriver. L’e-mail convient pour une urgence faible, mais le chat, les SMS ou une autre destination de notification sont souvent meilleurs pour une réponse active à un incident. L’idée est de s’assurer que quelqu’un voit l’alerte pendant que l’interruption est encore en cours ; pour une alerte monitoring production, privilégiez le canal où l’équipe réagit le plus vite.
Dirigez chaque alerte vers l’équipe qui peut agir. Une erreur de base de données ne devrait pas atterrir uniquement dans le chat du marketing. Une panne de paiement ne devrait pas rester dans une boîte de réception générale où trois autres personnes pensent que quelqu’un d’autre s’en charge.
Rendez la couverture hors horaires explicite. Si l’équipe de jour reçoit la première alerte et l’équipe de nuit la seconde, notez-le dans les notes du moniteur. Sinon, l’alerte arrivera dans une impasse après les heures ouvrées.
Un moniteur peut envoyer vers plusieurs endroits, mais cela ne veut pas dire qu’il le doit. Deux canaux suffisent pour beaucoup d’équipes : un répondant principal et un secours. Davantage de destinations peuvent produire le mauvais type de bruit.
Pensez à la personne qui reçoit le message à 1 h du matin. Elle a besoin du nom du service, de l’URL en échec et du dernier état connu. « Quelque chose est en panne » n’est pas une alerte ; c’est une énigme.
4. Séparez les alertes de production du bruit lié à la maintenance et aux tests
Les alertes de production doivent avoir leur propre circuit. La maintenance planifiée, les vérifications de préproduction et les fenêtres de déploiement peuvent générer de faux positifs si elles sont mélangées au même flux d’alertes. C’est là qu’une configuration d’alerte bien tenue fait gagner du temps.
Si un déploiement est prévu pendant 15 minutes, mettez le moniteur concerné en sourdine pendant cette fenêtre. Si la préproduction est vérifiée toutes les 5 minutes, gardez-la dans un groupe séparé pour qu’elle ne puisse pas déclencher d’appel au service de production. L’objectif n’est pas de cacher les problèmes ; c’est d’éviter que le bruit de test ressemble à un vrai incident.
C’est différent d’une simple configuration de suivi de disponibilité d’un site web, où la première question est simplement de savoir si une page est accessible. L’alerting est plus sélectif. Il pose une seconde question : faut-il interrompre un humain maintenant ?
Utilisez des noms qui rendent la séparation évidente. « API prod », « API préprod » et « Test de maintenance » sont plus clairs que trois libellés presque identiques. À 3 h du matin, un nom limpide fait gagner plus de temps que n’importe quel jeu de mots.
Les fenêtres de maintenance doivent être limitées dans le temps. Si vous mettez une vérification en sourdine pendant 2 heures et que vous oubliez de la réactiver, le système d’alerte devient aveugle. C’est un mauvais compromis, même si le déploiement initial s’est bien passé.
Petite remarque au passage : les faux positifs paraissent inoffensifs jusqu’au jour où ils se produisent trois fois dans la semaine. Ensuite, tout le monde commence à ignorer la quatrième alerte. C’est là le vrai coût.
5. Ajustez le timing de l’escalade pour que les alertes d’indisponibilité soient exploitables
L’escalade est l’étape où un moniteur devient un processus d’incident. Vous pouvez retarder la première alerte, la répéter après un intervalle donné, ou la transmettre à un autre intervenant si l’incident continue.
Commencez par décider qui doit recevoir la première notification. Cette personne doit pouvoir agir sans chercher le contexte. Si le premier intervenant ne peut pas modifier le service, l’alerte est adressée au mauvais interlocuteur.
Décidez ensuite de ce qui se passe après la première alerte. Une répétition au bout de 10 minutes peut être pertinente pour une panne tenace, tandis qu’un second routage vers un ingénieur de secours peut convenir à une petite équipe qui partage la garde. Le timing doit refléter la rapidité réelle de réponse de votre équipe, pas la rapidité que vous souhaiteriez.
L’escalade n’est pas du spam. Deux notifications peuvent être utiles si la seconde atteint une autre personne avec un autre niveau d’autorité. Six copies dans la même boîte de réception apprennent simplement aux gens à ne plus lire.
Soyez précis sur la conséquence d’une indisponibilité prolongée. Si la première alerte est manquée, la suivante va-t-elle à un manager, à un téléphone de garde ou à un canal d’incident partagé ? Écrivez la séquence dans les notes du moniteur pour que personne n’ait à deviner sous pression.
Une règle aide ici : si le service est orienté client, l’escalade doit être plus rapide. S’il s’agit d’un rapport interne qui peut attendre, le délai peut être plus long. Même plateforme, urgence différente.
6. Vérifiez une alerte de bout en bout avec un test d’indisponibilité contrôlé
Avant de faire confiance à l’alerte en production, testez-la une fois de bout en bout. Vous devez confirmer trois choses : que le moniteur échoue comme prévu, que le seuil se déclenche comme prévu et que la notification atteint la bonne personne.
Utilisez un test contrôlé, pas une vraie panne. Une modification temporaire d’URL, un point de terminaison de test ou une fenêtre de maintenance peuvent suffire à déclencher le moniteur en toute sécurité. L’objectif est de voir toute la chaîne fonctionner sans casser quelque chose d’important juste pour démontrer un point.
C’est l’étape que beaucoup d’équipes sautent. Ensuite, le premier vrai incident devient le premier vrai test, et c’est une façon pénible d’apprendre qu’il y a des erreurs de routage.
Surveillez attentivement la chronologie. Si la vérification échoue à 10 h 00, l’alerte ne devrait pas apparaître à 10 h 17, sauf si le seuil a été réglé ainsi volontairement. Si elle arrive dans le mauvais chat, corrigez cela avant le prochain incident, pas après.
Notez ce qui s’est passé pendant le test. Une simple note avec le nom du moniteur, le déclencheur utilisé, le destinataire et tout délai aidera plus tard quand quelqu’un demandera pourquoi une alerte s’est déclenchée deux fois. Le chiffre 2 compte plus qu’un souvenir vague.
Si vous êtes encore en train de construire le moniteur lui-même, vous voudrez peut-être d’abord configurer l’agent. Le chemin de configuration avec * peut aider lorsque la vérification a besoin d’une nouvelle installation, puis les paramètres d’alerte peuvent être ajoutés par-dessus sans tâtonner.
7. Consultez l’historique des alertes et affinez les seuils après les incidents réels
Les premières alertes vous apprennent plus qu’une semaine de planification. Passez-les en revue après de vrais incidents et cherchez des tendances : faux positifs répétés, alertes arrivées trop tard ou alertes envoyées à la mauvaise équipe.
Si un micro-coupure réseau de 2 minutes a déclenché une alerte, relevez le seuil. Si une panne de 12 minutes n’a produit qu’une seule notification sans escalade, raccourcissez le délai ou ajoutez une voie de suivi. Chaque incident réel vous donne un point de données, et un seul point peut déjà justifier un petit ajustement.
Le bruit est l’ennemi ici. Trop d’alertes à faible valeur ralentissent la réponse des gens, et cela peut transformer une courte interruption en une plus longue. Trop peu d’alertes produisent le même effet dans l’autre sens. Le bon équilibre n’est pas figé pour toujours.
Regardez les codes de statut, l’heure de la journée et le service concerné. Une page de connexion qui échoue deux fois en semaine peut justifier un seuil plus strict que la même page pendant un week-end peu fréquenté. Le contexte compte, car le coût de l’interruption n’est pas le même à toute heure.
Gardez le cycle de revue court au début. Après les 3 à 5 premières alertes, ajustez les notes du moniteur, la liste des destinataires et le timing d’escalade si nécessaire. Cette petite revue peut éviter qu’une alerte bruyante ne devienne une partie du quotidien.
Si vous suivez aussi des parcours utilisateurs associés, comme le paiement, il peut être utile de comparer ce que dit l’alerte avec ce que les utilisateurs ont réellement vu. Une alerte au niveau de la page et une vue au niveau de la session racontent souvent des parties différentes d’une même histoire, et la relecture de session Astrina pour vérifier le paiement peut aider à repérer plus facilement cet écart.
Dernier point pratique : consignez les changements dans le moniteur lui-même, pas seulement dans un fil de discussion. Un commentaire dans Slack disparaît dans le flux. Le moniteur, lui, reste.
