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.
Étape 3 : Inspecter, adapter et itérer
Après avoir mis en œuvre votre système d'observabilité, nous vous recommandons de continuellement revoir, évaluer, apprendre, adapter et améliorer votre mise en œuvre. Vous pouvez utiliser le modèle de maturité de l'AWS observabilité
Mettre en œuvre des révisions régulières
L'observabilité est un processus itératif. Cela nécessite des audits et des évaluations réguliers des composants existants, ainsi que des modifications et des améliorations pour favoriser une amélioration continue. Nous vous recommandons de procéder à des révisions régulières pour réévaluer les seuils d'alerte SLOs, les tableaux de bord, la granularité des mesures, les politiques de rétention, les stratégies d'échantillonnage, etc. afin de vous assurer qu'ils génèrent de la valeur pour vos équipes et votre entreprise. En reliant les coûts d'observabilité à des équipes et à des services spécifiques, vous pouvez prendre des décisions basées sur les données concernant la couverture et l'allocation des ressources.
Chez Amazon, nous menons des évaluations hebdomadaires du niveau de préparation opérationnelle (ORRs) afin d'auditer les processus et les postures d'observabilité des équipes par rapport aux meilleures pratiques. Il s'agit d'un exercice non bloquant qui correspond au nombre de services et à la fréquence des publications sur Amazon.
En fonction de la taille de votre organisation, vous pouvez également disposer d'une liste des activités comme si de rien n'était (BAU), dans laquelle un membre de chaque équipe est chargé de signaler les anomalies et les tendances, de découvrir les inconnues, de supprimer les instruments et les alertes indésirables, d'améliorer les tableaux de bord et de veiller à ce que la solution d'observabilité continue de fonctionner pour l'équipe et soit alignée sur les objectifs et les indicateurs de réussite de l'équipe. Cela pourrait également être l'occasion de réévaluer la stratégie d'alerte pour qu'elle soit plus réactive, proactive et plus proche de l'utilisateur. L'objectif de ces révisions est de créer un cycle vertueux, comme le montre l'illustration suivante, et d'améliorer la maturité de votre posture d'observabilité, comme décrit dans le modèle de maturité de l'AWS observabilité
Identifiez les playbooks les plus fréquemment consultés et envisagez d'améliorer votre application ou d'ajouter de l'instrumentation. Identifiez les runbooks les plus fréquemment exécutés et envisagez d'automatiser ces runbooks.
Les enseignements tirés de ces examens sont également partagés avec l'équipe d'observabilité et les spécialistes, afin de mettre en évidence les améliorations apportées aux programmes centraux et à la plateforme d'observabilité. Par exemple, en fonction de la fréquence des événements déclenchés par le déploiement, vous pouvez décider de donner la priorité à l'amélioration du pipeline de déploiement par rapport aux autres composants. Si le MTTR est plus élevé en raison de lacunes de surveillance, vous pouvez donner la priorité à l'amélioration de la plateforme d'observabilité et de sa configuration.
Célébrez vos victoires
Partagez les réussites des équipes qui utilisent des outils d'observabilité. Soulignez par exemple le succès d'une équipe qui a utilisé des indicateurs d'observabilité pour mettre en œuvre une solution alternative plus efficace et permettant de réduire le temps de latence ou les coûts. Communiquer ce succès souligne l'importance de l'observabilité et motive les autres équipes à améliorer leur posture d'observabilité et à viser un succès similaire.
Tirez les leçons des incidents
Réalisez des exercices post-incidents irréprochables similaires au processus de correction des erreurs (COE)
