Gestión de incidentes para equipos de alta velocidad
Políticas de escalación para una gestión eficaz de los incidentes
Cuando se produce un incidente, lo ideal es que el ingeniero de guardia o el equipo de SRE puedan resolverlo rápidamente y por su cuenta.
Evidentemente, la realidad no siempre es así. En ocasiones, la resolución requiere un equipo más grande, conocimientos especializados o competencias de mayor nivel. Por eso, cualquier organización con más de dos profesionales de la tecnología precisa de un plan y una política de escalación de incidentes.
¿En qué consiste la escalación de incidentes?
La escalación de incidentes es lo que ocurre cuando un empleado no es capaz de resolver un incidente por sí mismo y necesita pasar la tarea a un compañero con más experiencia o especializado.
¿Qué es una política de escalación?
La política de escalación da respuesta a la pregunta de cómo debe manejar la organización esos traspasos. En ella, se indica a quién se debe notificar cuando llega la alerta de un incidente, a quién se debe escalar el incidente si el primer usuario de respuesta no está disponible, quién debe hacerse cargo en caso de que el usuario de respuesta no pueda resolver la incidencia por sí mismo y cómo deben producirse esos traspasos (¿a través del centro de asistencia? ¿Directamente de un técnico a otro? ¿A través de una herramienta de gestión de incidentes?).
A primera vista, estas preguntas parecen sencillas, pero cuanto más grande sea la organización y más complejo sea tu ecosistema tecnológico, más detalladas serán las respuestas. Por ejemplo, a la hora de identificar a quién hay que avisar cuando llega la alerta de un incidente, la respuesta puede variar en función no solo de quién esté de guardia o disponible, sino también de los niveles de gravedad, la duración del incidente, etc.
En algunas empresas, una sola persona de guardia puede ser la primera en recibir la notificación, independientemente de la gravedad del incidente. En otras, podría tener sentido avisar a un desarrollador júnior si el incidente tiene una gravedad de nivel 3 y recurrir a una persona con mayor cualificación o un equipo especializado si la gravedad es de nivel 1.
Del mismo modo, algunas empresas pueden confiar en su primer usuario de respuesta para escalar un incidente cuando sea necesario. Otras pueden desencadenar una escalación automática a un desarrollador más cualificado o un equipo especializado si un incidente supera un determinado tiempo o empieza a afectar a un mayor número de sistemas o usuarios.
La política de escalación debería abordar no solo la forma en que la empresa escalará los incidentes y a quién, sino también si hay algunos matices según el tipo de incidente, el nivel de gravedad, la duración y el alcance del incidente.
Procesos de escalación de incidentes
Para las empresas que siguen las prácticas recomendadas de ITSM, el centro de asistencia suele ser el elemento central de la escalación de incidentes. Si el primero en responder no puede resolver un incidente, vuelve a dirigirse al centro de asistencia, que escala la incidencia a la siguiente línea de defensa que corresponda. Con Jira Service Management, los encargados de responder pueden escalar los incidentes dentro del ticket de incidente. Los encargados tienen acceso a los flujos de trabajo para guiar el proceso de resolución y pueden automatizar o personalizar las acciones según sea necesario. La designación de un nivel de gravedad puede dirigir a los encargados al flujo de trabajo adecuado.
Otras empresas, como Google, ponen a un SRE a cargo de los incidentes y esa persona se ocupa de las escalaciones necesarias (así como de congelar las nuevas publicaciones en caso de que un incidente haga que el equipo esté por encima de su umbral aceptable de tiempo de inactividad según su SLA/SLO).
En otras empresas, el primero en responder puede ser un desarrollador o un gestor de incidentes, o bien puede haber varios primeros puntos de contacto (en especial, cuando llega una alerta por un incidente de alta gravedad) y la escalación puede llevarse a cabo a través de procesos predefinidos directamente en esos equipos y entre ellos.
Independientemente de que el proceso pase por el centro de asistencia, lo facilite un equipo de SRE o se dé de manera automática dentro de los sistemas de seguimiento de incidentes, por lo general, hay tres vías que siguen las políticas de escalación.
Escalación jerárquica
La escalación jerárquica tiene lugar cuando un incidente se pasa a un equipo o a una persona según su nivel de experiencia o antigüedad dentro de la organización.
Por ejemplo, el primer usuario de respuesta de guardia podría ser un desarrollador júnior recién llegado al equipo. Si no es capaz de resolver una incidencia, en una organización jerárquica, pasa esa incidencia a un desarrollador más veterano. Si el desarrollador más veterano tampoco puede resolver la incidencia, se vuelve a pasar a otro desarrollador más veterano y así sucesivamente hasta que se ponga solución a la incidencia.
Escalación funcional
La escalación funcional es aquella que se produce cuando un incidente se pasa al equipo o a la persona con mejor preparación para resolverlo en función de sus habilidades o conocimientos de los sistemas, no de su antigüedad.
Por ejemplo, el primer usuario de respuesta de guardia puede ser un desarrollador júnior de un equipo que se centra en el back-end del producto X. Si detecta que el problema principal parece provenir de una integración con el producto Y, puede escalar el incidente a otro desarrollador júnior del equipo del producto Y.
Escalación automática
En el caso de los equipos que trabajan con una plataforma como Opsgenie, también puedes definir reglas que indiquen al sistema que escale automáticamente un incidente si la persona de guardia principal no admite ni cierra una alerta.
Algunos equipos pueden preferir un método de escalación antes que otro, pero no se excluyen mutuamente y muchos equipos combinan la escalación jerárquica, la funcional y la automática.
La matriz de escalación
Una matriz de escalación es un documento o sistema donde se define cuándo debería producirse la escalación y quién debería gestionar los incidentes en cada nivel de la escalación.
El término se utiliza en varios sectores. En RR. HH. pueden tener una matriz de escalación para las incidencias internas. Los centros de llamadas pueden tener una matriz de escalación para las incidencias del servicio de atención al cliente. Y los equipos de TI y DevOps pueden tener una o más matrices que ayudan a los ingenieros a saber cómo y cuándo escalar un incidente.
El nivel de detalle de una matriz varía mucho de una empresa a otra. Algunas organizaciones podrían tener un simple gráfico jerárquico en el que cada desarrollador escala a otro con un nivel de cualificación más alto según sea necesario. Otras organizaciones pueden tener matrices específicas para cada situación que indiquen a los desarrolladores con qué equipos deben ponerse en contacto en función del tipo de incidente o el nivel de gravedad. Como ocurre con la mayoría de las cosas en la gestión de incidentes, no hay una respuesta única para desarrollar la matriz de tu organización.
Prácticas recomendadas para desarrollar una política de escalación
Trata tu política de escalación como una guía, no como un conjunto de reglas estrictas
La tecnología no es algo estático y tus equipos tampoco. Google sugiere que, si tu equipo de SRE cree que un caso específico requiere otra estrategia de escalación, le des la libertad de tomar esa decisión. No se trata de crear reglas inflexibles, sino de elaborar directrices que se apliquen en la mayoría de las situaciones.
Audita periódicamente tu horario de guardia
¿Hay alguna laguna en el horario? ¿Tienes al personal adecuado de guardia? ¿Cuentas con el personal apropiado en el segundo y tercer nivel de guardia? Los horarios de guardia y la política de escalación deberían ir de la mano para agilizar la gestión de incidentes.
Establece unos umbrales inteligentes para la escalación
No todos los incidentes son iguales, por lo que no todos pueden o deben seguir la misma política de escalación.
En el caso de los incidentes de menor importancia, es posible que no quieras avisar al ingeniero de guardia hasta que empiece el horario de trabajo. En el caso de los incidentes graves, es probable que necesites a ese ingeniero independientemente de la hora que sea. En el caso de que se den varios incidentes, el ingeniero necesitará saber qué abordar primero o si tiene que escalar un incidente a un segundo ingeniero de inmediato.
Se trata de encontrar el equilibrio entre garantizar que los sistemas tengan el máximo tiempo de actividad y cumplan las promesas del SLA y los SLO, y asegurarse de que los ingenieros no se agoten, se vean desbordados de trabajo, se les prive de sueño ni sufran una avalancha de alertas.
Define unos procesos claros para la escalación
¿El desarrollador que realiza la escalación debería ponerse en contacto directamente con el equipo o la persona correspondiente, o tiene que pasar por el centro de ayuda? ¿Hay algún sistema que deba utilizar el desarrollador? ¿Cómo harás el seguimiento de la escalación? ¿Qué responsabilidades tiene el primer usuario de respuesta para asegurarse de que la siguiente persona se ocupe del incidente?
Estas preguntas deberían abordarse con claridad en la política y comunicarse expresamente a todos los desarrolladores de guardia con el fin de que las escalaciones se realicen sin problemas y los incidentes se resuelvan en menos tiempo.
Obtén más información sobre cómo Jira Service Management puede enriquecer tu práctica de gestión de incidentes al ofrecer una solución colaborativa a la escalación de incidentes para alcanzar resoluciones más rápidas.
Configuración de un horario de guardias con Opsgenie
En este tutorial aprenderás a configurar un horario de guardias, aplicar reglas de anulación, configurar notificaciones de guardias y mucho más, todo dentro de Opsgenie.
Leer el tutorialUn método de planificación de guardias más adecuado
Una planificación de guardias eficaz es fundamental para mantener una política corporativa saludable con respecto a las guardias. Descubre los errores habituales, los tipos de planificaciones con rotación y cómo hacerlas bien.
Leer el artículo