Fiabilité - Modèles de reprise après sinistre | Modèles |

Fiabilité - Modèles de reprise après sinistre

En savoir plus sur la fiabilité bien archivée → Reprise après sinistre et continuité des activités

Modèles

Où chercher	À quoi ressemble le bien
Stratégie de sauvegarde des données	✅ Exportations automatisées hebdomadaires ou mensuelles en utilisant le Service d’exportation de données ou un service de sauvegarde et de restauration dédié (tel que Own). La fréquence d’exportation correspond aux exigences de l’OPR. Données d’objets critiques exportées vers le stockage d’objets externes, si nécessaire.
Stratégie de sauvegarde des métadonnées	✅ Toutes les métadonnées versionnées dans Git en utilisant le format source Salesforce DX Modifications des métadonnées déployées uniquement depuis le contrôle source. Le pipeline CI/CD peut recréer n’importe quel environnement à partir du référentiel. Récupération ponctuelle disponible via l’historique Git.
Stratégie de sauvegarde de fichiers	✅ Enregistrements ContentVersion, pièces jointes et documents exportés vers un stockage externe à la date prévue. Exportation automatique de fichiers pour les exigences réglementaires de rétention. Système d’archivage externe pour les fichiers plus anciens que les besoins opérationnels de l’entreprise.
Validation de sauvegarde	✅ Exercices de restauration trimestriels dans des environnements Sandbox Full ou Developer. Restaurez les procédures documentées dans les runbooks avec des instructions pas à pas. La restauration test valide l’intégrité et l’intégralité de la sauvegarde avant les catastrophes.
Planification des tests de récupération	✅ Tests de restauration partielle trimestriels (métadonnées, objets spécifiques, sous-ensembles de fichiers). Forage annuel de récupération complète avec restauration complète de l’environnement. Leçons apprises documentées et runbooks mis à jour après chaque test.
Service de sauvegarde tiers	✅ Sauvegarde automatisée avec la capacité de restauration ponctuelle. Accord de niveau de service définissant RPO/RTO. Vérification automatisée quotidienne de la réalisation de la sauvegarde. Redondance géographique avec des sauvegardes stockées dans plusieurs régions.
Objets et champs personnalisés	✅ Objets personnalisés inclus dans les exécutions planifiées de Service d’exportation de données, avec des valeurs de champ récapitulatif de formule et de cumul recalculées plutôt qu’exportées (aucune valeur stockée n’existe à extraire) et des binaires de fichier ou de pièce jointe traités via un chemin d’exportation séparé. Types de champ complexes et relations de référence documentés et testés dans la séquence de restauration.
Fichiers et pièces jointes	✅ Objets ContentDocument et ContentVersion exportés avec des fichiers binaires. Bibliothèques de documents sauvegardées, y compris les structures et les autorisations de dossier. Les fichiers exportés conservent l’historique des versions des types de document critiques.
Stratégie d’actualisation des sandbox	✅ Organisation de production actualisée en Sandbox Full trimestriellement pour les tests de charge et la validation de la reprise après sinistre. Actualisation sandbox utilisée comme test de procédure de restauration. Masquage des données appliqué après l’actualisation pour protéger les données confidentielles dans les environnements de test.
Surveillance et alerte de sauvegarde	✅ Alertes automatisées lorsque les sauvegardes planifiées échouent ou sont retardées. Tableau de bord montrant le taux de réussite des tâches de sauvegarde, le temps de réalisation et les tendances du volume de données. Escalade à l’astreinte en cas d’échec de sauvegarde dépassant la période de délai acceptable.

Anti-modèles

