Découvrez ici nos planifications de mise à jour.

Les solutions résilientes maintiennent une qualité de service élevée même en cas de défaillance. Si les performances se dégradent ou si le service est interrompu, la solution se rétablit rapidement et efficacement.

La résilience d’une solution repose sur deux qualités clés :

• Dureté: Lorsque des problèmes surviennent, la solution les supporte et les endure.
• Élasticité: Une fois les problèmes résolus, la solution retrouve son état ou sa forme idéal.

Pour concevoir votre solution de résilience, vous devez concevoir à la fois pour la ténacité et l'élasticité, en assurant à la fois la durabilité et la récupération rapide face aux changements planifiés et imprévus.

Dans un contexte technologique, considérez un système ou une solution comme un ensemble de composants interdépendants qui se coordonnent pour atteindre des objectifs communs. Chaque composant peut échouer. Les problèmes au sein de ces composants, depuis les défauts de code et de configuration jusqu'aux problèmes réseau et matériel, peuvent entraîner un comportement inattendu et indésirable. Un système montre un comportement résilient lorsqu'un ou plusieurs composants tombent en panne, mais le système global continue de fonctionner ou revient rapidement à un état stable.

Pour améliorer la résilience de vos solutions Salesforce, nous recommandons de vous concentrer sur trois habitudes clés.

• Gestion du cycle de vie des applications : comment les équipes gèrent les logiciels tout au long de leur cycle de vie, depuis l'idée jusqu'au retrait
• Réaction aux incidents : comment les équipes identifient, résolvent et préviennent les problèmes qui affectent la disponibilité ou la sécurité d'un système
• Planification de continuité : comment les équipes planifient le fonctionnement de leurs équipes et de leurs systèmes lorsque des événements imprévus entraînent des problèmes

La gestion du cycle de vie des applications (ALM) est une pratique qui permet de gérer de façon globale un logiciel tout au long de son cycle de vie, depuis sa création jusqu'à son retrait. L'ALM est une pierre angulaire de la résilience du système et englobe les personnes, les processus, les outils et les disciplines associés au cycle de vie des applications. Ces disciplines comprennent les DevOps et les méthodologies de livraison, l'observabilité, les stratégies de test, la gouvernance et l'IC/CD.

Lorsqu'une entreprise pratique une ALM efficace, ses équipes réagissent rapidement aux changements, et ses applications suivent l'évolution des exigences métiers sans compromettre la stabilité ou la qualité.

D'autre part, sans ALM saine, les équipes rencontrent des difficultés à chaque étape du cycle de vie de l'application.

Les symptômes d'une mauvaise ALM comprennent :

• Cycles de développement lents et sujets aux erreurs
• Déploiements intensifs et difficiles
• Problèmes ou bogues de grande gravité découverts dans des environnements de production et de post-AQ
• Agents IA qui hallucinent ou dont le comportement est incohérent
• Annulations fréquentes ou déploiements correctifs requis pour stabiliser les versions

L'ALM touche presque tous les aspects d'une solution. Par conséquent, l'établissement de pratiques d'ALM claires et efficaces pour votre solution est un élément clé de votre travail architectural.

Élaborez de meilleures pratiques de GTA en vous concentrant sur trois domaines clés.

• Gestion des versions : la planification, le séquencement, le contrôle et la migration des modifications vers différents environnements
• Stratégie environnementale : une stratégie d'utilisation et de gestion d'applications dans des environnements cibles pendant le développement et les tests
• Stratégie de signalisation : définition des signaux critiques et instrumentation d'application utilisés pour détecter et corriger les défaillances dans le système avant la dégradation
• Stratégie de test : les principes et les normes qui guident la planification et l'exécution de tests pour évaluer la réussite de vos applications pendant les processus ALM

La gestion des versions consiste à planifier, séquencer, contrôler et migrer les modifications vers un ou plusieurs environnements. Une version unique est un groupe de modifications planifiées qu'une équipe déplace en même temps vers un environnement cible.

La publication d'une modification dans un système entraîne un risque. Si le système est dans un état stable avant la modification, il passe à un nouvel état, où il est également plus vulnérable aux risques liés aux modifications futures. Si de futures modifications déclenchent un état incontrôlé et instable dans le système, elles peuvent entraîner un incident critique. Dans une architecture de solution, concevoir des versions résilientes ne se limite pas à tester efficacement les modifications apportées. Cela implique également de planifier comment introduire des modifications dans vos systèmes et leurs utilisateurs en toute sécurité.

Le travail de vos équipes dépend d'informations de publication prévisibles et précises. Dans vos processus de gestion des modifications et d'activation, déterminez clairement quelles modifications peuvent être intégrées à votre système. Dans vos processus de gestion des versions et d'activation, spécifiez comment et à quelle fréquence les modifications sont publiées dans votre système.

Vos parties prenantes s'intéressent également aux informations sur les versions, en particulier si elles sont liées aux fonctionnalités ou aux correctifs de bogues qu'elles demandent. Pour gagner Trust en votre solution et démontrer de la valeur à vos parties prenantes, établissez des calendriers de publication cohérents et clairs et expédiez des artefacts de publication stables.

Pour établir une gestion efficace des versions pour Salesforce :

• En étroite adéquation avec la gouvernance architecturale et de développement. Assurez-vous que les versions sont planifiées longtemps à l'avance pour s'aligner sur tous les forums et contrôles de gouvernance pertinents. Avant de vous lancer dans le développement, faites examiner et approuver par le Conseil de l'IA tous les cas d'utilisation Agentforce prioritaires. Obtenez des cas d'utilisation Agentforce à haut risque examinés par les équipes Legal and Ethical Use.Utilisez des listes de contrôle de déploiement et de la documentation pour suivre les artefacts de déploiement, tels que les noms d'API d'agent Agentforce, par rapport aux activités de gouvernance.
• N'utilisez pas de processus de développement basé sur l'organisation ou de publication. Ce paradigme reflète des technologies plus anciennes et plus limitées pour le développement et la publication. Avec la Salesforce CLI, les équipes peuvent désormais adopter des capacités de développement et de publication pilotées par la source.
• Choisissez le mécanisme de libération le plus stable possible. Cette approche accomplit deux choses. Premièrement, il réduit la durée des fenêtres de publication et des interruptions de service. Deuxièmement, il permet des comportements de libération hautement contrôlés et prévisibles. Plus votre mécanisme de publication est stable, moins les versions risquent d'introduire des modifications qui nécessitent des correctifs ou des annulations. En cas de problème imprévu, des mécanismes de publication stables simplifient également la tâche du personnel de support ou des administrateurs système.

Les meilleurs mécanismes de publication pour votre équipe sont les options les plus stables pour lesquelles votre équipe possède les compétences requises. Ce sont les mécanismes de libération recommandés, répertoriés par ordre de stabilité. Tous sont compatibles les uns avec les autres. Par conséquent, utilisez-en plusieurs en même temps si cela convient à votre entreprise.

• Packages déverrouillés : les packages déverrouillés sont l'artefact de version le plus stable. Le déploiement de modifications en installant un package est le moyen le plus rapide et le plus prévisible d'introduire des modifications. Les packages utilisent la gestion des versions, qui permet une gestion robuste des modifications et des restaurations précises et conviviales pour l'administrateur système. Les packages nécessitent une solide gestion des métadonnées, qui peut vous aider à identifier rapidement les dépendances mal gérées. Ils créent également des pipelines et des artefacts de développement auditables. Consultez Empaquetage.
• DevOps Center – DevOps Center permet aux équipes d’exécution qui ont des ensembles de compétences à faible code ou pro-code d’utiliser le contrôle de la source, de travailler en collaboration sur les modifications et de définir des parcours de publication communs. DevOps Center s'intègre au contrôle des sources et permet de contrôler par pointer-cliquer les modifications et les déploiements.
• Développement piloté par la source et déploiement de métadonnées en utilisant la Salesforce CLI : si vous ne pouvez pas utiliser de packages, utilisez la Salesforce CLI pour votre développement piloté par la source et déploiement de métadonnées. Ne déployez pas de métadonnées en utilisant l'ancien format package.xml, qui suit une structure différente de celle du format source recommandé. Le format source a évolué pour prendre en charge le développement de packages, les workflows d'organisation test et un suivi des modifications plus précis dans les organisations sandbox. Le format est plus lisible, permet de découpler davantage les types de métadonnées complexes et les dépendances, et vous donne beaucoup plus de contrôle sur les manifestes de déploiement.
• Nommez vos versions. Donnez à vos versions des identifiants clairs pour aider vos équipes et vos parties prenantes à rester alignées. Dans Salesforce, le nom de chaque version majeure commence par « Spring », « Summer » ou « Winter », suivi de l'année de la version (par exemple, « Summer ’25 »). Si vous n'avez pas encore de convention de nommage pour définir et organiser les versions dans votre entreprise, établissez-en une et utilisez-la. L'utilisation de noms de version clairs facilite l'organisation à chaque étape de la planification, du développement et de la livraison, dans tous les systèmes de vos équipes. Utilisez vos noms de version dans votre feuille de route pour communiquer clairement à vos parties prenantes les changements à venir et quand. Utilisez vos noms de version dans votre documentation, vos journaux de modification, vos descriptions de travail, vos commentaires de code et vos branches de contrôle de code source afin de faciliter le suivi et l'audit de vos artefacts de développement.
• Dans un Manifeste de version, gérez correctement les dépendances. Les métadonnées Salesforce ont des dépendances intégrées. L'échec des déploiements Salesforce est souvent dû au fait que les dépendances ne sont pas correctement gérées. Le choix d'un mécanisme de publication stable, tel que décrit précédemment, peut vous aider à révéler les dépendances mal gérées plus tôt dans votre cycle de développement. L'une des principales raisons pour lesquelles les packages déverrouillés sont le vecteur de publication le plus stable est leur solide gestion des métadonnées, qui est requise pour le développement et la création de packages. Si vous ou vos équipes de gestion des versions ne comprenez pas les dépendances intégrées entre les types de métadonnées Salesforce, vous ne pourrez pas détecter proactivement les combinaisons problématiques dans vos manifestes de déploiement et de publication. Consultez Gestion des dépendances.

