Diagrama de clasificación de severidad de incidentes
Árbol de decisión para clasificar la severidad de un incidente: disponibilidad, alcance, impacto en el negocio y exposición de datos, hasta llegar a P1, P2, P3 o P4.
Cómo funciona
Renombra los carriles con vuestros derechos de decisión reales
Sustituye service desk, responsable del servicio, gestor de incidentes, y legal y cumplimiento por los roles que de verdad tienen cada decisión en vuestra organización. Si fuera de horario nadie es dueño de la pregunta de exposición de datos o de seguridad, eso es un hueco de guardia que cerrar antes de redibujar el carril.
Escribe vuestros umbrales de alcance en el diagrama
Abre «¿Cuántos usuarios o sedes afectados?» y sustituye el comentario por vuestras propias definiciones de varias sedes, un equipo y un solo usuario: una región, un segmento de clientes, un porcentaje de usuarios activos, una lista de cuentas concretas. Los umbrales que no están escritos se renegocian en cada incidente.
Define caído frente a degradado para vuestros servicios
Acordad qué significa «Caído» servicio por servicio, incluidos los casos de disponibilidad parcial: modo solo lectura, una región caída o una cola que sigue aceptando trabajo pero no lo procesa. La ambigüedad aquí desplaza el árbol entero un nivel.
Aplica la prueba de la solución alternativa con honestidad
Decide qué hace viable una solución alternativa: que esté documentada, permitida, dentro de la capacidad disponible y que las personas afectadas puedan usarla hoy. Un procedimiento manual que exige formación, personal extra o una excepción de política no es una solución alternativa, y tratarlo como tal es la forma más habitual de que un P1 quede registrado como P2.
Asocia a cada resultado un compromiso de respuesta distinto
Cada uno de «P1 crítico, puente activo», «P2 alto, corrección en curso», «P3 medio, plazo controlado» y «P4 bajo, trabajo planificado» debería llevar su propia regla de aviso, su cadencia de actualización y sus tiempos objetivo. Si dos niveles producen el mismo comportamiento, fúndelos en vez de mantener un nivel que nadie sabe distinguir.
Acordad quién puede reclasificar, y registrad el motivo
La decisión «¿Cambió el impacto en la siguiente actualización?» es la única vía autorizada para cambiar un nivel. Nombra a quién puede tomarla, exige que se vuelvan a aplicar las pruebas en lugar de renegociar el nivel, y registra las nuevas evidencias y la hora para que la revisión posterior vea cuándo cambió la foto.
Pon el diagrama en circulación para su aprobación y guarda la versión
Los criterios de severidad solo sirven si son los acordados. Compártelo con gestión de servicios, con los responsables de los servicios y con legal para que lo firmen, y conserva la versión aprobada, de modo que las definiciones que entrenáis sean las definiciones que publicáis.
Preguntas frecuentes
¿Qué diferencia hay entre severidad y prioridad de un incidente?
La severidad es una afirmación sobre el impacto: cuánto servicio está roto, para cuánta gente y qué bloquea. La prioridad es una afirmación sobre el orden: qué coge el equipo a continuación. ITIL en realidad no usa «severidad» como término formal; deriva la prioridad del impacto y la urgencia. Muchos equipos de ingeniería y de SRE usan severidad como atajo para la mitad del impacto, que es como la usa este diagrama. La regla práctica es que la severidad determina la respuesta que debes (avisos, puente, cadencia de actualización) y solo cambia cuando cambian las evidencias, mientras que la prioridad gobierna la cola y se puede recolocar cada día. Mantener un campo para cada cosa evita que se renegocie la valoración del impacto para conseguir un servicio más rápido.
¿En qué se diferencia esto de un diagrama del proceso de gestión de incidencias?
Responden a preguntas distintas sobre el mismo asunto. Este diagrama es un árbol de decisión: qué nivel de severidad le corresponde a este incidente y quién está facultado para decidirlo. Es una cadena de pruebas que termina en resultados con nombre, y se detiene en cuanto el nivel queda fijado. Un diagrama del proceso de gestión de incidencias es un mapa de procesos interfuncional: qué pasa después y quién lo hace, desde el registro hasta el diagnóstico, el escalado, la resolución y el cierre. La mayoría de los equipos necesitan los dos, y conectan exactamente en un punto: el paso en el que se asigna un nivel.
¿Cuántos niveles de severidad deberíamos tener?
Cuatro es el valor por defecto habitual y el que usa este diagrama, con algunas organizaciones añadiendo un P0 o SEV0 por encima para sucesos existenciales. El número importa menos que si cada nivel lleva asociada una respuesta distinta y escrita. Si P3 y P4 llevan a la misma regla de aviso, a los mismos tiempos objetivo y a la misma cadencia de actualización, tienes tres niveles y una etiqueta sin usar. Pocos niveles aplicados con coherencia ganan a muchos niveles aplicados a ojo, porque el valor de la clasificación es que todo el mundo aguas abajo pueda actuar sin preguntar.
¿Quién puede declarar un P1?
Nombra el rol por adelantado y mantén la lista corta. En este diagrama la declaración vive en el carril del gestor de incidentes y le llegan tres ramas distintas: una caída en varias sedes, una función crítica bloqueada sin solución alternativa viable, y una exposición confirmada de datos o de seguridad. Esa estructura es deliberada, porque a un P1 se debería poder llegar por evidencias desde más de una dirección, pero debería declararlo un rol que además pueda comprometer la respuesta. Cualquiera debería poder pedir un P1; un rol con nombre lo confirma.
¿Una exposición de datos o de seguridad convierte el incidente automáticamente en P1?
En este diagrama sí, y la rama de exposición se salta por completo la prueba del número de usuarios. La razón es que una exposición pone en marcha un reloj que corre desde que hay constancia y no desde que se resuelve, así que un incidente pequeño puede arrastrar una obligación grande. Con el RGPD de la UE y del Reino Unido, una violación de datos personales debe notificarse a la autoridad de control sin dilación indebida y, cuando sea posible, en un plazo de 72 horas desde que se tiene constancia, con la notificación a las personas afectadas como prueba aparte ligada al alto riesgo. Otros regímenes y contratos fijan sus propios plazos, y los avisos a clientes suelen ser más cortos que los legales, así que pon en la caja de decisión los que os apliquen. Muchas organizaciones además sacan las exposiciones de este árbol y las derivan a un proceso de respuesta ante incidentes de seguridad.
¿Cuándo debe cambiarse un nivel de severidad ya asignado?
Cuando cambian las evidencias, no cuando cambia la presión. Este diagrama le da una única vía: la decisión «¿Cambió el impacto en la siguiente actualización?», cuya rama «Aumentó» devuelve un P2 a la declaración de P1. Vuelve a aplicar las pruebas en lugar de reabrir la discusión, y registra qué evidencia nueva llegó y cuándo. Las bajadas de nivel siguen la misma regla y conviene tratarlas de forma explícita, porque un incidente que sigue en P1 después de que el impacto haya remitido enseña a la gente, en silencio, a ignorar el nivel.