Où chercher	À quoi ressemble mal
Stratégie de sauvegarde	⚠️ Aucune sauvegarde automatisée configurée, s’appuyant uniquement sur les sauvegardes de l’infrastructure de la plate-forme. Service de sauvegarde tiers configuré, mais jamais testé - les sauvegardes peuvent être corrompues ou incomplètes. Exportations manuelles de Data Loader pour les sauvegardes (exécution incohérente, couverture incomplète, pas d’automatisation).
Gestion des versions des métadonnées	⚠️ Modifications des métadonnées déployées via des ensembles de modifications sans contrôle source. Aucun référentiel Git pour l’historique des métadonnées. Restauration ponctuelle impossible - impossible de restaurer la configuration last-known-good après des modifications destructrices.
Validation de sauvegarde	⚠️ Sauvegardes configurées mais jamais restaurées dans l’environnement test. La première tentative de restauration se produit lors d’un véritable désastre révélant une portée incomplète ou des archives corrompues. Procédures de sauvegarde documentées, mais pas testées par le personnel de secours.
Étendue de sauvegarde	⚠️ En supposant que le Service d’exportation de données capture tout lorsque les valeurs de champ récapitulatif de formule et de cumul ne sont jamais exportées (recalculées dynamiquement, non stockées) et que les binaires de fichiers ou de pièces jointes nécessitent un traitement séparé, laissant les écarts découverts uniquement lors de la restauration.
Procédures de récupération	⚠️ Le runbook Recovery contient des étapes obsolètes de l’architecture de 2 ans. Procédures de récupération testées par un expert unique qui a quitté l’entreprise depuis. Des procédures manuelles si complexes que l’exécution sous tension est sujette à des erreurs.
Fréquence de sauvegarde	⚠️ Données de transaction critiques sauvegardées chaque semaine lorsque l’exigence métier est RPO sur 24 heures. Fréquence de sauvegarde non alignée avec la criticité métier - même planification pour toutes les données, quelle que soit leur importance. Planification de sauvegarde manquée en raison d’un manque de surveillance et d’alerte.
Conformité réglementaire	⚠️ Conservation des sauvegardes plus courte que ne l’exige le règlement en vigueur. Par exemple, la documentation de conformité HIPAA (politiques, analyses de risque, accords de niveau de vie, enregistrements d’infraction) a été purgée avant sa conservation de six ans au titre de l’article 164.316, ou les enregistrements d’audit financier régis par SOX ont été supprimés avant leur conservation de sept ans. Déficit de conformité découvert pendant l’audit.
Stockage de fichiers	⚠️ Fichiers volumineux stockés dans Salesforce sans stratégie d’archivage. Le stockage de fichiers augmente jusqu’à ce que l’organisation approche la limite. Aucune sauvegarde des enregistrements ContentVersion - fichiers perdus si l’organisation est corrompue. S’appuyer sur les utilisateurs pour conserver des copies personnelles des fichiers critiques.
Test sandbox	⚠️ Sandbox Full jamais actualisé de production - environnement de test sauvagement différent de la production. Volume de données en sandbox 1% de la production empêchant une validation réaliste de la restauration. L’actualisation sandbox est traitée comme un désagrément plutôt que comme une opportunité de validation de la reprise après sinistre.
Surveillance	⚠️ Les tâches de sauvegarde échouent en silence sans alerte. Découvrez les échecs de sauvegarde quelques semaines plus tard en cas de sinistre. Aucun tableau de bord montrant les tendances de réussite des tâches de sauvegarde. L’intégrité du service de sauvegarde est surveillée uniquement lorsque la facture arrive.
Clés de cryptage	⚠️ Traitement des données cryptées Shield comme sûres sans protéger le matériel de clé : La rotation des clés seule laisse les données antérieures intactes, mais la destruction d’un secret locataire (crypto-shred) ou la perte de Bring Your Own Key ou du matériel de clé cache-only rend les données cryptées définitivement irrécupérables. La gestion des clés est omise des procédures de récupération.
Dépendances inter-organisations	⚠️ Sauvegarde seule de l’organisation principale lorsque la solution dépend d’applications connectées, d’intégrations externes ou de l’authentification unique : Les secrets d’application connectée, les autorisations d’identifiant nommé et OAuth, et les jetons d’authentification externes ne sont pas conservés par une restauration de données et de métadonnées, et doivent être reconfigurés et réautorisés avant qu’une organisation récupérée puisse s’authentifier à des systèmes externes. Lorsque l’authentification unique externe est le seul chemin de connexion, un fournisseur d’identité non disponible bloque la connexion, même dans une organisation entièrement restaurée.

Modèles

