Votre équipe d'ingénieurs souffre-t-elle d'alerte ? Posez ces 8 questions

La fatigue d'alerte est un problème courant parmi les équipes d'ingénierie qui gèrent les opérations et entretiennent l'infrastructure.

Le problème provient généralement d'une approche aléatoire de la rédaction des alertes à mesure que les équipes grandissent et commencent à utiliser davantage d'infrastructures de complexité croissante. C'est tout à fait normal - à mesure qu'une entreprise ou une équipe grandit, il faut souvent du temps pour qu'une culture d'observabilité et de solides pratiques d'alerte prennent forme.

Il est facile de créer des alertes trop sensibles, trop bruyantes et trop prudentes. Au début, tout semble digne d'alerte simplement parce qu'il vaut mieux être prudent et maximiser le signal de production dans les premières étapes d'un produit.

"Alors que le nombre et la complexité des fonctionnalités et de l'infrastructure augmentent, l'amélioration des alertes est généralement en bas de la liste des priorités"

Naturellement, cette approche ne s'adapte pas très bien, mais à mesure que le nombre et la complexité des fonctionnalités et de l'infrastructure augmentent, l'amélioration des alertes est généralement bien en bas de la liste des priorités. Il en résulte de nombreuses alertes semi-significatives, du bruit, des changements de contexte et du multitâche pour l'ingénieur de garde. Dans les cas extrêmes, les coéquipiers s'épuisent, les alertes sont ignorées et votre équipe d'astreinte passe de l'amélioration de la qualité du service à la lutte contre les incendies en permanence sans impact significatif.

Comme toutes les entreprises, Intercom n'est pas à l'abri de ces inefficacités. Nous avons donc imaginé un procédé relativement léger pour lutter contre la fatigue d'alerte.

Comment nous pensons à la stratégie d'alerte

Le concept de «discipline d'alerte» est au cœur de la maîtrise des alertes. Comme le travail sur les fonctionnalités, les alertes et la stratégie d'alerte doivent être abordées de manière délibérée et structurée. Contrairement au travail sur les fonctionnalités, ce n'est pas quelque chose qui peut être bien planifié à l'avance.

Après tout, il est très peu probable que vous puissiez prédire la santé opérationnelle et le bruit de votre nouvelle fonctionnalité avant de l'expédier. Vous devez surveiller les alertes de manière régulière et planifiée afin que le travail d'alerte n'atteigne pas des niveaux insoutenables.

8 questions à se poser pour évaluer les alertes de votre équipe

Nous avons introduit des sessions régulières d'examen des alertes pour les équipes traitant des alertes fréquentes. Celles-ci ont d'abord eu lieu une ou plusieurs fois par cycle d'ingénierie de six semaines, mais sont devenues plus espacées à mesure que l'état des alertes et des moniteurs s'améliorait à un niveau plus gérable.

Chaque session d'examen des alertes commence par une liste ordonnée des alertes qui se sont déclenchées au cours de la période précédente, classées par fréquence de leur déclenchement. Nous utilisons la plate-forme PagerDuty comme source d'alerte, et ses fonctionnalités d'analyse nous fournissent les informations dont nous avons besoin pour décomposer la fréquence des alertes et les réponses. Les alertes qui contribuent le plus au bruit global (c'est-à-dire les incendies les plus fréquents) sont examinées en premier.

Chaque alerte est ensuite passée à travers une liste de contrôle de questions :

1. L'alerte est-elle toujours d'actualité ?

Toute alerte déclenchée par des systèmes obsolètes ou non entretenus ne doit pas déranger l'ingénieur de garde et doit être immédiatement supprimée.

2. L'alerte est-elle actionnable ?

Si un ingénieur de garde reçoit l'alerte, peut-il faire quelque chose immédiatement pour réparer ou améliorer la cause sous-jacente ? Si l'alerte n'est pas exploitable et utile, elle doit être supprimée. Un résumé hebdomadaire des problèmes ou des dégradations de performances peut être un meilleur endroit pour les informations dans l'alerte.

3. Les informations contenues dans l'alerte sont-elles immédiatement utiles même si elles ne sont pas exploitables ?

Nous pouvons diviser les informations d'alerte en deux grandes catégories.

• Signaux : ces alertes avertissent qu'un système fonctionne à sa limite, mais ne signifient pas nécessairement que le service est affecté. Un exemple serait l'un de vos serveurs fonctionnant à 100 % du processeur. Si le service fonctionne toujours correctement, l'astreinte doit-elle passer un temps précieux à enquêter ? Après tout, votre serveur fonctionne alors simplement au meilleur rapport travail-coût !
• Symptômes : ces alertes se déclenchent lorsque l'expérience client est affectée. Un exemple ici serait le nombre d'erreurs HTTP 5XX que votre service renvoie aux appelants.

