Cómo elegir los KPI y las métricas de gestión de incidentes

El valor de los KPI, las métricas y los análisis de incidentes

Los KPI (indicadores de rendimiento clave) son métricas con las que las empresas pueden determinar si cumplen objetivos concretos. En relación con la gestión de incidentes, estas métricas pueden ser un número de incidentes, el tiempo promedio para resolverlos o el tiempo promedio entre incidentes.

En la gestión de incidentes, el seguimiento de los KPI puede ayudar a identificar y diagnosticar problemas con procesos y sistemas, establecer puntos de referencia y objetivos realistas para que el equipo avance, y proporcionar un punto de partida para asuntos de mayor envergadura.

Por ejemplo, supongamos que el objetivo de tu empresa es resolver todos los incidentes en 30 minutos, pero actualmente tu equipo tarda una media de 45 minutos. Sin métricas específicas, es difícil saber qué es lo que va mal. ¿El sistema de alertas tarda demasiado tiempo? ¿El proceso se interrumpe? ¿Es necesario actualizar las herramientas de diagnóstico? ¿Es un problema del equipo o un problema tecnológico?

En cambio, si añades métricas y sabes exactamente cuánto tarda el sistema de alertas, se puede identificar como un problema o descartarlo. Si observas que el diagnóstico tarda más del 50 % del tiempo, puedes centrarte en la solución de problemas en ese aspecto. Si ves que el equipo B tarda un 25 % más de tiempo que los equipos A, C y D, puedes empezar a indagar en el motivo.

Alertas creadas

Si usas una herramienta de alertas, es útil saber cuántas alertas se generan en un periodo de tiempo determinado. Con una solución como Jira Service Management, puedes enviar alertas y crear informes y paneles para llevar un seguimiento.

Presta atención a los períodos con subidas o bajadas significativas y poco características o a las cifras con tendencia ascendente y, cuando los veas, profundiza en la razón de esos cambios y en cómo los están abordando tus equipos.

Incidentes a lo largo del tiempo

Llevar un seguimiento de los incidentes a lo largo del tiempo significa observar el número medio de incidentes durante un tiempo determinado. Esto puede ser cada semana, cada mes, cada trimestre, cada año o incluso a diario.

¿Se producen los incidentes con mayor o con menor frecuencia a lo largo del tiempo? ¿Es aceptable el número de incidentes o podría ser menor? Una vez que identifiques un problema con el número de incidentes, puedes empezar a preguntarte por qué esa cifra tiende a aumentar o se mantiene alta y qué puede hacer el equipo para resolver la incidencia.

MTBF

El MTBF (tiempo medio entre fallos) es la media de tiempo entre fallos reparables de un producto tecnológico. Se utiliza para controlar tanto la disponibilidad como la fiabilidad de los productos.

Al igual que con otras métricas, es un buen punto de partida para cuestiones más amplias. Si el MTBF es más bajo de lo que deseas, es el momento de preguntarse por qué los sistemas fallan tan a menudo y cómo puedes reducir o prevenir futuros fallos.

MTTA

El MTTA (tiempo medio hasta la admisión) es el tiempo promedio que transcurre desde que se activa una alerta del sistema hasta que un miembro del equipo confirma el incidente y empieza a trabajar para resolverlo. Aquí lo importante es conocer la capacidad de respuesta del equipo al abordar las incidencias.

Una vez que sepas que hay un problema de capacidad de respuesta, puedes empezar nuevamente a indagar en los motivos. ¿Por qué el MTTA es alto? ¿Los equipos tienen sobrecarga? ¿Tienen distracciones? ¿No está claro de quién es la responsabilidad de una alerta? El MTTA puede ayudarte a identificar un problema y preguntas como estas pueden guiarte hasta llegar a la raíz.

MTTD

El MTTD (tiempo medio de detección) es la media de tiempo que tarda tu equipo en descubrir una incidencia. Este término suele utilizarse en ciberseguridad cuando los equipos se centran en detectar ataques y brechas.

Si esta métrica cambia drásticamente o no se ajusta a lo esperado, es el momento, una vez más, de preguntarse por qué.

MTTR

El MTTR puede significar tiempo medio de reparación, resolución, respuesta o recuperación. Podría decirse que la más útil de estas métricas es el tiempo medio de resolución, ya que, además de controlar el tiempo invertido en diagnosticar y solucionar una incidencia inmediata, permite llevar un seguimiento del tiempo empleado en garantizar que no vuelva a ocurrir la misma incidencia. La recuperación es una métrica clave de DevOps para medir la estabilidad de los equipos de DevOps, como señala el programa DORA (DevOps Research and Assessment).