Les modèles et anti-modèles pour ALM montrent à quoi ressemble une gestion des versions correcte et médiocre pour une organisation Salesforce. Utilisez les modèles pour valider vos conceptions avant de les élaborer ou pour identifier les emplacements de votre système qui doivent être refactorisés.

Pour plus d'informations sur les outils Salesforce pour la gestion des versions, consultez Outils Salesforce pour la résilience.

Salesforce fournit divers environnements que vous pouvez utiliser pendant les cycles de développement et de test d'applications. Une stratégie d'environnement efficace pour Salesforce nécessite de comprendre comment utiliser les environnements et à quoi ressemble une bonne gestion. En ALM, l'utilité d'un environnement de développement ou de test dépend de sa fidélité et de son isolement par rapport à la production.

Une bonne stratégie environnementale offre plusieurs avantages.

• Une plus grande fidélité à la production
• Accélération de la configuration et de la destruction des environnements
• Plus agile dans le développement et les tests
• Sécurité accrue dans tout votre pipeline
• Réduction du bruit et des conflits à travers les étapes de livraison
• Équipes de développement plus heureuses

Les équipes peinent souvent à tirer parti de ces avantages. Les défis pour tirer le meilleur parti de vos environnements de développement et de votre stratégie peuvent provenir de plusieurs sources. Une source probable est le type de modèle de développement que vos équipes suivent.

Dans l'ancienne approche de développement basée sur l'organisation, chaque environnement devait remplir plusieurs fonctions. En plus d'être l'endroit où votre équipe effectue ses différents types de travail, elle devait être la source de vos artefacts de version (c'est-à-dire les métadonnées que vous souhaitiez déployer dans une version). Les environnements n'étaient pas faciles à configurer ou à démanteler. Par conséquent, ils étaient souvent surpeuplés et remplis de conflits de métadonnées entre les équipes, et ils ne contribuaient pas à une vitesse ou à une flexibilité significatives de l'ALM dans son ensemble.

L'utilisation d'un modèle de développement basé sur la source modifie fondamentalement la relation des environnements avec vos versions et artefacts de version. Dans ce modèle, le contrôle de la source est la source des métadonnées que vous souhaitez publier. Les environnements ne sont que des lieux où vos équipes travaillent.

Cependant, suivre le modèle de développement basé sur la source ne garantit pas à lui seul une bonne stratégie environnementale. Même avec le contrôle du code source, les équipes peuvent avoir du mal à configurer des conditions pour tester des intégrations à des systèmes externes, des configurations qui dépendent de métadonnées qui ne sont pas dans le contrôle du code source, par exemple des packages gérés ou des personnalisations qui dépendent de données), etc. Dans certaines circonstances, les défis d'un modèle basé sur la source sont similaires aux défis typiques d'un modèle basé sur l'organisation.

Pour élaborer une stratégie environnementale efficace :

• Adoptez un modèle de développement et de version piloté par la source. Arrêtez d'utiliser des modèles de développement basés sur l'organisation. Consultez Gestion des versions.) Vous devez dissocier vos environnements de ce que vous déployez pour créer une stratégie environnementale saine et des versions plus saines.
• Comprenez les types de travail que chaque environnement prend en charge. Les types d'environnement pris en charge par Salesforce ont des capacités et des limites différentes. En concevant votre stratégie environnementale, tenez compte des actions que les environnements peuvent et ne peuvent pas exécuter. Assurez-vous que vos équipes travaillent dans un environnement doté des capacités dont elles ont besoin. Pour plus d'informations, consultez cette présentation des environnements de développement Salesforce et de leurs fonctionnalités.

Consultez ce tableau pour découvrir les fonctionnalités et les environnements à utiliser pour plusieurs tâches de développement courantes.

Par ailleurs, notez que pour les agents Agentforce qui utilisent des fonctionnalités telles que la Bibliothèque de données Einstein, des articles Knowledge et des données non structurées, les tests complets sont limités, sauf si vous avez une sandbox Data 360. Une organisation sandbox Data 360 est également requise pour garantir des conditions de test précises.

• Découplez les environnements des artefacts de publication. N'utilisez pas le développement basé sur l'organisation. Traitez les environnements comme des lieux où le travail dure une période déterminée. Considérez l'état des métadonnées dans un environnement comme séparé de vos artefacts de publication. Si un élément de code ou de configuration est « compris » dans un environnement, il doit être engagé dans le contrôle de la source, ce qui en fait un artefact de version.

  • Les environnements sont éphémères. Élaborez des processus pour pouvoir les créer et les détruire le plus rapidement possible.
  • Les artefacts perdurent. Ils appartiennent au contrôle source.

• Découplez les environnements des parcours de publication. Il est courant d'afficher des parcours de publication obligatoires qui nécessitent le déploiement de modifications dans des environnements spécifiques. Souvent, cette approche est implémentée afin d'établir un proxy pour valider la maturité de l'application ou la stabilité de la version. Les équipes peuvent également l'utiliser pour tenter de limiter le nombre d'environnements dans lesquels elles doivent configurer une infrastructure de test complexe. Dans les paradigmes basés sur la source, vous disposez d'une plus grande flexibilité dans la façon et l'emplacement de validation et de test des modifications.

  • Les étapes de publication s'appliquent aux artefacts de publication, pas aux environnements. Ne créez pas un environnement uniquement dans le but de « recueillir » toutes les modifications à une étape de publication particulière. Le contrôle de la source, en particulier la branchement, sert à cela. Utilisez des stratégies de branchement dans le contrôle du code source pour organiser les modifications à déployer dans quels environnements. Selon le travail que vous devez effectuer, il peut être nécessaire de déployer toutes les métadonnées d'une version dans un environnement. La branchement permet de le faire. À quelques exceptions près, chaque environnement de développement doit être actualisé ou détruit dès que les travaux pertinents sont terminés. Assurez-vous de synchroniser toutes les modifications apportées aux métadonnées effectuées dans un environnement spécifique (et que vous souhaitez conserver) vers le contrôle source.
  • Les environnements ne sont aussi utiles que leur fidélité à la production. Optimisez les workflows de configuration ou l'automatisation de votre environnement afin de démanteler ou d'actualiser les environnements le plus rapidement possible. Considérez toute configuration qui vous empêche d'effectuer des actualisations d'environnement plus rapides et plus fréquentes comme un risque critique pour la résilience globale de vos processus ALM. Si vous avez des travaux d'assainissement connexes, ajoutez-les à vos plans et priorisez-les. Explorez comment adopter des unités modulaires à couplage plus souple dans votre système. Ils permettent aux équipes d'effectuer plus de types de développement dans des organisations tests et libèrent des allocations sandbox pour d'autres tâches. N'oubliez pas les capacités que les organisations tests offrent pour tester des fonctionnalités que vous n'avez pas en production, soit parce que vous n'avez pas acheté de licences pour elles, soit parce que vous ne les avez pas activées.
  • Dans les environnements auxquels les utilisateurs professionnels ou les utilisateurs peuvent accéder, laissez ces utilisateurs se concentrer sur ce qui les intéresse. Ne pas avoir d'environnements génériques et indifférenciés dans lesquels de nombreux groupes d'utilisateurs finaux ou parties prenantes tentent d'effectuer un travail lié à la gestion des relations commerciales commerciales. Invitez et activez des parties prenantes spécifiques dans des environnements spécifiques pour effectuer un travail spécifique. Évaluez attentivement tout processus qui place les utilisateurs ou les parties prenantes dans un environnement contenant plus de données qu'une sandbox Partial Copy ne peut prendre en charge. Assurez-vous que le volume de données est nécessaire au travail à réaliser. Planifiez vos cycles de test d'acceptation des utilisateurs et de développement en phase initiale de manière à ce qu'ils se déroulent le plus étroitement possible. Optimisez toutes les étapes de test afin d'activer des cycles de commentaires et d'itération plus rapides et plus précoces pour vos équipes de développement et vos utilisateurs. Consultez Stratégie de test.

