Fiabilidad - Patrones de recuperación de desastres | Patrones |

Fiabilidad - Patrones de recuperación de desastres

Obtenga más información acerca de la fiabilidad bien arquitectónica → Recuperación de desastres y continuidad comercial

Patrones

Dónde buscar	Qué buen aspecto tiene
Estrategia de copia de seguridad de datos	✅ Exportaciones automatizadas semanales o mensuales utilizando Servicio de exportación de datos o un servicio de copia de seguridad y recuperación exclusivo (como Propio). La frecuencia de exportación coincide con los requisitos de RPO. Datos de objetos críticos exportados al almacenamiento de objetos externo donde sea necesario.
Estrategia de copia de seguridad de metadatos	✅ Todos los metadatos versionados en Git utilizando el formato de origen Salesforce DX. Cambios de metadatos implementados solo desde el control de origen. Las oportunidades en curso de CI/CD pueden recrear cualquier entorno desde el repositorio. Recuperación de punto en el tiempo disponible a través del historial de Git.
Estrategia de copia de seguridad de archivos	✅ Registros ContentVersion, archivos adjuntos y documentos exportados a almacenamiento externo según lo programado. Exportación de archivos automatizada para requisitos de retención reguladores. Sistema de archivo externo para archivos con una antigüedad superior a las necesidades operativas comerciales.
Validación de copia de seguridad	✅ Desgloses de restauración trimestral a entornos Sandbox completos o Developer. Restaure procedimientos documentados en libros de ejecución con instrucciones paso a paso. La restauración de prueba valida la integridad y exhaustividad de la copia de seguridad antes de que se produzcan desastres.
Programación de pruebas de recuperación	✅ Pruebas de restauración parcial trimestrales (metadatos, objetos específicos, subconjuntos de archivos). Simulacro de recuperación completa anual con restauración de entorno completa. Lecciones aprendidas documentadas y libros de ejecución actualizados después de cada prueba.
Servicio de copia de seguridad externo	✅ Copia de seguridad automatizada con capacidad de restauración de punto en el tiempo. Acuerdo a nivel de servicio que define RPO/RTO. Verificación automatizada diaria de la realización de copias de seguridad. Redundancia geográfica con copias de seguridad almacenadas en múltiples regiones.
Objetos y campos personalizados	✅ Objetos personalizados incluidos en ejecuciones de Servicio de exportación de datos programadas, con valores de campo de resumen y fórmula recalculados en vez de exportados (no existe ningún valor almacenado para extraer) y binarios de archivos o archivos adjuntos gestionados a través de una ruta de exportación separada. Tipos de campo complejos y relaciones de búsqueda documentadas y probadas en la secuencia de restauración.
Archivos y archivos adjuntos	✅ Objetos ContentDocument y ContentVersion exportados con archivos binarios. Se realizaron copias de seguridad de bibliotecas de documentos incluyendo estructuras de carpetas y permisos. Los archivos exportados mantienen el historial de versiones para tipos de documentos críticos.
Estrategia de actualización de sandbox	✅ Organización de producción actualizada a Sandbox completo trimestralmente para pruebas de carga y validación de recuperación de desastres. Actualización de sandbox utilizada como prueba de procedimiento de restauración. Enmascaramiento de datos aplicado después de la actualización para proteger datos confidenciales en entornos de prueba.
Supervisión y alerta de copias de seguridad	✅ Alertas automatizadas cuando fallan o se retrasan las copias de seguridad programadas. Panel que muestra el índice de éxito del trabajo de copia de seguridad, el tiempo de realización y las tendencias de volumen de datos. Distribución a petición para fallos de copia de seguridad que superan el plazo de retraso aceptable.

Antipatrones

