Modèles de disponibilité et de performance
En savoir plus sur la fiabilité bien archivée → Architecture haute disponibilité
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Analyse de l’impact commercial | ✅ SLO définis par capacité métier (p. ex. « Flux de fermeture d’opportunité : 99,9 % de disponibilité, latence p95 inférieure à 2 secondes”) plutôt que par composant technique |
| Documentation sur les flux utilisateur | ✅ Chaque flux utilisateur critique a une SLO mesurable couvrant la disponibilité, la latence, le débit, le taux d’erreur et le temps de récupération lié à l’expérience utilisateur réelle |
| Enregistrements de décision d’architecture | ✅ Objectifs de disponibilité basés sur l’analyse des impacts des temps d’arrêt d’activité avec une justification documentée (p. ex. rapports par lot internes 99 % par rapport au traitement des commandes critiques pour le revenu 99,95 %) |
| Spécifications SLO | ✅ Objectifs réalistes tenant compte de la complexité architecturale (99 % = capacités standard de la plate-forme, 99,5 % = redondance de base et surveillance active, 99,9 % = sensibilisation multi-régions et basculement automatisé, 99,95 % = schémas actifs-actifs et tests du chaos, 99,99 % = architecture multi-organisations) |
| Documentation de la plate-forme | ✅ SLO de solution moins stricts que les SLA de plate-forme (par exemple, SLA de plate-forme 99,9 % → SLO de solution 99,5 %) fournissant un budget d’erreur pour les échecs de la couche applicative |
| Configuration de la surveillance | ✅ Indicateurs de niveau de service (SLI) mesurables objectivement via une instrumentation de plate-forme: temps de fonctionnement Trust.salesforce.com, analytiques Experience Cloud, temps de réponse de l’API Event Monitoring, réalisation AsyncApexJob |
| Métriques d’expérience utilisateur | ✅ Les SLO reflètent les parcours utilisateur complets (p. ex. « Flux de soumission de requêtes : les 5 étapes sont terminées dans les 8 secondes pour les utilisateurs p95”) pas le temps de fonctionnement d’API individuel |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Documentation sur l’architecture | ⚠️ « Le système doit être rapide et fiable » (pas mesurable, ne conduit à aucune décision d’architecture) |
| Spécifications SLO | ⚠️ « Tout nécessite un temps de fonctionnement de 99,999 % » (coût injustifié en ignorant les différences de criticité métier entre les opérations de chiffre d’affaires et les outils d’administration interne) |
| Stratégie de surveillance | ⚠️ Surveillance du processeur de l’infrastructure en tant que SLI principal (les architectes de métriques de plate-forme ne peuvent pas agir, ne reflétant pas l’expérience des utilisateurs) |
| Planification de la capacité de la plate-forme | ⚠️ Solution SLO correspond exactement au SLA de la plate-forme à 99,9 % (aucun budget d’erreur pour des problèmes de couche applicative, des échecs d’intégration ou une maintenance planifiée) |
| Documentation SLO | ⚠️ SLO définis par composant technique plutôt que par capacité métier accessible aux utilisateurs (disponibilité du composant nécessaire, mais insuffisante pour la fiabilité de l’expérience utilisateur) |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Stratégie de déploiement régional | ✅ Le déploiement sur une seule région avec la redondance Hyperforce gérée par la plate-forme (zones de disponibilité multiples, basculement automatique de l’infrastructure) fournit 99,9% de SLO pour la plupart des solutions |
| Architecture multi-organisations | ✅ Modèles multi-organisations uniquement lorsque l’entreprise nécessite un RPO/RTO garanti au-delà des capacités de la plate-forme, l’isolation des données géographiques réglementaires ou une indépendance régionale complète (actif-passif ou actif-actif avec la synchronisation des données) |
| Réplication des données | ✅ Capture des données de modification pour les données critiques (RPO en temps quasi réel, minutes), Événements de plate-forme pour les événements commerciaux en temps quasi réel, extraction planifiée de l’API de transfert en masse 2.0 pour les données de référence (RPO sur 24 heures) |
| Surveillance de l’intégrité de la plate-forme | ✅ Abonnement aux notifications de statut Trust.salesforce.com et aux API de statut spécifiques à l’instance permettant une réponse proactive aux incidents, aux fenêtres de maintenance et aux impacts sur les performances |
| Gestion dynamique de la charge | ✅ Les solutions répondent à l’état de santé de la plate-forme en réduisant le traitement par lot non critique pendant la dégradation, en reportant les tâches en arrière-plan pendant les périodes de maintenance |
| Utilisation du Centre d’échelle | ✅ L’examen hebdomadaire du Centre d’échelle identifie les transactions et les opérations de longue durée qui consomment des ressources disproportionnées, permettant une restauration architecturale avant l’impact sur les utilisateurs |
| Couches de détection des échecs | ✅ Détection à plusieurs niveaux: échecs de plate-forme via l’API status, échecs d’intégration via la surveillance du délai d’expiration, échecs d’application via la consignation des exceptions, dégradation des performances via les percentiles de latence, avertissements de capacité via Proactive Monitoring |
| Seuils d’alerte | ✅ Les alertes sont déclenchées par des modèles de taux d’erreur (par exemple, 5 expirations d’API en 60 secondes) ou une dégradation soutenue, pas par des pannes isolées normales dans les systèmes distribués |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Conception multi-organisations | ⚠️ Architecture multi-organisations implémentée « au cas où » sans exigence métier documentée justifiant la complexité opérationnelle de la synchronisation des données, provisionnement utilisateur, coordination du déploiement |
| Surveillance de l’intégrité de la plate-forme | ⚠️ Ignorer les notifications de statut Trust.salesforce.com, découvrir les fenêtres de maintenance lorsque les utilisateurs signalent des échecs (réponse réactive plutôt que proactive) |
| Détection des échecs | ⚠️ Alerte sur chaque erreur individuelle, quel que soit le taux (génère une fatigue d’alerte masquant les signaux critiques) ; l’expiration unique de l’API déclenche l’expiration de la page (réaction excessive au comportement normal du système distribué) |
| Réplication des données | ⚠️ Aucune surveillance spécifique à l’intégration, découvrez les échecs d’intégration uniquement lorsque les utilisateurs signalent des opérations bloquées (visibilité manquante sur l’intégrité du système externe) |
| Stratégie de redondance | ⚠️ Appel synchrone au service d’enrichissement externe sans expiration ni solution de repli (utilisateur bloqué lorsque le service externe est lent ou non disponible) |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Surveillance des utilisateurs réels (RUM) | ✅ Latence utilisateur réelle mesurée via des analytiques Experience Cloud ou une instrumentation personnalisée reflétant les conditions réelles du réseau, les performances de l’appareil, la distribution géographique |
| Surveillance synthétique | ✅ Transactions automatisées à partir de plusieurs emplacements qui valident la disponibilité et les performances avant que les utilisateurs signalent des problèmes (par exemple, soumission de commande toutes les 15 minutes dans 3 régions) |
| Traçage des transactions | ✅ Opérations à plusieurs étapes instrumentées avec un calendrier par étape identifiant les goulets d’étranglement (par exemple, l’appel externe de validation d’adresse de l’étape 3 représente 70 % de la latence totale) |
| Optimisation des requêtes | ✅ Requêtes sélectives avec des filtres indexés, requêtes de relation réduisant les allers-retours, prise en compte de l’optimiseur de requête avec des volumes de données à l’échelle de la production (le comportement change radicalement avec plus de 10M enregistrements) |
| Utilisation du cache de la plate-forme | ✅ Partitions de cache de session ou d’organisation servant des données de référence fréquemment accédées, préremplies lors d’opérations réussies fournissant des données périmées mais disponibles lorsque l’API en temps réel n’est pas disponible |
| Configuration d’expiration | ✅ Appels externes synchrones face à l’utilisateur 5-10 secondes (interface utilisateur réactive), appels externes asynchrones en arrière-plan 30-60 secondes (performances externes variables), traitement par lot 120 secondes (aucun utilisateur en attente); budget total à travers plusieurs appels externes par transaction |
| Surveillance de la latence d’intégration | ✅ percentiles de latence p50/p95/p99 par intégration avec SLO par point de terminaison ; les anomalies de latence (temps de réponse à la hausse) indiquent une saturation de la capacité avant un échec complet |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Stratégie de surveillance | ⚠️ Surveiller uniquement les métriques d’infrastructure (CPU du serveur, bande passante réseau) sans mesure de flux orientée utilisateur (les métriques ne reflètent pas l’expérience utilisateur réelle) |
| Stratégie de mise en cache | ⚠️ Aucune utilisation du cache de la plate-forme pour les données de référence fréquemment accédées (requêtes répétées pour les mêmes données augmentant la latence et consommant des limites SOQL) |
| Configuration d’expiration | ⚠️ Appel externe Flux synchrone avec une expiration de 120 secondes qui oblige l’utilisateur à fixer le chargement de la toupie pendant 2 minutes (doit utiliser une expiration de 5 à 10 secondes avec repli) |
| Test de performance | ⚠️ Test à petite échelle avec des volumes de données réduits (le comportement de l’optimiseur de requête change radicalement à plus de 10M d’enregistrements, ce qui rend les résultats à petite échelle trompeurs) |
| Conception de l’intégration | ⚠️ Aucun traçage au niveau de la transaction des workflows à plusieurs étapes (étape goulot d’étranglement invisible dans les métriques agrégées) |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Modèles d’échelle horizontale | ✅ Charge de travail distribuée entre plusieurs ressources : traitement en masse traite plusieurs enregistrements par transaction, traitement asynchrone distribue le travail dans le temps, partitionnement des données distribue la charge à travers les frontières |
| Configuration du traitement par lot | ✅ Limites optimales en débit et en gouverneur d’équilibrage de taille de lot (2 000 enregistrements par exécution Apex batch, 200 enregistrements par invocation de déclencheur, 25 requêtes par appel d’API composite) |
| Gestion des taux d’API | ✅ La mise en lot et en cache de l’intégration réduit la consommation d’API, surveille l’allocation d’API sur 24 heures par édition, la planification de la capacité ajoute des licences ou limite les augmentations avant l’épuisement |
| Exécution simultanée | ✅ Tâches par lot parallèles pour les données partitionnées (5 lots de cumul régionaux exécutés simultanément), les abonnés à l’événement de plate-forme traitant les flux simultanément |
| Surveillance de la profondeur de la file d’attente | ✅ Pour les intégrations asynchrones, les tendances de profondeur de file d’attente indiquent un retard de traitement par rapport à la cadence de production nécessitant une augmentation de la capacité ou une optimisation du débit |
| Détection des anomalies de volume | ✅ Les volumes de transactions nettement supérieurs ou inférieurs aux modèles attendus peuvent indiquer un emballement des processus nécessitant une investigation et une limitation |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Traitement par lot | ⚠️ Traiter tous les enregistrements de façon séquentielle lorsque le volume de données nécessite une exécution parallèle partitionnée (le partitionnement basé sur la date, basé sur le type d’enregistrement ou basé sur le propriétaire active le traitement simultané) |
| Consommation d’API | ⚠️ Le schéma d’intégration ajoute 25 % de consommation d’API sans planification de capacité (des erreurs soudaines de « limite d’API dépassée » impactent les utilisateurs) |
| Surveillance des files d’attente | ⚠️ Aucune surveillance de la profondeur de la file d’attente d’intégration asynchrone (le traitement est en retard sur la cadence de production sans visibilité) |
| Gestion des limites du gouverneur | ⚠️ Opérations synchrones traitant des volumes importants atteignant la taille du tas ou les limites en temps processeur (devrait passer au traitement asynchrone avec des limites dédiées) |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Hiérarchie de criticité des fonctionnalités | ✅ Niveaux définis : Critique (chiffre d’affaires/conformité, jamais dégradé), Important (flux de travail principaux, dégradés uniquement en cas d’incident majeur), Support (expérience améliorée, désactivé en cas d’échec de l’intégration), Facultatif (agréable, désactivé en cas de charge élevée) |
| Implémentation du disjoncteur | ✅ États du circuit (Fermé = normal, Ouvert = échoue immédiatement après le seuil, Mi-ouvert = sonde de récupération); Cache de la plate-forme stocke l’état, les événements de plate-forme diffusent des changements; s’ouvre après des échecs consécutifs (par exemple, 10 échecs) |
| Logique de nouvelle tentative | ✅ Backoff exponentiel pour les échecs transitoires (1s, 2s, 4s, 8s, plafond à 30-60s); réessayez les expirations réseau et les erreurs 5xx avec backoff, réessayez les limites de taux 429 après l’en-tête Réessayer-Après; ne réessayez jamais les erreurs 4xx du client ou du gouverneur dans la même transaction |
| Stratégies de repli | ✅ Sources de données alternatives (Cache de la plate-forme lorsque l’API en temps réel n’est pas disponible), comportement par défaut (règles standard lorsque le service de personnalisation est en panne), processus manuel (interface d’administration pour les transactions bloquées), file d’attente pour les nouvelles tentatives (Événements de plate-forme avec 72h de relecture) |
| Architecture de gestion des erreurs | ✅ Échouer rapidement (valider les entrées à l’entrée), échouer gracieusement (traiter 197 enregistrements sur 200 lorsque 3 échouent la validation), échouer de façon informative (consignation avec ID de transaction, contexte utilisateur, trace de pile), échouer en toute sécurité (annuler les transactions partielles, ne jamais exposer les internes aux utilisateurs) |
| Automatisation de la récupération | ✅ La surveillance de la plate-forme déclenche une récupération automatisée : mécanismes de nouvelle tentative asynchrones, files d’attente de lettres mortes pour échec de traitement, workflows d’auto-guérison permettant une récupération rapide sans intervention manuelle |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Dépendance de l’intégration | ⚠️ La soumission de commande échoue complètement lorsque le service de validation d’adresse externe est en panne (flux critique bloqué par la fonctionnalité de support; devrait se dégrader gracieusement avec une révision manuelle) |
| Stratégie du disjoncteur | ⚠️ Aucun disjoncteur sur appel externe entraînant l’attente de 120 secondes d’expiration de chaque transaction lorsque le système externe est en panne (tous les utilisateurs impactés par une intégration défaillante) |
| Logique de nouvelle tentative | ⚠️ Réessayer la limite en processeur Apex dépassé l’erreur immédiatement dans le même contexte de transaction (échouera de nouveau; devrait remettre en file d’attente en tant qu’opération asynchrone avec des limites dédiées) |
| Logique de nouvelle tentative | ⚠️ Réessayer indéfiniment jusqu’à la réussite (risque de boucle infinie, transaction jamais terminée ; devrait plafonner le nombre maximal de nouvelles tentatives) |
| Traitement des erreurs | ⚠️ Try-catch block avale exception sans consignation (échec invisible pour les opérateurs empêchant le diagnostic et la remédiation) |
| Traitement des erreurs | ⚠️ Afficher la trace de la pile à l’utilisateur final dans la page Lightning (risque de sécurité révélant les détails d’implémentation, mauvaise expérience utilisateur) |
| Stratégie de repli | ⚠️ Le service de calcul de la taxe échoue en bloquant toutes les soumissions de commande (capacité critique sans solution de repli ; devrait être mis en file d’attente pour traitement manuel ou utiliser des taux par défaut) |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Modélisation de la santé | ✅ État de santé agrégé: Santé du service (taux de réussite des transactions >99,5 % vert, 98-99,5 % jaune, <98 % rouge), Santé de l’intégration (toutes les réponses vertes, jaune dégradé, rouge ouvert du disjoncteur), Santé des données (courant de synchronisation vert, derrière jaune, rouge périmé/défaillant), Santé de la capacité (<70 % vert, 70-85 % jaune, >85 % rouge) |
| Surveillance des événements | ✅ Objets EventLogFile avec livraison 24h/1h acheminée vers SIEM externe pour rétention au-delà des limites en rétention native; capture les appels d’API, les vues de page, les exportations de rapports, l’activité de connexion, l’exécution Apex |
| Alertes Proactive Monitoring | ✅ L’évaluation continue expose les pics de limite en requêtes d’API (le seuil de 75% déclenche l’investigation), les échecs d’exécution Apex simultanés, les problèmes de limite en lignes SOQL, les tendances de consommation de stockage |
| Tableau de bord d’intégrité de l’intégration | ✅ Métriques par intégration : taux d’erreur (<1 % cible), latence p50/p95/p99 avec SLO, taux d’expiration (<0,1 % cible), état du disjoncteur, profondeur de file d’attente asynchrone ; journaux structurés avec ID de requête, point de terminaison, code de réponse, durée |
| Conception de l’alerte actionnable | ✅ Chaque alerte définit qui répond, ce qu’ils vérifient, comment ils corrigent; inclut le seuil franchi, la valeur actuelle, les tendances récentes, le lien du tableau de bord, le lien du runbook; la sévérité correspond à l’urgence (pages CRITIQUES à l’appel pour l’impact des utilisateurs, e-mails d’AVERTISSEMENT pour les préoccupations de tendance) |
| Détection des anomalies | ✅ anomalies de volume (300 % de la charge typique), anomalies de taux d’erreur (2 % vs 0,5 % typique même si le seuil est inférieur à 5 %), dérive de la latence (tendance à la hausse graduelle), anomalies comportementales (modèles de connexion inhabituels, tâches par lot en dehors de la planification) ; utilisé pour guider l’enquête et ne pas déclencher une escalade immédiate |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Surveillance des événements | ⚠️ Surveillance des événements activée mais jamais exportée (rétention native insuffisante pour l’analyse des tendances, données historiques perdues) |
| Conception de l’alerte | ⚠️ Message d’alerte « Erreur rencontrée » sans contexte, seuil ou action de réponse (génère une fatigue d’alerte, les opérateurs ne peuvent pas trier efficacement) |
| Sévérité de l’alerte | ⚠️ Traiter toutes les anomalies comme des alertes critiques (un taux élevé de faux positifs crée une fatigue des alertes entraînant le manque d’alertes critiques) |
| Surveillance sanitaire | ⚠️ Pas de modèle de santé agrégé, les opérateurs submergés de métriques techniques individuelles manquent de schémas inter-systèmes |
| Surveillance de l’intégration | ⚠️ Pas de taux d’erreur spécifique à l’intégration, de latence ou de suivi de l’état du disjoncteur (échecs d’intégration découverts de façon réactive dans les rapports utilisateur) |
| Surveillance de la capacité | ⚠️ Aucun examen Proactive Monitoring ou Scale Center (les risques de fiabilité liés aux transactions gourmandes en ressources ne sont pas détectés jusqu’à l’impact en production) |
Pour des exemples en ligne et des conseils détaillés, consultez le pilier Fiabilité ou parcourez l’explorateur Modèles et anti-modèles.