Fiabilité

Salesforce exploite une infrastructure résiliente dans plusieurs régions avec le basculement automatisé et la résilience au niveau de l'infrastructure. La plate-forme gère la redondance du centre de données, la disponibilité du réseau et le correctif de l'infrastructure, avec un statut de disponibilité de la plate-forme en temps réel visible sur Trust.salesforce.com.

Vous concevez la fiabilité de tout ce qui fonctionne sur cette infrastructure :: les modèles de données qui évoluent dans les limites du gouverneur, les transactions qui anticipent et récupèrent en cas d'échec, la surveillance qui détecte lorsque votre solution s'écarte des objectifs de disponibilité et les procédures de reprise après sinistre qui restaurent les opérations commerciales en cas d'échec.

Le contrat de niveau de service Salesforce couvre la plate-forme, mais vous détenez la fiabilité pour tout ce qui est au-dessus de la couche infrastructure. Vous êtes responsable de la définition et de la réalisation de vos propres objectifs de niveau de service (SLO), c'est-à-dire les objectifs de fiabilité requis par votre entreprise. La fiabilité au niveau de la couche applicative reste votre responsabilité, quel que soit le niveau de contrat de niveau de service de la plate-forme. La même plate-forme qui garantit la disponibilité la limite également : Les limites du gouverneur limitent la consommation de ressources de chaque locataire afin qu'aucun locataire ne puisse dégrader la plate-forme pour d'autres. Votre solution doit donc évoluer gracieusement dans ces limites, plutôt que de simplement demander plus de capacité.

Des solutions non fiables peuvent créer des impacts métiers en cascade. Le flux de revenu ralentit lorsque les plates-formes de commerce ne sont pas disponibles. La productivité diminue lorsque les outils internes échouent en plein workflow. Trust s'érode lorsque des données sont corrompues ou des enregistrements sont perdus. Ces problèmes s'aggravent au fil du temps à mesure que les contournements s'accumulent et que la dette technique augmente.

La fiabilité ne consiste pas à empêcher toutes les pannes. Les échecs se produisent dans les systèmes distribués. La fiabilité consiste à concevoir des systèmes qui anticipent les pannes, aident à contenir le rayon d'explosion et restaurent automatiquement le service. Les exigences de fiabilité varient selon l'impact commercial. Par exemple, un portail Experience Cloud accessible aux clients qui nécessite une disponibilité de 99,9 % implique des choix architecturaux fondamentalement différents qu'un processus de génération de rapports par lot interne qui tolère des retards occasionnels.

La fiabilité et l'excellence opérationnelle sont étroitement liées. Les deux traitent de la surveillance, de la réponse aux incidents et de la disponibilité du système. Ce chevauchement est intentionnel, pas accidentel. La distinction réside dans le temps de conception par rapport au temps d'exécution.

La fiabilité est ce que vous intégrez dans un système avant son exécution, notamment :

• les modèles de données précédemment mentionnés qui évoluent dans les limites du gouverneur
• les transactions qui anticipent et récupèrent les échecs
• la redondance et les disjoncteurs qui contiennent le rayon de souffle
• les objectifs de récupération - objectif de temps de récupération (RTO) et objectif de point de récupération (RPO) - qui déterminent le comportement de votre système en cas de problème.

La fiabilité est parfaite, c'est une propriété structurelle de votre solution.

L'excellence opérationnelle est la façon dont vous exploitez, améliorez et soutenez le système une fois qu'il est opérationnel, notamment :

• les pratiques de déploiement qui réduisent le risque de changement
• les runbooks et les parcours d'escalade qui guident votre équipe pendant les incidents
• les pipelines d'observabilité qui exposent les signaux
• les boucles de rétroaction qui améliorent le système au fil du temps.

L'excellence opérationnelle est pratiquée, c'est la discipline humaine et de processus entourant votre solution.

Le terrain commun entre les deux piliers est la couche de surveillance et d'observabilité. La surveillance est conçue comme un problème de fiabilité. Vous devriez construire des systèmes observables. Il est pratiqué comme une préoccupation d'excellence opérationnelle. Votre équipe agit en fonction de ce que ces systèmes vous disent. La fiabilité couvre les modèles architecturaux que vous intégrez, notamment les seuils d'alerte et les tableaux de bord d'intégrité. L'excellence opérationnelle désigne la façon dont votre équipe réagit aux signaux, tels que les runbooks et les réponses d'astreinte.

Tenez compte de cette distinction : La fiabilité indique « ce système survivra-t-il ? » tandis que l'Excellence opérationnelle traite de « votre équipe peut-elle l'exploiter ? » Un système parfaitement fiable, exploité par une équipe sans runbook, déploiement incohérent ou boucle de rétroaction, peut échouer en pratique. Une équipe opérationnellement excellente qui gère un système fragile et mal conçu sera submergée par des incidents qu'elle ne peut empêcher. Les deux piliers sont nécessaires et aucun ne remplace l'autre.

La fiabilité ne fonctionne pas isolément. Comme nous l'avons décrit dans les sections précédentes, l'Excellence opérationnelle est son partenaire le plus proche. Les deux piliers partagent la couche d'observabilité, la fiabilité définissant ce que vous élaborez dans un système et l'excellence opérationnelle définissant le fonctionnement de votre équipe. Trust nécessite également une infrastructure qui résiste aux attaques et préserve l'intégrité des données: un système n'est pas fiable s'il peut être compromis. L'optimisation des ressources empêche l'épuisement des limites du gouverneur, ce qui garantit la fiabilité de la plate-forme à l'échelle. L'optimisation des coûts permet d'équilibrer les investissements de fiabilité et la valeur métier qu'ils génèrent. Les objectifs de disponibilité justifient la complexité architecturale requise pour les atteindre. Aucun pilier ne produit isolément une solution bien conçue — la fiabilité fournit la base structurelle sur laquelle les autres piliers dépendent et se renforcent.

Utilisez ces principes pour guider vos décisions architecturales en matière de fiabilité sur la plate-forme.