Où chercher	À quoi ressemble le bien
Définition de l’objectif de temps de récupération (RTO)	✅ RTO défini par capacité métier plutôt que uniforme dans toute l’organisation. Opérations critiques pour le revenu : minutes à 1 heure. Services accessibles aux clients : 1-4 heures. Outils internes : 4-24 heures. Rapports historiques : jours. RTO documentés avec l’approbation des parties prenantes commerciales.
Définition de l’objectif de point de récupération (RPO)	✅ RPO défini sur la base de la perte de données acceptable par capacité. Transactions financières : RPO quasi nul (secondes, réplication asynchrone pilotée par l’événement). Enregistrements client : proche de zéro (minutes via CDC). Données Analytics : heures (synchronisation planifiée). État de workflow temporaire : jours (aucune réplication requise).
Disponibilité et rôles de l’équipe	✅ Personnel principal et de relève documenté pour tous les rôles critiques. Pas de point d’échec unique en Knowledge opérationnelle. Arborescence d’escalade définissant l’intervenant principal, la première sauvegarde, la deuxième sauvegarde. Informations de contact conservées dans le système accessibles lorsque Salesforce n’est pas disponible.
Procédures de communication	✅ Plan de communication sur les incidents définissant qui notifie les utilisateurs, les clients, les dirigeants. Page de statut externe hébergée hors de Salesforce pour la communication des utilisateurs pendant les pannes de plate-forme. Système de notification par SMS pour l’équipe d’astreinte lorsque les principaux outils de communication ne sont pas disponibles. Périodes d’escalade documentées (quand escalader de l’équipe au responsable à la direction).
Mappage des dépendances des fournisseurs	✅ Tous les fournisseurs externes critiques documentés, y compris Salesforce, les partenaires d’intégration, les fournisseurs de packages ISV. Accords de niveau de service fournisseurs et fenêtres de support documentés (24/7 vs heures ouvrables uniquement). Contacts et procédures d’escalade des fournisseurs documentés. Options de fournisseur alternatives identifiées pour les dépendances critiques.
Obligations réglementaires de notification	✅ Exigences obligatoires de notification des incidents documentées par secteur d’activité (services financiers, santé, gouvernement). Des délais de notification définis pour correspondre à la période requise de chaque règlement. Matrice de responsabilité définissant qui dépose les notifications auprès de quels organismes de réglementation. Modèles préparés pour une notification réglementaire rapide.
Analyse de l’impact commercial	✅ Chaque capacité métier classée par impact sur le chiffre d’affaires, impact utilisateur et risque réglementaire. Priorisation de la reprise basée sur le classement de l’impact métier. Ressources allouées à la reprise après sinistre proportionnelles à la criticité métier. Analyse d’impact revue chaque année à mesure que les priorités métiers évoluent.

Anti-modèles

Où chercher	À quoi ressemble mal
Définition RTO/RPO	⚠️ « Le système devrait être fiable » sans objectifs RTO/RPO mesurables. RTO/RPO défini par l’équipe TI sans contribution des parties prenantes commerciales. Cibles uniformes entre toutes les capacités en ignorant les différences de criticité (« tout nécessite un temps de fonctionnement de 99,999 % »).
Préparation de l’équipe	⚠️ Un seul administrateur Salesforce connaît les procédures de reprise après sinistre sans documentation ni personnel de secours. La rotation sous astreinte comprend le personnel qui n’a jamais exécuté de procédure de recouvrement. Intervenants principaux non disponibles en cas de sinistre (vacances, maladie, compagnie qui quitte).
Planification de la communication	⚠️ Aucun plan de communication - découvrir la nécessité de notifier les utilisateurs après un incident déjà en cours. Page de statut hébergée dans Salesforce elle-même non disponible pendant une panne Salesforce. Heures d’attente pour notifier les dirigeants en tentant la récupération.
Dépendances des fournisseurs	⚠️ Ignorant les conditions d’accord de niveau de service du fournisseur jusqu’à la catastrophe et attendant un support 24/7 de la part du fournisseur avec une couverture en heures ouvrables seulement. Aucun contact d’escalade de fournisseur documenté. Fournisseur de package ISV requis pour la récupération, mais l’entreprise n’est plus en activité.
Exigences réglementaires	⚠️ Inconscient des lois sur les notifications d’infraction obligatoires. Découvrez l’exigence de notification sur 24 heures après 48 heures. Aucun modèle n’est préparé - rédiger des notifications réglementaires pendant la réponse à un incident pendant que le compte à rebours de la conformité est enclenché.
Priorisation de la récupération	⚠️ Tenter de restaurer toutes les capacités simultanément en cas de catastrophe au lieu de prioriser les opérations critiques pour le revenu. Consacrer 8 heures à récupérer la capacité de génération de rapports internes avant de traiter le système de commande accessible aux clients.
Tests et exercices	⚠️ Plan de continuité d’activité jamais testé par des exercices. Supposons que les procédures documentées fonctionneront sous tension sans validation. Exercices sur table évités en raison du « manque de temps » malgré les jours passés à récupérer de problèmes non découverts lors de catastrophes réelles.
Transfert de Knowledge	⚠️ Disaster recovery Knowledge concentré dans un architecte principal qui n’a rien documenté. Les nouveaux membres de l’équipe sont intégrés sans formation à la reprise après sinistre. Supposons que tout le monde sait quoi faire en cas de catastrophe sans entraînement explicite ni exercices.
Validation des hypothèses	⚠️ Les procédures de récupération supposent une sauvegarde accessible sous 15 minutes mais la récupération de sauvegarde depuis une chambre froide prend 8 heures. En supposant que l’équipe est disponible sous 30 minutes, mais aucune procédure de rotation ou d’escalade d’astreinte n’est définie. Des estimations de temps de récupération basées sur des hypothèses optimistes jamais validées par des tests.