Dónde buscar	Aspecto negativo
Estrategia de copia de seguridad	⚠️ No se configuró ninguna copia de seguridad automatizada, basándose solo en copias de seguridad de infraestructura de plataforma. Servicio de copia de seguridad externo configurado pero nunca probado: las copias de seguridad pueden estar dañadas o incompletas. Exportaciones manuales del Cargador de datos en las que se basan las copias de seguridad (ejecución incoherente, cobertura incompleta, sin automatización).
Versión de metadatos	⚠️ Cambios de metadatos implementados a través de Conjuntos de cambios sin control de origen. Sin repositorio Git para el historial de metadatos. La recuperación de punto en el tiempo imposible: no puede restaurar la última configuración conocida-buena después de cambios destructivos.
Validación de copia de seguridad	⚠️ Copias de seguridad configuradas pero nunca restauradas en entorno de prueba. El primer intento de restauración se produce durante un desastre real que revela un ámbito incompleto o archivos dañados. Procedimientos de copia de seguridad documentados pero no probados por el personal de copia de seguridad.
Ámbito de copia de seguridad	⚠️ Suponiendo que Servicio de exportación de datos captura todo cuando los valores de campo de resumen y fórmula nunca se exportan (se vuelven a calcular de forma dinámica, no se almacenan) y los binarios de archivos o archivos adjuntos requieren una gestión separada, dejando brechas descubiertas solo en la restauración.
Procedimientos de recuperación	⚠️ El libro de ejecución de recuperación contiene pasos desfasados de una arquitectura de 2 años. Procedimientos de recuperación probados por un único experto que ha abandonado la empresa desde entonces. Procedimientos manuales tan complejos que la ejecución bajo tensión tiende a errores.
Frecuencia de copia de seguridad	⚠️ Los datos de transacciones críticas se copian de seguridad semanalmente cuando el requisito comercial es RPO de 24 horas. Frecuencia de copia de seguridad no alineada con la criticidad comercial: la misma programación para todos los datos independientemente de la importancia. Programación de copia de seguridad perdida debido a la falta de supervisión y alerta.
Cumplimiento normativo	⚠️ Retención de copia de seguridad más corta de lo que requiere la regulación vigente. Por ejemplo, la documentación de cumplimiento de HIPAA (pólizas, análisis de riesgo, BAA, registros de infracción) purgada antes de su retención de seis años §164.316, o registros de auditoría financiera gobernados por SOX eliminados antes de su retención de siete años. Déficit de cumplimiento descubierto durante la auditoría.
Almacenamiento de archivos	⚠️ Archivos de gran tamaño almacenados en Salesforce sin estrategia de archivado. El almacenamiento de archivos crece hasta que la organización se acerca al límite. Sin copia de seguridad de registros ContentVersion: archivos perdidos si la organización está dañada. Confiar en los usuarios para mantener copias personales de archivos críticos.
Pruebas de sandbox	⚠️ Sandbox completo nunca actualizado desde producción - entorno de prueba muy diferente de producción. Volumen de datos en sandbox 1% de la producción evitando una validación de restauración realista. Actualización de sandbox tratada como inconveniente en vez de oportunidad de validación de recuperación de desastres.
Supervisión	⚠️ Los trabajos de copia de seguridad fallan silenciosamente sin alertas. Descubra fallos de copia de seguridad semanas después durante el desastre cuando se necesita copia de seguridad. Sin panel mostrando tendencias de éxito de trabajo de copia de seguridad. Estado del servicio de copia de seguridad supervisado solo cuando llega la factura.
Claves de cifrado	⚠️ Tratar datos cifrados con Shield como seguros sin proteger material de claves: rotar claves por sí solas deja datos anteriores intactos, pero destruir un secreto de arrendatario (criptotritura) o perder material de clave Aportar su propia clave o solo caché hace que los datos cifrados sean permanentemente irrecuperables. La gestión de claves se omite de los procedimientos de recuperación.
Dependencias entre organizaciones	⚠️ Realizar una copia de seguridad de la organización principal sola cuando la solución depende de aplicaciones conectadas, integraciones externas o SSO: Los secretos de aplicaciones conectadas, las autorizaciones de credenciales nombradas y OAuth y los tokens de autenticación externa no se conservan por una restauración de datos y metadatos y deben reconfigurarse y volver a autorizarse antes de que una organización recuperada pueda autenticarse en sistemas externos. Cuando SSO externo es la única ruta de inicio de sesión, un proveedor de identidad no disponible bloquea el inicio de sesión incluso en una organización completamente recuperada.

Patrones

