Observabilidad y monitoreo: patrones
Obtenga más información acerca de Excelencia operativa bien arquitectónica → Observabilidad y monitoreo
Patrones
| Dónde buscar | Qué aspecto tiene |
|---|---|
| Plataforma | Monitoreo de eventos | ✅ Monitoreo de eventos está diseñado en la arquitectura inicial capturando identificadores de correlación que rastrean solicitudes a través de cadenas de procesamiento asíncrono e integraciones externas |
| Plataforma | Monitoreo de eventos | ✅ La infraestructura de observabilidad se incluye desde el sprint inicial en vez de actualizarse después de que los incidentes de producción resulten imposibles de diagnosticar |
| Plataforma | Integración | ✅ Los puntos de control de integración se colocan deliberadamente para permitir el rastreo de solicitudes entre límites del sistema |
| Plataforma | Eventos de plataforma | ✅ Las cargas de Evento de plataforma están estructuradas para visibilidad operativa con marcadores de transacciones y contexto |
| Plataforma | Registro personalizado | ✅ El marco de trabajo de registro personalizado captura eventos discretos con información contextual completa incluyendo identidad de usuario, marca de tiempo, duración y resultado |
| Plataforma | Mediciones | ✅ Las mediciones agregan mediciones numéricas a lo largo del tiempo revelando tendencias incluyendo índices de consumo de API, distribuciones de tiempo de CPU Apex e índices de éxito de trabajos por lotes |
| Plataforma | Rastreo distribuido | ✅ Los rastreos conectan llamadas de API síncronas con cadenas de procesamiento asíncronas, eventos de plataforma con ejecuciones de suscriptores y solicitudes de integración con respuestas del sistema externo |
| Plataforma | Observabilidad | ✅ La observabilidad permite a los operadores responder a preguntas arbitrarias sobre el comportamiento del sistema sin implementar nueva instrumentación para cada investigación |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Monitoreo de eventos | ⚠️ La solución se inicia sin registro personalizado, requiriendo una refactorización importante seis meses después cuando los incidentes de producción resultan imposibles de diagnosticar solo con registros de plataforma |
| Plataforma | Monitoreo de eventos | ⚠️ La capacidad de observación se actualiza en soluciones existentes que requieren cambios de instrumentación que afectan a la mayoría de los componentes y corren el riesgo de fallos durante el trabajo de mejora operativa |
| Plataforma | Integración | ⚠️ Se producen fallos de integración pero no se pueden trazar rutas de solicitud entre límites del sistema sin telemetría integral |
| Plataforma | Eventos de plataforma | ⚠️ Las cargas de Evento de plataforma carecen de contexto operativo, lo que hace que la investigación de incidentes dependa de la búsqueda en múltiples sistemas |
| Plataforma | Registro personalizado | ⚠️ Los registros capturan contexto insuficiente; las investigaciones requieren problemas de reproducción para recopilar información adicional |
| Plataforma | Observabilidad | ⚠️ Los tableros predefinidos no pueden responder a preguntas inesperadas sobre el comportamiento del sistema que emerge en producción |
Patrones
| Dónde buscar | Qué aspecto tiene |
|---|---|
| Plataforma | Monitoreo de eventos | ✅ Monitoreo de eventos está activado para entornos de producción que capturan el uso de API, la actividad de inicio de sesión, la ejecución Apex, consultas SOQL, páginas Visualforce, páginas Lightning y ejecuciones de reportes |
| Plataforma | Monitoreo de eventos | ✅ Los archivos de registro de eventos se exportan cada hora a una plataforma de registro centralizada, lo que permite el análisis histórico más allá de la retención de la plataforma nativa |
| Plataforma | Monitoreo de eventos | ✅ La agregación de registros externos activa la correlación con la telemetría de compañía desde otros sistemas para el rastreo de transacciones de extremo a extremo |
| Plataforma | Monitoreo de eventos | ✅ Los archivos de registro de eventos se mantienen cumpliendo los requisitos normativos para la creación de reportes de cumplimiento y el análisis de tendencias a largo plazo |
| Plataforma | Proactive Monitoring | ✅ Los umbrales Proactive Monitoring se ajustan deliberadamente basándose en el intervalo operativo normal específico de la organización en vez de aceptar valores predeterminados |
| Plataforma | Proactive Monitoring | ✅ Las alertas Proactive Monitoring detectan picos de límite de API, fallos Apex simultáneos, enfoques de límite de filas SOQL y contención de bloqueo de filas antes de incidentes visibles por el usuario |
| Plataforma | Proactive Monitoring | ✅ Los umbrales ajustados generan señales con capacidad de acción en las que los equipos Trust y actúan creando círculos virtuosos de mejora continua |
| Plataforma | Scale Center | ✅ Las líneas base de Centro de escala se establecen durante la estabilización de la solución y se vuelven a visitar después de cada versión principal |
| Plataforma | Scale Center | ✅ Scale Center revela qué operaciones consumen más recursos, qué transacciones se acercan a umbrales de tiempo de espera y dónde la inversión de optimización produce la mayor repercusión |
| Plataforma | Scale Center | ✅ El tiempo de transacción aumenta desde la investigación de solicitud de línea base revelando patrones de consulta N+1 no intencionados introducidos en la implementación más reciente |
| Plataforma | Configuración Seguimiento de auditoría | ✅ Configuración Seguimiento de auditoría realiza un seguimiento de los cambios de configuración incluyendo modificaciones de permisos, implementaciones de metadatos y actualizaciones de parámetros de seguridad con retención de hasta 180 días |
| Plataforma | Configuración Seguimiento de auditoría | ✅ Las entradas del seguimiento de auditoría de configuración se exportan para su retención más allá de 180 días cuando los requisitos contractuales o de cumplimiento exigen plazos históricos más largos |
| Plataforma | Shield | ✅ Seguimiento de auditoría de campo está activado de forma selectiva para campos que contienen datos confidenciales, datos regulados que requieren historial de cambios o datos de negocio críticos |
| Plataforma | Shield | ✅ Seguimiento de auditoría de campo proporciona hasta 10 años de retención para campos donde la comprensión de valores históricos ayuda a operaciones y creación de reportes de cumplimiento |
| Plataforma | Comprobación de estado | ✅ Las revisiones de Comprobación de estado se programan trimestralmente con resultados solucionados basándose en la prioridad de riesgo para el medio ambiente |
| Plataforma | Comprobación de estado | ✅ Los resultados de Comprobación del estado reciben una revisión deliberada en vez de aceptación pasiva; los controles de compensación o las diferentes tolerancias al riesgo están documentados |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Monitoreo de eventos | ⚠️ Monitoreo de eventos está activado pero los registros nunca se exportan, limitando las investigaciones al plazo de retención nativo e impidiendo el análisis de tendencias históricas |
| Plataforma | Monitoreo de eventos | ⚠️ Los archivos de registro de eventos permanecen en el almacenamiento de plataforma; la agregación externa no está implementada evitando la planificación de capacidad a largo plazo |
| Plataforma | Proactive Monitoring | ⚠️ Proactive Monitoring utiliza umbrales predeterminados que son demasiado sensibles o demasiado laxos, generando alertas ruidosas que los equipos aprenden a ignorar |
| Plataforma | Proactive Monitoring | ⚠️ El ruido de alerta destruye Trust en el sistema de monitoreo; los equipos dejan de responder a señales válidas |
| Plataforma | Scale Center | ⚠️ Scale Center está activado pero nunca revisado de forma proactiva; el desempeño se degrada lentamente hasta que los usuarios se quejan después de meses de degradación incremental |
| Plataforma | Scale Center | ⚠️ Las mediciones de desempeño carecen de contexto de línea base; no está claro si los tiempos de transacción de 3 segundos son típicos, mejorando o degradándose |
| Plataforma | Configuración Seguimiento de auditoría | ⚠️ Configuración Seguimiento de auditoría no se exporta; las limitaciones de retención impiden investigaciones de seguridad o validación de cumplimiento más allá de 180 días |
| Plataforma | Shield | ⚠️ Seguimiento de auditoría de campo está activado para todos los campos en vez de selectivamente, creando costos de almacenamiento sin el valor de cumplimiento correspondiente |
| Plataforma | Comprobación de estado | ⚠️ Los resultados de Comprobación de estado nunca se revisan; la configuración de seguridad se desvía de las recomendaciones de línea base sin aceptación deliberada |
Patrones
| Dónde buscar | Qué aspecto tiene |
|---|---|
| Plataforma | Flujos de usuario | ✅ Los flujos de usuario críticos se definen basándose en la repercusión de negocio y monitoreados de extremo a extremo para índices de éxito, tiempo de realización, puntos de abandono e índices de error |
| Plataforma | Flujos de usuario | ✅ Los flujos críticos incluyen actividades generadoras de ingresos (envío de pedidos, ejecución de contratos, cierre de oportunidades), actividades de gran volumen (inicio de sesión, búsqueda, creación de registros) y actividades de cumplimiento obligatorio (captura de consentimiento, realización de derechos de titulares de datos) |
| Plataforma | Flujos de usuario | ✅ Los flujos se instrumentan con marcadores de transacciones que indican inicio, finalización, abandono y fallo en cada paso significativo |
| Plataforma | Flujos de usuario | ✅ Flujo de envío de pedidos instrumentado con eventos de plataforma en cada etapa (validación de carrito, Comprobación de inventario, procesamiento de pagos, desencadenador de realización) mostrando el índice de éxito por etapa |
| Plataforma | Flujos de usuario | ✅ El monitoreo a nivel de flujo revela problemas invisibles en el monitoreo a nivel de componente porque pueden producirse fallos en cualquier punto de transición |
| Plataforma | Flujos de usuario | ✅ Las alertas se activan cuando los índices de éxito de flujos caen por debajo de umbrales aceptables o la duración supera objetivos de latencia |
| Plataforma | Integración | ✅ El monitoreo de estado de integración detecta fallos del sistema externo, problemas de red, problemas de autenticación y enfoques de límite de frecuencia antes de caer en fallos de cara al usuario |
| Plataforma | Integración | ✅ Alertas de monitoreo de índices de éxito al caer por debajo del 99% para integraciones síncronas críticas |
| Plataforma | Integración | ✅ Alertas de monitoreo de distribución de errores cuando aparecen nuevos tipos de error que no existían en la línea base |
| Plataforma | Integración | ✅ Monitoreo de percentil de latencia (p95) alerta cuando supera los 3 segundos para llamadas de cara al usuario síncronas |
| Plataforma | Integración | ✅ Alertas de monitoreo de desempeño cuando supera el 80% del límite de frecuencia conocido o umbral de SLA |
| Plataforma | Integración | ✅ Alertas de monitoreo de estado de disyuntor cuando se abre cualquier circuito indicando degradación del sistema externo |
| Plataforma | Integración | ✅ Alertas de monitoreo de índice de reintento cuando el índice de reintento sostenido supera el 5% indicando problemas de fiabilidad |
| Plataforma | Integración | ✅ Rutas de telemetría de integración a plataformas de monitoreo centralizadas que permiten la correlación entre límites del sistema |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Flujos de usuario | ⚠️ Los componentes se monitorean de forma independiente mostrando un funcionamiento saludable mientras que el 12% de los usuarios abandonan flujos críticos sin visibilidad de por qué |
| Plataforma | Flujos de usuario | ⚠️ Los tableros de estado de componentes se muestran de color verde mientras que los usuarios no pueden completar flujos de trabajo críticos que revelan fallos de arquitectura de monitoreo |
| Plataforma | Flujos de usuario | ⚠️ La trayectoria del usuario tocando múltiples clases, flujos, eventos de plataforma e integraciones externas de Apex carece de visibilidad de extremo a extremo |
| Plataforma | Flujos de usuario | ⚠️ Las trayectorias de negocio críticas carecen de instrumentación; se desconocen los índices de éxito y los puntos de abandono |
| Plataforma | Integración | ⚠️ Los fallos de integración solo se detectan después de caer en cascada en fallos de cara al usuario en vez de por anticipado |
| Plataforma | Integración | ⚠️ La telemetría de integración permanece aislada en sistemas individuales evitando la correlación y el análisis de causa raíz más allá de los límites |
| Plataforma | Integración | ⚠️ Monitoreo de alertas sobre síntomas posteriores después de que se produzca el daño en vez de revelar causas raíz temprano |
Patrones
| Dónde buscar | Qué aspecto tiene |
|---|---|
| Plataforma | SLI | ✅ Las SLI de disponibilidad miden el porcentaje de tiempo que los flujos críticos se ejecutan correctamente desde la perspectiva del usuario (reciben el resultado esperado, no solo 200 códigos de estado) |
| Plataforma | SLI | ✅ Los SLI de latencia miden el tiempo para completar operaciones en p50 (mediana), p90 (percentil 90 excluyendo anomalías), p95 (percentil 95 excluyendo peores anomalías) y p99 (percentil 99 mostrando la peor experiencia) |
| Plataforma | SLI | ✅ Los objetivos de latencia varían según la criticidad de la operación y la expectativa del usuario (la búsqueda de 500 ms se siente instantánea, la misma latencia para escribir entradas se siente lenta) |
| Plataforma | SLI | ✅ Los SLI de rendimiento miden el volumen de operaciones satisfactorias por unidad de tiempo revelando tendencias de crecimiento y utilización de capacidad |
| Plataforma | SLI | ✅ El rendimiento combinado con la latencia revela si el sistema mantiene el desempeño bajo carga creciente o se degrada a medida que crece el volumen |
| Plataforma | SLI | ✅ Los SLI de índice de error distinguen entre tipos de error (errores de usuario como fallos de validación frente a errores del sistema como excepciones de límite regulador) |
| Plataforma | SLO | ✅ Los objetivos de nivel de servicio se establecen definiendo umbrales de SLI aceptables basándose en requisitos de negocio antes de seleccionar patrones de arquitectura |
| Plataforma | SLO | ✅ Requisito de negocio “Los representantes de ventas deben ver actualizaciones de oportunidades en 5 segundos” dirige SLO “Cargas de página de detalles de oportunidad completadas en 3 segundos en p95” que dirige decisiones de arquitectura |
| Plataforma | SLO | ✅ Los SLO surgen de requisitos de negocio y dirigen decisiones arquitectónicas en vez de definirse basándose en lo que el sistema logra actualmente |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | SLI | ⚠️ La disponibilidad se mide desde la perspectiva técnica (código de estado 200) en vez de la perspectiva del usuario (recibir el resultado esperado) |
| Plataforma | SLI | ⚠️ La latencia se mide solo en la mediana sin comprender la experiencia del usuario en el peor de los casos con percentiles p95 o p99 |
| Plataforma | SLI | ⚠️ Los SLI de índice de error no distinguen entre errores de usuario y errores del sistema, enmascarando diferentes problemas que requieren soluciones diferentes |
| Plataforma | SLO | ⚠️ La arquitectura se construye primero, luego el SLO se define como “lo que alcancemos actualmente” lo que lleva a la aceptación de cargas de página de 12 segundos porque el diseño del sistema nunca consideró los requisitos del usuario |
| Plataforma | SLO | ⚠️ Los SLO están dirigidos por la arquitectura en vez de por el negocio, estableciendo objetivos basándose en lo que el sistema logra en vez de lo que los usuarios necesitan |
Patrones
| Dónde buscar | Qué aspecto tiene |
|---|---|
| Plataforma | Alertas | ✅ La clasificación de gravedad enruta incidentes críticos (producción no disponible, riesgo de corrupción de datos, compromiso de seguridad) a ingenieros de página de inmediato |
| Plataforma | Alertas | ✅ Los incidentes de alta gravedad (desempeño deteriorado, cortes parciales) generan notificaciones para una investigación rápida dentro del horario de oficina |
| Plataforma | Alertas | ✅ Las advertencias (acercándose a umbrales, desviación de configuración) generan notificaciones de resúmenes diarias para una solución proactiva |
| Plataforma | Alertas | ✅ El contexto de alerta incluye conteo de usuarios afectados, mensajes de error, rastreos de pilas, implementaciones recientes, alertas relacionadas y vínculos a tableros relevantes |
| Plataforma | Alertas | ✅ El contexto enriquecido reduce el tiempo medio de reconocimiento activando la evaluación e investigación de gravedad inmediata sin recopilar información básica |
| Plataforma | Alertas | ✅ La agrupación de alertas evita tormentas de alerta donde cientos de alertas relacionadas se desencadenan para un único problema subyacente |
| Plataforma | Alertas | ✅ Fallo de integración desencadena una alerta agrupada por extremo de integración mostrando 156 solicitudes fallidas en los últimos 5 minutos con gráfico de latencia, distribución de errores y vínculo de tablero |
| Plataforma | Alertas | ✅ La supresión de alertas evita que las condiciones transitorias conocidas generen alertas durante los plazos de mantenimiento o los periodos de reparación automática previstos |
| Plataforma | Alertas | ✅ Las alertas se suprimen durante el mantenimiento programado, durante los primeros minutos después de la implementación mientras se calientan las memorias caché y durante fallos transitorios breves donde la lógica de reintento se realiza correctamente |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Alertas | ⚠️ Todas las alertas enrutan al mismo canal sin clasificación de gravedad; los incidentes críticos no se distinguen de las advertencias rutinarias |
| Plataforma | Alertas | ⚠️ Las alertas carecen de contexto diagnóstico; los ingenieros de guardia deben recopilar información básica a través de consultas separadas antes de evaluar la gravedad |
| Plataforma | Alertas | ⚠️ El fallo de integración genera 156 alertas individuales en 5 minutos abrumando el teléfono del ingeniero de guardia, cada alerta idéntica excepto para la marca de tiempo |
| Plataforma | Alertas | ⚠️ Las tormentas de alerta evitan que los respondedores distingan un único problema subyacente de cientos de síntomas relacionados |
| Plataforma | Alertas | ⚠️ Alerta de incendios durante plazos de mantenimiento conocidos y condiciones transitorias generando ruido que erosiona Trust en el monitoreo |
| Plataforma | Alertas | ⚠️ La fatiga de alerta por falsos positivos ruidosos hace que los equipos ignoren las notificaciones reduciendo la efectividad de la respuesta |