Políticas de escalación para una gestión eficaz de los incidentes

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.

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.