Patrones de disponibilidad y rendimiento
Obtenga más información acerca de Fiabilidad bien arquitectónica → Arquitectura de alta disponibilidad
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Análisis de impacto comercial | ✅ SLO definidos por capacidad comercial (por ejemplo, “Flujo de cierre de oportunidad: 99,9% de disponibilidad, latencia p95 inferior a 2 segundos”) en vez de por componente técnico |
| Documentación de flujo de usuario | ✅ Cada flujo de usuario crítico tiene un SLO mensurable que cubre la disponibilidad, la latencia, el rendimiento, el índice de error y el tiempo de recuperación vinculados a la experiencia de usuario real |
| Registros de decisiones de arquitectura | ✅ Objetivos de disponibilidad basados en análisis de impacto de tiempo de inactividad comercial con justificación documentada (por ejemplo, creación de informes por lotes internos del 99% frente al procesamiento de pedidos crítico para los ingresos del 99,95%) |
| Especificaciones de SLO | ✅ Objetivos realistas considerando la complejidad arquitectónica (99% = funciones de plataforma estándar, 99,5% = redundancia básica y supervisión activa, 99,9% = conciencia de múltiples regiones y conmutación por error automatizada, 99,95% = patrones activo-activo y pruebas de caos, 99,99% = arquitectura de múltiples organizaciones) |
| Documentación de plataforma | ✅ SLO de solución menos estrictos que los SLA de plataforma (por ejemplo, SLA de plataforma 99,9% → SLO de solución 99,5%) proporcionando presupuesto de error para fallos de la capa de aplicación |
| Configuración de supervisión | ✅ Indicadores de nivel de servicio (SLI) medibles objetivamente a través de instrumentación de plataforma: Trust.salesforce.com uptime, Experience Cloud analytics, Tiempo de respuesta de API de Supervisión de eventos, Finalización de trabajos de AsyncApex |
| Mediciones de experiencia de usuario | ✅ Los SLO reflejan trayectorias de usuario completas (por ejemplo, “Flujo de envío de casos: los 5 pasos se completan en 8 segundos para usuarios p95”) no el tiempo de disponibilidad de API individual |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Documentación de arquitectura | ⚠️ “El sistema debe ser rápido y confiable” (no medible, no dirige decisiones de arquitectura) |
| Especificaciones de SLO | ⚠️ “Todo necesita un tiempo de disponibilidad del 99,999%” (coste no justificado ignorando las diferencias de criticidad comercial entre operaciones de ingresos y herramientas de administrador interno) |
| Estrategia de supervisión | ⚠️ Supervisión de CPU de infraestructura como SLI principal (los arquitectos de mediciones de plataforma no pueden actuar, no reflejan la experiencia de cara al usuario) |
| Planificación de capacidad de plataforma | ⚠️ El SLO de la solución coincide con el SLA de la plataforma exactamente al 99,9% (sin presupuesto de error para problemas de la capa de aplicación, fallos de integración o mantenimiento planificado) |
| Documentación de SLO | ⚠️ SLO definidos por componente técnico en vez de por capacidad comercial de cara al usuario (disponibilidad de componente necesaria pero insuficiente para la fiabilidad de la experiencia del usuario) |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Estrategia de despliegue regional | ✅ La implementación de una sola región con redundancia Hyperforce gestionada por plataforma (múltiples zonas de disponibilidad, fallo automático de infraestructura) proporciona un SLO del 99,9% para la mayoría de las soluciones |
| Arquitectura de múltiples organizaciones | ✅ Patrones de múltiples organizaciones solo cuando el negocio requiere RPO/RTO garantizado más allá de las funciones de la plataforma, aislamiento de datos geográficos reguladores o independencia regional completa (activo-pasivo o activo-activo con sincronización de datos) |
| Replicación de datos | ✅ Cambiar Captura de datos para datos críticos (RPO casi en tiempo real, minutos), Eventos de plataforma para eventos comerciales casi en tiempo real, extracción de API masiva programada 2.0 para datos de referencia (RPO de 24 horas) |
| Supervisión de estado de plataforma | ✅ Suscripción a notificaciones de estado de Trust.salesforce.com y API de estado específicas de instancia que permiten una respuesta proactiva a incidentes, plazos de mantenimiento e impactos en el rendimiento |
| Gestión de carga dinámica | ✅ Las soluciones responden al estado de estado de la plataforma reduciendo el procesamiento por lotes no crítico durante la degradación, aplazando trabajos en segundo plano durante plazos de mantenimiento |
| Uso de Scale Center | ✅ La revisión semanal del Centro de escala identifica transacciones y operaciones de larga ejecución que consumen recursos desproporcionados, lo que permite la solución arquitectónica antes del impacto sobre el usuario |
| Capas de detección de fallos | ✅ Detección de múltiples niveles: fallos de plataforma a través de API de estado, fallos de integración a través de supervisión de tiempo de espera, fallos de aplicación a través de registro de excepciones, degradación del rendimiento a través de percentiles de latencia, advertencias de capacidad a través de Proactive Monitoring |
| Umbrales de alerta | ✅ Las alertas se desencadenan en patrones de índice de error (por ejemplo, 5 tiempos de espera de API en 60 segundos) o degradación sostenida, no fallos aislados que son normales en sistemas distribuidos |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Diseño de múltiples organizaciones | ⚠️ La arquitectura de múltiples organizaciones implementada “por si acaso” sin requisitos comerciales documentados que justifiquen la complejidad operativa de la sincronización de datos, el aprovisionamiento de usuarios, la coordinación de la implementación |
| Supervisión de estado de plataforma | ⚠️ Ignorar notificaciones de estado Trust.salesforce.com, descubrir plazos de mantenimiento cuando los usuarios informan de fallos (respuesta reactiva en vez de proactiva) |
| Detección de fallos | ⚠️ Alerta sobre cada error individual independientemente del índice (genera fatiga de alerta ocultando señales críticas); el tiempo de espera de API única desencadena el agotamiento de la página (reacción excesiva al comportamiento normal del sistema distribuido) |
| Replicación de datos | ⚠️ Sin supervisión específica de la integración, solo descubra fallos de integración cuando los usuarios informen de operaciones bloqueadas (falta de visibilidad en el estado del sistema externo) |
| Estrategia de redundancia | ⚠️ Llamada síncrona a servicio de enriquecimiento externo sin tiempo de espera o reserva (usuario bloqueado cuando el servicio externo es lento o no está disponible) |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Supervisión de usuario real (RUM) | ✅ Latencia de usuario real medida a través de análisis de Experience Cloud o instrumentación personalizada reflejando condiciones de red reales, rendimiento de dispositivos, distribución geográfica |
| Supervisión sintética | ✅ Transacciones automatizadas desde múltiples ubicaciones validando la disponibilidad y el rendimiento antes de que los usuarios informen de problemas (por ejemplo, envío de pedidos cada 15 minutos desde 3 regiones) |
| Rastreo de transacciones | ✅ Operaciones de múltiples pasos instrumentadas con cronología por paso que identifica cuellos de botella (por ejemplo, la llamada de validación de direcciones del paso 3 representa el 70% de la latencia total) |
| Optimización de consultas | ✅ Consultas selectivas con filtros indexados, consultas de relaciones que reducen recorridos de ida y vuelta, consideración del optimizador de consultas con volúmenes de datos a escala de producción (el comportamiento cambia drásticamente con más de 10 registros) |
| Utilización de caché de plataforma | ✅ Particiones de caché de sesión u organización que sirven datos de referencia a los que se accede con frecuencia, rellenadas previamente durante operaciones correctas que proporcionan datos obsoletos pero disponibles cuando la API en tiempo real no está disponible |
| Configuración de tiempo de espera | ✅ Llamadas síncronas de cara al usuario de 5 a 10 segundos (interfaz de usuario con capacidad de respuesta), llamadas asíncronas en segundo plano de 30 a 60 segundos (rendimiento externo variable), procesamiento por lotes de 120 segundos (no hay usuario esperando); presupuesto total entre múltiples llamadas por transacción |
| Supervisión de la latencia de integración | ✅ percentiles de latencia p50/p95/p99 por integración con SLO por extremo; anomalías de latencia (tiempos de respuesta a la deriva hacia arriba) indican saturación de capacidad antes del fallo completo |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Estrategia de supervisión | ⚠️ Supervisar solo mediciones de infraestructura (CPU de servidor, ancho de banda de red) sin medición de flujo de cara al usuario (las mediciones no reflejan la experiencia de usuario real) |
| Estrategia de caché | ⚠️ Sin utilización de caché de plataforma para datos de referencia a los que se accede con frecuencia (consultas repetidas para los mismos datos que aumentan la latencia y consumen límites de SOQL) |
| Configuración de tiempo de espera | ⚠️ Llamada de flujo síncrono con un tiempo de espera de 120 segundos que provoca que el usuario mire fijamente el spinner de carga durante 2 minutos (debe utilizar un tiempo de espera de 5-10 segundos con reserva) |
| Pruebas de rendimiento | ⚠️ Pruebas a pequeña escala con volúmenes de datos mínimos (el comportamiento del optimizador de consultas cambia drásticamente a más de 10 millones de registros haciendo que los resultados a pequeña escala sean engañosos) |
| Diseño de integración | ⚠️ Sin rastreo a nivel de transacción de flujos de trabajo de múltiples pasos (paso de cuello de botella invisible en mediciones agregadas) |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Patrones de escala horizontal | ✅ Carga de trabajo distribuida entre múltiples recursos: masificación procesa múltiples registros por transacción, el procesamiento asíncrono distribuye el trabajo en el tiempo, la partición de datos distribuye la carga entre límites |
| Configuración de procesamiento por lotes | ✅ Rendimiento de equilibrio de tamaño de lote óptimo y límites reguladores (2.000 registros por ejecución de Apex por lotes, 200 registros por invocación de desencadenador, 25 solicitudes por llamada de API compuesta) |
| Gestión de frecuencia de API | ✅ El almacenamiento en caché y lote de integración reduce el consumo de API, supervisa la asignación de API de 24 horas por edición, la planificación de capacidad agrega licencias o limita los aumentos antes del agotamiento |
| Ejecución simultánea | ✅ Trabajos por lotes paralelos para datos particionados (5 lotes de acumulación regionales que se ejecutan simultáneamente), suscriptores de eventos de plataforma que procesan transmisiones al mismo tiempo |
| Supervisión de profundidad de cola | ✅ Para integraciones asíncronas, las tendencias de profundidad de cola indican que el procesamiento está a la zaga del índice de producción que requiere aumento de capacidad u optimización de rendimiento |
| Detección de anomalías de volumen | ✅ Los volúmenes de transacciones significativamente por encima/por debajo de los patrones esperados pueden indicar procesos desbocados que requieren investigación y regulación |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Procesamiento por lotes | ⚠️ Procesar todos los registros secuencialmente cuando el volumen de datos requiere ejecución paralela particionada (la partición basada en fecha, basada en tipo de registro o basada en propietario activa el procesamiento simultáneo) |
| Consumo de API | ⚠️ El patrón de integración agrega un consumo de API del 25% sin planificación de capacidad (los errores repentinos de “límite de API superado” afectan a los usuarios) |
| Supervisión de colas | ⚠️ Sin supervisión de la profundidad de cola de integración asíncrona (el procesamiento está por debajo del índice de producción sin visibilidad) |
| Gestión de límites reguladores | ⚠️ Operaciones síncronas que procesan grandes volúmenes alcanzando el tamaño de pila o límites de tiempo de CPU (deben pasar al procesamiento asíncrono con límites exclusivos) |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Jerarquía de criticidad de funciones | ✅ Niveles definidos: Crítica (ingresos/cumplimiento, nunca degradada), Importante (flujos de trabajo principales, degradada solo durante incidentes importantes), Apoyo (experiencia mejorada, desactivada durante fallo de integración), Opcional (buena opción, desactivada durante alta carga) |
| Implementación de disyuntor | ✅ Estados de circuito (Cerrado = normal, Abierto = falla inmediatamente después del umbral, Medio abierto = sonda de recuperación); Caché de plataforma almacena el estado, Cambios de difusión de Eventos de plataforma; se abre después de fallos consecutivos (por ejemplo, 10 fallos) |
| Lógica de reintento | ✅ Retroceso exponencial para fallos transitorios (1s, 2s, 4s, 8s, tope a 30-60s); reintentar tiempos de espera de red y errores 5xx con retroceso, reintentar 429 límites de frecuencia después del encabezado Reintentar después; nunca reintentar errores 4xx de cliente o errores de límite regulador en la misma transacción |
| Estrategias de reserva | ✅ Fuentes de datos alternativas (Caché de plataforma cuando la API en tiempo real no está disponible), comportamiento predeterminado (reglas estándar cuando el servicio de personalización está desactivado), proceso manual (interfaz de administrador para transacciones atascadas), cola para reintentarlo (Eventos de plataforma con 72h de reproducción) |
| Arquitectura de gestión de errores | ✅ Fallo rápido (validar entradas en la entrada), fallo con gracia (proceso 197 de 200 registros cuando 3 fallan validación), fallo informativo (registro con Id. de transacción, contexto de usuario, rastreo de pila), fallo seguro (revertir transacciones parciales, nunca exponer internos a usuarios) |
| Automatización de recuperación | ✅ La supervisión de plataforma desencadena la recuperación automatizada: mecanismos de reintento asíncrono, colas de letra muerta para procesamiento fallido, flujos de trabajo de autocuración que permiten una recuperación rápida sin intervención manual |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Dependencia de integración | ⚠️ El envío de pedidos falla completamente cuando el servicio de validación de direcciones externas se desactiva (flujo crítico bloqueado por la función de asistencia; debería degradarse con gracia con la revisión manual) |
| Estrategia de disyuntor | ⚠️ No hay disyuntor en la llamada externa que provoque que cada transacción espere 120 segundos para que se agote el tiempo de espera cuando el sistema externo esté apagado (todos los usuarios se vieron afectados por un fallo de integración) |
| Lógica de reintento | ⚠️ Reintentar el error de límite de CPU Apex superado inmediatamente en el mismo contexto de transacción (volverá a fallar; debería volver a ponerse en cola como operación asíncrona con límites exclusivos) |
| Lógica de reintento | ⚠️ Reintentar indefinidamente hasta el éxito (riesgo de bucle infinito, la transacción nunca se completa; debe limitar el máximo de intentos de reintento) |
| Gestión de errores | ⚠️ El bloqueo de captura de prueba traga excepciones sin registro (fallos invisibles para los operadores que impiden el diagnóstico y la remediación) |
| Gestión de errores | ⚠️ Mostrar rastreo de pila al usuario final en página Lightning (riesgo de seguridad que revela detalles de implementación, mala experiencia de usuario) |
| Estrategia de reserva | ⚠️ El servicio de cálculo de impuestos falla bloqueando todos los envíos de pedidos (función crítica sin reserva; debe hacer cola para el procesamiento manual o utilizar tasas predeterminadas) |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Modelado de salud | ✅ Estado de salud agregado: Estado de servicio (índice de operación correcta >99.5% verde, 98-99.5% amarillo, <98% rojo), Estado de integración (todos respondiendo verde, amarillo degradado, rojo abierto del disyuntor), Estado de datos (verde de corriente de sincronización, detrás de amarillo, rojo obsoleto/fallido), Estado de capacidad (<70% verde, 70-85% amarillo, >85% rojo) |
| Supervisión de eventos | ✅ Objetos EventLogFile con entrega 24h/1h enrutada a SIEM externo para su retención más allá de los límites de retención nativos; captura llamadas de API, vistas de página, exportaciones de informes, actividad de inicio de sesión, ejecución Apex |
| Alertas de Proactive Monitoring | ✅ La evaluación continua aflora picos de límite de solicitudes de API (75% umbral desencadena investigación), fallos de ejecución Apex simultáneos, problemas de límite de filas SOQL, tendencias de consumo de almacenamiento |
| Panel de salud de integración | ✅ Mediciones por integración: índice de error (<1% objetivo), latencia p50/p95/p99 con SLO, índice de tiempo de espera (<0,1% objetivo), estado del disyuntor, profundidad de cola asíncrona; registros estructurados con Id. de solicitud, extremo, código de respuesta, duración |
| Diseño de alerta con capacidad de acción | ✅ Cada alerta define quién responde, qué comprueba, cómo remedia; incluye umbral cruzado, valor actual, tendencia reciente, vínculo de panel, vínculo de libro de ejecución; gravedad coincidente con urgencia (páginas CRÍTICAS a petición para repercusión de usuario, correos electrónicos de ADVERTENCIA para preocupaciones de tendencia) |
| Detección de anomalías | ✅ Anomalías de volumen (300% de la carga típica), anomalías de índice de error (2% frente a 0,5% típicas incluso si están por debajo del umbral del 5%), desviación de latencia (tendencia gradual al alza), anomalías de comportamiento (patrones de inicio de sesión inusuales, trabajos por lotes fuera de la programación); se utilizan para guiar la investigación no desencadenar una distribución inmediata |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Supervisión de eventos | ⚠️ Supervisión de eventos activada pero nunca exportada (retención nativa insuficiente para análisis de tendencias, datos históricos perdidos) |
| Diseño de alerta | ⚠️ Mensaje de alerta “Se produjo un error” sin contexto, umbral o acción de respuesta (genera fatiga de alerta, los operadores no pueden actuar de forma efectiva) |
| Gravedad de alerta | ⚠️ Tratar todas las anomalías como alertas críticas (la alta tasa de falsos positivos crea fatiga en las alertas haciendo que se pierdan alertas críticas) |
| Supervisión de la salud | ⚠️ Sin modelo de salud agregado, los operadores se vieron abrumados con mediciones técnicas individuales que carecen de patrones entre sistemas |
| Supervisión de integración | ⚠️ Sin índice de error específico de integración, latencia o seguimiento del estado del disyuntor (fallos de integración descubiertos de forma reactiva a través de informes de usuario) |
| Supervisión de capacidad | ⚠️ Sin Proactive Monitoring o revisión de Scale Center (los riesgos de fiabilidad de transacciones que requieren muchos recursos pasan desapercibidos hasta el impacto en la producción) |
Para obtener ejemplos en línea y directrices detalladas, consulte el pilar Fiabilidad o navegue por el explorador de patrones y antipatrones.