Recuperación TI: orden de restauración por dependencias

Restaurar servidores no equivale a recuperar el servicio

Una aplicación puede estar encendida y seguir siendo inutilizable si no resuelve su nombre, no valida usuarios, no alcanza la base de datos o depende de un servicio externo caído. El plan de continuidad debe describir esas relaciones y ordenar la recuperación según el impacto de negocio, no limitarse a una lista de máquinas.

La guía de contingencia NIST SP 800-34 recomienda que la secuencia de recuperación refleje las prioridades del análisis de impacto y que los procedimientos sigan pasos lógicos entre componentes. Es una referencia técnica adaptable: cada empresa debe contrastarla con su arquitectura, contratos y requisitos aplicables.

Mapa mínimo de dependencias

Para cada servicio crítico, registra:

• Resultado de negocio: qué proceso habilita y quién confirma que vuelve a funcionar.
• Piezas técnicas: identidad, DNS, conectividad, certificados, secretos, almacenamiento, base de datos, aplicación e integraciones.
• Orden y condiciones: qué debe estar operativo antes del siguiente componente y qué prueba demuestra que está listo.
• Responsables y accesos: equipo de ejecución, aprobador, contactos externos y credenciales de emergencia guardadas fuera del dominio afectado.
• Objetivos de recuperación: RTO y RPO aprobados para el servicio, junto con cualquier modo degradado temporal.

Representa las relaciones como un grafo sencillo. Una dependencia compartida —por ejemplo, identidad corporativa o DNS— puede convertirse en el cuello de botella de varios servicios. Señálala como componente transversal y planifica cómo acceder al entorno de recuperación si el proveedor de identidad principal no está disponible.

Ejemplo: volver a poner en marcha el ERP

En un escenario hipotético, el ERP depende de red, resolución DNS, identidad, base de datos, almacenamiento y una integración con el banco. El runbook podría preparar primero el acceso administrativo independiente, comprobar la conectividad y el DNS de recuperación, validar el almacenamiento y la base de datos y, después, restaurar la aplicación. La integración bancaria se habilita cuando el equipo funcional verifica saldos, colas y transacciones pendientes.

Ese orden no es universal. Si la arquitectura real exige otro prerrequisito, prevalecen el diseño probado y las instrucciones del fabricante. Evita reconectar automáticamente sistemas restaurados a integraciones productivas antes de revisar duplicados o mensajes en espera.

Cómo comprobar que el orden sirve

Haz un ejercicio de mesa para revisar responsables y decisiones; luego ejecuta una prueba técnica acotada que mida tiempos, valide datos y registre bloqueos. Tras cada prueba, actualiza dependencias que hayan cambiado y asigna dueño a cada acción pendiente. Complementa el mapa con el guion de prueba de restauración de backups y la planificación RTO/RPO de recuperación.