Dónde buscar	Qué buen aspecto tiene
Definición del objetivo de tiempo de recuperación (RTO)	✅ RTO definido por capacidad comercial en vez de uniforme en toda la organización. Operaciones críticas para los ingresos: minutos a 1 hora. Servicios de cara al cliente: 1-4 horas. Herramientas internas: 4-24 horas. Creación de informes históricos: días. RTO documentados con la aprobación de las partes interesadas comerciales.
Definición del objetivo de punto de recuperación (RPO)	✅ RPO definido basándose en pérdida de datos aceptable por capacidad. Transacciones financieras: RPO cercano a cero (segundos, replicación asíncrona dirigida por eventos). Registros de clientes: cerca de cero (minutos a través de los CDC). Datos de Analytics: horas (sincronización programada). Estado de flujo de trabajo temporal: días (no se necesita replicación).
Disponibilidad y funciones del equipo	✅ Personal principal y de copia de seguridad documentado para todas las funciones críticas. Ningún punto único de fallo en Knowledge operacional. Árbol de distribución que define el respondedor principal, la primera copia de seguridad, la segunda copia de seguridad. Información de contacto mantenida en el sistema accesible cuando Salesforce no está disponible.
Procedimientos de comunicación	✅ Plan de comunicación de incidentes que define quién notifica a usuarios, clientes, ejecutivos. Página de estado externa alojada fuera de Salesforce para la comunicación de usuarios durante cortes de plataforma. Sistema de notificación SMS para el equipo a petición cuando las herramientas de comunicación principales no están disponibles. Periodos de tiempo de distribución documentados (cuándo distribuir de equipo a gerente a ejecutivo).
Asignación de dependencia de proveedor	✅ Todos los proveedores externos críticos documentados incluyendo Salesforce, socios de integración, proveedores de paquetes ISV. SLA de proveedor y plazos de asistencia documentados (24/7 frente a solo horario de oficina). Contactos y procedimientos de distribución de proveedores documentados. Opciones de proveedor alternativas identificadas para dependencias críticas.
Obligaciones de notificación reglamentaria	✅ Requisitos de notificación de incidentes obligatorios documentados por sector (servicios financieros, cuidados sanitarios, gobierno). Periodos de tiempo de notificación definidos para coincidir con el plazo requerido de cada regulación reguladora. Matriz de responsabilidad que define quién archiva notificaciones con qué organismos reguladores. Plantillas preparadas para una notificación reguladora rápida.
Análisis de impacto comercial	✅ Cada función comercial clasificada por impacto de ingresos, impacto de usuario y riesgo regulatorio. Priorización de recuperación basada en la clasificación de impacto comercial. Recursos asignados a la recuperación de desastres proporcional a la criticidad comercial. Análisis de impacto revisado anualmente a medida que evolucionan las prioridades comerciales.

Antipatrones

Dónde buscar	Aspecto negativo
Definición de RTO/RPO	⚠️ “El sistema debe ser fiable” sin objetivos de RTO/RPO mensurables. RTO/RPO definido por el equipo de TI sin entrada de partes interesadas comerciales. Objetivos uniformes entre todas las funciones ignorando las diferencias de criticidad (“todo necesita 99,999% de tiempo de disponibilidad”).
Preparación del equipo	⚠️ El administrador único de Salesforce conoce los procedimientos de recuperación de desastres sin documentación ni personal de copia de seguridad. La rotación a petición incluye personal que nunca ejecutó procedimientos de recuperación. Respondedores principales no disponibles durante el desastre (vacaciones, enfermedad, empresa desaparecida).
Planificación de comunicación	⚠️ Sin plan de comunicación: descubra la necesidad de notificar a los usuarios después del incidente que ya está en curso. La página de estado alojada en Salesforce no está disponible durante el fallo de funcionamiento de Salesforce. Horas de espera para notificar a los ejecutivos mientras intentan la recuperación.
Dependencias de proveedores	⚠️ Desconociendo las condiciones de SLA del proveedor hasta que se produzca un desastre y esperando asistencia ininterrumpida del proveedor con cobertura solo en horario de oficina. No hay contactos de distribución de proveedores documentados. Proveedor de paquete ISV requerido para la recuperación pero la empresa ya no está en el negocio.
Requisitos normativos	⚠️ Desconoce las leyes de notificación de infracciones obligatorias. Descubra el requisito de notificación de 24 horas después de que hayan transcurrido 48 horas. Sin plantillas preparadas: redacción de notificaciones reguladoras durante la respuesta a incidentes mientras el reloj de cumplimiento avanza.
Priorización de recuperación	⚠️ Intentar restaurar todas las funciones simultáneamente durante el desastre en vez de dar prioridad a operaciones críticas para los ingresos. Pasar 8 horas recuperando la capacidad de creación de informes internos antes de abordar el sistema de pedidos de cara al cliente.
Pruebas y simulacros	⚠️ Plan de continuidad comercial nunca probado a través de simulacros. Suponiendo que los procedimientos documentados funcionarán bajo tensión sin validación. Ejercicios de mesa evitados debido a la “falta de tiempo” a pesar de pasar días recuperándose de problemas no descubiertos durante desastres reales.
Transferencia Knowledge	⚠️ Knowledge recuperación de desastres concentrado en un arquitecto superior que no documentó nada. Los nuevos miembros del equipo se incorporaron sin formación en recuperación de desastres. Suponiendo que todos saben qué hacer durante los desastres sin entrenamiento explícito o ejercicios.
Validación de hipótesis	⚠️ Los procedimientos de recuperación asumen que la copia de seguridad es accesible en 15 minutos, pero la recuperación de la copia de seguridad desde el almacenamiento en frío tarda 8 horas. Suponiendo que el equipo está disponible en 30 minutos pero no se definen procedimientos de distribución o rotación de llamadas. Estimaciones de tiempo de recuperación basadas en suposiciones optimistas nunca validadas a través de pruebas.