• Élaborez différents parcours de publication pour différents types de modification. Les modifications n'exigent pas toutes que les mêmes types de travail ALM soient effectués dans le même ordre. Demander aux utilisateurs d'effectuer des tests d'acceptation des modifications mineures apportées aux composants back-end d'un système n'est probablement pas une bonne utilisation de leur temps. Cependant, l'acceptation des utilisateurs et les tests à l'échelle peuvent s'avérer extrêmement utiles pendant les premières étapes du développement d'une application mobile. Identifiez les parcours de publication pour différentes catégories de changement, par exemple risque élevé, risque moyen et risque faible.

  • Risque élevé : Les modifications impactent les clients, les partenaires ou tous les utilisateurs internes. Les modifications impactent la sécurité ou l'intégration. Les modifications ajoutent de nouvelles fonctionnalités complexes.
  • Risque moyen : Les modifications impactent plus d'un seuil défini d'utilisateurs internes. Les modifications impactent les modèles de données, l'automatisation qui effectue des opérations sur les données ou l'intégration.
  • Risque faible : impacte directement un nombre d'utilisateurs internes inférieur à un seuil défini. N'inclut pas les modifications apportées à la sécurité, aux modèles de données ou aux automatisations impliquant des opérations sur les données ou l'intégration.

• N'autorisez pas l'existence d'environnements surpeuplés. Un manque de discipline dans la définition des priorités, la portée et l'ordonnancement des travaux entraîne inévitablement une surcharge de travail dans les environnements de développement, avec des volumes de travail trop importants, trop nombreux et trop différents. Les environnements surpeuplés créent des niveaux élevés de stress, d'ambiguïté et de conflits entre les équipes de développement. Ils créent également du bruit dans les pipelines de développement et entravent les efforts de contrôle de la qualité. Outre ces effets négatifs, les environnements de développement surpeuplés constituent de graves menaces pour le maintien et la sécurité de l'environnement. Considérez la surpopulation comme un symptôme de problèmes potentiels dans vos processus ALM. Déterminez les causes profondes des problèmes et corrigez-les. Si vous rencontrez encore une surpopulation, vous pouvez acheter des sandbox supplémentaires.

La liste des modèles et anti-modèles pour ALM montre à quoi ressemble une bonne et une mauvaise gestion de l'environnement dans une organisation Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou pour identifier les zones de votre système qui doivent être refactorisées.

Pour plus d'informations sur les outils Salesforce pour la gestion de l'environnement, consultez Outils Salesforce pour la résilience.

Une stratégie de signalisation définit les signaux critiques et l'instrumentation d'application nécessaires pour détecter, diagnostiquer et corriger les pannes avant qu'elles ne se dégradent en cascade à l'échelle du système. Une instrumentation efficace transforme les applications de victimes passives d'échecs en participants actifs à leur propre résilience, capables de détecter les problèmes, d'adapter leur comportement et de coordonner une dégradation gracieuse lorsque nécessaire.

Lorsque les applications mettent en œuvre une instrumentation complète, elles acquièrent la capacité de s'autoréguler en cas de stress, de communiquer leur état de santé aux opérateurs et de participer aux efforts coordonnés de rétablissement. Ces capacités permettent aux systèmes de maintenir la qualité du service même lorsque des composants individuels sont en détresse. D'autre part, sans instrumentation appropriée, les applications deviennent des boîtes noires qui échouent silencieusement jusqu'à l'apparition de symptômes catastrophiques. Les équipes réagissent aux problèmes uniquement lorsque les utilisateurs les signalent, et le dépannage devient un exercice d'archéologie plutôt que d'observation.

• Détecter les échecs dans l'application Les applications doivent s'instrumenter pour détecter et répondre aux modèles de défaillance courants qui émergent sous une forte charge. Tenez compte de la saturation de la file d'attente. Lorsque les files d'attente de messages se remplissent plus rapidement qu'elles ne peuvent être traitées, les applications non instrumentées continuent d'accepter du travail jusqu'à ce que l'épuisement de la mémoire ou des cascades d'expiration se produisent. Des applications correctement instrumentées surveillent la profondeur de la file d'attente, les taux de rejet et la latence de traitement, déclenchant des réponses défensives lorsque les seuils sont dépassés.

• Gérer efficacement les signaux extérieurs à l'application: Le traitement des signaux du système d'exploitation représente un autre point d'instrumentation critique. Les applications doivent enregistrer les gestionnaires de signaux de terminaison (SIGTERM, SIGINT) pour permettre un arrêt gracieux. Pendant l'arrêt, les applications correctement instrumentées arrêtent d'accepter de nouveaux travaux, autorisent les requêtes en vol à se terminer, vident les tampons, ferment les connexions proprement et désinscrivent de la découverte du service. Cet arrêt orchestré évite la perte de données et permet aux répartiteurs de charge de rediriger le trafic sans interruption.

• Instrument pour scénarios de défaillance complexes : Au-delà de ces schémas de base, les applications doivent s'instrumenter pour des modes d'échec plus subtils. L'identification des défaillances grises, dans lesquelles les composants semblent sains pour certains observateurs alors qu'ils échouent pour d'autres, nécessite de corréler les signaux internes et externes. Une application peut utiliser son pool de connexions à la base de données pour signaler les contrôles d'intégrité réussis tout en suivant simultanément les taux de réalisation des transactions qui révèlent une dégradation rampante. Des stratégies d'instrumentation efficaces superposent plusieurs points d'observation.

  • Les métriques métiers suivent des indicateurs de réussite spécifiques à l'application, tels que les taux de réalisation de commandes ou la qualité des résultats de recherche.
  • Les métriques système surveillent l'utilisation des ressources, les distributions de latence et les taux d'erreur.
  • Les sondes synthétiques suivent en permanence des parcours critiques pour détecter la dégradation avant que les utilisateurs ne la rencontrent.
  • Le traçage distribué permet de visualiser les demandes à travers les frontières du service.

Ces signaux sont exposés via des interfaces standardisées qui permettent aux systèmes automatisés et aux opérateurs humains d'évaluer l'intégrité de l'application. L'instrumentation elle-même fait partie de la stratégie de résilience de l'application, permettant aux disjoncteurs de déclencher en fonction des taux d'erreur, aux autotartres de répondre aux profondeurs de file d'attente et aux opérateurs de prendre des décisions informées en cas d'incident.

Les modèles et anti-modèles ALM montrent à quoi ressemble une stratégie de signalisation correcte et médiocre dans une organisation Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou pour identifier les zones de votre système qui doivent être refactorisées.

Pour plus d'informations sur les outils Salesforce pour une stratégie de signalisation, consultez Outils Salesforce pour la résilience.

Une stratégie de test est un ensemble de principes directeurs et de normes pour planifier et exécuter des tests qui évaluent la réussite et l'échec des applications pendant les processus ALM. Une stratégie de test tient chaque partie prenante impliquée dans les tests informée de la priorité, du but et de la portée d'un test donné. Il aide également les équipes de projet à créer des plans de test efficaces et réfléchis.

Généralement, les développeurs ou les experts en assurance qualité et en tests sont impliqués dans la création et l'exécution de tests spécifiques. Une stratégie de test permet de s'assurer que ces personnes savent quels types de test doivent être effectués pour un projet donné et dans quelle séquence les effectuer. Une stratégie de test permet également de s'assurer que les équipes disposent des éléments nécessaires pour élaborer des tests, des plans de test et des artefacts bien formés (par exemple, des jeux de données, des appareils et des simulateurs de trafic ou de réseau).