• Distribuer la charge de travail par le biais de la pondération. Traitez plusieurs enregistrements dans des transactions uniques au lieu de vous appuyer sur des opérations séquentielles par enregistrement. La mise en masse partage les limites du gouverneur entre un lot traité dans une seule transaction, en respectant ces limites tout en optimisant le débit. Le traitement Apex basé sur des collections, les tâches par lot avec une étendue configurable et les événements de plate-forme consommés en masse incarnent tous ce principe. Les solutions bien traitées traitent 200 enregistrements avec le même nombre d'instructions SOQL et DML qu'un seul enregistrement en traitement séquentiel. Les modèles de charge de travail distribués offrent une résilience, car aucune défaillance d'enregistrement n'impacte le traitement de l'ensemble du lot.
• Prenons que tout échoue. Les limites du gouverneur, les fenêtres de maintenance de la plate-forme et les dépendances d'intégration créent des modes d'échec associés à l'architecture multilocataire Salesforce. Concevez dès le départ ces pannes spécifiques à la plate-forme. Les requêtes SOQL dépassent les limites en lignes sous un asymétrie de données. Le temps processeur Apex peut expirer lors de calculs complexes. Les expirations d'appel peuvent se produire lorsque les services externes ralentissent. Les verrous de ligne DML échouent lorsque des transactions simultanées entrent en collision. Les limites en stockage peuvent échouer lorsque les chargements de fichiers augmentent de façon inattendue. Les architectes qui planifient ces échecs élaborent des solutions fiables sans intervention manuelle. Ces systèmes fiables détectent les limites proches du gouverneur, contiennent le rayon d'explosion grâce au traitement des erreurs et récupèrent automatiquement via de nouvelles tentatives d'infrastructure et d'événements de plate-forme.
• Construire des systèmes autorécupérateurs. Concevez des solutions qui détectent les pannes et se rétablissent automatiquement sans intervention humaine. Les événements de plate-forme activent les modèles de nouvelle tentative personnalisés. La livraison à un abonné peut être réessayée avec EventBus.RetryableException, bien que la relecture de la transaction d'origine nécessite une architecture personnalisée. Le traitement des erreurs de flux dirige les exceptions vers les flux de récupération. Les tâches par lot Apex isolent les échecs de segment - un segment échoué n'empêche pas les autres segments de traiter - ce qui permet une réalisation partielle des tâches et une nouvelle tentative ciblée. Implémentez une logique de nouvelle tentative explicite en utilisant le suivi des erreurs dans AsyncApexJob pour la reprise après échec transitoire. Appliquez un recul exponentiel à ces schémas de nouvelle tentative lors du traitement des échecs transitoires. Les systèmes de récupération automatique maintiennent les objectifs de disponibilité, même en dehors des heures de travail, lorsque les intervenants humains ne sont pas disponibles, ce qui réduit le fardeau opérationnel tout en augmentant le temps moyen nécessaire pour récupérer.
• Concevez d'abord pour les exigences métiers. Définissez des objectifs de niveau de service basés sur l'impact métier réel avant de sélectionner des solutions techniques. Les composants ne nécessitent pas tous une disponibilité cinq-neufs. Adaptez l'investissement en fiabilité à la criticité métier et concevez une dégradation gracieuse pour les fonctionnalités de support. Les objectifs réalistes permettent des choix d'architecture appropriés et évitent la sur-ingénierie ou les sous-réalisations.
• Validez la récupération par des forages. Planifiez des exercices de reprise après sinistre qui testent la restauration de sauvegarde, les procédures de basculement et les playbooks de réponse aux incidents. Restaurez une sandbox Full Copy à partir d'une sauvegarde en production pour valider les processus de récupération. Introduisez des échecs délibérés dans les environnements sandbox pour vérifier que votre surveillance détecte des problèmes et que la récupération automatisée est correctement exécutée. Les exercices révèlent des lacunes dans les procédures, l'outillage et les livres d'exécution avant que de véritables incidents ne les exposent. Documentez les résultats des forages et suivez les correctifs des écarts découverts. Des tests réguliers garantissent que les capacités de récupération restent à jour à mesure que les solutions évoluent et que les membres de l'équipe changent.

Comprendre les opérations de Salesforce permet de concentrer les efforts de conception de la fiabilité sur ce que vous contrôlez. La plate-forme gère les problèmes d'infrastructure qui nécessiteraient des équipes dédiées dans les environnements informatiques traditionnels, tels que :

• Infrastructure multi-régions et basculement : Salesforce Hyperforce fournit aux centres de données régionaux un basculement automatisé des services internes. Il fournit également plusieurs zones de disponibilité dans les régions, et la réplication des données au niveau de la couche infrastructure. La plate-forme gère de façon transparente la distribution des zones de redondance et de disponibilité dans les régions.
• Engagements de SLA de plate-forme : Les niveaux de disponibilité garantis avec des recours contractuels sont négociés sur une base par client. Trust.salesforce.com publie en temps réel le statut de la plate-forme et l'historique des temps de fonctionnement, mais toute garantie de disponibilité spécifique et ses recours résident dans votre accord négocié. Consultez votre contrat et la documentation actuelle sur Salesforce Trust and Compliance pour connaître les engagements qui s'appliquent à votre organisation.
• Redondance de l'infrastructure : La plate-forme maintient des serveurs, des chemins de réseau, une infrastructure de base de données et des systèmes de stockage redondants. Le basculement au niveau de l'infrastructure se produit automatiquement lors de pannes matérielles sans intervention du client. Les sauvegardes de plate-forme protègent contre la perte de données au niveau de l'infrastructure.
• Maintenance et mises à jour de la plate-forme : Les principales versions de plate-forme offrent des fonctionnalités et des correctifs de sécurité avec la rétrocompatibilité gérée par Salesforce. Les fenêtres de maintenance de la plate-forme sont planifiées et communiquées sur trust.salesforce.com. Le correctif de l'infrastructure est effectué de façon transparente, sans l'intervention du client.
• Surveillance de l'intégrité de la plate-forme principale : Salesforce surveille les performances de l'infrastructure, notamment les temps de réponse à la base de données, la latence réseau, l'intégrité de la passerelle d'API et les performances du système de stockage. L ' état d ' intégrité de la plate-forme est affiché à l ' adresse trust.salesforce.com et comprend des informations en temps réel sur les incidents. Le statut spécifique à l'instance est disponible via l'API Statut.

Ces opérations de plate-forme créent les fondations sur lesquelles vous vous appuyez. Vous ne gérez pas les centres de données, les serveurs de provisionnement ou la conception de reprise après sinistre d'infrastructure. Vous êtes plutôt responsable de ce que vous concevez et configurez en plus de cette fondation.

Le modèle de responsabilité partagée spécifie que vous êtes responsable de tout ce que vous créez avec Salesforce. La fiabilité de la plate-forme active votre travail, mais ne le remplace pas. Vos responsabilités en matière de fiabilité couvrent six domaines interconnectés :

Les objectifs de niveau de service quantifient les exigences de fiabilité en termes mesurables. Les SLO répondent aux exigences métiers et à l'architecture technique. Avant de sélectionner des technologies ou de concevoir des modèles de données, établissez des SLO qui définissent la réussite de chaque flux utilisateur critique.

Les SLO mesurent généralement :

• Disponibilité - pourcentage de temps pendant lequel le système est opérationnel et accessible
• Latence - temps nécessaire pour effectuer les opérations, mesuré en percentiles (p50, p95, p99)
• Débit - volume d'opérations effectuées avec succès par unité de temps
• Taux d'erreur - pourcentage de requêtes qui échouent ou renvoient des erreurs
• Délai de récupération - durée requise pour rétablir le service après des incidents

Définissez des SLO par capacité métier plutôt que par composant technique. Les capacités accessibles aux utilisateurs nécessitent des SLO plus stricts que les processus administratifs ou par lot. Chaque SLO doit être mesurable objectivement en utilisant les instruments disponibles.

Les accords de niveau de service (SLA) sont des engagements contractuels avec des conséquences en cas d'échec. Tout niveau de disponibilité garanti et ses recours contractuels sont négociés par client. Consultez votre contrat et la documentation actuelle de Salesforce Trust and Compliance pour connaître les engagements applicables à votre organisation.

Les SLO de solution doivent être moins stricts que les SLA de plate-forme pour préserver le budget d'erreur. Si votre accord de niveau de service de plate-forme et votre solution SLO ciblent tous deux 99,9 %, tout temps d'arrêt important de la plate-forme consomme directement votre budget d'erreur, ce qui ne laisse aucune période tampon pour les échecs de la couche applicative, les problèmes d'intégration ou la maintenance planifiée pendant la même période de mesure. Une SLO est formellement enfreinte uniquement lorsque les temps d'arrêt cumulés épuisent le budget d'erreur complet pour la période de mesure. Si votre SLA et votre SLO sont définis sur le même objectif, un seul incident de plate-forme peut épuiser entièrement ce budget. Par exemple, lorsque la plate-forme fournit 99,9 %, ciblez une solution SLO de 99,5 % afin de maintenir une période tampon significative pour les problèmes que vous devez résoudre : bogues d'application, échecs d'intégration et fenêtres de déploiement.

Les indicateurs de niveau de service (SLI) sont des mesures utilisées pour évaluer la réalisation de la SLO. Les SLI doivent être mesurables objectivement, collectées de façon cohérente et directement liées à l'expérience utilisateur.

Pour les solutions Salesforce, les SLI comprennent :

• Temps de fonctionnement de la plate-forme via trust.salesforce.com
• Temps de chargement de page via les analytiques Experience Cloud
• Temps de réponse de l'API via Event Monitoring (qui nécessite le complément Event Monitoring ou Salesforce Shield)
• Taux de réussite des transactions via la consignation d'applications personnalisées
• Réalisation de tâches par lot via la surveillance AsyncApexJob

Des objectifs de disponibilité plus élevés entraînent une complexité et un coût croissants. Comprenez les implications architecturales avant de vous engager sur des objectifs :

