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é buen aspecto tiene |
|---|---|
| Plataforma | Supervisión | ✅ 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 a petición de inmediato |
| Plataforma | Supervisión | ✅ Los incidentes de alta gravedad (rendimiento deteriorado, apagón parcial) generan notificaciones inmediatas para una investigación rápida en horario de oficina |
| Plataforma | Supervisión | ✅ Las advertencias (acercándose a umbrales, desviación de configuración) se agregan en resúmenes diarios para una remediación proactiva |
| Plataforma | Supervisión | ✅ El enriquecimiento de alertas incluye contexto de diagnóstico: recuento de usuarios afectados, percentiles de índice de error, implementaciones recientes, alertas relacionadas y vínculos de panel directos |
| Plataforma | Supervisión | ✅ El contexto de alerta reduce el tiempo medio de reconocimiento proporcionando una evaluación de situación inmediata sin recopilar información básica a través de consultas separadas |
| Plataforma | Supervisión | ✅ La agrupación de alertas evita tormentas de alerta consolidando cientos de alertas relacionadas desde un único problema subyacente en una notificación con estadísticas agregadas |
| Plataforma | Supervisión | ✅ Las alertas agrupadas muestran el recuento, el índice y las transacciones afectadas que revelan un patrón de problemas sin abrumar a los respondedores |
| Plataforma | Supervisión | ✅ La supresión de alertas evita que condiciones transitorias conocidas generen alertas durante plazos de mantenimiento previstos o periodos de reparación automática |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Supervisión | ⚠️ El fallo de integración genera alertas individuales de 100 s en 5 minutos abrumando el teléfono on-call, cada alerta idéntica excepto la marca de tiempo |
| Plataforma | Supervisión | ⚠️ 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 | Supervisión | ⚠️ Todas las alertas se enrutan a través del mismo canal independientemente de la gravedad; los cortes críticos de producción compiten con advertencias menores |
| Plataforma | Supervisión | ⚠️ Alerta de incendios durante plazos de mantenimiento programados generando falsos positivos que erosionan Trust en sistema de monitoreo |
| Plataforma | Supervisión | ⚠️ La agrupación de alertas no existe; cada fallo de transacción desencadena alertas separadas creando tormentas de alerta durante incidentes |
| Plataforma | Supervisión | ⚠️ Las alertas no proporcionan vínculos a paneles relevantes; los respondedores emplean tiempo en encontrar herramientas de supervisión durante la respuesta a incidentes |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Operaciones | ✅ La rotación a petición es semanal o quincenal, lo que equilibra la distribución de la carga con la conservación del contexto |
| Plataforma | Operaciones | ✅ Los libros de ejecución están documentados para cada tipo de alerta permitiendo a los ingenieros a petición responder de forma efectiva sin experiencia en dominios profundos |
| Plataforma | Operaciones | ✅ Los libros de ejecución incluyen descripción de problemas, pasos de diagnóstico, procedimientos de solución, criterios de distribución y vínculos de documentación relacionada |
| Plataforma | Operaciones | ✅ Runbooks son documentos vivos en control de versión 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 | ✅ Frecuencia de páginas, recuento de incidentes fuera de hora y tasa de falsos positivos se miden para identificar la carga de llamadas no sostenible que requiere reparación arquitectónica |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Operaciones | ⚠️ Los Runbooks no existen; los ingenieros a petición se basan en Knowledge tribal y frecuentes distribuciones a expertos en la materia |
| Plataforma | Operaciones | ⚠️ Los libros de ejecución se almacenan en documentos personales en vez del control de versión compartido donde los miembros del equipo pueden acceder y actualizarlos |
| Plataforma | Operaciones | ⚠️ Las transiciones de rotación a petición 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 hora, falsos positivos); los patrones de carga permanecen invisibles |
| Plataforma | Operaciones | ⚠️ Los libros de ejecución se crean una vez durante la implementación inicial y nunca se actualizan a medida que evoluciona el sistema o surgen nuevos modos de fallo |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Operaciones | ✅ Las rutas de distribución técnica definen qué expertos en la materia gestionan 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 Procedimientos de creación de casos y criterios de gravedad de asistencia de Salesforce |
| Plataforma | Operaciones | ✅ Las rutas de distribución de ejecutivos definen qué ejecutivos reciben notificaciones para incidentes críticos comerciales |
| Plataforma | Operaciones | ✅ Los criterios de distribución son explícitos y objetivos: niveles de gravedad, umbrales de tiempo, recuentos de usuarios afectados, evaluaciones de impacto comercial |
| Plataforma | Operaciones | ✅ Las rutas de distribución están documentadas en libros de ejecución 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 imprecisos (“distribuir si parece malo”); los respondedores carecen de directrices claras 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 equivocadas o fallan durante los cambios de rotación |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Operaciones | ✅ Las revisiones posteriores a incidentes sin culpa se realizan en 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, detección, confirmación, investigación, respuesta, recuperación y 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 con plazos específicos, lo que evita la repetición o mejora la respuesta futura |
| Plataforma | Operaciones | ✅ Los elementos de acción evitan mejoras imprecisas (“mejorar la supervisión”) en favor de tareas concretas (“agregar alerta para índice de error de API que supera el 5% en plazo de 10 minutos”) |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Operaciones | ⚠️ La discusión 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 fue lenta |
| Plataforma | Operaciones | ⚠️ El análisis de causa raíz no distingue la causa técnica inmediata de los factores organizativos o que contribuyen al proceso |
| Plataforma | Operaciones | ⚠️ Se omite el análisis de detección; no se identifican las brechas de supervisión que permitieron a los usuarios reportar incidentes primero |
| Plataforma | Operaciones | ⚠️ Los elementos de acción son imprecisos 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é buen aspecto tiene |
|---|---|
| Plataforma | Knowledge Management | ✅ Las revisiones posteriores a incidentes se documentan y se comparten ampliamente más allá de los respondedores de incidentes inmediatos para el aprendizaje organizacional |
| Plataforma | Knowledge Management | ✅ Las revisiones posteriores a incidentes se almacenan en wiki compartido o base Knowledge con etiquetado que activa el análisis de patrones entre múltiples incidentes |
| Plataforma | Knowledge Management | ✅ Se realiza un seguimiento de la finalización de elementos de acción en revisiones posteriores evitando que las retrospectivas se conviertan en debates repetitivos sin seguimiento |
| Plataforma | Knowledge Management | ✅ Los índices de finalización de elementos de acción se miden como un indicador de salud operacional que revela si se implementan mejoras o simplemente se debaten |
| Plataforma | Operaciones | ✅ Los patrones de incidentes se analizan en múltiples incidentes revelando problemas sistémicos que requieren inversión arquitectónica |
| Plataforma | Operaciones | ✅ Los manuales se actualizan basándose en aprendizajes posteriores a incidentes garantizando que los procedimientos reflejan la experiencia de respuesta a incidentes real |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Knowledge Management | ⚠️ Los exámenes posteriores a incidentes no están documentados; el aprendizaje permanece en los equipos de respuesta a incidentes en vez de extenderse por toda la organización |
| Plataforma | Knowledge Management | ⚠️ 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 | Knowledge Management | ⚠️ Los elementos de acción se definen pero nunca se siguen; se desconoce el índice de finalización y no se implementan mejoras |
| Plataforma | Knowledge Management | ⚠️ Los bajos índices de finalización de elementos de acción persisten 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 | ⚠️ Los libros de ejecución no se actualizan después de incidentes; los procedimientos quedan desfasados a medida que evoluciona el sistema y surgen nuevos modos de fallo |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Operaciones | ✅ Tiempo medio para detectar (MTTD) se realiza un seguimiento 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 la confirmación de ingeniero a petición |
| Plataforma | Operaciones | ✅ Tiempo medio para restaurar (MTTR) se realiza un seguimiento 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 mensual de tendencias 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 constante, 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 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 de si los tiempos de respuesta están mejorando o degradándose |
| Plataforma | Operaciones | ⚠️ La MTTD, la MTTA y la 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 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 derrocha esfuerzo y no proporciona ningún valor |