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 de negocio

Patrones

Dónde buscar	Qué 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 a 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 volver a crear 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, archivos adjuntos y documentos de ContentVersion exportados a almacenamiento externo según lo programado. Exportación de archivos automatizada para requisitos de retención regulatorios. Sistema de archivo externo para archivos con una antigüedad superior a las necesidades operativas de negocio.
Validación de copia de seguridad	✅ Restaurar trimestralmente simulacros en entornos Sandbox completos o Developer. Restaure procedimientos documentados en libros de ejecuciones con instrucciones paso a paso. La restauración de pruebas valida la integridad y exhaustividad de las copias 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.
Campos y objetos personalizados	✅ Objetos personalizados incluidos en ejecuciones programadas del Servicio de exportación de datos, 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 campos 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 binarios de archivos. Se realizaron copias de seguridad de bibliotecas de documentos incluyendo permisos y estructuras de carpetas. 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.
Monitoreo y alerta de copia de seguridad	✅ Alertas automatizadas cuando las copias de seguridad programadas fallan o se retrasan. Tablero 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 únicamente 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 del Cargador de datos manual 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 historial de metadatos. Recuperación de punto en el tiempo imposible: no se 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 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 dinámicamente, 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	⚠️ La lista de ejecución de recuperación contiene pasos desfasados de una arquitectura de hace 2 años. Procedimientos de recuperación probados por un único experto que dejó la compañía desde entonces. Procedimientos manuales tan complejos que la ejecución bajo tensión tiende a errores.
Frecuencia de copia de seguridad	⚠️ Se realiza una copia de seguridad de los datos de transacciones críticas semanalmente cuando el requisito de negocio es 24 horas de RPO. Frecuencia de copia de seguridad no alineada con la criticidad de negocio: la misma programación para todos los datos independientemente de la importancia. Programación de copia de seguridad perdida debido a la falta de monitoreo y alertas.
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 (políticas, 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 archivo. 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 totalmente 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.
Monitoreo	⚠️ Los trabajos de copia de seguridad fallan silenciosamente sin alertas. Descubra fallos de copia de seguridad semanas después durante el desastre cuando se necesite la copia de seguridad. Sin tablero mostrando tendencias de éxito de trabajo de copia de seguridad. El estado del servicio de copia de seguridad se monitorea solo cuando llega la factura.
Claves de cifrado	⚠️ Tratar datos cifrados con Shield como seguros sin proteger material clave: 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 en los procedimientos de recuperación.
Dependencias entre organizaciones	⚠️ Realizar copias 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 mediante una restauración de datos y metadatos y deben volver a configurarse y 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é aspecto tiene
Definición de objetivo de tiempo de recuperación (RTO)	✅ RTO definido por capacidad de negocio 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 reportes históricos: días. RTO documentados con la aprobación de las partes interesadas de negocio.
Definición de 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 externo alojada fuera de Salesforce para la comunicación de usuarios durante cortes de plataforma. Sistema de notificación SMS para equipos de guardia 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 dependencias de proveedores	✅ Todos los proveedores externos críticos documentados incluyendo Salesforce, socios de integración, proveedores de paquetes ISV. SLA de proveedores 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 industria (servicios financieros, cuidados sanitarios, gobierno). Periodos de tiempo de notificación definidos para coincidir con el plazo requerido de cada regulación vigente. Matriz de responsabilidad que define quién archiva notificaciones con qué organismos reguladores. Plantillas preparadas para una notificación regulatoria rápida.
Análisis de impacto de negocio	✅ Cada función de negocio clasificada por repercusión en ingresos, repercusión en usuarios y riesgo regulatorio. Priorización de recuperación basada en la clasificación de repercusión de negocio. Recursos asignados a la recuperación de desastres proporcionales a la criticidad del negocio. Análisis de impacto revisado anualmente a medida que evolucionan las prioridades de negocio.

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 de negocio. Objetivos uniformes entre todas las funciones ignorando las diferencias de criticidad (“todo necesita un tiempo de disponibilidad del 99,999%”).
Preparación de 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, compañía abandonada).
Planificación de comunicaciones	⚠️ 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 Estado alojada en Salesforce no está disponible durante el fallo de Salesforce. Horas de espera para notificar a los ejecutivos al intentar la recuperación.
Dependencias de proveedores	⚠️ Desconoce las condiciones de SLA del proveedor hasta que se produzca el desastre y espera 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 compañía 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 transcurran 48 horas. No se preparan plantillas: redacción de notificaciones reguladoras durante la respuesta ante 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. Emplear 8 horas recuperando la capacidad de creación de reportes internos antes de abordar el sistema de pedidos de cara al cliente.
Pruebas y simulacros	⚠️ Plan de continuidad de negocio nunca probado a través de simulacros. Suponiendo que los procedimientos documentados funcionarán bajo tensión sin validación. Ejercicios de sobremesa 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. Nuevos miembros del equipo se incorporaron sin capacitación en recuperación de desastres. Suponiendo que todo el mundo sabe qué hacer durante los desastres sin capacitación explícita o simulacros.
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é 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 secuencias de comandos y espera cálida. Days RTO acepta la recuperación manual desde copia 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íncrona a través de Eventos de plataforma en cada guardado de registro (segundos de retraso 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. RPO de días: 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 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 simulacros. Retraso de replicación monitoreado continuamente en producción. Alertas configuradas cuando la replicación queda atrás del compromiso de RPO.
RTO/RPO específico de capacidad	✅ Diferentes funciones de negocio tienen diferentes objetivos de RTO/RPO reflejando la vitalidad del negocio. 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 costo-beneficio	✅ Objetivos de RTO/RPO equilibrados con el costo de implementación. Objetivos más estrictos requieren una inversión exponencialmente creciente. Caso de negocio documentado mostrando el costo 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 de negocio.
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.
Monitoreo de funciones de recuperación	✅ Monitoreo continuo de 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 secuencias de comandos con la 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 con 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 asistencia arquitectónica.
Desalineación de arquitectura	⚠️ El compromiso de RTO de 30 minutos pero sin procedimientos automatizados de recuperación y conmutación por error 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 cronometrados. Suponiendo que el RTO de 2 horas es alcanzable pero nunca se restaura realmente bajo restricciones de tiempo. Descubrir durante un desastre real ese RTO de 4 horas documentado requiere en realidad 18 horas.
Objetivos uniformes	⚠️ Todas las funciones asignadas al mismo RTO/RPO independientemente de la criticidad del negocio. El sistema de creación de reportes por lotes interno 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 funciones no críticas y subinversión en sistemas críticos.
Ignorar dependencias	⚠️ El 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. Las estimaciones de tiempo de recuperación ignoran el tiempo para restaurar sistemas dependientes.
Brechas de replicación	⚠️ Compromiso con RPO de 15 minutos pero Captura de datos de cambio configurado solo para 3 de 12 objetos críticos. Replicación de eventos de plataforma configurada pero sin monitoreo del desfase de entrega de eventos. La infraestructura de replicación se interrumpe y pasa desapercibida durante semanas hasta el desastre.
Desconocimiento de costos	⚠️ Compromiso de disponibilidad de cinco a nueve sin comprender el costo de implementación. Objetivos de RTO/RPO establecidos sin análisis de costo-beneficio. Negocio no dispuesto a financiar la infraestructura requerida para objetivos ya comprometidos con clientes.
Objetivos estáticos	⚠️ El RTO/RPO definido hace 5 años nunca se volvió a evaluar a pesar del crecimiento del negocio 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.
Brechas de documentación	⚠️ Objetivos de RTO/RPO documentados en documento de arquitectura pero no comunicados a partes interesadas de negocio. 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 monitoreo no puede medir con esa precisión. Objetivos definidos con precisión falsa sugiriendo rigor cuando el análisis subyacente es una estimación aproximada.
Monitoreo del absentismo	⚠️ Sin monitoreo continuo de las funciones de recuperación. La copia de seguridad se retrasa 2 días en la programación infringiendo el compromiso de RPO pero sin alertas. La organización secundaria en arquitectura activa-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é 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. Captura de datos de cambios 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 aplicaciones. 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 con fallos. Eventos de plataforma coloca las solicitudes en cola 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 proveedor externo identificadas para integraciones críticas que permiten un cambio rápido de proveedor durante las interrupciones del proveedor.
Patrones de múltiples organizaciones para cargas de trabajo críticas	✅ Patrón activo-pasivo: organización principal sirve todo el tráfico, la organización secundaria sincronizada pero inactiva, la conmutación por error durante el fallo de la región principal. Patrón activo-activo: ambas organizaciones sirven tráfico de producción de forma continua, usuarios asignados por geografía o unidad de negocio. Multiorganización justificada solo cuando el negocio requiere RPO/RTO más allá de las funciones de plataforma.
Sincronización de datos de múltiples organizaciones	✅ Captura de datos de cambios 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 casi 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 enrutamiento o autenticación DNS dirige a 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 una sola región con redundancia gestionada por plataforma suficiente para una disponibilidad del 99,9%. Múltiples organizaciones entre regiones consideradas solo para requisitos de 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.
Monitoreo de infraestructura	✅ Trust.salesforce.com monitoreado a través de la API de estado. Suscríbase a notificaciones de estado específicas de instancias. La solución responde al 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 error	✅ La conmutación por error automatizada se prefiere a la manual para objetivos RTO agresivos. Las comprobaciones 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 únicos de fallo	✅ La revisión de arquitectura identifica todos los puntos de fallo individuales. Cada SPOF identificado se evaluó para determinar la repercusión comercial y el costo de mitigación. SPOF de alto impacto mitigados a través de la redundancia. SPOF de bajo impacto aceptados con procedimientos de recuperación y aceptació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 únicos de fallo	⚠️ La solución completa depende de una API externa única sin reserva. El proveedor de dominios 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 una organización secundaria dañada o no funcional.
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. Monitoreo de desfase 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 la ampliación horizontal. El servidor de aplicación único mantiene todo el estado de la sesión de 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 fallo degrada el desempeño 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á parado. Comprobaciones de estado automatizadas no implementadas. La decisión de conmutación por error requiere la aprobación ejecutiva que retrasa la recuperación.
Fallo de planificación de capacidad	⚠️ Organización secundaria en arquitectura activa-pasiva dimensionada para el 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 principal pero no secundario. 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 de múltiples organizaciones con replicación activo-activo para herramientas de administrador internas utilizadas por 5 personas. Complejidad operativa de múltiples organizaciones no justificada por criticidad de negocio. Objetivo de disponibilidad del 99,999% para la creación de reportes por lotes 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 sola organización está siempre en una sola región y que varias regiones requieren múltiples organizaciones. Redundancia basada en geografía 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 del usuario. Sin mecanismo de cola: las transacciones fallan si el sistema externo se interrumpe temporalmente. Los usuarios no pueden continuar cuando la integración no está disponible.