Patrones

Dónde buscar	Qué buen aspecto tiene
Alineación arquitectónica de RTO	✅ Las decisiones de arquitectura coinciden con compromisos de RTO. Minutes RTO requiere conmutación por error automatizada y espera activa. Horas de RTO requiere recuperación con secuencia de comandos y espera cálida. Days RTO acepta la recuperación manual de copias de seguridad en frío. Se evita la sobreingeniería donde el negocio no justifica la complejidad.
Estrategia de replicación de RPO	✅ El método de replicación coincide con el objetivo de RPO. RPO cercano a cero: transmisión de eventos asíncronos a través de Eventos de plataforma en cada guardado de registro (segundos de retardo de propagación, entrega al menos una vez). RPO de minutos: Cambiar Captura de datos replicación asíncrona. Horas RPO: extracción de API por lotes programada. Días RPO: copia de seguridad manual en programación fija.
Pruebas de RTO	✅ Procedimientos de recuperación probados en condiciones programadas. RTO real medido durante simulacros de recuperación de desastres. Brechas entre el RTO de destino y el RTO alcanzado identificadas y solucionadas. RTO alcanzable por el personal de copia de seguridad, no solo expertos principales.
Validación de RPO	✅ Pérdida de datos medida durante pruebas de recuperación. RPO real en comparación con el objetivo durante los ejercicios. Retraso de replicación supervisado continuamente en producción. Alertas configuradas cuando la replicación queda atrás del compromiso de RPO.
RTO/RPO específico de la capacidad	✅ Las diferentes funciones comerciales tienen diferentes objetivos de RTO/RPO que reflejan la criticidad comercial. Flujo de pedidos de comercio electrónico: RTO de 15 minutos, RPO cercano a cero (justifica activo-pasivo de múltiples organizaciones). Knowledge base interna: RTO de 8 horas, RPO de 24 horas (justifica la restauración manual desde copia de seguridad).
Análisis de coste-beneficio	✅ Objetivos de RTO/RPO equilibrados con el coste de implementación. Objetivos más estrictos requieren una inversión exponencialmente creciente. Caso comercial documentado mostrando el coste de tiempo de inactividad que justifica la inversión en recuperación de desastres. La revisión anual confirma la alineación continua entre la inversión y el valor comercial.
Alineación de SLA	✅ Los objetivos de RTO/RPO de soluciones tienen en cuenta la línea base de SLA de plataforma. La solución solo puede proporcionar RTO mejor que la línea base de plataforma con arquitectura de múltiples organizaciones. Objetivos realistas establecidos considerando funciones de plataforma como base.
Supervisión de funciones de recuperación	✅ Supervisión continua de la divisa de copia de seguridad (antigüedad de copia de seguridad frente al objetivo de RPO). Alerta cuando la copia de seguridad se retrasa. Validación automatizada de que la infraestructura de recuperación (organización secundaria, almacenamiento externo) está operativa.
Recuperación automatizada frente a manual	✅ Los objetivos de RTO agresivos (minutos) requieren una conmutación por error automatizada con una intervención humana mínima. Los objetivos de RTO moderados (horas) permiten la recuperación con secuencia de comandos con iniciación humana. Los objetivos de RTO relajados (días) aceptan la recuperación manual siguiendo procedimientos documentados.

Antipatrones

