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 1 : Définissez votre étoile polaire
Une mise en œuvre réussie de l'observabilité ne repose pas uniquement sur les opérations et les outils, mais aussi sur la promotion d'une culture d'appropriation, d'amélioration continue et de résolution proactive des problèmes. Comme pour toute stratégie réussie, votre stratégie d'observabilité nécessite une prise en compte globale de trois piliers : les personnes, les processus et la technologie.
Lorsque vous souhaitez établir ou améliorer votre posture d'observabilité, nous vous recommandons de commencer par définir ce qui compte, de vous appuyer sur les résultats de votre entreprise et de revoir, ajuster et réaligner continuellement votre stratégie au fur et à mesure de l'évolution de votre entreprise, de vos équipes et de vos produits.
Au cours de cette première étape, vous définissez et établissez votre étoile polaire, qui est une définition convenue et bien comprise de ce à quoi ressemble une bonne apparence pour votre organisation. Nous vous recommandons de revoir certaines ou toutes les activités de cette étape au fur et à mesure de l'évolution de votre entreprise, lorsque vous lancez un nouveau produit, une nouvelle application ou un nouveau service, ou lorsque vous concevez un changement architectural majeur, afin de réévaluer votre plateforme d'observabilité et vos besoins organisationnels.
Intégrer l'observabilité plus tôt dans le cycle de développement (approche shift-left)
Faites de l'observabilité une responsabilité pour chaque membre des équipes d'ingénierie, d'exploitation et de produit, et traitez-la comme une exigence fonctionnelle principale, de la même manière que vous traitez les tests unitaires ou la sécurité. Cela ne transfère pas la responsabilité de l'équipe des opérations à l'équipe de développement, mais met en évidence la collaboration requise entre les différentes équipes. Il est utile pour les équipes d'effectuer les activités suivantes en collaboration au début du cycle de développement. Vous souhaiterez peut-être les exécuter par ticket, par fonctionnalité ou par produit.
-
Identifiez les parties prenantes. Qui sont les parties prenantes et qu'est-ce qui compte pour elles si cette fonctionnalité ou ce produit ne fonctionne pas comme prévu ? Lorsque vous identifiez les parties prenantes, tenez compte d'aspects tels que les fonctionnalités, la disponibilité, la sécurité, les coûts, les ventes et l'utilisation des produits. Les parties prenantes peuvent inclure votre équipe, les clients de votre produit, les parties prenantes internes de l'entreprise, les membres de l'équipe chargée des opérations de la plateforme et les développeurs d'applications. Selon le scénario, vos équipes chargées de la sécurité et des finances peuvent également être parties prenantes.
-
Identifiez les principaux résultats. Déterminez les principaux résultats et leur impact sur l'entreprise et sur chaque partie prenante. Identifiez le succès et l'échec de chaque résultat et de chaque partie prenante. Les résultats sont généralement définis comme des objectifs de niveau de service (SLOs) et doivent être quantifiables. Un SLO est une mesure pour chaque résultat. Un bon SLO a une valeur cible qui doit être atteinte ou maintenue comme objectif. Un SLO peut être une mesure de la satisfaction des utilisateurs. Un indicateur de niveau de service (SLI) est la ou les mesures réelles utilisées pour déterminer si vous atteignez le SLO : il s'agit du point de données quantifiable que vous suivez par rapport à votre objectif. Les exemples incluent la réduction du MTTR de 60 %, le maintien de la disponibilité des applications à 99,99 % ou l'amélioration de la productivité des développeurs de 30 %.
Prenons l'exemple du maintien de la disponibilité des applications à 99,99 % et définissons le SLO, le SLI et les indicateurs nécessaires pour mesurer et valider le succès. Pour cet exemple, considérons une RESTful application et définissons la disponibilité de l'application comme la réussite de toutes les demandes entrantes. Cela nécessite de mesurer le nombre total de demandes associées à l'application et l'état d'avancement de chaque demande. Lorsque vous les traduisez en SLO et SLI, vous avez besoin d'une métrique qui capture les demandes entrantes et d'une autre qui capture le statut des demandes. Si toutes les demandes sont traitées avec succès, l'application est considérée comme disponible. Si une ou plusieurs demandes entraînent des erreurs, l'application est considérée comme indisponible. Par conséquent, le SLI serait la somme des demandes traitées par erreur, divisée par la somme des demandes entrantes dans un intervalle de 5 minutes, ce qui correspond en fait à un taux d'erreur. Vous pouvez ajouter un objectif à ce SLI pour le transformer en SLO ; par exemple : efforcez-vous de faire en sorte que le taux d'erreur soit inférieur à 0,1 % sur 3 intervalles consécutifs de 5 minutes.
-
Priorisez les principaux résultats.En fonction de la priorité que vous définissez pour chaque résultat, vous pouvez choisir de vous concentrer d'abord sur les résultats qui ont le plus d'impact, au lieu de tout faire en même temps. Commencez par petites étapes, puis améliorez progressivement votre posture d'observabilité. L'observabilité est un processus qui nécessite des examens, des audits, des améliorations et des améliorations continus afin d'accroître la maturité et les avantages. La priorisation peut également vous donner l'occasion de définir des étapes progressives vers les résultats identifiés.
-
Identifiez l'instrumentation requise. Quels sont les composants et les caractéristiques connexes de l'architecture ou de la mise en œuvre qui peuvent influencer les résultats importants, tels qu'identifiés dans les étapes précédentes ? Par exemple, lorsque vous exécutez une application sur une instance Amazon Elastic Compute Cloud (Amazon EC2), le nombre de cœurs et la RAM disponible peuvent avoir un impact sur la réactivité et le débit de l'application. À ce stade, il peut également être utile de déterminer si les outils ou bibliothèques que vous utilisez fournissent déjà une partie de cette instrumentation. La réalisation d'une série d'examens préliminaires ou l'ajout de questions telles que les suivantes à la définition du terme « prêt » (DoR)
d'un ticket peut faire partie du processus standard. -
Si cette opération devait échouer, que devriez-vous savoir pour y remédier ? Comment une opération typique ou problématique affecte-t-elle les composants concernés ? Quel type de signal cette opération doit-elle envoyer : log, métrique ou trace ? Quel est le coût de cette instrumentation par rapport à sa valeur ? Quel type d'agrégation serait acceptable sans violation ? SLOs
-
Quels sont les composants et les dépendances susceptibles de provoquer un échec lors de cette opération ? Comment allez-vous identifier le composant ou la dépendance à l'origine de la panne ? Quels sont les différents leviers de configuration de ces composants et dépendances, et comment chacun influe-t-il sur le fonctionnement ?
-
Quels sont la granularité métrique et le taux d'échantillonnage requis pour garantir que le SLI et le SLO peuvent être mesurés avec précision ?
-
-
Définissez les critères de réussite. Pour chaque résultat prioritaire, définissez des seuils qui correspondent à l'impact de l'atteinte ou de la non-réalisation des objectifs. Les critères de réussite fournissent un contexte supplémentaire aux équipes lorsqu'elles répondent aux alertes. Ils vous permettent également de prévoir et de faire des compromis par rapport au coût de l'instrumentation pour obtenir la visibilité requise.
Mettre en place une organisation et une structure d'équipe efficaces
En fonction de la complexité architecturale et de la taille de votre entreprise, vous devrez peut-être mettre en place une équipe dédiée qui se concentre sur l'observabilité. Cette équipe sera chargée de configurer les outils d'observabilité et de mettre en place la plateforme d'observabilité pour les autres équipes. Nous vous recommandons également de mettre en place une équipe dédiée si vous optez pour une OpenTelemetry implémentation standard. Dans les petites entreprises, vous pouvez attribuer l'observabilité comme une responsabilité supplémentaire à chaque membre de l'équipe et également désigner des champions de l'observabilité chargés de promouvoir et d'appliquer les meilleures pratiques au sein des équipes. Ces champions consacrent une partie de leur journée à la définition des processus et à l'établissement de normes pour l'organisation. Ils travaillent en équipe autonome ou peuvent être dirigés par des spécialistes de l'observabilité dédiés. Le schéma suivant montre comment votre investissement peut déterminer votre approche organisationnelle.
Les champions peuvent être pleinement intégrés dans les équipes (comme le montre l'illustration suivante pour l'équipe 2) ou faire partie d'une équipe habilitante qui alterne entre les équipes pour établir et promouvoir les meilleures pratiques (équipe 1 dans l'illustration).
Suivez la répartition des coûts
Organisations doivent mettre en œuvre un suivi complet des coûts et une visibilité sur les indicateurs, les journaux et les traces, tout en établissant une responsabilité spécifique à l'équipe en matière d'utilisation des ressources et de coûts. L'intégration réussie des pratiques d'opérations financières (FinOps) nécessite des systèmes de surveillance automatisés dotés d'alertes budgétaires associées à une conservation systématique des données et à une optimisation de la collecte. Les équipes d'ingénierie et de finance devraient aligner leurs objectifs par le biais de tableaux de bord partagés et de révisions régulières. Organisations tirent avantage de la mise en œuvre de modèles de rétrofacturation clairs et de stratégies de répartition des coûts afin de renforcer l'appropriation et la responsabilisation.
Définir les normes
Identifiez et définissez les signaux de base et la télémétrie dont une application a besoin, y compris les stratégies d'alerte et de tableau de bord. Créez une liste de contrôle ou un processus d'examen officiel pour chaque candidature. Le site Web des meilleures pratiques d'AWS
observabilité
Mettre en place des processus d'escalade
Il est important d'établir et d'appliquer des mécanismes d'escalade, la propriété des alertes et des procédures de réponse. Nous vous recommandons de promouvoir une culture dans laquelle l'escalade n'est pas mal vue.
Améliorez vos compétences grâce à la formation
Identifiez le meilleur moyen d'améliorer les compétences des membres actuels et nouveaux de l'équipe, de renforcer l'importance de l'observabilité et de favoriser une culture d'amélioration continue. En fonction des besoins de votre organisation, vous pouvez choisir entre une formation préenregistrée, à la demande ou une formation en classe dispensée par des champions ou des spécialistes de l'observabilité. Votre Compte AWS équipe peut proposer des sessions de formation pratiques approfondies, telles que le One Observability Workshop
