Fiabilidad

Salesforce opera infraestructura resiliente 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 la red y los parches de infraestructura, con el estado de disponibilidad de la 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, el monitoreo 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 operaciones de negocio 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: Los límites reguladores limitan 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 de negocio en cascada. El flujo de ingresos se ralentiza cuando las plataformas de comercio 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 por repercusión de negocio. 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 reportes por lotes interno que tolera retrasos ocasionales.

Fiabilidad y Excelencia operativa están profundamente interconectadas. Ambos abordan el monitoreo, la respuesta ante 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 amplían 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 las cosas van mal.

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

Operational Excellence es el modo en que 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 ejecuciones y las rutas de distribución que guían a su equipo durante incidentes
• las oportunidades en curso de observabilidad que afloran señales
• los bucles de comentarios 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 monitoreo y observabilidad. El monitoreo está diseñado como un problema de fiabilidad. Debe crear sistemas observables. Se practica como una preocupación de Excelencia operativa. 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 tableros de estado. Operational Excellence cubre el modo en que su equipo responde a las señales, como las listas de ejecuciones y la 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 funciona 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. Optimización de recursos evita el agotamiento del límite regulador, garantizando que la plataforma permanece fiable a escala. Optimización de costos equilibra las inversiones de fiabilidad con el valor de negocio que ofrecen. 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 en un lote procesado en una sola transacción, respetando esos límites mientras 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 único afecta al procesamiento de todo el lote.
• Asumamos 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ñe 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 las transacciones simultáneas colisionan. 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 que se aproximan, 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 puede reintentarse con EventBus.RetryableException, aunque la reproducción de la transacción original requiere una 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 fallo no impide 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 un 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 del horario laboral, 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 de negocio primero. Defina objetivos de nivel de servicio basándose en la repercusión de negocio real antes de seleccionar soluciones técnicas. No todos los componentes requieren una disponibilidad de cinco a nueve. Haga coincidir la inversión de fiabilidad con la criticidad de negocio y diseñe una degradación elegante para funciones de apoyo. Los objetivos realistas activan 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 prueban la restauración de copias de seguridad, los procedimientos de conmutación por error y los libros de jugadas de respuestas ante incidentes. Restaure un entorno sandbox de copia completa desde una copia de seguridad de producción para validar procesos de recuperación. Introduzca fallos deliberados en entornos sandbox para confirmar que su monitoreo detecta problemas y que la recuperación automatizada se ejecuta correctamente. Los simulacros revelan brechas en procedimientos, herramientas y libros de ejecuciones antes de que los incidentes reales los expongan. Documente resultados de desglose y realice un seguimiento de la solución de 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 una conmutación por error automatizada de los 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. La conmutación 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 plataforma se programan y comunican en trust.salesforce.com. Los parches de infraestructura se producen de forma transparente, sin la participación del cliente.
• Monitoreo del estado de la plataforma principal: Salesforce monitorea el desempeño 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 desempeño del sistema de almacenamiento. El 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. En su lugar, 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 crea 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 de negocio y la arquitectura técnica. Antes de seleccionar tecnologías o diseñar modelos de datos, establezca SLO que definen 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 las operaciones, medido en 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 requerida para restaurar el servicio después de incidentes

Defina los SLO por capacidad de negocio 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 ningún colchón 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 destino, un incidente de plataforma única puede agotar ese presupuesto por completo. Por ejemplo, cuando la plataforma proporciona el 99,9%, diríjase 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. Los SLI deben ser objetivamente mensurables, recopilados de forma coherente y directamente vinculados 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
• Completar trabajo por lotes a través de monitoreo AsyncApexJob

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

Evite objetivos arbitrarios como "cinco nueves para todo". En su lugar, evalúe el impacto de negocio del tiempo de inactividad por función y establezca objetivos en consecuencia. La creación de reportes por lotes internos que toleran 7 horas de tiempo de inactividad mensual requiere 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 desde mediciones técnicas únicamente. Un sistema que reporta un tiempo de disponibilidad del 99,9% pero que experimenta tiempos de inactividad frecuentes falla en la fiabilidad basada en la experiencia del usuario. A los usuarios les importa 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 de extremo a extremo como un indicador de fiabilidad principal. La disponibilidad de componentes es necesaria, pero insuficiente para la fiabilidad de la experiencia del 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 de negocio demandan una conmutación por error entre regiones, documente esta dependencia de forma explícita 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 costos de licencia. Reserve patrones de múltiples organizaciones para escenarios donde los requisitos de negocio justifican 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 exigen el aislamiento de datos geográficos, la planificación de la continuidad de las actividades requiere independencia completa de una sola región
• La consolidación de organizaciones no es factible debido a los requisitos de autonomía de las unidades de negocio.

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 a los usuarios a la organización activa.

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