Dónde buscar	Aspecto negativo
Objetivos poco realistas	⚠️ Compromiso de RTO de 15 minutos con procedimientos de recuperación manuales que requieren 4 horas para ejecutarse. Prometiendo cero RPO sin infraestructura de replicación síncrona. Objetivos de RTO establecidos por TI sin compatibilidad arquitectónica.
Desalineación de arquitectura	⚠️ Compromiso de RTO de 30 minutos pero sin fallos automatizados y los procedimientos de recuperación son completamente manuales. Cero compromiso de RPO pero solo copias de seguridad diarias configuradas. Objetivos agresivos sin la inversión correspondiente en automatización y redundancia.
Objetivos no probados	⚠️ RTO nunca validado a través de simulacros de recuperación de desastres temporizados. Suponiendo que el RTO de 2 horas es alcanzable pero nunca se restaura realmente bajo restricciones de tiempo. Descubrir durante un desastre real que el RTO de 4 horas documentado requiere en realidad 18 horas.
Objetivos uniformes	⚠️ Todas las funciones asignadas al mismo RTO/RPO independientemente de la criticidad comercial. El sistema interno de creación de informes por lotes está diseñado para una disponibilidad de cinco a nueve mientras que el comercio electrónico crítico para los ingresos tiene el mismo objetivo. Sobreinversión masiva en capacidades no críticas y subinversión en sistemas críticos.
Ignorar dependencias	⚠️ RTO asume la restauración de la organización de Salesforce únicamente pero la solución depende del proveedor de identidad externo que tampoco está disponible. RPO asume que la copia de seguridad de datos es suficiente, pero las credenciales de integración y la configuración no se copian de seguridad. Las estimaciones de tiempo de recuperación ignoran el tiempo para restaurar sistemas dependientes.
Brechas de replicación	⚠️ Compromiso de RPO de 15 minutos pero Cambiar Captura de datos configurado solo para 3 de 12 objetos críticos. Plataforma Replicación de eventos configurada pero sin supervisión del retardo de entrega de eventos. La infraestructura de replicación se interrumpe y pasa desapercibida durante semanas hasta el desastre.
Desconocimiento de costes	⚠️ Comprometiéndose a cinco-nueve disponibilidades sin comprender el coste de implementación. Objetivos de RTO/RPO establecidos sin análisis de coste-beneficio. Negocio no dispuesto a financiar la infraestructura requerida para objetivos ya comprometidos con clientes.
Objetivos estáticos	⚠️ RTO/RPO definido hace 5 años nunca reevaluado a pesar del crecimiento comercial y el cambio de prioridades. Los objetivos continúan sin cambios a medida que evoluciona la solución y cambia la criticidad. Proceso de revisión anual ausente.
Déficits de documentación	⚠️ Objetivos de RTO/RPO documentados en documento de arquitectura pero no comunicados a partes interesadas comerciales. Negocio que desconoce las funciones de recuperación confirmadas. Déficit descubierto cuando el negocio espera una recuperación de 1 hora pero la arquitectura solo admite RTO de 24 horas.
Precisión falsa	⚠️ Comprometiéndose a una “disponibilidad del 99,97%” cuando la infraestructura de supervisión no puede medir con esa precisión. Objetivos definidos con falsa precisión que sugieren rigor cuando el análisis subyacente es una estimación aproximada.
Supervisión del absentismo	⚠️ Sin supervisión continua de las funciones de recuperación. La copia de seguridad está 2 días retrasada, violando el compromiso de RPO pero no hay alertas. La organización secundaria en arquitectura activo-pasiva no recibe actualizaciones de replicación pero las comprobaciones de estado no están configuradas.
Planificación sin ejecución	⚠️ Hermoso plan de recuperación de desastres con objetivos agresivos de RTO/RPO pero sin automatización, pruebas o procedimientos validados. Plan creado para satisfacer la casilla de verificación de cumplimiento pero sin realidad operativa detrás de los compromisos.

Patrones

