Close

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

Las cambiantes funciones de la gestión de problemas e incidentes

En la última década, la gestión de incidentes ha cambiado mucho.

Las directrices de la ITIL se han actualizado. Los equipos de TI han comenzado a compartir responsabilidades con DevOps y SecOps. La complejidad cada vez mayor de los sistemas ha propiciado una mayor complejidad de las soluciones de gestión de incidentes. Además, muchas empresas están adoptando los análisis retrospectivos y nuevas formas de medir el rendimiento.

A medida que la gestión de incidentes va cambiando y evolucionando continuamente, lo mismo sucede con su prima hermana, la gestión de problemas, así como con la relación entre ambas prácticas.

¿Qué es un problema y en qué se diferencia de un incidente?

Según la definición de la ITIL, un problema es “una causa o posible causa de uno o varios incidentes”.

Y un incidente es un solo evento no planificado que causa una interrupción del servicio.

En otras palabras, los incidentes son los episodios desagradables que los empleados de guardia suelen apurarse por resolver con la máxima rapidez posible y en su totalidad. Y los problemas son la causa fundamental de esos eventos disruptivos.

Un problema puede causar un solo incidente o varios. Además, el origen de un incidente puede rastrearse hasta un solo problema o, en ocasiones, varios.

Columna de servidores en el que uno de ellos está inclinado y crea problemas

Por ejemplo, la interrupción del servicio de cinco horas que le costó a Delta Airlines 150 millones de dólares en 2016 fue un incidente. El problema que causó ese incidente fue un corte de electricidad en un centro de operaciones y, presumiblemente, no contar contar con ningún plan de respaldo en caso de ese corte de electricidad.

Del mismo modo, la interrupción del servicio durante 12 horas en la App Store que le costó a Apple aproximadamente 25 millones de dólares fue un incidente. ¿Cuál fue el problema que lo originó? Una incidencia de DNS.

Si empleáramos estos términos fuera del ámbito tecnológico, ir al médico por una migraña sería un incidente. La causa de la migraña (alergias, problemas de vista o el estrés) sería el problema.

¿Gestión de problemas o gestión de incidentes?

Es obvio que los problemas y los incidentes están vinculados inextricablemente. Uno es la causa del otro, y los equipos tienen que prestar atención a ambos.

En el caso de los equipos de TI tradicionales, las últimas directrices de ITIL obligan a los equipos a gestionar tanto los problemas como los incidentes, pero a hacerlo por separado. La gestión de problemas es una práctica centrada en prevenir incidentes o en reducir sus consecuencias. La gestión de incidentes se centra en solucionar los incidentes en tiempo real.

La ventaja del enfoque de la ITIL es que prioriza los objetivos fundamentales tanto de la gestión de problemas como de la gestión de incidentes. Al convertirlas en prácticas independientes e igual de importantes, se supone que las directrices tratan de evitar el problema habitual de los equipos de TI que están constantemente apagando fuegos (o incidentes) sin ocuparse de su causa primordial.

Si el objetivo principal de un gestor de incidentes es solucionar los incidentes con rapidez y, el de un gestor de problemas, prevenirlos, combinar estas funciones puede provocar que alguno de estos objetivos (y ambos son vitales para una organización) pierda prioridad en favor del otro.

La desventaja de este enfoque es que separar ambas prácticas —que en realidad están tan íntimamente vinculadas— puede crear brechas de conocimiento y una ruptura de la comunicación entre la resolución de incidentes y el análisis de la causa primordial que conduce a la causa subyacente.

El DevOps y las funciones cambiantes de la gestión de incidentes y problemas

Como de costumbre, el colaborativo movimiento del DevOps ha difuminado las fronteras de la concepción tradicional de la TI: ver los problemas y la gestión de incidentes no como dos prácticas diferenciadas, sino como dos mitades superpuestas de una perspectiva holística.

Gráfico de ITIL con un diagrama de círculos independientes para la gestión de incidentes y la gestión de problemas, y gráfico de DevOps en forma de diagrama de Venn para la gestión de incidentes y problemas

Este cambio proviene no solo del hecho de que ambas prácticas son dos caras de la misma moneda (prevenir y resolver los incidentes), sino también de un enfoque de DevOps que, por lo general, afirma que:

  • Un incidente suele tener más de una causa primordial.
  • Los análisis retrospectivos deben ser sin acusaciones e incluir a todos los equipos afectados por un incidente.
  • La colaboración es la esencia de la mejora continua.

Esta superposición de la gestión de incidentes y problemas también se puede vincular al cambio de todo el sector hacia un enfoque de you built it, you run it. A medida que los equipos que desarrollan sistemas se van responsabilizando de resolver incidentes dentro de dichos sistemas, es lógico que el mismo equipo se responsabilice de realizar análisis retrospectivos, hacer el trabajo de detectives para llegar a la causa primordial de un incidente y hacer recomendaciones que prevengan o disminuyan el impacto de incidentes futuros.

El nexo existente entre la gestión de incidentes y la gestión de problemas es el análisis retrospectivo sin acusaciones, en el que una vez enfriada la urgencia, los gestores de incidentes se convierten en detectives y se dedican a la tarea de gestión y prevención de problemas.

El principal desafío al que se enfrentarán los equipos de DevOps que difuminan las fronteras entre estas dos prácticas consiste en asegurarse de que la gestión de problemas (con sus objetivos menos urgentes pero profundamente valiosos a largo plazo), no pierdan prioridad en favor de la apremiante urgencia de la gestión de incidentes.

A continuación
SRE