Une stratégie de test efficace permet de déterminer clairement comment, quand, où et pourquoi exécuter différents types de test (y compris des tests unitaires, des tests d'interface utilisateur et des tests de régression) dans diverses combinaisons et conditions afin de déterminer le comportement de votre système et de toute modification en vol. Une stratégie de test efficace produit des tests qui montrent la conformité d'un système à des exigences non fonctionnelles, telles que l'évolutivité, la fiabilité et la convivialité, qui peuvent être difficiles à mesurer avec un seul type de test.

Pour créer des stratégies de test efficaces pour Salesforce :

• Testez de façon itérative, fréquente et automatisée autant que possible. Concevez et implémentez une automatisation des tests qui permet aux équipes d'exécuter divers types de test sur diverses charges de travail. Orchestraz automatiquement diverses exécutions de test lorsque des modifications entrent dans le contrôle de la source. Cette approche permet aux équipes d'identifier proactivement et de traiter les régressions à un stade précoce. Utilisez l'intégration continue/livraison continue (CI/CD) pour cet effort si possible. Sinon, établissez des plans de test clairs qui permettent aux équipes d'exécuter des séquences de tests tôt et souvent, en libre-service. Pour les agents Agentforce testant, s'appuyer sur le Centre de test pour effectuer des tests rigoureux par lot sur les agents IA avec diverses entrées afin de s'assurer qu'ils fonctionnent correctement dans différents scénarios.
• Reconnaissez que chaque modification ne nécessite pas tous les types de test. De la même façon qu'un pipeline de versions efficace prend en charge les parcours pour les applications à risque élevé, moyen et faible, une stratégie de test efficace est également disponible. Indiquez clairement aux équipes comment sélectionner et suivre un régime de test approprié pour des applications présentant divers types de risque, de cas d'utilisation ou de complexité. Voir Stratégie environnementale.
• Déterminez quels tests peuvent être effectués dans différents types d'environnement. La fidélité à la production est un élément clé d'un test précis, mais cela signifie des choses différentes pour différents types de test. Par exemple, le test de régression nécessite la fidélité à la production en termes de métadonnées et, dans une certaine mesure, de données. Assurez-vous de définir le type de fidélité à la production requis pour une série de tests donnée, et de classer clairement les types d'environnement qui peuvent prendre en charge les conditions appropriées pour différents tests. Pour une vue d'ensemble des types de travail qui correspondent à chaque type d'environnement, consultez Stratégie environnementale.
• Utilisez des tests d'endurance, de contrainte, de performance et d'échelle pour évaluer en permanence la maturité d'application. Ces tests montrent la préparation d'une application par rapport aux besoins au niveau de la production. Pour de nouvelles fonctionnalités majeures, exécutez ces tests à plusieurs intervalles dans le cycle de développement d'applications. Il est anti-modèle de considérer ces tests comme faisant partie d'une seule phase ou étape de développement au lieu de faire partie de tâches en cours. Il est très utile pour les équipes de recueillir rapidement et souvent des commentaires sur les performances de l'application, ce qui les aide à mieux comprendre la proximité ou la distance entre l'application et la préparation au niveau de la production. La capacité de mieux identifier et résoudre les problèmes avant la mise en production des modifications vaut la complexité supplémentaire d'exécuter fréquemment des tests plus sophistiqués.
  • Savoir quels tests comptent. Vous aurez probablement un délai fixe pour effectuer votre test d'échelle ou de performance, ce qui rend difficile de tester chaque facette de votre système. Les fonctionnalités ne sont pas toutes utilisées de la même façon et les goulets d'étranglement à l'échelle n'impacteront pas tous l'activité de la même façon. Assurez-vous que vos tests à l'échelle ciblent les parties les plus utilisées et les plus appréciées du système. Définissez et comprenez les opportunités les plus importantes pour vérifier et améliorer l'échelle et les performances dans votre organisation.
  • Sachez à quoi ressemble « assez bien ». La définition des critères de réussite de vos tests d'échelle et de performance est essentielle. Assurez-vous que vous et vos équipes de développement utilisez les critères de réussite comme critères de test. Assurez-vous également qu'ils informent les équipes de développement des exigences fonctionnelles. Généralement, ces critères comprennent la prise en charge d'un nombre spécifique d'utilisateurs simultanés avec des temps de réponse inférieurs à une valeur convenue, et vos objectifs de niveau de service (SLO). Définissez vos critères cibles clés, puis concevez des tests d'échelle et de performance qui vérifient que les critères sont remplis.
  • Assurez-vous d'avoir des environnements adéquats. Les tests d'échelle et de performance nécessitent une fidélité particulière à la production. Vos jeux de données, vos données démographiques de demande, vos taux de demande et vos caractéristiques de charge de travail dans vos environnements de non-production doivent correspondre autant que possible à ce que vous voyez en production. Pour les tests d'échelle, vous devez utiliser une Sandbox Full . Si votre organisation n'a pas de sandbox Full pour les tests à l'échelle, vous ne pouvez pas exécuter des tests à l'échelle adéquats.
• Assurez-vous que les charges de travail de test vous aident à mesurer les exigences non fonctionnelles. Pensez à prendre en compte :
  • Données d'essai - Chaque type d'essai devrait être effectué par rapport à des données isolées de la production. Dans les tests unitaires Apex, mettre en œuvre des modèles d'usine de données pour s'assurer que le code génère ses propres données d'essai, isolées des données d'environnement. Vous pouvez également créer et gérer des jeux de données de test sous divers formats afin de tester les comportements de chargement de données, remplir des environnements de développement avec des données pour des tests basés sur l'interface utilisateur et faciliter les tests d'intégration. Toutes les données d'essai, qu'elles soient gérées en tant que jeux de données externalisés ou créées à la demande par un code d'usine de données, doivent être nettoyées des données confidentielles et d'identification. Il doit inclure des données corrompues, incomplètes et malformées pour prendre en charge les comportements de test unitaire négatifs et aux frontières.
  • Services fictifs et stub : pour des tests d'intégration, vous pouvez utiliser des services fictifs et stub pour simuler des réponses d'API. Apex prend en charge une API Stub pour créer des infrastructures fictives à utiliser dans des tests Apex. Mocking pour créer des infrastructures mocking qui peuvent être utilisées dans des tests Apex. Les simulations et les talons peuvent aider à valider les comportements de traitement des données d'un système, en s'appuyant moins sur des usines de données complexes ou des jeux de données tests externes. Il est parfois plus approprié d'utiliser des simulations et des stubs dans des tests où le trafic de production ou les volumes de données ne sont pas pertinents.
  • Appareils et technologies d'assistance - Un élément clé de l'élaboration d'applications intéressantes et accessibles est de s'assurer qu'elles répondent aux attentes des utilisateurs dans une variété d'appareils et avec différents types de technologies d'assistance. Un test d'utilisation efficace peut nécessiter plus d'investissements et différents types d'expertise, mais il est essentiel de connaître le degré d'architecture de vos applications accessibles aux utilisateurs lors de leur publication.
  • Simulateurs : lorsque vous devez répliquer des volumes de requêtes utilisateur de type production, un trafic d'API ou des variations de vitesse réseau, vous pouvez avoir besoin d'outils qui simulent ces conditions. Les tests n'ont pas tous besoin d'un tel niveau d'investissement. Ces outils sont souvent très utiles pour les tests d'évolutivité et de performance.
  • Le test IA et les agents - Un objectif principal du test est de réduire les hallucinations IA, qui sont des réponses convaincantes fabriquées et incorrectes . Assurez-vous que les cas d'utilisation de l'IA sont testés pour mettre en évidence les problèmes courants dus à une compréhension incomplète du client, à des données manquantes, à des champs avec des métadonnées incomplètes et à des données obsolètes. Utilisez le Centre de test pour faciliter la création des données de test nécessaires à ces tests.

Le tableau ci-dessous présente une sélection de schémas à rechercher ou à élaborer dans votre organisation, et des anti-schémas à éviter ou à cibler pour la correction.

✨ Découvrez plus de modèles pour ALM dans l'Explorateur de modèle et anti-modèle.

En ingénierie de la sécurité et de la fiabilité du site (SRE), la réponse aux incidents se concentre sur la façon dont les équipes identifient et traitent les événements qui impactent la disponibilité globale ou la sécurité d'un système, ainsi que sur la façon dont les équipes travaillent pour traiter les causes profondes et prévenir les problèmes futurs. La réponse à un incident implique les processus, les outils et les comportements organisationnels requis pour résoudre les problèmes en temps réel et après un problème.

En tant qu'architecte, vous n'êtes peut-être pas la personne qui surveille les opérations quotidiennes de votre solution une fois qu'elle est mise en ligne. Une partie de l'architecture de la résilience consiste à concevoir des capacités de récupération permettant aux équipes de support d'effectuer un diagnostic de premier niveau, de stabiliser les systèmes et de transférer efficacement l'investigation et l'atténuation des causes profondes aux équipes de développement ou de maintenance. Les équipes qui assistent directement les utilisateurs au quotidien peuvent ne pas avoir une compréhension approfondie ou une expertise approfondie de l'architecture du système. Il est essentiel que ces équipes disposent des outils et des processus nécessaires pour surveiller les opérations quotidiennes, accéder aux informations du système lors du diagnostic d'un incident potentiel et être des premiers intervenants efficaces pour tout problème impactant la disponibilité.

Vous pouvez améliorer la réponse des équipes aux incidents dans vos solutions Salesforce en vous concentrant sur votre temps de récupération, votre capacité de tri, et la surveillance et les alertes.

En cas d'incident, la première priorité doit être de rétablir un état opérationnel stable des systèmes. Souvent, les entreprises pensent que le seul moyen de se remettre d'un incident est de « corriger le problème ». Cette hypothèse est juste dans la mesure où l'analyse précise des causes premières et la résolution des problèmes critiques dans un système sont les moyens ultimes de les résoudre. Cependant, « corriger le problème » pendant les premières étapes de la réponse à la crise n'est pas l'approche la plus pratique. Selon la gravité d'un incident, chaque seconde et son impact peuvent entraîner une perte de chiffre d'affaires ou de réputation pour l'entreprise.

Souvent, la tentative de diagnostiquer et de traiter les causes profondes retarde les efforts de restauration d'un système. Sur le plan logistique, l'adoption d'une approche qui demande aux intervenants de s'attaquer aux causes profondes exerce une pression considérable sur les experts en la matière (PME) et le personnel de support de votre entreprise. Pour rechercher et corriger les causes profondes _d'_un incident, les PME doivent être de garde à chaque incident, ce qui peut empêcher le personnel de support de première ligne et en contact avec les clients d'agir. Cela peut également entraîner la publication par les équipes de modifications qui, à leur tour, créent plus d'incidents. Au final, une telle approche augmente les coûts, consomme de la bande passante entre les équipes, et entraîne en temps de crise des comportements qui peuvent éroder la Trust client et la réputation de la marque.

Le paradigme de gestion des incidents approprié consiste à prioriser et à se concentrer sur la reprise en tant que première étape. Une fois le système rétabli dans la stabilité, vous pouvez effectuer un suivi avec des post-mortems irréprochables, des enquêtes sur les incidents, des mesures correctives pour les causes premières et des activités similaires. Cet ordre d'opérations permet mieux au personnel d'intervention en cas d'incident de trier, de diagnostiquer et d'exécuter des tactiques de récupération, en alertant les PME concernées de ne prêter assistance que si nécessaire. Il permet également aux PME d'identifier et de corriger les causes profondes d'un incident en réduisant la pression d'un tic-tac.

Pour adopter un état d'esprit de reprise avant tout en réponse à un incident :

• Établir et atteindre des objectifs de niveau de service SLO. Les SLO sont des normes que vous développez avec vos parties prenantes pour des exigences non fonctionnelles spécifiques (NFR) d'un système, telles que les performances ou le temps de fonctionnement. Ces objectifs sont mesurés par des indicateurs de niveau de service (SLI) sur une période donnée. Sans SLO, la plupart des tâches liées à la réponse aux incidents et au dépannage des problèmes complexes peuvent sembler désorganisées et réactives, par exemple inciter à agir rapidement pour « mettre fin à cette erreur spécifique, pour cette poignée d’utilisateurs qui l’ont signalée ». C'est souvent ce cycle qui pousse les équipes à rapprocher l'analyse des causes profondes de la réponse aux incidents, car il semble que cela aidera à arrêter les comportements réactifs. Établir des SLO et des SLI est une méthode plus efficace pour commencer. Pour établir des SLO, tenez compte des questions ci-dessous.
  • Quel est le NFR de votre système pour les 1 à 3 prochaines années ? Par exemple, votre NFR peut inclure les temps de réponse, les taux de requête de pointe et les utilisateurs simultanés que votre système doit pouvoir prendre en charge.
  • Que voulez-vous que vos clients et leurs utilisateurs vivent ? Basez vos SLO sur la réponse à cette question, qui peut être « Les utilisateurs peuvent exécuter rapidement des rapports dans Salesforce ».
  • Que pouvez-vous mesurer et pendant quelle période devez-vous le mesurer? Basez vos SLI sur la réponse à cette question. Un SLI correspondant à l'exemple précédent peut être « x % des rapports sont chargés en n secondes en moyenne, mesurés sur une période de 30 jours ».
• Définir et standardiser les tactiques de récupération. Les annulations de modification et les implémentations de contournement peuvent aider à rendre un système opérationnel et à minimiser l'impact d'un incident. Tactiques et protocoles de récupération de documents qui peuvent être exécutés par les membres appropriés de votre équipe de support ou d'exploitation. Les tactiques de récupération diffèrent selon le type d'incident. Le tableau suivant présente un cadre général qui mappe les types d'incident avec des tactiques de récupération. Pour plus d'informations sur l'identification des points de défaillance et la définition de stratégies d'atténuation, consultez Disponibilité.

• Définissez des critères clairs de sortie. Utilisez vos SLO pour déterminer si votre système n'a pas de statut d'incident ou d'impact.
• Définissez des processus pour les examens postérieurs à un incident et la réparation des causes profondes. Prenez le temps d'examiner les incidents une fois le service rétabli. Pendant les examens, adoptez une approche post-mortem irréprochable. Collaborer avec les intervenants pour établir des faits clairs sur ce qui s'est produit et comment cela s'est produit, plutôt que de tenter d'attribuer une faute ou un blâme à des individus. Utilisez différents formats d'examen pour examiner les moyens de résoudre les problèmes à long terme.
  • Un examen postérieur à l'intervention est axé sur la réponse à l'incident. Il est utile pour déterminer si les processus et les tactiques de réponse appropriés sont en place.
  • Une analyse des causes profondes de l ' incident est axée sur cette dernière. Il peut aider à identifier les bogues ou les problèmes de conception et d'implémentation de votre système qui ont entraîné l'incident.
• Appliquez périodiquement vos protocoles de récupération convenus. Pratiquez les protocoles de reprise pour vous assurer que tout le monde sait comment gérer les incidents. Utilisez des environnements sandbox et de test pour offrir aux équipes des emplacements où pratiquer la simulation d'incident et la reprise. Exercez-vous également sur vos examens post-incident. En faisant tout cela, la récupération fait partie de votre culture d'ingénierie et de support.

Les modèles et anti-modèles de réponse aux incidents montrent à quoi ressemble l'architecture pour prioriser la reprise dans une solution Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou pour identifier les zones de votre système qui doivent être refactorisées.

Pour plus d'informations sur les outils Salesforce qui facilitent la récupération, consultez Outils Salesforce pour la résilience.

Dans le contexte de la technologie, le tri consiste à attribuer des catégories et des niveaux de sévérité aux problèmes et aux demandes de support. Quelle que soit la planification de votre solution, des problèmes et des demandes de support utilisateur vont survenir. Ces problèmes peuvent provenir d'un manque de formation ou de gestion des changements, de lacunes dans l'interface utilisateur/UX, de comportements inattendus de l'utilisateur et de problèmes système urgents qui ne sont pas détectés par la surveillance ou l'alerte.

Les équipes de support et d'exploitation doivent être en mesure d'étudier efficacement les requêtes de support utilisateur et de les diagnostiquer rapidement. Le tri des problèmes afin d'éliminer les problèmes moins graves et de détecter rapidement les incidents système critiques est une compétence clé pour ces équipes. Un mauvais tri ralentit tous les niveaux de support utilisateur, prolonge les incidents critiques et augmente le risque d'interruptions supplémentaires pour vos clients et votre activité.

Bien que vous ne soyez pas impliqué dans les opérations quotidiennes et le support, en tant qu'architecte, il est de votre responsabilité de vous assurer que vos équipes de support et d'exploitation peuvent trier efficacement les problèmes dans n'importe quelle solution que vous créez sur Salesforce Platform.

Pour permettre aux équipes de résoudre efficacement les problèmes dans vos solutions Salesforce :

• Assurez-vous que les équipes de support ont accès à des informations utiles.
  • Documentez votre système et vos modèles de conception. Garantir la lisibilité et la cohérence de votre solution est un élément clé pour permettre au personnel de support de comprendre le système qu'il est responsable de soutenir. Dans votre documentation, tenez compte de la façon dont les équipes trouveront des informations sur la priorité des problèmes ou des incidents avec les différentes parties du système. Assurez-vous également que les équipes peuvent consulter rapidement des informations techniques sur les tactiques de récupération en fonction de la zone d'impact. Fournissez des guides de dépannage pertinents pour les problèmes courants Agentforce, tels que la Classification des rubriques et la Sélection d'actions, qui peuvent aider les équipes à trier rapidement les problèmes liés aux autorisations ou à la configuration.
  • Concevez en tenant compte du débogage. Les équipes de support et les administrateurs d'organisation devront activer le débogage et les diagnostics afin de trier correctement les problèmes des utilisateurs dans divers environnements. Parmi les modèles de débogage, on peut citer ceux qui intègrent des messages d'erreur de consignation et personnalisés dans des parcours d'exécution à travers le système. Activez les équipes de support sur les approches courantes de débogage Agentforce avec des outils tels que les journaux d'événements et la vue de raisonnement d'Agent Builder.
  • Identifier les PME et les parties prenantes concernées par les incidents. Créez une liste de PME ou de parties prenantes pertinentes qui devraient être disponibles pour soutenir le rétablissement après un incident, et qui devraient être impliquées pendant l'analyse post-incident.
  • Faites attention aux transferts. Garantissez la qualité de chaque transfert de solution aux équipes de support ou d'exploitation dans le cadre de la mise en ligne. Offrir une formation au personnel de support pour qu'il puisse parcourir l'architecture système appropriée et des exercices fictifs d'intervention en cas d'incident. Pensez aux transferts postérieurs à l'incident, notamment à la façon dont les équipes doivent documenter les informations qui ne sont pas consignées dans les journaux ou les notes de requête, ainsi qu'à la façon dont les intervenants en cas d'incident peuvent contribuer aux enquêtes sur les causes profondes ou effectuer des tests d'acceptation des utilisateurs pour toute mesure corrective.
• Si vous êtes consulté, gardez tout le monde concentré sur le rétablissement comme préoccupation principale.
  • Répondez rapidement. Répondez rapidement aux demandes de support utilisateur, aux notifications de surveillance et aux alertes que vous recevez.
  • Aidez à distinguer les symptômes des problèmes. Déterminez si un incident système réel doit être corrigé. Essayez d'identifier les composants avec les problèmes réels. Assurez-vous que les tactiques de reprise convenues sont suivies afin de libérer rapidement le système du statut d'incident.
• Pour les agents Agentforce qui prennent en charge des cas d'utilisation critiques, assurez-vous que des contournements viables et pertinents sont en place et peuvent être activés avec un court préavis en tant que mesure de redondance. Il peut s'agir par exemple de basculer vers la manipulation manuelle ou de rediriger vers la documentation pertinente pour un examen manuel.

Les modèles et anti-modèles de réponse aux incidents montrent à quoi ressemble une architecture pour un tri efficace dans une solution Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou pour identifier les zones de votre système qui doivent être refactorisées.

Pour plus d'informations sur les outils Salesforce pour faciliter le tri, consultez Outils Salesforce pour la résilience.

La surveillance et l'alerte sont des termes très utilisés dans l'ingénierie de fiabilité des sites. Dans le contexte de la résilience du système, la surveillance consiste à évaluer en permanence l'état actuel d'un système, et l'alerte automatise les notifications aux parties prenantes sur les préoccupations potentielles concernant l'état du système. Une surveillance et une alerte efficaces sont essentielles pour dissocier l'échelle et la croissance de votre système de l'échelle et de la croissance de votre personnel de support.

Salesforce fournit diverses capacités intégrées pour surveiller les comportements dans votre système. Salesforce offre également une surveillance en temps réel des événements en complément ou dans le cadre de Salesforce Shield. Dans n'importe quelle solution Salesforce, les conceptions conçues pour la surveillance et les alertes fournissent :

• Capacités de réponse automatisée aux incidents
• Informations pertinentes pour les utilisateurs appropriés, au moment opportun
• Informations claires pour les vues historiques et l'analyse des tendances

Pour concevoir une surveillance et des alertes efficaces dans vos solutions Salesforce :

• Faire de l'automatisation une priorité. Bien que notifier les utilisateurs des changements d'état critiques soit un élément crucial pour maintenir vos systèmes stables et opérationnels, dans une architecture idéale, le système corrige automatiquement les problèmes lorsque possible et envoie des alertes uniquement en cas de problèmes urgents et irrécupérables. Même sans capacités d'autocorrection, l'automatisation peut rendre vos alertes et vos rapports plus utiles.
  • Commencez par ce que Salesforce fournit déjà. Salesforce Platform fournit des journaux et des API pertinents qui permettent de surveiller les opérations de votre solution par rapport aux limites du gouverneur. De plus, la plate-forme envoie des alertes en cas d'infraction aux limites du gouverneur et autres problèmes similaires. Utilisez ces journaux et alertes comme base pour explorer les moyens d'automatiser plus complètement l'auto-reprise du système, les rapports d'incident et les alertes. Par exemple, vous pouvez implémenter une automatisation qui surveille le journal, puis prendre une mesure de récupération lorsqu'un type d'événement particulier est consigné.
  • Classez de façon prévisible les changements d'état du système. Créez des catégories spécifiques et pertinentes pour les états clés que vous souhaitez surveiller et dont vous souhaitez générer des rapports. Alignez ces catégories sur les catégories que vous définissez pour gérer l'état dans vos composants d'application. Adoptez un état d'esprit orienté API pour gérer les informations sur les changements d'état. Des formats de message et des catégories d'état cohérents simplifient l'automatisation, la génération de rapports et les alertes.
  • Alignez votre logique d'automatisation sur les autres parties de votre système. Si vous avez élaboré un traitement des erreurs d'automatisation approprié, vous pouvez étendre ces modèles à la classification des changements d'état et à la réponse avec l'automatisation. Pour les changements d'état considérés comme récupérables, vous pouvez automatiser les comportements de réessai. Pour les changements d'état considérés comme critiques ou mortels, automatisez les alertes aux utilisateurs.
• Évite de faire du bruit. Lorsque les utilisateurs reçoivent un nombre excessif d'alertes, en particulier des alertes qui ne nécessitent aucune action, ils commencent généralement à désactiver ou à ignorer toutes les alertes. Ce scénario sape tous les efforts visant à créer des alertes utiles. Pour mieux définir qui reçoit les alertes, ce qui les déclenche et quand elles sont déclenchées, procédez comme suit.
  • Élaborer des cartes des parties prenantes. Pour vous assurer que votre système envoie les alertes appropriées aux parties prenantes appropriées au moment opportun, commencez par identifier et classer vos groupes de parties prenantes.
  • Acheminez les messages en fonction des privilèges utilisateur. Envoyez des alertes uniquement aux destinataires qui ont la capacité et l'autorité de répondre. Les utilisateurs professionnels peuvent recevoir des alertes sur les problèmes qu'ils peuvent corriger en corrigeant les problèmes dans les enregistrements auxquels ils ont accès. Si un problème nécessite une intervention technique plus impliquée, les alertes doivent être adressées au personnel de support.
  • Soyez clair sur la réponse attendue. Envoyez des alertes uniquement dans les scénarios qui nécessitent une intervention humaine. Structurez les messages pour indiquer clairement l'action attendue du destinataire. Si vous envoyez une alerte à une partie prenante pour la visibilité et qu'aucune mesure n'est requise de sa part, indiquez-le clairement dans la version du message qu'elle reçoit.
  • Déclarez les alertes opportunes et pertinentes. Les alertes envoyées en réponse à des échecs rencontrés et qui doivent encore être corrigés) ne sont pas aussi utiles que les alertes relatives à un échec potentiel. Idéalement, le personnel de support est alerté dès que des problèmes se produisent dans le système, ce qui permet de régler les problèmes avant qu'ils n'aient des répercussions négatives sur les opérations commerciales.