Modèles

Où chercher	À quoi ressemble le bien
Alignement architectural RTO	✅ Les décisions d’architecture correspondent aux engagements du RTO. Minutes RTO nécessite un basculement automatisé et une veille à chaud. Heures RTO nécessite une récupération scriptée et une veille chaude. Days RTO accepte la récupération manuelle de la sauvegarde à froid. Suringénierie évitée lorsque l’entreprise ne justifie pas la complexité.
Stratégie de réplication RPO	✅ La méthode de réplication correspond à la cible RPO. RPO quasi nul : diffusion d’événements asynchrones via des événements de plate-forme à chaque enregistrement enregistré (secondes de décalage de propagation, livraison au moins une fois). Minutes RPO : Réplication asynchrone Capture de données Change. Heures RPO : extraction d’API par lot planifiée. Jours RPO : sauvegarde manuelle à une fréquence fixe.
Test RTO	✅ Procédures de récupération testées dans des conditions temporelles. RTO réel mesuré pendant les exercices de reprise après sinistre. Écarts entre le RTO cible et le RTO atteint identifiés et corrigés. RTO réalisable par le personnel de secours, pas seulement les experts principaux.
Validation RPO	✅ Perte de données mesurée pendant les tests de récupération. RPO réel par rapport à la cible pendant les exercices. Délai de réplication surveillé en continu en production. Alertes configurées lorsque la réplication est en retard sur l’engagement du RPO.
RTO/RPO spécifique à la capacité	✅ Différentes capacités métiers ont différents objectifs RTO/RPO reflétant la criticité métier. Flux de commande E-commerce : RTO de 15 minutes, RPO quasi nul (justifie multi-organisation active-passive). Base de Knowledge interne : RTO 8 heures, RPO 24 heures (justifie la restauration manuelle à partir de la sauvegarde).
Analyse coûts-avantages	✅ Objectifs RTO/RPO équilibrés par rapport au coût d’implémentation. Des objectifs plus stricts nécessitent une augmentation exponentielle des investissements. Analyse de rentabilisation documentée montrant le coût des temps d’arrêt justifiant un investissement en reprise après sinistre. L’examen annuel confirme l’alignement continu entre l’investissement et la valeur commerciale.
Alignement SLA	✅ Les objectifs de RTO/RPO de solution prennent en compte la base de SLA de la plate-forme. La solution ne peut que fournir un RTO supérieur à la base de la plate-forme avec une architecture multi-organisations. Objectifs réalistes définis en considérant les capacités de la plate-forme comme fondement.
Surveillance des capacités de récupération	✅ Surveillance continue de la devise de sauvegarde (ancienneté de sauvegarde par rapport à l’objectif RPO). Alerte lorsque la sauvegarde prend du retard. Validation automatisée de l’infrastructure de récupération (organisation secondaire, stockage externe) opérationnelle.
Récupération automatisée et manuelle	✅ Les objectifs RTO agressifs (minutes) nécessitent un basculement automatisé avec une intervention humaine minimale. Les objectifs RTO modérés (heures) permettent une récupération scriptée avec l’initiation humaine. Les objectifs RTO relâchés (jours) acceptent la récupération manuelle en suivant des procédures documentées.

Anti-modèles

