Diagrama de flujo del plan de recuperación ante desastres (TI)
Diagrama de flujo con carriles del proceso de recuperación ante desastres de TI: criterios de activación, priorización por RTO y RPO, conmutación, restauración de datos, validación y retorno.
Cómo funciona
Renombra los carriles con los roles que tenéis de verdad
Sustituye Detección / Operaciones, Coordinador de recuperación, Dirección, Equipo de infraestructura y Responsables de aplicación por vuestros roles reales: NOC o monitorización, responsable de continuidad de servicios de TI, el directivo del turno de crisis, los equipos de plataforma y de bases de datos, los propietarios de cada servicio con nombre y apellidos. En organizaciones pequeñas es habitual fundir los carriles de coordinación e infraestructura; si un carril no tiene a nadie dentro, bórralo en lugar de dejarlo vacío.
Escribe vuestros criterios de activación sobre la decisión
Haz que «¿Se cumplen los criterios de activación?» sea lo bastante objetiva para aplicarla bajo presión: sede principal inaccesible, caída prevista superior al RTO de un sistema de nivel uno, almacenamiento o base de datos principal irrecuperable en su sitio. Nombra el rol autorizado a activar y a su suplente, y anota cómo se les localiza fuera del horario laboral.
Engancha cifras reales de RTO y RPO a cada sistema
Toma los objetivos del análisis de impacto en el negocio y no de lo que la infraestructura logra hoy, y ponlos por niveles junto a «Priorizar sistemas por RTO y RPO». Anota también el orden de dependencias además del orden de prioridad, porque una aplicación de nivel uno no se puede validar antes de que estén arriba los servicios de identidad, red y base de datos que tiene debajo.
Describe vuestro mecanismo real de recuperación
«Conmutar al sitio de recuperación» significa cosas muy distintas según haya infraestructura replicada, un respaldo templado, una segunda región de cloud o una reconstrucción desde soportes de copia. Mete en los comentarios de la caja el mecanismo, el enlace al procedimiento, dónde están las credenciales y las cuentas de emergencia y cualquier cambio manual de DNS o de red, para que el diagrama sirva durante una recuperación y no solo durante una revisión.
Define qué significa «integridad verificada» y quién lo dice
Fija las comprobaciones que hay detrás de «¿Integridad de los datos verificada?»: recuentos de registros, comprobaciones de consistencia e integridad referencial, pruebas de humo a nivel de aplicación, comparación con el último estado bueno conocido. Decide qué significa «una copia anterior», cuántos intentos de restauración haréis antes de escalar, y ten presente que cada paso atrás aumenta la pérdida de datos que tendrás que declarar frente al RPO.
Añade el retorno, prueba el diagrama y conserva la versión
Confirma que la ruta de retorno coincide con vuestra forma de trabajar: ventana, resincronización de los datos escritos en el sitio de recuperación, aprobación por control de cambios y el momento en el que se desactiva formalmente el plan. Después ejercita el diagrama, compara en la revisión posterior el tiempo de recuperación y la pérdida de datos reales frente a vuestros objetivos, y publica la versión aprobada para que la gente ensaye la misma revisión que seguiría en vivo.
Preguntas frecuentes
¿Qué diferencia hay entre recuperación ante desastres y continuidad de negocio?
La continuidad de negocio consiste en que la organización siga entregando sus productos y servicios durante una interrupción, por los medios que hagan falta: alternativas manuales, instalaciones sustitutas, personas reasignadas, proveedores de respaldo, comunicación con clientes. La recuperación ante desastres es la parte de TI: restablecer los sistemas, los datos y la infraestructura de los que depende la organización. El trabajo de continuidad marca las prioridades, porque es el análisis de impacto en el negocio el que decide qué actividades importan más y cuánto pueden estar interrumpidas; la recuperación ante desastres hereda esos tiempos como objetivos de RTO y RPO y responde por ellos. Un plan de recuperación sin entrada de continuidad tiende a recuperar primero lo que es más fácil de recuperar.
¿Qué significan exactamente RTO y RPO?
El RTO, tiempo objetivo de recuperación, es el plazo dentro del cual un sistema o servicio debe volver a ser usable, medido hacia delante desde la interrupción y no desde el momento en que alguien firma la activación. El RPO, punto objetivo de recuperación, es el momento al que deben restaurarse los datos, medido hacia atrás desde la interrupción, de modo que en la práctica es la pérdida máxima de datos que la organización acepta. Empujan inversiones distintas: el RTO depende de la rapidez con que puedas levantar la infraestructura (capacidad de respaldo, automatización, ensayo), mientras que el RPO está limitado por cada cuánto se copian los datos, así que una copia nocturna no puede sostener un RPO de menos de un día por rápida que sea la restauración. Ambos términos están definidos en normas de continuidad como la ISO 22301.
¿Quién debe autorizar la activación del plan, y cuándo?
La activación debe recaer en un rol que pueda asumir el coste y el riesgo de conmutar, normalmente un directivo o el jefe de crisis, con un suplente con nombre y una vía documentada fuera del horario laboral. En este diagrama está deliberadamente separada del rol de coordinador: el coordinador evalúa y recomienda, la dirección autoriza y el coordinador dirige después la recuperación. El disparador debe estar escrito de antemano y ser comprobable con datos disponibles pronto en la caída, porque el error caro no es activar demasiado pronto: es pasarse tres horas decidiendo si esto cuenta mientras corre el reloj del RTO.
¿Qué pasa si los datos restaurados no superan la comprobación de integridad?
El diagrama hace un bucle en lugar de seguir adelante: «¿Integridad de los datos verificada?» manda la rama Fallida a «Restaurar desde una copia anterior», que devuelve al paso de restauración para volver a verificar. Ese bucle es donde el RPO se pone a prueba en condiciones reales, porque cada paso atrás hacia una copia más antigua aumenta la pérdida de datos que tendrás que declarar, y en algún momento la respuesta honesta es que el objetivo no se puede cumplir y hay que decirle al negocio qué periodo tendrá que reconstruir a mano. Merece la pena acordar de antemano cuántos intentos se hacen, quién puede aceptar un punto de recuperación peor que el RPO y cómo se deja constancia de la diferencia.
¿Cada cuánto hay que probar el proceso de recuperación ante desastres?
Lo bastante a menudo como para que el plan refleje el parque actual, y con los resultados por escrito. La mayoría de las organizaciones combinan varias cosas: comprobaciones frecuentes de restauración sobre las copias, pruebas parciales o de componentes a lo largo del año y un ejercicio más completo con una periodicidad regular, habitualmente anual, con los sectores regulados y los servicios críticos exigiendo más. Importa más qué se prueba que cada cuánto. Una restauración que nunca llega a montarse y leerse no demuestra nada, y un ejercicio que se salta la validación y el retorno tiende a ocultar los dos problemas que más duelen en un suceso real: responsables de aplicación encontrando fallos que nadie previó y ninguna ruta acordada de vuelta al sitio principal.