La liste des modèles et anti-modèles montre à quoi ressemble l'architecture pour une surveillance et des alertes efficaces dans une solution Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou pour identifier les zones de votre système qui doivent être refactorisées.

Pour plus d'informations sur les outils Salesforce de surveillance et d'alerte, consultez Outils Salesforce pour la résilience.

Le tableau ci-dessous présente une sélection de modèles à rechercher ou à élaborer dans votre organisation, ainsi que des anti-modèles à éviter ou à cibler.

✨ Découvrez d'autres modèles de réponse aux incidents dans l'Explorateur de modèle et anti-modèle.

La planification de la continuité est un élément clé de la résilience de l'entreprise, qui met l'accent sur la façon de permettre aux personnes et aux systèmes de fonctionner à travers les problèmes causés par un événement imprévu. Les plans de continuité des activités (PCA) adoptent une vision orientée vers les personnes pour faire avancer les processus pendant les crises. Les aspects techniques de la planification de la continuité sont inclus dans les parties Reprise après sinistre d'un PCA. Consultez Continuité technologique.

Sans plans de continuité adéquats, votre organisation peut désormais savoir comment agir, et donc ne pas agir du tout, en cas de crise ou de panne du système. Une planification de continuité inefficace peut avoir un impact catastrophique sur les clients, les parties prenantes et l'entreprise. À la suite d'un événement indésirable, chaque instant qui passe sans maintenir ou récupérer des processus critiques risque de causer des dommages financiers, des dommages à la réputation, à la sécurité des employés et même à la conformité réglementaire.

