Fiabilidad

Salesforce opera infraestructura resistente entre múltiples regiones con conmutación por error automatizada y resiliencia a nivel de infraestructura. La plataforma gestiona la redundancia del centro de datos, la disponibilidad de red y los parches de infraestructura, con el estado de disponibilidad de plataforma en tiempo real visible en Trust.salesforce.com.

Usted diseña la fiabilidad de todo lo que se ejecuta en esta infraestructura:: los modelos de datos que se amplían dentro de los límites reguladores, las transacciones que anticipan y se recuperan de fallos, la supervisión que detecta cuándo su solución se desvía de los objetivos de disponibilidad y los procedimientos de recuperación de desastres que restauran las operaciones comerciales cuando se producen fallos.

El SLA de Salesforce cubre la plataforma, pero es propietario de fiabilidad para todo lo que esté por encima de la capa de infraestructura. Usted es responsable de definir y cumplir sus propios objetivos de nivel de servicio (SLO): los objetivos de fiabilidad que requiere su negocio. La fiabilidad de la capa de aplicación sigue siendo responsabilidad suya independientemente del nivel de SLA de la plataforma. La misma plataforma que garantiza la disponibilidad también la limita: regulador limita el consumo de recursos de cada arrendatario de modo que ningún arrendatario pueda degradar la plataforma para otros. Por lo tanto, su solución debe ampliarse correctamente dentro de esos límites, en vez de simplemente solicitar más capacidad.

Las soluciones poco fiables pueden crear impactos comerciales en cascada. El flujo de ingresos se ralentiza cuando las plataformas comerciales no están disponibles. La productividad disminuye cuando las herramientas internas fallan a mitad del flujo de trabajo. Trust se erosiona cuando se dañan los datos o se pierden registros. Estos problemas se agravan con el tiempo a medida que se acumulan soluciones y crece la deuda técnica.

La fiabilidad no se trata de evitar todos los fallos. Los fallos se producen en sistemas distribuidos. La fiabilidad consiste en diseñar sistemas que anticipen fallos, ayuden a contener el radio de explosión y restauren el servicio automáticamente. Los requisitos de fiabilidad varían según la repercusión comercial. Por ejemplo, un portal de Experience Cloud de cara al cliente que requiere una disponibilidad del 99,9% implica opciones arquitectónicas fundamentalmente diferentes a un proceso de creación de informes por lotes interno que tolera retrasos ocasionales.

Fiabilidad y Excelencia operativa están profundamente interconectadas. Ambos abordan la supervisión, la respuesta a incidentes y la disponibilidad del sistema. Este solapamiento es intencionado, no accidental. La distinción radica en el tiempo de diseño frente al tiempo de ejecución.

Fiabilidad es lo que diseña en un sistema antes de ejecutarse, incluyendo:

• los modelos de datos mencionados anteriormente que se escalan dentro de los límites reguladores
• las transacciones que anticipan y se recuperan de fallos
• la redundancia y los disyuntores que contienen radio de explosión
• los objetivos de recuperación -objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO)- que determinan cómo se comporta su sistema cuando algo falla.

La fiabilidad está integrada; es una propiedad estructural de su solución.

Operational Excellence es cómo opera, mejora y sostiene el sistema una vez que se ejecuta, incluyendo:

• las prácticas de implementación que reducen el riesgo de cambio
• las listas de ejecución y rutas de distribución que guían a su equipo durante incidentes
• las canalizaciones de observabilidad que afloran señales
• los bucles de retroalimentación que mejoran el sistema con el tiempo.

Se practica la excelencia operativa; es la disciplina humana y de proceso que rodea su solución.

El terreno compartido entre los dos pilares es la capa de supervisión y observabilidad. La supervisión está diseñada como un problema de fiabilidad. Debe crear sistemas observables. Se practica como una preocupación de Excelencia operacional. Su equipo actúa en función de lo que le indican esos sistemas. La fiabilidad cubre patrones arquitectónicos que crea, como umbrales de alerta y paneles de salud. Operational Excellence cubre cómo responde su equipo a señales, como libros de ejecución y respuesta a petición.

Considere esta distinción: Direcciones de fiabilidad “¿sobrevivirá este sistema?” mientras que Operational Excellence dirige “¿puede su equipo operarlo?” Un sistema perfectamente fiable operado por un equipo sin libros de ejecución, implementaciones incoherentes o sin bucles de comentarios puede seguir fallando en la práctica. Un equipo excelente desde el punto de vista operacional que gestiona un sistema frágil y mal diseñado se verá abrumado por incidentes que no pueden evitar. Ambos pilares son necesarios y ninguno sustituye al otro.

La fiabilidad no funciona de forma aislada. Como se describe en las secciones anteriores, Operational Excellence es su socio más cercano. Los dos pilares comparten la capa de observabilidad, con Fiabilidad definiendo lo que crea en un sistema y Excelencia operativa definiendo cómo opera su equipo. Confianza también requiere una infraestructura que resista los ataques y mantenga la integridad de los datos: un sistema no es fiable si puede verse comprometido. La optimización de recursos evita el agotamiento del límite regulador, garantizando que la plataforma permanezca fiable a escala. Optimización de costes equilibra las inversiones en fiabilidad con el valor comercial que entregan. Los objetivos de disponibilidad justifican la complejidad arquitectónica requerida para alcanzarlos. Ningún pilar produce una solución bien estructurada de forma aislada: la fiabilidad proporciona la base estructural de la que dependen y refuerzan los otros pilares.

Utilice estos principios para guiar sus decisiones de arquitectura para la fiabilidad en la plataforma.

• Distribuya la carga de trabajo a través de la masificación. Procese múltiples registros en transacciones únicas en vez de basarse en operaciones secuenciales por registro. La masificación comparte límites reguladores entre un lote procesado en una sola transacción, respetando esos límites al tiempo que maximiza el rendimiento. El procesamiento Apex basado en recopilaciones, los trabajos por lotes con ámbito configurable y los eventos de plataforma consumidos de forma masiva incorporan este principio. Las soluciones bien masificadas procesan 200 registros con el mismo número de declaraciones SOQL y DML que un registro en procesamiento secuencial. Los patrones de carga de trabajo distribuida proporcionan resiliencia porque ningún fallo de registro afecta al procesamiento de todo el lote.
• Supongamos que todo falla. Los límites reguladores, los plazos de mantenimiento de plataforma y las dependencias de integración crean modos de fallo relacionados con la arquitectura de múltiples arrendatarios de Salesforce. Diseño para estos fallos específicos de plataforma desde el principio. Las consultas SOQL superan los límites de filas bajo sesgo de datos. El tiempo de CPU Apex puede caducar durante cálculos complejos. Los tiempos de espera de llamadas pueden producirse a medida que se ralentizan los servicios externos. Los bloqueos de filas DML fallan cuando colisionan transacciones simultáneas. Los límites de almacenamiento pueden fallar cuando las cargas de archivos aumentan de forma inesperada. Los arquitectos que planifican estos fallos crean soluciones fiables sin intervención manual. Estos sistemas fiables detectan límites reguladores próximos, contienen radios de explosión a través de la gestión de errores y se recuperan automáticamente a través de marcos de trabajo de reintento y eventos de plataforma.
• Cree sistemas de recuperación automática. Diseñe soluciones que detectan fallos y se recuperan automáticamente sin intervención humana. Eventos de plataforma activa patrones de reintento personalizados. La entrega a un suscriptor se puede volver a intentar con EventBus.RetryableException, aunque la reproducción de la transacción original requiere arquitectura personalizada. La gestión de errores de flujo dirige excepciones a flujos de recuperación. Los trabajos por lotes Apex aíslan fallos de fragmentos (un fragmento con fallos no evita que se procesen otros fragmentos) permitiendo la realización parcial de trabajos y el reintento dirigido. Implemente lógica de reintento explícita utilizando seguimiento de errores en AsyncApexJob para la recuperación de fallos transitorios. Aplique retroceso exponencial a estos patrones de reintento al gestionar fallos transitorios. Los sistemas de recuperación automática mantienen los objetivos de disponibilidad incluso durante incidentes fuera de horario, cuando los respondedores humanos pueden no estar disponibles, reduciendo la carga operativa y mejorando al mismo tiempo el tiempo medio hasta la recuperación.
• Diseño para requisitos comerciales primero. Defina objetivos de nivel de servicio basándose en repercusión comercial real antes de seleccionar soluciones técnicas. No todos los componentes requieren una disponibilidad de cinco a nueve. Compare la inversión en fiabilidad con la criticidad comercial y diseñe una degradación elegante para funciones de asistencia. Los objetivos realistas permiten opciones de arquitectura apropiadas y evitan la sobreingeniería o la entrega insuficiente.
• Valide la recuperación a través de simulacros. Programe simulacros de recuperación de desastres que prueben la restauración de copias de seguridad, los procedimientos de conmutación por error y los libros de jugadas de respuesta a incidentes. Restaure un entorno sandbox de copia completa desde la copia de seguridad de producción para validar procesos de recuperación. Introduzca fallos deliberados en entornos sandbox para confirmar que su supervisión detecta problemas y que la recuperación automatizada se ejecuta correctamente. Los simulacros revelan brechas en procedimientos, herramientas y libros de ejecución antes de que incidentes reales los expongan. Documente los resultados de los ejercicios y realice un seguimiento de la solución de las brechas descubiertas. Las pruebas regulares garantizan que las funciones de recuperación permanecen actualizadas a medida que evolucionan las soluciones y cambia la pertenencia al equipo.

