Patrones de disponibilidad y desempeño
Obtenga más información acerca de la fiabilidad bien arquitectónica → Arquitectura de alta disponibilidad
Patrones
| Dónde buscar | Qué aspecto tiene |
|---|---|
| Análisis de impacto de negocio | ✅ SLO definidos por capacidad de negocio (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 de negocio con justificación documentada (por ejemplo, creación de reportes internos por lotes 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 monitoreo activo, 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 soluciones 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 monitoreo | ✅ 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 Event Monitoring, Realizació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%” (costo no justificado ignorando las diferencias de criticidad de negocio entre operaciones de ingresos y herramientas de administrador interno) |
| Estrategia de monitoreo | ⚠️ Monitoreo 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 de negocio de cara al usuario (disponibilidad de componente necesaria pero insuficiente para la fiabilidad de la experiencia del usuario) |
Patrones
| Dónde buscar | Qué 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 de infraestructura automático) 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, el aislamiento de datos geográficos regulatorios o la independencia regional completa (activo-pasivo o activo-activo con sincronización de datos) |
| Replicación de datos | ✅ Captura de datos de cambios para datos críticos (RPO casi en tiempo real, minutos), Eventos de plataforma para eventos de negocio casi en tiempo real, extracción de API masiva 2.0 programada para datos de referencia (RPO de 24 horas) |
| Monitoreo de estado de plataforma | ✅ Suscripción a notificaciones de estado Trust.salesforce.com y API de estado específicas de instancias que permiten una respuesta proactiva a incidentes, plazos de mantenimiento e impactos en el desempeño |
| Gestión de carga dinámica | ✅ Las soluciones responden al 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 de Scale Center identifica transacciones y operaciones de larga ejecución que consumen recursos desproporcionados, lo que permite la reparación arquitectónica antes de la repercusión 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 monitoreo de tiempo de espera, fallos de aplicación a través de registro de excepciones, degradación de desempeño 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 | ⚠️ Arquitectura multiorganización implementada “por si acaso” sin requisitos de negocio documentados que justifiquen la complejidad operativa de la sincronización de datos, el aprovisionamiento de usuarios, la coordinación de la implementación |
| Monitoreo de estado de plataforma | ⚠️ Ignorar notificaciones de estado Trust.salesforce.com, descubrir plazos de mantenimiento cuando los usuarios reportan fallos (respuesta reactiva en vez de proactiva) |
| Detección de fallos | ⚠️ Alertar sobre cada error individual independientemente de la frecuencia (genera fatiga de alerta ocultando señales críticas); el tiempo de espera de API única desencadena el agotamiento de página (reacción excesiva al comportamiento normal del sistema distribuido) |
| Replicación de datos | ⚠️ Sin monitoreo específico de la integración, solo descubra fallos de integración cuando los usuarios reporten operaciones bloqueadas (falta 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é aspecto tiene |
|---|---|
| Monitoreo 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, desempeño de dispositivos, distribución geográfica |
| Monitoreo sintético | ✅ Transacciones automatizadas desde múltiples ubicaciones validando la disponibilidad y el desempeño antes de que los usuarios reporten 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 identificando cuellos de botella (por ejemplo, llamada de validación de dirección de paso 3 representa el 70% de la latencia total) |
| Optimización de consultas | ✅ Consultas selectivas con filtros indexados, consultas de relaciones que reducen los 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 satisfactorias 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 (desempeño externo variable), procesamiento por lotes de 120 segundos (sin espera de usuario); total de presupuesto entre múltiples llamadas por transacción |
| Monitoreo de 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 monitoreo | ⚠️ Monitorear 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 hace que el usuario mire fijamente la centrifugadora de carga durante 2 minutos (debe utilizar un tiempo de espera de 5-10 segundos con reserva) |
| Pruebas de desempeño | ⚠️ Pruebas a pequeña escala con volúmenes de datos mínimos (el comportamiento del optimizador de consultas cambia drásticamente en más de 10 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é aspecto tiene |
|---|---|
| Patrones de escala horizontal | ✅ Carga de trabajo distribuida entre múltiples recursos: La 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 | ✅ Límites reguladores y rendimiento de equilibrio de tamaño de lote óptimo (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, monitorea 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 ejecutándose simultáneamente), suscriptores de Eventos de plataforma procesando transmisiones al mismo tiempo |
| Monitoreo 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 requiriendo un 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 estrangulació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) |
| Monitoreo de colas | ⚠️ No hay monitoreo de la profundidad de la cola de integración asíncrona (el procesamiento queda atrás del índice de producción sin visibilidad) |
| Gestión de límites reguladores | ⚠️ Operaciones síncronas que procesan grandes volúmenes alcanzando límites de tiempo de CPU o tamaño de pila (debe pasar a procesamiento asíncrono con límites exclusivos) |
Patrones
| Dónde buscar | Qué aspecto tiene |
|---|---|
| Jerarquía de criticidad de funciones | ✅ Niveles definidos: Crítico (ingresos/cumplimiento, nunca degradado), Importante (flujos de trabajo principales, degradados solo durante incidentes importantes), Compatible (experiencia mejorada, desactivada durante fallo de integración), Opcional (agradable, desactivado durante carga alta) |
| Implementación de disyuntores | ✅ Estados de circuito (Cerrado = normal, Abierto = falla inmediatamente después del umbral, Medio abierto = sonda de recuperación); Caché de plataforma almacena el estado, Eventos de plataforma emite cambios; 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á apagado), proceso manual (interfaz de administrador para transacciones atascadas), cola para reintentarlo (Eventos de plataforma con 72h de reproducción) |
| Arquitectura de tratamiento de errores | ✅ Fallo rápido (validar entradas en la entrada), fallo con gracia (proceso 197 de 200 registros cuando 3 fallan la validación), fallo informativo (registro con Id. de transacción, contexto de usuario, rastreo de pila), fallo seguro (revertir transacciones parciales, nunca exponer elementos internos a usuarios) |
| Automatización de recuperación | ✅ El monitoreo de plataforma desencadena la recuperación automatizada: mecanismos de reintento asíncronos, 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 por completo cuando el servicio de validación de direcciones externas se interrumpe (flujo crítico bloqueado por la función de asistencia; debe degradarse con gracia con la revisión manual) |
| Estrategia de disyuntor | ⚠️ No hay interruptor en la llamada externa que haga que cada transacción espere 120 segundos para que se agote el tiempo de espera cuando el sistema externo no esté disponible (todos los usuarios afectados por un fallo de integración) |
| Lógica de reintento | ⚠️ Reintentar error de límite de CPU Apex superado inmediatamente en el mismo contexto de transacción (volverá a fallar; debe 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 | ⚠️ Intentar capturar bloqueo traga excepción sin registro (fallo invisible para operadores que impide el diagnóstico y la reparación) |
| Gestión de errores | ⚠️ Mostrar rastreo de pila al usuario final en página Lightning (riesgo de seguridad revelando 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 (capacidad crítica sin reserva; debe hacer cola para el procesamiento manual o utilizar tipos predeterminados) |
Patrones
| Dónde buscar | Qué 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, interruptor abierto rojo), Estado de datos (verde corriente de sincronización, detrás de amarillo, rojo obsoleto/fallido), Estado de capacidad (<70% verde, 70-85% amarillo, >85% rojo) |
| Monitoreo 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 reportes, 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 (investigación de desencadenadores de umbral del 75%), fallos de ejecución Apex simultáneos, problemas de límite de filas SOQL, tendencias de consumo de almacenamiento |
| Tablero 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 la 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 tablero, vínculo de libro de ejecuciones; gravedad coincidente con urgencia (páginas CRÍTICAS a petición para repercusión en el usuario, emails 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 por debajo del umbral del 5%), desviación de latencia (tendencia ascendente gradual), anomalías de comportamiento (patrones de inicio de sesión inusuales, trabajos por lotes fuera de la programación); se utiliza para guiar la investigación no desencadenar una distribución inmediata |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Monitoreo de eventos | ⚠️ Monitoreo de eventos activado pero nunca exportado (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 clasificar de forma efectiva) |
| Alertar gravedad | ⚠️ 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) |
| Monitoreo de salud | ⚠️ Sin modelo de salud agregado, los operadores se vieron abrumados con mediciones técnicas individuales que carecían de patrones entre sistemas |
| Monitoreo de integración | ⚠️ No hay seguimiento del índice de error específico de la integración, la latencia o el estado del disyuntor (fallos de integración descubiertos de forma reactiva a través de reportes de usuario) |
| Monitoreo de capacidad | ⚠️ Sin revisión Proactive Monitoring o Scale Center (los riesgos de fiabilidad de transacciones intensivas en 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.