Vous pouvez améliorer la planification de la continuité dans vos systèmes en concentrant vos efforts sur trois domaines : la définition de la continuité opérationnelle pour Salesforce, la planification de la continuité technologique et le renforcement des capacités de sauvegarde et de restauration.

Votre entreprise a peut-être déjà mis en place un PCA. Dans ce cas, assurez-vous que Salesforce y est inclus. Si votre entreprise n'a pas de PCA, créez avec vos parties prenantes un PCA qui couvre vos organisations Salesforce.

Salesforce est souvent considéré comme une source de vérité pour les données clients et les processus métiers essentiels dans de nombreuses divisions commerciales. Ainsi, le rôle joué par Salesforce dans un PCA peut différer de celui des autres systèmes. Il est probable que Salesforce intervienne dans de nombreux domaines prioritaires pour la récupération.

Pour créer une planification de la continuité des opérations pertinente pour les systèmes Salesforce :

• Clarifier les priorités de relèvement Comme dans le cas de l'approche générale de l'intervention en cas d'incident, le relèvement doit être la priorité absolue des systèmes en période de crise. De nombreux services critiques sont exécutés dans et avec Salesforce. Vous devez aider les parties prenantes à identifier la priorité correcte pour récupérer diverses fonctions et capacités métiers. Un cadre général pourrait être :
  • Stabiliser l'infrastructure commerciale essentielle.
  • Stabiliser les services clients.
  • Stabiliser les services des employés et des partenaires.
