--- schema_version: "1" id: ca8c80a8805dd495f092444cadb9996003dcf188c257fa19ec23bd28638d6f74 title: "Gestión de incidentes: patrones" collection: architect version: current locale: es-mx portal_url: https://docs.salesforce.com/architect/current/es-mx/well-architected/guides/operational-excellence-incident-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/es-mx/well-architected/guide/operational-excellence-incident-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: 721b9ae47f94a6cf69563b884721cce062d5371cb1ad221ca00597e7e918e952 products: - Marco bien estructurado - Architect Site Content Repo --- # Gestión de incidentes: patrones Obtenga más información acerca de [Excelencia operativa](/docs/architect/es-mx/well-architected/guide/operational-excellence.html) bien arquitecta → [Gestión de incidentes](/docs/architect/es-mx/well-architected/guide/operational-excellence.html#incident-management) ## Detección y alerta de incidentes **Patrones** | Dónde buscar | Qué aspecto tiene | | --- | --- | | Plataforma \| Monitoreo | ✅ La arquitectura de alerta incluye clasificación de gravedad que enruta incidentes críticos (producción no disponible, daños en los datos, compromiso de seguridad) a páginas on-call inmediatamente | | Plataforma \| Monitoreo | ✅ Los incidentes de alta gravedad (desempeño degradado, apagón parcial) generan notificaciones inmediatas para una investigación rápida en horario laboral | | Plataforma \| Monitoreo | ✅ Las advertencias (acercándose a umbrales, desviación de configuración) se agregan en resúmenes diarios para una solución proactiva | | Plataforma \| Monitoreo | ✅ El enriquecimiento de alertas incluye contexto de diagnóstico: conteo de usuarios afectados, percentiles de índice de error, implementaciones recientes, alertas relacionadas y vínculos de tablero directos | | Plataforma \| Monitoreo | ✅ El contexto de alerta reduce el tiempo medio de reconocimiento proporcionando evaluación de situación inmediata sin recopilar información básica a través de consultas separadas | | Plataforma \| Monitoreo | ✅ La agrupación de alertas evita tormentas de alertas consolidando cientos de alertas relacionadas desde un único problema subyacente en una notificación con estadísticas agregadas | | Plataforma \| Monitoreo | ✅ Las alertas agrupadas muestran el conteo, el índice y las transacciones afectadas revelando el patrón de problemas sin abrumar a los respondedores | | Plataforma \| Monitoreo | ✅ 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 | **Antipatrones** | Dónde buscar | Aspecto negativo | | --- | --- | | Plataforma \| Monitoreo | ⚠️ El fallo de integración genera alertas individuales de 100 s en 5 minutos abrumando el teléfono de llamada, cada alerta idéntica excepto la marca de tiempo | | Plataforma \| Monitoreo | ⚠️ Las alertas carecen de contexto sobre el ámbito, los cambios recientes o los patrones de problemas; el ingeniero de guardia debe recopilar información básica manualmente | | Plataforma \| Monitoreo | ⚠️ Todas las alertas se enrutan a través del mismo canal independientemente de la gravedad; los cortes de producción críticos compiten con advertencias menores | | Plataforma \| Monitoreo | ⚠️ Alerta de incendios durante plazos de mantenimiento programados generando falsos positivos que erosionan Trust en sistema de monitoreo | | Plataforma \| Monitoreo | ⚠️ La agrupación de alertas no existe; cada fallo de transacción desencadena alertas separadas creando tormentas de alertas durante incidentes | | Plataforma \| Monitoreo | ⚠️ Las alertas no proporcionan vínculos a tableros relevantes; los respondedores emplean tiempo en encontrar herramientas de monitoreo durante la respuesta ante incidentes | ## Rotación a petición y Runbook **Patrones** | Dónde buscar | Qué aspecto tiene | | --- | --- | | Plataforma \| Operaciones | ✅ La rotación de llamadas es semanal o quincenal equilibrando la distribución de cargas con la conservación del contexto | | Plataforma \| Operaciones | ✅ Los libros de ejecuciones están documentados para cada tipo de alerta permitiendo a los ingenieros de guardia responder de forma efectiva sin experiencia en dominios profundos | | Plataforma \| Operaciones | ✅ Los libros de ejecuciones incluyen descripción de problemas, pasos de diagnóstico, procedimientos de corrección, criterios de distribución y vínculos de documentación relacionados | | Plataforma \| Operaciones | ✅ Las listas de ejecuciones son documentos vivos en control de versiones que evolucionan a través de elementos de acción post mortem | | Plataforma \| Operaciones | ✅ Los procedimientos de traspaso incluyen breves reuniones durante transiciones de rotación transfiriendo contexto incluyendo problemas activos, cambios recientes, riesgos conocidos y mantenimiento próximo | | Plataforma \| Operaciones | ✅ Las notas de traspaso escritas complementan el traspaso verbal evitando la pérdida de información durante las transiciones de rotación | | Plataforma \| Operaciones | ✅ La frecuencia de páginas, el conteo de incidentes fuera de horas y la tasa de falsos positivos se miden para identificar la carga de llamadas insostenible que requiere reparación arquitectónica | **Antipatrones** | Dónde buscar | Aspecto negativo | | --- | --- | | Plataforma \| Operaciones | ⚠️ Los Runbooks no existen; los ingenieros de guardia se basan en Knowledge tribal y escaladas frecuentes a expertos en la materia | | Plataforma \| Operaciones | ⚠️ Los libros de ejecuciones se almacenan en documentos personales en vez de en el control de versiones compartido donde los miembros del equipo pueden acceder y actualizarlos | | Plataforma \| Operaciones | ⚠️ Las transiciones de rotación de llamadas se producen sin reuniones de traspaso; el ingeniero entrante carece de contexto sobre problemas activos y cambios recientes | | Plataforma \| Operaciones | ⚠️ La alta carga a petición continúa indefinidamente a través de la heroicidad operativa en vez de impulsar mejoras arquitectónicas | | Plataforma \| Operaciones | ⚠️ No se realiza un seguimiento de las mediciones a petición (frecuencia de páginas, incidentes fuera de horario, falsos positivos); los patrones de carga permanecen invisibles | | Plataforma \| Operaciones | ⚠️ Las listas de ejecuciones se crean una vez durante la implementación inicial y nunca se actualizan a medida que evoluciona el sistema o emergen nuevos modos de fallo | ## Ruta de distribución **Patrones** | Dónde buscar | Qué aspecto tiene | | --- | --- | | Plataforma \| Operaciones | ✅ Las rutas de distribución técnica definen qué expertos en la materia tratan dominios de problemas específicos | | Plataforma \| Operaciones | ✅ Las rutas de distribución de gestión definen qué gestores reciben notificaciones para incidentes que superan los umbrales de gravedad o duración | | Plataforma \| Operaciones | ✅ Documento de rutas de distribución de proveedores Salesforce admite procedimientos de creación de casos y criterios de gravedad | | Plataforma \| Operaciones | ✅ Las rutas de distribución de ejecutivos definen qué ejecutivos reciben notificaciones para incidentes críticos de negocio | | Plataforma \| Operaciones | ✅ Los criterios de distribución son explícitos y objetivos: niveles de gravedad, umbrales de tiempo, conteos de usuarios afectados, evaluaciones de impacto de negocio | | Plataforma \| Operaciones | ✅ Las rutas de distribución están documentadas en libros de ejecuciones y son accesibles durante incidentes sin buscar información de contacto | **Antipatrones** | Dónde buscar | Aspecto negativo | | --- | --- | | Plataforma \| Operaciones | ⚠️ Las rutas de distribución no están documentadas; los ingenieros de guardia pierden el tiempo buscando contactos apropiados durante incidentes | | Plataforma \| Operaciones | ⚠️ Los criterios de distribución son vagos ("distribuir si parece malo"); los respondedores carecen de orientación clara acerca de cuándo distribuir | | Plataforma \| Operaciones | ⚠️ La notificación de gestión se produce demasiado tarde porque los umbrales de gravedad no están definidos; los ejecutivos aprenden sobre incidentes de usuarios | | Plataforma \| Operaciones | ⚠️ Los procedimientos de distribución de asistencia de Salesforce no están documentados; los equipos retrasan la apertura de casos de asistencia perdiendo tiempo de respuesta valioso | | Plataforma \| Operaciones | ⚠️ Los contactos de expertos en la materia están desfasados; las distribuciones llegan a personas incorrectas o fallan durante los cambios de rotación | ## Proceso de revisión posterior al incidente **Patrones** | Dónde buscar | Qué aspecto tiene | | --- | --- | | Plataforma \| Operaciones | ✅ Las revisiones posteriores a incidentes sin culpa se realizan en un plazo de 5 días hábiles después de eventos operativos significativos | | Plataforma \| Operaciones | ✅ La cultura sin culpa se centra en mejoras del sistema en vez de culpa individual, creando seguridad psicológica para una evaluación honesta | | Plataforma \| Operaciones | ✅ La cronología incluye una secuencia detallada desde las condiciones iniciales hasta la primera señal, la detección, la confirmación, la investigación, la respuesta, la recuperación y la validación | | Plataforma \| Operaciones | ✅ La cronología marca el tiempo de cada evento permitiendo el análisis de duración de las fases de detección, respuesta y recuperación | | Plataforma \| Operaciones | ✅ Causa raíz identifica fallo técnico o condición que causó directamente el incidente, distinguiendo de factores que contribuyen | | Plataforma \| Operaciones | ✅ El análisis de factores que contribuyen revela condiciones organizativas, de proceso o arquitectónicas que activaron o amplificaron el impacto de incidentes | | Plataforma \| Operaciones | ✅ El análisis de detección evalúa cómo se detectó el incidente y si la detección podría haber sido más rápida | | Plataforma \| Operaciones | ✅ La evaluación de respuesta identifica lo que salió bien durante la respuesta y lo que fue más lento o más difícil de lo necesario | | Plataforma \| Operaciones | ✅ Los elementos de acción son específicos, asignados y sujetos a plazos que evitan la repetición o mejoran la respuesta futura | | Plataforma \| Operaciones | ✅ Los elementos de acción evitan mejoras imprecisas ("mejorar el monitoreo") en favor de tareas concretas ("agregar alerta para índice de error de API que supera el 5% en un plazo de 10 minutos") | **Antipatrones** | Dónde buscar | Aspecto negativo | | --- | --- | | Plataforma \| Operaciones | ⚠️ El debate posterior al incidente concluye que "el trabajo por lotes tuvo un fallo, lo solucionamos" sin documentación o mejoras sistemáticas | | Plataforma \| Operaciones | ⚠️ Las revisiones posteriores a incidentes se centran en fallos individuales en vez de mejoras del sistema, destruyendo la seguridad psicológica | | Plataforma \| Operaciones | ⚠️ La cronología carece de marcas de tiempo que impidan el análisis de la duración; el equipo no puede identificar si la detección o la respuesta fueron lentas | | Plataforma \| Operaciones | ⚠️ El análisis de causa raíz no distingue la causa técnica inmediata de los factores que contribuyen a la organización o al proceso | | Plataforma \| Operaciones | ⚠️ Se omite el análisis de detección; no se identifican las brechas de monitoreo que permitieron a los usuarios reportar incidentes primero | | Plataforma \| Operaciones | ⚠️ Los elementos de acción son vagos sin propietarios o fechas de vencimiento; las mejoras se debaten pero nunca se implementan | | Plataforma \| Operaciones | ⚠️ Las revisiones posteriores a incidentes no se realizan en 5 días hábiles; el contexto se pierde y la urgencia de mejoras se desvanece | ## Documentación y aprendizaje posteriores al incidente **Patrones** | Dónde buscar | Qué aspecto tiene | | --- | --- | | Plataforma \| Gestión de Knowledge | ✅ Las revisiones posteriores a incidentes se documentan y comparten ampliamente más allá de los respondedores de incidentes inmediatos para el aprendizaje organizacional | | Plataforma \| Gestión de Knowledge | ✅ Las revisiones posteriores a incidentes se almacenan en wiki compartida o base Knowledge con etiquetado que activa el análisis de patrones entre múltiples incidentes | | Plataforma \| Gestión de Knowledge | ✅ Se realiza un seguimiento de la finalización del elemento de acción en revisiones posteriores evitando que las retrospectivas se conviertan en debates repetitivos sin seguimiento | | Plataforma \| Gestión de Knowledge | ✅ Los índices de finalización de elementos de acción se miden como indicador de estado operativo que revela si las mejoras se implementan o simplemente se debaten | | Plataforma \| Operaciones | ✅ Los patrones de incidentes se analizan entre múltiples incidentes revelando problemas sistémicos que requieren inversión arquitectónica | | Plataforma \| Operaciones | ✅ Los libros de ejecuciones se actualizan basándose en aprendizajes posteriores a incidentes garantizando que los procedimientos reflejan la experiencia de respuesta ante incidentes real | **Antipatrones** | Dónde buscar | Aspecto negativo | | --- | --- | | Plataforma \| Gestión de Knowledge | ⚠️ Las revisiones posteriores a incidentes no están documentadas; el aprendizaje permanece en los respondedores de incidentes en vez de extenderse por toda la organización | | Plataforma \| Gestión de Knowledge | ⚠️ Las revisiones posteriores a incidentes se almacenan en documentos personales en vez de Knowledge Base compartida donde los miembros del equipo pueden aprender del historial | | Plataforma \| Gestión de Knowledge | ⚠️ Los elementos de acción se definen pero nunca se realizan seguimientos; el índice de finalización es desconocido y las mejoras no se implementan | | Plataforma \| Gestión de Knowledge | ⚠️ Persisten índices bajos de realización de elementos de acción sin reconocer que las retrospectivas son ineficaces sin seguimiento | | Plataforma \| Operaciones | ⚠️ Los patrones de incidentes no se analizan entre múltiples incidentes; los problemas sistémicos permanecen ocultos porque cada incidente se trata de forma aislada | | Plataforma \| Operaciones | ⚠️ Las libretas de ejecución no se actualizan después de incidentes; los procedimientos quedan anticuados a medida que evoluciona el sistema y surgen nuevos modos de fallo | ## Mediciones y monitoreo de incidentes **Patrones** | Dónde buscar | Qué aspecto tiene | | --- | --- | | Plataforma \| Operaciones | ✅ Se realiza un seguimiento del tiempo medio para detectar (MTTD) midiendo la duración desde la incidencia hasta la detección | | Plataforma \| Operaciones | ✅ Tiempo medio para confirmar (MTTA) se realiza un seguimiento midiendo la duración desde la detección hasta el reconocimiento de ingeniero a petición | | Plataforma \| Operaciones | ✅ Se realiza un seguimiento del tiempo medio para restaurar (MTTR) midiendo la duración desde la detección hasta la restauración del servicio | | Plataforma \| Operaciones | ✅ Se realiza un seguimiento de la frecuencia de incidentes con una revisión de tendencias mensual que revela si la estabilidad está mejorando o degradándose | | Plataforma \| Operaciones | ✅ Se realiza un seguimiento del índice de fallos de cambios midiendo el porcentaje de implementaciones que causan incidentes de producción que requieren reparación | | Plataforma \| Operaciones | ✅ El índice de fallos de cambios se mantiene bajo de forma coherente, una pequeña fracción de todas las implementaciones | | Plataforma \| Operaciones | ✅ Las mediciones de incidentes se comparten con equipos de desarrollo durante la planificación de sprints informando sobre la priorización de retrasos y mejoras arquitectónicas | **Antipatrones** | Dónde buscar | Aspecto negativo | | --- | --- | | Plataforma \| Operaciones | ⚠️ No se realiza un seguimiento de las mediciones de incidentes; el equipo no tiene visibilidad sobre si los tiempos de respuesta están mejorando o degradándose | | Plataforma \| Operaciones | ⚠️ MTTD, MTTA y MTTR no se miden; los equipos no pueden identificar si la detección o la respuesta es el cuello de botella | | Plataforma \| Operaciones | ⚠️ No se realiza un seguimiento del índice de fallos de cambios; el equipo no sabe si las puertas de calidad son efectivas | | Plataforma \| Operaciones | ⚠️ Las tendencias de frecuencia de incidentes no se revisan mensualmente; la degradación de la estabilidad no se detecta hasta que se produce un incidente importante | | Plataforma \| Operaciones | ⚠️ Las mediciones de incidentes permanecen en el equipo de operaciones sin compartir con los equipos de desarrollo; no se solucionan los problemas arquitectónicos | | Plataforma \| Operaciones | ⚠️ Las mediciones se siguen pero nunca se utilizan para informar decisiones; la medición sin acción desperdicia esfuerzo y no proporciona ningún valor |