El futuro de la gestión de incidentes de TI, la respuesta y la prevención

Retrocede cinco años y pregunta a un equipo de TI quién era el responsable de la gestión de incidentes. Seguramente, la respuesta será "nosotros".

Si haces la misma pregunta hoy en día, lo más seguro es que te respondan que, además del equipo de TI, también son responsables los equipos de DevOps, SecOps y arquitectura. Muchas organización están virando poco a poco hacia la idea de "tú lo creas, tú lo gestionas".

Las ventajas evidentes de este enfoque son que quita presión a los equipos de TI y agiliza los tiempos de respuesta trasladando la responsabilidad a las personas que están más familiarizadas con el código. De este modo, se minimiza el tiempo de inactividad y se maximiza la productividad del equipo. Además, fomenta el desarrollo de un buen código. Si eres tú quien se tiene que despertar a las tres de la mañana para resolver un error, probablemente comprobarás el código hasta dos y tres veces la próxima vez que se ponga en funcionamiento, a fin de evitar que te vuelvan a llamar a las tres.

La dificultad de este enfoque es que las organizaciones siguen necesitando cierta centralización. Los directivos necesitan acceso a los informes y la documentación, mientras que las partes interesadas de la empresa quieren actualizaciones y quieren ver métricas de incidentes, como el tiempo medio de resolución y el tiempo medio de confirmación de recepción. Esperan actualizaciones de incidentes claras, informes de análisis retrospectivos y acciones de corrección.

Para muchas empresas que avanzan hacia la descentralización y que lo hacen bien, la respuesta a este desafío es la tecnología que permite la descentralización y la autonomía del equipo para preservar la agilidad de la resolución de incidentes y, al mismo tiempo, centralizar la información para mantener a la empresa al corriente.

Al igual que con cualquier otro gran cambio que podría interrumpir los flujos de trabajo y tener consecuencias imprevistas, tiene sentido que muchas organizaciones estén asumiendo la descentralización en pequeños pasos.

Comienzan identificando a un equipo que encaje bien en la política corporativa para un cambio como este y que esté gestionando una aplicación o un producto de bajo riesgo. A continuación, le trasladan al equipo la gestión de incidentes de la aplicación o el producto específico de este. Lo forman, implementan un horario de guardia y hacen un seguimiento de su progreso a lo largo del tiempo, en el que formulan preguntas como las siguientes:

• ¿Han mejorado los tiempos de recuperación?
• ¿Con qué barreras culturales se han topado?
• ¿Qué herramientas necesitó poner en práctica el equipo de TI?
• ¿Qué procesos necesitaron para comunicarse?
• ¿Son mejores las actualizaciones del sistema que genera ese equipo?
• ¿Se ha reducido el número de incidentes?
• Si decidimos implementar esta descentralización en otros equipos, ¿qué podemos quitar de esta ejecución de prueba inicial?

Estos casos de prueba funcionan para sentar una base con el fin de decidir si se implementa un marco basado en el concepto "tú lo creas, tú lo mantienes" en toda la empresa y, en caso afirmativo, cómo implementarlo de manera efectiva en todos los equipos.

Este avance hacia la descentralización también requiere un cambio hacia la colaboración entre equipos. Si DevOps participa en la gestión de incidentes, necesita un sitio en la mesa durante las reuniones sobre el proceso de gestión de incidentes de TI. Si TI sigue ofreciendo orientación sobre las prácticas de gestión de incidentes, deben participar en las revisiones de análisis retrospectivos que hagan otros equipos.

Cada equipo aporta sus puntos fuertes a la mesa de la reunión sobre gestión de incidentes. Los equipos de TI son buenos a la hora de desarrollar prácticas y documentación, y en seguir las directrices. Los equipos de DevOps son buenos en lo que se refiere a los cambios y el aprendizaje. SecOps puede aportar una perspectiva de seguridad.