Diseñe la sincronización de datos apropiada para 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 API masiva 2.0 en intervalos fijos se adapta a datos de referencia menos urgentes.

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 de la que proporcionan los procedimientos de restauración de plataforma. Utilice Captura de datos de cambios 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 aplicaciones pueda procesar cualquier solicitud. Evite el estado del lado del servidor que impide 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 aplicaciones. 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 con fallos. Ponga en cola solicitudes 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.

Monitoree 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 desempeño. 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 desempeño de la plataforma se degrada, reduzca la carga de procesamiento por lotes no crítica. Aplace trabajos en segundo plano durante periodos de mantenimiento utilizando monitoreo de trabajos programado. 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 funciones críticas bajo tensión.

Utilice Scale Center para identificar operaciones y transacciones de larga duració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 desempeño de otros. Estas no son 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 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 completan bien dentro de los límites, incluso bajo carga máxima. Cree margen dirigiéndose al 70% de los límites reguladores como el techo operativo en condiciones normales, reservando el 30% para picos inesperados. Este tampón se adapta a 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 de límite regulador mientras 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 instrucciones 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 recopilaciones proporciona mejoras de eficiencia de orden de magnitud sobre enfoques registro por registro.

La automatización desencadenada por registro debe gestionar 200 registros por invocación de desencadenador, porque la plataforma procesa la ejecución de desencadenadores en lotes de hasta 200 registros. Las operaciones de Lightning Data Service se realizan 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 sola 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 prolongado 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. Lote proporciona límites reguladores exclusivos por fragmento y aislamiento de fallos: un fragmento con fallo no evita que se completen otros fragmentos. Esto activa el éxito parcial y el reintento dirigido. Implemente lógica de reintento personalizada para fallos transitorios realizando un seguimiento de intervalos de fragmentos con fallos 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 simultáneamente por organización. Los trabajos adicionales se colocan en cola en Apex Flex Queue (hasta 100 trabajos en estado Espera) y se ejecutan automáticamente cuando se abren divisiones.
• Apex colocable en cola: Ejecute trabajos asíncronos con capacidad de encadenamiento para activar flujos de trabajo de múltiples pasos y parámetros de objetos complejos. Apex colocable en cola comparte el límite DailyAsyncApexExecutions de toda la organización de 250 000 ejecuciones por 24 horas con todos los demás Apex asíncronos: Batch, Future y Scheduled Apex, en vez de tener una asignación específica de colocable en cola. Utilice Apex colocable en cola para flujos de trabajo de integración y orquestación de múltiples pasos que requieren procesamiento secuencial con mejor monitoreo 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 ampliada más allá de 72 horas está disponible como un complemento de pago: verifique los límites máximos actuales y el estado general en la documentación más reciente de Eventos de Salesforce Platform antes de comprometerse a cumplir 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. Los eventos de plataforma proporcionan 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 se puede programar 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 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 operaciones secuenciales de gran tamaño en operaciones paralelas más pequeñas que se completan con mayor rapidez y permanecen dentro de los límites reguladores.

• Particionamiento basado 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.
• Particionamiento de tipo de registro: Procese diferentes tipos de registro de forma independiente incluyendo casos Socio frente a casos Cliente o cuentas Empresa frente a cuentas PyME. Los trabajos por lotes separados por tipo activan la paralelización. El tipo de registro a menudo se correlaciona con distintos procesos de negocio que justifican el procesamiento independiente.
• Particionamiento basado 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 del negocio 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: crecimiento del conteo de personas que dirige la asignación de llamadas de API y asignaciones de almacenamiento 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: conteo de integración y asignación de API de 24 horas que dirige la frecuencia (cada nuevo patrón de integración agrega consumo recurrente)
• Capacidad de procesamiento: conteo de trabajos por lotes y complejidad que dirige 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 picos de límite de solicitudes de uso de API próximos, almacenamiento próximo a límites y profundidad de colas de trabajos por lotes que crecen más allá de niveles sostenibles. La revisión de capacidad semanal activa el plazo de ejecución de adquisiciones para licencias o límites adicionales antes de que se produzca la repercusión en el negocio.