Comprender qué opera Salesforce le ayuda a centrar los esfuerzos de diseño de fiabilidad en lo que controla. La plataforma gestiona problemas de infraestructura que requerirían equipos exclusivos en entornos de TI tradicionales, como:

• Infraestructura multirregional y conmutación por error: Salesforce Hyperforce proporciona a los centros de datos regionales fallos automatizados de servicios internos. También proporciona múltiples zonas de disponibilidad dentro de regiones y replicación de datos en la capa de infraestructura. La plataforma gestiona la distribución de redundancia y zona de disponibilidad dentro de regiones de forma transparente.
• Compromisos de SLA de plataforma: Los niveles de disponibilidad garantizados con soluciones contractuales se negocian por cliente. Fidelity.salesforce.com publica el estado de la plataforma en tiempo real y el historial de tiempo de disponibilidad, pero cualquier garantía de disponibilidad específica y sus soluciones se mantienen en su acuerdo negociado. Revise su contrato y la documentación actual de Salesforce Trust y Cumplimiento para los compromisos que se aplican a su organización.
• Redundancia de infraestructura: La plataforma mantiene servidores redundantes, rutas de red, infraestructura de base de datos y sistemas de almacenamiento. El fallo a nivel de infraestructura se produce automáticamente durante fallos de hardware sin acción del cliente. Las copias de seguridad de plataforma protegen contra la pérdida de datos a nivel de infraestructura.
• Mantenimiento y actualizaciones de plataforma: Las principales versiones de plataforma entregan funciones y parches de seguridad con retrocompatibilidad gestionada por Salesforce. Los plazos de mantenimiento de la plataforma se programan y comunican en trust.salesforce.com. Los parches de infraestructura se producen de forma transparente, sin la participación del cliente.
• Supervisión del estado de la plataforma principal: Salesforce supervisa el rendimiento de la infraestructura, incluyendo los tiempos de respuesta de la base de datos, la latencia de la red, el estado de la pasarela de API y el rendimiento del sistema de almacenamiento. El estado de estado de la plataforma aparece en trust.salesforce.com e incluye actualizaciones de incidentes en tiempo real. El estado específico de la instancia está disponible a través de la API de estado.

Estas operaciones de plataforma crean la base sobre la que construye. No gestiona centros de datos, aprovisiona servidores o diseña la recuperación de desastres de infraestructura. Más bien, usted es responsable de lo que diseña y configura sobre esta base.

El modelo de responsabilidad compartida especifica que es propietario de la fiabilidad de todo lo que cree con Salesforce. La fiabilidad de plataforma activa su trabajo pero no lo sustituye. Sus responsabilidades de fiabilidad abarcan seis áreas interconectadas:

Los objetivos de nivel de servicio (SLO) cuantifican los requisitos de fiabilidad en términos mensurables. Los SLO acortan los requisitos comerciales y la arquitectura técnica. Antes de seleccionar tecnologías o diseñar modelos de datos, establezca SLO que definan el éxito para cada flujo de usuario crítico.

Los SLO suelen medir:

• Disponibilidad: porcentaje de tiempo que el sistema está operativo y accesible
• Latencia - tiempo necesario para completar operaciones, medido como percentiles (p50, p95, p99)
• Rendimiento: volumen de operaciones completadas con éxito por unidad de tiempo
• Porcentaje de errores: porcentaje de solicitudes que fallan o devuelven errores
• Tiempo de recuperación: duración necesaria para restablecer el servicio después de incidentes

Defina los SLO por capacidad comercial en vez de por componente técnico. Las funciones de cara al usuario requieren SLO más estrictos que los procesos administrativos o por lotes. Cada OSL debe poder medirse objetivamente utilizando los instrumentos disponibles.

Los acuerdos de nivel de servicio (SLA) son compromisos contractuales con consecuencias de fallo. Cualquier nivel de disponibilidad garantizado y sus soluciones contractuales se negocian por cliente. Revise su acuerdo y la documentación actual de Salesforce Trust y Cumplimiento para los compromisos aplicables a su organización.

Los SLO de soluciones deben ser menos estrictos que los SLA de plataforma para preservar el presupuesto de error. Si su SLA de plataforma y su SLO de solución apuntan al 99,9%, cualquier tiempo de inactividad de plataforma significativo consume directamente su presupuesto de error, sin dejar margen para fallos de la capa de aplicación, problemas de integración o mantenimiento planificado en el mismo periodo de medición. Un SLO se infringe formalmente solo cuando el tiempo de inactividad acumulado agota el presupuesto de error completo para el periodo de medición. Si su SLA y SLO están establecidos en el mismo objetivo, un incidente de plataforma única puede agotar ese presupuesto por completo. Por ejemplo, cuando la plataforma proporciona el 99,9%, apunte a un SLO de solución del 99,5% para mantener un colchón significativo para los problemas que debe solucionar: fallos de aplicación, fallos de integración y plazos de implementación.

Los indicadores de nivel de servicio (SLI) son mediciones utilizadas para evaluar el logro de SLO. Las SLI deben ser objetivamente medibles, recopiladas de forma coherente y directamente vinculadas a la experiencia del usuario.

Para soluciones de Salesforce, las SLI incluyen:

• Tiempo de disponibilidad de plataforma a través de trust.salesforce.com
• Tiempo de carga de página a través de Experience Cloud Analytics
• Tiempo de respuesta de API a través de Event Monitoring (que requiere el complemento Event Monitoring o Salesforce Shield)
• Índice de éxito de transacciones a través del registro de aplicaciones personalizadas
• Realización de trabajos por lotes a través de Supervisión de trabajos asíncronos

Los objetivos de mayor disponibilidad crean complejidad y coste exponencialmente crecientes. Comprenda las implicaciones arquitectónicas antes de comprometerse con objetivos:

Evite objetivos arbitrarios como “cinco nueves por todo”. En su lugar, evalúe la repercusión comercial del tiempo de inactividad por función y establezca objetivos en consecuencia. Los informes por lotes internos que toleran 7 horas de tiempo de inactividad mensual requieren una arquitectura fundamentalmente diferente al procesamiento de pedidos crítico para los ingresos que requiere una recuperación de menos de una hora.

Defina la fiabilidad desde una perspectiva de usuario en vez de solo desde mediciones técnicas. Un sistema que reporta un tiempo de disponibilidad del 99,9% pero experimenta tiempos de espera frecuentes falla en la fiabilidad basada en la experiencia del usuario. Los usuarios se preocupan por completar sus flujos de trabajo con éxito más que el tiempo de disponibilidad de API individual.

Diseñe SLO que reflejen trayectorias de usuarios en vez de llamadas de API individuales. Un flujo Checkout de múltiples pasos requiere que cada paso se complete correctamente en un tiempo aceptable. Mida los índices de finalización de flujos de usuario final a final como un indicador de fiabilidad principal. La disponibilidad de componentes es necesaria, pero insuficiente para la fiabilidad de la experiencia de usuario.

Salesforce Hyperforce proporciona centros de datos regionales que activan la distribución geográfica. La plataforma gestiona la redundancia de infraestructura en regiones incluyendo múltiples zonas de disponibilidad, fallo automático de servicios internos y replicación de datos en la capa de infraestructura. Los SLA de plataforma reflejan esta redundancia de infraestructura.

Para la mayoría de las soluciones, la implementación de una sola región con redundancia gestionada por plataforma proporciona suficiente disponibilidad. Trust Infraestructura de Salesforce para disponibilidad fundamental y arquitectura de soluciones de enfoque en fiabilidad de capa de aplicación, incluyendo patrones de integración tolerantes a fallos, degradación elegante y recuperación automatizada.

La conmutación por error intrarregional entre zonas de disponibilidad es automática e incluye compromisos de SLA de plataforma estándar: Salesforce gestiona esto de forma transparente en la capa de infraestructura. La recuperación de desastres entre regiones (fuera de la región) es una oferta de pago separada y no se incluye de forma predeterminada en ninguna edición estándar. Si sus requisitos de continuidad comercial demandan una conmutación por error entre regiones, documente esta dependencia explícitamente en su plan de recuperación de desastres de modo que las partes interesadas comprendan la distinción entre la resiliencia de plataforma incluida y las funciones de DR entre regiones adquiridas.

La arquitectura de múltiples organizaciones proporciona el aislamiento y la redundancia geográfica más sólidos, pero multiplica la complejidad operativa, incluyendo la sincronización de datos, el aprovisionamiento de usuarios, la coordinación de implementación y los costes de licencia. Reserve patrones de múltiples organizaciones para escenarios donde los requisitos comerciales justifiquen claramente la complejidad. Por ejemplo, considere un patrón de múltiples organizaciones para estos escenarios:

• El negocio requiere RPO/RTO garantizado más allá de las funciones de plataforma
• Los requisitos normativos imponen el aislamiento geográfico de los datos, la planificación de la continuidad de las actividades requiere una independencia completa de una sola región
• La consolidación de la organización no es posible debido a los requisitos de autonomía de la unidad comercial.

Patrón activo-pasivo: - La organización principal sirve todo el tráfico en condiciones normales. Las organizaciones secundarias en diferentes regiones permanecen sincronizadas pero inactivas. El fallo se produce durante un fallo de funcionamiento de la región principal. Esta solución proporciona el patrón multiorganización más sencillo pero deja la capacidad secundaria sin utilizar. Las capas de enrutamiento DNS o autenticación de usuario dirigen los usuarios a la organización activa.

Patrón activo-activo: - Ambas organizaciones sirven el tráfico de producción continuamente. Los usuarios se asignan por geografía, unidad comercial o tipo de carga de trabajo. Active-active maximiza la utilización de la capacidad, pero requiere sincronización de datos sofisticada y enrutamiento de usuarios. La resolución de conflictos es crítica cuando se modifica el mismo registro en ambas organizaciones.

Diseñe la sincronización de datos apropiada para los requisitos de RPO. Eventos de plataforma proporciona transmisión de eventos casi en tiempo real para cambios de datos críticos. Captura de datos de cambios entrega un seguimiento de cambios automático para objetos seleccionados con un desarrollo mínimo. La replicación de API programada a través de la API masiva 2.0 en intervalos fijos se adapta a datos de referencia menos sensibles al tiempo.

Aplique redundancia en capas de datos, aplicación e integración para evitar puntos de fallo únicos. La redundancia por capas garantiza que el fallo en cualquier capa única no comprometa la disponibilidad general del sistema.

• Redundancia de datos: La plataforma proporciona redundancia de datos a través de copias de seguridad de infraestructura. Complemente esta redundancia con replicación a nivel de aplicación cuando el negocio requiera una recuperación más rápida que la que proporcionan los procedimientos de restauración de plataforma. Utilice Cambiar Captura de datos o eventos de plataforma para replicar datos críticos en almacenamiento secundario o en sistemas externos de forma continua. Esto permite la recuperación de daños lógicos o de errores de configuración que las copias de seguridad de infraestructura no pueden solucionar.
• Redundancia de aplicación: Diseñe lógica de aplicación sin estado de modo que cualquier servidor de aplicación pueda procesar cualquier solicitud. Evite el estado del lado del servidor que evita la ampliación horizontal. Utilice tipos de metadatos personalizados y parámetros personalizados para la configuración que deben estar disponibles al instante en todos los servidores de aplicación. El diseño sin estado permite a un servidor de aplicaciones procesar solicitudes sin depender del estado específico del servidor.
• Redundancia de integración: Diseñe integraciones que toleran la no disponibilidad temporal del sistema externo. Implemente patrones de disyuntores detectando integraciones fallidas. Solicitudes de cola a través de Eventos de plataforma cuando los sistemas externos están inactivos en vez de bloquear operaciones de usuario. Esto aísla los fallos del sistema externo de las funciones de cara al usuario.

Supervise el estado de la plataforma Salesforce utilizando trust.salesforce.com y las API de estado específicas de instancias. Suscríbase a notificaciones de estado para su instancia para recibir alertas sobre incidentes, plazos de mantenimiento e impactos en el rendimiento. Las señales de estado de plataforma activan la respuesta proactiva en vez de la solución de problemas reactiva.

Diseñe soluciones que respondan al estado de salud de la plataforma. Cuando el rendimiento de la plataforma se degrade, reduzca la carga de procesamiento por lotes no crítica. Aplace trabajos en segundo plano durante plazos de mantenimiento utilizando la supervisión de trabajos programados. Desactive integraciones no esenciales para proteger operaciones críticas de cara al usuario durante incidentes. Este desprendimiento de carga dinámico mantiene la fiabilidad para capacidades críticas bajo tensión.

Utilice Scale Center para identificar operaciones y transacciones de larga ejecución que consumen recursos de plataforma desproporcionados. Scale Center proporciona visibilidad a nivel de transacciones, permitiendo a los arquitectos detectar riesgos de fiabilidad antes de que se conviertan en incidentes de cara al usuario. La revisión semanal de Scale Center revela patrones que requieren reparación arquitectónica.

Implemente la detección de fallos en múltiples niveles para detectar problemas antes de que se produzcan cortes completos en cascada. La detección por capas proporciona defensa en profundidad contra fallos no detectados.