Où chercher	À quoi ressemble mal
Objectifs irréalistes	⚠️ S’engager à effectuer un RTO de 15 minutes avec des procédures de récupération manuelles nécessitant 4 heures d’exécution. Promettant un RPO zéro sans infrastructure de réplication synchrone. Objectifs RTO définis par l’informatique sans support architectural.
Désalignement de l’architecture	⚠️ Engagement RTO de 30 minutes mais aucune procédure de basculement et de reprise automatisée n’est entièrement manuelle. Aucun engagement RPO mais uniquement des sauvegardes quotidiennes configurées. Des objectifs agressifs sans investissement correspondant en automatisation et redondance.
Objectifs non testés	⚠️ RTO jamais validé par des exercices de reprise après sinistre chronométrés. En supposant un RTO de 2 heures réalisable, mais jamais de restauration réelle sous des contraintes de temps. Découvrir lors d’une catastrophe réelle que le RTO de 4 heures documenté nécessite en fait 18 heures.
Objectifs uniformes	⚠️ Toutes les capacités attribuées au même RTO/RPO, quelle que soit la criticité métier. Système interne de génération de rapports par lot conçu pour la disponibilité des cinq-neufs alors que le commerce électronique critique pour le revenu a la même cible. Surinvestissement massif dans les capacités non critiques et sous-investissement dans les systèmes critiques.
Ignorer les dépendances	⚠️ RTO suppose la restauration de l’organisation Salesforce uniquement, mais la solution dépend du fournisseur d’identité externe également non disponible. RPO suppose que la sauvegarde des données est suffisante, mais les identifiants d’intégration et la configuration ne sont pas sauvegardés. Les estimations de temps de récupération ignorent le temps nécessaire pour restaurer les systèmes dépendants.
Lacunes de réplication	⚠️ Engagement sur RPO de 15 minutes mais Capture des données de modification configuré pour seulement 3 des 12 objets critiques. Réplication d’événement de plate-forme configurée, mais pas de surveillance du délai de livraison des événements. L’infrastructure de réplication se rompt et passe inaperçue pendant des semaines jusqu’au désastre.
Méconnaissance des coûts	⚠️ S’engager sur la disponibilité des cinq-neuf sans comprendre le coût d’implémentation. Objectifs RTO/RPO définis sans analyse coûts-avantages. Entreprise peu disposée à financer l’infrastructure requise pour les objectifs déjà engagés envers les clients.
Objectifs statiques	⚠️ RTO/RPO défini il y a 5 ans jamais réévalué malgré la croissance de l’entreprise et l’évolution des priorités. Les objectifs restent inchangés à mesure que la solution évolue et que la criticité change. Processus d’examen annuel absent.
Lacunes dans la documentation	⚠️ Objectifs RTO/RPO documentés dans le document d’architecture, mais pas communiqués aux parties prenantes de l’entreprise. Entreprise ignorant les capacités de récupération engagées. Écart découvert lorsque l’entreprise s’attend à une récupération d’une heure, mais que l’architecture prend en charge uniquement le RTO sur 24 heures.
Fausse précision	⚠️ S’engager à « 99,97 % de disponibilité » lorsque la surveillance de l’infrastructure ne peut pas mesurer avec cette précision. Cibles définies avec une fausse précision suggérant une rigueur lorsque l’analyse sous-jacente est une estimation approximative.
Absence de surveillance	⚠️ Aucune surveillance continue des capacités de récupération. La sauvegarde prend 2 jours de retard en violation de l’engagement du RPO, mais aucune alerte. Organisation secondaire dans une architecture active-passive ne recevant pas de mises à jour de réplication, mais contrôles d’intégrité non configurés.
Planification sans exécution	⚠️ Beau plan de reprise après sinistre avec des objectifs RTO/RPO agressifs mais sans automatisation, test, ni procédures validées. Case à cocher Plan créé pour satisfaire la conformité, mais aucune réalité opérationnelle derrière les engagements.

Modèles