Valide supuestos 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ímites reguladores, 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 desempeño de consultas con sesgo de datos real, profundidad de relación y conteos 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 usuarios simultáneos para validar el rendimiento y la contención de transacciones. Utilice pruebas de escala disponibles para organizaciones aptas 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 de pico para validar la capacidad de ampliación de la integración, la gestión de límites de frecuencia y el comportamiento del disyuntor 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 frente a entornos Sandbox de copia completa escalados para coincidir con la capacidad de producción. Prueba de escala se 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 usuario críticos sobre funciones de asistencia durante fallos. No todas las funciones tienen la misma importancia de negocio 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 del negocio incluso durante fallos parciales del sistema. Los usuarios prefieren funciones reducidas a la falta de 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 indica:

• Cerrada: operación normal, flujo de solicitudes al sistema externo según lo diseñado
• Abierto - umbral de fallo superado, las solicitudes fallan inmediatamente sin intentar llamadas externas, ahorrando recursos
• Medio abierto - 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 no disponibilidad temporal del servicio y las respuestas de límite de frecuencia a menudo se resuelven en cuestión de segundos. Implemente lógica de reintento que repita operaciones con fallos después de retrasos progresivos en vez de fallar inmediatamente.

El retroceso exponencial evita tormentas de reintento que abruman 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.

Haga coincidir la estrategia de reintento con el tipo de fallo.

