Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
REL11-BP06 Envoyer des notifications lorsque des événements ont un impact sur la disponibilité
Des notifications sont envoyées en cas de détection de dépassement de seuils, même si l’événement à l’origine du problème a été automatiquement résolu.
La réparation automatisée assure la fiabilité de votre charge de travail. Cependant, elle peut également masquer les problèmes sous-jacents à résoudre. Implémentez une surveillance et des événements appropriés afin de pouvoir détecter les schémas de problèmes, y compris ceux résolus par la réparation automatique, afin de pouvoir résoudre les problèmes de cause racine.
Les systèmes résilients sont conçus de manière à ce que les événements de dégradation soient immédiatement communiqués aux équipes concernées. Ces notifications doivent être envoyées par un ou plusieurs canaux de communication.
Résultat souhaité : Des alertes sont immédiatement envoyées aux équipes opérationnelles lorsque des seuils sont dépassés, tels que les taux d'erreur, la latence ou d'autres indicateurs de performance clés (KPI) critiques, afin que ces problèmes soient résolus dès que possible et que l'impact sur les utilisateurs soit évité ou minimisé.
Anti-modèles courants :
-
Envoyer un trop grand nombre d’alarmes.
-
Envoyer des alarmes non exploitables.
-
Régler les seuils d’alarme à un niveau trop élevé (sensibilité excessive) ou trop faible (sensibilité insuffisante).
-
Ne pas envoyer d’alarmes pour les dépendances externes.
-
Ne pas prendre en compte les défaillances grises lors de la conception de la surveillance et des alarmes.
-
Effectuer des réparations automatisées, mais ne pas notifier l’équipe appropriée que des réparations étaient nécessaires.
Avantages de l'établissement de cette meilleure pratique : les notifications de reprise informent les équipes opérationnelles et commerciales des dégradations de service afin qu'elles puissent réagir immédiatement afin de minimiser à la fois le temps moyen de détection (MTTD) et le temps moyen de réparation (MTTR). Les notifications d’événements de reprise vous permettent également de ne pas ignorer les problèmes qui se produisent peu fréquemment.
Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : moyen L’absence de mise en œuvre de mécanismes appropriés de surveillance et de notification des événements peut entraîner l’incapacité à détecter des schémas de problèmes, y compris ceux traités par la réparation automatisée. Une équipe ne sera informée de la dégradation du système que lorsque les utilisateurs contacteront le service clientèle ou par hasard.
Directives d’implémentation
Lors de la définition d’une stratégie de surveillance, le déclenchement d’une alarme est un événement courant. Cet événement contiendra probablement un identifiant pour l’alarme, l’état de l’alarme (comme IN ALARM ou OK) et les détails de ce qui l’a déclenchée. Dans de nombreux cas, un événement d’alarme doit être détecté et une notification par e-mail doit être envoyée. Voici un exemple d’action sur une alarme. La notification d’alarme est essentielle pour l’observabilité, car elle permet d’informer les bonnes personnes de l’existence d’un problème. Cependant, lorsque l’action sur les événements arrive à maturité dans votre solution d’observabilité, elle peut automatiquement remédier au problème sans nécessiter d’intervention humaine.
Une fois les alarmes de KPI surveillance établies, les alertes doivent être envoyées aux équipes appropriées lorsque les seuils sont dépassés. Ces alertes peuvent également être utilisées pour déclencher des processus automatisés qui tenteront de remédier à la dégradation.
Pour une surveillance plus complexe des seuils, des alarmes composites doivent être envisagées. Les alarmes composites utilisent un certain nombre d'alarmes de KPI surveillance pour créer une alerte basée sur la logique métier opérationnelle. CloudWatchLes alarmes peuvent être configurées pour envoyer des e-mails ou pour enregistrer des incidents dans des systèmes de suivi des incidents tiers à l'aide de l'SNSintégration d'Amazon ou d'Amazon EventBridge.
Étapes d’implémentation
Créez différents types d’alarmes en fonction des charges de travail surveillées, par exemple :
-
Les alarmes d’application permettent de détecter si une partie de votre charge de travail ne fonctionne pas correctement.
-
Les alarmes relatives à l’infrastructure indiquent à quel moment il faut mettre les ressources à l’échelle. Les alarmes peuvent être affichées visuellement sur les tableaux de bord, envoyer des alertes via Amazon SNS ou par e-mail, et fonctionner avec Auto Scaling pour augmenter ou diminuer les ressources de charge de travail.
-
Des alarmes statiques simples peuvent être créées pour surveiller le dépassement d’un seuil statique par une métrique pendant un nombre spécifié de périodes d’évaluation.
-
Des alarmes composites peuvent prendre en compte des alarmes complexes provenant de sources multiples.
-
Une fois l’alarme créée, créez les événements de notification appropriés. Vous pouvez directement invoquer un Amazon SNS API pour envoyer des notifications et associer toute automatisation à des fins de correction ou de communication.
-
Intégrez la surveillance Amazon Health Aware
pour permettre de surveiller la visibilité AWS des ressources susceptibles de présenter des dégradations. Pour les charges de travail essentielles à l'entreprise, cette solution donne accès à des alertes proactives et en temps réel pour les AWS services.
Ressources
Bonnes pratiques Well-Architected connexes :
Documents connexes :
Outils associés :
