Escalades. Scénarios typiques

J'ai été réveillé par un SMS à trois heures du matin.
Il n'y a pas eu de problème. Mon site a chuté pendant trois minutes, et il s'est relevé tout seul.
Mais je n'ai pas réussi à me rendormir.
Histoire vécue

Comme beaucoup le savent, HostTracker est un système de surveillance de l'efficacité des sites. L'une de ses principales fonctions est de notifier rapidement à l'utilisateur tout problème. L'efficacité des notifications et le niveau acceptable de “détalonnage&rdquo ; sont importants. Si vous envoyez des alertes à chaque “éternuement&rdquo ;, la personne ne trouvera pas les informations importantes dans ce flux.

Nous avons prévu plusieurs mécanismes qui aideront les bonnes personnes à recevoir les notifications nécessaires :

• Séparation des notifications en plusieurs groupes en fonction de leur criticité;
• Pas de notifications lors de défaillances à court terme;
• Rapport du problème au responsable rapidement;
• Reporter une panne prolongée à l'administration;
• Utiliser d'abord les alertes gratuites &ndash ; email, gtalk, puis les payantes &ndash ; SMS ou appel téléphonique ;.
• Au niveau du contact &ndash ; définir le temps de travail où ce contact doit recevoir les alertes;

Il existe trois types de notifications :

• Le site web a “chuté”;
• Le site web est toujours “down”;
• Le site web a “augmenté

Les notifications “down&rdquo ; et “rose&rdquo ; sont claires. Les notifications “site is still down&rdquo ; sont envoyées à chaque échec de test, mais seulement lors des chutes confirmées. L'algorithme de confirmation des échecs a été décrit dans l'article “Exclusion des fausses alertes”

Pour chaque paire site-contact, vous pouvez activer ou désactiver le type de notification approprié. Le paramètre peut être localisé dans les propriétés du contact ainsi que dans la “matrice&rdquo ; générale à la page “Abonnement aux notifications”

Escalade et niveau de détalonnage des notifications.

Supposons que deux personnes soient responsables du site :

• Administrateur
• Gestionnaire

Essayons de mettre en œuvre le scénario suivant :

• En cas de “drop&rdquo ; nous voulons envoyer immédiatement un message électronique à l'administrateur;
• Si le site ne remonte pas dans les 15 minutes, nous envoyons un SMS à l'administrateur;
• Si le site est “down&rdquo ; pendant plus d'une heure, alors nous envoyons un SMS au gestionnaire;

Ajout des contacts pour les utilisateurs. Pendant l'ajout, attirer l'attention sur la fenêtre “Notification Delay&rdquo ;.

Il semble que nous ayons trois contacts avec les retards suivants :

• Administrateur (courriel) &ndash ; aucun délai;
• Administrateur (SMS) &ndash ; 15 minutes de délai;
• Gestionnaire (SMS) &ndash ; délai de 1 heure;

Selon cette configuration, l'administrateur recevra toutes les notifications d'échecs à l'email, mais les notifications par SMS seront envoyées seulement si le site est “down&rdquo ; pendant plus de 15 minutes. Le gestionnaire ne recevra que les SMS concernant les pannes majeures de plus d'une heure. Mise en place de l'horaire de travail du contact

Supposons qu'un administrateur ne peut pas faire face, et que nous avons embauché un autre administrateur. Le premier travaille pendant la première moitié de la semaine, le second pendant la deuxième moitié. En conséquence, les notifications doivent être envoyées à l'administrateur “en service&rdquo ; Pour définir ce scénario, la fenêtre “Définir les heures de travail du contact&rdquo ; est utilisée dans les paramètres du contact.

Dans ce cas, le premier administrateur recevra les notifications par SMS du lundi au jeudi inclus. En outre, vous pouvez diviser la notification pour différents employés en fonction de l'heure de la journée, par exemple en désignant des administrateurs de jour et de nuit.

Conclusions : à l'aide de mécanismes relativement simples, nous pouvons couvrir la plupart des notifications affinent les scénarios des utilisateurs.