Alertes exploitables
Dans ce module, jusqu’à présent, nous avons exploré les façons d’aborder, de mesurer et d’interagir avec la fiabilité de nos systèmes. Mais la fiabilité a aussi un moyen d’interagir avec nous : les alertes. Il est facile de configurer Azure Monitor et d’autres outils pour vous envoyer des alertes basées sur des métriques et signaux, notamment les SLI et SLO déjà abordés. Azure peut également envoyer des alertes en fonction des problèmes des services à travers la fonctionnalité Azure Service Health.
La puissance de l’envoi facile d’alertes apporte son lot de dangers. C’est là que le mot durablement entre dans la définition de SRE que nous avons vue plus tôt :
L’ingénierie de fiabilité de site est une discipline d’ingénierie ayant pour vocation d’aider une organisation à atteindre durablement le niveau de fiabilité approprié dans ses systèmes, produits et services.
Les alertes sont conçues pour vous avertir en cas de problème avec vos systèmes. Toutefois, lorsque les alertes ne sont pas correctement configurées, cela peut nuire à votre objectif de création d’une pratique opérationnelle viable. Il est possible de gâcher tous les efforts entrepris dans le cadre de la mise en place de SLI et SLO dans votre organisation, si cela se traduit par un torrent d’alertes pour votre personnel. La fatigue par alerte est une maladie bien connue de la communauté des opérations. Cette unité a pour but de vous aider à l’empêcher de se produire dans votre organisation.
Des alertes qui ne sont pas exploitables sont un contributeur clé de la fatigue par alerte. Apprenons à éviter d’en créer.
Que sont (et que ne sont pas) les alertes ?
Pour comprendre pourquoi des alertes incorrectes peuvent créer un problème, vous devez réfléchir à l’objectif des alertes et à la façon dont elles diffèrent des autres signaux opérationnels.
Des alertes exploitables ne sont pas :
Journaux : Les alertes ne sont pas des enregistrements d’événements, mais il s’agit d’un travail pour les journaux. Si vous essayez simplement d’enregistrer un événement survenu, écrivez-le dans un fichier journal, plutôt que dans un récepteur de radiomessagerie.
Notifications : Les alertes ne sont pas destinées à annoncer des événements non critiques, comme l’achèvement d’une build du logiciel. Vous ne devriez pas avoir à interrompre une personne et à rompre leur concentration juste pour fournir une information de ce genre.
Pulsations : Les alertes ne doivent pas être utilisées pour rappeler que votre système est toujours en cours d’exécution. Nous avons vu des situations où les gens disent « Oh, si je ne reçois pas au moins un message de ce système toutes les heures, je sais qu’il y a un problème et que je dois y répondre ». C’est une idée terrible.
Les alertes exploitables sont utilisées dans les situations où vous avez besoin qu’une personne examine le problème et intervienne pour le résoudre. Les alertes doivent être des communications indiquant que des événements exceptionnels ou inattendus se sont produits et exigent l’attention d’une personne.
Si l’événement est une opération que le système peut gérer au travers de processus automatisés, comme la mise à l’échelle des ressources au sein d’une limite prédéfinie, aucune alerte n’est nécessaire. Le système doit simplement le gérer et écrire une ligne dans un journal. Il ne doit pas vous réveiller à 2h du matin pour vous informer qu’une situation donnée a été traitée avec succès.
Créer des alertes exploitables
Pour qu’une alerte soit exploitable, elle doit disposer des caractéristiques suivantes :
Simplicité : vous ne voulez pas créer une alerte qui oblige le destinataire à se creuser la tête avant de savoir quoi faire. Si l’alerte est trop complexe, le pauvre employé qui se réveille à peine au milieu de la nuit va perdre du temps à essayer de déterminer la signification.
Étendue : une des premières choses qu’une personne recevant le message doit faire, pour être en mesure de la hiérarchiser efficacement, est de déterminer l’étendue du problème. Le problème concerne-t-il un seul serveur ? Un seul service ? Une région entière ? Mondial ? Pour faciliter le travail du destinataire, insérez ces informations dans l’alerte.
Contexte : qu’est-ce que la personne qui va recevoir cette alerte doit savoir pour commencer à la traiter ? Examinons plus en détail cette partie.
Fournir un contexte dans l’alerte
Examinons certains éléments qu’une alerte exploitable doit toujours inclure afin que les destinataires disposent du contexte dont ils ont besoin :
D’où provient l’alerte ? De nombreuses organisations disposent de plusieurs systèmes d’analyse en cours d’exécution simultanément et d’un grand nombre de systèmes interconnectés. Le destinataire peut gagner beaucoup de temps si l’alerte indique « Cette alerte pour le système de paie THX-1138 provient de l’abonnement Azure Monitor ’prod’ ».
Quelles attentes ont été enfreintes ? Une alerte qui décrit uniquement l’état actuel des choses n’est pas aussi utile qu’elle pourrait l’être. Comparez « Le serveur de base de données fonctionne avec une charge de 80 % » à « Le serveur de base de données a fonctionné avec une charge de 80 % au cours des deux dernières heures alors qu’il devrait fonctionner avec une charge inférieure ou égale à 60 %. ».
Pourquoi est-ce un problème (pour le client) ? Les informations relatives à l’effet ou à l’impact de la situation sur le client nous donnent un moyen de déterminer l’importance et de choisir de manière appropriée notre réaction.
Quelles sont les étapes suivantes à suivre ? Si possible, l’alerte doit inclure ce que le destinataire doit effectuer ensuite, même s’il ne s’agit que d’un pointeur vers un guide de résolution des problèmes ou d’une autre documentation pour trouver de l’aide sur le diagnostic et la correction de ce problème.
L’inclusion de ce contexte utile et l’utilisation de vos alertes peuvent rendre les pratiques opérationnelles plus viables et faciliter la réponse à ces alertes.