Gestión de incidentes para equipos de alta velocidad
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.
Gestión de incidentes para equipos de alta velocidad
Acelera el flujo de información entre los equipos de operaciones y desarrollo para responder y restaurar los sistemas cuando se produzcan incidentes con Jira Service Management.
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 |
|
| 2 | Un incidente principal con impacto significativo |
|
| 3 | Un incidente secundario con bajo impacto |
|
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 necesitan. 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 factible que la gravedad, esta es la principal medida que usamos. 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. | ||
| Gravedad 2 | Un incidente grave con un impacto significativo. | ||
| 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. | |
| 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. | |
| Gravedad 5 | Errores o incidencias de soporte que no afectan al uso del producto. | ||
Es fundamental contar con una solución de gestión de incidentes para poder escalarlos, de modo que los equipos adecuados puedan agruparse de inmediato para resolverlos.
Descubre cómo todas las funciones de gestión de incidentes de Jira Service Management, incluidas las alertas y los horarios de guardia, la comunicación colaborativa y las sólidas funciones de informes y análisis, permiten a los equipos responder a los incidentes, resolverlos y aprender de ellos.
Descubre la comunicación de incidentes con Statuspage
En este tutorial, te mostraremos cómo utilizar plantillas de incidentes para comunicarte eficazmente durante las interrupciones. Puedes aplicarlo a muchos tipos de interrupciones del servicio.
Leer el tutorialPlantillas y ejemplos de comunicación de incidentes
A la hora de responder ante un incidente, las plantillas de comunicación tienen un valor incalculable. Hazte con las plantillas que utilizan nuestros equipos, así como con otros ejemplos para los incidentes comunes.
Leer el artículo