Diseñe umbrales de alerta que equilibren la detección temprana con los falsos positivos. Alerta cuando los índices de error superan umbrales o se produce una degradación sostenida, no en fallos aislados. Los errores únicos son normales en sistemas distribuidos. Los patrones de errores indican problemas de fiabilidad que requieren atención.

Los límites reguladores de Salesforce limitan el consumo de recursos de cada arrendatario en la plataforma de múltiples arrendatarios de modo que ningún arrendatario pueda degradar el rendimiento para otros. No se trata de restricciones arbitrarias; son límites arquitectónicos que dan forma al diseño de soluciones. Comprenda los límites reguladores antes de diseñar una arquitectura fiable. Las soluciones que se acercan regularmente a los límites reguladores bajo carga normal probablemente fallarán bajo tensión.

Límites reguladores críticos que afectan a decisiones de arquitectura:

Diseñe transacciones que se completen bien dentro de los límites, incluso bajo carga máxima. Cree margen apuntando al 70% de límites reguladores como el techo operativo en condiciones normales, reservando el 30% para picos inesperados. Este tampón admite aumentos de carga temporales, normalmente sin alcanzar límites estrictos.

La masificación es el patrón de escalabilidad fundamental para Salesforce. Procese múltiples registros en una sola transacción en vez de en operaciones de registro individuales. La masificación reduce el consumo límite regulador al tiempo que aumenta el rendimiento. Cada arquitecto de Salesforce debe dominar los patrones de masificación, ya que sustentan todas las soluciones ampliables.

Diseñe todos los desencadenadores Apex, clases por lotes e integraciones para procesar recopilaciones de registros de forma eficiente. Recopile identificadores de registro primero, luego procese todos los registros con declaraciones DML y de una sola consulta. Utilice mapas y conjuntos para búsquedas eficientes en vez de bucles anidados con consultas individuales. El procesamiento basado en recopilación proporciona mejoras de eficiencia de orden de magnitud sobre enfoques registro por registro.

La automatización desencadenada por registros debe gestionar 200 registros por invocación de desencadenador, porque la plataforma procesa la ejecución de desencadenadores en lotes de hasta 200 registros. Lightning Data Service realiza operaciones por lotes automáticamente, pero los componentes personalizados deben implementar patrones masivos de forma explícita al realizar operaciones DML.

El procesamiento asíncrono distribuye el trabajo a lo largo del tiempo en vez de intentar la finalización inmediata dentro de los límites reguladores de una única transacción. Utilice patrones asíncronos cuando las operaciones procesan grandes volúmenes de datos que superan los límites reguladores síncronos, dependen de sistemas externos con tiempos de respuesta variables, pueden tolerar la finalización retrasada o requieren un tiempo de ejecución ampliado más allá de los límites de CPU síncronos.

Funciones asíncronas de Salesforce y su ajuste arquitectónico:

• Lote Apex: Procese grandes volúmenes de registros en fragmentos de hasta 2.000 registros por método de ejecución. El lote proporciona límites reguladores exclusivos por fragmento y aislamiento de fallos: un fragmento con fallos no evita que se completen otros fragmentos. Esto permite el éxito parcial y el reintento dirigido. Implemente lógica de reintento personalizada para fallos transitorios realizando un seguimiento de intervalos de fragmentos fallidos en el objeto AsyncApexJob y volviendo a poner en cola trabajos por lotes dirigidos. Utilice lotes para migraciones de datos, actualizaciones masivas programadas y procesamiento de datos a gran escala. Hay un máximo de cinco trabajos por lotes en ejecución o pendientes de ejecución al mismo tiempo por organización. Los trabajos adicionales se ponen en cola en Apex Flex Queue (hasta 100 trabajos en estado Espera) y se ejecutan automáticamente a medida que se abren las divisiones.
• Queable Apex: Ejecute trabajos asíncronos con capacidad de encadenamiento para activar flujos de trabajo de múltiples pasos y parámetros de objetos complejos. Apex en cola comparte el límite de ejecuciones DailyAsyncApexExecutions de toda la organización de 250 000 ejecuciones por 24 horas con todos los demás Apex asíncronos: Batch, Future y Apex programado, en vez de tener una asignación específica de cola exclusiva. Utilice Apex en cola para flujos de trabajo de integración y orquestación de múltiples pasos que requieren procesamiento secuencial con mejor supervisión que los métodos @future.
• Eventos de plataforma: Los eventos de plataforma se utilizan en una arquitectura de eventos de publicación-suscripción que desvincula publicadores de suscriptores. Los eventos se reproducen desde un plazo de retención de 72 horas (3 días). La retención prolongada más allá de 72 horas está disponible como un complemento de pago: verifique los límites máximos actuales y el estado de GA en la documentación más reciente de Eventos de Salesforce Platform antes de comprometerse con obligaciones de SLA que dependen de la reproducción ampliada. Utilice Eventos de plataforma para la automatización dirigida por eventos, la integración entre sistemas y la transmisión de datos en tiempo real. Eventos de plataforma proporciona límites asíncronos naturales entre fases de transacciones.
• Apex programado: Ejecute trabajos en una programación fija utilizando expresiones CRON a través de System.schedule(). Un trabajo puede programarse para ejecutarse como máximo una vez a la hora: los campos CRON segundos y minutos deben utilizar valores fijos, no intervalos. Manténgase dentro del máximo de 100 trabajos de Apex programados por organización consolidando operaciones similares en clases programables únicas.

Cuando los volúmenes de datos superan los límites de procesamiento prácticos incluso con patrones de masificación y asíncronos, particione datos entre límites lógicos para activar el procesamiento paralelo. La partición de datos convierte grandes operaciones secuenciales en operaciones paralelas más pequeñas que se completan con mayor rapidez y permanecen dentro de los límites reguladores.

• Partición basada en fechas: Procese datos en plazos de tiempo incluyendo las transacciones de este mes o los casos del último trimestre. Archive datos históricos en Big Objects o almacenamiento externo para mantener el conjunto de trabajo gestionable. La mayoría de las consultas transaccionales se centran en datos recientes que hacen que la partición basada en tiempo sea naturalmente eficiente.
• Partición de tipo de registro: Procese diferentes tipos de registro de forma independiente, incluyendo casos de socios frente a casos de clientes o cuentas de empresa frente a cuentas de pymes. Los trabajos por lotes separados por tipo activan la paralelización. El tipo de registro a menudo se correlaciona con distintos procesos comerciales que justifican el procesamiento independiente.
• Partición basada en propietario: Distribuya el procesamiento por propietario de registro, como el procesamiento de las oportunidades de cada región de ventas de forma independiente. La partición basada en propietario es particularmente efectiva cuando se combina con un modelo de colaboración, ya que la seguridad se aplica a través de mecanismos existentes. La partición basada en propietario activa la distribución geográfica de la carga de procesamiento.

Proyecte requisitos de capacidad futuros basándose en el crecimiento comercial en vez de reaccionar para limitar el agotamiento. La planificación de capacidad proactiva evita incidentes de fiabilidad causados por el agotamiento de recursos de plataforma.

• Licencias de usuario: asignación de llamadas de API y asignaciones de almacenamiento dirigidas al crecimiento del recuento por usuario
• Almacenamiento de datos: volúmenes de transacciones y políticas de retención que impulsan el consumo de almacenamiento (planifique nominalmente un crecimiento anual del 10 al 20% como mínimo)
• Llamadas de API: recuento de integración y asignación de API de 24 horas dirigida por frecuencia (cada nuevo patrón de integración agrega consumo recurrente)
• Capacidad de procesamiento: recuento de trabajos por lotes y complejidad que dirigen colas de procesamiento asíncrono y límites de ejecución simultánea