• Agotamientos de tiempo 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 frecuencia (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 estar sobrecargado temporalmente
• Errores de cliente (4xx excepto 429): No reintente; solucione la solicitud como un error que indica una entrada no válida
• Limite de errores del regulador: No reintente en la misma transacción; vuelva a colocarse en cola como una operación asíncrona con límites exclusivos, por ejemplo publicando un evento de fallo que un suscriptor asíncrono reprocesa con retroceso bajo límites de transacción actualizados

Las estrategias de reserva definen enfoques alternativos cuando fallan los métodos principales, permitiendo el funcionamiento continuado 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 caché durante operaciones correctas. La caché proporciona datos obsoletos pero disponibles, lo que es mejor que un fallo completo para muchos casos de uso.
• Comportamiento predeterminado: Aplique reglas de negocio 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 del negocio 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 desempeño externo variable sin espera de usuario
• Llamadas de procesamiento por lotes: Utilizar los 120 segundos completos permitidos cuando ningún usuario está esperando una respuesta
• Múltiples llamadas por transacción: Presupuesta el 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 más rápido, permitiendo 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 la 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 de consumo regulador antes de operaciones costosas. Detecte fallos inmediatamente en vez de propagar el 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.
• Falla 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 y reporte 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 principal obstáculo 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. Revertir 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 pilas 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 la automatización de la conmutación por error, la frecuencia de las copias de seguridad y la inversión en pruebas de recuperación. Las diferentes funciones de negocio justifican diferentes inversiones de RTO. Debido a que RTO es el tiempo de inactividad que experimentan sus usuarios directamente, un destino omitido se traduce en interrupciones prolongadas y una pérdida de confianza del cliente Trust.

El RTO varía según la capacidad de negocio:

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. Los 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. 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 costo. Debido a que RPO es la pérdida de datos que absorbe su negocio, un destino perdido puede significar transacciones perdidas y brechas irrecuperables en sus registros.

Equilibre los requisitos de RPO con el costo 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 con fallos y defectos de integración, que causan la mayoría de la pérdida de datos. Existen copias de seguridad 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 abarquen datos, metadatos y archivos, ya que cada una requiere enfoques de copia de seguridad diferentes:

• Copias de seguridad: Implemente una estrategia de copia de seguridad integral que aborde tanto los datos como los 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 email 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, 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 una restauración puntual, recuperación granular a nivel de registro y 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 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, archivos adjuntos y documentos de ContentVersion 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 regulatorios que superan las funciones 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. Monitoree la actualización de copias 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 con fallo silencioso aflora inmediatamente en vez de en el siguiente simulacro.

Diseñe la replicación 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 cambiados. 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 de negocio 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 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 de múltiples sistemas complejas, MuleSoft Anypoint Platform proporciona orquestación, transformación y monitoreo. 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 sobremesa: El equipo pasa por escenarios de desastres, debatiendo funciones y puntos de decisión sin fallo real. Esta actividad es de bajo costo y revela brechas de procedimiento y desgloses 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 repercusión limitada en el negocio. Lleve a cabo regularmente, rotando qué procedimientos se prueban para cubrir todas las funciones de recuperación anualmente.
• Simulacro 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 de negocio 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 lecciones aprendidas después de cada simulacro. Actualice los libros de ejecuciones 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 del negocio va 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 plantilla de respaldo sea crítica.
• Procedimientos de comunicación: Defina cómo se comunican los incidentes a usuarios, clientes y ejecutivos. Establezca canales de comunicación que funcionan cuando las herramientas principales (por ejemplo, páginas de estado externas o sistemas de notificación SMS), incluyendo Salesforce en sí, no están disponibles.
• Dependencias de proveedores: Asigne dependencias de proveedores externos críticas para el funcionamiento de la solución. Rutas de distribución de documentos y SLA contractuales para cada proveedor clave 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 laboral que afecta al tiempo de recuperación.
• Obligaciones normativas: Identifique los requisitos de notificación desencadenados por interrupciones prolongadas. Los servicios financieros, los cuidados sanitarios y los contratos gubernamentales a menudo exigen la notificación de incidentes en plazos específicos. El incumplimiento puede crear riesgos legales y reglamentarios, 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 tableros de estado que muestran el estado operativo de inmediato. El estado de salud guía la respuesta operativa, incluyendo operaciones normales bajo estado verde, monitoreo mejorado bajo estado amarillo y respuesta de incidente activa bajo estado rojo.

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

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

• Monitoreo de eventos: Monitoreo de eventos incluye registros detallados que capturan llamadas de API, vistas de página, exportaciones de reportes, 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 cada hora requiere el complemento Event Monitoring 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 Monitoreo 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 la correlación, alerta y retención más allá de los límites nativos. Utilice Monitoreo 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 intensivas en 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 desempeño aflorante 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.

Monitoree el desempeño de la aplicación desde la perspectiva del usuario en vez de la perspectiva de la infraestructura:

• Monitoreo de usuarios reales (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, desempeño de dispositivos y distribución geográfica. El monitoreo sintético no puede replicar esta variabilidad.
• Monitoreo sintético: Ejecute transacciones automatizadas periódicamente desde múltiples ubicaciones para validar la disponibilidad y el desempeño. El monitoreo sintético detecta problemas antes de que los usuarios los reporten. Implemente monitoreo sintético 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 la cronología por paso. A continuación, identifique qué paso del flujo de trabajo de cinco pasos introduce latencia. No trate todo el flujo como una caja negra. La cronología a nivel de paso revela oportunidades de optimización invisibles en mediciones agregadas.

Monitoree 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 fallo sostenido que requiere atención inmediata
• Profundidad de cola: Para integraciones asíncronas, la cola en crecimiento indica que el procesamiento está a la zaga 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, permitiendo respuestas proactivas:

• Alertas con capacidad de acción: 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 remedia.
• Urgencia apropiada: Personal de guardia de página para fallos que afectan al usuario. Envíe email para un desempeño degradado. Incluya problemas en un resumen diario para capturar sobre tendencias. La urgencia no coincidente 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 tablero o libro de ejecución relevante. Permita a los respondedores iniciar el diagnóstico inmediatamente sin recopilar contexto. Todas las alertas deben 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 un fallo de plataforma de integración tiene más capacidad de acción 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 de base de la misma hora 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 suben entre varios días indican la saturación de capacidad o la regresión del desempeño.
• 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 de negocio, no objetivos arbitrarios
• Asegúrese de que los SLO de soluciones 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
• Monitorear 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 de negocio justifiquen claramente la complejidad
• Diseñar conmutación por error automatizada con libros de ejecuciones probados para patrones de múltiples organizaciones

Planificación de capacidad y escalabilidad

• 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
• Integraciones por lotes de todas las 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
• Monitorear la utilización de capacidad a través de la API de OrgLimits o Apex personalizado y alertar cuando el consumo se acerca 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 permitir el procesamiento paralelo cuando los volúmenes superan los límites secuenciales

Tolerancia y resiliencia a fallos

• 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
• Configurar los tiempos de espera apropiados para el tipo de operación (5-10 s de cara al usuario, 30-60 s 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 de negocio

• Definir RTO y RPO por capacidad de negocio antes del diseño
• Implementar copia de seguridad automatizada para datos, metadatos (control de origen) y archivos
• Validar procedimientos de restauración de copias de seguridad trimestralmente en entornos no de producción
• Monitorear la actualización de copias 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 de negocio 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 monitoreo de usuario real para flujos críticos de Experience Cloud
• Monitorear 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 Monitoreo de eventos a plataformas externas para la retención y el análisis a largo plazo
• Utilizar Proactive Monitoring y Scale Center para la 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 de trabajo bien diseñado.