Para fomentar una mayor colaboración entre los equipos, las empresas que lo hacen bien comparten información abiertamente, fomentan la empatía entre los equipos, acaban con los reproches entre equipos, usan el chat para mantener conectados a los equipos durante los incidentes y priorizan las revisiones de incidentes en las que todas las partes tienen un asiento en la mesa.

En las directrices de ITIL, la gestión de incidentes se suele considerar una práctica independiente de la prevención de incidentes. Ambas son piezas importantes del rompecabezas de ITSM, pero no suelen ir juntas.

El problema de este enfoque es que mantiene la gestión de incidentes en un estado reactivo. A los empleados de guardia se les encarga que apaguen incendios, y una vez que han apagado uno, deben pasar al siguiente. El único objetivo en mente es la recuperación, es decir, volver a poner el sistema en marcha.

Pero la perspectiva general va más allá de la recuperación. Cada vez hay más equipos de TI que se están dando cuenta y están adoptando esta idea con el tiempo, incorporando la prevención en el proceso de gestión de incidentes y usando métricas, como el tiempo medio de resolución en lugar del tiempo medio de recuperación, con el fin de evaluar su rendimiento.

Este enfoque se suele denominar "gestión de problemas" y su objetivo es armonizar los procesos para asegurarse de que los equipos no estén simplemente respondiendo ante un incendio y después pasen al siguiente, si no que respondan, se recuperen y aprendan del incidente, y apliquen este aprendizaje tanto al problema que tengan entre manos como a los sistemas de productos y servicios más amplios que estén gestionando.

Muchas organizaciones de TI empresarial cuentan con una práctica específica para la gestión de problemas. Normalmente, la tratan como un proceso independiente para otro equipo. En Atlassian abogamos por ir un paso más allá y adoptar un enfoque combinado en el que los equipos de operaciones de TI y desarrolladores incluyan la práctica de gestión de problemas en sus prácticas de incidentes. De este modo, se consigue una mayor visibilidad del incidente y se garantiza que no transcurra mucho tiempo entre su análisis y el momento en el que se produjo realmente,

ya que a largo plazo es más valioso prevenir los incidentes que responder ante ellos rápidamente.

Uno de los desafíos inherentes de esta transición hacia la colaboración entre equipos sobre la gestión de incidentes es que algunos equipos tienen una actitud más relajada que otros acerca del proceso y la documentación.

Aquí es donde puede ser más práctico contar con TI y con su supervisión, aunque otros equipos asuman la gestión de sus propios productos. Porque nadie quiere enfrentarse a un incidente grave con ojos soñolientos a las tres de la mañana sin un buen plan.

Al incorporar a los equipos al proceso de gestión de incidentes, el equipo de TI puede ayudarles a responder a las preguntas básicas que determinarán ese plan. Por ejemplo:

• ¿Cuál es nuestra respuesta ante incidentes?
• ¿Qué valores seguirás?
• ¿Cómo responderás en caso de incidente?
• ¿Dónde está la información que necesitas para los sistemas críticos a los que ofreces soporte? Si se encuentra en varios sistemas, ¿cómo puedes agruparla y conseguir que los expertos de guardia puedan consultarla fácilmente?
• ¿El equipo puede revisar el proceso y la documentación, y colaborar en ellos?

Esta transición hacia la descentralización, la colaboración y la combinación de la gestión de incidentes y problemas requiere algo más que una simple redistribución de responsabilidades y la participación de un profesional de TI en los análisis retrospectivos de DevOps. En este punto, la clave del éxito no radica en la tecnología ni en los procesos, sino en crear una política corporativa interna que promueva estos cambios.

Esta es la parte que demasiadas empresas procuran omitir y es la base de una transición efectiva. Así pues, ¿cómo es una política corporativa que fomenta la gestión de incidentes descentralizada, colaborativa y centrada en el futuro?

En Atlassian, creemos que los componentes principales son estos: