Son las 3:14 de la madrugada y el sistema de facturación dejó de responder. El reloj corre, los pedidos se acumulan y cada minuto que pasa tiene un precio: ventas que no se cierran, clientes que no pueden operar, equipos paralizados esperando que algo vuelva a encenderse. La pregunta que define a una organización en ese instante no es si ocurrió la falla, sino cuánto tarda en recuperarse y cuánta información perdió por el camino. Esa es la conversación de fondo en cualquier plan de recuperación ante desastres.
En corto: el tiempo de recuperación es dinero. Un plan de recuperación ante desastres (DRP) serio no se mide por la cantidad de páginas que tiene, sino por dos números acordados con el negocio: el RTO (cuánto puede estar caído un servicio) y el RPO (cuánta información puede perderse). Definir esos números por criticidad, y respaldarlos con replicación y recuperación en caliente, es lo que separa un susto de una crisis.
Cuando un servicio crítico se cae, el costo no es lineal: crece con cada hora. Hay costos visibles, como ventas no facturadas o penalizaciones contractuales, y costos silenciosos que pesan más a largo plazo: confianza erosionada, equipos reasignados a apagar incendios y decisiones que se toman a ciegas porque los datos no están disponibles.
El error frecuente es tratar todos los sistemas por igual. No todo necesita volver en minutos, pero algunos servicios no pueden esperar horas. Por eso la primera disciplina de un DRP es ponerle un valor al tiempo: ¿qué cuesta una hora de caída de este servicio en particular? Esa respuesta, aunque sea aproximada, ordena todo lo demás.
Hay dos métricas que conviene fijar antes de comprar tecnología o diseñar arquitecturas. Son la columna vertebral de cualquier estrategia de recuperación ante desastres:
La clave es que ambos números los define el negocio, no la tecnología. El área técnica diseña la solución para cumplirlos; el dueño del proceso decide cuánto tiempo y cuántos datos son tolerables. Cuando esa conversación no ocurre, la organización descubre sus RTO y RPO reales el día del incidente, y casi siempre son peores de lo que imaginaba.
No se trata de pedir "cero downtime y cero pérdida" para todo, porque eso es caro y, en la mayoría de los casos, innecesario. Se trata de graduar. Una forma práctica de hacerlo:
Este ejercicio es, en realidad, una extensión del análisis de impacto al negocio que vive dentro de un plan de continuidad de negocio. El DRP es la pata tecnológica de esa continuidad: traduce las prioridades del negocio en objetivos medibles de recuperación.
Con los RTO y RPO definidos, conviene agrupar los servicios en niveles o tiers. Esto evita gastar de más en lo que no lo amerita y de menos en lo que sí. Un esquema de referencia, que cada organización ajusta a su realidad:
El valor de esta clasificación es que convierte una discusión emocional ("¡todo es urgente!") en una decisión de inversión razonada. Cada nivel tiene un costo y una arquitectura asociados, y el negocio puede ver qué está pagando por cada minuto que se ahorra.
Para los servicios de nivel crítico, los respaldos tradicionales rara vez alcanzan: restaurar desde una copia puede tomar horas que el RTO no permite, y la copia de anoche puede violar un RPO de minutos. Ahí entran dos capacidades:
Estas capacidades cuestan más, y por eso se reservan para lo que de verdad las necesita. La decisión inteligente no es "replicar todo", sino alinear el nivel de protección de cada servicio con el RTO y el RPO que el negocio acordó pagar. Un DRP maduro es, en el fondo, una negociación honesta entre el costo del tiempo y el costo de la prevención.
Un punto que conviene recordar en estos meses de cierre de año, cuando se planifican presupuestos: un DRP no es un entregable que se archiva. Es una capacidad que se mantiene viva. Los RTO y RPO definidos hoy deben revisarse cuando cambia el negocio, cuando se agregan sistemas o cuando una adquisición altera el mapa de procesos. El número que era tolerable el año pasado puede ser ruinoso hoy.
El RTO mide tiempo de indisponibilidad: cuánto puede estar caído un servicio. El RPO mide pérdida de datos: hasta qué punto en el pasado puede recuperar la información. Un servicio puede tener un RTO alto y un RPO bajo, o viceversa, según lo que el negocio tolere.
No. Los respaldos son una pieza dentro del DRP. Para servicios diferibles pueden ser suficientes; para servicios críticos hacen falta además replicación y recuperación en caliente, porque restaurar desde una copia suele tardar más de lo que el RTO permite.
Partiendo del negocio, no de la tecnología. Mapee los procesos, estime el costo de tenerlos detenidos por unidad de tiempo y deje que ese impacto defina la criticidad. Un servidor importante para TI puede sostener un proceso diferible, y al revés.
Sería lo más caro, y no necesariamente lo más sensato. La protección debe ser proporcional al impacto. Replicación y recuperación en caliente se justifican donde cada minuto cuesta; en el resto, encarecen la operación sin un retorno claro.
Si su organización todavía no tiene un RTO y un RPO acordados por escrito para sus servicios críticos, ese es el lugar por donde empezar: una conversación entre el negocio y la tecnología que le ponga número al costo del tiempo. En SUMāTO acompañamos ese ejercicio, desde la clasificación de servicios por niveles hasta el diseño de la replicación y la recuperación en caliente que cada nivel requiere. Conversemos sobre cómo asegurar que, la próxima vez que el reloj empiece a correr, usted sepa exactamente cuánto puede esperar y cuánto puede perder.