Una vez más, esta métrica es mejor cuando se utiliza para el diagnóstico. ¿Son tus tiempos de resolución tan rápidos y eficientes como deseas? Si no es así, es hora de investigar más a fondo sobre cómo y por qué dicho tiempo de resolución no logra el objetivo.

La recuperación es una métrica clave de DevOps que permite medir la estabilidad de los equipos de DevOps, como señala el programa DORA (DevOps Research and Assessment). Es el tiempo total que se tarda en detectar, mitigar y resolver un problema.

Tiempo de guardia

Si tienes una rotación de guardias, puede que te resulte útil realizar un seguimiento del tiempo que los empleados y los contratistas pasan de guardia.Esta métrica te puede servir para evitar que haya empleados o equipos sobrecargados.

Jira Service Management te permite generar informes exhaustivos para ver rápidamente estas cifras.

SLA

Un SLA (acuerdo de nivel de servicio) es un acuerdo entre el proveedor y el cliente sobre los parámetros cuantificables, como el tiempo de actividad, la capacidad de respuesta y las responsabilidades.

Los compromisos asumidos en los SLA (sobre el tiempo de actividad, el tiempo medio de recuperación, etc.) son una de las razones por las que los equipos de gestión de incidentes necesitan hacer un seguimiento de estas métricas. En caso de que cambien cosas como el tiempo medio de respuesta o el tiempo medio entre fallos, hay que actualizar los contratos o se deben hacer correcciones rápidamente.

SLO

Un SLO (objetivo de nivel de servicio) es un acuerdo dentro de un SLA sobre una métrica específica, como el tiempo de actividad. Al igual que con el propio SLA, los SLO son métricas importantes a las que hay que dar seguimiento para asegurarse de que la empresa está cumpliendo su parte del trato en lo que respecta al servicio al cliente.

Marcas de tiempo (o cronograma)

Una marca de tiempo es información codificada sobre lo que sucedió en momentos específicos durante el incidente, antes de que ocurriera o después. Esta información no se suele considerar una métrica, pero es un dato importante para evaluar el estado de la gestión de incidentes y elaborar estrategias de mejora.

Las marcas de tiempo ayudan a los equipos a elaborar cronogramas del incidente y son útiles para las labores de preparación y respuesta. Un cronograma claro y compartido es uno de los recursos más prácticos para los análisis retrospectivos de incidentes.

Tiempo de actividad

El tiempo de actividad es la cantidad de tiempo (expresada en porcentaje) que los sistemas están disponibles y en funcionamiento.

La creciente conectividad de servicios en línea y la complejidad cada vez mayor de los propios sistemas implican que normalmente no existe un tiempo de actividad garantizado al 100 %. El objetivo de la mayoría de los productos es la alta disponibilidad, es decir, tener un sistema o producto que esté operativo sin interrupción durante largos periodos de tiempo. Según el estándar de la industria, el tiempo de actividad del 99,9 % es muy bueno y del 99,99 % es excelente.

El control del éxito en relación con esta métrica tiene que ver con hacer promesas a los clientes y mantenerlas. Y, al igual que con otras métricas, es solo un punto de partida. Si el tiempo de actividad no es del 99,99 %, averiguar el motivo requerirá más investigación, conversaciones con el equipo y análisis del proceso, de la estructura, del acceso o de la tecnología.

Ten cuidado con el análisis de incidentes

La desventaja de los KPI es que es fácil que se basen en datos insustanciales. Saber que el equipo no resuelve los incidentes lo suficientemente rápido no supone por sí solo que vayas a conseguir una solución, ya que además tienes que averiguar cómo y por qué el equipo resuelve o no las incidencias. También tienes que saber si las incidencias que estás comparando son realmente comparables.

Los KPI no explican cómo abordan tus equipos las incidencias delicadas, ni explican por qué el tiempo transcurrido entre incidentes se ha ido reduciendo en lugar de ampliarse, o por qué el incidente A duró tres veces más que el incidente B.

Para saber eso, se necesita información detallada. Y, si bien los datos pueden ser un punto de partida para llegar a esa información detallada, también pueden suponer un obstáculo. Nos pueden hacer sentir que hacemos lo suficiente aunque nuestras métricas no mejoren. Pueden agrupar incidentes que en realidad son muy diferentes entre sí y deberían abordarse de distinta manera. Pueden no tener en cuenta la experiencia de tus equipos y la complicación subyacente de los propios incidentes.