Observabilidad y supervisión - Patrones
Obtenga más información acerca de Excelencia operativa bien arquitecta → Observabilidad y supervisión
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Supervisión de eventos | ✅ Supervisión de eventos está diseñada 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 | Supervisión 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 a cadenas de procesamiento asíncronas, eventos de plataforma a ejecuciones de suscriptores y solicitudes de integración a respuestas del sistema externas |
| 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 | Supervisión 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 | Supervisión de eventos | ⚠️ La observabilidad se actualiza en la solución existente que requiere 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 a través de límites del sistema sin telemetría integral |
| Plataforma | Eventos de plataforma | ⚠️ Las cargas de Eventos 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 paneles predefinidos no pueden responder a preguntas inesperadas sobre el comportamiento del sistema que surge en producción |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Supervisión de eventos | ✅ Supervisión de eventos está activada 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 informes |
| Plataforma | Supervisión 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 | Supervisión de eventos | ✅ La agregación de registros externos permite la correlación con la telemetría de empresa desde otros sistemas para el rastreo de transacciones de extremo a extremo |
| Plataforma | Supervisión de eventos | ✅ Los archivos de registro de eventos se mantienen cumpliendo los requisitos normativos para la creación de informes 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 sobre las que se pueden realizar acciones en las que los equipos Trust y actúan creando círculos virtuosos de mejora continua |
| Plataforma | Scale Center | ✅ Las líneas base de Scale Center 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 mayor impacto |
| 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 de Seguimiento de auditoría de configuración se exportan para su retención más allá de 180 días cuando el cumplimiento o los requisitos contractuales 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 comerciales 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 informes de cumplimiento |
| Plataforma | Comprobación de estado | ✅ Las revisiones de Comprobación de estado se programan trimestralmente con resultados remediados basándose en la priorización de riesgos para el entorno |
| Plataforma | Comprobación de estado | ✅ Los resultados de Comprobación de estado reciben una revisión deliberada en vez de aceptación pasiva; se documentan controles de compensación o diferentes tolerancias al riesgo |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Supervisión de eventos | ⚠️ Supervisión de eventos está activada 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 | Supervisión 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 rendimiento se degrada lentamente hasta que los usuarios se quejan después de meses de degradación incremental |
| Plataforma | Scale Center | ⚠️ Las mediciones de rendimiento 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 evitan 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 de forma selectiva, creando costes 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é buen aspecto tiene |
|---|---|
| Plataforma | Flujos de usuario | ✅ Los flujos de usuarios críticos se definen basándose en el impacto comercial y supervisados de extremo a extremo para índices de éxito, tiempo de finalizació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 pago, Desencadenador de realización) mostrando el índice de éxito por etapa |
| Plataforma | Flujos de usuario | ✅ La supervisión a nivel de flujo revela problemas invisibles en la supervisión 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 del flujo caen por debajo de umbrales aceptables o la duración supera objetivos de latencia |
| Plataforma | Integración | ✅ La supervisión 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 supervisión del índice de éxito cuando se cae por debajo del 99% para integraciones síncronas críticas |
| Plataforma | Integración | ✅ Alertas de supervisión de distribución de errores cuando aparecen nuevos tipos de error que no existían en la línea base |
| Plataforma | Integración | ✅ Alertas de supervisión de percentil de latencia (p95) al superar los 3 segundos para llamadas de cara al usuario síncronas |
| Plataforma | Integración | ✅ Alertas de supervisión de rendimiento cuando superan el 80% del límite de frecuencia conocido o umbral de SLA |
| Plataforma | Integración | ✅ Alertas de supervisión de estado de disyuntor cuando se abre cualquier circuito indicando degradación del sistema externo |
| Plataforma | Integración | ✅ Alertas de supervisión 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 supervisión centralizadas que permiten la correlación entre límites del sistema |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Flujos de usuario | ⚠️ Los componentes se supervisan 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 paneles 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 supervisión |
| 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 comerciales críticas carecen de instrumentación; se desconocen las tasas de éxito y los puntos de abandono |
| Plataforma | Integración | ⚠️ Los fallos de integración se detectan solo después de caer en cascada en fallos de cara al usuario en vez de de forma proactiva |
| 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 | ⚠️ Supervisión 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é buen 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 entrada se siente lenta) |
| Plataforma | SLI | ✅ Los SLI de rendimiento miden el volumen de operaciones exitosas 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 rendimiento 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 comerciales antes de seleccionar patrones de arquitectura |
| Plataforma | SLO | ✅ Requisito comercial “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 comerciales 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 | ⚠️ Latencia se mide solo en la mediana sin comprender la experiencia del usuario más desfavorable en 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 diferentes soluciones |
| Plataforma | SLO | ⚠️ La arquitectura se construye primero, luego SLO se define como “lo que sea 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 dirigidos por el negocio, estableciendo objetivos basándose en lo que logra el sistema en vez de lo que necesitan los usuarios |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Alerta | ✅ La clasificación de gravedad enruta incidentes críticos (producción no disponible, riesgo de daños de datos, compromiso de seguridad) a ingenieros de página a petición de inmediato |
| Plataforma | Alerta | ✅ Los incidentes de alta gravedad (rendimiento deteriorado, cortes parciales) generan notificaciones para una investigación rápida dentro del horario de oficina |
| Plataforma | Alerta | ✅ Las advertencias (acercándose a umbrales, desviación de configuración) generan notificaciones de resúmenes diarias para la remediación proactiva |
| Plataforma | Alerta | ✅ El contexto de alerta incluye recuento de usuarios afectados, mensajes de error, rastreos de pilas, implementaciones recientes, alertas relacionadas y vínculos a paneles relevantes |
| Plataforma | Alerta | ✅ El contexto enriquecido reduce el tiempo medio para reconocer activando la evaluación de gravedad inmediata y la investigación sin recopilar información básica |
| Plataforma | Alerta | ✅ La agrupación de alertas evita tormentas de alerta donde cientos de alertas relacionadas se activan para un único problema subyacente |
| Plataforma | Alerta | ✅ 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 panel |
| Plataforma | Alerta | ✅ La supresión de alertas evita que condiciones transitorias conocidas generen alertas durante plazos de mantenimiento previstos o periodos de reparación automática |
| Plataforma | Alerta | ✅ Las alertas se suprimen durante el mantenimiento programado, durante los primeros minutos después de la implementación mientras se calientan las caché y durante breves fallos transitorios donde la lógica de reintento se realiza con éxito |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Alerta | ⚠️ Todas las alertas enrutan al mismo canal sin clasificación de gravedad; los incidentes críticos no se distinguen de las advertencias rutinarias |
| Plataforma | Alerta | ⚠️ 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 | Alerta | ⚠️ El fallo de integración genera 156 alertas individuales en 5 minutos abrumando el teléfono del ingeniero a petición, cada alerta idéntica excepto para la marca de tiempo |
| Plataforma | Alerta | ⚠️ Las tormentas de alerta evitan que los respondedores distingan un único problema subyacente de cientos de síntomas relacionados |
| Plataforma | Alerta | ⚠️ Alerta de incendios durante plazos de mantenimiento conocidos y condiciones transitorias generando ruido que erosiona Trust en el monitoreo |
| Plataforma | Alerta | ⚠️ La fatiga de alerta por falsos positivos ruidosos hace que los equipos ignoren las notificaciones reduciendo la eficacia de la respuesta |