Ces deux catégories fonctionnent mieux en tandem. Une personne de garde doit réagir et dépanner les symptômes, et ne considérer les signaux que comme une source d'information supplémentaire.

4. Si l'alerte est actionnable et pagination, doit-elle être traitée immédiatement ?

Si le problème n'a pas besoin d'être traité immédiatement, il ne devrait réveiller personne au milieu de la nuit. L'équipe doit décider d'autres moyens de faire apparaître les informations dans l'alerte dans ces situations, par exemple, une notification Slack ou de tableau de bord, ou une tâche ouverte dans un mécanisme de suivi des problèmes.

5. S'il est exploitable, existe-t-il un runbook ou un lien de dépannage ? Les étapes sont-elles suffisamment claires pour être suivies par n'importe quel ingénieur de l'équipe ?

L'une des pires expériences d'être un ingénieur sur appel - en particulier un nouveau - est la quantité de connaissances tribales qui s'accumule dans les équipes d'ingénierie au fil du temps. Il est intimidant de sauter sur un incident de production très grave juste pour se rendre compte que vous n'êtes pas familier avec cette partie du système et qu'elle n'est pas bien documentée.

“ Garder les informations de dépannage d'alerte claires, simples et à jour contribue grandement à réduire votre temps moyen d'atténuation et de récupération après un incident ”

Même si vous avez l'expertise, vous avez peut-être écrit le code il y a si longtemps que vous ne vous souvenez pas clairement de ce qu'il est censé faire. Garder les informations de dépannage d'alerte claires, simples et à jour contribue grandement à réduire votre temps moyen d'atténuation et de récupération après un incident (MTTM et MTTR).

6. S'il est exploitable, existe-t-il un lien vers le tableau de bord et affiche-t-il toutes les causes potentielles connues ?

Les tableaux de bord sont un excellent moyen de faire apparaître simultanément de grandes quantités d'informations système, ce qui signifie que les ingénieurs n'ont pas à fouiller dans divers journaux, métriques et traces pour déterminer la cause d'un problème. L'agrégation des données dans un tableau de bord et la fourniture du lien dans le cadre de l'alerte permettent un dépannage beaucoup plus rapide.

7. L'alerte est-elle trop sensible ou pas assez précise ? Bénéficierait-il d'une désensibilisation ou d'un changement de périmètre ?

De nombreuses alertes sont utiles mais mal calibrées. Ils peuvent être soit trop larges et ne pas tirer à chaque fois qu'ils le devraient, soit trop spécifiques et tirer plusieurs fois pour le même incident, ce qui ne fait qu'ajouter au bruit.

8. Enfin, est-ce qu'un être humain doit faire la remédiation ?

D'une certaine manière, tout code informatique automatise quelque chose qu'un humain peut faire. Alors pourquoi ne pas automatiser la résolution des problèmes déclenchant les alertes ? Alors que certaines alertes plus épineuses seraient difficiles à corriger automatiquement, comme un bogue dans le code ou un problème de performances dans le système, les actions automatisées peuvent résoudre de nombreux problèmes courants.

Cela est particulièrement vrai si vous utilisez une plate-forme cloud telle qu'AWS et que vous pouvez provisionner l'infrastructure sans avoir à vous soucier de demander du matériel supplémentaire. Par exemple, si un nœud de votre cluster de recherche affiche des disques défaillants, pourquoi ne pas le remplacer automatiquement ? Si le service manque de ressources de calcul en raison de l'augmentation du trafic, pourquoi ne pas évoluer et ajouter des VM ou des conteneurs supplémentaires ? Les détails de la correction peuvent ensuite être envoyés à l'équipe via des canaux sans alerte afin qu'ils puissent les examiner à leur guise.

Avez-vous répondu « non » à l'une de ces questions ?

Répondre par la négative à l'une de ces questions soulève une tâche hautement prioritaire pour l'équipe afin d'améliorer l'alerte, qu'il s'agisse d'arrêter la pagination, d'améliorer les étapes de dépannage, de l'automatiser ou simplement de résoudre le problème système sous-jacent.

L'essentiel de l'approche consiste à le faire de manière régulière et planifiée. Il maintient les niveaux de bruit bas et vos opérateurs et ingénieurs de garde heureux et productifs. Ils peuvent se concentrer sur l'amélioration de la qualité et l'impact plutôt que sur la lutte contre les incendies.

Êtes-vous intéressé par la façon dont nous travaillons chez Intercom? Nous serions ravis de vous parler - découvrez nos rôles d'ingénierie ouverts.