Où chercher	À quoi ressemble le bien
Redondance des données	✅ La plate-forme fournit automatiquement une sauvegarde de l’infrastructure. La réplication au niveau de l’application complète la sauvegarde de la plate-forme lorsque l’entreprise nécessite une récupération plus rapide. Capture des données de modification ou Événements de plate-forme répliquent des données critiques dans un stockage secondaire en continu. La réplication permet de récupérer les erreurs de corruption logique ou de configuration que les sauvegardes d’infrastructure ne peuvent pas résoudre.
Redondance de l’application	✅ Logique d’application sans état qui survit aux échecs de transaction individuels. Aucun état côté serveur n’empêche l’échelle horizontale. Les types de métadonnées personnalisées et les paramètres personnalisés de configuration sont instantanément disponibles dans tous les serveurs d’application. N’importe quel serveur d’application peut traiter n’importe quelle requête sans dépendre de l’état spécifique du serveur.
Redondance de l’intégration	✅ Les modèles de disjoncteur détectent les intégrations défaillantes. Les événements de plate-forme mettent en file d’attente les requêtes lorsque les systèmes externes ne sont pas disponibles plutôt que de bloquer les opérations des utilisateurs. Pannes système externes isolées de la fonctionnalité accessible aux utilisateurs. Plusieurs options de fournisseur externe identifiées pour les intégrations critiques permettant un changement rapide de fournisseur en cas de panne.
Modèles multi-organisations pour les charges de travail critiques	✅ Modèle actif-passif: L’organisation principale sert tout le trafic, l’organisation secondaire synchronisée mais inactive, basculement pendant la panne de la région principale. Modèle actif-actif : les deux organisations servent le trafic de production en continu, les utilisateurs étant alloués par zone géographique ou unité commerciale. Multi-organisation justifié uniquement lorsque l’entreprise nécessite un RPO/RTO au-delà des capacités de la plate-forme.
Synchronisation des données multi-organisations	✅ La Capture des données de modification offre une réplication en temps quasi réel pour les données critiques (15 minutes RPO). Les événements de plate-forme fournissent un flux d’événements pour les transactions critiques (RPO quasi nul). Réplication planifiée de l’API de transfert en masse 2.0 pour des données de référence (RPO sur 24 heures acceptable). Stratégie de résolution des conflits définie pour actif-actif lorsque le même enregistrement est modifié dans les deux organisations.
Architecture active-passive multi-organisations	✅ L’organisation principale dans la région Est des États-Unis sert tout le trafic de production. Organisation secondaire en Europe synchronisée via CDC, mais inactive. L’acheminement DNS ou la couche d’authentification dirige les utilisateurs vers l’organisation active. Les contrôles d’intégrité automatisés déclenchent le basculement lorsque l’organisation principale n’est pas disponible pendant 10 minutes consécutives.
Architecture active-active multi-organisations	✅ Utilisateurs EMEA dans l’organisation Europe, utilisateurs AMER dans l’organisation US basés sur le champ de région du profil utilisateur. Réplication bidirectionnelle pour des données de référence partagées (comptes, produits). Les données régionales sont conservées dans les organisations respectives (commandes, requêtes). La résolution des conflits utilise last-write-wins avec une autorité régionale pour les données principales des clients.
Distribution géographique	✅ Les centres de données régionaux Hyperforce activent la distribution géographique. Déploiement sur une seule région avec une redondance gérée par la plate-forme suffisante pour une disponibilité de 99,9 %. Multi-organisations dans les régions prises en compte uniquement pour plus de 99,95 % des exigences ou des mandats de résidence de données réglementaires.
Redondance du système externe	✅ Les API externes critiques ont des points de terminaison principaux et de basculement. Le disjoncteur bascule vers le point de terminaison de basculement lorsque le primaire rencontre des pannes durables. Services externes avec redondance géographique préférés aux fournisseurs monorégion pour les intégrations critiques.
Surveillance de l’infrastructure	✅ Trust.salesforce.com surveillé via l’API status. Abonnez-vous aux notifications de statut spécifiques à l’instance. La solution répond dynamiquement à l’état d’intégrité de la plate-forme en réduisant la charge non critique pendant la dégradation. Le Centre d’échelle identifie les opérations nécessitant beaucoup de ressources avant qu’elles n’impactent la capacité de redondance.
Automatisation du basculement	✅ Basculement automatisé préféré à manuel pour les cibles RTO agressives. Des contrôles d’intégrité sont effectués toutes les 1 à 5 minutes pour détecter les échecs. La logique de décision de basculement évite les faux positifs (nécessite un échec durable, pas des erreurs transitoires). Annulation automatique si la destination de basculement est également insalubre.
Points de défaillance uniques	✅ L’examen de l’architecture identifie tous les points de défaillance uniques. Chaque SPOF identifié a fait l’objet d’une évaluation de l’impact commercial et du coût d’atténuation. Les SPOF à fort impact atténués par la redondance. Les SPOF à faible impact acceptés avec des procédures documentées d’acceptation et de recouvrement des risques.
Test des capacités de redondance	✅ Les exercices de basculement planifiés valident la logique de basculement automatisée. Systèmes de sauvegarde testés en charge (pas seulement en veille au chaud au ralenti). La capacité de l’organisation secondaire a validé la gestion de la charge de production pendant les tests actifs-passifs. Les enseignements tirés de chaque test améliorent l’automatisation et les procédures.