Utilice Proactive Monitoring para evaluar continuamente el uso de la capacidad de la organización. Proactive Monitoring aflora riesgos de capacidad incluyendo el uso de API que se acerca a picos de límite de solicitudes, almacenamiento que se acerca a límites y profundidad de cola de trabajos por lotes que crece más allá de niveles sostenibles. La revisión de capacidad semanal activa el tiempo de candidato de adquisición para licencias o límites adicionales antes de que se produzca la repercusión comercial.

Valide suposiciones de escalabilidad a través de pruebas de carga antes de la implementación de producción. Las pruebas de carga revelan problemas de límite regulador, cuellos de botella de integración y restricciones de capacidad invisibles en pruebas de desarrollo de bajo volumen. Pruebe con volúmenes de datos a escala de producción y concurrencia para validar la fiabilidad bajo condiciones realistas.

• Pruebas de volumen de datos: Rellene volúmenes de datos a escala de producción en Sandbox de copia completa para validar el rendimiento de consultas con sesgo de datos real, profundidad de relación y recuentos de registros. Pruebe con más de 10 millones de registros cuándo alcanzará la producción esa escala. El comportamiento del optimizador de consultas cambia drásticamente a medida que aumenta el volumen de datos, lo que puede dar como resultado resultados de Prueba de escala reducida engañosos.
• Pruebas de usuario simultáneas: Simule el pico de carga de usuario simultánea para validar el rendimiento y la contención de transacciones. Utilice pruebas de escala disponibles para organizaciones cualificadas para simular cargas de trabajo de producción en entornos sandbox antes de la implementación. La ejecución simultánea revela problemas de bloqueo invisibles en pruebas de un solo usuario.
• Pruebas de carga de API: Genere volúmenes de API máximos para validar la capacidad de ampliación de la integración, la gestión de límites de velocidad y el comportamiento de los disyuntores bajo carga sostenida. Las pruebas de carga de API revelan si la lógica de reintento y la gestión de errores funcionan correctamente en condiciones de estrés.
• Prueba de escala: Prueba de escala es un producto de Salesforce utilizado para simular cargas de trabajo de producción en entornos Sandbox de copia completa ampliados para coincidir con la capacidad de producción. Prueba de escala ejecuta en entornos sandbox de copia completa en Hyperforce. Su instancia de producción no necesita estar en Hyperforce para utilizarla. Usted crea planes de prueba en su organización de producción, mientras que las pruebas se ejecutan en el entorno sandbox. Utilice Prueba de escala para validar el margen de maniobra de límite regulador, el rendimiento de procesamiento asíncrono y el comportamiento de respuesta de integración bajo condiciones de carga máxima antes de implementaciones importantes.

La degradación elegante mantiene la funcionalidad principal cuando fallan componentes no críticos. Diseñe sistemas priorizando flujos de usuarios críticos sobre funciones de asistencia durante fallos. No todas las funciones tienen la misma importancia comercial y las arquitecturas deben reflejar estas prioridades.

Definir jerarquía de criticidad de funciones:

Esta jerarquía permite a los arquitectos diseñar políticas de degradación que mantienen la continuidad comercial incluso durante fallos parciales del sistema. Los usuarios prefieren funciones reducidas a la no disponibilidad completa.

El patrón del disyuntor evita fallos en cascada cuando las integraciones dejan de estar disponibles. En vez de acumular tiempos de espera que consumen tiempo de transacción y límites reguladores, detecte patrones de fallo y deje de llamar a sistemas con fallos. Los disyuntores proporcionan fallos rápidos en vez de fallos lentos.

El disyuntor establece:

• Cerrada - operación normal, flujo de solicitudes al sistema externo según lo diseñado
• Abierto: se ha superado el umbral de fallo, las solicitudes fallan inmediatamente sin intentar llamadas externas, ahorrando recursos
• Semiabierto - periodo de prueba de recuperación, solicitudes limitadas que sondean sistemas externos para detectar la recuperación antes de cerrar completamente el circuito

Implemente disyuntores utilizando Caché de plataforma para almacenar el estado del circuito accesible en todas las transacciones. Utilice Eventos de plataforma para difundir cambios de estado en toda la organización. La lógica del disyuntor comprueba el estado antes de intentar llamadas externas, evitando límites de llamadas desperdiciadas en sistemas con fallos conocidos.

Los fallos transitorios son normales en sistemas distribuidos. Las interrupciones de red, la falta de disponibilidad de servicio temporal y las respuestas de límite de frecuencia a menudo se resuelven en cuestión de segundos. Implemente una lógica de reintento que repita las operaciones fallidas después de retrasos progresivos en vez de fallar inmediatamente.

El retroceso exponencial evita tormentas de reintento que desbordan los sistemas de recuperación. Un primer reintento puede producirse después de 1 segundo, un segundo después de 2 segundos, un tercero después de 4 segundos y un cuarto después de 8 segundos. Límite de retraso máximo de 30 a 60 segundos independientemente del crecimiento exponencial. Este patrón de retroceso proporciona a los sistemas con fallos tiempo para recuperarse mientras limita la duración total del reintento.

Compare la estrategia de reintento con el tipo de fallo.

• Tiempos de espera de red: Reintentar con un retroceso corto (es posible que la operación no haya llegado al servidor)
• Errores de límite de índice (429): Reintentar después del valor del encabezado Reintentar después o después del tiempo de restablecimiento del límite de frecuencia
• Errores de servidor (5xx): Reintentar con retroceso exponencial, ya que el servidor puede sobrecargarse temporalmente
• Errores de cliente (4xx excepto 429): No lo reintente; solucione la solicitud como un error que indica una entrada no válida
• Límite de errores del regulador: No vuelva a intentarlo en la misma transacción; vuelva a ponerse en cola como una operación asíncrona con límites exclusivos, por ejemplo, publicando un evento de fallo que un suscriptor asíncrono vuelva a procesar con retroceso bajo límites de transacción nuevos

Las estrategias de reserva definen enfoques alternativos cuando fallan los métodos principales, permitiendo el funcionamiento continuo en condiciones degradadas.

• Origen de datos alternativo: Recupere datos desde la sesión de caché de plataforma o desde una partición de organización cuando la API en tiempo real no esté disponible. Rellene previamente la memoria caché durante operaciones correctas. La memoria caché proporciona datos obsoletos pero disponibles, lo que es mejor que un fallo completo para muchos casos de uso.
• Comportamiento predeterminado: Aplique reglas comerciales estándar cuando un servicio de personalización o enriquecimiento no esté disponible. Proceso con valores predeterminados y indicador para el enriquecimiento cuando se recupera el servicio. El comportamiento predeterminado mantiene el rendimiento a costa de una precisión reducida.
• Proceso manual: Active la finalización de operaciones manuales cuando falle la automatización. Proporcione una interfaz de administrador para completar transacciones atascadas. La reserva manual evita la pérdida de datos y mantiene la continuidad comercial cuando la automatización se ve afectada.
• Cola para reintentarlo: Almacene operaciones en eventos de plataforma u objetos de cola personalizados para procesar cuando se recupere un sistema externo. La reproducción de eventos de plataforma con retención estándar de 72 horas permite la recuperación de suscriptores tras fallos temporales, sin pérdida de datos.

Configure tiempos de espera apropiados para todas las llamadas de integración. Salesforce aplica un máximo de 120 segundos de tiempo total de llamada por transacción. Presupuesta esta hora en todas las llamadas en una sola transacción para evitar agotar el tiempo de transacción en conexiones colgadas.

Consideraciones de diseño de tiempo de espera:

• Llamadas síncronas de cara al usuario: Utilice un máximo de 5 a 10 segundos para mantener la interfaz de usuario con capacidad de respuesta ya que los usuarios tienden a no esperar más
• Llamadas asíncronas en segundo plano: Utilice 30 a 60 segundos para acomodar el rendimiento externo variable sin que el usuario espere
• Llamadas de procesamiento por lotes: Utilice los 120 segundos completos permitidos cuando ningún usuario está esperando una respuesta
• Llamadas múltiples por transacción: Realice un presupuesto de tiempo total en todas las llamadas, como tres llamadas a 10 segundos cada una consumiendo 30 segundos de su presupuesto de 120 segundos.

Los tiempos de espera más cortos fallan con mayor rapidez, lo que permite que las estrategias de reserva se impliquen antes. Los tiempos de espera más largos aumentan el índice de éxito para sistemas externos lentos pero funcionales. Las consideraciones de equilibrio se basan en si el usuario está esperando una respuesta y la disponibilidad de estrategias de reserva.

Diseñe una gestión integral de errores para transformar fallos de bloqueos en degradación gestionada:

• Fallo rápido: Valide entradas y condiciones previas en puntos de entrada. Compruebe el límite regulador de consumo antes de operaciones costosas. Detecte fallos de inmediato en vez de propagar un estado no válido a través de múltiples capas de procesamiento. La detección temprana reduce el radio de explosión y simplifica la depuración.
• Fallar con gracia: Mantenga las funciones de usuario incluso cuando las operaciones fallen parcialmente. Si 3 de 200 registros en validación de fallos por lotes, procese los 197 registros correctos e informe de los 3 fallos en vez de fallar el lote completo. El éxito parcial es mejor que el fallo total para operaciones por lotes.
• Fallo informativo: Registre errores con Id. de transacción, contexto de usuario, parámetros de entrada y rastreo de pila. El contexto de error insuficiente es el obstáculo principal para la resolución rápida de incidentes. Cada registro de errores debe permitir al respondedor comprender qué falló, por qué y cómo reproducir.
• Fallo seguro: Asegúrese de que los fallos no comprometen la integridad o la seguridad de los datos. Revierta transacciones parciales en vez de dejar datos en un estado incoherente. Nunca exponga detalles de errores internos a usuarios finales, ya que los rastreos de pila revelan detalles de implementación útiles para atacantes.

Objetivo de tiempo de recuperación define el tiempo de inactividad máximo aceptable después de un desastre. RTO dirige las decisiones arquitectónicas sobre automatización de conmutación por error, frecuencia de copia de seguridad e inversión en pruebas de recuperación. Las diferentes funciones comerciales justifican diferentes inversiones de RTO. Debido a que RTO es el tiempo de inactividad que experimentan sus usuarios directamente, un objetivo incumplido se traduce en interrupciones prolongadas y erosionó Customer Trust.

El RTO varía según la capacidad comercial:

Defina RTO por función antes de diseñar la arquitectura de recuperación de desastres. RTO da forma a la selección de tecnología, la inversión en automatización y la cadencia de prueba. Objetivos de RTO más agresivos requieren una mayor inversión en automatización y redundancia.

Objetivo de punto de recuperación define el plazo máximo de pérdida de datos aceptable medido en el tiempo. El RPO determina la frecuencia de copia de seguridad, la estrategia de replicación y los patrones de sincronización. Un RPO más estricto requiere una replicación de datos más frecuente, aumentando la complejidad y el coste. Debido a que RPO es la pérdida de datos que absorbe su negocio, un objetivo no alcanzado puede significar transacciones perdidas y brechas irrecuperables en sus registros.

Equilibre los requisitos de RPO con el coste y la complejidad. El RPO cercano a cero requiere replicación de datos continua con una inversión significativa en infraestructura. La copia de seguridad diaria proporciona un RPO de 24 horas con una complejidad mínima. La mayoría de las organizaciones pueden tolerar cierta pérdida de datos para datos no financieros.

La redundancia de infraestructura de plataforma protege contra fallos de infraestructura, pero replica los resultados de errores de usuario, implementaciones defectuosas y defectos de integración, que causan la mayoría de la pérdida de datos. Las copias de seguridad existen para recuperarse de estos fallos de la capa de aplicación, no para compensar la fiabilidad de la plataforma. Implemente estrategias de copia de seguridad que cubran datos, metadatos y archivos, ya que cada uno requiere diferentes enfoques de copia de seguridad:

• Copias de seguridad: Implemente una estrategia de copia de seguridad integral que aborde datos y metadatos. Exporte datos de objetos críticos utilizando el Servicio de exportación de datos nativo: cada 7 días para Enterprise Edition, Performance Edition y Unlimited Edition; cada 29 días para Professional Edition y versiones inferiores. Los archivos de exportación están disponibles durante 48 horas después del envío del correo electrónico de notificación, sin incluir fines de semana, antes de la eliminación automática. Configure un proceso de descarga automatizado de modo que los archivos no se pierdan de forma permanente. Utilice la API de metadatos y Salesforce CLI (sf project retrieve) para controlar la configuración de la organización de versión, el código personalizado y la automatización declarativa en un sistema de control de origen como Git. Trate la copia de seguridad de metadatos como parte de sus oportunidades en curso de CI/CD estándar. Complemente la copia de seguridad de datos con servicios de copia de seguridad y recuperación exclusivos como Propio para la restauración de punto en el tiempo, la recuperación granular a nivel de registro y la retención más allá de la cadencia de exportación nativa. Exportación de datos nativa no admite la restauración de punto en el tiempo, y se requieren herramientas externas si su RTO/RPO demanda plazos de recuperación granulares. Pruebe los procedimientos de restauración regularmente; una copia de seguridad que nunca se restauró es un supuesto no probado.
• Copias de seguridad de metadatos: Controle la versión de todos los metadatos utilizando el formato de origen Salesforce DX en repositorios Git. El control de versión de metadatos permite una rápida restauración de la configuración después de daños o cambios no intencionados. Cada implementación debe ser reproducible desde el control de origen. Los metadatos en Git proporcionan recuperación de punto en el tiempo para la configuración.
• Copias de seguridad de archivos: Exporte registros ContentVersion, archivos adjuntos y documentos a almacenamiento externo. Salesforce funciona mejor para datos activos, no para el archivado de archivos a largo plazo: exporte archivos a almacenamiento externo para su retención reglamentaria. Implemente la exportación de archivos automatizada para requisitos de retención reguladores que superan las capacidades de la plataforma.
• Validación: Restaure periódicamente copias de seguridad en organizaciones borrador o en entornos sandbox de desarrollador para validar tanto los procedimientos como la integridad de las copias de seguridad. Las copias de seguridad no probadas a menudo fallan cuando es necesario debido a un ámbito de copia de seguridad incompleto o archivos dañados. Programe la validación de restauración trimestral para detectar problemas antes de que se produzcan desastres. Supervise la actualización de la copia de seguridad además de restaurar la validación. Alerta cuando la copia de seguridad correcta más reciente es anterior a su cadencia esperada, por ejemplo, cuando una exportación semanal no se completó en más de 8 días. Con esta validación, un trabajo de copia de seguridad fallido silenciosamente aflora inmediatamente en vez de en el siguiente simulacro.

Replicación de diseño apropiada para requisitos de RPO y múltiples organizaciones:

• Captura de datos de cambios (CDC): Suscríbase para cambiar eventos para objetos con seguimiento. CDC entrega eventos de creación, actualización, eliminación y anulación de eliminación con valores de campo modificados. Proporciona replicación casi en tiempo real con un esfuerzo de desarrollo mínimo para objetos compatibles incluyendo estándar y personalizados. Sujeto a asignación de entrega diaria basada en edición.
• Eventos de plataforma: Arquitectura de eventos personalizada para replicar eventos comerciales y cambios de estado. Más flexible que CDC admitiendo cargas personalizadas y estructuras de eventos complejas, pero requiere lógica de publicación explícita en desencadenadores o procesos. El estándar de plazo de reproducción de 72 horas permite la recuperación de fallos de suscriptor temporales.
• Replicación de API programada: La replicación de API de programación es la extracción por lotes a través de la API masiva 2.0 en una programación fija. Es la implementación más sencilla con un RPO igual a la frecuencia de extracción. La replicación de API programada es adecuada para datos no críticos donde la ejecución casi en tiempo real es innecesaria, como con datos de referencia o análisis históricos.
• Replicación orquestada por MuleSoft: Para topologías de replicación multisistema complejas, MuleSoft Anypoint Platform proporciona orquestación, transformación y supervisión. Su uso es apropiado para la replicación en Salesforce y múltiples sistemas externos, lo que requiere una sofisticada lógica de enrutamiento y transformación.

Pruebe la recuperación de desastres con simulacros programados que validan personas, procesos y tecnología juntos:

• Ejercicios de mesa: El equipo pasa por escenarios de desastres, debatiendo funciones y puntos de decisión sin fallos reales. Esta actividad es de bajo coste y revela brechas de procedimiento y fallos de comunicación. Realice ejercicios de Tabletop regularmente para mantener la preparación del equipo a medida que cambia el personal.
• Fallo parcial: - Pruebe procedimientos de recuperación específicos como restauración de metadatos desde el control de origen, restauración de datos desde el servicio de copia de seguridad o actualización de sandbox. Esto valida procedimientos técnicos con impacto comercial limitado. Lleve a cabo regularmente, rotando qué procedimientos se prueban para cubrir todas las funciones de recuperación anualmente.
• Taladro de conmutación por error completo: La conmutación por error completa es la conmutación por error completa en el entorno de recuperación de desastres con la interrupción del tráfico de producción. Proporciona la mayor confianza, pero requiere coordinación comercial y comunicación de usuario. Realice este simulacro anualmente para sistemas críticos. El simulacro de conmutación por error completo valida la capacidad de recuperación completa, incluyendo procedimientos de conmutación y comunicación de usuario.

Documente las lecciones aprendidas después de cada simulacro. Actualice libros de ejecución basándose en hallazgos. Las funciones de recuperación pueden degradarse a medida que cambian los equipos y evolucionan las soluciones. Trate la documentación de DR como artefactos vivos que requieren mantenimiento regular en vez de entregas puntuales.

La continuidad comercial se extiende más allá de la recuperación técnica para abarcar personas, procesos y dependencias de proveedores:

• Disponibilidad de equipo: Procedimientos de distribución de documentos y personal de copia de seguridad para funciones críticas. Asegúrese de que no existe un único punto de fallo en Knowledge operacional. Es posible que los socorristas principales no estén disponibles durante los desastres, lo que hace que la dotación de personal de respaldo sea fundamental.
• Procedimientos de comunicación: Defina cómo se comunican los incidentes a usuarios, clientes y ejecutivos. Establezca canales de comunicación que funcionen cuando las herramientas principales (por ejemplo, páginas de estado externas o sistemas de notificación SMS), incluyendo la propia Salesforce, no estén disponibles.
• Dependencias de proveedores: Asigne dependencias de proveedores externos críticas para la operación de la solución. Rutas de distribución de documentos y SLA contractuales para cada proveedor crítico incluyendo Salesforce, socios de integración y proveedores de paquetes ISV. Comprenda, por ejemplo, qué proveedores proporcionan asistencia las 24 horas del día, los 7 días de la semana y cuáles tienen asistencia solo en horario de oficina que afecta al tiempo de recuperación.
• Obligaciones normativas: Identifique los requisitos de notificación desencadenados por cortes prolongados. Los servicios financieros, los cuidados sanitarios y los contratos gubernamentales a menudo obligan a notificar incidentes en plazos de tiempo específicos. El incumplimiento puede crear riesgos normativos y legales, que agravan el impacto de los desastres.

Defina un modelo de salud que agregue múltiples señales en el estado de salud general del sistema. Los modelos de salud afloran el estado operativo de un vistazo, sin requerir el análisis de mediciones detalladas. Por ejemplo:

Diseñe paneles de salud que muestran el estado operativo de inmediato. El estado de salud guía la respuesta operativa, incluyendo operaciones normales bajo estado verde, supervisión mejorada bajo estado amarillo y respuesta de incidentes activa bajo estado rojo.

Las señales de estado de plataforma (tratadas anteriormente bajo Supervisión de estado de plataforma) revelan cuándo se degrada la infraestructura de Salesforce, pero no el rendimiento de su propia solución.

Aumente esas señales con observabilidad específica de la solución:

• Supervisión de eventos: Supervisión de eventos incluye registros detallados que capturan llamadas de API, vistas de página, exportaciones de informes, actividad de inicio de sesión y ejecución Apex. Los objetos EventLogFile entregan registros con una frecuencia de 24 horas (diarias) o 1 hora: la entrega por hora requiere el complemento Supervisión de eventos o Salesforce Shield. La retención es configurable hasta 365 días a través de Configuración, pero la retención ampliada requiere Salesforce Shield o el complemento Supervisión de eventos. Sin un complemento, los archivos de registro se conservan durante 1 día. Enrute eventos a un sistema externo de Gestión de eventos e información de seguridad (SIEM) o a una plataforma de agregación de registros para correlación, alerta y retención más allá de los límites nativos. Utilice Supervisión de eventos para detectar patrones de consumo de API anormales, para identificar procesos Apex desbocados y para auditar el acceso a datos en entornos regulados.
• Centro de escala: Scale Center proporciona visibilidad a nivel de transacciones sobre operaciones de larga ejecución, contención de bloqueo de filas y transacciones que requieren muchos recursos. Scale Center permite a los arquitectos identificar riesgos de fiabilidad de patrones de transacciones específicos antes de que causen incidentes de cara al usuario. Las revisiones semanales pueden revelar oportunidades de optimización.
• Proactive Monitoring: Proactive Monitoring permite la evaluación continua del estado de la organización, el rendimiento de afloramiento y los riesgos de escalabilidad. Proactive Monitoring proporciona alertas sobre picos de límite de solicitudes de API, fallos de ejecución Apex simultáneos, problemas de límite de filas SOQL y tendencias de consumo de almacenamiento. Está disponible para clientes con una asignación Éxito de firma (anteriormente, Asistencia de firma): no es una función de autoservicio incluida con ediciones estándar.

Supervise el rendimiento de la aplicación desde la perspectiva del usuario en vez de la perspectiva de la infraestructura:

• Supervisión de usuario real (RUM): Mida la experiencia de usuario real a través de análisis de Experience Cloud o instrumentación personalizada. RUM captura la latencia real, reflejando condiciones de red reales, rendimiento de dispositivos y distribución geográfica. La supervisión sintética no puede replicar esta variabilidad.
• Supervisión sintética: Ejecute transacciones automatizadas periódicamente desde múltiples ubicaciones para validar la disponibilidad y el rendimiento. La supervisión sintética detecta problemas antes de que los usuarios los informen. Implemente la supervisión sintética utilizando Apex programado, ejecutando operaciones críticas y reportando resultados con Eventos de plataforma.
• Rastreo de transacciones: Instrumente operaciones complejas de múltiples pasos para capturar el tiempo por paso. A continuación, identifique qué paso del flujo de trabajo de cinco pasos introduce la latencia. No trate todo el flujo como un cuadro negro. La cronología a nivel de paso revela oportunidades de optimización invisibles en mediciones agregadas.