Dónde buscar	Qué buen aspecto tiene
Redundancia de datos	✅ La plataforma proporciona copias de seguridad de infraestructura automáticamente. La replicación a nivel de aplicación complementa la copia de seguridad de plataforma cuando el negocio requiere una recuperación más rápida. Cambiar Captura de datos o Eventos de plataforma replican datos críticos en almacenamiento secundario de forma continua. La replicación permite la recuperación de daños lógicos o errores de configuración que las copias de seguridad de infraestructura no pueden solucionar.
Redundancia de aplicación	✅ Lógica de aplicación sin estado que sobrevive a fallos de transacciones individuales. Sin estado del lado del servidor que impida la ampliación horizontal. Tipos de metadatos personalizados y Configuración personalizada para configuración disponible al instante en todos los servidores de aplicación. Cualquier servidor de aplicación puede procesar cualquier solicitud sin depender del estado específico del servidor.
Redundancia de integración	✅ Los patrones de disyuntores detectan integraciones fallidas. Eventos de plataforma pone en cola solicitudes cuando los sistemas externos no están disponibles en vez de bloquear operaciones de usuario. Fallos del sistema externo aislados de funciones de cara al usuario. Múltiples opciones de proveedores externos identificadas para integraciones críticas que permiten un cambio rápido de proveedor durante cortes de proveedor.
Patrones de múltiples organizaciones para cargas de trabajo críticas	✅ Patrón activo-pasivo: organización principal sirve todo el tráfico, organización secundaria sincronizada pero inactiva, conmutación por error durante el fallo de la región principal. Patrón activo-activo: ambas organizaciones sirven el tráfico de producción de forma continua, usuarios asignados por geografía o unidad comercial. Multiorganización justificada solo cuando el negocio requiere RPO/RTO más allá de las funciones de la plataforma.
Sincronización de datos de múltiples organizaciones	✅ Cambiar Captura de datos entrega replicación casi en tiempo real para datos críticos (15 minutos RPO). Eventos de plataforma proporciona transmisión de eventos para transacciones críticas (RPO cercano a cero). Replicación programada de API masiva 2.0 para datos de referencia (RPO de 24 horas aceptable). Estrategia de resolución de conflictos definida para activo-activo cuando se modifica el mismo registro en ambas organizaciones.
Arquitectura activa-pasiva de múltiples organizaciones	✅ La organización principal en la región Este de EE.UU. sirve todo el tráfico de producción. Organización secundaria en la región de Europa sincronizada a través de CDC pero inactiva. La capa de autenticación o enrutamiento DNS dirige los usuarios a la organización activa. Las comprobaciones de estado automatizadas desencadenan fallos cuando la organización principal no está disponible durante 10 minutos consecutivos.
Arquitectura activo-activo de múltiples organizaciones	✅ Usuarios de EMEA en organización de Europa, usuarios de AMER en organización de EE.UU. basándose en campo de región de perfil de usuario. Replicación bidireccional para datos de referencia compartidos (cuentas, productos). Los datos regionales permanecen en organizaciones respectivas (pedidos, casos). La resolución de conflictos utiliza las últimas escrituras ganadas con autoridad regional para datos principales de clientes.
Distribución geográfica	✅ Los centros de datos regionales Hyperforce activan la distribución geográfica. Implementación de región única con redundancia gestionada por plataforma suficiente para una disponibilidad del 99,9%. Múltiples organizaciones entre regiones consideradas solo para requisitos del 99,95%+ o mandatos de residencia de datos reguladores.
Redundancia del sistema externo	✅ Las API externas críticas tienen extremos principales y de conmutación por error. El disyuntor cambia al extremo de conmutación por error cuando el principal experimenta fallos sostenidos. Servicios externos con redundancia geográfica preferida sobre proveedores de una sola región para integraciones críticas.
Supervisión de infraestructura	✅ Trust.salesforce.com supervisado a través de la API de estado. Suscríbase a notificaciones de estado específicas de instancia. La solución responde al estado de estado de la plataforma de forma dinámica reduciendo la carga no crítica durante la degradación. Scale Center identifica operaciones intensivas en recursos antes de que afecten a la capacidad de redundancia.
Automatización por fallo	✅ La conmutación por error automatizada se prefiere a la manual para objetivos RTO agresivos. Los controles de estado se ejecutan cada 1-5 minutos detectando fallos. La lógica de decisión de conmutación por error evita falsos positivos (requiere fallo sostenido, no errores transitorios). Reversión automatizada si el destino de la conmutación por error tampoco es saludable.
Puntos de fallo únicos	✅ La revisión de arquitectura identifica todos los puntos de fallo individuales. Cada SPOF identificado evaluado para impacto comercial y coste de mitigación. SPOF de alto impacto mitigados a través de la redundancia. SPOF de bajo impacto aceptados con procedimientos de aceptación y recuperación de riesgos documentados.
Prueba de funciones de redundancia	✅ Los simulacros de conmutación por error programados validan la lógica de conmutación por error automatizada. Sistemas de copia de seguridad probados bajo carga (no solo en espera en caliente inactivo). La capacidad de la organización secundaria validó la gestión de la carga de producción durante las pruebas activo-pasivo. Las lecciones aprendidas de cada prueba mejoran la automatización y los procedimientos.