Anti-modèles

Où chercher	À quoi ressemble mal
Points de défaillance uniques	⚠️ La solution entière dépend d’une API externe unique sans solution de repli. Le fournisseur de domaine personnalisé est SPOF. En cas d’échec du fournisseur, les utilisateurs ne peuvent pas joindre Experience Cloud. Compte utilisateur d’intégration unique : si désactivé, toutes les intégrations échouent.
Redondance non testée	⚠️ Architecture active-passive multi-organisation configurée mais jamais testée. L’organisation secondaire n’est pas synchronisée, mais les contrôles d’intégrité ne sont pas configurés. La première tentative de basculement se produit lors d’un véritable désastre révélant une organisation secondaire corrompue ou non fonctionnelle.
Lacunes dans la synchronisation des données	⚠️ Multi-organisation active-passive avec réplication CDC configurée pour 5 objets critiques sur 30. Le basculement se produit, mais l’organisation secondaire manque 80 % des données requises. Surveillance du décalage de réplication absente - organisation secondaire en retard de 3 jours sur le principal, mais aucune alerte.
Fausse redondance	⚠️ En supposant une architecture multi-régions alors que les deux organisations hébergeaient réellement dans la même région Hyperforce. API externes « redondantes » qui utilisent en réalité le même fournisseur en amont. Plusieurs parcours d’intégration qui transitent tous par le même point d’échec unique.
Architecture Stateful	⚠️ La logique d’application dépend de l’état en mémoire empêchant l’échelle horizontale. Le serveur d’application unique contient tous les états de session utilisateur - le redémarrage du serveur déconnecte tous les utilisateurs. Les ressources statiques mises en cache dans la mémoire de l’application au lieu du cache de la plate-forme créent une incohérence entre les serveurs.
Aucun disjoncteur	⚠️ L’intégration externe échoue et chaque transaction attend l’expiration complète de 120 secondes. Tous les utilisateurs impactés lorsque le système externe unique n’est pas disponible. Aucune isolation contre les échecs - une intégration défaillante dégrade les performances de la plate-forme entière.
Basculement manuel uniquement	⚠️ Architecture multi-organisations avec uniquement des procédures de basculement manuelles. Nécessite une procédure de 2 heures pour initier le basculement lorsque l’activité est en panne. Contrôles d’intégrité automatisés non implémentés. La décision de basculement nécessite l’approbation de la direction pour retarder le recouvrement.
Échec de la planification de la capacité	⚠️ Organisation secondaire en architecture active-passive dimensionnée pour 20 % de la charge de production. Le basculement se produit, mais l’organisation secondaire ne peut pas gérer le trafic de production complet. Architecture active-active avec les deux organisations à 85 % de capacité ne laissant aucune redondance lorsqu’une organisation échoue.
Dérive de configuration	⚠️ Les organisations principales et secondaires divergent au fil du temps, car les déploiements ne sont pas synchronisés. Métadonnées déployées dans principal, mais pas secondaire. Le basculement révèle une organisation secondaire qui exécute une version de code vieille de 6 mois.
Suringénierie	⚠️ Architecture multi-organisations avec réplication active-active pour les outils d’administration internes utilisés par 5 personnes. La complexité opérationnelle des organisations multiples n’est pas justifiée par la criticité métier. Un objectif de disponibilité de 99.999% pour les rapports par lot acceptable à 99%.
Incompréhension géographique	⚠️ En supposant que Hyperforce « multi-région » fournit automatiquement des capacités multi-organisations. Ne pas comprendre qu’une seule organisation réside toujours dans une seule région et plusieurs régions nécessite plusieurs organisations. Redondance basée sur la géographie impossible avec l’architecture mono-organisation.
Couplage d’intégration	⚠️ Toutes les intégrations sont synchrones sans solution de repli asynchrone. L’indisponibilité du système externe bloque les opérations des utilisateurs. Aucun mécanisme de mise en file d’attente - les transactions échouent si le système externe est temporairement en panne. Les utilisateurs ne peuvent pas continuer lorsque la prise en charge de l’intégration n’est pas disponible.