• Comptabilisez votre écosystème dans vos PCA. Salesforce n'est pas le seul système dans votre paysage. Assurez-vous d'identifier les écarts dans votre PCA autour des systèmes qui s'intègrent à Salesforce, des solutions installées par des fournisseurs AppExchange et de tout autre système qui se connecte à des données ou des processus dans Salesforce. Si votre capacité à livrer dépend des fournisseurs, demandez-leur leurs plans de continuité. Évaluez leurs capacités et planifiez la disponibilité de vos systèmes.
• Intégrez les préoccupations de PCA à votre stratégie de test. Créez des plans de test pour votre PCA et réalisez-les. Il est particulièrement important de tester les zones de votre PCA associées aux processus ou aux personnes, qui sont souvent négligées. Incorporez les éléments pertinents de votre PCA à votre stratégie de test ALM globale. Créez et suivez une planification de maintenance pour réviser les tests et vous assurer que votre plan reste à jour.

Les modèles et anti-modèles de planification montrent à quoi ressemble une planification de continuité correcte et médiocre dans une solution Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou pour identifier les emplacements de votre système qui doivent être refactorisés.

Pour plus d'informations sur les outils Salesforce pour définir la continuité des activités, consultez Outils Salesforce pour la résilience.

L'objectif de la continuité technologique est de s'assurer que les problèmes de composants dans un système n'empêchent pas l'entreprise de maintenir les opérations essentielles. Salesforce accorde la priorité au maintien de nos services au niveau de disponibilité le plus élevé et fournit des informations transparentes sur tout problème. Vous pouvez consulter sur trust.salesforce.com des informations en temps réel sur les performances et les problèmes du système Salesforce. En tant qu'architecte s'appuyant sur Salesforce, vos solutions bénéficient des capacités de fiabilité, de sécurité et de performance du site que Salesforce fournit sur l'ensemble de la plate-forme.

Cependant, la continuité globale de vos solutions Salesforce va au-delà des services intégrés que Salesforce fournit. D'un point de vue architectural, la planification de la continuité technologique de Salesforce doit commencer par poser et répondre à des questions sur la façon dont Salesforce s'intègre dans votre paysage d'entreprise plus large. Quels types de système s'intègrent à Salesforce ? Comment les systèmes externes dépendent-ils des processus ou des informations dans Salesforce ? Dans vos organisations Salesforce, quels processus ou fonctionnalités s'appuient sur les solutions AppExchange ? Vos utilisateurs accèdent-ils à Salesforce via des services d'identité tiers ou l'authentification unique ?

Pour améliorer la continuité technologique dans vos systèmes Salesforce :

• Évaluez votre infrastructure. La stratégie de réparation la plus courante pour les pannes ou les problèmes technologiques consiste à élaborer des services ou des systèmes redondants auxquels vous pouvez vous rabattre en cas d'incident. Chez Salesforce, nous avons une architecture volontairement redondante, ce qui signifie que nous conservons des copies des systèmes et des services de nos clients à différents emplacements physiques. Nous utilisons plusieurs techniques de reprise après sinistre, notamment le basculement de site, qui nous permet d'orienter le trafic utilisateur d'un centre de données à un autre si nécessaire. Pour identifier où il peut être nécessaire d'élaborer une redondance intentionnelle, posez-vous les questions ci-dessous.
  • Que se passe-t-il pendant une interruption du service [X] ? Pouvons-nous basculer de ce service à un autre ?
  • Combien de temps faut-il pour récupérer [X] ? Quel est l'impact pour nos clients ? Quel est l'impact pour nos partenaires ? Quel est l'impact pour les équipes internes ?
  • Qu'en est-il des sauvegardes et de leur fréquence ? Les sauvegardes peuvent-elles fournir les données nécessaires pour soutenir l'entreprise ?
  • Avons-nous des dépendances vis-à-vis des fournisseurs ? Quels sont leurs plans de PCA ?
• Apporter un soutien opérationnel. Le support opérationnel consiste à remettre en route les équipes le plus rapidement possible. Réfléchissez à la façon dont votre système peut gérer les augmentations significatives des exigences en capacité et la demande résultant de changements imprévus, y compris des changements à l'échelle de l'industrie, de la région ou mondiale. Assurez-vous que votre PCA tient compte des ressources supplémentaires ou des procédures de bris de verre dont l'ingénierie de la fiabilité du site (SRE) ou les équipes de support peuvent avoir besoin pour réagir efficacement aux incidents. Les questions à poser au sujet du soutien opérationnel comprennent :
  • En cas de panne, nos équipes techniques disposeraient-elles des outils nécessaires pour poursuivre leur travail ? Avons-nous simulé une panne pour valider des plans ou identifier des écarts ?
  • Si une catastrophe se produit dans une zone spécifique, avons-nous des plans de couverture pour cette zone?
  • Nos clients sont-ils mondiaux ? Fonctionnent-ils 24/7 ?
  • Avons-nous une surveillance et une alerte appropriées pour aviser les personnes appropriées en cas de défaillance?
• Automatisez et testez vos tactiques de récupération. Lorsqu'un problème est corrigé, identifiez son emplacement et comment il a été corrigé. Si possible, en fonction de la correction, automatisez vos tactiques de récupération et ajustez les problèmes de processus. De nombreuses entreprises planifient des simulations d'incident pour un sous-ensemble de services afin de tester la résilience du système. Par exemple, simuler un compte d'administrateur système verrouillé ou compromis, ou simuler une panne ou un problème avec un fournisseur AppExchange. Consultez Réaction aux incidents.)Les questions à poser sur la façon dont les tests et l'automatisation peuvent accélérer la restauration des services comprennent :
  • À quelle fréquence planifions-nous et exécutons-nous des simulations d'incident ?
  • Sait-on combien de temps il faut pour rétablir un état stable des services?
  • Avons-nous mis en place des processus de livraison stables?
  • Savons-nous où nous pouvons automatiser le basculement et la récupération ?

Traitez tous les éléments issus de vos examens postérieurs à l'incident comme vos autres éléments de développement. Ajoutez-les à vos systèmes de planification pour pouvoir les prioriser et les utiliser.

Les modèles et anti-modèles de planification montrent à quoi ressemble une planification de continuité technologique correcte et médiocre dans une solution Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou pour identifier les emplacements de votre système qui doivent être refactorisés.

