Close

El camino hacia una mejor gestión de incidentes empieza aquí

Conoce los niveles de gravedad de los incidentes

Identifica los incidentes y establece sus prioridades para agilizar la resolución

Hay tres verdades fundamentales en la gestión de incidentes.

La primera es que los incidentes son inevitables, en especial, en las empresas que están en constante crecimiento e innovación.

La segunda es que resulta esencial contar con una sólida práctica de gestión de incidentes para el correcto funcionamiento de la empresa (de lo contrario, esta sufrirá grandes pérdidas en lo que respecta tanto al tiempo y la satisfacción de los empleados como a los ingresos comerciales).

La tercera es que no todos los incidentes son iguales. No es lo mismo perder los datos de una base de datos que los de todas ellas. Hacer frente a una interrupción que afecte al 20 % de los usuarios es totalmente distinto a afrontar una interrupción que afecte al 90 % o al 100 %. Gestionar una interrupción del sistema durante las horas de mayor demanda es mucho más estresante que hacerlo cuando la mayoría de los clientes están durmiendo. Incluso dos incidentes que parecen idénticos sobre el papel son únicos bajo la superficie.

Logotipo de OpsGenie

Descubre el enfoque de Atlassian para la gestión de incidentes

Hoy en día es más importante que nunca tener un proceso de gestión de incidentes rápido y sencillo.

Por ello, las empresas con sólidos programas de gestión de incidentes tienen unos niveles de gravedad bien definidos y unas prácticas recomendadas claras para la jerarquización por orden de prioridad de los incidentes a medida que surjan.

¿Qué son los niveles de gravedad?

Los niveles de gravedad de los incidentes son una medida del impacto que tiene un incidente en la empresa. Normalmente, cuanto más bajo es el número de gravedad, más repercusión tiene el incidente.

Por ejemplo: en Atlassian, definimos un incidente de gravedad 1 como un “incidente crítico con un impacto muy alto”. Puede tratarse de la pérdida de datos de un cliente, una infracción de seguridad o la interrupción generalizada de un servicio orientado a los clientes.

Un incidente de gravedad 2 es un “incidente grave con un impacto significativo”, incluida la interrupción parcial de un servicio orientado a los clientes o el fallo de funcionamiento de una función esencial dentro de un sistema.

Por último, un incidente de gravedad 3 es un “incidente de menor importancia con un impacto bajo”, como un fallo del sistema que causa ligeras molestias a los clientes.

En Atlassian, los incidentes de gravedad 3 pueden gestionarse durante el día o el horario de trabajo, mientras que los de gravedad 1 y 2 generan una alerta para que los profesionales de guardia los solucionen de inmediato, independientemente de la hora que sea.

"Severity" (Gravedad) Descripción Ejemplos
1 Un incidente crítico con un impacto muy alto
  • Falla un servicio público, como Jira Cloud, para todos los clientes.
  • Se ha vulnerado la confidencialidad o la privacidad.
  • Se han perdido datos del cliente.
2 Un incidente principal con impacto significativo
  • No está disponible un servicio público para un subconjunto de clientes.
  • Afecta notablemente a la funcionalidad esencial (por ejemplo, git push, creación de incidencias...).
3 Un incidente secundario con bajo impacto
  • Pequeñas molestias para los clientes, con solución alternativa.
  • Disminución del rendimiento de uso.

Los niveles de gravedad resultan útiles para entender rápidamente la repercusión y establecer las prioridades para los equipos de TI y DevOps.

Cuanto mejor definidos estén los niveles de gravedad, más probable será que tu equipo esté en sintonía y pueda reaccionar de manera rápida y adecuada cuando se produzcan incidentes. Si no están bien definidos, es muy fácil perder un tiempo vital determinando y explicando la urgencia de un incidente en lugar de resolverlo.

¿Cuándo y dónde son útiles los niveles de gravedad?

La utilidad principal de los niveles de gravedad es que ahorran tiempo a los equipos. Un equipo con niveles de gravedad y una hoja de ruta clara para abordar cada nivel puede ir directamente a la solución. Un equipo sin niveles de gravedad probablemente pase los primeros minutos de un incidente grave, que son cruciales, averiguando la importancia que tiene, quién debería encargarse de él y cómo gestionarlo.

Cuanto más crítico sea el incidente, más importante será ahorrar todo el tiempo posible planificando con antelación no solo la resolución de los incidentes y los planes de comunicación, sino también unas prioridades y unos niveles de gravedad claros.

¿En qué se diferencia la gravedad de la prioridad?

A primera vista, cuando hablamos de los incidentes, la gravedad parece lo mismo que la prioridad. Al fin y al cabo, un incidente grave con consecuencias nefastas debería abordarse antes que un incidente de menor importancia, ¿no?

Pero lo cierto es que, en la mayoría de las empresas, es más complicado que eso.

La gravedad es una estimación del impacto. ¿Qué repercusión tiene un incidente en los usuarios? ¿Hace que se caiga todo el sistema? ¿Les impide completar una tarea esencial? ¿O tal vez solo provoque molestias y dificulte las tareas?

