Gestión de incidentes para equipos de alta velocidad
El futuro de la gestión de incidentes de TI, la respuesta y la prevención
En el pasado, el equipo encargado de responder ante los incidentes tecnológicos era casi siempre el de TI. Generalmente, el equipo estaba ubicado en un centro de operaciones de red (NOC), desde el que supervisaba sistemas y respondía a las interrupciones del servicio. Puede que un proveedor hubiera compilado el software, pero la implementación y el funcionamiento eran responsabilidad del equipo de operaciones informáticas del cliente. Actualmente, con la proliferación de los servicios en la nube, el proveedor compila el software, lo implementa y lo pone en funcionamiento.
No obstante, la gestión de incidentes sigue siendo una práctica de gestión de servicios de TI (ITSM) esencial. En el ámbito de la TI cuentan con una experiencia dilatada en el desarrollo de directrices, la gestión de presupuestos y la asunción de toda la carga de las tareas de diagnóstico, corrección, documentación y prevención de accidentes graves.
Obviamente, como ocurre con todo en el ámbito de la tecnología, el pasado no predice necesariamente el futuro, y en la actualidad la práctica de la gestión de incidentes está cambiando. Los equipos de DevOps, SecOps y arquitectura se involucran cada vez más. Las nuevas tecnologías y los productos interconectados han cambiado la manera en que gestionamos los incidentes. Además, las mentalidades, las prácticas y las estructuras de los equipos están cambiando para mantenerse al día.
Así pues, ¿cómo está cambiando la gestión de incidentes y qué implica eso para el futuro de nuestras funciones, productos, procesos y equipos?
Un avance hacia la descentralizació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.
El lento camino hacia la descentralización
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.
Descentralización significa colaboración entre 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.
El cambio de reactivo a proactivo
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.
Perseverar con el proceso y la documentación
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?
¿Está lista tu cultura empresarial para el cambio?
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:
Apertura e intercambio de información
Si los equipos no saben y no pueden acceder a lo que otros equipos hacen, se pierden oportunidades de conseguir momentos de lucidez que conduzcan a una comunicación, unos procesos y unos productos mejores.
Pensamiento centrado en el cliente
Cuando nos planteamos preguntas como “¿qué es realmente lo mejor para el cliente?”, a veces las respuestas que obtenemos no coinciden con nuestras actuales prácticas. Hace falta un enfoque intencionado al cliente para avanzar hacia el tipo de comunicación, proceso y eficiencia estructural que, en última instancia, hacen que nuestros productos sean mejores para los clientes.
Comprobaciones de estado periódicas
¿Cómo progresa cada equipo? ¿Cómo se sienten los miembros del equipo? ¿En qué puede mejorar el equipo? ¿Qué es lo que están haciendo mejor? En Atlassian, disponemos de un manual de estrategias del equipo que nos ayuda a comprobar el estado de nuestros equipos y a presentarles nuevas formas de trabajar.
Empatía
Si DevOps señala con el dedo a TI y TI refunfuña ante el enfoque más relajado de DevOps, no cabe duda de que esa no es una buena receta para la colaboración. En cambio, si queremos que se comuniquen, innoven y trabajen bien juntos, es preciso fomentar la empatía y las conexiones entre los equipos.
Capacitación
Los equipos deben estar capacitados para solucionar los problemas rápidamente y tomar decisiones de forma independiente siempre que sea posible. Las personas que forman parte de estos equipos deben sentirse capacitadas para pronunciarse si tienen una pregunta, una sugerencia o una inquietud, independientemente de su posición en el equipo o de sus años de experiencia.
Cuando los desarrolladores júnior sienten que pueden participar activamente en las reuniones y avisar de una incidencia (aunque el responsable de ese código sea alguien con más experiencia), el resultado es que se obtienen nuevas ideas innovadoras, se mejoran los procesos y se detectan errores antes de que vayan al código.
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