Définir les règles des notifications d'alerting

Une fois que l’entreprise a choisi un ou plusieurs outils de supervision, les administrateurs doivent mettre en place un certain nombre de règles pour éviter de se retrouver submergés d’alertes.

En premier lieu, vous devez définir différents niveaux d’alertes. Ces niveaux peuvent être établis en se basant sur la gravité des événements détectés. Les échelles de gravité varient en fonction des solutions et des équipements concernés. En général, on retrouve les niveaux suivants :
- Niveau 0 : événements purement informatifs
- Niveau 1 : avertissements
- Niveau 2 : événements mineurs, sans conséquences immédiates
- Niveau 3 : événements majeurs, entraînant un dysfonctionnement
- Niveau 4 et 5 : erreurs critiques ou fatales, qui nécessitent une remédiation en urgence.

Vous pouvez aussi définir des seuils, en deçà ou en delà desquels une alerte sera automatiquement déclenchée. Attention à bien délimiter ces seuils : s’ils laissent passer trop d’alertes, le risque est que les destinataires n’y prêtent plus attention à la longue. Inversement, s’ils sont trop élevés, les alertes risquent d’être déclenchées trop tardivement.

Dans tous les cas, il faut tenir compte du caractère critique des équipements et applications supervisés, pour adapter le niveau d’alerte en fonction de l’impact potentiel pour l’entreprise.

Un aspect important du paramétrage est la mise en place du processus d’alerte. Celui-ci permet de définir à qui les alertes doivent être remontées au sein de l’entreprise, et sous quelle forme. Il est important d’ajuster les règles à chaque type d’alerte.

Bien choisir les destinataires des alertes est essentiel. En général, les équipes chargées du support ou de l’exploitation sont les premières concernées, mais certaines alertes peuvent être transmises à d’autres services, notamment celles qui concernent la sécurité. Il faut tenir compte de l’expertise de chacun, tout comme de ses disponibilités. Les collaborateurs concernés peuvent également être amenés à recevoir des alertes lors d’astreintes. Prévoyez de renseigner un numéro de téléphone spécifique pour ce type de situation.

Si jamais le destinataire principal n’est pas disponible, il faut prévoir un second destinataire, voire un processus d’escalade pour remonter l’alerte à un niveau supérieur.

Dans certains cas, il faut paramétrer une répétition de l’alerte si celle-ci n’a pas été prise en charge au bout d’un délai établi à l’avance.

Il faut ensuite définir par quels canaux les alertes doivent être transmises. Pour les alertes de bas niveau, de simples notifications internes à l’application suffisent. Pour les alertes plus sérieuses, il faut privilégier les canaux où les techniciens chargés du support sont les plus susceptibles d’être joints rapidement : téléphone, messagerie instantanée, voire email selon les habitudes et préférences de l’équipe.

Enfin, il faut prévoir la possibilité de clôturer une alerte, une fois celle-ci examinée et les éventuels incidents résolus ou remontés.