Resilience

Continuidad operativa en TI: marco práctico para directores

IT Operational Continuity: A Practical Framework for Directors

Ninguna infraestructura está exenta de fallar. La pregunta que ordena la gestión de TI no es si habrá una interrupción, sino cuánto tardará la operación en recuperarse y cuánta información se perderá en el intento. La continuidad operativa es la disciplina que responde esa pregunta antes de que ocurra el incidente, no durante. Para un director de TI, tenerla resuelta es la diferencia entre una crisis gestionada y una improvisada.

¿Qué es la continuidad operativa en TI?

La continuidad operativa es la capacidad de una organización para mantener sus funciones esenciales durante y después de un evento disruptivo: un corte de energía, una falla de hardware, un ciberataque o un desastre natural. En el ámbito de TI, se materializa en un plan que define de antemano cómo se sostiene o se restablece cada servicio crítico, con qué recursos y en qué plazos.

Conviene distinguir dos conceptos que suelen confundirse. El plan de continuidad de negocio (BCP) abarca a toda la organización (personas, procesos, instalaciones) y busca que la empresa siga operando. El plan de recuperación ante desastres (DRP) es su componente tecnológico: se enfoca en restaurar los sistemas, los datos y la infraestructura de TI. Uno no reemplaza al otro; el DRP es la pieza de TI dentro del marco más amplio del BCP.

La diferencia entre ambos no es solo terminológica. Un plan de continuidad de negocio puede contemplar, por ejemplo, dónde trabajará el personal si una oficina queda inaccesible, mientras que el plan de recuperación ante desastres define cómo se restauran los servidores y las bases de datos que sostienen la operación. Para un director de TI, la prioridad es que el componente tecnológico sea sólido y esté alineado con lo que el negocio necesita para seguir funcionando, no que existan como documentos separados sin conexión entre sí.

Los dos indicadores que ordenan el plan: RTO y RPO

Todo plan de continuidad serio se construye sobre dos métricas que traducen el riesgo a números accionables:

RTO: Recovery Time Objective

Es el tiempo máximo que un servicio puede permanecer caído antes de que el impacto en el negocio sea inaceptable. Un sistema de facturación quizá tolere cuatro horas; una plataforma transaccional, apenas minutos. El RTO define cuán rápido debe ser el mecanismo de recuperación y, por lo tanto, cuánto conviene invertir en él.

RPO: Recovery Point Objective

Es la cantidad máxima de datos que la organización puede permitirse perder, medida en tiempo. Un RPO de una hora significa que los respaldos deben ser lo bastante frecuentes para que, ante una falla, nunca se pierda más de una hora de información. Cuanto menor el RPO, más frecuente y robusta debe ser la estrategia de respaldo y replicación.

La relación entre ambos indicadores es lo que da forma a la inversión. Un RTO y un RPO muy ajustados (de minutos) exigen infraestructura de recuperación sofisticada: replicación en tiempo real, sitios alternos listos para tomar la operación, automatización del failover. Un RTO y un RPO más holgados (de horas) permiten esquemas más económicos basados en respaldos periódicos. Definir estos números para cada proceso crítico es, en la práctica, decidir cuánto vale la pena invertir en proteger cada uno, y ese es exactamente el tipo de decisión que corresponde a la dirección, no solo al equipo técnico.

Cómo construir el plan, paso a paso

Un marco de continuidad operativa se levanta sobre cuatro etapas ordenadas:

Analizar el impacto en el negocio. Identificar qué procesos son verdaderamente críticos y cuánto cuesta cada hora de inactividad. Este análisis, no la intuición, es lo que define las prioridades.
Asignar RTO y RPO por proceso. Cada servicio crítico recibe sus propios objetivos de recuperación. No todo necesita el mismo nivel: sobredimensionar cuesta caro y subdimensionar deja expuesto lo importante.
Diseñar la arquitectura de respaldo y recuperación. Definir dónde viven las copias, cómo se replican los datos y qué infraestructura sostiene la operación cuando la principal falla. Aquí entran el respaldo en sitio, la replicación remota y la infraestructura de recuperación.
Probar y actualizar el plan. Un plan que nunca se ejecuta en simulacro es una hipótesis, no una garantía. Las pruebas periódicas revelan los huecos antes de que lo haga un incidente real.