Évitez les cibles arbitraires comme "cinq neuf pour tout". Évaluez à la place l'impact commercial des temps d'arrêt par capacité et définissez des objectifs en conséquence. Les rapports par lot internes qui tolèrent 7 heures d'arrêt mensuel nécessitent une architecture fondamentalement différente que le traitement des commandes critiques pour le revenu qui nécessite une récupération inférieure à une heure.

Définissez la fiabilité du point de vue des utilisateurs plutôt que des métriques techniques. Un système qui déclare un temps de fonctionnement de 99,9 %, mais connaît des expirations fréquentes, ne garantit pas la fiabilité basée sur l'expérience utilisateur. Les utilisateurs se soucient davantage de la réussite de leurs workflows que du temps de fonctionnement individuel de l'API.

Concevez des SLO qui reflètent les parcours utilisateur plutôt que des appels d'API individuels. Un flux Checkout à plusieurs étapes nécessite chaque étape pour réussir dans un délai acceptable. Mesurez les taux de réalisation de flux utilisateur de bout en bout en tant qu'indicateur de fiabilité principal. La disponibilité des composants est nécessaire, mais insuffisante pour la fiabilité de l'expérience utilisateur.

Salesforce Hyperforce fournit des centres de données régionaux permettant la distribution géographique. La plate-forme gère la redondance de l'infrastructure dans les régions, notamment les zones de disponibilité multiples, le basculement automatique des services internes et la réplication des données au niveau de la couche infrastructure. Les accords de niveau de service de plate-forme reflètent cette redondance de l'infrastructure.

Pour la plupart des solutions, le déploiement sur une seule zone avec une redondance gérée par la plate-forme fournit une disponibilité suffisante. Faites Trust à l'infrastructure Salesforce pour la disponibilité de base et concentrez l'architecture de solutions sur la fiabilité au niveau de la couche applicative, notamment les modèles d'intégration tolérants aux pannes, la dégradation gracieuse et la restauration automatisée.

Le basculement intra-région entre les zones de disponibilité est automatique et inclus dans les engagements de contrat de niveau de service de plate-forme standard. Salesforce gère cela de façon transparente au niveau de la couche infrastructure. La reprise après sinistre inter-régions (hors région) est une offre payante distincte et n'est incluse par défaut dans aucune édition standard. Si vos exigences de continuité des activités nécessitent un basculement inter-régions, documentez explicitement cette dépendance dans votre plan de reprise après sinistre afin de permettre aux parties prenantes de comprendre la distinction entre la résilience de la plate-forme incluse et les capacités DR inter-régions achetées.

L'architecture multi-organisations offre l'isolation et la redondance géographique les plus fortes, mais multiplie la complexité opérationnelle, notamment la synchronisation des données, le provisionnement utilisateur, la coordination du déploiement et les coûts de licence. Réservez des modèles multi-organisations pour les scénarios dans lesquels les exigences métiers justifient clairement la complexité. Prenons par exemple un schéma multi-organisations pour les scénarios suivants :

• L'entreprise nécessite un RPO/RTO garanti au-delà des capacités de la plate-forme
• Les exigences réglementaires obligent à isoler les données géographiques, la planification de la continuité des activités exige une totale indépendance par rapport à une seule région
• La consolidation de l'organisation est impossible en raison des exigences d'autonomie des unités commerciales.

Schéma actif-passif : - L'organisation principale sert tout le trafic dans des conditions normales. Les organisations secondaires de différentes régions restent synchronisées, mais inactives. Le basculement se produit pendant une panne dans la région principale. Cette solution fournit le schéma multi-organisation le plus simple, mais laisse la capacité secondaire inutilisée. L'acheminement DNS ou les couches d'authentification utilisateur dirigent les utilisateurs vers l'organisation active.

Modèle actif-actif : - Les deux organisations servent le trafic de production en continu. Les utilisateurs sont alloués par zone géographique, unité commerciale ou type de charge de travail. Actif-actif optimise l'utilisation de la capacité, mais nécessite une synchronisation des données sophistiquée et un acheminement utilisateur. La résolution des conflits est essentielle lorsque le même enregistrement est modifié dans les deux organisations.

Concevez une synchronisation des données adaptée aux exigences du RPO. Les événements de plate-forme fournissent un flux d'événements en temps quasi réel pour les modifications critiques des données. Capture des données de modification offre un suivi automatique des modifications pour les objets sélectionnés avec un développement minimal. La réplication d'API planifiée via l'API de transfert en masse 2.0 à intervalles fixes convient aux données de référence moins temporelles.

Appliquez une redondance aux couches de données, d'application et d'intégration pour éviter les points de défaillance uniques. La redondance en couches garantit qu'un échec à une couche unique ne compromet pas la disponibilité globale du système.

• Redondance des données : La plate-forme fournit une redondance des données via des sauvegardes d'infrastructure. Complétez cette redondance avec la réplication au niveau de l'application lorsque l'entreprise nécessite une récupération plus rapide que les procédures de restauration de la plate-forme. Utilisez la Capture des données de modification ou des événements de plate-forme pour répliquer en continu des données critiques dans un stockage secondaire ou dans des systèmes externes. Cela permet de récupérer la corruption logique ou les erreurs de configuration que les sauvegardes d'infrastructure ne peuvent pas résoudre.
• Redondance de l'application : Concevez une logique d'application sans état afin de permettre à n'importe quel serveur d'application de traiter n'importe quelle requête. Évitez l'état côté serveur qui empêche l'échelle horizontale. Utilisez des types de métadonnées personnalisées et des paramètres personnalisés pour la configuration, qui doivent être instantanément disponibles dans tous les serveurs d'application. La conception sans état d'état permet à un serveur d'application de traiter les requêtes sans dépendre de l'état spécifique du serveur.
• Redondance de l'intégration : Concevez des intégrations qui tolèrent la non disponibilité temporaire du système externe. Implémentez des modèles de disjoncteur détectant les échecs d'intégration. Mettez les requêtes en file d'attente via Événements de plate-forme lorsque les systèmes externes sont en panne plutôt que de bloquer les opérations des utilisateurs. Cela isole les défaillances système externes des fonctionnalités accessibles aux utilisateurs.

Surveillez l'intégrité de la plate-forme Salesforce en utilisant Trust.salesforce.com et des API de statut spécifiques à l'instance. Abonnez-vous aux notifications de statut de votre instance pour recevoir des alertes sur les incidents, les fenêtres de maintenance et les impacts sur les performances. Les signaux d'intégrité de la plate-forme activent une réponse proactive plutôt qu'un dépannage réactif.

Concevez des solutions qui répondent à l'état de santé de la plate-forme. Lorsque les performances de la plate-forme se dégradent, réduisez la charge de traitement par lot non critique. Reportez les tâches en arrière-plan pendant les périodes de maintenance en utilisant la surveillance des tâches planifiée. Désactivez les intégrations non essentielles pour protéger les opérations critiques auxquelles les utilisateurs sont confrontés en cas d'incident. Ce délestage dynamique maintient la fiabilité des capacités critiques sous tension.

Utilisez le Centre d'échelle pour identifier les transactions et les opérations de longue durée qui consomment des ressources de plate-forme disproportionnées. Le Centre d'échelle offre une visibilité au niveau des transactions, ce qui permet aux architectes de détecter les risques de fiabilité avant qu'ils ne deviennent des incidents pour les utilisateurs. L'examen hebdomadaire du Centre d'échelle révèle des modèles nécessitant une remise en état architecturale.

Implémentez la détection des pannes à plusieurs niveaux pour détecter les problèmes avant qu'ils ne tombent en panne. La détection en couches fournit une défense en profondeur contre les pannes non détectées.

Concevez des seuils d'alerte qui équilibrent la détection précoce et les faux positifs. Alertez lorsque les taux d'erreur dépassent les seuils ou lorsqu'une dégradation durable se produit, pas en cas de panne isolée. Les erreurs uniques sont normales dans les systèmes distribués. Les modèles d'erreur indiquent des problèmes de fiabilité qui nécessitent une attention particulière.

Les limites du gouverneur Salesforce limitent la consommation de ressources de chaque locataire dans la plate-forme multilocataire afin qu'aucun locataire ne puisse dégrader les performances d'autres locataires. Ce ne sont pas des restrictions arbitraires, ce sont des frontières architecturales qui façonnent la conception de solutions. Comprenez les limites du gouverneur avant de concevoir une architecture fiable. Les solutions qui approchent régulièrement les limites du gouverneur en charge normale échoueront probablement en cas de stress.

Limites critiques du gouverneur affectant les décisions architecturales :

Concevez des transactions qui respectent les limites, même en période de pointe. Élaborez une marge en ciblant 70 % des limites du gouverneur comme plafond opérationnel dans des conditions normales, en réservant 30 % aux pics inattendus. Ce tampon prend en charge les augmentations de charge temporaires, généralement sans atteindre les limitations sévères.

La mise en masse est le schéma d'évolutivité de base pour Salesforce. Traitez plusieurs enregistrements dans une seule transaction plutôt que dans des opérations d'enregistrement individuelles. La mise en masse réduit la consommation limite du gouverneur tout en augmentant le débit. Chaque architecte Salesforce doit maîtriser les modèles de traitement en masse, car ils sous-tendent toutes les solutions évolutives.

Concevez tous les déclencheurs Apex, classes par lot et intégrations pour traiter efficacement les collections d'enregistrements. Collectez d'abord les identifiants d'enregistrement, puis traitez tous les enregistrements avec des instructions à requête unique et DML. Utilisez des cartes et des ensembles pour des références efficaces plutôt que des boucles imbriquées avec des requêtes individuelles. Le traitement basé sur la collection améliore l'efficacité d'un ordre de grandeur par rapport aux approches enregistrement par enregistrement.

L'automatisation déclenchée par un enregistrement doit gérer 200 enregistrements par invocation de déclencheur, car la plate-forme traite l'exécution de déclencheur par lots allant jusqu'à 200 enregistrements. Les opérations Lightning Data Service sont automatiquement exécutées par lot, mais les composants personnalisés doivent implémenter explicitement des schémas en masse lors de l'exécution d'opérations DML.

Le traitement asynchrone distribue le travail dans le temps au lieu de tenter une réalisation immédiate dans les limites du gouverneur d'une seule transaction. Utilisez des modèles asynchrones lorsque les opérations traitent des volumes de données importants dépassant les limites du gouverneur synchrone, dépendent de systèmes externes avec des temps de réponse variables, peuvent tolérer un retard de réalisation ou nécessitent un temps d'exécution prolongé au-delà des limites CPU synchrones.

Les capacités asynchrones de Salesforce et leur adéquation architecturale :

• Apex lot : Traitez les volumes importants d'enregistrements par segments allant jusqu'à 2000 enregistrements par méthode d'exécution. Le lot fournit des limites du gouverneur dédiées par segment et une isolation contre les échecs - un segment échoué n'empêche pas les autres segments de se terminer. Cela permet une réussite partielle et une nouvelle tentative ciblée. Implémentez une logique de nouvelle tentative personnalisée pour les échecs transitoires en suivant les plages de segments échoués dans l'objet AsyncApexJob et en mettant en file d'attente les tâches par lot ciblées. Utilisez le traitement par lot pour les migrations de données, les mises à jour en masse planifiées et le traitement des données à grande échelle. Cinq tâches par lot maximum sont exécutées simultanément ou en attente d'exécution par organisation. Les tâches supplémentaires sont placées en file d'attente dans la file d'attente Flex Apex (jusqu'à 100 tâches sous le statut En attente) et exécutées automatiquement lorsque les créneaux sont ouverts.
• Apex Queueable : Exécutez des tâches asynchrones avec la capacité d'enchaînement pour activer des workflows à plusieurs étapes et des paramètres d'objet complexes. Apex Queueable partage la limite DailyAsyncApexExecutions de l'organisation de 250 000 exécutions par 24 heures avec tous les autres Apex asynchrones (Apex par lot, futur et planifié), au lieu de détenir une allocation spécifique à Queueable dédiée. Utilisez Apex Queuable pour des workflows d'orchestration et d'intégration à plusieurs étapes nécessitant un traitement séquentiel avec une meilleure surveillance que les méthodes @future.
• Événements de plate-forme : Les événements de plate-forme sont utilisés dans une architecture d'événements publier-s'abonner qui dissocie les éditeurs des abonnés. Les événements sont relus à partir d'une période de rétention de 72 heures (3 jours). La rétention prolongée au-delà de 72 heures est disponible en tant que complément payant. Vérifiez les limites maximales actuelles et le statut GA dans la dernière documentation Événements de plate-forme Salesforce avant de vous engager à respecter les obligations de contrat de niveau de service qui dépendent d'une lecture prolongée. Utilisez les événements de plate-forme pour l'automatisation pilotée par l'événement, l'intégration inter-systèmes et la diffusion de données en temps réel. Les événements de plate-forme fournissent des frontières asynchrones naturelles entre les phases de transaction.
• Apex planifié : Exécutez des tâches à une fréquence fixe en utilisant des expressions CRON via System.schedule(). L'exécution d'une tâche peut être planifiée au maximum une fois par heure. Les champs CRON seconds et minutes doivent utiliser des valeurs fixes, pas des plages. Restez dans les 100 tâches Apex planifiées maximum par organisation en regroupant les opérations similaires dans des classes uniques Planifiables.

Lorsque les volumes de données dépassent les limites de traitement pratiques, même avec des modèles de traitement en masse et asynchrones, partitionnez les données à travers des frontières logiques pour activer le traitement parallèle. Le partitionnement des données convertit les opérations séquentielles volumineuses en opérations parallèles plus petites qui se terminent plus rapidement et respectent les limites du gouverneur.

• Partitionnement basé sur la date : Traitez les données dans des périodes comprenant les transactions de ce mois ou les requêtes du trimestre précédent. Archivez les données historiques dans des Big Objects ou un stockage externe pour garder l'ensemble de travail gérable. La plupart des requêtes transactionnelles se concentrent sur des données récentes, ce qui rend le partitionnement temporel naturellement efficace.
• Partitionnement du type d'enregistrement : Traitez indépendamment différents types d'enregistrement, y compris les requêtes Partenaires par rapport aux requêtes Clients ou les comptes Entreprise par rapport aux comptes PME. Les tâches par lot séparées par type activent la parallélisation. Le type d'enregistrement est souvent corrélé à des processus métiers distincts justifiant un traitement indépendant.
• Partitionnement basé sur le propriétaire : Distribuez le traitement par propriétaire d'enregistrement, par exemple en traitant indépendamment les opportunités de chaque région commerciale. Le partitionnement basé sur le propriétaire est particulièrement efficace lorsqu'il est combiné à un modèle de partage, car la sécurité est appliquée via les mécanismes existants. Le partitionnement basé sur le propriétaire active la distribution géographique de la charge de traitement.

Prévoyez les besoins futurs en capacité en fonction de la croissance de l'entreprise plutôt que de réagir pour limiter l'épuisement. La planification proactive des capacités évite les incidents de fiabilité dus à l'épuisement des ressources de la plate-forme.

• Licences utilisateur - croissance des effectifs entraînant l'allocation d'appels d'API et les autorisations de stockage par utilisateur
• Stockage des données - volumes de transactions et politiques de rétention qui favorisent la consommation de stockage (prévoyez normalement une croissance annuelle minimale de 10 à 20 %)
• Appels d'API - le nombre d'intégrations et la fréquence déterminent l'allocation d'API sur 24 heures (chaque nouveau modèle d'intégration ajoute une consommation récurrente)
• Capacité de traitement - Nombre de tâches par lot et complexité entraînant des files d'attente de traitement asynchrones et des limitations en exécutions simultanées

Utilisez Proactive Monitoring pour évaluer en permanence l'utilisation des capacités de l'organisation. Proactive Monitoring expose les risques de capacité, notamment l'utilisation d'API proche des pics de limite de requêtes, les limites de stockage proches et la profondeur de la file d'attente des tâches par lot qui augmente au-delà des niveaux durables. L'examen hebdomadaire des capacités permet d'obtenir des délais pour des licences ou des limitations supplémentaires avant que l'impact métier ne se produise.

Validez les hypothèses d'évolutivité en testant la charge avant le déploiement en production. Les tests de charge révèlent des problèmes de limitation du gouverneur, des blocages d'intégration et des contraintes de capacité invisibles dans les tests de développement à faible volume. Testez avec des volumes de données à l'échelle de la production et la simultanéité pour valider la fiabilité dans des conditions réalistes.

• Test du volume de données : Remplissez les volumes de données à l'échelle de la production dans une organisation sandbox Full Copy pour valider les performances des requêtes avec un asymétrie des données réelles, la profondeur des relations et le nombre d'enregistrements. Testez avec plus de 10 millions d'enregistrements lorsque la production atteindra cette échelle. Le comportement de l'optimiseur de requête change radicalement à mesure que le volume de données augmente, ce qui peut entraîner des résultats de Test de l'évolutivité trompeurs.
• Tests utilisateur simultanés : Simulez les pics de charge d'utilisateurs simultanés pour valider le débit et le contentieux des transactions. Utilisez les tests à l'échelle disponibles pour les organisations qualifiantes afin de simuler les charges de travail de production dans des environnements sandbox avant le déploiement. L'exécution simultanée révèle des problèmes de verrouillage invisibles dans les tests mono-utilisateur.
• Test de charge d'API : Générez des volumes d'API de pointe pour valider l'évolutivité de l'intégration, la gestion des limites en taux et le comportement du disjoncteur en charge soutenue. Les tests de charge d'API révèlent si la logique de nouvel essai et le traitement des erreurs fonctionnent correctement dans des conditions de stress.
• Test de l'évolutivité : Test de l'évolutivité est un produit Salesforce utilisé pour simuler les charges de travail de production par rapport aux environnements sandbox Full Copy adaptés à la capacité de production. Test de l'évolutivité exécuté sur des sandbox Full Copy dans Hyperforce Votre instance de production n'a pas besoin d'être sur Hyperforce pour l'utiliser. Vous créez des plans de test dans votre organisation de production, pendant que les tests sont exécutés sur l'organisation sandbox. Utilisez le Test de l'évolutivité pour valider le comportement de réponse du gouverneur en cas de charge maximale, de débit de traitement asynchrone et d'intégration avant les déploiements majeurs.

Une dégradation gracieuse maintient la fonctionnalité principale lorsque les composants non critiques échouent. Concevez des systèmes priorisant les flux utilisateur critiques sur les fonctionnalités de support en cas d'échec. Les capacités n'ont pas toutes la même importance métier et les architectures devraient refléter ces priorités.

Définissez la hiérarchie de criticité des fonctionnalités :

Cette hiérarchie permet aux architectes de concevoir des stratégies de dégradation qui maintiennent la continuité de l'activité même en cas de défaillance partielle du système. Les utilisateurs préfèrent une fonctionnalité réduite à une indisponibilité totale.

Le modèle de disjoncteur évite les pannes en cascade lorsque les intégrations ne sont plus disponibles. Au lieu d'accumuler les expirations qui consomment du temps de transaction et des limites du gouverneur, détectez les modèles d'échec et arrêtez d'appeler les systèmes défaillants. Les disjoncteurs fournissent une panne rapide plutôt qu'une panne lente.

Le disjoncteur indique :

• Fermé - fonctionnement normal, les requêtes sont transmises au système externe tel que conçu
• Ouvert - seuil d'échec dépassé, les requêtes échouent immédiatement sans tenter d'appels externes, ce qui économise les ressources
• Période de test à moitié ouverte - récupération, des requêtes limitées sondent les systèmes externes pour détecter la récupération avant la fermeture complète du circuit

Implémentez des disjoncteurs en utilisant Cache de la plate-forme pour stocker l'état du circuit accessible dans toutes les transactions. Utilisez Événements de plate-forme pour diffuser les changements d'état dans l'organisation. La logique du disjoncteur vérifie l'état avant de tenter des appels externes, ce qui évite de gaspiller les limites en appels externes dans les systèmes connus défaillants.

Les échecs temporaires sont normaux dans les systèmes distribués. Les interruptions de réseau, l'indisponibilité temporaire du service et les réponses aux limitations de taux sont souvent résolues en quelques secondes. Implémentez une nouvelle logique qui répète les opérations échouées après des délais progressifs plutôt que d'échouer immédiatement.

Le recul exponentiel empêche les tempêtes qui submergent les systèmes de récupération. Une première tentative peut être effectuée après 1 seconde, une deuxième après 2 secondes, une troisième après 4 secondes et une quatrième après 8 secondes. Limitez le délai maximal à 30 à 60 secondes, quelle que soit la croissance exponentielle. Ce schéma de recul permet aux systèmes défaillants de récupérer tout en limitant la durée totale des nouvelles tentatives.

Mappez la stratégie de nouvelle tentative avec le type d'échec.

• Expirations réseau : Réessayez avec un backoff court (l'opération peut ne pas avoir atteint le serveur)
• Erreurs de limite de taux (429): Réessayer après la valeur d'en-tête Réessayer après ou après l'heure de réinitialisation de la limite de taux
• Erreurs de serveur (5xx) : Réessayez avec un backoff exponentiel, car le serveur peut être temporairement surchargé
• Erreurs client (4xx sauf 429) : Ne réessayez pas, corrigez la requête car une erreur indique une entrée non valide
• Erreurs de limitation du gouverneur : Ne réessayez pas dans la même transaction, refaites la file d'attente en tant qu'opération asynchrone avec des limites dédiées, par exemple en publiant un événement d'échec qu'un abonné asynchrone retraite avec backoff sous de nouvelles limites de transaction

Les stratégies de repli définissent d'autres approches lorsque les méthodes primaires échouent, ce qui permet de continuer à fonctionner dans des conditions dégradées.

• Source de données alternative : Récupérez les données de la session de cache de la plate-forme ou d'une partition d'organisation lorsque l'API en temps réel n'est pas disponible. Préremplissez le cache pendant les opérations réussies. Le cache fournit des données périmées mais disponibles, ce qui est préférable à un échec complet pour de nombreux cas d'utilisation.
• Comportement par défaut : Appliquez des règles métiers standard lorsqu'un service de personnalisation ou d'enrichissement n'est pas disponible. Traiter avec des valeurs par défaut et marquer l'enrichissement lors de la récupération du service. Le comportement par défaut maintient le débit au prix d'une précision réduite.
• Processus manuel : Activez la réalisation manuelle des opérations lorsque l'automatisation échoue. Offrez une interface d'administration pour réaliser les transactions bloquées. Le repli manuel empêche la perte de données et maintient la continuité de l'activité lorsque l'automatisation est altérée.
• File d'attente pour réessayer : Stockez les opérations dans des événements de plate-forme ou des objets de file d'attente personnalisés pour les traiter lors de la récupération d'un système externe. La relecture d'événements de plate-forme avec une rétention standard de 72 heures permet de récupérer les abonnés après des échecs temporaires, sans perte de données.

Configurez des expirations appropriées pour tous les appels externes d'intégration. Salesforce applique un délai total d'appel externe maximal de 120 secondes par transaction. Prévoyez ce temps entre tous les appels externes dans une seule transaction afin d'éviter d'épuiser le temps de transaction sur les connexions suspendues.

Considérations relatives à la conception d'expiration :

• Appels externes synchrones accessibles aux utilisateurs : Utilisez 5 à 10 secondes maximum pour maintenir une interface utilisateur réactive, car les utilisateurs ont tendance à ne pas attendre plus longtemps
• Appels externes asynchrones en arrière-plan : Utilisez 30 à 60 secondes pour ajuster les performances externes variables sans attendre l'utilisateur
• Traitement par lot des appels externes : Utilisez les 120 secondes complètes autorisées lorsqu'aucun utilisateur n'attend une réponse
• Appels externes multiples par transaction : Budgetez le temps total entre tous les appels externes, par exemple trois appels externes à 10 secondes chacun consommant 30 secondes de votre budget de 120 secondes.

Les expirations plus courtes échouent plus rapidement, ce qui permet aux stratégies de repli de s'engager plus tôt. Des expirations plus longues augmentent le taux de réussite des systèmes externes lents mais fonctionnels. Les considérations d'équilibre sont basées sur l'attente ou non d'une réponse par l'utilisateur et la disponibilité de stratégies de repli.

Concevez un traitement complet des erreurs pour transformer les échecs des pannes en dégradations gérées :

• Échec rapide : Validez les entrées et les conditions préalables aux points d'entrée. Vérifiez la consommation limite du gouverneur avant les opérations onéreuses. Détectez immédiatement les échecs au lieu de propager l'état non valide à travers plusieurs couches de traitement. La détection précoce réduit le rayon d'explosion et simplifie le débogage.
• Échouez gracieusement : Maintenez les capacités des utilisateurs même lorsque les opérations échouent partiellement. Si 3 des 200 enregistrements du lot échouent à la validation, traitez les 197 enregistrements réussis et signalez les 3 échecs au lieu d'échouer dans le lot complet. Une réussite partielle vaut mieux qu'un échec total pour des opérations par lot.
• Échouer à titre informatif : Consignez les erreurs avec l'ID de transaction, le contexte utilisateur, les paramètres d'entrée et la trace de pile. Un contexte d'erreur insuffisant est le principal obstacle à la résolution rapide des incidents. Chaque journal d'erreur doit permettre à l'intervenant de comprendre ce qui a échoué, pourquoi et comment se reproduire.
• Échouez en toute sécurité : Assurez-vous que les échecs ne compromettent pas l'intégrité ou la sécurité des données. Annulez les transactions partielles au lieu de laisser les données dans un état incohérent. N'exposez jamais les détails des erreurs internes aux utilisateurs, car les traces de pile révèlent des détails d'implémentation utiles aux assaillants.

L'objectif du temps de reprise définit le temps d'arrêt maximal acceptable après un sinistre. RTO pilote les décisions architecturales relatives à l'automatisation du basculement, à la fréquence de sauvegarde et à l'investissement dans les tests de restauration. Différentes capacités métiers justifient différents investissements RTO. Le RTO est le temps d'arrêt que vos utilisateurs subissent directement. Par conséquent, un objectif manqué se traduit par des pannes prolongées et une érosion de la Trust client.

RTO varie selon la capacité commerciale :

Définissez RTO par capacité avant de concevoir une architecture de reprise après sinistre. RTO façonne la sélection de technologies, l'investissement en automatisation et la cadence de test. Les objectifs RTO plus agressifs nécessitent un investissement plus important dans l'automatisation et la redondance.

L'objectif du point de récupération définit la période de perte de données maximale acceptable mesurée dans le temps. RPO détermine la fréquence de sauvegarde, la stratégie de réplication et les modèles de synchronisation. Une RPO plus stricte nécessite une réplication des données plus fréquente, une complexité et un coût accrus. Le RPO est la perte de données que votre entreprise absorbe. Par conséquent, un objectif manqué peut entraîner la perte de transactions et des écarts irrécupérables dans vos enregistrements.

Équilibrez les exigences des ORP avec le coût et la complexité. Le RPO quasi nul nécessite une réplication continue des données avec un investissement important en infrastructure. La sauvegarde quotidienne fournit un RPO sur 24 heures avec une complexité minimale. La plupart des organisations peuvent tolérer certaines pertes de données non financières.

La redondance de l'infrastructure de la plate-forme protège contre les défaillances de l'infrastructure, mais elle réplique les résultats d'erreurs utilisateur, de déploiements défectueux et de défauts d'intégration, qui entraînent la plupart des pertes de données. Des sauvegardes existent pour récupérer ces échecs de couche applicative, pas pour compenser la fiabilité de la plate-forme. Implémentez des stratégies de sauvegarde couvrant les données, les métadonnées et les fichiers, car chacune nécessite des approches de sauvegarde différentes :

• Sauvegardes de données : Mettez en œuvre une stratégie de sauvegarde complète traitant à la fois des données et des métadonnées. Exportez des données d'objets critiques en utilisant le service natif d'exportation de données : tous les 7 jours pour les éditions Enterprise, Performance et Unlimited ; tous les 29 jours pour les éditions Professional et inférieures. Les fichiers d'exportation sont disponibles pendant 48 heures après l'envoi de l'e-mail de notification, week-ends exclus, avant la suppression automatique. Configurez un processus de téléchargement automatisé afin d'éviter la perte définitive de fichiers. Utilisez l'API de métadonnées et Salesforce CLI (sf project retrieve) pour contrôler la configuration de l'organisation, le code personnalisé et l'automatisation déclarative dans un système de contrôle de code source tel que Git. Traitez la sauvegarde des métadonnées dans le cadre de votre pipeline CI/CD standard. Complétez la sauvegarde des données avec des services de sauvegarde et de restauration dédiés tels que Own pour la restauration ponctuelle, la récupération au niveau de l'enregistrement granulaire et la rétention au-delà de la cadence d'exportation native. L'exportation de données natives ne prend pas en charge la restauration ponctuelle, et un outillage tiers est requis si votre RTO/RPO exige des fenêtres de récupération précises. Testez régulièrement les procédures de restauration. Une sauvegarde qui n'a jamais été restaurée est une hypothèse non testée.
• Sauvegardes de métadonnées : Contrôlez toutes les métadonnées en utilisant le format source Salesforce DX dans les référentiels Git. Le contrôle de version des métadonnées active la restauration rapide de la configuration après corruption ou modifications involontaires. Chaque déploiement doit être reproductible à partir du contrôle du code source. Les métadonnées dans Git fournissent une récupération ponctuelle pour la configuration.
• Sauvegardes de fichiers : Exportez des enregistrements ContentVersion, des pièces jointes et des documents vers un stockage externe. Salesforce fonctionne mieux pour les données actives, pas pour l'archivage de fichiers à long terme - exportez des fichiers vers un stockage externe pour la rétention réglementaire. Implémentez l'exportation automatisée de fichiers pour les exigences réglementaires de rétention qui dépassent les capacités de la plate-forme.
• Validation : Restaurez périodiquement des sauvegardes dans des organisations tests ou des organisations sandbox Developer afin de valider les procédures et l'intégrité des sauvegardes. Les sauvegardes non testées échouent souvent lorsque nécessaire en raison d'une étendue de sauvegarde incomplète ou d'archives corrompues. Planifiez une validation de restauration trimestrielle pour détecter les problèmes avant les catastrophes. Surveillez la fraîcheur de sauvegarde en plus de restaurer la validation. Alertez lorsque la dernière sauvegarde réussie est plus ancienne que sa cadence attendue, par exemple lorsqu'une exportation hebdomadaire n'est pas terminée depuis plus de 8 jours. Avec cette validation, une tâche de sauvegarde échouée en silence est immédiatement exposée plutôt qu'au prochain exercice.

Concevoir une réplication adaptée aux exigences des organisations RPO et multi-organisations :

• Capture des données modifiées (CDC) : Abonnez-vous aux événements de modification des objets suivis. Le CDC fournit des événements Créer, Mettre à jour, Supprimer et Annuler la suppression avec des valeurs de champ modifiées. Fournit une réplication en temps quasi réel avec un effort de développement minimal pour les objets pris en charge, y compris standard et personnalisé. Sous réserve de l'allocation de livraison quotidienne basée sur l'édition.
• Événements de plate-forme : Architecture d'événements personnalisée pour répliquer des événements métiers et des changements d'état. Plus flexible que CDC prenant en charge des charges de travail personnalisées et des structures d'événements complexes, mais nécessite une logique de publication explicite dans les déclencheurs ou les processus. La fenêtre de relecture standard de 72 heures permet de récupérer les échecs temporaires des abonnés.
• Réplication d'API planifiée : La réplication de l'API Schedule est une extraction par lot via l'API de transfert en masse 2.0 selon une planification fixe. C'est l'implémentation la plus simple avec un RPO égal à la fréquence d'extraction. La réplication d'API planifiée convient aux données non critiques dans lesquelles l'exécution en temps quasi réel n'est pas nécessaire, par exemple avec des données de référence ou des analytiques historiques.
• Réplication orchestrée par MuleSoft : Pour des topologies de réplication multisystème complexes, MuleSoft Anypoint Platform fournit l'orchestration, la transformation et la surveillance. Son utilisation est appropriée pour la réplication à travers Salesforce et plusieurs systèmes externes, ce qui nécessite une logique d'acheminement et de transformation sophistiquée.

Testez la reprise après sinistre avec des exercices planifiés qui valident ensemble les personnes, les processus et la technologie :

• Exercices sur table : L'équipe parcourt les scénarios catastrophes, discutant des rôles et des points de décision sans basculement réel. Cette activité est peu coûteuse et révèle des lacunes procédurales et des ruptures de communication. Organisez régulièrement des exercices sur table pour maintenir la préparation de l'équipe à mesure que le personnel change.
• Basculement partiel : - Testez des procédures de récupération spécifiques telles que la restauration des métadonnées à partir du contrôle source, la restauration des données à partir du service de sauvegarde ou l'actualisation de sandbox. Cela valide des procédures techniques avec un impact métier limité. Effectuez régulièrement des rotations entre les procédures testées pour couvrir toutes les capacités de récupération annuellement.
• Exercice de basculement complet : Le basculement complet est le basculement complet vers l'environnement de reprise après sinistre avec la coupure du trafic de production. Il offre la plus grande confiance, mais nécessite une coordination métier et une communication avec les utilisateurs. Effectuez cet exercice annuellement pour les systèmes critiques. L'exercice de basculement complet valide toute la capacité de récupération, y compris les procédures de basculement et la communication des utilisateurs.

Documentez les leçons apprises après chaque exercice. Mettez à jour les runbooks en fonction des résultats. Les capacités de récupération peuvent se dégrader à mesure que les équipes changent et que les solutions évoluent. Traitez la documentation DR comme des artefacts vivants qui nécessitent un entretien régulier plutôt que comme des livrables uniques.

La continuité des activités va au-delà de la reprise technique pour englober les personnes, les processus et les dépendances des fournisseurs :

• Disponibilité de l'équipe : Documentez les procédures d'escalade et le personnel de secours pour les rôles critiques. Assurez-vous qu'aucun point d'échec unique n'existe dans Knowledge opérationnelle. Les intervenants principaux peuvent ne pas être disponibles en cas de sinistre, ce qui rend la dotation en renfort critique.
• Procédures de communication : Définissez comment les incidents sont communiqués aux utilisateurs, aux clients et aux dirigeants. Établissez des canaux de communication qui fonctionnent lorsque les outils principaux (par exemple, les pages de statut externes ou les systèmes de notification par SMS), y compris Salesforce lui-même, ne sont pas disponibles.
• Dépendances du fournisseur : Mappez les dépendances de fournisseurs externes critiques pour le fonctionnement de la solution. Documentez les parcours d'escalade et les accords de niveau de service contractuels de chaque fournisseur critique, y compris Salesforce, les partenaires d'intégration et les fournisseurs de packages ISV. Comprenez, par exemple, quels fournisseurs fournissent un support 24/7 et lesquels offrent un support uniquement pendant les heures ouvrables qui affecte le temps de recouvrement.
• Obligations réglementaires : Identifiez les exigences de notification déclenchées par des pannes prolongées. Les services financiers, les soins de santé et les marchés publics exigent souvent la notification des incidents dans des délais spécifiques. La non-conformité peut entraîner des risques réglementaires et juridiques, qui aggravent l'impact des catastrophes.

Définissez un modèle de santé qui agrège plusieurs signaux dans l'état de santé général du système. Les modèles de santé exposent l'état opérationnel en un coup d'œil, sans nécessiter l'analyse de métriques détaillées. Par exemple :

Concevez des tableaux de bord d'intégrité qui affichent immédiatement le statut opérationnel. L'état de santé guide l'intervention opérationnelle, notamment les opérations normales sous statut vert, la surveillance renforcée sous statut jaune et la réponse active aux incidents sous statut rouge.

Les signaux de statut de la plate-forme (déjà traités sous Surveillance de l'intégrité de la plate-forme) indiquent quand l'infrastructure Salesforce est dégradée, mais pas les performances de votre propre solution.

Augmentez ces signaux avec une observabilité spécifique à la solution :

• Surveillance des événements : Event Monitoring inclut des journaux détaillés qui capturent les appels d'API, les vues de page, les exportations de rapports, l'activité de connexion et l'exécution Apex. Les objets EventLogFile livrent des journaux avec une fréquence de 24 heures (quotidienne) ou d'une heure - la livraison horaire nécessite le complément Event Monitoring ou Salesforce Shield. La rétention est configurable jusqu'à 365 jours via la Configuration, mais une rétention prolongée nécessite Salesforce Shield ou le complément Event Monitoring Sans complément, les fichiers journaux sont conservés pendant 1 jour. Acheminez les événements vers un système SIEM (Security Information and Event Management) externe ou vers une plate-forme d'agrégation de journaux pour la corrélation, les alertes et la rétention au-delà des limites natives. Utilisez la Surveillance des événements pour détecter les modèles de consommation d'API anormaux, identifier les processus Apex galopants et auditer l'accès aux données dans des environnements réglementés.
• Centre d'échelle : Le Centre d'échelle fournit une visibilité au niveau des transactions sur les opérations à long terme, les litiges de verrouillage de ligne et les transactions exigeantes en ressources. Le Centre d'échelle permet aux architectes d'identifier les risques de fiabilité liés à des modèles de transaction spécifiques avant qu'ils ne provoquent des incidents pour les utilisateurs. Les examens hebdomadaires peuvent révéler des opportunités d'optimisation.
• Proactive Monitoring: Proactive Monitoring permet d'évaluer en permanence l'intégrité de l'organisation, les performances de surface et les risques d'évolutivité. Proactive Monitoring fournit des alertes sur les pics de limite en requêtes d'API, les échecs d'exécution Apex simultanés, les problèmes de limite en lignes SOQL et les tendances de consommation de stockage. Elle est disponible pour les clients qui disposent d'une autorisation Signature Success (auparavant appelée Support Signature). Elle n'est pas une fonctionnalité en libre-service incluse avec les éditions standard.

Surveillez les performances des applications du point de vue des utilisateurs plutôt que du point de vue de l'infrastructure :

• Surveillance des utilisateurs réels (RUM) : Mesurez l'expérience utilisateur réelle à l'aide d'analytiques Experience Cloud ou d'instrumentations personnalisées. RUM capture la latence réelle, qui reflète les conditions réelles du réseau, les performances de l'appareil et la distribution géographique. La surveillance synthétique ne peut pas reproduire cette variabilité.
• Surveillance synthétique : Exécutez périodiquement des transactions automatisées à partir de plusieurs emplacements pour valider la disponibilité et les performances. La surveillance synthétique détecte les problèmes avant que les utilisateurs ne les signalent. Implémentez une surveillance synthétique en utilisant Apex planifié, en exécutant des opérations critiques et en générant des rapports sur les résultats avec les Événements de plate-forme.
• Traçage des transactions : Instrumentez des opérations complexes à plusieurs étapes pour capturer le temps par étape. Identifiez ensuite l'étape du workflow en cinq étapes qui introduit la latence. Ne traitez pas le flux complet comme une boîte noire. La synchronisation au niveau de l'étape révèle des opportunités d'optimisation invisibles dans les métriques agrégées.

Surveillez toutes les intégrations externes en utilisant des taux d'erreur, des percentiles de latence et un débit. Les échecs d'intégration sont l'une des principales causes d'incidents de fiabilité :

• Taux d'erreur - Le pourcentage d'erreurs de renvoi d'appels (cible : <1 % pour une intégration saine)
• Latence - Le temps de réponse mesuré à p50, p95, p99 (définir SLO par intégration basé sur le budget d'expiration)
• Taux d'expiration : pourcentage de dépassement de l'expiration configurée (cible : <0,1 %)
• État du disjoncteur - État ouvert indiquant une panne durable nécessitant une attention immédiate
• Profondeur de file d'attente - Pour les intégrations asynchrones, l'augmentation de la file d'attente indique un retard de traitement par rapport au taux de production

Consignez tous les appels d'intégration avec l'ID de requête, le point de terminaison, le code de réponse et la durée. Ces données permettent une analyse rapide des causes premières lorsque les échecs d'intégration affectent la fiabilité. Les journaux d'intégration doivent permettre l'agrégation et l'analyse des tendances.

Concevez des alertes sur les problèmes avant que les utilisateurs ne soient impactés, en activant des réponses proactives :

• Alertes actionnables : Chaque alerte a une action de réponse définie et un répondeur attribué. Les alertes sans réponse claire créent de la fatigue et masquent les signaux critiques. La conception de l'alerte doit indiquer qui répond, ce qu'il vérifie et comment il y remédier.
• Urgence appropriée : Bipez le personnel d'astreinte pour les échecs impactant les utilisateurs. Envoyez un e-mail pour dégradation des performances. Insérez les problèmes dans un résumé quotidien pour capturer les tendances. Une urgence inadaptée entraîne soit une fatigue alertée due à une surescalade, soit des incidents manqués dus à une sous-escalade.
• Notifications riches en contexte : Incluez le seuil franchi, la valeur actuelle, les tendances récentes et un lien vers un tableau de bord ou un runbook approprié. Permettez aux intervenants de commencer immédiatement le diagnostic sans recueillir le contexte. Chaque alerte doit inclure suffisamment d'informations pour pouvoir trier sans requête supplémentaire.
• Suppression de la tempête : Lorsque plusieurs systèmes échouent simultanément, supprimez les alertes redondantes. Une alerte indiquant une défaillance de la plate-forme d'intégration est plus actionnable que 50 alertes d'échec d'intégration individuelles qui masquent la cause première.

La détection des anomalies identifie des modèles inhabituels et peut indiquer des problèmes émergents invisibles pour les alertes de seuil statiques :

• Anomalies de volume: Les volumes de transactions nettement supérieurs ou inférieurs aux modèles quotidiens attendus peuvent indiquer un emballement des processus ou des problèmes d'accès des utilisateurs.
• Anomalies de taux d'erreur: Les taux d'erreur élevés par rapport aux valeurs de référence de la même période de la semaine dernière attrapent une dégradation progressive avant qu'un dépassement de seuil se produise.
• Anomalies de latence: Les temps de réponse s'écartant vers le haut sur plusieurs jours indiquent une saturation de la capacité ou une régression des performances.
• Anomalies comportementales: Des modèles de connexion inhabituels, des pics d'utilisation d'API inattendus et des tâches par lot exécutées hors des fenêtres planifiées peuvent indiquer une utilisation suspecte.

Pour les clients qui disposent de l'autorisation Signature Success, Proactive Monitoring fournit une détection des anomalies au niveau de la plate-forme sans configuration supplémentaire. Complétez-le avec la détection des anomalies spécifiques à l'application pour les SLI personnalisés exportés vers des plates-formes d'analyse externes. Utilisez des signaux d'anomalie pour guider l'enquête plutôt que de déclencher une escalade immédiate, car la détection d'anomalies présente des taux de faux positifs plus élevés que les alertes de seuil.

Utilisez cette liste de contrôle lors des examens d'architecture, avant le déploiement en production et périodiquement pour une évaluation continue de la fiabilité.

Objectifs de fiabilité et SLO

• Définir des SLO pour tous les flux utilisateur critiques avant le début de la conception
• Établir des SLI mesurables liés à l'expérience utilisateur, pas seulement aux métriques d'infrastructure
• Définir des objectifs de disponibilité réalistes basés sur une analyse d'impact métier, pas sur des objectifs arbitraires
• Garantir que les SLO de solution sont moins stricts que les SLA de plate-forme pour fournir un budget d'erreur
• Objectifs de disponibilité des documents et justification dans les enregistrements de décision d'architecture

Architecture haute disponibilité

• Redondance de conception au niveau des couches données, application et intégration
• Surveiller l'intégrité de la plate-forme via Trust.salesforce.com et l'API Statut de l'instance
• Implémenter des contrôles d'intégrité de l'application indépendamment du statut de la plate-forme
• Prendre en compte l'architecture multi-organisations uniquement lorsque les exigences métiers justifient clairement la complexité
• Concevoir un basculement automatisé avec des runbooks testés pour des modèles multi-organisations

Évolutivité et planification des capacités

• Concevoir des transactions réalisées dans les limites de 70 % du gouverneur en charge normale
• Implémenter des modèles de traitement en masse dans tous les déclencheurs Apex, classes par lot et intégrations
• Utiliser le traitement asynchrone pour les opérations qui dépassent les limites synchrones
• Toutes les intégrations d'API par lot au lieu de passer des appels d'enregistrement individuels
• Effectuer des tests de charge avec des volumes de données à l'échelle de la production avant le déploiement
• Surveiller l'utilisation des capacités via l'API OrgLimits ou Apex personnalisé et alerter lorsque la consommation approche du plafond opérationnel de 70%
• Exigences en capacité de projet basées sur les prévisions de croissance sur 12 mois
• Partitionner les données à haut volume par date, type d'enregistrement ou propriétaire pour activer le traitement parallèle lorsque les volumes dépassent les limites séquentielles

Tolérance aux pannes et résilience

• Concevoir une dégradation gracieuse avec des niveaux de criticité de fonctionnalité définis
• Implémenter des disjoncteurs pour toutes les intégrations système externes
• Appliquer une nouvelle logique avec un recul exponentiel pour les échecs transitoires
• Configurer des expirations adaptées au type d'opération (5 à 10 s pour l'utilisateur, 30 à 60 s asynchrone)
• Concevoir des stratégies de repli en utilisant Cache de la plate-forme et des modèles basés sur la file d'attente
• Implémenter un traitement structuré des erreurs avec un contexte de diagnostic suffisant

Reprise après sinistre et continuité des activités

• Définir RTO et RPO par capacité métier avant la conception
• Implémenter une sauvegarde automatisée pour les données, les métadonnées (contrôle source) et les fichiers
• Valider les procédures de restauration de sauvegarde tous les trimestres dans des environnements non-production
• Surveiller la fraîcheur de la sauvegarde et alerter lorsqu'une sauvegarde planifiée est en retard
• Concevoir une stratégie de réplication des données correspondant aux exigences RPO
• Effectuer des tests de reprise après sinistre chaque année (tableau trimestriel)
• Documenter les procédures de continuité des affaires, y compris les parcours d’escalade des fournisseurs

Surveillance et observation

• Définir un modèle de santé agrégeant les signaux de service, d'intégration, de données et de capacité
• Abonnez-vous aux notifications de statut de plate-forme pour votre instance Salesforce
• Implémenter une véritable surveillance des utilisateurs pour les flux Experience Cloud critiques
• Surveillance de l'intégrité de l'intégration avec le taux d'erreur, la latence et l'état du disjoncteur
• Concevoir des alertes actionnables avec des procédures de réponse et une appropriation définies
• Acheminement des données de Surveillance des événements vers des plates-formes externes pour la rétention et l'analyse à long terme
• Utiliser Proactive Monitoring and Scale Center pour une évaluation continue des risques de fiabilité
• Appliquer la détection des anomalies pour les modèles de volume, de taux d'erreur et de latence afin de détecter les dégradations que les seuils statiques ne respectent pas

Partagez vos commentaires sur l'infrastructure bien archivée.