Supervise todas las integraciones externas utilizando índices de error, percentiles de latencia y rendimiento. Los fallos de integración son una causa principal de incidentes de fiabilidad:

• Porcentaje de errores: porcentaje de llamadas que devuelven errores (objetivo: <1% para una integración saludable)
• Latencia - El tiempo de respuesta medido en p50, p95, p99 (establecer SLO por integración basándose en presupuesto de tiempo de espera)
• Índice de tiempo de espera: porcentaje en el que se supera el tiempo de espera configurado (objetivo: <0,1%)
• Estado del disyuntor - El estado abierto indica un fallo sostenido que requiere atención inmediata
• Profundidad de cola - Para integraciones asíncronas, la cola creciente indica que el procesamiento está por debajo del índice de producción

Registre todas las llamadas de integración con Id. de solicitud, extremo, código de respuesta y duración. Estos datos permiten un análisis de causa raíz rápido cuando los fallos de integración afectan a la fiabilidad. Los registros de integración deben activar la agregación y el análisis de tendencias.

Diseñe alertas sobre problemas antes de que los usuarios se vean afectados, activando respuestas proactivas:

• Alertas procesables: Cada alerta tiene una acción de respuesta definida y un respondedor asignado. Las alertas sin respuesta clara crean fatiga y ocultan señales críticas. El diseño de alerta debe cubrir quién responde, qué comprueba y cómo soluciona.
• Urgencia apropiada: Personal a petición de página para fallos que afectan al usuario. Envíe un correo electrónico para un rendimiento degradado. Incluya problemas en un resumen diario para capturar sobre tendencias. La urgencia no adaptada crea fatiga de alerta por la distribución excesiva o incidentes perdidos por la distribución insuficiente.
• Notificaciones enriquecidas en contexto: Incluya el umbral cruzado, el valor actual, la tendencia reciente y un vínculo a un panel o libro de ejecución relevante. Permita a los respondedores iniciar el diagnóstico inmediatamente sin recopilar contexto. Cada alerta debe incluir suficiente información para el triaje sin consultas adicionales.
• Supresión de tormentas: Cuando varios sistemas fallan simultáneamente, suprima alertas redundantes. Una alerta que indica fallo de plataforma de integración es más procesable que 50 alertas de fallo de integración individuales que ocultan la causa raíz.

La detección de anomalías identifica patrones inusuales y puede indicar problemas emergentes invisibles para alertas de umbral estático:

• Anomalías de volumen: Los volúmenes de transacciones significativamente por encima o por debajo de los patrones diarios esperados pueden indicar procesos desbocados o problemas de acceso de usuarios.
• Anomalías de índice de error: Los índices de error elevados en comparación con las líneas base del mismo tiempo de la última semana detectan una degradación gradual antes de que se produzca un incumplimiento de umbral.
• Anomalías de latencia: Los tiempos de respuesta que se desplazan hacia arriba en varios días indican saturación de capacidad o regresión de rendimiento.
• Anomalías de comportamiento: Patrones de inicio de sesión inusuales, picos de uso de API inesperados y trabajos por lotes que se ejecutan fuera de los plazos programados pueden indicar un uso sospechoso.

Para clientes con la asignación Signature Success, Proactive Monitoring proporciona detección de anomalías a nivel de plataforma sin configuración adicional. Compleméntelo con la detección de anomalías específicas de la aplicación para SLI personalizadas exportadas a plataformas de análisis externas. Utilice señales de anomalía para guiar la investigación en vez de desencadenar una distribución inmediata, ya que la detección de anomalías tiene índices de falsos positivos más altos que las alertas de umbral.

Utilice esta lista de comprobación durante revisiones de arquitectura, antes de la implementación de producción y periódicamente para una evaluación de fiabilidad continua.

Objetivos de fiabilidad y SLO

• Definir SLO para todos los flujos de usuario críticos antes de que comience el diseño
• Establecer SLI mensurables vinculadas a la experiencia de usuario, no solo mediciones de infraestructura
• Establezca objetivos de disponibilidad realistas basándose en análisis de impacto comercial, no objetivos arbitrarios
• Asegúrese de que los SLO de solución son menos estrictos que los SLA de plataforma para proporcionar presupuesto de error
• Objetivos de disponibilidad de documentos y justificación en registros de decisiones de arquitectura

Arquitectura de alta disponibilidad

• Redundancia de diseño en capas de datos, aplicación e integración
• Supervisar el estado de la plataforma a través de Trust.salesforce.com y la API de estado de instancia
• Implementar comprobaciones de estado de aplicaciones independientes del estado de la plataforma
• Considere la arquitectura de múltiples organizaciones solo cuando los requisitos comerciales justifiquen claramente la complejidad
• Diseñar fallos automatizados con libros de ejecución probados para patrones de múltiples organizaciones

Escalabilidad y planificación de capacidad

• Diseñar transacciones completadas dentro del 70% de los límites reguladores bajo carga normal
• Implemente patrones de masificación en todos los desencadenadores Apex, clases por lotes e integraciones
• Utilizar procesamiento asíncrono para operaciones que superan los límites síncronos
• Lote todas las integraciones de API en vez de realizar llamadas de registro individuales
• Realizar pruebas de carga con volúmenes de datos a escala de producción antes de la implementación
• Supervise la utilización de la capacidad a través de la API de OrgLimits o Apex personalizado y alerte cuando el consumo se acerque al techo operativo del 70%
• Requisitos de capacidad de proyecto basados en expectativas de crecimiento a 12 meses
• Particione datos de gran volumen por fecha, tipo de registro o propietario para activar el procesamiento paralelo cuando los volúmenes superan los límites secuenciales

Tolerancia a fallos y resiliencia

• Diseñar una degradación elegante con niveles de criticidad de funciones definidos
• Implementar disyuntores para todas las integraciones de sistemas externos
• Aplicar lógica de reintento con retroceso exponencial para fallos transitorios
• Configure los tiempos de espera apropiados para el tipo de operación (5 a 10 segundos de cara al usuario, 30 a 60 segundos asíncronos)
• Diseñar estrategias de reserva utilizando Caché de plataforma y patrones basados en colas
• Implementar la gestión de errores estructurados con suficiente contexto de diagnóstico

Recuperación de desastres y continuidad comercial

• Definir RTO y RPO por capacidad comercial antes del diseño
• Implementar copias de seguridad automatizadas para datos, metadatos (control de origen) y archivos
• Validar procedimientos de restauración de copias de seguridad trimestralmente en entornos que no son de producción
• Supervisar la actualización de la copia de seguridad y alertar cuando vence una copia de seguridad programada
• Diseñar una estrategia de replicación de datos que coincida con los requisitos de RPO
• Realizar pruebas de recuperación de desastres anualmente (mesa trimestral)
• Documentar procedimientos de continuidad comercial incluyendo rutas de distribución de proveedores

Seguimiento y observabilidad

• Definir el modelo de salud agregando señales de servicio, integración, datos y capacidad
• Suscribirse a notificaciones de estado de plataforma para su instancia de Salesforce
• Implementar supervisión de usuario real para flujos críticos de Experience Cloud
• Supervisar el estado de integración con índice de error, latencia y estado del disyuntor
• Diseñar alertas con capacidad de acción con procedimientos de respuesta definidos y propiedad
• Enrutar datos de Supervisión de eventos a plataformas externas para la retención y el análisis a largo plazo
• Utilizar Proactive Monitoring and Scale Center para una evaluación de riesgos de fiabilidad continua
• Aplicar detección de anomalías para patrones de volumen, índice de error y latencia para capturar la degradación que no alcanzan los umbrales estáticos

Comparta sus comentarios sobre el Marco bien diseñado.