Pour plus d'informations sur les outils Salesforce pour la planification de la continuité technologique, consultez Outils Salesforce pour la résilience.

La restauration de copies sauvegardées de données ou de métadonnées peut aider à rétablir votre organisation dans son dernier état stable connu. Il peut également fournir un système de basculement lors d'une panne système catastrophique ou d'une interruption de service. La sauvegarde régulière de vos données et métadonnées et le stockage de vos copies cryptées et sauvegardées à un emplacement sécurisé ajoutent une couche de résilience supplémentaire à votre architecture.

Sans stratégies de sauvegarde et de restauration, vous ne pouvez pas restaurer des versions propres de vos données et métadonnées de production lorsqu'elles sont corrompues par des actes malveillants, lorsque des défauts sont involontairement introduits en production ou lorsqu'une défaillance pendant un chargement de données volumineux corrompt les données de production. L'un de ces scénarios peut entraîner la corruption ou même la perte définitive de vos données de production critiques. La mise en place d'une technologie de sauvegarde et de restauration offre plusieurs avantages en plus de la planification de la continuité, notamment l'aide aux stratégies de réduction des volumes de données importants et le respect des politiques de rétention liées à la conformité.

Pour garantir la continuité des stratégies de sauvegarde et de restauration dans vos solutions Salesforce :

• Commence. La première étape pour avoir une bonne stratégie de sauvegarde et de restauration est d'avoir une stratégie en premier lieu. Même une opération aussi simple que la sauvegarde nocturne de toutes les données et métadonnées de votre organisation peut éviter à votre entreprise de perdre des informations ou des fonctionnalités critiques en cas de sinistre.
• Limitez l'accès aux sauvegardes. Les administrateurs système sont les seuls utilisateurs qui doivent avoir accès à des copies sauvegardées de vos données. Cette restriction d'accès empêche un utilisateur professionnel d'afficher des enregistrements dans une copie de sauvegarde qu'il n'est pas autorisé à afficher dans votre organisation.
• Testez régulièrement votre processus de restauration. Quelle que soit la stratégie de sauvegarde et de restauration que vous implémentez, testez régulièrement votre processus de restauration dans une organisation sandbox Full ou Partial Copy pour vous assurer qu'il fonctionnera correctement lorsque vous en aurez besoin.
• Alignez votre stratégie de sauvegarde et de restauration sur votre stratégie d'archivage de données. Déterminez ce qui doit se passer dans vos sauvegardes ou archives lorsque des enregistrements sont archivés ou purgés de votre système. Consultez Volume de données).

Une stratégie de sauvegarde plus précise peut s'avérer nécessaire si vos volumes de données sont si importants qu'une sauvegarde complète n'a pas le temps de se terminer avant le début de l'exécution de la sauvegarde suivante. Une stratégie de sauvegarde plus précise peut également être nécessaire si les données de votre organisation changent si souvent que les mises à jour sont essentielles à votre organisation.

Pour rendre votre stratégie de sauvegarde plus précise :

• Étendez vos sauvegardes à des objets spécifiques. Cette stratégie implique de sauvegarder les enregistrements de différents objets à différents intervalles de temps. Notez que les objets enfants doivent être sauvegardés aux mêmes intervalles que leurs parents pour préserver la cohérence des données.
• Sauvegardes partielles de la case horaire. Cette stratégie consiste à différencier les sauvegardes complètes (de toutes les données et métadonnées) et partielles (uniquement des métadonnées et des enregistrements ajoutés ou modifiés depuis la dernière sauvegarde).

* N'arrêtez jamais d'effectuer des sauvegardes complètes. Il est important de noter que vous ne devez jamais éliminer complètement les sauvegardes complètes, même si les volumes de données entraînent de longues durées d'exécution. Pour des volumes de données importants, planifiez des sauvegardes complètes régulières mais peu fréquentes (par exemple, des sauvegardes hebdomadaires). Prévoyez également des sauvegardes partielles ou spécifiques à un objet plus fréquentes (par exemple, des sauvegardes nocturnes ou des sauvegardes toutes les X heures). Cette approche offre la flexibilité nécessaire pour reconstruire le jeu de données le plus complet et le plus précis à utiliser dans vos processus de restauration.*

Les modèles et anti-modèles de planification montrent à quoi ressemblent les capacités de sauvegarde et de restauration correctes et médiocres dans une solution Salesforce. Utilisez-les pour valider vos conceptions avant de les élaborer ou pour identifier les emplacements de votre système qui doivent être refactorisés.

Salesforce Backup and Recover, une solution Salesforce intégrée qui inclut Own Recover from the Own acquisition, protège les données importantes contre la perte ou la corruption. Notre solution hautement sécurisée, facile à configurer et toujours disponible garantit la continuité des activités et la résilience des données, et simplifie la conformité.

Utilisez Sauvegarde et restauration Salesforce pour éviter la perte de données, récupérer rapidement après des incidents de données et simplifier votre stratégie globale de gestion des données. Vous pouvez créer des stratégies de sauvegarde pour des données importantes et réglementées, et restaurer ces données en quelques clics seulement.

Les sauvegardes quotidiennes automatisées protègent toutes les données cruciales de votre organisation, notamment les métadonnées, les sandbox, les données de packages gérés, les pièces jointes, et davantage. Exécutez des sauvegardes aussi souvent que nécessaire pour atteindre vos objectifs de point de récupération (RPO) et protéger vos déploiements. Les sauvegardes sont toujours accessibles et stockées de façon sécurisée et conforme. La protection continue des données est également disponible pour des données encore plus confidentielles ou transactionnelles, ce qui accélère la récupération d'informations critiques en évolution rapide.

Détectez les activités de données inhabituelles, la perte de données et la corruption avec des alertes proactives envoyées directement par e-mail. Recevez des alertes en temps réel pour identifier des valeurs statistiques aberrantes ou créer des règles qui vous informent de l'activité inhabituelle des données, ce qui vous aide à détecter les incidents plus rapidement que jamais.

Salesforce Backup and Recover accélère la récupération en offrant une visibilité précise sur les modifications, ce qui permet d'identifier et de restaurer rapidement les données affectées. Des outils tels que des graphiques visuels mettent en évidence les modifications indésirables, tandis que des fonctionnalités de récupération faciles à utiliser restaurent avec précision les objets, les champs et les enregistrements affectés.

Nos outils permettent d'utiliser des sauvegardes pour les analytiques, les audits et la conformité, en offrant des données historiques recherchables, une fonctionnalité de recherche ouverte pour la visibilité des données passées et des capacités d'exportation pour les analytiques externes ou l'entreposage. Cela permet de redéfinir les sauvegardes sans avoir besoin d'API Salesforce supplémentaires.

Backup and Recover offre une console unique pour consolider toutes les sauvegardes, la gestion, les opérations et la conformité. Cette console permet d'accéder à, de gérer, de personnaliser et de surveiller les sauvegardes de toutes vos organisations de production et sandbox. Il permet également d'exécuter des requêtes de la personne concernée pour garantir la conformité des données de sauvegarde, et de contrôler entièrement la personnalisation des planifications de sauvegarde, de la fréquence et des stratégies de rétention.

• Atténuer l'impact des incidents de données. Salesforce Backup and Recover permet d'atténuer les incidents de données, tels que les cyberattaques ou les activités internes ou externes malveillantes, en permettant aux utilisateurs de restaurer l'état des enregistrements affectés avant l'incident. La fonctionnalité d'exportation de Backup and Recover garantit un accès continu aux données critiques des utilisateurs et leur utilisation.
• Évitez la perte permanente de données. L'erreur humaine reste la principale cause de perte de données. Backup and& Recover offre une solution précise et rapide à ces erreurs.
• Satisfaire plus facilement aux exigences légales et de conformité des données. Salesforce Backup and Recover prend en charge le modèle de responsabilité partagée, ce qui active la fonctionnalité en libre-service pour les oublis en masse ou la rectification des données dans vos données de sauvegarde.

Pour plus d'informations sur les outils Salesforce de sauvegarde et de restauration, consultez Outils Salesforce pour la résilience.

Le tableau ci-dessous présente une sélection de modèles à rechercher ou à élaborer dans votre organisation, ainsi que des anti-modèles à éviter ou à cibler.

✨ Découvrez d'autres modèles de planification de la continuité dans l'Explorateur de modèle et anti-modèle.

Aidez-nous à garder Salesforce Well-Architected pertinent pour vous ; répondez à notre sondage pour nous faire part de vos commentaires sur ce contenu et nous dire ce que vous souhaitez voir ensuite.