Priorizar la recuperación

Para ordenar una recuperación se usan dos criterios, y el orden entre ellos importa. El primero es técnico: un servicio no puede arrancar hasta que arranque aquel del que depende. El segundo es de negocio: entre los que ya pueden arrancar, se atiende primero el que tiene el RTO más corto o el impacto más alto.

La petición de un área, por insistente que sea, no es un criterio: es información que se usa para calibrar el segundo, y nunca para saltarse el primero.

En la tabla, cada servicio dice de quién depende. Quien no depende de nadie arranca primero, y el siguiente en la cadena es el que más servicios habilita al terminar. Es la parte del plan que más se reordena a última hora, y casi siempre mal.

Abre servicios_caidos y cuenta cuántos servicios dependen de cada identificador.

El tiempo hasta que un servicio está disponible es la suma de las horas de toda su cadena de dependencias: cada eslabón espera a que termine el anterior. Los servicios que no están en esa cadena se restauran a la vez y no la alargan.

Abre servicios_caidos y suma solo los servicios de la cadena de prs-mes01.

Con el mismo cálculo para cada servicio se obtiene la hora en que estaría disponible, y de ella se resta su RTO para ver la brecha. Una brecha positiva significa que el plan no cumple lo prometido. Con más de un servicio fuera de su RTO, la dirección necesita saber cuál es el peor para decidir dónde poner refuerzos.

Abre servicios_caidos, calcula la disponibilidad de los servicios de aplicación y compara con rto_h.

Si el orden técnico correcto no cumple el RTO de un servicio, saltarse las dependencias no es una salida: el servicio arrancaría sin lo que necesita. Lo que se hace es decirlo a la dirección con los números, y proponer lo que se puede cambiar: un procedimiento manual para operar mientras tanto, más personal para paralelizar o revisar el RTO si estaba mal puesto.