La prioridad, en cambio, indica la urgencia. ¿Con qué rapidez se debe solucionar esta incidencia? ¿Qué incidencia hay que resolver primero?

A veces, ambas medidas coinciden a la perfección. Es probable que un incidente de gravedad alta que interrumpa el trabajo de toda la empresa también tenga la mayor prioridad para los equipos de DevOps y TI.

No obstante, en ocasiones, la prioridad y la gravedad no tienen nada que ver. Por ejemplo: supongamos que hay una errata en el titular de la página de inicio de tu sitio web. Se trata de una incidencia de gravedad baja porque, en realidad, no afecta al funcionamiento del sitio web. Los usuarios pueden seguir haciendo lo que necesiten y los empleados también pueden continuar trabajando.

Sin embargo, es posible que la empresa considere que la corrección tiene una prioridad alta por motivos relacionados con el estándar de la marca, o bien porque causa confusión o simplemente da mala impresión. De esa forma, este incidente podría ser de gravedad baja y de prioridad alta.

Del mismo modo, supongamos que hay un incidente que interrumpe el funcionamiento de tu aplicación. Es de gravedad alta porque impide que los usuarios hagan lo que necesiten. Pero digamos también que ese incidente solo afecta al 0,05 % de los usuarios. Si hay otros incidentes con mayor repercusión, puede que una incidencia de este tipo no tenga la máxima prioridad, aunque por lo general las palabras “el sistema ha dejado de funcionar” conllevarían que todo el mundo se pusiera manos a la obra.

Ambas medidas son importantes en la gestión de incidentes, pero resulta fundamental reconocer cuándo coinciden y cuándo no. La gravedad alta no hace automáticamente que algo tenga la máxima prioridad y la prioridad alta no siempre implica que un sistema haya dejado de funcionar.

Dado que la prioridad es más procesable que la gravedad, es la principal medida que usamos en Opsgenie. Además, como la gravedad suele ser un factor clave que determina la prioridad, hemos incluido unas definiciones claras en nuestro manual de gestión de incidentes para nuestro propio trabajo.

Definición de los niveles de gravedad de los incidentes en tu organización

No todos los incidentes son iguales ni todas las organizaciones los gestionan de la misma manera. A la hora de definir los niveles de gravedad y los procesos y expectativas en torno a ellos, además del impacto del incidente, habrá que tener en cuenta lo siguiente:

  • El tamaño del equipo técnico
  • Programas de guardia
  • Los momentos del día de mayor y menor tráfico en el servicio
  • La frecuencia de los incidentes

¿Por qué? Porque cada uno de estos aspectos puede influir en la forma de definir los niveles de gravedad.

Por ejemplo, una aplicación que da servicio a los mercados locales de una sola zona horaria podría tener un gran vacío de uso entre las 2 y las 7 de la mañana. En ese caso, si todo el sistema se cae a las 3 de la mañana, ¿tiene el mismo nivel de gravedad que una interrupción del sistema durante las horas de mayor demanda?

¿O qué ocurre con una empresa emergente con un equipo pequeño y muchos incidentes que podríamos considerar de gravedad 3? ¿Debería seguir la etiqueta de gravedad 3 a rajatabla y dejar que el equipo concrete qué incidentes tienen prioridad cuando se dan tres a la vez? ¿O debería dividirlos en gravedad 3, 4 o incluso 5 para distinguir entre una pérdida parcial de funcionalidad en un sistema orientado a los clientes, incidencias de rendimiento y algo aún menos importante, como un error que no afecta al uso del sistema, pero que en algún momento tendrá que corregirse?

Lo esencial es conocer tu empresa, tu equipo y qué tipo de definiciones de los niveles de gravedad y de prioridad os van mejor.

Nivel 3 de Atlassian Nivel 4 Nivel 5
Gravedad 1

Un incidente crítico con un impacto muy alto.

Por ejemplo: un servicio orientado al cliente, como Jira, no está disponible para todos los usuarios.

Gravedad 2

Un incidente grave con un impacto significativo.

Por ejemplo: un servicio orientado al cliente no está disponible para un subgrupo de usuarios.

Gravedad 3 Un incidente de menor importancia con un impacto bajo.

Por ejemplo: un error del sistema provoca pequeñas molestias a los clientes.

Un incidente que puede volverse grave si no se aborda rápidamente.

Por ejemplo: una pérdida parcial de funcionalidad para un pequeño subgrupo de clientes.

Gravedad 4 Una solicitud de soporte que causa molestias a un cliente, pero no afecta al funcionamiento general del sistema.

Un incidente de menor importancia que afecta al uso del producto, pero no lo paraliza.

Por ejemplo: tiempos de carga más lentos de lo normal.

Gravedad 5

Errores o incidencias de soporte que no afectan al uso del producto.

Por ejemplo: un logotipo aparece en un lugar equivocado u oculta parcialmente la última letra de un titular.

A continuación
Cost of downtime