Observabilité et surveillance - Modèles
En savoir plus sur l’excellence opérationnelle bien archivée → Observabilité et surveillance
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Plate-forme | Surveillance des événements | ✅ Event Monitoring est conçu dans l’architecture initiale capturant des ID de corrélation qui tracent les requêtes à travers des chaînes de traitement asynchrones et des intégrations externes |
| Plate-forme | Surveillance des événements | ✅ L’infrastructure d’observabilité est incluse dès le sprint initial plutôt que modernisée lorsque les incidents de production s’avèrent impossibles à diagnostiquer |
| Plate-forme | Intégration | ✅ Les points de contrôle d’intégration sont placés délibérément pour activer le traçage des requêtes à travers les frontières du système |
| Plate-forme | Événements de plate-forme | ✅ Les charges utiles d’événement de plate-forme sont structurées pour la visibilité opérationnelle avec des marqueurs de transaction et le contexte |
| Plate-forme | Consignation personnalisée | ✅ L’infrastructure de consignation personnalisée capture des événements discrets avec des informations contextuelles complètes, notamment l’identité de l’utilisateur, l’horodatage, la durée et le résultat |
| Plate-forme | Métriques | ✅ Les métriques agrègent les mesures numériques au fil du temps révélant des tendances, notamment les taux de consommation d’API, les distributions de temps processeur Apex et les taux de réussite des tâches par lot |
| Plate-forme | Traçage distribué | ✅ Les traces connectent des appels d’API synchrones à des chaînes de traitement asynchrones, des événements de plate-forme à des exécutions d’abonnés et des requêtes d’intégration à des réponses système externes |
| Plate-forme | Observabilité | ✅ L’observabilité permet aux opérateurs de répondre à des questions arbitraires sur le comportement du système sans déployer de nouvel instrumentation pour chaque investigation |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Plate-forme | Surveillance des événements | ⚠️ Lancement de solutions sans consignation personnalisée, nécessitant une refactorisation majeure six mois plus tard lorsque les incidents de production s’avèrent impossibles à diagnostiquer avec les seuls journaux de plate-forme |
| Plate-forme | Surveillance des événements | ⚠️ L’observabilité est modernisée dans la solution existante nécessitant des changements d’instrumentation touchant la plupart des composants et risquant des bogues lors des travaux d’amélioration opérationnelle |
| Plate-forme | Intégration | ⚠️ Des échecs d’intégration se produisent, mais les chemins de requête ne peuvent pas être tracés à travers les frontières du système sans télémétrie complète |
| Plate-forme | Événements de plate-forme | ⚠️ Les charges utiles d’événements de plate-forme manquent de contexte opérationnel rendant l’enquête sur les incidents dépendante de la recherche dans plusieurs systèmes |
| Plate-forme | Consignation personnalisée | ⚠️ Les journaux capturent un contexte insuffisant; les enquêtes nécessitent de reproduire les problèmes pour recueillir des informations supplémentaires |
| Plate-forme | Observabilité | ⚠️ Les tableaux de bord prédéfinis ne peuvent pas répondre à des questions inattendues sur le comportement système émergent en production |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Plate-forme | Surveillance des événements | ✅ Event Monitoring est activé pour les environnements de production capturant l’utilisation d’API, l’activité de connexion, l’exécution Apex, les requêtes SOQL, les pages Visualforce, les pages Lightning et les exécutions de rapports |
| Plate-forme | Surveillance des événements | ✅ Exportation des fichiers journaux d’événements toutes les heures vers une plate-forme de consignation centralisée permettant une analyse historique au-delà de la rétention native de la plate-forme |
| Plate-forme | Surveillance des événements | ✅ L’agrégation de journaux externes permet la corrélation avec la télémétrie d’entreprise à partir d’autres systèmes pour le traçage des transactions de bout en bout |
| Plate-forme | Surveillance des événements | ✅ Les fichiers journaux d’événements sont conservés correspondant aux exigences réglementaires pour les rapports de conformité et l’analyse des tendances à long terme |
| Plate-forme | Proactive Monitoring | ✅ Les seuils Proactive Monitoring sont ajustés délibérément en fonction de la plage de fonctionnement normale spécifique à l’organisation plutôt que d’accepter les paramètres par défaut |
| Plate-forme | Proactive Monitoring | ✅ Les alertes Proactive Monitoring détectent les pics de limite d’API, les échecs Apex simultanés, les approches de limite de lignes SOQL et les contentions de verrouillage de ligne avant les incidents visibles par l’utilisateur |
| Plate-forme | Proactive Monitoring | ✅ Les seuils ajustés génèrent des signaux actionnables en lesquels les équipes Trust et agissent en créant des cycles vertueux d’amélioration continue |
| Plate-forme | Centre d’échelle | ✅ Les références du Centre d’échelle sont établies pendant la stabilisation de la solution et revisitées après chaque version majeure |
| Plate-forme | Centre d’échelle | ✅ Le Centre d’échelle indique quelles opérations consomment le plus de ressources, quelles transactions approchent les seuils d’expiration et où l’investissement dans l’optimisation produit le plus grand impact |
| Plate-forme | Centre d’échelle | ✅ Le temps de transaction augmente par rapport à l’enquête rapide de référence révélant des modèles de requête N+1 involontaires introduits dans le dernier déploiement |
| Plate-forme | Journal d’audit de configuration | ✅ Le Journal d’audit de configuration suit les changements de configuration, y compris les modifications d’autorisation, les déploiements de métadonnées et les mises à jour des paramètres de sécurité, avec une rétention jusqu’à 180 jours |
| Plate-forme | Journal d’audit de configuration | ✅ Les entrées du Journal d’audit de configuration sont exportées pour être conservées au-delà de 180 jours lorsque la conformité ou les exigences contractuelles exigent des fenêtres historiques plus longues |
| Plate-forme | Shield | ✅ Le Journal d’audit des champs est activé de façon sélective pour les champs contenant des données confidentielles, des données réglementées nécessitant un historique des modifications ou des données métiers critiques |
| Plate-forme | Shield | ✅ Journal d’audit des champs fournit jusqu’à 10 ans de rétention pour les champs dans lesquels la compréhension des valeurs historiques facilite les opérations et les rapports de conformité |
| Plate-forme | Contrôle d’intégrité | ✅ Les examens de contrôle d’intégrité sont planifiés tous les trimestres et les constatations sont corrigées en fonction de la priorité des risques pour l’environnement |
| Plate-forme | Contrôle d’intégrité | ✅ Les résultats du contrôle d’intégrité font l’objet d’un examen délibéré plutôt que d’une acceptation passive; les contrôles compensatoires ou les différentes tolérances au risque sont documentés |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Plate-forme | Surveillance des événements | ⚠️ La Surveillance des événements est activée mais les journaux ne sont jamais exportés, limitant les investigations à la période de rétention native et empêchant l’analyse des tendances historiques |
| Plate-forme | Surveillance des événements | ⚠️ Les fichiers journaux d’événements restent stockés sur la plate-forme ; l’agrégation externe n’est pas implémentée empêchant la planification des capacités à long terme |
| Plate-forme | Proactive Monitoring | ⚠️ Proactive Monitoring utilise des seuils par défaut trop sensibles ou trop laxistes, générant des alertes bruyantes que les équipes apprennent à ignorer |
| Plate-forme | Proactive Monitoring | ⚠️ Le bruit d’alerte détruit Trust dans le système de surveillance ; les équipes arrêtent de répondre aux signaux valides |
| Plate-forme | Centre d’échelle | ⚠️ Le Centre d’échelle est activé, mais n’est jamais revu proactivement ; les performances se dégradent lentement jusqu’à ce que les utilisateurs se plaignent après des mois de dégradation incrémentielle |
| Plate-forme | Centre d’échelle | ⚠️ Les métriques de performance n’ont pas de contexte de référence; on ne sait pas si les temps de transaction de 3 secondes sont typiques, s’améliorent ou se dégradent |
| Plate-forme | Journal d’audit de configuration | ⚠️ Le Journal d’audit de configuration n’est pas exporté ; les limitations de rétention empêchent les enquêtes de sécurité ou la validation de la conformité au-delà de 180 jours |
| Plate-forme | Shield | ⚠️ Le Journal d’audit des champs est activé pour tous les champs plutôt que de façon sélective, ce qui crée des coûts de stockage sans valeur de conformité correspondante |
| Plate-forme | Contrôle d’intégrité | ⚠️ Les conclusions du contrôle d’intégrité ne sont jamais examinées ; la configuration de la sécurité s’écarte des recommandations de référence sans acceptation délibérée |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Plate-forme | Flux utilisateur | ✅ Les flux utilisateur critiques sont définis en fonction de l’impact métier et surveillés de bout en bout pour les taux de réussite, le temps de réalisation, les points d’abandon et les taux d’erreur |
| Plate-forme | Flux utilisateur | ✅ Les flux critiques comprennent les activités génératrices de chiffre d’affaires (soumission de commande, exécution de contrat, fermeture d’opportunité), les activités à haut volume (connexion, recherche, création d’enregistrements) et les activités liées à la conformité (capture du consentement, respect des droits de la personne concernée) |
| Plate-forme | Flux utilisateur | ✅ Les flux sont instrumentés avec des marqueurs de transaction indiquant le début, la fin, l’abandon et l’échec à chaque étape significative |
| Plate-forme | Flux utilisateur | ✅ Flux de soumission de commande instrumenté avec des événements de plate-forme à chaque étape (validation du panier d’achat, contrôle d’inventaire, traitement du paiement, déclencheur d’exécution) montrant le taux de réussite par étape |
| Plate-forme | Flux utilisateur | ✅ La surveillance au niveau du flux révèle des problèmes invisibles dans la surveillance au niveau du composant, car des échecs peuvent se produire à n’importe quel point de transition |
| Plate-forme | Flux utilisateur | ✅ Alerte le déclenchement lorsque les taux de réussite du flux passent sous les seuils acceptables ou lorsque la durée dépasse les objectifs de latence |
| Plate-forme | Intégration | ✅ La surveillance de l’intégrité de l’intégration détecte les défaillances système externes, les problèmes de réseau, les problèmes d’authentification et les approches de limitation de taux avant d’entrer en cascade dans les échecs auxquels font face les utilisateurs |
| Plate-forme | Intégration | ✅ La surveillance du taux de réussite alerte en cas de baisse sous 99 % pour les intégrations synchrones critiques |
| Plate-forme | Intégration | ✅ La surveillance de la distribution des erreurs alerte lorsque de nouveaux types d’erreur apparaissent qui n’existaient pas dans la référence |
| Plate-forme | Intégration | ✅ La surveillance du percentile de latence (p95) alerte lorsque le délai dépasse 3 secondes pour les appels synchrones auxquels les utilisateurs sont confrontés |
| Plate-forme | Intégration | ✅ Surveillance du débit alerte lorsque le taux est supérieur à 80 % de la limite de taux connue ou du seuil de SLA |
| Plate-forme | Intégration | ✅ La surveillance de l’état du disjoncteur alerte lorsque n’importe quel circuit s’ouvre indiquant une dégradation du système externe |
| Plate-forme | Intégration | ✅ La surveillance du taux de nouvelles tentatives alerte lorsque le taux de nouvelles tentatives soutenues dépasse 5 % indiquant des problèmes de fiabilité |
| Plate-forme | Intégration | ✅ L’intégration télémétrique achemine vers des plates-formes de surveillance centralisées permettant la corrélation à travers les frontières du système |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Plate-forme | Flux utilisateur | ⚠️ Les composants sont surveillés indépendamment montrant un fonctionnement sain alors que 12% des utilisateurs abandonnent les flux critiques sans visibilité sur les raisons pour lesquelles |
| Plate-forme | Flux utilisateur | ⚠️ Les tableaux de bord d’intégrité des composants sont affichés en vert alors que les utilisateurs ne peuvent pas réaliser les workflows critiques révélant une défaillance de l’architecture de surveillance |
| Plate-forme | Flux utilisateur | ⚠️ Le parcours utilisateur touchant plusieurs classes Apex, flux, événements de plate-forme et intégrations externes manque de visibilité de bout en bout |
| Plate-forme | Flux utilisateur | ⚠️ Les parcours métiers critiques manquent d’instrumentation ; les taux de réussite et les points d’abandon sont inconnus |
| Plate-forme | Intégration | ⚠️ Les échecs d’intégration ne sont détectés qu’après une cascade d’échecs rencontrés par l’utilisateur plutôt que proactivement |
| Plate-forme | Intégration | ⚠️ La télémétrie d’intégration reste isolée dans les systèmes individuels, empêchant l’analyse de corrélation et de causes profondes à travers les frontières |
| Plate-forme | Intégration | ⚠️ Surveillance des alertes sur les symptômes en aval une fois les dommages causés plutôt que de révéler précocement les causes profondes |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Plate-forme | SLIs | ✅ Les SLI de disponibilité mesurent le pourcentage de temps d’exécution des flux critiques avec succès du point de vue de l’utilisateur (recevant le résultat attendu, pas seulement 200 code de statut) |
| Plate-forme | SLIs | ✅ Les SLI de latence mesurent le temps nécessaire pour effectuer les opérations à p50 (médiane), p90 (90e percentile excluant les valeurs aberrantes), p95 (95e percentile excluant les pires valeurs aberrantes) et p99 (99e percentile montrant l’expérience du pire cas) |
| Plate-forme | SLIs | ✅ Les cibles de latence varient selon la criticité de l’opération et l’attente de l’utilisateur (la recherche de 500 ms est instantanée, la même latence de saisie de l’entrée est lente) |
| Plate-forme | SLIs | ✅ Les SLI de débit mesurent le volume d’opérations réussies par unité de temps, révélant les tendances d’utilisation de la capacité et de croissance |
| Plate-forme | SLIs | ✅ Le débit combiné à la latence indique si le système maintient les performances sous une charge croissante ou se dégrade à mesure que le volume augmente |
| Plate-forme | SLIs | ✅ Les SLI de taux d’erreur distinguent les types d’erreur (erreurs utilisateur telles que les échecs de validation et erreurs système telles que les exceptions de limite du gouverneur) |
| Plate-forme | SLOs | ✅ Les objectifs de niveau de service sont établis en définissant des seuils SLI acceptables basés sur les exigences métiers avant de sélectionner des modèles d’architecture |
| Plate-forme | SLOs | ✅ Exigence métier « Les commerciaux doivent afficher les mises à jour d’opportunité dans les 5 secondes » pilote SLO « Les chargements de page de détail d’opportunité sont terminés dans les 3 secondes à la p95 » qui pilote les décisions d’architecture |
| Plate-forme | SLOs | ✅ Les SLO émergent des exigences métiers et déterminent les décisions architecturales plutôt que d’être définis en fonction des objectifs actuels du système |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Plate-forme | SLIs | ⚠️ La disponibilité est mesurée du point de vue technique (code de statut 200) plutôt que du point de vue de l’utilisateur (résultat attendu) |
| Plate-forme | SLIs | ⚠️ La latence est mesurée uniquement à la médiane sans comprendre l’expérience utilisateur au pire des percentiles p95 ou p99 |
| Plate-forme | SLIs | ⚠️ Les SLI de taux d’erreur ne font pas la distinction entre les erreurs utilisateur et les erreurs système, masquant différents problèmes nécessitant différentes solutions |
| Plate-forme | SLOs | ⚠️ L’architecture est construite d’abord, puis la SLO est définie comme « tout ce que nous réalisons actuellement » conduisant à l’acceptation de chargements de page de 12 secondes car la conception du système n’a jamais pris en compte les exigences des utilisateurs |
| Plate-forme | SLOs | ⚠️ Les SLO sont pilotés par l’architecture plutôt que par l’entreprise, en définissant des objectifs basés sur ce que le système atteint plutôt que sur les besoins des utilisateurs |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Plate-forme | Alerte | ✅ La classification de la sévérité achemine immédiatement les incidents critiques (production non disponible, risque de corruption des données, atteinte à la sécurité) vers les ingénieurs d’astreinte de page |
| Plate-forme | Alerte | ✅ Les incidents de haute gravité (performances dégradées, pannes partielles) génèrent des notifications pour une enquête rapide dans les heures ouvrables |
| Plate-forme | Alerte | ✅ Les avertissements (seuils proches, dérive de configuration) génèrent des notifications digest quotidiennes pour une correction proactive |
| Plate-forme | Alerte | ✅ Le contexte des alertes inclut le nombre d’utilisateurs affectés, les messages d’erreur, les traces de pile, les déploiements récents, les alertes associées et les liens vers les tableaux de bord appropriés |
| Plate-forme | Alerte | ✅ Le contexte enrichi réduit le délai moyen d’acceptation en permettant une évaluation et une enquête immédiates de la sévérité sans recueillir d’informations de base |
| Plate-forme | Alerte | ✅ Le regroupement des alertes empêche les tempêtes d’alerte où des centaines d’alertes associées sont déclenchées pour un seul problème sous-jacent |
| Plate-forme | Alerte | ✅ L’échec de l’intégration déclenche une alerte groupée par point de terminaison d’intégration montrant 156 requêtes échouées au cours des 5 dernières minutes avec un graphique de latence, une distribution d’erreurs et un lien vers le tableau de bord |
| Plate-forme | Alerte | ✅ La suppression des alertes empêche les conditions transitoires connues de générer des alertes pendant les périodes de maintenance ou de correction automatique attendues |
| Plate-forme | Alerte | ✅ Les alertes sont supprimées pendant la maintenance planifiée, pendant les premières minutes après le déploiement lorsque les caches sont chaudes, et lors de brefs échecs transitoires lorsque la logique de nouvelle tentative réussit |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Plate-forme | Alerte | ⚠️ Toutes les alertes sont acheminées vers le même canal sans classification de sévérité ; les incidents critiques ne sont pas distingués des avertissements de routine |
| Plate-forme | Alerte | ⚠️ Les alertes manquent de contexte diagnostique ; les ingénieurs d’astreinte doivent recueillir des informations de base via des requêtes séparées avant d’évaluer la sévérité |
| Plate-forme | Alerte | ⚠️ L’échec de l’intégration génère 156 alertes individuelles en 5 minutes submergeant le téléphone de l’ingénieur d’astreinte, chaque alerte étant identique à l’exception de l’horodatage |
| Plate-forme | Alerte | ⚠️ Les tempêtes d’alerte empêchent les intervenants de distinguer un seul problème sous-jacent des centaines de symptômes associés |
| Plate-forme | Alerte | ⚠️ Alerte le feu pendant les périodes de maintenance connues et les conditions transitoires générant un bruit qui érode Trust dans la surveillance |
| Plate-forme | Alerte | ⚠️ Alerter la fatigue à partir de faux positifs bruyants entraîne les équipes à ignorer les notifications réduisant l’efficacité des réponses |