Gestión de incidentes: patrones
Obtenga más información acerca de Excelencia operativa bien arquitecta → Gestión 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 |
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 |
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 |
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 |
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 |
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 |