Antipatrones

Dónde buscar	Aspecto negativo
Puntos de fallo únicos	⚠️ Toda la solución depende de una API externa única sin reserva. El proveedor de dominio personalizado es SPOF: si el proveedor falla, los usuarios no pueden llegar a Experience Cloud. Cuenta de usuario de integración única: si se desactiva, todas las integraciones fallan.
Redundancia no probada	⚠️ Arquitectura activa-pasiva de múltiples organizaciones configurada pero nunca probada. La organización secundaria no está sincronizada pero las comprobaciones de estado no están configuradas. El primer intento de conmutación por error se produce durante un desastre real que revela que la organización secundaria está dañada o no funciona.
Brechas de sincronización de datos	⚠️ Multiorganización activa-pasiva con replicación de CDC configurada para 5 de 30 objetos críticos. Se produce un error pero a la organización secundaria le falta el 80% de los datos requeridos. Supervisión de retardo de replicación ausente - organización secundaria 3 días por detrás de la principal pero sin alertas.
Redundancia falsa	⚠️ Suponiendo arquitectura de múltiples regiones cuando ambas organizaciones se alojan actualmente en la misma región Hyperforce. API externas “redundantes” que utilizan actualmente el mismo proveedor ascendente. Múltiples rutas de integración que enrutan todas por el mismo punto de fallo único.
Arquitectura con estado	⚠️ La lógica de la aplicación depende del estado en memoria que impide el escalado horizontal. El servidor de aplicación único mantiene todo el estado de sesión del usuario: el reinicio del servidor cierra la sesión de todos los usuarios. Recursos estáticos almacenados en caché en la memoria de la aplicación en vez de Caché de plataforma creando incoherencias entre servidores.
Sin disyuntores	⚠️ La integración externa falla y cada transacción espera el tiempo de espera completo de 120 segundos. Todos los usuarios afectados cuando un único sistema externo no está disponible. Sin aislamiento de fallos: una integración con fallos degrada el rendimiento completo de la plataforma.
Solo conmutación por error manual	⚠️ Arquitectura de múltiples organizaciones con solo procedimientos de conmutación por error manuales. Requiere un procedimiento de 2 horas para iniciar la conmutación por error mientras el negocio está cerrado. Comprobaciones de estado automatizadas no implementadas. La decisión de conmutación por error requiere la aprobación ejecutiva retrasando la recuperación.
Fallo de planificación de capacidad	⚠️ Organización secundaria en arquitectura activa-pasiva con un tamaño del 20% de la carga de producción. Se produce un error pero la organización secundaria no puede gestionar el tráfico de producción completo. Arquitectura activo-activo con ambas organizaciones al 85% de capacidad sin dejar redundancia cuando falla una organización.
Desviación de configuración	⚠️ Las organizaciones principales y secundarias divergen con el tiempo porque las implementaciones no están sincronizadas. Metadatos implementados en primarios pero no secundarios. La conmutación por error revela una organización secundaria que ejecuta una versión de código de hace 6 meses.
Sobreingeniería	⚠️ Arquitectura multiorganización con replicación activo-activo para herramientas de administrador internas utilizadas por 5 personas. Complejidad operativa de múltiples organizaciones no justificada por la criticidad comercial. El objetivo de disponibilidad del 99,999% para la creación de informes por lotes es aceptable al 99%.
Incomprensión geográfica	⚠️ Suponiendo que Hyperforce “multi-región” proporciona funciones de múltiples organizaciones automáticamente. No comprender que una única organización está siempre en una sola región y que varias regiones requieren múltiples organizaciones. La redundancia basada en geografía es imposible con arquitectura de una sola organización.
Acoplamiento de integración	⚠️ Todas las integraciones síncronas sin reserva asíncrona. La no disponibilidad del sistema externo bloquea las operaciones de usuario. Sin mecanismo de cola: las transacciones fallan si el sistema externo se desactiva temporalmente. Los usuarios no pueden continuar cuando la integración no está disponible.