Contra qué protege un plan de continuidad

Un plan de continuidad no se diseña contra un solo tipo de amenaza, sino contra la variedad de eventos que pueden detener la operación. Reconocerlos ayuda a dimensionar el plan:

Fallas de infraestructura. Cortes de energía, fallas de hardware o de los sistemas de respaldo. Son la causa más frecuente de interrupciones y, muchas veces, la más subestimada.
Errores humanos. Configuraciones equivocadas, cambios sin pruebas suficientes o fallas de gestión durante el mantenimiento. Una porción muy alta de las interrupciones tiene su origen en la operación, no en la tecnología.
Ciberataques. El ransomware y otros incidentes de seguridad pueden dejar sistemas y datos inaccesibles, lo que convierte al plan de continuidad en parte de la estrategia de ciberseguridad.
Desastres naturales. Sismos, inundaciones u otros eventos que afectan físicamente una instalación y exigen que la operación pueda sostenerse desde otro sitio.

Los errores más comunes al construir el plan

Muchos planes de continuidad fracasan no por falta de intención, sino por defectos que se repiten. El primero es tratar el plan como un documento de cumplimiento que se redacta una vez y se archiva, en lugar de un mecanismo vivo que se prueba y actualiza. Un plan que nunca se ejecutó en un simulacro es una hipótesis, no una garantía: la primera vez que se pone a prueba no debería ser durante un incidente real.

El segundo error es aplicar el mismo nivel de protección a todo por igual, sin distinguir lo crítico de lo accesorio. Eso lleva a sobreinvertir en sistemas que podrían tolerar una caída y, al mismo tiempo, a dejar expuesto lo verdaderamente importante. El tercero es olvidar que la recuperación depende de la conectividad: si el sitio de respaldo existe pero el enlace que lo conecta no ofrece garantías, el plan tiene un eslabón débil que solo se descubre en el peor momento.

Cómo priorizar: no todo es igual de crítico

El corazón de un plan de continuidad realista es aceptar que no todos los sistemas merecen el mismo nivel de protección. Intentar blindar todo por igual es caro e ineficiente; dejar todo al mismo nivel básico es peligroso. La respuesta está en clasificar los procesos por su criticidad para el negocio, y esa clasificación surge del análisis de impacto, no de la percepción de cada área sobre lo importante que es su propio sistema.

Una forma práctica de ordenarlo es agrupar los procesos en niveles. Los procesos críticos (aquellos cuya caída detiene ingresos, incumple obligaciones regulatorias o daña la relación con los clientes) exigen los RTO y RPO más ajustados y la infraestructura de recuperación más robusta. Los procesos importantes pero no críticos toleran ventanas de recuperación más amplias. Y los procesos de soporte pueden restaurarse cuando lo demás ya esté en pie. Esta jerarquía convierte un presupuesto limitado en una estrategia: se invierte donde el impacto lo justifica y se ahorra donde el riesgo es asumible.

La continuidad como decisión de infraestructura

El plan más detallado depende, al final, de la infraestructura que lo sostiene. De poco sirve fijar un RTO de minutos si la recuperación descansa en un solo sitio sin redundancia, o si el enlace que conecta la operación con su respaldo no ofrece garantías. Por eso la continuidad operativa termina siendo también una decisión de arquitectura: dónde se alojan los sistemas, con qué redundancia y con qué calidad de conectividad entre los puntos.

Un proveedor con red propia y redundante en la región, sumado a soluciones de continuidad e infraestructura pensadas para cargas críticas, permite que los objetivos de RTO y RPO dejen de ser una aspiración en el papel y se vuelvan sostenibles en la práctica.