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.
Observabilité opérationnelle
L'observabilité est nécessaire pour obtenir des informations exploitables sur les performances de vos environnements et vous aider à détecter et à étudier les problèmes. Il a également un objectif secondaire qui vous permet de définir et de mesurer des indicateurs de performance clés (KPIs) et des objectifs de niveau de service (SLOs) tels que le temps de disponibilité. Pour la plupart des entreprises, KPIs les opérations importantes sont le temps moyen de détection (MTTD) et le temps moyen de reprise (MTTR) après un incident.
Tout au long de l'observabilité, le contexte est important, car les données sont collectées, puis les balises associées sont collectées. Quel que soit le service, l'application ou le niveau d'application sur lequel vous vous concentrez, vous pouvez filtrer et analyser pour ce jeu de données spécifique. Les tags peuvent être utilisés pour automatiser l'intégration aux CloudWatch alarmes afin que les bonnes équipes puissent être alertées lorsque certains seuils métriques sont dépassés. Par exemple, une clé de balise example-inc:ops:alarm-tag et la valeur qu'elle contient peuvent indiquer la création de l' CloudWatch alarme. Une solution illustrant cela est décrite dans Utiliser des balises pour créer et gérer des CloudWatch alarmes Amazon pour les EC2 instances Amazon
La configuration d'un trop grand nombre d'alarmes peut facilement créer une tempête d'alertes, lorsqu'un grand nombre d'alarmes ou de notifications submergent rapidement les opérateurs et réduisent leur efficacité globale alors que les opérateurs trient et hiérarchisent manuellement les alarmes individuelles. Un contexte supplémentaire pour les alarmes peut être fourni sous forme de balises, ce qui signifie que des règles peuvent être définies au sein d'Amazon EventBridge pour garantir que l'accent est mis sur le problème en amont plutôt que sur les dépendances en aval.
Le rôle des opérations parallèles DevOps est souvent négligé, mais pour de nombreuses organisations, les équipes opérationnelles centrales continuent d'apporter une première réponse essentielle en dehors des heures normales de bureau. (Vous trouverez plus de détails sur ce modèle dans le livre blanc sur l'excellence opérationnelle.) Contrairement à l' DevOps équipe responsable de la charge de travail, elle n'a généralement pas les mêmes connaissances approfondies. Le contexte fourni par les balises dans les tableaux de bord et les alertes peut donc les diriger vers le runbook adapté au problème, ou lancer un runbook automatique (voir le billet de blog Automating Amazon CloudWatch
